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

C

HAPTER 

4:

 

C

ALL 

S

TART 

A

CTION

 

 

V

OICE

XML

 

P

ROGRAMMING 

G

UIDE 

 

 

 

FOR 

C

ISCO 

U

NIFIED 

C

USTOMER 

V

OICE 

P

ORTAL 

R

ELEASE 

4.0(1) 

 

 

 

19

 

Unified CVP VoiceXML Server can be configured to run code when a call has been received 
before the call flow is visited. The call start action can be implemented with either the Java API 
or the XML API. The call start action is a good way to create session data to be used by the rest 
of the application. There are two situations where session data may already exist: 

    If the voice browser passed additional arguments to the VoiceXML Server when the call was 

first received, these additional arguments are added as session data with the arguments’ 
name/value pairs translated to the session data name and value (both as 

String

s). 

    If a separate Cisco Unified CVP voice application transferred to the current application, the 

application designer may have chosen to transfer element and session data to the destination 
application. This data will be converted to session data in the destination application.  

The call start action is also given the ability to change the voice browser and any root document-
affecting settings for the call. These changes apply to the current call only, and allows for a truly 
dynamic application. By allowing the voice browser to change, the application can be deployed 
on multiple voice browsers at once and use a simple DNIS check to output VoiceXML to the 
appropriate browser. Changing root document settings such as properties and language allow the 
call start action to control how the application appears to the caller using information it knows 
only at call time. Note that these changes can only be made by the call start action because it runs 
before the VoiceXML Server has returned the first VoiceXML page and therefore can make 
changes that affect the outputted VoiceXML. Aside from these settings, the call start action can 
also change the maintainer and default audio path, though any component run within the call can 
do this as well. 

The start of call event can be run in the background by checking the appropriate checkbox in the 
Unified CVP VoiceXML Studio application settings. If this is not done, the caller will hear 
silence until the call start action is complete and the call flow reaches the first VoiceXML-
producing element. Answering the phone with too much silence could cause the caller to hang-
up, thinking something went wrong. Latency issues are not as big a concern later in the 
application because audio can be played while action is executing or the application could make 
the caller aware that some potentially lengthy action is about to occur. Running the call start 
action in the background will ensure that the call flow will begin immediately. 

Some notes of caution are warranted when running the call start action in the background. 
Firstly, ensure that elements in the call flow that attempt to access data created by the call start 
action do not try too quickly since it is possible the data has not been created yet. Since the call 
start action is run in a separate thread, there is no guarantee it will complete before the data it 
creates is required. The application can be architected to handle this by checking if the data 
exists before accessing it and if not, make the caller wait until it is created. Secondly, any errors 
that occur during execution of this action are placed in the error log but do not end the call 
(unless the application cannot run without performing the tasks in the call start action).