Appendix C: CallXML Variables

If we are using CallXML, we will need to be aware of the variables available, the syntax necessary to access them, and how we can use them to our best advantage. This section will clue you in to the subtleties and nuances of using variables in the CallXML markup.

Session Variables

CallXML browsers include a per "call" or "session" variable space. The CallXML logic elements are used to assign and clear values in those variables, and to submit those variables as HTTP GET or POST information to traditional web applications created with languages such as ColdFusion, Perl, Java, and ASP.

No instantiation of these variables needs to be made at all, as they are implicity declared by the gateway server whenever a call is placed to the destination CallXML application. These session variables are listed below:

Variable	Description
application.errorURL	where to go if the application terminated due to an unhandled event. There is a default URL provided by the system; setting it empty deactivates this feature
session.accountID	Voxeo ID of the called party (if known)
session.applicationID	the Voxeo applicationID number
session.callerID	the caller's phone number
session.calledID	the number that was called to get here
session.eventsenderID	the session ID of the sender of the last external event
session.eventvalue	the event value sent to the invoking (parent) document when a `<run>` (child) session ends
session.ID	identifier for the current session
session.lastchoice	contains the return value used for the last user utterance. For example, where "color (red, white, blue)", then "color" is returned.
session.lastconfidence	contains the match confidence value from the last user input that successfully matched in the application
session.lasterror	printable information about the last error that happened
session.lasteventID	contains the last event/action's 'id' value, which can then be compared with an element's 'id' attribute to perform application logic
session.lastphrase	contains the user's last utterance. For example, where "color (red, white, blue)", then "white" could be returned.
session.lasttermdigit	contains information that remembers the last termdigit the caller pressed
session.privatecallerID	contains a boolean value which indicates whether or not 'callblocking' is enabled for the number. Note that this value may not always be populated, depending on the exchange.
session.redirectedcalledID	displays the original callerID value, if the number dialed has an active redirect enabled
session.SIPCallID	displays a unique ID that can be used to track a SIP-based call
session.subaccountID	party-specific information
settings.choices.sensitivity	Adjusts how sensitive the interpreter is to loud versus quiet input. Adjusting upwards will make the interpreter more sensitive to quiet input. This property can be useful if your end user will be accessing the application in a very noisy environment, although it is advised that you use this setting very carefully, as it may have a detrimental effect on recognition accuracy. Allowed values are 0 to 100 with a default of 50.
settings.choices.inputmodes	Restricts the input mode to either voice or DTMF. Allowed values are "voice" or "dtmf".
settings.choices.minconfidence	Allows adjusting how accurate a user's utterance needs to be to get a valid grammar match. Allowed values are 0 to 100 with a default of 35. 0 will match all input, 100 will cause nomatch on all input.

Variable Naming Syntax

Variable names must start with a letter (A through Z or a through z) and can contain: A through Z, a through z, 0 through 9, and the underscore. Variable names can be 1 to 40 characters in length and are not case sensitive. Variable names beginning with the characters "session." in any case combination are reserved for internal system variables and cannot be created or set by the programmer. They are excluded from submission in a <goto> or a <run>. The same is for variables of the "application." type.

Thus, the following variable declarations would be considered incorrect:



<assign var="1_var" value="'frankenberry'"/>

<assign var="_1var" value="'chocula'"/>

<assign var="session.1_var" value="'booberry'"/>

Whereas the following listing would be considered 'legal':



<assign var="var1" value="'frankenberry'"/>

<assign var="Var_1" value="'chocula'"/>

<assign var="var1_session" value="'booberry'"/>

Variable Referencing

Any and all CallXML variables can be referenced within CallXML element attributes by using the $varname; syntax. To represent a single $ character it has to be encoded as $$. To illustrate further for the cubistic among us, an example of variable referencing is shown below:



...

  <do>

    <assign var="MyVar" value="'Mister Rogers'"/>



    <say> Welcome to $MyVar; neighborood</say>

  </do>

...

Time String Format

The time format standard used in CallXML is described here. Time format strings are used for maxtime and maxsilence attributes, and in the <wait> tag.

The time string format is:



<numeric value>[<optional qualifier>] | nolimit

The string begins with a required numeric value.

The valid qualifiers are:

h: hours
m: minutes
s: seconds (default)
ms: milliseconds

Example: "2h 45m 33s 117ms"

Note that if no qualifier is specified, an "s" qualifier is assumed. No combinations of qualifiers are allowed. If there is a need to specify an unlimited amount of time, simply use the key word "nolimit".

ANNOTATIONS: EXISTING POSTS

0 posts - click the button below to add a note to this page

Transfer & Call Variables

| TOC

| D: Best Practices