### Answer --- I don't see a specific error message in your question—could you share the exact error or SIP status code you're receiving? That said, the behavior you're describing (transfers failing for landlines and Google Voice but working for mobile) points to telephony provider-level differences in how those call types handle transfer protocols. [(1) ]() Common causes for inconsistent transfer failures: - **Telephony issues**: Call transfer works similarly to placing an outbound call, and failures occur for similar reasons as outbound call failures. The SIP connection log in your call logs is useful for diagnosing the failure reason. - **SIP REFER support**: Cold transfers rely on SIP REFER protocol, and it's up to the telephony provider to support this properly. [(2) ]() Landlines and VoIP services like Google Voice may handle SIP REFER differently than mobile carriers. - **Human detection issues**: If human detection is enabled, the call may fail if a human is not successfully detected. Possible reasons include the other party speaking after the detection timeout expired, or speech being too similar to an IVR/voicemail. [(1) ]() Recommended steps: 1. Check the SIP connection log for the failing calls to see the specific SIP error code and disconnection reason. 2. Verify your telephony provider's SIP trunk configuration, especially for transfer/REFER handling. [(2) ]() 3. If using custom telephony, check with your provider about how they route transfers to landlines vs. mobile numbers. If you can share the specific error message or SIP status code from your call logs, I can help narrow down the cause further.

​ To learn more, see the sources I considered: [[1] Debug call transfer failure](https://docs.retellai.com/reliability/call-performance) [[2] 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.

@AI Evy here is a screenshot https://cdn.discordapp.com/attachments/1475632420039561363/1475633097776169023/Screenshot_2026-02-23_at_3.18.21_PM.png?ex=699e31ea&is=699ce06a&hm=3662d128619d43d8755213076c58b90c96a05a30cd84bfed7a7cacae123b2d61&

### Answer --- I'm not able to view images or screenshots directly. Could you please copy and paste the error message text, or describe what the error says? Once you share the specific error message or SIP status code, I can help identify the cause. Based on your earlier description of transfers failing for landlines and Google Voice but working for mobile, common issues include: - **SIP REFER handling differences**: Cold transfers use SIP REFER protocol, and telephony providers handle this differently—landlines and VoIP services like Google Voice may not fully support SIP REFER the same way mobile carriers do. [(1) ]() - **Telephony provider configuration**: Check your termination and origination settings in your SIP trunking provider, and review the logs there for more details. - **SIP 500 errors**: If you're seeing a SIP 500 status code with "telephony_provider_unavailable," this indicates an issue on the telephony provider's side rather than Retell configuration. [(2) ]() Please share the error text and I can provide more specific guidance.

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) [[2] 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.

### Answer The error message "Transfer call cannot be completed, probably don't have the permission to perform the transfer" indicates a telephony provider permission issue, specifically related to how your SIP trunk or telephony provider handles call transfers. [(1) ]() Why this happens for landlines/Google Voice but not mobile: This is a telephony provider-level issue. Cold transfers rely on SIP REFER protocol, and it's up to the telephony provider to support caller ID override and proper routing. Landlines and VoIP services (like Google Voice) often have stricter requirements or different handling of SIP REFER compared to mobile carriers. Common causes: 1. **Caller ID verification requirements**: If you're using "user's number" as the displayed caller ID for warm transfers, the transfer may fail if that caller ID isn't verified with your telephony provider. [(2) ]() One user reported that transfers work when using "AI agent caller ID" but fail with "user's number" unless the caller ID is verified in Twilio. 2. **SIP trunk configuration**: Your telephony provider may not allow SIP REFER or PSTN transfer with certain caller IDs. [(1) ]() Recommended solutions: - Try changing the caller ID setting to "AI agent's number" instead of "user's number" to see if transfers succeed consistently. [(2) ]() - If you need to display the user's number, you may need to work with your telephony provider (Twilio, Telnyx, etc.) to adjust restrictions on caller ID for transfers. - Check your SIP trunk termination settings and ensure SIP REFER and PSTN transfer are properly configured. [

(1) ]()

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) [[2] Discord message from @kurddo on 2026-02-15](https://discord.com/channels/1186424376300679209/1186462578310910112/1472717004992548884) ​

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

### Answer In this context, "telephony provider" refers to Twilio (or whichever SIP trunking service you're using, such as Telnyx or Vonage) —not the end carrier (like AT&T, Verizon, etc.) that ultimately delivers the call to the landline or mobile phone. [(1) ]() When you set up elastic SIP trunking with Retell AI, you configure your telephony provider (Twilio, Telnyx, Vonage, etc.) with termination and origination settings. [(1) ]() [(2) ]() The telephony provider is responsible for: - Handling SIP REFER for cold transfers [(1) ]() - Managing caller ID permissions and routing [(2) ]() - Processing outbound calls to PSTN (the public phone network) [(1) ]() So when the error says "probably don't have the permission to perform the transfer," the issue is with your SIP trunking provider's configuration (e.g., Twilio) , not the downstream carrier. What to check in Twilio (if that's your provider) : - Verify your termination settings allow SIP REFER and PSTN transfer - Check that the caller ID you're using is verified in Twilio [(2) ]() - Review Twilio's logs for more specific error details [(1) ]() The reason transfers may work for mobile but fail for landlines/Google Voice is that these destination types may have stricter requirements on your telephony provider's side, or different routing rules that affect how the transfer is processed. [(1) ]() [(3) ]()

​ To learn more, see the sources I considered: [[1] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) [[2] Twilio](https://docs.retellai.com/deploy/twilio) [[3] Agent transfers the calls to itself](https://community.retellai.com/t/agent-transfers-the-calls-to-itself/699) ​

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

### Answer I don't have specific documentation confirming a recent change where Retell now preserves the original caller ID in the outbound INVITE. However, the changelog does document a Warm Transfer Caller ID feature released in November 2025 that allows you to control which caller ID appears when transferring calls (warm and cold) —showing either your AI agent's number or the original caller's number. [(1) ]() The Call Transfer Node documentation confirms you can configure caller ID for transfers: [(2) ]() - **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 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. The documentation notes that Retell Twilio numbers support showing the user's number on both warm and cold transfer, while Retell Telnyx numbers only support this when using SIP REFER via cold transfer. If caller ID override is not supported by your provider, the transfer would fail. This could explain the behavior you're seeing—if Retell is now passing the original caller ID and your telephony provider doesn't support caller ID override for certain call types (landlines/Google Voice) , the transfer fails with a permission error. Check out these potentially useful sources: [Call Transfer Node]() , [Platform Changelogs]()

​ To learn more, see the sources I considered: [[1] Platform Changelogs | Retell AI](https://www.retellai.com/changelog) [[2] Call Transfer Node](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.

### Answer --- For call transfers, Retell provides caller ID configuration options in the Call Transfer Node: [(1) ]() - **Retell Agent's number**: The transfer destination sees the Retell agent's number - **User's Number**: The transfer destination sees the original caller's number For warm transfers, Retell sets the

from

and

P-Asserted-Identity

headers to the user's number. For cold transfers using SIP REFER, caller ID override support depends on your telephony provider. For standard outbound calls (not transfers) , the documentation shows you can pass

custom_sip_headers

in the Create Phone Call API: [(2) ]()

javascript
custom_sip_headers: { // replace with custom sip headers you want to send (optional)
  X-Custom-Header: 'Custom Value'
}

However, I don't see explicit settings in the available documentation for: - "Use destination number as caller ID" - "Use trunk default caller ID" - A dedicated "outbound caller ID" override field for regular outbound calls The

from_number

parameter in outbound calls specifies your Retell-managed or imported number, which serves as the caller ID for the outbound leg. For imported numbers via custom telephony, the termination URI and authentication are configured, but caller ID behavior beyond that depends on your SIP trunk provider's settings. [(3) ]() If you need more granular control over outbound caller ID beyond what's documented, you may need to handle this at your telephony provider level or reach out for additional guidance.

​ To learn more, see the sources I considered: [[1] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[2] Outbound Calls (Make Calls)](https://docs.retellai.com/deploy/outbound-call) [[3] Import Phone Number](https://docs.retellai.com/api-references/import-phone-number) ​

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

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

​ To learn more, see the sources I considered: [[1] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[2] Twilio](https://docs.retellai.com/deploy/twilio) [[3] Help on Twilio DID questions](https://community.retellai.com/t/help-on-twilio-did-questions/24) ​

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

### Answer --- Could you share the updated configuration and the new error message you're seeing? The specific error will help identify what's still blocking the transfer. [(1) ]() Troubleshooting steps: 1. Check the call detailed log for the new SIP error code and disconnection reason—this should show whether it's still a caller ID issue or something else. [(2) ]() 2. **Verify transfer type**: Are you using cold transfer or warm transfer? Cold transfers use SIP REFER, while warm transfers use SIP DIAL. If cold transfer isn't working, try switching to warm transfer, which has better support for caller ID handling. [(3) ]() , [(4) ]() 3. **Check Twilio logs directly**: Since Retell won't know if your configuration works until a call is made, you'll need to check the logs in your telephony provider (Twilio) and potentially open a ticket with them. [(5) ]() 4. **Confirm the transfer destination format**: Ensure the number is in E.164 format (e.g.,

+15551234567

) or a valid SIP URI. [(3) ]() , [(4) ]() 5. **Try warm transfer with human detection disabled**: One user reported that warm transfers work better when caller ID override is needed. [(6) ]() Please share the new error message or SIP status code from the call logs so I can provide more specific guidance.

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

### Answer --- Yes, the phone number format appears incorrect. The transfer number should be in E.164 format without spaces. [(1) ]() , [(2) ]() Your current format:

+1 415 757 1440

(contains spaces) Correct E.164 format:

+14157571440

(no spaces) The documentation specifies that the transfer number should be "a number in e.164 format" or a SIP URI in the format of

sip:username@domain

. [(1) ]() , [(2) ]() Remove the spaces from your transfer number and it should be formatted as

+14157571440

.

​ 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) ​

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

### Answer No, the phone number format with spaces would not directly cause the *caller ID error (Twilio Error 32204) *. Those are two separate issues. [(1) ]() , [(2) ]() The caller ID error occurs because Twilio requires caller IDs to be verified before they can be used as outbound caller ID. When you configure "User's Number" as the displayed caller ID and the original caller's number (from landlines or Google Voice) isn't verified in your Twilio account, Twilio rejects it. [(1) ]() , [(2) ]() The phone number format issue (spaces in

+1 415 757 1440

) would likely cause a different problem—the transfer destination might not be recognized or routed correctly. The E.164 format requires no spaces:

+14157571440

. [(1) ]() , [(2) ]() You likely have two issues to fix: 1. **Caller ID configuration**: Change the caller ID setting from "User's Number" to "Retell Agent's number" to avoid the 32204 error [(1) ]() , [(2) ]() 2. **Transfer number format**: Remove spaces from the destination number so it's in proper E.164 format [(1) ]() , [(2) ]() Both should be corrected, but the caller ID error you're seeing is specifically related to the caller ID configuration, not the destination number forma

t.

​ 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) ​

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