We are currently investigating an issue related to call forwarding from the bot to a live operator. Calls remain in a stalled state, negatively affecting user experience and support operations. Problem Description When a caller requests to be connected to an operator, the system is expected to transfer the call via a SIP REFER. While this functionality works in the majority of cases, we are observing intermittent failures where the transfer does not occur and the call becomes stuck. Call Examples The following call IDs have been identified where the SIP REFER-based transfer failed: 019dd344-9839-7666-9401-094c0d566d17 019dd345-e2a7-7aa4-a6ac-ca1922cadf3e 019dd36f-685a-788e-a29d-02f04462aea3 019dd3f7-57ca-7bb7-970d-63846cb26ad9 019dd3f9-476b-7cc5-8d8b-d25704f9c028 Initial Findings 1. For a subset of failed calls, the corresponding PCAP files are empty, which limits our ability to perform packet-level analysis. 2. Over the past two days, analysis of non-empty PCAPs indicates that for calls routed through 34.213.129.25, the expected SIP REFER request is consistently missing in 100% of cases where a transfer to an operator should occur. For 44.229.228.186 is about 82%.

Thanks for reaching out about your SIP Trunking setup! You can find step-by-step troubleshooting help here: 👉 [Vapi SIP Trunking Guide](https://docs.vapi.ai/advanced/sip/sip-trunk) If that doesn’t resolve it, please reply with: • Your Call ID • The exact error message or behavior (e.g. 401 Unauthorized, timeout, etc.) • Whether it’s happening on inbound, outbound, or both trunks • Any recent configuration changes Once we have that info, we can help pinpoint the issue faster.

This looks less like a random failure and more like a signaling gap, if SIP REFER isn’t even being triggered on those routes, the issue is likely at the call control or routing layer, not media/PCAP. I’d focus on tracing the transfer logic (pre-REFER) and checking carrier/SIP trunk behavior or failover rules tied to those IPs. I’ve handled similar VAPI transfer issues and can help you isolate exactly where the REFER is dropping. Quick one: are these failed calls all hitting the same assistant flow or specific provider/region before the transfer step? @Dimitar Todorov

Hello @User, all calls are intended to follow the same bot assistant flow, and the transfer logic is the same. All successful and failed transfers target the same PBX (single IP). I could find any trace or indication that the bot fails before the refer.

Hi, thanks for the follow-up. Just to clarify, I’m not VAPI official support, but I specialize in diagnosing and fixing issues like this and can help you get it resolved so you can move forward. From what you’ve shared, the missing SIP REFER points to a breakdown before the transfer is triggered (likely in call control, routing logic, or provider handling on specific nodes). My approach would be: Trace the full call flow at signaling level (pre-REFER) across both working and failed calls Compare routing behavior tied to those IPs (34.213.129.25 / 44.229.228.186) Validate transfer trigger conditions inside the assistant + VAPI logs Check SIP trunk/provider behavior (some suppress or reject REFER under certain states) Reproduce and patch with a controlled fallback (e.g., re-INVITE or alternative transfer method if needed) I can jump in, pinpoint exactly where the REFER is breaking, and implement a reliable fix so your transfers are consistent. Quick question: are you using a single SIP provider/trunk for both inbound and transfer, or is there any routing split before the REFER step? @Dimitar Todorov

Hello @Matt thank you for helping us. We are using only one TRANSFER tool with multiple destinations and one SIP provider/trunk (local on-premise PBX). Each destination is different port (see attached image). https://cdn.discordapp.com/attachments/1498670743083417660/1500768202567848018/VAPI_Settings.png?ex=69f9a2ce&is=69f8514e&hm=e03520ac03cd18f09d52d5b237ef3d7af8dcd9731fde4f4c6acccfa212a63cf2&

Thanks, this setup clarifies a lot. Since REFER is completely missing in failed cases, the issue is likely at the transfer trigger or PBX port-level handling, not the general flow. I’ll compare working vs failed calls, validate destination selection, and check how each port on your PBX handles REFER (some require specific conditions/headers). I can pinpoint the exact break and implement a reliable fix quickly. Let’s take this privately so I can review logs with you and resolve this fast. @Dimitar Todorov