# Warm transfer with opt\_out\_human\_detection — bridge fails even when a human answers

**URL:** <https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997>\
**Category:** Support Help\
**Tags:** bug\
**Created:** [June 5, 2026, 1:58am UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997 "2026-06-05T01:58:12Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![andrew3](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/andrew3/32/1713_2.png) [@andrew3](https://community.retellai.com/u/andrew3)\
**Post date:** [June 5, 2026, 1:58am UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997/1 "2026-06-05T01:58:12Z")

</div>

Hi,

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):

1. Agent dialed the front desk; the leg connected and the Japanese whisper played correctly (~57–72s).
2. 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).
3. 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:

1. 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?
2. 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?
3. For our scenario (warm transfer to non-English-speaking human staff, whisper must be in the supplier’s language), what configuration do you recommend?

Thanks!

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [June 5, 2026, 12:46pm UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997/2 "2026-06-05T12:46:52Z")

</div>

Hi @andrew3 Checking with the team.

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [June 6, 2026, 11:41am UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997/3 "2026-06-06T11:41:12Z")

</div>

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:

1. 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.
2. 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.

Thank You

---

<div class="post-metadata">

**Author:** ![andrew3](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/andrew3/32/1713_2.png) [@andrew3](https://community.retellai.com/u/andrew3)\
**Post date:** [June 8, 2026, 1:50am UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997/4 "2026-06-08T01:50:17Z")

</div>

Hi Shaw,

Thanks for the details. Hopefully, the retry increases reliability.

Andrew

---

<div class="post-metadata">

**Author:** ![parth](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/parth/32/2114_2.png) [@parth](https://community.retellai.com/u/parth)\
**Post date:** [June 11, 2026, 10:42pm UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997/5 "2026-06-11T22:42:30Z")

</div>

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:

```auto
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."}  

```

Is this also a LiveKit failure?

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [June 12, 2026, 1:45pm UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997/6 "2026-06-12T13:45:00Z")

</div>

Hey @parth Checking your call ID with the team.

---

<div class="post-metadata">

**Author:** ![Shah-Fazal](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/shah-fazal/32/2522_2.png) [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)\
**Post date:** [June 12, 2026, 5:18pm UTC](https://community.retellai.com/t/warm-transfer-with-opt-out-human-detection-bridge-fails-even-when-a-human-answers/2997/7 "2026-06-12T17:18:57Z")

</div>

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.

Thank You