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:

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
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)
   • Tiene coste (nuevo hardware)
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
     • Para integración CTI los sistemas del cliente deberán existir en la sede de respaldo y con las mismas IP
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
     • Para integración CTI los sistemas del cliente deberán existir en sede de respaldo pudiendo cambiar las IPs
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]