A voice agent can understand a menu perfectly and still fail when it presses a key. Dual-tone multi-frequency (DTMF) reliability depends on tone transport, timing, call state, carrier behavior, and proof that the interactive voice response (IVR) system accepted the input. Technical teams need an end-to-end model for keypad events across real phone routes.
DTMF in 60 seconds
Dual-tone multi-frequency (DTMF) is the signaling system behind telephone keypad input. Pressing a key represents one low-frequency tone and one high-frequency tone at the same time. A receiver identifies the pair and maps it to a digit or symbol.
DTMF still handles tasks such as selecting an interactive voice response (IVR) option, entering an extension, supplying an account number, and confirming an action. In voice AI, it works in both directions:
- A caller presses keys and the voice agent receives the digits.
- A voice agent sends digits to navigate another system's IVR menu.
The second case is harder than a sendDigits() call suggests. The digit has to reach the correct call leg in a format the destination accepts, at a time when it is listening. The agent then needs evidence that the menu moved to the intended state.
Our optional IVR detection and navigation feature lets an outbound agent identify an automated system and use the digits 0-9, *, and # to work through a phone tree. The production acceptance bar remains end-to-end success on the routes and IVRs the product will call.
How dual-tone multi-frequency works
The standard keypad is a frequency matrix. Each row supplies a low-group frequency and each column supplies a high-group frequency. The intersection identifies the key.
| Low group | 1209 Hz | 1336 Hz | 1477 Hz | 1633 Hz |
|---|---|---|---|---|
| 697 Hz | 1 | 2 | 3 | A |
| 770 Hz | 4 | 5 | 6 | B |
| 852 Hz | 7 | 8 | 9 | C |
| 941 Hz | * | 0 | # | D |
For example, the digit 1 combines 697 Hz and 1209 Hz. The two-tone design gives the decoder a specific pair to detect and reduces the chance that ordinary speech will be mistaken for a key press. The full 4-by-4 layout includes A through D, although consumer phones usually expose only 0-9, *, and #.
The tone definitions come from ITU-T Recommendation Q.23. Modern IP calls can carry the resulting input as audio, a Real-time Transport Protocol (RTP) telephone event, or application data in Session Initiation Protocol (SIP) signaling. That distinction determines whether a clean key press survives the call path.
The three DTMF signaling modes
Teams often use in-band and out-of-band as if they name two universal settings. The real path has three common modes, and the terms describe different layers.
| Mode | What crosses the network | Best fit | Main failure risk |
|---|---|---|---|
| In-band audio | The two-frequency waveform is mixed into the voice audio | A destination that detects audible tones and accepts no event format | Speech codecs, transcoding, packet loss, gain control, or audio processing distort the tone |
| RTP telephone events | A named event travels in an RTP payload separate from audio samples | SIP and VoIP paths that negotiate telephone-event | Session Description Protocol (SDP) negotiation, payload mapping, or an intermediary drops or mistranslates the event |
| SIP INFO | A SIP request carries digit data inside the established dialog | Endpoints and providers with an agreed INFO convention | Session border controllers (SBCs) or call legs disagree about the body format, negotiation, or forwarding behavior |
In-band audio
In-band DTMF is literal sound in the media stream. It can work well on a clean G.711 codec path. Reliability falls when a speech-oriented codec, transcode, noise processor, or lossy network changes the waveform. A recording that sounds acceptable to a person does not prove that an IVR decoder received both frequencies for long enough.
RTP telephone events
RFC 4733 defines named telephone events in RTP and obsoletes RFC 2833. Providers still commonly call the mode “RFC 2833.” An SDP offer often advertises a dynamic payload mapping such as telephone-event/8000 and a supported event range.
DTMF events 0-9 use event codes 0-9, while *, #, and A-D use codes 10-15. The payload also carries an end flag, volume, and cumulative duration. Repeated packets can report the same event for resilience. A receiver must distinguish that redundancy from a second key press.
RTP events are out-of-band relative to audio samples, yet they still travel in the RTP media session. Every gateway, carrier, session border controller, and transfer path still has to preserve the event or convert it correctly.
SIP INFO
SIP INFO moves application information inside a SIP dialog. DTMF conventions built on INFO are less uniform. The SIP INFO framework notes that legacy DTMF mechanisms were proprietary and created interoperability problems. INFO is reliable only when the endpoints and intermediaries agree on the convention and forward it through the whole dialog.
A provider API may hide these modes behind one “send digit” operation. That is useful abstraction, but the underlying call leg still uses audio, RTP events, SIP INFO, or a provider-specific conversion. An accepted API request proves that the command entered the provider. It does not prove that the destination IVR acted on it.
How a voice agent should navigate an IVR
Reliable navigation is a state machine with an AI decision inside it. The transport and retry logic belong in deterministic runtime code.
- Classify the answer. The runtime distinguishes a human, voicemail, an IVR greeting, and early media.
- Build the current menu state. The agent extracts the available options and keeps digit strings as strings, preserving leading zeros and terminators such as #.
- Wait for an input window. A prompt boundary, beep, silence interval, or explicit call state establishes when the IVR is ready.
- Choose an allowed action. The model selects from the valid menu options or a deterministic policy supplies the digit.
- Emit one semantic DTMF event. The telephony layer maps that event to the negotiated transport for the active call leg.
- Observe the result. A new prompt, transfer tone, ringback, human speech, or terminal response shows whether the menu advanced.
- Apply a bounded recovery policy. No progress can trigger one slower retry, a different transport where the route supports it, a human handoff, or a clean exit.
This separation matters. Sending both an RTP event and an audible fallback at the same time can create a duplicate digit. Letting the language model write raw media packets gives it responsibility for timing and protocol state it cannot observe reliably.
The success signal is the IVR's next state. A completed SIP request, a sent RTP packet, or the local sound of a tone is only delivery evidence for one layer.
Production DTMF failures and their causes
The call legs use different modes
A platform sends RTP telephone events while the destination listens only for in-band audio. The reverse can happen after a carrier or private branch exchange (PBX) converts an event into a waveform. Mode support has to be understood per leg, including any gateway between VoIP and the public switched telephone network (PSTN).
The digit arrives too early
A call may still be playing early media, a greeting, or a prompt that ignores input. Fixed sleeps hide the race on one route and expose it on another. Prompt-aware state and a conservative input window are more stable than a single global delay.
Tone duration or interdigit gaps are wrong
A digit that is too short may be ignored. A long digit can have a special meaning on some equipment. A fast sequence can merge or overrun a legacy decoder. RFC 4733 cites 40 ms as a legacy minimum recognizable signal duration and 40 ms as a minimum pause in the equipment surveyed by ITU-T Q.24. Those values describe a compatibility floor, not a universal production setting. Destination behavior and the negotiated transport determine the accepted timing envelope.
Redundant packets become duplicate digits
RTP telephone events repeat state so a receiver can survive packet loss. A naive consumer that creates one application event per packet can turn 5 into 555. Deduplication uses the event code, RTP timestamp, synchronization source, duration progression, and end flag.
The mode changes during the call
Transfers, bridges, conferences, re-INVITEs, and carrier failover can create a new media leg or SDP mapping. DTMF that worked before a transfer can fail afterward if the runtime keeps using stale payload or route assumptions.
Audio processing damages in-band tones
Voice activity detection, echo control, automatic gain control, denoising, and speech codecs are optimized for conversation. In-band tones need a path that preserves the frequency pair and duration. DTMF bypasses speech-to-text; sending the tone through the transcription path adds delay and another decoder with no benefit.
Sensitive digits leak into AI and observability systems
DTMF can carry account numbers, access codes, or payment data. Raw values do not belong in language-model prompts, transcripts, recordings, analytics properties, or ordinary logs. The event pipeline can expose direction, count, timing, transport, and outcome while redacting the value. Workflows that collect regulated data need a purpose-built compliant path.
An implementation pattern for reliable keypad handling
A production design treats a digit as a semantic event from the application to the telephony edge.
At the application layer, the navigation policy produces an action such as send_dtmf("2"). The action includes the call ID, leg ID, direction, and correlation ID. Secret sequences are marked before they enter logging or model context.
At the session layer, call state establishes whether media is ready and which leg is active. The system serializes a sequence, applies duration and gap policy, and prevents concurrent speech or a second navigation action from creating overlapping input.
At the transport layer, the runtime uses the negotiated RTP payload, an agreed SIP INFO convention, or controlled in-band generation. One edge owns conversion. Parallel fallbacks stay disabled unless the destination's behavior explicitly requires them.
At the receiving side, repeated RTP reports collapse into one digit event. A complete event records start, duration, end, source, and transport. The application receives a normalized digit instead of raw packets or a transcript token.
At the outcome layer, the next IVR state closes the loop. Each attempt ends as accepted, rejected, timed out, duplicated, or unknown. Retries are bounded and carry the original correlation ID.
This model makes a transport change local. The conversation policy still chooses “billing” or “operator,” while the telephony edge handles how 2 or 0 crosses a specific route.
A production DTMF acceptance suite
A local tone generator proves the frequencies. Production acceptance has to exercise the complete path from agent decision to destination behavior.
| Test area | Required coverage | Passing evidence |
|---|---|---|
| Send and receive | Agent-to-IVR digits and caller-to-agent digits | Each semantic digit appears once and advances the expected state |
| Symbols and sequences | 0-9, *, #, leading zeros, terminators, long IDs, rapid and slow entry | Exact ordered sequence with no loss, merge, or duplication |
| Transport | Every supported in-band, RTP event, SIP INFO, and provider-API path | Negotiated mode is visible and the destination accepts it |
| Telephony route | Each carrier, SIP trunk, region, number type, and PSTN gateway in scope | Outcome metrics stay within the product's release threshold |
| Media conditions | Packet loss, jitter, transcoding, low audio level, noise processing | Expected recovery or a classified failure, never a silent false success |
| Call lifecycle | Early media, answer, hold, transfer, bridge, re-INVITE, and failover | DTMF follows the active leg and current negotiation |
| IVR behavior | Prompt barge-in, delayed prompts, repeated menus, invalid options, slow transfers | Bounded retry and fallback policy reaches a known terminal state |
| Privacy | Secret entry while recording, transcription, tracing, and analytics are active | Values are absent from every unapproved storage and model surface |
Useful trace data spans four layers:
- Decision: menu state, selected action, policy version, and correlation ID
- SIP and SDP: dialog, active leg, offer and answer, payload mapping, and re-negotiation
- RTP or audio: event code, timestamp, duration, end flag, or controlled tone-generation record
- Outcome: next prompt, transfer state, human answer, retry, timeout, and final navigation result
A synthetic IVR gives deterministic regression coverage. Real destination systems expose the carrier, gateway, timing, and decoder differences that a lab cannot reproduce. The release gate uses both. Our broader voice agent testing guide shows how these cases fit into scenario suites, failure injection, and production release controls.
How to evaluate DTMF support in a voice AI platform
“Supports DTMF” is too broad to serve as an acceptance criterion. Technical evaluation needs a defined contract and observable proof.
| Evaluation question | Production-grade answer |
|---|---|
| Can the platform send and receive digits? | Direction, channel, symbols, and limits are stated separately |
| Which transports work? | In-band, RFC 4733 events, SIP INFO, and provider abstractions are named per call type |
| How is a mode selected? | SDP negotiation, provider configuration, and any conversion rules are visible |
| Can timing be controlled? | Duration, interdigit gap, sequencing, prompt timing, and retry behavior have explicit policies |
| What happens after a transfer? | The active leg and renegotiated payload mapping replace stale call assumptions |
| How are duplicates prevented? | RTP retransmissions and application retries have separate deduplication rules |
| What proves success? | The platform correlates digit delivery with the IVR's resulting state |
| Can failures be debugged? | Call, SIP, RTP or audio, decision, and outcome evidence share one correlation path |
| Are secrets protected? | Redaction covers recordings, transcripts, prompts, traces, webhooks, and analytics |
| Is compatibility demonstrated? | The acceptance matrix uses the actual carriers, routes, codecs, transfers, and destination IVRs |
Carrier setup is part of that proof. Our SIP trunking guide explains how signaling, SDP, RTP, codecs, and gateways form the call path around a voice agent.
We are a fit when DTMF navigation is one requirement inside a production conversational AI product that also needs telephony, agent behavior, integrations, testing, and monitoring. A simple IVR or PBX feature may be sufficient when the entire job is collecting a few fixed digits with no conversational agent.
A representative evaluation runs one real outbound flow through the intended SIP route and target IVR. Gate deployment on prompt-level navigation success, leg-aware traces, and redacted digit handling. Evaluate Dasha for voice AI.