Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide

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 

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 

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. 

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. 

    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. 

    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.