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

[Matthew Kaufman <[e-mail]>]

On 10/4/2011 9:06 PM, Randell Jesup wrote:
> On 10/4/2011 2:19 PM, Bernard Aboba wrote:
>> [BA] I think this is the main point. If we finish RTCWEB 1.0
>> expeditiously, this will in all likelihood
>> spawn a number of browser-independent signaling libraries, as well as
>> developing a wealth of experience
>> with the limitations of RFCWEB 1.0, to inform future efforts.
>>
>> The alternative is to "load up the camel" until it collapses under the
>> weight of (largely irrelevant) use
>> cases. Since the realtime web has been around for over a decade, we have
>> a pretty good idea of what
>> native realtime capabilities would be used for -- and PSTN connectivity
>> has never been high on the list.
>
> Well, I'd say that's mildly debatable - VoIP companies chew a lot of 
> bandwidth on the net, and it's almost all going to the PSTN - though 
> it's not in browsers generally.  Skype completes a lot of on-net calls 
> - but they make a lot of money (almost all?) from PSTN calls.
>
> That said, I don't consider the Skypes of the world a problem here - 
> they can and will roll their own.  Same for PBX vendors I suppose, 
> though they'll try to leverage more existing examples.
>
> I think there will be a lot of small-to-medium users adding chat, 
> building games, etc, who care little or not at all about the PSTN. 
> Those are the ones who I worry about; they wouldn't realize there are 
> issues with glare (totally ignoring PSTN) or that forking can be 
> complex.  They want a simple, one-stop-shopping solution for adding 
> voice/video/data to their sites and games, etc.

Ok, so they don't know there's issues with glare or that forking is 
hard. Does that mean that we solve forking in the browser?

>
> Yes, people will build JS apps to provide that.  I'm worried about the 
> quality of those apps, and that the likely model will be the author 
> downloads a random version when they develop their service, and they 
> never update it.  This is a real problem; it is a real problem today 
> with other JS modules.

It can also be really simple JS modules and most of the complexity up at 
the server.

Or even more likely (see all the various mashups of the world already), 
simple JS modules and most of the complexity at a third party server 
that you use via its REST APIs.

>
> Does this mean we *have* to bake in some sort of signalling?  No, it 
> doesn't.  It is an _argument_ for providing some type of signalling as 
> a baseline default; or if not, then for starting a project to provide 
> that.
>
> Note that I said "baseline".  I did *not* say "can handle all the 
> intricacies of the PSTN well".

So does "baseline" include handling the fact that "forking is hard", or 
does baseline not address forking either?

> It could be something far simpler than
> SIP or XMPP, etc, or it could be a very dumbed-down version of one. 
> These small users (as noted) need something to provide the basics, and 
> to handle certain complexities that simply arise from normal usage 
> patterns and features (like forking).  Being able to access the PSTN 
> at all using this would be a plus - but it would not be critical in my 
> mind.

This still doesn't mean that the browser needs to become a SIP phone, 
any more than it needed a map rendering engine for Google Maps to exist 
or an IMAP client for Gmail to exist.

>
> And, as I mentioned, it could be external JS - but then it has be more 
> solid to start with.  For these simple uses - say chat with other 
> users on someones special-interest website, 2 and multiplayer gaming, 
> etc - we should try to pull together the minimum things any 
> app/service developer would need to be prepared for.  I think any 
> service that allows someone to log in from multiple devices has to 
> handle forking in some manner. Glare is always possible.  What else?  
> I'd like to see simple conferencing.  Perhaps the minimum is simple 
> enough that it makes more sense to develop a new, very simple 
> signalling JS module, and use it in examples. This would limit the 
> downside from not updating.

Or create a good *platform* for building RTC apps and let the developers 
build things you've never imagined. I think that's a far better outcome 
than building a SIP phone into the browser and then discovering that 
most people don't want to just make phone calls.

>
> The advantage of basing it on something known is that the basics of 
> all these protocols are well-understood.
>
> I'll paraphrase Harald (and many others in other contexts): make 
> simple things simple, make complex things possible.

The latter is far more important than the former. If making simple 
things simple makes complex things significantly harder or impossible, 
you're not building a platform for innovation.

Matthew Kaufman