Be very clear to yourself why you manage your own TURN servers

Running your own TURN servers for your WebRTC application is not necessarily the best decision. Make sure you know why you’re doing it.

[In this list of short articles, I’ll be going over some WebRTC related quotes and try to explain them]

Are you running your own TURN server? Great!

Now, are you crystal clear and honest with yourself about why you’re doing that exactly?

WebRTC has lots of moving parts you need to take care of. Lots of WebRTC servers: The application. Signaling servers. Media servers. And yes – TURN servers.

I already covered a few aspects of TURN in this WebRTC quote – We TURNed to see a STUNning view of the ICE. It is now time to review the build vs buy decision around TURN.

You see, NAT traversal in WebRTC is done by using two different servers: STUN and TURN. STUN is practically free and it can also be wrapped right into the TURN server.

TURN servers are easy to interface with, but not as easy to install, configure and maintain properly. Which is why my suggestion more often than not is to use a third party managed TURN service instead of putting up your own. Economies of scale along with focus and core competencies come to mind here with this decision.

Why buy your WebRTC TURN servers?

Buying a TURN server should be your default decision. It is simple. It isn’t too expensive (for the most part) and it will reduce a lot of your headaches.

Most of the companies that approach me with connectivity issues of their WebRTC application end up in that state simply because they decided to figure out NAT traversal in WebRTC on their own.

Here are a few really good reasons why you should buy your TURN service:

• The best practices of TURN (and STUN) configuration aren’t the defaults of open source TURN servers or of the standard specification itself. So if you don’t have someone inhouse who has done it at scale in the past already, then don’t start now
• Using a third party managed TURN server is simple. Onboarding and integration should be a breeze (a few hours at most)
• There’s no real vendor lock-in. Switching to your own TURN servers will cost you the same as it would to start with your own TURN servers, so you can delay that decision for later. And switching to another managed TURN server is just as simple as it is to start using one for the first time
• Testing for edge cases and figuring out issues with WebRTC connectivity is hard. It takes a lot of time, requires patience, understanding and visibility when issues fail. None of this is something you’ll have in the first months of running your own service
• It is cheap. Twilio has it at $0.4/gigabyte of data. And not all of your traffic will go through TURN anyways. When you’ll start paying too much to your taste, you will be able to put up your own infrastructure. But why invest in that effort before it is time to do so?
• Someone else will take care of scaling. TURN needs to be as close as possible to the end users. Installing a single server won’t be enough. Installing a single region won’t be enough. Why deal with that headache?
• Running TURN properly means deploying it in multiple regions (=many). This means that even if you have low traffic, if it is geographically spread, you are going to pay for a large number of servers – more than you need. This makes running your own expensive
• Firewall friendliness. Using your own servers means opening them up in firewall configurations of your customers. There’s a small likelihood that these firewalls are already configured to support the managed TURN service you are using for other tools

Why build your WebRTC TURN servers?

We are all builders. And we love building. So adding TURN into our belt of things we built makes sense. It also plays well into the vertical integration we now appreciate with how successful Apple has been with it with its services.

But frankly, it is mostly about control. The ability to control your own destiny without relying on others.

I still think you should buy your TURN servers from a reputable managed service provider. That said, here are some good reasons why to build and deploy your own:

• Data sovereignty and other regulatory reasons. In some industries, for some customers, the fact that you host and run your own servers is critical. In such a case, using a managed third party TURN service is simply impossible. In the same domain, privacy and data processing  requirements may make using a third party harder than setting up your own
• You already have a large traffic and footprint. With economies of scale this starts becoming interesting and important. If you have the sheer size that makes it worthwhile running your own then do it. I wouldn’t start below $10,000 or even $50,000 in monthly expenses for your managed TURN service, which is a lot of traffic. Why? Because you’ll need a full time ops person on the job for at least half a year if not longer. And you’ll need to deploy servers in many regions from the get go, so better start when you’re big enough
• Firewall configurations can be a mess. Sometimes, your customers may want to validate the IP addresses they configure are yours, or want to limit the IP address ranges they configure, or limit the services they expose themselves to. In such cases, they might not look at it nicely when you use a third party
• Existing customer installations might already be configured to your IP address ranges, and just placing your TURN servers within those ranges will be easier than asking them to change firewall configurations to incorporate a third party vendor
• Traffic control is another reason. Using your own SDN network configuration or packet acceleration may benefit from having your own TURN servers in-house, alongside the rest of your infrastructure as opposed to be hosted elsewhere where connectivity to your backend servers might be questionable

–

Build? Buy? Which one is the path you’ll be taking?

👉 Trying to get more of your calls connected in WebRTC? Check out this free video mini course on effectively connecting WebRTC sessions