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

Randell Jesup <> Mon, 19 September 2011 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5B7721F8C07 for <>; Mon, 19 Sep 2011 06:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Klp2unEdsMOO for <>; Mon, 19 Sep 2011 06:54:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D462421F8C00 for <>; Mon, 19 Sep 2011 06:54:32 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R5eL9-0005ju-KV for; Mon, 19 Sep 2011 08:56:55 -0500
Message-ID: <>
Date: Mon, 19 Sep 2011 09:53:34 -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: 7bit
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 13:54:33 -0000

On 9/19/2011 6:23 AM, Hadriel Kaplan wrote:
> On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote:
>> The point was made repeatedly when I explained this primary area of contention that we want it to be easy to use by the "little guys", and that even if signalling was a downloaded JS library, you'd end up with a wild mixture of old versions in use, which may complicate interop/federation (plus the overhead to pull them down, and some possible security issues).
> And you think having it in the Browsers won't end up with a wild mixture of old versions in use, and complicated interop/federation?

Not compared to the complexity if it's all "roll-your-own".  No one suggested that
people be locked into a signalling protocol, and JS libraries are an option.  We do
have a lot of experience with pseudo-standard APIs implemented in JS, such as jquery
and many others, and these aren't unrealistic concerns.

I lean towards a proposal I made a week or two ago; to allow full access (which allows
user-written JS signalling libraries) but provide minimal SIP+O/A as an option within
the browser.  This could be a JS library, but the primary users of this would be the
"little guys" who just want simple setup of media streams, and they're most likely to
never update, while browsers are updated frequently.

> And on top of it you'll end up with a wild mixture of signaling vendors, because there'll be a mixture of Browser vendors and it's unlikely they'll all use the same source code inside.  What's worse, it won't be controllable by the JS developer.  At least with a JS library they're all using the same source code, and the JS developer knows what it was/did if it was an older version.

That's entirely available to the application; they can use their own if they wish.
And while I suggest a simple SIP set be included, if we were certain a "standard" JS
lib were freely available and solid enough, that would make the argument stronger for
a JS lib.

> With regard to the issue of overhead of pulling it down every time, I thought browsers cache JS scripts, no?

Yes, and as of Firefox 3 if a script is served with Cache-Control: public, it will be
cached to disk even if coming from https.  Note that secure (https) content by default
isn't cached unless cache-control options are set.

I would strongly warn against fetching JS libs for a service like this over http, and as
part of the security review here we may well go further than that.

Randell Jesup