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

["Ravindran Parthasarathi" <[e-mail]>]

Hi Inaki,

I have answered to you in the another thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html).  I understand that there are lot of thread, So you might have confused.  As I indicated in the earlier mail, I'll come up with the write up to discuss the need for "RTCWeb default signaling protocol". Please note in the mail thread that there is no mention of SIP as a RTCWeb default signaling protocol. The argument is between "nothing" vs "default" signaling protocol.

SIP or XMPP based protocol will be selected as a default protocol based on technical merit of a given RTCWeb signaling problem but it is a second stage.

Thanks
Partha

>-----Original Message-----
>From: Iñaki Baz Castillo [mailto:[e-mail]]
>Sent: Tuesday, September 20, 2011 1:39 PM
>To: Ravindran Parthasarathi
>Cc: Roman Shpount; Randell Jesup; [e-mail]
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
>defining a signaling protocol for WebRTC (or not)]
>
>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]>