A STUN (Session Traversal Utilities for NAT) server allows NAT clients (i.e. IP Phones behind a firewall) to setup phone calls to a VoIP provider hosted outside of the local network.

The STUN server enables clients to find out their public IP address, NAT type, and the Internet-facing port associated by the NAT device with a particular local port. This information is used to set up a UDP communication session between the client and the VoIP provider to establish a call. The STUN protocol is defined in RFC 3489.

The STUN server is contacted on UDP port 3478, however the server will also ask clients to perform tests on a secondary IP and port number also associated with the server. The RFC states that this port and IP are arbitrary.

 

SingleComm's usage:

At SingleComm, we use port 19302, and use Google's STUN servers.
   URI's:              (found here:  https://help.singlecomm.com/hc/en-us/articles/229708128 )

	Port	URI
STUN Server (Main LB)	19302	stun.l.google.com
STUN Server	19302	stun1.l.google.com
STUN Server	19302	stun2.l.google.com
STUN Server	19302	stun3.l.google.com
STUN Server	19302	stun4.l.google.com

Because the devices we typically connect to are behind a NAT device, a request for the IP address of the computer will most likely return a local IP instead of the public IP and port that must be used to direct voice data to a client over the Internet. To work around this, a STUN server that is located outside of the NAT network is used to relay the public IP address back to the device that requested it.

 

 

Overview:

1. Bob indicates (through the web UI) he is ready to start a session with Alice

2. Bob’s web application interacts with the browser API to prepare a peerConnection

3. Bob’s browser returns a set of data representing the details of Bob’s session offer, including the layer 3 information regarding where it is prepared to receive session data

4. Bob’s web application signals (through any number of means) the offer to Alice’s web application

5. Alice’s web application notifies Alice of the incoming session request, and Alice indicates (through the web UI) that she wants to accept the session

6. Alice’s web application prepares it’s peerConnection, and provides Bob’s offer

7. Alice’s browser returns a set of data representing the details of Alice’s session answer, including the layer 3 information regarding where it is prepared to receive session data

8. Alice’s web application signals the answer to Bob’s web application

9. Bob’s web application feeds the answer to the browser's peerConnection

10. The two browsers send session data to the IP address/port each one indicated, and a session is established.

As Bob’s browser prepares it’s peerConnection to Alice's browser (step 2-3), it has no way of knowing what kind of topology it might face during this process. The browser knows it’s local interface IP address and port that it has ready for the session, but doesn’t know what IP and port might exist in a NAT binding created during the connection to Alice's device. Rather than signal one address and port to the other endpoint, the browser goes into a process called ICE candidate gathering to generate a list of potential IP and port endpoints with which to establish a connection on.

This process begins by sending a message to a server on the public internet, using the STUN protocol.
This initial message, called a binding request, originates from the local IP and Port that the browser already has allocated. During this request, the browser asks the STUN server to return the source IP and port that has for the connection. If a NAT device is between the end device and the STUN server, then the response will contain the public IP and port bound by the NAT process. This IP-Port combination is then added to the list of candidates which could potentially be capable of receiving session data.

---

 

ICE stands for Interactive Connectivity Establishment, and it is a technique used by NAT to establish communication channels for VOIP, instant-messaging, and other peer-to-peer or interactive media.

 

 

Related articles:

• Firewall transaction logs 
• STUN the Network – How STUN helps WebRTC Traverse NATs
• Signaling and calling  (this link is about video calling, but most of the material is still relevant)
• Call Center: Firewall and network configuration 
• Freeswitch diagnostics and common issues