DTMF Over VoIP: How Keypad Tones Travel and Why They Fail

DTMF over VoIP works reliably when the keypad press is sent as a data event (out-of-band, RFC 4733) rather than as audible tone squeezed through a compressed voice codec. When it fails, the cause is almost always a mismatch: one side sends tones in one way, the other side listens for a different way. This guide explains the three methods, how to tell which one you are using, and how to fix a phone system, auto-attendant or door entry unit that ignores key presses.

TL;DR

• DTMF is the set of tones your keypad makes. Over VoIP it can travel in-band (as audio), out-of-band via RFC 4733 (as RTP events), or via SIP INFO messages.
• RFC 4733 is the standard approach. It exists because compressed codecs can distort audible tones so badly that a system cannot tell one digit from another.
• Most “DTMF not working” faults come from a method mismatch, a low-bitrate codec, or a gateway or session border controller that does not translate between methods.
• With the UK landline switch-off due by January 2027, old door entry, alarm and lift lines need checking for tone compatibility before they move to digital.
• Fixes are usually configuration changes. Test each one with a single call to your own automated menu.

Table of Contents

• What DTMF is and why VoIP complicates it
• The three ways DTMF travels over VoIP
• Why DTMF stops working: the usual causes
• How to diagnose it in an hour
• Automated attendants and IVR: where DTMF faults hurt most
• The 2027 switch-off and door entry, alarms and lifts
• Our perspective
• Getting your phone system checked
• Settings cheat sheet
• FAQ
• Sources

What DTMF is and why VoIP complicates it

Dual-tone multi-frequency signalling is what happens when you press 1 for sales or type a PIN. Each key produces a pair of tones, and the system at the other end decodes the pair into a digit. On a traditional analogue line, that tone simply travelled down the copper with your voice, and nothing interfered with it.

VoIP changes the journey. Your voice is sampled, compressed by a codec, chopped into packets and sent over the internet. Codecs are designed to represent human speech efficiently, not pure electronic tones. A tone that survives a copper wire intact can come out the other end smeared, shortened or with missing chunks.

That is why the standards bodies defined a separate way to carry key presses. The IETF’s RFC 4733 describes how to carry DTMF signalling, other tone signals and telephony events in RTP packets, and it obsoletes the older RFC 2833. Many engineers and phone settings still say “RFC 2833”, and in practice the two are treated as the same thing on a handset or PBX.

The three ways DTMF travels over VoIP

In-band: simple, but fragile

With in-band DTMF the digits are just audio. The receiving system listens for the tone pairs and decodes them. This is fine when the call uses an uncompressed codec and the network is clean. It breaks down when the call is compressed, because, as RFC 4733 explains, the whole point of the event payload is to avoid the distortion that audible tones suffer through voice codecs. The nasty part is that the person pressing the key hears a perfectly normal beep. The fault is invisible to them and obvious only to whoever administers the system.

RFC 4733: the sensible default

Here the handset or PBX does not send a tone at all. It sends a small packet saying, in effect, “digit 5 started, digit 5 lasted this long, digit 5 ended”. The RFC defines digits 0 to 9, * and #, plus A to D, as named telephone events. Because the event rides in the RTP stream with the same sequence numbering and timing base as the audio, the receiver can line it up with the call.

For most business hosted telephony and SIP trunks, this is the setting you want, provided both ends agree on it.

SIP INFO: the awkward third option

SIP INFO sends the digit as a signalling message. It can be perfectly valid, but not every carrier, PBX or cloud platform accepts it, so it tends to be chosen only where a specific system demands it.

Why DTMF stops working: the usual causes

When readers search for “DTMF not working”, the fault is nearly always one of the following.

1. The two ends disagree on method

Your phone sends RFC 4733 events and the far end is listening for in-band tones, or the reverse. Neither side is broken; they simply are not speaking the same language. Many systems have an “auto” mode that prefers RFC 4733 and falls back to in-band if the other side does not advertise support. That is helpful, but it can mask a mismatch until a particular route or supplier misbehaves.

2. The codec is too compressed for in-band tones

If you are stuck with in-band signalling, the codec matters. Heavily compressed, low-bitrate codecs can distort tone frequencies so much that an automated recognition system cannot distinguish a 1 from a 4. Calls to your bank’s automated line are a classic example. Switching the codec, or switching to RFC 4733, usually cures it.

3. A cloud platform that only understands one format

This catches out businesses connecting a phone system to a collaboration or bot platform. Microsoft’s own community guidance notes that application-hosted media bots in Teams can only detect DTMF sent in-band, and that Teams does not convert out-of-band RFC 2833 into audible tones for them. In that situation, the fix is not a handset setting. It is a translation step in your session border controller (SBC). Microsoft’s Direct Routing documentation covers the SIP protocols that SBC has to handle.

4. Network trouble: jitter, loss and a badly set playout delay

Even RFC 4733 events travel as packets, and packets can arrive late or out of order. Receivers use a jitter buffer to put them back in sequence. Set the playout delay too low and the system is snappy, but you risk gaps in detection. Set it higher and recognition of long digit strings improves, at the cost of extra latency. The RFC also advises that receivers delay playout of tones slightly, so the system can separate genuine key presses from noise at the start of an event.

This is also where the UK government’s guidance is worth taking seriously. GOV.UK’s guidance on moving landlines to digital technologies makes the point that the change is not simply an equipment swap. Your phone system becomes an application that depends on your network, so jitter, packet loss and stability directly affect whether calls, and menu key presses, work.

5. Gateways that do not align the first packets

Where a gateway bridges VoIP to the old telephone network, RFC 4733 calls for careful time and power alignment, so the first audio packets of a tone do not create spurious tones downstream. A poorly configured or cheap gateway can produce phantom digits or double digits. If an auto-dialler or alarm panel registers digits you did not press, look here.

6. Router or firewall interference

Some routers and firewalls rewrite SIP traffic using a feature often called SIP ALG. It is a common suspect in forum and support advice when signalling or media misbehaves, and switching it off is a standard test on a business router. If DTMF only fails on one site and works from another, the router is worth checking before the phone system.

How to diagnose it in an hour

Work from the simplest check outwards. Change one thing at a time and re-test with a call to a known automated menu, such as your own auto-attendant or a bank line.

1. Find out what your phone is set to. Look for a DTMF mode in the handset or PBX trunk settings: in-band, RFC 2833/4733, SIP INFO or auto.
2. Set it to RFC 2833/4733 on both the extension and the trunk. This is the standard choice on modern hosted telephony.
3. Check the codec. If you must use in-band, use an uncompressed codec such as G.711 for that route.
4. Test from another site or a mobile. If the fault is on one location only, suspect the local router, firewall or internet connection.
5. Check the router. Disable SIP ALG as a test, and confirm there is no heavy traffic filling the uplink during the call.
6. Look at jitter and packet loss. A congested or unstable connection will break events as well as voice.
7. Ask your provider which method their network expects. If you connect to a Teams or bot platform, ask whether an SBC is converting between formats.

If you can capture a call, a packet trace shows immediately whether telephone-event packets are being sent and whether the far end accepted them. That removes the guesswork.

Automated attendants and IVR: where DTMF faults hurt most

A missed key press on a handset is an annoyance. On an automated menu it loses you a customer. The expert consensus for businesses adopting automated phone systems is to stop guessing about compatibility: many enterprise platforms explicitly require RFC 4733, and if your provider or configuration defaults to in-band audio, an automated attendant will frequently miss input. Where the platform and the carrier disagree, an SBC acting as a protocol translator is the robust answer.

If you take card payments by phone, keypad entry also has a compliance side. A guide to keeping card data out of IVR payment systems is written from an Australian perspective, but its points on keypad input handling and configuration apply to any business designing a phone payment flow. Check the UK card-scheme and PCI requirements with your payment provider.

The 2027 switch-off and door entry, alarms and lifts

DTMF is not only a call-centre topic. Plenty of small-business equipment uses tones: door entry panels that call a mobile and let you press 9 to open, alarm dialers, and lift emergency phones.

GOV.UK says the underlying Public Switched Telephone Network is being switched off by the telecommunications industry by January 2027, and that landlines and other devices reliant on it will need upgrading. A device that works perfectly on copper can lose functionality on a digital line if it relies on analogue signalling parameters that VoIP does not replicate. GOV.UK’s telecare announcement describes how landline companies will send an engineer to carry out the switchover and test the alarm personally, and the same page notes that providers have committed to battery backup exceeding the Ofcom minimum of one hour of access to emergency services in a power cut.

For a business, the practical steps are:

• List every device on a phone line: door entry, alarm, lift phone, card terminal, fax, franking machine.
• Ask the manufacturer or installer whether the device works with a VoIP adapter, and which DTMF method it uses.
• Test each device after the move, not just the main phone. Press every key it relies on.
• For safety-critical devices such as lift phones and fire or intruder alarms, involve the maintenance company and your communications provider before changing the line, and ask about power-cut cover.

Our perspective

We see the same pattern again and again: a business moves to VoIP, the desk phones are fine, and three weeks later someone notices the door entry will not open, or customers say your menu “does nothing” when they press a number. Nobody tested the unglamorous equipment, and nobody checked what DTMF method the system expected.

Our view is that DTMF should be treated as part of the design, not as a setting to fiddle with after a complaint. Choose RFC 4733 as the default, confirm what every connected device and platform needs, and put any translation in one place rather than letting three devices each guess. Then look at the network underneath. A phone system that depends on a shaky connection will have strange faults whatever the DTMF setting, which is why we look at the broadband, wifi and cabling alongside the phones.

We work with businesses across Essex, London and the South East without long-term contracts, and support is UK-based, so when a keypad problem turns up you speak to someone who can look at it rather than a script. If you are not sure what your current setup is doing, ask for the DTMF mode and codec to be written down. It takes minutes, and it makes every later fault quicker to solve.

— Paul

Getting your phone system checked

If your keypad tones are being missed, or you are about to move door entry and alarm lines to digital, we can review the setup and put it right. Our VoIP and SIP hosted telephony is configured with the right signalling for your equipment, and our AI-powered business phone systems handle automated reception and call handling. If the underlying connection is the problem, see our business broadband and leased line options, or ask us about a wifi survey if handsets run over wireless. Our network cabling installation is available where the wiring itself is suspect.

Settings cheat sheet

FAQ

What is the difference between in-band and out-of-band DTMF?

In-band DTMF sends the keypad tone as audio inside the voice stream, so it passes through the same codec as speech. Out-of-band DTMF sends the digit as a separate event, either in RTP packets under RFC 4733 or as a SIP message. Out-of-band is more reliable on compressed calls because no audio has to survive compression.

Why is DTMF not working on my VoIP phone?

The most common reason is that the two ends use different methods, for example your phone sends RFC 4733 events and the far end listens for in-band tones. Other causes are a heavily compressed codec, network jitter or loss, a gateway that does not translate, or router settings interfering with SIP. Set RFC 4733 on both sides first and test again.

Is RFC 2833 the same as RFC 4733?

Not formally. RFC 4733 obsoletes RFC 2833, clarifies the original and adds better support for long events and several events in one packet. On phone and PBX settings the two are usually treated as the same option, which is why you will still see “RFC 2833” in menus.

Will my door entry system work after the landline switch-off?

Not automatically. Equipment that relies on analogue signalling can lose functionality on a digital line, so it needs a compatible adapter or replacement. Ask the manufacturer or installer, test every function after the move, and involve your communications provider for safety-related devices.

Sources

• RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals (IETF)
• Moving landlines to digital technologies (GOV.UK)
• Telecare users urged to speak to telecoms providers ahead of switch to digital landlines (GOV.UK)
• DTMF support in MS Graph integration (Microsoft Q&A)
• Direct Routing SIP protocols (Microsoft Learn)

Recommended

• Voip
• Mobe XTouch T10
• VoIP Terms