# Call quality measurement Network call quality is about the audio path — delay, jitter, loss, and the listening scores derived from them. Conversational call quality is about the exchange: how long the caller waited, whether an interruption was honoured, whether the voice repeated itself. Connect measures the second, on the wire, at the end of every realtime call, and names the setting behind each finding. - **Status:** Available - **Audience:** both - **Channels:** phone - **In the app:** #/calls - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/technology/call-quality/ ## Two measurements wearing the same name **Network quality** — One-way delay, jitter, packet loss and the listening-quality scores estimated from them. It answers *did the audio arrive intact*, and it is the carrier's and the network's domain. **Conversational quality** — Response time, turn-taking, interruption handling, repetition, register, whether the caller was understood. It answers *was this a good conversation*, and no packet metric touches it. A call can score perfectly on the first and be unusable on the second: flawless audio of a voice that takes six seconds to answer and then talks over the caller. The reverse also happens, and confusing them wastes effort — tuning a model will not fix a lossy trunk, and a better codec will not fix a slow first token. ## What can actually be measured on the wire The measurement has to come from the audio stream's own state changes, not from the text that describes the call afterwards. Transcript rows are written when a sentence *completes*, so timing taken from them reports a fraction of the true wait — the first call reviewed here showed **8 ms** beside replies the caller had waited seconds for. - **Reply latency.** From the caller's last word — the moment their speaking state ends — to the first audio back. One `turn_timing` event per reply. - **Barge-in behaviour.** How long the voice kept talking after the caller spoke over it. Past two seconds, the interruption was effectively ignored. - **Gaps and silences.** Stretches with nothing from either side, which are a different fault from a slow reply. - **End-of-turn events.** Where the host path is in use, the detector's own decisions are recorded rather than inferred. Two thresholds turn those numbers into findings: a target reply of 2.5 seconds and a slow reply of 4 seconds. They are worth stating because the achievable floor on a speech-to-speech path is not the 1–2 seconds often quoted — it is the model's first token plus its end-of-turn detection, and the best call measured here had a **3.3 s median reply**. ## Does Connect use call-quality measurement? **Used, on the realtime engine, automatically at the end of every call.** The review produces deterministic findings — slow replies, long gaps, ignored interruptions, false stops, repetition, stock phrases, a reply in the wrong script, a caller who was not heard — and each finding names the setting that addresses it rather than describing the problem and stopping. The model's own opinion of the delivery is included and is **marked as the model's**, kept separate from the measured findings. The voice settings that were actually resolved for the call are snapshotted onto the call's quality record, so a review a week later judges what ran rather than what is configured now. Network-level metrics are not part of this. Connect does not compute a listening-quality score, and the parameters a speech stack cannot control — frequencies in hertz, levels in decibels, jitter — are listed as unsupported instead of being shown as something you can tune. ## When the model is the limit, no control helps A review that always offers a fix is a review that invents fixes. Where the model's own first token accounts for **60% or more** of the wait, the finding says so and deliberately offers no control to turn, because none of the available controls would change it. Those model-limited findings are listed and counted, and they do not lower the score — the score reflects what the operator could have done differently. The older number that counted everything is kept alongside it, so nothing is hidden by the change; there are simply two numbers with two meanings. > **Note** This is also why two behaviours were removed rather than left in the prompt: a respect-word cadence rule and murmur handling both measured as unchanged. A control that cannot move the measurement is worse than no control, because somebody will spend a week turning it. ## What no measurement will tell you Whether the answer was *right*. Whether the tone suited a distressed caller. Whether a question that was technically answered left the person no better off. Whether the business would have wanted that commitment made. Those are judgements, and the review is deliberately built to hand them to a person with the evidence attached rather than to score them. The practical division of labour: the deterministic findings tell you which calls to listen to and which setting to change, and a person decides what the conversation should have been. A related integrity check sits below both — a promised time that shares no time word with anything the caller said is refused outright, so a call cannot end with a booking nobody agreed to. ## Questions ### What counts as a good response time on an AI call? Under 2.5 seconds is the target used here and over 4 seconds is treated as slow. Judge a deployment on its median rather than its best turn: the floor on a speech-to-speech path is set by the model's first token plus end-of-turn detection, and 3.3 s is the best median measured on this stack. ### Why is a finding listed but not counted against the score? Because it is model-limited. If the model's own first token is most of the wait, no setting available to you would change it, and scoring it would make the number measure the model rather than the configuration. The all-inclusive figure is still kept beside it. ### Does this tell me if the line was crackly? No. That is network quality — delay, jitter and loss on the audio path — and it belongs to the carrier and the connection. The review measures the conversation, not the circuit. ## Related - [Call quality review](https://connectbyjbrh.com/docs/phone/voice-lab-review/) - [Reply latency on a call](https://connectbyjbrh.com/docs/phone/latency/) - [Voice latency](https://connectbyjbrh.com/docs/technology/voice-latency/) - [Barge-in](https://connectbyjbrh.com/docs/technology/barge-in/) - [Measuring conversational latency correctly](https://connectbyjbrh.com/research/measuring-voice-latency/) - [Call transcripts](https://connectbyjbrh.com/docs/technology/call-transcript/) - [What a setting cannot change](https://connectbyjbrh.com/docs/phone/model-limits/) ## What this page is based on - `docs-source/sources/PHONE.md` §6 — the Voice Lab and voice_quality.review - `docs-source/sources/PHONE.md` §12 — the realtime latency floor - Measured voice numbers (docs-source/facts.py `MEASURED`)