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.<br><br>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.
<br><br>Joe<br><br><div><span class="gmail_quote">On 4/5/06, <b class="gmail_sendername">Jean-Louis Seguineau</b> <<a href="mailto:jean-louis.seguineau@laposte.net">jean-louis.seguineau@laposte.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Let's try to dig into this further. But first, I believe we should agree on<br>wording definition. I believe RFC3388 
<a href="http://www.ietf.org/rfc/rfc3388.txt">http://www.ietf.org/rfc/rfc3388.txt</a><br>addresses some of these naming definitions.<br><br>Media stream is defined as a single media instance, e.g., an audio stream or<br>a video stream as well as a single whiteboard or shared application group.
<br>This is mapped to the Jingle <description/> element. A media stream is<br>identified by a mid (media ID)</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Media flow is defined as the association of a single media instance, e.g.,<br>
an audio stream or a video stream as well as a single whiteboard or shared<br>application group.  When using RTP, a media flow comprises one or more RTP<br>sessions. This can be mapped to a tuple comprised of a Jingle <description/>
<br>element and one or more <transport/> elements. A media flow is identified by<br>a fid (flow ID)</blockquote><div><br>There are two issues we need to clear up in this paragraph.  <br>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.
<br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is not enough to address the cases you mention in the context of<br>Jingle. So I believe we need to introduce another definition to group Media
<br>Flows together.<br><br>Media group is defined as the association of two or more media flows. A<br>media group is identified by a gid (group ID) <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The way Jingle is defined in JEP-166 implies that Media Streams i.e.<br><description/> are defined by a single xmlns. This is in line with XMPP.<br>That makes it difficult "for a single description to define more than one
<br>stream" (quote). But using the definition above we can have the following<br>construct to achieve the expected description.<br><br><description gid='0' mid='0' fid='0'<br>   xmlns='<a href="http://jabber.org/protocol/jingle/media/audio'">
http://jabber.org/protocol/jingle/media/audio'</a>><br> ... description for audio media<br></description><br><description gid='0' mid='1' fid='0'<br>   xmlns='<a href="http://jabber.org/protocol/jingle/media/video'">
http://jabber.org/protocol/jingle/media/video'</a>><br> ... description for video media<br></description><br><transport gid='0' fid='0'<br>   xmlns='<a href="http://jabber.org/protocol/jingle/transport/raw-udp'">
http://jabber.org/protocol/jingle/transport/raw-udp'</a>><br></transport><br><br>We would use the same gid for bind the two atomic description together. This<br>is in line with the current JEPs, where descriptions are bound to a single
<br>media. In the above example, we have only one transport for the two media<br>streams. If we try to apply the same approach to your example, we may end up<br>with something like:<br><br><br><description gid='0' fid='0'
<br>   xmlns='<a href="http://jabber.org/protocol/jingle/media/audio'">http://jabber.org/protocol/jingle/media/audio'</a>><br> ... description for audio media<br></description><br><description gid='0' fid='1'<br>
   xmlns='<a href="http://jabber.org/protocol/jingle/media/video'">http://jabber.org/protocol/jingle/media/video'</a>><br> ... description for video media<br></description><br><description fid='2'<br>   xmlns='
<a href="http://jabber.org/protocol/jingle/media/wb'">http://jabber.org/protocol/jingle/media/wb'</a>><br> ... description for whiteboard media<br></description><br><transport gid='0' fid='0'<br>   xmlns='<a href="http://jabber.org/protocol/jingle/transport/raw-udp'">
http://jabber.org/protocol/jingle/transport/raw-udp'</a>><br>   ... transport for audio stream<br></transport><br><transport gid='0' fid='1'<br>   xmlns='<a href="http://jabber.org/protocol/jingle/transport/raw-udp'">
http://jabber.org/protocol/jingle/transport/raw-udp'</a>><br>   ... transport for video stream<br></transport><br><transport fid='2'<br>   xmlns='<a href="http://jabber.org/protocol/jingle/transport/raw-udp'">
http://jabber.org/protocol/jingle/transport/raw-udp'</a>><br>   ... transport for whiteboard stream<br></transport><br><br>Does this approach address your concerns? Is it fair to say in this case the<br>channel is also a Media group?
</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Jean-Louis<br><br>-----Original Message-----<br>Message: 4<br>Date: Tue, 4 Apr 2006 14:06:52 -0700
<br>From: "Joe Beda" <<a href="mailto:jbeda@google.com">jbeda@google.com</a>><br>Subject: Re: (SPAM: 5.964) [Standards-JIG] RE: Jingle channel naming<br>        (was    Jingle schema extensibility)<br>To: "Jabber protocol discussion list" <
<a href="mailto:standards-jig@jabber.org">standards-jig@jabber.org</a>><br>Message-ID:<br>        <<a href="mailto:dbfdfee20604041406r3f982b33va81a504dffd86f44@mail.google.com">dbfdfee20604041406r3f982b33va81a504dffd86f44@mail.google.com
</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>This is very close to what I was thinking.  The one difference is that it<br>should be possible for a single description to define more than one stream.
<br>For example, a "audio+video" session might have "rtp-audio" and "rtp-video"<br>streams.  On top of that, there might be another description that does<br>whiteboarding that defines a "wb" stream.
<br><br>In that case, a channel is defined by a description and provided by a<br>transport.  We need a way to name these in the transports so that they don't<br>conflict if there are multiple descriptions on the same channel.  (So that
<br>you could have description 1 that defines a 'data' channel and description 2<br>that also defines a 'data' channel.)<br><br>Here are the solutions I can think of for this problem:<br>1) Require that all descriptions allow for channels to be named dynamicly.
<br>In this case, the entity putting together the descriptions would guarantee<br>that names didn't overlap.<br>2) Use the namespace of the descrition to help define the names.  Then there<br>would be something like <candidate name='rtp' description='
<br><a href="http://jabber.org/protocol/jingle/media/audio">http://jabber.org/protocol/jingle/media/audio</a>' ... /><br>3) Put ids on the descriptions and use those to help identify the channels:<br><description xmlns='...' did='mydescription' />
<br><transport><br>  <candidate name='rtp' did='mydescription' ... /><br></transport><br><br>I'm in favor of 1 or 3.  I think that 2 is too verbose.  Other ideas here?<br><br>Joe<br><br>On 4/4/06, Jean-Louis Seguineau <
<a href="mailto:jean-louis.seguineau@laposte.net">jean-louis.seguineau@laposte.net</a>> wrote:<br>><br>> I was under the impression that we were going toward a construct like this<br>> for multiple media streams:
<br>><br>> <jingle xmlns='<a href="http://jabber.org/protocol/jingle">http://jabber.org/protocol/jingle</a>' ...<br>>           sid='a73sjjvkla37jfea'><br>>     <description xmlns='<a href="http://jabber.org/protocol/jingle/media/audio'">
http://jabber.org/protocol/jingle/media/audio'</a>><br>>     ... description for audio media<br>>     </description><br>>     <description xmlns='<a href="http://jabber.org/protocol/jingle/media/video'">
http://jabber.org/protocol/jingle/media/video'</a>><br>>     ... description for video media<br>>     </description><br>>     <transport ...><br>>     </transport><br>> </jingle><br>
><br>> The communication session is encapsulated by the <jingle/> element and<br>> identified by its 'sid'. Every media stream is described in a separate<br>> distinct <description/> element, each in its own namespace.
<br>> Now on the transport front I suppose we have to make an offer with several<br>> of them. And in that case you are right in saying we must have some way of<br>> binding a particular transport to a particular media stream. The principle
<br>> could be something like:<br>><br>> <jingle xmlns='<a href="http://jabber.org/protocol/jingle">http://jabber.org/protocol/jingle</a>' ...<br>>           sid='a73sjjvkla37jfea'><br>>     <description xmlns='
<a href="http://jabber.org/protocol/jingle/media/audio">http://jabber.org/protocol/jingle/media/audio</a>'<br>>     id='audio'><br>>     ... description for audio media<br>>     </description><br>>     <description xmlns='
<a href="http://jabber.org/protocol/jingle/media/video">http://jabber.org/protocol/jingle/media/video</a>'<br>>     id='video'><br>>     ... description for video media<br>>     </description><br>>     <transport xmlns='
<a href="http://jabber.org/protocol/jingle/transport/raw-udp">http://jabber.org/protocol/jingle/transport/raw-udp</a>'<br>>     id-ref='audio'><br>>     </transport><br>>     <transport xmlns='<a href="http://jabber.org/protocol/jingle/transport/rtp-ice">
http://jabber.org/protocol/jingle/transport/rtp-ice</a>'<br>>     id-ref='audio'><br>>     </transport><br>>     <transport xmlns='<a href="http://jabber.org/protocol/jingle/transport/raw-udp">http://jabber.org/protocol/jingle/transport/raw-udp
</a>'<br>>     id-ref='video'><br>>     </transport><br>> </jingle><br>><br>> Do not put any special meaning behind the attributes added to description<br>> and transport. Their only purpose is to indicate that a particular
<br>> transport<br>> is linked to a particular media stream description.<br>><br>> Is this what you are referring to? And where would the notion of 'channel'<br>> appear then?<br>><br>> Jean-Louis<br>
<br></blockquote></div><br>