Hi ,I'm facing an issue with SIP URI rewriting during call transfers Setup & Call Flow Here's how our infrastructure is connected: 1. A call lands on our client's PBX on a specific extension. 2. The client's PBX forwards the call to our hosted PBX via a SIP trunk. 3. Our PBX routes the call to Vapi (via a SIP URI configured as a trunk in our PBX). 4. The Vapi AI agent picks up and handles the conversation. The Problem – Transfer Leg When the AI agent needs to transfer the call back (e.g., to a human agent or specific department on the client's PBX), the transfer fails. The call gets a 200 OK response from the control URL, but then disconnects. When I check the logs on my PBX, I can see the INVITE arriving — but the SIP URI in the request is different from what I sent. Vapi appears to be rewriting the SIP URI when it creates the new outbound leg. I need the SIP URI to arrive at my PBX exactly as I send it (e.g., sip:0051@3.222.3.222), because my PBX uses the extension in the URI to route the call to the correct destination on the client's PBX. I've Tried both blind and warm transfer plans My Questions 1. Is there a way to ensure the SIP URI I specify is preserved exactly as-is when Vapi sends the INVITE to my PBX? 2. Is there any other recommended approach for transferring SIP-originated calls back to the originating PBX with a specific extension? Any guidance would be greatly appreciated. Happy to share PBX logs or additional details if needed. Thank you

Suggestion: To troubleshoot SIP URI rewriting during transfers, verify that your SIP endpoint configuration in Vapi matches the exact URI format you require. For SIP transfers, Vapi sends a REFER packet, but the actual INVITE and URI handling are managed by your SIP provider. Ensure your SIP endpoint and transfer destination are configured precisely, and use packet capture tools (like Wireshark) to confirm the REFER and INVITE packets contain the expected SIP URI. Example troubleshooting step:

bash
# Check the REFER packet for the correct SIP URI
sip.Method == "REFER"

If the REFER contains the correct URI but the INVITE is rewritten, the issue is likely with your SIP provider's handling, not Vapi's. For more details, see the [Debug call forwarding drops documentation](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops). Source: - [Debug call forwarding drops documentation](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops)

This looks like Vapi normalizing the Request-URI on the outbound leg, which breaks your PBX routing since it relies on the user part (extension). Instead of relying on the URI alone, you might get more consistent behavior by passing the target extension via headers (e.g., X- headers) or ensuring it’s mapped in the To/Request-URI your PBX actually reads. Also worth checking if Vapi is enforcing a trunk domain override or SIP auth profile causing the rewrite. Have you confirmed whether your PBX routes strictly on the Request-URI user part, or can it fall back to headers like Diversion or X-Original-Called? @Arham

hey arham, could you please provide a call id where this occurs? we will review the logs and get back to you. additionally, if you are trying to use SIP URI as the destination for warm-transfers on VAPI, we currently only support SIP URI destinations for blind-transfers.