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

"Ravindran Parthasarathi" <> Mon, 19 September 2011 05:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6B1921F8B14 for <>; Sun, 18 Sep 2011 22:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 035SgpZjUKQY for <>; Sun, 18 Sep 2011 22:26:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AC41021F85AA for <>; Sun, 18 Sep 2011 22:26:55 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p8J5Tht3003167; Mon, 19 Sep 2011 01:29:43 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 01:29:12 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC768D.0E42C043"
Date: Mon, 19 Sep 2011 10:59:08 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
Thread-Index: Acx0skUlp3o+dLYgY0SRUu0WF3nTZAB2NTGg
References: <> <>
From: "Ravindran Parthasarathi" <>
To: "cbran" <>, "Ted Hardie" <>, "Jim McEachern" <>
X-OriginalArrivalTime: 19 Sep 2011 05:29:12.0001 (UTC) FILETIME=[1021AB10:01CC768D]
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 05:27:03 -0000



I agree with you totally. The intention of RTCWeb default signaling
protocol is to build the real-time application by any JavaScript web
developer without the understanding intricacies of underlying signaling
protocol. Also, the default signaling protocol is not going to stop any
innovative new or existing signaling protocol in RTCWeb client(browser).


IETF provides default signaling protocol and W3C provides browser API.





From: [] On Behalf
Of cbran
Sent: Saturday, September 17, 2011 2:21 AM
To: Ted Hardie; Jim McEachern
Cc: <>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
defining a signaling protocol for WebRTC (or not)]


+1 Ted - totally agree.

On 9/16/11 1:43 PM, "Ted Hardie" <> wrote:

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

Well said.

Your closing paragraph sums it up nicely in my mind.

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....

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

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,



rtcweb mailing list