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

Robert McQueen robert.mcqueen at collabora.co.uk
Thu May 29 19:38:49 UTC 2008

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 think I'm in favour of this, given the two XEPs seem to be copies of
each other. We could just have one RTP/AVP description XEP, with a media
type field. I discussed this earlier with Peter:

Robert McQueen: so, Olivier seems pretty sure that anything you want to
represent in the audio XEP will also need representation in the video
XEP, and that when implementing (using an RTP media stack) you'll just
end up mangling the data into the same format anyway
Robert McQueen: in fact, in our implementation, we do just have this
kinda thing:
Robert McQueen:  if (priv->media_type == MEDIA_TYPE_VIDEO)
Robert McQueen:     xmlns = NS_JINGLE_DESCRIPTION_VIDEO;
Robert McQueen: else
Robert McQueen:     xmlns = NS_JINGLE_DESCRIPTION_AUDIO;
Robert McQueen: so I can kinda see the point
Robert McQueen: the problem is with video is that you're tempted to add
all of these video-specific attributes like width, height, etc
Robert McQueen: but unless a certain codec already supports those
attributes in SDP a= negotiation, you're unlikely to be able to signal
anything useful there anyway, so there's not a great benefit to
promoting them into the namespace itself
Robert McQueen: the main thing that worries me is having caps discovery
Robert McQueen: but we can define #audio and #video really
Robert McQueen: certainly mangling one jingle offer into an SDP offer
will be easier this way
Peter Saint-Andre: yes, I keep copying and pasting from 167 to 180, and
we can define service discovery features quite easily
Peter Saint-Andre: are there potential problems with coordination
between audio and video, or is it easier to have everything in one RTP
Robert McQueen: ah, you'd still negotiate two RTP sessions
Robert McQueen: one for audio and one for video
Robert McQueen: so you still have two contents
Robert McQueen: you can't mix audio and video codecs within one offer
Peter Saint-Andre: aha
Peter Saint-Andre: so they'd simply be differentiated by the name and
Robert McQueen: yeah, so an SDP m-line has a media type as the first
Robert McQueen: http://tools.ietf.org/html/rfc4566#section-5.14
Peter Saint-Andre: nod
Peter Saint-Andre: I think this is one of my open issues
Robert McQueen: and I /really/ don't think you need a profile thing
Robert McQueen: we definitely imply RTP/AVP - and if we're not doing AVP
we're doing maybe SAVP, in which case we need to signal some keys
Robert McQueen: so we can cross that bridge when we come to it - maybe
throw a sub-namespace in with srtp key negotiation stuff in it
Robert McQueen: so I guess I'm in favour of rolling them into one
Robert McQueen: I might just paste what i said above into a mail
Robert McQueen: :P

> Thanks!
> Peter


More information about the Standards mailing list