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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Mo Zanaty
> (mzanaty)
> Sent: Friday, December 19, 2014 2:50 AM
> 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.

TURN server selection is discussed in https://tools.ietf.org/html/draft-patil-tram-turn-serv-selection-00

-Tiru

> 
> 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