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 General

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 . Para ello se utiliza por defecto el puerto 8088.

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.