Hi we had a lot of transfer failures today. Please have a look at the errors and let us know what went wrong
{“status”:“Transfer call cannot be completed, the other side did not pick up.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly.”}
2026-06-22 12:46:38.620 call_e7a7a677d17dfd2a25861d4a35b error: Error transferring call via SIP REFER, SIP status code: undefined SIP error category: user_no_answer Error: twirp error unknown: request timed out To troubleshoot, check out: Debug outbound connection issues - Retell AI (Debug outbound connection issues - Retell AI)
Hello @phonavar we dug into call_e7a7a677d17dfd2a25861d4a35b and here’s what we see:
The agent invoked transfer_call three times to +17576908091 on that call. Each attempt ended after roughly 15 seconds with the same “the other side did not pick up” / user_no_answer result.
No SIP 4xx/5xx came back from the carrier — that error string is what we surface when the ring window on the REFER expires before the destination answers.
Org-wide today you had 280 successful transfers on this DID, so the BYOC Twilio trunk and inbound path are healthy. This is scoped to attempts going to +17576908091 specifically.
One thing to flag on the mechanism: the “speak to human” node is configured as cold_transfer + sip_refer. In SIP REFER mode the ring window is governed by the carrier handling the REFER (Twilio in your BYOC setup), not by Retell’s transferRingDurationMs setting on the node.
What we’d suggest:
First, confirm whether +17576908091 was actually staffed/reachable around the times of these calls. The simplest explanation that fits the evidence is that the operator line isn’t picking up within the REFER ring window.
If you want Retell to control the ring window, switch the “speak to human” transfer node off sip_refer to the standard cold_transfer mode. In that mode Retell originates the outbound leg itself and transferRingDurationMs on the node is honored end-to-end.
Separately, the flow is re-firing transfer_call up to 3× on a single call after a successful:false result. Each retry is a fresh ring on the operator’s phone and won’t change the outcome if the line just isn’t answering. We’d recommend updating the prompt/flow so the agent informs the caller and offers to take a message after the first failed transfer rather than auto-retrying.
One note: we’re unable to pull the Twilio SIP trace for the three REFER attempts on that Call SID. On your sub account, you can confirm whether the timeout is Twilio’s REFER NOTIFY ceiling vs the downstream PSTN simply ringing out. That would tell us whether toggling off sip_refer or chasing the operator-line answering behavior is the load-bearing fix.
Thanks for the detailed breakdown. A few points from our side:
On the “operator not answering” theory:
We cross-checked successful vs failed transfers on the same day to the same number +17576908091. A successful transfer at 13:10 UTC connected immediately (child call duration 164 seconds — someone answered).
The failed transfers on the same day to the same number produced no child call in Twilio at all — meaning Twilio never created an outbound leg. If the operator line simply wasn’t answering, we’d still
expect to see a child call in Twilio with status no-answer. The absence of a child call points to the REFER not being processed by Twilio rather than the destination not picking up.
On the SIP trace:
We downloaded the PCAP from the Twilio console for the parent CallSID — the file was empty (24 bytes, header only, zero packets). We have now raised a ticket with Twilio asking them to pull SIP traces for
the failed REFER attempts and explain why no child call was created. We will share their findings here.
On switching off sip_refer:
We’d prefer to understand the root cause before changing the transfer mode, since 280 successful transfers happened on the same day using the current sip_refer setup. We don’t want to change the mechanism if
the issue is isolated to specific calls.