Understanding DTMF Transport Mechanisms: Inband Audio and Out-of-Band Methods
Overview
This guide explores Dual-Tone Multi-Frequency (DTMF) signaling transport methods in Voice over IP (VoIP) networks, focusing on Inband Audio and comparing it to RFC 4733 (formerly RFC 2833) dynamic RTP payloads and SIP INFO. Readers will learn the underlying mechanics of digit transmission, the impact of lossy audio compression codecs on inband tones, and how media gateways and Session Border Controllers (SBCs) handle DTMF interworking.

Key takeaways
- Inband DTMF transports digits as raw audio frequencies directly within the standard RTP payload.
- Lossy compression codecs (such as G.729 or AMR) distort inband DTMF tones, rendering them unreadable by distant IVRs.
- RFC 4733 (telephone-event) is the industry standard out-of-band RTP method that replaces audio tones with explicit digit event packets.
- SIP INFO carries DTMF digits via SIP signaling messages rather than the RTP media path, introducing potential timing synchronization issues.
- SBCs and media gateways must perform DTMF interworking when bridging two endpoints with mismatched DTMF capabilities.
Prerequisites
- Fundamental understanding of SIP session setup and SDP media negotiations.
- Basic knowledge of RTP stream mechanics and payload types.
- Familiarity with common VoIP codecs such as G.711 (PCMU/PCMA) and G.729.
Guide
- section #1
Fundamentals of DTMF in IP Telephony Dual-Tone Multi-Frequency (DTMF) is the signaling system used in telephony to send button press commands across a voice channel by combining two specific sine wave frequencies (a high band tone and a low band tone). In traditional PSTN networks, these tones traveled uncompressed along the same physical wire as the user's voice. When migrating voice communications to IP-based networks, transporting these precise audio frequencies presents architectural challenges due to packet loss, jitter, and low-bitrate audio compression. To address these challenges, modern VoIP systems utilize three main techniques for relaying DTMF digits: Inband Audio, Named Telephone Events via RTP (RFC 4733 / RFC 2833), and Out-of-Band SIP INFO messages.
- section #2
Mechanics of Inband Audio DTMF Inband Audio DTMF passes the actual acoustic sine wave tones generated by the endpoint directly into the primary RTP audio stream without any special packet framing or event processing. The sending device digitizes the analog DTMF frequencies into standard PCM samples and encapsulates them in normal RTP voice packets (e.g., payload type 0 for G.711 u-law or payload type 8 for G.711 a-law). The receiving endpoint, media gateway, or Interactive Voice Response (IVR) system must continuously process the incoming audio stream with a Digital Signal Processor (DSP) running a Goertzel algorithm or Fast Fourier Transform (FFT) to detect and decode the dual frequencies from the voice audio.
- section #3
Codec Compression and Tone Distortion The primary limitation of Inband Audio DTMF is its reliance on uncompressed or high-bitrate codecs. Lossy audio compression algorithms such as G.729, G.723.1, or AMR use Code-Excited Linear Prediction (CELP) models optimized specifically for human vocal tract acoustics. These algorithms discard phase information and sub-band frequencies that do not fit human speech models. As a result, when a DTMF tone passes through a CELP-based codec, the sine waves are clipped, warped, and harmonically distorted. The receiving DSP is usually unable to match the received signals against strict DTMF frequency tolerances, resulting in missed digits, duplicate digits, or talk-off (where human speech erroneously triggers a DTMF digit detection). Consequently, Inband Audio DTMF is only reliable when using uncompressed PCM codecs like G.711.
- section #4
RFC 4733 / RFC 2833 Out-of-Band RTP Events To eliminate the audio distortion inherent to compressed codecs, RFC 2833 (updated by RFC 4733) introduced a mechanism for transmitting DTMF as explicit RTP payload events. Instead of sending raw tone audio, the sending endpoint detects the local keypress, suppresses the audio generation, and generates dedicated RTP packets using a negotiated dynamic payload type (commonly 101). These packets explicitly state the key pressed (0-9, *, #, A-D), the tone duration, and the volume level. To guarantee delivery over lossy networks, the endpoint retransmits identical event packets multiple times with incrementing duration flags until the button is released. The session advertises this capability during SDP negotiation using the 'telephone-event' media attribute.
v=0 o=Root 12345 67890 IN IP4 192.168.1.100 s=VoIP Call c=IN IP4 192.168.1.100 t=0 0 m=audio 10000 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 - section #5
SIP INFO Signaling Method The SIP INFO method decouples DTMF completely from the media (RTP) layer by sending digits within SIP INFO request messages along the signaling path. When a user presses a key, the endpoint constructs an HTTP-like SIP INFO packet containing a plain text or MIME body detailing the signal name and duration. While this approach bypasses audio codec distortion and works even if media is muted, it introduces architectural challenges. SIP INFO messages travel through all proxy servers in the SIP signaling path, creating unnecessary processing overhead for stateful proxies. Furthermore, because signaling and media follow different paths with distinct latency profiles, SIP INFO DTMF often suffers from timing skew, causing digits to arrive out of sync with the associated RTP audio stream.
INFO sip:1001@10.0.0.1:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK776asdhds From: <sip:1000@10.0.0.2>;tag=12345 To: <sip:1001@10.0.0.1>;tag=67890 Call-ID: c3033100-a12b-11ed-a8fc-0002a5d5c51b CSeq: 201 INFO Content-Type: application/dtmf-relay Content-Length: 26 Signal=5 Duration=160 - section #6
DTMF Interworking at the Gateway and SBC In heterogeneous VoIP environments, endpoints frequently attempt to communicate using different DTMF transport methods. For instance, a legacy SIP trunk might only support Inband G.711 DTMF, while a WebRTC client or IP-PBX relies exclusively on RFC 4733 telephone-events. Session Border Controllers (SBCs) and Media Gateways perform DTMF Interworking to solve this mismatch. When an SBC receives an RFC 4733 RTP event from Endpoint A, it can suppress those event packets and synthesize clean, perfectly tuned G.711 inband audio tones to transmit to Endpoint B. Conversely, if an SBC receives inband tones over G.711 from an upstream carrier, its DSP can clamp (strip) the audio tones from the RTP stream and generate corresponding RFC 4733 event packets toward the internal IP network.
- section #7
Configuration Recommendations and Best Practices To ensure reliable DTMF delivery across SIP networks, adhere to standardized configuration practices across all core SBCs, PBXs, and carrier trunks. RFC 4733 (telephone-event) should always be configured as the primary DTMF transport method. Inband audio DTMF should be reserved strictly as a fallback mechanism for uncompressed G.711 calls when negotiating with legacy PSTN gateways. Always verify that dynamic payload numbers (e.g., 101) match across both legs of a bridged call or that the media engine properly re-maps payload types during interworking. Finally, ensure 'DTMF Clamping' is enabled on media gateways to prevent inband audio leakage when converting between inband audio and out-of-band events.
# Example: Asterisk pjsip.conf DTMF configuration options [endpoint-template](!) type=endpoint context=default # Options: rfc4733, inband, info, auto, auto_info dtmf_mode=rfc4733 allow=!all,g711u,g729 # Example: FreeSWITCH vars.xml / profile setting # <variable name="dtmf_type" value="rfc2833"/>
Further reading
- RFC 4733 - RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
- RFC 2833 - RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (Obsoleted)
- RFC 6086 - Session Initiation Protocol (SIP) INFO Method and Package Framework
- ITU-T Recommendation Q.23 - Technical features of push-button telephone sets