- 8.2.1: and
- 8.2.2:
-
ECMAScript expression - defined in ECMA-262 [ECMASCRIPT] 11.1; this is an expression which produces a value; an expression which is valid on the right
hand side of an assignment operator;
Several examples of ECMAScript expressions are as follows (ECMAScript expression in red):
-
ECMAScript variable name - defined in ECMA-262 [ECMASCRIPT] 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;
Several examples of ECMAScript variable names are as follows (ECMAScript variable name in red):
- Empty ECMAScript object - an object returned by the
new Object() ECMAScript expression; an
object with no properties.
- CCXML variable name - a variable name, with optional dot separated qualification, declared in a CCXML
var keyword.
- Scope element - a CCXML element which defines a variable scope;
-
Time interval - CCXML uses the Cascading Style Sheets, Level 2 [ 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".
- CCXML Application/Program - A collection of CCXML documents that together
create a complete application/program.
- CCXML Interpreter - The software that processes CCXML documents, executes
commands and dispatches events. Also referred to as the "CCXML Platform".
- CCXML Platform - An implementation of CCXML for a specific network and
environment, generally including a CCXML Interpreter as a component.
- CCXML Session - A single instance of a CCXML application. It can span multiple documents and phone
calls. See Section 3.5 Session Life-Cycle for details.
- CCXML Parent Session - The CCXML session that created the currently running session using the
element.
- Event - An action or occurrence to which an application can respond. Examples of events are incoming
phone calls, dialog actions or user defined events. Events in CCXML are modeled as ECMAScript objects and can contain complex
values. All events in CCXML have a standard set of properties as defined in section 9.4.2: Standard Event
Attributes.
- Associative array - An associative array (also known as a map, lookup table, or dictionary) is an
abstract data type composed of a collection of keys and a collection of values, where each key is associated with one value.
Associative arrays in ECMAScript are implemented using an Object with sub properties.
- Class - CCXML Classes are ECMAScript Constructor objects (see section 4.2.1 of the ECMAScript
specification for more information) to help in creating the appropriate type of object instances (such as connection,
conference and dialog). The Constructor object may contain properties that are not inherited by children objects (such as
Connection.states). The constructor object MAY also contain a Prototype property to allow properties
that are inherited. Platforms MAY choose to add properties to classes. By convention, the properties
MUST begin with an underscore, "_", to identify them as platform-dependent. All defined objects in
this specification must be initiated via one of these classes. An example would be
'MyConnection = new
Connection()'.
The Connection class MUST initiate connection objects, the Dialog class
MUST initiate dialog objects and the Conference class MUST initiate
conference objects.
3.5: Session Life-Cycle
3.5.1: Startup
A CCXML session can be started for the following reasons:
- A new incoming phone call coming into the platform.
- A CCXML application executing a
- An external session launch request coming into the platform.
To create a CCXML session, the URI for the initial CCXML document must be known, along with any fetching parameters
affecting how that CCXML document is retrieved. For incoming calls, the selection of the initial URI and fetching parameters is
platform-dependent, and MAY be based on information from the incoming call. Sessions created via
When a session is started due to an incoming call it has ownership of the new Connection that caused it to be created. The
new CCXML session will be responsible for processing the Connection state events and performing the Connection actions. If the
session was started because of a
A CCXML application can determine the reason its session was started by evaluating the contents of the
session.startupmode session variable that is defined in the Session
Variables section.
3.5.2: Shutdown
A CCXML session can end in one of the following ways:
- The CCXML application executes an
- An unhandled
"error.*" event.
- An unhandled
"ccxml.kill" event.
- A
"ccxml.kill.unconditional" event.
When a CCXML session ends, all active connections, conferences and dialogs that are owned by that session are automatically
terminated by the platform.
3.5.3: Session Life-Cycle Diagrams
The following diagrams illustrate the session life-cycle of several different scenarios. These diagrams do not show all
possible scenarios but rather show some of the most common ones that CCXML applications may encounter.
3.5.3.1: session can live before and after active connections (or no connections at
all)
A CCXML session does not necessarily need to have any connections associated with it. After starting, a session may acquire
connections as a result of
3.5.3.2: connection life shorter than session
In this example, the session is started due to an incoming call. A connection is typically shorter than a session. A session
does not end when a connection terminates.
3.5.3.3: session ends, kills all active connections
When a session ends, any resources, including connections owned by that session are terminated.
3.5.3.4: session can have multiple sequential connections
A session can have multiple sequential connections
3.5.3.5: session can have multiple sequential connections and multiple concurrent
connections
In addition to having multiple sequential connections, a session can have multiple concurrent connections.
3.5.3.5: move a connection to a newly created session
A connection can be moved from one CCXML session to another session. In the figure below, CCXML session (1) creates a new
CCXML session (2) via
3.5.3.7: move a connection to a "master" session
A connection can be moved from one CCXML session to another session, such as a "master" session.
3.5.3.8: optional "master" session for inbound call handling
Implementations MAY, as a platform-specific optimization, choose to deliver more than one inbound
call to a single "master" session. This can be viewed as equivalent to sessions handling incoming calls performing a
connection.alerting
event) to the single "master" CCXML session.
The default inbound call handling behavior for CCXML implementations is to create a new CCXML session and deliver the
connection.alerting event to it. If a platform supports delivery of multiple inbound calls to a single session,
the way this is configured is implementation specific.
3.5.3.9: ccxml.kill.unconditional event raised
If at anytime a ccxml.kill.unconditional event is raised by the underlying implementation, the CCXML session is
immediately terminated and all active connections, conferences and dialogs that are owned by that session are automatically
terminated by the platform.
3.5.3.10: Normal session shutdown requested by the platform
If at anytime the platform wishes to terminate a CCXML session it MUST raise a
ccxml.kill event to inform the CCXML application. The normal response to this event is for the CCXML application
to perform any clean up and termination of current active connections, conferences or dialogs and then execute an
If the CCXML application does not respond to the ccml.kill event in a timely manner the platform MAY then raise a ccxml.kill.unconditional event to immediately terminate the CCXML session and all
active connections, conferences, and dialogs that are owned by the session.
4: Simple Examples
4.1: Hello World
This simple CCXML document shows an example of a "hello world" application that is started due to an incoming call where the
application simply assigns a value to a variable, prints a message to the platform log and exits:
4.2: Accept or Reject a Call
This CCXML document shows an example of how to process a incoming call event and answer or reject the call based on the
phone number of the calling party:
4.3: Simple Dialog
This is an example of running a simple VoiceXML dialog from CCXML. The application answers an incoming phone call and then
connects it to a VoiceXML dialog that returns a value that is then logged to the platform:
dialog.ccxml:
dialog.vxml:
5: CCXML Elements Listing
|
Accept an incoming phone call |
|
Assign a variable a value |
|
Cancel a CCXML event timer |
|
CCXML container element |
|
Make an outbound call |
|
Create a new CCXML session |
|
Create a multi-party audio conference |
|
Destroy a multi-party audio conference |
|
Prepare a dialog for execution |
|
Start a dialog session's execution |
|
Stop a dialog session's execution |
|
Terminate a phone connection |
|
Used in statements |
|
Used in statements |
|
Block of event-processing statements |
|
Ends execution of the CCXML session |
|
Preload a CCXML file |
|
Move execution to a new location |
|
Conditional logic |
|
Connect two audio sources |
|
Log to the platform debug log |
|
Merge two connections at the network level |
|
Override HTTP headers and provide document metadata |
|
Provide document metadata |
|
Move an event source to another ccxml session |
|
Redirect an incoming call to a new endpoint |
|
Reject an incoming phone call |
|
An implementation MUST support |