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.