Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion

Iñaki Baz Castillo <> Thu, 20 October 2011 11:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 098F421F8AFF for <>; Thu, 20 Oct 2011 04:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.627
X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id USDczyI5Mokj for <>; Thu, 20 Oct 2011 04:45:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F082021F8AE6 for <>; Thu, 20 Oct 2011 04:45:29 -0700 (PDT)
Received: by vws5 with SMTP id 5so2309564vws.31 for <>; Thu, 20 Oct 2011 04:45:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id a11mr10377672vdg.1.1319111127139; Thu, 20 Oct 2011 04:45:27 -0700 (PDT)
Received: by with HTTP; Thu, 20 Oct 2011 04:45:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 20 Oct 2011 13:45:27 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Harald Alvestrand <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion
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 11:45:31 -0000

2011/10/20 Harald Alvestrand <>:
> While I may quibble with Inaki about the terminology he proposes, I think I
> support what he's driving at in the "components" Web page.
> In the -overview-02 draft section 7, the term "media negotiations" is used
> for what he calls "media signalling"; it is trying to get at the same
> distinction.
> In his category of "info signalling", I would quibble a bit in that I see
> "channel-related signalling" (a term I just invented, describing which media
> is sent on which SSRC on which port) as distinct from "identity-related
> signalling", where the whole question of "who am I talking to" is relevant.

Hi Harald, the terms I propose are just suggestions. I just wanted to
identify the different "signaling" components, how to name them is
just a matter of taste and I agree that your suggested names could be
just better. :)

As a suggestion, I think that the overview draft could include and
explain those terms so all the WG can refer to the standard names and
avoid confusion.

> I believe "channel-related signalling" needs to be treated together with
> "media signalling".

That's indeed the usual approach: the "channel-related signalling"
acts as a transport layer for the "media signalling". This is true in
SIP, XMPP and any other VoIP protocol.

The point here is:

If we assume that "channel-related signalling" carries "media
signalling" (as everybody agree I hope), what would entail mandating a
RTCweb default signaling protocol? It would mean that we
define/mandate both signalings (the format of the in-the-wire
messages), and that means that a website developer is not free anymore
to design his own message format and message exchange
mechanism/protocol. This is not just about the "media signaling" but
also about the "channel-related signalling".

We cannot mandate that because WWW already allows each developer to
decide his messages and protocol, and we don't know the requirements
of all the websites (and future websites) in the world, so we cannot
create and mandate a singaling protocol which fulfills every needs. We
cannot assume that every RTC communication involves a single "From"
and a single "To", we cannot assume that the hypothetical user_id
format (to identify the destination user) is valid for all the
websites, neither we can assume that every RTC communication has a
specific "user" destination.

IMHO RTCweb (and W3C) should be limited to define:

- A JavaScript API to manage media sessions (communication between
custom JS and the browser). If this involves state values then let's
call it a "protocol". ROAP accomplishes with this.

- Media related stuff (RTP, SRTP, codecs management, ICE, RTP

How the "channel-related signalling" and the "media signaling" is
carried in-the-wire should not be defined (IMHO) because it adds
dangerous constrains and it's against the spirit of the WWW world (in
which the lack of constrains is the key of its success).

We cannot go to Facebook and say "if you want to add RTCweb in your
website you must create user identifiers in this exact format,
authentication must be done in this way, you can add to the message
request just these fields...", that is a no-go.

As shown in other thread, currently Facebook JS sends the following
HTTP POST when a user sends a IM to other user in Facebook:

POST /ajax/chat/send.php?__a=1 HTTP/1.1'
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'
Content-Length: 399'
Cookie: datr=ZuyfTjurvmsqvYVBDcXF8u; c_user=104442654509775; L=2;
lu=RgQytVtJJBQSvWUNOYzs0oQg; sct=1319153603;
xs=60%3A1c179a6dfb7f08277477b20e778bd391; p=112;
Pragma: no-cache'
Cache-Control: no-cache'

Who will tell Facebook that it cannot use a similar message for RTCweb
audio/video request and instead Facebook must use a specific request
format with specific and limited fields? Not me :)

Best regards.

Iñaki Baz Castillo