Re: [rtcweb] Usecases for innovation.

Tim Panton <tim@phonefromhere.com> Wed, 09 November 2011 13:24 UTC

Return-Path: <tim@phonefromhere.com>
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 AA62C21F8B2A for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 05:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level:
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599]
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 sSQHN5AGFHT1 for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 05:24:16 -0800 (PST)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 71BCE21F8AFA for <rtcweb@ietf.org>; Wed, 9 Nov 2011 05:24:16 -0800 (PST)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 4C18F37A902; Wed, 9 Nov 2011 13:36:59 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <BLU152-W6072C34EB0609E293E49FC93DF0@phx.gbl>
Date: Wed, 09 Nov 2011 13:24:08 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <81E7739C-2C54-465B-B79F-9DC99BFDEAE0@phonefromhere.com>
References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com>, <6CB98137-B2A4-488C-BF5C-D7D87B23C7EC@cisco.com> <BLU152-W6072C34EB0609E293E49FC93DF0@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1084)
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: Wed, 09 Nov 2011 13:24:20 -0000

On 9 Nov 2011, at 01:05, Bernard Aboba wrote:

> [BA]  I'm trying to understand the "generic" issues presented by these cases.  
>  
> For #1, is the generic issue the ability to add support for codecs not supported natively (e.g. ability to add and use a codec added by a plugin, for example)?  
>  
> For #2, is the generic issue the ability to add support for new types of devices without standardized APIs, or is the issue being able to represent the input/output of a non-standard device in terms of a media stream? 

Well, in some sense kinect is just a lossy video encoder. So you could argue that they are the same problem.
Both cases point out the fact that tying codecs/networking/negotiation into one object and
only presenting a (somewhat opaque) blob of SDP to represent them limits what we can do 
at the javascript end. 
That may be a limitation we can live with, but at least we need to acknowledge that it is a limitation.

>  
>  
>  
>  
> Tim said:
>  
> " 1) H264 implementation in Javascript http://yfrog.com/nmng0z 
> 2) Kinect as an input device for a virtual receptionist in a real reception area
>  	(Voxeo's as it happens).
>  
> 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)."
>