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

[Randell Jesup <[e-mail]>]

On 10/5/2011 12:30 AM, Matthew Kaufman wrote:
> On 10/4/2011 9:06 PM, Randell Jesup wrote:
>> 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?

>> 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?

If you want me to answer that question: yes, I'd include support for 
some sort of resolution of forking.  Enough to avoid getting into 
trouble, only.

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

I am in *no way* saying it needs to be a SIP phone.  I'm saying "provide 
a simple-to-use basic signalling method which it totally optional to 
use, and which handles the basics needed of almost any signalling method 
(forking, glare, etc)".  Nothing about phones, nothing about PSTN.

We also don't ship browsers that consist of a canvas element and a JS 
interpreter, though you *could* build all websites that way (more or 
less), and some do (GMail and the like aren't far from it).  But most 
site authors are glad they don't have to start with a bucket of rocks to 
build a castle *as their only option*.

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

Again: I'm not suggesting "build in a SIP phone", and how does my 
proposal in any way tie the hands of someone who wants to build it 
themselves?

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

Ok, but in this case I don't want to complicate the later - so you're 
addressing a point I'm not making.  Please consider re-reading my 
posting with that in mind.


-- 
Randell Jesup
[e-mail]