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

Zack Sargent ZSargent at voxitas.com
Fri May 30 17:32:12 UTC 2008

From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Paul Witty
Sent: Friday, May 30, 2008 9:57 AM
To: XMPP Extension Discussion List
Subject: Re: [Standards] Jingle: one RTP application type to bind them all?

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.

I'll have a read through all the updated specs over the weekend, and try
to comment on them on Monday.




To throw another comment into this idea, providing separate channels for audio and video such that a network can provide separate QoS for each channel is also desirable.  I.e., less communication is lost if a frame of video is dropped than if a few words are dropped from the audio.  Therefore, separate streams across the network for each part are desirable as part of the same session initiation (though no present VOIP/Video implementations support this, yet).

More information about the Standards mailing list