Re: [MMUSIC] What is an m-line?

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 13 May 2013 19:14 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 9E2F121F9476 for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 12:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.341
X-Spam-Level:
X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiWD9AS4mWZT for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 12:14:50 -0700 (PDT)
Received: from blu0-omc4-s23.blu0.hotmail.com (blu0-omc4-s23.blu0.hotmail.com [65.55.111.162]) by ietfa.amsl.com (Postfix) with ESMTP id ABAFF21F8721 for <mmusic@ietf.org>; Mon, 13 May 2013 12:14:50 -0700 (PDT)
Received: from BLU169-W78 ([65.55.111.136]) by blu0-omc4-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 12:14:49 -0700
X-EIP: [21bLp088o56j2EVuYL4NZrOGjCr1ZmT5zlv/KlIG674=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W783DE3B448E226C811D1F393A00@phx.gbl>
Content-Type: multipart/alternative; boundary="_e2658fd3-23b8-4fc4-af63-96a87429405f_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Mon, 13 May 2013 12:14:48 -0700
Importance: Normal
In-Reply-To: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com>
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 13 May 2013 19:14:49.0249 (UTC) FILETIME=[234F5910:01CE500E]
Subject: Re: [MMUSIC] What is an m-line?
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, 13 May 2013 19:14:56 -0000

Martin said; 

>  1. an m-line represents a single RTP session
>     (or at least the part of the session that touches the client)
>     This appears to be consistent with the Plan B approach
> 
>  2. an m-line represents the set of RTP streams that decode into a
> single rendering, including layers, simulcast and FEC
> 
>  3. an m-line represents a single RTP stream; multiple m-lines might
> be required to obtain a single rendering if it uses layers, simulcast,
> FEC or FID groupings. This appears to be consistent with the Plan A approach
> 
> In the first instance, an m-line can be multiple "things".  In the
> latter two cases, an m-line is consistently one "thing" (or part
> thereof).
> 
> The first interpretation has a natural advantage in terms of signaling
> economy and natural bundling.  The latter interpretations seem to have
> advantages in dealing with call transfer and SSRC renumbering.
> 
> So, which is correct?

[BA] With respect to video, I believe that #1 is closer to what we see in existing implementations of simulcast and layered coding.  For that scenario, approach #3 could generate too many m lines.   Approach #1 is also consistent with the multicast scenarios envisaged in the early days of SDP, where multiple SSRCs could send to the same multicast address and port.    Where the mixer only puts out a single SSRC (e.g. audio or composited video), approach #2 is a degenerate case of #3.