Hi, Issue Summary I'm experiencing a technical problem with our outbound calling agent's ability to navigate IVR systems. While using Vapi's built-in DTMF functionality, the system logs indicate successful function calls with the correct digits, but many IVR systems fail to detect these inputs. This issue has been observed across multiple IVR systems, though it functions correctly with some. Affected Call IDs - dde63818-b547-41eb-bfd3-9e587cddd2ab - df13e533-4b27-4cd7-9c07-54e7f61a807f - ea0db2d8-a59f-4ae9-9b50-d49116efc056 - 1f5dd938-b0e6-40f2-b549-d9a6280a3606 Previous Resolution Attempts Attempt 1: Custom Twilio Implementation I developed a custom tool utilizing Twilio's Client SDK to directly transmit digits to the call. However, this approach consistently terminated the call. Investigation suggests this occurs because the call is transferred to Twilio, and after digit transmission, the call ends due to lack of further instructions. I attempted to resolve this by implementing a redirect back to the Vapi webhook: client.calls(call_sid).update( method="POST", twiml=f'https://api.vapi.ai/twilio/inbound_call' ) This resulted in the following error response from Vapi: {"message":["CallStatus must be one of the following values: ringing","Direction must be one of the following values: inbound, outbound"],"error":"Bad Request","statusCode":400} Additional Information I've noticed a DTMF tool in the tools section but have been unable to locate documentation regarding its customization or implementation. Could you please advise on potential solutions to address this DTMF detection issue?

Hi there! 👋 I understand you're having issues with DTMF detection in IVR systems while using Vapi's built-in functionality. This is a known challenge that several users have encountered. Let me help you troubleshoot this! ### Common Causes for DTMF Detection Issues 1. **Delayed DTMF Playback**: The most common issue is that DTMF tones have delayed playback time, causing the IVR to miss them in the required timeframe. Even though your logs show successful function calls, the actual tones might not be reaching the IVR system quickly enough. 2. **Call Status Mismatch**: The error you're seeing with your Twilio implementation is a classic call status issue. Vapi expects the call to be in "ringing" status, but after gathering DTMF, Twilio changes it to "in-progress" which causes the 400 error you're seeing. ### Potential Solutions Option 1: Proper DTMF Tool Configuration Make sure your assistant's model includes the DTMF tool correctly:

json
{
  "model": {
    "provider": "openai",
    "model": "gpt-3.5-turbo",
    "messages": [
      {
        "role": "system",
        "content": "You are an assistant that will hit menu options using the dtmf function."
      }
    ],
    "tools": [
      {
        "type": "dtmf"
      }
    ]
  }
}

Option 2: Use Twilio as Middleware For more reliable DTMF handling, consider using Twilio to handle the IVR navigation first, then transfer to Vapi. This approach requires: 1. Setting up a gather endpoint in Twilio:

javascript
twiml.gather({
  numDigits: 3,
  method: "POST",
  action: `${process.env.NEXT_PUBLIC_VAPI_SERVER_URL}/api/twilio/gather`,
});

2. After gathering DTMF, transfer to Vapi using a conference call to maintain the proper call status:

javascript
twiml.redirect({ method: "POST" }, "https://api.vapi.ai/twilio/inbound_call");

Option 3: Adjust DTMF Timing

@Sedrick You're experiencing problems with Vapi's built-in DTMF functionality not being reliably detected by some IVR systems, despite logs showing successful function calls. This is a known issue to us. To get it resolved, I suggest you to raise an feature request for it over here: https://roadmap.vapi.ai/

Also seeing this issue, seems to happen on some models more than others?