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

[Benjamin Schwartz <[e-mail]>]

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
>