¿WebRTC es sin ningún servidor ni siquiera un servidor de señalización posible?

Resumen

WEBRTC es un conjunto de componentes que habilita los medios en tiempo real y los canales de datos entre los navegadores. Sin embargo, todavía requiere un servicio de backend para ciertas funcionalidades. En este artículo, exploraremos las razones por las cuales es necesario un servicio de backend, los componentes y el hardware involucrados en la configuración de WEBRTC, los códecs de audio y videos compatibles, y la importancia de un directorio y servidor de aturdimiento.

1. ¿Qué es WebRTC??

WebRTC es un conjunto de componentes que permite a los desarrolladores configurar medios en tiempo real y canales de datos entre navegadores. Fue creado por Google y contiene componentes clave que se envían en Chrome, Firefox, Opera y Microsoft Edge (ORTC).

2. ¿Por qué todavía necesita un servicio de backend??

A pesar de las capacidades de WebRTC, se requiere un servicio de backend para ciertas funcionalidades. Por ejemplo, para llamar a alguien, debe conocer su dirección, que generalmente es dinámica. Esta información debe almacenarse y administrarse en un servidor. Además, un servicio de backend puede realizar un seguimiento de todos los dispositivos para un usuario y notificarles las llamadas entrantes.

3. Qué componentes y hardware están involucrados en la configuración de WebRTC?

WebRTC ayuda a configurar el entorno físico, como cámaras, altavoces y micrófonos, así como otros hardware como la cancelación de eco y el hardware de cancelación de fondo. También ayuda a configurar la red utilizando Stun (utilidades de traversal de sesión para NAT).

4. Qué códecs de audio son compatibles con WebRTC?

WebRTC admite varios códecs de audio, incluidos G711, ILBC y Opus. Opus es un códec variable de alta calidad ampliamente utilizado en WebRTC.

5. ¿Qué códecs de video son compatibles con WebRTC??

WebRTC admite códecs VP8 y VP9, ​​que son las variaciones libres de regalías de Google de H.264/h.265. También es compatible.264.

6. ¿Por qué son importantes los códecs de audio en WEBRTC??

Los códecs de audio manejan tareas como pérdida de paquetes, codificación y decodificación de audio, corrección de errores, cancelación de ruido, cancelación de eco y nivelación de volumen. Contribuyen a la popularidad de WebRTC en dispositivos y escritorios móviles.

7. ¿Cuál es el directorio de quién está disponible para llamar??

Para iniciar una llamada, debe saber la dirección del destinatario. El directorio sirve como páginas blancas dinámicas, lo que permite a los usuarios registrarse con un servidor y proporcionar información de contacto. Esto se puede implementar utilizando protocolos XMPP, SIP o personalizados.

8. ¿Por qué necesitas un servidor de aturdimiento??

Un servidor STUN (Session Traversal Utilidades para NAT) ayuda a determinar la dirección IP externa de un dispositivo y verifica si dos dispositivos pueden comunicarse directamente. Desempeña un papel crucial en el establecimiento de conexiones entre pares.

9. ¿Qué es un servidor de giro??

Si no es posible una sesión de igual a igual debido a las limitaciones de los firewall, se necesita un servidor de turno (transversal que usa relés alrededor de NAT). Ayuda a transmitir datos entre dispositivos evitando las restricciones de firewall.

10. ¿Por qué debería considerar usar un servicio de backend como Sinch??

Configurar y mantener servidores para la señalización, aturdimiento y giro puede ser complejo y costoso. Sinch, como proveedor de servicios de backend, ofrece soluciones escalables y rentables. Manejan mil millones de minutos por año y proporcionan SDK de WEBRTC optimizados para diferentes dispositivos y condiciones de red.

11. ¿Es WebRTC solo sobre backend??

No, WebRTC involucra aspectos de frontend y backend. Sinch, por ejemplo, personaliza y configura su SDK de WebRTC para garantizar un rendimiento óptimo entre dispositivos y condiciones de red. Implementan características como opus adaptativas para ajustar la calidad de grabación en función de las métricas de calidad del tráfico.

12. ¿Cuáles son los beneficios de usar Sinch??

Sinch ofrece experiencia en comunicaciones en tiempo real y proporciona SDK de WEBRTC personalizados, códecs optimizados y una red distribuida. Su precio para la transferencia de datos es rentable y garantizan una comunicación de baja latencia a través de servidores estratégicamente ubicados.

13. ¿Qué tan notable es la latencia de red en una conversación??

Alrededor de 250 ms de latencia de red se nota durante una conversación. Factores como la latencia de la red, el tiempo de procesamiento y la codificación de datos pueden contribuir a la latencia general.

14. ¿Qué funcionalidades ofrece un servicio de backend en WebRTC??

Un servicio de backend maneja tareas como administración de directorio, señalización, administración de servidores de aturdimiento y giro, y seguimiento de dispositivos para usuarios.

15. ¿Qué hace que WebRTC sea popular en dispositivos y escritorios móviles??

El soporte de WebRTC para códecs de audio y video, junto con su facilidad de uso y en tiempo real, contribuye a su popularidad en dispositivos y escritorios móviles.

¿WebRTC es sin ningún servidor ni siquiera un servidor de señalización posible?

Luego, abra dos pestañas en su navegador (o en dos navegadores diferentes), e ingrese Localhost: 7000. Como se mencionó anteriormente, es mejor tener dos cámaras disponibles para que este ejemplo funcione. Si todo va bien, debería ver una alimentación de video en cada una de las pestañas.

WebRTC y por qué todavía necesita un servicio de backend

Únase a la comunidad Dzone y obtenga la experiencia de miembro completo.

Este artículo apareció originalmente en el blog Sinch de Christian Jensen.

¿Qué es WebRTC??

WebRTC es un conjunto de componentes basados ​​en un par de innovaciones de empresas que Google compró en 2010. WebRTC permite a un desarrollador configurar medios en tiempo real y canales de datos entre dos navegadores (o móviles si lo compila para eso). Contiene un par de componentes clave y todos se envían en Chrome, Firefox y Opera, y existe una versión en Microsoft’s nuevo borde del navegador (ORTC).

Configuración de flujos de datos y hardware

WebRTC ayuda a configurar el entorno físico (como cámaras, altavoces y micrófonos) y otro hardware (como la cancelación de eco y el hardware de cancelación de fondo, aquellos que encontrará principalmente en móviles), además de ayudar a descubrir la red junto con Stun.

Códecs de audio y códecs de video

Uno de los principales beneficios que usa WebRTC sobre otro software cuando se trata de audio y video en tiempo real es el código abierto/códecs libres de regalías que Google tiene la amabilidad de enviar.

Códecs de audio

• G711, utilizado en redes telefónicas regulares
• ILBC, antigua codificada de banda estrecha, también se usa en redes telefónicas
• Opus, una variable de alta calidad y un códec (soporte para adaptación) que es el más nuevo en códec utilizado en WebRTC.

Hay más enviados, pero estos son los principales y los más utilizados.

Códecs de video

• VP8 y pronto VP9, ​​este es Google’S Variación de una H libre de regalías H.264/h.265 códec
• H.264 (agregado en 2015 como un acuerdo para ORTC)

Los códecs de audio hacen mucho trabajo por usted, cuidando la pérdida de paquetes, la codificación y decodificación de audio, corrección de errores, cancelación de ruido, cancelación de eco, nivelación de volumen y más. El hecho de que contenga códecs también lo hace muy popular en dispositivos y escritorios móviles.

Entonces, ahora puedo construir mi propia llamada basada en el navegador en puro JavaScript usando (agregue el marco JS del lado del cliente favorito aquí). Desafortunadamente,’S no es tan simple para configurar una llamada ya que faltan dos cosas principales aquí.

Directorio de quién está disponible para llamar (o descubrimiento de pares)

Para llamar a alguien, debe conocer la dirección y, a diferencia de los números de teléfono regulares, el direccionamiento en Internet es principalmente direcciones IP dinámicas. Para resolver esto, debes mantener el registro de dónde están todos. Esto se puede hacer de varias maneras usando XMPP, SIP, protocolos personalizados, etc., Pero todo se reduce a que cualquiera que esté listo para recibir una llamada de llamada en un servidor de una forma u otra, y le permite al servidor saber cómo contactar a ese par (implícito para una mayor entrega de oferta/invitación/SDP, etc.).

Piense en ello como una páginas blancas totalmente dinámicas. Esto generalmente se realiza en intervalos cronometrados para mantener los firewalls o de manera similar abierta para que el servidor de señalización notifique al cliente si alguien quiere comunicarse con ellos. Entonces, esta es la primera pieza que debe construir encima de eso.

A continuación, probablemente desee realizar un seguimiento de todos los dispositivos para un usuario en particular y notificarlos en todos los dispositivos si hay una llamada. Usando Sinch, nos encargamos de esta parte por ti.

Servidor de aturdimiento

Después de que su servidor de señalización ha localizado un dispositivo y envía una oferta, necesita un servidor de aturdimiento. El servidor de Stun facilitará determinar su dirección IP externa, así como si los dos (o más) dispositivos puedan hablar entre sí directamente entre sí. Sinch también se encargará de esto por ti.

Servidor de retransmisión de medios (servidor de giro)

Si no es posible una sesión entre pares (nuestros propios datos sugieren que esto representa alrededor del 25% de las sesiones), necesitará un servidor de giro. El servidor de giro básicamente cambiará los bits para usted a través de agujeros abiertos en el firewall entre los dos clientes. Por qué pasó esto? El más común son los firewalls asimétricos y la posibilidad de hacer agujeros en diferentes puertos en firewalls.

Ok, pero ¿por qué Don’t Presco esto yo mismo?

Bueno, podrías. Esto podría ser un poco excesivo, y se requerirá una competencia más en su equipo de operaciones. Su turno y los servidores de aturdimiento probablemente estarán muy utilizados y caros. Y aquí es donde entra la economía escalable. Dado que Sinch está haciendo más de mil millones de minutos por año, nuestros precios para la transferencia de datos son más baratos de lo que la mayoría de las empresas pueden obtener.

Probablemente también desee tener una red distribuida. Si, por ejemplo, tiene su servidor de turno en la U.S. y las llamadas están ocurriendo entre clientes en Europa, agregará latencia solo porque todo el tráfico necesita cruzar el océano. Una buena regla general es que alrededor de los 250 ms se nota en una conversación (más información de calidad de servicio aquí). Por lo tanto, sin agregar latencia de red en el cliente y el tiempo de procesamiento para codificar los datos, está básicamente garantizado que tiene demasiada latencia entre los clientes.

¿Se trata solo de backend??

Él’no solo sobre el backend. En Sinch tenemos una vasta experiencia de comunicaciones en tiempo real, y estamos personalizando y configurando nuestro SDK de WEBRTC para trabajar lo mejor en todos los dispositivos y en diferentes condiciones de redes. Un par de ejemplos son la implementación de Opus Adaptive, que ajustará la calidad de grabación en función de las métricas de calidad de nuestro tráfico. También sabemos qué códecs usar en circunstancias específicas, y cuáles seleccionar para minimizar la transcodificación y la latencia en todo el mundo.

Publicado en Dzone con permiso de Christian Jensen . Vea el artículo original aquí.

Las opiniones expresadas por los contribuyentes de dzone son propias.

¿WebRTC es sin ningún servidor ni siquiera un servidor de señalización posible??

Estoy tratando de configurar un complemento de Cordova para iOS que implementa las funciones de WebRTC sin usar ningún servidor y lo hará solo se utilizará en una red local. Sé que hay este complemento, que parece prometedor, pero tengo algunos problemas con ello. Mi plan no es usar un trun, aturdimiento o cualquier tipo de servidor de señalización. Quizás pienses ahora mismo: “Ok esto no es posible. Sin señalización es igual a sin conexión.“Pero déjame explicar primero. Como se señala aquí y aquí, es posible evitar usar un servidor Trun, aturdimiento o hielo. Creo que esta es una buena manera de comenzar mi proyecto, pero todavía hay una pregunta abierta. ¿Cómo se encontrarán los dispositivos si no hay ninguna señalización de tipo (en el ejemplo usan un nodo?.servidor js)? Ahora mismo estoy jugando con la idea de un código QR que contiene toda la información necesaria. Al final, debería verse así (los arrwos negros son más importantes): la idea es que todos los que entran en una habitación tienen que escanear un código QR en el RP y luego el dispositivo conoce la IP, el puerto, etc. de la conexión RP y WebRTC con un Datachannel se establecerá. He estado buscando una respuesta durante días, pero debido al hecho (o al menos una de las razones) que WebRTC ni siquiera es compatible con iOS Nativly no hay muchos ejemplos de WebRTC que funcionen en iOS y nadie para una red local. Entonces mi pregunta es: ¿Estoy de la manera correcta o esto ni siquiera es posible?? (No encontré ningún ejemplo para esto en ningún lugar, pero si junto todas las publicaciones que leí, creo que debería ser posible.)

preguntó el 10 de agosto de 2017 a las 12:38

3,257 3 3 insignias de oro 11 11 insignias de plata 19 19 Insignias de bronce

No importa cómo resuelva el descubrimiento, pero para establecer una conexión WEBRTC, debe obtener los mensajes de oferta y respuesta entre los compañeros de alguna manera. Esos mensajes contienen automáticamente candidatos de hielo si espera a que la reunión de hielo termine primero. Ver StackOverflow.com/a/29056385/918910.

WebRTC: un ejemplo de funcionamiento

Recientemente tuve que usar WebRTC para un proyecto simple. La tecnología en sí tiene muchas ventajas y se está desarrollando como un estándar abierto, sin la necesidad de ningún complemento. Sin embargo, era bastante nuevo en WebRTC y tuve algunos problemas para entender los conceptos básicos, así como crear una solución de trabajo. Hay muchos tutoriales disponibles (como este, que inspiró mi solución). Pero la mayoría de ellos son incompletos, obsoletos o me obligaron a usar algunos servicios de terceros (E.gramo. Google Firebase), que solo hizo que todo el proceso fuera más complicado de configurar y más difícil de entender.

Decidí armar la información de todos esos recursos y crear un ejemplo simple y de trabajo de una aplicación WEBRTC. No requiere ningún servicio de terceros a menos que desee usarlo a través de una red pública (en cuyo caso posee un servidor realmente ayudaría). Espero que proporcione un buen punto de partida para todos los interesados ​​en explorar WebRTC.

Este no será un tutorial completo de la tecnología WebRTC. Puede encontrar muchos tutoriales y explicaciones detalladas en todo Internet, por ejemplo aquí. También puede consultar la API de WebRTC si desea más información. Esta publicación solo le mostrará un posible ejemplo de trabajo de WebRTC y explicará cómo funciona.

Descripción general

El código fuente completo de este ejemplo está disponible en GitHub. El programa consta de tres partes:

• Aplicación web
• servidor de señalización
• Servidor de giro

El Aplicación web es muy simple: un archivo HTML y un archivo JavaScript (más una dependencia: enchufe.IO.js, que se incluye en el repositorio). Está diseñado para funcionar con solo dos clientes (dos navegadores web o dos pestañas del mismo navegador). Una vez que lo abra en su navegador (probado en Firefox 74), solicitará permiso para usar su cámara y micrófono. Una vez que se otorga el permiso, el video y el audio de cada una de las pestañas se transmitirán al otro.

Nota: Puede experimentar algunos problemas si intenta acceder a la misma cámara desde ambas pestañas. En mi prueba, yo’He usado dos dispositivos mientras se probó en mi máquina (una cámara portátil incorporada y una cámara web USB).

El servidor de señalización es utilizado por las aplicaciones WEBRTC para intercambiar información requerida para crear una conexión directa entre pares. Puede elegir cualquier tecnología que desee para esto. Este ejemplo usa WebSockets (python-socketio en backend y enchufe.io-cliente en frontend).

El DOBLAR Se requiere un servidor si desea usar este ejemplo a través de una red pública. El proceso se describe más a fondo en esta publicación. Para las pruebas de red locales, no lo necesitará.

Señalización

El servidor de señalización está escrito en Python3 y se ve así:

Desde AIOHTTP Importación web Importación Socketio Room = 'Room' SIO = Socketio.Asyncserver (cors_allowed_origins = '*') app = web.Aplicación () SIO.Adjuntar (aplicación) @sio.Event Async Def Connect (Sid, Environ): Print ('Connected', Sid) espera sio.emit ('listo', habitación = habitación, skip_sid = sid) sio.Enter_room (Sid, habitación) @sio.Evento Def Desconecte (SID): SIO.Leave_room (sid, habitación) impresión ('desconectado', sid) @sio.Event Async Def Data (SID, Data): imprimir ('Mensaje de <>: <>'.formato (sid, datos)) espera sio.emit ('Data', Data, Room = Room, Skip_sid = Sid) if __name__ == '__main__': Web.run_app (aplicación, puerto = 9999)

Cada cliente se une a la misma habitación. Antes de entrar en la habitación, un listo El evento se envía a todos los clientes actualmente en la sala. Eso significa que la primera conexión de WebSocket no recibirá ningún mensaje (la habitación está vacía), pero cuando se establezca la segunda conexión, la primera recibirá un listo Evento, lo que indica que hay al menos dos clientes en la habitación y la conexión WebRTC puede comenzar. Aparte de eso, este servidor reenviará cualquier dato (datos evento) que se envía por un websocket al otro.

La configuración es bastante simple:

Señalización de CD PIP Instalar AIOHTTP Python-Socketio Python Server.py

Esto iniciará el servidor de señalización en Localhost: 9999.

Webrtc

El proceso simplificado de usar WEBRTC en este ejemplo se ve así:

• Ambos clientes obtienen sus transmisiones de medios locales
• Una vez que se obtiene la secuencia, cada cliente se conecta al servidor de señalización
• Una vez que el segundo cliente se conecta, el primero recibe un listo evento, lo que significa que se puede negociar la conexión WebRTC
• El primer cliente crea un objeto RTCPeerConnection y envía una oferta al segundo cliente
• El segundo cliente recibe la oferta, crea un objeto RTCPeerConnection y envía una respuesta
• También se intercambia más información, como los candidatos de hielo
• Una vez que se negocia la conexión, se llama a una devolución de llamada para recibir una secuencia remota, y esa secuencia se utiliza como fuente del video elemento.

Si desea ejecutar este ejemplo en localhost, el servidor de señalización y la aplicación web es todo lo que necesita. La parte principal del archivo HTML es un solo elemento de video (que la fuente será establecida más tarde por el script):

La parte de JavaScript es un poco más complicada, y yo’lo explicaré paso a paso. Primero, están las variables de configuración:

// Variables de configuración const Signaling_Server_url = 'http: // localhost: 9999'; const pc_config = <>;

Para localhost, Pc_config puede permanecer vacío y Señaling_server_url debe apuntar al servidor de señalización que’he comenzado en el paso anterior.

A continuación, tenemos los métodos de señalización:

Sea socket = io (señaling_server_url, < autoConnect: false >); enchufe.en ('Data', (Data) => < console.log('Data received: ',data); handleSignalingData(data); >); enchufe.en ('listo', () => < console.log('Ready'); createPeerConnection(); sendOffer(); >); Deje sendData = (data) => < socket.emit('data', data); >;

En este ejemplo, queremos conectarnos al servidor de señalización solo después de obtener la transmisión de medios locales, por lo que necesitamos establecer . Aparte de eso, tenemos un enviar datos método que emite un datos evento, y reaccionamos al datos Evento manejando la información entrante adecuadamente (más sobre ella más tarde). Además, recibir un listo El evento significa que ambos clientes han obtenido sus transmisiones de medios locales y se han conectado al servidor de señalización, por lo que podemos crear una conexión de nuestro lado y negociar una oferta con el lado remoto.

dejar PC; Deje que LocalStream; Dejar remotrastreamelement = documento.QuerySelector ('#remotreStream');

Deje getLocalStream = () => < navigator.mediaDevices.getUserMedia(< audio: true, video: true >) .Entonces ((stream) => < console.log('Stream found'); localStream = stream; // Connect after making sure that local stream is availble socket.connect(); >) .Catch (Error => < console.error('Stream not found: ', error); >); >

Deje CreatePeerConnection = () => < try < pc = new RTCPeerConnection(PC_CONFIG); pc.onicecandidate = onIceCandidate; pc.onaddstream = onAddStream; pc.addStream(localStream); console.log('PeerConnection created'); >captura (error) < console.error('PeerConnection failed: ', error); >>;

Deje sendoffer = () => < console.log('Send offer'); pc.createOffer().then( setAndSendLocalDescription, (error) => < console.error('Send offer failed: ', error); >); >; Deje sendanswer = () => < console.log('Send answer'); pc.createAnswer().then( setAndSendLocalDescription, (error) => < console.error('Send answer failed: ', error); >); >; Dejar setandsendLocalDescription = (sessionDescription) => < pc.setLocalDescription(sessionDescription); console.log('Local description set'); sendData(sessionDescription); >;

Let OniceCandidate = (Event) => < if (event.candidate) < console.log('ICE candidate'); sendData(< type: 'candidate', candidate: event.candidate >); >>; Deje que OnaddStream = (Event) => < console.log('Add stream'); remoteStreamElement.srcObject = event.stream; >;

Deje que HandlesignalingData = (data) => < switch (data.type) < case 'offer': createPeerConnection(); pc.setRemoteDescription(new RTCSessionDescription(data)); sendAnswer(); break; case 'answer': pc.setRemoteDescription(new RTCSessionDescription(data)); break; case 'candidate': pc.addIceCandidate(new RTCIceCandidate(data.candidate)); break; >>;

// Iniciar conexión getLocalStream ();

CD web python -m http.servidor 7000

sudo apt install coturn thurnserver -a -o -v -n -no -dtls -no -tls -u nombre de usuario: credencial -r reasmname

const gurn_server_url = ': 3478'; const gurn_server_username = 'username'; const gurn_server_credential = 'credencial'; const pc_config = < iceServers: [ < urls: 'turn:' + TURN_SERVER_URL + '?transport=tcp', username: TURN_SERVER_USERNAME, credential: TURN_SERVER_CREDENTIAL >, < urls: 'turn:' + TURN_SERVER_URL + '?transport=udp', username: TURN_SERVER_USERNAME, credential: TURN_SERVER_CREDENTIAL >]>;