Documentacion de administador VIVAit Alert 1.0

1 INTRODUCCIÓN

El módulo de Alertas del sistema VIVAit Call constituye la solución que mdtel ha desarrollado para los sistemas de emergencias.

mdtel ha realizado un desarrollo en un entorno web sencillo, al que se accede mediante usuario y password.

En este entorno web se reflejan las situaciones de todas las llamadas recibidas en el sistema de alertas, asímismo, el entorno permite agrupar los datos del servicio en gráficos y/o tablas.

En el mismo entorno web se pueden configurar parámetros del sistema de alertas.

2 FUNCIONAMIENTO GLOBAL

El funcionamiento del sistema es el siguiente:

• El sistema se puede configurar para que solo algunos dispositivos puedan realizar llamadas de alerta  Si el dispositivo que intenta acceder al sistema no está autorizado será reencaminado hacía destinos predeterminados.
• El sistema se activa con la recepción de una llamada de alerta desde algún dispositivo, el usuario puede grabar un mensaje que será reproducido a los destinatarios.
• Se puede configurar un código de activación del sistema; se solicita un código al usuario que llama al teléfono de alertas.
• Cuando se recibe una llamada, el sistema la pasa a una IVR que invita al usuario a dejar un mensaje.
• Una vez grabado el mensaje el sistema lanza una batería de llamadas salientes simultáneas, configurables desde el portal Web, a hasta dos grupos distintos, Grupo 1 y Grupo 2. Como destinos de estos grupos se puede configurar cualquier número (extensión IP, números internos o externos, móvil corporativo, …).
• Si alguno de los destinos del Grupo 1, con capacidad para confirmar la llamada, descuelga, escucha el mensaje y confirma la llamada, ésta aparece en el portal Web como llamada confirmada y el sistema no lanza las llamadas programadas en el Grupo 2.
• Si ningún destino del Grupo 1 confirma la llamada, el sistema lanza un segundo grupo de llamadas, también configurable en el portal Web. En este segundo grupo de llamadas pueden existir destinos configurados de forma que puedan confirmar, si alguno de ellos confirma dicha llamada en el portal se reflejará una llamada Confirmada en Secundario. Si ninguno de los destinos del Grupo 2 confirma la llamada ésta aparece en el portal como No Completada y sombreada en rojo.
• El sistema no permite que todos los destinos están configurados como Grupo 2.
• Si es posible a todos los destinos que reciben la llamada de alarma se les muestra el número de teléfono que originó la llamada de alarma.
• El mensaje grabado se puede escuchar en cada destino y, además, se puede reproducir desde el portal Web.
• El portal Web indica en qué destinos se confirma la llamada, en qué destinos se descuelga la llamada, pero no se confirma, y en qué destinos ni se descuelga ni se confirma la llamada.
• Los estados en los que pueden estar las llamadas son los siguientes:
  • Confirmada.
  • No completada.
  • Abortada.
  • Confirmada en Secundario.
  • En Curso.
  • No autorizada.

Cuando ningún destino (del Grupo 1 o del Grupo 2) confirma la llamada ésta aparece en el portal como No completada y aparece sombreada en color rojo.

Si una llamada es confirmada por un destino del Grupo 1 aparece en el portal como Completada y está sombreada en color verde.

Si un usuario ha llamado a la extensión de alertas y ha colgado durante la locución la llamada aparece en el portal como Abortada y está sombreada en color rojo.

Si una llamada es confirmada por un destino del Grupo 2 aparece en el portal como Confirmada en Secundario y está sombreada en color naranja.

Si entra en el sistema una llamada ésta aparece inmediatamente en el portal, en estado En Curso y sombreada en azul, hasta que la llamada finalice y se actualice su estado indicando entonces su estado definitivo.

Cuando un origen no autorizado realiza una llamada al sistema de alertas una locución le indica que el origen de la llamada no está autorizado y que la llamada se va a transferir, el portal, en ese caso, refleja la llamada como no autorizada.

• Cuando se despliega la información de una llamada en el portal Web aparece el tiempo que cada uno de los destinos ha tardado en contestar y/o confirmar la llamada. Si los destinos no han atendido la llamada el tiempo es 0.
• El sistema permite configurar un servicio del tipo Salas de Conferencia.

3 DIAGRAMA DE BLOQUES DE LA SOLUCIÓN

3.1 Sistema sin Orígenes Autorizados

3.2 Sistema con Orígenes Autorizados

3.3 Salas de Conferencia

3.4 Diagramas de funcionamiento de la confirmación de llamadas

En función de la duración del tiempo de confirmación que de ha configurado en el sistema pueden producirse dos casos:

3.4.1 Tiempo de confirmación largo

3.4.2 Tiempo de confirmación corto

4 ARQUITECTURA

El desarrollo de la solución se basa en la siguiente arquitectura:

Los elementos principales del módulo de Alertas son:

• IVR desplegada sobre el elemento de conmutación de voz asterisk de VIVAit Call; existirá una IVR por servicio; esta IVR tendrá flujos condicionados por elementos de configuración.
• Base de datos en la que reside toda la configuración susceptible de ser modificada en la IVR y en la que se insertan las estadísticas de las llamadas recibidas y emitidas; se amplia la base de datos de la plataforma VIVAit Call con nuevas tablas para el módulo de Alertas.
• Portal de configuración y obtención de estadísticas del módulo de Alertas; es un portal diferente del de administración de la plataforma VIVAit Call o el de usuario de telefonía de VIVAit Call; se monta sobre servidor Apache Tomcat.
• Módulo de alertas para Asterisk.

El desarrollo de la solución utiliza los siguientes lenguajes:

• JAVA para el backend, conexión con base de datos.
• JavaScript para el portal, con Bootstrap como capa de JavaScript.
• C para el módulo de alertas.

El funcionamiento interno del sistema es el siguiente:

Se generan dos nuevos tipos de segmentos:

• 800 para la llamada que inicia la alerta
• 810 para los bloques de llamadas que se emiten.

Se produce una llamada que se gestiona en el sistema a través de un VDN y deja un mensaje grabado. Esta llamada se reenvía a una batería de usuarios (Primer bloque de llamadas o destinos primarios) entre los que hay usuarios que pueden confirmar la llamada y usuarios que no pueden. Si algún usuario de ese primer bloque confirma la llamada ésta queda registrada en el sistema, si ningún usuario del primer bloque la confirma se emite una segunda batería de llamadas, entre las que vuelve a haber usuarios con capacidad para confirmar la llamada y usuarios que no pueden confirmarla. Si la llamada no es confirmada por ningún usuario aparece en el sistema de supervisión como no confirmada, queda marcada en color rojo en el portal Web. El tiempo que pasa desde que se genera la llamada de emergencia hasta que se confirma ésta se ha diseñado aplicando criterios de eficiencia, de forma que el segundo bloque de llamadas se genera cuando el último usuario con capacidad para confirmar una llamada del primer bloque de llamadas, no lo ha hecho.

Entre las casuísticas que se contemplan en la salida de los bloques de llamadas se encuentran los siguientes tipos:

• Problemas internos: Por ejemplo, congestión o problemas con la red telefónica.
• Problemas achacables al usuario: Por ejemplo, no contesta o salta el contestador.
• Llamada confirmada: Se confirma la llamada pulsando un 1 (puede configurarse en el campo Código Confirmación Saliente del Servicio que la llamada se confirme con un código distinto).

4.1 Elementos del sistema

El sistema está formado por:

1. Un Asterisk que contiene:

• Una aplicación específica, APP_MDALERTAS, que cuenta con dos ficheros de configuración, MDalertas.conf y MDalertas_WEB.conf, situados en etc\asterisk\.
• Un Dialplan.

Cada uno de los servicios a los que se puede llamar ha de tener un VDN distinto.

El fichero de configuración se lee en cada una de las llamadas generadas → no existe reload.

2. Un GeneraConf, que permite sincronizar los cambios del portal de alertas y crear los ficheros de configuración → Es importante aclarar que si un administrador modifica la configuración del sistema directamente en uno de los ficheros de configuración existentes esta configuración no quedará reflejada en el portal web; sin embargo, si se aplicará al sistema de Alertas ya que Asterisk lee directamente estos ficheros.

3. Un portal Web para la gestión del servicio.

El portal de gestión permite controlar:

• el servicio.
• los destinos.
• las entidades.
• los orígenes autorizados.

4. Un sistema de supervisión activo, no relacionado con la plataforma del sistema.

Adicionalmente para configurar el Sistema de Alertas se han de configurar dispositivos de salida, VDN’s y grupos de grabaciones. Para configurar estos elementos utilizaremos el portal de administración de VIVAit Call.

Es necesario que las locuciones estén configuradas en el grupo de locución “Alertas”, y que sean del tipo sounds:

Todas las opciones relacionadas con las locuciones se encuentran en el menú VIVAit Response:

Para poder configurar el sistema de alertas con servicios de alertas y con Salas de conferencia son necesarias, al menos, 9 locuciones:

Los nombres de las locuciones, su situación en el sistema, y su contenido aparecen en la siguiente tabla:

Nombre Variable	Ubicación y nombre del fichero	Texto a locutar
locucion_comunicacion	/var/lib/asterisk/sounds/Alertas/ALE_emer_notif.wav	Sistema de alertas
locucion_confirmacion	/var/lib/asterisk/sounds/Alertas/ALE_emer_confir.wav	Sistema de alertas confirme con la tecla 1
locucion_informacion	/var/lib/asterisk/sounds/Alertas/ALE_emer_dejar.wav	Sistema de alertas grabe su mensaje
Alerta_confirmada	/var/lib/asterisk/sounds/Alertas/ALE_emer_confirOK.wav	Alerta confirmada
locucion_secundario	/var/lib/asterisk/sounds/Alertas/Destino Secundario.wav	Destino secundario
locucion_comunicacion_Salas	/var/lib/asterisk/sounds/Alertas/Sala_Comunicacion.wav	Ha sido convocado a una conferencia del sistema de alertas
locucion_Sala_informacion	/var/lib/asterisk/sounds/Alertas/Sala_Informacion.wav	Indique el motivo de la conferencia
locucion_timeout	/var/lib/asterisk/sounds/Alertas/ALE_emer_timeout.wav	Tiempo de confirmación vencido
Origen_No_Autorizado	/var/lib/asterisk/sounds/Alertas/LlamadaNoAutorizada.wav	Origen no autorizado, transferimos la llamada.

Adicionalmente se incluyen siguientes locuciones:

• Introduzca el código de autorización -> CodigoEntrada.wav
• confirme con la tecla cero -> ALE_emer_confir_0.wav
• confirme con la tecla dos-> ALE_emer_confir_2.wav
• confirme con la tecla tres-> ALE_emer_confir_3.wav
• confirme con la tecla cuatro-> ALE_emer_confir_4.wav
• confirme con la tecla cinco-> ALE_emer_confir_5.wav
• confirme con la tecla seis-> ALE_emer_confir_6.wav
• confirme con la tecla siete-> ALE_emer_confir_7.wav
• confirme con la tecla ocho-> ALE_emer_confir_8.wav
• confirme con la tecla nueve-> ALE_emer_confir_9.wav
• Teclee el código para confirmar-> ALE_emer_confir.wav

Todas ellas están relacionadas con la personalización del sistema y permiten configurar:

1. Un código de entrada al sistema que tiene que conocer la persona que llama.

2. Un código de confirmación de la llamada, por parte del destino configurado para confirmar, distinto del 1, código que por defecto pide el sistema.

Los nodos que forman parte del sistema estarán configurados en el portal de administración de VIVAit Call, será imprescindible que estén identificados como nodos de alerta → campo “Es Alertas” = SI:

Esta configuración garantiza la supervivencia del sistema VIVAit Alertas cuando uno de los nodos no está disponible.

Es importante tener en cuenta que cuando los “Servicios” tienen destinos pertenecientes al mismo nodo y éste no está disponible, el sistema de supervivencia solo funcionará si los destinos están asociados a terminales con doble registro (en nodos distintos) o cuando el propio sistema telefónico está configurado para garantizar las llamadas ente nodos aún cuando uno de ellos no esté disponible.

Podríamos considerar una buena política de configuración que los destinos de un “Servicio” estuviesen configurados en nodos distintos.

4.2 Pruebas del sistema

Además, se ha preparado un sistema de pruebas, ALER, capaz de simular cualquier tipo de llamada que pueda generarse en el sistema.

El sistema de pruebas ALER no genera segmentos durante las pruebas.

4.3 Ficheros de configuración

4.3.1 MDalertas.conf

[global]
id_dispositivo_llam_sal=1
contexto_lado_fuera=Cen_InicioLlamada_Emer_Salida
contexto_lado_dentro=Cen_InicioLlamada_Emer_IVR
grabacion_msj_prefijo=/var/spool/MDtel/Alertas/Real/
locucion_comunicacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_notif
locucion_confirmacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_confir
locucion_informacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_dejar
locucion_secundario=/var/lib/asterisk/sounds/WEB/Alertas/locicion_secundario
cad_copia_wav1=172.25.128.92:/var/spool/MDtel/Alertas/Real
cad_copia_wav2=-
tiempo_descolgado=30
tiempo_confirmacion=30
tiempo_grabacion=60

#include “MDalertas_WEB.conf”

En este fichero se configuran, entre otras cosas, las locuciones que reproduce el sistema de alertas, y los tiempos máximos para descolgar y confirmar las llamadas.

4.3.2 MDalertas_WEB.conf

Este fichero tiene una parte global en la que se configuran los siguientes parámetros:

Campo	Descripción
[9000_vdn]
vdn=9000
id_entidad=1
id_servicio=1
Id_dispositivo_llam_sal	Identifica el dispositivo de llamada desde el que se realiza el conjunto de llamadas.
tipo_servicio=10	Define como se comporta el sistema desde un punto de vista operativo. Si el valor es 10 el servicio es del tipo Emergencia, si el valor es 20 el servicio es una Sala de Conferencia.
sin_segmentos=no	Indica si se generan o no segmentos: Yes → no se generan segmentos, por ejemplo, para llamadas de prueba. No → se generan segmentos
locucion_comunicacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_notif	Locución que se reproduce cuando un usuario llama al servicio de emergencias.
locucion_confirmacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_confir	Locución que se reproduce en los teléfonos que reciben las llamadas de emergencias cuando alguien ha dejado un mensaje y se activa el sistema, antes de confirmar la llamada.
locucion_informacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_dejar	Locución que recibe la persona que llama al sistema de alertas
locucion_secundario=/var/lib/asterisk/sounds/WEB/Alertas/locicion_secundario	Locución que recibe un destino secundario
tiempo_descolgado=20	Tiempo durante el que suena la llamada esperando que el usuario descuelgue el teléfono.
tiempo_confirmacion=60	Tiempo desde que el usuario descuelga hasta que está disponible la posibilidad de confirmación.
tiempo_grabacion=60
eje1=01	Sirve para grabar en los segmentos (graba la cadena)
autorizada=no	Este campo controla la posibilidad de autorizar solo a algunos orígenes para que hagan llamadas al sistema de ALERTAS
dest_no_autorizada=0xxxxxxxxx	Teléfono al que se enviarán las llamadas al sistema de ALERTAS cuando el número que llama al sistema no está autorizado.

Además, el fichero tiene una parte para configurar los destinos primarios y secundarios:

Campo	Descripción
[9000_dest_0000]
secundario=no	Indica si el destino es primario o secundario: NO → Primario YES → Secundario
destino=4900
origen_nombre=orig_5
origen_num=1005	Sirve para identificar el número de EMERGENCIAS, si no lo identificamos el sistema utilizará el nº de teléfono que origina la EMERGENCIA.
confirmar=yes	Indica si el destino puede confirmar la EMERGENCIA: YES → Si puede confirmar NO → No puede confirmar
funcion=1005	Hace referencia a la tabla de funciones.
id_destino=15	ID del usuario que va recibir la llamada de EMERGENCIA.
[9000_dest_0001]
secundario=yes	Indica si el destino es primario o secundario: NO → Primario YES → Secundario
destino=4900
origen_nombre=orig_6
origen_num=1006	Sirve para identificar el número de EMERGENCIAS, si no lo identificamos el sistema utilizará el nº de teléfono que origina la EMERGENCIA.
confirmar=no	Indica si el destino puede confirmar la EMERGENCIA: YES → Si puede confirmar NO → No puede confirmar
funcion=1006	Hace referencia a la tabla de funciones.
id_destino=16	ID del usuario que va recibir la llamada de EMERGENCIA.

A continuación, podemos ver las líneas de un fichero MDalertas_WEB.conf que corresponde con la configuración de una Sala de Conferencia (servicio tipo 20). Además, la Sala tiene configurados orígenes autorizados y códigos de confirmación para el usuario que llama al sistema.

[9007_vdn]
vdn=9007
id_entidad=48
id_servicio=28
id_dispositivo_llam_sal=1
tipo_servicio=20
sin_segmentos=no
locucion_comunicacion=/var/lib/asterisk/sounds/WEB/Alertas/locucion_comunicacion_Salas
locucion_confirmacion=/var/lib/asterisk/sounds/WEB/Alertas/locucion_comunicacion
locucion_informacion=/var/lib/asterisk/sounds/WEB/Alertas/locucion_Sala_informacion
locucion_secundario=/var/lib/asterisk/sounds/WEB/Alertas/locucion_comunicacion
tiempo_descolgado=
tiempo_confirmacion=
tiempo_grabacion=
eje1=01020202
autorizada=yes
dest_no_autorizada=06133
codigo_confir_entra=321
codigo_confir_sale=

[9007_dest_0000]
secundario=no
destino=06133
origen_nombre=
origen_num=
confirmar=no
funcion=
id_destino=38

[9007_dest_0001]
secundario=no
destino=4002
origen_nombre=
origen_num=
confirmar=no
funcion=10
id_destino=40


[9007_autorizados]
4002=yes
06140=yes
6133=yes

Se ha creado una variable, alert_des_ultrecurso, en ex_Mdtel_particular.conf que permite encaminar las llamadas al sistema de alertas hacía un destino definido, cuando todos los elementos del sistema fallan y no es posible finalizar las llamadas del modo habitual.

4.4 Estructura de la Base de Datos

El sistema de Alertas tiene las siguientes tablas:

Excepto la tabla ALE_SEGMENTOS, todas se configuran a travé del portal web.

La estructura de la Base de Datos es la siguiente:

5 MONITORIZACIÓN DEL SISTEMA

5.1 DAT_ESTADOS_SERVICIOS

Se ha preparado una tabla para monitorizar el estado de los servicios del sistema de alertas:

DAT_ESTADOS_SERVICIOS

CREATE TABLE IF NOT EXISTS `nimitz`.`DAT_ESTADOS_SERVICIOS` (
  `ID_APLICACION` INT NOT NULL,
  `E_TIPO_SERVICIO` INT NOT NULL COMMENT 'TTipoServicio',
  `N_INSTANCIA` INT NOT NULL,
  `E_ESTADO_SERVICIO` INT NULL DEFAULT 0 COMMENT 'TEstadoServicio',
  `N_VALOR` INT NULL,
  `D_FECHA_ACTUALIZACION` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`ID_APLICACION`, `E_TIPO_SERVICIO`, `N_INSTANCIA`))
ENGINE = InnoDB

Esta tabla tendrá un registro por cada servicio a monitorizar.

Los campos de la tabla son los siguientes:

ID_APLICACION

El id que corresponda de la tabla COM_APLICACIONES, aunque es una tabla existe un enumerado que es un reflejo de la tabla (TAplicacion).

    //Sincronizada con la tabla COM_APLICACIONES
    //Id: 400-499
    TAplicacion = (
        aplicacion_Comun=1,
        aplicacion_Centralita=2,
        aplicacion_ACD=3,
        aplicacion_Mensajeria=4,
        aplicacion_Grabacion=5,
        aplicacion_SMS=6,
        aplicacion_Fax=7,
        aplicacion_Meet=8,
        aplicacion_Alertas=9
    );

E_TIPO_SERVICIO

El tipo de servicio, los valores se corresponden con el enumerado (TTipoServicio):

    // Tipo de servicios (tabla DAT_ESTADOS_SERVICIOS)
    // Id: 9300-9399
    //
    TTipoServicio=(
        tipoServicio_alertas = 10
    );  //9300

N_INSTANCIA

Por si hubiera mas de una instancia del servicio, por defecto 0.

E_ESTADO_SERVICIO

Estado del servicio, los valores se corresponden con el enumerado (TEstadoServicio):

    // Estado del servicio (tabla DAT_ESTADOS_SERVICIOS)
    // Id: 9400-9399
    //
    TEstadoServicio=(
        estadoServicio_desconocido = 0,
        estadoServicio_ok = 10,
        estadoServicio_alarma = 100
    );  //9400

N_VALOR

Un valor numérico por si queremos reflejar algún valor.

D_FECHA_ACTUALIZACION

Esta fecha se actualiza automáticamente si se inserta o se modifica el registro de la tabla.

5.2 Procedimiento almacenado

Se ha creado un procedimiento almacenado para insertar/modificar los registros:

ACD_PROC_ESTADO_SERVICIO

Este procedimiento tiene como parámetros:

ID_APLICACION

E_TIPO_SERVICIO

E_ESTADO_SERVICIO

N_VALOR

5.3 Zabbix

Para monitorizar el sistema se utiliza Zabbix.

Se crea el fichero UserParameter con el contenido:

UserParameter=asterisk.mdalertas[*],sudo /usr/sbin/asterisk -rx 'aler show' | grep -o '$1\=[0-9]*' | cut -f 2 -d "="

Se crean los ítems como en la imagen adjunta, poniendo entre los corchetes la variable a monitorizar:

En el servidor zabbix de la maquina hay una gráfica para el nodo ParCar donde se pueden visualizar dichas variables.

La monitorización de app_mdalertas se hará ejecutando, desde agente zabbix, el siguiente comando cada 30 minutos, en explotación; y 5 minutos en pruebas:

root@ParCar:/usr/src/MDtel/asterisk# asterisk -rx 'aler show' 
aler debug=0 errores=0 caducados=0 alertas_en_curso=0 aler_mem=0

La interpretación de la respuesta es:

• Si la respuesta no comienza con "aler", es que el módulo no está correctamente cargado.
• El valor de "debug" [0|1] indica si está activa la depuración. Puede ignorarse.
• El valor de "errores" es un contador de éstos. Debe ser cero o debe analizarse el log de Asterisk para buscar la fuente del problema que seguro existe.
• El valor de "caducados". también es un contador, indica situaciones de emergencia con antigüedad superior a una hora. Lo más probable es que se trate de algún tipo de fuga de memoria, por lo que debemos buscar la llamada y analizarla para depurar un problema.
• El valor de "alertas_en_curso" es un contador que indica cuántas alertas hay en curso. Puede ignorarse, excepto por el caso de que sea cero y el contador siguiente ("aler_mem" ) tenga un valor superior a cero. Si es así, hay un problema que debe diagnosticarse.
• El valor "aler_mem" puede ignorarse, excepto en lo indicado en el punto anterior.

Una vez conocido el problema, pueden reiniciarse los contadores con el comando Asterisk:

"module reload app_mdalertas.so" 

¡Cuidado! este comando (de muy rápida ejecución) sólo debe ejecutarse sin alertas en curso.

Se crea el fichero /etc/zabbix/zabbix_agentd.conf.d/UserParameter_MDalertas.conf con el contenido:

UserParameter=asterisk.mdalertas[*],sudo /usr/sbin/asterisk -rx 'aler show' | grep -o '$1\=[0-9]*' | cut -f 2 -d "="

Se modifica el template Vivait-Call Asterisk.xml donde se crean los items.

Para generar llamadas automáticas para monitorizar el servicio de alertas crearemos el script /usr/local/sbin/generarLlamada_Alertas.sh y su correspiondiente cron.d generarLlamada_Alerta

#!/bin/sh

asterisk -rx "originate local/9899@Cen_InicioLlamada_Emer_Test_ENTRAFUE extension 899@Cen_InicioLlamada_Emer_Test_ENTRADEN"
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
30  0    * * *   root    generarLlamada_Alertas.sh

Donde el 9899 será un VDN corporativo en la maquina donde esté el módulo de alertas y los contextos Cen_InicioLlamada_Emer_Test_ENTRAFUE y Cen_InicioLlamada_Emer_Test_ENTRADEN estarán creados en el fichero ext_InicioLlamada_Emer_Particular.conf

[Cen_VDN_9899]

;----------------------------------------------------------------------------------------------------------------
;----------------------- VDN 9899 ----------------------------------
;----------------------------------------------------------------------------------------------------------------
exten => _X.,1,NoOp(MDVDN_9899*****EXTEN=${EXTEN}**CID=${CALLERID(NUM)}**UCID=${UCID}*)

 same  =>     n,Answer

 same  =>     n,Goto(Cen_VDN_Alertas,9999,1)

 same  =>     n,HangUp(16)

include => Cen_finLlamada

Esto llamará al vdn de alertas 9999, que estará creado por defecto en el fichero MDalertas.conf de la siguiente forma:

[9999_vdn]
vdn=9999
id_entidad=0
id_servicio=0
tipo_servicio=10
sin_segmentos=yes
grabacion_msj_prefijo=/var/spool/MDtel/Alertas/Pruebas/
locucion_comunicacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_notif
locucion_confirmacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_confir
locucion_informacion=/var/lib/asterisk/sounds/Alertas/ALE_emer_dejar
locucion_secundario=/var/lib/asterisk/sounds/WEB/Alertas/locicion_secundario
cad_copia_wav1=-
cad_copia_wav2=-
tiempo_descolgado=5
tiempo_confirmacion=10
tiempo_grabacion=60
eje1=01
autorizada=no

[9999_dest_0000]
secundario=no
destino=9898
origen_nombre=pruebas_1
origen_num=1000
confirmar=yes
funcion=0
id_destino=0

El destino 9898 será un VDN corporativo y estará en la maquina donde se ejecute el script de la llamada automática generarLlamada_Alertas.sh

[Cen_VDN_9898]

;----------------------------------------------------------------------------------------------------------------
;----------------------- VDN 90000 ----------------------------------
;----------------------------------------------------------------------------------------------------------------
exten => _X.,1,NoOp(MDVDN_9898*****EXTEN=${EXTEN}**CID=${CALLERID(NUM)}**UCID=${UCID}*)

 same  =>    n,Answer
 same =>     n,AMD(670,1500,800,5000,100,50,20,256,5000)
 ;same =>     n,AMD()
 same =>     n,NoOp(MDMCAMDST*AMDSTATUS=${AMDSTATUS}*AMDCAUSA=${AMDCAUSE}*)
 same =>     n,Goto(${AMDSTATUS})
 same =>     n(NOTSURE),Goto(fin)
 same =>     n(HUMAN),System(/usr/local/bin/zabbix_sender -z 127.0.0.1 -s Homologacion-Corp1 -k "mdalertatest" -o 1)
 same =>     n,MDintz(nimitz|bd|sqlSinEspera|call ACD_PROC_ESTADO_SERVICIO(9,10,0,10,0))
 same =>     n,Goto(fin)
 same =>     n(MACHINE),System(/usr/local/bin/zabbix_sender -z 127.0.0.1 -s Homologacion-Corp1 -k "mdalertatest" -o 0)
 same =>     n,MDintz(nimitz|bd|sqlSinEspera|call ACD_PROC_ESTADO_SERVICIO(9,10,0,100,0))
 same =>     n,Goto(fin)
 same =>     n(HANGUP),Goto(fin)

 same =>     n(fin),Hangup()

include => Cen_finLlamada

Donde pone zabbix_sender hay que poner la IP y nombre del servidor de zabbix.

Esto solo monitoriza el camino de la llamada entre dos maquinas internas, hay que hablar con el operador para que nos proporcione DDIs para probar los primarios, los trunksips, etc...

5.4 Log's

Los log’s están en: var/log/asterisk/full

Hay que filtrar las llamadas por el origen, destino, VDN de emergencia, …

A partir de este filtro se obtendrá el ucid, éste es único por lo que facilitará seguir el hilo de una llamada. También se pueden buscar los destinos, nos ayudará a encontrar las llamadas que buscamos.