- From: Chris Davis <davisc@iivip.com>
- Date: Fri, 18 Jun 2004 10:54:31 -0500
- To: W3 list <www-voice@w3.org>
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