Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web

Bernard Aboba <> Tue, 16 December 2014 22:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C8271A0049 for <>; Tue, 16 Dec 2014 14:30:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c2ZO-SMCi8oy for <>; Tue, 16 Dec 2014 14:30:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D11091A004C for <>; Tue, 16 Dec 2014 14:30:11 -0800 (PST)
Received: by with SMTP id a108so10789492qge.8 for <>; Tue, 16 Dec 2014 14:30:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P+OBCnbRYy3M18UPXY1Qry3L9agnTOcVbIYUAO/k5K8=; b=S2yNBkjowy1Cy1hafdJfVa5V5/Xsg/X7PL/pNhRHkH6aZq/ckgGlTfqeweCHjs6iDH 8nhG+VnFhG/djVdvMOO4VukRiB3v1VD0pwgIBwi/gUcKUtJAhMqAFUm8iBecrpdqlfI1 AmyStq0l15+iiCFWXm68RR2y3Euf3T3u5vA6nQ/bUir1WMQfG0NXYn18WiUpiLTZfJkf Y2J5+K6cZtp3ZtR9v8kzVqVZl47aA1lL8hCP6DUiHfSUbWeTahbG8smZOb8BaxlNfsfT 9l9N5z/Wpj4JjpdrEirLndzZ76Xy+lG7WobSDJYKo/LyIars9CAozAghLMxOCKaxwwJn 5H9Q==
X-Received: by with SMTP id t63mr14568355qgd.72.1418769011059; Tue, 16 Dec 2014 14:30:11 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 73sm2114464qgt.42.2014. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 14:30:09 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <>
X-Mailer: iPad Mail (12B440)
In-Reply-To: <>
Date: Tue, 16 Dec 2014 17:30:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <20141215192409.GN47023@verdi> <> <> <> <> <> <> <20141216150303.GT47023@verdi> <> <20141216152100.GU47023@verdi> <> <> <> <>
To: "<>" <>
Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web
X-Mailman-Version: 2.1.15
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: Tue, 16 Dec 2014 22:30:16 -0000

On Dec 16, 2014, at 3:18 PM, David Singer <> wrote:
> no, quite the reverse.  If all browsers are also devices, then we only need to state the requirements for browsers if they differ from devices, and they don’t, do they?

[BA] Let us get real.  The idea that codecs are holding back WebRTC web site development is entirely bogus. 

Today developers are building WebRTC mobile apps that interoperate across platforms, based on a codec chosen by the developer. This works well enough that there are at least half a dozen major apps, each serving (tens? hundreds?) of millions of users. 

What we have NOT seen is a comparable blossoming of Web sites based on WebRTC. Clearly this cannot have to do with codecs because both WebRTC-enabled browsers support a common codec. So at present, a developer can build a mobile app and web site using VP8 that interoperates.

Yet that has not been enough. It doesn't take a genius to figure out why. The IETF RTCWEB protocols are relatively mature (with the exception of new stuff like ICE mobility) since they are mostly based on RFCs that were already implemented in working open source prior to WebRTC. So give a mobile developer open source code that works and they will figure out the APIs and what fixes/customizations they need to make it work. 

However the browser model is very different. The browser app developer typically cannot compile their own browser or fix browser bugs so they have to live with what is there. Today's polyfills typically only work for audio so writing a multi-browser video app that supports multiple video streams is a nightmare even without a codec problem. 

Imposing a dual MTI requirement will not solve this problem and in fact is likely to make it worse, because I fully expect that video capabilities will differ markedly between implementations. So today with the same codec we see browsers differ in multi stream, simulcast and SVC capabilities. From these three dimensions, adding more codecs is likely to add to the dimensions of difference on several more dimensions. Care to guess how much more time it will take to polyfill all the *new* differences?