Configuración práctica de Asterisk (9ª parte): Canreinvite, Directmedia y las transferencias de llamadas en Asterisk

En un sistema Asterisk la señalización SIP para el establecimiento de una llamada se produce siempre entre el servidor de Asterisk y las extensiones que participan en dicha llamada. Una vez que la llamada ha sido establecida, el tráfico rtp puede circular también a través del servidor de Asterisk o puede circular de forma directa entre las extensiones que participan en la llamada. Ambos sistemas tienen ventajas e inconvenientes:

• Si el tráfico rtp circula directamente entre las extensiones que participan en una llamada, la ventaja es que el servidor de Asterisk no tiene que soportar esa carga de trabajo, que en determinados casos puede ser muy importante, como por ejemplo cuando se trata de una PBX Asterisk con decenas o cientos de llamadas de forma simultánea.

• Si el tráfico rtp circula directamente entre las extensiones que participan en una llamada, el inconveniente es que Asterisk no reconocerá ningún código marcado en las extensiones una vez iniciada la llamada. Por lo tanto, no funcionarán en ningún caso aquellas aplicaciones de Asterisk que se activan mediante determinados códigos de marcado, como por ejemplo las transferencias de llamadas. 

Vemos pues que si queremos que funcionen las transferencias de llamadas y otras funciones que dependen de códigos de marcado (desvíos, no molestar, grabación de la llamada, etc)  es imprescindible que el tráfico de voz (rtp) circule también a través de Asterisk. La activación de esta característica se hacía en versiones anteriores de Asterisk mediante el parámetro canreinvite en el fichero sip.conf. Con la opción canreinvite=yes el trafico rtp circula directamente entre las extensiones que toman parte en una llamada, y con la opción canreinvite=no el tráfico rtp pasará a través de Asterisk. En el siguiente diagrama se muestra un ejemplo práctico de un sistema Asterisk con dos extensiones y la forma en que va el tráfico rtp cuando se ajusta canreinvite=yes y cuando se ajusta canreinvite=no

Cuando se llama desde la extensión 705 a la 706 con el parámetro canreinvite=no, la captura de paquetes mediante un analizador de protocolos de red como Wireshark es la siguiente:

Señalización SIP con la opción canreinvite=no

En la captura anterior vemos en primer lugar que la extensión 705 (10.22.81.22) envía un paquete INVITE al servidor de Asterisk (10.22.81.250) y éste a su vez envía otro paquete de INVITE a la extensión 706 (10.22.81.47). Después de completar la fase de señalización SIP (100 Trying, 180 Ringing, 200 Ok,…..) comienza el tráfico de paquetes rtp entre ambas extensiones pasando a través del servidor de Asterisk, es decir, por la IP 10.22.81.250 . La señalización SIP producida queda representada en el siguiente diagrama:

Señalización SIP en el establecimiento de una llamada

En cambio, si modificamos el fichero sip.conf y ajustamos el parámetro canreinvite a canreinvite=yes, el resultado será el siguiente:

Señalización SIP con la opción canreinvite=yes

Se observa en este caso que el tráfico de paquetes rtp va directo entre ambas extensiones (zona enmarcada en color azul) y se observa también que una vez que la extensión 705 envía el primer INVITE al servidor de Asterisk y éste envía el correspondiente INVITE a la extensión 206, el servidor de Asterisk envía un nuevo INVITE a cada una de las extensiones (zonas enmarcadas en color violeta). Estos nuevos invites son en realidad unos reinvites que efectúa el server de Asterisk a las extensiones  y de aquí viene el nombre tan curioso de este parámetro: canreinvite=yes. 

Si analizamos el contenido de estos mensajes de INVITE podemos ver que cuando el tráfico pasa por el servidor de Asterisk (canreinvite=no), las extensiones que participan en la llamada reciben la dirección IP del servidor de Asterisk como dirección IP a donde tienen que enviar sus paquetes rtp.

Invite del servidor de Asterisk a la extensión 10.22.81.47

En cambio si examinamos el contenido de los mensajes de reinvite (canreinvite=yes) podemos observar que el servidor de Asterisk informa a cada una de las extensiones de la dirección IP de la otra extensión, a fin de que el tráfico rtp pueda ir de forma directa entre ellas:

reinvite del servidor de Asterisk a la extensión 10.22.81.47

reinvite del servidor de Asterisk a la extensión 10.22.81.22

Es importante también tener en cuenta que en determinados casos Asterisk ignorará el ajuste canreinvite=yes y funcionará como si se hubiera ajustado a canreinvite=no. Este comportamiento “autónomo” de Asterisk se dará en los siguientes casos:

1. Si una cualquiera de las extensiones está configurada con la opción canreinvite=no.
2. Si las extensiones que participan en una llamada soportan codecs de voz no compatibles entre sí. En este caso el flujo de paquetes rtp con la voz digitalizada pasará por el servidor de Asterisk y éste realizará la oportuna conversión de codecs de voz. Atención: No olvidar que independientemente de la conversión de codecs que realice Asterisk, en la definición de cada extensión en el fichero sip.conf deberán de estar habilitados los respectivos codecs. Si una extensión trabaja solo con el codec alaw y otra lo hace con el codec ulaw, en la definición de  las extensiones en el sip.conf habrá que indicar allow=alaw para la primera de ellas y allow=ulaw para la segunda.
3. Si en el DialPlan aparece la opción de transferencia de llamada, mediante los parámetros  ”t”, ”T”. Para que Asterisk pueda realizar una transferencia de llamadas tiene que poder detectar el código que introducirá el usuario cuando desee realizar la transferencia y eso solo es posible si el tráfico rtp pasa a través del propio Asterisk.
4. Si en el DialPlan aparece cualquiera de las siguientes opciones “h”, “H” (permiso para colgar la llamada pulsando * al usuario llamante y al usuario llamado), “W”, “w” (permisos para iniciar la grabación de la llamada a la parte llamante y a la parte llamada) “L” (limitación de la duración de la llamada)

Por último, desde la versión de Asterisk 1.6.2, el parámetro canreinvite=yes y canreinvite=no han sido sustituidos por Directmedia=yes y Directmedia=no. El funcionamiento es el mismo pero el nombre refleja con mayor claridad la función que realiza.

Utilización del parámetro directmedia dentro del contexto “general” en sip.conf