🇪🇸
Omnileads Docs
ComunidadForo
Español
Español
  • 👶Introducción a OMniLeads
    • Características Generales de OMniLeads
    • Arquitectura y componentes
  • 🚀Instalación de OMniLeads
    • Deploy utilizando Docker
      • Deploy en Docker-Destkop
      • Deploy en Docker para VPS Cloud o VM
      • Deploy en Docker para VPS Cloud o VM con Bucket Externo
    • Deploy utilizando Ansible
      • Deploy en AIO (All-In-One)
      • Deploy en AIT (All-In-Three)
      • Deploy en HA (High Availability)
      • Backups, Restores, Upgrades y Rollbacks
      • Migración desde CentOS7
    • OMniLeads Enterprise
    • Deploy en Entornos de Desarrollo
    • First Login
    • Certificados TLS/SSL
    • Monitoreo y Observabilidad
    • Consideraciones de Seguridad
  • ⚙️Configuración inicial
  • 🪪Autenticación LDAP
  • 🎞️Video Llamadas (Pro)
    • Configuración Inicial
    • Wordpress Plugin
    • Webphone Demo
    • Embebiendo el Webphone
  • 🎯CX Survey (Pro)
    • Reportería
  • 📈Reportes Premium (Pro)
    • Reportes de Actividad
    • Analizando Resultados
  • 🔊Text To Speech - TTS (Pro)
  • ☎️Configuración del Canal de Voz
    • Parámetros generales del SIP trunk
  • 🆗Configuración del Canal de Whatsapp (Pro)
    • OMniLeads y GupShup
    • Dar de Alta Whatsapp Business en GupShup
    • Plantillas de Mensajes y Grupos Horarios
    • Proveedores
    • Lineas
  • 🚧Wallboard for Business (Pro)
    • Creación de un Wallboard
    • Agregando Widgets y Páginas "realtime"
    • Explorando Widgets y Métricas
  • 📤Mensajes Masivos (Pro)
    • Creación de Envios
    • Campañas de Turnos
    • Exportación de Resultados
  • 💬Campañas de Contacto
    • Campaña Entrante
      • Enrutamiento de llamadas entrantes
      • Derivación de llamadas entrantes desde la PBX hacia OMniLeads
      • Enrutamiento condicionado por rango de tiempo
      • IVR - Interactive Voice Response
      • Identificación de llamada entrante
      • Ejecución de dialplan personalizado
    • Campaña Manual
    • Campaña Preview
    • Campaña Dialer
    • Campaña de Whatsapp
  • 🎧Manual de agente
    • Login Logout
    • Llamadas manuales desde listado de contactos
    • Llamadas preview
    • Llamadas en dialer
    • Llamadas entrantes
    • Llamadas entre agentes
    • Listado de Contactos
    • Mensajes de Whatsapp
  • 🛑Métricas, grabaciones y supervisión
    • Grabaciones
    • Reportes de campañas entrantes
    • Reportes de campañas salientes
    • Reporte general de llamadas
    • Reportes de agente
    • Reportes de Whatsapp
    • Reportes de Conversaciones
    • Supervisión
  • 📊Auditoría de gestiones
  • ☎️Integración entre OMniLeads y PBXs
  • 🛠️Gestiones del administrador IT
  • 🧩Integración con CRM
    • Interacción desde OMniLeads hacia el CRM
    • Interacción desde el CRM hacia OMniLeads
  • 🔐Consideraciones sobre seguridad
  • 📌OMniLeads RESTful API
    • API de sesión de Agente en Asterisk
  • 🗒️Release Notes
  • ❤️Comunidad
  • 🎇Acerca De
Con tecnología de GitBook
En esta página
  • Arquitectura y componentes
  • Descripción de cada componente
  • Deploy y variables de entorno
  1. Introducción a OMniLeads

Arquitectura y componentes

Última actualización hace 1 año

Arquitectura y componentes

OMniLeads es una aplicación basada en múltiples componentes que residen en repositorios individuales de GitLab, donde se almacena el código fuente y/o de configuración, los scripts de build, deploy y pipelines CI/CD.

Si bien al momento de ejecutar una instancia de OMniLeads los componentes interactúan como una unidad a través de conexiones TCP/IP, la realidad es que cada uno es una entidad propia con su repositorio GitLab y ciclo DevOps.

A nivel de build, cada componente se distribuye a partir de contenedores (imágenes).

Podemos pensar a cada componente como una pieza de un rompecabezas con sus atributos:

Descripción de cada componente

A continuación, se describe cada componente:

  • Nginx es el webserver que recibe las peticiones HTTPS y redirecciona hacia OMLApp (Django/UWSGI) dichas solicitudes. OMLApp interactúa con varios componentes, ya sea para almacenar/aprovisionar configuración, así como también en la generación de llamadas, o a la hora de devolver vistas de reportes y supervisión de agentes/campañas.

    OMLApp utiliza PostgreSQL como motor SQL, Redis como caché y para aprovisionar la configuración de Asterisk, ya sea a través de archivos .conf así como también generando ciertas estructuras clave/valor que son consultadas por Asterisk en tiempo real a la hora de procesar llamadas sobre campañas. OMLApp se conecta a la interfaz AMI de Asterisk para generar llamadas y recargar alguna que otra configuración, también realiza conexiones hacia la API de WombatDialer cuando es necesario generar campañas con discado predictivo.

  • Para Asterisk, todos los agentes se encuentran disponibles en la URI de Kamailio, por lo que Kamailio recibe INVITEs (UDP 5060) desde Asterisk cuando éste requiere ubicar algún agente para conectar una llamada. Finalmente, cabe mencionar el hecho de que Kamailio genera conexiones hacia RTPEngine (TCP 22222) solicitando un SDP a la hora de establecer sesiones SIP entre Asterisk VoIP y los agentes WebRTC.

  • Al iniciar Asterisk, se lanza un proceso que establece el websocket contra dicho componente, y a partir de allí, recibe notificaciones cada vez que se proporcionan cambios en la configuración. En su configuración por defecto, levanta el puerto TCP 8000, y las conexiones recibidas son siempre redirigidas desde Nginx.

Deploy y variables de entorno

Habiendo procesado la exposición anterior sobre la función de cada componente y sus interacciones en términos del networking, pasamos a abordar el asunto del deploy.

Cada componente cuenta con un bash script y Ansible playbook que permiten la materialización del componente, ya sea sobre un Linux-Host dedicado o bien conviviendo con otros componentes en un mismo host.

Ésto es gracias al hecho de que la Ansible playbook puede ser invocada desde el bash script llamado first_boot_installer.tpl, en el caso de acudir al mismo como provisioner de un Linux-Host dedicado para hostear el componente dentro del marco de un cluster, así como también importada por la Ansible playbook del componente OMLApp a la hora de desplegar varios componentes en el mismo host donde corre la aplicación OMLApp.

Por lo tanto, concluimos en el hecho de que cada componente puede, o bien existir en un host standalone, o también convivir con OMLApp en el mismo host. Éstas posibilidades son contempladas por el método de instalación.

Dicho método de instalación está completamente basado en variables de entorno que se generan en el deploy y tienen como finalidad entre otras cosas, contener las direcciones de red y puerto de cada componente necesario para lograr la interacción. Es decir, todos los archivos de configuración de cada componente de OMniLeads, buscan a su par invocando variables de entorno de OS. Por ejemplo, el componente Asterisk apunta sus AGIs a la envvar $REDIST_HOST y $REDIS_PORT a la hora de intentar generar una conexión hacia Redis.

Gracias a las variables de entorno, se logra una compatibilidad entre los enfoques bare-metal y contenedores docker, es decir que podemos desplegar OMniLeads instalando todos los componentes en un host, distribuyendo los mismos en varios hosts o directamente sobre contenedores Docker.

El hecho de aprovisionar los parámetros de configuración vía variables de entorno, y además considerando la posibilidad de desplegar siempre la aplicación resguardando los datos que deben persistir (grabaciones de llamadas y DB PostgreSQL) sobre recursos montados sobre el sistema de archivos de Linux que aloja cada componente, podemos entonces plantear el hecho de trabajar con infraestructura inmutable como opción si así lo quisiéramos. Podemos fácilmente destruir y recrear cada componente, sin perder los datos importantes a la hora de hacer un redimensionamiento del componente o plantear actualizaciones. Podremos simplemente descartar el host donde corre una versión y desplegar uno nuevo con la última actualización.

Tenemos el potencial del abordaje que plantea el paradigma de infraestructura como código o infraestructura inmutable, planteado desde la perspectiva de las nuevas generaciones IT que operan dentro de la cultura DevOps. Éste enfoque es algo opcional, ya que se puede manejar actualizaciones desde la óptica más tradicional sin tener que destruir la instancia que aloja el componente.

OMLApp (): La aplicación web (Python/Django) está contenida en OMLApp.

Asterisk (): OMniLeads se basó en el framework Asterisk como base del ACD (Distribuidor Automático de Llamadas). Se encarga de la implementación de lógica de negocio (campañas telefónicas, grabaciones, reportes y métricas de la canalidad telefónica). A nivel de networking, Asterisk recibe peticiones AMI desde OMLApp y desde WombatDialer, mientras que necesita ejecutar conexiones hacia PostgresSQL para dejar logs, hacia Redis para consultar parámetros de campañas aprovisionados desde de OMLApp, y también necesita acceder a Nginx para el establecimiento del Websocket utilizado para traer el contenido de archivos de configuración contenidos en Asterisk (etc/asterisk) y generados desde OMLApp.

Kamailio (): Éste componente es utilizado en conjunto con RTPEngine (WebRTC bridge) a la hora de gestionar comunicaciones WebRTC (SIP over WSS) contra los usuarios agentes, mientras mantiene sesiones (SIP over UDP) contra Asterisk. Kamailio recibe los REGISTERs generados por el webphone (JSSIP) desde los agentes, por lo tanto se encarga de la labor de registro y localización de usuarios utilizando Redis para almacenar la dirección de red de cada usuario.

RTPEngine (): OMniLeads se apoya en RTPEngine a la hora del transcoding y bridge entre la tecnología WebRTC y la tecnología VoIP desde el punto de vista del audio. El componente mantiene canales de audio sRTP-WebRTC con los usuarios agentes por un lado, mientras que por el otro establece canales RTP-VoIP contra Asterisk. RTPEngine recibe conexiones desde Kamailio al puerto 22222.

Nginx (): El web server del proyecto es Nginx, y tiene como tarea recibir la peticiones TCP 443 por parte de los usuarios, así como también desde algunos componentes como Asterisk. Por un lado, Nginx es invocado cada vez que un usuario accede a la URL del ambiente desplegado. Si las peticiones de los usuarios tienen como destino renderizar alguna vista de la aplicación web Django, entonces Nginx redirecciona la petición a UWSGI, mientras que si las peticiones de los usuarios tienen como destino el REGISTER de su webphone JSSIP, entonces Nginx redirecciona la petición hacia Kamailio (para establecer un websocket SIP). También, Nginx es invocado por Asterisk a la hora de establecer el websocket contra el Websocket-Python de OMniLeads, que aprovisiona la configuración proporcionada desde OMLApp.

Python websocket (): OMniLeads se apoya en un servidor de websockets (basado en Python), utilizado para dejar corriendo tareas en segundo plano (reportes y generación de CSVs) y recibir una notificación asíncrona cuando la tarea se haya completado, lo cual optimiza el desempeño de la aplicación. A su vez, es utilizado como puente entre OMLApp y Asterisk en el aprovisionamiento de la configuración de archivos .conf (etc/asterisk).

Redis (): Redis es utilizado con 3 fines bien concretos. Por un lado, como caché para almacenar resultados de queries recurrentes implicadas en las vistas de supervisión de campañas y agentes; por otro lado se utiliza como DB para la presencia y localización de los usuarios; y finalmente para el almacenamiento de la configuración de Asterisk (etc/asterisk/) así como también de los parámetros de configuración implicados en cada módulo (campañas, troncales, rutas, IVR, etc.), reemplazando a la alternativa nativa de Asterisk (AstDB).

PostgreSQL (): PGSQL es el motor de DB SQL utilizado por OMniLeads. A partir de allí, se materializan todos los reportes y métricas del sistema. También allí, se almacena toda la información de configuración que debe persistir en el tiempo. Recibe conexiones en su puerto TCP 5432 desde los componentes OMLApp (lectura/escritura) y desde Asterisk (escritura de logs).

👶
https://gitlab.com/omnileads/ominicontacto
https://gitlab.com/omnileads/omlacd
https://gitlab.com/omnileads/omlkamailio
https://gitlab.com/omnileads/omlrtpengine
https://gitlab.com/omnileads/omlnginx
https://gitlab.com/omnileads/omnileads-websockets
https://gitlab.com/omnileads/omlredis
https://gitlab.com/omnileads/omlpgsql
_images/arq_omlredis.png
_images/arq_omlacd.png