IETF Logo Mail Archive

Re: [rtcweb] Mode 1 and getUserMedia

James Pearce <james@jamesandjo.com> Wed, 12 September 2018 19:58 UTC

Return-Path: <james@jamesandjo.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 4AC8F130E16 for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2018 12:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-com.20150623.gappssmtp.com
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 vHx2MfEAEB2u for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2018 12:58:01 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07C6130D7A for <rtcweb@ietf.org>; Wed, 12 Sep 2018 12:58:01 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id j198-v6so12786179ita.0 for <rtcweb@ietf.org>; Wed, 12 Sep 2018 12:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2J9VRY9peHWrTCc16oPQ7MTrG0hmIQ5sX7Rp8HDWHHE=; b=mZOK8HVP61vLlKH0jpKoEiGiq7opuQNI5IbgJYXosh9gLCtlZ33V01tefaGKU5V1+s CSJ1j7mhL4doczr9sTKmp9f76/st1WY9TTmwbIHnth6IZhxvIB9QQwhEIzkeTh2xe00o vz5AAUZRyUdm0X8e+nQC+x5J9I6LNL4muczat6kYI7ZijbYify9yFZBbx+z9Np+LGRhi 9lRXOAIyT3Y1CUE4HH7JwjINPP9kQjukSrX9GEz1Y/WwsVml4lwH6wxrDV43qzVIexCD QbMrZ+feySsbcT6UVe3FoKBaYC+surDHEsneGSyiqOb4ySQR7kUpyVLUc4q9SfimvpD2 AGHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2J9VRY9peHWrTCc16oPQ7MTrG0hmIQ5sX7Rp8HDWHHE=; b=X0pOn/1dG0f+Jm9D/Vg1r8uDHYd/A1yqVIRTxUWFaVpkK7Y8sEGAuDEjiF5Yqub//v gwPmAfDmtzpVsO7cY6e/XuOlIf/WJUeTh8UiRMOUKgLMNZJNds5L+r/MkqCOhNE0QeYn ZuxEjPJYo8b2JKjDF+2SaEVbz1IuSuClwHngxXMcXgIyWr5z7z23reWpGAXAcqITk3Zc rOUVub5hH3AOa5K/zM80LqPDKsX2v2Of2LWSItS2L+dO7QZVCN5Sm8pxXj08HhGh0DhO uECh4ZJcqsQEA8JY0fDB7CL/yRJVaEyc+di+IFLEKsFmNmKKTHmIKr3MOP0Tkf3jYLF7 pL0g==
X-Gm-Message-State: APzg51DIa6PdVHjF33nWhRzmtcsVff4dvr5v6SBnWMo0F7d4IKP5ZHkZ qktEY0oS0OXBJUEg6M9EvmijTyChS6HPeZebzrdfnun7Hb4=
X-Google-Smtp-Source: ANB0VdatXR1jjpBj91NRBt6NKWdQHjRyU68EXVRUXkuMD8gsijs5bixoQzoltt5BlbJrNW1m0tBPOlRg/+PEC7NWoR0=
X-Received: by 2002:a02:5651:: with SMTP id o78-v6mr3626037jab.8.1536782280938; Wed, 12 Sep 2018 12:58:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAO5ixTHz9fhoau4Q7WJgpOp_aaDujH6pYT32MB2gX7D9-+E0fg@mail.gmail.com> <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk>
In-Reply-To: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk>
From: James Pearce <james@jamesandjo.com>
Date: Wed, 12 Sep 2018 20:57:44 +0100
Message-ID: <CAO5ixTEus6ioeXtfM2vFtjY19mHJq10-R9vC6AHN_EagXm68+g@mail.gmail.com>
To: thp@westhawk.co.uk
Cc: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f3ee570575b20176"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/AF313eQwVEdeNYnlJIXTsxjWtB0>
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 19:58:05 -0000

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().

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

v2.23.0 | Report a Bug | By Email