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

[Randell Jesup <[e-mail]>]

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]