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

Ted/Cary,

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.

Thanks

Partha

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
Of cbran
Sent: Saturday, September 17, 2011 2:21 AM
To: Ted Hardie; Jim McEachern
Cc: <rtcweb@ietf.org>
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" <ted.ietf@gmail.com> wrote:

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

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

________________________________

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb