[rtcweb] Facebook is not SIP

Iñaki Baz Castillo <ibc@aliax.net> Thu, 20 October 2011 09:23 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 5120D21F8678 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 02:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.035
X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, 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 1ukZ3ZYFcgPI for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 02:23:13 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 819BC21F87FA for <rtcweb@ietf.org>; Thu, 20 Oct 2011 02:23:12 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so2726791vcb.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 02:23:12 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id p17mr719540vcq.41.1319102591054; Thu, 20 Oct 2011 02:23:11 -0700 (PDT)
Received: by with HTTP; Thu, 20 Oct 2011 02:23:10 -0700 (PDT)
Date: Thu, 20 Oct 2011 11:23:10 +0200
Message-ID: <CALiegfmWebR6pJCpCYhH3YWNTqnfENXU_uiu1Db5joM-RSrVAQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: [rtcweb] Facebook is not SIP
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: Thu, 20 Oct 2011 09:23:14 -0000

Hi all,

When two Facebook users chat via web, they are already using a
signaling protocol in-the-wire, which one? The *custom* signaling
protocol Facebook designed. So when Alice sends a IM via web to Bob
(both visiting Facebook website) the JS in Alice's browser sends to
the server some kind of HTTP request containing (I specule):

1) The Facebook *id* of the destination user (Bob).
2) Probably some other custom fields.
3) The text message itself (or picture, or video).

If Facebook implements RTCweb for *adding* audio/video sessions
between its web users, Facebook will be interested in keeping its
current message formats, so when making an audio call I expect that
the JS in Alice's browser would send to the server some HTTP request
as follows:

1) The Facebook *id* of the destination user (Bob).
2) Probably some other custom fields.
3) The "media description".

If ROAP defines a JSON structure holding a media descrition (SDP or
like-SDP), such JSON structure could fullfil the point 3 of the
in-the-wire signaling request. But that's all, still we need to also
indicate other fields to *complete* the signaling (points 1 and 2).
Who am I? who is this request destinated to? This is NOT about media
negotiation so ROAP does not help here (it's not its aim).

If you read   http://public.aliax.net/RTCweb_Signaling_Components.html:

- points 1 and 2 become the JS-Server Info Signaling.
- point 3 becomes the JS-Server Media Signaling.

Do all the people here *understand* that sending a SDP (or a ROAP O/A)
in-the-wire is not a *complete* signaling solution? More data is
required (JS-Server Info Signaling) so the server can perform
authorization and route the request to the indicated destination (ROAP
knowns nothing about users in a website, it's just about media
description and media state !!). Please, understand it. I've seen lot
of mails suggesting "just ROAP" as the in-the-wire signaling protocol.
Please compile what you say before proposing it and let's have useful

In the other side, WWW exists much before than RTCweb (obvious) and
WWW has succeeded because each website admin/developer can do whatever
he wants. So we (RTCweb WG) cannot arrive in 2011/2012 and mandate all
the websites to implement a SIP infraestructure if they want to
provide RTC. Neither we can mandate any other *specific* signaling
protocol in-the-wire (regardless it is carried over WebSocket, HTTP,
or whatever).

Continuing with Facebook: Let's imagine that this WG estandarizes a
specific RTC Signaling Protocol in the wire (not please!!!), let's
imagine some custom JSON format. A request could look as follows:

    # JS-Server Info Signaling:
    "from": "alice",
    "to": "bob",
    "request-type": "call",

     # JS-Server Media Signaling:
        "seq": 1
           o=- 2890844526 2890842807 IN IP4\n
           s= \n
           c=IN IP4\n
           t=2873397496 2873404696\n
           m=audio 49170 RTP/AVP 0"

The media signaling part could be achieved sending the JSON object
managed by ROAP (ROAP is just the API/protocol between JavaScript and
the browser RTCweb stack !!) as the example shows.

Now please look at top of the request (where the info signaling is):

    # JS-Server Info Signaling:
    "from": "alice",
    "to": "bob",
    "request-type": "call",

Such format assumes that there can be a single From and a single To
values. This is true in SIP, but I don't know if it's valid in other
protocols (in Skype I can receive an incoming call indicating two
users in the From field if those two were already joining a
conference). And we cannot expect that this format is valid for all
the websites (who knows what will Facebook need within next 5 years?
Who are we to mandate "no, you must limit yourself to this request

Also, Facebook uses a big integer for user identificator, SIP uses a
SIP AoR, XMPP uses whatever, any protocol uses its own user
identification. Who are we to mandate a single one?

In conclusion: If RTCweb standarizes a signaling protocol in-the-wire,
RTCweb is mandating Facebook to use such message format for RTC
sessions. Since Facebook uses a completely different request format
*today* in its integrated chat, do you really think Facebook will
accept this imposition?

Please, WWW already exists, don't try to mandate how it must works, it
*already* works without our impositions. So please, don't waste time
considering having/defining/mandating a RTCweb default signaling
protocol *in-the-wire* because we cannot mandate that in WWW world.
Let's move on.

The mission of RTCweb is to provide RTC communication to WWW world.
An "extra" feature is to make it possible to interoperate with VoIP
networks out there (specially those using SRTP/ICE for media). But
this is a desirable feature, not the main point, so RTCweb MUST NOT
mandate a specific signaling protocol in-the-wire just for the benefit
of those who want to build protocol gateways. This MUST NOT be a telco
business, this is Internet and WWW.

Sorry for this long mail. Best regards.

Iñaki Baz Castillo