# Two of my agents stopped getting user audio and keypad inputs

**URL:** <https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039>\
**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:** 1\
**Page:** 2

<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:** [June 15, 2026, 5:57pm UTC](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039/21 "2026-06-15T17:57:03Z")

</div>

Hello @yasser.santiago glad the picture clicked. Two things to flag before you act on the ES/DE plan:

\*\*1) On the diagnosis framing.\*\* STIR/SHAKEN attestation is a real factor on cross-border forwarded calls and likely contributes to caller-side hesitation, but it isn’t the full story for the silent-RTP pattern we saw today. Your BYOC DID `+17865036901` is also a US number receiving the same cross-border Aircall forwards (same `Failed-A` attestation pattern would apply), yet it captured audio on 14 of 16 calls today while `+17862203563` captured audio on 1 of 16. The variable that flipped the outcome was the trunk / Retell-managed Twilio subaccount carrying that DID, not the attestation status. So any fix that simply moves you to a different trunk has a strong chance of working even if attestation behavior is unchanged.

\*\*2) On the procurement question.\*\* Retell’s directly-purchasable DID inventory in the dashboard is currently US/CA only — there isn’t a flow to buy Spanish or German numbers natively in Retell. To get EU-local DIDs attached to your agents, the supported path is BYOC (bring-your-own-carrier) SIP-trunk import:

- Obtain the ES / DE local DIDs from a carrier that sells in those countries (your existing Aircall account may be one option if they expose SIP trunking on those DIDs; otherwise any in-country SIP carrier).
- Import the DIDs via custom telephony into Retell (same mechanism you’re already using for `+17865036901`): [Custom Telephony Overview - Retell AI](https://docs.retellai.com/deploy/custom-telephony)
- Forward Aircall traffic into the imported DIDs (or, if Aircall provides the DIDs themselves via SIP, skip the forwarding step entirely).

For your two priorities:

- Bypass the affected Retell-managed Twilio subaccount: yes — anything routed via BYOC sidesteps it, which is exactly the pattern your healthy `+17865036901` already demonstrates.
- Preserve original caller ID: BYOC forwarded calls preserve the original E.164 in the SIP `From` / `P-Asserted-Identity` / `Contact` headers — we confirmed this in your PCAPs earlier in the thread. No need to mask the customer’s number to make BYOC work.
- Avoid cross-border attestation friction: keeping the call in-region (EU caller → EU local DID) plausibly removes the cross-border STIR/SHAKEN failure mode, but the exact outcome depends on the EU carrier’s signaling. Worth validating with one test DID before migrating volume.

Two things to confirm carrier-side before you commit:

1. Whether Aircall (or your chosen EU carrier) sells SIP trunks on ES / DE numbers, not just PSTN forwarding — SIP-native is required for BYOC import into Retell.
2. The local carrier’s documentation requirements for issuing ES / DE DIDs (proof of address, in-country presence) vary by country and are managed at the carrier, not at Retell.

Thank You

[Previous page](https://community.retellai.com/t/two-of-my-agents-stopped-getting-user-audio-and-keypad-inputs/3039.md?page=1)