Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing

"Olle E. Johansson" <oej@edvina.net> Mon, 19 September 2011 07:48 UTC

Return-Path: <oej@edvina.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 0CA1821F8B36 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 00:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level:
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 IW3rT7dxkOtH for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 00:48:30 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 68FE921F8B28 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 00:48:30 -0700 (PDT)
Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id A61D0754BCE4; Mon, 19 Sep 2011 07:50:50 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <4E76EF3A.4010500@alvestrand.no>
Date: Mon, 19 Sep 2011 09:50:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC2D9F2C-5C1C-4076-A855-228B6B2A9D6A@edvina.net>
References: <4E76E8E8.2050102@ericsson.com> <4E76EF3A.4010500@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1244.3)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing
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: Mon, 19 Sep 2011 07:48:31 -0000

19 sep 2011 kl. 09:28 skrev Harald Alvestrand:

> On 09/19/2011 09:02 AM, Magnus Westerlund wrote:
>> WG,
>> 
>> There where some discussion in the Interim meeting last week about a
>> Screen/Application/Desktop sharing support use case. My take away from
>> the discussion is that this use cases is likely well enough understood
>> to actually start a consensus call now. However, to us WG chairs it was
>> clear that the use case in question actually needs to be split into two
>> parts.
>> 
>> A) Where the RTCWEB enabled browser can use a local application window,
>> the whole desktop or a Screen as a media source that can be encoded and
>> transported over the peerConnection for displaying/playback at the peer.
> I think this is a fairly well defined applicaiton (basically, take input from a synthetic source, where the synthetic source may be anything available to the browser), the baseline (but not the optimum) could simply be encoding the stuff using a default codec, and the access procedures shouldn't be much different than for microphone and camera. I support its inclusion in the document.
> 
> Note: The implementation of such a feature is far from trivial. I would not want to require that all browsers implementing RTCWeb support the feature.
I can agree with that, but I want to explore how this use case would affect RTCweb architecture.

>> B) Where a remote peer can provide one or more input types such as mouse
>> and keyboard to control the local system, not only including the
>> browser, but also other operating system resources. This clearly can
>> only happen after additional consent, most likely on a per occasion
>> consent.
> I see this as a  more tricky thing to get right (in most apps, the mixing of events from multiple sources depends strongly on both proper timing/sequencing and reliable delivery). I would like to not address this for now (RTCWeb version 1).
I think it's a good use case for the data channel. How many such use cases do we have? While use case A is quite often handled as a normal video stream, use case B is likely something like VNC. This is an application that is part of Microsoft Lync as well as the free SIP client Blink today.

/O