Re: [MMUSIC] M-lines: Wikifying it

[Jonathan Lennox <[e-mail]>]

Hi, Harald -

I think this is a good starting point, though I think things are somewhat more complicated than you've described.

First of all, for the SHIM approaches, you need to separate Transport parameters (e.g. ICE candidates) from Session parameters (e.g., SRTP keying).  This isn't relevant for Bundle/MMT, but as long as we're doing the work it might as well be done completely.

More significantly, I think, a number of parameters actually fall into multiple categories depending on how they're used.  For example, rtcp-fb is Transport (or, if you believe my previous argument, Session) when the rtcp-fb-pt field is "*", but it's Media when a specific payload type is given.

From: Harald Alvestrand [mailto:[e-mail]]
Sent: Wednesday, November 28, 2012 9:51 AM
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it

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?

                      Harald