Una de las grandes novedades que traía Asterisk 1.6.2 y que forman parte del gran número de novedades de Asterisk 1.8 es el soporte de un nuevo sistema de logueo de eventos llamado CEL (Channel Event Logging) que, supuestamente viene a solucionar los grandes problemas que tiene el CDR de Asterisk, como cuando se utilizan transferencias SIP en lugar de las transferencias nativas de Asterisk.
Esta característica es seguramente, una de las mejores razones por las que actualizar nuestro Asterisk de 1.4 o Asterisk 1.6.0 a la nueva versión de Asterisk 1.8. ya que son muchas las empresas que utilizan a diario el listado de llamadas realizadas junto con toda la información que suele incluir el CDR y necesitan aún más información o por lo menos, que esta se muestre adecuadamente.
Para que el no lo sepa, el CDR (Call Detail Record) es un registro «log» que gestiona y almacena todo el detalle de llamadas que se realizan a través de Asterisk por lo que, tanto para las empresas que necesitan llevar un control riguroso de llamadas, como para los proveedores que utilizan el CDR de Asterisk para poder facturar a sus clientes, este registro es de vital importancia.
La mayoría de las centralitas traen integrado un sistema que permite extraer el listado de llamadas, así como el resto de sus datos: fecha y hora de inicio de la llamada, duración, origen, destino, si la llamada se ha podido realizar correctamente o si ha ocurrido algún error, etc. Aunque la principal diferencia es que para acceder al CDR, o bien hay que pagar un ‘extra’, necesitar de otro sistema independiente que se conecta a la PBX mediante un puerto serie, y además no es todo lo fiable que debería ser.
El CDR que incluye Asterisk tampoco es una maravilla (aunque en comparación con el resto de sistemas PBX comerciales, es la mayor joya jamás inventada), y es que cuando se realizan llamadas que queremos monitorizar, existen algunas ciscustancias en las que el CDR no sabe interpretar correctamente: Por ejemplo, una transferencia realizada mediante la función SIP REFER (Transferencias SIP) que trae el propio terminal SIP, es algo que el CDR no implementa bien y en estos casos (y más aún si necesitamos facturar dicha llamada) se puede complicar bastante y para estos casos y muchos otros aparece CEL del que vamos a explicaros qué es y cómo funciona…
Muchas empresas optan por desarrollar su propio sistema CDR basado en los eventos del Manager de Asterisk (que como hemos comentado en otros artículos, muestra prácticamente todas las acciones que realiza Asterisk), aunque esto tiene el inconveniente que el Manager también continúa evolucionando y nuestro «sistema» puede dejar de funcionar en versiones de Asterisk más actualizadas, lo que suele desembocar en instalaciones de Asterisk «clavadas» en una versión desactualizada y probablemente con bugs que fueron resueltos en versiones posteriores.
Para evitar esto, a partir de la versión de Asterisk 1.6.2 aparece un nuevo sistema conocido como CEL que almacena todos los eventos que compone cada una de las llamadas que se ejecutan en Asterisk y los almacena en una base de datos (PostgreSQL, ODBC, FreeTDS, Radius, etc.) o en un archivo de texto plano en formato CSV.
La estructura SQL para almacenar los eventos de CEL es la siguiente:
CREATE TABLE cel(
id SERIAL,
eventtype VARCHAR( 30 ) NOT NULL ,
eventtime TIMESTAMP NOT NULL ,
userdeftype VARCHAR( 255 ) NOT NULL ,
cid_name VARCHAR( 80 ) NOT NULL ,
cid_num VARCHAR( 80 ) NOT NULL ,
cid_ani VARCHAR( 80 ) NOT NULL ,
cid_rdnis VARCHAR( 80 ) NOT NULL ,
cid_dnid VARCHAR( 80 ) NOT NULL ,
exten VARCHAR( 80 ) NOT NULL ,
context VARCHAR( 80 ) NOT NULL ,
channame VARCHAR( 80 ) NOT NULL ,
appname VARCHAR( 80 ) NOT NULL ,
appdata VARCHAR( 80 ) NOT NULL ,
amaflags INT NOT NULL ,
accountcode VARCHAR( 20 ) NOT NULL ,
peeraccount VARCHAR( 20 ) NOT NULL ,
uniqueid VARCHAR( 150 ) NOT NULL ,
linkedid VARCHAR( 150 ) NOT NULL ,
userfield VARCHAR( 255 ) NOT NULL ,
peer VARCHAR( 80 ) NOT NULL
);
ALTER TABLE "cel" AND PRIMARY KEY ("id");
ALTER TABLE "cel" AND INDEX ("uniqueid");
Una vez configurado Asterisk con soporte de ODBC siguiendo la documentación que viene con el propio Asterisk (ejecutando el comando ‘make -docdir‘ mientras compilamos Asterisk) y que nos genera un documento PDF en el directorio ./doc/tex/asterisk.pdf donde podemos ver mucha información y tutoriales, que nos ayudará a configurar un acceso ODBC con conexión al motor MySQL.
== Parsing ‘/etc/asterisk/cel_adaptive_odbc.conf’: [Sep 1 17:00:28] DEBUG[15208]: config.c:1335 config_text_file_load: Parsing /etc/asterisk/cel_adaptive_odbc== Found— Found adaptive CEL table cel@MySQL-asterisk.cel_adaptive_odbc.so => (Adaptive ODBC CEL backend)== Parsing ‘/etc/asterisk/cel_adaptive_odbc.conf’: [Sep 1 17:00:28] DEBUG[15208]: config.c:1335 config_text_file_load: Parsing /etc/asterisk/cel_adaptive_odbc == Found — Found adaptive CEL table cel@MySQL-asterisk. cel_adaptive_odbc.so => (Adaptive ODBC CEL backend)
Una vez conectado, al hacer una llamada se almacenarán varios registros, uno por cada evento que realiza Asterisk y por lo tanto nos permite llevar un control exhaustivo sobre todo lo que ha ocurrido en el transcurso de esa llamada, incluyendo quién está implicado y cuando ocurrió.
Event Description
CHAN START The time a channel was created
CHAN END The time a channel was terminated
ANSWER The time a channel was answered (ie, phone taken off-hook, etc)
HANGUP The time at which a hangup occurred.
CONF ENTER The time a channel was connected into a conference room
CONF EXIT The time a channel was removed from a conference room
CONF START The time the first person enters a conference
CONF END The time the last person left a conf (and turned out the lights?)
APP START The time a tracked application was started
APP END the time a tracked application ended
PARK START The time a call was parked
PARK END unpark event
BRIDGE START The time a bridge is started
BRIDGE END The time a bridge is ended
3WAY START When a 3-way conf starts (usually via attended xfer)
3WAY END When one or all exit a 3-way conf
BLINDTRANSFER When a blind transfer is initiated
ATTENDEDTRANSFER When an attended transfer is initiated
TRANSFER Generic transfer initiated; not used yet...?
HOOKFLASH So far, when a hookflash event occurs on a Zap interface
USER EVENT these are triggered from the dialplan, and have a name given by the user
Ejemplo de lo que almacena CEL en una llamada
Viendo los campos de la tabla, uno puede darse cuenta que no existen ciertos campos útiles para la facturación y que sí aparecen en las tablas de CDR: duration, billsec, y algún otro, y es que, aunque CEL parece ser la herramienta perfecta para llevar el CDR, no está pensado para sustituir al CDR de Asterisk, si no para complementarlo y es que esta información, junto con la que almacena el CDR de Asterisk, nos servirá para tener perfectamente definido qué ocurrió durante esa llamada, si fue transferida, a quien y en qué momento. Todo lo necesario para hacer los cálculos necesarios y poder presentarlo de la forma que consideremos más adecuada.
Seguramente, más de uno estará pensando que lo ideal para una empresa que necesite todos los datos de facturación, sería una mezcla entre el CDR y el CEL y puede que tenga razón, aunque seguramente habrá que pensar que esta forma nos permitirá jugar con herramientas propias de las bases de datos como Vistas y Triggers que nos permitirá, (con un poco de tiempo y algunas pruebas, eso sí) obtener absolutamente todo lo que puedas necesitar.