Re: [MMUSIC] What is an m-line?

[Paul Kyzivat <[e-mail]>]

On 5/15/13 2:47 PM, Bernard Aboba wrote:
> Colin said:
>
> "People often want to look at this from the point of view of what they
> wish they can change SDP to mean, but unless we are doing SDPng, we need
> to look at it from the practical point of view of what has deployed and
> what SDP was defined as when that equipment deployed. We need to find a
> way that provided backwards interoperability while still allowing us to
> negotiate the things we want now. You can easily define an extension to
> SDP that means that RTP received on a single m line was meant to be
> rendered in different windows, but the fact of the matter remains that
> is not how lots of SIP equipment worked so you can't pretend SDP always
> meant that because it did not."
>
> [BA]  The reality is that "SIP equipment" covers an awful lot of ground.
>   There are implementations that use a single m line for video and can
> handle and render multiple SSRCs within that RTP session in different
> windows.   Emil has referred to one of those (Jitsi videobridge).  There
> are also implementations that use a single m line and support
> simulcast/layered coding, rendering SSRC groups (e.g. groupings of
> simulcast and layered sources) in different windows.   Several
> implementations of H.264/SVC work this way.
>
> So when people on the say "SIP equipment works this way" or "SDP works
> this way" or even "RTP works this way" my BS meter goes off.  Usually
> they mean "the equipment I'm familiar with works this way".
>
> I'm not sure we can make a definitive statement about what "backwards
> interoperability" means with respect to video systems today, at least
> without some work to survey existing implementations.  And this somewhat
> complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, because the
> reality is that *neither* of these plans can achieve widespread
> "backwards interoperability" with respect to SDP, if what you mean by
> that is "I can take the SDP produced by a WebRTC implementation, throw
> it over the wire to an existing implementation and expect anything good
> to happen".

Perhaps the best we can do is acknowledge that the "legacy" use of RTP 
was underspecified, and so up to the application to sort out.

To move forward, maybe we can more carefully define what we want the 
m-line to mean going forward, and add some additional syntax (e.g. an 
attribute) that says this refined definition is being used. In an O/A 
context that would need to be confirmed in the answer.

That is for an unbundled m-line. A bundled m-line clearly has a 
different definition - presumably a subset of what an unbundled one is.

	Thanks,
	Paul