Re: [rtcweb] A different perspective on the video codec MTI discussion

Ted Hardie <> Thu, 14 March 2013 03:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F88111E809C for <>; Wed, 13 Mar 2013 20:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NOKfFANdYWj9 for <>; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c02::234]) by (Postfix) with ESMTP id 6769821F8AA6 for <>; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
Received: by with SMTP id f27so1608383iae.25 for <>; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rwOcSthRIyRoUyWuoA4rlXbIKkIq/Zis34Wr2F8N5ac=; b=RoJFpx4D3xudOF7j/s/ZO90M3BBWf5gqS6A5wRWhAspzDXVbcD49cA9GeOlaaeHAPX 2/pNzP17JWFJZYH2TkIHEp6DAbZDVX9z6oYXh5+idsWnEaBdQbAPQnzSLzATfojcxGK6 9tbfnWCabhhuJQhqz1LBpxqV3l0mlGCxBRdTZhOFP0kc5gW+ZJ9M/UlzCyFH3Bw6aAqB DhEO1Vkx82/+i7VJ1gBwbBosqTaCCAtvB73YmB6mfrasO86B2+NO7+ohazLYuxgom2tB UHLNF66Jf9Unpq+wro2AoJaMciTye5PBVv+2Ju8EU5la/NaAESOS9bCV27fUu8CLzd0B aTmQ==
MIME-Version: 1.0
X-Received: by with SMTP id ez9mr665777icb.29.1363230031008; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
Received: by with HTTP; Wed, 13 Mar 2013 20:00:30 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 13 Mar 2013 23:00:30 -0400
Message-ID: <>
From: Ted Hardie <>
To: Jonathan Rosenberg <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion
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: Thu, 14 Mar 2013 03:00:32 -0000

Hi Jonathan,

A quick comment in-line

On Wed, Mar 13, 2013 at 6:06 PM, Jonathan Rosenberg <> wrote:
> The reason is simple. For many application developers, what is interesting
> about webRTC is NOT just browser to browser communications, but connecting
> users in a browser to users elsewhere - on other devices, in other networks.
> After all, the vast majority of web application developers do not have the
> luxury of a massive social graph, or the luxury of their users being parked
> persistently on their website and thus able to receive an incoming call.
> Many websites that have customer support or service needs would love to be
> able to allow their users to have a video call with an agent. However, those
> agents are probably sitting on existing agent systems which are not web
> based,

I've made the cut here because the point I want to make isn't really
codec specific. It's that the core requirement of this working group
is laid out as enabling a new real time platform based on the web.
That's set out in the charter in this language:

"There are a number of proprietary implementations that provide direct
    interactive rich communication using audio, video, collaboration,
    games, etc. between two peers' web-browsers. These are not
    interoperable, as they require non-standard extensions or plugins to
    work.  There is a desire to standardize the basis for such
    communication so that interoperable communication can be established
    between *any compatible browsers*. The goal is to enable innovation on
    top of a set of basic components.  One core component is to enable
    real-time media like audio and video, a second is to enable data
    transfer directly between clients."

The emphasis on "*any compatible browsers*" is mine.  That is the
focus of the work; that new, web-based ecology is its reason for

We have understood from the beginning that there are many other
endpoints that it would be useful to interconnect with browsers, but
we have also understood that some choices would mean that those
connections would likely travel through gateways.  There may be agent
systems like those you describe above that are capable of DTLS-SRTP,
continued consent based on ICE, and all the other pieces of our
overall system, but there are certainly also many that are not.
Gatewaying will be common, and I personally hope companies with
histories of producing successful middle boxes enter the market with a

WebRTC will not produce a successful new ecology if it focuses its
technical decisions on full interoperability with non-WebRTC systems;
while the initial opportunity looks bigger, it is ultimately something
that circumscribes the possibilities for success.  You and I have both
seen the complications which arise from following that path, and this
group and its W3C partner group made a conscious decision not to
require it.  Time will tell if the choice was the right one, but, in
the mean time, the charter is clear.  I personally think that was the
right choice, and it is certainly, for me, the more exciting

Speaking as an individual, not as chair,


Ted Hardie