Test log: Provider "vapi", "openia", and "Google" "voicemailDetection": { "provider": "vapi", "beepMaxAwaitSeconds": 8 } My number provider is Twilio. Do you think it's necessary to change it? It's identified that only on iPhones is it capable of not answering the call so it knows it's a voicemail. On Android, however, it takes 1 to 3 seconds to identify and end the call. The logs show that on Android, all calls that last that length of time have the "Ended Reason" result of "Customer Ended Call," when it is and should be "Customer Did Not Answer." Additionally, they are counted as "Successful" calls, which makes no sense. Call iD iPhone: db06996a-6f0a-41d2-b4b8-60d8628727f9 1b3c7f45-1d4a-4c16-833a-765be9e7e856 1bda66be-5d9e-4789-acfb-f887c5d9dcbd Call iD Android: 9ec5df68-533d-4a59-abe9-50fba9af718b df6bbc99-ba82-4bfa-81eb-557022224d5b 0acb9671-0973-4f3e-a109-7827a7b9f7bb It's not possible that you need to answer a call to identify it, especially when you're already doing it. configuration, taking into account that each second is charged by both Vapi and the number provider, Twilio. These costs can be significant for bulk calls. I don't think the service is cost-effective, charging for each call attempt, given that Twilio also charges per second. Why is there a difference in detection behavior between calls to iPhone and Android under the same configuration? Is it a signaling/early media issue that doesn't work the same way for Android? Why are Android calls that end in 1-3 seconds due to machine detection incorrectly logged as Customer Ended Call and Successful? How can this be corrected? Is there any alternative configuration or recommendation to minimize/eliminate connection time on Android, or at least ensure that the termination reason and status are correctly logged?

ccing: @Kings_big💫

The difference in voicemail detection between iOS and Android likely stems from Android’s delayed signaling, causing Vapi to misclassify short calls as “Customer Ended Call”, to address this, you can adjust beepMaxAwaitSeconds, implement logic to reclassify short calls..

I understand that what you're saying is only for call classification, if it's a major visual problem, but I think I'm being quite clear that the problem is that the voicemail isn't being detected, which is why I'm being charged by Vapi and Twilio from the first second. Additionally, it's clear that Vapi is making an error in call classification, which is even more evident that something is working as it should. When adjusting beepMaxAwaitSeconds, I don't get any different results; I've already tested within a range of 0-12 seconds. Let me clarify again that I'm getting charges for calls that are rejected, unanswered, and go to voicemail. Additionally, in testing with an iPhone, I notice it's working well. Would a different solution be very helpful? Like changing my phone number provider? But these are additional costs, and if I'm going to have the same problem, I don't see anything logical or profitable.

Use Vapi based detection (provider: "vapi"), enable Twilio’s MachineDetection=Enable, set a retry plan with beepMaxAwaitSeconds: 30, and hang up as soon as voicemail is detected; optionally, test alternative providers like Telnyx if issues persist.

@NicolasBcortes I have your support ticket and I've replied to it yesterday. I'll get back to you within my analysis and will update you accordingly

Great, I'm glad to hear it. I'm waiting for a response from Twilio to enable CNAMs. I've also sent the information to Telnyx so I can have a number from my country and test it to see if it resolves the issue. I appreciate it. As soon as it's resolved, I'll reactivate the operation.

@NicolasBcortes Bye, I am asking, and I want to confirm: Are you talking about caller ID? If so, can you share some documentation or a link so I can go through it?

How was the analysis? I'm still waiting. I never got a response.

@NicolasBcortes while there is support for Telnyx integration, the platform doesn't have specific handling for these Telnyx caller ID masking headers. When Vapi makes calls through Telnyx, it's using a more standard approach.

json
const callOptions = {
  to: customer.number,
  from: phoneNumber.number,
  connection_id: telnyxCredential.telnyxApplicationId,
  // ... other options
}

Okay, these are just solutions to mask the number. But I don't have any answers as to why they're still charging and marking calls as answered when in tests I'm just rejecting them. I really need to fix this problem, as it's the only one that has a cost.