[Standards] Jingle: one RTP application type to bind them all?

Olivier Crête olivier.crete at collabora.co.uk
Fri May 30 19:29:15 UTC 2008

On Fri, 2008-05-30 at 15:57 +0100, Paul Witty wrote:
> Peter Saint-Andre wrote:
> > Back in April, Olivier Crête questioned whether we really need separate
> > application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
> >
> > http://mail.jabber.org/pipermail/standards/2008-April/018554.html
> >
> > Olivier suggested that we could simply negotiate one RTP "channel" and
> > use it for anything that RTP can do -- voice, video, real-time text (RFC
> > 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
> > would like to make sure that we have consensus on keeping things as-is
> > before moving forward with the Jingle specs. If you have feedback on
> > this issue, please weigh in on the standards at xmpp.org list.
> >   
> I'm in favour of simplifying things down so that there's as much in 
> common between audio/video channels as possible.  Though the use of the 
> word "one" in the above paragraph seems to suggest a single RTP channel, 
> implying all media being received on a single UDP port.  This would be a 
> bad idea at least where doing Jingle <-> SIP gateways is concerned, as 
> SIP uses separate UDP streams for each content type, so the gateway 
> would have to inspect each packet incoming on the Jingle side to 
> determine the payload type to send it out on the correct port.

What I suggested is to have one "type" of channel (ie one namespace).
Not to mix audio and video on the same port, that would be crazy (and I
hope I'm not). My goal is only to make jingle as close to SIP as
possible so as to make interoperability and future extensions easy.

Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080530/28ee27c4/attachment.sig>

More information about the Standards mailing list