Initial delay
# support
a
There seems to be an initil delay, for the first response after the assistant is supposed to answer the first time. Is there anyone way to improve this or mitigate or improve it ? Example - call id: e21f4a75-dda6-4d2b-8079-6aa93b1d9c6c But its like this at every call.
v
message has been deleted
@Amanski I'm sorry to hear that you're experiencing a delay in the initial response. Delays can be caused by various factors, including network latency, server processing time, or the complexity of the initial setup for the call. To address this issue, you might want to consider the following steps: 1. **Optimize Network Connectivity**: Ensure that the server hosting the VAPI is geographically close to your user base or uses a content delivery network (CDN) to reduce latency. 2. **Server Performance**: Check if the server has adequate resources to handle the load and optimize the server's performance. 3. **Code Optimization**: Review the initialization code for any inefficiencies that could be causing the delay. 4. **Caching**: Implement caching strategies for frequently accessed data to reduce load times. 5. **Concurrent Processing**: If possible, use asynchronous or concurrent processing to handle initial setup tasks without blocking the response. 6. **Monitoring Tools**: Utilize monitoring tools to identify bottlenecks and performance issues in real-time. If you've already tried these steps and the issue persists, it might be beneficial to look into the specific details of the call ID you provided. However, as a support bot, I don't have direct access to call logs or the ability to make changes to the system. Please ask support for more info on this, and they can provide a more detailed analysis and assistance to resolve the issue.
You can continue this conversation by mentioning me in the message.
a
The calls coming straight from VAPI, through twilio. So it is not really my code running it.
For example, 12 seconds wait time after initial response. Call id: 3a3266c4-10ce-4827-a4fb-2286f95176c0
s
Hey @Amanski can you try another call with smartEndpointingEnabled set to false, and using other properties as per your requirements. Most likely the smart endpointing model couldn't identify the user has stopped speaking and then you observed glitch in 2nd turn. Do let me know how it goes. https://cdn.discordapp.com/attachments/1307839903207526533/1308359607479042048/Screenshot_2024-11-19_at_2.42.50_PM.png?ex=673da856&is=673c56d6&hm=55e97aae6f4c21402f9e5ad48539f84da2c11f53f7597a5f5a28266074c9a7f9&
a
I just turned on smartEndpointing yesterday, to try to improve. And its worse with smart endpointing yes.
I can share some call ids without it.
s
To help track down this issue, could you share: - The call ID - When exactly this happened (the timestamp) - What response you expected to get - What response you actually got instead This would really help me figure out what went wrong! @Amanski please create a new ticket and share in the above format.
@Amanski also do let me know If I can close this ticket.
3 Views