Transfer initiated but destination phone never rin...
# support
m
Call IDs: - 019ce2bf-f379-7001-9c5d-30ec27e9cf46 — Mar 12, 11:54 AM ET - 019cde3c-f011-700d-b8d9-c5043ade1613 — Mar 11, 2:52 PM ET Expected: transferCall tool returns "Transfer initiated" → destination phone (+14126727375) rings → staff answers Actual: transferCall returns "Transfer initiated", call ends with endedReason: assistant-forwarded-call, destination phone never rings. Staff received the pre-transfer Pushover notification on both calls and were standing by with 3 employees in the office and open phone lines - confirmed no incoming call on their end. Both calls followed the same sequence: notify_staff_before_transfer (Success) → check_office_forward (Success) → transferCall ("Transfer initiated") → call ends. Transfer tool is a cold transfer to a US number with no transferPlan configured.
v
Next Step: Check your telephony provider's call logs for transfer errors using the
phoneCallProviderId
from your Vapi call object. Here's how to retrieve it:
Copy code
bash
curl -X GET "https://api.vapi.ai/call/{call_id}" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"
Look for the
phoneCallProviderId
in the response, then search for this ID in your provider's dashboard (e.g., Twilio Console > Call Logs) to identify why the transfer failed. For more details, see the [Vapi debug 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)
m
The transport provider is vapi.sip on both calls — not Twilio. There is no Twilio console to check. VAPI is handling the telephony directly via its own SIP infrastructure. SBC Call SIDs: - 718637960-3982319555-1756597058@msc1.382COM.COM (Mar 12) - 715909096-3982243861-1275286892@msc1.382COM.COM (Mar 11) Can a human agent look at these in your SIP logs?
Has this been looked at by a human?
Third failed transfer — different failure mode Call ID: 019cf75f-a294-7000-95c0-f3819242c9cc — Mar 16, 12:01 PM ET This one rang in the office and staff answered, but the call dropped on pickup. Same tool sequence as the previous two: notify_staff_before_transfer (Success) → check_office_forward (Success) → transferCall ("Transfer initiated") → endedReason: assistant-forwarded-call. Three employees in the office with open lines confirmed the drop. Ring count and post-transfer leg duration are not visible from our side — that data would be in your SIP/telephony logs. Please help.
m
Have you been able to resolve this
m
No. it keeps happening.
No. Will a human look into it?
m
Yes , I can take a look at it and also I’m ain’t a bot 😅🙂‍↔️
m
Thank you
Update from office staff: On two other calls this afternoon, the transferred caller connected and was mid-conversation with staff when the call dropped. Staff had to call them back. The bridge is establishing but failing during the live call, not just at handoff.
m
Thanks for sharing the details. From what you described, the transfer tool is returning “Transfer initiated,” but the call ends immediately with assistant-forwarded-call and the destination number never rings, even though the pre-transfer notification succeeds. Quick question: which telephony provider and transfer configuration are you using for the transferCall tool (e.g., Twilio, SIP, etc.)? Also, are there any logs on the provider side showing an attempted outbound call to +14126727375? @Michael
m
the first two calls i referenced failed that way... there was no ringing in the office and the call just ended. then today they let me know that thay had one fail after it rang in the office and was answered by staff and the call just ended... that is this one ... Third failed transfer — different failure mode Call ID: 019cf75f-a294-7000-95c0-f3819242c9cc — Mar 16, 12:01 PM ET This one rang in the office and staff answered, but the call dropped on pickup. Same tool sequence as the previous two: notify_staff_before_transfer (Success) → check_office_forward (Success) → transferCall ("Transfer initiated") → endedReason: assistant-forwarded-call. Three employees in the office with open lines confirmed the drop. Ring count and post-transfer leg duration are not visible from our side — that data would be in your SIP/telephony logs. Please help. Then later today these two calls happened like this ... Update from office staff: On two other calls this afternoon, the transferred caller connected and was mid-conversation with staff when the call dropped. Staff had to call them back. The bridge is establishing but failing during the live call, not just at handoff. The telephony provider is VAPI since we are using a line provided by VAPI. I told the customer we would be using a twilio line if this is going to be an ongoing issue. I was also made aware of a setting that might be causing this ... " • Tip: If you are using Vapi for transfers and they are failing, check for "phone-call-control" server events, as removing this often fixes call-forwarding issues. [11] " [11] https://vapi.ai/community/m/1369846718056763453
m
From what you described, it looks like the transfer is sometimes establishing but the bridge is failing either right at pickup or during the live conversation, since all of them still end with assistant-forwarded-call. Because you’re using a Vapi provided line, the detailed ring and bridge logs would likely only appear in the SIP/telephony logs on their side.
One thing I came across is that phone-call-control server events can sometimes interfere with Vapi transfers, and removing them has fixed similar issues for others. If you want, feel free to message me privately and I can help take a closer look at the call flow and settings to figure out exactly where the transfer is breaking. @Michael
m
are you able to look at the detailed ring and bridge logs in the SIP/telephony logs on the VAPI side?
are you able to look at the detailed ring and bridge logs in the SIP/telephony logs on the VAPI side?
I switched to a twilio phone number to avoid this issue