Re: CCXML: Dialog and Connection objects ISSUE-236 / ISSUE-237 [cc]

Petr/Hrvoje:

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:37:21, RJ Auburn wrote:

>
> Petr/Hrvoje,
>
> We actually did a pretty major cleanup based on this thread and we  
> feel that the current spec addresses a lot of the little  
> inconsistencies that were in the spec prior to this.
>
> A quick summary of the current state of affairs is below:
>
> ------------- START --------------
> 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
>
> ------------- END --------------
>
> Additionally we added references to the actual dialog/conference/ 
> connection objects on the conference.join/unjoined events.
>
> The end result is we feel that the current spec now presents a  
> consistent model for inputs and outputs across all the different  
> media objects.
>
> Please let us know if these changes address your concerns. If there  
> are still outstanding issues we would be happy to work with you  
> future to try and address what needed to be done. If we do not hear  
> back from you by April 17th 2008 we will consider this issue closed  
> in our issue tracker system.
>
> Thank you very much for your valuable comments on the CCXML  
> specification.
>
> Best regards,
>
> 	RJ
>
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> tel:+1-407-418-1800
>
>
>
> On Mar 15, 2007, at 09:30:05, Hrvoje Nezic wrote:
>>
>> ----- Original Message ----- From: "Petr Kuba" <kuba@optimsys.cz>
>> To: <www-voice@w3.org>
>> Cc: "Hrvoje Nezic" <hrvoje.nezic@envox-lab.hr>
>> Sent: Thursday, March 15, 2007 1:04 PM
>> Subject: Re: CCXML: Dialog and Connection objects
>>
>>
>>> Dear Hrvoje,
>>> thanks for your comments and let me add some notes in-line.
>>>
>>> However I would still appreciate further clarification on my  
>>> original comments.
>>>
>>> Hrvoje Nezic wrote:
>>>>> Dialog object contains connectionid and/or conferenceid  
>>>>> properties which
>>>>> identify the connection/conference that is driving a media  
>>>>> stream to the
>>>>> dialog.
>>>>
>>>> The specification doesn't explicitly state that the connection/ 
>>>> conference
>>>> is driving a media stream to the dialog, but this is a reasonable  
>>>> interpretation.
>>>
>>> See CCXML specification (version 20070119), section 7.4 Dialog  
>>> object properties, description of the connectionid property which  
>>> explicitly states:
>>> "Identifies the connection that is driving a media stream to the  
>>> dialog. ..."
>>> The same holds for the conferenceid property.
>>>
>>>> However, other interpretations are also possible, because the  
>>>> specification
>>>> states that the connection/conference is "associated" with the  
>>>> dialog.
>>>
>>> Statement like this is in the Connection object description, not  
>>> Dialog object. The specification is very clear for the Dialog  
>>> object.
>>>
>>>> For example, connection/conference could be the one specified in  
>>>> <dialogprepare>
>>>> or <dialogstart> although it doesn't drive a media stream to the  
>>>> dialog.
>>>
>>> This is wrong.
>>>
>>>>> As we understand, after introducing input and outputs properties  
>>>>> in the
>>>>> last draft connectionid/conferenceid will always have the same  
>>>>> value as
>>>>> the input property.
>>>>
>>>> There are still no input and output properties in <dialogprepare>  
>>>> and <dialogstart>.
>>>> I think that the specification should introduce these properties  
>>>> instead of
>>>> connectionid / conferenceid.
>>>
>>> Input and outputs properties in the Connection and Dialog objects  
>>> serve for storing information about all the endpoins bridged to  
>>> the particular connection / dialog. Connectionid / conferenceid in  
>>> <dialogprepare> /
>>> <dialogstart> and joinid in <createcall> serve for establishing  
>>> one new bridge. You do not need input / outputs properties in  
>>> <dialogprepare> /
>>> <dialogstart> / <createcall> tags.
>>
>> Petr,
>>
>> Of course, you are right. Please read my previous message: I was
>> "too quick on trigger" and because these days I am not occupied  
>> with CCXML
>> at all, I confused some things. I apologize again.
>>
>> Hrvoje
>>
>>
>
>

Received on Thursday, 24 April 2008 12:22:29 UTC