Do these calls or ringing correspond with different numbers (that clearly aren't normal phone numbers) on your call display? 100, 1000, 1001, 999, (or "admin") etc? If so, those aren't calls. They're SIP scanners. SIP scanners are programs written by crackers (script kiddies). They look for ways to break into your home network by scanning for open ports. Typically, they'll scan for common service ports to see if they're open, such as UDP 5060, 5061 and a few others (some scan for a lot more than that). If a port is open, they can access your ATA (and, potentially, other devices on your LAN). Your phones will ring with caller ids appearing as 1001, 999, something else that's clearly not a regular phone number, etc. These crackers will try to make free calls using your services (or much worse). That's why it's important to have a good NAT firewall in a router protecting your ATA, computers, and other devices on your LAN (local area network) and to never port forward or use DMZ. Port forwarding is security risk. Enabling DMZ is even worse.
Do you not have a router? Possibly Carrytel issued you a modem/router combo or gateway, and if so, it probably had a restricted cone NAT firewall. If you were not issued a modem/router combo or gateway by Cogeco and if you don't have your own router, then your ATA is unprotected. If Cogeco gave you a gateway or modem/router combo that has a Full Cone NAT, then it would also not be very useful for protecting your ATA.
When you check your call logs, by logging into
https://www.freephoneline.ca/callLogs, do you see the call that you answered listed? If not, then you're not dealing with actual phone calls. That's an important question.
1. Do you have "Allow Incoming SIP Messages from SIP Proxy Only" enabled in your ATA? If not, it should be. That feature does help block SIP Scanners.
2. Ensure that your ATA is provisioned according to this PDF file:
viewtopic.php?f=15&t=18839#p75423.
Check your settings.
3. When buying a router for VoIP, ensure you buy one that does not have a full cone NAT.
Visit
https://www.think-like-a-computer.com/2 ... es-of-nat/.
Mango from the Obitalk.com forums writes,
“Use a restricted cone NAT router, and do not use port forwarding or DMZ. Restricted cone NAT will only permit inbound traffic from the service provider you're registered to. If you have a full cone NAT router, it will allow traffic from any source. This is probably not what you intend.
If you have a Windows computer, you can test your router using the utility here:
http://www.dslreports.com/forum/remark,22292023. To run it, use stun stun.ekiga.net from a command prompt.” Essentially, you download the stun-test.zip file; extract the stun.exe file from within the zip file to an easily accessible location; use an elevated command prompt (visit
http://www.thewindowsclub.com/how-to-ru ... inistrator); change directory (cd) to the directory or location where you extracted stun.exe (visit
http://www.digitalcitizen.life/command- ... c-commands); and type “stun stun.ekiga.net” without the quotation marks followed by the enter/return button on your keyboard.
Asus routers, at the time of this writing, produce port restricted cone NAT routers, for example and are fine, provided you’re using one with Asuswrt-Merlin, third party firmware installed:
https://asuswrt.lostrealm.ca/about.
4. Again port forwarding and using DMZ are bad ideas (port forwarding opens ports/holes in your NAT firewall; it's a security issue). And that's another reason why you should have a router with a good firewall to protect your ATA.
5. It's best to have a decent router for VoIP.
Stick your ISP's modem/router combo or gateway in bridge mode, use your own router, and properly enable QoS for your ATA (if you’re going to use adaptive QoS, give your ATA the highest priority for internet traffic and assign lower priorities for all other devices on your LAN). Refer to your router's manual.
I'm not a big fan of this site, but for a general QoS description, visit
http://www.voipmechanic.com/qos-for-voip.htm (avoid anything this site says about the G.729 codec because you really don’t want to be using this low bitrate codec unless you’re using Freephoneline on a smartphone with a poor cellular data signal).
What you want in a router for Freephoneline (or a VoIP SIP service) is one
a) with a restricted or port restricted cone NAT Firewall,
b) that lets you disable its SIP ALG feature (especially if it's faulty),
c) with strong QoS features,
and d) that has the capacity to modify both Assured and Unreplied UDP timeouts.
With respect to "d)" ...
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, 10, 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.
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 General–>Tools-->Other settings. In part, for this reason, I tend to use Asus routers. However, 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.
The keep alive interval for FPL is 20. The SIP Registration Failure Retry Wait Time is 120. I use 10 for UDP Unreplied Timeout and 117 for UDP Assured Timeout.
Nothing (gateways or modem/router combos) currently issued by ISPs has all of those features. Typically it's best to put whatever gateway or router/modem combo they given you into bridge mode and to use your own router with the features that were just listed. In particular, point "a" helps to protect your ATA. Points b,c,and d and unrelated to SIP Scanner issues. But if you happen to be looking for a new router, those are things to consider.
So SIP scanners are the first cause for ringing that I would consider. Another, significantly less likely, cause may be related to ring voltage settings or the specific phone you're using (try another phone), but the reason I think a voltage issue is unlikely is due to the fact you weren't experiencing this problem with Carrytel. If it is some voltage issue, I probably won't be able to assist.