|
A Gentle Introduction to CCXML – Part One
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’ve spent quite a while learning about VoiceXML. And there will be more to come, as VoiceXML continues to evolve. In fact, VoiceXML 2.1 just reached the Proposed Recommendation phase – see http://www.w3.org/TR/voicexml21/ for the latest version.
In this series of articles however, we’re going to spend some time learning about how you can bring the strength of open standards to call control, allowing you to build richer applications that are easier to maintain and extend.
In the last issue, we gave a quick overview of how CCXML and VoiceXML might work together to offer different kinds of services. This issue, we are going to start by introducing the basic concepts that you will need to understand in CCXML. In future issues, we’ll start to build a simple CCXML application, and then put it together with some simple VoiceXML applications.
CCXML Concepts
CCXML allows you to build applications that are event-driven. That is, external events (like call control events) will be ‘caught’ by the CCXML application. The CCXML application will then take different actions (for example, starting a dialog, or joining a connection to a conference), and then perhaps change the state of the CCXML session. The overall state of the application is maintained by the CCXML environment.CCXML allows an application to:
- Create and destroy conferences;
- Create, destroy, and interact with dialogs (for example, a VoiceXML session);
- Accept, merge, redirect, and reject calls;
- Join calls to conferences, dialogs, and each other;
- Create and interact with other CCXML sessions;
- Interact with the outside world using HTTP
The CCXML Platform manages all of this using the call control signaling (for example, Session Initiation Protocol (SIP)). You may recall from our last article that CCXML doesn’t actually deal with the ‘media’ (for example, voice and video). CCXML manages the call signaling, and uses this to move media ‘channels’ so that they are connected to different ‘endpoints’. So CCXML relies upon capabilities of other components – like dialog (VoiceXML) platforms, and conference servers.
In the diagram below, a CCXML Platform is managing multiple CCXML sessions. A CCXML session is executing a CCXML document retrieved from a web application server. The CCXML application is using SIP signaling (solid line) to manage media channels (dashed lines) between different endpoints. The dialog represents (for example) a VoiceXML dialog running on a VoiceXML platform. The Connection represents a call from the telephone network, and the Conference represents a mixing element, which is mixing audio from different channels.
CCXML applications are concerned with different kinds of entities as compared to VoiceXML applications. Within a VoiceXML application, we worry about a session, or dialog, which represents a ‘call’. A VoiceXML application is driven by caller interaction, and the VoiceXML Form Interpretation Algorithm (which controls how a VoiceXML platform collects information from the caller).
In CCXML, we are concerned with elements related to call control and signaling. These are delivered as events, and allow us to manage the core CCXML entities:
- Sessions - A CCXML Session is a context which ‘owns’ connections, conferences, and dialogs.
- Connections - Connections represent calls that exist between different endpoints – for example, between a PSTN user, and a VoiceXML platform.
- Conferences - Conferences represent the mixing of media from different endpoints. This allows (for example) connections and dialogs to ‘hear’ multiple speakers simultaneously.
- Dialogs - A dialog includes things like VoiceXML applications, or even dialogs implemented and managed using traditional Interactive Voice Response (IVR) systems. These can be invoked and managed from a CCXML application.
CCXML therefore is concerned with creating, moving, and destroying the dashed lines in the diagram above, using control channels indicated by the solid lines. We’ll walk through some additional examples next issue, and understand how this call control happens ‘by default’ with a typical VoiceXML platform.
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:
In addition, SpeechTek University often includes very good tutorials about CCXML.
Summary
Understanding the concepts behind CCXML will allow you to start to begin building CCXML applications. This article has hopefully given you a start on this.
What’s Next?
Next issue, we’ll continue to learn about CCXML, and start to consider how we can use it to build interesting applications.
back
to the top
Copyright
© 2001-2007 VoiceXML Forum. All rights reserved.
The VoiceXML Forum is a program of the
IEEE
Industry Standards and Technology Organization (IEEE-ISTO).
|
