[Resolved] No Incoming calls on voip.freephoneline.ca

[Liptonbrisk]

http://forum.fongo.com/viewtopic.php?f=8&t=19918#p77984

Primary server was voip.freephoneline.ca. Changed it to voip4.freephoneline.ca:6060 and it did the trick.

[aLti]

This is definitely an issue at FPL's end. Although I was able to connect just fine to the primary server (voip.freephoneline.ca) yesterday, the message seen on my hardphone when trying to make a call was "Internal Server Error 500". All incoming calls went straight to voicemail. The call logs on FPL's website show "Unallocated (unassigned) number" when trying to call my own Freephoneline number. Switching to the secondary server (voip2.freephoneline.ca) resolved the issue for now. I don't think this was a server overload, it more looks like someone (perhaps one of the vendors or a hacker) has tried to improperly modify the configuration at FPL's end. I raised a ticket yesterday to inform FPL about the issue, but it was automatically discarded ("Please note that we do not provide free support for Freephoneline, but there is an active community that provides..."). I really didn't even ask for any support, all I wanted was to bring this issue to their attention. I don't remember encountering this issue until yesterday.

[Liptonbrisk]

The call logs on FPL's website show "Unallocated (unassigned) number" when trying to call my own Freephoneline number.

Why are you the only one telling me this? This is an honest question. I'm not being sarcastic or snide. I'm honestly wondering.

It shows "Temporary Failure" when I look at the call logs.

Normal call clearing is disconnect reason from the log. Let me get in and check config.

Also, keep in mind that last night, while others were claiming to have a problem on voip.freephoneline.ca, I wasn't.

I've now returned back to voip.freephoneline.ca just to test right now, and I'm still not having problems.

I really don't understand why my accounts aren't affected.

don't think this was a server overload, it more looks like someone (perhaps one of the vendors or a hacker) has tried to improperly modify the configuration at FPL's end.

Why wouldn't everyone on voip.freephoneline.ca be affected then? It wouldn't even be a temporary or intermittent issue. The situation should be game over for everyone using that server, no?
Or would only certain accounts be affected somehow? Doesn't make sense to me.

I raised a ticket yesterday to inform FPL about the issue, but it was automatically discarded ("Please note that we do not provide free support for Freephoneline, but there is an active community that provides..."). I really didn't even ask for any support, all I wanted was to bring this issue to their attention. I don't remember encountering this issue until yesterday.

Well, at least you tried to tell them about it. I wish more people would do that if they honestly feel the problem is with FPL. I can't do anything if my accounts work fine.

I will say I find it odd that people are getting ISUP error messages instead of SIP error messages.
For example, 41 Temporary error should normally be 503 Service Unavailable.

And 503 Service Unavailable means
The server is undergoing maintenance or is temporarily overloaded and so cannot process the request.

And that is why I suspect an overloaded server. Also, koreyb mentioned the service wasn't working, and then it was (very late at night), and then it wasn't again. That's an intermittent issue, and is consistent with the problem disappearing when server load decreases. For example, http://forum.fongo.com/viewtopic.php?f= ... =25#p77343

Anyway, voip.freephoneline.ca is working fine for me right now.

[aLti]

This is what my call logs from September 03 look like:



**501 is my FPL number, **431 is my landline (Bell).

Why wouldn't everyone on voip.freephoneline.ca be affected then?

If this was a server overload, then yes, everyone on that server would have been affected. Since only some customers were affected, I'd say it was more likely a configuration fault on the provider's end (most likely a routing issue of some sort).

[Liptonbrisk]

This is what my call logs from September 03 look like

I think you're misinterpreting my intent. You didn't have to take a screen cap and post. I believe that you received that Unallocated number error. I'm not asking for proof, and I certainly didn't think you were lying.
What I'm saying (and I'm someone who reads practically every single post on the FPL forum) is that no one else reported that same error to me (yet).
Consequently, why would the issue you're encountering necessarily be exactly the same as what others have reported in this thread?

Why wouldn't everyone on voip.freephoneline.ca be affected then?

If this was a server overload, then yes, everyone on that server would have been affected.

Back on April 7th, Fongo Support admitted an overload issue with voip.freephoneline.ca:
http://forum.fongo.com/viewtopic.php?f= ... =25#p77370
"Hello,

We apologize for the system issue you are having; we are experiencing higher than normal call volumes, and it has caused issues on our server. We have resolved the issue, and it should be working as usual now.
Note: You may need to reboot your ATA device."



I did experience a problem, but look:

http://forum.fongo.com/viewtopic.php?f=8&t=19934#p77324
On April 6th, at 4:00 p.m., I'm not having problems.


I don't have problems again until approximately 8 p.m.: http://forum.fongo.com/viewtopic.php?f= ... =25#p77341
In the interim, hanke is having problems (between 4 and 8), while I'm not: http://forum.fongo.com/viewtopic.php?f=8&t=19934#p77325.

So that's an acknowledged overload issue by Fongo support back in April. The problem isn't experienced by all users simultaneously, despite that period being problematic.
That's what happens with server congestion. If you've ever played an MMO or online game, you may have noticed the game server can only handle a certain number of players.
If the number of players increases beyond a certain threshold, the server becomes unstable, and players can start dropping until the server comes stable again. When an incoming call
drops with FPL, the call goes to voicemail.

Since only some customers were affected

Okay, but you're suggesting earlier that something involving voip.freephoneline.ca was suddenly hacked or misconfigured. In that case, I fail to see how anyone could use it.
And, as I stated, on the night of September 3rd, when I logged in on these forums, I switched to voip.freephoneline.ca and did not experience problems while others were.
Please keep in mind that I'm not saying you're wrong, but I haven't had problems with voip.freephoneline.ca during my tests yet. And voip.freephoneline.ca is working for me at the moment.

[aLti]

What I'm saying (and I'm someone who reads practically every single post on the FPL forum) is that no one else reported that same error to me.

Why would anyone report anything to you, since you "do not work for nor represent Freephoneline or Fongo", as written in your signature and visible in every single post you make?

Why would the issue you're encountering be exactly the same as what others have reported in this thread?

You mean, why would my issue of not being able to receive any phone calls on Sep 03 due to automatically being routed to voicemail, be the same as numerous other users not being able to receive phone calls on Sep 03 due to automatically being routed to voicemail? I think it's self explanatory, really.

In addition, I don't care much what Fongo Support says regarding this particular issue, since I've worked as an Escalation Engineer for a much, much bigger company solving much, much more complex problems than this. I also used to maintain my own Asterisk servers many years ago.

Okay, but you're suggesting earlier that something involving voip.freephoneline.ca was suddenly hacked or misconfigured. In that case, I fail to see how anyone could use it.

If you (accidentally) block or delete my forum account, does that mean that no one else can use his account on this forum? SIP is a highly standardized protocol. It has an overload control mechanism. If the system is configured properly, it should invoke 503 at which point the clients attempt to use the alternate server automatically.

[Liptonbrisk]

Why would anyone report anything to you, since you "do not work for nor represent Freephoneline or Fongo", as written in your signature and visible in every single post you make?

With respect to user to user support with FPL, I probably have the greatest number of responses, in particular, over the past few years and history online with users (not just here), and I've configured this service for a lot of people.
Regardless, no one else reported the exact same error during this September 3rd period on these forums (or elsewhere) yet.

And, really, given people often have tickets closed, who do you think they're directing questions to, if not here, to other moderators, or to me?

You mean, why would my issue of not being able to receive any phone calls on Sep 03 due to automatically being routed to voicemail, be the same as numerous other users not being able to receive phone calls on Sep 03 due to automatically being routed to voicemail? I think it's self explanatory, really.

Voicemail failover with FPL can occur due to more than one cause. Otherwise, I wouldn't be engaging in this conversation with you.

For example, I typically associate "destination out of order issues" (such as what I see in your call log) with SIP ALG or a configuration issue on the user's end: http://www.obitalk.com/forum/index.php? ... 1#msg27051 and http://forum.fongo.com/viewtopic.php?f= ... 944#p71928 (the Rogers proxy mentioned is voip4.freephoneline.ca:6060, which is for SIP ALG issues, but you must be aware of that).

In addition, I don't care much what Fongo Support says regarding this particular issue

They haven't said anything about this issue in September; they described the issue that occurred back in April.
I'm the one suggesting the two incidents may be related.

since I've worked as an Escalation Engineer

I never suggested you were anything other than an expert. Your qualifications don't change the questions I'm asking. I'm not asking out of malice, nor do I have any agenda either other than sincere curiosity at the moment.

In the event we've corresponded before, hello again.

If you (accidentally) block or delete my forum account, does that mean that no one else can use his account on this forum?

Fair enough.

Let me get this straight. Koreyb is having problems on Sept 3rd: http://forum.fongo.com/viewtopic.php?f= ... =50#p77929.
Using your analogy, koreyb's account is blocked at some point on Sept 3rd. Then it's unblocked a little after midnight on Sept. 4th, when server load would be start to be reduced typically after prime time: http://forum.fongo.com/viewtopic.php?f= ... =75#p77959. And then it's blocked again at 11:30 a.m on Sept 4th, when server load might, coincidentally, begin to increase: http://forum.fongo.com/viewtopic.php?f= ... =75#p77965. Or something on FPL's end was hacked/misconfigured, fixed, and then hacked/misconfigured again? Is that what you're telling me?

What could be happening is maintenance, but that's the same sip error code as 503, which is temporary overloading anyway.

I'm convinced the issue is with FPL. However, I find the intermittency weird if something has been hacked or misconfigured.

By the way, would you go as far as willing to speculate the cause isn't accidental if resources are a low priority for FPL users in comparison to, say, Fongo Home Phone users who pay a monthly fee?

SIP is a highly standardized protocol. It has an overload control mechanism

Thank you for taking time out of your busy schedule to explain SIP to me.

If the system is configured properly, it should invoke 503 at which point the clients attempt to use the alternate server automatically.

With FPL, the call would drop to voicemail on 503.

http://forum.fongo.com/viewtopic.php?f= ... =25#p77921

It shows "Temporary Failure" when I look at the call logs.

ISUP Cause Value 41 temporary failure corresponds with SIP Response 503 Service unavailable


https://www.ietf.org/rfc/rfc3261.txt
503 Service Unavailable

The server is temporarily unable to process the request due to a
temporary overloading or maintenance of the server. The server MAY
indicate when the client should retry the request in a Retry-After
header field. If no Retry-After is given, the client MUST act as if
it had received a 500 (Server Internal Error) response.

A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
attempt to forward the request to an alternate server. It SHOULD NOT
forward any other requests to that server for the duration specified
in the Retry-After header field, if present.

yesterday, the message seen on my hardphone when trying to make a call was "Internal Server Error 500"

Anyway, you're clearly agitated with my responses. Good evening.

[xegano]

I have administered four separate devices connected to FPL for many years with no recent configuration changes, so I represent a total of four customers:

SIP User Agent: OBIHAI/OBi302-3.0.1.4330 Teksavvy DSL TP-Link
SIP User Agent: Asterisk PBX 11.13.1~dfsg-2+deb8u5 Teksavvy DSL TP-Link
SIP User Agent: Linksys/SPA3102-5.1.7(GW) Eastlink cable Hitron
SIP User Agent: Cisco/SPA232D-1.3.6(005_281) CarryTel cable D-Link

All four have encountered the same inbound call issues as others have described on September 3rd and 4th.

Call logs show instances of "Unallocated (unassigned) number" and "Temporary failure".

Switching between voip.freephoneline.ca and voip2.freephoneline.ca sometimes resolves the problem for a short time, but the problem eventually persist. As of 4PM EST on September 4, inbound calls appear to be working again on both gateways.

Packet analysis from tcpdump at the WAN interface of the router show expected exchanges for registration and outbound calls. No packets appear from freephoneline.ca for inbound calls when the error condition occurs.

Based on my experience and that of others in this thread, I think that there is compelling evidence that this problem is caused by FPL's service as opposed to customer’s configuration, devices or network provider.

I don't have any solutions. I'm just posting to convince those who have the same symptoms, not to waste their time reconfiguring, rebooting routers, ATAs or whatever, like I did.

[Liptonbrisk]

Call logs show instances of "Unallocated (unassigned) number"

Okay, so you're the second now. Thanks for reporting.

No packets appear from freephoneline.ca for inbound calls when the error condition occurs.

Yes, that stands to reason.

As of 4PM EST on September 4, inbound calls appear to be working again on both gateways.

Are they still working for you?

Based on my experience and that of others in this thread, I think that there is compelling evidence that this problem is caused by FPL's service as opposed to customer’s configuration, devices or network provider.

I prefer ruling out configuration issues first before submitting tickets, especially since anything deemed an error on the user's end will result in the ticket being closed. But sure.

In your case, there's nothing I can do, except to suggest submitting a ticket: https://support.fongo.com/hc/en-us/requests/new. Maybe if there's enough tickets, something will happen. Really, if the problem isn't on the user's end, they should do something. If the ticket ends up being closed without a response, you can consider filing a complaint with CCTS: https://www.ccts-cprst.ca/.

voip.freephoneline.ca is still working, for whatever reason, for approximately 7 hours for me.
On Sept 3rd from 8:15p.m. to 12:34 a,m, on Sept. 4, voip.freephoneline.ca worked. I gave up trying to get it to not work and switched away to voip4.freephoneline.ca:6060, which has continued to work perfectly fine, until I switched over 7 hours ago to voip.freephoneline,ca, which, in turn, continues to work fine.

[Liptonbrisk]

Support staff isn’t obliged to read the forums or respond here. It’s best to submit a ticket if you're positive the issue isn't on your end: https://support.fongo.com/hc/en-us/requests/new.

For ongoing, unresolved issues that can’t be fixed with tickets, customers can submit complaints to CCTS:
https://www.ccts-cprst.ca/. I would give Fongo a week to respond to support request tickets first, at least, unless they've been closed
There's a delay in ticket responses due to COVID-19.

Other places to look for info include https://status.fongo.com/ (I don't see anything interesting yet) and https://twitter.com/Fongo_Mobile/with_replies (again, I don't see anything related).

Fongo's service phone number is 647-847-1355. I'm skeptical that anyone is answering calls though, and they don't work on weekends.

[Liptonbrisk]

voip.freephoneline.ca continues to work fine for me after 14 hours.

[Liptonbrisk]

Support staff isn’t obliged to read the forums or respond here. It’s best to submit a ticket if you're positive the issue isn't on your end: https://support.fongo.com/hc/en-us/requests/new.


For ongoing, unresolved issues that can’t be fixed with tickets, customers can submit complaints to CCTS:
https://www.ccts-cprst.ca/. I would give Fongo a week to respond to support request tickets first, at least, unless they've been closed
There's a delay in ticket responses due to COVID-19.

Other places to look for info include https://status.fongo.com/ (I don't see anything interesting yet) and https://twitter.com/Fongo_Mobile/with_replies (again, I don't see anything related).

Fongo's service phone number is 647-847-1355. I'm skeptical that anyone is answering calls though, and they don't work on weekends.

I suppose, since I'm a mod, I have a responsibility to try to do something for other users here, even though I'm not encountering the issue myself and suspect my ticket will be closed.
Anyway, I'll try submitting a ticket.

Edit: submitted

[aLti]

In the event we've corresponded before, hello again.

Not really sure what you mean by this, but it appears as if you've managed to agitate a lot of Fongo users in the past
I'm a new user here, and I don't think we've corresponded in the past.

Anyway, you're clearly agitated with my responses.

No, you simply posted direct questions and I gave you direct answers.

I will say I find it odd that people are getting ISUP error messages instead of SIP error messages.
ISUP Cause Value 41 temporary failure corresponds with SIP Response 503 Service unavailable.

I've searched not just this topic, but the entire forum, and the only user ever mentioning ISUP messages and server overload is you.
No user on this topic has complained about receiving ISUP 41 or any other ISUP message.

With FPL, the call would drop to voicemail on 503.

No, not if server overload behaviour has been setup correctly. The answer to this also lies in the quote from the relevant source which you have previously provided.
A server under load is not expected to receive any additional load (i.e. voicemails) since it cannot cope with the current amount of load it has.

For example, I typically associate "destination out of order issues" (such as what I see in your call log) with SIP ALG or a configuration issue on the user's end...

What you are seeing in my logs regarding the aforementioned error is me trying to call my cell phone number from my FPL number.
Around the same time, I also tried calling my landline from my FPL number and a completely different message was logged.
I'm not sure how you correlate this with "a configuration issue on the user's end", especially given the fact that my equipment has been working just fine since March 2020 without any configuration changes, up until Sep 03 when a lot of users started having the very same issue?

By the way, would you go as far as willing to speculate the cause isn't accidental if resources are a low priority for FPL users in comparison to, say, Fongo Home Phone users who pay a monthly fee?

FPL customers are also paying users. Each FPL account ($99.95) equals 20 months of a single FHP account ($4.95), maybe even more if we take into consideration that no free support exists for FPL. Now, do you have some first-hand information that's not publicly available and would like to share it with us?

And finally, speaking of a server overload, let me ask you a question, Liptonbrisk. During an overload, i.e. when the server is receiving more packets than it can process and its queues are already full, packets will be dropped for sure. But in that case, SIP users wouldn't even be able to register with the problematic server, now would they? And how many users here reported registration issues? None. And what does that tell you?

I think management may be the biggest problem here. Every company should learn from its own mistakes and past incidents, and should have an open channel to receive information about potential vulnerabilities, vendor and service issues, etc. FPL apparently had this issue several times in the past, and what did they learn? Nothing. The issue exists even today, and will continue to exist until the management starts acting appropriately. Advising users to randomly start changing their phone/modem settings doesn't help at all, in fact, it's quite counterproductive. Especially in situations where user configurations were working OK for a relatively long period of time and nothing was changed at the users' end.

[Liptonbrisk]

but it appears as if you've managed to agitate a lot of Fongo users in the past

Well, I'll keep that in mind the next time you have a problem.

I'm a new user here, and I don't think we've corresponded in the past.

Okay

I've searched not just this topic, but the entire forum, and the only user ever mentioning ISUP messages and server overload is you.
No user on this topic has complained about receiving ISUP 41 or any other ISUP message.

They complained about temporary failure.

Do you not associate temporary failure with being an ISUP message?

https://community.cisco.com/t5/voice-ov ... d-p/407136

http://www.dialogic.com/webhelp/img1010 ... ss7_cc.htm (granted, different service)

ISUP Cause Value SIP Response
41 – temporary failure 503 Service unavailable

No, not if server overload behaviour has been setup correctly.

Yeah. Unh, the last time someone pointed out things weren't configured normally, support seemed annoyed. I have no further comment.

I'm not sure how you correlate this with "a configuration issue on the user's end"

Not you, specifically. Look at the threads I linked and how that error was resolved.

FPL customers are also paying users. Each FPL account ($99.95) equals 20 months of a single FHP account ($4.95), maybe even more if we take into consideration that no free support exists for FPL. Now, do you have some first-hand information

I really don't. Keep in mind that I'm having to submit tickets just like everyone else when I have a request.

I'm going to have to search, but I remember a comment being made by a Fongo employee years ago (not recent) mentioning which users would be given priority first.

But in that case, SIP users wouldn't even be able to register with the problematic server, now would they?

The registration interval with FPL is huge: 1 hour. None of the other SIP services I use (which I won't name) do not enforce such a huge interval. So FPL's portal SIP status can take awhile to change in my experience.
And in the interim, SIP signalling can try to work. Whether the server is capable of responding is another matter.

Advising users to randomly start changing their phone/modem settings doesn't help at all, in fact, it's quite counterproductive. Especially in situations where user configurations were working OK for a relatively long period of time and nothing was changed at the users' end.

We'll have to agree to disagree on this point. So many users swear up and down that everything has been working fine for years, but incoming calls aren't working (or they can't register). Then they change local sip port and can magically reconnect. Or they reboot their devices with the ATA being last. Or they've been temp IP banned because SIP failure retry is not set to 120s and don't realize it. I appreciate the problems fixed by doing that are not associated with the problem described in this thread. I really do.

However, based on what I've seen before, users are told to factory reset their ATAs or IP Phones and reconfigure them from scratch. I suggest ensuring settings are correct first as a preemptive measure (using settings I've posted in this thread), with the expectation you'll be told to factory reset something--and then submit a ticket.



-----
Thanks to Mango, many of us now understand that in order for ATAs to remain registered and working properly with a VoIP SIP provider like Freephoneline, in particular after power failures, the following conditions must be met:

UDP Unreplied Timeout (in your router) < NAT Keep-alive Interval (in your ATA; for Obihai ATAs this is X_KeepAliveExpires) < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (or RegisterRetryInterval in Obihai ATAs)

“<“ means less than.

When a modem leases a new IP address, a problem can arise where prior associations using the old IP address are maintained in the router. When the ATA attempts to communicate using the old IP address, the response is unreplied, and then if the UDP Unreplied timeout is greater than the Keep Alive Interval (and UDP Unreplied timeout is often set to 30 by default in consumer routers) a problem arises where the corrupted connection persists. If UDP Unreplied timeout is, for example, 17, and the NAT Keep Alive Interval is 20, then the corrupted connection will timeout or close. A new connection will be created, and everything will work fine.

Another problem can occur when the Keep-Alive interval is greater than UDP Assured Timeout (often 180 by default in consumer routers): the NAT hole will close due to the ATA not communicating frequently enough with the SIP server. In turn, incoming calls may, intermittently, not reach the ATA. Again, X_Keepalives expires is supposed to be 20 with FPL.

(the above settings are making reference to those in Obihai ATAs)

Getting access to both UDP Unreplied Timeout and UDP Assured Timeout settings in consumer routers may be difficult, if not impossible. Asuswrt-Merlin (I would avoid any model below/less powerful than an RT-AC68U), third party firmware for Asus routers, does offer easy access to these two settings, which are found under General–>Tools-->Other settings. My understanding is that third party Tomato firmware has these two settings as well. So if your router supports Tomato firmware, that may be another option. Note that I will not be held accountable any damage resulting from failed firmware updates. Apparently, Mikrotik routers also allow users to change both Assured and Unreplied UDP timeout settings as well: https://forums.redflagdeals.com/recomme ... #p28056619.

The keep alive interval for FPL is 20. The SIP Registration Failure Retry Wait Time is 120. I use 17 for UDP Unreplied Timeout and 117 for UDP Assured Timeout.

Router firmware that allows users to adjust Assured and Unreplied UDP timeouts include

Asuswrt-Merlin
Ubiquiti
Mikrotik
pfSense
Tomato
DD-WRT

[ag19]

Hello Everyone,

I have been having the same issues for the past few days as well. It started with outgoing calls working/inbound calls not working and then changed to both not working.

This is what i did to solve the issue, not sure for how long it will stay up but we will see. I currently use the CISCO SPA 112 adapter for my service.

Here are the steps i followed (not saying these are the exact steps to follow but this is what made it work):

1) take an sharp object and reset your adapter. This will reset your adapter to factory settings and erase all the configuration that you have done initailly
2) find your IP address by dialing * * * * (4 stars) and than one by one, dial 1-1-0-# to get your IP address.
3) enter your IP address in the address bar of your browser and login to your adapter ( keep in mind that you must be connected on the same router as your PC/laptop you are using and where the adapter is connected to)
4) follow the step by step instructions on the attached configuration file ( you will need to log in to your freephoneline account to get some of the details from there)
5) once everything is saved and your adapter resets, your line should work for both inbound and outbound calls.

Like I mentioned above, this is what i followed for my CISCO SPA 112 adapter. Hopefully its the same for other adapters as well.

Hope this was helpful and resolves your issue.

[Liptonbrisk]

Support staff isn’t obliged to read the forums or respond here. It’s best to submit a ticket if you're positive the issue isn't on your end: https://support.fongo.com/hc/en-us/requests/new.

For ongoing, unresolved issues that can’t be fixed with tickets, customers can submit complaints to CCTS:
https://www.ccts-cprst.ca/. I would give Fongo a week to respond to support request tickets first, at least, unless they've been closed
There's a delay in ticket responses due to COVID-19.

Other places to look for info include https://status.fongo.com/ (I don't see anything interesting yet) and https://twitter.com/Fongo_Mobile/with_replies (again, I don't see anything related).

Fongo's service phone number is 647-847-1355. I'm skeptical that anyone is answering calls though, and they don't work on weekends.

[aLti]

They complained about temporary failure. Do you not associate temporary failure as being an ISUP message?

"Temporary failure" is written in FPL's logs, but at no time did the users receive it on their end devices.
This is also a clear indication that the issue was (is) somewhere on the FPL's end, since ISUP messages come from traditional phone lines (SS7).

The registration interval with FPL is huge: 1 hour.

Yes it is, but what about (voluntary) re-registration? I re-registered 15-20 times while the issue was happening. How do you explain that?

Yeah. Unh, the last time someone pointed out things weren't configured normally, support seemed annoyed.

OK, so their engineers are the best in the world, and their configurations are bullet-proof. Is that what we are supposed to believe in?

[Liptonbrisk]

"Temporary failure" is written in FPL's logs, but at no time did the users receive it on their end devices.

Other than you, I don't think many people told me about any error on their devices.

"If no Retry-After is given, the client MUST act as if
it had received a 500 (Server Internal Error) response."

You received that error, and it's associated with SIP error 503. The 500 error doesn't give me a lot to go on.
SIP error 503 is a little more useful.

Would maintenance be a more probable cause that fits (also 503)? And would "misconfiguration" then be the cause that's not affecting all accounts?

This is also a clear indication that the issue was (is) somewhere on the FPL's end

I've been pretty convinced of that since 11:30 p.m. on September 3rd. What I'm uncertain of is the cause.

Yes it is, but what about (voluntary) re-registration? I re-registered 15-20 times while the issue was happening. How do you explain that?

If load is dropping during that period, and then increasing afterwards, it's possible. It's also possible that something other than the proxy server is overloaded.
I'm still uncertain how a misconfiguration causes an intermittent issue.


What struck me first by your comment is that you weren't temporarily IP banned. Were you registering repeatedly over a 5 minute period?


https://community.freepbx.org/t/trunk-s ... ca/22479/8
"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)."


Is that not true anymore? That's not something I want to test.

OK, so their engineers are the best in the world, and their configurations are bullet-proof. Is that what we are supposed to believe in?

The value I've had from FPL has been pretty good. I've had it for over 10 years, and I paid $50. Support staff has generally been nice to me (although I no longer have a way to communicate as I did when I was first appointed a mod). I don't feel like rocking the boat too much, as long as my service works.

[Liptonbrisk]

Support staff isn’t obliged to read the forums or respond here. It’s best to submit a ticket if you're positive the issue isn't on your end: https://support.fongo.com/hc/en-us/requests/new.


For ongoing, unresolved issues that can’t be fixed with tickets, customers can submit complaints to CCTS:
https://www.ccts-cprst.ca/. I would give Fongo a week to respond to support request tickets first, at least, unless they've been closed
There's a delay in ticket responses due to COVID-19.

Other places to look for info include https://status.fongo.com/ (I don't see anything interesting yet) and https://twitter.com/Fongo_Mobile/with_replies (again, I don't see anything related).

Fongo's service phone number is 647-847-1355. I'm skeptical that anyone is answering calls though, and they don't work on weekends.

[Liptonbrisk]

Hope this was helpful and resolves your issue.

Thanks for trying to help.
I hope your service continues working.

[Liptonbrisk]

Well, after 19 hours of being on voip.freephoneline.ca, I give up. Incoming calls continue to work. I'm switching proxy. I hope everyone has a good weekend.

----
Support staff isn’t obliged to read the forums or respond here. It’s best to submit a ticket if you're positive the issue isn't on your end: https://support.fongo.com/hc/en-us/requests/new.


For ongoing, unresolved issues that can’t be fixed with tickets, customers can submit complaints to CCTS:
https://www.ccts-cprst.ca/. I would give Fongo a week to respond to support request tickets first, at least, unless they've been closed
There's a delay in ticket responses due to COVID-19.

Other places to look for info include https://status.fongo.com/ (I don't see anything interesting yet) and https://twitter.com/Fongo_Mobile/with_replies (again, I don't see anything related).

Fongo's service phone number is 647-847-1355. I'm skeptical that anyone is answering calls though, and they don't work on weekends.

[aLti]

What struck me first by your comment is that you weren't temporarily IP banned.
Were you registering repeatedly over a 5 minute period?

I rebooted my DSL modem a few times during the issue, and each time I was given a new IP address.
Perhaps that's the reason why.

If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
You received that error, and it's associated with SIP error 503.

No, I think that you haven't read the entire RFC in question, as well as its associated documents. You also need to understand how the packet flow goes and what SIP headers contain.
Upon receiving a 503, the client will act as if a 500 was received, but that doesn't imply that the client will change the received SIP error and its associated header on-the-fly from 503 to 500.
In fact, great many clients aren't even capable of changing the received error from one code into another on-the-fly.
So what you see on your phone display is what was actually received by the client, i.e. sent by the SIP server.
Now, intermediate SIP servers (and proxies) do have the capability of changing all headers on-the-fly, but in most cases these do not reside at customer's end.
To confirm, I've never received a 503, but for some reason you keep ignoring this fact. And I think I still may have the packet captures, unless I've deleted them already.

[Liptonbrisk]

I rebooted my DSL modem a few times during the issue, and each time I was given a new IP address.
Perhaps that's the reason why.

Right, okay.

No, I think that you haven't read the entire RFC in question, as well as its associated documents. You also need to understand how the packet flow goes and what SIP headers contain.
Upon receiving a 503, the client will act as if a 500 was received, but that doesn't imply that the client will change the received SIP error and its associated header on-the-fly from 503 to 500.
In fact, great many clients aren't even capable of changing the received error from one code into another on-the-fly.
So what you see on your phone display is what was actually received by the client, i.e. sent by the SIP server.
Now, intermediate SIP servers (and proxies) do have the capability of changing all headers on-the-fly, but in most cases these do not reside at customer's end.

Thank you very much for the explanation. I appreciate it.

To confirm, I've never received a 503, but for some reason you keep ignoring this fact.

I'm not ignoring that. I'm saying other users received "Temporary Failure" (edit: in FPL's call log user portal) and wondering what you make of that error.

More specifically, I don't want people to be experiencing this issue, and my submitting a ticket to someone who is probably not a senior rep, is probably going to get my ticket closed if I can't specify what the problem is, especially since I can't, inexplicably, reproduce it.

And I think I still may have the packet captures, unless I've deleted them already.

I suspect, since the issue is with FPL, you're not going to see anything exciting coming back to you (failover to voicemail), but if you do come across a likely cause, I'll add it to my ticket. Thank you.

[Liptonbrisk]

Support staff isn’t obliged to read the forums or respond here. It’s best to submit a ticket if you're positive the issue isn't on your end: https://support.fongo.com/hc/en-us/requests/new.

For ongoing, unresolved issues that can’t be fixed with tickets, customers can submit complaints to CCTS:
https://www.ccts-cprst.ca/. I would give Fongo a week to respond to support request tickets first, at least, unless they've been closed
There's a delay in ticket responses due to COVID-19.

Other places to look for info include https://status.fongo.com/ (I don't see anything interesting yet) and https://twitter.com/Fongo_Mobile/with_replies (again, I don't see anything related).

Fongo's service phone number is 647-847-1355. I'm skeptical that anyone is answering calls though, and they don't work on weekends.

I can't stay logged in the forums all day. If someone wants to quote this for me from time to time in this thread so that others know how to contact Fongo support, I would appreciate it. Thank you.

[aLti]

I'm not ignoring that. I'm saying other users received "Temporary Failure" and wondering what you make of that error.

Once again, you appear to be mistaken. The "Temporary Failure" wasn't received by any user. This was received & logged by FPL's servers instead.
You need to clearly differentiate what is received by FPL's servers vs. what is received by end users. And many times this might actually tell you where the problem lies.
So "Temporary Failure" was seen at FPL's end only, not at customer's end, and there's a huge difference between the two.