Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

Martin Thomson <> Fri, 19 July 2013 17:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3008611E80E3 for <>; Fri, 19 Jul 2013 10:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aFtxjzPZIyC4 for <>; Fri, 19 Jul 2013 10:58:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) by (Postfix) with ESMTP id 67B7B21E80DC for <>; Fri, 19 Jul 2013 10:58:03 -0700 (PDT)
Received: by with SMTP id c10so82738wiw.17 for <>; Fri, 19 Jul 2013 10:57:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B5TLJiMVsumn9hNXrfyvKdCg4UVOXv+Fk0iF8OGV3Xw=; b=bLvQOKrTpDJMTIKuFqXdD+VC3/gz53204u7Rhvo5PrSKX/sxNclTCXteT8so640CHe JuN14ZAAJdpFCUjT8g1vCaYemy8DtdHS63tcEDbH3ldCyoFKbEJzqgP7Cz8XbsqzTqlo rLvJ9uKCMHjF0m3RfIiyhR/5IHx/62kz00GcmVTYPmrBGHnNRsI0QxrGRRdYuu1Tq/j3 BWWOJvCofKVNfaHEGlxmGEsi6rHpgKWIicy1B6BJRWuFvA2RtfGBUVqbjxrQV4dig1vk ecCYpkKuFLp9eI5iT8JKz5wiRkTqtDnX2DHbyqMBmHrWkPB/Sy89kUYkKcIfact/e8H/ +byQ==
MIME-Version: 1.0
X-Received: by with SMTP id a14mr12947251wjx.84.1374256675056; Fri, 19 Jul 2013 10:57:55 -0700 (PDT)
Received: by with HTTP; Fri, 19 Jul 2013 10:57:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <> <> <> <> <> <> <>
Date: Fri, 19 Jul 2013 10:57:54 -0700
Message-ID: <>
From: Martin Thomson <>
To: Peter Thatcher <>
Content-Type: text/plain; charset="UTF-8"
Cc: "<>" <>, "" <>
Subject: Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Jul 2013 17:58:07 -0000

On 19 July 2013 10:39, Peter Thatcher <> wrote:
> So, are you trying to say "Look how hard this is to do with SDP.  We're not
> even done yet.  It will be even harder without SDP"?

In the Atlanta meeting (Nov 2012) I remember waiting for those damned
elevators with Justin.  He said something like: "So, if we'd chosen
comment 22 [CU-RTC-Web] do you think we'd be done by now?"  I was
quick to answer, "Of course not."  After all, we'd only made that
proposal 3-4 months earlier.  I know that nothing gets done in less
than a year, and this is not a small undertaking.

Since then, I've gained a more nuanced view.  We've set an impossibly
high bar for this specification, including all sorts of crazy
features: FEC, simulcast, layered codecs, congestion control,
undeployed codecs, multiplexing, and not to mention a new data

In reality, SDP never negotiated all that crap before.  Worse, despite
the existence of RFCs for most of these features, it turns out that
most implementations were proprietary.  We couldn't even agree on what
an m-line represents.

So, if asked the same question today, I'd probably have to say: "We'd
at least have had basic scenarios shipped.  We might not have sorted
out the hard cases like layered codecs, but we do have basic

What we have this the complete antithesis of any project I've been
involved in over the past 10 years.  It's gold-plating the pink

If we want to ship this thing, then we should be managing scope, not
protecting it.