VoIP and NAT problems

VoIP is often problematic when address masking is involved, the biggest problem being that the SIP protocol uses one port for signaling while audio works on another.

In this article, we will explain how different types of NAT work, knowing this we can choose the type of solution that best suits our scenario.

Before we begin, it is convenient to clarify certain terms:
- SIP: Session Initiation Protocol
Standard for initiating, modifying, and terminating interactive user sessions involving multimedia elements.

- SDP: Session Description Protocol
Describes the multimedia content of the session, such as which IP addresses, ports, and codecs will be used during communication. It is a signaling protocol.

- RTP: Real-time Transport Protocol
Transmission of real-time information, such as audio and video in a video conference.
- STUN: Simple Traversal Udp through Nat
Find ipWan:portWan using a server located on the Internet.

- TURN: Traverse Using Relay Nat
Server used for RTP traffic relay.

- ICE: Interactive Connection Establishment
Algorithm to decide whether to use STUN or TURN, STUN is always prioritized whenever possible because it is lighter for servers.

- SIP-ALG: Application-Level Gateway
It was developed to be used in NAT routers that inspect VoIP traffic and help rewrite SDP headers with WAN information. Unfortunately, most implementations are broken and do not work correctly.

NOTE: We must take into account that the SIP protocol is only responsible for call signaling, not audio. Audio is sent through RTP on a different port. Additionally, RTP traffic does not necessarily have to pass through the SIP server, but is usually sent directly between SIP clients.

Types of NAT

Full cone:
- Outgoing traffic is mapped to the WAN IP address while preserving the port. This is a 1-1 NAT, meaning one WAN IP address is needed for each internal client. Anyone who knows the WAN IP address and port can send traffic to the internal client.

NAT internal side	NAT external side	Direction	Remote machine
INT_ADDR, INT_PORT	EXT_ADDR, INT_PORT	->	REM_ADDR, REM_PORT
INT_ADDR, INT_PORT	EXT_ADDR, INT_PORT	<-	* , *

Restricted cone:
- Outgoing traffic is mapped to the WAN IP address while preserving the port. This is a 1-1 NAT, but only traffic from the host with which the client is communicating is allowed to return. This external host has carte blanche to communicate with any port of the client by attacking the desired WAN IP address and port.

NAT internal side	NAT external side	Direction	Remote machine
INT_ADDR, INT_PORT	EXT_ADDR, INT_PORT	->	REM_ADDR, REM_PORT
INT_ADDR, INT_PORT	EXT_ADDR, INT_PORT	<-	REM_ADDR, *

Port restricted cone:
- Outgoing traffic is mapped to the WAN IP address while preserving the port. This is a 1-1 NAT, but only traffic from the host with which the client is communicating is allowed to return. In this case, the external host can only communicate with the client through the original IP address and port (ipWan:pWan).

NAT internal side	NAT external side	Direction	Remote machine
INT_ADDR, INT_PORT	EXT_ADDR, INT_PORT	->	REM_ADDR, REM_PORT
INT_ADDR, INT_PORT	EXT_ADDR, INT_PORT	<-	REM_ADDR, REM_PORT

Symmetric:
- Outgoing traffic is mapped to the ipWan also mapping the output port, only return traffic to the host communicating with the client is allowed, in this case the external host can only communicate with the client through the original socket ipWan:pWan

NAT internal side	NAT external side	Direction	Remote machine
INT_ADDR, INT_PORT	EXT_ADDR, EXT_PORT1	->	REM_ADDR, REM_PORT1
INT_ADDR, INT_PORT	EXT_ADDR, EXT_PORT1	<-	REM_ADDR, REM_PORT1
INT_ADDR, INT_PORT	EXT_ADDR, EXT_PORT2	->	REM_ADDR, REM_PORT2
INT_ADDR, INT_PORT	EXT_ADDR, EXT_PORT2	<-	REM_ADDR, REM_PORT2

Depending on the type of NAT, we will use STUN to rewrite the SDP headers with WAN information, TURN if we need to forward RTP traffic through an external server, or ICE if we want the client to decide whether to use STUN or TURN.

We can find out the type of NAT using some tools available on the internet:

git clone https://github.com/automation-stack/nat-discovery.git
cd nat-discovery/
linux/nat-discovery

- Discovering NAT type (it may take 5 to 60 seconds) ...
------------------------------------------------------------

 NAT Type: Restricted Cone
 External IP: X.X.X.X
 External Port: 33410

git clone https://github.com/konradkonrad/pystun.git pystun-konrad
cd pystun-konrad/
git checkout research
mv README.md README.rst
python setup.py install
pystun

NAT Type: Restric Port NAT
External IP: X.X.X.X
External Port: 54320

As a STUN/TURN server, we have several options:

Most SIP servers will only handle SIP traffic, allowing RTP traffic to travel directly between clients. If we want to use TURN servers, we must perform additional configuration, for Kamailio it would be nathelper or nattraversal .

On the other hand, if we use Asterisk , the RTP will always go through it unless the reinvite option is indicated in sip.conf. In this case, the IP of the Asterisk server will be put in the SDP info in the first INVITE, and then a second INVITE (reinvite) will be sent with the client’s IP in the SDP.

In Asterisk, the NAT parameter can be configured with different values:

yes: Enables RFC 3581 and symmetric RTP, where both the transmission and reception of RTP will go through the same port.
no: Disables symmetric RTP and enables RFC 3581 if requested by the client.
force_rport: Enables RFC 3581 and disables symmetric RTP.
comedia: Enables symmetric RTP and enables RFC 3581 if requested by the client.

Finally, I leave a link to a very interesting video about NAT-VoIP issues:
https://www.youtube.com/watch?time_continue=3&v=9MWYw0fltr0