Hace varios años, Digium sacó un sistema que permitía configurar automáticamente los teléfonos sin tener que acceder a ellos, únicamente aprovechando el propio Asterisk y un módulo propio llamado DPMA (Digium Phone Module for Asterisk), es más… Digium estaba tan convencido de la utilidad de este módulo que incluso lo incluyó como el primer tema de su famoso Asterisk Advanced. No obstante, aunque la idea en sí era buena, la implantación no lo era tanto, ya que tenía ciertos requerimientos que lo complicaban tanto que, al final, casi era mejor acceder a cada uno de los teléfonos y configurarlos a mano. Pero la idea en sí era muy buena. Las empresas que hacen instalaciones de sistemas basados en Asterisk (con teléfonos, gateways, etc.) necesitan de un sistema que les ayude a configurar todos los teléfonos de una sentada sin tener que ir uno por uno y reduciendo el tiempo necesario para configurarlos.
La solución estándar siempre ha sido muy sencilla: servidor DHCP + servidor FTP + plantillas de configuración, de manera que creando una plantilla, el teléfono al encenderse se conecta al servidor DHCP para que éste le de una dirección IP, y además le dice la ruta donde se encuentra el firmware y su configuración. El teléfono se conecta al servidor FTP, se descarga la configuración y punto.
Pero hoy día en el que muchos teléfonos no se encuentran dentro de la red local del servidor, muchos fabricantes han optado por un sistema más automático: El teléfono nada más encenderse, se conecta a un servidor propio del fabricante donde se le indica: o bien el servidor donde se encuentra la configuración, o bien directamente la configuración del teléfono en función de su dirección MAC.
Esto implica que haya que acceder a un servicio del fabricante del teléfono y configurar manualmente los valores que va a tener ese teléfono. Es una ventaja frente a tener que acceder remotamente al teléfono y configurarlo, pero aún así, si tienes 15 o más teléfonos, esta solución no ayuda tampoco.
Para ello, Snom ha creado PhoneLink para Asterisk: una herramienta que hace uso de un sistema propio y remoto donde los teléfonos se van a conectar para buscar su configuración personal (SRAPS – Secure Redirection And Provisioning Service) y un módulo de Asterisk que lee la configuración que tengamos en el módulo PJSIP y la exporte al SRAPS para generar automáticamente la configuración para los teléfonos que tengamos dados de alta.
Esquema de cómo funciona el sistema PhoneLink de Snom
Para que esto funcione bien y que Asterisk se pueda comunicar con el servidor SRAPS, hace falta primero una configuración propia en Asterisk que haremos gracias a un módulo para el PJSIP.
[1000] type = phoneprovr endpoint = endpoint_1000 MAC = 000413928b88 IPUI = 0x0328D661AB PROFILE = snom OTHERVAR = othervalue
Aquí un ejemplo de cómo sería la configuración que PhoneLink procesaría y sincronizaría con el SRAPS
Como podéis ver, hace uso del res_phoneprov para crear una configuración específica para ese teléfono y subirla al servidor SRAPS con la misma configuración que le hemos configurado en el PJSIP.
Una de las ventajas es que es compatible con los teléfonos Snom ya sea de escritorio, DECT o de conferencia (que básicamente son los que utilizaremos con Asterisk) y que podemos configurar prácticamente cualquier parámetro del teléfono (hasta los botones de monitorización BLF) por lo que la configuración SIEMPRE estará sincronizada y nos ahorrará bastante tiempo a la hora de cambiar la configuración o añadir nuevos terminales.
Y aquí la web con el código del proyecto que se encarga de «capturar» la información particular de los teléfonos y subirla al servidor SRAPS: https://gitlab.com/publ2/phonelink_for_asterisk
Una solución mucho más efectiva, práctica y rápida que el dichoso DPMA de Digium. Cierto que sólo funciona con los teléfonos SNOM, pero es otra de las ventajas de utilizar este tipo de teléfonos. ¿o no?
Hace unos años dí una conferencia en el VoIP2DAY sobre el uso de la Inteligencia Artificial en el campo de la VoIP en el que hablaba que existen bancos (HSBC por poner un ejemplo) que comprueba durante una llamada, si la persona con la que hablamos es realmente quien dice ser, aprovechando un análisis de la voz telefónica (Voice ID Fingerprinting).
Esto hoy día ya no es una aplicación válida, ya que alguien le ha dado dos vueltas de tuerca a esto de la Inteligencia Artificial y ha conseguido que, aprovechando una conversación telefónica de 5 segundos, poder generar casi en tiempo real un modificador de audio para cambiar la voz de un TTS de forma que tenga exáctamente el mismo tono y el mismo timbre de voz que en la grabación de 5 segundos. Esto es, cualquiera con esa aplicación podría generar una conversación con nuestra voz y confundir y poder hacerse pasar por una persona.
Hay soluciones comerciales que ya hacen esto y que nos permite generar locuciones con la voz que queramos (incluso con una propia) por lo que si necesitamos generar nuevas locuciones para nuestro sistema, aquí tendríamos todo lo necesario.
No obstante, la aplicación «Real Time Voice Cloning» junto con toda la documentación de la tesis está disponible desde la página web del proyecto: https://github.com/CorentinJ/Real-Time-Voice-Cloning y un vídeo demostrativo de cómo funciona.
Así que, si tenéis un rato aburrido, os recomiendo que lo probéis porque es una herramienta tan útil como curiosa para frikear un buen rato.
Hace unos días recibo por parte de el canal de anuncios de Issabel, la compatibilidad con Vosk, un ASR gratuito, libre y offline (no necesita internet para funcionar). Issabel vuelve a adelantarse a todas las distribuciones de comunicaciones esta vez con algo que mucha gente quiere y lo han incluido ya en sus sistemas.
Leo el comunicado y pienso… ¿Cómo??? debe tener truco… Conozco varios sistemas que, aprovechando el boom de la inteligencia artificial y las redes neuronales, se han lanzado a crear modelos de reconocimiento de audio muy interesantes. Hace un par de años estuvimos en el Stand de Mozilla leyendo unos textos para ayudar a enseñar al motor. No obstante, este proyecto nos había pasado desapercibido y eso que posteriormente parecía haber pasado por delante en varias ocasiones sin haberme percatado de la joya que era.
Efectivamente, no tiene truco, la gente de Issabel no solo ha estado muy atenta si no que ha incorporado, además de muchas herramientas con las que ya cuenta, un reconocedor de audio (ASR) completamente libre y gratuito y que, a diferencia de muchos otros, no depende de terceros como Google, Amazon, Microsoft, etc.
Vosk es el motor, una aplicación escrita en Python y basada en redes neuronales que reconoce palabras en varios idiomas (según el diccionario que le cargues) y que funciona de forma independiente (no requiere conexiones a otros sistemas) por lo que instalas el servidor, cargas el diccionario del idioma que deseas, lo ejecutas y ya está el puerto listo para enviarle audio y que el motor lo convierta a texto.
Investigando, me di cuenta que lo presentaron en la ClueCon 2020 (el año pasado) donde explicaron cómo funciona y qué ventajas tiene. Podéis ver la presentación aquí:
He probado varios sistemas similares y por lo general, los ASR libres, en comparación con los sistemas comerciales, no eran muy competitivos, entiendo que un ASR es un sistema super-complejo y crear uno que funcione bien requiere de un gran esfuerzo económico que muchas veces sólo es posible si hay una empresa detrás, pero en esta ocasión la sorpresa ha sido mayúscula.
Echándole un vistazo a su web, el proyecto es completamente transparente… publican todas las presentaciones, todas las fórmulas, ecuaciones y sistemas que utilizan para el entrenamiento y análisis de la voz y posterior conversión en palabras.
También publican ejemplos y demos para que cualquiera pueda probarlo con varios comandos. Esto también lo conocía en otros sistemas, funciona muy bien en sus ejemplos pero luego uno prueba una conversación normal y no da con una traducción medianamente aceptable.
Así que sin más… me he puesto manos a la obra y por probar una grabación mía:
ejemplo de audio para comprobar la calidad del reconocedor de audio
Ejecuto el comando que se conecta al servidor y devuelve lo siguiente:
Como podéis ver, aunque falta el primer «hola» (en la grabación eran 3 ‘hola’) el reconocimiento es perfecto y tampoco es que sea una conversación muy difícil.
Probando algo más complejo:
El resultado ha sido este:
"text" : "una aplicación escrita en país y basada en redes neuronales que reconoce palabras en varios idiomas",
"text" : "y que funciona de forma independiente por lo que instala servidor cargas en diccionario idioma que deseas lo ejecutas y ya hasta el puerto listo para enviarle el audio"
}
Como podéis ver… el reconocimiento es prácticamente perfecto. (si, fallan algunas palabras… pero ¿qué esperabas?)
Instalación
La instalación del servidor no puede ser más sencilla:
docker run -d -p 2700:2700 alphacep/kaldi-es:latest
Ejecutamos este docker que corre en background y nos abre el puerto 2700 para que nos conectemos vía websocket y enviarle el audio.
Conectándonos al servidor Vosk
Luego tan solo hay que descargar un cliente websocket para enviarle el archivo wav (formateado a 8Khz y mono)
git clone https://github.com/alphacep/vosk-server
cd vosk-server/websocket
./test.py test.wav
Y si le pasáis el archivo wav que tengáis… veréis cómo lo reconoce.
Usando Asterisk para conectar el ASR de Vosk
La gente de AlphaCep ha publicado un módulo para Asterisk, FreeSwitch y Jigasi (el módulo que utiliza Jitsi)
De esta manera, podéis utilizar el reconocedor de audio directamente desde el Dialplan de Asterisk:
[internal]exten = 1,1,Answer same = n,Wait(1) same = n,SpeechCreate same = n,SpeechBackground(hello) same = n,Verbose(0,Result was ${SPEECH_TEXT(0)})
Eso sí, nos avisan en varios sitios que el sistema de reconocimiento requiere de un sistema potente, ya que consume bastante memoria y procesador cada vez que tiene que hacer un reconocimiento, pero eso es algo común en cualquier ASR hospedado por nosotros, así que a tenerlo en cuenta si queremos instalarlo en nuestro sistema de comunicaciones.
Hace unos días, un amigo me dejó un aparato muy curioso. Por la descripción me recordaba a otros que ya había visto anteriormente, pero cuando me comentó que este aparato es del creador del Snom One (una centralita embebida para pequeñas empresas que sacó Snom hace varios años) consiguió llamar más aún mi curiosidad y le pedí que me lo dejara para echarle un vistazo más de cerca.
El Vodia IO es un dispositivo que incluye:
Un router neutro de redethernet (como centro de nuestra red interna, o acceso a Internet: firewall, gestión de puertos, fibra, adsl, etc.)
Un access point Wifi a 2.4Ghz y 5Ghz
Una base DECT donde conectar teléfonos inalámbricos que sean compatibles con GAP (Generic Access Profile).
Una centralita VoIPmultitenant donde poder configurar no una centralita (un dominio) si no varios dominios donde conectar softphones, operadores SIP y los teléfonos DECT, además de un buen montón de posibilidades de configuración: locuciones, IVR, buzón de voz, etc.
Un equipo muy completo enfocado a una empresa pequeña o mediana (en la que podremos ponerle una centralita independiente a cada uno de los departamentos si lo deseamos, disponer de varios teléfonos inalámbricos y que nos haga de router). Ahora vamos a ver cómo es este aparato super-completo.
Aspecto exterior del Vodia IO
El Vodia IO viene con una fuente de alimentación externa y algunos cables aunque lo que llama la atención es el frontal. Una pantalla frontal donde nada más encenderla aparece la dirección IP para acceder y configurarlo.
La parte delantera ya tiene un buen aspecto, botones que podamos configurar sin necesitar de un ordenador. Tampoco es que vayamos a tocar mucho ahí, pero siempre viene bien.
La parte trasera llama mucho más la atención, ya que ahí están todos los conectores de todo lo que podemos enchufar: – 2 teléfonos analógicos – 2 puertos USB (para conectar en red o labores de mantenimiento) – 4 puertos de red Gigabit – 1 puerto WAN Ethernet Gigabit – 1 puerto de fibra óptica – 1 puerto RJ11 para líneas ADSL
Lo primero que vemos nada más encender, en cuanto conectamos el puerto WAN a Internet, es que el sistema se conecta para actualizarse a su última versión, lo cual puede llevar un buen rato. Se reinicia varias veces hasta estabilizarse en la última versión estable. Es algo que hace por si sólo, aunque se puede deshabilitar y que se actualice manualmente.
Configuración del Vodia IO
Aunque procedan del mismo creador, ni el exterior ni el interior tienen nada que ver con el que tenía el Snom One, salvo una cierta característica en común que suelen tener, en mi opinión, los interfaces de los productos de origen alemán: no se pueden decir que tengan un aspecto visual deslumbrante, un tema moderno con la última tecnología en frontend… pero lo importante es que son robustos y funcionan tal y como se espera.
El frontal deja claro que es un producto alemán, aunque se puede cambiar el idioma
Al acceder podemos tendremos a la vista un menú bastante intuitivo (visto la cantidad de cosas que se pueden hacer) en el que podremos configurar cualquier aspecto típico de un router neutro (rutas, port forwarding, redes wireless, etc.) que además también es wireless.
Por supuesto, este artículo no es sitio suficiente como para explicar cómo configurar este dispositivo, pero sí que hemos grabado un pequeño video donde podemos ver el recorrido del menú y las diferentes acciones que podemos llevar a cabo.
Si bien es cierto que el menú ofrece la posibilidad de trabajar con él en castellano/español, siempre he preferido la versión en inglés porque las traducciones a veces no son lo suficientemente consensuadas como para entender qué hacen o para qué sirven.
Recorrido sencillo por las opciones del Vodia IO
Como podéis ver, éste sistema tiene un gran número de opciones para configurar una centralita estándar (IVR, captura de llamadas, buzón de voz, salas de conferencia, así como cambio de logotipo, subida de locuciones, etc…) pero además, si os habéis fijado en el vídeo, llama la atención algunas características como:
También llama la atención que, si bien utilizamos una empresa (dominio) «localhost«, es posible crear otros, pudiendo utilizar este sistema para ofrecer servicio a varias pequeñas empresas de forma simultánea.
Unboxing Vodia
Frontal
Puertos de conexión
Frontal
Frontal
Pantalla
Vista general
En resumen…
Un dispositivo muy interesante para ciertas empresas que necesiten un todo-en-uno tanto para una pequeña como una mediana empresa que necesite una centralita completa, fácil de instalar, desplegar y configurar.
Si le puedo poner a una pega, no es a este dispositivo en particular, si no a la propia idea de tenerlo todo en un único aparato, ya que en caso de rotura, nos quedaríamos sin centralita, sin teléfonos y sin conexión a internet. Un punto demasiado crítico que nos obligaría a tomar medidas como, por ejemplo, tener otro de respaldo por si el principal se rompe. Un sistema de alta disponibilidad con otro Vodia IO para red, DECT, wifi, etc. (no solo para PBX) sería lo único que le echaría en falta a este aparato. (si lo tiene, no lo he encontrado)
Si queréis una demo, más información o ver alguna característica que os pueda interesar, precios, etc. os animo a que entréis en la página en español Vodia.es y preguntéis ahí.
En la actualidad hay cientos de softphones, cada uno orientado a un público muy concreto, aunque la mayoría cumplen las funciones básicas. No obstante, según los usuarios (su uso, personal o empresarial, país y costumbres, etc.) suelen requerir algunas funcionalidades que a menudo no vienen de serie y es necesario adquirir alguna versión superior.
En el ecosistema de la manzana hay una lista bastante curiosa de softphones, y si bien los lenguajes de hoy día permiten compilar la aplicación a los típicos sistemas operativo: (Windows, Linux y Mac) por determinadas circunstancias, la lista de software VoIP compatible con Mac es incluso menor a la de Windows y Linux.
Cuando uno busca un softphone para Mac, lo primero que encuentra es una gran cantidad de aplicaciones bloqueadas para trabajar con un operador en concreto. Este tipo de aplicación no nos interesan, ya que buscamos un software que podamos configurar con nuestros propios parámetros, nuestra propia centralita y nuestros propios codecs.
A continuación vamos a ver la lista de los principales softphones para MacOSX a modo de recopilatorio, por lo que si conoces alguno que no esté en esta lista y creas que debería, te invito a que lo dejes en los comentarios para añadirlo:
Otro de los clásicos entre los softphones que funcionan en MacOSX de siempre, ha sido Bria. La versión gratuita pasó de llamarse X-Lite a Bria Solo y, junto con Zoiper, uno de los más utilizados debido a su popularidad. Una de las desventajas es que la versión gratuita no dispone de algunas funcionalidades muy básicas como transferencias, además de mostrar publicidad. No obstante, la versión comercial si que trae todas esas funcionalidades y muchas otras. Tiene versión gratuita y comercial Web: https://counterpath.com/ Descargar: https://counterpath.com/try-now/
Todos estos softphones han sido comprobados y funcionan perfectamente. Tal y como comentamos, echamos en falta algunas características en la versión gratuita que sí existen en las versiones comerciales: transferencias, códec G729 e incluso grabación bajo demanda. Otra de las características interesante es la posibilidad de disponer de varias líneas para poder movernos entre ellas en el caso de querer poner en espera a alguien y llamar a otra personas. Esta funcionalidad no siempre está disponible.
Hace poco escuché hablar sobre Wahay, un proyecto de software libre que acaba de nacer y que permite a varios usuarios conectarse entre sí y poder hablar en una sala común de forma descentralizada y segura.
La mayoría de sistemas VoIP utilizan un sistema centralizado que aporta determinadas ventajas (gestión, control, identificación, grabación, etc.) es por esto por lo que la mayoría de los sistemas de centralitas incorporan una plataforma de multiconferencia que permita realizar reuniones en grupo.
Solución habitual de multiconferencia segura
No obstante, hay otro usuarios que pueden preferir algo menos gestionado y menos centralizado, razón por la cual existen otras soluciones que se adaptan más a lo que ellos necesitan. A mí así en bruto se me ocurre la solución WebRTC que transmite los streams entre los usuarios en lugar de a un servidor central, aunque en este caso también se sigue exigiendo la existencia de un servidor central.
Para estos usuarios está orientado este proyecto, aquellos que requieren una solución P2P real (sin pseudonodos ni servidores centrales) además de un extra de seguridad ya que, Wahay pasa toda la información a través de pasarelas de Tor para anonimizar la conexión.
Solución que propone Wahay
Wahay se basa en Mumble, una solución libre de multiconferencia similar a TeamSpeak, que es un sistema muy utilizado principalmente por jugadores para hablar entre ellos durante una partida, aunque no es muy utilizado en el entorno empresarial. No obstante, esta solución y el hecho de que esté detrás de Tor me hace pensar que está orientado a otro tipo de soluciones que buscan la seguridad y privacidad ante conversaciones algo más «delicadas».
Con esto de la cuarentena/confinamiento/reclusión o como queráis llamar al hecho de quedarse en casa para evitar que el Coronavirus COVID-19 se propague demasiado rápido por toda la población, son muchas las personas que están ingeniándoselas para trabajar desde casa, evitar los espacios comunes y aprovechar el tiempo en casa para hacer cosas que normalmente no tenemos tiempo para hacer: aprender cosas nuevas, leer, pasar más tiempo con los niños o incluso hacer ejercicio.
En cuanto al teletrabajo, esta ha sido una oportunidad increíble para poner en práctica algo que llevamos defendiendo desde siempre: la posibilidad de teletrabajar como forma de aprovechar al 100% el tiempo que no es posible compartir en una oficina (bien porque estás enfermo pero puedes trabajar, porque tienes que quedarte al cuidado de una persona que te puede requerir en un momento dado pero que te puede dejar trabajar el 95% del tiempo, o simplemente porque estás convaleciente pero tienes la mente perfectamente para poder trabajar tranquilamente a distancia).
Hace unos años en una empresa que conozco bastante bien se implantó un programa piloto: ofrecer teletrabajo a cada uno de los trabajadores durante 15 días al año siempre que hubiera un motivo razonable y se tuvieran los medios necesarios. Como empresa dedicada a la VoIP, la mayoría de los medios necesarios estaban perfectamente cubiertos: teléfono VoIP, un sistema de VPN al que conectar el ordenador personal, y cambiar las herramientas «locales» a herramientas de trabajo vía web y todos los documentos mediante herramientas Cloud (nada de enviar archivos directamente al cliente de correo que podrían ser foco de virus/troyanos/etc.). Todos los documentos eran enlaces a un sistema remoto.
No obstante había que preparar algunas cosas como una VPN para conectarse a la red, acostumbrar a todos a utilizar un sistema de comunicación asíncrona como el chat en lugar de algo presencial, y por supuesto, minimizar el número de tareas que requerían hacerse de forma presencial y buscar la manera de poder hacerlas en remoto dentro de lo posible. Ese proyecto piloto, no sólo fue un auténtico éxito si no un autentico acierto y sentó el precedente de que, si uno es responsable en su día a día, puede trabajar perfectamente desde su casa si realmente lo necesita. Por supuesto, el que no es responsable, no lo va a ser ni aunque esté sentado en la oficina.
Preparar todo esto para empezar a teletrabajar fue un esfuerzo que llevó bastante tiempo, pero como digo, el resultado fue un auténtico éxito que consiguió que la productividad no bajara incluso en aquellos momentos en los que alguien se encontrase de viaje, en un hotel. En esta ocasión, por el coronavirus, todo este cambio se pretende implantar en apenas una semana, algo que efectivamente, no sólo no da el efecto deseado, si no que contraproducente ya que se da una imagen de teletrabajo en la que la gente no está preparada, las herramientas no son las adecuadas y la seguridad brilla por su ausencia.
Uno de los beneficiados con las medidas impuestas por el gobierno han sido los sistemas de comunicaciones empresariales: chats, mensajería instantánea, softphones, servidores VPN, servidores RDP (que ya hablaremos en otro artículo sobre las consecuencias de hacer las cosas rápidamente y mal), y sobre todo los sistemas de videoconferencia.
Sistemas de videoconferencia hay muchos y muy variados, muchos son publicitados en series y películas pero luego hay que valorar realmente las cosas por su peso y no por su gasto publicitario. Si bien el sistema «Telepresence» de Cisco es uno de los más famosos es poco práctico debido a su coste y su dificultad de implantación entre las personas con las que se va a realizar la videoconferencia. Otros sistemas como los de Polycom son ‘exclusivos’ de Polycom y, al igual que con el de Cisco, sólo se comunican con sistemas de la misma marca. ¿Qué podemos hacer cuando queremos hacer una videoconferencia con alguien y no queremos que haga un consumo excesivo en hardware y licencias? Optar por soluciones abiertas y libres.
Protocolos abiertos en sistemas críticos
No sólo hemos sido testigos del gran auge de los sistemas de videoconferencia, si no que se han convertido en una de las fotografías más representativas:
Foto: Reuters
Seguramente la foto superior les sonará: el presidente Pedro Sánchez haciendo una videoconferencia con algunos ministros. Pero a los que trabajamos en esto nos fijamos además en otras cosas:
Pulsa para ampliar
Para empezar (si hacéis click en la fotografía) podréis ver el sistema completo de videoconferencia de Grandstream formado por un GVC3202, un GAC2500 y el software IPVideoTalk de Grandstream.
Eso ya me llamó la atención, es un sistema comercial de videoconferencia pero basado en protocolos abiertos (SIP, XMPP, WebRTC, etc.).
Pero acto seguido seguimos viendo otros sistemas de videoconferencia de otros líderes políticos con un logotipo que nos llama la atención: Jitsi-Meet
Si os fijáis cuando veáis la televisión, posiblemente veáis el logotipo de Jitsi en la esquina superior izquierda. No obstante, la mayoría lo eliminan para tener una visión completa. Curiosamente, los sistemas de videoconferencia propietarios no permiten eliminar la marca de agua con el logotipo: Ventajas del software libre.
Una de las ventajas de Jitsi es la posibilidad de instalarlo en nuestro propio servidor, pudiendo utilizarlo sin depender de terceros y personalizarlo a nuestro gusto e intereses. Esto ha hecho que sea uno de los sistemas más utilizados por colectivos que buscan ese extra de seguridad en sus comunicaciones diarias.
Jitsi-Meet cuenta con un servicio público Meet.jit.si que está siendo utilizado ampliamente por la gente como medio rápido y fácil de hacer una videoconferencia aprovechando este tiempo de confinamiento para ofrecer cursos (como éste de programación basado en TDD de nuestro amigo @J.J. Merelo)
Otros utilizan Jitsi-Meet para hacer videoconferencia entre compañeros de empresa, reuniones virtuales que no se han podido celebrar presencialmente o incluso simplemente como «sustituto a la oficina presencial«.
Jitsi-Meet es un software libre que ayuda a realizar videoconferencias a quién lo necesite y éste es un buen momento para ponerlo en práctica y demostrar tanto su calidad como su utilidad estos días.
La posibilidad de instalarlo con un simple apt-get install jitsi-meet hace que cualquiera que desee utilizarlo de forma independiente al servidor público que ofrecen, pueda hacerlo con total libertad.
Incluso Jitsi dispone de una aplicación móvil con la que poder hacer videoconferencia desde nuestro dispositivo móvil/tablet y que podremos conectar a nuestro servidor propio de Jitsi-Meet para poder utilizarlo internamente.
Hay muchos otros sistemas de videoconferencia basada en software libre, algunos más orientados a usuarios finales y otros más a desarrolladores, algunos más DoItYourself/BúscateLaVida, aunque la mayoría ofrecen servicios de ayuda/soporte si lo necesitas por un módico aporte económico. (siempre es mejor eso que estar pagando licencias periódicamente por cada usuario).
Decía hace poco en twitter que si con esto que está pasando, la empresa no aprovecha y empieza a meter el teletrabajo como parte de la cultura empresarial y organizativa de las nuevas empresas del siglo XXI, podemos concluir que nunca lo hará, porque no hay mejor ocasión, mejor excusa, ni cuenta con más apoyo que ahora para dar el paso y entender que el futuro del trabajo en las tecnologías de la información pasa por la deslocalización, y dejar el presencialismo o presentismo laboral como una característica propia de las empresas del siglo pasado.
No hay más que ver en Google Trends que el interés en el teletrabajo se ha disparado gracias a la necesidad (ni modas, ni oportunidades técnicas,… NECESIDAD) y es justamente ésta la razón por la que herramientas como la videoconferencia, la telefonía IP, y las centralitas en la nube están cumpliendo con lo que se prometió hace más de una década: mantener las comunicaciones allá donde estés sin importar cableado, infraestructuras, etc. y sin tener que hacer cambios, tan solo tener acceso a Internet.
Quizá por la dificultad de encontrar más talento «local» o dispuesto a desplazarse hasta donde se encuentra la empresa, lo que está claro es que cada vez son más las empresas que optan por herramientas sistemas de comunicación y una cultura empresarial que facilite el trabajo y la productividad entre personas que no se encuentran físicamente en la misma oficina, así que, al menos es interesante contar con esta posibilidad.
El siguiente artículo está escrito por Fabian Pignataro
Cada vez que el caos despliega sus alas sobre la aparente ordenada realidad que subyace los cimientos sobre los que se construyen los paradigmas que rigen las sociedades, el individualismo no fue precisamente la actitud que ayudó a la humanidad a salir adelante y ponerse nuevamente en marcha. Por el contrario, el accionar COMUNITARIO resultó el mejor aliado y motor de la superación en las diversas crisis que hemos atravesado.
Como dicen en mi país, «cuando las papas queman», afloran dos actitudes posibles:
(a) El «sálvese quien pueda», que ante el infortunio ajeno se concentra en el cuidado exclusivo del “propio ombligo” o bien olfatea un negocio lucrativo basado en la desesperación del prójimo.
(b) El «cuidarnos como hermanos», que fomenta una actitud de COMUNIDAD que vela y apuesta por un accionar colaborativo que tiende inequívocamente al bienestar individual y colectivo simultáneo.
Este artículo se enmarca dentro del ítem (b) desde una perspectiva de generación de software. Un grupo de profesionales IT, impregnados con esta clase de valores humanos, está impulsando una aplicación para Call & Contact Centers de Software Libre basada en la amigabilidad de las interfaces y facilidad de gestión desde un enfoque 100% Web & WebRTC que resulta especialmente ideal para estos tiempos de TRABAJO REMOTO.
OMniLeads es una aplicación de software libre capaz de hacer funcionar un Call/Contact Center con operaciones Inbound & Outbound (Blended).
Supervisión de usuarios WebRTC (channel spy, wishper entre otras funciones)
Reportes de productividad
Consola de Agente WebRTC
La aplicación está disponible para su libre instalación y uso. De esta manera, todo aquel que desee montar un Call/Contact Center como servicio a la comunidad, o bien para afrontar la recesión económica disminuyendo costos al prescindir del pago de licencias, puede instalarla siguiendo los pasos desplegados a continuación.
¿Como lo instalo?
Para ejecutar la aplicación es necesario contar con una instancia de GNU/Linux CentOS-7 Minimal. Podemos pautar una operación de 50 a 70 usuarios con un servidor de 8GB de RAM, CPU de las características de un Core-i7 y 100 GB de disco SSD o similar. No obstante, la aplicación puede escalar fácilmente hacia cientos de operadores simultáneos amplificando la potencia del servidor o bien acudir a un despliegue clusterizado (si la cosa es bien grande).
Deployment
El tipo de Deploy aquí expuesto es el más básico de todos y tiene que ver con descargar el repositorio sobre el host que hospedará la Aplicación para luego ejecutar un script bash que lanza un playbook Ansible.
Pre-requisitos
El host sobre el cual realizaremos la instalación debe contar con acceso a internet sin ningún tipo de restricción, con un hostname y dirección IP fija configurados.
Se plantea la instalación más básica: Ansible Self-Hosted
Luego de ingresar por SSH como root a nuestra instancia CentOS, se ejecutan algunos comandos previos al deploy:
Para luego posicionarse sobre el directorio “deploy/ansible” y allí configurar algunos pocos parámetros del sistema como la contraseña de acceso a la aplicación y otros.
cd ominicontacto/deploy/ansible
La configuración de dichos parámetros se hace en el archivo allí disponible inventory.
Como se puede apreciar cada parámetro está explicado dentro del archivo en cuestión, sin embargo resaltamos aquí debajo (en negrita) los que deben ser alterados como requisito excluyente para el despliegue de la aplicación bajo este esquema Ansible Self-Hosted.
############################################################## If you are installing a prodenv (PE) AIO y bare-metal, change the IP and hostname here ###########################################################
[prodenv-aio]
#localhost ansible_connection=local ansible_user=root #(this line is for self-hosted installation)#X.X.X.X ansible_ssh_port=22 ansible_user=root #(this line is for node-host installation)############################################################## Database #
# SET POSTGRESQL PASSWORD ##############################################################
postgres_database=omnileads
postgres_user=omnileads
#postgres_password=my_very_strong_pass############################################################## Web Admin ## SET WEB ADMIN PASSWORD ###############################################################admin_pass=my_very_strong_pass######################################## AMI for wombat dialer and OMniLeads ########################################
ami_user=omnileadsami
ami_password=5_MeO_DMT
###################################################### Wombat dialer credentials and MYSQL root password ######################################################
dialer_user=demoadmin
dialer_password=demo
#mysql_root_password=my_very_strong_pass###########################################################################
# Set the timezone where the nodes are. UNCOMMENT and set this if you are doing a fresh install ####################################################################################TZ=America/Argentina/Cordoba
Sobre todas las líneas indicadas, se debe extirpar el carácter ‘#’ e introducir una contraseña personalizada para los parámetros del tipo password y la zona horaria de su país para el caso del parámetro TZ (Time Zone).
Una vez listo el archivo de inventario, se procede con la ejecución del deploy:
./deploy.sh -i --iface=NIC_NAME
dónde NIC_NAME es el nombre de la interfaz de red de la instancia CentOS que implementa la dirección IP que el sistema va a utilizar.
Una vez finalizado el deploy, nos encontramos con una pantalla similar a la siguiente que nos indica que estamos listos para comenzar a configurar el sistema.
Finalmente se procede con el reinicio del host y posterior acceso por web.
Primer acceso al sistema & configuraciones
Para acceder y comenzar la configuración del sistema ingresar vía https a la IP del host.
Utilizando admin como usuario y la contraseña establecida en el archivo inventory (admin_pass).
De ahora en más todo apunta a comenzar con algunas configuraciones iniciales para luego generar los Troncales SIP para tomar y enviar llamadas con la red telefónica pública y posteriormente poner en marcha vuestras campañas Inbound / Outbound.
Por mucho que pase el tiempo, y más ahora que el número de sistemas VoIP en la nube (o en remoto) aumenta, el número de ataques también aumenta considerablemente y es entonces cuando se hace necesario el uso de herramientas que nos ofrezcan la seguridad que necesitamos para poder estar seguro que nuestro sistema está controlado y no vamos a ser víctimas de un ataque mientras no estamos pendientes. Esta es la función de SIPCHECK, una herramienta que se conecta a Asterisk y vigila de accesos ilegítimos de direcciones IP desconocidas manteniendo nuestro Firewall actualizado con las direcciones IP de los atacantes.
En 2010, durante una comida en el curso de Asterisk Advanced de Bilbao, surgió una idea muy simple pero efectiva. Uno de los principales problemas que tenían muchos de ellos era la inseguridad que producía recibir ataques en los Asterisk que debían estar expuestos por Internet.
Ni que decir tiene que surgieron muchas ideas: utilizar VPN, cambiar a puertos no estándar, etc. y tras la exposición de los problemas y las posibles soluciones, una de ellas se presentó tan sencilla como fácil de implementar: Generar una aplicación que analizara el log de Asterisk y cuando detectara errores de autentificación, baneara automáticamente esa IP compartiendo dicha IP con el resto de la comunidad.
Esto fue una gran idea y así se hizo en la versión inicial de SIPCheck. Cuando el sipcheck detectaba un ataque, obtenía la dirección IP y la compartía con el resto de la comunidad para que todos pudieran tomar nota y rechazarla en los firewalls.
El resultado de esto fue algo más inesperado de lo que pensábamos: miles de direcciones IP baneadas (incluso algunas legítimas) y firewalls con tablas inmensas que incluían direcciones IP que, en algún momento del pasado atacaron a alguien. Estaba claro que tener un firewall con decenas de miles de direcciones IP que, en algún momento pudieron ser víctimas de un ataque y sirvieran de proxy para otro atacante no era la solución, ni siquiera para tenerlo en una tabla ACL de «IPs denegadas» ya que el 90% de esas direcciones IP no van a volver a atacarnos. La solución a esto, sin duda, era otra.
Ante esto, sucedieron varias modificaciones (añadir IPs con un registro de fecha y hora para que expiraran pasado un tiempo, introducir únicamente aquellas direcciones IP comunes que hayan sido baneadas por varios usuarios distintos, etc.) y los resultados fueron interesantes, aunque seguía sin obtenerse el resultado esperado.
Para ello, en 2014 se publicó SIPCheck 2, una versión nueva que incluía un registro sobre las direcciones IP baneadas en una web local que se podía consultar y añadir o eliminar aquellas IPs en tiempo real. Se eliminó la parte comunitaria ya que entendimos que si a un usuario de Japón le ataca una IP, no tiene por qué atacar a otro de Nápoles y, de esta manera se reducía el número de direcciones IP en el firewall. Se añadió soporte IPSet que mejora el funcionamiento de grandes listas de direcciones IP baneadas y aún así, la lista seguía sin ser efectiva (seguían apareciendo nuevas direcciones y seguíamos teniendo en el firewall direcciones que ya no se usaban). Al menos con SIPCheck v.2 podíamos eliminar manualmente aquellas direcciones antiguas.
Es en 2019 que, tras algunos cambios y nuevos proyectos surgió la idea de renovar el SIPCheck para paliar algunos defectos del SIPCheck inicial (que todavía hay gente utilizándolo) así como para reducir la carga al mínimo (muy inferior al de SIPcheck 2 y por supuesto al de Fail2Ban), empezamos a desarrollar la tercera versión nuevamente pero con todas las mejoras.
SIPCheck v.3
Funcionamiento
Esta versión de SIPCheck utiliza dos mecanismos diferentes para controlar los eventos: – Mánager de Asterisk: (el 99% de los ataques) Con esto se controlan los intentos de login erroneos, los correctos y gracias a esto evitamos sobrecargar el sistema cuando el Asterisk es muy grande y genera mucha información en el log. – Archivo /var/log/asterisk/messages: (el 1% restante) Con esto se controlan los INVITES sin autentificar y que no aparecen en el manager. Está claro que con el parámetro ‘allowguest = no‘ ni siquiera aparecerán estos INVITES, pero de alguna manera había que controlar este caso.
El funcionamiento de esta versión se basa en la gestión automática de 3 listas:
Lista blanca : con direcciones IP confiables y que no deben estar baneadas aunque se reciban peticiones de registro con contraseña erronea. (Esta lista blanca la formarán aquellos que incluyamos en el archivo ‘whitelist.txt’ y aquellas direcciones IP que se hayan registrado correctamente.)
Lista de sospechosos : con direcciones IP procedentes de algunos ataques pero no los suficientes como para considerarlos ataques. Cuando se recibe un intento de registro con una contraseña inválida, se almacena aquí hasta que el número de intentos supere un número determinado /y configurable/. Si un sospechoso deja de enviar los intentos, el sistema lo eliminará de la lista de sospechosos pasado un tiempo.
Lista negra : con direcciones IP oficialmente considerados como ataques. Estos son auténticos atacantes y cuando están en la lista negra, el SIPCheck también lo incluye en el firewall impidiendo volver a acceder al sistema, por lo que el sistema es autónomo y no tenemos que preocuparnos. En esta lista permanecerá un tiempo configurable tras el cual se eliminarán tanto de la lista negra como del firewall, manteniendo a este limpio de atacantes antiguos.
Cuando SIPCheck detecte un ataque procedente de una IP, lo añadirá a la Lista de sospechosos y permitirá seguir recibiendo tráfico. Si recibe varias peticiones idénticas entonces pasará a considerarlo como un ataque oficial y lo añadirá a la lista negra y al firewall impidiendo más tráfico procedente de esa IP.
Si una IP se ha registrado correctamente en nuestro sistema, entonces se considera que esa IP pertenece a alguien «confiable» por lo tanto lo añadiremos a la Lista Blanca durante un tiempo evitando considerarlo atacante durante el tiempo en el que esa IP esté en la lista blanca. Esto impedirá banear una dirección IP de una empresa únicamente porque un teléfono tenga una contraseña errónea.
Todos los valores son configurables: número de contraseñas erroneas, tiempos en cada una de las listas, etc.
Se tiene incluso un archivo ‘whitelist.txt‘ donde podremos indicar las direcciones IP que jamás deberán serán baneadas por el SIPCheck (operadores, IPs de gestión, etc.)
Objetivos
El objetivo de esta aplicación son varios:
Orientado a sistemas de alta carga: Probándolo en sistemas de alta carga, el consumo se disparaba, por lo que había que buscar una forma alternativa de minimizarla. Para ello se utiliza principalmente el ‘manager’ de Asterisk y para algunos casos puntuales el messages como complemento y evitar la sobrecarga de analizar cada línea del log de Asterisk.
Evitar falsos positivos: En versiones anteriores, si un teléfono enviaba varias veces una contraseña erronea, el SIPCheck baneaba la IP entera. En esta versión, si una IP es registrada correctamente, pasa a una lista blanca que impide activar el protocolo de ataque en dicha IP compartida por varios teléfonos, seguramente de la misma empresa. De esta manera evitamos que un teléfono mal registrado en una empresa banee la IP del resto de la empresa.
Persistente en el tiempo: Si se reinicia la aplicación, todos los datos y direcciones IP de todas las listas se mantienen y se vuelven a banear en firewall (si no lo estaban ya).
Configurable: Se ha añadido un archivo sipcheck.conf donde poder configurar prácticamente cualquier parámetro que permita personalizar la aplicación.
La instalación es bastante sencilla ya que tan solo hay que seguir las 4 instrucciones del README para instalarla.
Y para comprobar qué está haciendo, todo queda registrado en un archivo de log en /var/log/sipcheck.log
Con esta aplicación, en varios Asterisk expuestos en Internet a modo de honeypot sin ningún otro tipo de protección, el sistema ha detectado y bloqueado cientos de ataques y lo mejor es que mantiene un firewall bastante reducido ya que las direcciones IP desde donde se producen los ataques dejan de atacar cuando empiezan a ser bloqueadas. Gracias a estos honeypots hemos aprendido muchas cosas nuevas sobre estos ataques que nos permitirán seguir mejorando el SIPCheck para conseguir detectar nuevas formas de ataques.
Si tienes comentarios o quieres dejarnos un feedback sobre esta aplicación puedes escribirnos un issue en Github, un comentario en el canal Telegram de @sinologic o en el correo electrónico sipcheck@sinologic.net
En 2014 ya hablamos cuando Snom presentaba su nuevo terminal Snom M65, un teléfono DECT que contaba con una base DECT-SIP y que permitía conectar las ventajas de la telefonía DECT al mundo de la VoIP.
5 años más tarde, Snom vuelve a presentarnos una reestructuración de su arsenal inalámbrico con sus nuevos terminales M70, M80 y M90, más orientados al entorno empresarial con muchas características que lo hacen ideal para ciertos entornos en los que la calidad de sonido no debe ser sacrificada por la necesidad de movilidad dentro de un recinto.
Ventajas de un teléfono DECT frente a un teléfono Wifi
Menos sensibilidad a ruidos procedentes de redes wifi ajenas
Tecnología orientada a transmitir VOZ
Servicios telefónicos integrados en el propio protocolo
Antena DECT Snom M900
Las antenas DECT Snom M900 es una antena DECT con conexión Ethernet con el que poder montar una infraestructura multicelda para crear una cobertura única formada por varias antenas DECT conectadas entre sí.
El sistema multicelda es similar al mecanismo que hoy día se utiliza para la cobertura de teléfonos móviles, en el que se sitúan antenas geográficamente de manera que formen una especie de panal de abeja permitiendo que una persona pueda estar hablando mientras cambia de cobertura de una antena a la cobertura de la siguiente. Si bien para ello hace falta que haya un cierto «solapamiento» de las coberturas, y una sincronización de los datos que se envían desde todas las antenas, esto último se hace mediante cableado Ethernet permitiendo así ahorrar en canales DECT disponibles.
Otra de las ventajas es la capacidad de formar una única red global (una cobertura única) con la que nos evitamos el engorroso trámite de tener que estar registrando y desregistrando terminales en las bases. Este sistema bastante conocido en el mundo GSM, ahora también está disponible en el entorno DECT y permite crear grandes mapas de cobertura con unas pocas antenas.
Ejemplo de cobertura multicelda
Una de las ventajas de los sistemas multicelda de Snom es que son capaces de conectar hasta (ojo a esto): 4000 bases conectadas entre sí para formar una única cobertura DECT.
Está claro que nadie va a conectar esa cantidad de bases (sobre todo porque no es recomendable conectarlas a menos de 4m una de otra) por lo que si quisieramos conectar 4000 bases conectándolas cada 4 metros, necesitaríamos una superficie de unos 40.960 metros cuadrados sólo para hacer la prueba, pero la idea queda clara que prácticamente no hay límites en cuanto a la cantidad de antenas que puedes conectar para extender la cobertura.
¿Por qué no más de 8 llamadas simultaneas?
Una de las quejas / preguntas más típicas sobre el DECT era el de la limitación de las llamadas simultáneas, y es que, sin intención de meterme en temas muy técnicos que darían para un post entero dedicado a esto, diremos que el protocolo DECT tiene limitados el número de canales dedicados a comunicación por lo que, si bien sólo se pueden hacer 4 llamadas simultáneas en las frecuencias permitidas con la calidad buena, se pueden llegar a hacer «hasta» 8 llamadas simultaneas si se comprime más la señal, algo que prácticamente todo el mundo hace.
Especto DECT durante una conversación
Cobertura DECT
Al funcionar con una frecuencia determinada y una potencia máxima controlada, los rangos de cobertura son prácticamente similares entre las marcas diferenciándose unas y otras por la calidad de los componentes de las antenas, ruidos, aislamientos, etc y consiguiendo así, mejorar la calidad y la comunicación cuando se está al límite de la distancia.
Considerando que cada antena tiene una cobertura máxima de 50m. de distancia en interiores y 300m. en exteriores, ya puedes hacerte una idea de que puedes utilizar estas antenas para prácticamente cualquier instalación que necesites.
El sistema multicelda permite además, conectar todas las antenas entre sí y gestionarlas desde una antena principal con lo que la configuración es, lógicamente, mucho más sencilla que si tuvieramos que entrar en cada antena una por una configurando las conexiones.
Para saber cuantas antenas hacen falta y a qué distancia poner cada una de ellas hay que hacer muchas pruebas, evaluar el tipo de lugar donde se va a realizar la instalación, ver qué paredes u obstáculos existen y de qué tipo (madera, ladrillos, metal, etc…) y hacer un estudio de cobertura en condiciones que, inicialmente puede ser muy difícil, pero a medida que le vayáis cogiendo práctica, veréis como se le pilla el truco rápidamente.
Terminales DECT
No os voy a engañar, lo que mucha gente hace es instalar buenas antenas DECT que proporcionen una buena cobertura y luego buscan los teléfonos DECT más baratos que puedan, a fin de cuentas, si son DECT compatible con GAP, deben ser compatibles con cualquier teléfono inalámbrico DECT.
Ese es quizá uno de los mayores errores que suelen cometer algunas empresas, y es que la «compatibilidad GAP» únicamente se refiere a la capacidad básica de hacer y recibir llamadas, pero no se refiere a muchos otros conceptos básicos y requeridos por cualquiera como:
Ver el número de la persona que llama. (CallerID)
Desviar o transferir una llamada a otra extensión.
Mantener la comunicación cuando nos movemos y cambiamos de antena.
etc.
Este tipo de características no vienen incluidas en el estándar GAP, por lo que si optamos por terminales de otras marcas con la esperanza de que sean compatibles, seguramente nos llevaremos una gran desilusión y lo que nos ahorremos en terminales, nos lo terminaremos comiendo en tiempo buscando soluciones que no existen, por esta razón, siempre he recomendado utilizar los terminales más compatibles con las antenas que se utilicen y de esa manera ahorraremos dolores de cabeza, pérdida de tiempo y dinero.
Como estamos hablando de Snom, los terminales también se han actualizado y es que ahora contamos con una nueva gama de terminales DECT completamente nuevos:
Snom M70
Snom M80
Snom M90
Como se puede apreciar en la imagen, los tres teléfonos son bastante parecidos, aunque hay bastantes diferencias entre los tres, así que vamos a verlas:
Diferencia de tamaño entre el M25 (izquierda), el M70, M80 y M90 (derecha)Comparación del Snom M25 junto con el resto de teléfonos DECT
Lo primero que llama la atención es la diferencia de estilo entre el M25 y la nueva hornada. Los nuevos DECT tienen una carcasa protegida por una textura más flexible, lo que suponemos sirve para dos objetivos: mejor agarre (evitamos caídas) y mayor resistencia en caso de caída (al tener una cobertura gomosa, la carcasa amortigua el golpe).
Lo segundo que llama la atención es el tamaño, más pequeño y además, los nuevos terminales incluyen una pinza para poder llevarlo colgado desde cualquier prenda o cinturón.
La pantalla es casi el doble de grande que su homólogo Snom M25 y bastante más práctica, mientras que las teclas son más pequeñas en los modelos M70 y M80, mientras que en el M90 las teclas forman parte de la misma capa, lo que es ideal de cara a limpieza y líquidos como se puede apreciar en la siguiente fotografía:
Detalle del teclado del Snom M80 (negro) y el Snom M90 (blanco)
Los modelos M80 y M90 comparten cargador, mientras que el M70 (algo más pequeño) necesita un cargador diferente al de sus dos hermanos mayores.
Los 3 teléfonos incluyen cargadores que se alimentan mediante un conector USB-A y que vienen con un conector hembra para hacer de switch o de puente y poder alimentar, a su vez, otros cargadores, una idea muy buena y que nos permite tener todos los teléfonos cargando en el mismo sitio sin necesidad de transformadores ni enchufes.
Detalle del conector de carga del Snom M80
La configuración es bastante sencila, ya que todo se configura desde la antena DECT (en este caso, la base Snom M900) y la configuración de los 4 teléfonos, para no haberlo hecho nunca, apenas me llevó 10 minutos con la configuración la cuenta SIP inclusive, por lo que es bastante sencilla y rápida.
