Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Randell Jesup <> Fri, 14 October 2011 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96AE321F8C5F for <>; Fri, 14 Oct 2011 09:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HugGiFbl2nkV for <>; Fri, 14 Oct 2011 09:34:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DE66221F8CD2 for <>; Fri, 14 Oct 2011 09:34:00 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1REkhs-00061x-7D for; Fri, 14 Oct 2011 11:34:00 -0500
Message-ID: <>
Date: Fri, 14 Oct 2011 12:29:36 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Fri, 14 Oct 2011 16:34:01 -0000

On 10/14/2011 11:43 AM, Iñaki Baz Castillo wrote:
> 2011/10/14<>:
>> The interconnection trapezoid we inherited from SIP has become a sort of Gordian knot. If we could avoid RTCWEB server from having to speak to each other at all, we could avoid re-inventing SDP syntax and/or semantics, at least to some degree.
> Hi, maybe I miss something, but this is WWW world and here there is no
> server-to-external-server interoperability, never.
> The SIP trapezoid exists and works, but IMHO there will never be a
> "RTCweb trapezoid". Or do we expect that a user visiting
> should be able to establish a media session with other user visiting
> I don't think that will occur. There are not "federated
> chats" in the web, why should we specify "federated media sessions"?

Well, out of that 'jungle' as you refer to it the result is client apps 
that have to talk N protocols -- look at Pidgeon/libpurple, for example. 
  How many IM protocols have to be encoded within it?  Effectively it's 
N clients with a single UI front end - and it has to reverse-engineer 
each of those other-site protocols, generally, and track when they 
change.  Similar things go on with other "let me post something to N 
places" tools, etc.

Federation sounds like a major win over that.

> IMHO this is out of the scope of RTCweb, and in case of introducing it
> in the specifications, it would become an overkill (standarizing
> signaling between different WWW domains? that's not feasible in this
> world).

rtcweb is explicitly NOT standardizing the method of federation.  SIP is 
an option, but just an option.  If there is complexity, it will exist 
solely at the federation gateway.  (And if everyone has a way to convert 
to (say) SDP offer-answer, it may work fairly easily.)

> So I agree with your draft. Instead of "federating" (a concept that
> does not exist in WWW jungle) using OAuth or something similar is the
> key (so a visitor would establish a HTTP/WebSocket
> connection with servers in order to establish a media
> session with other user visiting Facebook).

For that to work, you have to assume that the apps on linkedin and 
facebook each use the same signalling/etc protocol over the websocket, 
OR they know the details of the protocol the other uses, OR they all 
have a single default "fallback" signalling method, which I thought you 
wanted to avoid.

Randell Jesup