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

Teemu,

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  
publication.

Best regards,

	RJ


---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

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