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

Harald Alvestrand <> Wed, 15 May 2013 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FC4621F84DC for <>; Wed, 15 May 2013 13:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4pjEz9AIgZpa for <>; Wed, 15 May 2013 13:04:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E0CF721F8233 for <>; Wed, 15 May 2013 13:04:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 313FC39E199 for <>; Wed, 15 May 2013 22:04:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e9+9G2gDlyfW for <>; Wed, 15 May 2013 22:04:45 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:c9:5f50:178a:75d] (unknown [IPv6:2001:470:de0a:27:c9:5f50:178a:75d]) by (Postfix) with ESMTPSA id 06DB539E116 for <>; Wed, 15 May 2013 22:04:44 +0200 (CEST)
Message-ID: <>
Date: Wed, 15 May 2013 22:04:44 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
References: <>, <>, <>, <> <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>
In-Reply-To: <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>
Content-Type: multipart/alternative; boundary="------------060604000007040700010308"
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 20:04:54 -0000

On 05/15/2013 08:47 PM, Bernard Aboba wrote:
> <snip>
> 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".

I take a somewhat different approach:
If it's possible to *write an application* that uses the WebRTC 
interface, does not mangle the SDP, and sends that to an existing 
implementation (supporting SRTP and ICE), and has something useful 
happen, I think it's the success we can hope for.

This may mean having the application use content settings to force 
tracks to different m-lines, keep low the number of tracks offered, and 
other tricks that make sense in the context of *that application*.
It's the *application* that needs to interwork, it's not "WebRTC in 
general". WebRTC just needs to make it possible.

I see the idea that *any application* should produce SDP that's useful 
in such a scenario as an illusion, and pursuing that illusion is just 
going to hurt us.

> 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).

I find nothing to disagree with in this paragraph.