Subject: [MMUSIC] M-lines: Wikifying it

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Nov 2012 15:50:52 +0100

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

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 28 Nov 2012 11:29:47 -0500

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:[email-masked]]
Sent: Wednesday, November 28, 2012 9:51 AM
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it

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

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

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.

                      Harald

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2012 15:13:03 -0500

Inline

> 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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Nov 2012 21:24:54 +0100

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:[email-masked]]
> *Sent:* Wednesday, November 28, 2012 9:51 AM
> *To:* mmusic
> *Subject:* [MMUSIC] M-lines: Wikifying it
>
> - Properties that make sense to apply to an individual media stream, 
> and may need to be different for different media streams in the same 
> 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".
>
> 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.
>