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

["Hutton, Andrew" <[e-mail]>]

I agree we surely do need to need to cater for the case when a local TURN server is discovered or configured by the user/admin and specify how the WebRTC browser behaves in that scenario.  We have always had that requirement specified as Justin pointed out.

I support moving forward with draft-schwartz-rtcweb-return as it covers that use case.

The actual discovery mechanism is I assume something to discuss in TRAM.

Regards
Andy



From: rtcweb [mailto:[e-mail]] On Behalf Of Justin Uberti
Sent: 08 January 2015 04:15
To: Mark Nottingham
Cc: RTCWEB
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery

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]<mailto:[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]<mailto:[e-mail]>> wrote:
>
> On Dec 17, 2014, at 9:06 AM, Harald Alvestrand <[e-mail]<mailto:[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]<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
>
--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb