A caller presses 5 to confirm an appointment. The phone plays the familiar tone, but the automated service repeats its menu. The caller presses again, and this time the system receives two digits. The sound heard by the caller has not established what the application received or how the telephone network transported the input.
Dual-tone multi-frequency signalling, usually shortened to DTMF, identifies a telephone key using a pair of frequencies. It remains part of telephone interaction through automated menus, conference controls, and other services that accept keypad input. In packet-based calls, the key can also travel as a telephone event rather than as the audio waveform itself.
That distinction explains many practical failures. Diagnosing DTMF requires following the keypress from the handset through gateways and media systems to the application that interprets it.
How the frequency pair identifies a key
The DTMF arrangement takes one frequency from a low group and one from a high group. The two are transmitted simultaneously for a keypress. ITU-T Recommendation Q.23 specifies the frequency groups and their keypad allocation.
| Low frequency | 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, pressing 5 combines 770 Hz and 1336 Hz. Pressing 8 retains the same high frequency but uses 852 Hz as the low frequency. The full arrangement provides sixteen signals; the familiar consumer keypad exposes twelve, while A through D occupy the fourth column.
These are simultaneous components of a signal, rather than two tones played one after the other. A receiver identifies the combination and maps it to a symbol. It must also distinguish the end of one keypress from the beginning of the next so that repeated digits remain separate inputs.
Recognising a tone involves more than finding two frequencies
A practical detector cannot accept every brief appearance of energy near two frequencies as a valid key. Speech, background sounds, and signal processing can produce patterns that resemble part of a tone. The receiver needs to consider frequency tolerance, signal duration, relative levels, and separation between signals.
ITU-T Recommendation Q.24 addresses reception of push-button signals. When implementing or configuring a detector, use the applicable specification and product requirements rather than treating the nominal frequencies as a complete detection algorithm. A tone generator and a receiver can use the same frequency table and still disagree about what constitutes a valid signal.
One possible failure is a missed digit because the received tone is too short or distorted. Another is false recognition of speech as a keypress, often called talk-off. Increasing sensitivity to recover weak signals can affect false detections, so changing thresholds needs representative testing rather than a single successful call.
The signal heard locally may also be generated by the handset for feedback. It is useful evidence that the user pressed a key, but it does not prove that an equivalent tone reached the far end. This is especially relevant when the network transports the key as an event and generates audio only at selected points.
Audio and telephone events take different routes
In-band DTMF carries the tones within the audio signal. The receiving system detects them from that audio. This can work well when the path preserves the relevant signal, but codecs, transcoding, and other media processing may change what reaches the detector.
An alternative for RTP-based media is the telephone-event payload defined in RFC 4733, which superseded RFC 2833. It represents the event using fields such as its identifier, duration, and end indication. The receiver can recover the key without recognising its two frequencies from speech audio. The payload type is negotiated; implementations should not assume a universal fixed number.
Telephone events are sometimes described as out-of-band DTMF because they are separate from encoded speech samples. They can nevertheless travel in the RTP media path. That description does not necessarily mean the key is carried through a separate SIP signalling message. Establish the actual configured mechanism when examining a call.
A mixed network may use both representations on different legs. A gateway can detect tones and emit telephone events, or receive events and generate tones for an audio-only destination. A working path therefore requires compatible negotiation and conversion across the whole call, not just matching settings at the two applications.
Why one press can become two digits
Telephone-event transport can send multiple packets describing one event, including repeated end reports for reliability. RFC 4733 specifies this behaviour; a packet is not automatically a new keypress. Event handling needs to recognise the identity and timing of an event rather than append a digit for every received packet.
Duplication can also appear when both tone detection and event handling feed the same application input. If a gateway preserves an audio tone while also creating its telephone event, a downstream system may recognise each representation separately. The repair is to identify where both paths become active and configure the intended handling.
Do not treat all repeated digits as duplicates, however. A caller may intentionally enter 55. A filter that simply discards equal consecutive values can corrupt valid input. The implementation needs an event boundary or suitable detection state that distinguishes two presses from multiple reports of one press.
This is a useful place to separate media evidence from application evidence. A packet capture may show an event arriving correctly while the IVR processes it twice. Conversely, the application may receive one digit even though repeated packets appear in the capture. Inspect the relevant layer before changing network settings.
Follow a failing call through its actual path
Start with a reproducible call and record where it originates, which carrier and gateway routes it uses, and which IVR session receives it. If calls sometimes succeed, compare the routes rather than assuming that every call uses identical media handling. A transfer or conference bridge can introduce a different leg after the original connection worked.
Confirm which mechanism each leg negotiates and what it transmits. For audio DTMF, examine the signal reaching the detector. For telephone events, inspect event payloads and the receiver’s interpretation. Where a gateway converts representations, check both its input and output to locate the point where the digit disappears or changes.
Useful diagnostic cases include a single digit, repeated equal digits, a longer number, and input during or immediately after a prompt. Also test the paths users actually encounter: transfers, hold and resume, and calls from the supported device types. These cases expose different boundaries without requiring an exhaustive test of every possible telephone network.
A local demonstration between two compatible endpoints does not establish that a production carrier route works. Record the tested path and configuration with the result. Otherwise, a later routing change can invalidate the evidence while everyone continues referring to the earlier successful test.
Choose diagnostic records that let the media and application teams discuss the same call. A shared call reference, input collection stage, recognised event count, and relevant timestamps can locate a failure without retaining the entered number. If deeper capture is necessary, limit its scope and access. This is especially useful when a call transfers between systems that each assign their own session identifier.
The IVR still has to interpret valid input
Receiving the correct digit does not guarantee the correct application outcome. The IVR may be waiting for a different menu, collecting a fixed number of characters, or expecting a terminator such as #. A digit received before input collection begins can be lost unless the application deliberately buffers it.
Define that behaviour explicitly. If a prompt says that callers can press a key at any time, the application must accept the input while the prompt plays. If input is restricted to a later stage, the interaction should make that clear. A media configuration change cannot correct a mismatch between the spoken instruction and the application’s input state.
Timeouts also need a defined meaning. An interval with no input differs from an incomplete number, and an invalid selection differs from a transport failure. Give callers a reasonable recovery route and preserve enough session context to investigate recurring problems. The general distinction in why timeouts do not cancel work also applies when a timeout changes the menu while a downstream operation continues.
Keypad input can contain sensitive information, including account identifiers and authentication codes. Decide whether recordings and diagnostic records should retain those digits, and verify where tones or events can still be recovered. Masking the application log alone does not address a media recording that contains the same information.
DTMF itself does not establish the caller’s identity or permission to perform an operation. The application needs appropriate authentication and business controls around consequential actions. With those responsibilities separated, diagnosis becomes more direct: verify the keypress representation, follow its transport, confirm one recognised input, and examine the state that gave the input its meaning.
