Re: query. - ISSUE-234

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, 27 March 2008 13:22:22 UTC