¿Qué es WebRTC?

¿Qué es WebRTC?

WebRTC significa comunicación multimedia en tiempo real para la Web. Se pueden diferenciar dos puntos de vista a la hora de entender WebRTC: el mundo VoIP y el mundo Web. Hay quienes interpretan WebRTC como una forma de añadir la Web en el mundo VoIP, y otros que lo interpretan como una forma de enriquecer la Web con comunicaciones multimedia. Yo soy más partidario de esta última visión, e intento evitar concebir WebRTC como un mero interfaz nuevo al mundo VoIP.

¿Cómo te involucraste en WebRTC?

Hace años me interesé por el nuevo protocolo WebSocket (ahora RFC 6455) y participé en el grupo del IETF que lo definía.

WebSocket es un protocolo para la Web que permite transporte de datos bidireccional en tiempo real entre cliente (navegador web) y servidor, algo para lo que no había una solución estándar en el mundo Web al margen de Flash, HTTP long polling (que no es eficiente), Comet y poco más.

Con la llegada de WebSocket vi la posibilidad de hacer funcionar el protocolo SIP en aplicaciones Web, de ahí surgió la especificación draft-ietf-sipcore-sip-websocket (en pleno desarrollo actualmente en el grupo SIPCORE del IETF) así como implementaciones de lado cliente (JsSIP de mi amigo José Luis Millán) y de lado servidor (como OverSIP). Una vez planteada y resuelta la parte de señalización SIP se hacía necesario introducir también capacidad multimedia, y WebRTC (que estaba naciendo en ese momento) era justo lo que necesitábamos, así que nos involucramos.

El año pasado ustedes hicieron un lanzamiento, háblanos un poco más al respecto y qué ha pasado desde esa fecha hasta el día de hoy

Efectivamente, en ElastixWorld y Voip2day de 2012 en Madrid (que se hicieron conjuntamente), anunciamos durante nuestra presentación la publicación oficial de JsSIP (hasta entonces existía pero no era público). JsSIP es una librería JavaScript que implementa SIP sobre WebSocket y que hace uso de WebRTC.

Tras su liberación con licencia MIT ha tenido muchísima difusión, quizás más de la que esperábamos. Mucha gente se ha interesado por JsSIP y ha contribuido con parches y mejoras. Nos consta que es utilizado por muchas empresas que están ofreciendo o diseñando actualmente productos basados en WebRTC. Es más, hay incluso hay alguna empresa que ha intentado ofrecer un producto basado en JsSIP de forma fraudulenta, tratando de esconder la autoría del código.

Nuestro objetivo siempre ha sido convertir a JsSIP en la implementación de “SIP en el navegador” por referencia y, según nos consta, cuando alguien prueba JsSIP deja de lado el resto de alternativas.

Desde hace poco mas de un año la gente esta hablando mucho de WebRTC y hay bastantes ejemplos, pero en tu criterio ¿Cuál crees que es el estado actual de WebRTC como tecnología? ¿Crees que falta mucho para que madure?

WebRTC lleva en desarrollo más de dos años y medio, y a día de hoy está casi completado. No obstante, en mi honesta opinión (y hablo a título personal) WebRTC ha sufrido una larga demora debido a que desde el primer día, y debido a la influencia de telcos, se forzó el uso de SDP (existente en SIP y otros protocolos RTC). Se han tenido que escribir numerosos drafts para adaptar SDP a las nuevas exigencias del mundo Web y este proceso ha llevado su tiempo (al margen de que muchos pensamos que WebRTC no debería de ninguna forma forzar el uso de SDP).

Pese a que a muchos no nos gusta del todo cómo esta quedando, WebRTC ya está bastante definido a nivel de especificación. A nivel de implementación Chrome lleva la batuta, pese a que en cada nueva versión introducen bugs, arreglan 4 cosas y rompen 3. La interoperabilidad entre distintas versiones de Chrome es difícil, y si metemos a Firefox más aún, y de momento no hay más navegadores que implementen WebRTC.

Aún así, estimo que en un plazo de 4 a 6 meses las implementaciones madurarán muchísimo en base a especificaciones que cada vez son más sólidas y menos cambiantes.

Hay algunas soluciones, que integran a clientes finales, que están disponibles en Internet pero desde el punto de vista del usuario final no es algo tan entendible. ¿Es necesario que exista detrás una infraestructura o plataforma?

Adelantándome un poco a la charla que daré en ElastixWorld, hay dos visiones: la visión del mundo VoIP (la que conocemos la gente de este mundillo), y la visión del mundo Web (esa gente que hacen websites con millones de usuarios y que cotizan en bolsa más que una petrolera). En este último caso ¿es necesario tener una plataforma para utilizar WebRTC? pues no, no es cierto.

WebRTC no exige que haya un protocolo de señalización. No hace falta usar SIP ni XMPP ni nada conocido. Existen miles de ejemplos de chat en la web y usan protocolos custom sobre HTTP. Ese mismo canal de comunicación se puede reusar para transmitir la información necesaria de cara a establecer una comunicación WebRTC, y básicamente consiste en el envío de sendos SDP entre dos navegadores Web.

Una vez se ha negociado la sesión multimedia, empieza el proceso de STUN / ICE para encontrar el path de media directo entre los navegadores, y a continuación comienza la transmisión de audio y vídeo por RTP.

Entonces ¿hace falta una plataforma?

Depende… si queremos WebRTC para integrar soluciones de telefonía en la web obviamente hace falta una plataforma de telefonía. En este caso Asterisk (que está desarrollando soporte para WebRTC) puede ser una opción. Sin embargo, esa es una visión limitada que sólo sirve para convertir el navegador Web en un teléfono, sin interacción real con la Web. Si estamos en el mundo Web debemos dar mucho más valor añadido, y no simplemente empotrar un webphone en un navegador y hacer que sus funcionalidades se limiten a lo que ofrece una PBX (¿vas a controlar una multi-conferencia enviando tonos DTMF teniendo una aplicación web?).

En ese sentido tu hablas de desarrolladores de Webs. ¿Deben ellos tener habilitado en su infraestructura WebRTC para que un usuario final a través de un navegador haga una llamada a alguien a través de una página?

Depende. Supongamos una página que ya ofrece a sus usuarios un chat en tiempo real. Si esa página quiere permitir audio/vídeo llamadas entre sus usuarios no necesita desplegar ningún Asterisk ni similar (como mucho puede necesitar poner un servidor TURN a disposición de sus usuarios para soslayar los problemas de NAT).

Imagina que yo en vez de mandarte un mensaje “hola Paul” te mando un SDP, y tu aplicación web está preparada para procesarlo con el API de WebRTC. Tú me respondes con otro SDP y a partir de ese momento en el cual tú tienes mi SDP y yo tengo el tuyo, nuestros navegadores empiezan a mandarse pruebas de conectividad ICE hasta lograr establecer una conexión. Y ya podemos enviar y recibir audio y vídeo. Obviamente la web debe ser modificada para incluir botones de colgar, pausar, etc, así como para representar el vídeo remoto y el nuestro propio. Teóricamente no hace falta tener un Asterisk, ni nada similar. Otra cosa es que queramos interactuar con una plataforma VoIP existente.

En términos de herramienta ¿Cuál crees que es la ventaja principal de WebRTC frente a una aplicación como por ejemplo Skype?

Skype es un producto, un servicio y un cliente de chat, presencia y por supuesto de audio y vídeo. Tiene sus servidores, tiene sus aplicaciones para móvil y tienen su propio protocolo de señalización. En este caso Skype es un servicio final, un producto, mientras que WebRTC constituye una tecnología sobre la que perfectamente se podría construir la base para una aplicación como Skype.

En términos de seguridad ¿crees que hay alguna ventaja en WebRTC ?

Un problema que siempre ha sufrido la VoIP es que a nivel real la seguridad ha importado poco. Siempre hemos escondido nuestras redes VoIP dentro de redes LAN privadas, usando el propio NAT como “seguridad”.

Por poner un ejemplo, instalaciones de Asterisk siempre han estado ligadas a redes locales en la cuales la seguridad esta apartada del mundo por un firewall o simplemente por un router NAT, mientras que en el mundo Web la seguridad no puede ser opcional ni depender de la red en la que estés en cada momento.

En WebRTC se han tomado muchas de las especificaciones que ya existían y que ofrecen una seguridad muy fuerte para VoIP y las han exigido a nivel de protocolo. Por poner un ejemplo: un navegador web NO puede iniciar una sesión de audio/vídeo si el RTP no está cifrado y si no se ha usado ICE para autenticar a la parte remota.

Recientemente salió una noticia acerca que Opus va a ser el nuevo codec por defecto en WebRTC, cuéntanos algo más sobre esto.

Opus es un codec de audio derivado de Silk. Silk es el codec que utiliza Skype (un codec adaptativo, con una calidad de audio impresionante, que se adapta en tiempo real al ancho de banda disponible).

La especificación de Silk fue liberada y publicada por Skype, y el IETF publicó posteriormente Opus. Opus es sin duda el mejor codec de audio posible para un entorno tan variopinto como es Internet.

Un mensaje que quieras dar a la gente que va a ir al evento

Voy a enfocar mi presentación en las dos visiones que hay de WebRTC. El mensaje que trataré de transmitir es el de que hay que abrir la mente hacia WebRTC, y nunca considerar al navegador Web como un simple teléfono tonto conectado a tu Asterisk cual softphone gratuito. Ya hay, y habrá muchos más, servicios y productos basados en WebRTC que nada tienen que ver con telefonía, ni con Asterisk, ni con centralitas. Aprendamos de ellos y abramos nuestra mente.