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

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Wed Apr 5 20:45:31 UTC 2006


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? 
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? 

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

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?

I believe we're getting closer :) 


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

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>

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' .../>

Does this make any sense or are we just missing each other? :)


More information about the Standards mailing list