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.
<br><br>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.)
<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.  In this case, the entity putting together the descriptions would guarantee that names didn't overlap.  
<br>2) Use the namespace of the descrition to help define the names.  Then there would be something like <candidate name='rtp' description='<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><div><span class="gmail_quote">On 4/4/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;">
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 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><br>-----Original Message-----<br>Message: 3<br>Date: Mon, 3 Apr 2006 13:07:16 -0700<br>From: "Joe Beda" <<a href="mailto:jbeda@google.com">jbeda@google.com</a>><br>Subject: Re: (SPAM: 
5.957) RE: [Standards-JIG] Jingle schema<br>        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:dbfdfee20604031307v3eca6dedj1a19f702d27072cd@mail.google.com">dbfdfee20604031307v3eca6dedj1a19f702d27072cd@mail.google.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>I see.  What you are saying is that there is no explicit declaration of what
<br>channels a session requires a transport to provide?<br><br>I was assuming that this would be documened as part of the session JEP.<br>Some sessions would define one statically named channel (the poorly named<br>'rtp' channel for audio right now) while others may be more dynamic.  Is
<br>there some scenario where you think they need to be called out explicitly?<br>All else being equal, I'd rather the protocol be less chatty if possible.<br><br>As long as we are talking about channel naming, we are facing at least one
<br>problem right now with respect to the naming of channels:  Now that we can<br>have multiple sessions in play at once (not in the spec yet but we decided<br>that, right?) we need to name a channel in a way that binds it to a session.
<br><br>I would suggest that we use URIs for channel names but I'd be afraid it<br>would get too verbose.  Any other ideas?<br><br>Joe<br><br></blockquote></div><br>