Han pasado 10 años desde que lanzamos nuestra primera solución UCC basada en WebRTC. Pero, ¿por qué elegimos esta solución innovadora? Vamos a profundizar un poco en WebRTC y cómo surgió.
Una breve historia de WebRTC: La antesala
Wildix había estado usando applets para crear conexiones directas sin servidor en navegadores desde su primer soft client en 2009. Esta forma de trabajar era un poco tosca y daba muchos problemas — la falta de soporte entre navegadores, pequeñas actualizaciones que provocaban fallos que parecían aleatorios y la baja fiabilidad de Java en los navegadores debido a sus problemas de seguridad (y eficiencia).
El principal problema era la falta de estandarización entre navegadores y la falta de soporte integrado para las tecnologías que permitían las videoconferencias entre usuarios.
Aun así, conseguimos hacerlo funcionar. Lo suficiente.
Sin embargo, las tecnologías clave ya existían. El streaming P2P sin servidores estaba disponible desde finales de los 90, creciendo mucho a principio de los 2000 con el auge del uso de torrents. Casi todo el mundo que por aquella época era adolescente o tenía unos 20 años conocía a “un amigo” que había visto películas y programas antes de que se emitieran de forma general.
Además, los vendedores de telecomunicaciones ya habían empezado a ver la amenaza que suponía el acceso temprano a los flujos de datos. Flash 2.0 ofrecía sonido en estéreo ya en 1997, y varias aplicaciones de mensajería instantánea como AOL, MSN Messenger e incluso Yahoo Messenger, ofrecían posibilidad de llamadas de voz y el envío de mensajes parecidos a los SMS.
A su vez, Mark Spencer desarrolló Asterisk, el primer IP-PBX en 1999, tras no poder pagar un PBX convencional para su empresa. Esta sería la base de muchos IP-PBX y acabaría inspirando el Blue Ecosystem de Wildix.
Skype se lanzó como beta en 2003, una de las primeras soluciones de video llamadas por IP. Todos estos avances ofrecían cierta información de lo que se esperaba del futuro en este campo, y Dimitri y Steve Osler fueron capaces de predecirlo. Especialmente porque la tesis de Dimitri fue sobre el desarrollo de Asterisk.
Así que el escenario estaba listo para WebRTC
El desarrollo de WebRTC
Global IP Solutions se creó en 1999, y se centró en la creación de software embebido para comunicaciones en tiempo real (voz y vídeo) para redes IP. Normalmente sus productos se entregaban como “motores” que contenían todo lo que el cliente necesitaba.
La empresa entendió que la mayor parte de la tecnología VoIP había sido desarrollada para redes de conmutación de circuitos — aquellas con un canal dedicado a través del cual los nodos de la red podían comunicarse. Estas redes eran muy estables y ofrecían condiciones óptimas para el VoIP.
Sin embargo, la mayoría de llamadas VoIP se hacían sobre redes públicas, donde se podían perder paquetes, generar retrasos y añadir ruido. Las llamadas dentro de una misma red funcionaban bien; una llamada a un cliente externo muchas veces era imposible.
Global IP Solutions fue comprada por Google por 68.2 millones de $ en 2010, cuando empezó a incorporar sus patentes e ideas en su propio estándar de código abierto: WebRTC. También trabajó con otras empresas para desarrollar más esta idea.
El lanzamiento inicial de WebRTC podría decirse que fue en enero de 2011 por Ericsson Labs (por aquel entonces una filial de Ericsson). Solo se publicó en su blog: no había mucho seguimiento. Para muchos, esta publicación pasó totalmente desapercibida.
En junio de ese mismo año, Google publicó el código fuente de WebRTC, y al año siguiente mandó las especificaciones de WebRTC a la World Wide Web Consortium y a la Internet Engineering Task Force para ayudar a estandarizar el protocolo. El resultado fue que Chrome y Firefox implementaron WebRTC en 2013.
Wildix se convirtió rápidamente en un protocolo muy versátil que a su vez era seguro de usar. Dejamos a un lado los applets NPAPI que habíamos desarrollado y buscamos una forma de incorporar los elementos críticos en un programa compatible con WebRTC.
O más bien, casi nos deshicimos de los applets NPAPI. La realidad es que, aunque Chrome y Firefox soportaban WebRTC, el triste navegador de Microsoft no lo hizo en su momento. Aunque nos hubiera sido suficiente si nos hubiéramos centrado en el mercado del usuario final, Internet Explorer — después llamado Edge — se seguía usando en muchas empresas.
En el verano de 2013, teníamos una solución de comunicaciones por WebRTC operativa para páginas web: WebRTC Kite. Esto nos permitía conectar nuestros PBXs a una página web para mejorar las comunicaciones en tiempo real. Aunque ya habíamos conseguido una solución similar ejecutando Collaboration en el navegador, esta tecnología simplificaba mucho el proceso. Pero dado los problemas que hemos comentado — la solución “estandarizada” no era todavía estándar — nos encontramos que teníamos que mantener mucho código y muchas actualizaciones para diferentes navegadores.
Pero los hard clients ya no eran necesarios.
Cuantos más navegadores incorporaban WebRTC, menos problemas teníamos. Microsoft acabaría incorporando una forma de WebRTC (casi) en su navegador en 2017, aunque sería algo diferente, como siempre.
A pesar de que WebRTC se estaba convirtiendo en un estándar rápidamente, había muchos problemas importantes en la mentalidad de los clientes con respecto a las soluciones UC&C. Muchos querían descargarse algún tipo de hard client, ¡incluso en 2023! Esto puede provocar problemas de seguridad, siendo uno de los más conocidos (en el momento de escribir esto) incidente de seguridad de 3CX.
De la misma forma, la mayoría de las soluciones llamadas WebRTC siguen mantenidas por los applets y plugins de principios de 2010, lo que provoca un tiempo de desarrollo mayor, menor estabilidad y menor seguridad. Después de todo, ¿por qué descargar algo cuando tienes todo lo disponible en tu navegador? Para nosotros no tiene sentido.
Otros usos de WebRTC
Los usos de WebRTC no solo se limitan a Comunicaciones en tiempo real. Como muestra nuestro Desarrollo de x-bees, puedes integrar una gran variedad de productos a una solución WebRTC y el hecho de que todo se encuentre en el navegador lo hace muy eficiente.
Tenemos, por ejemplo, la integración con Salesforce. Permite la apertura de la aplicación automática al realizar llamadas, detección de contactos en la base de datos de Salesforce y ventanas emergentes para llamadas entrantes.
Se necesita muy poco espacio adicional, y no hay necesidad de tener una integración compleja por tener que usar un hard client. Desde un punto de vista personal, esta sencilla integración ahorra muchísimo tiempo — no hay que copiar ni pegar números (o introducirlos manualmente). También te permite obtener registros rápidamente de la base de datos con solo meter un número, si es que existe.
A esto, añádele registros automáticos de llamadas, chats y mucho más, y acabas teniendo una solución muy orientada a las ventas que mantiene tus contactos a mano.
Pero WebRTC puede hacer incluso más. Una videoconferencia es, como ya hemos dicho, mandar información por una red. Así que ¿por qué no acceso remoto usando WebRTC? En lugar de tener que bajarte un tedioso programa, un canal de datos WebRTC podría usarse (con el permiso del cliente) para controlar un sistema de forma remota. Esto podría facilitar mucho para los MSPs y otros proveedores de TI comprobar el estado de un equipo — especialmente donde se requiere soporte técnico ad hoc.
Wildix ya puede hacer esto usando exclusivamente WebRTC.
Y hay más oportunidades en el proyecto.
El efecto de WebRTC
WebRTC ha conseguido estandarizar las bases de para permitir la comunicación en tiempo real entre navegadores. No importa realmente qué navegador sea — todos los navegadores importantes vienen con alguna forma de WebRTC.
Wildix puede usarse en casi cualquier sistema, sin necesidad de descargas o plugins adicionales. Como resultado es ligero, fácil de usar y rápido de desplegar.
Así que la pregunta es: ¿Por qué no usarías una solución WebRTC?
Para más consejos de marketing, ¡suscríbete para recibir nuestra revista gratis!