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

Paul Kyzivat <> Wed, 15 May 2013 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA4BC21F8F69 for <>; Wed, 15 May 2013 09:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.825
X-Spam-Status: No, score=0.825 tagged_above=-999 required=5 tests=[AWL=-1.038, 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 GpQbcnw2CRPD for <>; Wed, 15 May 2013 09:03:42 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:32]) by (Postfix) with ESMTP id F1DFC11E80D2 for <>; Wed, 15 May 2013 09:03:41 -0700 (PDT)
Received: from ([]) by with comcast id cAyf1l0051ap0As53G3hGY; Wed, 15 May 2013 16:03:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id cG3h1l00A3ZTu2S3iG3hNl; Wed, 15 May 2013 16:03:41 +0000
Message-ID: <>
Date: Wed, 15 May 2013 12:03:39 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
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=1368633821; bh=0ZmsY/3VhYHx1RXA6ZShInZ/Rkdt1WNb+MG2vPyl2q0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kxhy8RQx6teZ3V3Ywjl+xEvz9aGNj25RHItXHfuFKCksk5n0XXUZrQrOAT0u1bVO2 AUEinokSUYocsPHJAcVtUQHDKclO3S9I9SXTg0QCgput356Ngbixa2NSdtyeUZyGUn Q79BAGAer3+M28T9iep5YGGWFyTU1kBdNxYuMNjnjMwmq0lEQQ0TjP5zOyZoyXHxcD SYfhi+EvxcExHdShqULf2qdSVRj5+UbCj1gMSEqg+tK5AM1Sj0lqyh+KOFpOzCL5Lx KbvjXZAaE2Qvqn2FNRX03SRVfL7/8zEomO+9p335N5m846g4jczOeFj5O0m4Jf5PCM M8pX5cUB+HmHA==
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: Wed, 15 May 2013 16:03:47 -0000

On 5/14/13 9:58 AM, Cullen Jennings (fluffy) wrote:
> People often want to look at this from the point of view of what they wish they can change SDP to mean, but unless we are doing SDPng, we need to look at it from the practical point of view of what has deployed and what SDP was defined as when that equipment deployed. We need to find a way that provided backwards interoperabiliyt while still allowing us to negotiate the things we want now. You can easily define an extension to SDP that means that RTP received on a single m line was meant to be rendered in differnt windows, but the fact of the matter remains that is not how lots of SIP equipment worked so you can't pretend SDP always meant that because it did not.

ISTM that there are two questions here:

- what is an m-line *without* bundle

- what is an m-line *within* a bundle

There are necessarily different, though of course our goal is to exploit 
some similarity between them.

My earlier reply with an alternative (4) was intended as an answer to 
what an m-line *within* a bundle is.

We clearly have different ideas of what a "legacy" m-line is.
Colin expressed a preference for (1). I guess that is probably a good 
proxy for what the "real RTP people" intended for it to be. My 
impression is that Fluffy most likely thinks (3) is closer to right, 
based on what is deployed in the sip world. The situation where what is 
deployed is different than what was intended isn't a new one. But its a 
hard one to come to grips with.

But what we most need to agree to is what a m-line will mean *within* a 


> On May 13, 2013, at 12: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
>> 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?
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list