We’ve also received a similar complaint from another client;
“We are having problems with our phone lines with incoming calls. Patients either can not here us or giving off a lot of static. We have reached out to the phone company and was told it is due to the AI.”
Unfortunately I do not have specific call ids or recordings for this client. Requested for them, will share if received.
Hello @hussain We reviewed call_7297a1d9cf52f0b2575548ae5e5. On Retell’s side, the caller audio that reached our ASR was only partially intelligible: the transcript captured just “I would like to…” and later “Yes,” after which the agent repeatedly asked if the caller was still there.
The agent/LLM/TTS path did continue responding, and we don’t see evidence that the agent prompt or voice generation caused the issue. This looks like the caller’s audio was already degraded by the time it reached Retell, or was being degraded somewhere on the telephony/media path before ASR.
To prevent / narrow this down, the best next step is to compare Retell’s multichannel recording with the upstream carrier/Twilio Voice Insights for the same Twilio CallSid: CA78cb24250b41ec018e13e7637bdfdbd9, around 2026-09-02 20:01:27 UTC. Specifically, please pull inbound-leg packet loss, jitter, MOS, and any RTP/media warnings from the carrier/Twilio side. That will tell us whether the caller audio was degraded before reaching Retell or whether there was a Retell media-ingress issue.
If this happens again, please send 2–3 additional call IDs plus the approximate timestamp in the recording where the caller sounded clear on your side but unclear in Retell. That will let us compare whether it is isolated to this call or tied to a specific route/carrier/path.
We pulled the Twilio-side data for CallSid CA78cb24250b41ec018e13e7637bdfdbd9. Voice Insights Advanced Features wasn’t enabled on our account, so we don’t have access to the full Metrics time-series or Events/warnings via the API for this call, but i did get these findings:
One warning logged: 32021 (STIR/SHAKEN Failed-C — ‘dest’ value in PASSporT claim doesn’t match SIP To header). This seems to be a caller-ID authentication mismatch, not a media/RTP issue, but flagging in case it’s relevant.
Let us know if there’s anything else you need from our side.
Hey @Shah-Fazal , we’d like to get to the bottom of this so that it doesn’t happen again or at least have a presentable reason as to why it occurred. If theres any clarity you can give us regarding it so we can close it out on our end, it’d be much appreciated.
Hello @hussain We took a closer look at call_7297a1d9cf52f0b2575548ae5e5 and here’s what we found.
What happened on Retell’s side
Across the 2m27s call, our ASR only captured two short fragments from the caller (“I would like to” at ~25s, and “Yes” at ~70s), which is why the agent kept asking “Are you still there?” The agent, LLM, and TTS themselves were healthy, the agent responded correctly whenever it did receive input, and there were no meaningful latency or generation issues on our side. The problem is that most of the caller’s speech never reached ASR intelligibly, even though it sounds clear on the client’s own recording.
We noticed that the agent is configured with aggressive background-voice cancellation. Agent agent_2096d26e416ba943b740fd8db8 (v43) has both noise and background speech reduction enabled. This mode is designed to suppress other human voices in the background (e.g. for open-office or web-call environments). When the incoming audio is already thin from multi-carrier transcoding, this mode can misclassify the primary speaker’s voice as background noise and suppress it, which matches the symptom exactly: clean at the source, near silent by the time ASR sees it.
What we recommend
Change the agent’s denoising mode from noise-and-background-speech-cancellation to noise-cancellation (or disable it entirely) for this agent. The aggressive tier is best suited to clean-microphone web calls, not forwarded PSTN traffic.
Simplify the routing path so callers reach Retell in one hop — either have them dial the Retell DID (+1‑202‑335‑9655) directly, or set the T‑Mobile number to immediate forwarding rather than no-answer forwarding. This also resolves the multi-ring delay in the other thread.
If this happens again after the denoising change, please send 2–3 additional call IDs plus the approximate timestamp in each recording where the caller’s audio starts breaking up, and we’ll dig further.