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

[Harald Alvestrand <[e-mail]>]

On 07/25/11 08:17, 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.
RFC 4566 section 5:

    An SDP session description consists of a session-level section
    followed by zero or more media-level sections.  The session-level
    part starts with a "v=" line and continues to the first media-level
    section.  Each media-level section starts with an "m=" line and
    continues to the next media-level section or end of the whole session
    description.

....

5.14.  Media Descriptions ("m=")

       m=<media> <port> <proto> <fmt> ...

    A session description may contain a number of media descriptions.
    Each media description starts with an "m=" field and is terminated by
    either the next "m=" field or by the end of the session description.
    A media field has several sub-fields:

<media> is the media type.  Currently defined media are "audio",
       "video", "text", "application", and "message", although this list
       may be extended in the future (see Section 8).

<port> is the transport port to which the media stream is sent.

In other words: an "m" line is tied to a port number, and (from RTP) the 
port number identifies the RTP session. The ICE parameters can override 
the port number, but they're carried within the "m" block, so they're 
tied to a single "m" line too.

I do not know what would happen if you used the same port number and ICE 
parameters with two "m" lines.