Re: Notification of implicit bridge teardowns - ISSUE-525

Derek:

The working group reviewed your question and has the following response.

> CCXML platforms do not generate ‘conference.unjoined’ events as a  
> result of implicit teardowns when applications perform <join>/ 
> <unjoin> or equivalent actions (such as <createcall> with a joined),  
> regardless of whether these teardowns are partial or complete.  The  
> reason for this is that such teardowns are a direct consequence of  
> actions taken by the application, for which outcome events already  
> exist (‘conference.joined’/’conference.unjoined’ against the media  
> endpoints directly affected).  State variables for both directly and  
> implicitly affected media endpoints are updated when this primary  
> events fires; failing to do so would result in inconsistent session  
> state between the two events when bridges appeared to exist that in  
> actuality do not.  By contrast, the ‘conference.unjoined’ events  
> specified to 10.6.14 exist to ensure that media bridges are  
> determined entirely using ‘connection.joined’ and  
> ‘connection.unjoined’ events, rather than being derived from call  
> control events such as ‘connection.disconnected’.


Hopefully this clarification addresses your concern. If you have any  
follow up questions please let us know.

Best regards,

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

On Jul 17, 2008, at 10:33 AM, RJ Auburn wrote:

> Derek:
>
> This is being tracked as ISSUE-525. Thanks for the feedback and we  
> will have an answer for you shortly.
>
> Best regards,
>
> 	RJ
>
> On May 30, 2008, at 1:23 PM, Sanders, Derek (Derek) wrote:
>
>>
>> The January 19th, 2007 CCXML Working Draft is not very clear on how  
>> implicit bridge teardowns resulting from a <join> should be  
>> handled.  Section 10.4.1 shows all of the possible outcomes of a  
>> <join> tag.  Some of these examples require a full or partial  
>> teardown of an existing bridge.  The spec does not state if a  
>> ‘conference.unjoined’ event should be generated when this occurs.   
>> It does state in section 10.6.14 that if a connection is dropped  
>> (as in a merge, disconnect, etc.), then the appropriate  
>> ‘conference.unjoined’ event(s) should be sent.  It may be an easy  
>> assumption that ANY implicit bridge teardowns should result in a  
>> ‘conference.unjoined’ event, but what about partial teardowns?  It  
>> starts to get a little more complicated there.  Is it enough to  
>> just update the connection state variables when bridges change as a  
>> result of a <join>?
>>
>> Thanks,
>> -Derek Sanders
>>
>

Received on Tuesday, 25 November 2008 03:48:18 UTC