[rtcweb] Facebook is not SIP

[Iñaki Baz Castillo <[e-mail]>]

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
<[e-mail]>