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

Paul Kyzivat <> Thu, 16 May 2013 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4281B11E80B8 for <>; Thu, 16 May 2013 14:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.307
X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ICLa4J33TpFF for <>; Thu, 16 May 2013 14:13:49 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:96]) by (Postfix) with ESMTP id 484AA21F8EA4 for <>; Thu, 16 May 2013 14:13:48 -0700 (PDT)
Received: from ([]) by with comcast id ckv71l0050vyq2s59lDnZo; Thu, 16 May 2013 21:13:47 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id clDn1l01Z3ZTu2S3RlDnqL; Thu, 16 May 2013 21:13:47 +0000
Message-ID: <>
Date: Thu, 16 May 2013 17:13:47 -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: <>, <>, <>, <> <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>
In-Reply-To: <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>
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=1368738827; bh=0eoohgaFpDaNjapTaNsD6ztn+exLTKdevVpmATFG7tk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m80CGCQ+hlug7fQiWMcrncxYM9yMqX/AVzs5x3nbB23dDZvzbN8MtctI/CLnhYjyJ eubuTFaEzAK6NO47yKVdiBd2D2Rwv4XGLWhpys4m7NEInXps5KnYxsu6/hXxMesHNK 4B9yArRKBP/cb1ilHIgccnCvU8QIvZj8jWtP98lht+UCYq6SdeI5a32JthndVhGMNU 29qWpqjCGSZIkK5vgICKa2bo5g3qCWAerNPm1dtLobCJitaSYF2bRFYYM5yb8jdPlt YOs2Zd5Iyjlnh3kZeCgo/H4Zp6LXOyDKwd3vLSAJDIlWP7aqssymi2wuDSUaCf09m0 +TBzw4UnRDrPw==
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: Thu, 16 May 2013 21:13:55 -0000

On 5/15/13 2:47 PM, Bernard Aboba wrote:
> Colin said:
> "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 interoperability 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 different 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."
> [BA]  The reality is that "SIP equipment" covers an awful lot of ground.
>   There are implementations that use a single m line for video and can
> handle and render multiple SSRCs within that RTP session in different
> windows.   Emil has referred to one of those (Jitsi videobridge).  There
> are also implementations that use a single m line and support
> simulcast/layered coding, rendering SSRC groups (e.g. groupings of
> simulcast and layered sources) in different windows.   Several
> implementations of H.264/SVC work this way.
> So when people on the say "SIP equipment works this way" or "SDP works
> this way" or even "RTP works this way" my BS meter goes off.  Usually
> they mean "the equipment I'm familiar with works this way".
> I'm not sure we can make a definitive statement about what "backwards
> interoperability" means with respect to video systems today, at least
> without some work to survey existing implementations.  And this somewhat
> complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, because the
> reality is that *neither* of these plans can achieve widespread
> "backwards interoperability" with respect to SDP, if what you mean by
> that is "I can take the SDP produced by a WebRTC implementation, throw
> it over the wire to an existing implementation and expect anything good
> to happen".

Perhaps the best we can do is acknowledge that the "legacy" use of RTP 
was underspecified, and so up to the application to sort out.

To move forward, maybe we can more carefully define what we want the 
m-line to mean going forward, and add some additional syntax (e.g. an 
attribute) that says this refined definition is being used. In an O/A 
context that would need to be confirmed in the answer.

That is for an unbundled m-line. A bundled m-line clearly has a 
different definition - presumably a subset of what an unbundled one is.