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

Aunque hoy en día la telefonía IP funciona a la perfección tanto en el caso de instalaciones de empresas como de usuarios residenciales, la VoIP sigue teniendo un  “lado oscuro” en los múltiples procedimientos empleados para evitar los problemas que causa el NAT, presente en la práctica totalidad de las conexiones a Internet.

STUN_TURN_ICE_0

Estos problemas no se dan cuando la parte de VoIP de la PABX IP se utiliza únicamente para comunicaciones entre extensiones situadas en la misma red interna (LAN), ya que en esos casos los paquetes TCP que llevan la señalización SIP y los paquetes RTP que llevan la voz digitalizada no tienen que atravesar ningún NAT. Esto es lo que sucede en la instalación que tenemos en marcha en el aula de telefonía del Instituto de Formación Profesional Tartanga con la centralita NCP500 de Panasonic.

STUN_TURN_ICE_1

Centralita NCP500 en el aula de Telefonía del Instituto Tartanga

La situación cambia cuando en una instalación como esta se quiere también realizar llamadas IP hacia el exterior de la LAN. Es decir, llamadas a extensiones IP que están en otra red LAN  o hacia teléfonos situados en la Red de Telefonía Básica, utilizando en este caso los servicios de un proveedor de Voz sobre IP que nos permita finalizar llamadas en dichos teléfonos de la Red de Telefonía Básica. En todos estos casos es necesario pasar a través del router con NAT y es entonces cuando aparece un grave problema del protocolo SIP.

STUN_TURN_ICE_3

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 actuación del NAT permite sin problemas la entrada de paquetes IP desde un servidor externo si previamente ha habido una conexión saliente a dicho servidor, ya que el NAT se encarga de crear una asociación entre la IP privada/puerto del lado LAN con la IP pública/puerto del lado WAN. En el siguiente diagrama se muestra la conexión de dos equipos situados en direcciones IP privadas (LAN) con un servidor situado en una dirección IP pública (WAN) a través de un NAT. Por simplificar el proceso se supone que dos equipos situados en la red interna con direcciones IP 10.0.0.1 y 10.0.0.2 se dirigen ambos al mismo servidor público situado en la dirección 202.123.211.25. En ambos casos,  las aplicaciones envían y reciben paquetes sobre el mismo número de puerto, el puerto 80, como es el caso del protocolo HTTP utilizado por los navegadores web.

STUN_TURN_ICE_3A

Se observa que el NAT crea una asociación entre cada IP privada/puerto con una IP pública/puerto. Así por ejemplo, el paquete que sale del ordenador A con IP origen=10.0.0.1 y puerto origen=80 al atravesar el NAT es cambiado a IP origen=202.123.211.25 y puerto origen=10080 y otro tanto sucede con el paquete que sale del ordenador B. Cuando responde el servidor del lado WAN, se dirigirá en ambos casos a la misma IP pública, la 202.123.211.25 pero con diferente número de puerto de destino en cada caso, el 10080 y el 20080. De esta manera el NAT sabe a que ordenador del lado LAN debe de entregar cada paquete que recibe desde el servidor del lado WAN

Se aprecia sin dificultad, que salvo programación manual de un NAT, el servicio NAT permite iniciar comunicaciones desde el lado LAN hacia el lado WAN pero impide iniciar cualquier comunicación desde el lado WAN hacia el lado LAN. Esto es así porque para atravesar el NAT desde el lado WAN hacia el lado LAN es necesario que exista una asociación en el NAT como las vistas anteriormente.

STUN_TURN_ICE_3B

Puesto que el protocolo SIP fue creado pensando que no existiría el NAT y que todos los equipos IP tendrían asignada una IP pública (IPv6), con un NAT de por medio, SIP tiene dos problemas importantes:

  1. No es posible que dos teléfonos IP se envíen paquetes de voz entre sí través de la WAN utilizando las IP privadas de dichos teléfonos. Los paquetes RTP deben de ir dirigidos hacia las IP públicas del lado WAN de los respectivos routers.
  2. Aunque un paquete RTP se dirija correctamente hacia la IP pública de lado WAN de un router, no pasará a través del NAT y no llegará al teléfono SIP de destino si no existe en el NAT una asociación IP privada-puerto/IP pública-puerto. Es decir, si previamente no ha habido una conexión saliente a través de dicho NAT.

En el siguiente diagrama se muestra de forma gráfica ambos problemas: Por un lado, los paquetes RTP no pueden ir dirigidos a una IP privada, ya que dichas direcciones no tienen validez en el lado WAN y por otro lado, aunque se modifique dicha dirección IP privada por la correspondiente IP pública, cuando los paquetes RTP salgan a la WAN a través de su router y alcancen el router del otro extremo,  tampoco podrán atravesar el NAT si previamente no ha habido una conexión saliente que establezca una asociación IP privada-puerto/IP pública-puerto en el NAT.

STUN_TURN_ICE_4

Dos graves problemas del protocolo SIP debidos al NAT

Se puede pensar a primera vista que el primero de los problemas tiene fácil solución si durante la fase de señalización SIP el SIP Proxy informa a cada teléfono SIP de la IP pública y puerto a donde tiene que enviar los paquetes RTP de voz. Pero esta función exige modificar el contenido de los paquetes SIP ya que no es posible hacerlo mediante una simple modificación de direcciones IP en la cabecera de los paquetes SIP por parte del SIP Proxy.

STUN_TURN_ICE_4c

Un SIP Proxy retransmite mensajes SIP entre los extremos pero no los modifica

En el diagrama anterior se observa que si el SIP Proxy intenta informar al teléfono B de la IP pública del teléfono A colocando dicho valor en el campo DIR IP ORIGEN del paquete enviado, entonces la señalización SIP falla, ya que el mensaje de respuesta  OK al mensaje INVITE no llega hacia quien envió dicho paquete, el SIP Proxy. Por lo tanto la IP pública y puerto a donde se deben de dirigir los paquetes RTP de voz la deben de colocar en el interior de los mensajes SIP de INVITE  los teléfonos SIP que quieren intervenir en la conversación. Pero para poder hacer esto es necesario que los teléfonos SIP conozcan los valores de IP pública y puerto con los que salen al lado WAN y para conseguir eso se utilizan  los Servidores STUN (Session Traversal Utilities for NAT), cuyo funcionamiento se muestra en el siguiente diagrama:

STUN_TURN_ICE_5

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 su IP y puerto 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.

STUN_TURN_ICE_6

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 utiliza esos valores para informar al teléfono SIP del otro extremo de la dirección y puerto 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.

STUN_TURN_ICE_7

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.

STUN_TURN_ICE_8

Respuesta de un servidor STUN

Efectivamente, 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.

STUN_TURN_ICE_9

El protocolo STUN es simple y efectivo, y con él resolvemos el problema de como hace un teléfono IP para conocer la IP pública y puerto con los que sale hacia el lado WAN. Pero todavía tenemos el segundo problema: Debe de haber una asociación creada en el NAT para que entren paquetes de voz RTP desde el lado WAN hacia un teléfono SIP que está situado en el lado LAN. Y según el tipo de NAT utilizado, este problema tiene a su vez dos soluciones distintas:

  • Si el NAT es de tipo Full Cone entonces la solución es inmediata. Cualquier paquete RTP de voz con destino a la IP pública-puerto utilizada para la comunicación con el SIP Proxy o con el servidor STUN será enviado por el NAT al teléfono SIP correspondiente. Y esto es así aunque los paquetes RTP de voz provengan de una IP diferente, ya que en el NAT de tipo Full Cone no se examina ni la dirección IP de origen de los paquetes ni el puerto.
  • Si el NAT es de cualquiera de los otros tres tipos, Restricted Cone, Port Restricted Cone o Symmetric entonces es imprescindible además que los paquetes de voz RTP tengan como dirección de origen la propia del SIP Proxy o la del servidor STUN, ya que en estos tipos de NAT solo se dejan pasar paquetes hacia el lado LAN si provienen de la IP pública del lado WAN con la que se ha establecido la conexión de salida. Es decir, los paquetes de voz deben atravesar el SIP Proxy o el servidor STUN, lo cual es algo para lo que, en principio, no está pensado ninguno de los dos servidores.

En el siguiente diagrama se observa el funcionamiento correcto de una comunicación donde se utiliza un NAT de tipo  Full Cone, donde una vez establecida una conexión saliente en el NAT, cualquier dispositivo en el exterior la puede utilizar para enviar paquetes hacia el interior del NAT, como por ejemplo señalización SIP proveniente de un Proxy SIP o paquetes RTP provenientes del otro extremo de una comunicación de VoIP:

STUN_TURN_ICE_11

 Y en el siguiente diagrama se muestra lo que sucede con los otros tres tipos de NAT: Una vez finalizada la fase de señalización SIP no se recibirán paquetes de voz, en uno o en ambos extremos, dependiendo del tipo de NAT en cada extremo.

STUN_TURN_ICE_12Puesto que los SIP Proxy tienen como misión la señalización SIP pero no el transporte de paquetes de voz RTP, la única opción es utilizar el servidor STUN para que, además de la propia función de servidor STUN se encargue también del transporte de los paquetes de voz RTP. A esta solución se la conoce por el nombre de 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.

STUN_TURN_ICE_13

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 simétrico, uno solo de los extremos o ninguno, es necesario comprobar la situación real de NAT de cada extremo para determinar cual es la mejor solución en cada uno de los dos extremos. De esa comprobación se encarga el protocolo ICE (Interactive Connectivity Establishment). Este protocolo 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 muy compleja y que no tiene todavía un soporte muy extendido entre los fabricantes de Router.

STUN_TURN_ICE_14

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.

STUN_TURN_ICE_14_a

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

Aunque puede parecer sencillo el funcionamiento de un SIP-ALG, 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 Application Layer Gateway puede realizar correctamente su trabajo, entendiendo 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.

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.

STUN_TURN_ICE_16

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.

STUN_TURN_ICE_15

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.

STUN_TURN_ICE_17Algunas 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.

STUN_TURN_ICE_18

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.

STUN_TURN_ICE_19

Pero atenciónlos problemas puede ser que todavía no hayan terminado. Para poder establecer la llamada es imprescindible que funcione la fase de señalización y que luego circulen sin problemas los paquetes de voz

1.- Si realizamos la llamada a través de un proveedor de voz IP que cuenta con un SBC, la fase de señalización funcionará sin problemas porque nuestro teléfono SIP o nuestra PBX SIP  se estará registrando de forma periódica en el SIP Register incluido en el SIP Proxy del proveedor de VoIP. Este registro se realiza mediante el envío de un paquete SIP REGISTER a la dirección IP del SBC y al puerto 5060, que es el utilizado por el protocolo SIP para la señalización. Cuando tengamos una llamada entrante, el proveedor de VoIP podrá enviarnos sin problema el mensaje de INVITE ya que nuestro cortafuegos estará abierto para paquetes provenientes desde dicha dirección y puerto.

STUN_TURN_ICE_20

Registro periódico de la centralita NCP500 en el proveedor de VoIP Sarevoz. El puerto utilizado es el 5060 para Sarevoz y el 35060 para la centralita NCP500

2.- Una vez terminada la fase de señalización viene el problema de los paquetes de voz y aquí es imprescindible que en nuestro cortafuegos estén abiertos los puertos involucrados en dicha comunicación. Es decir, en nuestro cortafuegos habrá que permitir la salida de los paquetes UDP generados por nuestro teléfono SIP o nuestra PBX SIP y habrá que permitir también en entrada los paquetes UDP que nos envía el SBC del proveedor de VoIP. Y aquí si que hay un problema importante ya que no es sencillo a simple vista saber cuales son los números de puertos utilizados, tanto por parte de nuestro equipo como por parte del SBC del proveedor de VoIP.

STUN_TURN_ICE_21

Puertos utilizados por la PBX NCP500 de Panasonic. El SBC de Sarevoz utiliza en cambio puertos UDP por encima de 52000

Es decir, en situaciones como estas dentro de la instalación de una PBX IP en una empresa, deberemos de contar inevitablemente con la colaboración del administrador de la red para abrir los puertos adecuados en el cortafuegos. En el caso de una instalación particular, deberemos igualmente de asegurarnos de que los puertos necesarios están abiertos en el cortafuegos. Y si estamos hablando de un softphone instalado en un PC, atención, que también hay un cortafuegos en marcha en el propio sistema operativo. Como se ha indicado al comienzo de esta entrada del blog, la VoIP tiene un lado oscuro que a veces pone las cosas un poco difíciles ……….

STUN_TURN_ICE_22

Para finalizar, nos podemos preguntar si es necesario saber todas estas cosas para trabajar con equipos de VoIP. Desde mi punto de vista, rotundamente SI.  Cuando un Técnico en Sistemas de Telefonía procede a instalar y programar centralitas IP deberá de configurar parámetros y opciones  a los que no encontrará sentido si no conoce previamente, aunque sea en líneas generales, los aspectos básicos de la voz IP, los problemas que presentan los NAT en las comunicaciones con protocolo SIP y las diferentes soluciones técnicas disponibles que se han analizado anteriormente.

Esta entrada fue publicada en Telefonía IP. Guarda el enlace permanente.

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

  1. APARECIDO ROGÉRIO NASCIMENTO DE MORAIS dijo:

    boa tarde

    Como faço pra funcionar os ramais sip externos do alcatel oxo sem vpn na minha empresa possuo um mikrotik rb 750

  2. Enrique dijo:

    Ahora con los UCM o IP PBX con varias funciones tan parecidas a las de los SBC. Puedes comentar cuál sería el escenario en que se requiere un SBC?. Por ejemplo una empresa con varias sucursales? Tiene sentido en una oficina pequeña con 50 extensiones? Saludos.

  3. Enrique dijo:

    Me uno a los compañeros. Gracias. Un gran trabajo.

    Saludos.

  4. Johnny dijo:

    Muchas gracias por la información. Muy buena.

  5. Denis dijo:

    Excelente trabajo!, gracias por tu aporte. Saludos.

  6. Cris dijo:

    Excelente explicación!! gracias porque has resuelto varias dudas que tenía al respecto.

  7. Lorenzo dijo:

    Que explicacion mas buena! Muchas gracias

  8. Marcos Ealo dijo:

    Uff, vaya lección que das en este post. Me has aclarado muchos conceptos que me tenían loco, aunque lamentablemente no he resuelto mi problema. La pregunta final es ¿hay alguna forma de tener telefonía SIP entre equipos ubicados en dos redes locales diferentes sin necesidad de tocar los firewalls? Durante el artículo he estado creyendo que sí, que utilizando un servidor TURN era posible pero al final me ha entrado la duda cuando has hablado de los proveedores de VoIP y de los SBC…. En cualquier caso te has ganado un seguidor

  9. Marcos dijo:

    uff, vaya lección de sabiduría que das en este post. Enhorabuena y mil millones de gracias. Me acabas de aclarar un montón de conceptos, aunque lamentablemente no me has dado la solución a mi problema :-(. Te has ganado un seguidor.

  10. Pablp dijo:

    Muy claro. Muchas gracias por compartir este material

Deja un comentario

Tu dirección de correo electrónico no será publicada.