Voice Browser Call Control: CCXML Version 1.0

Abstract

This document describes CCXML, or the Call Control eXtensible Markup Language. CCXML is designed to provide telephony call control support for VoiceXML or other dialog systems. CCXML has been designed to complement and integrate with a VoiceXML system. Because of this you will find many references to VoiceXML's capabilities and limitations. You will also find details on how VoiceXML and CCXML can be integrated. However it should be noted that the two languages are separate and are not required in an implementation of either language. For example CCXML could be integrated with a more traditional IVR system and VoiceXML or other dialog systems could be integrated with some other call control systems.

Status of this Document

This specification describes markup for designed to provide telephony call control support for VoiceXML or other dialog systems. CCXML is far from complete. This draft is meant to give people access to an early version of the language so that people can understand the direction that the working group is moving in. This specification describes the Call Control XML (CCXML) markup language that is designed to provide telephony call control support for VoiceXML or other dialog systems. This document has been produced as part of the W3C Voice Browser Activity, following the procedures set out for the W3C Process . The authors of this document are members of the Voice Browser Working Group ( W3C Members only ). This is a Royalty Free Working Group, as described in W3C's Current Patent Practice note. Working Group participants are required to provide patent disclosures.

This document is for public review, and comments and discussion are welcomed on the public mailing list <www-voice@w3.org>. To subscribe, send an email to <www-voice-request@w3. org> with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible online.

This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

This is work in progress and does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR/ .

Table of Contents

• Section 1: Introduction
• Section 2: Background
• Section 3: Concepts
• • 3.1: Event Processing
  • 3.2: Conferencing
  • 3.3: Call Management
  • 3.4: Scripting
  • • 3.4.1: Introduction
    • 3.4.2: Definitions
• Section 4: Object Model and Programming Contract
• Section 5: CCXML Elements Listing
• Section 6: Document Control Flow and Execution
• • 6.1: Overview
  • 6.2: elements
  • • 6.2.1: <ccxml>
    • 6.2.2: <if>
    • 6.2.3: <elseif>
    • 6.2.4: <else>
    • 6.2.5: <fetch> and <goto>
    • 6.2.6: <createccxml>
    • 6.2.7: <exit>
    • 6.2.8: <log>
  • 6.3: Events
  • • 6.3.1: Overview
    • 6.3.2: fetch.done
    • 6.3.3: error.fetch
    • 6.3.4: ccxml.exit
    • 6.3.5: ccxml.loaded
• Section 7: Dialogs
• • 7.1: Overview
  • 7.2: elements
  • • 7.2.1: <dialogstart>
    • 7.2.2: <dialogterminate>
  • 7.3: Events
  • • 7.3.1: Overview
    • 7.3.2: dialog.started
    • 7.3.3: dialog.exit
    • 7.3.4: dialog.disconnect
    • 7.3.5: dialog.transfer
    • 7.3.6: error.dialog.notstarted
    • 7.3.7: error.dialog.wrongstate
    • 7.3.8: dialog.user.*
• Section 8: Variables and Expressions
• • 8.1: Overview
  • 8.2: elements
  • • 8.2.1: <assign> and <var>
    • 8.2.2: <script>
• Section 9: Event Handling
• • 9.1: Event Concepts
  • 9.2: elements
  • • 9.2.1: <eventhandler>
    • 9.2.2: <transition>
    • 9.2.3: <send>
    • 9.2.4: <move>
  • 9.3: Event Transmission
  • 9.4: Standard Events
  • • 9.4.1: Connection Class
    • 9.4.2: Connection Events
    • 9.4.3: Standard Events
  • 9.5: Error Events
• Section 10: Telephony Operations and Resources
• • 10.1: Incoming Calls
  • • 10.1.1: Overview
    • 10.1.2: <accept>
    • 10.1.3: <redirect>
    • 10.1.4: <reject>
    • 10.1.5: <hold>
  • 10.2: Outgoing Calls
  • • 10.2.1: <createcall>
  • 10.3: Conferencing
  • • 10.3.1: <createconference>
    • 10.3.2: <destroyconference>
    • 10.3.3: <join>
    • 10.3.4: <unjoin>
  • 10.4: Bridging
  • 10.5: Disconnect
  • • 10.6.1: <disconnect>
• Section 11: Security
• • 11.1: Overview
  • 11.2: <authenticate>
• Section 12: Examples
• Appendix A - Future Study and Issues
• Appendix B - Related Work
• Appendix C - CCXML DTD
• Appendix D - CCXML Schema
• Appendix E - VoiceXML Integration
• Appendix F - Recommended Telephony Protocol Names
• Appendix G - Changes
• Appendix H - Acknowledgments

Section 1: Introduction

This document describes CCXML, or Call Control eXtensible Markup Language. CCXML is designed to provide telephony call control support for VoiceXML or other dialog systems. CCXML is intended to be an adjunct language to be used with a VoiceXML or other dialog implementation platform.

CCXML has been designed to complement and integrate with a VoiceXML system. Because of this you will find many references to VoiceXML's capabilities and limitations. You will also find details on how VoiceXML and CCXML can be integrated. However it should be noted that the two languages are separate and are not required in an implementation of either language. For example CCXML could be integrated with a more traditional IVR system and VoiceXML or other dialog systems could be integrated with some other call control systems.

CCXML is far from complete. This draft is meant to give people access to an early version of the language so that people can understand the direction that the working group is moving in.

Please note that this is a large document, and there are lots of improvements to make to it. However, it's more important to get widespread discussion on CCXML's ideas than to spend eternity refining it. There are a number of known issues and improvements, which are listed in this document in green. It holds ideas that should be incorporated, but were not included in this draft because of time constraints.

This document describes CCXML, the Call Control eXtensible Markup Language. CCXML provides declarative markup to describe telephony call control. CCXML is an adjunct language that can be used with VoiceXML or other dialog systems.

CCXML has been designed specifically to complement VoiceXML. Therefore, this document contains references to VoiceXML's capabilities and limitations, and details on how VoiceXML and CCXML can be integrated. However, the two languages are separate and neither is required for an implementation of the other. CCXML can be integrated with a traditional IVR system, and VoiceXML can interface with other call control systems.

CCXML is not complete. This draft provides access to an early version of the language, and illustrates the direction of the working group.

This is a large document and there are improvements still to be made to it. However, the working group believes it is more important to stimulate widespread discussion of CCXML's ideas by releasing a series of CCXML working drafts, than to defer release until the document is refined. There are a number of known issues and improvements, listed in this document in green, which highlight ideas that should be incorporated, but that are not resolved in this draft because of time constraints.

Section 3: Concepts

Properly adding advanced telephony features to VoiceXML entails adding not just a new telephone model, but new call management and event processing, as well. We'll briefly cover these three areas here. Since new event processing has the largest impact on our architecture, let's examine it first.

Section 3.1: Event Processing

Telephone applications need to receive and process large numbers of events. These events arrive from outside the program itself - either the underlying telephony platform, or from other programs. They must be processed quickly, as any delays could be discerned by the user.

Unfortunately, VoiceXML is not designed for the task. Its event model assumes only "synchronous" events - those which occur only when the program occupies certain states. (For example, a nomatch event can only occur within a field.) The language would have to be augmented to properly handle events which can arrive at any time. (It's true that telephone.disconnect can occur at any time, but this is something of a special case.) Further, it would be tough to reconcile the need for immediate processing with VoiceXML's single-threaded model.

Instead, we move all asynchronous handling to a CCXML session. Every executing VoiceXML program has an associated CCXML session. It runs on a session separate from the VoiceXML dialog. When an event is delivered to a user's voice session (now a coupling of an active VoiceXML dialog and its CCXML session), it is appended to the CCXML session's queue of events. The CCXML session spends almost all its time removing the event at the queue's head, processing the event, and then removing the next event. Meanwhile, the VoiceXML dialog can interact with the user, undisturbed by the incoming flow. Most VoiceXML programs never need to consider event processing at all.

Writing a CCXML program, then, mainly involves writing the handlers which are executed when certain events arrive. There are mechanisms for passing information back and forth between VoiceXML and CCXML, but the important points are that CCXML:

• lives on its own thread, and
• carries the burden of rapid asynchronous event handling

Note: References to threads are meant as logical threads and do not imply any specific platform implementation.

Section 3.2: Conferencing

VoiceXML currently has very few options for conferencing. Only the transfer element will establish any kind of connection between two voice callers; calls involving more than two parties, or other advanced applications, are out of reach. VoiceXML is largely a language for voice dialogs, and is silent on many telephony issues.

We would like a far more powerful and flexible method of creating calls. To do so, we introduce a few ideas here:

• Call legs are in some ways just audio sinks and sources. We should be able to join together arbitrary networks of them.
• A modern-day conference is not much more than an audio stream that mixes together all the speakers' audio outputs. Our conference networks will allow for conference objects, which mix together inputs into a single output channel.
• Our conferences could also include splitters, which take a single input channel and emit it over several outputs.
• The conference's architecture may be modified dynamically, thus allowing for moderation, floor control, mute, etc.
• Human speakers are not the only entities that can generate and consume audio. VoiceXML interpreters will be first-class citizens in the conferences we create, allowing, for example, "robot moderators" to operate discussions.
• Finally, we realize that conferencing technology is very dependent on the implementation platform. CCXML browsers may refuse to create certain conferences or networks, and still be in compliance. A large part of a CCXML program's event handlers will be concerned with these conferencing operations. All of these goals match the use-case and architectural documents that the Call Control working group has discussed so far.

Section 3.3: Call Management

VoiceXML also fails to offer sufficient control over the underlying telephone network. Although VoiceXML offers the disconnect directive to hang up an existing phone call, there are a number of desirable features to which the VoiceXML programmer cannot get access. They include:

• Outbound call placement.
• Selective call-answering. Currently, a running VoiceXML interpreter is always tied to an answered line. We may want to perform some computation before deciding if and how to answer the call.
• Some access to phone network signaling and error conditions.

We want to expose the phone network in a provider-neutral way, while still offering enough methods and information to be interesting. Toward that end, we have taken the Java Soft JCP call model for telephony-access. The topic is discussed below in more depth.

We want to expose the phone network in a provider-neutral way, while still offering enough methods and information to allow sophisticated types of call management. Toward that end, we have defined typical call control actions in a high-level, abstract way so that almost any underlying telephony definition should be able to implement them. This is discussed in more detail in Section 9.

Section 3.4: Scripting

Section 3.4.1 Introduction

The computational semantics of CCXML are based on the ECMAScript Compact Profile (ES-CP, also known as ECMA-327). Execution efficiency is a goal of the designers of CCXML, and ES-CP was chosen in order to avoid excessive execution overhead.

The ES-CP document states,

'ECMAScript Compact Profile is a subset of ECMAScript 3rd Edition tailored to resource-constrained devices such as battery powered embedded devices. Therefore, special attention is paid to constraining ECMAScript features that require proportionately large amounts of system memory (both for storing and executing the ECMAScript language features) and continuous or proportionately large amounts of processing power.'

CCXML is not intended for battery powered embedded devices, but it is intended to be practical for large, real-time telephony platforms managing thousands of lines. The constraints of ES-CP emphasize CCXML's ongoing concern for execution efficiency.

Even though ES-CP tends to be implemented using interpreters, CCXML does not require an interpretive implementation. ES-CP can be compiled to a target language such as C, and thus in turn to machine code, so that CCXML documents which are static can be rendered once in machine code. Even frequently modified CCXML documents can be translated and compiled on their way from the document server to the CCXML execution environment, in order to avoid multiplying interpretive overhead by the number of lines that execute the document.

The emphasis on efficiency in CCXML is also shown by the avoidance of features which can only be implemented either by interpretation or run-time evaluation.

The choice of an implementation strategy is up to the CCXML implementer. CCXML is designed to allow a range of choices in order to accommodate practical implementations on a wide variety of platforms.

Section 3.4.2 Definitions

The following terms, which are used throughout this specification, are defined here.

ECMAScript left-hand-side expression - defined in ECMA-262 11.2; this is an expression which produces a result to which a value can be assigned; an expression which is valid as the left hand operand of an assignment (=) operator;

ECMAScript expression - defined in ECMA-262 11.14; this is an expression which produces a value; an expression which is valid on the right hand side of an assignment operator;

ECMAScript variable name - defined in ECMA-262 7.6; this is any valid sequence of characters, known as an identifier, which can be used as a variable name, a property name, or a function name; this does not include any qualifiers, such as array or property accessors;

Empty ECMAScript object - an object returned by the new Object() expression; an object with no properties.

CCXML variable name - a variable name declared in a CCXML <var> element, with optional dot separated qualification.

Scope element - a CCXML element which defines a variable scope; <ccxml> and <transition> are CCXML scope elements.

Times - CCXML uses the CSS2 time format. Time designations consist of a non-negative real number followed by a time unit identifier. The time unit identifiers are:

• ms: milliseconds

• s: seconds

Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".

Section 4: Object Model and Programming Contract

CCXML can start and kill voice dialogs using language elements. It can receive events from voice dialogs, which may be standardized events such as dialog.exit , or application-specific ones. CCXML can support sending of an event to a voice dialog. We describe below how VoiceXML might be slightly modified to synchronously process arbitrary external events, much as it processes recognition events today. CCXML's only guaranteed control over a dialog is start and kill. Even if VoiceXML will process these external events, anything more than lifetime-management must be specifically supported by the voice dialog.

Finally, CCXML can create other CCXML sessions using a language element. That is the only guaranteed control one CCXML sessions ever wields over another. Any other interaction takes place through the event mechanism. CCXML sessions can both send and receive events between one another.

Section 5: CCXML Elements Listing

Section 6: Document Control Flow and Execution

Section 6.1: Overview

The execution of a CCXML document begins with the <ccxml> element at the top and then proceeds element by element in document order. The flow of the execution can be changed with the help of <if>, <elseif>, <else>, <fetch>, and <goto> elements. Most of a CCXML session's execution will take place within an <eventhandler> , which processes a stream of incoming events. A CCXML application can consist of multiple CCXML documents, traversed by use of <goto> and <fetch> .

Section 6.2: elements

Here are the details of the CCXML elements for control flow and execution.

Section 6.2.1: <ccxml>

Section 6.2.1.1: Overview

This is the parent element of a CCXML document and encloses the entire CCXML script in a document. When a <ccxml> element is executed, its child elements are collected logically together at the beginning of the document and executed in document order before the target <eventhandler>. This is called document initialization.

Section 6.2.1.2: CCXML Attribute Details

Section 6.2.2: <if>

Section 6.2.2.1: Overview

The <if> element is a program-control element. The <else> and <elseif> elements can appear optionally within an <if> element.

Section 6.2.2.2: If Attribute Details

Section 6.2.3: <elseif>

Section 6.2.3.1: Overview

The <elseif> element is a program-control element. The <else> and <elseif> elements can appear optionally within an <if> element.

Section 6.2.3.2: Elseif Attribute Details

Section 6.2.4: <else>

Section 6.2.4.1: Overview

The <else> element is a program-control element. The <else> and <elseif> elements can appear optionally within an <if> element.

Section 6.2.4.2: Else Attribute Details

Section 6.2.5: <fetch> and <goto>

Section 6.2.5.1: Overview

The <fetch> element, together with <goto> , is used to transfer execution to a different CCXML document in a multi-document CCXML application. In VoiceXML this is performed via the <goto> element, which blocks execution until the target page is loaded and ready to execute. CCXML programs, however, can be substantially more timing-sensitive than VoiceXML ones. All event-handling would have to be suspended until a blocking <goto> had found the target page, loaded, and parsed it. The time required could be hundreds of milliseconds or seconds, periods too lengthy for ignoring important incoming events.

Instead, we break the functions of VoiceXML's goto command into two parts. The <fetch> operator tells the interpreter to find, load, and parse a given page of CCXML. Execution returns from the element immediately, and the CCXML interpreter can continue on while the execution context works to get the target document ready for execution. When the <fetch> completes, the document which issued the fetch receives a fetch completion event. It can then issue a <goto> to immediately start executing the now-fetched page.

Below is a small snippet of code from the CCXML program's event handler. We execute a <fetch> operation, and continue on to assign to a state variable, and maybe handle more events. Eventually, the fetch completes, the CCXML interpreter services the event, and we perform the <goto> .

<fetch next="'http://www.web.com/control.ccxml'"/>
<--control continues here->
<assign name="state_var" expr="'fetch_wait'"/>
</transition>

<!-- ……… -->

<transition state="fetch_wait" event="fetch.done" name="evt"/>
<goto fetchid="evt.fetchid"/>
</transition>

There's no requirement to <goto> previously-fetched pages, but it is wasteful to not do so.

Section 6.2.5.2: Fetch Attribute Details

Asynchronous execution of a fetch element initiates a request for the CCXML document identified by its attributes. Execution immediately continues with the element following the fetch. When the asynchronous request has completed, the fetch completion event will be generated. If the fetch fails for any reason, a fetch fail event will be generated instead.

When fetch is executed synchronously, the CCXML document blocks until the fetch completes, and the fetch completion event is stored as identified by the synch attribute. In this case, the element following the fetch element will not be executed until fetch completes. The properties of the fetch completion event can be tested to determine the result of the fetch request, so that error handling alternatives can be provided.

Section 6.2.5.3: Goto Attribute Details

A goto element transfers control to the document identified by the fetch ID. The execution of a goto element does not depend upon whether the target document was fetched synchronously or asynchronously. However, the fetch completion event must have arrived before the <goto> is executed, otherwise, an error event is generated.

When a goto element is executed, the target document replaces the current document in its session. event sources associated with this session are inherited by the target document. Execution of the current document terminates.

Section 6.2.6: <createccxml>

Section 6.2.6.1: Overview

The createccxml element is used to create another CCXML session, which begins execution with the document identified by this element. The term "session" is not meant to imply a particular form of implementation. A CCXML session exists for each concurrently executing CCXML document. A session provides independent execution and a separate variable space for the CCXML documents it executes. A session is associated with one or more event sources and will receive events only from those endpoints. The execution of a CCXML document may add or subtract event sources from a session.

The createccxml element is used to create another CCXML session. The new CCXML session has no relation to its creator once spawned, and has a wholly separate lifetime and address space.

Section 6.2.6.2 Createccxml Attribute Details

Section 6.2.7: <exit>

Section 6.2.7.1: Overview

The exit element ends execution of the CCXML session. All pending events are discarded, and there is no way to restart CCXML execution.

The exit element ends execution of a CCXML document and its session.

Section 6.2.7.2 Exit Attribute Details

A CCXML script executing the <exit> element will generate a ccxml.exit event to the parent session. The exiting document will be identified on the exit event by its session ID.

Section 6.3: Events

Section 6.3.1: Overview

CCXML uses several threads to deal with document fetching, startup and shutdown.

CCXML allows operations such as document fetching, startup and shutdown to execute independently.

The following are the CCXML events that have to do with this:

Section 6.3.2: fetch.done - Fetch Completion Event

This event is generated when a fetch request completes. It is delivered to the document which issued the request.

The fields of this event are:

Section 6.3.3: error.fetch - Fetch Error Event

This event is generated when a fetch request does not successfully complete. It is delivered to the document which issued the request.

The fields of this event are:

Section 6.3.4: ccxml.exit - CCXML Document Exit Event

This event is generated when a CCXML document executes an <exit> element.

The fields of this event are:

Section 6.3.5: ccxml.loaded - CCXML Document Loaded Event

This event is generated for a newly loaded CCXML document to provide an opportunity for initialization. The CCXML platform should generate this event when the CCXML document is first loaded, both at session startup and after transferring control to a new document with the <goto> element. This event would be processed after the platform had executed the document initialization including executing any elements under the <ccxml> element.

The fields of this event are:

Section 7: Dialogs

Section 7.1: Overview

CCXML deals with all user interaction as "dialogs". Any time you want to perform an action where you interact with a caller you start a dialog on their session. Once a dialog has completed it can then return back to the CCXML session and the CCXML session can then make a decision on what to do next depending on what was returned.

Dialogs are not tied to any single dialog language. The requirements on a dialog language are very small and this could be implemented on anything from VoiceXML, SALT and even traditional IVR languages and platforms. Because of this a CCXML platform may support interaction with several dialog systems based on the mime type passed in at dialog startup.

CCXML treats starting a dialog as an asynchronous action meaning that when you start the dialog the control returns immediately back to the CCXML session and the CCXML session is notified of the result by an asynchronous event.

Section 7.2: elements

Section 7.2.1: <dialogstart>

Section 7.2.1.1: Overview

The <dialogstart> element is used to launch a dialog and associate it with an indicated call leg. The element includes a URI reference to a start-document for a dialog manager. The launched dialog executes on a separate thread of execution (may be a thread, process, or system depending upon platform implementation), not on CCXML's thread of execution. Once the dialog is kicked off, the CCXML script can immediately go back to handling incoming events.

The <dialogstart> element is used to launch a dialog, allocate a connection, associate the launched dialog with the allocated connection, and bridge the associated connection to another connection or to a conference. (See Section 10 for a discussion of connections and bridges.). The element includes a URI reference to a start-document for a dialog manager. The launched dialog executes on a separate thread of execution (may be a thread, process, or system depending upon platform implementation), not on CCXML's thread of execution. Once the dialog is kicked off, the CCXML script can immediately go back to handling incoming events.

The <dialogstart> element does not block execution of the CCXML script until the started dialog completes. The CCXML script regains control immediately. If the dialog cannot be started for any reason, an error.dialog.notstarted error event is thrown.

When the dialog completes, a "dialog.exit" event is posted to the event queue of the CCXML instance that launched it.

When the dialog is started if the dialog language allows access to telephony variables such as ANI, DNIS and UUI this will be propagated from the call leg to the dialog application.

If the "conid" attribute in the <dialogstart> specifies a connection rather than a conference, and if the dialog language allows access to telephony variables such as ANI, DNIS and UUI, values of these variables will be propagated from the specified connection to the dialog application.

Section 7.2.1.2: <dialogstart> Attribute Details

Section 7.2.2: <dialogterminate>

Section 7.2.2.1: Overview

A CCXML script may decide that it wants to destroy a current dialog. This is accomplished using the <dialogterminate> element in a CCXML script.

When the CCXML interpreter encounters a <dialogterminate> element, it sends a terminate event to the specified dialog.

Note that a <dialogterminate> request cannot be honored if the launched dialog is not yet in a ready state to receive it and act upon it. If this happens, a "error.dialog.wrongstate" event will be thrown.

When the CCXML application does a <dialogterminate> the dialog will still have a chance to return data to the CCXML application using a dialog.exit event. The details of how this mapping is done is up to the dialog language.

If you set the immediate attribute to true however the dialog does not get a chance to return data to the CCXML application and the CCXML application receives the "dialog.exit" event right away.

Section 7.2.2.2: <dialogterminate> Attribute Details

Section 7.3: Events

Section 7.3.1: Overview

CCXML and Dialogs do most of their communication using events. In the case where CCXML is receiving a event from a dialog it gets input into the CCXML applications event queue.

A CCXML application can also send a event to a dialog. How this is handled on the dialog side is dialog language dependent. On the CCXML side it is done by using the <send> element and passing in the dialogid that was received on the <dialogstart> element.

The following are the CCXML events that have to do with dialogs:

Section 7.3.2: dialog.started

This event is thrown when a dialog is started.

The fields of this event are:

Section 7.3.3: dialog.exit

This event is thrown when a dialog exits.

The fields of this event are:

Section 7.3.4: dialog.disconnect

This event is thrown when a dialog requests the call to be disconnected. It does not terminate the dialog but is only a request into the CCXML application to end the call.

The fields of this event are:

Section 7.3.5: dialog.transfer

This event is thrown when a dialog is requesting the call to be transferred.

The fields of this event are:

Section 7.3.6: error.dialog.notstarted

This event is thrown when a dialog can not be started for some reason.

The fields of this event are:

Section 7.3.7: error.dialog.wrongstate

This event is thrown when a dialog request was received and could not be completed because we are in a improper state.

The fields of this event are:

Section 7.3.8: dialog.user.*

This event is thrown when a dialog sends a user event to the CCXML application.

The fields of this event are:

Section 8: Variables and Expressions

Section 8.1: Overview

CCXML variables and expressions are similar to those in VoiceXML. All expressions must be valid ECMAScript expressions, assignable to variables with valid ECMAScript names. For more details please see section 3.4

Section 8.2: elements

Section 8.2.1: <assign> and <var>

Section 8.2.1.1: Overview

Variables are declared explicitly by the var element:

<var name="sessionid" />
<assign name="currentstate" expr="'initial'"/>

Variables declared without an explicit initial value are initialized to the ECMAScript undefined value. Variables must be declared before being used. However, see the <assign> element for a discussion of implicit declaration.

A variable is declared with the scope of the closest containing scope element. The fully-qualified name of a variable is the name of the variable's scope object prepended with a dot to the name of the variable. Within the attribute values of CCXML elements, variables can be referenced without their full qualification, which is implied. In the case of like-named variables declared in different scopes, the closest containing scope is implied, unless a fully-qualified variable name is used. If a variable is declared more than once, declarations subsequent to the first are considered to be assignments of the expr attribute initializer value to the variable. The default initializer is the ECMAScript value undefined .

Assignment to a variable which is undeclared at the point of the assignment implicitly declares that variable. The variable is declared in the scope of its closest containing scope element, and is known from the point of the assignment to the end of the scope. (See diagram)

Variables are declared using var element and assigned a value either at declaration time, or later through the assign element.

Section 8.2.1.2: Var Attribute Details

Section 8.2.1.3: Assign Attribute Details

Section 8.2.2: <script>

Section 8.2.2.1: Overview

The <script> element encloses computations written in the ECMAScript Compact Profile (ECMA-327) scripting language. For example, this <script> element defines a function that computes the greatest common factor of two integers:

<script>
<![CDATA[
function gcd(a, b)
{
 var t;
 if (a < 1 || b < 1)
   return -1;
 do
  {
   t = a % b;
   a = b;
   b = t;
  }
 while (b > 1);
 return (b == 0) ? a : b;
}
]]> 
</script>

A <script> element may occur in a <ccxml> element and in executable content. <transition> elements and <if> elements contain executable content. Script elements in a <ccxml> element are evaluated just after the document is loaded, along with the <var> and <assign> elements, in document order. Script elements in a <transition> element are evaluated as they are encountered. A <script> element in an <if> element is executed like other executable elements, as it is encountered.

A <script> element can declare variables with the ECMAScript var statement. Variables declared in this manner are in the scope of the closest containing scope element. They are known from the point of declaration to the end of the containing scope. The variables may be referenced with or without the qualification of their scope object. If a variable is declared more than once, declarations subsequent to the first are considered to be assignments of the initializer value to the variable. The default initializer is the ECMAScript value undefined

Section 8.2.2.2: script Attribute Details

Section 9: Event Handling

This section contains information on the <eventhandler>, <send>, <transition> and <move> elements.

Section 9.1: Event Concepts

Event Handling is one of the most powerful features of CCXML, and one way in which it is markedly different from VoiceXML. CCXML events have little to do with VoiceXML's events, such as nomatch or filled. VoiceXML events only occur within well-defined contexts, and are generated by the task at hand; it's impossible to receive a recognition-related event except within a field inside a form. CCXML events, however, can be delivered at any time and from a variety of sources. This flexible event-handling mechanism is essential for many telephony applications.

Every CCXML program can receive events. These might be in response to a previous action by the CCXML program (e.g., an outbound-call request, which generates an event to indicate when the call goes off-hook), or on the initiative of some external source (e.g., an incoming call to be answered). Events can be generated by the telephony system (as in the two previous examples), other CCXML programs (which emit events via the send element), or the CCXML recipient-interpreter (by sending an event to itself). There is a core set of telephony-related events (derived from the JTAPI/JCP/JCC event model. See JSR021 from the sun web site) that a browser must generate. Implementers are otherwise free to define and generate any platform-specific events they like. In addition, users/programmers may use the send element to send arbitrary events to external destinations, or may send arbitrary events to CCXML scripts from internal or external sources and may specify transition handlers to handle these events.

Every CCXML session can receive events. These might be in response to a previous action by the CCXML session (e.g., an outbound-call request, which generates an event to indicate when the call goes off-hook), or on the initiative of some external source (e.g., an incoming call to be answered). Events can be generated by the telephony system (as in the two previous examples), other CCXML session (which emits events via the send element), or the CCXML recipient-interpreter (by sending an event to itself). There is a core set of telephony-related events (derived from the JCC event model for connection objects. See JSR021 at java.sun.com for more information) that a browser must generate. Implementers are otherwise free to define and generate any platform-specific events they like. In addition, users/programmers may use the send element to send arbitrary events to external destinations, or may send arbitrary events to CCXML scripts from internal or external sources and may specify transition handlers to handle these events.

Each running CCXML interpreter has a queue, into which it places incoming events, and sorts them by arrival time along with any specified delay that has been requested. A CCXML programmer can only gain access to these queued events by using an eventhandler .

eventhandler elements are interpreted by an implicit Event Handler Interpretation Algorithm (EHIA). The EHIA's main loop removes the first event from the CCXML session's event queue, and then selects from the set of transition elements contained in the eventhandler . A transition element always indicates a set of accepted event types, and may indicate a further ECMAScript conditional expression to be evaluated. The transition element that accepts the type for the just-removed event, has a satisfied conditional expression (or none at all), and appears first in the eventhandler by document order, is the selected transition .

Once selected, the elements inside a transition element are executed in document order. At most, one transition will be chosen. If no transition elements meet all the criteria, none are selected and the event is simply dropped; the EHIA loop then starts over again, removing the event at the head of the queue. Any events that arrive while an event is already being processed are just placed on the queue for later. If the event queue is empty, and the EHIA wants to process an event, execution pauses until an event arrives.

Code inside an eventhandler should run "instantaneously", without blocking execution. This will allow events to be rapidly processed.

The only way for CCXML execution to leave an eventhandler is via an explicit goto inside a transition .

An eventhandler may also declare a state variable. An eventhandler 's state variable is used just as any other variable, but with a scope limited to the eventhandler and its elements. The eventhandler can be considered, and programmed as, a finite-state-automaton, with the state variable indicating the automaton's current state or node, and the transition elements, driven by incoming events, moving the machine to a new state and creating side effects along the way. We expect, but CCXML does not require, that each transition will contain an assignment to the state variable to drive the automaton to its next state.

Section 9.2: elements

Section 9.2.1: <eventhandler>

The <eventhandler> element acts a container for the <transition> elements. A valid CCXML document MUST only have a single <eventhandler> element.

Section 9.2.1.1: eventhandler Attribute Details

Eventhandler elements can contain only transition elements.

Section 9.2.2: <transition>

Section 9.2.2.1: transition Attribute Details

Section 9.2.3: <send>

Section 9.2.3.1: Overview

It's now clear how CCXML can receive, process, and respond to external events. But it's not obvious how CCXML can generate those events directly. For that, we need the send element. When the interpreter encounters a send , it will generate and deliver an event of the specified type to an indicated CCXML session. The set of addressable CCXML session is up to the browser implementer, but at least all CCXML session running within the same browser must be able to send events to each other.

Successful execution of the send element implies the event has been delivered to the event queue of the target CCXML session, however, the event will not be processed by the receiving session's eventhandler until any specified delay has elapsed. In the case of an event sent with a delay, the sending CCXML session need not continue executing after processing the send event, it is the responsibility of the receiving session to maintain the event on its queue until the delay has elapsed.

Section 9.2.3.2: send Attribute Details

Section 9.2.4: <move>

Section 9.2.4.1: Overview

The move element is used to add an event source to an executing CCXML session. An event source originates CCXML events. When an endpoint is added to a session, events originating from that endpoint will be delivered to that session's currently executing CCXML document.

The <move> element is used to move an event source (such as a Connection object) to an executing CCXML session. When an event source is moved to a session, events originating from that source will be delivered to that session's currently executing CCXML document. You MUST specify the "event" OR the "source" attribute. If you do not specify one or if you specify both a "error.ccxml" event will be thrown.

Section 9.2.4.2: <move> Attribute Details

Section 9.3: Event Transmission

Many useful applications are only possible when events can be passed to an arbitrary CCXML session, regardless of browser. For example, a user could be notified about a failed remote print job, or transferred to a now-available remote operator. Both scenarios involve events generated from a remote location and delivered over a network to a CCXML session. CCXML browsers must be able to dispatch such events correctly.

The protocol for communicating these events is now undetermined, but will eventually be specified so we can guarantee interoperability between CCXML. (HTTP and SIP are two options for network protocol.) Encoding options include SOAP and Xforms. Whatever we decide, the protocol we choose must allow for the following:

• Arbitrary string passing
• Encrypted and authenticated transmission
• Reliable transport
• Easy network operation

Section 9.4: Standard Events

CCXML can generate arbitrarily-named events. While any event name is possible, there is a small set of well-known events that are generated as a matter of course, and which any telephone application should handle. There are two kinds of these events: telephony events, which abstract interaction with the phone network, and language events.

The first, and larger set, is present so CCXML can keep abreast of what's happening with the telephone network. CCXML is designed to be neutral with respect to the telephony layer, so the event set we choose must be very generic and capable of describing the behavior of a wide variety of systems (e.g., Q931, SS7, VoIP, etc).

For now, we've chosen the JavaSoft JCP event model. It abstracts away many of the differences between the networks mentioned above, but does not offer much functionality. There may be better models than JCP, but it fits the bill for what we need at the moment: a small and easily-understood call model so we can write concrete sample programs. The ultimate choice of a standard model can be made later.

JCP was designed to be a cross-platform high-level event set to describe as generic a phone model as possible. The JCP/JCC call model consists of Addresses, Calls, Connections, and Providers. A Connection models the relationship between a single Call and a single Address. Neither value can change over the lifetime of the Call. A Call will maintain an association with zero or more Connections. It will have one Connection for every party in the call (so a two-party Call will have two Connections, and a four-party conference Call will have four).

All Calls are created by a Provider; the Call maintains an association with its Provider, which cannot change over the formers lifetime. Calls, Connections, and Providers all generate events, emitted when the object transitions to a new state.

We've focused on relatively simple types of call control, and we have tried to make the call control model in CCXML sufficiently abstract so that it can be implemented using all major telephony definitions such as JAIN Call Control (JCC), ECMA CSTA, and S.100.

We've chosen an event model for connections based on JCC (JSR 021). It abstracts away many of the differences between the networks mentioned above. There may be better models than JCC, but it fits the bill for what we need at the moment: a small and easily-understood call model so we can write concrete sample programs.

JCC was designed to be a cross-platform high-level event set to describe as generic a phone model as possible. The JCC call model consists of Addresses, Calls, Connections, and Providers. In the context of CCXML, we felt that the Address, Call, and Provider objects would add more complexity than value, so we omitted them as explicitly visible objects and focused on the behavior of Connections.

The CCXML call model therefore is based on the behavior of Connections. A call is received or initiated under control of a CCXML session through properties of a Connection.

In CCXML, a Connection is an object modeling a resource by which two independent unidirectional media streams, and optionally any associated network signaling traffic, can be controlled by a CCXML session. This corresponds roughly to a "call leg" as the term is used informally. <dialogstart> implicitly creates a Connection and bridges it to the Connection or Conference specified as an attribute of the <dialogstart> element. The behavior of Connections and bridges is discussed in Section 10.

Note that the JCC model is designed for endpoint devices only. Here is a fast description of the events. The descriptions and names are borrowed directly from the JavaSoft documentation.

Section 9.4.1: Connection Class

The state of a Connection object reflects events occurring at the telephony source it represents and actions taken by the CCXML document. The following state diagram shows the major aspects of Connection behavior, but omits some detail in favor of clarity.

The list of valid states that a connection can be in is:

• IDLE
• ALERTING
• PROGRESSING
• CONNECTED
• FAILED
• DISCONNECTED

Connections begin in the IDLE state and return to it when all other actions have been completed. The state diagram shows a DISCONNECTED state with a dotted line transition to IDLE. These states are essentially equivalent, IDLE/DISCONNECTED, and the dotted line transition occurs without the Connection emitting an event. Platforms may choose to implement one or both of these states.

• Transitions from IDLE/DISCONNECTED
  • connection.ALERTING event: the CCXML document is being notified of an incoming call; Connection transitions to ALERTING
  • <createcall> issued by the CCXML document; the Connection will emit a connection.PROGRESSING event and transition to PROGRESSING
• Transitions from ALERTING
  • <accept> issued by the CCXML document will connect the call; the Connection will emit a connection.CONNECTED event and transition to CONNECTED
  • <reject> issued by the CCXML document will reject the call; the Connection will emit a connection.FAILED event and transition to FAILED
  • <redirect> issued by the CCXML document will redirect the incoming call to another destination; the Connection will emit a connection.REDIRECTED event and transition to IDLE DISCONNECTED
    
  • a failure will result in a connection.FAILED event, and the Connection will transition to FAILED; the failure can occur before or after execution of CCXML elements
  • connection.ALERTING event if the network provides call progress indications
• Transitions from PROGRESSING
  • connection.CONNECTED event when the call is answered by the destination
  • connection.FAILED event when the call attempt is abandoned, which may indicate a busy, a no-answer, or other failure situation
  • connection.PROGRESSING event if the network provides call progress indications
• Transitions from CONNECTED
  • connection.DISCONNECTED event when the disconnect originates in the network; this requires not further action by the CCXML document;
  • <redirect> issued by the CCXML document will redirect the call to another destination; the Connection will emit a connection.REDIRECTED event and transition to IDLE/DISCONNECTED
  • <disconnect> issued by the CCXML document; the Connection will emit a connection.DISCONNECTED when the disconnect is completed.
  • connection.SIGNAL is emitted when additional Connection related information is available for processing by the CCXML application. The Connection remains in the CONNECTED state.
• Transitions from FAILED
  • the transition to IDLE DISCONNECTED will occur automatically after a short period of time, with no event emitted by the Connection, once the platform recovers from the failure
• Transitions from DISCONNECTED
  • Once a Connection enters DISCONNECTED, it transitions immediately to IDLE without further events being generated and without needing further action by the CCXML document

If a platform operational error occurs, the Connection will emit a connection.ERROR event, and transition to the ERROR state. A Connection will remain in the ERROR state until the error is corrected, and may then spontaneously transition to IDLE/DISCONNECTED. It will not transition to any other state from ERROR. The PROGRESSING and ALERTING states have reflexive transitions. This is intended to model protocols which have additional states at these points, and which may exchange messages such as PROCEEDING, ALERTING, FACILITY, or NOTIFY. Platforms may choose to implement addtional states which may be reflected in the substate property of the Connection object. Additional messages can be implemented with the CCXML <send> element.

Section 9.4.1.1: Connection Class Properties

An instance of the Connection class is associated with each telephony event source. Each instance is uniquely identified by its connection identifier. All Connection instances have a set of properties in common, shown in the following table. Properties marked with * only appear on an instance of the Connection class if they have a value. Other properties will always be present. Properties marked with + have been equated with those available in VoiceXML 2.0. In some cases, property names are slightly different in order to present the properties at a single level.

Connection Properties	Definitions
id	this property is the ECMAScript string value of the Connection identifier, which uniquely identifies each instance of the Connection class
state	this property identifies the current state of the Connection instance; the value of the state is a symbolic constant that is the name of the state
substate*	this property is a protocol-dependent property which allows further refinement of the state of a Connection, if desired
dialog*	this property is the identifier of an associated dialog, if there is one currently using the connection
local*+	this property is a URI which addresses the interpreter platform; for an incoming call, this is the called URI; for a redirected incoming call, this is also the most recent redirection, and the prior values are contained in the "redirect" property; for an outgoing call, this is the calling URI;
remote*+	this property is a URI which addresses the remote device; for an incoming call, this is the calling URI; for a redirected incoming call, this is the requestor of the most recent redirection, and prior values are contained in the "redirect" property; for an outgoing call, this is the called URI;
protocol*+	this property is a reference to an object defining protocol information for the protocol used on this connection; the referenced object defines information which applies to all connections using this protocol, and it has at least two properties: name - the name of the connection protocol; the name may also be a property on the connection instance referencing protocol specific information; if no further protocol specific information is available, then Connection[Connection.protocol.name] is undefined; (see Appendix F for a suggested set of protocol names) version - the version of the connection protocol For example, the assignment of protocol-dependent user-to-user information to a variable tmp from a Connection instance referenced by the variable cx would be: <assign name="tmp" expr="cx[cx.protocol.name].uui"/>
redirect*+	this property is an array representing the connection redirection paths; the first element, Connection.redirect[0], is the original number, and the last element is the most recent redirected number; each element of the array may define any of the following four properties: uri - this element's path pi - presentation information si - screening information reason - for example, "unknown", "user busy", "no reply", "deflection during alerting", "deflection immediate response", "mobile subscriber not reachable"
aai*+	this property is the application-to-application information passed during connection setup
originator*+	this property is set to either "local" or "remote" and indicates the originator of the connection; for an incoming call, this property is set to "remote"; for an outgoing call, it is set to "local"; For example, the assignment of the originating URI to a variable uri from a Connection instance referenced by the variable cx would be: <assign name="uri" expr="cx[cx.originator]"/>

Platforms may choose to add properties to Connection instances. By convention, the properties should begin with an underscore, "_", to identify them as platform-dependent.

Section 9.4.2: Connection Events

Section 9.4.2.1: connection.* Events

CCXML applications are notified of Connection activities by events, which often reflect Connection state changes. Applications may also take actions which change the state of a Connection and which cause other events to be generated.

All Connection events have a set of properties in common, shown in the following table. Fields marked with an asterisk only appear on the event object if they have a value. Other fields will always be present.

Common Field Names	Definitions
name	this property is set to the ECMAScript string value of the event name
connid	this property is the ECMAScript string value of the ID of the Connection object associated with this event
protocol*	this property is an ECMAScript string which identifies the protocol used by the event source; although this property is optional, it is recommended that platforms provide it in order to allow applications to tailor their behavior (see Appendix F for a suggested set of protocol identifiers)
info*	this property provides a reference to an object which may contain platform or protocol dependent information specific to the event
reason*	this property, although not provided by every event, when present provides a code indicating the status of the operation which triggered this event, or a reason for the occurrence of this event
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Platforms may choose to add properties to events. By convention, the properties should begin with an underscore, "_", to identify them as platform-dependent.

Platforms must provide a global method to convert symbolic connection identifiers, connid's, to object references. This method, connidReference(connid), takes a connection identifier as its only parameter and returns the object reference of the Connection object corresponding to the passed identifier, or null if the identifier does not refer to an instance of the Connection class. The connection property in the above table may be considered to be the result of calling this method with the connid property as its argument.

Section 9.4.2.2: connection.ALERTING

This event is emitted when a Connection transitions to the ALERTING state, or is notified of call progress in the ALERTING state.

The fields of this event are:

Field Name	Details
name	"connection.ALERTING"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
info*	An object which provides additional platform or protocol dependent information
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Information provided by the protocol prior to connection is accumulated and stored with the identified Connection object. This information will be available when the ALERTING event is delivered to the application.

Any further information provided by the protocol prior to connection will be provided in subsequent ALERTING events, and made available in the updated Connection object. Call related information provided after connection will result in connection.SIGNAL events.

Section 9.4.2.3: connection.PROGRESSING

This event is emitted when a Connection transitions to the PROGRESSING state as a result of <createcall>, or is notified of call progress in the PROGRESSING state.

The fields of this event are:

Field Name	Details
name	"connection.PROGRESSING"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
info*	An object which provides additional platform or protocol dependent information
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Section 9.4.2.4: connection.CONNECTED

This event is emitted when a Connection transitions to the CONNECTED state as a result of <accept>.

The fields of this event are:

Field Name	Details
name	"connection.CONNECTED"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
info*	An object which provides additional platform or protocol dependent information
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Section 9.4.2.5: connection.DISCONNECTED

This event is emitted when a Connection transitions to the DISCONNECTED state, as a result of either CCXML action or off-platform events.

The fields of this event are:

Field Name	Details
name	"connection.DISCONNECTED"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
reason*	A disconnection reason code
info*	An object which provides additional platform or protocol dependent information
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Section 9.4.2.6: connection.REDIRECTED

This event is emitted when a Connection transitions to the DISCONNECTED state as a result of <redirect>.

The fields of this event are:

Field Name	Details
name	"connection.REDIRECTED"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
reason*	A redirect result code.
info*	An object which provides additional platform or protocol dependent information
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Section 9.4.2.7: connection.FAILED

This event is emitted when a Connection transitions to the FAILED state, when an incoming or outgoing call fails to complete its connection.

The fields of this event are:

Field Name	Details
name	"connection.FAILED"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
reason*	A failure reason code
info*	An object which provides additional platform or protocol dependent information
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Section 9.4.2.8: connection.ERROR

This event is emitted when a Connection transitions to the ERROR state.

The fields of this event are:

Field Name	Details
name	"connection.ERROR"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
reason*	An error code if one is available
info*	An object which provides additional platform or protocol dependent information
connection	an ECMAScript object reference to the Connection object identified by the connid property for this event

Section 9.4.2.9: connection.SIGNAL

This event is emitted when a Connection is notified of new data available when in the CONNECTED state. The fields of this event are:

Field Name	Details
name	"connection.SIGNAL"
connid	The ID of the Connection associated with this event
protocol*	The platform protocol ID of the Connection protocol
info*	An object which provides additional platform or protocol dependent information

Examples where connection.SIGNAL could be generated include:

• DTMF received on the media stream after connection, perhaps identifying call setup information such as DNIS;
• Messaging received by the protocol after connection, such as that delivered by SIP INFO or ISDN FACILITY messages;
• Call analysis results indicating the results of answering machine, FAX, or modem detection attempt.

The data provided within the connection.SIGNAL event is protocol dependent. This data may be used to initiate a dialog (for example, if all required information is now available), or to message other platform components.

Signalling delivered on the media stream after a successful <dialogstart> may not be available to the CCXML application. This behavior is platform dependent.

All available call setup information is provided in the Connection object when the first connection.ALERTING event is generated. Any further information provided by the protocol prior to connection will be provided in subsequent ALERTING events, and made available in the updated Connection object. Call related information provided after connection will result in connection.SIGNAL events.

The Connection Object may be updated with new or changed information as the result of a connection.SIGNAL event.

Section 9.4.3: Standard Events

The second, smaller set, is only for language purposes. Of these, there are a) events sent from dialogs, and b) events sent from the CCXML interpreter. The standard events are described here.

• ccxml.loaded indicates that the script has just been completely loaded by the interpreter. This is a convenient time to perform script start-up processing.
• ccxml.fetch.done indicates that a CCXML fetch operation has completed.
• ccxml.joined indicates that a join operation has succeeded.
• ccxml.authenticated indicates that a <authenticate> operation has succeeded.

For dialog related events please see section 7.3 on dialog events.

    <transition event="error.*" name="evt">
      <log expr="'an error has occured (' + evt.error+ ')'" />
      <exit/>
    </transition>

Section 10: Telephony Operations and Resources

This section contains information on the <accept>, <createcall>, <createconference>, <destroyconference>, <disconnect>, <join>, <redirect>, <reject>, and <unjoin> elements.

The primary goal of CCXML is to provide call control throughout the duration of a call. Call control includes handling incoming calls, placing outgoing calls, bridging (or conferencing) multiple call legs, and ultimately disconnecting calls.

In CCXML, a Connection is an object modeling a resource by which two independent unidirectional media streams, and optionally any associated network signaling traffic, can be controlled by a CCXML session. This corresponds roughly to a "call leg" as the term is used informally.

The CCXML call model is based on the behavior of Connections. A network call is received or initiated under control of a CCXML session through properties of a Connection.

<dialogstart> implicitly creates a Connection and bridges it to another Connection or to a Conference specified as an attribute of the <dialogstart> element. In other words, to facilitate interaction between a network party and a dialog, two connections are required: one connection is associated with the network call, and the other connection is associated with the dialog.

Each Connection has one input by which it receives a media stream from another Connection or Conference.

Each Connection has one output media stream that can be directed to the inputs of multiple Connections and/or Conferences.

If a network call is active on a Connection, the media stream received from the network is the Connection output, and the Connection input media stream is transmitted to the network.

For a Connection created by <dialogstart>, the Connection input media stream is available to a recognizer under control of the CCXML session, and the Connection output media stream can be sourced from a resource (such as a TTS engine) under control of the CCXML session.

A "bridge" is a relationship between the input and/or output streams of connections or conferences. This is discussed in greater detail in Section 10.4.

Section 10.1: Incoming Calls

Section 10.1.1: Overview

One of the events a CCXML document can receive is a call setup indication. A CCXML session interested in handling incoming calls will have an eventhandler transition block for execution. The transition block will either accept, reject, or redirect the incoming call using the <accept>, <reject> or <redirect> CCXML elements. The underlying platform will signal the telephony system appropriately, depending on the element. Once the call is accepted, the CCXML document may initiate interactive dialog sessions with the incoming caller, or perform other telephony operations (e.g., place outgoing calls, join calls, etc).

Section 10.1.2: <accept>

Section 10.1.2.1: Overview

The <accept> element will accept and connect an incoming phone call.

Section 10.1.2.2: accept Attribute Details

Section 10.1.3: <redirect>

Section 10.1.3.1: Overview

The <redirect> element will redirect an incoming phone call.

Section 10.1.3.2: redirect Attribute Details

Section 10.1.4: <reject>

Section 10.1.4.1: Overview

The <reject> element will reject an incoming phone call.

Section 10.1.4.2: reject Attribute Details

<hold connid="currentCall" newconn="newID" alt="altStream"/><if cond="newID != undefined">
  <createcall use="newID" dest="'tel:+631-285-2583'"/>
  <join id1="newID" id2="currentCall"/>
</if>

Section 10.2: Outgoing Calls

Section 10.2.1: <createcall>

Section 10.2.1.1: Overview

A CCXML document can attempt to place an outgoing call with the createcall element. This element will instruct the platform to attempt to place an outgoing call to the indicated party. The element is non-blocking, and the CCXML document is immediately free to perform other tasks, such as initiating dialog interaction with another caller. The CCXML interpreter will receive an asynchronous event when the call attempt is completed. An event handler transition block can handle this event and perform further call control, such as conferencing. If the call was successfully placed, the transition block can also initiate a dialog interaction with the called party.

A CCXML document can attempt to place an outgoing call with the createcall element. This element will instruct the platform to allocate a Connection and attempt to place an outgoing call to a specified address. The element is non-blocking, and the CCXML document is immediately free to perform other tasks, such as initiating dialog interaction with another caller. The CCXML interpreter will receive an asynchronous event when the call attempt is completed. An event handler transition block can handle this event and perform further call control, such as conferencing. If the call was successfully placed, the transition block can also initiate a dialog interaction with the called party.

Section 10.2.1.2: createcall Attribute Details

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

             <var name="myConidVar"/>

             <createcall
                dest="'sip:+1-212-555-1212:1234@gateway.com;'"
                callerid="'sip:j.doe@big.com'"
                conid="myConidVar"
                aai="'This is application specific data'"
                hints="{callingDevice: 'notSpecified', callCharacteristics: 'voiceUnitCall'}" >
             </createcall>
         

Section 10.3: Conferencing

The CCXML <createconference> element can be used to create a conferencing object. This object is used to create multi-party conferences. Once created, the CCXML document can add call legs to the conference by using the join CCXML element. Call legs can be removed by issuing the unjoin element. A conference object can be destroyed using the destroyconference CCXML element. Asynchronous events will be sent to the CCXML document upon completion of each of these operations.

The CCXML <createconference> element can be used to create a conferencing object. This object facilitates multi-party conferences. Once a conference has been created, the CCXML document can add connections (call legs) to the conference by using the <join> element. Connections can be removed by using the <unjoin> element. (The <join> and <unjoin> elements are described in Section 10.4.). A conference object can be destroyed using the <destroyconference> CCXML element. Asynchronous events will be sent to the CCXML document upon completion of each of these operations.

The conference object models a special resource that mixes audio streams. Each Conference has one output and multiple inputs. The output stream of a Conference is derived by mixing all its input streams. The output of a Conference can be directed to the inputs of multiple Connections and/or Conferences (as a result of bridging).

Some telephony call control definitions do not define a separate conference object, instead defining a conference simply as a call with more than two parties. In order to accommodate the widest range of underlying telephony APIs, CCXML requires explicit use of a conference resource whenever two or more audio streams are mixed.

NOTE: A simple two-party call does not require the use of a conference object. This is discussed in Section 10.4.

Section 10.3.1: <createconference>

Section 10.3.1.1: createconference Attribute Details

Section 10.3.2: <destroyconference>

Section 10.3.2.1: destroyconference Attribute Details

Section 10.4: Bridging

In many situations, the CCXML document may want to create a simple, two party call. In these cases, a separate conference is not needed. Instead, the CCXML document can use the join CCXML element to bridge the two parties. The unjoin element can be used to unbridge a previously bridged call. Asynchronous events will be sent to the CCXML document upon completion of both the join and unjoin operations.

Note that it is possible to transition from a bridged two party call to a multi-party conference by first using the createconference CCXML element to create a conference object and then adding all of the parties to this conference. It is not possible to join a third call leg to an existing bridged call in order to create a 3-way call. If leg A is bridged to leg B, and then subsequently bridged to leg C, the result will be two 2-party calls, one between A and B and one between A and C.

Section 10.5: Disconnects

Section 10.5.1: <disconnect>

Section 10.5.1.1: Overview

A CCXML document may disconnect a call leg using the disconnect CCXML element. The underlying platform will send the appropriate protocol messages to perform the disconnect, and send an asynchronous event to the CCXML document when the disconnect operation completes.

A CCXML document may disconnect a call leg on a Connection by using the <disconnect> CCXML element. The underlying platform will sent the appropriate protocol messages to perform the disconnect, and send an asynchronous event to the CCXML document when the disconnect operation completes.

A CCXML document may also disconnect a dialog using the <disconnect> CCXML element. When a dialog is identified in the disconnect element, the dialog is notified of the disconnect occurrence. The dialog manager must always accept a disconnect notification, and does not provide a response.

Section 10.5.1.2: disconnect Attribute Details

A disconnected call will result in the generation of a connection.CONNECTION_DISCONNECTED event.

A disconnected call will result in the generation of a connection.DISCONNECTED event. A disconnect element must specify a callid attribute, a dialog attribute, or both.

Section 11: Security

Section 11.1: Overview

In some environments, it may be necessary to authenticate scripts with the execution platform, and vice-versa.

The first aspect of the trust relationship between the script and the platform is whether or not the document server (web server) trusts the platform making the URI request for a CCXML script. This can be strengthened by (1) requiring the platform to use HTTPS (SSL-encrypted HTTP) instead of cleartext HTTP to fetch the script; and (2) by requiring HTTP-style user authentication, i.e., userid and password.

Section 11.2: <authenticate>

Section 11.2.1: Overview

The second aspect is whether or not the platform trusts the script. This can be strengthened by requiring scripts to contain an <authenticate> element which provides information necessary to validate the script with the platform or an off-board authentication device such as a RADIUS server, SIP Proxy, or H.323 gatekeeper.

Section 11.2.2: authenticate Attribute Details

If the authentication is successful, a ccxml.authenticated event will be generated. If the authentication is unsuccessful, a ccxml.exit event will be generated, causing the script to terminate(ccxml.exit events cannot be caught or ignored).

Section 12: Examples

Example 1: Calling Card Application: Caller calls an 800 number and after some interaction with an IVR system places and outbound call to a friend.

-----------------
calling_card.ccxml

-----------------

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

<!DOCTYPE ccxml PUBLIC '-//W3C/DTD CCXML 1.0//EN' 'http://www.w3.org/TR/ccxml/ccxml.dtd' >

<ccxml xmlns="http://www.w3.org/2002/09/ccxml"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2002/09/ccxml 
   http://www.w3.org/TR/ccxml/ccxml.xsd" version="1.0">

  <!-- Create our ccxml level vars -->
  <var name="in_callid" expr="''" />
  <var name="out_callid" expr="''" />

  <!-- Set our initial state -->
  <assign name="currentstate" expr="'initial'" />

  <eventhandler statevariable="currentstate">
    <!-- Deal with the incoming call -->
    <transition state="initial" event="connection.ALERTING" name="evt">
      <assign name="in_callid" expr="evt.callid" />
      <accept callid="in_callid" />
    </transition>

    <transition state="initial" event="connection.CONNECTED" name="evt">
      <assign name="currentstate" expr="'in_vxml_session'" />
      <!-- VoiceXML dialog is started on a separate thread - see pin.vxml -->
      <dialogstart callid="in_callid" src="'pin.vxml'" />
    </transition>

    <!-- happens when pin.vxml VoiceXML dialog thread exits -->
    <transition state="in_vxml_session" event="dialog.exit" name="evt">
      <createcall dest="evt.values.telnum" name="out_callid" />
      <assign name="currentstate" expr="'calling'" />
    </transition>

    <transition state="calling" event="connection.FAILED" name="evt">
      <!-- tell the caller there was a error -->
      <dialogstart callid="in_callid" src="'error.vxml'" />
      <assign name="currentstate" expr="'oub_failed'" />
    </transition>

    <!-- happens when called party picks up the phone -->
    <transition state="calling" event="connection.CONNECTED" name="evt">
      <assign name="out_callid" expr="evt.callid" />
      <!-- tell the callee he is receiving a call -->
      <dialogstart callid="out_callid" src="'callee.vxml'" />
      <assign name="currentstate" expr="'outb_ready_to_join'" />
    </transition>

    <transition state="oub_failed" event="dialog.exit" name="evt">
      <exit />
    </transition>

    <!-- happens when callee's vxml dialog (callee.vxml exits) -->
    <transition state="outb_ready_to_join" event="dialog.exit" name="evt">
      <join id1="in_callid" id2="out_callid" />
      <assign name="currentstate" expr="'wtg_for_joined'" />
    </transition>

    <transition state="wtg_for_joined" event="ccxml.joined" name="evt">
      <assign name="currentstate" expr="'active'" />
    </transition>

    <!-- Lets clean up the call  -->
    <transition state="active" event="connection.DISCONNECT" name="evt">
      <if cond="evt.callid == in_callid">
        <disconnect callid="out_callid"/>
        <exit />
      </if>
      <assign name="currentstate" expr="'in_vxml_session'" />
      <!-- start VoiceXML dialog again to see
        if caller wants to make another call -->
      <dialogstart callid="in_callid" src="'pin.vxml'" />
    </transition>

    <!-- Catch disconnects in unexpected states -->
    <transition event="connection.DISCONNECT">
      <exit />
    </transition>
  </eventhandler>
</ccxml>
----------------------
pin.vxml

-------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form id="pin">
    <block> Welcome to Acme's Calling Card </block>
    <field name="pin" type="digits">
      <prompt> Please say your PIN number </prompt>
      <filled>
        <if cond="pin.length != 8">
          <clear namelist="pin"/>
        <else/>
          <assign name="application.pin" expr="pin" />
          <submit next="checktime.asp" namelist="pin"/>
        </if>
      </filled>
    </field>
  </form>
</vxml>
-------------------------
error.vxml

--------------------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <block> 
        Sorry. The Party you are trying to call
        is unavailable. 
        <exit/>
    </block>
  </form>
</vxml>
-----------------------
callee.vxml

---------------------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <block>You have a call. Connecting</block>
  </form>
</vxml>
----------------vxml doc output by 
checktime.asp

---------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form id="form2">
    <!--.asp consults back-end database before filling this value-->
    <assign name="timeleft" expr="600"/>  
    <block> Time remaining is <value expr="timeleft"/> seconds </block>
    <field name="telnum" type="digits" >
      <prompt> Please speak the telephone number you want to call </prompt>
      <filled>
        <if cond="telnum.length != 7">
          <clear namelist="telnum"/>
        <else/>
          <exit namelist="telnum"/>
        </if>
      </filled>
    </field>
  </form>
</vxml>

Example 2: Conferencing application. Different callers call into a conference through an agreed upon telephone number. When each one of them joins the conference he is told how many people are there in the conference and those already in the conference are informed about a new entrant to the conference. Similarly when someone hangs up, the fact that a conference participant has exited is announced. A conference object is created at the beginning of the conference and is destroyed when all the participants have hung up.

<!-- 
First page

 to all callers -->


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

<ccxml version="1.0">
  <var name="in_callid" expr="''"/>
  <var name="currentstate" expr="'initial'"/>
  
  <eventhandler statevariable="currentstate">
    <transition state="initial" event="connection.ALERTING" name="evt">
        <assign name="currentstate" expr="'alerting'"/>
        <assign name="in_callid" expr="evt.callid"/>
        <accept callid="in_callid"/>
    </transition>

    <transition state="alerting" event="connection.CONNECTED" name="evt">
        <assign name="currentstate" expr="'fetching'"/>
        <fetch next="'http://acme.com/conference.asp'" namelist="in_callid"/>
    </transition>

    <transition state="fetching" event="fetch.done" name="evt">
        <goto fetchid="evt.fetchid"/>
    </transition>

</eventhandler>
</ccxml>

==========================================================================
<!-- 
ccxml page returned by conference.asp to first caller's
browser

-->

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

  <var name="conf_id" expr="'''"/>
  <var name="currentstate" expr="'starting'"/>
  <var name="in_callid" expr="'0f0c0d@host1.com'"/>
  <!-- above value is the value submitted to conference.asp-->

<eventhandler statevariable="currentstate">

    <transition state="starting" event="ccxml.loaded" name="evt">
        <createconference id="conf_id"/>
    </transition>

    <transition state="starting" event="ccxml.conferencecreated" name="evt">
        <assign name="currentstate" expr="'fetching'"/>
        <fetch next="'http://acme.com/conference.asp'" namelist="in_callid conf_id"/>
    </transition>

    <transition state="fetching" event="fetch.done" name="evt">
        <goto fetchid="evt.fetchid"/>
    </transition>

</eventhandler>
</ccxml>

==========================================================================
<!-- 
ccxml page returned by conference.asp to all callers


(incl first after the above page to create a conference has
been sent to the first caller) -->

<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0">
  <var name="currentstate" expr="'ready_to_conf'"/>
  <var name="in_callid" expr="'ff0d01@host2.com'"/>
  <var name="conf_id" expr="'0a4602@host1.com'"/>

    <!-- above values are the values submitted to conference.asp-->
    <eventhandler statevariable="currentstate">

    <transition event="ccxml.loaded" name="evt">
        <dialogstart callid="in_sessionid" src="'vconference.asp'"/>
        <join id1="conf_id" id2="in_callid" />
        <dialogstart callid="conf_id" src="'newcaller.vxml'"/>
        <assign name="currentstate" expr="'active'" />
    </transition>

    <transition state="active" event="connection.DISCONNECTED" name="evt">
      <dialogstart callid="conf_id" src="'leave.vxml'"/>
      <assign name="currentstate" expr="'fetching'"/>
      <fetch next="'http://acme.com/teardown.asp'" namelist="in_callid conf_id"/>
    </transition>

    <transition state="fetching" event="fetch.done" name="evt">
        <goto fetchid="evt.fetchid"/>
    </transition>
</eventhandler>
</ccxml>


==========================================================================
<!-- vxml page 
vconference.asp

 -->

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
<form>
  <block> Welcome to the W3C conference. There are already
          <value expr="'3'"/> participants in the conference.
          <!--above value is based on count kept by vconference.asp-->
  </block>
</form>
</vxml>


==========================================================================
<!-- vxml page 
newcaller.vxml

 -->

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
    <form>
        <block> A new participant has entered the conference. </block>
    </form>
</vxml>

==========================================================================
<!-- vxml page 
leave.vxml

 -->

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
    <form>
        <block> Someone just left the conference. </block>
    </form>
</vxml>

==========================================================================
<!-- 
ccxml page returned by teardown.asp to all but the last
participant

 -->

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

<ccxml version="1.0">
  <var name="currentstate" expr="'destroying'"/>
  <var name="conf_id" expr="'0a4602@host1.com'"/>
  <var name="in_callid" expr="'ff0d01@host2.com'"/>
  <!-- above values are the values submitted to teardown.asp-->
    <eventhandler statevariable="currentstate">
    <transition event="ccxml.loaded" name="evt">
      <exit/>     <!-- just exit and destroy the session -->
    </transition>
  </eventhandler>
</ccxml>


==========================================================================
<!-- 
ccxml page returned by teardown.asp to last participant

 -->

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

<ccxml version="1.0">
  <assign name="currentstate" expr="'destroying'"/>
  <assign name="conf_id" expr="'0a4602@host1.com'"/>
  <assign name="in_sessionid" expr="'ff0d01@host2.com'"/>
    <!-- above values are the values submitted to teardown.asp -->
    <eventhandler statevariable="currentstate">
    <transition event="ccxml.loaded" name="evt">
      <destroyconference id="conf_id"/>
      <exit/>
    </transition>
  </eventhandler>
</ccxml>

Example 3: Call Center Customer Support Interactions Acme customer support line wants to run a customer information and support service which allows users to call in, interact with an automated menu system using DTMF and voice. When the customer reaches a menu which requires an operator, the customer is placed in a hold queue for an available operator.

Alternatively, if the customer requests an operator at any point Acme would like to allow the customer to either wait for an operator, or continue navigating the system while in the hold queue. If the customer continues interacting with the automated system while waiting, Acme would like to be able to interrupt periodically with status about the hold queue and offer the customer the option of canceling their request if their question has been answered by the automated system. When an operator is available, the customer's interactions are stopped and the operator is connected.

For training purposes, Acme would also like to be able to have a trainer listening when the customer is connected to the operator and the operator presses a special key to get the help of the trainer. This trainer could interrupt and provide hints to the new operator about how to answer the question. The customer would not be able to hear these hints.

----------------------
main.ccxml

-------------------------------

<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0">
  <var name="in_callerid"/>
  <var name="in_callid"/>
  <var name="out_callid"/>
  <var name="sup_callid"/>
  <var name="dlg_queue"/>
  <assign expr="'initial'" name="currentstate"/>
  <assign expr="'default'" name="queuemode"/>
  <eventhandler statevariable="currentstate">
  <transition event="connection.ALERTING" name="evt" state="initial">
    <!-- happens when the customer first calls the call center's 800 number -->
    <assign expr="evt.remote" name="in_callerid"/>
    <assign expr="evt.local" name="in_session"/>
    <assign expr="evt.callid" name="in_callid"/>
    <accept/>
  </transition>
  <transition event="connection.CONNECTED" name="evt" state="initial">
    <!-- happens if our incoming call is finally connected -->
    <assign expr="'in_mainchoice'" name="currentstate"/>
    <!-- start a VoiceXML dialog with the caller (see mainchoice.vxml below) -->
    <dialogstart dialogid="dlg_mainchoice" src="'http://acme/mainchoice.vxml'"/>
  </transition>
  <transition event="dialog.exit" name="evt" state="in_mainchoice">
    <!-- happens when mainchoice.vxml dialog exits -->
    <if cond="evt.mainchoice == 'agent'">
      <assign expr="in_callerid" name="caller_telnum"/>
      <fetch namelist="caller_telnum" next="'http://acme/queue_call.asp'"/>
    </if>
    <!-- assume queue_call.asp (not shown) will interact with the
      call-center's call-queuing system to queue the call. It will also
      send queue status to ccxml session when it receives one from the
      call-queuing system and inform the ccxml session when an agent is
      is available through an inter-browser communication mechanism. 
      Note that we do this fetch but we never do a goto to transition
      to this document. This also may be able to be done using
      the <send/> element instead. This needs to be better documented. -->
    <assign expr="'in_queue'" name="currentstate"/>
    <dialogstart dialogid="dlg_queue" callid="in_callid" src="'queue1.vxml'"/>
  </transition>
  <transition event="user.status" name="evt" state="in_queue">
    <!-- happens when status is received from an external program.
      Exit the customer's IVR interaction to announce the status of the
      queue -->
    <dialogterminate dialogid="dlg_queue"/>
  </transition>
  <transition event="dialog.exit" name="evt" state="in_queue">
    <!-- happens when we either exited the IVR interaction or the
      queue status, so depending on the queue mode we fall back in either
      one of them -->
    <if cond="queuemode == 'default'">
      <assign expr="'status'" name="queuemode"/>
      <dialogstart dialogid="dlg_queue" callid="in_callid" src="'queuestat.asp'"/>
    <else/>
      <assign expr="'default'" name="queuemode"/>
      <dialogstart dialogid="dlg_queue" callid="in_callid" src="'queue1.vxml'"/>
    </if>
  </transition>
  <transition event="user.agent_avail" name="evt" state="in_queue">
    <!-- happens if an agent is finally available, so we try
      to connect to her/him -->
    <createcall dest="evt.telnum" name="out_callid"/>
    <assign expr="'calling'" name="currentstate"/>
  </transition>
  <transition event="connection.CONNECTED" name="evt" state="calling">
    <!-- happens when agent is connected and picks up the phone,
      so we have to terminate the queue dialog -->
    <assign expr="evt.callid" name="out_callid"/>
    <dialogterminate dialogid="dlg_queue"/>
  </transition>
  <transition event="dialog.exit" name="evt" state="calling">
    <assign expr="'conversing'" name="currentstate"/>
    <dialogstart callid="out_callid" src="'agent.asp'"/>
    <join duplex="'full'" id1="in_callid" id2="out_callid"/>
  </transition>
  <transition event="user.conf_supervisor" name="evt" state="conversing">
    <!-- connect to the supervisor -->
    <createcall dest="evt.telnum" name="sup_callid"/>
  </transition>
  <transition event="connection.CONNECTED" name="evt" state="conversing">
    <join duplex="'half'" id1="in_callid" id2="sup_callid"/>
    <!-- supervisor can hear the customer
      but customer can't hear supervisor -->
    <join duplex="'full'" id1="out_callid" id2="sup_callid"/>
    <!-- agent and supervisor can hear each other -->
    <assign expr="'coaching'" name="currentstate"/>
  </transition>
  <transition event="connection.DISCONNECTED" name="evt" state="coaching">
    <if cond="evt.callid==sup_callid">
      <!-- the supervisor hung up, kick out the supervisor -->
      <unjoin id1="in_callid" id2="sup_callid"/>
      <unjoin id1="out_callid" id2="sup_callid"/>
      <disconnect callid="sup_callid"/>
      <assign expr="'conversing'" name="currentstate"/>
    <else/>
      <!-- the customer or agent hung up -->
      <exit/>
    </if>
  </transition>
  <transition event="connection.DISCONNECTED" name="evt">
    <!-- this cleans up all call legs and conference objects -->
    <exit/>
  </transition>
  </eventhandler>
</ccxml>

----------------------
mainchoice.vxml

-------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <field name="mainchoice" >
      <prompt>Please press or say 0 to talk to an agent,
      1 for self service</prompt>
      <option dtmf="0" value="agent"> zero </option>
      <option dtmf="1" value="self" > one  </option>

      <filled>
        <if cond="mainchoice=='agent'">
          <exit namelist="mainchoice"/>
        <else/>
          <goto next="http://acme/ivr.vxml" /> <!-- not shown -->
        </if>
      </filled>
    </field>
  </form>
</vxml>

----------------------
queue1.vxml

-------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <block>All our customer service agents are busy right now.
    Your call will be answered in the order that it was received.
    We will connect you to an agent when one becomes available.
    Meanwhile you can continue to use our automated system.
    <goto next="http://acme/ivr.vxml"/>
    </block>
  </form>
</vxml>

----------------------
queuestat.asp

-------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <block>
    All our customer service agents are still busy. There are
     <value expr="num_queued"/> callers ahead of you in the
     queue. If the automated system has answered your question,
     you can hangup. Otherwise please continue to hold.
    </block>
  </form>
</vxml>

----------------------
agent.asp

-------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <field name="attnkey" type="digits">
      <!-- give the agent the ability to contact supervisor
      by hitting the '#' key -->
      <option dtmf="#" value="supervisor" />
      <filled>
        <if cond="attnkey==supervisor">
          <send event="conf_supervisor" dest="ccxml" />
        <else />
          <clear namelist="attnkey" />
        </if>
      </filled>
    </field>
  </form>
</vxml>

Example 4: Personal Assistant. This program is a Personal Assistant that operates as an automated answering service.

A subscriber to this service would receive a phone number to the automated service. When a caller wants to talk to the subscriber, he calls the given number. This automated system asks who the caller is, and records the audio. Then the system calls the current number of the target person, and asks if the call should be connected.

If so, the calls are bridged. If not, then the original caller is warned and disconnected.

----------------------
main.ccxml

-------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0">
    <var expr="'initial'" name="currentstate"/>
    <var name="in_callid"/>
    <var name="dlg_onhold"/>
    <var name="out_callid"/>
    <var name="accepted"/>
    <eventhandler statevariable="currentstate">
        <transition event="connection.ALERTING" name="evt" state="initial">
            <assign expr="evt.callid" name="in_callid"/>
            <accept/>
        </transition>
        <transition event="connection.CONNECTED" name="evt" state="initial">
            <assign expr="'welcoming_caller'" name="currentstate"/>
            <dialogstart src="'welcome_message.vxml'"/>
        </transition>
        <transition event="dialog.exit" state="welcoming_caller">
            <!-- place the caller on hold -->
            <dialogstart dialogid="dlg_onhold" callid="in_callid" src="'holdmusic.vxml'"/>
            <!-- Contact the target.  The number here is server-generated -->
            <assign expr="'contacting_target'" name="currentstate"/>
            <createcall dest="'tel:+16505551212'" name="out_callid"/>
        </transition>
        <transition event="connection.CONNECTED" name="evt" state="contacting_target">
            <!-- Ask the target if (s)he would like to accept the call -->
            <assign expr="'waiting_for_target_answer'" name="currentstate"/>
            <dialogstart src="'outbound_greetings.vxml'"/>
        </transition>
        <transition event="dialog.exit" name="evt" state="waiting_for_target_answer">
            <assign expr="evt.accepted" name="accepted"/>
            <if cond="accepted == 'false'">
                <!-- disconnect the called party (but still notify the other one) -->
                <disconnect callid="out_callid"/>
            </if>
            <assign expr="'stop_hold'" name="currentstate"/>
            <dialogterminate dialogid="dlg_onhold"/>
        </transition>
        <transition event="dialog.exit" name="evt" state="stop_hold">
            <if cond="accepted == 'false'">
                <dialogstart callid="in_callid" src="'vm.vxml'"/>
           <else/>
                <assign expr="'playing_connecting'" name="currentstate"/>
                <dialogstart callid="in_callid" src="'connecting.vxml'"/>
            </if>
        </transition>
        <transition event="dialog.exit" name="evt" state="playing_connecting">
            <join id1="in_callid" id2="out_callid"/>
            <assign expr="'talking'" name="currentstate"/>
        </transition>
        <transition event="connection.DISCONNECTED" name="evt">
            <if cond="evt.callid == in_callid">
                <exit/>
            </if>
        </transition>
    </eventhandler>
</ccxml>

-----------------
welcome_message.vxml

-----------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <record name="recording">
      <prompt>
        This is the Personal Assistant.
        Please state your name.
      </prompt>
      <filled>
        OK, thanks.
        <submit next="postRecordingAndExit.vxml"
        namelist="recording"/>
      </filled>
    </record>
  </form>
</vxml>

-----------------
outbound_greetings.vxml

-----------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
  <form>
    <field id="answer">
      <grammar src="yesnogrammar"/>
      <prompt>
        <audio>Hi, you have a message from</audio>
        <audio src="dynamicallyRecordedName.wav"/>
        <audio> Would you like to take it?  Say Yes, or No.</audio>
      </prompt>

      <filled>
        <if cond="answer==yes">
          <audio>OK, connecting.</audio>
          <assign name="willaccept" value="true"/>
          <exit namelist="willaccept"/>
        <elseif cond="answer==no" />
          <audio>OK, goodbye. </audio>
          <assign name="willaccept" value="false"/>
          <exit namelist="willaccept"/>
        </if>
      </filled>
    </field>
  </form>
</vxml>

-----------------
vm.vxml

-----------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
    <form>
      <prompt>Transferring you to voice mail. </prompt>
      <block>
        <goto next="voicemail.vxml" />
      </block>
    </form>
</vxml>

-----------------
connecting.vxml

-----------------
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
    <form>
      <prompt>Your party is ready.  Connecting... </prompt>
      <block>
        <exit />
      </block>
    </form>
</vxml>

-----------------
holdmusic.vxml

-----------------

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0">
    <form id="Form">
        <block>
            <prompt bargin="false">
                Laa Laa Laa Laa. Don't you love this funky beat. 
                Laa Laa Laa Laa. Don't you love this funky beat. 
            </prompt>
            <goto next="holdmusic.vxml"/>
        </block>
    </form>
</vxml>


<!-- postRecordingAndExit.vxml writes and exposes the WAV file,
and then exits.  It's not interesting enough to include here. -->

Appendix B - Related Work

CPL

The Call Processing Language (CPL) is an XML based language that can be used to describe and control Internet telephony services. Its focus is user scripting of call handling behavior for incoming calls. It is designed to be suitable for running on a server where users may not be allowed to execute arbitrary programs, and so is not Turing-complete.

The latest version of CPL can be found linked from the IETF IP Telephony (IPTEL) working group charter page .

CallXML

CallXML is a markup language created by Voxeo corporation that includes both voice and call-control functionality. Most of the following is from the CallXML 2.0 specification: CallXML is an XML based markup language used to describe the user interface of a telephone, voice over IP, or multi-media call application to a CallXML browser.

CallXML was designed to make it easy for web developers to create applications that can interact with and control any number or type of calls, including:

• Telephone or Voice over IP call applications which can control the initiation and routing of a phone call itself, supporting such features as outbound dialing, conferencing, and multi-call interactions (e.g., conference bridges, internet call waiting, follow-me/find-me, etc)
• Telephone or Voice over IP call applications which can easily interact and respond to touch-tone based entry and selection (e.g., voicemail, interactive voice response)
• Call Applications which include support for additional media, such as faxes and video (e.g., unified messaging, video conferencing, etc.)

VoiceXML is designed to make it easy for web developers to create voice recognition based interfaces for either telephones or computer-based applications. As such, VoiceXML is an excellent solution for voice based applications which provide access to web content and information, including:

• Applications which allow users to retrieve web content via phone (e.g., voice portals, web-by-phone, audiotex)
• Applications which allow users to interact with web based services using spoken commands (e.g., stock quotes, sports scores)

Because of the natural complexity associated with dealing with voice commands, VoiceXML uses a relatively complex form/field/grammar/filled interface model in its design. In contrast, CallXML uses a more simplified block / action / event interface model, which can be easier to learn and which allows for visual design tools which directly represent CallXML markup as simple flow-chart like user interfaces. See http://community.voxeo.com

    "CSTA specifies an Applications Interface and Protocols for monitoring and 
    controlling calls and devices in a communications network.  

    These calls and devices may support various media and can reside in various network 
    environments such as IP, Switched Circuit Networks and mobile networks.  
    CSTA however, abstracts various details of underlying signalling protocols 
    (e.g. SIP/H.323) and networks for the applications."

TXML

TXML (Telera's Extensible Markup Language) is an XML based language designed by Telera for remotely controlling the behavior of Point of Presence (POP)call-centers. The POP call-center system is a Telera invention capable of answering, servicing, queuing and routing of calls at local points of presence to reduce communication costs of toll-free inbound contact centers.

TXML provides the syntax for the XML Pages, which are generated at the customer's application at the premises and used by a POP server to execute actions on behalf of the customer's contact center . The XML Pages are simple ASCII text files that are either stored in a Web server's directory at the premises or generated by scripts at the premises server. The XMLPages are requested from the premises server via HTTP requests made by a client on the POP gateway.

The language includes elements for

• Media Control
• Call Control and Telephony
• Call Router Integration

Go here for more Telera documentation.

SIP

SIP, the Session Initiation Protocol, is a signaling protocol for Internet conferencing, telephony, presence, events notification and instant messaging. As a signaling protocol, SIP sits "below" the application description level of VoiceXML and CCXML. We expect many CCXML and VoiceXML browsers to support SIP signaling. (These same comments apply to H.323 and MGCP/Megaco.)

Dynamicsoft has described a method for an application server to utilize a VoiceXML browser as a network resource. This is an interesting approach, but there still needs to be a mechanism for describing the call-control logic. An application server product from dynamicsoft provides language bindings in Java Servlets, CPL, and a general CGI interface.

See http://www.dynamicsoft.com/prod_sol/downloads/pdf/AppEngineNwkDecompMdl.pdf

Appendix C - CCXML DTD

Here is the CCXML DTD for your reference.

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

<!ENTITY % uri "CDATA">

<!ENTITY % version "NMTOKEN">

<!ENTITY % esvar "NMTOKEN">

<!ENTITY % esvars "CDATA">

<!ENTITY % expression "CDATA">

<!ENTITY % boolean "(true | false)">

<!ENTITY % content.type "CDATA">

<!ENTITY % duration "CDATA">

<!ENTITY % string "CDATA">


<!ENTITY % executable.content "accept | createcall | join | unjoin | createconference |
destroyconference | dialogstart | dialogterminate | send | disconnect | assign | var | script | if
| goto | fetch |  exit | redirect | move">


<!ELEMENT accept EMPTY>
<!ATTLIST accept  
    callid %expression;  '_event.callid' 
>

<!ELEMENT authenticate EMPTY>
<!ATTLIST authenticate  
    server  %expression;  #REQUIRED
    userid   %expression;  #REQUIRED
    password %expression;  #REQUIRED 
>

<!ELEMENT assign EMPTY>
<!ATTLIST assign  
    name %esvar;  #REQUIRED
    expr %expression;  #REQUIRED 
>

<!ELEMENT ccxml (authenticate | assign | var | eventhandler | script)* >
<!ATTLIST ccxml  
    version %version;  #REQUIRED 
>

<!ELEMENT createcall EMPTY>
<!ATTLIST createcall  
    dest %expression;   #REQUIRED 
    name %esvar;            #IMPLIED
>

<!ELEMENT createccxml EMPTY>
<!ATTLIST createccxml  
    fetchid %expression;  #REQUIRED 
    start %expression;  #IMPLIED 
    sessionid %esvar;  #IMPLIED 
>

<!ELEMENT createconference EMPTY>
<!ATTLIST createconference  
    id  %esvar;  #REQUIRED 
>

<!ELEMENT destroyconference EMPTY>
<!ATTLIST destroyconference  
    id %expression; #REQUIRED 
>

<!ELEMENT dialogstart EMPTY>
<!ATTLIST dialogstart  
    callid   %expression;    '_event.dialogid'
    src      %expression;           #REQUIRED
    type     %content.type;  'application/xml+vxml'
    namelist %esvars;         #IMPLIED
    dialogid %esvar;         #IMPLIED
>

<!ELEMENT dialogterminate EMPTY>
<!ATTLIST dialogterminate  
    dialogid  %expression;  '_event.dialogid'
    immediate  (true | false )  'false' 
>

<!ELEMENT disconnect EMPTY>
<!ATTLIST disconnect  
    callid %expression;  '_event.callid' 
    reason %expression;  #IMPLIED
>

<!ELEMENT else (%executable.content; | elseif | else)*>

<!ELEMENT elseif (%executable.content; | elseif | else)*>
<!ATTLIST elseif  
    cond %expression;  #REQUIRED 
>

<!ELEMENT eventhandler (transition)*>
<!ATTLIST eventhandler  
    id    ID       #IMPLIED
    statevariable  %esvar;  #REQUIRED 
>


<!ELEMENT exit EMPTY>
<!ATTLIST exit  
    expr     %expression;   '0'
    namelist %esvars;  #IMPLIED 
>

<!ELEMENT fetch EMPTY>
<!ATTLIST fetch  
    next     %expression;   #REQUIRED
    namelist %esvars;  #IMPLIED 
    method (get | post) 'get'
    fetchid %esvar; #IMPLIED
    sync %esvar; #IMPLIED
>

<!ELEMENT goto EMPTY>
<!ATTLIST goto  
    fetchid  %expression;  #REQUIRED 
>

<!ELEMENT if (%executable.content; | elseif | else)*>
<!ATTLIST if  
    cond %expression;  #REQUIRED 
>

<!ELEMENT join EMPTY>
<!ATTLIST join  
    id1    %expression;  #REQUIRED
    id2    %expression;  #REQUIRED
    duplex  %expression;  'full' 
>

<!ELEMENT move EMPTY>
<!ATTLIST move   
    endpoint    %expression;     #IMPLIED
    event       %expression;        #IMPLIED
    sessionid   %expression;     #REQUIRED
>

<!ELEMENT redirect EMPTY>
<!ATTLIST redirect  
    callid %expression;  '_event.callid'
    dest   %expression;    #REQUIRED
    reason %expression;  #IMPLIED 
>

<!ELEMENT reject EMPTY>
<!ATTLIST reject  
    reason %expression;  #IMPLIED
    callid %expression;  '_event.callid' 
>


<!ELEMENT script (#PCDATA)*>
<!ATTLIST script  
    src %expression;  #IMPLIED 
>

<!ELEMENT send EMPTY>
<!ATTLIST send  
    event    %expression;        #REQUIRED
    target   %expression;             #IMPLIED
    name     %expression;        #IMPLIED
    delay    %duration;     #IMPLIED
    namelist %esvars;  #IMPLIED 
>


<!ELEMENT transition (%executable.content;)*>
<!ATTLIST transition  
    state %string;       #IMPLIED
    event %expression;       #REQUIRED
    cond  %expression;  #IMPLIED
    name  %esvar;       #IMPLIED
>


<!ELEMENT unjoin EMPTY>
<!ATTLIST unjoin  
    id1 %expression;  #REQUIRED
    id2 %expression;  #REQUIRED 
>

<!ELEMENT var EMPTY>
<!ATTLIST var  
    name %esvar;  #REQUIRED
    expr %expression;  #IMPLIED 
>

Appendix D - CCXML Schema

Here is the CCXML Schema for your reference.

<?xml version = "1.0" encoding = "UTF-8"?>
<xsd:schema xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema">
    <xsd:group name = "executable.content">
        <xsd:choice>
            <xsd:element ref = "accept"/>
            <xsd:element ref = "createcall"/>
            <xsd:element ref = "join"/>
            <xsd:element ref = "unjoin"/>
            <xsd:element ref = "createconference"/>
            <xsd:element ref = "destroyconference"/>
            <xsd:element ref = "dialogstart"/>
            <xsd:element ref = "dialogterminate"/>
            <xsd:element ref = "send"/>
            <xsd:element ref = "disconnect"/>
            <xsd:element ref = "assign"/>
            <xsd:element ref = "var"/>
            <xsd:element ref = "script"/>
            <xsd:element ref = "if"/>
            <xsd:element ref = "goto"/>
            <xsd:element ref = "fetch"/>
            <xsd:element ref = "exit"/>
            <xsd:element ref = "redirect"/>
            <xsd:element ref = "move"/>
        </xsd:choice>
    </xsd:group>
    <xsd:element name = "accept">
        <xsd:complexType>
            <xsd:attribute name = "callid" use = "default" value = "_event.callid" type =
"xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "authenticate">
        <xsd:complexType>
            <xsd:attribute name = "server" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "userid" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "password" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "assign">
        <xsd:complexType>
            <xsd:attribute name = "name" use = "required" type = "xsd:%esvar;"/>
            <xsd:attribute name = "expr" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "ccxml">
        <xsd:complexType>
            <xsd:choice minOccurs = "0" maxOccurs = "unbounded">
                <xsd:element ref = "authenticate"/>
                <xsd:element ref = "assign"/>
                <xsd:element ref = "var"/>
                <xsd:element ref = "eventhandler"/>
                <xsd:element ref = "script"/>
            </xsd:choice>
            <xsd:attribute name = "version" use = "required" type = "xsd:%version;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "createcall">
        <xsd:complexType>
            <xsd:attribute name = "dest" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "name" type = "xsd:%esvar;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "createccxml">
        <xsd:complexType>
            <xsd:attribute name = "fetchid" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "start" type = "xsd:%expression;"/>
            <xsd:attribute name = "sessionid" type = "xsd:%esvar;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "createconference">
        <xsd:complexType>
            <xsd:attribute name = "id" use = "required" type = "xsd:%esvar;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "destroyconference">
        <xsd:complexType>
            <xsd:attribute name = "id" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "dialogstart">
        <xsd:complexType>
            <xsd:attribute name = "callid" use = "default" value = "_event.dialogid" type =
"xsd:%expression;"/>
            <xsd:attribute name = "src" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "type" use = "default" value = "application/xml+vxml" type =
"xsd:%content.type;"/>
            <xsd:attribute name = "namelist" type = "xsd:%esvars;"/>
            <xsd:attribute name = "dialogid" type = "xsd:%esvar;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "dialogterminate">
        <xsd:complexType>
            <xsd:attribute name = "dialogid" use = "default" value = "_event.dialogid" type =
"xsd:%expression;"/>
            <xsd:attribute name = "immediate" use = "default" value = "false">
                <xsd:simpleType>
                    <xsd:restriction base = "xsd:NMTOKEN">
                        <xsd:enumeration value = "true"/>
                        <xsd:enumeration value = "false"/>
                    </xsd:restriction>
                </xsd:simpleType>
            </xsd:attribute>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "disconnect">
        <xsd:complexType>
            <xsd:attribute name = "callid" use = "default" value = "_event.callid" type =
"xsd:%expression;"/>
            <xsd:attribute name = "reason" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "else">
        <xsd:complexType>
            <xsd:choice minOccurs = "0" maxOccurs = "unbounded">
                <xsd:group ref = "executable.content"/>
                <xsd:element ref = "elseif"/>
                <xsd:element ref = "else"/>
            </xsd:choice>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "elseif">
        <xsd:complexType>
            <xsd:choice minOccurs = "0" maxOccurs = "unbounded">
                <xsd:group ref = "executable.content"/>
                <xsd:element ref = "elseif"/>
                <xsd:element ref = "else"/>
            </xsd:choice>
            <xsd:attribute name = "cond" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "eventhandler">
        <xsd:complexType>
            <xsd:sequence minOccurs = "0" maxOccurs = "unbounded">
                <xsd:element ref = "transition"/>
            </xsd:sequence>
            <xsd:attribute name = "id" type = "xsd:ID"/>
            <xsd:attribute name = "statevariable" use = "required" type = "xsd:%esvar;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "exit">
        <xsd:complexType>
            <xsd:attribute name = "expr" use = "default" value = "0" type =
"xsd:%expression;"/>
            <xsd:attribute name = "namelist" type = "xsd:%esvars;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "fetch">
        <xsd:complexType>
            <xsd:attribute name = "next" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "namelist" type = "xsd:%esvars;"/>
            <xsd:attribute name = "method" use = "default" value = "get">
                <xsd:simpleType>
                    <xsd:restriction base = "xsd:NMTOKEN">
                        <xsd:enumeration value = "get"/>
                        <xsd:enumeration value = "post"/>
                    </xsd:restriction>
                </xsd:simpleType>
            </xsd:attribute>
            <xsd:attribute name = "fetchid" type = "xsd:%esvar;"/>
            <xsd:attribute name = "sync" type = "xsd:%esvar;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "goto">
        <xsd:complexType>
            <xsd:attribute name = "fetchid" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "if">
        <xsd:complexType>
            <xsd:choice minOccurs = "0" maxOccurs = "unbounded">
                <xsd:group ref = "executable.content"/>
                <xsd:element ref = "elseif"/>
                <xsd:element ref = "else"/>
            </xsd:choice>
            <xsd:attribute name = "cond" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "join">
        <xsd:complexType>
            <xsd:attribute name = "id1" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "id2" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "duplex" use = "default" value = "full" type =
"xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "move">
        <xsd:complexType>
            <xsd:attribute name = "endpoint" type = "xsd:%expression;"/>
            <xsd:attribute name = "event" type = "xsd:%expression;"/>
            <xsd:attribute name = "sessionid" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "redirect">
        <xsd:complexType>
            <xsd:attribute name = "callid" use = "default" value = "_event.callid" type =
"xsd:%expression;"/>
            <xsd:attribute name = "dest" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "reason" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "reject">
        <xsd:complexType>
            <xsd:attribute name = "reason" type = "xsd:%expression;"/>
            <xsd:attribute name = "callid" use = "default" value = "_event.callid" type =
"xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "script">
        <xsd:complexType>
            <xsd:simpleContent>
                <xsd:extension base = "xsd:string">
                    <xsd:attribute name = "src" type = "xsd:%expression;"/>
                </xsd:extension>
            </xsd:simpleContent>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "send">
        <xsd:complexType>
            <xsd:attribute name = "event" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "target" type = "xsd:%expression;"/>
            <xsd:attribute name = "name" type = "xsd:%expression;"/>
            <xsd:attribute name = "delay" type = "xsd:%duration;"/>
            <xsd:attribute name = "namelist" type = "xsd:%esvars;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "transition">
        <xsd:complexType>
            <xsd:choice minOccurs = "0" maxOccurs = "unbounded">
                <xsd:group ref = "executable.content"/>
            </xsd:choice>
            <xsd:attribute name = "state" type = "xsd:%string;"/>
            <xsd:attribute name = "event" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "cond" type = "xsd:%expression;"/>
            <xsd:attribute name = "name" type = "xsd:%esvar;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "unjoin">
        <xsd:complexType>
            <xsd:attribute name = "id1" use = "required" type = "xsd:%expression;"/>
            <xsd:attribute name = "id2" use = "required" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
    <xsd:element name = "var">
        <xsd:complexType>
            <xsd:attribute name = "name" use = "required" type = "xsd:%esvar;"/>
            <xsd:attribute name = "expr" type = "xsd:%expression;"/>
        </xsd:complexType>
    </xsd:element>
</xsd:schema>

Appendix E - VoiceXML Integration Details

Overview

This section describes the details of how CCXML and VoiceXML work together to provide dialog functionality in CCXML.

Events

CCXML and VoiceXML need to be able to exchange events between the browsers. The method of the message passing is up to the platform but it is assumed that there is some basic capacity in place.

One of the main areas that need to be dealt with is the VoiceXML application receiving random events. At this point until there are extensions to VoiceXML to allow this it is assumed there is only a limited amount of events that can be sent from the CCXML application to the VoiceXML application.

CCXML <dialogstart>

When a CCXML application processes a <dialogstart> element it starts up a VoiceXML application on the call leg with the URI that is passed in on the <dialogstart> element.

CCXML <dialogterminate>

When a CCXML application processes a <dialogterminate> it causes a "connection.disconnect" event to be thrown to the VoiceXML application. As far as the VoiceXML application knows the call was just disconnected. The VoiceXML application still has a chance to return data to the CCXML application by using the <exit> element in its <catch> statement.

VoiceXML <exit>

When a VoiceXML application processes a VoiceXML <exit> element it will cause the VoiceXML application to exit and return the contents of the namelist attribute to the CCXML application in the "dialog.exit" event in the following form:

      
      <exit namlist="foo bar jar"/>

maps into an event that looks like the following:

      dialog.exit
                 values.foo      
                 values.bar
                 values.jar

If the VoiceXML script is returning data using the expr attribute the data will be stored in "values.expr".

VoiceXML <disconnect>

When the VoiceXML application processes a <disconnect> element it causes a "dialog.disconnect" event to be thrown in the CCXML application. It is then up to the CCXML application to disconnect the call and sends back a "connection.disconnect" event. The following is an example of what would happen:

1. The VoiceXML script executes a <disconnect> element.
2. As a result, the VoiceXML interpreter sends a disconnect event to CCXML.
3. CCXML receives a "dialog.disconnect" event from the VoiceXML script. It interprets this as a request from the VoiceXML script to "please disconnect me".
4. An eventhandler in the CCXML script should have a <transition> element intended to handle the "dialog.disconnect" event.
5. The CCXML application would have a <disconnect> element as the child of the transition event. This would disconnect the call.
6. The CCXML platform completes the disconnect function, dropping the call. The platform performs an upcall which could result in CCXML throwing the "connection.DISCONNECTED" event.
7. An eventhandler in the CCXML script should have a <transition> element intended to handle the "connection.DISCONNECTED" event.
8. The <transition> element has a child element which performs a <send> of the "connection.disconnect.hangup" event to the VoiceXML script.

Here is the sample CCXML code that completes the disconnect and returns the "connection.disconnect" event back to VoiceXML:

      <ccxml version="1.0">
        <eventhandler statevariable="mystate">

          <transition event="dialog.disconnect" name="myevent">
            <assign name="dialogid" expr="myevent.dialogid"/>
            <disconnect sessionid="myevent.callid" />
          </transition>

          <transition event="connection.DISCONNECTED" >
            <send event="connection.disconnect.hangup" target="dialogid"/>
          </transition>

        </eventhandler>
      </ccxml>

VoiceXML <transfer>

When a VoiceXML application processes a <transfer> element it is handled within CCXML via series of events between the VoiceXML platform and the CCXML application. Here is an example:

1. The VoiceXML script executes a <transfer> element.
2. As a result, the VoiceXML interpreter sends a transfer event to CCXML. Included with the event is a namelist of the transfer element's attributes, e.g., the name of the form variable, the destination URI for the call to be transferred to, whether or not the call should be bridged or not, among others (see VoiceXML spec for complete list).
3. CCXML receives a dialog.transfer event from the VoiceXML script. It interprets this as a request from the VoiceXML script to "please transfer me". Included with the event is the session ID of the call associated with the VoiceXML script, as well as all the transfer attributes described in step 2.
4. An eventhandler in the CCXML script should have a <transition> element intended to handle the dialog.transfer event.
5. Some child element of <transition> executes, invoking a <createcall> function to create an outgoing call leg.
6. The CCXML platform completes the outgoing call function. This will cause a connection.CONNECTED event.
7. An eventhandler in the CCXML script should have a <transition> element intended to handle the connection.CONNECTED event.
8. The <transition> element has a child element which performs a <join> of the incoming call leg and the outgoing call leg.
9. If the bridge attribute was false, then the original VoiceXML session script does not care to wait until the end of the new call for status. Send a telephone.disconnect.transfer event now to inform that session that the transfer is complete. This conforms to the behavior specified by VoiceXML 1.0 and 2.0.
10. If the bridge attribute was true, then wait for the connection.DISCONNECTED event to occur on the new call leg. Extract the disconnect reason, and now send that reason to the form variable in the original, blocked VoiceXML session as a dialog.vxml.transfer.complete event

dialog.vxml.transfer.complete

This event is sent from the CCXML application to the VoiceXML platform which uses this to fill transfer field item.

The fields of this event are:

Sample

Here is some sample CCXML code to handle the events related to a call transfer:

      <ccxml version="1.0">

        <var name="in_callid" />
        <var name="out_callid" />
        <var name="dialogid" />

        <eventhandler statevariable="mystate">
          <transition event="dialog.transfer" name="in_event">
            <assign name="mystate" expr="'calling_out'" />
            <assign name="in_callid" expr="in_event.callid" />
            <assign name="dialogid" expr="in_event.dialogid" />

            <createcall dest="in_event.URI" name="out_callid" />
          </transition>

          <transition state="calling_out" event="connection.CONNECTED"
name="out_event">
            <assign name="mystate" expr="'outgoing_call_active'" />
            <join sessionid1="in_callid" sessionid2="out_event.callid " duplex="full" />
            <if cond="in_event.values.bridge == 'false'">
              <send event="connection.disconnect.transfer" dest="dialogid"/>
            </if>
          </transition>

          <transition state="outgoing_call_active" event="connection.DISCONNECTED"
name="out_event">
            <assign name="mystate" expr="'outgoing_call_finished'" />
            <if cond="in_event.bridge == 'true'">
              <if cond="in_event.callid == out_callid">
                <assign name="results" expr="far_end_disconnect" />
                <send event="dialog.vxml.transfer.complete" dest="in_event.dialogid"
namelist="results" />
              <else/>
                <send event="connection.disconnect.hangup" dest="dialogid" />
              </if>
            </if>
          </transition>
        </eventhandler><
      </ccxml>

User Disconnect

When a caller hangs up on one of the call legs the VoiceXML dialog is not automatically disconnected. You need to send a "connection.disconnect.hangup" event to the VoiceXML application so it can complete any cleanup that is required. The VoiceXML application can then still return data to the CCXML application by using the VoiceXML <exit> element.

Proposed Enhancement to VoiceXML Event Handling

One of CCXML's main reasons to exist is VoiceXML's inability to process asynchronous events. When CCXML receives one of these events, it can process it silently, or start a new VoiceXML dialog. However, there are some occasions when we would like to tightly bind the event-processing with the user interface. In these cases, the VoiceXML author must be aware of event-processing, but gains very fine-grained control over dealing with the incoming event. In these cases, VoiceXML must be enriched with a notion of synchronous event handling.

We would like VoiceXML to be as ignorant as possible of the events being tossed back and forth. For generic interruptible and hold-music applications, <dialogstart> is enough. For interfaces which might change in response to arriving events (e.g., an option becomes 'unghosted' when a processing job completes), we need VoiceXML to be event-aware.

We can make VoiceXML process event input in much the same way as it handles speech input today. A new kind of form item can check the interpreter's pending synchronous events, and try to process the first one, if any. The form item selects one from its set of valid event handlers, and executes the code there. If there are no incoming synchronous events for some period of time, the form item can generate a NOINPUT, and process it appropriately.

This kind of event-handling is much less ambitious than the asynchronous variety we described above. However, when we want the dialog to change according to incoming events, we don't mind changing the VoiceXML code, and <dialogstart> is too blunt an instrument, processing synchronous events inside the dialog can be a useful approach.

Appendix F - Recommended Telephony Protocol Names

Overview

This section defines a list of recommended telephony protocol names to be used in CCXML platforms. Platforms SHOULD use the following list when available. If the protocol is not defined in this list the platform MUST prefix the name with an underscore, "_", to identify them as platform-dependent.

Protocol names

Appendix G - Changes

Changes in working draft 2

• Added the redirect element.
• Added the reason attribute to the disconnect and reject elements.
• Removed the submit element.
• Updated the fetch element.
• Updated the goto element.
• Updated the exit element.
• Updated the createccxml element.
• Added the move element.
• Updated the DTD.
• Added a Schema.
• Updated the examples to match the new spec changes.
• Major Editorial Work.
• Updated transition element with default cond of "true".
• Updated the join element.
• Updated the unjoin element.
• Updated the createconference element.
• Updated the destroyconference element.
• Added ECMAScript.
• Added the script element.
• Updated the dialog interaction.
• Updated the dialogstart element
• Updated the dialogterminate element
• Added VoiceXML interaction section
• Added new dialog events
• Added new ccxml core events
• Updated attribute names to be more consistent

Changes in working draft 3

• Major editorial changes to reflect current status of the document (Entire Document)
• Minor corrections to all examples to reflect changes to the spec (Entire Document)
• Rewrote introduction (Section 1)
• Rewrote background (Section 2)
• Updated overview of call management (Section 3.3)
• Added CSS 2 times reference to the definitions section (Section 3.4.2)
• Rewrote section 4 introduction to cover updated object models (Section 4)
• Updated description of <if>, <elseif> and <else> (Section 6.2.2-6.2.4)
• Updated namelist attribute of <fetch> (Section 6.2.5.2)
• Updated method attribute of <fetch> (Section 6.2.5.2)
• Added timeout attribute of <fetch> (Section 6.2.5.2)
• Updated namelist attribute of <exit> (Section 6.2.7.2)
• Added <log> tag (Section 6.2.8)
• Updated threading description of section 6.3.1 (Section 6.3.1)
• Added clarification to "ccxml.loaded" event (Section 6.3.5)
• Updated overview of <dialogstart> to reflect object model changes (Section 7.2.1.1)
• Updated overview of <dialogstart> having to do with passing of call data (Section 7.2.1.1)
• Renamed the callid attribute to conid on <dialogstart> (Section 7.2.1.2)
• Updated type attribute of <dialogstart> to make it a ECMAScript expression (Section 7.2.1.2)
• Updated namelist attribute of <dialogstart> (Section 7.2.1.2)
• Added duplex attribute of <dialogstart> (Section 7.2.1.2)
• Renamed callid attribute of the "dialog.started" event to conid (Section 7.3.2)
• Renamed callid attribute of the "dialog.exit" event to conid (Section 7.3.3)
• Renamed callid attribute of the "dialog.disconnect" event to conid (Section 7.3.4)
• Renamed callid attribute of the "dialog.transfer" event to conid (Section 7.3.5)
• Renamed callid attribute of the "error.dialog.notstarted" event to conid (Section 7.3.6)
• Renamed callid attribute of the "error.dialog.wrongstate" event to conid (Section 7.3.7)
• Renamed callid attribute of the "dialog.user.*" event to conid (Section 7.3.8)
• Added scope diagram to section 8.2.1.1 (Section 8.2.1.1)
• Updated event concepts in section 9.1 to reflect updated call control model (Section 9.1)
• Updated event delivery details in section 9.1 to deal with user specified event delay (Section 9.1)
• Added description to <eventhandler> details (Section 9.2.1)
• Removed id attribute from <eventhandler> (Section 9.2.1.1)
• Added description to <transition> details to explain event selection (Section 9.2.2)
• Updated state attribute of the <transition> element to allow for more then one state (Section 9.2.2.1)
• Updated event attribute of the <transition> element to add regex support (Section 9.2.2.1)
• Added event matching text to define regex behavior (Section 9.2.2.2)
• Added clarification to <send> element processing (Section 9.2.3.1)
• Updated namelist attribute of the <send> tag (Section 9.2.3.2)
• Added clarification to <move> element processing (Section 9.2.4.1)
• Renamed endpoint attribute of <move> element to source and minor updates (Section 9.2.4.2)
• Updated event attribute of <move> element (Section 9.2.4.2)
• Complete rewrite of most of section 9.4 to reflect new event model (Section 9.4)
• Added error events section (Section 9.5)
• Major rewrite of section 10 introduction to reflect new call control model (Section 10)
• Renamed callid attribute of <accept> element to conid (Section 10.1.2.2)
• Renamed callid attribute of <redirect> element to conid (Section 10.1.3.2)
• Updated dest attribute of <redirect> element (Section 10.1.3.2)
• Renamed callid attribute of <reject> element to conid (Section 10.1.4.2)
• Added <hold> tag (Section 10.1.5)
• Updated overview of <createcall> element (Section 10.2.1.1)
• Updated dest attribute of <createcall> (Section 10.2.1.2)
• Renamed name attribute of <createcall> to conid (Section 10.2.1.2)
• Added aai attribute to <createcall> (Section 10.2.1.2)
• Added callerid attribute to <createcall> (Section 10.2.1.2)
• Added hints attribute to <createcall> (Section 10.2.1.2)
• Added use attribute to <createcall> (Section 10.2.1.2)
• Added timeout attribute to <createcall> (Section 10.2.1.2)
• Added examples section to <createcall> (Section 10.2.1.3)
• Major rewrite of Section 10.3 and 10.4 to reflect new call control models (Section 10.3 and 10.4)
• Updated disconnect section to update call control model (Section 10.5)
• Renamed callid attribute of <disconnect> to conid (Section 10.5.1.2)
• Added dialog attribute to <disconnect> (Section 10.5.1.2)
• Updated reason attribute of <disconnect> (Section 10.5.1.2)
• Updated details of the <authenticate> tag having to do with the "ccxml.exit" event (Section 11.2.2)
• Updated all examples to work with changes (Section 12)
• Moved all issues to Appendix A (Appendix A)
• Added ECMA-CSTA to Appendix B (Appendix B)
• Updated DTD (Appendix C)
• Updated Schema (Appendix D)
• Updated VoiceXML Integration Details (Appendix E)
• Added Recommended Telephony Protocol names (Appendix F)
• Renamed Changes and Acknowledgments Appendixes (Appendixes G and H)

Appendix H - Acknowledgments

This version of CCXML was written with the participation of members of the W3C Voice Browser Working Group, and a special thanks is in order for the following contributors:

David Attwater, BTexact Technologies <david.attwater@bt.com>

Eric Burger, Snowshore <eburger@snowshore.com>

Ken Davies, Hey Anita <Kend@heyanita.com>

Rajiv Dharmadhikari, Telera <rajiv@telera.com>

Dave Donnelly, BTexact Technologies <dave.donnelly@bt.com>

Daniel Evans, Nortel Networks <dde@nortelnetworks.com>

Mike Galpin, Syntellect <mgalpin@syntellect.com>

Markus Hahn, Voxeo <markus@voxeo.com>

David W Heileman, Unisys <David.Heileman@unisys.com>

Gadi Inon, Comverse <gad.inon@comverse.com>

Rob Marchand, VoiceGenie <rob@voicegenie.com>

Paolo Baggia, Loquendo <Paolo.Baggia@loquendo.com>

Brad Porter, TellMe Networks <brad@tellme.com>

Kenneth Rehor <ken@rehor.com>

Dave Renshaw <dave_renshaw@uk.ibm.com>

Saravanan Shanmugham, Cisco <sarvi@cisco.com>

Jim Trethewey, Intel <jim.r.trethewey@intel.com>

Wai-Yip Tung, Cisco <wtung@cisco.com>

This W3C specification is based upon CCXML 1.0 as contributed to the Voice Browser working group in April 2001. The CCXML authors were:

RJ Auburn, Voxeo

Michael Cafarella, TellMe

Don Jackson, TellMe

Jeff Peck,Intel

Pramod Sharma, Telera

Saravanan Shanmughan, Cisco Systems

Corey Stohs, Cisco Systems

Yi Zhang, Telera