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

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 3 Jun 2013 14:51:15 +0200

Hi,

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
protocol".

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
(website-B).

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

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

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
<[email-masked]>