Re: [MMUSIC] M-lines: Wikifying it

[Harald Alvestrand <[e-mail]>]

On 11/28/2012 05:29 PM, Jonathan Lennox wrote:
>
> 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.
>
Yes, if we do SHIM, they're different. Good point! Will you update the 
header for that?
(I tend to forget SHIM)
>
> 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.
>
That means we'll have to make 2 lines for it. I suspect it's not the 
only one.

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