- The call ID: - 12dc22c2-4563-46f8-b4f6-ddc5aebe80ca - When it happened (UTC): - Vapi call createdAt: 2025-09-09T23:14:23.932Z - Transfer initiated from our server: 2025-09-09T23:14:34Z (we log [transfer-branch] → SIP) - Call failed immediately after “Transferring…” (23:14:34Z–23:14:36Z window) - Twilio Elastic SIP Trunking “SIP Message Logs/Calls”: no entries from 23:14:30Z–23:15:30Z - What we expected: - After our webhook returned a SIP transfer destination, Vapi should emit a SIP INVITE to our Twilio trunk and Twilio should log the INVITE (or a 407 followed by an authenticated INVITE). - What actually happened: - Assistant answered and functioned normally; when transfer was requested, our webhook returned destination type=sip; call hung up immediately after “Transferring…”. Twilio shows no INVITE or call record for this time window (appears to fail before egress). - Exact transfer payload we returned (headers sanitized): - sipUri: sip:+17275934108@vocly-prod.pstn.twilio.com;transport=tls - sipHeaders: - From: - P‑Asserted‑Identity: "Carey Leisure & Carney" - Environment/auth posture during this test: - Target host: vocly-prod.pstn.twilio.com (Elastic SIP Trunk Termination) - Twilio Termination auth: IP ACL only, attached to the trunk, entries = 44.229.228.186/32 and 44.238.177.138/32 (Vapi egress IPs); no Credential List attached. - Our assistant payload (at start) showed "sip": null (we are not forcing transient creds in this test). - Request: - Please trace why no outbound INVITE was emitted for callId 12dc22c2-4563-46f8-b4f6-ddc5aebe80ca at 2025-09-09T23:14:34Z UTC when destination.type='sip' is returned with the Twilio trunk host and master‑CLI headers. We need to know whether Vapi suppressed the INVITE pre‑egress and the reason.

Thank you for the detailed breakdown. To help narrow down the cause, could you confirm if there were any recent changes to your SIP trunk or webhook configurations just before this failure started occurring? Even minor changes can sometimes impact call routing or trigger unexpected behavior. Example: - New IPs added/removed from the Twilio ACL - Webhook URL or payload format changes - Updates to the assistant or transfer tool configuration This will help determine if a configuration change may have led to the INVITE not being emitted. Source: - [Vapi outbound call not triggering (Discord)](https://discord.com/channels/1211482211119796234/1341449578100031488)

No config change preceded the failure. Outbound SIP transfer has never worked from the first attempt. All changes (headers, ACL fixes, transient tests) were made afterward while debugging; none led to a single outbound INVITE showing up in Twilio logs. - Current state (for the failing call): - callId: 12dc22c2-4563-46f8-b4f6-ddc5aebe80ca - createdAt: 2025-09-09T23:14:23.932Z UTC; transfer requested ~23:14:34Z UTC - destination: type='sip', sipUri='sip:+17275934108@vocly-prod.pstn.twilio.com;transport=tls' - sipHeaders: From=, P-Asserted-Identity="Carey Leisure & Carney" - Twilio Termination auth: IP ACL only (attached to trunk) with 44.229.228.186/32 and 44.238.177.138/32; no Credential List - Assistant answers; on transfer the call hangs immediately; Twilio Elastic SIP Trunking SIP logs/Calls show no INVITE in 23:14:30–23:15:30Z UTC. So there weren’t “changes right before it stopped working”; it simply never emitted an INVITE. We also exhaustively tested credential-based auth: - SIP Domain: Credential List only (no IP ACL), transient creds attached (username_present:true), and user-in-URI override; still no SIP logs (no 407/INVITE). - Trunk Termination: Credential List only (no IP ACL) with matching creds; still no SIP logs. - We rotated passwords to policy-compliant values and re-encrypted DB secrets; same result. Conclusion: even with creds correctly attached, no INVITE is emitted.

Hi go4anthony, For a failed outbound SIP transfer to Twilio with no INVITE sent, you should follow these steps: 1. **Check Call Ended Reason**: Use the [Vapi API](https://docs.vapi.ai/phone-calling/transfer-calls/debug-forwarding-drops) to confirm if Vapi initiated the forwarding with the correct

endedReason

. If

endedReason

is not

"assistant-forwarded-call"

, then check the assistant configuration. 2. **Inspect for Call Control Conflicts**: Ensure that

serverMessages

does not include

"phone-call-control"

, unless custom call control is required. 3. **Phone Call Provider Bypass**: Make sure

phoneCallProviderBypassEnabled

is set to

false

so that Vapi handles the call control. 4. **Verify SIP Configuration**: Double-check the SIP endpoint configuration and ensure it matches the SIP addressing and does not conflict with any other settings. 5. **Telephony Logs**: Since you mentioned there were no logs in Twilio’s message logs, ensure that the outbound transfer number is correct and properly configured. Double-check that the phone number being dialed is in the correct format with a country code. 6. **Review SIP REFER**: If using SIP for transfers, ensure that the SIP REFER packet is being generated by Vapi by checking the PCAP logs via Wireshark. If the problem persists after these steps, confirming the correct configuration through logs and ensuring the SIP settings are properly set up can help identify underlying issues. For more detailed guidance, consider reviewing the Twilio [SIP Integration documentation](https://docs.vapi.ai/advanced/sip/twilio). Let me know if you need further assistance we will be happy to help.

We’re sending the right transfer payload (SIP URI + master DID headers) to Twilio’s trunk. Twilio is set to IP‑ACL only with Vapi’s egress IPs. Still, Twilio sees no INVITE. That means the INVITE isn’t leaving Vapi. The telltale check is the call’s endedReason; if it’s not “assistant-forwarded-call,” Vapi never started forwarding. Our assistant config doesn’t include phone-call-control, and we’re not bypassing Vapi’s call control. We also tried credential‑only on both SIP Domain and Trunk; even then, no INVITE showed up. Can you trace callId 12dc22c2-4563-46f8-b4f6-ddc5aebe80ca (23:14:34Z UTC). and see why forwarding didn’t begin and why no INVITE was emitted.

We are doing a PCAP trace on the call id. Hang tight

Thanks for the suggestion. We’re not transferring to a SIP Domain user; we’re transferring to an Elastic SIP Trunk Termination host and per Twilio the user part must be the E.164: sip:+17275934108@vocly-prod.pstn.twilio.com;transport=tls. - The PCAP you shared is Twilio sending REFER to sip.vapi.ai and failing due to missing referUrl; that’s the Twilio SIP Domain REFER flow, which we are not using. - Can you please trace why, for callId 12dc22c2-4563-46f8-b4f6-ddc5aebe80ca at 2025‑09‑09T23:14:34Z UTC, Vapi did not emit an outbound INVITE to vocly‑prod.pstn.twilio.com? Our assistant returned: - sipUri: sip:+17275934108@vocly-prod.pstn.twilio.com;transport=tls - From/PAI: +17576974173 - Also, please confirm whether the transfer path used internally switched to a SIP Domain/REFER mode. Our intent is BYO trunk INVITE, not REFER. If Vapi requires transferPlan with REFER, we can test that, but then we’ll add Twilio as required.

We will look into it some more.

im guessing you guys don't know how to fix this...?

We attempted a trace for the call id

12dc22c2-4563-46f8-b4f6-ddc5aebe80ca

but due to our data retention policy, it is beyond the date range we can access. Do you happen to have another call id that is more recent? Preferably within <7 days. Also, our default method of transferPlans is

REFER

but we accept

DIAL

and

BYE

as valid SIP transfer methods if configured within the assistant. Another thing to note, I noticed you are using TLS transport. Typically we only use UDP so if you are having issues receiving invites to that SIP URI, you may want to consider UDP if possible.