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

[Saúl Ibarra Corretgé <[e-mail]>]

Hi,

On Sep 26, 2011, at 9:52 PM, Ravindran Parthasarathi wrote:

> Hi Inaki,
> 
> <snip> 
> Ok, but such protocol should be carried within HTTP or WebSocket, rather than being a native SIP/XMPP/whatever-custom-protocol built-in the web browsers. Do we agree on this? I think the answer is "not", so please continue reading. </snip>
> 
> Your assumption is wrong here. When I ask for standard signaling protocol, websocket will be one of the alternative to considered for further discussion in case there is an agreement for having standard signaling protocol.
> 

I'd consider WebSocket the transport, not the signaling protocol per se. After reading your last emails I'm not exactly sure about what you are proposing. Let me state a starting point: two browsers can't communicate with each other without meeting somewhere, like a server for example. Both are behind NAT and there is no discovery mechanism, so the only way for them to communicate is to visit a website, for example.

Now, if two users (browsers) are already in the same website, they'd have downloaded the same JS libraries from the web server, as Inaki pointed out, so they may speak SIP, XMPP or whatever signaling protocol.

What I think you are suggesting is that RTCweb-enabled browsers include some sort of signaling library built-in, is this correct? Even if they do that you'll need server cooperation to reach each other, and even in the multiplayer game example, you are always connected to a server.

Thus, I strongly disagree to trying to include any signaling protocol as part of RTCweb. Developers may choose a JS library to do that, or even develop their own, and deploy it in the web servers that power their site.


Regards,

--
Saúl Ibarra Corretgé
AG Projects