Tal y como comentábamos en su inicio, Asterisk-ES-RSP continua aportando su granito de arena corrigiendo bugs que reporta la comunidad e implementando funcionalidades interesantes, inexistentes en la versión base de esta release.

Para aquellos que aún no lo sepáis, el código fuente de Asterisk se descarga ahora del repositorio de Digium y después son aplicados los parches creados por el grupo. Todo esto se lleva a cabo a través del autopatcher. Después de la descarga del código y la aplicación de parches, la instalación de Asterisk no varía con respecto al método habitual.

Recién salidos del horno, comentamos tres nuevos parches ya commiteados y otros dos a la espera de ser probados por todo aquel que esté interesado en ellos. Esta vez nos hemos centrado en la cara más ‘callcenter’ de Asterisk. Los últimos parches commiteados son los siguientes:

- Bugfix: Solución del segfault generado al hacer una transferencia en asterisk-es-rsp desde una sala de conferencias.

Una pequeña modificación en el parche chan_sip-ironxfers.patch evita los segmentation faults en este escenario.

- Feature: Backport del soporte de shared_lastcall para colas.

Seguramente más de uno de vosotros ha tenido problemas al tener un agente atendiendo varias colas  con diferente tiempo administrativo. Asterisk consulta el tiempo de la última llamada atendida por el agente y verifica si éste es superior al tiempo administrativo (wrapuptime) de la cola que se tiene que atender ahora, sin tener en cuenta el wrapuptime de la cola donde fue atendida.

Desde las versiones más recientes de Asterisk, nos hemos traído esta funcionalidad que hace cuadrar los tiempos administrativos de los agentes en este escenario.

Esta funcionalidad hace que la disponibilidad del agente sea calculada en función del tiempo administrativo de la última cola atendida y no aquel de la cola que se quiere atender.

1 Point!

- Feature: Backport de la opción ‘R’ de la aplicación ‘Queue’.

Para aquellos que buscáis el comportamiento de los callcenters tradicionales, esta funcionalidad hace que el llamante escuche tono de llamada en lugar de música en espera cuando el terminal del agente está sonando.

Ya podéis disfrutar de estás funcionalidades siguiendo estas instrucciones.

Recordad que el branch a descargar sería el siguiente: http://asterisk-es-rsp.irontec.com/svn/asterisk-es-rsp/branches/asterisk/1.4.24.1/autopatcher/

A continuación listamos los nuevos parches subidos al team doktore y que están siendo probados  antes de ser commiteados:

- Feature: Backport de la función QUEUE_MEMBER.

Nos gusta saber si hay agentes disponibles antes de meter la llamada en cola. Por ello hemos añadido esta funcionalidad. Si conocemos la disponibilidad de los agentes antes de entrar en cola, podemos mandar la llamada a otra cola donde sí pueda ser atendida inmediatamente y así mejorar el nivel de servicio. Por otra parte, si sabemos antes de entrar en la cola que todos los agentes están ocupados podemos advertírselo al llamante con una locución antes de ejecutar la aplicación ‘Queue’.

Como aditivo a la función original, este parche hace uso de la funcionalidad shared_lastcall comentada anteriormente para tener en cuenta los escenarios de agentes atendiendo múltiples colas.

- Feature: Mostrar el ’state_interface’ del miembro de la cola al hacer un ‘queue show’ desde el CLI.

Esteroides para complementar el primer parche de asterisk-rsp (app_queue-state_interface.patch). El nuevo parche (app_queue-state_interface-queueshow.patch) nos permite ver desde consola el interfaz de estado de un miembro definido como Local/ y así conocer el terminal desde donde está atendiendo las llamadas. Supongo que aquellos que trabajéis con grandes callcenters lo agradeceréis!

Para aquellos que queráis probar estos dos últimos parches podéis descargaros este autopatcher modificado que los aplica y después instalar Asterisk  del mismo modo que siempre.

Esto es todo! Felicidades a asterisk-es-rsp y gracias por vuestro feedback y vuestros bug reports!

Por fin e conseguido algo de Internet (en Las Vegas mucho casino pero poco WiFi ) y puedo comentar lo que viví durante tres días en el AstriCon.

En una palabra (en inglés): awesome! Creo que no podía haber estado mejor. Me lo he pasado en grande y he tenido la ocasión de conocer a gente muy interesante y de poder intercambiar experiencias con otros tantos AstriFrikis.

El plato fuerte del AstriCon suelen ser las charlas y así ha sido éste año. No obstante, éste año no han ido tan ligadas al lado técnico y he tenido la ocasión de asistir a charlas extrañamente interesantes como por ejemplo chan_skype + Google Wave (con IAX2 de por medio) y el API de calendarios de Asterisk. He podido comprobar (con alegría) que finalmente el API de calendarios de Asterisk no es nada intrusivo con el core y se ha quedado en cuatro resource modules. Bien. También me sorprendió mucho la charla sobre OpenBTS, pero hay charlas y charlas y esa si que era de las segundas.

Otro de los puntos importantes era el hecho de que Asterisk cumpliera 10 años. Se armó una buena fiesta, con concurso, tarta, ¡y salchichas para todos! No faltó de nada, hasta nos dieron una medalla y un collar a lo hawaiano

Por último he de agradecer a todos el apoyo mostrado antes y tras el par de charlas que tuve la ocasión de dar. No me lo esperaba así ni en el mejor de mis sueños, ¡gracias!

A todo esto, ¿ya sabréis donde hay que ir de vacaciones el año que viene no? ¡Al AstriCon 2010!

A menudo cuando una centralita tiene alta carga, ver la consola o los logs que genera Asterisk en /var/log/asterisk/messages no es suficiente. Porque se genera gran cantidad de información, porque al tener muchas llamadas concurrentes seguir una llamada en concreto a través de saltos en un fichero es complicado, porque a medida que integramos más y más herramientas con Asterisk las llamadas ya no se controlan o se localizan en un único punto…

Lo que vamos a intentar es tener controlado el log de todo el sistema, incluyendo Asterisk, su dialplan, los agis y cualesquira herramientas que usemos. Los objetivos son claros:

• Tener todos los logs relevantes en un lugar unificado de tal forma que podamos seguir la pista a las llamadas o a los errores sin tener que hacer merges mentales de múltiples fuentes.
• Tener los logs marcados y clasificados de tal forma que podamos encontrar de forma cómoda y sencilla cualquier información puntual que necesitemos.
• Loguear todo lo que ocurre en la plataforma remotamente relacionado con el flujo de las llamadas y el correcto funcionamiento de las mismas.

En este post vamos a ver un ejemplo de cómo hacer esto con un criterio arbitrario. Se pretende que cualquira pueda adaptar este ejemplo a sus necesidades. En este ejemplo vamos a querer:

1. Los logs generales del sistema para ver que todo es correcto. Esto es, el syslog. Deberemos filtrar cúales de los servicios del sistema que loguean al syslog queremos ver y cuáles no.
2. Los logs relacionados con el flujo de una llamada. En este caso vamos a suponer que dialplan y agis.

Todo esto lo vamos a hacer a través del syslog del sistema y las opciones que nos brinda para filtrar y etiquetar los logs.  ¡Manos a la obra!

(más…)

Ya solo quedan unas pocas horas para que de comienzo el décimo AstriCon, el AstriCon 2009 y he de confesar que algo nervioso sí que me encuentro.

Éste año se celebra la décima edición, por lo que el evento promete. Habrá charlas (como siempre) pero se ha reducido la concurrencia, ya que el año pasado había demasiadas a la vez. También tendrá su sección de expositores, donde diversas empresas expondrán sus productos y servicios. ¡Y el AstriContest!, el concurso de dialplan que éste año se realizará con terminales analógicos (are you from the past?!) y que como primer premio tendrá un terminal con Android libre. ¡Habrá que intentarlo!

Además de porque es la décima edición y porque repito (el año pasado también tuve la suerte de poder venir) éste año el AstriCon me hace especial ilusión, porque en el call for papers me aceptaron ¡dos charlas! ¡El día que recibí el mail de John Todd no pude ni dormir! Por suerte las tengo el segundo y el tercer día, así mañana puedo ir viendo cómo va el tema

Aprovechando que he venido sólo (éste año Manwe no me acompaña y he venido con familia, pero se quedan en San Francisco) voy a sacar el FanBoy que hay en mi, que una vez al año no hace daño.

Subiré fotos, twittearé, bloguaré, … vamos un eco-pack del Web2.0, stay tuned!

Los lectores que seguís de forma activa las noticias de la comunidad de Asterisk habréis leído las discusiones suscitadas por las últimas versiones publicadas. Las versiones 1.4.2X han resultado ser bastante decepcionantes en cuando a estabilidad y la comunidad hispana, en la que nos hallamos la mayoría de integradores de Asterisk, se ha revolucionado bastante con interminables discusiones sobre el modelo de desarrollo de Asterisk, el control de calidad de las versiones y la inversión en tiempo==dinero empleados cercando y solventando estos problemas.

Es por ello, que a raíz de unas de estas discusiones se decidió crear el grupo de asterisk-es-rsp, como un proyecto de la comunidad hispana para unificar nuestros esfuerzos en tener una solución común probada, estable y participada por todos.

Asterisk-RSP NO es un fork de Asterisk. Es un branch en el que empresas y particulares aportamos parches y testing con el fin de disponer de una versión base de Asterisk realmente testeada y adaptada a las necesidades de la comunidad.

Después de varias semanas de desarrollo, el proyecto comienza a dar sus frutos. Actualmente existe un branch principal de Asterisk 1.4.24 y dahdi-linux+dahdi-tools que incluye bastantes bugfixes y funcionalidades extra respecto a la versión 1.4.24 original. Algunas de ellas contemplan:

• Soporte de RDSI BRI (tarjetas Digium, OpenVox, Beronet y Junghanns) mediante DAHDI.

• App_pickup2

• Queue_log realtime mediante UnixODBC

• Montones de bugfixes portados de las versiones 1.4.25, 1.4.26RC1 y svn-trunk

• func_devstate

• PickUp en terminales Thomson

Para aquellos que quieran participar o informarse sobre el proyecto existe una lista de correo en la que se discute el desarrollo del mismo. Un wiki está en construcción (aún está muy verde) para documentarlo, pero como siempre el log de svn es lo más actualizado que se puede encontrar.

Para descargar las fuentes:

svn co http://dev2.irontec.com/svn/asterisk-es-rsp/branches asterisk-es-rsp - -username guest - -password guest

svn co http://asterisk-es-rsp.irontec.com/svn/branches asterisk-rsp

Para ver el log:

svn log http://dev2.irontec.com/svn/asterisk-es-rsp/branches  - -username guest - -password guest

http://asterisk-es-rsp.irontec.com

Al igual que el año pasado, iré posteando a día vencido las idas y venidas de los alumnos y de los “infiltrados” para que los que no hayan podido venir se hagan una idea de lo que por aquí se cuece.

Ayer fue el primer día, día de presentaciones. Los alumnos no se conocían los unos a los otros pero al estar sentados juntos a medida que avanzaba la clase se hacían preguntas entre ellos y cooperaban en la resolución de problemas, eso mola

Espero que hayan dormido bien, porque hoy empieza lo duro: dialplan a tope, y conceptos más profundos de VoIP, ya que ayer sólo vimos lo imprescindible como para configurar un Asterisk con dos terminales que pudieran llamarse entre ellos.

He de decir que el nuevo temario está bastante bien y se tratan con mayor profundidad algunos temas como el NAT, que cuando yo hice el BootCamp ni me mencionaron. También vamos metiendo algún bonus como el uso de ngrep para examinar trazas SIP, y así la cosa se pone más interesante

Seguiremos informando…

PD: Tenéis todas la fotos que vaya sacando en Flickr.

Como se puede apreciar en las imágenes, ya tenemos todo listo para par el pistoletazo de salida al Asterisk Advanced Bilbao 2k9.

Éste año han cambiado algunas cosas como el nombre (antes era Asterisk Bootcamp) y la versión de Asterisk, ya que en esta ocasión utilizaremos Asterisk 1.6, pero la ilusión es la misma.

El trabajo que nos ha llevado montar la sala no es nada comparado con el que van a realizar los asistentes en esta semana intensiva de Asterisk Esperemos que al final de la semana la familia de dCAPs cuente con nuevos miembros.

Al igual que el año pasado, haremos un post diario sobre la marcha del curso en este blog y por supuesto que no faltará el Asterisk Night Adavnced

¿Te lo vas a perder?

Esta vez bajo el nombre Asterisk Advanced, pero volveremos a tener formación oficial de Digium en Bilbao!

Avanzada7 e Irontec organizarán el próximo curso Asterisk Advanced, que tendrá lugar en Bilbao del 20 al 24 de abril. El año pasado la experiencia fue muy buena así que tenemos el listón alto pero esperamos superarlo en esta ocasión.

La pregunta que muchos tendrán es “¿voy o no voy?”. Personalmente diferencio dos tipos de perfiles de usuarios como asistentes a los BootCamp:

• Usuarios con conocimientos básicos de Asterisk. Éstos usuarios han conocido Asterisk hace poco y acuden al BootCamp para adquirir conocimientos sobre VoIP y Asterisk.
• Usuarios con conocimientos medios o avanzados de Asterisk. Éstos usuarios ya llevan tiempo trabajando con Asterisk y suelen acudir al BootCamp para profundizar y afianzar aún más sus conocimientos.

Si crees que perteneces a alguno de los tipos de usuarios arriba mencionados, deberías venir.

La otra duda de los asistentes suele ser si presentarse o no al examen para la certificación dCAP. Mi recomendación es presentarse ya que en Internet no hay mucho material disponible sobre el examen, y lo mejor es verlo por uno mismo.

El año pasado ya tuvimos algún extra como el Night BootCamp y para este año ya se nos van ocurriendo ideas así que quien venga no espere dormir en toda la semana… ¡nos vemos en abril!

Happy Asterisk learning!!

Todos los que llevamos algún tiempo con Asterisk hemos tenido que pegarnos alguna vez con su sistema de colas. Las colas de Asterisk no son sencillas de manejar  ya que disponen de decenas de opciones para variar su comportamiento.

Uno de los parámetros de configuración más importantes para las colas es la estrategia (strategy), que define la forma en la que las llamadas serán repartidas entre los agentes.  En Asterisk 1.4 podemos elegir entre las siguientes estrategias:

• Leastrecent: Asigna la siguiente llamada al agente que más tiempo lleve sin atender una llamada.
• Fewestcalls: Asigna la siguiente llamada al agente que menos llamadas haya atendido.
• Random: Asigna la siguiente llamada aleatoriamente a cualquier agente disponible.
• Ringall: Llama a todos los agentes a la vez y el primero que descuelgue será quien atienda la llamada.
• RoundRobin: Distribuye las llamadas “por turnos” entre los agentes disponibles. (No disponible en Asterisk 1.6)
• RRMemory: Similar a RoundRobin, pero “recuerda” el último agente al que intentó llamar.

Además de la estraegia hay muchos parámetros que condicionan la distribución de las llamadas, como ringinuse, weight, etc, pero no es necesario adentrarnos en eso

La forma que tiene Asterisk de guardar en memoria los agentes de las colas es mediante una función hash. Esta función hash calcula un valor numérico en base a la interfaz del agente (por ejemplo Agent/1001 o SIP/1002). El valor devuelto por la función hash siempre va a ser el mismo, por lo que con ninguna de las estrategias arriba descritas podemos decidir un orden estricto de distribución de llamadas basado en el orden de login (sin hacer trampas ).

Para solucionar esto, Asterisk 1.6 implementa la estrategia “linear” que distribuye las llamadas de manera similar a RRMemory, pero siguiendo el orden en que los agentes se han unido a la cola.

Muchos encontramos esta estrategia particularmente interesante, pero desafortunadamente sólo está disponible para Asterisk 1.6. Tras buscar en el bugtracker de Digium, las listas de Asterisk-Developers y Asterisk-ES no he encontrado un backport de esta estrategia que funcione correctamente en Asterisk 1.4. Así, Manwe y yo hemos hemos hecho un backport de la estrategia “linear” para Asterisk 1.4.

El parche se aplica correctamente con Asterisk 1.4.23.1 y todas las pruebas realizadas han sido satisfactorias Aqúi lo tenéis: app_queue-linear-strategy

Happy Asterisk hacking!

Todos los que nos dedicamos a esto de Asterisk hacemos nuestros pinitos con mon, nagios, snmp y similares para atender nuestras centralitas y saber cuándo algo va mal. Este tipo de monitorización, depende del soporte que se haya vendido, no le importa al cliente ya que a él sólo le importa que la centralita funcione. Pero hay algunas estadísticas que sí que le pueden interesar al cliente, como saber cuántas llamadas concurrentes suele tener, si las licencias de su ASR están en uso por picos o de forma constante, si el balanceo de sus primarios está correctamente hecho o si por el contrario estamos saturando alguno… etc. Me refiero a estadísticas de uso de los recursos de Asterisk.

Esto no es nada nuevo. Hay multitud de programas y desarrollos a medida que nos permiten monitorizar estos casos y que nos generan gráficos y estadísticas en flash, con animaciones y todo. En este post vamos a hablar de Munin como sistema de monitorización de la centralita.

Para los que no lo conozcan, Munin es un sistema que nos genera gráficos de cualquier cosa que podamos imaginar: Uso de la CPU, colas del MTA, queries de Mysql, uso de la swap, uso de la RAM… todo a base de unos sencillos plugins.

Para usar munin no tenemos más que instalar los paquetes correspondientes:

apt-get install munin munin-node apache2

Una vez hecho esto esperaramos hasta 5 minutos para que munin genere las primeras imágenes y al acceder a la URL http://localhost/munin ¡SORPRESA! Tenemos un fea y anticuada web maquetada con tablas en la que a medida que pase el tiempo veremos cómo van dibujándose gráficos referentes a los recursos y servicios que tengamos instalados.

Por defecto munin trae bastantes plugins de monitorización de servicios. Los plugins en el caso de Debian se guardan en /usr/share/munin/plugins y se activan mediante enlaces simbólicos en /etc/munin/plugins/ y configuran en /etc/munin/plugin-conf.d/munin-node. Claro que hasta ahora no ha hecho falta tocar nada de todo esto porque funciona de serie.

Ya tenemos un sistema que genera gráficas de los servicios típicos que tenemos en un servidor GNU/Linux. Ahora sólo falta la parte de monitorizar asterisk usando los plugins que no vienen de serie con el programa.

En la web de munin podemos encontrar plugins generados por los usuarios. A partir de un plugin genérico que se conecta al manager de asterisk, mete un comando y parsea la respuesta podemos sacar casi todas las estadísticas que nos interesen: Canales zap, misdn, sip, iax, llamadas simultáneas, licencias G729 en uso…

Veamos un ejemplo de un plugin de munin que vía Manager saca las llamadas concurrentes en el asterisk:

Como puede verse leyendo un poco el código, la base del script es siempre el mismo, datos, establecimiento de la conexión… etc. Con sólo cambiar unas pocas líneas podemos ir sacando y monitorizando toda la información que deseemos. Las líneas clave serían:
$pop->print("Command: core show channels"); Donde metemos el comando que queremos.
$result = $line if $line =~ /active call/; Es la línea que tiene el resultado que queremos. Si ejecutamos a mano un asterisk -rx "core show channels" podemos ver que la respuesta es del estilo
root@pbx:/etc/asterisk/dialplan# asterisk -rx "core show channels"
Channel Location State Application(Data)
SIP/sarenet-09130f90 946571015@default:1 Ringing AppDial((Outgoing Line))
SIP/2627-b32fade0 s-VOIP@macro-salient Ring Dial(SIP/sarenet/946571015|80|
SIP/2100-08f814c0 2100@desde-usuarios: Ringing AppDial((Outgoing Line))
SIP/2652-b2cdd190 s@macro-llamadainter Ring Dial(SIP/2100|45|Tt)
SIP/sarenet-08b4d478 (None) Up Bridged Call(SIP/2404-b2ff03f0
SIP/2404-b2ff03f0 s-VOIP@macro-salient Up Dial(SIP/sarenet/943446826|80|
mISDN/1-u981 s@ivr-operadorbuzon: Up BackGround(locuciones/EUS_IVR_
SIP/sarenet-082f7388 (None) Up Bridged Call(SIP/2612-089c0d50
SIP/2612-089c0d50 s-VOIP@macro-salient Up Dial(SIP/sarenet/944806571|80|
9 active channels
5 active calls Está claro que en el caso de querer monitorizar las llamadas concurrentes a lo largo del tiempo lo que nos interesa es la línea última que es la que tiene el número de llamadas concurrentes en ese momento. Una vez tenemos la línea en la que está la información lo único que hace falta es sacar el dato de esa línea y sacar el resultado en el formato que a munin le interesa:
my $nb = (split ‘ ‘,$result)[0];
print "channels.value $nb\n";
De hecho, si ejecutamos el script a mano desde la consola lo que veremos será la salida que se le pasará a munin cuando éste ejecute dicho script de forma periódica:
root@pbx:~# /usr/share/munin/plugins/asteriskcalls
Response: Success
Message: Authentication accepted
Response: Follows
Privilege: Command
Channel Location State Application(Data)
mISDN/1-u994 s@macro-getcallerid: Ringing AGI(getcallerid.php|943085756)
SIP/sarenet-08e41cd0 (None) Up Bridged Call(SIP/2626-b318d338
SIP/2626-b318d338 s-VOIP@macro-salient Up Dial(SIP/sarenet/630642987|80|
SIP/sarenet-08b4d478 (None) Up Bridged Call(SIP/2404-b2ff03f0
SIP/2404-b2ff03f0 s-VOIP@macro-salient Up Dial(SIP/sarenet/943446826|80|
SIP/sarenet-082f7388 (None) Up Bridged Call(SIP/2612-089c0d50
SIP/2612-089c0d50 s-VOIP@macro-salient Up Dial(SIP/sarenet/944806571|80|
7 active channels
4 active calls
channels.value 4
Si nos fijamos en el principio del script podemos ver que “channels.value” es el valor que le interesa a munin para hacer la gráfica ya que hemos puesto “channels” en la vertical.

Este script hace las cosas bien, con manager y todo. Pero no tenemos por qué limitarnos a eso. Al final munin sólo quiere un valor para un campo vertical que irá pintando a lo largo del tiempo. Podemos hacer cosas menos bonitas y más imaginativas. Ejemplo de uso de un primario que pertenece a un grupo de varios:

Muchas veces este sencillo programa, que hace gráficas feas, pero que es muy sencillo de instalar y de configurar puede salvarte la vida ya que puedes ver que los últimos días ha habido errores en eth0, que las querys de mysql han aumentado demasiado, que las interrupciones están por las nubes… y te permite diagnosticar momentos de congestión o fallos pasados que no son posibles reproducir en el presente.