Call transfer: fallback when destination is busy / no answer + past warm transfer misrouting

Support Help
1

Hi Retell team,

I build voice agents and I need guidance on call transfer behaviour. There are two related points.

  1. Keeping the call on Retell when the destination doesn’t pick up

What I want to achieve: when the agent attempts a transfer and the destination is busy or doesn’t answer, the call should NOT be dropped. The agent should regain control and be able to say something like “the operator isn’t available right now, please hold a moment” or “can I take your details and have them call you back?”, and then continue the conversation normally.

My questions:

  • Is this supported today? If so, what is the exact configuration (dashboard settings and/or API fields)?
  • Can I set a custom ring timeout before the fallback is triggered?
  • Does the agent automatically regain control when the transfer fails, or do I need to handle it explicitly in the Conversation Flow (e.g. a dedicated node, or a variable exposing the transfer result)?
  • Are the underlying SIP causes exposed so I can branch differently on busy (486), no answer (408/480) and voicemail/answering machine detection?
  • Does this behaviour differ between warm transfer and cold transfer? Is cold transfer necessarily final once initiated?
  • Is there any supported way to put the caller on hold and retry the operator after a few seconds?
  1. Past issue: warm transfer routed to the wrong number

Some time ago I tested warm transfer in production and the call was transferred to a phone number different from the one configured in the transfer_call function. This caused a serious issue with one of my clients and I ultimately lost that account. Since then I have only used cold transfer and never re-enabled warm transfer.

Before putting warm transfer back into production I would like to understand:

  • Was this a known bug at the time, and has it been fixed?
  • What can cause the actual destination to differ from the one set in transfer_call? For example: a dynamic variable not being resolved, number formatting / E.164 issues, an agent-level setting overriding the function-level one, or a fallback to a default number on the account.
  • What checks or best practices do you recommend to guarantee the call goes exactly to the number passed in the function?

I’m happy to share agent IDs and specific call IDs if that helps you investigate. It was months ago and I’d like to find a solution for the future.
call_2791b051c3fdab5248409d2f9f0
call_84b29c0d02da4d9b299392828a7

Thanks in advance for your help.

Best regards
Matteo

2

Hello @matteventu7

Part 1: Transfer Failure — Keeping the Call on Retell

1.Is this supported?

Yes, but only with Agentic Warm Transfer. You can use a dedicated transfer agent with a Cancel Transfer tool. If the destination is unavailable or busy, the transfer agent can cancel the transfer, and the caller is returned to the main agent.

For configuration, use Call Transfer → Agentic Warm Transfer, assign a Two-way Conversation Agent, and set Action on Timeout to Cancel Transfer. The transfer agent should call Cancel Transfer when the destination is unavailable.

2.Custom ring timeout

Yes. You can configure the Transfer Ring Duration to control how long the destination rings before the transfer is considered unanswered. This can be configured per transfer.

3.Does the agent regain control automatically?

With Agentic Warm Transfer, yes. When the transfer agent calls Cancel Transfer, the main agent automatically resumes the conversation. No additional node or variable is required.

For standard warm transfer, there isn’t a clearly defined fallback path back to the main agent, so Agentic Warm Transfer is the safer approach.

4.Are SIP cause codes available for branching?

Raw SIP cause codes such as 486, 408, or 480 aren’t available as in-flow variables for branching. Call-level metadata can include reasons such as dial_busy, dial_no_answer, and dial_failed, but these aren’t exposed as branching conditions within the conversation flow.

5.Is cold transfer final?

Yes. With Cold Transfer, the call is immediately transferred to the destination and the agent drops off. There is no built-in fallback to the main agent. If you need fallback behaviour, use Warm Transfer or Agentic Warm Transfer.

6.Can the agent put the caller on hold and retry?

There isn’t a built-in hold-and-retry mechanism. The closest approach is Agentic Warm Transfer, where the transfer agent can attempt the transfer and cancel it if the destination isn’t available. A retry loop would need to be implemented separately.

Part 2: Warm Transfer Routing to the Wrong Number.

I can’t confirm from the available information whether this was a known bug or whether a specific fix was released. For confirmation of bug history or a previous fix, the best option is to have the team review the relevant Call IDs.

Potential causes to check include:

Invalid or incorrectly resolved dynamic variables — make sure the destination number is valid and in E.164 format, such as +14155551234.

Caller ID configuration — if using the user’s number as the caller ID and the provider doesn’t support it, the transfer can fail. E.164 formatting settings — verify that the Format to E.164 setting matches the format of the number you’re providing.

For the most reliable setup, use an E.164-formatted destination, validate any dynamically generated number before the transfer, verify the formatting settings, and use Retell Agent’s Number as the displayed caller ID unless you specifically need to use the user’s number. Agentic Warm Transfer is also preferable when you need the transfer agent to confirm that the correct destination has answered before completing the bridge.

Please share your Agent id and latest relevant call ids so we can check it.

Best Regards.