W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2009

Re: CCXML WD 19012007 - Limiting amount of connection inputs and other comments. [cc] ISSUE-570

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 9 Apr 2009 10:10:41 -0400
Cc: www-voice@w3.org, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>
Message-Id: <DA137C81-90CA-42C4-A8B3-12E70234604F@voxeo.com>
To: Teemu Tingander <Teemu.Tingander@tecnomen.com>

The working group has reviewed your mail and has a few questions and  
comments on our e-mail. Details are inline:

> On Feb 17, 2009, at 4:55 AM, Teemu Tingander wrote:
>> Dear WBWG
>> I have found few issues in current CCXML working draft  that I  
>> would like to have clarified or reasoned. I’m not currently working  
>> with  CCXML interpreter so unfortunately my comments do not cover  
>> the whole document.
>> 1.       <join/> - Limiting inputs to only one is not well  
>> reasoned. There seems to be no good reason for limiting connection  
>> objects input to only one. If platform is capable of “mixing” input  
>> the specification should not disallow this. When media “splitting”  
>> is allowed with outputs the mixing of input should be equally  
>> allowed, taking in account the systems capabilities.
>> a.       For example a Connection that is joined to conference and  
>> system wants to play audio periodically to caller. This should be  
>> allowed without leaving conference. Conference object joined with  
>> dialog is capable of doing this why should the connection object be  
>> more limited.
>> b.      Limiting inputs to only one as in current WD, causes <join/ 
>> > command to tear down some bridges or change their duplex without  
>> explicit request to do so. I think that this automation is  
>> confusing. If system does not support multiple inputs and <join/>  
>> request would cause that happen, the <join/> request should fail  
>> with error event.
>> c.       If this limitation is removed the complex  automation  
>> logic defined in chapters 10.4.1 and 10.4.2  would be obsolete
>> d.      The clause in chapter 10.4. “Note that <join> MUST NOT be  
>> used to add a Connection to an existing two-party bridge in order  
>> to create a 3-way Conference Instead” does not make any sense.
>> i.      In current scenario  proposed in current specification, A  
>> would hear C and  C would hear A , but B would only hear A without  
>> ablity to speak to A (the outcome of fullduplex , <join id1=”a”  
>> id1=”b” />  and <join id1=”a” id2=”c” />).
>> ii.      Without limiting inputs to 1  and as special case 3 party  
>> network style conferencing could be achieved with full duplex  
>> joins , <join id1=”a” id1=”b” />  and <join id1=”a” id2=”c” /> and  
>> <join id1=”b” id2=”c”/>. On the long run, this is not very  
>> efficient way of conferencing and specification could make this  
>> opinion know but should retain from making it non-conformant.
>> e.      If the system is capable of capturing input ( for example  
>> “DTMFS”)  to one dialog form multiple connections, why to rule out  
>> this possibility even thou it might be quite uncommon.

The working group understands your and very much appreciates this use  
case but at this stage in the spec it's too major of a change to make  
in CCXML 1.0. We would consider and would likely address this in a  
follow up version but trying to make that change at this point would  
trigger many implications in the process and existing implementations.

We do think that most of the cases can be addressed by utilizing  
Conference objects. While this may not be as elegant from a programing  
perspective it should allow some of these applications to be created.

Please let us know if tracking this as a CCXML 1.1 feature request  
would satisfy you for now.

>> 2.       7.3.2 <dialogterminate/> - At just end of chapter, Current  
>> WD states “The platform MUST implicitly tear down any existing  
>> bridges to the dialog and send a conference.unjoined to the CCXML  
>> document once the media paths have been freed.”  This clause should  
>> only match explicit bridges to dialogs, as defined in 10.4. This  
>> should be defined in specification more clearly, unless,  In  
>> context of <dialogstart/> and <dialogprepare/> and the definition  
>> of Implicit bridges in chapter 10.4, sending conference.unjoined  
>> does not follow the line.

We are having a little trouble understanding the exact issue here.  
Could you possibly expand on this and provide an example use case and  
call event flow where there would be a problem?


	RJ Auburn

RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C
Received on Thursday, 9 April 2009 14:11:33 UTC

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