Chris Kranky

Recent Posts

Will TURN impact deployment of WebRTC?

Chris KoehnckeChris Koehncke

u-turnAs part of raising the percentage of successful P2P connections, the WebRTC specs call for a TURN server to be available. TURN, which stands for Traversal Using Relay NAT, has a relatively simple job of relaying packets between clients that can’t, for whatever reason, talk directly to themselves — basically when a P2P connection isn’t possible.

How it works is simple. Client A sends the data to the TURN server who in ‘turn’ (like that don’t you) relays the data on to Client B.  TURN servers will sit on the public Internet and the notion is that Client A or B should be able to reach the TURN server in most cases. TURN is a last resort connection when all else fails in the P2P attempts.

A TURN server isn’t supposed to be particularly bright, it’s kind of a dumb box relaying packets without giving it much thought. It’s only real value is that it’s out for the public to see. STUN (which is the ability for a client to determine it’s public IP address) and TURN generally will run on the same box. TURN operates a lot like a Skype ‘super peer’.

Unfortunately, the real life experiences for TURN to date have been few.  The bulk of SIP-oriented VoIP networks don’t utilize TURN (with only a small percentage utilizing even STUN). Thus TURN is a lot of RFC’s and theory, with little practical experience..

The result is that there is no decent open source (or even paid) versions of TURN that you can simply download, compile, execute and go. Worse, as more folks have started to look at the TURN specifications for ‘real life’ deployments they discovered some missing bits, hence we now seem to have multiple versions of what TURN is. Finally, TURN appears to have various security gaps which might allow a 3rd party to improperly gain access to the box.

It’s common to see public lists of STUN servers available on the Internet (including Google). But you won’t find anyone advertising a public TURN server. Why? Because TURN servers can consume mass quantities of bandwidth and the question is who is paying? (STUN servers have very data needs).

The SBC vendors adapting their boxes to WebRTC are likely to attack this issue, but (1) who wants to buy a real ‘box’ to simply have a TURN server and (2) is there any real willingness to pay (or pay very much for what should be an appliance)?

With each WebRTC session that is enabled, the TURN server has to be ready to take the connection should the peers fail to negotiate a direct link. Because the TURN server will be dealing with variable bit rate streams of voice and data, there is the question of how big a TURN server one might need.

Of course, you could re-engineer elements of WebRTC to not use TURN capabilities, but then you run the risk that your application will fail for some % of user and clearly that’s not the entire point of WebRTC.

TURN obviously makes sense but for anyone serious about developing a WebRTC application, they’re gonna have to devote some cycles to building a commercial grade TURN server.  This sounds like a great market opportunity for someone to develop and offer on a reasonable price basis. Perhaps Google themselves, Amazon or any of the cloud providers might step in to offer on a per drink basis.

We’re still in the early stages of WebRTC and the devil is in the details and it’s little things like TURN that could slow initial deployments.