Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

Saúl Ibarra Corretgé <> Wed, 19 October 2011 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27B0E21F8C4A for <>; Wed, 19 Oct 2011 10:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sc-EtggxlyJD for <>; Wed, 19 Oct 2011 10:43:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F0F421F8C49 for <>; Wed, 19 Oct 2011 10:43:30 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 3ED4CB01A5; Wed, 19 Oct 2011 19:43:28 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 6917CB019E; Wed, 19 Oct 2011 19:43:27 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Saúl Ibarra Corretgé <>
In-Reply-To: <>
Date: Wed, 19 Oct 2011 19:43:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dan York <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
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, 19 Oct 2011 17:43:31 -0000

Hi Dan,

> If they are with startups, they want to build nice bright shiny objects that people will chase and use.  They want to make the next Twitter or FourSquare or (pick your cool service that everyone salivates over).  If they are with more established companies, they want to create easy-to-use interfaces that expose data or information in new and interesting ways or allow users to interact with their web apps in new and useful ways.
> And they want to do all this using the "languages of the web"... JavaScript, PHP, Ruby, Python, etc.
> They want "easily consumable" APIs where they can just look at a web page of documentation and understand in a few minutes how they can add functionality to their app using simple REST calls or adding snippets of code to their web page.  Their interaction with telephony is more along these lines:
> "Wow, dude, all I have to do is get an authorization token and curl this URL with my token and a phone number and I can create a phone call!"
> And the thing is... they can do this **TODAY** with existing proprietary products and services.  You can code it all up in Flex/Flash. You can write it in Java.  You can use Voxeo's Phono.  You could probably do it in Microsoft's Silverlight.  I seem to recall Twilio having a web browser client.  A bunch of the carriers/operators are starting to offer their own ways of doing this.  On any given week there are probably a dozen new startups out there with their own ideas for a new proprietary, locked-in way of doing RTC via web browsers.
> Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communications between browsers. 
> It can be done today.  Now.


Well, lets take Phono as an example. Why can people build cool things with it? Because it's a simple library and developers don't need to do much, right? That's only true because someone (Voxeo in the case of Phono) provides a server for it. Inaki and Jose could very well build a jQuery plugin on top of that jsSIP library which would connect you through *their* OverSIP servers and it would work just as good. A phone in your browser, 10 lines of JS.

Don't get me wrong, I don't want to bring the PSTN dinosaur into web browsers, but I don't want to build another island o devices to which we'll need to gateway later either, because we will.


Saúl Ibarra Corretgé
AG Projects