### Answer This error indicates a call transfer failure where the transfer destination did not answer within the timeout period. [(1) ]() Breakdown: - SIP status code: undefined — No specific SIP error code was returned - SIP error category: user_no_answer — The destination number did not pick up the transfer [(2) ]() - request timed out — The transfer attempt exceeded the allowed time waiting for an answer Common causes: 1. The transfer destination number is not answering or is unavailable [(1) ]() 2. The destination may have a long ring time that exceeds the timeout threshold [(2) ]() 3. Potential telephony provider issues on the receiving end [(3) ]() Troubleshooting steps: 1. Verify the destination number is active and can receive calls [(1) ]() 2. Test calling the destination number manually to confirm it answers [(2) ]() 3. Check with your telephony provider for any issues on their side [(1) ]() 4. Review the call detailed logs in your dashboard for additional context If you're using custom telephony, double-check your SIP trunk configuration and ensure the termination URI is correctly formatted.

​ To learn more, see the sources I considered: [[1] Debug outbound connection issues](https://docs.retellai.com/reliability/debug-outbound-call) [[2] Call transfer failures](https://community.retellai.com/t/call-transfer-failures/600) [[3] Not being able to transfer a call](https://community.retellai.com/t/not-being-able-to-transfer-a-call/225) ​

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

Thanks for the follow-up, @Paco. I'll get back to you soon.

​ To learn more, see the sources I considered: [[1] Custom Sip Trunk - extension transfers on warm transfer](https://community.retellai.com/t/custom-sip-trunk-extension-transfers-on-warm-transfer/425) [[2] I am having issues with a Warm Transfer](https://community.retellai.com/t/i-am-having-issues-with-a-warm-transfer/757) [[3] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) ​

### Answer If the call is transferring successfully and the remote extension answers, but you're still seeing the

user_no_answer

error, this is likely a warm transfer human detection issue. [(1) ]() When using warm transfer, the agent checks if a human is present after the transfer target answers. The original caller is only connected once a human is detected. If human detection fails within the configured timeout, the transfer is marked as failed—even if someone actually answered. Likely causes: - Human detection timeout expiring — The agent detection timeout may be too short, causing the system to mark the transfer as failed before detecting a human response. [(1) ]() [(2) ]() - No verbal response from the extension — The person answering may not be speaking quickly enough for the AI to detect a human. [(1) ]() Recommended fixes: 1. Increase the Agent detection timeout — The default is 30 seconds; try increasing this value. 2. Enable Auto-greet — When enabled, the agent will immediately say "Hello" when the transfer target picks up, encouraging a response and increasing the likelihood of detecting a human. 3. Verify human detection is appropriate for your use case — If the extension is an IVR or automated system, you may need to configure the "Navigate IVR" option or consider using cold transfer instead. If you're using custom SIP trunking, also check your telephony provider's logs to confirm the SIP signaling is completing correctly. [(3) ](

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

​ To learn more, see the sources I considered: [[1] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) ​

### Answer The Enable human detection option is found in the Call Transfer Node settings when you configure a warm transfer. [(1) ]() To access it: 1. Open your Conversation Flow agent 2. Add or select a Call Transfer Node 3. Set the transfer type to Warm transfer 4. You'll see the warm transfer specific settings including: - On-hold music - Navigate IVR - 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. - Auto-greet - Agent detection timeout — The maximum time the AI agent will wait to determine whether the transfer target is a human (default is 30 seconds) . - Whisper message (optional) - Three-way message (optional) These settings only appear after you select Warm transfer as your transfer type in Step 2 of the Call Transfer Node configuration.

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

### Answer Since you're using cold transfer and the call is successfully transferring with the remote extension answering, but you're still seeing the

user_no_answer

error with

request timed out

, this points to a telephony/SIP signaling issue rather than human detection (which only applies to warm transfers) . [(1) ]() [(2) ]() For cold transfers: - Cold transfer uses SIP REFER to transfer the call - The agent simply transfers the call to the destination and that's it—no human detection is involved Possible causes for your error: 1. Caller ID configuration issue — If you're using "User's Number" as the caller ID, the telephony provider must support caller ID override for SIP REFER. If it's not supported, the transfer can fail. 2. SIP REFER acknowledgment timing — The SIP REFER request may be timing out before the telephony provider confirms the transfer completed, even though the call actually connects. [(3) ]() Recommended troubleshooting: 1. Try switching the Caller ID setting to "Retell Agent's number" instead of "User's Number" to see if that resolves the error. [(1) ]() [(2) ]() [(3) ]() 2. Check your SIP connection logs in the call detailed logs for more context on the SIP signaling. [(4) ]() 3. If using Retell-purchased numbers via Twilio, note that Retell Twilio numbers support showing user's number on both warm and cold transfer, but if caller ID override isn't working

properly, it can cause failures. [(1) ]() [(2) ]()

​ To learn more, see the sources I considered: [[1] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[2] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[3] Call transfer failures](https://community.retellai.com/t/call-transfer-failures/600) [[4] 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.

### Answer Since cold transfers work sometimes but fail with

user_no_answer

other times, this points to intermittent SIP REFER acknowledgment timing issues on the telephony provider side. [(1) ]() What's happening: Cold transfers use SIP REFER, and the success/failure depends on how quickly the receiving telephony infrastructure acknowledges the transfer. [(2) ]() [(3) ]() Even though the call actually connects and the extension answers, if the SIP REFER acknowledgment times out before confirmation is received, Retell logs it as a failure. [(4) ]() Likely causes for intermittent failures: - Variable response times from the destination — Different network conditions, carrier routing, or the receiving PBX/system may respond faster or slower on different calls [(1) ]() - Caller ID override inconsistencies — If using "User's Number" as caller ID, some transfers may succeed while others fail depending on how the provider handles the SIP REFER with caller ID override [(2) ]() [(3) ]() Recommended actions: 1. Check the SIP connection logs in your call detailed logs for the failing calls vs. successful ones to compare the SIP signaling behavior [(1) ]() 2. Try switching Caller ID to "Retell Agent's number" — This eliminates the caller ID override requirement and may improve consistency [(2) ](

fer-node) [(3) ]() [(4) ]() 3. Consider switching to warm transfer — Warm transfers use SIP DIAL instead of SIP REFER, which has more reliable signaling and better caller ID override support 4. Contact your telephony provider to check their logs for the failing transfers—the issue may be on their SIP infrastructure side [(1) ]()

​ To learn more, see the sources I considered: [[1] Debug call transfer failure](https://docs.retellai.com/reliability/call-performance) [[2] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[4] Call transfer failures](https://community.retellai.com/t/call-transfer-failures/600) ​

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

Thanks for the follow-up, @Paco. I'll get back to you soon.

### Answer This SIP log confirms the issue. You're receiving a 408 Request Timeout on a NOTIFY message (CSeq: 6209 NOTIFY) from Retell's SIP server (

18.98.16.123

) . [(1) ]() What this means: During a SIP REFER cold transfer, your system sends NOTIFY messages to inform Retell about the transfer progress. The 408 timeout indicates that Retell's server didn't receive or acknowledge the NOTIFY in time—even though the actual call transfer completed successfully on your end. The root cause: This is a SIP signaling timing issue between your Asterisk/Kamailio system and Retell's SIP infrastructure. The call itself transfers fine, but the SIP REFER notification handshake times out, causing Retell to log it as

user_no_answer

. [(2) ]() Why it's intermittent: Network latency variations between your system (

188.34.182.252

) and Retell's SIP server can cause some NOTIFY messages to arrive within the timeout window while others don't. [(1) ]() Recommended actions: 1. Check your telephony provider's logs for patterns in the failing transfers 2. Review your SIP trunk configuration — ensure termination and origination URIs are correctly configured 3. Consider using TCP transport if not already (which you appear to be using based on the log) 4. Open a ticket with your telephony provider to investigate the NOTIFY timeout behavior Since the transfers actually complete successfully, this is primarily a logging/signaling issue rather than a functional failure.

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) [[2] Call transfer failures](https://community.retellai.com/t/call-transfer-failures/600) ​

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

Thanks for the follow-up, @Paco. I'll get back to you soon.

### Answer This SIP log shows the complete SIP REFER notification sequence working correctly on your Asterisk side: 1. First NOTIFY (CSeq: 25160) — Your system sends

SIP/2.0 100 Trying

in the body, indicating the transfer is in progress 2. Second NOTIFY (CSeq: 25161) — Your system sends

SIP/2.0 200 OK

in the body with

Subscription-State: terminated;reason=noresource

, indicating the transfer completed successfully The good news: Your Asterisk/FreePBX system is correctly sending the REFER subscription notifications to Retell's SIP server (

18.98.16.123

) . The

200 OK

in the final NOTIFY body confirms the transfer succeeded from your side. [(1) ]() The issue: The

user_no_answer

error you're seeing in Retell's logs suggests that Retell's SIP infrastructure may not be receiving or processing these NOTIFY messages before its internal timeout expires—even though your system is sending them correctly. Recommended next steps: 1. Check if Retell is responding to your NOTIFY messages — Look in your Asterisk logs for

200 OK

responses from Retell (

18.98.16.123

) acknowledging your NOTIFY requests 2. Consider switching to warm transfer — Warm transfers use SIP DIAL instead of SIP REFER, which has more reliable signaling [(2) ]() [(3) ]() 3. Contact Retell support — Since your SIP signaling appears correct but Retell is still logging failures, this may require investigation on Retell's side Since the transfers actually complete successfully, this appears to be a signaling acknowledgment timing issue rather than a functional problem. [(4) ]()

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) [[2] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[4] 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.

Thanks for the follow-up, @Paco. I'll get back to you soon.

### Answer This log confirms that Retell's SIP server (

18.98.16.123

) is responding with

200 success

to your NOTIFY message (CSeq: 25160) . [(1) ]() Summary of the complete SIP REFER sequence: 1. Your Asterisk sends NOTIFY with

100 Trying

→ Retell responds

200 success

✓ 2. Your Asterisk sends NOTIFY with

200 OK

and

Subscription-State: terminated

→ (need to check if Retell also acknowledged this one) Since Retell is acknowledging the first NOTIFY but you're still intermittently seeing

user_no_answer

errors, the issue likely occurs in one of these scenarios: - The second NOTIFY (with the final

200 OK

status) may not be getting acknowledged before Retell's internal timeout - There may be a race condition where Retell's transfer timeout fires before processing the final NOTIFY What to check: 1. Look for a

200 success

response from Retell for CSeq: 25161 (the second NOTIFY with

200 OK

in the body) 2. Compare the timing between successful and failing transfers Since your SIP signaling appears correct and Retell is acknowledging messages, but you're still seeing intermittent failures, this may require investigation on Retell's side. I don't have documentation that explains the internal timeout behavior for SIP REFER acknowledgments. Check out these potentially useful sources: [Custom Telephony Overview]() , [Call Transfer Node]() , [Transfer call]() Would you like me to try to answer generally based on common SIP/VoIP practices?

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) ​

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

### Answer Great find! Adding a 2-second delay (

wait(2)

) before the dial in your Asterisk transfer dialplan gives Retell's SIP server enough time to properly process the SIP REFER handshake before the actual transfer completes. [(1) ]() This is a useful workaround for the timing issue where the NOTIFY acknowledgment sequence was racing against Retell's internal timeout. Thanks for sharing the solution—this could help others using custom telephony with Asterisk who encounter similar intermittent

user_no_answer

errors on cold transfers.

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) ​

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

### Answer Yes, based on the community forums, other users have reported similar SIP REFER cold transfer timing issues. [(1) ]() In one case, a user experienced consistent

user_no_answer

and 603 errors with cold transfers using SIP REFER, where the error indicated

request timed out

even though the destination was reachable. The issue was traced to SIP signaling timing between the custom telephony setup and Retell's SIP server. [(2) ]() Your solution of adding a

wait(2)

delay before the dial in Asterisk is a practical workaround that allows the SIP REFER handshake to complete properly before the transfer executes. This addresses the race condition where Retell's internal timeout fires before the NOTIFY acknowledgment sequence completes. If others encounter this same intermittent

user_no_answer

error on cold transfers with custom SIP trunking (especially Asterisk/FreePBX) , your workaround could be helpful for them to try.

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

​ To learn more, see the sources I considered: [[1] Call transfer failures](https://community.retellai.com/t/call-transfer-failures/600) [[2] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) ​

### Answer I don't have official Retell AI documentation that specifically recommends adding a delay before dial in Asterisk for SIP REFER cold transfers. [(1) ]() However, based on your experience, the

wait(2)

workaround you discovered resolved the intermittent

user_no_answer

timing issue by allowing the SIP REFER handshake to complete properly before the transfer executes. Since it solved your problem and the official documentation notes that Retell "will not be able to know if the setup you provide works or not until a call is made," testing and adjusting your dialplan timing is a valid troubleshooting approach. If you're experiencing similar intermittent SIP REFER timeout errors with custom telephony, adding a short delay before dial could be worth trying—but this is specific to your Asterisk configuration rather than an official Retell recommendation. Check out these potentially useful sources: [Custom Telephony Overview]() , [Call Transfer Node]()

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) ​

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