Re: [rtcweb] Mode 1 and getUserMedia

westhawk <thp@westhawk.co.uk> Wed, 12 September 2018 20:19 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 70D1B130D7A for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2018 13:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ulNKQLfWTvPy for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2018 13:19:10 -0700 (PDT)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 771CB130EB2 for <rtcweb@ietf.org>; Wed, 12 Sep 2018 13:19:09 -0700 (PDT)
Received: (qmail 51720 invoked from network); 12 Sep 2018 20:19:08 -0000
X-APM-Authkey: 255286/0(159927/0) 2311
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 12 Sep 2018 20:19:08 -0000
Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 03AFB18A1028; Wed, 12 Sep 2018 21:19:08 +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 45OAShj6JeM9; Wed, 12 Sep 2018 21:19:07 +0100 (BST)
Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 954A918A0244; Wed, 12 Sep 2018 21:19:07 +0100 (BST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: westhawk <thp@westhawk.co.uk>
In-Reply-To: <CAO5ixTEus6ioeXtfM2vFtjY19mHJq10-R9vC6AHN_EagXm68+g@mail.gmail.com>
Date: Wed, 12 Sep 2018 21:19:05 +0100
Cc: RTCWeb IETF <rtcweb@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BDA3B3E1-3A9F-47DF-B26B-DFA19CC7E57B@westhawk.co.uk>
References: <CAO5ixTHz9fhoau4Q7WJgpOp_aaDujH6pYT32MB2gX7D9-+E0fg@mail.gmail.com> <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> <CAO5ixTEus6ioeXtfM2vFtjY19mHJq10-R9vC6AHN_EagXm68+g@mail.gmail.com>
To: James Pearce <james@jamesandjo.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/x1LBaIs86SdkGIAgNC7Y3SeVSDA>
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 20:19:14 -0000


> On 12 Sep 2018, at 20:57, James Pearce <james@jamesandjo.com> wrote:
> 
> That's interesting - in the GitHub comments, you say that without Mode 1, you have to use TURN.
> It's my understanding that Mode 1 is also required for TURN - that's certainly what the spec seems to say. I know Firefox will not enumerate relay ice candidates until I've called getUserMedia().

No, Mode 3 explicitly supports TURN:

"
Default route only: This is the the same as Mode 2, except that the associated private address MUST NOT be provided. This may cause traffic to hairpin through a NAT, fall back to the application TURN server, or fail altogether, with resulting quality implications.
“

I suppose I should write some test code to verify what is actually happening...

I see Safari 12 looks like supporting MDNS names in ICE candidates.

It is definitely a mess. 

T.




> 
> James
> 
> On Wed, 12 Sep 2018 at 15:47, westhawk <thp@westhawk.co.uk> wrote:
> 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
> 
> 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
>