From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Adam Roach <adam@nostrum.com>, 
 "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "Hutton, Andrew"
 <andrew.hutton@unify.com>
Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery
Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwCpE+OAAAbcQIAAAWHBgAAEPqYQ
Date: Fri, 19 Dec 2014 01:20:16 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A35521B46@xmb-rcd-x10.cisco.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net>
 <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com>
 <54933BA3.9040209@nostrum.com> <D0B8A9B6.40F29%mzanaty@cisco.com>
In-Reply-To: <D0B8A9B6.40F29%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WTQ0Vyg-lzGr4cYaLqrKOVHlKe8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
Precedence: list

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mo Zanaty
> (mzanaty)
> Sent: Friday, December 19, 2014 2:50 AM
> To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
>=20
> The priority order that makes most sense to me is:
>=20
> 1. user override
> 2. app override
> 3. auto discovery
> 4. app fallback
> 5. user fallback
>=20
> If any override is configured by the user or app, do not perform auto
> discovery, stop here.
>=20
> If auto discovery fails, use a fallback configured by the app or user.
>=20
> There is a big difference between an override and a fallback, so both see=
m
> necessary.
>=20
> 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-pat=
il-tram-turn-serv-selection-00

-Tiru

>=20
> Mo
>=20
> On 12/18/14, 3:40 PM, Adam Roach <adam@nostrum.com> wrote:
>=20
> 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, an=
d call
> quality (latency, loss) improves.
>=20
> 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 de=
ploy
> and advertise such servers; something that allows WebRTC applications to
> discover and use them; and something that puts the ultimate decision in t=
he
> hands of the users. Off the top of my head, adding a browser API that all=
ows
> applications to  to retrieve these servers and elect to use them if it wa=
nts 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.
>=20
> But that's all kind of orthogonal to the IETF issues: if we're going to d=
o
> *anything* in this space, we need the discovery mechanisms.
>=20
> /a
>=20
> 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
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb