[rtcweb] Why are we asking the wrong questions?

Roman Shpount <roman@telurix.com> Thu, 20 October 2011 15:16 UTC

Return-Path: <roman@telurix.com>
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 893D721F8ACE for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 08:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.857
X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ILZ+DOFfrDhO for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 08:16:23 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id B295321F8A91 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 08:16:22 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so3471234ggn.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 08:16:22 -0700 (PDT)
Received: by with SMTP id k7mr11365285pbv.30.1319123781744; Thu, 20 Oct 2011 08:16:21 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com []) by mx.google.com with ESMTPS id w4sm19890311pbf.6.2011. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 08:16:20 -0700 (PDT)
Received: by pzk34 with SMTP id 34so7562776pzk.9 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 08:16:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id q1mr20615884pbd.98.1319123779713; Thu, 20 Oct 2011 08:16:19 -0700 (PDT)
Received: by with HTTP; Thu, 20 Oct 2011 08:16:19 -0700 (PDT)
Date: Thu, 20 Oct 2011 11:16:19 -0400
Message-ID: <CAD5OKxvBMt_EDzPprGeFGGTPS0z3DXAz9YJPDqCwF6HKuPrpFg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="bcaec520ea434dfc5b04afbc709b"
Subject: [rtcweb] Why are we asking the wrong questions?
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: Thu, 20 Oct 2011 15:16:23 -0000

I am sorry for another rant, but it is painful to watch the discussion on
this list. We have a chance to create something great, but instead wasting
our time discussing irrelevant topics.

First irrelevant topic is "We want something that will allow to setup a
media call in 20 lines of JavaScript". If we are looking for something that
will to do this using the right JavaScript library and web server
components, then we will probably achieve this goal. If someone expects to
create something that by adding code at the browser level and no web server
cooperation will setup a call between two arbitrary browsers, then this is a
fool's quest. To setup a call browsers will need a meet point on the public
IP. On one hand we have hundred different ways to implement this using
current technology using a JavaScript library and one or the other server
component. On the other hand we have no standard protocol to implement a
meet point (some might argue for SIP or XMPP) but they do too much and do
not implement meet point functionality too well. If you want something
extremely simple just put a tel (or sip where supported) URL in your HTML.

Second irrelevant topic is PSTN vs some future web technology. We should
stop arguing about supporting or not supporting PSTN connectivity and
tailoring to the needs of some future start up. It is not about PSTN. It is
about supporting currently used call negotiation scenarios. RTC will need to
support all the scenarios actively used right now. Ideally, it should be
able to support future scenarios that we cannot support now due to
offer/answer limitations. Deliberately disabling support for current
applications is misguided not only from the point of view of
interoperability, but from the point of view of disabling future

As it was said numerous times on this list, there are quite a few examples
of RTC applications currently being used on the web. Their main limitation
is that they are using some sort of proprietary plugin to implement real
time media connections. The goal of this group is to create a set of
recommendations for standard implementation of this functionality. So the
right question would be what is the minimal feature set that needs to be
added to the browser which will allow web developers to create such
applications. Adding convenience APIs or optional functionality can be done
Roman Shpount