Re: [MMUSIC] M-lines: Wikifying it

[Paul Kyzivat <[e-mail]>]

inline

On 12/1/12 10:00 AM, Harald Alvestrand wrote:
> On 11/28/2012 09:13 PM, Paul Kyzivat wrote:
>> Inline
>>
>> On 11/28/12 9:50 AM, Harald Alvestrand wrote:
>>> Perhaps we can do some real work rather than just disagreeing on
>>> principles.
>>>
>>> Perhaps the most contentious issue now is "what should an M-line be".
>>> As far as I can tell, M-lines and their parameters describe 3 things:
>>>
>>> - Properties of the transport flow / RTP session (Transport, or T for
>>> short)
>>> - Properties that make sense to apply to an individual media stream, and
>>> may need to be different for different media streams in the same
>>> combined RTP session (Flow, or F for short)
>>> - Properties that make sense to apply to all streams of a given type
>>> (Media, or M for short)
>>>
>>> The properties that can be represented in M-lines are found in two IANA
>>> registries, both on
>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:
>>>
>>> - att-field (both session and media level)
>>> - att-field (media level only)
>>>
>>> I make it 179 entries in these categories, combined.
>>>
>>> I see the same kind of work being necessary no matter which way we go:
>>>
>>> - If we go with M-lines describing a whole RTP session (the MMT
>>> proposal), each property of the "F" class that we stil need needs to be
>>> copied onto a property in the "att-field (source level)" registry.
>>>
>>> - If we go with M-lines describing groups of media streams, degenerating
>>> to a single media stream in the case of using "a=inactive" for stream
>>> muting (the BUNDLE and TOGETHER proposals), each property of the "T"
>>> class needs to be described as "MUST have consistent values for all the
>>> combined M-lines", "MUST be taken only from the first M-line in the
>>> bundle argument", or "must get special treatment".
>>>
>>> - In both cases, the "M"-class lines don't need any special treatment.
>>> They just need to be present in all the M-lines where they're relevant.
>>>
>>> I've created a spreadsheet here:
>>>
>>> https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE
>>>
>>>
>>> with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for
>>> "necessary" and 0 for "will never matter").
>>>
>>> Anyone should be able to write it.
>>> If a few of us do a quick job of markup on it, I think we should be able
>>> to have a more realistic assessment in a few days.
>>>
>>> I've started, but much of this is unknown to me. Can others help?
>>
>> Don't forget the media formats listed in the m-line itself. The
>> meaning of these depends on the <proto> param. The focus of this
>> discussion is on those <proto> values that correspond to various
>> flavors of RTP. There are a bunch of <proto> values that don't
>> correspond to RTP, and that assign different meanings to the format
>> parameters.
> I'm happy to ignore anything but RTP. BUNDLE isn't defined for anything
> else (while, in the parallel discussion, we may get DTLS/SCTP within its
> scope too, the RTP parameter set is our current problem).

Hmm. OK, I went looking for something that says that. Section 7.1 does 
say that, though I can find no text that talks about which m-line 
<proto> values may be bundled together.

>> AFAIK, of the currently defined proto values only the RTP-related ones
>> have the notion of multiple flows within the session. But the sdp
>> extensions for SCTP media are currently being defined. That certainly
>> has the potential to be considered as multiple flows, and should be
>> considered in this discussion.
>>
>> For RTP transports, the formats are payload type numbers, and these
>> are mapped to actual formats (codecs) via a=rtpmap. I see that you
>> have proposed that rtpmap be per-media, not transport or flow. I guess
>> this means that the same payload type number could mean one thing for
>> all audio flows over the transport, and something different for all
>> video flows over the same transport.
> Absolutely not; that would violate both common sense and the BUNDLE
> draft as specified. The BUNDLE drafts explicitly say that a payload type
> number can only be used for one thing.
>> But the payload numbers to be used (specified on the m-line) is
>> negotiated in O/A. How would that work for audio vs. video? ISTM it
>> would be preferred to negotiate payload numbers and types
>> independently per flow.
> See above. They can't collide.
>>
>> Regarding the "importance" column in the table: I don't understand how
>> you have assigned values. In what frame of reference is importance to
>> be assessed?
> My completely subjective opinion, for RTCWEB. If others disagree, please
> change and add a comment. If we all agree, it becomes consensus.

Frankly I don't even know what most of the parameters in the list are.
But I assume that most of them were at one time important to somebody - 
at least those who defined it. Perhaps some are now obsolete, but most 
likely not all of them.

It isn't helpful if we all agree on what is important and what is not if 
we don't agree on the criterion for importance.

A couple of meanings that could be useful here:

- those that might be used in an rtcweb context vs. those that nobody
   thinks make any sense to use with rtcweb

- those that make sense to use in a bundle/mmt vs. those that may only
   be used outside a bundle/mmt.

I guess I would prefer the latter. It has the benefit that those nobody 
understands can be put in the unimportant category, and they won't be 
broken by bundle/mmt.

>> Regarding a=label: This could be any of T/F/M, depending on
>> application use. I think we must assume T, and consider an alternative
>> for F. (And for M if we think it is needed.)

I may have misunderstood your intended meaning for M. I assume you meant 
all RTP streams of the same media type (audio or video) within a single 
5-tuple.

> The claim that a=label can be used to mark flows makes it F.

a=label is a media-level attribute, so it is bound to an m-line.

In the absence of bundle, regardless of whether the corresponding RTP 
session has one or several flows. The m-line has a particular media 
type, so I guess it could be viewed as either T or M.

Some applications of a=label may assume or require that the labeled 
m-line contain only one RTP stream. If so, then perhaps the label could 
be considered to be F. But we can't really know that.

> If the
> people making that claim are willing to let go of the claim, we can
> change it to T. But at the moment its proponents are clearly calling for F.

Is your point that you know of cases where there is a desire to label an 
individual RTP-stream, and you would like to have a way to do that when 
RTP-streams are multiplexed in an RTP session?

I'm ok with that.

>> (I'm not convinced we need to identify an "M" scope distinct from T
>> and F.)
> Please consider the ones marked as such and tell me the argument for why
> it's obviously one or the other.
>
> In particular, a=rtpmap:<number> is clearly not T, but when we have
> multiple flows on an RTP session utilizing the same codec, I'd hate to
> be forced to create multiple identical payload types just because it was
> classified as an F field.

a=rtpmap is the *only* one currently marked M. And ISTM that it clearly 
is a T.

I say this because, as you have said elsewhere, each payload type number 
is tied to a particular codec of a particular codec, whether audio or 
video. It isn't possible to have payload type number 100 mean one thing 
for audio and a different thing for video.

OTOH, when multiplexing audio and video on the same 5-tuple it is 
necessary to know whether a particular a=rtpmap is intended to be audio 
or video. Normally it inherits that from the m-line it belongs to. That 
still works for bundle. It doesn't work for mmt.

So, I still think there is no need for M. But a=rtpmap is "special" in 
that it requires an extra datum. Unless there are other attributes that 
have the same issue I think this is just a special case.

	Thanks,
	Paul