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

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Tue Apr 4 20:20:59 UTC 2006

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' ...
    <description xmlns='http://jabber.org/protocol/jingle/media/audio'>
    ... description for audio media
    <description xmlns='http://jabber.org/protocol/jingle/media/video'>
    ... description for video media
    <transport ...>

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' ...
    <description xmlns='http://jabber.org/protocol/jingle/media/audio'
    ... description for audio media
    <description xmlns='http://jabber.org/protocol/jingle/media/video'
    ... description for video media
    <transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'
    <transport xmlns='http://jabber.org/protocol/jingle/transport/rtp-ice'
    <transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'

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?


-----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
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
	<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?


More information about the Standards mailing list