Server-initiated terminations

Support Help
1

Hello Retell team,

We run long-form AI investor interviews. A recent review surfaced two problems we need help with: a set of server-side kills of healthy calls, and chronic LLM first-token latency across the whole account.

Server-initiated terminations (13 calls)

  1. Call_bec71bfdeaac81f2d9e6627a5b5 | error_retell

  2. Call_83f85c5bf24891931e63d8eb0f0 | error_retell

  3. Call_0dd36dba731989595eadf3f8a9e | error_retell

  4. Call_3f5aff18f0e9ce87e4a3558f0d9 | error_retell

  5. Call_0d67b2f1a3648b60a6b5797e09b | error_asr

  6. Call_6db60684b8bd8e3d41450529b64 | error_no_audio_received

  7. Call_d884cdabb6cb2b7ce66ca9a3ed2 | error_no_audio_received

  8. Call_ebe2c5c794f4bc49b0c64473e54 | error_no_audio_received

  9. Call_7d06b5ddf99a874651c222daccb | error_no_audio_received

  10. Call_78c07247297dd0ec3645ab677dd | error_no_audio_received

  11. Call_8a5dc70595e031b326488b983fa | error_no_audio_received

  12. Call_36ab183911f305a13e600152120 | error_no_audio_received

  13. Call_45cd7a2fa59cdee2ca145cf5f3f | error_no_audio_received

These server-side kills — both the error_retell and the error_no_audio_received — are huge issues for us. We pay hundreds of dollars per call, and when these errors occur on hour-long calls, we lose extremely valuable transcripts. It is also a poor experience for our experts. What makes matters worse is that these calls are terminated with no proximate error in the debug log. The log simply shows “Ending call” while inbound audio and ASR were demonstrably alive (we can hear the people still talking).

The pattern (e.g., generic error_retell, >60 minutes, large context, clean logs) looks like an internal long-call failure mode. What is the actual kill mechanism here, and is there a context-size or duration limit we are hitting that we should design around?

The other calls seem to close due to a variety of ASR issues, be it escalating latency, disconnects with no opportunity for reconnection, or overly aggressive kill features.

What we’re asking for:

  1. Root cause can you please provide the root cause of the errors we’ve experienced so we can at least understand the issues

  2. Transcript recovery is there a path to trigger a correctly configured webhook payload, since often these errors mean nothing fires.

  3. Configuration guidance are there configuration setting we should be aware of to avoid issues at calls of this length / token count

  4. Roadmap: (a) a reconnect/grace path when inbound audio dies — let the client rejoin the same call instead of a hard kill ~60s later; (b) public web-SDK APIs for room/device/reconnect events and a supported mic-restart method — we regularly observe live-but-silent mic tracks on web calls and currently have no supported way to recover them.

2

Hello @adam I’m checking this with the team and will get back to you as soon as I have an update.

Thank You