Why do video calls cut out?

Question

I'm on the mathy end of tech, so I've treated the low level details of the internet as a black box all my career. Why do calls over the internet always cut out here and there? Is it a fundamental limitation of the foundations we use? What's the ELI35 answer to "Goddammit, Zoom, I missed that whole last sentence. WTF?"

PaulHoule · Accepted Answer

The internet works on a "best effort" basis.
Compare that to old voice telecom networks that reserved bandwidth end-to-end for the whole call.
If you send a packet to somebody you are talking to it is likely the packet will make it the whole way, but if a wireless connection experiences a burst of noise, a buffer is full somewhere, or there was some kind of glitch, or if the routing got changed, a packet gets lost.
Recovery is not supposed to be "at the the hop that got lost" (sometimes it is and that's mostly a bad thing!) but rather "end-to-end". That is, if a packet is lost it is up to the two sides communicating to decide what to do about it. In the case of a file transfer (say a web site) the far end might ask for missing content to be re transmitted. In the case of a phone call "the show most go on" and the dropped content can be discarded, the important thing is that subsequent packets get through.

retrac · Answer

One practical thing is to ensure your upstream isn't heavily congested. Many Internet connections are asymmetrical with much more downstream bandwidth than upstream. And many, if not most streaming protocols, are inherently bidirectional and are sending a constant stream of "Okay, got that!" acknowledgements both ways, which if congested, will tend to mess up video on both ends.
Otherwise, as another user mentioned, ultimately, there's no way around the "some of the packets disappeared in transit" problem. It's like white noise on an analogue radio channel. Some of the bits just get lost in transit. At that point, you can either request a resend (with unavoidable delay/skipping/glitching) or you can just drop the packets and re-sync when the stream starts making sense again (again with some degree of unavoidable blackout and glitching).
With that said, video could be more reliable. There are quality of service options. Streaming protocols could use forward error correction (though that has latency issues) and they could use UDP or checksumless UDP instead of TCP, which are less reliable but also generally less latency-variable. In combination with something like UDP streaming, they could use a compression algorithm that is robust to bit-flips and single packet loss (say, just dropping some spatial or colour resolution for a few frames instead of a quarter-second glitch). The hosts could talk to each other directly rather than through a relay server.
All of these techniques are used, somewhere. The biggest problem is that they're not widely compatible with what's already out there. ISPs tend to ignore QoS requests. Your smartphone does not have a hardware encoder for video except for MPEG-4, probably. It's quite possible your router will silently drop malformed UDP packets. Everyone is still behind NAT. And so on. And when you fall back to a common baseline codec and protocol, using TCP via a relay server, it's just kind of miserable when a packet disappears.