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

Adam, I think you are I are mostly saying the same thing. Things like there need to be incentives to deploy, the browser should tell the applications about available servers, and so on ...

There are probably a bunch of ways to do this - for example all the arguments being made about TURN server same equally true of HTTP socks servers yet my SP can't force all my traffic via a HTTP proxy of it's choosing. So I don't think claiming the privacy problems  is orthogonal to the the IETF issues is really OK. The privacy issues are pretty important. As you suggest, I'm OK with browser tells applications about servers that are available but I would not be keen on browser automatically choosing to use those. That creates the type of incentives that it's fine for the SP to block traffic that does not go through the approved (and inherently quality reducing) TURN server. 

It's also important to have solutions that makes business sense. Running TURN server is often sort of expensive from the bandwidth point of view so typically the TURN servers have a relation with the actual application to enable them - it's not just that someone is going to provide TURN servers for  for all webrtc applications in all networks. It's going to be a bit more complicated than that and that in helps drive some of the requirements for this. A way where applications can discover TURN servers that they are authorized to use if far more appealing to me. 

The privacy implications and bandwidth usage implications are very different for STUN and TURN and thus I think the appropriate discovery mechanics for them are likely different. At least the requirements for the mechanisms are different even if there is one mechanism that meets all the requirements. 

As tempting as is sounds to leave the selection up to the user, I don't think that will work. I think it needs to be up to the application running on the browser with perhaps the possibility to be overridden by user. 

There is a lot of ways to do discovery  and some of them are already supported so I think we should figure out what we want then work on which of various discovery approaches help with that. 

> On Dec 18, 2014, at 1:40 PM, Adam Roach <adam@nostrum.com> wrote:
> 
> So, I think it's important that we have some way to encourage deployment of TURN servers both in the ISPs, and as part of firewalls (both residential and enterprise). By putting TURN in paths that are already going to bear the traffic in question, the overall cost associated with calls goes down, and call quality (latency, loss) improves.
> 
> I'm sympathetic to the position that we don't want to give these entities specific hooks to force specific servers to be inserted into the flow. We need to find a balance here: something that allows the relevant entities to deploy and advertise such servers; something that allows WebRTC applications to discover and use them; and something that puts the ultimate decision in the hands of the users. Off the top of my head, adding a browser API that allows applications to  to retrieve these servers and elect to use them if it wants to would serve part of the purpose; giving users a means by which they can instruct the browser not to return such a list would serve the remainder.
> 
> But that's all kind of orthogonal to the IETF issues: if we're going to do *anything* in this space, we need the discovery mechanisms.
> 
> /a
> 
> On 12/18/14 11:23, Cullen Jennings (fluffy) wrote:
>> It seems that in the mobile case and many residential cases, doing that draft would allow a service provider to force all the traffic through a TURN server of the service providers choosing. Am I reading this correctly because I am pretty sure I would not be in favor of that.
>> 
>> 
>>> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:
>>> 
>>> I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4 should include a requirement that a WebRTC Browser MUST support the TURN server discovery as described in https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00.
>>>    Andy
>>>  _______________________________________________
>>> 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
> 