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

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


Let's try to dig into this further. But first, I believe we should agree on
wording definition. I believe RFC3388 http://www.ietf.org/rfc/rfc3388.txt
addresses some of these naming definitions.

Media stream is defined as a single media instance, e.g., an audio stream or
a video stream as well as a single whiteboard or shared application group.
This is mapped to the Jingle <description/> element. A media stream is
identified by a mid (media ID)

Media flow is defined as the association of a single media instance, e.g.,
an audio stream or a video stream as well as a single whiteboard or shared
application group.  When using RTP, a media flow comprises one or more RTP
sessions. This can be mapped to a tuple comprised of a Jingle <description/>
element and one or more <transport/> elements. A media flow is identified by
a fid (flow ID)

This is not enough to address the cases you mention in the context of
Jingle. So I believe we need to introduce another definition to group Media
Flows together.

Media group is defined as the association of two or more media flows. A
media group is identified by a gid (group ID)

The way Jingle is defined in JEP-166 implies that Media Streams i.e.
<description/> are defined by a single xmlns. This is in line with XMPP.
That makes it difficult "for a single description to define more than one
stream" (quote). But using the definition above we can have the following
construct to achieve the expected description.

<description gid='0' mid='0' fid='0'
   xmlns='http://jabber.org/protocol/jingle/media/audio'>
 ... description for audio media
</description>
<description gid='0' mid='1' fid='0'
   xmlns='http://jabber.org/protocol/jingle/media/video'>
 ... description for video media
</description>
<transport gid='0' fid='0'
   xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
</transport>

We would use the same gid for bind the two atomic description together. This
is in line with the current JEPs, where descriptions are bound to a single
media. In the above example, we have only one transport for the two media
streams. If we try to apply the same approach to your example, we may end up
with something like:


<description gid='0' fid='0'
   xmlns='http://jabber.org/protocol/jingle/media/audio'>
 ... description for audio media
</description>
<description gid='0' fid='1'
   xmlns='http://jabber.org/protocol/jingle/media/video'>
 ... description for video media
</description>
<description fid='2'
   xmlns='http://jabber.org/protocol/jingle/media/wb'>
 ... description for whiteboard media
</description>
<transport gid='0' fid='0'
   xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
   ... transport for audio stream
</transport>
<transport gid='0' fid='1'
   xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
   ... transport for video stream
</transport>
<transport fid='2'
   xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
   ... transport for whiteboard stream
</transport>

Does this approach address your concerns? Is it fair to say in this case the
channel is also a Media group?

Jean-Louis

-----Original Message-----
Message: 4
Date: Tue, 4 Apr 2006 14:06:52 -0700
From: "Joe Beda" <jbeda at google.com>
Subject: Re: (SPAM: 5.964) [Standards-JIG] RE: Jingle channel naming
	(was	Jingle schema extensibility)
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
Message-ID:
	<dbfdfee20604041406r3f982b33va81a504dffd86f44 at mail.google.com>
Content-Type: text/plain; charset="iso-8859-1"

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




More information about the Standards mailing list