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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 19 September 2011 09:30 UTC

Return-Path: <magnus.westerlund@ericsson.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 C725F21F8B39 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 02:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.508
X-Spam-Level:
X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 4TsZbzzvOdE2 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 02:30:28 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AF7A821F8B28 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 02:30:21 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-d0-4e770c3bb9aa
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.F2.20773.B3C077E4; Mon, 19 Sep 2011 11:32:43 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 11:32:43 +0200
Message-ID: <4E770C3B.3020402@ericsson.com>
Date: Mon, 19 Sep 2011 11:32:43 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E76E8E8.2050102@ericsson.com>
In-Reply-To: <4E76E8E8.2050102@ericsson.com>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
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 09:30:28 -0000

As Individual

On 2011-09-19 09:02, 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.
> 
> 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.
> 
> 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?

I think A only should be dealt with now.

The reason being that handling a local synthetic source is from this WGs
standardization almost without additional requirements. There is a bit
of extra API demands. There is the extra dimension of consent, where I
think this type needs user consent every time to pick the whole screen
or a particular application instance.

The only real question for us would be if the application output is fine
to encode using the video codecs that are proposed or if the media
encoding uses should be specialized for synthetic content?

As a question on the requirement I would also ask is sound output from a
particular application also should be included? From a requirement point
of view it doesn't seem difficult. Implementation may be far from easy.

Cheers

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
----------------------------------------------------------------------