Video chat peer-to-peer basado en WebRTC. Video chat P2P basado en la instalación de WebRTC Webrtc

Los usuarios de Internet europeos se dividen en dos partes: según una encuesta del Instituto de Análisis de la Opinión Pública de Allenbach (Alemania), Skype, el chat y los sistemas de mensajería instantánea se han convertido en una parte integral de La vida cotidiana De 16,5 millones de adultos y niños, 9 millones utilizan estos servicios ocasionalmente y 28 millones no los tocan.

Esto puede cambiar a medida que Firefox ahora se integre tecnología de comunicación en tiempo real (WebRTC), así como el propio cliente. Iniciar un chat de audio y vídeo ahora no es más difícil que abrir un sitio web. Servicios como Facebook y Skype, por otro lado, se basan en soluciones que utilizan un cliente independiente y crean una cuenta.

WebRTC se distingue no sólo por su facilidad de uso. Este método incluso le permite instalar conexión directa entre dos navegadores. De esta forma, los datos de audio y vídeo no pasan por un servidor donde pueda haber una sobrecarga o donde el administrador no sea especialmente sensible a la privacidad o la protección de datos. Gracias a la conexión directa, WebRTC no requiere registro ni Cuenta en cualquier servicio.

Para iniciar una conversación, sólo necesitas seguir el enlace. La comunicación sigue siendo privada., ya que el flujo de datos está cifrado. Google comenzó a participar activamente en la comunicación en tiempo real a través del navegador en 2011, cuando publicó el código fuente de su implementación WebRTC.

Poco después, Chrome y Firefox recibieron sus propios motores WebRTC. Actualmente, sus versiones móviles están equipadas tanto con esta tecnología como con el motor WebView 3.6 instalado con Android 5.0, que utilizan las aplicaciones.

Para la comunicación en tiempo real, se deben implementar interfaces JavaScript adecuadas en el visor web. Usando GetUserMedia software activa la captura desde fuentes de audio y vídeo, es decir, desde la webcam y el micrófono. RTCPeerConnection es responsable de establecer la conexión así como de la propia comunicación.

Paralelamente a la integración en el navegador, el grupo de trabajo del Consorcio World Wide Web(W3C) ha acelerado el proceso de estandarización de WebRTC. Debería estar terminado en 2015.

WebRTC se contenta con poco

Utilizar el servicio WebRTC no requiere de muchos recursos, ya que el servidor sólo conecta a los interlocutores. Establecer una conexión tampoco es particularmente difícil. Primero, el navegador indica al servidor WebRTC que planea iniciar una llamada. Recibe un enlace HTTPS del servidor: la comunicación está cifrada. El usuario envía este enlace a su interlocutor. Luego, el navegador solicita permiso al usuario para acceder a la cámara web y al micrófono.

Para establecer una conexión de streaming directa con el interlocutor, el navegador recibe su dirección IP y datos de configuración del servicio WebRTC. El visor web de la otra persona hace lo mismo.

Para que la conexión de streaming funcione sin problemas y con buena calidad, tres motores funcionan en el navegador. Dos de ellos optimizan y comprimen datos de audio y vídeo, el tercero se encarga de su transporte. Envía datos a través de protocolo SRTP(Protocolo de transporte seguro en tiempo real), que permite la transmisión cifrada en tiempo real.

Si no se puede establecer una conexión directa, WebRTC busca otra ruta. Por ejemplo, esto sucede cuando configuración de la red evitar que el servidor STUN informe la dirección IP. El estándar WebRTC estipula que en este caso la conversación se llevará a cabo, pero con la activación intermedia del servidor TURN (Traversal Using Relays around NAT). Entonces, en el sitio web netscan.co puedes verificar si WebRTC está implementado en tu computadora y con tu acceso a la Red.

Cómo se hace la conexión

Primero debes registrar la conversación (1). El servicio WebRTC proporciona un enlace que debe enviarse al interlocutor. El navegador, utilizando el servidor STUN, descubre su propia dirección IP (2), la envía al servicio y recibe la IP del socio para establecer una conexión directa (3). Si STUN falla, la conversación se redirige utilizando el servidor TURN (4).

La comunicación mediante tecnología WebRTC en el navegador se inicia mediante código JavaScript. Después de eso, tres motores son responsables de la comunicación: los motores de voz y video recopilan datos multimedia de la cámara web y el micrófono, y el motor de transporte combina la información y envía la transmisión en forma cifrada utilizando SRTP (Protocolo seguro en tiempo real).

¿Qué navegadores funcionan con WebRTC?

Chrome y Firefox tienen un motor WebRTC que utiliza servicios como talky.io. El navegador de Mozilla puede funcionar directamente con su propio cliente.

Google y Mozilla continúan desarrollando la idea de la comunicación en tiempo real: Chrome puede albergar conferencias WebRTC con múltiples participantes, y el nuevo cliente Hello de Firefox se desarrolló en colaboración con una filial del gigante de las telecomunicaciones Telefónica. Apple se mantiene al margen por ahora; no deberías esperar WebRTC en Safari todavía. Sin embargo, hay muchos aplicaciones alternativas para iOS y complementos para Safari.

Microsoft está tomando un rumbo ligeramente diferente. Como propietario de un competitivo servicio de skype Esta empresa no va a capitular ante WebRTC tan fácilmente. En cambio, Microsoft está desarrollando una tecnología llamada ORTC (Object Real-Time Communications) para explorador de Internet.

Las diferencias con WebRTC, como diferentes códecs y protocolos para establecer contacto con el servidor, son menores y con el tiempo probablemente se convertirán en una adición al estándar WebRTC que incluya estas diferencias. Por lo tanto, sólo Apple se queda atrás, como siempre.

Foto: empresas de manufactura; buenaluz/Fotolia.com

La mayor parte del material sobre WebRTC se centra en el nivel de aplicación de la codificación y no contribuye a la comprensión de la tecnología. Intentemos profundizar y descubrir cómo se produce la conexión, qué son el descriptor de sesión y los candidatos, para qué se necesitan. ATURDIR Y DOBLAR servidor.

WebRTC

Introducción

WebRTC es una tecnología orientada al navegador que le permite conectar dos clientes para la transferencia de datos de video. Características principales: compatibilidad con navegador interno (no es necesario utilizar tecnologías implementadas por terceros como Adobe Flash ) y la capacidad de conectar clientes sin utilizar servidores adicionales - conexión de igual a igual(Más, p2p).

Establecer una conexión p2p- una tarea bastante difícil, ya que las computadoras no siempre tienen público IP direcciones, es decir, direcciones en Internet. Debido a la pequeña cantidad IPv4 direcciones (y por motivos de seguridad), se desarrolló un mecanismo NAT, que le permite crear redes privadas, por ejemplo, para uso doméstico. Muchos enrutadores domésticos ahora admiten NAT y gracias a ello todos los dispositivos del hogar tienen acceso a Internet, aunque los proveedores de Internet suelen proporcionar uno IP DIRECCIÓN. Público IP Las direcciones son únicas en Internet, pero las direcciones privadas no lo son. Por lo tanto conéctate p2p- difícil.

Para entender esto mejor, considere tres situaciones: ambos nodos están en la misma red (Foto 1), ambos nodos están en redes diferentes (uno es privado y el otro es público) (Figura 2) y ambos nodos están en diferentes redes privadas con el mismo IP direcciones (Figura 3).

Figura 1: Ambos nodos en la misma red

Figura 2: Nodos en diferentes redes (uno privado, otro público)

Figura 3: Nodos en diferentes redes privadas, pero con direcciones numéricamente iguales

En las figuras anteriores, la primera letra en la notación de dos caracteres indica el tipo de nodo (p = par r = enrutador). En la primera figura, la situación es favorable: los nodos de su red están completamente identificados por red IP direcciones y por lo tanto pueden conectarse entre sí directamente. En la segunda figura tenemos dos redes diferentes con números de nodos similares. Aquí es donde aparecen los routers (routers), que tienen dos interfaz de red– dentro de su red y fuera de su red. Por eso tienen dos IP direcciones. Los nodos regulares tienen una sola interfaz a través de la cual pueden comunicarse únicamente dentro de su red. Si transmiten datos a alguien fuera de su red, entonces solo usan NAT dentro del enrutador (enrutador) y, por lo tanto, visible para otros en IP la dirección del enrutador es de ellos externo IP DIRECCIÓN. Así, en el nodo p1 Hay interior IP = 192.168.0.200 Y externo IP = 10.50.200.5 , y la última dirección también será externa a todos los demás nodos de su red. Una situación similar para el nodo. p2. Por lo tanto, su conexión es imposible si usa solo su interno (propio) IP direcciones. Puede utilizar direcciones externas, es decir, direcciones de enrutador, pero como todos los nodos de la misma red privada tienen la misma dirección externa, esto es bastante difícil. Este problema se resuelve utilizando el mecanismo. NAT

¿Qué pasará si decidimos conectar nodos a través de sus direcciones internas? Los datos no saldrán de la red. Para mejorar el efecto, puede imaginar la situación que se muestra en la última figura: ambos nodos tienen las mismas direcciones internas. Si los usan para comunicarse, cada nodo se comunicará consigo mismo.

WebRTC hace frente con éxito a tales problemas utilizando el protocolo HIELO, que, sin embargo, requiere el uso de servidores adicionales ( ATURDIR, DOBLAR). Más sobre todo esto a continuación.

Dos fases de WebRTC

Para conectar dos nodos a través de un protocolo WebRTC(o simplemente RTC, si dos se comunican iPhone«a) deben adoptarse algunas medidas preliminares para establecer una conexión. Esta es la primera fase: establecer una conexión. La segunda fase es la transmisión de datos de vídeo.

Vale la pena decir de inmediato que aunque la tecnología WebRTC utiliza muchos en su trabajo de varias maneras comunicaciones ( tcp Y UDP) y tiene conmutación flexible entre ellos, esta tecnología no tiene un protocolo para transmitir datos de conexión. No es de extrañar, porque conecta dos nodos. p2p No tan fácil. Por lo tanto es necesario tener algunos adicional un método de transmisión de datos que no está relacionado de ninguna manera con WebRTC. Podría ser una transferencia de socket, protocolo HTTP, incluso podría ser un protocolo SMTP o Correo Ruso. Este mecanismo de transmisión inicial los datos se llaman señal. No es necesario transmitir mucha información. Todos los datos se transmiten en forma de texto y se dividen en dos tipos: partido socialdemócrata Y Candidato de hielo. El primer tipo se utiliza para establecer una conexión lógica y el segundo para una conexión física. Más sobre todo esto más adelante, pero por ahora es importante recordar que WebRTC nos dará cierta información que deberá transmitirse a otro nodo. En cuanto transmitamos toda la información necesaria, los nodos podrán conectarse y ya no será necesaria nuestra ayuda. Entonces, el mecanismo de señalización que debemos implementar es por separado, se utilizará sólo cuando está conectado, pero no se utilizará al transmitir datos de vídeo.

Entonces, consideremos la primera fase: la fase de establecimiento de la conexión. Consta de varios puntos. Veamos esta fase primero para el nodo que inicia la conexión y luego para el que está esperando.

• Iniciador (llamador - llamador):
  1. Oferta para iniciar la transferencia de datos de vídeo (createOffer)
  2. Conseguir el tuyo partido socialdemócrata partido socialdemócrata)
  3. Conseguir el tuyo candidato de hielo candidato de hielo)
• Llamada en espera ( destinatario):
  1. Recibir una transmisión multimedia local (su) y configurarla para su transmisión (getUserMediaStream)
  2. Recibir una oferta para iniciar la transferencia de datos de video y crear una respuesta (createAnswer)
  3. Conseguir el tuyo partido socialdemócrata objeto y transmitirlo a través de un mecanismo de señalización ( partido socialdemócrata)
  4. Conseguir el tuyo candidato de hielo objetos y su transmisión a través de un mecanismo de señalización ( candidato de hielo)
  5. Recibir una transmisión multimedia remota (extranjera) y mostrarla en la pantalla (onAddStream)

La única diferencia está en el segundo punto.

A pesar de la aparente complejidad de los pasos, en realidad hay tres: enviar su propio flujo de medios (elemento 1), configurar los parámetros de conexión (elementos 2 a 4) y recibir el flujo de medios de otra persona (elemento 5). El paso más difícil es el segundo, porque consta de dos partes: establecer físico Y lógico conexiones. El primero indica camino, a lo largo del cual deben viajar los paquetes para llegar de un nodo de red a otro. El segundo indica parámetros de vídeo/audio– qué calidad usar, qué códecs usar.

etapa mental crearoferta o crearRespuesta debe estar conectado a las etapas de transmisión partido socialdemócrata Y candidato de hielo objetos.

Entidades Básicas

Flujos de medios (MediaStream)

La entidad principal es el flujo de medios, es decir, el flujo de datos de vídeo y audio, imágenes y sonido. Hay dos tipos de flujos de medios: locales y remotos. El local recibe datos de los dispositivos de entrada (cámara, micrófono) y el remoto a través de la red. Por tanto, cada nodo tiene un hilo local y uno remoto. EN WebRTC hay una interfaz para hilos Transmisión de medios y también hay una subinterfaz Corriente de medios locales específicamente para hilo local. EN javascript sólo puedes encontrar el primero, y si usas libjingle, entonces puedes encontrarte con el segundo.

EN WebRTC Hay una jerarquía bastante confusa dentro del hilo. Cada transmisión puede constar de varias pistas multimedia ( Pista multimedia), que a su vez puede constar de varios canales de medios ( Canal de medios). Y también puede haber varios flujos de medios.

Miremos todo en orden. Para ello, tengamos en cuenta algún ejemplo. Digamos que queremos transmitir no sólo un vídeo nuestro, sino también un vídeo de nuestra mesa, sobre la que hay un papel en el que vamos a escribir algo. Necesitaremos dos vídeos (nosotros + mesa) y un audio (nosotros). Está claro que nosotros y la tabla deberíamos dividirnos en diferentes subprocesos, porque estos datos probablemente dependen poco unos de otros. Por lo tanto tendremos dos Transmisión de medios‘a – uno para nosotros y otro para la mesa. El primero contendrá datos de video y audio, y el segundo contendrá solo video (Figura 4).

Figura 4: Dos flujos de medios diferentes. Uno para nosotros, uno para nuestra mesa.

Inmediatamente queda claro que un flujo de medios debe incluir como mínimo la capacidad de contener datos. diferentes tipos- vídeo y audio. Esto se tiene en cuenta en la tecnología y por ello cada tipo de datos se implementa a través de un media track. Pista multimedia. Las pistas multimedia tienen una propiedad especial. amable, que determina lo que tenemos frente a nosotros: vídeo o audio (Figura 5)

Figura 5: Los flujos de medios constan de pistas de medios

¿Cómo sucederá todo en el programa? Crearemos dos flujos de medios. Luego crearemos dos pistas de video y una pista de audio. Tengamos acceso a las cámaras y al micrófono. Digamos a cada pista qué dispositivo usar. Agreguemos una pista de video y audio a la primera transmisión multimedia y una pista de video de otra cámara a la segunda transmisión multimedia.

Pero, ¿cómo distinguimos los flujos de medios en el otro extremo de la conexión? Para hacer esto, cada flujo de medios tiene la propiedad etiqueta– etiqueta de flujo, su nombre (Figura 6). Las pistas multimedia tienen la misma propiedad. Aunque a primera vista parece que el vídeo se puede distinguir del sonido de otras formas.

Figura 6: Las secuencias y pistas de medios se identifican mediante etiquetas

Entonces, si las pistas de medios se pueden identificar mediante una etiqueta, ¿por qué necesitamos usar dos flujos de medios para nuestro ejemplo, en lugar de uno? Después de todo, puede transmitir un flujo multimedia, pero utilizar diferentes pistas en él. Hemos llegado a una propiedad importante de los flujos de medios: sincronizar pistas multimedia. Los diferentes flujos de medios no se sincronizan entre sí, pero dentro de cada flujo de medios todas las pistas se juegan simultáneamente.

Por lo tanto, si queremos que nuestras palabras, nuestras emociones faciales y nuestro papel se reproduzcan simultáneamente, entonces vale la pena utilizar un flujo de medios. Si esto no es tan importante, entonces es más rentable utilizar diferentes transmisiones: la imagen será más fluida.

Si es necesario desactivar alguna pista durante la transmisión, puede utilizar la propiedad activado pistas multimedia.

Finalmente, vale la pena pensar en el sonido estéreo. Como sabes, el sonido estéreo son dos sonidos diferentes. Y también deben trasladarse por separado. Para esto se utilizan canales. Canal de medios. Una pista de audio multimedia puede tener muchos canales (por ejemplo, 6 si necesita 5+1 audio). Por supuesto, también hay canales dentro de las pistas de medios. sincronizado. Para el vídeo normalmente se utiliza sólo un canal, pero se pueden utilizar varios, por ejemplo, para superponer publicidad.

Para resumir: Usamos un flujo de medios para transmitir datos de video y audio. Dentro de cada flujo de medios, los datos se sincronizan. Podemos usar múltiples flujos de medios si no necesitamos sincronización. Dentro de cada flujo multimedia hay dos tipos de pistas multimedia: para vídeo y para audio. Normalmente no hay más de dos pistas, pero puede haber más si necesitas transmitir varios vídeos diferentes (del interlocutor y su mesa). Cada pista puede constar de varios canales, que normalmente se utilizan sólo para sonido estéreo.

En la situación de video chat más simple, tendremos un flujo de medios local, que constará de dos pistas: una pista de video y una pista de audio, cada una de las cuales constará de un canal principal. La pista de vídeo es responsable de la cámara, la pista de audio es del micrófono y el flujo de medios es el contenedor de ambos.

Descriptor de sesión (SDP)

Diferentes computadoras siempre tendrán diferentes cámaras, micrófonos, tarjetas de video y otros equipos. Hay muchas opciones que tienen. Todo esto debe coordinarse para la transferencia multimedia de datos entre dos nodos de la red. WebRTC lo hace automáticamente y crea objeto especial– descriptor de sesión partido socialdemócrata. Pase este objeto a otro nodo y se podrán transferir los datos multimedia. Sólo que todavía no hay conexión con otro nodo.

Para ello se utiliza cualquier mecanismo de señalización. partido socialdemócrata se puede transmitir a través de enchufes, por persona (avisarlo a otro nodo por teléfono) o por correo ruso. Es muy sencillo: te darán un modelo ya preparado. partido socialdemócrata y hay que enviarlo. Y al recibirlo por el otro lado - transferir al departamento WebRTC. El descriptor de sesión se almacena como texto y se puede cambiar en sus aplicaciones, pero generalmente esto no es necesario. Por ejemplo, al conectar una computadora de escritorio ↔ un teléfono, a veces es necesario forzar la selección del códec de audio deseado.

Por lo general, al establecer una conexión, debe especificar algún tipo de dirección, por ejemplo URL. Esto no es necesario aquí, ya que a través del mecanismo de señalización tú mismo enviarás los datos a su destino. Indicar WebRTC lo que queremos instalar p2p conexión necesita llamar a la función createOffer. Después de llamar a esta función y darle un especial llamar de vuelta'Se creará un partido socialdemócrata objeto y transferido al mismo llamar de vuelta. Todo lo que se requiere de usted es transferir este objeto a través de la red a otro nodo (interlocutor). Después de esto, los datos llegarán al otro extremo a través del mecanismo de señalización, es decir, este partido socialdemócrata un objeto. Este descriptor de sesión es ajeno a este nodo y, por lo tanto, contiene información útil. Recibir este objeto es una señal para iniciar la conexión. Por lo tanto, debe aceptar esto y llamar a la función createAnswer. Es un análogo completo de createOffer. De vuelta al tuyo llamar de vuelta pasará el descriptor de sesión local y será necesario devolverlo a través del mecanismo de señalización.

Vale la pena señalar que puede llamar a la función createAnswer solo después de recibir el mensaje de otra persona. partido socialdemócrata objeto. ¿Por qué? porque local partido socialdemócrata el objeto que se generará cuando se llame a createAnswer debe depender del control remoto partido socialdemócrata un objeto. Sólo en este caso será posible coordinar la configuración de su vídeo con la configuración de su interlocutor. Además, no debe llamar a createAnswer y createOffer antes de recibir el flujo de medios local; no tendrán nada en qué escribir. partido socialdemócrata un objeto .

Desde en WebRTC es posible editar partido socialdemócrata objeto, luego de recibir el identificador local debe instalarse. Esto puede parecer un poco extraño de transmitir. WebRTC lo que ella misma nos dio, pero ese es el protocolo. Cuando se recibe una manija remota, también se debe instalar. Por lo tanto, debe instalar dos descriptores en un nodo: el suyo y el de otra persona (es decir, local y remoto).

Después de este apretones de manos Los nodos conocen los deseos de los demás. Por ejemplo, si el nodo 1 soporta códecs A Y B, y el nodo 2 soporta códecs B Y C, entonces, dado que cada nodo conoce sus propios descriptores y los de los demás, ambos nodos elegirán el códec B(Figura 7). La lógica de conexión ahora está establecida y se pueden transmitir flujos de medios, pero hay otro problema: los nodos todavía están conectados solo mediante un mecanismo de señalización.

Figura 7: Negociación de códec

candidato de hielo

Tecnología WebRTC tratando de confundirnos con su nueva metodología. Al establecer una conexión, no se especifica la dirección del nodo al que se desea conectar. Instalado primero lógico conexión, no físico, aunque siempre se hizo lo contrario. Pero esto no nos parecerá extraño si no olvidamos que estamos utilizando un mecanismo de señalización de terceros.

Entonces, la conexión ya se ha establecido (conexión lógica), pero aún no existe una ruta por la cual los nodos de la red puedan transmitir datos. No es tan simple, pero comencemos simple. Deje que los nodos estén en la misma red privada. Como ya sabemos, pueden conectarse fácilmente entre sí según sus necesidades internas. IP direcciones (o quizás a alguna otra, si no se utiliza TCP/IP).

Despues de algunos llamar de vuelta'Y WebRTC Cuéntanos candidato de hielo objetos. También vienen en forma de texto y, al igual que los descriptores de sesión, simplemente deben enviarse a través de un mecanismo de señalización. Si el descriptor de sesión contenía información sobre nuestra configuración a nivel de cámara y micrófono, entonces los candidatos contienen información sobre nuestra ubicación en la red. Páselos a otro nodo y podrá conectarse físicamente con nosotros, y como ya tiene un descriptor de sesión, lógicamente podrá conectarse y los datos "fluirán". Si recuerda enviarnos su objeto candidato, es decir, información sobre dónde se encuentra él en la red, podremos conectarnos con él. Observemos aquí una diferencia más con la clásica interacción cliente-servidor. La comunicación con el servidor HTTP se produce según el esquema de solicitud-respuesta, el cliente envía datos al servidor, quien los procesa y los envía a través de la dirección especificada en el paquete de solicitud. EN WebRTC necesito saber dos direcciones y conectarlos por ambos lados.

La diferencia con los descriptores de sesión es que solo es necesario instalar candidatos remotos. La edición aquí está prohibida y no puede aportar ningún beneficio. En algunas implementaciones WebRTC Los candidatos deben instalarse solo después de que se hayan configurado los descriptores de sesión.

¿Por qué solo había un descriptor de sesión pero podía haber muchos candidatos? Porque la ubicación en la red puede ser determinada no sólo por su interior IP dirección, sino también la dirección externa del enrutador, y no necesariamente solo una, así como las direcciones DOBLAR servidores. El resto del párrafo se dedicará a una discusión detallada de los candidatos y cómo conectar nodos de diferentes redes privadas.

Entonces, dos nodos están en la misma red (Figura 8). ¿Cómo identificarlos? Mediante el uso IP direcciones. Ninguna otra manera. Es cierto que aún puedes utilizar diferentes transportes ( tcp Y UDP) y diferentes puertos. Esta es la información contenida en el objeto candidato: IP, PUERTO, TRANSPORTE y algún otro. Utilicemos, por ejemplo, UDP transporte y 531 puerto.

Figura 8: Dos nodos están en la misma red

Entonces si estamos en el nodo p1, Eso WebRTC nos pasará dicho objeto candidato - . Este no es un formato exacto, sólo un diagrama. Si estamos en un nudo p2, entonces el candidato es – . A través de un mecanismo de señalización p1 recibirá un candidato p2(es decir, ubicación del nodo p2, es decir, su IP Y PUERTO). Entonces p1 puede conectarse con p2 directamente. Más correcto, p1 enviará datos a la dirección 10.50.150.3:531 con la esperanza de que lleguen p2. No importa si la dirección pertenece al nodo p2 o algún intermediario. Lo único importante es que los datos se enviarán a través de esta dirección y podrán llegar p2.

Mientras los nodos estén en la misma red, todo es simple y fácil: cada nodo tiene solo un objeto candidato (siempre es decir el suyo, es decir, su ubicación en la red). Pero habrá muchos más candidatos cuando los nodos estén en diferente redes.

Pasemos a un caso más complejo. Un nodo estará ubicado detrás del enrutador (más precisamente, detrás de NAT) y el segundo nodo estará ubicado en la misma red que este enrutador (por ejemplo, en Internet) (Figura 9).

Figura 9: Un nodo está detrás de NAT, el otro no

Este caso tiene una solución particular al problema, que consideraremos ahora. Enrutador doméstico normalmente contiene una tabla NAT. Este es un mecanismo especial diseñado para permitir que los nodos dentro de la red privada del enrutador accedan, por ejemplo, a sitios web.

Supongamos que el servidor web está conectado a Internet directamente, es decir, tiene una conexión pública IP* DIRECCIÓN. Deja que este sea un nodo p2. Nudo p1(cliente web) envía una solicitud a la dirección 10.50.200.10 . Primero los datos van al enrutador. r1, o más bien en su interior interfaz 192.168.0.1 . Después de lo cual, el enrutador recuerda la dirección de origen (dirección p1) y lo ingresa en una tabla especial NAT, luego cambia la dirección de origen a la tuya ( p1 → r1). Además, a mi manera externo interfaz, el enrutador envía datos directamente al servidor web p2. El servidor web procesa los datos, genera una respuesta y la devuelve. Envía al enrutador r1, ya que es él quien está en la dirección del remitente (el enrutador reemplazó la dirección por la suya). El enrutador recibe datos y mira la mesa. NAT y reenvía los datos al nodo p1. El enrutador actúa aquí como intermediario.

¿Qué pasa si varios nodos de la red interna acceden simultáneamente a la red externa? ¿Cómo sabrá el enrutador a quién enviar la respuesta? Este problema se resuelve usando puertos. Cuando un enrutador reemplaza la dirección del host por la suya propia, también reemplaza el puerto. Si dos nodos acceden a Internet, el enrutador reemplaza sus puertos de origen con diferente. Luego, cuando el paquete del servidor web regresa al enrutador, el enrutador entenderá por el puerto a quién está asignado el paquete. Ejemplo a continuación.

Volvamos a la tecnología WebRTC, o mejor dicho, a la parte que usa HIELO protocolo (por lo tanto Hielo candidatos). Nudo p2 tiene un candidato (su ubicación en la red – 10.50.200.10 ), y el nodo p1, que se encuentra detrás de un enrutador con NAT, tendrá dos candidatos: local ( 192.168.0.200 ) y candidato de enrutador ( 10.50.200.5 ). El primero no es útil, pero se genera igualmente, ya que WebRTC todavía no sabe nada sobre el nodo remoto; puede que esté o no en la misma red. El segundo candidato nos vendrá muy bien y, como ya sabemos, el puerto jugará un papel importante (para pasar por NAT).

Entrada de tabla NAT Se genera sólo cuando los datos salen de la red interna. Por lo tanto el nodo p1 debe transmitir los datos primero y solo después los datos del nodo p2 podrá llegar al nodo p1.

En la practica ambos nodos Estará detrás NAT. Para crear un registro en una tabla NAT de cada router, los nodos deben enviar algo al nodo remoto, pero esta vez ni el primero puede llegar al segundo, ni viceversa. Esto se debe al hecho de que los nodos no conocen su IP direcciones, y enviar datos a direcciones internas no tiene sentido.

Sin embargo, si se conocen las direcciones externas, la conexión se establecerá fácilmente. Si el primer nodo envía datos al enrutador del segundo nodo, el enrutador lo ignorará, ya que su tabla NAT vacío por ahora. Sin embargo, en el enrutador del primer nodo de la tabla NAT Necesito una grabación. Si ahora el segundo nodo envía datos al enrutador del primer nodo, entonces el enrutador los transferirá exitosamente al primer nodo. ahora la mesa NAT el segundo enrutador necesita datos.

El problema es que para reconocer tu exterior IP dirección, necesita un nodo ubicado en red compartida. Para solucionar este problema se utilizan servidores adicionales que están conectados directamente a Internet. Con su ayuda también se crean entradas preciadas en la tabla. NAT.

Servidores STUN y TURN

En la inicialización WebRTC debes indicar el disponible ATURDIR Y DOBLAR servidores, que luego llamaremos HIELO servidores. Si no se especifican servidores, solo los nodos en la misma red (conectados a ella sin NAT). Inmediatamente vale la pena señalar que para 3g-Se deben utilizar redes. DOBLAR servidores.

ATURDIR servidor es simplemente un servidor en Internet que devuelve una dirección de remitente, es decir, la dirección del nodo del remitente. El nodo situado detrás del router accede ATURDIR servidor para pasar NAT. El paquete llegó a ATURDIR servidor, contiene la dirección de origen: la dirección del enrutador, es decir, la dirección externa de nuestro nodo. Esta dirección ATURDIR servidor y lo devuelve. Así, el nodo recibe su exterior. IP la dirección y el puerto a través del cual es accesible desde la red. Más, WebRTC El uso de esta dirección crea un candidato adicional (dirección y puerto del enrutador externo). ahora en la mesa NAT El enrutador tiene una entrada que permite que los paquetes enviados al enrutador en el puerto requerido pasen a nuestro nodo.

Veamos este proceso con un ejemplo.

Ejemplo (operación del servidor STUN)

ATURDIR denotaremos el servidor por s1. El enrutador, como antes, a través de r1, y el nodo – a través p1. También deberás seguir la tabla. NAT– denotémoslo como r1_nat. Además, esta tabla suele contener muchos registros de diferentes nodos de la subred; no se proporcionarán.

Entonces, al principio tenemos una mesa vacía. r1_nat.

Tabla 2: Encabezado del paquete

Nudo p1 envía este paquete al enrutador r1(no importa cómo, se pueden usar en diferentes subredes diferentes tecnologías). El enrutador necesita cambiar la dirección de origen. IP principal, ya que la dirección especificada en el paquete obviamente no es adecuada para una subred externa; además, las direcciones de ese rango están reservadas y ni una sola dirección en Internet tiene esa dirección. El enrutador realiza una sustitución en el paquete y crea nueva entrada en tu mesa r1_nat. Para ello, necesita encontrar un número de puerto. Recordemos que dado que varios nodos dentro de una subred pueden acceder a la red externa, entonces en la tabla NAT debe ser mantenido información adicional, para que el enrutador pueda determinar cuál de estos varios nodos está destinado al paquete de retorno del servidor. Deje que el enrutador cree un puerto 888 .

Encabezado del paquete modificado:

Tabla 4: La tabla NAT se ha actualizado con una nueva entrada

Aquí IP la dirección y el puerto de la subred son exactamente los mismos que los del paquete original. De hecho, al realizar una devolución de datos, debemos tener una forma de restaurarlos por completo. IP la dirección de la red externa es la dirección del enrutador y el puerto ha cambiado al inventado por el enrutador.

El puerto real al que se dirige el nodo. p1 acepta la conexión - esto, por supuesto, 35777 , pero el servidor envía datos a ficticio puerto 888 , que será cambiado por el enrutador al real 35777 .

Entonces, el enrutador reemplazó la dirección de origen y el puerto en el encabezado del paquete y agregó una entrada a la tabla. NAT. Ahora el paquete se envía a través de la red al servidor, es decir, al nodo. s1. En la entrada, s1 tiene este paquete:

IP principal	PUERTO Src	IP de destino	Destino PUERTO
10.50.200.5	888	12.62.100.200	6000

Tabla 5: Paquete recibido por el servidor STUN

Total ATURDIR el servidor sabe que recibió un paquete de la dirección 10.50.200.5:888 . Ahora el servidor devuelve esta dirección. Vale la pena detenerse aquí y echar otro vistazo a lo que acabamos de ver. Las tablas anteriores son un fragmento de encabezamiento paquete, en absoluto de él contenido. No hablamos sobre el contenido, ya que no es tan importante, de alguna manera está descrito en el protocolo. ATURDIR. Ahora consideraremos, además del título, el contenido. Será simple y contendrá la dirección del enrutador. 10.50.200.5:888 , aunque lo tomamos de encabezamiento paquete. Esto no se hace con frecuencia; a los protocolos generalmente no les importa la información sobre las direcciones de los nodos; sólo es importante que los paquetes se entreguen a su destino previsto. Aquí estamos ante un protocolo que establece una ruta entre dos nodos.

Ahora tenemos un segundo paquete que va en la dirección opuesta:

Tabla 7: El servidor STUN envía un paquete con este contenido

A continuación, el paquete viaja a través de la red hasta llegar a la interfaz externa del enrutador. r1. El enrutador comprende que el paquete no está destinado a él. ¿Cómo entiende esto? Esto sólo lo puede determinar el puerto. Puerto 888 no lo usa para sus fines personales, sino que lo usa para el mecanismo NAT. Por lo tanto, el enrutador mira esta tabla. mira la columna PUERTO externo y busca una cadena que coincida Destino PUERTO del paquete entrante, es decir 888 .

IP interna	Puerto interno	IP externa	PUERTO externo
192.168.0.200	35777	10.50.200.5	888

Tabla 8: Tabla NAT

Tenemos suerte de que exista esa línea. Si no tuviéramos suerte, el paquete simplemente sería descartado. Ahora necesita comprender qué nodo de la subred debe enviar este paquete. No hay que apresurarse, recordemos nuevamente la importancia de los puertos en este mecanismo. Al mismo tiempo, dos nodos de la subred podrían enviar solicitudes a la red externa. Entonces, si para el primer nodo el enrutador encontró un puerto 888 , luego, para el segundo, se le ocurriría un puerto 889 . Supongamos que esto sucedió, es decir, la mesa r1_nat tiene este aspecto:

Tabla 10: El enrutador reemplaza la dirección del receptor

IP principal	PUERTO Src	IP de destino	Destino PUERTO
12.62.100.200	6000	192.168.0.200	35777

Tabla 11: El enrutador cambió la dirección del receptor

El paquete llega exitosamente al nodo. p1 y al observar el contenido del paquete, el nodo aprende sobre su contenido externo. IP dirección, es decir, la dirección del enrutador en la red externa. También conoce el puerto por el que pasa el enrutador. NAT.

¿Que sigue? ¿De qué sirve todo esto? El beneficio es una entrada en una tabla. r1_nat. Si ahora alguien manda al router r1 paquete con puerto 888 , entonces el enrutador reenviará este paquete al nodo p1. Así, se creó un pequeño pasaje estrecho hacia el nodo oculto. p1.

Del ejemplo anterior puedes hacerte una idea de cómo funciona. NAT y esencia ATURDIR servidor. En general, el mecanismo HIELO Y ATURDIMIENTO/GIRO Los servidores están precisamente orientados a superar las limitaciones. NAT.

Entre el nodo y el servidor puede haber no un enrutador, sino varios. En este caso, el nodo recibirá la dirección del enrutador que sea el primero en acceder a la misma red que el servidor. En otras palabras, obtenemos la dirección del enrutador conectado al ATURDIR servidor. Para p2p La comunicación es exactamente lo que necesitamos, si no olvidamos el hecho de que cada enrutador agregará la fila que necesitamos a la tabla. NAT. Por lo tanto, el camino de regreso volverá a ser igual de sencillo.

DOBLAR el servidor esta mejorado ATURDIR servidor. A partir de aquí se debe saber inmediatamente que cualquier DOBLAR El servidor puede funcionar y cómo. ATURDIR servidor. Sin embargo, también hay ventajas. Si p2p la comunicación es imposible (como en 3g redes), luego el servidor cambia al modo repetidor ( relé), es decir, funciona como intermediario. Por supuesto, sobre nada. p2p entonces no hay duda, pero fuera del marco del mecanismo HIELO los nodos creen que se están comunicando directamente.

En que casos es necesario DOBLAR¿servidor? ¿Por qué no hay suficiente ATURDIR servidores? El caso es que existen varias variedades. NAT. Se sustituyen por igual IP dirección y puerto, pero algunos de ellos tienen incorporada protección adicional contra la “falsificación”. Por ejemplo, en simétrico mesa NAT Se guardan 2 parámetros más - IP y el puerto del nodo remoto. Un paquete de la red externa pasa a través NAT a la red interna sólo si la dirección de origen y el puerto coinciden con los registrados en la tabla. Por lo tanto, el enfoque ATURDIR el servidor falla - tabla NAT dirección y puerto de la tienda ATURDIR servidor y cuando el enrutador recibe un paquete de WebRTC interlocutor, lo descarta porque está “falsificado”. El no vino de ATURDIR servidor.

De este modo DOBLAR Se necesita un servidor cuando ambos interlocutores están ubicados. simétrico NAT(cada uno a lo suyo).

Breve resumen

Aquí hay algunas declaraciones sobre entidades. WebRTC que siempre hay que tener presente. Se describen en detalle arriba. Si alguna de las afirmaciones no le parece del todo clara, vuelva a leer los párrafos pertinentes.

• flujo de medios
  • Los datos de vídeo y audio se empaquetan en flujos de medios.
  • Las transmisiones multimedia sincronizan las pistas multimedia que componen
  • Diferentes flujos de medios no están sincronizados entre sí.
  • Las transmisiones de medios pueden ser locales y remotas, la local generalmente está conectada a una cámara y un micrófono, las remotas reciben datos de la red en forma cifrada.
  • Hay dos tipos de pistas multimedia: de vídeo y de audio.
  • Las pistas multimedia tienen la capacidad de activarse o desactivarse
  • Las pistas de medios constan de canales de medios.
  • Las pistas multimedia sincronizan los canales multimedia que componen
  • Los flujos de medios y las pistas de medios tienen etiquetas por las que se pueden distinguir
• identificador de sesión
  • El descriptor de sesión se utiliza para conectar lógicamente dos nodos de red.
  • El descriptor de sesión almacena información sobre formas disponibles Codificación de datos de vídeo y audio.
  • WebRTC utiliza un mecanismo de señalización externo: la tarea de reenviar descriptores de sesión ( partido socialdemócrata) cae en la aplicación
  • El mecanismo de conexión lógica consta de dos etapas: oraciones ( oferta) y la respuesta ( respuesta)
  • La generación de un descriptor de sesión no es posible sin utilizar un flujo de medios local en el caso de una propuesta ( oferta) y no es posible sin utilizar un identificador de sesión remota en caso de una respuesta ( respuesta)
  • El descriptor resultante debe entregarse a la implementación. WebRTC, y no importa si este descriptor se obtiene de forma remota o local desde la misma implementación WebRTC
  • Es posible editar ligeramente el descriptor de sesión.
• Candidatos
  • candidato ( candidato de hielo) es la dirección del nodo en la red
  • La dirección del nodo puede ser la suya o puede ser la dirección de un enrutador o DOBLAR servidores
  • Siempre hay muchos candidatos.
  • El candidato está formado por IP dirección, puerto y tipo de transporte ( tcp o UDP)
  • Los candidatos se utilizan para establecer una conexión física entre dos nodos en una red.
  • Los candidatos también deben ser enviados a través de un mecanismo de señalización.
  • Los candidatos también deben ser transferidos a implementaciones. WebRTC, sin embargo sólo remoto
  • En algunas implementaciones WebRTC Los candidatos solo se pueden transmitir después de que se haya establecido el descriptor de sesión.
• ATURDIMIENTO/GIRO/HIELO/NAT
  • NAT– mecanismo para proporcionar acceso a la red externa
  • Los enrutadores domésticos admiten una mesa especial NAT
  • El enrutador reemplaza las direcciones en los paquetes: la dirección de origen por la suya propia, si el paquete va a una red externa, y la dirección del receptor por la dirección del host en la red interna, si el paquete proviene de una red externa.
  • Para proporcionar acceso multicanal a la red externa. NAT utiliza puertos
  • HIELO– mecanismo de derivación NAT
  • ATURDIR Y DOBLAR servidores: servidores auxiliares para omitir NAT
  • ATURDIR el servidor le permite crear los registros necesarios en la tabla NAT, y también devuelve la dirección externa del nodo
  • DOBLAR servidor generaliza ATURDIR mecanismo y hace que siempre funcione
  • En los peores casos DOBLAR el servidor se utiliza como intermediario ( relé), eso es p2p se convierte en una comunicación cliente-servidor-cliente.

WebRTC (Web Real Time Communications) es un estándar que describe la transmisión de datos de audio, datos de video y contenido desde y hacia el navegador en tiempo real sin instalar complementos u otras extensiones. El estándar permite convertir tu navegador en un terminal de videoconferencia, basta con abrir una página web para empezar a comunicarte.

¿Qué es WebRTC?

En este artículo veremos todo lo que necesita saber sobre la tecnología WebRTC para usuario regular. Veamos las ventajas y desventajas del proyecto, revelemos algunos secretos, le digamos cómo funciona, dónde y para qué se utiliza WebRTC.

¿Qué necesitas saber sobre WebRTC?

Evolución de los estándares y tecnologías de comunicación por vídeo.

Sergey Yutsaitis, Cisco, Vídeo+Conferencia 2016

Cómo funciona WebRTC

Lado del cliente

• El usuario abre una página que contiene una etiqueta HTML5.
• El navegador solicita acceso a la cámara web y al micrófono del usuario.
• El código JavaScript en la página del usuario controla los parámetros de conexión (direcciones IP y puertos del servidor WebRTC u otros clientes WebRTC) para evitar NAT y Firewall.
• Al recibir información sobre el interlocutor o sobre la transmisión de la conferencia mezclada en el servidor, el navegador comienza a negociar los códecs de audio y video utilizados.
• Comienza el proceso de codificación y la transferencia de datos de streaming entre clientes WebRTC (en nuestro caso, entre el navegador y el servidor).

En el lado del servidor WebRTC

No se requiere un servidor de video para intercambiar datos entre dos participantes, pero si necesita combinar a varios participantes en una conferencia, se requiere un servidor.

El servidor de video recibirá tráfico multimedia de varias fuentes, lo convertirá y lo enviará a los usuarios que usan WebRTC como terminal.

Además, el servidor WebRTC recibirá el tráfico de medios de los pares WebRTC y lo transmitirá a los participantes de la conferencia que utilizan aplicaciones para computadores de escritorio o dispositivos móviles, Si alguna.

Ventajas del estándar

• No se requiere instalación de software.
• Muy alta calidad de comunicación, gracias a:
  • Uso de códecs de vídeo (VP8, H.264) y audio (Opus) modernos.
  • Ajuste automático de la calidad de la transmisión a las condiciones de conexión.
  • Sistema incorporado de reducción de eco y ruido.
  • Ajuste automático del nivel de sensibilidad de los micrófonos participantes (AGC).
• Alto nivel de seguridad: todas las conexiones están protegidas y cifradas mediante protocolos TLS y SRTP.
• Hay un mecanismo incorporado para capturar contenido, por ejemplo, el escritorio.
• Posibilidad de implementar cualquier interfaz de gestión basada en HTML5 y JavaScript.
• La capacidad de integrar la interfaz con cualquier sistema back-end utilizando WebSockets.
• Proyecto con apertura código fuente- se puede implementar en su producto o servicio.
• Verdadera multiplataforma: la misma aplicación WebRTC funcionará igual de bien en cualquier Sistema operativo, de escritorio o móvil, siempre que el navegador admita WebRTC. Esto ahorra significativamente recursos en el desarrollo de software.

Desventajas del estándar

• Para organizar conferencias grupales de audio y video, se requiere un servidor de videoconferencia que mezcle video y sonido de los participantes, porque El navegador no sabe cómo sincronizar varias transmisiones entrantes entre sí.
• Todas las soluciones WebRTC son incompatibles entre sí, porque... el estándar describe solo métodos para transmitir video y audio, dejando la implementación de métodos para dirigirse a los suscriptores, rastrear su disponibilidad, intercambiar mensajes y archivos, programar y otras cosas al proveedor.
• En otras palabras, no podrá llamar desde una aplicación WebRTC de un desarrollador a una aplicación WebRTC de otro desarrollador.
• Mezclar conferencias grupales requiere grandes recursos informáticos, por lo que este tipo de comunicación por video requiere comprar una suscripción paga o invertir en su infraestructura, donde cada conferencia requiere 1 núcleo físico de un procesador moderno.

Secretos de WebRTC: cómo los proveedores se benefician de la innovadora tecnología web

Tzachi Levent-Levi, Bloggeek.me, Vídeo+Conferencia 2015

WebRTC para el mercado de videoconferencias

Aumento del número de terminales de videoconferencia

La tecnología WebRTC ha tenido una fuerte influencia en el desarrollo del mercado de las videoconferencias. Después del lanzamiento de los primeros navegadores con soporte WebRTC en 2013, el número potencial de terminales de videoconferencia en todo el mundo aumentó inmediatamente en mil millones de dispositivos. De hecho, cada navegador se ha convertido en un terminal de videoconferencia, no inferior a sus homólogos de hardware en términos de calidad de comunicación.

Uso en soluciones especializadas.

El uso de varias bibliotecas de JavaScript y API de servicios en la nube con soporte WebRTC facilita agregar soporte de comunicación por video a cualquier proyecto web. Anteriormente, para transmitir datos en tiempo real, los desarrolladores tenían que estudiar los principios de funcionamiento del protocolo y utilizar los desarrollos de otras empresas, lo que a menudo requería licencias adicionales, lo que aumentaba los costos. WebRTC ya se utiliza activamente en servicios como "Llamada desde el sitio", "Soporte por chat en línea", etc.

Ex usuarios de Skype para Linux

En 2014, Microsoft anunció el fin del soporte para el proyecto Skype para Linux, lo que provocó una gran irritación entre los especialistas en TI. La tecnología WebRTC no está vinculada al sistema operativo, sino que se implementa a nivel del navegador, es decir. Usuarios de Linux Podrá ver productos y servicios basados ​​en WebRTC como un reemplazo completo de Skype.

Competencia con Flash

WebRTC y HTML5 supusieron un golpe mortal para la tecnología Flash, que ya atravesaba sus peores años. Desde 2017, los principales navegadores dejaron oficialmente de admitir Flash y la tecnología ha desaparecido por completo del mercado. Pero debemos darle a Flash lo que le corresponde, porque fue él quien creó el mercado de las conferencias web y ofreció habilidades técnicas para comunicación en vivo en navegadores.

Presentaciones de vídeo WebRTC

Dmitry Odintsov, TrueConf, vídeo+conferencia octubre de 2017

Códecs en WebRTC

Códecs de audio

WebRTC utiliza códecs Opus y G.711 para comprimir el tráfico de audio.

G.711- el códec de voz más antiguo con una alta tasa de bits (64 kbps), que se utiliza con mayor frecuencia en los sistemas de telefonía tradicionales. La principal ventaja es la carga computacional mínima debido al uso de algoritmos de compresión livianos. El códec tiene un bajo nivel de compresión de señales de voz y no introduce retrasos de audio adicionales durante la comunicación entre usuarios.

G.711 es compatible con una gran cantidad de dispositivos. Los sistemas que utilizan este códec son más fáciles de utilizar que los basados ​​en otros códecs de audio (G.723, G.726, G.728, etc.). En términos de calidad, G.711 recibió una puntuación de 4,2 en las pruebas MOS (una puntuación entre 4 y 5 es la más alta y significa buena calidad, similar a la calidad de la transmisión del tráfico de voz en RDSI e incluso superior).

Opus es un códec con baja latencia de codificación (de 2,5 ms a 60 ms), soporte para velocidades de bits variables y altos niveles de compresión, ideal para transmitir señales de audio en streaming en redes con variables rendimiento. Opus es una solución híbrida que combina las mejores características de los códecs SILK (compresión de voz, eliminación de distorsión del habla humana) y CELT (codificación de datos de audio). El códec está disponible gratuitamente; los desarrolladores que lo utilizan no necesitan pagar regalías a los titulares de derechos de autor. En comparación con otros códecs de audio, Opus sin duda gana en muchos aspectos. Ha eclipsado a códecs de baja tasa de bits bastante populares, como MP3, Vorbis y AAC LC. Opus restaura la “imagen” del sonido más cercana al original que AMR-WB y Speex. Este códec es el futuro, razón por la cual los creadores de la tecnología WebRTC lo incluyeron en la gama obligatoria de estándares de audio compatibles.

Códecs de vídeo

Los desarrolladores tardaron varios años en elegir un códec de vídeo para WebRTC y, al final, decidieron utilizar H.264 y VP8. Casi todos los navegadores modernos admiten ambos códecs. Los servidores de videoconferencia solo necesitan admitir uno para funcionar con WebRTC.

VP8- un códec de vídeo gratuito con licencia abierta, caracterizado por una alta velocidad de decodificación de secuencias de vídeo y una mayor resistencia a la pérdida de fotogramas. El códec es universal y fácil de implementar en plataformas de hardware, razón por la cual los desarrolladores de sistemas de videoconferencia lo utilizan con mucha frecuencia en sus productos.

Códec de video pago H.264 Se hizo famoso mucho antes que su hermano. Este es un códec con un alto grado de compresión de la transmisión de video al guardar. Alta calidad video. La alta prevalencia de este códec entre los sistemas de videoconferencia de hardware sugiere su uso en el estándar WebRTC.

Google y Mozilla están promoviendo activamente el códec VP8, y Microsoft, Apple y Cisco están promoviendo activamente H.264 (para garantizar la compatibilidad con los sistemas de videoconferencia tradicionales). Y aquí surge un problema muy grande para los desarrolladores de soluciones WebRTC en la nube, porque si todos los participantes en una conferencia usan el mismo navegador, entonces basta con mezclar la conferencia una vez con un códec, y si los navegadores son diferentes y Safari / Edge son entre ellos, entonces la conferencia tendrá que codificarse dos veces con códecs diferentes, lo que duplicará la Requisitos del sistema al servidor de medios y, como resultado, el costo de las suscripciones a los servicios WebRTC.

API WebRTC

La tecnología WebRTC se basa en tres API principales:

• (responsable de que el navegador web reciba señales de audio y video de las cámaras o del escritorio del usuario).
• Conexión RTCPeer(responsable de la conexión entre navegadores para "intercambiar" datos multimedia recibidos de la cámara, el micrófono y el escritorio. Además, las "responsabilidades" de esta API incluyen el procesamiento de señales (limpiarlas de ruidos extraños, ajustar el volumen del micrófono) y controlar el códecs de audio y vídeo utilizados).
• Canal de datos RTC(proporciona transferencia de datos bidireccional a través de una conexión establecida).

Antes de acceder al micrófono y a la cámara del usuario, el navegador solicita permiso para hacerlo. EN Google Chrome Puedes configurar el acceso con antelación en la sección “Configuración”; en Opera y Firefox, los dispositivos se seleccionan directamente en el momento de obtener el acceso, desde una lista desplegable. La solicitud de permiso siempre aparecerá cuando se use el protocolo HTTP y solo una vez si se usa HTTPS:

Conexión RTCPeer. Cada navegador que participa en una conferencia WebRTC debe tener acceso a este objeto. Gracias al uso de RTCPeerConnection, los datos multimedia de un navegador a otro pueden incluso pasar a través de NAT y cortafuegos. Para transmitir con éxito flujos de medios, los participantes deben intercambiar los siguientes datos utilizando un transporte como web sockets:

• el participante iniciador envía al segundo participante una Oferta-SDP (estructura de datos con las características del flujo de medios que transmitirá);
• el segundo participante genera una "respuesta" - Answer-SDP y la envía al iniciador;
• luego se organiza un intercambio de candidatos ICE entre los participantes, si se detecta alguno (si los participantes están detrás de NAT o firewalls).

Una vez finalizado con éxito este intercambio, se organiza la transferencia directa de flujos de medios (audio y vídeo) entre los participantes.

Canal de datos RTC. El soporte para el protocolo Data Channel apareció en los navegadores hace relativamente poco tiempo, por lo que esta API puede considerarse exclusivamente en los casos de uso de WebRTC en los navegadores. Mozilla Firefox 22+ y Google Chrome 26+. Con su ayuda, los participantes pueden intercambiar mensajes de texto en el navegador.

Conexión vía WebRTC

Navegadores de escritorio compatibles

• Google Chrome (17+) y todos los navegadores basados ​​en el motor Chromium;
• Mozilla FireFox (18+);
• Ópera (12+);
• Safari (11+);

Navegadores móviles compatibles con Android

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Ópera Móvil (12+);
• Safari (11+).

WebRTC, Microsoft e Internet Explorer

Durante mucho tiempo, Microsoft guardó silencio sobre la compatibilidad con WebRTC en Internet Explorer y su nuevo navegador Edge. A los chicos de Redmond no les gusta mucho poner en manos de los usuarios tecnologías que no controlan, esa es su política. Pero poco a poco el asunto salió de un punto muerto, porque... Ya no era posible ignorar WebRTC y se anunció el proyecto ORTC, un derivado del estándar WebRTC.

Según los desarrolladores, ORTC es una extensión del estándar WebRTC con un conjunto mejorado de API basadas en JavaScript y HTML5, lo que, traducido al lenguaje común, significa que todo será igual, solo Microsoft, y no Google, controlará el estándar. y su desarrollo. El conjunto de códecs se ha ampliado con soporte para H.264 y algunos códecs de audio de la serie G.7ХХ, utilizados en telefonía y sistemas de videoconferencia por hardware. Es posible que haya soporte integrado para RDP (para transferencia de contenido) y mensajería. Por cierto, los usuarios de Internet Explorer no tienen suerte: la compatibilidad con ORTC solo estará disponible en Edge. Y, por supuesto, este conjunto de protocolos y códecs interactúa fácilmente con Skype Empresarial, lo que abre aún más aplicaciones comerciales para WebRTC.

El propósito de este artículo es utilizar una muestra de demostración de video chat de igual a igual (video chat p2p) para familiarizarse con su estructura y principio de funcionamiento. Para ello, utilizaremos la demostración de chat de vídeo punto a punto multiusuario webrtc.io-demo. Se puede descargar desde el enlace: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Cabe señalar que GitHub es un sitio o servicio web para el desarrollo colaborativo de proyectos Web. En él, los desarrolladores pueden publicar los códigos de sus desarrollos, discutirlos y comunicarse entre sí. Además, algunas grandes empresas de TI publican sus repositorios oficiales en este sitio. El servicio es gratuito para proyectos de código abierto. GitHub es un repositorio de bibliotecas de código fuente abiertas y gratuitas.

Entonces, colocaremos la muestra de demostración del chat de video punto a punto descargado de GitHub en la unidad C. computadora personal en el directorio creado para nuestra aplicación "webrtc_demo".

Arroz. 1

Como se desprende de la estructura (Fig. 1), el chat de vídeo punto a punto consta de scripts de cliente script.js y servidor server.js, implementados en el lenguaje de programación JavaScript. Script (biblioteca) webrtc.io.js (CLIENTE): proporciona la organización de comunicaciones en tiempo real entre navegadores utilizando un esquema peer-to-peer: "cliente-cliente", y webrtc.io.js (CLIENTE) y webrtc. io.js (SERVIDOR), utilizando el protocolo WebSocket, proporcionan comunicación dúplex entre el navegador y el servidor web utilizando una arquitectura cliente-servidor.

El script webrtc.io.js (SERVIDOR) se incluye en la biblioteca webrtc.io y se encuentra en el directorio node_modules\webrtc.io\lib. La interfaz de video chat index.html está implementada en HTML5 y CSS3. El contenido de los archivos de la aplicación webrtc_demo se puede ver utilizando uno de los editores html, por ejemplo "Notepad++".

Comprobaremos el principio de funcionamiento del video chat en sistema de archivos ORDENADOR PERSONAL. Para ejecutar el servidor (server.js) en una PC, debe instalar el entorno de ejecución node.js. Node.js le permite ejecutar código JavaScript fuera del navegador. Puede descargar node.js desde el enlace: http://nodejs.org/ (versión v0.10.13 al 15/07/13). En la página principal del sitio web node.org, haga clic en el botón de descarga y vaya a http://nodejs.org/download/. Para usuarios de Windows, primero descargue win.installer (.msi), luego ejecute win.installer (.msi) en la PC e instale nodejs y "npm package manager" en el directorio de Archivos de programa.

Arroz. 2

Así, node.js consta de un entorno para desarrollar y ejecutar código JavaScript, así como un conjunto de módulos internos que se pueden instalar mediante el administrador o el administrador de paquetes npm.

Para instalar módulos debes línea de comando Desde el directorio de la aplicación (por ejemplo, "webrtc_demo") ejecute el comando: npm instala nombre_módulo. Durante la instalación de módulos, el administrador npm crea una carpeta node_modules en el directorio desde el que se realizó la instalación. Durante la operación, nodejs conecta automáticamente los módulos desde el directorio node_modules.

Entonces, después de instalar node.js, abra la línea de comando y actualice el módulo express en la carpeta node_modules del directorio webrtc_demo usando el administrador de paquetes npm:

C:\webrtc_demo>npm instalar expreso

El módulo express es un framework web para node.js o una plataforma web para el desarrollo de aplicaciones. Para tener acceso global a express, puedes instalarlo así: instalación npm -g expreso.

Luego actualice el módulo webrtc.io:

C:\webrtc_demo>npm instalar webrtc.io

Luego en la línea de comando lanzamos el servidor: server.js:

C:\webrtc_demo>servidor de nodo.js

Arroz. 3

Eso es todo, el servidor se está ejecutando correctamente (Figura 3). Ahora, usando un navegador web, puede comunicarse con el servidor por dirección IP y cargar la página web index.html, desde la cual el navegador web extraerá el código de secuencia de comandos del cliente: script.js y el código de secuencia de comandos webrtc.io.js, y ejecútalos. Para operar el chat de video punto a punto (para establecer una conexión entre dos navegadores), debe comunicarse con el servidor de señales que se ejecuta en node.js desde dos navegadores que admitan webrtc.

Como resultado, se abrirá la interfaz de la parte cliente de la aplicación de comunicación (video chat) con una solicitud de permiso para acceder a la cámara y al micrófono (Fig. 4).

Arroz. 4

Después de hacer clic en el botón "Permitir", la cámara y el micrófono se conectan para la comunicación multimedia. Además, puede comunicarse mediante datos de texto a través de la interfaz de video chat (Fig. 5).

Arroz. 5

Se debe notar que. El servidor es un servidor de señalización y está diseñado principalmente para establecer conexiones entre los navegadores de los usuarios. Node.js se utiliza para operar el script del servidor server.js que proporciona señalización WebRTC.