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

["Asveren, Tolga" <[e-mail]>]

Making things simple/accessible to a wide range of programmers is a good
idea but then does this mean that a signaling protocol (even a simple
one) should be baked in the browser? For example, if I have a webserver
allowing people to play Battleships and want to add voice support for
players, why do I need to use SIP (or something as complex as it)? What
I am interested in would be limited to two-party simple voice
communication (no forking, no renegotiation, no early media, no reliable
responses etc....). A simple signaling protocol between JS and WebServer
should be good enough AFAICS. There could be some JS libraries built for
this purpose and one can use whichever one prefers (or develop its own).
Arguing about potential issues with a JS SIP library in the context of
simple use cases does not sound fair to me for this reason. The
requirement of simplicity for the no-signaling-protocol-in the-browser
approach would be: Keep the API exposing media related
information/attributes as simple as possible (but no simpler).

 

One could argue that the definition of "simple" includes things I
excluded above, e.g. forking. To me, simple means things similar to the
use case above but I doubt there is consensus on that.

 

Thanks,

Tolga

 

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Cameron Byrne
Sent: Wednesday, October 05, 2011 11:26 AM
To: Randell Jesup
Cc: [e-mail]
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
defining a signaling protocol for WebRTC (or not)]

 


On Oct 4, 2011 10:05 PM, "Randell Jesup" <[e-mail]> wrote:
>
> 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*.
>

I agree with Randal here. Let's make simple things simple, which does
not preclude making advanced and novel things possible.

Cb
>
>>> 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]
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb