Re: [rtcweb] Alternative decision process in RTCWeb

Phillip Hallam-Baker <> Mon, 02 December 2013 20:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 17FF01AD845; Mon, 2 Dec 2013 12:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QqPFepJjq4Mo; Mon, 2 Dec 2013 12:12:37 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::234]) by (Postfix) with ESMTP id C40A31ADBFF; Mon, 2 Dec 2013 12:12:36 -0800 (PST)
Received: by with SMTP id t61so6739607wes.25 for <multiple recipients>; Mon, 02 Dec 2013 12:12:34 -0800 (PST)
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=jimGY7k98L6kiDgFU7p4ePE7mjatZTMVGgssKUValnc=; b=F2dVx8KkcRdjStKDF7l7MQYKg3derRk2gqTWu6UAvoljWnX8HyjlK2UVUQ5io5hme0 V0AUNXdYmNEjuiMKhPntEygS1Aw/kHfQcEOVoTzcscmNINCQV/GsXk4s/eGwl4rWkjkf EaorDZkIvVvk0lTHKHUuD/1v9nRn3fIjqQ9Uskb2dEcgHVAgWgelkDNeYTg3E9ogbtti gbFelysCxdKToZnZ5gdUxk/CbNFkEYwztkcaUxCXIjMepkyzal+cNVODlki68pjvTqC9 cmV8eRi8OhMDGKfLO/FFg3t6Ug0GN24ljEtMhNOjv6l88Wrk+88fQIkOKcx8DH8K4DKC yytw==
MIME-Version: 1.0
X-Received: by with SMTP id gg16mr19721244wic.32.1386015153919; Mon, 02 Dec 2013 12:12:33 -0800 (PST)
Received: by with HTTP; Mon, 2 Dec 2013 12:12:33 -0800 (PST)
In-Reply-To: <>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <>
Date: Mon, 02 Dec 2013 15:12:33 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Bjoern Hoehrmann <>
Content-Type: multipart/alternative; boundary="001a11c22314e71c8b04ec92ccb5"
X-Mailman-Approved-At: Tue, 03 Dec 2013 08:35:01 -0800
Cc: "" <>, IETF Discussion <>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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: Mon, 02 Dec 2013 20:12:39 -0000

On Mon, Dec 2, 2013 at 2:27 PM, Bjoern Hoehrmann <> wrote:

> * Ron wrote:
> > 2. Can anybody show a sustainable objection for why we _can't_ use H.261.
> >
> >   If they can, we're probably doomed.  If they can't we have an initial
> >   choice for MTI.
> I have not seen a convincing argument that H.261 performs well enough to
> permit real-time video communication at reasonable quality and bitrates.

That is irrelevant.

MTI does not need to be a good choice, it merely needs to achieve

If someone can support HD video over a 300 BAUD connection, the technology
is almost certain to be proprietary. That does not mean that the IETF has
to accept the proprietary technology as MTI because it is the only one that
supports the needs of 300 BAUD users, it means that that group of users may
not be supported by the MTI CODEC.

MPEG2 will come out of patent in the nearish future and it is a not
terrible choice. It is certainly not the best choice but it isn't a
horrible one.

> I have not seen recent statistics for Germany but I suspect it is common
> that household members share a line with an upstream of around 640 kbps,
> that would basically allow for two 320x240 H.264 CBP + Audio streams at
> 30 fps in good quality. Would H.261 permit at least one stream at the
> same quality? If not, then nobody would use H.261-only WebRTC products,
> and people are not going to appreciate if a VP8 product connecting with
> a H.264 product falls back to H.261 to avoid negotiation failure.

People would use H.261 if that is all the clients at either end supported.
The value of the H.264 patent pool would be reduced from the ability to
perform the application to a quality issue for some subset (a clear
minority) of the user base.

We knew that there were real security and performance problems with 3DES
when we made it MTI in TLS 1.0 but that was the best choice available at
the time.

If there was an optimal technical choice that had no other consideration
there would be no need for MTI clauses at all.