W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2010

Re: July CCXML Implementation Report: 10_2_3: missing transition for connection.disconnected - should be 10_2_4 - ISSUE-739

From: Chris Davis <davisc@iivip.com>
Date: Fri, 20 Aug 2010 09:56:10 -0500
Message-ID: <4C6E978A.1000708@iivip.com>
To: kuba@optimsys.cz
CC: www-voice@w3.org

In the situation where a CCXML document does a <disconnect> 
immediately followed by a <send> to itself, you had mentioned that one
of the test cases was broken because it did not catch the connection.disconnected
should it occur before the <send> result.

We passed the test case as-is because our connection.disconnected is driven
by the call control result and that always happens several milliseconds after the internal event <send>
to ourself (which happens immediately).

For example, if using SS7 the <disconnect> would result in a REL message,
and the return RLC (milliseconds later) drives the connection.disconnected. If using SIP, the <disconnect>
would result in a BYE and the final response to the BYE (milliseconds later) would drive the 

We implemented it this way because section says of <disconnect>,
"the underlying platform MUST send the appropriate protocol messages to perform
the disconnect, and send an asynchronous event to the CCXML document when the
disconnect operation completes".

Clearly, the "disconnect operation" has not completed until the call control says it
has completed and by that time the <send> has either already been processed or at least is on
the event queue in front of it.

I'm just curious as to what your interpreter is doing that manages to insert connection.disconnected
before the <send>. Do you queue up a connection.disconnected immediately upon encountering a


Chris Davis
Interact Incorporated R&D
Received on Friday, 20 August 2010 14:56:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:41 UTC