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

José Luis Millán <> Mon, 19 September 2011 10:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78AB721F8B7F for <>; Mon, 19 Sep 2011 03:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.825
X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sRsqmkZuNK-X for <>; Mon, 19 Sep 2011 03:15:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7199021F8B7A for <>; Mon, 19 Sep 2011 03:15:15 -0700 (PDT)
Received: by iaby26 with SMTP id y26so6540477iab.31 for <>; Mon, 19 Sep 2011 03:17:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id l14mr3827459ibi.69.1316427457949; Mon, 19 Sep 2011 03:17:37 -0700 (PDT)
Received: by with HTTP; Mon, 19 Sep 2011 03:17:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Mon, 19 Sep 2011 12:17:37 +0200
Message-ID: <>
From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= <>
To: Randell Jesup <>
Content-Type: multipart/alternative; boundary=00151773e02800ef6804ad48a71c
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 10:15:16 -0000


2011/9/19 Randell Jesup <>

> +1 (comments below in-line)
> On 9/16/2011 4:43 PM, Ted Hardie wrote:
>  On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <<mailtomailto:
>> jim.mceachern@genband.**com <>>> 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.
> I agree whole-heartedly.  My (and I'll say Mozilla's) position is that we
> believe that while enabling unique new signalling and negotiation makes
> interesting new applications possible, we also must make sure that this
> ability is equally available to a (say) games developer who wants to add
> voice or video chat to their game without having to learn or understand 20
> years of discussions and experience with signalling and media protocols.
> As far as I know, this is achieved by a user level API regardless of the
signalling controller nature; browser built-in or JS stack, which serves as
an abstraction of the library underlying ins and outs.

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

 I would say that Mixture of old versions and the possible security issues
are problems to face in any case.

>> 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.
> I think we do want to optionally include the JS application in the
> decisions about bit allocation, but handle it automatically for most cases.
>  A class of complex WebRTC apps will want to be able to allocate the bits
> themselves, and in some cases drop or add streams (or switch operation
> modes) in response to bandwidth changes.  Details to be determined; I plan
> to make a proposal on this.  However, unless you go out of your way none of
> this will impinge on your straightforward WebRTC app.
>> 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.
> +1
>> 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,
>> Ted

> --
> Randell Jesup
> ______________________________**_________________
> rtcweb mailing list