Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt)

[Randell Jesup <[e-mail]>]

On 7/25/2011 8:17 AM, Emil Ivov wrote:
> На 25.07.11 14:06, Harald Alvestrand написа:
>> On 07/24/11 16:44, Matthew Kaufman wrote:
>>> In all my reading today I have not been able to find anything more concrete than the "SHOULD NOT" in section 5.2 of RFC3550. PLEASE follow up if you are aware of any other relevant specifications that would argue against using SSRC to multiplex audio and video streams over a single RTP session between a pair of compatible endpoints that agree to do so.
>> I have found *one* reason not mentioned in the draft:
>>
>> An RTP session with both "audio" and "video" media types cannot be
>> represented by an SDP description, since SDP ties RTP sessions 1-1 to
>> the "m" line of the description, which contains the top-level type, and
>> the codec descriptions omit the top-level type in their codec naming.
> I am not sure I understand this. Why would one need to use the same "m"
> line? What would be the consequences of using two different "m" lines?
>
> Personally, I am still not convinced that multiplexing brings
> significant improvement over the status quo but if we accept it then it
> definitely needs to keep separate "m" lines for tons of reasons.

I've been assuming the method of indicating multiplexing would be two m= 
lines with
the same c= destination and the same port specified.  This is a 
mechanism that has
been discussed before on the AVT list and/or in drafts (and I'm sure has 
also been
done before).  It does require avoiding using the same payload values in 
the two m= lines,
but beyond that it's fairly straightforward.  It also allows for the 
answerer to clearly reject a
media type explicitly, instead of an implicit rejection by removing the 
payloads of a type.

-- 
Randell Jesup
[e-mail]