Volume 4, Issue 2 - March/April 2004
 
   
  CCXML Update

By RJ Auburn

Introduction

The W3C Call Control subgroup recently hit the milestone of releasing CCXML (Call Control XML) as a Last Call Working Draft. It's taken many long hours of meetings and teleconferences to get to this point, but the work has delivered many valuable clarifications and improvements to the specification. The working group feels this should be the last revision with any major technical changes.

CCXML Review

CCXML delivers a flexible XML based platform on which any call control application can be created. While some VoiceXML vendors have added proprietary VoiceXML call control elements, these elements address only the relatively basic call control requirements of IVR/speech applications. Call control requirements as a whole go far beyond IVR and speech applications, into areas such as conferencing systems, PBX and softswitch implementation, and Call Center call queuing and Automatic Call distribution (ACD).

CCXML is designed to address the requirements of the entire spectrum of call control applications. For example, Voxeo has already seen customers implement complete conferencing, call switching, and ACD solutions as applications on our CCXML platform. Previously, such applications have been developed on proprietary call control platforms that were built specifically for the call control application at hand.

I previously introduced CCXML in my VoiceXML review article of March 2002 located at https://voicexmlreview.org/Mar2002/features/ccxml.html. If you haven't already, you should take a few minutes to read that introduction.

Overview

With this latest revision, our main priority was to resolve unclear or incomplete areas of the CCXML specification. During this process several sections of the specification were completely rewritten. In addition, the revision includes a number of technical changes, addressing both missing functionality and various implementation issues that were found by companies who have already created CCXML products.

The main technical changes were:

  • Addition of a <dialogprepare> element
  • Conferencing Enhancements
  • Event I/O Architecture

Additionally the following items were more clearly documented:

  • Event Details
  • Error Handling
  • Execution Model

And last - but not least - we reworked several areas in the interest of overall consistency:

  • Event Names
  • Event Fields
  • Attribute Names
  • Attribute Values

The long list of enhancements and the resulting specification address most of the questions that were left lingering from prior CCXML specification revisions.

Details
Lets dig into the major technical changes to help everyone fully understand what each does and how you can take advantage of them in your applications.

<dialogprepare>
The <dialogprepare> element is new in this release of the CCXML specification. <dialogprepare> enables CCXML applications to instruct VoiceXML browsers to load and prepare VoiceXML documents in advance of their actual use. This allows CCXML applications to control potential delays associated with initiating and fetching VoiceXML documents.

Such functionality is especially valuable for outbound applications - such as an appointment reminder service - where any delay after answering but before prompt playback is uncomfortable for the call recipient. If the delay is too long, the call recipient may hang up before hearing the message; alternatively, they may say "hello" several times, raising their frustration before they begin interacting with a VoiceXML application.

How <dialogprepare> works: a CCXML application can use this element to prepare and prefetch a VoiceXML dialog before actually placing the call. This "prefetched" dialog is assigned a dialogID that can be referred to in a subsequent <dialogstart> element. For example:



<?xml version="1.0" encoding="UTF-8"?>

<ccxml version="1.0">

    <var name="dID"/>

    <var name="accountid" expr="'1234-4321'"/>

        <eventprocessor>

        <!-- Get a dialog ready. This should prefetch the 

            document and all the audio files/grammars. -->

        <transition event="ccxml.loaded">

            <dialogprepare 

                src="'http://www.example.com/billReminder.vxml'"

                namelist="accountid"

                dialogid="mydialog"/>

        </transition>

        

        <!-- The dialog is ready. Lets place the call.-->

        <transition event="dialog.prepared">

            <createcall dest="'tel:'"/>

        </transition> 

                        

        <!-- Connect the call to the prefeched dialog.-->

        <transition event="connection.connected">

            <dialogstart prepareddialogid="mydialog"/>

        </transition>

    </eventhandler>

</ccxml>

In this example, the CCXML application instructs the VoiceXML platform to fetch http://www.example.com/billReminder.vxml?accountid=1234-4321 and prepare any resources required to execute the returned VoiceXML. Once pre-fetching is complete, the CCXML application has the CCXML platform place a call and, when connected, instantly connect the caller to the prepared dialog. Without the <dialogprepare> element, if the www.example.com web server were slow, the caller would experience uncomfortable silence while the VoiceXML platform attempts to fetch the VoiceXML document.

One item of note: CCXML platforms may implement varying levels of optimization in <dialogprepare>. Some platforms may only save the URL and wait until <dialogstart> to load the specified VoiceXML, while others may offer full support for prefeching and pre-parsing the VoiceXML document plus any audio or grammar files it references.

Conferencing Enhancements

CCXML has now significantly expanded support for multiparty conferences, including support for conference resource reservation and enhanced media processing. These features are implemented via attribute enhancements to the <createconfrence> and <join> elements.

New <createconference> attributes:

conferencename -- This attribute allows CCXML applications to create named conferences. Named conferences make multiparty conference bridge applications easer to write as they remove the burden of tracking conference session id's from back-end web application logic.

The following static CCXML code allows a caller to dial in and enter a conference "room number" to connect to:



<?xml version="1.0" encoding="UTF-8"?>

<ccxml version="1.0">

    <var name="connectionID_in"/>

    <eventprocessor>

        <transition event="connection.alerting" 

        name="evt">

            <assign name="connectionID_in" expr="evt.connectionid"/>

            <accept/>

        </transition> 

        

        <transition event="connection.connected" name="evt">

            <!-- start the voicexml dialog to get the conf. Room # -->

            <dialogstart src="'http://www.example.com/getConfCode.vxml'"/>

        </transition>

                          

        <transition event="dialog.exit" name="evt">

            <!-- get the confCode returned by voicexml and create the conference -->

            <createconference confname="evt.values['confCode']"/>

        </transition>

        

        <transition event="conference.created" name="evt">

            <join id1="connectionID_in" id2="evt.conferenceid"/>

       </transition>

        

    </eventhandler>

</ccxml>

In previous versions of CCXML, the sample application above would have required a backend web application to keep track of the conference ids in use.

reservedtalkers -- This attribute allows CCXML applications to reserve the specified number of conference mixer resources for a conference bridge. If a CCXML application knows that it is going to have 20 participants in a conference, it can use this attribute to ensure all required resources are available to handle all 20 callers.

reservedlisteners -- Similar to reservedtalkers, this attribute enables a CCXML application to reserve resources for "listen only" conference participants. This is useful in applications such as public company quarterly earnings calls, where there are a large number of listen-only participants and a small number of speaking participants.

New conference <join> attributes:

entertone -- Allows CCXML applications to specify if they want a tone to be played when a party joins a conference bridge. This attribute can either be true/false or it can specify the URL of the audio "entry tone" prompt to play.

exittone -- Enables CCXML applications to specify if and what tone should be played when a party exits a conference bridge.

autoinputgain and autooutputgain -- Allows CCXML applications to specify if they want automatic gain control (AGC) enabled for this call leg. AGC is a technique that makes volume levels the same between one speaker and another despite differences in that speakers phone type (handset or speakerphone), and phone quality.

dtmfclamp -- Enables CCXML applications to specify DTMF tones are filtered out from the conference bridge.

toneclamp -- Allows CCXML applications to specify if other single frequency tones are removed from the conference bridge.

Event I/O

The next series of changes are found in the Event I/O Architecture. The Event I/O Architecture enables CCXML to send and receive events to or from other platform components.

Building a complete event input/output system is a complex endeavor that spans several working groups within the W3C. As a result, the CCXML subgroup chose to define a generic interface between CCXML and "Event I/O Processors" that transmit and receive events. The W3C Call Control Subgroup members hope to work within the W3C to publish more specific implementation details on Event I/O processors in the future, including standard event serialization formats and features for protocol level integration; but for now, these details are platform dependent. What has been standardized today is the interface within CCXML to Event I/O Processors, allowing CCXML to take advantage of emerging standards as they develop.

For incoming events, an Event I/O Processor receives events and renders them into a set of ECMAScript objects. These ECMAScript objects have properties and methods that CCXML applications can access. For simple events, these objects often contain a simple list of property fields. For more complex events, these objects may expose full DOM Objects encapsulating XML data that CCXML applications can access, using standard DOM API's or new XPath data binding API's from the W3C DOM Working group (http://www.w3.org/TR/DOM-Level-3-XPath/).

For outgoing events, CCXML uses the <send> element to communicate with the Event I/O Processor. CCXML Applications specify the event I/O processor to use with the targettype attribute, and the destination within or to be used by that processor via the target attribute. Any optional configuration of the Event I/O Processor is done using the hints attribute.

The following example shows how this mechanism could be used to communicate with an Event I/O Processor that can send events out as e-mail messages:




<?xml version="1.0" encoding="UTF-8"?>

<ccxml version="1.0">

    <eventprocessor> 

        <transition event="ccxml.loaded">



            <var name="jacksEmailBody" expr="'I am Jack\'s broken heart.'"/>



            <send 

                target="'mailto:'"

                targettype="'x-email'"

                data="'Hello Jack'"

                namelist="jacksEmailBody"

        </transition>

    </eventhandler>

</ccxml>

In the above example, we are using an "x-email" Event I/O Processor to send a message to , with a body of "I am Jack's broken heart." While the exact behavior of an email event processor would be platform dependent today, this example gives you an idea of how it could work. Our x-email example Event I/O Processor takes the event name (the data attribute) and uses it as the subject of the e-mail; and takes the event parameters (jacksEmailBody) and uses the contents for the e-mail body.

Next Steps

Now that CCXML has hit Last Call status, there are a few required steps before it can become a full W3C Recommendation. First, the CCXML specification will be reviewed by other W3C working groups. These groups will review the specification to ensure it fits well, where required, with their own work. Additionally, during this time, the Working Group solicits comments from the public on the all aspects of the specification. Any questions or concerns that are raised during this phase can either be addressed in another Last Call Working Draft or in the final Candidate Recommendation, depending on how significant the resulting changes are.

In parallel, the working group will also start work on a suite of test cases as part of an implementation report. These tests will cover all features in the CCXML specification, allowing the working group to verify that all required features have been implemented by at least two vendors, and all optional features have been implemented by at least one vendor. These vendor implementations and tests are required by the W3C for all final Candidate Recommendation specifications. Voxeo has already implemented all required and optional CCXML features, and vendors including Elix, Genesys, IBM, Phonologies, and Nortel have implemented most if not all required features. As a result these tests are expected to conclude relatively quickly.

If you have any questions or comments about the new CCXML working draft, please feel free to e-mail at , or send a message to the W3C public mailing list at. If you'd like to learn more about CCXML, you can read the full Last Call Working Draft at http://www.w3.org/TR/CCXML. Additionally, Voxeo offers many CCXML tutorials plus free access to our CCXML platform at http://www.voxeo.com in the "IVR Developer" section of our site.

back to the top

Copyright © 2001-2004 VoiceXML Forum. All rights reserved.
The VoiceXML Forum is a program of the
IEEE Industry Standards and Technology Organization (IEEE-ISTO).