7 WebRTC
7.1 Aplicaciones

Con WebRTC [20], varias aplicaciones se pueden construir - no sólo se limita a funciones de comunicación. WebRTC no (sólo/principalmente ) se trata de " llamar " desde dentro del navegador, sino de permitir a los desarrolladores web acceder a los dispositivos de entrada de audio / vídeo a través de JavaScript , así como abstraer el problema de la comunicación de navegador a navegador para los desarrolladores web normales.

Una vez que el problema de comunicación de navegador a navegador ha sido resuelto, el WebRTC proporciona tanto un canal de datos de usuario para los datos de comunicaciones en tiempo real, como un canal de datos para enviar cualquier otro tipo de datos de una manera de igual a igual.

Todo esto en su mayoría no exige plug-ins - pero es compatible de forma nativa en los navegadores (actualmente Google Chrome, Mozilla Firefox, Opera, Microsoft Edge).

Aplicaciones navegador a navegador para llamadas de voz y conversación en vídeo

La aplicación más simple para WebRTC es la comunicación de audio / vídeo entre los navegadores. La capacidad interna del WebRTC ofrece micrófono (audio) y acceso a la cámara (vídeo) (el usuario puede seleccionar el dispositivo y concesión permiso).

Las funciones de la API importantes para este caso de uso son

Antes de que getUserMedia estuviera disponible, los navegadores manejaban ya objetos multimedia "estáticos" (< img >, <video >, <audio >). Estos objetos no sólo se podían mostrar, sino que también podían ser manipulados (por ejemplo, una etiqueta < img > puede escalarse usando el atributo width = " 400 "). La API getUserMedia añade el acceso a fuentes dinámicas tales como micrófonos y cámaras. Las características de estas fuentes pueden cambiar en respuesta a las necesidades de la aplicación. Los MediaConstraints se utilizan como forma estándar de la restricción de recursos.

El PeerConnection es una tecnología de comunicación que permite a dos usuarios comunicarse directamente, de un navegador a otro. Esta comunicación se coordina a través de un canal de señalización que es proporcionado por medios no especificados, pero por lo general por una secuencia de comandos en la página web que ha sido proporcionada por el servidor web. Muchos sitios web tienen ya la posibilidad de intercambiar mensajes entre el cliente y el servidor web (por ejemplo, a través de sockets web) .

Ejemplos de servicios son:

Compartir ficheros P2P

El RTCDataChannel permite a una aplicación web enviar y recibir datos de aplicación genérica peer- to-peer.

La interfaz DataChannel representa un canal de datos bidireccional entre dos compañeros. Mientras que el PeerConnection es un canal para RTC solamente, el DataChannel puede transportar cualquier tipo de datos.

Un servicio ejemplo es sharefest.me.

Pantalla compartida

La API getUserMedia no sólo puede acceder a la cámara / micrófono como fuente de los medios, sino también a la pantalla compartida. Por razones de seguridad, el acceso a la pantalla requiere un plug-in. Este plug-in sin embargo, no está permitiendo compartir la pantalla como tal (esto se hace por la parte WebRTC del navegador) , sino sólo el acceso a la API del navegador para ciertos dominios que están explícitamente permitidos a través del plug-in .

La mayoría de los servicios que se utilizan para comunicarse con audio / vídeo también ofrecen compartir pantalla.

Pizarra colaborativa

Además de una comunicación A/V y compartir la pantalla, el canal de datos aplicado también se puede utilizar para transferir no sólo archivos, sino también el control de la información. Esta información de control se puede utilizar para modificar el contenido mostrado en el navegador.

Un ejemplo de aplicación para esto puede ser una pizarra colaborativa. Mediante el envío de las entradas de una pizarra (" editor") para todas las demás pizarras bajo el mismo enlace ("espectadores") la aplicación del navegador puede actuar como pizarra compartida. Con el apoyo de la comunicación WebRTC, se puede utilizar, por ejemplo, un sitio web dentro de aprendizaje electrónico.

Realizar conferencias

Desde un concepto de navegador puro, el WebRTC se concibe como la comunicación de igual a igual, sin requerir infraestructura adicional.

Este enfoque arquitectónico hace que sea difícil de realizar sesiones con múltiples corrientes tales como grupos de videoconferencias u otros escenarios de radiodifusión "n-a-m".

Este enfoque arquitectónico hace que sea difícil realizar sesiones con múltiples corrientes tales como vídeoconferencias en grupo u otros escenarios de radiodifusión "a -n- m".

Vamos a empezar por el concepto de igual a igual, lo que se traduce en un enfoque de red de malla completa.

La mayor ventaja de este enfoque es su simplicidad al poder ser construido por un desarrollador, ya que no requiere ningún tipo de punto de distribución en el centro de la red (comparar Figura 12).

Por otra parte, esta simplicidad tiene el precio de una demanda muy alta en términos de rendimiento de la red. Cuantos más participantes asisten a una conferencia, más alto es el rendimiento de la red requerida en general.

image
Fig. 12 – Aproximación de red Peer-to-Peer

En contraste con el enfoque peer-to-peer, que implica una unidad de envío selectivo, una unidad de control de los medios requiere servidores adicionales (véase la Figura 13). Una unidad de envío selectivo actúa similar a un router o proxy, que transmite cada flujo de medios que recibe de uno a todos los otros.

Por una parte, esto reduce el rendimiento de la red requerida, como resultado de la posibilidad de subir sólo un flujo de medios por pares.

Por otra parte, el rendimiento de la red requerida solamente se desplaza hacia la unidad de envío selectivo.

En el caso de una unidad de control de los medios, la unidad central recibe todas las transmisiones multimedia de los receptores, de manera similar a la unidad de envío selectivo. Sin embargo, en un segundo paso, el tráfico es procesado por la unidad central, a fin de construir una corriente individual para cada receptor. Por último, la unidad de control de los medios de comunicación transmite sólo el flujo individual a cada receptor, lo que se traduce en una gran mejora en términos de rendimiento de la red requerida. Además, este enfoque también permite una amplia variedad de casos de aplicación concebibles mediante el uso de diferentes tipos de procesamiento de medios de la unidad central.

image
Fig. 13 - Unidad de Control de Medios de Comunicación y Unidad de reenvío selectivo