Packet loss is the fraction of media packets that leave the sender but never reach the receiver. Media travels as a stream of small packets, and along the way some are dropped — by Wi-Fi interference, a congested link that discards overflow, an overloaded router, or a flaky cellular handoff. Loss is normal on real networks; the question is only how much, and how the call copes.
Real-time clinical calls cannot simply ask for everything to be resent the way a file download does, because waiting for a full retransmission would blow the latency budget and stall the conversation. Instead they use a layered toolkit within tight time limits: concealment algorithms paper over small audio gaps so the ear barely notices, the receiver requests a fresh keyframe when video corrupts, forward error correction (FEC) sends a little redundant data so some losses can be reconstructed without any round trip, and selective retransmission (NACK) re-requests only the most important missing packets when there is just enough time.
These tricks have limits. Sustained loss above a few percent is where consultations degrade visibly — audio starts to garble, video freezes or pixelates — and at that point graceful degradation is a product decision, not an accident. Your product should define its fallback ladder explicitly: reduce resolution, drop frame rate, and ultimately fall back to audio-only, in that order, before the experience becomes unusable. The common mistake is leaving that behavior undefined, so under real-world loss the call degrades in whatever ad-hoc way the stack happens to choose, and a clinician loses the patient mid-sentence with no graceful step down.
