[tram] IMPORTANT CLARIFICATIONS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
"Karl Stahl" <karl.stahl@intertex.se> Thu, 13 February 2014 11:35 UTC
Return-Path: <karl.stahl@intertex.se>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E650A1A01EA for <tram@ietfa.amsl.com>; Thu, 13 Feb 2014 03:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level:
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzwI6rNDop7z for <tram@ietfa.amsl.com>; Thu, 13 Feb 2014 03:34:59 -0800 (PST)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E41A01F9 for <tram@ietf.org>; Thu, 13 Feb 2014 03:34:57 -0800 (PST)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131234511651; Thu, 13 Feb 2014 12:34:51 +0100
From: Karl Stahl <karl.stahl@intertex.se>
To: "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>, "'Hutton, Andrew'" <andrew.hutton@unify.com>, 'Justin Uberti' <juberti@google.com>, "'Muthu Arul Mozhi Perumal (mperumal)'" <mperumal@cisco.com>
References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com>
Date: Thu, 13 Feb 2014 12:34:51 +0100
Message-ID: <006701cf28af$9c2a27f0$d47e77d0$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01CF28B7.FDEE8FF0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac8obNsCBHZfUz6PQqmEmyo5gqkf2AAIL2iQ
Content-Language: sv
X-Mailman-Approved-At: Thu, 13 Feb 2014 05:43:49 -0800
Cc: tireddy@icisco.com, 'Simon Perreault' <simon.perreault@viagenie.ca>, 'Oleg Moskalenko' <mom040267@gmail.com>, tram@ietf.org, 'Marc Blanchet' <marc.blanchet@viagenie.ca>, "'Dan Wing (dwing)'" <dwing@cisco.com>
Subject: [tram] IMPORTANT CLARIFICATIONS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 11:35:08 -0000
On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the firewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things The intended solution in the enterprise case has not yet been spelled out in this TRAM-list discussion, so for better understanding, let me copy a few things from the discussion in September/October on the RTCWEB-list and what is (since long) spelled out in the draft-ietf-rtcweb-use-cases-and-requirements. For better understanding, I also want to point out that a TURN can have two interfaces (acting like a router for media between different networks). This allows to easier understand that can TURN servers can direct a best media path (rather than just thinking that a TURN service is a device which media just bounces against at one interface). And, we can also hope for that a TURN server becomes a (common) component of a firewall, which would allow the firewall to understand that the media directed to it is RTC and should be prioritized whereby the firewall can traffic shaped (back-off data traffic that may be filling its Internet pipe) as well as e.g. set diffserve bits or take other measures to assist proper quality handling thought the network. (These are common mechanisms available and used in firewalls/NATs/access routers, but TURN servers are not yet included such devices.) The same goes for access routers/default gateways, DPIs in the transport network itself – TURN servers included in such points were media can pass and quality measures applied may/will be very useful to get us WebRTC media with through networks without quality destruction. >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not allowing UDP traffic, could provide a real-time path using a TURN server paralleling the firewall, instead of tunneling RTP through always open http or https ports resulting in RTP media over TCP – with severe quality problems from TCP retransmissions of dropped packets. The TURN server address is most easily provided in the same way as the IP address and DNS address. (That would also put the right party in control – The network provider (here the enterprise) decides what is allowed on his network.) The browser should select which available TURN server address to use in the following priority order, where ICE could be used to try several: 1) TURN server address configured in the browser by the user (special cases, normally not used) 2) TURN server address configured by the network administrator via an “admin policy template” 3) TURN server address supplied by DHCP or similar automatic network method 4) TURN server address being supplied by the web application" And from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14 these enterprise things and necessity are spelled out in: F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- A22 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5> 3.3.5. Simple Video Communication Service, enterprise aspects <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.1> 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 3.3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1> ). What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.2> 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- There are further requirement listed, helping us to understand the need for auto discovery and a network provided TURN-server should be used to ENFORCE that media takes that path (and thus, other paths e.g. suggested by the remote MUST not happen to be used). This is related to the mobility aspect (valid even without the roaming idea): <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6> 3.3.6. Simple Video Communication Service, access change <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.1> 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1> ). The difference is that the user changes network access during the session. The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.2> 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7> 3.3.7. Simple Video Communication Service, QoS <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.1> 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 3.3.6 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6> ). The use of Quality of Service (QoS) capabilities is added: The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.2> 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- Further from the RTCWEB mailing list September 20th (by me): There are several reasons for a network service provider to supply a TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data traffic). Getting “WebRTC-ready” access and we look forward to telepresence for everyone. I hope this (a bit lengthy) summary of already thought-out and discussed aspects/requirements will help us understand that the auto-discovered TURN server is an ORDER from the enterprise and/or the NSP/ISP to send the media through this TURN path, and that other media paths that may exist MUST NOT BE USED. (That is why we especially have to watch/advice that workable media paths proposed by the remote party not becomes used “by accident”. /Karl Från: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Hi Andy, There are other ways to solve the problem for example using PCP. Can you clarify how deploying a TURN server in the Enterprise protects the users and the network ? -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs The case where the TURN server is the only option may become common within enterprise networks and that might be deliberate enterprise policy because it provides the better path (UDP through the F/W) and protects the users and the network. Andy From: tram [ <mailto:tram-bounces@ietf.org> mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: <mailto:tireddy@icisco.com> tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; <mailto:tram@ietf.org> tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Agree. If TURN is indeed being provided for the user's benefit, the client's ICE logic (based on RTT or similar) should result in it preferring the TURN path. On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com> wrote: Yes, I believe the second case is rare, but would be better than a rat race b/w administrators trying to block p2p traffic and force it through a TURN server and apps/endpoints finding smarter ways to bypass them. Muthu From: Oleg Moskalenko [mailto: <mailto:mom040267@gmail.com> mom040267@gmail.com] Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; <mailto:tireddy@icisco.com> tireddy@icisco.com; Marc Blanchet; <mailto:tram@ietf.org> tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs The TURN server has to be used when it is either the only option, or if it provides a better path (I guess the second case is rather rare). On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com> wrote: +1 Forcing all traffic through a TURN server and expecting it would provide the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide lower RTT, jitter etc, being able to detect and use (or switch to) that path might be desirable.. Muthu From: tram [mailto: <mailto:tram-bounces@ietf.org> tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: <mailto:tireddy@icisco.com> tireddy@icisco.com; Marc Blanchet; <mailto:tram@ietf.org> tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Inline. On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> wrote: Listening to this thread, I am afraid we are missing the very point and necessity for this milestone! - There are severe NAT traversal and quality issues that should and can be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser) There are ways, not only: Enterprises or ISPs wishing to provide their own TURN server, in an attempt to reduce so-called "triangle routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic. - Enterprises having restrictive firewalls, want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic. Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server This leads us into “TURN…to identify WebRTC flows” etc! It is not a mistake, but the very need for this milestone! Again, it has not been demonstrated why TURN is the right technology here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the same for WebRTC. What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method’s very idea (like all similar methods for getting RTC through ordinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is root of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point. I think that "fooling" is an incorrect description. The NAT is supposed to be transparent to the client. But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J ICE is a pre-protocol you use because you want a path for real-time media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible). If the NAT/Firewall owner and network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they are not aware, they cannot help! Hope this made it understandable on an overview level how this can become “TURN…to identify WebRTC flows” It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone. I am talking about general usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist). This is good, not evil! If the hesitations are raised because of a belief/hope/wish that there are no or will not be severe quality issues “because it is all about bandwidth”, “it will resolve itself with time” etc., I strongly object! That is wrong and will be very detrimental for WebRTC usage. We already see it and I can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad considering quality issues and allowing/encouraging methods to deal with them? If the hesitations are raised, because of suspicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telephony traffic), I could understand and would fight the same battle. But hopefully, those days are (soon) over – At least forward thinking carrier’s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The carrier’s offering/assuring good WebRTC will rather get the customers and income J. (Maybe the Web browser can detect and encourage this…) If there are technical concerns of bad result, or better methods allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used, and that the web browser automatically can chose those, then let us all understand those, so we can achieve what should be achieved by this milestone. Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much bigger jump that I don't yet see the justification for. In short: TURN is a technology that is supposed to fade away with the move to IPv6. I don't think we want to make it a critical element of WebRTC. /Karl Från: Dan Wing [mailto: <mailto:dwing@cisco.com> dwing@cisco.com] Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; <mailto:tireddy@icisco.com> tireddy@icisco.com; Karl Stahl; <mailto:tram@ietf.org> tram@ietf.org; Simon Perreault Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs On Feb 11, 2014, at 9:08 AM, Marc Blanchet < <mailto:marc.blanchet@viagenie.ca> marc.blanchet@viagenie.ca> wrote: Le 2014-02-11 à 00:39, Dan Wing < <mailto:dwing@cisco.com> dwing@cisco.com> a écrit : On Feb 10, 2014, at 5:30 PM, Justin Uberti < <mailto:juberti@google.com> juberti@google.com> wrote: Good to see there is a lot of interest for this milestone. But based on the description here, it seems like we want to use TURN primarily to identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem. +1. I would prefer allowing flows to establish themselves using their 'best' path, and the best path is seldom through a TURN server. When we imagine IPv6 in our future, we don't want to force an application-level proxy (TURN) server on the path solely for traversing an IPv6 firewall. It seems this thread is conflating all the possible reasons / justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy Unfortunately the TURN server nor the endpoint really know which of those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all). Dan, while I agree in principle, I doubt that a user could ever say "I want mobility or I want NAT traversal". I think the user only want the call to succeed, whatever the properties of its network point of attachment are. So what can we do? Should the TURN server provide any and all services the TURN client might possibly want, as that is what a robust TURN server will do, and the endpoint should prefer TURN candidates over all others because there might be some functionality / usefulness of TURN that the user might gain through TURN (e.g., enhanced privacy)? -d This seems problematic. Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology for some of these use-cases. -d On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl < <mailto:karl.stahl@intertex.se> karl.stahl@intertex.se> wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Från: tram [mailto: <mailto:tram-bounces@ietf.org> tram-bounces@ietf.org] För Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; <mailto:tram@ietf.org> tram@ietf.org; <mailto:tireddy@icisco.com> tireddy@icisco.com Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a écrit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, “automatically” does this.) I understand the STUN vs TURN priority issue. But I don't see how anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is provided and discovered, CURRENT usage of ICE may suggest a candidate from the remote party that will make a connection without the need/usage of the TURN server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the provisioning of auto-discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed "by accident"). (That was the thought behind the “automatically” within quotes.) BUT, since you brought up the question, assuming that we have the power to enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-discovered TURN server instead of STUN, would solve the same problem. However, thinking further (in relation to your next question - "anyone could set up a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below – I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) – The anycast discovered TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would this not be subject to the same service quality issues that plagued 6to4? That is, anyone could set up a badly-maintained, under-provisioned TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer... An auto-discovered TURN server must be trusted (whatever method it is discovered by). We are trusting the one providing us with an IP address and default gateway anyway. It would be easy if we could reuse that trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is not handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> <http://postellation.viagenie.ca/> http://postellation.viagenie.ca NAT64/DNS64 open-source --> <http://ecdysis.viagenie.ca/> http://ecdysis.viagenie.ca STUN/TURN server --> <http://numb.viagenie.ca/> http://numb.viagenie.ca _______________________________________________ tram mailing list <mailto:tram@ietf.org> tram@ietf.org <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list <mailto:tram@ietf.org> tram@ietf.org <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list <mailto:tram@ietf.org> tram@ietf.org <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list <mailto:tram@ietf.org> tram@ietf.org <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram
- [tram] Milestone 3: TURN server auto-discovery me… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- [tram] Milestone 3: TURN server auto-discovery me… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Dan Wing
- Re: [tram] Milestone 3: TURN server auto-discover… Marc Blanchet
- Re: [tram] Milestone 3: TURN server auto-discover… Dan Wing
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Oleg Moskalenko
- Re: [tram] Milestone 3: TURN server auto-discover… Pal Martinsen (palmarti)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- [tram] IMPORTANT CLARIFICATIONS: Milestone 3: TUR… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Pal Martinsen (palmarti)
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] IMPORTANT CLARIFICATIONS: Milestone 3:… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- [tram] QoS for RTC over the Internet, DISCUSS: Mi… Karl Stahl
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Simon Perreault
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Pal Martinsen (palmarti)
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Karl Stahl