I’m currently building a custom transcriber using the Deepgram SDK, and we’ve been experiencing an issue where the WebSocket connection unexpectedly closes with the endedReason = silence timeout. This has happened in multiple calls, including the following examples: • Call ID: 6eb7d45e-7db2-4064-81a4-817671875b01 • Call ID: d046a7e7-9275-40d8-8216-a4b9adb87b77 We suspect that the issue might be related to the connection with Deepgram because the WebSocket is closing while the customer is still speaking. Since no more data reaches the transcriber after this point, the call ends with a silence timeout. We would appreciate your help reviewing your logs to confirm whether this behavior is being triggered by Vapi or if it might be caused by the Deepgram connection. Additionally, we would like to better understand how Vapi’s backoff plan works. Specifically: • How does Vapi detect that the transcriber has been disconnected? • What information or signals are required from our side to ensure proper reconnection behavior? Thank you in advance for your support — any guidance or recommendations you can provide will be very helpful. Best regards, Vinicio from Aivora Solutions

Thank you for the detailed context. To help narrow down the cause of the silence timeout, could you clarify whether your server logs show any errors or dropped connections from Deepgram or the WebSocket at the exact moment the silence timeout occurs? This information will help determine if the issue is on the Deepgram side, your custom transcriber, or Vapi's handling of the connection. If you can share any relevant log snippets (with timestamps), that would be very helpful for further troubleshooting. Source: - [Vapi Custom Transcriber Documentation](https://docs.vapi.ai/customization/custom-transcriber)

Vinicio. From what you described, it sounds like the silence timeout is happening because no audio is reaching Deepgram once the socket closes. I can help you check whether Vapi is ending the stream or if the drop is coming from Deepgram’s side. Quick question: on your end, do you see any error or disconnect event right before the silence timeout kicks in? That info will make it easier to narrow down what’s causing the cutoff.

😅