Utilizar CCSS en Asterisk (parte 4)

Buenas!

En esta última parte vamos a resolver el misterio del posible bug aquél. Igual he dejado tanto tiempo para que penséis que se os ha olvidado de qué iba el rollo pero no es excusa porque podéis visitar las partes anteriores a continuación:

Bien, la movida era entonces que Asterisk está como una cabra y llama aunque la Alice rechace la retrollamada (el callback para los modernos). La solución que le encontramos a esto (digo encontramos porque no fui yo) partía de leer el estado en el que queda la retrollamada.

Es decir, si sabemos si Alice ha colgado o ha cogido, sabremos si seguir adelante llamando a Bob o no.

Lo que acabo de mencionar se divide en dos partes principales, la primera es saber cómo ha respondido Alice a la retrollamada y la segunda es controlar si llamar a Bob o no.

La segunda de estas partes es la fácil, en la parte 2 se habla de la subrutina cc_callback_sub, aunque en la parte 3 se menciona que también puede ser una macro. Con hacer un Hangup en lugar de dejar que la macro termine es suficiente.

La primera parte es la no-evidente, lo cual no quiere decir no-sencilla. Buscando un poco se puede encontrar una funcionalidad de Asterisk para guardar el estado de la última llamada, que es activar la funcionalidad storesipcause. Esto puede hacerse en el archivo sip.conf simplemente añadiendo lo siguiente:

storesipcause=yes

Muy importante mencionar que esto es bastante CPU consuming, que igual no debería utilizarse a diestro y siniestro. Hay que tener en cuenta que si tenemos una centralita con mucha carga de llamadas puede empeorar el rendimiento.

Haciendo esto, conseguimos que se guarde el “sip cause” que podremos ver haciendo un DumpChan en la macro/subrutina de la retrollamada.

Una vez sabido esto vamos al dialplan, a la macro/subrutina y hacemos que cuelgue cuando el resultado no haya sido un “SIP 200 OK”, que es el resultado que da cuando la llamada ha sido aceptada.

Para permitir que la funcionalidad storesipcause se pudiese mantener sin activar (por temas de rendimiento, sobre todo), lo que yo hago es comprobar si la variable existe y que su valor sea el correcto. De todas formas, el posible bug tampoco es tan grave, si la gente hace la retrollamada será para cogerla y si no la coge tampoco es un drama que el otro extremo reciba una llamada. Además, la petición de retrollamada puede cancelarse sin tener que esperar a que Asterisk llame al terminal llamado al CallCompletionCancel (hablo de esto en la parte 1), y realmente, esa sería la buena práctica.

Sin más, añadiendo la siguente línea (o una similar) a lo que tengáis definido como cc_callback_macro o cc_callback_sub es suficiente:

exten => s,n,ExecIf($[${EXISTS(${HASH(SIP_CAUSE,${CHANNEL})})}&&"${HASH(SIP_CAUSE,${CHANNEL})}"!="SIP 200 OK"]?Hangup())

#Nota: Mirad un poco el tema del storesipcause porque para acceder a las variables hay que hacerlo mediante la función Hash etc.

Y eso es todo, espero que haya sido mínimamente interesante todo esto, y prometo volver con más… o no.

Saludos.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s