Re: [rtcweb] Mode 1 and getUserMedia

[James Pearce <[e-mail]>]

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