Hi Vapi Support, I reviewed the latest SIP trace. The call is no longer failing on auth, and RTP is flowing both directions before teardown. However, the transfer still does not complete. What happens is: the assistant says it is transferring the Vapi log reports transfer failure due to user hangup on the SIP trace, the call remains bridged then CloudTalk sends BYE with: X-Asterisk-HangupCause: No user responding X-Asterisk-HangupCauseCode: 18 So from our side, it looks like the transfer is not being completed before the original CloudTalk caller leg times out and ends the call. Can you confirm: Whether transferCall on this SIP inbound call is actually being executed server-side Whether a transfer handoff is being attempted on the wire for this call Why the call remains bridged until CloudTalk times out, instead of completing the transfer first If needed, I can provide the full SIP trace showing RTP flow and the final CloudTalk BYE with cause 18.

To confirm if the transfer was attempted on the wire, download the PCAP for your call and filter for SIP REFER packets in Wireshark:

wireshark
sip.Method == "REFER"

If you see a REFER from Vapi, the transfer was initiated and CloudTalk is responsible for completing it. If not, review your Vapi SIP configuration for issues. For persistent drops, check the destination number format and provider logs as outlined in the [Vapi troubleshooting 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)

Thanks for sharing the trace it really helps. It feels like the transfer is being triggered, but not fully completing before CloudTalk times out the caller leg. Even though audio is flowing, the handoff doesn’t seem to finish on the SIP side. Can you confirm if a REFER or new INVITE is actually being sent during the transfer attempt? @Hani Emoss

Hi @Matt , I reviewed the SIP trace for the failed transfer. The call authenticates and connects to the Free Vapi SIP URI successfully, and the media bridge comes up. However, I do not see any SIP transfer sequence on the wire: no REFER no 202 Accepted no NOTIFY Instead, the call remains bridged until the original CloudTalk leg hangs up with: X-Asterisk-HangupCause: No user responding X-Asterisk-HangupCauseCode: 18 Then Asterisk sends BYE to the Vapi leg. So from our side, it appears transferCall is not producing an actual SIP REFER on this call path. i wonder why no REFER is being initiated ive also attached the trace https://cdn.discordapp.com/attachments/1487142002536743006/1487159836704768070/newexpor.txt?ex=69c82107&is=69c6cf87&hm=ea5ddac6a563408f7e2efd06e020528f839d62322b30dd30449d0c4ff6dfdea9&

Thanks for sharing this super helpful. From the trace, it looks like no REFER is being sent at all, so the transfer never actually starts on the SIP side and the call just sits there until CloudTalk times out. That usually means the transfer isn’t really being triggered or isn’t wired to SIP properly in this flow. I’ve seen this a few times, happy to take a look at your setup and help you fix it quickly if you want. @Hani Emoss

that would be great if you'd like to take a look