Hace unos días descubrimos una aplicación que permitía enviar información a distancia de un ordenador a otro de forma inalámbrica y que no lo hacía mediante Wifi, ni bluetooth ni ningún otro sistema físico similar, lo hacía mediante QR.
Para ello es necesario disponer de los dos equipos que queremos comunicar y ponerlos uno frente al otro de manera que las webcams puedan verse entre sí.
Entonces, basta con escribir el mensaje en uno de ellos y darle a «ENVIAR DATOS», la aplicación empezará a generar códigos QR que serán recogidos por el otro sistema que lo recibirá y verificará.
El sistema, como bien puedes imaginar, no es muy práctico, de hecho no es ni rápido ni seguro, pero es una frikada muy simpática para demostrar cómo, utilizando WebRTC para manejar la cámara y un poco de ingenio, se puede enviar mensajes a distancia de forma inalámbrica sin necesidad de Wifi ni Bluetooth.
Aproximadamente en 2016, llegó a nuestras manos uno de esos proyectos de tantos que se consideran «raros», esos proyectos que, en cuanto te lo explican pasan a ser un reto entre difícil e imposible, y por otro te hace rebanarte los sesos intentando dar con la forma de hacerlo, hasta que das con la tecla… de esos que te trae una «pequeña empresa desconocida» y que, por desgracia, no dimos con la clave en aquel momento.
Quizá por eso quedó olvidado hasta hace poco en mi memoria y que consistía sencillamente en desarrollar un sistema que le diera «una vuelta de tuerca» a las salas de conferencia que normalmente utilizamos (al menos así lo plantearon desde un principio), que permitiera a varias personas hablar entre sí, pero con varios detalles importantes y necesarios:
Los participantes de la sala tiene cada uno dos coordenadas (X,Y) de manera que estén situadas en una posición de un plano.
Cada persona únicamente podrían escuchar a aquellos usuarios que estuvieran dentro de un radio determinado. Si las coordenadas cambian y la distancia entre los usuarios saliese del rango, deberían dejar de escucharse entre sí.
El volumen deberá variar según la distancia entre sus usuarios. Aumentar conforme más cerca estuvieran los usuarios, y más bajo cuanto mayor distancia estén las coordenadas.
Cada «sala», deberá ser capaz de soportar salas con más de 100 usuarios
y algunos detalles más…
Nada más hablar de «salas de conferencia», lo primero que pensamos es cómo hacerlo con Asterisk, aunque rápidamente lo descartamos por que sería demasiado complicado. Las salas de conferencia de Asterisk están creadas pensando en un tipo de sala de conferencia muy concreta, así que la única posibilidad era desarrollarlo a mano usando WebRTC, ya que permitiría control en tiempo real del audio de varios puntos, pero por aquel entonces, WebRTC aún no era un estándar (llegó a hacerse estándar años más tarde, en 2021) y además el sistema de multiconferencia de audio mediante WebRTC, hablando con Iñaki Baz durante el FOSDEM de 2017, aunque posible, en aquel entonces no era nada fácil y requería un MCU (Servidor de conferencias) bastante potente y aún por desarrollar (y esto lo decía tras haber dado una conferencia sobre servidores de conferencias).
Iñaki Baz hablando sobre Mediasoup (Fosdem 2017)
Así que se explicó a la empresa interesada las ventajas e inconvenientes de cada posibilidad y que, en aquel entonces, aún le faltaba un poco para poder llevarlo a cabo, no obstante, el camino era sin duda utilizar WebRTC cuando se estabilizase y los avances que surgían rápidamente, lo permitieran.
Y hasta ahí… el proyecto quedó en el olvido… hasta que hace poco retornó a nuestra memoria.
Chat de Proximidad: La VoIP en los juegos
Años después, jugando a varios juegos tipo Shooter, aparece una característica muy interesante: el chat de proximidad, un sistema que permite escuchar a otras personas si éstas se encuentran relativamente cerca y hablan entre sí, lo que permite al jugador saber que tiene cerca a otros jugadores e incluso poder hablar con ellos si se encuentra lo suficientemente cerca virtualmente, permitiendo crear verdaderas salas de conferencia de muchos jugadores.
Tal y como se pedía en los requisitos, el chat de proximidad está «limitado» a 100 participantes, que no están hablando todos a la vez, ya que la mayoría están fuera del rango necesario para poder hablar entre ellos, pero sí pueden llegar a coincidir en un mismo espacio varias personas y que puedan hablar entre sí más de 50, lo que lo hace prácticamente inviable para mantener una conversación, pero sí para darte cuenta que el chat de proximidad es una herramienta muy divertida para hacerte la idea de que estás con mucha más gente.
En apenas dos años, se han disparado los juegos que incluyen el chat de proximidad, esta característica que ha mejorado la interactividad multiusuario a través de internet, lo que convierte en estos juegos en algo mucho más divertido al poder hablar en persona con extraños que están «virtualmente» cerca aunque se encuentren físicamente bien lejos. Es tal el éxito de esta característica que ya han aparecido servidores y clientes (plugins) para dotar de chat de proximidad a juegos que originalmente no lo incluyen.
Incluso hay herramientas de terceros (plugins o mods) que dotan del chat de proximidad incluso si el juego original no lo incluye y analizando el código, se puede ver que la solución planteada era justamente la que habíamos comentado. Prácticamente si un juego en el que los usuarios pueden desplazarse líbremente sobre un mapa, el chat de proximidad será algo obligatorio.
El metaverso, la realidad virtual, los juegos online multi-usuarios,… hacen que esto del chat de proximidad sea algo a investigar mucho más en serio y si, además aprovechamos las ventajas de las herramientas y librerías que han aparecido en los últimos años, aparecen algunos conceptos muy, muy interesantes.
Aunque si lo que queréis es probar de forma externa el chat de proximidad rápidamente, os recomiendo que entréis en esta web: https://app.chatmosphere.cc/session/sinologic con varias amigos y hagáis la prueba de lo que puede llegar a ser una característica que la incluyan prácticamente cualquier aplicación o página web, no únicamente juegos online. (Código fuente de chatmosphere)
Herramientas que usarían el chat de proximidad
¿Qué herramientas podrían incluir el chat de proximidad? Básicamente cualquier juego online. Es una opción voluntaria, por lo que cualquiera puede desactivarla, pero el chat de proximidad será útil cuando despegue el mundo de la realidad virtual y el metaverso. Herramientas donde puedas ir virtualmente a un aula y escuchar únicamente al profesor de esa aula o escucharlo con un volumen más bajo si estás más alejado, dará esa sensación de realismo que necesita este tipo de herramientas.
Otra posibilidad más avanzada sería la introducción de «obstáculos» que reduzcan el volumen o incluso distorsionen el audio que escuchamos. Esto quizá sería algo que veremos en breve y es que, de la misma forma que el famoso «raytracing» ha revolucionado los juegos incorporando gráficos hiper-realistas, el mismo sistema se puede utilizar para el sonido y permitir a una persona poder escuchar a otra si las condiciones de la «sala» lo posibilitan. No es lo mismo hablar en una habitación, que detrás de una pared o que en un espacio abierto.
Está claro que para ello aún falta, aunque viendo lo rápido que avanza todo, y con la capacidad de la inteligencia artificial, podríamos tener estas modificaciones a la vuelta de la esquina y que el chat de proximidad sólo sea el comienzo de la VoIP en muchos más ámbitos.
Hay ocasiones en las que podemos pensar que estamos en medio de una película de ciencia ficción cuando, en apenas 5 años hemos pasado de hablar por teléfono como una de las formas de comunicación más habituales, a tener reuniones por videoconferencia varias veces por semana con 5, 10 o incluso 20 personas de forma simultánea en un mosaico de pantalla donde poder ver a todos los participantes. ¿y qué ha ocasionado este cambio? Una pandemia… ¿realmente no os parece que es cosa de ciencia ficción?
Lo cierto es que la pandemia no ha ocasionado nada… la tecnología estaba ahí, sólo que el miedo por avanzar, por probar cosas nuevas, por no cambiar la forma en la que hacemos las cosas hace que no nos atrevamos a dar el salto y probar cosas que realmente podrían potenciar mucho más las comunicaciones. Ha sido necesaria una pandemia, una obligación de quedarse en casa, de trabajar en remoto, la necesidad de hacer una reunión pero sin poder desplazarnos a unas instalaciones, las que hace que esta tecnología se convierta de «algo experimental» a «algo obligatorio», y han sido las empresas que apostaron por ellas desde un principio las grandes beneficiadas:
Microsoft (con su Microsoft Teams), Zoom, 8×8 (con su Jitsi Meet), Google (con su Hangout, y ahora Meet) y otros servicios más personales como Whatsapp, Apple (con su FaceTime) o Amazon (con su Alexa) las que realmente han visto como sus cuentas de resultados han aumentado gracias a estos servicios, su popularidad se ha disparado y hoy día no hay empresa que no cuente con un servicio de videoconferencia propio para reuniones con proveedores o clientes.
WebRTC puede no ser la panacea, pero ha conseguido ser el sistema más popular de comunicaciones gracias a la necesidad de una comunicación rápida, eficaz, seguro, adaptable al ancho de banda de los usuarios, compatible con cualquier dispositivo (escritorio, tablet, móvil, etc.)
No obstante, a medida que la pandemia parece normalizarse y empiezan a llegar las vacunas, muchas empresas parecen haber vuelto a su antigua forma de trabajar.
Google Trends con los resultados del término WebRTC en todo el mundo.
En esta gráfica de Google Trends sobre las búsquedas acerca del término «webrtc» se puede ver cómo a mediados de abril de 2020 (cuando la pandemia empezó a extenderse por todo el mundo) las búsquedas sobre esta forma de comunicarse se dispararon y durante varios meses mantuvo bastante el interés, pero con el tiempo vuelve a los niveles de los últimos años.
¿está todo dicho en cuanto esta forma de comunicarse? ¿ha sido el teletrabajo una moda pasajera y útil únicamente cuando los gobiernos obligaban al confinamiento? ¿se mantendrán las videoconferencias como un sustituto de las reuniones presenciales? ¿volveremos a las oficinas pese a que el teletrabajo ha demostrado su utilidad?
Son muchas las preguntas que nos hacemos, cada uno tiene sus respuestas y me gustaría conocer vuestra opinión, por lo que os animo a que las escribáis en los comentarios, o en nuestro canal de telegram.
La gran deslocalización de trabajadores remotos que se nos viene encima
Internet propicia sociedades en las que no es necesario vivir en el mismo lugar en que trabajas. Una gran oportunidad para Españahttps://t.co/hRMthYXtDR
En mi opinión, y por los casos que conozco, creo que el teletrabajo y las comunicaciones vía mensajería, videoconferencia y/o VoIP han venido para quedarse en un gran número de empresas. Muchas se han visto obligadas a teletrabajar y han visto como su productividad no se ha visto mermada pero, en cambio, han aumentado sus beneficios personales. Por otro lado, que las empresas abran las puertas a trabajadores remotos les permite contratar a personas de otras provincias, comunidades y países que, de otra forma no podrían, y conseguirán talento que no podrían conseguir si únicamente contratan a personas que residan cerca de sus oficinas.
Por lo tanto, y desde este punto de vista, habrían dos tipos de empresas: – Las que se adapten y consigan una metodología de trabajo que permita sacar el máximo provecho a sus trabajadores sin importar dónde trabajen, y de esta manera podrán contratar a personas de cualquier lugar. – Las que no se adapten y vuelvan a la forma presencial de trabajar. Sólo podrán contratar a aquellas personas que vivan cerca de sus oficinas o acepten trasladarse a las grandes ciudades, con lo que sus posibilidades de personal nuevo y que les traiga ideas y conocimiento fresco estarán limitadas a su posición geográfica y a la oferta disponible.
Por supuesto, no todas las empresas pueden teletrabajar, pero las que sí pueden, gracias a la VoIP, las nuevas tecnologías y a las herramientas compartidas y distribuidas en la nube, tienen todo lo necesario para aprovechar esta oportunidad y dar con una forma de trabajar atractiva que atraiga al talento tanto si están en la gran ciudad, como si están en la España vaciada.
Las pymes ganan en competitividad gracias al teletrabajo, implica nuevas oportunidades de negocio y un ahorro de costes gracias a la deslocalización y a la revolucionaria transformación digitalhttps://t.co/EXhmDqpn2U
Esto lo extraigo de varias conversaciones con algunos amigos que me comentaban algunos ejemplos de sus nuevas empresas:
Un amigo empezó en su empresa (internacional) a los pocos días de comenzar la pandemia, así que fue a la oficina su primer día, le dieron su portátil y a casa a trabajar: Formación a distancia, reuniones por videoconferencia y reunión presencial de equipo una vez al mes en la oficina. En este caso, la oficina ha quedado como un lugar donde poder reunirse presencialmente para tratar aquellos temas de una forma más dinámica e interactiva.
Una prometedora startup (nacional), tienen una política de trabajo en remoto parcial, en la que 3 días trabajan en casa y 2 días trabajan en la oficina para acercar posturas y ponerse al día con lo que han hecho durante la semana. La oficina cuenta con espacio suficiente por si alguien prefiere trabajar allí cualquier día, pero hay libertad para ir los días que necesite o cuando concreten alguna reunión de equipo.
Otra gran empresa (nacional) en la que todos trabajan remotamente, sólo una reunión de equipo al mes presencialmente a otra provincia, por lo que una vez al mes debe viajar y ver a sus compañeros.
Por último, otra empresa conocida (nacional) ha dividido al personal de la empresa en dos grupos equivalentes que se turnan para trabajar en la oficina. De esta manera mezclan esa mecánica de trabajo remoto y la del trabajo en la oficina haciendo poco a poco que el trabajar en remoto sea algo habitual y aprovechan lo bueno de ambos entornos.
Estos sólo son algunos ejemplos de empresas (grandes, medianas y pequeñas) que han optado por el teletrabajo de una manera u otra y están contratando personal, lo que entiendo que les va bien y están creciendo pese a esta época convulsa. ¿y tú? ¿conoces algún caso interesante de teletrabajo?
El desarrollo de aplicaciones de voz es un concepto muy amplio que engloba desde desarrollos básicos de centralitas, programación de IVR, programación de entornos de red orientados a protocolos VoIP, gestión de paquetes, desarrollo de códecs, criptografía, programación de chatbots, y un largo etcétera que no tendría fin.
A pesar de esto, y centrándonos en este artículo en un desarrollo básico, vamos a hablar sobre los tres modos de desarrollar soluciones más comunes, utilizando herramientas conocidas por todos: Asterisk, Kamailio y WebRTC.
En próximos artículos hablaremos sobre otras técnicas y herramientas no tan conocidas pero que nos ofrecerán soluciones diferentes a las que se pueden llevar a cabo utilizando una de estas herramientas.
Asterisk
Asterisk nació como un software de centralita, pensada desde un principio como una herramienta software para actuar como PBX: (central de teléfonos) y con opciones incluidas en su código tan básicas como la música en espera (music-on-hold), buzón de voz (voicemail), transferencia de llamadas, grabación de llamadas, colas y agentes, reproducción de locuciones, IVR, etc. No obstante, cualquiera que desee una centralita al uso e instale un Asterisk por primera vez seguramente se encuentre con grandes frustraciones:
Nada más instalarlo, requiere de una gran cantidad de configuración para llegar a tener un sistema telefónico que cumpla mínimamente con lo que se requiere en una PBX estándar.
Requiere de unos conocimientos básicos nada básicos para alguien profano en la materia que desconoce cómo funcionan protocolos, códecs, dialplan, etc. para llegar a configurarlo de una forma mínimamente decente.
No incluye una herramienta que facilite la configuración a la vez que el mantemiento, teniendo que optar por soluciones externas como FreePBX, Issabel o soluciones comerciales.
Dicho lo cual, Asterisk dejó de ser un «software de PBX» para convertirse en una herramienta para la creación de aplicaciones de Voz (entre lo que se incluye, lógicamente, la creación de sistemas PBX). Gracias a esto, Asterisk hoy día es más conocido entre desarrolladores que necesitan crear su propia solución a medida, que entre empresas que necesitan una PBX tal cual. Y es por esta razón por la que Asterisk se podría considerar una de las mejores herramienta para desarrollar soluciones VoIP a medida, ya que incluye muchos medios y canales con los que poder desarrollar prácticamente cualquier solución que necesitemos.
Hemos hablado hasta la saciedad de los «interfaces» con los que cuenta Asterisk:
CLI (Command Line Interface), que es la forma más básica de acceder a Asterisk desde el terminal de consola y nos permite ejecutar comandos simplemente tecleando lo que queremos.
AGI (Asterisk Gateway Interface), un pseudo-lenguaje que nos permite externalizar acciones ejecutadas desde el propio Asterisk. De esta manera Asterisk «ejecuta» una aplicación externa a él mismo, permitiéndole acceder a recursos que, de otra manera, no sería posible al no tener soporte el propio Asterisk.
AMI (Asterisk Manager Interface), un puerto TCP al que nos podemos conectar para enviar comandos y recibir eventos de todo lo que sucede en el Asterisk, gracias a un protocolo muy sencillo para cualquiera que sepa mínimamente programar.
ARI (Asterisk REST Interface), un interfaz REST que permite tanto a Asterisk como a una aplicación, interactuar con canales, llamadas, usuarios, bridges, etc. de forma asíncrona y utilizando una conexión WebSocket para la comunicación de órdenes y datos mediante JSON.
Estos son los interfaces con los que cuenta Asterisk para desarrollar cualquier solución que se necesiten. Cada una de ellas realmente tiene ejemplos muy sencillos, pero también verdaderamente avanzados, ya que cualquiera de ellas permite una gran cantidad de posibilidades y flexibilidad para ayudarnos a crear cualquier cosa. Pese a todo el potencial que tienen estos interfaces, existen limitaciones en todos y cada uno de ellos. Hay necesidades que los AGI no pueden satisfacer y hay que acudir al AMI. Hay soluciones que el AMI es difícil y es mejor recurrir a ARI y hay necesidades que podemos ahorrar mucho tiempo y esfuerzo si utilizamos simplemente el CLI.
Kamailio
No obstante, existen necesidades y proyectos en los que Asterisk no es la herramienta ideal, Asterisk siempre puede ayudar, pero llega un momento que hay que mirar más allá y ver qué otras soluciones se pueden utilizar.
Por poner un ejemplo rápido y fácil de entender, podemos echarle un vistazo al proyecto HOMER.
HOMER es una herramienta muy conocida por todos, y cuya función se basa en recopilar, clasificar y gestionar el tráfico SIP, permitiéndonos llevar un control perfecto de todo lo que sucede en uno o varios servidores. ¿Cómo hace esto? Necesita de una herramienta que pueda capturar el tráfico SIP y enviarlo a un sistema que pueda clasificarlo y ejecutar código por cada paquete que le llegue. ¿Qué herramienta hace esto? ¿Asterisk? Podría… pero en este caso, un Asterisk manejando un gran volumen de llamadas SIP podría necesitar de grandes recursos, así que la solución que optaron para la versión HOMER 5 fue: Kamailio.
Kamailio es un servidor SIP PROXY / SIP REGISTRAR / etc. que se encarga de recibir paquetes SIP y procesarlos uno a uno. Al ser una herramienta orientada a esto, es muy, pero que muy eficiente, ya que no ha de manejar el audio RTP, ni hacer grabaciones, ni escuchar tonos DTMF, ni manejar transferencia, ni nada de nada, simplemente se centra en procesar cada paquete SIP que le llega. Por esta razón, un Kamailio es una herramienta supereficiente de procesamiento de paquetes SIP y la herramienta seleccionada por HOMER 5 para esta tarea.
La idea es fantástica si en nuestro desarrollo necesitamos procesar paquetes SIP (analizar los campos From, To, Contact, PAI, etc.) ya que podremos utilizar el archivo de configuración para programar qué queremos hacer ante cualquier paquete SIP que nos llegue.
WebRTC
No obstante, nos estamos centrando en desarrollo de aplicaciones de Voz basados en SIP pero ¿y si nuestro proyecto está por encima de este requisito? ¿Y si queremos desarrollar un proyecto pero no tenemos por qué hacerlo con extensiones SIP? En ese caso, otra de las soluciones que habría que estudiar es una librería muy famosa llamada WebRTC.
Aunque de WebRTC hemos hablado largo y tendido, hay que conocer bien lo que es para entender bien su alcance. Normalmente WebRTC está asociado a varios términos: Navegador Web moderno y/o softphone web.
WebRTC es mucho más que esto… aunque suene a descripción de la wikipedia, WebRTC es una librería de herramientas que nos permitirá desarrollar todo tipo de aplicaciones en las que intervenga cualquier tipo de «media» en tiempo real (eso puede ser audio, vídeo o también texto, archivos, captura de pantalla, etc.) utilizando para ello un navegador web.
No obstante, WebRTC nos permite crear aplicaciones en las que intervengan voz, audio o cualquier otro tipo de dato en tiempo real conectándonos a un servidor mediante WebSockets, lo que nos permite interactuar con cualquier aplicación remota que pueda conectarse vía WebSocket, eso elimina la necesidad de utilizarla «entre» navegadores web y nos abre las posibilidades con prácticamente cualquier otro dispositivo, desde herramientas de IoT, robots, domótica, seguridad, y un largo etcétera.
Por lo tanto, y aunque soy consciente que la curva de aprendizaje de WebRTC no es fácil, que requiere de muchos conocimientos previos bastante avanzados de Javascript, pero las posibilidades son realmente ilimitadas y son justamente éstas las que nos abrirán las puertas (y las están abriendo ahora mismo) con los nuevos proyectos que están surgiendo hoy día y que facilitarán la vida en los próximos años.
¿Conoces otras herramientas que pueden ser prácticas para desarollar aplicaciones, soluciones y proyectos VoIP? Anímate y escríbelas en los comentarios.
En 2011, una empresa llamada Global IP Solutions (GIPS) fue adquirida por Google tras comenzar un desarrollo de una API conocida como WebRTC que tenía el objetivo de acercar la voz y el vídeo en tiempo real a la web.
Más de 10 años después, el sistema que permite conectar micrófono y webcam al navegador y poder enviar y recibir streams de audio y vídeo se ha convertido por fín en un estándar declarado por la IETF. (la organización que recoge los protocolos y estándares de Internet)
Todo este tiempo para que organismos, empresas, desarrolladores y miles de usuarios puedan definir una forma común para enviarse audio y vídeo en tiempo real entre ellos, utilizando para esto una herramienta común: el navegador web.
Hoy día un navegador es prácticamente un sistema operativo capaz de correr aplicaciones y conectar el hardware con estas para que el usuario pueda trabajar y hacer aquello que necesite, de ahí la importancia de esta tecnología que hoy por fin, se puede considerar un estándar.
Son muchos los expertos y profesionales que han trabajado para llegar hasta donde se ha llegado hoy, un momento «cero» en el que empezar a trabajar con algo estable, una librería básica y unas normas que todas las herramientas deben cumplir para ser consideradas «de acuerdo a la norma». (La web también es un estándar y hay quién le da igual y saca sus propias extensiones, librerías y modificaciones sólo para su navegador, pero no es lo normal y debería recibir el rechazo común de cualquiera con dos dedos de frente).
Soy consciente que para muchos lectores, WebRTC no es más que otra forma de crear un softphone personalizado vía web, pero para los usuarios es un sistema que le permite comunicarse desde cualquier sitio.
Atrás quedó aquella necesidad de instalar una aplicación softphone, o instalar un plugin hecho en flash que se conecta a un módulo SIP-RTMP, o con un applet hecho en Java que conecta con el Asterisk vía protocolo IAX. (¿alguien recuerda esas maravillas del pleistoceno?)
Hoy día WebRTC nos permite mucho más que tener un softphone en el navegador, nos permite dotar de voz y vídeo a nuestras propias plataformas, nuestras herramientas, nuestras aplicaciones cotidianas para dotarles de una comunicación en tiempo real y aumentar la productividad y problemas por falta de comunicación.
También WebRTC nos dota de una grandísima herramienta con la que crear nuevas aplicaciones novedosas e ingeniosas con la que solucionar nuevos problemas de una forma mucho más sencilla.
Es cierto que WebRTC no es algo «básico y trivial» que cualquiera pueda crear y desarrollar como si nada, ya que se requiere de unos conocimientos técnicos avanzados, pero también es cierto que sin un estándar definido, todo lo que hace falta para desarrollar cualquier herramienta puede cambiar en la siguiente versión del navegador, por lo que era necesario un momento como este para poder empezar a aprender y desarrollar un software de cara a ser mantenido en el tiempo sin más complicaciones siempre que nos basemos en el estándar.
Como cualquier campo técnico que se asienta y madura, aparecen siempre personas, profesionales y empresas que tienden a avanzar en el desarrollo de cualquier mínima categoría, especialidad y variación de dicho campo con el objetivo de crecer, conseguir nuevos clientes o ampliar beneficios.
Esto ha ocurrido siempre, y ocurrió en el mundo de las bases de datos, cuando toda la información se almacenaba en archivos de textos, luego se pasó a almacenar en archivos binarios para poder disponer de un método de búsqueda más rápido y eficaz (¿alguien se acuerda de DBASE III Plus y similares?) luego aparecieron «motores» que ayudaban a organizar y realizar búsquedas en esos ficheros y cuando todo parecía que estaba inventado con la aparición del Access, MSSQL, MySQL, PosgreSQL y Oracle… apareció una nueva ramificación con los NOSQL que dió lugar a una nueva forma de entender las bases de datos (Mongo, Redis, Cassandra…). Estos motores no sustituyen a los primeros, si no que forman una especialización del motor para cierto tipo de información (más voluminosa, menos relacionada, ideal para grandes cantidades de datos y búsquedas muy rápidas y simples…) y si uno pensaba que ahí acababa la cosa, aparecen los motores de bases de datos orientados a «series de tiempo» (TimeSeries), ideal para guardar grandes volúmenes de información prestando especial interés a cuándo se insertó esa información. Esto es ideal y específicamente creado para IOT, telemetría de todo tipo (desde servidores hasta coches) y un largo etcétera… y como siempre, todo tiende a expandirse y especializarse hasta el infinito.
Lo mismo que le ha ocurrido a las bases de datos, ocurre hoy día en cualquier campo técnico: programación, robótica, comunicaciones, criptografía, cyberseguridad, etc. Cualquier entendido de hace 10 años en cualquier tema técnico, que no haya evolucionado con los continuos avances, hoy día no sabría ni por dónde empezar con la cantidad de modificaciones y ramificaciones que ha dado su especialidad.
En la VoIP por supuesto, también ocurre… desde los inicios en los que nos bastábamos para crear un sistema central basado en Asterisk y un conjunto de teléfonos con 4 o 5 servicios estándar (tranferencias, desvíos, BLF, etc.) hoy día todo se especializa en cualquier ámbito donde la VoIP tenga una importancia crítica e importante: Kamailio u OpenSIPs en proveedores de servicios, Asterisk o FreeSwitch para centralitas básicas a las que se le acopla generalmente un interfaz de gestión para dotarla de características para callcenters, centralitas virtuales, o simplemente para instalar en una empresa y que la telefonía funcione perfectamente con sus teléfonos IP de toda la vida.
Los teléfonos han evolucionado muchísimo, desde los antiguos Kimpo, Sipura, BT100 o Swissvoice, pasando por los Thomson ST2030, Linksys o Polycom hasta los últimos modelos con pantalla táctil, a color con todo tipo de leds, sensores, indicadores y funciones como los últimos modelos de Snom, Grandstream, Audiocodes o Yealink. Teléfonos para todos los gustos pero imposible comparar los antiguos modelos con los nuevos, no únicamente en prestaciones si no en apariencia.
Y aún así, esta metodología de funcionamiento, que podría considerarse tradicional o estándar y que seguramente sea la más frecuente de encontrar en las empresas por su relación calidad-precio-estabilidad, choca con una nueva ramificación de la VoIP que lleva gestionándose más de 10 años y que, al igual que ocurría con el mundo de las bases de datos, crea un nicho muy específico, aunque bastante amplio, que consiste en atraer la VoIP directamente de la aplicación/web/… y es WebRTC.
WebRTC no sustituye inicialmente a una centralita y sus teléfonos, su función es mucho más a bajo nivel y todo depende de la aplicación que gestiona las llamadas y las conversaciones, depende de la empresa que lleva la aplicación, y de que la aplicación esté actualizada. Una empresa que opte por un sistema WebRTC no necesitaría teléfonos IP, ni posiblemente un Asterisk que gestione esas llamadas, ya que la mayoría de las aplicaciones WebRTC están orientadas principalmente a interactuar entre usuarios de la misma plataforma. Como ejemplo tenemos a Whatsapp, Telegram, etc. que como bien se puede comprobar, no se puede hacer una llamada a un número fijo o un número internacional, ya que únicamente admite llamadas entre usuarios de la plataforma. El día que la plataforma deje de funcionar, la aplicación no tendrá opción para que podamos utilizar otra plataforma diferente a la oficial.
Esto no siempre es así, hay empresas que buscan integrar un sistema híbrido: mitad SIP, mitad WebRTC o lo que viene siendo utilizar un softphone WebRTC para conectar con la centralita Asterisk de toda la vida como si fuera un softphone más. Realmente esta idea es muy interesante para muchas empresas, aunque no es el objetivo de WebRTC por lo que tampoco hay mucho interés en ofrecer esta solución.
El objetivo de WebRTC es traer la posibilidad de comunicarse directamente a la aplicación y que el usuario que está trabajando en dicha aplicación, pueda hablar con otras personas (compañeros, clientes que se conectan a la web, etc.)
Así trabajan otras empresas como Microsoft Teams (antes Skype$Bussiness, antes Lync, antes OCS, antes …) favoreciendo y acercando la comunicación interna a través de una comunicación WebRTC y (si contratas el módulo PBX) poder conectar una PBX compatible para poder hacer y recibir llamadas empresariales puntuales.
Personalmente no me imagino a un callcenter trabajando con Microsoft Teams, tanto por el coste mensual, como por las limitaciones funcionales de la PBX y como por el coste de actualización cada pocos años de todo el sistema de comunicaciones, de la misma manera que tampoco me imagino un sistema de multivideoconferencia gobernado por un Asterisk en la que cada participante tenga que configurar su aplicación de videosoftphone para poder conectarse e interactuar.
Después de muchos años, WebRTC no es una evolución de la VoIP, si no una ramificación que aporta unas soluciones muy concretas a unos problemas que la VoIP tradicional: la de la PBX -register-proxy-usrloc-etc.- y los teléfonos IP no puede dar. Hay quien trabaja para crear una integración SIP-WebRTC, de la misma manera que hay motores de bases de datos NoSQL que admiten sentencias SQL y unas pseudo-relaciones bastante curiosas, pero desde mi punto de vista, el mundo «SIP» y el mundo «WebRTC» son dos ramas del mismo árbol que sirven a propósitos distintos y no del todo incompatibles.
Hay que tener en cuenta que Asterisk 17 soporta SIP bajo WebSocket, lo que permitiría conectar clientes WebRTC (siempre que sepas, puedas y tengas tiempo para programar un cliente WebRTC).
Por supuesto, aún no ha salido un sistema que integre ambos conceptos de forma nativa y es que los requisitos de WebRTC (FQDN, HTTPS, navegadores últimas versiones, etc.) hacen difícil una integración LTS (sin apenas necesitar de un mantenimiento mensual) por lo que quien opta por un sistema WebRTC debe estar dispuesto a pagar un mantenimiento continuado de programación para que el sistema siga funcionando pese a las variaciones de los navegadores, algo que muchas empresas no están dispuestas a hacer.
En resumen: La VoIP sigue expandiéndose, lentamente (eso si) hacia otras formas de comunicarse utilizando la web, y aunque veamos que el WebRTC es lo más de lo más, no hay que olvidarse que la VoIP basada en SIP, con sus teléfonos IP, sus centralitas software y hardware, sus paneles de gestión y monitorización, sigue existiendo, sigue avanzando y sigue siendo hoy día la opción más utilizada por las empresas. Quizá eso varíe en un futuro a medio o largo plazo, pero no será pronto.
Si bien ya sabéis que nos encantan los eventos sobre VoIP, hoy vamos a hablaros de uno cuya primera edición comienza hoy, aunque llevamos tiempo siguiendo su preparación y estamos seguros que va a tener una gran acogida, se trata de la JanusCon.
Como su nombre bien indica, es un evento orientado principalmente a usuarios y desarrolladores de Janus (la plataforma WebRTC creada por Lorenzo Miniero y el principal organizador de este evento) aunque también tiene espacio para todo tipo de desarrollos WebRTC y, de forma más genérica, aplicaciones y sistemas VoIP como Asterisk, OpenSIPS y Kamailio.
En esta ocasión, la JanusCon se celebrará los días 23, 24 y 25 de septiembre en un maravilloso entorno: Nápoles, zona conocida, no únicamente por sus Pizzas, si no por muchas muchas más cosas, lo que convierte a JanusCon en una gran oportunidad para aprovechar y hacer turismo por el sur de Italia.
Aprovechando el evento Astricon, se ha publicado la versión 16.0.0 de Asterisk entre un gran número de seguidores, usuarios y desarrolladores, una versión que llevamos esperando desde hace mucho tiempo ya que, tanto la versión Asterisk 14 como Asterisk 15 fueron ambas, versiones orientadas a desarrollo en la que se han incorporado bastantes buenas características, se han estabilizado algunas que ya existían y los usuarios de Asterisk llevamos esperando una versión LTS más de 3 años.
En la Astricon de 2014 se anunció la última versión LTS: Asterisk 13 y desde entonces ha llovido mucho. En aquel momento se publicaba PJSIP de forma oficial en una versión LTS (en un Asterisk orientado a producción) y los primeros trazos de un nuevo interfaz llamado ARI (Asterisk Rest Interface) pero que aún estaba un poco en pañales. Por esta razón, esperábamos que la siguiente versión LTS incorporase estas novedades mucho más estabilizados y orientados a entornos en producción, por esta razón, cuando nos enteramos que Asterisk 15 no sería una versión LTS, muchos nos quedamos con la miel en los labios sabiendo que nos tocaría esperar al menos otro año para poder aprender y disfrutar de las bondades que llevamos leyendo y escuchando tanto tiempo.
Nos levantábamos hace unos días con la noticia de la publicación de la Release Candidate de Asterisk 15 (la nueva versión de Asterisk) y que llevábamos tiempo esperando por lo que ello significa.
Hace poco veíamos como el equipo de desarrollo de Asterisk anunciaba que Asterisk 15 es, posiblemente, la versión más grande de Asterisk de los últimos 10 años. Este comentario parecer un poco exagerado, pero si analizamos los cambios internos que se han producido en las últimas versiones, empezamos a ver la realidad de dicha afirmación. Lo importante de esta versión son los cambios a nivel interno, una apuesta de futuro que sirve para que Asterisk siga creciendo con energía y vitalidad, al contrario que muchos software que nacen y se basan en parches sobre parches, lo que termina ocasionando un «spaguetti code» que pocos desarrolladores son capaces de manejar.
El objetivo es que Asterisk 15 esté disponible en octubre de 2017 y que tenga actualizaciones durante al menos, dos años. *Corrección*: Tal y como nos apunta @jbmanwe, Asterisk 15, aunque por el número debería ser una LTS, es una versión de desarrollo como Asterisk 14 (no LTS)
¿Qué trae de nuevo Asterisk 15?
Como suele ocurrir, uno de los principales intereses cuando aparece una nueva versión es ver, qué trae de nuevo:
Mejor soporte de WebRTC: Si bien Asterisk 14 ya presumía de soportar WebRTC, no va a ser hasta Asterisk 15 cuando el soporte de WebRTC sea completo. Un simple parámetro como «webrtc=yes» en la configuración ajustará todos los parámetros necesarios (NAT, SRTP, Opus, etc.) para poder utilizar WebRTC con Asterisk.
Introducción al concepto de Stream para la gestión de flujos de RTP. Lo que permite una mejor gestión del media ahora que también incluye soporte de WebRTC. También mejora el tema de videoconferencias, multiconferencias, etc. para ser más descriptivo y poder gestionarlo mejor.
Mejora en el soporte de PJSIP: Si bien Asterisk 12 y 13 ya incluía soporte de PJSIP, no será hasta Asterisk 15 cuando realmente el soporte sea completo. Las ventajas de PJSIP en Asterisk las hemos comentado hasta la saciedad, pero si bien el equipo de desarrollo de Asterisk había «bloqueado» una versión de PJProject (el proyecto detrás de PJSIP) para compilar con Asterisk y evitar problemas, en Asterisk 15 esta versión estará incluida por defecto y únicamente si queremos utilizar la última versión de PJSIP, tendremos que compilar con un flag especial.
Cambios en el esqueleto de Asterisk: Como hemos dicho muchas veces en Sinologic, Asterisk ha pasado a ser un software muy maduro creado por muchos tipos de desarrolladores que trabajan en muchas empresas, por lo que se ha tenido que trabajar muy duro en conseguir un código fácil de entender, reutilizable, y evolucionable. Por esta razón, desde Asterisk 11 se ha estado modificando el núcleo para convertir el código en objetos, lo que permite una gestión de memoria mucho más intuitiva y práctica, a la vez que se crea una capa de abstracción que permite a otros desarrolladores despreocuparse de ciertos conceptos fuertemente relacionados con el código.
Mejoras en características generales: Quizá lo más interesante para todos serían las novedades en las características generales, pero para eso habrá que examinar la versión más detenidamente. Lo único que de momento sabemos es que se han modificado muchas partes del código para mejorar su potencia, reducir el consumo y aumentar la compatibilidad con sistemas como Docker, contenedores y plataformas como systemd… No obstante, también se ha incluido muchas mejoras en aplicaciones, funciones y características incluidas en Asterisk y que seguro que todos los usuarios de Asterisk agradeceremos pero que tendremos que ver con tranquilidad.
Asterisk ya no es para todo el mundo.
Tristemente, y a medida que la VoIP se hace más y más común entre los mortales, las herramientas pasan a otro nivel. Si bien los que comenzamos hace algún tiempo seguimos con paciencia e ilusión las nuevas versiones de un software como Asterisk o Kamailio, la mayor parte de los usuarios apenas conocen este software y únicamente se centran en «el software que lo haga todo» ya sea 3CX, Issabel o FreePBX. Esto no es ningún caso malo, es simplemente la evolución natural de meter a más y más empresas en un mundo que desconocen y que, puestos a aprender, prefieren algo que les haga ganar dinero.
Asterisk (y también otras aplicaciones como freeSwitch, Kamailio, OpenSIPs, etc.) ha quedado relegado como software motor para aquellos profesionales que quieren profundizar en las posibilidades que les otorga para poder ofrecer cosas fuera del ámbito «comercial» y cotidiano y, como hemos dicho tantas veces, tratar a estas herramientas como herramientas que forman parte de un todo y no como sistemas «todo en uno».
Todo cambia, evoluciona y si bien la VoIP ha madurado y evolucionado, también los usuarios lo han hecho. El mercado se hace más grande y hay más personas que se han metido en el mundo de la VoIP, pese a que no sepan cómo funciona el protocolo SIP, qué es WebRTC o porqué interesa usar el códec Opus en lugar de Alaw. Hay espacio para todos y la VoIP es una rama propiamente dicha que sigue creciendo y generando sus propias ramas donde hacer crecer las hojas.
