Después de consultar con especialistas en este tema, programadores de deferentes ramas y maestros dimos con la solución al dilema y la dejamos plasmada en este post.
Solución:
WebRTC está diseñado para comunicaciones de video, audio y datos arbitrarios de alto rendimiento y alta calidad. En otras palabras, para aplicaciones exactamente como las que describes.
Las aplicaciones WebRTC necesitan un servicio a través del cual puedan intercambiar metadatos de medios y redes, un proceso conocido como señalización. Sin embargo, una vez que se ha realizado la señalización, el video/audio/datos se transmiten directamente entre los clientes, lo que evita el costo de rendimiento de la transmisión a través de un servidor intermediario.
WebSocket, por otro lado, está diseñado para la comunicación bidireccional entre el cliente y el servidor. Es posible transmitir audio y video a través de WebSocket (ver aquí por ejemplo), pero la tecnología y las API no están diseñadas inherentemente para una transmisión eficiente y robusta en la forma en que lo está WebRTC.
Como han dicho otras respuestas, WebSocket se puede usar para la señalización.
Mantengo una lista de recursos de WebRTC: le recomiendo encarecidamente que empiece por mirar la presentación de Google I/O de 2013 sobre WebRTC.
WebSockets:
-
Estándar IETF ratificado (6455) compatible con todos los navegadores modernos e incluso navegadores heredados que usan web-socket-js polyfill.
-
Utiliza protocolo de enlace compatible con HTTP y puertos predeterminados, lo que facilita mucho su uso con la infraestructura existente de firewall, proxy y servidor web.
-
API de navegador mucho más simple. Básicamente, un constructor con un par de devoluciones de llamada.
-
Cliente/navegador a servidor solamente.
-
Solo admite transporte en orden confiable porque está construido en TCP. Esto significa que las caídas de paquetes pueden retrasar todos los paquetes posteriores.
WebRTC:
-
Apenas comienza a ser compatible con Chrome y Firefox. MS ha propuesto una variante incompatible. El componente DataChannel aún no es compatible entre Firefox y Chrome. -
WebRTC es navegador a navegador en circunstancias ideales, pero aun así casi siempre requiere un servidor de señalización para configurar las conexiones. Las soluciones de servidor de señalización más comunes en este momento usan WebSockets.
-
La capa de transporte se puede configurar con la aplicación capaz de elegir si la conexión está en orden y/o es confiable.
-
API de navegador compleja y de varias capas. Hay bibliotecas JS para proporcionar una API más simple, pero son nuevas y cambian rápidamente (al igual que el propio WebRTC).
Los websockets utilizan el protocolo TCP.
WebRTC es principalmente UDP.
Por lo tanto, la razón principal de usar WebRTC en lugar de Websocket es la latencia. Con la transmisión por websocket, tendrá una latencia alta o una reproducción entrecortada con una latencia baja. Con WebRTC, puede lograr una reproducción suave y de baja latencia, lo cual es crucial para las comunicaciones VoIP.
Solo intente probar estas tecnologías con una pérdida de red, es decir, 2%. Verá grandes retrasos en la transmisión de Websocket.
Sección de Reseñas y Valoraciones
Al final de todo puedes encontrar las crónicas de otros gestores de proyectos, tú igualmente tienes la habilidad dejar el tuyo si te gusta.