There is some misconception around WebSockets and WebRTC – like when and where to use, which one is better etc. If we know the reason behind developing these technologies, opting apt one for our use will be pretty easy.
So, let us understand why they are developed and what are they good at.
WebRTC is designed for high-performance, high quality communication of video, audio and arbitrary data. In other words, for apps exactly like what you describe.
WebRTC apps need a service via which they can exchange network and media metadata, a process known as signaling. Once signaling has taken place, video/audio/data is streamed directly between clients, avoiding the performance cost of streaming via an intermediate server.
WebSockets on the other hand is designed for bi-directional communication between client and server. It is possible to stream audio and video over WebSocket, but the technology and APIs are not inherently designed for efficient, robust streaming in the way that WebRTC is.
WebSocket (or frameworks that use it, such as Socket.io) can be a good choice for signaling.
- Ratified IETF standard (6455) with support across all modern browsers and even legacy browsers using web-socket-js polyfill.
- Uses HTTP compatible handshake and default ports making it much easier to use with existing firewall, proxy and web server infrastructure.
- Much simpler browser API. Basically one constructor with a couple of callbacks.
- Client/browser to server only.
- Only supports reliable, in-order transport because it is built On TCP. This means packet drops can delay all subsequent packets.
- Just beginning to be supported by Chrome and Firefox. MS has proposed an incompatible variant. The DataChannel component is not yet compatible between Firefox and Chrome.
- WebRTC is browser to browser in ideal circumstances but even then almost always requires a signaling server to setup the connections. The most common signaling server solutions right now use WebSockets.
- Transport layer is configurable with application able to choose if connection is in-order and/or reliable.
- Complex and multi-layered browser API. There are JS libs to provide a simpler API but these are young and rapidly changing (just like WebRTC itself).