Subject: Call transfer hangs up immediately on Australian Vapi number Hi Vapi support, I’m experiencing a persistent issue with call transfers in my Vapi assistant setup and would appreciate assistance investigating it. Issue Summary When a caller asks the assistant to transfer the call, the assistant confirms the transfer and the Vapi dashboard shows the transfer as “Completed successfully”, however the call disconnects immediately afterwards. The destination phone never rings and the receiving party never receives the call. Call Details Call ID:

019e6d82-c67c-777d-95d4-5d79d8b42d4b

Timestamp: 28 May 2026 – 5:05 PM AEST Expected Behaviour The assistant should successfully transfer the live inbound call to the recipient (“Kelly”), and Kelly’s phone should ring normally so the conversation can continue. Actual Behaviour * Assistant says: “Transferring to Kelly.” * Dashboard displays: “Transfer Call — Completed successfully” * Original call disconnects immediately * Receiving party never receives the call * No ringing occurs on the destination device Environment / Setup * Location: Australia * Phone Number Type: Vapi AUD number * Transfer methods tested: 1. Vapi API transfer 2.

vapi.sip

Both methods produce the same failure. Troubleshooting Already Performed I have already spent approximately 3 hours troubleshooting this with Cooper in the Vapi support/copilot assistant. During testing: * SIP configuration appears valid * Logs and dashboard indicate the transfer completed successfully * No obvious SIP errors are visible from my side * Despite this, the transferred call never reaches the recipient https://cdn.discordapp.com/attachments/1509663453189636219/1509663453994815538/image.png?ex=6a19ff27&is=6a18ada7&hm=7190e57b72317807da4d84b10860c279afc8773d96a71b30332ed69dd67c7928& https://cdn.discordapp.com/attachments/1509663453189636219/1509663454561304824/Screenshot_2026-05-29_062931.png?ex=6a19ff27&is=6a18ada7&hm=9fd547b6da54b4b96ca016c3b3ffc6483df338bd9bf61a54a8ab1d9382f305d8&

Hey, Can you try after making these changes Remove

sipVerb: "refer"

from your transfer destination. If you'd prefer a straight handoff (the caller goes directly to Kelly, Vapi drops off), use

mode: "blind-transfer"

let me know if this fixes your issue

I can't see anywhere to remove sipVerb I am also blind transfering https://cdn.discordapp.com/attachments/1509663453189636219/1511191924264931448/image.png?ex=6a1f8ea7&is=6a1e3d27&hm=c66b449dadcf70fbb39585162c2bd24fd4982de93e15d39cbc4254650f72ec07&

Hey, I checked the logs for call 019e6d82-c67c-777d-95d4-5d79d8b42d4b, and Vapi is completing the transfer flow successfully on our side. Can you check and forward the Twilio provider logs for provider call SID CAdf815ca7e7a1f6f2c28267dc6693bf7e to see whether the outbound leg was rejected or failed to route to the destination number Regards, Priyanshu

Here is the call logs https://cdn.discordapp.com/attachments/1509663453189636219/1511527676500906184/message.txt?ex=6a20c758&is=6a1f75d8&hm=6734224a7a87636445a355c8f3a22307b34003cd6d9ce94da7059d87068fc374&

Hey, I checked the Vapi logs for call

019e6d82-c67c-777d-95d4-5d79d8b42d4b

. On our side, the transfer completed successfully: - the

transfer_call

tool completed successfully - the transfer was initiated to

+61423195915

- the call ended with

assistant-forwarded-call

, which means the assistant exited because the call was forwarded There are no transfer failed, SIP, or Twilio connect errors in the Vapi logs for this call. So at this point, the issue does not appear to be the assistant failing to invoke the transfer. The remaining gap is that the outbound provider leg to the destination does not appear to have connected or rung after handoff. Can you please check whether Twilio created a separate outbound/child call SID to

+61423195915

at the time of transfer, and if so send that call log as well? If no outbound child leg exists in Twilio at all, that would narrow this to the provider handoff path after Vapi marks the transfer initiated.

Yes — Twilio did create an outbound/child call leg. Here's the full call log for it: Twilio Outbound Child Call Log Call SID: CA785674fe23d516c08193d90453328a95 Date: 17:37:52 ACST 2026-06-03 Start Time: 17:37:52 ACST 2026-06-03 End Time: 17:37:56 ACST 2026-06-03 Duration: 0 sec Cost: — From: +6xxxxx195915 To: sip:+61xxx003305@5t4n6j0wnrl.sip.livekit.cloud;transport=tcp Direction: Trunking Originating Type: sip-pstn Trunk SID: TKe463091db9f94c7959125452fea3d2fc Status: No Answer Insights Summary (Carrier/SIP Properties) FieldValueCall StatenoanswerLast SIP Response487 Request TerminatedPost-Dial Delay0.884 secondsWho Hung Up—Twilio RTP Latency to PBX—Twilio RTP Latency to PSTN— From leg: Connection: mobile Country: AU Carrier: Optus Mobile Pty Ltd (02) (SingTel) To leg (SIP trunk): Connection: sip_trunk SIP Call ID: ac1954cb91827a7ccec2e3d58309713c@0.0.0.0 Signaling IPs: 159.13.54.178 ↔ 54.252.254.65 Media IPs: 168.86.147.139 Edge Location: Sydney (au1) Metrics: No packet loss, no jitter detected on either Carrier Edge or SIP Edge. Edge location for both: Sydney (au1). Request Inspector: No HTTP requests logged for this event.

The Twilio child leg was created, so the transfer request is getting past Vapi, but that leg is ending almost immediately with No Answer and SIP 487 Request Terminated after about 4 seconds. That means the outbound/SIP leg is being cancelled or terminated before the destination can answer, which lines up with why Kelly’s phone never rings. At this point, this looks like the provider/SIP handoff leg rather than the assistant failing to call the transfer tool. Can you send the full SIP request/response trace for CA785674fe23d516c08193d90453328a95, especially the INVITE, any 18x ringing/progress responses, and the CANCEL/487 sequence? That will show whether the SIP trunk, LiveKit/Vapi side, or downstream carrier is terminating the leg. Also, can you confirm which telephony provider the Vapi AUD number is provisioned through on your side, or share the number/provider metadata from the dashboard? I can see the transfer child leg in Twilio, but I want to confirm the provider for the original Vapi number before making that assumption.

I'm sending the numbers to two different legs while I'm trying to do my testing. Originally I was sending or transferring the calls to my Optus mobile phone, which was working successfully approximately three weeks ago when I was first playing with the transfer. I am now trying to transfer the call to a Teams number in Office 365 and it was unsuccessful. I then decided to go back to transferring the call for testing purposes to my Optus number and the same behavior is what we're discussing right now. I'm trying to work out why I could successfully transfer to my mobile number on the Optus network around two to three weeks ago but I can't seem to do it now.

Can you send the call ID for a transfer to your Optus mobile that succeeded around 2 to 3 weeks ago? That will let me compare the successful and failed transfer paths directly and narrow down what changed