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

Ted Hardie <> Fri, 16 September 2011 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5ADE21F8D6F for <>; Fri, 16 Sep 2011 13:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.592
X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DT4fMdzyTNqX for <>; Fri, 16 Sep 2011 13:41:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C6D9E21F8D66 for <>; Fri, 16 Sep 2011 13:41:18 -0700 (PDT)
Received: by ywa6 with SMTP id 6so3764644ywa.31 for <>; Fri, 16 Sep 2011 13:43:34 -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=50CfTpakE3V3CXotuv+VzS/ik9Yz13JFsnPDxQ19H8Q=; b=aoivHSGqf6pQus/ynOskHI865zfZot9FoSy43UXq7PhtE8Lao3GjCF+9CHsVkTcapw 7BFiuxhY2SwLEzXJSLYTp4AFXsZLe6k7LX2hRkPeApM7PL7k8VrU+2aJvX2BwNP/CFxV 3hy/IBSph8lZTqs/02jTONRtD84xVsq0kh+mQ=
MIME-Version: 1.0
Received: by with SMTP id b1mr12973522yho.19.1316205814205; Fri, 16 Sep 2011 13:43:34 -0700 (PDT)
Received: by with HTTP; Fri, 16 Sep 2011 13:43:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Fri, 16 Sep 2011 13:43:34 -0700
Message-ID: <>
From: Ted Hardie <>
To: Jim McEachern <>
Content-Type: multipart/alternative; boundary="20cf303dd4e801cda004ad150cea"
Cc: "<>" <>
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: Fri, 16 Sep 2011 20:41:19 -0000

On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <>wrote:

> Hadriel,
> Well said.
> Your closing paragraph sums it up nicely in my mind.
> <snip>
> The only thing we need to do for rtcweb is make sure the RTP library built
> into the browser supports media in such a way that it can communicate with
> other RTP peers at a media plane, regardless of what signaling protocol
> those peers might be using, preferably without going through media gateways.
>  And ... we need to make sure it's possible to use SIP on the rtcweb
> server....
> </snip>
I think there is more to it than this for it to be a success.  We have to
make sure that it is relatively easy to adopt  rtcweb in javascript
applications.  The way we've discussed that in the past was "2 party video
chat in 20 lines of javascript".   If a novel signalling protocol is created
every time, that won't be a practical choice.  Even if the signalling is
segmented into libraries, the app will have to download the one in use by a
particular website, potentially every time.  This is better than a plugin in
some ways and potentially actually worse in others.

We also have to make sure that the resulting application does not flood or
fry the network. That means it will have to have real congestion control
mechanisms.   Trusting the javascript application for that has some real
issues which we've already discussed.   Splitting signaling and congestion
control isn't a lot better.  If congestion control at the network level is
managed by the browser but signalling is in the javascript, then information
about that state has to pass into the JS application, so it can manage the
signalling.  That makes the APIs more complex and runs the risk that a naive
javascript application will not adjust to the congestion control
requirements at all.

The early web took off in part because of the ease of embedding things like
images (compared to gopher, for example) into rich content.  We have the
opportunity to create native web applications with much richer and more
interactive experiences with rtcweb, but if it is not easy to do, it won't
have the same impact.  If this is something that can be done only by folks
who can roll their own signalling protocol, it's dead, because the number of
content authors is too small.  If it even requires selecting among an
unbounded set of variously maintained libraries , it will be frustrating for
the developer of simple applications.   At that level, the existing plugins
will simply be more stable and better known.

Providing baseline APIs into a well-known signaling capability seems to me
far more likely to result in a real flowering of rtcweb content.  That's why
I want it.

Just my two cents, not taken from any hat,