NAT, STUN, TURN, ICE, UPnP, ALG, SBC y otros: El “lado oscuro” de la telefonía IP.

En mayo de 2014 se publicó esta entrada del blog donde se intentaba explicar las principales dificultades que podían aparecer en la telefonía IP, y por ello en el título se añadió esa expresión tan llamativa de “el lado oscuro” de la telefonía IP. Además, para remarcar más aun ese lado oscuro, se añadió a continuación la siguiente imagen 

Casi 8 años más tarde, en abril de 2022, y ya con más experiencia en telefonía IP, esta entrada merece una rectificación: ese supuesto “lado oscuro”, no es en absoluto, ni tan oscuro, ni tan siniestro como la imagen anterior podía dar a entender. El motivo para esta rectificación se debe a que, independientemente de que tengamos NAT en el router de nuestra empresa o domicilio particular e independientemente de que tengamos un firewall más o menos profesional, la instalación, configuración y puesta en marcha de un sistema de telefonía IP es relativamente sencilla en la mayoría de los casos. En el aula de telefonía del CIFP Tartanga LHII hemos trabajado, entre otros, con los siguientes sistemas:

• Instalación, configuración y puesta en marcha de una centralita IP de tipo propietario, como por ejemplo el modelo NCP 500 de Panasonic, con extensiones IP propietarias, extensiones SIP y con un trunk o enlace IP con un operador de voz IP, en nuestro caso, con la empresa Sarenet.
• Instalación, configuración y puesta en marcha de un servidor propio de telefonía IP basado en Asterisk, con extensiones SIP tanto en el interior de la empresa como extensiones SIP situadas en el exterior, y con enlace IP con un operador de voz IP.
• Instalación, configuración y puesta en marcha de un servidor propio de telefonía IP basado en un sistema Asterisk con interfaz web, como es por ejemplo, el caso de Issabel. 
• Instalación, configuración y puesta en marcha de una centralita IP “en la nube”, en nuestro caso con el operador Masvoz.

La primera instalación de telefonía IP que hicimos en la mencionada aula de telefonía se llevó a cabo con una centralita NCP500 de Panasonic, dotada de extensiones IP propietarias, de extensiones SIP y de un enlace SIP con el operador de voz IP Sarenet. Puesto que en esa primera instalación tanto la centralita como las extensiones estaban en la misma LAN, todo fue más sencillo, ya que la comunicación entre la centralita y las extensiones funcionó a la primera, sin producirse ningún problema ni en la fase de señalización de una llamada ni el envío del tráfico RTP de voz. La única dificultad que nos encontramos se dio en la configuración del enlace SIP con el operador, ya que en ese caso si que hay que atravesar el router y el firewall de la organización. Esta dificultad se resolvió desactivando el  SIP ALG que, por defecto, estaba configurada en dicho router.

Primera instalación de un centralita IP en el aula de Telefonía del Instituto Tartanga

El problema más conocido de la telefonía IP y, en concreto del protocolo SIP, es el hecho de la existencia de router con NAT, es decir, que en la mayoría de los casos tanto nuestras extensiones SIP como la centralita IP va a estar detrás de un router con NAT, en la parte LAN, con direcciones IP privadas.

El NAT “mapea” direcciones IP privadas en IP públicas

El servicio NAT se encarga de “mapear” nuestra dirección IP privada, que no puede salir a Internet y solo tiene validez dentro del ámbito de la zona LAN, en una dirección IP pública, que sí tiene validez en internet. Esta función de NAT, habitual en todos los routers domésticos y empresariales, no presenta ningún obstáculo para funciones como, por ejemplo, la navegación por internet, pero si que puede impedir el funcionamiento de un llamada telefónica mediante el protocolo SIP. Esto se debe a que el protocolo SIP se encarga únicamente del establecimiento de la llamada telefónica y, una vez establecida, los paquetes de voz RTP pueden ir de forma directa entre las extensiones IP que intervienen en la conversación, sin tener que pasar por ninguna centralita IP, como la centralita NCP500 de Panasonic o ningún servidor de voz IP como Asterisk. Este hecho obliga a que en el interior de los mensajes de señalización SIP vayan las respectivas direcciones IP de las extensiones IP, y es aquí donde surge el problema, porque estas direcciones IP son privadas y no son alcanzables de forma directa a través de internet.  

Envío de paquetes RTP de forma directa entre extensiones SIP

Lógicamente para que los teléfonos se puedan enviar los paquetes de voz entre sí es necesario que cada uno de ellos conozca la dirección IP del otro. Esta información solo puede transmitirse en la fase de señalización pero necesariamente debe ir dentro del contenido de estos mensaje de señalización, ya que si existe un proxy server que reenvía estos mensajes SIP, en las cabeceras de los paquetes IP solo hay espacio para las direcciones IP de origen y destino.

En las cabeceras de los paquetes IP no hay espacio para colocar las IP de cada teléfono

En el esquema anterior no hay ningún problema si ambos teléfonos y el proxy server están en la misma red, ya que las direcciones IP de los teléfonos SIP serán perfectamente válidas y alcanzables pero, cuando hay un router con NAT por el medio, el problema se complica ya que estas direcciones IP “locales” no serán alcanzables de forma directa. Este es el principal problema de la telefonía IP con el protocolo SIP y las diversas formas de solucionarlo es lo que, durante un tiempo, ha transmitido esa imagen de dificultad y complejidad de la telefonía IP. 

Otro problema de la telefonía IP con los routers se da cuando estos equipos impiden la propia fase de señalización de la llamada al bloquear las conexiones entrante desde el otro extremo. Este problema se puede solucionar con un redireccionamiento de puertos o “port forwarding” en el router (todo lo que venga a esta IP pública y a este puerto, envíalo a esta IP privada y a este puerto….), o bien haciendo que los propios equipos situados en la parte LAN mantengan abierto un “agujero” en el router, por ejemplo enviando paquetes de tipo REGISTER hacia el SIP Proxy. 

Problemas del protocolo SIP debidos al NAT

Para solventar estos dos problemas existen técnicas basadas en servidores de STUN, TURN, el protocolo ICE, el ALG que tienen implementado la mayoría de los router, la función UPnP, que también tienen incorporada muchos router o los denominados SBC (Session Border Controller). Estas técnicas si que constituyen “el lado oscuro” de la voz IP, pero, salvo escenarios de despliegue de telefonía IP muy específicos, en la mayoría de las instalaciones de telefonía IP, donde tan solo se requiere una centralita IP de forma local o una centralita IP en la nube, no será necesario emplear ninguna de esas técnicas para un funcionamiento correcto de la centralita IP. 

Para resolver el problema de las direcciones IP locales en el interior de los mensajes de señalización SIP, la primera técnica consiste en el uso de los llamados servidores de STUN, los cuales permiten a un equipo que está en el lado LAN conocer la IP pública con la que salen hacia el lado WAN o Internet. De esta forma, un teléfono IP o una centralita IP, puede colocar en el contenido de los mensajes de señalización la dirección IP con la que sale al exterior, a fin de que desde el otro extremo se envíen los paquetes de voz RTP a esta dirección IP pública.

Diagrama de funcionamiento de un servidor STUN

Cada uno de los teléfonos que participa en la conversación debe de acceder a un servidor STUN para conocer la IP pública con el que sale al exterior. Lógicamente los servidores STUN se encuentran siempre en direcciones IP públicas conocidas. Un ejemplo claro es el servidor STUN de Zoiper, que es utilizado por los softphones de Zoiper. En la siguiente imagen se muestra la pantalla de configuración avanzada del softphone Zoiper versión 3.2 donde se observan las opciones de configuración del servidor STUN, el cual por defecto es el de la propia Zoiper, es decir, stun.zoiper.com.

Configuración del softphone  Zoiper 3.2

Así, utilizando este servidor STUN, o cualquier otro que esté configurado, el softphone es capaz de encontrar la IP pública con la que sale al exterior y utilizar ese valor para informar al teléfono SIP del otro extremo de la dirección IP pública donde debe de enviar los paquetes RTP de voz. En la captura de pantalla del programa Wireshark se muestra la petición de un softphone de Zoiper al servidor STUN de Zoiper, el cual se encuentra en la dirección IP 82.129.27.63. El protocolo utilizado es CLASSIC, que es uno más de los muchos protocolos que componen TCP/IP.

Petición a un servidor STUN

Y en esta otra captura de pantalla se muestra la respuesta del servidor STUN de Zoiper a la petición anterior. La dirección IP pública del softphone de Zoiper es la 85.60.142.9.

Respuesta de un servidor STUN

Efectivamente, en este ejemplo práctico, si consultamos la información del router detrás del cual está este softphone veremos que su dirección WAN o IP pública es efectivamente la 85.60.142.9. En este caso el router es un SAGEM modelo F@ST 2604 (un router actualmente obsoleto, ya que la prueba práctica fue realizada en 2014)

El protocolo STUN es simple y efectivo, y con él resolvemos el problema de conocer la IP pública con la que sale hacia el lado WAN, pero todavía tenemos el problema de conseguir que estos paquetes RTP de voz puedan atravesar los respectivos routers desde el lado WAN hacia el lado LAN, hacia los teléfonos correspondientes. Como se ha indicado anteriormente, una solución inmediata es establecer una asociación o regla de entrada en cada router (port forwarding o virtual server), que envíe cada paquete recibido en la IP pública del router y en un rango determinado de puertos UDP hacia el teléfono correspondiente de lado LAN. Esto en cualquier caso no es la solución óptima y, además, dependiendo del tipo de NAT del router puede no ser tan sencillo. 

• Si el NAT es de tipo Full Cone, que es el caso más habitual, entonces la regla de entrada funcionará perfectamente ya que en el NAT de tipo Full Cone no se tiene en cuenta ni la dirección IP de origen del paquete ni tampoco el puerto de origen. Si el paquete se dirige a la IP pública del router y al puerto o puertos para los cuales hay un mapeo de entrada, ya sea porque ha habido una salida previa o porque se ha establecido una regla de forma manual, el router dejará pasar el paquete a través de el y lo enviará hacia el dispositivo adecuado del lado LAN, es decir, el que previamente ha salido con esa IP pública/puerto o para el que se ha hecho el mapeo de entrada. 

• Si el NAT es de cualquiera de los otros tres tipos, Restricted Cone, Port Restricted Cone o Symmetric entonces el problema se complica ya que se tiene en cuenta la dirección IP de origen, el puerto de origen o ambas cosas, y eso impide establecer, en la mayoría de los casos prácticos, una regla o mapeo manual, ya que a priori no sabemos desde que IP pública vamos a recibir los paquetes de voz desde el otro extremo. Evidentemente esta solución si sería válida en determinados casos particulares, como por ejemplo en las comunicaciones IP entre una empresa y sus delegaciones,  ya que en ese caso es posible conocer las IP públicas con las que se sale al exterior, pero si una delegación tiene una IP de tipo dinámico, entonces de nuevo habría un problema si en la sede central el tipo de NAT en el router es de uno cualquiera de los tres tipos mencionados anteriormente.  

Funcionamiento del NAT Restricted Cone, Port Restricted Cone y Simmetric

Para evitar el problema de las reglas de “port forwarding” una solución es el uso de los denominados servidores TURN (Traversal Using Relay NAT), el cual consiste en un servidor STUN junto con un mecanismo de Relay o conmutador. La parte STUN del servidor TURN funciona exactamente igual que un servidor STUN estándar y la parte Relay se encarga se reenviar también los paquetes de señalización SIP y los paquetes de voz RTP, de tal forma que puedan entrar por la conexión abierta en la comunicación con el propio servidor TURN. Como se observa en la siguiente figura, la dirección IP pública que el servidor TURN comunica al teléfono IP situado en el lado LAN no es la verdadera IP pública con la que el teléfono sale a internet a través del router con NAT, sino la IP pública del propio servidor de TURN. 

El uso de TURN también tiene sus inconvenientes ya que a simple vista se observa que dicho servidor tiene que estar activo permanentemente durante toda la comunicación de VoIP y además tiene que soportar todo el tráfico de VoIP. Siempre que se pueda, es preferible no utilizar estos servidores TURN. Como en una comunicación de VoIP pueden ser los dos extremos los que tengan NAT diferente a Full Cone, uno solo de los extremos o ninguno, es necesario comprobar la situación real de NAT de cada extremo en cada llamada para determinar cual es la mejor solución en cada caso. Para esta función se ha desarrollado el protocolo ICE (Interactive Connectivity Establishment), el cual realiza una serie de pruebas en los dos extremos que intervienen en la comunicación y determina el tipo de NAT existente y la solución más adecuada en cada caso para saltar la barrera del NAT, decidiendo si tiene que utilizar STUN,  TURN u otra opción. ICE es una solución compleja, que está siendo implementada en la mayoría de los teléfonos IP, tanto teléfonos físicos como de tipo softphone. Un estudio detallado del funcionamiento de ICE se encuentra descrito por Gorka Gorrotxategi en la siguiente entrada del blog de Irontec. 

www.nokia.com

En soluciones profesionales se emplea a veces una solución radicalmente distinta:  los denominados  SIP Application Layer Gateway (SIP-ALG). Estos dispositivos integrados en el propio Router con NAT  examinan el contenido de los paquetes que salen a través de ellos y cuando detectan un paquete  SIP de señalización, modifican su contenido de forma dinámica cambiando la IP privada y puerto que ha colocado el teléfono SIP por la IP pública y puerto por el que sale del router y que el propio SIP Application Layer Gateway conoce . Si se dispone de un SIP Application Layer Gateway, no es necesario utilizar los servicios de ningún servidor STUN, TURN o ICE.  La mayoría de los routers Wifi que se utilizan actualmente en entornos residenciales tienen incorporada esta característica, como por ejemplo el Router Wifi SAGEM F@ST 2604.

Opción SIP-ALG de un router básico

Aunque un SIP-ALG puede parecer una solución eficaz, en realidad es un procedimiento complejo, ya que exige “leer” y “entender” los diversos campos de los paquetes SIP y luego reescribir los valores de direcciones IP y puertos.  Lamentablemente diferentes fabricantes de equipos SIP suelen implementar el protocolo SIP de forma distinta, de tal manera que no siempre el  SIP-ALG puede realizar correctamente su trabajo, por lo que es habitual que “entiendan” de forma incorrecta el contenido de determinados campos de los paquetes SIP de señalización  y reescribiendo dichos  valores de direcciones y puertos de forma equivocada. Por ello, muchos expertos en telefonía IP desaconsejan utilizar esta funcionalidad y, por el contrario, aconsejan desactivar la opción SIP-ALG en los routers.

Para usuarios particulares y pequeñas empresas, otra solución disponible es el sistema Universal plug-and-play (UPnP), que viene integrado en los sistemas operativos Windows y que también permite solventar el problema de los NAT en las comunicaciones de VoIP mediante el protocolo SIP. Este sistema, como su propio nombre indica, proviene del conocido Plug&Play utilizado en Windows para el reconocimiento del hardware y consta de un conjunto de protocolos que permite a los distintos dispositivos de red conocer las características de los demás dispositivos conectados y en el caso de la VoIP permite a un teléfono IP o softphone IP interrogar al router acerca de la dirección IP pública y puerto con el que sale al exterior, sin que sea necesario el uso de un servidor STUN.

Información UPnP de un router básico

UPnP utiliza el protocolo denominado  Internet Gateway Device Protocol (Protocolo IGD) para permitir a un periférico IP (teléfono IP o softphone IP) funcionar a través de un NAT.  La mayoría de los routers y cortafuegos de tipo residencial soportan el protocolo IGD y permiten a los periféricos de red obtener la IP externa del dispositivo, enumerar los mapeos de puertos existentes y añadir o eliminar mapeos de puertos. Un periférico de red situado en la zona privada de la red puede modificar el mapeo de puertos de un router con IGD y permitir el acceso a dicho periférico desde un dispositivo situado en la zona pública de la red.

Logo de la tecnología UPnP

Este sistema UPnP tiene un problema fundamental en la falta de seguridad que supone el permitir a un periférico de red modificar los mapeos de puertos y direcciones IP, eliminando en cierta manera la seguridad ante ataques externos que aporta un cortafuegos debidamente programado. Un software malicioso puede utilizar esta característica para abrir la red interna a un ataque desde el exterior. Por ello, este tipo se soluciones se emplean únicamente en el caso de usuarios residenciales pero nunca en las comunicaciones de empresa.

Algunas de las empresas que forman parte del desarrollo y estandarización de UPnP

Es preciso señalar que cuando utilicemos los servicios de un proveedor de VoIP todo funcionará correctamente y en la mayoría de  los casos no nos tendremos que preocupar  de términos como NAT, STUN, TURN, ICE, ALG y otros.  Hoy en día la mayoría de los operadores de VoIP utilizan los denominados SBC o Session Border Controller. Estos equipos interceptan todas las comunicaciones entre el teléfono SIP del cliente y el servidor SIP Proxy, examinan los paquetes de señalización SIP y modifican su contenido para que el teléfono SIP del otro extremo envíe los paquetes de voz RTP hacia el SBC. Al igual que hacen los servidores TURN, los SBC también realizan la función de relay retransmitiendo los paquetes de voz hacia el teléfono SIP a través del NAT ya que se aprovechan de que previamente ha habido una conexión saliente desde el teléfono SIP hacia el SBC.

Por un SBC pasa la señalización SIP y los paquetes de voz RTP

Además, los SBC tienen otras importantes funciones como son:

1. Adaptar incompatibilidades entre diferentes versiones del protocolo SIP.
2. Adaptar incompatibilidades entre diferentes codecs empleados de audio o vídeo
3. Impedir ataques desde el exterior a los teléfonos SIP.
4. Permitir al operador de VoIP la grabación de llamadas  si hay una orden judicial al efecto.

Como resumen de todo lo anterior, cuando se escribió esta entrada del blog en 2014, eran muchas las dudas que teníamos acerca del funcionamiento práctico de los sistemas de telefonía IP y son estas dudas las que se han intentado explicar aquí. Pero transcurridos ya más de 8 años desde entonces y con la experiencia acumulada de haber instalado múltiples sistemas de telefonía IP, primero con la centralita NCP500 de Panasonic, luego con soluciones de software libre como Elastix, Asterisk o Issabel y, finalmente con centralitas en la nube como la ofrecida por el operador Masvoz, la conclusión es que, salvo casos muy particulares, la instalación, configuración y puesta en marcha de una centralita IP es un proceso relativamente sencillo y la fiabilidad de dichos sistemas está fuera de toda duda, habiendo desplazado hoy en día a todos los sistemas de telefonía basados en líneas analógicas o RDSI.