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

Teemu,

We just completed the call and had the following comments on your items:

Item 1:

While the working group agrees this could be a helpful feature  
enhancement the issue is that at this stage of the spec it would be a  
substantial change and trigger going back to another working draft  
instead of moving to candidate recommendation. Given there are other  
(slightly suboptimal) ways to support this specific use case we will  
defer this type of change to 1.1 and make sure it gets addressed at  
that point.

Item 2:

We think there's just confusion over the fact that we said that the  
platform must implicitly tear down bridges.  That's different from  
saying the platform must tear down implicit bridges; We don't think we  
ever meant to say that implicit vs. explicit bridges would be handled  
differently on a <dialogterminate>.  It seems that this could be  
resolved relatively easily by simply dropping the word "implicitly" at  
the tail end of 7.2.3.1.

Please let us know if these address your concerns. If that is the case  
then we will continue to move forward on publishing as the candidate  
recommendation.

Best regards,

	RJ

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

On May 14, 2009, at 8:21 AM, RJ Auburn wrote:

> 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 15:42:21 UTC