Hey team 👋 We’re investigating intermittent inbound PSTN call drops (~27–30 seconds in). The caller did not hang up although the ended-reason is named "customer ended call" ?! Details (example, but I have MANY examples, it's ~1 out of 8-10 calls): - Vapi Call ID: 019c9eb1-da84-7991-8bcb-b0e3961a01e9 - Conversation UUID (Vonage): CON-7170e673-da94-473e-84f3-0407fe60a76d - WS endpoint: phone-call-websocket.aws-us-west-2-backend-production-weekly1.vapi.ai - Vonage saw hangup request from IP 18.246.16.191 Transport: PSTN via Vonage Vonage support confirmed that at ~30s they receive an authenticated PUT /v1/calls/{uuid} (UpdateCall hangup) using our Voice API JWT. We are not issuing this request ourselves. Questions: - Under what conditions would Vapi send an UpdateCall to terminate a Vonage call? - Could this be triggered by: - WebSocket/media watchdog? - Server URL webhook timeout? - Internal transport health logic? Is there a way to see WS close reason / teardown reason internally? Any guidance appreciated 🙏

Thanks for sharing the logs, that helps a lot. If Vonage got an authenticated UpdateCall hangup from Vapi, something upstream is intentionally closing the call, not a random drop. Around 30s usually points to a WebSocket/media timeout or a slow webhook response. Are you seeing any WS disconnects, missed heartbeats, or delayed server responses right before the calls end? @Jeebs from eva.be

@James Christopher here's the answer from Vonage : "We are not seeing anything showing a failure from the WebSocket connection to Vonage. If this was the case, the WebSocket would have been terminated from Vonage's side and the PSTN call would have then been terminated, without the need for an API request."

That’s a strong signal, if Vonage didn’t drop the WebSocket and only ended the call after an authenticated UpdateCall, then the termination is likely coming from the Vapi side. The consistent ~30s timing points to a timeout (silence detection, webhook delay, agent error, or watchdog logic). I’d match the hangup timestamp with Vapi logs and check for errors or slow responses right before it ends. Are all these calls using the same agent config or server URL? @Jeebs from eva.be

@James Christopher it is still happening, I can provide with more call ids. Looping @User here as well. For example, this call was "interrupted abruptly" after 29seconds: 019cb8be-4fc5-7113-a89f-320034c70ec4. It's not the customer, it's the same problem (I have many others). Now, a few observations : - Right after, the customer called back (call id 019cb8bf-1a62-7005-9418-ad35cedbc517) without issue... - Somewhere in the middle, a call failed (call id 019cb8be-3c2d-7220-90a8-8dc7f094c9ba) because of "Call.in progress.error providerfault transport never connected", but that didn't impact anything apparently ?

Hi, Please see the answers below: 1. When would Vapi send an

UpdateCall

? An

UpdateCall

is sent during the call cleanup process. If the call worker detects that the WebSocket connection has closed, it triggers cleanup and sends a PUT hangup request to Vonage to terminate the call. 2. Could this be caused by WebSocket/media watchdog, webhook timeout, or transport health checks? No. These have been ruled out: • The proxy timeout (15s) was not the cause, as the worker initialized in under 1 second. • The 30-second silence timeout was also not the trigger, since it was being continuously reset during the conversation. Based on the logs, the WebSocket leg appears to be closed by the Vonage platform, which then triggers the cleanup flow. 3. Can we see the WebSocket close reason internally? Currently, we only log the WebSocket

readyState

, not the close code or reason. Adding logging for the close code/reason is one of the improvements we’re planning to make to improve debugging in cases like this. Best regards, Oshi Raghav Customer Support Vapi

@Oshi Raghav thanks again for reviewing this. I believe I’ve partially identified the root cause. The issue seems to occur only when my backend takes ~4–6 seconds to respond to the assistant-request server message. What I observe in that case is the following: 1. After roughly 4–5 seconds, Vapi sends a second assistant-request message, but with a new callId. 2. I’m not sure whether this is triggered by a Vonage retry, or a Vapi retry mechanism when the assistant is not created quickly enough. Once the call eventually connects, there seems to be some confusion downstream (possibly at the websocket layer or at the model provider level), and the call consistently terminates after ~27–31 seconds. For now I’ve mitigated the problem by ensuring my backend responds to assistant-request in <4 seconds, which seems to prevent the issue entirely. However, I’d really like to understand the intended behavior here: - Is Vapi expected to resend assistant-request if the backend response is slow? - If so, should it reuse the same callId rather than creating a new one? - Is there an idempotency mechanism we should implement on our side to handle this safely? Understanding the retry logic here would really help make our integration more robust. Thanks!

Hi, Please try the following recommendations: • Keep Response Time < 4 seconds: Ensure that you respond to the

assistant-request

within 4 seconds to avoid a Vonage timeout. • Implement Idempotency: If possible, implement idempotency on your backend using Vonage’s

conversation_uuid

as the idempotency key. This helps prevent duplicate processing if retries occur. • Cache Responses: Consider caching assistant configurations on your side to reduce response time and improve reliability.