Intermittent transfer bug: calls show endedReason=assistant-forwarded-call, but the destination never rings and the caller hears silence. Example callId: 019d59bc-deb6-7005-b853-5fd2b565e84d Destination: +14156382815 Assistant invoked transfer_call_tool with {"destination":"+14156382815"} and got "Transfer initiated", but: - runtime call logs end right after the tool call (no dial attempt / no carrier response) - SIP PCAP only contains the inbound 4 packets; the destination number never appears - repro rate ~4/5 fails, ~1/5 succeeds (happens with blind + warm transfer) phoneNumberId: 762a29fb-321e-4063-9637-825c7b97bc7f assistantId: 5d42f95e-d91c-40b3-a5ee-c7f4769503a8 transfer toolId: e9aa3966-85a6-40e3-8bc3-55c210d8cafc Can someone confirm if there’s a known issue on the Vapi carrier edge where transfer doesn’t create the outbound leg, and what mitigation is recommended? Many thanks in advance!!!

This doesn’t look like a carrier-edge issue it’s more likely the transfer flow breaking before the outbound leg is actually created. Since your logs stop right after “Transfer initiated” and there’s no SIP activity, the tool is being acknowledged but not fully executed. That usually points to an intermittent orchestration or state issue (e.g., race condition, call context ending early, or the session closing before the dial is triggered). The fact that it works ~1/5 times reinforces that it’s not a hard config error but something timing-related. I’d suggest checking whether the call session is still active at the moment of transfer and if there are any async timeouts or interruptions right after the tool call. Adding a slight delay or confirmation step before ending the assistant flow can sometimes stabilize it. If you want, I can help review your transfer flow and pinpoint where it’s dropping @michaelsimpson

hi yes that would be awesome