Asterisk Realtime

De Asterisk Wiki
Revisión del 17:45 6 jul 2014 de SirLouen (discusión | contribuciones)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Ir a la navegación Ir a la búsqueda

La arquitectura Asterisk Realtime, también llamada ARA (Asterisk Realtime Architecture), es un mecanismo que surgió a partir de la versión 1.2 de Asterisk y permitía poder realizar la configuración de varios aspectos del sistema en tiempo real, de forma dinámica a traves del uso de Bases de Datos relacionales, donde se contienen los parámetros de configuración al detalle, en vez de utilizar los clásicos ficheros de texto.

Usando Realtime

Si comparamos el uso de Asterisk Realtime, con el resto de los modos de configuración podemos destacar que la principal ventaja radica en la flexibilidad y la escalabilidad del sistema, además de la facilidad en las configuraciones sucesivas. Eventualmente la puesta en marcha podría considerarse el único aspecto negativo, pero una vez hecho esto, supera al resto de las opciones con diferencia.

Es muy práctico plantearse el hecho de montar un sistema Realtime, en base a una estructura a modo plantilla que podría servir en sucesivas instalaciones aminorando el tiempo total de puesta en marcha y en consecuencia ofreciendo aún más potencial.

Si consideramos que la flexibilidad que aporta un fichero de texto es mínima conjuntamente a otras opciones como la configuración a través de comandos AMI, o a través de la CLI dado que en una posible instancia estamos "obligados" a ofrecer total control en cualquiera de los casos, a un usuario que pudiera tener el acceso a cualquiera de estas tres alternativas, mientras que utilizando el sistema Realtime, al alojarse en una base de datos, podríamos utilizar cualquier lenguaje de programación, para conectar a la misma, y adaptar una aplicación, específicamente a las necesidades concretas de la organización.

Prácticamente cualquier tipo de Base de datos de tipo relacional es apta para este sistema, pero hay que considerar que Asterisk solo integra módulos de tipo recursos para establecer la conexión directa mediante tres vías populares:

  • Bases de Datos MySQL
  • Bases de Datos PostgreSQL
  • Conectividad a través de un driver ODBC, que a su vez, ofrecería la posibilidad de conectar prácticamente al 100% de las bases de datos del mercado (Microsoft SQL, Oracle 1Xg, IBM U2, etc).

En estos momentos, aunque los recursos para conectar directamente via MySQL y PostgreSQL siguen operativos, se espera que pasen a estar obsoletos en un corto periodo de tiempo, dado que la conectividad a traves del driver ODBC supone un sistema mas universal y cuyo desarrollo y perfeccionamiento supone mas estabilidad que el mantenimiento de un modulo especifico por cada Base de Datos que queremos dotar de soporte.

Configuración ODBC

Logo del Proyecto UnixODBC

En primera instancia dado que es el sistema de conectividad más popular y probablemente el único que prevalezca como comentabamos antes hay que considerar que en contrapartida es uno de los más complejos de configurar dentro de lo que cabe, pero tampoco excesivamente si sabemos que ficheros intervienen en el proceso:

  • Ficheros del Driver ODBC instalado en el sistema *NIX, en este caso son dos:
    • /etc/odbc.ini donde se establecen todos los datos de configuración básicos e interconexión, con nuestro SGBD, sea MySQL, PostgreSQL o el que permita la asociación vía ODBC
    • /etc/odbcinst.ini es donde se definen las librerías odbc especificas, según con que tipo de SGBD vayamos a conectar.
  • Ficheros de configuración del sistema Asterisk:
  • extconfig.conf: Aquí se especifican los módulos convertibles que vamos a utilizar con el sistema RT.
  • res_odbc.conf: Es el recurso especifico de Asterisk para interfasar con el Driver ODBC.

Hay que considerar adicionalmente el para la configuración de RT por ODBC serían necesarios dos módulos cargados en el sistema de tipo recurso: res_odbc.so y res_config_odbc.so

Fichero ExtConfig

Este fichero sirve para configurar todos los aspectos relevantes a los módulos de Asteirsk que son posiblemente convertibles al sistema Realtime, como pueden verse descritos en secciones más adelante.

La estructura del fichero es muy sencilla. Simplemente tiene un contexto llamando [settings] y dentro de este se pueden establecer los datos básicos que interfasarán el fichero de configuración especifico con un sistema de configuración especifico para una base de datos en concreto.

La sintaxis de cada fichero de configuración es la siguiente:

<nombre_modulo_convertible> => <tipo_driver>,<nombre_recurso_bbdd>,<nombre_tabla>

  • En este caso el nombre del modulo convertible los tenemos en la sección correspondiente
  • El tipo de driver seleccionable como vimos anteriormente, puede ser odbc, mysql, o postgresql, incluso ldap para integración con el sistema con el mismo nombre
  • El nombre del recurso que vayamos a utilizar, para asociarlo a una base de datos, por ejemplo el recurso ODBC en caso que vayamos a utilizar el fichero res_odbc.conf
  • El nombre de la tabla que vayamos a darle, por defecto, será la misma que la del módulo convertible

Fichero res_odbc

Este fichero se encarga de enlazar, cada los módulos que van a traspasar su configuración a la base de datos, con los DSN del sistema ODBC.

La estructura se divide en dos partes, por un lado podemos definir variables globales que afectarán al mismo, dentro de un contexto específico llamado [ENV]

Y por otro lado, podemos definir contextos secundarios, por cada conexión a cada DSN del Driver ODBC que deseemos realizar, y hayamos definido en el anterior fichero de configuración extconfig.conf. Justamente el nombre del contexto ha de coincidir con el nombre del recurso BBDD que definimos antes, y luego se pueden definir una serie de parametros especificos como podemos ver a continuación, importante considerar que la sintaxis sería: <parametro> => <valor>:

  • enabled: Si queremos que este activado o no
  • dsn: El nombre del DSN al que haremos referencia desde este recurso
  • username: Usuario para conectar a la base de datos
  • password: Contraseña para conectar a la base de datos, considerar que se guardara en formato texto plano y esto entrañara el riesgo que esto supone, por lo que es altamente recomendable, que creemos un usuario en la base de datos especifico para trabajar con asterisk con un nivel de privilegios exclusivo, y adaptado para operar con las bases de datos que intervienen, especialmente si la base de datos esta compartida con otros sistemas, incluso que el propio Asterisk este utilizando (como Interfaces Web).
  • pre-connect: Para realizar la conexión inmediatamente en el arranque del sistema.
  • idlecheck: Intervalo en segundos para comprobar si la conexión ha quedado "ausente" y es necesario reconectar por especificaciones especificas del SGBD en cuestión.
  • share_connections: Especificamos si queremos o no, que se comparta una sola conexión para todas las consultas, o debemos crear conexiones independientes, según el tipo de SGBD que estemos tratando
  • limit: En el caso que no utilicemos conexiones compartidas, el número limite de conexiones máximas que deberíamos establecer.
  • backslashisescape: Especificamos si la contrabarra se considera el comando escape o no, en bases de datos como MsSQL, no es así por tanto deberíamos desactivarla con "no".

Fichero ODBC.ini y ODBCInst.ini

El fichero ODBC.ini, es donde se configuran los DSN (Data Source Name, o nombres para fuentes de datos) que establecerán el conexionado entre el sistema *NIX y nuestro Sistema Gestor de Bases de Datos en cuestión. Especificamos las credenciales de acceso y demás información.

Por otro lado el fichero ODBCInst.ini, sirve para definir que librerías vamos a utilizar para el Driver en concreto, y su configuración.

Toda la información relativa de ambos ficheros puede encontrarse dentro de la página oficial del proyecto UnixODBC [1]. A continuación mostraremos dos ejemplos para una conexión a una base de datos MySQL utilizando el driver ODBC de Linux.

Archivo: odbc.ini
[mysql]
Driver=MySQL
Server=localhost
User=asterisk
Password=asterisk
Database=asterisk


Archivo: odbcinst.ini
[MySQL]
Driver=/usr/lib/odbc/libmyodbc.so
Setup=/usr/lib/odbc/libodbcmyS.so


Módulos Convertibles

Es posible convertir al sistema RealTime varios Módulos de Asterisk. Parte de ellos se consideran el sistema "Estático", dado que su configuración no esta basada en la idea de necesitar estar cambiandolos regularmente, solamente la ventaja de que al introducir cambios en los mismos, no tener que realizar una recarga del fichero desde la CLI para que los cambios quedasen efectuados.

Canal SIP

El canal SIP esta compuesto por las siguientes tablas:

  • sippeers: Sirve para almacenar toda la información específica de los pares SIP.
  • sipregs: Sirve para almacenar, todos los comandos "register" (SIP: register =>). No es muy recomendable utilizarla dado que su funcionamiento no es todo lo deseable que debería, y probablemente quede obsoleta próximamente.

Por lo demás el resto de la configuración ha de hacerse de forma estática en el fichero para el protocolo SIP de momento.

Estructura SipPeers

Es posible crear la tabla completa en la base de datos sippeers, tenemos que definir los siguientes campos[2]:

Tabla: sippeers
CREATE TABLE `pares_sip` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(80) NOT NULL DEFAULT ,
`context` varchar(80) DEFAULT NULL,

`callingpres` enum('allowed_not_screened','allowed_passed_screen',
'allowed_failed_screen','allowed','prohib_not_screened',
'prohib_passed_screen','prohib_failed_screen','prohib','unavailable') DEFAULT 'allowed_not_screened',
`deny` varchar(95) DEFAULT NULL,
`permit` varchar(95) DEFAULT NULL,
`secret` varchar(80) DEFAULT NULL,
`md5secret` varchar(80) DEFAULT NULL, `remotesecret` varchar(250) DEFAULT NULL,
`transport` enum('tcp','udp','tcp,udp') DEFAULT NULL,
`host` varchar(31) NOT NULL DEFAULT ,
`nat` varchar(5) NOT NULL DEFAULT 'no',
`type` enum('user','peer','friend') NOT NULL DEFAULT 'friend',
`accountcode` varchar(20) DEFAULT NULL,
`amaflags` varchar(13) DEFAULT NULL,
`callgroup` varchar(10) DEFAULT NULL, `callerid` varchar(80) DEFAULT NULL,
`defaultip` varchar(15) DEFAULT NULL,
`dtmfmode` varchar(7) DEFAULT NULL,
`fromuser` varchar(80) DEFAULT NULL,
`fromdomain` varchar(80) DEFAULT NULL, `insecure` varchar(4) DEFAULT NULL,
`language` char(2) DEFAULT NULL,
`mailbox` varchar(50) DEFAULT NULL,
`pickupgroup` varchar(10) DEFAULT NULL,
`qualify` char(3) DEFAULT NULL,
`regexten` varchar(80) DEFAULT NULL,
`rtptimeout` char(3) DEFAULT NULL,
`rtpholdtimeout` char(3) DEFAULT NULL,
`setvar` varchar(100) DEFAULT NULL,
`disallow` varchar(100) DEFAULT 'all',
`allow` varchar(100) DEFAULT 'g729;ilbc;gsm;ulaw;alaw',
`fullcontact` varchar(80) NOT NULL DEFAULT ,
`ipaddr` varchar(15) NOT NULL DEFAULT
,
`port` mediumint(5) unsigned NOT NULL DEFAULT '0',
`username` varchar(80) NOT NULL DEFAULT ,
`defaultuser` varchar(80) NOT NULL DEFAULT
,
`subscribecontext` varchar(80) DEFAULT NULL,
`directmedia` enum('yes','no') DEFAULT NULL,
`trustrpid` enum('yes','no') DEFAULT NULL,
`sendrpid` enum('yes','no') DEFAULT NULL,
`progressinband` enum('never','yes','no') DEFAULT NULL,
`promiscredir` enum('yes','no') DEFAULT NULL,
`useclientcode` enum('yes','no') DEFAULT NULL,
`callcounter` enum('yes','no') DEFAULT NULL,
`busylevel` int(10) unsigned DEFAULT NULL,
`allowoverlap` enum('yes','no') DEFAULT 'yes',
`allowsubscribe` enum('yes','no') DEFAULT 'yes',
`allowtransfer` enum('yes','no') DEFAULT 'yes',
`ignoresdpversion` enum('yes','no') DEFAULT 'no',
`template` varchar(100) DEFAULT NULL,
`videosupport` enum('yes','no','always') DEFAULT 'no',
`maxcallbitrate` int(10) unsigned DEFAULT NULL,
`rfc2833compensate` enum('yes','no') DEFAULT 'yes',
`session-timers` enum('originate','accept','refuse') DEFAULT 'accept', `session-expires` int(5) unsigned DEFAULT '1800',
`session-minse` int(5) unsigned DEFAULT '90',
`session-refresher` enum('uac','uas') DEFAULT 'uas',
`t38pt_usertpsource` enum('yes','no') DEFAULT NULL,
`outboundproxy` varchar(250) DEFAULT NULL,
`callbackextension` varchar(250) DEFAULT NULL,
`registertrying` enum('yes','no') DEFAULT 'yes',
`timert1` int(5) unsigned DEFAULT '500',
`timerb` int(8) unsigned DEFAULT NULL,
`qualifyfreq` int(5) unsigned DEFAULT '120',
`contactpermit` varchar(250) DEFAULT NULL,
`contactdeny` varchar(250) DEFAULT NULL,
`lastms` int(11) NOT NULL,
`regserver` varchar(100) NOT NULL DEFAULT ,
`regseconds` int(11) NOT NULL DEFAULT '0',
`useragent` varchar(50) NOT NULL DEFAULT ,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`),

KEY `name_2` (`name`)

) ENGINE = MyISAM DEFAULT CHARSET = latin1 ROW_FORMAT = DYNAMIC


También existen versiones mas reducidas, dependiendo realmente del número de campos que vayamos a dar uso. Hay que considerar que gran parte de los campos son las distintas propiedades especificas de los pares SIP y muchos tienen tendencia a quedar obsoletos próximamente dadas las eventuales mejoras que en el sistema Asterisk va produciéndose constantemente.

Configuración Específica sip.conf

Hay una serie de parámetros para el fichero sip.conf especificos para tratar con el sistema RT (ARA), y algunos de los cuales son especialmente importantes, dado que mejoran en gran medida el procesamiento de la información y de acceso más rapido a la base de datos:

  • rtcachefriends: Sirve para meter en la memoria cache de Asterisk, los pares más utilizados, disminuyendo los tiempos de acceso a la base de datos, los posibles valores son "yes" y "no", y es bastante recomendable tener esta opción activada en nuestro fichero de configuración.
  • rtsavesysname: Si queremos que se guarde en la memoria, la dirección de un servidor al cual se registra uno o varios pares dentro de nuestro sistema RT
  • rtupdate: Sirve para actualizar ciertos campos de la tabla sippeers en el momento que se registra un nuevo par por SIP, esta activada por defecto.
  • rtautoclear: Sirve para liberar de la memoria aquellos pares que hayan caducado en el tiempo de comprobación de registro de cada par
  • ignoreregexpire: Justamente contrapuesta al anterior parametro, no toma en cuenta el tiempo de expiración de los pares, conservandolos en memoria indefinidamente.

Canal IAX

El canal IAX posee las siguientes tablas disponibles:

  • iaxpeers: Similar al sippeers sirve para definir los pares IAX.
  • iaxusers: Sirve para definir los pares tipo user de IAX, hay que considerar que esta tabla va quedando obsoleta en favor de iaxpeers, al igual que ya lo hizo la tabla "sipusers" en su día.

Estructura IAXPeers

En este caso, también tenemos acceso a una tabla especifica [3] para definir todos los parámetros en detalle de los dispositivos IAX, y hay que considerar, que la tabla puede ajustarse a una versión mas personalizada para que se ajuste únicamente a las necesidades nuestras. Es importante tener en cuenta que las versiones personalizadas, han de contener todos los parámetros que hacen referencia a valores que registra Asterisk por defecto para mantener un control del sistema:

Tabla: iaxpeers
CREATE TABLE pares_iax (
name varchar(30) primary key NOT NULL,
username varchar(30),
type varchar(6) NOT NULL,

secret varchar(50),
md5secret varchar(32),
dbsecret varchar(100),
notransfer varchar(10),
inkeys varchar(100),
outkey varchar(100),
auth varchar(100),
accountcode varchar(100),
amaflags varchar(100),
callerid varchar(100),
context varchar(100),
defaultip varchar(15),
host varchar(31) NOT NULL default 'dynamic',
language char(5),
mailbox varchar(50),
deny varchar(95),
permit varchar(95),
qualify varchar(4),
disallow varchar(100),
allow varchar(100),

ipaddr varchar(15),
port integer default 0,
regseconds integer default 0
);
CREATE UNIQUE INDEX iax_buddies_username_idx ON iax_buddies(username);


Buzones de Voz

Al igual que los anteriores módulos, el sistema de buzones de voz se puede configurar utilizando la tabla única voicemail.

En este caso, la tabla voicemail incorpora la configuración de cada uno de los Buzones de voz, algo que puede realmente ser muy interesante, especialmente si consideramos, que la configuración en fichero, no proporciona excesiva seguridad, y como ya sabemos, el sistema de modificación de claves de buzones, se realiza utilizando una aplicación interna de Asterisk, que reescribe el fichero voicemail.conf, de una forma poco conveniente (e incluso modifica la cabecera, para indicar que hizo la modificación de forma semi-manual).

La estructura de la tabla voicemail más actualizada y completa es la siguiente [4], siguiendo como el caso de las anteriores, pudiéndose establecer una versión más reducida para aumentar la prácticidad:

Tabla: voicemail
CREATE TABLE `voicemail` (
`uniqueid` INT(4) NOT NULL AUTO_INCREMENT,
`customer_id` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`context` VARCHAR(10) COLLATE utf8_bin NOT NULL,
`mailbox` VARCHAR(10) COLLATE utf8_bin NOT NULL,
`password` INT(4) NOT NULL,
`fullname` VARCHAR(150) COLLATE utf8_bin DEFAULT NULL,

`email` VARCHAR(50) COLLATE utf8_bin DEFAULT NULL,
`pager` VARCHAR(50) COLLATE utf8_bin DEFAULT NULL,
`tz` VARCHAR(10) COLLATE utf8_bin DEFAULT 'central',
`attach` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'yes',
`saycid` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'yes',
`dialout` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`callback` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`review` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`operator` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`envelope` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`sayduration` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`saydurationm` TINYINT(4) NOT NULL DEFAULT '1',
`sendvoicemail` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`delete` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`nextaftercmd` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'yes',
`forcename` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`forcegreetings` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'no',
`hidefromdir` ENUM('yes','no') COLLATE utf8_bin NOT NULL DEFAULT 'yes',
`stamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`attachfmt` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`searchcontexts` ENUM('yes','no') COLLATE utf8_bin DEFAULT NULL,
`cidinternalcontexts` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`exitcontext` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`volgain` VARCHAR(4) COLLATE utf8_bin DEFAULT NULL,
`tempgreetwarn` ENUM('yes','no') COLLATE utf8_bin DEFAULT 'yes',
`messagewrap` ENUM('yes','no') COLLATE utf8_bin DEFAULT 'no',
`minpassword` INT(2) DEFAULT '4',
`vm-password` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`vm-newpassword` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`vm-passchanged` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`vm-reenterpassword` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`vm-mismatch` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`vm-invalid-password` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`vm-pls-try-again` VARCHAR(10) COLLATE utf8_bin DEFAULT NULL,
`listen-control-forward-key` VARCHAR(2) COLLATE utf8_bin DEFAULT NULL,
`listen-control-reverse-key` VARCHAR(1) COLLATE utf8_bin DEFAULT NULL,
`listen-control-pause-key` VARCHAR(1) COLLATE utf8_bin DEFAULT NULL,
`listen-control-restart-key` VARCHAR(1) COLLATE utf8_bin DEFAULT NULL,
`listen-control-stop-key` VARCHAR(13) COLLATE utf8_bin DEFAULT NULL,
`backupdeleted` VARCHAR(3) COLLATE utf8_bin DEFAULT '25',

PRIMARY KEY (`uniqueid`),
KEY `mailbox_context` (`mailbox`,`context`)
) ENGINE=INNODB DEFAULT CHARSET=latin1 ;


Música en Espera

Este es en la actualidad el único módulo convertible, que realmente se considera como un sistema RealTime de tipo estático, ya que realmente no es típico introducir modificaciones en el sistema de Música en Espera de Asterisk (aunque añadiendo funcionalidad RT, esto ya podría resultar más viable).

Solo existe como es lógico una tabla musiconhold y su estructura es relativamente sencilla comparada al resto:

Tabla: musiconhold
CREATE TABLE `musiconhold` (
`name` varchar(80) NOT NULL,
`directory` varchar(255) NOT NULL default ,
`application` varchar(255) NOT NULL default
,
`mode` varchar(80) NOT NULL default ,
`digit` char(1) NOT NULL default
,
`sort` varchar(16) NOT NULL default ,
`format` varchar(16) NOT NULL default
,
PRIMARY KEY (`name`));


Sistema de Colas

En este caso, el sistema de Colas es el que más tablas involucra. Podemos configurar las tres siguientes:

  • queues: Podemos configurar las colas y sus parámetros especificos
  • queue_members: Todos los miembros de las colas, y a las colas que están asociados
  • queue_log: Podemos trasvasar el sistema de estádisticas de las colas a un tipo base de datos en vez del fichero de texto plano en el directorio /var/log/asterisk

Estructura Queues y Queue Members

En Queues, se almacenan todos los parámetros específicos de las Colas Tablas de Colas Kristian Nielsen, Voopinfo LLC (2005) </ref>, ocurre exactamente lo mismo que en el resto de las estructuras, es adaptable a la necesidad, en este caso hay que considerar que muchos parámetros son especificos por ejemplo, del tipo de estrategia que vayamos a utilizar en la misma:

Tabla: queues
CREATE TABLE queue_table (
name VARCHAR(128) PRIMARY KEY,
musiconhold VARCHAR(128),
announce VARCHAR(128),
context VARCHAR(128),
timeout INT(11),

monitor_join tinyint(1),
monitor_format VARCHAR(128),
queue_youarenext VARCHAR(128),
queue_thereare VARCHAR(128),
queue_callswaiting VARCHAR(128),
queue_holdtime VARCHAR(128),
queue_minutes VARCHAR(128),
queue_seconds VARCHAR(128),
queue_lessthan VARCHAR(128),
queue_thankyou VARCHAR(128),
queue_reporthold VARCHAR(128),
announce_frequency INT(11),
announce_round_seconds INT(11),
announce_holdtime VARCHAR(128),
retry INT(11),
wrapuptime INT(11),
maxlen INT(11),
servicelevel INT(11),
strategy VARCHAR(128),
joinempty VARCHAR(128),
leavewhenempty VARCHAR(128),
eventmemberstatus tinyint(1),
eventwhencalled tinyint(1),
reportholdtime tinyint(1),
memberdelay INT(11),
weight INT(11),
timeoutrestart tinyint(1),

ringinuse tinyint(1),
setinterfacevar tinyint(1));


Por otro lado, tenemos Queue_members, donde podemos especificar parámetros especificos de los miembros que se conectaran a las mismas, con la siguiente estructura en este caso más directa:

Tabla: queue_members
CREATE TABLE queue_member_table (
uniqueid INT(10) UNSIGNED PRIMARY KEY AUTO_INCREMENT,
membername varchar(40),
queue_name varchar(128),
interface varchar(128),
penalty INT(11),
paused INT(11),
UNIQUE KEY queue_interface (queue_name, interface));


MeetMe

Este módulo convertible, esta basado en la tabla meetme.

Gracias a esta funcionalidad, podremos crear y eliminar salas de conferencias a voluntad, y tener un sistema de conferencias dínamico, para poder ofrecer el servicio a toda una Organización, sin necesidad de un mantenimiento constante.

Para ello basta con definir la estructura de la tabla correspondiente, según aqui descrito:

Tabla: meetme
CREATE TABLE meetme (
bookid int(11) auto_increment,
confno char(80) DEFAULT '0' NOT NULL,
starttime datetime default '1900-01-01 12:00:00',

endtime datetime default '2038-01-01 12:00:00',
pin char(20) NULL,
adminpin char(20) NULL,
opts char(20) NULL,
adminopts char(20) NULL,
recordingfilename char(80) NULL,

recordingformat char(10) NULL,
maxusers int(11) NULL,
members integer DEFAULT 0 NOT NULL,
index confno (confno,starttime,endtime),
PRIMARY KEY (bookid));


DialPlan en formato Realtime

Es también posible, configurar el Plan de Marcación de Asterisk con el sistema realtime. Realmente es una de las peores ideas ya que como sabemos, el dialplan podría casi considerarse un lenguaje de Script, y tener que realizar esto utilizando una base de datos podría resultar increíblemente complejo y muchísimo menos versátil, que la utilización de ficheros. Existen otros mecanismos para configurar el Plan de Marcación, sin contar los ficheros planos y RT, que incluso podrían ser mejor que este último, por eso queda verdaderamente desaconsejado la utilización de este método.

Quizá la utilidad surgiría si quisieramos montar algún tipo de interfaz gráfico aparte de los ya existentes, basado en la posibilidad de asociarlo a un sistema de Bases de datos, situación que resultaría en este caso aprovechable.

El nombre del módulo convertible recibe el mismo nombre que el fichero de configuración del Dialplan, en este caso extensions, y el formato estructural de la tabla, es muy similar al establecido en el sistema AMI para el evento "NewExten" representando las posibilidades que ofrece de configuración procedimental el DialPlan:

Tabla: extensions
CREATE TABLE `extensions_table` (
`id` int(11) NOT NULL auto_increment,
`context` varchar(20) NOT NULL default ,
`exten` varchar(20) NOT NULL default
,

`priority` tinyint(4) NOT NULL default '0',
`app` varchar(20) NOT NULL default ,
`appdata` varchar(128) NOT NULL default
,
PRIMARY KEY (`context`,`exten`,`priority`),

KEY `id` (`id`)
) TYPE=MyISAM;


Un ejemplo de un registro, por ejemplo para lanzar una pista de audio a traves de la aplicación Playback sería el siguiente:

INSERT INTO `dialplan` VALUES ('extensiones', '111', 1, 'Playback', 'bienvenida');

Referencias

  1. Configuración Driver ODBC, Nick Gorham, unixODBC Project
  2. Tabla SIP Peers, Varios Autores, Voopinfo LLC
  3. Tabla IAX Peers Varios Autores, Voopinfo LLC
  4. Tabla Voicemail Sherwood McGowan, Voopinfo LLC

Véase también

Enlaces Externos