Subject: [rtcweb] Facebook is not SIP

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 11:23:10 +0200

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
discussions.

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:
     "media":
     {
        "messageType":"OFFER",
        "offererSessionId":"13456789ABCDEF",
        "seq": 1
        "sdp":"
           v=0\n
           o=- 2890844526 2890842807 IN IP4 192.0.2.1\n
           s= \n
           c=IN IP4 192.0.2.1\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
format"?).

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
<[email-masked]>

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Thu, 20 Oct 2011 17:26:53 +0800

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.

Regards
Ranjit

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

Hi all,

  {

-- 
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2011 11:30:16 +0200

On 10/20/11 11:23, Iñaki Baz Castillo wrote:
> protocol Facebook designed.
They're using XMPP: https://developers.facebook.com/docs/chat/

Unfortunately Facebook has chosen (so far) to not participate in federation.

Rest of message deleted, since it's based on a false premise.

              Harald

---

From: Neil Stratford <[email-masked]>
Date: Thu, 20 Oct 2011 10:36:15 +0100

On Thu, Oct 20, 2011 at 10:30 AM, Harald Alvestrand <[email-masked]>wrote:

> They're using XMPP: https://developers.facebook.**com/docs/chat/<https://developers.facebook.com/docs/chat/>
>

I believe that is just for interop with external applications and not used
by their own web applications, though I may be wrong.

http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdfis
an interesting read.

Neil

---

From: Tim Panton <[email-masked]>
Date: Thu, 20 Oct 2011 10:39:37 +0100

> They're using XMPP: https://developers.facebook.com/docs/chat/

Yes, they are using XMPP - but are they using it to the browser or only for interop? The 
document does not say, and I haven't wiresharked the traffic to see,
at the very least I imagine they are running it over http / websockets.

> Unfortunately Facebook has chosen (so far) to not participate in federation.

Which is a shame, but it does bring up an interesting point, if we were to _force_
federation (of RTC) on a website by standardising it into rtcweb, then
that might cause sites like facebook to reject the standard.

> Rest of message deleted, since it's based on a false premise.

It isn't clear to me that it is a totally false premise and anyway the link above illustrates some
of the issues in using a non- web protocol on a web site. 
Specifically , FB use their own Auth presumably to provide a single-sign-on experience.

Tim

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 20 Oct 2011 11:37:11 +0200

Il giorno Thu, 20 Oct 2011 11:30:16 +0200

> Rest of message deleted, since it's based on a false premise.

I think what Iñaki meant is that the protocol between the browser (in
JavaScript) and the Facebook server is custom: the fact that it is then
gatewayed to XMPP is a different matter, just as the decision not to
federate.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 11:46:41 +0200

> They're using XMPP: https://developers.facebook.com/docs/chat/

It changes nothing. If RTCweb decides a standard in-the-wire signaling
protocol different than XMPP we are also forcing facebook to use a
protocol different than XMPP for audio/video signaling (in-the-wire).

Anyhow, this is what I capture from the network when I send a IM
message ("hello") to other user visiting Facebook website:

---------------------
POST /ajax/chat/send.php?__a=1 HTTP/1.1'
Host: www.facebook.com'
User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:10.0a1)
Gecko/20111017 Firefox/10.0a1'
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'
Accept-Language: en-us,en;q=0.5'
Accept-Encoding: gzip, deflate'
DNT: 1'
Connection: keep-alive'
X-SVN-Rev: 460802'
Content-Type: application/x-www-form-urlencoded; charset=UTF-8'
Referer: http://www.facebook.com/?sfrm=1'
Content-Length: 399'
Cookie: datr=ZuyfTjurvmsqvYVBDcXF8u; c_user=104442654509775; L=2;
lu=RgQytVtJJBQSvWUNOYzs0oQg; sct=1319153603;
xs=60%3A1c179a6dfb7f08277477b20e778bd391; p=112;
presence=EM319103631L212REp_5f1B04654409875F4EriF0CEstateFDutF1319103633096EvisF1H0EblcF0EsndF1ODiFA21B02602687525A2C_5dEfFA21B02602687525A2EuctF1319103618EsF0CEblFD55F1G319103604PEuoFD1B02602687525FDexpF1319103680370EflF_5b1_5dEolF0CCEalFD1B02602687525FDiF0EmF0CCCC;
wd=1366x675'
Pragma: no-cache'
Cache-Control: no-cache'
'
msg_id=1319103647568%3A3620978310&client_time=1319103646048&to=100002772687525&num_tabs=1&pvs_time&msg_text=hello&to_offline=false&to_idle=false&window_id=2877189837&sidebar_launched=true&sidebar_enabled=true&sidebar_capable=true&sidebar_should_show=false&sidebar_visible=false&post_form_id=449eb730c851e127f21d8a88b6a00667&fb_dtsg=AQC3StlW&lsd&post_form_id_source=AsyncRequest&__user=100002654409995
---------------------

Could you explain me where do you see "XMPP" there? Please note that
I'm speaking about the in-the-wire signaling between the webbrowser
and the server, and the above HTTP POST is the signaling message
Facebook is using for sending a IM.

> Unfortunately Facebook has chosen (so far) to not participate in federation.

Federation does not matter here. I'm just speaking about the
in-the-wire signaling protocol between web users visiting Facebook
website. Federation is another topic IMHO.

> Rest of message deleted, since it's based on a false premise.

Which premise?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2011 11:52:35 +0200

> at the very least I imagine they are running it over http / websockets.
I stand corrected; they are running their own protocol between the 
browser and their servers.
As does Google, for that matter, even though our backends are XMPP-based.

Sorry for going off half-baked.

           Harald