Two of my agents stopped getting user audio and keypad inputs

Support Help
1
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 
call_abe3e67bbe045dad38689b0f585
Agent ID 
agent_60ac19fb3fc0dcea8057b0034d
2

@Shah-Fazal could you provide any inisghts on why this is happening?

3

Hello @yasser.santiago Checking with the team. Thank You

4

@Shah-Fazal any updates :slightly_smiling_face: ?

5

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

6

These are the ids: agent_14c4aec52f3bbdfda097855c4e agent_60ac19fb3fc0dcea8057b0034d

7

normal call: call_a64162a834518186f3ea5f1386f
call with issue 1 hour after: call_abe3e67bbe045dad38689b0f585

8

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.

9

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.

    Thank You

10

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

11

More examples @Shah-Fazal
call_baa89cbf2d2a82ee3f18a69edd0
call_2c97a6b9ad6d26e5188379f587d
call_a8857b57780d606360f5632866d
call_3307127d3a3c5258029c2febc0c

different agent , different version

12

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

13

I just created a new agent different conversation flow, assigned a new phone number and same issue. What is happening?

call_3307127d3a3c5258029c2febc0c

14

Hey @yasser.santiago Checking with the team.

15

New agent

  • it got data: call_1409b2f70ab12ff6d3727738ff5
    but then no: call_9ab570505d5f7b5824a091cfab1
16

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

17

so what is the solution?

18

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.

19

@Shah-Fazal so what is the issue/solution ?

20

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?