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

[Suhas Nandakumar <[e-mail]>]

Few cents ..

I tend to agree with Cullen's sentiment since as a end user I don't want to
end up with service provider lock-in when using a TURN server.

Such lock-ins might not be a bad option but It need not be enforced by
design.

OTOH  I am not sure how effective will be a typical not-so-technical
end-user's decision making in choosing one turn server over the other.

But having flexibility is not a bad idea , thus i feel the spec needs to
just say the plausible options but mandating with MUST might not be what we
need here.



Cheers
Suhas


On Fri, Dec 19, 2014 at 8:55 PM, Benjamin Schwartz <[e-mail]>
wrote:

> To reiterate, the TRAM draft doesn't specify what WebRTC should actually
> do with the discovered TURN server(s).  RETURN (
> https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) attempts
> to fill in the details, and also resolve questions about priority of
> different settings, etc.
>
> Comments on the RETURN draft are appreciated, of couse.
>
> On Fri, Dec 19, 2014 at 5:15 AM, Hutton, Andrew <[e-mail]>
> wrote:
>
>> +1 to Adam and Mo's comments which make a lot of sense to me.
>>
>> I agree we need to enable the use of TURN servers which provide the best
>> user experience so enabling the use of TURN servers close to the clients
>> makes sense.  At the same time there are some security considerations which
>> we can provide some guidance on so would it make sense to do the following?
>>
>> 1. Add a reference to draft-ietf-tram-turn-server-discovery in
>> -transports- and make it a SHOULD/MAY/MUST implement (I prefer MUST but I
>> know others probably don't).
>>
>> 2. Add some text either inline or in the security considerations about
>> the concerns and the need for user/app override.
>>
>> By the way I am not sure we need the app override if we consider
>> draft-schwartz-rtcweb-return part of the solution.
>>
>> Andy
>>
>>
>> > -----Original Message-----
>> > From: Mo Zanaty (mzanaty) [mailto:[e-mail]]
>> > Sent: 18 December 2014 21:20
>> > To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew
>> > Cc: [e-mail]
>> > Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
>> >
>> > 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
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>