[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