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

Joe Beda jbeda at google.com
Wed Apr 5 16:53:29 UTC 2006


I don't necessarily agree with your definitions.  I think we need to answer
some questions before we go too deep.  Some questions/discussion inline
below.

I'll follow this mail up with a more concrete example for my option #3,
which, after talking with Scott, we are think is a promising way to go.

Joe

On 4/5/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
>
> 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)


This implies that each description element is bound to one and only one
"media stream" (what we've been calling a channel).  I don't think that this
is necessarily what we want.  It should be possible for one description to
define multiple streams/channels.  I also think that we don't want to bind
ourselves to tightly to RDP.  I would argue that a stream consists of a way
to unreliably get small packets of information between endpoints (similar to
UDP, but could be carried over TCP).  I do agree that we need a way to name
and refer to these streams.

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)


There are two issues we need to clear up in this paragraph.
1) Up until now, we've specified that there is one and only one transport
negotiated per session.  This transport is responsible for implementing all
of the streams/channels specified in various <description/> elements.
2) I'm not convinced that we need to define anything like a flow in the
Jingle spec proper.  If we want to support more than one physical
stream/channel being merged to support a single virtual stream/channel we
should probalby do so in the transport.  The idea of a flow (binding
multiple phsyical means of transmitting packets into one combined stream)
should be completely defined by the transport.  If there is a compelling
scenario for this now we should look at adding it to an an existing
transport or perhaps creating a new transport.  I'm inclined to wait and get
to it later.

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?


I don't think I understand why we would need a media group here.  From what
you've said here, I would say that a media stream and a channel are
essentially the same thing.  I've hesitated to use the term "media stream"
before as we are not bound to RTP and can care more than just media.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060405/7391ef39/attachment.html>


More information about the Standards mailing list