Intro
Before I start discussing TURN, just want to set the scene here. I’ve decided to write a series of articles on Interactive Connectivity Establishment (ICE). Why a series you might ask? To be honest with you I never really liked very long technical articles and discussing ICE would definitely be one. Instead, I’ll divide the theory and practice into smaller more digestible chunks. Coming first – TURN server as ICE heavily relies on it and it’s crucial to understand its operation.
What is TURN?
I will expand the acronym just because I like to know what they mean. You don’t have to remember that. Hopefully, with the explanation in this article, you will be able to intuitively decode it. TURN stands for Traversal Using Relays around NAT. It is defined in RFC 5766. You can find all the nitty-gritty there. My goal here is not to bore you with details but to allow you to understand the concept.
Why do you need a TURN server?
As always, a picture is worth a thousand words.
Let’s assume the endpoint in the lower left-hand corner (A) wants to communicate with the endpoint in the upper right-hand corner (B) via a SIP Proxy.
Endpoint A is behind a NAT with a private IP of 10.10.10.10. Endpoint B is on a public IP 20.20.20.20.
Normally when A sends a SIP Invite to B, it would contain the private IP in the Connection Data field within SDP, such as below:
c=IN IP4 10.10.10.10
Now, what happens when Endpoint B receives this information?
It will try to stream media towards this IP. Will that work? Sure not, it’s a private IP.
How does TURN work?
What can be done to fix this? This is where TURN server comes into the picture. In simple words, TURN allows fixing the media path.
Endpoint A will say “Hey Mr. TURN, please give me an IP and port that I can use to fix the media path”. This is done with an Allocation Request. If all goes well, the TURN server will send back a reply saying “Sure thing, you can use 30.30.30.30 and port 30000” (Allocation Response).
With this information, endpoint A will replace its private IP with the one received from the TURN server, resulting in the following Connection Information being sent within SDP (also including the port in the m line):
c=IN IP4 30.30.30.30
m=audio 30000
Endpoint B can now happily send RTP packets towards 30.30.30.30 on port 30000. The TURN server has a table that keeps track of all it’s clients so it knows that whatever is received on that port, it needs to forward to endpoint A.
Well, there is a NAT in front you might say, how does that get through to A?
It will not be blocked as the client (A) initiated the connection first towards port 3478 on the TURN server. The return traffic containing RTP packets encapsulated in STUN headers is therefore allowed (I’ll talk a bit more about STUN in the next episode).
Summary
A TURN server is nothing but a communication relay. It’s used when a direct connection between endpoints is not possible aka NAT is involved. I hope the acronym makes more sense now – Traversal Using Relays around NAT.
