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

Teemu,

Thanks for this feedback. We are tracking this as ISSUE-570.

	RJ

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

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.
> 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.
>
>
> BR
> -          Teemu
>

Received on Thursday, 19 February 2009 14:38:11 UTC