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

Teemu,

Thanks for the feedback. We will be reviewing your comments on todays  
call and will get back to you right away.

	RJ

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

On May 14, 2009, at 5:13 AM, Teemu Tingander wrote:

> Hi !
>
> Thank You for reviewing my comments.
>
> 1st case:
>
> About the degree of change: In my opinion, this change I proposed here
> would simplify both the implementation and CCXML bridge usage. This is
> due lack of complex logic that would be removed. As always, all  
> changes
> do have some impact on pre-standard implementations but this should  
> not
> be an issue why not to change the proposal. I see that this change  
> would
> be very beneficial for new CCXML interpreter implementations and the
> impact on existing pre-standard implementations would not be that big.
>
> If this is too late for addressing this case in 1.0, I certainly hope
> that 1.1 will bring it up.
>
> Using conference for this particular use-case does not seem that good
> approach.
>
> 2nd case:
>
> The bottom line in here is: Separation between of "explicit" and
> "implicit" bridges should not exist.
>
> Bridges  ("explicit") joined with <join/> do produce _joined_ event at
> creation and _unjoined_ at destruction.
>
> Bridges  ("implicit") created with <dialogstart/> associated with
> connectionid or with <dialogprepare/> do start bridge without explicit
> <join/> and thus this they for some reason won't cause
> <conference.joined/> event. Still in 7.3.2 <dialogterminate/> it is
> requested to throw _unjoined_ event for all bridges bound to current
> dialog.
>
> Bridge creation should be symmetric and for each bridge (explicit)
> creation should produce _joined_ and destructon _unjoined_ event. If
> Implicit bridges won't produce _joined_ should their destruction not
> throw _unjoined_ either.
>
> Associating Dialog with connection ( conference or call ) should not
> cause implicit join. It should just provide session.connection
> information to dialog. Bridging this dialog to call (or conference)
> should be performed by <join/>. Like <dialogterminate/> should  
> result to
> associated events including possible _unjoined_, in case there was
> bridge to this dialog. This would remove "mediadirection" need from
> <dialogstart/> and <dialogprepare/> as well as combine conferenceid  
> and
> sessionid to one single connectionid ( to provide session.connection
> information to dialog ).
>
> Another solution for this would be prohibiting bridges to dialogs and
> instead dialogs would always be started and bound to existing
> connections or conferences. In this case _joined_ and _unjoined_  
> events
> could be removed.
>
> Another possible scenario would be to use <createcall/>s notation
> (joinid) (that causes joined event according to attribute  
> description).
> Still the need for joinid versus <join/> is questionable.
>
> As a sidenote: I do think that conference.joined is a misleading event
> name for bridging call to dialog or to another call since bridge is
> creted between two connections "(call, conference or dialog)".
> Conference.joined and unjoined do sound more like "conference" events
> than "bridge" events. ( events from conference vs. events from actions
> ).
>
> Hopefully this solves the 2nd comment. I do have many other issues  
> in my
> sleeve but in sake of getting CCXML 1.0 out I try to keep thos in  
> there.
>
>
> - Teemu
>
> -----Original Message-----
> From: RJ Auburn [mailto:rj@voxeo.com]
> Sent: 07 May 2009 16:56
> To: Teemu Tingander
> Cc: www-voice@w3.org; W3C Voice Browser Working Group
> Subject: 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, 14 May 2009 12:22:42 UTC