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 [email protected] 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 "session"? 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 content-type Robert McQueen: yeah, so an SDP m-line has a media type as the first argument 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 Regards, Rob
