Hasta ahora todos los montajes con Asterisk han tenido en común que tanto el servidor de Asterisk como las extensiones IP están situados en la misma LAN. Este tipo de montajes corresponde perfectamente con la situación de aquellas empresas que tienen la PBX en sus propias instalaciones y que se conectan a la red de telefonía pública mediante el servicio ofrecido por proveedores de VoIP. Cuando estas empresas tienen además diferentes sedes o delegaciones, utilizan enlaces IP para permitir llamadas telefónicas entre ellas, tal y como se ha visto en la anterior entrada de este mismo blog.
PBX Asterisk conectadas a través de Internet mediante enlaces IP
Otro enfoque distinto de la telefonía IP es la posibilidad de colocar el servidor de Asterisk “en la nube” y colocar en las redes LAN de cada empresa únicamente las extensiones IP. Este nuevo enfoque aporta, entre otras, las siguientes ventajas:
- Un único servidor de Asterisk para todas las delegaciones de la empresa, simplificando su gestión y mantenimiento.
- Posibilidad de conectar fácilmente extensiones IP de pequeñas delegaciones donde no estaría justificado la existencia de una centralita o incluso de extensiones IP de trabajadores que desarrollan su actividad desde su domicilio particular.
- Posibilidad de externalizar el servicio telefónico con un operador de telefonía IP mediante el alquiler de una centralita “en la nube”, opción muy utilizada hoy en día por todo tipo de empresas.
Asterisk “en la nube”
Como ya se ha visto en la anterior entrada de este blog, cuando se establece un enlace entre Asterisk a través de Internet, los servidores de Asterisk necesitan conocer la IP pública con la que salen al exterior a través del router (parámetro externip en el fichero sip.conf), ya que el protocolo SIP coloca la dirección IP donde se deben reenviar las respuestas a los mensajes en el interior de los propios mensajes SIP. Cuando el Asterisk está situado “en la nube” y las extensiones IP se encuentran en LAN privadas se produce el mismo problema porque cuando una extensión IP envía un mensaje SIP hacia el servidor de Asterisk en la nube, también tiene que colocar en el campo Via del mensaje la dirección IP pública con la que sale al exterior, a fin de que Asterisk pueda enviar la respuesta de forma correcta. Lógicamente en estos casos no es posible configurar algo parecido al parámetro externip en cada una de las extensiones IP que se conectan con el servidor de Asterisk en la nube, teniendo en cuenta además que estás direcciones IP públicas con las que salen al exterior muchas pequeñas empresas y la mayoría de los domicilios particulares son de tipo dinámico y pueden cambiar. La solución que se emplea en estos casos es el uso de un servidor de STUN (Session Traversal Utilities for NAT) cuyo funcionamiento básico fue explicado en esta anterior entrada del blog.
Situación del servidor de Asterisk y del servidor de STUN
Las extensiones IP realizan una petición a intervalos regulares al servidor de STUN y este les envía como respuesta la dirección IP pública y puerto con la que salen al exterior a través del NAT del router, tarea que no supone ninguna dificultad al servidor de STUN, ya que éste ve, en el propio paquete UDP que le envía la extensión, la IP de origen (la IP pública del router) y el puerto de origen (puerto de origen asignado por el NAT).
Para estudiar el funcionamiento de un sistema de este tipo dentro del módulo de Sistemas de Telefonía Fija y Móvil que cursan los alumnos del primer curso del ciclo formativo de grado superior de “Sistemas de Telecomunicación e Informáticos”, en el aula de telefonía del Centro Integrado de Formación Profesional Tartanga hemos realizado el montaje anterior “simulando” la parte WAN, donde hemos colocado un servidor con Asterisk y otro servidor con COTURN, que es un servidor open source de STUN y TURN.
Montaje realizado en el aula de telefonía del CIFP Tartanga
Montaje práctico realizado en el aula
COTURN como servidor de STUN se instala fácilmente en Ubuntu 16.4, la versión de Linux que utilizamos habitualmente en el aula para las prácticas de telefonía IP. Como se ha indicado anteriormente, COTURN funciona como server de STUN, respondiendo a las peticiones de clientes STUN pero también puede funcionar como server de TURN, haciendo de relay para el tráfico RTP entre teléfonos IP. Esta opción será vista en posteriores entradas de este blog, ya que dependiendo del tipo de NAT de los router, puede ser necesario utilizarlo para tener flujo RTP (audio) en los teléfonos.
COTURN en modo “running “
Configuración de COTURN para el arranque automático
A diferencia de los enlaces entre sistemas Asterisk a través de routers, en este caso no es necesario establecer ningún tipo de port forwarding o virtual servers en los respectivos routers. La explicación reside en las dos siguientes características:
- En este sistema las extensiones “salen” hacia el servidor de STUN o hacia el servidor de Asterisk y por tanto las respuestas de estos pueden atravesar sin problemas el NAT de entrada de los routers.
- Aunque se envíe la voz de forma directa entre extensiones IP, sin pasar por el servidor de Asterisk (parámetro directmedia=yes), ambos router tienen un NAT de tipo Full Cone. Esto implica que cualquier paquete dirigido hacia la IP pública / puerto con la que ha salido una extensión IP hacia el exterior previamente, será enviado de nuevo en entrada hacia dicha extensión, aunque dichos paquetes provengan desde una IP pública / puerto a los que no se ha enviado previamente ningún paquete.
No es necesario configurar port forwarding o virtual servers en los respectivos router
Extensión 101 registrada en el Asterisk y con el servidor de STUN configurado
Extensiones 101 y 201 registradas correctamente en el Asterisk
Peticiones y respuestas entre los clientes (extensiones IP) y el servidor STUN
Petición de un cliente (teléfono IP) hacia el servidor de STUN
Respuesta del servidor STUN a la petición del cliente
Mensaje INVITE desde la extensión 101 al servidor de Asterisk
El router hace NAT de salida cambiando la IP de origen del paquete por su IP pública
La ext 201 espera recibir el audio en la IP pública de su router y en el puerto 5062
Una vez que cada extensión ha comunicado a la otra la dirección IP pública y puerto por donde espera recibir el audio, ambas envían un paquete RTP de audio hacia Asterisk colocando como puerto de origen el puerto donde esperan recibir el audio desde la otra extensión.
Paquetes “misteriosos” de audio RTP enviados por las ext 101 y 201 hacia Asterisk
Contenido de los paquetes RTP enviados por las extensiones hacia Asterisk
El envío de estos “misteriosos” paquetes RTP permite que los paquetes RTP de audio que posteriormente envíe la otra extensión a esa dirección IP pública / puerto, sean enviados por el router hacia el teléfono IP que está en el lado LAN, ya que previamente ese teléfono ha salido hacia el exterior por el router con esa IP pública/puerto. Esta forma tan particular de actuar de las extensiones IP se debe a que tienen configurado el servidor de STUN y por lo tanto “saben” que se encuentran detrás de un NAT y que por lo tanto, deben de abrir un “agujero” en el NAT para permitir el paso de los paquetes RTP que les llegarán del otro extremo.
Mecanismo empleado por las extensiones IP para “abrir” un agujero a los paquetes RTP
Otros modelos de teléfonos IP pueden utilizar estrategias distintas para abrir estos “agujeros” en los respectivos NAT. Una solución muy simple es que cada una de las extensiones envía un paquete RTP hacia la otra extensión colocando cada extensión como puerto de origen el puerto donde espera recibir el audio desde la otra extensión. De esta manera, cuando la otra extensión envía paquetes RTP hacia esa IP pública/puerto, el router conoce a que IP privada/puerto interno tiene que enviar esos paquetes.
Otra estrategia para abrir un agujero en el NAT
Tráfico RTP directo entre las ext 101 y 201, sin pasar por Asterisk
El tráfico RTP entre las extensiones circula de forma directa, sin pasar a través del Asterisk. Los paquetes enviados por la ext 101 van dirigidos a la IP “pública” 192.168.1.10 y puerto 5062 y los paquetes enviados por la ext 201 van dirigidos a la IP “pública” 192.168.1.1 y puerto 5060.
Paquete de audio enviado desde la ext 101 a la 201
Paquete de audio enviado desde la ext 101 a la 201
En este caso ha sido posible el tráfico de audio entre las extensiones porque ambos router tienen un NAT del tipo Full Cone, el cual no tiene en cuenta la dirección IP pública de origen o el puerto de origen para aceptar un paquete y enviarlo hacia el interior. Con otros tipos de NAT como los denominados Restricted Cone, Port Restricted Cone, Symmetric, o alguna variante de estos, el problema se complica y en determinados casos solo es posible el tráfico RTP entre extensiones mediante el uso de un servidor TURN que hace las funciones de servidor STUN y de relay de los paquetes de voz.
Full Cone NAT
Nota técnica: En anteriores entradas de este blog, todos los montajes realizados tenían como característica el tener a Asterisk detrás de un NAT y la solución que empleada es suministrar a Asterisk la IP pública con la que sale al exterior mediante el parámetro externip. En esta entrada del blog, por el contrario, son los clientes los que se encuentran detrás de un NAT y el uso de un servidor de STUN es la solución para que conozcan la dirección IP con la que salen al exterior.
No obstante, cuando se analiza el funcionamiento práctico se puede observar que, sorprendentemente, aún sin el uso de un servidor de STUN, la señalización funciona correctamente. Cuando se analizan los mensajes SIP con Wireshark se ve sin problemas que en el campo Via de la cabecera del mensaje aparece una dirección IP local, y sin embargo Asterisk responde a la IP pública desde donde ha recibido el mensaje.
Más aun, los teléfonos SIP de acuerdo con el RFC 3581 pueden incorporar en sus peticiones a Asterisk el parámetro rport en el campo Via, para solicitarle que envíe las respuestas no a la dirección IP de la línea superior del campo Via, sino a la dirección IP desde donde Asterisk ha recibido el paquete IP. Pues bien, si configuramos un teléfono IP para que no envíe ese parámetro rport, Asterisk sigue comportándose como si lo hubiera recibido y envía la respuesta a la dirección IP de origen de la cabecera del mensaje.
Comportamiento de Asterisk cuando recibe el parámetro rport
Dentro de la sección [general] del fichero sip.conf podemos configurar el comportamiento de Asterisk cuando el cliente está detrás de un NAT
Configuración del NAT en el fichero sip.conf
Como se observa en la figura anterior, Asterisk por defecto utiliza nat = auto_force_rport, que significa que, si Asterisk detecta que el cliente está detrás de un NAT, envía la respuesta a la dirección IP de origen del paquete y no a la dirección IP contenida en la línea superior del campo Via. Si seleccionamos nat = force_rport el comportamiento es el mismo, aunque el cliente no envíe el parámetro rport, Asterisk actuará como si lo hubiera enviado. Solamente en el caso de seleccionar nat = no, Asterisk enviará la respuesta a la dirección IP contenida en la línea superior del campo Via, pero en la práctica se comprueba que si esta dirección IP contenida en la línea superior del campo vía es distinta a la dirección IP de origen, Asterisk deduce que el cliente está detrás de un NAT y sigue enviando la respuesta a la dirección .
Cuando las peticiones del cliente llegan a Asterisk a través de uno o varios SIP Proxy, cada uno de los SIP Proxy añade su propia línea Via en la parte superior y entonces Asterisk sabe que la respuesta tiene que ir a la dirección IP contenida en la línea Via superior. Puesto que cuando un mensaje SIP atraviesa un SIP Proxy si que se modifica su dirección IP de origen, de nuevo Asterisk no tiene ningún problema a la hora de responder a una petición, ya que la dirección IP de origen del paquete IP y la dirección IP contenida en la línea Via superior serán las mismas y corresponderán al último SIP Proxy atravesado.
(para más información, consultar la entrada 21 de este mismo blog referente al funcionamiento de la línea Via cuando un mensaje atraviesa un SIP Proxy)
Por último, el parámetro comedia se utiliza para permitir que los paquetes de voz RTP puedan atravesar el NAT desde Asterisk hacia los clientes, pero otras estrategias ya vistas en este blog permiten esto mismo, por lo que habitualmente no es necesario incluir este parámetro en el fichero sip.conf.