Re: [MMUSIC] M-lines: Wikifying it

[Christer Holmberg <[e-mail]>]

Hi,

So, the exercise is NOT about how to apply attributes to individual sources?

Regards,

Christer

From: Harald Alvestrand [mailto:[e-mail]]
Sent: 3. joulukuuta 2012 12:54
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] M-lines: Wikifying it

On 12/03/2012 11:23 AM, Christer Holmberg wrote:
Hi,

A question for clarification:

When talking about the "F" class, what do you mean by "stream"? Do you mean individual sources associated with the m- line? Or, do you mean all sources associated with the m- line?

I ASSUME you mean all sources associated with the m- line, because otherwise you will need the a=ssrc attribute.

The purpose of the exercise is to figure out what attributes we need to redefine if we define the M-line to be an RTP session (the MMT and the all-videos-under-one-M-line approach) as opposed to what attributes we need to redefine if we define the M-line to be a group of sources that, in turn, may be associated with an RTP session (the BUNDLE approach).

F-lines need redefinition under the first approach, T-lines need redefinition (or adjustment) under the second, M-lines may be able to work in both cases.



Regards,

Christer

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Harald Alvestrand
Sent: 28. marraskuuta 2012 16:51
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