AI Voice Agent Transfer to Human Not Working

Answer in brief: Most failed AI voice agent transfers never reach the network. Across the three Vapi transfer-troubleshooting pages we opened on 8 September 2026, 11 of the 16 named symptoms resolve to configuration on your side, 3 to the carrier and 2 to the other party. Retell’s human-detection timeout defaults to 30 seconds.

This page is about the telephony layer only: SIP methods, call legs, caller ID, attestation and provider error codes. The conversational half of the problem — escalation triggers, the handoff packet, what the human is told — is covered separately in our guide to designing the AI-to-human handoff and context transfer. If your prospects are repeating themselves, read that one. If the call is dropping, ringing out, or sitting on hold music with nobody on the other end, you are in the right place.

The ordering below follows frequency, not severity. A dropped transfer is the worst outcome for a caller, but it is far from the most common cause, and teams waste days packet-capturing a problem that is a single boolean in an assistant config.

The first test: did my transfer ever leave the platform?

Every transfer failure splits at one point — whether your voice platform successfully initiated the handoff, or whether it never got that far. Both platforms publish the signal, and reading it is the same first move as in any dropped call: our guide to AI voice agent call-ended reason codes maps the field names across Vapi, Retell and Twilio.

Vapi’s forwarding-drop guide tells you to fetch the call object and read endedReason: assistant-forwarded-call means Vapi forwarded successfully and you continue debugging downstream; any other value means forwarding was not initiated and the fault is in your assistant configuration (Vapi, Debug call forwarding drops). Retell’s equivalent is the SIP connection log in the call record, which its troubleshooting page points to for transfers that were triggered but failed (Retell AI, Debug call transfer failure).

The trap is treating a success flag as proof of delivery. Vapi says this plainly on its blind-transfer page: “An assistant-forwarded-call ended reason confirms that Vapi initiated the transfer. It does not confirm that the downstream PBX or provider completed it.” (Vapi, Configure blind transfer modes). Treat the platform’s ended reason as a fork in the diagnosis, never as a result.

Before anything else, rule out the scenarios that are documented as unsupported. Vapi lists a compatibility matrix in which phone-to-phone and SIP-to-anything transfers are supported but web-to-phone and PSTN-to-SIP are not, with the note: “Web-to-phone transfers are not supported. The call will always drop in this scenario.” Retell’s page carries the same boundary — “Call transfer is only supported for phone calls, not web calls”. A demo that works from a browser widget and dies on a real number is usually this and nothing more.

Transfer failure taxonomy: cold, warm, SIP REFER and conference bridge

Four transfer modes are in general use, and each buys you something at the cost of something else. The table is the diagnostic: find the row you are running, then read across to the signature and the check.

Mode	How it works	Caller ID and attestation	Context carry	Who holds the leg	Failure signature	The check that confirms it
Cold transfer (SIP INVITE)	Establishes or updates the active call path, bridges the transfer, agent drops off. Retell’s default cold mode (Retell, Transfer call tool).	You choose what the destination sees. Showing the caller’s own number needs provider support; Retell documents that the transfer fails if caller ID override is not supported. Since 23 January 2026, cold_transfer_mode selects the method and show_transferee_as_caller only affects display, and only under SIP INVITE (Retell deprecation notice).	Custom X- headers on the INVITE. Retell warns they are preserved only when transferring directly to a SIP endpoint and may be stripped when transferring to a PSTN number (Retell, SIP headers).	Your platform, until the bridge completes and the agent drops off. Retell documents that the AI agent fee stops at that point and only the telephony fee continues.	Transfer is marked failed at the moment of dial, before the destination rings at all.	Re-run the identical transfer with Displayed Caller ID set to the agent’s own number. If it now connects, caller ID override is the cause, not routing.
Warm transfer (agent stays on the line)	The platform dials the destination on a second leg, plays hold audio to the caller, delivers a fixed message, a generated summary or TwiML, then bridges. Vapi ships five such modes (Vapi, Configure warm transfer modes).	Retell’s warm transfer uses SIP DIAL and sets the from and P-Asserted-Identity headers to the user’s number. Its Twilio numbers support showing the caller’s number on both warm and cold transfer; its Telnyx numbers support it only via cold transfer using SIP REFER.	Spoken, not signalled. Vapi’s summary modes generate destination-specific context from {{transcript}} with a summary timeout of 1–60 seconds.	Your platform holds both legs. Retell documents that the call bills at the normal per-minute agent rate through the hold and briefing phases.	The caller stays on hold music well past the configured ring duration, and no failure prompt is ever spoken.	Compare hold duration against the configured timeout. Vapi’s wait-for-operator timeout accepts 1–600 seconds and defaults to 60; Retell’s agent detection timeout defaults to 30 seconds. Hold that exceeds the timeout means the failure path is not firing.
SIP REFER (blind)	You ask the SIP endpoint to place a new call to the target and replace your leg. Twilio’s <Refer> is SIP-legs only — PSTN and Voice SDK legs return an error (Twilio, TwiML Voice: Refer).	The referred-to endpoint originates the new call, so caller ID and attestation become the provider’s, not yours. Vapi’s guide notes that once it sends the REFER, the SIP provider manages the transfer.	Headers in the REFER target URI — X- headers or User-to-User. Vapi’s blind-transfer-add-summary-to-sip-header mode places a generated summary in X-Transfer-Summary. Retell warns that providers may not honour custom SIP headers in a REFER request, and names Twilio as one that does not.	Nobody on your side after the endpoint returns 202 Accepted. You observe the outcome only through SIP NOTIFY.	Your call ends cleanly and the destination never rings.	Read the <Refer> action-URL parameters: ReferSipResponseCode 405 with ReferCallStatus failed means the endpoint rejected the REFER outright; NotifySipResponseCode 486 means the target was busy. Or take a packet capture and filter sip.Method == "REFER", as Vapi’s debug guide instructs.
Conference bridge	Both parties are placed into a named room and your application moves participants, rather than handing the call away. Twilio caps a room at 250 participants (Twilio, TwiML Voice: Conference).	The strongest option in the US. Twilio documents that preserving the original caller ID with a CallToken requires Programmable Voice Queues or Conferences, and states: “Using the <Dial> instruction is not possible for this call flow.” If the caller ID on the outgoing leg does not match the CallToken, Twilio rejects the call (Twilio, Trusted calling with SHAKEN/STIR).	Out of band. Context arrives by screen pop or CRM record — nothing rides in the audio path with the call.	Your application. Twilio documents that with endConferenceOnExit set on a participant, “when that participant leaves, the conference ends and all other participants drop out”.	The caller sits alone in the room listening to hold music. With startConferenceOnEnter false and no moderator present, Twilio documents that participants “are muted and hear background music until a participant joins where startConferenceOnEnter is true”. If the waitUrl document runs out of verbs, the music stops and silence plays.	Pull the conference participant list or status callbacks and answer one question: was a second participant leg ever created?

Any transfer you cannot place a row for is a transfer you cannot debug. If your vendor’s documentation does not tell you which SIP method it uses and who holds the leg, that is itself a finding — our checklist for auditing an AI vendor’s technical claims covers how to press for it.

Cause 1: configuration stopped the transfer before it was placed

This is the largest bucket by a distance. Method for the count: on 8 September 2026 we opened Vapi’s three published transfer-troubleshooting pages — blind transfer (6 symptom rows), warm transfer (7 rows) and debug forwarding drops (3 named root causes) — and classified each named cause as configuration, downstream network, or the other party. Sixteen causes, split 11 / 3 / 2. Of the three platforms whose transfer documentation we opened, Vapi is the only one we found publishing symptom-to-cause tables for transfers, which is why the count uses its pages; it is a count of documented causes, not of incidents in the field.

The configuration causes that recur:

• Your server is holding call control. Vapi’s guide says that if phone-call-control is present in serverMessages, your server is overriding Vapi’s call control, and to remove it unless you are implementing custom transfer logic. The companion flag is phoneCallProviderBypassEnabled, which must be false for platform-managed forwarding.
• The tool was never wired up. Retell’s troubleshooting page starts by asking you to confirm transfer_call is in the agent’s function list, and for conversation-flow agents, that the transfer node is actually reachable and connected.
• The SIP verb is doing something else. Vapi’s sipVerb accepts refer, dial and bye; bye ends the Vapi leg and places no destination call at all. A transfer that hangs up on the caller instantly, every time, is worth checking against this before anything else.
• A timeout is too short. Vapi lists a dial transfer that stops ringing too soon against a dialTimeout below the range it should sit in, and summary generation timing out against a summaryPlan.timeoutSeconds too short for the chosen model. The generated-summary path is a model call inside a live call, and it inherits every latency problem a mid-call model lookup has.

Cause 2: the network accepted the request and the destination refused the call

When the platform did initiate the transfer, the answer is in the signalling, and Twilio publishes the exact parameter set for a REFER-based handoff. Its <Refer> action URL returns ReferCallStatus, ReferSipResponseCode and NotifySipResponseCode, with worked scenarios: a success is 202 then 200; a busy target is 202 then 486 with ReferCallStatus busy; an endpoint that rejects the REFER outright returns 405 with status failed; and a caller who hangs up before the transaction completes yields status canceled with 202 and 180.

That last row matters more than teams expect, because “caller hangs up mid-transfer” is the case nobody tests and the case that generates the most confusing logs — a transfer that looks half-finished on both sides.

If you are on SIP trunking, Vapi’s debug guide tells you to pull the PCAP from the call object’s pcapUrl field, open it in Wireshark and filter sip.Method == "REFER": a present REFER with a 202 response means your platform did its job and the provider owns the rest; a missing REFER means the transfer was never initiated and you are back in Cause 1.

Cause 3: caller ID override and attestation quietly failed the transfer

Wanting the receiving human to see the original caller’s number is a reasonable product decision that has a telephony bill attached. Retell documents that showing the user’s number requires caller ID override support from the telephony provider, that its Twilio numbers support it on both warm and cold transfer while its Telnyx numbers support it only via cold transfer, and that where override is not supported the transfer fails rather than falling back.

In the United States there is a second cost, and it is the transfer-leg case of the wider question we cover in caller-ID authentication for AI voice agents. Twilio’s SHAKEN/STIR documentation defines attestation A as “the highest attestation given by the originating service provider to indicate that the caller is known and has the right to use the phone number as the caller ID”. Re-originating a leg with a number you do not have rights to is exactly the pattern that framework is designed to distrust. Twilio’s answer is the CallToken: pass it from the parent leg to the forwarded leg, and if the caller ID on the outgoing call does not match the token, Twilio rejects the call with an error. Where an incoming call arrives with no SHAKEN passport at all, Twilio signs the forwarded leg with attestation C.

For Australian deployments, none of that machinery applies: Twilio’s own page states that SHAKEN/STIR support is currently deployed only in the United States and France, and we could not locate a published Australian call-authentication scheme equivalent to it (we looked at the ACMA’s phone-scams pages and at the registered industry code itself). What Australia has instead is Communications Alliance industry code C661:2022 Reducing Scam Calls and Scam SMs, whose clause 4.2.1 reads: “Originating C/CSPs must prevent carriage of calls where the A-Party does not hold Rights of Use to the Number.” The note beneath it carves transit and terminating providers out of validating calls received via call redirection or call forwarding from a B-Party — so a forwarded leg is treated differently from an originated one, and the obligation sits with the originating provider. If you plan to present a number you do not hold rights of use to on an Australian transfer leg, that is a conversation to have with your carrier before launch, not after a block.

Why does my AI agent transfer land on hold music with nobody there?

This is cause 4, it generates the angriest callers, and it is a deadlock rather than an error: the transfer has failed, but the failure never propagates back to the agent, so nothing is ever said and nothing ever ends the call.

Both platforms design against it. Retell’s call transfer node has a pre-populated failure edge you can connect to a node that handles a failed transfer, and its human-detection setting connects the caller only once a human is detected — “The default timeout is 30 seconds.” Vapi’s wait-first warm transfer modes exist for the same reason, with a wait-for-operator timeout that defaults to 60 seconds.

Test for it anyway, on every platform, because the documented design and the observed behaviour can diverge. A report open on Retell’s own community forum since 29 July 2026, and tagged as a bug, describes a warm transfer whose target is classified as voicemail: transfer_call returns unsuccessful, no LLM turn is generated on the caller’s leg, the failure edge is never evaluated, and — in the reporter’s words — “The caller hears on-hold music indefinitely until they hang up.” On 6 August 2026 a Retell staff member replied: “It looks like a bug, and the team is investigating it.” As at 8 September 2026 the thread carries no accepted answer and no further update. We note it because it is a publicly documented instance of a class every buyer should test for, not as a mark against a vendor — Retell is one of the few platforms with a public forum where such a report can be read at all, which is the reason this example exists to cite.

The equivalent on other platforms is documented rather than reported. Vapi’s warm-transfer troubleshooting table lists a wait-first transfer that pauses too long against the cause “The operator or automated system did not produce detectable speech”, with the remedy being a shorter timeout or a non-wait mode. On a Twilio conference bridge the same silence has a different origin: a participant joining a conference that has not started is muted and hears background music until a moderator arrives, and a waitUrl document that runs out of verbs plays silence rather than looping.

The distinguishing test is short. Pull the destination leg from the provider’s call detail records. If no destination leg exists, the transfer never dialled and you are in Cause 1. If a destination leg exists and ended, but the caller’s leg continued on hold audio, you have a failure-path bug and your workaround is a hard ceiling — a maximum hold duration after which the agent speaks and re-offers, rather than waiting on a failure signal that may not arrive.

Cause 5: the transfer connected and the context did not travel

A connected transfer with no context is a telephony success and a commercial failure, and the mechanism is signalling, not prompting. Three constraints decide whether anything arrives with the call:

• The mode decides the channel. Warm transfer delivers context as speech — a fixed message, a generated summary or TwiML played to the destination. Blind transfer delivers it as a header, if at all. A conference bridge delivers nothing in the call path, which is why conference-based routing must be paired with a screen pop.
• Headers survive to SIP endpoints and not reliably to the PSTN. Retell states that custom SIP headers are preserved only when transferring directly to a SIP endpoint and may be stripped when transferring to a PSTN number, and separately warns that a provider may not honour custom headers on a REFER, naming Twilio as one that does not. Twilio’s own <Refer> page allows headers in the target URI but qualifies it — the endpoint has to stamp them.
• Headers have a size ceiling. Retell notes that many SIP parsers and middleboxes assume 1024 bytes is a reasonable maximum for a header line and may reject or truncate longer ones. A generated summary is exactly the kind of variable-length payload that passes in testing and truncates on a talkative caller.

What actually belongs in the packet, and how the receiving human should be handed it, is the conversational-layer question answered in our handoff and context-transfer guide. The telephony rule is narrower: choose the transfer mode that has a context channel before you design the packet, because the mode constrains what can be carried.

The pre-launch transfer test checklist

Almost every team tests the happy path and ships. The rows below the first are the ones that are routinely skipped and that account for most production incidents. Place each call deliberately, and capture the named artefact — an unrecorded test is an opinion.

#	Test call to place	How to force the condition	What to look for	Artefact to capture
1	Happy path, in hours	Trigger the transfer phrase; a human answers within two rings	Destination hears the intended introduction; caller and destination can hear each other; agent drops off cleanly	Call record with ended reason, plus the provider CDR for the destination leg
2	Transfer target busy	Put the target line on an active call from another handset first	The agent speaks a failure message within the ring duration and offers an alternative — never silence	On REFER paths, NotifySipResponseCode 486 and ReferCallStatus busy from the action URL
3	Target’s voicemail answers	Transfer to a mobile that is switched off or set to divert immediately	The caller is not bridged into a voicemail greeting, and the failure path fires; watch specifically for the hold-music deadlock	Full call recording plus the transcript timeline, timed against the configured detection timeout
4	Target rings out unanswered	Nobody picks up for the full configured ring duration	Agent recovers within the timeout you set, not the platform default you never changed	Configured ring duration alongside measured hold duration
5	Caller hangs up mid-transfer	Hang up in the gap between the agent’s last word and the bridge	Both legs terminate; no orphaned destination leg calls your staff member back with dead air	ReferCallStatus canceled, or the conference participant list showing both legs closed
6	Destination is an IVR or auto-attendant	Transfer to a main switchboard number rather than a direct line	Whether the platform can navigate it, or whether the caller is abandoned into a menu	Recording of the destination leg
7	Caller ID override on, then off	Run the identical transfer twice, changing only the displayed caller ID	Whether the transfer succeeds only when presenting your own number — the fastest confirmation of an override problem	Both call records side by side
8	Transfer during high concurrency	Drive concurrent calls to your quota, then trigger transfers	Whether transfers degrade or fail while the account is at its ceiling, and whether your fallback routing engages	Concurrency reading at the moment of the call, plus the ended reason
9	Transfer to a number that blocks unknown callers	Use a destination with call screening or blocking enabled	The failure surfaces to the caller instead of dropping; Vapi’s guide names destination call blocking as a cause of drops after a successful forward	Provider call timeline for the destination leg
10	After-hours and public-holiday routing	Run the same transfer outside business hours	The agent takes a different, correct path rather than transferring into an empty office	Call record with the timestamp in your local time zone

On row 8, be precise about what you are measuring. Retell publishes what happens when inbound traffic hits the ceiling: the caller is transferred to a configured fallback number if one exists, and if there is no fallback, or the fallback transfer itself fails, the call ends with concurrency_limit_reached. Pay-as-you-go workspaces are allocated 20 concurrent calls by default. Vapi allocates 10 concurrent slots by default and states that each call occupies one slot. What we could not locate on either platform is published behaviour for whether the destination leg of a warm transfer consumes a second concurrency slot while both legs are up — we looked at Vapi’s call concurrency page, Retell’s concurrency and limits page and both platforms’ transfer pages. Until a vendor states it, measure it: run the test in row 8 and read your own concurrency counter mid-transfer. Capacity planning for this is the same exercise as scaling from 100 to 10,000 calls a day.

Frequently asked questions

More questions of this kind are answered on our AI sales agent FAQ hub.

Why does my AI agent transfer land on hold music with nobody there?

Because the transfer failed and the failure never reached the agent. The destination leg ends or is classified as voicemail, but no turn is generated on the caller’s leg, so the failure branch is never taken and the hold audio keeps playing. Confirm it by pulling the destination leg from your provider’s call detail records: if a destination leg exists and ended while the caller’s leg continued, it is a failure-path problem, not a routing one. The durable workaround is a maximum hold duration after which the agent speaks regardless.

Does a successful transfer status mean the transfer worked?

No. Vapi states on its blind-transfer page that an assistant-forwarded-call ended reason confirms Vapi initiated the transfer and does not confirm the downstream PBX or provider completed it, and directs you to the provider’s call detail record and SIP signalling as the source of truth. Treat the platform flag as the fork in your diagnosis and the carrier record as the verdict.

Can the person receiving the transfer see the original caller’s number?

Sometimes, and it is a carrier question rather than a platform one. Retell documents that showing the user’s number requires caller ID override support from the telephony provider and that the transfer fails outright where it is unsupported. In the United States, Twilio requires you to pass a CallToken from the parent leg so SHAKEN/STIR attestation survives, and it rejects the call if the caller ID does not match the token. For Australia we could not locate a published equivalent attestation framework, having looked at the ACMA’s phone-scams pages and at the registered industry code; what that code does say is clause 4.2.1 of Communications Alliance industry code C661:2022 Reducing Scam Calls and Scam SMs, which requires originating providers to prevent carriage of calls where the A-Party does not hold rights of use to the number. Check with your carrier before you design around presenting someone else’s number.

Which transfer mode carries the most context?

Warm transfer, because it delivers context as speech that a human hears whether or not any system integration exists. Blind transfer can carry a summary in a SIP header — Vapi uses X-Transfer-Summary — but Retell notes that headers may be stripped when the destination is a PSTN number and that some providers do not honour custom headers on a REFER. A conference bridge carries no context in the audio path at all and must be paired with a screen pop.

How should I test transfers under load before launch?

Drive concurrent calls up to your quota, then trigger transfers and watch what degrades. Retell documents that inbound calls hitting the limit are sent to a configured fallback number, ending with concurrency_limit_reached where no fallback exists or the fallback transfer fails; Vapi provides 10 concurrent slots by default and recommends batching outbound lists into chunks of roughly 50 to 100 numbers run sequentially. Because we could not locate published behaviour from either vendor on whether a warm transfer’s second leg consumes another slot, measure your own concurrency counter during a live transfer rather than assuming.

What single check catches the most transfer failures fastest?

Read the ended reason, then immediately look for a destination leg in the carrier’s records. That one pair separates configuration failures — where no destination leg was ever created, 11 of the 16 documented causes we counted — from network refusals and failure-path deadlocks, and it takes under a minute per call.