Cisco Unified CVP VoiceXML components in Detail
Available Languages
Contents
- Cisco Unified CVP VoiceXML components in Detail
- Components
- Variables
- Global data
- Application data
- Session data
- Element data
- Component accessibility
- APIs
- Configurable elements
- Standard Action and Decision Elements
- Dynamic Element Configurations
- Start / End of Call Actions
- Hotevents
- Say it Smart Plugins
- Start and End of Application Actions
- Loggers
- On Error notification
- Unified CVP XML Decisions in detail
- <call_data>
- <data>
- <user_info>
- <general_date_time>
- <caller_activity>
- <historical_data>
- XML Decision Example #1
- XML Decision Example #2
- XML Decision Example #3
- VoiceXML insert elements
- Insert Element Restrictions
- Insert Element Inputs
- Insert Element Outputs
- Root document
- Example of insert elements
Cisco Unified CVP VoiceXML components in Detail
Some components of VXML Server require detailed explanations on how to use them properly, especially when their functionality requires or is extended by programming. While it is certainly possible to create a voice application entirely dependent on fixed data, most dynamic applications will require some programming work.
It is important for the non-developer user to be aware of these components and the functions they serve. The application designer will need to understand in what situations various components are needed so that a comprehensive specification can be given to a developer responsible for building these components.
This chapter describes these components in more detail, explaining typical situations where they would be used. It also describes the Unified CVP concepts utilized in order to develop and use the components. The Programming Guide for Cisco Unified CVP VXML Server and Unified Call Studio describes the components that require programming from the developer’s standpoint, explaining the process of constructing and deploying them. One can think of the Programming Guide for Cisco Unified CVP VXML Server and Cisco Unified Call Studio as a comprehensive description of what this chapter introduces.
- Components
- Variables
- APIs
- Configurable elements
- Standard Action and Decision Elements
- Dynamic Element Configurations
- Start / End of Call Actions
- Hotevents
- Say it Smart Plugins
- Start and End of Application Actions
- Loggers
- On Error notification
- Unified CVP XML Decisions in detail
- VoiceXML insert elements
Components
The components discussed in this chapter are:
- Built With Programming - These components require some programming effort.
- Call-Specific - These components are built to be used within individual calls.
- Custom Configurable Elements - A developer may wish to create their own reusable, configurable elements to supplement the elements Unified CVP provides.
- Standard Action and Decision Elements - For situations where unique, application-specific functionality is needed, thereby not requiring the flexibility and complexity of configurable elements.
- Dynamic Element Configurations - For situations where the configuration for a configurable element can only be determined at runtime.
- Start and End of Call Action - To perform tasks before each call begins and/or after each call ends.
- Hotevents - To specify the VoiceXML to execute when a certain VoiceXML event occurs.
- Say It Smart Plugins - To play back additional formatted data or to extend existing Say It Smart behavior.
- VXML Server-Specific - These components are built to run on VXML Server as a whole and do not apply to a specific call.
- Start and End of Application Actions - To perform tasks when a Unified CVP voice application is loaded and/or shuts down.
- Loggers - Plugins designed to listen to events that occur within calls to an application and log or report them.
- On Error Notification - To perform tasks if an error causes the phone call to end prematurely.
- Built Without Programming - These components do not require high-level programming effort to construct.
- XML Decisions - Unified CVP provides an XML format for writing simple decisions without programming. The exact XML format is detailed in this chapter.
- VoiceXML Insert Elements - This element is used in situations where the developer wishes to incorporate custom VoiceXML content into a Unified CVP application. The guidelines for building a VoiceXML insert element are given in this chapter.
Variables
Unified CVP offers variables as a mechanism for components to share data with each other, in four forms: global data, application data, session data and element data.
Global data
A global data variable is just that, it is globally accessible and modifiable from all calls to all applications. Global data is given a single namespace within VXML Server that is shared across all calls to all applications. If a component changes global data, that change is immediately available to all calls for all applications. Global data can hold any data, including a Java object. The lifetime of global data is the lifetime of VXML Server. Global data would be reset if the application server was to be restarted or the VXML Server web application archive (WAR) was to be restarted.
Global data is typically used to store static information that needs to be available to all components, no matter which application they reside in. For example, the holiday schedule of a company that applies to all applications for that company.
Application data
An application data variable is accessible and modifiable from all calls to a particular application. Application data variables from one application cannot be seen by components in another application. Each application is given its own namespace to store application data. If a component changes application data, that change is immediately available to all other calls to the application. Application data can hold any data, including a Java object. The lifetime of application data is the lifetime of the application. Application data would be reset if the application were updated and would be deleted if the application were released.
Application data is typically used to store application-specific information that does not change on a per call basis and is to be available to all calls (for example, the location of a database to use for the application).
Session data
Session data variables are accessible and modifiable from a single call session. Session data variables in one call cannot be accessed by components handling another call. Each session has its own session data namespace - session data set by one component will overwrite existing session data that has the same name. Session data can hold any data, including a Java data structure. The lifetime of session data is the lifetime of the session or the call. When the call ends, the session data is deleted.
Any component accessed within a call session, including elements, can create, modify and delete session data. Session data can even be created automatically by the system in two ways:
- If the voice browser passes additional arguments to VXML Server when the call is first received, these additional arguments will be added as session data with the arguments’ name/value pairs translated to the session data name and value (both as String types). For example, if the voice browser calls the URL:
http://myserver.com/CVP/Server?audium_application=MyApp&SomeData=1234This will create session data named SomeData with a value of 1234 in every call session of the application MyApp that starts via this URL.- If a Unified CVP voice application performs an application transfer to another application and the developer has chosen to pass data from the source application to the destination application, then this data will appear as session data in the destination application (the data is renamed before it is passed to the destination application). Please refer to the Call Studio documentation for more information on application transfers.
Element data
Element data variables are accessible from a single call session and modifiable from a single element within that call session. As the name suggests, element data can only be created by elements (excluding start and end of call events, the global error handler, hotevents, and XML decisions). Dynamic configurations are technically part of an element since they are responsible for configuring an element, so they can also create element data. Only the element that created an element data variable can modify or delete it, though it can be read by all other components. Due to the fact that the variable belongs to the element, the variable namespace is contained within the element, meaning two elements can define element data with the same name without interfering with each other. To uniquely identify an element data variable, both the name of the element and the name of the variable must be used. Like session data, the lifetime of session data is the lifetime of the session or the call. When the call ends, the element data is deleted.
Component accessibility
The following table lists each component and its ability to get and set global, application, session, and element data.
Global Data
Application Data
Session Data
Element Data
Component
Get
Set
Get
Set
Get
Set
Get
Set
Configurable Elements
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Standard Elements
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Dynamic Configurations
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Start and End of Call Actions
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Hotevents
No
No
No
No
No
No
No
No
Say It Smart Plugins
No
No
No
No
No
No
No
No
Start and End of Applications Actions
Yes
Yes
Yes
Yes
No
No
No
No
Loggers
Yes
No
Yes
No
Yes
No
Yes
No
On Error Notification
No
No
No
No
Yes
No
No
No
XML Decisions
No
No
No
No
No
No
No
No
VoiceXML Insert Elements
No
No
No
No
Yes
Yes
Yes
Yes
Note
Hotevents, being simply VoiceXML code appearing in the root document, do not have access to any server-side information.
Note
A Say It Smart Plugin’s sole purpose is to convert a value into a list of audio files and so do not have a need to access server-side information.
Note
A Logger's sole responsibility is to report or log data and therefore has access to all variables types but cannot set them.
Note
On Error Notification classes are given the session data that existed at the time the error occurred.APIs
To facilitate the development of components requiring programming effort, Unified CVP provides two application programming interfaces (APIs) for developers to use. The first is a Java API. The second API involves the use of XML sent via HTTP, thereby allowing components to be built using programming languages other than Java. Some more complex and tightly integrated components can be built only through the Java API, though in most other aspects, the two APIs are functionally identical. The APIs themselves and the process of building components using either API is fully detailed in the Javadocs published with the software and in the Programming Guide for Cisco Unified CVP VXML Server and Cisco Unified Call Studio. The two components that do not require the use of high-level programming, XML decisions and VoiceXML insert elements, are fully explained in this document.
The APIs are used to interface with VXML Server in order to retrieve data or change information. The API provided to each component has slightly different functionality reflecting each component’s unique abilities. The following lists abilities provided by the API that is common to most components used within a callflow:
- Getting call information such as the ANI, DNIS, call start time, application name, and so on.
- Getting or setting global data, application data, element data or session data.
- Getting information about the application’s settings such as the default audio path, voice browser, and so on.
- Setting the maintainer and default audio path. Changing the maintainer allows multiple people to maintain different parts of a single application. Changing the default audio path allows an application to change the persona or even language of the audio at any time during the call.
- Sending a custom event to all application loggers (see VXML Server Logging for more on logging with VXML Server).
The following table shows which APIs can be used to construct the various components listed.
VXML Server Component
Build with Java API
Build Using XML-over-HTTP API
VoiceXML Knowledge Suggested
Configurable Action and Decision Elements
Yes
No
No
Configurable Voice Elements
Yes
No
Yes
Standard Elements
Yes
Yes
No
Dynamic Element Configurations
Yes
Yes
No
Start or End of Call Actions
Yes
Yes
No
Hotevents
Yes
No
Yes
Say It Smart Plugins
Yes
No
No
Start and End of Application Actions
Yes
No
No
Loggers
Yes
No
No
On Error Notification
Yes
No
No
XML Decisions
N/A
N/A
N/A
VoiceXML Insert Elements
N/A
N/A
Yes
Configurable elements
Most of the elements in a typical Unified CVP application are pre-built, reusable elements whose configurations are customized by the application designer. Using a configurable element in a call flow requires no programming or VoiceXML expertise and since they can encapsulate a lot of functionality, greatly simplifies and speeds up the application building process. VXML Server includes dozens of elements that perform common tasks such as collecting a phone number or sending e-mail. A need may exist, however, for an element with functionality not available in the default installation. Additionally, while Unified CVP elements have been designed with configurations that are as flexible as possible, there may be situations where a desired configuration is not supported or difficult to implement.
To satisfy these concerns, a developer can construct custom configurable elements that, once built, can be used and reused. The developer can design the element to possess as large or as small a configuration as desired, depending on how flexible it needs to be. Once deployed, custom elements appear in Builder for Call Studio in the Element Pane and are configured in the same way as Unified CVP Elements.
Due to the level of integration with the Unified CVP software required, only the Java API provides the means for building configurable elements. Using this API, configurable action, decision, and voice elements can be built. Voice elements, due to the fact that they are responsible for producing VoiceXML, use an additional Java API, the Voice Foundation Classes (VFCs). The VFCs are used to abstract the differences between the various voice browsers supported by Unified CVP. The VFCs follow a design that parallels VoiceXML itself and only a developer familiar with VoiceXML and the process whereby a voice browser interprets VoiceXML will be fully suited to utilize the VFCs to build voice elements.
The Programming Guide for Cisco Unified CVP VXML Server and Cisco Unified Call Studio describes the process of building configurable elements including detailing the VFC API for building voice elements.
Standard Action and Decision Elements
Unlike configurable action or decision elements, a standard action or decision element is designed more as a one-off as they satisfy an application-specific purpose. As a result, standard action and decision elements do not require configurations.
There are many situations where programming effort is required to perform some task specific to an application. Since the task is very specialized, pre-existing reusable elements are too general to perform the effort. Additionally, building a configurable element for this purpose would be overkill since there is little chance it would be needed anywhere but in this application. The developer would use a standard action or decision element to perform just this task. If the task is applicable to multiple situations, the developer most likely would put in the extra effort to construct a configurable, reusable element.
Unified CVP provides a means of defining standard decision elements without programming by writing an XML document directly within Builder for Call Studio. This format should be investigated when desiring simple or moderately complex standard decision elements, falling back on the programming API should the built-in format prove insufficient. The XML format that the Builder for Call Studio user interface produces for standard decision elements is described later in this chapter.
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 Builder for Call 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.
To produce dynamic configurations, programming is required. Dynamic element configurations are responsible for taking a base configuration (a partial configuration created in the Builder for Call Studio), adding to it or changing it depending on the application business logic, and returning the desired element configuration to VXML 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 Unified CVP application to another Unified CVP 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.
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.
Hotevents
A hotevent is some developer-defined action performed whenever a VoiceXML event is triggered. Hotevents can take two forms. The first simply moves the caller to a new part of the call flow when the event is triggered. In this case the hotevent can be defined entirely in the Builder for Call Studio by the application designer and does not require any additional work by a developer. The second form of a hotevent executes custom VoiceXML content when the event is triggered (and may optionally also move to another part of the call flow).
The second form requires a Java class that returns the VoiceXML to execute when the event is triggered. This class is accessed once per call, not when the event is triggered. This is because hotevents appear in the VoiceXML root document, which is generated when the application is started or updated. For this reason the API provided to hotevents do not have access to call information normally given to other components. The purpose of a hotevent is solely to produce VoiceXML that will execute when the event is triggered.
A hotevent can be created to react based on a standard VoiceXML event such as nomatch or noinput, but a more common use for a hotevent is to be triggered by a developer-specified or a voice browser-specific event. For example, one can create a hotevent to play audio when a custom event occurs.
As with any other component that produces VoiceXML, the hotevent utilizes the VFCs and therefore can only be constructed with the Java API.
Say it Smart Plugins
In VXML Server, developers can create their own Say It Smart plugins. Similar to custom elements, Say it Smart plugins are pre-built Java classes that when deployed in the Builder for Call Studio can be used as a new Say It Smart type. As with custom elements, the level of integration required with the Unified CVP software restricts the creation of Say It Smart plugins to the Java API.
Custom Say It Smart plugins can be constructed to read back formatted data not handled by Unified CVP Say It Smart plugins, such as spelling playback or reading the name of an airport from its three-digit code. Plugins can also be created to extend the functionality of existing plugins, such as adding new output formats to play the information in another language. For example, a plugin can define a new output format for the Unified CVP Date Say It Smart plugin that reads back dates in Spanish.
Refer to the Programming Guide for Cisco Unified CVP VXML Server and Unified Call Studio for a full description of the process of building custom Say It Smart plugins.
Start and End of Application Actions
Unified CVP provides mechanisms to execute some code when an application is launched or shut down. A start of application action is run when the VXML Server web application archive (WAR) starts up (which occurs when the application server first starts up or the application server reloads the WAR), or the application is updated. An end of application action is run when the application is updated, released, or the web application is shut down (which occurs if the application server reloads or shuts down the web application or the application server itself is shut down).
The purpose of the start of application action is typically to set up global data or application data that would be accessed by components within the callflow. Since global and application data’s lifetime is the lifetime of the application and they can contain Java objects, the start of application action could even set up persistent database connections or other communications to external systems that would remain connected as long as the application were running.
Note
Should an error occur within the start of application class, the application deployment will continue unchanged. The designer can specify that an error in a particular start of application class should stop the application deployment. This would be done if the class performs mandatory tasks that are necessary for the application to run correctly.The purpose of the end of application action would be to clean up any data, database connections, and so on. that would no longer be needed once the application is shut down.
Note
The end of application action is called even when the application is updated because the update may have changed the data that is needed by the application.Every application deployed on VXML Server has the ability to define any number of start and end of application actions that are executed in the order in which they appear in the application settings.
Loggers
The act of logging information about callers to the system is performed by loggers. An application can reference any number of loggers that listen for logging events that occur. These events range from events triggered by a call, such as a caller entering an element or activating a hotlink to administration events such as an application being updated to errors that may have been encountered. Loggers can take the information on these events and do whatever desired with them. Typically the logger will store that information somewhere such as a log file, database or reporting system.
VXML Server includes default loggers that store the information obtained from logging events to parse-able text log files. A need may exist, however, for a logger with functionality not available in the default installation or a logger that takes the same data and stores it using a different mechanism.
To satisfy these concerns, a developer can construct custom loggers that listen for logger events and report them in their own way. The developer can design the logger to use a configuration to customize how the logger functions, depending on how flexible it needs to be. Due to the level of integration with the Unified CVP software required, only the Java API provides the means for building loggers.
Refer to VXML Server Logging in the section entitled Application Loggers for descriptions of the loggers included with VXML Server. Refer to the Programming Guide for Cisco Unified CVP VXML Server and Unified Call Studio for a description of the process of building custom loggers.
For additional information on Unified CVP VXML Server Logs, see Configuring Unified CVP Logging and Event Notification in the Configuration and Administration Guide for Cisco Unified Customer Voice Portal.
On Error notification
When errors occur on the VXML Server, the application-specific error voice element will handle how to handle the caller. If specified, the on error notification Java class can be configured to be activated when an error occurs. The class is given information about the application and some basic call information to allow the developer to specify the action accordingly. The developer can write this class to perform whatever they wish.
The most common purpose for the on error notification class is to perform some custom notification, something to indicate at runtime that an error occurred. This could involve paging an administrator or integrating with a third-party trouble ticket and notification process. Since the notification usually involves an administrator whose responsibility is the entire VXML Server, the Java class, once specified, will apply to any error that prematurely ends a call on any Unified CVP application.
Note
This class is used for notification purposes; it does not allow the call to recover from the error.
Note
There is no XML API equivalent for the on error notification; if done at all, it must be written in Java.Unified CVP XML Decisions in detail
Many commercial applications with decisions driven by business logic utilize an external rules engine to codify the definition of rules. These rules engines help describe the definition of a rule and then manage the process of making decisions based on the criteria at hand. VXML Server bundles a rule engine in the standard installation and provides an XML data format for defining decision elements within the framework of a voice application. The XML format is simple enough for an application designer to enter within Builder for Call Studio without requiring separate programming resources.
A detailed description of the structure of the XML format is warranted. The centerpiece of a rule is one or more expressions. An expression is a statement that evaluates to a true or false. In most cases, there are two parts (called terms) to an expression with an operator in between. The terms are defined by VXML Server to represent all of the most common items one would want to base decisions on in a voice application such as telephony data, element or session data, times and dates, caller activity, user information, and so on. The operators depend on the data being compared. For example, numbers can be compared for equality or greater than or less than while strings can be compared for equality or if it contains something. One kind of expression breaks this format: an exists expression which itself evaluates to a true or false and does not need anything to compare it to.
Examples:
Each of these conditions checks for the existence of something which is itself a complete expression.
One or more of these expressions are combined to yield one exit state of the decision element. Multiple expressions can be combined using ands or ors, though not a combination. For example: if the ANI begins with 212 OR if the ANI begins with 646 then return the exit state ‘Manhattan’.
If a combination of ands and ors is desired, multiple expressions that return the same exit state would be used. For example, if the ANI begins with 212 and the user is a gold or platinum customer, then return the exit state ‘discount’ would not work as a single rule because the discount would be given to callers with a 212 area code who are gold customers and all platinum customers (there is no way to set precedence).
This would have to be expressed as two rules with the same exit state:
- if the ANI begins with 212 AND the user is a gold customer, return the exit state discount
- if the ANI begins with 212 AND the user is a platinum customer, return the exit state discount
It is possible to define an exit state that returns when all other exit states fail to apply, called the default exit state. When not specified, all possible cases must be caught by the defined rules. For example, if a rule checks if a number is greater than 5, there should be another rule checking if the number is less than or equal to 5, unless the default exit state is defined. One can even create a set of rules that start from being restrictive, looking for only very specific matches, to progressively looser since the first rule to be true will yield an exit state and no more rules are tested.
The knowledge_base example in the preceding figure shows the main tags of the XML file format for defining a decision. The elements in this XML document are:
- rule - This tag names the rule for the decision. There can only be one <rule> tag in the document. The tag contains any number of exit states that make up the decision. The optional default_exit_state attribute lists the exit state to return if no other exit states apply (essentially an else exit state).
- exit_state - This tag encapsulates the expressions that when true, return a particular exit state. The name attribute must refer to the same value chosen when the decision element was defined in the Builder for Call Studio. The conjugate attribute can be either and or or. If the exit state contains only one expression the conjugate attribute is ignored. The content of the <exit_state> tag is the type of data to be compared, each type containing different kinds of data. There can be any number of children to the <exit_state> tag, each representing another expression linked with the conjugate.
- string - This tag represents an expression comparing strings. The operator attribute can be: contains, not_contains, ends_with, not_ends_with, equal, not_equal, starts_with, and not_starts_with. There can be only two children to the <string> tag, representing the two terms of the expression. If there are less than two, an error will occur. If more, the extra ones will be ignored. The content can be tags representing a constant string entered by the developer, data about the call, session and element data, user information, date and time information, the activity of the caller, and historical activity of the user. These tags are fully defined in the following sections.
- number - This tag represents an expression comparing numbers. The operator attribute can be: equal, not_equal, greater, greater_equal, less, and less_equal. There can be only two children to the <number> tag, representing the two terms of the expression. If there are less than two, an error will occur. If more, the extra ones will be ignored. The content can be tags representing a constant number entered by the developer, data about the call, session and element data, user information, date and time information, the activity of the caller, and historical activity of the user. These tags are fully defined in the following sections.
- boolean - This tag represents an expression which evaluates to a boolean result, requiring only a single term. If the check_existence attribute is yes, and the value attribute is true, it is checking if the data defined by the child tag exists. If check_existence is yes, and value is false, it is checking if the data defined by the child tag does not exist. If check_existence is no, the value attribute is used to compare the data defined by the child tag with either true or false. True means the expression is true if the data defined by the child tag evaluates to true. The child tags are a smaller subset of those allowed in <string> and <number>: data about the call, session and element data, user information, or the activity of the caller (each of these is fully defined in the following sections). When testing if the child tag’s value is true or false, it must be able to evaluate to a Boolean value. If it cannot, the decision will act as if the rule did not activate.
- constant_string / constant_number - These tags store string and number data in the value attribute. The number can be any integer or floating-point number.
Note
The number can also be treated as a string. For example, if 1234 starts with 12.The following sections explain the contents of the individual tags found within the <string>, <number> and <boolean> tags.
- <call_data>
- <data>
- <user_info>
- <general_date_time>
- <caller_activity>
- <historical_data>
- XML Decision Example #1
- XML Decision Example #2
- XML Decision Example #3
<call_data>
The call_data Tag figure shows the term that represents information about the current call. The type attribute can be ani, dnis, uui, iidigits, source, appname, duration, language, or encoding. The ANI, DNIS, UUI, and IIDIGITS will be NA if it is not sent by the telephony provider. Source is the name of the application that transferred to this application or null if this application was the first to be called. Duration is the duration of the call up to this point in seconds.
<data>
The <data> Tag figure shows the term that represents session or element data. The <session> tag refers to session data with its name in the name attribute. The <element> tag refers to element data with the name of the element in the name attribute and the name of the variable in the variable attribute.
<user_info>
The <user_info Tag figure shows the term that represents user information.
Note
If the application has not been configured to use the user management system, and the call was not associated with a specific UID, using this term will cause an error.Only one piece of user information can be returned per tag. Refer to User Management for more details about the user management system.
The possible user information to be compared is:
- demographic - This tag refers to the user’s demographic information. The type attribute can be name, zipcode, birthday, gender, ssn, country, language, custom1, custom2, custom3, or custom4.
- ani_info - This tag refers to the various phone numbers associated with the user account. If the type attribute is first, the first number in the list of numbers is returned. This would be returned if there was only one number associated with an account. If the attribute is num_diff the total number of different phone numbers associated with the account is returned.
- user_date_time - This tag refers to date information related to the user account. The type attribute indicates which user-related date to access and the field attribute is used to choose which part of the date to return. Type can be last_modified (indicating the last time the account was modified), creation (indicating the time the account was created), and last_call (indicating the last time the user called). Field can be hour_of_day (which returns an integer from 0 to 23), minute (which returns an integer from 0 to 59), day_of_month (which returns an integer from 1 to 31), month (which returns an integer from 1 to 12), day_of_week (which returns an integer from 1 to 7 where 1 is Sunday), or year (which returns the 4 digit year).
- called_from_ani - This tag returns true if the caller has previously called from the current phone number, false if not.
- account_info - This tag refers to the user’s account information. The type attribute can be pin, account_number, or external_uid.
<general_date_time>
The <general_date_time> Tag figure shows the term that represents general date information. The type attribute indicates which date to access and the field attribute is used to choose which part of the date to return. Type can be current (indicating the current date/time) or call_start (indicating the time the call began). Field can be hour_of_day (which returns an integer from 0 to 23), minute (which returns an integer from 0 to 59), day_of_month (which returns an integer from 1 to 31), month (which returns an integer from 1 to 12), day_of_week (which returns an integer from 1 to 7 where 1 is Sunday), or year (which returns the 4 digit year).
<caller_activity>
The <caller_activity> Tag figure shows the term that represents the activity of the caller in the current call. The <nth_element> tag returns the nth element visited by the caller where the attribute n is the number (starting at 1). The <nth_exit_state> tag returns the exit state of the nth element visited by the caller where the attribute n is the number (starting at 1). The <times_elemvis> tag returns the number of times the caller visited the element whose name is given in the element attribute. The <times_elemvis_exit> tag returns the number of times the caller visited the element whose name is given in the attribute element which returned an exit state whose name is given in the exit_state attribute.
<historical_data>
The <historical_data> Tag figure shows the term that represents the historical activity of the user associated with the call on the current application.
Note
If the application has not been configured with a user management database, using this term will cause an error. Refer to User Management for more details about the user management system.The type attribute determines what kind of value is returned. A value of num means that the value returned is the number of calls matching the criteria defined by the children tags. A value of last_date_time means that the value returned is the last date/time a call was received matching the criteria defined by the children tags. A value of first_date_time returns the first date/time a call was received that matched the criteria.
The field attribute is used if the type attribute is first_date_time or last_date_time and indicates which part of the date to compare. Field can be hour_of_day (which returns an integer from 0 to 23), minute (which returns an integer from 0 to 59), day_of_month (which returns an integer from 1 to 31), month (which returns an integer from 1 to 12), day_of_week (which returns an integer from 1 to 7 where 1 is Sunday), or year (which returns the 4 digit year). The children tags are used to turn on various criteria to add to the search.
The different search criteria are:
- caller - If this tag appears, the search looks for calls made by the current caller only. If it does not appear, it will search all calls made by all callers.
Note
If the call was not associated with a specific UID, an error will occur if this tag is used.- ani - If this tag appears, the search looks for calls made by the ANI specified in the value attribute. If the value attribute is not included, the ANI of the current caller is used.
- start - If this tag appears, the search looks for calls whose start date/time are between two times specified by successive <constant_date_time> children tags. The attributes of <constant_date_time> define the specific date to use. The month attribute must be an integer from 1 to 12. The day_of_month attribute must be an integer from 1 to 31. The year attribute must be a four digit integer. The hour_of_day attribute must be an integer from 0 to 23. The minute attribute must be an integer from 0 to 59. The second attribute must be an integer from 0 to 59.
- end - If this tag appears, the search looks for calls whose end date/time are between two times specified by successive <constant_date_time> children tags. See <start> (the previous bullet) for the description of the <constant_date_time> tag.
- flag - If this tag appears, the search looks for calls where a flag with the name given in the name attribute was triggered.
XML Decision Example #1
An application named Example1 would like to play Welcome back for callers who have previously called this application. The users are identified by their ANI (this application uses the user management database only for its history tracking). A decision element named CalledBefore would be needed which had two rules, one for those who the application recognizes and one for the rest (this is being done rather than using the default exit state for demonstration purposes).
In English, the rules are:
Rule Number
Expression
Exit State
1
The caller has called from this ANI before.
say_welcome_back
2
The caller has not called from this ANI before.
say_welcome
The Unified CVP decision element XML file would be named CalledBefore and be saved in %CVP_HOME%\VXMLServer\applications\Example1\data\misc.
The XML content will be:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE knowledge_base SYSTEM "../../../../dtds/DecisionKnowledgeBase.dtd"> <knowledge_base> <rule name="CalledFromAni"> <exit_state name="say_welcome_back" conjugate="and"> <boolean check_existence="no" value="true"> <user_info> <called_from_ani/> </user_info> </boolean> </exit_state> <exit_state name="say_welcome" conjugate="and"> <boolean check_existence="no" value="false"> <user_info> <called_from_ani/> </user_info> </boolean> </exit_state> </rule> </knowledge_base>XML Decision Example #2
An application named Example2 randomly chooses two letters of the alphabet and gives a prize to the caller whose name begins with either letter. The letters are chosen by an action element named GetRandomLetter and stored in element data named letter1 and letter2.
A decision element named IsCallerAWinner would be needed which has three exit states:
- For a user whose name begins with either letter.
- For users whose name does not begin with the letters.
- For users whose name is not in the records (this could be an error or could prompt the application to ask the user to register on the website).
Even if the application assumes that all users will have their names on file, it is prudent to add this third exit state just to make sure. In this example, the default exit state will be set to when the users do not match.
In English, the rules are:
Rule Number
Expression
Exit State
1
The caller’s name begins with the value stored in the element GetRandomLetter with the variable name letter1 or begins with the value stored in the element GetRandomLetter with the variable name letter2.
is a winner
2
The caller’s name does not begin with the value stored in the element GetRandomLetter with the variable name letter1 and does not begin with the value stored in the element GetRandomLetter with the variable name letter2.
not a winner
3
The caller’s name does not exist.
no name
The Unified CVP decision element XML file would be named IsCallerAWinner and be saved in %CVP_HOME%\VXMLServer\applications\Example2\data\misc.
The XML file content will be:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE knowledge_base SYSTEM "../../../../dtds/DecisionKnowledgeBase.dtd"> <knowledge_base> <rule name="NameStartsWith" default_exit_state="not a winner"> <exit_state name="no name" conjugate="and"> <boolean value="false" check_existence="yes"> <user_info> <demographic type="name"/> </user_info> </boolean> </exit_state> <exit_state name="is a winner" conjugate="or"> <string operator="starts_with"> <user_info> <demographic type="name"/> </user_info> <data> <element name="GetRandomLetter" variable="letter1"/> </data> </string> <string operator="starts_with"> <user_info> <demographic type="name"/> </user_info> <data> <element name="GetRandomLetter" variable="letter2"/> </data> </string> </exit_state> </rule> </knowledge_base>
Note
The no name exit state is listed first. This is because before we try to analyze the user’s name, we have to first know that it exists. So we check if the name does not exist first and if it fails it means the name exists and we can go on.
Note
The second exit state must check if the name begins with the first or second letter but the last exit state must check if the name does not begin with the first and second letter.XML Decision Example #3
An application named Example3 is designed to trigger a flag named account menu when a caller chooses to manage their account. As of June 15, 2004, the menu options were changed for the account menu. We want to tell people the options have changed, but only if we know they’ve visited that part of the application before June 15. If not, there is no reason to say anything because the caller is experiencing this for the first time. A decision element is needed that distinguishes between those to play the changed audio to from those who should encounter the menu normally. A tricky part of the rule is that it must deal with the day, month, and the year, making sure that callers from previous years and future years are handled correctly as well. Since the current state of the XML format does not allow date comparisons, a way must be determined to make this restriction. The solution is to use multiple rules which progressively get more restrictive in a sort of process-of-elimination manner. Since all conditions are to be handled, the rule must include those who do not hear the changed message using the same scheme (there is no need to use the default exit state).
In English, the rules are:
Rule Number
Expression
Exit State
1
The year the last time the caller triggered the flag account menu is less than 2004.
play changed
2
The year the last time the caller triggered the flag account menu is greater than 2004.
normal
Note At this time, if the above two rules were not triggered, the caller triggered the flag in the year 2004. 3
The month of the year the last time the caller triggered the flag account menu is less than 6.
play changed
4
The month of the year the last time the caller triggered the flag account menu is greater than 6
normal
Note At this time, if the above two rules were not triggered, the caller triggered the flag in June 2002. 5
The day of the month the last time the caller triggered the flag account menu is less than or equal to 15.
play changed
6
The day of the month the last time the caller triggered the flag account menu is greater than 15.
normal
The Unified CVP decision element XML file would be named DoesCallerNeedMenuChanges and be saved in %CVP_HOME%\VXMLServer\applications\Example3\data\misc.
The content of the XML file will be:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE knowledge_base SYSTEM "../../../../dtds/DecisionKnowledgeBase.dtd"> <knowledge_base> <rule name="NewMessageTest"> <exit_state name="play changed" conjugate="and"> <number operator="less"> <historical_data type="last_date_time" field="year"> <caller/> <flag name="account menu"/> </historical_data> <constant_number value="2004"/> </number> </exit_state> <exit_state name="normal" conjugate="and"> <number operator="greater "> <historical_data type="last_date_time" field="year"> <caller/> <flag name="account menu"/> </historical_data> <constant_number value="2002"/> </number> </exit_state> <exit_state name="play changed" conjugate="and"> <number operator="less"> <historical_data type="last_date_time" field="month"> <caller/> <flag name="account menu"/> </historical_data> <constant_number value="6"/> </number> </exit_state> <exit_state name="normal" conjugate="and"> <number operator="greater"> <historical_data type="last_date_time" field="month"> <caller/> <flag name="account menu"/> </historical_data> <constant_number value="6"/> </number> </exit_state> <exit_state name="play changed" conjugate="and"> <number operator="less_equal"> <historical_data type="last_date_time" field="day_of_month"> <caller/> <flag name="account menu"/> </historical_data> <constant_number value="15"/> </number> </exit_state> <exit_state name="normal" conjugate="and"> <number operator="greater"> <historical_data type="last_date_time" field="month"> <caller/> <flag name="account menu"/> </historical_data> <constant_number value="6"/> </number> </exit_state> </rule> </knowledge_base>VoiceXML insert elements
VoiceXML insert elements are different from other elements in that they are built almost entirely outside VXML Server using VoiceXML directly. One can think of an insert element as a way to insert custom VoiceXML content into a Unified CVP voice application without sacrificing the ability to interface with other elements in the call flow. While there are guidelines to follow to make these elements work, there are few restrictions on the VoiceXML content itself.
There are two common reasons an insert element is used, the first being the ability to leverage VoiceXML content that has already been created and integrate it into a Unified CVP application without having to do much recoding. The second reason is in situations where the requirement is to write a VoiceXML-producing element that is a one-off without having to go through the effort of writing a configurable voice element in Java and the VFCs. This is very similar to the reasons for writing standard action and decision elements instead of producing a configurable element. Writing VoiceXML is simpler than creating a voice element from scratch since that requires knowledge of both VoiceXML as well as the Unified CVP Java API.
One of the disadvantages of using insert elements is the fact that since the VoiceXML must be written to comply with a specific voice browser, the browser-agnostic capability of the voice application is lost. If the application is moved to another voice browser, all Unified CVP elements would automatically work, but the insert elements would have to be retested and tweaked to conform to the new browser’s requirements. Another disadvantage is the insert element’s lack of a configuration. If the desire is a reusable, configurable element, it is preferable to construct a voice element.
VoiceXML insert elements are accessed via a VoiceXML <subdialog>. The VoiceXML specification provides this tag as a way of allowing simple reusable functionality. It acts very much like a function in programming where inputs are sent to a function that performs some actions and returns the results. The subdialog definition itself can be located anywhere accessible with a URI. In this way, the Unified CVP application sees an insert element as simply another function to access.
The inputs and outputs are the means by which the insert element interfaces with the rest of the system. Most of the important data available to Unified CVP elements are sent as input to each Insert element. Once the insert element is complete, the return information contains any element or session data to create, log entries, the exit state of the insert element, and other data to act upon.
- Insert Element Restrictions
- Insert Element Inputs
- Insert Element Outputs
- Root document
- Example of insert elements
Insert Element Restrictions
The following restrictions apply to a VoiceXML insert element. An insert element conforming to these restrictions will be assured full integration with the Unified CVP application. These restrictions will be clarified later.
- The insert element cannot define its own root document, a root document generated by VXML Server must be used.
- The variables to return to VXML Server, including the exit state, must conform to a strict naming convention.
- When using the <return> tag, Unified CVP-specified arguments must be returned along with the custom variables.
Note
Use a VoiceXML insert element only in a top-level subdialog. You cannot use a VoiceXML Insert element in a nested subdialog.Insert Element Inputs
As with any element in the application, an insert element would need to be able to access information about the call such as element and session data, call data (such as the ANI), and even information found in the user management database if the application is configured to use one. Normally, this information is available in the Java or XML API. Since an insert element is written in VoiceXML, this information must be made available for the insert element to use from within the VoiceXML.
Unified CVP achieves this by creating VoiceXML variables in the root document containing all the desired information. The variable names conform to a naming convention so the Insert element developer can refer to them appropriately. This is one reason why Unified CVP requires the use of the VXML Server-generated root document.
In order to cut down on the number of variables appearing in the root document, the application designer is given the option of choosing which input groups are passed to the insert element. Additionally, the designer can individually choose which element and session data to pass. By minimizing the inputs to only the data required by the insert element, the overhead involved in using an Insert element is minimized.
Each input type is listed below:
- Telephony - This information deals with telephony data. The inputs start with audium_telephony_.
- audium_telephony_ani - The phone number of the caller or NA if not sent.
- audium_telephony_dnis - The DNIS or NA if not sent.
- audium_telephony_iidigits - The IIDIGITS or NA if not sent.
- audium_telephony_uui - The UUI or NA if not sent.
- audium_telephony_area_code - The area code of the caller’s phone number. Will not appear if the ANI is NA.
- audium_telephony_exchange - The exchange. Will not appear if the ANI is NA.
- Call - This information deals with the call. The inputs start with audium_call_.
- audium_call_session_id - The session ID.
- audium_call_source - The name of the application which transferred to this one. Will not appear if this application is the first application in the call.
- audium_call_start - The start time of the call in the format "DAY MNAME MONTH HH:MM:SS ZONE YEAR" where DAY is the abbreviated day of the week (for example, Wed), MNAME is the abbreviated name of the month (for example, Jun), HH is the hour (in military time), MM is the minute, SS is the seconds, ZONE is the time zone (for example, EDT), and YEAR is the four-digit year.
- audium_call_application - The name of the current application.
- History - This information deals with the history of elements visited so far in the call. The inputs start with audium_history_.
- audium_history - This entire content of the element history (including exit states) is contained in this variable. The format is [ELEMENT]:[EXITSTATE]|..|[ ELEMENT]:[EXITSTATE] where ELEMENT is the name of the element and EXITSTATE is the name of the exit state of this element. The order of the element/exit state pairs is consistent with the order in which they were visited. This will not appear if this insert element is the first element in the call.
- Data - This is the element and session data created so far in the call.
- audium_[ELEMENT]_[VARNAME] - This is an element variable where ELEMENT is the name of the element and VARNAME is the name of the variable.
Note
Both the element and variable names will have all spaces replaced with underscores. There may be no instances of this input if no element variables exist when this insert element is visited. For example, the variable audium_MyElement_the_value is element data named the value from the element MyElement.- audium_session_[VARNAME] - This is a session variable whose name is VARNAME.
Note
The variable name will have all spaces replaced with underscores. The value is expressed as a string even if the type is not a string (the toString() method of the Java class is called). There may be no instances of this input if no session variables exist when this insert element is visited.- User Data - This element information associated with the caller. It will only appear if the application has associated the call with a UID and a user management database has been set up for this application. The data will appear in the input exactly as in the database. The inputs start with user_.
- user_uid - This is the UID of the user.
- user_account_number - The account number of the user.
- user_account_pin - The PIN of the user.
- user_demographics_name - The name of the user.
- user_demographics_birthday - The birthday of the user.
- user_demographics_zip_code - The zip code of the user.
- user_demographics_gender - The gender of the user.
- user_demographics_social_security - The social security number of the user.
- user_demographics_country - The country of the user.
- user_demographics_language - The language of the user.
- user_demographics_custom1 - The value of the first custom column.
- user_demographics_custom2 - The value of the second custom column.
- user_demographics_custom3 - The value of the third custom column.
- user_demographics_custom4 - The value of the fourth custom column.
- user_account_external_uid - The external UID of the user.
- user_account_created - The date the account was created in the format. The value is in the format "DAY MNAME MONTH HH:MM:SS ZONE YEAR".
- user_account_modified - The date the last time the account was modified. The value is in the format "DAY MNAME MONTH HH:MM:SS ZONE YEAR".
- User By ANI - This provides historical information about the phone number of the caller with regards to this application. It will only appear if a user management database has been set up for this application. The inputs start with user_by_ani_.
Insert Element Outputs
Just like any element, VoiceXML insert elements can create element and session data, set the UID of the user to associate with the call, send custom logging events, and can return one of a set of exit states. Like voice elements, insert elements can have internal logging of caller activity and have global hotlinks and hotevents activated while the caller is visiting the Insert element. All of these actions involve variable data set within the Insert element and returned to VXML Server. These are crucial in order to properly integrate with the rest of the elements in the application.
Each of the return arguments is listed below:
- audium_exit_state - The exit state of this VoiceXML insert element. The value of this variable must be exactly as chosen in the Builder for Call Studio when defining the insert element.
- element_log_[VARNAME] / element_nolog_[VARNAME] - These create new element data for this VoiceXML insert element whose name is VARNAME and which either sends a logging event to log the element data value or not, respectively. The data type will be assumed to be a string. The variable name cannot include spaces.
- session_[VARNAME] - This creates a new session variable whose name is VARNAME. The data type is assumed to be a string. The variable name cannot include spaces. If the variable name already exists, the old value will be replaced with this one. If the old data type was not a string, the new data type will be a string.
- custom_[NAME] - This sends a custom logging event whose contents is the action named NAME and the value of the variable being the description.
- set_uid - This associates the UID passed to the call.
- audium_hotlink, audium_hotevent, audium_error, audium_action - These four Unified CVP variables are created in the root document and must be passed along in the return namelist. The content of each deals with the occurrence of any global hotlinks, hotevents, errors, or actions (for example, a hang-up) while in this insert element. Since the subdialog has its own context and root document, this data has to be explicitly passed for any of these events to be recognized by VXML Server. The developer should not alter the contents of these variables.
- audium_vxmlLog - This variable contains the raw content for an interaction logging event. Adding to the interaction log is not required - the audium_vxmlLog variable can be passed empty. In order for VXML Server to parse the interaction data correctly, a special format is required for the content of the audium_vxmlLog variable. This format is defined below. The format for interaction logging is:
|||ACTION$$$VALUE^^^ELAPSEDWhere: ACTION is the name of the action. The following bullets list the possible action names and the corresponding contents of VALUE:
- audio_group - This is used to indicate that the caller heard an audio group play. VALUE is the name of the audio group.
- inputmode - This is used to report how the caller entered their data, whether by voice or by DTMF key presses. VALUE should be contents of the inputmode VoiceXML shadow variable.
- utterance - This is used to report the utterance as recorded by the speech recognition engine. VALUE should be the contents of the utterance VoiceXML shadow variable.
- interpretation - This is used to report the interpretation as recorded by the speech recognition engine. VALUE should be the contents of the interpretation VoiceXML shadow variable.
- confidence - This is used to report the confidence as recorded by the speech recognition engine. VALUE should be the contents of the confidence VoiceXML shadow variable.
- nomatch - This is used to indicate the caller entered the wrong information, incurring a nomatch event. VALUE should be the count of the nomatch event.
- noinput - This is used to indicate the caller entered nothing, incurring a noinput event. VALUE should be the count of the noinput event.
- ELAPSED is the number of milliseconds since the VoiceXML page was entered. The root document provides a JavaScript function named application.getElapsedTime(START_TIME) which returns the number of milliseconds elapsed since the time specified in START_TIME.
The root document created by VXML Server for use in all VoiceXML insert elements contains a VoiceXML variable named audium_element_start_time_millisecs that must be initialized with the time in order for the elapsed time intervals to be calculated correctly. This variable need only be initialized once in the first VoiceXML page of the insert element. All subsequent pages in the VoiceXML insert element must not initialize the variable because VXML Server requires the elapsed time from the start of the element, not the page. So, in VoiceXML, the line to appear must look like:
<assign name="audium_element_start_time_millisecs" expr="new Date().getTime()" />For best results, this should appear as early as possible in the first page, preferably in a <block> in the first <form> of the page, certainly before any additional logging is done.
In VoiceXML, setting the value of an existing variable requires the <assign> tag. Since the expression contains a JavaScript function, the expr attribute must be used. Additionally, in order to avoid overwriting previous log information, the expression must append the new data to the existing content of the variable. For example, to add to the interaction log the fact that the xyz audio group was played, the VoiceXML line would look like:
<assign name="audium_vxmlLog" expr="audium_vxmlLog + '|||audio_group$$$xyz^^^' +application.getElapsedTime(audium_element_start_time_millisecs)"/>In another example, the utterance of a field named xyz is to be appended to the log. The VoiceXML would look like:
<assign name="audium_vxmlLog" expr="audium_vxmlLog +'|||utterance$$$'+ xyz.$utterance + '^^^' + application.getElapsedTime(audium_element_start_time_millisecs)"/>See VXML Server Logging for more detail about Unified CVP logging.
Root document
The subdialog context written by the developer must refer to a Unified CVP-generated root document. This is essential for proper integration of the VoiceXML insert element with VXML Server. The root document call must look like:
"/CVP/Server?audium_vxml_root=true&calling_into=APP& namelist=element_log_value|RTRN1|RTRN2|…"Where APP is the application name and RTRNX represent the names of all the element data, session data, and custom log entries (delimited by ‘|’ characters) the insert element returns, using the same naming convention described in the outputs section above.
The purpose for this requirement is related to how events are handled within the root document. The Unified CVP-generated root document catches events such as the activation of a global hotlink or a hangup, which then requires the call flow to leave the insert element. The insert element, however, may have created element and session data or added custom content to the log. This information is stored in VoiceXML variables that would be deleted once the subdialog context is exited. So the root document needs to be told which VoiceXML variables to send along to VXML Server when one of these events is triggered so that it can store them accordingly. In order to avoid problems that might occur if a global hotlink or hotevent was activated right after the insert element began the variables to be returned should be declared as near the start of the VoiceXML insert element as possible, even if they are not assigned initial values.
Note
The ability to use a standard ampersand in the root document URL instead of escaping it (as "&") is voice browser dependent. Most browsers will accept the escaped version so try that first.
Note
If the insert element does not need to send back any data in the namelist parameter, only the element_log_value variable need be included (the parameter should look like this: "...namelist=element_log_value").Example of insert elements
In the example below, a block is used to log the playing of the initial_prompt audio group. After this action, some inputs passed to it from VXML Server are played. Once this is done, it creates two element variables named var1 and var2 and a session variable named sessvar. After this, it goes through a field that catches a number and when done saves the utterance to the activity log and returns the exit state less if the number is less than 5 and greater_equal otherwise. The <return> tag returns the exit state, log variable, the four variables from the root document (error, hotlink, hotevent, and action), the two element data variables, the session data variable and a custom log entry (the number captured).
Also note that these last four variables are also passed to the root document call in the <vxml> tag so that events triggered within the insert element will correctly pass the data if it was captured by then.
Note
The VoiceXML listed below may not function on all browsers without modification.<?xml version="1.0"?> <vxml version="1.0" application="/CVP/Server?audium_vxmlroot=true&calling_into=MYAPP& namelist=element_log_var1|element_nolog_var2|session_sessvar|custom_custlog"> <form id="testform"> <block>This is the initial prompt <assign name="audium_element_start_time_millisecs" expr="new Date().getTime()"/> <assign name="audium_vxmlLog" expr="'|||audio_group$$$initial_prompt^^^' +application.getElapsedTime(audium_element_start_time_millisecs)"/> </block> <block>In the VoiceXML element. The ani is <value expr="audium_telephony_ani"/>. The element history is <value expr="audium_history"/>. User by ani num calls is <value expr="user_by_ani_num_calls"/>. Element data foo from element first <value expr="audium_first_foo"/>. Session variable foo2 <value expr="audium_session_foo2"/>. </block> <var name="element_log_var1" expr="'log me'"/> <var name="element_nolog_var2" expr="'do not log me'"/> <var name="session_sessvar" expr="'session_data_value'"/> <field name="custom_custlog" type="number"> <property name="inputmodes" value="voice" /> <prompt>Say a number.</prompt> <filled> <assign name="audium_vxmlLog" expr="audium_vxmlLog + '|||utterance$$$' + custom_custlog.$utterance + '^^^' +application.getElapsedTime(audium_element_start_time_millisecs)"/> <if cond=" custom_custlog < 5"> <assign name="audium_exit_state" expr="'less'"/> <else/> <assign name="audium_exit_state" expr="'greater_equal'"/> </if> <return namelist="audium_exit_state audium_vxmlLog audium_error audium_hotlink audium_hotevent audium_action element_log_var1 element_nolog_var2 session_sessvar custom_custlog" /> </filled> </field> </form> </vxml>
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)