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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CA1821F8B36 for <>; Mon, 19 Sep 2011 00:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.239
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IW3rT7dxkOtH for <>; Mon, 19 Sep 2011 00:48:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 68FE921F8B28 for <>; Mon, 19 Sep 2011 00:48:30 -0700 (PDT)
Received: from [] ( []) by (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" <>
In-Reply-To: <>
Date: Mon, 19 Sep 2011 09:50:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Harald Alvestrand <>
X-Mailer: Apple Mail (2.1244.3)
Cc: "" <>
Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.