HT801 not working with TD online banking security code

[torontovoipnewuserx]

Hi, I think the Fongo Home Phone, or the hardware HT801, is not working with TD Canada Trust online banking login security code retrival.

I used my Fongo Home Phone number to receive TD Canada Trust online banking login security code.

So TD Canada Trust called this number. When I picked up the phone, instead of TD Canada Trust directly reading out the security code, like most other online sites do, TD Canada Trust, annoyingly, is asking me to press a key first, before it proceeds to read out the code.

I pressed the key. But then voice prompt continued to ask me to press the key. Seems it does not received the expected DTMF signal, or whatever.

Has anyone run into such issue?

[Liptonbrisk]

I don't have Fongo Home Phone or do business with TD, but you have described the issue perfectly, insofar as the problem is likely related to DTMF, and the problem may be isolated to the system that TD uses. That is, if everything else works (Fongo's voicemail system, for example), I'm not sure you'd want to request that Fongo change a DTMF setting in the ATA that breaks everything except for TD.

You can test 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 that specific system. You'd have to submit a ticket to Fongo.

Since you can't change DTMF settings in the ATA yourself (since the ATA is linked to the provisioning server, I suspect whatever changes that can possibly be made by the user do not persist) there's nothing you can do except to report the issue to Fongo to ask whether they can reproduce the problem and possibly fix it for you: https://support.fongo.com/hc/en-us/requests/new. Not having Fongo Home Phone work properly with TD is a pretty big deal. That's an issue worth reporting, in my opinion.

[torontovoipnewuserx]

I did a DTMF signal test at 416-342-9562. Everything seems fine with HT801. The system correctly reported back the button I pressed.

So I guess TD Canda Trust must be using another (old ancient) way to receive DTMF singal, which unfortunately caused problem here.

To bad Fongo Locks HT801. Otherwise I would like to log into the admin portal of HT801, and find out what way it uses to process DTMF.

How come the No. 2 bank in the country, TD Canada Trust, did not fully test its system, to ensure the widest compatibilty, before it releases its products! TD Canada Trust must cheap out in software SQA testing, in order to save money. Shame on TD!

[Liptonbrisk]

So I guess TD Canda Trust must be using another (old ancient) way to receive DTMF singal

It's possible TD works with Inband DTMF and not RFC2833. I have no way of testing.

To test that theory, in the Grandstream ATA Web UI, you'd need to find the "Preferred DTMF Method" priorities found under the FXS Port tab.

"Preferred DTMF method
(in listed order):"

To test, Priority 1 should be "In-audio" for TD, and then, I guess, change "Priority 2" to "RFC2833" while testing. If that doesn't work, I would give up and revert settings to what they were.

Inband doesn't work with the G.729a audio codec because it's a very lossy codec, and I'm pretty sure Fongo's voicemail system doesn't work with Inband (or In-audio) DTMF. Inband doesn't work with Freephoneline's voicemail system.

Fongo Home Phone and Freephoneline support G.729a, but I always disable it because I hate the way it sounds. Anyway, for compatibility with G.729a, they use RFC2833.

I'm not sure whether changing Inband to priority 1 would prevent Fongo's voicemail from working.

When Inband is used, the touch tone is sent in the audio stream as was done with traditional POTS (plain old telephone service) or as how one could imagine playing back tones from a recording.
When RFC2833 is used, an RTP event is produced that signifies the DTMF key pressed by the user.

To bad Fongo Locks HT801. Otherwise I would like to log into the admin portal of HT801

I am sympathetic to this.

and find out what way it uses to process DTMF

I suspect priority 1 for Fongo Home Phone is RFC2833.

[torontovoipnewuserx]

I have a FreePhoneLine account and an OBI-200 box. I found they can deal with TD Canada Trust's online banking login secure code retrieval flawlessly. I never have to mess with the DTMF stuff in OBI-200. OBI-200 just can deal with it effortlessly 100% of the time.

So what gives here? The glossy shiny new HT801 box actually is much inferior to the 10+ year old plain dusty (but still faithfully reliable and much much more feature-rich) OBI-200 box? Don't tell me that HT801 is just a pile of stinking turd in a glossy box, with an extremely limited list of features.

[Liptonbrisk]

I have a FreePhoneLine account and an OBI-200 box. I found they can deal with TD Canada Trust's online banking login secure code retrieval flawlessly. I never have to mess with the DTMF stuff in OBI-200. OBI-200 just can deal with it effortlessly 100% of the time.

I use OBi202s for analogue stuff with Freephoneline (such as faxing), and they continue to be the most powerful ATAs intended for residential usage for Freephoneline (along with OBi302s). It’s unfortunate they’ve been discontinued.

I also wanted Obihai IP phones before they disappeared (also discontinued) completely and found OBi2182s fairly cheap at Newegg Canada before they sold out last year. You can’t fax with IP phones or record calls with an OBi2182, but like the rest of the Obihai series, call routing is exceptional.

So what gives here? The glossy shiny new HT801 box actually is much inferior

With respect to call routing features, all other ATAs intended for residential usage are inferior, frankly.

HT-801 supports G.722 audio codec, unlike the OBi2xx series, but Fongo doesn’t support that codec anyway.
OBi2182 does support G.722.

Anyway, the HT-801 may require a firmware update to address this issue, or the DTMF and/or codec settings being used by Fongo Home Phone for TD need to be changed in the HT-801.
I don’t have a HT-801 or use TD, so I have no way of testing. While I appreciate the situation is frustrating, I suggest becoming angry at the HT-801 isn’t going to solve anything. I would submit a ticket.

[cod con]

Fix to: HT801(HT802 in my case) not working with TD online banking security code
I am using FreePhoneLine & I have access to my adapter settings.
Solution inspired by:
https://networkengineering.stackexchang ... inistation
I have changed only 'Disable DTMF Negotiation:' from No to Yes & it seems to work.

[Liptonbrisk]

Out of curiosity, what happens if you disable priority 2 and priority 3?

That is, try to figure out whether TD is using RFC2833 or Inband (in-audio).

Test with Priority 1 is set to RFC2833. Then test again with Priory 1 set to In-audio.
You can keep DTMF negotiation setting disabled (set to “yes”) while testing.

Anyway, thanks for posting. Fongo Home Phone users will be forced to submit tickets to request setting changes.

[cod con]

In my case.
Change order/disable other 2 Priority did not produce any results.
I do not have a fully technically explanation
for the solution but, it works(at least for me).

[Liptonbrisk]

Thanks for testing and posting your solution.

The results don’t make sense to me, unless an ATA firmware bug exists.

[cod con]

HT801/(HT802 in my case) not working with Simplii Financial online banking security code.
It looks being a similar issue as TD online banking security code.
Has anyone run into such issue?
I am posting here because I did not find a specific tread. If it is OK posting here, I will come back with more details.

[Liptonbrisk]

Latest firmware version is 1.0.61.5: https://www.grandstream.com/support/firmware

What version are you using?

Theoretically, RFC2833 should work.

Are you not using the same settings that you were using with TD?

If you want to use in-audio, then it's important to use the PCMU (G.711u) codec only. Don't use G.729a or anything else.

RFC2833 for DTMF is more likely to work.

[cod con]

Upper Fix to: HT801(HT802) is mine.
My latest firmware version is 1.0.61.5
Yes, Pref DTMF is RFC2833. From last 2-3 month I have started having failure. From 10 calls 1 or 2 get trough.
Sometime am rejected because the high nr call failure.
The other options(ex: sending card nr info) of their phone system working just fine.
If I change DTMF to In-audio /Priority1 & RFC2833/Priority2 it seems working fine, but, because of that other service not working(KeepCalling & TD)
They do not get the key signal.
Also, I have tried(with no results) tuning some parameters inspired by:
https://networkengineering.stackexchang ... inistation
I have called Simplii Financial for this issue & their answer was Freephoneline/Fongo do not allow this signals passing trough. ???
Sill, has anyone other than me, run into such issue?

[Liptonbrisk]

Your phone generates the audible DTMF tones. Your ATA'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.



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.

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 (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




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
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]

If I change DTMF to In-audio /Priority1 & RFC2833/Priority2 it seems working fine, but, because of that other service not working(KeepCalling & TD)
They do not get the key signal.

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.

If you want to use In-Audio (Inband), change Preferred Vocoder (in listed order) in your ATA to all PCMU. Never use G729 for anything (it's an inferior lossy audio codec anyway). Inband is the same as sending tones along with your voice. It's typically the least reliable method, but it depends on the IVR system that you're calling.

When using In-Audio, do not use speaker phone (hands free) when pressing numbers. In-Audio 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 (on your LAN or ISP, such as packet loss, can still degrade the tones.

I have called Simplii Financial for this issue & their answer was Freephoneline/Fongo do not allow this signals passing trough. ???

No, that rep just wants to get you off the phone.

I just asked someone to test with Simplii, and that person didn't have a problem using Freephoneline. An Obihai ATA was used (Poly 4xx series ATAs have replaced them). Oddly, RFC 2833 works for inputting the card number but not the PIN. In-Band (In-Audio) works for both. Auto (in Obihai ATAs) works for both.

So,configure DTMF to force In-Audio
On the FXS Port page, apply the following settings.
1. Preferred DTMF method
Set the priority order to make In-audio the primary choice.
• Priority 1: In-audio
• Priority 2: RFC2833
• Priority 3: SIP INFO

2. Disable DTMF Negotiation
Change this setting to Yes. This forces the HT-801 to use your preferred method (In-audio) without trying to negotiate with the bank’s IVR system.

3. Preferred Vocoder (Codec)
To ensure the highest quality for In-audio tones, set the codec priority to an uncompressed format.
• Choice 1: PCMU (also known as G.711u)
• Choice 2: PCMU (also known as G.711u)

Actually, ensure all choices are PCMU.


4. Inband DTMF Duration
The default is 100ms. If you still have issues, you can try changing this value to 50ms.

Step 5. Apply and Reboot
a. Scroll to the bottom of the page and click the Apply button.
b. Reboot the device when prompted to ensure the new settings take effect.

That may help with Simplii, but I don’t suggest those settings will work universally well for everything.

For In-band to work, you need to be using PCMU, not be using handsfree speaker, and have excellent, reliable bandwidth without ping spikes and tons of jitter.

It seems that although SImplii's IVR system accepts RFC 2833 for the card number, PIN acceptance doesn't. In-Audio (Inband) can work for both, but it's trickier to use In-Audio.

The question to ask Simplii is why does their IVR accept RFC2833 for the card number and not for the PIN. Of course, most people there won't know. To me, these results suggest that their IVR system is misconfigured.

[cbcaccount]

That's what I'm experiencing too. Only in my case it's with Simplii Financial and Fido.

[Liptonbrisk]

I ran this scenario through A.I., and it's basically confirming what I thought.


```
Short answer
The bank's IVR drops RFC 2833 events during the PIN prompt, so only in-band tones survive.

Why your PIN fails with RFC 2833 but works in-band

1. Two different DTMF paths are colliding – Your VoIP adaptor sends the 16-digit card number as RFC 2833 packets that the IVR accepts, but the PIN digits are stripped so only silence reaches the tone detector.
2. What happens inside Simplii’s IVR – The IVR uses separate packet and audio detectors, and a mis-configured gateway routes the PIN phase to the audio detector while still discarding the packets.
3. Why Rogers/Fido mobile users see the same symptom – Rogers converts keypad presses into RFC 2833 events so the same Simplii gateway bug drops them before the audio detector can react.

Work-arounds you can use

• For SIP or ATA calls, enable in-band DTMF only when dialling Simplii, ensuring real tones traverse the network and reach the IVR.
• On mobile, enable any “send tones as audio” option or make the call through Wi-Fi calling on a different carrier to bypass the Rogers core.
• On a PBX trunk, force G.711 and regenerate tones locally to guarantee clean in-band transmission even if the remote end ignores RFC 2833.

What Simplii or its carrier needs to fix

• Configure the SIP-PSTN gateway to pass RFC 2833 packets during the PIN phase instead of stripping them, a setting many vendors call “telephone-event passthrough after media cut-through”.
• Ensure the IVR advertises one consistent DTMF delivery method for the entire call, because mixing methods mid-call confuses third-party equipment.

Key take-away
The problem resides in Simplii’s gateway configuration, so until they correct it the safest tactic is to send real audio tones for the PIN prompt.


Why the mobile-only workaround is unrealistic for most users

- The option to force a handset to emit audio DTMF is hidden or missing on many recent Android and iOS versions, so most people never see it in the settings menu.

- Even when a menu exists, modern LTE / 5G phones still strip tones once the call enters the carrier core, because the network converts them to Out-Of-Band events before leaving the carrier.

- Wi-Fi Calling routes the call through the same IMS core, which applies identical DTMF conversion, so the problem usually persists.

- Because success depends on handset model, OS build and carrier provisioning, support staff cannot give universal instructions, leaving most customers stuck.

Practical alternatives that *are* feasible
- **Use a land-line or VoIP desk phone set to in-band DTMF** – Dial Simplii from any wired phone or ATA you control to ensure real tones traverse the PSTN untouched and reach the IVR’s audio detector.

- **Call Simplii with a softphone app that lets you force G.711 + in-band** – Some apps can send RTP directly to Simplii’s SIP edge, bypassing carrier DTMF conversion.

- **Ask Simplii to enable voice-recognition PIN on your account** – Customer service can flip the IVR to voice PIN instead of DTMF, eliminating tone issues completely.

- **Use the web or mobile banking app for PIN-gated tasks** – Logging in online avoids the IVR path and its DTMF bug entirely.

Bottom line
Because carriers forcibly translate keypad presses into Out-Of-Band events deep inside their networks, end-users have little control over DTMF delivery on mobile calls; the sure-fire fixes are to place the call from equipment where you can dictate in-band tones, or to bypass DTMF entry altogether via voice recognition or online channels.


```

[Liptonbrisk]

That's what I'm experiencing too. Only in my case it's with Simplii Financial and Fido.

A friend just confirmed the same thing is happening on Telus and Bell.

Simplii's IVR is messed up. It's misconfigured.

The IVR accepts RFC2833 DTMF method for the card number, but it only works for In-band DTMF method for the PIN.

Good luck trying to explain to an average Simplii rep why the problem exists.

"The problem resides in Simplii’s gateway configuration, so until they correct it the safest tactic is to send real audio tones for the PIN prompt."

But they should understand that PIN entry isn't working for anyone one a cell phone. They should be able to understand that. At some point they're going to have to fix it. Too many people are going to complain.


A.I. Analysis follows:


Short answer
Telus, Bell, and Rogers all transport DTMF digits as out-of-band signaling events, so long card numbers register correctly at Simplii’s IVR while short PIN tones are stripped and not detected.

1. DTMF in Cellular Networks

1. Modern 3GPP networks send keypad presses as control messages (e.g., FACCH or RRC frames) rather than as in-audio tones, regenerating perfect dual-tone audio at the gateway.
2. In VoLTE calls, carriers encapsulate DTMF as RTP telephone-event packets (per RFC 2833/4733) across their IMS core.

2. Why Card Numbers Always Succeed

• Simplii’s IVR uses a packet-based detector for long digit strings, which listens for out-of-band events and regenerates precise audio tones for the IVR engine.
• Carrier networks reliably deliver these events intact, so the IVR registers all 16 card digits without error.

3. Why PIN Entry Fails

• During the PIN prompt, Simplii switches to an in-band tone detector that expects audible DTMF frequencies, but carriers strip raw audio in favor of digital event signaling.
• As a result, the IVR’s tone detector “hears” silence for the short PIN sequence, causing authentication to fail.

4. Work-arounds

• Use a landline or VoIP ATA configured for in-band DTMF so real tones traverse the PSTN untouched and reach the IVR’s audio detector.
• Call via a softphone app set to G.711 + in-band DTMF, bypassing carrier event conversion entirely.
• Perform PIN-protected tasks online or via Simplii’s mobile app to avoid the IVR path and its DTMF issue altogether.

[Liptonbrisk]

A.I. explanation for why Obihai/Poly 4xx ATA "Auto" DTMF mode works while Grandstream's fails is this:



Review of DTMF Handling Differences Between Poly (Obihai) and Grandstream ATAs

1. Poly (Obihai) 4xx ATAs: Dynamic DTMF Adaptation
Poly ATAs (such as the OBi series) support all common DTMF transmission methods—RFC 2833, in-band audio, and SIP INFO—and negotiate these options at call setup. What sets Poly apart is its ability to monitor DTMF effectiveness during a live call. If the remote system stops responding to the initially negotiated method (like RFC 2833), the ATA automatically switches to another supported method, such as in-band audio. This adjustment happens without user input and ensures continued DTMF functionality even when the far-end system's expectations change mid-session.

2. Grandstream HT801/HT802: Static DTMF Negotiation
Grandstream ATAs also support the same DTMF methods, but their "Auto" mode is much more static. The HT801 and HT802 perform a one-time negotiation at call setup based on a user-defined priority order. After that, the selected DTMF method remains fixed for the duration of the call. If the receiving system later changes its DTMF handling—for example, by stopping RFC 2833 support—these devices continue sending tones in the originally chosen format, which can result in DTMF input failures.

---

Key Feature Comparison

Code: Select all

| Feature                | Poly (Obihai) ATAs          | Grandstream HT801/HT802        |
| ---------------------- | --------------------------- | ------------------------------ |
| DTMF Methods Supported | RFC 2833, in-band, SIP INFO | RFC 2833, in-band, SIP INFO    |
| Negotiation Approach   | Dynamic, adaptive           | Static, one-time at call setup |
| Mid-Call Adaptation    | Yes, auto-switches methods  | No, fixed after call starts    |
| Fallback Mechanism     | Automatic to next method    | None                           |
| 

---

Conclusion
Poly (Obihai) 4xx series ATAs offer a more robust and flexible approach to DTMF signaling. Their dynamic adaptation allows DTMF tones to continue working even when the receiving system's expectations shift during the call. Grandstream’s more rigid design, while sufficient for simple IVR systems, can lead to failures in complex or stateful IVRs that change how they accept DTMF inputs mid-session. For environments where consistent DTMF reliability is critical, especially in banking IVRs or complex menu systems, Poly ATAs provide a clear advantage.