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

[Ted Hardie <[e-mail]>]

On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <[e-mail]>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,

Ted