Re: [rtcweb] Mode 1 and getUserMedia

[Adam Roach <[e-mail]>]

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