Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide
C
HAPTER
9:
C
ONFIGURABLE
E
LEMENTS
C
ISCO
CVP V
OICE
XML 3.1
Programmer
Guide
The diagram shows a typical exchange between the voice browser, CVP VoiceXML Server, and
several voice elements. In step 1, the voice browser makes an HTTP request for a VoiceXML
page to the Server. According to its record of the application call flow, the 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 the 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 the Server. Before exiting, it puts in the scratch space information
indicating that page A was completed. Foo returns a
several voice elements. In step 1, the voice browser makes an HTTP request for a VoiceXML
page to the Server. According to its record of the application call flow, the 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 the 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 the Server. Before exiting, it puts in the scratch space information
indicating that page A was completed. Foo returns a
null
exit state, indicating to the Server that
the voice element is not done. In step 4, the 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, the Server knows to go back to Foo
because it previously returned a
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, the Server knows to go back to Foo
because it previously returned a
null
exit state. It revisits Foo, passing along the two arguments.
Since the 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, the 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, the 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.
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, the 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, the 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
Cisco CVP VoiceXML 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.
Restrictions
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.
Restrictions
•
The voice element must produce VoiceXML using the CVP VoiceXML Voice Foundation
Classes (VFCs). The VFCs are the mechanism through which the voice element produces the
VoiceXML to send to the voice browser and CVP VoiceXML 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 CVP VoiceXML 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 the 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 the 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.
Copyright 2001 - 2005 Audium Corporation. All Rights Reserved. 10/05
56