This document provides HP comments on CCXML 1.0 Last Call Working Draft. In general, CCXML seems to provide most features for common call control use cases. The comments are primary based on our experience with 1st party call control scenarios using SS7/ISUP and SIP. As the specification proceeds through standardization, we expect to provide more comments especially from the 3rd party call control perspective.
| Id | Title | Section | Type |
| 0 | Typo | 6.1 | Clarification / Typographical / Editorial (§2.1) |
| 1 | Typo | 11.1 | Clarification / Typographical / Editorial (§2.1) |
| 2 | Example Error | 11.2 | Clarification / Typographical / Editorial (§2.1) |
| 3 | SIP reference | 10.5.4.2, 10.5.2.2, 10.5.4.2, Appendix E | Clarification / Typographical / Editorial (§2.1) |
| 4 | xmlns attribute missing in examples | Clarification / Typographical / Editorial (§2.1) | |
| 5 | Typo | 9.2.3.3 | Clarification / Typographical / Editorial (§2.1) |
| 6 | Clarify 'dialog system' | 1, 7 | Clarification / Typographical / Editorial (§2.1) |
| 7 | ccxml.loaded and synchronized fetch | 6.2.5, 6.3.5 | Clarification / Typographical / Editorial (§2.1) |
| 8 | CCXML Sequencing | 10.5.1, 7.2.2.2 | Clarification / Typographical / Editorial (§2.1) |
| 9 | Clarify interoperation with CSTA | Clarification / Typographical / Editorial (§2.1) | |
| 10 | Clarify best practise for setting connection information | Clarification / Typographical / Editorial (§2.1) | |
| 11 | application level variables | Feature Request (§2.4) | |
| 12 | Asychronous <fetch> with Data Access | 6.2.5 | Change to Existing Feature (§2.3) |
| 13 | application session support | Feature Request (§2.4) | |
| 14 | Clarify <goto> error | 6.2.5.1 | Clarification / Typographical / Editorial (§2.1) |
| 15 | Clarify namelist in dialog.transfer | 7.3.5 | Clarification / Typographical / Editorial (§2.1) |
For efficiency in carrier-grade solutions, CCXML application should be cached wherever possible thereby eliminating the need to fetch and parse the same document. In the web and VoiceXML worlds, this has led to an approach to writing dynamic application where the 'skeleton' of the application is specified in markup (hence cacheable since it doesn't change) and data is then retrieved from the application server to 'flesh out' the skeleton document. In particular, once the cached document is loaded, data is fetched from the server and injected into the scripting engine to allow dynamic behavior.
We want this capability in CCXML for efficiency. We can see two possible solutions.
1. Modification of <fetch> element to allow retrieval of non-CCXML documents. For example, using <fetch> to fetch a XML data document and then accessing its information using DOM access methods:
<transition state="fetchwait" event="fetch.done" name="event">
<var name="version" expr="session.documents[event.fetchid].
documentElement.getAttribute('version')"/>
</transition>
Currently, only CCXML documents are expected to be <fetch>ed: "The <fetch> tells the platform to find, load, and parse a given CCXML document" (i.e. application/ccxml+xml is assumed at the moment). However, if the platform behavior was built around the returned Content-Type (or even an explicit 'type' attribute which follows the recent TAG findings), then it could distinguish between parsing actions to be performed on the fetched document. We would also be required to handle more error situations (trying to <goto> a non-CCXML document, accessing the data in a CCXML document, etc).
Note also in this approach the use of "session.documents" to provide a point for access to the document. In principle, every documetn which has been fetched would accessible for the duration of the session.
2. Incorporate the <data> element from VoiceXML 2.1 with similar asynchronous behavior to the <fetch> element. For example:
<data src="xx.xml" namelist="aconnectionid ani dnis astart"/>
<transition event="data.done" name="event">
<var name="version" expr="session.documents[event.fetchid].
documentElement.getAttribute('anattribute')"/>
</transition>
Extend CCXML to allow data to fetched from an application server. Of the two approaches outlined, we would prefer extending <fetch> since the size of the language is kept to a minimum.
For efficient high density applications, we need to make maximum use of cached documents (i.e. using an optimized get - 304 not modified) so the document doesn't need to be retrieved from the application server and re-parsed.
If the whole CCXML application is written as a single document, the application-related information can be stored as document variables. However, when the CCXML application consists of multiple CCXML documents this is not possible.
The only method which CCXML allows today is passing application information back to the application server which then sends back the information inside the CCXML document. For example, if we wish to preserve the anis, dnis and connectionid, then they need to be passed up to the application server (the developer may not receive another connection event hence cannot rely on getting the information this way). However, this will break caching since different documents will always be returned even though the only difference between the documents may be this application data.
In VoiceXML 2.0 this problem was addressed using application scope variable.
Multiple media/control sessions need to be identified as belonging to the same session in the application server. For example, an application session may consists of delivering CCXML, VoiceXML and SRGS documents and requests for each of these documents may come from different HTTP clients.
A new CCXML session has a new session object (session.*), where initially the length of the connection array is 0. A CCXML session contain multiple active connections.
Replace 'contain' with 'containing'.
Caller calls an 800 number and after some interaction with an IVR system places and outbound call to a friend.
Replace last 'and' with 'an'.
Update the SIP reference from RFC2543 to RFC3261 - the later version covers SIP Secure.
Add CCXML xmlns in all examples.
Data is described as:
an ECMAScript expression returning a string that indicates the type of event being generated. The event type MAY include alphanumeric characters and the "." (dot) character. The first character MAY not be a dot or a digit. Event type names are case-insensitive. (Required)
Change example from data="hello.jack" to data="'hello.jack'".
We would like to see more clarification that the dialog control/server component can be any media handling sub-system so long as its respects the defined protocol with the CCXML component (maybe separate out features specifically related to dialog such as transfer in VoiceXML). For example, media handling sub-systems which handle fax, specialized audio playback (only) device, specialized DTMF handler, specialized recorder, answer machine detectors, etc. While we would prefer the term 'media handler' instead of dialog (dialogprepare, dialogstart, etc), we realize that even at this stage such a cosmetic change may be resisted.
6.3.5: ccxml.loaded - CCXML Document Loaded Event This event is thrown once the document is parsed and ready for execution (document initialization occurs between the fetched and loaded events). 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>. This event would be processed after the platform had executed the document initialization including executing any elements under the <ccxml> .
6.2.5: <fetch> and <goto> When <fetch> is executed synchronously, the CCXML session 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> 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.
Clarify if and when ccxml.loaded is sent to the page when performing a synchronized fetch.
<transition state="preparingdialog" event="dialog.prepared"
name="event"> <assign name="callstate" expr="'indialog'"/>
<accept/>
<dialogstart/>
</transition>
<transition state="preparingdialog" event="dialog.prepared" name="event">
<assign name="callstate" expr="'indialog'"/>
<accept connectionid="aconnectionid"/>
<dialogstart prepareddialogid="event.dialogid"/>
</transition>
In accept, 10.5.1, it says the connectionid attribute is OPTIONAL ; if omitted, the interpreter will accept using the id indicated in the current event being processed.
But the dialog.prepared event doesn't have that value.
Also in <dialogstart> it says 7.2.2.2: The element includes either a URI reference to the initial document for the dialog or the identity of a previously prepared dialog.
Having to add in these attributes certainly makes it more error prone and was not really in the earlier specs.
In the case where CSTA is used for third party call control for a switch located in front of the voice/ccxml system, the CSTA environment will set up a Call Identifier as the call moves through the switch to the IVR.
A CSTA Call Identifier is a reference associated with a call whereby the call is known to the switching, computing and special resource functions through the call's life. A Call Identifier is allocated to each call by the Switching Function, at the latest, when the call first becomes visible across a CSTA Service Boundary.
This Call Identifier is typically a record locater that can be used to provide a history of the call. As the call moves around call center agents, or IVR systems, this Call Identifier can be used to associate all of the learned info during the call. This way when the call is transferred from one agent to another the previous history of the call can be located.
How would this call identifier would be offered to the CCXML or VoiceXML dialog at the start of the call? Would the connectionid be equivalent to the CSTA call identifier or would it be expected that call identifier can be extracted from connection.csta (and data sent to that specific call identifier via <send>) and that this call identifier would be passed to VoiceXML session?
In some cases, the interaction with the call connection object built into CCXML is not sufficient for SS7/ISUP signalling use cases. In particular, before a call is <accept>ed, the CCXML interpreter may need to send the connection additional information; for example, sending an ISUP ACM message to initiate ringing at the far end (the IAM message is mapped to connection.ALERTING and the ANM message is mapped to the CCXML <accept> element). The question is how to send this additional information to the connection object?
We see a number of potential solutions:
<send target="evt.connectionid" targettype="ss7/isup"
data="'ACM...'"/>
Our general preference is for the second approach. It is not very clear from the specification that <send> is intended for sending information to a connection. If a connection object itself is able to have methods as in the second solution, then it would also be desirable for it to have settable properties: i.e. the connection object would have properties and methods which could be accessed and set by the developer. We aren't clear that this approach is prohibited by CCXML (connection objects are not read-only) and which of these solutions would be the best practise.
The specification says:
A <goto> transfers control to the document identified by the fetch ID. The execution of a <goto> 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.
In the case below
<fetch next="'createDialogAndAnswerCall.ccxml.jsp'" namelist="aconnectionid ani dnis" sync="fetchevent"/> <goto fetchid="fetchevent.fetchid"/>
if the fetch fails, then what error event should be used in case of a <goto> to an nonexisting document? Since error.fetch cannot be reused, what other error event should be used?
The dialog.transfer event defines a 'namelist' attribute. However, it is not clear the namelist can be set from within VoiceXML 2 specifically additional information about the transfer beyond the standard transfer features (e.g. additional information for the outbound connection). This needs to synchronized with VoiceXML 2.1.