Diferencia entre revisiones de «Registro Llamadas y Eventos»

De Asterisk Wiki
Ir a la navegación Ir a la búsqueda
Línea 80: Línea 80:
  
 
{{Archivo|/etc/asterisk/extensions.conf| ; Llamadas a Moviles<br>exten &#61;&gt; _6XXXXXXXX,1,Set(CDR(coste_minuto)&#61;0.05)}}
 
{{Archivo|/etc/asterisk/extensions.conf| ; Llamadas a Moviles<br>exten &#61;&gt; _6XXXXXXXX,1,Set(CDR(coste_minuto)&#61;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 <nowiki>[odbc_cdr]</nowiki>. 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 <nowiki>[global]</nowiki> 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:
 +
 +
{{Database|cdr|CREATE TABLE cdr (<br>calldate datetime NOT NULL default '0000-00-00 00:00:00',<br>clid varchar(80) NOT NULL default '',<br>src varchar(80) NOT NULL default '',<br>
 +
dst varchar(80) NOT NULL default '',<br>dcontext varchar(80) NOT NULL default '',<br>channel varchar(80) NOT NULL default '',<br>dstchannel varchar(80) NOT NULL default '',<br>
 +
lastapp varchar(80) NOT NULL default '',<br>lastdata varchar(80) NOT NULL default '',<br>duration int(11) NOT NULL default '0',<br>billsec int(11) NOT NULL default '0',<br>
 +
disposition varchar(45) NOT NULL default '',<br>amaflags int(11) NOT NULL default '0',<br>accountcode varchar(20) NOT NULL default '',<br>uniqueid varchar(32) NOT NULL default '',<br>
 +
userfield varchar(255) NOT NULL default ''<br>);}}
 +
 +
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 ====
 
==== Configuración SQLite ====

Revisión del 19:38 5 jun 2012

Format.png Formatear
Esta página necesita ser editada para cumplir los requisitos del wiki.
Puedes revisar todas las páginas sin suficiente formato en este enlace.
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)

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 sabe r


Sistema CEL

Segun 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.

Referencias

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

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