[Resolved] Register Failed: 404 Not Found on April 11, 2025

[vostro]

obihai 202, freephoneline decade user, from today morning, not working any more. anyone else same?

[Liptonbrisk]

I'm seeing this in multiple Obihai devices and MicroSIP.

Checking something . . .

[Liptonbrisk]

obihai 202, freephoneline decade user, from today morning, not working any more. anyone else same?

I merged your post into this thread and changed the subject heading to reflect the error code.

[hanke]

SPA3102 - No registration this morning. I have changed servers and no change. I have another Freephoneline using Obihai 202 and that works fine! Rebooting modem/router changes nothing. I haven't got time to trouble shoot right now. I will keep an eye on this post.

[vostro]

I'm seeing this in multiple Obihai devices and MicroSIP.

Checking something . . .

thanks a lot for attention, two account in two obhi202 box display same "Register Failed: 404 Not Found". hope it could be sorted out soon.

[Liptonbrisk]

Registration user database appears to be offline. The servers can't find our usernames.
The issue is occurring within FreePhoneLine's SIP registration server system.

I've tried to contact someone.

Fongo Mobile is working.

[Liptonbrisk]

If anyone is interested, when your ATA, IP Phone, SIP app, or SIP client sends a REGISTER request, the FreePhoneLine proxy server (voip.freephoneline.ca:5060, voip2.freephoneline.ca:5060, or voip4.freephoneline.ca:6060) or Fongo Home Phone server needs to look up your username (15191234567, for example) in its user account database. This is to confirm the account exists and retrieve authentication details. If the user database for Freephoneline or Fongo Home Phone is offline, unreachable, or malfunctioning, the registration server can't perform the lookup. When it fails to find your user record, because the database lookup isn't responding, returning a 404 Not Found error is the logical outcome. The server concludes it can't find the user it was asked about.

Although only Fongo would know the exact internal cause, an inaccessible or faulty registration database is plausible for this kind of widespread registration failure producing 404 Not Found errors.

[Liptonbrisk]

I'll sticky this thread until the problem is resolved.

Fongo is looking into the problem.

[emailit]

My FPL this morning is offline with "Device not Registered" message. Rebooting ata does not solve the problem.
A friend uses Fongo Home and she is experiencing the same issue. Fongo''s System Status webpage indicates nothing.
Fongo Mobile appears to work, but I cannot call FPL number.

[Liptonbrisk]

My FPL this morning is offline with "Device not Registered" message.

Yes, no one can register because there's an issue involving the registration database.

If anyone is interested, when your ATA, IP Phone, SIP app, or SIP client sends a REGISTER request, the FreePhoneLine proxy server (voip.freephoneline.ca:5060, voip2.freephoneline.ca:5060, or voip4.freephoneline.ca:6060) or Fongo Home Phone server needs to look up your username (15191234567, for example) in its user account database. This is to confirm the account exists and retrieve authentication details. If the user database for Freephoneline or Fongo Home Phone is offline, unreachable, or malfunctioning, the registration server can't perform the lookup. When it fails to find your user record, because the database lookup isn't responding, returning a 404 Not Found error is the logical outcome. The server concludes it can't find the user it was asked about.

Although only Fongo would know the exact internal cause, an inaccessible or faulty registration database is plausible for this kind of widespread registration failure producing 404 Not Found errors.


I contacted Fongo shortly after 8:00 a.m. EST today. They are looking into it.

[Liptonbrisk]

The problem is resolved. If anyone is interested, Fongo's switch vendor, Porta, would have been responsible for addressing this problem.
https://www.portaone.com/

This is always proper device reboot order:

A.Turn off modem, router and ATA (or IP Phone or close SIP App).

B. Turn on modem. Wait for modem to be fully up and running.

C. Turn on router. Wait for modem to be fully up and transmitting data before turning on router.

D. Turn on ATA (or IP Phone or open SIP app) only after the router is fully up and running.

The SIP device (ATA, IP Phone, or SIP app) should be the last device powered on in the device chain.

Reboot your devices now. Thank you.

[vostro]

great to hear, much appreciated.

[Liptonbrisk]

thanks a lot

You're welcome!

[emailit]

Fongo Home customer still has no phone service after rebooting FHP ata several times. She cannot dial out, thou she has a dial tone, and when I try to call, I get a busy signal.

[Liptonbrisk]

Fongo Home customer still has no phone service after rebooting FHP ata several times. She cannot dial out, thou she has a dial tone, and when I try to call, I get a busy signal.

I don't have Fongo Home Phone, so I can't confirm whether the issue is fixed for those users. A Fongo admin told me the issue is fixed (also https://status.fongo.com/incidents/sRu0fdDAuj5F), so I can't contact Fongo again without this individual doing some troubleshooting first.

1) Does she have a Grandstream HT-701 or HT-801 ATA?

https://support.fongo.com/hc/en-us/arti ... First-Time

2) What brand and model modem is she using?

3) What brand and model router is she using?
Ensure SIP ALG is disabled in it. Contact the ISP if need be.
Refer to step 1a from viewtopic.php?t=20199 and point B from viewtopic.php?p=78976#p78976.

4) Reboot devices in the following order. This is always proper device reboot order to help resolve corrupted NAT associations and DHCP lease issues:

A.Turn off modem, router, and ATA.

B. Turn on modem. Wait for modem to be fully up and running.

C. Turn on router. Wait for modem to be fully up and transmitting data before turning on router.

D. Turn on ATA (or IP Phone or open SIP app) only after the router is fully up and running.

The SIP device (ATA, IP Phone, or SIP app) should be the last device powered on in the device chain.

E. Now check with an incoming call.


5) What does the light pattern on the ATA indicate?

a) For a Grandstream HT-801 ATA look at page 18 from http://www.grandstream.com/sites/defaul ... _guide.pdf

b) For a Grandstream HT-701 ATA look at pages 12 and 13 from https://www.grandstream.com/hubfs/Produ ... nglish.pdf

The power light should be solid on.

The internet light should be solid on (or flashing rapidly indicating traffic). If it's off that indicates an internet connection problem to the ATA.

The phone light should be solid on (green with HT-701 or blue with HT-801), indicating registration with Fongo Home Phone. If it's off, that means the ATA isn't registered.



If step 4 doesn't produce a solid green or blue phone led, let me know, and then I'll try contacting Fongo again. However, if the problem persists after step 4 and also while the ATA's phone led is solid green or blue, then she should submit a ticket: https://support.fongo.com/hc/requests/new. Have her request in the ticket to have her ATA register using sip2.fongo.com:6060 (that's the same as voip4.freephoneline.ca:6060 for FPL users, by the way) to see if that helps (also get SIP ALG disabled in the user's router).

Edit: I should have included step 4 in a previous post and will do so now.

--
(General info)

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 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 Freephoneline, 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 obligated to respond
on the these user-to-user support forums.

[Liptonbrisk]

Fongo Home Phone is working. I called a user. Worked fine.

[hanke]

The problem is resolved. If anyone is interested, Fongo's switch vendor, Porta, would have been responsible for addressing this problem.
https://www.portaone.com/

Reboot/restart your ATAs, IP Phones, SIP apps, or SIP clients if you're not registered. Thank you.

My service as of 1141am is working again. Thank you Liptonbrisk for getting this corrected with you contacting the back end this morning to report it to them and getting an explanation as to the problem.

[Liptonbrisk]

Thank you Liptonbrisk for getting this corrected with you contacting the back end this morning to report it to them

You're welcome!

and getting an explanation as to the problem.

That's my explanation; I haven't been provided with an official explanation. I checked my syslogs and could see the 404 error. I don't know what the official cause was, but I can see what happened between the SIP clients and proxy servers for REGESTER requests. The issue was occurring within FPL/Fongo's SIP registration server system, and the most likely explanation was an inaccessible (offline or faulty) registration database.

[emailit]

My friend's Fongo Home is now back working again. Definately an issue at Fongo's end. At 94 years young, these outages are beyond her tech capabilitites! The Fongo supplied ata is a HT-802 (I believe) and it was rebooted several times (the cable modem was not) when the phone said "device not registered". After when my FPL came back up, I called her and just got a busy signal. ATA was rebooted again but calling issues remained ... it seems to me that the phone line was locked out due to some unknown reason even thou the ata was now registered ... similar to when the Internet goes down when you are talking on the phone and you are locked out for many hours due to a "hang up signal" was never received.

Thanks for all you do Liptonbrisk.

[Liptonbrisk]

My friend's Fongo Home is now back working again. Definately an issue at Fongo's end.

Maybe you could test that for her next time by rebooting the modem/router combo (if it's Rogers, they call it a gateway) first and then rebooting the ATA after the modem/router combo is back up and running.

At 94 years young, these outages are beyond her tech capabilitites!

Oh, okay. I mostly wanted to know if the phone light on the ATA was solid blue or green, which would have indicated the ATA was registered. If it's registered, the problem is not related to the problem described in this thread, and then I can't contact Fongo about it.

The problem in this thread is due to lack of registration.

The Fongo supplied ata is a HT-802 (I believe)

https://support.fongo.com/hc/articles/2 ... First-Time

It's a Grandstream HT-801 then, if it's not an HT-701.

and it was rebooted several times (the cable modem was not)

It's likely not just a modem. It's a modem/router combo. If it had been rebooted first (wait for it to be fully up and running) before the ATA was that may have resolved the problem faster.

when the phone said "device not registered"

Okay, then, that's what I wanted to know--whether the ATA was registered when the incoming call was made. You can tell by looking at the phone led on the ATA.

it seems to me that the phone line was locked out due to some unknown reason even thou the ata was now registered

1. The ATA reboot forces the device to attempt registering again. Initially, registration was failing due to the inaccessible (offline or faulty) registration database. Once Porta (the vendor used by Fongo) fixed the problem, the ATA still needed to initiate a new connection attempt to become registered. Rebooting the ATA is the standard way to make a registration attempt immediately. So, the reboot allows ATAs to successfully connect to the now-functional Fongo Home Phone service to achieve a registered state. Alternatively, the ATA attempts to register again at the next registration interval automatically. Regardless, that only restores basic registration status.

2. I suspect it's likely corrupted NAT associations existed that eventually resolved (this is described somewhat in point D from viewtopic.php?p=78976#p78976, but because Fongo Home Phone uses a locked ATA, I don't know what precise values are used for that service) in your friend's router.

I suspect the issue causing the calling problems, after registration was restored, was a temporary problematic state within your friend's router related to its NAT or connection tracking tables. During the Fongo service disruption, the ATA's registration attempts would have received "404 Not Found" replies from the server. Receiving these replies, even though they were errors, typically causes the router to mark the NAT state for those failed communication flows as "Assured," which are governed by a significantly longer internal timeout (a common default is approximately 180 seconds) compared to connection attempts that receive no reply at all (called "Unreplied" UDP timeouts, which are often 30 seconds in consumer routers). Because only the ATA was rebooted after Porta fixed the underlying issue causing the 404s, the router itself never had its state cleared, meaning these lingering Assured NAT states, associated with the communication path between the ATA's internal IP and the Fongo server, persisted in its memory.

Even when the ATA successfully registered using a new local UDP port after the Porta/Fongo fix, these numerous stale Assured entries likely still existed and continued to consume resources within the router's limited NAT table. I believe this resource contention is the most probable reason why subsequent attempts by the ATA to establish new connections for actual call signalling or RTP media (originating from its current ports) failed, resulting in the busy signal. The router likely struggled to allocate new table entries or process traffic efficiently for the path from the ATA's IP to the Fongo server due to the congestion or problematic state flags caused by the old, not-yet-expired Assured entries. The problem eventually resolved itself naturally when the router's internal timers-–most plausibly the longer UDP Assured timeout governing those specific stale entries-–finally expired enough of them. This cleared the congestion or error state, allowing the router subsequently to establish fresh, clean NAT paths for the ATA's calls. In essence, it was a two-stage problem: first, the registration database outage causing 404 registration errors, followed by a temporary local network issue where stale router states, resulting from those errors, blocked calls until those states naturally timed out.

That is, the corrupted NAT association within your friend's router/gateway timed out naturally. NAT tables in routers keep track of active connections. Stale or problematic entries, such as the one causing the busy signal, don't necessarily last forever. Routers have internal timers and mechanisms to eventually clear out old or inactive connection states. Routers don't keep the information for these connection states forever (usually). These entries have built-in timeouts. After a certain period of inactivity or based on internal timers (which vary between router models), the router automatically discards old or inactive connection entries.



Fongo's Grandstream ATA configuration uses random local SIP (and RTP) UDP ports upon reboot, which can help resolve stale NAT association issues, but problems can still arise when the modem/router combo isn't rebooted first. When discussing NAT entries associated with the ATA's IP address, I am referring to the private Local Area Network (LAN) IP address assigned to the ATA by the user's router (ex. 192.168.1.105).

I'll provide an example using a probable mechanism for the problem with common default UDP timeouts (30s Unreplied/180s Assured) as placeholders for the potentially hard-coded, non-discoverable (at least, not easily by end-users) values in a Rogers gateway (modem/router combo).

Router's Public IP (from ISP) = ex. 173.32.128.20
ATA's Private LAN IP (from router) = ex. 192.168.1.105
Fongo Server= sip2.fongo.com:6060 (IP 162.213.111.21:6060); 6060 is the UDP port
Example UDP Ports = ATA source 51000; Router external 55123
Common UDP Timeouts (placeholders) in routers = Unreplied 30 seconds, Assured 180 seconds

A. During normal operation before the "404 Not Found" outage, the ATA (LAN IP 192.168.1.105) sends a SIP REGISTER from port 51000 to 162.213.111.21:6060. The router creates a NAT entry: [Internal: 192.168.1.105:51000] <-> [External: 173.32.128.20:55123] -> [Destination: 162.213.111.21:6060] | Protocol: UDP | Timeout: (Starts ~30s becomes ~180s if reply received). Fongo's proxy server replies successfully (ex. 200 OK). The router sees two-way traffic, marks the NAT state as "Assured", and, in turn, applies the longer 180s timeout.

B. During the "404 Not Found" outage (receiving 404s), the Fongo server at 162.213.111.21:6060 now has an issue and starts replying to REGISTER requests with "404 Not Found" errors due to the registration database being inaccessible or faulty. The Grandstream Ht-801 ATA (at LAN IP 192.168.1.105), likely retrying periodically from port 51000 (or a new UDP port after reboot), sends REGISTER. The server replies with 404. The router forwards this 404 reply to the ATA. Because the router sees this two-way traffic (request out, 404 reply in), it marks the NAT state for this specific failed attempt flow as "Assured" and applies the longer UDP Assured Timeout (ex. 180s) to that entry: [Internal: 192.168.1.105:51000] <-> [External: 173.32.128.20:55123] -> [Destination: 162.213.111.21:6060]. Each retry receiving a 404 could refresh this Assured state or create new ones. So, repeated retries refresh this state or create similar Assured entries, potentially using other UDP ports, if the ATA was rebooted during the outage.

C. After the Porta/Fongo fix and the ATA reboots, the 404 problem is gone. The ATA reboots, gets assigned LAN IP 192.168.1.105 again, and tries to REGISTER using new UDP port 51002. This succeeds upon rebooting or at the next registration interval with a proper reply (ex. 200 OK).

D. Why would incoming calls still fail (due to stale states) without rebooting the router? Why, despite successful registration using port 51002, do attempts to make calls (which require establishing new UDP flows for signalling/media from new ports, such as 51002 or others) still fail?

i. Despite successful registration, call path issues can arise. This is because the Assured NAT entries created during the outage (from the flows that received 404 replies) might still exist in the router's table. The numerous stale, Assured NAT entries created during the outage (such as the one involving port 51000 via external port 55123, and potentially others) are still lingering in the router's NAT table because their longer 180s timer has not yet expired. These old entries consume finite resources (memory, table slots) within the router. When the ATA tries to initiate a new call flow from port 51002, the router needs to allocate a new NAT table entry. This allocation can fail or be significantly delayed if the table is congested by the still-present stale entries associated with the same internal IP (192.168.1.105) and destination (162.213.111.21:6060). These stale entries, associated with 192.168.1.105 communicating with 162.213.111.21:6060 via specific external ports (such as 55123), could interfere with the router establishing new, clean paths for the actual call signalling or media, even though the new registration flow works.


ii. Or the router's general connection tracking for this IP/destination pair might be temporarily disrupted due to the prior repeated failures. The router's general connection tracking might be confused from handling numerous failed-but-replied attempts. The router might have broadly flagged the path from 192.168.1.105 to 162.213.111.21:6060 as problematic due to the flood of prior errors, temporarily hindering new connection setups on that path regardless of the source port. Such an internal state could temporarily affect the processing or priority of all new connection attempts on that specific path, regardless of the source port being used, until the flag or condition was cleared by an internal timer or event. This is less likely, though possible, than the previous cause mentioned.


E. Natural resolution (timeout) occurs without needing to reboot the ATA. The router's internal timer governing the problematic state (ex. the 180s Assured timeout for a specific stale entry or another relevant timer, such as a general connection tracking state timeout, might have flagged this specific communication path, IP-to-IP, as problematic and applied a separate internal cleanup timer to that state, preventing new connections until it cleared) eventually expires for enough of the old entries. The router clears the stale state/old entries. The router can now successfully create the new NAT mapping needed for the call attempt originating from the ATA's current port (ex. UDP port 51002). Resources become available in the NAT table. Subsequent attempts by the ATA (192.168.1.105) to establish call paths to 162.213.111.21:6060 succeed as a fresh NAT mapping is created. Communication for calls is restored.

So even when the ATA uses a new source port, the persistence of old, stale NAT entries (kept alive by their longer 'Assured' timeout because they received 404 replies) may still congest the router's resources or trigger other state issues, preventing new connections until those old entries finally time out. That's why rebooting the modem/router combo, waiting for it to be fully up and running first, and then rebooting the ATA afterwards is advised, especially when the conditions from point D at viewtopic.php?p=78976#p78976 can't be met.




Incoming calls should reach Fongo Home Phone's voicemail system even when the ATA is either offline or not registered. Busy signal suggests something else, such as network path issues due to (router) NAT problems, rather than the ATA simply being offline.

similar to when the Internet goes down when you are talking on the phone and you are locked out for many hours due to a "hang up signal" was never received

That happens when BYE or CANCEL isn't received or processed correctly, but Fongo Home Phone has 4 channels, so that would have to happen four times with open calls on the account, which I doubt occurred. Freephoneline only has two channels by comparison. The number of channels represents the number of calls that can be active simultaneously.

I've dealt with calls not ending before and troubleshooted one scenario over here with an unrelated Freephoneline issue/bug that was fixed awhile ago: viewtopic.php?p=79211#p79211.


There is a rate limit for the number of registration attempts (each time you reboot your ATA a registration attempt occurs) that is allowed within a short interval before becoming IP blocked. That block also eventually clears. However, failover for being unregistered is Fongo's voicemail system and not a busy signal.

Thanks for all you do Liptonbrisk.

You're welcome!

[Liptonbrisk]

As this issue is resolved, I'm locking the thread.