Re: [rtcweb] Alternative decision process in RTCWeb

cowwoc <> Tue, 03 December 2013 15:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F0F01AE154 for <>; Tue, 3 Dec 2013 07:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GyZHHwvZb_al for <>; Tue, 3 Dec 2013 07:57:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 989D51AE05B for <>; Tue, 3 Dec 2013 07:57:30 -0800 (PST)
Received: by with SMTP id tp5so24092749ieb.11 for <>; Tue, 03 Dec 2013 07:57:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Cnq0gLi5Nse9ScJf+63f/LKL027b3+mzQ+sIWTyuxis=; b=bJixv+BuXVDWVyZsXDwbfkZHV7V56VrfXONXbkrs9jH4CEoEoUxzMq8lb6EbZqhD5q ROKw1eZd1VbkzGq/FVdkxjLdteA5hg1tvO0GdhyQlBv3CZTlyiF73Itr9wsXUMcQGoqg NaQ3P18hmNMSLBpN+7TmWfpZBRiHXUcJrjy3C2Aw8nyM5ntqJIMWldo6uO8RJGb7LzUe 19H9hcLoXByBqijGJOiAzpslh35RmzzUMbb263+X8PLXGj79SgbUHepNr112JuLOLNvR zhUAwH4KtscT/tTnLx/92i0ZMqY7kS5fSx4NXtVLek0uj2GYbGsGQVrxshv6UmpBrtI8 CH2A==
X-Gm-Message-State: ALoCoQnSd/WTJgZ2kCtkLae58hIO9zW/gQY3MafGwNuCEjf/9cJUoMo5vOlCtDUhgUomJHcft+ho
X-Received: by with SMTP id u1mr3262283igz.42.1386086247734; Tue, 03 Dec 2013 07:57:27 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id qi3sm3668172igc.8.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 07:57:26 -0800 (PST)
Message-ID: <>
Date: Tue, 03 Dec 2013 10:57:23 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Bjoern Hoehrmann <>
References: <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040001000109010903060409"
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: Tue, 03 Dec 2013 15:57:35 -0000

On 03/12/2013 8:15 AM, Bjoern Hoehrmann wrote:
> * cowwoc wrote:
>> I'd like to point you to
>> for two reasons:
>> 1. It states that Germany has an average upload rate of 3.13Mbps.
>> 2. It shows that upload speeds are increasing over time.
> That seems extremely unlikely to me, basic offerings like Vodafone's
> "DSL 6000" come with around 640 kbps upstream, Telekom's "Call & Surf
> Basic" comes with "up to 1 mbps", where I am right now the best DSL
> available has less than 384 kbps *downstream*; that does not add up
> to a situation where the median household has 3 mbps without extra-
> ordinary evidence ("average" over ones that care to test can naturally
> be expected to be much higher than the median over the population.)
>> H.261 is meant as a fallback only in the case that the market cannot
>> agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the
>> market cannot agree at runtime, what makes you believe that that same
>> sizable portion can agree on a MTI codec? And a final question, in case
>> you disagree with everything I've written so far: How do you advocate we
>> proceed in light of the fact that we already tried to (and failed) to
>> reach consensus around VP8 and H.264?
> If I were to believe VP8 and H.264 are not royality-free options that
> can be used in Free implementations of the protocol then the mandatory-
> to-implement codec is likely their only option to communicate with
> commercial implementations. If the only option is "not good enough", I
> might prefer the Working Group say so instead of offering a fig leaf.

I don't understand. What is the practical benefit of declaring "No MTI" 
(as you seem to be implying) over considering H.261 as MTI?

 1. What you could accomplish with with "No MTI" you could accomplish
    with H.261 as MTI (and more).
 2. What might not be good enough for one business/use-case will be for
    another. Why penalize all use-cases?
 3. What might not be good enough in Germany (today) might be good
    enough in North America and Asia. Why penalize the rest of the world?

Things *will* improve in Germany (supply will follow demand). Up until 
recently, Canada was stuck with 1MBps upload rates for over a decade. 
Out of nowhere we started getting upload rates of 10MBps, 20MBps and 
even 50MBps. The technology is there. The only thing holding it back are 
politics (monopolies in our case) and demand.