- From: Chris Davis <davisc@iivip.com>
- Date: Fri, 20 Aug 2010 09:56:10 -0500
- To: kuba@optimsys.cz
- CC: www-voice@w3.org
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 10.5.9.1 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 -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Received on Friday, 20 August 2010 14:56:47 UTC