STUN or TURN? Which one to prefer; and why?

HOME © Muaz Khan . @WebRTCWeb . Github . Latest issues . What's New?

This tutorial is out-dated (written in 2013). WebRTC implementation is heavily changed since then. So please do NOT refer or rely on this page.

1. The key difference between these two types of solutions though is that media will travel directly between both endpoints if STUN is used, whereas media will be proxied through the server if TURN is utilized.
2. TURN is preferred because it is capable to traverse symmetric NATs too. However, STUN is useful to speedup the connection out of getting immediate candidates when users are sitting behind same NAT e.g. LAN.
3. A media relay server or ICE server is utilized to setup the media session and provide the list of potential candidates to both parties in a call regardless of which media delivery option is selected for each end of the call.
4. Also understand that the media stream may not always use the same solution on both ends as STUN may be possible for one endpoint but not for the other endpoint.
5. When we use both STUN and TURN servers; STUN is always attempted first (!!!!!...not-on-chrome...!!!!!); TURN is used as fallback option depending on client locations and network topologies.

6. var iceServers = {
        iceServers: [STUN, TURN]
   };
   

7. TURN protocol runs top of STUN to setup a relay service. A well written TURN server will also function as STUN; so you can skip a "separate STUN server" option in such case.
8. TURN is developed to cover holes haven't (or may not) punched by the STUN; e.g. SNATs i.e. Symmetric NATs.
9. A critical disadvantage of a TURN server is its cost; and huge bandwidth usage in case when HD video stream is delivered.
10. The acronym STUN may also be seen referred to as Simple Traversal of UDP through NAT which was the protocol’s original name (as defined in now obsolete RFC 3489).
11. When the protocol was updated to include support for TCP the name was changed to Session Traversal Utilities for NAT to reflect that it was no longer limited to UDP traffic.
12. Although media leveraging STUN is not a direct host-to-host session it is the next best option as the media path is still sent directly between the two client’s own firewalls, over the Internet.
13. This keeps the media session as short as possible and does not burden the corporate network with handling the media relay processing or bandwidth.
14. There are three types of candidates:
    1. Local (or Host candidates) — the actual IP address bound directly to the remote client’s host operating system. It is "highest preferred" candidate option; and attempted first.
    2. Reflexive (STUN) — the public IP address assigned to the client’s immediate firewall perform network address translation. It is "next preferred" candidate option.
    3. Relay (TURN) — the publically accessible IP address assigned to the media relay server which is allocated to the client. If STUN fails; the final option is "relay candidates".
15. There is no way to direct browser to gather only "relay" candidates. Only signalling portion is left to the application developer. Here is a simple workaround to prefer only TURN-candidates:

16. var host      = false;
    var reflexive = false;
    var relay     = true;
    
    peer.onicecandidate = function(e) {
         var ice = e.candidate;
         if(!ice) return;
    	 
         if(host && ice.candidate.indexOf('typ host') == -1) return;
         if(reflexive && ice.candidate.indexOf('srflx') == -1) return;
         if(relay && ice.candidate.indexOf('relay') == -1) return;
    	 
         POST_to_Other_Peer(ice);
    };
    

17. What to install TURN server on your own VPS? Read TURN server installation Guide