April 23, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Introduction to CCXML, Part IV

  • November 7, 2002
  • By Jonathan Eisenzopf
  • Send Email »
  • More Articles »

In Part IV of the Introduction to CCXML, we will learn how to set up and breakdown a 2-party conference call using <join> and <unjoin>. We will also learn more about state variables and their use in CCXML.

Overview

We're going to build on the concepts that were introduced in the first three CCXML tutorials and extend them to simple call conferencing. In CCXML, there are two different types of conferencing elements. The simplest type uses the <join> and <unjoin> elements to conference two call legs together. The limitation is that it can only handle 2 callers. For multi-party conference calls, we would have to use the <createconference> and <destroyconference> elements. In this tutorial, we're going to stick with a two party conference call and look at multi-party conference calls in the next part of the Introduction to CCXML.

State Variables

One of the new concepts that I'm going to introduce in this tutorial is the state variable. A state variable is initialized when the CCXML application starts up. This variable changes its value (or state) as the call progresses. The name of the state variable is defined by the statevariable attribute in the <eventhandler> element:

<eventhandler statevariable="current_state">

The <eventhandler> element only points to the name of the variable that will be used as the state variable. It's still up to you to initialize the variable in the CCXML file:

<var name="current_state" expr="'init'"/>

You should set the state to an initial value that indicates that the program has just started, such as init or start, though there is not a standard naming scheme for the state variable.

This state variable defines the current state of the call and can be used to make decisions about what to do next. For example, we may not want to start an interactive VoiceXML dialog until the caller has listened to a disclaimer dialog first. To accomplish this, we would create a state variable that would change as soon as the caller had listened to the terms, which would trigger and play the main dialog.

<transition name="evt" state="'ready'"
            event="connection.CONNECTION_CONNECTED">
  <assign name="incoming_callid" 
          expr="evt.callid"/>
  <assign name="current_state" 
          expr="'playing_terms'"/>            
  <dialogstart src="'play_terms.vxml'"/>
</transition>

<transition name="evt" 
            state="'playing_terms'" 
            event="dialog.exit">
  <assign name="current_state" 
          expr="'running_main_dialog'"/>
  <var name="age" expr="evt.age"/>
  <if cond="age > 21">
    <dialogstart src="'main.vxml'"/>
    <else/>
      <exit/>
  </if>
</transition>

<transition name="evt" 
            state="'running_main_dialog'" 
            event="dialog.exit">
  <exit/>
</transition>

In the CCXML fragment above, the name of the state variable is current_state, which is defined elsewhere. When the call is connected and the CONNECTION_CONNECTED event is triggered, it's caught by the first <transition> element based on the matching event attribute and matching value for the state attribute. When a call is connected and this event handler is executed, the state variable will be changed to playing_terms and the VoiceXML dialog play_terms.vxml will be started.

When the dialog has completed and exited, the dialog.exit event is triggered by the CCXML interpreter. Notice how the second and third <transition> elements are both catching the dialog.exit event? What makes them different is that the second event handler will only be executed when the state variable is set to playing_terms whereas the third will only execute when the state variable is set to running_main_dialog. The ability to execute different handlers for the same event is what the state variable gives us. Think of it as a second way we can match or define event handlers; first by the named event, and second by the state variable. While we have less control over which events get fired by the CCXML interpreter, we do have TOTAL control over the value of the state variable.

So, when play_terms.vxml has completed execution, the second event handler will be triggered and the main.vxml dialog will start running. We've also changed the value of the state variable from playing_terms to running_main_dialog so that when main.vxml has completed executing, it will trigger the third event handler and call <exit/> ending the call. You can view the entire CCXML program here.





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel