Check the new version here

Popular channels

WebRTC – Comunicaciones P2P en la web



Buscando como hacer streaming de video sobre HTML5 me topé con WebRTC, que como sus siglas lo indican es la forma de hacer Real-Time Communication sobre web.
Este estándar de comunicación esta soportado por Google Chome, Firefox, Opera e Internet Explorer. Utiliza HTML5, JavaScript y codecs de audio y video (iLBC y VP) para intercambiar contenido entre navegadores de manera P2P.
Parece muy complicado y de cierta forma los es, pero existen implementaciones y tutoriales para lograr videoconferencias y transferencias de archivos casi instantáneas. Lo más complicado puede ser la parte no “estandarizada” y los desafíos de superar los firewalls, las redes internas y de coordinar un protocolo en común para concretar la conexión punto a punto.
Estableciendo conexión
Para que la conexión entre los pares sea establecida, estos deben saber cómo localizarse, las medidas de seguridad utilizadas y las políticas de firewall. Para ello debe utilizarse una serie de herramientas en paralelo. Supongamos que hay dos personas en un cuarto que se quieren comunicar entre si utilizando X tecnología. Lo primero que necesitarían es poder identificarse, crear un vínculo mínimo, que les permita al menos establecer en que idioma hablan y cómo se llaman. También este canal previo de comunicación debería dar cuenta de si existen errores al iniciar una comunicación. Evidentemente necesitan de una tercera parte que reciba esos datos y se los pase a la otra parte, ya que entre ellos todavía no saben como hablar. Este mediador se encargará de negociar las condiciones y de establecer cuando está todo listo. También puede permanecer presente como canal de emergencia por si algo falla luego de establecida la comunicación entre las partes.

A ésto en telecomunicaciones se lo conoce como Signaling, y en web lo podemos hacer con protocolos como Websocket o Ajax (servidor de por medio). El proceso sería mas o menos el siguiente:

  • Nicolás crea un objeto RTCPeerConnection.
  • Nicolás crea su “offer” (Session Description Protocol – SDP) con el método createOfferer() de RTCPeerConnection.
  • Nicolás llama setLocalDescription() con su “offer“.
  • Nicolás convierte todos estos datos a texto y mediante el mecanismo de signaling se los envía a Hugo.
  • Hugo recibe mediante signaling la “offer” de Nicolás
  • Hugo crea un setRemoteDescription() con la “offer” de Nicolás, para que su propio RTCPeerConnection conozca la configuración de Nicolás.
  • Hugo llama al metodo createAnswer(), y si todo es correcto, el resultado se lo envía a la descripción de la sesión actual.
  • Hugo toma esta descripción local y la llama setLocalDescription()
  • Hugo convierte todos estos datos a texto y mediante un mecanismo de signaling, se los envía a Nicolás como respuesta.
  • Nicolás recibe la respuesta a su llamada inicial.
  • Hugo y Nicolás establecen la comunicación remota mediante una conexión directa entre sus IP/Puertos y navegadores.


Listo, ya están conectados, el Signaling ya cumplió su propósito y para lo propio de WebRTC ya puede hacerse a un lado. Todo muy lindo en teoría, pero la verdad es que puesto en Internet la cosa es más complicada, la conexión esta realizada entre dos computadoras que se conectan a internet, pero antes de conectarse cada una de ellas pasa por su propio router, incluso varios en caso de empresas o instituciones. Cada uno de éstos configura y mapea puertos distintos, asigna IP locales a múltiples computadoras que comparten una IP pública (la que Hugo conocería de Nicolás y viceversa). Es como si las partes conocieran solo la dirección del edificio al que quieren enviar paquetes, pero nada sobre el piso o número de departamento en el que vive el destinatario, y para colmo tenemos un portero (firewall) que rechaza cualquier cosa que no sea clara o que no esté en la lista de paquetes solicitados por los inquilinos.

ICE, STUN y TURN para hacer un agujero en el NAT

Frente al problema de conocer cuales son los puertos por los que la conexión se va a establecer, existe una serie de herramientas, su uso va dependiendo del fracaso de la anterior, y como en el caso del Signaling es necesario un servidor para realizar los pedidos.



El objetivo es encontrar la dirección IP pública de cada parte, el tipo de NAT en el que se encuentra y el puerto de Internet asociado con el puerto local a través de NAT. Dependiendo del tipo de NAT (cono completo, cono restringido, restringido con puertos o simétrico) STUN puede no funcionar y ahí entra en juego TURN que hace de intermediario entre las partes recibiendo y reenviando paquetes. El único caso en que TURN es necesario es cuando una de las partes está detrás de un NAT simétrico y la otra parte detrás de un NAT simétrico o de cono de puertos restringidos.

ICE (Interactive Connectivity Establishment) soluciona esto, ya que utiliza SDP, STUN y TURN según sea necesario de manera automática. Solo es necesario indicarle que servidores STUN y TURN utilizar. Es necesario entender que mientras STUN solo entrega datos sobre la situación de la red, TURN va a recibir y reenviar paquetes todo el tiempo que la conexión dure. Por lo tanto, éste tipo de conexiones son mas costosas de implementar y de escalar. Por eso existe un extenso listado de servidores STUN gratuitos en Internet, mientras que con TURN deberás implementarlo o contratar algún servicio de media proxy.

No solo se trata de matar a Skype

El uso mas difundido es, el de sistemas de videoconferencias, pero la verdad es que el uso está limitado a la creatividad de quien lo aplique. Hay ejemplos de transferencias de archivos drag-and-drop entre computadoras, sincronización de servidores, incluso sitios webs que se comparten enteramente vía P2P haciendo que sus usuarios se conviertan en servidores.

En la actualidad hay cerca de 2.000.000.000 dispositivos que ya soportan conexiones de tipo WebRTC, y la expectativa es que aumente para 2019 a 7 mil millones (7 billones). No es difícil de imaginar que ya la estemos utilizando a diario sin siquiera saberlo, lo importante ahora es saber cómo incluirla en nuestra colección de herramientas.

0
5
0
5
5Comments
Matab0ts

+10 y tu web una preciosidad. Enhorabuena

0
leomalavera

No lo leí por tiempo pero igual se que es un buen post y merece 10 puntos y reco
mañana lo leeré.
Buen laburo.

0
gmarcos2003

Gracias por los comentarios, voy a tratar de hacer la serie de tutoriales para lograr transmitir canales webs y registrar el video.

0
rocktaku

caramba mañana paso y te dejo puntos buen post.

0
nosion

Muy bueno
Oye de casualidad no sabrás como hacer streaming con ffmpeg??
Nos haces un tutorial please??
Es que vi que hay gente que lo usa para transmitir canales web como los del desaparecido justintv
No tengo puntos, soy rango cuasi troll XD

0