AMI

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.

To Do Esta página necesita ser completada. Puedes revisar todas las páginas por completar en este enlace.

Las siglas AMI vienen de Asterisk Manager Interface, o Interfaz para la Gestión de Asterisk. Si pudieramos comparar a Asterisk con una PBX, AMI sería el equivalente a un CTI (Computer Interface Integration, o Interfaz de Integración con el Ordenador). Hay que considerar que aunque paradojicamente, Asterisk ya es un programa de ordenador en si, como veníamos diciendo, si consideraramos a Asterisk como otra PBX, sería como una interfaz para la integración con otras aplicaciones de ordenador.

Introducción a CTI

Clásico Key System de 6 Botones

Es interesante conocer algo sobre los sistemás CTI que incorporan muchas PBX del mercado. En los años 70, varios años después de la primera central conmutada, surgieron las primeras integraciones de sistemas no relacionadas exclusivamente con la función de conmutación de llamadas provenientes de los "Key Systems" (sistemas más sencillos que las PBX, basados en teléfonos con muchos botones) y de las propias PBX, que daban funcionalidades adicionales a las "sencillas" centralitas, como la posibilidad de tener una Operadora Autómatica, Buzones de Voz e incluso Marcadores Predictivos bastante funcionales.

Pero hasta finales de los años 80, no surgieron las primeras interfaces, capaces de enviar a través de un cable, Bus de comunicación, suficiente información acerca del estado de la PBX en cada momento, como para que una máquina conectada a esta (un ordenador), fuera capaz de interpretar estos mensajes y poder realizar funciones acorde. Sistemas CTI más avanzados permitieron incluso una comunicación de dos vías (duplex), con la cual, podriamos mandar información a la central de conmutación para que hiciera las veces de un telefono cualquiera. Durante los años 90, todas las centrales PBX ya incorporaban de alguna un otra forma, alguna interfaz CTI, el problema es que como venía siendo popular, el acceso al manejo de las mismas no estaba al alcance de cualquiera. Y la información al respecto tampoco cumplia una serie de estandares lo suficientemente divulgados como para ser comunes entre varias PBX de diferentes marcas.

A partir del siglo XXI surgió el concepto de Comunicaciones Unificadas, tratando de salvar la barrera de las CTI, dado que los programadores les resultaba demasiado complicado, tener que adaptar sus programas constantemente a las nuevas modificaciones que surgían por cuestiones de nuevas marcas en las empresas, o incluso nuevas versiones dentro de la propia marca.

Introducción a AMI

Curiosamente, es muy típico comparar a AMI con un CTI de cualquier PBX, pero AMI de hecho se aproxima más a un sistema de UC (Unified Communications, Comunicaciones Unificadas), dado que ofrece un estándar unificado, y evita la necesidad de normalizar y consolidar información proveniente de varios entornos.

De hecho, dada la rápida integración que supone este nivel que ofrece AMI, y que es muy dificil darse con otros sistemas PBX, mútliples aplicaciones provenientes del entorno Open Source, han sido capaces de adaptar sus sistemas para una correcta operación con Asterisk prácticamente desde sus inicios.

Existen innumerables proyectos que integran Asterisk para ofrecer una funcionalidad mejorada a traves de la interfaz AMI, y los tipos más comunes suelen ser:

• Aplicaciones basadas en la Monitorización: Por ejemplo para el control de usuarios, colas como Flash Operator Panel

• Aplicaciones relacionadas al control de las llamadas, como A2Billing sistema de facturación integrado en Asterisk para el control de los tiempos de llamada.

• Sistemas para marcado, como son los Dialers según visto en Generación Automática de Llamadas, basados en en la interfaz AMI para su funcionamiento.

Funcionamiento General

La interfaz AMI se basa en un flujo de datos en formato de texto plano (lo que puede ser un gran compromiso para la Seguridad de nuestro sistema Asterisk), y con una estructura Estandarizada que se preserva desde la primera versión.

El flujo que se crea dentro de la AMI puede ser provocado, tanto de forma saliente, a traves de los Módulos que vuelcan información en la interfaz, como comandos entrantes, que también recepcionarían ciertos Módulos y harían alguna función con los datos recibimos.

El formato o sintaxis es relativamente sencillo:

• La primera linea, suele ser del tipo: Event: <Comando> siendo el comando que se va a mostrar o ejecutar.
• Cada linea siguiente al igual que la primera, debe poseer una cabecera, indicando una "propiedad", y luego una información asociada a esta. Dependiendo del módulo podra tener tantas lineas con este formato, como Datos se puedan ofrecer o precisar (dependiendo si es información entrante o saliente).
• Al final del flujo de un Comando concreto, debe haber una linea vacía indicando el fin del comando. Esto puede ser util cara a comprobar si existe un End_of_line independiente, si creando un interprete que sea capaz de analizar todo el flujo.

Un ejemplo siguiendo estas directrices podría ser:

Event: Hangup Channel: SIP/ext11 Uniqueid: 1234567.89 Cause: 19

Esto significa, que nuestra interfaz Asterisk, ha recibido un comando Hangup (Fin de la Conversación), por el canal SIP para el dispositivo ext11, y la Causa ha sido NO ANSWER (Sin respuesta). El Uniqueid, identificaría en este caso, un evento con un código único, basado en una marca de tiempo aleatoria, podría utilizarse con fines de indexación si estamos registrando todos los eventos de alguna forma.

Configuración del Manager

Como comentábamos al principio, AMI es realmente un concepto de Comunicaciones Unificadas más que un simple CTI, y otra prueba de ello es que la conexión a AMI se realiza a través del protocolo TCP/IP. Concretamente el puerto por defecto que se suele utilizar para este propósito es el 5038. También existe la posibilidad de habilitar la funcionalidad de conectar con interfaces basadas en la web y aplicaciones como navegadores, utilizando el protocolo HTTP, gracias a una tecnología diseñada específicamente para Asterisk basada en Java y AJAX, llamada AJAM (Asynchronous Javascript Asterisk Manager), parecida a AJAX con respecto a la equivalencia con uso de mensajes XML, y para ello se utiliza por defecto el puerto 8088.

Configuración General

La estructura del fichero es muy estándar como vistas en otros módulos como SIP, IAX, e incluso el fichero referente a Colas, definido por contextos entre corchetes, considerando uno general donde se engloban todas las opciones genéricas referentes al funcionamiento de AMI, y también otras que afectan a todos los contextos específicos por igual. En este caso el contexto principal sería [general], y el resto de los contextos serían los usuarios del sistema con sus parámetros concretos.

Los parámetros más comunes que suelen ser declarados en el apartado general son los siguientes:

• enable: Permitimos el uso del AMI, por el protocolo TCP/IP estándar.
• port: Podemos cambiar el puerto por defecto, 5038, por otro definido a voluntad
• webenabled: Permitimos el uso del AMI, por HTTP utilizando la tecnología AJAM, muy útil en determinados contextos.
• bindaddr: Si queremos asociar el Mánager a una IP concreta del servidor, o por el contrario a todas las combinaciones posibles si ponemos 0.0.0.0 (por defecto).
• allowmultiplelogin: Permitir la posibilidad de acceder con el mismos usuario múltiples veces
• displayconnects: Permitir que envie información en caso de conexión de un cliente a AMI a traves de la CLI
• timestampevents: Si deseamos que además incluya una marca de tiempo en cada evento que aparezca en la consola
• channelvars: Si queremos que se muestren determinadas variables de canal cada vez que un evento de canal salga, especificamos los nombres de las variables especificas, separadas por copas
• debug: Podemos especificar ("on" y "off"), si queremos que aparezcan entre los eventos de AMI, mensajes de debug adicionales, además de poder ser accesibles desde la CLI
• authlimit: Si queremos limitar el número máximo de sesiones autentificadas totales, podemos especificar el número con este parámetro.
• httptimeout: Elegimos la cantidad de segundos que una sesión HTTP puede quedar activa antes de necesitar volverse a autentificar, en terminos de vida de una "cookie", tiempo despues de complentar una acción con éxito, o tiempo después de recibir un evento tipo WaitEvent, sin respuesta

Configuración de Usuarios

Por otra parte, tenemos que configurar los usuarios que tienen permitido el acceso a la interfaz. El nombre del contexto, tiene que ser justamente el mismo, que el nombre de usuario que queramos definir, por tanto si creamos el contexto [asterisk] tendremos un usuario para acceder a AMI llamado "asterisk".

Por otro lado, el resto de los parámetros definen algunos comportamientos y el resto de parámetros para su correcta autenticación:

Véase también

• Colas
• Generación Automática de Llamadas

Enlaces Externos

• Flash Operator Panel es un panel de control para observar el estado de las lineas, las Colas, y otros aspectos de Asterisk en tiempo real.