STUN, TURN, ICE: the Three Musketeers of SIP calling

There is an opinion that the words in the beginning of the header mean the same (like SIP and VoIP as well as dialers and softphones merge together in the mass consciousness). It is not, however, so: STUN, TURN, and ICE are different protocols which are to solve the same task of routing beyond firewalls and NAT (Network Address Translation). The proper protocol choice depends on your network settings, security requirements, and the other factors.

Let’s focus briefly on these technologies.

STUN

STUN (Session Traversal Utilities for NAT) is a client-server protocol which provides a tool for hosts to detect the presence of a network address translator and firewalls. STUN-clients send binding requests to a STUN-server; it responds with a response that contains the IP address and port number of the client, as observed from the server's perspective, for sending voice packets to the corresponding party.

STUN is described in detail in RFC 3489, RFC 8489, and RFC 5780; here we just note the main: in fact, it’s a mechanism of proper addresses detecting for the voice data transmission if it implies different networks built on NAT. This solves such issues as failure to register on PBX, or no-sound-call, or call abort, or no inbound calls issue.

With that, a STUN-server is to be beyond a network where a PBX/softphone is, but this is not always possible. Should some party be outside a symmetric NAT, STUN is not applicable. In this case the floor is given to TURN.

TURN

The protocol known as Traversal Using Relays around NAT (detailed description is given in RFC 8656) is to help devices to interact beyond a symmetric NAT via a “mediator”, namely a TURN-server. In a certain sense, TURN completes STUN; often a STUN server also is a TURN one.

TURN is good in matters of addressing STUN’s shortcomings, e.g. work out-of-symmetric-NAT becomes possible, but necessity of an external server connection still remains. Since data is transmitted via a “mediator” server, this leads to some delay.

So that data would go the best way, there is ICE.

ICE

ICE (Interactive Connectivity Establishment; please see RFC 8445 and RFC 5768) in its turn is an addition to STUN и TURN. Its main purpose is to define the connection way:

• first, it tries to establish a direct connection;
• if that isn’t possible, ICE tries to connect via STUN;
• otherwise it’s a TURN time.

A definite ICE’s plus is simplicity: users don't have to delve into NAT intricacies. On the other hand, it requires more time for connection as it might need sequentially checking all the possible ways.

Softphone, firewall, DNS, and the others

We are quite sure, our thoughtful readers already have extra questions: is it necessary to have their own STUN-servers for calling via a softphone? If yes, how to set it up in Softphone.Pro? What about firewall bypass? DNS records, yet again.

All the answers you will find in the new big article STUN, TURN, and ICE in Softphone.Pro in our knowledgebase. DNS, Linux (on the example Ubuntu Server 24.04 LTS), own server, all there.

Enjoy!

YOU MAY ALSO LIKE

Help STUN, TURN, and ICE in Softphone.Pro

Blog Voip choppy audio: how to quickly find records with stuttering and breaking up

Blog SIP vs VoIP, dialers VS softphones: differences and similarities

Blog Call me maybe… via “sip:”, “callto:”, and “tel:”

Blog How to continue receiving calls when the Android softphone app is in the background or closed

---