Cisco Cisco Unified Customer Voice Portal 10.0(1) Developer's Guide
C
HAPTER
9:
C
ONFIGURABLE
E
LEMENTS
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
4.1(1)
51
The diagram shows a typical exchange between the voice browser, VXML Server, and several
voice elements. In step 1, the voice browser makes an HTTP request for a VoiceXML page to
VXML Server. According to its record of the application call flow, VXML Server in step 2
accesses the voice element Foo. The voice element Foo is shown on the right. The element is
coded to contain within it a small call flow with three possible exit states. It can produce three
separate VoiceXML pages, A, B, and C. In step 2, the scratch space is empty, indicating that the
element is being visited for the first time. Foo therefore needs to produce the VoiceXML page A.
Note that the A contains in it a submit that points back to VXML Server and includes two
arguments “arg1” and “arg2”. In step 3, Foo produces the VoiceXML page by assembling VFC
objects and passes those objects back to VXML Server. Before exiting, it puts in the scratch
space information indicating that page A was completed. Foo returns a
voice elements. In step 1, the voice browser makes an HTTP request for a VoiceXML page to
VXML Server. According to its record of the application call flow, VXML Server in step 2
accesses the voice element Foo. The voice element Foo is shown on the right. The element is
coded to contain within it a small call flow with three possible exit states. It can produce three
separate VoiceXML pages, A, B, and C. In step 2, the scratch space is empty, indicating that the
element is being visited for the first time. Foo therefore needs to produce the VoiceXML page A.
Note that the A contains in it a submit that points back to VXML Server and includes two
arguments “arg1” and “arg2”. In step 3, Foo produces the VoiceXML page by assembling VFC
objects and passes those objects back to VXML Server. Before exiting, it puts in the scratch
space information indicating that page A was completed. Foo returns a
null
exit state, indicating
to VXML Server that the voice element is not done. In step 4, VXML Server converts the VFC
objects into a complete VoiceXML page that is sent back to the voice browser. In step 5, the
voice browser has parsed the VoiceXML and makes a new request for the next VoiceXML page.
The request contains the two arguments specified in the VoiceXML page A. In step 6, VXML
Server knows to go back to Foo because it previously returned a
objects into a complete VoiceXML page that is sent back to the voice browser. In step 5, the
voice browser has parsed the VoiceXML and makes a new request for the next VoiceXML page.
The request contains the two arguments specified in the VoiceXML page A. In step 6, VXML
Server knows to go back to Foo because it previously returned a
null
exit state. It revisits Foo,
passing along the two arguments. Since VXML Server maintains the session for each call, and
the scratch space is stored in the session, Foo can access the Session API to get the scratch space.
Foo’s scratch space indicates that A is complete. It makes a decision C based on the arguments
passed to it and chooses option 3, therefore requiring page D to be produced. Foo also notes that
after producing this page, it is done. In step 7, Foo returns the VFC objects containing page D
and returns with the exit state “Exit3”. In step 8, VXML Server produces the VoiceXML page
and sends it to the voice browser. In step 9, the voice browser parsed the VoiceXML page and
asks for the next one. Finally, in step 10, VXML Server notes that Foo returned an exit state of
“Exit3” so refers to the application call flow to discover where to go once Foo returns an exit
state of “Exit3”. It determines that the next voice element to access is “Bar”. The call continues
in this manner until it ends.
the scratch space is stored in the session, Foo can access the Session API to get the scratch space.
Foo’s scratch space indicates that A is complete. It makes a decision C based on the arguments
passed to it and chooses option 3, therefore requiring page D to be produced. Foo also notes that
after producing this page, it is done. In step 7, Foo returns the VFC objects containing page D
and returns with the exit state “Exit3”. In step 8, VXML Server produces the VoiceXML page
and sends it to the voice browser. In step 9, the voice browser parsed the VoiceXML page and
asks for the next one. Finally, in step 10, VXML Server notes that Foo returned an exit state of
“Exit3” so refers to the application call flow to discover where to go once Foo returns an exit
state of “Exit3”. It determines that the next voice element to access is “Bar”. The call continues
in this manner until it ends.
Restrictions and Recommendations
Unified CVP tries to make as few restrictions on building custom elements as possible. However,
in order to ensure proper integration of custom voice elements with the rest of the system, some
restrictions must be set. Additionally, there are guidelines that do not necessarily need to be
followed, though they are recommended for design and tighter integration considerations.
in order to ensure proper integration of custom voice elements with the rest of the system, some
restrictions must be set. Additionally, there are guidelines that do not necessarily need to be
followed, though they are recommended for design and tighter integration considerations.
Restrictions
•
The voice element must produce VoiceXML using the Unified CVP Voice Foundation
Classes (VFCs). The VFCs are the mechanism through which the voice element produces the
VoiceXML to send to the voice browser and VXML Server is tightly integrated with them.
See Appendix A: The Voice Foundation Classes for a full description of the VFCs.
Classes (VFCs). The VFCs are the mechanism through which the voice element produces the
VoiceXML to send to the voice browser and VXML Server is tightly integrated with them.
See Appendix A: The Voice Foundation Classes for a full description of the VFCs.
•
The voice element cannot define its own root document. The root document is automatically
generated by VXML Server and is vital for many features to function such as the ability to
activate hotlinks, perform logging, and activate the end of call action.
generated by VXML Server and is vital for many features to function such as the ability to
activate hotlinks, perform logging, and activate the end of call action.