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

Jonathan Lennox <jonathan@vidyo.com> Mon, 13 May 2013 19:38 UTC

Return-Path: <jonathan@vidyo.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 129F421F9408 for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 12:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ux-I4y9MTIlF for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 12:38:53 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id EC33621F93FC for <mmusic@ietf.org>; Mon, 13 May 2013 12:38:52 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6C9A45530C0; Mon, 13 May 2013 15:38:52 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E42BB552FD5; Mon, 13 May 2013 15:38:51 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 13 May 2013 15:37:30 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Mon, 13 May 2013 15:38:51 -0400
Thread-Topic: [MMUSIC] What is an m-line?
Thread-Index: Ac5QEW67zgVkCn0cTTKTQGWs0xdEYA==
Message-ID: <79FFE18A-D38C-4CEE-9113-EE2FC1E8D0FE@vidyo.com>
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com> <519138CB.5020202@alum.mit.edu>
In-Reply-To: <519138CB.5020202@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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:38:58 -0000

On May 13, 2013, at 3:02 PM, Paul Kyzivat wrote:

>> RFC 4566 is helpfully devoid of detail, so we are free to come up with
>> any interpretation we choose.  Here are the ones that I have seen:
>> 
>>  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
> 
> Well, it was my impression that Plan B still intends to allow bundling 
> in order to combine audio and video into a single RTP session. So in 
> that case neither of the m-lines represents a single RTP session in full.

Yes, the idea behind MMT was to preserve this interpretation of an m-line, even as we added a/v mux, rather than forcing descriptions of RTP sessions to be spread across multiple parts of the SDP.

The WG prefers BUNDLE to MMT, though, so I guess we're going to have to cope with description spreading, regardless of which of the current plans on that're on the table are accepted.

--
Jonathan Lennox
jonathan@vidyo.com