I've read a thread about this but it didn't work for me. For context, call transfers show as successful in Vapi (endedReason: "assistant-forwarded-call"), but the destination phone never rings and the original caller gets dropped. And Twilio logs show a 403 Forbidden error on the transfer attempt. Call Details: Call ID: 019c1a10-5b65-7cc2-8966-7276e77a99f9 Timestamp: February 1, 2026 at 4:36 PM UTC (2026-02-01T16:36:45.732Z) Duration: 16 seconds Ended Reason: assistant-forwarded-call Transfer Tool Response: "Transfer initiated." I've followed these two documentation guides step-by-step: 1. Debug forwarding drops: https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops 2. Twilio SIP trunk setup: https://docs.vapi.ai/advanced/sip/twilio In my Twilio config: - Elastic SIP Trunk created with Trunk SID: TK41f70ba3ae492561a3bea6177ac27cd8 - SIP REFER enabled in trunk features - PSTN Transfer allowed - Termination URI: simplementary-vapi.pstn.twilio.com - Origination URI: sip:[my-number]@sip.vapi.ai (priority 10, weight 10, enabled) (I did not include the number for privacy reasons) - Geographic permissions enabled for all relevant countries - IP Access Control Lists configured with Vapi IPs: 44.229.228.186/32 and 44.238.177.138/32 I need to get call transfers working so the destination phone rings and the caller stays connected.

Hi there, Thank you for your message. Our team is currently out of the office. We operate Monday through Friday, from 9:00 AM to 8:00 PM Pacific Standard Time (PST). We’ll get back to you as soon as possible during our normal business hours. If your message is urgent, please mark it accordingly or include “URGENT” in the subject line, and we’ll do our best to respond promptly. Warm regards, Vapi Customer Support Team

Action Step: Double-check that the destination number you are transferring to is in full E.164 format (e.g.,

+1234567890

) and try calling it directly from your Twilio console. If the direct call fails or returns a 403 Forbidden, the issue is likely with number formatting or Twilio permissions—correct the format or update permissions as needed before retrying the transfer. Example:

+14155552671

According to the documentation, this is the most common cause for successful Vapi transfers that fail at the provider level ([see guide](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops)). Source: - [Debug call forwarding drops](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops)

To create the SIP Trunk on Vapi, I called the **credential API query**: { "provider": "byo-sip-trunk", "name": "Twilio Trunk 2", "gateways": [ { "ip": "simplementary-vapi.pstn.twilio.com", "inboundEnabled": false // <- This might be the problem } ], "outboundLeadingPlusEnabled": true } After debugging, I suspect the issue is that my Vapi SIP trunk has inboundEnabled: false (outbound only). Based on the Twilio logs, the transfer is being treated as a "Trunking Originating" call (from SIP trunk → PSTN), which gets rejected with 403 because the trunk isn't configured for bidirectional traffic. But when I tried to set inboundEnabled as true throught the API call or dashboard, I get this error: { * "message": "Couldn't validate SIP trunk credential. SIP gateway creation failed."*, "error": "Bad Request", "statusCode": 400 } The trunk ONLY creates successfully when inbound calls are disabled or set to false. Do let me know if you need more information

To resolve the 403 error and enable call transfers, ensure your SIP trunk is bidirectional by setting

"inboundEnabled": true

and that your Twilio Termination URI is correctly allowlisted in both Twilio and Vapi. Here’s an example API call:

json
{
  "provider": "byo-sip-trunk",
  "name": "Twilio Trunk",
  "gateways": [
    {
      "ip": "simplementary-vapi.pstn.twilio.com",
      "inboundEnabled": true
    }
  ],
  "outboundLeadingPlusEnabled": true
}

If you still receive a "SIP gateway creation failed" error, double-check that all required IPs are allowlisted and that your SIP URI is correct—this is the most common cause for this error according to the documentation ([see guide](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops)). Sources: - [Debug call forwarding drops](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops) - [SIP Trunking](https://docs.vapi.ai/advanced/sip/sip-trunk)

I've allowed the IPs in Twilio already and still get the error message... https://cdn.discordapp.com/attachments/1467593909545992294/1467600063256592456/image.png?ex=6980f891&is=697fa711&hm=3ba421cb678e8c67e7312c7a07942936428350cf282c01452d0984a259445747& https://cdn.discordapp.com/attachments/1467593909545992294/1467600064552767733/image.png?ex=6980f892&is=697fa712&hm=ddf083563b3430b514cb24bf7bb873b8cb195aeb8d038f9c9dd788a6c32bb5b7& https://cdn.discordapp.com/attachments/1467593909545992294/1467600066058518578/image.png?ex=6980f892&is=697fa712&hm=e2d882bd7041ad4a5653bce39af4eedf2af1950095baf6effe935e65e3b5511c& https://cdn.discordapp.com/attachments/1467593909545992294/1467600067123875891/image.png?ex=6980f892&is=697fa712&hm=206e121704e373daf89ae4e9762ab98bc6c773f2ea9ce94dfdc96c0d2c99307e&

Double-check that the

"ip"

field in your Vapi credential exactly matches your Twilio Termination SIP URI (including spelling and domain), as even a minor mismatch will cause the "SIP gateway creation failed" error. For example:

json
{
  "provider": "byo-sip-trunk",
  "name": "Twilio Trunk",
  "gateways": [
    {
      "ip": "simplementary-vapi.pstn.twilio.com",
      "inboundEnabled": true
    }
  ],
  "outboundLeadingPlusEnabled": true
}

If the error persists, try recreating the trunk with a new, unique name and confirm the domain is correct in both Twilio and Vapi ([see documentation](https://docs.vapi.ai/advanced/sip/twilio)). Source: - [Twilio SIP Integration](https://docs.vapi.ai/advanced/sip/twilio)

Thanks for sharing the details. It looks like the 403 is happening because your trunk is outbound-only—making it bidirectional requires "inboundEnabled": true and correct allowlisting of your Twilio Termination URI and IPs. The fact that creation fails when enabling inbound usually points to a mismatch or missing allowlist entry. Can you confirm that all Twilio SIP IPs and URIs are added in Vapi’s gateway settings? @dylan

Hi, thanks for getting back. So I've read the Twilio docs and added the following IP Addresses to my SIP Trunk Access Control List in Twilio: Vapi Termination IPs: - 44.229.228.186/32 - 44.238.177.138/32 Twilio Dublin Edge IPs: - 54.171.127.192/32 - 54.171.127.193/32 - 54.171.127.194/32 - 54.171.127.195/32 Twilio Ashburn Edge IPs: - 54.172.60.0/32 - 54.172.60.1/32 - 54.172.60.2/32 - 54.172.60.3/32 And I also included all those Twilio IPs in my Vapi Gateway Config: { "provider": "byo-sip-trunk", "name": "Twilio Trunk Bidirectional", "gateways": [ { "ip": "simplementary-vapi.pstn.twilio.com", "port": 5060, "outboundEnabled": true, * "inboundEnabled": true, // ← Fails with this set to true* "outboundProtocol": "udp" }, { "ip": "54.172.60.0", "port": 5060, "outboundEnabled": false, "inboundEnabled": true }, { "ip": "54.172.60.1", "port": 5060, "outboundEnabled": false, "inboundEnabled": true }, { "ip": "54.172.60.2", "port": 5060, "outboundEnabled": false, "inboundEnabled": true }, { "ip": "54.172.60.3", "port": 5060, "outboundEnabled": false, "inboundEnabled": true }, { "ip": "54.171.127.192", "port": 5060, "outboundEnabled": false, "inboundEnabled": true }, { "ip": "54.171.127.193", "port": 5060, "outboundEnabled": false, "inboundEnabled": true }, { "ip": "54.171.127.194", "port": 5060, "outboundEnabled": false, "inboundEnabled": true }, { "ip": "54.171.127.195", "port": 5060, "outboundEnabled": false, "inboundEnabled": true } ], "outboundLeadingPlusEnabled": true }

Thanks for sharing all the details it’s clear you’ve set up the allowlisting correctly. The error usually isn’t just about IPs; it often comes down to SIP credential validation, how Twilio expects bidirectional trunks to be configured, or small port/protocol mismatches on the inbound gateways. Sometimes the order of gateway entries or the way inbound/outbound flags are set can also trigger the 400 validation error. The practical next step would be to review the full configuration, verify the Twilio trunk credentials, and adjust the Vapi gateway so "inboundEnabled": true works reliably. We can assist you privately and walk through these checks step by step, this approach usually resolves the validation issue much faster than trial and error. @dylan

my warm transfers are not working today either, working fine last week, no changes on my end

Would that be okay? How should we do it?

Yes, that’s totally fine. The best way to move forward is to continue this privately so we can look at the full configuration end to end. I’ll help you review the Twilio trunk settings, SIP credentials, gateway order, and inbound validation logic in Vapi, and pinpoint exactly what’s causing the 400 error when inbound is enabled. If you send me a message privately, I’ll assist you directly and help you get the trunk working bidirectional without trial and error, this is usually much faster and more reliable one-on-one. @dylan

@Vapi Support Bot I still need help with this 😔

Try this actionable step: Double-check that the

"ip"

field in your Vapi credential exactly matches your Twilio Termination SIP URI (including spelling and domain), as even a minor mismatch will cause the "SIP gateway creation failed" error. Here’s the recommended payload:

json
{
  "provider": "byo-sip-trunk",
  "name": "Twilio Trunk",
  "gateways": [
    {
      "ip": "simplementary-vapi.pstn.twilio.com",
      "inboundEnabled": true
    }
  ],
  "outboundLeadingPlusEnabled": true
}

If this still fails, the next best step is to proceed with private troubleshooting as previously suggested, since the issue may be due to deeper configuration or credential validation details ([see documentation](https://docs.vapi.ai/advanced/sip/twilio)). Source: - [Twilio SIP Integration](https://docs.vapi.ai/advanced/sip/twilio)

@User could i get some help on this?

Pinging our team to look into it!

@dylan did you ever figure it out?