(SPAM: 5.957) RE: [Standards-JIG] Jingle schema extensibility

Joe Beda jbeda at google.com
Mon Apr 3 20:07:16 UTC 2006

I see.  What you are saying is that there is no explicit declaration of what
channels a session requires a transport to provide?

I was assuming that this would be documened as part of the session JEP.
Some sessions would define one statically named channel (the poorly named
'rtp' channel for audio right now) while others may be more dynamic.  Is
there some scenario where you think they need to be called out explicitly?
All else being equal, I'd rather the protocol be less chatty if possible.

As long as we are talking about channel naming, we are facing at least one
problem right now with respect to the naming of channels:  Now that we can
have multiple sessions in play at once (not in the spec yet but we decided
that, right?) we need to name a channel in a way that binds it to a session.

I would suggest that we use URIs for channel names but I'd be afraid it
would get too verbose.  Any other ideas?


On 4/3/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
> Joe, I am in agreement with what you said. My question was related to the
> notion of channel. Now that we have de-coupled the various pieces session,
> media description and transport, am I right in saying that channel is
> linked
> to transport? If this is the case, then do you think it possible to have a
> common approach for all transports types were the name of the channel
> would
> be always declared the same way?
> >From your answer, I have the feeling this is not the case. How then can
> we
> ensure channels are properly named?
> Jean-Louis
> -----Original Message-----
> Message: 2
> Date: Mon, 3 Apr 2006 09:40:00 -0700
> From: "Joe Beda" <jbeda at google.com>
> Subject: Re: [Standards-JIG] Jingle schema extensibility
> To: "Jabber protocol discussion list" <standards-jig at jabber.org>
> Message-ID:
>         <dbfdfee20604030940n5c9c0a29naf1fe420bd760114 at mail.google.com>
> Content-Type: text/plain; charset="iso-8859-1"
> My thinking is that a channel has a name associated with it.  It is up to
> the session type to define the streams to be used and push data over them.
> It is up to the transport to provide a way to move that data from one peer
> to another.  While most of the transports so far use something like a
> <candidate/> element to define a channel (or a possible route for a
> channel)
> this isn't necessary for all transports.
> For example, for JEP-0177, it might make more sense to have a <channel/>
> element under the transport instead of <candidate/> since there is one and
> only one choice.
> Joe
> On 4/2/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
> >
> > JEP-166's glossary describes a channel as a 'named way to get
> information
> > between the endpoints...'  From the rest of the description I am under
> the
> > impression that a channel is linked to the transport of a media type.
> >
> > In effect, from the various transport JEPs, it appears that the common
> > practice id to have a <candidate/> element as a child of a <transport/>
> > element. And the name attribute is described as required for most all of
> > them except JEP-179.
> >
> > This is just an example of potential interpretation issues. Couldn't we
> > include additional schema definitions in JEP-166 describing the
> mandatory
> > attributes of <transport/>, <candidate/> and <description/> in addition
> to
> > open extensibility (xs:any)?
> >
> > The idea is not to indicate that, if these <transport/>, <candidate/>
> and
> > <description/> are to be used in their respective application context,
> > then
> > they must provide a minimum required information. We could do this in
> high
> > level JEPs for media description and transport, but it seems adequate to
> > use
> > JEP-166 for this.
> >
> > Jean-Louis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060403/4f5b03a4/attachment.html>

More information about the Standards mailing list