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