FPL stopped working with 401 Unauthorized on REGIST

Have a question or problem with your Fongo application? This forum is the place to get help from both staff and fellow community members.
Fongo recommends Fongo Home Phone for a fully supported Home Phone system for only $4.95/mo

FPL stopped working with 401 Unauthorized on REGIST

Postby carniver » 08/11/2022

My free phone line stopped working altogether
Tried digging into server logs, and saw that the first REGISTER goes through successfully but the same command 1 hour later always fails with HTTP 401

Is this a hardware issue?
carniver
Just Passing Thru
 
Posts: 4
Joined: 08/11/2022
SIP Device Name: Grandstream HT801
Firmware Version: 1.0.41.2
ISP Name: Telus
Computer OS: Windows 10
Router: Telus router

Re: FPL stopped working with 401 Unauthorized on REGIST

Postby Liptonbrisk » 08/11/2022

First, I deleted the tiny, snipped, syslog entries because you posted both your FPL number and full name on a public forum, which is a really bad idea unless you want telemarketing bots and scammers to add your number to their lists and call you.

You were also showing how many World Credits are left on your account.



carniver wrote:My free phone line stopped working altogether


Based on what evidence?
What happens exactly? When you pick up the phone and dial, do you hear an error message?
Do you witness loss of registration in both the ATA (navigate to status-->port status-->registration) and also at https://www.freephoneline.ca/showSipSettings?

The next time this happens, login at https://www.freephoneline.ca/showSipSettings
Please note that if "SIP User Agent" reflects a different device than the one you're using, someone else is using your Freephoneline VoIP unlock key.

When there are multiple devices/softphones/Lines (on an ATA) using the same FPL account, only the most recent registration is valid. The previously registered device (or ATA, in this case) will lose registration, and, consequently, incoming calls will not ring on it. This is especially important to consider if someone else is using your SIP credentials (username and password) that are found after logging in at https://www.freephoneline.ca/showSipSettings or if you're trying to register your FPL account with a smartphone SIP app (or FPL desktop app), with another device, or more than one ATA line. Registration is required for incoming calls. It is not required for outgoing calls. Only one registration per FPL account is allowed at any time. A single line on an ATA is one registration. A SIP app is another.

A more significant concern, though, is that multiple registration attempts can lead to temporary IP bans. The more devices being used with the exact same FPL account can make the temporary ban happen more quickly. Each time you reboot or restart your ATA or SIP app, it's attempting to register with Freephoneline again. Multiple registration attempts within a short period can result in temporary IP ban. Each time you reboot your ATA (or run a SIP app) it's attempting to register with FPL's proxy server again.

"As May 2013, our servers will rate limit REGISTER requests to a maximum of 10 requests per 5 minutes. Each authentication round usually consumes 2 requests (digest auth), so it is a fair number given our guidelines. Also, it does not affect INVITES (which are also authenticated)...

This rate limit is applied per IP address as our service is tailored to residential Canadian users (ADSL/Cable)."



If you've been temporarily IP banned, you can try switching to another proxy server: voip,freephoneline.ca, voip2.freephoneline.ca, or voip4.freephoneline.ca:6060.


voip4.freephoneline.ca:6060 is used to help circumvent buggy SIP ALGs in routers, and it's a good choice to try if you weren't using it before.



Tried digging into server logs, and saw that the first REGISTER goes through successfully but the same command 1 hour later always fails with HTTP 401



The first REGISTER attempt always generates a 401 response. That's normal. The server sends a challenge, 401 (which you didn't show for CSeq: 2163 REGISTER), and then the user's device responds with the login and hashed (MD5) password (which you did show). In other words, for CSeq: 2163 REGISTER, you showed the last two lines from this image:

Image
https://andrewjprokop.wordpress.com/201 ... istration/
That's what should happen.


In the example you provided for CSeq: 2164 REGISTER, the ATA is challenged (401) with a new nonce value, which is normal and expected. That's where the log ends. In other words, for CSeq: 2164, you showed the first two lines in the above image only. The ATA should respond again, and you should finally see a corresponding "200 OK".

If each subsequent registration after the 401 challenge response keep failing over and over and over again, that's a problem, but you haven't provided any evidence of that.



Use this guide to configure your ATA: viewtopic.php?f=15&t=20252#p79162. Change SIP REGISTER Contact Header Uses to WAN Address. You've got yours set to LAN.
"Register Expiration" needs to be 60 minutes in the ATA (not 3600 minutes). Please note that "Subscribe for MWI" should be "No" (the guide has that wrong). "SIP Registration Failure Retry Wait Time" should be 120 seconds or higher. "Use Random SIP Port" should be set to "Yes".


Is this a hardware issue?


There doesn't appear to be any evidence of anything abnormal occurring in the entries you provided, so I'm not sure what you're referring to.
Please do not send me emails; I do not work for nor represent Freephoneline or Fongo. Post questions on the forums so that others may learn from responses or assist you. Thank you. If you have an issue with your account or have a billing issue, submit a ticket here: https://support.fongo.com/hc/en-us/requests/new. Visit http://status.fongo.com/ to check FPL/Fongo service status. Freephoneline setup guides can be found at viewforum.php?f=15.
User avatar
Liptonbrisk
Technical Support
 
Posts: 2764
Joined: 04/26/2010
SIP Device Name: Obihai 202/2182, Groundwire
Firmware Version: various
ISP Name: FTTH
Computer OS: Windows 64 bit
Router: Asuswrt-Merlin & others

Re: FPL stopped working with 401 Unauthorized on REGIST

Postby carniver » 08/12/2022

Thank you LiptonBrisk. So it's good to know that 401 isn't the cause of the issue, but anyway, my phone works for couple days and then it would not receive any incoming calls, and making outgoing calls will result in silence for a minute and then a fault tone. Sometimes rebooting the IP Phone device or the internet router would fix it, sometimes it doesn't. This account is only used by one device, I don't think I've been IP banned, but does Fongo send out warning emails on IP bans?
carniver
Just Passing Thru
 
Posts: 4
Joined: 08/11/2022
SIP Device Name: Grandstream HT801
Firmware Version: 1.0.41.2
ISP Name: Telus
Computer OS: Windows 10
Router: Telus router

Re: FPL stopped working with 401 Unauthorized on REGIST

Postby Liptonbrisk » 08/12/2022

carniver wrote:Thank you LiptonBrisk. So it's good to know that 401 isn't the cause of the issue, but anyway, my phone works for couple days and then it would not receive any incoming calls, and making outgoing calls will result in silence for a minute and then a fault tone.


If you see that you're registered in both the ATA (log in to ATA and navigate to status-->port status-->registration) and also at https://www.freephoneline.ca/showSipSettings, then it's unlikely the problem is related to registration. It would be worth checking both locations when the problem happens again.

Make sure you change "SIP REGISTER Contact Header Uses" to "WAN Address" in your Grandstream ATA so that you're more likely to ensure the RTP audio stream is directed to your public WAN IP address instead of nowhere (LAN IP).

Lastly, this situation seems more likely to be related to power outages (when power returns, the ATA boots up first, which is bad if UDP timeouts are not set correctly in the router being used) or intermittent internet service (or WAN IP address changing) that can, in turn, lead to stale connections/NAT associations developing between your router or hub and ATA. Refer to Point D from viewtopic.php?f=8&t=20199#p78976. If you can't change UDP timeouts to satisfy the conditions listed in point D, then remember that proper device reboot order is always Modem--->Router--->ATA. Make sure that the first device in the list is fully up and running before the next device is. That is, the ATA should always be rebooted last in the device chain, after the modem and the router (or hub) are up and running first. Unfortunately, using the correct device reboot order is just a temporary solution until the problem occurs again. When dealing with problems arising from stale connections, the solution is to put your Telus Hub in bridge mode and get a router with firmware that allows you to adjust UDP timeouts. You can increase your ATA's SIP Registration Failure Retry Wait Time beyond 120 seconds without any problem, but unless you have a router that allows you to adjust UDP timeouts, it can be a guessing game trying to determine what your router's (or hub's) UDP Assured Timeout is. UDP Assured Timeout needs to be less than SIP Registration Failure Retry Wait Time. Some consumers routers use 180 seconds as the default value for for UDP Assured Timeout, so you could try 200 seconds for SIP Registration Failure Retry Wait Time, with the understanding that after a failed registration attempt, your ATA will try to register again in 200 seconds instead of 120 seconds.

I know this scenario works for resolving UDP timeout problems:

For Telus Wi-Fi Hubs, put LAN port 1 on the Hub in bridge mode. Then connect your router to LAN port 1.
Alternatively, contact Telus and ask them how to enable bridge mode.
Attach Asus RT-AX86U, for example, using Asuswrt-Merlin firmware to LAN port 1 on the Telus Hub. Change UDP timeouts in Asuswrt-Merlin as described in point D. Attach ATA to RT-AX86U.



I don't think I've been IP banned


Given your description of the problem and that the registration process seems to be working normally, I doubt you were. Registration timers are important to avoid them (60 minutes for "Register Expiration" and 120 or greater seconds for "SIP Registration Failure Retry Wait Time"). So is not using your FPL credentials on multiple devices.


Again, use this guide to configure your ATA: viewtopic.php?f=15&t=20252#p79162. Change SIP REGISTER Contact Header Uses to WAN Address. You've got yours set to LAN.
"Register Expiration" needs to be 60 minutes in the ATA (not 3600 minutes). Please note that "Subscribe for MWI" should be "No" (the guide has that wrong). "SIP Registration Failure Retry Wait Time" should be 120 seconds or higher. "Use Random SIP Port" and "Use Random RTP Port" should be set to "Yes".



but does Fongo send out warning emails on IP bans?


No.



It might worth checking to see whether you can reach the servers when you experience this problem (based on your syslog you are reaching voip.freephoneline.ca though).
However, I think the problem you're describing is due to point D from viewtopic.php?f=8&t=20199#p78976 and not a temporary ban.

Regardless, if you''re interested you can try this WINMTR test.:

The instructions below are for testing to FPL's proxy servers, but I would also test to 208.85.218.146 and 208.85.218.147, which are the RTP IPs at the moment for FPL.
That's where the RTP audio packets come from.


"Test pings and jitter (you want little to no variation between pings) to the specific Freephoneline SIP servers you plan on using.

Use winmtr: https://sourceforge.net/projects/winmtr/. Ping about 200 times to each server.

My pings to
-voip.freephoneline.ca average 11 ms.
-voip2.freephoneline.ca average 12 ms
-voip4.freephoneline.ca average 27 ms

If you're using a Macintosh, maybe this helps: https://www.reddit.com/r/TagPro/comment ... tr_on_mac/

When using WinMTR, look at the very last hop or line. Look at your average ping and then maximum ping. Although WINMTR doesn't provide a jitter value, you can get an idea of what yours is by subtracting maximum ping from your average. Jitter is the difference between each successive ping. The bigger the difference, the bigger the problem.

Same with ping, which represents lag or delay. The lower your ping and jitter, the better.

You do not want high pings and lots of jitter (you do not want a lot of variation between each ping). If you get horrible results (pings over 200ms), to any server, you probably don’t want to use that server. So you would want to give that server the lowest priority.

I get between 11 (voip.freephoneline.ca and voip2.freephoneline.ca) and 24ms (voip4.freephonline.ca) on average, depending on the server I'm testing to. Preferably, you want pings below 100ms.
Anything over 200ms is unacceptable.
What you don't want to see is 40, 45, 50, 35, 500, 40, 30, 45, 700. That's bad jitter.
You want relatively consistent pings without a lot of variation.

One reason why jitter can occur is due to other devices on your LAN (local area network) using bandwidth. That’s why properly enabling QoS in your router for your ATA is always a good idea. Refer to point C from viewtopic.php?f=8&t=20199#p78976.

Bad jitter can produce broken-up audio or choppiness during phone calls. Severe jitter (or large ping spikes) can cause calls to drop. Ping affects delay.

I recommend testing pings/jitter between 8 p.m. and 11 p.m. to see if local congestion is a factor (this often is your ISP's fault). Sundays are the best days to test (because that's when most people in your area will be home). 8 p.m. - 11 p.m. is prime time. During prime time (between 8 p.m. and 11 p.m.) cable internet nodes may be oversubscribed in your area and face congestion issues (and congestion can also exist with DSL). So I suggest testing services between 8 p.m. and 11 p.m., particularly on Sundays, when everyone in your area will be home.

Ping is a measurement of data packet transmission, and ping does affect delay or lag. All gamers know, almost inherently, that lag affects them negatively. A PC gamer will pound his or her keyboard in hope that a character will respond on his or her monitor, quickly, but when there's a delay or lag, reality doesn't meet expectation. A gamer can see this problem visually. Over VoIP, anything over 200-210 ms, you will typically start to encounter crosstalk due to increased delay, even if the untrained ear doesn't notice. All VoIP services are subject to the same scientific principles including the fact that speed of transmission affects delay, and Freephoneline is not some magical service that is somehow exempt from issues arising from high pings and jitter. When pings and, especially, jitter are high, it's a pretty horrible experience, just as it would be with any other VoIP service. When pings and jitter are fine, Freephoneline is great.

Lastly, anyone using any communication service (or even when playing online games or using other online services) should understand that the longer the path to the server being used, the greater the potential exists for a problem to occur somewhere along that path. Freephoneline’s SIP servers are located in Ontario."

-- from download/file.php?id=2164 (pages 16 and 17)
Please do not send me emails; I do not work for nor represent Freephoneline or Fongo. Post questions on the forums so that others may learn from responses or assist you. Thank you. If you have an issue with your account or have a billing issue, submit a ticket here: https://support.fongo.com/hc/en-us/requests/new. Visit http://status.fongo.com/ to check FPL/Fongo service status. Freephoneline setup guides can be found at viewforum.php?f=15.
User avatar
Liptonbrisk
Technical Support
 
Posts: 2764
Joined: 04/26/2010
SIP Device Name: Obihai 202/2182, Groundwire
Firmware Version: various
ISP Name: FTTH
Computer OS: Windows 64 bit
Router: Asuswrt-Merlin & others


Return to Community Support

Who is online

Users browsing this forum: Google [Bot] and 28 guests