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

Joe Beda jbeda at google.com
Tue Apr 4 21:06:52 UTC 2006


This is very close to what I was thinking.  The one difference is that it
should be possible for a single description to define more than one stream.
For example, a "audio+video" session might have "rtp-audio" and "rtp-video"
streams.  On top of that, there might be another description that does
whiteboarding that defines a "wb" stream.

In that case, a channel is defined by a description and provided by a
transport.  We need a way to name these in the transports so that they don't
conflict if there are multiple descriptions on the same channel.  (So that
you could have description 1 that defines a 'data' channel and description 2
that also defines a 'data' channel.)

Here are the solutions I can think of for this problem:
1) Require that all descriptions allow for channels to be named dynamicly.
In this case, the entity putting together the descriptions would guarantee
that names didn't overlap.
2) Use the namespace of the descrition to help define the names.  Then there
would be something like <candidate name='rtp' description='
http://jabber.org/protocol/jingle/media/audio' ... />
3) Put ids on the descriptions and use those to help identify the channels:
<description xmlns='...' did='mydescription' />
<transport>
  <candidate name='rtp' did='mydescription' ... />
</transport>

I'm in favor of 1 or 3.  I think that 2 is too verbose.  Other ideas here?

Joe

On 4/4/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
>
> I was under the impression that we were going toward a construct like this
> for multiple media streams:
>
> <jingle xmlns='http://jabber.org/protocol/jingle' ...
>           sid='a73sjjvkla37jfea'>
>     <description xmlns='http://jabber.org/protocol/jingle/media/audio'>
>     ... description for audio media
>     </description>
>     <description xmlns='http://jabber.org/protocol/jingle/media/video'>
>     ... description for video media
>     </description>
>     <transport ...>
>     </transport>
> </jingle>
>
> The communication session is encapsulated by the <jingle/> element and
> identified by its 'sid'. Every media stream is described in a separate
> distinct <description/> element, each in its own namespace.
> Now on the transport front I suppose we have to make an offer with several
> of them. And in that case you are right in saying we must have some way of
> binding a particular transport to a particular media stream. The principle
> could be something like:
>
> <jingle xmlns='http://jabber.org/protocol/jingle' ...
>           sid='a73sjjvkla37jfea'>
>     <description xmlns='http://jabber.org/protocol/jingle/media/audio'
>     id='audio'>
>     ... description for audio media
>     </description>
>     <description xmlns='http://jabber.org/protocol/jingle/media/video'
>     id='video'>
>     ... description for video media
>     </description>
>     <transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'
>     id-ref='audio'>
>     </transport>
>     <transport xmlns='http://jabber.org/protocol/jingle/transport/rtp-ice'
>     id-ref='audio'>
>     </transport>
>     <transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'
>     id-ref='video'>
>     </transport>
> </jingle>
>
> Do not put any special meaning behind the attributes added to description
> and transport. Their only purpose is to indicate that a particular
> transport
> is linked to a particular media stream description.
>
> Is this what you are referring to? And where would the notion of 'channel'
> appear then?
>
> Jean-Louis
>
>
> -----Original Message-----
> Message: 3
> Date: Mon, 3 Apr 2006 13:07:16 -0700
> From: "Joe Beda" <jbeda at google.com>
> Subject: Re: (SPAM: 5.957) RE: [Standards-JIG] Jingle schema
>         extensibility
> To: "Jabber protocol discussion list" <standards-jig at jabber.org>
> Message-ID:
>         <dbfdfee20604031307v3eca6dedj1a19f702d27072cd at mail.google.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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?
>
> Joe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060404/229f3715/attachment.html>


More information about the Standards mailing list