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 http://www.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:+1-831-555-1234'"/>
</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:marla@example.com'"
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 marla@example.com ,
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 rj@voxeo.com,
or send a message to the W3C public mailing list at
www-voice@w3.org.
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).
|