La anterior entrada de este blog ha estado dedicada a la puesta en marcha de un enlace SIP entre sistemas Asterisk a través de routers, con simulación de la parte WAN, a fin de poder llevar a cabo el montaje en el aula de una forma sencilla. En esta nueva entrada se lleva a cabo el mismo montaje pero ahora de forma real, a través de sendos routers conectados a Internet.
Esquema del montaje realizado
En este caso ambas localizaciones están conectadas a Internet a través del operador Movistar mediante accesos de tipo FTTH. En una de ellas se utiliza un HGU (Home Gateway Unit) de Mitrastar, modelo GPT-2541GNAC, que es un equipo que incluye el ONT y el router. En la otra localización se utiliza el router modelo HGW-2501 GN-R2, el cual se encuentra conectado al correspondiente ONT. La configuración del enlace SIP es idéntica a la realizada en la anterior entrada del blog donde se llevaba a cabo una “simulación” de la WAN, variando únicamente las direcciones IP públicas que hay que colocar en la definición del enlace SIP y en la variable externip, todo ello dentro de cada fichero sip.conf.
Definición del enlace en uno de los ficheros sip.conf
En el otro extremo del enlace hay una configuración similar, donde la dirección IP del enlace es la 80.29.71.21 y la dirección IP asignada a la variable externip es la que tiene en su interfaz WAN el router, la 79.153.53.128. Como ya se ha indicado en la anterior entrada de este blog dedicada al establecimiento de un enlace sip a través de routers, Asterisk solo sustituye las direcciones IP de los campos Via, Contact y Connection Information de los mensajes SIP por la IP pública señalada por el parámetro externip cuando estos mensajes tienen como destino direcciones IP que no pertenecen a la red señalada por el parámetro localnet. Una vez configurados ambos ficheros sip.conf y efectuados los correspondientes reload desde el CLI de Asterisk, se comprueba que el enlace es alcanzable (reachable) desde ambos extremos.
Comprobación del enlace desde el CLI de Asterisk
Y después de configurar los respectivos dialplan de ambos Asterisk, las llamadas se pueden efectuar con total normalidad en ambos sentidos, funcionando correctamente la señalización y pasando sin problemas por ambos router el tráfico RTP de la voz.
Llamada desde la extensión 101 del Asterisk A hacia la extensión 702 del Asterisk B
En la captura de la figura anterior se observa en primer lugar que la extensión IP situada en la dirección 192.168.1.33 envía un mensaje de INVITE al servidor de Asterisk situado en la dirección 192.168.1.100, con la invitación para participar en una sesión a la extensión 702 situada en el otro extremo del enlace. Una vez que el servidor de Asterisk valida este mensaje de INVITE, lo reenvía hacia el router situado en el otro extremo del enlace, en la dirección IP pública 79.153.53.128 y después de establecerse la secuencia correcta de señalización (mensajes Trying, Ringing y OK ) comienza el tráfico RTP de voz entre ambos servidores de Asterisk y entre el servidor y la extensión que ha iniciado la llamada (en el otro extremo del enlace sucede algo similar).
Contenido del mensaje INVITE
En el mensaje INVITE que envía el servidor de Asterisk hacia el otro extremo del enlace se observa que las direcciones IP situadas en los campos Via, Contact y Connection Information en el interior del protocolo SDP, corresponden a la dirección IP pública del router, como consecuencia del uso de la variable externip en el fichero sip.conf.
Llamada desde la extensión 702 del Asterisk B hacia la extensión 103 del Asterisk A
En esta otra captura se observa la llegada de un mensaje de INVITE desde el Asterisk situado en el otro extremo del enlace. El servidor de Asterisk reenvía este mensaje hacia la extensión IP a la cual va dirigida la llamada y una vez que concluye la señalización, comienza el tráfico RTP de voz.
Contenido del mensaje INVITE
La captura de la imagen anterior corresponde al mensaje INVITE recibido desde la extensión 702 situada en el otro extremo del enlace hacia la extensión 103. De la misma forma que antes, en el protocolo SDP aparece la dirección IP pública del router del otro extremo.
Virtual Servers Setup en el HGU de MitraStar
En el HGU de MitraStar modelo GPT-2541GNAC se utiliza la opción de Virtual Servers dentro del menú de NAT para redirigir todo el tráfico que llega al puerto 5060 UDP (señalización SIP) hacia el servidor de Asterisk, y también se redirige todo el tráfico UDP que llega a los puertos 10000 al 10010 hacia el mismo servidor (tráfico de paquetes RTP de voz).
Port Forwarding en el router HGW-2501GN-R2
En el router modelo HGW 2501 GN-R2 se utiliza para la misma función la opción Port Forwarding, situada también dentro del menú de NAT.
Configuración de la DMZ en el HGU de MitraStar
En un entorno de pruebas puede ser más cómodo usar la opción DMZ (zona desmilitarizada) que incorporan la mayoría de los router. Con esta opción, se reenvía hacia el servidor de Asterisk todo el tráfico que proviene del exterior y que no es respuesta a peticiones realizadas desde el interior de la LAN. 
Configuración DMZ en el router HGW 2501 GN-R2
Como curiosidad, se observa que al estar conectados a Internet se reciben constantes intentos de establecimiento de sesión por parte de servidores SIP externos. Normalmente estos intentos se llevan a cabo con números de extensión aleatorios y este tipo de intentos de conexión se reciben aunque no se haya establecido previamente un enlace SIP con ellos. Como ya se ha visto en una anterior entrada de este mismo blog, podemos prohibir este tipo de llamadas mediante la variable allowguest = no en el fichero sip.conf. En cambio, si se coloca la variable allowguest = yes en el fichero sip.conf, estas llamadas entrarán por el context default del dialplan, donde deberán recibir el tratamiento oportuno.
Intentos de conexión desde servidores SIP externos
Es importante tener en cuenta que si no se indica nada en el fichero sip.conf, la variable allowguest queda configurada por defecto con el valor yes, por lo que todas las llamadas entrantes que provienen de servidores SIP con los que no se ha establecido un enlace, se derivan al contexto default
Llamadas rechazadas por no encontrarse la extensión en el contexto default
NOTA IMPORTANTE: Como se ha indicado en la anterior entrada de este blog (Configuración práctica de Asterisk – 10) si se utilizan routers con modo de funcionamiento “FULL CONE NAT” es posible establecer la señalización SIP a través de los router y el tráfico RTP sin que sea necesario establecer reglas de Virtual Server o Port Forwarding.
Paso de la señalización SIP sin reglas de Virtual Server o Port Forwarding
Paso del tráfico RTP sin reglas de Virtual Server o Port Forwarding