[rtcweb] My considerations about "inter-website-communication", RTT and emergency services

Iñaki Baz Castillo <ibc@aliax.net> Mon, 03 June 2013 12:51 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 421C721F9698 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 05:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0IBrehDgx+Xb for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 05:51:37 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0221F947C for <rtcweb@ietf.org>; Mon, 3 Jun 2013 05:51:36 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id bs12so1783278qab.15 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 05:51:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=rt3wmyPEMh9Kzkpb1K+BN+6UCyci+wam5mqfRaZhVNA=; b=I90PuDwxRIKTdauHG7CpI3Bv/6m2qXcu2jkT6HrmveD8yz57LVJ1bj2lxC0P0uNRUo o08n/KXt9Iosne9KZMJleH83ReYZyVJUNtPGNXPOjhVmXUTYYvaM3JQryCmc9CYOnZZr +l+D8PRTZ3871oqFghh4UcHYcHkw9Cz4BveY6Wr++AF2CrvoP+++Wuuz+x5dCd2q1huM 1ICtenBno1igGAQ0vSP/nbEibiqaoy0JHLol79SffPxJSawotlLV5XhDvExTSC2p9kAz cN9ygF0aL8cGMHCQchnCsNHy6bIJ8YNf1qwJXWAIhEKRK6v+O2NUt1z8qB6k1g0lviga 5UQg==
X-Received: by with SMTP id t16mr4204129qcr.93.1370263896039; Mon, 03 Jun 2013 05:51:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 3 Jun 2013 05:51:15 -0700 (PDT)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Mon, 3 Jun 2013 14:51:15 +0200
Message-ID: <CALiegfn4u1NQ6y=U92pAg9x5-tXPkSH=wwKiBTyQor2zH1S_1w@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkqYe/HAOlJTo0fVt6boy1SgnYU/HJ+GfkqIJjE8EbG1WDidmQdpDHMgLI2C2BAf4a6ajzu
Subject: [rtcweb] My considerations about "inter-website-communication", RTT and emergency services
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: Mon, 03 Jun 2013 12:51:38 -0000


Currently interaction between users of different websites is achieved
via widgets and/or oAuth. JS codes provided by different websites
typically don't directly interact.

Alice can give a comment into a Wordpress blog by signing with her
Facebook account, but the JS code she uses for leaving such a comment
is provided by the blog. There is not an "inter-blogging standard

WebRTC is like Youtube, but instead of user-to-server it provides
user-to-user RT communication. A user logged into Youtube cannot
directly access to a video published in Vimeo, right? A webpage can
include a Youtube video, but for that it must include a JS/HTML code
provided by Youtube site.

The same for WebRTC. Let's assume that website-B will provide some JS
widget that can be embedded in any webpage (i.e. a "call me" button)
so the web visitor in website-A can click on it and establish a WebRTC
audio/video session with somebody (Bob) in website-B. The important
consideration here is that the JS app is provided by the website of
the called party, and the RT session established between Alice and Bob
makes use of JS code and server(s) provided by a single website/domain

So when I constantly read about "inter-operator RT communication" I
wonder, do we really know how the WWW works and what the WWW wants and

If we talk about RealTime-Text, there are tons of ways it can be
achieved with existing browser technologies (including the new
DataChannel). Assuming the WWW-"federation"-style explained above, RTT
between different websites can be already implemented, and the same
for usual-chat. But it's not implemented in that way (two users logged
into different websites can not chat one to each other because
websites don't want to offer such a feature). This is, it can already
be done, but it's not done. Adding a new standard specification (just
covering the realtime text part) will change nothing. It's up to
websites to allow it.

And since "emergency services" seem to be the last argument for all, I
wonder whether we expect that a web visitor in a RealTime audio/video
poker game should be able to make an audio call to 112 emergency
number from the poker website. If the answer is not (and it should be
"not") I expect that the "emergency services" argument is avoided from
now because it is a show-stopper which hast zero relationship with the

Emergency services will be able to provide their own website or JS
widget that other websites could embed into their webs. Those
emergency websites will deploy the servers and the logic they require
to interact, at audio/video/text/fax/sms/whatever levels, with the RT
signaling protocols they use in the "leg B" of the session with their
existing legacy communication systems.

My two cents.

Iñaki Baz Castillo