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

Harald Alvestrand <harald@alvestrand.no> Wed, 15 May 2013 20:04 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4621F84DC for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 13:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pjEz9AIgZpa for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 13:04:49 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E0CF721F8233 for <mmusic@ietf.org>; Wed, 15 May 2013 13:04:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 313FC39E199 for <mmusic@ietf.org>; Wed, 15 May 2013 22:04:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9+9G2gDlyfW for <mmusic@ietf.org>; 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 eikenes.alvestrand.no (Postfix) with ESMTPSA id 06DB539E116 for <mmusic@ietf.org>; Wed, 15 May 2013 22:04:44 +0200 (CEST)
Message-ID: <5193EA5C.7050905@alvestrand.no>
Date: Wed, 15 May 2013 22:04:44 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com>, <C5E08FE080ACFD4DAE31E4BDBF944EB1134E782F@xmb-aln-x02.cisco.com>, <5193B1DB.2070308@alum.mit.edu>, <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <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-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=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".

Bravo!


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