Arquitectura VIVAit

Producto:	VIVAit Call VIVAit Suite

1 Introducción

La plataforma VIVAit se basa en múltiples piezas de código libre y múltiples piezas de desarrollo propio realizado por MDtel para constituir plataformas profesionales de:

• Telefonía corporativa
• Contact Center

Los módulos de programa desarrollados por MDtel estarán explicados en la sección descripción de los elementos, diagnósticos y operaciones para VIVAit

Cada uno de estos módulos dispone de sus correspondientes programas y configuraciones. A efectos de roles en la arquitectura se puede ver en ver proceso de instalacion de la plataforma VIVAit.

Volver arriba [| Volver al indice]

2 Consideraciones de arquitecura

1. Por razones de incompatibilidad de las configuraciones de gateway con procesamiento de llamadasACD , el producto VIVAit Suite obliga a disponer de un mínimo de dos máquinas para su implantación; en una máquina se dispondrá de las funciones de gateway (y probablemente otras) y en otra máquina se dispondrá de las funciones de procesamiento de llamadas (y probablemente otras). La no aplicación de este criterio de arquitectura genera:
   • Grabaciones perdidas
   • Grabaciones que nunca se cierran
   • Llamadas duplicadas a efectos de grabaciones y estadísticas
   • La plataforma es menos robusta y menos tolerante a fallos de programa
2. El producto VIVAit Call puede ser implantado en una sola máquina (cuestiones de capacidad y redundancia aparte)
3. Las máquinas pueden ser físicas o virtuales indistintamente; lógicamente, si hay que introducir tarjetas físicas (de conexión a RTC/PBX o de transcoding), será necesario disponer de una máquina física para la inserción de dichas tarjetas.
4. El entorno cluster utilizado en la plataforma (típicamente para procesamiento, servidor de base de datos de tiempo real...) es activo/pasivo; de los dos servidores, solo se está aprovechando la capacidad de proceso de uno de ellos
5. Las grabaciones deben ser consideradas como un activo de información más del cliente; así pues su almacenamiento y mecanismos de respaldo debería ser el mismo que en otros activos; desde un punto de vista práctico, debe ser en la NAS/SAN del cliente (que gestiona el cliente) donde deben almacenarse las grabaciones; esto alivia los requerimientos de almacenamiento, políticas de seguridad y de respaldo de la plataforma VIVAit Suite.
6. En general las consideraciones de dimensionamiento de la arquitectura serán calculadas "ad hoc" en cada caso.

Volver arriba [| Volver al indice]

3 Arquitecturas validadas

3.1 Entorno monosede, pequeño/mediano

• Un entorno de telefonía corporativa (VIVAit Call) puede implementarse en un solo nodo, que agrupa todas las funciones, incluyendo registro de terminales y gateway
• Un entorno de contact center (VIVAit Suite) requiere de un nodo de registro MAS un nodo gateway
• Un entorno mixto (VIVAit Call y VIVAit Suite) puede implementarse con dos nodos; uno solo para registro de Contact Center y otro para registro de corporativa y gateway de ambos productos

3.2 Entorno multisede, grande

• Es preferible el registro centralizado para asegurar que todas las funciones (retrollamada, grupos...) funcionan para todos los usuarios sin "islas"
• Los terminales de VIVAit Call (telefonía corporativa) se logan a un servidor principal y un servidor alternativo; depende de que el terminal permita dicha configuración
• Los usuarios y terminales de VIVAit Suite (contact center) se logan en un solo servidor
• Se recomienda que el servidor principal de registro sea cluster
• Se recomienda que la base de datos de tiempo real este en cluster.
• En arquitecturas grandes es necesario un nodo de gestión; se recomienda que dicho nodo sea cluster, al contener elementos críticos del sistema (base de datos de tiempo real)

4 Alta disponibilidad para nodo VIVAit Suite

Para proporcionar al sistema Alta Disponibilidad existen varios escenarios posibles:

4.1 Alta Disponibilidad proporcionada por el entorno de vistualización.

• Solo existe una instancia de nodo VIVAit Suite
• La virtualización se encarga de proprcionar la Alta Disponibilidad del servicio
• La virtualización se encarga deproprocionar backups de las máquinas

4.2 Cluster Activo / pasivo físico.

• Cluster de contact center físicamente cercanos
• Una máquina física es activo y la otra es pasivo; mediante DRDB e IP flotante se controla el servicio del activo
• Orientado a fallos hardware del activo (la virtualización suele solucionar esta casuística)

4.3 Cluster activo / pasivo distribuido.

• Cluster distribuido de contact center entre sedes
• A efectos de los puestos de agentes es un unico sistema
• Totalmente automático
• Requiere:
  • Conectividad de nivel 2 entre sedes (los servidores del cluster comparten IP)
  • Velocidad Gigabit entre sedes (La conexión de (100 Mbps) seria suficiente mientras que se garantice un jitter inferior a 3.5ms entre ambos.)

4.4 Dos sistemas VIVAit Suite.

• Se implanta un segundo contact center
• En caso de incidencia existe procedimiento manual para conmutar al segundo sistema
• Requiere:
  • Determinar procedimiento de conmutación
  • Definir como será la configuración/sincronización del segundo sistema

4.5 Grupos ACD en Gateways.

• Se implantan grupos ACD solo telefónicos (no CTI) en el gateway existente en la sede de respaldo
• La línea 2 de los terminales de los agentes está logada en estos grupos ACD
• En caso de incidencia las llamadas se enrutan automaticamente a estos grupos y los agentes las atiendes solo telefonicamente
• Requiere:
  • Que la línea 2 de los terminales de agente esté disponible para esta funcionalidad

Volver arriba [| Volver al indice]

5 Instalación de VIVAit Call y VIVAit Suite in a box

VIVAit Call y VIVAit Suite no pueden instalarse en la misma máquina. Cuando VIVAit Call necesita la conexión de una tarjeta física de primarios la aplicación se instala en una máquina con sistema operativo Linux y las aplicaciones que requiere (esta máquina constituye el Gateway y el nodo de corporativa).

Además se instalará un software de virtualización (QEMU), este software nos permitirá crear una máquina virtualizada sobre la que instalaremos VIVAit Suite.

Manual de instalación del software de virtualización

6 Nodo WebRTC

Nodo operativo hasta la versión 3.6 de VIVAit Call

La arquitectura de WebRTC en VIVAit Call es la siguiente:

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.

7 Nodo STG

Nodo operativo a partir de la versión 4.0 de VIVAit Call

Para minimizar el area de exposición de VIVAit a redes inseguras (internet), se han concentrado las funciones que requieren conectividad con dichas redes en el nodo STG. Las conexiones vía internet de Web Call, APP VIVAit Call Business y otros (p.ej hardphone en internet) serán terminadas y controladas en este nodo.

Se han definido mecanismos de balanceo de carga y alta disponibilidad (Pacemaker, Haproxy).

7.1 Nodo STG/FlexiSIP

El nodo STG/FlexiSIP tiene un servicio push. Este servicio sirve para enviar llamadas entrantes SIP o mensajes de texto en el dispositivo móvil del usuario, ya que se requieren notificaciones push para recibir información cuando la aplicación de Vivait Business no está activa en primer plano. FlexiSIp actúa como proxy en el registro de los terminales.

8 Estado de extensión

El diagrama siguiente muestra los diferentes bloques y funciones de cada componente en VIVAit Call:

Componentes Principales:

Componentes	Explicación
NODO REGISTRO	La extensión manda un register al nodo y este le responde si estádisponible o no.
GRAN HERMANO	El gran hermano es un elemento que conoce el estado de todo lo que pasa en VIVAit , cuando hay un evento sabe como están las extensiones en todo momento (si no se produce un evento en el usuario , el estado aparecerá como desconocido). Los diferentes estados que hay son ( desconocido , no está en uso , en uso , no disponible , sonando , en espera).
WEB SERVICE	A través de este webservice , se podrán recibir peticiones GET desde un elemento externo para saber el estado de las extensiones , el webservice devolverá el estado mediante JSON.
ELEMENTO EXTERNO	Desde un elemento externo , se enviarán las peticiones para saber el estado y se podrán ver desde un entorno gráfico. Los elementos externos son ( portal mdtel , grafana , app del cliente etc…).

9 Multiterminal

Se ha desarrollado una nueva funcionalidad para VIVAit Call 4.0, con esta funcionalidad se pretende disponer de un mecanismo que permite manejar múltiples dispositivos por parte de un usuario (hardphone, softphone, apphone, webphone...) y que exista un algoritmo de asignación de llamada al teléfono o teléfonos de manera coherente.