# Introducción a OMniLeads
[OMniLeads](https://www.omnileads.net/) es una innovadora solución de software de código abierto que aprovecha la tecnología WebRTC (WebRTC) para potenciar los centros de contacto. Diseñado y pensando en la versatilidad, OMniLeads admite una amplia gama de **canales de comunicación, incluidos voz, vídeo, WhatsApp Chat & Voice, Redes Sociales y Campañas de Email,** además de sumar Herramientas de Colaboración y Text-To-Speech (TTS) para generación de Audios Personalizados de plataforma.
Ésto lo convierte en una opción ideal para las organizaciones que buscan gestionar e implementar estrategias eficientes de servicio al cliente omnicanal. Además, pone a disposición métricas, reportes e indicadores, supervisión real-time de agentes, módulos de auditorías para backoffice, y demás funcionalidades avanzadas de QA, gestión de contactos y campañas. El hecho de contar con tecnología [WebRTC](https://www.webrtc.org/) lo hace ideal para cursar la canalidad de Voz y Video con agentes tanto en modalidad onsite como home-office, debido a la eficiencia y seguridad criptográfica que implica la tecnología WebRTC en su operación por defecto, al momento de mantener sesiones a través de Internet. Por otro lado, la administración y gestión mediante un acceso 100% Web, hace el camino más simple a la hora de resolver una estrategia omnicanal con herramientas colaborativas.
Los diferentes perfiles de usuarios (agentes, supervisores, administradores o clientes) acceden a OMniLeads desde cualquier navegador web moderno. Al no requerir del uso de aplicaciones de escritorio (*softphones*), no es necesario realizar las típicas configuraciones sobre las estaciones de trabajo de los agentes de Contact Center. Tan sólo con acceder a la dirección web HTTPS donde reside la aplicación, tanto agentes como supervisores pueden estar online gestionando comunicaciones con los clientes. Ésta facilidad, implica una gran ventaja a la hora de brindar servicios de cloud CCaaS (Contact Center as a Service). OMniLeads puede adaptarse a una compañía u organización que necesita montar su propio Contact Center integrado a su central PBX, así como también escalar hacia compañías que brindan servicios de Customer Contact (BPO - Business Process Outsourcing), ya sea en entornos on-premise así como también en despliegues en cloud.

Esquema Básico

### ¿Cómo la obtengo? El [repositorio](https://gitlab.com/omnileads/omldeploytool) se encuentra disponible en GitLab, para su libre descarga, instalación, modificación y uso del software. ### ¿Cómo lo instalo? En la sección Instalación de OMniLeads se aborda éste asunto, presentando los pasos a seguir para instalar la aplicación bajo ciertos esquemas que se mencionan en el mismo documento. ### ¿Cómo me capacito? Ésta documentación cubre todos los aspectos del producto, desde cuestiones técnicas inherentes al Administrador (DevOps), hasta aspectos funcionales orientados a los agentes, supervisores o líderes del Contact Center. El usuario, entusiasta o empresa afin puede tener acceso a [Trainings Profesionales Sin Costo](https://www.omnileads.net/slides), con el objetivo de profundizar en la materia y know-how del producto. ### Características generales * [Características generales de OMniLeads](/introduccion-a-omnileads/caracteristicas-generales-de-omnileads) * [WebRTC - Tecnología subyacente de OMniLeads](/introduccion-a-omnileads/caracteristicas-generales-de-omnileads#webrtc-tecnologia-subyacente-de-omnileads) * [Características y funcionalidades de OMniLeads](/introduccion-a-omnileads/caracteristicas-generales-de-omnileads#caracteristicas-y-funcionalidades-de-omnileads) * [OMniLeads como Contact Center integrado a una PBX basada en SIP](/introduccion-a-omnileads/caracteristicas-generales-de-omnileads#omnileads-como-contact-center-integrado-a-una-pbx-basada-en-sip) * [OMniLeads en una compañía de servicios de Customer Contact](/introduccion-a-omnileads/caracteristicas-generales-de-omnileads#omnileads-en-una-compania-de-servicios-de-customer-contact) * [OMniLeads para carriers o proveedores de cloud PBX](/introduccion-a-omnileads/caracteristicas-generales-de-omnileads#omnileads-para-carriers-o-proveedores-de-cloud-pbx) ### Arquitectura En ésta sección, se introduce la arquitectura del proyecto, junto a la descripción de todos sus componentes: * [Arquitectura y componentes](/introduccion-a-omnileads/arquitectura-y-componentes) * [Descripción de cada componente](/introduccion-a-omnileads/arquitectura-y-componentes#descripcion-de-cada-componente) * [Deploy y variables de entorno](/introduccion-a-omnileads/arquitectura-y-componentes#deploy-y-variables-de-entorno) * [El potencial de acudir a cloud-init como provisioner](/introduccion-a-omnileads/arquitectura-y-componentes#el-potencial-de-acudir-a-cloud-init-como-provisioner) ### Instalación En éste capítulo, se cubren todos los tipos de instalación de la aplicación: * [Instalación de OMniLeads](/instalacion-de-omnileads) * [Deploy de OMniLeads OnPremise](/instalacion-de-omnileads#deploy-de-omnileads-onpremise) * [Deploy de OMniLeads OnPremise Alta Disponibilidad](/instalacion-de-omnileads#deploy-de-omnileads-onpremise-alta-disponibilidad) * [Deploy de OMniLeads sobre DigitalOcean](/instalacion-de-omnileads#deploy-de-omnileads-sobre-digitalocean) * [Deploy de OMniLeads basado en Terraform](/instalacion-de-omnileads#deploy-de-omnileads-basado-en-terraform) ### Seguridad En ésta sección, se plantean las configuraciones mínimas a realizar para que la aplicación se ejecute en un marco de seguridad mínima recomendada: * [Consideraciones sobre seguridad](/consideraciones-sobre-seguridad) ### Configuración inicial En éste capítulo, se plantean las configuraciones escenciales a realizar una vez que dejamos instalada una instancia de OMniLeads: * [Configuración inicial](/configuracion-inicial#configuracion-inicial) * [Roles y permisos](/configuracion-inicial#roles-y-permisos) * [Usuarios](/configuracion-inicial#usuarios) * [Grupos de agentes](/configuracion-inicial#grupos-de-agentes) * [Adicionar paquetes de audios en otros idiomas](/configuracion-inicial#adicionar-paquetes-de-audios-en-otros-idiomas) * [Música de espera](/configuracion-inicial#musica-de-espera) * [Pausas](/configuracion-inicial#pausas) * [Primer login de agente](/configuracion-inicial#primer-login-de-agente) * [Registro de la instancia](/configuracion-inicial#registro-de-la-instancia) * [Addons comerciales disponibles](/configuracion-inicial#addons-comerciales-disponibles) ### Campañas Toda comunicación entre «el exterior» y un agente de OMniLeads, es encapsulado dentro de una campaña. En éste capítulo, se aborda todo lo inherente a la gestión de campañas entrantes y salientes (manuales, preview y dialer): * [Campañas telefónicas](/campanas-de-contacto) * [Calificaciones](/campanas-de-contacto#calificaciones) * [Base de contactos](/campanas-de-contacto#base-de-contactos) * [Configuración de restricciones sobre campos de contactos](/campanas-de-contacto#configuracion-de-restricciones-sobre-campos-de-contactos) * [Formularios](/campanas-de-contacto#formularios) * [Campañas, calificaciones y formularios](/campanas-de-contacto#campanas-calificaciones-y-formularios) * [Campañas manuales](/campanas-de-contacto#campanas-manuales) * [Campañas preview](/campanas-de-contacto#campanas-preview) * [Campañas con Discador](/campanas-de-contacto#campanas-con-discador-predictivo) * [Campañas entrantes](/campanas-de-contacto#campanas-entrantes) * [Plantillas de campaña](/campanas-de-contacto#plantillas-de-campana) * [Interacción con sistemas de gestión externos](/campanas-de-contacto#interaccion-con-sistemas-de-gestion-externos) ### Auditoría de gestiones de agentes Cada vez que un agente genera una *gestión positiva* con un contacto, existe la posibilidad de auditar la misma desde el *módulo de auditorías*: * [Auditoría de gestiones (backoffice)](/auditoria-de-gestiones) ### Gestiones del administrador IT En éste capítulo, se cubren algunas tareas inherentes al administrador técnico de OMniLeads. Cuestiones como la configuración de bajo nivel del módulo de discador predictivo, gestión de actualizaciones, backup and restore, y cambio de dirección IP de la plataforma, son tratadas en éste capítulo de la documentación: * [Gestiones del administrador IT](/gestiones-del-administrador-it) * [Variables de entorno](/gestiones-del-administrador-it#variables-de-entorno) * [Configuración del módulo de *Discador predictivo*](/gestiones-del-administrador-it#configuracion-del-modulo-de-discador-predictivo) * [Cambiar certificados SSL](/gestiones-del-administrador-it#cambiar-certificados-ssl) * [Resetear contraseña web de admin](/gestiones-del-administrador-it#resetear-contrasena-web-de-admin) * [Backup & Restore](/gestiones-del-administrador-it#backup-restore-de-base-de-datos) * [Actualizaciones](/gestiones-del-administrador-it#actualizaciones) * [Cambios de los parámetros de red (Hostname y/o Dirección IP) y cambios de contraseñas de servicios](/gestiones-del-administrador-it#cambios-de-los-parametros-de-red-hostname-y-o-direccion-ip-y-cambios-de-contrasenas-de-servicios) * [Desbloqueo de usuarios](/gestiones-del-administrador-it#desbloqueo-de-usuarios) * [Recovery & Takeover nodo PostgreSQL HA](/gestiones-del-administrador-it#recovery-and-takeover-nodo-postgresql-ha) * [Desinstalación de OMniLeads](/gestiones-del-administrador-it#desinstalacion-de-omnileads) ### OMniLeads RESTful API En ésta sección, se puede encontrar todas las especificaciones de la API Rest del sistema: * [OMniLeads RESTful API](/omnileads-restful-api-pro) * [Endpoint de Login](/omnileads-restful-api-pro#endpoint-de-login) * [Endpoint obtener estructura de Base de Datos de Contactos](/omnileads-restful-api-pro#endpoint-obtener-estructura-de-base-de-datos-de-contactos) * [Endpoint creacion de contacto](/omnileads-restful-api-pro#endpoint-creacion-de-contacto) * [Endpoint de Generación de llamadas](/omnileads-restful-api-pro#endpoint-de-generacion-de-llamadas) * [Endpoint listado de opciones de calificación](/omnileads-restful-api-pro#endpoint-listado-de-opciones-de-calificacion) * [Endpoint listado de calificaciones](/omnileads-restful-api-pro#endpoint-listado-de-calificaciones) * [Endpoint crear nueva calificación](/omnileads-restful-api-pro#endpoint-crear-nueva-calificacion) * [Endpoint crear nuevo contacto y asignarle calificación](/omnileads-restful-api-pro#endpoint-crear-nuevo-contacto-y-asignarle-calificacion) * [Endpoint para modificar una calificación existente](/omnileads-restful-api-pro#endpoint-para-modificar-una-calificacion-existente) * [API de Sesión de Agente en Asterisk](/omnileads-restful-api-pro#api-de-sesion-de-agente-en-asterisk) * [Endpoint para obtener las credenciales SIP de Agente](/omnileads-restful-api-pro#endpoint-para-obtener-las-credenciales-sip-de-agente) # Características Generales de OMniLeads ### Tecnología subyacente de OMniLeads Antes de citar los casos de uso, ponemos énfasis en repasar los beneficios de la tecnología WebRTC, núcleo de OMniLeads. WebRTC dota a un navegador web de la posibilidad de mantener comunicaciones real-time de voz, video, chat y compartición de pantalla. OMniLeads se nutre de ésta tecnología para nuclear las comunicaciones y la interfaz de gestión web, evitando el uso de aplicaciones de escritorio «softphones», lo cual otorga una inmediatez en términos de «click and work» en el alta usuarios, ya que a partir de un login web, dichos usuarios están en línea procesando comunicaciones.
Algunas de las principales ventajas de WebRTC son las siguientes: * Se minimizan los puntos de fallo en las estaciones de trabajo. * Se minimizan las tareas del helpdesk y por ende, la demanda del personal de soporte/sistemas. * Se trabaja con los codecs de audio Opus y video VP8, ambos concebidos para una máxima performance en entornos de Internet (codecs internet nativos). * A nivel seguridad, todas las comunicaciones viajan cifradas de manera obligatoria, en términos de señalización y media. ### Características y funcionalidades de OMniLeads Actualmente, OMniLeads facilita una gestión sólida y soporte telefónico mediante varios tipos de campañas: ✅ Campañas entrantes: administra de manera eficiente las llamadas entrantes y enrútelas a los agentes adecuados. ✅ Campañas Preview: prepara a los agentes con información relevante antes de realizar una llamada. ✅ Campañas Manuales: proporciona herramientas para que los agentes se comuniquen manualmente con los clientes con facilidad. ✅ Campañas de Discador Automático: incorpora un potente discador interno 100% Open Source, además de integraciones con otros discadores de mercado. ✅ Reciclado de campañas por calificación de agente y/o status telefónico. ✅ Cambio de base de contactos para seguir discando ininterrumpidamente. ✅ Videollamadas basadas en web: campañas de videollamadas directamente desde páginas web. ✅ Compartir pantalla entre agente y cliente a partir de Videollamadas. ✅ Integración con WhatsApp Business: amplia su alcance y accesibilidad con las capacidades de comunicación de [WhatsApp Business de Meta](https://business.whatsapp.com/). ✅ Consola de Agente y Supervisor basada en WebRTC. ✅ Diferentes perfiles de usuario: administrador, administrador supervisor, cliente supervisor y agente. ✅ Detección de contestador automático. ✅ Grabación completa de llamadas. ✅ Informes de productividad. ✅ Supervisión en tiempo real. ✅ Creación sencilla de formularios web. ✅ Gestión de Calificaciones. ✅ Integración con CRM/ERP a través de la API RestFull. ✅ Modo Agentes Remotos. ✅ Integración con centralita PBX ✅ Soporte de Text-To-Speech (TTS) para generación de Audios Personalizados. ✅ Listo para virtualizar! OMniLeads fue concebido como una tecnología orientada a los entornos de virtualización. ✅ Listo para escalar! OMniLeads ofrece escenarios de Cluster Horizontal y HA (High Availability) ✅ **Versión Enterprise** para cuentas exigentes: dota a la plataforma de una "Capa Empresarial" para segmentos verticales y cuentas exigentes. ✅ Orientación 100% a Contact Center. No se trata de un software de PBX con agregados de reportería y/o supervisión. La aplicación fue concebida desde cero, y como una plataforma orientada y optimizada para funcionalidades de Contact Center. Con **Whatsapp Business**, puede: ✅ Tener varios usuarios chateando en el mismo número de WhatsApp. ✅ Conéctarse a múltiples cuentas de WhatsApp y recibir todos los mensajes en un solo lugar. ✅ Crear y chatear con nuevos contactos sin tocar el celular. ✅ Enviar y recibir mensajes ✅ Enviar y Recibir multimedia (imágenes/audio/documentos). ✅ Llamadas Inbound desde Whatsapp Business API (NEW) ### OMniLeads como Contact Center integrado a una PBX basada en SIP OMniLeads resulta ideal para las compañías que demandan funcionalidades típicas de Contact Center, que el sistema PBX no llega a cubrir por su propia naturaleza. Por lo tanto, OMniLeads surge como una alternativa para complementar dicha central PBX, desde una instancia independiente (bare-metal host, virtual machine o infraestructura de cloud) integrada a la PBX, permitiendo el fluir de las comunicaciones entre ambos componentes, de manera fiable, segura y transparente. Se plantea expandir el paradigma tradicional de adquisición de un stack de software de reportería/supervisión instalado sobre la PBX, para en lugar de ello, desplegar una completa aplicación de Contact Center independiente (utiliza su propio Asterisk), que permite a su vez una integración sencilla con el software de PBX, de manera tal que podamos derivar una opción del IVR de la PBX hacia una campaña entrante de OMniLeads, o bien realizar una transferencia desde una extensión de la PBX hacia OMniLeads, o viceversa. Las ventajas que se hacen notables, son: * Evitar el coste económico que involucran las licencias de software de las típicas herramientas complementarias del mercado, que dotan a la PBX de algunas funcionalidades de *reporting y supervisión* de colas. * Evitar el coste en términos de performance del core de telefonía *PBX* sacrificada para correr complejos reportes y herramientas de monitoreo, que implica ejecutar un «módulo de call center» sobre el sistema PBX. En operaciones donde hay una gran demanda de extracción de reportes, o bien donde se necesita escalar en términos de agentes, es sumamente sencillo desplegar OMniLeads *out of the box*, ya sea en una VM, VPS o server dedicado, sin perder la integración con la PBX.
### OMniLeads en una compañía de servicios de Customer Contact Bajo éste escenario, OMniLeads puede trabajar como núcleo de comunicaciones de un Contact Center con agentes que van entre las decenas y centenas. Así, OMniLeads puede manejar múltiples troncales SIP a la vez, con sus pertinentes enrutamientos entrantes y salientes de comunicaciones. En éstos contextos, la escalabilidad es un requisito básico, ya que las operaciones son muy dinámicas y pueden demandar picos de usuarios conectados trabajando en simultáneo. La escalabilidad se garantiza a partir de concebir nuestra solución de manera tal que pueda ser fácilmente desplegada en modalidad de cluster de alta disponibilidad. A su vez, la API RestFull permite generar fácilmente CRMs o web workflows para cada campaña, de manera tal de ajustarse a los requisitos del cliente que terceriza la cartera.
### OMniLeads para carriers o proveedores de cloud PBX Si la necesidad es implementar un servicio de CCaaS (Contact Center as a Service), OMniLeads resulta ideal a partir de la ventaja otorgada por WebRTC y Docker como tecnología de base. Podemos citar ventajas como las siguientes: * **WebRTC** elimina la necesidad de instalar aplicaciones softphone para escritorio, ya que la voz y el video fluye a través del browser de los agentes y supervisores. Ésto elimina un punto de falla y mantenimiento sobre las estaciones de trabajo. * Los **codecs** implementados para audio y video son Opus y VP8, ambos diseñados para funcionar en Internet, los cuales se adaptan dinámicamente al ancho de banda disponible, lo que evita los incómodos entrecortes de llamadas de la VoIP convencional. * **Seguridad**: El intercambio de información entre las estaciones de trabajo y la instancia de OML en cloud, se encuentra encriptado bajo los estándares HTTPS, sRTP y dTLS. * [Kamailio](https://www.kamailio.org/) es parte del core de comunicaciones de OMniLeads. Se trata de un Proxy-SIP de avanzadas prestaciones y crucial para brindar seguridad a servidores de VoIP y video de acceso público en Internet. * La arquitectura de Contenedores permite desplegar OMniLeads fácilmente abstrayendo la infraestructura subyacente, y permitiendo sin problemas correr en Cloud proviers como Amazon, Google Cloud, Digital Ocean, OVH, Linode, etc.
# Arquitectura y componentes
## 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: * **OMLApp** (): La aplicación web (Python/Django) está contenida en OMLApp. 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.
* **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. ![\_images/arq\_omlacd.png](https://documentacion-omnileads.readthedocs.io/es/latest/_images/arq_omlacd.png) * **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. 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.
* **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). 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*.
* **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*). ![\_images/arq\_omlredis.png](https://documentacion-omnileads.readthedocs.io/es/latest/_images/arq_omlredis.png) * **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).
### 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.
### # Instalación de OMniLeads {% embed url="" %} OMniLEads Quick Install {% endembed %} ## Instalación de OMniLeads Antes de avanzar con la instalación, se recomienda leer y entender la sección [Arquitectura y componentes](/introduccion-a-omnileads/arquitectura-y-componentes). Desde los inicios del Proyecto, las instalaciones se han basado en sistemas operativos CentOS7. Sin embargo, dada su pronta fecha de expiración (end-of-life), el equipo de OMniLeads ha trabajado arduamente para soportar sistemas operativos modernos como *Ubuntu Server, Debian Server, Rocky Linux, entre otros.* A partir de la adopción de una Arquitecturas basada en Contenedores y métodos de instalación totalmente automatizados, las tareas de Administración y Mantenimiento IT se han simplificado de manera significativa debido a la clara abstracción de las dependencias de capas subyacentes. Describiremos a continuación los diferentes escenarios correspondientes a formatos desplegables. No obstante, mayor información se podrá encontrar en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool).
* [Correr OMniLeads con Docker](/instalacion-de-omnileads/deploy-utilizando-docker): Permite correr la aplicación en una estación de trabajo (Mac, Linux, Windows) o en un Linux Host, con una configuración mínima y funcional "todo en uno". * [Correr OMniLeads con Automatización Ansible](/instalacion-de-omnileads/deploy-utilizando-ansible): Permite correr la aplicación en cualquier sistema operativo Linux moderno con soporte de [Podman](https://docs.podman.io/en/latest/). Bajo este formato, es posible manejar cientos de instancias en paralelo gracias a los bondades de Ansible. ### # Deploy utilizando Docker En el siguiente apartado abordaremos los pasos necesarios para tener OMniLeads corriendo en entornos dockerizados. Se requiere contar con Docker-Engine instalado en el ambiente a desplegar (Linux, Mac, o Win$): * [Docker Install documentation](https://docs.docker.com/get-docker/) y el siguiente repositorio clonado: ``` git clone https://gitlab.com/omnileads/omldeploytool.git cd omldeploytool/docker-compose ``` ## OMniLeads & Docker Compose Este entorno es ideal para un Testing Inicial o Prueba de Concepto ("PoC") local, debido a su rápido despliegue. Sin embargo no es recomendado para entornos productivos. En este directorio, encontraremos 3 entornos de Docker Compose: * **test-env**: se utiliza para lanzar el stack de manera local mediante Docker Desktop. * **prod-env**: se utiliza para lanzar el stack en un VPS (Virtual Private Server) o VM (Virtual Machine). * **dev-env**: se utiliza para lanzar el stack de desarrollo (development) de manera local mediante Docker Desktop. Para cualquiera de los casos, se precisa crear un archivo .env a partir de copiar el archivo env de ejemplo, provisto por el escenario elegido. A modo de ejemplo, intentaremos lanzar "test-env": ``` $ cp env test-env/.env $ cd test-env $ docker-compose up -d $ ../oml_manage --reset_pass $ ../oml_manage --init_env ``` Una vez que el entorno esté corriendo, simplemente se accede a la Suite mediante con user y password "admin". * [Docker Desktop](/instalacion-de-omnileads/deploy-utilizando-docker/deploy-en-docker-destkop) * [Docker en VPS Cloud o VM](/instalacion-de-omnileads/deploy-utilizando-docker/deploy-en-docker-para-vps-cloud-o-vm) * [Docker en VPS Cloud o VM utilizando Bucket Externo](/instalacion-de-omnileads/deploy-utilizando-docker/deploy-en-docker-para-vps-cloud-o-vm-con-bucket-externo) # Deploy en Docker-Destkop Para este escenario, no resulta mandatorio trabajar sobre el archivo de variables. Simplemente se procede con la ejecución de la instancia a partir del siguiente comando: ``` $ docker-compose up -d ``` Arribaremos a un resultado como el que se muestra en pantalla:
En el apartado de [First Login](/instalacion-de-omnileads/first-login), se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador. ### Configurando Wombat Dialer \ [Wombat Dialer](https://www.wombatdialer.com) es un software de terceros y no forma parte del stack FLOSS de OMniLeads. Sin embargo, es una opción válida para implementar una lógica de campaña de marcación predictiva. \ \ El archivo docker-compose.yml incluye el servicio Wombat Dialer & MariaDB (su backend SQL), por lo que está disponible para configuración e integración accediendo a localhost o a su Dirección IP según convenga: /wombat o . Los otros escenarios no implementan Wombat Dialer de forma predeterminada, por lo que si desea implementar Wombat Dialer en producción, deberá tener una VM/VPS para instalar el marcador allí y luego configurarlo para que funcione con OMniLeads. \ \ Consulte nuestra documentación oficial en la sección de [Creación de Campañas Dialer.](/gestiones-del-administrador-it#configuracion-del-modulo-de-discador-predictivo) Nota: al configurar las credenciales iniciales de mariadb, el password raíz es **admin123**, luego, en la conexión AMI, la dirección del servidor es **acd**. ### Simulando llamadas desde/hacia PSTN sobre Docker-Desktop Adicional al despliegue de componentes de OMniLeads, se agrega a la lista de arriba un container "emulador de red pública pstn" (pstn-emulator). De esta manera, se pueden realizar llamadas via OMniLeads y forzar diferentes resultados de acuerdo al número telefónico discado. A su vez, también es posible simular llamadas entrantes por línea de comandos. **Reglas de Plan de Discado para Llamadas Salientes:** * Cualquier número discado que finalice con 0: PSTN devolverá una señal BUSY (ocupado). * Cualquier número discado que finalice con 1: PSTN atenderá la llamada y reproducirá audios de ejemplo. * Cualquier número discado que finalice con 2: PSTN atenderá la llamada, reproducirá un audio corto y luego cortará (simulando un corte del contacto). * Cualquier número discado que finalice con 3: PSTN atenderá la llamada luego de 35 segundos de Ringing. * Cualquier número discado que finalice con 5: PSTN enviará una señal de Ringing durante 120 segundos y luego cortará (simulando un evento de NO\_ANSWER). * Cualquier número discado que finalice con 9: PSTN enviará una señal de Congestión. **Generando llamadas entrantes hacia OMniLeads:** ``` ./oml_manage --call_generate ``` La ejecución de este script permitirá la generación de una llamada entrante, que se derivará a la campaña por default creada en el [apartado de generación de datos de testing](/instalacion-de-omnileads/first-login#user-content-create-some-testing-data). **Registrando un SIP Phone para simular llamadas hacia OMniLeads:** También es posible registrar un clásico "Softphone" al PSTN-Emulator para interaccionar con la Suite de OMniLeads y simular llamadas. Las credenciales por default de la cuenta SIP se pueden verificar a continuación: * username: 1234567 * secret: omnileads * domain: YOUR\_HOSTNAME (cambiar el valor "YOUR\_HOSTNAME" el correspondiente al nombre de host o Dirección IP del entorno) * port: el puerto por default para el PSTN Emulator es el UDP 6060. A partir de esta configuración, ya es posible enviar llamadas desde el SIP Phone al DID 01177660010, como así también generar contacto desde un agente hacia el PSTN Number 1234567 (número del abonado registrado al SIP Phone).
Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # Deploy en Docker para VPS Cloud o VM Ya se ha visto como levantar OMniLeads utilizando Docker Dekstop. Sin embargo, para ambientes que utilicen Virtual Machines (VM) o Virtual Private Servers (VPS), es preciso trabajar sobre algunas variables de configuración. Para ello, dentro del Linux Host haremos uso del script de despliegue **deploy.sh** de nuestro repositorio "prod-env" mediante el siguiente comando: ``` $ curl -o deploy.sh -L "https://gitlab.com/omnileads/omldeploytool/-/raw/main/docker-compose/prod-env/deploy.sh?ref_type=heads" && chmod +x deploy.sh $ export DOCKER_ENGINE_IPV4=X.X.X.X && ./deploy.sh ``` Una vez que el entorno es iniciado, se puede proceder al login de plataforma accediendo a la URL , utilizando username y password "admin". **Importante para entornos detrás de NAT** Dado que el protocolo VoIP es sensible a ambientes de NAT (Network Address Translation), y dado que OMniLeads es usualmente desplegado a partir de una IP LAN, ciertos ajustes son necesarios para asegurar conectividad en sus componentes. Específicamente, para conectar a PBXs y/o Session Border Controllers (SBCs) mediante SIP Trunk y permitir acceso de usuario mediante internet, se debe considerar agregar la IP de NAT mediante argumento. Ésto se muestra en el siguiente ejemplo: ``` $ curl -o deploy.sh -L "https://gitlab.com/omnileads/omldeploytool/-/raw/main/docker-compose/prod-env/deploy.sh?ref_type=heads" && chmod +x deploy.sh $ export DOCKER_ENGINE_IPV4=X.X.X.X NAT_IPV4=Z.Z.Z.Z && ./deploy.sh ```
En el apartado de [First Login](/instalacion-de-omnileads/first-login), se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador. Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # Deploy en Docker para VPS Cloud o VM con Bucket Externo Para este escenario, similar al de la sección anterior, se consideran variables extras referentes a la configuración de un Bucket de Almacenamiento Externo (Object Storage). Consideraremos la definición del Object Storage a utilizar a partir de las variables **BUCKET\_URL** (dirección url del bucket externo), **BUCKET\_ACCESS\_KEY** y **BUCKET\_SECRET\_KEY** (para las credenciales de acceso), **BUCKET\_REGION** (para la región) y **BUCKET\_NAME** (para el nombre del bucket definido en el cloud provider). Estas variables entran en juego en los archivos .yml referentes a cada entorno. En cualquier caso, una vez parametrizados, podemos proceder a bajar los servicios o levantarlos nuevamente mediante instrucciones de Docker-Compose. ``` $ docker-compose down $ docker-compose up -d ```
En el apartado de [First Login](/instalacion-de-omnileads/first-login), se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador. Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # Deploy utilizando Ansible En el siguiente apartado abordaremos los pasos necesarios para tener OMniLeads corriendo en entornos contenerizados bajo [Podman](https://docs.podman.io/en/latest/). Es requisito fundamental contar con una distribución de Linux con Podman instalado (3.0.0 or higher). En la actualidad, sistemas operativos modernos como Debian, Ubuntu, Rocky, o Alma Linux, tienen repositorios activados que permiten su descarga. Nota: Si se trabaja sobre un VPS con una IP Pública, es mandatorio contar con una interface de red dedicada a una IP Privada. Para ello procedemos a clonar el repositorio del Deploy Manager del proyecto y nos posicionamos en la carpeta de Ansible: ``` git clone https://gitlab.com/omnileads/omldeploytool.git cd omldeploytool/ansible ``` Es importante destacar que el uso del Deploy Manager con Ansible nos permitirá múltiples acciones administrativas: * crear nuevas instancias * llevar adelante procesos de upgrades & rollbacks * llevar proceos de Disaster Recovery: backups & restores * administrar cientos de instancias de OMniLleads en paralelo, mediante archivos de inventario
Para cada instancia operativa, una colección de componentes es invocada mediante los servicios de SystemD, cada uno de ellos ejecutándose en un contenedor. También es posible agrupar dichos contenedores en instancias físicas separadas (cluster horizontal) y darles características de redundancia y disponibilidad (cluster HA). Debajo se puede apreciar un bosquejo de la arquitectura basada en contenedores y sus componentes involucrados:
### Bash Script y Ansible como piezas clave 📋 Una instancia de OMniLeads es desplegada en un Linux server utilizando SystemD y Podman, a partir de un Bash Script que se alimenta de variables de entorno y utiliza un set de archivos de Ansible para automatización (Playbooks + Templates). Este bash script será el responsable de la ejecución de múltiples acciones sobre uno o más tenants al mismo tiempo. Básicamente, busca el archivo de inventario de acuerdo a la ubicación especificada en la línea de comando y a partir de allí lanza el Playbook "raíz" de Ansible (matrix.yml). Ejecutando el siguiente comando, podemos interpretar sus posibles usos: ``` ./deploy.sh --help ``` Si el objetivo es correr instalaciones, upgrades, backups o restores, se deben especificar 2 parametros fundamentales: * **--action=** * **--tenant=** En el siguinte ejemplo, el script llevará a cabo una acción de instalación sobre la carpeta "tenant-folder", en cuyo interior contiene el archivo de inventario correspondiente con la descripción y parametrización de su/s tenant/s. ``` ./deploy.sh --action=install --tenant= ``` ### Systemd & Podman para gestión de componentes 🔧 Bajo este método de instalación, contaremos con la posibilidad de manejar contenedores (componentes) como servicios tradicionales de SystemD. ``` systemctl start component systemctl restart component systemctl stop component ``` Detrás de cada acción disparada por el comando systemctl, un contenedor de Podman es lanzado, parado o reiniciado. Este contenedor es el resultado de una imágen invocada a partir de las variables de entorno configuradas en el deployment. Debajo se expone un ejemplo, en el que observamos el archivo SystemD para el componente de Nginx: */etc/systemd/system/nginx.service*: ``` [Unit] Description=Podman container-oml-nginx-server.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor=%t/containers [Service] Environment=PODMAN_SYSTEMD_UNIT=%n Restart=on-failure TimeoutStopSec=70 ExecStartPre=/bin/rm -f %t/%n.ctr-id ExecStart=/usr/bin/podman run \ --cidfile=%t/%n.ctr-id \ --cgroups=no-conmon \ --sdnotify=conmon \ --replace \ --detach \ --network=host \ --env-file=/etc/default/nginx.env \ --name=oml-nginx-server \ --volume=/etc/omnileads/certs:/etc/omnileads/certs \ --volume=django_static:/opt/omnileads/static \ --volume=django_callrec_zip:/opt/omnileads/asterisk/var/spool/asterisk/monitor \ --volume=nginx_logs:/var/log/nginx/ \ --rm \ docker.io/omnileads/nginx:230215.01 ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id Type=notify NotifyAccess=all [Install] WantedBy=default.target ``` Nginx, a su vez, tendrá su archivo de variables de entorno definidas de la siguiente manera: */etc/default/nginx.env*: ``` DJANGO_HOSTNAME=172.16.101.221 DAPHNE_HOSTNAME=172.16.101.221 KAMAILIO_HOSTNAME=localhost WEBSOCKETS_HOSTNAME=172.16.101.221 ENV=prodenv S3_ENDPOINT=http://172.16.101.221:9000 ``` ### Pasemos a la acción! Dependiendo de la estructura del archivo de inventario y de sus variables definidas, OMniLeads puede ser desplegado de manera remota en 3 esquemas posibles: * [Correr OMniLeads All in One con Podman & Systemd](/instalacion-de-omnileads/deploy-utilizando-ansible/deploy-en-aio-all-in-one): Todos los componentes representados en contenedores se despliegan en el mismo Linux Host. * [Correr OMniLeads Cluster con Podman & Systemd](/instalacion-de-omnileads/deploy-utilizando-ansible/deploy-en-ait-all-in-three)**:** Los componentes se agrupan en una estructura de Cluster Horizontal (útil para alto tráfico o escenarios de alta carga). * [Correr OMniLeads Cluster HA con Podman & Systemd](/instalacion-de-omnileads/deploy-utilizando-ansible/deploy-en-ha-high-availability)**:** Los componentes se agrupan en dos nodos Activo-Pasivo para soporte de Alta Disponibilidad. # Deploy en AIO (All-In-One)
## OMniLeads en un Linux Host "All In One" Mediante este método de instalación, es posible desplegar la Suite de OMniLeads en un único Linu Host con todos sus componentes involucrados de manera local (localhost):
Para ello, se require una instancia de Linux (con cualquier sistema operativo moderno) con acceso a Internet. Dado que Ansible utiliza un proceso de conexión SSH (secure shell) para acceder a la instancia y ejecutar su playbook, es requisito obligatorio contar con la llave pública SSH y el archivo known\_hosts configurado oportunamente. ### Comprendiendo el Archivo de Inventario Debajo se especifica un archivo de inventario genérico para un típico despliegue en el esquema AIO. **En su primera sección** se listan los diferentes hosts por tenant y por tipo de deployment a ejecutar (aio\_instances):
**En su segunda sección**, el archivo de inventario permite parametrizar variables de entorno necesarias para la acción. Nota: Por default, todas ellas afectan de manera directa a TODAS las instancias declaradas, a menos que una variable (o grupo de variables) sea especificada en la sección del host (o grupo de hosts) en cuestión. Finalmente, **la última sección** comprende a la agrupación de hosts en función de la arquitectura seleccionada. En nuestro caso, bajo la etiqueta *omnileads\_aio* se listaria la/s instancia/s AIO que se pretende/n deployar. Las etiquetas de *omnileads\_data, omnileads\_voice*, etc. refieren a etiquetas de despliegues de Cluster Horizontal y Cluster HA, que se verán en próximas secciones). Debajo se muestra un ejemplo: ``` ############################################################################################################# # -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA). # ############################################################################################################# omnileads_aio: ####### <<<<<<<<<<<< USTED ESTA AQUI! <<<<<<<<<<<<<<< hosts: #tenant_example_1: #tenant_example_2: #tenant_example_3: #tenant_example_4: #tenant_example_7_aio_A: #tenant_example_7_aio_B: ################################################ omnileads_data: hosts: #tenant_example_5_data: omnileads_voice: hosts: #tenant_example_5_voice: omnileads_app: hosts: #tenant_example_5_app: ################################################ ha_omnileads_sql: hosts: #tenant_example_7_sql_A: #tenant_example_7_sql_B: ``` ### Ahora sí, manos a la Obra! Como primer paso, procedemos a crear la carpeta **instances** en el directorio raíz. Seguido a ello, en su interior crearemos una subcarpeta donde alojaremos el archivo de inventario de ejemplo provisto por el repositorio: Nota: Si bien estamos dentro de un repositorio versionado, el nombre "instances" está reservado y es ignorado por el repositorio a partir del archivo .gitignore. 
mkdir instances
mkdir instances/onpremise_oml
cp inventory.yml instances/onpremise_oml
De acuerdo a lo comprendido en las secciones del archivo de inventario, declararemos nuestra futura instancia de OMniLeads en la sección de aio. En nuestro caso, usaremos el nombre de ejemplo "algarrobo" para definir el tenant: ``` algarrobo: tenant_id: algarrobo ansible_host: 190.19.150.18 omni_ip_lan: 172.16.101.44 infra_env: lan ``` Es importante especificar el escenario en el que se trabajará. Si usaremos un VPS, el entorno a configurar será "cloud", y será "lan" si se usa una Virtual Machine. Definiremos para ello la variable de entorno **infra\_env** según sea el caso: "cloud" (por default) o "lan". Las variables **tenant\_id** (nombre del tenant), **ansible\_host** (dirección IP que deberá alcanzar Ansible para ejecutar la Playbook) y **omni\_ip\_lan** (dirección IP privada de la interface lan) son mandatorias para especificar al tenant. A su vez, las variables **bucket\_url** y **postgres\_host** deben quedar comentadas, de manera tal que tanto PostgreSQL como MinIO Object Storage sean instaladas dentro de la instancia. Finalmente, debemos asegurarnos de que la última sección contenga al tenant dentro del grupo *omnileads\_aio*. Debajo un ejemplo sobre nuestro tenant "algarrobo": ``` ############################################################################################################# # -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA). # ############################################################################################################# omnileads_aio: hosts: algarrobo: #tenant_example_3: #tenant_example_4: #tenant_example_2: omnileads_data: hosts: #tenant_example_5_data: #tenant_example_6_data: omnileads_voice: hosts: #tenant_example_5_voice: #tenant_example_6_voice: omnileads_app: hosts: #tenant_example_5_app: #tenant_example_6_app: ``` Con el archivo de inventario configurado, procedemos a ejecutar la acción de instalación del nuevo tenant: ``` ./deploy.sh --action=install --tenant=onpremise_oml ``` En el apartado de [First Login](/instalacion-de-omnileads/first-login), se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador. Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # Deploy en AIT (All-In-Three)
## OMniLeads en un Cluster Horizontal Mediante este método de instalación, es posible desplegar la Suite de OMniLeads en una disposición de Cluster Horizontal, agrupando contenedores según el siguiente esquema:
Para ello, se requiren de tres instancias de Linux (con cualquier sistema operativo moderno) con acceso a Internet. Dado que Ansible utiliza un proceso de conexión SSH (secure shell) para acceder a la instancia y ejecutar su playbook, es requisito obligatorio contar con la llave pública SSH y el archivo known\_hosts configurado oportunamente en cada host. ### Comprendiendo el Archivo de Inventario Debajo se especifica un archivo de inventario genérico para un típico despliegue en el esquema AIT. **En su primera sección** se listan los diferentes hosts por tenant y por tipo de deployment a ejecutar (cluster\_instances):
**En su segunda sección**, el archivo de inventario permite parametrizar variables de entorno necesarias para la acción. Nota: Por default, todas ellas afectan de manera directa a TODAS las instancias declaradas, a menos que una variable (o grupo de variables) sea especificada en la sección del host (o grupo de hosts) en cuestión. Finalmente, **la última sección** comprende a la agrupación de hosts en función de la arquitectura seleccionada. En nuestro caso, bajo las etiquetas *omnileads\_data, omnileads\_voice y omnileads\_app* se listarian los hosts correspondientes a la/s instancia/s que se pretende/n deployar. Debajo se muestra un ejemplo: ``` ############################################################################################################# # -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA). # ############################################################################################################# omnileads_aio: hosts: #tenant_example_1: #tenant_example_2: #tenant_example_3: #tenant_example_4: #tenant_example_7_aio_A: #tenant_example_7_aio_B: ################################################ omnileads_data: ####### <<<<<<<<<<<< USTED ESTA AQUI! <<<<<<<<<<<<<<< hosts: #tenant_example_5_data: omnileads_voice: hosts: #tenant_example_5_voice: omnileads_app: hosts: #tenant_example_5_app: ################################################ ha_omnileads_sql: hosts: #tenant_example_7_sql_A: #tenant_example_7_sql_B: ``` ### Ahora sí, manos a la Obra! Como primer paso, procedemos a crear la carpeta **instances** en el directorio raíz. Seguido a ello, en su interior crearemos una subcarpeta donde alojaremos el archivo de inventario de ejemplo provisto por el repositorio: Nota: Si bien estamos dentro de un repositorio versionado, el nombre "instances" está reservado y es ignorado por el repositorio a partir del archivo .gitignore. 
mkdir instances
mkdir instances/omlcluster
cp inventory.yml instances/omlcluster
De acuerdo a lo comprendido en las secciones del archivo de inventario, declararemos nuestra futura instancia de OMniLeads en AIT en la sección de cluster. En nuestro caso, usaremos el nombre de ejemplo "tala" para definir el tenant: ``` cluster_instances: children: tala: hosts: tala_data: ansible_host: 172.16.101.41 omni_ip_lan: 172.16.101.41 ansible_ssh_port: 22 tala_voice: ansible_host: 172.16.101.42 omni_ip_lan: 172.16.101.42 ansible_ssh_port: 22 tala_app: ansible_host: 172.16.101.43 omni_ip_lan: 172.16.101.43 ansible_ssh_port: 22 vars: tenant_id: tala data_host: 172.16.101.41 voice_host: 172.16.101.42 application_host: 172.16.101.43 infra_env: lan ``` Es importante especificar el escenario en el que se trabajará. Si usaremos un VPS, el entorno a configurar será "cloud", y será "lan" si se usa una Virtual Machine. Definiremos para ello la variable de entorno **infra\_env** según sea el caso: "cloud" (por default) o "lan". Las variables **tenant\_id** (nombre del tenant), **ansible\_host** (dirección IP que deberá alcanzar Ansible para ejecutar la Playbook) y **omni\_ip\_lan** (dirección IP privada de la interface lan) son mandatorias para especificar al tenant. A su vez, las variables **bucket\_url** y **postgres\_host** deben quedar comentadas, de manera tal que tanto PostgreSQL como MinIO Object Storage sean instaladas dentro de la instancia \_data. Finalmente, debemos asegurarnos de que la última sección contenga al tenant dentro de sus grupos correspondientes (\_*data, \_*voice y \_app). Debajo un ejemplo sobre nuestro tenant "tala": ``` ############################################################################################################# # -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA). # ############################################################################################################# omnileads_aio: hosts: #tenant_example_1: #tenant_example_2: #tenant_example_3: #tenant_example_4: omnileads_data: hosts: tala_data: omnileads_voice: hosts: tala_voice: omnileads_app: hosts: tala_app: ``` Con el archivo de inventario configurado, procedemos a ejecutar la acción de instalación del nuevo tenant: ``` ./deploy.sh --action=install --tenant=omlcluster ``` En el apartado de [First Login](/instalacion-de-omnileads/first-login), se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador. Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # Deploy en HA (High Availability)
## OMniLeads en un Cluster HA Mediante este método de instalación, es posible desplegar la Suite de OMniLeads en una disposición de Cluster de Alta Disponibilidad, agrupando contenedores según el siguiente esquema:
Para ello, se requieren de cuatro instancias de Linux (con cualquier sistema operativo moderno) con acceso a Internet. Dado que Ansible utiliza un proceso de conexión SSH (secure shell) para acceder a la instancia y ejecutar su playbook, es requisito obligatorio contar con la llave pública SSH y el archivo known\_hosts configurado oportunamente en cada host. ### Comprendiendo el Archivo de Inventario Debajo se especifica un archivo de inventario genérico para un típico despliegue en el esquema de Cluster HA. **En su primera sección** se listan los diferentes hosts por tenant y por tipo de deployment a ejecutar (ha\_instances):
**En su segunda sección**, el archivo de inventario permite parametrizar variables de entorno necesarias para la acción. Nota: Por default, todas ellas afectan de manera directa a TODAS las instancias declaradas, a menos que una variable (o grupo de variables) sea especificada en la sección del host (o grupo de hosts) en cuestión. Finalmente, **la última sección** comprende a la agrupación de hosts en función de la arquitectura seleccionada. En nuestro caso, bajo las etiquetas *omnileads\_aio y ha\_omnileads\_sql,* se listarian los hosts correspondientes a la/s instancia/s que se pretende/n deployar ("\_*aio" hará referencia a los nodos A y B de HA para Aplicación, mientras que "\_sql" hará referencia a los nodos read-only y read-write de PostgreSQL*). Debajo se muestra un ejemplo: ``` ############################################################################################################# # -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA). # ############################################################################################################# omnileads_aio: hosts: #tenant_example_1: #tenant_example_2: #tenant_example_3: #tenant_example_4: #tenant_example_7_aio_A: #tenant_example_7_aio_B: ################################################ omnileads_data: hosts: #tenant_example_5_data: omnileads_voice: hosts: #tenant_example_5_voice: omnileads_app: hosts: #tenant_example_5_app: ################################################ ha_omnileads_sql: hosts: #tenant_example_7_sql_A: #tenant_example_7_sql_B: ``` ### Ahora sí, manos a la Obra! Como primer paso, procedemos a crear la carpeta **instances** en el directorio raíz. Seguido a ello, en su interior crearemos una subcarpeta donde alojaremos el archivo de inventario de ejemplo provisto por el repositorio: Nota: Si bien estamos dentro de un repositorio versionado, el nombre "instances" está reservado y es ignorado por el repositorio a partir del archivo .gitignore. 
mkdir instances
mkdir instances/omlclusterha
cp inventory.yml instances/omlclusterha
De acuerdo a lo comprendido en las secciones del archivo de inventario, declararemos nuestra futura instancia de OMniLeads en HA en la sección de ha\_instances. En nuestro caso, usaremos el nombre de ejemplo "eucalipto" para definir el tenant: ``` ha_instances: children: eucalipto: hosts: eucalipto_sql_A: tenant_id: eucalipto_sql_A ansible_host: 172.16.101.101 omni_ip_lan: 172.16.101.101 ha_rol: main eucalipto_sql_B: tenant_id: eucalipto_sql_B ansible_host: 172.16.101.102 omni_ip_lan: 172.16.101.102 ha_rol: backup eucalipto_aio_A: tenant_id: eucalipto_aio_A ansible_host: 172.16.101.109 omni_ip_lan: 172.16.101.109 ha_rol: main eucalipto_aio_B: tenant_id: eucalipto_aio_B ansible_host: 172.16.101.110 omni_ip_lan: 172.16.101.110 ha_rol: backup vars: infra_env: lan omnileads_ha: true ha_vip_nic: ens18 netaddr: 172.16.101.0/16 netprefix: 16 ha_vip_nic: ens18 postgres_1: 172.16.101.101 postgres_2: 172.16.101.102 aio_1: 172.16.101.109 aio_2: 172.16.101.110 omnileads_vip: 172.16.101.200 postgres_rw_vip: 172.16.101.201 postgres_ro_vip: 172.16.101.202 bucket_url: https://172.16.101.100:9000 bucket_access_key: mYLcr7sdsahfaklsdx5vEbe7PO bucket_secret_key: v1Dl34Q29Bv6ruaWSjkdhajskhdajks7cUAEvSVfAtvGkR bucket_name: eucalipto ``` Es importante especificar el escenario en el que se trabajará. Si usaremos un VPS, el entorno a configurar será "cloud", y será "lan" si se usa una Virtual Machine. Definiremos para ello la variable de entorno **infra\_env** según sea el caso: "cloud" (por default) o "lan". Las variables **tenant\_id** (nombre del tenant) y **ansible\_host** (dirección IP que deberá alcanzar Ansible para ejecutar la Playbook) son mandatorias para especificar al tenant. A su vez, se listan un conjunto de variables necesarias para el correcto funcionamieto del cluster HA: * ha\_vip\_nic: este parámetro hace referencia a la IP virtual a asignar al cluster. En un entorno de alta disponiblidad debemos indicar a cada nodo del cluster su condición inicial (ha\_rol), de esta manera se especifica el nombre de la NIC sobre la cual la VIP se establecerá. * omnileads\_ha: este parámetro instruye a Ansible a correr ciertas tasks de playbook relacionadas a configuración de HA * netaddr y netprefix: parámetros utilizados para describir la red y máscara del entorno. * postgres\_1: dirección IP del nodo 1 de PostgreSQL * postgres\_2: dirección IP del nodo 2 de PostgreSQL * aio\_1: dirección IP del nodo 1 de App * aio\_2: dirección IP del nodo 2 de App * omnileads\_vip: dirección IP virtual para el acceso HTTPS del cluster HA * postgres\_rw\_vip: dirección IP del nodo RW (read-write) de PostgreSQL * postgres\_ro\_vip: dirección IP del nodo RO (read-only) de PostgreSQL * bucket\_url: la url del bucket externo (object storage) El resto de los paráemtros se pueden customizar a gusto. Finalmente, debemos asegurarnos de que la última sección contenga a los hosts del cluster correspondiente al tenant HA (tanto en \_*aio como en* \_sql). Debajo un ejemplo sobre nuestro tenant "eucalipto": ``` ############################################################################################################# # -- In this section the hosts are grouped based on the type of deployment (AIO, Cluster & Cluster HA). # ############################################################################################################# omnileads_aio: hosts: #tenant_example_1: #tenant_example_2: #tenant_example_3: #tenant_example_4: eucalipto_aio_A: eucalipto_aio_B: ################################################ omnileads_data: hosts: #tenant_example_5_data: omnileads_voice: hosts: #tenant_example_5_voice: omnileads_app: hosts: #tenant_example_5_app: ################################################ ha_omnileads_sql: hosts: eucalipto_sql_A: eucalipto_sql_B: ``` Con el archivo de inventario configurado, procedemos a ejecutar la acción de instalación del nuevo tenant: ``` ./deploy.sh --action=install --tenant=omlclusterha ``` En el apartado de [First Login](/instalacion-de-omnileads/first-login), se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador. Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # Backups, Restores, Upgrades y Rollbacks ## Realizando un Backup Los archivos de backup involucran por un lado, archivos de configuración personalizados de Asterisk (/etc/asterisk/custom). Por otro lado, se efectúa un respaldo de la Base de Datos Relacional de Postgres. Para correr un backup, se debe ejecutar el siguiente script: ``` ./deploy.sh --action=backup --tenant= ``` Dicho respaldo es depositado en el Bucket asociado a la instancia durante su proceso de despliegue. Recordemos que los escenarios expuestos permiten incorporar MinIO como bucket por default, o bien sumar soluciones populares de Cloud Providers orientadas a Object Storage, como Spaces (Digital Ocean) o S3 (Amazon). Dentro del bucket, se observará una carpeta de backup con un archivo .sql precedido por el timestamp de ejecución (marca de tiempo). A su vez, otro directorio contará con los respaldos de Asterisk correspondientes.
## Realizando un Recovery Frente a un escenario de Disaster, es posible proceder a un Fresh Install de una instancia productiva y aplicar una acción de restauración de información desde un backup (Recovery). Para que ésto suceda de manera efectiva, debemos modificar los últimos dos parámetros del inventory.yml correspondiente a nuestra carpeta de tenants. Ésto último es necesario para indicar que el bucket no maneja certificados confiables, y para configurar el timestamp del backup a restaurar: ``` restore_file_timestamp: 1681215859 ``` De esta manera, ejecutando el siguiente script con la action "restore", se procederá a reinstaurar el backup tomado en el paso previo sobre la nueva instancia desplegada y contar asi con un ambiente recuperado: ``` ./deploy.sh --action=restore --tenant= ``` ## ## Realizando un Upgrade El Equipo de OMniLeads construye imágenes de todos los componentes que conforman su arquitectura (builds). Los mismos están hosteados en Docker Hub en el siguiente enlace: {% embed url="" fullWidth="false" %} Es importante diferenciar el Repositorio principal de Aplicación (Web) del resto de los repositorios de componentes (asterisk, rtpengine, kamailio, nginx, websockets y postgres). La Web App utiliza una semántica de definición de releases que implica RC (releases candidatos) y STABLE (releases aptos para ambientes productivos), como se observa a continuación: ``` pre-release-X.Y.Z X.Y.Z ``` Sin embargo, el resto de los componentes utilizan semánticas de fechas seguidas por el número de versión de dicho release, por ejemplo: ``` 230204.01 ``` Cada vez que un release de WebApp es liberado, el mismo se disponibiliza por medio de una imágen en el registro de containers (Container Registry). A su vez el archivo el archivo **Releases-Notes.md** en la raiz del repositorio es actualizado para contemplar un correcto "mapping" entre las versiones de los componentes y la versión del Release de aplicación. Por lo tanto, para aplicar actualizaciones de manera correcta es importante "traernos" los últimos cambios correspondientes a la rama estable. Ésto lo logramos con el siguiente comando: ``` git fetch all git pull origin main git checkout release-2.3.1 ``` A partir de alli, el próximo paso es actualizar el archivo inventory.yml (correspondiente al tenant) con la versión "target". Por ejemplo, "2.X.X" en la captura debajo: ``` omnileads_img: docker.io/omnileads/omlapp:250201.01 asterisk_img: docker.io/omnileads/asterisk:250102.01 ``` Por último, procedemos a ejecutar el script con la acción "upgrade" a los efectos de proceder a la actualización del/de el/los componente/s en cuestión. ``` ./deploy.sh --action=upgrade --tenant= ``` ## Realizando un Rollback El uso de Contenedores en OMniLeads permite ejecutar procedimientos de rollbacks de manera rápida y segura. De esta manera podemos recuperar las versiones previas a la actualización en caso la misma no haya generado resultados satisfactorios. ``` omnileads_img: docker.io/omnileads/omlapp:240117.01 asterisk_img: docker.io/omnileads/asterisk:240102.01 ``` Con el inventory.yml modificado, es posible entonces volver a la versión previa al cambio: ``` ./deploy.sh --action=upgrade --tenant=tenant_name_folder ``` Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # Migración desde CentOS7 ## Migrando OMniLeads desde CentOS-7 🔄 Desde los inicios del Proyecto, las instalaciones se han basado en sistemas operativos CentOS7. Sin embargo, dada su pronta fecha de expiración (end-of-life), el equipo de OMniLeads ha trabajado arduamente para soportar sistemas operativos modernos como *Ubuntu Server, Debian Server, Rocky Linux, entre otros.* A partir de la adopción de una Arquitecturas basada en Contenedores y métodos de instalación totalmente automatizados, las tareas de Administración y Mantenimiento IT se han simplificado de manera significativa debido a la clara abstracción de las dependencias de capas subyacentes. Para lograr una correcta migración desde una instancia OMniLeads en CentOS7 hacia su arquitectura basada en contenedores, es necesario realizar un Fresh Install de OMniLeads sobre otro host (o grupo de hosts según el método de instalación involucrado) asegurando que las variables listadas en el inventory.yml deben tener la necesaria correspondencia con su contraparte en la instancia de CentOS7. A saber: * ami\_user * ami\_password * postgres\_password * postgres\_database * postgres\_user * dialer\_user * dialer\_password *IMPORTANTE:* Para el procedimiento, debemos considerar que la versión de la imágen de Postgres a desplegar con OMniLeads debe ser "omnileads/postgres:230624.01". Por lo tanto, se debe agregar el siguiente cambio en la variable de groupvars\_all/all inherente al servicio: ``` #################### containers img tag ################################ #postgres_img: docker.io/postgres:14.9-bullseye postgres_img: docker.io/omnileads/postgres:230624.01 ``` En OMniLeads sobre CentOS7, se debe ejecutar el siguiente comando a los efectos de obtener el backup de archivos correspondientes. Es importante aclarar que el backup resultante será subido al correspondiente Object Storage que la nueva instancia de OMniLeads utilizó en su despliegue "fresh": ``` export NOMBRE_BACKUP=some_file_name pg_dump -h ${PGHOST} -p ${PGPORT} -U ${PGUSER} -Fc -b -v -f /tmp/${NOMBRE_BACKUP}.sql -d ${PGDATABASE} --no-acl export AWS_ACCESS_KEY_ID=$your_new_instance_bucket_key export AWS_SECRET_ACCESS_KEY=$your_new_instance_bucket_secret_key export S3_BUCKET_NAME=$your_new_instance_bucket_name ``` Como hemos visto en la sección de Backups, el objetivo sería poder restaurar los backups de audios personalizados, audios telefónicos, backup de base de datos, etc, sobre el nuevo deploy de OMniLeads. Para migrar la información a un OMniLeads bajo el método de instalación AIO, exportamos la variable de S3\_ENDPOINT como se muestra a continuación: ``` export S3_ENDPOINT=http://$OML_AIO_IP:9000 ``` Para el caso de un OMniLeads bajo el método de instalación AIT (cluster), exportamos la variable de S3\_ENDPOINT de la siguiente manera: ``` export S3_ENDPOINT=http://$OML_DATA_IP:9000 ``` Si en cambio, se decide por utilizar un Object Storage Externo, el dato lo deberemos obtener desde el proveedor correspondiente: ``` export S3_ENDPOINT=https://$object_storage_url ``` Finalmente, procedemos a subir todos los backups desde OMniLeads sobre CentOS7 jacia el Bucket definido en el paso anterior: ``` aws --endpoint ${S3_ENDPOINT} s3 sync /opt/omnileads/media_root s3://${S3_BUCKET_NAME}/media_root aws --endpoint ${S3_ENDPOINT} s3 sync /opt/omnileads/asterisk/var/spool/asterisk/monitor/ s3://${S3_BUCKET_NAME} aws --endpoint ${S3_ENDPOINT} s3 cp /tmp/pgsql-backup-$NOMBRE_BACKUP.sql s3://${S3_BUCKET_NAME}/backup/ ``` ## Restaurando la información debemos modificar los últimos dos parámetros del inventory.yml correspondiente a nuestra carpeta de tenants. Ésto último es necesario para indicar que el bucket no maneja certificados confiables, y para configurar el timestamp del backup a restaurar: ``` restore_file_timestamp: $NOMBRE_BACKUP ``` De esta manera, ejecutando el siguiente script con la action "restore", se procederá a reinstaurar el backup tomado en el paso previo sobre la nueva instancia desplegada y contar asi con un ambiente migrado: ``` ./deploy.sh --action=restore --tenant= ``` Ahora, se debe revertir a la imágen original de Postgres, lo cual implica restabelcer el contenido de group\_vars/all a su estado previo: ``` #################### containers img taf ################################ postgres_img: docker.io/postgres:14.9-bullseye #postgres_img: omnileads/postgres:230624.01 ``` Finalmente, ejecutamos el upgrade: ``` ./deploy.sh --action=upgrade --tenant=$your_inventory_folder_name ``` ## Personalizaciones de Asterisk Dialplan OMniLeads se basa en contenedores (imágenes), por lo tanto todo cambio de código efectuado dentro del container es "efímero". Para dotar al sistema de modificaciones permanentes (dialplan, scripts, configuraciones particulares), se recomienda utilizar imágenes personalizadas. Un ejemplo de cómo lograr dicho objetivo se expone en el siguiente [repo](https://gitlab.com/omnileads/acd-customizations-example/). Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # OMniLeads Enterprise Qué es OMniLeads Enterprise? OMniLeads Enterprise es una Suite de Contact Center de "Carril Empresarial" basada en el Open Core de OMniLeads e impulsada por la innovación y colaboración de una gran Comunidad de Usuarios. Este producto cuenta con el respaldo comercial y de ingeniería del Patrocinador y Fabricante [Freetech Solutions](https://www.freetechsolutions.com.ar), lo que garantiza a los clientes el mejor rendimiento disponible. Además, añade una capa de módulos empresariales, como Reportes de Alto Impacto, Wallboard de Tiempo Real, Encuestas de CX Automatizadas, White Labeling, Videollamadas, Integración con Whatsapp Business, Discador Predictivo/Progresivo, entre otros. Esta versión puede ser implementada de manera muy sencilla, tan sólo referenciando la imágen comercial del contenedor de aplicación en el archivo de inventario mediante el agregado del string "-enterprise": ``` omnileads_img: docker.io/omnileads/omlapp:231227.01-enterprise ``` **Ésto permite pasarse de Community a Enterprise (y visceversa) de manera ágil y sin instalaciones extras ni pérdidas de información.** Registrando la instancia y activando una Subscripción con el Vendor, ya se cuenta con la solución de Carril Empresarial disponible y sin procedimientos extras. Para solicitar una Demo, siga las instrucciones desde aquí: . # Deploy en Entornos de Desarrollo Se requiere contar con Docker-Engine instalado en el ambiente de desarrollo a desplegar (de ahora en mas, "devenv"). El mismo puede ser desplegado en diferentes sistemas operativos, como Linux, Mac, o Win$: * [Docker Install documentation](https://docs.docker.com/get-docker/) Acto seguido, se procede al clonado del repositorio para trabajar en su configuración y despliegue. Es importante accesar al directorio de development-env para ejecutar el deploy: ``` git clone https://gitlab.com/omnileads/omldeploytool.git cd omldeploytool/development-env/ ``` El entorno de desarrollo ("devenv") de OMniLeads plantea un docker-compose.yml que mapea algunos repositorios dentro de algunos contenedores. Tomamos como ejemplo el código de Django; allí se puede observar cómo el código dentro del servicio app se mapea. ``` volumes: - ${REPO_PATH}/omlapp/:/opt/omnileads/ominicontacto/ ``` El deploy del entorno implica la creación de un directorio de nombre *omnileads-repos* para allí clonar todos los repositorios de los componentes de OMniLeads. Para levantar el entorno de desarrollo se deberá ejecutar por única vez el script de deploy.sh tal cual se indica debajo: ``` $ ./deploy.sh --os_host= --gitlab_clone= ``` Donde os\_host puede ser: "*linux"*, "*mac"* o "*win"*. Mientras que gitlab\_clone puede equivaler a "*ssh"* o "*https"* a la hora de elegir por el método que se utilizará para clonar los repos. Además de clonar los repos, el deploy.sh se encarga de setear MinIO (Object Storage) para que las grabaciones y media\_root (django) operen bajo un bucket provisto por el propio servicio de MinIO. Debajo una salida de ejemplo al momento de utilizar el método "https" de clonado, y su correspondiente lanzamiento de containers:
### Reset de Django pass ``` ./manage.sh --reset_pass ``` ### Inicializar entorno con datos de pruebas ``` ./manage.sh --init_env ``` ### Variables Todas las variables implicadas en el docker-compose se pueden leer/editar sobre el archivo .env. ### Build de imágenes Los servicios: nginx, rtpengine, acd (asterisk), kamailio y app presentan la posibilidad de ser buildeados desde el compose. Por ejemplo: ``` docker-compose build app ``` En el apartado de [First Login](/instalacion-de-omnileads/first-login), se pueden revisar los pasos necesarios para obtener el primer acceso a la UI con usuario Administrador. Para mayor información, sugerimos visitar la documentación expuesta en el [repositorio oficial del proyecto](https://gitlab.com/omnileads/omldeploytool). # First Login ### Login como usuario Administrador Antes del primer login, es necesario resetear el password del usuario admin mediante el siguiente comando dentro del directorio de docker-compose: ``` ./oml_manage --reset_pass ``` Luego se accede a través del browser a la URL de la instancia deployada con las credenciales por default. En el caso de haber deployado Docker-Desktop en un entorno local, ingresaremos con localhost, o bien mediante la Dirección IP si el entorno es remoto: o \_IP Default Admin User & Pass: ``` admin admin ``` En el primer login con dichas credenciales, se procederá al cambio de password:
### El script oml\_manage Este script es utilizado para acciones administrativas, tales como leer logs de contenedores, borrar tablas de Postgres, entre otras posibles tareas: ``` ./oml_manage --help ``` ### Creando Datos Iniciales para Testing A partir del siguiente script, es posible generar datos inciales en la instancia (como agentes y campañas de test), con el objetivo de agilizar el setting inicial del entorno. ``` ./oml_manage --init_env ``` En el caso de la creación de datos de prueba, el script permite generar agentes y campañas de test listas para su utilización:
# Certificados TLS/SSL ## Aprovisionamiento de certificados TLS/SSL 🔐 A partir de la variable "certs" presente en el archivo de inventario, es posible indicar certificados SSL específicos diferentes a los "autofirmados" generados en el procedimiento de instalación por default. Las posibles opciones son: * **selfsigned**: desplegará un certificado autofirmado (no es recomendado para ambientes de producción). * **custom**: si la idea es implementar certificados propios, se deben colocar dentro de instances/tenant\_folder los archivos correspondientes al certificado y su clave privada bajo los nombres: cert.pem y key.pem. * **certbot**: desplegará una instancia con un certificado generado por Let's Encrypt SSL. Cuando trabajamos con certificados autogenerados usando Certbot, debemos asegurar que nuestra instancia cuente con un FQDN válido (Fully Qualified Domain Name) y su correspondiente resolución de nombres DNS. Adicional a ello, el puerto 80 debe estar accesible desde la CA en Internet (Certificate Authority), y debemos contar con un email válido para poder recibir renovaciones desde el proveedor Let's Encrypt. ``` certs: certbot fqdn: omlinstance.domain.com notification_email: your_email@domain.com ``` Todos los métodos aplican tanto para instalaciones nuevas como para actualizaciones, *a excepción de Certbot (no disponible en procedimientos de upgrades).* # Monitoreo y Observabilidad ## Observability 🔎 Al desplegar instancias OMniLeads basadas en contenedores, el proceso de instalación y despliegue incorpora algunos componentes clave a la hora de hablar de Monitoring. Estos servicios permiten no solamente obtener métricas orientadas al sistema operativo anfitrión, sino también extender el alcance de observabilidad al resto de los componentes: redis, postgres, asterisk, entre otros, y centralizar los logs en el Stack de Observabilidad. A partir de este hecho, es posible contar con un **Centro de Observabilidad Multi-Instancia** con el objetivo de centralizar el monitoreo de los diferentes componentes (métricas y logs), de múltiples tenants al mismo tiempo. Ésto es posible gracias a las bondades de [Prometheus](https://prometheus.io/) (exportación de métricas) por un lado, y a [Loki](https://grafana.com/oss/loki/) y [Promtail](https://grafana.com/docs/loki/latest/send-data/promtail/) (centralización de logs) por el otro. * **Loki**: utilizado para almacenar archivos de logs provenientes de loscomponentes de OMniLeads, como ser djando, nginx, kamailio, etc. * **Promtail**: utilizado para parsear los archivos de logs de sistema y aplicación y enviarlos a Loki DB.
## Un verdadero Centro de Monitoreo! De esta manera, el área tecnológica o de IT de una empresa o un carrier cloud puede invocar mediante [Grafana/Prometheus](https://grafana.com/) las fuentes de datos proveniente de los tenants desplegados para luego construir Dashboards de Observabilidad y ofrecer análisis de logs almacenados en las bases de datos de Loki. Esto permite observar "al detalle" ambientes productivos de OMniLeads, y dota al Team de SREs / DevOps Engineers de la suficiente información para actuar proactivamente con sus clientes.
Centralized observability. # Consideraciones de Seguridad OMniLeads es una aplicación que combina tecnologías Web (https), WebRTC (wss & sRTP) y VoIP (SIP & RTP). Esto implica cierta complejidad a la hora de desplegarlo en producción bajo un escenario de exposición a Internet.
\ En el lado Web de las cosas lo ideal es implementar un Reverse Proxy o Load Balancer delante de OMnileads, es decir expuesto a Internet (TCP 443) y que reenvíe las solicitudes al Nginx del stack de OMniLeads. \ \ En cuanto a VoIP, cuando se conecta a la PSTN a través de VoIP, es ideal para operar detrás de un SBC (Session Border Controller) expuesto a Internet.\ \ Sin embargo, podemos utilizar de manera inteligente la tecnología **Cloud Firewall** cuando operamos sobre VPS expuestos a Internet. A continuación, se muestran las reglas de firewall que se aplicarán en la instancia All In One: * 443/TCP Nginx: aquí es donde se procesan las solicitudes Web/WebRTC a Nginx. El puerto 443 se puede abrir a todo Internet. * 20000-30000/UDP: WebRTC sRTP RTPengine: este rango de puertos se puede abrir a todo Internet. * 5060/UDP Asterisco: Aquí es donde se procesan las solicitudes SIP para llamadas entrantes de los ITSP. Este puerto debe abrirse restringiendo por origen en la(s) IP(s) del(de los) proveedor(es) de terminación PSTN SIP. * 40000-50000/UDP VoIP RTP Asterisk: este rango de puertos debe abrirse restringiendo por origen en las IP de los proveedores de terminación PSTN SIP. * 9090/TCP Prometheus (opcional, solo si vas a monitorear con grafana y prometheus): Aquí es donde se procesan las conexiones provenientes de la central de monitoreo, más precisamente de Prometheus Master. Este puerto se puede abrir restringiendo por origen en la IP del centro de monitoreo. * 3100/TCP Loki (opcional, solo si vas a centralizar logs de contenedores con grafana y loki): aquí es donde se procesan las conexiones provenientes de la central de monitoreo, más precisamente de Grafana. Este puerto se puede abrir restringiendo por origen en la IP del centro de monitoreo. # Configuración inicial ## Configuración inicial Luego de atravesar el proceso de [Instalación de OMniLeads](/instalacion-de-omnileads), asumimos que la aplicación se encuentra instalada y disponible en la correspondiente URL, por lo que en ésta sección se plantean los pasos esenciales de configuración post-instalación.
### Registro de la instancia Éste paso no es obligatorio, ya que el sistema puede funcionar perfectamente sin realizar un registro. Sin embargo, el Proceso de Registración permite un fácil acceso a servicios del fabricante, como así también una mejor trazabilidad a la hora de reportar bugs o requests de nuevos features de software. También resulta necesario tener la instancia registrada a la hora de adquirir un Addon Comercial o Suscribir la plataforma al Soporte de Fabricante. A futuro, aquellos integradores certificados (que han aprobado el programa de certificación oficial de OMniLeads), a partir de registrar la instancia, podrán firmar la instalación con el código de certificación, logrando así dejar una constancia de que la plataforma ha sido desplegada y configurada por un *Ingeniero IT* certificado por el fabricante.
Se deben completar los campos allí solicitados, y luego se recibirá un e-mail con el código de la instancia:
Luego, cada vez que ingresemos a la sección de registro a partir del menú *Ayuda -> Registrarse*, se obtendrá una salida que informa el hecho de haber registrado ya la instancia:
El registro de la instancia pide como valores obligatorios el nombre del usuario o empresa, la dirección de e-mail y la contraseña, siendo opcional el campo de teléfono. Una vez que se ha registrado la instancia satisfactoriamente, se le enviará un e-mail a la dirección ingresada con el valor de la clave asignada a la instancia. En caso de que quiera que se le reenvíe el e-mail con la llave de la instancia una vez registrado, puede usar el botón «Reenviar llave». Es importante tener en cuenta que si quiere registrar varias instancias con una misma dirección de e-mail, debe ingresar también la misma contraseña. En otro caso, use una dirección de e-mail diferente. ### Roles y permisos A éste módulo, se accede a partir del menú *Usuarios y grupos -> Roles y permisos*. En ésta sección del módulo citado, se puede listar los roles predefinidos del sistema, verificar los permisos específicos de cada rol, y finalmente crear nuevos roles personalizados con ciertos privilegios o limitaciones según las necesidades.
A continuación, se listan los roles predefinidos: * **Cliente Webphone**: Éste rol, si bien viene creado por defecto, sólamente se utiliza cuando se adquiere e instala el addon [Click2Call](https://www.omnileads.net/click2call). * **Agente**: Los usuarios generados y asignados a éste rol, podrán acceder a la consola de agente, con todos los permisos que ello implica (acceso al webphone para disparar llamadas, posibilidad de ejecutar pausas, acceso a agenda y grabaciones del agente, entre otros). * **Referente**: Los usuarios generados y asignados a éste rol, podrán sólo listar todas las campañas, consultar reportes generales de agentes y llamadas, acceder a la supervisión de agentes y campañas. * **Supervisor**: Los usuarios generados y asignados a éste rol, podrán trabajar con todas las campañas a las que estén asignados (crear, modificar, eliminar y listar), así como acceder a la supervisión y reportes generales de llamadas y agentes. También podrán buscar grabaciones de sus campañas, listar y subir bases de contactos y acceder al módulo de telefonía, donde podrán trabajar con algunas secciones. A su vez, podrá editar y eliminar agentes que él mismo haya creado, independientemente de si están asignados a sus campañas. El rol de supervisor puede otorgar "Permisos para Ver" a otros supervisores (a cualquier otro supervisor independientemente de si los creó o no) sólo sobre campañas que él mismo haya creado. Sin embargo, no podrá asignar supervisores a campañas que no haya creado. * **Gerente**: Los usuarios generados y asignados a éste rol, podrán realizar todas las acciones de un supervisor, y además podrán visualizar el módulo de Auditorías. * **Administrador**: Los usuarios generados y asignados a éste rol, tienen acceso completo a todo el sistema. Sólamente los administradores pueden editar o borrar usuarios con perfil Administrador. Para generar un *rol personalizado*, se debe acceder al menú *Usuarios y grupos -> Roles y permisos -> Crear rol*. Al nuevo rol se le asigna un nombre y luego se marcan los permisos que tendrá. Para no iniciar desde cero, el usuario puede partir de una base de permisos de cierto perfil, y luego seguir personalizando (añadiendo o limitando permisos) hasta dejar su rol listo. A continuación, se ejemplifica la creación de un nuevo rol: * Creación de un nuevo rol: Se crea un nuevo rol y se asigna un nombre al mismo.
Desde el combo de opciones del nuevo rol creado, se puede *imitar permisos de otro rol* ya existente, o bien *aplicar permisos de otro rol* ya existente. La diferencia radica en que la primer opción pone los mismos permisos del rol existente, mientras que la segunda opción suma los permisos del rol existente, a los permisos que ya han sido seleccionados en el nuevo rol.
* Guardado del nuevo rol: Finalmente, se guarda el nuevo rol creado.
### Usuarios Vamos a diferenciar entre usuarios del tipo «Agente» y usuarios del tipo «Administrativos». Los usuarios *Agente* son quienes gestionan las comunicaciones, y los usuarios *Administrativos* gestionan la aplicación (Administrador, Supervisor, Referente, Gerente, etc.). Importante Antes de crear un usuario *Agente*, debe existir al menos un *Grupo de agentes*. Para crear un usuario, se debe acceder al menú *Usuarios y grupos -> Lista de usuarios -> Nuevo usuario*.
Allí, se despliega un formulario a completar con los datos del nuevo usuario. Dentro de dicho forumlario, desde la opción *Rol del usuario*, se determinará si el nuevo usuario será del tipo «Agente» o «Administrativo», de acuerdo al rol que se asocie al usuario creado. Avanzando en el Wizard, se procede a la *Selección de Campañas*, donde la vista permite seleccionar (por Tipo) las campañas a las que se asociará el usuario creado. De esta manera, al clickear en Finalizar, el usuario queda apto para operar en la plataforma:

Selección de Campañas

### Importación de Usuarios Desde la versión 2.4.0 ya es posible importar usuarios en bulk (masivamente), a partir de subir un archivo CSV clickando en el botón "*Importar Lista de Usuarios (CSV)*". Es importante remarcar que el proceso asociado a la carga masiva exige un formato de CSV (columnas) cuya cabecera debe seguir un formato específico para su correcto parseo: *Username, First Name, Last Name, Profile, Email, Password, Group, Auth* *Nota: El botón de "Descargar Lista de usuarios (CSV)" ya ofrece dicha estructura. Ésto facilita procesos de importación/exportación futuros.*
### Clonar agentes Para lograr agilidad a la hora de crear recursos en el sistema, la vista de Usuarios permite clonar agentes conservando tanto sus campañas asignadas como su configuración de grupo. De esta manera el administrador y/o supervisor puede ahorrar un valioso tiempo de configuración sin tener que repetir acciones por cada recurso creado:
### Grupos de agentes En ésta sección, se administran los grupos de agentes, grupos que serán invocados en diferentes módulos del sistema, como puede ser a la hora de asignar usuarios a campañas, o en la extracción de reportes, así como también en el módulo de supervisión. **Creación de grupo de agentes** Para crear un grupo de agentes, se debe acceder al menú *Usuarios y grupos -> Nuevo grupo de agentes*.
Los campos allí desplegados, son los siguientes: * **Nombre:** Es el nombre que se desea asignar al grupo de agentes. * **Despausar automáticamente:** Para comprender éste parámetro, debemos explicar que en OMniLeads, luego de cada llamada (de cualquier naturaleza) procesada por un agente, el mismo es forzado a ingresar en una pausa ACW (After Call Work), en la cual permanece inactivo para las campañas asignadas, de manera tal que pueda completar la calificación de la llamada actual y terminar su gestión. Ahora bien, para salir de dicha pausa inducida por el sistema, existen 2 posibilidades, y allí es donde entra nuestro parámetro, ya que por un lado si dejamos el valor en «0» el agente debe salir explícitamente de la pausa para seguir operando, pero si colocamos un número (por ejemplo, 5 segundos), ésto implica que el agente asignado a éste grupo, luego de caer en una pausa inducida ACW, el sistema lo vuelva a dejar online a los X segundos (según lo indicado en «Despausar automáticamente»). Éste parámetro se puede manejar desde el grupo de agentes, o bien desde una configuración de la campaña, que se mencionará más adelante. * **Conjunto de pausas:** Aquí se presenta la posibilidad de asignar un grupo de pausas (previamente creado) al grupo de agentes, para que así los agentes que formen parte de dicho grupo, no visualicen todas las pausas, sino únicamente aquellas que forman parte del grupo de pausas asignado. * **Auto atender entrantes:** Si éste valor está checkeado, entonces las llamadas provenientes de campañas entrantes serán conectadas al agente sin brindar la posibilidad de notificación (ring) y opción de atender por parte del agente. * **Auto atender dialer:** Si éste valor está checkeado, entonces las llamadas provenientes de campañas con discador predictivo serán conectadas al agente sin brindar la posibilidad de notificación (ring) y opción de atender por parte del agente. * **Forzar calificación:** Si éste valor está checkeado, entonces todas las llamadas que realice o reciba el agente, deberán ser calificadas antes de volver a estar operativo el agente. Al seleccionar ésta opción, se deshabilita la posibilidad de despausar automáticamente al agente, ya que pasa a ser obligatoria la calificación. * **Forzar despausa:** Si la opción de «Forzar calificación» está habilitada, entonces se ofrece ésta segunda opción para forzar la despausa, una vez calificada la llamada. Si éste valor no está checkeado, el agente tendrá que retomar operación de manera explícita luego de calificar la llamada. * **Llamada fuera de campaña:** Si éste valor está checkeado, permitirá al agente realizar llamadas que no encuadren dentro de ninguna campaña, teniendo en cuenta que las mismas, no dejarán registro de reportería, grabaciones, etc. * **Permitir el acceso a las grabaciones:** Si éste valor está checkeado, el agente tendrá acceso a la búsqueda, descarga y escucha de sus propias grabaciones. * **Permitir el acceso al dashboard:** Si éste valor está checkeado, el agente tendrá acceso al dashboard sobre su gestión. * **Permitir la activación de On-Hold:** Si éste valor está checkeado, se permitirá al agente poner una llamada en espera. * **Ver temporizadores en consola:** Si éste valor está checkeado, el agente podrá ver los tiempos de operación y pausa que figuran en la esquina superior izquierda de la consola de agente. * **Limitar agendas personales:** Si éste valor está checkeado, se puede introducir la cantidad máxima de agendas personales que puede manejar un agente. * **Limitar agendas personales en días:** Si éste valor está checkeado, se puede introducir la cantidad máxima de días que se permitirá al agente usar, a la hora de agendar una llamada. Es decir, el agente podrá agendar llamadas dentro de la ventana de N días configurado a partir de éste parámetro. * **Acceso a los contactos como agente:** Si éste valor está checkeado, el agente tendrá acceso a la lista de contactos, desde la consola de agente. * **Acceso a las agendas como agente:** Si éste valor está checkeado, el agente tendrá acceso a la agenda, desde la consola de agente. * **Acceso a las calificaciones como agente:** Si éste valor está checkeado, el agente tendrá acceso al listado de calificaciones gestionadas, desde la consola de agente. * **Acceso a las campañas preview como agente:** Si éste valor está checkeado, el agente tendrá acceso al listado de campañas preview a las cuales se encuentra asignado, desde la consola de agente. * **Permiso de uso de la canalidad Whatsapp:** En caso exista integración con Whatsapp Business, este skill permite tener acceso al envío/recepción de mensajes de Whatsapp. * **Permiso de uso de la canalidad Meta Messenger:** En caso exista integración con Meta Messenger de Facebook, este skill permite tener acceso al envío/recepción de mensajes de desde una Landing Page de Meta configurada en la plataforma. * **Restringir Tipos de Llamadas Manuales:** este checkbox permite personalizar los tipos de campaña que serán desplegados a la hora de intentar efectuar una llamada manual en nombre de campaña, por parte del agente. ### Adicionar paquetes de audios en otros idiomas Los audios genéricos que los agentes o teléfonos externos escucharán vienen por defecto en inglés, siendo configurables en las rutas entrantes o rutas salientes, de manera tal que si el canal telefónico se encuentra con alguna indicación a través de un audio genérico dentro del flujo de una llamada, éste podrá ser reproducido de acuerdo al idioma indicado. Si la instancia precisa utilizar otros idiomas, se pueden instalar los mismos a través de la sección *Recursos -> Audios -> Paquetes de Audio de Asterisk*, en donde se podrán adicionar nuevos idiomas.
Al seleccionar el idioma deseado y presionar la opción «Guardar», se descargará e instalará dicho paquete de idioma. ### Música de espera Dentro del módulo *Recursos* -> *Audios -> Listas de Música de espera*, se permite gestionar *listas de reproducción* con archivos en el formato *wav 16 bits*. Las listas aquí generadas, podrán ser utilizadas en las *campañas entrantes* a la hora de poner a los llamantes en cola de espera. Cabe destacar, que no podrán eliminarse playlists que estén en uso por alguna campaña o que tengan archivos asignados.
Una vez creada una nueva lista, deberán agregarse las músicas deseadas, a través de archivos en formato **.wav** a cargarse desde su computadora. Sólo estarán disponibles para su uso en campañas entrantes las playlists que tengan al menos una música cargada.
### Pausas Los agentes pueden entrar en una pausa cada vez que deseen quedar desafectados para atender nuevas comunicaciones, de manera tal que se evita que una campaña entrante o con discador predictivo, le entregue una nueva llamada. Además, los estados de pausa son útiles para registrar productividad y medir los tiempos de sesión del agente. Las pausas las pueden generar los usuarios con dicho permiso, y pueden ser del tipo «Recreativas» o «Productivas». **Creación de pausas** Para generar una nueva pausa, se debe acceder al menú *Pausas -> Listado de pausas -> Nuevo*:
Desde el formulario que se despliega, se asigna un nombre, se selecciona el tipo de pausa, y se guardan los cambios. A la hora de presentar los reportes de sesión de agente, las pausas totalizadas se dividen en pausas recreativas y pausas productivas, lo cual permite medir la productividad de nuestros agentes de una manera más exacta. **Creación de conjuntos de pausas** Los grupos de pausas permiten, como su nombre lo indica, agrupar determinadas pausas creadas previamente, para ser asignadas a grupos de agentes. De ésta manera, los agentes que formen parte de un determinado grupo de agentes, con un determinado grupo de pausas, podrán utilizar sólamente las pausas de dicho grupo desde su consola de agente, y no tendrán acceso a todas las pausas que se hayan dado de alta en el sistema. Para generar un conjunto de pausas, se debe acceder al menú *Pausas -> Conjuntos de pausas -> Nuevo*:
Desde el formulario que se despliega, se asigna un nombre, se agregan pausas creadas previamente al nuevo grupo, y se guardan los cambios.
### Primer login de agente Importante Tener en cuenta que para obtener un login exitoso, debemos contar con un **MICRÓFONO disponible** en la estación de trabajo desde la cual se ha realizado el login de agente. Si ésto no se cumple, entonces el login será defectuoso. Una vez que accedemos con nuestro agente, si todo va bien, se desplegará un popup que solicita el permiso para tomar control del micrófono:
Al habilitar el permiso, debemos escuchar un audio que el sistema reproduce, indicando el login exitoso:
# Autenticación LDAP ### Configuración de Autenticación Externa Para Operaciones en las que sea una exigencia la autenticación de usuario mediante Sistemas Externos, OmniLeads añade a partir del Release Oficial 1.32 la Autenticación mediante protoclo [LDAP (Protocolo Ligero de Acceso a Directorios, por sus siglas en inglés)](https://es.wikipedia.org/wiki/Protocolo_ligero_de_acceso_a_directorios). Este método de autenticación permite a la plataforma autenticar cada acceso de usuario mediante un servicio externo LDAP, como ser [OpenLDAP](https://www.openldap.org/) o [Active Directory de Microsoft](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api). Para configurar la Autenticación Externa basada en LDAP, el administrador debe dirigirse al Menú Seguridad → Autenticación, y configurar las opciones correspondientes a su entorno:
* **Tipo**: En el que seleccionará LDAP (en futuros releases, se anexarán otros mecanismos de autenticación externa). * **Servidor**: La URI de contactación del servidor, anteponiendo protocolo y especificando Dirección IP o FQDN (full hostname) y puerto, tal como se muestra en la imágen. * **Base DN**: Distinguished Name o “nombre distiniguido”, describe la ruta base en el árbol de información que llevará al protocolo al resultado deseado de la búsqueda. * **Activación**: opción de activación de la feature. * **Check de Simple Authentication AD**: este checkbox utiliza formatos de username del tipo user\@dominio, a la hora de joinear a servicios de LDAP basados en Microsoft Active Directory. En el ejemplo, “172.16.102.101” hace referencia a la Direccón de Red del servidor donde se aloja el Backend externo de autenticación ([OpenLdap](https://openldap.org/) o [Microsoft Active Directo](https://learn.microsoft.com/es-es/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview)[ry](https://learn.microsoft.com/es-es/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview)). A su vez, “:10389” indica el puerto donde dicho servicio se expone. Por otro lado, el campo **BaseDN** hace referencia al “Nombre Distinguido” que se utilizará de base para explorar rápidamente el **DIT** (Directory Information Tree) y encontrar el resultado de la búsqueda. En el ejemplo, el string “*dc=planetexpress, dc=com*” comprende campos **DC** (elemento de acceso del dominio) que utiliza el mapa del sistema de nombres de dominio o **DNS** (domain name server). Sin embargo, este campo puede ser tan extenso como se requiera, como ser Nombre de la Empresa (O), Unidades Organizativas (OU) y/o Nombre Común (cn) para grupos de usuarios. Debajo se expone un ejemplo basado en [Microsoft Active Directory](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api). Si la cuenta de un usuario está en el contenedor o recurso ldap *Usuarios*, la información de enlace *Base DN* resultaría ser: “*cn=users,dc=pantac2,dc=org*”. Para este caso, al activar el checkbox de Simple Authentication previamente descripto, las credenciales transmitidas a Active Directory se expresan con el formato username\@dominio, donde "dominio" se lo sustituye por los campos de acceso a dominio -DC- (, en el ejemplo).

Ejemplo de Nombre Distinguido Base

### Métodos de Activación Al Activar la autenticación por protocolo LDAP, los mecanismos de Activación pueden ser: * **Todos:** todos los usuarios se configurarán con la autenticación externa por default. * **Todos menos Admin**: todos los usuarios se configurarán con la autenticación externa por default, menos el usuario Admin del sistema. * **Manual (default activo)**: cada nuevo usuario heredará de manera forzada la autenticación externa a la hora de ser dado de alta en el sistema. Sin embargo el administrador puede modificar la configuración de dicho usuario en todo momento. * **Manual (default inactivo)**: cada nuevo usuario heredará la autenticación "Legacy" a la hora de ser dado de alta en el sistema. Sin embargo el administrador puede modificar la configuración del usuario en todo momento. Para poder verificar la configuración de autenticación de usuarios, basta con dirigirse a la vista de Usuarios del sistema y revisar la columna Autenticación, tal como se muestra en la siguiente imágen:
A su vez, tanto para crear usuarios nuevos como para editar existentes, el administrador puede modificar su manera de accesar al sistema por medio de la vista detallada del usuario. La autenticación externa se podrá activar en la vista de usuario siempre y cuando exista un servicio de autenticación externa configurado en el menú de Seguridad del sistema, tal cual se ha explicado en el apartado anterior:
### Autenticando contra servicios de LDAP: Si la Autenticación de Sistema Externo está activada sobre un usuario y éste último efectúa un Login en el sistema, **OMniLeads** utilizará dicho *Backend de Autenticación Externa* para accesar. IMPORTANTE: dado que OMniLeads delega la autenticación a otra entidad, es importante que *el usuario esté creado en el sistema de directorios externo, de manera tal que la autenticación se lleve adelante consistentemente*. Si el proceso de autenticación no es satisfactorio, el usuario recibirá un mensaje de error de acceso; caso contrario podrá hacer uso normal de la plataforma. En el caso de que el servicio de LDAP se encuentre caído y el usuario Admin también utilice LDAP como método de acceso, tendrá chances de recuperar su acceso al sistema mediante un comando ejecutado por el usuario root del Sistema Operativo (superusuario): `source /opt/omnileads/virtualenv/bin/activate` *`cd /opt/omnileads/ominicontacto`* *`python3 manage.py desactivar_autenticacion_externa`* # Video Llamadas (Pro) ### OMniLeads Enterprise - Webphone Client
\ El módulo comercial de Video Llamadas disponible en [OMniLeads Enterprise](/instalacion-de-omnileads/omnileads-enterprise), permite embeber en su página web un widget ligero, para permitir que sus clientes llamen a su negocio **solo con un click**, sin otra herramienta más que el **web browser**. #### #### Requisitos 1. Una instancia de OMniLeads Enterprise > * **release-1.3.2** minimamente instalado para el **release-1.0.0** del webphone client. > * **release-1.5.0** minimamente instalado para el **release-2.0.0** del webphone client. > * **release-1.7.0** minimamente instalado para el **release-3.0.0** del webphone client. > * **release-1.12.0** minimamente instalado para el **release-3.5.0** del webphone client. Importante Esta instancia **debe ser** accesible desde Internet y debe trabajar con **certificados confiables**. Puede observar la documentación de OMnileads que habla sobre como instalar un servidor en la nube: OMniLeads Cloud. 1. La pagina web donde va a embeber el webphone tiene que estar usando HTTPS (Requisito de WebRTC). Nota A partir de la versión 3.5.0 existe la posibilidad de hacer Videollamada. # Configuración Inicial #### Pasos para instalar el módulo WebphoneClient en OMniLeads 1. Descargue desde [AQUI](https://fts-public-packages.s3.sa-east-1.amazonaws.com/webphone_client_app/webphone_client_app-latest.tar.gz) el Demo Web de Webphone Client, que lo acompañará a revisar ejemplos para montar código HTML/JS en su Web Pública. 2. Ingrese con su cuenta de admin en [https://OML\_HOST/admin/](https://oml_host/admin/). En la sección «Constance» clickee en «Config»
1. Setear la variable *WEBPHONE\_CLIENT\_ENABLED* a True, clickeando en el box. Esto habilitará el módulo. 2. Setear la variable *WEBPHONE\_CLIENT\_TTL*. El tiempo de vida de las credenciales del webphonees de 1200 segundos (20 minutos) 3. Setear la variable *WEBPHONE\_VIDEO\_DOMAIN* con el servidor de jitsi a utilizar en caso de que quiera permitir llamadas de video.
Luego hacer click en «Save» #### Registro de Key OMniLeads Es condición necesaria que la instancia esté registrada, acción que se efectúa desde el Menú Ayuda>Registrar del panel de Administración:
Webphone Client Pro está disponible para versiones de OmniLeads 1.3.2 o superiores. Si tiene dudas en cómo obtener la key de activación, contacte a [info@omnileads.net](mailto:info%40omnileads.net). #### Configurando el WebPhone client Con la variable WEBPHONE\_CLIENT\_ENABLED seteada en True, ahora puede crear un usuario WebphoneClient, logueandose a OMniLeads como admin: 1. Ir a Usuarios y Grupos –> Nuevo usuario. Escoger el rol «Webphone Client» para este usuario.
2. Puede ver el usuario creado en Usuarios y Grupos –> WebphoneClients
Nota Recuerde el usuario y contraseña de este usuario. Los va a necesitar para para poder obtener las credenciales SIP de login usando la API de OMniLeads. #### Acerca del Licenciamiento Webphone Client es un módulo comercial, motivo por el cual su funcionamiento está sujeto a la activación de producto a partir de la vinculación de una key (llave de acceso) con el Servidor de Llaves. El esquema de licenciamiento es de carácter permanente (key definitiva), y se brinda 1 año de actualizaciones para cobertura de bug-fixing y nuevas features sobre el release instalado. En caso de precisar upgrades de releases superado el año de la compra, se puede actualizar la key a un costo módico. La key permite activar el módulo en 1 (una) sola instancia a la vez, y no está sujeta a la cantidad de agentes operando en la plataforma. Si tiene dudas en cómo obtener la key de activación, contacte a [info@omnileads.net](mailto:info%40omnileads.net). # Wordpress Plugin ### WordPress plugin Creamos un sencillo plugin de WordPress, así usted puede insertar el WebPhone client como un Widget, en cualquier parte de su página web. El plugin aun no ha sido publicado en el repositorio de wordpress, por lo que tiene que ser instalado manualmente: #### Installation 1. En la página de administración de Wordpress ir a Plugin -> Añadir nuevo y subir el archivo *oml-webphone-client.zip*. 2. Click en el botón «Instalar» y esperar a que instale. 3. Una vez instalado Activar el plugin en la lista de plugins. #### Configuración 1. Ir a Settings -> OMniLeads WebphoneClient, allí va a configurar su webphone client con las credenciales del Usuario WebPhone Cliente que usted creó en su instancia OMniLeads. Luego ingrese la URL de la API.
1. Una vez configurado esto, ir al menu Widget, donde verá que disponible el «OML WebphoneClient Widget». Aquí se van a configurar mas cosas:
* **Titulo:** un titulo para su webphone * **KamailioHost:** la IP LAN de su instancia de OMniLeads. **Si nosotros estamos hosteando el OMniLeads preguntenos por este parámetro** * **Opciones de estilo:** el nombre de los IDs y clases para crear un diseño custom del webphone usando CSS. Observe la seccion [Changelog](https://oml-videophone-webrtc-plugin.readthedocs.io/es/latest/changelog.html#about-webphone-design) * **Botones de llamada:** puede insertar un máximo de cuatro botones de llamada. Acá configura el número a llamar y el nombre que va a tener el botón. 1. Click en guardar para salvar la configuración y ya puede observar en su página el widget insertado. #### Actualización de plugin Para actualizar el plugin es necesario primero: 1. En la página de administración de Wordpress ir a Plugin encontrar el plugin OMniLeads Webphone Addon 2. Desactivar y eliminar el plugin 3. Volver a instalarlo con el .zip actualizado. Nota Es necesario volver a configurar los datos en Settings -> OMniLeads WebphoneClient, pues el plugin se ha desinstalado y vuelto a instalar. [AnteriorEmbebiendo el Webphone](broken://pages/2wnRb7UsyT8fwaopGqaG)[SiguienteWebphone Demo](broken://pages/QmmMP0Zpl8mXZzYTfkFD) Última actualización hace 1 año # Webphone Demo ### WebPhone Demo Este es una demo de como funciona el webphone, utilizando Flask como backend. Todo el contenido esta en la carpeta *demo*. Para ejecutar este código ud debe: 1. Editar el objeto config en el archivo *views.py* con la configuración de su OMniLeads ``` config = { 'URL_API_CREDENTIALS': 'https://OML_HOST/api/v1/webphone/credentials/', // Your OML instance 'client_username': 'client_username', // Your OML WebPhone Client User username. 'client_password': 'clientpassword', // Your OML WebPhone Client User password. } ``` 1. Editar estas variables en el archivo *templates/index.html* ``` 'KamailioHost': "X.X.X.X", // This is the LAN IP of you OMniLeads instance 'WebSocketPort': "443", // This is the port you se to connect via Web browser to your OMniLeads instance 'WebSocketHost': "domain.example.com", // This is the domain name you use to connect via Web browser to your OMniLeads instance ``` 1. Instalar flask y correrlo localmente ``` $ pip install Flask $ pip install pyopenssl $ cd demo/ $ FLASK_APP=webphone.py FLASK_DEBUG=1 flask run --cert=adhoc ``` Por ultimo, navegar a: [AnteriorWordpress Plugin](broken://pages/ZJGdbqzerPXOJhz6tDHN)SiguienteAuditoría de gestiones Última actualización hace 1 año # Embebiendo el Webphone ### Embebiendo el webphone a su página web **Si su página web esta hosteada en el CMS Wordpress vaya directamente a esta sección:** [WordPress plugin](https://oml-videophone-webrtc-plugin.readthedocs.io/es/latest/wordpress.html#about-wordpress-plugin) #### Incluyendo el código JavaScript del webphone a su index.html 1. Copie todos los archivos .js dentro de la carpeta */static/js* a su web server. Puede observar un template del archivo index.html en *demo/templates/index.html* para saber que debe modificar en su página si quiere agregar el WebPhone. De todas maneras vamos a describir que hacer: 2. Incluir todos los archivos .js en el html de su página, como se ve en el index.html del demo. Importante Mantener el orden de los archivos .js como se muestra a continuación. ``` { } ``` 1. Incluir el siguiente bloque \, donde se encuentra el contexto del módulo JavaScript. A continuación, está la explicación de las variables: ``` {