jawsont wrote: it must be something on the other end.
Well there could be an issue with your account (and you can test it yourself by configuring your account on a SIP app or by using the FPL desktop app) after migration.
But all servers are working this morning. I've tested all of them. I have no issue with incoming or outgoing calls on any of them using any of my FPL accounts. And I've been testing voip.freephonleline.ca since yesterday evening until 9 a.m. EST this morning. It's worked perfectly fine.
http://forum.fongo.com/viewtopic.php?f= ... =25#p77370
1) When you login at
https://www.freephoneline.ca/showSipSettings,
a) what does SIP Status indicate?
b) what does SIP User agent indicate?
2) a) Dial ***1. Enter the IP address you hear into a web browser.
b)Log into the ATA (default username and password are "admin" without quotation marks).
c)Navigate to Status-->System Status-->SP(FPL) Service Status
What does the registration status indicate? Please copy and paste the status here.
3) What brand and model modem are you using?
4) What brand and model router are you using?
5) If you used the Obitalk web portal (
http://www.obitalk.com) to configure your ATA, keep in mind that you must continue using it to configure your ATA. Otherwise whatever settings you change will eventually be overwritten by what you previously entered at obitalk.com anyway. If you wish to disable this behaviour, dial ***1. Enter that IP address into a web browser. Navigate to System Management-->OBiTalk Provisioning-->select Disabled for the method. Save. Reboot ATA. Now obitalk.com won't overwrite whatever changes you make via the device's interface (via IP address).
Pick one method (obitalk.com) or the other (IP address of device) for changing device settings. But do not use both methods.
(In Obitalk.com, you will need to enable and enter expert settings to do the following, if you want to use Obitalk.com. You do this by selecting Edit Profile-->Advanced Options-->check Enable OBi Expert Entry from Dashboard-->submit))
Keep in mind too, that if you're using the Obitalk.com web portal, after you submit a new setting, it take several minutes before Obitalk.com pushes the changes you've made to your ATA. Your ATA should reboot automatically after the changes are submitted.
In your Obihai ATA or at Obitalk.com (whichever method you normally use; don't use both methods), navigate to Voice Services-->SP(FPL) Service-->X_UserAgentPort. X_UserAgentPort should be a random port number between 30000 and 60000. Just pick a port number in that range. Change to a new port number in that range. Click the “submit” button, and reboot the ATA. (If you use Obitalk.com to change settings, you will need to continue using Obitalk.com).
If changing X_UserAgentPort works, you were dealing with a corrupted NAT connection in your router.
Possibly a NAT router connection was never disconnected or never timed out properly. And, then, the ATA keeps the corrupted connection in a persistent state over and over again. (Credit goes to Mango for this information). Possibly, this problem is due to the router's UDP timeout being in excess of the ATA's Failure Retry timer (RegisterRetryInterval with Obihai ATAs). With FPL, that's 120 seconds.
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_KeepaliveExpires is supposed to be 20 with FPL.
Getting access to both UDP Unreplied Timeout and UDP Assured Timeout settings in consumer routers may be difficult, if not impossible. Asuswrt-Merlin, third party firmware for Asus routers, does offer easy access to these two settings, which are found under Tools-->Other settings. However, my understanding is that third party Tomato firmware has these two settings as well. Mikrotik routers do as well:
https://forums.redflagdeals.com/recomme ... #p28056619. 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.
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.
RegisterRetryInterval can be found by navigating to ITSP Profile (whichever one you use for FPL)-->SIP-->RegisterRetryInterval (should be 120 seconds or higher if need be)
X_KeepAliveExpires can be found by navigating to Voice Services-->SP (whichever one you use for FPL)-->X_KeepAliveExpires
6 a)
Note that too many registration attempts within a short period can result in a temporary IP ban with the server you're attempting to register with. Always check registration status in the ATA and also your SIP status after logging in at
https://www.freephoneline.ca/showSipSettings. If you see a device listed under SIP User Agent that you don't recognize, you've either been hacked or someone else is using your Freephoneline SIP username and SIP Password.
Each time you reboot the ATA, it's attempting to register with Freephoneline again. If you attempt more than 10 registrations in 5 minutes (this is why the RegistrationPeriod of 3600 seconds in addition to the RegisterRetryInterval of 120 seconds are important settings in your ATA),
you may end up being temporarily IP banned by the specific FPL server the ATA (and/or desktop app) was sending
registration requests to.
RegistrationPeriod can be found by navigating to ITSP Profile (whichever one you use for FPL)-->SIP-->RegistrationPeriod (needs to be 3600 seconds)
https://support.freephoneline.ca/hc/en- ... /212430746
If you're temporarily IP banned, you could then try switching ProxyServer to a different FPL server than the one you were previously using (voip.freephoneline.ca, voip2.freephoneline.ca, or voip4.freephoneline.ca:6060), unless you need to use voip4.freephoneline.ca:6060 because you have SIP ALG forced on in your router. The purpose of
voip4.freephoneline.ca:6060 is to circumvent buggy SIP ALG features in routers.
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)."
b) Also note that only one registration per FPL account is allowed at any time. When there are multiple devices/softphones using the same account, only the most recent registration is valid. The previous device will lose registration and incoming calls will not work on it.
7) As hanke mentioned, you can also try rebooting your modem–>router (wait for it to be fully up and transmitting data; wait for Wi-Fi SSIDs to populate first)–>ATA (in that specific order). That's always proper device reboot order.
8) You can try to eliminate your router as being the source of the problem by briefly connecting the ATA directly to your modem. If that works, the issue involves your router.
If the issue still persists afterwards, you can try to submit a ticket asking for a "forced registration." Freephoneline doesn't normally offer free technical support, but if your account has been affected as a result of the server migration, it doesn't hurt to ask.