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:
-
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 (each is a String
).
-
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.
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 |
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.
Some notes of caution are warranted when running the call
start action in the background:
-
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.
-
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).