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

[Iñaki Baz Castillo <[e-mail]>]

2011/9/20 Ravindran Parthasarathi <[e-mail]>:
> One of the main aim of the RTCWeb default signaling protocol is to make two
> party real-time communication easy with less development effort for any web
> developer.

Hi, let me some comments please:

1) "RTCWeb default signaling protocol" is not defined neither it
exists. I would ask you for not talking about it as if it was already
approved since that could become confusing for readers. Also, given
other threads it's clear that most of the people here is contrary to a
"RTCWeb default signaling protocol" or "SIP built-in the browser".
They have also given good rationale across multiple threads.

2) If browsers speak pure SIP then the server side MUST also speak
SIP. How to accomplish with that in shared web hostings? Must the web
admins learn about SIP and installing/configuring a
OpenSER/Kamailio/OpenSIPS/SER SIP proxy/registrar? This question has
been made several times in some threads. No reply yet (same occurs
with other given arguments).

3) Making the signaling path a separate flow means that the web server
(so the web application in server side) would not be aware about
sessions status. So if for example two users visit the same page and
speak through their web browsers and later one of them logouts from
the web, the server has no easy way to force the call termination.
Neither a "forum-administrator" could reject an spammer from an audio
conference room (or it would be hard to accomplish). In contrast, if
the signaling is carried via HTTP/WebSocket, the logic is centralized
and the server application would be aware of existing sessions.


Best regards.


-- 
Iñaki Baz Castillo
<[e-mail]>