[MMUSIC] What is an m-line?

[Martin Thomson <[e-mail]>]

We've had a great deal of discussion about plan A and B and the
various interactions of these proposals with bundling.  But I still
don't get a good sense that there is a working consensus on what an
m-line actually represents.

I think that we've each reached our own conclusions, but they
definitely are not consistent.  We need a well-understood semantic for
m-lines if we have any chance of resolving these issues; Plan A/B
being only the first RTCWEB problem to address.

RFC 4566 is helpfully devoid of detail, so we are free to come up with
any interpretation we choose.  Here are the ones that I have seen:

 1. an m-line represents a single RTP session
    (or at least the part of the session that touches the client)
    This appears to be consistent with the Plan B approach

 2. an m-line represents the set of RTP streams that decode into a
single rendering, including layers, simulcast and FEC

 3. an m-line represents a single RTP stream; multiple m-lines might
be required to obtain a single rendering if it uses layers, simulcast,
FEC or FID groupings
    This appears to be consistent with the Plan A approach

In the first instance, an m-line can be multiple "things".  In the
latter two cases, an m-line is consistently one "thing" (or part
thereof).

The first interpretation has a natural advantage in terms of signaling
economy and natural bundling.  The latter interpretations seem to have
advantages in dealing with call transfer and SSRC renumbering.

So, which is correct?