W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2009

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

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 14 May 2009 08:21:54 -0400
Cc: <www-voice@w3.org>, "W3C Voice Browser Working Group" <w3c-voice-wg@w3.org>
Message-Id: <886409B9-01D4-4D19-8726-1292A3B4B60C@voxeo.com>
To: "Teemu Tingander" <Teemu.Tingander@tecnotree.com>

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


RJ Auburn
CTO, Voxeo Corporation

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:40 UTC