[rtcweb] Another consideration about signaling

Iñaki Baz Castillo <ibc@aliax.net> Fri, 16 September 2011 15:39 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DCA4021F8CA6 for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 08:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_43=1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YN68Ep4FPbZQ for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 08:39:58 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 624EA21F8C90 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 08:39:58 -0700 (PDT)
Received: by qyk33 with SMTP id 33so4034569qyk.10 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 08:42:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id fl9mr2090988qab.328.1316187733117; Fri, 16 Sep 2011 08:42:13 -0700 (PDT)
Received: by with HTTP; Fri, 16 Sep 2011 08:42:13 -0700 (PDT)
Date: Fri, 16 Sep 2011 17:42:13 +0200
Message-ID: <CALiegfmoPWfhtBRiOfgLHG1uhJK_kK2t11xMoop-fT6qW4DUJQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: rtcweb@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [rtcweb] Another consideration about signaling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Sep 2011 15:39:59 -0000

Hi all,

Let's imagine that rtcweb defines a specific signaling protocol (i.e.
SIP) so browsers MUST use it natively for signaling the media streams.
Of course this would require a SIP proxy/server in server side (think
about NAT) which IMHO seems a showstopper (how to deploy such a SIP
proxy in shared web hostings? a "mod_sip" for Apache? should I make a
XMPP<->SIP protocol gateway in order to intercommunicate web-browsers
with pure XMPP clients?)

But there is another important drawback with this assumption:

A web site could be interested in drawing in the web the status of the
different audio/video streams between users connected to the web. This
could mean displaying in the web the active streams (audio/video),
when a session is on hold, when it's resumed again, when a new stream
is added to a multimedia session (i.e. offering video within an
already established audio session).

If the signaling uses a separate channel (i.e. SIP) then there is no
way for the web server to know what happens during multimedia sessions
(or it would be really difficult to achieve). So multimedia sessions
would be completely separated from the web page itself. Is that what
we want?

In the other side, if the signaling is implemented within HTTP or
WebSocket (by using any custom mechanism), it would be easy for the
web server to know the active sessions status in detail, and it could
use such a information for rendering it in the webpage (so others web
visitors can see the status of my calls, for example).

I just see advantages in *non* mandating a separate and specific
signaling protocol within rtcweb, even more taking into account that
this is supposed to be an added value for the web. This is: a
web-browser MUST NOT be a native SIP phone (IMHO). I wouldn't like to
see a competition between Firefox 12 and Chrome 17 in next SIPit
(Session Initiation Protocol Interoperability Test).

Best regards.

Iñaki Baz Castillo