### Answer Yes, Retell AI automatically provides

{{user_number}}

as a default system variable for phone calls [(1) ]() . This variable contains the caller's phone number . For phone calls specifically,

{{user_number}}

represents the user's phone number, which is the

from_number

for inbound calls and the

to_number

for outbound calls . You can reference it in prompts, tool configurations, and other supported fields using the

{{user_number}}

syntax . No configuration is required—it's available automatically [(1) ]() [(2) ]() . In JavaScript code (like in a Code node) , you would access it as

dv.user_number

instead of using the

{{...}}

template syntax [(3) ]() .

​ To learn more, see the sources I considered: [[1] Dynamic variables: personalize Retell agent calls](https://docs.retellai.com/build/dynamic-variables) [[2] Discord message from @pawsboss on 2025-04-22](https://discord.com/channels/1186424376300679209/1186462578310910112/1364231488224104500) [[3] Code node](https://docs.retellai.com/build/conversation-flow/code-node) ​

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

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

rsation-flow/call-transfer-node) - Retell Twilio numbers support showing user's number on both warm and cold transfer, but Retell Telnyx numbers only support it via cold transfer with SIP REFER 3. **Alternative Approach**: If the third party needs to know the original caller's number but caller ID override doesn't work, you could: - Use Custom SIP Headers to pass the user's number as metadata [(3) ]() [(4) ]() [(5) ]() - Extract and pass

{{user_number}}

to your API via a custom function before or during transfer - Use the Retell Agent's Number for the actual transfer, but include the original caller info in your API request The TwiML app approach you mentioned could work as a workaround to intercept and reformat the call before it reaches your third party platform.

​ To learn more, see the sources I considered: [[1] Warm transfer on inbound calls fails when trying to present user’s number as caller ID (Custom Twili](https://discord.com/channels/1186424376300679209/1435963983986425977) [[2] Warm transfer](https://discord.com/channels/1186424376300679209/1436106645632450671) [[3] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[4] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[5] Connect Retell voice agents to custom telephony](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 The behavior you're seeing—where transfers work with Retell's Number but fail with User's Number—is actually expected given how Twilio validates caller ID [(1) ]() [(2) ]() . ## Why This Happens When you set the caller ID to User's Number, Twilio performs caller ID validation on the outbound leg of the transfer. Twilio will reject the call if: 1. The number isn't verified in your Twilio account 2. You don't own or have permission to use that specific caller ID 3. Caller ID override isn't properly configured in your SIP trunk settings When you use Retell's Number, it works because that number is already associated with your Retell/Twilio integration and has the proper permissions . ## The Core Issue For warm transfers, Retell sets the

from

and

P-Asserted-Identity

headers to the user's number . For cold transfers using SIP REFER, it's up to the telephony provider to support caller ID override . If caller ID override isn't supported or properly configured, the transfer fails . ## What's Likely Happening Since your destination is a Twilio number that triggers an API, Twilio is enforcing caller ID validation rules. It's rejecting calls where the

from

number (the user's number) isn't authorized in your account. ## Solutions 1. Contact Twilio Support to enable caller ID override permissions for your SIP trunk specifically for transfers to any number 2. Use Custom SIP Headers instead—pass the user's number as metadata (like

X-Original-Caller

) that your API can read, while keeping the actual caller ID as Retell's Number [(1) ]() [(2) ]() [(3) ](

ocs.retellai.com/deploy/custom-telephony) 3. Configure your TwiML app to accept the Retell Number as caller ID, then extract the original user number from SIP headers or a webhook parameter The TwiML app approach you mentioned would definitely work as a workaround to intercept and reformat before hitting your third-party platform.

​ To learn more, see the sources I considered: [[1] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Connect Retell voice agents to custom telephony](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 The 32204 error you're getting confirms that Twilio is rejecting the transfer because the user's number isn't verified in your Twilio account [(1) ]() [(2) ]() . This is a Twilio validation issue, not a Retell limitation. ## What You Can Actually Achieve *Option 1: Use Retell-Twilio Numbers (Easiest) * If you purchase your Twilio numbers directly through Retell (Retell-Twilio numbers) , caller ID override works automatically for both warm and cold transfers . This is the most straightforward solution if you can migrate to Retell-managed numbers. *Option 2: Custom SIP Headers (Recommended Workaround) * Since showing the user's number as caller ID isn't working with your custom Twilio setup, pass it as metadata instead: 1. Add a custom SIP header in your transfer configuration with the user's number [(1) ]() [(2) ]() [(3) ]() 2. Set the displayed caller ID to "Retell Agent's Number" so the transfer completes 3. Your third-party platform reads the original caller number from the SIP header In the Call Transfer node, add a custom SIP header like: - Header name:

X-Original-Caller

(must start with

X-

) - Header value:

{{user_number}}

Your third-party platform's TwiML app or API can then extract this header to get the real caller's number [(3) ]() . Option 3: Contact Twilio to Enable Permissions Ask Twilio support to enable caller ID override specifically for your SIP trunk. This requires configuration on their end for custom telephony setups [(1) ](

m/build/single-multi-prompt/transfer-call) [(2) ]() [(4) ]() . ## Why This Is Happening Retell-Twilio numbers support showing the user's number on both warm and cold transfers, but Retell-Telnyx numbers only support it via cold transfer using SIP REFER [(1) ]() [(2) ]() . For custom Twilio SIP trunking (your setup) , you need explicit permissions from Twilio to override caller ID [(4) ]() . The custom SIP headers approach is your most reliable path forward without changing your telephony setup.

​ To learn more, see the sources I considered: [[1] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Set & parse custom SIP headers](https://docs.retellai.com/build/telephony/sip-headers) [[4] Warm transfer on inbound calls fails when trying to present user’s number as caller ID (Custom Twili](https://discord.com/channels/1186424376300679209/1435963983986425977) ​

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

### Answer Based on the sources, there are a few reasons why your custom SIP headers might not be appearing: ## Common Issues with Custom SIP Headers 1. Headers Only Work with SIP Endpoints Custom SIP headers are preserved only when transferring directly to a SIP endpoint. They may be stripped when transferring to a PSTN number [(1) ]() [(2) ]() . If your third-party platform is receiving calls via a regular phone number (E.164 format like +1234567890) instead of a SIP URI, the headers won't make it through. 2. Known Bug with Multi-Prompt Agents There was a reported bug where custom SIP headers weren't saving properly in Multi-Prompt agents [(3) ]() . Users reported that after adding custom SIP headers to the transfer function, the headers would disappear when reopening the function configuration. This was fixed, but if you're experiencing similar behavior, try: - Re-adding the headers after the fix - Publishing a new version of your agent - Verifying the headers are still there after saving 3. Header Naming Requirements All header names must start with

X-

or be

User-To-User

(case insensitive) [(1) ]() [(4) ]() [(2) ]() . If your headers don't follow this format, they won't be sent. ## What to Check 1. **Transfer destination format**: Are you transferring to a SIP URI (like

sip:user@domain.com

) or a PSTN number? Headers only reliably work with SIP URIs [(1) ]() . 2. **Header configuration**: In your Call Transfer functio

n, verify: - Headers are properly saved (check for the bug mentioned above) - Header names start with

X-

- The configuration persists after publishing 3. **Cold transfer method**: If using cold transfer, check whether you're using SIP INVITE or SIP REFER. For cold transfers with SIP REFER, different telephony providers may or may not honor custom SIP headers [(4) ]() . If you're transferring to a regular phone number instead of a SIP URI, that's likely why the headers aren't coming through—they get stripped during PSTN conversion.

​ To learn more, see the sources I considered: [[1] Set & parse custom SIP headers](https://docs.retellai.com/build/telephony/sip-headers) [[2] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[3] Call_transfer - Custom SIP headers not saving on Multi_Prompt Agent](https://discord.com/channels/1186424376300679209/1430166790079516762) [[4] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) ​

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