# Agent not able to hear caller

**URL:** <https://community.retellai.com/t/agent-not-able-to-hear-caller/3588>\
**Category:** Support Help\
**Tags:** telephony\
**Created:** [September 2, 2026, 7:42pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588 "2026-09-02T19:42:03Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![hussain](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/hussain/32/140_2.png) [@hussain](https://community.retellai.com/u/hussain)\
**Post date:** [September 2, 2026, 7:42pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/1 "2026-09-02T19:42:03Z")

</div>

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](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](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

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [September 2, 2026, 8:05pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/2 "2026-09-02T20:05:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hussain](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/hussain/32/140_2.png) [@hussain](https://community.retellai.com/u/hussain)\
**Post date:** [September 2, 2026, 8:29pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/3 "2026-09-02T20:29:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [September 2, 2026, 8:54pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/4 "2026-09-02T20:54:42Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hussain](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/hussain/32/140_2.png) [@hussain](https://community.retellai.com/u/hussain)\
**Post date:** [September 3, 2026, 8:39pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/5 "2026-09-03T20:39:10Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [September 3, 2026, 8:44pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/6 "2026-09-03T20:44:26Z")

</div>

@hussain Checking with the team.

Thank You

---

<div class="post-metadata">

**Author:** ![hussain](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/hussain/32/140_2.png) [@hussain](https://community.retellai.com/u/hussain)\
**Post date:** [September 4, 2026, 9:54pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/7 "2026-09-04T21:54:37Z")

</div>

Hey guys, anything new come up on this?

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [September 5, 2026, 1:01pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/8 "2026-09-05T13:01:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hussain](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/hussain/32/140_2.png) [@hussain](https://community.retellai.com/u/hussain)\
**Post date:** [September 7, 2026, 2:39pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/9 "2026-09-07T14:39:19Z")

</div>

Ok @Shah-Fazal , appreciate it.

---

<div class="post-metadata">

**Author:** ![hussain](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/hussain/32/140_2.png) [@hussain](https://community.retellai.com/u/hussain)\
**Post date:** [September 8, 2026, 2:16pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/10 "2026-09-08T14:16:11Z")

</div>

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.

Thanks again

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [September 9, 2026, 12:12pm UTC](https://community.retellai.com/t/agent-not-able-to-hear-caller/3588/11 "2026-09-09T12:12:39Z")

</div>

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.

Thank You
