CCXML WD 19012007 - Limiting amount of connection inputs and other comments.

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