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: Petr Kuba <kuba@optimsys.cz>
Date: Fri, 20 Aug 2010 17:27:32 +0200
Message-ID: <4C6E9EE4.3080107@optimsys.cz>
To: Chris Davis <davisc@iivip.com>
CC: www-voice@w3.org

You are absolutely right that in a real-world cases this scenario 
usually behaves the way you describe (although since both <send> and 
<disconnect> are asynchronous you can never guarantee order of the events).

The problem I reported occurred with our telephony testing simulator 
which was configured to process without any delays.

When we use SIP, everything is OK.


On 20.8.2010 16:56, Chris Davis wrote:
> Petr,
> 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 connection.disconnected.
> 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
> <disconnect>?
> Regards,
> Chris
Received on Friday, 20 August 2010 15:28:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:57 UTC