CCXML 1.0-W3C Development Guide

| TOC

Prophecy 8.0 Porting Guide: CCXML

How do I know what version of CCXML I am using?

The first step to making sure that you are ready for this porting effort is to research what version of CCXML that you are currently using. You can verify this in several ways:

In the Application Mananger interface of Voxeo's hosted evolution portal ("Account" --> "Application Manager"), you can view the details of each application mapping. After selecting the "Application Manager" link in question, you will see a listing of all applications in your account containing fields for "Application Name", "Application Type", and "Deployment Type".

If your application type(s) read as "VoiceCenter 5.5 - CCXML Voxeo - DEPRECATED", then this indicates that your application code is based on the specification from 2002, and that the current platform used is the IVR platform that is set for deprecation.

If the application type(s) list "Prophecy - CCXML Voxeo", then this indicates that the code is using the CCXML markup from the 2002 specification on the most recent version of Prophecy, and that no porting will be required.

If your application type(s) read as "Prophecy - CCXML W3C 1.0", then your code is already using the most recent version of the Prophecy platform, and is using the most recent incarnation of the W3C specification from 2007, and no application porting will be required.

Within your code, if you see that main parent element is denoted as <eventhandler>, then your CCXML code is based on the specification from 2002. If your CCXML application content specifies <event processor>, then your code is based on the W3C specification from 2007, and no porting at all will be required.

If there is any doubt at all as to what platform that you are using, we encourage you to ask us for confirmation: We are happy to provide assistance to our developers to ensure that no problems arise from the migration to the newer software platform.

Prophecy Call Control XML 1.0 features

Prophecy 8.0 is the first-ever implementation of the W3C Call Control XML 1.0 working draft from 2007, which is far superior to the older implementation from 2002. While Prophecy 8 supports the older implementation that our developers have been using for a number of years, a conversion to the newer specification can enhance the IVR application in numerous ways:

The CCXML 1.0 browser supports the <dialogprepare> element, which adds another layer of failover when launching VoiceXML dialogs. When implemented properly, this ensures that the caller experience is never met with any errors due to a hosting server failing to load a VoiceXML component.

The CCXML 1.0 browser also natively supports full call recording. In the CCXML implementation from 2002, one had to resort to dedicating a call leg connected to a VoiceXML dialog to successfully record the entirity of a call when using a CCXML + VXML application, but this is no longer a problem with the Voxeo extensions to the CCXML 1.0 specification.

Staying well ahead of the curve, Voxeo's implementation on the Prophecy platform also offers support for the <foreach> element within the CCXML 1.0 context as well: While the inclusion of this feature into the official specification is still in the future, we have chosen to add this to the arsenal of features in our implementation per overwhelming demand from our developers.

Prophecy 8 also supports the full range of the Connection, Conference, and Dialog Objects that are detailed in the newest W3C specification.

The CCXML 1.0 platform also makes use of the JavaScript Object Notation methods for stringify and parse, which allows us to convert Objects to Strings, and vice-versa using client-side scripting: This can be very useful in accessing the properties of the various CCXML Object values, mentioned previously.

Prophecy 8 also supports ECMAScript for XML (E4X), an alternate client-side scripting language for developers to leverage in their CCXML 1.0 applications to replace the aging and clunky DOM interfaces that have been implemented in the past.

The CCXML 1.0 implementation using the Prophecy 8 platform also allows developers to launch not only VoiceXML dialogs, but also CallXML 3.0 dialogs as well. This allows for much more robust and finer grained control for those using the CallXML markup language as the primary dialog component in IVR applications.

Another new inclusion to the CCXML 1.0 platform is the ability to access newly-available shadow variables that are generated at the end of a call session that tracks the call start, call end times, along with a call duration summary for eaiser tracking/billing purposes.

CCXML 1.0 on the Prophecy platform has full ECMAScript support via the <script> element

Using the Prophecy platform, you can now turn off the Call Progress Analyzer and avoid scenarios where after confirming a human, you get a CPA event, and you stop and restart a dialog by invoking <script> session.connections[conn_id]._CPA.Enabled = false; </script>

When using the Prophecy platform CPA can continue listening for event, even while in VoiceXML dialogs.

CCXML Application Porting

Be aware of the fact that if you are using the older CCXML markup from the 2002 specification on the Voice Center 5.5 platform, it is not required that you update your application code to use the markup from the recent specification from 2007 in order for it to function on the Prophecy IVR software platform: With the few exceptions that are noted below, CCXML code from the 2002 specification that runs on the 5.5 platform is backwards compatible with the CCXML 2002 Prophecy platform, and will require only minor adjustments to your application code.

At some point in the distant future, CCXML 2002 will be deprecated in favor of the newer implementation, and it may well be worth the effort to stay ahead of the curve, and to port your application code now: The choice is up to you.

If porting from CCXML 2k2 to CCXML 1.0:
Should you choose to port our CCXML 2002 application code to use the markup definined in the newest incarnation of the CCXML specification from 2007, the following guidelines should serve as a valuable starting point:

Nomenclature changes in elements and attributes:

<accept callid=""> has been deprecated in favor of <accept conectionid="">

<createcall name=""> has been deprecated in favor of <createcall conectionid="">

<createccxml fetchd="">has been deprecated entirely

<createconference id=""> has been deprecated in favor of <createconference conferenceid="">

<createconference voxeo-confname=""> has been deprecated in favor of <createconference confname="">

<destroy> has been deprecated in favor of <destroy conference>

<destroy id=""> has been deprecated in favor of <destroyconference conferenceid="">

<dialogstart type="'application/xml+vxml;platform=motorola'"> has been deprecated entirely, and should be replaced with <dialogstart type="'application/voicexml+xml'">

<dialogstart callid=""> has been deprecated entirely.

<disconnect callid=""> has been deprecated in favor of <disconnect connectionid="">

<eventhandler> has been deprecated in favor of the <eventprocessor> element

<eventhandler id=""> has been deprecated entirely

<fetch synch=""> has been deprecated entirely

<join voxeo-entertone=""> has been deprecated in favor of <join entertone="">

<join voxeo-exittone=""> has been deprecated in favor of <join exittone="">

<redirect callid=""> has been deprecated entirely

<reject callid=""> has been deprecated in favor of <reject connection id="">

<send event=""> has been deprecated in favor of <send name="">. Note that while CCXML 2k2 does have a "name" attribute for the <send> element, it's usage is different when using Prophecy CCXML 1.0.

Nomenclature changes in CCXML events:

"ccxml.conference.joined" has been changed to "conference.joined"

"ccxml.conference.unjoined" has been changed to "conference.unjoined"

"ccxml.conference.created" has been changed to "conference.created"

"ccxml.conference.destroyed" has been changed to "conference.destroyed"

"ccxml.fetch.done" has been changed to "fetch.done"

"ccxml.authenticated" has been deprecated entirely

"connection.CONNECTION_ALERTING" has been changed to "connection.alerting"

"connection.CONNECTION_CONNECTED" has been changed to "connection.connected"

"connection.CONNECTION_CREATED" has been changed to "connection.progressing"

"connection.CONNECTION_DISCONNECTED" has been changed to "connection.disconnected"

"connection.CONNECTION_FAILED" has been changed to "connection.failed"

"call.CALL_CREATED", "call.CALL_ACTIVE", and "call.CALL_INVALID" have been deprecated entirely

"error.dialog.wrongstate" has been deprecated entirely

"error.send" has been changed to "error.send.failed"

"error.outofsync" has been deprecated entirely

"error.statemismatch" has been deprecated entirely

"error.system" has been deprecated entirely

"error.document" has been deprecated entirely

"user.*" syntax for events has been deprecated entirely

"system.ping" has been deprecated entirely

General tips, and "Gotchas":

Developers should also make a point to carefully look over the VoiceXML porting guide to ensure that all changes listed are put into place for existing dialog content.

Variables must be declared for left-hand ECMAScript: when invoking <send name="foo"/>, it is required that <var name="foo"/> is defined before the <send> element is invoked.

The <transition state="foo"> attribute is defined as a string, and as such, single quotes should not be specified:

CCXML 2007: <transition state="foo">
CCXML 2002: <transition state=" 'foo' ">

An unhandled "error.*" event implies an immediate application exit that is triggered at the platform scope, (this was put into place to prevent runaway sessions)

Any and all "timeout" attribute values are in CSS2 format, and should not be specified with a 'ms' (milliseconds) suffix:

CCXML 2007: <createcall timeout="'200'" ../>
CCXML 2002: <createcall timeout="'200ms'" ../>

"error" events no longer store the reason for the error in the 'error' field; these are stored in the 'reason' field, and the name of the error event is now available within the 'name' field:

CCXML 2007: "evt.error"
CCXML 2002: "evt.reason"

<transition event="error.*" name="evt"> <log expr=""'*** We caught an ' + evt.name + ' due to ' + evt.reason + ' ***'"/> <exit/> </transition>

Any ICM events are no longer prepended with "user."; this means that CCXML 2007 scripts should be edited to trap "myEvent" as opposed to "user.myEvent".

Outbound call transfer syntax via the <createcall>, or <createconference> elements, or programmatic outbound dialing via a request to http://api.voxeo.net should be specified using a strict e.164 format, as the Prophecy software is more strict in this regard: While Voice Center 5.5 allowed dial strings of "4072223333", or "tel:4072223333", outbound calls on Prophecy should use a syntax that specifies "tel:+[country code][number]", or "tel:+14072223333".

CallerID spoofing for outbound calls via the <createcall> element has changed in the Prophecy platform by intorducing the "callerid" attribute, so as to be compliant with the W3C specification:

CCXML 2007: <createcall dest="'tel:12223334444'" callerid="'1111111111'"/>
CCXML 2002: <createcall dest="'tel:12223334444;voxeo.option.callerid=1111111111'"/>

As the default Speechify 2.0 text-to-speech engine has been deprecated entirely, do be aware that in some cases, pronouciations of strings may well change. Therefore it is suggested that an audit of all TTS output be performed prior to deploying ported code in a production capacity. In addition, the older SP 2.0-specific TTS markup will no longer function on the Prophecy platform. Note that as there is no SSML support in any capacity for CCXML dialog extensions, any TTS tuning will need to be done within the context of a VoiceXML dialog, as opposed to a CCXML dialog extension.

As noted above, the migration to the Prophecy software, regardless of the decision to switch to CCXML 1.0 markup or not, comes with the change in Text-to-Speech engines available within the context of the Voxeo dialog extensions. At present, the following TTS options (and the syntaxes required to invoke them), that are available for use in both a Staging, and Production capacity are listed below:

* Prophecy English Female (default): <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=English-Female2'" type="'application/x-texttospeech'"/>

* Prophecy English Male: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=English-Male2'" type="'application/x-texttospeech'"/>

* Rhetorical Spanish Female: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=es-mx-fm3'" type="'application/x-texttospeech'"/>

* Rhetorical UK Female: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=en-gb-fm1'" type="'application/x-texttospeech'"/>

* Rhetorical English Male: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=English-Male3'" type="'application/x-texttospeech'"/>

If using CCXML code from the 2002 specification on the Prophecy platform:

Developers should be very much aware of the fact that <dialogstart type="'application/xml+vxml;platform=motorola'"> has been deprecated entirely, and should be replaced with <dialogstart type="'application/voicexml+xml'">. Failure to edit application content to comply with he correct "type" will result in unexpected behavior, and in some cases, a fatal application error.

Developers should also make a point to carefully look over the VoiceXML porting guide to ensure that any changes detailed are put into place for any existing dialog content.

As the default Speechify 2.0 text-to-speech engine has been deprecated entirely, do be aware that in some cases, pronouciations of strings may well change. Therefore it is suggested that an audit of all TTS output be performed prior to deploying ported code in a production capacity. In addition, the older SP 2.0-specific TTS markup will no longer function on the Prophecy platform. Note that as there is no SSML support in any capacity for CCXML dialog extensions, any TTS tuning will need to be done within the context of a VoiceXML dialog, as opposed to a CCXML dialog extension.

As noted above, the migration to the Prophecy software, regardless of the decision to switch to CCXML 1.0 markup or not, comes with the change in Text-to-Speech engines available within the context of the Voxeo dialog extensions. At present, the following TTS options (and the syntaxes required to invoke them), that are available for use in both a Staging, and Production capacity are listed below:

* Prophecy English Female (default): <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=English-Female2'" type="'application/x-texttospeech'"/>

* Prophecy English Male: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=English-Male2'" type="'application/x-texttospeech'"/>

* Rhetorical Spanish Female: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=es-mx-fm3'" type="'application/x-texttospeech'"/>

* Rhetorical UK Female: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=en-gb-fm1'" type="'application/x-texttospeech'"/>

* Rhetorical English Male: <dialogstart src="'null://?text=This is a test of the Text to Speech dialog extension&voice=English-Male3'" type="'application/x-texttospeech'"/>

ANNOTATIONS: EXISTING POSTS

0 posts - click the button below to add a note to this page

Cache Manager API

| TOC

| Learning CCXML 1.0