CCXML 1.0 Discrepancies

We just finished integrating a CCXML interpreter on top of our VXML
layer here at Interact. We found the following during development:

1) 
The spec says the CCXML should receive a dialog.disconnect event from
VXML if VXML encounters a <disconnect> element. It then says a CCXML
document should send a connection.DISCONNECT event to VXML, but the
example shows a connection.disconnect.hangup being sent. Which is it?

2)
DTD incomplete: createcall is not part of executable.content

3)
DTD incomplete: log is not part of executable.content

4)
DTD incomplete: createcall missing attributes such as callerid, hints,
timeout, etc.

5)
DTD incomplete: disconnect missing attribute dialogid

6)
DTD incomplete: log not defined as ELEMENT or ATTLIST

7)
DTD error: move has bogus attribute endpoint

8)
DTD/spec mismatch several elements have the attribute callid in the DTD,
but the spec refers to that attribute as connid (accept ), or conid
(dialogstart)

9)
Design Omission: the <send> element can perform time-delayed event
transmissions. The spec does not provide a way to remove that or keep it
from occurring after the fact. There should an additional element that
lets the application remove the pending transaction.

10)
Cryptic disconnect: the spec says "The dialog attribute is optional; if
omitted, no dialog disconnect notification will be sent." What is this
notification? 

11)
No defined transition order of precedence if the document specifies two
transitions for the same event, one with a state the other without a
state that matches the state when the event is received, it is ambiguous
as to which transition block should be executed.

At Interact, we went with the following:
a)
State and Event: This block is executed when the state and event name
match, and there are no wild cards(asterisks) For example:  
        
        <transition state="s1" event="connection.ALERTING">
        
        There can be multiple states as well, such as:
        
        <transition state="s1 s2" event="connection.ALERTING">
        
        
b)
Event Wildcard: This block is executed regardless of state for the
specified event if any event comes in that matches the prefix of the
event name(text before the *). For example:
        
        <transition event="wildCard*">
        
c)
Single Event: This block is executed if the named event is received in
any state. For Example:
        
        <transition event="eventName">
        
The CCXML spec does not dictate the above (or any) order of precedence.
However, the precedence described above allows documents to give
importance to transition blocks that exactly match.  
        
        
12)

ccxml.conferencecreated: This event is used in the example conferencing
application in Section 12. It seems to imply that a CCXL interpreter
should throw this event, but this is not stated under the
<createconference> element. 

13)
        
No indication of conference destruction! The spec implies a
ccxml.conference.created event in Section 12. A
ccxml.conference.destroyed event is required for CCXML channels to know
when the conference they were in was destroyed such that the channel
could perform other tasks. This is critical when the channel that
destroyed the conference is not the same as the channel that created the
conference.

14)

No indication of unjoin complete The spec has a ccxml.joined, it needs a
ccxml.unjoined to let a document know when switch connections are
complete to allow it to perform additional operations

15)
Unusable conferencing example. The conferencing application in Section
12 would not work. Specifically, in the following section, the
vconference.asp document plays a text to speech message to the caller,
joins the caller to a conference, then starts a dialog to play a message
to the conference (newcaller.vxml):
        
        <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>
        
However, the CCXML interpreter does not wait(as per the spec) for a
dialogstart to complete before continuing execution. Therefore,
depending upon your hardware in use, the call is dumped into the
conference via join either before the text to speech of vconference.asp
finishes, or it gets cut off, or the newcaller.vxml text to speech
message played to the conference members is lost, played late, or not
heard at all.
        
Instead, the application should wait for a dialog.exit from the
vconference.asp document before issuing a join, and then wait for a
ccxml.joined before starting the newcaller.vxml dialog.


-- 
Chris Davis
Interact Incorporated R&D
(512)502-9969x117

Received on Friday, 18 June 2004 13:00:05 UTC