Manual de operación plataforma VIVAit

Producto:	VIVAit Call VIVAit Suite

1 Introducción

En este documento se describe la arquitectura general de la plataforma VIVAit, detallando aquellos procesos principales que componen cada uno de los elementos del sistema, y sus principales elementos de diagnóstico Quedan fuera del ámbito de este documento:

• Uso de aplicación de agente (VIVAit Desk)
• Uso de aplicación de supervisor (VIVAit Supervisor), incluyendo sus módulos autónomos (VIVAit reporting, VIVAit Tracker)
• Uso de portal de administración
• Uso de portal de traceo de llamadas y agentes (VIVAit Tracker web)
• Uso de portal de monitorización zabbix

2 Arquitectura

[| Volver al índice]

3 Descripción de los elementos, diagnósticos y operaciones

Las siguientes tablas definen los principales elementos software de la plataforma VIVAit, que son detallados en apartados siguientes:

Nivel de sistema operativo

Elemento	Instancias	Propósito	Producto	Observaciones
Ubuntu Server LTS 64 bits	Uno por servidor		VIVAit Call VIVAit Suite	Actualmente (Oct-2015) 14.04 Bajo proyecto puede cambiarse
Almacenamiento de grabaciones	Uno por sistema	Almacenamiento de las grabaciones, ya sean de entorno corporativo o de contact center	VIVAit Call VIVAit Suite	Típicamente un espacio grande de almacenamiento proporcionado por el cliente y que se monta como un sistema de archivos local en los servidores de la plataforma Pueden existir sistemas secundarios de almacenamiento de grabaciones

Nivel de conmutación de voz

Elemento	Instancias	Propósito	Producto	Observaciones
Asterisk 1.4.24 by MDtel	Uno por servidor ACD	Núcleo de conmutación de voz basado en Asterisk 1.4 y modificado por MDtel	VIVAit Suite	Fuertemente modificado por MDtel En el futuro migrará a Asterisk 13 Certified
Dialplan ACD by MDtel	Uno por servidor ACD	Configuración de voz	VIVAit Suite	En el futuro se unificará con corporativa
Asterisk 13 Certified by MDtel	Uno por servidor corporativo/gateway	Núcleo de conmutación de voz basado en Asterisk 13 y modificado por MDtel	VIVAit Call VIVAit Suite	Actualmente asterisk estándar (10/15) La instalación contempla descargar de la red el más actualizado, siempre CERTIFIED"
Dialplan corporativo	Uno por servidor corporativo/gateway	Configuración de voz	VIVAit Call VIVAit Suite	En el futuro se unificará con ACD

Nivel de base de datos

Elemento	Instancias	Propósito	Producto	Observaciones
MySQL 5.5	Donde haya BBDD de cualquier tipo (incluso zabbix)	Motor de Base de Datos	VIVAit Call VIVAit Suite	A efectos prácticos va a ser en todos los servidores con casi total seguridad
BBDD tiempo real	Una por sistema	Base de Datos sobre la que trabaja todo el entorno de tiempo real	VIVAit Call VIVAit Suite
BBDD réplica	Una por sistema multinodo	Base de Datos para acceso a información de reporting…y similar	VIVAit Call VIVAit Suite	Bajo proyecto puede existir más de una En el nodo en el que exista réplica existirá además copia (excepto nodo ACD)
BBDD copia	Uno por servidor corporativo/gateway	Copias de tablas de configuración para respaldo de la misma	VIVAit Call VIVAit Suite	Local en cada nodo Los nodos de ACD actualmente no trabajan con copia; en caso de fallo de BBDD TR se usa el modo emergencia

Nivel de procesos VIVAit

Elemento	Instancias	Propósito	Producto	Observaciones
Intz-Nimitz	Donde haya una BBDD de tiempo real o copia	Interfaz entre el dialplan y la base de datos	VIVAit Call VIVAit Suite	No donde haya BBDD de réplica Sistemas grandes pueden contemplar mas de un intz-nimitz central"
vivait-cti	Uno por servidor ACD	Interfaz entre VIVAit Desk, supervisor y el manager de asterisk	VIVAit Suite
myAcdSuperv	Uno por servidor ACD	Recopilador de datos de asterisk y actualiza en la BBDD Genera llamadas en el marcador	VIVAit Suite
motorSal	Uno por sistema con ACD	Motor de marcador saliente automático	VIVAit Suite	Solo si hay marcación saliente Junto a la BBDD de tiempo real
recordCentral	Uno por sistema	Servidor de grabaciones, se conectan los agentes a el	VIVAit Call VIVAit Suite	Se arrancan varias instancias en función del número de nodos Debe instalarse en un servidor que tenga el almacenamiento de grabaciones en su sistema de archivos
recordNodo	Uno por servidor corporativo/gateway	Agente de grabación	VIVAit Call VIVAit Suite
bdCentral	Uno, en el nodo con la BBDD de tiempo real	Genera la base de datos que se copiará para respaldo a otros nodos	VIVAit Call VIVAit Suite
bdNodo	En cada nodo con BBDD de copia	Recoge la base de datos del servidor central con el objeto de tener el respaldo	VIVAit Call VIVAit Suite
Actualizador	Uno por sistema con ACD	Se encarga de proporcionar las versiones actualizadas de las aplicaciones de puesto de trabajo	VIVAit Suite	En el mismo servidor que el portal de administración
phoneProv-tftp	Uno por sistema	Se encarga del aprovisionamiento masivo de terminales	VIVAit Call VIVAit Suite	En instalaciones grandes habrá más de uno, quizás uno por sede grande; depende de la infraestructura de DHCP
borraregistrosnimitz
Mover grabaciones a nube

Administración

Elemento	Instancias	Propósito	Producto	Observaciones
Tomcat 7	Uno por servidor con portales	Servidor de aplicaciones JAVA	VIVAit Call VIVAit Suite
Portal admón	Uno por sistema	Portal de administración del sistema	VIVAit Call VIVAit Suite	Bajo proyecto puede existir más de uno
Portal usuario	Uno por sistema	Portal de usuario, para acceso a buzones, su configuración	VIVAit Call	Bajo proyecto puede existir más de uno
Tracker web	Uno por sistema	Portal de seguimiento de llamadas	VIVAit Call VIVAit Suite	Debe instalarse en un servidor que tenga los ficheros de grabación montados en su sistema de archivos Ligado a recordCentral Bajo proyecto puede existir más de uno
Monitor	Uno por sistema	Portal de monitores de pared de Call Center	VIVAit Suite	Bajo proyecto puede existir más de uno
Apache	Uno por servidor de calendarios	Servidor de portales WEB	VIVAit Call VIVAit Suite
Servidor de calendarios	Uno por sistema	Aloja calendarios para su uso en diferentes entornos de NIMITZ	VIVAit Call VIVAit Suite	Bajo proyecto puede existir más de uno

Monitorización

Elemento	Instancias	Propósito	Producto	Observaciones
Servidor zabbix	Uno por instalación	Monitorización técnica y de negocio	VIVAit Call VIVAit Suite	Bajo proyecto puede existir más de uno Tipicamente irá o en BBDD replica o en nodo de gestión en instalaciones grandes
Templates zabbix	Uno por instalación	Adaptaciones específicas	VIVAit Call VIVAit Suite
Agente Zabbix	Uno por servidor	Agente de monitorización	VIVAit Call VIVAit Suite
Scripts monitorización zabbix	Uno por servidor	Agente de monitorización	VIVAit Call VIVAit Suite

[| Volver al índice]

3.1 Sistema Operativo

Los sistemas operativos de nuestra plataforma se corresponden a las versiones de Ubuntu Server LTS , ya que son las versiones estables, con un soporte continuado y mas estables a actualizaciones desde la salida Ubuntu 14.04.1. En concreto el sistema operativo utilizado para la plataforma VIVAit es Ubuntu Server 14.04.4 LTS. Para más información https://help.ubuntu.com/lts/serverguide/index.html.

3.1.1 Funcionamiento en cluster

En caso de existir funcionamiento en cluster se basa en:

• Heartbeat: IP flotante entre las dos máquinas que componen el cluster; típicamente este "latido" entre máquinas se realizará mediante conexión directa con cable cruzado para asegurar que no existan problemas de comunicaciones tales como retardo, pérdida de paquetes, etc en este latido y pueda ser causa de un balanceo inadecuado.

Nota 17-11-2015: Se ha realizado en un cliente un cluster distribuido, con dos servidores en diferentes sedes, realizando el heartbeat mediante enlace Gigabit. Si bien la solución no está validada por desarrollo, se está observando el funcionamiento.

• DRBD que se encargar de mantener una serie de carpetas totalmente replicadas entre los dos nodos; dichas las carpetas son:

El cluster es activo/pasivo; la máquina activa posee la IP flotante y tiene arrancados los servicios.

3.1.2 Configuración del cluster

Para montar un cluster de asterisk partimos de la siguiente situación inicial:

• Dos maquinas con VIVAit Call 3.0 instalado.
• El driver bonding de Interfaces de Red en Ubuntu Server.

Los pasos a seguir para la configuración en el Ubunto Server son los siguientes:

• Instalar ifenslave:

aptitude install ifenslave.

Finalizada la instalación, comprobamos que la instalación de Bonding se ha configurado para empezar desde el arranque del sistema operativo desde el fichero /etc/modules:

vi /etc/modules # /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. # Parameters can be specified after the module name. lp rtc bonding

• Crear o editar el archivo llamado /etc/modprobe.d/bonding.conf y añadir la siguiente linea en negrita:

echo "alias bond0 bonding"> /etc/modprobe.d/bonding.conf

• Editar el fichero /etc/network/interfaces y añadir lo que esta en negrita:

# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # Bonding #em1 ip manual y esclavo en el "bond0" NIC auto em1 iface em1 inet manual bond-master bond0 bond-primary em0 #em2 ídem, creando así un vínculo de enlace 2. auto em2 iface em2 inet manual bond-master bond0 auto bond0 iface bond0 inet static address 10.255.255.11 netmask 255.255.255.0 gateway 10.255.255.254 bond-mode active-backup bond-miimon 100 bond-slaves none # em3 replica entre servidores auto em3 iface em3 inet static address 10.255.254.10 netmask 255.255.255.0 # em4 gestion auto em4 iface em4 inet static address 172.17.47.255 netmask 255.255.0.0

• Reiniciamos el sistema para que el kernel tome los cambios.

• Comprobación que en las dos maquinas el archivo /etc/host contenga el los nombre de las dos maquinas a vincular. En el ejemplo el archivo en ambas maquinas es:

127.0.0.1 localhost 10.255.255.11 vivaitcall-CL-UAH-1 10.255.255.12 vivaitcall-CL-UAH-2 10.255.255.10 vivaitcall-CL-UAH 10.255.255.10 BDTR 10.255.254.10 vivaitcall-CL-UAH-1-em3 10.255.254.11 vivaitcall-CL-UAH-2-em3

• Creamos dos particiones iguales en ambos ordenadores , usando el comando parted.

root@vivaitcall-CL-UAH-1:~# parted /dev/sda GNU Parted 2.3 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p free Model: HP LOGICAL VOLUME (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 17,4kB 262kB 245kB Free Space 1 262kB 1000MB 1000MB fat32 boot 2 1000MB 201GB 200GB ext4 3 201GB 217GB 16,0GB linux-swap(v1) 4 217GB 237GB 20,0GB ext4 237GB 1000GB 763GB Free Space (parted) mkpart primary 237GB 1000GB (parted) p free Model: HP LOGICAL VOLUME (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 17,4kB 262kB 245kB Free Space 1 262kB 1000MB 1000MB fat32 boot 2 1000MB 201GB 200GB ext4 3 201GB 217GB 16,0GB linux-swap(v1) 4 217GB 237GB 20,0GB ext4 5 237GB 1000GB 763GB primary  No File System como ext4 1000GB 1000GB 204kB Free Space (parted)quit mkfs.ext4 /dev/sda5 root@vivaitcall-CL-UAH-1:~# parted /dev/sda GNU Parted 2.3 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p free Model: HP LOGICAL VOLUME (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 17,4kB 262kB 245kB Free Space 1 262kB 1000MB 1000MB fat32 boot 2 1000MB 201GB 200GB ext4 3 201GB 217GB 16,0GB linux-swap(v1) 4 217GB 237GB 20,0GB ext4 5 237GB 1000GB 763GB primary 1000GB 1000GB 204kB Free Space (parted) rm 5 (parted) mkpart primary 237GB 1000GB (parted) p free Model: HP LOGICAL VOLUME (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 17,4kB 262kB 245kB Free Space 1 262kB 1000MB 1000MB fat32 boot 2 1000MB 201GB 200GB ext4 3 201GB 217GB 16,0GB linux-swap(v1) 4 217GB 237GB 20,0GB ext4 5 237GB 1000GB 763GB ext4 primary  Si File Sytem ext4 1000GB 1000GB 204kB Free Space (parted)quit

• Instalar los paquetes necesarios para el drbd. En Ubuntu server 14.04 ya está instalado.

aptitude install drbd8-utils aptitude update (si no instala el drbd8-utils actualizar) aptitude install drbd8-utils (volver a lanzar)

• Creamos el archivo /etc/drbd.conf en ambas maquinas:

# You can find an example in /usr/share/doc/drbd.../drbd.conf.example include "drbd.d/global_common.conf"; include "drbd.d/*.res"; resource MDcluster { protocol C; on vivaitcall-CL-UAH-1 { device /dev/drbd0; disk /dev/sda5; address 10.255.254.10:7788; meta-disk internal; } on vivaitcall-CL-UAH-2 { device /dev/drbd0; disk /dev/sda5; address 10.255.254.11:7788; meta-disk internal; } disk { on-io-error detach; } net { max-buffers 2048; ko-count 4; } syncer { rate 100M; al-extents 257; } startup { wfc-timeout 0; degr-wfc-timeout 120; } }

• Reiniciamos el sistema para que el kernel tome los cambios.
• Inicializamos el recurso, para ello primero deberemos crear los recursos DRBD teclearemos en ambas maquinas. Desde /etc.

drbdadm create-md MDcluster (no y yes )

Si tenemos algún problema porque ya exista sistema de ficheros.

dd if=/dev/zero of=/dev/sda5 bs=1M count=128 drbdadm create-md MDcluster (no y yes )

• Reiniciamos ambas maquinas para que su kernel tome los cambios.
• Levantamos el servicio del DRBD en ambos servidores (nos preguntara que si queremos enviar los datos a los desarrolladores de drbd) tecleando no, no se envían.

service drbd start /etc/init.d/drbd start

Ahora ambas maquinas son secundarias.

Indicar cual de las dos maquinas usaremos como primaria, por tanto en la maquina elegida habra que ejecutar:

drbdadm -- --overwrite-data-of-peer primary all (en una máquina) Nota: La ip virtual que va a estar asignada a la maquina activa es 172.25.129.70.

Podemos teclear el comando cat para ver si esta sincronizando y su progreso:

cat /proc/drbd Nota: El servicio DRBD aparecera como Primary/Secondary si ejecutamos en el primario ; y aparecerá 'Secondary/Primary' si lo ejecutamos en el secundario.

• Instalación de los script de arranque:

update-rc.d -f drbd remove (en las dos maquinas) update-rc.d drbd start 13 2 3 4 5 . stop 87 0 1 6 . (en las dos máquinas)

• Seleccionar la fuente de sincronización.

Formateamos un disco de la maquina que queramos que funcione como fuente del servicio DRBD, para evitar conflictos:

mkfs.ext4 /dev/drbd0

Creamos el directorio sobre el que vamos a montar el disco, en ambas maquinas.

mkdir /HDcluster

Creamos un archivo dentro /HDcluster de que se verá solo cuando el disco no está montado en ambas maquinas.

touch sinMontar Nota: Este archivo nos puede servir para monitorizar mediante zabbix, nagios, ... que el disco no está montado.

 En una de las maquinas montamos el disco (desde fuera del directorio HDcluster)

mount /dev/drbd0 /HDcluster

• Procedemos a mover todos los datos que necesitemos en este disco y a crear accesos directos, los directorios que vamos a mover son los siguientes:

/etc/asterisk /var/lib/asterisk /usr/lib/asterisk /usr/spool/asterisk /var/lib/mysql /var/tftp/

El procedimiento que vamos a seguir es el siguiente, en el primer ordenador:

Cd /HDcluster tar -zcvf etc-asterisk.tgz /etc/asterisk tar -zxvf etc-asterisk.tgz rm -rf /etc/asterisk ln -s /HDcluster/etc/asterisk /etc/asterisk tar -zcvf var-lib-asterisk.tgz /var/lib/asterisk tar -zxvf var-lib-asterisk.tgz rm -rf /var/lib/asterisk ln -s /HDcluster/var/lib/asterisk /var/lib/asterisk tar -zcvf usr-lib-asterisk.tgz /usr/lib/asterisk tar -zxvf usr-lib-asterisk.tgz rm -rf /usr/lib/asterisk ln -s /HDcluster/usr/lib/asterisk /usr/lib/asterisk tar -zcvf var-spool-asterisk.tgz /var/spool/asterisk tar -zxvf var-spool-asterisk.tgz rm -rf /var/spool/asterisk ln -s /HDcluster/var/spool/asterisk /var/spool/asterisk tar -zcvf var-lib-mysql.tgz /var/lib/mysql tar -zxvf var-lib-mysql.tgz rm -rf /var/lib/mysql ln -s /HDcluster/var/lib/mysql /var/lib/mysql tar -zcvf var-lib-phoneprov-tftp.tgz /var/lib/phoneprov-tftp/ tar -zxvf var-lib-phoneprov-tftp.tgz rm -rf /var/lib/phoneprov-tftp/ ln -s /HDcluster/var/lib/phoneprov-tftp /var/lib/phoneprov-tftp

En la segunda maquina debemos borrar los directorios y crear los accesos directos.

rm -rf /etc/asterisk ln -s /HDcluster/etc/asterisk /etc/asterisk rm -rf /var/lib/asterisk ln -s /HDcluster/var/lib/asterisk /var/lib/asterisk rm -rf /usr/lib/asterisk ln -s /HDcluster/usr/lib/asterisk /usr/lib/asterisk rm -rf /var/spool/asterisk ln -s /HDcluster/var/spool/asterisk /var/spool/asterisk rm -rf /var/lib/mysql ln -s /HDcluster/var/lib/mysql /var/lib/mysql rm -rf /var/lib/phoneprov-tftp ln -s /HDcluster/var/lib/phoneprov-tftp /var/lib/phoneprov-tftp

• Configurar heartbeat para las dos maquinas.

Instalamos heartbeat en las dos maquinas. En UBUNTU Server 14.04 ya está instalado.

aptitude install heartbeat

Debemos modificar 3 ficheros en cada una de las maquinas, estos se encuentran en /etc/ha.d. El primer fichero a modificar es ha.cf.:

En la maquina vivaitcall-CL-UAH-1 es: 

root@vivaitcall-CL-UAH-1:~# cat /etc/ha.d/ha.cf # Explicacion en /usr/share/doc/heartbeat/ha.cf.gz udpport 694 baud 19200 auto_failback off use_logd yes crm no # Temporizaciones en segs logfacility local0 keepalive 2 deadtime 8 warntime 16 initdead 64 deadping 6 #ucast bond0 vivaitcall-CL-UAH-1 ucast bond0 vivaitcall-CL-UAH-2 #ucast em3 vivaitcall-CL-UAH-1-em3 ucast em3 vivaitcall-CL-UAH-2-em3 #Ping a puerta de enlace,gw1,gw2,gw3,gw4 ping_group red_local 10.255.255.12 respawn hacluster /usr/lib/heartbeat/ipfail apiauth ipfail gid=haclient uid=hacluster node vivaitcall-CL-UAH-1 node vivaitcall-CL-UAH-2

Y en la maquina vivaitcall-CL-palacio-2 es:

root@vivaitcall-CL-UAH-1:~# cat /etc/ha.d/ha.cf # Explicacion en /usr/share/doc/heartbeat/ha.cf.gz udpport 694 baud 19200 auto_failback off use_logd yes crm no # Temporizaciones en segs logfacility local0 keepalive 2 deadtime 8 warntime 16 initdead 64 deadping 6 ucast bond0 vivaitcall-CL-UAH-1 #ucast bond0 vivaitcall-CL-UAH-2 ucast em3 vivaitcall-CL-UAH-1-em3 #ucast em3 vivaitcall-CL-UAH-2-em3 #Ping a puerta de enlace,gw1,gw2,gw3,gw4 ping_group red_local 10.255.255.12 respawn hacluster /usr/lib/heartbeat/ipfail apiauth ipfail gid=haclient uid=hacluster node vivaitcall-CL-UAH-1 node vivaitcall-CL-UAH-2

Nota: El parámetro auto_failback se utiliza para indicar si queremos que al recuperarse una maquina adquiera los recursos sobre los que tiene prioridad.

El segundo fichero es authkeys,, este fichero es el mismo en ambas maquinas:

chmod 600 authkeys (importante) auth 1 1 sha1 claveSecretaATope

El tercer fichero haresources, donde especificaremos en las dos maquinas que deben apuntar a la maquina que queremos que tenga prioridad en la adquisición de los recursos, este fichero es el mismo en las dos maquinas:

MÁQUINA 1 -> vivaitcall-CL-palacio-1 hb_mdtel MÁQUINA 2-> vivaitcall-CL-palacio-1 hb_mdtel

Copiaremos en el directorio /etc/ha.d/resource.d/ los scripts de arranque con permisos 755 (lo podemos hacer mediante WINSCP). Los scripts se encuentran en C:\Documents and Settings\javier.gutierrez.MDTEL\Mis documentos\Centrales\Asterisk\Cluster\scripts.

chmod 755 hb_catalina chmod 755 hb_mdtel chmod 755 hb_mdtel_firewall

Deberemos editar el archivo hb_mdtel

(IP flotante a.b.c.d./mask) 10.255.255.10 CAD_IP_FLOTA=10.255.255.10/24/bond0

• Paramos el proceso myAcdSuperv.

mv /etc/rc2.d/S02myAcdSuperv s02myAcdSuperv

• Reiniciamos ambas maquinas para que su kernel tome los cambios.

[| Volver al índice]

3.1.3 Comprobación de buen funcionamiento del cluster

• La maquina activa tiene que tener en HDcluster montado el disco con todos sus directorios y la maquina inactiva no (tenemos que ver el archivo que hemos creado "sinMontar"). 
• La ip virtual tiene que estar en la maquina activa (ifconfig) y no tiene que estar en la inactiva. 
• El asterisk tiene que estar arrancado en la maquina activa y parado en la inactiva. 
• Tecleando la ip de la maquina activa en un navegador debemos acceder al portal de vivait-call y en la inactiva no debe de estar activo. 
• Para cambiar el cluster manualmente podemos utilizar los siguientes comandos:

/usr/share/heartbeat/hb_takeover

La maquina desde la que se ejecuta se convierte en la maquina activa

/usr/share/heartbeat/hb_standby

La maquina desde la que se ejecuta deja de ser la maquina activa

3.1.4 Notas para MySQL

Si mysql es parte del cluster tenemos que tener en cuenta dos cosas:

• El archivo /etc/mysql/debían.cnf contiene una clave que debe ser igual en ambas maquinas y debe ser la clave de la máquina de donde cojamos la base de datos.
  

# Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localhost user = debian-sys-maint password = AI6AdPtnhLUrNm1S socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] user = debian-sys-maint password = AI6AdPtnhLUrNm1S socket = /var/run/mysqld/mysqld.sock basedir = /usr

• El archivo /etc/apparmor.d/usr.sbin.mysqld contiene donde pueden estar ubicados los archivos de mysql, al cambiar su ubicación y poner un enlace directo en /var/lib/mysql si no modificamos este archivo mysql no arrancara al no tener la nueva ubicación entre sus localizaciones permitidas. Este es un ejemplo de las líneas que debemos añadir.
  

/var/run/mysqld/mysqld.sock w, (copiar después de esta linea) #//!! /HDcluster/var/lib/mysql/ r, /HDcluster/var/lib/mysql/** rwk, #//!!

3.1.5 Notas de desincronización

EL servicio del DRBD esta iniciado pero al teclear el comando cat /proc/drbd para ver si esta sincronizando se presenta "primary/unknown" y/o secondary/unknown ".

• En el nodo primary

drbdadm connect all

• En el nodo secondary

drbdadm disconnect all drbdadm -- --discard-my-data connect all

3.1.6 Adaptar red a cliente

Para adaptar la red de los equipos al entorno del cliente hay que editar los siguientes ficheros:

/etc/network/interfaces /etc/resolv.conf /etc/hosts /etc/ha.d/resource.d/hb_mdtel /etc/ha.d/ha.cf - TFTP: /etc/inetd.conf (IP del cluster)

Tras la modificaciones oportunas, se debe reiniciar las dos máquinas para cargar las nuevas configuraciones.

[| Volver al índice]

3.2 Matriz de conmutación

Encontramos dos diferentes núcleos de conmutación en la plataforma VIVAit:

• Para los nodos de procesamiento ACD el núcleo de conmutación es asterisk 1.4 RSP con fuertes modificaciones realizadas por MDtel en determinados módulos (queues, chan_spy entre otros)

• Para los nodos que realizan funcionalidad de gateway y/o procesamiento de telefonía corporativa, se utiliza como núcleo de conmutación asterisk 13, versión certified

https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Documentation

3.2.1 Dialplan

En función del nodo en el que estemos trabajando, encontraremos dos tipos de dialplan:

• Dialplan ACD --> Dialplan que aplica a nodos ACD
• Dialplan corporativa --> Dialplan que aplica a nodos de corporativa o gateways (ya sean de corporativa o ACD)

En la plataforma VIVAit, el dialplan es parte fundamental de la plataforma, no pudiendo ser modificado o sustituido de manera no planificada

[| Volver al índice]

3.3 Servicios networking

Son muy importantes las configuraciones adecuadas de los servicios de:

• NTP: El sistema en global ha de estar sincronizado; todos los servidores y puestos de trabajo (en el caso de VIVAit Suite) han de estar perfectamente sincronizados; los servidores de la plataforma se sincronizarán con el NTP del cliente; si el cliente no tiene NTP será necesario que un servidor de la plataforma se sincronice con un NTP externo y este sea el servidor para el resto de la plataforma

• DNS: La configuración de DNS de la plataforma será coherente con el resto de la plataforma IT del cliente

• DHCP: Es necesario coordinar con el cliente la asignación de direcciones para los diferentes elementos de la plataforma VIVAit, fundamentalmente para terminales telefónicos; en este caso además será necesario activa la opción 66 que permitirá definir el servidor TFTP del que los terminales cogerán sus ficheros de aprovisionamiento

3.4 Bases de datos (BBDD)

La base de datos del sistema se basa en el motor de base de datos MySQL, es un elemento crítico del sistema, en el que insertan y del que obtiene mucha información múltiples procesos. Muchas comunicaciones entre procesos se realizan vía Base de Datos (tabla COM_COMUNICADOS). Pueden existir distintas instancias de base de datos que explicadas en las siguientes secciones, nuestra base de datos tiene la siguiente estructura: Información completa de la BD. Podéis ampliar más información en https://dev.mysql.com/doc/

3.4.1 BBDD Tiempo Real

En la base de datos de tiempo real insertan información todos los procesos del sistema, y se realizan los cambios en configuración utilizando como herramienta el portal de administración y VIVAit Supervisor

De la base de datos de tiempo real leen los procesos que requieren información, y las aplicaciones:

• VIVAit Supervisor (para reporting de tiempo real)
• PanelWeb
• Datos de sesión de VIVAit Desk
• Monitorización Zabbix
• Otros

El portal de administración se encarga de escribir las configuraciones añadidas o modificadas en la base de datos

3.4.2 BBDD Réplica

A efectos de asegurar las prestaciones del sistema, se establece una réplica de la base de datos, sincronizada con la de tiempo real; los procesos y aplicaciones pesados, que realicen consultas a las base de datos que puedan comprometer las prestaciones del sistema atacan a la réplica y nunca a la base de datos de tiempo real

Es posible que en instalaciones pequeñas no exista réplica, en cuyo caso se establece una base de datos unificada sobre la de tiempo real, en la que se añaden índices y procedimientos almacenados que típicamente residen en la de réplica.

Es posible establecer tantas réplicas como sean necesarias si diferentes procesos pesados se penalizan en exceso, si bien una implantación tipo contemplará una sola

Algunos procesos que utilizan la base de datos de réplica son:

• VIVAit Reporting
• VIVAit Tracker
• Histórico en tiempo real de VIVAit Supervisor

IMPORTANTE: Ningún proceso, programa, aplicación, etc. escribe en la base de datos de réplica; tan solo se extrae información

3.4.3 BBDD de copia

A efectos de asegurar el funcionamiento y como medida de contingencia ante un problema puntual de comunicación con la BD de tiempo real, en cada nodo disponemos de una BD de copia local. Posiblemente de un tamaño menor que la BD de tiempo real, dependiendo de cuanto tiempo pase hasta la próxima sincronización con la base de tiempo real.Esta base de datos llamada nimitzCopia.

Solo entrara en funcionamiento,cuando se produzca el problema mencionado, dejando acceder a los datos y poder dar servicio a la empresa mientras se soluciona el problema.

3.4.3.1 Backup y restore

Se utilizan dos script, para realizar la copia de seguridad y restaurar en la base de datos de copia local que son:

• El proceso bdCentral.sh que es el encargado de realizar la copia de seguridad. Tiene un archivo de configuración bdCentral.conf. En este archivo hay un parámetro (IGNORE_TABLAS) que indica las tablas de las que NO se realizará copia de seguridad. Toda tabla que no se indique formará parte de la copia de seguridad. Vuelca los resultados en /var/log/bdCentral.log
• El proceso bdNodo.sh que es el encargado de descargar la copia de seguridad y restaurarla en local. Tiene un archivo de configuración bdNodo.conf. Vuelca los resultados en /var/log/bdNodo.log. El fichero de backup se copia mediante el usuario sincroniza, que deberá poder acceder sin contraseña al servidor donde reside la copia.

En caso de producirse algún error en alguno de los procesos, marcarán dicho error en el log con una línea que comienza con la cadena "*ERROR".

3.4.4 Diagnósticos y operaciones sobre bases de datos

Comandos importantes, desde dentro consola de Mysql:

show master status: Realizado desde el master
show slave status: Realizado desde el esclavo; el valor "seconds behind master" nos indica
cuanto está retrasada la réplica con respecto a la base de datos de tiempo real

[| Volver al índice]

3.5 Procesos propios

3.5.1 bdCentral

El proceso bdCentral.sh es el encargado de realizar la copia de seguridad. Tiene un archivo de configuración bdCentral.conf. En este archivo hay un parámetro (IGNORE_TABLAS) que indica las tablas de las que NO se realizará copia de seguridad. Toda tabla que no se indique formará parte de la copia de seguridad. Vuelca los resultados en /var/log/bdCentral.log

En caso de producirse algún error, se marcará dicho error en el log con una línea que comienza con la cadena "*ERROR".

Para ejecutar bdCentral:

bdCentral.sh /etc/MDtel/bdCentral.conf

Estos procesos se ejecutan automáticamente. Para ello está copiado el fichero bdCentral a /etc/cron.d.

Por defecto la programación vienen comentada por lo que será necesario activarlo.

Para que se roten los logs hay que copiar el fichero bdCentral.logrotate a /etc/logrotate.d (como bdCentral)

[| Volver al índice]

3.5.2 bdNodo

El proceso bdNodo.sh es el encargado de descargar la copia de seguridad y restaurarla en local. Tiene un archivo de configuración bdNodo.conf. Vuelca los resultados en /var/log/bdNodo.log. El fichero de backup se copia mediante el usuario sincroniza, que deberá poder acceder sin contraseña al servidor donde reside la copia.

En caso de producirse algún error, se marcará dicho error en el log con una línea que comienza con la cadena "*ERROR".

Para ejecutar bdNodo:

bdNodo.sh /etc/MDtel/bdNodo.conf

Estos procesos se ejecutan automáticamente. Para ello está copiado el fichero bdNodo a /etc/cron.d.

Por defecto la programación vienen comentada por lo que será necesario activarlo.

Para que se roten los logs hay que copiar el fichero bdNodo.logrotate a /etc/logrotate.d (como bdNodo)

[| Volver al índice]

3.5.3 Intz-Nimitz

Permite integrar procesos de asterisk (del dialplan) con la base de datos; por ejemplo es el que graba segmentos, inspecciona donde esta registrado un agente…etc. La estabilidad de este proceso es importante para el funcionamiento del sistema, si bien las llamadas entran en caso de no estar disponible.

Para mas información consultar la página de intz-nimitz.

Desde un SSH ejecuta el comando “nc ip_maquina 1115”

root@vivait-acd:~# nc localhost 1115
intz-nimitz sis ver='V02.6' inic='20140401 110116' alarmas=21 ultAlar='20140414 171244'
intz-nimitz gmp msj=942/1024 buf=1024/1024 tarea=16/102
intz-nimitz tmp uptime=1816550 (21d 0h 35m 50s)
intz-nimitz vic identif='cms1' entorno='nimitz' conx=0/128 numConx=1018(0)
intz-nimitz mys curro=80/0/0/0 soli=1012(0) soliErr=6(0) soliEncol=0(0/0)
intz-nimitz cache colas=128/10/0/0 vdn=128/8/0/0 usuExten=10/0/0/0

Donde cada parámetro monitorizado indica:

Parámetro	Descripción
sis/ver	Versión del proceso
sis/inic	Fecha de de arranque del proceso
Sis/alarmas	Alarmas desde arranque
Sis/ultAlar	Fecha de última alarma
Gmp/msj
Gmp/buf
Gmp/tarea
Tmp/uptime	Tiempo que lleva el servicio activo
Vic/identif	Etiqueta de identificación del servicio
Vic/entorno	Entorno de base de datos
Vic/conx	Conexiones activas/conexiones máximas
Vic/numConx	Conexiones totales (último minuto)
Mys/curro
Mys/soli	Conexiones solicitadas (último minuto)
Mys/soliErr	Conexiones solicitadas con error (último minuto)
Mys/soliEncol	Conexiones encoladas
Cache/cola	Colas monitorizadas/
Cache/vdn	VDN’s monitorizados
Cache/usuExten

[| Volver al índice]

3.5.4 motorSal

Parte fundamental del proceso de marcación saliente, gestiona como hay que llamar a los diferentes contactos asignados a las campañas. Transforma los contactos en intentos de marcación.

A efectos de diagnósticos, desde un SSH ejecuta el comando “nc ip_maquina 1120”

root@vivait-acd:~# nc localhost 1120
motorSal sis ver='V01.4' inic='20140725 140832' alarmas=1 ultAlar='20140725 140832'
motorSal gmp msj=253/256 buf=256/256 tarea=99/102
motorSal tmp uptime=600165 (6d 22h 42m 45s)
motorSal mtr mys=1 ocup=0% planif=28(0) intento=26(0)

Donde cada parámetro monitorizado indica:

Parámetro	Descripción
SIS/ver	Versión del proceso
SIS/inic	Fecha de de arranque del proceso
SIS/alarmas	Alarmas desde arranque
SIS/ultAlar	Fecha de última alarma
Gmp/msj
Gmp/buf
Gmp/tarea
Tmp/uptime	Tiempo que lleva corriendo
mtr/mys	Si está conectado al MySQL
mtr/ocup	Porcentaje de ocupación
mtr/planif	Contactos planificados Totales (Último minuto)
mtr/intento	Intentos totales (Ültimo minuto)

Respecto a los logs del motroSal consultar el siguiente apartado: Trazas motorSal

[| Volver al índice]

3.5.5 MyACDSuperv

Refleja el estado de las colas de asterisk en la base de datos; tiene sentido a efectos de estadísticas e informes, pero no a efectos de funcionamiento de la conmutación de voz

Es también el proceso que genera las llamadas en el marcador automático de VIVAit Suite

A efectos de diagnósticos, desde un SSH se ejecuta el comando “nc ip_maquina 1112”

root@vivait-acd:~# nc localhost 1112
myAcdSuperv SIS ver='04.6' inic='20140416 081613' alarmas=6 ultAlar='20140416 121652'
myAcdSuperv AMI cnx=1 ocup=28% exten=2/2/511 asig=0/11/4095
myAcdSuperv MYSQL cnx=1 ms=316

Donde cada parámetro monitorizado indica:

Parámetro	Descripción
SIS/ver	Versión del proceso
SIS/inic	Fecha de de arranque del proceso
SIS/alarmas	Alarmas desde arranque
SIS/ultAlar	Fecha de última alarma
AMI/cnx	Conectado (1) a asterisk
AMI/ocup	Porcentaje de ocupación de MyACDSuperv
AMI/exten	-
AMI/asig
MYSQL/cnx	Conectado (1) a MySQL
MYSQL/ms	Tiempo de última operación en ejecutarse

[| Volver al índice]

3.5.6 proceso escoba

El proceso escoba se encarga de resolver y consolidar todos aquellos segmentos de grabación que han quedado almacenados en los gateways por falta de información o incoherencias. Existen dos tipos de procesos escobas:

1. Proceso escoba perteneciente a nodo con agente de grabación (recordNodo) llamado escobaGW.pl.
2. Proceso escoba perteneciente o no a un servidor de grabación (recordCentral) llamado escobaGrabsBd.pl.

3.5.6.1 escobaGW.pl

Proceso que se ejecuta en los nodos busca en el disco RAM , las grabaciones de segmentos cuya antigüedad sea superior a mas de un día, es decir, si el proceso por ejemplo se ejecuta a la 01:00 a.m. del día 24/03/2016 buscara todas aquellas grabacionesn de segmentos realizadas antes de la 01:00 a.m del día 22/03/2016. Una vez realizada la busqueda, obtendra el UCID a traves del nombre del fichero, y comprobara su correspondencia con la tabla DAT_LLAMADAS. Si existe una llamada con ese UCID, cambiara el estado de la llamada para que sea procesada correctamente. En caso contrario, es movida a la carpeta /var/lib/recordNodo/grabError.

3.5.6.2 escobaGrabsBd.pl

Se ejecuta sobra la base de datos de histórico, normalmente se ejecuta en un servidor de grabación (recordCentral). El proceso hace una búsqueda en dos tablas:

• En DAT_SEGMENTOS obtiene todos aquellos segmentos con grabaciones que dieron error, su estado tendrá valor 120.

[| Volver al índice]

• En DAT_LLAMADAS obtendremos todos los registros correspondiente al segmentos anteriores.

Después hace una búsqueda en el sistema, usando como ruta el campo D_HORA_INICIO de cada llamada, que indica la ruta entera donde se encuentra el archivo. Una vez encontrado el archivo cambia el estado del segmento que tenia un error a estado de grabación disponible , que tendrá valor 100. Si no encontramos el segmento, no realizara nada.

3.5.7 recordCentral

Se considera como un servidor de grabaciones. Todas las grabaciones de llamadas son un activo importante y una empresa con Contact Center pueda recibir millones de llamadas que necesitan estar registradas y almacenadas en discos duros con gran capacidad, dichas maquinas donde suelen alojarse estos servidores poseen discos duros limitados, lo que hace necesario en algunos casos incorporar dispositivos NAS.

Los dispositivos NAS son dispositivos de almacenamiento conectados a una red que permite el almacenamiento y la recuperación de datos desde una ubicación centralizada, flexibles y escalables, lo que significa que a medida que necesite almacenamiento adicional, puede añadirlo al que tiene. Esto no indica que sea necesario poseer de dispositivos NAS para funcionar, sino que puede tomar datos de diferentes sitios.

En recordCentral pueden existir tres tipos de dispositivos NAS:

• Uno dedicado para las llamadas
• Uno dedicado para los segmentos
• Uno mixto para todas las llamadas y segmentos.

El recordCentral se encarga de recoger todas las grabaciones de segmentos que tienen de estado proceso(3) en cada nodo gestionado, es decir, coger aquellos segmentos de llamadas marcados como llamadas disponibles, las intenta descargar los segmentos de las llamadas y convertirlas al formato adecuado (MP3). Como una caracteristica particular cada diez minutos, siempre no tenga ninguna otra tarea, intenta ver si puede establecer conexión con un nodo en cuarentena, para sacarlos de cuarentena y recoger todas las grabaciones de segmentos disponibles, para intentar convertir e descargar todas las grabaciones.

A efectos de diagnósticos, desde un SSH se ejecuta el comando nc ip_maquina 1114 en la maquina donde creamos que debe estar ejecutando el proceso recordCentral. Ejemplo:

root@smadavacdrecord1:~# nc localhost 1114
recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423 160112'
recordCentral MYSQL cnx=1
recordCentral NAS llamadas=1 segmentos=1
recordCentral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305
recordCentral NODO fase=0 cuarentena= descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10'

La explicación de los campos se muestra en la tabla siguiente:

Parámetro	Descripción
SIS/ver	Versión del proceso
SIS/inic	Fecha de de arranque del proceso
SIS/alarmas	Alarmas desde arranque
SIS/ultAlar	Fecha de última alarma
MYSQL/cnx	Conectado (1) a MySQL
NAS/llamadas	Alojamiento en NAS de llamadas activo (grabación de llamada completa en un único archivo)
NAS/segmentos	Alojamiento en NAS de segmentos activo
REC/llamNum	Llamadas procesadas
REC/llamErr	Llamadas con error
REC/segmNum	Segmentos procesados
REC/segmErr	Segmentos con error
NODO/fase	Número de proceso de recordCentral
NODO/cuarentena	Lista de nodos en cuarentena, separada por comas
NODO/descarga	Lista de nodos en descarga, separada por comas
NODO/gestion	Lista de nodos gestionados, separada por comas (cuarentena + descarga = gestión)

[| Volver al índice]

3.5.8 recordNodo

Se considera como proceso con función de agente de grabación para un nodo. Solo debe existir uno por maquina o por nodo (configurado como grabador) en el portal de administración de VIVAit.

Para su funcionamiento utiliza un disco RAM por que su tiempo de acceso mejora drásticamente, debido a que la memoria RAM es varios órdenes de magnitud más rápida que las unidades de disco reales, haciendo que la velocidad de procesamiento de las grabaciones sea mucho mas rápida.

Este disco RAM normalmente ocupa la mitad de la memoria RAM de una maquina pero no es obligatorio pues dependerá de la memoria que disponible en cada maquina, y además, se configura con un tamaño no superior a 2GB de memoria RAM. Hay que tener especial cuidado en que no se llene en espacio ni tampoco los i-nodos. Se puede monitorizar a través de la aplicación zabbix.

El recordNodo se encarga de recoger todas las grabaciones de segmentos que tienen de estado proceso(2), es decir, aquellos segmentos de llamadas que han sido grabadas pero no están siendo procesadas, moviéndolas del disco RAM a su carpeta correspondiente.

La forma de obtener la carpeta correspondiente es obteniendo el dato del campo D_HORA_INICIO en la tabla DAT_LLAMADAS para cada segmento,tras un tratamiento del campo creara la subruta correspondientes: /año/mes/dia/hora/min. Entonces, la ruta correcta seria /var/lib/recordNodo/grabaciones/año/mes/dia/hora/min, donde año, mes, dia , hora y min son los valores numéricos obtenidos del campo D_HORA_INICIO.

A efectos de diagnósticos, desde un SSH se ejecuta el comando nc ip_maquina 1113 en la maquina donde creamos que debe estar ejecutando el proceso recordNodo:

root@smadavgw5:~#nc localhost 1113
recordNodo SIS ver='04.00.00' inic='20160326 105137' alarmas=2 ultAlar='20160326 105542'
recordNodo MYSQL cnx=1
recordNodo REC grabNum=0 grabErr=0

La explicación de los campos se muestra en la tabla siguiente:

Parámetro	Descripción
SIS/ver	Versión del proceso
SIS/inic	Fecha de de arranque del proceso
SIS/amarmas	Alarmas desde arranque
SIS/ultAlar	Fecha de última alarma
MYSQL/cnx	Conectado (1) a MySQL
REC/llamNum	Llamadas procesadas
REC/llamErr	Llamadas con error
REC/segmNum	Segmentos procesados
REC/segmErr	Segmentos con error

3.5.9 Vivait-CTI

Permite la comunicación entre la aplicación VIVAit Desk de agente y el asterisk, sincronizando; convierte el protocolo “asterisk manager” a CSTA (VIVAit Desk “habla” CSTA).

Es un proceso importante para que el uso de VIVAit Desk, y que los agentes puedan realizar su operativa normal con la entrada y salida de llamadas… si bien el cursado telefónico de llamadas es factible, no disponer de las facilidades de VIVAit Desk y formularios hace el sistema difícilmente manejable

A efectos de diagnósticos, desde un SSH se ejecuta el comando “nc ip_maquina 1111”

root@vivait-acd:~# nc localhost 1111
vivait-cti sis ver='V01.5' inic='20140414 104312' alarmas=13 ultAlar='20140415 173152'
vivait-cti gmp msj=1018/1024 buf=1023/1024 tarea=97/102
vivait-cti tmp uptime=694748 (8d 0h 59m 8s)
vivait-cti cti numConx=(0/511) numPend=(0/127) numMakeCallPend=0 numCall=(0/2047)
numChan=(0/4095) numAuxStr=(0/511) numMoniColas=(0/511) numMoniDevice=0
numMoniCall=0 numMoniCallAuto=0 numMoniCallByDevice=0 numMoni=(0/511)
auditCallErr=0 auditAuxStrErr=0 auditMsjReqErr=0 araChanID=0 araUniqueID=0 araMoni=0
vivait-cti ami esta=conx resp=652(0) evs=1397(0) descar=556(0) err=16 errConx=16
numAct(0/0/127) auditErrAct=0

Donde cada parámetro monitorizado indica:

ver	Versión del proceso
sis/inic	Fecha de de arranque del proceso
Sis/alarmas	Alarmas desde arranque
Sis/ultAlar	Fecha de última alarma
Gmp/msj
Gmp/buf
Gmp/tarea
Tmp/uptime
Cti/numConx	Número de conexiones actuales / Número de conexiones máximo
Cti/numPend
Cti/numMakeCallPend	Llamadas pendientes de realizar
Cti/numcall
Cti/numChan
Cti/numAuxStr
Cti/numMoniColas	Número de colas monitorizadas
Cti/numMoniDevice
Cti/numMoniCall
Cti/numMoniCallAuto
Cti/numMoniCallByDevice
Cti/numMoni
Cti/auditCallErr
Cti/auditAuxStrErr
Cti/ auditMsjReqErr
Cti/ araChanID
Cti/ araUniqueID
Cti/ araMoni
Ami/esta	Estado de conexión contra manarger de asterisk
Ami/resp
Ami/evs	Número de eventos (último minuto)
Ami/descar
Ami/err	Errores
Ami/errConx	Errores de conexión
Ami/numAct
Ami/auditErrAct

[| Volver al índice]

3.6 Requerimientos de conectividad

Lado A	Lado B	Puertos	Sentido	Observ.
Terminal telefónico	Servidor	TCP 5060	A -> B	Señalización SIP
Terminal telefónico	Servidor	UDP 5060	A -> B	Señalización SIP
Terminal telefónico	Servidor	10000 a 20000	A -> B B -> A	RTP
Terminal telefónico	Servidor TFTP	UDP 69	A -> B B -> A	Para actualización de terminales por TFTP
Terminal telefónico	Servidor NTP	UDP 123	A -> B
VIVAit Desk	Servidor	TCP 4500	A -> B	Comunicación CTI
VIVAit Desk	Servidor	TCP 3306	A -> B	Acceso a Mysql Base de datos
VIVAit Desk	Servidor Syslog	UDP 514	A -> B	Para envio de logs de agente
VIVAit Supervisor	Servidor	TCP 3306	A -> B	Acceso a Mysql Base de datos
VIVAit Tracker	Servidor	TCP 3306	A -> B	Acceso a Mysql Base de datos
VIVAit Tracker	Servidor	TCP 8180	A -> B
Actualizador	Servidor	TCP 80	A -> B	Necesario para actualizaciones de versiones de aplicaciones de agente y supervisores
Portal de administración	Servidor	TCP 8180	A -> B	Acceso al portal de administración VIVAit Suite
VIVAit Tracker Web	Servidor	TCP 8180	A -> B
Monitor	Servidor	TCP 8180	A -> B	Wallboard
Monitorización	Servidor	TCP 80	A -> B	Acceso a portal monitorización (Zabbix)

[| Volver al índice]

3.7 Gateways

El concepto de gateway como tal no existe en la plataforma VIVAit; existen nodos de ACD y nodos de corporativa.

A efectos de operación un nodo de corporativa es el que en cualquier caso asumirá las funcionalidades de gateway, y recibirá las conexiones (analógicas, digitales o IP) a sistemas externos o a la RTC

El concepto gateway queda pues suscrito a entornos meramente comerciales

Incluimos no obstante en este apartado los diagnósticos y operaciones básicos de conexiones a sistemas externos o RTC

3.8 Servidor de grabación

3.8.1 Almacenamiento en la nube

Almacenamiento en la nube. Existe la posibilidad de que tras un determinado periodo de tiempo las grabaciones sean movidas a un almacenamiento externo. De esta operativa se encarga el proceso /usr/local/sbin/mueveGrabaciones.pl que recibe como parámetro la ruta al archivo de configuración. Dicho archivo tiene los siguientes elementos:

• $db: Nombre de la base de datos.
• $dbHost: servidor de MySQL
• $dbPort: Puerto del MySQL.
• $dbUsuario: Usuario de conexión a MySQL.
• $dbClave: Clave del usuario anterior.
• $dirBase: Directorio donde residen las grabaciones
• $diasCaducidad: Dias de antigüedad para mover las grabaciones
• $sftpHost: Servidor SFTP de destino
• $sftpPort: Puerto SFTP.
• $sftpUsuario: Usuario SFTP.
• $sftpClave: Clave del usuario SFTP.
• $simula: Si este campo vale 1, las grabaciones se copian, pero no se borran del directorio original, ni se actualiza su ubicación en la base de datos.

La grabación indica donde se encuentra mediante el campo E_UBICACION_GRABACION, que puede tener los siguientes valores:

• Sin definir (0)
• En línea (10): Las grabaciones se encuentran en el servidor de grabaciones.
• Fuera de línea (20): las grabaciones se encuentran en una ubicación externa.

[| Volver al índice]

3.9 Reporting

La aplicación de reporting en general no tiene procesos habituales de operación y mantenimiento. Los informes son obtenidos desde la interfaz gráfica o mediante un procedimiento de scripting, descritos en “Formato de fichero de intercambio para VIVAit Reporting”.

3.9.1 Formato de fichero de intercambio para VIVAit Reporting

Nombre	Descripción	Ejemplo
Selección de registros
SQL_selec	Expresión SQL que se añadirá al where a la SQL principal.	C_ORIGEN like '6%' and C_COD_CLIENTE= '023'
SQL_select_leido	Filtro de selección legible	Skill igual a 60310
SQL_orden	Lista de campos por los que se ordenará, después de los que estén ya definidos en la plantilla.	C_ORIGEN, C_COD_CLIENTE
Salida
FIC_extension	Extensión de fichero de salida: PDF, XLSX, CSV	PDF
FIC_tipo_entrega	'P': Pantalla, 'D': Directorio, 'C': Correo	D
FIC_destino	Si 'C', dirección de correo, si 'D', ruta del directorio	D:\informes\
Plantilla
INF_modelo	Ruta del fichero de plantilla	C:\Modelos\llamadas.rep
INF_descripción	Descripción del informe	Informe detallado de llamadas
Base de datos
BD_ip	IP o nombre de máquina
BD_puerto	Puerto de MySQL
BD_base_datos	Nombre de base de datos
BD_usuario	Usuario de base de datos
BD_clave	Clave de acceso cifrada
Parámetros
PAR_desde_vis	Fecha inicial de selección en formato legible (o '-' si no hay)	01/01/2016
PAR_hasta_vis	Fecha final de selección en formato legible (o '-' si no hay)	31/01/2016
PAR_01	Parámetro opcional
..	..
PAR_20	Parámetro opcional

El fichero tendrá un nombre único para permitir la generación simultánea de informes. El fichero es borrado por la aplicación de forma automática. Se pasa a la aplicación de generación de informes como parámetro. Por ejemplo:

“C:\Archivos de Programa\MDtel\Nimitz\LanzaInformes\LanzaInformes.exe”
“C:\Archivos de Programa\MDtel\Nimitz\LanzaInformes\NIM00001.tmp”

Ejemplo de fichero:

SQL_selec=(DAT_ACUMULADOS_COLAS.ID_COLA in (11)) SQL_select_leido=Skill igual a 60310 SQL_orden= FIC_extension=pdf FIC_tipo_entrega=P FIC_destino=C:\ INF_modelo=skill_setsi.rep INF_descripcion=Skill. SETSI BD_ip=172.25.1.2 BD_puerto=3306 BD_base_datos=nimitz BD_usuario=nimitz BD_clave=UIk5jNY9PVX5ogg= PAR_desde_vis=- PAR_hasta_vis=- PAR_01=

[| Volver al índice]

4 Otros Diagnósticos y operaciones básicas

4.1 Arranque y apagado de la plataforma

En general el arranque y apagado de cada nodo de una plataforma VIVAit es el estándar de un procedimiento ordenado de apagado en una máquina linux: "Shutdown -h now" o comando de apagado inmediato o programado equivalente

El orden de arranque de la plataforma deberá ser:

1. En primer lugar arrancar el nodo con la base de datos de tiempo real
2. Una vez finalizado el arranque del punto 1, arrancar el nodo con la base de datos de réplica
3. Una vez finalizado el arranque del punto 2, arrancar el resto de nodos en cualquier orden

Al respecto del orden de apagado de nodos, es el siguiente:

1. En primer lugar se apagarán, en cualquier orden, los nodos que NO CONTENGAN bases de datos de tiempo real ni bases de datos de réplica
2. Una vez apagados totalmente todos los nodos del punto 1, apagaremos el nodo (o nodos) con bases de datos de réplica
3. Una vez apagados totalmente todos los nodos del punto 2, se apagará el nodo con la base de datos de tiempo real

[| Volver al índice]

4.2 Grabación

4.2.1 Comprobación de que el servidor de grabación esta activo

Si al ejecutar el comando nc ip_maquina 1114, si no se recibe ninguna respuesta, significa el servidor de grabación no estaría activo. También usando el comando ps aux | grep recordCentral , donde si no escribe ningun resultado implica que tampoco esta activo.

4.2.2 Comprobación de que los nodos están conectados al servidor de grabación

Debemos fijarnos en la linea de respuesta del comando nc ip_maquina 1114, que seria:

root@smadavacdrecord1:~# nc localhost 1114 recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423 160112' recordCentral MYSQL cnx=1 recordCentral NAS llamadas=1 segmentos=1 recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305 recordCentral NODO fase=0 cuarentena= descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10'

Sabiendo que el parámetro "fase=0" es el numero que identifica el recordCentral, los demás parámetros nos indicaran los nodos disponibles , que funcionan o no en el servidor. Entonces "gestión=4,6,7,8,9,10" indica el id de los nodos que maneja el proceso.

4.2.3 Comprobación de que un nodo tiene activo el agente de grabación

Si al ejecutar el comando nc ip_maquina 1113, no se recibe ninguna respuesta, significa que el nodo no tiene activo el agente de grabación. También usando el comando ps aux | grep recordNodo, donde si no escribe ningun resultado implica que tampoco esta activo.

4.2.4 Comprobación de que un nodo está subiendo archivos de grabación al servidor

Debemos fijarnos en la linea de respuesta del comando nc ip_maquina 1114, que seria:

root@smadavacdrecord1:~# nc localhost 1114 recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423 160112' recordCentral MYSQL cnx=1 recordCentral NAS llamadas=1 segmentos=1 recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305 recordCentral NODO fase=0 cuarentena= descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10'

Fijándonos en "descarga=8,6,4,7,10,9" nos confirma que todos los nodos que maneja el proceso funcionan perfectamente y el servidor puede manejar las grabaciones.

4.2.5 Comprobación de grabaciones que se hayan quedado enganchadas en un nodo

Podemos fijarnos en los dos comandos, para nc ip_maquina 1114:

root@smadavacdrecord1:~# nc localhost 1114 recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423 160112' recordCentral MYSQL cnx=1 recordCentral NAS llamadas=1 segmentos=1 recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305 recordCentral NODO fase=0 cuarentena= descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10'

Fijándonos en el campo "cuarentena=" indica que ninguno de los nodos tiene problemas.

4.2.6 Comprobación del estado de ocupación del almacenamiento temporal de grabaciones en un nodo.

Desde un SSH ejecuta el comando df - h en la maquina donde creamos que debe estar ejecutando el proceso recordNod:

Filesystem	Size	Used	Avail	Use%	Mounted on
udev	486M	4,0K	486M	1,00%	/dev
tmpfs	100M	416K	99M	1,00%	/run
/dev/vda1	236M	68M	156M	31,00%	/boot
tmpfs	100M	48K	100M	1,00%	/var/spool/asterisk/monitor

Nos fijaríamos en la línea marcada en negrita, el campo "Use%" indicara el porcentaje de almacenamiento temporal de grabaciones en un nodo.

[| Volver al índice]

4.3 Calendarios

El servidor de calendarios reside en "/var/www/dav/html/cal.php"

Para comprobar si el servidor interno de calendarios está operativo nos conectaremos al enlace

http://IP_SERV_CALENDAR/dav/html/cal.php

Si el sistema nos pide usuario y clave querrá decir que el servidor de calendarios está operativo en esa maquina

Para comprobar que funciona en la consola de asterisk usaremos los comandos

calendar show calendars
calendar show calendar [nombreCalendario]

Nota: Debido bugs detectados, el proceso requerirá:
      - La realización de una sincronización manual de la sección "mdcal" desde el portal de administración
      - Añadir la línea #include "/etc/asterisk/mdcal.conf" en el fichero calendars.conf y hacer "reload" de asterisk

[| Volver al índice]

4.4 Syslog de agentes

Syslog es un estándar para el envío de mensajes de registro en una red informática IP. Por Syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro. Se lanza automáticamente al arrancar un sistema Unix, y es el encargado de guardar informes sobre el funcionamiento de la máquina (eventos, seguridad del sistema, etc) pero puede contener también cualquier información como mensajes de las diferentes partes del sistema (núcleo, programas...) y los envía y/o almacena en diferentes localizaciones transmitiéndose mediante un puerto UDP. Esto permite concentrar los registros de múltiples máquinas en un único punto simplificando la labor de gestión al administrador siendo habitual que múltiples dispositivos lo soporten.

El formato del mensaje se compone de tres campos :

• La cabecera contiene la prioridad, fecha y hora del mensaje, máquina, proceso (nombre e identificador) que lo ha generado y la versión del protocolo utilizado.
• Una serie de pares clave-valor con metadatos.
• El texto del mensaje.

Si es necesario podemos activar el registro de todos los eventos telefónicos que realiza un agente ACD llamado Syslog de agentes. Su activación se realiza mediante el portal de administración VIVAit configurando unos parámetros para un usuario llamado Rastreo BBDD" y Rastreo Syslog. Para más información[| ver sección Portal de administración - General - Usuarios - Pestaña ACD ].

Elemento	Procedimiento
Operacion
Ubicación del proceso	Script arranque: /etc/init/ rsyslog.conf Configuración : /etc/rsyslog.d/30-vivait- desk.conf
Arranque	service rsyslog start
Parada	service rsyslog stop
Reinicio	service rsyslog reload
Diagnostico
Registro de logs	/var/log/MDtel/vivait-desk.log Fichero del día actual. se guardan los 30 anteriores comprimidos en tar.g

[| Volver al índice]

5 Funcionalidades específicas

5.1 Mecanismo de prioridad adaptativa

El mecanismo de prioridad adaptativa permite en una plataforma VIVAit Suite establecer prioridades en las que se tenga en cuenta el tiempo de espera de las llamadas en cola, proporcionando una alternativa al mecanismo de prioridad absoluta que existe por defecto

Se adjunta documento explicativo

Asignación de llamadas por prioridad adaptativa

[| Volver al índice]

5.2 Marcación saliente

Dentro del ACD hay un comportamiento especial que es la marcación saliente. Esta puede ser de tres tipos:

• Vista previa: El agente demanda la siguiente llamada a realizar.
• Progresivo: Se llama al agente y se lanza la llamada al contacto.
• Predictivo: El sistema calcula cuando va a estar libre el agente y se adelanta lanzando varias llamadas (configurables por parámetros). La llamada que es contestada primero, se pasa a una cola (el resto se cuelgan) a la espera que el agente se quede libre.

5.2.1 Esquema de funcionamiento

Los contactos se agrupan en listas para su facilidad de asignación a campañas, aunque finalmente lo que se asigna a una campaña es un contacto.

Las campañas tienen estrategias. Las estrategias definen como se ha de llamar (del primero al último, sólo los pares, etc.). Tienen una serie de parámetros que dependiendo de la estrategia pueden tener distinta utilidad. Desde el punto de vista de la base de datos, las estrategias se definirían en la tabla ACD_CLASES_ESTRATEGIAS y se les da valor en la tabla ACD_ESTRATEGIAS_MARCADOR. Una vez establecida la campaña y asignados sus contactos y dependiendo del modo de marcación (que se define en las colas) el proceso motorSal crea los intentos de marcación (siempre y cuando no estén en las listas Robinson), que serán leídos por el proceso myAcdSuperv que los convierte en llamadas para el Asterisk.

5.2.2 Flujo de estados

El flujo de estados es el reflejado en la figura siguiente

Los diferentes estados de un contacto son:

Estado	ID_Estado	Descripción
Planificable	0	El contacto está preparado para que lo gestione motorSal y según la estrategia definida se establece el campo ACD_CONTACTOS_CAMPANNAS.D_HORA_PROXIMA
Planificado	10	Cuando ha llegado el tiempo marcado en HORA PROXIMA, motorSal ejecuta la 2ª fase de la estrategia, generando el intento de marcación.
Intento	20	El control pasa a myAcdSuperv, que a su vez genera la llamada en Asterisk. Cuando termina, se pasa a Planificable o Finalizado.
Finalizado	100	Las gestiones con este contacto han terminado.
Abortado	110
Obsoleto	200	Se ha agotado el tiempo para contactar sin agotar todos los intentos. No se le vuelve a llamar nunca.

5.2.3 Carga de contactos

Instrucciones para carga automatizada de contactos

Ejemplo de fichero de carga de contactos

[| Volver al índice]

5.3 Movilidad

La movilidad es una función integral de las comunicaciones en la empresa. Cualquier empleado (usuario) es móvil en cierto grado, sea dentro o fuera de la organización.La solución óptima debe proporcionar continuidad de servicios y acceso a nuestros servicios, sin importar donde se esté.

5.3.1 Ofrecer movilidad a un usuario

Para permitir la movilidad a un usuario, puede ser en el momento de crear o editar un usuario en el apartado Administración de usuario en General del portal de administración VIVAit. Asignándole un numero login (numero personal corporativo para el usuario) y una clave login ( se debe asignar una clave por defecto, pero puede cambiarla en el [|portal de usuario]). Para más información[| ver sección Portal de administración - General - Usuarios - administración de usuarios - Pestaña Centralita].

Además, de crear un permiso de la aplicación Centralita a cualquier nivel, desde el apartado Permisos de usuarios en General del portal de administración VIVAit.Para más información[| ver sección Portal de administración - General - Usuarios - Permisos a usuarios]

Finalmente, y por razones de seguridad todo terminal tiene asociado una extensión y deberá permitir la movilidad de usuarios. La extensión se configura cambiando a SI el campo Hay Movilidad desde el apartado Extensiones de Dispositivos en VIVAit Call del portal de administración VIVAit. Para más información [| ver sección Portal de administración - VIVAit Call - Dispositivos - Extensiones]

[| Volver al índice]

5.4 Grabación

La grabación en VIVAit Call está diseñada para ser lo mas flexible posible.

5.4.1 Configuración

Si deseamos grabar, debemos activar que alguno de los dispositivos/elementos que intervienen en la llamada se grabe.

Estos dispositivos/elementos son:

• Nodo.
• Usuario con Centralita.
• Agente.
• Grupo ACD corporativo y de Contact Center.
• Enlace exterior.
• Extensión.
• Facilidades.
• Grupo: grupo de salto o grupo de operadoras.
• Sala de conferencia.
• VDN corporativo y de Contact Center.
• Pre-rutas.

Por otro lado necesitaremos que la llamada pase por un nodo que sea grabador, es decir, que si la llamada esta configurada para que se grabe pero no pasa por ningún nodo grabador, la llamada no se grabará.

Al configurar un nodo existen 4 campos que intervienen en la grabación.

'Grabador'

Se configura en el portal en la sección general/nodos.

Este campo corresponde con el campo B_ES_GRABADOR de la tabla COM_NODOS , este campo define si el nodo va a grabar las llamas que pasen por el que necesiten ser grabadas y no se estén grabando ya.

Es un campo booleano los posibles valores en el portal son si/no y en la base de datos 1/0.

'Modo grabación infraestructura'

Se configura en el portal en la sección general/nodos.

Este campo define como está la infraestructura configurada, este campo existe por compatibilidad con VIVAit uite y para poder configurar la grabación bajo demanda.

Este campo corresponde con el campo E_MODO_GRABACION_INFRAESTRUCTURA de la tabla COM_NODOS, Este campo usa los valores del enumerado BD.ENUM.TModoGrabacionInfraestructura|TModoGrabacionInfraestructura]].

La formula que se seguiría para ver si una llamada se graba en ese nodo es:

(NODO.E_MODO_GRABACION_INFRAESTRUCTURA) AND (NODO.B_ENRU_GRABAR OR CEN_PRE_RUTA.B_ENRU_GRABAR OR "OBJETO".B_ENRU_GRABAR)

Que sería que si la infraestructura esta en NoGraba no se graba nada de lo que se rute en ese nodo y en cualquiera de los 2 otros caso (GrabaTodo o GrabaPorPeticion) se grabaría dependiendo de la configuración del Nodo, la ruta o el objeto en cuestión (preruta, grupo ACD, extension,...).

'Grabar enrutamiento'

Se configura en el portal en la sección general/nodos.

Este campo define si van a grabar las llamadas que se enruten en este nodo.

Campo E_ENRU_GRABAR de la tabla COM_NODOS que usa los valores del enumerado TTipoEnruGrabar.

'RecordCentral'

Se configura en el portal en la sección general/nodos.

Define que instancia del recordCentral es la encargada de tratar las grabaciones de este nodo.

Para aumentar el rendimiento a la hora de traerse las grabaciones, se pueden definir varias instancias de proceso recordCentral, este campo define cual de estas instancias se encargara de este nodo.

5.4.2 Vivait Tracker

Desde VIVAit Supervisor que es la aplicación dirigida a Supervisores, que ofrece la posibilidad de supervisar y gestionar grupos ACD, agentes, asignaciones, prioridades,etc. Se puede obtener acceso directo a las aplicaciones de grabación (VIVAit tracker)

Esquematico actual del proyecto tracker

1º El tracker web llama al web service Remote login para iniciar sesión y determinar si tiene permisos para la escucha y descarga de grabaciones.

2º Si la ubicación de la grabación es local, mira la ruta de esta y se procede a la escucha o descarga de esta.

3º Si la ubicación de la grabación es remota, entra en escena el proxy. Es el que realiza la petición.

4º Si utilizamos el tracker windows, este, como el tracker web, llama primero al web service remote login para la autenticación y tema de Permisos.

5º Para descargar o escuchar una grabación desde el tracker windows, se llama al web service servidor de grabaciones pasándole simplemente el ID de segmento.mp3. Este web service, con el ID de segmento, se encarga de determinar la ubicación de la grabación. Esquematico actual del proyecto tracker

1º El tracker web llama al web service Remote login para iniciar sesió (comunicación https) y determinar si tiene permisos para la escucha y descarga de grabaciones. Se elimina el proxy

2º Si la ubicación de la grabación es local, mira la ruta de esta y se procede a la escucha o descarga de esta.

3º Si la ubicación de la grabación es remota, se realiza una petición al host remoto. El tipo de petición vendrá fijada por base de datos (http, https, ftp,ftps)

4º Si utilizamos el tracker windows, este, como el tracker web, llama primero al web service remote login para la autenticación y tema de permisos (comunicación https extremo a extremo).

5º Para descargar o escuchar una grabación desde el tracker windows, se llama al web service servidor de grabaciones pasándole simplemente el ID de segmento.mp3. Este web service, con el ID de segmento, se encarga de determinar la ubicación de la grabación.

Volver arriba [Volver al indice]

5.5 Enrutamiento

5.5.1 Funcionamiento

El proceso de enrutamiento, como vemos en el esquemático, se compone de dos fases:

1. Preenrutameinto, que se encarga de tratar todas las llamadas
2. Enrutamiento externo, que tiene módulos dedicados al enrutamiento hacia:

• Enlaces externos.
• Extensiones.
• Usuarios de telefonía corporativa.
• Facilidades.
• Salas de conferencia.
• Agentes de grupos ACD.
• Grupos ACD.
• Vdn.
• Buzones para dejar mensaje.
• Buzones para su gestión.

Se asume que existen rutas directas entre todos los nodos de la red.

Se asume que están directamente enrutadas todas las direcciones IP involucradas, tanto nodos, como terminales.

Se asume que todas las facilidades están disponibles en todos los nodos, aunque es posible que la implementación sea diferente entre ellos.

Los datos de entrada básicos al proceso de enrutamiento (pdEntr) son:

• Dispositivo
• Cola
• Origen
• Nodo entrada
• UCID
• CALLER_ID_NAME
• CALLER_ID_NUM
• DNIS
• Desvío por dialplan

A partir de los datos de entrada básicos anteriores se pueden deducir los siguientes valores:

• Sede del dispositivo de entrada
• Sede del nodo de entrada
• Ancho de banda disponible en la sede del dispositivo
• Ancho de banda disponible en la sede del nodo
• Categoría entrante
• Valor del eje1 asignado a la llamadas
• CALLER_ID_NUM_EXTERNO

Los datos de salida globales del proceso de enrutamiento (pdSale) son:

• Categoría saliente
• Código de cliente (opcional)
• Tipo de destino:

• No existe
• Ruta externa
• Extensión
• Usuario de telefonía corporativa
• Facilidad
• Salas de conferencia
• Agentes de grupos ACD
• Grupos ACD
• VDN
• Buzón para dejar mensaje.
• Buzón para dejar mensaje por ocupado.
• Buzón para dejar mensaje por no contestación.
• Buzón para su gestión.

• Destinatario (cuando se trata de un usuario o de un agente)
• Valor del eje1 asignado a la llamada
• Buzón de las extensiones y usuarios que los tengan asignados
• Si el buzón está en nodo distinto al de entrada
• DESVIO_INCONDICIONAL (sólo extensiones y usuarios) (valor MENSA=desvio_mensajeria en variable)
• DESVIO_NO_CONTESTA (sólo extensiones y usuarios) (valor MENSA=desvio_mensajeria en variable)
• DESVIO_OCUPADO (sólo extensiones y usuarios) (valor MENSA=desvio_mensajeria en variable)
• DESVIO_FUERA_SERV (sólo extensiones y usuarios) (valor MENSA=desvio_mensajeria en variable)

Los datos de salida para cada una de las posibles rutas en orden son (nn va de 01 maxRutas [nn son dos dígitos decimales]):

• CONTADOR_ABDE_nn (contador para control de ancho de banda en sede de dispositivo de entrada).
• CONTADOR_ABNE_nn (contador para control de ancho de banda en sede de nodo de entrada).
• CONTADOR_ABDS_nn (contador para control de ancho de banda en sede de dispositivo de salida).
• CONTADOR_ABNS_nn (contador para control de ancho de banda en sede de nodo de salida).
• CALLER_NAME_SAL_nn , puede salir de una extensión, un usuario o de un agente.
• CALLER_NUM_SAL_nn, puede salir de una extensión, un usuario o de un agente.
• DESTINO_SAL_nn , en general, el valor C_NOMBRE o destino de salida.
• RUTA_NODO_nn , Cadena de marcación para ir la nodo que soporta DESTINO_SAL_nn, si es distinto del nodo de entrada.
• RUTA_SAL_nn

• Extensión: cadena marcación.
• Facilidad: E_CODIGO_FACILIDAD obtenido de la tabla CEN_FACILIDADES.
• Usuario: cadena marcación de la extensión asignada al usuario en movilidad o en propiedad.
• Agente: cadena marcación de la extensión a la que está conectado el agente.
• Ruta externa: contexto que gestiona la llamada saliente.

5.5.1.1 Fase preenrutamiento

La fase de preenrutamiento (basada en la tabla CEN_PRE_RUTA) se usa en todas las llamadas entrantes, tanto internas, como externas. Permite desarrollar un “prerouting” estándar para ACD y para telefonía corporativa.

Los datos de entrada al proceso de enrutamiento son iguales a los del proceso global de enrutamiento, excepto en que este proceso no usa el nodo de entrada ya que es independiente de éste.

Los datos de salida de la fase de preenrutamiento:

• D_CATEGORIA_SAL
• COD_CLIENTE (opcional)
• TIPO_DESTINO_SAL

• No existe.
• Volver a preenrutar.
• Ruta externa.
• Extensión.
• Usuario de telefonía corporativa.
• Facilidad.
• Sala de conferencia.
• Agente de grupos ACD.
• Grupos ACD.
• VDN.
• Buzón para dejar mensaje.
• Buzón para dejar mensaje por ocupado.
• Buzón para dejar mensaje por no contestación.
• Buzón para su gestión.

• COD_CLIENTE
• Valor del eje1 asignado a la llamada
• CALLER_NAME
• CALLER_NUM
• DESTINO

El proceso de preenrutamiento consiste en seleccionar un único registro de la tabla CEN_PRE_RUTA y, con sus valores y con los valores de entrada al proceso, generar los datos de salida.

Un posible tipo de salida es "Volver a preenrutar". Esto permite realimentar el proceso un máximo de "max_pre_ruta_regs" veces (en archivo .conf) para simplificar configuración. Sólo tiene sentido realimentar si se ha hecho alguna modificación en los datos de selección de registro, ya que en caso contrario se produciría un bucle que el proceso de preenrutamiento es capaz de detectar y evitar.

Para elegir el registro de CEN_PRE_RUTA, se tienen en cuenta los datos de entrada de la llamada, de modo que se cumpla con todos los puntos siguientes:

• ID_CATEGORIA_ENT igual a la del dispositivo de entrada.
• CALLER_NUM de entrada

• Debe comenzar por la cadena C_ORIGEN_ENT_PREF o C_ORIGEN_ENT_PREF=NULL, con menos prioridad. Es conveniente rellenar este dato del modo más restrictivo que sea posible, independientemente de C_ORIGEN_ENT_EXPR. Ello permite disminuir el uso innecesario de recursos de evaluación de expresiones regulares.
• Debe de tener un número de dígitos igual o superior a N_ORIGEN_ENT_MIN_DIGITOS, si este valor no es NULL o cero.
• Debe de tener un número de dígitos igual o inferior a N_ORIGEN_ENT_MAX_DIGITOS, si este valor no es NULL o cero.
• Debe cumplir la expresión regular C_ORIGEN_ENT_EXPR, si ésta no es NULL.

• DNIS empiece con C_DESTINO_ENT_PREF o C_DESTINO_ENT_PREF=NULL. Es conveniente rellenar este dato del modo más restrictivo que sea posible, independientemente de C_DESTINO_ENT_EXPR. Ello permite disminuir el uso innecesario de recursos de evaluación de expresiones regulares.
• Si varias entradas cumplen la condición anterior, se prueba primero la que el campo C_DESTINO_ENT_PREF tenga una longitud mayor y, de entre éstas, la que C_ORIGEN_ENT_PREF tenga una longitud mayor.
• DNIS tenga un número de dígitos igual o superior a N_DESTINO_ENT_MIN_DIGITOS, si este valor no es NULL o cero.
• DNIS tenga un número de dígitos igual o inferior a N_ORIGEN_ENT_MIN_DIGITOS, si este valor no es NULL o cero.
• DNIS cumpla la expresión regular C_DESTINO_ENT_EXPR, si ésta no es NULL.

Si no se encuentra ninguna entrada adecuada, quiere decir que es una llamada prohibida y se devuelve el tipo de destino "No existe".

Puede conseguirse un destino "por defecto" diferente, creando una entrada que encaje siempre para cada categoría: C_ORIGEN_ENT, C_ORIGEN_ENT_MIN_DIGITOS, C_ORIGEN_ENT_MAX_DIGITOS, C_ORIGEN_ENT_EXPR, C_DESTINO_ENT_PREF, N_DESTINO_ENT_MIN_DIGITOS, N_DESTINO_ENT_MAX_DIGITOS y C_DESTINO_ENT_EXPR a valor NULL.

Una vez elegida una entrada, ésta puede transformar o sustituir el valor de ID_CATEGORIA, CALLER_NAME, CALLER_NUM, DESTINO, COD_CLIENTE y/o EJE1_MSK a la salida del proceso.

Si ID_CATEGORIA_SAL es cero, se propaga a la salida el valor de la entrada. En caso contrario, se sustituye.

Si C_CALLER_NAME está vacío, se mantiene el valor hubiese a la entrada. En caso contrario, se sustituye.

C_CALLER_NUM puede contener una cadena que identifica el nuevo CALLER_NUM. Además, si la cadena comienza por los caracteres que se indican, el significado es especial:

• "=" o cadena vacía, el nuevo CALLER_NUM es igual al de entrada al proceso.
• "+" el nuevo CALLER_NUM es igual al de entrada al proceso, con los caracteres a continuación de "+" como prefijo.
• "-" se quita el número de caracteres que se indica a continuación de "-".
• "_" lo que sigue al carácter es una expresión regular que se aplica al CALLER_NUM de entrada. Dicha expresión regular tiene obligatoriamente que contener una subcadena (definida entre paréntesis, según el estándar de expresiones regulares) que nos da el nuevo CALLER_NUM de salida. Si la expresión regular no se cumpliese, se propagará el valor de entrada al proceso.
• cualquier otro valor del primer carácter determina que es una constante que sustituye el valor a la entrada.

Cada vez que se utilice una preruta, se incrementará el valor de N_CONTA si el valor de N_UMBRAL es mayor que cero.

Un valor N_UMBRAL mayor que cero permite modificar el destino de salida cuando el valor de actual de N_CONTA (antes de incrementarse) supere o sea igual el valor de N_UMBRAL. Si se cumple la condición indicada, se usa como destino tras el preenrutamiento, los valores de los campos E_TIPO_DESTINO_SAL_2 y C_DESTINO_SAL_2.

Si el valor de N_UMBRAL es menor o igual a cero o si N_CONTA es inferior a N_UMBRAL, se usa como destino tras el preenrutamiento, los valores de los campos E_TIPO_DESTINO_SAL_1 y C_DESTINO_SAL_1. Con este mecanismo de N_CONTA y N_UMBRAL, se pretende facilitar el discriminar a los llamantes reincidentes, cuando sea necesario.

Un proceso periódico externo debe encargarse de poner a cero o decrementar el valor de N_CONTA. Como resultado de los procesos de filtrado y de verificación anteriores, se habrá obtenido un TIPO_DESTINO_SAL y un C_DESTINO_SAL a partir de los campos con sufijo "_1" o "_2", con una metodología similar al caso C_CALLER_NUM.

C_DESTINO_SAL_x puede contener cadena que permite obtener el nuevo destino. Además, si la cadena comienza por los caracteres que se indican, el significado es especial:

• "=" o cadena vacía, el nuevo destino es igual al de entrada al proceso.
• "+" el nuevo destino es igual al de entrada al proceso, con los caracteres a continuación de "+" como prefijo.
• "-" se quita el número de caracteres que se indica a continuación de "-".
• "_" lo que sigue al carácter es una expresión regular que se aplica al destino de entrada. Dicha expresión regular tiene obligatoriamente que contener una subcadena (definida entre paréntesis, según el estándar de expresiones regulares) que nos da el nuevo destino de salida. Si la expresión regular no se cumpliese, quiere decir que es una llamada prohibida y se encaminará hacia una facilidad por defecto.
• cualquier otro valor del primer carácter determina que es una constante que sustituye el valor a la entrada.

Información de salida del proceso de preenrutamiento: Cuando TIPO_DESTINO_SAL_x toma los valores que se indican, el proceso global de enrutamiento sólo requiere de preenrutamiento y la información a devolver se obtiene dependiendo de TIPO_DESTINO_SAL_x:

• No existe: Se asume que no se conoce un destino para los datos de entrada, por lo que la llamada se encamina hacia una facilidad por defecto que gestiona su tratamiento.
• Extensión: A partir de las tablas CEN_DISPOSITIVOS, CEN_EXTENSIONES y CEN_NODOS, se devolverán los valores que permiten alcanzar la extensión en el nodo principal y en el secundario.
• Facilidad: A partir de las tablas CEN_DISPOSITIVOS, CEN_FACILIDADES y CEN_NODOS.
• Usuario de telefonía corporativa: A partir de las tablas CEN_USUARIOS, CEN_DISPOSITIVOS, CEN_EXTENSIONES y CEN_NODOS, se devolverán los valores que permiten alcanzar al usuario en el nodo principal y en el secundario de la extensión que corresponde en base a movilidad, con prioridad, o en base a propiedad. El caso de movilidad no se tiene en cuenta si el proceso de enrutamiento se realiza en "modo supervivencia".
• Sala conferencia: A partir de las tablas CEN_SALAS_CONFERENCIAS y CEN_NODOS.
• Agente de ACD: A partir de las tablas ACD_USUARIOS, DAT_TR_ACD_EXTENSIONES, CEN_DISPOSITIVOS, CEN_EXTENSIONES y CEN_NODOS, se devolverán los valores que permiten alcanzar al agente en el nodo principal y en el secundario.
• VDN: A partir de las tablas ACD_VDN y CEN_NODOS, se devolverán los valores que permiten alcanzar al VDN en su nodo.
• Grupo ACD: A partir de las tablas ACD_COLAS y CEN_NODOS, se devolverán los valores que permiten alcanzar al grupo ACD en su nodo.

El campo B_GENERAR_SEGMENTO de la tabla CEN_PRE_RUTA indica al proceso de preenrutamiento que es preciso generar un segmento de tipo "preenrutamiento". En el segmento generado, se rellena el campo C_ETIQUETA1 del nuevo segmento con el valor que contiene el campo homónimo del registro asociado en la tabla CEN_LISTA_PRE_RUTAS.

5.5.1.2 Fase de enrutamiento en casos en que el destino no es externo

Datos de entrada al proceso de enrutamiento externo: iguales a los de salida del proceso de preenrutamiento (pdPreSale), uniéndose a éstos los datos globales de entrada al proceso (pdEntr).

Datos de salida de la fase de enrutamiento: iguales que los del proceso global de enrutamiento (pdSale).

Específicamente y sólo para los casos en que el destino es una extensión (tipo de destino extensión, usuario de telefonía corporativa o agente) es cuando son válidos los datos correspondientes al buzón asociado y los datos de los posibles desvíos previstos.

También en este caso, se prevén dos posibles rutas, una se corresponde con el acceso a la extensión en el nodo principal de ésta y la otra en el nodo secundario.

En el resto de tipos de destino, sólo se prevé una ruta que puede incluir o no un enlace internodal.

5.5.1.3 Fase de enrutamiento en el caso de destino externo

Datos de entrada al proceso de enrutamiento externo: iguales a los de salida del proceso de preenrutamiento (pdPreSale), uniéndose a éstos los datos globales de entrada al proceso (pdEntr). Datos de salida de la fase de enrutamiento: iguales que los del proceso global de enrutamiento (pdSale).

Se elige los primeros "max_ruta" registros (configurado en archivo .conf) en CEN_DESTINOS_EXTERNOS unido con CEN_RELACION_DESTINOS_ENLACES_EXTERNOS que, teniendo en cuenta los datos de entrada al proceso de enrutamiento, cumpla con todos los puntos siguientes:

• ID_CATEGORIA_ENT igual a la de salida del proceso de preenrutamiento.
• C_DESTINO_SAL de proceso de preenrutamiento empiece con C_DESTINO_ENT_PREF.
• Si varias entradas cumplen la condicion anterior, se prueba primero la que el campo C_DESTINO_ENT_PREF tenga una longitud mayor.
• C_DESTINO_SAL tenga un número de dígitos igual o superior a N_DESTINO_ENT_MIN_DIGITOS, si este valor no es NULL o cero.
• C_DESTINO_SAL tenga un número de dígitos igual o inferior a N_DESTINO_ENT_MAX_DIGITOS, si este valor no es NULL o cero.
• C_DESTINO_SAL cumpla la expresión regular C_DESTINO_ENT_EXPR, si ésta no es NULL.

Aparte de la longitud del campo C_DESTINO_ENT_PREF, se usa N_PRIORIDAD como campo para ordenar los registros y seleccionar lo "max_ruta" primeros.

Una vez que un registro es válido, se descartan todos los registros cuyo C_DESTINO_ENT_PREF es diferente del primero seleccionado.

Como resultado de los procesos de filtrado y de verificación anteriores, se habrá obtenido hasta un máximo de "max_rutas" valores para posibles rutas. Las posibles propagaciones y transformaciones en los datos de cada ruta son función de los datos de cada registro seleccionado:

CALLER_NAME_nn: Si C_CALLER_NAME está vacío, se propaga el valor de entrada. En caso contrario, se sustituye.

CALLER_NUM_nn: Sale de C_CALLER_NUM que puede contener una cadena que identifica el nuevo CALLER_NUM_n. Además, si C_CALLER_NUM comienza por los caracteres que se indican, el significado es especial:

• "=" o cadena vacía, el nuevo CALLER_NUM_nn es igual al de entrada al proceso.
• "+" el nuevo CALLER_NUM_nn es igual al de entrada al proceso, con los caracteres a continuación de "+" como prefijo.
• "-" se quita el número de caracteres que se indica a continuación de "-".
• "_" lo que sigue al carácter es una expresión regular que se aplica al CALLER_NUM de entrada. Dicha expresión regular tiene obligatoriamente que contener una subcadena (definida entre paréntesis, según el estándar de expresiones regulares) que nos da el nuevo CALLER_NUM de salida. Si la expresión regular no se cumpliese, se propaga el valor de entrada al proceso.
• ">" Si existe valor para CALLER_NUM_EXTERNO, se propagará éste a la salida. En caso contrario y si no está vacía la cadena que queda al eliminar el prefijo ">", se susituye en la salida por el valor de la cadena sin prefijo. Si la cadena estuviese únicamente constituida por el valor ">", se propaga el valor de entrada.
• cualquier otro valor del primer carácter determina que es una constante sin ninguna modificación.

C_DESTINO_SAL_nn: Se obtiene a partir de C_DESTINO_SAL que puede contener una cadena que identifica el nuevo destino. Además, si la cadena comienza por los caracteres que se indican, el significado es especial:

• "=" o cadena vacía, el nuevo destino es igual al de entrada al proceso.
• "+" el nuevo destino es igual al de entrada al proceso, con los caracteres a continuación de "+" como prefijo.
• "-" se quita el número de caracteres que se indica a continuación de "-".
• "_" lo que sigue al carácter es una expresión regular que se aplica al destino de entrada. Dicha expresión regular tiene obligatoriamente que contener una subcadena (definida entre paréntesis, según el estándar de expresiones regulares) que nos da el nuevo destino de salida. Si la expresión regular no se cumpliese, se propaga el valor de entrada al proceso.
• cualquier otro valor del primer carácter determina que es una constante sin ninguna modificación.

RUTA_NODO_nn: Sólo se usa si el nodo de salida es diferente del nodo de entrada. Contiene la cadena de marcación para ir la nodo que soporta DESTINO_SAL_nn. Sale del campo C_FORMATO_DIAL (sustituyendo variables) correspondiente al tipo de dispositivo del enlace exterior.

RUTA_SAL_nn: Es el campo C_DATO_ASTERISK obtenido a partir del registro en la tabla CEN_ENLACE_EXTERIOR que se corresponde con ID_ENLACE_EXTERIOR de la tabla CEN_RELACION_DESTINOS_ENLACES_EXTERNOS.

[| Volver al índice]

5.6 Control de ancho de banda

Para el control de ancho de banda, primero hemos de tener en consideración que una llamada puede tener asociadas hasta cuatro sedes

• Sede del terminal origen (terminal A)
• Sede del nodo de registro del terminal origen (nodo A)
• Sede del terminal destino (terminal B)
• Sede del nodo de registro del terminal destino (nodo B)

Además hemos de tener en cuenta que el audio de la conversación podrá ir:

• De manera directa entre terminal A y terminal B
• De manera indirecta, a través de los nodos A y B

Cuando se va a cursar una llamada de terminal A a terminal B, el proceso de enrutamiento del nodo A devuelve 4 variables de canal al dialplan:

Variable	Campos
R_ABDE_xx	R = Variable de rutas --- AB = ancho de banda --- D = dispositivo --- E = Entrante --- xx = de 0 a 3
R_ABNE_xx	R = Variable de rutas --- AB = ancho de banda --- N = nodo --- E = Entrante --- xx = de 0 a 3
R_ABDS_xx	R = Variable de rutas --- AB = ancho de banda --- D = dispositivo --- S = Saliente --- xx = de 0 a 3
R_ABNS_xx	R = Variable de rutas --- AB = ancho de banda --- N = nodo --- S = Saliente --- xx = de 0 a 3

El valor de cada variable es una cadena del tipo AB.wwww.xxxx.y.z donde cada valor es:

• wwww --> id de sede
• xxxx --> ancho de banda total de la sede
• y --> número de llamadas a sumar si conversación directa
• z --> número de llamadas a sumar si conversación indirecta

Por otro lado tenemos que tener en cuenta que el dialplan tiene control de las llamadas que cada sede puede cursar

De esta forma, cuando existe una nueva llamada el dialplan aplica la fórmula, suma el resultado al número de llamadas en curso y lo compara con el máximo...si el resultado es mayor que le máximo la llamada no se cursará por congestión

Configuraremos el ancho de banda por sede en el portal de administración y el consumo que hace cada llamada en la variable AB_CONSUMO_LLAMADA del fichero ext_MDtel_particular.conf de cada nodo de conmutación; el valor por defecto es 32

[| Volver al índice]

6 Puesto de trabajo

El puesto de trabajo del agente en la plataforma VIVAit (para el producto VIVAit Suite) estará compuesto por:

• PC (típicamente windows) en el que reside la aplicación VIVAit Desk
• Terminal telefónico con extensión física asociada.

Para más información [| ver sección Portal de administración-VIVAit Suite ACD+ - Puestos].

6.1 Relación PC/teléfono en puesto de trabajo

Existirá una relación única entre nombre PC y extensión física asociada, si bien los agentes se identificarán por su login que les acompaña al puesto de trabajo en el que se loguen Existe un procedimiento documentado para la operativa de cambio de puesto de trabajo, en caso de ser necesario el cambio de PC o de teléfono de un puesto de trabajo.

6.1.1 Procedimiento para un cambio de puesto de trabajo

Se basa en una asignación de PC a teléfono relaccionando la extensión telefónica del terminal físico con el nombre del puesto de trabajo. La configuración de dicha asociación se realiza en el portal de administración de la plataforma.

Cualquier cambio que se realice en terminal telefónico o PC de agente ha de mantener la asociación en el portal a efectos de permitir el funcionamiento del sistema.

A continuación se reflejan los cambios más habituales:

Cambio	Procedimiento	Punto de acción
Cambio de ubicación de un PC	Opción 1.- Renombrar el PC para que conserve el nombre que tenía el anterior en esa ubicación	PC de agente
	Opción 2.- Rehacer la asignación extensión/puesto	Portal de administración
Instalación de PC nuevo en puesto existente	Opción 1.- Renombrar el PC para que conserve el nombre que tenía el anterior en esa ubicación	PC de agente
	Opción 2.- Rehacer la asignación extensión/puesto	Portal de administración
Cambio de nombre en un PC	Rehacer asignación extensión/puesto	Rehacer asignación extensión/puesto
Cambio de ubicación de un teléfono	Rehacer la asignación extensión/puesto	Portal de administración
Instalación de un teléfono nuevo en puesto existente	Rehacer la asignación extensión/puesto	Portal de administración
Instalación de un nuevo puesto de agente	Hacer asignación extensión/puesto	Portal de administración

6.2 Estructura de aplicaciones en puesto de trabajo

Las aplicaciones del puesto de trabajo pueden estar ubicadas en cualquier carpeta del sistema. Es importante tener en cuenta que los procesos de actualización, logs… escriben en dichas carpetas, por lo que el usuario de windows deberá tener permisos de lectura/escritura y borrado sobre dichas carpetas La instalación del puesto de trabajo es muy liviana para el sistema; las aplicaciones ocupan poco espacio y no se modifican ficheros del sistema operativo (registry o similares) Los ficheros importantes son

Fichero	Descrición
Vivait-desk.exe	Contiene la aplicación VIVAit Desk de agente
vivait_desk_dll.dll	Este fichero contiene controles sobre los formularios (controles de texto, algunas reglas de obligatoriedad…)
nimitz.ini	Configuración del puesto de agente
lanzador.exe	Aplicación de actualización de versiones
lanzador.ini	Configuración del actualizador de aplicaciones
Carpeta forms	En esta carpeta están ubicados los formularios que se abren ante llamada entrante o saliente
Carpeta imágenes	Contiene las imágenes izquierda y derecha de la barra de VIVAit Desk

6.3 Secciones de utilidad en nimitz.ini

El fichero nimitz.ini contiene la configuración del puesto de agente; sus principales parámetros son:

Fichero	Descripción
Sección [bd1]	host="ip_BBDD_tiempo_real" basedatos="nimitz" usuario="nimitz" clave="UIk5jMY9PVX6ogg=" Contiene información para la conexión a BBDD de tiempo real, en la que VIVAit Desk fundamentalmente inserta información
Sección [bd2]	host=" ip_BBDD_replica " basedatos="nimitz" usuario="nimitz" clave="UIk5jMY9PVX6ogg=" Contiene información para la conexión a BBDD de réplica, en la que VIVAit Desk solo leerá información
Sección [telefono]	pruebas=1 (Valores válidos 0 ó 1) Activación de funcionalidad "servicio técnico" en VIVAit Desk.
Sección [trazas]	nivel=3 archivo=1 sobreescribir=1 Activación de generación de ficheros de trazas "viva-desk.log" en carpeta de aplicaciones

6.4 Parámetros en invocación a VIVAit Desk

La aplicación VIVAit Desk puede ser invocada con una serie de parámetros que condicionan su funcionamiento; los parámetros son:

• Primer parámetro: Nombre del archivo .ini; usado como alternativa al fichero por defecto "nimitz.ini"
• Segundo parámetro: Nombre de puesto; usado como alternativa al nombre de puesto del ordenador
• Tercer parámetro: Nombre de login; para forzar un usuario; es de utilidad si el sistema está configurado como "confiar en sistema operativo", en cuyo caso no permite seleccionar un login de agente para acceder a la aplicación

6.5 Instalación y actualización de aplicaciones de puestos de trabajo

La instalación y actualización de las aplicaciones en el puesto de trabajo pasan por disponer de los ficheros “lanzador.exe” y “lanzador.ini” (debidamente configurado) dentro de la carpeta en la que se desee instalar. Lanzando la aplicación “lanzador.exe” se instalará o actualizará el sistema.

El fichero “lanzador.ini” tiene el siguiente aspecto:

URL="http://IP_Servidor:8180/WSActualizaXML/actualizar.xml"
BASE_URL_DESCARGAS="http://IP_servidor:8180/XMLFILES/"

6.6 Servicio técnico en VIVAit Desk

La activación de la funcionalidad de servicio técnico en VIVAit Desk nos permite realizar sincronizaciones manuales de la aplicación y activar trazas a nivel de Base de Datos o a nivel de log sobre el propio VIVAit Desk. Pulsando el botón derecho del ratón sobre la barra VIVAit Desk accederemos a las capacidades de soporte técnico [| Volver al índice]

8 Accesos Web

Aplicación	Enlace
Portal de administración VIVAit Suite	http://ip_admin:8180/Vivait-Call
VIVAit Tracker	http://ip_tracker:8180/Vivait-Tracker
Monitor Web	http://ip_monitor:8180/MonitorWeb
Monitorización Zabbix	http://ip_zabbix:80/zabbix
Base de datos tiempo real	http://ip_bbdd_tr:80/phpmyadmin/
Base de datos réplica	http://ip_bbdd_replica:80/phpmyadmin

8.1 Permisos de aplicaciones

Se crean a través del portal de administración VIVAit . Debe conocerse como funcionan los ejes [ver sección Portal de administracion - General - Ejes] y que existen cuatro aplicaciones creadas en la plataforma:

La forma como dar permisos de aplicaciones a un usuario esta explicada en la [| sección Portal de administracion - General - Usuarios ].

9 Integraciones con servicios externos

9.1 Presencia con Openfire

VIVAit se integra con servidor XMPP Openfire en su versión 3.10.2 (última probada)

Además del servidor, es necesario instalar un plugin de integración con asterisk 13, denominado "asterisk IM", versión 1.4.1

La instalación del servidor Openfire es una instalación estándar, realizada de paquete

La instalación del plugin es un "jar" que se carga desde la pagina de plugins de openfire

Con esto conseguiremos comunicar asterisk y OPenfire de manera que:

• Los estados telefónicos de una extensión VIVAit se reflejen en Openfire
• Poder marcar desde los clientes de IM instalados en los puestos
• Ver en el cliente llamadas entrantes al teléfono

---

Enlaces de interes:

Página proyecto openfire

Página proyecto "asterisk IM"

[| Volver al índice]