https://retellai.com/?utm_source=discord&utm_medium=seo logo
Powered by
"My number +1571xxx can make outbound calls manual...
# ❓・ai-evy-support
d
@AI Evy "My number +1571xxx can make outbound calls manually from the dashboard, but when my AI agent triggers a transfer_call tool (both cold and warm), it fails within 600ms. The outbound leg never connects. Agent ID is in the logs. Manual outbound works fine — only AI-initiated transfers are broken."
a
Thanks for tagging me @DecomAlpha. I'll look through relevant sources and get back to you shortly.
d
ok
a
### Answer Based on the transfer failure pattern you're describing (600ms failure with both cold and warm transfers when AI-initiated, but manual outbound works) , here are the most common causes: Transfer Number Format Verify your transfer number is in e.164 format (e.g., +15551234567) or a SIP URI format like 
sip:username@domain
[(1) ]() [(2) ]() . If your transfer destination is not in e.164 format, you can choose to keep the input as is by selecting raw format when using custom telephony . Telephony Provider Permissions For warm transfers specifically, your telephony provider needs additional permissions beyond basic outbound calling [(3) ]() . Warm transfer uses SIP DIAL behavior and may require different permissions than cold transfer [(1) ]() [(2) ]() . Caller ID Configuration Check your "Displayed Caller ID" setting in the transfer configuration . You can configure whether the transfer destination sees: - **Retell Agent's number**: The transfer destination will see the Retell agent's number - **User's Number**: The transfer destination will see the number of the user (requires telephony provider support for caller ID override) For warm transfer using SIP DIAL, Retell sets 
from
and 
P-Asserted-Identity
headers to the user's number . If caller ID override is not supported by your provider, the transfer would fail . Provider-Specific Requirements If you're using custom telephony (not Retell-Twilio numbers) , you may need to contact your provider about warm transfer support [(3) ](
nels/1186424376300679209/1436106645632450671) . Retell Twilio numbers support showing user's number on both warm and cold transfer, while Retell Telnyx numbers only support this when using SIP REFER via cold transfer [(1) ]() [(2) ]() . Recommended Next Steps 1. Verify your transfer number format matches e.164 or SIP URI requirements 2. Check your caller ID display setting - try "Retell agent number" if currently using "User's Number" 3. If using custom telephony, confirm with your provider that they support the transfer method you're attempting 4. Review your SIP trunking settings if applicable
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
d
I tried all that and it's failing. I can't review my sip trunking settings
@AI Evy That doesn't seem to work
a
Thanks for the follow-up, @DecomAlpha. I'll get back to you soon.
### Answer Based on your symptoms (600ms failure on AI-initiated transfers but manual outbound works) , this matches a known pattern with SIP trunking configurations [(1) ]() . Critical SIP Trunking Configuration Issue For cold transfers specifically, your SIP trunking provider must be configured to allow SIP REFER and PSTN transfer [(2) ]() . The cold transfer mode uses SIP REFER by default, which asks an endpoint to start a separate call to a third party for transfer handoff . Try This Configuration Change In your Call Transfer Node settings, switch the cold transfer mode from 
SIP REFER
to 
SIP INVITE
. SIP INVITE establishes or updates the active call path, then bridges the transfer, and has different provider requirements than SIP REFER . If Using Elastic SIP Trunking Check your termination settings in your SIP trunking provider and verify you've provided the correct termination URL to Retell [(3) ]() . Also verify your origination settings if inbound calls are affected . Known Issue Pattern Other users have reported this exact issue with Twilio SIP trunking where some numbers transfer successfully while others fail with the same configuration [(1) ]() . One user reported the error: 
SIP REFER did not go through
, which indicates the SIP trunk is not configured correctly to allow SIP REFER . Next Steps 1. Switch cold transfer mode to 
SIP INVITE
in your transfer node settings [(2) ]() 2. If that doesn't work, contact your telephony provider to enable SIP REFER and PSTN transfer with the transferee's number
showing as caller ID 3. Share your call ID with Retell support for detailed SIP logs
​ To learn more, see the sources I considered: [[1] Failure in call transfers with SIP Trunking](https://discord.com/channels/1186424376300679209/1328524251497631856) [[2] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] 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.
PreviousNext
Powered by