Re: [MMUSIC] M-lines: Wikifying it

Jonathan Lennox <> Wed, 28 November 2012 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C9CE21F84BC for <>; Wed, 28 Nov 2012 08:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IRTM46dsf3r9 for <>; Wed, 28 Nov 2012 08:29:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2274921F849A for <>; Wed, 28 Nov 2012 08:29:55 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id ACF88798279; Wed, 28 Nov 2012 11:04:38 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB022.mail.lan (unknown []) by (Postfix) with ESMTP id EAF6B798176; Wed, 28 Nov 2012 11:04:34 -0500 (EST)
Received: from BE235.mail.lan ([]) by HUB022.mail.lan ([]) with mapi; Wed, 28 Nov 2012 11:29:32 -0500
From: Jonathan Lennox <>
To: Harald Alvestrand <>, mmusic <>
Date: Wed, 28 Nov 2012 11:29:47 -0500
Thread-Topic: [MMUSIC] M-lines: Wikifying it
Thread-Index: Ac3Ng8P3GkOWi5lkRxWEzeqsnUq8/AAAA5Jg
Message-ID: <C3759687E4991243A1A0BD44EAC823034DFAC1FAA9@BE235.mail.lan>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C3759687E4991243A1A0BD44EAC823034DFAC1FAA9BE235maillan_"
MIME-Version: 1.0
Subject: Re: [MMUSIC] M-lines: Wikifying it
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Nov 2012 16:29:57 -0000

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 []
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

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

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?