### Answer On the transition logic: for a call transfer node, "Transition happens when transfer fails. There's already a pre-populated edge for this. Feel free to connect that to a node to handle transfer failure" [(1) ]() . This confirms the failed edge is meant to fire on transfer failure and route to another node, which is the pattern you've set up. For your specific questions: 1. On ring duration/timeout: "Use this slider to set how long the destination should ring for this transfer. The value you set here applies only to this transfer. If you do not set it, we use your agent-level ring duration setting. This works for cold transfer, warm transfer, and agentic warm transfer" . So there is a configurable ring timeout that applies to cold transfers, and if the destination doesn't answer within it, that should count toward the transfer failing. 2. On human detection: this is documented specifically for warm transfer, not cold transfer. Under warm transfer settings: "Enable human detection: When enabled, the agent will check if a human is present after the transfer target answers. The original caller will only be connected once a human is detected... Agent detection timeout: The maximum amount of time the AI agent will wait to determine whether the transfer target is a human. The caller is connected only if human detection succeeds within this timeframe. Otherwise, the transfer is marked as failed" . This mechanism (and its explicit "transfer is marked as failed" behavior on timeout) is not documented as being available for cold transfer. 3. On debugging failed-but-triggered transfers generally: "Telephony issues: Call transfer is similar to placing an outbound call, and failures occur for similar reasons as outbound call failures. The SIP connection log is available in the call logs and is use

ful for diagnosing the failure reason" [(2) ]() . Checking the SIP connection log in your call logs for this specific call would show why the failed edge didn't trigger as expected. 4. I don't have documentation confirming or denying whether the warm transfer voicemail/no-answer issue described in that community thread also affects cold transfers — that's not covered in the sources available to me. For your core ask, no-answer causing a cold transfer to end the call instead of routing to the failed edge isn't behavior explicitly documented one way or the other in these sources. Given this is a specific bug-like behavior report, I'd check the SIP connection log for that call first to confirm the actual failure reason.

​ To learn more, see the sources I considered: [[1] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[2] Debug call transfer failure](https://docs.retellai.com/reliability/call-performance) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

@AI Evy Pulled the SIP capture for the failed call. The caller's leg shows INVITE → 180 → 200 OK → then a BYE originating from Retell's side, with no Reason header. So Retell is tearing down the caller leg rather than resuming the agent when the transfer doesn't complete. There's no second INVITE in the capture at all.

### Answer I don't have documentation that details the specific SIP signaling behavior (BYE handling, Reason headers, or INVITE sequencing) on Retell's side when a cold transfer's destination doesn't answer [(1) ]() . The sources confirm the general troubleshooting path — checking the SIP connection log for outbound-call-style failures — but don't document the internal logic for why a caller leg would be torn down with a BYE instead of resuming the agent flow. Given what you've found (BYE with no Reason header, no second INVITE, and the failed edge never firing) , this looks like exactly the kind of case the docs point you toward escalating rather than self-diagnosing further: "The SIP connection log is available in the call logs and is useful for diagnosing the failure reason" — you've already gone past that step. I'd recommend sharing this SIP capture directly with Retell support along with the call ID, since the observed behavior (BYE instead of routing to the failed edge) isn't something I can confirm as expected or as a bug from the sources available to me. I also can't confirm from the sources whether the warm transfer voicemail/no-answer issue referenced in that community thread applies to cold transfers — that's not documented here either.

​ To learn more, see the sources I considered: [[1] Debug call transfer failure](https://docs.retellai.com/reliability/call-performance) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.