Protocols such as SIP and WebRTC are instrumental in peer-to-peer (P2P) networks, especially for real-time, media-rich applications, such as gaming and videoconferencing. When two nodes in a P2P network want to exchange data, they need each other’s IP address to establish bi-directional communication. Easy enough, except this poses a security risk. To cope with that risk, networks often employ network address translation (NAT) to mask IP addresses, which then often breaks P2P media connections. To deal with NAT, addresses are often identified and conveyed with a tool called STUN, or Session Traversal Utilities for NAT. And STUN works great — except when it doesn’t.
For example, STUN will not work with symmetric NAT, which is common in large companies, nor will it work when the two nodes are separated by a firewall. When STUN doesn’t work, nodes can’t communicate, the application fails to work, and users get angry.
In such situations, a server running the Traversal Using Relays around NAT (TURN) protocol can save the day. In situations where NAT prevents two nodes from exchanging IP addresses and STUN can’t serve as an intermediary, those nodes can provide their IP addresses to a third party — a TURN server — which then relays each address to the other party.
The good news: TURN servers remedy almost all NAT-related connectivity issues. However, depending on the application, a lot of traffic may get routed through TURN servers. Accommodating heavy loads means more capital expense on TURN infrastructure, including having numerous TURN servers placed across the geographic range of an application’s user base. Additionally, optimal application performance will depend in part on having TURN servers located at the edge, as near as possible to client nodes. (Because communications run into the most congestion and interference beyond the core network, having TURN servers at or near the edge will improve end-to-end communication efficiency.) TURN server placement can make a significant difference in application performance and user experiences.
The obvious question follows: How do you figure out where to place your TURN servers? For better or worse, the answer can be complicated.
How do we determine “closest”?
As mentioned, you want the nearest proximity feasible between your nodes and TURN server(s). While this is a potentially complex problem, there are a few basic methods to pursue.
Domain Name System (DNS)
DNS is a worldwide naming service that maps Internet-connected resources to IP addresses. When a browser requests a server’s IP address, DNS can select which address to report. The selection process can use a range of criteria in picking the most performant IP address to provide, such as latency or load balancing. However, in regard to TURN server placement, DNS will offer clues more than a specific placement prescription, which can leave a strong element of guesswork in the process.
Geo IP
As its name implies, a Geo IP service allows you to input an IP address and obtain physical location information, including region, country, city, latitude, and longitude. This can be helpful if, for example, you do location lookup on your users’ IP addresses and determine what geographic clusters they live in. The problem is that different Geo IP services can return different answers, making specificity difficult. We would only recommend Geo IP if DNS wasn’t available at the application level.
Telemetry
When you want to know where a device is, sometimes all you have to do is ask. Most smartphones, for instance, can immediately provide their precise GPS location — if permissions allow it. Telemetry can offer very precise guidance on TURN server placement for user groups, but some or even many users may not allow sharing of their location data. In such cases, a backup plan is necessary.
Additional TURN server location considerations
If the world revolved around application developers and publishers, user locations would be immediately visible, entirely accurate, and even predictable. In reality, people move around, and the trend toward mobility means that client nodes move more than ever. Who is connecting and when they’re connected can change from moment to moment. As a result, TURN server placement that was optimized last week may be under-utilized or otherwise inefficient this week.
We have analytics, but we don’t have a crystal ball. Historical data can only take us so far. Understandably, application developers often decide TURN server placement is just too much hassle and outsource the problem to a hosting service. This offers no guarantee of optimization, though. For example, one of the world’s largest cloud service providers offers a STUN/TURN solution, but users must select their service by region. All of South America has one server. In the U.S., between northern California and northern Virginia, there are precisely zero additional servers. (Which one do you pick for users in centrally-located Kansas? Who knows?) The closest server to the Middle East, which is currently exploding with popularity in many application groups, is in Germany.
TURN server location selection is an imprecise science, and there are no perfect answers. Still, developers can ask providers some insightful questions in pursuit of picking the right service.
- What is the availability of the selected solution, both geographically as well as in terms of capacity and scaling?
- If you need to add servers, does the solution allow for it?
- Are key regions covered for your application?
- Does the provider offer any road map guidance on coverage expansion into additional areas?
In short, you need to match your own expected audience and growth trajectory to that of your TURN service provider.
A TURN service for tomorrow’s needs
What if the network itself offered TURN service?
That probably sounds strange, but it’s exactly what Subspace designed into its global infrastructure. By deploying TURN servers throughout its network as part of the core stack, Subspace can optimize TURN deployment and bring those services to the edge where they’re needed and best utilized. And because Subspace built its network and algorithms specifically for real-time applications, users get TURN capabilities embedded within an infrastructure already designed for their performance needs.
With Subspace’s WebRTC-CDN, developers are freed from the need to deploy or configure their own TURN servers. You simply connect, point traffic at the Subspace IP Proxy address, and instantly access a worldwide TURN network. Subspace’s packet proxying systems automatically identify traffic details and apply the optimizations needed to rush communications between nodes more quickly and efficiently than ever possible with non-optimized alternatives.
To find out more about WebRTC-CDN’s ease and value, click here.
