Touch Tone Keypads Not Work

[maxkuku]

Hi everyone,

why is pressing touch tone keypad not transmitted during calls? Does anyone know how to fix this? Please help me. Much appreciated.

My adapter: Grandstream HT286.

[Liptonbrisk]

A) You can check whether all phone buttons are recognized by calling the free 416 or 250 numbers listed at http://thetestcall.blogspot.com. Wait for voice message. Press # to end echo test.
Press 2 to enter DTMF testing. Press all digits on phone number pad. Press #. What you pressed should be read back to you.
If that works, then all the buttons on your phone are fine, and the current DTMF setting the ATA is using worked for the specific system being called.

b) Also, dial *98 or your Freephoneline number. If FPL's voicemail system works for your your key presses, then they are being recognized.

You're going to have to be a lot more specific about what phone system(s) don't recognize your key presses if those two tests work.

[Liptonbrisk]

(General Info)

Your phone generates the audible DTMF (Dual-Tone Multi-Frequency) tones. Your ATA's job is to interpret those tones and transmit them over the internet to your SIP service provider (Freephoneline). A problem can arise in how the ATA handles this transmission.



There are two primary DTMF methods:

1. In-band

The audible tones are sent within the main audio stream in the same manner your voice is. This method is highly dependent on the audio codec used. If a compressed codec (such as G.729a) is active, the tones can become distorted and unrecognizable.

G.729a is a lossy codec, and I can't stand it. There's really no reason for anyone to be using it anymore unless that individual is desperately seeking to conserve data usage.

In-band is generally considered the least reliable method, especially if a compressed audio codec (such as G.729a) is being used. The compression process can distort the precise tone frequencies, making them unrecognizable to the receiving system. Inband might work passably well if G.711u is being used exclusively, but network issues, including packet loss, can still degrade the tones.

There are certain circumstances where using Inband DTMF may be necessary. For example, some door-entry or intercom systems use access panels that require audible DTMF tones to unlock doors or activate gates. Those panels lack SIP-info or RFC 2833 stacks, so in-band audio is the only way to use them properly.

If an older alarm panel or the central station receiver doesn't properly support RFC 2833 signals, communication will fail. In that case, if you were using the G.711u audio codec for the connection, trying Inband DTMF might be a last-resort troubleshooting step, as it sends the tones as audio. Most alarm communicators simply dial in DTMF over the line. They do not support RFC 2833 or SIP INFO natively. Here's an example: viewtopic.php?p=75441#p75441.

You may come across an Interactive Voice Response (IVR) system (such as phone banking with customer service menus) that is older or poorly configured and doesn't recognize the standard RFC 2833 signals being sent. If your key presses aren't registering on a specific system when using RFC 2833, and you are using the G.711 codec, switching to inband might work for interacting with that specific system.

However, generally, avoid InBand DTMF unless out-of-band methods are failing first.




2. RFC 2833 (out-of-band)

The keypress is converted into a special data packet, separate from the audio stream. This is the modern, generally more reliable standard because it is not affected by audio compression.

Again, this method sends the DTMF tones out-of-band as specially formatted data within RTP (Real-time Transport Protocol, used for delivering audio) packets, separate from the voice/audio packets. It uses a specific payload type defined by the RFC 2833 standard (sometimes called NTE or Named Telephone Events). The receiving end reconstructs the tone based on this data.

RFC 2833 is considered the most compatible method for VoIP. Since the tones are sent as data separate from the audio stream, they are not affected by audio codec compression or typical levels of packet loss/jitter. RFC 2833is the standard method providers tend to recommend.

RFC 4733 replaced 2833:

"RFC 4733 is a technical document from the Internet Engineering Task Force (IETF) titled "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals," published in December 2006. It specifies how devices should package touch-tones (DTMF), dial tones, busy signals, and other telephone-related sounds into data packets for transmission over IP networks using the Real-time Transport Protocol (RTP). RFC 4733 officially replaces (or "obsoletes") the earlier standard RFC 2833 by expanding and clarifying its framework. Although RFC 2833 has been formally replaced, the method is still commonly referred to as "RFC 2833" in practice, and most implementations remain backward compatible. Like its predecessor, RFC 4733 defines a reliable way to send DTMF tones out-of-band relative to the audio stream—meaning as separate data packets rather than audio mixed with voice—thereby avoiding problems caused by voice compression. Key changes introduced by RFC 4733 include removing the strict requirement that all compliant devices must support DTMF events, making support negotiable during call setup; adding procedures for handling long events through segmentation, reporting multiple events in a single packet, and reporting "state events"; and establishing a formal registry, managed by IANA, for assigning new telephony event codes. In essence, RFC 4733 serves as the updated standard for reliably transmitting DTMF tones and other telephony signals within RTP data streams for VoIP communications." (An A.I. explanation)

https://datatracker.ietf.org/doc/html/rfc4733




Grandstream DTMF Method Comparison

i) RFC 2833 Out-of-Band (as Data)

RFC 2833 sends DTMF digits as special data packets. With the AVT method, DTMF digits are not sent as audible tones within the voice path. Instead, they are transmitted as distinct data packets, which are separate from the voice packets but sent within the same RTP (Real-time Transport Protocol) media session. This is the modern standard for VoIP DTMF, also known as Named Telephony Events (NTE). The keypress is converted into a special data packet, separate from the audio packets. This is the modern, generally more reliable standard because it is not affected by audio compression.


This method sends the DTMF tones out-of-band as specially formatted data within RTP packets, separate from the voice audio packets

Pros

• Typically reliable and not affected by audio compression codecs
• This is the most widely supported and recommended method.
• Relatively low bandwidth

Cons:

• May not be supported by very old IVR systems

---

ii) In-Audio (Inband)
Inband sends the actual, audible DTMF tones directly within the primary audio path, treating them exactly as if they were part of your speech.

Pros

• Universal Concept
  Mimics traditional phone lines, making it compatible with older systems.
• This method is a simple fallback and a good troubleshooting option if out-of-band methods fail.

Cons

• Codec Dependent
  Only works reliably with uncompressed codecs, such G.711u. Tones will be distorted by compression.
• Uses more bandwidth than sending data packets.

---

iii) SIP INFO
Out-of-Band (as SIP Message)
This method sends the DTMF digits using a special SIP INFO message, which is a command sent separately from the audio stream.

This method also sends the DTMF tones out-of-band, but instead of using RTP packets, it uses SIP INFO messages, which are part of the call (Session Initiation Protocol or SIP) control signalling.

SIP INFO is generally reliable as it also avoids audio codec issues. However, support for SIP INFO for DTMF is less universal across all providers and equipment compared to RFC 2833. I've tested SIP INFO DTMF and found it works with FPL's voicemail system, but RFC 2833 is usually preferred for broader compatibility.

When VoIP and SIP were first developed in the late 1990s and early 2000s, many technical standards were still incomplete. At that time, voice calls used RTP streams to carry audio, but there was no standard method for sending key presses needed for phone menus. To address this, SIP INFO was introduced (RFC 2976). It allowed phones to send key press information as separate SIP messages during a call. For example, when a person pressed "5," the phone would send a special SIP INFO packet to inform the system. However, in real-world VoIP networks, SIP signalling often travels separately from audio streams and can experience delays, packet loss, or be blocked by firewalls and other network devices. Some systems require multiple SIP messages for a single key press, while others expect only one, leading to compatibility problems, especially with automated systems such as banking menus. A better method was later developed, called RFC 2833 (also known as out-of-band RTP). It sends key press signals as special RTP packets separate from the regular audio data but within the same RTP stream. Because these signals are not treated as audio, they avoid distortion from voice compression and are much more reliable, even under less-than-ideal network conditions. Today, most phone systems and automated menus expect key presses to be transmitted using RFC 2833/RFC 4733 (NTE).


Pros

• This is a standardized, official, out-of-band method.
• Keeps DTMF signalling entirely separate from the audio path.

Cons

• Not universally supported by all VoIP providers and gateways. It's outdated.

---

iv) negotiate with peer (newer Grandstream ATA models than HT-286)
The Grandstream ATA attempts to automatically negotiate the best DTMF method with the other end of the call. In this mode, the ATA attempts to automatically negotiate the best DTMF method (RFC 2833, In-Audio, or SIP INFO) with the system on the other end of the call during the initial call setup.

Pros

• In theory, negotiate with peer should work without manual configuration.

Cons

• Negotiate with peer can be a frequent cause of intermittent DTMF problems. The negotiation can fail or become confused when a call is transferred.

[Liptonbrisk]

For DMTF (key presses not recognized) bank issues, try these steps:


1a) Dial ***
b) Then dial 02
c) Enter the IP address you hear into a web browser.
d) Login to your ATA.

Default login password is admin.

2. Navigate to Advanced Settings tab used for Freephonline-->Advanced Options-->Preferred Vocoder

a) Ensure every choice is set to "PCMU".


The only codecs that Freephoneline supports are G.711u (PCMU) and G729a (which sounds worse than PCMU).

Don't use G729a for banking or DTMF. I would set all choices to PCMU.


3. Scroll down to "Send DTMF".

a) Select "in-audio"
b) uncheck "via RTP (RFC2833)
c) uncheck "via SIP INFO".

When using In-Audio, do not use speaker phone (hands free) when pressing numbers. In-Audio is generally considered the least reliable DTMF method, especially if a compressed audio codec (such as G.729a) is being used. The compression process can distort the precise tone frequencies, making them unrecognizable to the receiving system. Inband might work passably well if G.711u is being used exclusively, but network issues (on your LAN or ISP), including packet loss, can still degrade the tones.

4. Click "Update" and "reboot".

5. Click "Apply" and "Reboot"

Afterwards, I would consider selecting/checking "via RTP (RFC2833)" again if "in-audio" doesn't work for a specific IVR (interactive voice response) system you're dialing into. Remember to click "Update" afterwards.

---
You can check whether all phone buttons are recognized by calling the free 416 or 250 numbers listed at http://thetestcall.blogspot.com. Wait for voice message. Press # to end echo test.
Press 2 to enter DTMF testing. Press all digits on phone number pad. Press #. What you pressed should be read back to you.
If that works, then all the buttons on your phone are fine, and the current DTMF setting the ATA is using worked for the specific system (not your banking system) being called.