Agent not able to hear caller

Support Help
1

Hi retell support,

We received a call recording from a client that shows that the callers voice was understandable.

However, the agents replies seemed like it was unable to hear them clearly.

Retell’s call history’s recording also shows that the callers voice was unclear and could not be understood.

Here’s a link to their recording of the call: https://drive.google.com/file/d/1nz_Q6psCaXSFE7b7QEuCWM8nSovOM97m/view?usp=drive_link

And here’s a link to the recording from retells call history page: https://drive.google.com/file/d/1cqlphm_yaRdNe56q-rnjBTBvAtNPAMKP/view?usp=sharing

Here is the call_id as well: call_7297a1d9cf52f0b2575548ae5e5

How can we prevent this from happening?

Thanks

2

Hello @hussain I’m checking your Call ID with the team and will get back to you as soon as I have an update.

Thank You

3

Alright, appreciate the response @Shah-Fazal

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.

4

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.

Thank You

5

Hi @Shah-Fazal

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:

Carrier Edge (inbound, Verizon Wireless → Twilio):

  • Packet Loss Detected: false
  • Jitter Detected: false
  • Twilio RTP Latency to PSTN: <10ms

SIP Edge (Twilio → LiveKit/Retell):

  • Packet Loss Detected: false
  • Jitter Detected: false
  • Twilio RTP Latency to PBX: <10ms

Other details:

  • Post-Dial Delay: 0.07s
  • Who Hung Up: caller
  • Call State: completed, duration 2:28
  • 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.

6

@hussain Checking with the team.

Thank You

7

Hey guys, anything new come up on this?

8

Hey @hussain I’ve pinged the team again, but I haven’t received a response yet. I’ll let you know as soon as I have an update.

Thank You