Cisco Cisco Customer Voice Portal Downloads 릴리스 노트
C
HAPTER
1:
I
NTRODUCTION
U
SER
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
11
provided to allow seamless integration of VoiceXML insert elements with the rest of the call
flow.
flow.
The use of VoiceXML insert elements has its consequences such as the loss of being able to
seamlessly switch between different voice browsers, some greater processing overhead involved
with integration with the rest of the call flow, as well as the added complexity of dealing with
VoiceXML itself rather than creating an application with easy to use configurable elements.
seamlessly switch between different voice browsers, some greater processing overhead involved
with integration with the rest of the call flow, as well as the added complexity of dealing with
VoiceXML itself rather than creating an application with easy to use configurable elements.
VoiceXML insert elements can have as many exit states as the developer requires, with a
minimum of one.
minimum of one.
Decision Elements
Even the simplest voice applications require some level of decision making throughout the call
flow. These “crossroads” are encapsulated in decision elements.
flow. These “crossroads” are encapsulated in decision elements.
Decision Element
Encapsulates business logic that make decisions with at least two exit
states.
states.
A decision element is like a traffic cop, redirecting the flow of callers according to built in
business rules. Examples of business rules include decisions such as whether to play an ad to a
caller, which of five different payment plans should be offered to the caller, or whether to
transfer a caller to an agent or hang up.
business rules. Examples of business rules include decisions such as whether to play an ad to a
caller, which of five different payment plans should be offered to the caller, or whether to
transfer a caller to an agent or hang up.
The results of a decision element are represented as exit states. Although many decisions are
boolean in nature, (e.g. “has the caller registered?”, “is the caller new to the application?”),
decision elements can have as many exit states as desired, as long as at least two are specified.
boolean in nature, (e.g. “has the caller registered?”, “is the caller new to the application?”),
decision elements can have as many exit states as desired, as long as at least two are specified.
The configuration for a configurable decision contains two components: settings and variables.
Additionally, the Java class that defines the configurable decision sets the exit states it can return
and the designer must map each exit state to another call flow component to handle all its
consequences.
Additionally, the Java class that defines the configurable decision sets the exit states it can return
and the designer must map each exit state to another call flow component to handle all its
consequences.
Action Elements
Many voice applications require actions to occur “behind the scenes” at some point in the call. In
these cases, the action does not produce VoiceXML (and thus has no audible effect on the call)
or perform some action that branches the call flow (like a decision). Instead the action makes a
calculation, interfaces with a backend system such as a database or legacy system, stores data to
a file or notifies an outside system of a specific event. All of these processes are built into action
elements.
these cases, the action does not produce VoiceXML (and thus has no audible effect on the call)
or perform some action that branches the call flow (like a decision). Instead the action makes a
calculation, interfaces with a backend system such as a database or legacy system, stores data to
a file or notifies an outside system of a specific event. All of these processes are built into action
elements.
Action Element
Encapsulates business logic that performs tasks not affecting the call
flow (i.e., has only one exit state).
flow (i.e., has only one exit state).