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:
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 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
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: