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

[Roman Shpount <[e-mail]>]

Randell,

What I fail to understand is in what way would adding signaling to the web
browser would  make things easy to build? How is what you are proposing
better then 2 or 3 well written samples?

On the other hand, if you decide to build such simple signaling interface,
depending on what use case you are trying to address you will end up with
very different libraries. You have to decide how complex you want to make
this library on the server vs the client side. You will need to decide if
the purpose of this library is to simplify browser-to-browser or
browser-to-PSTN calls. There is going to be a large number of very complex
decisions none of which have obvious answers and will greatly affect the
overall library design.

Most importantly, I think this is a misconception that you can build
something that can be developed in 20 lines or less and be useful. Real-time
communication is order of magnitude more complex then most of the web
related applications. You need to deal with multiple event sources, deal
with event collisions, negotiation failures, call state machines. And this
is what required for the basic call setups. Once you start dealing with
transfers, conferences, call status monitoring, things become even more
complex. It is almost impossible to develop something that is simple to use
that serves more then one or two specific use cases. If we try to invent
something like this we might never finish.
_____________
Roman Shpount


On Mon, Sep 19, 2011 at 6:36 PM, Randell Jesup <[e-mail]>wrote:

> On 9/19/2011 4:33 PM, Saúl Ibarra Corretgé wrote:
>
>> You misunderstood me; I meant "if you use an optional SIP module, you'll
>>> need to have a SIP proxy on your server".  WebRTC in general presumes
>>> some sort
>>> of server architecture to solve the discovery/invitation problem.  There
>>> *are*
>>> some possible uses of WebRTC that might not use a central server(s).
>>> The simplest
>>> would be the "phone-tag" server, where you and the person you want to
>>> talk to
>>> exchange IP addresses and external port numbers over the phone, and type
>>> them into
>>> the web app, which then opens a default-configured PeerConnection and
>>> re-negotiates
>>> to the actual configuration.
>>>
>>>  Still, you need this "phone-tag" server, so who will provide it? I don't
>> see a way for 2 parties to communicate without help from outside the
>> browser, thus, I wouldn't define any sort of protocol, even if we could
>> simplify one.
>>
>
> The purpose of including a protocol (which is optional to use) isn't to
> allow
> direct browser-to-browser discovery or initiation without a server.  In
> fact,
> it doesn't help *or* hurt that use-case.  A primary reason for including a
> protocol
> is to make it easy to build things.  We don't *just* want organizations
> with the
> resources of Google or Skype or Cisco (or Mozilla) to be the ones who can
> make
> use of this new capability; we want all web developers to feel it's within
> their
> grasp.  This could be satisfied in a few ways, as discussed: "baked in"
> simple
> SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine
> baked
> in; or a pure JS implementation.  But we are wary of putting it out with
> merely
> the hope that a good-enough JS lib will show up someday (and there are
> other pros
> and cons; no need to repeat them here).
>
> As far as needing external servers: there are some ideas we're floating
> around
> that would allow for server-less or virtually server-less operation of
> WebRTC
> clients including discovery and initiation, from behind NATs.  We haven't
> speced it out or even proven it's workable yet, but we're going to look
> very
> closely at some type of proof-by-existence for this idea.
>
>
>
> --
> Randell Jesup
> [e-mail]
>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>