Issue while transferring and getting a new "response_required" afterwards

Support Help
1

Hi everyone,
On a previous ticket I opened regarding an unsuccessful call transfer (A call transfer was not done, but we sent the transfer - #2 by mark1), you recommended the following:

"Team traced call_631e600e9057d627b3e1368ba84 against the public log and the custom-LLM handler. The transfer was lost due to a timing race in the response stream. Recommended fix on your custom LLM (api.getpuppeteer.ai/llm-websocket): Emit transfer_number earlier in the stream — ideally on the very first content chunk of the transfer response, or on a frame that also carries content. Don’t put it only on a trailing empty frame after a long farewell sentence.
Keep the farewell preceding the transfer short (or omit it). The longer TTS plays after transfer_number is captured, the larger the window for a turn flip + new response_required to wipe out the pending transfer."

We implemented the recommended fixes and shortened the farewell preceding the transfer as much as possible. However, the issue happened again in this call: call_1510ed34ce6ef154c71b0e64544. We received a response_required event right after sending the transfer.

Since we have already shortened the farewell as much as we can, should we re-send the transfer_number in subsequent turns if a new response_required event is triggered?

Ideally, once a transfer_number is sent, we would like the transfer to be executed as soon as possible and not remain susceptible to being overridden or cleared by a subsequent caller utterance that triggers a new response_required event.

2

Hey @emilia I have escalated this Call ID to the Team for Review. Best Regards

3

Hey @emilia

On call_1510ed34ce6ef154c71b0e64544: the LLM emitted transfer_number on response 14 at 16:05:44, but the caller said “Right.” during the farewell TTS at 16:05:49. That barge-in cancelled response 14, dropping the pending transfer, and we issued response_required 15. Your LLM’s response 15 didn’t include transfer_number, so no transfer dispatched.

You can try to set no_interruption_allowed: true on the same response frame that carries transfer_number. This pins interruption_sensitivity=0 for that response, so caller barge-in during the farewell won’t cancel it, and the transfer fires on agent-done-speaking as intended.

To answer your question - yes, re-emitting transfer_number on the next response_required will also work (no guard blocks it).

Docs: https://docs.retellai.com/build/custom-llm - see the ‘response’ event schema for ‘no_interruption_allowed’ and ‘transfer_number’.

Thank You