What it is
A technology for real-time voice and video in the browser, directly between participants, with no page reloads.
How we apply it
For voice inside our own services — for example, mesh voice chat where audio doesn't pass through an intermediate server at all.
Where WebRTC helps a business
- A team needs voice rooms and calls on its own server rather than in a cloud messenger.
- A broadcast should be watchable almost without delay: screen sharing, gameplay, a presentation.
- Everything should run in a browser on desktop and phone, with nothing to install.
- The server must not be able to hear conversations.
Architectures
- Mesh: every participant connects directly to every other. Latency is in the tens of milliseconds and the server load is almost zero, but everyone sends their voice to everyone, so there is a cap on the number of people.
- Through a server (SFU): participants send their stream to a server, which forwards it to the others. Needed for large rooms, but it requires server capacity.
- WHEP: receiving a broadcast over WebRTC with under a second of latency, instead of HLS with several seconds.
How we use it
In Peregovorka, our platform for voice, chat and streaming:
- Mesh voice. Three shared voice channels, calls in private conversations, and groups, with up to 10 people per channel. Voice goes directly between participants and is encrypted between browsers; the server only introduces participants and relays signalling packets.
- Our own TURN. People who cannot connect directly are helped by a coturn relay. Credentials are temporary and last an hour, and the relay cannot decrypt a conversation.
- Streaming. A viewer picks the regular mode (HLS, 6 to 8 seconds of latency, stable on mobile networks) or the fast one (WHEP, under a second).
- Screen sharing goes through the server: 1080p, 30 frames per second, up to 18 Mbit/s.
We deploy such a platform on your server under Infrastructure.
Common problems
- Mesh does not scale. With 10 participants each one sends voice to nine others. More than 10 people per channel would need a different design, through a server.
- Without TURN some people cannot connect. Routers and mobile networks do not always allow a direct connection, so your own TURN is a must.
- Browsers differ. Chrome, Edge and Safari play the stream in 1440p, while Firefox gets 720p in H.264. Moving the chat into a separate window over a game works in Chrome and Edge from version 116.
- Encryption is not everywhere. Voice is encrypted between browsers, but text chats are not: they sit in the database on the server, and this is listed among the limitations.
When you do not need it
If an ordinary messenger is enough for the team and its availability is not in question, your own platform is just one more server to maintain. And mesh voice does not suit webinars for hundreds of viewers: they need a different architecture.