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

"Ravindran Parthasarathi" <> Tue, 20 September 2011 08:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73F6521F8511 for <>; Tue, 20 Sep 2011 01:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HEDDIaiZS4-i for <>; Tue, 20 Sep 2011 01:51:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA5E821F8510 for <>; Tue, 20 Sep 2011 01:51:58 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p8K8srJq006197; Tue, 20 Sep 2011 04:54:53 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 04:54:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 20 Sep 2011 14:24:21 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
Thread-Index: Acx3bJ/O1CWDXs32QnSt1wgAlRrTYwABSYuQ
References: <><><><><><><><><><><><><><><><><><> <CALiegfkCrusXTrJt9ez4CkYNBUR4s 8MDD75Ks>
From: Ravindran Parthasarathi <>
To: Iñaki Baz Castillo <>
X-OriginalArrivalTime: 20 Sep 2011 08:54:22.0488 (UTC) FILETIME=[E42AA980:01CC7772]
Cc: Randell Jesup <>,
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Sep 2011 08:51:59 -0000

Hi Inaki,

I have answered to you in the another thread (  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.


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