DTMF — the tones you hear when pressing phone keys — is deceptively simple but a persistent source of VoIP problems. IVR systems that don't respond, voicemail that won't accept input, conference PINs that won't work. The root cause is almost always a mismatch in how DTMF is being transported.
In traditional PSTN, DTMF tones are audio — 697Hz+1209Hz for "1", 770Hz+1336Hz for "2", and so on. Both parties hear the tone. In VoIP, this approach works poorly because audio codecs (especially G.729 and G.722) are optimized for voice frequencies and often distort or drop DTMF tones during encoding.
VoIP introduced alternative transport methods that carry DTMF as signaling data rather than audio, eliminating codec distortion. The problem: there are three different methods and they must match on both ends of the call.
Skip the manual trace reading? Paste your trace into SIPSymposium — it identifies which transport method (RFC 2833, in-band, or SIP INFO) is in use on each leg, and surfaces mismatches between endpoints. Or continue below for manual diagnostics.
In the SIP trace, find the SDP in the INVITE and 200 OK. Confirm both contain telephone-event and that the payload type numbers match (see SIP codec negotiation and SDP offer-answer for the underlying mechanics):
Filter your PCAP on payload type 101. If you see type-101 packets being sent but not received (or vice versa), a firewall or SBC is dropping them. If no type-101 packets exist at all, the sender is using in-band or SIP INFO.
Search the trace for SIP INFO requests with Content-Type: application/dtmf-relay. If present, the sender is using SIP INFO. Confirm the receiver's proxy is passing INFO requests end-to-end.
RFC 2833 not negotiating: Ensure both endpoints have telephone-event enabled and payload type 101 is included in the SDP m= line. On Asterisk (chan_sip): dtmfmode=rfc2833. On FreeSWITCH: dtmf-type=rfc2833 in the profile.
Payload type mismatch: Explicitly configure both endpoints to use the same payload type number for telephone-event. Most platforms default to 101 — if one is using a different value, change it to match.
In-band with compressed codec: Switch to RFC 2833, or switch the codec to G.711 (PCMU/PCMA) if in-band is required. Never use in-band DTMF with G.729 — the codec distorts the tones. See VoIP codec comparison for codec-specific behavior.
SBC stripping DTMF: Configure the SBC to pass-through RFC 2833 events without transcoding, or explicitly configure DTMF relay between legs. Most SBCs have a DTMF handling configuration that defaults to re-originating — change it to transparent pass-through.
Asterisk chan_sip: Set dtmfmode=rfc2833 per peer. Use dtmfmode=auto to let Asterisk detect which method the remote end supports. Check with "sip show peer <name>" to confirm the negotiated method.
Asterisk PJSIP: Set dtmf_mode=rfc4733 in the endpoint config. RFC 4733 is the updated version of RFC 2833 and backward compatible.
FreeSWITCH: Set dtmf-type=rfc2833 in the SIP profile. For transcoding scenarios, use start_dtmf and stop_dtmf applications in the dialplan to detect and regenerate DTMF across codec boundaries.
DTMF not working in VoIP is almost always a transport method mismatch. Check the SDP for a=rtpmap:101 telephone-event/8000 — if missing, RFC 2833 is not negotiated. If using G.729 with in-band DTMF, the codec distorts the tones. If using SIP INFO, verify the proxy passes INFO messages end-to-end. The most reliable fix is to use RFC 2833 with G.711.
RFC 2833 (also called RFC 4733) sends DTMF as special RTP packets with payload type 101, negotiated in the SDP. It is the most reliable method and works with any codec. SIP INFO sends DTMF digits in SIP signaling messages — it is a legacy method that requires the SIP proxy to pass INFO end-to-end and has no standard format.
Never use in-band DTMF with G.729 — the codec compresses audio in a way that distorts DTMF tones below the detection threshold. Switch to RFC 2833 by adding a=rtpmap:101 telephone-event/8000 to your SDP. In Asterisk set dtmfmode=rfc2833 (chan_sip) or dtmf_mode=rfc4733 (PJSIP). In FreeSWITCH set dtmf-type=rfc2833 in the Sofia profile.
Paste your SIP trace into SIPSymposium. The analyzer checks telephone-event negotiation in the SDP, identifies payload type mismatches, detects in-band DTMF with incompatible codecs, and tells you exactly which transport method each endpoint is using.