Subject: [rtcweb] Mode 1 and getUserMedia

From: James Pearce <[email-masked]>
Date: Wed, 12 Sep 2018 14:35:51 +0100

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

---

From: westhawk <[email-masked]>
Date: Wed, 12 Sep 2018 15:47:13 +0100

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 <[email-masked]> 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: James Pearce <[email-masked]>
Date: Wed, 12 Sep 2018 20:57:44 +0100

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 <[email-masked]> wrote:

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

---

From: westhawk <[email-masked]>
Date: Wed, 12 Sep 2018 21:19:05 +0100

> On 12 Sep 2018, at 20:57, James Pearce <[email-masked]> 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.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Sep 2018 23:00:28 -0700

Mode 1 is not needed for TURN.

On Wed, Sep 12, 2018 at 1:19 PM westhawk <[email-masked]> wrote:

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Sep 2018 02:02:00 -0500

To be clear, if you're seeing Firefox behave in a way that doesn't 
comply with the ip-handling specification, please either file a bug at 
<https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC>, 
or send me an email that describes exact steps to reproduce the issue 
you're seeing and an explanation of what is happening versus what should 
be happening, and I'll forward it to the relevant parties.

/a

On 9/13/18 1:00 AM, Justin Uberti wrote:
> On Wed, Sep 12, 2018 at 1:19 PM westhawk <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     > On 12 Sep 2018, at 20:57, James Pearce <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > 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().
>
>     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.
>     “
>
>     > On Wed, 12 Sep 2018 at 15:47, westhawk <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> On 12 Sep 2018, at 14:35, James Pearce <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >>
>     >> Hi,
>     >>
>     >> 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.
>     >>
>     >> 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
>     >> 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
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: James Pearce <[email-masked]>
Date: Thu, 13 Sep 2018 16:27:43 +0100

With Firefox, I may be running into a different variant of the bug I
entered before:
*Bug 1384265 <https://bugzilla.mozilla.org/show_bug.cgi?id=1384265>*

If I add a TURN iceServer, and set iceTransportPolicy to relay, but never
call GUM, Chrome will connect, but Firefox won't.
However, the TURN server is on a VPN network. That bug above is about
Firefox not choosing the route to the origin when in mode 1. I guess that
would also mean it wouldn't use that supplied TURN server either.

James

On Thu, 13 Sep 2018 at 08:02, Adam Roach <[email-masked]> wrote:

> To be clear, if you're seeing Firefox behave in a way that doesn't comply
> with the ip-handling specification, please either file a bug at
> <https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC>
> you're seeing and an explanation of what is happening versus what should be
> happening, and I'll forward it to the relevant parties.
>
> /a
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Lennart Grahl <[email-masked]>
Date: Thu, 13 Sep 2018 18:47:08 +0200

That sounds like a result of mode 2. I assume Firefox collects the
address of the default route first and then talks to all the STUN/TURN
servers provided via that interface only. If the VPN's address is not
the default route and the TURN server is only available in the VPN, the
TURN server cannot be reached.

I'm actually not sure what's correct in that case. But if the TURN
server is reachable via multiple interfaces, the public IP from both of
your interfaces would leak. So, I guess Firefox is correct and Chrome
shouldn't reach the TURN server either?

By the way, 1000% agree that we need a proper way to access mode 1 for
other use cases.

Cheers
Lennart

---

From: James Pearce <[email-masked]>
Date: Fri, 14 Sep 2018 11:02:22 +0100

That's correct, but Firefox chooses the wrong default route. That's the
existing bug.
All browsers except Firefox use the route to the origin as the default
route (which is now in the spec).
So what I'm seeing is expected given that bug exists.

James

On Thu, 13 Sep 2018 at 17:47, Lennart Grahl <[email-masked]> wrote:

> comply
> >> <
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC>
> >> <
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC>,