Hi everyone, I’m facing a recurring issue with call transfers using transfer_call_tool. Behavior: The tool returns “success”, however: the original call is immediately terminated the call does not ring on the destination number there is no explicit error in the logs, only a call drop Tool name is correct: transfer_call_tool The prompt does not contain any instruction to end the call after the transfer. Tool: 1bbe60bd-309f-443e-b907-1a8ca2f2a1fe Assistant: 21572483-78b9-449e-8c81-8bb1479cdcf2 Call Logs: 019b9620-7b00-7778-8a5a-e959c2e3f7bc 019b961b-53ad-7444-aea4-92f147694110 019b960d-c5c1-7ee5-97a8-b578ed5a44e2 If you could check at which step the transfer is failing at the provider layer, that would be greatly appreciated.

To check if the transfer was successfully initiated at the provider layer, retrieve the call details and inspect the

endedReason

field. Run the following API call (replace

{call_id}

and

YOUR_API_KEY

):

bash
curl -X GET "https://api.vapi.ai/call/{call_id}" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"

If

endedReason

is

"assistant-forwarded-call"

, the issue is likely with your telephony provider; otherwise, review your assistant's transfer configuration. This step will help you pinpoint where the transfer is failing in the workflow. For more details, see the [Debug call forwarding drops documentation](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)

I checked the call details via the API. The endedReason is assistant-forwarded-call, which confirms the transfer was successfully initiated by Vapi. However, the outbound leg is never created or rings, and the original call is terminated immediately. This strongly suggests a telephony/provider-side issue (carrier rejection, outbound routing, or Caller ID constraints), not an assistant or tool configuration problem.

Hi Nico, Thanks — since the call shows endedReason = "assistant-forwarded-call", Vapi did initiate the transfer. Next steps to confirm provider-side failure and collect the data we need to diagnose it: 1. Get telephony call ID from the Vapi call object (phoneCallProviderId). Example field in call API response:

"phoneCallProviderId": "CAabc123"

. 2. Check provider logs using that ID: - Twilio: Console > Monitor > Calls — search by Call SID → inspect timeline & TwiML execution for REFER/transfer errors. - Vonage: Dashboard > Call Logs — search by telephony call id/timestamp. - Telnyx: Mission Control > CDRs — search by telephony call id. 3. Look for these provider-side indicators: - No outbound call leg created or no INVITE sent → outbound routing/egress blocked. - 4xx/5xx SIP or PSTN errors (e.g., 403, 480, 503) → carrier rejection or destination unreachable. - Caller ID/CLI rejected or blocked by destination/carrier → check outgoing Caller ID configured for your Vapi number/provider. - Early hangup/leg closed immediately after REFER/transfer acceptance. 4. If using SIP, download Vapi PCAP (call object includes pcapUrl) and inspect in Wireshark: - Filter: sip.Method == "REFER" and look for responses (202, 4xx/5xx). - Confirm whether Vapi sent REFER and whether provider attempted a new INVITE to the destination. 5. Share the provider-side evidence here if you want us to review: - phoneCallProviderId from the call object - Provider call SID/ID and the exact timestamps - Provider timeline screenshots or SIP error codes (e.g., 403, 480, 486) - PCAP file or Wireshark screenshots showing REFER/INVITE and responses If you provide the phoneCallProviderId and any provider logs or SIP error codes, I will inspect them and point to the precise failure step. For reference: https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops