The Threshold Is 30ms Jitter, 1% Loss: Detecting Call-Quality Degradation and Adaptive Fallback in the Callbot Loop

What MOS, jitter, and packet loss actually tell you

Twilio's Voice Insights documentation flags a high-jitter warning on SDK calls when jitter stays at or above 30 milliseconds for three out of five consecutive sample windows, and raises a separate high-RTT warning when round-trip time exceeds 400 milliseconds at the same frequency. Carrier and SIP trunking calls get looser bands: cumulative packet loss above 5% and average jitter above 5 milliseconds mark the edge of "good" quality there. A callbot loop should carry that split straight into code — WebRTC SDK calls and SIP trunk calls need different degradation thresholds, not one shared number.

NICE CXone's voice quality metrics guide buckets MOS at 4.3+ as excellent, 3–3.4 as fair, and below 3 as poor, with packet loss under 1% as excellent and above 5% as poor. The two vendors don't line up exactly, but both point to the same inflection zone: perceived quality breaks down somewhere around 1% packet loss and 30-millisecond jitter. If your loop only logs those numbers as alerts, quality stays degraded for the rest of the call.

Detection and branching are two different jobs

Most implementations stop at collecting metrics and leave the decision of what to change to a human reading logs afterward. Mid-call, that delay is itself the failure. The same way a dead-air detection gate treats silence as a signal that triggers a recovery branch, a quality loop needs an explicit state — call it `quality_degraded` — in its state machine, so a signal from the detection module immediately slows TTS pacing, shifts toward confirmation-style prompts, or hands off to DTMF-only input.

From degradation signal to recovery: an adaptive fallback roadmap

Planning starts by pinning the transition threshold in code before anything else. A reasonable first target: jitter at or above 30ms in three of five sample windows, or packet loss above 1%, should trigger degraded mode within 500 milliseconds. A second target: false-positive barge-in detection while in degraded mode shouldn't exceed the normal-mode rate by more than 5 percentage points. Without both numbers, the rollout decision collapses into "it feels slower."

Four failure patterns recur. Metrics get logged but never wired to a branch, so the system observes without acting. Transition thresholds are set too sensitively, and ordinary calls keep flapping into degraded mode. A single threshold gets applied across SDK and carrier paths, which over-flags SIP trunk calls that were never that strict to begin with. And degraded mode has no exit condition, so a call stays throttled for its entire remaining length.

Preventing flapping means giving transition and recovery different time windows. Transition needs three-of-five sample hysteresis; recovery should demand a longer stable stretch, such as 10 consecutive clean samples, so a brief spike doesn't flip the mode back and forth. Once in degraded mode, shorten TTS response length and lean on confirmation prompts, and when packet loss crosses the carrier threshold of 5%, pre-declare a branch that reconnects the call or force-downgrades to DTMF-only.

On the operational side, inject jitter and loss with a network emulator before shipping and verify both the transition and the recovery round-trip, not just one direction. Lock MOS, jitter, loss rate, and transition state as standard call-log fields, and apply the same PII masking rules to quality logs that already apply to call content. Keep transition and recovery events in their own stream, separate from alerting, so you can later trace which outbound paths concentrated the degradation.

For the ongoing loop, pull the outbound paths or carriers with the highest weekly rate of degraded transitions and decide whether that calls for swapping SIP trunks or adjusting Opus FEC settings. Tracking the average time from transition to recovery release over release is the one number that shows whether the roadmap itself is improving.

Quick reference

The 30ms-jitter, 1%-loss numbers matter less than whether they live in the state machine as branch conditions rather than sitting in a detection log. Add hysteresis — short windows to transition, longer stable stretches to recover — and keep SDK and carrier paths on separate thresholds, and a callbot loop can lower its own strategy the moment a call turns bad.

References

Call Quality Events — Twilio Voice Insights

Voice Quality Metrics — NICE CXone