Re: [rtcweb] Mode 1 and getUserMedia

[James Pearce <[e-mail]>]

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 <[e-mail]> wrote:

> 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
>
> On 13.09.2018 17:27, James Pearce wrote:
> > 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 <[e-mail]> 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>
> >> <
> 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:
> >>
> >> Mode 1 is not needed for TURN.
> >>
> >> On Wed, Sep 12, 2018 at 1:19 PM westhawk <[e-mail]> wrote:
> >>
> >>>
> >>>
> >>>> On 12 Sep 2018, at 20:57, James Pearce <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>
> >>
> >> _______________________________________________
> >> rtcweb mailing [e-mail]://
> www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>