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

Paul Kyzivat <> Mon, 13 May 2013 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21CFD21F9488 for <>; Mon, 13 May 2013 12:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.746
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LqQs5JNVJZKb for <>; Mon, 13 May 2013 12:02:37 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:56]) by (Postfix) with ESMTP id 8AEE221F947C for <>; Mon, 13 May 2013 12:02:36 -0700 (PDT)
Received: from ([]) by with comcast id bUVQ1l0050QuhwU56X2coL; Mon, 13 May 2013 19:02:36 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id bX2c1l00F3ZTu2S3NX2c4N; Mon, 13 May 2013 19:02:36 +0000
Message-ID: <>
Date: Mon, 13 May 2013 15:02:35 -0400
From: Paul Kyzivat <>
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
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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-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: 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.


> 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