Fix DTMF Tones Not Working

Resolve DTMF detection failures in Asterisk IVR, call transfers, and voicemail: RFC 2833, SIP INFO, and inband configuration

Understanding DTMF in VoIP

DTMF (Dual-Tone Multi-Frequency) signaling sends digit presses during a call. In VoIP, there are three methods to transmit DTMF, and both sides must use the same method or DTMF will fail silently.

Method	How It Works	Pros	Cons
RFC 2833 / RFC 4733	DTMF events sent as special RTP packets (payload type 101)	Most reliable; works with any codec; standard method	Both sides must support it
SIP INFO	DTMF digits sent as SIP messages (out-of-band)	Works when RTP path has issues	Slower; may have timing issues; not all devices support it
Inband	Actual audio tones in the RTP stream (like analog DTMF)	Works with any endpoint	Fails with compressed codecs (G.729); CPU intensive; unreliable

Best Practice: Always use RFC 2833 (rfc2833) as your primary DTMF mode. It is the industry standard and most reliable method for VoIP DTMF transmission.

DTMF Configuration

chan_sip Configuration (sip.conf):

[general]
; Set default DTMF mode for all peers
dtmfmode=rfc2833

; Options:
; rfc2833  - RFC 2833/4733 (recommended, most compatible)
; info     - SIP INFO messages
; inband   - Audio tones in RTP stream
; auto     - Negotiate (try rfc2833 first, fall back to inband)

; Per-peer override:
[my-phone]
type=friend
dtmfmode=rfc2833

; For problematic devices that only support SIP INFO:
[old-gateway]
type=peer
dtmfmode=info

; For analog adapters (ATAs) that send inband:
[ata-device]
type=friend
dtmfmode=inband

PJSIP Configuration (pjsip.conf):

[my-endpoint]
type=endpoint
dtmf_mode=rfc4733     ; RFC 4733 (updated RFC 2833)

; Options:
; rfc4733    - RFC 4733 telephone-event (recommended)
; inband     - In-band audio tones
; info       - SIP INFO messages
; auto       - Auto-detect (try rfc4733 first)
; auto_info  - Auto-detect, prefer SIP INFO

Common DTMF Problems & Fixes

1. DTMF Mode Mismatch

The most common cause. If Asterisk is set to rfc2833 but the phone sends SIP INFO, the digits will be lost. Check both sides and make them match.

2. Inband DTMF with Compressed Codecs

Inband DTMF sends actual audio tones. Compressed codecs like G.729 distort these tones, making them unrecognizable by the DSP. Never use inband DTMF with G.729. Switch to RFC 2833 or use G.711.

3. RFC 2833 Payload Type Mismatch

RFC 2833 uses a dynamic RTP payload type (usually 101). If the remote side uses a different payload type number and Asterisk does not negotiate correctly, DTMF events are lost. Check the SDP negotiation.

; Look in SDP for telephone-event:
; m=audio 10000 RTP/AVP 0 101
; a=rtpmap:101 telephone-event/8000
;                               ^^^^
; Both sides must agree on this payload type

4. DTMF During Early Media (Before Answer)

Some IVR systems require DTMF before the call is officially answered (during 183 Session Progress). Asterisk may not process RFC 2833 events during early media. Fix by answering the call first:

; In extensions.conf - always Answer() before reading DTMF:
exten => s,1,Answer()
 same => n,Wait(1)
 same => n,Read(DIGITS,please-enter-number,4)
 same => n,Verbose(1,Caller entered: ${DIGITS})

5. Feature Codes Eating DTMF

If Dial() is called with the T or t options (transfer), Asterisk listens for feature codes (* or #) and may consume DTMF digits intended for the remote IVR.

; Problem: 't' and 'T' flags enable transfer features
; which intercept * and # DTMF
exten => _X.,1,Dial(PJSIP/${EXTEN},,tT)

; Fix: Remove t/T if you don't need transfer features
exten => _X.,1,Dial(PJSIP/${EXTEN},30)

; Or set specific feature codes that don't conflict:
; In features.conf:
; blindxfer = *1
; atxfer = *2

Debugging DTMF Issues

# Enable DTMF debugging
asterisk -rx "core set verbose 5"

# Enable SIP debug to see SIP INFO DTMF
asterisk -rx "sip set debug on"
# or
asterisk -rx "pjsip set logger on"

# Enable RTP debug to see RFC 2833 events
asterisk -rx "rtp set debug on"

# Look for these log lines:
# "Got DTMF digit X via RFC 2833"     <-- RFC 2833 working
# "Got DTMF digit X via SIP INFO"     <-- SIP INFO working
# "DTMF begin 'X'"                    <-- DTMF received
# "DTMF end 'X'"                      <-- DTMF completed

# If you see NO DTMF messages when pressing digits:
# 1. Check dtmfmode matches on both sides
# 2. Check if RTP is flowing (rtp set debug on)
# 3. Try switching to dtmfmode=auto

# Test DTMF from dialplan:
exten => 999,1,Answer()
 same => n,Playback(beep)
 same => n,Read(RESULT,,1)
 same => n,SayDigits(${RESULT})
 same => n,Hangup()

DTMF Passthrough on SIP Trunks

When Asterisk bridges two SIP channels (e.g., internal phone to external trunk), DTMF must be properly converted if the two sides use different DTMF modes.

; Scenario: Phone uses RFC 2833, trunk uses SIP INFO
; Asterisk will automatically convert between DTMF modes
; as long as each peer has the correct dtmfmode set.

; Phone side:
[phone-100]
type=friend
dtmfmode=rfc2833

; Trunk side (provider requires SIP INFO):
[my-trunk]
type=peer
dtmfmode=info

; Asterisk handles the conversion automatically.
; If DTMF still fails, try:
; 1. Set both sides to the same mode
; 2. Use dtmfmode=auto on the trunk
; 3. Ask your provider which DTMF mode they support