Configuración práctica de Asterisk (10ª parte): SIP Trunk entre sistemas Asterisk pasando a través de routers

En una reciente entrada de este blog dedicada en exclusiva a  la construcción de un trunk entre sistemas Asterisk se han visto entre otras cosas, lo siguiente:

  • Definición en el fichero sip.conf del enlace SIP. 
  • Configuración en el fichero extension.conf para la realización de llamadas salientes  y para la recepción de llamadas entrantes por el enlace SIP.
  • Parámetro allowguest = yes y allowguest = no para permitir llamadas entrantes desde PBX IP “desconocidas”.
  • Función del parámetro register y otros parámetros necesarios para la conexión de una PBX IP Asterisk con un operador de VoIP (en nuestro caso, con el operador Sarenet).

En el primero de los casos, cuando se establece un enlace SIP entre dos sistemas Asterisk situados en la misma red, no hay ningún problema especial, porque no hay routers intermedios donde sea necesario hacer NAT y tampoco hay firewall que cierran el paso a los paquetes de señalización SIP o a los paquetes de audio RTP. En el segundo de los casos, cuando se establece un enlace SIP entre nuestro sistema Asterisk y un operador de VoIP, comienzan a aparecer los problemas que tiene la voz IP cuando hay que atravesar routers y firewall, pero gracias a la función register y a la existencia de un SBC (sesion border controller) en el lado del operador, los problemas se pueden resolver sin mucha dificultad:

  • Con la función register nuestro Asterisk establece una comunicación a intervalos regulares con el operador de VoIP, lo cual le permite al operador conocer en todo momento la dirección IP pública donde estamos situados en cada momento. Con esta información, cada vez que el operador de VoIP recibe una llamada desde la red de telefonía pública con destino hacia nuestro Asterisk, ya sabe a que dirección IP pública debe enviar el correspondiente mensaje INVITE.
  • Al mismo tiempo, los mensajes de register enviados por nuestro Asterisk hacia el operador de VoIP mantienen abierto un agujero en el NAT de nuestro router, lo cual permite a cualquier paquete enviado desde el operador hacia nuestro Asterisk atravesar el NAT y ser dirigido hacia nuestro Asterisk, sin que haya sido necesario configurar ningún tipo de NAT de entrada en el router. 
  • Los SBC que utilizan los operadores de VoIP envían hacia nuestro Asterisk tanto los paquetes de señalización como los paquetes de voz, por lo que independientemente del tipo de NAT que tengamos (Full Cone, Restricted Cone, Port Restricted Cone,  Symmetric o alguna variante de estos) , los paquetes de voz entrantes desde el operador de VoIP llegarán sin problemas hasta nuestro Asterisk si tenemos la precaución de abrir los correspondientes puertos UDP en el firewall (5060 para la señalización y puertos UDP utilizados por el operador para los paquetes RTP).

Pero cuando se desea establecer un enlace SIP entre dos sistemas Asterisk a través de una red pública como es Internet, surgen nuevos problemas, ya que ahora hay que atravesar routers y firewall y además, no hay mensajes de register que establezcan agujeros en los respectivos NAT y tampoco hay un SBC en el otro lado que facilite las cosas para el paso de los paquetes RTP de voz. Para analizar este problema, en el aula de telefonía del Instituto de Formación Profesional Tartanga  hemos llevado a cabo un montaje que reproduce con fidelidad esta situación:

Esquema del montaje realizado

Los router que hemos utilizado corresponden al modelo Archer C5 de TP-Link. En ambos router se han configurado las direcciones IP del lado LAN y del lado WAN indicadas en la figura anterior y, además, se ha llevado a cabo la siguiente configuración:

  • Para los dos servidores de Asterisk la dirección de gateway o puerta de enlace corresponde a la dirección LAN del router, es decir, la 10.22.81.2
  • Para el router A se ha fijado la dirección de gateway a la 192.168.1.10 y para el router B la dirección de gateway es la 192.168.1.1. De esta forma nos aseguramos de que cualquier paquete que llegue a los router desde el lado WAN se enviará inevitablemente hacia el otro router (Nota: más adelante se llevará a cabo una configuración de estas direcciones de gateway que simula aun mejor el funcionamiento del lado WAN al estilo de como lo hace la red Internet).

Una vez configuradas las direcciones de gateway se pasa a configurar el NAT en cada uno de los router. Para ello, se accede a la opción denominada Forwarding > Virtual Servers.

Configuración del NAT en el router Archer C5 de TP-Link

Para el caso del router A es necesario redirigir el tráfico SIP entrante al puerto 5060 hacia el server de Asterisk.

Configuración del NAT para los paquetes de señalización SIP

Y para el router A también es necesario redirigir el tráfico RTP entrante con origen en el Asterisk B. Para ello en ambos Asterisk se ha configurado el fichero rtp.conf para utilizar únicamente los puertos del 10000 al 10010, por lo que solo es necesario abrir estos puertos hacia el servidor de Asterisk correspondiente. 

Configuración del NAT para el tráfico RTP (paquetes de voz)

En el router B hay que llevar a cabo una configuración similar del NAT, solo que en este caso la dirección IP local donde se debe redirigir la señalización SIP (puerto 5060) y el tráfico RTP (puertos del 10000 al 10010) debe ser la del servidor de Asterisk B, es decir, la 10.22.81.6.

En este sistema de pruebas, la configuración del enlace SIP en ambos ficheros sip.conf es la mostrada a continuación:

Configuración de los enlaces SIP en los ficheros sip.conf

Y en los respectivos dialplan (fichero extensions.conf) se ha realizado una configuración básica para permitir llamadas internas, salientes y entrantes. En la definición de las extensiones de ambos Asterisk dentro del fichero sip.conf se ha utilizado context=erandio.

Configuración de un dialplan básico en ambos Asterisk

Con esta configuración llega el momento de realizar la primera llamada de pruebas, desde la extensión 102 del Asterisk A hacia la extensión 201 del Asterisk B y como era de esperar, comienzan los problemas: la extensión 201 suena pero al descolgar el teléfono no se establece la llamada ni hay voz. Examinando el tráfico con el analizador de protocolos Wireshark, observamos lo siguiente:

  • La extensión 102 envía correctamente el mensaje de INVITE a su servidor de Asterisk, el Asterisk A.
  • El Asterisk A envía correctamente el mensaje de INVITE por el enlace SIP hacia la IP pública del router B, la 192.168.1.10
  • El router B efectúa correctamente la función de NAT y envía el mensaje de INVITE hacia el Asterisk B.
  • El Asterisk B no es capaz de responder hacia el Asterisk A porque el protocolo SIP no tiene en cuenta las direcciones de la cabecera IP sino las direcciones IP que coloca en el interior del paquete (zonas message header y message body) y aquí las direcciones IP que aparecen son locales. En el campo Contact se indica la dirección IP donde Asterisk espera recibir las respuestas al mensaje INVITE enviado hacia el otro extremo del enlace. Como la dirección IP que aparece es una dirección privada, no es enrutable por Internet y no podrá ser utilizada por el Asterisk B para enviar las respuestas al INVITE hacia el Asterisk A. Además como estas direcciones IP son de la misma red en la que está el Asterisk B, este envía la respuesta al INVITE directamente hacia su red y no hacia el router B a través de su dirección de gateway.
  • Conclusión, el Asterisk A no recibe ninguna respuesta al mensaje INVITE enviado hacia el Asterisk B y cuelga la llamada. 

Mensaje INVITE desde el Asterisk A hacia el Asterisk B

Es necesario por tanto que el Asterisk A coloque dentro del paquete INVITE que envía hacia el Asterisk B la dirección pública de su router, que es la 192.168.1.1. Esto se consigue añadiendo en la sección [general ] del fichero sip.conf la siguiente línea:

[general]                                                                                                                                          externip=192.168.1.1

Esta línea le permite al servidor de Asterisk conocer cual es la IP pública con la que “sale” hacia el lado WAN y además coloca está dirección en el interior de los paquetes SIP que envía hacia el lado WAN, para que posteriormente las respuestas sean enviadas hacia esa dirección IP “pública” del lado WAN. Lógicamente en el fichero sip.conf del Asterisk B hay que escribir una línea similar pero ahora con la dirección IP pública del router B, es decir, la 192.168.1.10

Aunque parece que todo es correcto, cuando se prueba de nuevo con una llamada desde el Asterisk A hacia el Asterisk B, la señalización sigue sin funcionar. Al examinar otra vez con Wireshark el paquete INVITE que envía el Asterisk A hacia el Asterisk B, se comprueba que, aparentemente, el parámetro externip=192.168.1.1 no está cumpliendo su función, ya que las direcciones IP que aparecen en el interior del paquete SIP siguen siendo direcciones IP del lado LAN. 

Examinando con cuidado las diferentes opciones de configuración del fichero sip.conf se encuentra que para que funcione correctamente el parámetro externip es necesario configurar también el parámetro localnet=dir IP/máscara de subred. Este parámetro le indica a Asterisk las direcciones IP locales a las que afectará la sustitución por la IP pública del router gracias al parámetro externip. La configuración de la sección general del fichero sip.conf para el Asterisk A queda entonces de la siguiente forma:

[general]                                                                                                                                          externip=192.168.1.1                                                                                                                    localnet=10.22.81.0/255.255.255.0

Y ahora si, cuando repetimos la llamada entre la extensión 102 del Asterisk A y la extensión 201 del Asterisk B todo funciona correctamente, la extensión 201 suena y al descolgar se establece la llamada. Al examinar con Wireshark el mensaje INVITE que recibe el Asterisk B desde el Asterisk A se comprueba que el parámetro externip está cumpliendo con su función ya que la dirección IP de respuesta en el interior del paquete SIP que aparece en el campo Contact es la dirección IP pública del router A. Además, en el protocolo SDP aparece también esta dirección IP pública como la dirección donde se debe enviar el tráfico RTP desde el otro extremo del enlace. 

Nuevo mensaje INVITE desde el Asterisk A hacia el Asterisk B

Pero los problemas no han terminado ………. al descolgar los teléfonos no hay voz en ninguno de ellos. Examinando otra vez el tráfico UDP hacia cada Asterisk mediante el analizador de protocolos Wireshark comprobamos que los paquetes RTP si que están saliendo desde cada Asterisk hacia el otro Asterisk,  pero éstos no lo derivan hacia el teléfono IP correspondiente. El problema en este caso es claro, no está configurado en los ficheros sip.conf el parámetro directmedia=no, y por ello Asterisk se encarga de la señalización pero no gestiona el tráfico de paquetes RTP entre los extremos de la comunicación. Añadiendo la  mencionada línea directmedia=no en la sección [general] de ambos ficheros sip.conf el problema queda resuelto y el tráfico de voz funciona con normalidad. 

[general]                                                                                                                                          externip=192.168.1.1                                                                                                                    localnet=10.22.81.1/255.255.255.0                                                                                         directmedia=no

Y con esto, después de hacer el correspondiente sip reload, el funcionamiento es totalmente correcto.  Las llamadas entre Asterisk se llevan a cabo sin problemas tanto en lo referente a la señalización como en lo referente a la voz. 

Asterisk B

Asterisk A

Los dos Asterisk conectados a través de routers en el aula de telefonía del CIFP Tartanga

Conexiones del lado LAN y del lado WAN en el router B

Conexiones del lado LAN y del lado WAN en el router A

Detalle de la sección [general] en el  fichero sip.conf del Asterisk A

LLamada entrante en el Asterisk 

Un detalle técnico importante a tener en cuenta es que Asterisk solo modifica las direcciones internas de los mensajes SIP mediante el parámetro externip cuando se dirigen a una red distinta a la del propio Asterisk. Es decir, en el ejemplo anterior cuando hacemos una llamada “interna” entre extensiones de una misma centralita, los parámetros externip y localnet serán ignorados por Asterisk, ya que tanto el Asterisk como las extensiones se encuentran en la misma red.  Se puede observar sin dificultad que no tiene ningún sentido que Asterisk coloque en llamadas de este tipo la dirección IP pública del router como dirección de respuesta para la señalización o para recibir los paquetes de voz, ya que la llamada en ningún momento “sale” por el router. 

 

Ámbito de actuación de los parámetros externip y localnet

Esta configuración forma parte de los contenidos impartidos en el módulo de Sistemas de Telefonía Fija y Móvil a los alumnos del ciclo formativo de grado superior de Sistemas de Telecomunicación e Informáticos. La conexión de dos Asterisk a través de una red pública como es Internet se lleva a cabo de forma similar, y solo nos deberemos enfrentar a las dificultades relativas a la configuración del NAT en los router situados en ambos extremos. Puesto que estos router habitualmente tienen una IP pública de tipo dinámico en el lado WAN, será necesario consultar esta dirección IP previa a la puesta en marcha del enlace SIP en los respectivos ficheros sip.conf, cosa que no será necesaria si los router situados en ambos extremos disponen de una IP pública estática en el lado WAN.

Nota:  Se agradece a Jesús Ortíz de Barrón, profesor de electrónica del CIFP Tartanga, la colaboración prestada para el desarrollo de esta actividad.  

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

Deja un comentario

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