[Standards-JIG] RE: Jingle channel naming (was Jingle schema extensibility)

Joe Beda jbeda at google.com
Wed Apr 5 23:43:16 UTC 2006

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 ;)

Comments inline.

On 4/5/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
> Joe,
> 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
> association
> 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
> of
> 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
> make
> 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 :)
> Jean-Louis
> -----Original Message-----
> Message: 1
> Date: Wed, 5 Apr 2006 10:12:28 -0700
> From: "Joe Beda" <jbeda at google.com>
> Subject: Re: [Standards-JIG] RE: Jingle channel naming (was Jingle
>         schema  extensibility)
> To: "Jabber protocol discussion list" <standards-jig at jabber.org>
> Message-ID:
>         <dbfdfee20604051012k29f21642w28ee1768f6442cc5 at mail.google.com>
> Content-Type: text/plain; charset="iso-8859-1"
> Here are some proposed changes to address these issues:
> 1) Earlier we decided to allow multiple <description/> elements to be
> active
> at the same time.  This allows us to add whiteboarding to an audio
> session,
> for instance.  One thing that we didn't talk about is allowing multiple
> descriptions of the same *type* (namespace) to be active at once.  To
> allow
> this we should my add a description id (did) to each description element.
> It might look something like this:
> <jingle type='inititate' sid='sid-0' ...>
>   <description xmlns='desc-ns-0' did='did-0'>...</description>
>   <description xmlns='desc-ns-0' did='did-1'>...</description>
> </jingle>
> In this way the user can accept/reject either of these and we can identify
> them from each other.  There should also be a way to specify which
> description a 'session-info' message is sent to.
> 2) We still only have one and only one transport negotiated per session.
> That transport should be able to support multiple channels.
> 3) A channel is changed to be defined as "An abstract way to get a stream
> of
> data packets from one description to another.  The transport is not
> required
> to be reliable or to preserve order."
> 4) A channel is identified uniquely by the tuple (<channel
> id>,<description
> id>).   (I'm renaming the channel name attribute to "channel id" or 'cid'
> for short).
> 5) The requirement for a channel is defined by the description.  This
> could
> either be done staticly in the JEP for the description (say voice always
> uses a cid of 'voice-rtp') or could be done dynamicly by the description.
> Adding this in, we would end up with something like this.  (Assuming that
> the 'desc-ns-0' description statically requires a channel with
> cid='cid-0')
> <jingle type='inititate' sid='sid-0' ...>
>   <description xmlns='desc-ns-0' did='did-0'>...</description>
>   <description xmlns='desc-ns-0' did='did-1'>...</description>
>   <transport xmlns='trans-ns-0'>...</transport>
> </jingle>
> Negotiation of channels happens via transport-info messages:
> <jingle type='transport-info' sid='sid-0' ...>
>   <transport-info xmlns='trans-ns-0'>
>     <candidate cid='cid-0' did='did-0' .../>
>     <candidate cid='cid-0' did='did-1' .../>
>   </transport-info>
> </jingle>
> Does this make any sense or are we just missing each other? :)
> Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060405/c18ed553/attachment.html>

More information about the Standards mailing list