Transfer Call tool consistently failing — 100% failure rate today, single-prompt agent

Support Help
1

Agent ID: agent_6483c4c27e6513fec980c96e93
LLM ID: llm_3d2df0283a962057f666ea1d413f (version 55)
Phone number: +351289060017

Since 19/08/2026, our transfer_call tool has been failing on every single
attempt — not intermittently, every attempt across the whole day. The
agent always reaches the same fallback line (“Não foi possível
transferir neste momento” — “Could not transfer at this moment”),
never a successful handoff, regardless of caller.

Tool configuration (from GET /get-retell-llm):
“transfer_destination”: { “type”: “predefined”, “number”: “+351965262803” },
“custom_sip_headers”: { “X-Telnyx-Username”: “activaretellOut” },
“transfer_option”: {
“type”: “warm_transfer”,
“opt_out_human_detection”: true,
“agent_detection_timeout_ms”: 21000,
“on_hold_music”: “uplifting_beats”,
“show_transferee_as_caller”: false
}

Example failed calls (call_id / timestamp):
call_1d5cb9e779c7839880db780d961 — 2026-08-19 16:12 UTC
call_a59db8655258222284ca88950b6 — 2026-08-19 14:05 UTC
call_56bb2d44a16bffd668f0f817a95 — 2026-08-19 10:49 UTC (2 attempts, same call)
call_e9713400107c0dfe68417d3fba5 — 2026-08-19 09:41 UTC

We’ve confirmed the destination number (+351965262803) is correctly
formatted (E.164) and reachable via normal calls. Given the failure is
100% consistent regardless of caller or time of day, our working
hypothesis is that it’s related to the custom SIP header
(“X-Telnyx-Username”: “activaretellOut”) — either that SIP
trunk/credential on our Telnyx side isn’t accepting the transfer, or
something changed on your end in how that header is handled for
transfers.

Could you check server-side logs for these call attempts and tell us
specifically why the transfer is failing (destination unreachable, SIP
negotiation error, timeout, etc.)? We’d like to know whether this is
something to fix on our Telnyx trunk configuration or something on
Retell’s side.

We use Telnyx as our Custom Telephony provider (SIP trunk, not self-hosted infrastructure). Do we need to configure anything on our end for the RTP/audio allowlist mentioned in your Aug 24 deadline email, or does Telnyx handle this automatically as a hosted provider?

2

Hello @pauloajsopa Thanks for sharing the Call IDs. I’ll check them with the team and get back to you as soon as I have an update.

Thank You

3

Check your Telnyx SIP trunk logs directly — they’ll show the actual rejection reason (auth failure, route misconfiguration, etc). The 100% failure rate points to a trunk/credential issue rather than Retell. Verify the activaretellOut username still has valid creds and that your trunk routing rules accept outbound transfers. If those check out, grab the SIP failure codes from Telnyx and share them with Retell support — they can’t see why Telnyx rejected the INVITE, only that it failed.

4

Hello @pauloajsopa Team checked and the call did not transfer because the user did not answer. The call rang for about 30 seconds without pickup, and this is unrelated to the X-Telnyx-Username header.

Thank You