Everyone building group video eventually learns the same lesson. Getting it working is the easy 80 percent. The last part, the bit that decides whether real users actually have a good call, is where all the time goes.
I have shipped a few of these now, and the pattern holds. You get an SFU in place, calls scale past a handful of people, the demo looks great, and then you launch and a whole new category of problems turns up that never appeared on your test network. Here are the ones that got me, and what to do about them.
TURN is not optional, and where you put it matters
In the office, every WebRTC connection succeeds, because everyone is on the same clean network. Out in the wild, a real chunk of your users sit behind symmetric NATs and corporate firewalls that block direct peer connections outright. For them, media has to be relayed through a TURN server, or the call just fails with no obvious error.
So you stand up coturn:
# turnserver.conf, the parts that actually matter
listening-port=3478
tls-listening-port=5349
min-port=49152
max-port=65535
lt-cred-mech
realm=yourdomain.com
external-ip=YOUR_PUBLIC_IP
fingerprint
The bit people miss is placement. A TURN server in one region relaying media for users on the far side of the planet adds brutal latency. If your users are spread out, your relays have to be spread out too, close to them. One central TURN box is fine for a demo and a real problem at scale.
Your bandwidth assumptions are wrong
On your test setup, everyone has fat, stable bandwidth. Real users do not. Someone is tethered to a phone, someone's kid is streaming Netflix on the same line, someone drops from wifi to cellular halfway through.
WebRTC adapts on its own through congestion control, but if you are running simulcast on an SFU, you still have to wire up the logic that picks which quality layer to forward to each viewer as their bandwidth shifts. Get that wrong and you hit the classic failure. One person on bad wifi, the SFU keeps pushing them a high layer, their call falls apart, and everyone else is fine and confused about the complaints.
Watch it with getStats instead of guessing:
JS
setInterval(async () => {
const stats = await pc.getStats();
stats.forEach((report) => {
if (report.type === "inbound-rtp" && report.kind === "video") {
console.log({
packetsLost: report.packetsLost,
jitter: report.jitter,
framesDropped: report.framesDropped,
});
}
});
}, 2000);
Packet loss and jitter creeping up is your early warning, well before a user types "is anyone else lagging?"
Calls die when the network changes
This one is easy to miss completely, because it never happens at your desk. A user walks out of wifi range, their phone flips to cellular, and their IP changes. The existing ICE connection is now pointing at an address that no longer exists, and the call just freezes.
The fix is an ICE restart, which renegotiates the connection paths without tearing down the whole call:
js
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState === "disconnected" ||
pc.iceConnectionState === "failed") {
pc.restartIce(); // renegotiate paths, keep the call alive
}
};
Without this, every network hiccup is a dropped call and an annoyed user. With it, most of them recover in a second or two and nobody even notices.
You cannot fix what you cannot see
The last one is less a bug and more a habit. If your only signal that calls are bad is users complaining, you are already too late. Pull those getStats numbers into something you can look at across sessions: packet loss, round-trip time, bitrate, freeze counts. The teams that run good video are the ones watching these, not the ones waiting for a support ticket.
The takeaway
Getting a video call working is a weekend. Getting it to hold up for real users on real networks is the actual project, and none of it, the TURN placement, the bandwidth handling, the reconnection logic, the monitoring, shows up until you are live. That gap is why serious video conferencing software development takes real time, and why custom audio video conferencing solutions usually get built by people who have already hit these walls. If you want to see how that side comes together, we do this kind of production video work day to day.
Anyway. If you are shipping group video soon, assume every one of these is coming for you. They are.
Top comments (0)