VICIdial DTMF Troubleshooting

Originally published at vicistack.com. Follow us for more call center engineering content.

Last updated: March 2026 | Reading time: ~24 minutes

DTMF problems in VICIdial are the kind of issue that makes you question your career choices. The agent presses a button to transfer a call. Nothing happens. They press it again. Still nothing. The customer is sitting there listening to silence while your agent frantically clicks a button that used to work fine yesterday.

Or maybe it's your IVR. Callers dial in, hear "Press 1 for sales," and press 1. Your Call Menu doesn't register the digit. They press it again. And again. Then they hang up. You just lost a lead because of a DTMF configuration mismatch that takes 30 seconds to fix once you know what's wrong.

I've been troubleshooting DTMF issues in Asterisk-based systems since 2012. The problem is almost always one of five things, and I'm going to walk through every single one of them with the exact configs you need.

---

What DTMF Is (30-Second Version)

DTMF stands for Dual-Tone Multi-Frequency. When someone presses a key on a phone, it generates two simultaneous tones at specific frequencies. The "1" key sends 697 Hz and 1209 Hz together. The "9" key sends 852 Hz and 1477 Hz. The receiving system decodes these tone pairs back into digits.

In the analog world, this was simple — tones traveled through the wire, the switch decoded them. In VoIP, it's a mess because there are three completely different ways to transmit DTMF digits, and if the sender and receiver don't agree on which method to use, digits either get mangled, duplicated, or lost entirely.

The Three DTMF Transmission Methods

1. Inband (Audio Stream)

The actual DTMF tone is encoded into the audio RTP stream, exactly like a regular sound. The receiving end needs a DSP (Digital Signal Processor) to detect and decode the tones from the audio.

The problem: Compressed codecs like G.729 and G.722 distort the tone frequencies. Asterisk will literally tell you this:

WARNING[12345]: dsp.c:1525 ast_dsp_process: Inband DTMF is not supported on codec g729. Use RFC2833

Inband only works reliably with G.711 (ulaw/alaw). If your trunk uses any other codec and your dtmfmode is set to inband, you'll get missed digits, ghost digits, or nothing at all.

When you'd use it: Almost never in 2026. Legacy systems that can't handle RFC 2833. Some analog gateway conversions. That's about it.

2. RFC 2833 / RFC 4733 (RTP Named Telephone Events)

Instead of sending the actual tone in the audio, the sending side generates special RTP packets called "named telephone events" (NTE). These packets ride alongside the audio stream in the same RTP session but use a different payload type (typically 101).

RFC 4733 is the updated version of RFC 2833 and is functionally identical for DTMF purposes. Asterisk uses the term rfc4733 in PJSIP and rfc2833 in chan_sip, but they're the same thing.

This is the default and recommended method for almost every modern VoIP deployment. It's codec-independent, reliable, and universally supported by carriers.

3. SIP INFO

DTMF digits are sent as SIP signaling messages (INFO requests) completely outside the RTP audio stream. The digit information is carried in the SIP message body.

The problem: SIP INFO messages travel through the SIP signaling path, which may be different from the media path. If your SIP proxy, SBC, or NAT device doesn't pass INFO messages correctly, digits vanish. SIP INFO also introduces latency because it's a request/response transaction on the signaling channel rather than a simple RTP packet.

When you'd use it: Some carriers require it. Some PBX integrations only support it. But if you have the choice, use RFC 2833/4733 instead.

---

Configuring DTMF in Asterisk for VICIdial

PJSIP (Modern Asterisk 16+)

In your PJSIP endpoint configuration, the relevant setting is dtmf_mode:

[my-carrier]
type=endpoint
transport=transport-udp
context=trunkinbound
disallow=all
allow=ulaw
dtmf_mode=rfc4733

Valid values for dtmf_mode:

• rfc4733 — RFC 2833/4733 Named Telephone Events (recommended)
• inband — Tones in audio stream (only works with G.711)
• info — SIP INFO messages
• auto — Tries RFC 4733 first, falls back to inband
• auto_info — Tries RFC 4733, falls back to SIP INFO

chan_sip (Legacy Asterisk)

If you're still on chan_sip (VICIdial installs before 2024 typically), the setting is in sip.conf:

[my-carrier]
type=peer
host=sip.carrier.com
dtmfmode=rfc2833
disallow=all
allow=ulaw

Valid values for dtmfmode:

• rfc2833 — Same as rfc4733 (recommended)
• inband — Tones in audio stream
• info — SIP INFO
• auto — RFC 2833 with inband fallback

The Golden Rule

Your Asterisk dtmfmode MUST match what your carrier expects. If your carrier sends RFC 2833 events and your endpoint is set to info, Asterisk will ignore the RTP telephone events and try to decode SIP INFO messages that never arrive. The digits just disappear.

This is the #1 cause of DTMF problems we see. Someone changed a carrier, the new carrier uses a different DTMF method, and nobody updated the Asterisk config.

---

VICIdial-Specific DTMF Issues

The MeetMe Bridge Problem

Here's the thing most people don't realize about VICIdial: when an agent is on a call, both legs (the agent's phone and the customer's phone) are connected through an Asterisk MeetMe conference bridge. This is how VICIdial enables monitoring, whisper coaching, and barge-in.

The MeetMe bridge acts as a software transcoder that mixes audio from both legs. This mixing process washes out inband DTMF tones. The signal goes in as a clean dual-tone, gets mixed with the other party's audio, and comes out the other side as garbage that no DSP can decode.

That's why VICIdial has a dedicated DTMF button on the agent screen. When an agent needs to send DTMF (like navigating an IVR after a transfer), they use the DTMF field on the agent interface instead of pressing keys on their softphone. This triggers the agi-dtmf.agi script, which injects DTMF digits directly into the correct leg of the MeetMe conference using the Asterisk Manager Interface.

If agents report that their phone keypad doesn't send DTMF during calls: This is expected behavior in VICIdial. They need to use the DTMF button on the agent web interface instead.

The agi-dtmf.agi Script

The DTMF injection script lives at /var/lib/asterisk/agi-bin/agi-dtmf.agi. When an agent types digits into the DTMF field and clicks send, VICIdial uses AMI to execute this AGI script on the appropriate channel.

If the DTMF button on the agent screen doesn't work:

1. Check that agi-dtmf.agi exists and is executable:

ls -la /var/lib/asterisk/agi-bin/agi-dtmf.agi
# Should show -rwxr-xr-x owned by asterisk

1. Check Asterisk AGI permissions:

asterisk -rx "module show like res_agi"
# Should show res_agi.so loaded

1. Verify the AMI user has sufficient permissions in manager.conf:

[cron]
secret = your_secret
read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan,originate
write = system,call,agent,user,config,command,reporting,originate

The dtmf read permission and originate write permission are both needed.

IVR / Call Menu DTMF Detection

VICIdial's Call Menu feature (Admin > Inbound > Call Menus) relies on Asterisk's Background() and WaitExten() applications to detect digits. If callers report pressing keys and nothing happening:

Check 1: DTMF mode on the inbound trunk

Whatever carrier delivers your inbound DID calls needs to have the correct dtmfmode configured. If inbound calls arrive via a different carrier than outbound, you might have the outbound trunk configured correctly but the inbound trunk wrong.

Check 2: The extension context

Call Menu entries map to Asterisk extensions in a specific context. Make sure the context referenced by your DID route matches where the Call Menu dialplan lives. In VICIdial, this is typically handled automatically, but custom modifications can break the routing.

Check 3: Codec negotiation on the inbound leg

If the inbound trunk negotiates G.729 and dtmfmode is inband, DTMF will fail. Check your Asterisk console:

asterisk -rx "pjsip show channel <channel-name>"

Look at the negotiated codec and the DTMF mode to confirm they're compatible.

---

Diagnosing DTMF Issues Step by Step

Step 1: Enable RTP Debug

This is the most useful diagnostic for DTMF problems:

asterisk -rx "rtp set debug on"

Now make a test call and press some digits. You should see output like:

Got RTP packet from 10.0.0.50:12345 (type 101, seq 34521, ts 160000, len 4)
 -- DTMF event '5' received on channel PJSIP/carrier-00000001

If you see the RTP packets arriving but no DTMF event decoded, your dtmfmode doesn't match what the carrier is sending.

If you don't see any RTP packets with type 101, the carrier may be sending DTMF via SIP INFO or inband instead of RFC 2833.

Turn it off when you're done:

asterisk -rx "rtp set debug off"

Step 2: Check SIP DEBUG for INFO Messages

If you suspect SIP INFO DTMF:

asterisk -rx "pjsip set logger on"

Press digits during a call and look for SIP INFO messages in the console:

<--- Received SIP request (xxx bytes) from UDP:10.0.0.50:5060 --->
INFO sip:asterisk@10.0.0.1 SIP/2.0
Content-Type: application/dtmf-relay

Signal=5
Duration=160

If you see these INFO messages but Asterisk isn't processing them, your endpoint's dtmf_mode is probably set to rfc4733 when it should be info.

Step 3: Verify with a Known-Good Test

Create a simple test extension in your dialplan:

[test-dtmf]
exten => 9999,1,Answer()
same => n,Read(DIGITS,,4,,,10)
same => n,SayDigits(${DIGITS})
same => n,Hangup()

Dial 9999, enter 4 digits, and see if Asterisk reads them back. If this works from a SIP phone but not through the carrier trunk, the problem is on the trunk config. If it doesn't work from the SIP phone either, the problem is on the phone/softphone side.

Step 4: Check for NAT Issues

NAT traversal problems can cause RTP (including RFC 2833 DTMF events) to get blocked even when SIP signaling works fine. Symptoms: calls connect, audio works in one or both directions, but DTMF digits never arrive.

In PJSIP, make sure your transport and endpoint handle NAT correctly:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=YOUR.PUBLIC.IP
external_signaling_address=YOUR.PUBLIC.IP
local_net=10.0.0.0/8
local_net=172.16.0.0/12
local_net=192.168.0.0/16

And on the endpoint:

[my-carrier]
type=endpoint
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no

direct_media=no is especially important in VICIdial deployments — with the MeetMe conference bridge, direct media between endpoints would bypass Asterisk entirely, breaking DTMF, recording, and monitoring.

---

Carrier-Specific DTMF Gotchas

The Dual-Conversion Problem

Some carriers accept DTMF in one format and convert it to another format before delivering it to you. For example, the originating phone sends inband DTMF, the carrier detects and strips the tones, converts them to RFC 2833, and delivers RFC 2833 events to your Asterisk server.

This usually works fine. The problem happens when the conversion is lossy or misconfigured on the carrier side. Symptoms include:

• Missing digits: The carrier's detector misses a tone, so it never gets converted
• Duplicate digits: The carrier sends both the original inband tone AND the RFC 2833 event
• Delayed digits: The conversion adds latency, causing timing issues in IVR menus

If you suspect dual-conversion issues, ask your carrier what DTMF mode they deliver and whether they do any conversion. Most tier-1 carriers (Telnyx, Twilio, Bandwidth) deliver clean RFC 2833 and document their behavior. Smaller carriers may not.

The "Last Digit Missing" Problem

A classic DTMF issue: the caller enters 4 digits, but Asterisk only receives 3. The last digit is consistently truncated.

This happens because the RTP END event for the last digit gets lost — often due to packet loss or the carrier terminating the RTP stream too quickly after the last digit. The workaround in Asterisk:

[my-carrier]
type=endpoint
dtmf_mode=rfc4733
rtp_timeout=30

If you're using an AGI or dialplan application that reads DTMF with a timeout, make sure the timeout is long enough. The Read() application's timeout parameter is in seconds. Setting it to 10 gives callers plenty of time.

Telecom Provider Comparison

Different providers handle DTMF differently. In our experience across hundreds of VICIdial deployments:

Provider	Default DTMF	Notes
Telnyx	RFC 2833	Clean, configurable via portal
Twilio Elastic SIP	RFC 2833	Reliable, well-documented
Bandwidth	RFC 2833	Solid,
VoIP.ms	RFC 2833	Works well, budget-friendly
Flowroute	RFC 2833	Good DTMF support
Vitelity	RFC 2833	Adequate for most cases

Most modern SIP carriers default to RFC 2833/4733 and that's what you should configure in Asterisk unless you have a specific reason not to.

---

Advanced DTMF Scenarios

Blind Transfer DTMF Issues

When an agent does a blind transfer (sends the call to another extension or external number), the call leaves the MeetMe bridge and enters a new channel. DTMF behavior changes because the call is no longer bridged through the conference.

If the transferred call reaches an IVR (like a carrier's voicemail system) and the caller can't navigate it, check the dtmfmode on the outbound leg of the transfer. In VICIdial, blind transfers go through the Local channel to the dialplan, which then originates a new outbound call. The dtmfmode on that outbound trunk matters.

DTMF During Recording Prompts

Some VICIdial configurations use AGI(agi-record_prompts.agi) to record custom IVR prompts via phone. If the recording stops unexpectedly, it might be because Asterisk is interpreting DTMF in the audio as control signals. You can disable DTMF detection during recording with the q option in the Record() application.

The Comma Trick

A known workaround for systems that truncate the last DTMF digit: append a comma (pause) at the end of the DTMF string. In Asterisk dialplan, a comma in a DTMF string adds a brief pause:

same => n,SendDTMF(12345,,250)

The third parameter is the duration in milliseconds. Sending slightly longer DTMF events (250ms instead of the default 100ms) can help carriers that have aggressive detection thresholds.

---

Quick Reference: DTMF Troubleshooting Flowchart

1. Can you hear the DTMF tones in the audio?

   • Yes → Inband DTMF is being sent. Check if Asterisk expects inband or RFC 2833
   • No → RFC 2833 or SIP INFO is being used

2. Enable rtp set debug on — do you see type 101 packets?

   • Yes → RFC 2833 is arriving. Is dtmfmode set to rfc4733/rfc2833?
   • No → The sender isn't using RFC 2833. Check for SIP INFO messages

3. Enable pjsip set logger on — do you see INFO messages with dtmf-relay?

   • Yes → SIP INFO DTMF is arriving. Set dtmfmode to info
   • No → DTMF isn't reaching Asterisk at all. Check NAT, firewall, carrier config

4. Do digits work from a local SIP phone but not through the trunk?

   • Yes → Trunk configuration issue. Carrier DTMF mismatch
   • No → Local Asterisk configuration issue or phone issue

5. Do digits work through the trunk but not in VICIdial agent calls?

   • Yes → MeetMe bridge issue. Use the agent screen DTMF button instead of phone keys

---

When To Call Your Carrier

You've set dtmfmode correctly, RTP debug shows no events arriving, SIP debug shows no INFO messages, firewall rules are open, NAT is configured properly, and test calls from local SIP phones work fine.

At this point, the problem is on the carrier side. Common carrier-side issues:

• DTMF stripping at the SBC without re-injection
• Codec transcoding that destroys inband tones without RFC 2833 conversion
• Firewall or NAT rules on their side that block RTP event packets
• Misconfigured DTMF conversion in their platform

Ask your carrier: "What DTMF mode do you deliver on inbound calls, and what do you expect on outbound calls?" A good carrier can answer this in 30 seconds. If they can't, that tells you something about their operation.

---

---

Related reading:

• VICIdial DTMF Not Working: Every Fix We've Found in 14 Years of Asterisk
• VICIdial SIP Troubleshooting: Fix One-Way Audio, 503s, and Registration Failures
• Migrating from GoAutoDial to VICIdial: Step-by-Step
• STIR/SHAKEN for VICIdial: The Complete 2026 Implementation Guide ## The Bottom Line

DTMF problems in VICIdial fall into five buckets:

1. dtmfmode mismatch between Asterisk and the carrier (90% of cases)
2. Codec incompatibility with inband DTMF (G.729/G.722 + inband = broken)
3. MeetMe bridge washing out inband tones (use the agent screen DTMF button)
4. NAT/firewall blocking RTP event packets
5. Carrier-side DTMF conversion bugs

Fix #1 first. Set your trunk to rfc4733 (PJSIP) or rfc2833 (chan_sip), confirm with your carrier, and 9 out of 10 DTMF problems go away.

If you're running a contact center and DTMF issues are burning agent time and killing IVR completion rates, that's the kind of thing we fix at ViciStack. We've tuned Asterisk DTMF configs across every major SIP carrier and can usually resolve the issue in under an hour. The $5K engagement pays for itself the first week your IVR stops dropping callers.