We’re using Conversation Flow transfer nodes with transfer_option.type: “warm_transfer” and a private_handoff_option (prompt-based whisper). Our suppliers are Japanese hotels, so we set opt_out_human_detection: true specifically so the whisper to staff starts directly in Japanese, rather than the agent first playing the English “Hello, is anyone there?” detection probe.
We hit a problem where a transfer to a human front-desk staff member failed to bridge.
Reference call: call_93ce6866035678b2c7d299bec04
What happened (from the transcript/timeline):
Agent dialed the front desk; the leg connected and the Japanese whisper played correctly (~57–72s).
A real human at the front desk answered and spoke clearly multiple times — e.g. “Is this about a reservation?” and “Is the call connected?” (~74–93s).
Despite the human being on the line, the warm transfer never bridged the caller. The flow took the “Transfer failed” edge, moved to our Farewell node, and the agent hung up — abandoning both the caller and the front desk (disconnection_reason: agent_hangup).
Importantly, the fact that the transfer ended in the “Transfer failed” state is itself the evidence that human detection failed — a real human answered and spoke, yet the transfer was treated
as failed/unanswered. It appears that opting out of human detection also removes the signal Retell uses to confirm a human answered and proceed with bridging the caller — so the transfer can’t complete even on a successful human pickup, not just on voicemail.
Our questions:
With opt_out_human_detection: true, what is the intended mechanism for a warm transfer to bridge the caller after the whisper? Why would it fall through to “Transfer failed” here when a human clearly answered?
Is there a way to keep human detection enabled but configure the detection probe / prompt language (e.g. Japanese) so we get reliable bridging and avoid the English probe?
For our scenario (warm transfer to non-English-speaking human staff, whisper must be in the supplier’s language), what configuration do you recommend?
Hello @andrew3 Thanks for the detailed write-up — that’s an unusually clean repro. Confirmed root cause on call_93ce6866035678b2c7d299bec04:
The bridge branch fired correctly — opt_out_human_detection: true arrived at the orchestrator, the Japanese whisper played, and the destination human was on the line. The failure was on our side: the LiveKit room-service RPC that swaps the destination participant into the caller’s room (moveParticipant) returned Service Unavailable / no response from servers at ~t=74s. Our orchestrator caught that exception and returned a generic failureReason: "Call connected but no human response detected." to the flow — which is misleading: with opt_out_human_detection=true, no human-detection is actually attempted, so that string can only ever come from a caught bridge-step exception (in this call, the LiveKit RPC). That’s why the “Transfer failed” edge fired despite a human clearly being on the line.
Two follow-ups on our side:
We’re filing an internal bug to (a) replace the overloaded failureReason string with the real underlying error so this kind of failure is diagnosable from the transcript alone, and (b) evaluate adding a single retry on transient LiveKit moveParticipant failures so a one-off blip doesn’t burn a real call.
The destination number itself is fine — the caller redialed 2 minutes later and that warm transfer bridged successfully (call_c3b4e878bffab9d0c460d38188d). No action needed on your trunk/PBX or your opt_out_human_detection config.
Nothing for you to change on the agent. We’ll follow up with engineering and circle back when the fix is in.
Hi Team,
I have a call (call_2635a395b9b6605d01c9f2a022d) where the transfer target agent responded (in english) at timestamp 3:03 for the question “Hello, is anyone there?”, but it still got the error immediately:
tool_call_id: 6b815ab21de83b35
{"status":"Call connected but no human response detected.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly."}
Hello @parth Thanks for flagging this and for the detailed call example.
For call_2635a395b9b6605d01c9f2a022d, this wasn’t a LiveKit / bridge failure. On this agent’s LLM config, opt_out_human_detection is not set on the transfer_call tool, so it defaults to false and human detection ran.
On attempt #1, Zach’s greeting wording felt a bit robotic; detection never passed, and we returned the generic “no human response detected” message. The second attempt had a clean greeting, detection passed, and the bridge succeeded.
If you’d prefer the whisper to fire immediately after SIP answer without waiting for detectable speech, you can set opt_out_human_detection: true on the transfer option for this agent. The tradeoff is that IVRs/voicemail will also receive the whisper since we’ll skip detection.