Problemas de la VoIP y NAT

La VoIP suele ser muy problemática cuando hay enmascaramiento de direcciones involucradas, el mayor problema es que el protocolo SIP utiliza un puerto para señalización mientras que el audio funciona por otro.

En este artículo explicaremos como funcionan los diferentes tipos de NAT, sabiendo esto podremos elegir el tipo de solución que mejor se adapte a nuestro escenario.

Antes de nada es conveniente aclarar ciertos términos:
- SIP: Session Initiation Protocol
Estándar para la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia.

- SDP: Session Description Protocol
Describe el contenido multimedia de la sesión, por ejemplo qué direcciones IP, puertos y códecs se usarán durante la comunicación. Es un protocolo de señalización.

- RTP: Real-time Transport Protocol
Transmisión de información en tiempo real, como por ejemplo audio y vídeo en una videoconferencia.
- STUN: Simple Traversal Udp through Nat
Averiguar ipWan:puertoWan utilizando un servidor ubicado en Internet.

- TURN: Traverse Using Relay Nat
Servidor utilizado para el relay de tráfico RTP.

- ICE: Interactive Connection Establishment
Algortimo para decidir si STUN o TURN, se prioriza STUN siempre que sea posible por ser mas liviano para los servidores.

- SIP-ALG: Application-Level Gateway
Fué desarrollado para ser utilizado en routers-NAT que inspeccionan el tráfico VoIP y ayudar a reescribir las cabeceras SDP con la información WAN. Desafortunadamente la mayoría de implementaciones están rotas y no funcionan correctamente.

NOTA: Debemos tener en cuenta que el protocolo SIP solo se encarga de la señalización de la llamada no del audio, este se envía mediante RTP por un puerto distinto, además el tráfico RTP no tiene porque pasar por el servidor SIP si no que suele enviarse directamente entre los clientes SIP.

Tipos de NAT

Full cone:
- El tráfico saliente se mapea a la ipWan conservando el puerto, se trata de un nateo 1-1, es decir se necesita una ip wan por cada cliente interno, cualquiera que conozca la ipWan:pWan puede enviarle tráfico al cliente interno.

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:
- El tráfico saliente se mapea a la ipWan conservando el puerto, se trata de un nateo 1-1, solo se permite el tráfico de vuelta al host con el que se está comunicando el cliente, este host externo tiene carta blanca para comunicarse con cualquier puerto del cliente atacando a la ipWan:pWan que desee.

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:
- El tráfico saliente se mapea a la ipWan conservando el puerto, se trata de un nateo 1-1, solo se le permite el tráfico de vuelta al host con el que se está comunicando el cliente, en este caso el host externo solo podrá comunicarse con el cliente mediante el socket original 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:
- El tráfico saliente se mapea a la ipWan mapeando también el puerto de salida, solo se le permite el tráfico de vuelta al host con el que se está comunicando el cliente, en este caso el host externo solo podrá comunicarse con el cliente mediante el socket original 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

Según el tipo de NAT utilizaremos STUN para reescribir las cabeceras SDP con la información WAN, TURN si necesitamos reenviar el tráfico RTP a través de un servidor externo o ICE si queremos que el cliente decida si utilizar STUN o TURN.

Podemos averiguar el tipo de NAT mediante algunas herramientas disponibles en 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

Como servidor STUN/TURN tenemos varias opciones:

La mayoría de servidores SIP solo se encargarán del tráfico SIP dejando que el tráfico RTP viaje entre los clientes directamente, si queremos utilizar servidores TURN debemos realizar configuración adicional, para Kamailio sería nathelper o nattraversal .

En cambio si utilizamos Asterisk el RTP siempre pasará por él a no ser que se indique la opción reinvite en sip.conf, en tal caso en el primer INVITE se pondrá la ip del servidor asterisk en la info SDP para luego enviar un segundo INVITE(reinvite) con la ip del cliente en el SDP.

En Asterisk se puede configurar el parámetro NAT, los diferentes valores son:

yes: Se habilita la RFC 3581 y el RTP simétrico, tanto la transmisión como la recepción del RTP irá por el mismo puerto.
no: Se deshabilita el RTP simétrico y se habilita la RFC 3581 si el cliente lo solicita.
force_rport: Se habilita la RFC 3581 y se deshabilita el RTP simétrico.
comedia: Se habilita el RTP simétrico y se habilita la RFC 3581 si el cliente lo solicita.

Por último dejo el enlace a un vídeo muy interesante sobre la problemática NAT-VoIP:
https://www.youtube.com/watch?time_continue=3&v=9MWYw0fltr0