Why Doesn’t Google Provide a Free TURN Server?

April 3, 2017

No such thing as free lunch. Or a free TURN server.

It is now 2017 and WebRTC has been with us for over 5 years now. You’d think that by now people would know enough about WebRTC so that noob questions won’t be with us anymore. But that just isn’t the case.

Want to learn more about WebRTC server requirements and specifications? Enroll now to my 3-part video mini-course for free:

One question that comes up from time to time is why doesn’t Google (or anyone else for that matter) offer a free TURN server?

Besides the fact that you shouldn’t be using free STUN or TURN servers that are out there simply because you have zero way to control them when things go wrong, lets first understand what’s the difference between these two servers – or more accurately protocols, since STUN and TURN usually end up being deployed together.

How STUN works

The illustration below should give you the gist of how STUN works:

When STUN is used, the browser or any other WebRTC enabled device sends out a message to the STUN server asking him “who am I?”. The idea here that STUN is used to find out your public IP address. This is something your machine doesn’t know on its own as this “allocation” happens by the NAT you are behind (and you will almost always be behind a NAT). That information is also dynamic in nature – you can’t really rely on the same answer being received each time – or that the pinhole generated by the query itself will stay open.

This is a simple question that the STUN can provide a single answer for. Furthermore, this takes place over UDP, making it lightweight and quick – not even requiring establishing a longstanding connection or having context in place.

Once the browser has the answer, he can share it, and if all else works as expected, he will be receiving media directly.

The STUN’s role here was limited to this single question at the beginning.

How TURN works

Here’s how TURN works:

When it comes to TURN, we start with a request for binding – our browser is practically asking the TURN server if he can be used as a relay point. And if the TURN server obliges, then it can now be used to receive all media from the other device on the session and relay that to our own browser.

While the initial binding request isn’t taxing (though still more expensive on our TURN server than the query sent to the STUN server), the real issue is the media that gets relayed.

If you take a simple WebRTC video session that gets limited to 500kbps or so, then a 15 minute session will end up eating…

That ends up being over 50MB in traffic. Assuming we do only 10 sessions an hour on average on that TURN server, we end up with 360GB in traffic per month. And that for quite a small service. It isn’t really expensive, but it does if you scale it up: use more bandwidth per session, have more sessions per hour on average – and you’re going to end up with lots of data traffic.

Here’s how a recent stress run we’ve had on testRTC ended up:

For a stress test with 500 participants, split into group of 5 browsers per multiparty call, running for only 6.5 minutes, we ended up with 52Gb of media traffic in each direction. Less than 10 minutes.

Now think what happens if all that traffic need to go through a TURN server. And that TURN server is free for all.

Putting it all together

STUN and TURN are drastically different from each other. We need both in real production WebRTC services. And we usually think of them of a single server entity deployed in the backend – for STUN we simply don’t fret about the resource needs it has and focus on what we need to get TURN running in scale and in multiple geographical locations.

It is also standard practice to clamp down on your TURN server and have credentials configured for it. For WebRTC, these credentials need to be ephemeral in nature – created per session on demand and not per user (as often is the case in SIP).


  • If you are wondering why there are no free TURN server out there, or good code on github that has TURN already configured for it that works – don’t. It makes no sense for anyone to give that for free
  • If you happen to bump into a TURN server with user/password credentials that work, then please don’t make use of them – someone ends up footing the bill for you – and he is probably doing it without even knowing (he wasn’t aware of the abuse potential I am assuming)
  • And if you still end up using that TURN server (nasty you) – expect that person to find that out at some point and just shut you out of his server – not something you want happening if you have users for your service
  • Cobble up your own TURN servers or use a paid managed WebRTC TURN service. I like the managed alternative here
  • Oh – and you will definitely need TURN server in WebRTC – even if you are using media servers

Want to learn more about WebRTC servers?

Tomorrow, I will be launching a free video mini-course. This course explains what servers you will need to deploy for your WebRTC product, what are their machine specifications and what are the tools that are out there to assist you developing them faster.

Want to learn more about WebRTC server requirements and specifications? Enroll now to my 3-part video mini-course for free:

You may also like

WebRTC predictions for 2023

WebRTC predictions for 2023

Your email address will not be published. Required fields are marked

  1. I think you want to change the bandwidth calculation to use 1.5 or 2mbps which is what chrome uses by default for a 640×480 resolution.

    Makes TURN much more expensive to run if you don’t restrict it 😉

    1. I tried to be nice, and a bit more critical on what I see people doing in production when they have some sense in them (=limiting bit rates to fit the resolution/quality/costs they expect).

      But yes. Chrome is a bandwidth hog when it comes to using the bandwidth it estimates is available for its use.

    1. Yes, it does. But is that enough of a reason? You can spin up VMs virtually anywhere these days at a relatively low cost if your computational load is low (and it is for STUN and TURN). The real problem here is the bandwidth.

      1. Thanks for the article. I think the processing load is worth considering on TURN if it does some video processing instead of just relaying. But in that case you don’t call it TURN anymore, right? It is a SFU or MCU perhaps.

        1. Cetin,

          The problem is less processing and more bandwidth costs – they can pile up if you give anyone the ability to abuse you for their own needs and practically hijack your TURN server.

          And yes. A TURN server can only relay – it can’t even look inside the packets as they are encrypted. An MCU or SFU is more of a media server which is a totally different beast with different characteristics.


  2. We have our Linux Server ( Production). Will it be a wise decision to use that as STUN and/or TURN server, also ?

    or should we have something on cloud specifically behaving as STUN/TURN ?

    [The Application will be used by < 1000 users but in different geographies]

  3. Can a TURN server be used briefly to setup a connection between “A” and “B” and then no longer needed as “A” and “B” are now aware of each other directly?
    Turn based web games and text chat would use a lot less bandwidth than video & audio and potentially an exciting use for WebRTC.

    1. As far as I know, once TURN is selected, it won’t fallback to peer to peer. That said, assuming peer to peer is possible, it is what gets selected.

      The issue I know about with turn based web games is that often times you want to have a server make the decisions and keep things in sync with the game, which means direct connectivity for turn based games might not be a preference (though probably depends a lot on the game).

      Text chat usually needs to be stored and backed up for most systems, which again insinuates the need for a server.

  4. ….It’s gonna be expensive our use cases will mostly be multi-party.. I hope we’ll get the funding when we start pitching

  5. Well, it seems complicated but a TURN server is just a fallback streaming media server for relaying audio/video data when a direct -P2P- connection is not possible.
    Tokbox says that around of 20% of their users need a TURN server for their AV solutions.

  6. Thanks for this article. I appreciated the simplicity.

    I’ve been trying to configure Coturn server to work with Matrix-Synapse. I’ve read a ton of tutorials and messed about with the configuration but no joy. I wonder if you might point me in the right direction.

    I have installed Matrix-Synapse via Freedombox on a Raspberry Pi3B. Along side, this on the same Pi, I have installed NextCloud Talk, which installed Coturn Turn server. The Pi is on my home network, behind a home router, on which I have set up port forwarding for TURN and Matrix-Synapse (as well as other services). I have opened up ports for TURN in the Freddombox firewall. Firewalld.

    I can get voice calls to connect between local network devices, but from external devices the call comes through but can not connect! Text chat works fine though.

    I have been using the following testing service while messing with this configuration:https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

    Any suggestions about how to start problem solving would be very much appreciated.


  7. Nicely written article. I’m just getting started with WebRTC (10 years too late I know), and this was a great read.

  8. Hi Nice article.

    We are trying to established only 1-1 live streaming application in our app through webRTC. There is no need to have SFU as video streaming will always happened 1:1 …. From same app. I have few queries

    Are we still required to have TURN server ?

    What would you recommend for this requirement

    Should we implement our own Stun/Turn server or third party provider is needed ? which one would you recommend ?

    1. Mihir,

      Yes. You still need a TURN server, probably even more than with an SFU.

      Look at Twilio STUN/TURN service or Xirsys for a third party provider. There’s little in the way of vendor lock-in, so nothing to lose by starting off with them.

    1. Nothing against them. Interesting it turned that way.

      coturn is the most popular and widely used STUN/TURN server for WebRTC out there. If you want to use your own – then go with coturn. Don’t be adventurous and try other open source TURN servers.

      (we use coturn as well at testRTC for certain services we offer)

  9. Hi amazing article, thank you so much for the info.

    I did have one question regarding STUN. If using STUN and the connection being peer to peer there would essentially be no server costs as far as the bandwidth is concerned?

    1. True. STUN is practically free when it comes to bandwidth use.

      You will still need to host it (or pay for it, or use a “free” service). And there are also your signaling hosting/costs, but that’s not much compared to the costs media relay via TURN.

  10. Hi, does anyone know if these public servers have limits? I and wondering if it would be possible to query these servers too often and get our services blocked for running queries? More specifically the stun.l.google.com servers. Thanks

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}