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

Iñaki Baz Castillo <> Tue, 20 September 2011 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7FF621F84C3 for <>; Tue, 20 Sep 2011 01:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hrsHrVGmVY4d for <>; Tue, 20 Sep 2011 01:07:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 38C8D21F84ED for <>; Tue, 20 Sep 2011 01:07:00 -0700 (PDT)
Received: by qyk33 with SMTP id 33so274385qyk.10 for <>; Tue, 20 Sep 2011 01:09:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id db16mr354062vdb.497.1316506165175; Tue, 20 Sep 2011 01:09:25 -0700 (PDT)
Received: by with HTTP; Tue, 20 Sep 2011 01:09:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 20 Sep 2011 10:09:24 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: Ravindran Parthasarathi <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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:07:00 -0000

2011/9/20 Ravindran Parthasarathi <>om>:
> 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