https://vapi.ai/ logo
Join Discord
Powered by
SIP transfers always fail: REFER Refer-To built fr...
# support
n
SIP transfers always fail: REFER 
Refer-To
built from wrong gateway Following up on this thread (the hybrid gateway workaround suggested here is what led us to this bug). [Setup (as recommended by Vapi support in this thread):](https://discord.com/channels/1211482211119796234/1494130355660259408)
Copy code
{
  "provider": "byo-sip-trunk",
  "name": "Twilio SIP Trunk",
  "gateways": [
    {
      "ip": "<our-fqdn>.pstn.twilio.com",
      "inboundEnabled": false,
      "outboundEnabled": true
    },
    {
      "ip": "54.172.60.0",
      "inboundEnabled": true,
      "outboundEnabled": false
    }
  ],
  "outboundAuthenticationPlan": {
    "authUsername": "vapi"
  },
  "outboundLeadingPlusEnabled": true
}
Bug: When a transfer is triggered, Vapi sends a SIP REFER to Twilio. The Refer-To URI is constructed using the inbound gateway's IP and the ephemeral TLS rport of the active session — not the configured outbound FQDN. Twilio receives the REFER, tries to route to a nonexistent ephemeral port, and returns 403 Forbidden. Reproduced from our own SIP traces: # Twilio's inbound Via header (note rport=): Via: SIP/2.0/TLS 54.172.60.1:5061;branch=...;rport= # Vapi's REFER — Refer-To picks up that IP and rport: Refer-To: <sip:+@54.172.60.1:> ← WRONG # Expected: Refer-To: <sip:+@.pstn.twilio.com> ← should use outbound gateway FQDN The ephemeral port is the TLS source port Twilio used for the inbound connection — it's gone by the time the REFER is processed. This makes every single transfer fail.
Root cause: When inbound and outbound gateways are different entries (the only way to make Twilio work per this thread), Vapi constructs Refer-To from the inbound session's source address instead of the configured outbound gateway. The two are different entries precisely because of the FQDN validation bug described in this thread — so that workaround directly causes this bug. Pcap would definitively prove it but it likely contains caller PII so we're not sharing it publicly — happy to share privately with an engineer if needed.
v
This appears to be a Vapi-side SIP REFER construction bug. The documentation recommends escalating to support when SIP traces show Vapi is building the Refer-To URI incorrectly. To escalate, include: - Call ID and timestamp - SIP trace and troubleshooting results - Provider error codes/logs - Screenshots of your gateway configuration Submit these details to Vapi support so engineering can investigate and resolve the issue. Reference: [Vapi call forwarding debug 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)
PreviousNext
Powered by