# The call sounded bad

Four different complaints arrive as 'the call sounded bad', and they have different causes: audio that is narrow because telephone audio is narrow, audio that breaks up because of the network, a voice that seems to cut people off, and a voice that sounds wrong rather than broken. Connect measures timing and turn-taking on the wire; it does not measure the network leg, and there is no recording on the live carrier to listen back to.

- **Status:** Available
- **Audience:** both
- **Channels:** phone
- **In the app:** #/calls, #/phone
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/call-audio-quality/

## Four complaints, one sentence

**Muffled or thin** — Telephone audio is band-limited. Connect's own speech on the carrier path is delivered as small narrowband audio on purpose, because that is what the phone network carries. It will not sound like a podcast, and that is not a defect.
**Breaking up, robotic, dropping words** — A network or device symptom on one leg of the call. This is the one worth chasing, and it is usually the caller's mobile signal or a browser participant's connection rather than the line.
**Talking over the caller, or stopping mid-sentence** — Turn-taking, not audio. The caller experiences it as noise, but nothing is wrong with the sound — see [the voice talked over the caller](/docs/troubleshooting/voice-cut-the-caller/).
**Sounds wrong, flat, or not like us** — Delivery. That is the voice, the style and the profile, which is what the Voice Lab is for, not a fault to be fixed on this page.

Getting the complaint into one of those four boxes is most of the work, because three of them are not audio problems at all and the fourth is almost never inside the software.

## What can be measured, and what cannot

Timing is measured on the wire. The worker times the caller's last word to the first audio back, and posts a timing event for each reply and a barge-in event carrying how long the voice kept talking after the caller spoke over it. That measurement replaced reading times off transcript rows, which produced eight-millisecond replies beside pauses the caller had waited seconds through — a transcript row arrives when a sentence is finished, not when it started.

The call review then reports deterministic findings: slow replies, long gaps, ignored interruptions, false stops, repetition, stock phrases, the wrong script, and a caller who was not heard. Each finding names the setting that addresses it, and the settings that actually ran are snapshotted on the call so the review judges the call that happened rather than the configuration as it stands today.

> **Note** Per-packet network quality — loss, jitter, the codec that was negotiated — belongs to the carrier's leg of the call and is not reported into Connect. If the complaint is genuinely about broken audio, the carrier's own call detail is the evidence, not the call review.

## Causes, likeliest first

| Cause | Who it affects | What to try |
|---|---|---|
| Mobile signal on the caller's side | One caller, intermittently | Nothing in Connect; ask for a redial or a call-back |
| A browser participant's connection or headset | Calls involving the softphone | A wired headset and a stable connection change more than any setting |
| Background noise on the caller's side | Noisy environments, and callers who are not heard | Noise cancellation is an engine setting in the Voice Lab |
| Narrowband audio mistaken for a fault | Everyone, consistently | Expected on the phone network; compare against another call on the same line |
| Turn-taking read as audio trouble | Fast talkers and short answers | Interruption thresholds and end-of-speech timing, both in the Voice Lab |

## What Connect completed

- The call was carried, transcribed and recorded as a call, with its outcome and who ended it.
- Reply timings and interruption events were measured on the wire for every turn and kept with the call.
- The review ran at the end and listed what it could determine deterministically, including a caller who was not heard.
- The settings that actually ran were snapshotted on the call, so a later change to the line does not rewrite what is being judged.

## What Connect did not complete

- No audio was kept. Call recording is a foundation capability and is not enabled on the live carrier, so there is nothing to listen back to — the transcript and the timings are the whole record.
- No network measurement was taken of either leg: loss, jitter and codec are the carrier's, not Connect's.
- Nothing was adjusted mid-call in response to the audio; noise cancellation and the timing thresholds are settings chosen before the call, not adaptations made during it.
- The model's remarks on delivery are reported as the model's opinion and are not treated as a measurement.

## What you can do

1. Ask the person complaining which of the four things happened, in their words.
   - Result: 'It cut me off' and 'it kept breaking up' point at completely different fixes, and the distinction rarely survives being written down as 'bad audio'.
2. Open the call and read the review findings before anything else.
   - Result: An unheard caller or an ignored interruption is a finding with a setting behind it. No findings on a call people disliked points at delivery or at the network.
3. Compare two calls on the same line from the same day.
   - Result: A problem present on both is the line or the settings; a problem on one is that call's network or that caller's device.
4. For browser calls, try a wired headset and a wired connection before changing anything in the product.
   - Result: The browser leg is the one part of the path a person can improve in a minute.

## What an administrator can do

- Turn on noise cancellation for lines whose callers ring from noisy places, and check whether unheard-caller findings fall afterwards.
- Read findings that a setting cannot change as exactly that: where the model's own first token accounts for most of a wait, the review says so and offers no control, and those findings are counted without lowering the score.
- Check the voice and style before blaming the audio path — a delivery complaint is answered in [the Voice Lab review](/docs/phone/voice-lab-review/), not by a codec.
- Keep expectations honest with callers and colleagues: the realtime floor is the model's first token plus its end-of-turn detection, measured at 3.3 s median on the best call, not one to two seconds.

## When to escalate

Escalate when broken audio appears on every call on a line rather than on one caller's, when unheard-caller findings rise sharply without a change to the line, or when the complaint is that the voice is inaudible rather than imperfect. A line-wide audio fault involves the carrier's leg, and the carrier's own call detail is where that investigation has to start.

## Questions

### Can I listen to the recording to judge it myself?

Not on the live carrier. Recording exists as a capability that is asked of the provider rather than assumed, and it is not enabled there, so no audio is kept. The transcript, the per-reply timings and the review findings are the evidence a call leaves behind.

### Does Connect report jitter or packet loss?

No. Those belong to the provider's leg of the call and are not reported into Connect, so a page that showed them would be showing an estimate. What is measured here is timing and turn-taking, taken on the wire rather than inferred from transcript rows.

### The voice sounds robotic. Is that the audio or the voice?

Usually the voice. Delivery is set by the voice, the style and the profile, and some qualities — exact pitch in hertz, loudness in decibels, precise pause lengths — cannot be set at all and are listed as unsupported rather than shown as sliders that do nothing.

## Related

- [Connect's own voice](https://connectbyjbrh.com/docs/phone/connect-voice-tts/)
- [Call quality review](https://connectbyjbrh.com/docs/phone/voice-lab-review/)
- [Reply latency on a call](https://connectbyjbrh.com/docs/phone/latency/)
- [Calling from the browser](https://connectbyjbrh.com/docs/phone/softphone/)
- [Measuring conversational latency correctly](https://connectbyjbrh.com/research/measuring-voice-latency/)
- [The voice talked over the caller](https://connectbyjbrh.com/docs/troubleshooting/voice-cut-the-caller/)

## What this page is based on

- `docs-source/sources/PHONE.md` §6 — the Voice Lab and wire-measured latency
- `docs-source/sources/PHONE.md` §11 and §12 — Connect's own voice, and what is not available
- Connect capability registry (docs-source/facts.py) — call_recording, barge_in, voice_lab