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

["Mo Zanaty (mzanaty)" <[e-mail]>]

The priority order that makes most sense to me is:

1. user override
2. app override
3. auto discovery
4. app fallback
5. user fallback

If any override is configured by the user or app, do not perform auto
discovery, stop here.

If auto discovery fails, use a fallback configured by the app or user.

There is a big difference between an override and a fallback, so both seem
necessary.

Obviously, we need some mechanism for 3 as Adam said, in case it needs to
be invoked.

Mo

On 12/18/14, 3:40 PM, Adam Roach <[e-mail]> 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 <[e-mail]>
>>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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

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