Re: [rtcweb] Usecases for innovation.

Randell Jesup <> Wed, 02 November 2011 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C3061F0CA0 for <>; Wed, 2 Nov 2011 10:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cFUlKvh3Hm5w for <>; Wed, 2 Nov 2011 10:55:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EA1961F0C4B for <>; Wed, 2 Nov 2011 10:55:45 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1RLf2P-0006aA-1X for; Wed, 02 Nov 2011 12:55:45 -0500
Message-ID: <>
Date: Wed, 02 Nov 2011 13:55:25 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Usecases for innovation.
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: Wed, 02 Nov 2011 17:55:46 -0000

On 11/1/2011 12:02 PM, Wolfgang Beck wrote:
> On Tue, Nov 1, 2011 at 3:18 PM, Iñaki Baz Castillo<>;  wrote:
>> 2011/11/1 Tim Panton<>;:
>>> I've repeatedly been asked for use-cases for innovative applications of webRTC
>>> to justify my contention that we should be providing a low-level framework,
>>> not an embedded legacy compatibility application.
> [..]
>> Indeed most of the discussions in this WG are about how to make
>> ***current*** SIP devices to work with a WebRTC scenario. It's a
>> limited vision of WebRTC in which the main interest is to make profit
>> of this new spec within telcos business. Bad IMHO. But, where are
>> those "innovative" and "crazy" Web folks right now? why 95% of people
>> discussing in this ***open*** WG are telcos? So this is also their
>> fault, the fault of people not participating here and now.

Well, the IETF's AVT group has a strong component of telephony (really 
VoIP/Video) people, so it's not that surprising.  Most of the "web" 
people would be focused on the W3C side of things, and have minimal 
interest in the plumbing. ;-)  Mostly only in how the exposed interfaces 
affect them, but they (generic website/app developers) haven't really 
seen what's proposed yet - and most of them don't even follow the W3C, 
which is more major site vendors and browser people I believe.

I straddle both - long-term core Mozilla contributor, now employee, but 
in the interim spent 7 years working on videophones. But I'm no expert 
on website/javascript-library design.  (Mozilla does have people more 
focused on that involved.)

> Well, I'm working for a telco. Hadriel' employer sells equipment to
> telcos and telephony providers.
> Still our proposals to avoid standardized signaling and to depart from
> classical telco signaling flows were not well
> received by the crazy web folks. The world has turned upside down..

We (browser vendors) have a strong focus on getting something 
deployable, without unduly limiting potential innovation.  We also (as 
has been mentioned) have concerns over complexity exposed and the 
resultant reliance on (rarely-if-ever-updated) JS frameworks.

Quite honestly, the largest problem we have is NOT signalling; one way 
or another media and data channels can get open and negotiated.  The 
biggest problem and hardest one to "solve" (it's not truly "solvable") 
is security and privacy and the user-interaction aspects of that.  The 
technical issues of signalling, congestion control, and data channels 
are all eminently resolvable (even if there is no universally-agreed 
'best' solution).  Security and privacy are far harder, and the 
solutions less satisfying.

So, if you have brain cycles to born, spend them on security, IMHO.

(Note: personal opinions, not official Mozilla position, though 
"Mozilla" may agree with me)

Randell Jesup