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

@shaw could you provide any inisghts on why this is happening?

3

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

4

@shaw 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.