Re: [rtcweb] Usecases for innovation.

Iñaki Baz Castillo <ibc@aliax.net> Tue, 01 November 2011 14:18 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 30FEC21F9852 for <rtcweb@ietfa.amsl.com>; Tue, 1 Nov 2011 07:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.645
X-Spam-Level:
X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, 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 zmr1HhUK0I4J for <rtcweb@ietfa.amsl.com>; Tue, 1 Nov 2011 07:18:55 -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 5951821F984B for <rtcweb@ietf.org>; Tue, 1 Nov 2011 07:18:55 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so6893848vcb.31 for <rtcweb@ietf.org>; Tue, 01 Nov 2011 07:18:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.150.212 with SMTP id z20mr2782684vcv.58.1320157131983; Tue, 01 Nov 2011 07:18:51 -0700 (PDT)
Received: by 10.220.184.6 with HTTP; Tue, 1 Nov 2011 07:18:51 -0700 (PDT)
In-Reply-To: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com>
References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com>
Date: Tue, 1 Nov 2011 15:18:51 +0100
Message-ID: <CALiegfkrPeBRG=URtM7=xmVHgHrQkhf9bGBL1JUE2h9ofbj=OQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Tim Panton <tim@phonefromhere.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Usecases for innovation.
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: Tue, 01 Nov 2011 14:18:56 -0000

2011/11/1 Tim Panton <tim@phonefromhere.com>;:
> I've repeatedly been asked for use-cases for innovative applications of webRTC
> to justify my contention that we should be providing a low-level framework,
> not an embedded legacy compatibility application.

> By chance, this weekend I was exposed to 2 innovative uses of real-time-communications
> in a browser that _won't_ fit in the current looking-over-its-shoulder scheme.
>
> 1) H264 implementation in Javascript http://yfrog.com/nmng0z

Interesting but, how is that related to WebRTC? IMHO the RTP stack and
media manipulation (including codecs) must be built-in the browser
rather than doing it at JavaScript level.


> 2) Kinect as an input device for a virtual receptionist in a real reception area
>        (Voxeo's as it happens).

This is cool, but IMHO it requires:

1) A system driver for the Kinect device (in the same way a webcam
requires a system driver).

2) A browser specification for handling those kind of devices (indeed
not all the RTC is audio and video).

3) A mechanism for passing in-the-wire the data retrieved from the
device (corporal position and so).


- Bullet 1 is out of the scope of WebRTC, however there are open
source drivers for Kinect in most of the operating systems.

- IMHO bullet 2 should be in the scope of some other (new?) Working
Group, and we need it to be somehow standarized (I can't imagine a
specification for handling *just* Kinect in browsers, those kind of
devices should be "standarized" before carrying them to the browsers).

- Bullet 3 can already be achieved in multiple ways (using HTTP
polling, HTTP Commet, AJAX, WebSocket... and in theory also the WebRTC
Data specification).



> Neither of these are production ready - or indeed necessarily a good idea,
> but the fact that neither (minor) innovation fits at all into our brand new framework
> should give us pause for thought. (but given the pell-mell dash to be compatible
> with last century's deskphones I don't imagine it will).

Indeed most of the discussions in this WG are about how to make
***current*** SIP devices to work with a WebRTC scenario. It's a
limited vision of WebRTC in which the main interest is to make profit
of this new spec within telcos business. Bad IMHO. But, where are
those "innovative" and "crazy" Web folks right now? why 95% of people
discussing in this ***open*** WG are telcos? So this is also their
fault, the fault of people not participating here and now.

In the other side, let's take into account that 99% of Web folks know
absolutely nothing about RTC and/or VoIP. They live on top of HTTP and
port 80/443. WebRTC is about realtime communications, we need people
with RTC experience here. But indeed we need also the vision of Web
folks (in contrast to so much legacy telephony vision).

Anyhow I'm not so pesimist. I think that current WebRTC design is
flexible enough to make possible lot of features without being
constrained to follow a telco/telephony model at all.

Regards.



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