Re: [MMUSIC] M-lines: Wikifying it

[Paul Kyzivat <[e-mail]>]

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.

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. 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.

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?

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'm not convinced we need to identify an "M" scope distinct from T and F.)

	Thanks,
	Paul