Why Doesn’t Google Provide a Free TURN Server?

03/04/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).

So…

  • 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

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:

Responses

Gustavo says:
April 3, 2017

Come on Google, Don’t be evil

Reply
Peter Cardillo says:
April 4, 2017

Thanks for the insight – perfect for bite sized late night reading.

Reply
Philipp Hancke says:
April 4, 2017

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 😉

Reply
    Tsahi Levent-Levi says:
    April 4, 2017

    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.

    Reply
Ilya Selitser says:
April 4, 2017

TURN should be geo-redundant and this requires additional network, infrastructure etc. resources.

Reply
    Tsahi Levent-Levi says:
    April 4, 2017

    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.

    Reply
      Cetin A. says:
      April 6, 2017

      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.

      Reply
        Tsahi Levent-Levi says:
        April 6, 2017

        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.

        Tsahi

        Reply
RealTimeWeekly | RealTimeWeekly #174 says:
April 10, 2017

[…] Why Doesn’t Google Provide a Free TURN Server? […]

Reply
Ron says:
February 17, 2018

Hi,

Can you give us some recommendation about public/free services ?

Reply
Rohit says:
March 1, 2018

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]

Reply
    Tsahi Levent-Levi says:
    March 1, 2018

    Not much to go around with here, but I’d use a managed service like Twilio NAT traversal service or XirSys and be done with it.

    Reply
Koma says:
October 2, 2018

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.

Reply
    Tsahi Levent-Levi says:
    October 2, 2018

    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.

    Reply
Kangwa says:
February 9, 2019

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

Reply

Comment