[Standards-JIG] RE: Jingle channel naming (was Jingle schema extensibility)
jean-louis.seguineau at laposte.net
Thu Apr 6 16:33:07 UTC 2006
As for the use of 'cid', we may well return back to using 'name' and say
that the cid is (name, did). Anyway, if this is all what's left I'm sure
we'll find something appropriate ;)
Joe, would you able to illustrate what we discussed for a case where we have
two descriptions one for audio, and one for video. I believe you would be
comfortable doing that for the ICE transport. That would help us check if we
are really on the right track. For my part, I am going to check if I could
represent some of the uses cases given in RFC4317 SDP Offer/Answer Examples.
In this case, I'd be using the raw-udp profile.
Thanks in adavance
Thanks for being patient Jean-Louis -- I think we are making progress here.
(I'm not sure if anyone else on the list cares though ;)
On 4/5/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
> Total agreement on point 1/ (you just called 'did' what I called 'mid'
> because of the media type definition)
> The result for partial negotiation or rejection is definitively a plus.
> I got the idea for point 2/ that we only allow one negotiation type per
> Jingle session, hence one <transport/>. Agreed.
> As to point 3/, does this mean that once a negotiation has reached an
> agreement, we have, in the context of your example, a channel being
> composed of a <description/> and a <candidate/>? Obviously this
> will change dynamically if the channel is renegotiated during the session.
> Did I get you right?
I would put it this way. The requirement for the channel is defined by the
description. It is up to the transport to provide/implement this channel.
The candidate message is really part of the description format. A transport
should feel free to use whatever syntax necessary to implement the channel.
I used it here as it is part of the ICE transport and gives us something
concrete. For the raw UDP transport, I would actually prefer to call the
elements under the <transport> element <channel> or <socket> instead of
On more general terms, isn't it enough to say that a channel is "An abstract
> way to get a stream of data packets from one description to another." The
> channel behavior being further described in each description's JEP. And
> obviously we may find description that will not require a real physical
> transport to compose a channel. Is this correct?
I'm not sure how tightly we should lock down the service contract for a
channel. We might want to leave this undefined right now as you suggest.
If we do define it, we should go with the lowest common denominator (packet
loss, unordered) I think.
>From point 4/ I believe I get the idea of channel as a way of naming the
> above association between a media type <description/> and a particular
> physical transport (expressed by a <candidate/>). Is this correct?
> Am I right in saying that a cid will remain fixed for the entire duration
> the Jingle session?
Yes -- the cid for a particular channel should remain fixed. I would think
that a <description> can add/remove channels dynamically if necessary. (For
instance, I may add video to an av session during media-info negotions.)
What I find misleading though is the use of cid (channel ID), because in
> fact a channel is identified by what you call a 'cid' and a 'did'. So we
> relate it to a particular <candidate/> through the two attributes cid and
> did. I would be more comfortable if we could change cid into some other
> acronym ;)
I get what you are saying. The cid isn't unique -- only the (cid, did) pair
is unique. Do you have any suggestions for naming here?
For point 5/ have you already found uses cases mandating a static definition
> of a channel? What would be against having the reference always dynamic
> (that could includes no channel reference for certain sessions)? If we
> it dynamic, I suppose we will need a way to express it?
Right now Talk uses a static name for the channel ('rtp') and it works
well. Requiring all names to be allocated dynamicly could make very simple
description JEPs more complex. Since they don't need to be unique (only be
unique in the context of the did) there is no reason to be dynamic in this
I believe we're getting closer :)
More information about the Standards