Volume 6, Issue 3 - Sep/Oct 2006
 
   
 

First Words – Is There Life Beyond VoiceXML?

Welcome to “First Words” – the VoiceXML Review’s column to teach you about VoiceXML (and now CCXML!!) and how you can use it. We hope you enjoy the lesson.

We’re off in a new direction in this issue. We’ve spent a long time – nearly six years! – working with VoiceXML 2.0 and more recently VoiceXML 2.1.  Now, we going to spend some time looking at the exciting ways that VoiceXML can work with CCXML (yeah, yeah, I know – I need a hobby).


A Brief Overview of CCXML

CCXML (Call Control XML) is a specification being developed by the Call Control subgroup of the Voice Browser Working Group of the W3C.  CCXML provides mechanisms for implementing advanced call control functionality in a standards-based way.  The original work on CCXML was derived from industry contributions from companies such as Telera (now part of Genesys) and Voxeo. Many of the contributors to CCXML have been involved with the development of VoiceXML as well.


How CCXML and VoiceXML Work Together

If you’ve been following our investigations into VoiceXML, you will have noticed that the call control you can manage with VoiceXML is pretty limited.  You can transfer a call (in a few different ways), and you can hang up.     Good stuff for many kinds of applications, but still, not terribly exciting.  The reason for this is that the Voice Browser Working Group vision has always been for a separate standard that managed advanced call control.  There is where CCXML comes in.

CCXML relies upon other resources (such as VoiceXML) to directly interact with the caller using prompts, speech recognition, DTMF, and text to speech.   CCXML focuses instead on controlling how calls are set up, torn down, and how the audio paths are connected and moved around.  It then relies on these other resources to actually do something with the media.   So CCXML will do things like connect a call to a VoiceXML application, a conference mixer, or some other resource.

For a more concrete example, consider this:

  1. A new inbound call is presented to a CCXML interpreter; the CCXML application can look at the information coming along with the call (caller’s number, callee’s number, and so on), and decide what to do with it before even answering the call.
  2. Let’s assume that we decide to route this call to a self-service application.  The CCXML application might select a VoiceXML resource to handle the call, and prepare it for use;
  3. Once the VoiceXML session is ready, the CCXML application would then answer the call, and connect it to the VoiceXML dialog.
  4. When the VoiceXML dialog is complete, it can indicate this by executing an <exit/> or <disconnect/>.  The CCXML application is informed of this, and can then terminate the call.

There are a few interesting things to consider here:

  • In our work with VoiceXML, much of this happens magically under the hood of whatever VoiceXML platform we’re using.  In fact the VoiceXML platform is performing much of this on our behalf (likely without using CCXML, but rather software that is written to interact with the VoIP network, or a telephony card).  When our VoiceXML session ‘starts’, we’re already connected to the call.
  • CCXML doesn’t actually deal with the ‘media’ (voice in this example).  CCXML manages the call signaling, and uses this to move media ‘channels’ so that it is connected to different ‘endpoints’.  So in our example above, CCXML will decide that the media needs to be connected to a VoiceXML session for the duration of that call.  After the VoiceXML session is complete, the CCXML application may then choose to move that media channel elsewhere – connecting the caller to an agent, transferring the call elsewhere, or even connecting to another VoiceXML application.  In this model, CCXML actually makes things like <transfer/> and <disconnect/> do what they are supposed to do.
  • Although the CCXML specification is being developed to be independent of the dialog services to which it controls access, CCXML does pay special attention to VoiceXML.  The specification includes an appendix that describes the kind of events and data that need to be exchanged between CCXML and VoiceXML.  In this series, we’re going to focus on how VoiceXML and CCXML work together (otherwise, my continued career with the VoiceXML Review could be in jeopardy!).

CCXML and VoiceXML are both ‘application’ level languages.  They allow a developer to specify call control and dialog behavior using a standardized markup language.  However, neither the VoiceXML nor CCXML specifications specify the ‘plumbing’ that controls how CCXML and VoiceXML talk to each other.   Internet plumbing is the responsibility of the Internet Engineering Task Force (IETF).  The IETF looks after protocols like SIP and RTP, the foundation for modern VoIP systems.
 
A working group in the IETF is currently designing the plumbing that can connect VoiceXML and CCXML.   The specification builds upon RFC 4240 (also known as NETANN), an existing specification that defines how to invoke particular services in a VoIP environment.  The new specification is currently published as draft-burke-vxml, and itself builds upon RFC 3261 – the ubiquitous SIP.

Over the coming months, we’ll have a closer look at all of these parts and how they work together.  We won’t worry too much about the plumbing parts, although we will spend one article on it later on.


Further Reading

For further reading on these topics, you can have a look at:

http://www.w3.org/Voice - Home of the VoiceXML and CCXML specifications;
http://www.ietf.org – Home of Requests For Comments (RFCs) such as SIP and NETANN;

The particular things we’ve referenced in this article:

There have been a number of articles on CCXML in past issues of VoiceXML Review.   And: Read this issue of the VoiceXML Review!! There are several great articles talking about VoIP and VoiceXML.


Summary

Once you’ve mastered VoiceXML, you may be interested in learning how to build applications that use more advanced call control techniques.    CCXML and VoiceXML can be combined using standards-based technologies to help you do this.


What’s Next?

Next month, we’ll start to look into how CCXML and VoiceXML combine to let you build extremely rich applications.  In the articles following that, we’ll build some interesting CCXML applications.

back to the top

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