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, 01 Nov 2011 15:18:51 +0100
Message-ID: <CALiegfkrPeBRG=URtM7=xmVHgHrQkhf9bGBL1JUE2h9ofbj=OQ@mail.gmail.com>
From: Iñaki 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>
- [rtcweb] Usecases for innovation. Tim Panton
- Re: [rtcweb] Usecases for innovation. Iñaki Baz Castillo
- Re: [rtcweb] Usecases for innovation. Wolfgang Beck
- Re: [rtcweb] Usecases for innovation. Igor Faynberg
- Re: [rtcweb] Usecases for innovation. Iñaki Baz Castillo
- Re: [rtcweb] Usecases for innovation. Randell Jesup
- Re: [rtcweb] Usecases for innovation. Ravindran Parthasarathi
- Re: [rtcweb] Usecases for innovation. Wolfgang Beck
- Re: [rtcweb] Usecases for innovation. Randell Jesup
- Re: [rtcweb] Usecases for innovation. Cullen Jennings
- Re: [rtcweb] Usecases for innovation. Bernard Aboba
- Re: [rtcweb] Usecases for innovation. Tim Panton
- Re: [rtcweb] Usecases for innovation. Bernard Aboba