STUN, TURN and ICE in Softphone.Pro

1. What is STUN and why is it needed?

The parties in the SIP call (let's call them the Agent and the Client) must agree on the addresses to use for transmitting voice data. If both parties have unique IP address, which does not change and is not used by other computers or SIP phones, there are no issues. The Agent and the Client send each other their IPs to establish a direct connection and exchange data (voice packets).

If a direct connection between the Agent and the Client isn't possible, the situation becomes more complicated. For example, the Agent and/or the Client may be in networks (e.g., a corporate network or a home Internet provider's network) that use NAT to provide Internet connection for multiple clients with the same external IP address. It may cause issues such as:

  • the softphone may fail to register with the PBX;
  • one-way audio may occur during calls;
  • calls may drop during the conversation;
  • the Agent may not receive incoming calls.

This happens because the softphone doesn't recognize NAT and reports its local IP address to the other party. Local IP address is not reachable from outside by other client or PBX.

Softphone operation behind NAT

The STUN technology is designed to solve this problem. It allows for the Agent and the Client to use a third-party server to correctly determine each other's IP addresses. Later in the article, different implementations of STUN are described with the info on how to configure them in Softphone.Pro.

2. Are STUN, TURN, and ICE the same thing?

You may have heard terms like ICE and TURN in addition to the aforementioned STUN. What are they?

The quick answer to this question is: STUN, TURN, and ICE are protocols designed to solve the problem of addressing devices behind firewalls and NAT. Depending on your network configuration, security requirements, and other factors, it makes sense to use one or another.

Let's take a closer look at each of these protocols.

2.1. STUN

The operation of the STUN technology is described in detail in RFC 3489, RFC 8489, and RFC 5780. Let's describe the basic principles of this technology.

STUN (Simple Traversal of UDP through NAT or Session Traversal Utilities for NAT) is a client-server protocol that allows applications to detect the presence and type of firewalls and NAT. STUN clients (e.g., the Agent's softphone or PBX) send requests to a STUN server and receive in response the address from which the request came to the STUN server. This IP is sent to the other party in the dialogue for sending voice packets.

How STUN client (softphone) and STUN server interact:

Interaction between softphone and STUN server

The STUN server must be located outside the networks where the Agent's softphone and PBX are located. This may be inconvenient or rather impossible in certain network configurations (e.g., with enhanced security requirements and control over external connections).

Note that the STUN protocol will not work if one or both parties in the dialogue are behind a symmetric NAT. This type of NAT is typically used for security purposes, as the router will only accept connections and transmit data from nodes to which the client has previously connected. The TURN protocol is designed to bypass symmetric NAT.

2.2. TURN

The TURN (Traversal Using Relays around NAT) protocol is designed to work around symmetric NAT. A TURN server acts as an intermediary between two devices that are behind symmetric NAT. TURN is more of a complement to the STUN protocol, and often STUN servers may also function as TURN servers.

Voice packets transmission through a TURN server:

Transmission of voice data through a STUN server

This protocol addresses one of the shortcomings of STUN (allowing operation behind symmetric NAT) but does not address another (the requirement to connect to an external server). It also introduces another drawback - since data (in our example, voice packets) doesn't go directly from one client to another but is instead relayed through another server," this adds latency.

TURN protocol description is available in RFC 8656.

2.3. ICE

ICE (Interactive Connectivity Establishment) protocol is an addition to the STUN and TURN protocols. This protocol attempts to automatically determine which connection method to use:

  1. First, it tries to establish a direct connection between devices.
  2. If a direct connection cannot be established, it attempts to establish a connection via STUN.
  3. If that is also impossible, TURN is used.

The advantage of ICE is simplicity for the end user (they do not need to think about what type of NAT they have or which settings to enable). The disadvantages are inherited from STUN and TURN in addition to noticeable connection setup time (as clients check all possible connection methods before establishing a connection).

The ICE protocol is described in RFC 8445, and its application in the SIP protocol is described in RFC 5768.

3. Do I need to set up my own STUN server for calls via softphone?

There are many STUN servers that can be used in softphones. Usually, the choice of server is determined by the geographical location of the server and the security requirements in your network.

Softphone.Pro by default uses our stun.softphone.pro server, which is pre-configured in the application. Set up and use your own STUN server if your security requirements do not allow the use of third-party STUN servers, or if you want full control over all the infrastructure used by the softphone.

4. How to configure STUN and ICE in Softphone.Pro

By default, Softphone.Pro uses STUN for bypassing firewalls and NAT at stun.softphone.pro. Alternatively you can enable ICE or disable firewall traversal (if the employee's softphone and PBX are on the same network).

4.1. Firewall traversal configuration in Softphone.Pro

Open settings, go to the SIP account settings, and change the value of the Firewall traversal method setting:

  • STUN - use the STUN protocol;
  • ICE - use the ICE protocol;
  • None - disable firewall traversal.

Firewall traversal settings in Softphone.Pro

4.2. Firewall traversal configuration in Softphone.Pro Team

Use Team softphone provisioning feature and add the following to the user configuration file:

To enable STUN add 

[SipAccount1]
FirewallTraversalMethod=STUN

To enable ICE add 

[SipAccount1]
FirewallTraversalMethod=ICE

To disable firewall traversal add 

[SipAccount1]
FirewallTraversalMethod=LOCAL

5. How to set up Linux STUN server

If you want to use your own STUN server (e.g., for security or reliability reasons), you will need to install and configure it. After verifying its operation, you will need to configure DNS records for the server and set the server address in the Softphone.Pro settings.

5.1. How to install and configure your own STUN server

Below is a brief description of how to install and configure STUN server with coturn package for Linux (in the example, Ubuntu Server 24.04 LTS is used). Refer to coturn GitHub page for more information.

You will need a Linux server with a public IP address and superuser access.

5.1.1. Install the coturn server from the repository: 

apt install coturn

5.1.2. The coturn service will install and start. Open the configuration file /etc/turnserver.conf and set the server settings:

  • listening-port: the port on which the server will accept connections via UDP and TCP protocols (default is 3478). This port is needed for DNS configuration;
  • tls-listening-port: the port on which the server will accept connections via the TLS protocol (default is 5349). This port is needed for DNS configuration;
  • external-ip: the public IP address of your server;
  • min-port: the minimum value of the port range opened for UDP connections (default is 49152);
  • max-port: the maximum value of the port range opened for UDP connections (default is 56635);
  • stun-only: if enabled the server operates only in STUN server mode.

5.1.3. Restart the server to apply settings: 

systemctl restart coturn

The server is configured and ready to accept requests to the configured ports. Configure the DNS and specify the server address in Softphone.Pro.

5.2. DNS configuration for STUN

You can configure multiple STUN servers to increase the stability and reliability of the STUN. DNS A records, AAAA records, and SRV records in DNS distribute client requests among multiple servers.

A record associates a domain with an IPv4 server address. AAAA record associates a domain with an IPv6 address.

SRV is a special type of DNS record that allows a single domain to provide services (in this example, STUN) on various servers. This enables flexible infrastructure configuration while maintaining simplicity for the client.

Multiple STUN servers example:

  • Let's assume we have two primary servers with IPs 198.51.100.20 and 203.0.113.30 and a backup server with IP 203.0.113.40.
  • Add A records to DNS for the primary servers with stun1.example.com and stun2.example.com domains and the backup server with stun-reserve.example.com domain.
  • Add A records for stun.example.com domain with the IPs of the primary servers (a fallback mechanism for STUN server IP discovery).
  • Add SRV records for all service addresses.

DNS records example:

Example IPs are used. 

stun1.example.com.			60	IN	A	198.51.100.20
stun2.example.com.			60	IN	A	203.0.113.30
stun-reserve.example.com.		60	IN	A	203.0.113.40
stun.example.com.			60	IN	A	198.51.100.20
stun.example.com.			60	IN	A	203.0.113.30
_stuns._tcp.stun.example.com.		60	IN	SRV	1	0	5347	stun1.example.com.	
_stuns._tcp.stun.example.com.		60	IN	SRV	1	0	5347	stun2.example.com.	
_stuns._tcp.stun.example.com.	60	IN	SRV	2	0	5347	stun-reserve.example.com.
_stun._tcp.stun.example.com.		60	IN	SRV	1	0	3477	stun1.example.com.	
_stun._tcp.stun.example.com.		60	IN	SRV	1	0	3477	stun2.example.com.
_stun._tcp.stun.example.com.	60	IN	SRV	2	0	3477	stun-reserve.example.com.
_stun._udp.stun.example.com.		60	IN	SRV	1	0	3477	stun1.example.com.	
_stun._udp.stun.example.com.		60	IN	SRV	1	0	3477	stun2.example.com.
_stun._udp.stun.example.com.	60	IN	SRV	2	0	3477	stun-reserve.example.com.

Description of SRV record columns:

  1. Service address: consists of the service, protocol, and domain name;
  2. TTL: in seconds;
  3. Class: for SRV records, IN is used;
  4. Record type: SRV;
  5. Priority: clients first process records with lower priority;
  6. Weight: the order of processing records with the same priority depends on the specified weight;
  7. Port: the port for connecting to the server;
  8. Target: the domain name of the destination server.

The port in the 7th column of the SRV record:

  • for the _stun._ service - the port from the listening-port parameter
  • for the _stuns._ service - the port from the tls-listening-port parameter
of the coturn settings.

You can check configured DNS records using the nslookup command. Example command to check the added SRV record _stun._udp.stun.example.com. and A record stun.example.com.:

Example nslookup command

5.3. STUN server address configuration in Softphone.Pro

Set the STUN server address in Softphone.Pro in the SIP settings section, in the STUN server parameter:

Configuring the STUN server address in Softphone.Pro

You can specify multiple servers separated by spaces.

To configure your own STUN server address in the Softphone.Pro Team service, use Team softphone provisioning and add the following to the user configuration file: 

[AppSettings]
StunServers=stun.example.com

You can specify multiple servers separated by spaces.

5.4. DNS discovery of STUN server by STUN client

Recall that we configured DNS by adding the following records: 

stun1.example.com.		60	IN	A	198.51.100.20
stun2.example.com.		60	IN	A	203.0.113.30
stun-reserve.example.com.	60	IN	A	203.0.113.40
stun.example.com.		60	IN	A	198.51.100.20
stun.example.com.		60	IN	A	203.0.113.30
_stuns._tcp.stun.example.com.	60	IN	SRV	1	0	5347	stun1.example.com.	
_stuns._tcp.stun.example.com.	60	IN	SRV	1	0	5347	stun2.example.com.	
_stuns._tcp.stun.example.com.	60	IN	SRV	2	0	5347	stun-reserve.example.com.
_stun._tcp.stun.example.com.	60	IN	SRV	1	0	3477	stun1.example.com.	
_stun._tcp.stun.example.com.	60	IN	SRV	1	0	3477	stun2.example.com.
_stun._tcp.stun.example.com.	60	IN	SRV	2	0	3477	stun-reserve.example.com.
_stun._udp.stun.example.com.	60	IN	SRV	1	0	3477	stun1.example.com.	
_stun._udp.stun.example.com.	60	IN	SRV	1	0	3477	stun2.example.com.
_stun._udp.stun.example.com.	60	IN	SRV	2	0	3477	stun-reserve.example.com.

Let's describe the process that the STUN client (in our case, Softphone.Pro) follows to discover STUN server using SRV records.

  1. The client uses the STUN domain name from the settings and requests an SRV record from DNS:
    • _stun._udp.stun.example.com. (if STUN operates over UDP);
    • _stun.tcp.stun.example.com. (if STUN operates over TCP);
    • _stuns.tcp.stun.example.com. (if STUN operates over TLS);
  2. If SRV records are found, the client receives a prioritized list of addresses (5th column of the SRV record) for the requested service (stun or stuns).
  3. The client begins processing the list in order of increasing priority:
    • In the example, the client first attempts to connect to addresses with priority 1.
    • The address is randomly selected from records with the same weight (6th column of the SRV record). If the weights differ, the address is selected according to the algorithm described in RFC 2782.
    • The address selected for connection is removed from the list for the priority.
    • For the selected address, the client queries DNS and receives an A or AAAA record with the server's IP address.
    • The client attempts to connect to the obtained IP address on the port specified in the SRV record.
    • If the client fails to connect to the server, it attempts to connect to the next server in the list until the list is empty.
  4. If there are SRV records with different priorities, the client repeats step 3 for the next priority.
  5. If no SRV record is found on the server, the client requests A and AAAA records for STUN server domain and attempts to connect to the found addresses using the default ports (3478 for TCP and UDP requests, 5349 for STUN over TLS).

The example record from section 5.2 of this guide will be processed by the softphone as follows:

  1. Let's assume Softphone.Pro connects to STUN over UDP. The softphone is configured with the STUN server address stun.example.com
  2. The softphone queries DNS for the _stun._udp.stun.example.com. record and finds an SRV record with the following address lists:
    • Priority 1: 
      _stun._udp.stun.example.com.  60  IN  SRV  1  0  3477  stun1.example.com.	
_stun._udp.stun.example.com.  60  IN  SRV  1  0  3477  stun2.example.com.
    • Priority 2: 
      _stun._udp.stun.example.com.  60  IN  SRV  2  0  3477  stun-reserve.example.com.
  3. Since the servers in the first list have the same weight of 0, the softphone randomly selects a server from the list and queries DNS for an A record. For example, let's say it selects the server stun1.example.com, and this server is removed from the list for priority 1.
  4. The address lists for the next connection at this point look like this:
    • Priority 1: 
      _stun._udp.stun.example.com.  60  IN  SRV  1  0  3477  stun2.example.com.
    • Priority 2: 
      _stun._udp.stun.example.com.  60  IN  SRV  2  0  3477  stun-reserve.example.com.
  5. The softphone obtains the IP address of the server stun1.example.com from the A record in DNS:
    stun1.example.com.  60  IN  A  198.51.100.20
    and attempts to connect to the STUN server at the specified IP (198.51.100.20) and port from the SRV record (3477) at the address 198.51.100.20:3477;
  6. If the connection fails, the softphone takes the remaining address in the list for priority 1, stun2.example.com, and removes it from the list for priority 1.
  7. The address lists for the next connection at this point look like this:
    • Priority 1: empty list
    • Priority 2: 
      _stun._udp.stun.example.com.  60  IN  SRV  2  0  3477  stun-reserve.example.com.
  8. The softphone obtains the IP address of the server stun2.example.com from the A record in DNS:
    stun2.example.com.  60  IN  A  203.0.113.30
    and attempts to connect to the STUN server at the address 203.0.113.30:3477
  9. If the connection to the second address also fails, the softphone proceeds to the address list for priority 2, as the list for priority 1 is empty.
  10. The softphone takes the only address stun-reserve.example.com and removes it from the list for priority 2.
  11. The address lists for the next connection at this point look like this:
    • Priority 1: empty list
    • Priority 2: empty list
  12. The softphone obtains the IP address of the server stun-reserve.example.com from the A record in DNS:
    stun-reserve.example.com.  60  IN  A  203.0.113.40
    and attempts to connect to the STUN server at the address 203.0.113.40:3477.
  13. If the connection to the STUN server is successful, the softphone uses it to obtain its external IP address and continue operation.

The operation of SRV records in DNS is described in detail in RFC 2782, and STUN server discovery in DNS is described in section 8 of RFC 8489.

See all articles