# Two of my agents stopped getting user audio and keypad inputs **URL:** \ **Category:** Support Help\ **Tags:** bug\ **Created:** [June 9, 2026, 11:05am UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039 "2026-06-09T11:05:59Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 9, 2026, 11:05am UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/1 "2026-06-09T11:05:59Z")
| Description | No modification had been made and out of nowhere two of my agents stopped getting audio and keypad input. These are production agents handling hundreds of calls. Same agent normal call: call\_a64162a834518186f3ea5f1386f → An hour before it was working | | --- | --- | | Call ID | | ```auto call_abe3e67bbe045dad38689b0f585 ``` | Agent ID | | | --- | --- | ```auto agent_60ac19fb3fc0dcea8057b0034d ``` ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 9, 2026, 12:45pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/2 "2026-06-09T12:45:44Z")
@Shah-Fazal could you provide any inisghts on why this is happening? ---
**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:** [June 9, 2026, 1:15pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/3 "2026-06-09T13:15:00Z")
Hello @yasser.santiago Checking with the team. Thank You ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 9, 2026, 2:38pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/4 "2026-06-09T14:38:39Z")
@Shah-Fazal any updates 🙂 ? ---
**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:** [June 9, 2026, 4:12pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/5 "2026-06-09T16:12:27Z")
Hello @yasser.santiago happy to dig deeper, but here’s what we have so far. Comparing the two calls on `agent_60ac19fb3fc0dcea8057b0034d`: - **Working call** `call_a64162a834518186f3ea5f1386f` (06:27 UTC, +4915151263914 → +17862203563): 10+ user turns transcribed, DTMF captured, normal flow, 219s before caller hangup. - **Broken call** `call_abe3e67bbe045dad38689b0f585` (08:05 UTC, same caller, same DID, same agent): zero user turns transcribed, zero DTMF events, 69s before caller hangup. What this tells us: - The “no audio received” watchdog did not fire on the broken call, meaning RTP packets were arriving — they just carried no decodable speech or DTMF. - The agent configuration was unchanged between the two calls. - Other callers reaching this same agent in the same window were transcribed normally. That points to a transient issue on this caller’s specific leg (the German mobile path or handset) rather than something on our side, but to confirm definitively we’d need PCAP/media-side evidence. To move this forward, could you share: 1. The **agent ID of the second affected agent** — your original message mentioned two, but only `agent_60ac19fb3fc0dcea8057b0034d` was cited. 2. One or two **example call IDs from any recurrence** after the 08:05 UTC call so we can check whether the pattern is still active or limited to that window. If it’s reproducing, a fresh affected call ID would let us pull PCAP/media-side evidence for that leg. Thank You ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 9, 2026, 8:31pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/6 "2026-06-09T20:31:28Z")
These are the ids: agent\_14c4aec52f3bbdfda097855c4e agent\_60ac19fb3fc0dcea8057b0034d ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 9, 2026, 8:32pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/7 "2026-06-09T20:32:47Z")
normal call: call\_a64162a834518186f3ea5f1386f call with issue 1 hour after: call\_abe3e67bbe045dad38689b0f585 ---
**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:** [June 9, 2026, 9:24pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/8 "2026-06-09T21:24:39Z")
Hey @yasser.santiago thanks, but those are the same two calls we already analyzed in the previous reply `call_a64162a834518186f3ea5f1386f` working at 06:27 UTC and `call_abe3e67bbe045dad38689b0f585` broken at 08:05 UTC, both on `agent_60ac19fb3fc0dcea8057b0034d`). To recap what we found: - On the working call, 10+ user turns were transcribed and DTMF was captured cleanly. - On the broken call (same caller +4915151263914, same DID, same agent), RTP was arriving (the no-audio watchdog never fired) but carried no decodable speech or DTMF — the caller hung up after 69s. - Agent config was identical between the two calls, and other callers reaching this same agent in that window were transcribed normally. That keeps pointing at the caller-leg (German mobile path / handset) rather than something on our side. To go further we still need one of the two things from the previous message: 1. A **call ID from any recurrence** after 08:05 UTC — a fresh recurrence gives us a live target to pull PCAP / media-side evidence against. A one-off historical call won’t tell us whether it has self-cleared. If there has been no recurrence since 08:05 UTC and the second agent is fine now, that itself is evidence the issue was transient on that caller’s leg. ---
**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:** [June 10, 2026, 1:04pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/9 "2026-06-10T13:04:29Z")
Hello @yasser.santiago followed up on `agent_14c4aec52f3bbdfda097855c4e` and we see the same fingerprint as on the first agent, but the cross-call evidence points to caller-side abandonment on `+17864749711`, not a Retell-side regression. Specifics: - On the same agent, same hour, working calls (e.g. `call_aaed4d73a56abe0df0a087fb7fc`) captured DTMF (`#36055560`) and ASR turns cleanly — proving the keypad + audio pipeline is healthy end-to-end on this agent/trunk during the affected window. - The “broken” calls all share: short duration, `user_hangup`, zero user turns transcribed, zero DTMF events, null e2e latency, and inbound to `+17864749711` specifically. The Spanish DID `+34930482758` on the same agents is largely unaffected. - We compared your org’s null-audio rate against the rest of the platform during the same 07–12 UTC window on Jun 9: platform-wide ~22% baseline across 37k calls / 1.7k orgs, your org 82–95% concentrated on `+17864749711`. There’s no platform incident or trunk-level regression in that window. - Inbound volume on `+17864749711` ran ~17× normal during the 10:00 UTC hour (172 calls vs ~10/hr baseline), which amplifies the absolute count of “caller heard the prompt and gave up.” - Most broken calls carry `x-twilio-verstat: TN-Validation-Failed-A` — STIR/SHAKEN attestation is failing for international callers reaching this US DID, which typically produces “spam likely” warnings on the caller’s handset and is a plausible driver of the hesitation/abandonment we’re seeing. Two recommendations: 1. For Spanish/French callers, route them to a Spain-local DID (you already have `+34930482758` working cleanly on these agents) rather than the US `+17864749711` — that should both eliminate the attestation failure and improve answer-confidence. 2. If you want us to dig further into a specific affected caller, share one or two more call IDs that you yourself observed as broken (ideally where you know the caller did try to speak or press keys) and we’ll parse the PCAPs to rule out a codec-level edge case. ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 10, 2026, 9:14pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/10 "2026-06-10T21:14:44Z")
I test the agent: call\_baa89cbf2d2a82ee3f18a69edd0 The reason those calls were short, was beacasue the users could not talk or itnerect with the agent so they hang up @Shah-Fazal ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 10, 2026, 9:17pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/11 "2026-06-10T21:17:16Z")
More examples @Shah-Fazal call\_baa89cbf2d2a82ee3f18a69edd0 call\_2c97a6b9ad6d26e5188379f587d call\_a8857b57780d606360f5632866d call\_3307127d3a3c5258029c2febc0c different agent , different version ---
**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:** [June 10, 2026, 9:52pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/12 "2026-06-10T21:52:51Z")
Hey @yasser.santiago thanks for the self-test and the additional examples. After looking across 20+ recent inbound calls on these agents over the last 72 hours, the picture is consistent. What we see: - 0 of 20 sampled calls in the last 72h advanced past the `Greeting & Intent` node — they all stall waiting for keypad entry and the caller eventually hangs up (matching your self-test `call_baa89cbf2d2a82ee3f18a69edd0`). - Internal logs show \*\*no DTMF events arriving at Retell\*\* during the keypad-entry window on the failing calls. On the only known-working call this week on the same agent `call_a64162a834518186f3ea5f1386f`), we logged the full DTMF sequence `#3572590*`) and the flow completed end-to-end. - ASR / TTS / LLM / KB pipelines are healthy on the failing calls; SDP between Twilio and Retell correctly negotiates RFC 2833 telephone-event (PT=101) bidirectionally. The Twilio trunk config has been unchanged since 2026-01-26. - The delta we can see at the SIP layer: the \*\*failing calls carry a SIP `Diversion` header\*\* pointing at an upstream forwarding hop `sip:+498912080631@206.147.76.45`). The known-working reference call has no Diversion header — it arrived at Twilio directly. Portuguese and French callers on the same trunk and agent profile are also completing normally. The most likely mechanism — given the working-vs-broken contrast — is that the upstream carrier handling the forwarded leg isn’t relaying RFC 2833 telephone-event packets through to Twilio, so the digits the caller presses never reach us. We can’t fully confirm that from our side because Retell’s PCAP retention is SIP-only — proving the absence of telephone-event RTP frames needs a media-side capture (Twilio Voice Insights), which is the one remaining gap on this theory. Recommendations: - \*\*Flow-level mitigation:\*\* since the `Greeting & Intent` node currently relies on keypad-only entry, a forwarded-leg caller whose DTMF is stripped has no way to proceed. Adding a speech-fallback path on that node (let the caller speak the ID, agent confirms digits back) would remove the single point of failure on forwarded legs. - \*\*Identify the forwarding source:\*\* check whether anything changed in inbound routing on your European numbers / PBX / forwarding provider that introduced the hop at `206.147.76.45`. If your voice carrier added or changed a forwarding rule, ask them whether RFC 2833 is being passed through on the forwarded leg, or whether SIP INFO / in-band DTMF can be enabled as an alternative. - \*\*Optional packet-level confirmation:\*\* if it would help when you go back to the carrier, we can walk you through pulling a Twilio Voice Insights media-side capture for one of these CallSids (your self-test was `CA15eb83870328c8a5d6110b785cc698c3`) — that gives direct evidence that telephone-event RTP frames are absent on the inbound leg. Thank You ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 11, 2026, 9:50am UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/13 "2026-06-11T09:50:08Z")
I just created a new agent different conversation flow, assigned a new phone number and same issue. What is happening? call\_3307127d3a3c5258029c2febc0c ---
**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:** [June 11, 2026, 12:57pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/14 "2026-06-11T12:57:47Z")
Hey @yasser.santiago Checking with the team. ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 11, 2026, 3:14pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/15 "2026-06-11T15:14:57Z")
New agent - it got data: call\_1409b2f70ab12ff6d3727738ff5 but then no: call\_9ab570505d5f7b5824a091cfab1 ---
**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:** [June 11, 2026, 8:38pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/16 "2026-06-11T20:38:08Z")
Hi @yasser.santiago confirming what we’re seeing on today’s calls: - `call_1409b2f70ab12ff6d3727738ff5` (10:40 UTC, `+17862203563`) — audio captured, agent responded normally (~5.2s e2e latency), full flow ran. - `call_9ab570505d5f7b5824a091cfab1` (14:56 UTC, same DID) — no user audio decoded, agent never got to respond. Zooming out on `+17862203563` today: **1 out of 16** inbound calls captured audio. On your BYOC DID `+17865036901` in the same window, calls are running normally (audio + DTMF intact). Same agent, same conversation flow on both — so the issue isolates to the media-delivery path on the Retell-managed Twilio number, not the agent itself. Thank You ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 11, 2026, 9:54pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/17 "2026-06-11T21:54:58Z")
so what is the solution? ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 12, 2026, 9:43am UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/18 "2026-06-12T09:43:55Z")
### 2. The Spam “Penalty Box” Expired Your support ticket revealed that your numbers were recently hit by a burst of spam (the 156 self-loop calls). - When US carriers detect a sudden burst of highly suspicious traffic on a specific number, automated fraud systems will often put that number in a temporary “penalty box.” During this time, they might allow the SIP connection to establish but actively drop the audio packets to prevent toll fraud or harassment. - It is highly probable that this automated security cooldown period simply expired, restoring normal media streams to your numbers. ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 15, 2026, 12:55pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/19 "2026-06-15T12:55:26Z")
@Shah-Fazal so what is the issue/solution ? ---
**Author:** ![yasser.santiago](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/yasser.santiago/32/1308_2.png) [@yasser.santiago](https://community.retellai.com/u/yasser.santiago)\ **Post date:** [June 15, 2026, 1:05pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/20 "2026-06-15T13:05:25Z")
Hi team, Thank you for the detailed breakdown. Your explanation regarding the STIR/SHAKEN attestation (`verstat=Failed-A`) resulting in silent RTP makes complete sense and perfectly explains what we are experiencing. The reason legitimate calls are failing the attestation is due to our Aircall forwarding setup. We are forwarding calls from European Aircall numbers (ES/DE) to the US Retell DIDs. During the forward, Aircall passes the original customer’s European Caller ID. To the US carriers, this cross-border VoIP routing looks spoofed, which triggers the STIR/SHAKEN failure and strips the audio payload. I actually experienced this exact issue myself—my own legitimate test calls connected but had zero audio. We could technically force Aircall to override the Caller ID and pass the Aircall VoIP number instead, but **this is a last-resort scenario for us.** Our AI architecture relies on capturing the user’s original phone number to identify them in our CRM and Back Office. If we mask it, the AI loses all customer context. **My main question:** If we purchase local Spanish (ES) and German (DE) numbers directly within Retell, and forward our Aircall traffic to those local numbers instead of the US ones, will that bypass the cross-border STIR/SHAKEN failure and allow the audio to pass while preserving the customer’s original Caller ID? [Next page](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039.md?page=2)