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, 7 May 2009 09:55:46 -0400
Cc: www-voice@w3.org, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>
Message-Id: <FB8A3F0C-3E27-4CD4-87ED-C0DDC618516F@voxeo.com>
To: Teemu Tingander <Teemu.Tingander@tecnomen.com>

Would you please be able to confirm that these resolutions are  
acceptable for you? If they are not can you please let us know by  
5/14. If we don't hear anything by that date we are going to consider  
these non critical and move forward on the the next stages of  

Best regards,


RJ Auburn
CTO, Voxeo Corporation

On Apr 9, 2009, at 10:10 AM, RJ Auburn wrote:

> Teemu,
> 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?
> Thanks,
> 	RJ Auburn
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> Chair, Editor and Chair, CCXML, VBWG, W3C
Received on Thursday, 7 May 2009 13:56:33 UTC

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