a
@Vapi
v
@anw Hello! How can I assist you today with VAPI? If you have any questions or need support with voice development, feel free to ask!
a
is it possible to inject an instruction during a live vapi call? for example ask the agent to summarize and end the conversation @Vapi
v
@anw Yes, it is possible to inject instructions during a live VAPI call. You can send commands to the agent through your server endpoint that VAPI will hit during the call. If you want the agent to summarize and end the conversation, you would typically send a specific instruction that your voice application is programmed to recognize and act upon. For example, you might send a command like
{"action": "summarize_and_end_call"}
to your endpoint, and your voice application would interpret this and instruct the agent accordingly. If you need to set this up or have any specific questions on how to implement this, please let me know, and I can assist you further!
a
@Vapi what would be best way to constantly ttrack a vapi call for elapsted time? conversaiton-update?
v
@anw To constantly track the elapsed time of a VAPI call, you can use the
conversation-update
event to receive periodic updates about the call state. This event can be configured to trigger at regular intervals, providing you with the information you need to calculate the elapsed time. Here's a general approach to track the elapsed time: 1. Start a timer when the
call-start
event is triggered. 2. Receive
conversation-update
events at defined intervals. 3. Calculate the elapsed time based on the timestamps from these updates. 4. Stop the timer when the
call-end
event is triggered. By using the timestamps provided in each
conversation-update
event, you can keep an accurate track of how long the call has been active. If you need more detailed instructions or help with implementation, please let me know!
a
@Vapi would this be too heavy for a next.js webapplication to constantly process the conversation updates or nah
v
@anw Processing conversation updates in a Next.js web application should generally not be too heavy, as long as the updates are handled efficiently. Modern web applications, including those built with Next.js, are quite capable of handling real-time updates, especially if the frequency of updates is reasonable and the processing for each update is not computationally intensive. Here are a few tips to ensure smooth performance: 1. Optimize Update Frequency: Only request updates at a frequency that is necessary for your application. For example, if you only need to display elapsed time to the minute, you don't need updates every second. 2. Efficient State Management: Use efficient state management to handle updates. For example, React's useState or useReducer hooks can help manage state without unnecessary re-renders. 3. WebSockets or Server-Sent Events: Consider using WebSockets or Server-Sent Events (SSE) for a persistent connection that can handle real-time data efficiently. 4. Throttling or Debouncing: If updates can potentially happen very frequently, use throttling or debouncing techniques to limit the number of times your update handling function is called. 5. Background Processing: If heavy computation is needed, consider offloading it to a Web Worker or server-side API to avoid blocking the main thread. 6. Monitor Performance: Use performance monitoring tools to keep an eye on the application's resource usage and optimize as needed. If you notice performance issues, you may need to profile your application and optimize the parts of your code that handle the conversation updates. However, for most use cases, handling conversation updates should be well within the capabilities of a Next.js application. If you have specific concerns or a unique use case, please provide more details, and I can offer more tailored advice.
a
@Chowderr yeah but is it system instruction or user
@Vapi whats best way to track the duration of a call during the live call?
@Vapi is it better to take from seconds_since_start or use your timer thing
v
@anw The best way to track the duration of a live call would typically be to use the
seconds_since_start
parameter provided by VAPI's
conversation-update
event or similar call control features. This parameter gives you the elapsed time directly from the call control system, which ensures accuracy as it is based on the call platform's own timing mechanisms. Using
seconds_since_start
has several advantages: 1. Accuracy: It is calculated by the call control system, which means it should accurately reflect the call's duration without being affected by any latency or discrepancies that might occur in your application. 2. Simplicity: It eliminates the need for you to implement your own timer logic, which simplifies your application code. 3. Reliability: It is less prone to errors that might occur if the application's timer is not started or stopped correctly. In summary, leveraging the
seconds_since_start
provided by VAPI is generally the better and more reliable approach for tracking call duration during a live call. If you need further assistance or have more questions, feel free to ask!
c
Did you try it out?
a
@Chowderr im gonna try rn, to calculate time through seconds_since_start
if you want a easier way you can use duration in end-of-call report but i need my webapp to deduct seconds from user account real tiem
@Vapi while injecting in controlurl get this: Error details: {"error":"[\n \"property instruction should not exist\",\n \"type must be one of the following values: add-message, control, say, transfer, transcriber-response\"\n]"} can you explain each one please
v
@anw Certainly! The error message you're seeing indicates that the payload you sent to the control URL contains an invalid property (
instruction
) and that the
type
property must be one of the specified values. Here's an explanation of each valid
type
value you can use: 1. **add-message**: This action allows you to add a text message to the call. It could be used for various purposes, such as displaying a message to an agent or logging a message for the call. 2. **control**: This action is used to control the call flow. It can include commands like hang up, mute, hold, etc. It's a way to programmatically manage the call state. 3. **say**: This action instructs the VAPI to play a text-to-speech message to the participants of the call. You can specify the message and various attributes like language, voice, and volume. 4. **transfer**: This action is used to transfer the call to another recipient. This could be another phone number or a SIP address. You can also specify additional parameters for the transfer, such as the method of transfer and any contextual information to pass along. 5. **transcriber-response**: This action is typically used in conjunction with a transcribing service. It allows you to handle the response from a transcriber, which could include the transcribed text of the call or parts of the call. To resolve the error, you need to remove the
instruction
property from your payload and ensure that the
type
property is set to one of the valid values listed above. If you're trying to send a specific command or action, make sure it aligns with the available
type
options and the structure expected by the VAPI. If you need further clarification or assistance with constructing the correct payload, please let me know!
a
finally u help me mfer ❤️
@Vapi how to make the inbound number only for overflow calls?
v
@anw To configure an inbound number to handle only overflow calls, you would typically set up call routing logic within your telephony system or contact center software. Here's a general approach to achieve this: 1. **Primary Queue Configuration**: Set up your primary call queue(s) to handle incoming calls. This is where calls will be directed initially. 2. **Overflow Criteria**: Define the criteria for overflow calls. This could be based on the number of calls waiting, the wait time in the queue, or agent availability. 3. **Inbound Number Setup**: Configure the inbound number that you want to use for overflow calls. This number will act as a secondary line for excess calls that meet the overflow criteria. 4. **Routing Logic**: Implement routing logic in your telephony system that redirects calls to the overflow inbound number when the primary queue(s) meet the overflow criteria. This logic can often be configured directly in your contact center software or through a custom application that interfaces with your telephony system's API. 5. **Fallback Options**: Ensure there are fallback options in place in case the overflow number also reaches capacity. This could involve voicemail, additional overflow numbers, or a message informing callers of high call volumes. 6. **Monitoring and Adjustment**: Regularly monitor the performance of your call queues and adjust the overflow criteria as necessary to ensure that calls are being handled efficiently. If you're using a specific telephony or contact center platform, you may need to consult the platform's documentation or support to understand the exact steps and features available to set up overflow handling. Each system may have its own method for configuring these settings. If you need more detailed instructions or have specific questions about your setup, please provide additional details about your telephony system, and I can offer more tailored advice.
a
@Vapi how many cocnurrent calls can one agent handle? 9 right?
v
@anw Typically, an agent can only handle one call at a time effectively, as they need to be fully engaged with the caller to provide quality service. The idea of an agent handling multiple concurrent calls is not practical in a standard customer service scenario. However, in certain contexts like call monitoring, barge-in, or whisper coaching, a supervisor might be able to listen in on multiple calls at once, but even then, they would not be actively handling all those calls simultaneously. The number you're referring to, such as "9 concurrent calls," might be related to a specific system's capability or a configuration limit rather than an agent's ability to handle calls. For example, a phone system might allow an agent to have up to 9 lines that they can switch between, but this does not mean they can effectively manage 9 conversations at the same time. If you're referring to a specific system's limitation or a feature within VAPI, please provide more context or check the system's documentation for accurate information. If you have a different scenario in mind, please clarify so I can provide a more precise answer.
a
@Vapi i mean how many calls can one assistant handle. like can the same assistant id handle 9 inbound calls?
v
@anw The number of concurrent calls an assistant can handle typically depends on the capabilities of the underlying infrastructure and the specific configuration of the VAPI platform you're using. There isn't a universal limit like "9 inbound calls" for an assistant; it can vary based on the service provider's resources and how the assistant is designed. In many cases, a single assistant ID can handle multiple concurrent calls because the assistant is essentially a software entity that can be scaled to handle a high volume of interactions simultaneously. The actual limit can be quite high, subject to the performance of the servers and the network. For precise limitations and capabilities, you should refer to the documentation of the VAPI platform you're using or contact their support. They can provide you with the exact numbers and any potential costs associated with scaling to handle multiple concurrent calls. If you're planning to handle a high volume of concurrent calls, it's important to ensure that your assistant and the backend infrastructure are optimized for such load to maintain performance and reliability.
c
ot sure what is confusing but the limit is 10........does not matter howmany assistants you he. Its straightforward as can be.
a
@Chowderr whats hte limit though?
c
Your not listening, the limit is 10 and always has been from day UNLESS you buy more.
2 Views