Re: [rtcweb] Mode 1 and getUserMedia

Mode 1 is not needed for TURN.

On Wed, Sep 12, 2018 at 1:19 PM westhawk <thp@westhawk.co.uk> wrote:

>
>
> > On 12 Sep 2018, at 20:57, James Pearce <james@jamesandjo.com> 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 <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
> >
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>