VAPI call with dynamic bots ending abruptly on the...
# support
h
Call ids: 0522f192-4902-44cd-a0f7-573ce121e004 - Jan 28, 2025, 8:14 AM 063ebb62-6446-4d47-8a07-1cbfa5158b16 - Jan 28, 2025, 8:17 AM What is happening right now?: VAPI call with dynamic bots ending abruptly on the client side. Because the vapi client ended the call, on the VAPI call back I get the status: customer-ended-call. This is the error we see on the client side: "could not emit" {"action":"error","errorMsg":"Meeting has ended","error":{"type":"no-room","msg":"Exiting meeting because room was deleted","details":"undefined"},"callClientId":"17380810201060.599168343132723"} "Error: Unhandled error. (undefined)\n at c.emit (https://beta.getblue.ai/_next/static/chunks/2992-05c74049ca7d5dfe.js:1:23713)\n at c.emit (https://beta.getblue.ai/_next/static/chunks/2992-05c74049ca7d5dfe.js:1:13989)\n at et. (https://beta.getblue.ai/_next/static/chunks/2992-05c74049ca7d5dfe.js:1:15521)\n at et.emit (https://beta.getblue.ai/_next/static/chunks/54917a0b-6c18f4dad39fb0e5.js:1:12890)\n at et.value (https://beta.getblue.ai/_next/static/chunks/54917a0b-6c18f4dad39fb0e5.js:4:115099)\n at et.value (https://beta.getblue.ai/_next/static/chunks/54917a0b-6c18f4dad39fb0e5.js:4:110251)\n at a (https://beta.getblue.ai/_next/static/chunks/54917a0b-6c18f4dad39fb0e5.js:4:16056)\n at n (https://beta.getblue.ai/_next/static/chunks/766-d103e5897fdda67a.js:11:3570)\n at c (https://beta.getblue.ai/cdn-cgi/scripts/7d0fa10a/cloudflare-static/rocket-loader.min.js:1:9405)\nEnd of stack for Error object" Need help with: I don't know why the meeting room was deleted. I checked the VAPI dashboard to check the logs, however I was not able to identify the root cause. This issue is happening consistently and it is affecting many of our customers. Need help root causing this and fix it. Let me know if you need any further details to debug. Expected behavior: The call should not end abruptly on the client side without the user initiating it.
a
Heyheniousrock Thank you for creating the ticket! A member of our team will reach out to you shortly.
v
You can continue this conversation by mentioning me in the message.
@heniousrock I'm sorry to hear that you're experiencing issues with calls ending abruptly. To assist you further, I would need to check the logs associated with the call IDs you've provided. However, since I don't have direct access to the VAPI dashboard or logs, I recommend the following steps to help you identify and resolve the issue: 1. Review the server logs around the time the calls were disconnected to see if there are any error messages or warnings that could indicate why the meeting room was deleted. 2. Check if there are any patterns or commonalities between the affected calls, such as the same users, devices, network conditions, or specific actions taken during the call. 3. Verify if there have been any recent changes to your system or the VAPI configuration that might be related to the issue. 4. Ensure that your client-side implementation is handling events and errors correctly and that it's not inadvertently triggering the deletion of the meeting room. 5. If you're using a third-party service like Twilio, check their status page and logs for any incidents that could be affecting your calls. If you continue to face difficulties and need more detailed assistance, please reach out to VAPI support with the call IDs, any relevant logs, and a detailed description of the issue. They will be able to provide more specific guidance and help you resolve the problem. In the meantime, if there's anything else I can do to assist you, please let me know.
Got it. Tagging @User for additional help.
h
Here are the Call ids: 0522f192-4902-44cd-a0f7-573ce121e004 - Jan 28, 2025, 8:14 AM 063ebb62-6446-4d47-8a07-1cbfa5158b16 - Jan 28, 2025, 8:17 AM
@Vapi can you give me more context on why I would encounter "Exiting meeting because room was deleted" on the vapi client
v
@heniousrock Certainly! The message "Exiting meeting because room was deleted" suggests that the virtual room or session associated with the ongoing call was terminated or removed unexpectedly. This can happen due to several reasons: 1. **Server-Side Termination**: The server hosting the VAPI service might have programmatically deleted the room due to an internal cleanup process, error, or misconfiguration. 2. **Timeouts**: If the room has been inactive for a certain period, it might be automatically deleted due to timeout settings. 3. **Resource Constraints**: Server resource constraints or policies might lead to early termination of rooms to free up resources. 4. **API Errors**: An error in the API call or callback process might inadvertently trigger the deletion of the room. 5. **Client-Side Issues**: The client application might have sent a request to delete the room due to a bug or a misinterpreted user action. 6. **Operational Policies**: The service might have operational policies that trigger room deletion under certain conditions, such as exceeding a usage limit. 7. **Maintenance or Updates**: Scheduled maintenance or updates to the VAPI service could result in temporary room deletions. To resolve this, you would typically need to check the server logs for the specific call IDs to understand the sequence of events that led to the room being deleted. Additionally, reviewing the configuration of your VAPI service and ensuring that the client-side implementation is correctly handling room lifecycle events is crucial. If you're unable to determine the cause from the logs and configurations, reaching out to VAPI support with detailed information will be the next step to troubleshoot and resolve the issue.
h
@Vapi how do I identify if the "Exiting meeting because room was deleted" issue was from the client side or server side error. Can you provide debugging instructions on this?
@User how do I identify if the "Exiting meeting because room was deleted" issue was from the client side or server side error. Can you provide debugging instructions on this?
@Vapi how do I identify if the "Exiting meeting because room was deleted" issue was from the client side or server side error. Can you provide debugging instructions on this?
v
@heniousrock To identify whether the "Exiting meeting because room was deleted" issue originated from the client side or the server side, you can follow these debugging steps: 1. **Check Server Logs**: Access the server logs for the VAPI service around the time the issue occurred. Look for any error messages, warnings, or actions that indicate the room was deleted. Pay special attention to the logs with the provided call IDs. 2. **Review Client Logs**: Examine the client application logs to see if there were any actions taken by the user or the client application that could have led to the deletion of the room. 3. **Inspect API Calls**: Look at the API call history to see if there were any requests made to delete the room or end the meeting. This can help you determine if the deletion was triggered by an API call. 4. **Analyze Network Traffic**: If possible, analyze the network traffic between the client and the server to see if there were any requests from the client that could have caused the room to be deleted. 5. **Reproduce the Issue**: Attempt to reproduce the issue in a controlled environment. This can help you identify any client-side actions or server-side conditions that lead to the problem. 6. **Check for Configuration Changes**: Review any recent changes to the VAPI configuration or the client application that might have affected the room lifecycle. 7. **Consult Documentation**: Review the VAPI documentation for any known issues or behaviors related to room deletion. 8. **Contact Support**: If you're unable to determine the cause, provide the support team with the call IDs, server logs, client logs, and a description of the issue. They can help you investigate further. Remember to check for any patterns or commonalities among the affected calls, such as specific users, devices, or actions that precede the issue. This can provide valuable clues for troubleshooting.
h
@Vapi could using our own chatgpt provider key cause high latency leading to "Exiting meeting because room was deleted" error
v
@heniousrock Using your own ChatGPT provider key should not directly cause high latency leading to the "Exiting meeting because room was deleted" error. The provider key is typically used for authentication and billing purposes and should not impact the operational aspects of the VAPI service, such as room management and call stability. However, if the integration with ChatGPT involves processing or generating responses in real-time during the call, and if there are significant delays in this process, it could potentially lead to timeouts or unexpected behavior on the client side. This would usually not delete a room but could cause the client to behave as if the call has ended. To determine if latency is an issue, you can: 1. Monitor the response times from the ChatGPT service when using your provider key. 2. Check if there is a correlation between the high latency periods and the instances of the "Exiting meeting because room was deleted" error. 3. Review the client and server-side timeout settings to ensure they are configured to handle any expected delays. If you suspect that latency is contributing to the issue, you may want to optimize the interaction with ChatGPT or adjust the timeout settings accordingly. If the problem persists, reaching out to the support team with specific details about the latency and its impact on the service would be advisable.
h
@Vapi in the logs I noticed that the turn latency is around 1200 - 2000 ms. Will this cause "Exiting meeting because room was deleted" error.
v
@heniousrock A TURN (Traversal Using Relays around NAT) server latency of 1200 - 2000 ms is quite high and could potentially contribute to issues during a voice or video call session. TURN servers are used to relay traffic between clients when they are unable to communicate directly due to NAT or firewall restrictions. While high TURN latency itself does not directly cause a room to be deleted, it can lead to a poor user experience, including delays in audio/video transmission, which might trigger timeouts or cause the client application to think the connection has been lost. If the client or server interprets this as a call ending condition, it could lead to the room being closed prematurely. To address high TURN latency: 1. **Optimize Network Connectivity**: Ensure that the TURN servers are geographically close to the users or distributed in a way that minimizes latency. 2. **Load Balancing**: Implement load balancing to distribute traffic evenly across multiple TURN servers. 3. **TURN Server Performance**: Check the performance and capacity of the TURN servers to handle the traffic. 4. **Client-Side Handling**: Ensure that the client application has robust handling for network latency and does not prematurely end the call or delete the room. 5. **Server Configuration**: Review server-side timeout settings and adjust them to accommodate higher latencies. If adjusting these factors does not resolve the issue, you may need to investigate further or consult with the support team for the TURN service or VAPI to determine the best course of action.
s
@heniousrock Please join today's office hours will resolve it over there because I need to look into your dashboard and other things what's going wrong for you https://discord.gg/amX87g6K?event=1333839871458152598
h
Sure, I am on the office hours right now
@Shubham Bajaj were you able to take a look at the issue?
s
@heniousrock Call ID: 0522f192-4902-44cd-a0f7-573ce121e004 What transpired in this situation is that when the Assistant inquired about your approach to handling errors, you provided a response that was subsequently segmented into smaller parts. The model/LLM was then re-engaged, resulting in the generation of output that did not reach you. This occurred because the endpointing model, which determines whether the user is still speaking, indicated that you were indeed speaking. Consequently, when you concluded your remarks, the call was unexpectedly terminated. Furthermore, even after you had finished speaking, there was an additional request made to the LLM. This scenario primarily involves the endpointing process, which assesses when the user has finished speaking, along with related models for continuing the conversation. However, the customer’s call was abruptly disconnected due to network issues and websocket connections. As illustrated in the log below, the system identified your input (user) and, unexpectedly, closed the websocket connection, leading to the termination of the call.
🔵 16:16:29:612 Process
send
Requested End Call. 🔵 16:16:29:612 Process `send`'s Stream
stdout
Data: end-call 🔵 16:16:29:567 Process `receive`'s Stream
stderr
Data: {"timestamp":"2025-01-28T16:16:29.567676Z","level":"ERROR","fields":{"message":"Failed to close consumer: ConsumerNoLongerExists(ConsumerId(\"6bacf88c-ab26-49d7-946f-27bdcaf5ced0\"))"},"target":"daily_core::call_manager::events::subscription::common"} 🔵 16:16:29:504 Process `receive`'s Stream
stderr
Data: {"timestamp":"2025-01-28T16:16:29.503791Z","level":"ERROR","fields":{"message":"no subscription for consumer: ConsumerId(\"6bacf88c-ab26-49d7-946f-27bdcaf5ced0\")"},"target":"daily_core::call_manager::events::from_sfu::soup_consumer_closed"} 🔵 16:16:29:376 [non-user CHECKPOINT] Reached language detection Buffer 🔵 16:16:29:363 [user LOG] Endpointing timeout 500ms (rule:
heuristic
)
@heniousrock Call ID:063ebb62-6446-4d47-8a07-1cbfa5158b16 🔵 16:19:27:871 Voice Input Formatted: "I'm not comfortable divulging specific details about our current systems over the phone.", Original: "I'm not comfortable divulging specific details about our current systems over the phone." 🔵 16:19:28:050 ElevenLabs (Websocket #21) Pushing 91... "Can you clarify how Rippling offers better value compared to optimizing our existing tools?" 🔵 16:19:28:262 Bot started speaking 🔵 16:19:29:214
assistant
Partial Transcript : I'm not comfortable: 0.9970703 🔵 16:19:29:417 Process `receive`'s Stream
stderr
Data: {"timestamp":"2025-01-28T16:19:29.417390Z","level":"ERROR","fields":{"message":"no subscription for consumer: ConsumerId(\"878cf1f8-4e3a-4cf7-a6fb-094800a49b9a\")"},"target":"daily_core::call_manager::events::from_sfu::soup_consumer_closed"} 🔵 16:19:29:448 Process `send`'s Stream
stdout
Data: end-call 🔵 16:19:29:449 Process
send
Requested End Call. 🔵 16:19:29:449 Live Call Manager Ending...(customer-ended-call)
Essentially, the ended_reason is accurate in this context, as the underlying process has transmitted a signal to the client-side process indicating no_subscription. This, in turn, caused the client-side process (web-protocol) to initiate the call hangup signal or close the websocket, leading to the calls being concluded with the reason** "customer-ended-call".**
@heniousrock I require your help with the following. The next steps: - What's the frequency of calls terminating like this? - Ensuring there are no random, network issues or race conditions.
*FYI For Everyone: * A media stream (audio/video) was expected to exist, but it was already removed. Which means Ensure media consumers don’t drop unexpectedly is responsibility of the underlying tech.
@heniousrock a gentle reminder to continue this thread.
@heniousrock because of no response closing this ticket.
27 Views