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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 13 May 2013 19:02 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 21CFD21F9488 for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 12:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.746
X-Spam-Level:
X-Spam-Status: No, score=0.746 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MANGLED_FORM=2.3, RDNS_NONE=0.1]
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 LqQs5JNVJZKb for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 12:02:37 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE221F947C for <mmusic@ietf.org>; Mon, 13 May 2013 12:02:36 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id bUVQ1l0050QuhwU56X2coL; Mon, 13 May 2013 19:02:36 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id bX2c1l00F3ZTu2S3NX2c4N; Mon, 13 May 2013 19:02:36 +0000
Message-ID: <519138CB.5020202@alum.mit.edu>
Date: Mon, 13 May 2013 15:02:35 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com>
In-Reply-To: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368471756; bh=6wtk+HKgWX+J97YCyqnUQJ4CDkkrWnz2t8tc1cpGS1w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NzaY7q7gblKP6+1bMK91tClOQ7as50VUrISSSQiyfWkwdg1VRDGs5HGX6pA+Ka5Jj SBEzgGYj+wdn96f9SRI8+PcaohHnfJ7C5RN2y31xaJTj5IqbLh73+91K7KzXAou1MB Gazd2X1OcsA0xAK5fpybtIsk/MDX5N55LMQAt7+Mw/NIcWuvLbiw/ICehbn5SFc8aT wvZJZ2X3II6gTVMWwxtg3XYQGpw7CVSKQvpJQoed4qYn0/ExyjQapuNr1+INxJGaeM EI2zBao4jVU2xf+S0Yzme096HreL4UunUq02NmJTCU+Jmzq8ENQnjuPtznKwyIMyiv NQ1Z2RFEf2JlA==
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:02:48 -0000

On 5/13/13 2:42 PM, Martin Thomson wrote:
> We've had a great deal of discussion about plan A and B and the
> various interactions of these proposals with bundling.  But I still
> don't get a good sense that there is a working consensus on what an
> m-line actually represents.
>
> I think that we've each reached our own conclusions, but they
> definitely are not consistent.  We need a well-understood semantic for
> m-lines if we have any chance of resolving these issues; Plan A/B
> being only the first RTCWEB problem to address.
>
> 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.

>   2. an m-line represents the set of RTP streams that decode into a
> single rendering, including layers, simulcast and FEC

Hmm. I was thinking *this* was what Cullen intended by Plan A.
But now that you bring it up, I thing there is some existing SDP syntax 
for simulcast/FEC/FID that might only work with (3). (But I don't have 
the details of that stuff in my head.)

>   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

I offer another try:

4. an m-line represents one or more (zero or more?) 
sources/flows/tracks/captures (pick the name that suits you) that share 
a single RTP session and that all are consistent with the media 
description accompanying the m-line.

IIUC this is what Plan B is trying to achieve.

	Thanks,
	Paul

> 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?
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>