IETF Logo Mail Archive

Re: [rtcweb] Mode 1 and getUserMedia

westhawk <thp@westhawk.co.uk> Wed, 12 September 2018 14:47 UTC

Return-Path: <thp@westhawk.co.uk>
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 AF691130DD8 for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2018 07:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sxiJCpdaTEM for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2018 07:47:17 -0700 (PDT)
Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24C41292AD for <rtcweb@ietf.org>; Wed, 12 Sep 2018 07:47:16 -0700 (PDT)
Received: (qmail 22329 invoked from network); 12 Sep 2018 14:47:14 -0000
X-APM-Authkey: 255286/0(159927/0) 1629
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 12 Sep 2018 14:47:14 -0000
Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id AD0DB18A04F1; Wed, 12 Sep 2018 15:47:14 +0100 (BST)
Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4Fs4SUbmzNcW; Wed, 12 Sep 2018 15:47:14 +0100 (BST)
Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 812DA18A01FD; Wed, 12 Sep 2018 15:47:14 +0100 (BST)
From: westhawk <thp@westhawk.co.uk>
Message-Id: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_63683A57-EC0A-4AC2-A519-0D4F97D72A97"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 12 Sep 2018 15:47:13 +0100
In-Reply-To: <CAO5ixTHz9fhoau4Q7WJgpOp_aaDujH6pYT32MB2gX7D9-+E0fg@mail.gmail.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
To: James Pearce <james@jamesandjo.com>
References: <CAO5ixTHz9fhoau4Q7WJgpOp_aaDujH6pYT32MB2gX7D9-+E0fg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/ojWqtwOCvizeO8Mlyj-mJd14eIs>
Subject: Re: [rtcweb] Mode 1 and getUserMedia
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Sep 2018 14:47:20 -0000

Yeah, I call this the “You have to take a selfie before you fly the drone” problem.
I’ve just filed a GitHub issue on it for the use case spec for webRTC NV.

https://github.com/w3c/webrtc-nv-use-cases/issues/1 <https://github.com/w3c/webrtc-nv-use-cases/issues/1>

Feel free to add commentary there as well as here.

T.


> On 12 Sep 2018, at 14:35, James Pearce <james@jamesandjo.com> wrote:
> 
> 
> Hi, 
> 
> I have a quesion about the use of getUserMedia to obtain user consent for Mode 1 operation.
> 
> I have an application that uses WebRTC to deliver real-time media streams in one direction only. Client applications are consumers only, in some cases the client devices do not have any media capture capability.
> I'm trying to develop a strategy for deploying the application on the public web so, naturally, my plan is to use TURN to relay through NAT.
> 
> I've run into trouble with 
>   a) The requirement that Mode 1 is needed to use TURN
>   b) User consent for Mode 1 is tied to getUserMedia()
> 
> Firstly, it's not clear to me why there is a restriction on using TURN in mode 2. Does TURN reveal address information that would otherwise be hidden to the peer? I've noticed that Chrome seems to use TURN even without consent being given. Firefox does not.
> 
> Secondly, with no capture devices, getUserMedia can never succeed, thus, a user can never give consent for Mode 1. This is unfortunate, as WebRTC is ideal for some applications that require one-way streaming to limited-spec devices. Granted, not many devices today have no capture capability, but even when they do, requesting permission to access a microphone when it'll never be needed is confusing to end users. Is there a better mechanism we can use to obtain consent when getUserMedia is not necessary?
> 
> 
> I know I've raised this issue tangentially before, but having to explain issues to end users is beginning to wear thin. It's becoming a headache.
> 
> Thanks,
> 
> James
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email