[SPA122] Number key presses not recognised for phone surveys, services etc

[Erft]

I've seen a couple of posts from 2010 and 2013 that seem similar to this, but I couldn't see any resolution...

So, we all know how important it is that the touch tone numbers we press be recognised when we're navigating a phone tree system. For the most part, my number presses are usually recognised by the system and I can find my way to the department I need. But sometimes they're not. And sometimes they will be for part of the way, but not all. Or usually, I'll get to talk to whom I want, and then there's a survey at the end, and my number presses aren't recognised. Also, when a robo survey or poll comes calling, it doesn't recognise that I've pressed a number.

For example, with my Service Ontario call today, I got through the phone tree and was asked if I want to answer a survey at the end of the call. I pressed "1" for yes, and it "heard" that — it told me to stay on the line after the end of my call. After the agent and I finished speaking, the survey started and it kept saying "We're sorry, we did not get a response from you," despite my pressing the number key.
Multiple businesses and services phone systems cannot "hear" that I've pressed a number, no matter how many times I press it. This can be scary when it's banking or a government service.

The problem seems to be how the tone is generated by the VoIP. Is there a way to change my ATA settings so my key presses will be recognised and accepted by all the phone systems?

I use a Vtech handset with a Cisco SPA 122.

[Liptonbrisk]

The problem seems to be how the tone is generated by the VoIP.

Your Vtech handset generates the audible DTMF tones. The Cisco SPA 122's job is to interpret those tones and transmit them over the internet to your SIP service provider. A problem can arise in how the ATA handles this transmission.

Is there a way to change my ATA settings so my key presses will be recognised and accepted by all the phone systems?

While using Auto for DTMF Tx Method is supposed to come close to accomplishing this, the reality is that it's impossible to guarantee acceptance by all phone systems with a single setting since different IVRs (Interactive Voice Response systems) can have unique or outdated configuration requirements. Your issue, where tones work initially but fail later (on a survey after speaking to an agent), often happens when the call is transferred to a different system that expects a different DTMF method than the one your ATA is using or has already negotiated.


There are two primary DTMF methods:

A) 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.

This 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 (such as a survey menu). Inband might work passably well if G.711u is being used exclusively, but network issues, such as 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.




B) 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 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




Cisco SPA122 DTMF Method Comparison

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

AVT 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:

• There was a SPA122 specific bug, supposedly. The ATA can sometimes fail to filter the original audio tone, sending a "double-digit" signal: https://community.cisco.com/t5/voice-sy ... -p/1997003. I suspect (but am not positive) this has been fixed in firmware updates, which is why I listed #1 below.
• Compatibility
  May not be supported by very old IVR systems

---

ii) InBand (as Audio)
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) 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) Auto
The SPA122 attempts to automatically negotiate the best DTMF method with the other end of the call. In this mode, the SPA122 attempts to automatically negotiate the best DTMF method (AVT, InBand, or INFO) with the system on the other end of the call during the initial call setup.

Pros

• In theory, Auto should work without manual configuration.

Cons

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

---

So, as a troubleshooting step, you try to avoid the Auto DTMF setting and manually set the DTMF Tx Method to AVT. If that fails for a specific IVR system or service, try InBand, but ensure your audio codec is set to G.711.




1) The latest firmware version for your ATA is located at https://software.cisco.com/download/hom ... .4.1%20SR5

I accept no responsibility for failed firmware updates. Instructions are here: https://www.cisco.com/c/en/us/support/d ... pa122.html.

Read https://community.cisco.com/t5/voice-sy ... -p/2260834 (possibly a firmware update might help, if you're using an old firmware version in your ATA)

If you do update firmware, then test DTMF using “Auto” again before proceeding.


2. a) Dial **** (four stars)
b) Then dial 110#
c) Enter the IP address you hear into a web browser.
d) Login to your ATA. (default username and password is admin)
e) Always choose the admin login and advanced view menus (select "advanced" in the upper right).

3. Navigate to Voice --> Line (the one used for FPL) --> Audio Configuration
Make the following changes
a) Preferred Codec: G711u
b) Second Preferred Codec: G711u
c) Third Preferred Codec: G711u
d) G729a Enable: no
e) DTMF Process INFO: no
This prevents the ATA from attempting to use this less-supported method, forcing it to use the more reliable AVT standard.
f) DTMF Process AVT: yes
This enables the processing of AVT events, which is Cisco's implementation of the RFC 2833 standard.
g) DTMF Tx Method: AVT
This forces the ATA to transmit all keypresses using the AVT/RFC 2833 standard.
h) DTMF Tx Mode: Normal
This mode is less restrictive than Strict and is known to resolve recognition issues, particularly with systems that might be sensitive to DTMF timing.
i) DTMF Tx Strict Hold Off Time: leave at default
Since this setting will be inactive when DTMF Tx Mode is Normal, there is no reason to change it from its default value.

4. Submit settings, and reboot ATA.

5. Do not use speaker phone (hands free) when pressing numbers.

6. And if that still doesn't work, you can try "DTMF Tx Method: Inband". However, AVT is more likely to work for you, overall.

7. Lastly, the Vtech handset itself might be generating tones that are too short for some IVR systems to recognize as well (I think that's less likely in this case to be your issue though). You may want to look for increasing the tone duration in the handset's settings, if the option exists (I don't know your phone). That's not an ATA setting.

8. You can also test DTMF by calling the Toronto or B.C. numbers from https://thetestcall.blogspot.com/.
Wait for the beep, press #, and then press 2. Then press every single digit on your phone. Then press #. Wait to hear if each button was successfully pressed. Then end the call. That way you can test to ensure DTMF is working properly--for that specific IVR system.

[Erft]

Hi Liptonbrisk, thanks for jumping in to help me with this.

Major roadblock to figuring anything out: I am unable to access my ATA settings.
I went into router settings to see what the assigned IP address is since the one it's supposed to be, timed out. I copied and pasted the new IP address, and it still timed out. I confirmed it by dialing into the configuration menu on my analog phone.

I got a new router (cbn CH8568 Docsis 3.1) when I got Teksavvy service about 7 months ago. I have old security cameras that only work with older routers, so I've bridged the new router to my TL-WR841N so I can continue using them. I don't know if that could have messed with the ATA. It doesn't make sense to me that even though I'm trying to access the ATA settings on the IP address the router tells me it's assigned, I still can't get in. Also, Teksavvy had me alter the setup a little. This is the first time I've tried accessing ATA settings since I got Teksavvy.

Now it goes:
-Cable to modem
-Modem to router
-Router to ATA
-Router to PC

It used to go:
-Cable to modem
-Modem to blue ATA
-Yellow ATA to blue Router
-Yellow router to PC

Not able to get into the ATA settings on my PC (Chrome and Edge)...

Can you offer any help with this?

[Liptonbrisk]

A) Does step 2 from my previous post not work?
i) Dial **** (four stars)
ii) Then dial 110#
iii) Enter the IP address you hear into a web browser.
iv) Login to your ATA. (default username and password is admin)
v) Always choose the admin login and advanced view menus (select "advanced" in the upper right).


B) Alternatively, refer to step 1 from the PDF guide located at download/file.php?id=1742

(If the steps below don't work, set your PC’s IP to 192.168.15.2 with subnet 255.255.255.0; revert back to obtain an IP address automatically after configuring your ATA.)

That is,
i) Connect an ethernet cable from your computer directly to the yellow ETHERNET port on the back of the SPA122.

ii) Ensure your computer is set to obtain an IP address automatically (DHCP enabled).


iii) Access the web interface

iv) Open a web browser on your computer

v) Enter the default IP address: 192.168.15.1

vi) Enter the login credentials:

Username: admin

Password: admin

(those are default values)

https://www.cisco.com/c/en/us/support/d ... pa122.html

[Erft]

Thank-you.
Regarding step 2; before I posted my reply, I did the first part (****, 110#) to confirm the IP address. I was very uneasy about making the changes you listed, through the IVR if I still wasn't able to access the admin settings through web browser, so I decided to keep trying for a visual interface.

By changing the PC ethernet cable from the blue ATA port, to the yellow ATA port, I was able to access the SPA122 admin settings with the 192.162.15.1.
Should I just keep it like that? PC internet, phone, and wifi are all still working fine.

I made the changes you listed, clicked "Submit", and then I just got a blank page with the Setup, Network, Voice etc headings at the top. The modem didn't reboot, but when I tried to go back into Line 1, I was booted out. So I logged back in and, since no changes had taken effect, I made them again. This time the ATA rebooted when I clicked "Submit". I tested the DTMF and it works...with that system, as you say. So I take heart from that success.

Regarding the firmware update; my ATA's firmware is out of date (present update is 1.4.1 SR5, and mine has 1.3.3 (115)). Since you help a lot of older people with their phone lines, I'm sure you are familiar with people being nervous about making changes to the technology. I am willing to update the firmware but I am nervous. You made a disclaimer before, so I don't hold you responsible if things go belly-up, but in your opinion, do you think it will improve things further? Is there a lot to gain from a firmware update?

[Liptonbrisk]

Thank-you.
Regarding step 2; before I posted my reply, I did the first part (****, 110#) to confirm the IP address. I was very uneasy about making the changes you listed

For step 2, in my initial response, there are no changes. You're just accessing the ATA via its Web UI.
Anyway, if step 2 doesn't work, I suspect two different subnets in conjunction with a double NAT is the likely cause of your inability to access your SPA122 ATA’s web interface from your PC, given your current network setup. Double NAT occurs when you have two routers in sequence, each creating its own private network (subnet) and assigning IP addresses via DHCP. Devices connected to the second router (your TP-Link) are on a different subnet than those connected to the first router (your CBN CH8568). If your ATA is connected to the TP-Link router and your PC is connected to the Teksavvy router (or vice versa), they may be on different subnets and cannot communicate directly.

If the IP addresses assigned to your PC and ATA are in different subnets (ex. 192.168.0.x vs. 192.168.1.x), you have double NAT.
If you can access the internet from both, but not local devices across routers, this is a classic symptom.

You could set your TP-Link router to Access Point (AP) mode (not router mode). This disables its NAT and DHCP, making all devices part of the same subnet as your Teksavvy router. Alternatively, connect both your PC and ATA directly to the Teksavvy router.

After making these changes, reboot your devices and check the IP assignments. They should all be on the same subnet (ex. 192.168.0.x).


Using a ethernet cable between the PC and the ATA, and accessing it via 192.162.15.1, bypasses that problem.

By changing the PC ethernet cable from the blue ATA port, to the yellow ATA port, I was able to access the SPA122 admin settings with the 192.162.15.1.
Should I just keep it like that? PC internet, phone, and wifi are all still working fine.

Yes, that's fine.

I tested the DTMF and it works...with that system, as you say. So I take heart from that success.

Well, it's success with that specific IVR system that you called into. That doesn't mean the survey IVR works for you.

Regarding the firmware update; my ATA's firmware is out of date (present update is 1.4.1 SR5, and mine has 1.3.3 (115)). Since you help a lot of older people with their phone lines, I'm sure you are familiar with people being nervous about making changes to the technology. I am willing to update the firmware but I am nervous. You made a disclaimer before, so I don't hold you responsible if things go belly-up, but in your opinion, do you think it will improve things further?

Never update firmware if there's even a tiny chance of a power outage occurring. So if there's a storm in your area, if you see lights flickering, etc., don't perform a firmware update. Your ATA and PC must not lose power or turn off in the middle of a firmware update.

If all IVR systems that you dial into work as expected now, then there's no need to trying updating firmware. If they still fail and if both AVT and InBand also fail to work for you (after testing with each DTMF method, respectively), then, yes, I would update firmware to see if anything improves.

Otherwise, in your case, I probably wouldn't bother.

Is there a lot to gain from a firmware update?

As I noted previously, bug fixes, for one.

https://community.cisco.com/t5/voice-sy ... -p/2260834

Updating firmware to 1.3.1 or higher will fix DTMF issues

.

[Erft]

Thank-you Liptonbrisk.
Yes, I am able to access my ATA's web interface now that I have the PC ethernet cable going into the yellow port on the back of the ATA. What you say about different subnets makes sense. I don't understand all you tell me, but that little piece makes sense.

The next time I choose to do a customer service survey, I'll be interested to see if it works. Sometimes the key presses are accepted, sometimes they're not. But I did make those changes you said to make, and hopefully that'll get all key presses accepted. If not, I guess I try "g) DTMF Tx Method: AVT" changing AVT to Inband and see how that works?
Should I try changing "f) DTMF Process AVT: yes" to "No"?

[Liptonbrisk]

If you change the DTMF Tx Method to Inband, then yes, set DTMF Process AVT to “no” since you no longer want the ATA to generate or process AVT events but, instead, want the ATA to pass the actual audio tones through unchanged.

If AVT does not work,
1. Set DTMF Tx Method to Inband
2. Set DTMF Process AVT to no
3. Ensure your Preferred codecs are set to G.711u (mandatory for Inband DTMF to work reliably)
4. Save settings, and reboot the ATA

Do not change DTMF Process AVT to “no” while still using AVT as your transmission method. That would disable AVT DTMF entirely, and your keypresses would not be sent as RFC 2833 events, likely breaking DTMF for most IVRs.

Inband is considered less reliable overall than AVT though.

[Erft]

Thank-you.

[Liptonbrisk]

You’re welcome!