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

Iñaki Baz Castillo <ibc@aliax.net> Fri, 14 October 2011 18:33 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003AF21F8BB6 for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 11:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level:
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBGpTesniVMe for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 11:33:48 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3303E21F8B9D for <rtcweb@ietf.org>; Fri, 14 Oct 2011 11:33:48 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1499996vcb.31 for <rtcweb@ietf.org>; Fri, 14 Oct 2011 11:33:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.184.103 with SMTP id et7mr10275347vdc.35.1318617227637; Fri, 14 Oct 2011 11:33:47 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 11:33:47 -0700 (PDT)
In-Reply-To: <4E986370.4030601@jesup.org>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com> <4E986370.4030601@jesup.org>
Date: Fri, 14 Oct 2011 20:33:47 +0200
Message-ID: <CALiegfnQwXFzgEG-zPT1DicQU5L80wpetyeVqbr7ykTO9Xxryg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2011 18:33:49 -0000

2011/10/14 Randell Jesup <randell-ietf@jesup.org>;:
>> The SIP trapezoid exists and works, but IMHO there will never be a
>> "RTCweb trapezoid". Or do we expect that a user visiting facebook.com
>> should be able to establish a media session with other user visiting
>> linkedin.com? 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.

WWW is different. The "software" is provided by each web site. This is
at least how WW works today.



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

Then, if rtcweb is explicitly NOT standardizing the method of
federation, what is this discussion about? :)


>> 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 linkedin.com visitor would establish a HTTP/WebSocket
>> connection with Facebook.com 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,

No, I meant that web sites A.com and B.com allow to each other
displaying the visitors in each page, so a visitor in A.com can see in
the web the visitors connected to B.com. But if a visitor in A.com
wants to talk with a visitor in B.com, A.com retrieves the JS
signaling from *B.com* (B.com allows that due to some kind of
authorization, i.e. OAuth) and both visitors in A.com and B.com speak
the signaling protocol of B.com.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>;