Hi, we are experiencing an issue where the model will call the dtmf according to the logs, but then it won't be received on the other end. It seems to vary from call to call, but if we call the same number we always have consistent results, i.e. calling a number that detects ivr input always detects the dtmf tool, and calling a number that doesn't detect it never will. I'm confident that the IVR that's being called can detect dtmf input, since I've called it myself to manually verify. Is this a known issue and is there a fix?

@John Hello! I'm sorry to hear that you're experiencing inconsistencies with DTMF detection. This isn't a known widespread issue, but it can occur due to various factors such as network latency, codec mismatches, or configuration settings on either the sending or receiving end. To help you better, I would need to gather more information about the specific circumstances under which this issue occurs. Could you please provide me with the following details? 1. The time frame during which the issue was observed. 2. Any specific error codes or messages from the logs. 3. The model or API version you are using. 4. Whether this issue occurs with all calls to the same number or if it's intermittent even with the same destination. 5. If possible, a sample of the code or the method you are using to send DTMF tones. With this information, I can investigate further and assist you in resolving the issue. If you have already gathered some of this information, please share it with me. If not, I recommend checking these details and getting back to me so we can proceed with troubleshooting.

@Vapi 1/2: Here's an example of the dtmf being sent: 15:41:10:288 [CHECKPOINT] Model sent start token 15:41:10:340 [LOG] Model called tool: dtmf({"keys":"1"}) 15:41:10:344 [LOG] Model request cost (attempt #1, $0.00038985, 2599 prompt, 0 completion) 15:41:10:345 [CHECKPOINT] Model sent end token 3: I'm currently using the GPT-4o model. 4: Calls to the same number always fail. 5. I'm using the built-in VAPI dtmf function

@John Thank you for providing the details. It seems that the DTMF tones are being sent correctly from the model's side. Since calls to the same number always fail, it's likely not an issue with the model itself but could be related to how the DTMF tones are being transmitted or received by the IVR system. Here are a few steps we can take to troubleshoot the issue: 1. **Check Network and Codec Settings**: Ensure that the network path between your system and the IVR supports the transmission of DTMF tones. Also, verify that the codecs used for the call support out-of-band DTMF, which is often required for reliable transmission. 2. **Test with Different DTMF Durations**: Sometimes, IVR systems have specific timing requirements for DTMF tones. Try adjusting the duration of the DTMF tones if the VAPI allows for this parameter to be set. 3. **Review IVR Configuration**: Double-check the IVR settings to ensure it's configured to detect DTMF tones correctly. There might be settings related to DTMF detection thresholds or methods that need to be adjusted. 4. **Contact IVR Vendor**: If the IVR system is provided by a third-party vendor, reach out to their support team for assistance. They might have insights into common issues or configuration settings that affect DTMF detection. 5. **Log Analysis**: If possible, obtain logs from the IVR system when the DTMF tones are sent to see if the IVR is receiving the tones but not processing them correctly. If you've already tried these steps or need further assistance, please let me know, and we can explore additional troubleshooting options. If there's a specific configuration or test you would like to perform with the VAPI DTMF function, I can assist with that as well.

can you please share the failing call ids.

Here's 5 of them, and I can scrounge up some others if needed. One of those is to the same number twice (d24e & 51ec) to demo the consistency of it. 4fef44da-1f87-41a1-8410-29c9032b57f1 02b880ce-f476-425f-b3f4-1d6dc0b57556 51eca2c7-07ac-47ce-8a95-d799cd7a0fb5 d24e39a9-999d-43a8-b025-ce2f398f0996 d2a247d1-d74f-4e7b-82e2-8970ab13b7d5

Not to chirp in here too hard but I would not use built in vapi dtmf and instead build your function to call and endpoint that controls the twilio call to sends digits. Not sure if you are using twilio but this is a reliable solution in my experience solving the same issue.

I was hoping there’d be a native solution, but I’m definitely not above building my own. thanks for the advice!

I think that their native solution should work and its probably down to how you have the call set up. I know I made it sound way harder than it actaully is. You just need an endpoint that when triggered takes in the digit to send, and you set up your agent to have a tool/function to attend to this. the endpoint just has access to the twilio API and sends digits.

How did you handle sending digits when there's simultaneous calls going on?

Assuming I have something like this: VAPI -[digit(s)]-> endpoint -[digit(s), twilio api key]-> twilio

If I have multiple calls running, then I'd need to somehow also send which ongoing call I need to update... Sorry if the question is dumb I'm quite new to twilio

Each vapi call that is made with twilio also has a twilio call id which is what you will need to use when sending digits to the twilio call.

So can vapi get it's own current call id to send to the endpoint?

Yes GET vapi call, there will be the twilio call id in there, use that to control the call with Twilio API

@John can you please share the call id for which it's working, because dmtf tones were generated and sent in required time.

231ab32c-1e62-4b16-b4f8-e8c6b77f362a fb2b7fb9-5b1b-42d4-b1ca-300f0dd8144c bf6ad949-f392-4050-b0d3-0a7f895b9f0d these all worked fine. Fwiw I agree that Vapi is generating and sending tones. The call logs always have tool calls in them and the tool calls succeed. It's just that for whatever reason the dtmf tone isn't being detected on the other end. I've manually called to make sure that their IVR can detect tones and they do when I input them manually

to add on to this, we found that the following does work:

async function updateCall() {
    const sid = "CAcc352de99d...";

    const updateResponse = await client.calls(
        sid
    ).update({
        twiml: "<Response><Play digits='1234'/></Response>",
    });
}

but immediately disconnects the call after playing the tones; we also tried copying Vapi's TwiML to try to reconnect to the websocket but it didn't work

@Shubham Bajaj any updates to this? any newer advice on tricks or workarounds? One thing that is not clear to me is whether I should be able to hear the tones in the call recording? I can see 'Model called tool: dtmf({"keys":"2"})' in the logs, but I don't hear a tone in the recording. Is this expected?

@cw OUR current DTMF or key press solutions aren’t working as expected and aren’t reliable for production, so we’ve started reworking them. We expect to have them live in production next week with the necessary fixes, and you’ll be informed through #1211483332496465962 .