Re: [rtcweb] Facebook is not SIP

"Avasarala, Ranjit" <> Thu, 20 October 2011 09:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCF5C21F8A6F for <>; Thu, 20 Oct 2011 02:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PyoQ0Jn5wpEG for <>; Thu, 20 Oct 2011 02:26:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 54F1821F8A71 for <>; Thu, 20 Oct 2011 02:26:58 -0700 (PDT)
Received: from ([fe80::c4c3:4566:8b3b:ec85]) by ([fe80::5efe:]) with mapi; Thu, 20 Oct 2011 17:26:56 +0800
From: "Avasarala, Ranjit" <>
To: Iñaki Baz Castillo <>, "" <>
Date: Thu, 20 Oct 2011 17:26:53 +0800
Thread-Topic: [rtcweb] Facebook is not SIP
Thread-Index: AcyPCepm0neKHZZRTnOAQUYgvMav0gAADbiA
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [rtcweb] Facebook is not SIP
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: Thu, 20 Oct 2011 09:26:59 -0000

True. That’s what I mean when I said we really do not need SIP for RTCWeb. But some lightweight signaling protocol could be useful in rtcweb. So as part of RTCWeb standardization, we could propose what a simple signaling protocol should provide and leave it to implementers t decide on the actual signaling protocol to use.


-----Original Message-----
From: [] On Behalf Of Iñaki Baz Castillo
Sent: Thursday, October 20, 2011 2:53 PM
Subject: [rtcweb] Facebook is not SIP

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

- 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
rtcweb mailing list