CCXML 1.0 Session and Application Variables

Session Variables

The CCXML 1.0 platform has a number of system-defined variables that are created upon application execution which persist throughout the duration of the call session. These variable values are read-only, and may not be modified at the application scope, (however, it is entirely possible to declare a user variable that contains the value of the session variable, and then modify the value, of course). Neither can the application developer create and declare new session variables, (or any variables that contain a 'session.' prefix). Session variables are dependent upon the context of the state that they are in: for instance, if there is no conference in the current session, then we should not expect the "session.conferences" variable to have a value of anything other than 'undefined'. Of course, this also implies that certain session variable values will change upon each change of state in the application. The below listing defines the available session variables, and what values one can expect to see when referencing them:

session.startupmode: This session variable allows the developer to log the mode that the CCXML 1.0 script started as. The possible values are:
* newcall - Indicates that the session was started via a new inbound call
* external - Indicates that the session was started via an external launch request, (ie, via an http token request).
* createccxml - Indicates that the session was started via the invocation of a <createcall>

session.id: This session variable contains the unique alphanumeric identifier that is associated with any CCXML 1.0 session. Developers are strongly encouraged to both log, and store this data in any production deployments, as it allows the developer to easily locate the details of any given call session by searching in the persistent voxeo logs.

session.uri: Contains the value of the URI that was used during the creation of the current CCXML 1.0 session, including any querystring parameters that might be in the request. If multiple document fetches were performed when creating the session, (as could occur when redirects are involved), then the value defined will be the URI of the final target document.

session.parentid: This session variable contains a string value that equates to the parent CCXML 1.0 session that created the current session, (if applicable).

session.connections: This session variable contains an Associative Array which lists all Connection Objects that the current session has active. Each key in this Array evaluates to the connection identifier of the Connection itself.

session.conferences: This session variable contains an Associative Array which lists all Conference Objects that the current session has active. Each key in this Array evaluates to the Conference identifier of the Connection itself.

session.dialogs: This session variable contains an Associative Array which lists all Dialog Objects that the current session has active. Each key in this Array evaluates to the Dialog identifier of the Connection itself.

session.ioprocessors: Contains an Associative Array which lists any external event I/O access URI's that are available to the current session, with each key in the array being the type of the event I/O processor.

session.values: This session variable is an Associative Array containing a list of session parameters that are passed upon the creation of the session.

Application Variables

The CCXML 1.0 platform also allows developers to define application scoped variables which, similar to Session Variables, will persist throughout the entire session. Unlike Session Variables, Application-scoped variables are entirely under developer control, and may be created, and modified at any point in the application execution. Be aware that Application variables that are properties of the application object do not need to be explicitly declared, but any Application variables that are not properties, (ie, Objects), must be declared explicitly. Also note that Application Variables are freely accessible within any CCXML 1.0 document in the application execution. An example of creating application variables is illustrated in this code snippet:



     <!-- declaring a user variable -->

       <var name="author" expr="'matthew henry'"/>

       <log expr="'***** AUTHOR = ' + author"/>





      <!-- assigning the user variable Application scope -->

       <assign name="application.author" expr="'steve sax'"/>

       <log expr="'***** AUTHOR = ' + author"/>

       <log expr="'***** APPLICATION.AUTHOR = ' + application.author"/>





      <!-- declaring a new Object -->

        <assign name="application.myObject" expr="new Object()"/>





      <!-- assigning application scoped properties to the Object -->

        <assign name="application.myObject.prop1" expr="'rob green'"/>

        <assign name="application.myObject.prop2" expr="'eric simpson'"/>



       <log expr="'***** APPLICATION.MYOBJECT.PROP1 = ' + application.myObject.prop1"/>

       <log expr="'***** APPLICATION.MYOBJECT.PROP2 = ' + application.myObject.prop2"/>

ANNOTATIONS: EXISTING POSTS

ctorkelson

4/28/2010 11:15 PM (EDT)

There seems to be an error in the declaration of the new object in this example. It seems that <var> should be <assign> as discussed here

http://lists.w3.org/Archives/Public/www-voice/2009OctDec/0022.html

Could this page be updated with a working example that shows how to read property values in one CCXML file that were assigned in another CCXML file?

voxeojeremyr

4/28/2010 11:53 PM (EDT)

Hello,

Thank you for the heads up on the update to the specification. I have notified our documentation team of the change and we should have that fixed in a few days.

As far as your question regarding a "working example that shows how to read property values in one CCXML file that were assigned in another CCXML file", can you give us any more details? Are you looking to pass variables from a parent CCXML document to a child document?

Standing by,
Jeremy Richmond
Voxeo Support

gayatripawar

4/14/2011 9:45 AM (EDT)

Hi..,

Thanks for your documentation, it helps us a lot in developing our application.
Actually I have a doubt : when session.callerid is restricted then the error is in application or at the server?
Please reply me on gayatri.pawar@sumasoft.net

VoxeoDustin

4/14/2011 3:46 PM (EDT)

Hey Gayatri,

If the caller ID value is returned as 'restricted', this is from the carrier as the caller has requested their number be restricted.

Regards,
Dustin

I: CCXML 1.0 Objects

| TOC

| Voxeo-Specific Properties