Registro Llamadas y Eventos

De Asterisk Wiki
Saltar a: navegación, buscar
Alert.png To Do
Esta página necesita ser completada.
Puedes revisar todas las páginas por completar en este enlace.


El registro de llamadas en Asterisk, llamado CDR (Call Detail Record), y de Eventos llamado CEL (Call Event Logging) proveen de múltiples mecanismos de almacenaje de toda la información relativa a las llamadas, con carácter entrante y saliente del sistema, específicamente diseñado para su posible posterior analísis.

Sistema CDR

Como veíamos, CDR, Call Detail Record, es simplemente un registro de todos los pasos que concurren en una llamada, pero con un nivel de detalle bastante reducido.

Introducción

Este sistema es muy práctico cuando queremos saber por ejemplo, a quien llaman nuestros usuarios, o quien los llama, y otros datos relativos a las mismas, como el tiempo establecido, resultado de la llamada (si estaba ocupada o no disponible, o si fue contestada), etc. Es muy similar en cierto sentido al sistema de Estádisticas aplicable a las Colas según puede verse con aplicaciones como Asternic Stats para el manejo de las mismas. Pero es bastante limitado en lo que se refiere a controlar el flujo de la llamada, ya que la cantidad de información que registra es bastante escueta.

Pero en este caso, se aplica para el 100% de las llamadas entrantes y salientes, e inclusive llamadas que se realicen dentro de la máquina Asterisk. Los usos más típicos que suelen darse para este sistema son:

Sistema A2Billing de Facturación
  • Control de Llamadas
  • Sistemas de Facturación a Terceros [1]
  • Análisis y Depuración del Sistema
  • Estadísticas varias.

Para el sistema CDR existen múltiples formas de almacenamiento, principalmente las que hemos comentado, ficheros de texto plano, y diversos tipos de Bases de Datos que hacen referencia:

  • Por defecto, se almacena en un fichero llamado master.csv dentro del directorio /var/log/asterisk/cdr-csv/ en formato como su extensión indica, CSV (Comma-Separated Values, valores separados por comas), siempre que este activada la función de almacenamiento de los CDR en su fichero principal de configuración cdr.conf
  • Es posible Almacenar en Bases de Datos MySQL (fichero de configuración cdr_mysql.conf)
  • En BBDD de Tipo PostgreSQL (fichero cdr_pgsql.conf).
  • También en bases de datos SQLite (fichero cdr_sqlite3_custom.conf)
  • Con un Driver ODBC parecido al sistema visto en Asterisk Realtime (Fichero cdr_odbc.conf)
  • Podemos pasar al AMI información de lectura sobre el CDR (fichero cdr_manager.conf)

Los problemas del sistema CDR surgen debido a que solo se almacena un solo registro CDR con toda la información por llamada. Esto quiere decir, que en el caso que ocurran los siguients posibles casos, la llamada no se registraría en condiciones:

  • Llamadas transferidas
  • Llamadas aparcadas
  • Sistemas de Conferencias
  • Llamadas puestas en Espera

Configuración Ficheros CSV

Para poder configurar CDR, el fichero principal es llamado cdr.conf situado en el mismo directorio que el resto de los ficheros de configuración /etc/asterisk/.

La estructura del mismo es relativamente básica, un contexto [general] como casi todos los módulos de Asterisk, y luego los siguientes contextos que hacen referencias a partes especificas, en este caso los dos más comunes son [csv] que hace referencia al fichero Master.CSV que comentabamos anteriormente, y [radius] para almecenamiento utilizando un servidor RADIUS para la autentificación, pero en esencia un fichero CSV para el amacenaje.

Configuración General

Aquí se especifican todos los parámetros que afectar al modo general de almacenaje utilizando este sistema:

  • enable: Básicamente activa la funcionalidad de registro CDR
  • unanswered: Registra las llamadas no atendidas también
  • endbeforehexten: En caso que llegemos a la extensión especial, h pararía el registro CDR en el fichero
  • initiatedseconds: En caso de utilizar un sistema de Facturación, es práctico para redondear el tiempo a nivel de segundos hacia arriba para facilitar el cálculo del importe
  • batch: Permite registrar la información en bloques, en vez de registrarla de un golpe al finalizar la conversación. El riesgo es que si Asterisk se bloquea durante el proceso de una llamada escribiendo en el fichero, este estaría abierto y podría perderse información.
  • size: Si utilizamos el modo batch, aquí especificaríamos el numero de registros CDR antes de lanzar un bloque (batch) a nuestro fichero.
  • time: También es posible lanzar un bloque por segundos, en este caso, sería el número de segundos antes de conformar un bloque y lanzarlo al fichero.
  • scheduleronly: En caso que queramos que se genere un proceso específico para realizar la gestión de copia en bloque, o si queremos utilizar el propio proceso que controla el sistema de gestión de los bloques.
  • safeshutdown: En caso que el sistema se detenga, paraliza esto, hasta que todos los registros CDR hayan sido grabados en el fichero.

Configuración Específica

Tanto para la copia directa en nuestra máquina o utilizando un sistema RADIUS existen una serie de parámetros específicos comunes y concretos de cada método:

  • usegmtime: Sirve para registrar los eventos en el huso GMT exclusivamente
  • loguiqueid: Para registrar en cada evento, un identificador unico
  • accountlog: En caso que queramos tener un registro independiente para cada código de cuenta, esto es especifico para temas relativos a Facturación

Y concretamente para el sistema RADIUS especificamos el fichero de configuración del cliente que hará la autentificación con radiuscfg => [2]

Configuración Bases de Datos

Como vimos en la sección anterior existen múltitud de formas de almacenaje dentro de posibles bases de Datos. Hay que considerar como vimos en el sistema Asterisk Realtime, la mayoría de las adaptaciones para bases de datos específicas como PostgreSQL y MySQL es posible que caigan en la obsolescencia debido a que la genericidad que ofrecen los driver ODBC ha superado ampliamente a estas alturas a esas adaptaciones personalizadas.

La ventaja general que tiene la escritura en base de datos, es la mayor dificultad o casi imposibilidad en la corrupción de la información como ocurre en el caso del fichero CSV.

Configuración ODBC

En terminos generales, el sistema de interfaz de nuestra máquina Asterisk con un Driver ODBC se realizaría utilizando los siguientes ficheros de configuracion:

  • cdr_adaptive_odbc.conf: Es la evolución del antiguo cdr_odbc.conf que incorpora funciones adicionales para poder registrar la información a medida que deseemos volcar en nuestra base de datos valiendonos de la aplicación Set dentro del Plan de Marcación. A este sistema se le denomina CDR Adaptativo.
  • res_odbc.conf: Es básicamente el fichero que establece la conexión directa entre el driver y Asterisk, especificando un DSN concreto.

El CDR Adaptativo surgió a partir de la versión 1.6 como una gran mejora, y se basa en la premisa que tenemos intención de registrar en una base de datos, determinados aspectos concretos de una llamada. Para ello haríamos referencia a la función CDR y según que parametro le pasemos, registraremos una información u otra en consecuencia. Además podríamos crear nuevos campos dentro de la tabla, lo que convertiría al sistema CDR en un mecanismo mucho más versátil.

Por ejemplo en el Plan de Marcación podriamos definir la siguiente ejecución, en el caso que la extensión realice una llamada por una extensión concreta que llama a móviles, podriamos establecer un campo adicional en nuestra base de datos, llamado coste_minuto, e ir asignandole un valor un otro dependiendo la extensión que haya tomado nuestro usuario para calcular el importe de la llamada (multiplicando la duración de la misma, por la variable coste_minimo en función de lo elegido:

Archivo: /etc/asterisk/extensions.conf
 ; Llamadas a Moviles
exten => _6XXXXXXXX,1,Set(CDR(coste_minuto)=0.05)


La estructura del fichero cdr_adaptive_odbc.conf esta basada en la definición de contextos por cada tabla a la que queramos hacer referencia del registro de llamadas. El contexto lo definimos con un nombre cualquiera descriptivo para la conexión, ejemplo [odbc_cdr]. Luego podemos definir los siguientes parámetros especificos:

  • connection: El nombre del contexto dentro de res_odbc.conf al que queremos hacer referencia, tenemos más información de este fichero dentro del apartado Asterisk Realtime.
  • table: La tabla de la base de datos SQL donde vamos a almacenar la información
  • usegmtime: Si queremos utilizar el tiempo en el huso GMT por defecto.

Configuración MySQL / PostgreSQL

En este caso, como comentaba antes, la mayoría de las soluciones "a medida" para diferentes bases de datos estan quedando obsoletas en favor de los Drivers ODBC y más en este caso, el sistema ODBC Adaptativo que incorpora funcionalidades muy superiores.

En caso de MySQL, tenemos el fichero cdr_mysql.conf, y para PostgreSQL, el fichero cdr_pgsql.conf, cuya configuración de ambos se basa en un único contexto [global] y dentro de este los siguientes parámetros específicos:

  • hostname: Dirección IP del servidor MySQL
  • dbname: Nombre de la base de datos contenida en el servidor MySQL
  • table: Nombre de la tabla a la que haremos referencia
  • user: Usuario de la base de datos
  • password: Contraseña del usuario de la base de datos
  • port: Puerto de la base de datos MySQL si es diferente al estándar 3306.

Para el caso de las bases de datos, necesitaremos crear una tabla como la siguiente, donde se almacenará toda la información SQL:

Tabla: cdr
CREATE TABLE cdr (
calldate datetime NOT NULL default '0000-00-00 00:00:00',
clid varchar(80) NOT NULL default '',
src varchar(80) NOT NULL default '',
dst varchar(80) NOT NULL default '',
dcontext varchar(80) NOT NULL default '',
channel varchar(80) NOT NULL default '',
dstchannel varchar(80) NOT NULL default '',
lastapp varchar(80) NOT NULL default '',
lastdata varchar(80) NOT NULL default '',
duration int(11) NOT NULL default '0',
billsec int(11) NOT NULL default '0',
disposition varchar(45) NOT NULL default '',
amaflags int(11) NOT NULL default '0',
accountcode varchar(20) NOT NULL default '',
uniqueid varchar(32) NOT NULL default '',
userfield varchar(255) NOT NULL default ''
);


Esta estructura, también es valido para otros sistemas, como el Driver ODBC, en caso que sea la configuración estandar y no vayamos a usar campos adicionales específicos del sistema Adaptativo.

Configuración SQLite

Por otro lado existe la posibilidad de almacenar en un sistema de Base de Datos más básico para máquinas que no hacen un uso especialmente intensivo de este recurso, como es el caso de SQLite, un tipo de base de datos transaccional que esta basada en uno o varios ficheros localizados, y requiere un bajo nivel de configuración (por no decir nulo). En contrapartida hay que saber que este tipo de Base de Datos es muy limitada (porque en esencia no deja de ser un único fichero), y suele ser utilizada para instalaciones, literalmente, de andar por casa (de hecho por ejemplo uno de los sistemas que utilice una base de datos SQL es el sistema de almacenamiento online Dropbox [3] para el software que proporciona en el lado Cliente. Esto es importante, dado que aunque sea un sistema de base de datos como otros aquí vistos es muy posible que si estemos haciendo un uso intensivo del mismo, tengamos la necesidad de cambiar lo antes posible

La ventaja es que en su fichero de configuración cdr_sqlite3_custom.conf podemos especificar que campos vamos a registrar a voluntad, lo que podría ser práctico en caso que deseemos utilizar este sistema de base de datos para uno fin muy específico. Solamente es posible guardar un solo fichero llamado Master.db y una tabla contenida en el mismo en estos momentos.

La estructura de este fichero es muy básica:

En primer lugar definimos un único contexto llamado [master] , y dentro de este, definimos los siguientes parámetros:

  • table => cdr: sería como queremos llamarle a la tabla, en este caso le llamaremos cdr
  • columns =>: Las columnas soportadas, son: calldate, clid, dcontext, channel, dstchannel, lastapp, lastdata, duration, billsec, disposition, amaflags, accountcode, uniqueid, userfield, test
  • values =>: Los valores registrados por defecto por la Función CDR.

Sistema CEL

Según visto anteriormente, CEL, Call Event Logging, es una evolución de CDR, surgida a partir de la versión 1.8, dando aun superior soporte al anterior intento basado en el CDR Adaptativo, y diseñada para poder tener control no solo de los pasos de la llamada, sino de los eventos a nivel interno que van surgiendo en el flujo de una llamada dentro de nuestro Plan de Marcación. Es posible que el sistema CDR quede obsoleto con el tiempo en favor a CEL, dado que es capaz de recibir y manipular la misma cantidad de información que CDR, pero incluso con mayor detalle a voluntad, aunque el primero, podría aun conservarse para sistemas que tampoco requieran un nivel de detalle tan excesivo, dada que su facilidad de interpretación.

La estructura de almacenamiento es equivalente a la de CDR, con ficheros CSV, o con Bases de Datos. Hay que considerar la posible cantidad ingente de informacion que es capaz de almacenar CEL por tanto la versión en ficheros de texto puede ser bastante negativa y en la mayor parte de los casos que vayamos a hacer un uso aceptable (ni siquiera intensivo) del sistema, deberíaos optar por la opción de registro en Bases de Datos.

Los ficheros de configuración estándar son:

  • Para ficheros de texto, sería cel.conf, aplicable también para el caso de registro de eventos a la interfaz AMI y para realizar la autentificación a traves de un servidor RADIUS
  • Para el caso de bases de datos PostgreSQL, sería cel_pgsql.conf.
  • En caso de querer utilizar la base de datos SQLite, cel_sqlite3_custom.conf (solo soporta la versión 3, excepto que posibles versiones superiores, fueran retrocompatibles)
  • Si queremos utilizar un driver ODBC, cel_odbc.conf opción más recomendada entre todas las posibles aquí listadas.

Curiosamente para MySQL no existe todavía una integración especifica, lo que indica en gran medida dado que este sistema de registro de Eventos todavía no es tan popular, que se tenga previsto preservar la conexión con el driver ODBC que resulta más genérico.

En caso de CEL también podemos tener personalizaciones de eventos, al igual que con CDR Adaptativo, la función que se encarga de esta cuestión sería CELGenUserEvent


Referencias

  1. A2Billing es un sistema de Facturación para Asterisk de Star2billing S.L.
  2. Radius Client NG, Maxim Sobolev (2003)
  3. DropBox, Dropbox Inc.

Véase también

Enlaces Externos

  • CDR-Stats es una interfaz web para la gestión de CDR en Python.
  • SQLite, página oficial de este básico motor de Base de Datos