Diferencia entre revisiones de «Manual de operación VIVAit 5.1»

De VIVAitwiki
Ir a la navegaciónIr a la búsqueda
 
(No se muestran 344 ediciones intermedias del mismo usuario)
Línea 5: Línea 5:
 
|-
 
|-
 
|}<big>
 
|}<big>
== Introducción ==
+
== Introducción a la plataforma '''''VIVA'''it'' ==
 
<br><br>
 
<br><br>
En este documento se describe la arquitectura general de la plataforma '''''VIVA'''''it, detallando aquellos procesos principales que componen cada uno de los elementos del sistema, y sus principales elementos de diagnóstico.
+
En este documento se describe la plataforma <big>'''''VIVA'''''it</big> de <big>'''''<span style="color:#144F9B">MD</span>'''''Tel</big>, cuyo objetivo principal es proporcionar servicios de comunicaciones con tecnología VoIP.
 +
<br><br>
 +
La plataforma '''''VIVA'''it'' tiene dos proyecciones en el plano comercial, cuya denominación ser utilizará recurrentemente a lo largo de este documento:
 +
<br><br>
 +
:  • <big>'''''VIVA'''''it Call</big>, producto '''''VIVA'''''it para el entorno corporativo
 +
:  • <big>'''''VIVA'''''it Suite</big>, producto '''''VIVA'''''it para el entorno call center
 +
<br><br>
 +
Se documentan los procesos principales de cada elemento del sistema, así como sus componentes clave para el diagnóstico.<br>
 +
Por ello el presente documento se divide en cuatro grandes grupos:
 +
<br><br>
 +
: • [[#Arquitectura de la plataforma VIVAit          | '''Arquitectura de la plataforma ''VIVAit''''']]<br>
 +
: • [[#Descripción de los elementos software          | '''Descripción de los elementos software''']]<br>
 +
: • [[#Funcionalidades específicas en VIVAit          | '''Funcionalidades específicas en ''VIVAit''''']]<br>
 +
: • [[#Diagnósticos y operaciones básicas en VIVAit  | '''Diagnósticos y operaciones básicas en ''VIVAit''''']]
 
<br><br>
 
<br><br>
 
Quedan fuera del ámbito de este documento:
 
Quedan fuera del ámbito de este documento:
 
<br><br>
 
<br><br>
* Uso de aplicación de agente ('''''VIVA'''''it Desk)<br>
+
: * Uso de aplicación de agente ('''''VIVA'''''it Desk)<br>
* Uso de aplicación de supervisor ('''''VIVA'''''it Supervisor), incluyendo sus módulos autónomos ('''''VIVA'''''it reporting, '''''VIVA'''''it Tracker)<br>
+
: * Uso de aplicación de supervisor ('''''VIVA'''''it Supervisor), incluyendo sus módulos autónomos ('''''VIVA'''''it reporting, '''''VIVA'''''it Tracker)<br>
* Uso de portal de administración<br>
+
: * Uso de portal de administración<br>
* Uso de portal de traceo de llamadas y agentes ('''''VIVA'''''it Tracker web)<br>
+
: * Uso de portal de traceo de llamadas y agentes ('''''VIVA'''''it Tracker web)<br>
* Uso de portal de monitorización zabbix
+
: * Uso de portal de monitorización zabbix
 
<br><br>
 
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Introducción a la plataforma VIVAit]][[#Introducción a la plataforma VIVAit | Volver arriba]]
 +
</div>
 
<div style="
 
<div style="
 
   text-align:right;
 
   text-align:right;
Línea 41: Línea 65:
 
<br><br>
 
<br><br>
  
== Arquitectura ==
+
== Arquitectura de la plataforma '''''VIVA'''it''==
 
<br><br>
 
<br><br>
El sistema '''''VIVA'''it'' de '''''MDT'''el'' se compone de nodos de distinto tipo para proporcionar servicios de comunicaciones con tecnología VoIP.<br>
+
La plataforma '''''VIVA'''it'' de '''''<span style="color:#144F9B">MD</span>'''''Tel se compone de nodos de distinto tipo:  
Los módulos básico que definen el nodo son:<br>
 
: • '''Sistema Operativo''', sobre servidor en máquina física o virtualizada<br>
 
: • '''Asterisk''': gestiona llamadas telefónicas VoIP, integrando funciones de una central telefónica en un servidor<br>
 
: • '''DBTR''': gestor de la base de datos<br>
 
: • '''Tomcat''': servidor web para los diferentes portales: gestión, supervisor, usuario, traker, ...<br>
 
: • '''Webrtc''': gestionar llamadas telefónicas desde un navegador web
 
 
<br><br>
 
<br><br>
'''Ejemplo de entorno totalmente virtualizado'''
+
:''''' Nodo tipo operativo'''''<br>
 +
:Realiza funciones de encaminamiento de tráfico telefónico. Estarán dados de alta en el portal de gestión. Entre ellos están: <br>
 +
::''' Nodo Corporativo,''' para entornos corporativos de telefonía IP y diferentes aplicaciones. Nodo de procesamiento de telefonía corporativa. Tiene la aplicación Asterisk.<br>
 +
::''' Nodo Call Center,''' para los servicios típicos de call center. Nodo de procesamiento de call center. Tiene la aplicación Asterisk.<br>
 +
::''' Nodo Gateway,''' auxiliar del nodo corporativo para funciones de telefonía tradicional. Tiene la aplicación Asterisk.<br>
 +
:: '''Nodo STG,''' para gestionar tráfico telefónico a/desde internet. Este nodo asume la funcionalidad WebRTC que da soporte a terminales webfon e incorpora flexisip para terminales VCB.<br>
 +
::''' Nodo MCAM,''' para proporcionar servicios de multicanalidad.<br>
 +
:: '''Nodo Presencia,''' para proporcionar servicios de presencia.<br>
 +
:: '''Nodo Varios,''' utilizado normalmente para identificar un nodo tipo auxiliar.<br>
 
<br><br>
 
<br><br>
[[File:arquitectura_virtualización_V5.1.png|800px|center|thumb]]
+
:'''''Nodo tipo auxiliar'''''<br>
 +
:Realiza funciones auxiliares. Aunque conveniente no es necesario darlos de alta en el portal de gestión. Entre otros podemos encontrar:<br>
 +
::''' Nodo BBDD,''' soporta la base de datos del sistema, bien sea la de tiempo real o la de histórico. En entornos especialmente grandes, suele estar implementado en máquinas dedicadas (bien un servidor o de un clúster de dos servidores).<br>
 +
::''' Nodo de Gestión,'''  contiene el portal de administración y opcionalmente otros procesos auxiliares no relacionados directamente con la conmutación telefónica de llamadas como: otros portales tracker, GH (Gran Hermano).
 
<br><br>
 
<br><br>
'''Ejemplo de entorno virtualizado en varías máquinas'''
+
Esta sería la arquitectura funcional, en un proyecto determinado pueden coexistir varios de estos nodos en un solo servidor físico o virtual.<br>
 +
Los despliegues pueden ser múltiples pudiendo abarcar desde:
 
<br><br>
 
<br><br>
[[File:arquitectura_virtualización_2_V5.1.png|1500px|center|thumb]]
+
:''' Instalación sencilla,''' un solo servidor que contiene nodo corporativo + nodo de gestión + nodo BBDD.<br>
 +
:''' Instalación con máximo despliegue,''' cada nodo en un servidor, pudiendo existir varios nodos con la misma funcionalidad: varios nodos corporativos, varios nodos GW, etc.
 
<br><br>
 
<br><br>
En la versión actual los módulos software en los que se implementan estos nodos, según su funcionalidad, son:
+
En la versión actual los módulos software en los que se implementan los nodos que proporcionan servicios de VoIP son:<br>
 +
: • '''Sistema Operativo''', sobre servidor en máquina física o virtualizada<br>
 +
: • '''Asterisk''': gestiona llamadas telefónicas VoIP, integrando funciones de una central telefónica en un servidor<br>
 +
: • '''DBTR''': gestor de la base de datos<br>
 +
: • '''Tomcat/Apache''': servidor web para los diferentes portales: gestión, supervisor, usuario, traker, ...<br>
 +
: • '''Webrtc''': gestionar llamadas telefónicas desde un navegador web
 
<br><br>
 
<br><br>
 
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
 
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
Línea 68: Línea 104:
 
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Asterisk
 
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Asterisk
 
|-
 
|-
| style="padding:0.5cm; font-weight:bold;" | [[#Arquitectura nodo Corporativo | Corporativo]]
+
| style="padding:0.5cm; font-weight:bold;" | [[#Arquitectura nodo Corporativo | Corporativo / GW]]
 
| style="padding:0.5cm;" | Telefonía corporativa
 
| style="padding:0.5cm;" | Telefonía corporativa
 
| style="padding:0.5cm;" | Linux 6.12.63+deb13-amd64
 
| style="padding:0.5cm;" | Linux 6.12.63+deb13-amd64
Línea 84: Línea 120:
 
|}
 
|}
 
<br><br>
 
<br><br>
Para una información más detallada consultar [[#Descripción de los elementos, diagnósticos y operaciones | Versiones de los módulos software]]
+
Para una información más detallada consultar [[#Descripción de los elementos software | Versiones de los módulos software]]
 
<br><br>
 
<br><br>
 
<div style="
 
<div style="
Línea 95: Línea 131:
 
   display:inline-block;
 
   display:inline-block;
 
">
 
">
[[File:flecha_verde.png|20px|link=#Arquitectura]][[#Arquitectura | Volver arriba]]
+
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
 
</div>
 
</div>
 
<div style="
 
<div style="
Línea 123: Línea 159:
 
=== Arquitectura nodo ''Corporativo'' ===
 
=== Arquitectura nodo ''Corporativo'' ===
 
<br><br>
 
<br><br>
 
+
Un nodo Corporativo / GW se puede instalar en máquinas físicas (directamente sobre el hardware disponible) o sobre máquinas virtuales.<br>
<br><br>
+
El entorno virtualizado será el procedimiento preferido por '''''<span style="color:#144F9B">MD</span>'''''Tel siempre que no existan necesidades especiales que aconsejen el uso de máquinas físicas.<br>
 
+
Estas necesidades especiales suelen ser sistemas que tengan un alto volumen de llamadas y sea preferible la instalación en máquinas físicas.
 
<br><br>
 
<br><br>
 
<div style="
 
<div style="
Línea 136: Línea 172:
 
   display:inline-block;
 
   display:inline-block;
 
">
 
">
[[File:flecha_verde.png|20px|link=#Arquitectura]][[#Arquitectura | Volver arriba]]
+
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
 
</div>
 
</div>
 
<div style="
 
<div style="
Línea 162: Línea 198:
 
<br><br>
 
<br><br>
  
=== Arquitectura nodo ''Call Center'' ===
+
==== Arquitectura nodo ''Corporativo / GW'' sobre máquinas físicas ====
 +
<br><br>
 +
Este despliegue puede realizarse, según especificaciones del proyecto, sobre una solo máquina o sobre varias máquinas:
 +
<br><br>
 +
'''Todo en una sola máquina'''
 +
<br><br>
 +
Sobre la plataforma del sistema operativo se despliegan los distintos servicios necesarios. A continuación se muestran, una configuración mínima:
 +
<br><br>
 +
[[File:arquitectura_física_V5.1.png|1500px|center|thumb]]
 +
<br><br>
 +
'''Despliegue en varias máquinas'''
 
<br><br>
 
<br><br>
La arquitectura de este tipo de nodo se hereda de versiones anteriores.
+
Sobre el sistema operativo de cada máquina se despliegan los distintos servicios, distribuyéndolos según los procesos de instalación correspondiente.<br>
 +
El ejemplo anterior en dos máquinas físicas podría ser el siguiente:
 
<br><br>
 
<br><br>
[[File:arquitectura_call_center_V5.1.png|800px|center|thumb]]
+
[[File:arquitectura_física_2_V5.1.png|1500px|center|thumb]]
 
<br><br>
 
<br><br>
 +
En este caso se ha añadido DBTHIST, una base de datos que almacena información histórica para distintos propósitos, como seguridad, postproceso o copias de respaldo.
 
<div style="
 
<div style="
 
   text-align:right;
 
   text-align:right;
Línea 177: Línea 225:
 
   display:inline-block;
 
   display:inline-block;
 
">
 
">
[[File:flecha_verde.png|20px|link=#Arquitectura]][[#Arquitectura | Volver arriba]]
+
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
 
</div>
 
</div>
 
<div style="
 
<div style="
Línea 203: Línea 251:
 
<br><br>
 
<br><br>
  
==== Arquitectura del puesto de agente ====
+
==== Arquitectura nodo ''Corporativo'' sobre máquinas virtuales ====
 +
<br><br>
 +
El despliegue virtualizado puede realizarse, según especificaciones del proyecto, sobre una solo máquina física o sobre varias.<br>
 +
El entorno de virutalización es sobre el programa QEMU, que permite ejecutar un sistema operativo dentro de otro (host), como si fuera una “máquina dentro de otra máquina”
 +
<br><br>
 +
'''Todo en una sola máquina'''
 +
<br><br>
 +
El mínimo número de máquinas virtuales en una instalación son 2, un VIVAit-corporativo y una máquina de BD/Gestión.
 +
<br><br>
 +
[[File:arquitectura_virtualización_1_V5.1.png|1000px|center|thumb]]
 +
<br><br>
 +
En el caso de necesitar instalar tarjetas físicas para conectar líneas al sistema, se instalará Asterisk en la maquina física, pero este no será un nodo '''''VIVA'''it''.<br>
 +
se comportará como un conversor de líneas físicas a SIP y dentro de ''''VIVA'''it'' se configurarán las líneas como ''Trunk SIP''.
 +
<br><br>
 +
'''Despliegue en varias máquinas'''
 
<br><br>
 
<br><br>
Como complemento a la arquitectura Call Center se muestra la arquitectura asociada a los actores principales del ACD: agentes y supervisores.
+
El sistema estará compuesto de tantas máquinas virtuales como sean necesarias y el número de máquinas físicas necesarias para asumir la carga de la instalación.
 +
El ejemplo virtualizado anterior, en dos máquinas físicas, podría ser el siguiente:
 
<br><br>
 
<br><br>
[[File:Arquitectura-Puesto-Agente.jpg|1500px|center|thumb]]
+
[[File:arquitectura_virtualizacion_2_V5.1.png|1500px|center|thumb]]
 
<br><br>
 
<br><br>
 
<div style="
 
<div style="
Línea 218: Línea 281:
 
   display:inline-block;
 
   display:inline-block;
 
">
 
">
[[File:flecha_verde.png|20px|link=#Arquitectura]][[#Arquitectura | Volver arriba]]
+
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
 
</div>
 
</div>
 
<div style="
 
<div style="
Línea 244: Línea 307:
 
<br><br>
 
<br><br>
  
=== Arquitectura del nodo ''STG'' ===
+
=== Arquitectura nodo ''Call Center'' ===
 
<br><br>
 
<br><br>
 
+
La arquitectura de este tipo de nodo se hereda de versiones anteriores.
 
<br><br>
 
<br><br>
[[File:Arquitectura nodo STG.png |1500px|center|thumb]]
+
[[File:arquitectura_call_center_V5.1.png|800px|center|thumb]]
 
<br><br>
 
<br><br>
 
<div style="
 
<div style="
Línea 259: Línea 322:
 
   display:inline-block;
 
   display:inline-block;
 
">
 
">
[[File:flecha_verde.png|20px|link=#Arquitectura]][[#Arquitectura | Volver arriba]]
+
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
 
</div>
 
</div>
 
<div style="
 
<div style="
Línea 285: Línea 348:
 
<br><br>
 
<br><br>
  
== Descripción de los elementos, diagnósticos y operaciones ==
+
==== Arquitectura del puesto de agente ====
Las siguientes tablas definen los principales elementos software de la plataforma '''''VIVA'''''it, que son detallados en apartados siguientes:
+
<br><br>
 
+
Como complemento a la arquitectura Call Center se muestra la arquitectura asociada a los actores principales del ACD: agentes y supervisores.
 
+
<br><br>
 
+
[[File:Arquitectura-Puesto-Agente.jpg|1500px|center|thumb]]
{| class="wikitable"
+
<br><br>
|-
+
<div style="
|+ <big>'''Nivel de sistema operativo'''</big>
+
  text-align:right;
! Elemento!! Instancias!! Propósito!! Producto!! Observaciones
+
  margin-top:20px;
|-
+
  padding:8px;
| Ubuntu Server LTS 64 bits || Uno por servidor|| ||'''''VIVA'''''it Call
+
  border:1px solid #ccc;
'''''VIVA'''''it Suite
+
  background-color:#f9f9f9;
|| Actualmente (dic-2022) 20.04
+
  border-radius:6px;
Bajo proyecto puede cambiarse
+
  display:inline-block;
|-
+
">
| Almacenamiento de grabaciones|| Uno por sistema|| Almacenamiento de las grabaciones, ya sean de entorno corporativo o de contact center||'''''VIVA'''''it Call
+
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
'''''VIVA'''''it Suite
+
</div>
|| 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
+
<div style="
Pueden existir sistemas secundarios de almacenamiento de grabaciones
+
  text-align:right;
|-
+
  margin-top:20px;
|-
+
  padding:8px;
|}
+
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
=== Arquitectura del nodo ''STG'' ===
 +
<br><br>
 +
Este nodo está formado por los componentes que permiten conectar, a través de Internet, servicios de VoIP para terminales del sistema que acceden a los nodos corporativos.<br>
 +
Para minimizar la exposición de '''''VIVA'''it'' a redes abiertas, como internet, este nodo concentra las funciones que requieren conectividad con dichas redes.<br>
 +
Con esta filosofía de diseño conexiones de VIVAit Web Call, app como VCB, hardphone en internet, etc. serán controladas por este nodo.
 +
<br><br>
 +
[[File:Arquitectura nodo STG.png |1500px|center|thumb]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
 +
 +
=== Servicios de networking ===
 +
<br><br>
 +
Al integrar el sistema '''''VIVA'''it'' en la infraestructura del cliente, destinado a prestar servicios de VoIP, es fundamental considerar los servicios necesarios para su correcto funcionamiento.<br>
 +
Aunque los servidores pueden ser proporcionados por el sistema de '''''<span style="color:#144F9B">MD</span>'''''Tel, lo más habitual es que el cliente los aporte dentro de su propia infraestructura:
 +
<br><br>
 +
: * '''NTP''': el sistema en global ha de estar sincronizado; todos los servidores y puestos de trabajo (en el caso de ''VIVA''it Suite) han de estar perfectamente sincronizados. <br>
 +
::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<br>
 +
: * '''DNS''': la configuración de DNS de la plataforma será coherente con el resto de la plataforma IT del cliente<br>
 +
: * '''DHCP''': Es necesario coordinar con el cliente la asignación de direcciones para los diferentes elementos de la plataforma '''''VIVA'''''it, fundamentalmente para terminales telefónicos. <br>
 +
::En este caso será necesario activar la opción 66 del DHCP que permitirá definir el servidor TFTP del que los terminales descargaran sus ficheros de aprovisionamiento
 +
<br><br>
 +
[[File:arquitectura_networking_1_V5.1.png|1000px|center|thumb]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Arquitectura de la plataforma VIVAit]][[#Arquitectura de la plataforma VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
{| class="wikitable"
+
=== Conectividad en '''''VIVA'''it'' ===
|-
+
<br><br>
|+ <big>'''Nivel de conmutación de voz'''</big>
 
|-
 
! 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||'''''VIVA'''''it 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||'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||En el futuro se unificará con ACD
 
|-
 
|}
 
 
 
 
 
{| class="wikitable"
 
|-
 
|+ <big>'''Nivel de base de datos'''</big>
 
|-
 
! Elemento!! Instancias!! Propósito!! Producto!! Observaciones
 
|-
 
|MySQL 8.0||Donde haya BBDD de cualquier tipo (incluso zabbix)||Motor de Base de Datos||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
|-
 
|BBDD réplica||Una por sistema multinodo||Base de Datos para acceso a información de reporting…y similar||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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
 
|-
 
|}
 
 
 
  
{| class="wikitable"
+
==== Esquema '''''VIVA'''''it Call ====
|-
+
<br><br>
|+ <big>'''Nivel de procesos ''VIVA''it'''</big>
+
El esquema siguiente muestra todos los flujos de información existentes en un entorno típico de '''telefonía corporativa (sin presencia)'''
|-
+
<br><br>
! Elemento!! Instancias!! Propósito!! Producto!! Observaciones
+
[[Archivo:Flujos corporativa.png|1000px|center|thumb]]
|-
+
<br><br>
|Intz-Nimitz||Donde haya una BBDD de tiempo real o copia||Interfaz entre el dialplan y la base de datos||'''''VIVA'''''it Call
+
La descripción de los flujos se puede consultar en [[#Tabla de flujos VIVAit | Tabla de flujos '''''VIVA'''it'' ]]
'''''VIVA'''''it Suite
+
<br><br>
||No donde haya BBDD de réplica
 
Sistemas grandes pueden contemplar mas de un intz-nimitz central"
 
|-
 
|Intz-gh||En el nodo con menos carga|| Conocer el estado de las extensiones de diferentes nodos|| '''''VIVA'''''it Call || Solo va en un nodo. Recomendamos instalarlo en el nodo con menos carga. Si desconocemos cual
 
es, instalarlo en la maquina con BDHIST.
 
|-
 
|vivait-cti||Uno por servidor ACD||Interfaz entre '''''VIVA'''''it Desk, supervisor y el manager de asterisk||'''''VIVA'''''it Suite||
 
|-
 
|myAcdSuperv||Uno por servidor ACD||Recopilador de datos de asterisk y actualiza en la BBDD
 
Genera llamadas en el marcador
 
||'''''VIVA'''''it Suite
 
||
 
|-
 
|motorSal||Uno por sistema con ACD||Motor de marcador saliente automático||'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||
 
|-
 
|bdNodo||En cada nodo con BBDD de copia||Recoge la base de datos del servidor central con el objeto de tener el respaldo||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||
 
|-
 
|Actualizador||Uno por sistema con ACD||Se encarga de proporcionar las versiones actualizadas de las aplicaciones de puesto de trabajo||'''''VIVA'''''it Suite||En el mismo servidor que el portal de administración
 
|-
 
|phoneProv-tftp||Uno por sistema||Se encarga del aprovisionamiento masivo de terminales||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||||||||
 
|-
 
|}
 
  
 
+
==== Esquema '''''VIVA'''''it Suite ====
{| class="wikitable"
+
<br><br>
|-
+
En el entorno de Contact Center se encuentran los siguientes flujos entre servicios (comunicaciones entre servidores).
|+ <big>'''Administración'''</big>
+
<br><br>
|-
+
[[Archivo:Flujos Contact servicios.png|1000px|center|thumb]]
! Elemento!! Instancias!! Propósito!! Producto!! Observaciones
 
|-
 
|Tomcat 9||Uno por servidor con portales||Servidor de aplicaciones JAVA||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
|-
 
|Portal de administración ||Uno por sistema||Portal de administración del sistema||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||Bajo proyecto puede existir más de uno
 
|-
 
|Portal usuario||Uno por sistema||Portal de usuario, para acceso a buzones, su configuración||'''''VIVA'''''it Call||Bajo proyecto puede existir más de uno
 
|-
 
|Tracker web||Uno por sistema||Portal de seguimiento de llamadas||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||'''''VIVA'''''it Suite||Bajo proyecto puede existir más de uno
 
|-
 
|Apache||Uno por servidor de calendarios||Servidor de portales WEB||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||
 
|-
 
|Servidor de calendarios||Uno por sistema||Aloja calendarios para su uso en diferentes entornos de NIMITZ||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||Bajo proyecto puede existir más de uno
 
|-
 
|}
 
 
 
 
 
{| class="wikitable"
 
|-
 
|+ <big>'''Monitorización'''</big>
 
|-
 
! Elemento!! Instancias!! Propósito!! Producto!! Observaciones
 
|-
 
|Servidor zabbix||Uno por instalación||Monitorización técnica y de negocio||'''''VIVA'''''it Call
 
'''''VIVA'''''it 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||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||
 
|-
 
|Agente Zabbix||Uno por servidor||Agente de monitorización||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||
 
|-
 
||Scripts monitorización zabbix||Uno por servidor||Agente de monitorización||'''''VIVA'''''it Call
 
'''''VIVA'''''it Suite
 
||
 
|-
 
|}
 
 
<br><br>
 
<br><br>
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
+
La descripción de los flujos se puede consultar en [[#Tabla de flujos VIVAit | Tabla de flujos '''''VIVA'''it'' ]]
 
<br><br>
 
<br><br>
 
+
<div style="
 
+
   text-align:right;
===Versiones de módulos===
+
   margin-top:20px;
 
 
{| class="wikitable"
 
|-
 
! Módulo  !! VSuite
 
V.3.10
 
! VSuite
 
V.3.2.0
 
! VSuite
 
V.3.3.0
 
! VIVAit V.3.0.0
 
(VSuite 3.4+VCall3.0)
 
!  VIVAit V.3.1.0
 
(VSuite 3.5+VCall3.1)
 
! '''''<span style="color:#144F9B">VIVA</span>'''''it V.3.2
 
(VSuite 3.6+VCall 3.2)
 
! '''''<span style="color:#144F9B">VIVA</span>'''''it V.3.4
 
(VSuite 3.8+VCall 3.4)
 
! '''''<span style="color:#144F9B">VIVA</span>'''''it V.3.5
 
(VSuite 3.9+VCall 3.5)
 
! '''''<span style="color:#144F9B">VIVA</span>'''''it V.3.6
 
(VSuite 3.9+VCall 3.6)
 
! '''''<span style="color:#144F9B">VIVA</span>'''''it V.4.0
 
(VSuite 3.9+VCall 4.0)
 
! '''''<span style="color:#144F9B">VIVA</span>'''''it V.5.0
 
(VSuite 3.9+VCall 5.0)
 
! '''''<span style="color:#144F9B">VIVA</span>'''''it V.5.1
 
(VSuite 3.9+VCall 5.1)
 
|-
 
| Sistema Operativo || || || ||
 
|| Ubuntu 14.0.4 Server 64 Kb || Ubuntu 16.0.4 || Ubuntu 16.0.4 y Ubuntu 18.04 || Ubuntu 20 || Ubuntu 20 || Ubuntu 22 || Debian 12 || Debian 13
 
|-
 
|MySQL || || || || || 5.5 ||5.7 || 5.7 || 8.0 || 8.0 || 8.0 || 8.0 || ----
 
|-
 
|Mariadb || || || || || || || || || || || || 11.8
 
|-
 
|Tomcat|| || || || || 7 ||8 || 8 || 9 || 9 || 9 || 9 || 11
 
|-
 
|PHP || || || || || 5 ||7 || 7 || 7.4 || 7.4 || ---- || ---- || 8.4
 
|-
 
|OpenJDK || || || || || 7 ||8 || 8 || 11 || 11.0.17 || ---- || ---- || 11
 
|-
 
| Asterisk '''(*)''' || 1.4 || 1.4 || 1.4 || 1.4 Nodo ACD, 13 resto nodos || 1.4 Nodo ACD, 13 resto nodos ||1.4 Nodo ACD, 13 resto nodos ||1.4 Nodo ACD, 13 resto nodos ||1.4 Nodo ACD, 13 resto nodos ||1.4 Nodo ACD, 13.21 resto nodos ||1.4 Nodo ACD, 18 resto nodos ||1.4 Nodo ACD, 18 resto nodos  || 18
 
|-
 
|Asterisk ACD (VS)|| || || ||3.3.1||3.4.1||3.5.0||3.5.3 || 3.5.4 || 3.5.5 || ---- || ----  || ----
 
|-
 
|Asterisk Cisco (VC)|| || || ||3.3.4||3.4.4||3.5.1||3.5.4 || 3.5.5 || 3.5.5 || ----|| ----  || 3.7.0
 
|-
 
|Asterisk Corp (C)|| || || ||3.3.4||3.4.4||3.5.1||3.5.4 ||3.5.5 ||3.5.6 ||---- || ----  || 3.7.0
 
|-
 
|BD (C)||3.2.0||3.4.0||3.5.0||3.6.0||3.8.0||3.9.0||3.11.0 || 3.11.1 || 3.11.2 || 3.11.3 || 3.20.0  || 3.30
 
|-
 
|CargaContactos (VS)|| || || || || || ||3.8.0 || 3.8.0 || 3.8.0 || 3.8.0  ||  3.8.0  || 3.8.0
 
|-
 
|Dialplan ACD (VS)|| || || || ||3.5.0||3.6.0||3.8.1 || 3.8.2 || 3.8.3 || 3.8.4 || 3.9.0  || 3.10.0
 
|-
 
|Dialplan Corp (C)|| || || ||3.3.1||3.5.0||3.6.0||3.8.1 || 3.8.2 || 3.8.3 || 3.8.4 || 3.9.0  || 3.10.0
 
|-
 
|Generaconf (C)||3.0.0||3.0.0||3.2.0||3.4.0||3.5.0||3.6.0||3.8.0 || 3.8.1 || 3.8.2 || 3.8.3 || 3.9.0  || 3.9.3
 
|-
 
|Instalador (C)||3.1.0||3.2.0||3.3.0||3.4.0||3.5.0||3.6.0||3.8.0 || 3.9.0 || 3.10.0 || 3.11.0  || 3.20 || 3.20
 
|-
 
|Intz-gh (VC)|| || || || || ||0.1.0||0.1.1 || 0.1.2 || 0.1.3 || 0.1.4 || 0.1.5  || 0.1.7
 
|-
 
|Intz-nimitz (C)||2.6.0||3.0.1||3.0.3||3.4.1||3.4.2||3.4.4||3.5.0 || 3.7.1 || 3.08 || 4.0.0 || 4.0.1  || 4.0.3
 
|-
 
|Intz-tap (C)|| || || || || || || || || || || || 0.1.0
 
|-
 
|Janus (VS)|| || || || || || || ||  ||  || 0.0.8  || || 
 
|-
 
|Lazarus común (VS)||3.1.0||3.2.0||3.3.0||3.4.0||3.5.0||3.6.0||3.6.1 || 3.6.2 || 3.6.3 || 3.6.4 || ||
 
|-
 
|Mcan (VS)||---||---||---||---||---||---||--- || 0.1.5 || 0.1.5 || ---  || ---  || ---
 
|-
 
|MotorPredi (VS)||---||---||---||---||---||---||0.1.1 || 0.1.1 || 0.1.1 || ---- || ----  || ----
 
|-
 
|Motorsal (VS)||1.4.0||3.1.0||3.2.0||3.3.0||3.4.0||3.5.3||3.6.1 || 3.6.1 || 3.6.3 || 3.6.4 || ||
 
|-
 
|Multimonitorweb (VS)||3.0.1||3.0.2||3.1.0||3.1.0||3.2.0||3.2.0||3.4.1 || 3.4.1 || 3.4.3 || 3.4.4 || ||
 
|-
 
|MyACDSuperv (VS)||5.2.0||5.3.0||5.3.0||5.3.2||5.3.2||5.3.3||6.0.1 || 6.0.3 || 6.0.4 || 6.0.5 || ||
 
|-
 
|Phone_prov (C)||------||------||3.0.1||3.0.3||3.0.3||3.0.3||3.0.4 || 3.0.4 || 3.0.4 || 3.0.4  || 3.0.5 || 3.0.5
 
|-
 
|Portal de administración (C)||3.1.0||3.2.0||3.3.0||3.4.0||3.5.0||3.6.0||3.8.0 || 3.8.3 || 3.8.5 || 3.8.6 || 3.8.7  || 4.1.2
 
|-
 
|Portal usuario (VC)||------||------||------||3.0.0||3.1.0||4.0.0||4.1.0 || 4.1.0 || 4.1.1 || 4.1.2 || 4.1.3  || ----
 
|-
 
|Portal webfon (VC)||------||------||------||-----||-----||-----||-----||1.0.0 ||1.0.1 ||1.0.2 ||2.010  || 2.3.0
 
|-
 
|FonBo||------||------||------||-----||-----||-----||-----|| 1.0.0 || 1.0.1 || 1.0.1 || 1.0.1 || 2.0.5
 
|-
 
|Preview (VS)||1.0.18||3.2.0||3.3.0||3.4.0||3.5.0||3.5.0||---||--- ||--- ||--- ||----||----
 
|-
 
|recordCentral (C)||-----||-----||-----||4.0.0||4.0.1||4.0.2||4.0.3||4.0.3||4.0.3 ||4.0.4 || 4.0.4 || 4.0.4
 
|-
 
|recordgwd (C)||1.3.0||1.3.0||3.1.0||-----||-----||----||----||---- ||---- ||---- ||----  || ----
 
|-
 
|recordNodo (C)||-----||-----||-----||4.0.0||4.0.0||4.0.0||4.0.3||4.0.3||4.0.3 ||4.0.3 ||4.0.3
 
|-
 
|recordprocesad (C)||1.2.0||1.2.0||3.0.0||-----||-----||----||----||---- ||---- ||---- ||----  || ----
 
|-
 
|Sercen (C)  || || || || || || |||| || 0.03.01 || 0.03.|| 0.03.05  || 0.4.2
 
|-
 
|Supervisor Web (VS)|| || || || || || ||1.0.0||1.0.0 ||1.1.0 ||1.1.1 ||1.2.0  || 2.0.2
 
|-
 
|Tracker Web (C)||3.0.2||3.1.0||3.2.0||3.3.0||3.4.0||3.5.0||3.7.0||3.7.1||3.7.3 ||3.7.8  ||3.8.0  ||
 
|-
 
|Tracker Corporativo (C)|| || || || || || || || || || || || 0.1.0
 
|-
 
|Tracker windows (C)||3.0.0||3.1.0||3.2.0||3.3.0||3.4.0||3.4.0||----||---- ||---- ||---- ||----  || ----
 
|-
 
|VIVA designer (VS)||1.0.23||3.0.1||3.1.0||3.1.0||3.2.0||3.2.0||----||---- ||---- ||---- ||----  || ----
 
|-
 
|VIVA desk (VS)||3.0.2||3.2.0||3.3.0||3.4.0||3.5.0||3.5.2||3.5.3||3.6.1||3.6.6 ||3.6.7
 
|-
 
|VIVAit Call Business IOS ||---||---||---||---||---||---||--- || --- || --- || --- || 2.1.6  || 3.17.3
 
|-
 
|VIVAit Call Business Androit ||---||---||---||---||---||---||--- || --- || --- || --- || 2.1.6  || 3.0.17
 
|-
 
|VIVAit Call Celullar ||---||---||---||---||---||---||--- || --- || --- || --- ||  || 1.0.1
 
|-
 
|VIVAit Call Cloud ||---||---||---||---||---||---||--- || --- || --- || --- || ---  || ----
 
|-
 
|VIVA report (VS)||1.2.0||3.1.0||3.2.0||3.2.2||3.3.0||3.4.1||3.5.1||3.5.2||3.5.3 ||3.5.4 ||  ||
 
|-
 
|VIVA supervisor (VS)||3.0.0||3.1.0||3.2.0||3.3.0||3.4.0||3.6.1||3.8.0||3.8.1 ||3.8.2 ||3.8.3 || ||
 
|-
 
|Vivait-cti (VS)||3.0.0||3.0.1||3.0.1||3.0.1||3.0.2||3.0.2||4.0.1||4.0.3||4.0.3 || -- || --  || --
 
|-
 
|WebRTC (VC)||-----||-----||-----||-----||-----||-----||-----||0.0.1 ||0.0.6 ||0.0.7 ||0.0.9 || 0.0.10
 
|-
 
|Vivait-direc ||-----||-----||-----||-----||-----||-----||-----|| ----- || ----- || ----- || ----- || 0.0.8
 
|}
 
<br><br>
 
'''(C)''': Módulo común
 
<br><br>
 
'''(VC)''': Módulo de VIVAit Call
 
<br><br>
 
'''(VS)''': Módulo de VIVAit Suite
 
<br><br>
 
'''(*)''' La información sobre las versiones disponibles de Asterisk se puede encontrar en: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions.
 
<br><br>
 
[[File:asterisk1.PNG|700px|center]]
 
<br><br>
 
<div style="
 
   text-align:right;
 
   margin-top:20px;
 
 
   padding:8px;
 
   padding:8px;
 
   border:1px solid #ccc;
 
   border:1px solid #ccc;
Línea 629: Línea 509:
 
   display:inline-block;
 
   display:inline-block;
 
">
 
">
[[File:flecha_verde.png|20px|link=#Versiones de módulos]][[#Versiones de módulos | Volver arriba]]
+
[[File:flecha_verde.png|20px|link=#Conectividad en VIVAit]][[#Conectividad en VIVAit | Volver arriba]]
 
</div>
 
</div>
 
<div style="
 
<div style="
Línea 655: Línea 535:
 
<br><br>
 
<br><br>
  
=== Sistema Operativo ===
+
==== Esquema usuario-servidor ====
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 '''''VIVA'''''it es Ubuntu Server 20.04. LTS. Para más información https://wiki.ubuntu.com/Kernel/LTSEnablementStack.
+
<br><br>
 +
Entre usuarios y servicios se documentan los siguientes flujos:
 +
<br><br>
 +
[[Archivo:Flujos Contact puestos.png|1000px|center|thumb]]
 +
<br><br>
 +
La descripción de los flujos se puede consultar en [[#Tabla de flujos VIVAit | Tabla de flujos '''''VIVA'''it'' ]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Conectividad en VIVAit]][[#Conectividad en VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
==== Tabla de flujos '''''VIVA'''it'' ====
 +
<br><br>
 +
La sisguiente tabla muestra los flujos de datos que se establecen entre los distintos componentes del sistema '''''VIVA'''it''.
 +
<br><br>
 +
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
 +
|-
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Lado A
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Lado B
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Puertos
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Sentido
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Terminal telefónico
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 5060
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Señalización SIP
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Terminal telefónico
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | UDP 5060
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Señalización SIP
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Terminal telefónico
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | 10000 a 20000
 +
| style="padding:0.5cm;"                  | A -> B<br>
 +
B -> A
 +
| style="padding:0.5cm;"                  | RTP
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Terminal telefónico
 +
| style="padding:0.5cm;"                  | Servidor TFTP
 +
| style="padding:0.5cm;"                  | UDP 69
 +
| style="padding:0.5cm;"                  | A -> B<br>
 +
B -> A
 +
| style="padding:0.5cm;"                  | Para actualización de terminales por TFTP
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Terminal telefónico
 +
| style="padding:0.5cm;"                  | Servidor NTP
 +
| style="padding:0.5cm;"                  | UDP 123
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | '''''VIVA'''''it Desk
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 4500
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Comunicación CTI
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | '''''VIVA'''''it Desk
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 3306
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Acceso a Mysql Base de datos
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | '''''VIVA'''''it Desk
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | UDP 514
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Para envío de logs de agente
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | '''''VIVA'''''it Supervisor<br>
 +
aplicación de supervisor
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 4500
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Comunicación CTI
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | '''''VIVA'''''it Supervisor<br>
 +
portal de supervisión
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 3306
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Acceso a Mysql Base de datos
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | '''''VIVA'''''it Tracker
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 3306
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Acceso a Mysql Base de datos
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Tracker WEB
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 3306
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Acceso a Mysql Base de datos
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Actualizador
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 80
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Necesario para actualizaciones de versiones de aplicaciones de agente y supervisores
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Portales
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 443
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Acceso a los diferentes portales de '''''VIVA'''''it
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Monitor
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 8180
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Wallboard
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Monitorización
 +
| style="padding:0.5cm;"                  | Servidor
 +
| style="padding:0.5cm;"                  | TCP 80
 +
| style="padding:0.5cm;"                  | A -> B
 +
| style="padding:0.5cm;"                  | Acceso a portal monitorización (Zabbix)
 +
|-
 +
|}
 +
</div>
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Conectividad en VIVAit]][[#Conectividad en VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
<!--[[Archivo:ubuntu-versiones.png|750px]]-->
+
=== Gateways '''''VIVA'''it'' ===
 
+
<br><br>
 
+
El concepto de gateway no existe como entidad funcional dentro de la plataforma '''''VIVA'''''it. En su arquitectura únicamente se definen nodos ACD (Automatic Call Distribution) y nodos corporativos.<br>
[[File:ubuntu-versiones.png|750px|center]]
+
Desde el punto de vista operativo, el nodo corporativo es el encargado de asumir las funcionalidades típicamente asociadas a un gateway. En particular, gestiona la interconexión con sistemas externos, incluyendo interfaces analógicas, digitales e IP, así como la conexión con la Red Telefónica Conmutada.<br>
 
+
Por tanto, el término gateway queda limitado a un uso comercial o conceptual, sin correspondencia directa con elementos funcionales dentro de la plataforma.<br>
 
+
En consecuencia, los procedimientos de diagnóstico y operación relativos a la conectividad con sistemas externos o con la RTC deben realizarse conforme a los mecanismos definidos para el nodo corporativo.
 
+
<br><br>
'''A partir de la versión de VIVAit 5.0 el sistema operativo utilizado para la plataforma  es Debian 12'''
+
<div style="
 
+
  text-align:right;
=== Funcionamiento en cluster ===
+
  margin-top:20px;
 
+
  padding:8px;
Un clúster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad, de tal forma que el conjunto es visto como un único ordenador.
+
  border:1px solid #ccc;
 
+
  background-color:#f9f9f9;
De un clúster se espera que presente combinaciones de los siguientes servicios:
+
  border-radius:6px;
 
+
  display:inline-block;
# Alto rendimiento
+
">
# Alta disponibilidad
+
[[File:flecha_verde.png|20px|link=#Gateways VIVAit]][[#Gateways VIVAit | Volver arriba]]
# Balanceo de carga
+
</div>
# Escalabilidad
+
<div style="
 
+
  text-align:right;
Tal y como esta definido el cluster de MDtel, este comprueba conectividad con la otra máquina que lo forma y con un punto de confianza. Si la máquina no tiene conectividad con la otra y si con el punto de confianza es que el servidor está vivo, mientas que si no tengo conectividad ni con la otra máquina ni con el punto de confianza es que el muerto soy yo, por lo que balanceo.
+
  margin-top:20px;
 
+
  padding:8px;
Por lo que las máquinas balancean en los casos siguientes:
+
  border:1px solid #ccc;
 
+
  background-color:#f9f9f9;
* Todo lo que tenga que ver con la red, es decir, caída de la tarjeta de red, apagado de la máquina, corte en la red..
+
  border-radius:6px;
 
+
  display:inline-block;
Y no balancea en los siguientes:
+
">
 
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
* No balancea en los demás casos, es decir, todo lo que tenga que ver con procesos de una máquina (caída asterisk, base de datos, intz-nimitz)
+
</div>
 
+
<div style="
 
+
  text-align:right;
===== Píldoras =====
+
  margin-top:20px;
 
+
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
====== Prevenir que un nodo vuelva a tomar el control tras volver a estar operativo ======
+
== Descripción de los elementos software ==
 +
<br><br>
  
 +
=== Niveles funcionales del software ===
 +
<br><br>
 +
Los niveles funcionales o capas del software en el sistema '''''VIVA'''it'' cumplen una función específica y se apoyan en el nivel inferior.
 +
<br><br>
 +
La lista de los mismos es la siguiente:
 +
<br><br>
 +
: • [[#Nivel de sistema operativo | '''Nivel de sistema operativo''']]<br>
 +
: • [[#Nivel de conmutación de voz | '''Nivel de conmutación de voz''']]<br>
 +
: • [[#Nivel de base de datos | '''Nivel de base de datos''']]<br>
 +
: • [[#Nivel de procesos VIVAit | '''Nivel de procesos ''VIVAit''''']]<br>
 +
: • [[#Nivel de Administración | '''Nivel de Administración''']]<br>
 +
: • [[#Nivel de Monitorización | '''Nivel de Monitorización''']]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
Cuando queremos evitar que un recurso vuelva al nodo en el que estaba originalmente tras la recuperación del nodo, ejecutaremos la siguiente orden.
+
==== Nivel de sistema operativo ====
 
+
<br><br>
pcs resource defaults resource-stickiness=100
+
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
 
+
|-
====== Borrar un recurso ======
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Elemento
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Instancias
pcs resource delete DRBDFs
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Propósito
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Producto
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Ubuntu Server LTS <br>
 +
64 bits
 +
| style="padding:0.5cm;"                  | Uno por servidor
 +
| style="padding:0.5cm;"                  |
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Actualmente (may-2026) 22.04. Bajo proyecto puede cambiarse
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Debian LTS
 +
| style="padding:0.5cm;"                  | Uno por servidor
 +
| style="padding:0.5cm;"                  |
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Actualmente (may-2026) 13 (Trixie). Bajo proyecto puede cambiarse
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Almacenamiento de grabaciones
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Almacenamiento de las grabaciones, ya sean de entorno corporativo o de Contact Center
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | 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
 +
|}
 +
<br><br>
 +
Para más detalles, consultar el apartado [[#Sistema Operativo |Sistema Operativo]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
====== Sincronización del drbd ======
+
==== Nivel de conmutación de voz ====
 
+
<br><br>
Para sincronizar el drdb tras un fallo tenemos que determinar cuál es el nodo que tiene los datos buenos y cuál es el que vamos a sobrescribir sus datos
+
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
 
+
|-
En el nodo que vamos a sobrescribir los datos ejecutaremos los siguientes comandos.
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Elemento
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Instancias
drbdadm secondary all
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Propósito
drbdadm disconnect all
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Producto
drbdadm invalidate all
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones
drbdadm connect all
+
|-
 
+
| style="padding:0.5cm; font-weight:bold;" | Asterisk 1.4.24 <br>
 
+
by MDtel
Y en el nodo que tiene los datos correctos.
+
| style="padding:0.5cm;"                  | Uno por servidor ACD
 
+
| style="padding:0.5cm;"                  | Núcleo de conmutación de voz basado en Asterisk 1.4 y modificado por MDtel
drbdadm connect all
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Fuertemente modificado por MDtel. En el futuro migrará a Asterisk 18.9 Certified
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Dialplan ACD <br>
 +
by MDtel
 +
| style="padding:0.5cm;"                  | Uno por servidor ACD
 +
| style="padding:0.5cm;"                  | Configuración de voz
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | En el futuro se unificará con corporativa
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Asterisk 18.9 <br>
 +
Certified by MDtel
 +
| style="padding:0.5cm;"                  | Uno por servidor corporativo / gateway
 +
| style="padding:0.5cm;"                  | Núcleo de conmutación de voz basado en Asterisk 18.9 y modificado por MDtel
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Actualmente Asterisk estándar (05/26). <br>
 +
La instalación contempla descargar de la red la versión 18 más actualizada, siempre "CERTIFIED"
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Dialplan corporativo
 +
| style="padding:0.5cm;"                  | Uno por servidor corporativo/gateway
 +
| style="padding:0.5cm;"                  | Configuración de voz|
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | En el futuro se unificará con ACD
 +
|}
 +
<br><br>
 +
Para más detalles, consultar el apartado [[#Matriz de conmutación |Matriz de conmutación]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
==== Nivel de base de datos ====
 +
<br><br>
 +
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
 +
|-
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Elemento
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Instancias
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Propósito
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Producto
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | MySQL 8.0.45
 +
| style="padding:0.5cm;"                  | Donde haya BBDD de cualquier tipo (incluso zabbix)
 +
| style="padding:0.5cm;"                  | Motor de Base de Datos para Ubuntu 22.04
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | A efectos prácticos se pretende que sea la BBDD de todos los servicios
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | MariaDB 11.8.3
 +
| style="padding:0.5cm;"                  | Donde haya BBDD de cualquier tipo
 +
| style="padding:0.5cm;"                  | Motor de Base de Datos para Debian 13
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | A efectos prácticos se pretende que sea la BBDD de todos los servicios
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | DBTR
 +
| style="padding:0.5cm;"                  | Una por sistema
 +
| style="padding:0.5cm;"                  | Base de Datos sobre la que trabaja todo el entorno de tiempo real
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | DBHIST
 +
| style="padding:0.5cm;"                  | Una por sistema multinodo
 +
| style="padding:0.5cm;"                  | Base de Datos para postproceso, como reporting, traker, supervisor, ... Subconjunto de tablas de DBTR con la que está sincronizada
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de una. <br>
 +
En el nodo en el que exista réplica existirá además copia (excepto nodo ACD)
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | DB copia
 +
| style="padding:0.5cm;"                  | Uno por servidor corporativo / gateway
 +
| style="padding:0.5cm;"                  | Copia de tablas de configuración de DBTR para respaldo de la misma
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | 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
 +
|}
 +
</div>
 +
<br><br>
 +
Para más detalles, consultar el apartado [[#Bases de datos (BBDD) |Bases de Datos]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
====== Mover un recurso de nodo ======
+
==== Nivel de procesos '''''VIVA'''it'' ====
 
+
<br><br>
Para mover un recurso de nodo utilizaremos el siguiente comando.
+
La mayoría de los elementos aparecen como servicios en los nodos correspondientes.
 
+
<br><br>
pcs resource move IP-ASTER
+
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
pcs resource clear IP-ASTER
+
|-
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Elemento
Esto crea restricciones locales para evitar que el recurso vuelva a este nodo (Puede tener prioridad de ejecución en este nodo y haría que volviera a este nodo automáticamente al estar online).
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Instancias
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Propósito
La restricción que crea banea el nodo para este recurso, si queremos quitar esta restricción creada.
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Producto
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones
pcs resource clear DRBDfsASTER
+
|-
 
+
| style="padding:0.5cm; font-weight:bold;" | intz-nimitz
<span style="color:#f32100">Mirar si existe alguna manera de mover un recurso sin que se creen estas restricciones locales</span>
+
| style="padding:0.5cm;"                  | Donde haya una BBDD de tiempo real o copia
 
+
| style="padding:0.5cm;"                  | Interfaz entre el dialplan y la base de datos
 
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
====== Habilitar/deshabilitar recursos ======
+
| style="padding:0.5cm;"                  | No donde haya BBDD de réplica.<br>
 
+
En sistemas grandes pueden contemplar más de un intz-nimitz
Los comandos para habilitar y deshabilitar recursos en un nodo son
+
|-
 
+
| style="padding:0.5cm; font-weight:bold;" | intz-gh
Si especificamos un tiempo, pcs esperara este tiempo y retornara 0 si el recurso a parado o 1 si el recurso no ha parado en el tiempo especificado.
+
| style="padding:0.5cm;"                  | En el nodo con menos carga
 
+
| style="padding:0.5cm;"                  | Conocer el estado de las extensiones de diferentes nodos
pcs resource disable resource_id [--wait[=n]]
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 
+
| style="padding:0.5cm;"                  | Solo va en un nodo. Si desconocemos cual es el nodo con menos carga, instalarlo en la maquina con BDHIST
Si especificamos un tiempo, pcs esperara este tiempo y retornara 0 si el recurso a arrancado o 1 si el recurso no ha arrancado en el tiempo especificado.
+
|-
 
+
| style="padding:0.5cm; font-weight:bold;" | intz-tap
pcs resource enable resource_id [--wait[=n]]
+
| style="padding:0.5cm;"                  | En los nodos corporativos
pcs config show
+
| style="padding:0.5cm;"                  | Encargado de la grabación SIPREC y TBC
pcs resource cleanup resource_id
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
pcs resource clear
+
| style="padding:0.5cm;"                  | Junto al modulo chan_mdtap de asterisk para enviar los flujos RTP a un elemento externo
pcs resource refresh
+
|-
 
+
| style="padding:0.5cm; font-weight:bold;" | serCen
Borra los Failed Actions de un recurso:
+
| style="padding:0.5cm;"                  | En nodo STG y nodo de gestión
 
+
| style="padding:0.5cm;"                  | Encargado de la autenticidad y doble factor de los usuarios
pcs resource cleanup [recurso]
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 
+
| style="padding:0.5cm;"                  | Proporciona servicios a los diferentes portales (front-end) del sistema
====== Notas sincronismo ======
+
|-
 +
| style="padding:0.5cm; font-weight:bold;" | vivait-direct
 +
| style="padding:0.5cm;"                  | En nodo STG y nodo de gestión
 +
| style="padding:0.5cm;"                   | Centraliza y gestiona la consulta de agendas y contactos desde distintas fuentes de datos. <br>
 +
Alternativa a Vivait-FonBO que sigue gestionando el histórico de llamadas
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Servicio invocado por los portales vivait-user y webfon2
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | vivait-cti
 +
| style="padding:0.5cm;"                  | Uno por servidor ACD
 +
| style="padding:0.5cm;"                  | Interfaz entre '''''VIVA'''''it Desk, supervisor y el manager de asterisk
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | motorSal
 +
| style="padding:0.5cm;"                  | Uno por servidor ACD
 +
| style="padding:0.5cm;"                  | Motor de marcador saliente automático
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Solo si hay marcación saliente. Junto a DBTR
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | myAcdSuperv
 +
| style="padding:0.5cm;"                  | Uno por servidor ACD
 +
| style="padding:0.5cm;"                  | Recopilador de datos de asterisk y actualiza en la BBDD. Genera llamadas en el marcador
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | recordCentral
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Servidor de grabaciones, los agentes (recorNodo) se conectan a él
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | 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
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | recordNodo
 +
| style="padding:0.5cm;"                  | Uno por servidor corporativo / gateway
 +
| style="padding:0.5cm;"                  | Agente de grabación
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | bdCentral
 +
| style="padding:0.5cm;"                  | Uno, en el nodo con la BBDD de tiempo real
 +
| style="padding:0.5cm;"                  | Genera la base de datos que se copiará para respaldo a otros nodos
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | bdNodo
 +
| style="padding:0.5cm;"                  | En cada nodo con BBDD de copia
 +
| style="padding:0.5cm;"                  | Recoge la base de datos del servidor central con el objeto de tener el respaldo
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Actualizador
 +
| style="padding:0.5cm;"                  | Uno por sistema con ACD
 +
| style="padding:0.5cm;"                  | Se encarga de proporcionar las versiones actualizadas de las aplicaciones de puesto de trabajo
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | En el mismo servidor que el portal de administración
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | phoneProv-tftp
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Se encarga del aprovisionamiento masivo de terminales
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | En instalaciones grandes habrá más de uno, quizás uno por sede grande; depende de la infraestructura de DHCP
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | borraregistrosnimitz
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Se encarga de la gestión de las bases de datos, aplicando políticas de retención que limitan la persistencia de los registros hasta una fecha máxima establecida.
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | En la BDTR es típico dejar 6 meses y en BDHIST 5 anos.
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | movergrabacionesanube
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Guardar las grabaciones un un NAS del cliente
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Utiliza el módulo RecordCentral
 +
|}
 +
</div>
 +
<br><br>
 +
Para más detalles, consultar el apartado [[#Procesos propios VIVAit | Procesos propios VIVAit]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
Si tenemos este fallo:
+
==== Nivel de Administración ====
 
+
<br><br>
root@VC-PROC-SUMA-ALC-02:/tmp# cat /proc/drbd
+
Este nivel software proporciona servicios para administrar el sistema y servicios al usuario final. Se estructura en dos capas:
version: 8.4.10 (api:1/proto:86-101)
+
<br><br>
srcversion: 7922D81D3881494EB149253
+
: • [[#Nivel de Administración - Front-end| '''Front-end''']]: capa de presentación que interactúa con el usuario (portales web, interfaces gráficas o paneles de control), encargada de mostrar la información y recoger las acciones del usuario.<br>
   0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
+
: • [[#Nivel de Administración - Back-end| '''Back-end''']]: capa de lógica y procesamiento donde se gestionan los servicios, la ejecución de aplicaciones y el acceso a datos, apoyándose en servidores como Apache HTTP Server y Apache Tomcat.
root@VC-PROC-SUMA-ALC-01:~# cat /proc/drbd
+
<br><br>
version: 8.4.10 (api:1/proto:86-101)
+
Para obtener más información del tipo administración consultar el apartado [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Portales_de_administraci%C3%B3n_VIVAit Portales de Administración].<br>
srcversion: 7922D81D3881494EB149253
+
Para ver los diferentes portales de usuario ver [[#Portales web corporativos | Portales web corporativos]].
   0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown   r-----
+
<br><br>
 
+
</div>
 
+
<br><br>
En el nodo principal
+
<div style="
 
+
  text-align:right;
drbdadm connect all
+
  margin-top:20px;
 +
  padding:8px;
 +
   border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
   background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
   text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
En el nodo secundario
 
  
drbdadm -- --discard-my-data connect all
 
  
********* En secundario: **************
+
===== Nivel de Administración - Front-end =====
drbdadm secondary drbdASTER
+
<br><br>
drbdadm disconnect drbdASTER
+
Se compone de dos entidades:
drbdadm -- --discard-my-data connect drbdASTER
+
<br><br>
 
+
: • '''Servidores''': donde se ejecutan las aplicaciones y servicios web, como Apache HTTP Server.<br>
********* En primario: ****************
+
: • '''Clientes''': interfaces de acceso para los usuarios, como portales web.
drbdadm primary drbdASTER
+
<br><br>
drbdadm disconnect drbdASTER
+
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
drbdadm connect drbdASTER
+
|-
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Elemento
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Instancias
====== Configuración para KVM ======
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Propósito
 
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Producto
'''vi /etc/multipath.conf'''
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones                |
-----------------------------
+
|-
defaults {
+
| style="padding:0.5cm; font-weight:bold;" | Apache2
    user_friendly_names yes
+
| style="padding:0.5cm;"                  | Uno por servidor con portales
}
+
| style="padding:0.5cm;"                  | Servidor de páginas web. Servidor de portales. No usa JAVA
blacklist {
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]"
+
| style="padding:0.5cm;"                  |
devnode "^vd[b-z]?[0-9]"
+
|-
devnode "vda"
+
| style="padding:0.5cm; font-weight:bold;" | Vivait-Call
devnode "vda1"
+
| style="padding:0.5cm;"                  | Uno por sistema
devnode "^drbd[0-9]*"
+
| style="padding:0.5cm;"                  | Portal de administración del sistema
}
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de uno
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | vivait-user
 +
| style="padding:0.5cm;"                  | Uno por sistema en nodo STG
 +
| style="padding:0.5cm;"                  | Portal de usuario, para acceso a buzones, configuración, etc.
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de uno
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | webfon2
 +
| style="padding:0.5cm;"                  | Uno por sistema en nodo STG
 +
| style="padding:0.5cm;"                  | Portal de VIVAit Call Web
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de uno
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | webfon2-solo
 +
| style="padding:0.5cm;"                  | Uno por sistema en nodo STG
 +
| style="padding:0.5cm;"                  | Dialpad de VIVAit Call Web.<br>
 +
webfon2 =  vivait-user + webfon2-solo
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de uno
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Vivait-Tracker
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Portal de seguimiento de llamadas ''Denominado Tracker web''.
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Debe instalarse en un servidor que tenga los ficheros de grabación montados en su sistema de archivos.<br>
 +
Ligado a recordCentral
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Tracker-Corp
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Portal de seguimiento de llamadas del entorno corporativo. ''Denominado Tracker corporativo''.
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Debe instalarse en un servidor que tenga los ficheros de grabación montados en su sistema de archivos.<br>
 +
Ligado a recordCentral
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Monitor
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Portal de monitores de pared de Call Center
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de uno
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Vivait-Supervisor
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Portal de monitorización de llamadas del entorno corporativo
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de uno
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Baikal
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Servidor de calendarios para su uso en diferentes entornos de nimitz
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|}
 +
</div>
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
systemctl restart multipathd.service
+
===== Nivel de Administración - Back-end =====
 
+
<br><br>
'''vi /etc/corosync/corosync.conf'''
+
Se compone principalmente de los siguientes elementos:
------------------------------------
+
<br><br>
totem {
+
: • '''Servidor''': infraestructura donde se alojan las aplicaciones y servicios que exponen APIs (por ejemplo, aplicaciones Java desplegadas en servidores como Apache Tomcat).<br>
    version: 2
+
::Recibe peticiones web (HTTP), ejecuta el código Java de la aplicación y devuelve la respuesta al cliente (navegador, app, etc.).<br>
    cluster_name: CLmdtel
+
: • '''Clientes''': aplicaciones externas (front-end, apps móviles, otros sistemas) que consumen las APIs del back-end.
    transport: knet
+
<br><br>
    crypto_cipher: aes256
+
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
    crypto_hash: sha256
+
|-
    token: 12000
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Elemento
}
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Instancias
nodelist {
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Propósito
    node {
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Producto
        ring0_addr: nodo-vc-01
+
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones
        name: nodo-vc-01
+
|-
        nodeid: 1
+
| style="padding:0.5cm; font-weight:bold;" | Tomcat11
    }
+
| style="padding:0.5cm;"                  | Uno por sistema
    node {
+
| style="padding:0.5cm;"                  | Servidor de aplicaciones web Apache Tomcat especializado en ejecutar aplicaciones desarrolladas en Java.
        ring0_addr: nodo-vc-02
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
        name: nodo-vc-02
+
| style="padding:0.5cm;"                  | Para proyectos especiales puede existir uno por contexto JAVA
        nodeid: 2
+
|-
    }
+
| style="padding:0.5cm; font-weight:bold;" | cargaClickToCall
}
+
| style="padding:0.5cm;"                  | Uno por sistema
quorum {
+
| style="padding:0.5cm;"                  | Inserción en BBDD de la tabla ACD_LISTAS_LLAMAME a través de los parámetros proporcionados
    provider: corosync_votequorum
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
    two_node: 1
+
| style="padding:0.5cm;"                  | Se invoca desde el portal Vivait-Call
}
+
|-
logging {
+
| style="padding:0.5cm; font-weight:bold;" | cargaContactos
    to_logfile: yes
+
| style="padding:0.5cm;"                  | Uno por sistema
    logfile: /var/log/corosync/corosync.log
+
| style="padding:0.5cm;"                  | Inserción en BBDD de las tablas ACD_CONTACTOS y ACD_CONTACTOS_CAMPANNA a través de los parámetros proporcionados
    to_syslog: yes
+
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
    timestamp: on
+
| style="padding:0.5cm;"                  | Se invoca desde el portal Vivait-Call
}
+
|-
 +
| style="padding:0.5cm; font-weight:bold;" | ChatWebService
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Interface entre el formulario de chat del VivaDesk y el servicio de chansip
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Servicio de multicanal texto
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | GeneraConf
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Sincroniza cambios en algunas tablas de la BBDD con ficheros Asterisk
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Se invoca desde el portal Vivait-Call
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | generaLlamada
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Generación de una llamada telefónica a partir de la invocación al servicio
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Creación de un archivo de llamada Asterisk y puesta en la carpeta outgoing
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | InfoWS
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Proporciona información de llamadas de la BBDD y gestiona  grabaciones
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | La información de las llamadas puede ser de DBTR o DBHIST.<br>
 +
Inicia/finaliza grabaciones y mediante un script se trasladan los archivos de grabación a un directorio de ficheros específico
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Vivait-FonBO
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Proporciona información de la agenda e histórico de llamadas
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Invocado por los portales vivait-user y webfon2
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Vivait-Supervisor
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Obtiene información de la BBDD y ejecuta acciones en el entorno corporativo.
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Se invoca desde el portal Vivait-Supervisor
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Tracker-Rest
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Proporciona información de las llamadas corporativas y los ficheros de audio de las posibles grabaciones asociadas
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call
 +
| style="padding:0.5cm;"                  | Se invoca desde el portal Tracker-Corp
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Vivait-Tracker
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Proporciona información de las llamadas y los ficheros de audio de las posibles grabaciones asociadas.<br>
 +
Permite valorar las llamadas
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Se invoca desde el portal Vivait-Tracker
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Vivait-Call
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Gestiona DBTR. Lee, crea, borra y actualiza los registros en las tablas de nimitz
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Se invoca desde el portal Vivait-Call
 +
|}
 +
</div>
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
systemctl restart corosync
+
==== Nivel de Monitorización ====
 
+
<br><br>
'''Revisar que están arrancados después de reinicar:'''
+
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
Corosync Pacemaker multipath
+
|-
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Elemento
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Instancias
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Propósito
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Producto
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Observaciones
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Servidor Zabbix
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Monitoriza el estado y el rendimiento del sistema en tiempo real
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  | Bajo proyecto puede existir más de uno. Típicamente irá o en BBDD replica o en nodo de gestión en instalaciones grandes
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Template Zabbix
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Define qué se va a monitorizar y cómo hacerlo de forma reutilizable
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Agente Zabbix
 +
| style="padding:0.5cm;"                  | Uno por sistema a monitorizar
 +
| style="padding:0.5cm;"                  | Componente que se instala en los equipos que se quieres monitorizar para recoger información directamente del sistema
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Script monitorización Zabbix
 +
| style="padding:0.5cm;"                  | Uno por sistema
 +
| style="padding:0.5cm;"                  | Amplia lo que el sistema puede vigilar, especialmente cuando algo no se puede medir con las opciones estándar
 +
| style="padding:0.5cm;"                  | '''''VIVA'''''it Call / '''''VIVA'''''it Suite
 +
| style="padding:0.5cm;"                  |
 +
|}
 +
</div>
 +
<br><br>
 +
Para más detalles, consultar el apartado [[#Monitorización en VIVAit | Monitorización en VIVAit]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Niveles funcionales del software]][[#Niveles funcionales del software| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
===Versiones de módulos===
 +
<br><br>
 +
{| class="wikitable" style="margin-left:auto; margin-right:auto; border:none;"
 +
|-
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | Módulo
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VSuite V.3.1
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VSuite V.3.2
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VSuite V.3.3
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.3.0 (VSuite 3.4 + VCall 3.0)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.3.1 (VSuite 3.5 + VCall 3.1)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.3.2 (VSuite 3.6 + VCall 3.2)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.3.4 (VSuite 3.8 + VCall 3.4)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.3.5 (VSuite 3.9 + VCall 3.5)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.3.6 (VSuite 3.9 + VCall 3.6)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.4.0 (VSuite 3.9 + VCall 4.0)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.5.0 (VSuite 3.9 + VCall 5.0)
 +
! align=center style="padding:0.5cm; background-color:#0099ff; color:white;" | VIVAit V.5.1 (VSuite 3.9 + VCall 5.1)
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Año de lanzamiento
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | 2015
 +
| align=center style="padding:0.2cm";      | 2016
 +
| align=center style="padding:0.2cm";      | 2018
 +
| align=center style="padding:0.2cm";      | 2020
 +
| align=center style="padding:0.2cm";      | 2021
 +
| align=center style="padding:0.2cm";      | 2022
 +
| align=center style="padding:0.2cm";      | 2023
 +
| align=center style="padding:0.2cm";      | 2025
 +
| align=center style="padding:0.2cm";      | 2026
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Sistema Operativo
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | Ubuntu 14.0 LTS
 +
| align=center style="padding:0.2cm;      | Ubuntu 14.0 LTS
 +
| align=center style="padding:0.2cm;      | Ubuntu 16.0 LTS 
 +
| align=center style="padding:0.2cm;      | Ubuntu 18.4 LTS
 +
| align=center style="padding:0.2cm;      | Ubuntu 20.4 LTS 
 +
| align=center style="padding:0.2cm;      | Ubuntu 20.4 LTS 
 +
| align=center style="padding:0.2cm;      | Ubuntu 20.4 LTS 
 +
| align=center style="padding:0.2cm;      | Ubuntu 22.4 LTS nodos ACD y Cisco<br>
 +
Debian 12 resto de nodos
 +
| align=center style="padding:0.2cm;      | Ubuntu 22.4 LTS nodos ACD y Cisco<br>
 +
Debian 13 resto de nodos
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | MySQL (C)
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | 5.5
 +
| align=center style="padding:0.2cm;      | 5.5 
 +
| align=center style="padding:0.2cm;      | 5.7 
 +
| align=center style="padding:0.2cm;      | 5.7
 +
| align=center style="padding:0.2cm;      | 8.0
 +
| align=center style="padding:0.2cm;      | 8.0
 +
| align=center style="padding:0.2cm;      | 8.0 
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Mariadb (C)
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ----
 +
| align=center style="padding:0.2cm;      | ---- 
 +
| align=center style="padding:0.2cm;      | 10.11
 +
| align=center style="padding:0.2cm;      | 11.4
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Apache Tomcat (C) || ---- || ---- || ---- || ---- || 7 ||8 || 8 || 9 || 9 || 9 || 9 || 11
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | PHP (C) || ---- || ---- || ---- || 5.6 || 5.6 || 7.0 || 7.0 || 7.4 || 7.4 || 8.2 || 8.4 || 8.4
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | OpenJDK (C) || ---- || ---- || ---- || ---- || 7.0 ||8.0 || 8.0 || 11.0 || 11.0 || 11.0 || 11.0 || 21.0
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;"  | Asterisk LTS '''(*)'''
 +
| align=center style="padding:0.2cm";        | 1.4  nodo ACD
 +
| align=center style="padding:0.2cm";        | 1.4  nodo ACD
 +
| align=center style="padding:0.2cm";        | 1.4  nodo ACD
 +
| align=center style="padding:0.2cm";        | 1.4  nodo ACD, <br>
 +
13 resto nodos
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
13 resto nodos
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
13 resto nodos 
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
13 resto nodos 
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
13 resto nodos
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
13 resto nodos
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
18 resto nodos
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
18 resto nodos 
 +
| align=center style="padding:0.2cm";        | 1.4 nodo ACD, <br>
 +
18 resto nodos
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Asterisk MDTel <br>
 +
nodo ACD (VS)
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | ---- 
 +
| align=center style="padding:0.2cm";      | ---- 
 +
| align=center style="padding:0.2cm";      | 3.3.1
 +
| align=center style="padding:0.2cm";      | 3.4.1
 +
| align=center style="padding:0.2cm";      | 3,5,0
 +
| align=center style="padding:0.2cm";      | 3.5.3
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
| align=center style="padding:0.2cm";      | 3.5.5
 +
| align=center style="padding:0.2cm";      | 3.5.5
 +
| align=center style="padding:0.2cm";      | 3.5.5
 +
| align=center style="padding:0.2cm";      | 3.5.5
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Asterisk MDTel <br>
 +
nodo Corp Cisco (VC)
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | ---- 
 +
| align=center style="padding:0.2cm";      | 3.3.4
 +
| align=center style="padding:0.2cm";      | 3.4.4
 +
| align=center style="padding:0.2cm";      | 3.5.1
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Asterisk MDTel <br>
 +
nodo Corp / GW (VC)
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | ----
 +
| align=center style="padding:0.2cm";      | ---- 
 +
| align=center style="padding:0.2cm";      | 3.3.4
 +
| align=center style="padding:0.2cm";      | 3.4.4
 +
| align=center style="padding:0.2cm";      | 3.5.1
 +
| align=center style="padding:0.2cm";      | 3.5.4
 +
| align=center style="padding:0.2cm";      | 3.5.5
 +
| align=center style="padding:0.2cm";      | 3.5.6
 +
| align=center style="padding:0.2cm";      | 3.5.6
 +
| align=center style="padding:0.2cm";      | 3.6.0
 +
| align=center style="padding:0.2cm";      | 3.7.0
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | BD (C)||3.2.0||3.4.0||3.5.0||3.6.0||3.8.0||3.9.0||3.11.0 || 3.11.1 || 3.11.2 || 3.11.3 || 3.20.0  || 3.30
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | CargaContactos (VS)|| || || || || || ||3.8.0 || 3.8.0 || 3.8.0 || 3.8.0  ||  3.8.0  || 3.8.0
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Dialplan ACD (VS)|| || || || ||3.5.0||3.6.0||3.8.1 || 3.8.2 || 3.8.3 || 3.8.4 || 3.9.0  || 3.10.0
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Dialplan Corp (C)|| || || ||3.3.1||3.5.0||3.6.0||3.8.1 || 3.8.2 || 3.8.3 || 3.8.4 || 3.9.0  || 3.10.0
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Generaconf (C)||3.0.0||3.0.0||3.2.0||3.4.0||3.5.0||3.6.0||3.8.0 || 3.8.1 || 3.8.2 || 3.8.3 || 3.9.0  || 3.9.3
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Instalador (C)||3.1.0||3.2.0||3.3.0||3.4.0||3.5.0||3.6.0||3.8.0 || 3.9.0 || 3.10.0 || 3.11.0  || 3.20 || 3.20
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Intz-gh (VC)|| || || || || ||0.1.0||0.1.1 || 0.1.2 || 0.1.3 || 0.1.4 || 0.1.5  || 0.1.7
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Intz-nimitz (C)||2.6.0||3.0.1||3.0.3||3.4.1||3.4.2||3.4.4||3.5.0 || 3.7.1 || 3.08 || 4.0.0 || 4.0.1  || 4.0.3
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Intz-tap (C)|| || || || || || || || || || || || 0.1.0
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Janus WebRTC Server (VC) || --- || --- || --- || --- || --- || --- || --- || 0.8.0 || 0.8.0 || 0.8.0  || 0.10.10 || 0.10.10
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | LazarusComún (VS)||3.1.0||3.2.0||3.3.0||3.4.0||3.5.0||3.6.0||3.6.1 || 3.6.2 || 3.6.3 || 3.6.4 || ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Mcan (VS) || --- ||---||---||---||---||---||--- || 0.1.5 || 0.1.5 || ---  || ---  || ---
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | MotorPredi (VS)||---||---||---||---||---||---||0.1.1 || 0.1.1 || 0.1.1 || ---- || ----  || ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Motorsal (VS)||1.4.0||3.1.0||3.2.0||3.3.0||3.4.0||3.5.3||3.6.1 || 3.6.1 || 3.6.3 || 3.6.4 || ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Multimonitorweb (VS)||3.0.1||3.0.2||3.1.0||3.1.0||3.2.0||3.2.0||3.4.1 || 3.4.1 || 3.4.3 || 3.4.4 || ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | MyACDSuperv (VS)||5.2.0||5.3.0||5.3.0||5.3.2||5.3.2||5.3.3||6.0.1 || 6.0.3 || 6.0.4 || 6.0.5 || ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Phone_prov (C)||------||------||3.0.1||3.0.3||3.0.3||3.0.3||3.0.4 || 3.0.4 || 3.0.4 || 3.0.4  || 3.0.5 || 3.0.5
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Portal de administración (C)|| 3.1.0 || 3.2.0 || 3.3.0 || 3.4.0 || 3.5.0 || 3.6.0 || 3.8.0 || 3.8.3 || 3.8.5 || 3.8.6 || 4.1.2 || 4.1.3
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Portal usuario (VC) || --- || --- || --- || 3.0.0 || 3.1.0 || 4.0.0 || 4.1.0 || 4.1.0 || 4.1.1 || 4.1.2 || ----  || ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Nuevo portal usuario (VC) || --- || --- || --- || --- || --- || --- || --- || 1.0.0 || 1.0.1 || 1.0.2 || 2.0.10  || 2.3.1
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Portal webfon (VC) || --- || --- || --- || --- || --- || --- || --- || 1.0.0 || 1.0.1 || 1.0.2 || 2.0.10  || 2.3.1
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | FonBo (VC) ||------||------||------||-----||-----||-----||-----|| 1.0.0 || 1.0.1 || 1.0.1 || 1.0.1 || 2.0.5
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Preview (VS)||1.0.18||3.2.0||3.3.0||3.4.0||3.5.0||3.5.0||---||--- ||--- ||--- ||----||----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | recordCentral (C)||-----||-----||-----||4.0.0||4.0.1||4.0.2||4.0.3||4.0.3||4.0.3 ||4.0.4 || 4.0.4 || 4.0.4
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | recordgwd (C)||1.3.0||1.3.0||3.1.0||-----||-----||----||----||---- ||---- ||---- ||----  || ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | recordNodo (C)||-----||-----||-----||4.0.0||4.0.0||4.0.0||4.0.3||4.0.3||4.0.3 ||4.0.3 ||4.0.3
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | recordprocesad (C) ||1.2.0||1.2.0||3.0.0||-----||-----||----||----||---- ||---- ||---- ||----  || ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Sercen (C) || || || || || || |||| || 0.03.01 || 0.03.|| 0.03.05  || 0.4.2
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Supervisor Web (VS)|| || || || || || ||1.0.0||1.0.0 ||1.1.0 ||1.1.1 ||1.2.0  || 2.0.2
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Tracker Web (C) ||3.0.2||3.1.0||3.2.0||3.3.0||3.4.0||3.5.0||3.7.0||3.7.1||3.7.3 ||3.7.8  ||3.8.0  ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Tracker Corporativo (C) || ---- || ---- || ---- || ---- || ---- || ---- || ---- || ---- || ---- || ---- || ---- || 0.1.0
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Tracker windows (C) || 3.0.0 || 3.1.0 || 3.2.0 || 3.3.0 || 3.4.0 || 3.4.0 || ---- || ---- || ---- || ---- || ----  || ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVA designer (VS) || 1.0.23 || 3.0.1 || 3.1.0 || 3.1.0 || 3.2.0 || 3.2.0 || ----|| ---- || ---- || ---- || ----  || ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVA desk (VS) || 3.0.2 || 3.2.0 || 3.3.0 || 3.4.0 || 3.5.0 || 3.5.2 || 3.5.3 || 3.6.1 || 3.6.6 || 3.6.6 || 3.6.6 ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVAit Call Business IOS (VC) ||---||---||---||---||---||---||--- || --- || --- || --- || 2.1.6  || 3.17.3
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVAit Call Business Androit (VC) ||---||---||---||---||---||---||--- || --- || --- || --- || 2.1.6  || 3.0.17
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVAit Call Celullar ||---||---||---||---||---||---||--- || --- || --- || --- ||  || 1.0.1
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVAit Call Cloud (VC) ||---||---||---||---||---||---||--- || --- || --- || --- || ---  || ----
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVA report (VS)||1.2.0||3.1.0||3.2.0||3.2.2||3.3.0||3.4.1||3.5.1||3.5.2||3.5.3 ||3.5.4 ||  ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | VIVA supervisor (VS)||3.0.0||3.1.0||3.2.0||3.3.0||3.4.0||3.6.1||3.8.0||3.8.1 ||3.8.2 ||3.8.3 || ||
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | vivait-cti (VS) || 3.0.0 || 3.0.1 || 3.0.1 || 3.0.1 || 3.0.2 || 3.0.2 || 4.0.1 || 4.0.1 || 4.0.1 || 4.0.1 || 4.0.1 || 4.0.1
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | WebRTC (VC)||-----||-----||-----||-----||-----||-----||-----||0.0.1 ||0.0.6 ||0.0.7 ||0.0.9 || 0.0.10
 +
|-
 +
| style="padding:0.5cm; font-weight:bold;" | Vivait-direc (VC) ||-----||-----||-----||-----||-----||-----||-----|| ----- || ----- || ----- || ----- || 0.0.8
 +
|-
 +
|}
 +
<br><br>
 +
La distribución de los módulos software por tipo de nodo se documentan en los procesos de instalación.<br>
 +
Se puede consultar un ejemplo de un entrorno virualizado en el siguiente enlace [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manuales_de_instalaci%C3%B3n#Tipos_de_m.C3.A1quinas_virtuales  Instalación VIVAit 3.5]
 +
<br><br>
 +
'''(C)''': Módulo común
 +
<br><br>
 +
'''(VC)''': Módulo de VIVAit Call
 +
<br><br>
 +
'''(VS)''': Módulo de VIVAit Suite
 +
<br><br>
 +
'''(*)''' La información sobre las versiones disponibles de Asterisk se puede encontrar en [https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions Versiones de Asterisk ]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Versiones de módulos]][[#Versiones de módulos| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
===== Ejemplo de cluster con mysql y asterisk =====
+
=== Sistema Operativo ===
 
+
<br><br>
En este ejemplo vamos a crear un cluster que maneje mysql y Asterisk como servicios separados.
+
En la plataforma '''''VIVA'''it'' se utiliza el sistema operativo Linux, con dos distribuciones según la versión del proyecto:<br>
 
+
: Hasta la versión 4.0 y para proyectos especiales de '''''VIVA'''it'', se emplea [[#Sistema Operativo Ubuntu| Ubuntu Server LTS]].<br>
Para lograr esto vamos a necesitar que el drbd maneje dos particiones separadas y tener dos ip flotantes, una para cada servicio.
+
: • A partir de la versión 5.0 de '''''VIVA'''it'', se utiliza por defecto [[#Sistema Operativo Debian| Debian LTS]].
 
+
<br><br>
====== Requisitos previos ======
 
 
 
Los requisitos previos antes de comenzar la instalación del cluster son:
 
 
 
Nodos correctamente actualizados (update/upgrade).
 
 
 
• Conexión a internet.
 
 
 
• NTP configurado.
 
 
 
 
 
'''''Creación de las particiones e instalación y configuración del drbd'''''
 
 
 
====== Particionado (En los 2 nodos) ======
 
 
 
Para la instalación de los dos recursos drbd necesitamos tener dos particiones que vamos a crear añadiendo un disco duro en cada una de las máquinas. Lo añadimos mediante el Gestor de Máquinas Virtuales de la máquina 999-sgestion. Los tamaños serán los siguientes:
 
 
 
• Corporativo -> 50Gb
 
 
 
• BDTR -> 100Gb
 
 
 
Lo siguiente es crear la partición en cada servidor:
 
 
 
 
 
[[File:cluster1.png|400px]]
 
 
 
Vamos a utilizar la herramienta parted seguido del dispositivo que queremos particionar. En este caso el espacio que vamos a particionar está en el dispositivo /dev/vdc.
 
 
 
parted /dev/vdc
 
 
 
Una vez ejecutado el comando entraremos en una consola de la aplicación.
 
 
 
Ejecutando el comando
 
 
 
(parted) print free
 
 
 
Obtenemos las particiones que tiene el dispositivo actualmente y el espacio libre que disponemos.
 
 
 
[[File:cluster2.png|400px]]
 
 
 
En este ejemplo disponemos de 50Gb de espacio libre que es el que vamos a utilizar para las 2 particiones necesarias.
 
  
Lanzamos el comando mkpart para realizar la primera partición que será para mysql.
+
==== Sistema Operativo Ubuntu ====
 
+
<br><br>
(parted) mkpart
+
El sistema operativo de la plataforma '''''VIVA'''it'', hasta la versión 4.0, se basa en Ubuntu Server LTS.<br>
 +
Estas versiones cuentan con soporte a largo plazo (LTS), lo que las hace más estables y con actualizaciones controladas desde Ubuntu 14.04.1.<br>
 +
En concreto, el sistema operativo utilizado en'''''VIVA'''it'' es Ubuntu Server 22.04 LTS.<br>
 +
Para más información visitar [https://ubuntu.com/server/docs/ Ubuntu Server].
 +
<br><br>
 +
[[File:sistema_operativo_ubuntu_V5.1.png|1000px|center|thumb]]
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Sistema Operativo]][[#Sistema Operativo| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
El nombre que le vamos a dar a la partición es '''DRBD-MYSQL'''.
+
==== Sistema Operativo Debian ====
El Tipo de sistema de ficheros '''ext4'''.
+
<br><br>
Luego nos pedirá el principio de la partición, en el ejemplo vamos a comenzar en 198Gb y vamos a finalizar en 550Gb.
+
El sistema operativo de la plataforma '''''VIVA'''it'', desde la versión 4.0, se basa en Debain LTS.<br>
 
+
En concreto, el sistema operativo utilizado en '''''VIVA'''it'' es la versión número Debian 13, de nombre Trixie con soporte a largo plazo LTS.<br>
 
+
Estas versiones cuentan con soporte a largo plazo (LTS), lo que las hace más estables y con actualizaciones controladas.<br>
[[File:cluster3.png|400px]]
+
Para más información [https://www.debian.org/releases/trixie/index.es.html Debian “trixie”].
 
+
<br><br>
Realizaremos la segunda partición volviendo a ejecutar el mismo comando
+
[[File:sistema_operativo_debian_V5.1.png|1000px|center|thumb]]
 
+
<br><br>
(parted) mkpart
+
<div style="
 
+
  text-align:right;
 
+
  margin-top:20px;
En este ejemplo el nombre para esta partición será '''DRBD-ASTER''' el tipo '''ext4''' y le daremos el espacio restante del disco.
+
  padding:8px;
 
+
  border:1px solid #ccc;
[[File:cluster4.png|400px]]
+
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Sistema Operativo]][[#Sistema Operativo| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
=== Matriz de conmutación ===
 +
<br><br>
 +
La matriz de conmutación en la plataforma '''''VIVA'''it'' se plantea con tres núcleos de conmutación diferentes:<br>
 +
: * '''Nodos ACD''': el núcleo de conmutación es Asterisk 1.4 RSP <br>
 +
: * '''Nodos corporativo Cisco''': el núcleo de conmutación es Asterisk 18 versión certified <br>
 +
: * '''Nodos corporativos / GW''': el núcleo de conmutación es Asterisk 18 versión certified <br>
 +
Sobre este núcleo constituido por Asterisk LTS se realizan las modificaciones necesarias para implementar la plataforma '''''VIVA'''it'' conformando Asterisk '''MDT'''el.<br>
 +
Para información de las diferentes versiones de Asterisk LTS visitar [https://docs.asterisk.org/About-the-Project/Asterisk-Versions/ |Versiones de Asterisk].
  
Para ver el resultado de las particiones podemos ejecutar el comando.
+
Asterisk MDTEL
  
lsblk
+
Dialplan VIVAit
  
[[File:cluster5.png|400px]]
 
  
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
+
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Matriz de conmutación]][[#Matriz de conmutación | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
==== Asterisk '''''MDT'''el'' ====
 +
<br><br>
 +
Sobre el software Asterisk LTS instalado se realizan modificaciones para implementar las funcionalidades de conmutación de '''''VIVA'''it''.<br>
 +
Estas modificaciones se llevan a cabo mediante dos acciones complementarias, dando lugar al Asterisk '''MDT'''el.
 +
<br><br>
 +
: * [[#Archivos añadidos por MDtel | Archivos añadidos]]
 +
: * [[#Archivos modificados por MDTel | Archivos modificados]]
 +
<br><br>
  
====== Gestión de particiones con LVM (En los 2 nodos) ======
+
===== Archivos añadidos por '''MD'''tel =====
 +
<br><br>
 +
Los archivos añadidos son los siguientes:
  
 +
* '''apps/app_ucid.c'''
 +
* '''apps/app_cli.c'''
 +
* '''apps/app_crash.c'''
 +
* '''apps/app_mdintz.c'''
 +
* '''apps/app_mdintz.exports.in'''
 +
* '''include/asterisk/mdintz.h'''
 +
* '''include/asterisk/ucid.h'''
 +
* '''res/res_mdcal.c'''
  
Crearemos las 2 particiones lvm en los 2 servidores con los siguientes comandos.
 
  
En este ejemplo las particiones que queremos utilizar son /dev/sda5 para mysql y /dev/sda6 para Asterisk, esto podrá cambiar en las instalaciones.
+
apps/app_ucid.c
 +
apps/app_cli.c
 +
apps/app_crash.c
 +
apps/app_crash.exports.in
 +
apps/app_mdintz.c
 +
apps/app_mdintz.exports.in
 +
include/asterisk/mdintz.h
 +
include/asterisk/ucid.h
 +
include/asterisk/mdcrash.h
 +
res/res_mdcal.c
 +
configs/samples/MDcrash.conf
 +
include/asterisk/mdgh.h
 +
res/res_mdgh.exports.in
 +
res/res_mdgh.c
 +
channels/chan_mdtap.c
 +
apps/pqcti
 +
apps/app_md_pqcti.c
  
[[File:cluster6.png|400px]]
 
  
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
 
  
 +
'''→ apps/app_mdintz.exports.in '''
  
====== Instalación y configuración del drbd (En los 2 nodos) ======
+
Este archivo sirve para la exportación de funciones del mdintz para el uso por aplicaciones externas
  
Instalaremos el paquete drbd8-utils. En Ubuntu 20.04 drbd-utils
+
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Matriz de conmutación]][[#Matriz de conmutación | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
apt-get install drbd-utils
+
===== Archivos modificados por '''''MDT'''el'' =====
 +
<br><br>
 +
Los archivos modificados por '''MD'''tel son los mostrados a continuación:
  
Ahora tenemos que editar los archivos de configuración del drbd, estos archivos están en el directorio /etc/drbd.d
+
* '''apps/app_mixmonitor.c'''
 +
* '''res/res_calendar_caldav.c'''
 +
* '''contrib/scripts/safe_asterisk'''
 +
* '''contrib/init.d/rc.debian.asterisk'''
 +
* '''channels/sig_pri.c'''
 +
* '''channels/chan_sip.c'''
  
Primero editaremos la configuración general, el archivo global_common.conf y le añadiremos en la sección net lo siguiente.
 
  
vi /etc/drbd.d/global_common.conf
+
'''→ main/audiohook.c''' <!--style="color:#0000ff" -->
 +
 
 +
'''audiohook.c''' ha sido modificado para solucionar un crash de asterisk al utilizar en el mixmonitor las opciónes r y t
  
[[File:cluster7.png|400px]]
 
  
Si tenemos problemas con los backup que realiza Vodafone en las máquinas virtuales añadir:
 
  
  net {
+
'''→ app_crash.c '''
                # protocol timeout max-epoch-size max-buffers
 
                # connect-int ping-int sndbuf-size rcvbuf-size ko-count
 
                # allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
 
                # after-sb-1pri after-sb-2pri always-asbp rr-conflict
 
                # ping-timeout data-integrity-alg tcp-cork on-congestion
 
                # congestion-fill congestion-extents csums-alg verify-alg
 
                # use-rle
 
                protocol C;
 
                after-sb-0pri discard-zero-changes;
 
                after-sb-1pri discard-secondary;
 
                after-sb-2pri disconnect;
 
        }
 
  
Ó (nota Centro de Servicios)
+
Esta nueva aplicación es sólo compatible con '''Asterisk 13'''.
  
net {
+
La documentación de la misma se encuentra en el comando: '''"core show application Crash"'''
    ping-int 30;
 
    timeout 20;
 
    connect-int 30;
 
    protocol C;
 
    after-sb-0pri discard-older-primary;
 
    after-sb-1pri discard-secondary;
 
    after-sb-2pri disconnect;
 
}
 
  
 +
Esta nueva aplicación ''permite añadir'' al plan de pruebas:
  
Para configurar los recursos tenemos que crear en el directorio /etc/drbd.d un archivo para cada recurso. Estos archivos deben tener la extensión res.
+
* Generación de una parada de asterisk. (Crash(IwantToGetAnAccessViolation) ó Crash(IwantToGetADoubleFreeMem))
 +
* Verificación de su impacto. Por ejemplo, no deben cortarse las llamadas en curso, si así está previsto por la topología.
 +
* Correcta generación de los "core", comprobando que funciona "backtrace" (bt).
  
Creamos el archivo para el recurso mysql con el nombre drbd-mysql.res.
+
'''Nota.-''' Esta aplicación no debería estar presente en una instalación de '''Asterisk 13'''
  
vi drbd-mysql.res
 
  
El contenido del archivo es:
+
'''→ app_mdintz.c y mdintz.h''' <!--style="color:#0000ff" -->
  
resource drbdMYSQL {
+
Esta aplicación sirve como interfaz a entornos (funcionalidades) creados por MDtel
  on VC-CORP-Cetelem-Mad-cl1 {
 
    device /dev/drbd0;
 
    disk /dev/mapper/vg_DRBD--MYSQL-lv_DRBD--MYSQL;
 
    address 10.10.10.10:7788;
 
    meta-disk internal;
 
  }
 
  on VC-CORP-Cetelem-Mad-cl2 {
 
    device /dev/drbd0;
 
    disk /dev/mapper/vg_DRBD--MYSQL-lv_DRBD--MYSQL;
 
    address 10.10.10.11:7788;
 
    meta-disk internal;
 
  }
 
}
 
  
 +
Para mas información consultar la página de [[MDintz|MDintz]].
  
Ahora haremos lo mismo para el recurso Asterisk, el archivo se llamará: drbd-aster.res.
+
Las rutas de estos archivos son las siguientes:
  
vi drbd-aster.res
+
'''apps/app_mdintz.c''' <br/>
 +
'''include/asterisk/mdintz.h '''
  
 +
'''app_mdintz.c''' :
  
y el contenido será el siguiente:
+
'''app_mdintz.c''' orientada al proceso de enrutamiento a implementar en ''intz-nimitz.''
  
resource drbdASTER {
+
El archivo '''.c''' es casi igual para asterisk 1.4.24 y asterisk 13.  
  on VC-CORP-Cetelem-Mad-cl1 {
+
'''Nota.-''' Cuando se compila para asterisk 13, es necesario comentar la línea que pone<br /> '''"#define ASTERISK_OLD".'''
    device /dev/drbd1;
 
    disk /dev/mapper/vg_DRBD--ASTER-lv_DRBD--ASTER;
 
    address 10.10.10.10:7789;
 
    meta-disk internal;
 
  }
 
  on VC-CORP-Cetelem-Mad-cl2 {
 
    device /dev/drbd1;
 
    disk /dev/mapper/vg_DRBD--ASTER-lv_DRBD--ASTER;
 
    address 10.10.10.11:7789;
 
    meta-disk internal;
 
  }
 
}
 
  
'''Realizamos este mismo proceso en el otro nodo del cluster.''' Los ficheros de configuración los podemos copiar de un nodo a otro.
+
Los cambios implementados son:
  
 +
* Unificación de código entre las versiones de asterisk
 +
* Nuevo comando "qry"
 +
* Posible resolución de "Mal write" en intz-nimitz (a verificar)
  
====== Configuración de /etc/hosts (En los 2 nodos) ======
+
En cuanto al nuevo comando, el formato es:
  
Tenemos que configurar correctamente los nombres de las máquinas en el archivo /etc/hosts.
+
'''mdintz qry <nHostFijo> <entorno> <servicio> <par1>...<parN>'''
  
vi /etc/hosts
 
  
El contenido de este archivo variará según la configuración, para este ejemplo.
+
Permite interrogar a un servidor de igual modo que hace el dialplan con '''fines de diagnóstico'''. La única diferencia es que se ha añadido el parámetro '''"nHostFijo"''' que puede tomar como valor '''"*"''' (lo que solicita una interrogación secuencial a todos los servidores definidos, igual a la funcionalidad del dialplan) ó '''"0"''' a '''"3"''' (que solicita un interrogación dirigida el host indicado como hostN, y sólo a él, en archivo de configuración).
  
[[File:cluster8.png|400px]]
 
  
:{|
+
Para instalarlo, es necesario copiar:
|
 
127.0.0.1 localhost
 
#127.0.1.1 VC-CORP-mdtelMad-cl1
 
  
128.1.4.201 VC-CORP-mdtel-Mad-cl1
+
* '''asterisk/apps/app_mdintz.c'''
128.1.4.202  VC-CORP-mdtel-Mad-cl2
+
* '''asterisk/include/asterisk/mdintz.h'''
 +
* En asterisk 1.4.24 conviene asegurar que se ha actualizado '''"asterisk/apps/app_queue.o"''' y '''"asterisk/apps/app_queue.so"'''
 +
* Luego '''"make", "make install"''' y module '''"unload/load"''' (mejor "stop now" y start)
  
10.10.10.10 nodo-vc-01
+
'''→ scripts y rc.debian.asterisk'''
10.10.10.11    nodo-vc-02
 
  
 +
cambiado contrib/scripts por el modificado por MDtel<br />
 +
cambiado contrib/init.d/rc.debian.asterisk por el modificado por MDtel
  
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
 
  
 +
'''→ Carpeta mp3 añadida al directorio addons'''
  
====== Creación de los recursos en drbd. (En los 2 nodos) ======
+
La carpeta mp3 en addons permite la reproducción desde el diaplan de los mensajes en mp3. En make menuselect hay que marcar el format_mp3 y app_mp3 e instalar el paquete mpg123 de ubuntu
  
Ahora crearemos los recursos en drbd, primero el de mysql
+
'''→ sig_pri.c'''
  
drbdadm create-md drbdMYSQL
+
Modificado para enviar/recibir el ucid en un primario qsig
  
Y después el de Asterisk
+
Para que se envie el ucis tenemos que habilitar el envio de facilidades en el chan_dahdi.conf
  
drbdadm create-md drbdASTER
+
facilityenable = yes
  
Y arrancamos el drbd en el nodo.
 
  
/etc/init.d/drbd start
+
'''→ init.d''' <!--style="color:#0000ff" -->
  
Crearemos las carpetas donde se montarán los recursos del drbd
+
* Uno de los archivos modificados ha sido '''init.d''', se encuentra en la ruta: '''/etc/init.d/asterisk'''. La modificación realizada es la siguiente:
  
mkdir HDmysql
+
{|style="background-color:#ffffcc;" class="wikitable"
 
+
|-
touch /HDmysql/sinMontar
+
|-
 
+
| SAFE_ASTEISK=/usr/sbin/safe_asterisk <br/>
mkdir HDaster
+
if [ -x $SAFE_ASTERISK ] ; then<br/>
touch /HDaster/sinMontar
+
:# //!! wkw<br/>
 +
:DAEMON=$SAFE_ASTERISK<br/>
 +
fi
 +
|}
  
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
 
  
====== Sincronización del drbd. (En 1 nodo) ======
+
<!--archivo-->
  
Este proceso solo se debe realizar en un nodo, Con este comando sincronizaremos los 2 discos y el nodo desde donde lo lancemos será el que aporte los datos en la sincronización. Como no hay nada en los discos todavía es igual desde que nodo se ejecute.
+
'''→ safe-asterisk'''
 +
* Se encuentra en la siguiente ruta:'''/usr/sbin/safe-asterisk''' .En este archivo se ha modificado MAXFILES=32768
  
drbdadm -- --overwrite-data-of-peer primary all
+
'''→ default'''
  
 +
* Este fichero podemos encontrarlo en: '''/etc/default/asterisk'''. La finalidad de la modificación de este fichero es poder correr como usuario Asterisk, grupo asterisk y generar cores (descomentar línea)
 +
Las modificaciones realizadas han sido:
  
Podemos ir viendo cual es el porcentaje que lleva realizado con el siguiente comando.
+
{|style="background-color:#ffffcc;" class="wikitable"
 +
|-
 +
|-
 +
| AST_USER="asterisk"
 +
AST_GROUP="asterisk"
  
watch -n 1 'cat /proc/drbd'
+
COREDUMP=yes
 +
|}
  
Al final de la sincronización debería salir algo como esto.
+
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Matriz de conmutación]][[#Matriz de conmutación | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
[[File:cluster9.png|400px]]
+
===== Nueva función de asterisk: app_cli.so =====
  
 +
Esta función permite ejecutar desde el '''dialplan''' un comando de línea de consola de '''asterisk (CLI).''' Su primer uso (y esperamos que no último) será para lanzar los '''notify''' que los teléfonos necesitan para el ''reaprovisionamiento'' desde el portal o desde la facilidad de movilidad de usuario.
  
 +
Básicamente ejecuta un comando y devuelve su salida. Utiliza un archivo intermedio que puede ser:
  
===== Pacemaker, corosync y pcs =====
+
* '''/dev/null''' si el campo se deja vacío, por tanto, no se puede recuperar la salida.
 +
* '''TEMP''', en cuyo caso se crea un archivo temporal que se borra antes de finalizar la ejecución de la función.
 +
* Un nombre de fichero que es responsabilidad del dialplan el borrarlo cuando proceda.
  
  
Ahora deberíamos tener en los 2 nodos un mysql configurado y corriendo, un Asterisk configurado y corriendo y 2 particiones de drbd (una para mysql y otra para Asterisk) sincronizadas, aunque no están montadas en ningún sitio.
+
Para instalarlo basta copiar '''apps/app_cli.c''' en el directorio ''' "apps" ''' de los fuentes y luego  ejecutar '''"make" y "make install".'''
  
 +
A continuación se pasa el resultado de '''"core show function CLI" '''
  
====== Parar y deshabilitar los servicios. (en los 2 nodos) ======
+
'''[Synopsis]'''
  
Todos los servicios que vayan a ser controlados por el pacemaker tienen que estar parados y el arranque deshabilitado para que el pacemaker los arranque y los pare en el nodo que corresponda.
+
Lanza un comando CLI desde dialplan
  
/etc/init.d/asterisk stop
+
'''[Description]''' <br />
  /etc/init.d/mysql stop
+
  - CLI(nomArchSal,cmd)<br />
  /etc/init.d/drbd stop
+
  - Si 'nomArchSal' está vacio, se usa '/dev/null' y no se recupera resultado<br />
  systemctl disable mysql
+
  - Si 'nomArchSal'=TEMP, Se crea un archivo temporal que se borra al final<br />
systemctl disable drbd
+
  - En otro caso, se crea el archivo y no se borra
  systemctl disable asterisk
 
  
 +
'''[Syntax]'''<br />
 +
CLI(nomArchSal,cmd)
  
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
+
'''[Arguments]'''<br />
 +
'''nomArchSal'''
 +
    Archivo de salida (si se omite, /dev/null)
 +
'''cmd'''
 +
    Comando a ejecutar via CLI
  
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Matriz de conmutación]][[#Matriz de conmutación | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
====== Instalación de los paquetes necesarios. (En los 2 nodos) ======
+
==== Dialplan  '''''VIVA'''it'' ====
  
Instalamos los paquetes necesarios.
+
El Dialplan podría considerarse la columna vertebral del sistema ''Asterisk''.
  
apt install corosync pacemaker pcs
+
Es una colección ordenada de acciones que se llevan a cabo cuando un usuario marca una serie de números. Hace la función de una tabla de enrutamiento de llamadas.
  
 +
Todas las configuraciones generales de Asterisk están accesibles en la ruta '''/etc/asterisk'''
  
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
+
'''CONCEPTOS BÁSICOS'''
  
 +
♦ '''EXTENSIONES'''
  
====== Configuramos la clave del usuario hacluster. (En los 2 nodos) ======
+
Una extensión es una marcación en el teclado de un teléfono. Dicha configuración podemos encontrarla en el archivo '''extensions.conf'''
  
Al instalar los paquetes se crea un usuario hacluster que tenemos que ponerle clave
+
Por ejemplo, un usuario podría marcar “3001” en su teléfono, y eso sería una extensión. También podría marcar un número de teléfono nacional, como por ejemplo “915881000”, y también sería una extensión.
  
passwd hacluster
+
En Asterisk pueden definirse también extensiones como texto, por tanto no debemos relacionar las extensiones únicamente con números.
  
La clave deberá ser la misma en los 2 nodos. '''ivivacluster'''
+
Algunas reglas que sería interesante conocer serían las siguientes:
  
 +
{| class="wikitable"
 +
|-
 +
! '''Regla''' !! '''Descripción'''
 +
|-
 +
| '''X''' || Cualquier cifra de 0 a 9
 +
|-
 +
|'''Z'''||Cualquier cifra de 1 a 9
 +
|-
 +
|'''N'''||Cualquier cifra de 2 a 9
 +
|-
 +
|'''[x-y]'''||Cualquier cifra de "x" a "y"
 +
|-
 +
|'''[xyz]'''|| Las cifras "x", "y" o "z"
 +
|-
 +
|'''.'''||Una o más repeticiones del símbolo anterior
 +
|-
 +
|'''!'''||Cero o más repeticiones del símbolo anterior
 +
|}
  
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
+
Estas reglas son necesarias a la hora de definir por ejemplo todos los números de teléfono posibles en España
  
 +
♦ '''PRIORIDADES'''
  
====== Autentificación del pcs. (En 1 nodo) ======
+
En lenguaje scripting, las acciones se van ejecutando de arriba a abajo en orden. En cambio, en Asterisk, el orden en el que se ejecutan las acciones es el indicado mediante números.
 +
Primero se ejecutará la acción 1, luego la 2...así sucesivamente.
  
En uno de los nodos ejecutamos el siguiente comando para autenticar el pcs.
+
Es decir no basta con definir las acciones que se llevarán a cabo, también debemos indicar el orden en el que se llevarán a cabo.
  
pcs host auth nodo-vc-01 nodo-vc-02 -u hacluster -p ivivacluster
+
♦ '''CONTEXTOS'''
  
El resultado del comando tiene que ser:
+
Es mecanismo que nos permite variar el comportamiento del sistema en función del número que se marque. Su misión es aumentar la seguridad del sistema ofreciendo servicios diferenciados en función del usuario.
  
<span style="color:#007bca">VC-CORP-Cetelem-Mad-cl1: Authorized
+
La sintaxis típica es el nombre del contexto englobado entre corchetes [nombre_contexto]. Si un dispositivo no tiene un contexto definido se redirige directamente al contexto por defecto.
VC-CORP-Cetelem-Mad-cl2: Authorized</span>
 
  
====== Creación y configuración del cluster. (En 1 nodo) ======
 
  
Ahora creamos el cluster e incluimos las maquinas que lo van a componer y le asignamos un nombre (este nombre no puede exceder de 15 caracteres).
 
  
pcs cluster destroy (en caso de no encontrar /var/lib/pcsd/known-hosts y después lanzar pcs host auth noco-vc-01 nodo-vc-02  -h hacluster -p ivivacluster)
+
Los ficheros que conforman el Dialplan se clasifican en:
  
pcs cluster setup CLmutuaint  nodo-vc-01 nodo-vc-02 --start --enable --force
+
* '''Generales'''
 +
* '''Particulares'''
 +
* '''Web'''
  
Si todo ha ido bien la salida debería ser algo como esto.
+
{| class="wikitable"
 +
|-
 +
! '''Fichero''' !! '''Función'''
 +
|-
 +
| '''Generales''' || Se encuentran los ficheros de propios de MDtel y Asterisk. Es importante remarcar que estos ficheros NO pueden ser modificados por el usuario.
 +
|-
 +
|'''Particular'''||Estos ficheros son los únicos que puede modificar el usuario
 +
|-
 +
|'''Web'''|| Se encierran aquí los archivos generados automáticamente por la plataforma, a través del portal
 +
|}
  
[[File:cluster10.png|500px]]
+
En función del nodo en el que estemos trabajando, encontraremos dos tipos de dialplan:
  
Lo habilitamos '''''en todos los nodos'''''
+
'''* Dialplan ACD''' --> Dialplan que aplica a nodos ACD
  
pcs cluster enable --all
+
'''* Dialplan corporativa''' --> Dialplan que aplica a nodos de corporativa o gateways (ya sean de corporativa o ACD)
  
La salida será:
+
A continuación se muestran las tablas con los ficheros correspondientes a cada Dialplan.
  
<span style="color:#007bca">VC-CORP-CDS-MAD-01: Cluster Enabled
+
{| border="1" align="center" bgcolor="FloralWhite"
  VC-CORP-CDS-MAD-02: Cluster Enabled</span>
+
|+ '''Ficheros de configuración Dialplan Corporativo'''
 +
| '''GENERALES'''
 +
| '''PARTICULARES'''
 +
| '''WEB'''
 +
|-
 +
| ext_Grabaciones.conf <br />ext_InicioLlamada.conf <br /> ext_InicioLlamada_Dahdi.conf <br />ext_InicioLlamada_ExtSIP.conf <br/>ext_InicioLlamada_TrunkSIP.conf <br />ext_MARCAR_ColaCentralita.conf <br /> ext_MARCAR_ColaCentralita_Dial.conf<br /> ext_MARCAR_Cola.conf <br />ext_MARCAR_Cola_Dial.conf<br />ext_MARCAR.conf <br /> ext_MARCAR_DejarMensaje.conf <br /> ext_MARCAR_DejarMensaje_Dial.conf <br />ext_MARCAR_Extension.conf<br />ext_MARCAR_Extension_Dial.conf <br />ext_MARCAR_Externo.conf <br />ext_MARCAR_Externo_Dial.conf <br />ext_MARCAR_Facilidad.conf <br />ext_MARCAR_Facilidad_Dial.conf <br />ext_MARCAR_Facilidad_nimitz.conf<br />ext_MARCAR_Interno.conf <br />ext_MARCAR_LeerMensaje.conf <br />ext_MARCAR_LeerMensaje_Dial.conf<br />ext_MARCAR_Nodo.conf<br />ext_MARCAR_Nodo_Dial.conf <br />ext_MARCAR_SalasConf.conf <br />ext_MARCAR_SalasConf_Dial.conf <br />ext_MARCAR_Servicios.conf <br />ext_MARCAR_VDN.conf <br />MARCAR_VDN_Dial.conf<br />ext_MDtel.conf <br />ext_MDtel_Var.conf <br />ext_Subrutinas_AnchoBanda.conf <br />ext_Subrutinas_BD.conf <br />ext_Subrutinas_BD_Facilidad.conf <br />ext_Subrutinas_BD_Facilidad.conf <br /> ext_Subrutinas_Colas.conf <br />ext_Subrutinas.conf <br />ext_Subrutinas_Enrutamiento.conf <br />ext_Subrutinas_finLlamada.conf<br />ext_Subrutinas_Grabacion.conf<br />ext_Subrutinas_nimitz.conf<br />ext_Subrutinas_Varias.conf<br />ext_Subscribe.conf<br />ext_Transfer.conf <br />ext_Transfer_ExtSIP.conf<br />ext_Transfer_TrunkInternos.conf <br />ext_TrunkInternos.conf<br />ext_TrunkInternos_Dial.conf <br />sip_Estatico.conf<br /> sip_GENCUST.conf <br />sip_notify.conf <br />queues.conf <br /> queues_GENERAL.conf <br />queues_PLANTILLACOLAS.conf<br />
  
Arrancamos el cluster '''en todos los nodos'''
+
| ext_Enrutador_Particular.conf<br /> ext_InicioLlamada_Dahdi_Particular.conf<br />ext_InicioLlamada_ExtSIP_Particular.conf<br />ext_InicioLlamada_Particular.conf <br />ext_InicioLlamada_TrunkSIP_Particular.conf<br />ext_MARCAR_Extension_Particular.conf <br />ext_MARCAR_Externo_Particular.conf <br/> ext_MARCAR_Facilidad_Particular.conf<br /> ext_MARCAR_VDN_Particular.conf <br />ext_MDtel_Particular.conf <br/> ext_TrunkInternos_Particular.conf <br/>
  
pcs cluster start --all
+
|asterisk_WEB.conf <br /> ext_MDtel_WEB.conf <br /> sip_trunkExt_WEB.conf <br />sip_trunkInt_WEB.conf <br />sip_trunk_WEB.conf <br /> sip_WEB.conf <br /> queues_WEB.conf
 +
|}
  
  
[[File:cluster11.png|500px]]
+
{| border="1" align="center" bgcolor="FloralWhite"
 +
|+ '''Ficheros de configuración Dialplan ACD'''
 +
| '''GENERALES'''
 +
| '''PARTICULARES'''
 +
| '''WEB'''
 +
|-
 +
| ext_Enrutador.conf<br />ext_Grabaciones.conf <br /> ext_InicioLlamada.conf <br /> ext_InicioLlamada_CTI.conf <br />ext_InicioLlamada_Dahdi.conf <br />ext_InicioLlamada_ExtSIP.conf <br />ext_InicioLlamada_Marcador.conf <br />ext_InicioLlamada_TrunkSIP.conf <br />ext_MARCAR_ColaCentralita.conf <br />ext_MARCAR_ColaCentralita_Dial.conf<br />ext_MARCAR_Cola.conf <br />ext_MARCAR_Cola_Dial.conf <br />ext_MARCAR.conf <br />ext_MARCAR_DejarMensaje.conf <br />ext_MARCAR_DejarMensaje_Dial.conf <br />ext_MARCAR_Extension.conf <br />ext_MARCAR_Extension_Dial.conf <br />ext_MARCAR_Externo.conf <br />ext_MARCAR_Externo_Dial.conf <br />ext_MARCAR_Facilidad.conf <br />ext_MARCAR_Facilidad_Dial.conf <br />ext_MARCAR_Facilidad_nimitz.conf<br />ext_MARCAR_LeerMensaje.conf <br />ext_MARCAR_LeerMensaje_Dial.conf <br />ext_MARCAR_Nodo.conf <br />ext_MARCAR_Nodo_Dial.conf <br />ext_MARCAR_SalasConf.conf <br />ext_MARCAR_SalasConf_Dial.conf<br />ext_MARCAR_Servicios.conf <br />ext_MARCAR_VDN.conf <br />ext_MARCAR_VDN_Dial.conf<br />ext_MDtel.conf <br />ext_MDtel_Var.conf <br />ext_Subrutinas_AnchoBanda.conf <br />ext_Subrutinas_BD.conf <br />ext_Subrutinas_BD_Facilidad.conf <br /> ext_Subrutinas_Colas.conf <br />ext_Subrutinas.conf <br />ext_Subrutinas_Enrutamiento.conf <br /> ext_Subrutinas_finLlamada.conf<br />ext_Subrutinas_Grabacion.conf <br />ext_Subrutinas_nimitz.conf<br />ext_Subrutinas_Varias.conf <br />ext_Subscribe.conf<br />ext_Transfer.conf <br />ext_Transfer_ExtSIP.conf<br />ext_Transfer_TrunkInternos.conf <br />ext_TrunkInternos.conf <br />ext_TrunkInternos_Dial.conf <br />queues_GENERAL.conf<br />queues_PLANTILLACOLAS.conf <br />sip_GENCUST.conf <br />sip_GENERAL.conf <br />sip_notify.conf <br />sip_PLANTILLAEXT.conf<br />sip_supervision.conf <br />
  
Comprobamos que todo está correcto con el siguiente comando:
 
  
Nos mostrara el estado del cluster.
 
  
[[File:cluster12.png|700px]]
+
| ext_Enrutador_Particular.conf <br />ext_InicioLlamada_CTI_Particular.conf<br />ext_InicioLlamada_Dahdi_Particular.conf<br />ext_InicioLlamada_ExtSIP_Particular.conf<br />ext_InicioLlamada_Marcador_Particular.conf <br />ext_InicioLlamada_Particular.conf.<br />ext_InicioLlamada_TrunkSIP_Particular.conf<br />ext_MARCAR_Externo_Particular.conf<br />ext_MARCAR_Facilidad_Particular.conf<br />ext_MARCAR_VDN_Particular.conf<br /> ext_MDtel_Particular.conf<br />ext_TrunkInternos_Particular.conf<br />
  
 +
|asterisk_WEB.conf <br /> ext_MDtel_WEB.conf <br />queues_WEB.conf<br /> sip_trunkInt_WEB.conf <br />sip_WEB.conf <br />
 +
|}
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Matriz de conmutación]][[#Matriz de conmutación | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
En la salida del comando, vemos que STONITH (Shoot The Other Node In The Head) esta activado, pero no hay dispositivos configurados.
+
=== Bases de datos (BBDD)===
 
+
<br><br>
Quitamos el STONITH.
 
 
 
pcs property set stonith-enabled=false --force
 
 
 
 
 
También deshabilitaremos la política de quorum. Un cluster tiene quorum cuando más de la mitad de los nodos están online. Pacemaker por defecto para todos los servicios si no hay quorum, esto no tiene mucho sentido en un cluster de 2 nodos.
 
 
 
pcs property set no-quorum-policy=ignore --force
 
 
 
 
 
Vamos a ver la lista de propiedades del cluster para ver que hemos deshabilitado todo correctamente.
 
 
 
pcs property list
 
 
 
  
[[File:cluster13.png|500px]]
 
  
 +
[[Archivo:Icono en construccion.png|600px|miniaturadeimagen|center|marco|En construcción]]
  
 +
<br><br>
 +
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: [[Base de datos|Información completa de la BD]]. Podéis ampliar más información en https://dev.mysql.com/doc/
  
====== Creación de las IP flotantes (En 1 nodo) ======
 
  
Ahora vamos a crear las 2 direcciones ip flotantes para que la conexión se realice a la maquina correcta en cada caso, esta ip balanceara entre los diferentes nodos para dar acceso a los servicios en el nodo en el que estén activos.
+
==== 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 '''''VIVA'''''it Supervisor
  
Creamos la IP para el mysql.
+
De la base de datos de tiempo real leen los procesos que requieren información, y las aplicaciones:
 +
*'''''VIVA'''''it Supervisor (para reporting de tiempo real)
 +
*PanelWeb
 +
*Datos de sesión de '''''VIVA'''''it Desk
 +
*Monitorización Zabbix
 +
* Otros
  
pcs resource create IP-MYSQL ocf:heartbeat:IPaddr2 ip=128.1.4.205 nic=eno1:0 cidr_netmask=16 op monitor interval=60s
+
El portal de administración se encarga de escribir las configuraciones añadidas o modificadas en la base de datos
  
Y la IP para el Asterisk
+
Para cuando la BDTR contienen un número masivo de datos, existe un script que borra el contenido de ciertas tablas de la BD (tablas DAT_) dejando solamente datos de un cierto número de días configurable.
 +
Este script se llama borraRegistrosNimitz.pl; para más información consultar el apartado de Howto's.
  
pcs resource create IP-ASTER ocf:heartbeat:IPaddr2 ip=128.1.4.207 nic=eno1:1 cidr_netmask=16 op monitor interval=60s
+
'''Por defecto, a partir de la versión 3.2.0 de la plataforma, los registros se mantedrán 2 meses.'''
  
Comprobamos el estado del cluster.
+
==== 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
pcs status
 
  
Nos mostrará los nuevos recursos creados y nos indicará en que nodo han sido arrancados.
+
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
  
[[File:cluster14.png|600px]]
+
Algunos procesos que utilizan la base de datos de réplica son:
 +
*'''''VIVA'''''it Reporting
 +
*'''''VIVA'''''it Tracker
 +
*Histórico en tiempo real de '''''VIVA'''''it Supervisor
  
  
 +
'''IMPORTANTE: Ningún proceso, programa, aplicación, etc. escribe en la base de datos de réplica; tan solo se extrae información'''
  
====== Configuración del drdb. (En 1 nodo) ======
+
==== 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.
  
 +
===== Backup y restore =====
  
La configuración de DRBD en Pacemaker implica que creemos varios recursos que se ejecutaran a la vez, para ello, utilizaremos una opción de pcs que nos permite encolar varios comandos y ejecutarlos al mismo tiempo. Estos comandos serán ejecutados únicamente en un nodo.
+
Se utilizan dos script, para realizar la copia de seguridad y restaurar en la base de datos de copia local que son:
  
Primero ejecutaremos los comandos necesarios para la creación del drbd para mysql.
+
* 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.
  
pcs cluster cib drbd_mysql_cfg
+
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".
pcs -f drbd_mysql_cfg resource create DRBDmysql ocf:linbit:drbd drbd_resource=drbdMYSQL op monitor interval=60s
 
pcs -f drbd_mysql_cfg resource master DRBDmysqlClone DRBDmysql master-max=1 master-node-max=1 clone-max=2 clone-node-max=1  notify=true
 
pcs -f drbd_mysql_cfg resource promotable DRBDmysql promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1  notify=true
 
pcs cluster cib-push drbd_mysql_cfg
 
  
Y lo mismo para el drbd de asterisk.
+
==== Diagnósticos y operaciones sobre bases de datos ====
  
pcs cluster cib drbd_aster_cfg
+
=====Comprobación que una base de datos está arrancada=====
pcs -f drbd_aster_cfg resource create DRBDaster ocf:linbit:drbd drbd_resource=drbdASTER op monitor interval=60s
+
Para comprobar si la base de datos está arrancada debemos poner en el terminal : '''ps aux | grep mysql'''
pcs -f drbd_aster_cfg resource promotable DRBDaster promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1  notify=true
 
pcs cluster cib-push drbd_aster_cfg
 
pcs cluster cib drbd_aster_cfg
 
pcs cluster cib-push drbd_aster_cfg
 
  
 +
Si la base de datos está arrancada y funcionando correctamente se nos mostrará en el terminal:
 +
[[Archivo:Base_Datos_bien.png‎ |500px|center]]
  
Miraremos el estado del cluster
+
Por el contrario, si la base de datos presenta algun problema el mensaje mostrado será:
  
pcs status
+
[[Archivo:Base_datos_mal.png |center]]
  
El resultado debería de mostrar que los recursos del drbd están creado y cuál es el nodo primario (master) y cuál es el nodo secundario (slave) para ambos recursos.
+
=====Comprobación que la base de datos de réplica está sincronizada con la base de datos de tiempo real.=====
  
[[File:cluster15.png|700px]]
+
Si se necesita verificar que la base de réplica está sincronizada con la base de datos en tiempo real basta con acudir al comando : '''show slave status\G'''.
  
 +
Una vez introducido veremos:
  
====== Montar las particiones del drbd. (En 1 nodo) ======
+
[[Archivo:Replica.png |980px|center]]
  
Formatearemos las particiones del drbd.
+
Comandos importantes, desde dentro consola de Mysql:
  
  mkfs.ext4 /dev/drbd1
+
  '''show master status''': Realizado desde el master
mkfs.ext4 /dev/drbd0
+
'''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. Si el valor de este campo es elevado nos indicará
 +
que la base de datos real con la réplica no estará sincronizada, por tanto, nos interesa que este valor sea lo más pequeño posible.
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
Una vez finalizado el proceso la pantalla mostrará a siguiente información (para cada comando).
+
=== Procesos propios '''''VIVA'''it'' ===
 +
<br><br>
  
[[File:cluster16.png|700px]]
 
  
 +
==== bdCentral ====
  
Ahora crearemos el recurso para montar la partición de mysql en el directorio que creamos.
+
El proceso ''bdCentral.sh'' es el encargado de realizar la copia de seguridad. Tiene un archivo de configuración ''bdCentral.conf'' el cual puede encontrarse en la ruta '''/etc/MDtel/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
  
Vamos a crear restricciones para asegurarnos que los recursos estén todos en el nodo correcto y que arrancan en orden.
+
En caso de producirse algún error, se marcará dicho error en el log con una línea que comienza con la cadena "*ERROR".
  
Vamos a configurar que la partición se monte en el nodo que sea master que la ip flotante este en este nodo y arranque después de haber montado la partición.
+
Para ejecutar bdCentral:
 +
bdCentral.sh /etc/MDtel/bdCentral.conf
  
pcs cluster cib fs_mysql_cfg
+
Estos procesos se ejecutan automáticamente. Para ello está copiado el fichero bdCentral a /etc/cron.d.
pcs -f fs_mysql_cfg resource create DRBDfsMYSQL Filesystem device="/dev/drbd0" directory="/HDmysql" fstype="ext4"
 
pcs -f fs_mysql_cfg constraint colocation add DRBDfsMYSQL with DRBDmysqlClone INFINITY with-rsc-role=Master
 
pcs -f fs_mysql_cfg constraint order promote DRBDmysqlClone then start DRBDfsMYSQL
 
pcs -f fs_mysql_cfg constraint colocation add IP-MYSQL with DRBDfsMYSQL INFINITY
 
pcs -f fs_mysql_cfg constraint order DRBDfsMYSQL then IP-MYSQL
 
pcs cluster cib-push fs_mysql_cfg
 
pcs status
 
  
La salida mostrará lo siguiente:
+
Por defecto la programación vienen comentada por lo que será necesario activarlo.
  
[[File:cluster17.png|700px]]
+
Para que se roten los logs hay que copiar el fichero bdCentral.logrotate a /etc/logrotate.d (como bdCentral)
 +
La ruta donde se encuentran los logs es la siguiente: '''/var/log/myAcdSuperv.log'''
 +
 
 +
Fichero de configuación:
  
Nos indica que el Filesystem está creado y montado en el nodo nodo-vc-01.
+
ARCH_LOG=/var/log/bdCentral.log
 +
 +
BDHOST=localhost
 +
BDUSU=adminNimitz
 +
BDCLAVE=imdtelnimitz
 +
BDRUTA=/var/lib/MDtel/backupBDnimitz
 +
 +
 +
IGNORE_TABLAS=(nimitz.DAT_ACD_RASTREO  nimitz.DAT_ACUMULADOS_AGENTES  nimitz.DAT_ACUMULADOS_AGENTES_COLAS
 +
nimitz.DAT_ACUMULADOS_AGENTES_PAUSAS  nimitz.DAT_ACUMULADOS_AGENTES_VDN  nimitz.DAT_ACUMULADOS_COLAS 
 +
nimitz.DAT_ACUMULADOS_VDN  nimitz.DAT_ACUMULADOS_VDN_COLAS  nimitz.DAT_CONTACTOS_PREPARADOS 
 +
nimitz.DAT_IVR_INTERACCIONES  nimitz.DAT_IVR_NODOS  nimitz.DAT_IVR_PAGOS_TARJETA  nimitz.DAT_IVR_RESULT_ENCUESTAS
 +
nimitz.DAT_LLAMADAS  nimitz.DAT_LOG  nimitz.DAT_MUESTRAS_COLAS  nimitz.DAT_SEGMENTOS  nimitz.DAT_SESIONES_AGENTES 
 +
nimitz.DAT_SESIONES_AGENTES_COLAS  nimitz.DAT_SESIONES_AGENTES_PAUSAS  nimitz.DAT_SESIONES_AGENTES_VDN 
 +
nimitz.DAT_SINCRONIZA  nimitz.DAT_TR_ACD_EXTENSIONES  nimitz.DAT_TR_ACD_EXTEN_COLA  nimitz.DAT_TR_COLAS 
 +
nimitz.DAT_VALORACIONES  nimitz.DAT_ACD_RASTREO  nimitz.DAT_ACUMULADOS_AGENTES_COLAS 
 +
nimitz.DAT_ACUMULADOS_AGENTES_PAUSAS  nimitz.DAT_ACUMULADOS_AGENTES_VDN  nimitz.DAT_ACUMULADOS_COLAS 
 +
nimitz.DAT_ACUMULADOS_VDN  nimitz.DAT_LLAMADAS  nimitz.DAT_MUESTRAS_COLAS  nimitz.DAT_SEGMENTOS 
 +
nimitz.DAT_SESIONES_AGENTES  nimitz.DAT_SESIONES_AGENTES_COLAS  nimitz.DAT_SESIONES_AGENTES_PAUSAS 
 +
nimitz.DAT_SESIONES_AGENTES_VDN  nimitz.DAT_TR_ACD_EXTENSIONES  nimitz.DAT_TR_ACD_EXTEN_COLA  nimitz.DAT_TR_COLAS 
 +
nimitz.DAT_VALORACIONES)
  
Ahora haremos lo mismo para la partición de Asterisk.
+
*A continuación se explica los campos mas relevantes del fichero de configuración bdCentral.conf.
 +
{| class="wikitable"
 +
|-
 +
!Campo !!Descripción !!Posibles valores (si aplica)
 +
|-
 +
|ARCH_LOG|| /RUTA/FICHERO de log del proceso||
 +
|-
 +
|BDHOST||IP o HOST máquina base de datos de tiempo real||
 +
|-
 +
|BDUSU||Usuario acceso Base de datos de tiempo real||
 +
|-
 +
|BDCLAVE||Clave usuario acceso base de datos tiempo real||
 +
|-
 +
|BDRUTA||Ruta donde se depositará el dump de la base de datos||
 +
|-
 +
|IGNORE_TABLAS||Tablas de las que no queramos hacer backup||
 +
|-
 +
|}
  
pcs cluster cib fs_aster_cfg
 
pcs -f fs_aster_cfg resource create DRBDfsASTER Filesystem device="/dev/drbd1" directory="/HDaster" fstype="ext4"
 
pcs -f fs_aster_cfg constraint colocation add DRBDfsASTER with DRBDasterClone INFINITY with-rsc-role=Master
 
pcs -f fs_aster_cfg constraint order promote DRBDasterClone then start DRBDfsASTER
 
pcs -f fs_aster_cfg constraint colocation add IP-ASTER with DRBDfsASTER INFINITY
 
pcs -f fs_aster_cfg constraint order DRBDfsASTER then IP-ASTER
 
pcs cluster cib-push fs_aster_cfg
 
pcs status
 
  
Vemos que ya tenemos las 2 particiones montadas.
+
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
[[File:cluster18.png|700px]]
+
==== 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, este archivo puede encontrarse en la ruta '''/etc/MDtel/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".
  
======  Copiar datos de Asterisk a partición drbd. (En nodo 1) ======
+
Para ejecutar bdNodo:
  
Esto hay que realizarlo en el nodo en el que está montada la partición drbd para asterisk. Estará montado en la carpeta /HDaster
+
bdNodo.sh /etc/MDtel/bdNodo.conf
  
cd /HDaster/
+
Estos procesos se ejecutan automáticamente. Para ello está copiado el fichero bdNodo a /etc/cron.d.
tar -zcvf etc-asterisk.tgz /etc/asterisk
 
tar -zxvf  etc-asterisk.tgz
 
rm etc-asterisk.tgz
 
tar -zcvf var-lib-asterisk.tgz /var/lib/asterisk
 
tar -zxvf  var-lib-asterisk.tgz
 
rm var-lib-asterisk.tgz
 
tar -zcvf usr-lib-asterisk.tgz /usr/lib/asterisk
 
tar -zxvf  usr-lib-asterisk.tgz
 
rm usr-lib-asterisk.tgz
 
tar -zcvf var-spool-asterisk.tgz /var/spool/asterisk
 
tar -zxvf  var-spool-asterisk.tgz
 
rm var-spool-asterisk.tgz
 
  
======  Borrar los directorios de asterisk y crear enlaces simbólicos. (En los 2 nodos) ======
+
Por defecto la programación vienen comentada por lo que será necesario activarlo.
  
Borraremos los directorios y crearemos los enlaces simbólicos necesarios.
+
Para que se roten los logs hay que copiar el fichero bdNodo.logrotate a /etc/logrotate.d (como bdNodo)
  
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
rm -rf /etc/asterisk
+
==== Intz-Nimitz ====
ln -s /HDaster/etc/asterisk /etc/asterisk
 
  
rm -rf /var/lib/asterisk
+
Permite integrar procesos de asterisk (del dialplan) con la base de datos; por ejemplo es el que graba segmentos, inspecciona donde está 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.
ln -s /HDaster/var/lib/asterisk /var/lib/asterisk
 
  
rm -rf /usr/lib/asterisk
 
ln -s /HDaster/usr/lib/asterisk /usr/lib/asterisk
 
  
rm -rf /var/spool/asterisk
+
Para mas información consultar la página de [[intz-nimitz|intz-nimitz]].
ln -s /HDaster/var/spool/asterisk /var/spool/asterisk
 
  
 +
Desde un SSH ejecuta el comando “nc ip_maquina 1115”
  
======  Copiar datos de mysql a partición drbd. (En 1 nodo) ======
+
'''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
  
Esto hay que realizarlo en el nodo en el que está montada la partición drbd para mysql. Estará montado en la carpeta /HDmysql
 
  
cd /HDmysql/
+
Donde cada parámetro monitorizado indica:
tar -zcvf var-lib-mysql.tgz /var/lib/mysql
+
{| class="wikitable"
tar -zxvf  var-lib-mysql.tgz
+
|-
tar -zcvf etc-mysql.tgz /etc/mysql
+
!Parámetro!!Descripción
tar -zxvf  etc-mysql.tgz
+
|-
 
+
|sis/ver||Versión del proceso
 
+
|-
======  Borrar los directorios de mysql y crear enlaces simbólicos. (En los 2 nodos) ======
+
|sis/inic||Fecha de de arranque del proceso
 
+
|-
Los datos contenidos en estos directorios ya no son válidos, borramos los directorios.
+
|Sis/alarmas||Alarmas desde arranque
 
+
|-
Los enlaces simbólicos no van a ser necesarios, los vamos a conservar para facilitar el acceso a los directorios de mysql habituales
+
|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||Número de hilos contra la base de datos
 +
|-
 +
|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||
 +
|-
 +
|}
  
rm -rf /var/lib/mysql
+
Como complemento a los diagnósticos:
ln -s /HDmysql/var/lib/mysql /var/lib/mysql
 
rm -rf /etc/mysql
 
ln -s /HDmysql/etc/mysql /etc/mysql
 
  
 +
* Podremos examinar el fichero de configuración del proceso en  '''/etc/MDtel/intz-nimitz.conf'''
 +
* Podremos examinar los logs del proceso en '''/var/log/intz-nimitz.log'''
  
======  Modificar configuración de apparmor para mysql. (En los 2 nodos) ======
+
'''Fichero de configuración:'''
  
Debemos cambiar la configuración de apparmor para darle a mysql acceso a la nueva localización de los ficheros.
+
#
 
+
# Los nombres no pueden tener numeros
Debemos modificar el fichero /etc/apparmor.d/usr.sbin.mysqld
+
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
 
+
# Los valores comentados indican valores por defecto
  vi /etc/apparmor.d/usr.sbin.mysqld
+
 
+
  base
 
+
{
Y dejarlo configurado con la nueva ubicación de los ficheros. Debe quedar así:
+
cfg
 
+
{
 
+
soy_demonio = 1
[[File:cluster19.png|300px]]
+
hay_syslog = 0
 
+
# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
[[File:cluster20.png|300px]]
+
archivo_pid = -
 
+
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
Aplicamos los cambios con:
+
# No se usa si se activa hay_syslog
 
+
archivo_traza = -
apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld
+
}
 
+
cfg_recarga
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
+
{
 
+
  # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
====== Modificar archivos de configuración de mysql. (En 1 nodo) ======
+
nivel_traza = 3
 
+
pruebas = 1
Los enlaces simbólicos no funcionan con mysql, por eso necesitamos modificar archivos de configuración de mysql para cambiar las rutas de acceso a los archivos creado en el directorio /HDmysql.
+
hay_flush_traza = 1
 
+
}
Esto hay que realizarlo en el nodo que tiene montada la partición /HDmysql.
+
sis
 
+
{
Modificamos el fichero my.cnf.fallback
+
# No se usa. No modificar
 
+
subsistema = 0
  vi /HDmysql/etc/mysql/my.cnf.fallback
+
}
 
+
gmp
 
+
{
Deberá quedar así.
+
# Numero de mensajes. No modificar
 
+
num_msj = 1024
 
+
# Numero de buffer. No modificar
[[File:cluster21.png|300px]]
+
num_buf = 1024
 
+
}
Ahora el fichero mysql.cnf.
+
}
 
+
   
  vi /HDmysql/etc/mysql/mysql.cnf
+
  supervision
 
+
{
Y quedará así.
+
puerto_escucha = 1115
 
+
}
[[File:cluster22.png|400px]]
+
 
+
supervision_recarga
El fichero mysqld.cnf.
+
{
 
+
to_periodo = 60
  vi /HDmysql/etc/mysql/mysql.conf.d/mysqld.cnf
+
}
 
+
[[File:cluster23.png|400px]]
+
  cache
 
+
{
 
+
        hay_cache = 1
Y por último el fichero my.cnf.
+
}
 
+
  vi /HDmysql/etc/mysql/my.cnf
+
cache_recarga
 
+
{
Y quedara de la siguiente manera. (datadir / log_bin / includedir)
+
  # to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos
 
+
        colas_to_vida = 300
 
+
        colas_num_entrada = 128
[[File:cluster24.png|500px]]
+
        vdn_to_vida = 300
 
+
        vdn_num_entrada = 128
 
+
}
[[File:cluster25.png|500px]]
+
 
+
  regexp
 
+
{
[[File:cluster26.png|400px]]
+
hay_regexp = 1
 
+
}
 
+
====== Configuración del arranque de mysql. (En 1 nodo) ======
+
regexp_recarga
 
+
{
Vamos a configurar el arranque de mysql y le vamos a poner como condiciones que este en el nodo que este la ip flotante de mysql y que arranque después de que esté la ip.
+
num_entradas = 32
 
+
inc_entradas = 128
pcs cluster cib mysql_cfg
+
max_entradas = 1024
pcs -f mysql_cfg resource create MYSQL ocf:heartbeat:mysql binary="/usr/sbin/mysqld" config="/etc/mysql/my.cnf"  datadir="/var/lib/mysql" pid="/var/run/mysqld/mysqld.pid" socket="/var/run/mysqld/mysqld.sock" additional_parameters="--bind- address=0.0.0.0" op start timeout=60s op stop timeout=60s op monitor interval=20s timeout=30s
+
}
  pcs -f mysql_cfg constraint colocation add MYSQL with IP-MYSQL INFINITY
+
  pcs -f mysql_cfg constraint order IP-MYSQL then MYSQL
+
vivaitcall
  pcs cluster cib-push mysql_cfg
+
{
  pcs status
+
hay_vic = 1
 
+
puerto_escucha = 5555
 
+
identif = cms1
====== Configuración del arranque de Asterisk. (En 1 nodo) ======
+
entorno = nimitz
 +
max_conx = 128
 +
}
 +
 +
vivaitcall_recarga
 +
  {
 +
to_solicitud = 3
 +
to_desconexion = 3
 +
ip_valida
 +
{
 +
# Hasta 32 bloques de direcciones validas
 +
todas
 +
{
 +
ip = 0.0.0.0
 +
msk = 0.0.0.0
 +
}
 +
localhost
 +
{
 +
ip = 127.0.0.1
 +
msk = 255.255.255.255
 +
}
 +
}
 +
}
 +
 +
enrutamiento
 +
{
 +
hay_enrutamiento = 1
 +
max_pre_ruta_regs = 4
 +
max_ruta = 4
 +
max_ruta_desvios = 2
 +
  # Filtro de informacion de ancho de banda
 +
# MYSDanchoBandaPasoNinguno      0
 +
# MYSDanchoBandaPasoSoloDirectos 1
 +
  # MYSDanchoBandaPasoSoloEnPaso  2
 +
  # MYSDanchoBandaPasoTodos        3
 +
filtro_ancho_banda = 1
 +
  }
 +
   
 +
mysql
 +
{
 +
hay_mysql = 1
 +
host = BDTR
 +
usuario = nimitz
 +
clave = phikau3iwCe4O0PP5b09ng==
 +
base_datos = nimitz
 +
bd_supervivencia = 0
 +
num_curro = 10
 +
}
 +
 +
mysql_recarga
 +
{
 +
to_resp = 5
 +
}
  
  pcs cluster cib aster_cfg
+
   
pcs -f aster_cfg resource create ASTER lsb:asterisk
+
Los siguientes son los campos del fichero de configuración '''int-nimitz.conf''':
pcs -f aster_cfg constraint colocation add ASTER with IP-ASTER INFINITY
 
pcs -f aster_cfg constraint order IP-ASTER then ASTER
 
pcs cluster cib-push aster_cfg
 
pcs status
 
  
 +
{| class="wikitable"
 +
|-
 +
|Variable a modificar||Comentarios||Posibles valores (si aplica)
 +
|-
 +
|soy_demonio||Si corro como demonio o como proceso||1 demonio – 0 proceso
 +
|-
 +
|hay_syslog||Si hay servidor de syslog||1 lo hay – 0 no lo hay
 +
|-
 +
|archivo_pid||# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)||
 +
|-
 +
|archivo_traza||# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)||
 +
|-
 +
|nivel_traza||# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)||
 +
|-
 +
|pruebas||||
 +
|-
 +
|hay_flush_traza||||
 +
|-
 +
|subsistema||# No se usa. No modificar||
 +
|-
 +
|num_msj||# Numero de mensajes. No modificar||
 +
|-
 +
|num_buf||# Numero de buffer. No modificar||
 +
|-
 +
|puerto_escucha||Puerto de supervisión del demonio||
 +
|-
 +
|to_periodo||Timeout para reconectar||
 +
|-
 +
|hay_cache||si guarda datos o no en cache||1 hay cache – 0 no hay cache
 +
|-
 +
|colas_to_vida||# to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos||
 +
|-
 +
|colas_num_entrada||Número de entradas correspondiente a las colas||
 +
|-
 +
|vdn_to_vida||# to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos||
 +
|-
 +
|vdn_num_entrada||Número de entradas correspondiente a los VDN||
 +
|-
 +
|hay_regexp||||
 +
|-
 +
|num_entradas||||
 +
|-
 +
|inc_entradas||||
 +
|-
 +
|max_entradas||||
 +
|-
 +
|hay_vic||||
 +
|-
 +
|puerto_escucha||Puerto de escucha a nivel de vivait-call||
 +
|-
 +
|identif ||||
 +
|-
 +
|entorno||Nombre base de datos||
 +
|-
 +
|max_conx||Número máximo de conexiones a la base de datos||
 +
|-
 +
|to_solicitud||Timeout de solicitud||
 +
|-
 +
|to_desconexion||Timeout de desconexión||
 +
|-
 +
|ip||Dirección de red de escucha del intz-nimitz||
 +
|-
 +
|msk ||Máscara de red de escucha del intz-nimitz||
 +
|-
 +
|ip||IP localhost||
 +
|-
 +
|msk||Máscara localhost||
 +
|-
 +
|hay_enrutamiento||Hay fase de enrutamiento o no||1 hay enrutamiento – 0 no hay
 +
|-
 +
|max_pre_ruta_regs||Número máximo de prerutas a cargar||
 +
|-
 +
|max_ruta||Número máximo de rutas a cargar||
 +
|-
 +
|max_ruta_desvios||Número máximo de rutas de desvíos a cargar||
 +
|-
 +
|filtro_ancho_banda||Filtrar por ancho de banda||1 filtrar – 0 no filtrar
 +
|-
 +
|hay_mysql||Hay mysql||1 hay -0 no hay
 +
|-
 +
|host||IP o HOST máquina base de datos ||
 +
|-
 +
|usuario||Usuario acceso Base de datos||
 +
|-
 +
|clave||Clave usuario acceso base de datos||
 +
|-
 +
|base_datos||Nombre de la base de datos||
 +
|-
 +
|bd_supervivencia||Hay o no base de datos de supervivencia||1 hay base de datos de supervivencia – 0 no hay
 +
|-
 +
|num_curro||Número de conexiones simultáneas a la base de datos||
 +
|-
 +
|to_resp||Timeout de respuesta||
 +
|-
 +
|}
  
====== Mover los recursos a otra máquina. (En 1 nodo) ======
 
 
El crear 2 particiones separadas para el Asterisk y el mysql nos da la posibilidad de correr un servicio en cada máquina y tener los 2 nodos activos.
 
 
Para mover un recurso de nodo utilizaremos el siguiente comando en el nodo que está el recurso ejecutándose.
 
 
pcs resource move DRBDfsASTER
 
 
Esto crea restricciones locales para evitar que el recurso vuelva a este nodo (Puede tener prioridad de ejecución en este nodo y haría que volviera a este nodo automáticamente al estar online).
 
 
La restricción que crea banea el nodo para este recurso, si queremos quitar la restricción creada.
 
 
pcs resource clear DRBDFsAst
 
 
 
-----------------------------------------------------------------------------------------------------------------------------
 
 
==== Instalación y configuración del Cluster hasta la versión '''''<span style="color:#144F9B">VIVA</span>'''''it 3.3 ====
 
.
 
 
 
 
Hasta la versión '''3.3''' de '''''<span style="color:#144F9B">VIVA</span>'''''it , la instalación y configuración del cluster se hace de la siguiente forma:
 
 
 
'''[[Instalación y configuración del Cluster hasta la versión VIVAit 3.3]]'''
 
 
 
 
 
 
 
 
.
 
 
=== 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
+
<br><br>
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Documentation
+
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
==== Modificaciones realizadas sobre Asterisk 13 certified 2 ====
 
  
===== Archivos añadidos por '''MD'''tel =====
+
<!--
Los archivos añadidos son los siguientes:
+
==== intz-gh ====
  
* '''apps/app_ucid.c'''
+
intz-gh es un demonio que permite tanto la monitorizacion de extensiones (BLFs), como la activación de retrollamadas entre distintos nodos.
* '''apps/app_cli.c'''
 
* '''apps/app_crash.c'''
 
* '''apps/app_mdintz.c'''
 
* '''apps/app_mdintz.exports.in'''
 
* '''include/asterisk/mdintz.h'''
 
* '''include/asterisk/ucid.h'''
 
* '''res/res_mdcal.c'''
 
  
  
 +
'''Comandos desde consola de asterisk'''
  
'''→ apps/app_mdintz.exports.in '''
+
mdgh show
  
Este archivo sirve para la exportación de funciones del mdintz para el uso por aplicaciones externas
+
Uso: mdgh show [config | exten <exten_num> | enla <peer>]]
  
===== Modificaciones de archivos =====
+
* '''Ejemplo'''
  
Los archivos modificados por '''MD'''tel son los mostrados a continuación:
+
mdgh show config
 +
mdgh Configuracion:
 +
 +
  debug=no
 +
  retro_hay=yes
 +
  subscripcion_hay=yes
 +
  rest_red_ip=255.255.255.255
 +
  rest_red_msk=255.255.255.255
 +
  rest_puerto_escucha=8090
 +
  retro_exten_tech=SIP
 +
  retro_contexto=Cen_InicioLlamada_GHRetro
 +
  retro_to_descolgar=30 s
 +
  retro_A_cartel_fmt='retro: %s
  
* '''apps/app_mixmonitor.c'''
+
mdgh show exten 6146
* '''res/res_calendar_caldav.c'''
+
* '''contrib/scripts/safe_asterisk'''
+
mdgh Datos de la extension 6146:
* '''contrib/init.d/rc.debian.asterisk'''
+
* '''channels/sig_pri.c'''
+
  Datos en intz-gh:
* '''channels/chan_sip.c'''
+
    ESTADO=NOT_INUSE
 +
    INUSE=0
 +
    RINGING=0
 +
    TS=1535609682
 +
    HACE=1171
  
 +
mdgh show en la Trunk_MDtel
  
'''→ main/audiohook.c''' <!--style="color:#0000ff" -->
+
mdgh Datos del enlace Trunk_MDtel:
 +
 +
  Datos en intz-gh:
 +
    INUSE=0
 +
    RINGING=0
 +
    TS=1535610093
 +
    HACE=834
  
'''audiohook.c''' ha sido modificado para solucionar un crash de asterisk al utilizar en el mixmonitor las opciónes r y t
 
  
 +
'''Fichero de log'''
  
 +
/var/log/intz-gh.log
  
'''→ app_crash.c '''
 
  
Esta nueva aplicación es sólo compatible con '''Asterisk 13'''.
+
'''Fichero de configuracion'''
  
La documentación de la misma se encuentra en el comando: '''"core show application Crash"'''
+
/etc/MDtel/intz-gh.conf
  
Esta nueva aplicación ''permite añadir'' al plan de pruebas:
 
  
* Generación de una parada de asterisk. (Crash(IwantToGetAnAccessViolation) ó Crash(IwantToGetADoubleFreeMem))
+
'''Campos intz-gh.conf'''
* Verificación de su impacto. Por ejemplo, no deben cortarse las llamadas en curso, si así está previsto por la topología.
 
* Correcta generación de los "core", comprobando que funciona "backtrace" (bt).
 
  
'''Nota.-''' Esta aplicación no debería estar presente en una instalación de '''Asterisk 13'''
+
# Los nombres no pueden tener numeros.
 +
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles.
 +
# Los valores comentados indican valores por defecto.
  
 +
base
 +
 
 +
cfg
 +
{
 +
soy_demonio = 1
 +
hay_syslog = 0
 +
# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
 +
archivo_pid = -
 +
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
 +
# No se usa si se activa hay_syslog
 +
archivo_traza = -
 +
}
 +
cfg_recarga
 +
{
 +
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
 +
nivel_traza = 3
 +
pruebas = 1
 +
hay_flush_traza = 1
 +
# traza_milisegundos = 1
 +
}
 +
sis
 +
{
 +
# No se usa. No modificar
 +
subsistema = 0
 +
}
 +
gmp
 +
{
 +
# Numero de mensajes. No modificar
 +
num_msj = 256
 +
# Numero de buffer. No modificar
 +
num_buf = 256
 +
}
 +
}
 +
 +
supervision
 +
{
 +
puerto_escucha = 1116
 +
}
 +
 +
supervision_recarga
 +
{
 +
to_periodo = 60
 +
}
 +
 +
regexp
 +
{
 +
hay_regexp = 1
 +
}
 +
 +
regexp_recarga
 +
{
 +
num_entradas = 32
 +
inc_entradas = 128
 +
max_entradas = 1024
 +
}
 +
 +
vivaitcall
 +
{
 +
hay_vic = 1
 +
puerto_escucha = 5556
 +
identif = gh_000
 +
entorno = gh
 +
max_conx = 4
 +
}
 +
 +
vivaitcall_recarga
 +
{
 +
to_solicitud = 10
 +
to_desconexion = 10
 +
ip_valida
 +
{
 +
# Hasta 32 bloques de direcciones validas
 +
todas
 +
{
 +
ip = 0.0.0.0
 +
msk = 0.0.0.0
 +
}
 +
localhost
 +
{
 +
ip = 127.0.0.1
 +
msk = 255.255.255.255
 +
}
 +
}
 +
}
 +
 +
mysql
 +
{
 +
hay_mysql = 1
 +
host = BDTR
 +
usuario = nimitz
 +
clave = phikau3iwCe4O0PP5b09ng==
 +
base_datos = nimitz
 +
}
 +
 +
mysql_recarga
 +
{
 +
to_resp = 5
 +
}
 +
 +
gh1
 +
{
 +
hay_gh1 = 1
 +
# umbrales para el numero de digitos de una extension
 +
# sirve para saber si un peer es una extension o un enlace
 +
exten_min_digi = 3
 +
exten_max_digi = 8
 +
# numero maximo de extensiones soportadas
 +
exten_max = 500
 +
# numero maximo de enlaces soportados
 +
enla_max = 20
 +
# numero maximo de retrollamadas activas concurrentes
 +
retro_max = 50
 +
# numero maximo de retrollamadas activas concurrentes para una extension como destino (max 31)
 +
retro_max_b = 4
 +
}
 +
 +
gh1_recarga
 +
{
 +
# tiempo maximo en segs. para activar una retrollamada tras finalizar llamada
 +
to_retro_candidato = 60
 +
# tiempo maximo en segs. que una retrollamada espera a que las extensiones esten libres
 +
to_retro_activo = 300
 +
# temporizador de limpieza de tablas en segs.
 +
to_limpiar = 10
 +
}
 +
 +
ias
 +
{
 +
hay_ias = 1
 +
url = mdgh_rest
 +
puerto = 8090
 +
}
 +
 +
ias_recarga
 +
{
 +
# tiempo maximo en segs. para conectar con asterisk para comandos
 +
to_conx_cmd = 10
 +
# periodo en horas para actualizar lista de id de nodos y sus direcciones ip
 +
to_lista_nodos = 1
 +
}
 +
-->
  
'''→ app_mdintz.c y mdintz.h''' <!--style="color:#0000ff" -->
+
===== Nuevo servicio en intz-nimitz 04.00.00  =====
 
 
Esta aplicación sirve como interfaz a entornos (funcionalidades) creados por MDtel
 
 
 
Para mas información consultar la página de [[MDintz|MDintz]].
 
 
 
Las rutas de estos archivos son las siguientes:
 
 
 
'''apps/app_mdintz.c''' <br/>
 
'''include/asterisk/mdintz.h '''
 
 
 
'''app_mdintz.c''' :
 
 
 
'''app_mdintz.c''' orientada al proceso de enrutamiento a implementar en ''intz-nimitz.''
 
 
 
El archivo '''.c''' es casi igual para asterisk 1.4.24 y asterisk 13.
 
'''Nota.-''' Cuando se compila para asterisk 13, es necesario comentar la línea que pone<br /> '''"#define ASTERISK_OLD".'''
 
 
 
Los cambios implementados son:
 
 
 
* Unificación de código entre las versiones de asterisk
 
* Nuevo comando "qry"
 
* Posible resolución de "Mal write" en intz-nimitz (a verificar)
 
 
 
En cuanto al nuevo comando, el formato es:
 
 
 
'''mdintz qry <nHostFijo> <entorno> <servicio> <par1>...<parN>'''
 
 
 
 
 
Permite interrogar a un servidor de igual modo que hace el dialplan con '''fines de diagnóstico'''. La única diferencia es que se ha añadido el parámetro '''"nHostFijo"''' que puede tomar como valor '''"*"''' (lo que solicita una interrogación secuencial a todos los servidores definidos, igual a la funcionalidad del dialplan) ó '''"0"''' a '''"3"''' (que solicita un interrogación dirigida el host indicado como hostN, y sólo a él, en archivo de configuración).
 
 
 
 
 
Para instalarlo, es necesario copiar:
 
 
 
* '''asterisk/apps/app_mdintz.c'''
 
* '''asterisk/include/asterisk/mdintz.h'''
 
* En asterisk 1.4.24 conviene asegurar que se ha actualizado '''"asterisk/apps/app_queue.o"''' y '''"asterisk/apps/app_queue.so"'''
 
* Luego '''"make", "make install"''' y module '''"unload/load"''' (mejor "stop now" y start)
 
 
 
'''→ scripts y rc.debian.asterisk'''
 
 
 
cambiado contrib/scripts por el modificado por MDtel<br />
 
cambiado contrib/init.d/rc.debian.asterisk por el modificado por MDtel
 
 
 
 
 
'''→ Carpeta mp3 añadida al directorio addons'''
 
 
 
La carpeta mp3 en addons permite la reproducción desde el diaplan de los mensajes en mp3. En make menuselect hay que marcar el format_mp3 y app_mp3 e instalar el paquete mpg123 de ubuntu
 
 
 
'''→ sig_pri.c'''
 
 
 
Modificado para enviar/recibir el ucid en un primario qsig
 
 
 
Para que se envie el ucis tenemos que habilitar el envio de facilidades en el chan_dahdi.conf
 
 
 
facilityenable = yes
 
 
 
 
 
'''→ init.d''' <!--style="color:#0000ff" -->
 
 
 
* Uno de los archivos modificados ha sido '''init.d''', se encuentra en la ruta: '''/etc/init.d/asterisk'''. La modificación realizada es la siguiente:
 
 
 
{|style="background-color:#ffffcc;" class="wikitable"
 
|-
 
|-
 
| SAFE_ASTEISK=/usr/sbin/safe_asterisk <br/>
 
if [ -x $SAFE_ASTERISK ] ; then<br/>
 
:# //!! wkw<br/>
 
:DAEMON=$SAFE_ASTERISK<br/>
 
fi
 
|}
 
 
 
 
 
<!--archivo-->
 
 
 
'''→ safe-asterisk'''
 
* Se encuentra en la siguiente ruta:'''/usr/sbin/safe-asterisk''' .En este archivo se ha modificado MAXFILES=32768
 
 
 
'''→ default'''
 
 
 
* Este fichero podemos encontrarlo en: '''/etc/default/asterisk'''. La finalidad de la modificación de este fichero es poder correr como usuario Asterisk, grupo asterisk y generar cores (descomentar línea)
 
Las modificaciones realizadas han sido:
 
 
 
{|style="background-color:#ffffcc;" class="wikitable"
 
|-
 
|-
 
| AST_USER="asterisk"
 
AST_GROUP="asterisk"
 
 
 
COREDUMP=yes
 
|}
 
 
 
===== Nueva función de asterisk: app_cli.so =====
 
 
 
Esta función permite ejecutar desde el '''dialplan''' un comando de línea de consola de '''asterisk (CLI).''' Su primer uso (y esperamos que no último) será para lanzar los '''notify''' que los teléfonos necesitan para el ''reaprovisionamiento'' desde el portal o desde la facilidad de movilidad de usuario.
 
 
 
Básicamente ejecuta un comando y devuelve su salida. Utiliza un archivo intermedio que puede ser:
 
  
* '''/dev/null''' si el campo se deja vacío, por tanto, no se puede recuperar la salida.
 
* '''TEMP''', en cuyo caso se crea un archivo temporal que se borra antes de finalizar la ejecución de la función.
 
* Un nombre de fichero que es responsabilidad del dialplan el borrarlo cuando proceda.
 
  
  
Para instalarlo basta copiar '''apps/app_cli.c''' en el directorio ''' "apps" ''' de los fuentes y luego  ejecutar '''"make" y "make install".'''
+
Para las colas con extensiones multiterminal, se ha creado un ha creado un nuevo servicio en intz-nimitz 04.00.00.
  
A continuación se pasa el resultado de '''"core show function CLI" '''
+
La descripción de nuevo servicio es:
  
'''[Synopsis]'''
+
    multiTermGrupoSaltoRing
 +
    . Devuelve la mascara con los terminales que tienen que sonar (ring) al estar la extension en una cola (queue, ringall).
 +
    . par1 (extension)
 +
    . Retornos posibles (ademas del los genericos) en ${MDintzRes}:
 +
    .. OK: Todo correcto.
 +
    .. KO: Ha habido un problema.
 +
    . Retorno en MTERM (solo si OK): mascara con los terminales y su orden (ej: '33245289').
 +
    . Retorno en MTERM_MENOR (solo si OK): mascara con los terminales y su orden, filtrando las de orden menor (ej: '00200200').
  
Lanza un comando CLI desde dialplan
+
==== 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.
  
'''[Description]''' <br />
+
A efectos de diagnósticos, desde un SSH ejecuta el comando “nc ip_maquina 1120”
- CLI(nomArchSal,cmd)<br />
 
- Si 'nomArchSal' está vacio, se usa '/dev/null' y no se recupera resultado<br />
 
- Si 'nomArchSal'=TEMP, Se crea un archivo temporal que se borra al final<br />
 
- En otro caso, se crea el archivo y no se borra
 
  
'''[Syntax]'''<br />
+
'''root@vivait-acd:~# nc localhost 1120'''
  CLI(nomArchSal,cmd)
+
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)
  
'''[Arguments]'''<br />
+
Donde cada parámetro monitorizado indica:
'''nomArchSal'''
 
    Archivo de salida (si se omite, /dev/null)
 
'''cmd'''
 
    Comando a ejecutar via CLI
 
 
 
==== Dialplan  ====
 
 
 
El Dialplan podría considerarse la columna vertebral del sistema ''Asterisk''.
 
 
 
Es una colección ordenada de acciones que se llevan a cabo cuando un usuario marca una serie de números. Hace la función de una tabla de enrutamiento de llamadas.
 
 
 
Todas las configuraciones generales de Asterisk están accesibles en la ruta '''/etc/asterisk'''
 
 
 
'''CONCEPTOS BÁSICOS'''
 
 
 
♦ '''EXTENSIONES'''
 
 
 
Una extensión es una marcación en el teclado de un teléfono. Dicha configuración podemos encontrarla en el archivo '''extensions.conf'''
 
 
 
Por ejemplo, un usuario podría marcar “3001” en su teléfono, y eso sería una extensión. También podría marcar un número de teléfono nacional, como por ejemplo “915881000”, y también sería una extensión.
 
 
 
En Asterisk pueden definirse también extensiones como texto, por tanto no debemos relacionar las extensiones únicamente con números.
 
 
 
Algunas reglas que sería interesante conocer serían las siguientes:
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! '''Regla''' !! '''Descripción'''
+
!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||
 
|-
 
|-
| '''X''' || Cualquier cifra de 0 a 9
+
|Gmp/tarea||
 
|-
 
|-
|'''Z'''||Cualquier cifra de 1 a 9
+
|Tmp/uptime||Tiempo que lleva corriendo
 
|-
 
|-
|'''N'''||Cualquier cifra de 2 a 9
+
|mtr/mys||Si está conectado al MySQL
 
|-
 
|-
|'''[x-y]'''||Cualquier cifra de "x" a "y"
+
|mtr/ocup||Porcentaje de ocupación
 
|-
 
|-
|'''[xyz]'''|| Las cifras "x", "y" o "z"
+
|mtr/planif||Contactos planificados Totales (Último minuto)
 
|-
 
|-
|'''.'''||Una o más repeticiones del símbolo anterior
+
|mtr/intento||Intentos totales (Ültimo minuto)
 
|-
 
|-
|'''!'''||Cero o más repeticiones del símbolo anterior
 
 
|}
 
|}
  
Estas reglas son necesarias a la hora de definir por ejemplo todos los números de teléfono posibles en España
+
* Posee un fichero de configuración llamado ''motorSal.conf'' en la ruta '''/etc/MDtel/motorSal.conf''':
  
♦ '''PRIORIDADES'''
+
#
 
+
# Los nombres no pueden tener numeros
En lenguaje scripting, las acciones se van ejecutando de arriba a abajo en orden. En cambio, en Asterisk, el orden en el que se ejecutan las acciones es el indicado mediante números.
+
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
Primero se ejecutará la acción 1, luego la 2...así sucesivamente.
+
# Los valores comentados indican valores por defecto
 
+
Es decir no basta con definir las acciones que se llevarán a cabo, también debemos indicar el orden en el que se llevarán a cabo.
+
base
 
+
{
♦ '''CONTEXTOS'''
+
cfg
 
+
{
Es mecanismo que nos permite variar el comportamiento del sistema en función del número que se marque. Su misión es aumentar la seguridad del sistema ofreciendo servicios diferenciados en función del usuario.
+
soy_demonio = 1
 
+
hay_syslog = 0
La sintaxis típica es el nombre del contexto englobado entre corchetes [nombre_contexto]. Si un dispositivo no tiene un contexto definido se redirige directamente al contexto por defecto.
+
# Archivo con identificador de proceso: (-: /var/run/motorSal.pid)
 
+
archivo_pid = -
 
+
# Archivo_traza: (-: stdout o /var/log/motorSal.log si soy_demonio)
 
+
# No se usa si se activa hay_syslog
Los ficheros que conforman el Dialplan se clasifican en:
+
archivo_traza = -
 
+
}
* '''Generales'''
+
cfg_recarga
* '''Particulares'''
+
{
* '''Web'''
+
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
 
+
nivel_traza = 2
{| class="wikitable"
+
pruebas = 0
|-
+
hay_flush_traza = 1
! '''Fichero''' !! '''Función'''
+
# traza_milisegundos = 1
|-
+
}
| '''Generales''' || Se encuentran los ficheros de propios de MDtel y Asterisk. Es importante remarcar que estos ficheros NO pueden ser modificados por el usuario.
+
sis
|-
+
{
|'''Particular'''||Estos ficheros son los únicos que puede modificar el usuario
+
# No se usa. No modificar
|-
+
subsistema = 0
|'''Web'''|| Se encierran aquí los archivos generados automáticamente por la plataforma, a través del portal
+
}
|}
+
gmp
 
+
{
En función del nodo en el que estemos trabajando, encontraremos dos tipos de dialplan:
+
# Numero de mensajes. No modificar
 +
num_msj = 256
 +
# Numero de buffer. No modificar
 +
num_buf = 256
 +
}
 +
}
 +
 +
supervision
 +
{
 +
puerto_escucha = 1120
 +
}
 +
 +
supervision_recarga
 +
{
 +
to_periodo = 60
 +
}
 +
 +
mysql
 +
{
 +
hay_mysql = 1
 +
host = localhost
 +
usuario = nimitz
 +
clave = phikau3iwCe4O0PP5b09ng==
 +
base_datos = nimitz
 +
}
 +
 +
motor
 +
{
 +
hay_motor = 1
 +
ciclos_campanna_activa = 30
 +
# Directorio donde se almacenan las librerias dinamicas con las estrategias
 +
# Por defecto = '/usr/lib/motorSal/estrategias'
 +
dir_estrategias = /usr/lib/motorSal/estrategias
 +
}
 +
 +
motor_recarga
 +
{
 +
# Periodo de ejecucion del ciclo del motor
 +
to_ciclo = 10
 +
}
 +
 +
muestreo
 +
{
 +
hay_muestreo = 1
 +
}
  
'''* 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)
+
Los campos del fichero de configuración son los siguientes:
  
A continuación se muestran las tablas con los ficheros correspondientes a cada Dialplan.
+
{| class="wikitable"
 
+
|-
{| border="1" align="center" bgcolor="FloralWhite"
+
!Campo !!Descripción !!Posibles valores (si aplica)
|+ '''Ficheros de configuración Dialplan Corporativo'''
+
|-
| '''GENERALES'''
+
|soy_demonio||Si corro como demonio o como proceso||1 demonio – 0 proceso
| '''PARTICULARES'''
+
|-
| '''WEB'''
+
|hay_syslog||Si hay servidor de syslog||1 lo hay – 0 no lo hay
 +
|-
 +
|archivo_pid||# Archivo con identificador de proceso: (-: /var/run/motorSal.pid)||
 +
|-
 +
|archivo_traza||# Archivo_traza: (-: stdout o /var/log/motorSal.log si soy_demonio)||
 +
|-
 +
|nivel_traza||# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)||
 +
|-
 +
|pruebas||||
 +
|-
 +
|hay_flush_traza||||
 +
|-
 +
|traza_milisegundos||||
 +
|-
 +
|subsistema||# No se usa. No modificar||
 +
|-
 +
|num_msj||# Numero de mensajes. No modificar||
 +
|-
 +
|num_buf ||# Numero de buffer. No modificar||
 +
|-
 +
|puerto_escucha||Puerto de supervisión del demonio||
 +
|-
 +
|to_periodo||Timeout para reconectar||
 +
|-
 +
|hay_mysql||Hay mysql||1 hay -0 no hay
 +
|-
 +
|host||IP o HOST máquina base de datos de tiempo real||
 +
|-
 +
|usuario||Usuario acceso Base de datos de tiempo real||
 +
|-
 +
|clave||Clave usuario acceso base de datos de tiempo real||
 +
|-
 +
|base_datos||Nombre de la base de datos||
 +
|-
 +
|hay_motor||Si hay campañas saliente o no||1 hay motor saliente – 0 no hay motor saliente
 +
|-
 +
|ciclos_campanna_activa||||
 +
|-
 +
|dir_estrategias ||# Directorio donde se almacenan las librerias dinámicas con las estrategias||
 +
|-
 +
|to_ciclo||# Periodo de ejecución del ciclo del motor||
 +
|-
 +
|hay_muestreo||||1 hay muestreo – 0 no hay muestreo
 
|-
 
|-
| ext_Grabaciones.conf <br />ext_InicioLlamada.conf <br /> ext_InicioLlamada_Dahdi.conf <br />ext_InicioLlamada_ExtSIP.conf <br/>ext_InicioLlamada_TrunkSIP.conf <br />ext_MARCAR_ColaCentralita.conf <br /> ext_MARCAR_ColaCentralita_Dial.conf<br /> ext_MARCAR_Cola.conf <br />ext_MARCAR_Cola_Dial.conf<br />ext_MARCAR.conf  <br /> ext_MARCAR_DejarMensaje.conf <br /> ext_MARCAR_DejarMensaje_Dial.conf <br />ext_MARCAR_Extension.conf<br />ext_MARCAR_Extension_Dial.conf <br />ext_MARCAR_Externo.conf <br />ext_MARCAR_Externo_Dial.conf <br />ext_MARCAR_Facilidad.conf <br />ext_MARCAR_Facilidad_Dial.conf <br />ext_MARCAR_Facilidad_nimitz.conf<br />ext_MARCAR_Interno.conf <br />ext_MARCAR_LeerMensaje.conf <br />ext_MARCAR_LeerMensaje_Dial.conf<br />ext_MARCAR_Nodo.conf<br />ext_MARCAR_Nodo_Dial.conf <br />ext_MARCAR_SalasConf.conf <br />ext_MARCAR_SalasConf_Dial.conf <br />ext_MARCAR_Servicios.conf <br />ext_MARCAR_VDN.conf <br />MARCAR_VDN_Dial.conf<br />ext_MDtel.conf <br />ext_MDtel_Var.conf <br />ext_Subrutinas_AnchoBanda.conf <br />ext_Subrutinas_BD.conf <br />ext_Subrutinas_BD_Facilidad.conf <br />ext_Subrutinas_BD_Facilidad.conf <br /> ext_Subrutinas_Colas.conf <br />ext_Subrutinas.conf <br />ext_Subrutinas_Enrutamiento.conf <br />ext_Subrutinas_finLlamada.conf<br />ext_Subrutinas_Grabacion.conf<br />ext_Subrutinas_nimitz.conf<br />ext_Subrutinas_Varias.conf<br />ext_Subscribe.conf<br />ext_Transfer.conf <br />ext_Transfer_ExtSIP.conf<br />ext_Transfer_TrunkInternos.conf <br />ext_TrunkInternos.conf<br />ext_TrunkInternos_Dial.conf <br />sip_Estatico.conf<br /> sip_GENCUST.conf <br />sip_notify.conf <br />queues.conf <br /> queues_GENERAL.conf <br />queues_PLANTILLACOLAS.conf<br />
 
 
| ext_Enrutador_Particular.conf<br /> ext_InicioLlamada_Dahdi_Particular.conf<br />ext_InicioLlamada_ExtSIP_Particular.conf<br />ext_InicioLlamada_Particular.conf <br />ext_InicioLlamada_TrunkSIP_Particular.conf<br />ext_MARCAR_Extension_Particular.conf <br />ext_MARCAR_Externo_Particular.conf <br/> ext_MARCAR_Facilidad_Particular.conf<br /> ext_MARCAR_VDN_Particular.conf <br />ext_MDtel_Particular.conf <br/> ext_TrunkInternos_Particular.conf <br/>
 
 
|asterisk_WEB.conf <br /> ext_MDtel_WEB.conf <br /> sip_trunkExt_WEB.conf <br />sip_trunkInt_WEB.conf <br />sip_trunk_WEB.conf <br /> sip_WEB.conf <br /> queues_WEB.conf
 
 
|}
 
|}
  
 +
* Respecto a los logs del motorSal consultar el siguiente apartado: [[Trazas motorSal]]. Los logs pueden verse en la ruta '''/var/log/motorSal.log'''
  
{| border="1" align="center" bgcolor="FloralWhite"
 
|+ '''Ficheros de configuración Dialplan ACD'''
 
| '''GENERALES'''
 
| '''PARTICULARES'''
 
| '''WEB'''
 
|-
 
| ext_Enrutador.conf<br />ext_Grabaciones.conf <br /> ext_InicioLlamada.conf <br /> ext_InicioLlamada_CTI.conf <br />ext_InicioLlamada_Dahdi.conf <br />ext_InicioLlamada_ExtSIP.conf <br />ext_InicioLlamada_Marcador.conf <br />ext_InicioLlamada_TrunkSIP.conf <br />ext_MARCAR_ColaCentralita.conf <br />ext_MARCAR_ColaCentralita_Dial.conf<br />ext_MARCAR_Cola.conf <br />ext_MARCAR_Cola_Dial.conf <br />ext_MARCAR.conf <br />ext_MARCAR_DejarMensaje.conf <br />ext_MARCAR_DejarMensaje_Dial.conf <br />ext_MARCAR_Extension.conf <br />ext_MARCAR_Extension_Dial.conf <br />ext_MARCAR_Externo.conf <br />ext_MARCAR_Externo_Dial.conf <br />ext_MARCAR_Facilidad.conf <br />ext_MARCAR_Facilidad_Dial.conf <br />ext_MARCAR_Facilidad_nimitz.conf<br />ext_MARCAR_LeerMensaje.conf <br />ext_MARCAR_LeerMensaje_Dial.conf <br />ext_MARCAR_Nodo.conf <br />ext_MARCAR_Nodo_Dial.conf <br />ext_MARCAR_SalasConf.conf <br />ext_MARCAR_SalasConf_Dial.conf<br />ext_MARCAR_Servicios.conf <br />ext_MARCAR_VDN.conf <br />ext_MARCAR_VDN_Dial.conf<br />ext_MDtel.conf <br />ext_MDtel_Var.conf <br />ext_Subrutinas_AnchoBanda.conf <br />ext_Subrutinas_BD.conf <br />ext_Subrutinas_BD_Facilidad.conf <br /> ext_Subrutinas_Colas.conf <br />ext_Subrutinas.conf <br />ext_Subrutinas_Enrutamiento.conf <br /> ext_Subrutinas_finLlamada.conf<br />ext_Subrutinas_Grabacion.conf <br />ext_Subrutinas_nimitz.conf<br />ext_Subrutinas_Varias.conf <br />ext_Subscribe.conf<br />ext_Transfer.conf <br />ext_Transfer_ExtSIP.conf<br />ext_Transfer_TrunkInternos.conf <br />ext_TrunkInternos.conf <br />ext_TrunkInternos_Dial.conf <br />queues_GENERAL.conf<br />queues_PLANTILLACOLAS.conf <br />sip_GENCUST.conf <br />sip_GENERAL.conf <br />sip_notify.conf <br />sip_PLANTILLAEXT.conf<br />sip_supervision.conf <br />
 
 
 
 
| ext_Enrutador_Particular.conf <br />ext_InicioLlamada_CTI_Particular.conf<br />ext_InicioLlamada_Dahdi_Particular.conf<br />ext_InicioLlamada_ExtSIP_Particular.conf<br />ext_InicioLlamada_Marcador_Particular.conf <br />ext_InicioLlamada_Particular.conf.<br />ext_InicioLlamada_TrunkSIP_Particular.conf<br />ext_MARCAR_Externo_Particular.conf<br />ext_MARCAR_Facilidad_Particular.conf<br />ext_MARCAR_VDN_Particular.conf<br /> ext_MDtel_Particular.conf<br />ext_TrunkInternos_Particular.conf<br />
 
  
|asterisk_WEB.conf <br /> ext_MDtel_WEB.conf <br />queues_WEB.conf<br /> sip_trunkInt_WEB.conf <br />sip_WEB.conf <br />
 
|}
 
 
<br><br>
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
<br><br>
  
=== Servicios networking ===
+
==== MyACDSuperv ====
Son muy importantes las configuraciones adecuadas de los servicios de:
+
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.
  
* '''NTP''': El sistema en global ha de estar sincronizado; todos los servidores y puestos de trabajo (en el caso de ''VIVA''it 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
+
Es el responsable de mostrar información en las ventanes de tiempo real del supervisor.
  
* '''DNS''': La configuración de DNS de la plataforma será coherente con el resto de la plataforma IT del cliente
+
Es también el proceso que genera las llamadas en el marcador automático de '''''VIVA'''''it Suite.
  
* '''DHCP''': Es necesario coordinar con el cliente la asignación de direcciones para los diferentes elementos de la plataforma '''''VIVA'''''it, 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
+
A efectos de diagnósticos, desde un SSH se ejecuta el comando “nc ip_maquina 1112”.
  
=== Bases de datos (BBDD)===
+
'''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
  
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.
+
Donde cada parámetro monitorizado indica:
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: [[Base de datos|Información completa de la BD]]. Podéis ampliar más información en https://dev.mysql.com/doc/
+
{| class="wikitable"
 +
|-
 +
!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||Extensiones/Extensiones/Extensiones monitorizadas|-
 +
|-
 +
|AMI/asig||
 +
|-
 +
|MYSQL/cnx||Conectado (1) a MySQL
 +
|-
 +
|MYSQL/ms||Tiempo de última operación en ejecutarse
 +
|-
 +
|}
  
 +
Como complemento a los diagnósticos:
  
==== BBDD Tiempo Real ====
+
* Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/myAcdSuperv.cnf'''
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 '''''VIVA'''''it Supervisor
+
* Podremos examinar los logs del proceso en '''/var/log/myAcdSuperv.log'''
  
De la base de datos de tiempo real leen los procesos que requieren información, y las aplicaciones:
 
*'''''VIVA'''''it Supervisor (para reporting de tiempo real)
 
*PanelWeb
 
*Datos de sesión de '''''VIVA'''''it 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
 
  
Para cuando la BDTR contienen un número masivo de datos, existe un script que borra el contenido de ciertas tablas de la BD (tablas DAT_) dejando solamente datos de un cierto número de días configurable.
+
<br><br>
Este script se llama borraRegistrosNimitz.pl; para más información consultar el apartado de Howto's.
+
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
'''Por defecto, a partir de la versión 3.2.0 de la plataforma, los registros se mantedrán 2 meses.'''
+
==== 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:
 +
# Proceso escoba perteneciente a nodo con agente de grabación (recordNodo) llamado '''''escobaGW.pl'''''.
 +
# Proceso escoba perteneciente o no a un servidor de grabación (recordCentral) llamado '''''escobaGrabsBd.pl'''''.
  
==== BBDD Réplica ====
+
===== escobaGW.pl =====
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
+
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''.
  
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.
+
===== escobaGrabsBd.pl =====
 +
Se ejecuta sobre 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.
  
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
+
<br><br>
 
+
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
Algunos procesos que utilizan la base de datos de réplica son:
+
<br><br>
*'''''VIVA'''''it Reporting
+
* En DAT_LLAMADAS obtendremos todos los registros correspondiente al segmentos anteriores.
*'''''VIVA'''''it Tracker
+
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.
*Histórico en tiempo real de '''''VIVA'''''it Supervisor
 
  
 +
==== 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, las máquinas donde suelen alojarse estos servidores poseen discos duros limitados, lo que hace necesario en algunos casos incorporar ''dispositivos NAS''.
  
'''IMPORTANTE: Ningún proceso, programa, aplicación, etc. escribe en la base de datos de réplica; tan solo se extrae información'''
+
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 significa que sea necesario tener ''dispositivos NAS'' para funcionar, sino que puede tomar datos de diferentes sitios.
  
==== BBDD de copia ====
+
En '''recordCentral''' pueden existir tres tipos de dispositivos NAS:
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'''.
+
* Uno dedicado para las llamadas
 
+
* Uno dedicado para los segmentos
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.
+
* Uno mixto para todas las llamadas y segmentos.
  
===== 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 '''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, intenta descargar los segmentos de las llamadas y convertirlas al formato adecuado (MP3).
 +
Como una característica particular cada diez minutos, siempre que 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 y descargar todas las grabaciones. 
  
* 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
+
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:
* 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.
+
'''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:
  
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".
+
{| class="wikitable"
 
+
|-
==== Diagnósticos y operaciones sobre bases de datos ====
+
! Parámetro !! Descripción
 
+
|-
=====Comprobación que una base de datos está arrancada=====
+
| SIS/ver || Versión del proceso
Para comprobar si la base de datos está arrancada debemos poner en el terminal : '''ps aux | grep mysql'''
+
|-
 
+
| SIS/inic || Fecha de arranque del proceso
Si la base de datos está arrancada y funcionando correctamente se nos mostrará en el terminal:
+
|-
[[Archivo:Base_Datos_bien.png‎ |500px|center]]
+
| SIS/alarmas || Alarmas desde arranque
 
+
|-
Por el contrario, si la base de datos presenta algun problema el mensaje mostrado será:
+
| SIS/ultAlar || Fecha de última alarma
 
+
|-
[[Archivo:Base_datos_mal.png |center]]
+
| MYSQL/cnx || Conectado (1) a MySQL
 
+
|-
=====Comprobación que la base de datos de réplica está sincronizada con la base de datos de tiempo real.=====
+
| NAS/llamadas || Alojamiento en NAS de llamadas activo (grabación de llamada completa en un único archivo)
 
+
|-
Si se necesita verificar que la base de réplica está sincronizada con la base de datos en tiempo real basta con acudir al comando : '''show slave status\G'''.
+
| NAS/segmentos || Alojamiento en NAS de segmentos activo
 
 
Una vez introducido veremos:
 
 
 
[[Archivo:Replica.png |980px|center]]
 
 
 
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. Si el valor de este campo es elevado nos indicará
 
que la base de datos real con la réplica no estará sincronizada, por tanto, nos interesa que este valor sea lo más pequeño posible.
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
 
 
=== Tabla Dat_Log ===
 
 
 
En la tabla '''Dat_log''' podemos encontrar el histórico de las operaciones realizadas por las aplicaciones contra la Base de Datos; se registran todos los cambios que realizan los usuarios a través de las diferentes aplicaciones (Portal de administración, Supervisor, Meet y Alertas).
 
 
 
La tabla está formada por los siguientes campos:
 
 
 
[[BD.DAT_LOG]]
 
 
 
 
En la siguiente tabla se especifican algunos de los posibles valores de los campos, en función del valor de E_ACCION.
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
!E_ACCION Nº!!E_ACCION TAccionLog!!Descripción de la acción!! `C_TABLA` !! `ID_REGISTRO` !! `N_PAR1` !! `N_PAR2` !! `C_PAR3` !! `C_PAR4`
+
| REC/llamNum || Llamadas procesadas
 
|-
 
|-
|10||accionLog_escuchar_seg||Escuchar segmento|| || || || || ||  
+
| REC/llamErr || Llamadas con error
 
|-
 
|-
|20||accionLog_escuchar_lla||Escuchar llamada|| || || || || ||
+
| REC/segmNum || Segmentos procesados
 
|-
 
|-
|30||accionLog_descargar_seg||Descargar segmento|| || || || || ||
+
| REC/segmErr || Segmentos con error
 
|-
 
|-
|40||accionLog_descargar_lla||Descargar llamada|| || || || || ||
+
| NODO/fase  || Número de proceso de recordCentral
 
|-
 
|-
|50||accionLog_generar_config||Generar configuración|| || || || || ||
+
| NODO/cuarentena  || Lista de nodos en cuarentena, separada por comas
 
|-
 
|-
|60||accionLog_cambiar_clave_propia||Cambiar clave propia|| || || || || ||
+
| NODO/descarga || Lista de nodos en descarga, separada por comas
 
|-
 
|-
|65||accionLog_login_correcto||Login correcto||||idUsuario||nivelSupervisor|| ||
+
| NODO/gestion || Lista de nodos gestionados, separada por comas (cuarentena + descarga = gestión)
|-
+
|}
|70||accionLog_login_erroneo||Login erroneo|| || || || || ||
+
 
|-
+
Como complemento a los diagnósticos:
|80||accionLog_login_multiple||Login multiple|| || || || || ||
+
* Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/recordCentral.pconf'''
|-
+
 
|90||accionLog_escuchar_ext||Escuchar Extensión|| || || || || ||
+
El fichero es el siguiente:
|-
+
|100||accionLog_chg_objetivo_peso||Modificar nivel servicio|| ||idCola||objetivo||peso|| ||
+
#
|-
+
# Configuracion de recordCentral.pl
|105||accionLog_add_agente_cola_bd||Añadir agente a grupo BD|| ||idCola||agente||prioridad||obligatorio||
+
#
|-
+
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
|115||accionLog_del_agente_cola_bd||Quitar agente de grupo BD|| ||idCola||agente|| ||
+
$depurar = 1;
|-
+
|125||accionLog_prio_agente_cola_bd||Modificar prioridad agente en grupo BD|| ||idCola||agente||prioridad||obligatorio|| 
+
# 0: Arranca como proceso - 1: arranca como demonio
|-
+
$soyDemonio = 1;
|135||accionLog_perfil_agente_bd||Asignar perfil a agente BD|| ||idAgente||perfil||  ||||
+
|-
+
# Archivo de log ('': salida estandar)
|140||accionLog_add_agente||Añadrid agente|| || ||  || || ||
+
$logArch = '/var/log/record/recordCentral.log';
|-
+
|145||accionLog_del_agente||Borrar agente|| || ||  || || ||
+
# Archivo para el pid (eliminando el .pid final)
|-
+
$pidArch = '/var/run/record/recordCentral';
|150||accionLog_chg_agente||Modificar agente|| ||idAgente|| || ||nombre||cuenta
+
|-
+
# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
|155||accionLog_add_agenda_perfil||Añadir agenda a perfil|| ||idPerfil||idAgenda||  || ||
+
$unaVezSolo = 0;
|-
+
|160||accionLog_del_agenda_perfil||Borrar agenda de perfil|| ||idPerfil||idAgenda||  || ||
+
# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
|-
+
$toBucle = 10;
|165||accionLog_add_entrada_agenda||Añadir entrada a agenda|| || ||idAgenda|| ||nombre||numero
+
|-
+
# Bytes por segundo en archivos de grabaciones
|170||accionLog_del_entrada_agenda||Borrar entrada de agenda|| ||idEntrada||idAgenda|| ||nombre||numero
+
$bytesPorSegundo = 16000;
|-
+
|175||accionLog_chg_entrada_agenda||Modificar entrada de agenda|| ||idEntradaAgenda|| || ||nombre||numero
+
# Bytes a leer en cada accceso a disco
|-
+
$bytesLeerBuf = 1048576;
|180||accionLog_add_agenda||Añadir agenda|| || || || ||nombre||descripción
+
|-
+
# Conexion de base de datos
|185||accionLog_del_agenda||Borrar agenda|| || ||  || || ||
+
$db='nimitz';
 +
$dbHost = 'BDTR';
 +
$dbPort = '3306';
 +
$dbUsuario = 'nimitz';
 +
$dbClave = 'ivivanimitz';
 +
 +
# Configuracion de la supervision
 +
$supPort = '1114';
 +
 +
# Configuracion de archivos con grabaciones (Orig en nodo)
 +
$grabHay = 0;
 +
$grabAudioCalidad = 32;
 +
$grabAudioFormato = 'mp3';
 +
$grabAudioExten = 'mp3';
 +
$grabAudioCifrado = 0;
 +
$grabRutaUsaTimestamp = 1;
 +
$grabRutaOrig = '/var/lib/recordNodo/grabaciones';
 +
$grabRutaTmp = '/var/lib/recordProcesad/grabTmp';
 +
$grabRutaDest = '/var/lib/recordProcesad/grabRecord';
 +
$grabRutaError = '/var/lib/recordProcesad/grabError';
 +
$segmHay = 1;
 +
$segmUmbralTiempo = 10;
 +
$segmMargenTiempo = 5;
 +
$segmAudioCalidad = 32;
 +
$segmAudioFormato = 'mp3';
 +
$segmAudioExten = 'mp3';
 +
$segmAudioCifrado = 0;
 +
$segmRutaUsaTimestamp = 1;
 +
$segmRutaTmp = '/var/lib/recordProcesad/segmTmp';
 +
$segmRutaDest = '/var/lib/recordProcesad/segmRecord';
 +
$segmRutaError = '/var/lib/recordProcesad/segmError';
 +
 +
# Seleccion de tipos de segmento a grabar separados por comas ('' = todos)
 +
$tiposSegmentoGrabar = '';
 +
 +
# Indica si se graba ring
 +
$grabarRing = 0;
 +
 +
# Minino numero de segundos para generar segmento externo
 +
$segmExternoMinSegs = 10;
 +
 +
 
 +
 
 +
*Los campos del fichero de configuración son los siguientes:
 +
 
 +
{| class="wikitable"
 
|-
 
|-
|190||accionLog_chg_agenda||Modificar agenda|| ||idAgenda|| || ||nombre||descripción
+
!Campo !!Descripción !!Posibles valores (si aplica)
 
|-
 
|-
|195||accionLog_add_etiqueta_agente||Añadir etiqueta agente|| || || || ||nombre||descripción
+
|recordCentral.pconf|| ||  
 
|-
 
|-
|200||accionLog_del_etiqueta_agente||Borrar etiqueta agente|| ||idEtiqueta|| ||  || ||
+
|Variable a modificar||Comentarios||
 
|-
 
|-
|205||accionLog_chg_etiqueta_agente||Modificar etiqueta agente|| ||idEtiqueta|| || ||nombre||descripción
+
|$depurar||# 0: Solo alarmas en archivo log - 1: alarmas y trazas||
 
|-
 
|-
|210||accionLog_add_rel_etiqueta_agente||Añadir relación etiqueta agente|| ||idEtiqueta|| idUsuario||  || ||
+
|$soyDemonio||# 0: Arranca como proceso - 1: arranca como demonio||
 
|-
 
|-
|215||accionLog_del_rel_etiqueta_agente||Borrar relación etiqueta agente|| ||idEtiqueta|| idUsuario||  || ||
+
|$logArch =||# Archivo de log ('': salida estandar)||
 
|-
 
|-
|220||accionLog_chg_rel_etiqueta_agente||Modificar relación etiqueta agente|| ||idEtiqueta|| idUsuario||  || ||
+
|$pidArch||# Archivo para el pid (eliminando el .pid final)||
 
|-
 
|-
|225||accionLog_add_perfil||Añadir perfil|| || || ||  ||nombre||descripción
+
|$unaVezSolo||# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)||
 
|-
 
|-
|230||accionLog_del_perfil||Borrar perfil|| ||idPerfil|| ||  || ||
+
|$toBucle||# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas||
 
|-
 
|-
|235||accionLog_chg_perfil||Modificar perfil|| ||idPerfil|| || ||nombre||descripción
+
|$bytesPorSegundo||# Bytes por segundo en archivos de grabaciones||
 
|-
 
|-
|240||accionLog_add_rel_cola_perfil_bd||Añadir relación grupo ACD/perfil BD|| ||idCola|| idPerfil||prioridad||obligatorio|| 
+
|$bytesLeerBuf||# Bytes a leer en cada accceso a disco||
 
|-
 
|-
|250||accionLog_del_rel_cola_perfil_bd||Borrar relación grupo ACD/perfil BD|| ||idCola|| idPerfil||prioridad||obligatorio|| 
+
|$db||Nombre de la base de datos||
 
|-
 
|-
|260||accionLog_chg_rel_cola_perfil_bd||Modificar relación grupo ACD/perfil BD|| ||idCola|| idPerfil||prioridad||obligatorio|| 
+
|$dbHost||IP o HOST máquina base de datos de tiempo real||
 
|-
 
|-
|265||accionLog_add_cola||Añadir grupo ACD|| || || || ||nombre||descripción
+
|$dbPort||Puerto de escucha de mysql||
 
|-
 
|-
|270||accionLog_del_cola||Borrar grupo ACD|| || || || ||  ||
+
|$dbUsuario||Usuario acceso Base de datos de tiempo real||
 
|-
 
|-
|275||accionLog_chg_cola||Modificar grupo ACD|| ||idAgente|| || ||nombre||descripción
+
|$dbClave||Clave usuario acceso base de datos de tiempo real||
 
|-
 
|-
|280||accionLog_add_campanna_cola_bd||Añadir campaña a grupo ACD BD|| ||idCola||idCampanna||  || ||
+
|$supPort ||Puerto de supervision del demonio||
 
|-
 
|-
|285||accionLog_del_campanna_cola_bd||Borrar campaña de grupo ACD BD|| || ||  || || ||
+
|$grabHay||Hay fase de enrutamiento o no||
 
|-
 
|-
|290||accionLog_chg_cola_algor_predic||Cambiar algoritmo predictivo de grupo ACD|| || || || || ||
+
|$grabAudioCalidad||Calidad del audio ||
 
|-
 
|-
|300||accionLog_enviar_msj||Enviar mensaje ||tipo_msj||ambito||id_ambito||N_VAR1||N_VAR2||C_VAR3
+
|$grabAudioFormato||Formato del archivo de grabacion||
 
|-
 
|-
|305||accionLog_cerrar_sesion||Cerrar sesión|| ||idUsuario||forzado||segundos||fecha||motivo
+
|$grabAudioExten||Extensión del archivo de grabacion||
 
|-
 
|-
|310||accionLog_activa_campanna_bd||Activar campaña|| ||idCampanna||activa|| ||  ||
+
|$grabAudioCifrado||Si el archivo de grabación va cifrado ||
 
|-
 
|-
|320||accionLog_grabacion_sombra||Grabación en la sombra|| || ||  || || ||
+
|$grabRutaUsaTimestamp||||
 
|-
 
|-
|330||accionLog_add_filtro_contactos|| || || ||  || || ||
+
|$grabRutaOrig||# Directorio donde se localizan las grabaciones de llamadas||
 
|-
 
|-
|335||accionLog_del_filtro_contactos|| || || ||  || || ||
+
|$grabRutaTmp||Directorio temporal de las grabaciones de llamadas||
 
|-
 
|-
|340||accionLog_chg_filtro_contactos|| || || ||  || || ||
+
|$grabRutaDest||# Directorio Destino de  las grabaciones de llamadas||
 
|-
 
|-
|350||accionLog_add_val_filtro_contactos|| || || ||  || || ||
+
|$grabRutaError||# Directorio  de  las grabaciones de llamadas con error||
 
|-
 
|-
|355||accionLog_del_val_filtro_contactos|| || || ||  || || ||
+
|$segmHay||Hay segmentos||1 hay segmentos – 0 no hay
 
|-
 
|-
|400||accionLog_activar_contactos|| || ||idCampanna|| ||  || ||
+
|$segmUmbralTiempo||||
 
|-
 
|-
|405||accionLog_cancelar_contactos|| || ||idCampanna|| ||  || ||
+
|$segmMargenTiempo||Tiempo que se coge antes y despues del segmento||
 
|-
 
|-
|410||accionLog_orden_contactos|| || ||idCampanna|| ||  || ||
+
|$segmAudioCalidad||Calidad del audio ||
 
|-
 
|-
|415||accionLog_prioridad_contactos|| || ||idCampanna|| || || ||
+
|$segmAudioFormato||Formato del archivo de grabacion||
 
|-
 
|-
!colspan="9"|ACCIÓN LOGS PORTAL: Faltan añadir en la BD (Datos versión) y Revisar si ya existen. Poner los parámetros
+
|$segmAudioExten||Extensión del archivo de grabación||
 
|-
 
|-
|5310||accionLog_chg_acd_configuracion|| || || || || || ||
+
|$segmAudioCifrado||Si el archivo de grabación va cifrado ||1 se cifra – 0 no se cifra
 
|-
 
|-
|5315||accionLog_add_acd_finales|| || || || || || ||
+
|$segmRutaUsaTimestamp||||
 
|-
 
|-
|5320||accionLog_chg_acd_finales|| || || || || || ||
+
|$segmRutaTmp ||Ruta temporal||
 
|-
 
|-
|5325||accionLog_del_acd_finales|| || || || || || ||
+
|$segmRutaDest = ||Ruta donde se almacenan los archivos de grabación||
 
|-
 
|-
|5330||accionLog_add_acd_formularios|| || || || || || ||
+
|$segmRutaError||Ruta de los archivos de grabación con error||
 
|-
 
|-
|5335||accionLog_chg_acd_formularios|| || || || || || ||
+
|$tiposSegmentoGrabar||# Selección de tipos de segmento a grabar separados por comas ('' = todos)||
 
|-
 
|-
|5340||accionLog_del_acd_formularios||||||||||||||
+
|$grabarRing||# Indica si se graba ring||1 se graba – 0 no se graba
 
|-
 
|-
|5345||accionLog_add_acd_pausas|| || || || || || ||
+
|$segmExternoMinSegs||# Mínino número de segundos para generar segmento externo||
 
|-
 
|-
|5350||accionLog_chg_acd_pausas|| || || || || || ||
+
|}
|-
+
 
|5355||accionLog_del_acd_pausas|| || || || || || ||
+
 
|-
+
<!--
|5359||accionLog_add_cen_molticanal_texto_entrada|| || || || || || ||
+
:Se explican a continuación las variables más importantes del proceso RecordCentral:
|-
+
 
|5360||accionLog_add_acd_supercolas|| || || || || || ||
+
# Conexion de base de datos
|-
+
$db='nimitz';
|5361||accionLog_del_cen_molticanal_texto_entrada|| || || || || || ||
+
$dbHost = 'BDTR';
|-
+
$dbPort = '3306';
|5362||accionLog_udel_cen_molticanal_texto_entrada||||||||||||||
+
$dbUsuario = 'nimitz';
|-
+
$dbClave = 'ivivanimitz';
|5363||accionLog_add_cen_molticanal_texto_salida|| || || || || || ||
+
 
|-
+
# Configuracion de archivos con grabaciones (Orig en nodo)
|5364||accionccionLog_chg_cen_molticanal_texto_salida|| || || || || || ||
+
$grabHay = 0;
|-
+
$grabAudioCalidad = 32;
|5365||accionLog_chg_acd_supercolas|| || || || || || ||
+
$grabAudioFormato = 'ogg';
|-
+
$grabAudioExten = 'ogg';
|5366||accionLog_udel_cen_molticanal_texto_salida|| || || || || || ||
+
$grabAudioCifrado = 0;
|-
+
$grabRutaUsaTimestamp = 1;
|5367||accionLog_chg_cen_molticanal_texto_entrada|| || || || || || ||
+
$grabRutaOrig = '/var/lib/recordNodo/grabaciones';
|-
+
$grabRutaTmp = '/var/lib/recordProcesad/grabTmp';
|5368||accionLog_del_cen_molticanal_texto_salida|| || || || || || ||
+
$grabRutaDest = '/var/lib/recordProcesad/grabRecord';
|-
+
$grabRutaError = '/var/lib/recordProcesad/grabError';
|5370||accionLog_del_acd_supercolas|| || || || || || ||
+
$segmHay = 1;
|-
+
$segmUmbralTiempo = 10;
|5375||accionLog_udel_acd_supercolas|| || || || || || ||
+
$segmMargenTiempo = 5;
 +
$segmAudioCalidad = 32;
 +
$segmAudioFormato = 'ogg';
 +
$segmAudioExten = 'ogg';
 +
$segmAudioCifrado = 0;
 +
$segmRutaUsaTimestamp = 1;
 +
$segmRutaTmp = '/var/lib/recordProcesad/segmTmp';
 +
$segmRutaDest = '/var/lib/recordProcesad/segmRecord';
 +
$segmRutaError = '/var/lib/recordProcesad/segmError';
 +
 
 +
# Seleccion de tipos de segmento a grabar separados por comas ('' = todos)
 +
$tiposSegmentoGrabar = '';
 +
 
 +
# Indica si se graba ring
 +
$grabarRing = 0;
 +
 
 +
-->
 +
 
 +
* Podremos examinar los logs del proceso en '''/var/log/recordCentral.log'''
 +
<!-- En la versión 3.6.0. del instalador se adjuntan los siguientes archivos en el paquete recordCentral:
 +
 
 +
borraGrabaciones.pconf: Debe colocarse en /etc/MDtel y contiene los datos de acceso a BBDD así como los días de caducidad de las grabaciones.
 +
borraGrabaciones.pl: El script. Se ejecuta con el archivo de configuración como parámetro (mueveGrabaciones.pl /etc/MDtel/mueveGrabaciones.pconf)
 +
borraGrabaciones: Fichero cron. Contiene la programación del script. Debe colocarse en /etc/cron.d
 +
-->
 +
 
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
 +
 
 +
==== 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 ''VIVA''it'''.
 +
 
 +
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 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:
 +
{| class="wikitable"
 
|-
 
|-
|5380||accionLog_add_acd_vdn|| || || || || || ||
+
! Parámetro  !! Descripción
 
|-
 
|-
|5385||accionLog_chg_acd_vdn|| || || || || || ||
+
| SIS/ver || Versión del proceso
 
|-
 
|-
|5390||accionLog_del_acd_vdn|| || || || || || ||
+
| SIS/inic  || Fecha de arranque del proceso
 
|-
 
|-
|5395||accionLog_udel_acd_vdn|| || || || || || ||
+
| SIS/amarmas || Alarmas desde arranque
 
|-
 
|-
|5396||accionLog_add_cen_vdn|| || || || || || ||
+
| SIS/ultAlar || Fecha de última alarma
 
|-
 
|-
|5397||accionLog_chg_cen_vdn|| || || || || || ||
+
| MYSQL/cnx || Conectado (1) a MySQL
 
|-
 
|-
|5398||accionLog_del_cen_vdn|| || || || || || ||
+
| REC/llamNum || Llamadas procesadas
 
|-
 
|-
|5399||accionLog_udel_cen_vdn|| || || || || || ||
+
| REC/llamErr || Llamadas con error
 
|-
 
|-
|5400||accionLog_add_campos|| || || || || || ||
+
| REC/segmNum || Segmentos procesados
 
|-
 
|-
|5405||accionLog_chg_campos|| || || || || || ||
+
| REC/segmErr || Segmentos con error
|-
+
|}
|5410||accionLog_del_campos|| || || || || || ||
+
 
|-
+
Como complemento a los diagnósticos:
|5415||accionLog_add_categorias|| || || || || || ||
+
* Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/recordNodo.pconf'''
|-
+
:Se muestra a continuación el fichero de configuración:
|5420||accionLog_chg_categorias|| || || || || || ||
+
|-
+
#
|5425||accionLog_del_categorias|| || || || || || ||
+
# Configuracion de recordNodo.pl
|-
+
#
|5430||accionLog_chg_com_configuracion|| || || || || || ||
+
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
|-
+
$depurar = 1;
|5435||accionLog_add_nodos|| || || || || || ||
+
|-
+
# 0: Arranca como proceso - 1: arranca como demonio
|5440||accionLog_chg_nodos|| || || || || || ||
+
$soyDemonio = 1;
|-
+
|5445||accionLog_del_nodos|| || || || || || ||
+
# Archivo de log ('': salida estandar)
|-
+
$logArch = '/var/log/record/recordNodo.log';
|5450||accionLog_udel_nodos|| || || || || || ||
+
|-
+
# Archivo para el pid (eliminando el .pid final)
|5455||accionLog_add_sedes|| || || || || || ||
+
$pidArch = '/var/run/record/recordNodo';
|-
+
|5460||accionLog_chg_sedes|| || || || || || ||
+
# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
|-
+
$unaVezSolo = 0;
|5465||accionLog_del_sedes|| || || || || || ||
+
|-
+
# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
|5470||accionLog_udel_sedes|| || || || || || ||
+
$toBucle = 5;
|-
+
|5475||accionLog_add_dat_sincroniza|| || || || || || ||
+
# Tiempo de guarda en segundos desde D_HORA_FIN hasta que se procesa llamada
|-
+
$toProcesar = 30;
|5480||accionLog_chg_dat_sincroniza|| || || || || || ||
+
|-
+
# Bytes por segundo en archivos de grabaciones
|5485||accionLog_add_extensiones|| || || || || || ||
+
$bytesPorSegundo = 16000;
|-
+
|5490||accionLog_chg_extensiones|| || || || || || ||
+
# Bytes a leer en cada accceso a disco
|-
+
$bytesLeerBuf = 1048576;
|5495||accionLog_del_extensiones|| || || || || || ||
+
|-
+
# Conexion de base de datos
|5500||accionLog_udel_extensiones|| || || || || || ||
+
$db='nimitz';
|-
+
$dbHost = 'BDTR';
|5505||accionLog_add_facilidades|| || || || || || ||
+
$dbPort = '3306';
|-
+
$dbUsuario = 'nimitz';
|5510||accionLog_chg_facilidades|| || || || || || ||
+
$dbClave = 'ivivanimitz';
|-
+
|5515||accionLog_del_facilidades|| || || || || || ||
+
# Configuracion de la supervision
|-
+
$supPort = '1113';
|5520||accionLog_add_locuciones|| || || || || || ||
+
|-
+
# Quien es mi nodo para filtrar grabaciones
|5525||accionLog_chg_locuciones|| || || || || || ||
+
$miNodo = 2;
|-
+
|5530||accionLog_del_locuciones|| || || || || || ||
+
# Directorio donde se localizan las grabaciones
|-
+
$grabRutaOrig = '/var/spool/asterisk/monitor';
|5535||accionLog_add_musica|| || || || || || ||
+
$grabRutaDest = '/var/lib/recordNodo/grabaciones';
|-
+
$grabRutaError = '/var/lib/recordNodo/grabError';
|5540||accionLog_chg_musica|| || || || || || ||
+
$grabRutaUsaTimestamp = 1;
|-
+
|5545||accionLog_del_musica|| || || || || || ||
+
# Tiempo en segundos limite a truncar en las grabaciones (0=sin limite)
|-
+
$grabLimiteSegs = 0;
|5550||accionLog_add_permisos|| || || || || || ||
+
|-
+
# Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminacion
|5555||accionLog_chg_permisos|| || || || || || ||
+
$segmEliminarGrabacionTrato = 1;
 +
$patronEliminarGrabacion = '/etc/MDtel/null.bin';
 +
 +
 
 +
*A continuación se indican los campos del fichero:
 +
 
 +
 
 +
{| class="wikitable"
 
|-
 
|-
|5560||accionLog_del_permisos|| || || || || || ||
+
!Campo !!Descripción !!Posibles valores (si aplica)
 
|-
 
|-
|5565||accionLog_add_plantillas|| || || || || || ||
+
|$depurar||# 0: Solo alarmas en archivo log - 1: alarmas y trazas||
 
|-
 
|-
|5570||accionLog_chg_plantillas|| || || || || || ||
+
|$soyDemonio||# 0: Arranca como proceso - 1: arranca como demonio||
 
|-
 
|-
|5575||accionLog_del_plantillas|| || || || || || ||
+
|$logArch||# Archivo de log ('': salida estandar)||
 
|-
 
|-
|5580||accionLog_add_puestos_extensiones|| || || || || || ||
+
|$pidArch||# Archivo para el pid (eliminando el .pid final)||
 
|-
 
|-
|5585||accionLog_chg_puestos_extensiones|| || || || || || ||
+
|$unaVezSolo||# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)||
 
|-
 
|-
|5590||accionLog_del_puestos_extensiones|| || || || || || ||
+
|$toBucle||# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas||
 
|-
 
|-
|5595||accionLog_des_puestos_extensiones|| || || || || || ||
+
|$toProcesar||# Tiempo de guarda en segundos desde D_HORA_FIN hasta que se procesa llamada||
 
|-
 
|-
|5600||accionLog_add_usuarios|| || || || || || ||
+
|$bytesPorSegundo||# Bytes por segundo en archivos de grabaciones||
 
|-
 
|-
|5605||accionLog_chg_usuarios|| || || || || || ||
+
|$bytesLeerBuf||# Bytes a leer en cada accceso a disco||
 
|-
 
|-
|5610||accionLog_del_usuarios|| || || || || || ||
+
|$db||Nombre de la base de datos||
 
|-
 
|-
|5615||accionLog_udel_usuarios|| || || || || || ||
+
|$dbHost||IP o HOST máquina base de datos de tiempo real||
 
|-
 
|-
|5620||accionLog_chg_licencias|| || || || || || ||
+
|$dbPort||Puerto de escucha de mysql||
 
|-
 
|-
!colspan="9"|ACCIONES DE LOS EJES
+
|$dbUsuario||Usuario acceso Base de datos de tiempo real||
 
|-
 
|-
|5705||accionLog_chg_Eje|| || || || || || ||
+
|$dbClave||Clave usuario acceso base de datos de tiempo real||
 
|-
 
|-
|5710||accionLog_out_Eje_Padre|| || || || || || ||
+
|$supPort||Puerto de supervision del demonio||
 
|-
 
|-
|5715||accionLog_del_Eje|| || || || || || ||
+
|$miNodo||# Quien es mi nodo para filtrar grabaciones||
 
|-
 
|-
|5720||accionLog_add_Eje||  ||  ||  || || || ||
+
|$grabRutaOrig||# Directorio donde se localizan las grabaciones||
 
|-
 
|-
|5725||accionLog_set_Eje_Padre|| || || || || || ||
+
|$grabRutaDest ||Directorio destino de las grabaciones procesadas||
 
|-
 
|-
|5730||accionLog_add_acd_pausas_usuarios|| || || || || || ||
+
|$grabRutaError||Directorio destino de las grabacionescon error||
 
|-
 
|-
|5735||accionLog_del_acd_pausas_usuarios|| || || || || || ||
+
|$grabRutaUsaTimestamp||||
 
|-
 
|-
|5740||accionLog_add_centros_dispositivos|| || || || || || ||
+
|$grabLimiteSegs||# Tiempo en segundos limite a truncar en las grabaciones (0=sin limite)||
 
|-
 
|-
|5745||accionLog_chg_centros_dispositivos|| || || || || || ||
+
|$segmEliminarGrabacionTrato||# Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminacion||1 se procesa – 0 no se procesa
 
|-
 
|-
|5750||accionLog_del_centros_dispositivos|| || || || || || ||
+
|$patronEliminarGrabacion||Patron de eliminacion||'/etc/MDtel/null.bin'--> para utilizar '''silencio'''
 +
'/etc/MDtel/pito.slin'--> para utilzar un '''pitido''' (va asociado al fichero pito.slin).
 
|-
 
|-
|5755||accionLog_add_centros_extensiones|| || || || || || ||
+
|}
|-
+
 
|5760||accionLog_chg_centros_extensiones|| || || || || || ||
+
<!--
|-
+
:Se muestran a continuación las variables que son modificadas con mayor frecuencia:
|5765||accionLog_del_centros_extensiones|| || || || || || ||
+
# Conexion de base de datos
|-
+
$db='nimitz';
|5770||accionLog_add_acd_usuarios|| || || || || || ||
+
$dbHost = 'BDTR';
|-
+
$dbPort = '3306';
|5775||accionLog_chg_acd_usuarios||||||||||||||
+
$dbUsuario = 'nimitz';
|-
+
$dbClave = 'ivivanimitz';
|5780||accionLog_add_relacion_campos|| || || || || || ||
+
 
|-
+
# Quien es mi nodo para filtrar grabaciones
|5785||accionLog_del_relacion_campos|| || || || || || ||
+
$miNodo = 1;
|-
+
 
|5786||accionLog_chg_grabacion_configuracion|| || || || || || ||
+
# Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminación
|-
+
$segmEliminarGrabacionTrato = 1;
|5787||accionLog_add_campannas|| || || || || || ||
+
$patronEliminarGrabacion = '/etc/MDtel/null.bin';
|-
+
 
|5788||accionLog_chg_campannas|| || || || || || ||
+
 
|-
+
 
|5789||accionLog_del_campannas|| || || || || || ||
+
-->
|-
+
* Podremos examinar los logs del proceso en '''/var/log/recordNodo.log'''
|5790||accionLog_udel_campannas|| || || || || || ||
+
 
|-
+
 
|5791||accionLog_add_lista_contactos|| || || || || || ||
+
 
|-
+
==== Sercen ====
|5792||accionLog_chg_lista_contactos|| || || || || || ||
+
 
|-
+
Sercen (Servicios Centrales) es un demonio de VIVAit que provee servicios centralizados
|5793||accionLog_del_lista_contactos|| || || || || || ||
+
a muchos elementos de la arquitectura. Sirve para identificar a los usuarios y garantizar
|-
+
que los mismos sean quienes dicen ser.
|5794||accionLog_udel_lista_contactos|| || || || || || ||
+
Puede haber varias instancias en el, y diferentes servicios pueden estar en diferentes
|-
+
Sercen
|5795||accionLog_add_lista_llamames|| || || || || || ||
+
 
|-
+
 
|5796||accionLog_chg_lista_llamames|| || || || || || ||
+
Ejemplos de servicios:
|-
+
 
|5797||accionLog_del_lista_llamames|| || || || || || ||
+
'''- Autenticación, de factor simple o doble factor'''
|-
+
 
|5798||accionLog_udel_lista_llamames|| || || || || || ||
+
'''- Integración con proveedores de autenticación'''
|-
+
 
|5799||accionLog_add_lista_robinson|| || || || || || ||
+
'''- Click2talk (Demonio dentro de Vivait)'''
|-
+
 
|5800||accionLog_chg_lista_robinson|| || || || || || ||
+
 
|-
+
Sercen permite autenticar un usuario (simple factor o doble factor), utilizando para ello
|5801||accionLog_del_lista_robinson|| || || || || || ||
+
la base de datos de vivait y/u otro mecanismo externo, como puede ser el directorio
|-
+
activo de Microsoft.
|5802||accionLog_udel_lista_robinson|| || || || || || ||
+
 
|-
+
SerCen se relaciona con :
|5803||accionLog_add_contacto|| || || || || || ||
+
 
|-
+
 
|5804||accionLog_chg_contacto|| || || || || || ||
+
'''- BBDD'''
|-
+
 
|5805||accionLog_del_contacto|| || || || || || ||
+
'''- Asterisk (para el click2talk)'''
|-
+
 
|5806||accionLog_udel_contacto|| || || || || || ||
+
'''- VIVAit Meet (para por ejemplo las funciones “botón colaborar” y ”Recursos
|-
+
compartidos”.'''
|5807||accionLog_import_contactos|| || || || || || ||
+
 
|-
+
'''- Con los portales a los que proporciona los servicios vía webservice'''
|5808'''(*)'''||accionLog_add_contacto_campanna|| || || || || || ||
+
 
|-
+
 
|'''''5818'''''||accionLog_chg_contacto_campanna|| || || || || || ||
+
 
|-
+
===== Interfaz para autenticación (app-webfon / serCen) =====
|5809||accionLog_chk_exist_contacto_campanna|| || || || || || ||
+
 
|-
+
 
|5810||accionLog_add_contacto_lista|| || || || || || ||
+
 
|-
+
 
|5811||accionLog_chk_exist_contacto_lista|| || || || || || ||
+
 
|-
+
Este interfaz permite autenticar un usuario (simple factor o doble factor), utilizando para ello la base de datos de vivait y/u otro mecanismo externo, como puede ser el directorio activo de Microsoft. El objetivo es que app-webfon obtenga un token que debe incluirse en las comunicaciones con el resto de elementos para que estos conozcan que las solicitudes proceden de un usuario autenticado. Este token también puede utilizarse para que otras aplicaciones puedan se iniciadas desde app-webfon y no se requiera de un proceso específico de autenticación para cada aplicación. De modo recíproco, app- webfon debe soportar el ser invocado con un token y, en tal caso, considerar que el usuario ya está autenticado.
|5812||accionLog_del_contacto_lista|| || || || || || ||
+
 
 +
 
 +
Por ello, se asume que cada usuario conoce su clave. Independientemente de qui én gestione la clave, esta puede tener asociados periodos de expiración y de caducidad. Cuando finaliza el periodo de expiración, el usuario tiene que cambiar la clave obligatoriamente para poder acceder a sus credenciales (token). Tras la caducidad, ya no puede obtener credenciales válidas.
 +
 
 +
 
 +
Cuando la autenticación utiliza las claves almacenadas en la base de datos vivait, serCen permite cambiar la clave. Si la validación de la clave se apoya en mecanismos externos (como puede ser el directorio activo), entonces serCen no soporta el cambio de claves, informando de ello en las respuestas correspondientes a los comandos de autenticación.
 +
 
 +
 
 +
 
 +
 
 +
===== Comandos de SerCen =====
 +
 
 +
 
 +
Los diferentes comandos de SerCen son:
 +
 
 +
 
 +
{| class="wikitable"
 
|-
 
|-
|5813||accionLog_add_estrategia|| || || || || || ||
+
! COMANDOS !! DESCRIPCIÓN
 
|-
 
|-
|5814||accionLog_chg_estrategia|| || || || || || ||
+
| autenticar1 || Para autenticar en base al primer factor (usuario y clave).
 
|-
 
|-
|5815||accionLog_del_estrategia|| || || || || || ||
+
| autenticar2 || Para, si procede, autenticar en base al segundo factor (pin adicional).
 
|-
 
|-
|5816||accionLog_udel_estrategia|| || || || || || ||
+
| autenticartokenaad || Autenticar empleando un token de "azure active directory"
 
|-
 
|-
|5817'''(*)'''||accionLog_chk_exist_contacto|| || || || || || ||
+
| validarToken || Para autenticar a un usuario en base a un token suministrado por otra aplicación
 
|-
 
|-
|'''''5818'''''||accionLog_add_telefono_robinson|| || || || || || ||
+
| revalidarToken || Para ampliar el periodo de expiración de un token válido.
 
|-
 
|-
|5819||accionLog_chg_telefono_robinson|| || || || || || ||
+
| revocarToken || Para que un token deje de ser válido.
 
|-
 
|-
|5820||accionLog_del_telefono_robinson|| || || || || || ||
+
| cambiarClave || Permite que una clave pueda se cambiada. Esto es posible cuando el usuario ha sido autenticado y, además, la clave tiene que estar siendo gestionada por vivait. Este cambio no es posible, por ejemplo, si se trata de una clave validada por un directorio activo.
|-
+
|}
|5821||accionLog_chk_exist_robinson_lista|| || || || || || ||
+
 
|-
+
 
|5822||accionLog_add_dat_click2call|| || || || || || ||
+
 
|-
+
====== Comandos autenticar1 ======
|5823||accionLog_chg_dat_click2call|| || || || || || ||
+
 
|-
+
Comandos autenticar1 y respuestas posibles:
|5824||accionLog_del_dat_click2call|| || || || || || ||
+
 
 +
autenticar1. Autenticación primer factor.
 +
 
 +
url (POST): https://<servidor_webfon>/sercen/postautenticar1
 +
 
 +
datos de entrada:    '''{"cuenta": "fulano","clave$1aA": "dificil","aplicacion": "webfon","expira": 7200,"clvCambiar": "masdificil$1aA"}'''
 +
 
 +
* "expira" es opcional y siempre posible. Permite solicitar un periodo de expiración (segs) para el token devuelto.
 +
 
 +
*  "clvCambiar" es opcional y solo se tiene en cuenta si no hay doble factor. Permite cambiar la clave del usuario, si es autenticado.
 +
 
 +
 
 +
'''Ejemplos de posibles respuestas:'''
 +
 
 +
 
 +
{| class="wikitable"
 
|-
 
|-
|5825||accionLog_chk_exist_dat_click2call|| || || || || || ||
+
! Ejemplo !! Respuesta
 
|-
 
|-
|5826||accionLog_add_aplicaciones|| || || || || || ||
+
| ejRes1 || {"errorNum": 101,"errorCad": "Clave incorrecta"}
 
|-
 
|-
|5827||accionLog_chg_aplicaciones|| || || || || || ||
+
| ejRes2 || {"errorNum": 115,"errorCad": "Clave caducada"}
 
|-
 
|-
|5828||accionLog_del_aplicaciones|| || || || || || ||
+
| ejRes3 || {"errorNum": 116,"errorCad": "Clave expirada","dobleFactor": "no","clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
 
|-
 
|-
|5829||accionLog_add_cen_destinos|| || || || || || ||
+
| ejRes4 || ejRes4: {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "email","clvExpira": 86400}
 
|-
 
|-
|5830||accionLog_chg_cen_destinos|| || || || || || ||
+
| ejRes5 || {"errorNum":0,"errorCad":"OK","token": "1234567890","dobleFactor": "email","clvExpira": 86400}
 
|-
 
|-
|5831||accionLog_del_cen_destinos|| || || || || || ||
+
| ejRes6 || {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "no","token2": "0987654321","expira": 3600,"clvExpira": 86400,"clvPuedeCambiar": true,"clvHaCambiado": true,"clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
|-
+
|}
|5832||accionLog_add_acd_monitores|| || || || || || ||
+
 
|-
+
 
|5833||accionLog_chg_acd_monitores|| || || || || || ||
+
Este comando se invoca para autenticar al usuario en base a cuenta y clave. Opcionalmente, se soporta un doble factor en base a un pin que se comunica al usuario mediante correo electrónico u otro medio.
|-
+
 
|5834||accionLog_del_acd_monitores|| || || || || || ||
+
El campo "expira" en la respuesta informa sobre el token devuelto. Dicho token es válido durante un periodo que se expresa en segundos a transcurrir desde el momento en que se informa.
|-
+
 
|5835||accionLog_add_campos_monitor_8|| || || || || || ||
+
El campo "clvExpira" en la respuesta informa en segs. sobre cuando va a expirar la clave introducida y validada (errorNum=0). Si devuelve cero o no devuelve nada, quiere decir que no va a expirar por estar configurado de esa manera o porque es un autenticación ldap.
|-
+
 
|5836||accionLog_chg_campos_monitor_8|| || || || || || ||
+
Al invocar este comando, app-webfon solicita, opcionalmente (campo "expira"), un periodo (en segundos) cuyo valor debe formar parte de su configuración. El valor finalmente válido es el que aparece con el mismo nombre en la respuesta (si finalmente es positiva) y si no hay doble factor.
|-
+
 
|5837||accionLog_del_campos_monitor_8|| || || || || || ||
+
Es responsabilidad de app-webfon el efectuar una solicitud para revalidar el token, mediante un procedimiento que se describirá posteriormente, tantas veces como considere necesario.
|-
+
 
|5838||accionLog_add_agendas|| || || || || || ||
+
 
|-
+
 
|5839||accionLog_chg_agendas|| || || || || || ||
+
En lo que se refiere a las posibles respuestas a autenticar1, pueden darse varios casos:
|-
+
 
|5840||accionLog_del_agendas|| || || || || || ||
+
Se produce un error: ejRes1 y ejRes2.
|-
+
 
|5841||accionLog_add_agendas_telefonos|| || || || || || ||
+
La clave ha expirado y no hay doble factor (ejRes3). Se invita a cambiar la clave invocando de nuevo a autenticar1 con "clvCambiar", para lo cuál se aportan datos de la complejidad requerida.
|-
 
|5842||accionLog_chg_agendas_telefonos|| || || || || || ||
 
|-
 
|5843||accionLog_del_agendas_telefonos|| || || || || || ||
 
|-
 
|5844||accionLog_add_agendas_campos_cliente|| || || || || || ||
 
|-
 
|5845||accionLog_chg_agendas_campos_cliente|| || || || || || ||
 
|-
 
|5846||accionLog_del_agendas_campos_cliente|| || || || || || ||
 
|-
 
!colspan="9"|GRUPOS DE SALTO
 
|-
 
|5847||accionLog_add_grupos_salto|| || || || || || ||
 
|-
 
|5848||accionLog_chg_grupos_salto|| || || || || || ||
 
|-
 
|5849||accionLog_del_grupos_salto|| || || || || || ||
 
|-
 
|5850||accionLog_udel_grupos_salto|| || || || || || ||
 
|-
 
!colspan="9"|GRUPOS DE CAPTURA
 
|-
 
|5851||accionLog_add_grupos_captura|| || || || || || ||
 
|-
 
|5852||accionLog_chg_grupos_captura|| || || || || || ||
 
|-
 
|5853||accionLog_del_grupos_captura|| || || || || || ||
 
|-
 
|5854||accionLog_udel_grupos_captura|| || || || || || ||
 
|-
 
|5855||accionLog_add_grupos_locuciones|| || || || || || ||
 
|-
 
|5856||accionLog_chg_grupos_locuciones|| || || || || || ||
 
|-
 
|5857||accionLog_del_grupos_locuciones|| || || || || || ||
 
|-
 
|5858||accionLog_udel_grupos_locuciones|| || || || || || ||
 
|-
 
!colspan="9"|INFORMES DE CALIDAD
 
|-
 
|5859||accionLog_add_informes_calidad|| || || || || || ||
 
|-
 
|5860||accionLog_chg_informes_calidad|| || || || || || ||
 
|-
 
|5861||accionLog_del_informes_calidad|| || || || || || ||
 
|-
 
|5862||accionLog_udel_informes_calidad|| || || || || || ||
 
|-
 
!colspan="9"|En todas se inserta el idUsuario, TAplicacion.CALL_CENTER, TComponentes.PORTAL_DE_ADMINISTRADOR, Código de la acción, "ACD_INFORME_CALIDAD", el id del informe
 
|-
 
!colspan="9"|PREGUNTAS DE CALIDAD
 
|-
 
|5863||accionLog_add_preguntas_calidad|| || || || || || ||
 
|-
 
|5864||accionLog_chg_preguntas_calidad|| || || || || || ||
 
|-
 
|5865||accionLog_del_preguntas_calidad|| || || || || || ||
 
|-
 
|5866||accionLog_udel_preguntas_calidad|| || || || || || ||
 
|-
 
!colspan="9"|En todas se inserta el idUsuario, TAplicacion.CALL_CENTER, TComponentes.PORTAL_DE_ADMINISTRADOR, Código de la acción, "ACD_PREGUNTAS_CALIDAD", el id de la pregunta
 
|-
 
!colspan="9"|SALAS MEET
 
|-
 
|5867||accionLog_add_sala_meet|| || || || || || ||
 
|-
 
|5868||accionLog_add_perfil_sala_meet|| || || || || || ||
 
|-
 
|5869||accionLog_add_grupo_sala_meet|| || || || || || ||
 
|-
 
|5870||accionLog_chg_sala_meet|| || || || || || ||
 
|-
 
|5871||accionLog_chg_perfil_sala_meet|| || || || || || ||
 
|-
 
|5872||accionLog_chg_grupo_sala_meet|| || || || || || ||
 
|-
 
|5873||accionLog_del_sala_meet|| || || || || || ||
 
|-
 
|5874||accionLog_del_perfil_sala_meet|| || || || || || ||
 
|-
 
|5875||accionLog_del_grupo_sala_meet|| || || || || || ||
 
|-
 
|5876||accionLog_udel_sala_meet|| || || || || || ||
 
|-
 
|5877||accionLog_udel_perfil_sala_meet|| || || || || || ||
 
|-
 
|5878||accionLog_udel_grupo_sala_meet|| || || || || || ||
 
|-
 
!colspan="9"|ALERTAS
 
|-
 
|7000||accionLog_add_ale_entidades|| || || || || || ||
 
|-
 
|7005||accionLog_chg_ale_entidades|| || || || || || ||
 
|-
 
|7010||accionLog_del_ale_entidades|| || || || || || ||
 
|-
 
|7015||accionLog_udel_ale_entidades|| || || || || || ||
 
|-
 
|7020||accionLog_add_ale_servicios|| || || || || || ||
 
|-
 
|7025||accionLog_chg_ale_servicios|| || || || || || ||
 
|-
 
|7030||accionLog_del_ale_servicios|| || || || || || ||
 
|-
 
|7035||accionLog_udel_ale_servicios|| || || || || || ||
 
|-
 
|7040||accionLog_add_ale_destinos|| || || || || || ||
 
|-
 
|7045||accionLog_chg_ale_destinos|| || || || || || ||
 
|-
 
|7050||accionLog_del_ale_destinos|| || || || || || ||
 
|-
 
|7055||accionLog_udel_ale_destinos|| || || || || || ||
 
|-
 
|7060||accionLog_add_ale_autorizadas|| || || || || || ||
 
|-
 
|7065||accionLog_chg_ale_autorizadas|| || || || || || ||
 
|-
 
|7070||accionLog_del_ale_autorizadas|| || || || || || ||
 
|-
 
|7075||accionLog_udel_ale_autorizadas|| || || || || || ||
 
|-
 
!colspan="9"|Acciones comunes válidas para todas las situaciones si utilizamos el campo C_TABLA
 
|-
 
|50000||accionLog_add_registro|| || || || || || ||
 
|-
 
|50005||accionLog_chg_registro|| || || || || || ||
 
|-
 
|50010||accionLog_del_registro|| || || || || || ||
 
|-
 
|50015||accionLog_udel_registro|| || || || || || ||
 
|}
 
  
=== Procesos propios ===
+
La clave es válida y hay doble factor en ejRes4.
  
==== bdCentral ====
+
La clave es válida y hay doble factor "totp" con usuario no enrolado en ejRes6. Se incluye un código QR que permite enrolar al usuario
  
El proceso ''bdCentral.sh'' es el encargado de realizar la copia de seguridad. Tiene un archivo de configuración ''bdCentral.conf'' el cual puede encontrarse en la ruta '''/etc/MDtel/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".
+
La clave es válida y no hay doble factor en ejRes6. El usuario ha sido autenticado. Se devuelven "token" y "token2". También se informa sobre si es posible cambiar la clave ("clvPuedeCambiar") y sobre sus requerimientos de complejidad. Si el
 +
comando autenticar1 hubiese incluido un cambio de clave mediante el campo "clvCambiar" y este cambio hubiese sido completado, se devolverá un booleano "clvHaCambiado" para informar de ello.
  
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.
+
====== Comandos autenticar2 ======
 +
 
 +
 
 +
Comandos autenticar2 y respuestas posibles:
 +
 
 +
autenticar2. Autenticación doble factor.
 +
 
 +
url (POST): https://<servidor_webfon>/sercen/postautenticar2
 +
 
 +
datos de entrada: '''{"token": "1234567890","pin": "1234","expira": 7200,"clvCambiar": "masdificil$1aA"}'''
  
Por defecto la programación vienen comentada por lo que será necesario activarlo.
+
* "expira" es opcional.
 +
* "clvCambiar" es opcional. Permite cambiar la clave del usuario, si es autenticado.
  
Para que se roten los logs hay que copiar el fichero bdCentral.logrotate a /etc/logrotate.d (como bdCentral)
 
La ruta donde se encuentran los logs es la siguiente: '''/var/log/myAcdSuperv.log'''
 
  
Fichero de configuación:
+
'''Ejemplos de posibles respuestas:'''
  
ARCH_LOG=/var/log/bdCentral.log
 
 
BDHOST=localhost
 
BDUSU=adminNimitz
 
BDCLAVE=imdtelnimitz
 
BDRUTA=/var/lib/MDtel/backupBDnimitz
 
 
 
IGNORE_TABLAS=(nimitz.DAT_ACD_RASTREO  nimitz.DAT_ACUMULADOS_AGENTES  nimitz.DAT_ACUMULADOS_AGENTES_COLAS
 
nimitz.DAT_ACUMULADOS_AGENTES_PAUSAS  nimitz.DAT_ACUMULADOS_AGENTES_VDN  nimitz.DAT_ACUMULADOS_COLAS 
 
nimitz.DAT_ACUMULADOS_VDN  nimitz.DAT_ACUMULADOS_VDN_COLAS  nimitz.DAT_CONTACTOS_PREPARADOS 
 
nimitz.DAT_IVR_INTERACCIONES  nimitz.DAT_IVR_NODOS  nimitz.DAT_IVR_PAGOS_TARJETA  nimitz.DAT_IVR_RESULT_ENCUESTAS
 
nimitz.DAT_LLAMADAS  nimitz.DAT_LOG  nimitz.DAT_MUESTRAS_COLAS  nimitz.DAT_SEGMENTOS  nimitz.DAT_SESIONES_AGENTES 
 
nimitz.DAT_SESIONES_AGENTES_COLAS  nimitz.DAT_SESIONES_AGENTES_PAUSAS  nimitz.DAT_SESIONES_AGENTES_VDN 
 
nimitz.DAT_SINCRONIZA  nimitz.DAT_TR_ACD_EXTENSIONES  nimitz.DAT_TR_ACD_EXTEN_COLA  nimitz.DAT_TR_COLAS 
 
nimitz.DAT_VALORACIONES  nimitz.DAT_ACD_RASTREO  nimitz.DAT_ACUMULADOS_AGENTES_COLAS 
 
nimitz.DAT_ACUMULADOS_AGENTES_PAUSAS  nimitz.DAT_ACUMULADOS_AGENTES_VDN  nimitz.DAT_ACUMULADOS_COLAS 
 
nimitz.DAT_ACUMULADOS_VDN  nimitz.DAT_LLAMADAS  nimitz.DAT_MUESTRAS_COLAS  nimitz.DAT_SEGMENTOS 
 
nimitz.DAT_SESIONES_AGENTES  nimitz.DAT_SESIONES_AGENTES_COLAS  nimitz.DAT_SESIONES_AGENTES_PAUSAS 
 
nimitz.DAT_SESIONES_AGENTES_VDN  nimitz.DAT_TR_ACD_EXTENSIONES  nimitz.DAT_TR_ACD_EXTEN_COLA  nimitz.DAT_TR_COLAS 
 
nimitz.DAT_VALORACIONES)
 
  
*A continuación se explica los campos mas relevantes del fichero de configuración bdCentral.conf.
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
!Campo !!Descripción !!Posibles valores (si aplica)
+
! Ejemplo !! Respuesta
 +
|-
 +
| ejRes1 || {"errorNum": 102,"errorCad": "Pin incorrecto"}
 +
|-
 +
| ejRes2 || {"errorNum": 115,"errorCad": "Clave caducada"}
 
|-
 
|-
|ARCH_LOG|| /RUTA/FICHERO de log del proceso||
+
| ejRes3 || {"errorNum": 116,"errorCad": "Clave expirada","clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
|-
 
|BDHOST||IP o HOST máquina base de datos de tiempo real||
 
|-
 
|BDUSU||Usuario acceso Base de datos de tiempo real||
 
|-
 
|BDCLAVE||Clave usuario acceso base de datos tiempo real||
 
|-
 
|BDRUTA||Ruta donde se depositará el dump de la base de datos||
 
|-
 
|IGNORE_TABLAS||Tablas de las que no queramos hacer backup||
 
 
|-
 
|-
 +
| ejRes4 || ejRes4: {"errorNum": 0,"errorCad": "OK","token2": "0987654321","expira": 3600,"clvExpira": 86400,"clvPuedeCambiar": true,"clvHaCambiado": true,"clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
 
|}
 
|}
  
  
<br><br>
+
Este comando se invoca para autenticar en base a un segundo factor: pin enviado por un medio de transporte independiente.
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
==== bdNodo ====
+
El campo "expira" en la respuesta informa sobre el token enviado y token2 devuelto. Dichos token son válidos durante un periodo que se expresa en segundos a transcurrir desde el momento en que se informa.
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, este archivo puede encontrarse en la ruta '''/etc/MDtel/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:
+
El campo "clvExpira" en la respuesta informa en segs. sobre cuando va a expirar la clave introducida y validada (errorNum=0). Si devuelve cero o no devuelve nada, quiere decir que no va a expirar por estar configurado de esa manera o porque es un autenticación ldap.
 +
 
 +
 
 +
El campo que requiere explicación adicional es "token2". "token" puede ser traspasado a otras aplicaciones para evitar procesos de autenticación, pero esas aplicaciones (a las que no debe pasarse el valor de "token2") no podrán realizar operaciones relacionadas con el propio token, como puede ser revocarlo, cuando el usuario cierre el app-webfon. Es decir, el valor de "token2" sólo se requiere para operaciones de gestión del propio token. Sin "token2" tampoco es posible ejecutar el comando "cambiarClave".
 +
 
 +
 
 +
En lo que se refiere a las posibles respuestas a autenticar2, pueden darse varios casos:
 +
 
 +
 
 +
Se produce un error: ejRes1 y ejRes2.
 +
 
 +
 
 +
La clave ha expirado (ejRes3). Se invita a cambiar la clave invocando de nuevo a autenticar2 con "clvCambiar", para lo cuál se aportan datos de la complejidad requerida.
 +
 
 +
 
 +
El pin del doble factor es válido en ejRes4. El usuario ha sido autenticado. Se devuelve "token2" ("token" ya se tiene). También se informa sobre si es posible cambiar la clave ("clvPuedeCambiar") y sobre sus requerimientos de complejidad. Si el comando autenticar2 hubiese incluido un cambio de clave mediante el campo "clvCambiar" y este cambio hubiese sido completado, se devolverá un booleano "clvHaCambiado" para informar de ello.
 +
 
  
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.
+
====== Comando autenticartokenaad ======
  
Para que se roten los logs hay que copiar el fichero bdNodo.logrotate a /etc/logrotate.d (como bdNodo)
 
  
<br><br>
+
Autenticar empleando un token de "Azure active directory"
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
==== Intz-Nimitz ====
 
  
Permite integrar procesos de asterisk (del dialplan) con la base de datos; por ejemplo es el que graba segmentos, inspecciona donde está 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.
+
url (POST): https://<servidor_webfon>/sercen/postautenticartokenaad
  
  
Para mas información consultar la página de [[intz-nimitz|intz-nimitz]].
+
datos de entrada: '''{"token": "tokenrequetelargao","aplicacion": "webfon","expira": 7200} ("expira" es opcional).'''
  
Desde un SSH ejecuta el comando “nc ip_maquina 1115”
 
  
'''root@vivait-acd:~# nc localhost 1115'''
+
Ejemplos de posibles respuestas:
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:
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
!Parámetro!!Descripción
+
! Ejemplo !! Respuesta
 
|-
 
|-
|sis/ver||Versión del proceso
+
| ejRes1 || {"errorNum": 101,"errorCad": "Token incorrecto"}
 
|-
 
|-
|sis/inic||Fecha de de arranque del proceso
+
| ejRes2 || {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "email"}
 
|-
 
|-
|Sis/alarmas||Alarmas desde arranque
+
| ejRes3 || {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "no","token2": "0987654321","expira": 3600}
|-
+
|}
|Sis/ultAlar||Fecha de última alarma
+
 
|-
+
 
|Gmp/msj||
+
====== Comando validartoken ======
|-
+
 
|Gmp/buf||
+
Es un comando muy simple, que permite conocer si un token es válido y su periodo de expiración.
|-
+
 
|Gmp/tarea||
+
 
 +
url (POST): https://<servidor_webfon>/sercen/postvalidartoken
 +
 
 +
 
 +
datos de entrada: '''{"token": "1234567890"}'''
 +
 
 +
 
 +
Ejemplos de posibles respuestas:
 +
 
 +
 
 +
{| class="wikitable"
 
|-
 
|-
|Tmp/uptime||Tiempo que lleva el servicio activo
+
! Ejemplo !! Respuesta
 
|-
 
|-
|Vic/identif||Etiqueta de identificación del servicio
+
| ejRes1 || {"errorNum": 100,"errorCad": "Token expirado"}
 
|-
 
|-
|Vic/entorno||Entorno de base de datos
+
| ejRes2 || {"errorNum": 103,"errorCad": "Token incorrecto"}
 
|-
 
|-
|Vic/conx||Conexiones activas/conexiones máximas
+
| ejRes3 || {"errorNum": 0,"errorCad": "OK","expira": 2538}
 +
|}
 +
 
 +
 
 +
 
 +
====== Comando revalidartoken ======
 +
 
 +
Permite ampliar el periodo de expiración de un token. El periodo ampliado es el que se indica en la respuesta.
 +
 
 +
 
 +
url (POST): https://<servidor_webfon>/sercen/revalidartoken
 +
 
 +
 
 +
datos de entrada: '''{"token": "1234567890","token2": "0987654321","expira": 7200} ("expira" es opcional).'''
 +
 
 +
 
 +
Ejemplos de posibles respuestas:
 +
 
 +
 
 +
{| class="wikitable"
 
|-
 
|-
|Vic/numConx||Conexiones totales (último minuto)
+
! Ejemplo !! Respuesta
 
|-
 
|-
|Mys/curro||Número de hilos contra la base de datos
+
| ejRes1 || {"errorNum": 100,"errorCad": "Token expirado"}
 
|-
 
|-
|Mys/soli||Conexiones solicitadas (último minuto)
+
| ejRes2 || {"errorNum": 103,"errorCad": "Token incorrecto"}
|-
 
|Mys/soliErr||Conexiones solicitadas con error (último minuto)
 
|-
 
|Mys/soliEncol||Conexiones encoladas
 
|-
 
|Cache/cola|| Colas monitorizadas/
 
|-
 
|Cache/vdn||VDN’s monitorizados
 
|-
 
|Cache/usuExten||
 
 
|-
 
|-
 +
| ejRes3 || {"errorNum": 0,"errorCad": "OK","expira": 3600}
 
|}
 
|}
  
Como complemento a los diagnósticos:
 
  
* Podremos examinar el fichero de configuración del proceso en  '''/etc/MDtel/intz-nimitz.conf'''
 
* Podremos examinar los logs del proceso en '''/var/log/intz-nimitz.log'''
 
  
'''Fichero de configuración:'''
+
====== Comando revocartoken ======
 +
 
 +
Permite revocar un token.
 +
 
  
  #
+
  url (POST): https://<servidor_webfon>/sercen/postrevocartoken
# Los nombres no pueden tener numeros
+
 
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
+
 
# Los valores comentados indican valores por defecto
+
datos de entrada: '''{"token": "1234567890","token2": "0987654321"}'''
+
 
base
+
 
{
+
Ejemplos de posibles respuestas:
cfg
+
 
{
+
 
soy_demonio = 1
+
{| class="wikitable"
hay_syslog = 0
+
|-
# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
+
! Ejemplo !! Respuesta
archivo_pid = -
+
|-
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
+
| ejRes1 || {"errorNum": 103,"errorCad": "Token incorrecto"}
# No se usa si se activa hay_syslog
+
|-
archivo_traza = -
+
| ejRes2 || {"errorNum": 0,"errorCad": "OK"}
}
+
|}
cfg_recarga
+
 
{
+
 
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
+
====== Comando cambiarClave ======
nivel_traza = 3
+
 
pruebas = 1
+
Permite que un usuario autenticado cambie su clave y amplíe el periodo de expiración y de caducidad.
hay_flush_traza = 1
+
 
}
+
 
sis
+
  url (POST): https://<servidor_webfon>/sercen/postcambiarclave
{
+
 
# No se usa. No modificar
+
 
subsistema = 0
+
datos de entrada:'''{"token": "1234567890","token2": "0987654321","clvCambiar": "masdificil$1aA"}'''
}
+
 
gmp
+
 
{
+
Ejemplos de posibles respuestas:
# Numero de mensajes. No modificar
+
 
num_msj = 1024
+
 
# Numero de buffer. No modificar
+
{| class="wikitable"
num_buf = 1024
+
|-
}
+
! Ejemplo !! Respuesta
  }
+
|-
+
| ejRes1 || {"errorNum": 102,"errorCad": "Clave incorrecta"}
supervision
+
|-
{
+
| ejRes2 || {"errorNum": 117,"errorCad": "Clave demasiado simple"}
puerto_escucha = 1115
+
|-
}
+
| ejRes3 || {"errorNum": 118,"errorCad": "Clave con caracteres no soportados"}
+
|-
supervision_recarga
+
| ejRes4 || {"errorNum": 119,"errorCad": "Clave no admite cambio"}
{
+
|-
to_periodo = 60
+
| ejRes5 || {"errorNum": 120,"errorCad": "Clave repetida"}
}
+
|-
+
| ejRes6 || {"errorNum": 0,"errorCad": "OK","clvExpira": 86400}
cache
+
|-
{
+
|}
        hay_cache = 1
+
 
}
+
 
+
 
cache_recarga
+
 
{
+
===== Posibles errores =====
# to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos
+
 
        colas_to_vida = 300
+
 
        colas_num_entrada = 128
+
{| class="wikitable"
        vdn_to_vida = 300
+
|-
        vdn_num_entrada = 128
+
! Número de error !! Descripción breve
}
+
|-
+
| 0 || OK
regexp
+
|-
{
+
| 100 || Token expirado
hay_regexp = 1
+
|-
}
+
| 101 || Pin expirado
+
|-
regexp_recarga
+
| 102 || Clave incorrecta
{
+
|-
num_entradas = 32
+
| 103 || Token incorrecto
inc_entradas = 128
+
|-
max_entradas = 1024
+
| 104 || Token2 incorrecto
}
+
|-
+
| 105 || Pin incorrecto
vivaitcall
+
|-
{
+
| 106 || Token comprometido
hay_vic = 1
+
|-
puerto_escucha = 5555
+
| 107 || Token anulado
identif = cms1
+
|-
entorno = nimitz
+
| 108 || Token inválido
max_conx = 128
+
|-
}
+
| 115 || Clave caducada
+
|-
vivaitcall_recarga
+
| 116 || Clave expirada
{
+
|-
to_solicitud = 3
+
| 117 || Clave demasiado simple
to_desconexion = 3
+
|-
ip_valida
+
| 118 || Clave con caracteres no soportados
{
+
|-
# Hasta 32 bloques de direcciones validas
+
| 119 || Clave no admite cambio
todas
+
|-
{
+
| 120 || Clave repetida
ip = 0.0.0.0
+
|-
msk = 0.0.0.0
+
| 400 || Error en datos de entrada
}
+
|-
localhost
+
| 401 || Error registro de extensión
{
+
|-
ip = 127.0.0.1
+
| 402 || Error en el estado del dispositivo
msk = 255.255.255.255
+
|-
}
+
| 403 || Error en el estado de la media con el navegador
}
 
}
 
 
enrutamiento
 
{
 
hay_enrutamiento = 1
 
max_pre_ruta_regs = 4
 
max_ruta = 4
 
max_ruta_desvios = 2
 
# Filtro de informacion de ancho de banda
 
# MYSDanchoBandaPasoNinguno      0
 
# MYSDanchoBandaPasoSoloDirectos 1
 
# MYSDanchoBandaPasoSoloEnPaso  2
 
# MYSDanchoBandaPasoTodos        3
 
filtro_ancho_banda = 1
 
}
 
 
mysql
 
{
 
hay_mysql = 1
 
host = BDTR
 
usuario = nimitz
 
clave = phikau3iwCe4O0PP5b09ng==
 
base_datos = nimitz
 
bd_supervivencia = 0
 
num_curro = 10
 
}
 
 
mysql_recarga
 
{
 
to_resp = 5
 
}
 
 
 
 
Los siguientes son los campos del fichero de configuración '''int-nimitz.conf''':
 
 
 
{| class="wikitable"
 
 
|-
 
|-
|Variable a modificar||Comentarios||Posibles valores (si aplica)
+
| 404 || No hay línea libre
 
|-
 
|-
|soy_demonio||Si corro como demonio o como proceso||1 demonio – 0 proceso
+
| 405 || La línea no está libre
 
|-
 
|-
|hay_syslog||Si hay servidor de syslog||1 lo hay – 0 no lo hay
+
| 406 || La línea es errónea
 
|-
 
|-
|archivo_pid||# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)||
+
| 407 || Línea en estado erróneo
 
|-
 
|-
|archivo_traza||# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)||
+
| 408 || JSEP obligatorio
 
|-
 
|-
|nivel_traza||# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)||
+
| 409 || JSEP ‘offer’ obligatorio
 
|-
 
|-
|pruebas||||
+
| 410 || Cifrado extremo a extremo no soportado
 
|-
 
|-
|hay_flush_traza||||
+
| 411 || Canal de datos no soportado
 
|-
 
|-
|subsistema||# No se usa. No modificar||
+
| 412 || Comando desconocido
 
|-
 
|-
|num_msj||# Numero de mensajes. No modificar||
+
| 413 || No hay recursos
 
|-
 
|-
|num_buf||# Numero de buffer. No modificar||
+
| 414 || No hay conferencia libre
 
|-
 
|-
|puerto_escucha||Puerto de supervisión del demonio||
+
| 415 || Error conferencia
 
|-
 
|-
|to_periodo||Timeout para reconectar||
+
| 416 || Línea no conectada
 
|-
 
|-
|hay_cache||si guarda datos o no en cache||1 hay cache – 0 no hay cache
+
| 500 || Error interno
|-
+
|}
|colas_to_vida||# to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos||
 
|-
 
|colas_num_entrada||Número de entradas correspondiente a las colas||
 
|-
 
|vdn_to_vida||# to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos||
 
|-
 
|vdn_num_entrada||Número de entradas correspondiente a los VDN||
 
|-
 
|hay_regexp||||
 
|-
 
|num_entradas||||
 
|-
 
|inc_entradas||||
 
|-
 
|max_entradas||||
 
|-
 
|hay_vic||||
 
|-
 
|puerto_escucha||Puerto de escucha a nivel de vivait-call||
 
|-
 
|identif ||||
 
|-
 
|entorno||Nombre base de datos||
 
|-
 
|max_conx||Número máximo de conexiones a la base de datos||
 
|-
 
|to_solicitud||Timeout de solicitud||
 
|-
 
|to_desconexion||Timeout de desconexión||
 
|-
 
|ip||Dirección de red de escucha del intz-nimitz||
 
|-
 
|msk ||Máscara de red de escucha del intz-nimitz||
 
|-
 
|ip||IP localhost||
 
|-
 
|msk||Máscara localhost||
 
|-
 
|hay_enrutamiento||Hay fase de enrutamiento o no||1 hay enrutamiento – 0 no hay
 
|-
 
|max_pre_ruta_regs||Número máximo de prerutas a cargar||
 
|-
 
|max_ruta||Número máximo de rutas a cargar||
 
|-
 
|max_ruta_desvios||Número máximo de rutas de desvíos a cargar||
 
|-
 
|filtro_ancho_banda||Filtrar por ancho de banda||1 filtrar – 0 no filtrar
 
|-
 
|hay_mysql||Hay mysql||1 hay -0 no hay
 
|-
 
|host||IP o HOST máquina base de datos ||
 
|-
 
|usuario||Usuario acceso Base de datos||
 
|-
 
|clave||Clave usuario acceso base de datos||
 
|-
 
|base_datos||Nombre de la base de datos||
 
|-
 
|bd_supervivencia||Hay o no base de datos de supervivencia||1 hay base de datos de supervivencia – 0 no hay
 
|-
 
|num_curro||Número de conexiones simultáneas a la base de datos||
 
|-
 
|to_resp||Timeout de respuesta||
 
|-
 
|}
 
  
  
  
  
<br><br>
+
===== Logs y comandos =====
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
+
 
<br><br>
+
 
 +
En serCen podemos monitorizar el funcionamiento del proceso de login de los usuarios.
  
 +
'''systemctl status serCen.service'''
  
<!--
+
Resultado esperado:
==== intz-gh ====
 
  
intz-gh es un demonio que permite tanto la monitorizacion de extensiones (BLFs), como la activación de retrollamadas entre distintos nodos.
+
serCen.service - LSB: Start/stop serCen
 +
Loaded: loaded (/etc/init.d/serCen; generated)
 +
Active: active (exited) since Thu 2022-02-10 15:16:46 CET;
 +
2h 38min ago
 +
Docs: man:systemd-sysv-generator(8)
 +
Process: 942 ExecStart=/etc/init.d/serCen start
 +
(code=exited, status=0/SUCCESS)
 +
feb 10 15:16:45 VC-WebP-AytoArganda-MAD-02 systemd[1]:
 +
Starting LSB: Start/stop serCen...
 +
feb 10 15:16:45 VC-WebP-AytoArganda-MAD-02 serCen[942]:
 +
Starting serCen
 +
feb 10 15:16:46 VC-WebP-AytoArganda-MAD-02 systemd[1]:
 +
Started LSB: Start/stop serCen.
  
  
'''Comandos desde consola de asterisk'''
+
Para listar información de serCen:
  
  mdgh show
+
  '''nc localhost 1125'''
  
Uso: mdgh show [config | exten <exten_num> | enla <peer>]]
 
  
* '''Ejemplo'''
+
Resultado esperado:
  
  mdgh show config
+
  serCen sis ver='00.01.04.1' inic='20220210 173436' alarmas=0 ultAlar='00000000
  mdgh Configuracion:
+
  000000'
   
+
  serCen gmp msj=254/256 buf=256/256 tarea=97/102
  debug=no
+
serCen tmp uptime=1009 (0d 0h 16m 49s)
  retro_hay=yes
+
serCen wws mysql=1 conxNum=0 conxMaxPeriodo=0
  subscripcion_hay=yes
+
serCen wwc numCacheLibre=3 numColaPend=0
  rest_red_ip=255.255.255.255
+
serCen wwc numReq=0/0 numGet=0/0 numPost=0/0 numPut=0/0 numDelete=0/0
  rest_red_msk=255.255.255.255
+
serCen smt numCacheLibre=5 numColaPend=0 enPeriodo=0/0 numMsj=2/0
  rest_puerto_escucha=8090
 
  retro_exten_tech=SIP
 
  retro_contexto=Cen_InicioLlamada_GHRetro
 
  retro_to_descolgar=30 s
 
  retro_A_cartel_fmt='retro: %s
 
  
mdgh show exten 6146
 
 
mdgh Datos de la extension 6146:
 
 
  Datos en intz-gh:
 
    ESTADO=NOT_INUSE
 
    INUSE=0
 
    RINGING=0
 
    TS=1535609682
 
    HACE=1171
 
  
mdgh show en la Trunk_MDtel
+
Ejemplos del log de serCen:
  
mdgh Datos del enlace Trunk_MDtel:
 
 
  Datos en intz-gh:
 
    INUSE=0
 
    RINGING=0
 
    TS=1535610093
 
    HACE=834
 
  
  
'''Fichero de log'''
+
Acceso:
 +
 
 +
[[File:sercen1.png |1000px]]
 +
 
 +
Clave errónea:
 +
 
 +
[[File:sercen2.png |1000px]]
 +
 
 +
==== Aplicación PQCTI ====
 +
 
 +
 
 +
Pqcti es una nueva aplicacion de asterisk 13 que sirve para establecer llamadas , cada asterisk tendrá su modulo pqcti instalado y configurado. No hay una arquitectura como tal , sino una base para empezar a desarrollar cosas por encima.
 +
 
 +
 
 +
[[Archivo:PQCTI.png|600px|center]]
 +
 
 +
 
 +
La aplicación pqcti es un webservice con JSON y está configurada en un Tomcat. Cada nodo tendrá su pqcti, por lo que si ese nodo cae, no se podrán realizar consultas o conexiones desatendidas a ese nodo.
 +
 
 +
 
 +
Actualmente pqcti se utiliza para:
 +
 
 +
'''- Las conexiones desatendidas'''
 +
 
 +
'''- Para el click2talk'''
 +
 
 +
'''- La funcionalidad de llamar desde agenda o historial en el portal de usuario VIVAit'''
  
/var/log/intz-gh.log
 
  
  
'''Fichero de configuracion'''
 
  
/etc/MDtel/intz-gh.conf
+
===== Servicios web =====
  
  
'''Campos intz-gh.conf'''
+
Los servicios web que proporciona la aplicación son de dos tipos:
  
# Los nombres no pueden tener numeros.
 
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles.
 
# Los valores comentados indican valores por defecto.
 
  
base
+
1. Operativos
 
+
 
cfg
+
 
{
+
 
soy_demonio = 1
+
{| class="wikitable sortable"
hay_syslog = 0
+
|-
# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
+
! Comando!! Descripción
archivo_pid = -
+
|-
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
+
| '''cmd_llamar''' || Inicia una llamada saliente desde una extensión vivait-call.
# No se usa si se activa hay_syslog
+
|-
archivo_traza = -
+
| '''cmd_liberar''' || Libera una llamada establecida, que haya sido registrada en pqcti. La llamada se identifica mediante el ucid que se pasa como parámetro de invocación.
}
+
|-
cfg_recarga
+
|}
{
+
 
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
+
 
nivel_traza = 3
+
 
pruebas = 1
+
 
hay_flush_traza = 1
+
 
# traza_milisegundos = 1
+
2. Informativos
}
+
 
sis
+
 
{
+
 
# No se usa. No modificar
+
{| class="wikitable sortable"
subsistema = 0
+
|-
}
+
! Comando!! Descripción
gmp
+
|-
{
+
| '''info_llamadas''' || Informa sobre las llamadas registradas en pqcti. Devuelve un array con la información de cada llamada.
# Numero de mensajes. No modificar
+
|-
num_msj = 256
+
| '''info_llamadas_num''' || Devuelve el número de llamadas registradas en pqcti.
# Numero de buffer. No modificar
+
|-
num_buf = 256
+
| '''info_llamada''' || Devuelve la información de la llamada cuyo ucid se pasa como parámetro de invocación.
}
+
|-
}
+
|}
 +
 
 +
 
 +
 
 +
===== Archivos relevantes y procedimientos de despliegue =====
 +
 
 +
 
 +
Los archivos relevantes para construir la aplicación son:
 +
 
 +
 
 +
Fuentes (directorio referenciado en donde se encuentren los fuentes de asterisk):
 +
 
 +
 
 +
* '''apps/app_md_pqcti.c'''
 
   
 
   
  supervision
+
* '''apps/pqcti/*.c y apps/pqcti/*.h'''
  {
+
 
puerto_escucha = 1116
+
* '''apps/Makefile''' (Que requiere de ser modificado para compilar la aplicación)
  }
+
 
   
+
 
  supervision_recarga
+
 
  {
+
------ Añadir al final de "clean:" "pqcti/*.o" ------
to_periodo = 60
+
 
  }
+
:{|
 +
|-
 +
|
 +
 
 +
  ------ Añadir debajo de "$(subst .c,.o,$(wildcard
 +
  confbridge/*.c)): _ASTCFLAGS+=$(call
 +
MOD_ASTCFLAGS,app_confbridge)" ------
 +
  # wkw inicio
 +
  $(if $(filter app_md_pqcti,$
 +
  (EMBEDDED_MODS)),modules.link,app_md_pqcti.so): $(subst
 +
  .c,.o,$(wildcard pqcti/*.c))
 +
$(subst .c,.o,$(wildcard pqcti/*.c)): _ASTCFLAGS+=$
 +
(call MOD_ASTCFLAGS,app_md_pqcti)
 +
#wkw fin (mirar clean:)
 +
  ------
 +
|} <br>
 +
 
 +
'''La compilación y despliegue se hace del modo habitual: "make" y "make install".'''
 +
 
 +
 
 +
 
 +
====== Configuración de archivos relevantes: ======
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 
   
 
   
regexp
 
{
 
hay_regexp = 1
 
}
 
 
   
 
   
regexp_recarga
+
* '''En el Dialplan. Llamada saliente''' (en el archivo que se considere adecuado)
{
+
 
num_entradas = 32
+
A continuación se ofrece un dialplan de inicio de llamada. Conviene analizar si los contextos de transferencia son distintos a los habituales.
inc_entradas = 128
+
 
max_entradas = 1024
+
:{|
}
+
|-
   
+
|
  vivaitcall
+
  ------
  {
+
  [pqcti_inicio_llamada_sale]
hay_vic = 1
+
  exten => _X.,1,NoOp(ID_DISPOSITIVO=${ID_DISPOSITIVO})
puerto_escucha = 5556
+
same =>      n,NoOp(UCID=${UCID})
identif = gh_000
+
same =>      n,NoOp(PQCTI_SAL_EXTEN=${PQCTI_SAL_EXTEN})
entorno = gh
+
  same =>      n,NoOp(PQCTI_SAL_ANI_NUM=$
max_conx = 4
+
  {PQCTI_SAL_ANI_NUM})
}
+
  same =>      n,NoOp(PQCTI_SAL_ANI_NAME=$
   
+
{PQCTI_SAL_ANI_NAME})
  vivaitcall_recarga
+
  same =>      n,NoOp(PQCTI_SAL_DNIS_NUM=$
  {
+
{PQCTI_SAL_DNIS_NUM})
to_solicitud = 10
+
same =>      n,NoOp(PQCTI_SAL_DNIS_NAME=$
to_desconexion = 10
+
{PQCTI_SAL_DNIS_NAME})
ip_valida
+
  same =>      n,Set(__TRANSFER_CONTEXT=pqcti_transferir_llamada)
{
+
  same =>      n,Set(__FORWARD_CONTEXT=pqcti_desviar_llamada)
  # Hasta 32 bloques de direcciones validas
+
  same =>      n,Set(CALLERID(name)=$
todas
+
  {PQCTI_SAL_ANI_NAME})
{
+
same =>      n,Set(CALLERID(num)=${PQCTI_SAL_ANI_NUM})
ip = 0.0.0.0
+
same =>      n,Set(CHANNEL(hangup_handler_wipe)=$
msk = 0.0.0.0
+
  {CONTEXT},fin,1())
}
+
  same =>      n,pqctiLlamSaleIniciada
localhost
+
  same =>      n,NoOp(INSERT en BD)
{
+
  same =>      n,Goto(Cen_Inicio_SIP,${EXTEN},1)
ip = 127.0.0.1
+
  exten => fin,1,pqctiLlamLiberada
msk = 255.255.255.255
+
  same =>      n,NoOp(UPDATE en BD)
}
+
  same =>      n,Return
}
+
  ------
  }
+
 
   
+
|} <br>
  mysql
+
 
  {
+
 
hay_mysql = 1
+
* '''Para llamada entrante'''
host = BDTR
+
 
usuario = nimitz
+
 
clave = phikau3iwCe4O0PP5b09ng==
+
Es muy importante llamar a "ucid(0)" antes de pqctiLlamEntra y de insertar en BD. No importa si en "Cen_Inicio_TrunkSip" se invoca de nuevo a "ucid(0)" porque se mantiene el asignado.
base_datos = nimitz
+
 
  }  
+
:{|
   
+
|-
  mysql_recarga
+
|
  {
+
  ------
to_resp = 5
+
  [pqcti_inicio_llamada_entra]
}
+
  exten => _X.,1,NoOp(ID_DISPOSITIVO=${ID_DISPOSITIVO})
   
+
  same =>      n,ucid(0)
  gh1
+
same =>      n,NoOp(UCID=${UCID})
  {
+
  same =>     
hay_gh1 = 1
+
  n,Set(__TRANSFER_CONTEXT=pqcti_transferir_llamada)
  # umbrales para el numero de digitos de una extension
+
  same =>     
# sirve para saber si un peer es una extension o un enlace
+
  n,Set(__FORWARD_CONTEXT=pqcti_desviar_llamada)
exten_min_digi = 3
+
  same =>      n,Set(CHANNEL(hangup_handler_wipe)=$
exten_max_digi = 8
+
  {CONTEXT},fin,1())
# numero maximo de extensiones soportadas
+
same =>      n,pqctiLlamEntra
exten_max = 500
+
same =>      n,NoOp(INSERT into DAT_CONX_DESATEN)
# numero maximo de enlaces soportados
+
  same =>      n,Goto(Cen_Inicio_TrunkSip,${EXTEN},1)
enla_max = 20
+
  <br>
# numero maximo de retrollamadas activas concurrentes
+
  exten => fin,1,pqctiLlamLiberada
retro_max = 50
+
  same =>      n,NoOp(UPDATE DAT_CONX_DESATEN set
# numero maximo de retrollamadas activas concurrentes para una extension como destino (max 31)
+
  D_HORA_FIN,DURACION)
retro_max_b = 4
+
  same =>      n,Return
}
+
  ------
   
 
  gh1_recarga
 
  {
 
  # tiempo maximo en segs. para activar una retrollamada tras finalizar llamada
 
to_retro_candidato = 60
 
  # tiempo maximo en segs. que una retrollamada espera a que las extensiones esten libres
 
to_retro_activo = 300
 
  # temporizador de limpieza de tablas en segs.
 
to_limpiar = 10
 
  }
 
   
 
  ias
 
  {
 
hay_ias = 1
 
url = mdgh_rest
 
puerto = 8090
 
  }
 
   
 
  ias_recarga
 
  {
 
  # tiempo maximo en segs. para conectar con asterisk para comandos
 
to_conx_cmd = 10
 
  # periodo en horas para actualizar lista de id de nodos y sus direcciones ip
 
to_lista_nodos = 1
 
  }
 
-->
 
  
===== Nuevo servicio en intz-nimitz 04.00.00  =====
+
|} <br>
  
  
  
Para las colas con extensiones multiterminal, se ha creado un ha creado un nuevo servicio en intz-nimitz 04.00.00.
+
* '''En /etc/asterisk/acl.conf'''
 +
 
  
La descripción de nuevo servicio es:
 
  
    multiTermGrupoSaltoRing
+
Debe configurarse el acl que limita el acceso al servicio desde direcciones ip conocidas.
    . Devuelve la mascara con los terminales que tienen que sonar (ring) al estar la extension en una cola (queue, ringall).
 
    . par1 (extension)
 
    . Retornos posibles (ademas del los genericos) en ${MDintzRes}:
 
    .. OK: Todo correcto.
 
    .. KO: Ha habido un problema.
 
    . Retorno en MTERM (solo si OK): mascara con los terminales y su orden (ej: '33245289').
 
    . Retorno en MTERM_MENOR (solo si OK): mascara con los terminales y su orden, filtrando las de orden menor (ej: '00200200').
 
  
==== motorSal ====
+
Un ejemplo en que se permite una red de servidores y un equipo:
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'
+
[pqcti_acl_comandos]
  motorSal gmp msj=253/256 buf=256/256 tarea=99/102
+
  deny=0.0.0.0/0.0.0.0
  motorSal tmp uptime=600165 (6d 22h 42m 45s)
+
  permit=172.25.128.0/24
  motorSal mtr mys=1 ocup=0% planif=28(0) intento=26(0)
+
  permit=192.168.0.20/32
 +
  permit=127.0.0.1
 +
------
  
Donde cada parámetro monitorizado indica:
+
|} <br>
  
{| class="wikitable"
 
|-
 
!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)
 
|-
 
|}
 
  
* Posee un fichero de configuración llamado ''motorSal.conf'' en la ruta '''/etc/MDtel/motorSal.conf''':
 
  
#
+
* '''En /etc/asterisk/http.conf'''
# Los nombres no pueden tener numeros
+
 
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
+
:{|
# Los valores comentados indican valores por defecto
+
|-
+
|
base
+
  ------
{
+
  [general]
cfg
+
  servername=vcall-nodo
{
+
enabled=yes
soy_demonio = 1
+
  bindaddr=0.0.0.0
hay_syslog = 0
+
bindport=8088
  # Archivo con identificador de proceso: (-: /var/run/motorSal.pid)
+
prefix=vcall-nodo
archivo_pid = -
+
sessionlimit=100
  # Archivo_traza: (-: stdout o /var/log/motorSal.log si soy_demonio)
+
  session_inactivity=30000
  # No se usa si se activa hay_syslog
+
  session_keep_alive=15000
archivo_traza = -
+
  enablestatic=no
}
+
  ;redirect = / /static/config/index.html
cfg_recarga
+
tlsenable=no
{
+
  ;tlsbindaddr=0.0.0.0:8089
  # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
+
  ;tlscipher=
nivel_traza = 2
+
  ;tlsdisablev1=yes
pruebas = 0
+
  ;tlsdisablev11=yes
hay_flush_traza = 1
+
  ;tlsdisablev12=yes
  # traza_milisegundos = 1
+
  ;tlsservercipherorder=yes
}
+
  ;[post_mappings]
sis
+
  ;uploads = /var/lib/asterisk/uploads/
{
+
  ------
  # No se usa. No modificar
+
 
subsistema = 0
+
|} <br>
}
+
 
gmp
+
 
{
+
* '''En /etc/asterisk/pqcti.conf'''
  # Numero de mensajes. No modificar
+
 
num_msj = 256
+
:{|
  # Numero de buffer. No modificar
+
|-
num_buf = 256
+
|
}
+
  ------
  }
+
  [general]
   
+
  debug=false
  supervision
+
llamadas_registrar=true
  {
+
  <br>
puerto_escucha = 1120
+
  [comandos]
  }
+
url_comandos_v1=pqcti/v1/comandos
   
+
  acl=pqcti_acl_comandos
  supervision_recarga
+
  <br>
  {
+
  [llamada_sale]
to_periodo = 60
+
  canal_A_tech=sip
  }
+
  canal_A_dial_cad_fmt=%s
+
  contexto=pqcti_inicio_llamada_sale
mysql
+
  temporizador_segs=30
{
+
  ------
hay_mysql = 1
+
 
host = localhost
+
|} <br>
usuario = nimitz
 
clave = phikau3iwCe4O0PP5b09ng==
 
base_datos = nimitz
 
}
 
   
 
  motor
 
  {
 
hay_motor = 1
 
ciclos_campanna_activa = 30
 
  # Directorio donde se almacenan las librerias dinamicas con las estrategias
 
  # Por defecto = '/usr/lib/motorSal/estrategias'
 
dir_estrategias = /usr/lib/motorSal/estrategias
 
  }
 
   
 
  motor_recarga
 
  {
 
  # Periodo de ejecucion del ciclo del motor
 
to_ciclo = 10
 
  }
 
   
 
  muestreo
 
{
 
hay_muestreo = 1
 
}
 
  
  
Los campos del fichero de configuración son los siguientes:
 
  
{| class="wikitable"
+
* '''En /etc/asterisk/ext_Subrutinas_BD.conf'''
|-
+
 
!Campo !!Descripción !!Posibles valores (si aplica)
+
:{|
 
|-
 
|-
|soy_demonio||Si corro como demonio o como proceso||1 demonio – 0 proceso
+
|
|-
+
 
|hay_syslog||Si hay servidor de syslog||1 lo hay – 0 no lo hay
+
;------------------------------------------------------
|-
+
[Cen_Sub_updateDatConxDesaten_Fin]
|archivo_pid||# Archivo con identificador de proceso: (-: /var/run/motorSal.pid)||
+
;------------------------------------------------------
|-
+
-----------
|archivo_traza||# Archivo_traza: (-: stdout o /var/log/motorSal.log si soy_demonio)||
+
;------------------------------------------------------
|-
+
-----------
|nivel_traza||# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)||
+
; ${ARG1}: C_UCID
|-
+
<br>
|pruebas||||
+
exten => s,1,NoOp(MDSUBUPDDATCONXDESCON*)
|-
+
<br>
|hay_flush_traza||||
+
  same =>  n,ExecIf($["${SPRV}"="1"]?
|-
+
Return(SUPERVIVENCIA))
|traza_milisegundos||||
+
<br>
|-
+
  same =>  n,ExecIf($["${ARG1}"=""]?Return(NO_UCID))
|subsistema||# No se usa. No modificar||
+
<br>
|-
+
  same =>  n,MDintz(nimitz|bd|sqlSinEspera|update
|num_msj||# Numero de mensajes. No modificar||
+
DAT_CONX_DESATEN set D_HORA_FIN=now(),N_DURACION=now()-
|-
+
D_HORA_INICIO where C_UCID="${ARG1}")
|num_buf ||# Numero de buffer. No modificar||
+
<br>
|-
+
  ;same =>  n,DumpChan
|puerto_escucha||Puerto de supervisión del demonio||
+
  same =>  n,Return(OK)
|-
+
<br>
|to_periodo||Timeout para reconectar||
+
include => Cen_finLlamada
|-
+
<br>
|hay_mysql||Hay mysql||1 hay -0 no hay
+
;------------------------------------------------------
|-
+
-----------
|host||IP o HOST máquina base de datos de tiempo real||
+
[Cen_Sub_updateDatConxDesaten_Contestada]
|-
+
;------------------------------------------------------
|usuario||Usuario acceso Base de datos de tiempo real||
+
-----------
|-
+
;------------------------------------------------------
|clave||Clave usuario acceso base de datos de tiempo real||
+
-----------
|-
+
; ${ARG1}: C_UCID
|base_datos||Nombre de la base de datos||
+
<br>
|-
+
exten => s,1,NoOp(MDSUBUPDDATCONXDESCON*)
|hay_motor||Si hay campañas saliente o no||1 hay motor saliente – 0 no hay motor saliente
+
<br>
|-
+
  same =>  n,ExecIf($["${SPRV}"="1"]?
|ciclos_campanna_activa||||
+
Return(SUPERVIVENCIA))
|-
+
<br>
|dir_estrategias ||# Directorio donde se almacenan las librerias dinámicas con las estrategias||
+
  same =>  n,ExecIf($["${ARG1}"=""]?Return(NO_UCID))
|-
+
<br>
|to_ciclo||# Periodo de ejecución del ciclo del motor||
+
  same =>  n,MDintz(nimitz|bd|sqlSinEspera|update
|-
+
DAT_CONX_DESATEN set B_CONTESTADA=1 where C_UCID="$
|hay_muestreo||||1 hay muestreo – 0 no hay muestreo
+
{ARG1}")
|-
+
<br>
|}
+
  ;same =>n,DumpChan
 +
  same =>n,Return(OK)
 +
include => Cen_finLlamada
 +
<br>
 +
;------------------------------------------------------
 +
-----------
 +
[Cen_Sub_insertDatConxDesaten]
 +
;------------------------------------------------------
 +
-----------
 +
;------------------------------------------------------
 +
-----------
 +
; ${ARG1}: ID_NODO
 +
; ${ARG2}: C_UCID
 +
; ${ARG3}: C_ORIGEN_NUM
 +
; ${ARG4}: C_ORIGEN_NAME
 +
; ${ARG5}: C_ORIGEN_EXTEN
 +
; ${ARG6}: C_DESTINO_NUM
 +
; ${ARG7}: C_DESTINO_NAME
 +
; ${ARG8}: ID_DISPOSITIVO
 +
;
 +
<br>
 +
exten => s,1,NoOp(MDSUBINSERTDATCONXDES*)
 +
<br>
 +
  same =>n,ExecIf($["${SPRV}"="1"]?
 +
Return(SUPERVIVENCIA))
 +
<br>
 +
  same =>  n,ExecIf($["${ARG1}"=""]?Return(NO_IDNODO))
 +
  same =>  n,ExecIf($["${ARG2}"=""]?Return(NO_UCID))
 +
  same =>  n,ExecIf($["${ARG3}"=""]?Set(ARG3=NULL))
 +
  same =>  n,ExecIf($["${ARG4}"=""]?Set(ARG4=NULL))
 +
  same =>  n,ExecIf($["${ARG5}"=""]?Set(ARG5=NULL))
 +
  same =>  n,ExecIf($["${ARG6}"=""]?Set(ARG6=NULL))
 +
  same =>  n,ExecIf($["${ARG7}"=""]?Set(ARG7=NULL))
 +
  same =>  n,ExecIf($["${ARG8}"=""]?Set(ARG8=NULL))
 +
<br>
 +
  same =>  n,MDintz(nimitz|bd|sqlSinEspera|insert into
 +
DAT_CONX_DESATEN
 +
(D_HORA_INICIO,ID_NODO,C_UCID,C_ORIGEN_NUM,C_ORIGEN_NAM
 +
E,C_ORIGEN_EXTEN,C_DESTINO_NUM,C_DESTINO_NAME,ID_DISPOS
 +
ITIVO) VALUES(now(),${ARG1},"${ARG2}","${ARG3}","$
 +
{ARG4}","${ARG5}","${ARG6}","${ARG7}",${ARG8}))
 +
<br>
 +
  ;same =>n,DumpChan
 +
  same =>n,Return(OK)
 +
<br>
 +
include => Cen_finLlamada
 +
<br>
 +
<br>
 +
---------------------------------------
  
* Respecto a los logs del motorSal consultar el siguiente apartado: [[Trazas motorSal]]. Los logs pueden verse en la ruta '''/var/log/motorSal.log'''
 
 
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
 
==== 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 el responsable de mostrar información en las ventanes de tiempo real del supervisor.
 
 
Es también el proceso que genera las llamadas en el marcador automático de '''''VIVA'''''it 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:
 
{| class="wikitable"
 
|-
 
!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||Extensiones/Extensiones/Extensiones monitorizadas|-
 
|-
 
|AMI/asig||
 
|-
 
|MYSQL/cnx||Conectado (1) a MySQL
 
|-
 
|MYSQL/ms||Tiempo de última operación en ejecutarse
 
|-
 
|}
 
  
Como complemento a los diagnósticos:
+
|} <br>
  
* Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/myAcdSuperv.cnf'''
 
* Podremos examinar los logs del proceso en '''/var/log/myAcdSuperv.log'''
 
  
 +
* '''En /etc/asterisk/ext_MARCAR_Extension_Dial.conf'''
  
  
<br><br>
+
*En este fichero hay que añadir lo que está en negrita.
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
==== 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:
+
|-
# Proceso escoba perteneciente a nodo con agente de grabación (recordNodo) llamado '''''escobaGW.pl'''''.
+
|
# Proceso escoba perteneciente o no a un servidor de grabación (recordCentral) llamado '''''escobaGrabsBd.pl'''''.
 
  
===== 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''.
+
[Cen_Marcar_Extension_Dial_Gosub]
 +
;------------------------------------------------------
 +
-----------
 +
exten => s,1,NoOp(MDSUBMAREXTEN*)
 +
<br>
 +
  same =>  n,Gosub(Cen_Sub_updAnswer,s,1(${UCID},$
 +
{ID_DISPOSITIVO},${ENR_IDSEGMENTO}))
 +
<br>
 +
  same =>  n,ExecIf($[$[${MDDEBUG}-0] > 1]?DumpChan)
 +
<br>
 +
  ;Declarar la variable PASARTONOS en el trunk que
 +
queramos
 +
  same => n,ExecIf($["${PASARTONOS}"="1"]?
 +
SetChannelOption(14,0))
 +
<br>
 +
  ;Rellenar el historico de llamadas
 +
; same =>    n,Gosub(Cen_Sub_updDatHisLlam_tipo,s,1($
 +
{DIALEDPEERNUMBER},${TIPOLLAMHIST_ENTRANTE},${UCID}))
 +
  same =>    n,Gosub(Cen_Sub_updDatHisLlam_tipo_ID,s,1($
 +
{DIALEDPEERNUMBER},${TIPOLLAMHIST_ENTRANTE},$
 +
{ID_HLL_S}))
 +
<br>
 +
'''; Poner contestadas las llamadas de conexiones'''
 +
'''desatendidas'''
 +
'''same =>    n,GosubIf($["${PQCTI_REGISTRAR()}"="SI"]?'''
 +
'''Cen_Sub_updateDatConxDesaten_Contestada,s,1(${UCID}))'''
 +
<br>
 +
same =>  n,Return()
  
===== escobaGrabsBd.pl =====
+
|} <br>
Se ejecuta sobre 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.
 
  
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
* 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.
 
  
==== 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, las máquinas 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 significa que sea necesario tener ''dispositivos NAS'' para funcionar, sino que puede tomar datos de diferentes sitios.
+
'''Descripción de campos del archivo pqcti.conf:'''
  
En '''recordCentral''' pueden existir tres tipos de dispositivos NAS:
+
'''• general'''
* Uno dedicado para las llamadas
 
* Uno dedicado para los segmentos
 
* Uno mixto para todas las llamadas y segmentos.
 
  
 +
*'''debug'''. Activa la depuración desde el inicio, aunque puede activarse mediante comando "pqcti debug on"
 +
 +
*'''llamadas_registrar'''. Booleano que indica si se mantiene un registro de llamadas.Si se desactiva esta opción,
 +
no hay registro y, por tanto, no se soportan los comandos "cmd_liberar" y los comandos informativos.
 +
 +
 +
'''• comandos'''
 +
 +
*''' url_comandos_v1'''. La parte no común de la url. Con la configuración de http.conf propuesta, la url completa sería:
 +
http://<IP_NODO>:8089/vcall-nodo/pqcti/v1/comandos
 +
 +
*''' acl.''' Configura el "acl" a utilizar en el archivo "/etc/asterisk/acl.conf"
 +
 +
 +
'''• llamada_sale'''
 +
 +
*''' canal_A_tech.''' Configura la tecnología de los canales de extensiones. Típicamente "sip". Podría ser "local", pero:
 +
 +
  '''¡¡¡CUIDADO !!! si se usase un canal local, se perdería la función de "setvar" en el "peer": se pierde ID_DISPOSITIVO.'''
 +
 +
 +
* '''canal_A_dial_cad_fmt.''' Si los canales de extensiones fuesen "sip/<exten>", entonces este campo sería "%s". Si la tecnología fuese "local", este campo sería "%s@<contexto>/n".
 +
 +
* '''contexto.''' Es el contexto en el que se inicia la llamada saliente. Como son necesarios algunos ajustes, debe existir un contexto especial antes de ir al contexto genérico "Cen_Inicio_Sip".
 +
 +
* '''temporizador_segs.''' Tiempo máximo (en segs.) para el descolgado de la extensión para la que se solicita el inicio de la llamada saliente.
 +
 +
===== Aplicaciones para el dialplan de asterisk =====
 +
 +
 +
 +
* '''pqctiLlamSaleIniciada''' (sin parámetros). Debe invocarse al inicio del dialplan de una llamada saliente. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".
 +
 +
 +
* '''pqctiLlamEntra'''. Debe invocarse al inicio del dialplan de una llamada entrante. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".
 +
 +
 +
* '''pqctiLlamLiberada'''. Debe invocarse al finalizar una llamada que previamente ha sido registrada en pqcti con las aplicaciones anteriores. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".
 +
 +
 +
 +
 +
 +
 +
===== Comandos de asterisk =====
 +
 +
 +
 +
A continuación se muestran varios comandos de pqcti para asterisk.
  
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, intenta descargar los segmentos de las llamadas y convertirlas al formato adecuado (MP3).
 
Como una característica particular cada diez minutos, siempre que 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 y 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:
 
  
{| class="wikitable"
+
{| class="wikitable sortable"
 
|-
 
|-
! Parámetro !! Descripción
+
! Comando!! Descripción
 
|-
 
|-
| SIS/ver || Versión del proceso
+
| '''pqcti show''' || Lista los datos de configuración y de las llamadas registradas.
 
|-
 
|-
| SIS/inic || Fecha de arranque del proceso
+
| '''pqcti reload''' || Recarga la configuración si se ha modificado "/etc/asterisk/pqcti.conf".
 
|-
 
|-
| SIS/alarmas || Alarmas desde arranque
+
| |'''pqcti debug [on|off]''' || Activa y desactiva la depuración del módulo.
 
|-
 
|-
| SIS/ultAlar || Fecha de última alarma
+
|}
 +
 
 +
 
 +
 
 +
 
 +
===== Tabla en base de datos =====
 +
 
 +
 
 +
Con el fin de que otra aplicación pueda seguir las llamadas registradas en pqcti, se ha previsto una nueva tabla en base de datos: DAT_CONX_DESATEN.
 +
 
 +
Dicha tabla integra todos los registros de todos los nodos vivait y será mantenida por el dialplan.
 +
 
 +
 
 +
Por supuesto, esa tabla sólo tiene sentido cuando "llamadas_registrar=true".
 +
 
 +
 
 +
 
 +
:{|
 
|-
 
|-
| MYSQL/cnx || Conectado (1) a MySQL
+
|
|-
+
 
| NAS/llamadas || Alojamiento en NAS de llamadas activo (grabación de llamada completa en un único archivo)
+
------
|-
+
CREATE TABLE IF NOT EXISTS `nimitz`.`DAT_CONX_DESATEN`
| NAS/segmentos || Alojamiento en NAS de segmentos activo
+
(
|-
+
  `ID` INT NOT NULL AUTO_INCREMENT,
| REC/llamNum || Llamadas procesadas
+
  `D_HORA_INICIO` DATETIME NULL,
|-
+
  `D_HORA_FIN` DATETIME NULL,
| REC/llamErr || Llamadas con error
+
  `N_DURACION` INT NULL DEFAULT 0,
|-
+
  `ID_NODO` INT NULL DEFAULT NULL,
| REC/segmNum || Segmentos procesados
+
  `C_UCID` VARCHAR(32) NULL,
|-
+
  `C_ORIGEN_NUM` VARCHAR(32) NULL,
| REC/segmErr || Segmentos con error
+
  `C_ORIGEN_NAME` VARCHAR(128) NULL,
|-
+
  `C_ORIGEN_EXTEN` VARCHAR(32) NULL,
| NODO/fase  || Número de proceso de recordCentral
+
  `C_DESTINO_NUM` VARCHAR(32) NULL,
|-
+
  `C_DESTINO_NAME` VARCHAR(128) NULL,
| NODO/cuarentena  || Lista de nodos en cuarentena, separada por comas
+
  `ID_DISPOSITIVO` VARCHAR(32) NULL,
|-
+
  PRIMARY KEY (`ID`),
| NODO/descarga || Lista de nodos en descarga, separada por comas
+
  UNIQUE INDEX `IDX_UCID_UNIQUE` (`C_UCID` ASC)
|-
+
VISIBLE,
| NODO/gestion || Lista de nodos gestionados, separada por comas (cuarentena + descarga = gestión)
+
  INDEX `IDX_HORA_INICIO` (`D_HORA_INICIO` ASC)
|}
+
VISIBLE)
 +
------
  
Como complemento a los diagnósticos:
+
|} <br>
* Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/recordCentral.pconf'''
+
 
 +
 
 +
 
 +
===== Interfaz para los servicios =====
 +
 
 +
 
 +
Todos los servicios están implementados en base a un POST con un json en el cuerpo de la solicitud, que contiene los parámetros de invocación, y otro json en el cuerpo de la respuesta.
 +
 
 +
En ambos casos, el json es un objeto con campos.
 +
 
 +
Está implementada, como opción, el uso de un GET con parámetros, pero no se recomienda su uso, excepto para pruebas, porque puede haber problemas con el conjunto de caracteres no ascii.
 +
 
 +
Si no hay problemas a nivel de red, de transporte o en las reglas básicas del comando, el estado de la respuesta es siempre "200 OK", indicándose los posibles errores en el json de respuesta.
 +
 
 +
Todas las respuestas contienen un campo denominado "resultado" (de la ejecución) que puede tomar los siguientes valores:
 +
 
 +
 
 +
 
 +
* '''OK.''' La ejecución se ha iniciado correctamente. En el caso de la llamada saliente, no quiere decir que se haya establecido y, ni siquiera, que se haya iniciado porque puede que la extensión no descuelgue.
 +
 
 +
* '''ERROR.''' Hay un error en los parámetros de invocación o en el estado de la llamada referida y no se puede ejecutar el comando solicitado.
 +
 
 +
* '''NO_EJECUTADO.''' Hay un problema no achacable a quién invoca y no se puede ejecutar el comando.
 +
 
 +
 
 +
 
 +
Si El "resultado" no es "OK", se devuelve un campo "diagnóstico" con una cadena que describe el problema detectado. Siempre es texto en español, por lo que su uso previsto es para logs.
 +
 
 +
 
 +
 
 +
 
 +
 
 +
===== Descipción de comandos y respuestas de json =====
 +
 
 +
 
 +
A partir de aquí se describen los comandos y respuestas en base a json de ejemplo, ya que los campos son triviales y autoexplicativos:
  
El fichero es el siguiente:
 
 
#
 
# Configuracion de recordCentral.pl
 
#
 
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
 
$depurar = 1;
 
 
# 0: Arranca como proceso - 1: arranca como demonio
 
$soyDemonio = 1;
 
 
# Archivo de log ('': salida estandar)
 
$logArch = '/var/log/record/recordCentral.log';
 
 
# Archivo para el pid (eliminando el .pid final)
 
$pidArch = '/var/run/record/recordCentral';
 
 
# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
 
$unaVezSolo = 0;
 
 
# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
 
$toBucle = 10;
 
 
# Bytes por segundo en archivos de grabaciones
 
$bytesPorSegundo = 16000;
 
 
# Bytes a leer en cada accceso a disco
 
$bytesLeerBuf = 1048576;
 
 
# Conexion de base de datos
 
$db='nimitz';
 
$dbHost = 'BDTR';
 
$dbPort = '3306';
 
$dbUsuario = 'nimitz';
 
$dbClave = 'ivivanimitz';
 
 
# Configuracion de la supervision
 
$supPort = '1114';
 
 
# Configuracion de archivos con grabaciones (Orig en nodo)
 
$grabHay = 0;
 
$grabAudioCalidad = 32;
 
$grabAudioFormato = 'mp3';
 
$grabAudioExten = 'mp3';
 
$grabAudioCifrado = 0;
 
$grabRutaUsaTimestamp = 1;
 
$grabRutaOrig = '/var/lib/recordNodo/grabaciones';
 
$grabRutaTmp = '/var/lib/recordProcesad/grabTmp';
 
$grabRutaDest = '/var/lib/recordProcesad/grabRecord';
 
$grabRutaError = '/var/lib/recordProcesad/grabError';
 
$segmHay = 1;
 
$segmUmbralTiempo = 10;
 
$segmMargenTiempo = 5;
 
$segmAudioCalidad = 32;
 
$segmAudioFormato = 'mp3';
 
$segmAudioExten = 'mp3';
 
$segmAudioCifrado = 0;
 
$segmRutaUsaTimestamp = 1;
 
$segmRutaTmp = '/var/lib/recordProcesad/segmTmp';
 
$segmRutaDest = '/var/lib/recordProcesad/segmRecord';
 
$segmRutaError = '/var/lib/recordProcesad/segmError';
 
 
# Seleccion de tipos de segmento a grabar separados por comas ('' = todos)
 
$tiposSegmentoGrabar = '';
 
 
# Indica si se graba ring
 
$grabarRing = 0;
 
 
# Minino numero de segundos para generar segmento externo
 
$segmExternoMinSegs = 10;
 
 
  
 +
*'''cmd_llamar -> Inicia una llamada saliente desde una extensión vivait-call.'''
  
*Los campos del fichero de configuración son los siguientes:
+
Resultado esperado :  
  
{| class="wikitable"
+
:{|
 
|-
 
|-
!Campo !!Descripción !!Posibles valores (si aplica)
+
|
|-
+
cmd={
|recordCentral.pconf|| ||
+
  "comando": "cmd_llamar",
|-
+
  "extension": "201",
|Variable a modificar||Comentarios||
+
  "ani_num": "201",
|-
+
  "ani_name": "ext_201",
|$depurar||# 0: Solo alarmas en archivo log - 1: alarmas y trazas||
+
  "dnis_num": "221",
|-
+
  "dnis_name": "ext_221"
|$soyDemonio||# 0: Arranca como proceso - 1: arranca como demonio||
+
}
|-
+
resp={
|$logArch =||# Archivo de log ('': salida estandar)||
+
  "comando": "cmd_llamar",
 +
  "ucid": "20999000031643889797",
 +
  "estado_actual": "llam_sale_espera",
 +
  "resultado": "OK",
 +
  "ahora": "20220203 130317.107"
 +
}
 +
 
 +
|} <br>
 +
 
 +
En el comando, sólo son obligatorios: comando, extension y dnis_num. El resto son opcionales. Los campos "ani" no deben usarse, salvo por una buena razón.
 +
El campo "dnis_num" sólo sirve para presentar el dato en el display de la extensión que
 +
inicia la llamada.
 +
 
 +
 
 +
 
 +
 
 +
*'''cmd_liberar -> Libera una llamada establecida, que haya sido registrada en pqcti.'''
 +
 
 +
:{|
 
|-
 
|-
|$pidArch||# Archivo para el pid (eliminando el .pid final)||
+
|
 +
 
 +
cmd={
 +
  "comando": "cmd_liberar",
 +
  "ucid": "20999000031643889797"
 +
}
 +
resp={
 +
  "comando": "cmd_liberar",
 +
  "ucid": "20999000031643889797",
 +
  "resultado": "OK",
 +
  "ahora": "20220203 130804.526"
 +
}
 +
 
 +
|} <br>
 +
 
 +
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
 +
 
 +
 
 +
 
 +
*'''info_llamadas -> Informa sobre las llamadas registradas en pqcti. Devuelve un array con la información de cada llamada.'''
 +
 
 +
:{|
 
|-
 
|-
|$unaVezSolo||# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)||
+
|
 +
}
 +
resp={
 +
  "comando": "info_llamadas",
 +
  "llamadas": [
 +
    {
 +
      "ucid": "20999000051643890188",
 +
      "estado_actual": "llam_sale_iniciada",
 +
      "duracion_segundos": 8
 +
    }
 +
  ],
 +
  "resultado": "OK",
 +
  "ahora": "20220203 130957.149"
 +
}
 +
 
 +
|} <br>
 +
 
 +
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
 +
 
 +
 
 +
*'''info_llamadas_num -> IDevuelve el número de llamadas registradas en pqcti.'''
 +
 
 +
:{|
 
|-
 
|-
|$toBucle||# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas||
+
|
 +
 
 +
resp={
 +
  "comando": "info_llamadas_num",
 +
  "llamadas_num": 1,
 +
  "resultado": "OK",
 +
  "ahora": "20220203 131001.134"
 +
}
 +
 
 +
|} <br>
 +
 
 +
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
 +
 
 +
 
 +
 
 +
 
 +
*'''info_llamada , "ucid"-> "20999000051643890188" -> IDevuelve el número de llamadas registradas en pqcti.'''
 +
 
 +
:{|
 
|-
 
|-
|$bytesPorSegundo||# Bytes por segundo en archivos de grabaciones||
+
|
 +
 
 +
resp={
 +
  "comando": "info_llamada",
 +
  "ucid": "20999000051643890188",
 +
  "estado_actual": "llam_sale_iniciada",
 +
  "duracion_segundos": 14,
 +
  "resultado": "OK",
 +
  "ahora": "20220203 131003.638"
 +
}
 +
|} <br>
 +
 
 +
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
 +
 
 +
 
 +
<br>
 +
 
 +
==== Vivait-CTI ====
 +
Permite la comunicación entre la aplicación '''''VIVA'''''it Desk de agente y el asterisk, sincronizando; convierte el protocolo “asterisk manager” a CSTA ('''''VIVA'''''it Desk “habla” CSTA).
 +
 
 +
Es un proceso importante para el uso de '''''VIVA'''''it Desk, y para 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 '''''VIVA'''''it 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:
 +
 
 +
{| class="wikitable"
 
|-
 
|-
|$bytesLeerBuf||# Bytes a leer en cada accceso a disco||
+
!ver!!Versión del proceso
 
|-
 
|-
|$db||Nombre de la base de datos||
+
|sis/inic||Fecha de arranque del proceso
 
|-
 
|-
|$dbHost||IP o HOST máquina base de datos de tiempo real||
+
|Sis/alarmas||Alarmas desde arranque
 
|-
 
|-
|$dbPort||Puerto de escucha de mysql||
+
|Sis/ultAlar||Fecha de última alarma
 +
|-
 +
|Gmp/msj||
 +
|-
 +
|Gmp/buf||
 +
|-
 +
|Gmp/tarea||
 
|-
 
|-
|$dbUsuario||Usuario acceso Base de datos de tiempo real||
+
|Tmp/uptime||
 
|-
 
|-
|$dbClave||Clave usuario acceso base de datos de tiempo real||
+
|Cti/numConx||Número de conexiones actuales / Número de conexiones máximo
 
|-
 
|-
|$supPort ||Puerto de supervision del demonio||
+
|Cti/numPend||
 
|-
 
|-
|$grabHay||Hay fase de enrutamiento o no||
+
|Cti/numMakeCallPend||Llamadas pendientes de realizar
 
|-
 
|-
|$grabAudioCalidad||Calidad del audio ||
+
|Cti/numcall||
 
|-
 
|-
|$grabAudioFormato||Formato del archivo de grabacion||
+
|Cti/numChan||
 
|-
 
|-
|$grabAudioExten||Extensión del archivo de grabacion||
+
|Cti/numAuxStr||
 
|-
 
|-
|$grabAudioCifrado||Si el archivo de grabación va cifrado ||
+
|Cti/numMoniColas||Número de colas monitorizadas
 
|-
 
|-
|$grabRutaUsaTimestamp||||
+
|Cti/numMoniDevice||
 
|-
 
|-
|$grabRutaOrig||# Directorio donde se localizan las grabaciones de llamadas||
+
|Cti/numMoniCall||
 
|-
 
|-
|$grabRutaTmp||Directorio temporal de las grabaciones de llamadas||
+
|Cti/numMoniCallAuto||
 
|-
 
|-
|$grabRutaDest||# Directorio Destino de  las grabaciones de llamadas||
+
|Cti/numMoniCallByDevice||
 
|-
 
|-
|$grabRutaError||# Directorio  de  las grabaciones de llamadas con error||
+
|Cti/numMoni||
 
|-
 
|-
|$segmHay||Hay segmentos||1 hay segmentos – 0 no hay
+
|Cti/auditCallErr||
 
|-
 
|-
|$segmUmbralTiempo||||
+
|Cti/auditAuxStrErr||
 
|-
 
|-
|$segmMargenTiempo||Tiempo que se coge antes y despues del segmento||
+
|Cti/ auditMsjReqErr||
 
|-
 
|-
|$segmAudioCalidad||Calidad del audio ||
+
|Cti/ araChanID||
 
|-
 
|-
|$segmAudioFormato||Formato del archivo de grabacion||
+
|Cti/ araUniqueID||
 
|-
 
|-
|$segmAudioExten||Extensión del archivo de grabación||
+
|Cti/ araMoni||
 
|-
 
|-
|$segmAudioCifrado||Si el archivo de grabación va cifrado ||1 se cifra – 0 no se cifra
+
|Ami/esta||Estado de conexión contra manarger de asterisk
 
|-
 
|-
|$segmRutaUsaTimestamp||||
+
|Ami/resp||
 
|-
 
|-
|$segmRutaTmp ||Ruta temporal||
+
|Ami/evs||Número de eventos (último minuto)
 
|-
 
|-
|$segmRutaDest = ||Ruta donde se almacenan los archivos de grabación||
+
||Ami/descar
 
|-
 
|-
|$segmRutaError||Ruta de los archivos de grabación con error||
+
|Ami/err||Errores
 
|-
 
|-
|$tiposSegmentoGrabar||# Selección de tipos de segmento a grabar separados por comas ('' = todos)||
+
|Ami/errConx||Errores de conexión
 
|-
 
|-
|$grabarRing||# Indica si se graba ring||1 se graba – 0 no se graba
+
|Ami/numAct||
 
|-
 
|-
|$segmExternoMinSegs||# Mínino número de segundos para generar segmento externo||
+
|Ami/auditErrAct||
 
|-
 
|-
 
|}
 
|}
  
 +
Como complemento a los diagnósticos:
  
<!--
+
Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/vivait-cti.conf'''
:Se explican a continuación las variables más importantes del proceso RecordCentral:
 
  
# Conexion de base de datos
+
*El fichero de configuración, '''vivait-cti.conf''', es el siguiente:
$db='nimitz';
 
$dbHost = 'BDTR';
 
$dbPort = '3306';
 
$dbUsuario = 'nimitz';
 
$dbClave = 'ivivanimitz';
 
  
# Configuracion de archivos con grabaciones (Orig en nodo)
+
#
$grabHay = 0;
+
# Los nombres no pueden tener numeros
$grabAudioCalidad = 32;
+
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
$grabAudioFormato = 'ogg';
+
# Los valores comentados indican valores por defecto
$grabAudioExten = 'ogg';
+
$grabAudioCifrado = 0;
+
base
$grabRutaUsaTimestamp = 1;
+
{
$grabRutaOrig = '/var/lib/recordNodo/grabaciones';
+
cfg
$grabRutaTmp = '/var/lib/recordProcesad/grabTmp';
+
{
$grabRutaDest = '/var/lib/recordProcesad/grabRecord';
+
soy_demonio = 1
$grabRutaError = '/var/lib/recordProcesad/grabError';
+
hay_syslog = 0
$segmHay = 1;
+
# Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)
$segmUmbralTiempo = 10;
+
archivo_pid = -
$segmMargenTiempo = 5;
+
# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)
$segmAudioCalidad = 32;
+
  # No se usa si se activa hay_syslog
$segmAudioFormato = 'ogg';
+
archivo_traza = -
$segmAudioExten = 'ogg';
+
}
$segmAudioCifrado = 0;
+
cfg_recarga
$segmRutaUsaTimestamp = 1;
+
{
$segmRutaTmp = '/var/lib/recordProcesad/segmTmp';
+
  # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
$segmRutaDest = '/var/lib/recordProcesad/segmRecord';
+
nivel_traza = 3
$segmRutaError = '/var/lib/recordProcesad/segmError';
+
pruebas = 1
 
+
hay_flush_traza = 1
# Seleccion de tipos de segmento a grabar separados por comas ('' = todos)
+
}
$tiposSegmentoGrabar = '';
+
sis
 
+
{
# Indica si se graba ring
+
# No se usa. No modificar
$grabarRing = 0;
+
subsistema = 0
 
+
}
-->
+
gmp
 
+
{
* Podremos examinar los logs del proceso en '''/var/log/recordCentral.log'''
+
  # Numero de mensajes. No modificar
<!-- En la versión 3.6.0. del instalador se adjuntan los siguientes archivos en el paquete recordCentral:
+
num_msj = 1024
 
+
# Numero de buffer. No modificar
borraGrabaciones.pconf: Debe colocarse en /etc/MDtel y contiene los datos de acceso a BBDD así como los días de caducidad de las grabaciones.
+
num_buf = 1024
borraGrabaciones.pl: El script. Se ejecuta con el archivo de configuración como parámetro (mueveGrabaciones.pl /etc/MDtel/mueveGrabaciones.pconf)
+
}
borraGrabaciones: Fichero cron. Contiene la programación del script. Debe colocarse en /etc/cron.d
+
}
-->
 
 
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
 
 
==== 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 ''VIVA''it'''.
 
 
 
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 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:
 
{| class="wikitable"
 
|-
 
! Parámetro  !! Descripción
 
|-
 
| SIS/ver || Versión del proceso
 
|-
 
| SIS/inic || Fecha 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
 
|}
 
 
 
Como complemento a los diagnósticos:
 
* Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/recordNodo.pconf'''
 
:Se muestra a continuación el fichero de configuración:
 
 
   
 
   
  #
+
  supercolas
  # Configuracion de recordNodo.pl
+
  {
#
+
en_comandos = 0
  # 0: Solo alarmas en archivo log - 1: alarmas y trazas
+
en_eventos = 0
  $depurar = 1;
+
  # archivo_conf = supercolas.conf
 +
  }
 
   
 
   
  # 0: Arranca como proceso - 1: arranca como demonio
+
  supervision
  $soyDemonio = 1;
+
  {
 +
puerto_escucha = 1111
 +
}
 
   
 
   
  # Archivo de log ('': salida estandar)
+
cti
  $logArch = '/var/log/record/recordNodo.log';
+
{
 +
hay_cti = 1
 +
  # Dimensionamiento de recursos. Uno menos, ya que cero no vale
 +
max_conx = 512
 +
max_call = 2048
 +
max_channel = 4096
 +
max_monitor = 512
 +
max_str_aux = 512
 +
puerto_escucha = 4500
 +
link_id = 1
 +
  #
 +
hay_vdn = 1
 +
hay_usuarios = 1
 +
usuarios
 +
{
 +
vivait
 +
{
 +
clave = 3RSMbPlTi61rG5pySx9hhUokz8Fyy3Nql2w8Jairfl8=
 +
ip = 0.0.0.0
 +
msk = 0.0.0.0
 +
}
 +
}
 +
}
 
   
 
   
  # Archivo para el pid (eliminando el .pid final)
+
cti_recarga
  $pidArch = '/var/run/record/recordNodo';
+
{
   
+
makeCall_primero_dentro = 1
  # 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
+
makeCall_primero_fuera_agente_descuelga = 1
$unaVezSolo = 0;
+
temporizador_makeCall = 30
   
+
fmt_canal_exten = SIP/%s
  # Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
+
  # contextos para llamadas salientes makeCall y makePredictiveCal
$toBucle = 5;
+
contexto_makeCall_primeroFuera = Cen_MakeCallPrimeroFuera
+
contexto_makeCall_primeroFueraDentro = Cen_MakeCallPrimeroFueraDentro
  # Tiempo de guarda en segundos desde D_HORA_FIN hasta que se procesa llamada
+
contexto_makeCall_primeroDentro = Cen_MakeCallPrimeroDentro
  $toProcesar = 30;
+
  # contextos para llamadas salientes desde myAcdSuperv
 +
contexto_myAcdSuperv_ProgreFuera = Cen_myAcdSuperv_ProgreFuera
 +
contexto_myAcdSuperv_ProgreDentro = Cen_myAcdSuperv_ProgreDentro
 +
contexto_myAcdSuperv_PredicFuera = Cen_myAcdSuperv_PredicFuera
 +
contexto_myAcdSuperv_PredicDentro = Cen_myAcdSuperv_PredicDentro
 +
  # contexto para transferencias
 +
contexto_redirect = Cen_Redirect
 +
  # expresiones regulares. se evaluan en el orden indicado
 +
expr_esExtenLocal = ^(4)[0-9]{4}$
 +
expr_esExtenInterna = -
 +
expr_esCola = ^(8)[0-9]{4}$
 +
expr_esPuntoDistribucion = ^(9)[0-9]{4}$
 +
expr_esPuntoEnrutamiento = -
 +
expr_esNumPrivateLocal = ^[369][0-9][0-9][0-9][0-9]$
 +
expr_esNumPrivateUnknown = ^[369]
 +
expr_esNumPublicNational = ^0?[69][0-9]{8}$
 +
expr_esNumPublicInternational = ^000[0-9]*
 +
  # resto siempre esNumPublicUnknown
 +
  #
 +
audit_hay_Call = 1
 +
audit_call_minutContestada = 60
 +
audit_call_minutNoContestada = 5
 +
audit_hay_AuxStr = 1
 +
audit_AuxStr_minut = 2
 +
audit_hay_MsjReq = 1
 +
audit_MsjReq_minut = 2
 +
  #
 +
  }
 
   
 
   
  # Bytes por segundo en archivos de grabaciones
+
  ami
  $bytesPorSegundo = 16000;
+
  {
 +
max_action = 128
 +
ip_asterisk = localhost
 +
puerto_ami = 5038
 +
usuario_ami = vivait
 +
clave_ami = vivactisecret
 +
to_inac = 30
 +
to_audit = 600
 +
audit_max_resp = 3
 +
}
 
   
 
   
# Bytes a leer en cada accceso a disco
+
 
$bytesLeerBuf = 1048576;
+
 
+
Los siguientes son los campos del fichero de configuración:
# Conexion de base de datos
+
 
$db='nimitz';
+
{| class="wikitable"
$dbHost = 'BDTR';
+
|-
$dbPort = '3306';
+
!Campo !!Descripción !!Posibles valores (si aplica)
$dbUsuario = 'nimitz';
+
|-
$dbClave = 'ivivanimitz';
+
|soy_demonio||# 0: Arranca como proceso - 1: arranca como demonio||
+
|-
# Configuracion de la supervision
+
|hay_syslog||Si hay servidor de syslog||1 lo hay – 0 no lo hay
$supPort = '1113';
+
|-
+
|archivo_pid||# Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)||
# Quien es mi nodo para filtrar grabaciones
+
|-
$miNodo = 2;
+
|archivo_traza||# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)||
 
# Directorio donde se localizan las grabaciones
 
$grabRutaOrig = '/var/spool/asterisk/monitor';
 
$grabRutaDest = '/var/lib/recordNodo/grabaciones';
 
$grabRutaError = '/var/lib/recordNodo/grabError';
 
$grabRutaUsaTimestamp = 1;
 
 
# Tiempo en segundos limite a truncar en las grabaciones (0=sin limite)
 
$grabLimiteSegs = 0;
 
 
# Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminacion
 
$segmEliminarGrabacionTrato = 1;
 
$patronEliminarGrabacion = '/etc/MDtel/null.bin';
 
 
 
 
*A continuación se indican los campos del fichero:
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
!Campo !!Descripción !!Posibles valores (si aplica)
+
|nivel_traza||# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)||
 
|-
 
|-
|$depurar||# 0: Solo alarmas en archivo log - 1: alarmas y trazas||
+
|pruebas||||
 
|-
 
|-
|$soyDemonio||# 0: Arranca como proceso - 1: arranca como demonio||
+
|hay_flush_traza||||
 
|-
 
|-
|$logArch||# Archivo de log ('': salida estandar)||
+
|subsistema||# No se usa. No modificar||
 
|-
 
|-
|$pidArch||# Archivo para el pid (eliminando el .pid final)||
+
|num_msj||# Numero de mensajes. No modificar||
 
|-
 
|-
|$unaVezSolo||# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)||
+
|num_buf||# Numero de buffer. No modificar||
 
|-
 
|-
|$toBucle||# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas||
+
|en_comandos||||
 
|-
 
|-
|$toProcesar||# Tiempo de guarda en segundos desde D_HORA_FIN hasta que se procesa llamada||
+
|en_eventos||||
 
|-
 
|-
|$bytesPorSegundo||# Bytes por segundo en archivos de grabaciones||
+
|archivo_conf||Archivo configuracion de asterisk para las supercolas||
 
|-
 
|-
|$bytesLeerBuf||# Bytes a leer en cada accceso a disco||
+
|puerto_escucha||Puerto de supervision del demonio||
 
|-
 
|-
|$db||Nombre de la base de datos||
+
|hay_cti||hay cti||1 hay cti – o no hay
 
|-
 
|-
|$dbHost||IP o HOST máquina base de datos de tiempo real||
+
|max_conx||Numero maximo de conexiones||
 
|-
 
|-
|$dbPort||Puerto de escucha de mysql||
+
|max_call||Numero maximo de llamadas||
 
|-
 
|-
|$dbUsuario||Usuario acceso Base de datos de tiempo real||
+
|max_channel||Numero maximo de canales||
 
|-
 
|-
|$dbClave||Clave usuario acceso base de datos de tiempo real||
+
|max_monitor||Numero maximo de grabaciones||
 
|-
 
|-
|$supPort||Puerto de supervision del demonio||
+
|max_str_aux||||
 
|-
 
|-
|$miNodo||# Quien es mi nodo para filtrar grabaciones||
+
|puerto_escucha||Puesto escucha del demonio||
 
|-
 
|-
|$grabRutaOrig||# Directorio donde se localizan las grabaciones||
+
|link_id||||
 
|-
 
|-
|$grabRutaDest ||Directorio destino de las grabaciones procesadas||
+
|hay_vdn||Existen vdns||1 existen – o no existen
 
|-
 
|-
|$grabRutaError||Directorio destino de las grabacionescon error||
+
|hay_usuarios||Existen usuarios||1 existen – o no existen
 
|-
 
|-
|$grabRutaUsaTimestamp||||
+
|clave||Clave usuario cti cifrada||
 
|-
 
|-
|$grabLimiteSegs||# Tiempo en segundos limite a truncar en las grabaciones (0=sin limite)||
+
|ip||Direcion de red de escucha del cti||
 
|-
 
|-
|$segmEliminarGrabacionTrato||# Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminacion||1 se procesa – 0 no se procesa
+
|msk||Mascara de red de escucha del cti||
 +
|-
 +
|makeCall_primero_dentro||||
 +
|-
 +
|makeCall_primero_fuera_agente_descuelga||||
 +
|-
 +
|temporizador_makeCall||Tiempo maximo para realizar llamada||
 +
|-
 +
|fmt_canal_exten||||
 +
|-
 +
|contexto_makeCall_primeroFuera||# contextos para llamadas salientes makeCall y makePredictiveCal||
 +
|-
 +
|contexto_makeCall_primeroFueraDentro||# contextos para llamadas salientes makeCall y makePredictiveCal||
 +
|-
 +
|contexto_makeCall_primeroDentro||# contextos para llamadas salientes makeCall y makePredictiveCal||
 +
|-
 +
|contexto_myAcdSuperv_ProgreFuera||# contextos para llamadas salientes desde myAcdSuperv||
 +
|-
 +
|contexto_myAcdSuperv_ProgreDentro||# contextos para llamadas salientes desde myAcdSuperv||
 +
|-
 +
|contexto_myAcdSuperv_PredicFuera||# contextos para llamadas salientes desde myAcdSuperv||
 +
|-
 +
|contexto_myAcdSuperv_PredicDentro||# contextos para llamadas salientes desde myAcdSuperv||
 +
|-
 +
|contexto_redirect||# contexto para transferencias||
 +
|-
 +
|expr_esExtenLocal||# expresiones regulares. Se evaluan en el orden indicado||
 +
|-
 +
|expr_esExtenInterna ||# expresiones regulares. Se evaluan en el orden indicado||
 +
|-
 +
|expr_esCola||# expresiones regulares. Se evaluan en el orden indicado||
 
|-
 
|-
|$patronEliminarGrabacion||Patron de eliminacion||'/etc/MDtel/null.bin'--> para utilizar '''silencio'''
+
|expr_esPuntoDistribucion||# expresiones regulares. Se evaluan en el orden indicado||
'/etc/MDtel/pito.slin'--> para utilzar un '''pitido''' (va asociado al fichero pito.slin).
 
 
|-
 
|-
|}
+
|expr_esPuntoEnrutamiento||# expresiones regulares. Se evaluan en el orden indicado||
 
+
|-
<!--
+
|expr_esNumPrivateLocal||# expresiones regulares. Se evaluan en el orden indicado||
:Se muestran a continuación las variables que son modificadas con mayor frecuencia:
+
|-
# Conexion de base de datos
+
|expr_esNumPrivateUnknown||# expresiones regulares. Se evaluan en el orden indicado||
$db='nimitz';
+
|-
$dbHost = 'BDTR';
+
|expr_esNumPublicNational||# expresiones regulares. Se evaluan en el orden indicado||
$dbPort = '3306';
+
|-
$dbUsuario = 'nimitz';
+
|expr_esNumPublicInternational||# expresiones regulares. Se evaluan en el orden indicado||
$dbClave = 'ivivanimitz';
+
|-
 
+
|audit_hay_Call||||
# Quien es mi nodo para filtrar grabaciones
+
|-
$miNodo = 1;
+
|audit_call_minutContestada||||
 
+
|-
# Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminación
+
|audit_call_minutNoContestada||||
$segmEliminarGrabacionTrato = 1;
+
|-
$patronEliminarGrabacion = '/etc/MDtel/null.bin';
+
|audit_hay_AuxStr||||
 
+
|-
 
+
|audit_AuxStr_minut||||
 
+
|-
-->
+
|audit_hay_MsjReq||||
* Podremos examinar los logs del proceso en '''/var/log/recordNodo.log'''
+
|-
 
+
|audit_MsjReq_minut||||
 
+
|-
 
+
|max_action||Numero maximo de acciones en el manager de asterisk||
==== Sercen ====
+
|-
 
+
|ip_asterisk||Ip del asterisk de ACD||
Sercen (Servicios Centrales) es un demonio de VIVAit que provee servicios centralizados
+
|-
a muchos elementos de la arquitectura. Sirve para identificar a los usuarios y garantizar
+
|puerto_ami||Puerto del manager de asterisk ACD||
que los mismos sean quienes dicen ser.
+
|-
Puede haber varias instancias en el, y diferentes servicios pueden estar en diferentes
+
|usuario_ami||Usuario del manager de asterisk del ACD||
Sercen
+
|-
 +
|clave_ami||Clave del manager de asterisk del ACD||
 +
|-
 +
|to_inac||Timeout de inactividad||
 +
|-
 +
|to_audit||||
 +
|-
 +
|audit_max_resp||Tiempo maximo de respuesta||
 +
|-
 +
|}
  
  
Ejemplos de servicios:
+
* Podremos examinar los logs del proceso en '''/var/log/vivait-cti.conf'''
  
'''- Autenticación, de factor simple o doble factor'''
+
==== Introducción al aprovisionamiento ====
  
'''- Integración con proveedores de autenticación'''
+
En cada Centralita Telefónica existente, se puede configurar sus teléfonos IP y asignarles extensiones a cada teléfono. Para hacer un ''aprovisionamiento'' de los teléfonos es necesario que el técnico configure uno a uno manualmente utilizando su interfaz web, esto no es práctico, ya que genera muchos errores y el tiempo de implementación se incrementa drásticamente. Además, es casi imposible la administración cotidiana de los teléfonos IP. Desde '''MD'''tel se utiliza una herramienta que permite que los teléfonos IP soportados y homologados por '''MD'''tel ([[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Documentaci%C3%B3n_de_usuario_VIVAit_Call_3.0#Terminales_telef.C3.B3nicos ver Terminales telefónicos]]) se puedan aprovisionar automáticamente, brindando una fácil implementación y administración cotidiana.
  
'''- Click2talk (Demonio dentro de Vivait)'''
 
  
 +
===== ¿Qué es aprovisionar? =====
  
Sercen permite autenticar un usuario (simple factor o doble factor), utilizando para ello
+
Aprovisionar un teléfono es el proceso de configuración automático de teléfonos IP para su uso con una Centralita Telefónica de forma remota. Una vez que aprovisione un teléfono, el teléfono automáticamente se configurará correctamente y podrá administrar los teléfonos de forma centralizada y remota, sin tener que iniciar sesión en la interfaz web de cada uno de los teléfonos.  
la base de datos de vivait y/u otro mecanismo externo, como puede ser el directorio
 
activo de Microsoft.
 
  
SerCen se relaciona con :
+
El aprovisionamiento de teléfono facilita enormemente la administración cotidiana de los teléfonos IP. Esto hace que sea fácil de cambiar las contraseñas de extensión,realizar desvíos de llamadas, nombre a mostrar, mensajería y demás configuraciones, ya que puede hacerlo de forma centralizada para todos los teléfonos desde el portal de administración y luego transferir los cambios al teléfono.
  
 +
===== TFTP =====
  
'''- BBDD'''
+
'''TFTP''' son las siglas de '''T'''rivial '''F'''ile '''T'''ransfer '''P'''rotocol ''(Protocolo de transferencia de archivos trivial)''.
  
'''- Asterisk (para el click2talk)'''
+
Es un protocolo de transferencia muy simple semejante a una versión básica de FTP. TFTP a menudo se utiliza para transferir pequeños archivos entre terminales en una red.
  
'''- VIVAit Meet (para por ejemplo las funciones “botón colaborar” y ”Recursos
+
Algunos detalles del TFTP:
compartidos”.'''
 
  
'''- Con los portales a los que proporciona los servicios vía webservice'''
+
* Utiliza UDP (puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza los  
 +
puertos 20 y 21 TCP).
 +
* No puede listar el contenido de los directorios.
 +
* No existen mecanismos de autenticación o cifrado.
 +
* Se utiliza para leer o escribir archivos de un servidor remoto.
 +
* Soporta tres modos diferentes de transferencia, "netascii", "octet" y "mail”.
  
 +
===== Funcionamiento del servidor phoneprove-TFTP =====
  
 +
A continuación se muestra un esquema que facilita el entendimiento del funcionamiento del servidor phoneprove-TFTP:
  
===== Interfaz para autenticación (app-webfon / serCen) =====
+
[[Archivo:Funcionamiento_Servidor.png‎ |center]]
  
 +
El servidor Phoneprove-TFTP se ''encarga del aprovisionamiento masivo de terminales'', es de gran utilidad porque cualquier cambio en los teléfonos pueden ser realizados a nivel DHCP y todos los teléfonos tomarán la nueva configuración luego de reiniciarlos.
  
 +
Desde phoneprove-TFTP se generara los archivos necesarios para cada teléfono y que sirven para ser aprovisionados automáticamente.
 +
El servidor phoneprove-TFTP  tiene alojados los ficheros de configuración están ordenados según las direcciones MAC de los teléfonos. El teléfono “preguntará” al servidor cual es su fichero de configuración utilizando su dirección MAC. Este a través de su MAC , consulta en la base de datos para ofrecer al terminal los datos de configuración según su plantilla, cual sera su extensión , cual sera el usuario propietario, entre otras cosas.
  
 +
{|
 +
|-
 +
|
 +
  '''Nota:''' En instalaciones grandes habrá más de uno, quizás uno por sede grande; depende de la infraestructura de DHCP.
 +
|}
  
 +
===== Parámetros necesarios de Aprovisionamiento de Teléfonos =====
  
Este interfaz permite autenticar un usuario (simple factor o doble factor), utilizando para ello la base de datos de vivait y/u otro mecanismo externo, como puede ser el directorio activo de Microsoft. El objetivo es que app-webfon obtenga un token que debe incluirse en las comunicaciones con el resto de elementos para que estos conozcan que las solicitudes proceden de un usuario autenticado. Este token también puede utilizarse para que otras aplicaciones puedan se iniciadas desde app-webfon y no se requiera de un proceso específico de autenticación para cada aplicación. De modo recíproco, app- webfon debe soportar el ser invocado con un token y, en tal caso, considerar que el usuario ya está autenticado.
+
'''Notas:''' el aprovisionamiento desarrollado por '''MD'''tel, no emplea un fichero por cada
 +
teléfono, sino que emplea una plantilla por cada modelo de teléfono.
 +
Debe haber una '''configuración previa del servidor DHCP''' es necesario coordinar con el cliente la asignación de direcciones para
 +
los diferentes elementos de la plataforma '''''VIVA'''''it, fundamentalmente para terminales telefónicos; en este caso además será necesario
 +
activar la opción 66 que permitirá definir el servidor TFTP del que los terminales cogerán sus ficheros de aprovisionamiento.
 +
El aprovisionamiento desde el portal de administración solo es posible para aquellos teléfonos IP homologados y probados desde '''MD'''tel 
 +
[[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Documentaci%C3%B3n_de_usuario_VIVAit_Call_3.0#Terminales_telef.C3.B3nicos ver Terminales  telefónicos]]
  
  
Por ello, se asume que cada usuario conoce su clave. Independientemente de qui én gestione la clave, esta puede tener asociados periodos de expiración y de caducidad. Cuando finaliza el periodo de expiración, el usuario tiene que cambiar la clave obligatoriamente para poder acceder a sus credenciales (token). Tras la caducidad, ya no puede obtener credenciales válidas.
+
Como existen parámetros comunes de todos los teléfonos de la misma marca de fabricante, muchos de los parámetros necesarios para el aprovisionamiento  como comentamos se han generado desde MDtel en forma de plantillas, que estarán disponibles en el portal de administración VIVAit [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Plantillas | ver plantilla del portal de administración VIVAit]].  
  
 +
La configuración de un teléfono SIP es muy sencilla y en no es necesario tener conocimientos avanzados de informática o de telefonía. Cada una de estas plantillas que sirven para aprovisionar un teléfono IP homologado, algunos de los parámetros predeterminados se explicarán a continuación .
  
Cuando la autenticación utiliza las claves almacenadas en la base de datos vivait, serCen permite cambiar la clave. Si la validación de la clave se apoya en mecanismos externos (como puede ser el directorio activo), entonces serCen no soporta el cambio de claves, informando de ello en las respuestas correspondientes a los comandos de autenticación.
 
  
 +
====== Parámetros de Aprovisionamiento globales ======
  
 +
* Configuración de la red y MAC.
 +
* Zona horaria.
  
 +
====== Parámetros de Aprovisionamiento Personales ======
  
===== Comandos de SerCen =====
+
Además de los parámetros de aprovisionamiento globales, el teléfono también obtendrá información de configuración individual, tales como:
  
 +
*Número de Extensión.
 +
*Nombre y Contraseña de usuario SIP.
 +
*Configuración de Teclas BLF.
 +
*Contraseña de la Interfaz Web del Teléfono IP.
 +
*Idioma de la Pantalla.
 +
*Orden de Preferencia de los Codecs.
  
Los diferentes comandos de SerCen son:
+
===== Aprovisionamiento de teléfonos nivel usuario =====
  
 
+
{|
{| class="wikitable"
 
 
|-
 
|-
! COMANDOS !! DESCRIPCIÓN
+
|
|-
+
  '''Notas:''' La dirección MAC debe estar especificada en letras mayúsculas.
| autenticar1 || Para autenticar en base al primer factor (usuario y clave).
+
  La dirección MAC del teléfono se puede encontrar en la etiqueta adhesiva en la parte inferior del teléfono, o de lo contrario se deberá acceder desde
|-
+
  el menú del propio terminal.  
| autenticar2 || Para, si procede, autenticar en base al segundo factor (pin adicional).
 
|-
 
| autenticartokenaad || Autenticar empleando un token de "azure active directory"
 
|-
 
| validarToken || Para autenticar a un usuario en base a un token suministrado por otra aplicación
 
|-
 
| revalidarToken || Para ampliar el periodo de expiración de un token válido.
 
|-
 
| revocarToken || Para que un token deje de ser válido.
 
|-
 
| cambiarClave || Permite que una clave pueda se cambiada. Esto es posible cuando el usuario ha sido autenticado y, además, la clave tiene que estar siendo gestionada por vivait. Este cambio no es posible, por ejemplo, si se trata de una clave validada por un directorio activo.
 
 
|}
 
|}
  
 +
Los pasos a seguir son los siguientes:
  
 +
'''1)''' Dar de alta el teléfono en el portal de administración, se debe seleccionar el modelo del teléfono, e indicar la dirección MAC del teléfono a aprovisionar, todo ello desde el portal de administración VIVAit.
 +
Para mas información ver [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Aprovisionamiento del portal de administracion| aprovisionamiento del portal de administración VIVAit]].
  
====== Comandos autenticar1 ======
+
'''2)''' En el mismo portal de administración se deberá crear una extensión , asignar a la extensión el teléfono que se quiera aprovisionar, elegir la plantilla adecuada del teléfono y el usuario propietario (solo si sera un puesto fijo) desde [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Extensiones | extensiones del portal de administración]].
  
Comandos autenticar1 y respuestas posibles:
+
'''3)''' Conectar el teléfono a la red LAN informática (conectarlo al router o switch) para que tenga acceso a Internet:
  
autenticar1. Autenticación primer factor.
+
:*El teléfono enviará un mensaje de multidifusión a través de la LAN.  
 +
:*Este será captado por la Central Telefónica siempre que esté en la misma LAN.
 +
:*Al teléfono se le enviará una URL de aprovisionamiento.  
  
url (POST): https://<servidor_webfon>/sercen/postautenticar1
+
'''4)''' Como la mayoría de teléfonos IP del mercado al arrancar una vez sabiendo la URL de aprovisionamiento piden una serie de archivos de configuración para aprovisionarse vía TFTP. EL servidor phoneprove-TFTP, detectara la petición y a través de la MAC y datos del usuario, consultará en la base de datos los datos necesarios para aprovisionar al teléfono y si todo funciona correctamente mandara al teléfono IP los datos de configuración necesarios para funcionar.
  
datos de entrada:    '''{"cuenta": "fulano","clave$1aA": "dificil","aplicacion": "webfon","expira": 7200,"clvCambiar": "masdificil$1aA"}'''
+
'''5)''' Asegúrese de que el teléfono encuentren el servidor TFTP, para ello esperar un tiempo adecuado para que termine el aprovisionamiento.
  
* "expira" es opcional y siempre posible. Permite solicitar un periodo de expiración (segs) para el token devuelto.
 
  
* "clvCambiar" es opcional y solo se tiene en cuenta si no hay doble factor. Permite cambiar la clave del usuario, si es autenticado.
+
'''6)''' Finalmente aparecerá como registrado en la centralita, obtendrá una dirección IP y podra funcionar según la configuración establecida.
  
 
+
{|
'''Ejemplos de posibles respuestas:'''
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Ejemplo !! Respuesta
+
|
|-
+
  '''Nota''': Si no se reaprovisiona tras un periodo largo de tiempo, desenchufe el cable de alimentación eléctrica <br /> o el cable Ethernet (si se utiliza la alimentación en línea PoE) para reiniciar los teléfonos.
| ejRes1 || {"errorNum": 101,"errorCad": "Clave incorrecta"}
 
|-
 
| ejRes2 || {"errorNum": 115,"errorCad": "Clave caducada"}
 
|-
 
| ejRes3 || {"errorNum": 116,"errorCad": "Clave expirada","dobleFactor": "no","clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
 
|-
 
| ejRes4 || ejRes4: {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "email","clvExpira": 86400}
 
|-
 
| ejRes5 || {"errorNum":0,"errorCad":"OK","token": "1234567890","dobleFactor": "email","clvExpira": 86400}
 
|-
 
| ejRes6 || {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "no","token2": "0987654321","expira": 3600,"clvExpira": 86400,"clvPuedeCambiar": true,"clvHaCambiado": true,"clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
 
 
|}
 
|}
  
 +
===== Aprovisionamiento de teléfonos nivel técnico =====
  
Este comando se invoca para autenticar al usuario en base a cuenta y clave. Opcionalmente, se soporta un doble factor en base a un pin que se comunica al usuario mediante correo electrónico u otro medio.
+
====== Plantilla de configuración ======
  
El campo "expira" en la respuesta informa sobre el token devuelto. Dicho token es válido durante un periodo que se expresa en segundos a transcurrir desde el momento en que se informa.
+
La plantilla de configuración empleadas en el apartado  [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Plantillas | plantilla del portal de administración VIVAit]] de cada modelo está formada por una serie de variables.  
  
El campo "clvExpira" en la respuesta informa en segs. sobre cuando va a expirar la clave introducida y validada (errorNum=0). Si devuelve cero o no devuelve nada, quiere decir que no va a expirar por estar configurado de esa manera o porque es un autenticación ldap.
+
Los valores se obtienen de la tabla de la base de datos CEN_TELEFONOS, CEN_USUARIOS, ACD_EXTENSIONES, ACD_NODOS, COM_NODOS... correspondientes a la extensión del teléfono, usuario, nodo, etc.  
  
Al invocar este comando, app-webfon solicita, opcionalmente (campo "expira"), un periodo (en segundos) cuyo valor debe formar parte de su configuración. El valor finalmente válido es el que aparece con el mismo nombre en la respuesta (si finalmente es positiva) y si no hay doble factor.
+
variable ${NODO1_C_NOMBRE}='corp-ast13'
 +
variable ${EXTEN_C_CLAVE_REGISTRO}='Tel21002'
 +
variable ${USU_C_CODIGO_POSTAL}=''28034'
 +
variable ${SEDE_C_CODIGO_POSTAL}='28034'
 +
variable ${USU_C_NOMBRE}='Juan Antonio'
 +
variable ${USU_C_APELLIDO2}='Ramirez'
 +
variable ${SEDE_C_NOMBRE}='RED_LAB'
 +
variable ${NODO2_C_NOMBRE}= NULL
 +
variable ${EXTEN_C_NOMBRE}='' 21002
 +
variable ${USU_C_LOCALIDAD}=''
 +
variable ${USU_C_NOMBRE_MOSTRAR}='Juan'
 +
variable ${NODO1_C_IP}='175.25.129.70'
 +
variable ${MODEL_C_PREFIJO_PLANTILLA_MAC}='T28P'
 +
variable ${SEDE_C_LOCALIDAD}='Madrid'
 +
variable ${USU_C_APELLIDO1}='Casas'
 +
variable ${NODO2_C_IP}= NULL
 +
variable ${TF_ID_EXTENSION}='5'
 +
cargando campos idExten=5
  
Es responsabilidad de app-webfon el efectuar una solicitud para revalidar el token, mediante un procedimiento que se describirá posteriormente, tantas veces como considere necesario.
+
====== Ficheros y paquetes necesarios ======
  
 +
'''Paquetes previos:''' libnet-tftpd-perl, tftp-hpa, libnet-address-ip-local-perl
 +
'''Usuario de funcionamiento:''' root
  
 
+
{|
En lo que se refiere a las posibles respuestas a autenticar1, pueden darse varios casos:
 
 
 
Se produce un error: ejRes1 y ejRes2.
 
 
 
La clave ha expirado y no hay doble factor (ejRes3). Se invita a cambiar la clave invocando de nuevo a autenticar1 con "clvCambiar", para lo cuál se aportan datos de la complejidad requerida.
 
 
 
La clave es válida y hay doble factor en ejRes4.
 
 
 
La clave es válida y hay doble factor "totp" con usuario no enrolado en ejRes6. Se incluye un código QR que permite enrolar al usuario
 
 
 
 
 
La clave es válida y no hay doble factor en ejRes6. El usuario ha sido autenticado. Se devuelven "token" y "token2". También se informa sobre si es posible cambiar la clave ("clvPuedeCambiar") y sobre sus requerimientos de complejidad. Si el
 
comando autenticar1 hubiese incluido un cambio de clave mediante el campo "clvCambiar" y este cambio hubiese sido completado, se devolverá un booleano "clvHaCambiado" para informar de ello.
 
 
 
 
 
====== Comandos autenticar2 ======
 
 
 
 
 
Comandos autenticar2 y respuestas posibles:
 
 
 
autenticar2. Autenticación doble factor.
 
 
 
url (POST): https://<servidor_webfon>/sercen/postautenticar2
 
 
 
datos de entrada: '''{"token": "1234567890","pin": "1234","expira": 7200,"clvCambiar": "masdificil$1aA"}'''
 
 
 
* "expira" es opcional.
 
* "clvCambiar" es opcional. Permite cambiar la clave del usuario, si es autenticado.
 
 
 
 
 
'''Ejemplos de posibles respuestas:'''
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Ejemplo !! Respuesta
+
|
|-
+
  '''Nota:'''  los archivos y directorios que generemos podrian necesitar que se permitiera el acceso al archivo de lectura <br/> y escritura en el servidor TFTP.
| ejRes1 || {"errorNum": 102,"errorCad": "Pin incorrecto"}
 
|-
 
| ejRes2 || {"errorNum": 115,"errorCad": "Clave caducada"}
 
|-
 
| ejRes3 || {"errorNum": 116,"errorCad": "Clave expirada","clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
 
|-
 
| ejRes4 || ejRes4: {"errorNum": 0,"errorCad": "OK","token2": "0987654321","expira": 3600,"clvExpira": 86400,"clvPuedeCambiar": true,"clvHaCambiado": true,"clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
 
 
|}
 
|}
  
 +
'''Archivos necesarios:'''
  
Este comando se invoca para autenticar en base a un segundo factor: pin enviado por un medio de transporte independiente.
+
/usr/local/sbin/phoneprov-tftp.pl
 +
/usr/local/sbin/phoneprov-tftp.pm
 +
/etc/MDtel/phoneprov-tftp.pconf
 +
/etc/init/phoneprov-tftp.conf
 +
/etc/logrotate.d/phoneprov-tftp
  
El campo "expira" en la respuesta informa sobre el token enviado y token2 devuelto. Dichos token son válidos durante un periodo que se expresa en segundos a transcurrir desde el momento en que se informa.
 
  
 +
'''Directorios a crear:'''
  
El campo "clvExpira" en la respuesta informa en segs. sobre cuando va a expirar la clave introducida y validada (errorNum=0). Si devuelve cero o no devuelve nada, quiere decir que no va a expirar por estar configurado de esa manera o porque es un autenticación ldap.
+
/var/lib/phoneprov-tftp/plt
 +
/var/lib/phoneprov-tftp/bin
  
 +
*El archivo de configuración, '''phoneprov-tftp''', es el siguiente:
  
El campo que requiere explicación adicional es "token2". "token" puede ser traspasado a otras aplicaciones para evitar procesos de autenticación, pero esas aplicaciones (a las que no debe pasarse el valor de "token2") no podrán realizar operaciones relacionadas con el propio token, como puede ser revocarlo, cuando el usuario cierre el app-webfon. Es decir, el valor de "token2" sólo se requiere para operaciones de gestión del propio token. Sin "token2" tampoco es posible ejecutar el comando "cambiarClave".
+
#
 
+
# Configuracion de phoneprov-tftp.pl
 
+
#
En lo que se refiere a las posibles respuestas a autenticar2, pueden darse varios casos:
+
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
 
+
$depurar = 1;
 
+
Se produce un error: ejRes1 y ejRes2.
+
# 0: Arranca como proceso - 1: arranca como demonio
 
+
$soyDemonio = 1;
 
+
La clave ha expirado (ejRes3). Se invita a cambiar la clave invocando de nuevo a autenticar2 con "clvCambiar", para lo cuál se aportan datos de la complejidad requerida.
+
# Archivo de log ('': salida estandar)
 
+
$logArch = '/var/log/phoneprov-tftp.log';
 
+
El pin del doble factor es válido en ejRes4. El usuario ha sido autenticado. Se devuelve "token2" ("token" ya se tiene). También se informa sobre si es posible cambiar la clave ("clvPuedeCambiar") y sobre sus requerimientos de complejidad. Si el comando autenticar2 hubiese incluido un cambio de clave mediante el campo "clvCambiar" y este cambio hubiese sido completado, se devolverá un booleano "clvHaCambiado" para informar de ello.
+
# Archivo para el pid
 
+
$pidArch = '/var/run/phoneprov-tftp';
 
+
 
+
# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
 
+
$unaVezSolo = 0;
====== Comando autenticartokenaad ======
+
 
+
# Conexion de base de datos
 
+
$db='nimitz';
Autenticar empleando un token de "Azure active directory"
+
$dbHost = 'BDTR';
 
+
$dbPort = 3306;
 
+
$dbUsuario = 'nimitz';
  url (POST): https://<servidor_webfon>/sercen/postautenticartokenaad
+
$dbClave = 'ivivanimitz';
 
+
 
+
# Configuracion de la supervision
datos de entrada: '''{"token": "tokenrequetelargao","aplicacion": "webfon","expira": 7200} ("expira" es opcional).'''
+
$supPort = 1123;
 
+
 
+
# Configuracion de servidor TFTP
Ejemplos de posibles respuestas:
+
#
 
+
# Los archivos estaticos no tienen variables. Se sirven sin modificar.
 
+
# Estan en el arbol de directorios a partir del indicado por '$dirEstatico'
{| class="wikitable"
+
#
|-
+
# Los archivos dinamicos soportan sustitucion de varibles.
! Ejemplo !! Respuesta
+
# Las plantillas con variables a sustituir estan en el arbol de directorios
|-
+
# a partir del indicado por '$dirPlantilla'.
| ejRes1 || {"errorNum": 101,"errorCad": "Token incorrecto"}
+
# Los archivos temporales con variables sustituidas estan en el arbol
|-
+
# de directorios a partir del indicado por '$dirDinamico'.
| ejRes2 || {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "email"}
+
# Los archivos dinamicos se identifican porque contienen una mac.
|-
+
# Tambien se identifican en base a las lineas que comienzan con '@'.
| ejRes3 || {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "no","token2": "0987654321","expira": 3600}
+
# En este ultimo caso, no se refieren a un telefono y puede tener pocas vars.
|}
+
#
 +
$miDir = '';
 +
$bindDir = '';
 +
$bindPuerto = 69;
 +
$dirPlantilla = '/var/lib/phoneprov-tftp/plt';
 +
$dirEstatico = '/var/lib/phoneprov-tftp/bin';
 +
$dirDinamico = '/tmp';
 +
$toRRQ = 10;
 +
$toACK = 5;
 +
$errACK = 3;
 +
$tamBlq = 512;
 +
 +
# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_EXTENSIONES
 +
$clasesCamposExtension = '50';
 +
# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_USUARIOS
 +
  $clasesCamposUsuario = '70';
 +
 +
# Expresiones regulares de archivos con mac estaticos (separados por '>')
 +
$nomArchMacEstaticos = '^SEP.*\.tlv$>^SEP.*\.bin$>^SP.*\.xml$';
 +
 +
# Traducciones previas de nombres de archivo estaticos
 +
#%archivo = 'trad';
 +
 +
# Traducciones previas de nombres de archivo dinamicos sin mac
 +
@y000000000044.cfg = 'Yealink-T23G-comun.cfg';
 +
@y000000000034.cfg = 'Yealink-T21P-comun.cfg';
 +
@y000000000000.cfg = 'Yealink-T28P-comun.cfg';
 +
@y000000000004.cfg = 'Yealink-T26P-comun.cfg';
 +
@y000000000036.cfg = 'Yealink-T41P-comun.cfg';
 +
@y000000000058.cfg = 'Yealink-T58V-comun.cfg';
 +
@y000000000069.cfg = 'Yealink-T27G-comun.cfg';
 +
@snom710.htm = 'Snom-710-comun.cfg';
 +
@snom710-firmware.xml = 'Snom-710-firmware.xml';
 +
@spa514G.cfg = 'cisco-spa514G.cfg';
 +
@spa512G.cfg = 'cisco-spa512G.cfg';
  
  
====== Comando validartoken ======
+
*Los campos del fuchero de configuración y su significado se muestran en la su¡iguiente tabla:
 
 
Es un comando muy simple, que permite conocer si un token es válido y su periodo de expiración.
 
 
 
 
 
url (POST): https://<servidor_webfon>/sercen/postvalidartoken
 
 
 
 
 
datos de entrada: '''{"token": "1234567890"}'''
 
 
 
 
 
Ejemplos de posibles respuestas:
 
 
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Ejemplo !! Respuesta
+
!Campo !!Descripción !!Posibles valores (si aplica)
 
|-
 
|-
| ejRes1 || {"errorNum": 100,"errorCad": "Token expirado"}
+
|$depurar||# 0: Solo alarmas en archivo log - 1: alarmas y trazas||
 +
|-
 +
|$soyDemonio||# 0: Arranca como proceso - 1: arranca como demonio||
 +
|-
 +
|$logArch =||# Archivo de log ('': salida estandar)||
 +
|-
 +
|$pidArch||# Archivo para el pid||
 
|-
 
|-
| ejRes2 || {"errorNum": 103,"errorCad": "Token incorrecto"}
+
|$unaVezSolo||# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)||
 
|-
 
|-
| ejRes3 || {"errorNum": 0,"errorCad": "OK","expira": 2538}
+
|$db||Nombre de la base de datos||
|}
 
 
 
 
 
 
 
====== Comando revalidartoken ======
 
 
 
Permite ampliar el periodo de expiración de un token. El periodo ampliado es el que se indica en la respuesta.
 
 
 
 
 
url (POST): https://<servidor_webfon>/sercen/revalidartoken
 
 
 
 
 
datos de entrada: '''{"token": "1234567890","token2": "0987654321","expira": 7200} ("expira" es opcional).'''
 
 
 
 
 
Ejemplos de posibles respuestas:
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Ejemplo !! Respuesta
+
|$dbHost||IP o HOST máquina base de datos de tiempo real||
 
|-
 
|-
| ejRes1 || {"errorNum": 100,"errorCad": "Token expirado"}
+
|$dbPort||Puerto de escucha de mysql||
 
|-
 
|-
| ejRes2 || {"errorNum": 103,"errorCad": "Token incorrecto"}
+
|$dbUsuario||Usuario acceso Base de datos de tiempo real||
 
|-
 
|-
| ejRes3 || {"errorNum": 0,"errorCad": "OK","expira": 3600}
+
|$dbClave||Clave usuario acceso base de datos de tiempo real||
|}
 
 
 
 
 
 
 
====== Comando revocartoken ======
 
 
 
Permite revocar un token.
 
 
 
 
 
url (POST): https://<servidor_webfon>/sercen/postrevocartoken
 
 
 
 
 
datos de entrada: '''{"token": "1234567890","token2": "0987654321"}'''
 
 
 
 
 
Ejemplos de posibles respuestas:
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Ejemplo !! Respuesta
+
|$supPort ||Puerto de supervisión del demonio||
 
|-
 
|-
| ejRes1 || {"errorNum": 103,"errorCad": "Token incorrecto"}
+
|$miDir ||||
 
|-
 
|-
| ejRes2 || {"errorNum": 0,"errorCad": "OK"}
+
|$bindDir||bindAddres||
|}
 
 
 
 
 
====== Comando cambiarClave ======
 
 
 
Permite que un usuario autenticado cambie su clave y amplíe el periodo de expiración y de caducidad.
 
 
 
 
 
url (POST): https://<servidor_webfon>/sercen/postcambiarclave
 
 
 
 
 
datos de entrada:'''{"token": "1234567890","token2": "0987654321","clvCambiar": "masdificil$1aA"}'''
 
 
 
 
 
Ejemplos de posibles respuestas:
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Ejemplo !! Respuesta
+
|$bindPuerto||Puerto de escucha del demonio||
 
|-
 
|-
| ejRes1 || {"errorNum": 102,"errorCad": "Clave incorrecta"}
+
|$dirPlantilla||Directorio de las plantillas de aprovisionamiento||
 
|-
 
|-
| ejRes2 || {"errorNum": 117,"errorCad": "Clave demasiado simple"}
+
|$dirEstatico||Directorio archivos estáticos||
 
|-
 
|-
| ejRes3 || {"errorNum": 118,"errorCad": "Clave con caracteres no soportados"}
+
|$dirDinamico||# Los archivos temporales con variables sustituidas están en el árbol de directorios a partir del indicado por '$dirDinamico'.||
 
|-
 
|-
| ejRes4 || {"errorNum": 119,"errorCad": "Clave no admite cambio"}
+
|$toRRQ ||||
 
|-
 
|-
| ejRes5 || {"errorNum": 120,"errorCad": "Clave repetida"}
+
|$toACK||Timeout ACK||
 
|-
 
|-
| ejRes6 || {"errorNum": 0,"errorCad": "OK","clvExpira": 86400}
+
|$errACK||Número de errores de ACK||
 
|-
 
|-
|}
+
|$tamBlq||Tamaño del bloque de archivos a transferir||
 
 
 
 
 
 
 
 
===== Posibles errores =====
 
 
 
 
 
{| class="wikitable"
 
 
|-
 
|-
! Número de error !! Descripción breve
+
|$clasesCamposExtension||# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_EXTENSIONES ||
 
|-
 
|-
| 0 || OK
+
|$clasesCamposUsuario||# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_USUARIOS ||
 
|-
 
|-
| 100 || Token expirado
+
|$nomArchMacEstaticos||# Expresiones regulares de archivos con mac estaticos (separados por '>')||
 
|-
 
|-
| 101 || Pin expirado
+
|%archivo||# Traducciones previas de nombres de archivo estaticos||
 
|-
 
|-
| 102 || Clave incorrecta
+
|@y000000000044.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 103 || Token incorrecto
+
|@y000000000034.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 104 || Token2 incorrecto
+
|@y000000000000.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 105 || Pin incorrecto
+
|@y000000000004.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 106 || Token comprometido
+
|@y000000000036.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 107 || Token anulado
+
|@y000000000058.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 108 || Token inválido
+
|@y000000000069.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 115 || Clave caducada
+
|@snom710.htm||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 116 || Clave expirada
+
|@snom710-firmware.xml||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 117 || Clave demasiado simple
+
|@spa514G.cfg ||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 118 || Clave con caracteres no soportados
+
|@spa512G.cfg ||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|-
| 119 || Clave no admite cambio
+
|}
 +
 
 +
==== Watchdog ====
 +
 
 +
Se trata de una aplicación del asterisk que monitoriza el SIP y en caso de fallo, pasado un cierto tiempo, reinicia el asterisk y genera un core.
 +
Si escribimos en CLI de asterisk perro tenemos los siguientes comandos:
 +
 
 +
{| class="wikitable" border="0" style="background:#ffffff" align="top"
 
|-
 
|-
| 120 || Clave repetida
+
|Activar||Activar el Watchdog
 
|-
 
|-
| 400 || Error en datos de entrada
+
|Desactivar||Desactiva el Watchdog
 
|-
 
|-
| 401 || Error registro de extensión
+
|Parada IWantToStop||Reinicia el asterisk y genera un core para pruebas
 
|-
 
|-
| 402 || Error en el estado del dispositivo
+
|Reload||Realiza una recarga del Watchdog y aplica cambios en su configuración
 
|-
 
|-
| 403 || Error en el estado de la media con el navegador
+
|Show||Ver el estado del Watchdog
|-
+
 
| 404 || No hay línea libre
+
perro avisado=0 activo=1 segsDormir=1 segsInic=60 segsGuarda=30 maxErr=3
|-
+
perro        nombre=sip_monitor_udp lwp=[15437] segsInic=60 segsGuarda=30 hace=11 err=0/5
| 405 || La línea no está libre
 
|-
 
| 406 || La línea es errónea
 
|-
 
| 407 || Línea en estado erróneo
 
|-
 
| 408 || JSEP obligatorio
 
 
|-
 
|-
| 409 || JSEP ‘offer’ obligatorio
 
|-
 
| 410 || Cifrado extremo a extremo no soportado
 
|-
 
| 411 || Canal de datos no soportado
 
|-
 
| 412 || Comando desconocido
 
|-
 
| 413 || No hay recursos
 
|-
 
| 414 || No hay conferencia libre
 
|-
 
| 415 || Error conferencia
 
|-
 
| 416 || Línea no conectada
 
|-
 
| 500 || Error interno
 
 
|}
 
|}
  
 +
El dato "hace" informa de cuanto tiempo ha transcurrido desde el último tick. Facilita la calibración del parámetro de configuración "segs_guarda", normalmente es 30
  
 +
Tiene un fichero de configuración ubicado en /etc/asterisk/MDcrash.conf
  
 +
{| class="wikitable" border="0" style="background:#ffffff" align="top"
 +
|-
 +
|Sección [perro]
 +
||activo=yes (Si esta o no activo)
 +
segs_dormir=1 (Un tick por segundo)
  
===== Logs y comandos =====
+
segs_inic=60
  
 +
segs_guarda=30
  
En serCen podemos monitorizar el funcionamiento del proceso de login de los usuarios.
+
max_errores=3 
 
+
|-
'''systemctl status serCen.service'''
+
|Sección [sip_monitor_udp]
 +
||segs_inic=60
  
Resultado esperado:
+
segs_guarda=30 (Cada 30 segundos si no reciba trafico SIP genera core)
  
serCen.service - LSB: Start/stop serCen
+
max_errores=5 (Número máximo de errores)
Loaded: loaded (/etc/init.d/serCen; generated)
+
|-
Active: active (exited) since Thu 2022-02-10 15:16:46 CET;
+
|}
2h 38min ago
 
Docs: man:systemd-sysv-generator(8)
 
Process: 942 ExecStart=/etc/init.d/serCen start
 
(code=exited, status=0/SUCCESS)
 
feb 10 15:16:45 VC-WebP-AytoArganda-MAD-02 systemd[1]:
 
Starting LSB: Start/stop serCen...
 
feb 10 15:16:45 VC-WebP-AytoArganda-MAD-02 serCen[942]:
 
Starting serCen
 
feb 10 15:16:46 VC-WebP-AytoArganda-MAD-02 systemd[1]:
 
Started LSB: Start/stop serCen.
 
  
 +
<!-- <br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>-->
  
Para listar información de serCen:
+
==== Proceso de Backup ====
 +
Las plataformas '''''VIVA'''''it Call y '''''VIVA'''''it Suite incluyen un script para realizar un proceso de backup.
  
'''nc localhost 1125'''
+
Se utilizará el script '''backup.sh''', que se encuentra en el directorio '''etc/MDTel'''.
  
 +
Se ejecuta automaticamente mediante el uso de un cron
  
Resultado esperado:
+
'''texto del cron:'''
  
  serCen sis ver='00.01.04.1' inic='20220210 173436' alarmas=0 ultAlar='00000000
+
  SHELL=/bin/sh
000000'
+
  PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
  serCen gmp msj=254/256 buf=256/256 tarea=97/102
+
  # m h dom mon dow user command
  serCen tmp uptime=1009 (0d 0h 16m 49s)
+
  0 2 * * * root /etc/MDtel/backup.sh /etc/MDtel/backup.cfg
  serCen wws mysql=1 conxNum=0 conxMaxPeriodo=0
 
  serCen wwc numCacheLibre=3 numColaPend=0
 
serCen wwc numReq=0/0 numGet=0/0 numPost=0/0 numPut=0/0 numDelete=0/0
 
serCen smt numCacheLibre=5 numColaPend=0 enPeriodo=0/0 numMsj=2/0
 
  
 +
Para activar el script hay que descomentar la línea
 +
# m h dom mon dow user command
  
Ejemplos del log de serCen:
+
Los directorios de los que se hace copia son:
 +
* DIR=var/lib/asterisk/sounds/Particular
 +
* DIR=var/lib/asterisk/moh
 +
* DIR=etc
 +
* DIR=etc/asterisk
 +
* DIR=etc/cron.d
 +
* DIR=etc/dahdi
 +
* DIR=etc/exim4
 +
* DIR=etc/ha.d
 +
* DIR=etc/logrotate.d
 +
* DIR=etc/MDtel
 +
* DIR=etc/mysql
 +
* DIR=etc/network
 +
* DIR=etc/zabbix
 +
* DIR=usr/local/sbin
  
 +
Por defecto se realiza un backup cada dos horas en la carpeta '''/var/spool/MDtel/backup'''.
  
 +
Para cambiar la ruta de destino del backup habrá que modificar el fichero backup.sh, en concreto modificar la variable MDTEL.
  
Acceso:
+
El fichero ''' backup.cfg''' que se genera incluye copia de la siguiente información:
 +
* Ficheros de configuración de la aplicación.
 +
* Base de Datos.
 +
* Dialplan.
  
[[File:sercen1.png |1000px]]
+
Se guardarán 10 copias del fichero ''' backup.cfg '''
  
Clave errónea:
+
Los campos disponibles en el fichero son los siguientes:
  
[[File:sercen2.png |1000px]]
+
{| class="wikitable"
 +
|-
 +
!Campo !!Descripción !!Posibles valores (si aplica)
 +
|-
 +
|IP_BD ||IP o HOST máquina base de datos de tiempo real||
 +
|-
 +
|HAY_SMB ||Si hay o no servidor SAMBA||1 si existe servidor SAMBA o 0 si no existe
 +
|-
 +
|HOST_SMB||IP o HOST servidor SAMBA||
 +
|-
 +
|USU_SMB||Usuario acceso servidor SAMBA||
 +
|-
 +
|CLAVE_SMB||Clave usuario acceso servidor SAMBA||
 +
|-
 +
|RUTA_SMB||Ruta donde se guardará el backup en el servidor SAMBA||
 +
|-
 +
|}
  
==== Aplicación PQCTI ====
+
Para recuperar una plataforma utilizando el backup, habrá que instalar una máquina nueva y cargar los ficheros de configuración, Base de Datos y Dialplan guardados en el proceso de backup.
  
 +
===== Información adicional: como funciona un cron =====
  
Pqcti es una nueva aplicacion de asterisk 13 que sirve para establecer llamadas , cada asterisk tendrá su modulo pqcti instalado y configurado. No hay una arquitectura como tal , sino una base para empezar a desarrollar cosas por encima.
+
La información sobre el fucnionamiento de un cron puede encontrarse en: [http://lasegundapuerta.com/index.php/informatica/linux-y-software-libre/1709-comando-cron-en-linux-ubuntu Información sobre el comando cron]
  
 +
==== CHAT ====
 +
La información para configurar el CHAT y su funcionamiento puede encontrarse en:
  
[[Archivo:PQCTI.png|600px|center]]
+
[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#CHAT_2 enlace]]
  
 +
==== MEET ====
  
La aplicación pqcti es un webservice con JSON y está configurada en un Tomcat. Cada nodo tendrá su pqcti, por lo que si ese nodo cae, no se podrán realizar consultas o conexiones desatendidas a ese nodo.
+
El esquema de conexión para el Meet es el siguiente:
  
 +
[[File:Conexion.jpg|800px]]
  
Actualmente pqcti se utiliza para:
 
  
'''- Las conexiones desatendidas'''
+
La configuración necesaria en los navegadores, para posibilitar que se puedan compartir pantallas, se encuentra en el siguiente [[Preguntas_frecuentes_administraci%C3%B3n|enlace]]
  
'''- Para el click2talk'''
 
  
'''- La funcionalidad de llamar desde agenda o historial en el portal de usuario VIVAit'''
+
Ficheros:
  
 +
*El fichero config.json tiene la configuración necesaria para proporcionar el servicio.
  
  
 +
Fichero de configuracion MEET:
  
===== Servicios web =====
+
/etc/janus/janus.cfg
 +
/etc/janus/janus.plugin.echotest.cfg
 +
/etc/janus/janus.transport.http.cfg
 +
/etc/janus/janus.transport.websockets.cfg
 +
/etc/janus/vivait.plugin.meet.cfg
 +
/etc/janus/vivait.plugin.move.cfg
  
 +
En los archivos de configuracion, es obligatorio revisar:
 +
*janus.cfg
 +
interface = IP_NODO
 +
server_name = IP_NODO
 +
ice_enforce_list = IP_NODO (e ip publicas, si las hay)
  
Los servicios web que proporciona la aplicación son de dos tipos:
+
*vivait.plugin.meet.cfg
 +
meet_url = https://IP_NODO/meet#
 +
local_nodo_id = ID_NODO
 +
local_ip = IP_NODO (escucha [sip])
 +
email_from_default_invitation = vivait-meet-18-04@mdtel.local
 +
smart_host = mdsmtp.mdtel.net
  
 +
*vivait.plugin.move.cfg
 +
local_nodo_id = ID_NODO
 +
local_ip = IP_NODO (escucha [sip])
  
1. Operativos
+
Fichero de logs:
  
 +
/var/log/janus.log
  
  
{| class="wikitable sortable"
+
Los posibles problemas de conexión de los usuarios al portal habrá que analizarlos en la consola para analistas del  navegador.
|-
 
! Comando!! Descripción
 
|-
 
| '''cmd_llamar''' || Inicia una llamada saliente desde una extensión vivait-call.
 
|-
 
| '''cmd_liberar''' || Libera una llamada establecida, que haya sido registrada en pqcti. La llamada se identifica mediante el ucid que se pasa como parámetro de invocación.
 
|-
 
|}
 
  
 +
La configuración necesaria en el portal de administración de '''''VIVA'''''it Call se puede consultar en este [[Portal_de_administraci%C3%B3n_VIVAit#VIVAit_Meet_.28En_Construcci.C3.B3n.29|enlace]].
  
 +
====Gran Hermano (GH)====
  
 +
Gran Hermano (GH) controla el estado de las extensiones de diferentes nodos. Esto permite gestionar servicios como la movilidad avanzada, la retrollamada entre extensiones de diferentes nodos, el uso de BLF's por parte de los usuarios en movilidad,…
  
 +
Esquema de instalación:
  
2. Informativos
+
[[File:Gran hermano.png|800px |center]]
  
  
  
{| class="wikitable sortable"
+
GH solo se instala en un nodo. Recomendamos instalarlo en el nodo con menos carga. Si desconocemos cual
|-
+
es, lo instalaremos en la maquina con BDHIST.
! Comando!! Descripción
 
|-
 
| '''info_llamadas''' || Informa sobre las llamadas registradas en pqcti. Devuelve un array con la información de cada llamada.
 
|-
 
| '''info_llamadas_num''' || Devuelve el número de llamadas registradas en pqcti.
 
|-
 
| '''info_llamada''' || Devuelve la información de la llamada cuyo ucid se pasa como parámetro de invocación.
 
|-
 
|}
 
  
  
 +
===== Intz-gh =====
 +
El demonio que gestiona el Gran Hermano es Intz-gh, que se encuentra en versión V0.1.0.
  
===== Archivos relevantes y procedimientos de despliegue =====
+
El demonio tiene un fichero de configuración: '''/etc/Mdtel/intz-gh.conf''' con el siguiente aspecto:
 
 
 
 
Los archivos relevantes para construir la aplicación son:
 
 
 
 
 
Fuentes (directorio referenciado en donde se encuentren los fuentes de asterisk):
 
 
 
 
 
* '''apps/app_md_pqcti.c'''
 
 
   
 
   
* '''apps/pqcti/*.c y apps/pqcti/*.h'''
+
#
 
+
# Los nombres no pueden tener numeros
* '''apps/Makefile''' (Que requiere de ser modificado para compilar la aplicación)
+
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
 
+
# Los valores comentados indican valores por defecto
 
+
base
 
+
{
------ Añadir al final de "clean:" "pqcti/*.o" ------
+
cfg
 
+
{
:{|
+
soy_demonio = 1
|-
+
hay_syslog = 0
|
+
  # Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
 
+
archivo_pid = -
  ------ Añadir debajo de "$(subst .c,.o,$(wildcard
+
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
  confbridge/*.c)): _ASTCFLAGS+=$(call
+
# No se usa si se activa hay_syslog
  MOD_ASTCFLAGS,app_confbridge)" ------
+
  archivo_traza = -
  # wkw inicio
+
  }
  $(if $(filter app_md_pqcti,$
+
  cfg_recarga
  (EMBEDDED_MODS)),modules.link,app_md_pqcti.so): $(subst
+
  {
.c,.o,$(wildcard pqcti/*.c))
+
  # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
  $(subst .c,.o,$(wildcard pqcti/*.c)): _ASTCFLAGS+=$
+
  nivel_traza = 3
  (call MOD_ASTCFLAGS,app_md_pqcti)
+
  pruebas = 1
  #wkw fin (mirar clean:)
+
hay_flush_traza = 1
  ------
+
  # traza_milisegundos = 1
|} <br>
+
  }
 
+
sis
'''La compilación y despliegue se hace del modo habitual: "make" y "make install".'''
+
{
 
+
# No se usa. No modificar
 
+
subsistema = 0
 
+
}
====== Configuración de archivos relevantes: ======
+
gmp
 
+
{
 
+
# Numero de mensajes. No modificar
 
+
num_msj = 256# Numero de buffer. No modificar
 
+
num_buf = 256
 
+
}
 
+
}
   
+
supervision
   
+
{
* '''En el Dialplan. Llamada saliente''' (en el archivo que se considere adecuado)
+
puerto_escucha = 1116
 
+
}
A continuación se ofrece un dialplan de inicio de llamada. Conviene analizar si los contextos de transferencia son distintos a los habituales.
+
supervision_recarga
 
+
{
:{|
+
to_periodo = 60
|-
+
}
|
+
regexp
  ------
+
{
  [pqcti_inicio_llamada_sale]
+
hay_regexp = 1
  exten => _X.,1,NoOp(ID_DISPOSITIVO=${ID_DISPOSITIVO})
+
}
  same =>      n,NoOp(UCID=${UCID})
+
regexp_recarga
  same =>      n,NoOp(PQCTI_SAL_EXTEN=${PQCTI_SAL_EXTEN})
+
{
  same =>      n,NoOp(PQCTI_SAL_ANI_NUM=$
+
num_entradas = 32
  {PQCTI_SAL_ANI_NUM})
+
inc_entradas = 128
  same =>      n,NoOp(PQCTI_SAL_ANI_NAME=$
+
max_entradas = 1024
  {PQCTI_SAL_ANI_NAME})
+
}
  same =>      n,NoOp(PQCTI_SAL_DNIS_NUM=$
+
vivaitcall
  {PQCTI_SAL_DNIS_NUM})
+
{
  same =>      n,NoOp(PQCTI_SAL_DNIS_NAME=$
+
hay_vic = 1
  {PQCTI_SAL_DNIS_NAME})
+
puerto_escucha = 5556
  same =>      n,Set(__TRANSFER_CONTEXT=pqcti_transferir_llamada)
+
identif = gh_000
  same =>      n,Set(__FORWARD_CONTEXT=pqcti_desviar_llamada)
+
entorno = gh
  same =>      n,Set(CALLERID(name)=$
+
max_conx = 4
  {PQCTI_SAL_ANI_NAME})
+
}
  same =>      n,Set(CALLERID(num)=${PQCTI_SAL_ANI_NUM})
+
vivaitcall_recarga
  same =>      n,Set(CHANNEL(hangup_handler_wipe)=$
+
{
  {CONTEXT},fin,1())
+
to_solicitud = 10
  same =>      n,pqctiLlamSaleIniciada
+
to_desconexion = 10
  same =>      n,NoOp(INSERT en BD)
+
  ip_valida
  same =>      n,Goto(Cen_Inicio_SIP,${EXTEN},1)
+
  {
  exten => fin,1,pqctiLlamLiberada
+
# Hasta 32 bloques de direcciones validas
  same =>      n,NoOp(UPDATE en BD)
+
todas
  same =>      n,Return
+
{
  ------
+
ip = 0.0.0.0
 
+
msk = 0.0.0.0
|} <br>
+
}
 
+
localhost
 +
{
 +
ip = 127.0.0.1
 +
msk = 255.255.255.255}
 +
}
 +
}
 +
  mysql
 +
  {
 +
  hay_mysql = 1
 +
host = BDTR
 +
  usuario = nimitz
 +
  clave = phikau3iwCe4O0PP5b09ng==
 +
  base_datos = nimitz
 +
  }
 +
  mysql_recarga
 +
  {
 +
  to_resp = 5
 +
  }
 +
  gh1
 +
  {
 +
  hay_gh1 = 1
 +
# umbrales para el numero de digitos de una extension
 +
# sirve para saber si un peer es una extension o un enlace
 +
exten_min_digi = 3
 +
  exten_max_digi = 8
 +
# numero maximo de extensiones soportadas
 +
exten_max = 500
 +
# numero maximo de enlaces soportados
 +
  enla_max = 20
 +
  # numero maximo de retrollamadas activas concurrentes
 +
  retro_max = 50
 +
# numero maximo de retrollamadas activas concurrentes para una extension como destino (max 31)
 +
retro_max_b = 4
 +
}
 +
  gh1_recarga
 +
  {
 +
  # tiempo maximo en segs. para activar una retrollamada tras finalizar llamada
 +
to_retro_candidato = 60
 +
# tiempo maximo en segs. que una retrollamada espera a que las extensiones esten libres
 +
  to_retro_activo = 300
 +
# temporizador de limpieza de tablas en segs.
 +
  to_limpiar = 10
 +
}
 +
ias
 +
{
 +
hay_ias = 1
 +
  url = mdgh_rest
 +
  puerto = 8090
 +
}ias_recarga
 +
{
 +
# tiempo maximo en segs. para conectar con asterisk para comandos
 +
  to_conx_cmd = 10
 +
  # periodo en horas para actualizar lista de id de nodos y sus direcciones ip
 +
to_lista_nodos = 1
 +
}
  
* '''Para llamada entrante'''
+
Los campos del fichero de configuración y su significado son los siguientes:
  
  
Es muy importante llamar a "ucid(0)" antes de pqctiLlamEntra y de insertar en BD. No importa si en "Cen_Inicio_TrunkSip" se invoca de nuevo a "ucid(0)" porque se mantiene el asignado.
+
{| class="wikitable"
 
+
|-
:{|
+
!Campo!!Descripción
 +
|-
 +
|soy_demonio || # 0: Arranca como proceso - 1: arranca como demonio
 
|-
 
|-
|
+
|hay_syslog || Si hay servidor de syslog
------
+
|-
[pqcti_inicio_llamada_entra]
+
|archivo_pid || # Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)
exten => _X.,1,NoOp(ID_DISPOSITIVO=${ID_DISPOSITIVO})
+
|-
same =>      n,ucid(0)
+
|archivo_traza | |# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)
same =>      n,NoOp(UCID=${UCID})
+
|-
same =>     
+
|nivel_traza || # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
n,Set(__TRANSFER_CONTEXT=pqcti_transferir_llamada)
+
|-
same =>     
+
|pruebas ||
n,Set(__FORWARD_CONTEXT=pqcti_desviar_llamada)
 
same =>      n,Set(CHANNEL(hangup_handler_wipe)=$
 
{CONTEXT},fin,1())
 
same =>      n,pqctiLlamEntra
 
same =>      n,NoOp(INSERT into DAT_CONX_DESATEN)
 
same =>      n,Goto(Cen_Inicio_TrunkSip,${EXTEN},1)
 
<br>
 
exten => fin,1,pqctiLlamLiberada
 
same =>      n,NoOp(UPDATE DAT_CONX_DESATEN set
 
D_HORA_FIN,DURACION)
 
same =>      n,Return
 
------
 
 
 
|} <br>
 
 
 
 
 
 
 
* '''En /etc/asterisk/acl.conf'''
 
 
 
 
 
 
 
Debe configurarse el acl que limita el acceso al servicio desde direcciones ip conocidas.
 
 
 
Un ejemplo en que se permite una red de servidores y un equipo:
 
 
 
:{|
 
 
|-
 
|-
|
+
|hay_flush_traza ||
 
 
------
 
[pqcti_acl_comandos]
 
deny=0.0.0.0/0.0.0.0
 
permit=172.25.128.0/24
 
permit=192.168.0.20/32
 
permit=127.0.0.1
 
------
 
 
 
|} <br>
 
 
 
 
 
 
 
* '''En /etc/asterisk/http.conf'''
 
 
 
:{|
 
 
|-
 
|-
|
+
|traza_milisegundos ||
------
+
|-
[general]
+
|subsistema || # No se usa. No modificar
servername=vcall-nodo
+
|-
enabled=yes
+
|num_msj || # Numero de mensajes. No modificar
bindaddr=0.0.0.0
+
|-
bindport=8088
+
|num_buf || # Numero de buffer. No modificar
prefix=vcall-nodo
+
|-
sessionlimit=100
+
|puerto_escucha || Puesto escucha del demonio
session_inactivity=30000
 
session_keep_alive=15000
 
enablestatic=no
 
;redirect = / /static/config/index.html
 
tlsenable=no
 
;tlsbindaddr=0.0.0.0:8089
 
;tlscipher=
 
;tlsdisablev1=yes
 
;tlsdisablev11=yes
 
;tlsdisablev12=yes
 
;tlsservercipherorder=yes
 
;[post_mappings]
 
;uploads = /var/lib/asterisk/uploads/
 
------
 
 
 
|} <br>
 
 
 
 
 
* '''En /etc/asterisk/pqcti.conf'''
 
 
 
:{|
 
 
|-
 
|-
|
+
|to_periodo || Timeout para reconectar
------
 
[general]
 
debug=false
 
llamadas_registrar=true
 
<br>
 
[comandos]
 
url_comandos_v1=pqcti/v1/comandos
 
acl=pqcti_acl_comandos
 
<br>
 
[llamada_sale]
 
canal_A_tech=sip
 
canal_A_dial_cad_fmt=%s
 
contexto=pqcti_inicio_llamada_sale
 
temporizador_segs=30
 
------
 
 
 
|} <br>
 
 
 
 
 
 
 
* '''En /etc/asterisk/ext_Subrutinas_BD.conf'''
 
 
 
:{|
 
 
|-
 
|-
|
+
|hay_regexp ||
 
+
|-
;------------------------------------------------------
+
|num_entradas ||
[Cen_Sub_updateDatConxDesaten_Fin]
+
|-
;------------------------------------------------------
+
|inc_entradas ||
-----------
+
|-
;------------------------------------------------------
+
|max_entradas ||
-----------
+
|-
; ${ARG1}: C_UCID
+
|hay_vic ||
<br>
+
|-
exten => s,1,NoOp(MDSUBUPDDATCONXDESCON*)
+
|puerto_escucha || Puerto de escucha a nivel de VIVAit Call
<br>
+
|-
  same =>  n,ExecIf($["${SPRV}"="1"]?
+
|identif ||
Return(SUPERVIVENCIA))
+
|-
<br>
+
|entorno || Nombre base de datos
  same =>  n,ExecIf($["${ARG1}"=""]?Return(NO_UCID))
+
|-
<br>
+
|max_conx || Número máximo de conexiones a la base de datos
  same =>  n,MDintz(nimitz|bd|sqlSinEspera|update
+
|-
DAT_CONX_DESATEN set D_HORA_FIN=now(),N_DURACION=now()-
+
|to_solicitud || Timeout de solicitud
D_HORA_INICIO where C_UCID="${ARG1}")
+
|-
<br>
+
|to_desconexion || Timeout de desconexión
  ;same =>  n,DumpChan
+
|-
  same =>  n,Return(OK)
+
|ip || Dirección de red de escucha del intz-nimitz
<br>
+
|-
include => Cen_finLlamada
+
|msk || Mascara de red de escucha del intz-nimitz
<br>
+
|-
;------------------------------------------------------
+
|ip || IP localhost
-----------
+
|-
[Cen_Sub_updateDatConxDesaten_Contestada]
+
|msk || mascara localhost
;------------------------------------------------------
+
|-
-----------
+
|hay_mysql || Hay mysql
;------------------------------------------------------
+
|-
-----------
+
|host || IP o HOST maquina base de datos
; ${ARG1}: C_UCID
+
|-
<br>
+
|usuario || Usuario acceso Base de datos
exten => s,1,NoOp(MDSUBUPDDATCONXDESCON*)
 
<br>
 
  same =>  n,ExecIf($["${SPRV}"="1"]?
 
Return(SUPERVIVENCIA))
 
<br>
 
  same =>  n,ExecIf($["${ARG1}"=""]?Return(NO_UCID))
 
<br>
 
  same =>  n,MDintz(nimitz|bd|sqlSinEspera|update
 
DAT_CONX_DESATEN set B_CONTESTADA=1 where C_UCID="$
 
{ARG1}")
 
<br>
 
  ;same =>n,DumpChan
 
  same =>n,Return(OK)
 
include => Cen_finLlamada
 
<br>
 
;------------------------------------------------------
 
-----------
 
[Cen_Sub_insertDatConxDesaten]
 
;------------------------------------------------------
 
-----------
 
;------------------------------------------------------
 
-----------
 
; ${ARG1}: ID_NODO
 
; ${ARG2}: C_UCID
 
; ${ARG3}: C_ORIGEN_NUM
 
; ${ARG4}: C_ORIGEN_NAME
 
; ${ARG5}: C_ORIGEN_EXTEN
 
; ${ARG6}: C_DESTINO_NUM
 
; ${ARG7}: C_DESTINO_NAME
 
; ${ARG8}: ID_DISPOSITIVO
 
;
 
<br>
 
exten => s,1,NoOp(MDSUBINSERTDATCONXDES*)
 
<br>
 
  same =>n,ExecIf($["${SPRV}"="1"]?
 
Return(SUPERVIVENCIA))
 
<br>
 
  same =>  n,ExecIf($["${ARG1}"=""]?Return(NO_IDNODO))
 
  same =>  n,ExecIf($["${ARG2}"=""]?Return(NO_UCID))
 
  same =>  n,ExecIf($["${ARG3}"=""]?Set(ARG3=NULL))
 
  same =>  n,ExecIf($["${ARG4}"=""]?Set(ARG4=NULL))
 
  same =>  n,ExecIf($["${ARG5}"=""]?Set(ARG5=NULL))
 
  same =>  n,ExecIf($["${ARG6}"=""]?Set(ARG6=NULL))
 
  same =>  n,ExecIf($["${ARG7}"=""]?Set(ARG7=NULL))
 
  same =>  n,ExecIf($["${ARG8}"=""]?Set(ARG8=NULL))
 
<br>
 
  same =>  n,MDintz(nimitz|bd|sqlSinEspera|insert into
 
DAT_CONX_DESATEN
 
(D_HORA_INICIO,ID_NODO,C_UCID,C_ORIGEN_NUM,C_ORIGEN_NAM
 
E,C_ORIGEN_EXTEN,C_DESTINO_NUM,C_DESTINO_NAME,ID_DISPOS
 
ITIVO) VALUES(now(),${ARG1},"${ARG2}","${ARG3}","$
 
{ARG4}","${ARG5}","${ARG6}","${ARG7}",${ARG8}))
 
<br>
 
  ;same =>n,DumpChan
 
  same =>n,Return(OK)
 
<br>
 
include => Cen_finLlamada
 
<br>
 
<br>
 
---------------------------------------
 
 
 
 
 
|} <br>
 
 
 
 
 
* '''En /etc/asterisk/ext_MARCAR_Extension_Dial.conf'''
 
 
 
 
 
*En este fichero hay que añadir lo que está en negrita.
 
 
 
:{|
 
 
|-
 
|-
|
+
|clave || Clave usuario acceso base de datos
 +
|-
 +
|base_datos||Nombre de la base de datos
 +
|-
 +
|to_resp || Timeout de respuesta
 +
|-
 +
|hay_gh1 || Hay intz-gh
 +
|-
 +
|exten_min_digi || # umbrales para el numero de dígitos de una extensión # sirve para saber si un peer es una extensión o un enlace
 +
|-
 +
|exten_max_digi ||
 +
|-
 +
|exten_max || # numero máximo de extensiones soportadas
 +
|-
 +
|enla_max || # numero máximo de enlaces soportados
 +
|-
 +
|retro_max || # numero máximo de retrollamadas activas concurrentes. '''Valor por defecto --> 50'''
 +
|-
 +
|retro_max_b || # numero máximo de retrollamadas activas concurrentes para una extensión como destino (max 31). '''Valor por defecto --> 4'''
 +
|-
 +
|to_retro_candidato || # tiempo máximo en segs. para activar una retrollamada tras finalizar llamada. '''Valor por defecto --> 60'''
 +
|-
 +
|to_retro_activo || # tiempo máximo en segs. que una retrollamada espera a que las extensiones estén libres. '''Valor por defecto --> 300'''
 +
|-
 +
|to_limpiar || # temporizador de limpieza de tablas en segs.
 +
|-
 +
|hay_ias ||
 +
|-
 +
|url  ||
 +
|-
 +
|puerto ||
 +
|-
 +
|to_conx_cmd || # tiempo máximo en segs. para conectar con Asterisk para comandos
 +
|-
 +
|to_lista_nodos || # periodo en horas para actualizar lista de id de nodos y sus direcciones ip
 +
|}
 +
 
 +
 
 +
 
 +
Para saber si GH funciona correctamente usaremos el comando '''nc localhost 1116''', obteniendo resultados similares a los siguientes:
 +
 
 +
* intz-gh sis ver='00.01.00' inic='20181007 081237' alarmas=0 ultAlar='00000000 000000'
 +
* intz-gh gmp msj=252/256 buf=256/256 tarea=95/102
 +
* intz-gh tmp uptime=86503 (1d 0h 1m 43s)
 +
* intz-gh vic identif='gh_000' entorno='gh' conx=0/4 numConx=2349(7)
 +
* intz-gh regExpr entr=32/32/1024 numRegExpr=0 consul=0(0)
 +
* intz-gh ias nodos=3 cmd=11(0) cmdErr=0 tresp=0
 +
* intz-gh gh1 exten=9/500 enla=1/20 retro=0/0/50
 +
* intz-gh gh1 soli=2349(0) soliErr=0(0) soliEncol=0(0)
 +
 
 +
Los '''log's''' que genera el sistema se encuentran en: /var/log/intz-gh.log
  
;------------------------------------------------------
+
===== mdgh.conf y Mdintz.conf =====
-----------
 
[Cen_Marcar_Extension_Dial_Gosub]
 
;------------------------------------------------------
 
-----------
 
exten => s,1,NoOp(MDSUBMAREXTEN*)
 
<br>
 
  same =>  n,Gosub(Cen_Sub_updAnswer,s,1(${UCID},$
 
{ID_DISPOSITIVO},${ENR_IDSEGMENTO}))
 
<br>
 
  same =>  n,ExecIf($[$[${MDDEBUG}-0] > 1]?DumpChan)
 
<br>
 
  ;Declarar la variable PASARTONOS en el trunk que
 
queramos
 
  same => n,ExecIf($["${PASARTONOS}"="1"]?
 
SetChannelOption(14,0))
 
<br>
 
  ;Rellenar el historico de llamadas
 
; same =>    n,Gosub(Cen_Sub_updDatHisLlam_tipo,s,1($
 
{DIALEDPEERNUMBER},${TIPOLLAMHIST_ENTRANTE},${UCID}))
 
  same =>    n,Gosub(Cen_Sub_updDatHisLlam_tipo_ID,s,1($
 
{DIALEDPEERNUMBER},${TIPOLLAMHIST_ENTRANTE},$
 
{ID_HLL_S}))
 
<br>
 
'''; Poner contestadas las llamadas de conexiones'''
 
'''desatendidas'''
 
'''same =>    n,GosubIf($["${PQCTI_REGISTRAR()}"="SI"]?'''
 
'''Cen_Sub_updateDatConxDesaten_Contestada,s,1(${UCID}))'''
 
<br>
 
same =>  n,Return()
 
  
|} <br>
+
Además existen dos ficheros de configuración de Asterisk: /etc/asterisk/'''mdgh.conf''':
 +
 +
[servicios]
 +
retro_hay=yes
 +
subscripcion_hay=yes
 +
[rest]
 +
rest_red_ip=172.25.126.21
 +
rest_red_msk=255.255.255.255
 +
rest_puerto_escucha=8090
 +
retro_exten_tech=SIP
 +
retro_contexto=Cen_InicioLlamada_GHRetro
 +
retro_to_descolgar=30
 +
retro_A_cartel_fmt=retro: %s
  
 +
Y /etc/asterisk/'''Mdintz.conf'''
  
 +
[gh]
 +
host0=BDTR
 +
port0=5556
 +
toConx=5
 +
toRx=10
  
'''Descripción de campos del archivo pqcti.conf:'''
+
Los campos de los ficheros y su significado son los siguientes:
  
'''• general'''
+
{| class="wikitable"
 +
|-
 +
!Campo!!Descripción
 +
|-
 +
|retro_hay || Si es YES, empleamos la retrollamada '''multinodo''' del '''GH''', si es no, utilizamos la retrollamada de Asterisk
 +
|-
 +
|subscripcion_hay || Si es YES, empleamos los BLFs del '''GH''', si es no, utilizamos los BLFs de Asterisk
 +
|-
 +
|rest_red_ip || '''IP del servidor donde corre el intz-gh'''
 +
|-
 +
|rest_red_msk || Máscara de red donde corre el intz-gh
 +
|-
 +
|rest_puerto_escucha || Puerto de escucha a nivel de VIVAit  Call
 +
|-
 +
|retro_exten_tech || Tecnología empleada en las extensiones
 +
|-
 +
|retro_contexto || Contexto del GH
 +
|-
 +
|retro_to_descolgar || timeot retrollamada descolgar
 +
|-
 +
|retro_A_cartel_fmt || Información aparece en el display si la llamada es una retrollamada
 +
|}
  
*'''debug'''. Activa la depuración desde el inicio, aunque puede activarse mediante comando "pqcti debug on"
 
  
*'''llamadas_registrar'''. Booleano que indica si se mantiene un registro de llamadas.Si se desactiva esta opción,
+
{| class="wikitable"
no hay registro y, por tanto, no se soportan los comandos "cmd_liberar" y los comandos informativos.
+
|-
 +
!Campo!!Descripción
 +
|-
 +
|host0 || Base de datos de tiempo real
 +
|-
 +
|port0 || Puerto de escucha
 +
|}
  
  
'''• comandos'''
+
El comando para conocer el estado de los diferentes elementos en Asterisk es:
  
*''' url_comandos_v1'''. La parte no común de la url. Con la configuración de http.conf propuesta, la url completa sería:
+
'''mdgh show
http://<IP_NODO>:8089/vcall-nodo/pqcti/v1/comandos
+
Uso: mdgh show [config | exten <exten_num> | enla <peer>]]'''
  
*''' acl.''' Configura el "acl" a utilizar en el archivo "/etc/asterisk/acl.conf"
+
Por ejemplo:
  
 +
'''mdgh show exten 6140'''
  
'''• llamada_sale'''
+
:* mdgh Datos de la extension 6140:
 +
:* Datos en intz-gh:
 +
:* ESTADO=NOT_INUSE
 +
:* INUSE=0
 +
:* RINGING=0
 +
:* TS=1538978766
 +
:* HACE=362
 +
:* SUBS_NODOS_NUM=1
 +
:* Estado en cache local: NOT_INUSE
  
*''' canal_A_tech.''' Configura la tecnología de los canales de extensiones. Típicamente "sip". Podría ser "local", pero:
+
'''mdgh show enla Trunk_MDtel'''
  
  '''¡¡¡CUIDADO !!! si se usase un canal local, se perdería la función de "setvar" en el "peer": se pierde ID_DISPOSITIVO.'''
+
* mdgh Datos del enlace Trunk_MDtel:
 +
:* Datos en intz-gh:
 +
:* INUSE=0
 +
:* RINGING=0
 +
:* TS=1538978766
 +
:* HACE=461
  
  
* '''canal_A_dial_cad_fmt.''' Si los canales de extensiones fuesen "sip/<exten>", entonces este campo sería "%s". Si la tecnología fuese "local", este campo sería "%s@<contexto>/n".
+
El fichero de logs es el:
 +
/var/log/intz-gh.log
  
* '''contexto.''' Es el contexto en el que se inicia la llamada saliente. Como son necesarios algunos ajustes, debe existir un contexto especial antes de ir al contexto genérico "Cen_Inicio_Sip".
 
  
* '''temporizador_segs.''' Tiempo máximo (en segs.) para el descolgado de la extensión para la que se solicita el inicio de la llamada saliente.
+
===== Retrollamadas =====
  
===== Aplicaciones para el dialplan de asterisk =====
+
El funcionamiento será el siguiente:
  
 +
*La retrollamada queda programada de extensión física "A" a extensión física "B" (no queda programada a numeraciones de usuarios); esto no quiere decir que no podamos programar una retrollamada cuando hemos llamado a una numeración de usuario, pero queda programada en la extensión física en la que está ese usuario en ese momento.
  
 +
*El número llamado "B" podrá ser derivado de varias causas:
  
* '''pqctiLlamSaleIniciada''' (sin parámetros). Debe invocarse al inicio del dialplan de una llamada saliente. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".
+
::"A" ha llamado a "B"
 +
::"A" ha llamado a un usuario ubicado en "B"
 +
::"A" ha llamado a un destino desviado a "B"
 +
::"A" ha llamado a un destino y por preruta acaba en "B"  
 +
::...
  
 +
*Las causas por las que se podrá programar una retrollamada son:
 +
::"B" está ocupada
 +
::"B" no contesta
 +
::"B" está ocupada y no contesta (ha sonado en línea 2--> )
  
* '''pqctiLlamEntra'''. Debe invocarse al inicio del dialplan de una llamada entrante. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".
 
  
 +
'''Solo podremos programar la retrollamada si el sistema devuelve: extensión ocupada o no contesta'''
  
* '''pqctiLlamLiberada'''. Debe invocarse al finalizar una llamada que previamente ha sido registrada en pqcti con las aplicaciones anteriores. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".
 
  
 +
Estas dos últimas casuísticas son iguales a efectos de usuario, pero no a efectos internos...
  
 +
Si una llamada va a buzón, salta a un grupo ACD, a una IVR...entonces NO habrá retrollamada (porque se considera contestada)
 +
 +
*Para programar una retrollamada se pulsa el código de facilidad (*43#) una vez colgada la misma; el sistema recordará la última llamada durante un período de tiempo configurable; aunque entre una llamada en "A", este podrá programar retrollamada a la última saliente si sigue dentro del período
 +
*Se podrá abortar una retrollamada ( (*44#), pero esto no borrará la última llamada (podemos arrepentirnos de haber abortado la retrollamada)
 +
*En el gran hermano se guardará Nodo A + Ext_A (numero y name) + Ext_B (numero y name_usuario) + Causa + Timestamp
 +
*Solo se puede programar una retrollamada y que sea la última
 +
*Si la ultima llamada saliente es, por ejemplo exterior --> No hay posibilidad de programar ninguna retrollamada
  
  
  
 +
====== <big>Acuerdos de funcionamiento</big> ======
  
===== Comandos de asterisk =====
+
*Un origen A solo tendrá programa una retrollamada a un destino B; si teniendo una programada decide programar otra, la primera se pierde.
  
 +
*Un destino B puede serlo de múltiples orígenes "n" (configurable); cuando B esté disponible para retrollamada, se lanzará una llamada a uno de los orígenes y cuando vuelva a quedar disponible a otro de ellos.
  
 +
*Si se trata de programar una "n+1" retrollamada (desde A5) para un destino B, el sistema le informará de que la retrollamada no ha podido programarse (locución a determinar)
  
A continuación se muestran varios comandos de pqcti para asterisk.
 
  
  
 +
====== <big>Cuestiones</big> ======
  
{| class="wikitable sortable"
+
*Se prevé que la retrollamada suene en una extensión desviada; si "A" llama a "B" y esta está desviada en "C", si suena "C" la retrollamada que programo.
|-
 
! Comando!! Descripción
 
|-
 
| '''pqcti show''' || Lista los datos de configuración y de las llamadas registradas.
 
|-
 
| '''pqcti reload''' || Recarga la configuración si se ha modificado "/etc/asterisk/pqcti.conf".
 
|-
 
| |'''pqcti debug [on|off]''' || Activa y desactiva la depuración del módulo.
 
|-
 
|}
 
  
 +
*Si salta al buzón no puede haber retrollamada.
  
 +
==== GeneraConf ====
  
 +
El GeneraConf es el webservice (war) que se utiliza en la plataforma '''''<span style="color:#144F9B">VIVA</span>'''''it para generar ficheros de configuración a partir de las modificaciones realizadas por el usuario en las tablas de la Base de Datos del sistema à es un intermediario entre los portales y Asterisk.
  
===== Tabla en base de datos =====
+
Es importante tener en cuenta que el proceso convierte tablas de Base de Datos en ficheros de configuración, pero NO genera Dialplan ni sincroniza locuciones.
  
 +
El GeneraConf  se instala en el mismo servidor que el Tomcat, normalmente con el portal de administración.
  
Con el fin de que otra aplicación pueda seguir las llamadas registradas en pqcti, se ha previsto una nueva tabla en base de datos: DAT_CONX_DESATEN.
+
GeneraConf lee de la tabla Dat_Sincroniza, genera los ficheros de configuración y los coloca en su sitio.
  
Dicha tabla integra todos los registros de todos los nodos vivait y será mantenida por el dialplan.
+
===== Fichero de configuración =====
  
 +
GeneraConf es un proceso que no incorpora fichero de configuración. El proceso es llamado por los portales del entorno '''''<span style="color:#144F9B">VIVA</span>'''''it  (portal de administración y portal de alertas) siendo los propios portales los que han de incluir los parámetros necesarios.
  
Por supuesto, esa tabla sólo tiene sentido cuando "llamadas_registrar=true".
+
En el portal de administración de '''''<span style="color:#144F9B">VIVA</span>'''''it Call tenemos que configurar la url para poder sincronizar los cambios realizados utilizando el proceso:
  
  
 +
[[File:URL de sincronizacion.jpg]]
  
:{|
 
|-
 
|
 
  
------
 
CREATE TABLE IF NOT EXISTS `nimitz`.`DAT_CONX_DESATEN`
 
(
 
  `ID` INT NOT NULL AUTO_INCREMENT,
 
  `D_HORA_INICIO` DATETIME NULL,
 
  `D_HORA_FIN` DATETIME NULL,
 
  `N_DURACION` INT NULL DEFAULT 0,
 
  `ID_NODO` INT NULL DEFAULT NULL,
 
  `C_UCID` VARCHAR(32) NULL,
 
  `C_ORIGEN_NUM` VARCHAR(32) NULL,
 
  `C_ORIGEN_NAME` VARCHAR(128) NULL,
 
  `C_ORIGEN_EXTEN` VARCHAR(32) NULL,
 
  `C_DESTINO_NUM` VARCHAR(32) NULL,
 
  `C_DESTINO_NAME` VARCHAR(128) NULL,
 
  `ID_DISPOSITIVO` VARCHAR(32) NULL,
 
  PRIMARY KEY (`ID`),
 
  UNIQUE INDEX `IDX_UCID_UNIQUE` (`C_UCID` ASC)
 
VISIBLE,
 
  INDEX `IDX_HORA_INICIO` (`D_HORA_INICIO` ASC)
 
VISIBLE)
 
------
 
  
|} <br>
+
GeneraConf incluye el parámetro '''AlcanceSincroniza''' que se utiliza para distinguir el portal que deseamos sincronizar. Los portales (administración y alertas) deberán incluir este parámetro cuando llamen al generaConf:
  
 +
*Si no se indica o se indica con valor 10 (alcanceSincroniza=10) se sincroniza el entorno '''''<span style="color:#144F9B">VIVA</span>'''''it Call, excluyendo el entorno de alertas.
 +
*Si se indica con valor 20 (alcanceSincroniza=20), se sincroniza solo el entorno de Alertas.
  
 +
A tal efecto se ha creado el siguiente enumerado:
  
===== Interfaz para los servicios =====
+
public enum TAlcanceSincroniza  {
 
+
        ALCANCESSINC_VIVAITCALL("10"),
 +
        ALCANCESSINC_ALERTAS("20");
 +
       
 +
        private TAlcanceSincroniza(String text) {
 +
            this.text = text;
 +
        }  
 +
        private final String text;  
 +
        @Override
 +
        public String toString() {
 +
            return text;
 +
        }
 +
    }
 +
 
 +
 
 +
Existe un fichero, '''generaConf.properties''', que permite simular la creación de ficheros de configuración con los cambios que hayamos realizado en el portal. Los ficheros de configuración creados en modo simulación se crear en una ruta distinta a la habitual, por lo que no sobrescriben los ficheros de configuración que se están utilizando.
 +
 
 +
Nuevo fichero /etc/MDtel/generaConf.properties :
 +
 
 +
root@Homologacion-Corp1:~# cat /etc/MDtel/generaConf.properties
 +
 +
simular=0
 +
simDirMDtel=/tmp/MDtel
 +
simDirAsterisk=/tmp/Asterisk
 +
deshabExten=0
 +
deshabCola=0
 +
deshabBuzones=0
 +
deshabCti=0
 +
deshabRecGwd=1
 +
deshabRecNodo=0
 +
deshabRecProc=1
 +
deshabRecCen=0
 +
deshabMDcal=0
 +
deshabArchAsterisk=0
 +
deshabVoces=0
 +
deshabEnInt=0
 +
deshabEnExt=0
 +
deshabMoh=0
 +
deshabGrupos=0
 +
deshabVdn=0
  
Todos los servicios están implementados en base a un POST con un json en el cuerpo de la solicitud, que contiene los parámetros de invocación, y otro json en el cuerpo de la respuesta.
+
El valor 1 indica que GeneraConf simula el fichero asociado, cuando el valor es “0” no se genera la simulación.
  
En ambos casos, el json es un objeto con campos.
+
El proceso GeneraConf permite subir tanto locuciones como MOH desde el portal. Cuando subimos las locuciones a través del portal el GeneraConf se encarga de copiar las locuciones a un directorio temporal, posteriormente las colocará en los directorios definitivos correspondientes.
  
Está implementada, como opción, el uso de un GET con parámetros, pero no se recomienda su uso, excepto para pruebas, porque puede haber problemas con el conjunto de caracteres no ascii.
+
===== Ficheros de logs =====
  
Si no hay problemas a nivel de red, de transporte o en las reglas básicas del comando, el estado de la respuesta es siempre "200 OK", indicándose los posibles errores en el json de respuesta.
+
El fichero con los log’s generado se encuentra en /var/log/Tomcat.x/generaConf.log.
  
Todas las respuestas contienen un campo denominado "resultado" (de la ejecución) que puede tomar los siguientes valores:
 
  
  
 +
==== Nodo WebRTC ====
  
* '''OK.''' La ejecución se ha iniciado correctamente. En el caso de la llamada saliente, no quiere decir que se haya establecido y, ni siquiera, que se haya iniciado porque puede que la extensión no descuelgue.
+
Se adjunta la documentación del nodo WebRTC:
  
* '''ERROR.''' Hay un error en los parámetros de invocación o en el estado de la llamada referida y no se puede ejecutar el comando solicitado.
 
  
* '''NO_EJECUTADO.''' Hay un problema no achacable a quién invoca y no se puede ejecutar el comando.
+
<big>'''[[:medio:DOCUMENTO_WEBRTC_v9.pdf| Manual de instalación y operación del nodo WebRTC ]]'''</big>
  
  
 +
La arquitectura de WebRTC en VIVAit Call es la  siguiente:
  
Si El "resultado" no es "OK", se devuelve un campo "diagnóstico" con una cadena que describe el problema detectado. Siempre es texto en español, por lo que su uso previsto es para logs.
 
  
  
  
  
 +
[[File:webrtc.png|900px|center]]
  
===== Descipción de comandos y respuestas de json =====
 
  
  
A partir de aquí se describen los comandos y respuestas en base a json de ejemplo, ya que los campos son triviales y autoexplicativos:
 
  
 +
Componentes Principales:
  
*'''cmd_llamar -> Inicia una llamada saliente desde una extensión vivait-call.'''
 
  
Resultado esperado :
 
  
:{|
+
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
 +
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Componentes  '''''
 +
! align=center style="background-color:#0099ff;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
 
|-
 
|-
|
+
| font-weight: bold;" | '''APACHE'''
cmd={
+
|  | Apache es un servidor web HTTP de código abierto.La funcionalidad principal de este servicio web es servir a los usuarios todos los ficheros necesarios para visualizar la web. Las solicitudes de los usuarios se hacen normalmente mediante un navegador (Chrome, Firefox, Safari, etc.).
  "comando": "cmd_llamar",
+
|-
  "extension": "201",
+
| font-weight: bold;" | '''SERCEN'''
  "ani_num": "201",
+
| | Sirve para identificar a los usuarios y garantizar que los mismos sean quienes dicen ser.
  "ani_name": "ext_201",
+
|-
  "dnis_num": "221",
+
| font-weight: bold;" | '''JANUS'''
  "dnis_name": "ext_221"
+
|  | Janus es un servidor WebRTC concebido para ser de propósito general. Como tal, no proporciona ninguna funcionalidad más que implementar los medios para configurar una comunicación de medios WebRTC con un navegador, intercambiar mensajes JSON con él y transmitir RTP / RTCP y mensajes entre navegadores y la lógica de la aplicación del lado del servidor a los que están apegados.
  }
+
|-
resp={
+
| font-weight: bold;" | '''IPTABLES'''
  "comando": "cmd_llamar",
+
|  | Es un programa  que se encarga de filtrar los paquetes de red , es decir , es la parte que se encarga de determinar qué paquetes de datos queremos que lleguen hasta el servidor y cuáles no.
  "ucid": "20999000031643889797",
+
|-
  "estado_actual": "llam_sale_espera",
+
| font-weight: bold;" | '''FAIL2BAN'''
  "resultado": "OK",
+
|  | Es una aplicación de Linux que permite evitar accesos no autorizados al servidor. Funciona bloqueando o baneando  las IP que realicen varios intentos de acceso incorrectos al servidor.
  "ahora": "20220203 130317.107"
+
|-
  }
+
| font-weight: bold;" | '''CLIENTE'''
 +
| |      El cliente debe de proporcionar una ip pública , un dns para esa ip y un certificado válido.
  
|} <br>
+
|}
  
En el comando, sólo son obligatorios: comando, extension y dnis_num. El resto son opcionales. Los campos "ani" no deben usarse, salvo por una buena razón.
+
=== Portales web corporativos ===
El campo "dnis_num" sólo sirve para presentar el dato en el display de la extensión que
+
<br><br>
inicia la llamada.
 
  
 +
El portal de usuario VIVAit Call permite que determinadas funcionalidades del sistema puedan ser accesibles por los usuarios finales desde una interfaz mucho más cómoda y amigable que el telefónico.
 +
<br><br>
 +
Existen varias opciones del portal de usuario según las necesidades del cliente , las diferentes opciones en base a la configuración son:
 +
<br><br>
 +
* Portal de usuario
 +
* Portal Webcall
 +
* Portal para integración con Teams
 +
* Portal Vivait Tracker
 +
* Portal Vivait Supervisor
 +
<br><br>
 +
Para configurar las diferentes posibilidades en los portales de usuario hay que modificar el archivo '''“vivaitConfig.js”''' , este archivo se encuentra en :  '''/var/www/vivait/webs/portal/Assets/Config/'''
 +
<br><br>
 +
[[File:p-usuario1.png|center|600px]]
 +
<br><br>
 +
*'''webphoneLink :''' Configuración del link de la web con solo el dialpad.
 +
*'''IsWebPhoneDisabled:''' Configuración para habilitar (false) o deshabilitar (true) la aparición de webphone al iniciar el portal.
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
  
 +
==== Accesos Web ====
  
*'''cmd_liberar -> Libera una llamada establecida, que haya sido registrada en pqcti.'''
+
{| class="wikitable"
 
+
|-
:{|
+
! Aplicación !! Enlace
 
|-
 
|-
|
+
|Portal de administración '''''VIVA'''''it Suite || http://ip_admin:8180/Vivait-Call
 
+
|-
cmd={
+
|'''''VIVA'''''it Tracker||http://ip_tracker:8180/Vivait-Tracker
  "comando": "cmd_liberar",
+
|-
  "ucid": "20999000031643889797"
+
|Monitor Web||http://ip_monitor:8180/MonitorWeb
}
+
|-
resp={
+
|Monitorización Zabbix||http://ip_zabbix:80/zabbix
  "comando": "cmd_liberar",
 
  "ucid": "20999000031643889797",
 
  "resultado": "OK",
 
  "ahora": "20220203 130804.526"
 
}
 
 
 
|} <br>
 
 
 
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
 
 
 
 
 
 
 
*'''info_llamadas -> Informa sobre las llamadas registradas en pqcti. Devuelve un array con la información de cada llamada.'''
 
 
 
:{|
 
 
|-
 
|-
|
+
|Base de datos tiempo real||http://ip_bbdd_tr:80/phpmyadmin/
}
 
resp={
 
  "comando": "info_llamadas",
 
  "llamadas": [
 
    {
 
      "ucid": "20999000051643890188",
 
      "estado_actual": "llam_sale_iniciada",
 
      "duracion_segundos": 8
 
    }
 
  ],
 
  "resultado": "OK",
 
  "ahora": "20220203 130957.149"
 
}
 
 
 
|} <br>
 
 
 
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
 
 
 
 
 
*'''info_llamadas_num -> IDevuelve el número de llamadas registradas en pqcti.'''
 
 
 
:{|
 
 
|-
 
|-
|
+
|Base de datos réplica||http://ip_bbdd_replica:80/phpmyadmin
 +
|}
  
resp={
+
===== Permisos de aplicaciones =====
  "comando": "info_llamadas_num",
+
Se crean a través del '''portal de administración ''VIVA''it''' . Debe conocerse como funcionan los ejes [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Ejes| ver sección Portal de administracion - General - Ejes]] y que pueden existir hasta seis aplicaciones creadas en la plataforma:
  "llamadas_num": 1,
 
  "resultado": "OK",
 
  "ahora": "20220203 131001.134"
 
}
 
  
|} <br>
 
  
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
+
[[File:Permisos-Portal_Administracion.jpg|center]]
  
  
 +
La forma como dar permisos de aplicaciones a un usuario está explicada en la [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Asignaci.C3.B3n_de_Permisos_de_Usuario_por_Administrador | sección  Portal de administracion - General - Usuarios ]].
  
  
*'''info_llamada , "ucid"-> "20999000051643890188" -> IDevuelve el número de llamadas registradas en pqcti.'''
+
==== Portal de usuario ====
 +
<br><br>
 +
Para configurar el portal de usuario solo para terminales telefónicos (sin webphone) se tendría que hacer de la siguiente forma:
 +
<br><br>
 +
[[File:p-usuario2.png|center|300px]]
 +
<br><br>
 +
*'''webphoneLink :''' Comentar la línea con ( // ) al comienzo de esta.
 +
*'''IsWebPhoneDisabled:''' Deshabilitar (true) para que no aparezca webphone al iniciar el portal.
 +
<br><br>
 +
Al terminar la configuración , en el portal se deshabilitará el botón de webphone:
 +
<br><br>
 +
[[File:p-usuario3.png|center|700px]]
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
:{|
+
==== Portal Webcall ====
|-
+
<br><br>
|
+
Para configurar el portal de usuario VIVAit Call web con webphone integrado en la misma página se tendría que hacer de la siguiente forma:
 +
<br><br>
 +
[[File:p-usuario4.png|center|300px]]
 +
<br><br>
 +
*'''webphoneLink :''' Comentar la línea con ( // ) al comienzo de esta.
 +
*'''IsWebPhoneDisabled:''' Habilitar (false) para que aparezca webphone al iniciar el portal.
 +
<br><br>
 +
Al terminar la configuración , en el portal aparecerá el dialpad de webphone:
 +
<br><br>
 +
[[File:p-usuario5.png|center|800px]]
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
resp={
+
==== Portal para integración con Teams ====
  "comando": "info_llamada",
+
<br><br>
  "ucid": "20999000051643890188",
+
Para configurar el portal de usuario VIVAit Call web con botón de enlace a otra página con webphone se tendría que hacer de la siguiente forma:
  "estado_actual": "llam_sale_iniciada",
+
<br><br>
  "duracion_segundos": 14,
+
[[File:p-usuario6.png|center|300px]]
  "resultado": "OK",
+
<br><br>
  "ahora": "20220203 131003.638"
+
*'''webphoneLink :''' Poner el link del enlace a webphone
  }
+
*'''IsWebPhoneDisabled:''' Deshabilitar (true) para que no aparezca webphone al iniciar el portal.
|} <br>
+
<br><br>
 +
Al terminar la configuración , en el portal estará habilitado el botón de webphone , que al pulsar sobre el nos llevará a otra página con el dialpad :
 +
<br><br>
 +
[[File:p-usuario7.png|center|800px]]
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0 Volver al índice]
 +
<br><br>
  
(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").
+
==== Varios portales en una sola instalación ====
 
+
<br><br>
 
+
Existe la posibilidad de tener varios portales en una misma instalación de VIVAit Call con diferentes url’s para cada portal .
<br>
+
<br><br>
 
+
[[File:p-usuario8.png|center|600px]]
==== Vivait-CTI ====
+
<br><br>
Permite la comunicación entre la aplicación '''''VIVA'''''it Desk de agente y el asterisk, sincronizando; convierte el protocolo “asterisk manager” a CSTA ('''''VIVA'''''it Desk “habla” CSTA).
+
Un ejemplo de las url’s de los portales sería:
 +
<br><br>
 +
https://servidor/webs/vivait-user/ → Portal usuario
 +
https://servidor/webs/webfon2-solo → DialPad
 +
https://servidor/webs/webfon3 → Portal webphone
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
Es un proceso importante para el uso de '''''VIVA'''''it Desk, y para 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 '''''VIVA'''''it Desk y formularios hace el sistema difícilmente manejable
+
==== Portal Vivait Tracker ====
 +
<br><br>
 +
===== Introducción a Vivait Tracker 0.1 =====
 +
<br><br>
 +
Con la versión 5.1 de la plataforma '''''VIVA'''''it Call se ha lanzado un nuevo tracker: ''VIVAit Tracker'', que supone una mejora sobre el producto anterior: [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Vivait-Tracker ''Tracker WEB''] más enfocado al mundo Call Center.<br>
 +
Los puntos claves del nuevo '''''portal VIVAit Tracker''''' dirigido al entorno corporativo son:<br>
 +
: • Adaptación para facilitar su uso en entornos de telefonía corporativa.<br>
 +
: • Permite seguir llamadas y escuchar/descargar grabaciones en caso de existir.<br>
 +
: • Integrado con entornos de texto (TBC y desarrollos futuros).
 +
<br><br>
 +
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
A efectos de diagnósticos, desde un SSH se ejecuta el comando “nc ip_maquina 1111”
+
====== Arquitectura de Vivait Tracker 0.1 ======
 +
<br><br>
 +
Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:
 +
<br><br>
 +
: - '''Frontend'''<br>
 +
::Reside en un servidor web Apache.<br>
 +
::Se invoca desde un navegador mediante una URL del tipo https://host/ws/<br>
 +
        https://172.25.128.252/Tracker_Corp/
 +
::Es la parte visual: HTML, CSS, JavaScript.<br>
 +
::No accede directamente a la base de datos; solo obtiene datos desde una API.
 +
<br><br>
 +
: - '''Backend / API REST'''<br>
 +
::Corre en un servidor web Tomcat.<br>
 +
::Expone la API en: <br>
 +
        https://172.25.128.252/Tracker-Rest/tracker/.
 +
::Contiene la lógica que permite interactuar con la BBDD.<br>
 +
::Responde en JSON para que el frontend pueda ofrecérselo al navegador.<br>
 +
<br><br>
 +
Diagrama funcional de la arquitectura de VIVAit Tracker 0.1
 +
<br><br>
 +
[[File:arquitectura3_tracker_V5.1.png|1500px|center|thumb]]
 +
<br><br>
 +
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
'''root@vivait-acd:~# nc localhost 1111'''
+
====== Flujo completo del ciclo de datos ======
vivait-cti sis ver='V01.5' inic='20140414 104312' alarmas=13 ultAlar='20140415 173152'
+
<br><br>
vivait-cti gmp msj=1018/1024 buf=1023/1024 tarea=97/102
+
Siguiendo el proceso se contemplan los siguientes pasos:
vivait-cti tmp uptime=694748 (8d 0h 59m 8s)
+
<br><br>
vivait-cti cti numConx=(0/511) numPend=(0/127) numMakeCallPend=0 numCall=(0/2047)
+
'''Paso 1''' El usuario invoca el frontend residente en Apache desde un navegador, usando javascript, mediante la URL del tipo:<br>
numChan=(0/4095) numAuxStr=(0/511) numMoniColas=(0/511) numMoniDevice=0
+
        https://host/Traker_Corp/
numMoniCall=0 numMoniCallAuto=0 numMoniCallByDevice=0 numMoni=(0/511)
+
El navegador carga la página web servida por Apache.
auditCallErr=0 auditAuxStrErr=0 auditMsjReqErr=0 araChanID=0 araUniqueID=0 araMoni=0
+
<br><br>
vivait-cti ami esta=conx resp=652(0) evs=1397(0) descar=556(0) err=16 errConx=16
+
'''Paso 2''' Una vez superada la fase de [[#Seguridad de VIVAit Tracker 0.1 |validación]] se muestra un [[#Descripción de la interfaz de VIVAit Supervisor 2.0 |formulario]] que permite al usuario definir los parámetros de una consulta.<br>
numAct(0/0/127) auditErrAct=0
+
::La página del formulario inicia una transacción para efectuar una solicitud HTTP POST al endpoint correspondiente, por ejemplo:<br>
 
+
                https://172.25.128.252/Tracker_Corporativo/
Donde cada parámetro monitorizado indica:
+
::siendo la carga util de esta solicitud los datos del formulario rellenado por el usuario:<br>
 +
                {fechaInicio: "", fechaFin: "", horaInicio: "", horaFin: "", listaExtensiones: [], listaGrupos: [],…}         
 +
<br><br>
 +
'''Paso 3''' Al recibir los datos del formulario el frontend hace una petición a la API REST de Tomcat.<br>
  
{| class="wikitable"
+
<br><br>
|-
+
'''Paso 4''' La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta.<br>
!ver!!Versión del proceso
+
 
|-
+
<br><br>
|sis/inic||Fecha de arranque del proceso
+
'''Paso 5''' El frontend recibe el JSON con los datos de la consulta en la respuesta:<br>
|-
+
                POST https://172.25.128.252/Tracker-Rest/tracker/lista
|Sis/alarmas||Alarmas desde arranque
+
::El navegador lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.
|-
+
<br><br>
|Sis/ultAlar||Fecha de última alarma
+
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
|-
+
<br><br>
|Gmp/msj||
+
 
|-
+
====== Seguridad de Vivait Tracker 0.1 ======
|Gmp/buf||
+
<br><br>
|-
+
El acceso está controlado mediante validación de tokens.
|Gmp/tarea||
+
<br><br>
|-
+
'''Paso 1 Autenticación inicial'''
|Tmp/uptime||
+
<br><br>
|-
+
: • Al introducir sus credenciales el usuario se valida a través del servicio de autenticación ''sercen''<br>
|Cti/numConx||Número de conexiones actuales / Número de conexiones máximo
+
                https://172.25.128.252/sercen/postautenticar1
|-
+
: • Sercen genera un token firmado que identifica la sesión del usuario.
|Cti/numPend||
+
<br><br>
|-
+
'''Paso 2 Validación interna de permisos'''
|Cti/numMakeCallPend||Llamadas pendientes de realizar
+
<br><br>
|-
+
: • Una vez que el frontend tiene el token, cada petición pasa por una validación de la API del tomcat:<br>
|Cti/numcall||
+
                https://172.25.128.252/Tracker-Rest/tracker/verificarToken
|-
+
:: En la misma se comprueba que:<br>
|Cti/numChan||
+
::: - El token es válido.<br>
|-
+
::: - El usuario tiene permisos para el recurso que está intentando usar. <br>
|Cti/numAuxStr||
+
:::  Es necesario que el usuario tenga acceso a la aplicación ''Grabador'', ver [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit_5.0#Submen.C3.BA_Permisos_a_usuarios Usuarios].<br>
|-
+
: • No se ejecuta ninguna acción si el token no es validado primero.
|Cti/numMoniColas||Número de colas monitorizadas
+
<br><br>
|-
+
'''Paso 3 Proxy inverso apache-tomcat'''
|Cti/numMoniDevice||
+
<br><br>
|-
+
: • Apache actúa como punto de entrada único:
|Cti/numMoniCall||
+
:: - El usuario solo ve URLs de apache.
|-
+
:: - Las peticiones que requieren lógica del backend se redirigen internamente a tomcat.
|Cti/numMoniCallAuto||
+
:: - Esto se consigue mediante proxy inverso, por ejemplo:<br>
|-
+
::: /Tracker_Corporativo → servido por apache<br>
|Cti/numMoniCallByDevice||
+
                https://172.25.128.252/Tracker_Corp/
|-
+
::: /Tracker-Rest → Apache las pasa a Tomcat de forma transparente para el usuario<br>
|Cti/numMoni||
+
                https://172.25.128.252/Tracker-Rest/tracker/extensiones
|-
+
: • El navegador utilizado por el usuario nunca ve a tomcat.
|Cti/auditCallErr||
+
<br><br>
|-
+
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
|Cti/auditAuxStrErr||
+
<br><br>
|-
 
|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||
 
|-
 
|}
 
  
Como complemento a los diagnósticos:
+
===== Descripción de la interfaz de Vivait Tracker 0.1 =====
 +
<br><br>
 +
Este apartado se trata en [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/VIVAit_Tracker#Descripción_de_la_interfaz_de_Vivait_Tracker_0.1 Vivait Tracker]
 +
<br><br>
 +
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
Podremos examinar el fichero de configuración del proceso en '''/etc/MDtel/vivait-cti.conf'''
+
==== Portal VIVAit Supervisor ====
 +
<br><br>
  
*El fichero de configuración, '''vivait-cti.conf''', es el siguiente:
+
===== Introducción a Vivait Supervisor 2.0 =====
 
+
<br><br>
#
+
Con la versión 5.1 de la plataforma '''''VIVA'''''it Call se ha lanzado la aplicación: ''Vivait-Supervisor 2.0''.
# Los nombres no pueden tener numeros
+
<br><br>
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
+
Los puntos claves del '''''portal Vivait Supervisor''''' son:<br>
# Los valores comentados indican valores por defecto
+
: • Seguimiento de las llamadas generadas en el sistema '''''VIVA'''''it Call.<br>
+
: • Visualización de resultados mediante gráficos, tablas y otros formatos.<br>
base
+
: • Exportación de datos para su posterior análisis.
{
+
<br><br>
cfg
+
<div style="
{
+
  text-align:right;
soy_demonio = 1
+
  margin-top:20px;
hay_syslog = 0
+
  padding:8px;
# Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)
+
  border:1px solid #ccc;
archivo_pid = -
+
  background-color:#f9f9f9;
# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)
+
  border-radius:6px;
# No se usa si se activa hay_syslog
+
  display:inline-block;
archivo_traza = -
+
">
}
+
[[File:flecha_verde.png|20px|link=#Portales web corporativos]][[#Portales web corporativos| Volver arriba]]
cfg_recarga
+
</div>
{
+
<div style="
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
+
  text-align:right;
nivel_traza = 3
+
  margin-top:20px;
pruebas = 1
+
  padding:8px;
hay_flush_traza = 1
+
  border:1px solid #ccc;
}
+
  background-color:#f9f9f9;
sis
+
  border-radius:6px;
{
+
  display:inline-block;
# No se usa. No modificar
+
">
subsistema = 0
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
}
+
</div>
gmp
+
<div style="
{
+
  text-align:right;
# Numero de mensajes. No modificar
+
  margin-top:20px;
num_msj = 1024
+
  padding:8px;
# Numero de buffer. No modificar
+
  border:1px solid #ccc;
num_buf = 1024
+
  background-color:#f9f9f9;
}
+
  border-radius:6px;
}
+
  display:inline-block;
+
">
supercolas
+
[[File:casa.png|20px|link=#]][[# | Página Principal]]
{
+
</div>
en_comandos = 0
+
<br><br>
en_eventos = 0
+
 
# archivo_conf = supercolas.conf
+
====== Definiciones en Vivait Supervisor 2.0 ======
}
+
<br><br>
+
A continuación se definen los principales conceptos empleados en el supervisor:
supervision
+
<br><br>
{
+
'''Dashboard'''<br>
puerto_escucha = 1111
+
:Panel de control que presenta de forma visual y resumida la información clave (datos, indicadores o métricas),<br>
}
+
:con el objetivo de facilitar la supervisión, el análisis y la toma de decisiones de manera rápida y eficiente.<br>
+
:Un dashboard está compuesto por uno o varios componentes.
cti
+
<br><br>
{
+
'''Componente'''<br>
hay_cti = 1
+
:Elemento individual que forma parte de un dashboard y cuya función es mostrar la información requerida.<br>
# Dimensionamiento de recursos. Uno menos, ya que cero no vale
+
:Los componentes pueden adoptar distintos formatos, entre los más habituales:<br>
max_conx = 512
+
::'''• Tablas:'''<br>
max_call = 2048
+
:::La información se presenta en formato tabular. Las cabeceras y la estructura de la tabla se definen durante la creación de su lógica.<br>
max_channel = 4096
+
::'''• Gráficos:'''<br>
max_monitor = 512
+
:::Los datos se muestran de forma visual mediante distintos tipos de gráficos, como barras, líneas, circulares, entre otros.<br>
max_str_aux = 512
+
::Según el modo en que actualizan la información, los componentes se clasifican en:<br>
puerto_escucha = 4500
+
::'''• Dinámicos:'''<br>
link_id = 1
+
:::La información se actualiza de forma periódica, de acuerdo con un temporizador asociado al componente.<br>
#
+
::'''• Estáticos:'''<br>
hay_vdn = 1
+
:::La información se carga al iniciar el dashboard y no se vuelve a actualizar hasta que el panel de control se invoca nuevamente.
hay_usuarios = 1
+
<br><br>
usuarios
+
<div style="
{
+
  text-align:right;
vivait
+
  margin-top:20px;
{
+
  padding:8px;
clave = 3RSMbPlTi61rG5pySx9hhUokz8Fyy3Nql2w8Jairfl8=
+
  border:1px solid #ccc;
ip = 0.0.0.0
+
  background-color:#f9f9f9;
msk = 0.0.0.0
+
  border-radius:6px;
}
+
  display:inline-block;
}
+
">
}
+
[[File:flecha_verde.png|20px|link=#Portales web corporativos]][[#Portales web corporativos| Volver arriba]]
+
</div>
cti_recarga
+
<div style="
{
+
  text-align:right;
makeCall_primero_dentro = 1
+
  margin-top:20px;
makeCall_primero_fuera_agente_descuelga = 1
+
  padding:8px;
temporizador_makeCall = 30
+
  border:1px solid #ccc;
fmt_canal_exten = SIP/%s
+
  background-color:#f9f9f9;
# contextos para llamadas salientes makeCall y makePredictiveCal
+
  border-radius:6px;
contexto_makeCall_primeroFuera = Cen_MakeCallPrimeroFuera
+
  display:inline-block;
contexto_makeCall_primeroFueraDentro = Cen_MakeCallPrimeroFueraDentro
+
">
contexto_makeCall_primeroDentro = Cen_MakeCallPrimeroDentro
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
# contextos para llamadas salientes desde myAcdSuperv
+
</div>
contexto_myAcdSuperv_ProgreFuera = Cen_myAcdSuperv_ProgreFuera
+
<div style="
contexto_myAcdSuperv_ProgreDentro = Cen_myAcdSuperv_ProgreDentro
+
  text-align:right;
contexto_myAcdSuperv_PredicFuera = Cen_myAcdSuperv_PredicFuera
+
  margin-top:20px;
contexto_myAcdSuperv_PredicDentro = Cen_myAcdSuperv_PredicDentro
+
  padding:8px;
# contexto para transferencias
+
  border:1px solid #ccc;
contexto_redirect = Cen_Redirect
+
  background-color:#f9f9f9;
# expresiones regulares. se evaluan en el orden indicado
+
  border-radius:6px;
expr_esExtenLocal = ^(4)[0-9]{4}$
+
  display:inline-block;
expr_esExtenInterna = -
+
">
expr_esCola = ^(8)[0-9]{4}$
+
[[File:casa.png|20px|link=#]][[# | Página Principal]]
expr_esPuntoDistribucion = ^(9)[0-9]{4}$
+
</div>
expr_esPuntoEnrutamiento = -
+
<br><br>
expr_esNumPrivateLocal = ^[369][0-9][0-9][0-9][0-9]$
+
 
expr_esNumPrivateUnknown = ^[369]
+
====== Arquitectura de Vivait Supervisor 2.0 ======
expr_esNumPublicNational = ^0?[69][0-9]{8}$
+
<br><br>
expr_esNumPublicInternational = ^000[0-9]*
+
Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:
# resto siempre esNumPublicUnknown
+
<br><br>
#
+
: - '''Frontend'''<br>
audit_hay_Call = 1
+
::Reside en un servidor web Apache.<br>
audit_call_minutContestada = 60
+
::Se invoca desde un navegador mediante una URL del tipo https://host/ws/<br>
audit_call_minutNoContestada = 5
+
        https://172.25.128.92/Vivait-Supervisor/
audit_hay_AuxStr = 1
+
::Es la parte visual: HTML, CSS, JavaScript.<br>
audit_AuxStr_minut = 2
+
::No accede directamente a la base de datos; solo obtiene datos desde una API.
audit_hay_MsjReq = 1
+
<br><br>
audit_MsjReq_minut = 2
+
: - '''Backend / API REST'''<br>
#
+
::Corre en un servidor web Tomcat.<br>
}
+
::Expone la API en: <br>
+
        https://172.25.128.92/Vivait-Supervisor/.
ami
+
::Contiene la lógica que permite interactuar con la BBDD.<br>
{
+
::Responde en JSON para que el frontend pueda ofrecérselo al navegador.<br>
max_action = 128
+
<br><br>
ip_asterisk = localhost
+
Diagrama funcional de la arquitectura de Vivait-Supervisor
puerto_ami = 5038
+
<br><br>
usuario_ami = vivait
+
[[File:arquitectura_supervisor2_V5.1.png|1500px|center|thumb]]
clave_ami = vivactisecret
+
<br><br>
to_inac = 30
+
<div style="
to_audit = 600
+
  text-align:right;
audit_max_resp = 3
+
  margin-top:20px;
}
+
  padding:8px;
+
  border:1px solid #ccc;
 
+
  background-color:#f9f9f9;
 
+
  border-radius:6px;
Los siguientes son los campos del fichero de configuración:
+
  display:inline-block;
 
+
">
{| class="wikitable"
+
[[File:flecha_verde.png|20px|link=#Portales web corporativos]][[#Portales web corporativos| Volver arriba]]
|-
+
</div>
!Campo !!Descripción !!Posibles valores (si aplica)
+
<div style="
|-
+
  text-align:right;
|soy_demonio||# 0: Arranca como proceso - 1: arranca como demonio||
+
  margin-top:20px;
|-
+
  padding:8px;
|hay_syslog||Si hay servidor de syslog||1 lo hay – 0 no lo hay
+
  border:1px solid #ccc;
|-
+
  background-color:#f9f9f9;
|archivo_pid||# Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)||
+
  border-radius:6px;
|-
+
  display:inline-block;
|archivo_traza||# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)||
+
">
|-
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
|nivel_traza||# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)||
+
</div>
|-
+
<div style="
|pruebas||||
+
  text-align:right;
|-
+
  margin-top:20px;
|hay_flush_traza||||
+
  padding:8px;
|-
+
  border:1px solid #ccc;
|subsistema||# No se usa. No modificar||
+
  background-color:#f9f9f9;
|-
+
  border-radius:6px;
|num_msj||# Numero de mensajes. No modificar||
+
  display:inline-block;
|-
+
">
|num_buf||# Numero de buffer. No modificar||
+
[[File:casa.png|20px|link=#]][[# | Página Principal]]
|-
+
</div>
|en_comandos||||
+
<br><br>
|-
+
 
|en_eventos||||
+
====== Flujo completo del ciclo de datos ======
|-
+
<br><br>
|archivo_conf||Archivo configuracion de asterisk para las supercolas||
+
Siguiendo el proceso se contemplan los siguientes pasos:
|-
+
<br><br>
|puerto_escucha||Puerto de supervision del demonio||
+
'''Paso 1''' El usuario invoca el frontend residente en Apache desde un navegador, usando javascript, mediante la URL del tipo:<br>
|-
+
        https://host/Vivait-Supervisor/
|hay_cti||hay cti||1 hay cti – o no hay
+
El navegador carga la página web servida por Apache.
|-
+
<br><br>
|max_conx||Numero maximo de conexiones||
+
'''Paso 2''' Una vez superada la fase de [[#Seguridad de Vivait Supervisor 2.0|validación]] se muestra [[#Descripción de la interfaz de Vivait Supervisor 2.0 |la pantalla inicial]] que permite al usuario elegir el dashboard, previamente configurado, ejecutándose la monitorización de la consulta preparada.<br>
|-
+
::Tras elegir el dashboard deseado, la página web realiza solicitudes periódicas HTTP POST al endpoint correspondiente,<br>
|max_call||Numero maximo de llamadas||
+
::donde se obtienen los datos de los componentes asociados al dashboard, por ejemplo:<br>
 +
                https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
 +
::siendo la carga útil de esta solicitud la identificación del componente con los filtros elegidos por el usuario:<br>
 +
              {idCompoCuadro: "15",…}
 +
                  filtros : [{tipo: "titulo", valor: "titulo=Detalle"}, {tipo: "fechaDesde", valor: "FechaDesde="},…]
 +
                idCompoCuadro: "15"         
 +
<br><br>
 +
'''Paso 3''' Al recibir los datos el frontend hace una petición a la API REST de Tomcat.<br>
 +
<br><br>
 +
'''Paso 4''' La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta.<br>
 +
              INFO TablaDinamicosDaoImpl:607 - componerSQL SELECT DATE_FORMAT(DAT_LLAMADAS.D_HORA_INICIO,'%Y-%m-%d'),DATE ...
 +
<br><br>
 +
'''Paso 5''' El frontend recibe el JSON con los datos de la consulta en la respuesta:<br>
 +
                POST https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
 +
::El navegador lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Portales web corporativos]][[#Portales web corporativos| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
 +
 
 +
====== Seguridad de Vivait Supervisor 2.0 ======
 +
<br><br>
 +
El acceso, del usuario a la aplicación, está controlado mediante validación de tokens y acceso a la aplicación correspondiente.<br>
 +
ver [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit_5.0#Submen.C3.BA_Permisos_a_usuarios Usuarios]
 +
<br><br>
 +
La aplicación ''CALL_CENTER'' es la que gestiona los perfiles del usuario para Vivait-Supervisor, según la siguiente tabla:
 +
<br><br>
 +
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
 +
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.3cm;color:#ffffff;" | '''''Perfil de Usuario'''''
 +
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.3cm;color:#ffffff;" | '''''Nivel administración'''''
 +
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.3cm;color:#ffffff;" | '''''Funciones'''''
 
|-
 
|-
|max_channel||Numero maximo de canales||
+
| style="text-align: center; font-weight: bold;padding:0.3cm;" |Administración
 +
| | Distinto de Ninguno:
 +
: - '''Alto''',
 +
: - '''Medio''' o
 +
: - '''Bajo'''.
 +
| | Configuración y utilización de dashboard.
 
|-
 
|-
|max_monitor||Numero maximo de grabaciones||
+
| style="text-align: center; font-weight: bold;padding:0.3cm;" |Consulta
 +
| | '''Ninguno'''
 +
| | Utilización de dashboard.
 
|-
 
|-
|max_str_aux||||
+
|}
|-
+
<br><br>
|puerto_escucha||Puesto escucha del demonio||
+
El usuario no tiene acceso a Vivait-Supervisor si no tiene asignada la aplicación ''CALL_CENTER''.
|-
+
<br><br>
|link_id||||
+
El proceso de validación que se sigue dentro del sistema es el siguiente:
|-
+
<br><br>
|hay_vdn||Existen vdns||1 existen – o no existen
+
'''Paso 1 Autenticación inicial'''
|-
+
<br><br>
|hay_usuarios||Existen usuarios||1 existen – o no existen
+
: • Al introducir sus credenciales el usuario se valida a través del servicio de autenticación ''sercen''<br>
|-
+
                https://172.25.128.92/sercen/postautenticar1
|clave||Clave usuario cti cifrada||
+
: • Sercen genera un token firmado que identifica la sesión del usuario.
|-
+
<br><br>
|ip||Direcion de red de escucha del cti||
+
'''Paso 2 Validación interna de permisos'''
|-
+
<br><br>
|msk||Mascara de red de escucha del cti||
+
: • Una vez que el frontend tiene el token, cada petición pasa por una validación de la API del tomcat:<br>
|-
+
:: En la misma se comprueba que el usuario tiene permisos para el recurso que está intentando utilizar, según la tabla anterior.<br>
|makeCall_primero_dentro||||
+
::* Si el usuario tiene un perfil de administrador puede configurar (crear, borrar o gestionar) y consultar dashboard.<br>
|-
+
::* Si el usuario tiene un perfil de consulta solo puede consultar dashboard ya configurados, no puede gestionarlos.<br>
|makeCall_primero_fuera_agente_descuelga||||
+
<br><br>
|-
+
'''Paso 3 Proxy inverso apache-tomcat'''
|temporizador_makeCall||Tiempo maximo para realizar llamada||
+
<br><br>
|-
+
: • Apache actúa como punto de entrada único:
|fmt_canal_exten||||
+
:: - El usuario solo ve URLs de apache.
|-
+
:: - Las peticiones que requieren lógica del backend se redirigen internamente a tomcat.
|contexto_makeCall_primeroFuera||# contextos para llamadas salientes makeCall y makePredictiveCal||
+
:: - Esto se consigue mediante proxy inverso, por ejemplo:<br>
|-
+
:::/Vivait-Supervisor/ → servido por apache<br>
|contexto_makeCall_primeroFueraDentro||# contextos para llamadas salientes makeCall y makePredictiveCal||
+
                https://172.25.128.92/Vivait-Supervisor/
|-
+
:::Apache las pasa a Tomcat de forma transparente para el usuario<br>
|contexto_makeCall_primeroDentro||# contextos para llamadas salientes makeCall y makePredictiveCal||
+
                https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
|-
+
: • El navegador utilizado por el usuario nunca ve al módulo tomcat.
|contexto_myAcdSuperv_ProgreFuera||# contextos para llamadas salientes desde myAcdSuperv||
+
<br><br>
|-
+
<div style="
|contexto_myAcdSuperv_ProgreDentro||# contextos para llamadas salientes desde myAcdSuperv||
+
  text-align:right;
|-
+
  margin-top:20px;
|contexto_myAcdSuperv_PredicFuera||# contextos para llamadas salientes desde myAcdSuperv||
+
  padding:8px;
|-
+
  border:1px solid #ccc;
|contexto_myAcdSuperv_PredicDentro||# contextos para llamadas salientes desde myAcdSuperv||
+
  background-color:#f9f9f9;
|-
+
  border-radius:6px;
|contexto_redirect||# contexto para transferencias||
+
  display:inline-block;
|-
+
">
|expr_esExtenLocal||# expresiones regulares. Se evaluan en el orden indicado||
+
[[File:flecha_verde.png|20px|link=#Portales web corporativos]][[#Portales web corporativos| Volver arriba]]
|-
+
</div>
|expr_esExtenInterna ||# expresiones regulares. Se evaluan en el orden indicado||
+
<div style="
|-
+
  text-align:right;
|expr_esCola||# expresiones regulares. Se evaluan en el orden indicado||
+
  margin-top:20px;
|-
+
  padding:8px;
|expr_esPuntoDistribucion||# expresiones regulares. Se evaluan en el orden indicado||
+
  border:1px solid #ccc;
|-
+
  background-color:#f9f9f9;
|expr_esPuntoEnrutamiento||# expresiones regulares. Se evaluan en el orden indicado||
+
  border-radius:6px;
|-
+
  display:inline-block;
|expr_esNumPrivateLocal||# expresiones regulares. Se evaluan en el orden indicado||
+
">
|-
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
|expr_esNumPrivateUnknown||# expresiones regulares. Se evaluan en el orden indicado||
+
</div>
|-
+
<div style="
|expr_esNumPublicNational||# expresiones regulares. Se evaluan en el orden indicado||
+
  text-align:right;
|-
+
  margin-top:20px;
|expr_esNumPublicInternational||# expresiones regulares. Se evaluan en el orden indicado||
+
  padding:8px;
|-
+
  border:1px solid #ccc;
|audit_hay_Call||||
+
  background-color:#f9f9f9;
|-
+
  border-radius:6px;
|audit_call_minutContestada||||
+
  display:inline-block;
|-
+
">
|audit_call_minutNoContestada||||
+
[[File:casa.png|20px|link=#]][[# | Página Principal]]
|-
+
</div>
|audit_hay_AuxStr||||
+
<br><br>
|-
+
 
|audit_AuxStr_minut||||
+
====== Descripción de la interfaz de Vivait Supervisor 2.0 ======
|-
+
<br><br>
|audit_hay_MsjReq||||
+
Este apartado se trata en [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/VIVAit_Supervisor#Descripción_de_la_interfaz_de_Vivait_Supervisor_2.0 Vivait Supervisor]
|-
+
<br><br>
|audit_MsjReq_minut||||
+
<div style="
|-
+
  text-align:right;
|max_action||Numero maximo de acciones en el manager de asterisk||
+
  margin-top:20px;
|-
+
  padding:8px;
|ip_asterisk||Ip del asterisk de ACD||
+
  border:1px solid #ccc;
|-
+
  background-color:#f9f9f9;
|puerto_ami||Puerto del manager de asterisk ACD||
+
  border-radius:6px;
|-
+
  display:inline-block;
|usuario_ami||Usuario del manager de asterisk del ACD||
+
">
|-
+
[[File:flecha_verde.png|20px|link=#Portales web corporativos]][[#Portales web corporativos| Volver arriba]]
|clave_ami||Clave del manager de asterisk del ACD||
+
</div>
|-
+
<div style="
|to_inac||Timeout de inactividad||
+
  text-align:right;
|-
+
  margin-top:20px;
|to_audit||||
+
  padding:8px;
|-
+
  border:1px solid #ccc;
|audit_max_resp||Tiempo maximo de respuesta||
+
  background-color:#f9f9f9;
|-
+
  border-radius:6px;
|}
+
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
===  Monitorización en '''''VIVA'''it'' ===
 +
<br><br>
 +
La plataforma de monitorización utiliza es Zabbix sistema de supervisión del sistema '''''VIVA'''it''. Se trata herramienta de monitorización que se usa para vigilar el estado de sistemas informáticos y redes en tiempo real.
  
* Podremos examinar los logs del proceso en '''/var/log/vivait-cti.conf'''
 
  
==== Introducción al aprovisionamiento ====
+
<br><br>
 
+
<div style="
En cada Centralita Telefónica existente, se puede configurar sus teléfonos IP y asignarles extensiones a cada teléfono. Para hacer un ''aprovisionamiento'' de los teléfonos es necesario que el técnico configure uno a uno manualmente utilizando su interfaz web, esto no es práctico, ya que genera muchos errores y el tiempo de implementación se incrementa drásticamente. Además, es casi imposible la administración cotidiana de los teléfonos IP. Desde '''MD'''tel se utiliza una herramienta que permite que los teléfonos IP soportados y homologados por '''MD'''tel ([[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Documentaci%C3%B3n_de_usuario_VIVAit_Call_3.0#Terminales_telef.C3.B3nicos ver Terminales telefónicos]]) se puedan aprovisionar automáticamente, brindando una fácil implementación y administración cotidiana.
+
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
====Generalidades de Zabbix ====
 +
<br><br>
 +
Con Zabbix puedes controlar:
  
===== ¿Qué es aprovisionar? =====
+
Servidores (CPU, RAM, disco…)
 
+
Redes (routers, switches, tráfico)
Aprovisionar un teléfono es el proceso de configuración automático de teléfonos IP para su uso con una Centralita Telefónica de forma remota. Una vez que aprovisione un teléfono, el teléfono automáticamente se configurará correctamente y podrá administrar los teléfonos de forma centralizada y remota, sin tener que iniciar sesión en la interfaz web de cada uno de los teléfonos.
+
Bases de datos
 
+
Aplicaciones
El aprovisionamiento de teléfono facilita enormemente la administración cotidiana de los teléfonos IP. Esto hace que sea fácil de cambiar las contraseñas de extensión,realizar desvíos de llamadas, nombre a mostrar, mensajería y demás configuraciones, ya que puede hacerlo de forma centralizada para todos los teléfonos desde el portal de administración y luego transferir los cambios al teléfono.
+
Servicios en la nube
  
===== TFTP =====
+
Básicamente: te dice si algo funciona bien o falla.
  
'''TFTP''' son las siglas de '''T'''rivial '''F'''ile '''T'''ransfer '''P'''rotocol ''(Protocolo de transferencia de archivos trivial)''.
+
Qué hace exactamente
 +
'''Monitoriza'''
  
Es un protocolo de transferencia muy simple semejante a una versión básica de FTP. TFTP a menudo se utiliza para transferir pequeños archivos entre terminales en una red.
+
Recoge datos continuamente:
  
Algunos detalles del TFTP:
+
uso de CPU
 +
memoria
 +
espacio en disco
 +
latencia de red
  
* Utiliza UDP (puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza los
+
'''Genera alertas'''
puertos 20 y 21 TCP).
 
* No puede listar el contenido de los directorios.
 
* No existen mecanismos de autenticación o cifrado.
 
* Se utiliza para leer o escribir archivos de un servidor remoto.
 
* Soporta tres modos diferentes de transferencia, "netascii", "octet" y "mail”.
 
  
===== Funcionamiento del servidor phoneprove-TFTP =====
+
Si algo va mal:
  
A continuación se muestra un esquema que facilita el entendimiento del funcionamiento del servidor phoneprove-TFTP:
+
envía emails
 +
manda notificaciones
 +
lanza acciones automáticas
  
[[Archivo:Funcionamiento_Servidor.png‎ |center]]
+
'''Muestra gráficos'''
 +
históricos de rendimiento
 +
dashboards en tiempo real
  
El servidor Phoneprove-TFTP se ''encarga del aprovisionamiento masivo de terminales'', es de gran utilidad porque cualquier cambio en los teléfonos pueden ser realizados a nivel DHCP y todos los teléfonos tomarán la nueva configuración luego de reiniciarlos.
+
'''Cómo funciona'''
  
Desde phoneprove-TFTP se generara los archivos necesarios para cada teléfono y que sirven para ser aprovisionados automáticamente.
+
Tiene varios componentes:
El servidor phoneprove-TFTP  tiene alojados los ficheros de configuración están ordenados según las direcciones MAC de los teléfonos. El teléfono “preguntará” al servidor cual es su fichero de configuración utilizando su dirección MAC. Este a través de su MAC , consulta en la base de datos para ofrecer al terminal los datos de configuración según su plantilla, cual sera su extensión , cual sera el usuario propietario, entre otras cosas.
 
  
{|
+
Servidor Zabbix → recoge y analiza datos
|-
+
Agentes Zabbix → instalados en máquinas para enviar info
|
+
Interfaz web → donde ves todo
  '''Nota:''' En instalaciones grandes habrá más de uno, quizás uno por sede grande; depende de la infraestructura de DHCP.
+
'''Ejemplo real'''
|}
 
  
===== Parámetros necesarios de Aprovisionamiento de Teléfonos =====
+
Imagina que tienes un servidor:
  
'''Notas:''' el aprovisionamiento desarrollado por '''MD'''tel, no emplea un fichero por cada
+
CPU al 95% → Zabbix lo detecta
teléfono, sino que emplea una plantilla por cada modelo de teléfono.
+
Te manda alerta
Debe haber una '''configuración previa del servidor DHCP''' es necesario coordinar con el cliente la asignación de direcciones para
+
Puedes actuar antes de que se caiga
los diferentes elementos de la plataforma '''''VIVA'''''it, fundamentalmente para terminales telefónicos; en este caso además será necesario
+
'''Por qué se usa'''
activar la opción 66 que permitirá definir el servidor TFTP del que los terminales cogerán sus ficheros de aprovisionamiento.
+
Detectar problemas antes de que afecten a usuarios
El aprovisionamiento desde el portal de administración solo es posible para aquellos teléfonos IP homologados y probados desde '''MD'''tel 
+
Controlar infraestructuras grandes
[[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Documentaci%C3%B3n_de_usuario_VIVAit_Call_3.0#Terminales_telef.C3.B3nicos ver Terminales  telefónicos]]
+
Automatizar supervisión
  
 +
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Monitorización en VIVAit]][[#Monitorización en VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
Como existen parámetros comunes de todos los teléfonos de la misma marca de fabricante, muchos de los parámetros necesarios para el aprovisionamiento  como comentamos se han generado desde MDtel en forma de plantillas, que estarán disponibles en el portal de administración VIVAit [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Plantillas | ver plantilla del portal de administración VIVAit]].
+
====Zabbix ====
 +
<br><br>
  
La configuración de un teléfono SIP es muy sencilla y en no es necesario tener conocimientos avanzados de informática o de telefonía. Cada una de estas plantillas que sirven para aprovisionar un teléfono IP homologado, algunos de los parámetros predeterminados se explicarán a continuación .
 
  
 +
Zabbix es una solución de código abierto que ofrece características de monitorización avanzada de forma tecnica y para el negocio, para todo tipo de servidores, aplicaciones y equipos que forman parte de una red. La versión que utilizamos en '''md'''tel es Zabbix 2.2.2.
  
====== Parámetros de Aprovisionamiento globales ======
+
Zabbix  monitoriza los recursos  de un equipo en forma remota, permite centralizar la información en un servidor que permite visualizar el monitoreo, cuenta con una interfaz de administración vía web y utiliza un mecanismo flexible de la notificación que permita que los usuarios configuren las alarmas basadas email para informar virtualmente cualquier acontecimiento. Esto permite una reacción rápida a los problemas del servidor.  
 
 
* Configuración de la red y MAC.
 
* Zona horaria.
 
 
 
====== Parámetros de Aprovisionamiento Personales ======
 
 
 
Además de los parámetros de aprovisionamiento globales, el teléfono también obtendrá información de configuración individual, tales como:
 
 
 
*Número de Extensión.
 
*Nombre y Contraseña de usuario SIP.
 
*Configuración de Teclas BLF.
 
*Contraseña de la Interfaz Web del Teléfono IP.
 
*Idioma de la Pantalla.
 
*Orden de Preferencia de los Codecs.
 
 
 
===== Aprovisionamiento de teléfonos nivel usuario =====
 
  
 +
Para acceder al servidor Zabbix abrimos el navegador y ponemos la dirección de red (IP) de la maquina donde se encuentra instalado el servidor de Zabbix seguido de "/Zabbix.
 
{|
 
{|
 
|-
 
|-
 
|
 
|
  '''Notas:''' La dirección MAC debe estar especificada en letras mayúsculas.
+
Direccion.IP.Zabbix.Server/zabbix
  La dirección MAC del teléfono se puede encontrar en la etiqueta adhesiva en la parte inferior del teléfono, o de lo contrario se deberá acceder desde
 
  el menú del propio terminal.  
 
 
|}
 
|}
  
Los pasos a seguir son los siguientes:  
+
Zabbix posee documentación tanto en wiki, foros y comunidades.Para ampliar la información se puede visitar:
 +
[[http://www.zabbix.com Sitio oficial de Zabbix]]
  
'''1)''' Dar de alta el teléfono en el portal de administración, se debe seleccionar el modelo del teléfono, e indicar la dirección MAC del teléfono a aprovisionar, todo ello desde el portal de administración VIVAit.
+
===== Glosario Zabbix =====
Para mas información ver [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Aprovisionamiento del portal de administracion| aprovisionamiento del portal de administración VIVAit]].
+
<br><br>
  
'''2)''' En el mismo portal de administración se deberá crear una extensión , asignar a la extensión el teléfono que se quiera aprovisionar, elegir la plantilla adecuada del teléfono y el usuario propietario (solo si sera un puesto fijo) desde [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Extensiones | extensiones del portal de administración]].  
+
Se trata de una lista de conceptos básicos de Zabbix, pero para ampliar la información sobre otros términos, visite el [[http://www.zabbix.com Sitio oficial de Zabbix]].
 +
* '''host'''
 +
:En Zabbix, un host es una entidad que define el elemento en red que se desea monitorizar/supervisar activamente sus recursos locales y aplicaciones. Este puede ser una impresa, router, switch, sensores de temperatura, un servidor, un ordenador,etc, o también una aplicación. La característica de un host es que debe poseer una dirección de red (IP).
  
'''3)''' Conectar el teléfono a la red LAN informática (conectarlo al router o switch) para que tenga acceso a Internet:
+
* '''host group'''
 +
:En Zabbix, un host group (grupo host) es una agrupación lógica de los host, como una forma de organizar los dispositivos "Host" registrados en Zabbix para su monitorización. Puede contener hosts y templates.  Los grupos host se utilizan en la asignación de derechos de acceso a los hosts para diferentes grupos de usuarios.
  
:*El teléfono enviará un mensaje de multidifusión a través de la LAN.
+
* '''item'''
:*Este será captado por la Central Telefónica siempre que esté en la misma LAN.
+
:En Zabbix, un item (medida) es el parámetro que deseamos obtener del host, básicamente es una medida especifica que el servidor Zabbix recogerá de los agentes de Zabbix instalados en los host.
:*Al teléfono se le enviará una URL de aprovisionamiento.  
 
  
'''4)''' Como la mayoría de teléfonos IP del mercado al arrancar una vez sabiendo la URL de aprovisionamiento piden una serie de archivos de configuración para aprovisionarse vía TFTP. EL servidor phoneprove-TFTP, detectara la petición y a través de la MAC y datos del usuario, consultará en la base de datos los datos necesarios para aprovisionar al teléfono y si todo funciona correctamente mandara al teléfono IP los datos de configuración necesarios para funcionar.  
+
* '''trigger'''
 +
:En Zabbix, un trigger(disparador) es una entidad que define un umbral para detectar la existencia de un problema en un dispositivo.  Son valores recolectados por los "items", se usa para "evaluar" los datos recibidos con condiciones definidas. Las condiciones son de tipo aritmético y lógico.
 +
* '''event'''
 +
:En Zabbix, un event (evento) es la aparición de un suceso en Zabbix que necesita atención. Por ejemplo, el cambio de estado a raíz de un trigger, el descubrimiento de un nuevo agente (autoregistro),etc.
 +
* '''action'''
 +
:En Zabbix, una action(acción) son reglas predefinidas para reaccionar a un evento disparado por los triggers, es decir, define qué hacer ante un evento. Consta de operaciones (por ejemplo, una notificacion, comandos remotos) y condiciones (cuando  la operación se lleva a cabo).
 +
* '''notification'''
 +
:En Zabbix, una notification (notificacion) es la entidad con que Zabbix nos puede notificar (Correo Electrónico,mensajes vía "SMS" o Jabber).
 +
* '''template'''
 +
:En Zabbix, un témplate (plantilla) viene predefinida en la instalación de Zabbix Server, con el fin de ser aplicada en base al tipo de sistema operativo(Linux, Mac, Window, etc) o en elementos que comparten los mismos parámetros de medición, por ejemplo la carga del procesador, uso de memoria y  uso de recursos de red. Las plantillas son un conjunto de módulos "ITEM, TRIGGERS y GRÁFICAS", que están preconfigurados y listas para ser aplicadas a uno o varios hosts.
 +
* '''application'''
 +
:En Zabbix, una application (aplicación) es una agrupación lógica de los items.
 +
* '''Zabbix server'''
 +
:El Zabbix server (servidor de Zabbix) es el proceso central donde están definidas las configuraciones y donde se almacenan todos los datos y estadísticas recogidas de los agentes Zabbix.Consta de una base de datos, una interfaz web y el propio server. Como servidor, se encarga de recoger los datos de los agentes, calcular los triggers, enviar notificaciones, etc.
 +
* '''Zabbix agent'''
 +
:El zabbix agent (agente de Zabbix)  es un proceso desplegado en los host que son supervisados, que funciona como un servicio y puede funcionar de forma activa y pasiva simultáneamente.
  
'''5)''' Asegúrese de que el teléfono encuentren el servidor TFTP, para ello esperar un tiempo adecuado para que termine el aprovisionamiento.
+
=====Discovery=====
 
+
<br><br>
 
 
'''6)''' Finalmente aparecerá  como registrado en la centralita, obtendrá una dirección IP y podra funcionar según la configuración establecida.
 
  
 +
La funcionalidad discovery(detección) lista los dispositivos que se integran en nuestra red y el tipo de servicios que proporciona. Por ejemplo, si la empresa tuviera cien colas ACDs, y veinticinco VDNS, y en cada cola como veinte medidas, seria muy laborioso registrar una por uno cada uno. 
 +
Gracias a esta funcionalidad, se descubre todas las interfaces de red que se tiene, automáticamente y tanto para colas nodos o IVR. Para utilizar esta funcionalidad , se hace el uso de dos script, que se instalan en el momento de instalación de Zabbix en el directorio "/usr/local/sbin", que son:
 
{|
 
{|
 
|-
 
|-
|
+
|
  '''Nota''': Si no se reaprovisiona tras un periodo largo de tiempo, desenchufe el cable de alimentación eléctrica <br /> o el cable Ethernet (si se utiliza la alimentación en línea PoE) para reiniciar los teléfonos.  
+
'''zabbixDiscoveryQueues.pl''' : script utilizado para buscar colas ACD.
 +
 
 +
'''zabbixDiscoveryVDN.pl''' : script utilizado para buscar VDNS.
 
|}
 
|}
 +
La explicación de como configurarla se encuentra en el manual oficial [[https://www.zabbix.com/documentation/2.2/manual/discovery/network_discovery/rule | Zabbix detección de redes]].
  
===== Aprovisionamiento de teléfonos nivel técnico =====
+
=====Notificaciones=====
  
====== Plantilla de configuración ======
+
Necesariamente, debe darse de alta al usuario y darse de alta el servidor de correo electrónico para poder ser capaz de enviar correos.
  
La plantilla de configuración empleadas en el apartado  [[http://vivait-wiki.MDtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Plantillas | plantilla del portal de administración VIVAit]] de cada modelo está formada por una serie de variables.
+
Por otro lado, el formato del correo electrónico y las condiciones de envío de correo al usuario se configura en las acciones. Véase  el [[https://www.zabbix.com/documentation/2.2/manual/quickstart/notification  | manual oficial de Zabbix 2.2]]
  
Los valores se obtienen de la tabla de la base de datos CEN_TELEFONOS, CEN_USUARIOS, ACD_EXTENSIONES, ACD_NODOS, COM_NODOS... correspondientes a la extensión del teléfono, usuario, nodo, etc.
+
===== Usuarios =====
 +
<br><br>
  
variable ${NODO1_C_NOMBRE}='corp-ast13'
 
variable ${EXTEN_C_CLAVE_REGISTRO}='Tel21002'
 
variable ${USU_C_CODIGO_POSTAL}=''28034'
 
variable ${SEDE_C_CODIGO_POSTAL}='28034'
 
variable ${USU_C_NOMBRE}='Juan Antonio'
 
variable ${USU_C_APELLIDO2}='Ramirez'
 
variable ${SEDE_C_NOMBRE}='RED_LAB'
 
variable ${NODO2_C_NOMBRE}= NULL
 
variable ${EXTEN_C_NOMBRE}='' 21002
 
variable ${USU_C_LOCALIDAD}=''
 
variable ${USU_C_NOMBRE_MOSTRAR}='Juan'
 
variable ${NODO1_C_IP}='175.25.129.70'
 
variable ${MODEL_C_PREFIJO_PLANTILLA_MAC}='T28P'
 
variable ${SEDE_C_LOCALIDAD}='Madrid'
 
variable ${USU_C_APELLIDO1}='Casas'
 
variable ${NODO2_C_IP}= NULL
 
variable ${TF_ID_EXTENSION}='5'
 
cargando campos idExten=5
 
  
====== Ficheros y paquetes necesarios ======
+
Zabbix permite la organización de usuarios en grupos para establecer los permisos adecuados de acuerdo al tipo de perfil que deseemos crear. Necesariamente un usuario debe permanecer a un grupo o varios grupos.Todos los usuarios acceden a la aplicación de Zabbix a través de la interfaz Web.
  
'''Paquetes previos:''' libnet-tftpd-perl, tftp-hpa, libnet-address-ip-local-perl
+
Cada usuario Zabbix se le asigna un nombre de usuario único , una contraseña y podemos indicarle que tipo de comunicación que posee, normalmente es vía email, pero puede ser vía a otro tipo de medios. Para mas información ver el [[https://www.zabbix.com/documentation/2.2/manual/web_interface/user_profile || manual oficial ]].
'''Usuario de funcionamiento:''' root
+
 +
===== Visualización =====
 +
<br><br>
 +
 
 +
Con Zabbix es posible visualizar los datos como  gráficos, pantallas, mapas y hasta presentaciones cambiantes, entre otros. En este apartado solo nombraremos características esenciales que se tendra que completar con el [[https://www.zabbix.com/documentation/2.2/manual/config/visualisation | manual oficial]]
 +
====== Graphs ======
 +
<br><br>
  
 
{|
 
{|
 
|-
 
|-
 
|
 
|
  '''Nota:'''  los archivos y directorios que generemos podrian necesitar que se permitiera el acceso al archivo de lectura <br/> y escritura en el servidor TFTP.
+
'''Nota:''' Debe crearse algun item dentro del host para poder utilizar una gráfica.
 
|}
 
|}
 +
En Zabbix una gráfica sirve para representar gráficamente los resultados obtenidos de uno item o varios items.
 +
[[File:EjemploGrafica.png|center|750px]]
 +
Los valores min / avg / max que Zabbix obtiene y representa son de un registro de datos de la tabla tendencias.
 +
 +
====== Screens ======
 +
<br><br>
 +
 +
 +
La pantalla refiere a otra característica adaptable de ZABBIX cuál permite que los usuarios creen las pantallas personalizadas dentro de ZABBIX para exhibir la información. Se considera como una colección de gráficas y no depende del host. Una pantalla puede consistir en gráficos simples, gráficos personalizados, integrar mapas, Alertas, gráficos estadísticos o texto llano tal como los 5 valores pasados de un item particular entre otros; y mostrar la información de forma dinámica.
  
'''Archivos necesarios:'''
+
[[File:EjemploScreen.png|center|750px]]
 +
 
 +
====== Maps ======
 +
<br><br>
 +
 
 +
En Zabbix, un map (mapa) es una representación gráfica de la situacion de nuestros dispositivos en red. Es un escenario que muestra nuestra red, aplicaciones y servicios a través de figuras o iconos.  Dichas figuras toman vida en respuesta a los eventos que se dan en nuestro entorno.
 +
[[File:EjemploMaps.png|center|750px]]
 +
[[File:EstadosMaps.png|center|750px]]
 +
 
 +
 
 +
====== Monitorizar el estado de los raid ======
 +
<br><br>
 +
 
 +
 
 +
Los siguientes comandos son necesarios para poder monitorizar el estado de los raid.
 +
La orden:
 +
 
 +
>hpacucli "ctrl slot=1 logicaldrive 1 show status"
  
/usr/local/sbin/phoneprov-tftp.pl
+
nos proporciona el estado de un raid (p.e. logicaldrive 1 (931.5 GB, 1): Interim Recovery Mode).
/usr/local/sbin/phoneprov-tftp.pm
 
/etc/MDtel/phoneprov-tftp.pconf
 
/etc/init/phoneprov-tftp.conf
 
/etc/logrotate.d/phoneprov-tftp
 
  
 +
La orden:
 +
>hpacucli "ctrl slot=1 logicaldrive all show status"
  
'''Directorios a crear:'''
+
nos proporciona el estado de todos los raid.
  
/var/lib/phoneprov-tftp/plt
+
p.e.:
/var/lib/phoneprov-tftp/bin
+
logicaldrive 1 (931.5 GB, 1): Interim Recovery Mode
  
*El archivo de configuración, '''phoneprov-tftp''', es el siguiente:
+
logicaldrive 2 (1.8 TB, 1): OK.
  
#
+
Para conseguir información genérica el comando
# Configuracion de phoneprov-tftp.pl
 
#
 
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
 
$depurar = 1;
 
 
   
 
   
  # 0: Arranca como proceso - 1: arranca como demonio
+
  ctrl all show config detail
$soyDemonio = 1;
+
 
+
nos muestra mucha información y podemos saber el modelo de disco físico que lleva instalado para poder comprar el modelo antes de "operar".
# Archivo de log ('': salida estandar)
+
 
$logArch = '/var/log/phoneprov-tftp.log';
+
 
+
<br><br>
# Archivo para el pid
+
<div style="
$pidArch = '/var/run/phoneprov-tftp';
+
  text-align:right;
+
  margin-top:20px;
# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
+
  padding:8px;
$unaVezSolo = 0;
+
  border:1px solid #ccc;
+
  background-color:#f9f9f9;
# Conexion de base de datos
+
  border-radius:6px;
$db='nimitz';
+
  display:inline-block;
$dbHost = 'BDTR';
+
">
$dbPort = 3306;
+
[[File:flecha_verde.png|20px|link=#Monitorización en VIVAit]][[#Monitorización en VIVAit | Volver arriba]]
$dbUsuario = 'nimitz';
+
</div>
$dbClave = 'ivivanimitz';
+
<div style="
+
  text-align:right;
# Configuracion de la supervision
+
  margin-top:20px;
$supPort = 1123;
+
  padding:8px;
+
  border:1px solid #ccc;
# Configuracion de servidor TFTP
+
  background-color:#f9f9f9;
#
+
  border-radius:6px;
# Los archivos estaticos no tienen variables. Se sirven sin modificar.
+
  display:inline-block;
# Estan en el arbol de directorios a partir del indicado por '$dirEstatico'
+
">
#
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
# Los archivos dinamicos soportan sustitucion de varibles.
+
</div>
# Las plantillas con variables a sustituir estan en el arbol de directorios
+
<div style="
# a partir del indicado por '$dirPlantilla'.
+
  text-align:right;
# Los archivos temporales con variables sustituidas estan en el arbol
+
  margin-top:20px;
# de directorios a partir del indicado por '$dirDinamico'.
+
  padding:8px;
# Los archivos dinamicos se identifican porque contienen una mac.
+
  border:1px solid #ccc;
# Tambien se identifican en base a las lineas que comienzan con '@'.
+
  background-color:#f9f9f9;
# En este ultimo caso, no se refieren a un telefono y puede tener pocas vars.
+
  border-radius:6px;
#
+
  display:inline-block;
$miDir = '';
+
">
$bindDir = '';
+
[[File:casa.png|20px|link=#]][[# | Página Principal]]
$bindPuerto = 69;
+
</div>
$dirPlantilla = '/var/lib/phoneprov-tftp/plt';
+
<br><br>
$dirEstatico = '/var/lib/phoneprov-tftp/bin';
+
 
$dirDinamico = '/tmp';
+
==== Zabbix en '''MD'''tel ====
$toRRQ = 10;
+
<br><br>
$toACK = 5;
+
 
$errACK = 3;
+
 
$tamBlq = 512;
+
===== Configuraciones de Zabbix =====
+
<br><br>
# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_EXTENSIONES
+
 
  $clasesCamposExtension = '50';
+
====== Agentes Zabbix ======
# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_USUARIOS
+
{|-
$clasesCamposUsuario = '70';
+
|
+
|
# Expresiones regulares de archivos con mac estaticos (separados por '>')
+
  '''Nota:''' Hay que instalar un agente Zabbix en cada maquina que se quiera monitorizar.
$nomArchMacEstaticos = '^SEP.*\.tlv$>^SEP.*\.bin$>^SP.*\.xml$';
+
|}
+
 
# Traducciones previas de nombres de archivo estaticos
+
El agente de Zabbix puede recoger datos:
#%archivo = 'trad';
+
*'''De forma pasiva:''' el server contacta al agente pidiéndole un dato (por ejemplo el consumo de CPU en ese instante) y el agente responde al server con ese dato. A esta acción del agente le llamaremos '''Agente activo'''.
+
*'''De forma activa:''' en un primer momento, el server le enviará al agente el listado de items a monitorizar. A partir de ese momento, será el agente que de forma periódica recogerá datos sobre esos ítems y se los hará llegar al server. A esta acción del agente le llamaremos ''''''Agente pasivo''''''.
# Traducciones previas de nombres de archivo dinamicos sin mac
+
 
@y000000000044.cfg = 'Yealink-T23G-comun.cfg';
 
@y000000000034.cfg = 'Yealink-T21P-comun.cfg';
 
@y000000000000.cfg = 'Yealink-T28P-comun.cfg';
 
@y000000000004.cfg = 'Yealink-T26P-comun.cfg';
 
@y000000000036.cfg = 'Yealink-T41P-comun.cfg';
 
@y000000000058.cfg = 'Yealink-T58V-comun.cfg';
 
@y000000000069.cfg = 'Yealink-T27G-comun.cfg';
 
@snom710.htm = 'Snom-710-comun.cfg';
 
@snom710-firmware.xml = 'Snom-710-firmware.xml';
 
@spa514G.cfg = 'cisco-spa514G.cfg';
 
@spa512G.cfg = 'cisco-spa512G.cfg';
 
  
  
*Los campos del fuchero de configuración y su significado se muestran en la su¡iguiente tabla:
+
====== Configurar agente de forma pasiva ======
 +
<br><br>
 +
Para configurar el agente de Zabbix necesitamos acceder a la maquina que actuará como agente, y en el directorio /etc/zabbix modificar el fichero '''zabbix_agentd.conf''' e indicar cual es la dirección de red (IP) del servidor Zabbix.
  
{| class="wikitable"
+
{|  
 
|-
 
|-
!Campo !!Descripción !!Posibles valores (si aplica)
+
|
|-
+
##### Passive checks related
|$depurar||# 0: Solo alarmas en archivo log - 1: alarmas y trazas||
+
### Option: Server
|-
+
#      List of comma delimited IP addresses (or hostnames) of Zabbix servers.
|$soyDemonio||# 0: Arranca como proceso - 1: arranca como demonio||
+
#      Incoming connections will be accepted only from the hosts listed here.
|-
+
#       If IPv6 support is enabled then '127.0.0.1', '::127.0.0.1', '::ffff:127.0.0.1' 
|$logArch =||# Archivo de log ('': salida estandar)||
+
#      are treated equall$
 +
#
 +
# Mandatory: no
 +
# Default:
 +
Server= IP.Server Zabbix.
 +
|}
 +
Tras la configuración del fichero, debemos reiniciar el servicio de los agentes.
 +
{|
 
|-
 
|-
|$pidArch||# Archivo para el pid||
+
|
 +
sudo service zabbix-agent restart
 +
|}
 +
 
 +
====== Configurar agente de forma activa ======
 +
<br><br>
 +
 
 +
Para configurar el agente de Zabbix necesitamos acceder a la máquina que actuará como agente, y en el directorio /etc/zabbix modificar el fichero '''zabbix_agentd.conf''' e indicar cual es la dirección de red (IP) del servidor Zabbix.
 +
 
 +
{|  
 
|-
 
|-
|$unaVezSolo||# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)||
+
|  
 +
##### Active checks related
 +
### Option: ServerActive
 +
#      List of comma delimited IP:port (or hostname:port) pairs of Zabbix serv$
 +
#      If port is not specified, default port is used.
 +
#      IPv6 addresses must be enclosed in square brackets if port for that hos$
 +
#      If port is not specified, square brackets for IPv6 addresses are option$
 +
#      If this parameter is not specified, active checks are disabled.
 +
#       Example: ServerActive=127.0.0.1:20051,zabbix.domain,[::1]:30051,::1,[12$
 +
#
 +
# Mandatory: no
 +
# Default:
 +
ServerActive=127.0.0.1
 +
--------------------------sección separada----------------------------
 +
### Option: UserParameter
 +
#      User-defined parameter to monitor. There can be several user-defined pa$
 +
#      Format: UserParameter=<key>,<shell command>
 +
#      See 'zabbix_agentd' directory for examples.
 +
#
 +
# Mandatory: no
 +
# Default:
 +
# UserParameter=
 +
User_parameters:asterisk.pid, /usr/bin/asterisk -rx 'core show chanels'|grep 'active calls'| cat -d -f 1
 +
|}
 +
 
 +
El parámetro '''User_parameters''' tiene un formato de este estilo:
 +
{|
 
|-
 
|-
|$db||Nombre de la base de datos||
+
|
 +
User_parameters: NombreMedida, comando.
 +
|}
 +
 
 +
El nombre de la medida se refiere al nombre que demos a la aplicación , no hace falta que exista una aplicación con ese nombre en Zabbix, y el comando , es el comando remoto que tiene que ejecutar el servidor Zabbix. Posiblemente necesita darse permisos para ejecutar el comando y siempre debe devolver un valor (un numero o un tiempo) que el servidor Zabbix puede manejar.
 +
Tras la configuración del fichero, debemos reiniciar el servicio de los agentes.
 +
{|
 
|-
 
|-
|$dbHost||IP o HOST máquina base de datos de tiempo real||
+
|
|-
+
sudo service zabbix-agent restart
|$dbPort||Puerto de escucha de mysql||
+
|}
|-
+
<br><br>
|$dbUsuario||Usuario acceso Base de datos de tiempo real||
+
<div style="
|-
+
  text-align:right;
|$dbClave||Clave usuario acceso base de datos de tiempo real||
+
  margin-top:20px;
|-
+
  padding:8px;
|$supPort ||Puerto de supervisión del demonio||
+
  border:1px solid #ccc;
|-
+
  background-color:#f9f9f9;
|$miDir ||||
+
  border-radius:6px;
|-
+
  display:inline-block;
|$bindDir||bindAddres||
+
">
|-
+
[[File:flecha_verde.png|20px|link=#Zabbix en MDtel]][[#Zabbix en MDtel| Volver arriba]]
|$bindPuerto||Puerto de escucha del demonio||
+
</div>
|-
+
<div style="
|$dirPlantilla||Directorio de las plantillas de aprovisionamiento||
+
  text-align:right;
|-
+
  margin-top:20px;
|$dirEstatico||Directorio archivos estáticos||
+
  padding:8px;
|-
+
  border:1px solid #ccc;
|$dirDinamico||# Los archivos temporales con variables sustituidas están en el árbol de directorios a partir del indicado por '$dirDinamico'.||
+
  background-color:#f9f9f9;
|-
+
  border-radius:6px;
|$toRRQ ||||
+
  display:inline-block;
|-
+
">
|$toACK||Timeout ACK||
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
|-
+
</div>
|$errACK||Número de errores de ACK||
+
<div style="
|-
+
  text-align:right;
|$tamBlq||Tamaño del bloque de archivos a transferir||
+
  margin-top:20px;
|-
+
  padding:8px;
|$clasesCamposExtension||# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_EXTENSIONES ||
+
  border:1px solid #ccc;
|-
+
  background-color:#f9f9f9;
|$clasesCamposUsuario||# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_USUARIOS ||
+
  border-radius:6px;
|-
+
  display:inline-block;
|$nomArchMacEstaticos||# Expresiones regulares de archivos con mac estaticos (separados por '>')||
+
">
|-
+
[[File:casa.png|20px|link=#]][[# | Página Principal]]
|%archivo||# Traducciones previas de nombres de archivo estaticos||
+
</div>
|-
+
<br><br>
|@y000000000044.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
 
|-
+
===== Scripts del Servidor Zabbix =====
|@y000000000034.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
<br><br>
|-
+
 
|@y000000000000.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
{|
|-
+
|
|@y000000000004.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
|
|-
+
'''Nota''': <small>No olvidar que en la misma maquina del server Zabbix, debe configurarse como agente de Zabbix.</small>
|@y000000000036.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
|}
|-
+
Después de realizar la [[# Instalación de Zabbix | Instalación de Zabbix ]] correctamente. Se han creado otros ficheros scripts (''scripts propios de '''md'''tel'') que facilitarán la petición del servidor a los agentes activos, para poder parametrizar todos los elementos del negocio que suelen monitorizarse.
|@y000000000058.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
Dependiendo de lo que vaya a monitorizarse necesitaremos algún script o todos. Algunos nos informan sobre elementos de negocio, saber si asterisk funciona , monitorizar el CTI (lanzara nc localhost 1111) , controlar el Intz-Nimitz, comprobar si funciona motalsal, ect.
|-
+
 
|@y000000000069.cfg||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
Cada script se exportara a los host, para que pueda facilitar los datos que pide el servidor Zabbix y configurarse.
|-
+
Por ejemplo,para monitorizar las llamadas en curso del ACD, agentes conectados, agentes desconectados, etc.
|@snom710.htm||# Traducciones previas de nombres de archivo dinámicos sin mac||
+
Todos los scripts se deben colocar en el directorio /usr/local/sbin con permisos 755, su nombre es parecido a "zabbixSenderXXXXX.pl"
|-
+
{|
|@snom710-firmware.xml||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|@spa514G.cfg ||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
|-
 
|@spa512G.cfg ||# Traducciones previas de nombres de archivo dinámicos sin mac||
 
 
|-
 
|-
 +
|
 +
ls /usr/local/sbin/ |grep zabbixSender
 +
'''zabbixSenderACDBD.pl'''
 +
'''zabbixSenderACD.pl'''
 +
'''zabbixSenderCTI.pl'''
 +
'''zabbixSender-intz-nimitz.pl'''
 +
'''zabbixSenderMotorSal.pl'''
 +
'''zabbixSenderMyACDSuperv.pl'''
 +
'''zabbixSenderRecordNodo.pl'''
 +
'''zabbixSenderRecordCentral.pl'''
 
|}
 
|}
  
==== Watchdog ====
+
Se crea una tarea programada en linux para poder ejecutarse los scripts, programando el tiempo en que debe ejecutarse.
 +
 
 +
Si visualizo que "............" aparece:
  
Se trata de una aplicación del asterisk que monitoriza el SIP y en caso de fallo, pasado un cierto tiempo, reinicia el asterisk y genera un core.
+
*****  root zabbix
Si escribimos en CLI de asterisk perro tenemos los siguientes comandos:
 
  
{| class="wikitable" border="0" style="background:#ffffff" align="top"
+
====== zabbixSenderACDBD.pl ======
|-
+
<br><br>
|Activar||Activar el Watchdog
 
|-
 
|Desactivar||Desactiva el Watchdog
 
|-
 
|Parada IWantToStop||Reinicia el asterisk y genera un core para pruebas
 
|-
 
|Reload||Realiza una recarga del Watchdog y aplica cambios en su configuración
 
|-
 
|Show||Ver el estado del Watchdog
 
  
perro avisado=0 activo=1 segsDormir=1 segsInic=60 segsGuarda=30 maxErr=3
+
'''Uso:''' Obtiene diversos valores por cada cola, estados de agente por cola y estados de agente generales.
perro        nombre=sip_monitor_udp lwp=[15437] segsInic=60 segsGuarda=30 hace=11 err=0/5
+
 
 +
'''Ubicación:''' Servidor BDTR.
 +
 
 +
'''Parámetros:''' Ruta al archivo de configuración (Por ejemplo: ''/etc/MDtel/zabbixSenderACDBD.pconf'')
 +
 
 +
'''Archivo de configuración:''' zabbixSenderACDBD.pconf
 +
 
 +
{|
 
|-
 
|-
 +
|
 +
<small>'''$db:''' Nombre de la BBDD (normalmente nimitz)
 +
'''$dbHost:''' Dirección IP del servidor de BBDD de TR (normalmente BDTR)
 +
'''$dbPort:''' Puerto MySQL (normalmente 3306)
 +
'''$dbUsuario:''' Usuario MySQL (normalmente nimitz)
 +
'''$dbClave:''' Clave del usuario
 +
'''$sZab:''' Dirección IP del servidor Zabbix
 +
'''$hZab:''' Nombre del host Zabbix (normalmente el nombre de máquina, tal y como se configura en
 +
zabbix_agentd.conf o en el host en la web de Zabbix)</small>
 
|}
 
|}
  
El dato "hace" informa de cuanto tiempo ha transcurrido desde el último tick. Facilita la calibración del parámetro de configuración "segs_guarda", normalmente es 30
+
====== zabbixSenderACD.pl ======
 +
<br><br>
  
Tiene un fichero de configuración ubicado en /etc/asterisk/MDcrash.conf
+
'''Uso:''' Obtener el PID de Asterisk para revisar si se ha reiniciado en caso de que cambie.
  
{| class="wikitable" border="0" style="background:#ffffff" align="top"
+
'''Ubicación:''' Servidor ACD.
|-
 
|Sección [perro]
 
||activo=yes (Si esta o no activo)
 
segs_dormir=1 (Un tick por segundo)
 
  
segs_inic=60
+
'''Parámetros:''' Ruta al archivo de configuración (Por ejemplo: ''/etc/MDtel/zabbixSenderACD.pconf'').
  
segs_guarda=30
+
'''Archivo de configuración:''' zabbixSenderACDBD.pconf.
  
max_errores=3 
+
{|
 
|-
 
|-
|Sección [sip_monitor_udp]
+
|  
||segs_inic=60
+
<small>'''$db:''' Nombre de la BBDD (normalmente nimitz)
 +
'''$dbHost:''' Dirección IP del servidor de BBDD de TR (normalmente BDTR)
 +
'''$dbPort:''' Puerto MySQL (normalmente 3306)
 +
'''$dbUsuario:''' Usuario MySQL (normalmente nimitz)
 +
'''$dbClave:''' Clave del usuario
 +
'''$sZab:''' Dirección IP del servidor Zabbix
 +
'''$hZab:''' Nombre del host Zabbix (normalmente el nombre de máquina, tal y como se configura en
 +
zabbix_agentd.conf o en el host en la web de Zabbix)</small>
 +
|}
 +
 
 +
====== zabbixSenderCTI.pl ======
 +
<br><br>
 +
 
 +
'''Uso:''' Obtener estado y los distintos valores de vivait-cti.
  
segs_guarda=30 (Cada 30 segundos si no reciba trafico SIP genera core)
+
'''Ubicación:''' Servidor donde se ejecute vivait-cti. Normalmente el servidor ACD.
  
max_errores=5 (Número máximo de errores)
+
'''Parámetros:'''
 +
{|
 
|-
 
|-
 +
|
 +
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 +
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 
|}
 
|}
  
<!-- <br><br>
+
====== zabbixSender-intz-nimitz.pl ======
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
+
<br><br>
<br><br>-->
 
  
==== Proceso de Backup ====
+
'''Uso:''' Obtener estado y los distintos valores de intz-nimitz.
Las plataformas '''''VIVA'''''it Call y '''''VIVA'''''it Suite incluyen un script para realizar un proceso de backup.
 
  
Se utilizará el script '''backup.sh''', que se encuentra en el directorio '''etc/MDTel'''.
+
'''Ubicación:''' Servidor donde se ejecute intz-nimitz.
 +
 
 +
'''Parámetros:'''
 +
{|
 +
|-
 +
|
 +
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 +
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 +
|}
  
Se ejecuta automaticamente mediante el uso de un cron
+
====== zabbixSenderMotorSal.pl ======
 +
<br><br>
  
'''texto del cron:'''
+
'''Uso:''' Obtener estado y los distintos valores de motorSal.
  
SHELL=/bin/sh
+
'''Ubicación:''' Servidor donde se ejecute motorSal.
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
# m h dom mon dow user command
 
0 2 * * * root  /etc/MDtel/backup.sh /etc/MDtel/backup.cfg
 
  
Para activar el script hay que descomentar la línea
+
'''Parámetros:'''
# m h dom mon dow user command
+
{|
 +
|-
 +
|
 +
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 +
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 +
|}
  
Los directorios de los que se hace copia son:
+
====== zabbixSenderMyACDSuperv.pl ======
* DIR=var/lib/asterisk/sounds/Particular
+
<br><br>
* DIR=var/lib/asterisk/moh
 
* DIR=etc
 
* DIR=etc/asterisk
 
* DIR=etc/cron.d
 
* DIR=etc/dahdi
 
* DIR=etc/exim4
 
* DIR=etc/ha.d
 
* DIR=etc/logrotate.d
 
* DIR=etc/MDtel
 
* DIR=etc/mysql
 
* DIR=etc/network
 
* DIR=etc/zabbix
 
* DIR=usr/local/sbin
 
  
Por defecto se realiza un backup cada dos horas en la carpeta '''/var/spool/MDtel/backup'''.
+
'''Uso:''' Obtener estado y los distintos valores de myAcdSuperv.
  
Para cambiar la ruta de destino del backup habrá que modificar el fichero backup.sh, en concreto modificar la variable MDTEL.
+
'''Ubicación:''' Servidor donde se ejecute myAcdSuperv.
  
El fichero ''' backup.cfg''' que se genera incluye copia de la siguiente información:
+
'''Parámetros:'''
* Ficheros de configuración de la aplicación.
+
{|
* Base de Datos.
+
|-
* Dialplan.
+
|
 +
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 +
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 +
|}
  
Se guardarán 10 copias del fichero ''' backup.cfg '''
+
====== zabbixSenderRecordNodo.pl ======
 +
<br><br>
  
Los campos disponibles en el fichero son los siguientes:
+
'''Uso:''' Obtener estado y los distintos valores de recordNodo.
  
{| class="wikitable"
+
'''Ubicación:''' Servidor donde se ejecute recordNodo.
|-
+
 
!Campo !!Descripción !!Posibles valores (si aplica)
+
'''Parámetros:'''
|-
+
{|
|IP_BD ||IP o HOST máquina base de datos de tiempo real||
 
|-
 
|HAY_SMB ||Si hay o no servidor SAMBA||1 si existe servidor SAMBA o 0 si no existe
 
|-
 
|HOST_SMB||IP o HOST servidor SAMBA||
 
|-
 
|USU_SMB||Usuario acceso servidor SAMBA||
 
|-
 
|CLAVE_SMB||Clave usuario acceso servidor SAMBA||
 
|-
 
|RUTA_SMB||Ruta donde se guardará el backup en el servidor SAMBA||
 
 
|-
 
|-
 +
|
 +
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 +
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 
|}
 
|}
  
Para recuperar una plataforma utilizando el backup, habrá que instalar una máquina nueva y cargar los ficheros de configuración, Base de Datos y Dialplan guardados en el proceso de backup.
+
====== zabbixSenderRecordCentral.pl ======
 +
<br><br>
  
===== Información adicional: como funciona un cron =====
+
'''Uso:''' Obtener estado y los distintos valores de recordCentral.
  
La información sobre el fucnionamiento de un cron puede encontrarse en: [http://lasegundapuerta.com/index.php/informatica/linux-y-software-libre/1709-comando-cron-en-linux-ubuntu Información sobre el comando cron]
+
'''Ubicación:''' Servidor donde se ejecute recordCentral.
  
==== CHAT ====
+
'''Parámetros:'''
La información para configurar el CHAT y su funcionamiento puede encontrarse en:
+
{|
 +
|-
 +
|
 +
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 +
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 +
|}
  
[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#CHAT_2 enlace]]
 
  
==== MEET ====
+
A continuación se muestra una tabla resumen de los distintos scripts y sus funcionalidades:
  
El esquema de conexión para el Meet es el siguiente:
+
[[Archivo:Zabbix_scripts.png |960px]]
  
[[File:Conexion.jpg|800px]]
+
====== Dimensionamiento del servidor (Startpollers) ======
 +
<br><br>
  
 +
{|
 +
|
 +
|
 +
'''Nota''': <small>EL parámetro StartPollers es un <u>parámetro numérico</u> que forma parte del fichero de configuración
 +
del servidor Zabbix(zabbix_server.conf). Por defecto el servidor Zabbix está configurado para
 +
iniciar con cinco startpollers.</small>
 +
|}
  
La configuración necesaria en los navegadores, para posibilitar que se puedan compartir pantallas, se encuentra en el siguiente [[Preguntas_frecuentes_administraci%C3%B3n|enlace]]
+
El servidor Zabbix puede hacer peticiones a los agentes de las medidas que necesita o quiere. O en caso contrario los agentes envian en un tiempo determinado la información al servidor. Para recibir todas estas peticiones necesitamos los pollers. 
  
 +
Los poller son los procesos encargados de recibir todas las peticiones de medidas. Aumentaremos su cantidad dependiendo de la necesitad que tengamos. Para ello podemos observar la queue , que es la encargada de almacenar un listado de todas las cosas que están pedidas para medirse y recibirse.  SI por ejemplo esta cola (queue) muestra mas de mil medidas seguramente estos pollers sean un cuello de botella y habrá que aumentar su numero.
  
Ficheros:
+
====== Templates ======
 +
<br><br>
  
*El fichero config.json tiene la configuración necesaria para proporcionar el servicio.  
+
Zabbix cuenta con templates (plantillas) que facilitan la tarea de "Registrar Equipos y Dispositivos" y agregarles métricas; acelerar el despliegue de las tareas de supervisión en un host; aplicar cambios masivos a tareas de supervisión. En '''md'''tel hemos creado plantillas propias que facilitan estos procesos, los cuales necesitaremos [[#Importar templates |importar templates]].
  
 +
Las plantillas están vinculados directamente a los hosts individuales, por tanto se necesitaran utilizar en cada host.
  
Fichero de configuracion MEET:
+
Automáticamente, cada template rellena por item las aplicaciones, trigers, alarmas,gráficos,... etc.
  
/etc/janus/janus.cfg
+
A continuación, se muestran los distintos bloques de funciones de la instalación en función de cada template:
/etc/janus/janus.plugin.echotest.cfg
 
/etc/janus/janus.transport.http.cfg
 
/etc/janus/janus.transport.websockets.cfg
 
/etc/janus/vivait.plugin.meet.cfg
 
/etc/janus/vivait.plugin.move.cfg
 
  
En los archivos de configuracion, es obligatorio revisar:
+
{| class="wikitable" style="text-align:center;"
*janus.cfg
+
|-
interface = IP_NODO
+
! Templates !! Se instalan en general
server_name = IP_NODO
+
|-
ice_enforce_list = IP_NODO (e ip publicas, si las hay)
+
| DRBD|| SI (si clúster)
 +
|-
 +
| motorSal|| -
 +
|-
 +
| Vivait-Suite ACD|| -
 +
|-
 +
| Vivait-Suite BBDD|| -
 +
|-
 +
| Vivait-Suite Record|| -
 +
|-
 +
| Vivait-Suite GW|| -
 +
|-
 +
| Vivait-Call Asterisk|| -
 +
|-
 +
| Vivait-Call bdCentral|| -
 +
|-
 +
| Vivait-Call bdNodo|| si
 +
|-
 +
| cambiarPerfil_Cal|| -
 +
|-
 +
| Template App Zabbix Server|| -
 +
|-
 +
| Template_OS_Linux*|| si(si no posee ip virtuales de clúster)
 +
|-
 +
| Template_App_MySQL|| si
 +
|-
 +
|}
  
*vivait.plugin.meet.cfg
 
meet_url = https://IP_NODO/meet#
 
local_nodo_id = ID_NODO
 
local_ip = IP_NODO (escucha [sip])
 
email_from_default_invitation = vivait-meet-18-04@mdtel.local
 
smart_host = mdsmtp.mdtel.net
 
  
*vivait.plugin.move.cfg
 
local_nodo_id = ID_NODO
 
local_ip = IP_NODO (escucha [sip])
 
  
Fichero de logs:
+
{| class="wikitable" style="text-align:center;"
 
+
|+ '''Dependiendo del tipo de nodo:'''
/var/log/janus.log
+
|-
 
+
! Templates !! ACD !! Corporativo/GW
 
+
|-
Los posibles problemas de conexión de los usuarios al portal habrá que analizarlos en la consola para analistas del  navegador.
+
| DRBD|| - || -
 
+
|-
La configuración necesaria en el portal de administración de '''''VIVA'''''it Call se puede consultar en este [[Portal_de_administraci%C3%B3n_VIVAit#VIVAit_Meet_.28En_Construcci.C3.B3n.29|enlace]].
+
| motorSal|| - || -
 
+
|-
====Gran Hermano (GH)====
+
| Vivait-Suite ACD|| Si || -
 +
|-
 +
| Vivait-Suite BBDD|| - || -
 +
|-
 +
| Vivait-Suite Record|| - || -
 +
|-
 +
| Vivait-Suite GW|| - || Si
 +
|-
 +
| Vivait-Call Asterisk|| - || Si
 +
|-
 +
| Vivait-Call bdCentral|| - || -
 +
|-
 +
| Vivait-Call bdNodo|| - || -
 +
|-
 +
| cambiarPerfil_Cal|| - || -
 +
|-
 +
| Template App Zabbix Server|| - || -
 +
|-
 +
| Template_OS_Linux*|| - || -
 +
|-
 +
| Template_App_MySQL|| - || -
 +
|-
 +
|}
  
Gran Hermano (GH) controla el estado de las extensiones de diferentes nodos. Esto permite gestionar servicios como la movilidad avanzada, la retrollamada entre extensiones de diferentes nodos, el uso de BLF's por parte de los usuarios en movilidad,…
 
  
Esquema de instalación:
 
  
[[File:Gran hermano.png|800px |center]]
+
{| class="wikitable" style="text-align:center;"
 +
|+ '''Dependiendo del tipo de Base de dato'''s:
 +
|-
 +
! Templates !! BBDD <br />Tiempo Real !! BBDD<br /> Réplica !! BBDD Copia
 +
|-
 +
| DRBD|| - || - || -
 +
|-
 +
| motorSal|| Si(si ACD) || - || -
 +
|-
 +
| Vivait-Suite ACD|| - || - || -
 +
|-
 +
| Vivait-Suite BBDD|| si || si || si
 +
|-
 +
| Vivait-Suite Record|| - || - || -
 +
|-
 +
| Vivait-Suite GW|| - || - || -
 +
|-
 +
| Vivait-Call Asterisk|| - || - || -
 +
|-
 +
| Vivait-Call bdCentral|| si || - || -
 +
|-
 +
| Vivait-Call bdNodo|| - || - || -
 +
|-
 +
| cambiarPerfil_Cal|| - || - || -
 +
|-
 +
| Template App Zabbix Server|| - || - || -
 +
|-
 +
| Template_OS_Linux*|| - || - || -
 +
|-
 +
| Template_App_MySQL|| - || - || -
 +
|-
 +
|}
  
  
  
GH solo se instala en un nodo. Recomendamos instalarlo en el nodo con menos carga. Si desconocemos cual
+
{| class="wikitable" style="text-align:center;"
es, lo instalaremos en la maquina con BDHIST.
+
|-
 
+
! Templates !! Administración
 
+
|-
===== Intz-gh =====
+
| DRBD|| -
El demonio que gestiona el Gran Hermano es Intz-gh, que se encuentra en versión V0.1.0.
+
|-
 +
| motorSal|| -
 +
|-
 +
| Vivait-Suite ACD|| -
 +
|-
 +
| Vivait-Suite BBDD|| -
 +
|-
 +
| Vivait-Suite Record|| -
 +
|-
 +
| Vivait-Suite GW|| -
 +
|-
 +
| Vivait-Call Asterisk|| -
 +
|-
 +
| Vivait-Call bdCentral|| -
 +
|-
 +
| Vivait-Call bdNodo|| -
 +
|-
 +
| cambiarPerfil_Cal||SI (si posee servidor calendarios)
 +
|-
 +
| Template App Zabbix Server|| -
 +
|-
 +
| Template_OS_Linux*|| -
 +
|-
 +
| Template_App_MySQL|| -  
 +
|-
 +
|}
 +
 
 +
 
  
El demonio tiene un fichero de configuración:  '''/etc/Mdtel/intz-gh.conf''' con el siguiente aspecto:
+
{| class="wikitable" style="text-align:center;"
+
|-
#
+
! Templates !! Servidor de grabaciones
# Los nombres no pueden tener numeros
+
|-
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
+
| DRBD|| -
# Los valores comentados indican valores por defecto
+
|-
base
+
| motorSal|| -
{
+
|-
cfg
+
| Vivait-Suite ACD|| -  
{
+
|-  
soy_demonio = 1
+
| Vivait-Suite BBDD|| -
hay_syslog = 0
+
|-
# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
+
| Vivait-Suite Record|| Si
archivo_pid = -
+
|-
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
+
| Vivait-Suite GW|| -
# No se usa si se activa hay_syslog
+
|-
archivo_traza = -
+
| Vivait-Call Asterisk|| -
}
+
|-
cfg_recarga
+
| Vivait-Call bdCentral|| -
{
+
|-
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
+
| Vivait-Call bdNodo|| -
nivel_traza = 3
+
|-
pruebas = 1
+
| cambiarPerfil_Cal||-
hay_flush_traza = 1
+
|-
# traza_milisegundos = 1
+
| Template App Zabbix Server|| -
}
+
|-
sis
+
| Template_OS_Linux*|| -
{
+
|-
# No se usa. No modificar
+
| Template_App_MySQL|| -
subsistema = 0
+
|-
}
+
|}
gmp
+
 
{
+
 
# Numero de mensajes. No modificar
+
 
num_msj = 256# Numero de buffer. No modificar
+
{| class="wikitable" style="text-align:center;"
num_buf = 256
+
|+ '''Monitorización'''
}
+
|-
}
+
! Templates !! General !! Contact Center
supervision
+
|-
{
+
| DRBD|| - || -
puerto_escucha = 1116
+
|-
}
+
| motorSal|| - || -
supervision_recarga
+
|-
{
+
| Vivait-Suite ACD|| - || -
to_periodo = 60
+
|-
}
+
| Vivait-Suite BBDD|| - || -
regexp
+
|-
{
+
| Vivait-Suite Record|| - || -
hay_regexp = 1
+
|-
}
+
| Vivait-Suite GW|| - || -
regexp_recarga
+
|-
{
+
| Vivait-Call Asterisk|| - || -
num_entradas = 32
+
|-
inc_entradas = 128
+
| Vivait-Call bdCentral|| - || -
max_entradas = 1024
+
|-
}
+
| Vivait-Call bdNodo|| - || -
vivaitcall
+
|-
{
+
| cambiarPerfil_Cal|| - || -
hay_vic = 1
+
|-
puerto_escucha = 5556
+
| Template App Zabbix Server|| si || -
identif = gh_000
+
|-
entorno = gh
+
| Template_OS_Linux*|| - || -
max_conx = 4
+
|-
}
+
| Template_App_MySQL|| - || -
vivaitcall_recarga
+
|-
{
+
|}
to_solicitud = 10
+
 
to_desconexion = 10
+
 
ip_valida
+
 
{
+
====== '''Resumen''' ======
# Hasta 32 bloques de direcciones validas
+
<br><br>
todas
+
 
{
+
{| class="wikitable"
ip = 0.0.0.0
+
|-
msk = 0.0.0.0
+
!Plantillas MDTEL !! Trigger !! Descripción !! Severidad !! Actuación a llevar a cabo
}
+
|-
localhost
+
|Template DRBD||DRBD balanceado en {HOST.NAME}||El DRBD ha balanceado en Host||Desastre||Revisar ambos nodos del cluster.  
{
+
Comprobar que el DRBD está sincronizado (cat /proc/drbd).
ip = 127.0.0.1
+
|-
msk = 255.255.255.255}
+
|Template DRBD||DRBD desconectado en {HOST.NAME}||El DRBD esta desconectado en Host||Desastre||Revisar Host. Comprobar estado del DRBD (cat /proc/drbd)
}
+
|-
}
+
|Template DRBD||DRBD no actualizado en {HOST.NAME}||Estado de disco invalido en DRBD (cat /proc/drbd no devuelve UpToDate)||Desastre||Forzar sincronización del DRBD
mysql
+
|-
{
+
|Template motorSal||motorSal caido||El motorSal esta caido||Desastre||Reiniciar motorSal.
hay_mysql = 1
+
Revisar log (var/log/motorsal.log) para averiguar la causa
host = BDTR
 
usuario = nimitz
 
clave = phikau3iwCe4O0PP5b09ng==
 
base_datos = nimitz
 
}
 
mysql_recarga
 
{
 
to_resp = 5
 
}
 
gh1
 
{
 
hay_gh1 = 1
 
# umbrales para el numero de digitos de una extension
 
# sirve para saber si un peer es una extension o un enlace
 
exten_min_digi = 3
 
exten_max_digi = 8
 
# numero maximo de extensiones soportadas
 
exten_max = 500
 
# numero maximo de enlaces soportados
 
enla_max = 20
 
# numero maximo de retrollamadas activas concurrentes
 
retro_max = 50
 
# numero maximo de retrollamadas activas concurrentes para una extension como destino (max 31)
 
retro_max_b = 4
 
}
 
gh1_recarga
 
{
 
# tiempo maximo en segs. para activar una retrollamada tras finalizar llamada
 
to_retro_candidato = 60
 
# tiempo maximo en segs. que una retrollamada espera a que las extensiones esten libres
 
to_retro_activo = 300
 
# temporizador de limpieza de tablas en segs.
 
to_limpiar = 10
 
}
 
ias
 
{
 
hay_ias = 1
 
url = mdgh_rest
 
puerto = 8090
 
}ias_recarga
 
{
 
# tiempo maximo en segs. para conectar con asterisk para comandos
 
to_conx_cmd = 10
 
# periodo en horas para actualizar lista de id de nodos y sus direcciones ip
 
to_lista_nodos = 1
 
}
 
 
 
Los campos del fichero de configuración y su significado son los siguientes:
 
 
 
 
 
{| class="wikitable"
 
|-
 
!Campo!!Descripción
 
 
|-
 
|-
|soy_demonio || # 0: Arranca como proceso - 1: arranca como demonio
+
|Template Vivait-Call Asterisk||Asterisk reiniciado||El Asterisk se ha reiniciado||Alta||Comprobar que ha arrancado correctamente.
 +
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
 
|-
 
|-
|hay_syslog || Si hay servidor de syslog
+
|Template Vivait-Call Asterisk||Error en enrutamiento||Error en enrutamiento||Baja||Revisar full de asterisk para comprobar donde está el error.
 +
Corregir (añadir prerutas o lo que sea necesario).
 
|-
 
|-
|archivo_pid || # Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)
+
|Template Vivait-Call Asterisk||No hay extensiones registradas||No hay extensiones registradas||Alta||Revisar full de asterisk para comprobar donde está el error.
 +
Revisar sip_WEB.conf
 
|-
 
|-
|archivo_traza | |# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)
+
|Template Vivait-Call Asterisk||No hay trunks activos||No hay trunks activos||Baja||Revisar full de asterisk para comprobar donde está el error.
 +
Revisar enlaces en portal.
 
|-
 
|-
|nivel_traza || # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
+
|Template Vivait-Call bdCentral||Error en bdCentral||Se ha dado un error en el bdCentrlal||Alta||Revisar BBDD central.
 
|-
 
|-
|pruebas ||
+
|Template Vivait-Call cambiarPerfil_Cal||cambiarPerfil_Cal no ejecutado||No se ha ejecutado cambiarPerfil||Alta||Revisar log (/var/log/cambiarPerfil_Cal.log).
 +
Actuar en consecuencia
 
|-
 
|-
|hay_flush_traza ||
+
|Template Vivait-Call cambiarPerfil_Cal||Error en cambiarPerfil_Cal||Ha dado un error al cambiar el perfil||Alta||Revisar log (/var/log/cambiarPerfil_Cal.log).
 +
Actuar en consecuencia
 
|-
 
|-
|traza_milisegundos ||
+
|Template Vivait-Suite ACD||PID Asterisk cambiado||El PID de Asterisk ha cambiado||Desastre||Comprobar que ha arrancado correctamente.
 +
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura
 
|-
 
|-
|subsistema || # No se usa. No modificar
+
|Template Vivait-Suite ACD||VivaitCTI caido||El CTI está caido||Alta||Reiniciar vivait-cti. Comprobar en log (/var/log/vivait-cti.log) la causa
 
|-
 
|-
|num_msj || # Numero de mensajes. No modificar
+
|Template Vivait-Suite ACD||Vivait-CTI desconectado de Asterisk||El CTI está desconetado de Asterisk || Desastre ||Comprobar que ha arrancado correctamente.
 +
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
 
|-
 
|-
|num_buf || # Numero de buffer. No modificar
+
|Template Vivait-Suite BBDD||MyACDSuperV caido||MyACDSuperV esta caido||Alta||Iniciar myAcdSuperv. Comprobar en log /var/log/myAcdSuperv.log) la causa.
 
|-
 
|-
|puerto_escucha || Puesto escucha del demonio
+
|Template Vivait-Suite GW||{HOSTNAME} Asterisk caido||El asterisk en esa maquina se encuentra caido||Alta||Comprobar que ha arrancado correctamente.
 +
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
 
|-
 
|-
|to_periodo || Timeout para reconectar
+
|Template Vivait-Suite GW||{HOSTNAME} Asterisk PID cambiado||El PID de Asterisk ha cambiado||Alta||Comprobar que ha arrancado correctamente.
 +
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
 
|-
 
|-
|hay_regexp ||
+
|Template Vivait-Suite GW||{HOSTNAME} error en numero de enlaces||Existe un error en el numero de enlaces||Baja||Revisar full de asterisk para comprobar donde está el error.
 +
Revisar sip_WEB.conf
 
|-
 
|-
|num_entradas ||
+
|Template Vivait-Suite GW||{HOSTNAME} error en numero procesos asterisk||Existe un error en el numero de procesos de asterisk||Alta||Comprobar con “ps aux | grep aster” cuantos asterisk aparecen.
 +
Solo tiene que aparecer un safe_asterisk y un asterisk.
 
|-
 
|-
|inc_entradas ||
+
|Template Vivait-Suite GW||Alarma en recordnodo||Alarma en recordnodo||Media||Revisar log (/var/log/record/recordNodo.log).
 +
Actuar en consecuencia.
 
|-
 
|-
|max_entradas ||
+
|Template Vivait-Suite GW||Espacio libre en /var/spool/asterisk/monitor menor del 15%||Espacio libre en /var/spool/asterisk/monitor menor del 15%||Desastre||Revisar log (/var/log/record/recordNodo.log).
 +
Actuar en consecuencia.
 
|-
 
|-
|hay_vic ||
+
|Template Vivait-Suite GW||Espacio libre en /var/spool/asterisk/monitor menor del 40%||Espacio libre en /var/spool/asterisk/monitor menor del 40%||Desastre||Revisar log (/var/log/record/recordNodo.log).
 +
Actuar en consecuencia.
 
|-
 
|-
|puerto_escucha || Puerto de escucha a nivel de VIVAit Call
+
|Template Vivait-Suite GW||Porcentaje de nodos libres en /var/spool/asterisk/monitor menor al 25%||Porcentaje de nodos libres en /var/spool/asterisk/monitor menor al 25%||N/A||Revisar log (/var/log/record/recordNodo.log).
 +
Actuar en consecuencia.
 
|-
 
|-
|identif ||
+
|Template Vivait-Suite GW||Sin datos de grabaciones movidas||Sin datos de grabaciones movidas||Alta||Revisar log (/var/log/record/recordNodo.log).
 +
Actuar en consecuencia
 
|-
 
|-
|entorno || Nombre base de datos
+
|Template Vivait-Suite GW||Sin espacio en dispositivo||Sin espacio en dispositivo||N/A||Revisar log (/var/log/record/recordNodo.log).
 +
Liberar espacio moviendo grabaciones
 
|-
 
|-
|max_conx || Número máximo de conexiones a la base de datos
+
|Template Vivait-Suite Record||recordCentral Gateways en cuarentena|| ||Baja||Revisar log (/var/log/record/recordCentral.log).
 +
Revisar GW afectado (conexión SSH, procesos corriendo, etc.).
 
|-
 
|-
|to_solicitud || Timeout de solicitud
+
|Template Vivait-Suite Record||recordCentral NAS llamadas desconectado|| ||Media||Revisar estado NAS (normalmente NFS montada en /var/lib/recordProcesad/segmRecord)
 
|-
 
|-
|to_desconexion || Timeout de desconexión
+
|Template Vivait-Suite Record||recordCentral NAS segmentos desconectado|| ||Media||Revisar estado NAS (normalmente NFS montada en /var/lib/recordProcesad/segmRecord)
 
|-
 
|-
|ip || Dirección de red de escucha del intz-nimitz
+
|Template Vivait-Suite Record||recordCentral retrasado en exceso|| ||Media||Comprobar con “nc localhost 1114” desde el propio host de cuanto es el retraso.
 +
Monitorizar que se reduce con el paso del tiempo.
 
|-
 
|-
|msk || Mascara de red de escucha del intz-nimitz
+
|}
|-
+
 
|ip || IP localhost
+
 
|-
+
* El template OS Linux tiene asociado el Template App Zabbix Agent.
|msk || mascara localhost
+
Una '''base de datos unificada''' es una base de datos de tiempo real junto a  una base de datos de replica
 +
 
 +
====== Importar templates ======
 +
<br><br>
 +
 
 +
Las plantillas propias de '''md'''tel se encuentran en la ruta "'''/usr/src/nimitz/archivos'''" y empiezan con el nombre de "TemplateXXX.xml".
 +
 
 +
{|
 
|-
 
|-
|hay_mysql || Hay mysql
+
|
|-
+
ls /usr/src/nimitz/archivos | grep Template
|host || IP o HOST maquina base de datos
+
'''Template DRBD.xml'''
|-
+
'''Template motorSal.xml'''
|usuario || Usuario acceso Base de datos
+
'''Templates Vivait-Suite_GW.xml'''
|-
+
'''Templates Vivait-Suite.xml'''
|clave || Clave usuario acceso base de datos
+
'''Template Vivait-Call Asterisk.xml'''
|-
+
'''Template Vivait-Call bdCentral.xml'''
|base_datos||Nombre de la base de datos
+
'''Template Vivait-Call bdNodo.xml'''
|-
+
  '''Template Vivait-Call cambiarPerfil_Cal.xml'''
|to_resp || Timeout de respuesta
+
 
|-
 
|hay_gh1 || Hay intz-gh
 
|-
 
|exten_min_digi || # umbrales para el numero de dígitos de una extensión # sirve para saber si un peer es una extensión o un enlace
 
|-
 
|exten_max_digi ||
 
|-
 
|exten_max || # numero máximo de extensiones soportadas
 
|-
 
|enla_max || # numero máximo de enlaces soportados
 
|-
 
|retro_max || # numero máximo de retrollamadas activas concurrentes. '''Valor por defecto --> 50'''
 
|-
 
|retro_max_b || # numero máximo de retrollamadas activas concurrentes para una extensión como destino (max 31). '''Valor por defecto --> 4'''
 
|-
 
|to_retro_candidato || # tiempo máximo en segs. para activar una retrollamada tras finalizar llamada. '''Valor por defecto --> 60'''
 
|-
 
|to_retro_activo || # tiempo máximo en segs. que una retrollamada espera a que las extensiones estén libres. '''Valor por defecto --> 300'''
 
|-
 
|to_limpiar || # temporizador de limpieza de tablas en segs.
 
|-
 
|hay_ias ||
 
|-
 
|url ||
 
|-
 
|puerto ||
 
|-
 
|to_conx_cmd || # tiempo máximo en segs. para conectar con Asterisk para comandos
 
|-
 
|to_lista_nodos || # periodo en horas para actualizar lista de id de nodos y sus direcciones ip
 
 
|}
 
|}
  
  
 +
La importación se realizara una vez a través de la web, no hace falta desde el servidor Zabbix, puede ser en cualquier  computadora con acceso a la interfaz web de Zabbix.
 +
 +
[[File:ImportarTemplates.png|750px|center]]
  
Para saber si GH funciona correctamente usaremos el comando '''nc localhost 1116''', obteniendo resultados similares a los siguientes:
+
Hay opciones varias opciones a elegir para importación de templates, pero podemos dejar por defecto las señaladas y pulsar el botón "import".
  
* intz-gh sis ver='00.01.00' inic='20181007 081237' alarmas=0 ultAlar='00000000 000000'
+
<br><br>
* intz-gh gmp msj=252/256 buf=256/256 tarea=95/102
+
<div style="
* intz-gh tmp uptime=86503 (1d 0h 1m 43s)
+
  text-align:right;
* intz-gh vic identif='gh_000' entorno='gh' conx=0/4 numConx=2349(7)
+
  margin-top:20px;
* intz-gh regExpr entr=32/32/1024 numRegExpr=0 consul=0(0)
+
  padding:8px;
* intz-gh ias nodos=3 cmd=11(0) cmdErr=0 tresp=0
+
  border:1px solid #ccc;
* intz-gh gh1 exten=9/500 enla=1/20 retro=0/0/50
+
  background-color:#f9f9f9;
* intz-gh gh1 soli=2349(0) soliErr=0(0) soliEncol=0(0)
+
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Monitorización en VIVAit]][[#Monitorización en VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
Los '''log's''' que genera el sistema se encuentran en: /var/log/intz-gh.log
+
==== Configuración para un primer funcionamiento de Zabbix ====
 +
<br><br>
  
===== mdgh.conf y Mdintz.conf =====
+
Se describe una básica configuracion de Zabbix para cualquier equipo que utilice Windows o linux. Pues  mediante la definición de hosts, items, triggers y acciones, Zabbix permite efectuar un monitoreo efectivo de plataformas IT heterogéneas.  
  
Además existen dos ficheros de configuración de Asterisk: /etc/asterisk/'''mdgh.conf''':
+
===== Configuración de los equipost (host) para la monitorización =====
   
+
<br><br>
[servicios]
+
 
retro_hay=yes
+
{|
subscripcion_hay=yes
+
|-
[rest]
+
|
rest_red_ip=172.25.126.21
+
'''Nota''': Tenga en cuenta que debe de estar previamente configurado el agente Zabbix del
rest_red_msk=255.255.255.255
+
  dispositivo a ser monitorizado apuntando a la IP del "Servidor Zabbix".
rest_puerto_escucha=8090
+
|}
retro_exten_tech=SIP
+
Existen dos tipos de host:
retro_contexto=Cen_InicioLlamada_GHRetro
+
* '''Host físico''': donde la dirección de red que registramos en Zabbix, corresponde al dispositivo que deseamos monitorizar.
retro_to_descolgar=30
+
* '''Host virtual''': es una dirección IP virtual, que puede relacionarse con un servidor Web, clusters, etc.
retro_A_cartel_fmt=retro: %s
 
  
Y /etc/asterisk/'''Mdintz.conf'''
 
 
[gh]
 
host0=BDTR
 
port0=5556
 
toConx=5
 
toRx=10
 
  
Los campos de los ficheros y su significado son los siguientes:
+
[[File:CreacionHost.png|750px|center]]
  
{| class="wikitable"
+
Las opciones basicas para configurar un host son las siguientes:
|-
+
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
!Campo!!Descripción
+
! align=center ;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Campos'''''
 +
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
 +
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Valores posibles'''''
 
|-
 
|-
|retro_hay || Si es YES, empleamos la retrollamada '''multinodo''' del '''GH''', si es no, utilizamos la retrollamada de Asterisk
+
| font-weight: bold;" | '''Host Name'''
 +
|  | Definir un nombre para el host.
 +
||Se puede utilizar números, letras, espacios y guiones bajos están permitidos.
 
|-
 
|-
|subscripcion_hay || Si es YES, empleamos los BLFs del '''GH''', si es no, utilizamos los BLFs de Asterisk
+
| font-weight: bold;" | '''Visible Name'''
 +
|  | Identificar con un nombre, la maquina a la que se refiere el host.
 +
||Si no tiene valor, se mostrara como nombre "Host Name".
 
|-
 
|-
|rest_red_ip || '''IP del servidor donde corre el intz-gh'''
+
| font-weight: bold;" | '''Groups'''
|-
+
| | Seleccionar al grupo de host que pertence.Seleccione uno o varios grupos de la caja derecha.
|rest_red_msk || Máscara de red donde corre el intz-gh
+
|| Los valores que puede seleccionar por defecto:
|-
+
Discoverd hosts.
|rest_puerto_escucha || Puerto de escucha a nivel de VIVAit  Call
 
|-
 
|retro_exten_tech || Tecnología empleada en las extensiones
 
|-
 
|retro_contexto || Contexto del GH
 
|-
 
|retro_to_descolgar || timeot retrollamada descolgar
 
|-
 
|retro_A_cartel_fmt || Información aparece en el display si la llamada es una retrollamada
 
|}
 
  
 +
Switches.
  
{| class="wikitable"
+
Templates.
|-
 
!Campo!!Descripción
 
|-
 
|host0 || Base de datos de tiempo real
 
|-
 
|port0 || Puerto de escucha
 
|}
 
  
 +
Templates MDtel.
  
El comando para conocer el estado de los diferentes elementos en Asterisk es:
+
Zabbix servers.
  
'''mdgh show
+
Linux Servers.
Uso: mdgh show [config | exten <exten_num> | enla <peer>]]'''
 
  
Por ejemplo:
+
Hypervisors.
  
'''mdgh show exten 6140'''
+
Virtual machines.
  
:* mdgh Datos de la extension 6140:
+
O crear uno nuevo en '''New group'''.
:* Datos en intz-gh:
 
:* ESTADO=NOT_INUSE
 
:* INUSE=0
 
:* RINGING=0
 
:* TS=1538978766
 
:* HACE=362
 
:* SUBS_NODOS_NUM=1
 
:* Estado en cache local: NOT_INUSE
 
  
'''mdgh show enla Trunk_MDtel'''
+
|-
 +
| font-weight: bold;" | '''Agent interfaces'''
 +
|  |Se recomienda usar una dirección IP, en vez de un nombre de la maquina para resolver por un servidor de DNS que puede fallar.
 +
|  | 10050 por defecto
 +
|}
  
* mdgh Datos del enlace Trunk_MDtel:
+
Cuando termine, haga clic en nel boton "Save".  Su nuevo "Host" debe ser visible en la lista de "Host registrados".Despues el zabbix, intentara configurarse el zabbix para conectarse a la IP.... cada x tiempo hace un barrido.
:* Datos en intz-gh:
 
:* INUSE=0
 
:* RINGING=0
 
:* TS=1538978766
 
:* HACE=461
 
  
  
El fichero de logs es el:
+
====== Comprobación de disponibilidad del host ======
/var/log/intz-gh.log
+
<br><br>
  
 +
Para saber si todo esta bien debemos ver la Z de disponibilidad. 
  
===== Retrollamadas =====
 
  
El funcionamiento será el siguiente:
+
[[File:EstadosZHost.png|750px|center]]
  
*La retrollamada queda programada de extensión física "A" a extensión física "B" (no queda programada a numeraciones de usuarios); esto no quiere decir que no podamos programar una retrollamada cuando hemos llamado a una numeración de usuario, pero queda programada en la extensión física en la que está ese usuario en ese momento.
 
  
*El número llamado "B" podrá ser derivado de varias causas:
+
Indicación de los colores del icono Z:
  
::"A" ha llamado a "B"
+
* Si el icono Z en la columna de disponibilidad es de color rojo, indica que hay un error en la comunicación - mueva el cursor del ratón sobre él para ver el mensaje de error.  
::"A" ha llamado a un usuario ubicado en "B"
 
::"A" ha llamado a un destino desviado a "B"
 
::"A" ha llamado a un destino y por preruta acaba en "B"
 
::...
 
  
*Las causas por las que se podrá programar una retrollamada son:
+
* Si el icono es gris, significa que esta en proceso de comunicación con el "Agente Zabbix". Compruebe que el servidor Zabbix está en marcha, y pruebe a actualizar la página más tarde.  El tiempo estimado para revisar si existe problemas es de 5 minutos.
::"B" está ocupada
 
::"B" no contesta
 
::"B" está ocupada y no contesta (ha sonado en línea 2--> )
 
  
 +
* Si el icono es verde, esta funcionando correctamente.
  
'''Solo podremos programar la retrollamada si el sistema devuelve: extensión ocupada o no contesta'''
+
<br><br>
 
+
<div style="
 
+
  text-align:right;
Estas dos últimas casuísticas son iguales a efectos de usuario, pero no a efectos internos...
+
  margin-top:20px;
 
+
  padding:8px;
Si una llamada va a buzón, salta a un grupo ACD, a una IVR...entonces NO habrá retrollamada (porque se considera contestada)
+
  border:1px solid #ccc;
+
  background-color:#f9f9f9;
*Para programar una retrollamada se pulsa el código de facilidad (*43#) una vez colgada la misma; el sistema recordará la última llamada durante un período de tiempo configurable; aunque entre una llamada en "A", este podrá programar retrollamada a la última saliente si sigue dentro del período
+
  border-radius:6px;
*Se podrá abortar una retrollamada ( (*44#), pero esto no borrará la última llamada (podemos arrepentirnos de haber abortado la retrollamada)
+
  display:inline-block;
*En el gran hermano se guardará Nodo A + Ext_A (numero y name) + Ext_B (numero y name_usuario) + Causa + Timestamp
+
">
*Solo se puede programar una retrollamada y que sea la última
+
[[File:flecha_verde.png|20px|link=#Monitorización en VIVAit]][[#Monitorización en VIVAit | Volver arriba]]
*Si la ultima llamada saliente es, por ejemplo exterior --> No hay posibilidad de programar ninguna retrollamada
+
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
====Indicar que plantilla (template) tendrá el host ====
 +
<br><br>
 +
Esta configuración es opcional.<br>
 +
Tras [[#Importar templates |importar templates]] nos dirigimos al host ya configurado, y en su pestaña de templates pulsamos "add" y añadimos la plantilla/s adecuadas.
  
 +
===== Asignar items al host =====
 +
<br><br>
  
====== <big>Acuerdos de funcionamiento</big> ======
+
{|
 +
|-
 +
|
 +
'''Nota''':Un host puede tener un ITEM sin necesitad de tener template.
 +
|}
  
*Un origen A solo tendrá programa una retrollamada a un destino B; si teniendo una programada decide programar otra, la primera se pierde.
+
Todos lo ITEMS se agrupan por HOST, esto significa que cada HOST tiene sus propios "Módulos que recogen datos del Host".  Para agregar un nuevo módulo vamos a "Configuration → Hosts" y localizamos el "Host" al cual queremos agregarle un nuevo "Item".
  
*Un destino B puede serlo de múltiples orígenes "n" (configurable); cuando B esté disponible para retrollamada, se lanzará una llamada a uno de los orígenes y cuando vuelva a quedar disponible a otro de ellos.
+
[[File:CrearItemEjemplo.png|750px|center]]
  
*Si se trata de programar una "n+1" retrollamada (desde A5) para un destino B, el sistema le informará de que la retrollamada no ha podido programarse (locución a determinar)
+
Parametros o campos a rellenar para una configuración básica :
  
 +
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
 +
! align=center ;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Campos'''''
 +
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
 +
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Valores posibles'''''
 +
|-
 +
| font-weight: bold;" | '''Name'''
 +
|  | Definir un nombre para el item.  Este nombre va a ser nuestro identificador para todas la gestiones en donde lo involucremos como el caso de Triggers.
 +
||
 +
|-
 +
| font-weight: bold;" | '''Type'''
 +
|| Indicar de que entidad queremos recibir informacion.
 +
||Puede ser al "Agente Zabbix" o a el Hardware como impresoras, switch o routers. 
 +
|-
 +
| font-weight: bold;" | '''Key'''
 +
|  | los "Items" utilizan "Key" que son parámetros de Zabbix.  Los "Key" nos permiten indicar específicamente que tipo de información vamos a solicitara a la entidad. Se puede considerar también como el nombre de alguna aplicación.
 +
||
 +
|-
 +
| font-weight: bold;" | '''host interface'''
 +
|  |Es la direccion de red del servidor zabbix (puede ser uno o mas)
 +
|  |
 +
||
 +
|-
 +
| font-weight: bold;" | '''Units'''
 +
|  |Es la dirección de red del servidor zabbix (puede ser uno o mas)
 +
|  |
 +
|-
 +
| font-weight: bold;" | '''Type of information'''
 +
|  |Tipo de unidades con el que mostrar Zabbix el valor segundos, minutos, euros,....
 +
||
 +
|}
 +
 +
Cuando termine, haga clic en Guardar.  El nuevo elemento debe aparecer en la ITEMLIST.
 +
Para mas informacion [[http://entation/1.8/manual/config/items#zabbix_agent. ver documentación Zabbix]]
 +
 +
 +
====== Ver la información recolectada por el item ======
 +
<br><br>
  
  
====== <big>Cuestiones</big> ======
+
{|
 
+
|-
*Se prevé que la retrollamada suene en una extensión desviada; si "A" llama a "B" y esta está desviada en "C", si suena "C" la retrollamada que programo.
+
|
 
+
<small>'''Nota:''' Normalmente para ver la información lo encontraremos en "Monitoring → Latest data",luego
*Si salta al buzón no puede haber retrollamada.
+
clic en el signo "+" en "other" siempre que no pertenezca a una aplicación.  
 
+
  En caso contrario, estará bajo el nombre de la aplicación.</small>
==== GeneraConf ====
+
|}
 
 
El GeneraConf es el webservice (war) que se utiliza en la plataforma '''''<span style="color:#144F9B">VIVA</span>'''''it para generar ficheros de configuración a partir de las modificaciones realizadas por el usuario en las tablas de la Base de Datos del sistema à es un intermediario entre los portales y Asterisk.
 
 
 
Es importante tener en cuenta que el proceso convierte tablas de Base de Datos en ficheros de configuración, pero NO genera Dialplan ni sincroniza locuciones.  
 
 
 
El GeneraConf se instala en el mismo servidor que el Tomcat, normalmente con el portal de administración.
 
 
 
GeneraConf lee de la tabla Dat_Sincroniza, genera los ficheros de configuración y los coloca en su sitio.
 
 
 
===== Fichero de configuración =====
 
  
GeneraConf es un proceso que no incorpora fichero de configuración. El proceso es llamado por los portales del entorno '''''<span style="color:#144F9B">VIVA</span>'''''it (portal de administración y portal de alertas) siendo los propios portales los que han de incluir los parámetros necesarios.
+
Después de definir el "Item" vamos a revisar la información que esta recolectando. .  La información comenzará a ser recolectada según el tiempo que le indicamos en el "Item".
  
En el portal de administración de '''''<span style="color:#144F9B">VIVA</span>'''''it Call tenemos que configurar la url para poder sincronizar los cambios realizados utilizando el proceso:
+
[[File:VerInfoITEM.png|750px|center]]
  
 +
La espera para recibir la información varía dependiendo del tiempo de recolección del item, la mayoría suele ser aproximadamente al minuto de generar el "Item". Zabbix le ofrece la opción de visualizar la información en forma gráfica (sencilla).  En el "Item" en lista haga clic en la columna "History - Graph".
  
[[File:URL de sincronizacion.jpg]]
+
[[File:VIsualGraficaValorItem.png|center|750px]]
 +
Si en un caso usted no observa información le recomendamos:
 +
 
 +
* Ingrese al "Item" y revise que la información del "Key" este igual al ejemplo "system.cpu.load"
 +
* Verifique que el agente este funcionando en el "Servidor a ser monitoreado" y que "El Servidor recolector Zabbix" este funcionando.
 +
* El icono "Z" en el host debe estar en color verde.
 +
* Asegure que esta monitoreando el servidor que le agregó este "Item"
  
 +
===== Configurar los Triggers para los host =====
 +
<br><br>
  
 +
A partir de la información que captura los agentes , el servidor de Zabbix comienza a efectuar la recolección de estos items en la base de datos. Con esto se tiene un registro histórico de tales mediciones, que pueden ser tan simples como un simple ping hasta datos de uso de disco, memoria, cpu, etc.
 +
A partir de los datos que se reciben de los agentes lo que sigue es definir y configurar Triggers, que son evaluaciones que hace Zabix de estos datos para determinar la existencia de un Problema en un dispositivo.
 +
{|
 +
|-
 +
|
 +
Nota: Un trigger necesita una accion, que indica que hacer cuando se activa el trigger.
 +
|}
  
GeneraConf incluye el parámetro '''AlcanceSincroniza''' que se utiliza para distinguir el portal que deseamos sincronizar. Los portales (administración y alertas) deberán incluir este parámetro cuando llamen al generaConf:
 
  
*Si no se indica o se indica con valor 10 (alcanceSincroniza=10) se sincroniza el entorno '''''<span style="color:#144F9B">VIVA</span>'''''it Call, excluyendo el entorno de alertas.
+
Un trigger(disparador) es un tipo de reacción ante unas medidas, como un disparador en el que si pasa algo se activa. Los Trigger en Zabbix son módulos que creamos a uno o múltiples "Items" para evaluar o comparar los valores recolectados por los "Items" con condiciones que nosotros definamos. Las condiciones son de tipo aritmético y lógico.
*Si se indica con valor 20 (alcanceSincroniza=20), se sincroniza solo el entorno de Alertas.
 
  
A tal efecto se ha creado el siguiente enumerado:
+
Para configurar un "Trigger o Disparador" seleccionamos "Configuration → Hosts" localizamos el "Host" de ejemplo que creamos y luego hacemos clic en "Trigger", después haga clic en "Create Trigger".
  
public enum TAlcanceSincroniza  {
+
Parametros o campos a rellenar para una configuración básica :
        ALCANCESSINC_VIVAITCALL("10"),
 
        ALCANCESSINC_ALERTAS("20");
 
       
 
        private TAlcanceSincroniza(String text) {
 
            this.text = text;
 
        }  
 
        private final String text;  
 
        @Override
 
        public String toString() {
 
            return text;
 
        }
 
    }
 
  
 +
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
 +
! align=center ;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Campos'''''
 +
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
 +
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Valores posibles'''''
 +
|-
 +
| font-weight: bold;" | '''Name'''
 +
|  | Definir un nombre para el trigger.  Este nombre va a ser nuestro identificador para todas la gestiones en donde lo involucremos como el caso de los eventos.
 +
||
 +
|-
 +
| font-weight: bold;" | '''Expression'''
 +
||  Hay que indicar para que medida se crea (item) y sus funciones con los parametros adecuados. '''''Recomendación usar expression constructor que pedirá siempre al crearlo, para que item es y sus funciones...'''''
 +
||Ejemplo: {New host:system.cpu.load.avg(180)}>2
 +
|-
 +
| font-weight: bold;" | '''Key'''
 +
|  | los "Items" utilizan "Key" que son parámetros de Zabbix.  Los "Key" nos permiten indicar específicamente que tipo de información vamos a solicitara a la entidad. Se puede considerar tambien como el nombre de alguna aplicacion.
 +
||
 +
|-
 +
| font-weight: bold;" | '''Descripción'''
 +
|  | Una descripción breve sobre el trigger.
 +
||
 +
|-
 +
| font-weight: bold;" | '''Severity'''
 +
|  | everidad distinguida por colores,
 +
|| No classified
 +
Information
 +
Warning
 +
Average
 +
High
 +
Disaster
 +
|}
  
Existe un fichero, '''generaConf.properties''', que permite simular la creación de ficheros de configuración con los cambios que hayamos realizado en el portal. Los ficheros de configuración creados en modo simulación se crear en una ruta distinta a la habitual, por lo que no sobrescriben los ficheros de configuración que se están utilizando.
 
  
Nuevo fichero /etc/MDtel/generaConf.properties :
 
  
root@Homologacion-Corp1:~# cat /etc/MDtel/generaConf.properties
+
====== Comprobar el estado del trigger ======
+
<br><br>
simular=0
 
simDirMDtel=/tmp/MDtel
 
simDirAsterisk=/tmp/Asterisk
 
deshabExten=0
 
deshabCola=0
 
deshabBuzones=0
 
deshabCti=0
 
deshabRecGwd=1
 
deshabRecNodo=0
 
deshabRecProc=1
 
deshabRecCen=0
 
deshabMDcal=0
 
deshabArchAsterisk=0
 
deshabVoces=0
 
deshabEnInt=0
 
deshabEnExt=0
 
deshabMoh=0
 
deshabGrupos=0
 
deshabVdn=0
 
  
El valor 1 indica que GeneraConf simula el fichero asociado, cuando el valor es “0” no se genera la simulación.
+
Podemos ver el estado del "Trigger" en "Monitoring → Triggers".El color en caso de que se active depende de la severidad definida. Por ejemplo,  si el "Trigger" esta en color verde indica que el resultado de la métrica se mantiene por debajo de la condición que indicamos.  Por el contrario si el resultado esta "sobre lo indicado" su color sera rojo.
  
El proceso GeneraConf permite subir tanto locuciones como MOH desde el portal. Cuando subimos las locuciones a través del portal el GeneraConf se encarga de copiar las locuciones a un directorio temporal, posteriormente las colocará en los directorios definitivos correspondientes.
+
[[File:EstadoTrigger.png|center|750px]]
  
===== Ficheros de logs =====
+
===== Asociar un Action al trigger =====
 +
<br><br>
  
El fichero con los log’s generado se encuentra en /var/log/Tomcat.x/generaConf.log.
+
Una action(acción) sirve para configurar un mensaje de alerta o una accion para Zabbix, ante un problema. Hay varias formas de gestionar un problema a través de una acción:
  
 +
# A través de mensajes simples, alertando al instante.
 +
# Escalar los mensajes hacia el jefe y/o otros grupos.
 +
# Ejecución de commandos remotos.
 +
# Notificaciones repetidas hasta que se resuelve el problema.
 +
# Notificaciones y comandos retardados.
 +
# Escenario complejo, la combinación de todo lo anterior.
  
 +
Para crear una configuración en "Configuration-Actions". La explicación esta en la [[ https://www.zabbix.com/documentation/2.0/manual/config/notifications/action documentación de Zabbix]].
 +
-->
  
==== Nodo WebRTC ====
+
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Monitorización en VIVAit]][[#Monitorización en VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
Se adjunta la documentación del nodo WebRTC:
+
== Funcionalidades específicas en '''''VIVA'''it'' ==
 +
<br><br>
 +
En este apartado se tratará de las funcionalidades especificas de que dispone el sistema '''''VIVA'''it''.<br>
 +
Este apartado contiene las siguientes funcionalidades:
 +
<br><br>
 +
: • [[#Mecanismo de prioridad adaptativa|'''Mecanismo de prioridad adaptativa''']], asignación de llamadas en colas modulada por tiempo de espera.<br>
  
  
<big>'''[[:medio:DOCUMENTO_WEBRTC_v9.pdf| Manual de instalación y operación del nodo WebRTC ]]'''</big>
 
  
 +
<br><br>
  
La arquitectura de WebRTC en VIVAit Call es la  siguiente:
 
  
  
 +
=== Mecanismo de prioridad adaptativa ===
  
 +
El mecanismo de prioridad adaptativa permite en una plataforma '''''VIVA'''''it 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
  
 +
==== Introducción ====
  
[[File:webrtc.png|900px|center]]
+
Este documento presenta una propuesta de mecanismo de asignación de llamadas en colas a agentes basado no solo en las prioridades de agente a cola,
 +
sino en un factor de corrección de prioridad derivado del tiempo de espera de una llamada
  
 +
==== Terminología ====
  
 +
* '''Prioridad de llamada:''' A cada llamada susceptible de ser atendida en el ''Call Center'' se le asignará una prioridad de llamada; dicha prioridad será asignada cada vez que un agente quede disponible.
 +
* '''Prioridad de grupo ACD:''' Los agentes del ''Call Center'' tendrán configurada una prioridad para cada grupo ACD al que pertenecen
 +
* '''Tiempo de espera:''' Tiempo que una llamada lleva en espera en un determinado grupo ACD; si la llamada cambia de un grupo ACD a otro el tiempo de espera pasa a cero
 +
* '''Objetivo de servicio:''' Tiempo objetivo máximo de espera por cada grupo ACD
  
 +
'''Nota.-''' ''En terminología Asterisk el aumento de prioridad corresponde con números descendentes, es decir,<br />
 +
prioridad 50 es mejor que prioridad 70''
  
Componentes Principales:
+
==== Mecanismo de asignación de llamadas ====
 +
 
 +
En el momento en que exista un agente disponible para recibir llamada, el agente recepcionará la llamada con mejor prioridad de llamada (menor número). La prioridad de llamada para cada llamada se establecerá de la siguiente manera:
 +
 
 +
- Agentes con prioridad de grupo ACD de 1 a 99 utilizarán el mecanismo convencional de asterisk de prioridad absoluta; será útil para grupos ACD críticos o en Call Centers muy convencionales
 +
 
 +
'''Si un agente tiene prioridad menor de 100 en grupos ACD y hay llamadas en dichos grupos, estas llamadas serán atendidas por el agente con prioridad absoluta.'''
 +
 
 +
- Agentes con prioridad de colas de 100 en adelante; se utilizará el siguiente mecanismo de prioridad ponderada:
 +
 
 +
:*Si el grupo ACD de la llamada está dentro del objetivo de servicio, la prioridad de llamada será la prioridad de grupo ACD (a efectos prácticos se aplicará el mecanismo convencional de asignación de llamada a agente, equitativo entre grupos ACD con misma prioridad)
  
 +
:*Si el grupo ACD de la llamada está fuera del objetivo de servicio, se aplicará una ponderación que mejorará la prioridad de la llamada a medida que aumente el tiempo de espera:
  
 +
[[Archivo:Formula.png |center]]
  
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
+
En una configuración de igualdad de prioridad de agente y objetivo de servicio, el tiempo de espera influiría de manera determinante (más o menos en
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Componentes  '''''
+
función del peso) en la asignación de la siguiente llamada
! align=center style="background-color:#0099ff;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
+
El peso podrá adquirir tres posibles valores: 0, 1 y 10
|-
 
| font-weight: bold;" | '''APACHE'''
 
|  | Apache es un servidor web HTTP de código abierto.La funcionalidad principal de este servicio web es servir a los usuarios todos los ficheros necesarios para visualizar la web. Las solicitudes de los usuarios se hacen normalmente mediante un navegador (Chrome, Firefox, Safari, etc.).
 
|-
 
| font-weight: bold;" | '''SERCEN'''
 
|  | Sirve para identificar a los usuarios y garantizar que los mismos sean quienes dicen ser.
 
|-
 
| font-weight: bold;" | '''JANUS'''
 
|  | Janus es un servidor WebRTC concebido para ser de propósito general. Como tal, no proporciona ninguna funcionalidad más que implementar los medios para configurar una comunicación de medios WebRTC con un navegador, intercambiar mensajes JSON con él y transmitir RTP / RTCP y mensajes entre navegadores y la lógica de la aplicación del lado del servidor a los que están apegados.
 
|-
 
| font-weight: bold;" | '''IPTABLES'''
 
|  | Es un programa  que se encarga de filtrar los paquetes de red , es decir , es la parte que se encarga de determinar qué paquetes de datos queremos que lleguen hasta el servidor y cuáles no.
 
|-
 
| font-weight: bold;" | '''FAIL2BAN'''
 
|  | Es una aplicación de Linux que permite evitar accesos no autorizados al servidor. Funciona bloqueando o baneando  las IP que realicen varios intentos de acceso incorrectos al servidor.
 
|-
 
| font-weight: bold;" | '''CLIENTE'''
 
|  |      El cliente debe de proporcionar una ip pública , un dns para esa ip y un certificado válido.
 
  
|}
+
[[Archivo:Esquema.png |center]]
  
 +
  <span style="color:#000080">- Calculo prioridad de llamada: se calcula por llamada cada vez que un agente queda libre</span>
 +
  <span style="color:#000080">- Agente atiende llamada con mejor prioridad de llamada</span>
  
  
 +
<!--
 +
[[Medio:Asignación de llamadas por prioridad adaptativa.pdf|Asignación de llamadas por prioridad adaptativa]]-->
  
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
 +
=== 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.
  
=== Requerimientos de conectividad ===
 
  
El esquema siguiente muestra como ejemplo todos los flujos de información existentes en un entorno típico de <big>'''telefonía corporativa (sin presencia)'''</big> ('''''VIVA'''''it Call)
+
====Esquema de funcionamiento====
 +
[[Archivo:esquema funcionamiento marcador.jpg|center|500px]]
  
[[Archivo:Flujos corporativa.png|cebter]]
+
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.
  
En el entorno de <big>'''Contact Center'''</big>, encontramos los siguientes flujos <big>'''entre servicios'''</big> (comunicaciones entre servidores, ('''''VIVA'''''it Suite))  
+
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.
  
[[Archivo:Flujos Contact servicios.png|650px|center]]
+
====Flujo de estados====
  
y <big>'''entre usuarios y servicios'''</big> los reflejados a continuación:
+
El flujo de estados es el reflejado en la figura siguiente:
  
[[Archivo:Flujos Contact puestos.png|600px|center]]
+
[[Archivo:diagrama de flujo motorsal.png|center|800px]]
  
{| class="wikitable"
+
Los diferentes estados de un contacto son:
 +
{| class="wikitable sortable"
 
|-
 
|-
!Lado A!!Lado B!!Puertos!!Sentido!!Observ.
+
! Estado !! ID_Estado!! Descripción
 
|-
 
|-
|Terminal telefónico||Servidor||TCP 5060||A -> B||Señalización SIP
+
| 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
 
|-
 
|-
|Terminal telefónico||Servidor||UDP 5060||A -> B||Señalización SIP
+
|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.
 
|-
 
|-
|Terminal telefónico||Servidor||10000 a 20000||A -> B
+
|Intento||20||El control pasa a myAcdSuperv, que a su vez genera la llamada en Asterisk. Cuando termina, se pasa a Planificable o Finalizado.
B -> A
 
||RTP
 
 
|-
 
|-
|Terminal telefónico||Servidor TFTP||UDP 69||A -> B
+
|Finalizado||100||Las gestiones con este contacto han terminado.
B -> A
 
||Para actualización de terminales por TFTP
 
 
|-
 
|-
|Terminal telefónico||Servidor NTP||UDP 123||A -> B||
+
|Abortado||110||
 
|-
 
|-
|'''''VIVA'''''it Desk||Servidor||TCP 4500||A -> B||Comunicación CTI
+
|Obsoleto||200||Se ha agotado el tiempo para contactar sin agotar todos los intentos. No se le vuelve a llamar nunca.
 
|-
 
|-
|'''''VIVA'''''it Desk||Servidor||TCP 3306||A -> B||Acceso a Mysql Base de datos
+
|Cancelado||300||
|-
 
|'''''VIVA'''''it Desk||Servidor Syslog||UDP 514||A -> B||Para envio de logs de agente
 
|-
 
|'''''VIVA'''''it Supervisor||Servidor||TCP 3306||A -> B||Acceso a Mysql Base de datos
 
|-
 
|'''''VIVA'''''it Tracker||Servidor||TCP 3306||A -> B||Acceso a Mysql Base de datos
 
|-
 
|'''''VIVA'''''it 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 '''''VIVA'''''it Suite
 
|-
 
|'''''VIVA'''''it 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)
 
 
|-
 
|-
 
|}
 
|}
  
<br><br>
+
====Carga de contactos====
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Gateways ===
+
===== Descripción =====
El concepto de gateway como tal no existe en la plataforma '''''VIVA'''''it; 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
+
A continuación se explica la configuración y funcionamiento de la utilidad encargada de asignar contactos a campañas.
  
El concepto gateway queda pues suscrito a entornos meramente comerciales
+
===== Configuración =====
  
Incluimos no obstante en este apartado los diagnósticos y operaciones básicos de conexiones a sistemas externos o RTC
+
El archivo de configuración recibe el nombre de '''cargaContactos.pconf.''' Este archivo reside en '''/etc/MDtel.''' El formato se describe en la tabla siguiente. Hay que tener en cuenta que las columnas empiezan a numerarse en 0.
  
Para verificar los enlaces establecidos ejecutamos el siguiente comando en el terminal: '''sip show peers'''
+
{| class="wikitable" style="text-align:center;"
 
+
|-
Al ejecutar este comando obtenemos la salida:
+
! Parámetro !! Valor !! Obligatorio !! Defecto
 
+
|-
[[Archivo:Enlace_Exterior.png |center]]
+
| db|| Nombre de la base de datos|| SI || nimitz
 
+
|-
Las columnas ''Host'' y ''Port'' nos muestran las conexiones establecidas y nos informa de un posible problema de conexión.
+
| dbHost|| Host MySQL || SI || localhost
 
+
|-
Sabremos que ''no existe conexión'' cuando la columna Host tiene el valor '''Unspecified''' y en la columna Port aparece un '''0''' , a continuación se muestra un ejemplo:
+
| dbPort|| Puerto MySQL || NO || 3306
 
+
|-
 
+
| dbUsuario || Usuario de acceso a la base de datos|| SI ||
[[Archivo:Ejemplo_no_conexion.png |center]]
+
|-
 
+
| dbClave || Clave del usuario || SI ||
<!--
+
|-
<span style="background:#00FF00">FALTA AQUI DIAGNOSTICOS Y OPERACIONES DE ENLACES EXTERNOS</span>
+
| rutaContactos || Ruta hasta el archivo de contactos || NO || /var/spool/MDtel/contactos
-->
+
|-
 
+
| obsoletos || Si vale 1, marcar como obsoletos los contactos anteriores || NO || 0
===  Servidor de grabación ===
+
|-
==== Almacenamiento en la nube ====
+
| diasCaducidad || Número de dias a partir de los cuales caducarán los contactos || SI ||
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:
+
| idCampanna || Número de columna que contiene el ID de la campaña || SI||
 
+
|-
*$db: Nombre de la base de datos.
+
| idLista || Numero de columna que contiene el ID de la lista || SI ||
*$dbHost: servidor de MySQL
+
|-
*$dbPort: Puerto del MySQL.
+
| prioridad || Número de columna que contiene la prioridad || NO || Nota: El valor es de 0 a 99. A mayor número mayor prioridad (se le llamará '''ANTES''')
*$dbUsuario: Usuario de conexión a MySQL.
+
|-
*$dbClave: Clave del usuario anterior.
+
| tipoTarea|| Número de columna que contiene el tipo de tarea || NO || Nota: los posibles valores de la columna son : <br /> *A: Alta <br /> *M: Modificación <br /> *B: Baja<br /> Por defecto el valor es A
*$dirBase: Directorio donde residen las grabaciones
+
|-
*$diasCaducidad: Dias de antigüedad para mover las grabaciones
+
| codCli || Número de columna del CSV que contiene el código de cliente || SI ||
*$sftpHost: Servidor SFTP de destino
+
|-  
*$sftpPort: Puerto SFTP.
+
| nombreCon || Número de columna del CSV que contiene el nombre || NO ||
*$sftpUsuario: Usuario SFTP.
+
|-  
*$sftpClave: Clave del usuario SFTP.
+
| apellido1 || Número de columna del CSV que contiene el primer apellido|| NO ||
*$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.
+
|-
 
+
| apellido2 || Número de columna del CSV que contiene el segundo apellido || NO ||
La grabación indica donde se encuentra mediante el campo E_UBICACION_GRABACION, que puede tener los siguientes valores:
+
|-
*Sin definir (0)
+
| empresa || Número de columna del CSV que contiene la empresa || NO ||
*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.
+
| direccion1 || Número de columna del CSV que contiene la dirección || NO ||
 
+
|-
<br><br>
+
| direccion2 || Número de columna del CSV que contiene la dirección 2 || NO ||
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
+
|-
<br><br>
+
| codPostal || Número de columna del CSV que contiene el código postal || NO ||
 
+
|-
=== Reporting ===
+
| localidad || Número de columna del CSV que contiene la localidad || NO ||
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 '''''VIVA'''''it Reporting”.
+
| provin || Número de columna del CSV que contiene la provincia || NO ||
 
+
|-
==== Formato de fichero de intercambio para '''''VIVA'''''it Reporting ====
+
| email || Número de columna del CSV que contiene el email || NO ||
{| class="wikitable"
+
|-
|-
+
| valFijo_1 || Número de columna del CSV que contiene el primer número fijo del contacto || SI ||
! Nombre !! Descripción !! Ejemplo
+
|-
 +
| valFijo_2 || Número de columna del CSV que contiene el segundo número fijo del contacto || NO ||
 +
|-
 +
| valFijo_3 || Número de columna del CSV que contiene el tercer número fijo del contacto || NO ||
 +
|-
 +
| valFijo_4 || Número de columna del CSV que contiene el cuarto número fijo del contacto || NO ||
 +
|-
 +
| valMovil_1 || Número de columna del CSV que contiene el primer número móvil del contacto || SI ||
 +
|-
 +
| valMovil_2 || Número de columna del CSV que contiene el segundo número móvil del contacto || NO ||
 +
|-
 +
| valMovil_3 || Número de columna del CSV que contiene el tercer número móvil del contacto || NO ||
 +
|-
 +
| valMovil_4 || Número de columna del CSV que contiene el CUARTO número móvil del contacto || NO ||
 +
|-
 +
| edad || Número de columna del CSV que contiene la edad || NO ||
 +
|-
 +
| nOpc1|| Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-
 +
| nOpc2 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-
 +
| nOpc3 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-
 +
| nOpc4 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-
 +
| nOpc5 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-  
 +
| nOpc6 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-
 +
| nOpc7 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-
 +
| nOpc8 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 +
|-
 +
| cOpc1 || Número de columna del CSV que contiene cadena opcional || NO ||
 +
|-
 +
| cOpc2 || Número de columna del CSV que contiene cadena opcional || NO ||
 +
|-
 +
| cOpc3 || Número de columna del CSV que contiene cadena opcional || NO ||
 +
|-
 +
| cOpc4 || Número de columna del CSV que contiene cadena opcional || NO ||
 +
|-
 +
| cOpc5 || Número de columna del CSV que contiene cadena opcional || NO ||
 +
|-
 +
| cOpc6 || Número de columna del CSV que contiene cadena opcional || NO ||
 +
|-
 +
| cOpc7 || Número de columna del CSV que contiene cadena opcional || NO ||
 +
|-  
 +
| cOpc8 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
|-
| colspan="3"| Selección de registros
+
| Idioma || Idioma del contacto || NO ||
 
|-
 
|-
| 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
+
===== Funcionamiento =====
|| Skill igual a 60310
+
 
|-
+
Para ejecutar la utilidad se debe teclear la siguiente orden en la línea de comandos:
| 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
+
 
|-
+
'''cmd# cargaContactos.pl /<ruta hasta el conf>/cargaContactos.pconf <archivo CSV>'''
| colspan="3"|  Salida
+
 
|-
+
El archivo con los contactos deberá ser un CSV con los campos separados por ';'. La utilidad parsea el archivo conforme a la distribución indicada en la configuración y crea las correspondientes entradas en las tablas '''ACD_CONTACTOS''' y '''ACD_CONTACTOS_CAMPANNAS.'''
| 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\
 
|-
 
| colspan="3"|  Plantilla
 
|-
 
| INF_modelo || Ruta del fichero de plantilla || C:\Modelos\llamadas.rep
 
|-
 
| INF_descripción || Descripción del informe || Informe detallado de llamadas
 
|-
 
| colspan="3"|  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 ||
 
|-
 
| colspan="3"|  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 ||
 
|}
 
  
 +
La utilidad crea un log en '''/var/log/cargaContactos.log''' en el que vuelca toda la operativa.
 +
Por pantalla se va mostrando un lista con el ID asignado al contacto y el ID de campaña al que se le ha asignado.
  
El fichero tendrá un nombre único para permitir la generación simultánea de informes.
+
Un ejemplo de fichero de carga de contactos sería el siguiente:  
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:
+
#
{| class="wikitable"
+
# Configuracion de cargaContactos.pconf
|-
+
#
| SQL_selec=(DAT_ACUMULADOS_COLAS.ID_COLA in (11))
+
# Conexion de base de datos
 
+
$db='nimitz';
SQL_select_leido=Skill igual a 60310
+
$dbHost = 'localhost';
 
+
$dbPort = '3306';
SQL_orden=
+
$dbUsuario = 'nimitz';
FIC_extension=pdf
+
$dbClave = 'LA QUE SEA';
 
+
$diasCaducidad='300';
FIC_tipo_entrega=P
+
$rutaGrab = '/var/spool/MDtel/contactos';
 +
$idCampanna = '31';
 +
$idLista = '32';
 +
$obsoletos = 0;
 +
$codCli = '1';
 +
$nombreCon = '2';
 +
$apellido1 = '3';
 +
$apellido2 = '4';
 +
$empresa = '5';
 +
$direccion1 = '6';
 +
$direccion2 = '7';
 +
$codPostal = '8';
 +
$localidad = '9';
 +
$provin = '10';
 +
$email = '11';
 +
$valFijo_1 = '12';
 +
$valFijo_2 = '13';
 +
$valFijo_3 = '14';
 +
$valFijo_4 = '15';
 +
$valMovil_1 = '16';
 +
$valMovil_2 = '17';
 +
$valMovil_3 = '18';
 +
$valMovil_4 = '19';
 +
$edad = '20';
 +
$nOpc1 = '21';
 +
$nOpc2 = '22';
 +
$nOpc3 = '23';
 +
$nOpc4 = '24';
 +
$cOpc1 = '25';
 +
$cOpc2 = '26';
 +
$cOpc3 = '27';
 +
$cOpc4 = '28';
 +
$prioridad = '29';
 +
$tipoTarea = '30';
  
FIC_destino=C:\
+
====Comportamiento de reprogramaciones de llamadas en función del estado del agente====
  
INF_modelo=skill_setsi.rep
+
Se ha preparado la siguiente maqueta:
  
INF_descripcion=Skill. SETSI
+
Campaña saliente.
 +
Cola saliente progresiva.
 +
Dos agentes logados en VIVAit Suite.
  
BD_ip=172.25.1.2
+
En el formulario de la llamada se indica: llamada redirigida
 +
Se selecciona el "check dirigida"
  
BD_puerto=3306
+
Las posibilidades de prueba son dos: "'''Cualquier agente'''" y "'''Solo agente'''"
  
BD_base_datos=nimitz
+
Resultados son los siguientes:
  
BD_usuario=nimitz
+
{| class="wikitable sortable"
 
+
|-
BD_clave=UIk5jNY9PVX5ogg=
+
| '''Estado del agente''' || '''Modo Cualquier Agente'''|| '''Modo Solo Agente'''
 
+
|-
PAR_desde_vis=-
+
| '''Agente Preparado''' || Entra llamada a agente|| Entra llamada a agente
 
+
|-
PAR_hasta_vis=-
+
|'''Agente en Pausa'''||Entra llamada a otro agente disponible||Espera a agente y entra llamada.
 
+
|-
PAR_01=
+
|'''Agente Hablando'''||Espera a agente y entra llamada||Espera a agente y entra llamada.
 +
|-
 +
|'''Agente en Tiempo administrativo'''||Espera a agente y entra llamada||Espera a agente y entra llamada.
 +
|-
 +
|'''Agente no logado'''||Entra llamada a otro agenete disponible||Consume intento.
 +
|-
 +
|'''Agente con una pestaña de chat abierta y el otro agente en pausa'''||Entra llamada a otro agente disponible||Espera a agente y entra llamada.
 +
|-
 +
|'''Agente con dos pestañas de chat abiertas'''||Espera a agente y entra llamada||Espera a agente y entra llamada.
 +
|-
 
|}
 
|}
  
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
 +
 +
=== Movilidad ===
 +
La movilidad es una función integral de las comunicaciones en la empresa. Cualquier empleado (usuario) es móvil en cierto grado, ya 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 estemos.
  
==== Resumen de significado de columnas en reporting histórico ====
+
==== Ofrecer movilidad a un usuario ====
Esta información se puede consultar en el siguiente enlace:
+
<!--parte daniel-->
 +
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 ''VIVA''it'''.  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 [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Documentaci%C3%B3n_de_usuario_VIVAit_Call_3.0#Portal_de_usuario |portal de usuario]]). <br/>Para más información[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Pesta.C3.B1a_Centralita | 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 ''VIVA''it'''.<br/>Para más información[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Asignaci.C3.B3n_de_Permisos_de_Usuario_por_Administrador | ver sección  Portal de administración - General - Usuarios - Permisos a usuarios]]
  
http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Documentacion_de_usuario_VIVAit_Suite_3.3#Resumen_del_valor_de_las_columnas_que_aparecen_en_los_informes
 
  
<!--
+
'''La movilidad permite''' disponer de las extensiones telefónicas empresariales en cualquier lugar. Por
===== Agente,asistencia diaria y agente. Asistencia diaria del grupo =====
+
ejemplo, con un ordenador portátil o smartphone en una ubicación remota con conexión a Internet,
 +
podríamos tener registrada nuestra extensión remotamente, y así las llamadas hacia/desde nuestra
 +
oficina serían enrutadas por Internet hasta el equipo en cuestión sin coste alguno.
  
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
 
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
 
o realizadas por el agente excluido el tiempo de retención.<br/>
 
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
 
tras finalizar las llamadas contestadas por el agente.<br/>
 
'''• Tiempo de llamado:''' Tiempo de ring en llamadas ACD.<br/>
 
'''• Tiempo disponible:''' Tiempo que el agente estuvo conectado y no está
 
incluido en ninguno de los anteriores.<br/>
 
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa<br/>
 
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas por
 
el agente.<br/>
 
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
 
el agente.<br/>
 
'''• Llamadas transferidas:''' Número de llamadas ACD que fueron
 
transferidas por el agente.
 
  
===== Agente. Aux y Grupo Aux =====
+
<!--parte daniel-->
 +
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 ''VIVA''it'''. Para más información [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Extensiones | ver sección Portal de administración - VIVAit Call - Dispositivos - Extensiones]]
  
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
+
==== ¿Cómo funcionan las extensiones? ====
el agente.<br/>
 
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
 
o realizadas por el agente excluido el tiempo de retención.<br/>
 
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
 
tras finalizar las llamadas contestadas por el agente.<br/>
 
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
 
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas por
 
el agente.<br/>
 
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa.<br/>
 
'''• Desglose de tiempos AUX:''' Tiempo que el agente estuvo en cada uno
 
de los motivos de pausa.
 
  
===== Agente. Resumen diario =====
+
Primeramente el usuario debe tener los ejes apropiados en la tabla '''COM_USUARIOS_APLICACION''' (aplicación centralita).
  
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
+
La extensión debe de tener ''un teléfono'' y por tanto ''un modelo de teléfono asociado.''
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
+
 
o realizadas por el agente excluido el tiempo de retención.<br/>
+
Es tan simple como especificar '''la extensión, el usuario y la clave de este.'''
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
+
 
tras finalizar las llamadas contestadas por el agente.<br/>
+
Para corroborar el funcionamiento de esta hay ''dos métodos'':
'''• Tiempo de llamado:''' Tiempo de ring en llamadas ACD.<br/>
 
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa.<br/>
 
'''• Tiempo disponible:''' Tiempo que el agente estuvo conectado y no está
 
incluido en ninguno de los anteriores.<br/>
 
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas.<br/>
 
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
 
el agente.<br/>
 
'''• Llamadas entrada Ext:''' Número de llamadas entrantes NO ACD a la
 
extensión.<br/>
 
'''• Llamadas salida Ext:''' Número de llamadas salientes NO ACD desde la
 
extensión.<br/>
 
'''• Llamadas transferidas:''' Número de llamadas ACD que fueron
 
transferidas por el agente.<br/>
 
'''• Llamadas retenidas:''' Número de retenciones que sufrieron las
 
llamadas contestadas por el agente.<br/>
 
'''• Tiempo promedio ACD:''' Tiempo ACD/ Llamadas ACD.<br/>
 
'''• Tiempo promedio ACW:''' TiempoACW/Llamadas ACD.<br/>
 
'''• Tiempo promedio de entrada a la Ext:''' Tiempo entrada Ext/
 
Llamadas entrada Ext.<br/>
 
'''• Tiempo promedio de salida a la Ext:''' Tiempo salida Ext/ Llamadas
 
salida Ext.<br/>
 
'''• Tiempo promedio retención:''' Tiempo retención/Llamadas retenidas.<br/>
 
'''• % Ocupación con ACW:''' ((Tiempo ACD+ Tiempo retención+ Tiempo
 
ACW)/Tiempo con personal)* 100.<br/>
 
'''• % Ocupación sin ACW:''' ((Tiempo ACD+ Tiempo retención)/Tiempo
 
con personal)* 100.<br/>
 
'''• % disp.:''' (Tiempo disponible/Tiempo conectado)* 100.
 
  
===== Agente. Grupo ACD diario =====
+
'''* CLI asterisk:'''
  
 +
'''mdintz qry * nimitz bd extenEntraUsuarioMovil 25001 20001 1234'''
  
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
+
Y como resultado obtenemos lo siguiente:
el agente de un grupo ACD.<br/>
 
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
 
o realizadas por el agente excluido el tiempo de retención de un grupo
 
ACD.<br/>
 
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
 
tras finalizar las llamadas contestadas por el agente de un grupo ACD.<br/>
 
'''• Ayuda:''' Número de llamadas contestadas por el agente que necesitaron
 
de consulta de un grupo ACD.<br/>
 
'''• Llamadas retenidas:''' Número de retenciones que el agente realizó
 
sobre las llamadas de ese grupo ACD.<br/>
 
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas por
 
el agente en ese grupo ACD.<br/>
 
'''• Trans. salida:''' Llamadas que finalizan con una transferencia.
 
  
===== Grupo ACD. Reporte diario con AHT =====
+
mdintz Variables:<br/>
 +
MdintzIdentif='cms1'<br />
 +
MOVIL_TIPO_RESET='10'<br />
 +
MOVIL_CAD_RESET='notify_yealink'<br />
 +
MdintzRes='OK'
  
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
+
El usuario con el login numérico 20001 se ha "movido" a la extensión 25001
el agente de un grupo ACD.<br/>
+
 
'''• Tiempo promedio ACD:''' Tiempo ACD/Llamadas ACD.<br/>
+
Ahora ''nos quitamos de esa extensión mediante el siguiente comando:''
'''• Tiempo promedio ACW:''' Tiempo ACW/Llamadas ACD.<br/>
+
 
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
+
'''mdintz qry * nimitz bd extenSaleUsuarioMovil 25001'''
o realizadas por el agente excluido el tiempo de retención de un grupo
+
 
ACD.<br/>
+
Resultado del comando:
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
 
tras finalizar las llamadas contestadas por el agente de un grupo ACD.
 
'''• Tiempo de llamado:''' Tiempo de ring en llamadas ACD de un grupo
 
ACD.<br/>
 
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa.<br/>
 
'''• Tiempo disponible:''' Tiempo que el agente estuvo conectado y no está
 
incluido en ninguno de los anteriores.<br/>
 
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
 
'''• Ayuda:''' Número de llamadas ACD contestadas por el agente en las que
 
necesito hacer uso de la consulta.<br/>
 
'''• Llamadas retenidas:''' Número de retenciones que el agente realizó
 
sobre las llamadas ACD contestadas.<br/>
 
'''• Tiempo retención:''' Tiempo que las llamadas contestadas ACD
 
estuvieron retenidas por el agente.<br/>
 
'''• Trans. salida:''' Número de llamadas ACD que fueron transferidas por el
 
agente.<br/>
 
'''• AHT:''' (Tiempo ACD+ Tiempo ACW+ Tiempo retención)/Llamadas
 
ACD.(Average Handle Time)<br/>
 
  
===== Grupo ACD. QOS =====
+
mdintz Variables:<br/>
 +
MdintzIdentif='cms1'<br/>
 +
MOVIL_TIPO_RESET='10'<br/>
 +
MOVIL_CAD_RESET='notify_yealink'<br/>
 +
  MdintzRes='OK'
  
'''• Vel. prom. de resp.:''' Tiempo total de espera de llamadas antes de ser
+
Las pruebas anteriores han sido '''con extensiones con movilidad y con usuario con/sin
atendidas/Llamadas ACD.<br/>
+
propietario.'''
'''• Tiempo prom. de aban.:''' Tiempo abandonadas(tiempo que las
 
llamadas abandonadas estuvieron en el grupo ACD)/Llamadas
 
abandonadas.<br/>
 
'''• Llamadas ofrecidas:''' Número de llamadas entrantes al grupo
 
ACD(Llamadas ACD+ Abandonadas+ Desbordadas).<br/>
 
'''• Llamadas ACD:''' Número de llamadas contestadas por los agentes.<br/>
 
'''• Llamadas abandonadas:''' Número de llamadas colgadas por el cliente
 
en el grupo ACD antes de ser contestadas o desbordadas.<br/>
 
'''• Desconectadas por ACD:''' Número de llamadas desbordadas que al
 
salir del grupo ACD se cuelgan.<br/>
 
'''• Desbordadas por ACD:''' Número total de llamadas desbordadas(incluye
 
las desconectadas).<br/>
 
'''• Llamadas atendidas en < 20s:'''Número de llamadas contestadas con
 
tiempo de respuesta menor a 20 segundos.<br/>
 
'''• Tiempo total de espera:''' Tiempo total que las llamadas estuvieron
 
esperando antes de ser atendidas.<br/>
 
'''• % N.A.:''' Llamadas ACD/(Llamadas ACD+ Llamadas abandonadas).<br/>
 
'''• % N.D.S.:''' (Llamadas atendidas en < 20s/Llamadas ofrecidas)* 100.<br/>
 
'''• T.M.O:''' (Tiempo ACD+ Tiempo ACW+ Tiempo retención)/Llamadas
 
ACD.(Tiempo Medio Operación)
 
  
===== Informe conducción (VDN Conducción) =====
+
Ahora las realizamos '''con extensiones sin movilidad'''
  
'''•Entrantes al grupo ACD:''' Número de llamadas ofrecidas al grupo
+
'''mdintz qry * nimitz bd extenEntraUsuarioMovil 25002 20001 1234'''
ACD(Contestadas+ Abandonadas+ Desbordadas).<br/>
+
 
'''•Llamadas contestadas:''' Número de llamadas contestadas por un agente.<br/>
+
Obteniendo:
'''•Contestadas NDS:''' Número de llamadas contestadas en nivel de servicio,
+
 
tiempo de respuesta< 20 segundos.<br/>
+
mdintz Variables:<br/>
'''•Abandonadas:''' Número de llamadas abandonadas, colgadas por el cliente
+
MdintzIdentif='cms1'<br/>
antes de ser contestadas por un agente o desbordadas.<br/>
+
MdintzRes='movil_error_datos'
'''•Desconectadas:''' Número de llamadas desbordadas que fueron colgadas al
+
 
salir del grupo ACD.<br/>
+
Como era lo previsible no nos deja "movernos" a esa extensión ya que no tiene movilidad.
'''•Desbordadas:''' Número total de llamadas desbordadas (incluye desconectadas)<br/>
+
<!--
'''•Llamadas retenidas:''' Número de retenciones que el agente realizó sobre las
+
'''<u>Si un usuario ya se ha movido a una extensión no se puede mover a otra si no es deslogandose de esta antes.</u>'''
llamadas ACD contestadas.<br/>
 
'''•% N.A.:''' (Llamadas contestadas/(Llamadas contestadas+ Abandonadas+
 
Desbordadas))* 100.<br/>
 
'''•% N.D.S.:''' (Contestadas NDS/(Llamadas contestadas+ Abandonadas + Desbordadas))*100<br/>
 
'''•% Abandonadas:''' (Abandonadas/(Llamadas contestadas+ Abandonadas+ Desbordadas))* 100.<br/>
 
'''•Acum. RING:''' Tiempo de ring en llamadas ACD(entrantes).<br/>
 
'''•ACDTIME:''' Tiempo de conversación ACD de las llamadas contestadas o
 
realizadas por el agente excluido el tiempo de retención de un grupo ACD.<br/>
 
'''•Acum. ACW:''' Tiempo dedicado por el agente a tareas administrativas tras
 
finalizar las llamadas.<br/>
 
'''•Acum HOLD:''' Tiempo que las llamadas contestadas ACD estuvieron retenidas
 
por el agente.<br/>
 
'''•Acum. OTHER:''' Tiempo total que las llamadas estuvieron esperando en el
 
grupo ACD antes de ser atendidas.<br/>
 
'''•Acum. AVAIL:''' Acum. STAFF- (ACDTIME+ Acum. ACW+ Acum. RING+ Acum.
 
HOLD+ Acum. AUX).<br/>
 
'''•Acum. Staff:''' Suma del Tiempo conectado de todos los agentes al grupo
 
ACD(Este tiempo se repercute en todos los grupos ACD a los que esta
 
conectado el agente).<br/>
 
'''•Acum. AUX:''' Suma del Tiempo en pausa de todos los agentes que estén
 
conectados al grupo ACD(Este tiempo se repercute en todos los grupos ACD a
 
los que esta conectado el agente).<br/>
 
'''•Prom. ACD:''' ACDTIME/Llamadas contestadas.<br/>
 
'''•Prom. ACW:''' Acum. ACW/Llamadas contestadas.<br/>
 
'''•Prom. HOLD:''' Acum. HOLD/Llamadas retenidas.<br/>
 
'''•AHT:''' (ACDTIME+ Acum. ACW+ Acum. HOLD)/Llamadas contestadas.<br/>
 
'''•Vel. prom. de resp.:''' Tiempo total de espera de llamadas antes de ser
 
atendidas/Llamadas ACD.<br/>
 
'''•Tiempo máx. de espera:''' Tiempo de la llamada que estuvo mas tiempo en el
 
grupo ACD hasta que fue atendida.<br/>
 
'''•Agentes en PH:''' (Acum. Staff- Acum. AUX)/1800(Agentes conectados que no
 
están en pausa en el intervalo).<br/>
 
'''•Agentes Staff:''' Acum. Staff/1800(Agentes conectados en el intervalo)<br/>
 
'''•Desglose de tiempos AUX:''' Tiempo que el agente estuvo en cada uno de los
 
motivos de pausa.
 
  
===== Informe de producción =====
+
Esta línea se comenta porque se ha preparado el sistema para que los ususarios se puedan logar en una nueva extensión y el sistema lo deslogue de la primera a la que se movió. La variable que controla este funcionamiento es MD_AUTODES, con dos posibles valores:
 +
0, para que el usuario deba deslogarse de una extensión para logarse en otra.
 +
1, para que sea el sistema el que deslogue automátiamente al usuario cuando cambia de una extensión de movilidad a otra.
 +
-->
  
'''• LL. ACD:'''Número de llamadas contestadas por ese agente para ese
+
'''<u>Si un usuario ya se ha movido a una extensión y se mueve a otra, el sistema lo deslogará de la primera para logarlo en la segunda.</u>'''
grupo ACD.<br />
 
'''• LL. HOLD:''' Número de retenciones efectuadas para las llamadas
 
contestadas en ese grupo ACD.<br />
 
'''• LL. Redir.:''' Número de llamadas no contestadas por un agente que
 
fueron redirigidas de nuevo a la cola.<br />
 
'''• LL. No colgadas cliente:''' Número de llamadas que terminaron sin el
 
colgado del cliente.<br />
 
'''• LL. Aband.:''' Número de llamadas abandonadas en ese grupo ACD, este
 
valor es independiente del agente por tanto se repite el valor para todos
 
los agentes en un mismo grupo ACD.<br />
 
'''• LL. Transfer.:''' Número de llamadas ACD que fueron transferidas por el
 
agente.<br />
 
'''• LL. Conf:''' Número de llamadas ACD en las que el agente estableció
 
conferencia.<br />
 
'''• S. Extensión:''' Número de llamadas salientes de extensión, este valor es
 
independiente del grupo ACD se repite el valor para todos los grupos
 
ACD en los que está conectado el agente.<br />
 
'''• Acum. Staff:''' Tiempo que el agente estuvo conectado al grupo ACD.<br />
 
'''• Acum. RING:''' Tiempo de ring en las llamadas ACD(entrantes) que
 
fueron contestadas por el agente.<br />
 
'''• Acum. ACD:''' Tiempo de conversación de las llamadas ACD(entrantes)
 
que fueron contestadas por el agente.<br />
 
'''• Acum. ACW:''' Tiempo dedicado por el agente a tareas administrativas
 
tras finalizar las llamadas que fueron contestadas por él.<br />
 
'''• Acum HOLD:''' Tiempo que las llamadas ACD(entrantes) para ese grupo
 
ACD que fueron contestadas por el agente estuvieron retenidas.<br />
 
'''• Acum. AVAIL:''' Acum. STAFF- (Acum. ACD+ Acum. ACW+ Acum. RING+
 
Acum. HOLD+ Acum. AUX)..<br />
 
'''• Acum. AUX:''' Tiempo que el agente estuvo en pausa este valor es
 
independiente del grupo ACD se repite el valor para todos los grupos
 
ACD en los que está conectado el agente..<br />
 
'''• Desgloses de tiempos AUX, tiempo AUX por cada uno de los
 
motivos.''' este valor es independiente del grupo ACD se repite el valor
 
para todos los grupos ACD en los que está conectado el agente.
 
-->
 
  
===== Consideraciones adicionales =====
+
'''mdintz qry * nimitz bd extenEntraUsuarioMovil 21000 20001 1234'''
  
Los tiempos se insertan en el intervalo en el que se deja ese "estado", esto provoca que en un intervalo pueda ser mayor el tiempo ACD que el tiempo conectado.
+
Con salida:
  
''* Ejemplo:''
+
mdintz Variables:<br/>
 +
MdintzIdentif='cms1'<br/>
 +
MOVIL_EXTEN='25001'<br/>
 +
MDintzRes='movil_ya_login'
  
-Llamada: Duración 15 minutos Hora fin de la llamada 13:01
+
'''* Dialplan'''
-Llamada: Duración 20 minutos Hora fin de la llamada 13:24
 
Suma de las duraciones de las llamadas para el intervalo ''35 minutos'' tiempo
 
conectado del agente en el intervalo ''30 minutos.''
 
Cuando los periodos consultados sean mas amplios (diario, mensual) los
 
desfases tenderán a desaparecer.
 
  
 +
Para llamar a la función de movilidad hay que marcar el '''9992.'''
  
 +
Nota.- Para comprobar que se realiza todo correctamente habría que mirar las trazas de Asterisk
  
 
<br><br>
 
<br><br>
Línea 6813: Línea 8696:
  
  
=== TBC (Translation by Chat) ===
 
  
  
La funcionalidad permite que dos interlocutores (a los que llamaremos “extranjero” y “agente”) puedan interactuar en una llamada telefónica independientemente del idioma en el que se expresen.
 
  
==== Requerimientos de usuario ====
 
  
Desde el punto de vista de usuario los requerimientos serán:
 
  
• Extranjero: Cualquier tipo de terminal telefónico (de VIVAit Call o externo) alcanzando un usuario de VIVAit Call;
+
=== Desvío por calendario ===
  
• Agente: Usuario de VIVAit Call, con terminal telefónico en VIVAit Call y portal de usuario; el entorno más unificado se consigue si el terminal telefónico es Web Call
 
  
 +
Se ha desarrollado una nueva funcionalidad para VIVAit Call que permite
 +
establecer desvíos de extensiones y usuarios en base a una programación
 +
horaria.
 +
Una vez puesta en marcha esta funcionalidad , el orden de desvíos de usuarios o
 +
extensión en VIVAit Call será:
  
  
==== Funcionamiento a nivel de usuario ====
+
* Primero se atiende si el usuario o extensión tiene desvío incondicional a
 +
mensajería.
  
 +
* En segundo lugar se comprueba si dispone de desvío programado, y se
 +
encuentra en una franja horaria con desvío activo.
  
1. Llamadas entrantes a grupos o servicios con traducción activada por defecto: En estos casos el agente no tendrá que hacer nada y la llamada dispondrá de servicio de traducción; es típico en grupos ACD
+
* Posteriormente se atiende si el usuario o extensión tiene desvío
 +
incondicional.
  
 +
* Posteriormente se tratarán resto de desvíos condicionales (por no
 +
conectado, por ocupado o por no contesta).
  
  
2. Llamadas salientes realizadas por el agente a un extranjero: En tal caso el agente realizará la llamada anteponiendo la facilidad *14# (ejemplo *14#3140) o la configurada a tal efecto en cada instalación
 
  
  
  
3. Llamadas establecidas para las que se desea activar TBC:
+
[[Archivo:Captura de pantalla de 2022-11-16 07-58-38.png|center|900px]]
  
a. En el caso de Web Call el agente dispondrá de un botón en el control de llamada que le servirá para activar TBC; la activación pasa por una autotransferencia directa de la llamada
 
  
b. En el caso de otros terminales el usuario deberá realizar una transferencia directa a si mismo (se usa para ello llamada a  *14*)
 
  
  
El funcionamiento general una vez establecida una llamada con servicio TBC será:
+
Los componentes principales de la arquitectura son:
  
  
• El extranjero habla en su idioma y escucha audios en su idioma; como se ha indicado anteriormente, en el lado del extranjero no es necesario ninguna herramienta adicional al terminal telefónico, que podrá ser interno o externo a VIVAit Call
+
*'''Servidor de calendarios''' : Para definir las programaciones de desvíos se ha utilizado una solución de servidor estándar de calendarios; se ha optado por el servidor Baikal, por disponer de todas las funcionalidades necesarias y disponer de BBDD Mysql (especialmente adecuado en entornos VIVAit)
  
  
'''El agente'''
+
*'''Intz-Nimitz''' : El proceso de enrutamiento de VIVAit consultará en cada llamada el estado de desvío programado al servidor de calendarios; esta consulta solo se realizará en caso de que dicha extensión o usuario tenga activo dicho desvío y un calendario asignado; por defecto los desvíos programados estarán desactivados en todas las extensiones y usuarios para proteger las prestaciones del sistema.
  
'''Para la recepción:'''
 
  
• Escucha el audio del extranjero (en el terminal)
+
*'''Frontales''' : Para la administración por parte de los usuarios de los desvíos programados se ofrecen los siguientes frontales:
  
• Lee el texto transcrito en el idioma del extranjero
+
- '''Portal de usuario:''' Cada usuario podrá definir desvíos programados en el mismo entorno en el que define el resto de desvíos.
  
• Lee el texto traducido en el idioma del agente
+
- '''Portal de administración de VIVAit''': Desde dicho portal se podrán gestionar por un administrador los desvíos programados de      usuarios y extensiones de todo el sistema.
  
 +
- '''Portal de administración de Baikal''': Desde dicho portal se podrán gestionar el servidor de calendarios.
  
'''Para la emisión:'''
+
- '''Entorno estándar de gestión de calendarios:''' desde un entorno estándar de gestión de calendarios (p. ej Thunderbird), y con protocolo CalDav, se podrán realizar gestiones de todos los calendarios de un entorno VIVAit. Este entorno sería una alternativa al portal de administración (no de usuario), debido a que:
  
  • Escribe en su idioma
+
1.  Se deberá configurar dicho entorno para acceder con el usuario de administración de calendarios.
 +
   
 +
2.  Se podrán ver todos los calendarios del sistema (de todas las extensiones y usuarios).
  
• Lee el texto traducido al idioma del extranjero
 
  
• Tiene opción de reproducir el audio que ha escuchado el extranjero
+
Por defecto no será necesario montar un nuevo nodo de VIVAit, para el despliegue de Baikal se montará donde esté ubicado el portal de administración de VIVAit.
  
 +
  '''Baikal se ubicará por defecto en el mismo nodo en el que se encuentre el portal de administración de VIVAit.'''
  
  
  
==== Funcionamiento a nivel de VIVAit Call ====
 
  
A nivel de VIVAit Call, los elementos principales involucrados en el servicio son:
 
  
'''• mdtap: Con sus componentes chan_mdtap e intz_tap se encargará de:'''
+
===== Baikal =====
  
''' chan_mdtap:'''
+
Como se ha indicado en el apartado de arquitectura, VIVAit Call utilizará un servidor de calendarios Baikal para almacenar la información referente a desvíos programados de usuarios y extensiones.
  
• Captura el audio
+
Baikal es un servidor CalDAV ligero. Los datos se almacenan en una base de datos Mysql (diferente a la base de datos de VIVAit).
  
• Reenvía a intz_tap
+
En el caso de su uso en VIVAit Call:
  
  • El audio pasa al otro extremo
+
* Existirá un único usuario administrador de Baikal que podrá crear los calendarios (desde los frontales anteriormente descritos).
 +
   
 +
* Los calendarios y los desvíos podrán ir asociados tanto a usuarios como a extensiones.
 +
 +
* Cada extensión o usuario de VIVAit tiene un calendario asignado que se crea automáticamente en Baikal al programar el primer evento desde el portal de administración de VIVAit o desde el portal de usuario.
  
  
''' intz_tap:'''
+
'''Si se instala Vivait 3.6 desde repositorio ,  habría que realizar los siguientes pasos en Mysql:'''
  
'''Para speech to text'''
+
'''Configuración de Mysql'''
  
• Invoca al servicio de conversión de audio a texto configurado y lo envía
 
  
• Recibe el texto y otros datos y los inserta en BDTR
+
La instalación de Baikal implica disponer de un servidor Mysql operativo; será necesario crear una base de datos de nombre “baikal” con un usuario “baikal” que será el que utilizarán los frontales para la interacción con el servidor de calendarios:
  
 +
Baikal usa su propia base de datos (diferente a la de VIVAit)
  
'''Para text to speech
 
'''
 
• Periodicamente (polling) comprueba si hay mensajes de tipo de contenido audio
 
  
• Recupera la URL
+
'''1.Configuración inicial Mysql'''
  
• Invoca al servicio de conversión de texto a audio configurado y lo envía
 
  
• Recibe el audio y lo inserta en la conversación en sustitución del audio del agente
+
Si la instalación la estamos realizando sobre un nodo que no tenía instalado Mysql y lo hemos instalado durante este proceso de instalación en el paso 3 del punto anterior, deberemos configurar Mysql para su integración con VIVAit.
  
 +
'''Acceder a Mysql y cambiar clave de root'''
 +
-------------------------
 +
mysql_secure_installation
 +
mysql -u root -p
 +
mysql> ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘ LACLAVEDEVIVAITPARAMYSQL ’;
 +
-------------------------
  
'''Portal de usuario/Web Call'''
+
*'''No realizar la configuración inicial de Mysql si el nodo ya dispone de base de datos VIVAit'''
  
•      Cuando se abre pestaña de TBC sincroniza mensajes https://172.25.128.253/Vivait-FonBO/api/recuperarId
 
  
  •    Periodicamente (polling) pide nuevos mensajes de TBC del extranjero a FonBO https://172.25.128.253/Vivait-FonBO/api/listaMensajesUsuario?lastId=85&idioma=es
+
'''2.Configuración de Base de datos Baikal'''
  
•    Envía mensajes de texto a FonBO https://wwv.mdtel.es/Vivait-FonBO/api/insertaMensaje?hayTraduccion=true&idiomaDestino=fr
 
  
 +
'''Crear base de datos de baikal'''
 +
-------------------------
 +
mysql> create database baikal;
 +
-------------------------
 +
'''2. Crear usuario baikal'''
 +
-------------------------
 +
create user 'baikal'@'localhost' identified by 'ivivabaikal';
 +
-------------------------
 +
'''3. Asignar privilegios a usuario baikal
 +
-------------------------
 +
grant all on baikal.* to ‘baikal'@'localhost’;
 +
-------------------------
  
'''FonBO:'''
 
  
• Responde a polling de Portal de usuario/Web Call
+
'''Configuración de Baikal'''
  
• Envía mensajes a traducir al servicio de traducción texto a texto, solo si el idioma del agente (configurado) y el idioma del extranjero (típicamente detectado) son diferentes; lo realiza para las traducciones en ambos sentidos
 
  
• Recibe mensajes traducidos y los inserta en BDTR
+
Una vez instalado, podemos comprobar que el servidor Baikal está operativo accediendo a su URL de gestión en:
  
  • Envía mensajes de texto al servicio de Text to Speech
+
  '''http://<IPServer>/baikal/html/'''
  
• Recibe el audio, lo almacena e inserta en BDTR (una URL)
 
  
 +
Tras acceder deberemos configurarlo adecuadamente, realizando los siguientes pasos:
  
  
==== Puesta en marcha ====
+
'''Crear la conexión entre VIVA it y Baikal'''
  
 +
Tener correctamente configurado en la tabla WEB_CONFIGURACION el usuario y clave de la base de datos de Baikal; esto permitirá configurar Baikal (usuario, calendarios…) sin tener que acceder a su interfaz de administración.
  
Para disponer de la funcionalidad será necesario disponer de:
+
Se configura:
  
 +
* Host
 +
* Puerto (defecto 3306)
 +
* Driver con el que se conecta (Mysql)
 +
* Usuario de BBDD Baikal
 +
* Clave de BBDD Baikal
  
• Base de datos actualizada con tabla DAT_MENSAJES_IA y COM_USUARIOS
 
  
• Fonbo versión xxxx
 
  
• Web Call versión 2.0.0 (para esta funcionalidad, esta versión de Web Call requerirá otros cambios en BBDD por otras funcionalidades implementadas)
+
'''A nivel de base de datos'''
  
• Chan_mdtap e Intz_Tap funcionando
 
  
 +
[[Archivo:calendario1.png|center|700px]]
  
  
La configuración cargada por defecto en el sistema permite la activación con mucha facilidad de las funciones de:
+
Donde:
  
 +
* '''MySQL host''' - Nombre del host de mysql.
 +
* '''MySQL database name''' - Nombre de la base de datos creada.
 +
* '''MySQL username''' - Nombre de usuario de acceso.
 +
* '''MySQL password''' - Contraseña de acceso.
  
• Casuística 1: Llamadas salientes realizadas por el agente a un extranjero; el agente marcará *14#num_Destino
 
  
  
::[[File:tbc1.PNG|250px|center]]
+
'''En ajuste de sistema'''
  
  
Es la facilidad con E_CODIGO_FACILIDAD = 800 (transcripción de número de teléfono).  
+
[[Archivo:calendario2.png|center|500px]]
  
 +
Donde:
  
::[[File:tbc2.PNG|800px|center]]
+
 +
* '''Zona horaria''' – Seleccionar la región que corresponda (típicamente Europe/Madrid).
 +
 +
* '''Habilitar o deshabilitar CardDav o CalDav''' – Es necesario habilitar CalDav, y deshabilitar CardDav (no se va a utilizar).
  
 +
* '''Enviar invitación al correo del remitente''' – Dejar vacío.
 +
 +
* '''Seleccionar el tipo de autenticación WebDav''' – Hay tres opciones (Digest, Basic y Apache), la opción que hay que seleccionar es Digest.
 +
 +
* '''Contraseña del administrador''' – Esta contraseña se configura solo para entrar al entorno de Baikal.
  
La numeración está definida por prerutas, una por categoría
 
  
  
::[[File:tbc3.PNG|800px|center]]
 
  
 +
'''Desde Baikal + Cliente Caldav'''
  
  
  
• Casuística 2: Llamadas establecidas para las que se desea activar TBC; el agente pulsará el botón de “traducción simultánea”
+
La administración desde Baikal solo será necesaria en caso de no poder utilizar los frontales desarrollados para la gestión de la funcionalidad.
  
::[[File:tbc4.PNG|350px|center]]
 
  
== Otros Diagnósticos y operaciones básicas ==
+
Consideraciones relevantes:
=== Arranque y apagado de la plataforma ===
 
  
En general el arranque y apagado de cada nodo de una plataforma '''''VIVA'''''it 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
+
*Desde la administración de Baikal si podremos crear:
  
  
El orden de arranque de la plataforma deberá ser:
+
- usuarios (en caso de la funcionalidad en VIVAit solo usuario único de VIVAit).
# En primer lugar arrancar el nodo con la base de datos de tiempo real
 
# Una vez finalizado el arranque del punto 1, arrancar el nodo con la base de datos de réplica
 
# Una vez finalizado el arranque del punto 2, arrancar el resto de nodos en cualquier orden
 
  
 +
- calendarios (existirá uno por extensión o usuario).
  
Al respecto del orden de apagado de nodos, es el siguiente:
 
# 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
 
# Una vez apagados totalmente todos los nodos del punto 1, apagaremos el nodo (o nodos) con bases de datos de réplica
 
# Una vez apagados totalmente todos los nodos del punto 2, se apagará el nodo con la base de datos de tiempo real
 
  
<br><br>
+
*Desde la administración de Baikal no podremos gestionar eventos de calendario; para ello deberemos usar un cliente CalDav (p. ej Thunderbird).
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
<!--
 
=== Nivel matriz de conmutación ===
 
-->
 
  
=== Grabación ===
 
  
==== Configuración de la grabación en la plataforma corporativa ====
+
'''Ejemplo de una consulta de intz-Nimitz a Baikal en los ficheros log:'''
Para que una llamada se grabe, lo primero de todo es que  alguien tenga la capacidad de grabar. Esto se consigue diciendo al nodo que sea grabador. Esto provoca que el nodo llame al mixmonitor para grabar y se inserte un registro en el DAT_GRABACIONES. Esto no significa que ya las llamadas se vayan a grabar, ya que para eso tiene que ser procesadas por un nodo que sea grabador. Hay tres, llamémosle elementos, que se pueden grabar:
 
  
* El nodo, es decir todo lo que el nodo enrute
 
* Prerutas
 
* Objetos: que son las extensiones, usuarios, grupos corporativos, etc.
 
  
Tenemos tres formas de grabar:
+
Ante una consulta de Intz-Nimitz a Baikal, los resultados devueltos en el fichero de log (/var/log/intz-nimitz.log) por Baikal pueden ser:
  
* Grabar con beep periódico
 
* Grabar sin beep periódico
 
* Descartar grabación
 
  
Si de los tres elementos tenemos que uno grabe, ya sea con o sin beep periódico, esa llamada se va a grabar ya que son OR, en cuanto haya un elemento que diga que grabe se va a grabar.
+
1. En caso de existir una programación de desvío, Baikal devolverá los campos asunto y location de la programación, que podrán ser usados en los procesos posteriores de tratamiento de la llamada en caso de ser necesario:
  
Al igual pasa si tenemos que un elemento tenga descartar la grabación. La grabación no se inicia.
 
  
Referente al campo de Modo de grabación en infraestructura, este no se emplea para la grabación de corporativo, sino que solo tiene validez en ACD. Para grabación en el ACD hay que, como se ha dicho anteriormente poner un nodo que sea grabador y especificar un elemento de los tres que hay cual es el que se va a grabar.
 
  
Para que exista una grabación ha de existir un segmento asociado a esta. Los segmentos se tratan en las prerutas. Hay un campo es las prerutas que es Generar segmento al enrutar. Si está se generará el segmento del tipo de la preruta y su correspondiente grabación si esta está configurada. Si le decimos que no genere segmentos al enrutar y el sistema está configurado para que grabe, el recordCentral creará un tipo de segmento llamado externo para esa grabación. Podemos configurar si queremos que se cree o no ese segmento, para eso hay que modificar el fichero de configuración del recordCentral y poner un tiempo muy alto al campo $segmExternoMinSegs. También podemos configurar que segmentos queremos que se graben. Por defecto el recordCentral va configurado para que se graben todos los segmentos. Para decirle que solo grabe cierto tipo de segmentos hay que ponerlos los que queramos que si se graben en la variable $tiposSegmentoGrabar del fichero de configuración del recordCentral.
+
[[Archivo:calendario5.png|center|700px]]
  
  
==== Como configurar la grabación bajo demanda ====
 
  
Para activar la grabación bajo demanda es necesario activar el '''MixMonitor'''.
+
2. En caso de no existir programación de desvío, devolverá vacío:
  
En el Nodo hay que identificar '''Grabar por enrutamiento''' = '''Sin grabación'''.
 
  
  
 +
[[Archivo:captura6.png|center|700px]]
  
[[File:Ejemplo activacion grabacion en nodo CORP-2.jpg|centro]]
+
=== Grabación ===
  
 +
La grabación en '''''VIVA'''''it Call está diseñada para ser lo mas flexible posible.
  
 +
====Configuración====
  
 +
Si deseamos grabar, debemos activar que alguno de los dispositivos/elementos que intervienen en la llamada se grabe.
  
En el Nodo ACD y/o Corporativo es obligatorio que el campo '''Modo de grabación de infraestructura''' sea igual a '''Graba por petición'''.
+
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 cuatro campos que intervienen en la grabación.
  
[[File:NODO ACD-2.jpg|centro]]
+
''''Grabador''''
  
 +
Se configura en el portal en la sección general/nodos.
  
 +
Este campo corresponde con el campo [[BD.COM_NODOS#B_ES_GRABADOR|B_ES_GRABADOR]] de la tabla [[BD.COM_NODOS|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.
  
En la Campaña (asignar la cola a la campaña; si se pone el modo de grabación en la cola, '''no funciona <big><sup>'''**'''</sup></big>''', ha de ir en la campaña o en el VDN) o en VDN el campo “'''Modo de grabación'''” debe ser igual a '''Grabación Bajo demanda inicio sin grabar ó grabando'''.
+
Es un campo booleano los posibles valores en el portal son si/no y en la base de datos 1/0.
  
  
  
[[File:MODO DE GRABACION EN CAMPAÑA-2.jpg|centro]]
+
''''Modo grabación infraestructura''''
  
 +
<!--Su configuración se realiza en el portal, en la sección general/nodos.
  
 +
Este campo define como está configurada la infraestructura, este campo existe por compatibilidad con '''''VIVA'''''it suite y para poder configurar la grabación bajo demanda.
  
 +
Este campo corresponde con el campo [[BD.COM_NODOS#E_MODO_GRABACION_INFRAESTRUCTURA|E_MODO_GRABACION_INFRAESTRUCTURA]] de la tabla [[BD.COM_NODOS|COM_NODOS]], Este campo usa los valores del enumerado BD.ENUM.TModoGrabacionInfraestructura|TModoGrabacionInfraestructura]].
  
El formulario de '''''VIVA'''''it  Desk que se abra cuando entre la llamada que queremos grabar ha de tener los botones de grabación.
+
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,...).-->
 +
[[:medio:Modo grabacion infraestructura grabacion por petición.pdf|Modo grabación de infraestructura-Graba por petición]]
  
[[File:Ejemplo de formulario con botones de grabacion.jpg|centro]]
 
  
 +
''''Grabar enrutamiento''''
  
 +
Se configura en el portal en la sección general/nodos.
  
Trazas '''''VIVA'''''it  Desk:
+
Este campo define si van a grabar las llamadas que se enruten en este nodo.
  
gre evliniciarGrabacion infra=20 modo=10 esta=”6/Demanda sin grabar”
+
Campo [[BD.COM_NODOS#E_ENRU_GRABAR|E_ENRU_GRABAR]] de la tabla [[BD.COM_NODOS|COM_NODOS]] que usa los valores del enumerado [[BD.ENUM.TTipoEnruGrabar|TTipoEnruGrabar]].
  
Para que la grabación bajo demanda esté bien configurada en la traza anterior los valores de '''infra''' y '''modo''' deben ser '''distintos de 0'''.
 
  
 +
''''RecordCentral''''
  
'''<big><sup><big>'''**'''</big></sup> Hemos visto que la grabación Bajo demanda en los Grupos ACD si funciona.</big>'''
+
Se configura en el portal en la sección general/nodos.
  
Para activarla hay que entrar en la configuración del Grupo ACD que queremos grabar y activar la grabación por enrutamiento:
+
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.
  
[[File:cap_1.jpg|600px]]
+
====Vivait Tracker====
 +
<!--
 +
::<span style="background:#FFAA00"> DANIEL LA ÚNICA REFERENCIA A VIVAIT TRACKER EN LA DOCUMENTACIÓN "Vivait supervisor" QUE TENGO DICE LO SIGUIENTE. </span>
 +
-->
 +
Desde '''''VIVA'''''it Supervisor,  que es la aplicación dirigida a Supervisores, ofrece la posibilidad de supervisar y gestionar grupos ACD, agentes, asignaciones, prioridades,etc. Se puede obtener acceso directo a las aplicaciones de grabación ('''''VIVA'''''it tracker)
  
 +
<!--
 +
::<span style="background:#FFAA00"> DANIEL FIN EXPLICACIÓN. </span>
  
Además indicamos en el modo de grabación: Grabación bajo demanda inicio sin grabar.
 
  
 +
::<span style="background:#FFAA00"> DANIEL De la documentacion creada por ivan. </span>
 +
-->
 +
Esquematico actual del proyecto tracker
 +
[[Archivo:Esquematico_tracker_1.jpg|center]]
  
[[File:cap_2.jpg|600px]]
 
  
 +
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.
  
En la consola vemos los siguientes datos:
+
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.
  
[[File:cap_3.jpg|600px]]
+
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.
  
==== Comprobar que el servidor de grabación está activo ====
+
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.
 +
<!--
 +
::<span style="background:#FFAA00"> DANIEL De la documentación creada por ivan. </span>
 +
-->
 +
Esquematico actual del proyecto tracker
 +
[[Archivo:Esquematico_tracker_2_https.jpg|center]]
  
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 ningún resultado implica que tampoco esta activo.
 
  
==== Comprobar que los nodos están conectados al servidor de grabación ====
+
1º El tracker web llama al web service Remote login para iniciar sesión (comunicación https) y determinar si tiene permisos para la escucha y descarga de grabaciones. Se elimina el proxy
  
Debemos fijarnos en la linea de respuesta del comando '''''nc ip_maquina 1114''''', que seria:
+
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.
{| class="wikitable"
 
|-
 
| root@smadavacdrecord1:~# nc localhost 1114
 
recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423
 
160112'
 
  
recordCentral MYSQL cnx=1
+
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)
  
recordCentral NAS llamadas=1 segmentos=1
+
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).
  
recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305
+
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.
  
'''recordCentral NODO fase=0 cuarentena='' descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10''''
+
[[#Grabación_(Vivait_Tracker)| Volver arriba]]
|}
+
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0 Volver al índice]
 +
<br><br>
  
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.
+
=== Enrutamiento ===
  
==== Comprobar que un nodo tiene activo el agente de grabación ====
+
[[Archivo:Enrutamiento.png|885px |center]]
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.
 
  
==== Comprobar 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:
 
  
{| class="wikitable"
+
==== Enfoque inicial ====
|-
 
| root@smadavacdrecord1:~# nc localhost 1114
 
recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423
 
160112'
 
  
recordCentral MYSQL cnx=1
+
[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Enfoque_inicial Acceso]
  
recordCentral NAS llamadas=1 segmentos=1
+
==== Funcionamiento ====
 +
El proceso de enrutamiento, como vimos en el esquemático, se compone de dos fases:
  
recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305
+
# Preenrutameinto, que se encarga de tratar todas las llamadas
 +
# 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.
  
'''recordCentral NODO fase=0 cuarentena='' descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10''''
+
Se asume que existen rutas directas entre todos los nodos de la red.
|}
 
  
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.
+
Se asume que están directamente enrutadas todas las direcciones IP involucradas, tanto nodos, como terminales.
  
==== Comprobación de grabaciones que se hayan quedado enganchadas en un nodo ====
+
Se asume que todas las facilidades están disponibles en todos los nodos, aunque es posible que la implementación sea diferente entre ellos.
Podemos fijarnos en los dos comandos, para '''''nc ip_maquina 1114''''':
 
{| class="wikitable"
 
|-
 
| root@smadavacdrecord1:~# nc localhost 1114
 
recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423
 
160112'
 
  
recordCentral MYSQL cnx=1
+
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
  
recordCentral NAS llamadas=1 segmentos=1
 
  
recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305
+
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
  
'''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.
+
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)
  
==== 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:
+
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.
  
{|class="wikitable"
+
=====Fase preenrutamiento =====
|-
 
! 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
 
  
|}
+
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.
  
Nos fijaríamos en la línea marcada en negrita, el campo "Use%" indicara el porcentaje de almacenamiento temporal de grabaciones en un nodo.
+
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.
  
<br><br>
+
Los datos de salida de la fase de preenrutamiento:
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
+
* D_CATEGORIA_SAL
<br><br>
+
* 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
  
===Escuchas e intrusiones en asterisk===
+
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.
'''CallSpy''' es una aplicación elaborada para asterisk que permite a un usuario realizar escuchas e
 
intrusiones en llamadas.
 
En realidad tenemos dos aplicaciones en asterisk, CallSpy y CallSpyee.
 
====CallSpy ====
 
{|
 
|-
 
|
 
'''Nota:''' Como mucho se pueden tener a dieciséis personas al mismo tiempo usando esta aplicación.  
 
|}
 
  
Como hemos mencionado anteriormente, esta aplicación permite la escucha de llamadas y,  
+
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.
opcionalmente, realiza la función de intrusión. Tiene tres opciones de configuración obligatorios
 
que mostramos a continuación:
 
  
{|
+
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 
  CallSpy(<tipoEspiado>,<expRegEspiado>,<parametrosConf>)
+
:* 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.
La opción '''<tipoEspiado>''' se refiere a que tipo de objeto que podemos espiar correspondiente, solo debe elegirse un único tipo:
+
 
*'''c:''' escuchar una cola
+
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.  
*'''v:''' escuchar un vdn
+
 
*'''a:''' escuchar a un agente
+
Si ID_CATEGORIA_SAL es cero, se propaga a la salida el valor de la entrada. En caso contrario, se sustituye.  
*'''e:''' escuchar extensión
 
La opción '''<expRegEspiado>''' representa el número de la cola, VDN, agente o extensión que queremos escuchar. Tiene que ser una expresión regular.
 
La opción '''<parametrosConf>''' se refiera a los parámetros de configuración para la llamada que podemos espiar, se pueden combinar o juntar :
 
*'''q:''' Desactiva el 'beep' al comienzo de cada nueva llamada.
 
*'''v([value]):''' Ajusta el volumen en el rango -4 a 4 (más alto, mas volumen).
 
*'''e:''' Habilita el que se pueda cambiar a otra llamada de la misma extensión.  
 
*'''w:''' Habilita el que se pueda activar la intrusión (whisper).
 
Una vez iniciada la escucha, solo falta que entre una llamada al objetivo que estemos espiando. Al
 
iniciar la escucha, se puede hacer lo siguiente:
 
*Pulsando '''#''' modifica el volumen de escucha.
 
*Pulsando '''*''' cambia a una nueva llamada.
 
*Pulsando '''1''' si esta habilitado, cambia a otra llamada de la misma extensión.
 
*Pulsando '''2''' si esta habilitado, inicia la función de intrusión.
 
*Pulsando '''3''' desactiva la función de intrusión.
 
====CallSpyee (espiado)====
 
Mediante esta aplicación indicamos los parámetros que permite a una llamada ser seleccionada para
 
escuchar. Las opciones de configuración son:
 
{|
 
|-
 
|
 
CallSpyee([CID_NUM],[cola],[vdn],[agen],[exten])
 
<small>'''Nota:'''No son parámetros obligatorios, por lo que no hace falta rellenar todos los campos pero si respetar sus posiciones separadas por comas.<small>
 
|}
 
La explicación de los parámetros es la siguiente:
 
*'''CID_NUM:''' representa el call ID de la llamadas
 
*'''cola:'''representa el número de la cola que se quiere espiar (${QUEUE} ).
 
*'''vdn:'''  representa el número del VDN que se quiere espiar (${VDN} ).
 
*'''agen:''' representa el número del agente que se quiere espiar.
 
*'''exten:''' representa el número de la extensión que se quiere espiar (${EXTENSION}) .
 
  
Por ejemplo si queremos escuchar todas las llamadas en las que participa una extensión determinada pondremos en la macro de extensiones:
+
Si C_CALLER_NAME está vacío, se mantiene el valor hubiese a la entrada. En caso contrario, se sustituye.
{|
 
|-
 
|
 
exten => s,n,CallSpyee(,,,${EXTENSION})
 
|}
 
  
====Cambios para el dialplan de asterisk====
+
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:
El funcionamiento de este tipo de servicio conlleva un cambio en el dialplan de asterisk. En cada macro correspondiente se pondrá los diferentes CallSpyee para VDN, colas  , extensiones y agentes.  
+
* "=" o cadena vacía, el nuevo CALLER_NUM es igual al de entrada al proceso.  
Pasos a seguir:
+
* "+" el nuevo CALLER_NUM es igual al de entrada al proceso, con los caracteres a continuación de "+" como prefijo.  
*Paso 1. Creación de un código de intrusión para cada tipo según necesidad (cola, VDN, agente y
+
* "-" se quita el número de caracteres que se indica a continuación de "-".
extensión).  
+
* "_" 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.
|-
 
|
 
Ejemplo '''MD'''tel:  declaramos como código de intrusión a Agente *44*NUMERO
 
;==========================================
 
;======== Intrusion a Agente
 
;==========================================
 
exten => _*44*X.,1,set(CadMarcar=intrusionEspiado)
 
exten => _*44*X.,n,set(DesL=SERVICIO)
 
exten => _*44*X.,n,set(datoServicio=^${EXTEN:4})  
 
exten => _*44*X.,n,Goto(finMacro,1)
 
<small>'''Nota:''' En la tercera línea podemos observar la expresión regular que se le pasara al CallSpy correspondiente con el número marcado por el espia. <small>
 
|}
 
  
*Paso 2.Llamar a CallSpy con la configuración deseada.
+
Cada vez que se utilice una preruta, se incrementará el valor de N_CONTA si el valor de N_UMBRAL es mayor que cero.
{|
 
|-
 
|
 
Ejemplo '''MD'''tel:  llamada a CallSpy especificando que vamos a espiar una cola (la c del primer parámetro, con la
 
extensión introducida en el código de intrusión y con whisper, es decir, función de intrusión habilitada.
 
;------------------------------------------------------------------------
 
; Intrusion a Espiado
 
;------------------------------------------------------------------------
 
exten => intrusionEspiado,1,NoOp
 
exten => intrusionEspiado,n,GotoIf($["${datoServicio}"=""]?colgar)
 
exten => intrusionEspiado,n,CallSpy(c,${datoServicio},w)
 
exten => intrusionEspiado,n(colgar),Hangup
 
|}
 
* Paso 3. Llamar a CallSpyee con la configuración de las llamadas candidatas a ser escuchadas.
 
{|
 
|-
 
|
 
Ejemplo '''MD'''tel:
 
exten => s,n,CallSpyee(,,,,${EXTENSION}) → Para extensiones
 
exten => s,n,CallSpyee(,${QUEUE},,,) → Llamadas espiadas por cola
 
exten => s,n,CallSpyee(,,${VDN},,) → Llamadas espiadas por VDN
 
|}
 
  
<br><br>
+
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.
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Calendarios ===
+
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.
  
{| class="wikitable"
+
Un proceso periódico externo debe encargarse de poner a cero o decrementar el valor de N_CONTA.
| Nota: '''En la versión de VIVAit 3.5 , Se tiene que instalar el nuevo servidor de DaviCal. '''
+
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.
|}
 
  
Para la configuración de los calendarios en la versión VIVAit 3.5 , se tiene que instalar el nuevo servidor DaviCal en una máquina aparte.
+
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.  
  
Se adjunta un manual para su instalación:
+
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.
  
 +
===== 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).
  
<big>'''[[medio:Servidor_Calendarios_DAViCal.pdf|Manual de instalación de servidor de calendarios para '''''<span style="color:#144F9B">VIVA</span>'''''it 3.5]]'''</big>
+
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.
  
  
  
 +
===== 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.
  
Para la configuración de los Calendarios se hace uso de '''CalDAV''', estándar de Internet que permite a un cliente acceder a información de planificación en un servidor remoto. Permite que varios clientes accedan a la misma información, facilitando la cooperación. Muchas aplicaciones, tanto clientes como servidores, son compatibles con este protocolo.
+
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.  
  
Si deseamos crear un calendario en la plataforma '''VIVAit''' podemos hacerlo siguiendo el  siguiente enlace: 
+
Una vez que un registro es válido, se descartan todos los registros cuyo C_DESTINO_ENT_PREF es diferente del primero seleccionado.  
Para comprobar que el servidor de calendarios funciona correctamente bastaría con cargar en la barra de direcciones la siguiente url: [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Calendarios |Calendarios]]
 
  
http://${NODO.HOST}/dav/html/cal.php/calendars/${DAV.CUENTA}/${DAV.CALENDARIO}
+
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:  
  
donde,
+
CALLER_NAME_nn: Si C_CALLER_NAME está vacío, se propaga el valor de entrada. En caso contrario, se sustituye.
  
* '''NODO.HOST:''' es la ip del servidor calendar
+
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:  
* '''DAV.CUENTA:''' hace referencia a la cuenta de usuario
+
* "=" o cadena vacía, el nuevo CALLER_NUM_nn es igual al de entrada al proceso. 
* '''DAV.CALENDARIO:''' hace referencia el nombre de la cuenta
+
* "+" 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.
  
Una vez que se carga la url sabremos que el servidor funciona correctamente si visualizamos lo siguiente:
+
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.
  
[[Archivo:Captura de pantalla de 2016-07-21 12_43_58.png || 1020px|center]]
+
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.  
 
 
 
 
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
 
      - En la máquina donde esté instalado el servidor de calendarios apuntar a la IP de la BDTR (/var/www/dav/config.php)
 
  
 +
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.
 
<br><br>
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
<br><br>
  
=== Syslog de agentes ===
+
=== Control de ancho de banda ===
'''''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 :
+
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)
* 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.
+
:* Sede del nodo de registro del terminal origen (nodo A)
* Una serie de pares clave-valor con metadatos.
+
:* Sede del terminal destino (terminal B)
* El texto del mensaje.
+
:* 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
 +
 
 +
[[Archivo:ancho de banda.png|700px]]
  
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 ''VIVA''it'''  configurando unos parámetros para un usuario llamado ''Rastreo BBDD" y ''Rastreo Syslog''. Para más información[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Pesta.C3.B1a_ACD | ver sección  Portal de administración - General - Usuarios - Pestaña ACD  ]].
+
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:
  
{| class="wikitable" border="0"  align="top"
+
{| class="wikitable"  
 +
|-
 +
! Variable!!Campos
 
|-  
 
|-  
| align="center" style="background:Lavender; color:Black" |<big>'''Elemento'''</big>
+
|R_ABDE_xx||R = Variable de rutas --- AB = ancho de banda --- D = dispositivo --- E = Entrante --- xx = de 0 a 3
|align="center" style="background:Lavender; color:Black" | <big>'''Procedimiento'''</big>
 
 
|-
 
|-
!colspan="2" width="60 px" style="background:Lavender; color:Black"|Operacion
+
|R_ABNE_xx||R = Variable de rutas --- AB = ancho de banda --- N = nodo --- E = Entrante --- xx = de 0 a 3
 
|-
 
|-
|Ubicación del proceso||Script arranque: /etc/init/ rsyslog.conf
+
|R_ABDS_xx||R = Variable de rutas --- AB = ancho de banda --- D = dispositivo --- S = Saliente --- xx = de 0 a 3
Configuración :
+
|-  
/etc/rsyslog.d/30-vivait-
+
|R_ABNS_xx||R = Variable de rutas --- AB = ancho de banda --- N = nodo --- S = Saliente --- xx = de 0 a 3
desk.conf
 
|-
 
|Arranque||service rsyslog start
 
|-
 
|Parada||service rsyslog stop
 
|-
 
|Reinicio||service rsyslog reload
 
 
|-
 
|-
!colspan="2" width="60 px" style="background:Lavender; color:Black"|Diagnostico
 
|-
 
|Registro de logs||/var/log/MDtel/vivait-desk.log
 
Fichero del día actual. se guardan los 30
 
anteriores comprimidos en tar.g
 
 
|}
 
|}
  
 +
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
  
'''Ejemplo 30-vivait-desk.conf:'''
 
 
#  Default rules for rsyslog.
 
#
 
#            For more information see rsyslog.conf(5) and /etc/rsyslog.conf
 
 
#
 
# First some standard log files.  Log by facility.
 
#
 
local4.*            -/var/log/MDtel/vivait-desk.log
 
local5.*              -/var/log/MDtel/rastreo.log
 
  
 +
=== MDflow ===
  
Es muy importante comprobar que el servidor de '''syslog''' escucha por el puerto '''514''':
+
MDflow es una aplicación Asterisk que se basa en la unidad de medida TIC (un TIC, por defecto, corresponde a 500ms, pero es configurable).
 
#################
 
#### MODULES ####
 
#################
 
 
module(load="imuxsock") # provides support for local system logging
 
module(load="imklog")  # provides kernel logging support
 
#module(load="immark")  # provides --MARK-- message capability
 
 
# provides UDP syslog reception
 
module(load="imudp")
 
input(type="imudp" port="514")
 
 
# provides TCP syslog reception
 
module(load="imtcp")
 
input(type="imtcp" port="514")
 
 
# Enable non-kernel facility klog messages
 
$KLogPermitNonKernelFacility on
 
 
###########################
 
#### GLOBAL DIRECTIVES ####
 
###########################
 
  
=== Generación de un Core ===
+
Los términos que usaremos para la explicación de la funcionalidad y que son relevantes
Un Core es la memoria de un programa.
+
para comprender, implantar, mantener e interpretar la misma son:
  
Para generar un Core rápido con Asterisk hay que hacer lo siguiente:
 
  
    Ejecutar ps aux | grep asterisk y coger el PID del programa
 
    gdb /usr/sbin/asterisk [PID]
 
    gcore [file]
 
  
<br><br>
+
* '''Nodo VIVAit''': Un nodo VIVAit es cualquier elemento dado de alta en el sistema
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
+
como tal, que contiene un proceso de conmutación de voz Asterisk incorporado. Un
<br><br>
+
cluster activo/pasivo son dos ordenadores, pero un solo nodo. Típicamente existen
 +
nodos de tres tipos (si bien los dos primeros pueden combinarse en uno solo):
  
==Funcionalidades específicas ==
+
- Nodo de registro para telefonía corporativa
=== Mecanismo de prioridad adaptativa ===
 
  
El mecanismo de prioridad adaptativa permite en una plataforma '''''VIVA'''''it 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
+
- Nodo Gateway
  
==== Introducción ====
+
- Nodo de registro ACD
  
Este documento presenta una propuesta de mecanismo de asignación de llamadas en colas a agentes basado no solo en las prioridades de agente a cola,
+
* '''TIC''': Unidad básica de medida de tiempo de md flow; por defecto el valor es
sino en un factor de corrección de prioridad derivado del tiempo de espera de una llamada
+
500ms; nótese que los valores devueltos por el sistema siempre estarán medidos
 +
en segundos, aunque internamente use el TIC como base de tiempos.
  
==== Terminología ====
+
* '''Flujo:''' Cada uno de los nueve elementos de medida y control que podrán
 +
establecerse por nodo VIVAit.
  
* '''Prioridad de llamada:''' A cada llamada susceptible de ser atendida en el ''Call Center'' se le asignará una prioridad de llamada; dicha prioridad será asignada cada vez que un agente quede disponible.
+
* '''Medición:''' Capacidad de md flow para determinar el número de llamadas por
* '''Prioridad de grupo ACD:''' Los agentes del ''Call Center'' tendrán configurada una prioridad para cada grupo ACD al que pertenecen
+
segundo que se están estableciendo en un determinado flujo. Nótese que no se
* '''Tiempo de espera:''' Tiempo que una llamada lleva en espera en un determinado grupo ACD; si la llamada cambia de un grupo ACD a otro el tiempo de espera pasa a cero
+
hace referencia a duración de las mismas o medición de llamadas previamente
* '''Objetivo de servicio:''' Tiempo objetivo máximo de espera por cada grupo ACD
+
establecidas
  
'''Nota.-''' ''En terminología Asterisk el aumento de prioridad corresponde con números descendentes, es decir,<br />
+
* '''Control:''' Capacidad de md flow para limitar el número de llamadas por segundo
prioridad 50 es mejor que prioridad 70''
+
que se están estableciendo en un determinado flujo
  
==== Mecanismo de asignación de llamadas ====
+
* '''Tasa de llamadas por segundo:''' Cantidad de llamadas que se están
 +
estableciendo por segundo en un nodo VIVAit. Nótese que no se hace referencia a
 +
duración de las mismas o llamadas previamente establecidas
  
En el momento en que exista un agente disponible para recibir llamada, el agente recepcionará la llamada con mejor prioridad de llamada (menor número). La prioridad de llamada para cada llamada se establecerá de la siguiente manera:
+
* '''DNIS: Dialed Number Identification Servic'''e; número destino de una llamada
 +
 
 +
* '''Congestión''': Estado del nodo VIVAit cuando se sobrepasa una determinada tasa
 +
de llamadas por segundo; el mecanismo md flow entrará en funcionamiento cuando
 +
el sistema entre en estado de congestión.
 +
 
 +
* '''Llamada desbordada:''' Llamada que en el tratamiento de la congestión se
 +
considera apta para ser descartada (si bien el tratamiento se definirá en dialplan, el
 +
funcionamiento lógico previsto es descartarla).
  
- Agentes con prioridad de grupo ACD de 1 a 99 utilizarán el mecanismo convencional de asterisk de prioridad absoluta; será útil para grupos ACD críticos o en Call Centers muy convencionales
+
* '''Llamada a agujero:''' Llamada que en el tratamiento de la congestión se considera
 +
ha de progresar por no quedar colas de DNIS disponibles (se explicará y justificará
 +
el funcionamiento más adelante).
  
'''Si un agente tiene prioridad menor de 100 en grupos ACD y hay llamadas en dichos grupos, estas llamadas serán atendidas por el agente con prioridad absoluta.'''
+
* '''Mdflow en paso:''' md flow puede ser utilizado para:
  
- Agentes con prioridad de colas de 100 en adelante; se utilizará el siguiente mecanismo de prioridad ponderada:
+
- Solo medir . En este caso md flow se encontrará en paso.
  
:*Si el grupo ACD de la llamada está dentro del objetivo de servicio, la prioridad de llamada será la prioridad de grupo ACD (a efectos prácticos se aplicará el mecanismo convencional de asignación de llamada a agente, equitativo entre grupos ACD con misma prioridad)
+
- Medir y realizar control de flujo.
  
:*Si el grupo ACD de la llamada está fuera del objetivo de servicio, se aplicará una ponderación que mejorará la prioridad de la llamada a medida que aumente el tiempo de espera:
+
* '''DNIS masivo:''' Un DNIS con alta tasa de llamadas por segundo.
  
[[Archivo:Formula.png |center]]
+
* '''DNIS ocasional:''' Un DNIS con baja tasa de llamadas por segundo.
  
En una configuración de igualdad de prioridad de agente y objetivo de servicio, el tiempo de espera influiría de manera determinante (más o menos en
 
función del peso) en la asignación de la siguiente llamada
 
El peso podrá adquirir tres posibles valores: 0, 1 y 10
 
  
[[Archivo:Esquema.png |center]]
 
  
  <span style="color:#000080">- Calculo prioridad de llamada: se calcula por llamada cada vez que un agente queda libre</span>
 
  <span style="color:#000080">- Agente atiende llamada con mejor prioridad de llamada</span>
 
  
  
<!--
 
[[Medio:Asignación de llamadas por prioridad adaptativa.pdf|Asignación de llamadas por prioridad adaptativa]]-->
 
  
<br><br>
+
La aplicación está diseñada para '''controlar el flujo de llamadas entrantes''' → '''El sistema cuenta llamadas en cada periodo TIC.'''
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Marcación saliente ===
+
El módulo permite difinir distintas cajas de medida y control ('''FLUJO''').
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.
 
  
 +
Se pueden definir n cajas y ubicarlas en Asterisk (por ejemplo en un enlace externo, una caja que agrupe todos los enlaces, en los enlaces interiores y en extensiones).
  
====Esquema de funcionamiento====
+
Cada una de las cajas, o flujos, mide y controla la tasa de llamadas en cada TIC → Se mostrará en llamadas/segundo.
[[Archivo:esquema funcionamiento marcador.jpg|center|500px]]
 
  
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.
+
El '''FLUJO'''mide lo que está pasando en un determinado punto del dialplan; un ejemplo claro será la primera línea de éste, cuando se crea una llamada de un enlace externo.
  
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.
+
El '''FLUJO'''permite controlar y medir, y está pensado para enviar información a Zbbix.
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.
 
  
====Flujo de estados====
+
Desde el punto de vista del Dialplan, se trata de una aplicación con dos parámetros:
 +
*Que caja se utiliza (número del 1 al 9).
 +
*DNIS que permite controlar para que destino queremos hacer el control de flujo.
  
El flujo de estados es el reflejado en la figura siguiente:
+
Para encolar internamente cada '''FLUJO''' tiene un número de colas definidas y cada DNIS está en una cola.
 +
Cuando entra una llamada y se invoca a la caja con el DNIS de esa llamada, o se crea nueva cola, o se encola en una existente para ese DNIS si la hubiera.
 +
El número de colas deberá ser el numero de DNIS masivo.
 +
 
 +
Una cola de un DNIS se libera de ese DNIS cuando queda vacia (por eso los ocasionales no tendrán cola habitualmente y los masivos si).
 +
 
 +
Cuando entra una llamada si el DNIS tiene cola se encola, si no tiene y hay libres se crea una nueva y si no hay colas libres (maximo configurable), la llamada pasa. (se asume que las masivas quedarán en colas y que las ocasionales pasarán).
 +
 
 +
Para sacar llamadas (desencolar), saco una de cada cola (fair queues). No podemos configurar que de unas colas se atiendan mas llamadas que de otras.
 +
 
 +
En control de flujo se indica para cada caja la tasa de entrada en llamadas/s.
 +
 
 +
El mecanismo de control de flujo entra en funcionamiento cuando el sistema entra en '''congestión'''.
 +
 
 +
Las llamadas que se encolan tienen un retardo adicional tipico de un TIC.
 +
 
 +
Cuando una llamada entra en cola se define un tiempo máximo en cola (por defecto 5 segundo); si se alcanza ese tiempo se considera llamada desbordada, la aplicación la saca con una etiqueta y sigue con el dialplan que podrá tirarla, podrá derivarla...
 +
 
 +
 
 +
Mdflow se invoca dentro del dialplan del sistema. Por
 +
ejemplo, será la primera línea del dialplan correspondiente a un enlace externo; a la salida
 +
de md flow, este proporcionará una etiqueta, que podrá ser “Ok”, “desborda”, “agujero” o
 +
“error”
 +
El funcionamiento general de md flow es el reflejado en el siguiente diagrama de flujo.
  
[[Archivo:diagrama de flujo motorsal.png|center|800px]]
 
  
Los diferentes estados de un contacto son:
 
{| class="wikitable sortable"
 
|-
 
! 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.
 
|-
 
|Cancelado||300||
 
|-
 
|}
 
  
====Carga de contactos====
+
[[Archivo:mdflow.png|885px |center]]
  
===== Descripción =====
+
Como se puede apreciar en el diagrama de flujo:
 +
 
 +
*mdflow siempre cuenta las llamadas para establecer la tasa de llamadas por segundo.
 +
 
 +
* Solo hace control de flujo si no está en paso.
 +
 
 +
* Solo hace control de flujo si hay congestión (tasa de llamadas por segundo superior a la máxima configurada).
 +
 
 +
* Estando en congestión:
 +
 
 +
 
 +
'''- Si entra una llamada nueva'''
 +
 
 +
Y existe otra encolada para el DNIS se encola en dicha cola.
 +
 
 +
Y no existe cola para el DNIS se crea la cola y encola SI quedan colas disponibles.
 +
 
 +
Si no quedan colas disponibles la llamada sale con etiqueta “agujero”.
 +
 
 +
 
 +
'''- Al respecto de colas'''
 +
 
 +
Una cola se crea cuando hay una llamada con un DNIS no encolado y si existen aún colas disponibles.
 +
 
 +
Una cola se libera de un DNIS cuando no quedan llamadas en cola para ese DNIS.
 +
 
 +
Las colas no tienen una profundidad máxima.
 +
 
 +
Las colas tienen un tiempo de permanencia.
 +
 
 +
Las llamadas se van atendiendo equitativamente en cada cola, todas tienen el mismo peso, saliendo con etiqueta “Ok”
 +
 
 +
 
 +
'''- Al respecto de llamadas'''
 +
 
 +
Una llamada se saca de la cola con etiqueta “desborda” si pasa el máximo tiempo configurado en cola
 +
 
 +
 
 +
'''- Si se produce un error en el sistema las llamadas podrán salir con etiqueta “error”.
  
A continuación se explica la configuración y funcionamiento de la utilidad encargada de asignar contactos a campañas.
 
  
===== Configuración =====
 
  
El archivo de configuración recibe el nombre de '''cargaContactos.pconf.''' Este archivo reside en '''/etc/MDtel.''' El formato se describe en la tabla siguiente. Hay que tener en cuenta que las columnas empiezan a numerarse en 0.
 
  
{| class="wikitable" style="text-align:center;"
 
|-
 
! Parámetro !! Valor !! Obligatorio !! Defecto
 
|-
 
| db|| Nombre de la base de datos|| SI || nimitz
 
|-
 
| dbHost|| Host MySQL || SI || localhost
 
|-
 
| dbPort|| Puerto MySQL || NO || 3306
 
|-
 
| dbUsuario || Usuario de acceso a la base de datos|| SI ||
 
|-
 
| dbClave || Clave del usuario || SI ||
 
|-
 
| rutaContactos || Ruta hasta el archivo de contactos || NO || /var/spool/MDtel/contactos
 
|-
 
| obsoletos || Si vale 1, marcar como obsoletos los contactos anteriores || NO || 0
 
|-
 
| diasCaducidad || Número de dias a partir de los cuales caducarán los contactos || SI ||
 
|-
 
| idCampanna || Número de columna que contiene el ID de la campaña || SI||
 
|-
 
| idLista || Numero de columna que contiene el ID de la lista || SI ||
 
|-
 
| prioridad || Número de columna que contiene la prioridad || NO || Nota: El valor es de 0 a 99. A mayor número mayor prioridad (se le llamará '''ANTES''')
 
|-
 
| tipoTarea|| Número de columna que contiene el tipo de tarea || NO || Nota: los posibles valores de la columna son : <br /> *A: Alta <br /> *M: Modificación <br /> *B: Baja<br /> Por defecto el valor es A
 
|-
 
| codCli || Número de columna del CSV que contiene el código de cliente || SI ||
 
|-
 
| nombreCon || Número de columna del CSV que contiene el nombre || NO ||
 
|-
 
| apellido1 || Número de columna del CSV que contiene el primer apellido|| NO ||
 
|-
 
| apellido2 || Número de columna del CSV que contiene el segundo apellido || NO ||
 
|-
 
| empresa || Número de columna del CSV que contiene la empresa || NO ||
 
|-
 
| direccion1 || Número de columna del CSV que contiene la dirección || NO ||
 
|-
 
| direccion2 || Número de columna del CSV que contiene la dirección 2 || NO ||
 
|-
 
| codPostal || Número de columna del CSV que contiene el código postal || NO ||
 
|-
 
| localidad || Número de columna del CSV que contiene la localidad || NO ||
 
|-
 
| provin || Número de columna del CSV que contiene la provincia || NO ||
 
|-
 
| email || Número de columna del CSV que contiene el email || NO ||
 
|-
 
| valFijo_1 || Número de columna del CSV que contiene el primer número fijo del contacto || SI ||
 
|-
 
| valFijo_2 || Número de columna del CSV que contiene el segundo número fijo del contacto || NO ||
 
|-
 
| valFijo_3 || Número de columna del CSV que contiene el tercer número fijo del contacto || NO ||
 
|-
 
| valFijo_4 || Número de columna del CSV que contiene el cuarto número fijo del contacto || NO ||
 
|-
 
| valMovil_1 || Número de columna del CSV que contiene el primer número móvil del contacto || SI ||
 
|-
 
| valMovil_2 || Número de columna del CSV que contiene el segundo número móvil del contacto || NO ||
 
|-
 
| valMovil_3 || Número de columna del CSV que contiene el tercer número móvil del contacto || NO ||
 
|-
 
| valMovil_4 || Número de columna del CSV que contiene el CUARTO número móvil del contacto || NO ||
 
|-
 
| edad || Número de columna del CSV que contiene la edad || NO ||
 
|-
 
| nOpc1|| Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| nOpc2 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| nOpc3 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| nOpc4 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| nOpc5 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| nOpc6 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| nOpc7 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| nOpc8 || Número de columna del CSV que contiene dato numérico opcional || NO ||
 
|-
 
| cOpc1 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| cOpc2 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| cOpc3 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| cOpc4 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| cOpc5 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| cOpc6 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| cOpc7 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| cOpc8 || Número de columna del CSV que contiene cadena opcional || NO ||
 
|-
 
| Idioma || Idioma del contacto || NO ||
 
|-
 
|}
 
  
===== Funcionamiento =====
 
  
Para ejecutar la utilidad se debe teclear la siguiente orden en la línea de comandos:
 
  
'''cmd# cargaContactos.pl /<ruta hasta el conf>/cargaContactos.pconf <archivo CSV>'''
+
Al respecto de las llamadas que salen con etiqueta “agujero”, cabría pensar que si no
 +
quedan colas disponibles las llamadas con etiqueta agujero serian llamadas candidatas a
 +
ser descartadas a DNIS ocasionales y se les dará prioridad. Téngase en cuenta que en
 +
circunstancias de congestión, las colas estarán típicamente ocupadas por DNIS masivos, y
 +
no por DNIS ocasionales, de manera que es altamente probable que cualquier DNIS
 +
masivo ya tenga cola asignada y que al agujero vayan DNIS ocasionales; todo esto pasa
 +
por realizar un buen dimensionamiento del máximo de colas (que debiera ser muy
 +
parecido al número de DNIS masivos)
 +
 
  
El archivo con los contactos deberá ser un CSV con los campos separados por ';'. La utilidad parsea el archivo conforme a la distribución indicada en la configuración y crea las correspondientes entradas en las tablas '''ACD_CONTACTOS''' y '''ACD_CONTACTOS_CAMPANNAS.'''
 
  
La utilidad crea un log en '''/var/log/cargaContactos.log''' en el que vuelca toda la operativa.
 
Por pantalla se va mostrando un lista con el ID asignado al contacto y el ID de campaña al que se le ha asignado.
 
  
Un ejemplo de fichero de carga de contactos sería el siguiente:
 
  
#
 
# Configuracion de cargaContactos.pconf
 
#
 
# Conexion de base de datos
 
$db='nimitz';
 
$dbHost = 'localhost';
 
$dbPort = '3306';
 
$dbUsuario = 'nimitz';
 
$dbClave = 'LA QUE SEA';
 
$diasCaducidad='300';
 
$rutaGrab = '/var/spool/MDtel/contactos';
 
$idCampanna = '31';
 
$idLista = '32';
 
$obsoletos = 0;
 
$codCli = '1';
 
$nombreCon = '2';
 
$apellido1 = '3';
 
$apellido2 = '4';
 
$empresa = '5';
 
$direccion1 = '6';
 
$direccion2 = '7';
 
$codPostal = '8';
 
$localidad = '9';
 
$provin = '10';
 
$email = '11';
 
$valFijo_1 = '12';
 
$valFijo_2 = '13';
 
$valFijo_3 = '14';
 
$valFijo_4 = '15';
 
$valMovil_1 = '16';
 
$valMovil_2 = '17';
 
$valMovil_3 = '18';
 
$valMovil_4 = '19';
 
$edad = '20';
 
$nOpc1 = '21';
 
$nOpc2 = '22';
 
$nOpc3 = '23';
 
$nOpc4 = '24';
 
$cOpc1 = '25';
 
$cOpc2 = '26';
 
$cOpc3 = '27';
 
$cOpc4 = '28';
 
$prioridad = '29';
 
$tipoTarea = '30';
 
  
====Comportamiento de reprogramaciones de llamadas en función del estado del agente====
+
[[Archivo:mdflow2.png|655px |center]]
  
Se ha preparado la siguiente maqueta:
 
  
Campaña saliente.
 
Cola saliente progresiva.
 
Dos agentes logados en VIVAit Suite.
 
  
En el formulario de la llamada se indica: llamada redirigida
 
Se selecciona el "check dirigida"
 
  
Las posibilidades de prueba son dos: "'''Cualquier agente'''" y "'''Solo agente'''"
 
  
Resultados son los siguientes:
+
==== Proceso de instalación de mdflow en una instalación existente; → como se "añade" mdflow en un VIVAit existente ====
 +
   
 +
El proceso de instalación depende de dos ficheros:
 +
*'''app_mdflow.c''' que se ha de ubicar en el directorio /usr/src/MDtel/asterisk/apps/
 +
*'''MDflow.conf''' que ha de ponerse en /etc/asterisk/
  
{| class="wikitable sortable"
+
Tras poner ambos ficheros en sus respectivos lugares, nos iremos a /usr/src/MDtel/asterisk/ y compilaremos el asterisk make && make install
|-
+
 
| '''Estado del agente''' || '''Modo Cualquier Agente'''|| '''Modo Solo Agente'''
+
Para que el asterisk cargue el nuevo módulo entrarems en la consola de asterisk (asterisk -r) y ejecutaremos '''module load app_mdflow.so'''
|-
 
| '''Agente Preparado''' || Entra llamada a agente|| Entra llamada a agente
 
|-
 
|'''Agente en Pausa'''||Entra llamada a otro agente disponible||Espera a agente y entra llamada.
 
|-
 
|'''Agente Hablando'''||Espera a agente y entra llamada||Espera a agente y entra llamada.
 
|-
 
|'''Agente en Tiempo administrativo'''||Espera a agente y entra llamada||Espera a agente y entra llamada.
 
|-
 
|'''Agente no logado'''||Entra llamada a otro agenete disponible||Consume intento.
 
|-
 
|'''Agente con una pestaña de chat abierta y el otro agente en pausa'''||Entra llamada a otro agente disponible||Espera a agente y entra llamada.
 
|-
 
|'''Agente con dos pestañas de chat abiertas'''||Espera a agente y entra llamada||Espera a agente y entra llamada.
 
|-
 
|}
 
  
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Movilidad ===
 
La movilidad es una función integral de las comunicaciones en la empresa. Cualquier empleado (usuario) es móvil en cierto grado, ya 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 estemos.
 
  
==== Ofrecer movilidad a un usuario ====
+
==== Parámetros de configuración ====
<!--parte daniel-->
 
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 ''VIVA''it'''.  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 [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Documentaci%C3%B3n_de_usuario_VIVAit_Call_3.0#Portal_de_usuario |portal de usuario]]). <br/>Para más información[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Pesta.C3.B1a_Centralita | 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 ''VIVA''it'''.<br/>Para más información[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Asignaci.C3.B3n_de_Permisos_de_Usuario_por_Administrador | ver sección  Portal de administración - General - Usuarios - Permisos a usuarios]]
 
  
  
'''La movilidad permite''' disponer de las extensiones telefónicas empresariales en cualquier lugar. Por
+
*'''Parámetros generales'''
ejemplo, con un ordenador portátil o smartphone en una ubicación remota con conexión a Internet,
 
podríamos tener registrada nuestra extensión remotamente, y así las llamadas hacia/desde nuestra
 
oficina serían enrutadas por Internet hasta el equipo en cuestión sin coste alguno.
 
  
  
<!--parte daniel-->
+
'''- tick_ms:''' duración de un TIC.
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 ''VIVA''it'''. Para más información [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Extensiones | ver sección Portal de administración - VIVAit Call - Dispositivos - Extensiones]]
 
  
==== ¿Cómo funcionan las extensiones? ====
+
'''- estad_interv_seg:''' define intervalo de medida, si bien las informaciones siempre las proporcionará en tasa de llamadas/s.
  
Primeramente el usuario debe tener los ejes apropiados en la tabla '''COM_USUARIOS_APLICACION''' (aplicación centralita).
 
  
La extensión debe de tener ''un teléfono'' y por tanto ''un modelo de teléfono asociado.''
+
*'''Parámetros por flujo'''
  
Es tan simple como especificar '''la extensión, el usuario y la clave de este.'''
 
  
Para corroborar el funcionamiento de esta hay ''dos métodos'':
+
'''-Flujo:''' nombre del flujo (solo para la salida de estadísticas); no conecta con nada en dialplan o similar.
  
'''* CLI asterisk:'''
+
'''-En_paso:''' (0 o 1); si está a 1 solo mide, siempre devuelve OK; si “en_paso” es 0 hay control de flujo.
  
'''mdintz qry * nimitz bd extenEntraUsuarioMovil 25001 20001 1234'''
+
'''-Tasa_sal_seg:''' tasa máxima de salida de llamadas/s configuradas para ese flujo; saldrán ese valor de llamadas por segundo con etiqueta “Ok”.
  
Y como resultado obtenemos lo siguiente:
+
'''-Dnis_max:''' número de colas máximo en ese flujo. Si se configura 1 cola, se comporta como cola única, no se hace caso al DNIS.
  
mdintz Variables:<br/>
+
'''-Dnis_umbral_masivo:''' no vale para control, pero sí para medida; nos define que un DNIS es masivo si hay tantas o más llamadas encoladas que las indicadas en este parámetro; si está solo en paso no se mide porque no hay colas.'''
MdintzIdentif='cms1'<br />
 
MOVIL_TIPO_RESET='10'<br />
 
MOVIL_CAD_RESET='notify_yealink'<br />
 
MdintzRes='OK'
 
  
El usuario con el login numérico 20001 se ha "movido" a la extensión 25001
+
'''-to_desborda_seg:''' Tiempo máximo en cola de una llamada; pasado el tiempo sale
 +
con "desborda"
  
Ahora ''nos quitamos de esa extensión mediante el siguiente comando:''
 
  
'''mdintz qry * nimitz bd extenSaleUsuarioMovil 25001'''
 
  
Resultado del comando:
+
==== Fichero de configuración ====
  
mdintz Variables:<br/>
 
MdintzIdentif='cms1'<br/>
 
MOVIL_TIPO_RESET='10'<br/>
 
MOVIL_CAD_RESET='notify_yealink'<br/>
 
MdintzRes='OK'
 
  
Las pruebas anteriores han sido '''con extensiones con movilidad y con usuario con/sin
+
El fichero de configuración se ubica en '''/etc/Asterisk/MDflow.conf''' ; su contenido por defecto es el
propietario.'''
+
siguiente:
  
Ahora las realizamos '''con extensiones sin movilidad'''
 
  
'''mdintz qry * nimitz bd extenEntraUsuarioMovil 25002 20001 1234'''
 
  
Obteniendo:
+
[general]
 +
; Periodo de tiempo para medidas de tasa de llamadas
 +
tick_ms=500
 +
; Periodo de tiempo para calculos estadísticos
 +
estad_interv_seg=10
 +
; Máximo 9 flujos ([flujo_1] a [flujo_9])
 +
; Tiene que empezar en [flujo_1] y ser correlativos
 +
[flujo_1]
 +
; Nombre asignado al flujo. Se usa en las salidas de los comandos
 +
flujo=Cen_Inicio_SIP
 +
; "En paso"
 +
; 1: No se controla el flujo (siempre etiqueta OK), sólo se mide
 +
; 0: Se controla la tasa de llamadas y se hacen medidas
 +
en_paso=0
 +
; Tasa máxima de llamadas (expresada en llamadas/seg) que etiquetadas OK
 +
; Para un tick de 500 ms, este valor debe ser par
 +
tasa_sal_seg=4
 +
; Número máximo de dnis a encolar. Resto se etiquetan como AGUJERO
 +
dnis_max=2
 +
; Umbral para el número de llamadas encoladas en un dnis, que hace que
 +
; éste sea calificado como "masivo"
 +
; El valor mínimo es 2
 +
dnis_umbral_masivo=8
 +
; Límite de tiempo en segundos, transcurrido el cuál se etiqueta DESBORDA
 +
to_desborda_seg=5
 +
[flujo_2]
 +
flujo=Cen_Inicio_TrunkSip
 +
en_paso=1
 +
tasa_sal_seg=20
 +
dnis_max=100
 +
dnis_umbral_masivo=10
 +
to_desborda_seg=5
 +
[flujo_3]
 +
flujo=Cen_TrunkInternos
 +
en_paso=1
 +
tasa_sal_seg=20
 +
dnis_max=100
 +
dnis_umbral_masivo=10
 +
to_desborda_seg=5
  
mdintz Variables:<br/>
+
==== Ejemplo claro de invocación de mdflow desde dialplan y posterior tratamiento en función de las etiquetas de salida ====
MdintzIdentif='cms1'<br/>
 
MdintzRes='movil_error_datos'
 
  
Como era lo previsible no nos deja "movernos" a esa extensión ya que no tiene movilidad.
+
Por defecto el MDflow se pondrá en los siguientes ficheros de Asterisk:
<!--
+
* ext_InicioLlamada_ExtSIP.conf 
'''<u>Si un usuario ya se ha movido a una extensión no se puede mover a otra si no es deslogandose de esta antes.</u>'''
+
* ext_InicioLlamada_TrunkSIP.conf 
 +
* ext_TrunkInternos.conf
 +
ya que son los diferentes contextos de entrada de llamadas.
  
Esta línea se comenta porque se ha preparado el sistema para que los ususarios se puedan logar en una nueva extensión y el sistema lo deslogue de la primera a la que se movió. La variable que controla este funcionamiento es MD_AUTODES, con dos posibles valores:
+
;--------------------------------------------------------------------------------
0, para que el usuario deba deslogarse de una extensión para logarse en otra.
+
[Cen_TrunkInternos]
1, para que sea el sistema el que deslogue automátiamente al usuario cuando cambia de una extensión de movilidad a otra.
+
;--------------------------------------------------------------------------------
-->
+
;--------------------------------------------------------------------------------
 +
exten => _[*#%0-9a-zA-Z].,1,NoOp(MDENTTR_X****EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
 +
 +
  same =>                  n,Set(__ENR_PEER_ORIGEN=${CHANNEL(peername)})
 +
 +
 +
;-------------------------
 +
;  Control de flujo
 +
;-------------------------
 +
  same =>                  n,Set(HORAINI=${EPOCH})
 +
  same =>                  n,MDflow(3,${EXTEN})
 +
  same =>                  n,Log(NOTICE,MDFLOWTRUNKINT**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**PEER=${ENR_PEER_ORIGEN}**CID=${CALLERID(NUM)}*)
 +
  same =>                  n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 +
  same =>                  n,Set(GROUP()=TrunkInternos)
 +
  same =>                  n,Set(valor=)
 +
  same =>                  n,ExecIf($["${LlamTrunkInternos}" = ""]?Set(valor=300):Set(valor=${LlamTrunkInternos}))
 +
  same =>                  n,ExecIf($[${GROUP_COUNT(TrunkInternos)} > ${valor}]?HangUp(1))
 +
  same =>                  n,Log(NOTICE,MDGROUPTRUNKINT**GROUPCOUNT=${GROUP_COUNT(TrunkInternos)}**PEER=${ENR_PEER_ORIGEN}**CID=${CALLERID(NUM)}*)
 +
 +
[Cen_Inicio_TrunkSip]
 +
;exten => _[*#%0-9a-zA-Z].,1,NoOp(MDINITRUNKSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
 +
exten => _[*#%0-9].,1,NoOp(MDINITRUNKSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
 +
 +
  ;      TTipoIdEnrutamiento = (
 +
  ;              tipoIdEnrutamiento_ninguno=0,  // quitar no sabemos
 +
  ;              tipoIdEnrutamiento_dispositivo=10,   
 +
  ;              tipoIdEnrutamiento_cola=20   
 +
  ;      );
 +
 +
  same =>            n,Set(ENR_PEER_ORIGEN=)
 +
  same =>            n,Set(__ENR_TIPO_ORIGEN=10)
 +
  same =>            n,Set(__ENR_ORIGEN=${ID_DISPOSITIVO})
 +
  ;same =>            n,Set(__SPAN_IN=)
 +
  ;same =>            n,Set(__CANAL_IN=)
 +
  ;same =>            n,Set(__TIPO_LLAMADA=${TIPOLLAMADAENT})
 +
 +
  same =>            n,NoOp(ENR_TIPO_ORIGEN=${ENR_TIPO_ORIGEN}***ENR_ORIGEN=${ENR_ORIGEN})
 +
 +
;-------------------------
 +
;  Control de flujo
 +
;-------------------------
 +
  same =>          n,Set(HORAINI=${EPOCH})
 +
  same =>          n,MDflow(1,${EXTEN})
 +
  same =>          n,Log(NOTICE,MDFLOWTRUNKSIP**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**CID=${CALLERID(NUM)}*)
 +
  same =>          n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 +
  same =>          n,Set(GROUP()=${CHANNEL(peername)})
 +
  same =>          n,Set(valor=)
 +
  same =>          n,ExecIf($["${maxLlam}" = ""]?Set(valor=300):Set(valor=${maxLlam}))
 +
  same =>           n,ExecIf($[${GROUP_COUNT(${CHANNEL(peername)})} > ${valor}]?HangUp(1))
 +
  same =>          n,Log(NOTICE,MDFLOWTRUNKSIP**GROUPCOUNT=${GROUP_COUNT(${CHANNEL(peername)})}**PEER=${CHANNEL(peername)}**CID=${CALLERID(NUM)}*)
 +
  
'''<u>Si un usuario ya se ha movido a una extensión y se mueve a otra, el sistema lo deslogará de la primera para logarlo en la segunda.</u>'''
+
'''Esto desaparecera cuando el dialplan sea unificado'''
 +
'''ahora es necesartio para que pase el ucid del acd'''
  
'''mdintz qry * nimitz bd extenEntraUsuarioMovil 21000 20001 1234'''
+
 
+
[Cen_Inicio_SIP]
Con salida:
+
exten => _[*#%0-9].,1,NoOp(MDINIEXTENSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
 
+
  mdintz Variables:<br/>
+
  same =>            n,Set(ENR_PEER_ORIGEN=)
MdintzIdentif='cms1'<br/>
+
  same =>            n,Set(__ENR_TIPO_ORIGEN=10)
  MOVIL_EXTEN='25001'<br/>
+
  same =>            n,Set(__ENR_ORIGEN=${ID_DISPOSITIVO})
  MDintzRes='movil_ya_login'
+
  same =>            n,Set(__SPAN_IN=)
 +
  same =>            n,Set(__CANAL_IN=)
 +
  ;same =>            n,Set(__TIPO_LLAMADA=${TIPOLLAMADASAL})
 +
 +
  ;-------------------------
 +
  ; Control de flujo
 +
  ;-------------------------
 +
  same =>           n,Set(HORAINI=${EPOCH})
 +
  same =>          n,MDflow(2,${EXTEN})
 +
  same =>          n,Log(NOTICE,MDFLOWEXTSIP**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**CID=${CALLERID(NUM)}*)
 +
  same =>           n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 +
   
 +
 +
  same =>           n,NoOp(ENR_TIPO_ORIGEN=${ENR_TIPO_ORIGEN}***ENR_ORIGEN=${ENR_ORIGEN})
 +
   
 +
'''Para recibir el UCID de otros vivait (move,meet)'''
  
'''* Dialplan'''
 
  
Para llamar a la función de movilidad hay que marcar el '''9992.'''
 
  
Nota.- Para comprobar que se realiza todo correctamente habría que mirar las trazas de Asterisk
+
==== Comandos básicos de diagnóstico ====
  
<br><br>
+
  Comandos básicos (dentro de la consola asterisk)
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
 +
*'''mdflow show stats''': permite ver las medidas de cada flujo configurando que etsa tomando el mdflow, cuantas colas se estan utilizando, cuanteas llamadas pasan, cuantas desbordan, cuantas son agujero, cuantos dnis masivos hay...
  
 +
Preproduccion-Corp0*CLI>  mdflow show stats
 +
 +
mdflow Estadística global:
 +
  activo=1
 +
  supervEjecutando=1
 +
  tickMs=500
 +
  estadIntervSeg=10
 +
  flowNum=3
  
 +
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
 +
  flowInd=1 enPaso=0
 +
  flowInd=1 tasaUltIntervMs=10003
 +
  flowInd=1 tasaUltEntra=0
 +
  flowInd=1 tasaUltSaleOk=0
 +
  flowInd=1 tasaUltSaleDesborda=0
 +
  flowInd=1 tasaUltSaleAgujero=0
 +
  flowInd=1 tasaUltSaleError=0
 +
  flowInd=1 llamUltColaMax=0
 +
  flowInd=1 dnisUltColasUsoMax=0
 +
  flowInd=1 dnisUltMasivoMax=0
 +
  flowInd=1 retardoUltMedioMs=0
  
 +
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
 +
  flowInd=2 enPaso=1
 +
  flowInd=2 tasaUltIntervMs=10003
 +
  flowInd=2 tasaUltEntra=0
 +
  flowInd=2 tasaUltSaleOk=0
 +
  flowInd=2 tasaUltSaleDesborda=0
 +
  flowInd=2 tasaUltSaleAgujero=0
 +
  flowInd=2 tasaUltSaleError=0
 +
  flowInd=2 llamUltColaMax=0
 +
  flowInd=2 dnisUltColasUsoMax=0
 +
  flowInd=2 dnisUltMasivoMax=0
 +
  flowInd=2 retardoUltMedioMs=0
  
 +
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
 +
  flowInd=3 enPaso=0
 +
  flowInd=3 tasaUltIntervMs=10003
 +
  flowInd=3 tasaUltEntra=0
 +
  flowInd=3 tasaUltSaleOk=0
 +
  flowInd=3 tasaUltSaleDesborda=0
 +
  flowInd=3 tasaUltSaleAgujero=0
 +
  flowInd=3 tasaUltSaleError=0
 +
  flowInd=3 llamUltColaMax=0
 +
  flowInd=3 dnisUltColasUsoMax=0
 +
  flowInd=3 dnisUltMasivoMax=0
 +
  flowInd=3 retardoUltMedioMs=0
  
 +
*'''mdflow show dnis''': permite saber cuales son los DNIS masivos de la centralita
  
=== Desvío por calendario ===
+
Preproduccion-Corp0*CLI> mdflow show dnis
 
 
 
 
Se ha desarrollado una nueva funcionalidad para VIVAit Call que permite
 
establecer desvíos de extensiones y usuarios en base a una programación
 
horaria.
 
Una vez puesta en marcha esta funcionalidad , el orden de desvíos de usuarios o
 
extensión en VIVAit Call será:
 
  
 +
mdflow Estado global:
 +
  activo=1
 +
  supervEjecutando=1
 +
  tickMs=500
 +
  estadIntervSeg=10
 +
  flowNum=3
  
* Primero se atiende si el usuario o extensión tiene desvío incondicional a
+
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
mensajería.
+
  flowInd=1 enPaso=0
 +
  flowInd=1 dnisColaNum=1 no se controlan dnis
  
* En segundo lugar se comprueba si dispone de desvío programado, y se
+
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
encuentra en una franja horaria con desvío activo.
+
  flowInd=2 enPaso=1
 +
  flowInd=2 dnisColaNum=2
 +
  flowInd=2 dnisUltMasivoMax=0
  
* Posteriormente se atiende si el usuario o extensión tiene desvío
+
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
incondicional.
+
  flowInd=3 enPaso=0
 +
  flowInd=3 dnisColaNum=1 no se controlan dnis
  
* Posteriormente se tratarán resto de desvíos condicionales (por no
+
*'''mdflow show config''' Permite ver la configuracion de los distintos flujos
conectado, por ocupado o por no contesta).
 
  
 +
Preproduccion-Corp0*CLI> mdflow show config
  
 +
mdflow Configuración global:
 +
  activo=1
 +
  supervEjecutando=1
 +
  tickMs=500
 +
  estadIntervSeg=10
 +
  estadFases=20
 +
  flowNum=3
  
 +
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
 +
  flowInd=1 enPaso=0
 +
  flowInd=1 llamSalTick=1
 +
  flowInd=1 llamSalSeg=2
 +
  flowInd=1 dnisColaNum=1
 +
  flowInd=1 dnisUmbralMasivo=8
 +
  flowInd=1 llamDesbordaToSeg=5
  
 +
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
 +
  flowInd=2 enPaso=1
 +
  flowInd=2 llamSalTick=1
 +
  flowInd=2 llamSalSeg=2
 +
  flowInd=2 dnisColaNum=2
 +
  flowInd=2 dnisUmbralMasivo=10
 +
  flowInd=2 llamDesbordaToSeg=5
  
[[Archivo:Captura de pantalla de 2022-11-16 07-58-38.png|center|900px]]
+
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
 
+
  flowInd=3 enPaso=0
 +
  flowInd=3 llamSalTick=1
 +
  flowInd=3 llamSalSeg=2
 +
  flowInd=3 dnisColaNum=1
 +
  flowInd=3 dnisUmbralMasivo=8
 +
  flowInd=3 llamDesbordaToSeg=5
  
  
 +
*'''mdflow reload:''' Recarga mdflow leyendo de nuevo el fichero de configuración
 +
MDlow.conf; se puede realizar con la plataforma en funcionamiento normal pero no
 +
se recomienda realizarlo en momentos de alto tráfico; los cambios de configuración
 +
se aplican tras un comando “mdflow reload”
  
Los componentes principales de la arquitectura son:
+
Preproduccion-Corp0*CLI> mdflow reload
  
  
*'''Servidor de calendarios''' : Para definir las programaciones de desvíos se ha utilizado una solución de servidor estándar de calendarios; se ha optado por el servidor Baikal, por disponer de todas las funcionalidades necesarias y disponer de BBDD Mysql (especialmente adecuado en entornos VIVAit)
+
*'''mdflow debug:''' Muestra estadísticas por pantalla a intervalos regulares; no se
 +
recomienda su uso sistemático.
  
 +
Preproduccion-Corp0*CLI> mdflow debug
  
*'''Intz-Nimitz''' : El proceso de enrutamiento de VIVAit consultará en cada llamada el estado de desvío programado al servidor de calendarios; esta consulta solo se realizará en caso de que dicha extensión o usuario tenga activo dicho desvío y un calendario asignado; por defecto los desvíos programados estarán desactivados en todas las extensiones y usuarios para proteger las prestaciones del sistema.
+
==== Comandos básicos de diagnóstico ====
  
 +
El MDflow está activo si los comandos anteriormente mencionados devuleven datos, si no devuelven nada es que ha ocurrido un error al cargar el módulo en asterisk. Los comandos de diagnostico empleados son los mismos que hemos mencionado anteriormente más el '''mdflow debug on''', que muestra lo mismo que el '''mdflow show stats''' pero lo hace para cada llamada que pase por la parte del dialplan que hemos mencionado antes.
  
*'''Frontales''' : Para la administración por parte de los usuarios de los desvíos programados se ofrecen los siguientes frontales:
 
  
- '''Portal de usuario:''' Cada usuario podrá definir desvíos programados en el mismo entorno en el que define el resto de desvíos.
 
  
- '''Portal de administración de VIVAit''': Desde dicho portal se podrán gestionar por un administrador los desvíos programados de      usuarios y extensiones de todo el sistema.
+
==== Asignación de flujos ====
  
- '''Portal de administración de Baikal''': Desde dicho portal se podrán gestionar el servidor de calendarios.
 
  
- '''Entorno estándar de gestión de calendarios:''' desde un entorno estándar de gestión de calendarios (p. ej Thunderbird), y con protocolo CalDav, se podrán realizar gestiones de todos los calendarios de un entorno VIVAit. Este entorno sería una alternativa al portal de administración (no de usuario), debido a que:
+
Por defecto, en la instalación irán definidos los siguientes flujos:
  
1.   Se deberá configurar dicho entorno para acceder con el usuario de administración de calendarios.
+
*'''Flujo 1 (trunksip):''' Flujo que analiza las llamadas que vienen de los trunksip.
+
Típicamente son las llamadas que provienen de los operadores en los Gatewais.
2.  Se podrán ver todos los calendarios del sistema (de todas las extensiones y usuarios).
+
Está configurado en el contexto Cen_InicioLlamada_TrunkSip.
  
 +
*'''Flujo 2 (Extensiones):''' Flujo para las llamadas originadas por las extensiones SIP
 +
registradas en el nodo. Está configurado en el contexto Cen_InicioLlamada_SIP.
  
Por defecto no será necesario montar un nuevo nodo de VIVAit, para el despliegue de Baikal se montará donde esté ubicado el portal de administración de VIVAit.
+
*'''Flujo 3 (trunkInternos):''' Flujo para las llamadas que provienen de otros nodos.
 +
Está configurado en el contexto Cen_TrunkInternos
  
  '''Baikal se ubicará por defecto en el mismo nodo en el que se encuentre el portal de administración de VIVAit.'''
 
  
  
 +
Estos son flujos genéricos que irán definidos en la instalación, se podrán generar mas si la
 +
instalación lo requiere, por ejemplo, si la instalación tiene primarios se podrá definir un
 +
flujo para las llamadas que vienen por el contexto Cen_InicioLlamada_Dahdi.
  
  
 +
El significado del flujo 3 es diferente según el tipo de nodo en que se está ejecutando. Por
 +
ejemplo, en una instalación de 2 nodos, un nodo Gateway y un nodo de procesamiento, el
 +
flujo 3 en el nodo gateways estará midiendo el tráfico que manda el nodo de
 +
procesamiento hacia el exterior del sistema, típicamente las llamadas salientes al sistema,
 +
en cambio, el mismo flujo en el nodo de procesamiento, estará indicando las llamadas que
 +
vienen del Gateway, típicamente las llamadas entrantes del exterior.
  
===== Baikal =====
 
  
Como se ha indicado en el apartado de arquitectura, VIVAit Call utilizará un servidor de calendarios Baikal para almacenar la información referente a desvíos programados de usuarios y extensiones.
+
Esto es mucho menos evidente en instalaciones con varios nodos, con trunk hacia
 +
proveedores externos en los nodos de procesamiento, etc.
  
Baikal es un servidor CalDAV ligero. Los datos se almacenan en una base de datos Mysql (diferente a la base de datos de VIVAit).
 
  
En el caso de su uso en VIVAit Call:
 
  
* Existirá un único usuario administrador de Baikal que podrá crear los calendarios (desde los frontales anteriormente descritos).
+
==== Configuración de cola única ====
 
* Los calendarios y los desvíos podrán ir asociados tanto a usuarios como a extensiones.
 
 
* Cada extensión o usuario de VIVAit tiene un calendario asignado que se crea automáticamente en Baikal al programar el primer evento desde el portal de administración de VIVAit o desde el portal de usuario.
 
  
  
'''Si se instala Vivait 3.6 desde repositorio , habría que realizar los siguientes pasos en Mysql:'''
+
  La configuración de colas es útil cuando el número de DNIS es finito y queremos priorizar
 +
los números llamados menos frecuentemente sobre los masivos.
  
'''Configuración de Mysql'''
+
Cuando el número de DNIS es muy grande la configuración mediante colas no ofrece un
 +
funcionamiento óptimo, las colas serán ocupadas cada una con un DNIS diferente y todos
 +
los DNIS que no tengan cola libre saldrán por la salida “agujero”.
  
 +
Para tener un control del flujo en estas situaciones se ha creado el concepto de cola única,
 +
su comportamiento es que todas las llamadas van a la misma cola y no hay llamadas que
 +
obtengan la salida “agujero” y por tanto todas tienen la misma prioridad.
  
La instalación de Baikal implica disponer de un servidor Mysql operativo; será necesario crear una base de datos de nombre “baikal” con un usuario “baikal” que será el que utilizarán los frontales para la interacción con el servidor de calendarios:
+
Este comportamiento se obtiene poniendo el parámetro de configuración del flujo
 +
dnis_max con el valor 1 (dnis_max=1).
 +
 
 +
Un ejemplo típico de utilización de este tipo de configuración sería en el flujo 3 de los
 +
nodos gateways. Este flujo tendrá las llamadas que el resto de los nodos envían al exterior
 +
y los DNIS no coincidirían en su mayoría.
  
Baikal usa su propia base de datos (diferente a la de VIVAit)
+
==== MDflow y las trazas ====
  
 +
El diaplan devulelve trazas del MDflow mdiante mensajes NOTICE, por lo que filtrando en el full de asterisk por la cadena MDFLOW irán apareciendo los diferentes retornos de ejecucion del MDFLOW (cuanto tiempo ha tardado en ejecutarse, qué devuelve el MDflow para esa llamada (agujero, desbordada, ok o error))
  
'''1.Configuración inicial Mysql'''
 
  
  
Si la instalación la estamos realizando sobre un nodo que no tenía instalado Mysql y lo hemos instalado durante este proceso de instalación en el paso 3 del punto anterior, deberemos configurar Mysql para su integración con VIVAit.
+
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
'''Acceder a Mysql y cambiar clave de root'''
+
=== Estadísticas en '''''<span style="color:#144F9B">VIVA</span>'''''it Call ===
-------------------------
 
mysql_secure_installation
 
mysql -u root -p
 
mysql> ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘ LACLAVEDEVIVAITPARAMYSQL ’;
 
-------------------------
 
  
*'''No realizar la configuración inicial de Mysql si el nodo ya dispone de base de datos VIVAit'''
+
[[:medio:Estadisticas_VIVAIT_ Call.pdf|Como configurar estadísticas para '''''VIVA'''''it Call ]]
  
  
'''2.Configuración de Base de datos Baikal'''
+
<br><br>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Funcionalidades específicas en VIVAit ]][[#Funcionalidades específicas en VIVAit | Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
 +
== Diagnósticos y operaciones básicas en '''''VIVA'''it'' ==
 +
<br><br>
  
'''Crear base de datos de baikal'''
+
=== Arranque y apagado de la plataforma ===
-------------------------
+
<br><br>
mysql> create database baikal;
 
-------------------------
 
'''2. Crear usuario baikal'''
 
-------------------------
 
create user 'baikal'@'localhost' identified by 'ivivabaikal';
 
-------------------------
 
'''3. Asignar privilegios a usuario baikal
 
-------------------------
 
grant all on baikal.* to ‘baikal'@'localhost’;
 
-------------------------
 
  
 +
En general el arranque y apagado de cada nodo de una plataforma '''''VIVA'''''it 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
  
'''Configuración de Baikal'''
 
  
 +
El orden de arranque de la plataforma deberá ser:
 +
# En primer lugar arrancar el nodo con la base de datos de tiempo real
 +
# Una vez finalizado el arranque del punto 1, arrancar el nodo con la base de datos de réplica
 +
# Una vez finalizado el arranque del punto 2, arrancar el resto de nodos en cualquier orden
  
Una vez instalado, podemos comprobar que el servidor Baikal está operativo accediendo a su URL de gestión en:
 
  
'''http://<IPServer>/baikal/html/'''
+
Al respecto del orden de apagado de nodos, es el siguiente:
 +
# 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
 +
# Una vez apagados totalmente todos los nodos del punto 1, apagaremos el nodo (o nodos) con bases de datos de réplica
 +
# Una vez apagados totalmente todos los nodos del punto 2, se apagará el nodo con la base de datos de tiempo real
  
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
Tras acceder deberemos configurarlo adecuadamente, realizando los siguientes pasos:
 
  
  
'''Crear la conexión entre VIVA it y Baikal'''
+
=== Cluster '''''VIVA'''it'' ===
 +
<br><br>
  
Tener correctamente configurado en la tabla WEB_CONFIGURACION el usuario y clave de la base de datos de Baikal; esto permitirá configurar Baikal (usuario, calendarios…) sin tener que acceder a su interfaz de administración.
+
==== Introducción a cluster  ====
 
+
<br><br>
Se configura:
+
Un clúster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad, de tal forma que el conjunto es visto como un único ordenador.
 
+
<br><br>
* Host
+
De un clúster se espera que presente combinaciones de los siguientes servicios:
* Puerto (defecto 3306)
+
<br><br>
* Driver con el que se conecta (Mysql)
+
: # Alto rendimiento <br>
* Usuario de BBDD Baikal
+
: # Alta disponibilidad<br>
* Clave de BBDD Baikal
+
: # Balanceo de carga <br>
 
+
: # Escalabilidad
 
+
<br><br>
 
+
<div style="
'''A nivel de base de datos'''
+
  text-align:right;
 
+
  margin-top:20px;
 
+
  padding:8px;
[[Archivo:calendario1.png|center|700px]]
+
  border:1px solid #ccc;
 
+
  background-color:#f9f9f9;
 
+
  border-radius:6px;
Donde:
+
  display:inline-block;
 +
">
 +
[[File:flecha_verde.png|20px|link=#Cluster VIVAit]][[#Cluster VIVAit| Volver arriba]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
 +
</div>
 +
<div style="
 +
  text-align:right;
 +
  margin-top:20px;
 +
  padding:8px;
 +
  border:1px solid #ccc;
 +
  background-color:#f9f9f9;
 +
  border-radius:6px;
 +
  display:inline-block;
 +
">
 +
[[File:casa.png|20px|link=#]][[# | Página Principal]]
 +
</div>
 +
<br><br>
  
* '''MySQL host''' - Nombre del host de mysql.
+
==== Funcionamiento en cluster ====
* '''MySQL database name''' - Nombre de la base de datos creada.
+
<br><br>
* '''MySQL username''' - Nombre de usuario de acceso.
 
* '''MySQL password''' - Contraseña de acceso.
 
  
  
 +
Tal y como esta definido el cluster de MDtel, este comprueba conectividad con la otra máquina que lo forma y con un punto de confianza. Si la máquina no tiene conectividad con la otra y si con el punto de confianza es que el servidor está vivo, mientas que si no tengo conectividad ni con la otra máquina ni con el punto de confianza es que el muerto soy yo, por lo que balanceo.
  
'''En ajuste de sistema'''
+
Por lo que las máquinas balancean en los casos siguientes:
 +
Tal y como esta definido el cluster de MDtel, este comprueba conectividad con la otra máquina que lo forma y con un punto de confianza. Si la máquina no tiene conectividad con la otra y si con el punto de confianza es que el servidor está vivo, mientas que si no tengo conectividad ni con la otra máquina ni con el punto de confianza es que el muerto soy yo, por lo que balanceo.
  
 +
Por lo que las máquinas balancean en los casos siguientes:
  
[[Archivo:calendario2.png|center|500px]]
+
* Todo lo que tenga que ver con la red, es decir, caída de la tarjeta de red, apagado de la máquina, corte en la red..
  
Donde:
+
Y no balancea en los siguientes:
  
+
* No balancea en los demás casos, es decir, todo lo que tenga que ver con procesos de una máquina (caída asterisk, base de datos, intz-nimitz)
* '''Zona horaria''' – Seleccionar la región que corresponda (típicamente Europe/Madrid).
 
 
* '''Habilitar o deshabilitar CardDav o CalDav''' – Es necesario habilitar CalDav, y deshabilitar CardDav (no se va a utilizar).
 
  
* '''Enviar invitación al correo del remitente''' – Dejar vacío.
 
 
* '''Seleccionar el tipo de autenticación WebDav''' – Hay tres opciones (Digest, Basic y Apache), la opción que hay que seleccionar es Digest.
 
 
* '''Contraseña del administrador''' – Esta contraseña se configura solo para entrar al entorno de Baikal.
 
  
 +
===== Píldoras =====
  
  
 +
====== Prevenir que un nodo vuelva a tomar el control tras volver a estar operativo ======
  
'''Desde Baikal + Cliente Caldav'''
 
  
 +
Cuando queremos evitar que un recurso vuelva al nodo en el que estaba originalmente tras la recuperación del nodo, ejecutaremos la siguiente orden.
  
 +
pcs resource defaults resource-stickiness=100
  
La administración desde Baikal solo será necesaria en caso de no poder utilizar los frontales desarrollados para la gestión de la funcionalidad.
+
====== Borrar un recurso ======
  
 +
pcs resource delete DRBDFs
  
Consideraciones relevantes:
+
====== Sincronización del drbd ======
  
*Desde la administración de Baikal si podremos crear:
+
Para sincronizar el drdb tras un fallo tenemos que determinar cuál es el nodo que tiene los datos buenos y cuál es el que vamos a sobrescribir sus datos
  
 +
En el nodo que vamos a sobrescribir los datos ejecutaremos los siguientes comandos.
  
- usuarios (en caso de la funcionalidad en VIVAit solo usuario único de VIVAit).
+
drbdadm secondary all
 +
drbdadm disconnect all
 +
drbdadm invalidate all
 +
drbdadm connect all
  
- calendarios (existirá uno por extensión o usuario).
 
  
 +
Y en el nodo que tiene los datos correctos.
  
*Desde la administración de Baikal no podremos gestionar eventos de calendario; para ello deberemos usar un cliente CalDav (p. ej Thunderbird).
+
drbdadm connect all
  
  
'''Ejemplo de una consulta de intz-Nimitz a Baikal en los ficheros log:'''
+
====== Mover un recurso de nodo ======
  
 +
Para mover un recurso de nodo utilizaremos el siguiente comando.
  
Ante una consulta de Intz-Nimitz a Baikal, los resultados devueltos en el fichero de log (/var/log/intz-nimitz.log) por Baikal pueden ser:
+
pcs resource move IP-ASTER
 +
pcs resource clear IP-ASTER
  
 +
Esto crea restricciones locales para evitar que el recurso vuelva a este nodo (Puede tener prioridad de ejecución en este nodo y haría que volviera a este nodo automáticamente al estar online).
  
1. En caso de existir una programación de desvío, Baikal devolverá los campos asunto y location de la programación, que podrán ser usados en los procesos posteriores de tratamiento de la llamada en caso de ser necesario:
+
La restricción que crea banea el nodo para este recurso, si queremos quitar esta restricción creada.
  
 +
pcs resource clear DRBDfsASTER
  
 +
<span style="color:#f32100">Mirar si existe alguna manera de mover un recurso sin que se creen estas restricciones locales</span>
  
[[Archivo:calendario5.png|center|700px]]
 
  
 +
====== Habilitar/deshabilitar recursos ======
  
 +
Los comandos para habilitar y deshabilitar recursos en un nodo son
  
2. En caso de no existir programación de desvío, devolverá vacío:
+
Si especificamos un tiempo, pcs esperara este tiempo y retornara 0 si el recurso a parado o 1 si el recurso no ha parado en el tiempo especificado.
  
 +
pcs resource disable resource_id [--wait[=n]]
  
 +
Si especificamos un tiempo, pcs esperara este tiempo y retornara 0 si el recurso a arrancado o 1 si el recurso no ha arrancado en el tiempo especificado.
  
[[Archivo:captura6.png|center|700px]]
+
pcs resource enable resource_id [--wait[=n]]
 +
pcs config show
 +
pcs resource cleanup resource_id
 +
pcs resource clear
 +
pcs resource refresh
  
=== Grabación ===
+
Borra los Failed Actions de un recurso:
  
La grabación en '''''VIVA'''''it Call está diseñada para ser lo mas flexible posible.
+
pcs resource cleanup [recurso]
  
====Configuración====
+
====== Notas sincronismo ======
  
Si deseamos grabar, debemos activar que alguno de los dispositivos/elementos que intervienen en la llamada se grabe.
+
Si tenemos este fallo:
  
Estos dispositivos/elementos son:
+
root@VC-PROC-SUMA-ALC-02:/tmp# cat /proc/drbd
 +
version: 8.4.10 (api:1/proto:86-101)
 +
srcversion: 7922D81D3881494EB149253
 +
  0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
 +
root@VC-PROC-SUMA-ALC-01:~# cat /proc/drbd
 +
version: 8.4.10 (api:1/proto:86-101)
 +
srcversion: 7922D81D3881494EB149253
 +
  0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown  r-----
  
* 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á.
+
En el nodo principal
  
Al configurar un nodo existen cuatro campos que intervienen en la grabación.
+
drbdadm connect all
  
''''Grabador''''
+
En el nodo secundario
  
Se configura en el portal en la sección general/nodos.
+
drbdadm -- --discard-my-data connect all
  
Este campo corresponde con el campo [[BD.COM_NODOS#B_ES_GRABADOR|B_ES_GRABADOR]] de la tabla [[BD.COM_NODOS|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.
+
********* En secundario: **************
 +
drbdadm secondary drbdASTER
 +
drbdadm disconnect drbdASTER
 +
drbdadm -- --discard-my-data connect drbdASTER
  
Es un campo booleano los posibles valores en el portal son si/no y en la base de datos 1/0.
+
********* En primario: ****************
 +
drbdadm primary drbdASTER
 +
drbdadm disconnect drbdASTER
 +
drbdadm connect drbdASTER
  
  
 +
====== Configuración para KVM ======
  
''''Modo grabación infraestructura''''
+
'''vi /etc/multipath.conf'''
 +
-----------------------------
 +
defaults {
 +
    user_friendly_names yes
 +
}
 +
blacklist {
 +
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]"
 +
devnode "^vd[b-z]?[0-9]"
 +
devnode "vda"
 +
devnode "vda1"
 +
devnode "^drbd[0-9]*"
 +
}
  
<!--Su configuración se realiza en el portal, en la sección general/nodos.
+
systemctl restart multipathd.service
  
Este campo define como está configurada la infraestructura, este campo existe por compatibilidad con '''''VIVA'''''it suite y para poder configurar la grabación bajo demanda.
+
'''vi /etc/corosync/corosync.conf'''
 +
------------------------------------
 +
totem {
 +
    version: 2
 +
    cluster_name: CLmdtel
 +
    transport: knet
 +
    crypto_cipher: aes256
 +
    crypto_hash: sha256
 +
    token: 12000
 +
}
 +
nodelist {
 +
    node {
 +
        ring0_addr: nodo-vc-01
 +
        name: nodo-vc-01
 +
        nodeid: 1
 +
    }
 +
    node {
 +
        ring0_addr: nodo-vc-02
 +
        name: nodo-vc-02
 +
        nodeid: 2
 +
    }
 +
}
 +
quorum {
 +
    provider: corosync_votequorum
 +
    two_node: 1
 +
}
 +
logging {
 +
    to_logfile: yes
 +
    logfile: /var/log/corosync/corosync.log
 +
    to_syslog: yes
 +
    timestamp: on
 +
}
  
Este campo corresponde con el campo [[BD.COM_NODOS#E_MODO_GRABACION_INFRAESTRUCTURA|E_MODO_GRABACION_INFRAESTRUCTURA]] de la tabla [[BD.COM_NODOS|COM_NODOS]], Este campo usa los valores del enumerado BD.ENUM.TModoGrabacionInfraestructura|TModoGrabacionInfraestructura]].
+
systemctl restart corosync
  
La formula que se seguiría para ver si una llamada se graba en ese nodo es:
+
'''Revisar que están arrancados después de reinicar:'''
{|
+
  Corosync Pacemaker multipath
|
 
|-
 
|
 
  (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,...).-->
 
[[:medio:Modo grabacion infraestructura grabacion por petición.pdf|Modo grabación de infraestructura-Graba por petición]]
 
  
 +
===== Ejemplo de cluster con mysql y asterisk =====
  
''''Grabar enrutamiento''''
+
En este ejemplo vamos a crear un cluster que maneje mysql y Asterisk como servicios separados.
  
Se configura en el portal en la sección general/nodos.
+
Para lograr esto vamos a necesitar que el drbd maneje dos particiones separadas y tener dos ip flotantes, una para cada servicio.
  
Este campo define si van a grabar las llamadas que se enruten en este nodo.
+
====== Requisitos previos ======
  
Campo [[BD.COM_NODOS#E_ENRU_GRABAR|E_ENRU_GRABAR]] de la tabla [[BD.COM_NODOS|COM_NODOS]] que usa los valores del enumerado [[BD.ENUM.TTipoEnruGrabar|TTipoEnruGrabar]].
+
Los requisitos previos antes de comenzar la instalación del cluster son:
  
 +
• Nodos correctamente actualizados (update/upgrade).
  
''''RecordCentral''''
+
• Conexión a internet.
  
Se configura en el portal en la sección general/nodos.
+
• NTP configurado.
  
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.
+
'''''Creación de las particiones e instalación y configuración del drbd'''''
  
====Vivait Tracker====
+
====== Particionado (En los 2 nodos) ======
<!--
 
::<span style="background:#FFAA00"> DANIEL LA ÚNICA REFERENCIA A VIVAIT TRACKER EN LA DOCUMENTACIÓN "Vivait supervisor" QUE TENGO DICE LO SIGUIENTE. </span>
 
-->
 
Desde '''''VIVA'''''it Supervisor,  que es la aplicación dirigida a Supervisores, ofrece la posibilidad de supervisar y gestionar grupos ACD, agentes, asignaciones, prioridades,etc. Se puede obtener acceso directo a las aplicaciones de grabación ('''''VIVA'''''it tracker)
 
  
<!--
+
Para la instalación de los dos recursos drbd necesitamos tener dos particiones que vamos a crear añadiendo un disco duro en cada una de las máquinas. Lo añadimos mediante el Gestor de Máquinas Virtuales de la máquina 999-sgestion. Los tamaños serán los siguientes:
::<span style="background:#FFAA00"> DANIEL FIN EXPLICACIÓN. </span>
 
  
 +
• Corporativo -> 50Gb
  
::<span style="background:#FFAA00"> DANIEL De la documentacion creada por ivan. </span>
+
• BDTR -> 100Gb
-->
 
Esquematico actual del proyecto tracker
 
[[Archivo:Esquematico_tracker_1.jpg|center]]
 
  
 +
Lo siguiente es crear la partición en cada servidor:
  
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.
+
[[File:cluster1.png|400px]]
  
3º Si la ubicación de la grabación es remota, entra en escena el proxy. Es el que realiza la petición.
+
Vamos a utilizar la herramienta parted seguido del dispositivo que queremos particionar. En este caso el espacio que vamos a particionar está en el dispositivo /dev/vdc.
  
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.
+
parted /dev/vdc
  
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.
+
Una vez ejecutado el comando entraremos en una consola de la aplicación.
<!--
 
::<span style="background:#FFAA00"> DANIEL De la documentación creada por ivan. </span>
 
-->
 
Esquematico actual del proyecto tracker
 
[[Archivo:Esquematico_tracker_2_https.jpg|center]]
 
  
 +
Ejecutando el comando
  
1º El tracker web llama al web service Remote login para iniciar sesión (comunicación https) y determinar si tiene permisos para la escucha y descarga de grabaciones. Se elimina el proxy
+
(parted) print free
  
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.
+
Obtenemos las particiones que tiene el dispositivo actualmente y el espacio libre que disponemos.
  
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)
+
[[File:cluster2.png|400px]]
  
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).
+
En este ejemplo disponemos de 50Gb de espacio libre que es el que vamos a utilizar para las 2 particiones necesarias.  
  
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.
+
Lanzamos el comando mkpart para realizar la primera partición que será para mysql.
  
[[#Grabación_(Vivait_Tracker)| Volver arriba]]
+
(parted) mkpart
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Enrutamiento ===
+
El nombre que le vamos a dar a la partición es '''DRBD-MYSQL'''.
 +
El Tipo de sistema de ficheros '''ext4'''.
 +
Luego nos pedirá el principio de la partición, en el ejemplo vamos a comenzar en 198Gb y vamos a finalizar en 550Gb.
  
[[Archivo:Enrutamiento.png|885px |center]]
 
  
 +
[[File:cluster3.png|400px]]
 +
 +
Realizaremos la segunda partición volviendo a ejecutar el mismo comando
 +
 +
(parted) mkpart
 +
 +
 +
En este ejemplo el nombre para esta partición será '''DRBD-ASTER''' el tipo '''ext4''' y le daremos el espacio restante del disco.
 +
 +
[[File:cluster4.png|400px]]
  
==== Enfoque inicial ====
 
  
[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Enfoque_inicial Acceso]
+
Para ver el resultado de las particiones podemos ejecutar el comando.
  
==== Funcionamiento ====
+
lsblk
El proceso de enrutamiento, como vimos en el esquemático, se compone de dos fases:
 
  
# Preenrutameinto, que se encarga de tratar todas las llamadas
+
[[File:cluster5.png|400px]]
# 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.
+
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
  
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.
+
====== Gestión de particiones con LVM (En los 2 nodos) ======
  
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
 
  
 +
Crearemos las 2 particiones lvm en los 2 servidores con los siguientes comandos.
  
A partir de los datos de entrada básicos anteriores se pueden deducir los siguientes valores:
+
En este ejemplo las particiones que queremos utilizar son /dev/sda5 para mysql y /dev/sda6 para Asterisk, esto podrá cambiar en las instalaciones.
* 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
 
  
 +
[[File:cluster6.png|400px]]
  
Los datos de salida globales del proceso de enrutamiento (pdSale) son:
+
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
* 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]):
+
====== Instalación y configuración del drbd (En los 2 nodos) ======
* 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.
 
  
=====Fase preenrutamiento =====
+
Instalaremos el paquete drbd8-utils. En Ubuntu 20.04 drbd-utils
  
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.
+
apt-get install drbd-utils
  
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.
+
Ahora tenemos que editar los archivos de configuración del drbd, estos archivos están en el directorio /etc/drbd.d
  
Los datos de salida de la fase de preenrutamiento:
+
Primero editaremos la configuración general, el archivo global_common.conf y le añadiremos en la sección net lo siguiente.
* 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.
+
vi /etc/drbd.d/global_common.conf
  
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.
+
[[File:cluster7.png|400px]]
  
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:
+
Si tenemos problemas con los backup que realiza Vodafone en las máquinas virtuales añadir:
* 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".
+
  net {
 +
                # protocol timeout max-epoch-size max-buffers
 +
                # connect-int ping-int sndbuf-size rcvbuf-size ko-count
 +
                # allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
 +
                # after-sb-1pri after-sb-2pri always-asbp rr-conflict
 +
                # ping-timeout data-integrity-alg tcp-cork on-congestion
 +
                # congestion-fill congestion-extents csums-alg verify-alg
 +
                # use-rle
 +
                protocol C;
 +
                after-sb-0pri discard-zero-changes;
 +
                after-sb-1pri discard-secondary;
 +
                after-sb-2pri disconnect;
 +
        }
  
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.
+
Ó (nota Centro de Servicios)
  
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.
+
net {
 +
    ping-int 30;
 +
    timeout 20;
 +
    connect-int 30;
 +
    protocol C;
 +
    after-sb-0pri discard-older-primary;
 +
    after-sb-1pri discard-secondary;
 +
    after-sb-2pri disconnect;
 +
}
  
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.  
+
Para configurar los recursos tenemos que crear en el directorio /etc/drbd.d un archivo para cada recurso. Estos archivos deben tener la extensión res.
  
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:
+
Creamos el archivo para el recurso mysql con el nombre drbd-mysql.res.
* "=" 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.
+
vi drbd-mysql.res
  
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.
+
El contenido del archivo es:
  
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.
+
resource drbdMYSQL {
Con este mecanismo de N_CONTA y N_UMBRAL, se pretende facilitar el discriminar a los llamantes reincidentes, cuando sea necesario.
+
  on VC-CORP-Cetelem-Mad-cl1 {
 
+
    device /dev/drbd0;
Un proceso periódico externo debe encargarse de poner a cero o decrementar el valor de N_CONTA.
+
    disk /dev/mapper/vg_DRBD--MYSQL-lv_DRBD--MYSQL;
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.
+
    address 10.10.10.10:7788;
 
+
    meta-disk internal;
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. 
+
  on VC-CORP-Cetelem-Mad-cl2 {
* "+" el nuevo destino es igual al de entrada al proceso, con los caracteres a continuación de "+" como prefijo. 
+
    device /dev/drbd0;
* "-" se quita el número de caracteres que se indica a continuación de "-". 
+
    disk /dev/mapper/vg_DRBD--MYSQL-lv_DRBD--MYSQL;
* "_" 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. 
+
    address 10.10.10.11:7788;
* cualquier otro valor del primer carácter determina que es una constante que sustituye el valor a la entrada.
+
    meta-disk internal;
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.
 
  
===== Fase de enrutamiento en casos en que el destino no es externo =====
+
Ahora haremos lo mismo para el recurso Asterisk, el archivo se llamará: drbd-aster.res.
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).  
+
vi drbd-aster.res
  
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.
+
y el contenido será el siguiente:
  
En el resto de tipos de destino, sólo se prevé una ruta que puede incluir o no un enlace internodal.  
+
resource drbdASTER {
 +
  on VC-CORP-Cetelem-Mad-cl1 {
 +
    device /dev/drbd1;
 +
    disk /dev/mapper/vg_DRBD--ASTER-lv_DRBD--ASTER;
 +
    address 10.10.10.10:7789;
 +
    meta-disk internal;
 +
  }
 +
  on VC-CORP-Cetelem-Mad-cl2 {
 +
    device /dev/drbd1;
 +
    disk /dev/mapper/vg_DRBD--ASTER-lv_DRBD--ASTER;
 +
    address 10.10.10.11:7789;
 +
    meta-disk internal;
 +
  }
 +
}
  
 +
'''Realizamos este mismo proceso en el otro nodo del cluster.''' Los ficheros de configuración los podemos copiar de un nodo a otro.
  
  
===== Fase de enrutamiento en el caso de destino externo =====
+
====== Configuración de /etc/hosts (En los 2 nodos) ======
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:
+
Tenemos que configurar correctamente los nombres de las máquinas en el archivo /etc/hosts.
* 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.
+
vi /etc/hosts
  
Una vez que un registro es válido, se descartan todos los registros cuyo C_DESTINO_ENT_PREF es diferente del primero seleccionado.  
+
El contenido de este archivo variará según la configuración, para este ejemplo.
  
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:
+
[[File:cluster8.png|400px]]
  
CALLER_NAME_nn: Si C_CALLER_NAME está vacío, se propaga el valor de entrada. En caso contrario, se sustituye.  
+
:{|
 +
|
 +
127.0.0.1 localhost
 +
#127.0.1.1 VC-CORP-mdtelMad-cl1
  
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:
+
128.1.4.201 VC-CORP-mdtel-Mad-cl1
* "=" o cadena vacía, el nuevo CALLER_NUM_nn es igual al de entrada al proceso.
+
  128.1.4.202  VC-CORP-mdtel-Mad-cl2
* "+" 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:
+
10.10.10.10 nodo-vc-01
* "=" o cadena vacía, el nuevo destino es igual al de entrada al proceso.  
+
10.10.10.11    nodo-vc-02
* "+" 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.
+
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== 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
+
====== Creación de los recursos en drbd. (En los 2 nodos) ======
:* 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:
+
Ahora crearemos los recursos en drbd, primero el de mysql
:* De manera directa entre terminal A y terminal B
 
:* De manera indirecta, a través de los nodos A y B
 
  
[[Archivo:ancho de banda.png|700px]]
+
drbdadm create-md drbdMYSQL
  
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:
+
Y después el de Asterisk
  
{| class="wikitable"
+
drbdadm create-md drbdASTER
|-  
 
! 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:
+
Y arrancamos el drbd en el nodo.
:* '''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
+
/etc/init.d/drbd start
  
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
+
Crearemos las carpetas donde se montarán los recursos del drbd
  
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
+
mkdir HDmysql
  
 +
touch /HDmysql/sinMontar
  
=== MDflow ===
+
mkdir HDaster
 +
touch /HDaster/sinMontar
  
MDflow es una aplicación Asterisk que se basa en la unidad de medida TIC (un TIC, por defecto, corresponde a 500ms, pero es configurable).
+
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
  
Los términos que usaremos para la explicación de la funcionalidad y que son relevantes
+
====== Sincronización del drbd. (En 1 nodo) ======
para comprender, implantar, mantener e interpretar la misma son:
 
  
 +
Este proceso solo se debe realizar en un nodo, Con este comando sincronizaremos los 2 discos y el nodo desde donde lo lancemos será el que aporte los datos en la sincronización. Como no hay nada en los discos todavía es igual desde que nodo se ejecute.
  
 +
drbdadm -- --overwrite-data-of-peer primary all
  
* '''Nodo VIVAit''': Un nodo VIVAit es cualquier elemento dado de alta en el sistema
 
como tal, que contiene un proceso de conmutación de voz Asterisk incorporado. Un
 
cluster activo/pasivo son dos ordenadores, pero un solo nodo. Típicamente existen
 
nodos de tres tipos (si bien los dos primeros pueden combinarse en uno solo):
 
  
- Nodo de registro para telefonía corporativa
+
Podemos ir viendo cual es el porcentaje que lleva realizado con el siguiente comando.
  
- Nodo Gateway
+
watch -n 1 'cat /proc/drbd'
  
- Nodo de registro ACD
+
Al final de la sincronización debería salir algo como esto.
  
* '''TIC''': Unidad básica de medida de tiempo de md flow; por defecto el valor es
+
[[File:cluster9.png|400px]]
500ms; nótese que los valores devueltos por el sistema siempre estarán medidos
 
en segundos, aunque internamente use el TIC como base de tiempos.
 
  
* '''Flujo:''' Cada uno de los nueve elementos de medida y control que podrán
 
establecerse por nodo VIVAit.
 
  
* '''Medición:''' Capacidad de md flow para determinar el número de llamadas por
 
segundo que se están estableciendo en un determinado flujo. Nótese que no se
 
hace referencia a duración de las mismas o medición de llamadas previamente
 
establecidas
 
  
* '''Control:''' Capacidad de md flow para limitar el número de llamadas por segundo
+
===== Pacemaker, corosync y pcs =====
que se están estableciendo en un determinado flujo
 
  
* '''Tasa de llamadas por segundo:''' Cantidad de llamadas que se están
 
estableciendo por segundo en un nodo VIVAit. Nótese que no se hace referencia a
 
duración de las mismas o llamadas previamente establecidas
 
  
* '''DNIS: Dialed Number Identification Servic'''e; número destino de una llamada
+
Ahora deberíamos tener en los 2 nodos un mysql configurado y corriendo, un Asterisk configurado y corriendo y 2 particiones de drbd (una para mysql y otra para Asterisk) sincronizadas, aunque no están montadas en ningún sitio.
  
* '''Congestión''': Estado del nodo VIVAit cuando se sobrepasa una determinada tasa
 
de llamadas por segundo; el mecanismo md flow entrará en funcionamiento cuando
 
el sistema entre en estado de congestión.
 
  
* '''Llamada desbordada:''' Llamada que en el tratamiento de la congestión se
+
====== Parar y deshabilitar los servicios. (en los 2 nodos) ======
considera apta para ser descartada (si bien el tratamiento se definirá en dialplan, el
 
funcionamiento lógico previsto es descartarla).
 
  
* '''Llamada a agujero:''' Llamada que en el tratamiento de la congestión se considera
+
Todos los servicios que vayan a ser controlados por el pacemaker tienen que estar parados y el arranque deshabilitado para que el pacemaker los arranque y los pare en el nodo que corresponda.
ha de progresar por no quedar colas de DNIS disponibles (se explicará y justificará
 
el funcionamiento más adelante).
 
  
* '''Mdflow en paso:''' md flow puede ser utilizado para:
+
/etc/init.d/asterisk stop
 +
/etc/init.d/mysql stop
 +
/etc/init.d/drbd stop
 +
systemctl disable mysql
 +
systemctl disable drbd
 +
systemctl disable asterisk
  
- Solo medir . En este caso md flow se encontrará en paso.
 
  
- Medir y realizar control de flujo.
+
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
  
* '''DNIS masivo:''' Un DNIS con alta tasa de llamadas por segundo.
 
  
* '''DNIS ocasional:''' Un DNIS con baja tasa de llamadas por segundo.
+
====== Instalación de los paquetes necesarios. (En los 2 nodos) ======
  
 +
Instalamos los paquetes necesarios.
  
 +
apt install corosync pacemaker pcs
  
  
 +
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
  
  
La aplicación está diseñada para '''controlar el flujo de llamadas entrantes''' → '''El sistema cuenta llamadas en cada periodo TIC.'''
+
====== Configuramos la clave del usuario hacluster. (En los 2 nodos) ======
  
El módulo permite difinir distintas cajas de medida y control ('''FLUJO''').
+
Al instalar los paquetes se crea un usuario hacluster que tenemos que ponerle clave
  
Se pueden definir n cajas y ubicarlas en Asterisk (por ejemplo en un enlace externo, una caja que agrupe todos los enlaces, en los enlaces interiores y en extensiones).
+
passwd hacluster
  
Cada una de las cajas, o flujos, mide y controla la tasa de llamadas en cada TIC → Se mostrará en llamadas/segundo.
+
La clave deberá ser la misma en los 2 nodos. '''ivivacluster'''
  
El '''FLUJO'''mide lo que está pasando en un determinado punto del dialplan; un ejemplo claro será la primera línea de éste, cuando se crea una llamada de un enlace externo.
 
  
El '''FLUJO'''permite controlar y medir, y está pensado para enviar información a Zbbix.
+
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
  
Desde el punto de vista del Dialplan, se trata de una aplicación con dos parámetros:
 
*Que caja se utiliza (número del 1 al 9).
 
*DNIS que permite controlar para que destino queremos hacer el control de flujo.
 
  
Para encolar internamente cada '''FLUJO''' tiene un número de colas definidas y cada DNIS está en una cola.
+
====== Autentificación del pcs. (En 1 nodo) ======
Cuando entra una llamada y se invoca a la caja con el DNIS de esa llamada, o se crea nueva cola, o se encola en una existente para ese DNIS si la hubiera.
 
El número de colas deberá ser el numero de DNIS masivo.
 
  
Una cola de un DNIS se libera de ese DNIS cuando queda vacia (por eso los ocasionales no tendrán cola habitualmente y los masivos si).
+
En uno de los nodos ejecutamos el siguiente comando para autenticar el pcs.
  
Cuando entra una llamada si el DNIS tiene cola se encola, si no tiene y hay libres se crea una nueva y si no hay colas libres (maximo configurable), la llamada pasa. (se asume que las masivas quedarán en colas y que las ocasionales pasarán).
+
pcs host auth nodo-vc-01 nodo-vc-02 -u hacluster -p ivivacluster
  
Para sacar llamadas (desencolar), saco una de cada cola (fair queues). No podemos configurar que de unas colas se atiendan mas llamadas que de otras.
+
El resultado del comando tiene que ser:
  
En control de flujo se indica para cada caja la tasa de entrada en llamadas/s.
+
<span style="color:#007bca">VC-CORP-Cetelem-Mad-cl1: Authorized
 +
VC-CORP-Cetelem-Mad-cl2: Authorized</span>
  
El mecanismo de control de flujo entra en funcionamiento cuando el sistema entra en '''congestión'''.
+
====== Creación y configuración del cluster. (En 1 nodo) ======
  
Las llamadas que se encolan tienen un retardo adicional tipico de un TIC.
+
Ahora creamos el cluster e incluimos las maquinas que lo van a componer y le asignamos un nombre (este nombre no puede exceder de 15 caracteres).
  
Cuando una llamada entra en cola se define un tiempo máximo en cola (por defecto 5 segundo); si se alcanza ese tiempo se considera llamada desbordada, la aplicación la saca con una etiqueta y sigue con el dialplan que podrá tirarla, podrá derivarla...
+
pcs cluster destroy (en caso de no encontrar /var/lib/pcsd/known-hosts y después lanzar pcs host auth noco-vc-01 nodo-vc-02  -h hacluster -p ivivacluster)
  
 +
pcs cluster setup CLmutuaint  nodo-vc-01 nodo-vc-02 --start --enable --force
  
Mdflow se invoca dentro del dialplan del sistema. Por
+
Si todo ha ido bien la salida debería ser algo como esto.
ejemplo, será la primera línea del dialplan correspondiente a un enlace externo; a la salida
 
de md flow, este proporcionará una etiqueta, que podrá ser “Ok”, “desborda”, “agujero” o
 
“error”
 
El funcionamiento general de md flow es el reflejado en el siguiente diagrama de flujo.
 
  
 +
[[File:cluster10.png|500px]]
  
 +
Lo habilitamos '''''en todos los nodos'''''
  
[[Archivo:mdflow.png|885px |center]]
+
pcs cluster enable --all
  
Como se puede apreciar en el diagrama de flujo:
+
La salida será:
  
*mdflow siempre cuenta las llamadas para establecer la tasa de llamadas por segundo.
+
<span style="color:#007bca">VC-CORP-CDS-MAD-01: Cluster Enabled
 +
VC-CORP-CDS-MAD-02: Cluster Enabled</span>
  
* Solo hace control de flujo si no está en paso.
+
Arrancamos el cluster '''en todos los nodos'''
  
* Solo hace control de flujo si hay congestión (tasa de llamadas por segundo superior a la máxima configurada).
+
pcs cluster start --all
  
* Estando en congestión:
 
  
 +
[[File:cluster11.png|500px]]
  
'''- Si entra una llamada nueva'''
+
Comprobamos que todo está correcto con el siguiente comando:
  
Y existe otra encolada para el DNIS se encola en dicha cola.
+
Nos mostrara el estado del cluster.
  
Y no existe cola para el DNIS se crea la cola y encola SI quedan colas disponibles.
+
[[File:cluster12.png|700px]]
  
Si no quedan colas disponibles la llamada sale con etiqueta “agujero”.
 
  
 +
En la salida del comando, vemos que STONITH (Shoot The Other Node In The Head) esta activado, pero no hay dispositivos configurados.
  
'''- Al respecto de colas'''
+
Quitamos el STONITH.
  
Una cola se crea cuando hay una llamada con un DNIS no encolado y si existen aún colas disponibles.
+
pcs property set stonith-enabled=false --force
  
Una cola se libera de un DNIS cuando no quedan llamadas en cola para ese DNIS.
 
  
Las colas no tienen una profundidad máxima.
+
También deshabilitaremos la política de quorum. Un cluster tiene quorum cuando más de la mitad de los nodos están online. Pacemaker por defecto para todos los servicios si no hay quorum, esto no tiene mucho sentido en un cluster de 2 nodos.
  
Las colas tienen un tiempo de permanencia.
+
pcs property set no-quorum-policy=ignore --force
  
Las llamadas se van atendiendo equitativamente en cada cola, todas tienen el mismo peso, saliendo con etiqueta “Ok”
 
  
 +
Vamos a ver la lista de propiedades del cluster para ver que hemos deshabilitado todo correctamente.
  
'''- Al respecto de llamadas'''
+
pcs property list
  
Una llamada se saca de la cola con etiqueta “desborda” si pasa el máximo tiempo configurado en cola
 
  
 +
[[File:cluster13.png|500px]]
  
'''- Si se produce un error en el sistema las llamadas podrán salir con etiqueta “error”.
 
  
  
 +
====== Creación de las IP flotantes (En 1 nodo) ======
  
 +
Ahora vamos a crear las 2 direcciones ip flotantes para que la conexión se realice a la maquina correcta en cada caso, esta ip balanceara entre los diferentes nodos para dar acceso a los servicios en el nodo en el que estén activos.
  
 +
Creamos la IP para el mysql.
  
 +
pcs resource create IP-MYSQL ocf:heartbeat:IPaddr2 ip=128.1.4.205 nic=eno1:0 cidr_netmask=16 op monitor interval=60s
  
 +
Y la IP para el Asterisk
  
Al respecto de las llamadas que salen con etiqueta “agujero”, cabría pensar que si no
+
pcs resource create IP-ASTER ocf:heartbeat:IPaddr2 ip=128.1.4.207 nic=eno1:1 cidr_netmask=16 op monitor interval=60s
quedan colas disponibles las llamadas con etiqueta agujero serian llamadas candidatas a
 
ser descartadas a DNIS ocasionales y se les dará prioridad. Téngase en cuenta que en
 
circunstancias de congestión, las colas estarán típicamente ocupadas por DNIS masivos, y
 
no por DNIS ocasionales, de manera que es altamente probable que cualquier DNIS
 
masivo ya tenga cola asignada y que al agujero vayan DNIS ocasionales; todo esto pasa
 
por realizar un buen dimensionamiento del máximo de colas (que debiera ser muy
 
parecido al número de DNIS masivos)
 
  
 +
Comprobamos el estado del cluster.
 +
 +
pcs status
  
 +
Nos mostrará los nuevos recursos creados y nos indicará en que nodo han sido arrancados.
  
  
 +
[[File:cluster14.png|600px]]
  
  
[[Archivo:mdflow2.png|655px |center]]
 
  
 +
====== Configuración del drdb. (En 1 nodo) ======
  
  
 +
La configuración de DRBD en Pacemaker implica que creemos varios recursos que se ejecutaran a la vez, para ello, utilizaremos una opción de pcs que nos permite encolar varios comandos y ejecutarlos al mismo tiempo. Estos comandos serán ejecutados únicamente en un nodo.
  
 +
Primero ejecutaremos los comandos necesarios para la creación del drbd para mysql.
  
==== Proceso de instalación de mdflow en una instalación existente; → como se "añade" mdflow en un VIVAit existente ====
+
pcs cluster cib drbd_mysql_cfg
   
+
pcs -f drbd_mysql_cfg resource create DRBDmysql ocf:linbit:drbd drbd_resource=drbdMYSQL op monitor interval=60s
El proceso de instalación depende de dos ficheros:
+
pcs -f drbd_mysql_cfg resource master DRBDmysqlClone DRBDmysql master-max=1 master-node-max=1 clone-max=2 clone-node-max=1  notify=true
*'''app_mdflow.c''' que se ha de ubicar en el directorio /usr/src/MDtel/asterisk/apps/
+
pcs -f drbd_mysql_cfg resource promotable DRBDmysql promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1  notify=true
*'''MDflow.conf''' que ha de ponerse en /etc/asterisk/
+
pcs cluster cib-push drbd_mysql_cfg
  
Tras poner ambos ficheros en sus respectivos lugares, nos iremos a /usr/src/MDtel/asterisk/ y compilaremos el asterisk make && make install
+
Y lo mismo para el drbd de asterisk.
  
Para que el asterisk cargue el nuevo módulo entrarems en la consola de asterisk (asterisk -r) y ejecutaremos '''module load app_mdflow.so'''
+
pcs cluster cib drbd_aster_cfg
 +
pcs -f drbd_aster_cfg resource create DRBDaster ocf:linbit:drbd drbd_resource=drbdASTER op monitor interval=60s
 +
pcs -f drbd_aster_cfg resource promotable DRBDaster promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1  notify=true
 +
pcs cluster cib-push drbd_aster_cfg
 +
pcs cluster cib drbd_aster_cfg
 +
pcs cluster cib-push drbd_aster_cfg
  
  
 +
Miraremos el estado del cluster
  
==== Parámetros de configuración ====
+
pcs status
  
 +
El resultado debería de mostrar que los recursos del drbd están creado y cuál es el nodo primario (master) y cuál es el nodo secundario (slave) para ambos recursos.
  
 +
[[File:cluster15.png|700px]]
  
*'''Parámetros generales'''
 
  
 +
====== Montar las particiones del drbd. (En 1 nodo) ======
  
'''- tick_ms:''' duración de un TIC.
+
Formatearemos las particiones del drbd.
 +
 
 +
mkfs.ext4 /dev/drbd1
 +
mkfs.ext4 /dev/drbd0
  
'''- estad_interv_seg:''' define intervalo de medida, si bien las informaciones siempre las proporcionará en tasa de llamadas/s.
+
Una vez finalizado el proceso la pantalla mostrará a siguiente información (para cada comando).
  
 +
[[File:cluster16.png|700px]]
  
*'''Parámetros por flujo'''
 
  
 +
Ahora crearemos el recurso para montar la partición de mysql en el directorio que creamos.
  
'''-Flujo:''' nombre del flujo (solo para la salida de estadísticas); no conecta con nada en dialplan o similar.
+
Vamos a crear restricciones para asegurarnos que los recursos estén todos en el nodo correcto y que arrancan en orden.
  
'''-En_paso:''' (0 o 1); si está a 1 solo mide, siempre devuelve OK; si “en_paso” es 0 hay control de flujo.
+
Vamos a configurar que la partición se monte en el nodo que sea master que la ip flotante este en este nodo y arranque después de haber montado la partición.
  
'''-Tasa_sal_seg:''' tasa máxima de salida de llamadas/s configuradas para ese flujo; saldrán ese valor de llamadas por segundo con etiqueta “Ok”.
+
pcs cluster cib fs_mysql_cfg
 +
pcs -f fs_mysql_cfg resource create DRBDfsMYSQL Filesystem device="/dev/drbd0" directory="/HDmysql" fstype="ext4"
 +
pcs -f fs_mysql_cfg constraint colocation add DRBDfsMYSQL with DRBDmysqlClone INFINITY with-rsc-role=Master
 +
pcs -f fs_mysql_cfg constraint order promote DRBDmysqlClone then start DRBDfsMYSQL
 +
pcs -f fs_mysql_cfg constraint colocation add IP-MYSQL with DRBDfsMYSQL INFINITY
 +
pcs -f fs_mysql_cfg constraint order DRBDfsMYSQL then IP-MYSQL
 +
pcs cluster cib-push fs_mysql_cfg
 +
pcs status
  
'''-Dnis_max:''' número de colas máximo en ese flujo. Si se configura 1 cola, se comporta como cola única, no se hace caso al DNIS.
+
La salida mostrará lo siguiente:
  
'''-Dnis_umbral_masivo:''' no vale para control, pero sí para medida; nos define que un DNIS es masivo si hay tantas o más llamadas encoladas que las indicadas en este parámetro; si está solo en paso no se mide porque no hay colas.'''
+
[[File:cluster17.png|700px]]
  
'''-to_desborda_seg:''' Tiempo máximo en cola de una llamada; pasado el tiempo sale
+
Nos indica que el Filesystem está creado y montado en el nodo nodo-vc-01.
con "desborda"
 
  
 +
Ahora haremos lo mismo para la partición de Asterisk.
  
 +
pcs cluster cib fs_aster_cfg
 +
pcs -f fs_aster_cfg resource create DRBDfsASTER Filesystem device="/dev/drbd1" directory="/HDaster" fstype="ext4"
 +
pcs -f fs_aster_cfg constraint colocation add DRBDfsASTER with DRBDasterClone INFINITY with-rsc-role=Master
 +
pcs -f fs_aster_cfg constraint order promote DRBDasterClone then start DRBDfsASTER
 +
pcs -f fs_aster_cfg constraint colocation add IP-ASTER with DRBDfsASTER INFINITY
 +
pcs -f fs_aster_cfg constraint order DRBDfsASTER then IP-ASTER
 +
pcs cluster cib-push fs_aster_cfg
 +
pcs status
  
==== Fichero de configuración ====
+
Vemos que ya tenemos las 2 particiones montadas.
  
 +
[[File:cluster18.png|700px]]
  
El fichero de configuración se ubica en '''/etc/Asterisk/MDflow.conf''' ; su contenido por defecto es el
 
siguiente:
 
  
 +
======  Copiar datos de Asterisk a partición drbd. (En nodo 1) ======
  
 +
Esto hay que realizarlo en el nodo en el que está montada la partición drbd para asterisk. Estará montado en la carpeta /HDaster
  
  [general]
+
  cd /HDaster/
  ; Periodo de tiempo para medidas de tasa de llamadas
+
  tar -zcvf etc-asterisk.tgz /etc/asterisk
  tick_ms=500
+
  tar -zxvf etc-asterisk.tgz
  ; Periodo de tiempo para calculos estadísticos
+
  rm etc-asterisk.tgz
  estad_interv_seg=10
+
  tar -zcvf var-lib-asterisk.tgz /var/lib/asterisk
  ; Máximo 9 flujos ([flujo_1] a [flujo_9])
+
  tar -zxvf var-lib-asterisk.tgz
  ; Tiene que empezar en [flujo_1] y ser correlativos
+
  rm var-lib-asterisk.tgz
  [flujo_1]
+
  tar -zcvf usr-lib-asterisk.tgz /usr/lib/asterisk
  ; Nombre asignado al flujo. Se usa en las salidas de los comandos
+
  tar -zxvf usr-lib-asterisk.tgz
  flujo=Cen_Inicio_SIP
+
  rm usr-lib-asterisk.tgz
  ; "En paso"
+
  tar -zcvf var-spool-asterisk.tgz /var/spool/asterisk
  ; 1: No se controla el flujo (siempre etiqueta OK), sólo se mide
+
  tar -zxvf var-spool-asterisk.tgz
  ; 0: Se controla la tasa de llamadas y se hacen medidas
+
  rm var-spool-asterisk.tgz
  en_paso=0
+
 
; Tasa máxima de llamadas (expresada en llamadas/seg) que etiquetadas OK
+
====== Borrar los directorios de asterisk y crear enlaces simbólicos. (En los 2 nodos) ======
  ; Para un tick de 500 ms, este valor debe ser par
+
 
  tasa_sal_seg=4
+
Borraremos los directorios y crearemos los enlaces simbólicos necesarios.
  ; Número máximo de dnis a encolar. Resto se etiquetan como AGUJERO
+
 
dnis_max=2
+
 
  ; Umbral para el número de llamadas encoladas en un dnis, que hace que
+
  rm -rf /etc/asterisk
; éste sea calificado como "masivo"
+
  ln -s /HDaster/etc/asterisk /etc/asterisk
; El valor mínimo es 2
+
 
dnis_umbral_masivo=8
+
  rm -rf /var/lib/asterisk
; Límite de tiempo en segundos, transcurrido el cuál se etiqueta DESBORDA
+
  ln -s /HDaster/var/lib/asterisk /var/lib/asterisk
to_desborda_seg=5
+
 
[flujo_2]
+
  rm -rf /usr/lib/asterisk
flujo=Cen_Inicio_TrunkSip
+
  ln -s /HDaster/usr/lib/asterisk /usr/lib/asterisk
en_paso=1
 
tasa_sal_seg=20
 
dnis_max=100
 
dnis_umbral_masivo=10
 
  to_desborda_seg=5
 
  [flujo_3]
 
flujo=Cen_TrunkInternos
 
  en_paso=1
 
  tasa_sal_seg=20
 
dnis_max=100
 
  dnis_umbral_masivo=10
 
  to_desborda_seg=5
 
  
==== Ejemplo claro de invocación de mdflow desde dialplan y posterior tratamiento en función de las etiquetas de salida ====
+
rm -rf /var/spool/asterisk
 +
ln -s /HDaster/var/spool/asterisk /var/spool/asterisk
  
Por defecto el MDflow se pondrá en los siguientes ficheros de Asterisk:
 
* ext_InicioLlamada_ExtSIP.conf 
 
* ext_InicioLlamada_TrunkSIP.conf 
 
* ext_TrunkInternos.conf
 
ya que son los diferentes contextos de entrada de llamadas.
 
  
;--------------------------------------------------------------------------------
+
====== Copiar datos de mysql a partición drbd. (En 1 nodo) ======
[Cen_TrunkInternos]
+
 
;--------------------------------------------------------------------------------
+
Esto hay que realizarlo en el nodo en el que está montada la partición drbd para mysql. Estará montado en la carpeta /HDmysql
;--------------------------------------------------------------------------------
+
 
exten => _[*#%0-9a-zA-Z].,1,NoOp(MDENTTR_X****EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
+
  cd /HDmysql/
+
  tar -zcvf var-lib-mysql.tgz /var/lib/mysql
  same =>                  n,Set(__ENR_PEER_ORIGEN=${CHANNEL(peername)})
+
  tar -zxvf  var-lib-mysql.tgz
   
+
  tar -zcvf etc-mysql.tgz /etc/mysql
+
  tar -zxvf etc-mysql.tgz
;-------------------------
+
 
;  Control de flujo
+
 
;-------------------------
+
====== Borrar los directorios de mysql y crear enlaces simbólicos. (En los 2 nodos) ======
  same =>                  n,Set(HORAINI=${EPOCH})
 
  same =>                  n,MDflow(3,${EXTEN})
 
  same =>                  n,Log(NOTICE,MDFLOWTRUNKINT**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**PEER=${ENR_PEER_ORIGEN}**CID=${CALLERID(NUM)}*)
 
  same =>                  n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 
  same =>                  n,Set(GROUP()=TrunkInternos)
 
  same =>                  n,Set(valor=)
 
  same =>                  n,ExecIf($["${LlamTrunkInternos}" = ""]?Set(valor=300):Set(valor=${LlamTrunkInternos}))
 
  same =>                  n,ExecIf($[${GROUP_COUNT(TrunkInternos)} > ${valor}]?HangUp(1))
 
  same =>                  n,Log(NOTICE,MDGROUPTRUNKINT**GROUPCOUNT=${GROUP_COUNT(TrunkInternos)}**PEER=${ENR_PEER_ORIGEN}**CID=${CALLERID(NUM)}*)
 
 
  [Cen_Inicio_TrunkSip]
 
  ;exten => _[*#%0-9a-zA-Z].,1,NoOp(MDINITRUNKSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
 
  exten => _[*#%0-9].,1,NoOp(MDINITRUNKSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
 
   
 
  ;      TTipoIdEnrutamiento = (
 
  ;              tipoIdEnrutamiento_ninguno=0,  // quitar no sabemos
 
  ;              tipoIdEnrutamiento_dispositivo=10,   
 
  ;              tipoIdEnrutamiento_cola=20   
 
  ;      );
 
   
 
  same =>            n,Set(ENR_PEER_ORIGEN=)
 
  same =>            n,Set(__ENR_TIPO_ORIGEN=10)
 
  same =>            n,Set(__ENR_ORIGEN=${ID_DISPOSITIVO})
 
  ;same =>            n,Set(__SPAN_IN=)
 
  ;same =>            n,Set(__CANAL_IN=)
 
  ;same =>            n,Set(__TIPO_LLAMADA=${TIPOLLAMADAENT})
 
 
  same =>            n,NoOp(ENR_TIPO_ORIGEN=${ENR_TIPO_ORIGEN}***ENR_ORIGEN=${ENR_ORIGEN})
 
 
;-------------------------
 
  ;  Control de flujo
 
;-------------------------
 
  same =>          n,Set(HORAINI=${EPOCH})
 
  same =>          n,MDflow(1,${EXTEN})
 
  same =>          n,Log(NOTICE,MDFLOWTRUNKSIP**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**CID=${CALLERID(NUM)}*)
 
  same =>          n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 
  same =>          n,Set(GROUP()=${CHANNEL(peername)})
 
  same =>          n,Set(valor=)
 
  same =>          n,ExecIf($["${maxLlam}" = ""]?Set(valor=300):Set(valor=${maxLlam}))
 
  same =>          n,ExecIf($[${GROUP_COUNT(${CHANNEL(peername)})} > ${valor}]?HangUp(1))
 
  same =>          n,Log(NOTICE,MDFLOWTRUNKSIP**GROUPCOUNT=${GROUP_COUNT(${CHANNEL(peername)})}**PEER=${CHANNEL(peername)}**CID=${CALLERID(NUM)}*)
 
 
  
'''Esto desaparecera cuando el dialplan sea unificado'''
+
Los datos contenidos en estos directorios ya no son válidos, borramos los directorios.
'''ahora es necesartio para que pase el ucid del acd'''
+
 
 +
Los enlaces simbólicos no van a ser necesarios, los vamos a conservar para facilitar el acceso a los directorios de mysql habituales
 +
 
 +
rm -rf /var/lib/mysql
 +
ln -s /HDmysql/var/lib/mysql /var/lib/mysql
 +
rm -rf /etc/mysql
 +
ln -s /HDmysql/etc/mysql /etc/mysql
  
 
[Cen_Inicio_SIP]
 
exten => _[*#%0-9].,1,NoOp(MDINIEXTENSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
 
 
  same =>            n,Set(ENR_PEER_ORIGEN=)
 
  same =>            n,Set(__ENR_TIPO_ORIGEN=10)
 
  same =>            n,Set(__ENR_ORIGEN=${ID_DISPOSITIVO})
 
  same =>            n,Set(__SPAN_IN=)
 
  same =>            n,Set(__CANAL_IN=)
 
  ;same =>            n,Set(__TIPO_LLAMADA=${TIPOLLAMADASAL})
 
 
  ;-------------------------
 
  ;  Control de flujo
 
  ;-------------------------
 
  same =>          n,Set(HORAINI=${EPOCH})
 
  same =>          n,MDflow(2,${EXTEN})
 
  same =>          n,Log(NOTICE,MDFLOWEXTSIP**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**CID=${CALLERID(NUM)}*)
 
  same =>          n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 
 
 
  same =>            n,NoOp(ENR_TIPO_ORIGEN=${ENR_TIPO_ORIGEN}***ENR_ORIGEN=${ENR_ORIGEN})
 
 
'''Para recibir el UCID de otros vivait (move,meet)'''
 
  
 +
======  Modificar configuración de apparmor para mysql. (En los 2 nodos) ======
  
 +
Debemos cambiar la configuración de apparmor para darle a mysql acceso a la nueva localización de los ficheros.
  
==== Comandos básicos de diagnóstico ====
+
Debemos modificar el fichero /etc/apparmor.d/usr.sbin.mysqld
  
  Comandos básicos (dentro de la consola asterisk)
+
vi /etc/apparmor.d/usr.sbin.mysqld
  
*'''mdflow show stats''': permite ver las medidas de cada flujo configurando que etsa tomando el mdflow, cuantas colas se estan utilizando, cuanteas llamadas pasan, cuantas desbordan, cuantas son agujero, cuantos dnis masivos hay...
 
  
Preproduccion-Corp0*CLI>  mdflow show stats
+
Y dejarlo configurado con la nueva ubicación de los ficheros. Debe quedar así:
 
mdflow Estadística global:
 
  activo=1
 
  supervEjecutando=1
 
  tickMs=500
 
  estadIntervSeg=10
 
  flowNum=3
 
  
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
 
  flowInd=1 enPaso=0
 
  flowInd=1 tasaUltIntervMs=10003
 
  flowInd=1 tasaUltEntra=0
 
  flowInd=1 tasaUltSaleOk=0
 
  flowInd=1 tasaUltSaleDesborda=0
 
  flowInd=1 tasaUltSaleAgujero=0
 
  flowInd=1 tasaUltSaleError=0
 
  flowInd=1 llamUltColaMax=0
 
  flowInd=1 dnisUltColasUsoMax=0
 
  flowInd=1 dnisUltMasivoMax=0
 
  flowInd=1 retardoUltMedioMs=0
 
  
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
+
[[File:cluster19.png|300px]]
  flowInd=2 enPaso=1
 
  flowInd=2 tasaUltIntervMs=10003
 
  flowInd=2 tasaUltEntra=0
 
  flowInd=2 tasaUltSaleOk=0
 
  flowInd=2 tasaUltSaleDesborda=0
 
  flowInd=2 tasaUltSaleAgujero=0
 
  flowInd=2 tasaUltSaleError=0
 
  flowInd=2 llamUltColaMax=0
 
  flowInd=2 dnisUltColasUsoMax=0
 
  flowInd=2 dnisUltMasivoMax=0
 
  flowInd=2 retardoUltMedioMs=0
 
  
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
+
[[File:cluster20.png|300px]]
  flowInd=3 enPaso=0
 
  flowInd=3 tasaUltIntervMs=10003
 
  flowInd=3 tasaUltEntra=0
 
  flowInd=3 tasaUltSaleOk=0
 
  flowInd=3 tasaUltSaleDesborda=0
 
  flowInd=3 tasaUltSaleAgujero=0
 
  flowInd=3 tasaUltSaleError=0
 
  flowInd=3 llamUltColaMax=0
 
  flowInd=3 dnisUltColasUsoMax=0
 
  flowInd=3 dnisUltMasivoMax=0
 
  flowInd=3 retardoUltMedioMs=0
 
  
*'''mdflow show dnis''': permite saber cuales son los DNIS masivos de la centralita
+
Aplicamos los cambios con:
  
  Preproduccion-Corp0*CLI> mdflow show dnis
+
  apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld
  
mdflow Estado global:
+
'''Realizamos este mismo proceso en el otro nodo del cluster.'''
  activo=1
 
  supervEjecutando=1
 
  tickMs=500
 
  estadIntervSeg=10
 
  flowNum=3
 
  
  mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
+
====== Modificar archivos de configuración de mysql. (En 1 nodo) ======
  flowInd=1 enPaso=0
 
  flowInd=1 dnisColaNum=1 no se controlan dnis
 
  
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
+
Los enlaces simbólicos no funcionan con mysql, por eso necesitamos modificar archivos de configuración de mysql para cambiar las rutas de acceso a los archivos creado en el directorio /HDmysql.
  flowInd=2 enPaso=1
 
  flowInd=2 dnisColaNum=2
 
  flowInd=2 dnisUltMasivoMax=0
 
  
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
+
Esto hay que realizarlo en el nodo que tiene montada la partición /HDmysql.
  flowInd=3 enPaso=0
 
  flowInd=3 dnisColaNum=1 no se controlan dnis
 
  
*'''mdflow show config''' Permite ver la configuracion de los distintos flujos
+
Modificamos el fichero my.cnf.fallback
  
  Preproduccion-Corp0*CLI> mdflow show config
+
  vi  /HDmysql/etc/mysql/my.cnf.fallback
  
mdflow Configuración global:
 
  activo=1
 
  supervEjecutando=1
 
  tickMs=500
 
  estadIntervSeg=10
 
  estadFases=20
 
  flowNum=3
 
  
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
+
Deberá quedar así.
  flowInd=1 enPaso=0
 
  flowInd=1 llamSalTick=1
 
  flowInd=1 llamSalSeg=2
 
  flowInd=1 dnisColaNum=1
 
  flowInd=1 dnisUmbralMasivo=8
 
  flowInd=1 llamDesbordaToSeg=5
 
  
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
 
  flowInd=2 enPaso=1
 
  flowInd=2 llamSalTick=1
 
  flowInd=2 llamSalSeg=2
 
  flowInd=2 dnisColaNum=2
 
  flowInd=2 dnisUmbralMasivo=10
 
  flowInd=2 llamDesbordaToSeg=5
 
  
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
+
[[File:cluster21.png|300px]]
  flowInd=3 enPaso=0
 
  flowInd=3 llamSalTick=1
 
  flowInd=3 llamSalSeg=2
 
  flowInd=3 dnisColaNum=1
 
  flowInd=3 dnisUmbralMasivo=8
 
  flowInd=3 llamDesbordaToSeg=5
 
  
 +
Ahora el fichero mysql.cnf.
  
*'''mdflow reload:''' Recarga mdflow leyendo de nuevo el fichero de configuración
+
vi /HDmysql/etc/mysql/mysql.cnf
MDlow.conf; se puede realizar con la plataforma en funcionamiento normal pero no
 
se recomienda realizarlo en momentos de alto tráfico; los cambios de configuración
 
se aplican tras un comando “mdflow reload”
 
  
Preproduccion-Corp0*CLI> mdflow reload
+
Y quedará así.
  
 +
[[File:cluster22.png|400px]]
  
*'''mdflow debug:''' Muestra estadísticas por pantalla a intervalos regulares; no se
+
El fichero mysqld.cnf.
recomienda su uso sistemático.
 
  
  Preproduccion-Corp0*CLI> mdflow debug
+
  vi /HDmysql/etc/mysql/mysql.conf.d/mysqld.cnf
  
==== Comandos básicos de diagnóstico ====
+
[[File:cluster23.png|400px]]
  
El MDflow está activo si los comandos anteriormente mencionados devuleven datos, si no devuelven nada es que ha ocurrido un error al cargar el módulo en asterisk. Los comandos de diagnostico empleados son los mismos que hemos mencionado anteriormente más el '''mdflow debug on''', que muestra lo mismo que el '''mdflow show stats''' pero lo hace para cada llamada que pase por la parte del dialplan que hemos mencionado antes.
 
  
 +
Y por último el fichero my.cnf.
  
 +
vi /HDmysql/etc/mysql/my.cnf
  
==== Asignación de flujos ====
+
Y quedara de la siguiente manera. (datadir / log_bin / includedir)
  
  
Por defecto, en la instalación irán definidos los siguientes flujos:
+
[[File:cluster24.png|500px]]
  
*'''Flujo 1 (trunksip):''' Flujo que analiza las llamadas que vienen de los trunksip.
 
Típicamente son las llamadas que provienen de los operadores en los Gatewais.
 
Está configurado en el contexto Cen_InicioLlamada_TrunkSip.
 
  
*'''Flujo 2 (Extensiones):''' Flujo para las llamadas originadas por las extensiones SIP
+
[[File:cluster25.png|500px]]
registradas en el nodo. Está configurado en el contexto Cen_InicioLlamada_SIP.
 
  
*'''Flujo 3 (trunkInternos):''' Flujo para las llamadas que provienen de otros nodos.
 
Está configurado en el contexto Cen_TrunkInternos
 
  
 +
[[File:cluster26.png|400px]]
  
  
Estos son flujos genéricos que irán definidos en la instalación, se podrán generar mas si la
+
======  Configuración del arranque de mysql. (En 1 nodo) ======
instalación lo requiere, por ejemplo, si la instalación tiene primarios se podrá definir un
 
flujo para las llamadas que vienen por el contexto Cen_InicioLlamada_Dahdi.
 
  
 +
Vamos a configurar el arranque de mysql y le vamos a poner como condiciones que este en el nodo que este la ip flotante de mysql y que arranque después de que esté la ip.
  
El significado del flujo 3 es diferente según el tipo de nodo en que se está ejecutando. Por
+
pcs cluster cib mysql_cfg
ejemplo, en una instalación de 2 nodos, un nodo Gateway y un nodo de procesamiento, el
+
pcs -f mysql_cfg resource create MYSQL ocf:heartbeat:mysql binary="/usr/sbin/mysqld" config="/etc/mysql/my.cnf"  datadir="/var/lib/mysql" pid="/var/run/mysqld/mysqld.pid" socket="/var/run/mysqld/mysqld.sock" additional_parameters="--bind- address=0.0.0.0" op start timeout=60s op stop timeout=60s op monitor interval=20s timeout=30s
flujo 3 en el nodo gateways estará midiendo el tráfico que manda el nodo de
+
pcs -f mysql_cfg constraint colocation add MYSQL with IP-MYSQL INFINITY
procesamiento hacia el exterior del sistema, típicamente las llamadas salientes al sistema,
+
pcs -f mysql_cfg constraint order IP-MYSQL then  MYSQL
en cambio, el mismo flujo en el nodo de procesamiento, estará indicando las llamadas que
+
pcs cluster cib-push mysql_cfg
vienen del Gateway, típicamente las llamadas entrantes del exterior.
+
pcs status
  
  
Esto es mucho menos evidente en instalaciones con varios nodos, con trunk hacia
+
====== Configuración del arranque de Asterisk. (En 1 nodo) ======
proveedores externos en los nodos de procesamiento, etc.
 
  
 +
pcs cluster cib aster_cfg
 +
pcs -f aster_cfg resource create ASTER lsb:asterisk
 +
pcs -f aster_cfg constraint colocation add ASTER with IP-ASTER INFINITY
 +
pcs -f aster_cfg constraint order IP-ASTER then ASTER
 +
pcs cluster cib-push aster_cfg
 +
pcs status
  
  
==== Configuración de cola única ====
+
====== Mover los recursos a otra máquina. (En 1 nodo) ======
  
 +
El crear 2 particiones separadas para el Asterisk y el mysql nos da la posibilidad de correr un servicio en cada máquina y tener los 2 nodos activos.
  
La configuración de colas es útil cuando el número de DNIS es finito y queremos priorizar
+
Para mover un recurso de nodo utilizaremos el siguiente comando en el nodo que está el recurso ejecutándose.
los números llamados menos frecuentemente sobre los masivos.
 
  
  Cuando el número de DNIS es muy grande la configuración mediante colas no ofrece un
+
  pcs resource move DRBDfsASTER
funcionamiento óptimo, las colas serán ocupadas cada una con un DNIS diferente y todos
+
 
los DNIS que no tengan cola libre saldrán por la salida “agujero”.
+
Esto crea restricciones locales para evitar que el recurso vuelva a este nodo (Puede tener prioridad de ejecución en este nodo y haría que volviera a este nodo automáticamente al estar online).
 +
 
 +
La restricción que crea banea el nodo para este recurso, si queremos quitar la restricción creada.
  
  Para tener un control del flujo en estas situaciones se ha creado el concepto de cola única,
+
  pcs resource clear DRBDFsAst
su comportamiento es que todas las llamadas van a la misma cola y no hay llamadas que
 
obtengan la salida “agujero” y por tanto todas tienen la misma prioridad.
 
  
Este comportamiento se obtiene poniendo el parámetro de configuración del flujo
 
dnis_max con el valor 1 (dnis_max=1).
 
  
Un ejemplo típico de utilización de este tipo de configuración sería en el flujo 3 de los
+
-----------------------------------------------------------------------------------------------------------------------------
nodos gateways. Este flujo tendrá las llamadas que el resto de los nodos envían al exterior
 
y los DNIS no coincidirían en su mayoría.
 
  
==== MDflow y las trazas ====
+
===== Instalación y configuración del Cluster hasta la versión '''''<span style="color:#144F9B">VIVA</span>'''''it 3.3 =====
 +
.
  
El diaplan devulelve trazas del MDflow mdiante mensajes NOTICE, por lo que filtrando en el full de asterisk por la cadena MDFLOW irán apareciendo los diferentes retornos de ejecucion del MDFLOW (cuanto tiempo ha tardado en ejecutarse, qué devuelve el MDflow para esa llamada (agujero, desbordada, ok o error))
 
  
  
 +
Hasta la versión '''3.3''' de '''''<span style="color:#144F9B">VIVA</span>'''''it , la instalación y configuración del cluster se hace de la siguiente forma:
  
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Estadísticas en '''''<span style="color:#144F9B">VIVA</span>'''''it Call ===
+
'''[[Instalación y configuración del Cluster hasta la versión VIVAit 3.3]]'''
  
[[:medio:Estadisticas_VIVAIT_ Call.pdf|Como configurar estadísticas para '''''VIVA'''''it Call ]]
 
  
  
== Configuración de los diferentes Portales de Usuario ==
+
<!--
 +
=== Nivel matriz de conmutación ===
 +
-->
 
<br><br>
 
<br><br>
El portal de usuario VIVAit Call permite que determinadas funcionalidades del sistema puedan ser accesibles por los usuarios finales desde una interfaz mucho más cómoda y amigable que el telefónico.
+
 
<br><br>
+
=== Gateways ===
Existen varias opciones del portal de usuario según las necesidades del cliente , las diferentes opciones en base a la configuración son:
 
<br><br>
 
* Portal de usuario
 
* Portal Webcall
 
* Portal para integración con Teams
 
* Portal Vivait Tracker
 
* Portal Vivait Supervisor
 
<br><br>
 
Para configurar las diferentes posibilidades en los portales de usuario hay que modificar el archivo '''“vivaitConfig.js”''' , este archivo se encuentra en :  '''/var/www/vivait/webs/portal/Assets/Config/'''
 
<br><br>
 
[[File:p-usuario1.png|center|600px]]
 
<br><br>
 
*'''webphoneLink :''' Configuración del link de la web con solo el dialpad.
 
*'''IsWebPhoneDisabled:''' Configuración para habilitar (false) o deshabilitar (true) la aparición de webphone al iniciar el portal.
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
 
<br><br>
 
<br><br>
  
=== Portal de usuario ===
+
El concepto de gateway como tal no existe en la plataforma '''''VIVA'''''it; existen nodos de ACD y nodos de corporativa.
<br><br>
 
Para configurar el portal de usuario solo para terminales telefónicos (sin webphone) se tendría que hacer de la siguiente forma:
 
<br><br>
 
[[File:p-usuario2.png|center|300px]]
 
<br><br>
 
*'''webphoneLink :''' Comentar la línea con ( // ) al comienzo de esta.
 
*'''IsWebPhoneDisabled:''' Deshabilitar (true) para que no aparezca webphone al iniciar el portal.
 
<br><br>
 
Al terminar la configuración , en el portal se deshabilitará el botón de webphone:
 
<br><br>
 
[[File:p-usuario3.png|center|700px]]
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Portal Webcall ===
+
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
<br><br>
+
 
Para configurar el portal de usuario VIVAit Call web con webphone integrado en la misma página se tendría que hacer de la siguiente forma:
+
El concepto gateway queda pues suscrito a entornos meramente comerciales
<br><br>
+
 
[[File:p-usuario4.png|center|300px]]
+
Incluimos no obstante en este apartado los diagnósticos y operaciones básicos de conexiones a sistemas externos o RTC
<br><br>
+
 
*'''webphoneLink :''' Comentar la línea con ( // ) al comienzo de esta.
+
Para verificar los enlaces establecidos ejecutamos el siguiente comando en el terminal: '''sip show peers'''  
*'''IsWebPhoneDisabled:''' Habilitar (false) para que aparezca webphone al iniciar el portal.
+
 
<br><br>
+
Al ejecutar este comando obtenemos la salida:
Al terminar la configuración , en el portal aparecerá el dialpad de webphone:
+
 
<br><br>
+
[[Archivo:Enlace_Exterior.png |center]]
[[File:p-usuario5.png|center|800px]]
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Portal para integración con Teams ===
+
Las columnas ''Host'' y ''Port'' nos muestran las conexiones establecidas y nos informa de un posible problema de conexión.  
<br><br>
+
 
Para configurar el portal de usuario VIVAit Call web con botón de enlace a otra página con webphone se tendría que hacer de la siguiente forma:
+
Sabremos que ''no existe conexión'' cuando la columna Host tiene el valor '''Unspecified''' y en la columna Port aparece un '''0''' , a continuación se muestra un ejemplo:
<br><br>
+
 
[[File:p-usuario6.png|center|300px]]
+
 
<br><br>
+
[[Archivo:Ejemplo_no_conexion.png |center]]
*'''webphoneLink :''' Poner el link del enlace a webphone
+
 
*'''IsWebPhoneDisabled:''' Deshabilitar (true) para que no aparezca webphone al iniciar el portal.
+
<!--
<br><br>
+
<span style="background:#00FF00">FALTA AQUI DIAGNOSTICOS Y OPERACIONES DE ENLACES EXTERNOS</span>
Al terminar la configuración , en el portal estará habilitado el botón de webphone , que al pulsar sobre el nos llevará a otra página con el dialpad :
+
-->
<br><br>
 
[[File:p-usuario7.png|center|800px]]
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Varios portales en una sola instalación ===
 
<br><br>
 
Existe la posibilidad de tener varios portales en una misma instalación de VIVAit Call con diferentes url’s para cada portal .
 
<br><br>
 
[[File:p-usuario8.png|center|600px]]
 
<br><br>
 
Un ejemplo de las url’s de los portales sería:
 
<br><br>
 
https://servidor/webs/vivait-user/ → Portal usuario
 
https://servidor/webs/webfon2-solo → DialPad
 
https://servidor/webs/webfon3 → Portal webphone
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Portal Vivait Tracker ===
 
<br><br>
 
==== Introducción a Vivait Tracker 0.1 ====
 
<br><br>
 
Con la versión 5.1 de la plataforma '''''VIVA'''''it Call se ha lanzado un nuevo tracker: ''VIVAit Tracker'', que supone una mejora sobre el producto anterior: [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Vivait-Tracker ''Tracker WEB''] más enfocado al mundo Call Center.<br>
 
Los puntos claves del nuevo '''''portal VIVAit Tracker''''' dirigido al entorno corporativo son:<br>
 
: • Adaptación para facilitar su uso en entornos de telefonía corporativa.<br>
 
: • Permite seguir llamadas y escuchar/descargar grabaciones en caso de existir.<br>
 
: • Integrado con entornos de texto (TBC y desarrollos futuros).
 
<br><br>
 
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
===== Arquitectura de Vivait Tracker 0.1 =====
 
<br><br>
 
Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:
 
<br><br>
 
: - '''Frontend'''<br>
 
::Reside en un servidor web Apache.<br>
 
::Se invoca desde un navegador mediante una URL del tipo https://host/ws/<br>
 
        https://172.25.128.252/Tracker_Corp/
 
::Es la parte visual: HTML, CSS, JavaScript.<br>
 
::No accede directamente a la base de datos; solo obtiene datos desde una API.
 
<br><br>
 
: - '''Backend / API REST'''<br>
 
::Corre en un servidor web Tomcat.<br>
 
::Expone la API en: <br>
 
        https://172.25.128.252/Tracker-Rest/tracker/.
 
::Contiene la lógica que permite interactuar con la BBDD.<br>
 
::Responde en JSON para que el frontend pueda ofrecérselo al navegador.<br>
 
<br><br>
 
Diagrama funcional de la arquitectura de VIVAit Tracker 0.1
 
<br><br>
 
[[File:arquitectura3_tracker_V5.1.png|1500px|center|thumb]]
 
<br><br>
 
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
====== Flujo completo del ciclo de datos ======
+
=== Grabación ===
<br><br>
 
Siguiendo el proceso se contemplan los siguientes pasos:
 
<br><br>
 
'''Paso 1''' El usuario invoca el frontend residente en Apache desde un navegador, usando javascript, mediante la URL del tipo:<br>
 
        https://host/Traker_Corp/
 
El navegador carga la página web servida por Apache.
 
 
<br><br>
 
<br><br>
'''Paso 2''' Una vez superada la fase de [[#Seguridad de VIVAit Tracker 0.1 |validación]] se muestra un [[#Descripción de la interfaz de VIVAit Supervisor 2.0 |formulario]] que permite al usuario definir los parámetros de una consulta.<br>
 
::La página del formulario inicia una transacción para efectuar una solicitud HTTP POST al endpoint correspondiente, por ejemplo:<br>
 
                https://172.25.128.252/Tracker_Corporativo/
 
::siendo la carga util de esta solicitud los datos del formulario rellenado por el usuario:<br>
 
                {fechaInicio: "", fechaFin: "", horaInicio: "", horaFin: "", listaExtensiones: [], listaGrupos: [],…}         
 
<br><br>
 
'''Paso 3''' Al recibir los datos del formulario el frontend hace una petición a la API REST de Tomcat.<br>
 
  
<br><br>
+
==== Configuración de la grabación en la plataforma corporativa ====
'''Paso 4''' La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta.<br>
+
Para que una llamada se grabe, lo primero de todo es que  alguien tenga la capacidad de grabar. Esto se consigue diciendo al nodo que sea grabador. Esto provoca que el nodo llame al mixmonitor para grabar y se inserte un registro en el DAT_GRABACIONES. Esto no significa que ya las llamadas se vayan a grabar, ya que para eso tiene que ser procesadas por un nodo que sea grabador. Hay tres, llamémosle elementos, que se pueden grabar:
  
<br><br>
+
* El nodo, es decir todo lo que el nodo enrute
'''Paso 5''' El frontend recibe el JSON con los datos de la consulta en la respuesta:<br>
+
* Prerutas
                POST https://172.25.128.252/Tracker-Rest/tracker/lista
+
* Objetos: que son las extensiones, usuarios, grupos corporativos, etc.
::El navegador lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.
 
<br><br>
 
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
===== Seguridad de Vivait Tracker 0.1 =====
+
Tenemos tres formas de grabar:
<br><br>
 
El acceso está controlado mediante validación de tokens.
 
<br><br>
 
'''Paso 1 Autenticación inicial'''
 
<br><br>
 
: • Al introducir sus credenciales el usuario se valida a través del servicio de autenticación ''sercen''<br>
 
                https://172.25.128.252/sercen/postautenticar1
 
: • Sercen genera un token firmado que identifica la sesión del usuario.
 
<br><br>
 
'''Paso 2 Validación interna de permisos'''
 
<br><br>
 
: • Una vez que el frontend tiene el token, cada petición pasa por una validación de la API del tomcat:<br>
 
                https://172.25.128.252/Tracker-Rest/tracker/verificarToken
 
:: En la misma se comprueba que:<br>
 
::: - El token es válido.<br>
 
::: - El usuario tiene permisos para el recurso que está intentando usar. <br>
 
:::  Es necesario que el usuario tenga acceso a la aplicación ''Grabador'', ver [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit_5.0#Submen.C3.BA_Permisos_a_usuarios Usuarios].<br>
 
: • No se ejecuta ninguna acción si el token no es validado primero.
 
<br><br>
 
'''Paso 3 Proxy inverso apache-tomcat'''
 
<br><br>
 
: • Apache actúa como punto de entrada único:
 
:: - El usuario solo ve URLs de apache.
 
:: - Las peticiones que requieren lógica del backend se redirigen internamente a tomcat.
 
:: - Esto se consigue mediante proxy inverso, por ejemplo:<br>
 
::: /Tracker_Corporativo → servido por apache<br>
 
                https://172.25.128.252/Tracker_Corp/
 
::: /Tracker-Rest → Apache las pasa a Tomcat de forma transparente para el usuario<br>
 
                https://172.25.128.252/Tracker-Rest/tracker/extensiones
 
: • El navegador utilizado por el usuario nunca ve a tomcat.
 
<br><br>
 
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
==== Descripción de la interfaz de Vivait Tracker 0.1 ====
+
* Grabar con beep periódico
<br><br>
+
* Grabar sin beep periódico
Este apartado se trata en [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/VIVAit_Tracker#Descripción_de_la_interfaz_de_Vivait_Tracker_0.1 Vivait Tracker]
+
* Descartar grabación
<br><br>
 
[[#Introducción a Vivait Tracker 0.1 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
=== Portal VIVAit Supervisor ===
+
Si de los tres elementos tenemos que uno grabe, ya sea con o sin beep periódico, esa llamada se va a grabar ya que son OR, en cuanto haya un elemento que diga que grabe se va a grabar.
<br><br>
 
==== Introducción a Vivait Supervisor 2.0 ====
 
<br><br>
 
Con la versión 5.1 de la plataforma '''''VIVA'''''it Call se ha lanzado la aplicación: ''Vivait-Supervisor 2.0''.
 
<br><br>
 
Los puntos claves del '''''portal Vivait Supervisor''''' son:<br>
 
: • Seguimiento de las llamadas generadas en el sistema '''''VIVA'''''it Call.<br>
 
: • Visualización de resultados mediante gráficos, tablas y otros formatos.<br>
 
: • Exportación de datos para su posterior análisis.
 
<br><br>
 
[[#Introducción a Vivait Supervisor 2.0| Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
===== Definiciones en Vivait Supervisor 2.0 =====
+
Al igual pasa si tenemos que un elemento tenga descartar la grabación. La grabación no se inicia.
<br><br>
 
A continuación se definen los principales conceptos empleados en el supervisor:
 
<br><br>
 
'''Dashboard'''<br>
 
:Panel de control que presenta de forma visual y resumida la información clave (datos, indicadores o métricas),<br>
 
:con el objetivo de facilitar la supervisión, el análisis y la toma de decisiones de manera rápida y eficiente.<br>
 
:Un dashboard está compuesto por uno o varios componentes.
 
<br><br>
 
'''Componente'''<br>
 
:Elemento individual que forma parte de un dashboard y cuya función es mostrar la información requerida.<br>
 
:Los componentes pueden adoptar distintos formatos, entre los más habituales:<br>
 
::'''• Tablas:'''<br>
 
:::La información se presenta en formato tabular. Las cabeceras y la estructura de la tabla se definen durante la creación de su lógica.<br>
 
::'''• Gráficos:'''<br>
 
:::Los datos se muestran de forma visual mediante distintos tipos de gráficos, como barras, líneas, circulares, entre otros.<br>
 
::Según el modo en que actualizan la información, los componentes se clasifican en:<br>
 
::'''• Dinámicos:'''<br>
 
:::La información se actualiza de forma periódica, de acuerdo con un temporizador asociado al componente.<br>
 
::'''• Estáticos:'''<br>
 
:::La información se carga al iniciar el dashboard y no se vuelve a actualizar hasta que el panel de control se invoca nuevamente.
 
<br><br>
 
[[#Introducción a Vivait Supervisor 2.0| Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
===== Arquitectura de Vivait Supervisor 2.0 =====
+
Referente al campo de Modo de grabación en infraestructura, este no se emplea para la grabación de corporativo, sino que solo tiene validez en ACD. Para grabación en el ACD hay que, como se ha dicho anteriormente poner un nodo que sea grabador y especificar un elemento de los tres que hay cual es el que se va a grabar.
<br><br>
+
 
Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:
+
Para que exista una grabación ha de existir un segmento asociado a esta. Los segmentos se tratan en las prerutas. Hay un campo es las prerutas que es Generar segmento al enrutar. Si está se generará el segmento del tipo de la preruta y su correspondiente grabación si esta está configurada. Si le decimos que no genere segmentos al enrutar y el sistema está configurado para que grabe, el recordCentral creará un tipo de segmento llamado externo para esa grabación. Podemos configurar si queremos que se cree o no ese segmento, para eso hay que modificar el fichero de configuración del recordCentral y poner un tiempo muy alto al campo $segmExternoMinSegs. También podemos configurar que segmentos queremos que se graben. Por defecto el recordCentral va configurado para que se graben todos los segmentos. Para decirle que solo grabe cierto tipo de segmentos hay que ponerlos los que queramos que si se graben en la variable $tiposSegmentoGrabar del fichero de configuración del recordCentral.
<br><br>
+
 
: - '''Frontend'''<br>
+
 
::Reside en un servidor web Apache.<br>
+
==== Como configurar la grabación bajo demanda ====
::Se invoca desde un navegador mediante una URL del tipo https://host/ws/<br>
+
 
        https://172.25.128.92/Vivait-Supervisor/
+
Para activar la grabación bajo demanda es necesario activar el '''MixMonitor'''.
::Es la parte visual: HTML, CSS, JavaScript.<br>
+
 
::No accede directamente a la base de datos; solo obtiene datos desde una API.
+
En el Nodo hay que identificar '''Grabar por enrutamiento''' = '''Sin grabación'''.
<br><br>
 
: - '''Backend / API REST'''<br>
 
::Corre en un servidor web Tomcat.<br>
 
::Expone la API en: <br>
 
        https://172.25.128.92/Vivait-Supervisor/.
 
::Contiene la lógica que permite interactuar con la BBDD.<br>
 
::Responde en JSON para que el frontend pueda ofrecérselo al navegador.<br>
 
<br><br>
 
Diagrama funcional de la arquitectura de Vivait-Supervisor
 
<br><br>
 
[[File:arquitectura_supervisor2_V5.1.png|1500px|center|thumb]]
 
<br><br>
 
[[#Introducción a Vivait Supervisor 2.0| Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
====== Flujo completo del ciclo de datos ======
 
<br><br>
 
Siguiendo el proceso se contemplan los siguientes pasos:
 
<br><br>
 
'''Paso 1''' El usuario invoca el frontend residente en Apache desde un navegador, usando javascript, mediante la URL del tipo:<br>
 
        https://host/Vivait-Supervisor/
 
El navegador carga la página web servida por Apache.
 
<br><br>
 
'''Paso 2''' Una vez superada la fase de [[#Seguridad de Vivait Supervisor 2.0|validación]] se muestra [[#Descripción de la interfaz de Vivait Supervisor 2.0 |la pantalla inicial]] que permite al usuario elegir el dashboard, previamente configurado, ejecutándose la monitorización de la consulta preparada.<br>
 
::Tras elegir el dashboard deseado, la página web realiza solicitudes periódicas HTTP POST al endpoint correspondiente,<br>
 
::donde se obtienen los datos de los componentes asociados al dashboard, por ejemplo:<br>
 
                https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
 
::siendo la carga útil de esta solicitud la identificación del componente con los filtros elegidos por el usuario:<br>
 
              {idCompoCuadro: "15",…}
 
                  filtros : [{tipo: "titulo", valor: "titulo=Detalle"}, {tipo: "fechaDesde", valor: "FechaDesde="},…]
 
                idCompoCuadro: "15"         
 
<br><br>
 
'''Paso 3''' Al recibir los datos el frontend hace una petición a la API REST de Tomcat.<br>
 
<br><br>
 
'''Paso 4''' La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta.<br>
 
              INFO TablaDinamicosDaoImpl:607 - componerSQL SELECT DATE_FORMAT(DAT_LLAMADAS.D_HORA_INICIO,'%Y-%m-%d'),DATE ...
 
<br><br>
 
'''Paso 5''' El frontend recibe el JSON con los datos de la consulta en la respuesta:<br>
 
                POST https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
 
::El navegador lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.
 
<br><br>
 
[[#Introducción a Vivait Supervisor 2.0| Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_4.0  Volver al índice]
 
<br><br>
 
  
===== Seguridad de Vivait Supervisor 2.0 =====
 
<br><br>
 
El acceso, del usuario a la aplicación, está controlado mediante validación de tokens y acceso a la aplicación correspondiente.<br>
 
ver [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit_5.0#Submen.C3.BA_Permisos_a_usuarios Usuarios]
 
<br><br>
 
La aplicación ''CALL_CENTER'' es la que gestiona los perfiles del usuario para Vivait-Supervisor, según la siguiente tabla:
 
<br><br>
 
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
 
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.3cm;color:#ffffff;" | '''''Perfil de Usuario'''''
 
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.3cm;color:#ffffff;" | '''''Nivel administración'''''
 
! align=center style="background-color:#0099ff;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0.3cm;color:#ffffff;" | '''''Funciones'''''
 
|-
 
| style="text-align: center; font-weight: bold;padding:0.3cm;" |Administración
 
| | Distinto de Ninguno:
 
: - '''Alto''',
 
: - '''Medio''' o
 
: - '''Bajo'''.
 
| | Configuración y utilización de dashboard.
 
|-
 
| style="text-align: center; font-weight: bold;padding:0.3cm;" |Consulta
 
| | '''Ninguno'''
 
| | Utilización de dashboard.
 
|-
 
|}
 
<br><br>
 
El usuario no tiene acceso a Vivait-Supervisor si no tiene asignada la aplicación ''CALL_CENTER''.
 
<br><br>
 
El proceso de validación que se sigue dentro del sistema es el siguiente:
 
<br><br>
 
'''Paso 1 Autenticación inicial'''
 
<br><br>
 
: • Al introducir sus credenciales el usuario se valida a través del servicio de autenticación ''sercen''<br>
 
                https://172.25.128.92/sercen/postautenticar1
 
: • Sercen genera un token firmado que identifica la sesión del usuario.
 
<br><br>
 
'''Paso 2 Validación interna de permisos'''
 
<br><br>
 
: • Una vez que el frontend tiene el token, cada petición pasa por una validación de la API del tomcat:<br>
 
:: En la misma se comprueba que el usuario tiene permisos para el recurso que está intentando utilizar, según la tabla anterior.<br>
 
::* Si el usuario tiene un perfil de administrador puede configurar (crear, borrar o gestionar) y consultar dashboard.<br>
 
::* Si el usuario tiene un perfil de consulta solo puede consultar dashboard ya configurados, no puede gestionarlos.<br>
 
<br><br>
 
'''Paso 3 Proxy inverso apache-tomcat'''
 
<br><br>
 
: • Apache actúa como punto de entrada único:
 
:: - El usuario solo ve URLs de apache.
 
:: - Las peticiones que requieren lógica del backend se redirigen internamente a tomcat.
 
:: - Esto se consigue mediante proxy inverso, por ejemplo:<br>
 
:::/Vivait-Supervisor/ → servido por apache<br>
 
                https://172.25.128.92/Vivait-Supervisor/
 
:::Apache las pasa a Tomcat de forma transparente para el usuario<br>
 
                https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
 
: • El navegador utilizado por el usuario nunca ve al módulo tomcat.
 
<br><br>
 
[[#Introducción a Vivait Supervisor 2.0| Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
==== Descripción de la interfaz de Vivait Supervisor 2.0 ====
+
[[File:Ejemplo activacion grabacion en nodo CORP-2.jpg|centro]]
<br><br>
+
 
Este apartado se trata en [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/VIVAit_Supervisor#Descripción_de_la_interfaz_de_Vivait_Supervisor_2.0 Vivait Supervisor]
 
<br><br>
 
[[#Introducción a Vivait Supervisor 2.0 | Volver arriba]] / [https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
== Puesto de trabajo ==
 
El puesto de trabajo del agente en la plataforma '''''VIVA'''''it  (para el producto '''''VIVA'''''it Suite) estará compuesto por:
 
* PC (típicamente windows) en el que reside la aplicación '''''VIVA'''''it Desk
 
* Terminal telefónico con extensión física asociada.
 
  
Para más información [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Puestos | ver sección Portal de administración-VIVAit Suite ACD+ - Puestos]].
 
  
=== Relación PC/teléfono en puesto de trabajo ===
+
En el Nodo ACD y/o Corporativo es obligatorio que el campo '''Modo de grabación de infraestructura''' sea igual a '''Graba por petición'''.
  
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.
 
==== 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:
 
  
{| class="wikitable"
+
[[File:NODO ACD-2.jpg|centro]]
|-
+
 
! Cambio !! Procedimiento !! Punto de acción
+
 
|-
+
 
|rowspan="2"| 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
+
En la Campaña (asignar la cola a la campaña; si se pone el modo de grabación en la cola, '''no funciona <big><sup>'''**'''</sup></big>''', ha de ir en la campaña o en el VDN) o en VDN el campo “'''Modo de grabación'''” debe ser igual a '''Grabación Bajo demanda inicio sin grabar ó grabando'''.
|-
 
|  Opción 2.- Rehacer la asignación extensión/puesto || Portal de administración
 
|-
 
| rowspan="2"| 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
 
|}
 
<!--
 
[[File:relacion_puesto_agente.png|center|500px]]
 
-->
 
  
=== 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
 
{| class="wikitable"
 
|-
 
! Fichero !! Descrición
 
|-
 
| Vivait-desk.exe || Contiene la aplicación '''''VIVA'''''it 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 '''''VIVA'''''it Desk
 
|-
 
|}
 
  
=== Secciones de utilidad en nimitz.ini ===
 
  
==== Configuración del puesto de agente ====
+
[[File:MODO DE GRABACION EN CAMPAÑA-2.jpg|centro]]
  
El fichero nimitz.ini contiene la configuración del puesto de agente; sus principales parámetros son:
 
  
{| class="wikitable" border="0" style="background:#ffffff" align="top"
 
|-
 
| |''' Fichero'''
 
|| '''Descripción'''
 
|-
 
|Sección [bd1]
 
||host="ip_BBDD_tiempo_real"
 
puerto="Nº puerto"
 
basedatos="nimitz"
 
usuario="nimitz"
 
clave="UIk5jMY9PVX6ogg="
 
  
Contiene información para la conexión a BBDD de tiempo real, en la que '''''VIVA'''''it Desk fundamentalmente inserta información
 
|-
 
|Sección [bd2]
 
||host=" ip_BBDD_replica "
 
puerto="Nº puerto"
 
basedatos="nimitz"
 
usuario="nimitz"
 
clave="UIk5jMY9PVX6ogg="
 
  
Contiene información para la conexión a BBDD de réplica, en la que '''''VIVA'''''it Desk solo leerá información
+
El formulario de '''''VIVA'''''it Desk que se abra cuando entre la llamada que queremos grabar ha de tener los botones de grabación.
|-
 
|Sección [telefono]
 
||pruebas=1 (Valores válidos 0 ó 1)
 
Activación de funcionalidad "servicio técnico" en '''''VIVA'''''it Desk.
 
Cuando usamos el parámetro pruebas=1 permitimos abrir más de una sesión de '''''VIVA'''''it Desk; esto puede provocar que el programa no responda y estemos obligados a resetear la aplicación
 
  
puesto="Nombre puesto"
 
|-
 
|Sección [trazas]
 
|| '''nivel=3''' (indica el nivel de trazas suministrado por el sistema)
 
  
'''archivo=1''' (indica que se generará un fichero con las trazas del sistema)
+
[[File:Ejemplo de formulario con botones de grabacion.jpg|centro]]
  
'''consola=0''' (Si el nivel de trazas es 3 no debemos utilizar el valor consola=1, impedirá que arranque el desk)
 
  
'''sobreescribir=1''' Se genera un fichero de trazas para la sesión activa. Cuando el desk se cierra se genera un fichero nuevo perdiendo las trazas de la sesión anterior.
 
  
'''sobreescribir=0''' se genera un fichero de trazas cuando el agente abre el desk y cuando cierra la sesión y abre una nueva se van acumulando las trazas en el mismo fichero.
+
Trazas '''''VIVA'''''it  Desk:
  
Activación de generación de ficheros de trazas "viva-desk.log" en carpeta de aplicaciones
+
gre evliniciarGrabacion infra=20 modo=10 esta=”6/Demanda sin grabar”
|}
 
  
=== Parámetros en invocación a '''''VIVA'''''it Desk ===
+
Para que la grabación bajo demanda esté bien configurada en la traza anterior los valores de '''infra''' y '''modo''' deben ser '''distintos de 0'''.
  
La aplicación '''''VIVA'''''it 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
 
  
=== Instalación y actualización de aplicaciones de puestos de trabajo ===
+
'''<big><sup><big>'''**'''</big></sup> Hemos visto que la grabación Bajo demanda en los Grupos ACD si funciona.</big>'''
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:
+
Para activarla hay que entrar en la configuración del Grupo ACD que queremos grabar y activar la grabación por enrutamiento:
URL="http://IP_Servidor:8180/WSActualizaXML/actualizar.xml"
 
BASE_URL_DESCARGAS="http://IP_servidor:8180/XMLFILES/"
 
  
=== Servicio técnico en '''''VIVA'''''it Desk ===
 
La activación de la funcionalidad de servicio técnico en '''''VIVA'''''it 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 '''''VIVA'''''it Desk. Pulsando el botón derecho del ratón sobre la barra '''''VIVA'''''it Desk accederemos a las capacidades de soporte técnico
 
<br><br>
 
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 
<br><br>
 
  
== Funcionamiento de la plataforma en modo emergencia ==
+
[[File:cap_1.jpg|600px]]
== Accesos Web ==
 
  
{| class="wikitable"
 
|-
 
! Aplicación !! Enlace
 
|-
 
|Portal de administración '''''VIVA'''''it Suite || http://ip_admin:8180/Vivait-Call
 
|-
 
|'''''VIVA'''''it 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
 
|}
 
  
=== Permisos de aplicaciones ===
+
Además indicamos en el modo de grabación: Grabación bajo demanda inicio sin grabar.
Se crean a través del '''portal de administración ''VIVA''it''' . Debe conocerse como funcionan los ejes [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Ejes| ver sección Portal de administracion - General - Ejes]] y que pueden existir hasta seis aplicaciones creadas en la plataforma:
 
  
  
[[File:Permisos-Portal_Administracion.jpg|center]]
+
[[File:cap_2.jpg|600px]]
  
  
La forma como dar permisos de aplicaciones a un usuario está explicada en la [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Asignaci.C3.B3n_de_Permisos_de_Usuario_por_Administrador | sección  Portal de administracion - General - Usuarios ]].
+
En la consola vemos los siguientes datos:
  
== Elementos monitorizados del sistema ==
 
===Generalidades de Zabbix===
 
====Zabbix ====
 
Zabbix es una solución de código abierto que ofrece características de monitorización avanzada de forma tecnica y para el negocio, para todo tipo de servidores, aplicaciones y equipos que forman parte de una red. La versión que utilizamos en '''md'''tel es Zabbix 2.2.2.
 
  
Zabbix  monitoriza los  recursos  de un equipo en forma remota, permite centralizar la información en un servidor que permite visualizar el monitoreo, cuenta con una interfaz de administración vía web y utiliza un mecanismo flexible de la notificación que permita que los usuarios configuren las alarmas basadas email para informar virtualmente cualquier acontecimiento. Esto permite una reacción rápida a los problemas del servidor.
+
[[File:cap_3.jpg|600px]]
 +
 
 +
==== Comprobar que el servidor de grabación está activo ====
  
Para acceder al servidor Zabbix abrimos el navegador y ponemos la dirección de red (IP) de la maquina donde se encuentra instalado el servidor de Zabbix seguido de "/Zabbix.
+
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 ningún resultado implica que tampoco esta activo.
|-
 
|
 
Direccion.IP.Zabbix.Server/zabbix
 
|}
 
  
Zabbix posee documentación tanto en wiki, foros y comunidades.Para ampliar la información se puede visitar:
+
==== Comprobar que los nodos están conectados al servidor de grabación ====
[[http://www.zabbix.com Sitio oficial de Zabbix]]
 
===== Glosario Zabbix =====
 
Se trata de una lista de conceptos básicos de Zabbix, pero para ampliar la información sobre otros términos, visite el [[http://www.zabbix.com Sitio oficial de Zabbix]].
 
* '''host'''
 
:En Zabbix, un host es una entidad que define el elemento en red que se desea monitorizar/supervisar activamente sus recursos locales y aplicaciones. Este puede ser una impresa, router, switch, sensores de temperatura, un servidor, un ordenador,etc, o también una aplicación. La característica de un host es que debe poseer una dirección de red (IP).
 
  
* '''host group'''
+
Debemos fijarnos en la linea de respuesta del comando '''''nc ip_maquina 1114''''', que seria:
:En Zabbix, un host group (grupo host) es una agrupación lógica de los host, como una forma de organizar los dispositivos "Host" registrados en Zabbix para su monitorización. Puede contener hosts y templates.  Los grupos host se utilizan en la asignación de derechos de acceso a los hosts para diferentes grupos de usuarios.
+
{| class="wikitable"
 +
|-
 +
| root@smadavacdrecord1:~# nc localhost 1114
 +
recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423
 +
160112'
  
* '''item'''
+
recordCentral MYSQL cnx=1
:En Zabbix, un item (medida) es el parámetro que deseamos obtener del host, básicamente es una medida especifica que el servidor Zabbix recogerá de los agentes de Zabbix instalados en los host.
 
  
* '''trigger'''
+
recordCentral NAS llamadas=1 segmentos=1
:En Zabbix, un trigger(disparador) es una entidad que define un umbral para detectar la existencia de un problema en un dispositivo.  Son valores recolectados por los "items", se usa para "evaluar" los datos recibidos con condiciones definidas. Las condiciones son de tipo aritmético y lógico.
 
* '''event'''
 
:En Zabbix, un event (evento) es la aparición de un suceso en Zabbix que necesita atención. Por ejemplo, el cambio de estado a raíz de un trigger, el descubrimiento de un nuevo agente (autoregistro),etc.
 
* '''action'''
 
:En Zabbix, una action(acción) son reglas predefinidas para reaccionar a un evento disparado por los triggers, es decir, define qué hacer ante un evento. Consta de operaciones (por ejemplo, una notificacion, comandos remotos) y condiciones (cuando  la operación se lleva a cabo).
 
* '''notification'''
 
:En Zabbix, una notification (notificacion) es la entidad con que Zabbix nos puede notificar (Correo Electrónico,mensajes vía "SMS" o Jabber).
 
* '''template'''
 
:En Zabbix, un témplate (plantilla) viene predefinida en la instalación de Zabbix Server, con el fin de ser aplicada en base al tipo de sistema operativo(Linux, Mac, Window, etc) o en elementos que comparten los mismos parámetros de medición, por ejemplo la carga del procesador, uso de memoria y  uso de recursos de red. Las plantillas son un conjunto de módulos "ITEM, TRIGGERS y GRÁFICAS", que están preconfigurados y listas para ser aplicadas a uno o varios hosts.
 
* '''application'''
 
:En Zabbix, una application (aplicación) es una agrupación lógica de los items.
 
* '''Zabbix server'''
 
:El Zabbix server (servidor de Zabbix) es el proceso central donde están definidas las configuraciones y donde se almacenan todos los datos y estadísticas recogidas de los agentes Zabbix.Consta de una base de datos, una interfaz web y el propio server. Como servidor, se encarga de recoger los datos de los agentes, calcular los triggers, enviar notificaciones, etc.
 
* '''Zabbix agent'''
 
:El zabbix agent (agente de Zabbix)  es un proceso desplegado en los host que son supervisados, que funciona como un servicio y puede funcionar de forma activa y pasiva simultáneamente.
 
  
=====Discovery=====
+
recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305
La funcionalidad discovery(detección) lista los dispositivos que se integran en nuestra red y el tipo de servicios que proporciona. Por ejemplo, si la empresa tuviera cien colas ACDs, y veinticinco VDNS, y en cada cola como veinte medidas, seria muy laborioso registrar una por uno cada uno. 
 
Gracias a esta funcionalidad, se descubre todas las interfaces de red que se tiene, automáticamente y tanto para colas nodos o IVR. Para utilizar esta funcionalidad , se hace el uso de dos script, que se instalan en el momento de instalación de Zabbix en el directorio "/usr/local/sbin", que son:
 
{|
 
|-
 
|
 
'''zabbixDiscoveryQueues.pl''' : script utilizado para buscar colas ACD.
 
  
'''zabbixDiscoveryVDN.pl''' : script utilizado para buscar VDNS.
+
'''recordCentral NODO fase=0 cuarentena='' descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10''''
 
|}
 
|}
La explicación de como configurarla se encuentra en el manual oficial [[https://www.zabbix.com/documentation/2.2/manual/discovery/network_discovery/rule | Zabbix detección de redes]].
 
  
=====Notificaciones=====
+
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.
  
Necesariamente, debe darse de alta al usuario y darse de alta el servidor de correo electrónico para poder ser capaz de enviar correos.
+
==== Comprobar 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.
  
Por otro lado, el formato del correo electrónico y las condiciones de envío de correo al usuario se configura en las acciones. Véase  el [[https://www.zabbix.com/documentation/2.2/manual/quickstart/notification  | manual oficial de Zabbix 2.2]]
+
==== Comprobar 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:
  
=====Usuarios=====
+
{| class="wikitable"
Zabbix permite la organización de usuarios en grupos para establecer los permisos adecuados de acuerdo al tipo de perfil que deseemos crear. Necesariamente un usuario debe permanecer a un grupo o varios grupos.Todos los usuarios acceden a la aplicación de Zabbix a través de la interfaz Web.
 
 
 
Cada usuario Zabbix se le asigna un nombre de usuario único , una contraseña y podemos indicarle que tipo de comunicación que posee, normalmente es vía email, pero puede ser vía a otro tipo de medios. Para mas información ver el [[https://www.zabbix.com/documentation/2.2/manual/web_interface/user_profile || manual oficial ]].
 
 
=====Visualización=====
 
Con Zabbix es posible visualizar los datos como  gráficos, pantallas, mapas y hasta presentaciones cambiantes, entre otros. En este apartado solo nombraremos características esenciales que se tendra que completar con el [[https://www.zabbix.com/documentation/2.2/manual/config/visualisation | manual oficial]]
 
======Graphs======
 
{|
 
 
|-
 
|-
|
+
| root@smadavacdrecord1:~# nc localhost 1114
'''Nota:''' Debe crearse algun item dentro del host para poder utilizar una gráfica.
+
recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423
|}
+
160112'
En Zabbix una gráfica sirve para representar gráficamente los resultados obtenidos de uno item o varios items.
 
[[File:EjemploGrafica.png|center|750px]]
 
Los valores min / avg / max que Zabbix obtiene y representa son de un registro de datos de la tabla tendencias.
 
  
======Screens======
+
recordCentral MYSQL cnx=1
La pantalla refiere a otra característica adaptable de ZABBIX cuál permite que los usuarios creen las pantallas personalizadas dentro de ZABBIX para exhibir la información. Se considera como una colección de gráficas y no depende del host. Una pantalla puede consistir en gráficos simples, gráficos personalizados, integrar mapas, Alertas, gráficos estadísticos o texto llano tal como los 5 valores pasados de un item particular entre otros; y mostrar la información de forma dinámica.
 
  
[[File:EjemploScreen.png|center|750px]]
+
recordCentral NAS llamadas=1 segmentos=1
  
======Maps======
+
recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305
En Zabbix, un map (mapa) es una representación gráfica de la situacion de nuestros dispositivos en red. Es un escenario que muestra nuestra red, aplicaciones y servicios a través de figuras o iconos.  Dichas figuras toman vida en respuesta a los eventos que se dan en nuestro entorno.
 
[[File:EjemploMaps.png|center|750px]]
 
[[File:EstadosMaps.png|center|750px]]
 
  
 +
'''recordCentral NODO fase=0 cuarentena='' descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10''''
 +
|}
  
======Monitorizar el estado de los raid======
+
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.
Los siguientes comandos son necesarios para poder monitorizar el estado de los raid.
 
La orden:
 
  
>hpacucli "ctrl slot=1 logicaldrive 1 show status"
+
==== Comprobación de grabaciones que se hayan quedado enganchadas en un nodo ====
 +
Podemos fijarnos en los dos comandos, para '''''nc ip_maquina 1114''''':
 +
{| class="wikitable"
 +
|-
 +
| root@smadavacdrecord1:~# nc localhost 1114
 +
recordCentral SIS ver='01.2' inic='20140423 094058' alarmas=11041 ultAlar='20140423
 +
160112'
  
nos proporciona el estado de un raid (p.e. logicaldrive 1 (931.5 GB, 1): Interim Recovery Mode).
+
recordCentral MYSQL cnx=1
  
La orden:
+
recordCentral NAS llamadas=1 segmentos=1
>hpacucli "ctrl slot=1 logicaldrive all show status"
 
  
nos proporciona el estado de todos los raid.
+
recordCenral REC llamNum=24901 llamErr=0 segmNum=38906 segmErr=0 retraso=305
  
p.e.:
+
'''recordCentral NODO fase=0 cuarentena='' descarga='8,6,4,7,10,9' gestion='4,6,7,8,9,10''''
logicaldrive 1 (931.5 GB, 1): Interim Recovery Mode
+
|}
  
logicaldrive 2 (1.8 TB, 1): OK.
+
Fijándonos en el campo "cuarentena=''" indica que ninguno de los nodos tiene problemas.
  
Para conseguir información genérica el comando
+
==== Comprobación del estado de ocupación del almacenamiento temporal de grabaciones en un nodo. ====
 
ctrl all show config detail
 
  
nos muestra mucha información y podemos saber el modelo de disco físico que lleva instalado para poder comprar el modelo antes de "operar".
+
Desde un SSH ejecuta el comando '''''df - h''''' en la maquina donde creamos que debe estar ejecutando el proceso recordNod:
 +
 
 +
{|class="wikitable"
 +
|-
 +
! 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
  
===Zabbix en '''MD'''tel===
 
 
 
==== Configuraciones de Zabbix ====
 
 
===== Agentes Zabbix =====
 
{|-
 
|
 
|
 
'''Nota:''' Hay que instalar un agente Zabbix en cada maquina que se quiera monitorizar.
 
 
|}
 
|}
  
El agente de Zabbix puede recoger datos:
+
Nos fijaríamos en la línea marcada en negrita, el campo "Use%" indicara el porcentaje de almacenamiento temporal de grabaciones en un nodo.
*'''De forma pasiva:''' el server contacta al agente pidiéndole un dato (por ejemplo el consumo de CPU en ese instante) y el agente responde al server con ese dato. A esta acción del agente le llamaremos '''Agente activo'''.
 
*'''De forma activa:''' en un primer momento, el server le enviará al agente el listado de items a monitorizar. A partir de ese momento, será el agente que de forma periódica recogerá datos sobre esos ítems y se los hará llegar al server. A esta acción del agente le llamaremos ''''''Agente pasivo''''''.
 
  
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
 
+
===Escuchas e intrusiones en asterisk===
====== Configurar agente de forma pasiva======
+
'''CallSpy''' es una aplicación elaborada para asterisk que permite a un usuario realizar escuchas e  
Para configurar el agente de Zabbix necesitamos acceder a la maquina que actuará como agente, y en el directorio /etc/zabbix modificar el fichero '''zabbix_agentd.conf''' e indicar cual es la dirección de red (IP) del servidor Zabbix.
+
intrusiones en llamadas.
 
+
En realidad tenemos dos aplicaciones en asterisk, CallSpy y CallSpyee.  
{|  
+
====CallSpy ====
 +
{|
 
|-
 
|-
 
|  
 
|  
  ##### Passive checks related
+
  '''Nota:''' Como mucho se pueden tener a dieciséis personas al mismo tiempo usando esta aplicación.  
### Option: Server
 
#      List of comma delimited IP addresses (or hostnames) of Zabbix servers.
 
#      Incoming connections will be accepted only from the hosts listed here.
 
#      If IPv6 support is enabled then '127.0.0.1', '::127.0.0.1', '::ffff:127.0.0.1'
 
#      are treated equall$
 
#
 
# Mandatory: no
 
# Default:
 
Server= IP.Server Zabbix.
 
 
|}
 
|}
Tras la configuración del fichero, debemos reiniciar el servicio de los agentes.
+
 
 +
Como hemos mencionado anteriormente, esta aplicación permite la escucha de llamadas y,
 +
opcionalmente, realiza la función de intrusión. Tiene tres opciones de configuración obligatorios
 +
que mostramos a continuación:
 +
 
 
{|
 
{|
 
|-
 
|-
 
|
 
|
  sudo service zabbix-agent restart
+
  CallSpy(<tipoEspiado>,<expRegEspiado>,<parametrosConf>)
 +
 
 
|}
 
|}
 
+
La opción '''<tipoEspiado>''' se refiere a que tipo de objeto que podemos espiar correspondiente, solo debe elegirse un único tipo:
====== Configurar agente de forma activa ======
+
*'''c:''' escuchar una cola
 
+
*'''v:''' escuchar un vdn
Para configurar el agente de Zabbix necesitamos acceder a la máquina que actuará como agente, y en el directorio /etc/zabbix modificar el fichero '''zabbix_agentd.conf''' e indicar cual es la dirección de red (IP) del servidor Zabbix.
+
*'''a:''' escuchar a un agente  
 
+
*'''e:''' escuchar extensión
{|
+
La opción '''<expRegEspiado>''' representa el número de la cola, VDN, agente o extensión que queremos escuchar. Tiene que ser una expresión regular.
|-
+
La opción '''<parametrosConf>''' se refiera a los parámetros de configuración para la llamada que podemos espiar, se pueden combinar o juntar :
|
+
*'''q:''' Desactiva el 'beep' al comienzo de cada nueva llamada.
##### Active checks related
+
*'''v([value]):''' Ajusta el volumen en el rango -4 a 4 (más alto, mas volumen).  
### Option: ServerActive
+
*'''e:''' Habilita el que se pueda cambiar a otra llamada de la misma extensión.
#      List of comma delimited IP:port (or hostname:port) pairs of Zabbix serv$
+
*'''w:''' Habilita el que se pueda activar la intrusión (whisper).
#      If port is not specified, default port is used.
+
Una vez iniciada la escucha, solo falta que entre una llamada al objetivo que estemos espiando. Al
#      IPv6 addresses must be enclosed in square brackets if port for that hos$
+
iniciar la escucha, se puede hacer lo siguiente:
#      If port is not specified, square brackets for IPv6 addresses are option$
+
*Pulsando '''#''' modifica el volumen de escucha.  
#       If this parameter is not specified, active checks are disabled.
+
*Pulsando '''*''' cambia a una nueva llamada.  
#      Example: ServerActive=127.0.0.1:20051,zabbix.domain,[::1]:30051,::1,[12$
+
*Pulsando '''1''' si esta habilitado, cambia a otra llamada de la misma extensión.  
#
+
*Pulsando '''2''' si esta habilitado, inicia la función de intrusión.
# Mandatory: no
+
*Pulsando '''3''' desactiva la función de intrusión.
# Default:
+
====CallSpyee (espiado)====
ServerActive=127.0.0.1
+
Mediante esta aplicación indicamos los parámetros que permite a una llamada ser seleccionada para
--------------------------sección separada----------------------------
+
escuchar. Las opciones de configuración son:  
### Option: UserParameter
+
{|
  #      User-defined parameter to monitor. There can be several user-defined pa$
+
|-
  #      Format: UserParameter=<key>,<shell command>
+
|
#      See 'zabbix_agentd' directory for examples.
+
  CallSpyee([CID_NUM],[cola],[vdn],[agen],[exten])
#
+
  <small>'''Nota:'''No son parámetros obligatorios, por lo que no hace falta rellenar todos los campos pero si respetar sus posiciones separadas por comas.<small>
# Mandatory: no
 
# Default:
 
# UserParameter=
 
User_parameters:asterisk.pid, /usr/bin/asterisk -rx 'core show chanels'|grep 'active calls'| cat -d -f 1
 
 
|}
 
|}
 +
La explicación de los parámetros es la siguiente:
 +
*'''CID_NUM:''' representa el call ID de la llamadas
 +
*'''cola:'''representa el número de la cola que se quiere espiar (${QUEUE} ).
 +
*'''vdn:'''  representa el número del VDN que se quiere espiar (${VDN} ).
 +
*'''agen:''' representa el número del agente que se quiere espiar.
 +
*'''exten:''' representa el número de la extensión que se quiere espiar (${EXTENSION}) .
  
El parámetro '''User_parameters''' tiene un formato de este estilo:
+
Por ejemplo si queremos escuchar todas las llamadas en las que participa una extensión determinada pondremos en la macro de extensiones:  
 
{|
 
{|
 
|-
 
|-
 
|
 
|
  User_parameters: NombreMedida, comando.
+
  exten => s,n,CallSpyee(,,,${EXTENSION})
 
|}
 
|}
  
El nombre de la medida se refiere al nombre que demos a la aplicación , no hace falta que exista una aplicación con ese nombre en Zabbix, y el comando , es el comando remoto que tiene que ejecutar el servidor Zabbix. Posiblemente necesita darse permisos para ejecutar el comando y siempre debe devolver un valor (un numero o un tiempo) que el servidor Zabbix puede manejar.
+
====Cambios para el dialplan de asterisk====
Tras la configuración del fichero, debemos reiniciar el servicio de los agentes.
+
El funcionamiento de este tipo de servicio conlleva un cambio en el dialplan de asterisk. En cada macro correspondiente se pondrá los diferentes CallSpyee para VDN, colas  , extensiones y agentes.
 +
Pasos a seguir:
 +
*Paso 1. Creación de un código de intrusión para cada tipo según necesidad (cola, VDN, agente y  
 +
extensión).  
 
{|
 
{|
 
|-
 
|-
 
|
 
|
  sudo service zabbix-agent restart
+
  Ejemplo '''MD'''tel:  declaramos como código de intrusión a Agente *44*NUMERO
 +
;==========================================
 +
;======== Intrusion a Agente
 +
;==========================================
 +
exten => _*44*X.,1,set(CadMarcar=intrusionEspiado)
 +
exten => _*44*X.,n,set(DesL=SERVICIO)
 +
exten => _*44*X.,n,set(datoServicio=^${EXTEN:4})
 +
exten => _*44*X.,n,Goto(finMacro,1)
 +
<small>'''Nota:''' En la tercera línea podemos observar la expresión regular que se le pasara al CallSpy correspondiente con el número marcado por el espia. <small>
 
|}
 
|}
  
===== Scripts del Servidor Zabbix =====
+
*Paso 2.Llamar a CallSpy con la configuración deseada.
 
{|
 
{|
 +
|-
 
|
 
|
|
+
  Ejemplo '''MD'''tel: llamada a CallSpy especificando que vamos a espiar una cola (la c del primer parámetro, con la
  '''Nota''': <small>No olvidar que en la misma maquina del server Zabbix, debe configurarse como agente de Zabbix.</small>
+
extensión introducida en el código de intrusión y con whisper, es decir, función de intrusión habilitada.  
 +
;------------------------------------------------------------------------
 +
; Intrusion a Espiado
 +
;------------------------------------------------------------------------
 +
exten => intrusionEspiado,1,NoOp
 +
exten => intrusionEspiado,n,GotoIf($["${datoServicio}"=""]?colgar)
 +
exten => intrusionEspiado,n,CallSpy(c,${datoServicio},w)
 +
exten => intrusionEspiado,n(colgar),Hangup
 
|}
 
|}
Después de realizar la [[# Instalación de Zabbix | Instalación de Zabbix ]] correctamente. Se han creado otros ficheros scripts (''scripts propios de '''md'''tel'') que facilitarán la petición del servidor a los agentes activos, para poder parametrizar todos los elementos del negocio que suelen monitorizarse.
+
* Paso 3. Llamar a CallSpyee con la configuración de las llamadas candidatas a ser escuchadas.
Dependiendo de lo que vaya a monitorizarse necesitaremos algún script o todos. Algunos nos informan sobre elementos de negocio, saber si asterisk funciona , monitorizar el CTI (lanzara nc localhost 1111) , controlar el Intz-Nimitz, comprobar si funciona motalsal, ect.
 
 
 
Cada script se exportara a los host, para que pueda facilitar los datos que pide el servidor Zabbix y configurarse.
 
Por ejemplo,para monitorizar las llamadas en curso del ACD, agentes conectados, agentes desconectados, etc.
 
Todos los scripts se deben colocar en el directorio /usr/local/sbin con permisos 755, su nombre es parecido a "zabbixSenderXXXXX.pl"
 
 
{|
 
{|
 
|-
 
|-
|  
+
|
  ls /usr/local/sbin/ |grep zabbixSender
+
  Ejemplo '''MD'''tel:
'''zabbixSenderACDBD.pl'''
+
  exten => s,n,CallSpyee(,,,,${EXTENSION}) → Para extensiones
'''zabbixSenderACD.pl'''
+
  exten => s,n,CallSpyee(,${QUEUE},,,) → Llamadas espiadas por cola
'''zabbixSenderCTI.pl'''
+
  exten => s,n,CallSpyee(,,${VDN},,) → Llamadas espiadas por VDN
'''zabbixSender-intz-nimitz.pl'''
 
  '''zabbixSenderMotorSal.pl'''
 
'''zabbixSenderMyACDSuperv.pl'''
 
  '''zabbixSenderRecordNodo.pl'''
 
  '''zabbixSenderRecordCentral.pl'''
 
 
|}
 
|}
  
Se crea una tarea programada en linux para poder ejecutarse los scripts, programando el tiempo en que debe ejecutarse.
+
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
Si visualizo que "............" aparece:
+
=== Calendarios ===
  
*****  root zabbix
+
{| class="wikitable"
 +
| Nota: '''En la versión de VIVAit 3.5 , Se tiene que instalar el nuevo servidor de DaviCal. '''
 +
|}
  
======zabbixSenderACDBD.pl======
+
Para la configuración de los calendarios en la versión VIVAit  3.5 , se tiene que instalar el nuevo servidor DaviCal en una máquina aparte.
  
'''Uso:''' Obtiene diversos valores por cada cola, estados de agente por cola y estados de agente generales.
+
Se adjunta un manual para su instalación:  
  
'''Ubicación:''' Servidor BDTR.
 
  
'''Parámetros:''' Ruta al archivo de configuración (Por ejemplo: ''/etc/MDtel/zabbixSenderACDBD.pconf'')
 
  
'''Archivo de configuración:''' zabbixSenderACDBD.pconf
+
<big>'''[[medio:Servidor_Calendarios_DAViCal.pdf|Manual de instalación de servidor de calendarios para '''''<span style="color:#144F9B">VIVA</span>'''''it 3.5]]'''</big>
  
{|
 
|-
 
|
 
<small>'''$db:''' Nombre de la BBDD (normalmente nimitz)
 
'''$dbHost:''' Dirección IP del servidor de BBDD de TR (normalmente BDTR)
 
'''$dbPort:''' Puerto MySQL (normalmente 3306)
 
'''$dbUsuario:''' Usuario MySQL (normalmente nimitz)
 
'''$dbClave:''' Clave del usuario
 
'''$sZab:''' Dirección IP del servidor Zabbix
 
'''$hZab:''' Nombre del host Zabbix (normalmente el nombre de máquina, tal y como se configura en
 
zabbix_agentd.conf o en el host en la web de Zabbix)</small>
 
|}
 
  
  
======zabbixSenderACD.pl======
 
  
'''Uso:''' Obtener el PID de Asterisk para revisar si se ha reiniciado en caso de que cambie.
 
  
'''Ubicación:''' Servidor ACD.
 
  
'''Parámetros:''' Ruta al archivo de configuración (Por ejemplo: ''/etc/MDtel/zabbixSenderACD.pconf'').
 
  
'''Archivo de configuración:''' zabbixSenderACDBD.pconf.
+
Para la configuración de los Calendarios se hace uso de '''CalDAV''', estándar de Internet que permite a un cliente acceder a información de planificación en un servidor remoto. Permite que varios clientes accedan a la misma información, facilitando la cooperación. Muchas aplicaciones, tanto clientes como servidores, son compatibles con este protocolo.
  
{|
+
Si deseamos crear un calendario en la plataforma '''VIVAit''' podemos hacerlo siguiendo el siguiente enlace:   
|-
+
Para comprobar que el servidor de calendarios funciona correctamente bastaría con cargar en la barra de direcciones la siguiente url: [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Calendarios |Calendarios]]
|
 
<small>'''$db:''' Nombre de la BBDD (normalmente nimitz)
 
'''$dbHost:''' Dirección IP del servidor de BBDD de TR (normalmente BDTR)
 
  '''$dbPort:''' Puerto MySQL (normalmente 3306)
 
  '''$dbUsuario:''' Usuario MySQL (normalmente nimitz)
 
'''$dbClave:''' Clave del usuario
 
'''$sZab:''' Dirección IP del servidor Zabbix
 
'''$hZab:''' Nombre del host Zabbix (normalmente el nombre de máquina, tal y como se configura en
 
zabbix_agentd.conf o en el host en la web de Zabbix)</small>
 
|}
 
       
 
  
======zabbixSenderCTI.pl======
+
http://${NODO.HOST}/dav/html/cal.php/calendars/${DAV.CUENTA}/${DAV.CALENDARIO}
  
'''Uso:''' Obtener estado y los distintos valores de vivait-cti.
+
donde,
  
'''Ubicación:''' Servidor donde se ejecute vivait-cti. Normalmente el servidor ACD.
+
* '''NODO.HOST:''' es la ip del servidor calendar
 +
* '''DAV.CUENTA:''' hace referencia a la cuenta de usuario
 +
* '''DAV.CALENDARIO:''' hace referencia el nombre de la cuenta
  
'''Parámetros:'''
+
Una vez que se carga la url sabremos que el servidor funciona correctamente si visualizamos lo siguiente:
{|
 
|-
 
|
 
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 
|}
 
  
 +
[[Archivo:Captura de pantalla de 2016-07-21 12_43_58.png || 1020px|center]]
  
======zabbixSender-intz-nimitz.pl======
 
  
'''Uso:''' Obtener estado y los distintos valores de intz-nimitz.
+
Si el sistema nos pide usuario y clave querrá decir que el servidor de calendarios está operativo en esa maquina
  
'''Ubicación:''' Servidor donde se ejecute intz-nimitz.
+
Para comprobar que funciona en la consola de asterisk usaremos los comandos
 +
calendar show calendars
 +
calendar show calendar [nombreCalendario]
  
'''Parámetros:'''
+
  '''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
|-
+
      - En la máquina donde esté instalado el servidor de calendarios apuntar a la IP de la BDTR (/var/www/dav/config.php)
|
 
  <small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 
|}
 
       
 
  
======zabbixSenderMotorSal.pl======
+
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
'''Uso:''' Obtener estado y los distintos valores de motorSal.
+
=== 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.
  
'''Ubicación:''' Servidor donde se ejecute motorSal.
+
El formato del mensaje se compone de tres campos :
  
'''Parámetros:'''
+
* 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.
|
 
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 
|}
 
  
======zabbixSenderMyACDSuperv.pl======
+
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 ''VIVA''it'''  configurando unos parámetros para un usuario llamado ''Rastreo BBDD" y ''Rastreo Syslog''. Para más información[[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Pesta.C3.B1a_ACD | ver sección  Portal de administración - General - Usuarios - Pestaña ACD  ]].
  
'''Uso:''' Obtener estado y los distintos valores de myAcdSuperv.
+
{| class="wikitable" border="0"  align="top"
 
+
|-
'''Ubicación:''' Servidor donde se ejecute myAcdSuperv.
+
| align="center" style="background:Lavender; color:Black" |<big>'''Elemento'''</big>
 
+
|align="center" style="background:Lavender; color:Black" | <big>'''Procedimiento'''</big>
'''Parámetros:'''
+
|-
{|
+
!colspan="2" width="60 px" style="background:Lavender; color:Black"|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
 
|-
 
|-
|
+
!colspan="2" width="60 px" style="background:Lavender; color:Black"|Diagnostico
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
 
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
 
|}
 
 
 
======zabbixSenderRecordNodo.pl======
 
 
 
'''Uso:''' Obtener estado y los distintos valores de recordNodo.
 
 
 
'''Ubicación:''' Servidor donde se ejecute recordNodo.
 
 
 
'''Parámetros:'''
 
{|
 
 
|-
 
|-
|  
+
|Registro de logs||/var/log/MDtel/vivait-desk.log
<small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
+
Fichero del día actual. se guardan los 30
'''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
+
anteriores comprimidos en tar.g
 
|}
 
|}
  
  
======zabbixSenderRecordCentral.pl======
 
'''Uso:''' Obtener estado y los distintos valores de recordCentral.
 
  
'''Ubicación:''' Servidor donde se ejecute recordCentral.
+
'''Ejemplo 30-vivait-desk.conf:'''
 
+
'''Parámetros:'''
+
#  Default rules for rsyslog.
{|
+
#
|-
+
#            For more information see rsyslog.conf(5) and /etc/rsyslog.conf
|
+
  <small>'''--sZab:''' Ip del servidor Zabbix. Si se omite, se asume localhost.
+
#
  '''--hZab:''' Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.</small>
+
  # First some standard log files. Log by facility.
|}
+
  #
 +
local4.*            -/var/log/MDtel/vivait-desk.log
 +
local5.*              -/var/log/MDtel/rastreo.log
  
  
A continuación se muestra una tabla resumen de los distintos scripts y sus funcionalidades:  
+
Es muy importante comprobar que el servidor de '''syslog''' escucha por el puerto '''514''':
 +
 +
#################
 +
#### MODULES ####
 +
#################
 +
 +
module(load="imuxsock") # provides support for local system logging
 +
module(load="imklog")  # provides kernel logging support
 +
#module(load="immark")  # provides --MARK-- message capability
 +
 +
# provides UDP syslog reception
 +
module(load="imudp")
 +
input(type="imudp" port="514")
 +
 +
# provides TCP syslog reception
 +
module(load="imtcp")
 +
input(type="imtcp" port="514")
 +
 +
# Enable non-kernel facility klog messages
 +
$KLogPermitNonKernelFacility on
 +
 +
###########################
 +
#### GLOBAL DIRECTIVES ####
 +
###########################
  
[[Archivo:Zabbix_scripts.png |960px]]
+
=== Generación de un Core ===
 +
Un Core es la memoria de un programa.
  
====== Dimensionamiento del servidor (Startpollers) ======
+
Para generar un Core rápido con Asterisk hay que hacer lo siguiente:
{|
 
|
 
|
 
'''Nota''': <small>EL parámetro StartPollers es un <u>parámetro numérico</u> que forma parte del fichero de configuración
 
del servidor Zabbix(zabbix_server.conf). Por defecto el servidor Zabbix está configurado para
 
iniciar con cinco startpollers.</small>
 
|}
 
  
El servidor Zabbix puede hacer peticiones a los agentes de las medidas que necesita o quiere. O en caso contrario los agentes envian en un tiempo determinado la información al servidor. Para recibir todas estas peticiones necesitamos los pollers. 
+
    Ejecutar ps aux | grep asterisk y coger el PID del programa
 +
    gdb /usr/sbin/asterisk [PID]
 +
    gcore [file]
  
Los poller son los procesos encargados de recibir todas las peticiones de medidas. Aumentaremos su cantidad dependiendo de la necesitad que tengamos. Para ello podemos observar la queue , que es la encargada de almacenar un listado de todas las cosas que están pedidas para medirse y recibirse.  SI por ejemplo esta cola (queue) muestra mas de mil medidas seguramente estos pollers sean un cuello de botella y habrá que aumentar su numero.
+
<br><br>
 
+
<div style="
=====Templates=====
+
  text-align:right;
 
+
  margin-top:20px;
Zabbix cuenta con templates (plantillas) que facilitan la tarea de "Registrar Equipos y Dispositivos" y agregarles métricas; acelerar el despliegue de las tareas de supervisión en un host; aplicar cambios masivos a tareas de supervisión. En '''md'''tel hemos creado plantillas propias que facilitan estos procesos, los cuales necesitaremos [[#Importar templates |importar templates]].
+
  padding:8px;
 
+
  border:1px solid #ccc;
Las plantillas están vinculados directamente a los hosts individuales, por tanto se necesitaran utilizar en cada host.
+
  background-color:#f9f9f9;
 
+
  border-radius:6px;
Automáticamente, cada template rellena por item las aplicaciones, trigers, alarmas,gráficos,... etc.
+
  display:inline-block;
 
+
">
A continuación, se muestran los distintos bloques de funciones de la instalación en función de cada template:
+
[[File:flecha_verde.png|20px|link=#Diagnósticos y operaciones básicas en VIVAit]][[#Diagnósticos y operaciones básicas en VIVAit | Volver arriba]]
 
+
</div>
{| class="wikitable" style="text-align:center;"
+
<div style="
|-  
+
  text-align:right;
! Templates !! Se instalan en general
+
  margin-top:20px;
|-
+
  padding:8px;
| DRBD|| SI (si clúster)
+
  border:1px solid #ccc;
|-
+
  background-color:#f9f9f9;
| motorSal|| -
+
  border-radius:6px;
|-  
+
  display:inline-block;
| Vivait-Suite ACD|| -
+
">
|-
+
[[File:Índice_azul.png|20px|link=#toc]][[#toc | Ir al índice]]
| Vivait-Suite BBDD|| -
+
</div>
|-  
+
<div style="
| Vivait-Suite Record|| -
+
  text-align:right;
|-  
+
  margin-top:20px;
| Vivait-Suite GW|| -
+
  padding:8px;
|-
+
  border:1px solid #ccc;
| Vivait-Call Asterisk|| -
+
  background-color:#f9f9f9;
|-
+
  border-radius:6px;
| Vivait-Call bdCentral|| -
+
  display:inline-block;
|-  
+
">
| Vivait-Call bdNodo|| si
+
[[File:casa.png|20px|link=#]][[# | Página Principal]]
|-
+
</div>
| cambiarPerfil_Cal|| -
+
<br><br>
|-  
 
| Template App Zabbix Server|| -
 
|-  
 
| Template_OS_Linux*|| si(si no posee ip virtuales de clúster)
 
|-
 
| Template_App_MySQL|| si
 
|-
 
|}
 
  
 +
== puntos a reasignar ==
 +
===  Servidor de grabación ===
 +
==== 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.
  
{| class="wikitable" style="text-align:center;"
+
La grabación indica donde se encuentra mediante el campo E_UBICACION_GRABACION, que puede tener los siguientes valores:
|+ '''Dependiendo del tipo de nodo:'''
+
*Sin definir (0)
|-
+
*En línea (10): Las grabaciones se encuentran en el servidor de grabaciones.
! Templates !! ACD !! Corporativo/GW
+
*Fuera de línea (20): las grabaciones se encuentran en una ubicación externa.
|-
 
| DRBD|| - || -
 
|-
 
| motorSal|| - || -
 
|-
 
| Vivait-Suite ACD|| Si || -
 
|-
 
| Vivait-Suite BBDD|| - || -
 
|-
 
| Vivait-Suite Record|| - || -
 
|-
 
| Vivait-Suite GW|| - || Si
 
|-
 
| Vivait-Call Asterisk|| - || Si
 
|-
 
| Vivait-Call bdCentral|| - || -
 
|-
 
| Vivait-Call bdNodo|| - || -
 
|-
 
| cambiarPerfil_Cal|| - || -
 
|-
 
| Template App Zabbix Server|| - || -
 
|-
 
| Template_OS_Linux*|| - || -
 
|-
 
| Template_App_MySQL|| - || -
 
|-
 
|}
 
  
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
 +
=== 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 '''''VIVA'''''it Reporting”.
  
{| class="wikitable" style="text-align:center;"
+
==== Formato de fichero de intercambio para '''''VIVA'''''it Reporting ====
|+ '''Dependiendo del tipo de Base de dato'''s:
+
{| class="wikitable"
|-  
+
|-
! Templates !! BBDD <br />Tiempo Real !! BBDD<br /> Réplica !! BBDD Copia
+
! Nombre !! Descripción !! Ejemplo
|-  
+
|-
| DRBD|| - || - || -
+
| colspan="3"| Selección de registros
|-  
+
|-
| motorSal|| Si(si ACD) || - || -
+
| SQL_selec || Expresión SQL que se añadirá al where a la SQL principal. || C_ORIGEN like '6%' and C_COD_CLIENTE= '023'
|-
+
|-
| Vivait-Suite ACD|| - || - || -
+
| SQL_select_leido || Filtro de selección legible
|-
+
|| Skill igual a 60310
| Vivait-Suite BBDD|| si || si || si
+
|-
|-  
+
| 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
| Vivait-Suite Record|| - || - || -
+
|-
|-  
+
| colspan="3"|  Salida
| Vivait-Suite GW|| - || - || -
+
|-
|-  
+
| FIC_extension || Extensión de fichero de salida: PDF, XLSX, CSV || PDF
| Vivait-Call Asterisk|| - || - || -
+
|-
|-  
+
| FIC_tipo_entrega || 'P': Pantalla, 'D': Directorio, 'C': Correo || D
| Vivait-Call bdCentral|| si || - || -
+
|-
|-  
+
| FIC_destino || Si 'C', dirección de correo, si 'D', ruta del directorio || D:\informes\
| Vivait-Call bdNodo|| - || - || -
+
|-
|-  
+
| colspan="3"| Plantilla
| cambiarPerfil_Cal|| - || - || -
+
|-
|-  
+
| INF_modelo || Ruta del fichero de plantilla || C:\Modelos\llamadas.rep
| Template App Zabbix Server|| - || - || -
+
|-
|-  
+
| INF_descripción || Descripción del informe || Informe detallado de llamadas
| Template_OS_Linux*|| - || - || -
+
|-
|-  
+
| colspan="3"| Base de datos
| Template_App_MySQL|| - || - || -
+
|-
 +
| 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 ||  
 +
|-
 +
| colspan="3"| 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”
  
{| class="wikitable" style="text-align:center;"
+
Ejemplo de fichero:
|-
+
{| class="wikitable"
! Templates !! Administración
+
|-
|-  
+
| SQL_selec=(DAT_ACUMULADOS_COLAS.ID_COLA in (11))
| DRBD|| -
 
|-
 
| motorSal|| -
 
|-
 
| Vivait-Suite ACD|| -
 
|-
 
| Vivait-Suite BBDD|| -
 
|-
 
| Vivait-Suite Record|| -
 
|-
 
| Vivait-Suite GW|| -
 
|-
 
| Vivait-Call Asterisk|| -
 
|-
 
| Vivait-Call bdCentral|| -
 
|-
 
| Vivait-Call bdNodo|| -
 
|-
 
| cambiarPerfil_Cal||SI (si posee servidor calendarios)
 
|-
 
| Template App Zabbix Server|| -
 
|-
 
| Template_OS_Linux*|| -
 
|-
 
| Template_App_MySQL|| -
 
|-
 
|}
 
  
 +
SQL_select_leido=Skill igual a 60310
  
 +
SQL_orden=
 +
FIC_extension=pdf
  
{| class="wikitable" style="text-align:center;"
+
FIC_tipo_entrega=P
|-
 
! Templates !! Servidor de grabaciones
 
|-
 
| DRBD|| -
 
|-
 
| motorSal|| -
 
|-
 
| Vivait-Suite ACD|| -
 
|-
 
| Vivait-Suite BBDD|| -
 
|-
 
| Vivait-Suite Record|| Si
 
|-
 
| Vivait-Suite GW|| -
 
|-
 
| Vivait-Call Asterisk|| -
 
|-
 
| Vivait-Call bdCentral|| -
 
|-
 
| Vivait-Call bdNodo|| -
 
|-
 
| cambiarPerfil_Cal||-
 
|-
 
| Template App Zabbix Server|| -
 
|-
 
| Template_OS_Linux*|| -
 
|-
 
| Template_App_MySQL|| -
 
|-
 
|}
 
  
 +
FIC_destino=C:\
  
 +
INF_modelo=skill_setsi.rep
  
{| class="wikitable" style="text-align:center;"
+
INF_descripcion=Skill. SETSI
|+ '''Monitorización'''
+
 
|-
+
BD_ip=172.25.1.2
! Templates !! General !! Contact Center
+
 
|-
+
BD_puerto=3306
| DRBD|| - || -
+
 
|-
+
BD_base_datos=nimitz
| motorSal|| - || -
+
 
|-
+
BD_usuario=nimitz
| Vivait-Suite ACD|| - || -
+
 
|-
+
BD_clave=UIk5jNY9PVX5ogg=
| Vivait-Suite BBDD|| - || -
+
 
|-  
+
PAR_desde_vis=-
| Vivait-Suite Record|| - || -
+
 
|-
+
PAR_hasta_vis=-
| Vivait-Suite GW|| - || -  
+
 
|-
+
PAR_01=
| Vivait-Call Asterisk|| - || -
 
|-
 
| Vivait-Call bdCentral|| - || -
 
|-
 
| Vivait-Call bdNodo|| - || -
 
|-
 
| cambiarPerfil_Cal|| - || -
 
|-
 
| Template App Zabbix Server|| si || -
 
|-
 
| Template_OS_Linux*|| - || -
 
|-
 
| Template_App_MySQL|| - || -
 
|-
 
 
|}
 
|}
  
  
 +
==== Resumen de significado de columnas en reporting histórico ====
 +
Esta información se puede consultar en el siguiente enlace:
  
======'''Resumen'''======
+
http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Documentacion_de_usuario_VIVAit_Suite_3.3#Resumen_del_valor_de_las_columnas_que_aparecen_en_los_informes
  
{| class="wikitable"
+
<!--
|-
+
===== Agente,asistencia diaria y agente. Asistencia diaria del grupo =====
!Plantillas MDTEL !! Trigger !! Descripción !! Severidad !! Actuación a llevar a cabo
+
 
|-
+
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
|Template DRBD||DRBD balanceado en {HOST.NAME}||El DRBD ha balanceado en Host||Desastre||Revisar ambos nodos del cluster.
+
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
Comprobar que el DRBD está sincronizado (cat /proc/drbd).
+
o realizadas por el agente excluido el tiempo de retención.<br/>
|-
+
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
|Template DRBD||DRBD desconectado en {HOST.NAME}||El DRBD esta desconectado en Host||Desastre||Revisar Host. Comprobar estado del DRBD (cat /proc/drbd)
+
tras finalizar las llamadas contestadas por el agente.<br/>
|-
+
'''• Tiempo de llamado:''' Tiempo de ring en llamadas ACD.<br/>
|Template DRBD||DRBD no actualizado en {HOST.NAME}||Estado de disco invalido en DRBD (cat /proc/drbd no devuelve UpToDate)||Desastre||Forzar sincronización del DRBD
+
'''• Tiempo disponible:''' Tiempo que el agente estuvo conectado y no está
|-
+
incluido en ninguno de los anteriores.<br/>
|Template motorSal||motorSal caido||El motorSal esta caido||Desastre||Reiniciar motorSal.  
+
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa<br/>
Revisar log (var/log/motorsal.log) para averiguar la causa
+
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas por
|-
+
el agente.<br/>
|Template Vivait-Call Asterisk||Asterisk reiniciado||El Asterisk se ha reiniciado||Alta||Comprobar que ha arrancado correctamente.
+
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
+
el agente.<br/>
|-
+
'''• Llamadas transferidas:''' Número de llamadas ACD que fueron
|Template Vivait-Call Asterisk||Error en enrutamiento||Error en enrutamiento||Baja||Revisar full de asterisk para comprobar donde está el error.  
+
transferidas por el agente.
Corregir (añadir prerutas o lo que sea necesario).
+
 
|-
+
===== Agente. Aux y Grupo Aux =====
|Template Vivait-Call Asterisk||No hay extensiones registradas||No hay extensiones registradas||Alta||Revisar full de asterisk para comprobar donde está el error.  
+
 
Revisar sip_WEB.conf
+
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
|-
+
el agente.<br/>
|Template Vivait-Call Asterisk||No hay trunks activos||No hay trunks activos||Baja||Revisar full de asterisk para comprobar donde está el error.  
+
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
Revisar enlaces en portal.
+
o realizadas por el agente excluido el tiempo de retención.<br/>
|-
+
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
|Template Vivait-Call bdCentral||Error en bdCentral||Se ha dado un error en el bdCentrlal||Alta||Revisar BBDD central.
+
tras finalizar las llamadas contestadas por el agente.<br/>
|-
+
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
|Template Vivait-Call cambiarPerfil_Cal||cambiarPerfil_Cal no ejecutado||No se ha ejecutado cambiarPerfil||Alta||Revisar log (/var/log/cambiarPerfil_Cal.log).
+
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas por
Actuar en consecuencia
+
el agente.<br/>
|-
+
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa.<br/>
|Template Vivait-Call cambiarPerfil_Cal||Error en cambiarPerfil_Cal||Ha dado un error al cambiar el perfil||Alta||Revisar log (/var/log/cambiarPerfil_Cal.log).
+
'''• Desglose de tiempos AUX:''' Tiempo que el agente estuvo en cada uno
Actuar en consecuencia
+
de los motivos de pausa.
|-
+
 
|Template Vivait-Suite ACD||PID Asterisk cambiado||El PID de Asterisk ha cambiado||Desastre||Comprobar que ha arrancado correctamente.  
+
===== Agente. Resumen diario =====
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura
+
 
|-
+
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
|Template Vivait-Suite ACD||VivaitCTI caido||El CTI está caido||Alta||Reiniciar vivait-cti. Comprobar en log (/var/log/vivait-cti.log) la causa
+
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
|-
+
o realizadas por el agente excluido el tiempo de retención.<br/>
|Template Vivait-Suite ACD||Vivait-CTI desconectado de Asterisk||El CTI está desconetado de Asterisk || Desastre ||Comprobar que ha arrancado correctamente.
+
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
+
tras finalizar las llamadas contestadas por el agente.<br/>
|-
+
'''• Tiempo de llamado:''' Tiempo de ring en llamadas ACD.<br/>
|Template Vivait-Suite BBDD||MyACDSuperV caido||MyACDSuperV esta caido||Alta||Iniciar myAcdSuperv. Comprobar en log /var/log/myAcdSuperv.log) la causa.
+
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa.<br/>
|-
+
'''• Tiempo disponible:''' Tiempo que el agente estuvo conectado y no está
|Template Vivait-Suite GW||{HOSTNAME} Asterisk caido||El asterisk en esa maquina se encuentra caido||Alta||Comprobar que ha arrancado correctamente.  
+
incluido en ninguno de los anteriores.<br/>
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
+
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas.<br/>
|-
+
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
|Template Vivait-Suite GW||{HOSTNAME} Asterisk PID cambiado||El PID de Asterisk ha cambiado||Alta||Comprobar que ha arrancado correctamente.
+
el agente.<br/>
Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.
+
'''• Llamadas entrada Ext:''' Número de llamadas entrantes NO ACD a la
|-
+
extensión.<br/>
|Template Vivait-Suite GW||{HOSTNAME} error en numero de enlaces||Existe un error en el numero de enlaces||Baja||Revisar full de asterisk para comprobar donde está el error.
+
'''• Llamadas salida Ext:''' Número de llamadas salientes NO ACD desde la
Revisar sip_WEB.conf
+
extensión.<br/>
|-
+
'''• Llamadas transferidas:''' Número de llamadas ACD que fueron
|Template Vivait-Suite GW||{HOSTNAME} error en numero procesos asterisk||Existe un error en el numero de procesos de asterisk||Alta||Comprobar con “ps aux | grep aster” cuantos asterisk aparecen.  
+
transferidas por el agente.<br/>
Solo tiene que aparecer un safe_asterisk y un asterisk.
+
'''• Llamadas retenidas:''' Número de retenciones que sufrieron las
|-
+
llamadas contestadas por el agente.<br/>
|Template Vivait-Suite GW||Alarma en recordnodo||Alarma en recordnodo||Media||Revisar log (/var/log/record/recordNodo.log).
+
'''• Tiempo promedio ACD:''' Tiempo ACD/ Llamadas ACD.<br/>
Actuar en consecuencia.
+
'''• Tiempo promedio ACW:''' TiempoACW/Llamadas ACD.<br/>
|-
+
'''• Tiempo promedio de entrada a la Ext:''' Tiempo entrada Ext/
|Template Vivait-Suite GW||Espacio libre en /var/spool/asterisk/monitor menor del 15%||Espacio libre en /var/spool/asterisk/monitor menor del 15%||Desastre||Revisar log (/var/log/record/recordNodo.log).  
+
Llamadas entrada Ext.<br/>
Actuar en consecuencia.
+
'''• Tiempo promedio de salida a la Ext:''' Tiempo salida Ext/ Llamadas
|-
+
salida Ext.<br/>
|Template Vivait-Suite GW||Espacio libre en /var/spool/asterisk/monitor menor del 40%||Espacio libre en /var/spool/asterisk/monitor menor del 40%||Desastre||Revisar log (/var/log/record/recordNodo.log).  
+
'''• Tiempo promedio retención:''' Tiempo retención/Llamadas retenidas.<br/>
Actuar en consecuencia.
+
'''• % Ocupación con ACW:''' ((Tiempo ACD+ Tiempo retención+ Tiempo
|-
+
ACW)/Tiempo con personal)* 100.<br/>
|Template Vivait-Suite GW||Porcentaje de nodos libres en /var/spool/asterisk/monitor menor al 25%||Porcentaje de nodos libres en /var/spool/asterisk/monitor menor al 25%||N/A||Revisar log (/var/log/record/recordNodo.log).  
+
'''• % Ocupación sin ACW:''' ((Tiempo ACD+ Tiempo retención)/Tiempo
Actuar en consecuencia.
+
con personal)* 100.<br/>
|-
+
'''• % disp.:''' (Tiempo disponible/Tiempo conectado)* 100.
|Template Vivait-Suite GW||Sin datos de grabaciones movidas||Sin datos de grabaciones movidas||Alta||Revisar log (/var/log/record/recordNodo.log).
+
 
Actuar en consecuencia
+
===== Agente. Grupo ACD diario =====
|-
+
 
|Template Vivait-Suite GW||Sin espacio en dispositivo||Sin espacio en dispositivo||N/A||Revisar log (/var/log/record/recordNodo.log).
+
 
Liberar espacio moviendo grabaciones
+
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
|-
+
el agente de un grupo ACD.<br/>
|Template Vivait-Suite Record||recordCentral Gateways en cuarentena|| ||Baja||Revisar log (/var/log/record/recordCentral.log).
+
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
Revisar GW afectado (conexión SSH, procesos corriendo, etc.).
+
o realizadas por el agente excluido el tiempo de retención de un grupo
|-
+
ACD.<br/>
|Template Vivait-Suite Record||recordCentral NAS llamadas desconectado|| ||Media||Revisar estado NAS (normalmente NFS montada en /var/lib/recordProcesad/segmRecord)
+
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
|-
+
tras finalizar las llamadas contestadas por el agente de un grupo ACD.<br/>
|Template Vivait-Suite Record||recordCentral NAS segmentos desconectado|| ||Media||Revisar estado NAS (normalmente NFS montada en /var/lib/recordProcesad/segmRecord)
+
'''• Ayuda:''' Número de llamadas contestadas por el agente que necesitaron
|-
+
de consulta de un grupo ACD.<br/>
|Template Vivait-Suite Record||recordCentral retrasado en exceso|| ||Media||Comprobar con “nc localhost 1114” desde el propio host de cuanto es el retraso.  
+
'''• Llamadas retenidas:''' Número de retenciones que el agente realizó
Monitorizar que se reduce con el paso del tiempo.
+
sobre las llamadas de ese grupo ACD.<br/>
|-
+
'''• Tiempo retención:''' Tiempo que las llamadas estuvieron retenidas por
|}
+
el agente en ese grupo ACD.<br/>
 +
'''• Trans. salida:''' Llamadas que finalizan con una transferencia.
  
 +
===== Grupo ACD. Reporte diario con AHT =====
  
* El template OS Linux tiene asociado el Template App Zabbix Agent.
+
'''• Llamadas ACD:''' Número de llamadas ACD contestadas o realizadas por
Una '''base de datos unificada''' es una base de datos de tiempo real junto a una base de datos de replica
+
el agente de un grupo ACD.<br/>
 +
'''• Tiempo promedio ACD:''' Tiempo ACD/Llamadas ACD.<br/>
 +
'''• Tiempo promedio ACW:''' Tiempo ACW/Llamadas ACD.<br/>
 +
'''• Tiempo ACD:''' Tiempo de conversación ACD de las llamadas contestadas
 +
o realizadas por el agente excluido el tiempo de retención de un grupo
 +
ACD.<br/>
 +
'''• Tiempo ACW:''' Tiempo dedicado por el agente a tareas administrativas
 +
tras finalizar las llamadas contestadas por el agente de un grupo ACD.
 +
'''• Tiempo de llamado:''' Tiempo de ring en llamadas ACD de un grupo
 +
ACD.<br/>
 +
'''• Tiempo AUX:''' Tiempo que el agente estuvo en pausa.<br/>
 +
'''• Tiempo disponible:''' Tiempo que el agente estuvo conectado y no está
 +
incluido en ninguno de los anteriores.<br/>
 +
'''• Tiempo con personal:''' Tiempo que ha estado conectado el agente.<br/>
 +
'''• Ayuda:''' Número de llamadas ACD contestadas por el agente en las que
 +
necesito hacer uso de la consulta.<br/>
 +
'''• Llamadas retenidas:''' Número de retenciones que el agente realizó
 +
sobre las llamadas ACD contestadas.<br/>
 +
'''• Tiempo retención:''' Tiempo que las llamadas contestadas ACD
 +
estuvieron retenidas por el agente.<br/>
 +
'''• Trans. salida:''' Número de llamadas ACD que fueron transferidas por el
 +
agente.<br/>
 +
'''• AHT:''' (Tiempo ACD+ Tiempo ACW+ Tiempo retención)/Llamadas
 +
ACD.(Average Handle Time)<br/>
  
====== Importar templates======
+
===== Grupo ACD. QOS  =====
  
Las plantillas propias de '''md'''tel se encuentran en la ruta "'''/usr/src/nimitz/archivos'''" y empiezan con el nombre de "TemplateXXX.xml".
+
'''• Vel. prom. de resp.:''' Tiempo total de espera de llamadas antes de ser
 
+
atendidas/Llamadas ACD.<br/>
{|
+
'''• Tiempo prom. de aban.:''' Tiempo abandonadas(tiempo que las
|-
+
llamadas abandonadas estuvieron en el grupo ACD)/Llamadas
|
+
abandonadas.<br/>
ls /usr/src/nimitz/archivos | grep Template
+
'''• Llamadas ofrecidas:''' Número de llamadas entrantes al grupo
'''Template DRBD.xml'''
+
ACD(Llamadas ACD+ Abandonadas+ Desbordadas).<br/>
'''Template motorSal.xml'''
+
'''• Llamadas ACD:''' Número de llamadas contestadas por los agentes.<br/>
'''Templates Vivait-Suite_GW.xml'''
+
'''• Llamadas abandonadas:''' Número de llamadas colgadas por el cliente
'''Templates Vivait-Suite.xml'''
+
en el grupo ACD antes de ser contestadas o desbordadas.<br/>
'''Template Vivait-Call Asterisk.xml'''
+
'''• Desconectadas por ACD:''' Número de llamadas desbordadas que al
'''Template Vivait-Call bdCentral.xml'''
+
salir del grupo ACD se cuelgan.<br/>
'''Template Vivait-Call bdNodo.xml'''
+
'''• Desbordadas por ACD:''' Número total de llamadas desbordadas(incluye
'''Template Vivait-Call cambiarPerfil_Cal.xml'''
+
las desconectadas).<br/>
 +
'''• Llamadas atendidas en < 20s:'''Número de llamadas contestadas con
 +
tiempo de respuesta menor a 20 segundos.<br/>
 +
'''• Tiempo total de espera:''' Tiempo total que las llamadas estuvieron
 +
esperando antes de ser atendidas.<br/>
 +
'''• % N.A.:''' Llamadas ACD/(Llamadas ACD+ Llamadas abandonadas).<br/>
 +
'''• % N.D.S.:''' (Llamadas atendidas en < 20s/Llamadas ofrecidas)* 100.<br/>
 +
'''• T.M.O:''' (Tiempo ACD+ Tiempo ACW+ Tiempo retención)/Llamadas
 +
ACD.(Tiempo Medio Operación)
  
|}
+
===== Informe conducción (VDN Conducción) =====
  
 +
'''•Entrantes al grupo ACD:''' Número de llamadas ofrecidas al grupo
 +
ACD(Contestadas+ Abandonadas+ Desbordadas).<br/>
 +
'''•Llamadas contestadas:''' Número de llamadas contestadas por un agente.<br/>
 +
'''•Contestadas NDS:''' Número de llamadas contestadas en nivel de servicio,
 +
tiempo de respuesta< 20 segundos.<br/>
 +
'''•Abandonadas:''' Número de llamadas abandonadas, colgadas por el cliente
 +
antes de ser contestadas por un agente o desbordadas.<br/>
 +
'''•Desconectadas:''' Número de llamadas desbordadas que fueron colgadas al
 +
salir del grupo ACD.<br/>
 +
'''•Desbordadas:''' Número total de llamadas desbordadas (incluye desconectadas)<br/>
 +
'''•Llamadas retenidas:''' Número de retenciones que el agente realizó sobre las
 +
llamadas ACD contestadas.<br/>
 +
'''•% N.A.:''' (Llamadas contestadas/(Llamadas contestadas+ Abandonadas+
 +
Desbordadas))* 100.<br/>
 +
'''•% N.D.S.:''' (Contestadas NDS/(Llamadas contestadas+ Abandonadas + Desbordadas))*100<br/>
 +
'''•% Abandonadas:''' (Abandonadas/(Llamadas contestadas+ Abandonadas+ Desbordadas))* 100.<br/>
 +
'''•Acum. RING:''' Tiempo de ring en llamadas ACD(entrantes).<br/>
 +
'''•ACDTIME:''' Tiempo de conversación ACD de las llamadas contestadas o
 +
realizadas por el agente excluido el tiempo de retención de un grupo ACD.<br/>
 +
'''•Acum. ACW:''' Tiempo dedicado por el agente a tareas administrativas tras
 +
finalizar las llamadas.<br/>
 +
'''•Acum HOLD:''' Tiempo que las llamadas contestadas ACD estuvieron retenidas
 +
por el agente.<br/>
 +
'''•Acum. OTHER:''' Tiempo total que las llamadas estuvieron esperando en el
 +
grupo ACD antes de ser atendidas.<br/>
 +
'''•Acum. AVAIL:''' Acum. STAFF- (ACDTIME+ Acum. ACW+ Acum. RING+ Acum.
 +
HOLD+ Acum. AUX).<br/>
 +
'''•Acum. Staff:''' Suma del Tiempo conectado de todos los agentes al grupo
 +
ACD(Este tiempo se repercute en todos los grupos ACD a los que esta
 +
conectado el agente).<br/>
 +
'''•Acum. AUX:''' Suma del Tiempo en pausa de todos los agentes que estén
 +
conectados al grupo ACD(Este tiempo se repercute en todos los grupos ACD a
 +
los que esta conectado el agente).<br/>
 +
'''•Prom. ACD:''' ACDTIME/Llamadas contestadas.<br/>
 +
'''•Prom. ACW:''' Acum. ACW/Llamadas contestadas.<br/>
 +
'''•Prom. HOLD:''' Acum. HOLD/Llamadas retenidas.<br/>
 +
'''•AHT:''' (ACDTIME+ Acum. ACW+ Acum. HOLD)/Llamadas contestadas.<br/>
 +
'''•Vel. prom. de resp.:''' Tiempo total de espera de llamadas antes de ser
 +
atendidas/Llamadas ACD.<br/>
 +
'''•Tiempo máx. de espera:''' Tiempo de la llamada que estuvo mas tiempo en el
 +
grupo ACD hasta que fue atendida.<br/>
 +
'''•Agentes en PH:''' (Acum. Staff- Acum. AUX)/1800(Agentes conectados que no
 +
están en pausa en el intervalo).<br/>
 +
'''•Agentes Staff:''' Acum. Staff/1800(Agentes conectados en el intervalo)<br/>
 +
'''•Desglose de tiempos AUX:''' Tiempo que el agente estuvo en cada uno de los
 +
motivos de pausa.
  
La importación se realizara una vez a través de la web, no hace falta desde el servidor Zabbix, puede ser en cualquier  computadora con acceso a la interfaz web de Zabbix.
+
===== Informe de producción =====
 
 
[[File:ImportarTemplates.png|750px|center]]
 
 
 
Hay opciones varias opciones a elegir para importación de templates, pero podemos dejar por defecto las señaladas y pulsar el botón "import".
 
 
 
===Configuración para un primer funcionamiento de Zabbix===
 
Se describe una básica configuracion de Zabbix para cualquier equipo que utilice Windows o linux. Pues  mediante la definición de hosts, items, triggers y acciones, Zabbix permite efectuar un monitoreo efectivo de plataformas IT heterogéneas.
 
 
 
====Configuración de los equipost (host) para la monitorización====
 
{|
 
|-
 
|
 
'''Nota''': Tenga en cuenta que debe de estar previamente configurado el agente Zabbix del
 
dispositivo a ser monitorizado apuntando a la IP del "Servidor Zabbix".
 
|}
 
Existen dos tipos de host:
 
* '''Host físico''': donde la dirección de red que registramos en Zabbix, corresponde al dispositivo que deseamos monitorizar.
 
* '''Host virtual''': es una dirección IP virtual, que puede relacionarse con un servidor Web, clusters, etc.
 
 
 
 
 
[[File:CreacionHost.png|750px|center]]
 
 
 
Las opciones basicas para configurar un host son las siguientes:
 
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
 
! align=center ;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Campos'''''
 
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
 
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Valores posibles'''''
 
|-
 
| font-weight: bold;" | '''Host Name'''
 
|  | Definir un nombre para el host.
 
||Se puede utilizar números, letras, espacios y guiones bajos están permitidos.
 
|-
 
| font-weight: bold;" | '''Visible Name'''
 
|  | Identificar con un nombre, la maquina a la que se refiere el host.
 
||Si no tiene valor, se mostrara como nombre "Host Name".
 
|-
 
| font-weight: bold;" | '''Groups'''
 
|  | Seleccionar al grupo de host que pertence.Seleccione uno o varios grupos de la caja derecha.
 
|| Los valores que puede seleccionar por defecto:
 
Discoverd hosts.
 
  
Switches.
+
'''• LL. ACD:'''Número de llamadas contestadas por ese agente para ese
 
+
grupo ACD.<br />
Templates.
+
'''• LL. HOLD:''' Número de retenciones efectuadas para las llamadas
 
+
contestadas en ese grupo ACD.<br />
Templates MDtel.
+
'''• LL. Redir.:''' Número de llamadas no contestadas por un agente que
 
+
fueron redirigidas de nuevo a la cola.<br />
Zabbix servers.
+
'''• LL. No colgadas cliente:''' Número de llamadas que terminaron sin el
 
+
colgado del cliente.<br />
Linux Servers.
+
'''• LL. Aband.:''' Número de llamadas abandonadas en ese grupo ACD, este
 
+
valor es independiente del agente por tanto se repite el valor para todos
Hypervisors.
+
los agentes en un mismo grupo ACD.<br />
 +
'''• LL. Transfer.:''' Número de llamadas ACD que fueron transferidas por el
 +
agente.<br />
 +
'''• LL. Conf:''' Número de llamadas ACD en las que el agente estableció
 +
conferencia.<br />
 +
'''• S. Extensión:''' Número de llamadas salientes de extensión, este valor es
 +
independiente del grupo ACD se repite el valor para todos los grupos
 +
ACD en los que está conectado el agente.<br />
 +
'''• Acum. Staff:''' Tiempo que el agente estuvo conectado al grupo ACD.<br />
 +
'''• Acum. RING:''' Tiempo de ring en las llamadas ACD(entrantes) que
 +
fueron contestadas por el agente.<br />
 +
'''• Acum. ACD:''' Tiempo de conversación de las llamadas ACD(entrantes)
 +
que fueron contestadas por el agente.<br />
 +
'''• Acum. ACW:''' Tiempo dedicado por el agente a tareas administrativas
 +
tras finalizar las llamadas que fueron contestadas por él.<br />
 +
'''• Acum HOLD:''' Tiempo que las llamadas ACD(entrantes) para ese grupo
 +
ACD que fueron contestadas por el agente estuvieron retenidas.<br />
 +
'''• Acum. AVAIL:''' Acum. STAFF- (Acum. ACD+ Acum. ACW+ Acum. RING+
 +
Acum. HOLD+ Acum. AUX)..<br />
 +
'''• Acum. AUX:''' Tiempo que el agente estuvo en pausa este valor es
 +
independiente del grupo ACD se repite el valor para todos los grupos
 +
ACD en los que está conectado el agente..<br />
 +
'''• Desgloses de tiempos AUX, tiempo AUX por cada uno de los
 +
motivos.''' este valor es independiente del grupo ACD se repite el valor
 +
para todos los grupos ACD en los que está conectado el agente.
 +
-->
  
Virtual machines.
+
===== Consideraciones adicionales =====
  
O crear uno nuevo en '''New group'''.
+
Los tiempos se insertan en el intervalo en el que se deja ese "estado", esto provoca que en un intervalo pueda ser mayor el tiempo ACD que el tiempo conectado.
  
|-
+
''* Ejemplo:''
| font-weight: bold;" | '''Agent interfaces'''
 
|  |Se recomienda usar una dirección IP, en vez de un nombre de la maquina para resolver por un servidor de DNS que puede fallar.
 
|  | 10050 por defecto
 
|}
 
  
Cuando termine, haga clic en nel boton "Save". Su nuevo "Host" debe ser visible en la lista de "Host registrados".Despues el zabbix, intentara configurarse el zabbix para conectarse a la IP.... cada x tiempo hace un barrido.  
+
  -Llamada: Duración 15 minutos Hora fin de la llamada 13:01
 +
-Llamada: Duración 20 minutos Hora fin de la llamada 13:24
 +
Suma de las duraciones de las llamadas para el intervalo ''35 minutos'' tiempo
 +
conectado del agente en el intervalo ''30 minutos.''
 +
Cuando los periodos consultados sean mas amplios (diario, mensual) los
 +
desfases tenderán a desaparecer.
  
  
===== Comprobación de disponibilidad del host=====
 
Para saber si todo esta bien debemos ver la Z de disponibilidad. 
 
  
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
  
[[File:EstadosZHost.png|750px|center]]
 
  
 +
=== TBC (Translation by Chat) ===
  
Indicacion de los colores del icono Z:
 
  
* Si el icono Z en la columna de disponibilidad es de color rojo, indica que hay un error en la comunicación - mueva el cursor del ratón sobre él para ver el mensaje de error.  
+
La funcionalidad permite que dos interlocutores (a los que llamaremos “extranjero” y “agente”) puedan interactuar en una llamada telefónica independientemente del idioma en el que se expresen.
  
* Si el icono es gris, significa que esta en proceso de comunicación con el "Agente Zabbix". Compruebe que el servidor Zabbix está en marcha, y pruebe a actualizar la página más tarde.  El tiempo estimado para revisar si existe problemas es de 5 minutos.
+
==== Requerimientos de usuario ====
  
* Si el icono es verde, esta funcionando correctamente.
+
Desde el punto de vista de usuario los requerimientos serán:
  
 +
• Extranjero: Cualquier tipo de terminal telefónico (de VIVAit Call o externo) alcanzando un usuario de VIVAit Call;
  
====Indicar que plantilla (template) tendra el host [opcional]====
+
• Agente: Usuario de VIVAit Call, con terminal telefónico en VIVAit Call y portal de usuario; el entorno más unificado se consigue si el terminal telefónico es Web Call
Tras [[#Importar templates |importar templates]] nos dirigimos al host ya configurado, y en su pestaña de templates pulsamos "add" y añadimos la plantilla/s adecuadas.
 
  
====Asignar items al host ====
 
{|
 
|-
 
|
 
'''Nota''':Un host puede tener un ITEM sin necesitad de tener template.
 
|}
 
  
Todos lo ITEMS se agrupan por HOST, esto significa que cada HOST tiene sus propios "Módulos que recogen datos del Host".  Para agregar un nuevo módulo vamos a "Configuration → Hosts" y localizamos el "Host" al cual queremos agregarle un nuevo "Item".
 
  
[[File:CrearItemEjemplo.png|750px|center]]
+
==== Funcionamiento a nivel de usuario ====
  
Parametros o campos a rellenar para una configuración básica :
 
  
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
+
1. Llamadas entrantes a grupos o servicios con traducción activada por defecto: En estos casos el agente no tendrá que hacer nada y la llamada dispondrá de servicio de traducción; es típico en grupos ACD
! align=center ;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Campos'''''
 
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
 
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Valores posibles'''''
 
|-
 
| font-weight: bold;" | '''Name'''
 
|  | Definir un nombre para el item. Este nombre va a ser nuestro identificador para todas la gestiones en donde lo involucremos como el caso de Triggers.
 
||
 
|-
 
| font-weight: bold;" | '''Type'''
 
|| Indicar de que entidad queremos recibir informacion.
 
||Puede ser al "Agente Zabbix" o a el Hardware como impresoras, switch o routers. 
 
|-
 
| font-weight: bold;" | '''Key'''
 
|  | los "Items" utilizan "Key" que son parámetros de Zabbix.  Los "Key" nos permiten indicar específicamente que tipo de información vamos a solicitara a la entidad. Se puede considerar también como el nombre de alguna aplicación.
 
||
 
|-
 
| font-weight: bold;" | '''host interface'''
 
|  |Es la direccion de red del servidor zabbix (puede ser uno o mas)
 
|  |
 
||
 
|-
 
| font-weight: bold;" | '''Units'''
 
|  |Es la dirección de red del servidor zabbix (puede ser uno o mas)
 
|  |
 
|-
 
| font-weight: bold;" | '''Type of information'''
 
|  |Tipo de unidades con el que mostrar Zabbix el valor segundos, minutos, euros,....
 
||
 
|}
 
  
Cuando termine, haga clic en Guardar.  El nuevo elemento debe aparecer en la ITEMLIST.
 
Para mas informacion [[http://entation/1.8/manual/config/items#zabbix_agent. ver documentación Zabbix]]
 
  
  
===== Ver la información recolectada por el item =====
+
2. Llamadas salientes realizadas por el agente a un extranjero: En tal caso el agente realizará la llamada anteponiendo la facilidad *14# (ejemplo *14#3140) o la configurada a tal efecto en cada instalación
{|
 
|-
 
|
 
<small>'''Nota:''' Normalmente para ver la información lo encontraremos en "Monitoring → Latest data",luego
 
clic en el signo "+" en "other" siempre que no pertenezca a una aplicación.
 
En caso contrario, estará bajo el nombre de la aplicación.</small>
 
|}
 
  
Después de definir el "Item" vamos a revisar la información que esta recolectando.  .  La información comenzará a ser recolectada según el tiempo que le indicamos en el "Item".
 
  
[[File:VerInfoITEM.png|750px|center]]
 
  
La espera para recibir la información varía dependiendo del tiempo de recolección del item, la mayoría suele ser aproximadamente al minuto de generar el "Item". Zabbix le ofrece la opción de visualizar la información en forma gráfica (sencilla).  En el "Item" en lista haga clic en la columna "History - Graph".
+
3. Llamadas establecidas para las que se desea activar TBC:
  
[[File:VIsualGraficaValorItem.png|center|750px]]
+
a. En el caso de Web Call el agente dispondrá de un botón en el control de llamada que le servirá para activar TBC; la activación pasa por una autotransferencia directa de la llamada
Si en un caso usted no observa información le recomendamos:
 
 
 
* Ingrese al "Item" y revise que la información del "Key" este igual al ejemplo "system.cpu.load"
 
* Verifique que el agente este funcionando en el "Servidor a ser monitoreado" y que "El Servidor recolector Zabbix" este funcionando.
 
* El icono "Z" en el host debe estar en color verde.
 
* Asegure que esta monitoreando el servidor que le agregó este "Item"
 
  
====Configurar los Triggers para los host====
+
b. En el caso de otros terminales el usuario deberá realizar una transferencia directa a si mismo (se usa para ello llamada a *14*)
A partir de la información que captura los agentes , el servidor de Zabbix comienza a efectuar la recolección de estos items en la base de datos. Con esto se tiene un registro histórico de tales mediciones, que pueden ser tan simples como un simple ping hasta datos de uso de disco, memoria, cpu, etc.
 
A partir de los datos que se reciben de los agentes lo que sigue es definir y configurar Triggers, que son evaluaciones que hace Zabix de estos datos para determinar la existencia de un Problema en un dispositivo.
 
{|
 
|-
 
|
 
  Nota: Un trigger necesita una accion, que indica que hacer cuando se activa el trigger.
 
|}
 
  
  
Un trigger(disparador) es un tipo de reacción ante unas medidas, como un disparador en el que si pasa algo se activa. Los Trigger en Zabbix son módulos que creamos a uno o múltiples "Items" para evaluar o comparar los valores recolectados por los "Items" con condiciones que nosotros definamos.  Las condiciones son de tipo aritmético y lógico.
+
El funcionamiento general una vez establecida una llamada con servicio TBC será:
  
Para configurar un "Trigger o Disparador" seleccionamos "Configuration → Hosts" localizamos el "Host" de ejemplo que creamos y luego hacemos clic en "Trigger", después haga clic en "Create Trigger".
 
  
Parametros o campos a rellenar para una configuración básica :
+
• El extranjero habla en su idioma y escucha audios en su idioma; como se ha indicado anteriormente, en el lado del extranjero no es necesario ninguna herramienta adicional al terminal telefónico, que podrá ser interno o externo a VIVAit Call
  
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
 
! align=center ;border-top:0.05pt solid #000000;border-bottom:0.05pt solid #000000;border-left:0.05pt solid #000000;border-right:none;padding:0cm;color:#ffffff;" | '''''Campos'''''
 
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Explicación'''''
 
! align=center ;border:0.05pt solid #000000;padding:0cm;color:#ffffff;" | '''''Valores posibles'''''
 
|-
 
| font-weight: bold;" | '''Name'''
 
|  | Definir un nombre para el trigger.  Este nombre va a ser nuestro identificador para todas la gestiones en donde lo involucremos como el caso de los eventos.
 
||
 
|-
 
| font-weight: bold;" | '''Expression'''
 
||  Hay que indicar para que medida se crea (item) y sus funciones con los parametros adecuados. '''''Recomendación usar expression constructor que pedirá siempre al crearlo, para que item es y sus funciones...'''''
 
||Ejemplo: {New host:system.cpu.load.avg(180)}>2
 
|-
 
| font-weight: bold;" | '''Key'''
 
|  | los "Items" utilizan "Key" que son parámetros de Zabbix.  Los "Key" nos permiten indicar específicamente que tipo de información vamos a solicitara a la entidad. Se puede considerar tambien como el nombre de alguna aplicacion.
 
||
 
|-
 
| font-weight: bold;" | '''Descripción'''
 
|  | Una descripción breve sobre el trigger.
 
||
 
|-
 
| font-weight: bold;" | '''Severity'''
 
|  | everidad distinguida por colores,
 
|| No classified
 
Information
 
Warning
 
Average
 
High
 
Disaster
 
|}
 
  
 +
'''El agente'''
  
 +
'''Para la recepción:'''
  
===== Comprobar el estado del trigger =====
+
• Escucha el audio del extranjero (en el terminal)
Podemos ver el estado del "Trigger" en "Monitoring → Triggers".El  color en caso de que se active depende de la severidad definida. Por ejemplo,  si el "Trigger" esta en color verde indica que el resultado de la métrica se mantiene por debajo de la condición que indicamos.  Por el contrario si el resultado esta "sobre lo indicado" su color sera rojo.
 
  
[[File:EstadoTrigger.png|center|750px]]
+
• Lee el texto transcrito en el idioma del extranjero
  
====Asociar un Action al trigger====
+
• Lee el texto traducido en el idioma del agente
  
Una action(acción) sirve para configurar un mensaje de alerta o una accion para Zabbix, ante un problema. Hay varias formas de gestionar un problema a través de una acción:
 
  
# A través de mensajes simples, alertando al instante.
+
'''Para la emisión:'''
# Escalar los mensajes hacia el jefe y/o otros grupos.
 
# Ejecución de commandos remotos.
 
# Notificaciones repetidas hasta que se resuelve el problema.
 
# Notificaciones y comandos retardados.
 
# Escenario complejo, la combinación de todo lo anterior.
 
  
Para crear una configuración en "Configuration-Actions". La explicación esta en la [[ https://www.zabbix.com/documentation/2.0/manual/config/notifications/action documentación de Zabbix]].
+
• Escribe en su idioma
-->
 
  
== Integraciones con servicios externos ==
+
• Lee el texto traducido al idioma del extranjero
  
 +
• Tiene opción de reproducir el audio que ha escuchado el extranjero
  
=== Presencia con Openfire ===
 
'''''VIVA'''''it 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
+
==== Funcionamiento a nivel de VIVAit Call ====
  
Con esto conseguiremos comunicar asterisk y OPenfire de manera que:
+
A nivel de VIVAit Call, los elementos principales involucrados en el servicio son:
*Los estados telefónicos de una extensión '''''VIVA'''''it  se reflejen en Openfire
 
*Poder marcar desde los clientes de IM instalados en los puestos
 
*Ver en el cliente llamadas entrantes al teléfono
 
  
-----
+
'''• mdtap: Con sus componentes chan_mdtap e intz_tap se encargará de:'''
  
'''<big>Enlaces de interes:</big>'''
+
''' chan_mdtap:'''
  
[http://www.igniterealtime.org/projects/openfire/ Página proyecto openfire]
+
• Captura el audio
  
[https://community.igniterealtime.org/thread/56076 Página proyecto "asterisk IM"]
+
• Reenvía a intz_tap
 
+
 
 
+
• El audio pasa al otro extremo
=== Reuniones virtuales con Openmeetings ===
+
 
'''OpenMeetings''' es un sistema de vídeo web-conferencia en tiempo real. Usando recursos como audio (micrófono), vídeo (cámara web), posibilidad de subir y convertir presentaciones (en PDF , PPT o ODP que se convierten a Flash), compartición de la pantalla de tu ordenador, o pizarra digital compartida, panel de administración, posibilidad de grabar las sesiones… y completo soporte multiplataforma, es decir, que aparte de poder grabar las sesiones, se puede compartir un escritorio también desde una máquina Linux.
+
 
 
+
''' intz_tap:'''
Para instalar '''OpenMettings''' debe seguir el [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Manuales_de_instalaci%C3%B3n#Instalaci.C3.B3n_de_Openmeetings | manual de Instalación de Openmeetings]]
+
 
 
+
'''Para speech to text'''
 
+
 
 
+
• Invoca al servicio de conversión de audio a texto configurado y lo envía
=== Integración de portal usuario de VIVAit Call Web Microsoft Teams ===
+
 
 
+
• Recibe el texto y otros datos y los inserta en BDTR
 
+
 
La integración de VIVAit Call Web con MS Teams se realiza en tres pasos; dos
+
 
de ellos han de ser realizados íntegramente por el cliente puesto que requieren
+
'''Para text to speech
realizar modificaciones en su entorno de gestión de Microsoft Azure y Teams.
+
'''
 
+
• Periodicamente (polling) comprueba si hay mensajes de tipo de contenido audio
 
+
 
[[Archivo:teams-esquema.png|400px|center]]
+
• Recupera la URL
 
+
 
 
+
• Invoca al servicio de conversión de texto a audio configurado y lo envía
 
+
 
A continuación se muestra que debe hacer el administrador de Teams y de Mdtel para la integración con Ms Teams , los pasos consisten en:
+
• Recibe el audio y lo inserta en la conversación en sustitución del audio del agente
{| class="wikitable"
+
 
|-
+
 
! Responsable !! Pasos
+
'''Portal de usuario/Web Call'''
|-
+
 
|Administrador de Teams y Mdtel || Generar el archivo .zip con todos los elementos requeridos para una integrar una nueva aplicación en MS Teams. Este archivo .zip es diferente para cada cliente de VIVAit Call Web y tiene que ser generado para cada caso
+
•      Cuando se abre pestaña de TBC sincroniza mensajes https://172.25.128.253/Vivait-FonBO/api/recuperarId
|-
+
 
 
+
  •    Periodicamente (polling) pide nuevos mensajes de TBC del extranjero a FonBO https://172.25.128.253/Vivait-FonBO/api/listaMensajesUsuario?lastId=85&idioma=es
|}
+
 
 
+
•    Envía mensajes de texto a FonBO https://wwv.mdtel.es/Vivait-FonBO/api/insertaMensaje?hayTraduccion=true&idiomaDestino=fr
 
+
 
 
+
 
'''PASOS:'''
+
'''FonBO:'''
 
+
 
'''Generar archivo ZIP con todos los elementos'''
+
• Responde a polling de Portal de usuario/Web Call
 
+
 
El paso ha de ser realizado por un administrador de Teams y mdtel
+
• Envía mensajes a traducir al servicio de traducción texto a texto, solo si el idioma del agente (configurado) y el idioma del extranjero (típicamente detectado) son diferentes; lo realiza para las traducciones en ambos sentidos
 
+
 
Debemos disponer de los valores :
+
• Recibe mensajes traducidos y los inserta en BDTR
 
+
 
* ''' AAD_APLICACION_ID'''
+
• Envía mensajes de texto al servicio de Text to Speech
*  
+
 
* ''' AAD_CLAVE_EXPIRA'''
+
• Recibe el audio, lo almacena e inserta en BDTR (una URL)
*  
+
 
* ''' AAD_CLAVE_VALOR'''
+
 
*  
+
 
* ''' AAD_CLAVE_ID'''
+
==== Puesta en marcha ====
 
+
 
 
+
 
Estos datos serán proporcionados a mdtel, que generará un archivo ZIP
+
Para disponer de la funcionalidad será necesario disponer de:
 
+
 
'''VIVAit-call-web-empresa-vivait-manifest.zip'''
+
 
 
+
• Base de datos actualizada con tabla DAT_MENSAJES_IA y COM_USUARIOS
 
+
 
Para crear este archivo .zip, se parte de un zip base en el que modifican los valores que
+
• Fonbo versión xxxx
se indican de manifest.json :
+
 
 
+
• Web Call versión 2.0.0 (para esta funcionalidad, esta versión de Web Call requerirá otros cambios en BBDD por otras funcionalidades implementadas)
    
+
 
* ''' staticTabs.contentUrl (debe apuntar a la web específica del cliente).'''
+
• Chan_mdtap e Intz_Tap funcionando
      
+
 
* ''' validDomains (lista de dominios a los que se permite acceder: el dominio de la web del cliente).'''
+
 
      
+
 
* ''' webApplicationInfo.id <AAD_APLICACION_ID>'''
+
La configuración cargada por defecto en el sistema permite la activación con mucha facilidad de las funciones de:
      
+
 
* ''' webApplicationInfo.resource <AAD_URL_APLICACION_ID>'''
+
 
 
+
• Casuística 1: Llamadas salientes realizadas por el agente a un extranjero; el agente marcará *14#num_Destino
 
+
 
 
+
 
También con estos valores debe modificarse la configuración de serCen:
+
::[[File:tbc1.PNG|250px|center]]
 
+
 
   
+
 
* ''' ws_implementacion.aad_app_client_id = <AAD_APLICACION_ID>'''
+
Es la facilidad con E_CODIGO_FACILIDAD = 800 (transcripción de número de teléfono).
    
+
 
* ''' ws_implementacion.aad_app_client_secret_cifrado = <AAD_CLAVE_VALOR> (CIFRADO)'''
+
 
    
+
::[[File:tbc2.PNG|800px|center]]
* ''' ws_implementacion.aad_app_secret_expire = <AAD_CLAVE_EXPIRA>'''
+
 
   
+
 
 
+
La numeración está definida por prerutas, una por categoría
 
+
 
1- A partir de aquí, interviene un administrador de MS Teams.
+
 
    
+
::[[File:tbc3.PNG|800px|center]]
    
+
 
'''Acceder a:'''  https://admin.teams.microsoft.com
+
 
   
+
 
 
+
 
 
+
• Casuística 2: Llamadas establecidas para las que se desea activar TBC; el agente pulsará el botón de “traducción simultánea”
[[Archivo:teams-wiki.png|600px|center]]
+
 
 +
::[[File:tbc4.PNG|350px|center]]
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
=== Puesto de trabajo ===
 +
<br><br>
 +
 
 +
El puesto de trabajo del agente en la plataforma '''''VIVA'''''it  (para el producto '''''VIVA'''''it Suite) estará compuesto por:
 +
* PC (típicamente windows) en el que reside la aplicación '''''VIVA'''''it Desk
 +
* Terminal telefónico con extensión física asociada.
 +
 
 +
Para más información [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Portal_de_administraci%C3%B3n_VIVAit#Puestos | ver sección Portal de administración-VIVAit Suite ACD+ - Puestos]].
 +
 
 +
==== Relación PC/teléfono en puesto de trabajo ====
 +
<br><br>
 +
 
 +
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.
 +
 
 +
 
 +
 
 +
===== Procedimiento para un cambio de puesto de trabajo =====
 +
<br><br>
 +
 
 +
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:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Cambio !! Procedimiento !! Punto de acción
 +
|-
 +
|rowspan="2"| 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
 +
|-
 +
| rowspan="2"| 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
 +
|}
 +
<!--
 +
[[File:relacion_puesto_agente.png|center|500px]]
 +
-->
 +
 
 +
==== Estructura de aplicaciones en puesto de trabajo ====
 +
<br><br>
 +
 
 +
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
 +
{| class="wikitable"
 +
|-
 +
! Fichero !! Descrición
 +
|-
 +
| Vivait-desk.exe || Contiene la aplicación '''''VIVA'''''it 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 '''''VIVA'''''it Desk
 +
|-
 +
|}
 +
 
 +
==== Secciones de utilidad en nimitz.ini ====
 +
<br><br>
 +
 
 +
===== Configuración del puesto de agente =====
 +
<br><br>
 +
 
 +
El fichero nimitz.ini contiene la configuración del puesto de agente; sus principales parámetros son:
 +
 
 +
{| class="wikitable" border="0" style="background:#ffffff" align="top"
 +
|-
 +
| |''' Fichero'''
 +
|| '''Descripción'''
 +
|-
 +
|Sección [bd1]
 +
||host="ip_BBDD_tiempo_real"
 +
puerto="Nº puerto"
 +
basedatos="nimitz"
 +
usuario="nimitz"
 +
clave="UIk5jMY9PVX6ogg="
 +
 
 +
Contiene información para la conexión a BBDD de tiempo real, en la que '''''VIVA'''''it Desk fundamentalmente inserta información
 +
|-
 +
|Sección [bd2]
 +
||host=" ip_BBDD_replica "
 +
puerto="Nº puerto"
 +
basedatos="nimitz"
 +
usuario="nimitz"
 +
clave="UIk5jMY9PVX6ogg="
 +
 
 +
Contiene información para la conexión a BBDD de réplica, en la que '''''VIVA'''''it Desk solo leerá información
 +
|-
 +
|Sección [telefono]
 +
||pruebas=1 (Valores válidos 0 ó 1)
 +
Activación de funcionalidad "servicio técnico" en '''''VIVA'''''it Desk.
 +
Cuando usamos el parámetro pruebas=1 permitimos abrir más de una sesión de '''''VIVA'''''it Desk; esto puede provocar que el programa no responda y estemos obligados a resetear la aplicación
 +
 
 +
puesto="Nombre puesto"
 +
|-
 +
|Sección [trazas]
 +
|| '''nivel=3''' (indica el nivel de trazas suministrado por el sistema)
 +
 
 +
'''archivo=1''' (indica que se generará un fichero con las trazas del sistema)
 +
 
 +
'''consola=0''' (Si el nivel de trazas es 3 no debemos utilizar el valor consola=1, impedirá que arranque el desk)
 +
 
 +
'''sobreescribir=1''' Se genera un fichero de trazas para la sesión activa. Cuando el desk se cierra se genera un fichero nuevo perdiendo las trazas de la sesión anterior.
 +
 
 +
'''sobreescribir=0''' se genera un fichero de trazas cuando el agente abre el desk y cuando cierra la sesión y abre una nueva se van acumulando las trazas en el mismo fichero.
 +
 
 +
Activación de generación de ficheros de trazas "viva-desk.log" en carpeta de aplicaciones
 +
|}
 +
 
 +
==== Parámetros en invocación a '''''VIVA'''''it Desk ====
 +
<br><br>
 +
 
 +
La aplicación '''''VIVA'''''it 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
 +
 
 +
==== 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/"
 +
 
 +
==== Servicio técnico en '''''VIVA'''''it Desk ====
 +
<br><br>
 +
 
 +
La activación de la funcionalidad de servicio técnico en '''''VIVA'''''it 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 '''''VIVA'''''it Desk. Pulsando el botón derecho del ratón sobre la barra '''''VIVA'''''it Desk accederemos a las capacidades de soporte técnico
 +
<br><br>
 +
[https://vivait-wiki.mdnova.local/wiki/vivait/index.php/Manual_de_operación_VIVAit_5.0  Volver al índice]
 +
<br><br>
 +
 
 +
=== Integraciones con servicios externos ===
 +
<br><br>
 +
 
 +
 
 +
==== Presencia con Openfire ====
 +
<br><br>
 +
 
 +
'''''VIVA'''''it 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 '''''VIVA'''''it  se reflejen en Openfire
 +
*Poder marcar desde los clientes de IM instalados en los puestos
 +
*Ver en el cliente llamadas entrantes al teléfono
 +
 
 +
-----
 +
 
 +
'''<big>Enlaces de interes:</big>'''
 +
 
 +
[http://www.igniterealtime.org/projects/openfire/ Página proyecto openfire]
 +
 
 +
[https://community.igniterealtime.org/thread/56076 Página proyecto "asterisk IM"]
 +
 
 +
 
 +
==== Reuniones virtuales con Openmeetings ====
 +
<br><br>
 +
 
 +
'''OpenMeetings''' es un sistema de vídeo web-conferencia en tiempo real. Usando recursos como audio (micrófono), vídeo (cámara web), posibilidad de subir y convertir presentaciones (en PDF , PPT o ODP que se convierten a Flash), compartición de la pantalla de tu ordenador, o pizarra digital compartida, panel de administración, posibilidad de grabar las sesiones… y completo soporte multiplataforma, es decir, que aparte de poder grabar las sesiones, se puede compartir un escritorio también desde una máquina Linux.
 +
 
 +
Para instalar '''OpenMettings''' debe seguir el [[http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Manuales_de_instalaci%C3%B3n#Instalaci.C3.B3n_de_Openmeetings | manual de Instalación de Openmeetings]]
 +
 
 +
 
 +
 
 +
==== Integración de portal usuario de VIVAit Call Web Microsoft Teams ====
 +
<br><br>
 +
 
 +
 
 +
 
 +
La integración de VIVAit Call Web con MS Teams se realiza en tres pasos; dos
 +
de ellos han de ser realizados íntegramente por el cliente puesto que requieren
 +
realizar modificaciones en su entorno de gestión de Microsoft Azure y Teams.
 +
 
 +
 
 +
[[Archivo:teams-esquema.png|400px|center]]
 +
 
 +
 
 +
 
 +
A continuación se muestra que debe hacer el administrador de Teams y de Mdtel para la integración con Ms Teams , los pasos consisten en:
 +
{| class="wikitable"
 +
|-
 +
! Responsable !! Pasos
 +
|-
 +
|Administrador de Teams y Mdtel || Generar el archivo .zip con todos los elementos requeridos para una integrar una nueva aplicación en MS Teams. Este archivo .zip es diferente para cada cliente de VIVAit Call Web y tiene que ser generado para cada caso
 +
|-
 +
 
 +
|}
 +
 
 +
 
 +
 
 +
'''PASOS:'''
 +
 
 +
'''Generar archivo ZIP con todos los elementos'''
 +
 
 +
El paso ha de ser realizado por un administrador de Teams y mdtel
 +
 
 +
Debemos disponer de los valores :
 +
 
 +
* ''' AAD_APLICACION_ID'''
 +
*  
 +
* ''' AAD_CLAVE_EXPIRA'''
 +
*  
 +
* ''' AAD_CLAVE_VALOR'''
 +
*  
 +
* ''' AAD_CLAVE_ID'''
 +
 
 +
 
 +
Estos datos serán proporcionados a mdtel, que generará un archivo ZIP
 +
 
 +
'''VIVAit-call-web-empresa-vivait-manifest.zip'''
 +
 
 +
 
 +
Para crear este archivo .zip, se parte de un zip base en el que modifican los valores que
 +
se indican de manifest.json :
 +
 
 +
    
 +
* ''' staticTabs.contentUrl (debe apuntar a la web específica del cliente).'''
 +
      
 +
* ''' validDomains (lista de dominios a los que se permite acceder: el dominio de la web del cliente).'''
 +
      
 +
* ''' webApplicationInfo.id <AAD_APLICACION_ID>'''
 +
      
 +
* ''' webApplicationInfo.resource <AAD_URL_APLICACION_ID>'''
 +
 
 +
 
 +
 
 +
También con estos valores debe modificarse la configuración de serCen:
 +
 
 +
   
 +
* ''' ws_implementacion.aad_app_client_id = <AAD_APLICACION_ID>'''
 +
    
 +
* ''' ws_implementacion.aad_app_client_secret_cifrado = <AAD_CLAVE_VALOR> (CIFRADO)'''
 +
    
 +
* ''' ws_implementacion.aad_app_secret_expire = <AAD_CLAVE_EXPIRA>'''
 +
   
 +
 
 +
 
 +
1- A partir de aquí, interviene un administrador de MS Teams.
 +
    
 +
    
 +
'''Acceder a:'''  https://admin.teams.microsoft.com
 +
   
 +
 
 +
 
 +
[[Archivo:teams-wiki.png|600px|center]]
  
  
Línea 10 846: Línea 12 388:
 
[[Archivo:teams-ad18.png|700px|center]]
 
[[Archivo:teams-ad18.png|700px|center]]
  
== Marcador Predictivo ==
+
=== Marcador Predictivo ===
 +
<br><br>
 +
 
  
 
La marcación, como la conocemos hasta ahora, comienza en la tabla de contactos del portal.
 
La marcación, como la conocemos hasta ahora, comienza en la tabla de contactos del portal.
Línea 10 862: Línea 12 406:
  
  
===Arquitectura===
+
==== Arquitectura ====
 +
<br><br>
  
  
Línea 10 873: Línea 12 418:
 
[[File:ArquitecturaMODULOS.jpg|600px]]
 
[[File:ArquitecturaMODULOS.jpg|600px]]
  
===¿Como funciona un marcador predictivo?===
+
==== ¿Como funciona un marcador predictivo? ====
 +
<br><br>
 +
 
 +
====== Conceptos y funcionamiento general ======
 +
<br><br>
  
====Conceptos y funcionamiento general====
 
  
 
Un marcador predictivo se ocupa del cálculo del volumen de llamadas requeridas para conseguir la mayor productividad.  Esto ayuda a que los agentes estén en conversación el mayor tiempo posible.  Este tipo de marcación es ideal para campañas que tengan más de 20 agentes simultáneos.  Mientras más agentes, el algoritmo de predicción funciona mejor.  En campañas pequeñas el riesgo de un algoritmo de predicción agresivo puede ser el de un incremento en los abandonos por parte de los clientes (los clientes contestan, pero del otro lado no hay agentes disponibles, y cuelgan).   
 
Un marcador predictivo se ocupa del cálculo del volumen de llamadas requeridas para conseguir la mayor productividad.  Esto ayuda a que los agentes estén en conversación el mayor tiempo posible.  Este tipo de marcación es ideal para campañas que tengan más de 20 agentes simultáneos.  Mientras más agentes, el algoritmo de predicción funciona mejor.  En campañas pequeñas el riesgo de un algoritmo de predicción agresivo puede ser el de un incremento en los abandonos por parte de los clientes (los clientes contestan, pero del otro lado no hay agentes disponibles, y cuelgan).   
Línea 10 895: Línea 12 443:
 
El sistema determina cuanto tráfico es capaz de generar, en función del número de agentes disponibles.
 
El sistema determina cuanto tráfico es capaz de generar, en función del número de agentes disponibles.
  
=== Modelos de marcación predictivos ===
+
==== Modelos de marcación predictivos ====
 +
<br><br>
  
 
Básicamente existen cuatro modelos de marcación:
 
Básicamente existen cuatro modelos de marcación:
Línea 10 945: Línea 12 494:
 
Lee datos de la tabla ACD_COLAS y, en función de los parámetros configurados, genera variables de salida en la tabla DAT_TR_COLAS para modular el funcionamiento de MyACDsuperV, además rellena los datos de la tabla DAT_MUESTRA_COLAS_PREDICTIVAS que “funcionará” como histórico de lo que ha ido pasando.
 
Lee datos de la tabla ACD_COLAS y, en función de los parámetros configurados, genera variables de salida en la tabla DAT_TR_COLAS para modular el funcionamiento de MyACDsuperV, además rellena los datos de la tabla DAT_MUESTRA_COLAS_PREDICTIVAS que “funcionará” como histórico de lo que ha ido pasando.
  
==='''Parámetros'''===
+
==== '''Parámetros''' ====
 +
<br><br>
 +
 
  
 
Cada modelo de predictivo utiliza un conjunto de parámetros.
 
Cada modelo de predictivo utiliza un conjunto de parámetros.
Línea 10 971: Línea 12 522:
 
'''PAR10:''' Nivel de servicio.
 
'''PAR10:''' Nivel de servicio.
  
===Variables===
+
==== Variables ====
 +
<br><br>
 +
 
  
 
Cada modelo de predictivo utiliza una variables que se encuentran en la tabla DAT_TR_COLAS:
 
Cada modelo de predictivo utiliza una variables que se encuentran en la tabla DAT_TR_COLAS:
Línea 11 007: Línea 12 560:
 
'''VAR14:''' Nº de colas predictivas compartidas.
 
'''VAR14:''' Nº de colas predictivas compartidas.
  
=== Nuevas tablas ===
+
==== Nuevas tablas ====
 +
<br><br>
 +
 
 +
 
 +
===== DAT_MUESTRAS_COLAS_PREDICTIVAS =====
 +
<br><br>
  
==== DAT_MUESTRAS_COLAS_PREDICTIVAS====
 
  
 
Constituirá el histórico del marcador predictivo.
 
Constituirá el histórico del marcador predictivo.
Línea 11 117: Línea 12 674:
  
  
=== Particularidades del modelo mezcla===
+
==== Particularidades del modelo mezcla ====
 +
<br><br>
 +
 
  
 
En el modelo mezcla asumimos que los agentes se conectan a las mismas colas.
 
En el modelo mezcla asumimos que los agentes se conectan a las mismas colas.
Línea 11 138: Línea 12 697:
 
En el arranque del modelo los datos de tiempo de servicio y de intentos 100contactos se obtienen de los parámetros PAR7 y PAR1.
 
En el arranque del modelo los datos de tiempo de servicio y de intentos 100contactos se obtienen de los parámetros PAR7 y PAR1.
  
====Escalabilidad====
+
===== Escalabilidad =====
 +
<br><br>
 +
 
  
 
El marcador predictivo necesita conectarse a una base de datos, para obtener datos, lee de una tabla y escribe en otra, pero no necesita muchos datos para poder funcionar.
 
El marcador predictivo necesita conectarse a una base de datos, para obtener datos, lee de una tabla y escribe en otra, pero no necesita muchos datos para poder funcionar.
Línea 11 144: Línea 12 705:
 
En entornos grandes se puede tener una réplica de la base de datos, con pocos datos, una para leer y otra para escribir. Además, en estos entornos, se podrían tener varios Motor_Predi.
 
En entornos grandes se puede tener una réplica de la base de datos, con pocos datos, una para leer y otra para escribir. Además, en estos entornos, se podrían tener varios Motor_Predi.
  
====Límites al sistema====
+
===== Límites al sistema =====
 +
<br><br>
 +
 
  
 
Quizá fuesen necesarios "topes" al número máximo de intentos en base a un porcentaje calculado a partir de la capacidad del sistema.
 
Quizá fuesen necesarios "topes" al número máximo de intentos en base a un porcentaje calculado a partir de la capacidad del sistema.
Línea 11 155: Línea 12 718:
  
  
== Canales digitales en VIVAit Suite ==
+
=== Canales digitales en VIVAit Suite ===
  
 
Se incluye enlace a documentación en formato .pdf a canales digitales, actualmente correo electrónico
 
Se incluye enlace a documentación en formato .pdf a canales digitales, actualmente correo electrónico

Revisión actual del 13:39 5 may 2026

Producto: VIVAit Call

VIVAit Suite

Sumario

1 Introducción a la plataforma VIVAit



En este documento se describe la plataforma VIVAit de MDTel, cuyo objetivo principal es proporcionar servicios de comunicaciones con tecnología VoIP.

La plataforma VIVAit tiene dos proyecciones en el plano comercial, cuya denominación ser utilizará recurrentemente a lo largo de este documento:

VIVAit Call, producto VIVAit para el entorno corporativo
VIVAit Suite, producto VIVAit para el entorno call center



Se documentan los procesos principales de cada elemento del sistema, así como sus componentes clave para el diagnóstico.
Por ello el presente documento se divide en cuatro grandes grupos:

Arquitectura de la plataforma VIVAit
Descripción de los elementos software
Funcionalidades específicas en VIVAit
Diagnósticos y operaciones básicas en VIVAit



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 de la plataforma VIVAit



La plataforma VIVAit de MDTel se compone de nodos de distinto tipo:

Nodo tipo operativo
Realiza funciones de encaminamiento de tráfico telefónico. Estarán dados de alta en el portal de gestión. Entre ellos están:
Nodo Corporativo, para entornos corporativos de telefonía IP y diferentes aplicaciones. Nodo de procesamiento de telefonía corporativa. Tiene la aplicación Asterisk.
Nodo Call Center, para los servicios típicos de call center. Nodo de procesamiento de call center. Tiene la aplicación Asterisk.
Nodo Gateway, auxiliar del nodo corporativo para funciones de telefonía tradicional. Tiene la aplicación Asterisk.
Nodo STG, para gestionar tráfico telefónico a/desde internet. Este nodo asume la funcionalidad WebRTC que da soporte a terminales webfon e incorpora flexisip para terminales VCB.
Nodo MCAM, para proporcionar servicios de multicanalidad.
Nodo Presencia, para proporcionar servicios de presencia.
Nodo Varios, utilizado normalmente para identificar un nodo tipo auxiliar.



Nodo tipo auxiliar
Realiza funciones auxiliares. Aunque conveniente no es necesario darlos de alta en el portal de gestión. Entre otros podemos encontrar:
Nodo BBDD, soporta la base de datos del sistema, bien sea la de tiempo real o la de histórico. En entornos especialmente grandes, suele estar implementado en máquinas dedicadas (bien un servidor o de un clúster de dos servidores).
Nodo de Gestión, contiene el portal de administración y opcionalmente otros procesos auxiliares no relacionados directamente con la conmutación telefónica de llamadas como: otros portales tracker, GH (Gran Hermano).



Esta sería la arquitectura funcional, en un proyecto determinado pueden coexistir varios de estos nodos en un solo servidor físico o virtual.
Los despliegues pueden ser múltiples pudiendo abarcar desde:

Instalación sencilla, un solo servidor que contiene nodo corporativo + nodo de gestión + nodo BBDD.
Instalación con máximo despliegue, cada nodo en un servidor, pudiendo existir varios nodos con la misma funcionalidad: varios nodos corporativos, varios nodos GW, etc.



En la versión actual los módulos software en los que se implementan los nodos que proporcionan servicios de VoIP son:

Sistema Operativo, sobre servidor en máquina física o virtualizada
Asterisk: gestiona llamadas telefónicas VoIP, integrando funciones de una central telefónica en un servidor
DBTR: gestor de la base de datos
Tomcat/Apache: servidor web para los diferentes portales: gestión, supervisor, usuario, traker, ...
Webrtc: gestionar llamadas telefónicas desde un navegador web



Tipo de nodo Función Sistema Operativo Asterisk
Corporativo / GW Telefonía corporativa Linux 6.12.63+deb13-amd64 Asterisk certified/18.9-cert4
Call Center Telefonía ACD Ubuntu 22.04.4 LTS Asterisk 1.4.24-RSP
Webrtc Nodo STG Linux 6.12.43+deb13-amd64 -



Para una información más detallada consultar Versiones de los módulos software



2.1 Arquitectura nodo Corporativo



Un nodo Corporativo / GW se puede instalar en máquinas físicas (directamente sobre el hardware disponible) o sobre máquinas virtuales.
El entorno virtualizado será el procedimiento preferido por MDTel siempre que no existan necesidades especiales que aconsejen el uso de máquinas físicas.
Estas necesidades especiales suelen ser sistemas que tengan un alto volumen de llamadas y sea preferible la instalación en máquinas físicas.



2.1.1 Arquitectura nodo Corporativo / GW sobre máquinas físicas



Este despliegue puede realizarse, según especificaciones del proyecto, sobre una solo máquina o sobre varias máquinas:

Todo en una sola máquina

Sobre la plataforma del sistema operativo se despliegan los distintos servicios necesarios. A continuación se muestran, una configuración mínima:

Arquitectura física V5.1.png



Despliegue en varias máquinas

Sobre el sistema operativo de cada máquina se despliegan los distintos servicios, distribuyéndolos según los procesos de instalación correspondiente.
El ejemplo anterior en dos máquinas físicas podría ser el siguiente:

Arquitectura física 2 V5.1.png



En este caso se ha añadido DBTHIST, una base de datos que almacena información histórica para distintos propósitos, como seguridad, postproceso o copias de respaldo.



2.1.2 Arquitectura nodo Corporativo sobre máquinas virtuales



El despliegue virtualizado puede realizarse, según especificaciones del proyecto, sobre una solo máquina física o sobre varias.
El entorno de virutalización es sobre el programa QEMU, que permite ejecutar un sistema operativo dentro de otro (host), como si fuera una “máquina dentro de otra máquina”

Todo en una sola máquina

El mínimo número de máquinas virtuales en una instalación son 2, un VIVAit-corporativo y una máquina de BD/Gestión.

Arquitectura virtualización 1 V5.1.png



En el caso de necesitar instalar tarjetas físicas para conectar líneas al sistema, se instalará Asterisk en la maquina física, pero este no será un nodo VIVAit.
se comportará como un conversor de líneas físicas a SIP y dentro de 'VIVAit se configurarán las líneas como Trunk SIP.

Despliegue en varias máquinas

El sistema estará compuesto de tantas máquinas virtuales como sean necesarias y el número de máquinas físicas necesarias para asumir la carga de la instalación. El ejemplo virtualizado anterior, en dos máquinas físicas, podría ser el siguiente:

Arquitectura virtualizacion 2 V5.1.png





2.2 Arquitectura nodo Call Center



La arquitectura de este tipo de nodo se hereda de versiones anteriores.

Arquitectura call center V5.1.png





2.2.1 Arquitectura del puesto de agente



Como complemento a la arquitectura Call Center se muestra la arquitectura asociada a los actores principales del ACD: agentes y supervisores.

Arquitectura-Puesto-Agente.jpg





2.3 Arquitectura del nodo STG



Este nodo está formado por los componentes que permiten conectar, a través de Internet, servicios de VoIP para terminales del sistema que acceden a los nodos corporativos.
Para minimizar la exposición de VIVAit a redes abiertas, como internet, este nodo concentra las funciones que requieren conectividad con dichas redes.
Con esta filosofía de diseño conexiones de VIVAit Web Call, app como VCB, hardphone en internet, etc. serán controladas por este nodo.

Arquitectura nodo STG.png





2.4 Servicios de networking



Al integrar el sistema VIVAit en la infraestructura del cliente, destinado a prestar servicios de VoIP, es fundamental considerar los servicios necesarios para su correcto funcionamiento.
Aunque los servidores pueden ser proporcionados por el sistema de MDTel, lo más habitual es que el cliente los aporte dentro de su propia infraestructura:

* 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 será necesario activar la opción 66 del DHCP que permitirá definir el servidor TFTP del que los terminales descargaran sus ficheros de aprovisionamiento



Arquitectura networking 1 V5.1.png





2.5 Conectividad en VIVAit



2.5.1 Esquema VIVAit Call



El esquema siguiente muestra todos los flujos de información existentes en un entorno típico de telefonía corporativa (sin presencia)

Flujos corporativa.png



La descripción de los flujos se puede consultar en Tabla de flujos VIVAit

2.5.2 Esquema VIVAit Suite



En el entorno de Contact Center se encuentran los siguientes flujos entre servicios (comunicaciones entre servidores).

Flujos Contact servicios.png



La descripción de los flujos se puede consultar en Tabla de flujos VIVAit



2.5.3 Esquema usuario-servidor



Entre usuarios y servicios se documentan los siguientes flujos:

Flujos Contact puestos.png



La descripción de los flujos se puede consultar en Tabla de flujos VIVAit



2.5.4 Tabla de flujos VIVAit



La sisguiente tabla muestra los flujos de datos que se establecen entre los distintos componentes del sistema VIVAit.

Lado A Lado B Puertos Sentido Observaciones
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 UDP 514 A -> B Para envío de logs de agente
VIVAit Supervisor

aplicación de supervisor

Servidor TCP 4500 A -> B Comunicación CTI
VIVAit Supervisor

portal de supervisión

Servidor TCP 3306 A -> B Acceso a Mysql Base de datos
VIVAit Tracker Servidor TCP 3306 A -> B Acceso a Mysql Base de datos
Tracker WEB Servidor TCP 3306 A -> B Acceso a Mysql Base de datos
Actualizador Servidor TCP 80 A -> B Necesario para actualizaciones de versiones de aplicaciones de agente y supervisores
Portales Servidor TCP 443 A -> B Acceso a los diferentes portales de VIVAit
Monitor Servidor TCP 8180 A -> B Wallboard
Monitorización Servidor TCP 80 A -> B Acceso a portal monitorización (Zabbix)





2.6 Gateways VIVAit



El concepto de gateway no existe como entidad funcional dentro de la plataforma VIVAit. En su arquitectura únicamente se definen nodos ACD (Automatic Call Distribution) y nodos corporativos.
Desde el punto de vista operativo, el nodo corporativo es el encargado de asumir las funcionalidades típicamente asociadas a un gateway. En particular, gestiona la interconexión con sistemas externos, incluyendo interfaces analógicas, digitales e IP, así como la conexión con la Red Telefónica Conmutada.
Por tanto, el término gateway queda limitado a un uso comercial o conceptual, sin correspondencia directa con elementos funcionales dentro de la plataforma.
En consecuencia, los procedimientos de diagnóstico y operación relativos a la conectividad con sistemas externos o con la RTC deben realizarse conforme a los mecanismos definidos para el nodo corporativo.



3 Descripción de los elementos software



3.1 Niveles funcionales del software



Los niveles funcionales o capas del software en el sistema VIVAit cumplen una función específica y se apoyan en el nivel inferior.

La lista de los mismos es la siguiente:

Nivel de sistema operativo
Nivel de conmutación de voz
Nivel de base de datos
Nivel de procesos VIVAit
Nivel de Administración
Nivel de Monitorización





3.1.1 Nivel de sistema operativo



Elemento Instancias Propósito Producto Observaciones
Ubuntu Server LTS

64 bits

Uno por servidor VIVAit Call / VIVAit Suite Actualmente (may-2026) 22.04. Bajo proyecto puede cambiarse
Debian LTS Uno por servidor VIVAit Call Actualmente (may-2026) 13 (Trixie). 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



Para más detalles, consultar el apartado Sistema Operativo



3.1.2 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 18.9 Certified
Dialplan ACD

by MDtel

Uno por servidor ACD Configuración de voz VIVAit Suite En el futuro se unificará con corporativa
Asterisk 18.9

Certified by MDtel

Uno por servidor corporativo / gateway Núcleo de conmutación de voz basado en Asterisk 18.9 y modificado por MDtel VIVAit Call Actualmente Asterisk estándar (05/26).

La instalación contempla descargar de la red la versión 18 más actualizada, siempre "CERTIFIED"

Dialplan corporativo Uno por servidor corporativo/gateway Configuración de voz| VIVAit Call En el futuro se unificará con ACD



Para más detalles, consultar el apartado Matriz de conmutación



3.1.3 Nivel de base de datos



Elemento Instancias Propósito Producto Observaciones
MySQL 8.0.45 Donde haya BBDD de cualquier tipo (incluso zabbix) Motor de Base de Datos para Ubuntu 22.04 VIVAit Call / VIVAit Suite A efectos prácticos se pretende que sea la BBDD de todos los servicios
MariaDB 11.8.3 Donde haya BBDD de cualquier tipo Motor de Base de Datos para Debian 13 VIVAit Call / VIVAit Suite A efectos prácticos se pretende que sea la BBDD de todos los servicios
DBTR Una por sistema Base de Datos sobre la que trabaja todo el entorno de tiempo real VIVAit Call / VIVAit Suite
DBHIST Una por sistema multinodo Base de Datos para postproceso, como reporting, traker, supervisor, ... Subconjunto de tablas de DBTR con la que está sincronizada 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)

DB copia Uno por servidor corporativo / gateway Copia de tablas de configuración de DBTR para respaldo de la misma VIVAit Call 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



Para más detalles, consultar el apartado Bases de Datos



3.1.4 Nivel de procesos VIVAit



La mayoría de los elementos aparecen como servicios en los nodos correspondientes.

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.

En sistemas grandes pueden contemplar más de un intz-nimitz

intz-gh En el nodo con menos carga Conocer el estado de las extensiones de diferentes nodos VIVAit Call Solo va en un nodo. Si desconocemos cual es el nodo con menos carga, instalarlo en la maquina con BDHIST
intz-tap En los nodos corporativos Encargado de la grabación SIPREC y TBC VIVAit Call Junto al modulo chan_mdtap de asterisk para enviar los flujos RTP a un elemento externo
serCen En nodo STG y nodo de gestión Encargado de la autenticidad y doble factor de los usuarios VIVAit Call / VIVAit Suite Proporciona servicios a los diferentes portales (front-end) del sistema
vivait-direct En nodo STG y nodo de gestión Centraliza y gestiona la consulta de agendas y contactos desde distintas fuentes de datos.

Alternativa a Vivait-FonBO que sigue gestionando el histórico de llamadas

VIVAit Call / VIVAit Suite Servicio invocado por los portales vivait-user y webfon2
vivait-cti Uno por servidor ACD Interfaz entre VIVAit Desk, supervisor y el manager de asterisk VIVAit Suite
motorSal Uno por servidor ACD Motor de marcador saliente automático VIVAit Suite Solo si hay marcación saliente. Junto a DBTR
myAcdSuperv Uno por servidor ACD Recopilador de datos de asterisk y actualiza en la BBDD. Genera llamadas en el marcador VIVAit Suite
recordCentral Uno por sistema Servidor de grabaciones, los agentes (recorNodo) se conectan a él VIVAit Call 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
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 Uno por sistema Se encarga de la gestión de las bases de datos, aplicando políticas de retención que limitan la persistencia de los registros hasta una fecha máxima establecida. VIVAit Call / VIVAit Suite En la BDTR es típico dejar 6 meses y en BDHIST 5 anos.
movergrabacionesanube Uno por sistema Guardar las grabaciones un un NAS del cliente VIVAit Suite Utiliza el módulo RecordCentral



Para más detalles, consultar el apartado Procesos propios VIVAit



3.1.5 Nivel de Administración



Este nivel software proporciona servicios para administrar el sistema y servicios al usuario final. Se estructura en dos capas:

Front-end: capa de presentación que interactúa con el usuario (portales web, interfaces gráficas o paneles de control), encargada de mostrar la información y recoger las acciones del usuario.
Back-end: capa de lógica y procesamiento donde se gestionan los servicios, la ejecución de aplicaciones y el acceso a datos, apoyándose en servidores como Apache HTTP Server y Apache Tomcat.



Para obtener más información del tipo administración consultar el apartado Portales de Administración.
Para ver los diferentes portales de usuario ver Portales web corporativos.






3.1.5.1 Nivel de Administración - Front-end



Se compone de dos entidades:

Servidores: donde se ejecutan las aplicaciones y servicios web, como Apache HTTP Server.
Clientes: interfaces de acceso para los usuarios, como portales web.



Elemento Instancias Propósito Producto Observaciones |
Apache2 Uno por servidor con portales Servidor de páginas web. Servidor de portales. No usa JAVA VIVAit Call / VIVAit Suite
Vivait-Call Uno por sistema Portal de administración del sistema VIVAit Call / VIVAit Suite Bajo proyecto puede existir más de uno
vivait-user Uno por sistema en nodo STG Portal de usuario, para acceso a buzones, configuración, etc. VIVAit Call Bajo proyecto puede existir más de uno
webfon2 Uno por sistema en nodo STG Portal de VIVAit Call Web VIVAit Call Bajo proyecto puede existir más de uno
webfon2-solo Uno por sistema en nodo STG Dialpad de VIVAit Call Web.

webfon2 = vivait-user + webfon2-solo

VIVAit Call Bajo proyecto puede existir más de uno
Vivait-Tracker Uno por sistema Portal de seguimiento de llamadas Denominado Tracker web. 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

Tracker-Corp Uno por sistema Portal de seguimiento de llamadas del entorno corporativo. Denominado Tracker corporativo. VIVAit Call Debe instalarse en un servidor que tenga los ficheros de grabación montados en su sistema de archivos.

Ligado a recordCentral

Monitor Uno por sistema Portal de monitores de pared de Call Center VIVAit Suite Bajo proyecto puede existir más de uno
Vivait-Supervisor Uno por sistema Portal de monitorización de llamadas del entorno corporativo VIVAit Call Bajo proyecto puede existir más de uno
Baikal Uno por sistema Servidor de calendarios para su uso en diferentes entornos de nimitz VIVAit Call / VIVAit Suite





3.1.5.2 Nivel de Administración - Back-end



Se compone principalmente de los siguientes elementos:

Servidor: infraestructura donde se alojan las aplicaciones y servicios que exponen APIs (por ejemplo, aplicaciones Java desplegadas en servidores como Apache Tomcat).
Recibe peticiones web (HTTP), ejecuta el código Java de la aplicación y devuelve la respuesta al cliente (navegador, app, etc.).
Clientes: aplicaciones externas (front-end, apps móviles, otros sistemas) que consumen las APIs del back-end.



Elemento Instancias Propósito Producto Observaciones
Tomcat11 Uno por sistema Servidor de aplicaciones web Apache Tomcat especializado en ejecutar aplicaciones desarrolladas en Java. VIVAit Call / VIVAit Suite Para proyectos especiales puede existir uno por contexto JAVA
cargaClickToCall Uno por sistema Inserción en BBDD de la tabla ACD_LISTAS_LLAMAME a través de los parámetros proporcionados VIVAit Suite Se invoca desde el portal Vivait-Call
cargaContactos Uno por sistema Inserción en BBDD de las tablas ACD_CONTACTOS y ACD_CONTACTOS_CAMPANNA a través de los parámetros proporcionados VIVAit Suite Se invoca desde el portal Vivait-Call
ChatWebService Uno por sistema Interface entre el formulario de chat del VivaDesk y el servicio de chansip VIVAit Suite Servicio de multicanal texto
GeneraConf Uno por sistema Sincroniza cambios en algunas tablas de la BBDD con ficheros Asterisk VIVAit Call / VIVAit Suite Se invoca desde el portal Vivait-Call
generaLlamada Uno por sistema Generación de una llamada telefónica a partir de la invocación al servicio VIVAit Call / VIVAit Suite Creación de un archivo de llamada Asterisk y puesta en la carpeta outgoing
InfoWS Uno por sistema Proporciona información de llamadas de la BBDD y gestiona grabaciones VIVAit Suite La información de las llamadas puede ser de DBTR o DBHIST.

Inicia/finaliza grabaciones y mediante un script se trasladan los archivos de grabación a un directorio de ficheros específico

Vivait-FonBO Uno por sistema Proporciona información de la agenda e histórico de llamadas VIVAit Call Invocado por los portales vivait-user y webfon2
Vivait-Supervisor Uno por sistema Obtiene información de la BBDD y ejecuta acciones en el entorno corporativo. VIVAit Call Se invoca desde el portal Vivait-Supervisor
Tracker-Rest Uno por sistema Proporciona información de las llamadas corporativas y los ficheros de audio de las posibles grabaciones asociadas VIVAit Call Se invoca desde el portal Tracker-Corp
Vivait-Tracker Uno por sistema Proporciona información de las llamadas y los ficheros de audio de las posibles grabaciones asociadas.

Permite valorar las llamadas

VIVAit Call / VIVAit Suite Se invoca desde el portal Vivait-Tracker
Vivait-Call Uno por sistema Gestiona DBTR. Lee, crea, borra y actualiza los registros en las tablas de nimitz VIVAit Call / VIVAit Suite Se invoca desde el portal Vivait-Call





3.1.6 Nivel de Monitorización



Elemento Instancias Propósito Producto Observaciones
Servidor Zabbix Uno por sistema Monitoriza el estado y el rendimiento del sistema en tiempo real VIVAit Call / VIVAit Suite Bajo proyecto puede existir más de uno. Típicamente irá o en BBDD replica o en nodo de gestión en instalaciones grandes
Template Zabbix Uno por sistema Define qué se va a monitorizar y cómo hacerlo de forma reutilizable VIVAit Suite
Agente Zabbix Uno por sistema a monitorizar Componente que se instala en los equipos que se quieres monitorizar para recoger información directamente del sistema VIVAit Suite
Script monitorización Zabbix Uno por sistema Amplia lo que el sistema puede vigilar, especialmente cuando algo no se puede medir con las opciones estándar VIVAit Call / VIVAit Suite



Para más detalles, consultar el apartado Monitorización en VIVAit



3.2 Versiones de módulos



Módulo VSuite V.3.1 VSuite V.3.2 VSuite V.3.3 VIVAit V.3.0 (VSuite 3.4 + VCall 3.0) VIVAit V.3.1 (VSuite 3.5 + VCall 3.1) VIVAit V.3.2 (VSuite 3.6 + VCall 3.2) VIVAit V.3.4 (VSuite 3.8 + VCall 3.4) VIVAit V.3.5 (VSuite 3.9 + VCall 3.5) VIVAit V.3.6 (VSuite 3.9 + VCall 3.6) VIVAit V.4.0 (VSuite 3.9 + VCall 4.0) VIVAit V.5.0 (VSuite 3.9 + VCall 5.0) VIVAit V.5.1 (VSuite 3.9 + VCall 5.1)
Año de lanzamiento ---- ---- ---- 2015 2016 2018 2020 2021 2022 2023 2025 2026
Sistema Operativo ---- ---- ---- Ubuntu 14.0 LTS Ubuntu 14.0 LTS Ubuntu 16.0 LTS Ubuntu 18.4 LTS Ubuntu 20.4 LTS Ubuntu 20.4 LTS Ubuntu 20.4 LTS Ubuntu 22.4 LTS nodos ACD y Cisco

Debian 12 resto de nodos

Ubuntu 22.4 LTS nodos ACD y Cisco

Debian 13 resto de nodos

MySQL (C) ---- ---- ---- 5.5 5.5 5.7 5.7 8.0 8.0 8.0 ---- ----
Mariadb (C) ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 10.11 11.4
Apache Tomcat (C) ---- ---- ---- ---- 7 8 8 9 9 9 9 11
PHP (C) ---- ---- ---- 5.6 5.6 7.0 7.0 7.4 7.4 8.2 8.4 8.4
OpenJDK (C) ---- ---- ---- ---- 7.0 8.0 8.0 11.0 11.0 11.0 11.0 21.0
Asterisk LTS (*) 1.4 nodo ACD 1.4 nodo ACD 1.4 nodo ACD 1.4 nodo ACD,

13 resto nodos

1.4 nodo ACD,

13 resto nodos

1.4 nodo ACD,

13 resto nodos

1.4 nodo ACD,

13 resto nodos

1.4 nodo ACD,

13 resto nodos

1.4 nodo ACD,

13 resto nodos

1.4 nodo ACD,

18 resto nodos

1.4 nodo ACD,

18 resto nodos

1.4 nodo ACD,

18 resto nodos

Asterisk MDTel

nodo ACD (VS)

---- ---- ---- 3.3.1 3.4.1 3,5,0 3.5.3 3.5.4 3.5.5 3.5.5 3.5.5 3.5.5
Asterisk MDTel

nodo Corp Cisco (VC)

---- ---- ---- 3.3.4 3.4.4 3.5.1 3.5.4 3.5.4 3.5.4 3.5.4 3.5.4 3.5.4
Asterisk MDTel

nodo Corp / GW (VC)

---- ---- ---- 3.3.4 3.4.4 3.5.1 3.5.4 3.5.5 3.5.6 3.5.6 3.6.0 3.7.0
BD (C) 3.2.0 3.4.0 3.5.0 3.6.0 3.8.0 3.9.0 3.11.0 3.11.1 3.11.2 3.11.3 3.20.0 3.30
CargaContactos (VS) 3.8.0 3.8.0 3.8.0 3.8.0 3.8.0 3.8.0
Dialplan ACD (VS) 3.5.0 3.6.0 3.8.1 3.8.2 3.8.3 3.8.4 3.9.0 3.10.0
Dialplan Corp (C) 3.3.1 3.5.0 3.6.0 3.8.1 3.8.2 3.8.3 3.8.4 3.9.0 3.10.0
Generaconf (C) 3.0.0 3.0.0 3.2.0 3.4.0 3.5.0 3.6.0 3.8.0 3.8.1 3.8.2 3.8.3 3.9.0 3.9.3
Instalador (C) 3.1.0 3.2.0 3.3.0 3.4.0 3.5.0 3.6.0 3.8.0 3.9.0 3.10.0 3.11.0 3.20 3.20
Intz-gh (VC) 0.1.0 0.1.1 0.1.2 0.1.3 0.1.4 0.1.5 0.1.7
Intz-nimitz (C) 2.6.0 3.0.1 3.0.3 3.4.1 3.4.2 3.4.4 3.5.0 3.7.1 3.08 4.0.0 4.0.1 4.0.3
Intz-tap (C) 0.1.0
Janus WebRTC Server (VC) --- --- --- --- --- --- --- 0.8.0 0.8.0 0.8.0 0.10.10 0.10.10
LazarusComún (VS) 3.1.0 3.2.0 3.3.0 3.4.0 3.5.0 3.6.0 3.6.1 3.6.2 3.6.3 3.6.4
Mcan (VS) --- --- --- --- --- --- --- 0.1.5 0.1.5 --- --- ---
MotorPredi (VS) --- --- --- --- --- --- 0.1.1 0.1.1 0.1.1 ---- ---- ----
Motorsal (VS) 1.4.0 3.1.0 3.2.0 3.3.0 3.4.0 3.5.3 3.6.1 3.6.1 3.6.3 3.6.4
Multimonitorweb (VS) 3.0.1 3.0.2 3.1.0 3.1.0 3.2.0 3.2.0 3.4.1 3.4.1 3.4.3 3.4.4
MyACDSuperv (VS) 5.2.0 5.3.0 5.3.0 5.3.2 5.3.2 5.3.3 6.0.1 6.0.3 6.0.4 6.0.5
Phone_prov (C) ------ ------ 3.0.1 3.0.3 3.0.3 3.0.3 3.0.4 3.0.4 3.0.4 3.0.4 3.0.5 3.0.5
Portal de administración (C) 3.1.0 3.2.0 3.3.0 3.4.0 3.5.0 3.6.0 3.8.0 3.8.3 3.8.5 3.8.6 4.1.2 4.1.3
Portal usuario (VC) --- --- --- 3.0.0 3.1.0 4.0.0 4.1.0 4.1.0 4.1.1 4.1.2 ---- ----
Nuevo portal usuario (VC) --- --- --- --- --- --- --- 1.0.0 1.0.1 1.0.2 2.0.10 2.3.1
Portal webfon (VC) --- --- --- --- --- --- --- 1.0.0 1.0.1 1.0.2 2.0.10 2.3.1
FonBo (VC) ------ ------ ------ ----- ----- ----- ----- 1.0.0 1.0.1 1.0.1 1.0.1 2.0.5
Preview (VS) 1.0.18 3.2.0 3.3.0 3.4.0 3.5.0 3.5.0 --- --- --- --- ---- ----
recordCentral (C) ----- ----- ----- 4.0.0 4.0.1 4.0.2 4.0.3 4.0.3 4.0.3 4.0.4 4.0.4 4.0.4
recordgwd (C) 1.3.0 1.3.0 3.1.0 ----- ----- ---- ---- ---- ---- ---- ---- ----
recordNodo (C) ----- ----- ----- 4.0.0 4.0.0 4.0.0 4.0.3 4.0.3 4.0.3 4.0.3 4.0.3
recordprocesad (C) 1.2.0 1.2.0 3.0.0 ----- ----- ---- ---- ---- ---- ---- ---- ----
Sercen (C) 0.03.01 0.03. 0.03.05 0.4.2
Supervisor Web (VS) 1.0.0 1.0.0 1.1.0 1.1.1 1.2.0 2.0.2
Tracker Web (C) 3.0.2 3.1.0 3.2.0 3.3.0 3.4.0 3.5.0 3.7.0 3.7.1 3.7.3 3.7.8 3.8.0
Tracker Corporativo (C) ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0.1.0
Tracker windows (C) 3.0.0 3.1.0 3.2.0 3.3.0 3.4.0 3.4.0 ---- ---- ---- ---- ---- ----
VIVA designer (VS) 1.0.23 3.0.1 3.1.0 3.1.0 3.2.0 3.2.0 ---- ---- ---- ---- ---- ----
VIVA desk (VS) 3.0.2 3.2.0 3.3.0 3.4.0 3.5.0 3.5.2 3.5.3 3.6.1 3.6.6 3.6.6 3.6.6
VIVAit Call Business IOS (VC) --- --- --- --- --- --- --- --- --- --- 2.1.6 3.17.3
VIVAit Call Business Androit (VC) --- --- --- --- --- --- --- --- --- --- 2.1.6 3.0.17
VIVAit Call Celullar --- --- --- --- --- --- --- --- --- --- 1.0.1
VIVAit Call Cloud (VC) --- --- --- --- --- --- --- --- --- --- --- ----
VIVA report (VS) 1.2.0 3.1.0 3.2.0 3.2.2 3.3.0 3.4.1 3.5.1 3.5.2 3.5.3 3.5.4
VIVA supervisor (VS) 3.0.0 3.1.0 3.2.0 3.3.0 3.4.0 3.6.1 3.8.0 3.8.1 3.8.2 3.8.3
vivait-cti (VS) 3.0.0 3.0.1 3.0.1 3.0.1 3.0.2 3.0.2 4.0.1 4.0.1 4.0.1 4.0.1 4.0.1 4.0.1
WebRTC (VC) ----- ----- ----- ----- ----- ----- ----- 0.0.1 0.0.6 0.0.7 0.0.9 0.0.10
Vivait-direc (VC) ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- 0.0.8



La distribución de los módulos software por tipo de nodo se documentan en los procesos de instalación.
Se puede consultar un ejemplo de un entrorno virualizado en el siguiente enlace Instalación VIVAit 3.5

(C): Módulo común

(VC): Módulo de VIVAit Call

(VS): Módulo de VIVAit Suite

(*) La información sobre las versiones disponibles de Asterisk se puede encontrar en Versiones de Asterisk



3.3 Sistema Operativo



En la plataforma VIVAit se utiliza el sistema operativo Linux, con dos distribuciones según la versión del proyecto:

• Hasta la versión 4.0 y para proyectos especiales de VIVAit, se emplea Ubuntu Server LTS.
• A partir de la versión 5.0 de VIVAit, se utiliza por defecto Debian LTS.



3.3.1 Sistema Operativo Ubuntu



El sistema operativo de la plataforma VIVAit, hasta la versión 4.0, se basa en Ubuntu Server LTS.
Estas versiones cuentan con soporte a largo plazo (LTS), lo que las hace más estables y con actualizaciones controladas desde Ubuntu 14.04.1.
En concreto, el sistema operativo utilizado enVIVAit es Ubuntu Server 22.04 LTS.
Para más información visitar Ubuntu Server.

Sistema operativo ubuntu V5.1.png





3.3.2 Sistema Operativo Debian



El sistema operativo de la plataforma VIVAit, desde la versión 4.0, se basa en Debain LTS.
En concreto, el sistema operativo utilizado en VIVAit es la versión número Debian 13, de nombre Trixie con soporte a largo plazo LTS.
Estas versiones cuentan con soporte a largo plazo (LTS), lo que las hace más estables y con actualizaciones controladas.
Para más información Debian “trixie”.

Sistema operativo debian V5.1.png





3.4 Matriz de conmutación



La matriz de conmutación en la plataforma VIVAit se plantea con tres núcleos de conmutación diferentes:

* Nodos ACD: el núcleo de conmutación es Asterisk 1.4 RSP
* Nodos corporativo Cisco: el núcleo de conmutación es Asterisk 18 versión certified
* Nodos corporativos / GW: el núcleo de conmutación es Asterisk 18 versión certified

Sobre este núcleo constituido por Asterisk LTS se realizan las modificaciones necesarias para implementar la plataforma VIVAit conformando Asterisk MDTel.
Para información de las diferentes versiones de Asterisk LTS visitar |Versiones de Asterisk.

Asterisk MDTEL

Dialplan VIVAit






3.4.1 Asterisk MDTel



Sobre el software Asterisk LTS instalado se realizan modificaciones para implementar las funcionalidades de conmutación de VIVAit.
Estas modificaciones se llevan a cabo mediante dos acciones complementarias, dando lugar al Asterisk MDTel.

* Archivos añadidos
* Archivos modificados



3.4.1.1 Archivos añadidos por MDtel



Los archivos añadidos son los siguientes:

  • apps/app_ucid.c
  • apps/app_cli.c
  • apps/app_crash.c
  • apps/app_mdintz.c
  • apps/app_mdintz.exports.in
  • include/asterisk/mdintz.h
  • include/asterisk/ucid.h
  • res/res_mdcal.c


apps/app_ucid.c apps/app_cli.c apps/app_crash.c apps/app_crash.exports.in apps/app_mdintz.c apps/app_mdintz.exports.in include/asterisk/mdintz.h include/asterisk/ucid.h include/asterisk/mdcrash.h res/res_mdcal.c configs/samples/MDcrash.conf include/asterisk/mdgh.h res/res_mdgh.exports.in res/res_mdgh.c channels/chan_mdtap.c apps/pqcti apps/app_md_pqcti.c


→ apps/app_mdintz.exports.in

Este archivo sirve para la exportación de funciones del mdintz para el uso por aplicaciones externas





3.4.1.2 Archivos modificados por MDTel



Los archivos modificados por MDtel son los mostrados a continuación:

  • apps/app_mixmonitor.c
  • res/res_calendar_caldav.c
  • contrib/scripts/safe_asterisk
  • contrib/init.d/rc.debian.asterisk
  • channels/sig_pri.c
  • channels/chan_sip.c


→ main/audiohook.c

audiohook.c ha sido modificado para solucionar un crash de asterisk al utilizar en el mixmonitor las opciónes r y t


→ app_crash.c

Esta nueva aplicación es sólo compatible con Asterisk 13.

La documentación de la misma se encuentra en el comando: "core show application Crash"

Esta nueva aplicación permite añadir al plan de pruebas:

  • Generación de una parada de asterisk. (Crash(IwantToGetAnAccessViolation) ó Crash(IwantToGetADoubleFreeMem))
  • Verificación de su impacto. Por ejemplo, no deben cortarse las llamadas en curso, si así está previsto por la topología.
  • Correcta generación de los "core", comprobando que funciona "backtrace" (bt).
Nota.- Esta aplicación no debería estar presente en una instalación de Asterisk 13


→ app_mdintz.c y mdintz.h

Esta aplicación sirve como interfaz a entornos (funcionalidades) creados por MDtel

Para mas información consultar la página de MDintz.

Las rutas de estos archivos son las siguientes:

apps/app_mdintz.c
include/asterisk/mdintz.h

app_mdintz.c :

app_mdintz.c orientada al proceso de enrutamiento a implementar en intz-nimitz.

El archivo .c es casi igual para asterisk 1.4.24 y asterisk 13.

Nota.- Cuando se compila para asterisk 13, es necesario comentar la línea que pone
"#define ASTERISK_OLD".

Los cambios implementados son:

  • Unificación de código entre las versiones de asterisk
  • Nuevo comando "qry"
  • Posible resolución de "Mal write" en intz-nimitz (a verificar)

En cuanto al nuevo comando, el formato es:

mdintz qry <nHostFijo> <entorno> <servicio> <par1>...<parN>


Permite interrogar a un servidor de igual modo que hace el dialplan con fines de diagnóstico. La única diferencia es que se ha añadido el parámetro "nHostFijo" que puede tomar como valor "*" (lo que solicita una interrogación secuencial a todos los servidores definidos, igual a la funcionalidad del dialplan) ó "0" a "3" (que solicita un interrogación dirigida el host indicado como hostN, y sólo a él, en archivo de configuración).


Para instalarlo, es necesario copiar:

  • asterisk/apps/app_mdintz.c
  • asterisk/include/asterisk/mdintz.h
  • En asterisk 1.4.24 conviene asegurar que se ha actualizado "asterisk/apps/app_queue.o" y "asterisk/apps/app_queue.so"
  • Luego "make", "make install" y module "unload/load" (mejor "stop now" y start)

→ scripts y rc.debian.asterisk

cambiado contrib/scripts por el modificado por MDtel
cambiado contrib/init.d/rc.debian.asterisk por el modificado por MDtel


→ Carpeta mp3 añadida al directorio addons

La carpeta mp3 en addons permite la reproducción desde el diaplan de los mensajes en mp3. En make menuselect hay que marcar el format_mp3 y app_mp3 e instalar el paquete mpg123 de ubuntu

→ sig_pri.c

Modificado para enviar/recibir el ucid en un primario qsig

Para que se envie el ucis tenemos que habilitar el envio de facilidades en el chan_dahdi.conf

facilityenable = yes


→ init.d

  • Uno de los archivos modificados ha sido init.d, se encuentra en la ruta: /etc/init.d/asterisk. La modificación realizada es la siguiente:
SAFE_ASTEISK=/usr/sbin/safe_asterisk

if [ -x $SAFE_ASTERISK ] ; then

  1. //!! wkw
DAEMON=$SAFE_ASTERISK

fi


→ safe-asterisk

  • Se encuentra en la siguiente ruta:/usr/sbin/safe-asterisk .En este archivo se ha modificado MAXFILES=32768

→ default

  • Este fichero podemos encontrarlo en: /etc/default/asterisk. La finalidad de la modificación de este fichero es poder correr como usuario Asterisk, grupo asterisk y generar cores (descomentar línea)

Las modificaciones realizadas han sido:

AST_USER="asterisk"

AST_GROUP="asterisk"

COREDUMP=yes





3.4.1.3 Nueva función de asterisk: app_cli.so

Esta función permite ejecutar desde el dialplan un comando de línea de consola de asterisk (CLI). Su primer uso (y esperamos que no último) será para lanzar los notify que los teléfonos necesitan para el reaprovisionamiento desde el portal o desde la facilidad de movilidad de usuario.

Básicamente ejecuta un comando y devuelve su salida. Utiliza un archivo intermedio que puede ser:

  • /dev/null si el campo se deja vacío, por tanto, no se puede recuperar la salida.
  • TEMP, en cuyo caso se crea un archivo temporal que se borra antes de finalizar la ejecución de la función.
  • Un nombre de fichero que es responsabilidad del dialplan el borrarlo cuando proceda.


Para instalarlo basta copiar apps/app_cli.c en el directorio "apps" de los fuentes y luego ejecutar "make" y "make install".

A continuación se pasa el resultado de "core show function CLI"

[Synopsis]

Lanza un comando CLI desde dialplan

[Description]

- CLI(nomArchSal,cmd)
- Si 'nomArchSal' está vacio, se usa '/dev/null' y no se recupera resultado
- Si 'nomArchSal'=TEMP, Se crea un archivo temporal que se borra al final
- En otro caso, se crea el archivo y no se borra

[Syntax]

CLI(nomArchSal,cmd)

[Arguments]
nomArchSal

   Archivo de salida (si se omite, /dev/null)

cmd

   Comando a ejecutar via CLI





3.4.2 Dialplan VIVAit

El Dialplan podría considerarse la columna vertebral del sistema Asterisk.

Es una colección ordenada de acciones que se llevan a cabo cuando un usuario marca una serie de números. Hace la función de una tabla de enrutamiento de llamadas.

Todas las configuraciones generales de Asterisk están accesibles en la ruta /etc/asterisk

CONCEPTOS BÁSICOS

EXTENSIONES

Una extensión es una marcación en el teclado de un teléfono. Dicha configuración podemos encontrarla en el archivo extensions.conf

Por ejemplo, un usuario podría marcar “3001” en su teléfono, y eso sería una extensión. También podría marcar un número de teléfono nacional, como por ejemplo “915881000”, y también sería una extensión.

En Asterisk pueden definirse también extensiones como texto, por tanto no debemos relacionar las extensiones únicamente con números.

Algunas reglas que sería interesante conocer serían las siguientes:

Regla Descripción
X Cualquier cifra de 0 a 9
Z Cualquier cifra de 1 a 9
N Cualquier cifra de 2 a 9
[x-y] Cualquier cifra de "x" a "y"
[xyz] Las cifras "x", "y" o "z"
. Una o más repeticiones del símbolo anterior
! Cero o más repeticiones del símbolo anterior

Estas reglas son necesarias a la hora de definir por ejemplo todos los números de teléfono posibles en España

PRIORIDADES

En lenguaje scripting, las acciones se van ejecutando de arriba a abajo en orden. En cambio, en Asterisk, el orden en el que se ejecutan las acciones es el indicado mediante números. Primero se ejecutará la acción 1, luego la 2...así sucesivamente.

Es decir no basta con definir las acciones que se llevarán a cabo, también debemos indicar el orden en el que se llevarán a cabo.

CONTEXTOS

Es mecanismo que nos permite variar el comportamiento del sistema en función del número que se marque. Su misión es aumentar la seguridad del sistema ofreciendo servicios diferenciados en función del usuario.

La sintaxis típica es el nombre del contexto englobado entre corchetes [nombre_contexto]. Si un dispositivo no tiene un contexto definido se redirige directamente al contexto por defecto.


Los ficheros que conforman el Dialplan se clasifican en:

  • Generales
  • Particulares
  • Web
Fichero Función
Generales Se encuentran los ficheros de propios de MDtel y Asterisk. Es importante remarcar que estos ficheros NO pueden ser modificados por el usuario.
Particular Estos ficheros son los únicos que puede modificar el usuario
Web Se encierran aquí los archivos generados automáticamente por la plataforma, a través del portal

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)

A continuación se muestran las tablas con los ficheros correspondientes a cada Dialplan.

Ficheros de configuración Dialplan Corporativo
GENERALES PARTICULARES WEB
ext_Grabaciones.conf
ext_InicioLlamada.conf
ext_InicioLlamada_Dahdi.conf
ext_InicioLlamada_ExtSIP.conf
ext_InicioLlamada_TrunkSIP.conf
ext_MARCAR_ColaCentralita.conf
ext_MARCAR_ColaCentralita_Dial.conf
ext_MARCAR_Cola.conf
ext_MARCAR_Cola_Dial.conf
ext_MARCAR.conf
ext_MARCAR_DejarMensaje.conf
ext_MARCAR_DejarMensaje_Dial.conf
ext_MARCAR_Extension.conf
ext_MARCAR_Extension_Dial.conf
ext_MARCAR_Externo.conf
ext_MARCAR_Externo_Dial.conf
ext_MARCAR_Facilidad.conf
ext_MARCAR_Facilidad_Dial.conf
ext_MARCAR_Facilidad_nimitz.conf
ext_MARCAR_Interno.conf
ext_MARCAR_LeerMensaje.conf
ext_MARCAR_LeerMensaje_Dial.conf
ext_MARCAR_Nodo.conf
ext_MARCAR_Nodo_Dial.conf
ext_MARCAR_SalasConf.conf
ext_MARCAR_SalasConf_Dial.conf
ext_MARCAR_Servicios.conf
ext_MARCAR_VDN.conf
MARCAR_VDN_Dial.conf
ext_MDtel.conf
ext_MDtel_Var.conf
ext_Subrutinas_AnchoBanda.conf
ext_Subrutinas_BD.conf
ext_Subrutinas_BD_Facilidad.conf
ext_Subrutinas_BD_Facilidad.conf
ext_Subrutinas_Colas.conf
ext_Subrutinas.conf
ext_Subrutinas_Enrutamiento.conf
ext_Subrutinas_finLlamada.conf
ext_Subrutinas_Grabacion.conf
ext_Subrutinas_nimitz.conf
ext_Subrutinas_Varias.conf
ext_Subscribe.conf
ext_Transfer.conf
ext_Transfer_ExtSIP.conf
ext_Transfer_TrunkInternos.conf
ext_TrunkInternos.conf
ext_TrunkInternos_Dial.conf
sip_Estatico.conf
sip_GENCUST.conf
sip_notify.conf
queues.conf
queues_GENERAL.conf
queues_PLANTILLACOLAS.conf
ext_Enrutador_Particular.conf
ext_InicioLlamada_Dahdi_Particular.conf
ext_InicioLlamada_ExtSIP_Particular.conf
ext_InicioLlamada_Particular.conf
ext_InicioLlamada_TrunkSIP_Particular.conf
ext_MARCAR_Extension_Particular.conf
ext_MARCAR_Externo_Particular.conf
ext_MARCAR_Facilidad_Particular.conf
ext_MARCAR_VDN_Particular.conf
ext_MDtel_Particular.conf
ext_TrunkInternos_Particular.conf
asterisk_WEB.conf
ext_MDtel_WEB.conf
sip_trunkExt_WEB.conf
sip_trunkInt_WEB.conf
sip_trunk_WEB.conf
sip_WEB.conf
queues_WEB.conf


Ficheros de configuración Dialplan ACD
GENERALES PARTICULARES WEB
ext_Enrutador.conf
ext_Grabaciones.conf
ext_InicioLlamada.conf
ext_InicioLlamada_CTI.conf
ext_InicioLlamada_Dahdi.conf
ext_InicioLlamada_ExtSIP.conf
ext_InicioLlamada_Marcador.conf
ext_InicioLlamada_TrunkSIP.conf
ext_MARCAR_ColaCentralita.conf
ext_MARCAR_ColaCentralita_Dial.conf
ext_MARCAR_Cola.conf
ext_MARCAR_Cola_Dial.conf
ext_MARCAR.conf
ext_MARCAR_DejarMensaje.conf
ext_MARCAR_DejarMensaje_Dial.conf
ext_MARCAR_Extension.conf
ext_MARCAR_Extension_Dial.conf
ext_MARCAR_Externo.conf
ext_MARCAR_Externo_Dial.conf
ext_MARCAR_Facilidad.conf
ext_MARCAR_Facilidad_Dial.conf
ext_MARCAR_Facilidad_nimitz.conf
ext_MARCAR_LeerMensaje.conf
ext_MARCAR_LeerMensaje_Dial.conf
ext_MARCAR_Nodo.conf
ext_MARCAR_Nodo_Dial.conf
ext_MARCAR_SalasConf.conf
ext_MARCAR_SalasConf_Dial.conf
ext_MARCAR_Servicios.conf
ext_MARCAR_VDN.conf
ext_MARCAR_VDN_Dial.conf
ext_MDtel.conf
ext_MDtel_Var.conf
ext_Subrutinas_AnchoBanda.conf
ext_Subrutinas_BD.conf
ext_Subrutinas_BD_Facilidad.conf
ext_Subrutinas_Colas.conf
ext_Subrutinas.conf
ext_Subrutinas_Enrutamiento.conf
ext_Subrutinas_finLlamada.conf
ext_Subrutinas_Grabacion.conf
ext_Subrutinas_nimitz.conf
ext_Subrutinas_Varias.conf
ext_Subscribe.conf
ext_Transfer.conf
ext_Transfer_ExtSIP.conf
ext_Transfer_TrunkInternos.conf
ext_TrunkInternos.conf
ext_TrunkInternos_Dial.conf
queues_GENERAL.conf
queues_PLANTILLACOLAS.conf
sip_GENCUST.conf
sip_GENERAL.conf
sip_notify.conf
sip_PLANTILLAEXT.conf
sip_supervision.conf


ext_Enrutador_Particular.conf
ext_InicioLlamada_CTI_Particular.conf
ext_InicioLlamada_Dahdi_Particular.conf
ext_InicioLlamada_ExtSIP_Particular.conf
ext_InicioLlamada_Marcador_Particular.conf
ext_InicioLlamada_Particular.conf.
ext_InicioLlamada_TrunkSIP_Particular.conf
ext_MARCAR_Externo_Particular.conf
ext_MARCAR_Facilidad_Particular.conf
ext_MARCAR_VDN_Particular.conf
ext_MDtel_Particular.conf
ext_TrunkInternos_Particular.conf
asterisk_WEB.conf
ext_MDtel_WEB.conf
queues_WEB.conf
sip_trunkInt_WEB.conf
sip_WEB.conf





3.5 Bases de datos (BBDD)




En construcción



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.5.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

Para cuando la BDTR contienen un número masivo de datos, existe un script que borra el contenido de ciertas tablas de la BD (tablas DAT_) dejando solamente datos de un cierto número de días configurable. Este script se llama borraRegistrosNimitz.pl; para más información consultar el apartado de Howto's.

Por defecto, a partir de la versión 3.2.0 de la plataforma, los registros se mantedrán 2 meses.

3.5.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.5.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.5.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.5.4 Diagnósticos y operaciones sobre bases de datos

3.5.4.1 Comprobación que una base de datos está arrancada

Para comprobar si la base de datos está arrancada debemos poner en el terminal : ps aux | grep mysql

Si la base de datos está arrancada y funcionando correctamente se nos mostrará en el terminal:

Base Datos bien.png

Por el contrario, si la base de datos presenta algun problema el mensaje mostrado será:

Base datos mal.png
3.5.4.2 Comprobación que la base de datos de réplica está sincronizada con la base de datos de tiempo real.

Si se necesita verificar que la base de réplica está sincronizada con la base de datos en tiempo real basta con acudir al comando : show slave status\G.

Una vez introducido veremos:

Replica.png

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. Si el valor de este campo es elevado nos indicará 
que la base de datos real con la réplica no estará sincronizada, por tanto, nos interesa que este valor sea lo más pequeño posible.



Volver al índice

3.6 Procesos propios VIVAit




3.6.1 bdCentral

El proceso bdCentral.sh es el encargado de realizar la copia de seguridad. Tiene un archivo de configuración bdCentral.conf el cual puede encontrarse en la ruta /etc/MDtel/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) La ruta donde se encuentran los logs es la siguiente: /var/log/myAcdSuperv.log

Fichero de configuación:

ARCH_LOG=/var/log/bdCentral.log

BDHOST=localhost
BDUSU=adminNimitz
BDCLAVE=imdtelnimitz
BDRUTA=/var/lib/MDtel/backupBDnimitz


IGNORE_TABLAS=(nimitz.DAT_ACD_RASTREO  nimitz.DAT_ACUMULADOS_AGENTES  nimitz.DAT_ACUMULADOS_AGENTES_COLAS
nimitz.DAT_ACUMULADOS_AGENTES_PAUSAS  nimitz.DAT_ACUMULADOS_AGENTES_VDN  nimitz.DAT_ACUMULADOS_COLAS  
nimitz.DAT_ACUMULADOS_VDN  nimitz.DAT_ACUMULADOS_VDN_COLAS  nimitz.DAT_CONTACTOS_PREPARADOS  
nimitz.DAT_IVR_INTERACCIONES  nimitz.DAT_IVR_NODOS  nimitz.DAT_IVR_PAGOS_TARJETA  nimitz.DAT_IVR_RESULT_ENCUESTAS 
nimitz.DAT_LLAMADAS  nimitz.DAT_LOG  nimitz.DAT_MUESTRAS_COLAS  nimitz.DAT_SEGMENTOS  nimitz.DAT_SESIONES_AGENTES  
nimitz.DAT_SESIONES_AGENTES_COLAS  nimitz.DAT_SESIONES_AGENTES_PAUSAS  nimitz.DAT_SESIONES_AGENTES_VDN  
nimitz.DAT_SINCRONIZA  nimitz.DAT_TR_ACD_EXTENSIONES  nimitz.DAT_TR_ACD_EXTEN_COLA  nimitz.DAT_TR_COLAS  
nimitz.DAT_VALORACIONES  nimitz.DAT_ACD_RASTREO  nimitz.DAT_ACUMULADOS_AGENTES_COLAS   
nimitz.DAT_ACUMULADOS_AGENTES_PAUSAS  nimitz.DAT_ACUMULADOS_AGENTES_VDN  nimitz.DAT_ACUMULADOS_COLAS  
nimitz.DAT_ACUMULADOS_VDN  nimitz.DAT_LLAMADAS  nimitz.DAT_MUESTRAS_COLAS  nimitz.DAT_SEGMENTOS  
nimitz.DAT_SESIONES_AGENTES  nimitz.DAT_SESIONES_AGENTES_COLAS  nimitz.DAT_SESIONES_AGENTES_PAUSAS  
nimitz.DAT_SESIONES_AGENTES_VDN  nimitz.DAT_TR_ACD_EXTENSIONES  nimitz.DAT_TR_ACD_EXTEN_COLA  nimitz.DAT_TR_COLAS  
nimitz.DAT_VALORACIONES)
  • A continuación se explica los campos mas relevantes del fichero de configuración bdCentral.conf.
Campo Descripción Posibles valores (si aplica)
ARCH_LOG /RUTA/FICHERO de log del proceso
BDHOST IP o HOST máquina base de datos de tiempo real
BDUSU Usuario acceso Base de datos de tiempo real
BDCLAVE Clave usuario acceso base de datos tiempo real
BDRUTA Ruta donde se depositará el dump de la base de datos
IGNORE_TABLAS Tablas de las que no queramos hacer backup




Volver al índice

3.6.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, este archivo puede encontrarse en la ruta /etc/MDtel/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.6.3 Intz-Nimitz

Permite integrar procesos de asterisk (del dialplan) con la base de datos; por ejemplo es el que graba segmentos, inspecciona donde está 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 Número de hilos contra la base de datos
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

Como complemento a los diagnósticos:

  • Podremos examinar el fichero de configuración del proceso en /etc/MDtel/intz-nimitz.conf
  • Podremos examinar los logs del proceso en /var/log/intz-nimitz.log

Fichero de configuración:

#
# Los nombres no pueden tener numeros
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
# Los valores comentados indican valores por defecto

base
{
	cfg
	{
		soy_demonio = 1
		hay_syslog = 0
# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
		archivo_pid = -
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
# No se usa si se activa hay_syslog
		archivo_traza = -
	}
	cfg_recarga
	{
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
		nivel_traza = 3
		pruebas = 1
		hay_flush_traza = 1
	}
	sis
	{
# No se usa. No modificar
		subsistema = 0
	}
	gmp
	{
# Numero de mensajes. No modificar
		num_msj = 1024
# Numero de buffer. No modificar
		num_buf = 1024
	}
} 

supervision
{
	puerto_escucha = 1115
} 

supervision_recarga
{
	to_periodo = 60
}

cache
{
        hay_cache = 1
}

cache_recarga
{
# to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos
        colas_to_vida = 300
        colas_num_entrada = 128
        vdn_to_vida = 300
        vdn_num_entrada = 128
}

regexp
{
	hay_regexp = 1
}

regexp_recarga
{
	num_entradas = 32
	inc_entradas = 128
	max_entradas = 1024
}

vivaitcall
{
	hay_vic = 1
	puerto_escucha = 5555
	identif = cms1
	entorno = nimitz
	max_conx = 128
}

vivaitcall_recarga
{
	to_solicitud = 3
	to_desconexion = 3
	ip_valida
	{
# Hasta 32 bloques de direcciones validas
		todas
		{
			ip = 0.0.0.0
			msk = 0.0.0.0
		}
		localhost
		{
			ip = 127.0.0.1
			msk = 255.255.255.255
		}
	}
}

enrutamiento
{
	hay_enrutamiento = 1
	max_pre_ruta_regs = 4
	max_ruta = 4
	max_ruta_desvios = 2
# Filtro de informacion de ancho de banda
# MYSDanchoBandaPasoNinguno      0
# MYSDanchoBandaPasoSoloDirectos 1
# MYSDanchoBandaPasoSoloEnPaso   2
# MYSDanchoBandaPasoTodos        3
	filtro_ancho_banda = 1
}

mysql
{
	hay_mysql = 1
	host = BDTR
	usuario = nimitz
	clave = phikau3iwCe4O0PP5b09ng==
	base_datos = nimitz
	bd_supervivencia = 0
	num_curro = 10
}

mysql_recarga
{
	to_resp = 5
}


Los siguientes son los campos del fichero de configuración int-nimitz.conf:

Variable a modificar Comentarios Posibles valores (si aplica)
soy_demonio Si corro como demonio o como proceso 1 demonio – 0 proceso
hay_syslog Si hay servidor de syslog 1 lo hay – 0 no lo hay
archivo_pid # Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
archivo_traza # Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
nivel_traza # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
pruebas
hay_flush_traza
subsistema # No se usa. No modificar
num_msj # Numero de mensajes. No modificar
num_buf # Numero de buffer. No modificar
puerto_escucha Puerto de supervisión del demonio
to_periodo Timeout para reconectar
hay_cache si guarda datos o no en cache 1 hay cache – 0 no hay cache
colas_to_vida # to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos
colas_num_entrada Número de entradas correspondiente a las colas
vdn_to_vida # to_vida = 0, no se almacenan entradas. to_vida > 0 en segundos
vdn_num_entrada Número de entradas correspondiente a los VDN
hay_regexp
num_entradas
inc_entradas
max_entradas
hay_vic
puerto_escucha Puerto de escucha a nivel de vivait-call
identif
entorno Nombre base de datos
max_conx Número máximo de conexiones a la base de datos
to_solicitud Timeout de solicitud
to_desconexion Timeout de desconexión
ip Dirección de red de escucha del intz-nimitz
msk Máscara de red de escucha del intz-nimitz
ip IP localhost
msk Máscara localhost
hay_enrutamiento Hay fase de enrutamiento o no 1 hay enrutamiento – 0 no hay
max_pre_ruta_regs Número máximo de prerutas a cargar
max_ruta Número máximo de rutas a cargar
max_ruta_desvios Número máximo de rutas de desvíos a cargar
filtro_ancho_banda Filtrar por ancho de banda 1 filtrar – 0 no filtrar
hay_mysql Hay mysql 1 hay -0 no hay
host IP o HOST máquina base de datos
usuario Usuario acceso Base de datos
clave Clave usuario acceso base de datos
base_datos Nombre de la base de datos
bd_supervivencia Hay o no base de datos de supervivencia 1 hay base de datos de supervivencia – 0 no hay
num_curro Número de conexiones simultáneas a la base de datos
to_resp Timeout de respuesta





Volver al índice


3.6.3.1 Nuevo servicio en intz-nimitz 04.00.00

Para las colas con extensiones multiterminal, se ha creado un ha creado un nuevo servicio en intz-nimitz 04.00.00.

La descripción de nuevo servicio es:

   multiTermGrupoSaltoRing
   . Devuelve la mascara con los terminales que tienen que sonar (ring) al estar la extension en una cola (queue, ringall).
   . par1 (extension)
   . Retornos posibles (ademas del los genericos) en ${MDintzRes}:
   .. OK: Todo correcto.
   .. KO: Ha habido un problema.
   . Retorno en MTERM (solo si OK): mascara con los terminales y su orden (ej: '33245289').
   . Retorno en MTERM_MENOR (solo si OK): mascara con los terminales y su orden, filtrando las de orden menor (ej: '00200200').

3.6.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)
  • Posee un fichero de configuración llamado motorSal.conf en la ruta /etc/MDtel/motorSal.conf:
#
# Los nombres no pueden tener numeros
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
# Los valores comentados indican valores por defecto

base
{
	cfg
	{
		soy_demonio = 1
		hay_syslog = 0
# Archivo con identificador de proceso: (-: /var/run/motorSal.pid)
		archivo_pid = -
# Archivo_traza: (-: stdout o /var/log/motorSal.log si soy_demonio)
# No se usa si se activa hay_syslog
		archivo_traza = -
	}
	cfg_recarga
	{
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
		nivel_traza = 2
		pruebas = 0
		hay_flush_traza = 1
#		traza_milisegundos = 1
	}
	sis
	{
# No se usa. No modificar
		subsistema = 0
	}
	gmp
	{
# Numero de mensajes. No modificar
		num_msj = 256
# Numero de buffer. No modificar
		num_buf = 256
	}
}

supervision
{
	puerto_escucha = 1120
}

supervision_recarga
{
	to_periodo = 60
}

mysql
{
	hay_mysql = 1
	host = localhost
	usuario = nimitz
	clave = phikau3iwCe4O0PP5b09ng==
	base_datos = nimitz
}

motor
{
	hay_motor = 1
	ciclos_campanna_activa = 30
# Directorio donde se almacenan las librerias dinamicas con las estrategias
# Por defecto = '/usr/lib/motorSal/estrategias'
	dir_estrategias = /usr/lib/motorSal/estrategias
}

motor_recarga
{
# Periodo de ejecucion del ciclo del motor
	to_ciclo = 10
}

muestreo
{
	hay_muestreo = 1
}


Los campos del fichero de configuración son los siguientes:

Campo Descripción Posibles valores (si aplica)
soy_demonio Si corro como demonio o como proceso 1 demonio – 0 proceso
hay_syslog Si hay servidor de syslog 1 lo hay – 0 no lo hay
archivo_pid # Archivo con identificador de proceso: (-: /var/run/motorSal.pid)
archivo_traza # Archivo_traza: (-: stdout o /var/log/motorSal.log si soy_demonio)
nivel_traza # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
pruebas
hay_flush_traza
traza_milisegundos
subsistema # No se usa. No modificar
num_msj # Numero de mensajes. No modificar
num_buf # Numero de buffer. No modificar
puerto_escucha Puerto de supervisión del demonio
to_periodo Timeout para reconectar
hay_mysql Hay mysql 1 hay -0 no hay
host IP o HOST máquina base de datos de tiempo real
usuario Usuario acceso Base de datos de tiempo real
clave Clave usuario acceso base de datos de tiempo real
base_datos Nombre de la base de datos
hay_motor Si hay campañas saliente o no 1 hay motor saliente – 0 no hay motor saliente
ciclos_campanna_activa
dir_estrategias # Directorio donde se almacenan las librerias dinámicas con las estrategias
to_ciclo # Periodo de ejecución del ciclo del motor
hay_muestreo 1 hay muestreo – 0 no hay muestreo
  • Respecto a los logs del motorSal consultar el siguiente apartado: Trazas motorSal. Los logs pueden verse en la ruta /var/log/motorSal.log




Volver al índice

3.6.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 el responsable de mostrar información en las ventanes de tiempo real del supervisor.

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

Como complemento a los diagnósticos:

  • Podremos examinar el fichero de configuración del proceso en /etc/MDtel/myAcdSuperv.cnf
  • Podremos examinar los logs del proceso en /var/log/myAcdSuperv.log




Volver al índice

3.6.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.6.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.6.6.2 escobaGrabsBd.pl

Se ejecuta sobre 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.6.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, las máquinas 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 significa que sea necesario tener 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, intenta descargar los segmentos de las llamadas y convertirlas al formato adecuado (MP3). Como una característica particular cada diez minutos, siempre que 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 y 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 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)

Como complemento a los diagnósticos:

  • Podremos examinar el fichero de configuración del proceso en /etc/MDtel/recordCentral.pconf

El fichero es el siguiente:

#
# Configuracion de recordCentral.pl
#
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
$depurar = 1; 

# 0: Arranca como proceso - 1: arranca como demonio
$soyDemonio = 1;

# Archivo de log (: salida estandar)
$logArch = '/var/log/record/recordCentral.log';

# Archivo para el pid (eliminando el .pid final)
$pidArch = '/var/run/record/recordCentral';

# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
$unaVezSolo = 0;

# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
$toBucle = 10;

# Bytes por segundo en archivos de grabaciones
$bytesPorSegundo = 16000;

# Bytes a leer en cada accceso a disco
$bytesLeerBuf = 1048576;

# Conexion de base de datos
$db='nimitz';
$dbHost = 'BDTR';
$dbPort = '3306';
$dbUsuario = 'nimitz';
$dbClave = 'ivivanimitz';

# Configuracion de la supervision
$supPort = '1114';

# Configuracion de archivos con grabaciones (Orig en nodo)
$grabHay = 0;
$grabAudioCalidad = 32;
$grabAudioFormato = 'mp3';
$grabAudioExten = 'mp3';
$grabAudioCifrado = 0;
$grabRutaUsaTimestamp = 1;
$grabRutaOrig = '/var/lib/recordNodo/grabaciones';
$grabRutaTmp = '/var/lib/recordProcesad/grabTmp';
$grabRutaDest = '/var/lib/recordProcesad/grabRecord';
$grabRutaError = '/var/lib/recordProcesad/grabError';
$segmHay = 1;
$segmUmbralTiempo = 10;
$segmMargenTiempo = 5;
$segmAudioCalidad = 32;
$segmAudioFormato = 'mp3';
$segmAudioExten = 'mp3';
$segmAudioCifrado = 0;
$segmRutaUsaTimestamp = 1;
$segmRutaTmp = '/var/lib/recordProcesad/segmTmp';
$segmRutaDest = '/var/lib/recordProcesad/segmRecord';
$segmRutaError = '/var/lib/recordProcesad/segmError';

# Seleccion de tipos de segmento a grabar separados por comas ( = todos)
$tiposSegmentoGrabar = ;

# Indica si se graba ring
$grabarRing = 0;

# Minino numero de segundos para generar segmento externo
$segmExternoMinSegs = 10;


  • Los campos del fichero de configuración son los siguientes:
Campo Descripción Posibles valores (si aplica)
recordCentral.pconf
Variable a modificar Comentarios
$depurar # 0: Solo alarmas en archivo log - 1: alarmas y trazas
$soyDemonio # 0: Arranca como proceso - 1: arranca como demonio
$logArch = # Archivo de log (: salida estandar)
$pidArch # Archivo para el pid (eliminando el .pid final)
$unaVezSolo # 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
$toBucle # Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
$bytesPorSegundo # Bytes por segundo en archivos de grabaciones
$bytesLeerBuf # Bytes a leer en cada accceso a disco
$db Nombre de la base de datos
$dbHost IP o HOST máquina base de datos de tiempo real
$dbPort Puerto de escucha de mysql
$dbUsuario Usuario acceso Base de datos de tiempo real
$dbClave Clave usuario acceso base de datos de tiempo real
$supPort Puerto de supervision del demonio
$grabHay Hay fase de enrutamiento o no
$grabAudioCalidad Calidad del audio
$grabAudioFormato Formato del archivo de grabacion
$grabAudioExten Extensión del archivo de grabacion
$grabAudioCifrado Si el archivo de grabación va cifrado
$grabRutaUsaTimestamp
$grabRutaOrig # Directorio donde se localizan las grabaciones de llamadas
$grabRutaTmp Directorio temporal de las grabaciones de llamadas
$grabRutaDest # Directorio Destino de las grabaciones de llamadas
$grabRutaError # Directorio de las grabaciones de llamadas con error
$segmHay Hay segmentos 1 hay segmentos – 0 no hay
$segmUmbralTiempo
$segmMargenTiempo Tiempo que se coge antes y despues del segmento
$segmAudioCalidad Calidad del audio
$segmAudioFormato Formato del archivo de grabacion
$segmAudioExten Extensión del archivo de grabación
$segmAudioCifrado Si el archivo de grabación va cifrado 1 se cifra – 0 no se cifra
$segmRutaUsaTimestamp
$segmRutaTmp Ruta temporal
$segmRutaDest = Ruta donde se almacenan los archivos de grabación
$segmRutaError Ruta de los archivos de grabación con error
$tiposSegmentoGrabar # Selección de tipos de segmento a grabar separados por comas ( = todos)
$grabarRing # Indica si se graba ring 1 se graba – 0 no se graba
$segmExternoMinSegs # Mínino número de segundos para generar segmento externo


  • Podremos examinar los logs del proceso en /var/log/recordCentral.log



Volver al índice

3.6.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 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 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

Como complemento a los diagnósticos:

  • Podremos examinar el fichero de configuración del proceso en /etc/MDtel/recordNodo.pconf
Se muestra a continuación el fichero de configuración:
#
# Configuracion de recordNodo.pl
#
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
$depurar = 1;

# 0: Arranca como proceso - 1: arranca como demonio
$soyDemonio = 1;

# Archivo de log (: salida estandar)
$logArch = '/var/log/record/recordNodo.log';

# Archivo para el pid (eliminando el .pid final)
$pidArch = '/var/run/record/recordNodo';

# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
$unaVezSolo = 0;

# Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
$toBucle = 5;

# Tiempo de guarda en segundos desde D_HORA_FIN hasta que se procesa llamada
$toProcesar = 30;

# Bytes por segundo en archivos de grabaciones
$bytesPorSegundo = 16000;

# Bytes a leer en cada accceso a disco
$bytesLeerBuf = 1048576;

# Conexion de base de datos
$db='nimitz';
$dbHost = 'BDTR';
$dbPort = '3306';
$dbUsuario = 'nimitz';
$dbClave = 'ivivanimitz';

# Configuracion de la supervision
$supPort = '1113';

# Quien es mi nodo para filtrar grabaciones
$miNodo = 2;

# Directorio donde se localizan las grabaciones
$grabRutaOrig = '/var/spool/asterisk/monitor';
$grabRutaDest = '/var/lib/recordNodo/grabaciones';
$grabRutaError = '/var/lib/recordNodo/grabError';
$grabRutaUsaTimestamp = 1;

# Tiempo en segundos limite a truncar en las grabaciones (0=sin limite)
$grabLimiteSegs = 0;

# Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminacion
$segmEliminarGrabacionTrato = 1;
$patronEliminarGrabacion = '/etc/MDtel/null.bin';

  • A continuación se indican los campos del fichero:


Campo Descripción Posibles valores (si aplica)
$depurar # 0: Solo alarmas en archivo log - 1: alarmas y trazas
$soyDemonio # 0: Arranca como proceso - 1: arranca como demonio
$logArch # Archivo de log (: salida estandar)
$pidArch # Archivo para el pid (eliminando el .pid final)
$unaVezSolo # 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
$toBucle # Tiempo de espera en segundos cuando no hay conexion o cuando no hay llamadas
$toProcesar # Tiempo de guarda en segundos desde D_HORA_FIN hasta que se procesa llamada
$bytesPorSegundo # Bytes por segundo en archivos de grabaciones
$bytesLeerBuf # Bytes a leer en cada accceso a disco
$db Nombre de la base de datos
$dbHost IP o HOST máquina base de datos de tiempo real
$dbPort Puerto de escucha de mysql
$dbUsuario Usuario acceso Base de datos de tiempo real
$dbClave Clave usuario acceso base de datos de tiempo real
$supPort Puerto de supervision del demonio
$miNodo # Quien es mi nodo para filtrar grabaciones
$grabRutaOrig # Directorio donde se localizan las grabaciones
$grabRutaDest Directorio destino de las grabaciones procesadas
$grabRutaError Directorio destino de las grabacionescon error
$grabRutaUsaTimestamp
$grabLimiteSegs # Tiempo en segundos limite a truncar en las grabaciones (0=sin limite)
$segmEliminarGrabacionTrato # Indica si se procesan segmentos de tipo tipoSegmEliminarGrabacion y patron eliminacion 1 se procesa – 0 no se procesa
$patronEliminarGrabacion Patron de eliminacion '/etc/MDtel/null.bin'--> para utilizar silencio

'/etc/MDtel/pito.slin'--> para utilzar un pitido (va asociado al fichero pito.slin).

  • Podremos examinar los logs del proceso en /var/log/recordNodo.log


3.6.9 Sercen

Sercen (Servicios Centrales) es un demonio de VIVAit que provee servicios centralizados a muchos elementos de la arquitectura. Sirve para identificar a los usuarios y garantizar que los mismos sean quienes dicen ser. Puede haber varias instancias en el, y diferentes servicios pueden estar en diferentes Sercen


Ejemplos de servicios:

- Autenticación, de factor simple o doble factor

- Integración con proveedores de autenticación

- Click2talk (Demonio dentro de Vivait)


Sercen permite autenticar un usuario (simple factor o doble factor), utilizando para ello la base de datos de vivait y/u otro mecanismo externo, como puede ser el directorio activo de Microsoft.

SerCen se relaciona con :


- BBDD

- Asterisk (para el click2talk)

- VIVAit Meet (para por ejemplo las funciones “botón colaborar” y ”Recursos compartidos”.

- Con los portales a los que proporciona los servicios vía webservice


3.6.9.1 Interfaz para autenticación (app-webfon / serCen)

Este interfaz permite autenticar un usuario (simple factor o doble factor), utilizando para ello la base de datos de vivait y/u otro mecanismo externo, como puede ser el directorio activo de Microsoft. El objetivo es que app-webfon obtenga un token que debe incluirse en las comunicaciones con el resto de elementos para que estos conozcan que las solicitudes proceden de un usuario autenticado. Este token también puede utilizarse para que otras aplicaciones puedan se iniciadas desde app-webfon y no se requiera de un proceso específico de autenticación para cada aplicación. De modo recíproco, app- webfon debe soportar el ser invocado con un token y, en tal caso, considerar que el usuario ya está autenticado.


Por ello, se asume que cada usuario conoce su clave. Independientemente de qui én gestione la clave, esta puede tener asociados periodos de expiración y de caducidad. Cuando finaliza el periodo de expiración, el usuario tiene que cambiar la clave obligatoriamente para poder acceder a sus credenciales (token). Tras la caducidad, ya no puede obtener credenciales válidas.


Cuando la autenticación utiliza las claves almacenadas en la base de datos vivait, serCen permite cambiar la clave. Si la validación de la clave se apoya en mecanismos externos (como puede ser el directorio activo), entonces serCen no soporta el cambio de claves, informando de ello en las respuestas correspondientes a los comandos de autenticación.



3.6.9.2 Comandos de SerCen

Los diferentes comandos de SerCen son:


COMANDOS DESCRIPCIÓN
autenticar1 Para autenticar en base al primer factor (usuario y clave).
autenticar2 Para, si procede, autenticar en base al segundo factor (pin adicional).
autenticartokenaad Autenticar empleando un token de "azure active directory"
validarToken Para autenticar a un usuario en base a un token suministrado por otra aplicación
revalidarToken Para ampliar el periodo de expiración de un token válido.
revocarToken Para que un token deje de ser válido.
cambiarClave Permite que una clave pueda se cambiada. Esto es posible cuando el usuario ha sido autenticado y, además, la clave tiene que estar siendo gestionada por vivait. Este cambio no es posible, por ejemplo, si se trata de una clave validada por un directorio activo.


3.6.9.2.1 Comandos autenticar1

Comandos autenticar1 y respuestas posibles:

autenticar1. Autenticación primer factor.

url (POST): https://<servidor_webfon>/sercen/postautenticar1

datos de entrada: {"cuenta": "fulano","clave$1aA": "dificil","aplicacion": "webfon","expira": 7200,"clvCambiar": "masdificil$1aA"}

  • "expira" es opcional y siempre posible. Permite solicitar un periodo de expiración (segs) para el token devuelto.
  • "clvCambiar" es opcional y solo se tiene en cuenta si no hay doble factor. Permite cambiar la clave del usuario, si es autenticado.


Ejemplos de posibles respuestas:


Ejemplo Respuesta
ejRes1 {"errorNum": 101,"errorCad": "Clave incorrecta"}
ejRes2 {"errorNum": 115,"errorCad": "Clave caducada"}
ejRes3 {"errorNum": 116,"errorCad": "Clave expirada","dobleFactor": "no","clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
ejRes4 ejRes4: {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "email","clvExpira": 86400}
ejRes5 {"errorNum":0,"errorCad":"OK","token": "1234567890","dobleFactor": "email","clvExpira": 86400}
ejRes6 {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "no","token2": "0987654321","expira": 3600,"clvExpira": 86400,"clvPuedeCambiar": true,"clvHaCambiado": true,"clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}


Este comando se invoca para autenticar al usuario en base a cuenta y clave. Opcionalmente, se soporta un doble factor en base a un pin que se comunica al usuario mediante correo electrónico u otro medio.

El campo "expira" en la respuesta informa sobre el token devuelto. Dicho token es válido durante un periodo que se expresa en segundos a transcurrir desde el momento en que se informa.

El campo "clvExpira" en la respuesta informa en segs. sobre cuando va a expirar la clave introducida y validada (errorNum=0). Si devuelve cero o no devuelve nada, quiere decir que no va a expirar por estar configurado de esa manera o porque es un autenticación ldap.

Al invocar este comando, app-webfon solicita, opcionalmente (campo "expira"), un periodo (en segundos) cuyo valor debe formar parte de su configuración. El valor finalmente válido es el que aparece con el mismo nombre en la respuesta (si finalmente es positiva) y si no hay doble factor.

Es responsabilidad de app-webfon el efectuar una solicitud para revalidar el token, mediante un procedimiento que se describirá posteriormente, tantas veces como considere necesario.


En lo que se refiere a las posibles respuestas a autenticar1, pueden darse varios casos:

Se produce un error: ejRes1 y ejRes2.

La clave ha expirado y no hay doble factor (ejRes3). Se invita a cambiar la clave invocando de nuevo a autenticar1 con "clvCambiar", para lo cuál se aportan datos de la complejidad requerida.

La clave es válida y hay doble factor en ejRes4.

La clave es válida y hay doble factor "totp" con usuario no enrolado en ejRes6. Se incluye un código QR que permite enrolar al usuario


La clave es válida y no hay doble factor en ejRes6. El usuario ha sido autenticado. Se devuelven "token" y "token2". También se informa sobre si es posible cambiar la clave ("clvPuedeCambiar") y sobre sus requerimientos de complejidad. Si el comando autenticar1 hubiese incluido un cambio de clave mediante el campo "clvCambiar" y este cambio hubiese sido completado, se devolverá un booleano "clvHaCambiado" para informar de ello.


3.6.9.2.2 Comandos autenticar2

Comandos autenticar2 y respuestas posibles:

autenticar2. Autenticación doble factor.

url (POST): https://<servidor_webfon>/sercen/postautenticar2

datos de entrada: {"token": "1234567890","pin": "1234","expira": 7200,"clvCambiar": "masdificil$1aA"}

  • "expira" es opcional.
  • "clvCambiar" es opcional. Permite cambiar la clave del usuario, si es autenticado.


Ejemplos de posibles respuestas:


Ejemplo Respuesta
ejRes1 {"errorNum": 102,"errorCad": "Pin incorrecto"}
ejRes2 {"errorNum": 115,"errorCad": "Clave caducada"}
ejRes3 {"errorNum": 116,"errorCad": "Clave expirada","clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}
ejRes4 ejRes4: {"errorNum": 0,"errorCad": "OK","token2": "0987654321","expira": 3600,"clvExpira": 86400,"clvPuedeCambiar": true,"clvHaCambiado": true,"clvLongitudMinima": 6,"clvRequiereNumeros": true, "clvRequiereMayusculas": true, "clvRequiereMinusculas": true, "clvRequiereCarsEspeciales": false}


Este comando se invoca para autenticar en base a un segundo factor: pin enviado por un medio de transporte independiente.

El campo "expira" en la respuesta informa sobre el token enviado y token2 devuelto. Dichos token son válidos durante un periodo que se expresa en segundos a transcurrir desde el momento en que se informa.


El campo "clvExpira" en la respuesta informa en segs. sobre cuando va a expirar la clave introducida y validada (errorNum=0). Si devuelve cero o no devuelve nada, quiere decir que no va a expirar por estar configurado de esa manera o porque es un autenticación ldap.


El campo que requiere explicación adicional es "token2". "token" puede ser traspasado a otras aplicaciones para evitar procesos de autenticación, pero esas aplicaciones (a las que no debe pasarse el valor de "token2") no podrán realizar operaciones relacionadas con el propio token, como puede ser revocarlo, cuando el usuario cierre el app-webfon. Es decir, el valor de "token2" sólo se requiere para operaciones de gestión del propio token. Sin "token2" tampoco es posible ejecutar el comando "cambiarClave".


En lo que se refiere a las posibles respuestas a autenticar2, pueden darse varios casos:


Se produce un error: ejRes1 y ejRes2.


La clave ha expirado (ejRes3). Se invita a cambiar la clave invocando de nuevo a autenticar2 con "clvCambiar", para lo cuál se aportan datos de la complejidad requerida.


El pin del doble factor es válido en ejRes4. El usuario ha sido autenticado. Se devuelve "token2" ("token" ya se tiene). También se informa sobre si es posible cambiar la clave ("clvPuedeCambiar") y sobre sus requerimientos de complejidad. Si el comando autenticar2 hubiese incluido un cambio de clave mediante el campo "clvCambiar" y este cambio hubiese sido completado, se devolverá un booleano "clvHaCambiado" para informar de ello.



3.6.9.2.3 Comando autenticartokenaad

Autenticar empleando un token de "Azure active directory"


url (POST): https://<servidor_webfon>/sercen/postautenticartokenaad


datos de entrada: {"token": "tokenrequetelargao","aplicacion": "webfon","expira": 7200} ("expira" es opcional).


Ejemplos de posibles respuestas:


Ejemplo Respuesta
ejRes1 {"errorNum": 101,"errorCad": "Token incorrecto"}
ejRes2 {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "email"}
ejRes3 {"errorNum": 0,"errorCad": "OK","token": "1234567890","dobleFactor": "no","token2": "0987654321","expira": 3600}


3.6.9.2.4 Comando validartoken

Es un comando muy simple, que permite conocer si un token es válido y su periodo de expiración.


url (POST): https://<servidor_webfon>/sercen/postvalidartoken


datos de entrada: {"token": "1234567890"}


Ejemplos de posibles respuestas:


Ejemplo Respuesta
ejRes1 {"errorNum": 100,"errorCad": "Token expirado"}
ejRes2 {"errorNum": 103,"errorCad": "Token incorrecto"}
ejRes3 {"errorNum": 0,"errorCad": "OK","expira": 2538}


3.6.9.2.5 Comando revalidartoken

Permite ampliar el periodo de expiración de un token. El periodo ampliado es el que se indica en la respuesta.


url (POST): https://<servidor_webfon>/sercen/revalidartoken


datos de entrada: {"token": "1234567890","token2": "0987654321","expira": 7200} ("expira" es opcional).


Ejemplos de posibles respuestas:


Ejemplo Respuesta
ejRes1 {"errorNum": 100,"errorCad": "Token expirado"}
ejRes2 {"errorNum": 103,"errorCad": "Token incorrecto"}
ejRes3 {"errorNum": 0,"errorCad": "OK","expira": 3600}


3.6.9.2.6 Comando revocartoken

Permite revocar un token.


url (POST): https://<servidor_webfon>/sercen/postrevocartoken


datos de entrada: {"token": "1234567890","token2": "0987654321"}


Ejemplos de posibles respuestas:


Ejemplo Respuesta
ejRes1 {"errorNum": 103,"errorCad": "Token incorrecto"}
ejRes2 {"errorNum": 0,"errorCad": "OK"}


3.6.9.2.7 Comando cambiarClave

Permite que un usuario autenticado cambie su clave y amplíe el periodo de expiración y de caducidad.


url (POST): https://<servidor_webfon>/sercen/postcambiarclave


datos de entrada:{"token": "1234567890","token2": "0987654321","clvCambiar": "masdificil$1aA"}


Ejemplos de posibles respuestas:


Ejemplo Respuesta
ejRes1 {"errorNum": 102,"errorCad": "Clave incorrecta"}
ejRes2 {"errorNum": 117,"errorCad": "Clave demasiado simple"}
ejRes3 {"errorNum": 118,"errorCad": "Clave con caracteres no soportados"}
ejRes4 {"errorNum": 119,"errorCad": "Clave no admite cambio"}
ejRes5 {"errorNum": 120,"errorCad": "Clave repetida"}
ejRes6 {"errorNum": 0,"errorCad": "OK","clvExpira": 86400}



3.6.9.3 Posibles errores
Número de error Descripción breve
0 OK
100 Token expirado
101 Pin expirado
102 Clave incorrecta
103 Token incorrecto
104 Token2 incorrecto
105 Pin incorrecto
106 Token comprometido
107 Token anulado
108 Token inválido
115 Clave caducada
116 Clave expirada
117 Clave demasiado simple
118 Clave con caracteres no soportados
119 Clave no admite cambio
120 Clave repetida
400 Error en datos de entrada
401 Error registro de extensión
402 Error en el estado del dispositivo
403 Error en el estado de la media con el navegador
404 No hay línea libre
405 La línea no está libre
406 La línea es errónea
407 Línea en estado erróneo
408 JSEP obligatorio
409 JSEP ‘offer’ obligatorio
410 Cifrado extremo a extremo no soportado
411 Canal de datos no soportado
412 Comando desconocido
413 No hay recursos
414 No hay conferencia libre
415 Error conferencia
416 Línea no conectada
500 Error interno



3.6.9.4 Logs y comandos

En serCen podemos monitorizar el funcionamiento del proceso de login de los usuarios.

systemctl status serCen.service

Resultado esperado:

serCen.service - LSB: Start/stop serCen
Loaded: loaded (/etc/init.d/serCen; generated)
Active: active (exited) since Thu 2022-02-10 15:16:46 CET;
2h 38min ago
Docs: man:systemd-sysv-generator(8)
Process: 942 ExecStart=/etc/init.d/serCen start
(code=exited, status=0/SUCCESS)
feb 10 15:16:45 VC-WebP-AytoArganda-MAD-02 systemd[1]:
Starting LSB: Start/stop serCen...
feb 10 15:16:45 VC-WebP-AytoArganda-MAD-02 serCen[942]:
Starting serCen
feb 10 15:16:46 VC-WebP-AytoArganda-MAD-02 systemd[1]:
Started LSB: Start/stop serCen.


Para listar información de serCen:

nc localhost 1125


Resultado esperado:

serCen sis ver='00.01.04.1' inic='20220210 173436' alarmas=0 ultAlar='00000000
000000'
serCen gmp msj=254/256 buf=256/256 tarea=97/102
serCen tmp uptime=1009 (0d 0h 16m 49s)
serCen wws mysql=1 conxNum=0 conxMaxPeriodo=0
serCen wwc numCacheLibre=3 numColaPend=0
serCen wwc numReq=0/0 numGet=0/0 numPost=0/0 numPut=0/0 numDelete=0/0
serCen smt numCacheLibre=5 numColaPend=0 enPeriodo=0/0 numMsj=2/0


Ejemplos del log de serCen:


Acceso:

Sercen1.png

Clave errónea:

Sercen2.png

3.6.10 Aplicación PQCTI

Pqcti es una nueva aplicacion de asterisk 13 que sirve para establecer llamadas , cada asterisk tendrá su modulo pqcti instalado y configurado. No hay una arquitectura como tal , sino una base para empezar a desarrollar cosas por encima.


PQCTI.png


La aplicación pqcti es un webservice con JSON y está configurada en un Tomcat. Cada nodo tendrá su pqcti, por lo que si ese nodo cae, no se podrán realizar consultas o conexiones desatendidas a ese nodo.


Actualmente pqcti se utiliza para:

- Las conexiones desatendidas

- Para el click2talk

- La funcionalidad de llamar desde agenda o historial en el portal de usuario VIVAit



3.6.10.1 Servicios web

Los servicios web que proporciona la aplicación son de dos tipos:


1. Operativos


Comando Descripción
cmd_llamar Inicia una llamada saliente desde una extensión vivait-call.
cmd_liberar Libera una llamada establecida, que haya sido registrada en pqcti. La llamada se identifica mediante el ucid que se pasa como parámetro de invocación.



2. Informativos


Comando Descripción
info_llamadas Informa sobre las llamadas registradas en pqcti. Devuelve un array con la información de cada llamada.
info_llamadas_num Devuelve el número de llamadas registradas en pqcti.
info_llamada Devuelve la información de la llamada cuyo ucid se pasa como parámetro de invocación.


3.6.10.2 Archivos relevantes y procedimientos de despliegue

Los archivos relevantes para construir la aplicación son:


Fuentes (directorio referenciado en donde se encuentren los fuentes de asterisk):


  • apps/app_md_pqcti.c
  • apps/pqcti/*.c y apps/pqcti/*.h
  • apps/Makefile (Que requiere de ser modificado para compilar la aplicación)



Añadir al final de "clean:" "pqcti/*.o" ------

------ Añadir debajo de "$(subst .c,.o,$(wildcard
confbridge/*.c)): _ASTCFLAGS+=$(call
MOD_ASTCFLAGS,app_confbridge)" ------
# wkw inicio
$(if $(filter app_md_pqcti,$
(EMBEDDED_MODS)),modules.link,app_md_pqcti.so): $(subst
.c,.o,$(wildcard pqcti/*.c))
$(subst .c,.o,$(wildcard pqcti/*.c)): _ASTCFLAGS+=$
(call MOD_ASTCFLAGS,app_md_pqcti)
#wkw fin (mirar clean:)
------

La compilación y despliegue se hace del modo habitual: "make" y "make install".


3.6.10.2.1 Configuración de archivos relevantes:
  • En el Dialplan. Llamada saliente (en el archivo que se considere adecuado)

A continuación se ofrece un dialplan de inicio de llamada. Conviene analizar si los contextos de transferencia son distintos a los habituales.

------
[pqcti_inicio_llamada_sale]
exten => _X.,1,NoOp(ID_DISPOSITIVO=${ID_DISPOSITIVO})
same =>      n,NoOp(UCID=${UCID})
same =>      n,NoOp(PQCTI_SAL_EXTEN=${PQCTI_SAL_EXTEN})
same =>      n,NoOp(PQCTI_SAL_ANI_NUM=$
{PQCTI_SAL_ANI_NUM})
same =>      n,NoOp(PQCTI_SAL_ANI_NAME=$
{PQCTI_SAL_ANI_NAME})
same =>      n,NoOp(PQCTI_SAL_DNIS_NUM=$
{PQCTI_SAL_DNIS_NUM})
same =>      n,NoOp(PQCTI_SAL_DNIS_NAME=$
{PQCTI_SAL_DNIS_NAME})
same =>      n,Set(__TRANSFER_CONTEXT=pqcti_transferir_llamada)
same =>      n,Set(__FORWARD_CONTEXT=pqcti_desviar_llamada)
same =>      n,Set(CALLERID(name)=$
{PQCTI_SAL_ANI_NAME})
same =>      n,Set(CALLERID(num)=${PQCTI_SAL_ANI_NUM})
same =>      n,Set(CHANNEL(hangup_handler_wipe)=$
{CONTEXT},fin,1())
same =>      n,pqctiLlamSaleIniciada
same =>      n,NoOp(INSERT en BD)
same =>      n,Goto(Cen_Inicio_SIP,${EXTEN},1)
exten => fin,1,pqctiLlamLiberada
same =>      n,NoOp(UPDATE en BD)
same =>      n,Return
------


  • Para llamada entrante


Es muy importante llamar a "ucid(0)" antes de pqctiLlamEntra y de insertar en BD. No importa si en "Cen_Inicio_TrunkSip" se invoca de nuevo a "ucid(0)" porque se mantiene el asignado.

------
[pqcti_inicio_llamada_entra]
exten => _X.,1,NoOp(ID_DISPOSITIVO=${ID_DISPOSITIVO})
same =>      n,ucid(0)
same =>      n,NoOp(UCID=${UCID})
same =>      
n,Set(__TRANSFER_CONTEXT=pqcti_transferir_llamada)
same =>      
n,Set(__FORWARD_CONTEXT=pqcti_desviar_llamada)
same =>      n,Set(CHANNEL(hangup_handler_wipe)=$
{CONTEXT},fin,1())
same =>      n,pqctiLlamEntra
same =>      n,NoOp(INSERT into DAT_CONX_DESATEN)
same =>      n,Goto(Cen_Inicio_TrunkSip,${EXTEN},1)

exten => fin,1,pqctiLlamLiberada same => n,NoOp(UPDATE DAT_CONX_DESATEN set D_HORA_FIN,DURACION) same => n,Return ------


  • En /etc/asterisk/acl.conf


Debe configurarse el acl que limita el acceso al servicio desde direcciones ip conocidas.

Un ejemplo en que se permite una red de servidores y un equipo:

------
[pqcti_acl_comandos]
deny=0.0.0.0/0.0.0.0
permit=172.25.128.0/24
permit=192.168.0.20/32
permit=127.0.0.1
------


  • En /etc/asterisk/http.conf
------
[general]
servername=vcall-nodo
enabled=yes
bindaddr=0.0.0.0
bindport=8088
prefix=vcall-nodo
sessionlimit=100
session_inactivity=30000
session_keep_alive=15000
enablestatic=no
;redirect = / /static/config/index.html
tlsenable=no
;tlsbindaddr=0.0.0.0:8089
;tlscipher=
;tlsdisablev1=yes
;tlsdisablev11=yes
;tlsdisablev12=yes
;tlsservercipherorder=yes
;[post_mappings]
;uploads = /var/lib/asterisk/uploads/
------


  • En /etc/asterisk/pqcti.conf
------
[general]
debug=false
llamadas_registrar=true

[comandos] url_comandos_v1=pqcti/v1/comandos acl=pqcti_acl_comandos
[llamada_sale] canal_A_tech=sip canal_A_dial_cad_fmt=%s contexto=pqcti_inicio_llamada_sale temporizador_segs=30 ------


  • En /etc/asterisk/ext_Subrutinas_BD.conf
;------------------------------------------------------
[Cen_Sub_updateDatConxDesaten_Fin]
;------------------------------------------------------
-----------
;------------------------------------------------------
-----------
; ${ARG1}: C_UCID

exten => s,1,NoOp(MDSUBUPDDATCONXDESCON*)
same => n,ExecIf($["${SPRV}"="1"]? Return(SUPERVIVENCIA))
same => n,ExecIf($["${ARG1}"=""]?Return(NO_UCID))
same => n,MDintz(nimitz|bd|sqlSinEspera|update DAT_CONX_DESATEN set D_HORA_FIN=now(),N_DURACION=now()- D_HORA_INICIO where C_UCID="${ARG1}")
;same => n,DumpChan same => n,Return(OK)
include => Cen_finLlamada
;------------------------------------------------------ ----------- [Cen_Sub_updateDatConxDesaten_Contestada] ;------------------------------------------------------ ----------- ;------------------------------------------------------ ----------- ; ${ARG1}: C_UCID
exten => s,1,NoOp(MDSUBUPDDATCONXDESCON*)
same => n,ExecIf($["${SPRV}"="1"]? Return(SUPERVIVENCIA))
same => n,ExecIf($["${ARG1}"=""]?Return(NO_UCID))
same => n,MDintz(nimitz|bd|sqlSinEspera|update DAT_CONX_DESATEN set B_CONTESTADA=1 where C_UCID="$ {ARG1}")
;same =>n,DumpChan same =>n,Return(OK) include => Cen_finLlamada
;------------------------------------------------------ ----------- [Cen_Sub_insertDatConxDesaten] ;------------------------------------------------------ ----------- ;------------------------------------------------------ ----------- ; ${ARG1}: ID_NODO ; ${ARG2}: C_UCID ; ${ARG3}: C_ORIGEN_NUM ; ${ARG4}: C_ORIGEN_NAME ; ${ARG5}: C_ORIGEN_EXTEN ; ${ARG6}: C_DESTINO_NUM ; ${ARG7}: C_DESTINO_NAME ; ${ARG8}: ID_DISPOSITIVO ;
exten => s,1,NoOp(MDSUBINSERTDATCONXDES*)
same =>n,ExecIf($["${SPRV}"="1"]? Return(SUPERVIVENCIA))
same => n,ExecIf($["${ARG1}"=""]?Return(NO_IDNODO)) same => n,ExecIf($["${ARG2}"=""]?Return(NO_UCID)) same => n,ExecIf($["${ARG3}"=""]?Set(ARG3=NULL)) same => n,ExecIf($["${ARG4}"=""]?Set(ARG4=NULL)) same => n,ExecIf($["${ARG5}"=""]?Set(ARG5=NULL)) same => n,ExecIf($["${ARG6}"=""]?Set(ARG6=NULL)) same => n,ExecIf($["${ARG7}"=""]?Set(ARG7=NULL)) same => n,ExecIf($["${ARG8}"=""]?Set(ARG8=NULL))
same => n,MDintz(nimitz|bd|sqlSinEspera|insert into DAT_CONX_DESATEN (D_HORA_INICIO,ID_NODO,C_UCID,C_ORIGEN_NUM,C_ORIGEN_NAM E,C_ORIGEN_EXTEN,C_DESTINO_NUM,C_DESTINO_NAME,ID_DISPOS ITIVO) VALUES(now(),${ARG1},"${ARG2}","${ARG3}","$ {ARG4}","${ARG5}","${ARG6}","${ARG7}",${ARG8}))
;same =>n,DumpChan same =>n,Return(OK)
include => Cen_finLlamada

---------------------------------------




  • En /etc/asterisk/ext_MARCAR_Extension_Dial.conf


  • En este fichero hay que añadir lo que está en negrita.
;------------------------------------------------------
-----------
[Cen_Marcar_Extension_Dial_Gosub]
;------------------------------------------------------
-----------
exten => s,1,NoOp(MDSUBMAREXTEN*)

same => n,Gosub(Cen_Sub_updAnswer,s,1(${UCID},$ {ID_DISPOSITIVO},${ENR_IDSEGMENTO}))
same => n,ExecIf($[$[${MDDEBUG}-0] > 1]?DumpChan)
;Declarar la variable PASARTONOS en el trunk que queramos same => n,ExecIf($["${PASARTONOS}"="1"]? SetChannelOption(14,0))
;Rellenar el historico de llamadas ; same => n,Gosub(Cen_Sub_updDatHisLlam_tipo,s,1($ {DIALEDPEERNUMBER},${TIPOLLAMHIST_ENTRANTE},${UCID})) same => n,Gosub(Cen_Sub_updDatHisLlam_tipo_ID,s,1($ {DIALEDPEERNUMBER},${TIPOLLAMHIST_ENTRANTE},$ {ID_HLL_S}))
; Poner contestadas las llamadas de conexiones desatendidas same => n,GosubIf($["${PQCTI_REGISTRAR()}"="SI"]? Cen_Sub_updateDatConxDesaten_Contestada,s,1(${UCID}))
same => n,Return()


Descripción de campos del archivo pqcti.conf:

• general

  • debug. Activa la depuración desde el inicio, aunque puede activarse mediante comando "pqcti debug on"
  • llamadas_registrar. Booleano que indica si se mantiene un registro de llamadas.Si se desactiva esta opción,

no hay registro y, por tanto, no se soportan los comandos "cmd_liberar" y los comandos informativos.


• comandos

  • url_comandos_v1. La parte no común de la url. Con la configuración de http.conf propuesta, la url completa sería:

http://<IP_NODO>:8089/vcall-nodo/pqcti/v1/comandos

  • acl. Configura el "acl" a utilizar en el archivo "/etc/asterisk/acl.conf"


• llamada_sale

  • canal_A_tech. Configura la tecnología de los canales de extensiones. Típicamente "sip". Podría ser "local", pero:
 ¡¡¡CUIDADO !!! si se usase un canal local, se perdería la función de "setvar" en el "peer": se pierde ID_DISPOSITIVO.


  • canal_A_dial_cad_fmt. Si los canales de extensiones fuesen "sip/<exten>", entonces este campo sería "%s". Si la tecnología fuese "local", este campo sería "%s@<contexto>/n".
  • contexto. Es el contexto en el que se inicia la llamada saliente. Como son necesarios algunos ajustes, debe existir un contexto especial antes de ir al contexto genérico "Cen_Inicio_Sip".
  • temporizador_segs. Tiempo máximo (en segs.) para el descolgado de la extensión para la que se solicita el inicio de la llamada saliente.
3.6.10.3 Aplicaciones para el dialplan de asterisk
  • pqctiLlamSaleIniciada (sin parámetros). Debe invocarse al inicio del dialplan de una llamada saliente. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".


  • pqctiLlamEntra. Debe invocarse al inicio del dialplan de una llamada entrante. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".


  • pqctiLlamLiberada. Debe invocarse al finalizar una llamada que previamente ha sido registrada en pqcti con las aplicaciones anteriores. Sólo es obligatorio que se invoque si se ha configurado "llamadas_registrar=true".




3.6.10.4 Comandos de asterisk

A continuación se muestran varios comandos de pqcti para asterisk.


Comando Descripción
pqcti show Lista los datos de configuración y de las llamadas registradas.
pqcti reload Recarga la configuración si se ha modificado "/etc/asterisk/pqcti.conf".
pqcti debug [on|off] Activa y desactiva la depuración del módulo.



3.6.10.5 Tabla en base de datos

Con el fin de que otra aplicación pueda seguir las llamadas registradas en pqcti, se ha previsto una nueva tabla en base de datos: DAT_CONX_DESATEN.

Dicha tabla integra todos los registros de todos los nodos vivait y será mantenida por el dialplan.


Por supuesto, esa tabla sólo tiene sentido cuando "llamadas_registrar=true".


------
CREATE TABLE IF NOT EXISTS `nimitz`.`DAT_CONX_DESATEN`
(
  `ID` INT NOT NULL AUTO_INCREMENT,
  `D_HORA_INICIO` DATETIME NULL,
  `D_HORA_FIN` DATETIME NULL,
  `N_DURACION` INT NULL DEFAULT 0,
  `ID_NODO` INT NULL DEFAULT NULL,
  `C_UCID` VARCHAR(32) NULL,
  `C_ORIGEN_NUM` VARCHAR(32) NULL,
  `C_ORIGEN_NAME` VARCHAR(128) NULL,
  `C_ORIGEN_EXTEN` VARCHAR(32) NULL,
  `C_DESTINO_NUM` VARCHAR(32) NULL,
  `C_DESTINO_NAME` VARCHAR(128) NULL,
  `ID_DISPOSITIVO` VARCHAR(32) NULL,
  PRIMARY KEY (`ID`),
  UNIQUE INDEX `IDX_UCID_UNIQUE` (`C_UCID` ASC)
VISIBLE,
  INDEX `IDX_HORA_INICIO` (`D_HORA_INICIO` ASC)
VISIBLE)
------


3.6.10.6 Interfaz para los servicios

Todos los servicios están implementados en base a un POST con un json en el cuerpo de la solicitud, que contiene los parámetros de invocación, y otro json en el cuerpo de la respuesta.

En ambos casos, el json es un objeto con campos.

Está implementada, como opción, el uso de un GET con parámetros, pero no se recomienda su uso, excepto para pruebas, porque puede haber problemas con el conjunto de caracteres no ascii.

Si no hay problemas a nivel de red, de transporte o en las reglas básicas del comando, el estado de la respuesta es siempre "200 OK", indicándose los posibles errores en el json de respuesta.

Todas las respuestas contienen un campo denominado "resultado" (de la ejecución) que puede tomar los siguientes valores:


  • OK. La ejecución se ha iniciado correctamente. En el caso de la llamada saliente, no quiere decir que se haya establecido y, ni siquiera, que se haya iniciado porque puede que la extensión no descuelgue.
  • ERROR. Hay un error en los parámetros de invocación o en el estado de la llamada referida y no se puede ejecutar el comando solicitado.
  • NO_EJECUTADO. Hay un problema no achacable a quién invoca y no se puede ejecutar el comando.


Si El "resultado" no es "OK", se devuelve un campo "diagnóstico" con una cadena que describe el problema detectado. Siempre es texto en español, por lo que su uso previsto es para logs.



3.6.10.7 Descipción de comandos y respuestas de json

A partir de aquí se describen los comandos y respuestas en base a json de ejemplo, ya que los campos son triviales y autoexplicativos:


  • cmd_llamar -> Inicia una llamada saliente desde una extensión vivait-call.

Resultado esperado :

cmd={
  "comando": "cmd_llamar",
  "extension": "201",
  "ani_num": "201",
  "ani_name": "ext_201",
  "dnis_num": "221",
  "dnis_name": "ext_221"
}
resp={
  "comando": "cmd_llamar",
  "ucid": "20999000031643889797",
  "estado_actual": "llam_sale_espera",
  "resultado": "OK",
  "ahora": "20220203 130317.107"
}

En el comando, sólo son obligatorios: comando, extension y dnis_num. El resto son opcionales. Los campos "ani" no deben usarse, salvo por una buena razón. El campo "dnis_num" sólo sirve para presentar el dato en el display de la extensión que inicia la llamada.



  • cmd_liberar -> Libera una llamada establecida, que haya sido registrada en pqcti.
cmd={
  "comando": "cmd_liberar",
  "ucid": "20999000031643889797"
}
resp={
  "comando": "cmd_liberar",
  "ucid": "20999000031643889797",
  "resultado": "OK",
  "ahora": "20220203 130804.526"
}

(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").


  • info_llamadas -> Informa sobre las llamadas registradas en pqcti. Devuelve un array con la información de cada llamada.
}
resp={
  "comando": "info_llamadas",
  "llamadas": [
    {
     "ucid": "20999000051643890188",
     "estado_actual": "llam_sale_iniciada",
     "duracion_segundos": 8
    }
 ],
 "resultado": "OK",
 "ahora": "20220203 130957.149"
}

(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").


  • info_llamadas_num -> IDevuelve el número de llamadas registradas en pqcti.
resp={
  "comando": "info_llamadas_num",
  "llamadas_num": 1,
  "resultado": "OK",
  "ahora": "20220203 131001.134"
}

(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").



  • info_llamada , "ucid"-> "20999000051643890188" -> IDevuelve el número de llamadas registradas en pqcti.
resp={
  "comando": "info_llamada",
  "ucid": "20999000051643890188",
  "estado_actual": "llam_sale_iniciada",
  "duracion_segundos": 14,
  "resultado": "OK",
  "ahora": "20220203 131003.638"
}

(Este comando sólo puede invocarse si se ha configurado "llamadas_registrar=true").



3.6.11 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 el uso de VIVAit Desk, y para 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 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

Como complemento a los diagnósticos:

Podremos examinar el fichero de configuración del proceso en /etc/MDtel/vivait-cti.conf

  • El fichero de configuración, vivait-cti.conf, es el siguiente:
#
# Los nombres no pueden tener numeros
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
# Los valores comentados indican valores por defecto

base
{
	cfg
	{
		soy_demonio = 1
		hay_syslog = 0
# Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)
		archivo_pid = -
# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)
# No se usa si se activa hay_syslog
		archivo_traza = -
	}
	cfg_recarga
	{
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
		nivel_traza = 3
		pruebas = 1
		hay_flush_traza = 1
	}
	sis
	{
# No se usa. No modificar
		subsistema = 0
	}
	gmp
	{
# Numero de mensajes. No modificar
		num_msj = 1024
# Numero de buffer. No modificar
		num_buf = 1024
	}
}

supercolas
{
	en_comandos = 0
	en_eventos = 0
#	archivo_conf = supercolas.conf
}

supervision
{
	puerto_escucha = 1111
}

cti
{
	hay_cti = 1
# Dimensionamiento de recursos. Uno menos, ya que cero no vale
	max_conx = 512
	max_call = 2048
	max_channel = 4096
	max_monitor = 512
	max_str_aux = 512
	puerto_escucha = 4500
	link_id = 1
#
	hay_vdn = 1
	hay_usuarios = 1
	usuarios
	{
		vivait
		{
			clave = 3RSMbPlTi61rG5pySx9hhUokz8Fyy3Nql2w8Jairfl8=
			ip = 0.0.0.0
			msk = 0.0.0.0
		}
	}
} 

cti_recarga
{
	makeCall_primero_dentro = 1
	makeCall_primero_fuera_agente_descuelga = 1
	temporizador_makeCall = 30
	fmt_canal_exten = SIP/%s
# contextos para llamadas salientes makeCall y makePredictiveCal
	contexto_makeCall_primeroFuera = Cen_MakeCallPrimeroFuera
	contexto_makeCall_primeroFueraDentro = Cen_MakeCallPrimeroFueraDentro
	contexto_makeCall_primeroDentro = Cen_MakeCallPrimeroDentro
# contextos para llamadas salientes desde myAcdSuperv
	contexto_myAcdSuperv_ProgreFuera = Cen_myAcdSuperv_ProgreFuera
	contexto_myAcdSuperv_ProgreDentro = Cen_myAcdSuperv_ProgreDentro
	contexto_myAcdSuperv_PredicFuera = Cen_myAcdSuperv_PredicFuera
	contexto_myAcdSuperv_PredicDentro = Cen_myAcdSuperv_PredicDentro
# contexto para transferencias
	contexto_redirect = Cen_Redirect
# expresiones regulares. se evaluan en el orden indicado
	expr_esExtenLocal = ^(4)[0-9]{4}$
	expr_esExtenInterna = -
	expr_esCola = ^(8)[0-9]{4}$
	expr_esPuntoDistribucion = ^(9)[0-9]{4}$
	expr_esPuntoEnrutamiento = -
	expr_esNumPrivateLocal = ^[369][0-9][0-9][0-9][0-9]$
	expr_esNumPrivateUnknown = ^[369]
	expr_esNumPublicNational = ^0?[69][0-9]{8}$
	expr_esNumPublicInternational = ^000[0-9]*
# resto siempre esNumPublicUnknown
#
	audit_hay_Call = 1
	audit_call_minutContestada = 60
	audit_call_minutNoContestada = 5
	audit_hay_AuxStr = 1
	audit_AuxStr_minut = 2
	audit_hay_MsjReq = 1
	audit_MsjReq_minut = 2
#
} 

ami
{
	max_action = 128
	ip_asterisk = localhost
	puerto_ami = 5038
	usuario_ami = vivait
	clave_ami = vivactisecret
	to_inac = 30
	to_audit = 600
	audit_max_resp = 3
}


Los siguientes son los campos del fichero de configuración:

Campo Descripción Posibles valores (si aplica)
soy_demonio # 0: Arranca como proceso - 1: arranca como demonio
hay_syslog Si hay servidor de syslog 1 lo hay – 0 no lo hay
archivo_pid # Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)
archivo_traza # Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)
nivel_traza # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
pruebas
hay_flush_traza
subsistema # No se usa. No modificar
num_msj # Numero de mensajes. No modificar
num_buf # Numero de buffer. No modificar
en_comandos
en_eventos
archivo_conf Archivo configuracion de asterisk para las supercolas
puerto_escucha Puerto de supervision del demonio
hay_cti hay cti 1 hay cti – o no hay
max_conx Numero maximo de conexiones
max_call Numero maximo de llamadas
max_channel Numero maximo de canales
max_monitor Numero maximo de grabaciones
max_str_aux
puerto_escucha Puesto escucha del demonio
link_id
hay_vdn Existen vdns 1 existen – o no existen
hay_usuarios Existen usuarios 1 existen – o no existen
clave Clave usuario cti cifrada
ip Direcion de red de escucha del cti
msk Mascara de red de escucha del cti
makeCall_primero_dentro
makeCall_primero_fuera_agente_descuelga
temporizador_makeCall Tiempo maximo para realizar llamada
fmt_canal_exten
contexto_makeCall_primeroFuera # contextos para llamadas salientes makeCall y makePredictiveCal
contexto_makeCall_primeroFueraDentro # contextos para llamadas salientes makeCall y makePredictiveCal
contexto_makeCall_primeroDentro # contextos para llamadas salientes makeCall y makePredictiveCal
contexto_myAcdSuperv_ProgreFuera # contextos para llamadas salientes desde myAcdSuperv
contexto_myAcdSuperv_ProgreDentro # contextos para llamadas salientes desde myAcdSuperv
contexto_myAcdSuperv_PredicFuera # contextos para llamadas salientes desde myAcdSuperv
contexto_myAcdSuperv_PredicDentro # contextos para llamadas salientes desde myAcdSuperv
contexto_redirect # contexto para transferencias
expr_esExtenLocal # expresiones regulares. Se evaluan en el orden indicado
expr_esExtenInterna # expresiones regulares. Se evaluan en el orden indicado
expr_esCola # expresiones regulares. Se evaluan en el orden indicado
expr_esPuntoDistribucion # expresiones regulares. Se evaluan en el orden indicado
expr_esPuntoEnrutamiento # expresiones regulares. Se evaluan en el orden indicado
expr_esNumPrivateLocal # expresiones regulares. Se evaluan en el orden indicado
expr_esNumPrivateUnknown # expresiones regulares. Se evaluan en el orden indicado
expr_esNumPublicNational # expresiones regulares. Se evaluan en el orden indicado
expr_esNumPublicInternational # expresiones regulares. Se evaluan en el orden indicado
audit_hay_Call
audit_call_minutContestada
audit_call_minutNoContestada
audit_hay_AuxStr
audit_AuxStr_minut
audit_hay_MsjReq
audit_MsjReq_minut
max_action Numero maximo de acciones en el manager de asterisk
ip_asterisk Ip del asterisk de ACD
puerto_ami Puerto del manager de asterisk ACD
usuario_ami Usuario del manager de asterisk del ACD
clave_ami Clave del manager de asterisk del ACD
to_inac Timeout de inactividad
to_audit
audit_max_resp Tiempo maximo de respuesta


  • Podremos examinar los logs del proceso en /var/log/vivait-cti.conf

3.6.12 Introducción al aprovisionamiento

En cada Centralita Telefónica existente, se puede configurar sus teléfonos IP y asignarles extensiones a cada teléfono. Para hacer un aprovisionamiento de los teléfonos es necesario que el técnico configure uno a uno manualmente utilizando su interfaz web, esto no es práctico, ya que genera muchos errores y el tiempo de implementación se incrementa drásticamente. Además, es casi imposible la administración cotidiana de los teléfonos IP. Desde MDtel se utiliza una herramienta que permite que los teléfonos IP soportados y homologados por MDtel ([ver Terminales telefónicos]) se puedan aprovisionar automáticamente, brindando una fácil implementación y administración cotidiana.


3.6.12.1 ¿Qué es aprovisionar?

Aprovisionar un teléfono es el proceso de configuración automático de teléfonos IP para su uso con una Centralita Telefónica de forma remota. Una vez que aprovisione un teléfono, el teléfono automáticamente se configurará correctamente y podrá administrar los teléfonos de forma centralizada y remota, sin tener que iniciar sesión en la interfaz web de cada uno de los teléfonos.

El aprovisionamiento de teléfono facilita enormemente la administración cotidiana de los teléfonos IP. Esto hace que sea fácil de cambiar las contraseñas de extensión,realizar desvíos de llamadas, nombre a mostrar, mensajería y demás configuraciones, ya que puede hacerlo de forma centralizada para todos los teléfonos desde el portal de administración y luego transferir los cambios al teléfono.

3.6.12.2 TFTP

TFTP son las siglas de Trivial File Transfer Protocol (Protocolo de transferencia de archivos trivial).

Es un protocolo de transferencia muy simple semejante a una versión básica de FTP. TFTP a menudo se utiliza para transferir pequeños archivos entre terminales en una red.

Algunos detalles del TFTP:

  • Utiliza UDP (puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza los

puertos 20 y 21 TCP).

  • No puede listar el contenido de los directorios.
  • No existen mecanismos de autenticación o cifrado.
  • Se utiliza para leer o escribir archivos de un servidor remoto.
  • Soporta tres modos diferentes de transferencia, "netascii", "octet" y "mail”.
3.6.12.3 Funcionamiento del servidor phoneprove-TFTP

A continuación se muestra un esquema que facilita el entendimiento del funcionamiento del servidor phoneprove-TFTP:

Funcionamiento Servidor.png

El servidor Phoneprove-TFTP se encarga del aprovisionamiento masivo de terminales, es de gran utilidad porque cualquier cambio en los teléfonos pueden ser realizados a nivel DHCP y todos los teléfonos tomarán la nueva configuración luego de reiniciarlos.

Desde phoneprove-TFTP se generara los archivos necesarios para cada teléfono y que sirven para ser aprovisionados automáticamente. El servidor phoneprove-TFTP tiene alojados los ficheros de configuración están ordenados según las direcciones MAC de los teléfonos. El teléfono “preguntará” al servidor cual es su fichero de configuración utilizando su dirección MAC. Este a través de su MAC , consulta en la base de datos para ofrecer al terminal los datos de configuración según su plantilla, cual sera su extensión , cual sera el usuario propietario, entre otras cosas.

 Nota: En instalaciones grandes habrá más de uno, quizás uno por sede grande; depende de la infraestructura de DHCP.
3.6.12.4 Parámetros necesarios de Aprovisionamiento de Teléfonos
Notas: el aprovisionamiento desarrollado por MDtel, no emplea un fichero por cada 
teléfono, sino que emplea una plantilla por cada modelo de teléfono.
Debe haber una configuración previa del servidor 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 
activar la opción 66 que permitirá definir el servidor TFTP del que los terminales cogerán sus ficheros de aprovisionamiento.
El aprovisionamiento desde el portal de administración solo es posible para aquellos teléfonos IP homologados y probados desde MDtel   
[ver Terminales  telefónicos] 


Como existen parámetros comunes de todos los teléfonos de la misma marca de fabricante, muchos de los parámetros necesarios para el aprovisionamiento como comentamos se han generado desde MDtel en forma de plantillas, que estarán disponibles en el portal de administración VIVAit [| ver plantilla del portal de administración VIVAit].

La configuración de un teléfono SIP es muy sencilla y en no es necesario tener conocimientos avanzados de informática o de telefonía. Cada una de estas plantillas que sirven para aprovisionar un teléfono IP homologado, algunos de los parámetros predeterminados se explicarán a continuación .


3.6.12.4.1 Parámetros de Aprovisionamiento globales
  • Configuración de la red y MAC.
  • Zona horaria.
3.6.12.4.2 Parámetros de Aprovisionamiento Personales

Además de los parámetros de aprovisionamiento globales, el teléfono también obtendrá información de configuración individual, tales como:

  • Número de Extensión.
  • Nombre y Contraseña de usuario SIP.
  • Configuración de Teclas BLF.
  • Contraseña de la Interfaz Web del Teléfono IP.
  • Idioma de la Pantalla.
  • Orden de Preferencia de los Codecs.
3.6.12.5 Aprovisionamiento de teléfonos nivel usuario
 Notas: La dirección MAC debe estar especificada en letras mayúsculas.
 La dirección MAC del teléfono se puede encontrar en la etiqueta adhesiva en la parte inferior del teléfono, o de lo contrario se deberá acceder desde
 el menú del propio terminal.   

Los pasos a seguir son los siguientes:

1) Dar de alta el teléfono en el portal de administración, se debe seleccionar el modelo del teléfono, e indicar la dirección MAC del teléfono a aprovisionar, todo ello desde el portal de administración VIVAit. Para mas información ver [del portal de administracion| aprovisionamiento del portal de administración VIVAit].

2) En el mismo portal de administración se deberá crear una extensión , asignar a la extensión el teléfono que se quiera aprovisionar, elegir la plantilla adecuada del teléfono y el usuario propietario (solo si sera un puesto fijo) desde [| extensiones del portal de administración].

3) Conectar el teléfono a la red LAN informática (conectarlo al router o switch) para que tenga acceso a Internet:

  • El teléfono enviará un mensaje de multidifusión a través de la LAN.
  • Este será captado por la Central Telefónica siempre que esté en la misma LAN.
  • Al teléfono se le enviará una URL de aprovisionamiento.

4) Como la mayoría de teléfonos IP del mercado al arrancar una vez sabiendo la URL de aprovisionamiento piden una serie de archivos de configuración para aprovisionarse vía TFTP. EL servidor phoneprove-TFTP, detectara la petición y a través de la MAC y datos del usuario, consultará en la base de datos los datos necesarios para aprovisionar al teléfono y si todo funciona correctamente mandara al teléfono IP los datos de configuración necesarios para funcionar.

5) Asegúrese de que el teléfono encuentren el servidor TFTP, para ello esperar un tiempo adecuado para que termine el aprovisionamiento.


6) Finalmente aparecerá como registrado en la centralita, obtendrá una dirección IP y podra funcionar según la configuración establecida.

 Nota: Si no se reaprovisiona tras un periodo largo de tiempo, desenchufe el cable de alimentación eléctrica 
o el cable Ethernet (si se utiliza la alimentación en línea PoE) para reiniciar los teléfonos.
3.6.12.6 Aprovisionamiento de teléfonos nivel técnico
3.6.12.6.1 Plantilla de configuración

La plantilla de configuración empleadas en el apartado [| plantilla del portal de administración VIVAit] de cada modelo está formada por una serie de variables.

Los valores se obtienen de la tabla de la base de datos CEN_TELEFONOS, CEN_USUARIOS, ACD_EXTENSIONES, ACD_NODOS, COM_NODOS... correspondientes a la extensión del teléfono, usuario, nodo, etc.

variable ${NODO1_C_NOMBRE}='corp-ast13'
variable ${EXTEN_C_CLAVE_REGISTRO}='Tel21002'
variable ${USU_C_CODIGO_POSTAL}=28034'
variable ${SEDE_C_CODIGO_POSTAL}='28034' 
variable ${USU_C_NOMBRE}='Juan Antonio'
variable ${USU_C_APELLIDO2}='Ramirez'
variable ${SEDE_C_NOMBRE}='RED_LAB'
variable ${NODO2_C_NOMBRE}= NULL
variable ${EXTEN_C_NOMBRE}= 21002
variable ${USU_C_LOCALIDAD}= 
variable ${USU_C_NOMBRE_MOSTRAR}='Juan' 
variable ${NODO1_C_IP}='175.25.129.70' 
variable ${MODEL_C_PREFIJO_PLANTILLA_MAC}='T28P' 
variable ${SEDE_C_LOCALIDAD}='Madrid' 
variable ${USU_C_APELLIDO1}='Casas' 
variable ${NODO2_C_IP}= NULL
variable ${TF_ID_EXTENSION}='5' 
cargando campos idExten=5
3.6.12.6.2 Ficheros y paquetes necesarios

Paquetes previos: libnet-tftpd-perl, tftp-hpa, libnet-address-ip-local-perl Usuario de funcionamiento: root

  Nota:  los archivos y directorios que generemos podrian necesitar que se permitiera el acceso al archivo de lectura 
y escritura en el servidor TFTP.

Archivos necesarios:

/usr/local/sbin/phoneprov-tftp.pl 
/usr/local/sbin/phoneprov-tftp.pm
/etc/MDtel/phoneprov-tftp.pconf 
/etc/init/phoneprov-tftp.conf 
/etc/logrotate.d/phoneprov-tftp 


Directorios a crear:

/var/lib/phoneprov-tftp/plt 
/var/lib/phoneprov-tftp/bin
  • El archivo de configuración, phoneprov-tftp, es el siguiente:
#
# Configuracion de phoneprov-tftp.pl
#
# 0: Solo alarmas en archivo log - 1: alarmas y trazas
$depurar = 1;

# 0: Arranca como proceso - 1: arranca como demonio
$soyDemonio = 1;

# Archivo de log (: salida estandar)
$logArch = '/var/log/phoneprov-tftp.log';

# Archivo para el pid
$pidArch = '/var/run/phoneprov-tftp';

# 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
$unaVezSolo = 0;

# Conexion de base de datos
$db='nimitz';
$dbHost = 'BDTR';
$dbPort = 3306;
$dbUsuario = 'nimitz';
$dbClave = 'ivivanimitz';

# Configuracion de la supervision
$supPort = 1123;

# Configuracion de servidor TFTP
#
# Los archivos estaticos no tienen variables. Se sirven sin modificar.
# Estan en el arbol de directorios a partir del indicado por '$dirEstatico'
#
# Los archivos dinamicos soportan sustitucion de varibles.
# Las plantillas con variables a sustituir estan en el arbol de directorios
# a partir del indicado por '$dirPlantilla'.
# Los archivos temporales con variables sustituidas estan en el arbol
# de directorios a partir del indicado por '$dirDinamico'.
# Los archivos dinamicos se identifican porque contienen una mac.
# Tambien se identifican en base a las lineas que comienzan con '@'.
# En este ultimo caso, no se refieren a un telefono y puede tener pocas vars.
# 
$miDir = ;
$bindDir = ;
$bindPuerto = 69;
$dirPlantilla = '/var/lib/phoneprov-tftp/plt';
$dirEstatico = '/var/lib/phoneprov-tftp/bin';
$dirDinamico = '/tmp';
$toRRQ = 10;
$toACK = 5;
$errACK = 3;
$tamBlq = 512;

# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_EXTENSIONES 
$clasesCamposExtension = '50';
# Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_USUARIOS 
$clasesCamposUsuario = '70';

# Expresiones regulares de archivos con mac estaticos (separados por '>')
$nomArchMacEstaticos = '^SEP.*\.tlv$>^SEP.*\.bin$>^SP.*\.xml$';

# Traducciones previas de nombres de archivo estaticos
#%archivo = 'trad';

# Traducciones previas de nombres de archivo dinamicos sin mac
@y000000000044.cfg = 'Yealink-T23G-comun.cfg';
@y000000000034.cfg = 'Yealink-T21P-comun.cfg';
@y000000000000.cfg = 'Yealink-T28P-comun.cfg';
@y000000000004.cfg = 'Yealink-T26P-comun.cfg';
@y000000000036.cfg = 'Yealink-T41P-comun.cfg';
@y000000000058.cfg = 'Yealink-T58V-comun.cfg';
@y000000000069.cfg = 'Yealink-T27G-comun.cfg';
@snom710.htm = 'Snom-710-comun.cfg';
@snom710-firmware.xml = 'Snom-710-firmware.xml';
@spa514G.cfg = 'cisco-spa514G.cfg';
@spa512G.cfg = 'cisco-spa512G.cfg';


  • Los campos del fuchero de configuración y su significado se muestran en la su¡iguiente tabla:
Campo Descripción Posibles valores (si aplica)
$depurar # 0: Solo alarmas en archivo log - 1: alarmas y trazas
$soyDemonio # 0: Arranca como proceso - 1: arranca como demonio
$logArch = # Archivo de log (: salida estandar)
$pidArch # Archivo para el pid
$unaVezSolo # 0: El programa se ejecuta indefinidamente - 1: solo una vez (util en depuracion)
$db Nombre de la base de datos
$dbHost IP o HOST máquina base de datos de tiempo real
$dbPort Puerto de escucha de mysql
$dbUsuario Usuario acceso Base de datos de tiempo real
$dbClave Clave usuario acceso base de datos de tiempo real
$supPort Puerto de supervisión del demonio
$miDir
$bindDir bindAddres
$bindPuerto Puerto de escucha del demonio
$dirPlantilla Directorio de las plantillas de aprovisionamiento
$dirEstatico Directorio archivos estáticos
$dirDinamico # Los archivos temporales con variables sustituidas están en el árbol de directorios a partir del indicado por '$dirDinamico'.
$toRRQ
$toACK Timeout ACK
$errACK Número de errores de ACK
$tamBlq Tamaño del bloque de archivos a transferir
$clasesCamposExtension # Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_EXTENSIONES
$clasesCamposUsuario # Valores de E_TIPO_CAMPO en tabla COM_CAMPOS que enganchan ID_TABLA con CEN_USUARIOS
$nomArchMacEstaticos # Expresiones regulares de archivos con mac estaticos (separados por '>')
%archivo # Traducciones previas de nombres de archivo estaticos
@y000000000044.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@y000000000034.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@y000000000000.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@y000000000004.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@y000000000036.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@y000000000058.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@y000000000069.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@snom710.htm # Traducciones previas de nombres de archivo dinámicos sin mac
@snom710-firmware.xml # Traducciones previas de nombres de archivo dinámicos sin mac
@spa514G.cfg # Traducciones previas de nombres de archivo dinámicos sin mac
@spa512G.cfg # Traducciones previas de nombres de archivo dinámicos sin mac

3.6.13 Watchdog

Se trata de una aplicación del asterisk que monitoriza el SIP y en caso de fallo, pasado un cierto tiempo, reinicia el asterisk y genera un core. Si escribimos en CLI de asterisk perro tenemos los siguientes comandos:

Activar Activar el Watchdog
Desactivar Desactiva el Watchdog
Parada IWantToStop Reinicia el asterisk y genera un core para pruebas
Reload Realiza una recarga del Watchdog y aplica cambios en su configuración
Show Ver el estado del Watchdog

perro avisado=0 activo=1 segsDormir=1 segsInic=60 segsGuarda=30 maxErr=3 perro nombre=sip_monitor_udp lwp=[15437] segsInic=60 segsGuarda=30 hace=11 err=0/5

El dato "hace" informa de cuanto tiempo ha transcurrido desde el último tick. Facilita la calibración del parámetro de configuración "segs_guarda", normalmente es 30

Tiene un fichero de configuración ubicado en /etc/asterisk/MDcrash.conf

Sección [perro] activo=yes (Si esta o no activo)

segs_dormir=1 (Un tick por segundo)

segs_inic=60

segs_guarda=30

max_errores=3

Sección [sip_monitor_udp] segs_inic=60

segs_guarda=30 (Cada 30 segundos si no reciba trafico SIP genera core)

max_errores=5 (Número máximo de errores)


3.6.14 Proceso de Backup

Las plataformas VIVAit Call y VIVAit Suite incluyen un script para realizar un proceso de backup.

Se utilizará el script backup.sh, que se encuentra en el directorio etc/MDTel.

Se ejecuta automaticamente mediante el uso de un cron

texto del cron:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
0 2 * * * root  /etc/MDtel/backup.sh /etc/MDtel/backup.cfg

Para activar el script hay que descomentar la línea

# m h dom mon dow user command

Los directorios de los que se hace copia son:

  • DIR=var/lib/asterisk/sounds/Particular
  • DIR=var/lib/asterisk/moh
  • DIR=etc
  • DIR=etc/asterisk
  • DIR=etc/cron.d
  • DIR=etc/dahdi
  • DIR=etc/exim4
  • DIR=etc/ha.d
  • DIR=etc/logrotate.d
  • DIR=etc/MDtel
  • DIR=etc/mysql
  • DIR=etc/network
  • DIR=etc/zabbix
  • DIR=usr/local/sbin

Por defecto se realiza un backup cada dos horas en la carpeta /var/spool/MDtel/backup.

Para cambiar la ruta de destino del backup habrá que modificar el fichero backup.sh, en concreto modificar la variable MDTEL.

El fichero backup.cfg que se genera incluye copia de la siguiente información:

  • Ficheros de configuración de la aplicación.
  • Base de Datos.
  • Dialplan.

Se guardarán 10 copias del fichero backup.cfg

Los campos disponibles en el fichero son los siguientes:

Campo Descripción Posibles valores (si aplica)
IP_BD IP o HOST máquina base de datos de tiempo real
HAY_SMB Si hay o no servidor SAMBA 1 si existe servidor SAMBA o 0 si no existe
HOST_SMB IP o HOST servidor SAMBA
USU_SMB Usuario acceso servidor SAMBA
CLAVE_SMB Clave usuario acceso servidor SAMBA
RUTA_SMB Ruta donde se guardará el backup en el servidor SAMBA

Para recuperar una plataforma utilizando el backup, habrá que instalar una máquina nueva y cargar los ficheros de configuración, Base de Datos y Dialplan guardados en el proceso de backup.

3.6.14.1 Información adicional: como funciona un cron

La información sobre el fucnionamiento de un cron puede encontrarse en: Información sobre el comando cron

3.6.15 CHAT

La información para configurar el CHAT y su funcionamiento puede encontrarse en:

[enlace]

3.6.16 MEET

El esquema de conexión para el Meet es el siguiente:

Conexion.jpg


La configuración necesaria en los navegadores, para posibilitar que se puedan compartir pantallas, se encuentra en el siguiente enlace


Ficheros:

  • El fichero config.json tiene la configuración necesaria para proporcionar el servicio.


Fichero de configuracion MEET:

/etc/janus/janus.cfg /etc/janus/janus.plugin.echotest.cfg /etc/janus/janus.transport.http.cfg /etc/janus/janus.transport.websockets.cfg /etc/janus/vivait.plugin.meet.cfg /etc/janus/vivait.plugin.move.cfg

En los archivos de configuracion, es obligatorio revisar:

  • janus.cfg
interface = IP_NODO
server_name = IP_NODO
ice_enforce_list = IP_NODO (e ip publicas, si las hay)
  • vivait.plugin.meet.cfg
meet_url = https://IP_NODO/meet#
local_nodo_id = ID_NODO
local_ip = IP_NODO (escucha [sip])
email_from_default_invitation = vivait-meet-18-04@mdtel.local
smart_host = mdsmtp.mdtel.net
  • vivait.plugin.move.cfg
local_nodo_id = ID_NODO
local_ip = IP_NODO (escucha [sip])

Fichero de logs:

/var/log/janus.log


Los posibles problemas de conexión de los usuarios al portal habrá que analizarlos en la consola para analistas del  navegador.

La configuración necesaria en el portal de administración de VIVAit Call se puede consultar en este enlace.

3.6.17 Gran Hermano (GH)

Gran Hermano (GH) controla el estado de las extensiones de diferentes nodos. Esto permite gestionar servicios como la movilidad avanzada, la retrollamada entre extensiones de diferentes nodos, el uso de BLF's por parte de los usuarios en movilidad,…

Esquema de instalación:

Gran hermano.png


GH solo se instala en un nodo. Recomendamos instalarlo en el nodo con menos carga. Si desconocemos cual es, lo instalaremos en la maquina con BDHIST.


3.6.17.1 Intz-gh

El demonio que gestiona el Gran Hermano es Intz-gh, que se encuentra en versión V0.1.0.

El demonio tiene un fichero de configuración: /etc/Mdtel/intz-gh.conf con el siguiente aspecto:

#
# Los nombres no pueden tener numeros
# Si el valor de una cadena contiene espacios, se pondra entre comillas dobles
# Los valores comentados indican valores por defecto
base
{
cfg
{
soy_demonio = 1
hay_syslog = 0
# Archivo con identificador de proceso: (-: /var/run/intz-nimitz.pid)
archivo_pid = -
# Archivo_traza: (-: stdout o /var/log/intz-nimitz.log si soy_demonio)
# No se usa si se activa hay_syslog
archivo_traza = -
}
cfg_recarga
{
# Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
nivel_traza = 3
pruebas = 1
hay_flush_traza = 1
# traza_milisegundos = 1
}
sis
{
# No se usa. No modificar
subsistema = 0
}
gmp
{
# Numero de mensajes. No modificar
num_msj = 256# Numero de buffer. No modificar
num_buf = 256
}
} 
supervision
{
puerto_escucha = 1116
}
supervision_recarga
{
to_periodo = 60
}
regexp
{
hay_regexp = 1
}
regexp_recarga
{
num_entradas = 32
inc_entradas = 128
max_entradas = 1024
}
vivaitcall
{
hay_vic = 1
puerto_escucha = 5556
identif = gh_000
entorno = gh
max_conx = 4
}
vivaitcall_recarga
{
to_solicitud = 10
to_desconexion = 10
ip_valida
{
# Hasta 32 bloques de direcciones validas
todas
{
ip = 0.0.0.0
msk = 0.0.0.0
}
localhost
{
ip = 127.0.0.1
msk = 255.255.255.255}
}
}
mysql
{
hay_mysql = 1
host = BDTR
usuario = nimitz
clave = phikau3iwCe4O0PP5b09ng==
base_datos = nimitz
}
mysql_recarga
{
to_resp = 5
}
gh1
{
hay_gh1 = 1
# umbrales para el numero de digitos de una extension
# sirve para saber si un peer es una extension o un enlace
exten_min_digi = 3
exten_max_digi = 8
# numero maximo de extensiones soportadas
exten_max = 500
# numero maximo de enlaces soportados
enla_max = 20
# numero maximo de retrollamadas activas concurrentes
retro_max = 50
# numero maximo de retrollamadas activas concurrentes para una extension como destino (max 31)
retro_max_b = 4
}
gh1_recarga
{
# tiempo maximo en segs. para activar una retrollamada tras finalizar llamada
to_retro_candidato = 60
# tiempo maximo en segs. que una retrollamada espera a que las extensiones esten libres
to_retro_activo = 300
# temporizador de limpieza de tablas en segs.
to_limpiar = 10
}
ias
{
hay_ias = 1
url = mdgh_rest
puerto = 8090
}ias_recarga
{
# tiempo maximo en segs. para conectar con asterisk para comandos
to_conx_cmd = 10
# periodo en horas para actualizar lista de id de nodos y sus direcciones ip
to_lista_nodos = 1
}

Los campos del fichero de configuración y su significado son los siguientes:


Campo Descripción
soy_demonio # 0: Arranca como proceso - 1: arranca como demonio
hay_syslog Si hay servidor de syslog
archivo_pid # Archivo con identificador de proceso: (-: /var/run/vivait-cti.pid)
|# Archivo_traza: (-: stdout o /var/log/vivait-cti.log si soy_demonio)
nivel_traza # Nivel_traza: (0: alarma, 1: aviso, 2: info, 3: depuAlto o 4: depuBajo)
pruebas
hay_flush_traza
traza_milisegundos
subsistema # No se usa. No modificar
num_msj # Numero de mensajes. No modificar
num_buf # Numero de buffer. No modificar
puerto_escucha Puesto escucha del demonio
to_periodo Timeout para reconectar
hay_regexp
num_entradas
inc_entradas
max_entradas
hay_vic
puerto_escucha Puerto de escucha a nivel de VIVAit Call
identif
entorno Nombre base de datos
max_conx Número máximo de conexiones a la base de datos
to_solicitud Timeout de solicitud
to_desconexion Timeout de desconexión
ip Dirección de red de escucha del intz-nimitz
msk Mascara de red de escucha del intz-nimitz
ip IP localhost
msk mascara localhost
hay_mysql Hay mysql
host IP o HOST maquina base de datos
usuario Usuario acceso Base de datos
clave Clave usuario acceso base de datos
base_datos Nombre de la base de datos
to_resp Timeout de respuesta
hay_gh1 Hay intz-gh
exten_min_digi # umbrales para el numero de dígitos de una extensión # sirve para saber si un peer es una extensión o un enlace
exten_max_digi
exten_max # numero máximo de extensiones soportadas
enla_max # numero máximo de enlaces soportados
retro_max # numero máximo de retrollamadas activas concurrentes. Valor por defecto --> 50
retro_max_b # numero máximo de retrollamadas activas concurrentes para una extensión como destino (max 31). Valor por defecto --> 4
to_retro_candidato # tiempo máximo en segs. para activar una retrollamada tras finalizar llamada. Valor por defecto --> 60
to_retro_activo # tiempo máximo en segs. que una retrollamada espera a que las extensiones estén libres. Valor por defecto --> 300
to_limpiar # temporizador de limpieza de tablas en segs.
hay_ias
url
puerto
to_conx_cmd # tiempo máximo en segs. para conectar con Asterisk para comandos
to_lista_nodos # periodo en horas para actualizar lista de id de nodos y sus direcciones ip


Para saber si GH funciona correctamente usaremos el comando nc localhost 1116, obteniendo resultados similares a los siguientes:

  • intz-gh sis ver='00.01.00' inic='20181007 081237' alarmas=0 ultAlar='00000000 000000'
  • intz-gh gmp msj=252/256 buf=256/256 tarea=95/102
  • intz-gh tmp uptime=86503 (1d 0h 1m 43s)
  • intz-gh vic identif='gh_000' entorno='gh' conx=0/4 numConx=2349(7)
  • intz-gh regExpr entr=32/32/1024 numRegExpr=0 consul=0(0)
  • intz-gh ias nodos=3 cmd=11(0) cmdErr=0 tresp=0
  • intz-gh gh1 exten=9/500 enla=1/20 retro=0/0/50
  • intz-gh gh1 soli=2349(0) soliErr=0(0) soliEncol=0(0)

Los log's que genera el sistema se encuentran en: /var/log/intz-gh.log

3.6.17.2 mdgh.conf y Mdintz.conf

Además existen dos ficheros de configuración de Asterisk: /etc/asterisk/mdgh.conf:

[servicios]
retro_hay=yes
subscripcion_hay=yes
[rest]
rest_red_ip=172.25.126.21
rest_red_msk=255.255.255.255
rest_puerto_escucha=8090
retro_exten_tech=SIP
retro_contexto=Cen_InicioLlamada_GHRetro
retro_to_descolgar=30
retro_A_cartel_fmt=retro: %s

Y /etc/asterisk/Mdintz.conf

[gh]
host0=BDTR
port0=5556
toConx=5
toRx=10

Los campos de los ficheros y su significado son los siguientes:

Campo Descripción
retro_hay Si es YES, empleamos la retrollamada multinodo del GH, si es no, utilizamos la retrollamada de Asterisk
subscripcion_hay Si es YES, empleamos los BLFs del GH, si es no, utilizamos los BLFs de Asterisk
rest_red_ip IP del servidor donde corre el intz-gh
rest_red_msk Máscara de red donde corre el intz-gh
rest_puerto_escucha Puerto de escucha a nivel de VIVAit Call
retro_exten_tech Tecnología empleada en las extensiones
retro_contexto Contexto del GH
retro_to_descolgar timeot retrollamada descolgar
retro_A_cartel_fmt Información aparece en el display si la llamada es una retrollamada


Campo Descripción
host0 Base de datos de tiempo real
port0 Puerto de escucha


El comando para conocer el estado de los diferentes elementos en Asterisk es:

mdgh show Uso: mdgh show [config | exten <exten_num> | enla <peer>]]

Por ejemplo:

mdgh show exten 6140

  • mdgh Datos de la extension 6140:
  • Datos en intz-gh:
  • ESTADO=NOT_INUSE
  • INUSE=0
  • RINGING=0
  • TS=1538978766
  • HACE=362
  • SUBS_NODOS_NUM=1
  • Estado en cache local: NOT_INUSE

mdgh show enla Trunk_MDtel

  • mdgh Datos del enlace Trunk_MDtel:
  • Datos en intz-gh:
  • INUSE=0
  • RINGING=0
  • TS=1538978766
  • HACE=461


El fichero de logs es el: /var/log/intz-gh.log


3.6.17.3 Retrollamadas

El funcionamiento será el siguiente:

  • La retrollamada queda programada de extensión física "A" a extensión física "B" (no queda programada a numeraciones de usuarios); esto no quiere decir que no podamos programar una retrollamada cuando hemos llamado a una numeración de usuario, pero queda programada en la extensión física en la que está ese usuario en ese momento.
  • El número llamado "B" podrá ser derivado de varias causas:
"A" ha llamado a "B"
"A" ha llamado a un usuario ubicado en "B"
"A" ha llamado a un destino desviado a "B"
"A" ha llamado a un destino y por preruta acaba en "B"
...
  • Las causas por las que se podrá programar una retrollamada son:
"B" está ocupada
"B" no contesta
"B" está ocupada y no contesta (ha sonado en línea 2--> )


Solo podremos programar la retrollamada si el sistema devuelve: extensión ocupada o no contesta


Estas dos últimas casuísticas son iguales a efectos de usuario, pero no a efectos internos...

Si una llamada va a buzón, salta a un grupo ACD, a una IVR...entonces NO habrá retrollamada (porque se considera contestada)

  • Para programar una retrollamada se pulsa el código de facilidad (*43#) una vez colgada la misma; el sistema recordará la última llamada durante un período de tiempo configurable; aunque entre una llamada en "A", este podrá programar retrollamada a la última saliente si sigue dentro del período
  • Se podrá abortar una retrollamada ( (*44#), pero esto no borrará la última llamada (podemos arrepentirnos de haber abortado la retrollamada)
  • En el gran hermano se guardará Nodo A + Ext_A (numero y name) + Ext_B (numero y name_usuario) + Causa + Timestamp
  • Solo se puede programar una retrollamada y que sea la última
  • Si la ultima llamada saliente es, por ejemplo exterior --> No hay posibilidad de programar ninguna retrollamada


3.6.17.3.1 Acuerdos de funcionamiento
  • Un origen A solo tendrá programa una retrollamada a un destino B; si teniendo una programada decide programar otra, la primera se pierde.
  • Un destino B puede serlo de múltiples orígenes "n" (configurable); cuando B esté disponible para retrollamada, se lanzará una llamada a uno de los orígenes y cuando vuelva a quedar disponible a otro de ellos.
  • Si se trata de programar una "n+1" retrollamada (desde A5) para un destino B, el sistema le informará de que la retrollamada no ha podido programarse (locución a determinar)


3.6.17.3.2 Cuestiones
  • Se prevé que la retrollamada suene en una extensión desviada; si "A" llama a "B" y esta está desviada en "C", si suena "C" la retrollamada que programo.
  • Si salta al buzón no puede haber retrollamada.

3.6.18 GeneraConf

El GeneraConf es el webservice (war) que se utiliza en la plataforma VIVAit para generar ficheros de configuración a partir de las modificaciones realizadas por el usuario en las tablas de la Base de Datos del sistema à es un intermediario entre los portales y Asterisk.

Es importante tener en cuenta que el proceso convierte tablas de Base de Datos en ficheros de configuración, pero NO genera Dialplan ni sincroniza locuciones.

El GeneraConf se instala en el mismo servidor que el Tomcat, normalmente con el portal de administración.

GeneraConf lee de la tabla Dat_Sincroniza, genera los ficheros de configuración y los coloca en su sitio.

3.6.18.1 Fichero de configuración

GeneraConf es un proceso que no incorpora fichero de configuración. El proceso es llamado por los portales del entorno VIVAit (portal de administración y portal de alertas) siendo los propios portales los que han de incluir los parámetros necesarios.

En el portal de administración de VIVAit Call tenemos que configurar la url para poder sincronizar los cambios realizados utilizando el proceso:


URL de sincronizacion.jpg


GeneraConf incluye el parámetro AlcanceSincroniza que se utiliza para distinguir el portal que deseamos sincronizar. Los portales (administración y alertas) deberán incluir este parámetro cuando llamen al generaConf:

  • Si no se indica o se indica con valor 10 (alcanceSincroniza=10) se sincroniza el entorno VIVAit Call, excluyendo el entorno de alertas.
  • Si se indica con valor 20 (alcanceSincroniza=20), se sincroniza solo el entorno de Alertas.

A tal efecto se ha creado el siguiente enumerado:

public enum TAlcanceSincroniza  {
        ALCANCESSINC_VIVAITCALL("10"),
        ALCANCESSINC_ALERTAS("20"); 
        
        private TAlcanceSincroniza(String text) {
            this.text = text;
        }   
        private final String text;   
        @Override
        public String toString() {
            return text;
        }
    }


Existe un fichero, generaConf.properties, que permite simular la creación de ficheros de configuración con los cambios que hayamos realizado en el portal. Los ficheros de configuración creados en modo simulación se crear en una ruta distinta a la habitual, por lo que no sobrescriben los ficheros de configuración que se están utilizando.

Nuevo fichero /etc/MDtel/generaConf.properties :

root@Homologacion-Corp1:~# cat /etc/MDtel/generaConf.properties

simular=0
simDirMDtel=/tmp/MDtel
simDirAsterisk=/tmp/Asterisk
deshabExten=0
deshabCola=0
deshabBuzones=0
deshabCti=0
deshabRecGwd=1
deshabRecNodo=0
deshabRecProc=1
deshabRecCen=0
deshabMDcal=0
deshabArchAsterisk=0
deshabVoces=0
deshabEnInt=0
deshabEnExt=0
deshabMoh=0
deshabGrupos=0
deshabVdn=0

El valor 1 indica que GeneraConf simula el fichero asociado, cuando el valor es “0” no se genera la simulación.

El proceso GeneraConf permite subir tanto locuciones como MOH desde el portal. Cuando subimos las locuciones a través del portal el GeneraConf se encarga de copiar las locuciones a un directorio temporal, posteriormente las colocará en los directorios definitivos correspondientes.

3.6.18.2 Ficheros de logs

El fichero con los log’s generado se encuentra en /var/log/Tomcat.x/generaConf.log.


3.6.19 Nodo WebRTC

Se adjunta la documentación del nodo WebRTC:


Manual de instalación y operación del nodo WebRTC


La arquitectura de WebRTC en VIVAit Call es la siguiente:



Webrtc.png



Componentes Principales:


Componentes Explicación
APACHE Apache es un servidor web HTTP de código abierto.La funcionalidad principal de este servicio web es servir a los usuarios todos los ficheros necesarios para visualizar la web. Las solicitudes de los usuarios se hacen normalmente mediante un navegador (Chrome, Firefox, Safari, etc.).
SERCEN Sirve para identificar a los usuarios y garantizar que los mismos sean quienes dicen ser.
JANUS Janus es un servidor WebRTC concebido para ser de propósito general. Como tal, no proporciona ninguna funcionalidad más que implementar los medios para configurar una comunicación de medios WebRTC con un navegador, intercambiar mensajes JSON con él y transmitir RTP / RTCP y mensajes entre navegadores y la lógica de la aplicación del lado del servidor a los que están apegados.
IPTABLES Es un programa que se encarga de filtrar los paquetes de red , es decir , es la parte que se encarga de determinar qué paquetes de datos queremos que lleguen hasta el servidor y cuáles no.
FAIL2BAN Es una aplicación de Linux que permite evitar accesos no autorizados al servidor. Funciona bloqueando o baneando las IP que realicen varios intentos de acceso incorrectos al servidor.
CLIENTE El cliente debe de proporcionar una ip pública , un dns para esa ip y un certificado válido.

3.7 Portales web corporativos



El portal de usuario VIVAit Call permite que determinadas funcionalidades del sistema puedan ser accesibles por los usuarios finales desde una interfaz mucho más cómoda y amigable que el telefónico.

Existen varias opciones del portal de usuario según las necesidades del cliente , las diferentes opciones en base a la configuración son:

  • Portal de usuario
  • Portal Webcall
  • Portal para integración con Teams
  • Portal Vivait Tracker
  • Portal Vivait Supervisor



Para configurar las diferentes posibilidades en los portales de usuario hay que modificar el archivo “vivaitConfig.js” , este archivo se encuentra en : /var/www/vivait/webs/portal/Assets/Config/

P-usuario1.png



  • webphoneLink : Configuración del link de la web con solo el dialpad.
  • IsWebPhoneDisabled: Configuración para habilitar (false) o deshabilitar (true) la aparición de webphone al iniciar el portal.



Volver al índice


3.7.1 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
3.7.1.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 pueden existir hasta seis aplicaciones creadas en la plataforma:


Permisos-Portal Administracion.jpg


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


3.7.2 Portal de usuario



Para configurar el portal de usuario solo para terminales telefónicos (sin webphone) se tendría que hacer de la siguiente forma:

P-usuario2.png



  • webphoneLink : Comentar la línea con ( // ) al comienzo de esta.
  • IsWebPhoneDisabled: Deshabilitar (true) para que no aparezca webphone al iniciar el portal.



Al terminar la configuración , en el portal se deshabilitará el botón de webphone:

P-usuario3.png



Volver al índice

3.7.3 Portal Webcall



Para configurar el portal de usuario VIVAit Call web con webphone integrado en la misma página se tendría que hacer de la siguiente forma:

P-usuario4.png



  • webphoneLink : Comentar la línea con ( // ) al comienzo de esta.
  • IsWebPhoneDisabled: Habilitar (false) para que aparezca webphone al iniciar el portal.



Al terminar la configuración , en el portal aparecerá el dialpad de webphone:

P-usuario5.png



Volver al índice

3.7.4 Portal para integración con Teams



Para configurar el portal de usuario VIVAit Call web con botón de enlace a otra página con webphone se tendría que hacer de la siguiente forma:

P-usuario6.png



  • webphoneLink : Poner el link del enlace a webphone
  • IsWebPhoneDisabled: Deshabilitar (true) para que no aparezca webphone al iniciar el portal.



Al terminar la configuración , en el portal estará habilitado el botón de webphone , que al pulsar sobre el nos llevará a otra página con el dialpad :

P-usuario7.png



Volver al índice

3.7.5 Varios portales en una sola instalación



Existe la posibilidad de tener varios portales en una misma instalación de VIVAit Call con diferentes url’s para cada portal .

P-usuario8.png



Un ejemplo de las url’s de los portales sería:

https://servidor/webs/vivait-user/ → Portal usuario
https://servidor/webs/webfon2-solo → DialPad
https://servidor/webs/webfon3 → Portal webphone



Volver al índice

3.7.6 Portal Vivait Tracker



3.7.6.1 Introducción a Vivait Tracker 0.1



Con la versión 5.1 de la plataforma VIVAit Call se ha lanzado un nuevo tracker: VIVAit Tracker, que supone una mejora sobre el producto anterior: Tracker WEB más enfocado al mundo Call Center.
Los puntos claves del nuevo portal VIVAit Tracker dirigido al entorno corporativo son:

• Adaptación para facilitar su uso en entornos de telefonía corporativa.
• Permite seguir llamadas y escuchar/descargar grabaciones en caso de existir.
• Integrado con entornos de texto (TBC y desarrollos futuros).



Volver arriba / Volver al índice

3.7.6.1.1 Arquitectura de Vivait Tracker 0.1



Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:

- Frontend
Reside en un servidor web Apache.
Se invoca desde un navegador mediante una URL del tipo https://host/ws/
       https://172.25.128.252/Tracker_Corp/
Es la parte visual: HTML, CSS, JavaScript.
No accede directamente a la base de datos; solo obtiene datos desde una API.



- Backend / API REST
Corre en un servidor web Tomcat.
Expone la API en:
       https://172.25.128.252/Tracker-Rest/tracker/.
Contiene la lógica que permite interactuar con la BBDD.
Responde en JSON para que el frontend pueda ofrecérselo al navegador.



Diagrama funcional de la arquitectura de VIVAit Tracker 0.1

Arquitectura3 tracker V5.1.png



Volver arriba / Volver al índice

3.7.6.1.2 Flujo completo del ciclo de datos



Siguiendo el proceso se contemplan los siguientes pasos:

Paso 1 El usuario invoca el frontend residente en Apache desde un navegador, usando javascript, mediante la URL del tipo:

       https://host/Traker_Corp/

El navegador carga la página web servida por Apache.

Paso 2 Una vez superada la fase de validación se muestra un formulario que permite al usuario definir los parámetros de una consulta.

La página del formulario inicia una transacción para efectuar una solicitud HTTP POST al endpoint correspondiente, por ejemplo:
               https://172.25.128.252/Tracker_Corporativo/
siendo la carga util de esta solicitud los datos del formulario rellenado por el usuario:
               {fechaInicio: "", fechaFin: "", horaInicio: "", horaFin: "", listaExtensiones: [], listaGrupos: [],…}          



Paso 3 Al recibir los datos del formulario el frontend hace una petición a la API REST de Tomcat.



Paso 4 La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta.



Paso 5 El frontend recibe el JSON con los datos de la consulta en la respuesta:

               POST https://172.25.128.252/Tracker-Rest/tracker/lista
El navegador lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.



Volver arriba / Volver al índice

3.7.6.1.3 Seguridad de Vivait Tracker 0.1



El acceso está controlado mediante validación de tokens.

Paso 1 Autenticación inicial

• Al introducir sus credenciales el usuario se valida a través del servicio de autenticación sercen
               https://172.25.128.252/sercen/postautenticar1
• Sercen genera un token firmado que identifica la sesión del usuario.



Paso 2 Validación interna de permisos

• Una vez que el frontend tiene el token, cada petición pasa por una validación de la API del tomcat:
               https://172.25.128.252/Tracker-Rest/tracker/verificarToken
En la misma se comprueba que:
- El token es válido.
- El usuario tiene permisos para el recurso que está intentando usar.
Es necesario que el usuario tenga acceso a la aplicación Grabador, ver Usuarios.
• No se ejecuta ninguna acción si el token no es validado primero.



Paso 3 Proxy inverso apache-tomcat

• Apache actúa como punto de entrada único:
- El usuario solo ve URLs de apache.
- Las peticiones que requieren lógica del backend se redirigen internamente a tomcat.
- Esto se consigue mediante proxy inverso, por ejemplo:
/Tracker_Corporativo → servido por apache
               https://172.25.128.252/Tracker_Corp/
/Tracker-Rest → Apache las pasa a Tomcat de forma transparente para el usuario
               https://172.25.128.252/Tracker-Rest/tracker/extensiones
• El navegador utilizado por el usuario nunca ve a tomcat.



Volver arriba / Volver al índice

3.7.6.2 Descripción de la interfaz de Vivait Tracker 0.1



Este apartado se trata en Vivait Tracker

Volver arriba / Volver al índice

3.7.7 Portal VIVAit Supervisor



3.7.7.1 Introducción a Vivait Supervisor 2.0



Con la versión 5.1 de la plataforma VIVAit Call se ha lanzado la aplicación: Vivait-Supervisor 2.0.

Los puntos claves del portal Vivait Supervisor son:

• Seguimiento de las llamadas generadas en el sistema VIVAit Call.
• Visualización de resultados mediante gráficos, tablas y otros formatos.
• Exportación de datos para su posterior análisis.





3.7.7.1.1 Definiciones en Vivait Supervisor 2.0



A continuación se definen los principales conceptos empleados en el supervisor:

Dashboard

Panel de control que presenta de forma visual y resumida la información clave (datos, indicadores o métricas),
con el objetivo de facilitar la supervisión, el análisis y la toma de decisiones de manera rápida y eficiente.
Un dashboard está compuesto por uno o varios componentes.



Componente

Elemento individual que forma parte de un dashboard y cuya función es mostrar la información requerida.
Los componentes pueden adoptar distintos formatos, entre los más habituales:
• Tablas:
La información se presenta en formato tabular. Las cabeceras y la estructura de la tabla se definen durante la creación de su lógica.
• Gráficos:
Los datos se muestran de forma visual mediante distintos tipos de gráficos, como barras, líneas, circulares, entre otros.
Según el modo en que actualizan la información, los componentes se clasifican en:
• Dinámicos:
La información se actualiza de forma periódica, de acuerdo con un temporizador asociado al componente.
• Estáticos:
La información se carga al iniciar el dashboard y no se vuelve a actualizar hasta que el panel de control se invoca nuevamente.





3.7.7.1.2 Arquitectura de Vivait Supervisor 2.0



Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:

- Frontend
Reside en un servidor web Apache.
Se invoca desde un navegador mediante una URL del tipo https://host/ws/
       https://172.25.128.92/Vivait-Supervisor/
Es la parte visual: HTML, CSS, JavaScript.
No accede directamente a la base de datos; solo obtiene datos desde una API.



- Backend / API REST
Corre en un servidor web Tomcat.
Expone la API en:
       https://172.25.128.92/Vivait-Supervisor/.
Contiene la lógica que permite interactuar con la BBDD.
Responde en JSON para que el frontend pueda ofrecérselo al navegador.



Diagrama funcional de la arquitectura de Vivait-Supervisor

Arquitectura supervisor2 V5.1.png





3.7.7.1.3 Flujo completo del ciclo de datos



Siguiendo el proceso se contemplan los siguientes pasos:

Paso 1 El usuario invoca el frontend residente en Apache desde un navegador, usando javascript, mediante la URL del tipo:

       https://host/Vivait-Supervisor/

El navegador carga la página web servida por Apache.

Paso 2 Una vez superada la fase de validación se muestra la pantalla inicial que permite al usuario elegir el dashboard, previamente configurado, ejecutándose la monitorización de la consulta preparada.

Tras elegir el dashboard deseado, la página web realiza solicitudes periódicas HTTP POST al endpoint correspondiente,
donde se obtienen los datos de los componentes asociados al dashboard, por ejemplo:
               https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
siendo la carga útil de esta solicitud la identificación del componente con los filtros elegidos por el usuario:
              {idCompoCuadro: "15",…}
                  filtros : [{tipo: "titulo", valor: "titulo=Detalle"}, {tipo: "fechaDesde", valor: "FechaDesde="},…]
               idCompoCuadro: "15"          



Paso 3 Al recibir los datos el frontend hace una petición a la API REST de Tomcat.


Paso 4 La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta.

              INFO TablaDinamicosDaoImpl:607 - componerSQL SELECT DATE_FORMAT(DAT_LLAMADAS.D_HORA_INICIO,'%Y-%m-%d'),DATE ...



Paso 5 El frontend recibe el JSON con los datos de la consulta en la respuesta:

               POST https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
El navegador lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.





3.7.7.1.4 Seguridad de Vivait Supervisor 2.0



El acceso, del usuario a la aplicación, está controlado mediante validación de tokens y acceso a la aplicación correspondiente.
ver Usuarios

La aplicación CALL_CENTER es la que gestiona los perfiles del usuario para Vivait-Supervisor, según la siguiente tabla:

Perfil de Usuario Nivel administración Funciones
Administración Distinto de Ninguno:
- Alto,
- Medio o
- Bajo.
Configuración y utilización de dashboard.
Consulta Ninguno Utilización de dashboard.



El usuario no tiene acceso a Vivait-Supervisor si no tiene asignada la aplicación CALL_CENTER.

El proceso de validación que se sigue dentro del sistema es el siguiente:

Paso 1 Autenticación inicial

• Al introducir sus credenciales el usuario se valida a través del servicio de autenticación sercen
               https://172.25.128.92/sercen/postautenticar1
• Sercen genera un token firmado que identifica la sesión del usuario.



Paso 2 Validación interna de permisos

• Una vez que el frontend tiene el token, cada petición pasa por una validación de la API del tomcat:
En la misma se comprueba que el usuario tiene permisos para el recurso que está intentando utilizar, según la tabla anterior.
  • Si el usuario tiene un perfil de administrador puede configurar (crear, borrar o gestionar) y consultar dashboard.
  • Si el usuario tiene un perfil de consulta solo puede consultar dashboard ya configurados, no puede gestionarlos.



Paso 3 Proxy inverso apache-tomcat

• Apache actúa como punto de entrada único:
- El usuario solo ve URLs de apache.
- Las peticiones que requieren lógica del backend se redirigen internamente a tomcat.
- Esto se consigue mediante proxy inverso, por ejemplo:
/Vivait-Supervisor/ → servido por apache
               https://172.25.128.92/Vivait-Supervisor/
Apache las pasa a Tomcat de forma transparente para el usuario
               https://172.25.128.92/Vivait-Supervisor/tablas/TablaComponenteDinamicoAjax
• El navegador utilizado por el usuario nunca ve al módulo tomcat.





3.7.7.1.5 Descripción de la interfaz de Vivait Supervisor 2.0



Este apartado se trata en Vivait Supervisor



3.8 Monitorización en VIVAit



La plataforma de monitorización utiliza es Zabbix sistema de supervisión del sistema VIVAit. Se trata herramienta de monitorización que se usa para vigilar el estado de sistemas informáticos y redes en tiempo real.






3.8.1 Generalidades de Zabbix



Con Zabbix puedes controlar:

Servidores (CPU, RAM, disco…) Redes (routers, switches, tráfico) Bases de datos Aplicaciones Servicios en la nube

Básicamente: te dice si algo funciona bien o falla.

Qué hace exactamente Monitoriza

Recoge datos continuamente:

uso de CPU memoria espacio en disco latencia de red

Genera alertas

Si algo va mal:

envía emails manda notificaciones lanza acciones automáticas

Muestra gráficos históricos de rendimiento dashboards en tiempo real

Cómo funciona

Tiene varios componentes:

Servidor Zabbix → recoge y analiza datos Agentes Zabbix → instalados en máquinas para enviar info Interfaz web → donde ves todo Ejemplo real

Imagina que tienes un servidor:

CPU al 95% → Zabbix lo detecta Te manda alerta Puedes actuar antes de que se caiga Por qué se usa Detectar problemas antes de que afecten a usuarios Controlar infraestructuras grandes Automatizar supervisión





3.8.2 Zabbix




Zabbix es una solución de código abierto que ofrece características de monitorización avanzada de forma tecnica y para el negocio, para todo tipo de servidores, aplicaciones y equipos que forman parte de una red. La versión que utilizamos en mdtel es Zabbix 2.2.2.

Zabbix monitoriza los recursos de un equipo en forma remota, permite centralizar la información en un servidor que permite visualizar el monitoreo, cuenta con una interfaz de administración vía web y utiliza un mecanismo flexible de la notificación que permita que los usuarios configuren las alarmas basadas email para informar virtualmente cualquier acontecimiento. Esto permite una reacción rápida a los problemas del servidor.

Para acceder al servidor Zabbix abrimos el navegador y ponemos la dirección de red (IP) de la maquina donde se encuentra instalado el servidor de Zabbix seguido de "/Zabbix.

Direccion.IP.Zabbix.Server/zabbix

Zabbix posee documentación tanto en wiki, foros y comunidades.Para ampliar la información se puede visitar: [Sitio oficial de Zabbix]

3.8.2.1 Glosario Zabbix



Se trata de una lista de conceptos básicos de Zabbix, pero para ampliar la información sobre otros términos, visite el [Sitio oficial de Zabbix].

  • host
En Zabbix, un host es una entidad que define el elemento en red que se desea monitorizar/supervisar activamente sus recursos locales y aplicaciones. Este puede ser una impresa, router, switch, sensores de temperatura, un servidor, un ordenador,etc, o también una aplicación. La característica de un host es que debe poseer una dirección de red (IP).
  • host group
En Zabbix, un host group (grupo host) es una agrupación lógica de los host, como una forma de organizar los dispositivos "Host" registrados en Zabbix para su monitorización. Puede contener hosts y templates. Los grupos host se utilizan en la asignación de derechos de acceso a los hosts para diferentes grupos de usuarios.
  • item
En Zabbix, un item (medida) es el parámetro que deseamos obtener del host, básicamente es una medida especifica que el servidor Zabbix recogerá de los agentes de Zabbix instalados en los host.
  • trigger
En Zabbix, un trigger(disparador) es una entidad que define un umbral para detectar la existencia de un problema en un dispositivo. Son valores recolectados por los "items", se usa para "evaluar" los datos recibidos con condiciones definidas. Las condiciones son de tipo aritmético y lógico.
  • event
En Zabbix, un event (evento) es la aparición de un suceso en Zabbix que necesita atención. Por ejemplo, el cambio de estado a raíz de un trigger, el descubrimiento de un nuevo agente (autoregistro),etc.
  • action
En Zabbix, una action(acción) son reglas predefinidas para reaccionar a un evento disparado por los triggers, es decir, define qué hacer ante un evento. Consta de operaciones (por ejemplo, una notificacion, comandos remotos) y condiciones (cuando la operación se lleva a cabo).
  • notification
En Zabbix, una notification (notificacion) es la entidad con que Zabbix nos puede notificar (Correo Electrónico,mensajes vía "SMS" o Jabber).
  • template
En Zabbix, un témplate (plantilla) viene predefinida en la instalación de Zabbix Server, con el fin de ser aplicada en base al tipo de sistema operativo(Linux, Mac, Window, etc) o en elementos que comparten los mismos parámetros de medición, por ejemplo la carga del procesador, uso de memoria y uso de recursos de red. Las plantillas son un conjunto de módulos "ITEM, TRIGGERS y GRÁFICAS", que están preconfigurados y listas para ser aplicadas a uno o varios hosts.
  • application
En Zabbix, una application (aplicación) es una agrupación lógica de los items.
  • Zabbix server
El Zabbix server (servidor de Zabbix) es el proceso central donde están definidas las configuraciones y donde se almacenan todos los datos y estadísticas recogidas de los agentes Zabbix.Consta de una base de datos, una interfaz web y el propio server. Como servidor, se encarga de recoger los datos de los agentes, calcular los triggers, enviar notificaciones, etc.
  • Zabbix agent
El zabbix agent (agente de Zabbix) es un proceso desplegado en los host que son supervisados, que funciona como un servicio y puede funcionar de forma activa y pasiva simultáneamente.
3.8.2.2 Discovery



La funcionalidad discovery(detección) lista los dispositivos que se integran en nuestra red y el tipo de servicios que proporciona. Por ejemplo, si la empresa tuviera cien colas ACDs, y veinticinco VDNS, y en cada cola como veinte medidas, seria muy laborioso registrar una por uno cada uno. Gracias a esta funcionalidad, se descubre todas las interfaces de red que se tiene, automáticamente y tanto para colas nodos o IVR. Para utilizar esta funcionalidad , se hace el uso de dos script, que se instalan en el momento de instalación de Zabbix en el directorio "/usr/local/sbin", que son:

zabbixDiscoveryQueues.pl : script utilizado para buscar colas ACD.

zabbixDiscoveryVDN.pl : script utilizado para buscar VDNS.

La explicación de como configurarla se encuentra en el manual oficial [| Zabbix detección de redes].

3.8.2.3 Notificaciones

Necesariamente, debe darse de alta al usuario y darse de alta el servidor de correo electrónico para poder ser capaz de enviar correos.

Por otro lado, el formato del correo electrónico y las condiciones de envío de correo al usuario se configura en las acciones. Véase el [| manual oficial de Zabbix 2.2]

3.8.2.4 Usuarios




Zabbix permite la organización de usuarios en grupos para establecer los permisos adecuados de acuerdo al tipo de perfil que deseemos crear. Necesariamente un usuario debe permanecer a un grupo o varios grupos.Todos los usuarios acceden a la aplicación de Zabbix a través de la interfaz Web.

Cada usuario Zabbix se le asigna un nombre de usuario único , una contraseña y podemos indicarle que tipo de comunicación que posee, normalmente es vía email, pero puede ser vía a otro tipo de medios. Para mas información ver el [|| manual oficial ].

3.8.2.5 Visualización



Con Zabbix es posible visualizar los datos como gráficos, pantallas, mapas y hasta presentaciones cambiantes, entre otros. En este apartado solo nombraremos características esenciales que se tendra que completar con el [| manual oficial]

3.8.2.5.1 Graphs



Nota: Debe crearse algun item dentro del host para poder utilizar una gráfica.

En Zabbix una gráfica sirve para representar gráficamente los resultados obtenidos de uno item o varios items.

EjemploGrafica.png

Los valores min / avg / max que Zabbix obtiene y representa son de un registro de datos de la tabla tendencias.

3.8.2.5.2 Screens




La pantalla refiere a otra característica adaptable de ZABBIX cuál permite que los usuarios creen las pantallas personalizadas dentro de ZABBIX para exhibir la información. Se considera como una colección de gráficas y no depende del host. Una pantalla puede consistir en gráficos simples, gráficos personalizados, integrar mapas, Alertas, gráficos estadísticos o texto llano tal como los 5 valores pasados de un item particular entre otros; y mostrar la información de forma dinámica.

EjemploScreen.png
3.8.2.5.3 Maps



En Zabbix, un map (mapa) es una representación gráfica de la situacion de nuestros dispositivos en red. Es un escenario que muestra nuestra red, aplicaciones y servicios a través de figuras o iconos. Dichas figuras toman vida en respuesta a los eventos que se dan en nuestro entorno.

EjemploMaps.png
EstadosMaps.png


3.8.2.5.4 Monitorizar el estado de los raid




Los siguientes comandos son necesarios para poder monitorizar el estado de los raid. La orden:

>hpacucli "ctrl slot=1 logicaldrive 1 show status"

nos proporciona el estado de un raid (p.e. logicaldrive 1 (931.5 GB, 1): Interim Recovery Mode).

La orden:

>hpacucli "ctrl slot=1 logicaldrive all show status"

nos proporciona el estado de todos los raid.

p.e.: logicaldrive 1 (931.5 GB, 1): Interim Recovery Mode

logicaldrive 2 (1.8 TB, 1): OK.

Para conseguir información genérica el comando

ctrl all show config detail

nos muestra mucha información y podemos saber el modelo de disco físico que lleva instalado para poder comprar el modelo antes de "operar".






3.8.3 Zabbix en MDtel




3.8.3.1 Configuraciones de Zabbix



3.8.3.1.1 Agentes Zabbix
Nota: Hay que instalar un agente Zabbix en cada maquina que se quiera monitorizar.

El agente de Zabbix puede recoger datos:

  • De forma pasiva: el server contacta al agente pidiéndole un dato (por ejemplo el consumo de CPU en ese instante) y el agente responde al server con ese dato. A esta acción del agente le llamaremos Agente activo.
  • De forma activa: en un primer momento, el server le enviará al agente el listado de items a monitorizar. A partir de ese momento, será el agente que de forma periódica recogerá datos sobre esos ítems y se los hará llegar al server. A esta acción del agente le llamaremos 'Agente pasivo'.


3.8.3.1.2 Configurar agente de forma pasiva



Para configurar el agente de Zabbix necesitamos acceder a la maquina que actuará como agente, y en el directorio /etc/zabbix modificar el fichero zabbix_agentd.conf e indicar cual es la dirección de red (IP) del servidor Zabbix.

##### Passive checks related
### Option: Server
#       List of comma delimited IP addresses (or hostnames) of Zabbix servers.
#       Incoming connections will be accepted only from the hosts listed here.
#       If IPv6 support is enabled then '127.0.0.1', '::127.0.0.1', '::ffff:127.0.0.1'  
#       are treated equall$
#
# Mandatory: no
# Default:
Server= IP.Server Zabbix.

Tras la configuración del fichero, debemos reiniciar el servicio de los agentes.

sudo service zabbix-agent restart
3.8.3.1.3 Configurar agente de forma activa



Para configurar el agente de Zabbix necesitamos acceder a la máquina que actuará como agente, y en el directorio /etc/zabbix modificar el fichero zabbix_agentd.conf e indicar cual es la dirección de red (IP) del servidor Zabbix.

##### Active checks related
### Option: ServerActive
#       List of comma delimited IP:port (or hostname:port) pairs of Zabbix serv$
#       If port is not specified, default port is used.
#       IPv6 addresses must be enclosed in square brackets if port for that hos$
#       If port is not specified, square brackets for IPv6 addresses are option$
#       If this parameter is not specified, active checks are disabled.
#       Example: ServerActive=127.0.0.1:20051,zabbix.domain,[::1]:30051,::1,[12$
#
# Mandatory: no
# Default:
ServerActive=127.0.0.1
--------------------------sección separada----------------------------
### Option: UserParameter
#       User-defined parameter to monitor. There can be several user-defined pa$
#       Format: UserParameter=<key>,<shell command>
#       See 'zabbix_agentd' directory for examples.
#
# Mandatory: no
# Default:
# UserParameter=
User_parameters:asterisk.pid, /usr/bin/asterisk -rx 'core show chanels'|grep 'active calls'| cat -d -f 1

El parámetro User_parameters tiene un formato de este estilo:

User_parameters: NombreMedida, comando.

El nombre de la medida se refiere al nombre que demos a la aplicación , no hace falta que exista una aplicación con ese nombre en Zabbix, y el comando , es el comando remoto que tiene que ejecutar el servidor Zabbix. Posiblemente necesita darse permisos para ejecutar el comando y siempre debe devolver un valor (un numero o un tiempo) que el servidor Zabbix puede manejar. Tras la configuración del fichero, debemos reiniciar el servicio de los agentes.

sudo service zabbix-agent restart





3.8.3.2 Scripts del Servidor Zabbix



Nota: No olvidar que en la misma maquina del server Zabbix, debe configurarse como agente de Zabbix.

Después de realizar la Instalación de Zabbix correctamente. Se han creado otros ficheros scripts (scripts propios de mdtel) que facilitarán la petición del servidor a los agentes activos, para poder parametrizar todos los elementos del negocio que suelen monitorizarse. Dependiendo de lo que vaya a monitorizarse necesitaremos algún script o todos. Algunos nos informan sobre elementos de negocio, saber si asterisk funciona , monitorizar el CTI (lanzara nc localhost 1111) , controlar el Intz-Nimitz, comprobar si funciona motalsal, ect.

Cada script se exportara a los host, para que pueda facilitar los datos que pide el servidor Zabbix y configurarse. Por ejemplo,para monitorizar las llamadas en curso del ACD, agentes conectados, agentes desconectados, etc. Todos los scripts se deben colocar en el directorio /usr/local/sbin con permisos 755, su nombre es parecido a "zabbixSenderXXXXX.pl"

ls /usr/local/sbin/ |grep zabbixSender
zabbixSenderACDBD.pl
zabbixSenderACD.pl
zabbixSenderCTI.pl
zabbixSender-intz-nimitz.pl
zabbixSenderMotorSal.pl
zabbixSenderMyACDSuperv.pl
zabbixSenderRecordNodo.pl
zabbixSenderRecordCentral.pl

Se crea una tarea programada en linux para poder ejecutarse los scripts, programando el tiempo en que debe ejecutarse.

Si visualizo que "............" aparece:

          • root zabbix
3.8.3.2.1 zabbixSenderACDBD.pl



Uso: Obtiene diversos valores por cada cola, estados de agente por cola y estados de agente generales.

Ubicación: Servidor BDTR.

Parámetros: Ruta al archivo de configuración (Por ejemplo: /etc/MDtel/zabbixSenderACDBD.pconf)

Archivo de configuración: zabbixSenderACDBD.pconf

$db: Nombre de la BBDD (normalmente nimitz)
$dbHost: Dirección IP del servidor de BBDD de TR (normalmente BDTR)
$dbPort: Puerto MySQL (normalmente 3306)
$dbUsuario: Usuario MySQL (normalmente nimitz)
$dbClave: Clave del usuario
$sZab: Dirección IP del servidor Zabbix
$hZab: Nombre del host Zabbix (normalmente el nombre de máquina, tal y como se configura en 
zabbix_agentd.conf o en el host en la web de Zabbix)
3.8.3.2.2 zabbixSenderACD.pl



Uso: Obtener el PID de Asterisk para revisar si se ha reiniciado en caso de que cambie.

Ubicación: Servidor ACD.

Parámetros: Ruta al archivo de configuración (Por ejemplo: /etc/MDtel/zabbixSenderACD.pconf).

Archivo de configuración: zabbixSenderACDBD.pconf.

$db: Nombre de la BBDD (normalmente nimitz)
$dbHost: Dirección IP del servidor de BBDD de TR (normalmente BDTR)
$dbPort: Puerto MySQL (normalmente 3306)
$dbUsuario: Usuario MySQL (normalmente nimitz)
$dbClave: Clave del usuario
$sZab: Dirección IP del servidor Zabbix
$hZab: Nombre del host Zabbix (normalmente el nombre de máquina, tal y como se configura en
zabbix_agentd.conf o en el host en la web de Zabbix)
3.8.3.2.3 zabbixSenderCTI.pl



Uso: Obtener estado y los distintos valores de vivait-cti.

Ubicación: Servidor donde se ejecute vivait-cti. Normalmente el servidor ACD.

Parámetros:

--sZab: Ip del servidor Zabbix. Si se omite, se asume localhost.
--hZab: Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.
3.8.3.2.4 zabbixSender-intz-nimitz.pl



Uso: Obtener estado y los distintos valores de intz-nimitz.

Ubicación: Servidor donde se ejecute intz-nimitz.

Parámetros:

--sZab: Ip del servidor Zabbix. Si se omite, se asume localhost.
--hZab: Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.
3.8.3.2.5 zabbixSenderMotorSal.pl



Uso: Obtener estado y los distintos valores de motorSal.

Ubicación: Servidor donde se ejecute motorSal.

Parámetros:

--sZab: Ip del servidor Zabbix. Si se omite, se asume localhost.
--hZab: Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.
3.8.3.2.6 zabbixSenderMyACDSuperv.pl



Uso: Obtener estado y los distintos valores de myAcdSuperv.

Ubicación: Servidor donde se ejecute myAcdSuperv.

Parámetros:

--sZab: Ip del servidor Zabbix. Si se omite, se asume localhost.
--hZab: Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.
3.8.3.2.7 zabbixSenderRecordNodo.pl



Uso: Obtener estado y los distintos valores de recordNodo.

Ubicación: Servidor donde se ejecute recordNodo.

Parámetros:

--sZab: Ip del servidor Zabbix. Si se omite, se asume localhost.
--hZab: Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.
3.8.3.2.8 zabbixSenderRecordCentral.pl



Uso: Obtener estado y los distintos valores de recordCentral.

Ubicación: Servidor donde se ejecute recordCentral.

Parámetros:

--sZab: Ip del servidor Zabbix. Si se omite, se asume localhost.
--hZab: Nombre del host Zabbix. Si se omite, se asume el nombre de máquina local.


A continuación se muestra una tabla resumen de los distintos scripts y sus funcionalidades:

Zabbix scripts.png

3.8.3.2.9 Dimensionamiento del servidor (Startpollers)



Nota: EL parámetro StartPollers es un parámetro numérico que forma parte del fichero de configuración 
del servidor Zabbix(zabbix_server.conf). Por defecto el servidor Zabbix está configurado para
iniciar con cinco startpollers.

El servidor Zabbix puede hacer peticiones a los agentes de las medidas que necesita o quiere. O en caso contrario los agentes envian en un tiempo determinado la información al servidor. Para recibir todas estas peticiones necesitamos los pollers.

Los poller son los procesos encargados de recibir todas las peticiones de medidas. Aumentaremos su cantidad dependiendo de la necesitad que tengamos. Para ello podemos observar la queue , que es la encargada de almacenar un listado de todas las cosas que están pedidas para medirse y recibirse. SI por ejemplo esta cola (queue) muestra mas de mil medidas seguramente estos pollers sean un cuello de botella y habrá que aumentar su numero.

3.8.3.2.10 Templates



Zabbix cuenta con templates (plantillas) que facilitan la tarea de "Registrar Equipos y Dispositivos" y agregarles métricas; acelerar el despliegue de las tareas de supervisión en un host; aplicar cambios masivos a tareas de supervisión. En mdtel hemos creado plantillas propias que facilitan estos procesos, los cuales necesitaremos importar templates.

Las plantillas están vinculados directamente a los hosts individuales, por tanto se necesitaran utilizar en cada host.

Automáticamente, cada template rellena por item las aplicaciones, trigers, alarmas,gráficos,... etc.

A continuación, se muestran los distintos bloques de funciones de la instalación en función de cada template:

Templates Se instalan en general
DRBD SI (si clúster)
motorSal -
Vivait-Suite ACD -
Vivait-Suite BBDD -
Vivait-Suite Record -
Vivait-Suite GW -
Vivait-Call Asterisk -
Vivait-Call bdCentral -
Vivait-Call bdNodo si
cambiarPerfil_Cal -
Template App Zabbix Server -
Template_OS_Linux* si(si no posee ip virtuales de clúster)
Template_App_MySQL si


Dependiendo del tipo de nodo:
Templates ACD Corporativo/GW
DRBD - -
motorSal - -
Vivait-Suite ACD Si -
Vivait-Suite BBDD - -
Vivait-Suite Record - -
Vivait-Suite GW - Si
Vivait-Call Asterisk - Si
Vivait-Call bdCentral - -
Vivait-Call bdNodo - -
cambiarPerfil_Cal - -
Template App Zabbix Server - -
Template_OS_Linux* - -
Template_App_MySQL - -


Dependiendo del tipo de Base de datos:
Templates BBDD
Tiempo Real
BBDD
Réplica
BBDD Copia
DRBD - - -
motorSal Si(si ACD) - -
Vivait-Suite ACD - - -
Vivait-Suite BBDD si si si
Vivait-Suite Record - - -
Vivait-Suite GW - - -
Vivait-Call Asterisk - - -
Vivait-Call bdCentral si - -
Vivait-Call bdNodo - - -
cambiarPerfil_Cal - - -
Template App Zabbix Server - - -
Template_OS_Linux* - - -
Template_App_MySQL - - -


Templates Administración
DRBD -
motorSal -
Vivait-Suite ACD -
Vivait-Suite BBDD -
Vivait-Suite Record -
Vivait-Suite GW -
Vivait-Call Asterisk -
Vivait-Call bdCentral -
Vivait-Call bdNodo -
cambiarPerfil_Cal SI (si posee servidor calendarios)
Template App Zabbix Server -
Template_OS_Linux* -
Template_App_MySQL -


Templates Servidor de grabaciones
DRBD -
motorSal -
Vivait-Suite ACD -
Vivait-Suite BBDD -
Vivait-Suite Record Si
Vivait-Suite GW -
Vivait-Call Asterisk -
Vivait-Call bdCentral -
Vivait-Call bdNodo -
cambiarPerfil_Cal -
Template App Zabbix Server -
Template_OS_Linux* -
Template_App_MySQL -


Monitorización
Templates General Contact Center
DRBD - -
motorSal - -
Vivait-Suite ACD - -
Vivait-Suite BBDD - -
Vivait-Suite Record - -
Vivait-Suite GW - -
Vivait-Call Asterisk - -
Vivait-Call bdCentral - -
Vivait-Call bdNodo - -
cambiarPerfil_Cal - -
Template App Zabbix Server si -
Template_OS_Linux* - -
Template_App_MySQL - -


3.8.3.2.11 Resumen



Plantillas MDTEL Trigger Descripción Severidad Actuación a llevar a cabo
Template DRBD DRBD balanceado en {HOST.NAME} El DRBD ha balanceado en Host Desastre Revisar ambos nodos del cluster.

Comprobar que el DRBD está sincronizado (cat /proc/drbd).

Template DRBD DRBD desconectado en {HOST.NAME} El DRBD esta desconectado en Host Desastre Revisar Host. Comprobar estado del DRBD (cat /proc/drbd)
Template DRBD DRBD no actualizado en {HOST.NAME} Estado de disco invalido en DRBD (cat /proc/drbd no devuelve UpToDate) Desastre Forzar sincronización del DRBD
Template motorSal motorSal caido El motorSal esta caido Desastre Reiniciar motorSal.

Revisar log (var/log/motorsal.log) para averiguar la causa

Template Vivait-Call Asterisk Asterisk reiniciado El Asterisk se ha reiniciado Alta Comprobar que ha arrancado correctamente.

Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.

Template Vivait-Call Asterisk Error en enrutamiento Error en enrutamiento Baja Revisar full de asterisk para comprobar donde está el error.

Corregir (añadir prerutas o lo que sea necesario).

Template Vivait-Call Asterisk No hay extensiones registradas No hay extensiones registradas Alta Revisar full de asterisk para comprobar donde está el error.

Revisar sip_WEB.conf

Template Vivait-Call Asterisk No hay trunks activos No hay trunks activos Baja Revisar full de asterisk para comprobar donde está el error.

Revisar enlaces en portal.

Template Vivait-Call bdCentral Error en bdCentral Se ha dado un error en el bdCentrlal Alta Revisar BBDD central.
Template Vivait-Call cambiarPerfil_Cal cambiarPerfil_Cal no ejecutado No se ha ejecutado cambiarPerfil Alta Revisar log (/var/log/cambiarPerfil_Cal.log).

Actuar en consecuencia

Template Vivait-Call cambiarPerfil_Cal Error en cambiarPerfil_Cal Ha dado un error al cambiar el perfil Alta Revisar log (/var/log/cambiarPerfil_Cal.log).

Actuar en consecuencia

Template Vivait-Suite ACD PID Asterisk cambiado El PID de Asterisk ha cambiado Desastre Comprobar que ha arrancado correctamente.

Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura

Template Vivait-Suite ACD VivaitCTI caido El CTI está caido Alta Reiniciar vivait-cti. Comprobar en log (/var/log/vivait-cti.log) la causa
Template Vivait-Suite ACD Vivait-CTI desconectado de Asterisk El CTI está desconetado de Asterisk Desastre Comprobar que ha arrancado correctamente.

Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.

Template Vivait-Suite BBDD MyACDSuperV caido MyACDSuperV esta caido Alta Iniciar myAcdSuperv. Comprobar en log /var/log/myAcdSuperv.log) la causa.
Template Vivait-Suite GW {HOSTNAME} Asterisk caido El asterisk en esa maquina se encuentra caido Alta Comprobar que ha arrancado correctamente.

Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.

Template Vivait-Suite GW {HOSTNAME} Asterisk PID cambiado El PID de Asterisk ha cambiado Alta Comprobar que ha arrancado correctamente.

Salvar core (/tmp/core.XXX) y full (/var/log/asterisk/full) a ubicación segura.

Template Vivait-Suite GW {HOSTNAME} error en numero de enlaces Existe un error en el numero de enlaces Baja Revisar full de asterisk para comprobar donde está el error.

Revisar sip_WEB.conf

Template Vivait-Suite GW {HOSTNAME} error en numero procesos asterisk Existe un error en el numero de procesos de asterisk Alta grep aster” cuantos asterisk aparecen.

Solo tiene que aparecer un safe_asterisk y un asterisk.

Template Vivait-Suite GW Alarma en recordnodo Alarma en recordnodo Media Revisar log (/var/log/record/recordNodo.log).

Actuar en consecuencia.

Template Vivait-Suite GW Espacio libre en /var/spool/asterisk/monitor menor del 15% Espacio libre en /var/spool/asterisk/monitor menor del 15% Desastre Revisar log (/var/log/record/recordNodo.log).

Actuar en consecuencia.

Template Vivait-Suite GW Espacio libre en /var/spool/asterisk/monitor menor del 40% Espacio libre en /var/spool/asterisk/monitor menor del 40% Desastre Revisar log (/var/log/record/recordNodo.log).

Actuar en consecuencia.

Template Vivait-Suite GW Porcentaje de nodos libres en /var/spool/asterisk/monitor menor al 25% Porcentaje de nodos libres en /var/spool/asterisk/monitor menor al 25% N/A Revisar log (/var/log/record/recordNodo.log).

Actuar en consecuencia.

Template Vivait-Suite GW Sin datos de grabaciones movidas Sin datos de grabaciones movidas Alta Revisar log (/var/log/record/recordNodo.log).

Actuar en consecuencia

Template Vivait-Suite GW Sin espacio en dispositivo Sin espacio en dispositivo N/A Revisar log (/var/log/record/recordNodo.log).

Liberar espacio moviendo grabaciones

Template Vivait-Suite Record recordCentral Gateways en cuarentena Baja Revisar log (/var/log/record/recordCentral.log).

Revisar GW afectado (conexión SSH, procesos corriendo, etc.).

Template Vivait-Suite Record recordCentral NAS llamadas desconectado Media Revisar estado NAS (normalmente NFS montada en /var/lib/recordProcesad/segmRecord)
Template Vivait-Suite Record recordCentral NAS segmentos desconectado Media Revisar estado NAS (normalmente NFS montada en /var/lib/recordProcesad/segmRecord)
Template Vivait-Suite Record recordCentral retrasado en exceso Media Comprobar con “nc localhost 1114” desde el propio host de cuanto es el retraso.

Monitorizar que se reduce con el paso del tiempo.


* El template OS Linux tiene asociado el Template App Zabbix Agent.
Una base de datos unificada es una base de datos de tiempo real junto a  una base de datos de replica
3.8.3.2.12 Importar templates



Las plantillas propias de mdtel se encuentran en la ruta "/usr/src/nimitz/archivos" y empiezan con el nombre de "TemplateXXX.xml".

ls /usr/src/nimitz/archivos | grep Template
Template DRBD.xml
Template motorSal.xml
Templates Vivait-Suite_GW.xml
Templates Vivait-Suite.xml
Template Vivait-Call Asterisk.xml
Template Vivait-Call bdCentral.xml
Template Vivait-Call bdNodo.xml
Template Vivait-Call cambiarPerfil_Cal.xml


La importación se realizara una vez a través de la web, no hace falta desde el servidor Zabbix, puede ser en cualquier computadora con acceso a la interfaz web de Zabbix.

ImportarTemplates.png

Hay opciones varias opciones a elegir para importación de templates, pero podemos dejar por defecto las señaladas y pulsar el botón "import".





3.8.4 Configuración para un primer funcionamiento de Zabbix



Se describe una básica configuracion de Zabbix para cualquier equipo que utilice Windows o linux. Pues mediante la definición de hosts, items, triggers y acciones, Zabbix permite efectuar un monitoreo efectivo de plataformas IT heterogéneas.

3.8.4.1 Configuración de los equipost (host) para la monitorización



Nota: Tenga en cuenta que debe de estar previamente configurado el agente Zabbix del 
dispositivo a ser monitorizado apuntando a la IP del "Servidor Zabbix".

Existen dos tipos de host:

  • Host físico: donde la dirección de red que registramos en Zabbix, corresponde al dispositivo que deseamos monitorizar.
  • Host virtual: es una dirección IP virtual, que puede relacionarse con un servidor Web, clusters, etc.


CreacionHost.png

Las opciones basicas para configurar un host son las siguientes:

Campos Explicación Valores posibles
Host Name Definir un nombre para el host. Se puede utilizar números, letras, espacios y guiones bajos están permitidos.
Visible Name Identificar con un nombre, la maquina a la que se refiere el host. Si no tiene valor, se mostrara como nombre "Host Name".
Groups Seleccionar al grupo de host que pertence.Seleccione uno o varios grupos de la caja derecha. Los valores que puede seleccionar por defecto:

Discoverd hosts.

Switches.

Templates.

Templates MDtel.

Zabbix servers.

Linux Servers.

Hypervisors.

Virtual machines.

O crear uno nuevo en New group.

Agent interfaces Se recomienda usar una dirección IP, en vez de un nombre de la maquina para resolver por un servidor de DNS que puede fallar. 10050 por defecto

Cuando termine, haga clic en nel boton "Save". Su nuevo "Host" debe ser visible en la lista de "Host registrados".Despues el zabbix, intentara configurarse el zabbix para conectarse a la IP.... cada x tiempo hace un barrido.


3.8.4.1.1 Comprobación de disponibilidad del host



Para saber si todo esta bien debemos ver la Z de disponibilidad.


EstadosZHost.png


Indicación de los colores del icono Z:

  • Si el icono Z en la columna de disponibilidad es de color rojo, indica que hay un error en la comunicación - mueva el cursor del ratón sobre él para ver el mensaje de error.
  • Si el icono es gris, significa que esta en proceso de comunicación con el "Agente Zabbix". Compruebe que el servidor Zabbix está en marcha, y pruebe a actualizar la página más tarde. El tiempo estimado para revisar si existe problemas es de 5 minutos.
  • Si el icono es verde, esta funcionando correctamente.





3.8.5 Indicar que plantilla (template) tendrá el host



Esta configuración es opcional.
Tras importar templates nos dirigimos al host ya configurado, y en su pestaña de templates pulsamos "add" y añadimos la plantilla/s adecuadas.

3.8.5.1 Asignar items al host



Nota:Un host puede tener un ITEM sin necesitad de tener template.

Todos lo ITEMS se agrupan por HOST, esto significa que cada HOST tiene sus propios "Módulos que recogen datos del Host". Para agregar un nuevo módulo vamos a "Configuration → Hosts" y localizamos el "Host" al cual queremos agregarle un nuevo "Item".

CrearItemEjemplo.png

Parametros o campos a rellenar para una configuración básica :

Campos Explicación Valores posibles
Name Definir un nombre para el item. Este nombre va a ser nuestro identificador para todas la gestiones en donde lo involucremos como el caso de Triggers.
Type Indicar de que entidad queremos recibir informacion. Puede ser al "Agente Zabbix" o a el Hardware como impresoras, switch o routers.
Key los "Items" utilizan "Key" que son parámetros de Zabbix. Los "Key" nos permiten indicar específicamente que tipo de información vamos a solicitara a la entidad. Se puede considerar también como el nombre de alguna aplicación.
host interface Es la direccion de red del servidor zabbix (puede ser uno o mas)
Units Es la dirección de red del servidor zabbix (puede ser uno o mas)
Type of information Tipo de unidades con el que mostrar Zabbix el valor segundos, minutos, euros,....

Cuando termine, haga clic en Guardar. El nuevo elemento debe aparecer en la ITEMLIST. Para mas informacion [ver documentación Zabbix]


3.8.5.1.1 Ver la información recolectada por el item




Nota: Normalmente para ver la información lo encontraremos en "Monitoring → Latest data",luego 
clic en el signo "+" en "other" siempre que no pertenezca a una aplicación. 
En caso contrario, estará bajo el nombre de la aplicación.

Después de definir el "Item" vamos a revisar la información que esta recolectando. . La información comenzará a ser recolectada según el tiempo que le indicamos en el "Item".

VerInfoITEM.png

La espera para recibir la información varía dependiendo del tiempo de recolección del item, la mayoría suele ser aproximadamente al minuto de generar el "Item". Zabbix le ofrece la opción de visualizar la información en forma gráfica (sencilla). En el "Item" en lista haga clic en la columna "History - Graph".

VIsualGraficaValorItem.png

Si en un caso usted no observa información le recomendamos:

  • Ingrese al "Item" y revise que la información del "Key" este igual al ejemplo "system.cpu.load"
  • Verifique que el agente este funcionando en el "Servidor a ser monitoreado" y que "El Servidor recolector Zabbix" este funcionando.
  • El icono "Z" en el host debe estar en color verde.
  • Asegure que esta monitoreando el servidor que le agregó este "Item"
3.8.5.2 Configurar los Triggers para los host



A partir de la información que captura los agentes , el servidor de Zabbix comienza a efectuar la recolección de estos items en la base de datos. Con esto se tiene un registro histórico de tales mediciones, que pueden ser tan simples como un simple ping hasta datos de uso de disco, memoria, cpu, etc. A partir de los datos que se reciben de los agentes lo que sigue es definir y configurar Triggers, que son evaluaciones que hace Zabix de estos datos para determinar la existencia de un Problema en un dispositivo.

Nota: Un trigger necesita una accion, que indica que hacer cuando se activa el trigger.


Un trigger(disparador) es un tipo de reacción ante unas medidas, como un disparador en el que si pasa algo se activa. Los Trigger en Zabbix son módulos que creamos a uno o múltiples "Items" para evaluar o comparar los valores recolectados por los "Items" con condiciones que nosotros definamos. Las condiciones son de tipo aritmético y lógico.

Para configurar un "Trigger o Disparador" seleccionamos "Configuration → Hosts" localizamos el "Host" de ejemplo que creamos y luego hacemos clic en "Trigger", después haga clic en "Create Trigger".

Parametros o campos a rellenar para una configuración básica :

Campos Explicación Valores posibles
Name Definir un nombre para el trigger. Este nombre va a ser nuestro identificador para todas la gestiones en donde lo involucremos como el caso de los eventos.
Expression Hay que indicar para que medida se crea (item) y sus funciones con los parametros adecuados. Recomendación usar expression constructor que pedirá siempre al crearlo, para que item es y sus funciones... Ejemplo: {New host:system.cpu.load.avg(180)}>2
Key los "Items" utilizan "Key" que son parámetros de Zabbix. Los "Key" nos permiten indicar específicamente que tipo de información vamos a solicitara a la entidad. Se puede considerar tambien como el nombre de alguna aplicacion.
Descripción Una descripción breve sobre el trigger.
Severity everidad distinguida por colores, No classified
Information
Warning
Average
High
Disaster


3.8.5.2.1 Comprobar el estado del trigger



Podemos ver el estado del "Trigger" en "Monitoring → Triggers".El color en caso de que se active depende de la severidad definida. Por ejemplo, si el "Trigger" esta en color verde indica que el resultado de la métrica se mantiene por debajo de la condición que indicamos. Por el contrario si el resultado esta "sobre lo indicado" su color sera rojo.

EstadoTrigger.png
3.8.5.3 Asociar un Action al trigger



Una action(acción) sirve para configurar un mensaje de alerta o una accion para Zabbix, ante un problema. Hay varias formas de gestionar un problema a través de una acción:

  1. A través de mensajes simples, alertando al instante.
  2. Escalar los mensajes hacia el jefe y/o otros grupos.
  3. Ejecución de commandos remotos.
  4. Notificaciones repetidas hasta que se resuelve el problema.
  5. Notificaciones y comandos retardados.
  6. Escenario complejo, la combinación de todo lo anterior.

Para crear una configuración en "Configuration-Actions". La explicación esta en la [[ https://www.zabbix.com/documentation/2.0/manual/config/notifications/action documentación de Zabbix]]. -->





4 Funcionalidades específicas en VIVAit



En este apartado se tratará de las funcionalidades especificas de que dispone el sistema VIVAit.
Este apartado contiene las siguientes funcionalidades:

Mecanismo de prioridad adaptativa, asignación de llamadas en colas modulada por tiempo de espera.





4.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

4.1.1 Introducción

Este documento presenta una propuesta de mecanismo de asignación de llamadas en colas a agentes basado no solo en las prioridades de agente a cola, sino en un factor de corrección de prioridad derivado del tiempo de espera de una llamada

4.1.2 Terminología

  • Prioridad de llamada: A cada llamada susceptible de ser atendida en el Call Center se le asignará una prioridad de llamada; dicha prioridad será asignada cada vez que un agente quede disponible.
  • Prioridad de grupo ACD: Los agentes del Call Center tendrán configurada una prioridad para cada grupo ACD al que pertenecen
  • Tiempo de espera: Tiempo que una llamada lleva en espera en un determinado grupo ACD; si la llamada cambia de un grupo ACD a otro el tiempo de espera pasa a cero
  • Objetivo de servicio: Tiempo objetivo máximo de espera por cada grupo ACD
Nota.- En terminología Asterisk el aumento de prioridad corresponde con números descendentes, es decir,
prioridad 50 es mejor que prioridad 70

4.1.3 Mecanismo de asignación de llamadas

En el momento en que exista un agente disponible para recibir llamada, el agente recepcionará la llamada con mejor prioridad de llamada (menor número). La prioridad de llamada para cada llamada se establecerá de la siguiente manera:

- Agentes con prioridad de grupo ACD de 1 a 99 utilizarán el mecanismo convencional de asterisk de prioridad absoluta; será útil para grupos ACD críticos o en Call Centers muy convencionales

Si un agente tiene prioridad menor de 100 en grupos ACD y hay llamadas en dichos grupos, estas llamadas serán atendidas por el agente con prioridad absoluta.

- Agentes con prioridad de colas de 100 en adelante; se utilizará el siguiente mecanismo de prioridad ponderada:

  • Si el grupo ACD de la llamada está dentro del objetivo de servicio, la prioridad de llamada será la prioridad de grupo ACD (a efectos prácticos se aplicará el mecanismo convencional de asignación de llamada a agente, equitativo entre grupos ACD con misma prioridad)
  • Si el grupo ACD de la llamada está fuera del objetivo de servicio, se aplicará una ponderación que mejorará la prioridad de la llamada a medida que aumente el tiempo de espera:
Formula.png

En una configuración de igualdad de prioridad de agente y objetivo de servicio, el tiempo de espera influiría de manera determinante (más o menos en función del peso) en la asignación de la siguiente llamada El peso podrá adquirir tres posibles valores: 0, 1 y 10

Esquema.png
 - Calculo prioridad de llamada: se calcula por llamada cada vez que un agente queda libre
 - Agente atiende llamada con mejor prioridad de llamada




Volver al índice

4.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.


4.2.1 Esquema de funcionamiento

Esquema funcionamiento marcador.jpg

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.

4.2.2 Flujo de estados

El flujo de estados es el reflejado en la figura siguiente:

Diagrama de flujo motorsal.png

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.
Cancelado 300

4.2.3 Carga de contactos

4.2.3.1 Descripción

A continuación se explica la configuración y funcionamiento de la utilidad encargada de asignar contactos a campañas.

4.2.3.2 Configuración

El archivo de configuración recibe el nombre de cargaContactos.pconf. Este archivo reside en /etc/MDtel. El formato se describe en la tabla siguiente. Hay que tener en cuenta que las columnas empiezan a numerarse en 0.

Parámetro Valor Obligatorio Defecto
db Nombre de la base de datos SI nimitz
dbHost Host MySQL SI localhost
dbPort Puerto MySQL NO 3306
dbUsuario Usuario de acceso a la base de datos SI
dbClave Clave del usuario SI
rutaContactos Ruta hasta el archivo de contactos NO /var/spool/MDtel/contactos
obsoletos Si vale 1, marcar como obsoletos los contactos anteriores NO 0
diasCaducidad Número de dias a partir de los cuales caducarán los contactos SI
idCampanna Número de columna que contiene el ID de la campaña SI
idLista Numero de columna que contiene el ID de la lista SI
prioridad Número de columna que contiene la prioridad NO Nota: El valor es de 0 a 99. A mayor número mayor prioridad (se le llamará ANTES)
tipoTarea Número de columna que contiene el tipo de tarea NO Nota: los posibles valores de la columna son :
*A: Alta
*M: Modificación
*B: Baja
Por defecto el valor es A
codCli Número de columna del CSV que contiene el código de cliente SI
nombreCon Número de columna del CSV que contiene el nombre NO
apellido1 Número de columna del CSV que contiene el primer apellido NO
apellido2 Número de columna del CSV que contiene el segundo apellido NO
empresa Número de columna del CSV que contiene la empresa NO
direccion1 Número de columna del CSV que contiene la dirección NO
direccion2 Número de columna del CSV que contiene la dirección 2 NO
codPostal Número de columna del CSV que contiene el código postal NO
localidad Número de columna del CSV que contiene la localidad NO
provin Número de columna del CSV que contiene la provincia NO
email Número de columna del CSV que contiene el email NO
valFijo_1 Número de columna del CSV que contiene el primer número fijo del contacto SI
valFijo_2 Número de columna del CSV que contiene el segundo número fijo del contacto NO
valFijo_3 Número de columna del CSV que contiene el tercer número fijo del contacto NO
valFijo_4 Número de columna del CSV que contiene el cuarto número fijo del contacto NO
valMovil_1 Número de columna del CSV que contiene el primer número móvil del contacto SI
valMovil_2 Número de columna del CSV que contiene el segundo número móvil del contacto NO
valMovil_3 Número de columna del CSV que contiene el tercer número móvil del contacto NO
valMovil_4 Número de columna del CSV que contiene el CUARTO número móvil del contacto NO
edad Número de columna del CSV que contiene la edad NO
nOpc1 Número de columna del CSV que contiene dato numérico opcional NO
nOpc2 Número de columna del CSV que contiene dato numérico opcional NO
nOpc3 Número de columna del CSV que contiene dato numérico opcional NO
nOpc4 Número de columna del CSV que contiene dato numérico opcional NO
nOpc5 Número de columna del CSV que contiene dato numérico opcional NO
nOpc6 Número de columna del CSV que contiene dato numérico opcional NO
nOpc7 Número de columna del CSV que contiene dato numérico opcional NO
nOpc8 Número de columna del CSV que contiene dato numérico opcional NO
cOpc1 Número de columna del CSV que contiene cadena opcional NO
cOpc2 Número de columna del CSV que contiene cadena opcional NO
cOpc3 Número de columna del CSV que contiene cadena opcional NO
cOpc4 Número de columna del CSV que contiene cadena opcional NO
cOpc5 Número de columna del CSV que contiene cadena opcional NO
cOpc6 Número de columna del CSV que contiene cadena opcional NO
cOpc7 Número de columna del CSV que contiene cadena opcional NO
cOpc8 Número de columna del CSV que contiene cadena opcional NO
Idioma Idioma del contacto NO
4.2.3.3 Funcionamiento

Para ejecutar la utilidad se debe teclear la siguiente orden en la línea de comandos:

cmd# cargaContactos.pl /<ruta hasta el conf>/cargaContactos.pconf <archivo CSV>

El archivo con los contactos deberá ser un CSV con los campos separados por ';'. La utilidad parsea el archivo conforme a la distribución indicada en la configuración y crea las correspondientes entradas en las tablas ACD_CONTACTOS y ACD_CONTACTOS_CAMPANNAS.

La utilidad crea un log en /var/log/cargaContactos.log en el que vuelca toda la operativa. Por pantalla se va mostrando un lista con el ID asignado al contacto y el ID de campaña al que se le ha asignado.

Un ejemplo de fichero de carga de contactos sería el siguiente:

#
# Configuracion de cargaContactos.pconf
#
# Conexion de base de datos
$db='nimitz';
$dbHost = 'localhost';
$dbPort = '3306';
$dbUsuario = 'nimitz';
$dbClave = 'LA QUE SEA';
$diasCaducidad='300';
$rutaGrab = '/var/spool/MDtel/contactos';
$idCampanna = '31';
$idLista = '32';
$obsoletos = 0;
$codCli = '1';
$nombreCon = '2';
$apellido1 = '3';
$apellido2 = '4';
$empresa = '5';
$direccion1 = '6';
$direccion2 = '7';
$codPostal = '8';
$localidad = '9';
$provin = '10';
$email = '11';
$valFijo_1 = '12';
$valFijo_2 = '13';
$valFijo_3 = '14';
$valFijo_4 = '15';
$valMovil_1 = '16';
$valMovil_2 = '17';
$valMovil_3 = '18';
$valMovil_4 = '19';
$edad = '20';
$nOpc1 = '21';
$nOpc2 = '22';
$nOpc3 = '23';
$nOpc4 = '24';
$cOpc1 = '25';
$cOpc2 = '26';
$cOpc3 = '27';
$cOpc4 = '28';
$prioridad = '29';
$tipoTarea = '30';

4.2.4 Comportamiento de reprogramaciones de llamadas en función del estado del agente

Se ha preparado la siguiente maqueta:

Campaña saliente. Cola saliente progresiva. Dos agentes logados en VIVAit Suite.

En el formulario de la llamada se indica: llamada redirigida Se selecciona el "check dirigida"

Las posibilidades de prueba son dos: "Cualquier agente" y "Solo agente"

Resultados son los siguientes:

Estado del agente Modo Cualquier Agente Modo Solo Agente
Agente Preparado Entra llamada a agente Entra llamada a agente
Agente en Pausa Entra llamada a otro agente disponible Espera a agente y entra llamada.
Agente Hablando Espera a agente y entra llamada Espera a agente y entra llamada.
Agente en Tiempo administrativo Espera a agente y entra llamada Espera a agente y entra llamada.
Agente no logado Entra llamada a otro agenete disponible Consume intento.
Agente con una pestaña de chat abierta y el otro agente en pausa Entra llamada a otro agente disponible Espera a agente y entra llamada.
Agente con dos pestañas de chat abiertas Espera a agente y entra llamada Espera a agente y entra llamada.



Volver al índice

4.3 Movilidad

La movilidad es una función integral de las comunicaciones en la empresa. Cualquier empleado (usuario) es móvil en cierto grado, ya 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 estemos.

4.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]


La movilidad permite disponer de las extensiones telefónicas empresariales en cualquier lugar. Por ejemplo, con un ordenador portátil o smartphone en una ubicación remota con conexión a Internet, podríamos tener registrada nuestra extensión remotamente, y así las llamadas hacia/desde nuestra oficina serían enrutadas por Internet hasta el equipo en cuestión sin coste alguno.


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]

4.3.2 ¿Cómo funcionan las extensiones?

Primeramente el usuario debe tener los ejes apropiados en la tabla COM_USUARIOS_APLICACION (aplicación centralita).

La extensión debe de tener un teléfono y por tanto un modelo de teléfono asociado.

Es tan simple como especificar la extensión, el usuario y la clave de este.

Para corroborar el funcionamiento de esta hay dos métodos:

* CLI asterisk:

mdintz qry * nimitz bd extenEntraUsuarioMovil 25001 20001 1234

Y como resultado obtenemos lo siguiente:

mdintz Variables:
MdintzIdentif='cms1'
MOVIL_TIPO_RESET='10'
MOVIL_CAD_RESET='notify_yealink'
MdintzRes='OK'

El usuario con el login numérico 20001 se ha "movido" a la extensión 25001

Ahora nos quitamos de esa extensión mediante el siguiente comando:

mdintz qry * nimitz bd extenSaleUsuarioMovil 25001

Resultado del comando:

mdintz Variables:
MdintzIdentif='cms1'
MOVIL_TIPO_RESET='10'
MOVIL_CAD_RESET='notify_yealink'
MdintzRes='OK'

Las pruebas anteriores han sido con extensiones con movilidad y con usuario con/sin propietario.

Ahora las realizamos con extensiones sin movilidad

mdintz qry * nimitz bd extenEntraUsuarioMovil 25002 20001 1234

Obteniendo:

mdintz Variables:
MdintzIdentif='cms1'
MdintzRes='movil_error_datos'

Como era lo previsible no nos deja "movernos" a esa extensión ya que no tiene movilidad.

Si un usuario ya se ha movido a una extensión y se mueve a otra, el sistema lo deslogará de la primera para logarlo en la segunda.

mdintz qry * nimitz bd extenEntraUsuarioMovil 21000 20001 1234

Con salida:

mdintz Variables:
MdintzIdentif='cms1'
MOVIL_EXTEN='25001'
MDintzRes='movil_ya_login'

* Dialplan

Para llamar a la función de movilidad hay que marcar el 9992.

Nota.- Para comprobar que se realiza todo correctamente habría que mirar las trazas de Asterisk



Volver al índice




4.4 Desvío por calendario

Se ha desarrollado una nueva funcionalidad para VIVAit Call que permite establecer desvíos de extensiones y usuarios en base a una programación horaria. Una vez puesta en marcha esta funcionalidad , el orden de desvíos de usuarios o extensión en VIVAit Call será:


  • Primero se atiende si el usuario o extensión tiene desvío incondicional a

mensajería.

  • En segundo lugar se comprueba si dispone de desvío programado, y se

encuentra en una franja horaria con desvío activo.

  • Posteriormente se atiende si el usuario o extensión tiene desvío

incondicional.

  • Posteriormente se tratarán resto de desvíos condicionales (por no

conectado, por ocupado o por no contesta).



Captura de pantalla de 2022-11-16 07-58-38.png



Los componentes principales de la arquitectura son:


  • Servidor de calendarios : Para definir las programaciones de desvíos se ha utilizado una solución de servidor estándar de calendarios; se ha optado por el servidor Baikal, por disponer de todas las funcionalidades necesarias y disponer de BBDD Mysql (especialmente adecuado en entornos VIVAit)


  • Intz-Nimitz : El proceso de enrutamiento de VIVAit consultará en cada llamada el estado de desvío programado al servidor de calendarios; esta consulta solo se realizará en caso de que dicha extensión o usuario tenga activo dicho desvío y un calendario asignado; por defecto los desvíos programados estarán desactivados en todas las extensiones y usuarios para proteger las prestaciones del sistema.


  • Frontales : Para la administración por parte de los usuarios de los desvíos programados se ofrecen los siguientes frontales:

- Portal de usuario: Cada usuario podrá definir desvíos programados en el mismo entorno en el que define el resto de desvíos.

- Portal de administración de VIVAit: Desde dicho portal se podrán gestionar por un administrador los desvíos programados de usuarios y extensiones de todo el sistema.

- Portal de administración de Baikal: Desde dicho portal se podrán gestionar el servidor de calendarios.

- Entorno estándar de gestión de calendarios: desde un entorno estándar de gestión de calendarios (p. ej Thunderbird), y con protocolo CalDav, se podrán realizar gestiones de todos los calendarios de un entorno VIVAit. Este entorno sería una alternativa al portal de administración (no de usuario), debido a que:

1. Se deberá configurar dicho entorno para acceder con el usuario de administración de calendarios.

2. Se podrán ver todos los calendarios del sistema (de todas las extensiones y usuarios).


Por defecto no será necesario montar un nuevo nodo de VIVAit, para el despliegue de Baikal se montará donde esté ubicado el portal de administración de VIVAit.

 Baikal se ubicará por defecto en el mismo nodo en el que se encuentre el portal de administración de VIVAit.



4.4.1 Baikal

Como se ha indicado en el apartado de arquitectura, VIVAit Call utilizará un servidor de calendarios Baikal para almacenar la información referente a desvíos programados de usuarios y extensiones.

Baikal es un servidor CalDAV ligero. Los datos se almacenan en una base de datos Mysql (diferente a la base de datos de VIVAit).

En el caso de su uso en VIVAit Call:

  • Existirá un único usuario administrador de Baikal que podrá crear los calendarios (desde los frontales anteriormente descritos).
  • Los calendarios y los desvíos podrán ir asociados tanto a usuarios como a extensiones.
  • Cada extensión o usuario de VIVAit tiene un calendario asignado que se crea automáticamente en Baikal al programar el primer evento desde el portal de administración de VIVAit o desde el portal de usuario.


Si se instala Vivait 3.6 desde repositorio , habría que realizar los siguientes pasos en Mysql:

Configuración de Mysql


La instalación de Baikal implica disponer de un servidor Mysql operativo; será necesario crear una base de datos de nombre “baikal” con un usuario “baikal” que será el que utilizarán los frontales para la interacción con el servidor de calendarios:

Baikal usa su propia base de datos (diferente a la de VIVAit)


1.Configuración inicial Mysql


Si la instalación la estamos realizando sobre un nodo que no tenía instalado Mysql y lo hemos instalado durante este proceso de instalación en el paso 3 del punto anterior, deberemos configurar Mysql para su integración con VIVAit.

Acceder a Mysql y cambiar clave de root
-------------------------
mysql_secure_installation
mysql -u root -p
mysql> ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘ LACLAVEDEVIVAITPARAMYSQL ’;
-------------------------
  • No realizar la configuración inicial de Mysql si el nodo ya dispone de base de datos VIVAit


2.Configuración de Base de datos Baikal


Crear base de datos de baikal
-------------------------
mysql> create database baikal;
-------------------------
2. Crear usuario baikal
-------------------------
create user 'baikal'@'localhost' identified by 'ivivabaikal';
-------------------------
3. Asignar privilegios a usuario baikal
-------------------------
grant all on baikal.* to ‘baikal'@'localhost’;
-------------------------


Configuración de Baikal


Una vez instalado, podemos comprobar que el servidor Baikal está operativo accediendo a su URL de gestión en:

http://<IPServer>/baikal/html/


Tras acceder deberemos configurarlo adecuadamente, realizando los siguientes pasos:


Crear la conexión entre VIVA it y Baikal

Tener correctamente configurado en la tabla WEB_CONFIGURACION el usuario y clave de la base de datos de Baikal; esto permitirá configurar Baikal (usuario, calendarios…) sin tener que acceder a su interfaz de administración.

Se configura:

  • Host
  • Puerto (defecto 3306)
  • Driver con el que se conecta (Mysql)
  • Usuario de BBDD Baikal
  • Clave de BBDD Baikal


A nivel de base de datos


Calendario1.png


Donde:

  • MySQL host - Nombre del host de mysql.
  • MySQL database name - Nombre de la base de datos creada.
  • MySQL username - Nombre de usuario de acceso.
  • MySQL password - Contraseña de acceso.


En ajuste de sistema


Calendario2.png

Donde:


  • Zona horaria – Seleccionar la región que corresponda (típicamente Europe/Madrid).
  • Habilitar o deshabilitar CardDav o CalDav – Es necesario habilitar CalDav, y deshabilitar CardDav (no se va a utilizar).
  • Enviar invitación al correo del remitente – Dejar vacío.
  • Seleccionar el tipo de autenticación WebDav – Hay tres opciones (Digest, Basic y Apache), la opción que hay que seleccionar es Digest.
  • Contraseña del administrador – Esta contraseña se configura solo para entrar al entorno de Baikal.



Desde Baikal + Cliente Caldav


La administración desde Baikal solo será necesaria en caso de no poder utilizar los frontales desarrollados para la gestión de la funcionalidad.


Consideraciones relevantes:

  • Desde la administración de Baikal si podremos crear:


- usuarios (en caso de la funcionalidad en VIVAit solo usuario único de VIVAit).

- calendarios (existirá uno por extensión o usuario).


  • Desde la administración de Baikal no podremos gestionar eventos de calendario; para ello deberemos usar un cliente CalDav (p. ej Thunderbird).


Ejemplo de una consulta de intz-Nimitz a Baikal en los ficheros log:


Ante una consulta de Intz-Nimitz a Baikal, los resultados devueltos en el fichero de log (/var/log/intz-nimitz.log) por Baikal pueden ser:


1. En caso de existir una programación de desvío, Baikal devolverá los campos asunto y location de la programación, que podrán ser usados en los procesos posteriores de tratamiento de la llamada en caso de ser necesario:


Calendario5.png


2. En caso de no existir programación de desvío, devolverá vacío:


Captura6.png

4.5 Grabación

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

4.5.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 cuatro 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'

Modo grabación de infraestructura-Graba por petición


'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.

4.5.2 Vivait Tracker

Desde VIVAit Supervisor, que es la aplicación dirigida a Supervisores, 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

Esquematico tracker 1.jpg


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

Esquematico tracker 2 https.jpg


1º El tracker web llama al web service Remote login para iniciar sesión (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 índice

4.6 Enrutamiento

Enrutamiento.png


4.6.1 Enfoque inicial

Acceso

4.6.2 Funcionamiento

El proceso de enrutamiento, como vimos 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.
4.6.2.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.

4.6.2.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.


4.6.2.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

4.7 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

Ancho de banda.png

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


4.8 MDflow

MDflow es una aplicación Asterisk que se basa en la unidad de medida TIC (un TIC, por defecto, corresponde a 500ms, pero es configurable).

Los términos que usaremos para la explicación de la funcionalidad y que son relevantes para comprender, implantar, mantener e interpretar la misma son:


  • Nodo VIVAit: Un nodo VIVAit es cualquier elemento dado de alta en el sistema

como tal, que contiene un proceso de conmutación de voz Asterisk incorporado. Un cluster activo/pasivo son dos ordenadores, pero un solo nodo. Típicamente existen nodos de tres tipos (si bien los dos primeros pueden combinarse en uno solo):

- Nodo de registro para telefonía corporativa

- Nodo Gateway

- Nodo de registro ACD

  • TIC: Unidad básica de medida de tiempo de md flow; por defecto el valor es

500ms; nótese que los valores devueltos por el sistema siempre estarán medidos en segundos, aunque internamente use el TIC como base de tiempos.

  • Flujo: Cada uno de los nueve elementos de medida y control que podrán

establecerse por nodo VIVAit.

  • Medición: Capacidad de md flow para determinar el número de llamadas por

segundo que se están estableciendo en un determinado flujo. Nótese que no se hace referencia a duración de las mismas o medición de llamadas previamente establecidas

  • Control: Capacidad de md flow para limitar el número de llamadas por segundo

que se están estableciendo en un determinado flujo

  • Tasa de llamadas por segundo: Cantidad de llamadas que se están

estableciendo por segundo en un nodo VIVAit. Nótese que no se hace referencia a duración de las mismas o llamadas previamente establecidas

  • DNIS: Dialed Number Identification Service; número destino de una llamada
  • Congestión: Estado del nodo VIVAit cuando se sobrepasa una determinada tasa

de llamadas por segundo; el mecanismo md flow entrará en funcionamiento cuando el sistema entre en estado de congestión.

  • Llamada desbordada: Llamada que en el tratamiento de la congestión se

considera apta para ser descartada (si bien el tratamiento se definirá en dialplan, el funcionamiento lógico previsto es descartarla).

  • Llamada a agujero: Llamada que en el tratamiento de la congestión se considera

ha de progresar por no quedar colas de DNIS disponibles (se explicará y justificará el funcionamiento más adelante).

  • Mdflow en paso: md flow puede ser utilizado para:

- Solo medir . En este caso md flow se encontrará en paso.

- Medir y realizar control de flujo.

  • DNIS masivo: Un DNIS con alta tasa de llamadas por segundo.
  • DNIS ocasional: Un DNIS con baja tasa de llamadas por segundo.




La aplicación está diseñada para controlar el flujo de llamadas entrantesEl sistema cuenta llamadas en cada periodo TIC.

El módulo permite difinir distintas cajas de medida y control (FLUJO).

Se pueden definir n cajas y ubicarlas en Asterisk (por ejemplo en un enlace externo, una caja que agrupe todos los enlaces, en los enlaces interiores y en extensiones).

Cada una de las cajas, o flujos, mide y controla la tasa de llamadas en cada TIC → Se mostrará en llamadas/segundo.

El FLUJOmide lo que está pasando en un determinado punto del dialplan; un ejemplo claro será la primera línea de éste, cuando se crea una llamada de un enlace externo.

El FLUJOpermite controlar y medir, y está pensado para enviar información a Zbbix.

Desde el punto de vista del Dialplan, se trata de una aplicación con dos parámetros:

  • Que caja se utiliza (número del 1 al 9).
  • DNIS que permite controlar para que destino queremos hacer el control de flujo.

Para encolar internamente cada FLUJO tiene un número de colas definidas y cada DNIS está en una cola. Cuando entra una llamada y se invoca a la caja con el DNIS de esa llamada, o se crea nueva cola, o se encola en una existente para ese DNIS si la hubiera. El número de colas deberá ser el numero de DNIS masivo.

Una cola de un DNIS se libera de ese DNIS cuando queda vacia (por eso los ocasionales no tendrán cola habitualmente y los masivos si).

Cuando entra una llamada si el DNIS tiene cola se encola, si no tiene y hay libres se crea una nueva y si no hay colas libres (maximo configurable), la llamada pasa. (se asume que las masivas quedarán en colas y que las ocasionales pasarán).

Para sacar llamadas (desencolar), saco una de cada cola (fair queues). No podemos configurar que de unas colas se atiendan mas llamadas que de otras.

En control de flujo se indica para cada caja la tasa de entrada en llamadas/s.

El mecanismo de control de flujo entra en funcionamiento cuando el sistema entra en congestión.

Las llamadas que se encolan tienen un retardo adicional tipico de un TIC.

Cuando una llamada entra en cola se define un tiempo máximo en cola (por defecto 5 segundo); si se alcanza ese tiempo se considera llamada desbordada, la aplicación la saca con una etiqueta y sigue con el dialplan que podrá tirarla, podrá derivarla...


Mdflow se invoca dentro del dialplan del sistema. Por ejemplo, será la primera línea del dialplan correspondiente a un enlace externo; a la salida de md flow, este proporcionará una etiqueta, que podrá ser “Ok”, “desborda”, “agujero” o “error” El funcionamiento general de md flow es el reflejado en el siguiente diagrama de flujo.


Mdflow.png

Como se puede apreciar en el diagrama de flujo:

  • mdflow siempre cuenta las llamadas para establecer la tasa de llamadas por segundo.
  • Solo hace control de flujo si no está en paso.
  • Solo hace control de flujo si hay congestión (tasa de llamadas por segundo superior a la máxima configurada).
  • Estando en congestión:


- Si entra una llamada nueva

Y existe otra encolada para el DNIS se encola en dicha cola.

Y no existe cola para el DNIS se crea la cola y encola SI quedan colas disponibles.

Si no quedan colas disponibles la llamada sale con etiqueta “agujero”.


- Al respecto de colas

Una cola se crea cuando hay una llamada con un DNIS no encolado y si existen aún colas disponibles.

Una cola se libera de un DNIS cuando no quedan llamadas en cola para ese DNIS.

Las colas no tienen una profundidad máxima.

Las colas tienen un tiempo de permanencia.

Las llamadas se van atendiendo equitativamente en cada cola, todas tienen el mismo peso, saliendo con etiqueta “Ok”


- Al respecto de llamadas

Una llamada se saca de la cola con etiqueta “desborda” si pasa el máximo tiempo configurado en cola


- Si se produce un error en el sistema las llamadas podrán salir con etiqueta “error”.




Al respecto de las llamadas que salen con etiqueta “agujero”, cabría pensar que si no quedan colas disponibles las llamadas con etiqueta agujero serian llamadas candidatas a ser descartadas a DNIS ocasionales y se les dará prioridad. Téngase en cuenta que en circunstancias de congestión, las colas estarán típicamente ocupadas por DNIS masivos, y no por DNIS ocasionales, de manera que es altamente probable que cualquier DNIS masivo ya tenga cola asignada y que al agujero vayan DNIS ocasionales; todo esto pasa por realizar un buen dimensionamiento del máximo de colas (que debiera ser muy parecido al número de DNIS masivos)




Mdflow2.png



4.8.1 Proceso de instalación de mdflow en una instalación existente; → como se "añade" mdflow en un VIVAit existente

El proceso de instalación depende de dos ficheros:

  • app_mdflow.c que se ha de ubicar en el directorio /usr/src/MDtel/asterisk/apps/
  • MDflow.conf que ha de ponerse en /etc/asterisk/

Tras poner ambos ficheros en sus respectivos lugares, nos iremos a /usr/src/MDtel/asterisk/ y compilaremos el asterisk make && make install

Para que el asterisk cargue el nuevo módulo entrarems en la consola de asterisk (asterisk -r) y ejecutaremos module load app_mdflow.so


4.8.2 Parámetros de configuración

  • Parámetros generales


- tick_ms: duración de un TIC.

- estad_interv_seg: define intervalo de medida, si bien las informaciones siempre las proporcionará en tasa de llamadas/s.


  • Parámetros por flujo


-Flujo: nombre del flujo (solo para la salida de estadísticas); no conecta con nada en dialplan o similar.

-En_paso: (0 o 1); si está a 1 solo mide, siempre devuelve OK; si “en_paso” es 0 hay control de flujo.

-Tasa_sal_seg: tasa máxima de salida de llamadas/s configuradas para ese flujo; saldrán ese valor de llamadas por segundo con etiqueta “Ok”.

-Dnis_max: número de colas máximo en ese flujo. Si se configura 1 cola, se comporta como cola única, no se hace caso al DNIS.

-Dnis_umbral_masivo: no vale para control, pero sí para medida; nos define que un DNIS es masivo si hay tantas o más llamadas encoladas que las indicadas en este parámetro; si está solo en paso no se mide porque no hay colas.

-to_desborda_seg: Tiempo máximo en cola de una llamada; pasado el tiempo sale con "desborda"


4.8.3 Fichero de configuración

El fichero de configuración se ubica en /etc/Asterisk/MDflow.conf ; su contenido por defecto es el siguiente:


[general]
; Periodo de tiempo para medidas de tasa de llamadas
tick_ms=500
; Periodo de tiempo para calculos estadísticos
estad_interv_seg=10
; Máximo 9 flujos ([flujo_1] a [flujo_9])
; Tiene que empezar en [flujo_1] y ser correlativos
[flujo_1]
; Nombre asignado al flujo. Se usa en las salidas de los comandos
flujo=Cen_Inicio_SIP
; "En paso"
; 1: No se controla el flujo (siempre etiqueta OK), sólo se mide
; 0: Se controla la tasa de llamadas y se hacen medidas
en_paso=0
; Tasa máxima de llamadas (expresada en llamadas/seg) que etiquetadas OK
; Para un tick de 500 ms, este valor debe ser par
tasa_sal_seg=4
; Número máximo de dnis a encolar. Resto se etiquetan como AGUJERO
dnis_max=2
; Umbral para el número de llamadas encoladas en un dnis, que hace que
; éste sea calificado como "masivo"
; El valor mínimo es 2
dnis_umbral_masivo=8
; Límite de tiempo en segundos, transcurrido el cuál se etiqueta DESBORDA
to_desborda_seg=5
[flujo_2]
flujo=Cen_Inicio_TrunkSip
en_paso=1
tasa_sal_seg=20
dnis_max=100
dnis_umbral_masivo=10
to_desborda_seg=5
[flujo_3]
flujo=Cen_TrunkInternos
en_paso=1
tasa_sal_seg=20
dnis_max=100
dnis_umbral_masivo=10
to_desborda_seg=5

4.8.4 Ejemplo claro de invocación de mdflow desde dialplan y posterior tratamiento en función de las etiquetas de salida

Por defecto el MDflow se pondrá en los siguientes ficheros de Asterisk:

  • ext_InicioLlamada_ExtSIP.conf
  • ext_InicioLlamada_TrunkSIP.conf
  • ext_TrunkInternos.conf

ya que son los diferentes contextos de entrada de llamadas.

;--------------------------------------------------------------------------------
[Cen_TrunkInternos]
;--------------------------------------------------------------------------------
;--------------------------------------------------------------------------------
exten => _[*#%0-9a-zA-Z].,1,NoOp(MDENTTR_X****EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)

 same =>                  n,Set(__ENR_PEER_ORIGEN=${CHANNEL(peername)})


;-------------------------
;  Control de flujo
;-------------------------
 same =>                  n,Set(HORAINI=${EPOCH})
 same =>                  n,MDflow(3,${EXTEN})
 same =>                  n,Log(NOTICE,MDFLOWTRUNKINT**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**PEER=${ENR_PEER_ORIGEN}**CID=${CALLERID(NUM)}*)
 same =>                  n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 same =>                  n,Set(GROUP()=TrunkInternos)
 same =>                  n,Set(valor=)
 same =>                  n,ExecIf($["${LlamTrunkInternos}" = ""]?Set(valor=300):Set(valor=${LlamTrunkInternos}))
 same =>                  n,ExecIf($[${GROUP_COUNT(TrunkInternos)} > ${valor}]?HangUp(1))
 same =>                  n,Log(NOTICE,MDGROUPTRUNKINT**GROUPCOUNT=${GROUP_COUNT(TrunkInternos)}**PEER=${ENR_PEER_ORIGEN}**CID=${CALLERID(NUM)}*)

[Cen_Inicio_TrunkSip]
;exten => _[*#%0-9a-zA-Z].,1,NoOp(MDINITRUNKSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)
exten => _[*#%0-9].,1,NoOp(MDINITRUNKSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)

 ;      TTipoIdEnrutamiento = (
 ;              tipoIdEnrutamiento_ninguno=0,   // quitar no sabemos
 ;              tipoIdEnrutamiento_dispositivo=10,     
 ;              tipoIdEnrutamiento_cola=20     
 ;      );

 same =>            n,Set(ENR_PEER_ORIGEN=)
 same =>            n,Set(__ENR_TIPO_ORIGEN=10)
 same =>            n,Set(__ENR_ORIGEN=${ID_DISPOSITIVO})
 ;same =>            n,Set(__SPAN_IN=)
 ;same =>            n,Set(__CANAL_IN=)
 ;same =>            n,Set(__TIPO_LLAMADA=${TIPOLLAMADAENT})

 same =>            n,NoOp(ENR_TIPO_ORIGEN=${ENR_TIPO_ORIGEN}***ENR_ORIGEN=${ENR_ORIGEN})

;-------------------------
;  Control de flujo
;-------------------------
 same =>           n,Set(HORAINI=${EPOCH})
 same =>           n,MDflow(1,${EXTEN})
 same =>           n,Log(NOTICE,MDFLOWTRUNKSIP**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**CID=${CALLERID(NUM)}*)
 same =>           n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))
 same =>           n,Set(GROUP()=${CHANNEL(peername)})
 same =>           n,Set(valor=)
 same =>           n,ExecIf($["${maxLlam}" = ""]?Set(valor=300):Set(valor=${maxLlam}))
 same =>           n,ExecIf($[${GROUP_COUNT(${CHANNEL(peername)})} > ${valor}]?HangUp(1))
 same =>           n,Log(NOTICE,MDFLOWTRUNKSIP**GROUPCOUNT=${GROUP_COUNT(${CHANNEL(peername)})}**PEER=${CHANNEL(peername)}**CID=${CALLERID(NUM)}*)

Esto desaparecera cuando el dialplan sea unificado ahora es necesartio para que pase el ucid del acd


[Cen_Inicio_SIP]
exten => _[*#%0-9].,1,NoOp(MDINIEXTENSIP**EXTEN=${EXTEN}**CID=${CALLERID(NUM)}*)

 same =>            n,Set(ENR_PEER_ORIGEN=)
 same =>            n,Set(__ENR_TIPO_ORIGEN=10)
 same =>            n,Set(__ENR_ORIGEN=${ID_DISPOSITIVO})
 same =>            n,Set(__SPAN_IN=)
 same =>            n,Set(__CANAL_IN=)
 ;same =>            n,Set(__TIPO_LLAMADA=${TIPOLLAMADASAL})

 ;-------------------------
 ;  Control de flujo
 ;-------------------------
 same =>           n,Set(HORAINI=${EPOCH})
 same =>           n,MDflow(2,${EXTEN})
 same =>           n,Log(NOTICE,MDFLOWEXTSIP**RES=${MDflowRes}**SEG=$[${EPOCH}-${HORAINI}]**CID=${CALLERID(NUM)}*)
 same =>           n,ExecIf($["${MDflowRes}"="DESBORDA"]?HangUp(1))


 same =>            n,NoOp(ENR_TIPO_ORIGEN=${ENR_TIPO_ORIGEN}***ENR_ORIGEN=${ENR_ORIGEN})

Para recibir el UCID de otros vivait (move,meet)


4.8.5 Comandos básicos de diagnóstico

  Comandos básicos (dentro de la consola asterisk)
  • mdflow show stats: permite ver las medidas de cada flujo configurando que etsa tomando el mdflow, cuantas colas se estan utilizando, cuanteas llamadas pasan, cuantas desbordan, cuantas son agujero, cuantos dnis masivos hay...
Preproduccion-Corp0*CLI>  mdflow show stats

mdflow Estadística global:
  activo=1
  supervEjecutando=1
  tickMs=500
  estadIntervSeg=10
  flowNum=3
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
  flowInd=1 enPaso=0
  flowInd=1 tasaUltIntervMs=10003
  flowInd=1 tasaUltEntra=0
  flowInd=1 tasaUltSaleOk=0
  flowInd=1 tasaUltSaleDesborda=0
  flowInd=1 tasaUltSaleAgujero=0
  flowInd=1 tasaUltSaleError=0
  flowInd=1 llamUltColaMax=0
  flowInd=1 dnisUltColasUsoMax=0
  flowInd=1 dnisUltMasivoMax=0
  flowInd=1 retardoUltMedioMs=0
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
  flowInd=2 enPaso=1
  flowInd=2 tasaUltIntervMs=10003
  flowInd=2 tasaUltEntra=0
  flowInd=2 tasaUltSaleOk=0
  flowInd=2 tasaUltSaleDesborda=0
  flowInd=2 tasaUltSaleAgujero=0
  flowInd=2 tasaUltSaleError=0
  flowInd=2 llamUltColaMax=0
  flowInd=2 dnisUltColasUsoMax=0
  flowInd=2 dnisUltMasivoMax=0
  flowInd=2 retardoUltMedioMs=0
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
  flowInd=3 enPaso=0
  flowInd=3 tasaUltIntervMs=10003
  flowInd=3 tasaUltEntra=0
  flowInd=3 tasaUltSaleOk=0
  flowInd=3 tasaUltSaleDesborda=0
  flowInd=3 tasaUltSaleAgujero=0
  flowInd=3 tasaUltSaleError=0
  flowInd=3 llamUltColaMax=0
  flowInd=3 dnisUltColasUsoMax=0
  flowInd=3 dnisUltMasivoMax=0
  flowInd=3 retardoUltMedioMs=0
  • mdflow show dnis: permite saber cuales son los DNIS masivos de la centralita
Preproduccion-Corp0*CLI> mdflow show dnis
mdflow Estado global:
  activo=1
  supervEjecutando=1
  tickMs=500
  estadIntervSeg=10
  flowNum=3
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
  flowInd=1 enPaso=0
  flowInd=1 dnisColaNum=1 no se controlan dnis
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
  flowInd=2 enPaso=1
  flowInd=2 dnisColaNum=2
  flowInd=2 dnisUltMasivoMax=0
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
  flowInd=3 enPaso=0
  flowInd=3 dnisColaNum=1 no se controlan dnis
  • mdflow show config Permite ver la configuracion de los distintos flujos
Preproduccion-Corp0*CLI> mdflow show config
mdflow Configuración global:
  activo=1
  supervEjecutando=1
  tickMs=500
  estadIntervSeg=10
  estadFases=20
  flowNum=3
mdflow flujo=[flujo_1]/Cen_Inicio_TrunkSip:
  flowInd=1 enPaso=0
  flowInd=1 llamSalTick=1
  flowInd=1 llamSalSeg=2
  flowInd=1 dnisColaNum=1
  flowInd=1 dnisUmbralMasivo=8
  flowInd=1 llamDesbordaToSeg=5
mdflow flujo=[flujo_2]/Cen_Inicio_SIP:
  flowInd=2 enPaso=1
  flowInd=2 llamSalTick=1
  flowInd=2 llamSalSeg=2
  flowInd=2 dnisColaNum=2
  flowInd=2 dnisUmbralMasivo=10
  flowInd=2 llamDesbordaToSeg=5
mdflow flujo=[flujo_3]/Cen_TrunkInternos:
  flowInd=3 enPaso=0
  flowInd=3 llamSalTick=1
  flowInd=3 llamSalSeg=2
  flowInd=3 dnisColaNum=1
  flowInd=3 dnisUmbralMasivo=8
  flowInd=3 llamDesbordaToSeg=5


  • mdflow reload: Recarga mdflow leyendo de nuevo el fichero de configuración

MDlow.conf; se puede realizar con la plataforma en funcionamiento normal pero no se recomienda realizarlo en momentos de alto tráfico; los cambios de configuración se aplican tras un comando “mdflow reload”

Preproduccion-Corp0*CLI> mdflow reload


  • mdflow debug: Muestra estadísticas por pantalla a intervalos regulares; no se

recomienda su uso sistemático.

Preproduccion-Corp0*CLI> mdflow debug

4.8.6 Comandos básicos de diagnóstico

El MDflow está activo si los comandos anteriormente mencionados devuleven datos, si no devuelven nada es que ha ocurrido un error al cargar el módulo en asterisk. Los comandos de diagnostico empleados son los mismos que hemos mencionado anteriormente más el mdflow debug on, que muestra lo mismo que el mdflow show stats pero lo hace para cada llamada que pase por la parte del dialplan que hemos mencionado antes.


4.8.7 Asignación de flujos

Por defecto, en la instalación irán definidos los siguientes flujos:

  • Flujo 1 (trunksip): Flujo que analiza las llamadas que vienen de los trunksip.

Típicamente son las llamadas que provienen de los operadores en los Gatewais. Está configurado en el contexto Cen_InicioLlamada_TrunkSip.

  • Flujo 2 (Extensiones): Flujo para las llamadas originadas por las extensiones SIP

registradas en el nodo. Está configurado en el contexto Cen_InicioLlamada_SIP.

  • Flujo 3 (trunkInternos): Flujo para las llamadas que provienen de otros nodos.

Está configurado en el contexto Cen_TrunkInternos


Estos son flujos genéricos que irán definidos en la instalación, se podrán generar mas si la instalación lo requiere, por ejemplo, si la instalación tiene primarios se podrá definir un flujo para las llamadas que vienen por el contexto Cen_InicioLlamada_Dahdi.


El significado del flujo 3 es diferente según el tipo de nodo en que se está ejecutando. Por ejemplo, en una instalación de 2 nodos, un nodo Gateway y un nodo de procesamiento, el flujo 3 en el nodo gateways estará midiendo el tráfico que manda el nodo de procesamiento hacia el exterior del sistema, típicamente las llamadas salientes al sistema, en cambio, el mismo flujo en el nodo de procesamiento, estará indicando las llamadas que vienen del Gateway, típicamente las llamadas entrantes del exterior.


Esto es mucho menos evidente en instalaciones con varios nodos, con trunk hacia proveedores externos en los nodos de procesamiento, etc.


4.8.8 Configuración de cola única

La configuración de colas es útil cuando el número de DNIS es finito y queremos priorizar
los números llamados menos frecuentemente sobre los masivos.
Cuando el número de DNIS es muy grande la configuración mediante colas no ofrece un
funcionamiento óptimo, las colas serán ocupadas cada una con un DNIS diferente y todos
los DNIS que no tengan cola libre saldrán por la salida “agujero”.
Para tener un control del flujo en estas situaciones se ha creado el concepto de cola única,
su comportamiento es que todas las llamadas van a la misma cola y no hay llamadas que
obtengan la salida “agujero” y por tanto todas tienen la misma prioridad.
Este comportamiento se obtiene poniendo el parámetro de configuración del flujo
dnis_max con el valor 1 (dnis_max=1).
Un ejemplo típico de utilización de este tipo de configuración sería en el flujo 3 de los
nodos gateways. Este flujo tendrá las llamadas que el resto de los nodos envían al exterior
y los DNIS no coincidirían en su mayoría.

4.8.9 MDflow y las trazas

El diaplan devulelve trazas del MDflow mdiante mensajes NOTICE, por lo que filtrando en el full de asterisk por la cadena MDFLOW irán apareciendo los diferentes retornos de ejecucion del MDFLOW (cuanto tiempo ha tardado en ejecutarse, qué devuelve el MDflow para esa llamada (agujero, desbordada, ok o error))




Volver al índice

4.9 Estadísticas en VIVAit Call

Como configurar estadísticas para VIVAit Call






5 Diagnósticos y operaciones básicas en VIVAit



5.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


5.2 Cluster VIVAit



5.2.1 Introducción a cluster



Un clúster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad, de tal forma que el conjunto es visto como un único ordenador.

De un clúster se espera que presente combinaciones de los siguientes servicios:

# Alto rendimiento
# Alta disponibilidad
# Balanceo de carga
# Escalabilidad





5.2.2 Funcionamiento en cluster




Tal y como esta definido el cluster de MDtel, este comprueba conectividad con la otra máquina que lo forma y con un punto de confianza. Si la máquina no tiene conectividad con la otra y si con el punto de confianza es que el servidor está vivo, mientas que si no tengo conectividad ni con la otra máquina ni con el punto de confianza es que el muerto soy yo, por lo que balanceo.

Por lo que las máquinas balancean en los casos siguientes: Tal y como esta definido el cluster de MDtel, este comprueba conectividad con la otra máquina que lo forma y con un punto de confianza. Si la máquina no tiene conectividad con la otra y si con el punto de confianza es que el servidor está vivo, mientas que si no tengo conectividad ni con la otra máquina ni con el punto de confianza es que el muerto soy yo, por lo que balanceo.

Por lo que las máquinas balancean en los casos siguientes:

  • Todo lo que tenga que ver con la red, es decir, caída de la tarjeta de red, apagado de la máquina, corte en la red..

Y no balancea en los siguientes:

  • No balancea en los demás casos, es decir, todo lo que tenga que ver con procesos de una máquina (caída asterisk, base de datos, intz-nimitz)


5.2.2.1 Píldoras
5.2.2.1.1 Prevenir que un nodo vuelva a tomar el control tras volver a estar operativo

Cuando queremos evitar que un recurso vuelva al nodo en el que estaba originalmente tras la recuperación del nodo, ejecutaremos la siguiente orden.

pcs resource defaults resource-stickiness=100
5.2.2.1.2 Borrar un recurso
pcs resource delete DRBDFs
5.2.2.1.3 Sincronización del drbd

Para sincronizar el drdb tras un fallo tenemos que determinar cuál es el nodo que tiene los datos buenos y cuál es el que vamos a sobrescribir sus datos

En el nodo que vamos a sobrescribir los datos ejecutaremos los siguientes comandos.

drbdadm secondary all
drbdadm disconnect all 
drbdadm invalidate all
drbdadm connect all


Y en el nodo que tiene los datos correctos.

drbdadm connect all


5.2.2.1.4 Mover un recurso de nodo

Para mover un recurso de nodo utilizaremos el siguiente comando.

pcs resource move IP-ASTER 
pcs resource clear IP-ASTER

Esto crea restricciones locales para evitar que el recurso vuelva a este nodo (Puede tener prioridad de ejecución en este nodo y haría que volviera a este nodo automáticamente al estar online).

La restricción que crea banea el nodo para este recurso, si queremos quitar esta restricción creada.

pcs resource clear DRBDfsASTER

Mirar si existe alguna manera de mover un recurso sin que se creen estas restricciones locales


5.2.2.1.5 Habilitar/deshabilitar recursos

Los comandos para habilitar y deshabilitar recursos en un nodo son

Si especificamos un tiempo, pcs esperara este tiempo y retornara 0 si el recurso a parado o 1 si el recurso no ha parado en el tiempo especificado.

pcs resource disable resource_id [--wait[=n]]

Si especificamos un tiempo, pcs esperara este tiempo y retornara 0 si el recurso a arrancado o 1 si el recurso no ha arrancado en el tiempo especificado.

pcs resource enable resource_id [--wait[=n]]
pcs config show
pcs resource cleanup resource_id
pcs resource clear
pcs resource refresh

Borra los Failed Actions de un recurso:

pcs resource cleanup [recurso]
5.2.2.1.6 Notas sincronismo

Si tenemos este fallo:

root@VC-PROC-SUMA-ALC-02:/tmp# cat /proc/drbd
version: 8.4.10 (api:1/proto:86-101)
srcversion: 7922D81D3881494EB149253
 0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
root@VC-PROC-SUMA-ALC-01:~# cat /proc/drbd
version: 8.4.10 (api:1/proto:86-101)
srcversion: 7922D81D3881494EB149253
 0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown   r-----


En el nodo principal

drbdadm connect all

En el nodo secundario

drbdadm -- --discard-my-data connect all 
********* En secundario: ************** 
drbdadm secondary drbdASTER
drbdadm disconnect drbdASTER
drbdadm -- --discard-my-data connect drbdASTER
********* En primario: ****************
drbdadm primary drbdASTER
drbdadm disconnect drbdASTER
drbdadm connect drbdASTER


5.2.2.1.7 Configuración para KVM
vi /etc/multipath.conf
-----------------------------
defaults {
   user_friendly_names yes
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]"
devnode "^vd[b-z]?[0-9]"
devnode "vda"
devnode "vda1"
devnode "^drbd[0-9]*"
}
systemctl restart multipathd.service
vi /etc/corosync/corosync.conf
------------------------------------
totem {
   version: 2
   cluster_name: CLmdtel
   transport: knet
   crypto_cipher: aes256
   crypto_hash: sha256
   token: 12000
}
nodelist {
   node {
       ring0_addr: nodo-vc-01
       name: nodo-vc-01
       nodeid: 1
   }
   node {
       ring0_addr: nodo-vc-02
       name: nodo-vc-02
       nodeid: 2
   }
}
quorum {
   provider: corosync_votequorum
   two_node: 1
}
logging {
   to_logfile: yes
   logfile: /var/log/corosync/corosync.log
   to_syslog: yes
   timestamp: on
}
systemctl restart corosync

Revisar que están arrancados después de reinicar:

Corosync Pacemaker multipath


5.2.2.2 Ejemplo de cluster con mysql y asterisk

En este ejemplo vamos a crear un cluster que maneje mysql y Asterisk como servicios separados.

Para lograr esto vamos a necesitar que el drbd maneje dos particiones separadas y tener dos ip flotantes, una para cada servicio.

5.2.2.2.1 Requisitos previos

Los requisitos previos antes de comenzar la instalación del cluster son:

• Nodos correctamente actualizados (update/upgrade).

• Conexión a internet.

• NTP configurado.


Creación de las particiones e instalación y configuración del drbd

5.2.2.2.2 Particionado (En los 2 nodos)

Para la instalación de los dos recursos drbd necesitamos tener dos particiones que vamos a crear añadiendo un disco duro en cada una de las máquinas. Lo añadimos mediante el Gestor de Máquinas Virtuales de la máquina 999-sgestion. Los tamaños serán los siguientes:

• Corporativo -> 50Gb

• BDTR -> 100Gb

Lo siguiente es crear la partición en cada servidor:


Cluster1.png

Vamos a utilizar la herramienta parted seguido del dispositivo que queremos particionar. En este caso el espacio que vamos a particionar está en el dispositivo /dev/vdc.

parted /dev/vdc

Una vez ejecutado el comando entraremos en una consola de la aplicación.

Ejecutando el comando

(parted) print free

Obtenemos las particiones que tiene el dispositivo actualmente y el espacio libre que disponemos.

Cluster2.png

En este ejemplo disponemos de 50Gb de espacio libre que es el que vamos a utilizar para las 2 particiones necesarias.

Lanzamos el comando mkpart para realizar la primera partición que será para mysql.

(parted) mkpart

El nombre que le vamos a dar a la partición es DRBD-MYSQL. El Tipo de sistema de ficheros ext4. Luego nos pedirá el principio de la partición, en el ejemplo vamos a comenzar en 198Gb y vamos a finalizar en 550Gb.


Cluster3.png

Realizaremos la segunda partición volviendo a ejecutar el mismo comando

(parted) mkpart


En este ejemplo el nombre para esta partición será DRBD-ASTER el tipo ext4 y le daremos el espacio restante del disco.

Cluster4.png


Para ver el resultado de las particiones podemos ejecutar el comando.

lsblk

Cluster5.png

Realizamos este mismo proceso en el otro nodo del cluster.


5.2.2.2.3 Gestión de particiones con LVM (En los 2 nodos)

Crearemos las 2 particiones lvm en los 2 servidores con los siguientes comandos.

En este ejemplo las particiones que queremos utilizar son /dev/sda5 para mysql y /dev/sda6 para Asterisk, esto podrá cambiar en las instalaciones.

Cluster6.png

Realizamos este mismo proceso en el otro nodo del cluster.


5.2.2.2.4 Instalación y configuración del drbd (En los 2 nodos)

Instalaremos el paquete drbd8-utils. En Ubuntu 20.04 drbd-utils

apt-get install drbd-utils

Ahora tenemos que editar los archivos de configuración del drbd, estos archivos están en el directorio /etc/drbd.d

Primero editaremos la configuración general, el archivo global_common.conf y le añadiremos en la sección net lo siguiente.

vi /etc/drbd.d/global_common.conf

Cluster7.png

Si tenemos problemas con los backup que realiza Vodafone en las máquinas virtuales añadir:

 net {
               # protocol timeout max-epoch-size max-buffers
               # connect-int ping-int sndbuf-size rcvbuf-size ko-count
               # allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
               # after-sb-1pri after-sb-2pri always-asbp rr-conflict
               # ping-timeout data-integrity-alg tcp-cork on-congestion
               # congestion-fill congestion-extents csums-alg verify-alg
               # use-rle
               protocol C;
               after-sb-0pri discard-zero-changes;
               after-sb-1pri discard-secondary;
               after-sb-2pri disconnect;
       }

Ó (nota Centro de Servicios)

net {
   ping-int 30;
   timeout 20;
   connect-int 30;
   protocol C;
   after-sb-0pri discard-older-primary;
   after-sb-1pri discard-secondary;
   after-sb-2pri disconnect;
}


Para configurar los recursos tenemos que crear en el directorio /etc/drbd.d un archivo para cada recurso. Estos archivos deben tener la extensión res.

Creamos el archivo para el recurso mysql con el nombre drbd-mysql.res.

vi drbd-mysql.res

El contenido del archivo es:

resource drbdMYSQL {
 on VC-CORP-Cetelem-Mad-cl1 {
   device /dev/drbd0;
   disk /dev/mapper/vg_DRBD--MYSQL-lv_DRBD--MYSQL;
   address 10.10.10.10:7788;
   meta-disk internal;
 }
 on VC-CORP-Cetelem-Mad-cl2 {
   device /dev/drbd0;
   disk /dev/mapper/vg_DRBD--MYSQL-lv_DRBD--MYSQL;
   address 10.10.10.11:7788;
   meta-disk internal;
 }
}


Ahora haremos lo mismo para el recurso Asterisk, el archivo se llamará: drbd-aster.res.

vi drbd-aster.res


y el contenido será el siguiente:

resource drbdASTER {
 on VC-CORP-Cetelem-Mad-cl1 {
   device /dev/drbd1;
   disk /dev/mapper/vg_DRBD--ASTER-lv_DRBD--ASTER;
   address 10.10.10.10:7789;
   meta-disk internal;
 }
 on VC-CORP-Cetelem-Mad-cl2 {
   device /dev/drbd1;
   disk /dev/mapper/vg_DRBD--ASTER-lv_DRBD--ASTER;
   address 10.10.10.11:7789;
   meta-disk internal;
 }
}

Realizamos este mismo proceso en el otro nodo del cluster. Los ficheros de configuración los podemos copiar de un nodo a otro.


5.2.2.2.5 Configuración de /etc/hosts (En los 2 nodos)

Tenemos que configurar correctamente los nombres de las máquinas en el archivo /etc/hosts.

vi /etc/hosts

El contenido de este archivo variará según la configuración, para este ejemplo.

Cluster8.png

127.0.0.1	localhost
#127.0.1.1	VC-CORP-mdtelMad-cl1
128.1.4.201	VC-CORP-mdtel-Mad-cl1
128.1.4.202   VC-CORP-mdtel-Mad-cl2
10.10.10.10	 nodo-vc-01
10.10.10.11    nodo-vc-02


Realizamos este mismo proceso en el otro nodo del cluster.


5.2.2.2.6 Creación de los recursos en drbd. (En los 2 nodos)

Ahora crearemos los recursos en drbd, primero el de mysql

drbdadm create-md drbdMYSQL

Y después el de Asterisk

drbdadm create-md drbdASTER

Y arrancamos el drbd en el nodo.

/etc/init.d/drbd start

Crearemos las carpetas donde se montarán los recursos del drbd

mkdir HDmysql
touch /HDmysql/sinMontar
mkdir HDaster
touch /HDaster/sinMontar

Realizamos este mismo proceso en el otro nodo del cluster.

5.2.2.2.7 Sincronización del drbd. (En 1 nodo)

Este proceso solo se debe realizar en un nodo, Con este comando sincronizaremos los 2 discos y el nodo desde donde lo lancemos será el que aporte los datos en la sincronización. Como no hay nada en los discos todavía es igual desde que nodo se ejecute.

drbdadm -- --overwrite-data-of-peer primary all


Podemos ir viendo cual es el porcentaje que lleva realizado con el siguiente comando.

watch -n 1 'cat /proc/drbd'

Al final de la sincronización debería salir algo como esto.

Cluster9.png


5.2.2.3 Pacemaker, corosync y pcs

Ahora deberíamos tener en los 2 nodos un mysql configurado y corriendo, un Asterisk configurado y corriendo y 2 particiones de drbd (una para mysql y otra para Asterisk) sincronizadas, aunque no están montadas en ningún sitio.


5.2.2.3.1 Parar y deshabilitar los servicios. (en los 2 nodos)

Todos los servicios que vayan a ser controlados por el pacemaker tienen que estar parados y el arranque deshabilitado para que el pacemaker los arranque y los pare en el nodo que corresponda.

/etc/init.d/asterisk stop
/etc/init.d/mysql stop
/etc/init.d/drbd stop
systemctl disable mysql
systemctl disable drbd
systemctl disable asterisk


Realizamos este mismo proceso en el otro nodo del cluster.


5.2.2.3.2 Instalación de los paquetes necesarios. (En los 2 nodos)

Instalamos los paquetes necesarios.

apt install corosync pacemaker pcs


Realizamos este mismo proceso en el otro nodo del cluster.


5.2.2.3.3 Configuramos la clave del usuario hacluster. (En los 2 nodos)

Al instalar los paquetes se crea un usuario hacluster que tenemos que ponerle clave

passwd hacluster

La clave deberá ser la misma en los 2 nodos. ivivacluster


Realizamos este mismo proceso en el otro nodo del cluster.


5.2.2.3.4 Autentificación del pcs. (En 1 nodo)

En uno de los nodos ejecutamos el siguiente comando para autenticar el pcs.

pcs host auth nodo-vc-01 nodo-vc-02 -u hacluster -p ivivacluster

El resultado del comando tiene que ser:

VC-CORP-Cetelem-Mad-cl1: Authorized
VC-CORP-Cetelem-Mad-cl2: Authorized
5.2.2.3.5 Creación y configuración del cluster. (En 1 nodo)

Ahora creamos el cluster e incluimos las maquinas que lo van a componer y le asignamos un nombre (este nombre no puede exceder de 15 caracteres).

pcs cluster destroy (en caso de no encontrar /var/lib/pcsd/known-hosts y después lanzar pcs host auth noco-vc-01 nodo-vc-02   -h hacluster -p ivivacluster)
pcs cluster setup CLmutuaint  nodo-vc-01 nodo-vc-02 --start --enable --force

Si todo ha ido bien la salida debería ser algo como esto.

Cluster10.png

Lo habilitamos en todos los nodos

pcs cluster enable --all

La salida será:

VC-CORP-CDS-MAD-01: Cluster Enabled
VC-CORP-CDS-MAD-02: Cluster Enabled

Arrancamos el cluster en todos los nodos

pcs cluster start --all


Cluster11.png

Comprobamos que todo está correcto con el siguiente comando:

Nos mostrara el estado del cluster.

Cluster12.png


En la salida del comando, vemos que STONITH (Shoot The Other Node In The Head) esta activado, pero no hay dispositivos configurados.

Quitamos el STONITH.

pcs property set stonith-enabled=false --force


También deshabilitaremos la política de quorum. Un cluster tiene quorum cuando más de la mitad de los nodos están online. Pacemaker por defecto para todos los servicios si no hay quorum, esto no tiene mucho sentido en un cluster de 2 nodos.

pcs property set no-quorum-policy=ignore --force


Vamos a ver la lista de propiedades del cluster para ver que hemos deshabilitado todo correctamente.

pcs property list


Cluster13.png


5.2.2.3.6 Creación de las IP flotantes (En 1 nodo)

Ahora vamos a crear las 2 direcciones ip flotantes para que la conexión se realice a la maquina correcta en cada caso, esta ip balanceara entre los diferentes nodos para dar acceso a los servicios en el nodo en el que estén activos.

Creamos la IP para el mysql.

pcs resource create IP-MYSQL ocf:heartbeat:IPaddr2 ip=128.1.4.205 nic=eno1:0 cidr_netmask=16 op monitor interval=60s

Y la IP para el Asterisk

pcs resource create IP-ASTER ocf:heartbeat:IPaddr2 ip=128.1.4.207 nic=eno1:1 cidr_netmask=16 op monitor interval=60s

Comprobamos el estado del cluster.

pcs status

Nos mostrará los nuevos recursos creados y nos indicará en que nodo han sido arrancados.


Cluster14.png


5.2.2.3.7 Configuración del drdb. (En 1 nodo)

La configuración de DRBD en Pacemaker implica que creemos varios recursos que se ejecutaran a la vez, para ello, utilizaremos una opción de pcs que nos permite encolar varios comandos y ejecutarlos al mismo tiempo. Estos comandos serán ejecutados únicamente en un nodo.

Primero ejecutaremos los comandos necesarios para la creación del drbd para mysql.

pcs cluster cib drbd_mysql_cfg
pcs -f drbd_mysql_cfg resource create DRBDmysql ocf:linbit:drbd drbd_resource=drbdMYSQL op monitor interval=60s
pcs -f drbd_mysql_cfg resource master DRBDmysqlClone DRBDmysql master-max=1 master-node-max=1 clone-max=2 clone-node-max=1  notify=true
pcs -f drbd_mysql_cfg resource promotable DRBDmysql promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1  notify=true 
pcs cluster cib-push drbd_mysql_cfg

Y lo mismo para el drbd de asterisk.

pcs cluster cib drbd_aster_cfg
pcs -f drbd_aster_cfg resource create DRBDaster ocf:linbit:drbd drbd_resource=drbdASTER op monitor interval=60s
pcs -f drbd_aster_cfg resource promotable DRBDaster promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1  notify=true 
pcs cluster cib-push drbd_aster_cfg
pcs cluster cib drbd_aster_cfg
pcs cluster cib-push drbd_aster_cfg


Miraremos el estado del cluster

pcs status

El resultado debería de mostrar que los recursos del drbd están creado y cuál es el nodo primario (master) y cuál es el nodo secundario (slave) para ambos recursos.

Cluster15.png


5.2.2.3.8 Montar las particiones del drbd. (En 1 nodo)

Formatearemos las particiones del drbd.

mkfs.ext4 /dev/drbd1
mkfs.ext4 /dev/drbd0

Una vez finalizado el proceso la pantalla mostrará a siguiente información (para cada comando).

Cluster16.png


Ahora crearemos el recurso para montar la partición de mysql en el directorio que creamos.

Vamos a crear restricciones para asegurarnos que los recursos estén todos en el nodo correcto y que arrancan en orden.

Vamos a configurar que la partición se monte en el nodo que sea master que la ip flotante este en este nodo y arranque después de haber montado la partición.

pcs cluster cib fs_mysql_cfg
pcs -f fs_mysql_cfg resource create DRBDfsMYSQL Filesystem device="/dev/drbd0" directory="/HDmysql" fstype="ext4"
pcs -f fs_mysql_cfg constraint colocation add DRBDfsMYSQL with DRBDmysqlClone INFINITY with-rsc-role=Master
pcs -f fs_mysql_cfg constraint order promote DRBDmysqlClone then start DRBDfsMYSQL
pcs -f fs_mysql_cfg constraint colocation add IP-MYSQL with DRBDfsMYSQL INFINITY
pcs -f fs_mysql_cfg constraint order DRBDfsMYSQL then IP-MYSQL
pcs cluster cib-push fs_mysql_cfg
pcs status

La salida mostrará lo siguiente:

Cluster17.png

Nos indica que el Filesystem está creado y montado en el nodo nodo-vc-01.

Ahora haremos lo mismo para la partición de Asterisk.

pcs cluster cib fs_aster_cfg
pcs -f fs_aster_cfg resource create DRBDfsASTER Filesystem device="/dev/drbd1" directory="/HDaster" fstype="ext4"
pcs -f fs_aster_cfg constraint colocation add DRBDfsASTER with DRBDasterClone INFINITY with-rsc-role=Master
pcs -f fs_aster_cfg constraint order promote DRBDasterClone then start DRBDfsASTER
pcs -f fs_aster_cfg constraint colocation add IP-ASTER with DRBDfsASTER INFINITY
pcs -f fs_aster_cfg constraint order DRBDfsASTER then IP-ASTER
pcs cluster cib-push fs_aster_cfg
pcs status

Vemos que ya tenemos las 2 particiones montadas.

Cluster18.png


5.2.2.3.9 Copiar datos de Asterisk a partición drbd. (En nodo 1)

Esto hay que realizarlo en el nodo en el que está montada la partición drbd para asterisk. Estará montado en la carpeta /HDaster

cd /HDaster/
tar -zcvf etc-asterisk.tgz /etc/asterisk
tar -zxvf  etc-asterisk.tgz
rm etc-asterisk.tgz
tar -zcvf var-lib-asterisk.tgz /var/lib/asterisk
tar -zxvf  var-lib-asterisk.tgz
rm var-lib-asterisk.tgz
tar -zcvf usr-lib-asterisk.tgz /usr/lib/asterisk
tar -zxvf  usr-lib-asterisk.tgz
rm usr-lib-asterisk.tgz
tar -zcvf var-spool-asterisk.tgz /var/spool/asterisk
tar -zxvf  var-spool-asterisk.tgz
rm var-spool-asterisk.tgz
5.2.2.3.10 Borrar los directorios de asterisk y crear enlaces simbólicos. (En los 2 nodos)

Borraremos los directorios y crearemos los enlaces simbólicos necesarios.


rm -rf /etc/asterisk
ln -s /HDaster/etc/asterisk /etc/asterisk
rm -rf /var/lib/asterisk
ln -s /HDaster/var/lib/asterisk /var/lib/asterisk
rm -rf /usr/lib/asterisk
ln -s /HDaster/usr/lib/asterisk /usr/lib/asterisk
rm -rf /var/spool/asterisk
ln -s /HDaster/var/spool/asterisk /var/spool/asterisk


5.2.2.3.11 Copiar datos de mysql a partición drbd. (En 1 nodo)

Esto hay que realizarlo en el nodo en el que está montada la partición drbd para mysql. Estará montado en la carpeta /HDmysql

cd /HDmysql/
tar -zcvf var-lib-mysql.tgz /var/lib/mysql
tar -zxvf  var-lib-mysql.tgz
tar -zcvf etc-mysql.tgz /etc/mysql
tar -zxvf  etc-mysql.tgz


5.2.2.3.12 Borrar los directorios de mysql y crear enlaces simbólicos. (En los 2 nodos)

Los datos contenidos en estos directorios ya no son válidos, borramos los directorios.

Los enlaces simbólicos no van a ser necesarios, los vamos a conservar para facilitar el acceso a los directorios de mysql habituales

rm -rf /var/lib/mysql
ln -s /HDmysql/var/lib/mysql /var/lib/mysql
rm -rf /etc/mysql
ln -s /HDmysql/etc/mysql /etc/mysql


5.2.2.3.13 Modificar configuración de apparmor para mysql. (En los 2 nodos)

Debemos cambiar la configuración de apparmor para darle a mysql acceso a la nueva localización de los ficheros.

Debemos modificar el fichero /etc/apparmor.d/usr.sbin.mysqld

vi /etc/apparmor.d/usr.sbin.mysqld


Y dejarlo configurado con la nueva ubicación de los ficheros. Debe quedar así:


Cluster19.png

Cluster20.png

Aplicamos los cambios con:

apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld

Realizamos este mismo proceso en el otro nodo del cluster.

5.2.2.3.14 Modificar archivos de configuración de mysql. (En 1 nodo)

Los enlaces simbólicos no funcionan con mysql, por eso necesitamos modificar archivos de configuración de mysql para cambiar las rutas de acceso a los archivos creado en el directorio /HDmysql.

Esto hay que realizarlo en el nodo que tiene montada la partición /HDmysql.

Modificamos el fichero my.cnf.fallback

vi  /HDmysql/etc/mysql/my.cnf.fallback


Deberá quedar así.


Cluster21.png

Ahora el fichero mysql.cnf.

vi /HDmysql/etc/mysql/mysql.cnf

Y quedará así.

Cluster22.png

El fichero mysqld.cnf.

vi /HDmysql/etc/mysql/mysql.conf.d/mysqld.cnf

Cluster23.png


Y por último el fichero my.cnf.

vi /HDmysql/etc/mysql/my.cnf

Y quedara de la siguiente manera. (datadir / log_bin / includedir)


Cluster24.png


Cluster25.png


Cluster26.png


5.2.2.3.15 Configuración del arranque de mysql. (En 1 nodo)

Vamos a configurar el arranque de mysql y le vamos a poner como condiciones que este en el nodo que este la ip flotante de mysql y que arranque después de que esté la ip.

pcs cluster cib mysql_cfg
pcs -f mysql_cfg resource create MYSQL ocf:heartbeat:mysql binary="/usr/sbin/mysqld" config="/etc/mysql/my.cnf"  datadir="/var/lib/mysql" pid="/var/run/mysqld/mysqld.pid" socket="/var/run/mysqld/mysqld.sock" additional_parameters="--bind- address=0.0.0.0" op start timeout=60s op stop timeout=60s op monitor interval=20s timeout=30s
pcs -f mysql_cfg constraint colocation add MYSQL with IP-MYSQL INFINITY
pcs -f mysql_cfg constraint order IP-MYSQL then  MYSQL
pcs cluster cib-push mysql_cfg
pcs status


5.2.2.3.16 Configuración del arranque de Asterisk. (En 1 nodo)
pcs cluster cib aster_cfg 
pcs -f aster_cfg resource create ASTER lsb:asterisk 
pcs -f aster_cfg constraint colocation add ASTER with IP-ASTER INFINITY 
pcs -f aster_cfg constraint order IP-ASTER then ASTER 
pcs cluster cib-push aster_cfg
pcs status


5.2.2.3.17 Mover los recursos a otra máquina. (En 1 nodo)

El crear 2 particiones separadas para el Asterisk y el mysql nos da la posibilidad de correr un servicio en cada máquina y tener los 2 nodos activos.

Para mover un recurso de nodo utilizaremos el siguiente comando en el nodo que está el recurso ejecutándose.

pcs resource move DRBDfsASTER

Esto crea restricciones locales para evitar que el recurso vuelva a este nodo (Puede tener prioridad de ejecución en este nodo y haría que volviera a este nodo automáticamente al estar online).

La restricción que crea banea el nodo para este recurso, si queremos quitar la restricción creada.

pcs resource clear DRBDFsAst



5.2.2.4 Instalación y configuración del Cluster hasta la versión VIVAit 3.3

.


Hasta la versión 3.3 de VIVAit , la instalación y configuración del cluster se hace de la siguiente forma:


Instalación y configuración del Cluster hasta la versión VIVAit 3.3




5.3 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

Para verificar los enlaces establecidos ejecutamos el siguiente comando en el terminal: sip show peers

Al ejecutar este comando obtenemos la salida:

Enlace Exterior.png

Las columnas Host y Port nos muestran las conexiones establecidas y nos informa de un posible problema de conexión.

Sabremos que no existe conexión cuando la columna Host tiene el valor Unspecified y en la columna Port aparece un 0 , a continuación se muestra un ejemplo:


Ejemplo no conexion.png



5.4 Grabación



5.4.1 Configuración de la grabación en la plataforma corporativa

Para que una llamada se grabe, lo primero de todo es que alguien tenga la capacidad de grabar. Esto se consigue diciendo al nodo que sea grabador. Esto provoca que el nodo llame al mixmonitor para grabar y se inserte un registro en el DAT_GRABACIONES. Esto no significa que ya las llamadas se vayan a grabar, ya que para eso tiene que ser procesadas por un nodo que sea grabador. Hay tres, llamémosle elementos, que se pueden grabar:

  • El nodo, es decir todo lo que el nodo enrute
  • Prerutas
  • Objetos: que son las extensiones, usuarios, grupos corporativos, etc.

Tenemos tres formas de grabar:

  • Grabar con beep periódico
  • Grabar sin beep periódico
  • Descartar grabación

Si de los tres elementos tenemos que uno grabe, ya sea con o sin beep periódico, esa llamada se va a grabar ya que son OR, en cuanto haya un elemento que diga que grabe se va a grabar.

Al igual pasa si tenemos que un elemento tenga descartar la grabación. La grabación no se inicia.

Referente al campo de Modo de grabación en infraestructura, este no se emplea para la grabación de corporativo, sino que solo tiene validez en ACD. Para grabación en el ACD hay que, como se ha dicho anteriormente poner un nodo que sea grabador y especificar un elemento de los tres que hay cual es el que se va a grabar.

Para que exista una grabación ha de existir un segmento asociado a esta. Los segmentos se tratan en las prerutas. Hay un campo es las prerutas que es Generar segmento al enrutar. Si está se generará el segmento del tipo de la preruta y su correspondiente grabación si esta está configurada. Si le decimos que no genere segmentos al enrutar y el sistema está configurado para que grabe, el recordCentral creará un tipo de segmento llamado externo para esa grabación. Podemos configurar si queremos que se cree o no ese segmento, para eso hay que modificar el fichero de configuración del recordCentral y poner un tiempo muy alto al campo $segmExternoMinSegs. También podemos configurar que segmentos queremos que se graben. Por defecto el recordCentral va configurado para que se graben todos los segmentos. Para decirle que solo grabe cierto tipo de segmentos hay que ponerlos los que queramos que si se graben en la variable $tiposSegmentoGrabar del fichero de configuración del recordCentral.


5.4.2 Como configurar la grabación bajo demanda

Para activar la grabación bajo demanda es necesario activar el MixMonitor.

En el Nodo hay que identificar Grabar por enrutamiento = Sin grabación.


Ejemplo activacion grabacion en nodo CORP-2.jpg



En el Nodo ACD y/o Corporativo es obligatorio que el campo Modo de grabación de infraestructura sea igual a Graba por petición.



NODO ACD-2.jpg


En la Campaña (asignar la cola a la campaña; si se pone el modo de grabación en la cola, no funciona **, ha de ir en la campaña o en el VDN) o en VDN el campo “Modo de grabación” debe ser igual a Grabación Bajo demanda inicio sin grabar ó grabando.


MODO DE GRABACION EN CAMPAÑA-2.jpg



El formulario de VIVAit Desk que se abra cuando entre la llamada que queremos grabar ha de tener los botones de grabación.


Ejemplo de formulario con botones de grabacion.jpg


Trazas VIVAit Desk:

gre evliniciarGrabacion infra=20 modo=10 esta=”6/Demanda sin grabar”

Para que la grabación bajo demanda esté bien configurada en la traza anterior los valores de infra y modo deben ser distintos de 0.


** Hemos visto que la grabación Bajo demanda en los Grupos ACD si funciona.

Para activarla hay que entrar en la configuración del Grupo ACD que queremos grabar y activar la grabación por enrutamiento:


Cap 1.jpg


Además indicamos en el modo de grabación: Grabación bajo demanda inicio sin grabar.


Cap 2.jpg


En la consola vemos los siguientes datos:


Cap 3.jpg

5.4.3 Comprobar que el servidor de grabación está 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 ningún resultado implica que tampoco esta activo.

5.4.4 Comprobar 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.

5.4.5 Comprobar 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.

5.4.6 Comprobar 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.

5.4.7 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.

5.4.8 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

5.5 Escuchas e intrusiones en asterisk

CallSpy es una aplicación elaborada para asterisk que permite a un usuario realizar escuchas e intrusiones en llamadas. En realidad tenemos dos aplicaciones en asterisk, CallSpy y CallSpyee.

5.5.1 CallSpy

Nota: Como mucho se pueden tener a dieciséis personas al mismo tiempo usando esta aplicación. 

Como hemos mencionado anteriormente, esta aplicación permite la escucha de llamadas y, opcionalmente, realiza la función de intrusión. Tiene tres opciones de configuración obligatorios que mostramos a continuación:

CallSpy(<tipoEspiado>,<expRegEspiado>,<parametrosConf>)

La opción <tipoEspiado> se refiere a que tipo de objeto que podemos espiar correspondiente, solo debe elegirse un único tipo:

  • c: escuchar una cola
  • v: escuchar un vdn
  • a: escuchar a un agente
  • e: escuchar extensión

La opción <expRegEspiado> representa el número de la cola, VDN, agente o extensión que queremos escuchar. Tiene que ser una expresión regular. La opción <parametrosConf> se refiera a los parámetros de configuración para la llamada que podemos espiar, se pueden combinar o juntar :

  • q: Desactiva el 'beep' al comienzo de cada nueva llamada.
  • v([value]): Ajusta el volumen en el rango -4 a 4 (más alto, mas volumen).
  • e: Habilita el que se pueda cambiar a otra llamada de la misma extensión.
  • w: Habilita el que se pueda activar la intrusión (whisper).

Una vez iniciada la escucha, solo falta que entre una llamada al objetivo que estemos espiando. Al iniciar la escucha, se puede hacer lo siguiente:

  • Pulsando # modifica el volumen de escucha.
  • Pulsando * cambia a una nueva llamada.
  • Pulsando 1 si esta habilitado, cambia a otra llamada de la misma extensión.
  • Pulsando 2 si esta habilitado, inicia la función de intrusión.
  • Pulsando 3 desactiva la función de intrusión.

5.5.2 CallSpyee (espiado)

Mediante esta aplicación indicamos los parámetros que permite a una llamada ser seleccionada para escuchar. Las opciones de configuración son:

CallSpyee([CID_NUM],[cola],[vdn],[agen],[exten]) 
Nota:No son parámetros obligatorios, por lo que no hace falta rellenar todos los campos pero si respetar sus posiciones separadas por comas.

La explicación de los parámetros es la siguiente:

  • CID_NUM: representa el call ID de la llamadas
  • cola:representa el número de la cola que se quiere espiar (${QUEUE} ).
  • vdn: representa el número del VDN que se quiere espiar (${VDN} ).
  • agen: representa el número del agente que se quiere espiar.
  • exten: representa el número de la extensión que se quiere espiar (${EXTENSION}) .

Por ejemplo si queremos escuchar todas las llamadas en las que participa una extensión determinada pondremos en la macro de extensiones:

exten => s,n,CallSpyee(,,,${EXTENSION}) 

5.5.3 Cambios para el dialplan de asterisk

El funcionamiento de este tipo de servicio conlleva un cambio en el dialplan de asterisk. En cada macro correspondiente se pondrá los diferentes CallSpyee para VDN, colas , extensiones y agentes. Pasos a seguir:

  • Paso 1. Creación de un código de intrusión para cada tipo según necesidad (cola, VDN, agente y

extensión).

Ejemplo MDtel:  declaramos como código de intrusión a Agente *44*NUMERO 
;========================================== 
;======== Intrusion a Agente 
;========================================== 
exten => _*44*X.,1,set(CadMarcar=intrusionEspiado) 
exten => _*44*X.,n,set(DesL=SERVICIO) 
exten => _*44*X.,n,set(datoServicio=^${EXTEN:4}) 
exten => _*44*X.,n,Goto(finMacro,1) 
Nota: En la tercera línea podemos observar la expresión regular que se le pasara al CallSpy correspondiente con el número marcado por el espia. 
  • Paso 2.Llamar a CallSpy con la configuración deseada.
Ejemplo MDtel:  llamada a CallSpy especificando que vamos a espiar una cola (la c del primer parámetro, con la
extensión introducida en el código de intrusión y con whisper, es decir, función de intrusión habilitada. 
;------------------------------------------------------------------------ 
; Intrusion a Espiado 
;------------------------------------------------------------------------ 
exten => intrusionEspiado,1,NoOp 
exten => intrusionEspiado,n,GotoIf($["${datoServicio}"=""]?colgar) 
exten => intrusionEspiado,n,CallSpy(c,${datoServicio},w) 
exten => intrusionEspiado,n(colgar),Hangup 
  • Paso 3. Llamar a CallSpyee con la configuración de las llamadas candidatas a ser escuchadas.
Ejemplo MDtel: 
exten => s,n,CallSpyee(,,,,${EXTENSION}) → Para extensiones 
exten => s,n,CallSpyee(,${QUEUE},,,) → Llamadas espiadas por cola 
exten => s,n,CallSpyee(,,${VDN},,) → Llamadas espiadas por VDN 



Volver al índice

5.6 Calendarios

Nota: En la versión de VIVAit 3.5 , Se tiene que instalar el nuevo servidor de DaviCal.

Para la configuración de los calendarios en la versión VIVAit 3.5 , se tiene que instalar el nuevo servidor DaviCal en una máquina aparte.

Se adjunta un manual para su instalación:


Manual de instalación de servidor de calendarios para VIVAit 3.5




Para la configuración de los Calendarios se hace uso de CalDAV, estándar de Internet que permite a un cliente acceder a información de planificación en un servidor remoto. Permite que varios clientes accedan a la misma información, facilitando la cooperación. Muchas aplicaciones, tanto clientes como servidores, son compatibles con este protocolo.

Si deseamos crear un calendario en la plataforma VIVAit podemos hacerlo siguiendo el siguiente enlace: Para comprobar que el servidor de calendarios funciona correctamente bastaría con cargar en la barra de direcciones la siguiente url: [|Calendarios]

http://${NODO.HOST}/dav/html/cal.php/calendars/${DAV.CUENTA}/${DAV.CALENDARIO}

donde,

  • NODO.HOST: es la ip del servidor calendar
  • DAV.CUENTA: hace referencia a la cuenta de usuario
  • DAV.CALENDARIO: hace referencia el nombre de la cuenta

Una vez que se carga la url sabremos que el servidor funciona correctamente si visualizamos lo siguiente:

Captura de pantalla de 2016-07-21 12 43 58.png


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
      - En la máquina donde esté instalado el servidor de calendarios apuntar a la IP de la BDTR (/var/www/dav/config.php)



Volver al índice

5.7 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


Ejemplo 30-vivait-desk.conf:

#  Default rules for rsyslog.
#
#            For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
local4.*            -/var/log/MDtel/vivait-desk.log
local5.*              -/var/log/MDtel/rastreo.log


Es muy importante comprobar que el servidor de syslog escucha por el puerto 514:

#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

# Enable non-kernel facility klog messages
$KLogPermitNonKernelFacility on

###########################
#### GLOBAL DIRECTIVES ####
###########################

5.8 Generación de un Core

Un Core es la memoria de un programa.

Para generar un Core rápido con Asterisk hay que hacer lo siguiente:

   Ejecutar ps aux | grep asterisk y coger el PID del programa
   gdb /usr/sbin/asterisk [PID]
   gcore [file]





6 puntos a reasignar

6.1 Servidor de grabación

6.1.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

6.2 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”.

6.2.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=


6.2.2 Resumen de significado de columnas en reporting histórico

Esta información se puede consultar en el siguiente enlace:

http://vivait-wiki.mdtel.net/wiki/vivait/index.php/Documentacion_de_usuario_VIVAit_Suite_3.3#Resumen_del_valor_de_las_columnas_que_aparecen_en_los_informes


6.2.2.1 Consideraciones adicionales

Los tiempos se insertan en el intervalo en el que se deja ese "estado", esto provoca que en un intervalo pueda ser mayor el tiempo ACD que el tiempo conectado.

* Ejemplo:

-Llamada: Duración 15 minutos Hora fin de la llamada 13:01
-Llamada: Duración 20 minutos Hora fin de la llamada 13:24
Suma de las duraciones de las llamadas para el intervalo 35 minutos tiempo
conectado del agente en el intervalo 30 minutos.
Cuando los periodos consultados sean mas amplios (diario, mensual) los
desfases tenderán a desaparecer.




Volver al índice


6.3 TBC (Translation by Chat)

La funcionalidad permite que dos interlocutores (a los que llamaremos “extranjero” y “agente”) puedan interactuar en una llamada telefónica independientemente del idioma en el que se expresen.

6.3.1 Requerimientos de usuario

Desde el punto de vista de usuario los requerimientos serán:

• Extranjero: Cualquier tipo de terminal telefónico (de VIVAit Call o externo) alcanzando un usuario de VIVAit Call;

• Agente: Usuario de VIVAit Call, con terminal telefónico en VIVAit Call y portal de usuario; el entorno más unificado se consigue si el terminal telefónico es Web Call


6.3.2 Funcionamiento a nivel de usuario

1. Llamadas entrantes a grupos o servicios con traducción activada por defecto: En estos casos el agente no tendrá que hacer nada y la llamada dispondrá de servicio de traducción; es típico en grupos ACD


2. Llamadas salientes realizadas por el agente a un extranjero: En tal caso el agente realizará la llamada anteponiendo la facilidad *14# (ejemplo *14#3140) o la configurada a tal efecto en cada instalación


3. Llamadas establecidas para las que se desea activar TBC:

a.	En el caso de Web Call el agente dispondrá de un botón en el control de llamada que le servirá para activar TBC; la activación pasa por una autotransferencia directa de la llamada
b.	En el caso de otros terminales el usuario deberá realizar una transferencia directa a si mismo (se usa para ello llamada a  *14*)


El funcionamiento general una vez establecida una llamada con servicio TBC será:


• El extranjero habla en su idioma y escucha audios en su idioma; como se ha indicado anteriormente, en el lado del extranjero no es necesario ninguna herramienta adicional al terminal telefónico, que podrá ser interno o externo a VIVAit Call


El agente

Para la recepción:

•	Escucha el audio del extranjero (en el terminal)
•	Lee el texto transcrito en el idioma del extranjero
•	Lee el texto traducido en el idioma del agente


Para la emisión:

•	Escribe en su idioma
•	Lee el texto traducido al idioma del extranjero
•	Tiene opción de reproducir el audio que ha escuchado el extranjero



6.3.3 Funcionamiento a nivel de VIVAit Call

A nivel de VIVAit Call, los elementos principales involucrados en el servicio son:

• mdtap: Con sus componentes chan_mdtap e intz_tap se encargará de:

chan_mdtap:

•	Captura el audio
•	Reenvía a intz_tap
•	El audio pasa al otro extremo


intz_tap:

Para speech to text

•	Invoca al servicio de conversión de audio a texto configurado y lo envía
•	Recibe el texto y otros datos y los inserta en BDTR


Para text to speech

•	Periodicamente (polling) comprueba si hay mensajes de tipo de contenido audio
•	Recupera la URL
•	Invoca al servicio de conversión de texto a audio configurado y lo envía
•	Recibe el audio y lo inserta en la conversación en sustitución del audio del agente


Portal de usuario/Web Call

•      Cuando se abre pestaña de TBC sincroniza mensajes https://172.25.128.253/Vivait-FonBO/api/recuperarId
 •     Periodicamente (polling) pide nuevos mensajes de TBC del extranjero a FonBO https://172.25.128.253/Vivait-FonBO/api/listaMensajesUsuario?lastId=85&idioma=es
•     Envía mensajes de texto a FonBO https://wwv.mdtel.es/Vivait-FonBO/api/insertaMensaje?hayTraduccion=true&idiomaDestino=fr


FonBO:

•	Responde a polling de Portal de usuario/Web Call
•	Envía mensajes a traducir al servicio de traducción texto a texto, solo si el idioma del agente (configurado) y el idioma del extranjero (típicamente detectado) son diferentes; lo realiza para las traducciones en ambos sentidos
•	Recibe mensajes traducidos y los inserta en BDTR
•	Envía mensajes de texto al servicio de Text to Speech
•	Recibe el audio, lo almacena e inserta en BDTR (una URL)


6.3.4 Puesta en marcha

Para disponer de la funcionalidad será necesario disponer de:


• Base de datos actualizada con tabla DAT_MENSAJES_IA y COM_USUARIOS

• Fonbo versión xxxx

• Web Call versión 2.0.0 (para esta funcionalidad, esta versión de Web Call requerirá otros cambios en BBDD por otras funcionalidades implementadas)

• Chan_mdtap e Intz_Tap funcionando


La configuración cargada por defecto en el sistema permite la activación con mucha facilidad de las funciones de:


• Casuística 1: Llamadas salientes realizadas por el agente a un extranjero; el agente marcará *14#num_Destino


Tbc1.PNG


Es la facilidad con E_CODIGO_FACILIDAD = 800 (transcripción de número de teléfono).


Tbc2.PNG


La numeración está definida por prerutas, una por categoría


Tbc3.PNG



• Casuística 2: Llamadas establecidas para las que se desea activar TBC; el agente pulsará el botón de “traducción simultánea”

Tbc4.PNG




6.4 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.4.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.4.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.4.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.4.3 Secciones de utilidad en nimitz.ini



6.4.3.1 Configuración del puesto de agente



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"

puerto="Nº puerto" 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 "

puerto="Nº puerto" 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. Cuando usamos el parámetro pruebas=1 permitimos abrir más de una sesión de VIVAit Desk; esto puede provocar que el programa no responda y estemos obligados a resetear la aplicación

puesto="Nombre puesto"

Sección [trazas] nivel=3 (indica el nivel de trazas suministrado por el sistema)

archivo=1 (indica que se generará un fichero con las trazas del sistema)

consola=0 (Si el nivel de trazas es 3 no debemos utilizar el valor consola=1, impedirá que arranque el desk)

sobreescribir=1 Se genera un fichero de trazas para la sesión activa. Cuando el desk se cierra se genera un fichero nuevo perdiendo las trazas de la sesión anterior.

sobreescribir=0 se genera un fichero de trazas cuando el agente abre el desk y cuando cierra la sesión y abre una nueva se van acumulando las trazas en el mismo fichero.

Activación de generación de ficheros de trazas "viva-desk.log" en carpeta de aplicaciones

6.4.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.4.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.4.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

6.5 Integraciones con servicios externos




6.5.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"


6.5.2 Reuniones virtuales con Openmeetings



OpenMeetings es un sistema de vídeo web-conferencia en tiempo real. Usando recursos como audio (micrófono), vídeo (cámara web), posibilidad de subir y convertir presentaciones (en PDF , PPT o ODP que se convierten a Flash), compartición de la pantalla de tu ordenador, o pizarra digital compartida, panel de administración, posibilidad de grabar las sesiones… y completo soporte multiplataforma, es decir, que aparte de poder grabar las sesiones, se puede compartir un escritorio también desde una máquina Linux.

Para instalar OpenMettings debe seguir el [| manual de Instalación de Openmeetings]


6.5.3 Integración de portal usuario de VIVAit Call Web Microsoft Teams




La integración de VIVAit Call Web con MS Teams se realiza en tres pasos; dos de ellos han de ser realizados íntegramente por el cliente puesto que requieren realizar modificaciones en su entorno de gestión de Microsoft Azure y Teams.


Teams-esquema.png


A continuación se muestra que debe hacer el administrador de Teams y de Mdtel para la integración con Ms Teams , los pasos consisten en:

Responsable Pasos
Administrador de Teams y Mdtel Generar el archivo .zip con todos los elementos requeridos para una integrar una nueva aplicación en MS Teams. Este archivo .zip es diferente para cada cliente de VIVAit Call Web y tiene que ser generado para cada caso


PASOS:

Generar archivo ZIP con todos los elementos

El paso ha de ser realizado por un administrador de Teams y mdtel

Debemos disponer de los valores :

  • AAD_APLICACION_ID
  • AAD_CLAVE_EXPIRA
  • AAD_CLAVE_VALOR
  • AAD_CLAVE_ID


Estos datos serán proporcionados a mdtel, que generará un archivo ZIP

VIVAit-call-web-empresa-vivait-manifest.zip


Para crear este archivo .zip, se parte de un zip base en el que modifican los valores que se indican de manifest.json :


  • staticTabs.contentUrl (debe apuntar a la web específica del cliente).
  • validDomains (lista de dominios a los que se permite acceder: el dominio de la web del cliente).
  • webApplicationInfo.id <AAD_APLICACION_ID>
  • webApplicationInfo.resource <AAD_URL_APLICACION_ID>


También con estos valores debe modificarse la configuración de serCen:


  • ws_implementacion.aad_app_client_id = <AAD_APLICACION_ID>
  • ws_implementacion.aad_app_client_secret_cifrado = <AAD_CLAVE_VALOR> (CIFRADO)
  • ws_implementacion.aad_app_secret_expire = <AAD_CLAVE_EXPIRA>


1- A partir de aquí, interviene un administrador de MS Teams.


Acceder a: https://admin.teams.microsoft.com


Teams-wiki.png



2- Pulsar en “Administrar aplicaciones” y “Cargar”, donde se subirá el archivo que habremos creado con los datos obtenidos en Azure Active Directory:

                               VIVAit-call-web-empresa-vivait-manifest.zip


Integración de portal usuario de VIVAit Call Web Microsoft Teams desde el cliente

A continuación se muestran los pasos que han de ser realizados íntegramente por el cliente puesto que requieren realizar modificaciones en su entorno de gestión de Microsoft Azure y Teams , los pasos consisten en:


Responsable Pasos
Administrador Azure Configurar en Azure AD para que reconozca a VIVAit Call Web. Es el paso más complejo
Usuario Incorporación de la nueva aplicación en Microsoft Teams


Paso 1: Configurar en Azure AD

El proceso de configuración en Azure AD es, como se ha indicado anteriormente, el más complejo. Ha de ser realizado íntegramente por un administrador de Azure


Las acciones a realizar son:


  • Administrar Azure Active Directory / Registros de aplicaciones / Nuevo registro



Teams-ad1.png



  • Rellenamos el nombre de la aplicación. La cadena “empresa” debesustituirse por un acrónimo de la empresa que estamos integrando. No debe rellenarse el campo “URI de redirección”


Teams-ad2.png



  • Al pulsar en “Registrar”, almacenamos el valor que aparece en “Id de aplicación (cliente)” con la etiqueta <AAD_APLICACION_ID>, porque será necesario en pasos posteriores


Teams-ad3.png


  • Entramos en "Agregar un certificado o secreto"


Teams-ad4.png


  • Pulsamos en “Nuevo secreto de cliente” y:

o En Descripción, rellenamos: Clave de acceso

o En expira: 24 mesesPulsamos el botón “Agregar” y obtenemos:


Teams-ad5.png


Es necesario tomar nota para pasos posteriores de los siguientes datos:


Datos Descripción
Expira Es la fecha en la que expirará la clave creada y será necesario repetir este proceso. Conviene que el periodo de validez sea lo más grande posible y, por ello, al agregar indicamos un periodo de 24 meses. El valor lo almacenamos con la etiqueta

<AAD_CLAVE_EXPIRA>.

Valor Es el valor de la clave o secreto. Hay que obtenerlo obligatoriamente copiando y pegando porque lo que se ve es incompleto. El valor lo almacenamos con la etiqueta <AAD_CLAVE_VALOR>.
Id de Secreto Es el identificador de la clave o secreto. Hay que obtenerlo obligatoriamente copiando y pegando porque lo que se ve es incompleto. El valor lo almacenamos con la etiqueta <AAD_CLAVE_ID>.


  • Entramos en "Exponer un API"


  • Pulsamos en “Agregar un ámbito”


  • Rellenamos “URI de id. de la aplicación”:

- Propuesto por defecto: api://bfe5e58a-c1d5-4736-8996-0d6b29346d6b

- Rellenado :api://empresa.vivait.es/bfe5e58a-c1d5-4736-8996-0d6b29346d6b


La cadena “bfe5e58a-c1d5-4736-8996-0d6b29346d6b” se incluye a modo de ejemplo, debiendo ser rellenada por el id de aplicación obtenido para el caso




Teams-ad6.png


  • Pulsamos “Guardar y continuar”



  • Pulsamos botón “Agregar ámbito”. Nos aseguramos que el estado del ámbito es “Habilitado”


Teams-ad7.png



Teams-ad8.png


-Ahora tenemos que pulsar “Agregar una aplicación cliente”

-Rellenamos “Id. de cliente”:(por ejemplo) 1fec8e78-bce4-4aaf-ab1b-5451cc387264

-Activamos el check del ámbito

-Pulsamos el botón “Agregar aplicación”

Teams-ad9.png


Con esto, autorizamos a “Teams mobile” y a la aplicación Teams de escritorio


-Es necesario repetir lo mismo con “Id. de cliente”: (por ejemplo) 5e3ce6c0-2b1f-4285-8d4b-75ee78787346. Con ello se autoriza a la aplicación web de Teams

-El resultado será similar a la siguiente ilustración:



Teams-ad10.png


-Entramos en "Permisos de API" y pulsamos en “Agregar un premiso”

-Pulsamos en “Microsoft Graph”


Teams-ad11.png



Teams-ad12.png


-Añadimos “profile” y pulsamos botón “Agregar permisos”


Teams-ad13.png


-Debe quedar:


Teams-ad14.png


-Ahora pulsamos en “Conceder consentimiento de administrador para ...”



Teams-ad15.png




-Ahora pulsamos en “Conceder consentimiento de administrador para ...”



Teams-ad16.png


-Pulsamos en “Sí” y nos debe quedar


Teams-ad17.png


Con estos pasos, finaliza la configuración de la aplicación en Azure Active Directory.



Paso 2: Incorporación de la nueva aplicación en Microsoft Teams


El paso 2 será realizado por cada usuario


A partir de ese momento, los usuarios de Microsoft Teams pueden incorporar la aplicación en: https://teams.microsoft.com



Teams-ad18.png

6.6 Marcador Predictivo




La marcación, como la conocemos hasta ahora, comienza en la tabla de contactos del portal. MotorSal cambia los contactos del portal en la Base de Datos, para que vayan pasando por distintos estados. El cambio de estado de planificable a planificado se hace por prioridad de antigüedad→ los más antiguos tienen mayor prioridad. En el nuevo marcador predictivo aparece un parámetro nuevo “N_PARAM13", del MotorSal, que indicará el porcentaje de contactos antiguos y el porcentaje de contactos nuevos que cambiarán de planificables a planificados.

  • Un marcador predictivo genera llamadas automáticas en entornos de contact center, orientando el modelo a conseguir la mayor productividad posible (agentes en conversaciónla mayor parte del tiempo).
  • El objetivo del sistema es conectar a clienetes llamados con agentes disponibles, consiguiendo que los agentes estén el menor tiempo posible disponibles.
  • Los marcadores predictivos mejoran su precisión con un volumen alto de llamadas. Se considera que mejoran su eficacia a partir de la existencia de 20 agentes simultáneos.
  • La unidad de medida del tráfico utilizada es el ERLANG: Un agente hablando todo el tiempo.


6.6.1 Arquitectura




ArquitecturaPP.jpg


En el siguiente equema se muestan los módulos que intervienen en el Marcador Predictivo:


ArquitecturaMODULOS.jpg

6.6.2 ¿Como funciona un marcador predictivo?



6.6.2.1 Conceptos y funcionamiento general




Un marcador predictivo se ocupa del cálculo del volumen de llamadas requeridas para conseguir la mayor productividad. Esto ayuda a que los agentes estén en conversación el mayor tiempo posible. Este tipo de marcación es ideal para campañas que tengan más de 20 agentes simultáneos. Mientras más agentes, el algoritmo de predicción funciona mejor. En campañas pequeñas el riesgo de un algoritmo de predicción agresivo puede ser el de un incremento en los abandonos por parte de los clientes (los clientes contestan, pero del otro lado no hay agentes disponibles, y cuelgan).

La variable más crítica en un marcador predictivo es la qie indica el número de intentos que han de generarse en el siguente periodo.

Conceptualmente un marcador predictivo funciona cuando hay una gran cantidad de agentes.

El marcador predictivo funciona utilizando conceptos estedísticos.

El marcador predictivo saliente tiene en cuenta:

  1. El número de agentes presentes no pausados → define la capacidad existente de cursar tráfico saliente.
  2. La duración media de las llamadas incluyendo el tiempo administrativo (AHT), el sistema observa la desviación típica → define el número de ntentos a lanzar.
  3. Es necesario definir la probabilidad de fallo en la que deseamos trabajar (entenderemos por fallo la situación que se produce cuando un cliente descuelga el teléfono y no encuentra un agente disponible).

Con los tres parámetos anteriores podemos conocer el tráfico que debemos lanzar, teniendo el valor del parámetro "intentos para obtener 100".

El sistema determina cuanto tráfico es capaz de generar, en función del número de agentes disponibles.

6.6.3 Modelos de marcación predictivos



Básicamente existen cuatro modelos de marcación:

  1. CONSERVADOR: No predice, cuando un agente se queda libre lanza el número de intentos necesarios para conseguir el número de contactis definidos. Es el más sencillo de todos. Cualquier modelo se convierte en coservador si no se dan las condiciones para cumplir con los objetivos buscados. Se suele activar cuando hay pocos agentes logados. Existen parámetros que definen cuando un modelo diferente se convierte en conservador; por ejemplo, el número de agentes. En el modelo conservdor solo se cargan algunos valores en DAT_MUESTRAS_COLAS_PREDICTIVAS: nº de agentes (no pausados no reservados), intentos 100contactos real y tasa de fallo calculada. → También denominado predictivo básico; usa una configuración fija de llamadas salientes cada vez que un agente queda libre.
  2. MANUAL: Los parámetros de ACD_COLAS rellenan las variables de la tabla DAT_TR_COLAS. No se tiene en cuenta la evolución del entorno. No se adapta con el paso del tiempo, hay que ir reconfigurándolo constantemente. → El modelo usa como variables solo los parámetros de configuración.
  3. SOLO SALIENTE: Los agentes están logados en una sola cola de saliente predictivo, todos con la misma prioridad.
  4. MEZCLA: Los agentes se conectan a más de un grupo ACD y éstos pueden ser de cualquier tipo (entrantes o salientes).

Los modelos "asumen" que los agentes tienen la misma prioridad, que están logados en el mismo número de colas y además que la asignación de los agentes a las colas es uniforme → Las llamadas SALIENTES deben tener mayor prioridad que las entrantes.

El sistema permite cambiar una campaña de un modelo a otro.

A continuación indicamos los cambios en lo módulos / demonios existentes:

MotorSal:

Este demonio mueve contactos a DAT_INTENTOS_MARCADOR para generar intentos. Los intentos los lee MyACDSuperV, que pasa los intentos generados por MotorSal a Asterisk.

La configuración de MotorSal añade escalabilidad permitiendo:

  1. Divisor planificables → Ratio entre planificables y planificados
  2. Tener más de un MotorSal (cuando leemos más de una campaña).


MyACDSuperV

Este demonio maneja COLAS.

Se cambia el nombre de dos campos:

  • E_TIPO_COLA → E_TIPO_COLA_FORZADA
  • ID_COLA → ID_COLA_FORZADA

Además, se introduce un nuevo campo:

  • ID_COLA_USADA que informa de la cola usada.


BasedeDatos

En la base de datos se guardan medidas específicas → se trabaja con coma fija.


Nuevos demonios:


Motor_Predi → Motor de predicción (precide el ritmo de llamadas necesario para obtener los “contactos” que hemos definido) Definirá los intentos que se van a generar, para ello controla el funcionamiento de MyACDSuperV → MARCA EL RITMO AL QUE SE GENERAN LOS INTENTOS.

Lee datos de la tabla ACD_COLAS y, en función de los parámetros configurados, genera variables de salida en la tabla DAT_TR_COLAS para modular el funcionamiento de MyACDsuperV, además rellena los datos de la tabla DAT_MUESTRA_COLAS_PREDICTIVAS que “funcionará” como histórico de lo que ha ido pasando.

6.6.4 Parámetros




Cada modelo de predictivo utiliza un conjunto de parámetros.

PAR1: Intentos 100 contactos. Cuantos intentos tengo que hacer para obtener 100 contactos. Se utiliza en los modelos conservador y manual.

PAR2: dato booleano. Indica, para cada intento, si se utiliza el anterior (PAR1). Hay algoritmos que pueden calcular esto, pero con el parámetro 2 pondremos el valor manualmente.

PAR3: Indica el umbral del nº de contactos x unidad de tiempo generados, por debajo del cual el modelo de la campaña cambia a conservador. Se utiliza en modelos manuales, solo saliente y mezcla.

PAR4: Nº de agentes presentes (logados no pausados) reservados. Resta capacidad disponible. Se utiliza en modelos solo saliente y manual.

PAR5: Umbral mínimo de agentes presentes (logados no pausados ni reservados). Si no se llega a este umbral mínimo el sistema utilizará el modelo conservador.

PAR6: Probabilidad de fallo que aceptaremos. Se utiliza en solo saliente, manual y automático. Estará entre 0 y 1 (para el cálculo se multiplica por 1.000.000 para tener un valor con 4 decimales).

PAR7: Tiempo de servicio previsto. Se utiliza cuando no existen datos, por ejemplo, en un arranque de servicio. Se utiliza en el modelo manual, y en el resto de modelos cuando hay pocas llamadas. Motor_Predi “decide” cuando utiliza el tiempo de servicio previsto calculado y cuando utiliza el que hemos configurado en PAR7.

PAR8: Tiempo disponible que se les asigna a los agentes, a pare del tiempo administrativo.

Parámetros del modelo MEZCLA:

PAR9: Tiempo de servicio.

PAR10: Nivel de servicio.

6.6.5 Variables




Cada modelo de predictivo utiliza una variables que se encuentran en la tabla DAT_TR_COLAS:

VAR1: Es una marca de coherencia de uso interno. Se utiliza para saber que las variables las “escribe” “quien” debe. Si la marca no es correcta implica que el sistema funciona en modo conservador.

VAR2: Tiempo de servicio calculado. En modo manual se copia de ACD_COLAS. En modo Solo Saliente y Mezcla es un dato calculado. Con pocas llamadas es copiado.

VAR3: Tiempo de servicio corregido. Sumando el tiempo disponible (PAR8).

VAR4: Nº de agentes que estoy utilizando para calcular la capacidad (presentes, no pausados y no reservados).

VAR5: Tasa de fallo calculada (nº de abandonadas x 1.000.000/nº de contactos).

VAR6: Intentos 100 contactos que he calculado en un periodo de tiempo que se ha configurado. Se calcula en los modos Solo Saliente y Mezcla, en Manual es un dato copiado.

VAR7: Nº de contactos/hora calculados. En el tiempo permite calcular el tráfico medio a generar.


Variables para el modelo Mezcla:


VAR8: Suma de tráficos ofrecidos en las distintas colas no predictivas (en centésimas de Erlang).

VAR9: Tráfico cursado en las colas no predictivas.

VAR10: Llamadas totales por hora, incluye las abandonadas.

VAR11: Llamadas hora en conversación.

VAR12: Nº de agentes necesarios para ofrecer el nivel de servicio.

VAR13: Nº de colas No predictivas compartidas.

VAR14: Nº de colas predictivas compartidas.

6.6.6 Nuevas tablas




6.6.6.1 DAT_MUESTRAS_COLAS_PREDICTIVAS




Constituirá el histórico del marcador predictivo.

Los campo y su explicación son los siguientes:

Campo Tipo de dato Descripción
* D_HORA datetime Hora normalizada para muestreo
* ID_COLA int(11) Cola a la que se refieren las medidas
* ID_ALGORITMO_PREDICTIVO int(11) Algoritmo predictivo configurado al obtener la medida
* N_PREDIC_PARn int(11) Valor configurado para PARn al obtener la medida
* N_PREDIC_VARn int(11) Valor de VARn generado por motorPredi
* N_PREDIC_PERIODO_INTENTOS int(11) Periodo en segundos analizado para calcular intentos100Contactos
* N_PREDIC_INTENTOS int(11) Número de intentos generados en el periodo anterior
* N_PREDIC_CONTACTOS int(11) Número de contactos obtenidos en el periodo anterior


En el siguiente bloque se encuentran contadores de intentos agrupados por estado. Todos ellos suman N_PREDIC_INTENTOS.

En función del estado el intento se contabiliza como contacto según contenido en /**/

Campo Tipo de dato Descripción
N_PREDIC_SALIENDO int(11) /* no intento, no contacto */
N_PREDIC_COLA int(11) /* intento, contacto */
N_PREDIC_CONVERSACION int(11) /* intento, contacto */
N_PREDIC_COMPLETADA int(11) /* intento, contacto */
N_PREDIC_OCUPADO int(11) /* intento, no contacto */
N_PREDIC_NO_CONTESTA int(11) /* intento, no contacto */
N_PREDIC_PROBLEMAS_RED int(11) /* intento, no contacto */
N_PREDIC_NUMERO_MAL int(11) /* intento, no contacto */
N_PREDIC_RECHAZADA int(11) /* intento, no contacto */
N_PREDIC_ABANDONADA int(11) /* intento, no contacto */
N_PREDIC_FAX int(11) /* intento, no contacto */
N_PREDIC_MAQUINA int(11) /* intento, no contacto */
N_PREDIC_ROBINSON int(11) /* no intento, no contacto */
N_PREDIC_CADUCADO int(11) /* no intento, no contacto */
N_PREDIC_CAMPANNA_CERRADA int(11) /* no intento, no contacto */
N_PREDIC_DIRIGIDO_NO_AGENTE int(11) /* no intento, no contacto */
N_PREDIC_REPROGRAMADO int(11) /* intento, contacto */
N_PREDIC_PERIODO_TRAFICO int(11) Periodo en segundos analizado para calcular tiempo medio de servicio
N_PREDIC_LLAMADAS_NUM int(11) Número de llamadas en el periodo analizado

Este valor se refiere a las llamadas sumadas en los tres valores posteriores

N_PREDIC_TCONVERSACION int(11) Suma de los tiempos de conversación para esas llamadas en segundos
N_PREDIC_TADMINISTRATIVO int(11) Suma de los tiempos administrativos para esas llamadas en segundos
N_PREDIC_TSERVICIO int(11) Suma de los tiempos de servicio para esas llamadas (Tconv + Tadmin) en segundos
N_PREDIC_STD_TSERVICIO int(11) Desviación estándar de los tiempos en servicio x10.000
N_PREDIC_LLAMADAS_TOTALES int(11) Número de llamadas (contactos) totales tramitadas por el grupoAcd.
N_PREDIC_TSERVICIO_X_LLAMADA int(11) Tiempo medio de servicio en segundos
N_PREDIC_TRAFICO_CURSADO int(11) Tráfico (expresado en centésimas de Erlang) cursado en las N_PREDIC_LLAMADAS_TOTALES llamadas
N_PREDIC_AGENTES int(11) Agentes presentes
N_PREDIC_AGENTES_OCUPACION int(11) Grado de ocupación de los agentes presentes (x10.000)
Los siguientes contadores se utilizan en el modelo MEZCLA.
N_PREDIC_PERIODO_TRAFICO_ENTRADA int(11) Sólo se usa en grupos ACD de tipo mezcla. Indica en qué periodo en segundos se ha hecho el análisis de los grupos compartidos.
N_PREDIC_AGENTES_ENTRADA int(11) Número de agentes requeridos en los grupos ACD compartidos para dar servicio según los parámetros de nivel de servicio.
N_PREDIC_PCT_CONTACTOS_SALIDA int(11) Coeficiente (x1.000.000) aplicado al tráfico a generar en un grupo ACD predictivo en base a que los agentes están compartidos en otros grupos ACD predictivos.

Las nuevas tablas de la Base de DAtos tienen la siguiente estructura:

Esquema marcador.jpeg


6.6.7 Particularidades del modelo mezcla




En el modelo mezcla asumimos que los agentes se conectan a las mismas colas.

Las colas de PREDICTIVO debemos configurarlas de forma que tengan mayor prioridad.

Modelo Mezcla.jpg

  • Fase 1: Observamos cuantoa agentes disponibles tenemos (no reservados).
  • Fase 2: Calculamos el tráfico cursado en grupos ACD NO PREDICTIVOS; tenemos que tener en cuenta las llamadas cursadas y las abandonadas. Además observaremos a qué colas ACD están conectados los agentes.
  • Fase 3: Se calculan los agentes necesarios para atender el tráfico NO PREDICTIVO.
  • Fase 4: El tráfico se reparte entre los agentes sobrantes.

De los datos obtenidos en estas primeras fases el sistema proporcionará el número de agentes necesarios para cada una de la colas de predictivo, este número de agentes constituye el dato de VAR4 (nº de agenetes presentes no reservados y no pausados).

El tráfico de predictivo se reparte equitativamente entre los agentes disponibles, en términos de minutos/hablados.

Si en algú momento el modelo MEZCLA genera un fallo, no cambiará al modelo conservador, simplemente no generará llamadas → aplica el criterio "si hay dudas no llamo".

En el arranque del modelo los datos de tiempo de servicio y de intentos 100contactos se obtienen de los parámetros PAR7 y PAR1.

6.6.7.1 Escalabilidad




El marcador predictivo necesita conectarse a una base de datos, para obtener datos, lee de una tabla y escribe en otra, pero no necesita muchos datos para poder funcionar.

En entornos grandes se puede tener una réplica de la base de datos, con pocos datos, una para leer y otra para escribir. Además, en estos entornos, se podrían tener varios Motor_Predi.

6.6.7.2 Límites al sistema




Quizá fuesen necesarios "topes" al número máximo de intentos en base a un porcentaje calculado a partir de la capacidad del sistema.

El parámetro N_Maxal está en la tabla ACD_COLAS e indica el número máximo de llamadas salientes que soporta el sistema.

Quizá se incluya un nuevo parámetro técnico → Tope de intentos 100 contactos.

Documentación Marcador Predictivo


6.7 Canales digitales en VIVAit Suite

Se incluye enlace a documentación en formato .pdf a canales digitales, actualmente correo electrónico

Documentación canal correo electrónico




Volver al índice


La arquitectura general de VIVAit Suite para canales digitales es la reflejada a continuación



Mcan1.png


Los componentes reflejados en verde en el esquema de la arquitectura son componentes externos a VIVAit Suite.

Los elementos principales que aparecen en la arquitectura de VIVAit Suite para la implementación de canales digitales serán:


  • Plataforma: Tipo de comunicación concreta que estableceremos; actualmente las posibilidades son:


- Tareas

- Correo

- Whatsapp

- Telegram


  • Proveedor: Identifica el servicio a través del cual podremos acceder a las plataformas; actualmente son:


-VIVAit: El acceso a la plataforma se realiza directamente con tecnología VIVAit

-Messagebird: Proveedor de accesos a servicios como Whatsapp y Telegram (VIVAit no puede conectarse directamente a estos servicios por política de estas empresas)


  • VIVAit Mcan: Nuevo demonio de multicanalidad que hace el tratamiento específico de los canales digitales


  • Bot: En los nuevos canales digitales, una conversación podrá ser tratada previamente por un elemento automático (bot) que automatice acciones o enrute en base a diferentes parámetros.


  • Chan_sit: Módulo de asterisk desarrollado por mdtel que permite insertar una interacción digital como una llamada más dentro del sistema; es el elemento que inserta "llamadas" que no son son de voz dentro de asterisk


  • Mqtt: Protocolo de intercambio de mensajes entre MCan y resto de VIVAit Suite (Chat_Sit y VIVAit Cti). VIVAit Suite prevé la instalación de un servidor Mqtt en su infraestructura


  • Tomcat: Los agentes dispondrán de un complemento web en la barra de agente; la parte de servidor de dicho complemento residirá en un Tomcat


  • Formdesk: Formulario específico de VIVA desk para tratamiento de correo; será muy habitual iniciarlo minimizado


  • Mailform: Complemento web de formdesk que presenta al agente toda la gestión del correo recibido; se podría entender que sustituye al formulario de VIVA desk


El canal correo abre un formulario “de desk” que no es el que maneja el correo
El canal correo electrónico también utiliza formulario web en agente


Otros conceptos relevantes que aparecen en la arquitectura son:


  • Conversaciones: De la misma manera que existen conversaciones en voz, existirán conversaciones en canales digitales, incluso en el canal correo electrónico.

Una conversación vendrá definida por:

- Un origen

- Un destino

- No se ha producido cierre ó

- No se ha vencido el tiempo de salvaguarda


Los canales digitales utilizan el concepto de conversación, con un inicio y un final


6.8 Principales elementos funcionales

6.8.1 Mcan

Mcan es un demonio desarrollado por mdtel e integrado en la arquitectura deVIVAit Suite que permite la integración de canales digitales diferentes de la voz dentro del sistema.

Así pues, mcan :


  • Detecta la existencia de interacciones digitales que han de entrar a VIVAit Suite


  • Proporciona un mecanismo de encolamiento previo (la terminología “cola previa” será ampliamente utilizada), que maneja la posibilidad de que existan un número muy alto de interacciones digitales que no habrán de estar en “cola asterisk” directamente (imaginemos un buzón de correo electrónico al que le entra Spam)


  • Proporciona mecanismos de automatización de tratamiento:

- Mensajes de bienvenida

- Mensajes de paciencia

- Bots


  • Entrega interacciones cercanas a su tratamiento en el tiempo a asterisk (vía el módulo chan_sit) para ser encoladas


mcan proporciona control de flujo, implementa cola previa


6.8.1.1 Diagnósticos y comprobaciones mcan

Comprobación de estado

Para comprobar si mcan está activo ejecutaremos el comando:


/etc/init.d/vivait-mcan status


el resultado esperado será:

vivait-mcan is running


Diagnósticos básicos


Para visualizar los diagnósticos básicos de mcan ejecutaremos el comando:

nc localhost 1124


Dicho comando nos mostrará las estadísticas más importantes sobre el funcionamiento del demonio mcan


Mcan2.png


Trazas


Las trazas de mcan son almacenadas en el fichero /var/log/vivait-mcan.log


Mcan3.png



Fichero de configuración


El fichero vivait-mcan.conf está ubicando en /etc/MDtel



6.8.2 Entorno de agente

Para los canales digitales (centraremos ejemplos y casos en interacciones de correo electrónico), la experiencia de agente se verá potenciada con el uso de nuevas herramientas

Recordemos que en el caso de interacciones digitales, el agente tendrá configurada una capacidad que le permitirá poder atender más de una interacción simultáneamente (de voz solo una), consumiendo cada interacción entrante un esfuerzo (la voz consume todo). Una vez sobrepasado el esfuerzo máximo no entrarán más interacciones al agente


Las herramientas del agente para los entornos de canales digitales serán:

  • Formulario específico de VIVA desk de canal digital, que no solo estará adaptado a las realidades de ese canal (por ejemplo deberá presentar ventana de chat), sino que podrá invocar a herramientas específicas que potencien la experiencia de agente.
  • Formulario externo (pero perteneciente a VIVA it Suite) de canal digital, que permitirá al agente gestionar la interacción completa (ignorando incluso el formulario de VIVA desk)


Por ejemplo, para el canal correo existe un formulario externo específico, basado en web y denominado mailform, cuyo aspecto se muestra a continuación


Mcan4.png



Este formulario web está integrado a nivel CTI con VIVA it Suite, por lo que las acciones que se realicen influyen en el funcionamiento el sistema; por ejemplo si el agente transfiere pasará a estar disponible en VIVA desk


Si bien en este momento no vamos a documentar completamente mailform, si indicaremos sus principales funciones:


  • Se abre a la entrada de una interacción en el agente
  • El agente dispone a la izquierda de un histórico de interacciones de correo con el cliente


Mcan5.png


  • El agente puede realizar acciones de responder, transferir, aparcar, cerrar


Mcan6.png


Si el agente responde dispondrá de plantillas y un entorno de edición de email (Se adjunta imagen)


Mcan7.png


Desde un punto de vista técnico, aparece un nuevo entorno de definición del funcionamiento de ciertos parámetros asociados al agente, que se configurarán en un fichero “.ini” cuyo nombre coincidirá con el ejecutable del VIVA Desk


Mcan8.png


El contenido de ese fichero “.ini” nos permitirá configurar cosas tales como (se adjuntan ejemplos de interacciones de correo):

  • Mailform se abrirá sin posibilidad de respnder
  • Mailform permitirá introducción de texto libre en respuestas
  • Mailform se abre automáticamente a la vez que el formulario VIVA desk
  • Ubicación de mailform (url)
  • Formulario VIVA Desk se iconiza automáticamente


Mcan9.png


6.8.3 Otras funcionalidades en agente

Otras funcionalidades típicas que un agente podrá realizar son:


  • Estando en llamada telefónica poder enviar un correo electrónico. Requiere realizar un formulario personalizado (o añadir la funcionalidad a uno existente)


  • Estando en llamada telefónica poder consultar el histórico de correos electrónicos de un cliente. Requiere realizar un formulario personalizado (o añadir la funcionalidad a uno existente)


  • Acceder al entorno de dashboards de supervisor web con permisos muy controlados sobre que puede ver y que puede modificar; un ejemplo típico de uso es disponer de un dashboard que le permita ver correos que ha aparcado para desaparcarla; otro ejemplo es poder ver correos en cola previa para tratarlos (porque por ejemplo estoy hablando con el cliente sobre un correo que ha mandado)



6.9 Funcionamiento típico

Un flujo típico de funcionamiento sería (se utiliza canal tipo correo electrónico como ejemplo):


1.Un cliente manda un correo electrónico a un servicio (por ejemplo atención al cliente)

2. El correo electrónico entra en el buzón del servidor de correo electrónico

3. Mcan

  • a. detecta la existencia del correo electrónico (realiza polling periódico)
  • b. copia el correo (.eml) al repositorio interno de VIVA it Suite

4. Si existe bot, se pasan las reglas del bot para obtener el grupo ACD destino

5. La interacción pasa a cola previa, siendo mcan el responsable de su cambio de estado

6. Cuando se dan las condiciones (típicamente el algoritmo correspondiente determina que en poco tiempo el correo será tratado por agente) mcan entrega la interacción a Chan_Sit, que lo encola "en asterisk"

7. Cuando se asigna la interacción a agente

- a. Se abre el formulario de correo en VIVA desk

- b. Se abre mailform (web); la interacción se realizará típicamente desde este formulario

8. Si el agente

- a. realiza determinadas acciones (transferir, aparcar…) la interacción vuelve a mcan a cola previa

- b. Si termina la interacción o la aparca, quedará disponible (o recuperará capacidad al liberar esfuerzo)


  • VIVA it mcan monitoriza constantemente un canal. En función del tipo de canal está monitorización podrá ser por “polling” o por otras tecnologías (p. ej. Webhooks)


  • Cuando existe un nuevo mensaje en el canal, VIVA it mcan determina si dicho mensaje pertenece a una conversación existente o constituye una nueva conversación. Los criterios para determinarlo son:


- Si existen mensajes con mismo origen y destino previos, que constituyeron una conversación y esta no se ha cerrado (por ejemplo, el agente no la ha cerrado), el nuevo mensaje es parte de la misma conversación


- Si existen mensajes con mismo origen y destino previos, que constituyeron una conversación y esta se ha cerrado, si no se ha vencido el tiempo de salvaguarda se sigue considerando parte de la misma conversación



6.10 Bots

Los bots residen junto a mcan (misma máquina), en la carpeta /var/lib/vivait-mcan/scripts


Cada bot creado y su revisión correspondiente en esa carpeta


Mcan12.png


El nombre del fichero de cada bot contiene información importante que se relaciona con la configuración del canal correspondiente

  • Nombre de bot (por ejemplo en la imagen anterior botEmailEnrutarAsunto
  • Revisión del bot (por ejemplo en la imagen anterior 00000


Así, un canal ejecutará un bot y una revisión configurada, que corresponderá con el nombre fichero cuyo nombre bot y número de revisión sea la misma. Cuando un bot está en modo prueba entonces usará siempre y solo la revisión 00000.



6.10.1 Funcionamiento de bots

Como se ha indicado anteriormente, un canal creado en VIVA it Suite puede llevar asociado un bot que automatiza las acciones previas a su paso a cola previa

Si bien se pueden desarrollar bots a medida de necesidades de cliente, por defecto el sistema dispone de dos tipos de bot creados para interacciones de tipo correo electrónico(considérense plantillas para crear cada bot de cada servicio) que permiten:

  • Enrutar una interacción en base a asunto
  • Enrutar una interacción en base a horario


Los bots automatizan tratamientos
Por defecto tenemos plantillas para email, enrutar en base a asunto o horario



Los bots son manejados en pseudocódigo basado en Python; su uso está previsto para ser realizado por parte de personal muy concreto, no necesariamente técnico.


Los bots manejan un sistema de versiones y prueba que nos permitirán:

  • Definir si un bot está en modo prueba o en modo producción
  • Definir que versión de bot deseamos pasar a producción


En general este proceso se basará en el número de revisión configurado en VIVA it Suite para un bot, que coincidirá con parte del nombre del fichero de bot



6.10.2 Modificaciones en bots

El aspecto del pseudocódigo de un bot es (la siguiente figura muestra el pseudocódigo donde se configura el enrutamiento en base a asunto del bot botEmailEnrutarAsunto


Mcan13.png


Como se puede intuir, en el ejemplo anterior en base a expresiones regulares contenidas en el campo asunto de un correo electrónico podremos definir con facilidad el grupo ACD hacia el que se dirigirá una interacción y con que prioridad entrará.

Los cambios realizados en un bot se aplicarán sin necesidad de reinicio alguno para siguientes interaciones entrantes.

Es especialmente relevante el uso de una identación adecuada; el pseudocódigo basado en Python tiene en cuenta las identaciones como parte de la estructura del código; se recomienda usar (como se ve en la figura anterior) una herramienta de edición que facilite la visualización de caracteres especiales, tales como espacios, tabuladores y retornos de carro. En la imagen anterior se ha utilizado como herramienta de edición:


  • Notepad++
  • Opciones de view/show symbols activadas según imagen a continuación


Mcan14.png


Las identificaciones son MUY importantes en el pseudocódigo de los bots

Se recomienda que cualquier cambio que se realice en un bot en producción genere una nueva versión (no modificar la versión existente), lo cual implica:


  • Crear un nuevo fichero con versión incrementada
  • Modificar dicho fichero
  • Cambiar en la configuración de VIVA it Suite la versión


Utilizar la gestión de versiones de bot



6.10.3 Herramienta de prueba de bots

Con la herramienta “vivait-mcan-bot-test” podemos probar bots

En el ejemplo siguiente probaremos el bot “botEmailPPHglobal” en su versión 2


Mcan15.png


Una vez dentro si tecleamos el mensaje que entra en el caso del correo (valor por defecto) será el asunto


Mcan16.png


En ese ejemplo vemos que como hemos enviado un correo con asunto que contiene “cancel” le ha asignado prioridad 2


6.11 Canal

La creación de un canal facilita la comunicación entre VIVA it Suite y los elementos de omunicación externos; típicamente un canal será:


  • Un buzón de correo electrónico que será tratado desde VIVA it Suite
  • Una cuenta de Whatsapp que será tratada desde VIVA it Suite
  • Una cuenta de Telegram que será tratada desde VIVA it Suite


6.11.1 Configuración plataforma mail

Típicamente cada buzón del cliente que vayamos a monitorizar será un canal

Es recomendable pedir al cliente que no nos conectemos al buzón original, sino a un buzón espejo que ellos creen, al que se copian todos los correos y de esta manera nosotros manejamos el buzón espejo y ellos siguen gestionando el original, asegurando que ellos puedan tener siempre la info original


Fundamentalmente configuraremos:

  • Protocolo y credenciales de lectura de buzón para comprobar correos nuevos
  • Protocolo y credenciales de envío de mensajes
  • Temporizadores
  • Acciones auxiliares (por ejemplo si tras leer un mensaje lo borramos de la bandeja de entrada del buzón de correo)



6.11.2 Herramienta de prueba de conexión a cuenta de correo de cliente

Existe un script “enviar.sh” que nos ayuda a determinar con una herramienta externa a VIVA it Suite si la conexión con el servidor de correo está funcionando


Dentro del script se meten todas la credenciales, y se le llama con /root/scripts/enviar.sh


6.11.3 Conexión a proveedor Messagebird

A efectos, mcan sería como montar un servidor web con HTTPS. Mcan (dentro de la red del cliente) ha de ser visto desde messagebird (en internet)

No es necesario consumir ni una IP completa ni siquiera un puerto completo, basta con que llegue a mcan un “trozo de URL” en un puerto de una IP


Típicamente existirá un proxy inverso delante que

  • termina el túnel (descifra)
  • deriva URL hacia mcan
  • tiene que tener una IP publica fija
  • un DNS válido
  • un certificado asociado


Este proxy inverso debiera ser parte de la arquitectura de seguridad del cliente; si el cliente no lo tiene podemos ponerlo nosotros



6.12 Desk

VIVA Desk contiene integrados las clases necesarias que invocarán (creando el formulario en VIVA it Call) a los formularios web correspondientes:

  • TfrmEmail
  • TfrmCHAT

VIVA Desk tendrá asociado un fichero “.ini” con el mismo nombre que el “.exe” del desk (típicamente “vivait-desk.ini”)

Los parámetros principales a manejar están dentro de la sección [Email] y serán:


Parámetro Descripción
url_solo_visor=0 El formulario de correo web se abrirá sin posibilidad de modificar
url_texto_libre=1 El formulario de correo web solo permitirá cargar plantillas en la confección de correos
url_webcorreo_auto=1 El formulario de correo web se abre automáticamente
url_webchat_auto=1 El formulario de chat web se abre automáticamente
url_webcorreo=http://172.25.128.100:8180/mailForm/correo/VerCorreo Ubicación del formulario de correo web
url_webchat=http://172.25.128.100:8180/chatForm/chatForm/view Ubicación del formulario de chat web
form_iconizar=0 EL formulario web se abre minimizado




6.13 Configuraciones de procesos internos

6.13.1 Mcan

Ubicado en /etc/MDtel/vivait-mcan.conf

En el fichero /etc/host hay que meter la IP del MQTTHOST al que se hace referencia en este fichero

Es necesario configurar el ID que tiene este no do en la BBDD (campo nodo_id)

Por lo demás este fichero solo contiene configuraciones de “ajuste fino”


6.13.2 Chan_sit

Chan_sit reside en el nodo ACD


La configuración de Chan_sit está en /etc/asterisk/chan_sit.conf


Existen configuraciones específicas para [mcan_email] y [mcan_chat] en las que lo relevante es configurar la IP de la maquina en la que reside mcan



6.14 Comprobaciones

6.14.1 Estados de las llamadas

TMCAestado= (
   mcaEstado_Fin= 0,
   mcaEstado_Llamando= 10,
   mcaEstado_Ring= 20, -> EN COLA ASTERISK
   mcaEstado_Agente= 30,
   mcaEstado_Reserva= 40,
   mcaEstado_Transfiriendo= 50,
   mcaEstado_colaPrevia= 100,
   mcaEstado_Aparcado= 200,
   mcaEstado_Bot= 300
 ); // 10100


6.14.2 Total de correos pendientes de tratar

El total de correos pendientes de tratar en un sistema serán la suma de:


  • Correos que estén en el buzón aún no leidos por VIVA it Suite; hay que tener en cuenta que VIVA it Suite tiene un control de flujo en mcan y no lee siempre todos los correos del buzón
  • Correos que estén en cola previa (estado 100) y que serán visualizados desde supervisor web
  • Correos que estén en cola asterisk (estado 20) y que serán visualizados desde



6.14.3 Ubicación de los correos

Los correos quedan ubicados en /var/lib/vivait-mcan/eml