Fundamentals
Packet Loss Diagnosis Workflow
'Calls sound bad' becomes engineering the moment packet loss is quantified and localized. Loss has an address: it occurs on a specific link, in a specific direction, under specific load. This workflow takes you from a vague complaint to that address with two captures and arithmetic — the same workflow behind the jitter and robotic-voice guides, laid out end-to-end.
It assumes you can capture at two points (typically the phone's LAN segment and the WAN edge). If you can only capture one point, capture at the edge — it answers the most questions.
Step zero: quantify and aim
From any bad call's capture, record per direction: packets expected, packets lost (sequence gaps), loss %, and the loss shape — sprinkled singles or bursts (consecutive gaps). Burst loss during a call that coincides with a big transfer suggests queue overflow; steady sprinkled loss suggests a physical/link problem; loss at call start only suggests something else entirely (a route change settling). Also record who else is affected: one phone, one site, one provider — the scope decides which segment to bisect first. Then pick the failing direction and follow that stream; loss is directional, and workflows that average directions mislead.
| Loss pattern | Points at | Confirm with |
|---|---|---|
| Bursts aligned with bulk traffic | Congested queue (uplink saturation, bufferbloat) | Utilization graphs at loss timestamps; QoS check |
| Steady low-level loss, all hours | Physical layer: cabling, failing port/NIC, duplex mismatch | Interface error counters (CRC/alignment) on the path |
| Loss only on Wi-Fi endpoints | Airtime contention / roaming / weak signal | Wired test at the same desk; AP statistics |
| Clean at LAN edge, loss present at WAN edge (same call) | Your router's queueing or the ISP access link | Router queue drops counters; ISP ticket with both captures |
| Clean leaving your WAN, peer reports loss | Upstream/carrier path | Carrier ticket with timestamps and stream stats |
The bisection discipline
Two synchronized captures of the same call at two points turn 'somewhere' into 'between A and B': packets present at A but absent at B were lost in between, full stop. Repeat with the second point moved (across the router, across the switch, across the Wi-Fi boundary) and the segment shrinks until it names a device or a link. This is slower than guessing and faster than arguing — most loss hunts end at one of three mundane addresses: a saturating uplink queue, a Wi-Fi segment treated as wired-equivalent, or a physical interface quietly accumulating errors that nobody graphed. Interface counters deserve their sentence: a switch port with rising CRC errors is packet loss with a return address, and it is visible without any capture at all.
The workflow, condensed
- Quantify from a real bad call: per-direction loss % and shape, scope (who else), and time pattern.
- Inspect the free evidence first: interface error counters and utilization graphs along the path at the loss times.
- Capture the same call at LAN edge and WAN edge; compare stream sequence continuity to bisect the loss to a segment.
- Move the capture boundary once more to isolate the device/link inside the segment (switch uplink, router queue, AP, ISP handoff).
- Fix the identified mechanism (QoS/scheduling for queues; cable/port for physical errors; wiring or coverage for Wi-Fi; carrier ticket with both captures for upstream).
- Verify statistically: a week of stream statistics (provider MOS/loss reports or scheduled test calls) showing loss back under ~0.5% — not one good call.
Frequently asked questions
- Can packet loss occur with zero congestion?
- Yes: physical errors (bad cable, dying optic, duplex mismatch) drop packets on empty networks, and policers/firewalls drop by policy. The pattern table separates them — congestion is load-shaped; physical loss is not.
- What is a duplex mismatch and why does it still exist?
- One end of an Ethernet link runs full-duplex while the other runs half (a failed auto-negotiation against a hard-coded port). The half-duplex side sees collisions and drops frames, worst under load. It survives because it 'works' at low traffic — exactly the profile that hides until busy hours.
- How do I prove loss is the carrier's when they ask us to reboot things?
- Two-point evidence: the stream complete leaving your WAN with timestamps, and loss measured arriving at the far end (their own RTCP/stream stats or the peer's capture). Present both files and the Call-ID; evidence ends script loops.