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

Iñaki Baz Castillo <ibc@aliax.net> Fri, 14 October 2011 15:43 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 D364821F8CA0 for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 08:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.127, 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 ICTaW62cRhBa for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 08:43:59 -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 2834B21F8C9F for <rtcweb@ietf.org>; Fri, 14 Oct 2011 08:43:59 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1324542vcb.31 for <rtcweb@ietf.org>; Fri, 14 Oct 2011 08:43:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.184.103 with SMTP id et7mr9493042vdc.35.1318607038558; Fri, 14 Oct 2011 08:43:58 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Fri, 14 Oct 2011 08:43:58 -0700 (PDT)
In-Reply-To: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM>
Date: Fri, 14 Oct 2011 17:43:58 +0200
Message-ID: <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: BeckW@telekom.de
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 15:43:59 -0000

2011/10/14  <BeckW@telekom.de>;:
> 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 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"?

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

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

Regards.



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