Dear , On outbound calls, the assistant should start speaking only after the client answers, but right now it speaks while the phone is still ringing. Even with a long first message, the client often hears only part of it or just the end. If the client answers late, the silence timeout kicks in and plays its message first — without waiting for a response, ending the call. I’ve tried all possible API configurations. There needs to be proper answer detection before the assistant begins talking on outbound calls. I'm open to provide any example needed but I believe I explained the core concept. I appreciate any help on this

It appears you're experiencing an issue with Vapi's Answering Machine Detection (AMD) feature. Vapi does have answer detection capabilities designed to determine if a call is answered by a person or machine, but it may need proper configuration for your outbound calls. Consider reviewing your AMD settings, as this is specifically designed to address the issue you're experiencing where the assistant speaks before the human recipient answers.

Thanks, but I'm not trying to detect answering machines. I'm simply trying to make sure the assistant doesn't speak until a human answers the outbound call, regardless of whether it's a person or a machine. Right now, the assistant starts talking while the call is still ringing, which causes the first message to be cut off or missed entirely. I’ve already explored the AMD settings, but this seems to be a more basic issue of not waiting for the call to be answered before speaking.

Hey! To help track down this issue, could you share: - The call ID This would really help us figure out what went wrong!

Sure, there are bunch of examples but I just initiated a call to show you this: In this call I immediately responded with "This is my first response." once I answered the call. but the AI already started speaking while it was ringing you can check the transcribtion: "AI: Hello, Shahab. This is Adam from Home Leader Realty. Just reaching out to update your profile regarding your real estate needs. Are you thinking of buying a property?" here is the call ID: 4063848e-10d9-459e-a32e-2b51455c454e This applies to all outgoing calls. Please note that the "assistant-waits-for-user" option is not applicable in this scenario. For example, even if the client answers on the first ring and remains silent, the assistant continues to wait for a response for the full duration of silenceTimeoutSeconds. If we set a lower value for silenceTimeoutSeconds, the call may end prematurely. For instance, if the assistant starts speaking while the phone is still ringing and the client answers at the 10th second, a silenceTimeoutSeconds value of 13 can cause the call to drop just a few seconds after the actual answer. In such cases, the AI may either play the timeout message and immediately hang up or sometimes not respond at all. Here are two examples for reference: 512f68a7-971e-4f24-8fa2-1d8febc1ab95 05b0028a-b1bd-46ff-9ca8-5706ed5ff404

I also faced this. My solution was to add "Hello" for the first message and it's kinda okay ish

looking into it/.

Hey @User, Unfortunately I had to stop all of my clients outgoing calls because of this error. mostly all of the outgoing calls affected.

AMD could potentially help you as well as modifying the assistant prompt. Can you modify the 'Conversation Flow' section of your prompt to state: - Call Beginning behavior: Do not say anything until the ringing has stopped completely. Whether or not the person has responded upon answering the call, you will start the conversation by saying, "Hello Shahab, uhh this is Adam from home leader realty Maziar Moini's brokerage, how are you doing?" let us know what the result is

I've tested this with the existing assistant and also a new one. it still starts speaking once it started ringing.

Looks like telephony notifying us too early that the call started, and we just start the call once telephony establishes that connection, we rely on them to tell us when the call is connected

Exactly. but in reality, the call isn't yet connected to the other party, it can be corrected by using the correct status. The status of call. Can be: queued, ringing, in-progress, canceled, completed, failed, busy or no-answer for Twilio in addition to initiated it needs to listen to the webhook for the status of in-progress otherwise no response by the assistant is needed, this fix reduces a huge load over your servers as well as the costs for outbound calls. I'm open for any cooperate if needed. please check the sources below: https://help.twilio.com/articles/223132267-Tracking-the-Status-of-an-Outbound-Twilio-Voice-Call https://www.twilio.com/docs/voice/api/call-resource?utm_source=chatgpt.com Once a call is created, it progresses through multiple states until it is finally completed. Outbound calls initiated via the REST API cycle through these states in order: Queued: Twilio has accepted your API request, and is determining the correct Super Network partner to connect your call. NOTE: Outbound Child (bridged or forwarded) calls created with the TwiML verb skip the queued state and go straight to initiated, then ringing and in-progress. Initiated: Twilio has forward your call request to one of our Super Network partners. Ringing: Twilio has received a signal from our Super Network partner advising the destination phone is ringing. In-progress: Twilio has received a signal from our Super Network partner advising the call has been answered. Completed: The call has ended.

Thank you for providing the information and documentation. Fortunately, we are also following the same process. However, Twilio is returning the status too early, which is the reason for the issue you are observing. If you wish to verify, you can take the Twilio call ID as an identifier and contact them directly. If Twilio sends the status updates prematurely, we are unable to take any action other than following their updates.

I understand that this might be a complex issue to resolve, but it's crucial that the assistant only starts speaking when the status is "in-progress." This is important to ensure that the assistant doesn't speak before the client has actually answered the call. If the only webhooks you are receiving are for "initiated" or "ringing" statuses, then one potential solution could be API polling. By periodically checking the call status through the Twilio API, we can ensure that the assistant speaks only once the call is in progress. I'm confident that there's a solution here, just like all the other challenges you've overcome so far.

Hey, Could you please schedule a brief call at your convenience so we can discuss this matter in detail? Kindly use the following link to book a suitable time: .