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

Randell Jesup <> Mon, 19 September 2011 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E15F21F8CF0 for <>; Mon, 19 Sep 2011 15:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.582
X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, GB_I_INVITATION=-2]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bb3lfbuVqz3h for <>; Mon, 19 Sep 2011 15:37:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A77A921F8CD0 for <>; Mon, 19 Sep 2011 15:37:27 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R5mVD-0008Ju-DC for; Mon, 19 Sep 2011 17:39:51 -0500
Message-ID: <>
Date: Mon, 19 Sep 2011 18:36:28 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.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] 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: Mon, 19 Sep 2011 22:37:28 -0000

On 9/19/2011 4:33 PM, Saúl Ibarra Corretgé wrote:
>> You misunderstood me; I meant "if you use an optional SIP module, you'll
>> need to have a SIP proxy on your server".  WebRTC in general presumes some sort
>> of server architecture to solve the discovery/invitation problem.  There *are*
>> some possible uses of WebRTC that might not use a central server(s).   The simplest
>> would be the "phone-tag" server, where you and the person you want to talk to
>> exchange IP addresses and external port numbers over the phone, and type them into
>> the web app, which then opens a default-configured PeerConnection and re-negotiates
>> to the actual configuration.
> Still, you need this "phone-tag" server, so who will provide it? I don't see a way for 2 parties to communicate without help from outside the browser, thus, I wouldn't define any sort of protocol, even if we could simplify one.

The purpose of including a protocol (which is optional to use) isn't to allow
direct browser-to-browser discovery or initiation without a server.  In fact,
it doesn't help *or* hurt that use-case.  A primary reason for including a protocol
is to make it easy to build things.  We don't *just* want organizations with the
resources of Google or Skype or Cisco (or Mozilla) to be the ones who can make
use of this new capability; we want all web developers to feel it's within their
grasp.  This could be satisfied in a few ways, as discussed: "baked in" simple
SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine baked
in; or a pure JS implementation.  But we are wary of putting it out with merely
the hope that a good-enough JS lib will show up someday (and there are other pros
and cons; no need to repeat them here).

As far as needing external servers: there are some ideas we're floating around
that would allow for server-less or virtually server-less operation of WebRTC
clients including discovery and initiation, from behind NATs.  We haven't
speced it out or even proven it's workable yet, but we're going to look very
closely at some type of proof-by-existence for this idea.

Randell Jesup