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

[Randell Jesup <[e-mail]>]

+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 
> <[e-mail] <mailto:[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.

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.

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

>
> 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
[e-mail]