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

Colin Perkins <> Wed, 15 May 2013 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA49121F8F33 for <>; Wed, 15 May 2013 11:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.448
X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yCJCq-0QgAk0 for <>; Wed, 15 May 2013 11:59:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 018C021F859D for <>; Wed, 15 May 2013 11:59:27 -0700 (PDT)
Received: from [] (port=39185 helo=[]) by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Ucgv7-0004uv-Jh; Wed, 15 May 2013 19:59:26 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6A0C4719-F4E9-416A-A672-B163C9B528DE"
From: Colin Perkins <>
In-Reply-To: <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>
Date: Wed, 15 May 2013 19:59:24 +0100
Message-Id: <>
References: <>, <>, <>, <> <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>
To: Bernard Aboba <>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "" <>
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 18:59:32 -0000

On 15 May 2013, at 19:47, Bernard Aboba wrote:
> Colin said: 

For the record, I think it was Cullen said this, although in a message I quoted. 


> "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". 
> IMHO, it is unrealistic to expect *any* implementation of the current WebRTC API to deliver that.  Until "comment 22" is resolved, SDP parsing/munging is going to be an unpleasant, time consuming but necessary task for interop with legacy equipment.  So as they said in Dr. Strangelove, "stop worrying and love the bomb". 
> What I *would* like is for the RTP/RTCP produced by WebRTC implementations to not require a compute intensive media gateway/transcoder/munger to enable media to be handled by existing systems, at least when the same video codecs are available (and no, that shouldn't necessarily mean "video codec implementations based on the same source code", because the spec should be good enough to enable interoperability of independent implementations).  

Colin Perkins