Re: [MMUSIC] M-lines: Wikifying it

Harald Alvestrand <harald@alvestrand.no> Mon, 03 December 2012 11:14 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8C621F8596 for <mmusic@ietfa.amsl.com>; Mon, 3 Dec 2012 03:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.148
X-Spam-Level:
X-Spam-Status: No, score=-110.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAo0H-X0BA0n for <mmusic@ietfa.amsl.com>; Mon, 3 Dec 2012 03:14:44 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4395A21F86BE for <mmusic@ietf.org>; Mon, 3 Dec 2012 03:14:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26BDC39E1FC; Mon, 3 Dec 2012 12:14:42 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p13O93Gf4rSA; Mon, 3 Dec 2012 12:14:40 +0100 (CET)
Received: from [158.38.97.117] (unknown [158.38.97.117]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 170A539E04C; Mon, 3 Dec 2012 12:14:40 +0100 (CET)
Message-ID: <50BC89A0.1030104@alvestrand.no>
Date: Mon, 03 Dec 2012 12:14:40 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------030806030205050208080509"
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] M-lines: Wikifying it
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2012 11:14:47 -0000

On 12/03/2012 12:05 PM, Christer Holmberg wrote:
>
> Hi,
>
> So, the exercise is NOT about how to apply attributes to individual 
> sources?
>

Only in the sense that it is about figuring out which attributes need to 
be applied to individual sources.

> Regards,
>
> Christer
>
> *From:*Harald Alvestrand [mailto:harald@alvestrand.no]
> *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:*mmusic-bounces@ietf.org <mailto:mmusic-bounces@ietf.org> 
> [mailto:mmusic-bounces@ietf.org] *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
>
>
>
>
>