As we have already seen, the primary technical issue standing in the way of the universal deployment of VoIP is the problem of NAT traversal. Because of the large number of NAT topologies and the different rules that an NAT can enforce, it is very difficult to find a single standardized methodology to ensure that P2P communication can take place. VoIP of course is the classic P2P application but there are many others such as filesharing. We’ve covered a few techniques that allow VoIP traversal before – like the STUN protocol. A VoIP client contacts an external server to determine the external IP address at which it can be reached behind a NAT firewall. It then uses this external IP address and port in the SIP information which it sends to the receiving VoIP client begin the transfer of the RTP stream.
Unfortunately, certain symmetric NAT configurations change the external IP address and port of a device when the remote location changes. This breaks the STUN protocol and renders it useless. There is however another technique which is based on the STUN system. It’s called Traversal Using Relay NAT or TURN for short. As the name suggests, the TURN protocol makes use of a relay server to overcome the restrictions of symmetric NATs.
Here’s an overview of how TURN works. It’s quite simple once you understand the fundamental concepts. To start off with, the device sitting behind a NAT firewall sends a request to a TURN server for external IP address just like with a STUN Server. However, instead of the server sending back the external IP address of the VoIP client, the TURN server sends its own external IP address and port instead. It also keeps track of the external IP address and port of the VoIP client. The VoIP client having received the external address of the TURN server, sends that information in the SIP packet to the remote VoIP client which begins to send its media via RTP to the address specified.
The RTP stream is therefore actually directed to the TURN server. Since the server has already obtained the external IP address of the VoIP client behind the NAT firewall, it can then forward the RTP stream to that address so that it reaches its destination perfectly. This is pretty much a foolproof way for any VoIP client to navigate and NAT firewall. Unfortunately it’s quite resource intensive from the point of view of the entity managing the TURN server. For this reason, it is used only as a last resort when no other VoIP connection is working. The Interactive Connectivity Establishment or ICE methodology includes the TURN protocol as a possible solution for NAT traversal if necessary.