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

Harald Alvestrand <harald@alvestrand.no> Mon, 19 September 2011 07:26 UTC

Return-Path: <harald@alvestrand.no>
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 06EBF21F8560 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 00:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.185
X-Spam-Level:
X-Spam-Status: No, score=-108.185 tagged_above=-999 required=5 tests=[AWL=2.414, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 wnCASRT3BeDn for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 00:26:38 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 22D5921F852E for <rtcweb@ietf.org>; Mon, 19 Sep 2011 00:26:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCF9339E0CD; Mon, 19 Sep 2011 09:28:59 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNvhpkvvdKDK; Mon, 19 Sep 2011 09:28:59 +0200 (CEST)
Received: from [192.168.1.51] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 425F139E051; Mon, 19 Sep 2011 09:28:59 +0200 (CEST)
Message-ID: <4E76EF3A.4010500@alvestrand.no>
Date: Mon, 19 Sep 2011 09:28:58 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4E76E8E8.2050102@ericsson.com>
In-Reply-To: <4E76E8E8.2050102@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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:26:39 -0000

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.
> 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).
> My interpretation is that A only allows for application sharing in
> conferencing contexts, like in the WEBEX session the Interim meeting was
> held with where we shared slides. Where the combination of A and B is
> providing for VNC/Remote desktop.
>
> Thus the question to the WG is the following.
>
> 1) Do you support or object the inclusion of use case A, B or Both in
> our Use case document?
>
> 2) Do you have additional comments for or against either of the use cases?
>
>
> As WG chair
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>