What Is DTMF, and Why Is a Key Sometimes "Not Registered"?

Definition and origin

DTMF stands for Dual-Tone Multi-Frequency. The method was developed in the United States in the 1950s and 1960s, and gradually replaced rotary dialing, in which the phone "told" the network the digit through short breaks in the line.

The idea: the keys are arranged in a table of four rows and three (sometimes four) columns. Each row has a low frequency, and each column has a high frequency. Pressing a key plays the two frequencies together. Such a combination almost never appears in normal speech, so it is easy for the system to detect it, and hard to confuse it with a human voice.

This is also why the method has lasted to this day. Every IVR menu, every calling card and every system that asks you to "enter your ID number" relies on it.

The frequency table

If you want to see it in numbers, this is how the keypad is built:

For example, the digit 5 is a combination of 770 and 1336 Hz. There is also a fourth column, with the letters A to D, which is almost never found on regular phones but exists in the standard.

The user doesn't need to remember this. What matters is understanding that a key is really a tone, and that is where most of the problems come from when that tone travels over the internet.

Where you meet DTMF day to day

• IVR menu: "For classes press 1, for the office press 2."
• Accessing a voicemail box: entering a secret code to hear messages.
• Calling cards: entering the card number and the code.
• Conference rooms: entering a PIN code to join.
• Services of other organizations: a bank, an HMO, the electric company, which ask you to enter an ID number or choose an extension.
• Codes inside the phone system: on many phone systems you enter a code to transfer a call, pick up a call from another phone, or turn on "Do Not Disturb."

In all of these cases the same problem can come up: the user presses, and nothing happens. Or they press once, and the system registers two.

The problem: a tone passing through a compression machine

On an old landline phone, the key's tone traveled down the line like your voice, and the phone system "heard" it. On the internet, the voice doesn't travel as is. It is cut into packets and compressed by a codec, which was built to preserve human speech, not exact tones.

A codec like G.711 preserves the sound relatively well. More heavily compressing codecs, like G.729, can distort it until the system on the other side doesn't recognize it. And if a packet is lost in the middle of the tone, the key can be cut off, disappear or be registered twice.

That is why the VoIP world developed ways to "tell" about the key instead of "playing" it. Instead of sending a tone, a message is sent: "Key 5 was pressed, for such and such a duration." This is accurate, and it doesn't depend on the codec.

The three methods

There are three main ways to carry a key press in an internet call:

• RFC 2833 (now RFC 4733), also called RTP Event or "out-of-band inside RTP": the key press is sent as a special packet inside the voice channel (RTP), but not as a tone; it is sent as a structured message: which key, and for how long. This is the most common method, and usually also the default on phones.
• SIP INFO: the key press is sent as a message in the management channel (SIP), separately from the voice. It is reliable, but not every system supports it, and it may arrive slightly after the voice.
• Inband: the tone itself is sent inside the voice, as on an old line. It works only with a codec that does not distort the tone, such as G.711, and it is sensitive to packet loss.

Why a key "isn't registered": the common causes

1. Method mismatch: the phone sends RFC 2833, and the system on the other side waits for an Inband tone, or the reverse. The key press is sent, but nobody is "listening" for it in that language.
2. A compressing codec with Inband: the tone is distorted and not recognized.
3. Packet loss: part of the tone or of the message disappears along the way.
4. A press that is too short: in some systems, a very quick press is not registered.
5. Pressing before the menu is ready: you press while the menu hasn't started listening yet, for example in the middle of a greeting that isn't set to accept key presses.
6. Double sending: the phone sends both a message and a tone, and the system registers the key twice: you pressed 1, and 11 was registered.

Diagnosis: how to tell where the problem is

When a user complains that the keys don't work, a few simple questions quickly narrow the search:

Tip: when you report this kind of problem, mention which extension, to which number, and at what time. That way the call can be found in the log and you can check what actually went through it.

DTMF when building an IVR menu

Whoever sets up an IVR menu has to think about the keys as well, not just the recording:

• Allow key presses during the greeting: regular callers know in advance what to press, and don't want to wait until the end of the message.
• A reasonable wait time for a keypress — after the message ends, wait a few seconds. Too short, and older callers can't keep up; too long, and everyone else gets annoyed.
• What happens when there is no keypress — transfer to the office, play the message again, or politely hang up. Don't leave the caller hanging.
• What happens on a wrong keypress — a short message, "That option doesn't exist," and back to the menu.
• Long input — when asking for an account number or ID number, end with # so the system knows the caller has finished.

Different devices, different behavior

• IP phone — usually sends RFC 2833. You can change the method in the account settings, under a name like "DTMF Type".
• Softphone — depends on the app. Most apps work with RFC 2833, and some let you choose.
• Regular phone through an adapter (ATA) — the phone plays a tone, and the adapter has to "hear" it and convert it to a message. A wrong setting on the adapter is a common cause of double keypresses.
• Mobile calling from outside — the keypress travels over the cellular network and reaches the PBX through the carrier. There is nothing to change on the caller's side.

The key point: when a menu works for outside callers and fails only from one particular extension, the problem is almost always in the device settings of that extension.

An example from the field

At the "Tiferet Shmuel" yeshiva (a made-up name), parents complained that in the grades system menu they "press 2 and hear the message for 22." It turned out the problem affected only parents calling from an old home phone connected to an adapter.

Their adapter sent each keypress twice — once as a tone and once as a message. After a single method was selected in the adapter settings, the problem was solved. The menu itself was not changed at all.

Privacy: what to do with numbers that callers enter

When you ask a caller to enter an ID number, a card number or a secret code, the keypresses become sensitive information. A few things are worth remembering:

• Call recording — with the Inband method, the tones can be heard in the recording, and anyone listening can work out the digits from them. With the other methods the recording is usually silent at those moments, but it depends on the system.
• Transcription and logs — don't store secret codes in places that aren't meant for them.
• A code that is too short — a four-digit code for a voicemail box or a conference is convenient, but easy to guess. It's better to choose a code that isn't a simple sequence like 1234.

The simple rule: what you press is like what you say. If you wouldn't want it heard in a recording, think about where it is stored.

Keypresses inside the PBX: special codes

Besides menus, in many phone systems you dial short codes to trigger actions: star plus a number to pick up a call ringing at another extension, a code to transfer a call, a code to enter the voicemail box. Here the key doesn't go to an outside system; the PBX itself receives it.

When such a code doesn't work, the first question is whether it was dialed before the call (like a regular number) or during it. Codes dialed before the call are sent as a dialed number, so DTMF problems don't affect them. Codes dialed during the call are affected.