Re: [rtcweb] Usecases for innovation.

[Iñaki Baz Castillo <[e-mail]>]

2011/11/1 Tim Panton <[e-mail]>:
> 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
<[e-mail]>