The problem: the IVR ignores your callers
A caller rings your menu, presses 1, and nothing happens. Or the first digit registers and the rest are lost. Or it works from a desk phone but not from mobiles. Every one of these is a DTMF transmission problem, and it comes down to a single mismatch: the two ends of the call are not sending and expecting tones the same way.
DTMF (Dual-Tone Multi-Frequency) is the pair of audio tones a phone generates when you press a key. On a traditional line those tones simply travel down the wire as sound. On VoIP there are three completely different ways to carry them, and they are not interchangeable.
The three methods
1. Inband — tones inside the audio
The digits are sent as actual audio in the RTP stream, exactly as an analogue phone would. It sounds simple and it works perfectly with G.711, which is an uncompressed codec that reproduces the tones faithfully.
It breaks badly with compressed codecs. G.729 and similar are optimised for the human voice, not for pure tones — they distort DTMF enough that the receiving end either mishears the digit or misses it entirely. If you use a compressed codec, do not use inband DTMF. This single combination causes an enormous share of "IVR does not respond" tickets.
2. RFC 2833 / RFC 4733 — tones as RTP events
Instead of sending the sound, the sender puts a special named-telephone-event packet in the RTP stream that says "digit 1, this long." The receiver reconstructs it. Because it is signalled data rather than audio, codec compression cannot corrupt it.
This is the default nearly everywhere and the right choice in nearly every case. RFC 4733 is the modern revision of RFC 2833; you will hear both names for the same mechanism, and equipment labelled either way interoperates.
The one catch: the two sides must agree on the RTP payload type used for the events, negotiated in the SDP (commonly 101). A mismatch here means digits are transmitted and silently ignored.
3. SIP INFO — digits as signalling messages
The digit is sent out-of-band entirely, as a SIP INFO request separate from the media stream. It is reliable in the sense that it does not depend on the audio path at all.
Its weaknesses are timing and support. Because the INFO travels the signalling path rather than with the media, its arrival is not tightly synchronised with the audio, which matters for applications that care about exact timing. Support is also inconsistent across carriers. Treat SIP INFO as a fallback for when RFC 2833 cannot be made to work, not as a first choice.
Configuring it in Asterisk
In the older chan_sip stack, the setting is dtmfmode in sip.conf, set globally or per peer:
[general]
dtmfmode=rfc2833
[1001]
type=friend
dtmfmode=rfc2833 ; per-peer overrides the global valueValid values are rfc2833, inband, info and auto. The auto setting negotiates RFC 2833 if the far end advertises support and falls back to inband if not — convenient, but it hides mismatches that you would rather see explicitly.
In PJSIP the equivalent is dtmf_mode on the endpoint:
[1001]
type=endpoint
dtmf_mode=rfc4733PJSIP accepts rfc4733, inband, info and auto. Note the name change: rfc4733 here is the same mechanism chan_sip calls rfc2833.
Diagnosing a DTMF problem
Work from the evidence rather than guessing. Turn on the SIP logger and watch a real call:
asterisk -rvvv
pjsip set logger on # or: sip set debug onThen check what Asterisk actually receives. The most direct test is to send the call to the built-in echo or a simple dialplan that reads digits, and watch the console — Asterisk logs each DTMF event it detects, so if nothing appears, the digits are not arriving in a form it understands.
Three checks resolve most cases:
- Codec vs method. If you are on G.729 or any compressed codec and
dtmfmodeis inband, that is your bug. Switch to RFC 2833. - Payload type agreement. Look at the SDP in both directions. Both ends should list
telephone-eventand agree on the payload number. A mismatch means silent failure. - Mismatched ends. If your PBX sends RFC 2833 and the carrier expects INFO (or vice versa), digits vanish. Ask the carrier what they expect rather than assuming.
Double digits and missed digits
If a single keypress registers twice, something in the path is sending the digit by two methods at once — commonly a device set to auto or an SBC re-generating tones inband while also passing the RTP events through. Pin both ends to RFC 2833 explicitly.
If digits are intermittently lost, suspect packet loss on the RTP path. RFC 2833 events are sent as RTP packets and can be dropped like any other; a link with loss will lose digits before the audio becomes obviously bad.
Frequently asked questions
Which DTMF mode should I use?
RFC 2833 (called rfc4733 in PJSIP) in almost every case. It survives codec compression, is widely supported, and stays synchronised with the media. Only move to SIP INFO if a specific carrier requires it.
Why does DTMF work on some calls but not others?
Different call paths negotiate different codecs and traverse different equipment. An internal call using G.711 will tolerate inband DTMF while an external call on G.729 will not — same PBX, same setting, different outcome.
Can I use inband DTMF safely?
Only with an uncompressed codec such as G.711, and only where you control the whole path. It is a poor default because a codec change anywhere breaks it silently.
Why do digits arrive doubled?
The digit is being transmitted twice by two different mechanisms simultaneously. Set an explicit mode on both endpoints instead of relying on auto-negotiation.