Transfer destination: a US mobile number in E.164 format. Caller ID setting: show the Retell number (show_transferee_as_caller = false).
Failed call 1: call_5f8f5b43a18d67260076c1c7b2f. Agentic warm transfer. Result: “Transfer failed due to an error.”
Failed call 2: call_8ba6a305fe753d7cc2f385a93de. Plain warm transfer. Result: “Transfer call cannot be completed, the other side declined the transfer.”
Both failed about 4 seconds after the transfer started, and the destination phone never rang.
A direct outbound call from the same Retell number to the same mobile worked: it rang, and my transfer agent handled the call normally.
Questions:
What do your internal logs show as the reason for each failure?
Do new accounts or Retell-purchased numbers have any restriction on call transfers (verification step, spending limit, caller-ID or anti-spam block)? If so, how do I lift it?
Happy to share the destination number privately. Thanks!
For the first call, the agent you are transferring to should be a transfer agent. please see Call transfer node in conversation flow → Configure Agentic Warm Transfer Specific Settings for detailed setup.
for second call, I will loop in our telephony team to take a look.
For your question, we don’t put restriction on new account, there’s no block on your account at this moment.
Hi @mark1, thanks, that helps. Your screenshot shows exactly what I see too.
First failure (call_5f8f5b43a18d67260076c1c7b2f, agentic warm transfer): you’re right that our agent isn’t registered as a transfer agent. We created it through the API as a normal conversation-flow agent, so it shows up in the main agent list. When I open “Select transfer agent” on the transfer node, it lists none, and an agent created from that dialog does not appear in the main list. We’re rebuilding ours the same way and will retest.
Second failure (call_8ba6a305fe753d7cc2f385a93de, plain warm transfer): no transfer agent is involved. It failed about 4 seconds after the transfer started with “the other side declined the transfer,” and the destination phone never rang. A direct outbound call from the same number to the same phone works. Could the telephony team check what happened for that call? I can share the destination number privately if needed. Thank you!
Thanks for the clarification and for sharing the Call ID. I’ve noted the issue with the plain warm transfer and will have the relevant team review what happened during that transfer attempt.
Thanks @mark1. Quick update from our side. The first failure is solved: after adopting a registered transfer agent (is_transfer_agent true), agentic transfers dial and bridge correctly on real calls, for both the person-request and emergency paths.
For the 603: we can reproduce it with a direct outbound call from the same number to the same phone, and it’s declined instantly. But two other phones, one on the same carrier and one on a different line, accept calls from that number every time. So it looks specific to that one line, likely call blocking on the carrier side, and we’re checking with the carrier. You don’t need to spend more time with Twilio unless the trace shows something else.
One question: does the trace show whether the 603 came from the carrier’s network or from the device? Thanks again for the help.
Thanks for the detailed update — glad to hear the agentic transfer issue is resolved.
Regarding the 603, I’ll check whether the SIP trace provides enough information to determine if the decline originated from the carrier network or further downstream at the device/line level.
I’ll get back to you once I have more information.
