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

Re: query. - ISSUE-234

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 24 Apr 2008 08:25:57 -0400
Cc: www-voice@w3.org, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>
Message-Id: <33E8F456-0253-4506-988A-7ED114DB35EE@voxeo.com>
To: murulidharar@huawei.com

Murali,

Since we have not heard any update from you we are going to go on and  
consider this issue resolved. Thank you very much for your comments on  
the CCXML specification.

Best regards,

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



On Mar 27, 2008, at 09:21:02, RJ Auburn wrote:

>
> Murali,
>
> Sorry for the late reply here. The working group ended up making a  
> number of changes in this area that we think will greatly help  
> address this issue. The key item was a reworking of the connection/ 
> dialog/conference objects to be more flexible in what information  
> they convey. A quick summary of the current state of affairs is below:
>
> Dialog Object Properties:
> 	dialogid	This property is the ECMAScript string value of the
> 			Dialog Identifier, which uniquely identifies each
> 			instance of the Dialog class.
> 	input		As defined by the Media Endpoint Object in 10.4.3.
> 	outputs		As defined by the Media Endpoint Object in 10.4.3.
> 	objecttype	This property states the type of this object which must  
> be 'dialog'
>
> Connection Object Properties (only properties of interest, not a  
> complete list):
> 	connectionid	This property is the ECMAScript string value of the
> 			Connection Identifier, which uniquely identifies each
> 			instance of the Connection object
> 	input		As defined by the Media Endpoint Object in 10.4.3.
> 	outputs		As defined by the Media Endpoint Object in 10.4.3.
> 	objecttype	This property states the type of this object which must  
> be 'connection'
>
> Media Endpoint Object (10.4.3)
>
> 	input		The identifier (connectiondid/conferenceid/dialogid) of the
> 			single media endpoint (connection, dialog or conference) providing
> 			the input stream to this media endpoint or undefined if
> 			there is no input stream. This property MUST be updated each
> 			time a <join>/<unjoin> or any other media operation changes
> 			the media source to this media endpoint. If the media endpoint
> 			does not have a media source the value MUST be ECMAScript  
> undefined.
> 			For example the creation of a half duplex bridge
> 				<join id1="con1" id2="con2" duplex="half" />
> 			Result
> 				session.connections[con1].input = "con2"
> 				session.connections[con2].input = undefined
>
> 	outputs		An array containing the identifiers of all media endpoints  
> to which
> 			the output stream of this media endpoint is sent. If the media  
> endpoint
> 			does not have any media destinations the length of the array MUST  
> be 0.
> 			For example the creation of a half duplex bridge
> 				<join id1="con1" id2="con2" duplex="half" />
> 			Result
> 				session.connections[con1].outputs.length = 0
> 				session.connections[con2].outputs.length = 1
>
> The end result is we got rid of the dedicated dialogid/connection id  
> references an instead replaced them with generic array references  
> that more accurately reflect the real state of the underlying  
> connection model.
>
> The working group feels that these changes should address your  
> concerns and allow for the flexibility requested. If you disagree  
> with this statement please let us know and we would be happy to see  
> what we can do to address your concerns. If the working group does  
> not hear back from you by April 17th however we will consider this  
> resolution acceptable and will close out the issue from our list of  
> open issues.
>
>
> Thank you very much for your continued comments on the CCXML  
> specification.
>
> Best regards,
>
> 	RJ
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> Editor and Chair, CCXML 1.0, W3C
>
>
>
> On Sep 28, 2007, at 01:26:32, murulidhara wrote:
>> Hi,
>> Sorry , I had problem with the mpdification text , and I think I  
>> unknowingly sent that your voxeo id (on 30-5-2007).
>> Find my analysis here on the modified text:
>> Only modifying section will create ambiguity between section  
>> 7.1.1.1 and dialog object(7.4) section. In dialog object section it  
>> is mentioned that
>> "connectionid of dialog object Identifies the connection that is  
>> driving a media stream to the dialog. If the media stream to the  
>> dialog is not being driven by a connection, then this property must  
>> be undefined.
>> Note: connectionid and conferenceid properties are mutually  
>> exclusive."
>> So, this also needs to be modified.
>> Also, I think we must make dialogid property of connection object  
>> must be an array, Here is the use case :
>> When application gets connection.alerting , application might  
>> prepare 2 dialogs on that connection thinking that one of the 2  
>> will be selected based on some parameter in connection.connected.
>> This scenario will create problem if we have single dialogid in  
>> connection object:
>> 1. prepare dialog x and y on connection conn1
>> 2. now connection object can only contain one dialog id i.e x or y  
>> based on the order of preparation.
>> 3. now suppose instead of connection.connected ,connection.failed  
>> is received.
>> 4. in connection.failed transition, application needs to clean up  
>> its associated resource.
>> 5. but there is no way for application to know that there are 2  
>> dialogs x and y associated with it. So he will miss out on  
>> executing <dialogterminate> for either dialog x or y.(note bridges  
>> in connection object will be updated only when dialog.started is  
>> received)
>>
>> Regards,
>> murali
>>
>> -----Original Message-----
>> From: RJ Auburn [mailto:rj@voxeo.com]
>> Sent: Thursday, September 27, 2007 7:35 PM
>> To: murulidharar@huawei.com
>> Cc: www-voice@w3.org; W3C Voice Browser Working Group
>> Subject: Re: query. - ISSUE-234
>>
>> Murulidhara,
>>
>> As we have not heard any comments back on our response from you we
>> are closing this issue out in our tracking system.
>>
>> Thank you very much for the feedback on the CCXML specification.
>>
>>    RJ
>>
>>
>> On May 17, 2007, at 10:01 :12, RJ Auburn wrote:
>>
>> >
>> > Murulidhara:
>> >
>> > This issue number got reassigned to ISSUE-234.
>> >
>> > The CCXML subgroup has added the following text to section 7.2.1.1
>> > (<dialogprepare>) to clarify the intended behavior:
>> >
>> >> If the connectionid or conferenceid attributes are specified on
>> >> <dialogprepare> the Dialog Object's connectionid/conferenceid
>> >> properties MUST be set to the appropriate values. Additionally the
>> >> dialogid attribute of the Connection Object MUST be set to the
>> >> dialogid of the new Dialog.
>> >
>> >
>> > Please let us know if this resolves your question. If we do not
>> > hear from you by 6/1/2007 we will consider this issue resolved.
>> >
>> > Thanks,
>> >
>> >   RJ
>> >
>> > ---
>> > RJ Auburn
>> > CTO, Voxeo Corporation
>> > Chair, Call Control Subgroup, VBWG.
>> >
>> >
>> >
>> >
>> > On Feb 8, 2007, at 10:35 AM, RJ Auburn wrote:
>> >
>> >>
>> >> This is being tracked as ISSUE-110
>> >>
>> >> RJ
>> >> ---
>> >> RJ Auburn
>> >> CTO, Voxeo Corporation
>> >> tel:+1-407-418-1800
>> >>
>> >>
>> >>
>> >> On Jan 22, 2007, at 6:55 AM, murulidhara wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>>
>> >>> I had a Query regarding the creation of bridges in case of
>> >>> implicit join to a connection using <dialgprepare>
>> >>>
>> >>> PROBLEM:
>> >>>
>> >>> 1.       create a session.
>> >>>
>> >>> 2.       create 2 connections say conn1 and conn2.
>> >>>
>> >>> 3.       preapare dialog x on conn1
>> >>>
>> >>> 4.       preapare dialog x on conn2
>> >>>
>> >>> since the “Implicit bridges created using <dialogprepare>/
>> >>> <dialogstart> (by specifing 'connectionid' or 'conferenceid') are
>> >>> established when the dialog is started. No bridging events are
>> >>> generated; the 'dialog.started' event indicates that the dialog
>> >>> was started and the bridge is in place.” Connection object will
>> >>> not be updated till dialog.started is received. And  so
>> >>> Connection objects of both conn1 and conn2 will not contain
>> >>> dialog id which are just been prepared on them. Only session
>> >>> object will be updated.
>> >>>
>> >>>
>> >>> So now.
>> >>>
>> >>> Say conn1 gets connection.failed.
>> >>>
>> >>> Now if I want to clear the dialog created on conn1 then I cant
>> >>> access dialogid through event$.connection.dialogid  as connection
>> >>> object is not updated.(dialog is not started still) , I cant even
>> >>> access it through session variables. As session variable will
>> >>> intern access connection object.
>> >>>
>> >>> And also session.dialogs[] , will give dialog id but they don’t
>> >>> give to which connection the dialog belongs.
>> >>>
>> >>> So , how can I access the dialog id of conn1.
>> >>>
>> >>>
>> >>> Please let me know.
>> >>>
>> >>>
>> >>> Regards,
>> >>>
>> >>> Murali dhar R
>> >>>
>> >>>
>> >>>
>> >>> This e-mail and attachments contain confidential information from
>> >>> HUAWEI, which is intended only for the person or entity whose
>> >>> address is listed above. Any use of the information contained
>> >>> herein in any way (including, but not limited to, total or
>> >>> partial disclosure, reproduction, or dissemination) by persons
>> >>> other than the intended recipient's) is prohibited. If you
>> >>> receive this e-mail in error, please notify the sender by phone
>> >>> or email immediately and delete it!
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>
>
Received on Thursday, 24 April 2008 12:26:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 April 2008 12:26:49 GMT