Re: [rtcweb] rtcweb-transports reference to TRAM discovery

[Justin Uberti <[e-mail]>]

The actual requirement (as indicated in S 3.3.5.1 of
https://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-15#page-8)
is for an enterprise to be able to force the use of a enterprise-controlled
TURN server. Here, enterprise policy surely can allow for all traffic to be
forced through said TURN server, just as it can be done for HTTP/HTTPS
proxies today.

I agree that the ISP TURN server case is different, and merits additional
discussion. So while we can argue about exactly how autodiscovery should
work (e.g. .pac or
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00), we
should be able to agree on how things should work once a local TURN server
is found (i.e. https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04
).

This would allow the above scenario to be satisfied when the TURN proxy
configuration is set through enterprise policy, and would be a substantial
improvement over the current state of affairs (e.g. where many enterprises
force all WebRTC traffic to TCP or through a HTTPS proxy)


On Wed, Dec 24, 2014 at 1:54 PM, Mark Nottingham <[e-mail]> wrote:

> I’d say that there’s some level of implementer interest in standardising /
> documenting proxy.pac, but — so far — inadequate resources; I don’t see
> *any* interest in WPAD standardization, as it’s viewed as actively bad.
>
> Regards,
>
>
> > On 17 Dec 2014, at 4:58 pm, 🔓Dan Wing <[e-mail]> wrote:
> >
> > On Dec 17, 2014, at 9:06 AM, Harald Alvestrand <[e-mail]>
> wrote:
> >
> >> On 12/17/2014 05:19 PM, Hutton, Andrew wrote:
> >>> OP: 15 December 2014 22:44 Justin Uberti Wrote:
> >>>> I think making it a requirement is probably premature until we have a
> >>>> WG document that explains what should happen when you discover one of
> >>>> these network-provided TURN servers.
> >>>> Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is
> >>>> accepted as a WG doc, we can add a requirement for support for RETURN
> >>>> and server discovery.
> >>>>
> >>>> Unclear whether it needs to be MUST-strength until we get some
> >>>> implementation feedback though.
> >>>>
> >>> -transports already states " WebRTC browsers MUST support
> configuration of STUN and TURN servers, both from browser configuration and
> from an application".
> >>>
> >>> So it looks like we already have a requirement but no explanation of
> what should happen when both are available.
> >>
> >> The last times we've talked about this, people have imagined
> configuring this via the same mechanism as configuring HTTP proxies
> (nonstandard script at a nonstandard URL).
> >>
> >> Autodiscovery may be preferable, but it's not clear that it removes the
> need for the script-like things.
> >
> > If there is, gathering that requirement seems important.  Mark
> Nottingham was beginning an effort around WPAD standardization (or
> something that resembled it).  CC'ing him in case there is useful status on
> that front.
> >
> > -d
> >
> >
> >>
> >>>
> >>> Looks like we need to adopt draft-schwartz-rtcweb-return and explain
> this stuff. I would certainly support that and put some effort into getting
> this done.
> >>>
> >>> Andy
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>