Grandstream HT801 not provisioning. Its been 7 days.

[fatimapabani12]

My HT801 is not working. Its been 7+ days. I just wanted to set up DMTF dialing so that I could use touch tone when selecting menus. First off, how ridiculous is it that you cant even select menus with touch tone when dialing with Fongo? Anyway, I read on the internet that I have to go into the admin settings and change a setting there. Admin user and pass doesnt work. So I read - I have to reset the modem to get into the web based settings. I click the pin at the back and reset. Now I cant make any calls when turning it back on. Reset the device maybe 30 times so far, still cant make calls (busy line).

I check the admin settings:
Provision: Not running (Last status: Downloading file from URL)
Registration: Not Registered

For SEVEN days now despite repeated support tickets, no one is doing anything. Apparently after 10 hours of research, I find out that Fongo has to re-provision my device. There is nothing I can do except wait for someone to acknowledge my ticket and do this for me.

I am at my wits end and want to make a complaint with BBB. This is ridiculous how much time I have wasted. Every support ticket I get a stupid generic reply that is absolutely not helpful telling me to go check the online status (and of course, all systems are working except my phone).

WHAT THE HELL?
There is no phone number, no way to reach anyone, no support, nothing. Why is this so difficult? How many more hours of my life am I supposed to waste on this?

[Liptonbrisk]

You posted in the Freephoneline forum. Based on your post, with a description of you expecting Fongo to provision your ATA, I've moved your thread to the Fongo Home Phone forum.

Are you using Freephonline or Fongo Home Phone?

1) There is no technical support at all for Freephoneline, and Freephoneline users need to configure their ATAs themselves. Freephoneline requires owning a VoIP unlock key. Your ATA"s configuration guide is location at viewtopic.php?p=79162#p79162. After following that guide, If you continue to experience registration issues, as a Freephoneline user, visit viewtopic.php?t=20539, and follow the steps by step down the list. After successfully registering, visit viewtopic.php?p=82961#p82961 to learn how to configure your ATA's DTMF settings.

2) If you're using Fongo Home phone, this is the escalation process: https://support.fongo.com/hc/articles/2 ... -Complaint. You will not resolve your problem by filing a complaint with BBB. You might with CCTS.

If you're a Fongo Home Phone customer, you have two issues: A. Your ATA is unregistered. B. After the ATA is registered successfully, you should ask Fongo to configure your ATA as follows if you continue to experience DTMF banking issues to see whether those settings work for you: viewtopic.php?p=82961#p82961.


i) Dial ***
ii) Then dial 02

If you don't hear a LAN IP address, then your router isn't assigning a LAN IP to the ATA.

3) Refer to the LED pattern: https://documentation.grandstream.com/k ... ds-pattern

4) What does the LED pattern on the ATA indicate?

5) If the NET light comes on, but the phone light never does, that means the ATA isn't registered with Fongo's server.

6) With Fongo Home Phone, Fongo is responsible for provisioning your ATA. If If no one responds to your ticket, private message me with your ticket number. I can't promise that anyone else will look into the matter or respond to me (I don't work for Fongo), but I can try to notify someone. You can private message me your ticket number at ucp.php?i=pm&mode=compose&u=1229.

7) Once the ATA is registered successfully, ask Fongo to configure your ATA as follows if you continue to experience DTMF banking issues to see whether those settings work for you: viewtopic.php?p=82961#p82961.


--
(General Info)
These are user-to-user support forums. Fongo Support staff is not obligated to respond here, and there's no guarantee forum posts are read by staff.

Also, none of the volunteer moderators here work for Fongo. We don't have access to your account.


Fongo support tickets can be submitted at
https://support.fongo.com/hc/requests/new.

You can check your ticket status by logging in at
https://support.fongo.com/hc/requests. That's an account for tickets
(zendesk) only and is completely separate from your Fongo Home Phone account or
any other Fongo account you may have. If you don't have a zendesk account yet, click "Sign Up" after visiting the link.
Use the same email address that you use to submit tickets. Do not use the same password as your Fongo Home Phone
account. Again, these accounts are unrelated.

Support staff does not respond to tickets on weekends or Canadian holidays.
Support hours are 9 a.m. until 4 p.m. EST. They are not obliged to respond
on the these user-to-user forums.

[Liptonbrisk]

(continued)


Visit https://status.fongo.com/.
If "Support System" indicates "Degraded Performance" or "Partial Outage", ticket response time can take up to a week (or longer).

Fongo does have https://twitter.com/Fongo_Support. I'm not sure if anyone
there responds to direct messages.

Similarly, they appear to be on Facebook:
https://www.facebook.com/FongoMobile/. I don't know whether they'll respond to you there.

[Liptonbrisk]

First off, how ridiculous is it that you cant even select menus with touch tone when dialing with Fongo?

Depends on the system used.

viewtopic.php?p=82474#p82474

I haven't bothered testing Simplii's IVR system since June 2025, but Telus, Bell, and Rogers mobility (cellular) didn't work for entering the telephone banking password (or PIN) for Simplii back in June 2025 (possibly the problem is fixed now).

I'll give you an example with Simplii Financial: viewtopic.php?p=82474#p82474.
Fongo Home Phone (Grandstream HT-801), Telus, Bell, and Rogers mobility (cellular) don't work for entering the telephone banking password (or PIN) at this moment for Simplii.

Why?

Well, when you call and you're prompted for your card number, Auto DTMF Method works for the card number, but that doesn't work for the telephone banking password (or PIN).

Auto is vague and doesn't tell me what DTMF method specifically works.

So, I try RFC2833 (AVT). That works for the card number. However, RFC2833 (AVT) doesn't work for the telephone banking password.

That's messed up. The system they use to recognize DTMF for the telephone banking password should be configured in the same manner as the one used for entering the card number, but nope. The IVR system used for recognizing the telephone banking password doesn't work with RFC2833.

Inband works for both the card number and the telephone banking password, but really, Simplii should have RFC2833 (AVT) working for the telephone banking password as well.

That suggests that Simplii's IVR system is misconfigured: Telus, Bell, and Rogers cellular services do not work for entering Simiplii's telephone banking password (at this time). It's not just ATAs using SIP services (Fongo Home Phone) that don't work. Almost everything doesn't work at defaults-- except Obihai ATAs work with DTMF method set to Auto--for Simplii.

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. An 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.

[Liptonbrisk]

(General DTMF 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 (Fongo Home Phone/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]

These settings work for TD banking (Fongo has to configure this for Fongo Home Phone users):

viewtopic.php?p=82961#p82961

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".
.................

Hi Liptonbrisk

I've tried this and it worked perfectly. Thank you for your quick and detailed reply.