Cisco Cisco Customer Voice Portal Downloads Guide Du Développeur
C
HAPTER
9:
C
ONFIGURABLE
E
LEMENTS
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
48
The diagram shows a typical exchange between the voice browser, Unified CVP VoiceXML
Server, and several voice elements. In step 1, the voice browser makes an HTTP request for a
VoiceXML page to the VoiceXML Server. According to its record of the application call flow,
the VoiceXML 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
VoiceXML 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 VoiceXML
Server. Before exiting, it puts in the scratch space information indicating that page A was
completed. Foo returns a
Server, and several voice elements. In step 1, the voice browser makes an HTTP request for a
VoiceXML page to the VoiceXML Server. According to its record of the application call flow,
the VoiceXML 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
VoiceXML 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 VoiceXML
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 VoiceXML Server that the voice
element is not done. In step 4, the VoiceXML 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 VoiceXML 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 VoiceXML 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 VoiceXML 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 VoiceXML 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 VoiceXML 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.
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 VoiceXML 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 VoiceXML 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 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.
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 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 Unified CVP VoiceXML Server is tightly
integrated with them. See 0 The Voice Foundation Classes for a full description of the VFCs.
VoiceXML to send to the voice browser and Unified CVP VoiceXML Server is tightly
integrated with them. See 0 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 VoiceXML 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.
ability to activate hotlinks, perform logging, and activate the end of call action.