Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Ted Hardie <> Tue, 20 September 2011 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A987721F8C2B for <>; Tue, 20 Sep 2011 07:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.092
X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-2.494, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L3FDHHRvndqo for <>; Tue, 20 Sep 2011 07:58:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1528621F8C1E for <>; Tue, 20 Sep 2011 07:58:26 -0700 (PDT)
Received: by gxk19 with SMTP id 19so500869gxk.31 for <>; Tue, 20 Sep 2011 08:00:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/zGRe5L78LiJy1/SQRCzyqr+GUo2Y31/oml62+jGIko=; b=h6ITq8/GOsUQNAeIZsx2gRWGonuFysCg7vfknj4HAJ2COHMnj0TXdBN9XDc9F+Hks0 pZ8DOxPST/DKMV/LPeQ1O5QQp+xZh5o7BLyMduv98Zw4iiptR7qlFEIp7rlQbo1un2Fj bXOon53EmdEE1xslwh/WVDx7V1YQkyIcevV2I=
MIME-Version: 1.0
Received: by with SMTP id b1mr5483010yho.19.1316530844749; Tue, 20 Sep 2011 08:00:44 -0700 (PDT)
Received: by with HTTP; Tue, 20 Sep 2011 08:00:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 20 Sep 2011 17:00:44 +0200
Message-ID: <>
From: Ted Hardie <>
To: Matthew Kaufman <>
Content-Type: multipart/alternative; boundary=20cf303dd4e8564ee004ad60b96a
Cc: Randell Jesup <>,
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
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: Tue, 20 Sep 2011 14:58:26 -0000

On Tue, Sep 20, 2011 at 12:46 AM, Matthew Kaufman <
> wrote:

> By that logic we should have a built-in shopping cart to make creating web
> storefronts easier, a built-in email client to make it easier to build the
> next Gmail, etc.
> Except that all the interesting things that have ever happened on the web
> are because clever people used the minimal built-in stuff to make something
> much more than the sum of its parts, not because the masses used the
> pre-built parts to replicate what already exists.
> I don't want my web browser to have a phone inside of it. I want my web
> browser to be the thing that someone turns into the next great real-time
> communications experience... whatever that is.
I may still be jet-lagged (okay, I am still jet-lagged), but the reductio ad
absurdum of that seems to be "I don't want my web browser to have a baked in
file transfer protocol, I want it to be a platform for building the next
great file transfer protocol experience".

Having a standard signaling method for setting up media session neither
prevents the creation of other signaling methods nor does it limit what
sessions are getting created.  It does facilitate doing the things we know
we want to do in the common case--which includes  making embeddable
interactive audio/video easy to code and deploy.

Again, just my two Rappen.