Cisco Cisco Unified Customer Voice Portal 10.5(1) Release Note
C
HAPTER
4:
C
ALL
S
TART
A
CTION
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
7.0(1)
21
Chapter 4: Call Start Action
VXML 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:
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 VXML 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
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 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.
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 VXML 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.
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 VXML 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
Call 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.
Call 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).
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).