For years, the default answer for real-time bidirectional communication on the web has been simple:

• Need a chat? Use WebSockets.
• Need signaling? Use WebSockets.
• Need lightweight control messages? Use WebSockets.

And honestly, most of the time, that answer is still correct… although not necessarily the most optimal (I still find XMPP / Jabber a pretty robust alternative, and my default choice for certain scenarios where a battle-tested solution with scalability, resilience and chat features matter).

But while working with WebRTC and SFU architectures, I kept running into the same question:

If we already have a fully encrypted, low-latency, bidirectional transport through WebRTC DataChannels (based on SCTP protocol), why introduce a second parallel communication stack with WebSockets?