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

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 14 October 2011 17:59 UTC

Return-Path: <HKaplan@acmepacket.com>
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 2F8E021F8CA5 for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 10:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 tQbRUuF+dGXR for <rtcweb@ietfa.amsl.com>; Fri, 14 Oct 2011 10:59:54 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6218E21F8C6F for <rtcweb@ietf.org>; Fri, 14 Oct 2011 10:59:54 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Oct 2011 13:59:53 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 13:59:53 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
Thread-Index: AQHMipsTQTQZSKEKrkKeWaPKwpQ4nw==
Date: Fri, 14 Oct 2011 17:59:53 +0000
Message-ID: <ABB0E87F-DEEF-4386-A718-D48E00F5961A@acmepacket.com>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com>
In-Reply-To: <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C1C48479777F1C47A82EDBEA4F699515@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <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 17:59:55 -0000

On Oct 14, 2011, at 11:43 AM, Iñaki Baz Castillo wrote:

> Hi, maybe I miss something, but this is WWW world and here there is no
> server-to-external-server interoperability, never.

That's odd - I could have sworn the emails I type into my gmail account reach servers outside of Google, using a standard protocol: SMTP.  Is gmail not in the "WWW world"?
;)

> 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"?

Ummm, but there *are* federated chats.  When I join the jabber room for IETF meetings, I don't have a personal account on the IETF's jabber site to do so.

I don't debate that chat is mostly done in closed communities (AIM, YIM, etc.), but SMS is a type of chat and widely popular in a federated model.  And it's usage grew tremendously once different providers federated, which I assume wasn't a coincidence of timing.


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

One problem with that of course is that the user interface would change dramatically every call, and depending on which direction the call was.  My guess is people generally get used to and like their particular UI - where the icons are, what they look like, menu options, settings, etc.

And I would expect some sites to offer JS which lets me do things like turn video off forever, or use a static picture/video of my choosing, which would somehow have to be communicated to the called domain's JS. (And that's just the tip of the proverbial iceberg)

-hadriel