Cisco Cisco Unified Customer Voice Portal 11.0(1) User Guide
C
HAPTER
2:
V
OICE
XML
S
ERVER
C
OMPONENTS IN
D
ETAIL
V
OICE
XML
S
ERVER
U
SER
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
20
Dynamic Element Configurations
Each configurable voice, action, and decision element used in an application must have a
configuration. Usually, the configuration will be fixed - it acts the same for every caller that
visits it. In these situations, the designer using Unified CVP VoiceXML Studio creates this
configuration in the Configuration Pane. This configuration is saved as an XML file when the
application is deployed.
configuration. Usually, the configuration will be fixed - it acts the same for every caller that
visits it. In these situations, the designer using Unified CVP VoiceXML Studio creates this
configuration in the Configuration Pane. This configuration is saved as an XML file when the
application is deployed.
There are situations, though, that a configuration for an element depends on information known
only at runtime – it is dynamic. An example would be to configure the Unified CVP audio voice
element to play a greeting message depending on the time of the day. Only at runtime does the
application know the exact calling time and therefore what greeting message to play.
only at runtime – it is dynamic. An example would be to configure the Unified CVP audio voice
element to play a greeting message depending on the time of the day. Only at runtime does the
application know the exact calling time and therefore what greeting message to play.
To produce dynamic configurations, programming is required. Dynamic element configurations
are responsible for taking a base configuration (a partial configuration created in the Unified
CVP VoiceXML Studio), adding to it or changing it depending on the application business logic,
and returning the desired element configuration to Unified CVP VoiceXML Server.
are responsible for taking a base configuration (a partial configuration created in the Unified
CVP VoiceXML Studio), adding to it or changing it depending on the application business logic,
and returning the desired element configuration to Unified CVP VoiceXML Server.
Start / End of Call Actions
Unified CVP provides mechanisms to execute some code when a phone call is received for a
particular application or when the call ends. The end of a call is defined as either a hang up by
the caller, a hang up by the system, a move from one VoiceXML application to another
VoiceXML application, or other rarer ways for the call to end such as a blind transfer or session
timeout.
particular application or when the call ends. The end of a call is defined as either a hang up by
the caller, a hang up by the system, a move from one VoiceXML application to another
VoiceXML application, or other rarer ways for the call to end such as a blind transfer or session
timeout.
The purpose of the start of call action is typically to set up dynamic information that is used
throughout the call, for example, the current price of a stock or information about the caller
identified by their ANI in some situations. The end of call action is typically used to export
information about the call to external systems, perform call flow history traces, or execute other
tasks that require information on what occurred within the call.
The start of call action is given the special ability to change the voice browser of the call. This
change applies 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 compatible with the appropriate browser.
This task can only be done in the start of call action because the call technically has not started
when this action occurs.
throughout the call, for example, the current price of a stock or information about the caller
identified by their ANI in some situations. The end of call action is typically used to export
information about the call to external systems, perform call flow history traces, or execute other
tasks that require information on what occurred within the call.
The start of call action is given the special ability to change the voice browser of the call. This
change applies 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 compatible with the appropriate browser.
This task can only be done in the start of call action because the call technically has not started
when this action occurs.
The end of call action is given the special ability to produce a final VoiceXML page to send to
the browser. Even though the caller is no longer connected to the browser by the time the end of
call action is run, some voice browsers will allow for the interpretation of a VoiceXML page sent
back in response to a request triggered by a disconnect or hang-up event. Typically this page will
perform final logging tasks on the browser.
the browser. Even though the caller is no longer connected to the browser by the time the end of
call action is run, some voice browsers will allow for the interpretation of a VoiceXML page sent
back in response to a request triggered by a disconnect or hang-up event. Typically this page will
perform final logging tasks on the browser.