[SOLVED] Incoming calls using Asus routers

[emporium]

Is there presently any issues with Incoming calls ?

I haven't changed anything, and since yesterday evening, all incoming calls, seem to timeout (no ringing on callers end) but then go straight to voicemail.

No changes to network setup recently. All has been working fine for years..
Rebooted router and cable modem (just in case), but no difference.

Also tried different servers (voip, and voip2 at least) and no difference.

Outgoing calls work flawlessly.

Another provider/profile on my ATA works fine.

Any feedback would be appreciated.

[Liptonbrisk]

No issues with 3 different phone numbers, including one with the ATA in B.C.
Two are registered on voip4.freephoneline.ca:6060 in Ontario.

I'll try voip.freephoneline.ca

[Liptonbrisk]

I can't reproduce this on any server.

I'll try a fourth FPL number.

[Liptonbrisk]

I'll try a fourth FPL number.

Works fine.

[Liptonbrisk]

If a server is being affected, I'm not experiencing the problem yet.

In the meantime, refer to pages 40, 41, and 42 from download/file.php?id=2156 under the heading, "Are you getting one way audio issues with an OBi200/202 and Freephoneline? Are incoming calls not ringing? Can you not hear one side of the conversation (you can hear the caller, but the caller can't hear you or viceversa)?".

Make sure to try a new random X_UserAgentPort, and check registration status in your ATA:

Dial ***1
Enter the IP address you're told into your web browser. Login to your ATA.
Navigate to Status>>System Status

Registration is a requirement for incoming calls, and only one registration is allowed at any time per FPL account.

[Liptonbrisk]

I just did a 3-way call, and then I merged another call with a different number on another device to test for multiple channel issues.
Everything worked.

I'll try again in 30 minutes.

[Liptonbrisk]

Incoming calls on voip.freephoneline.ca still work.

Are you having problems with all incoming calls, or is it just a problem with incoming calls from one specific phone number?

[emporium]

Thank you for the quick feedback. I'll run a few more tests on my end. Just find it strange. Have not changed anything on my obi202, and neither on my router.. And it just started. It's been great for years.
Funny part, is I got 1 call that came in about 1hr ago, but that's it Nothing since. I've even tried calling from a fongo number I have on my cell phone and it does the same.

If I use the Old desktop app, I can see the incoming ring, but when I answer, I don't hear anything.

I'll continue further investigations on my end. I just want to make sure I wasn't wasting my time, if it was a known server end issue.

I'll post back if I find something.

[Liptonbrisk]

THave not changed anything on my obi202, and neither on my router.

That really doesn't mean very much since issues can occur in users' routers without them doing anything.
For example, refer to point D below.

Also, ISPs can push new firmware to their users' modems, hubs, or gateways without the customers' knowledge and settings can, in turn, be reset.


-----
(Generic info)

Typically, for VoIP SIP services, especially for Freephoneline/Fongo, you want

A) a router that does not have a full cone NAT,

Visit https://dh2i.com/kbs/kbs-2961448-unders ... -punching/.
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.

B) a router that lets you disable SIP ALG if it's buggy,

To understand why SIP ALG often causes horrible problems, please visit
https://www.voip-info.org/routers-sip-alg/ (scroll down to the section on SIP ALG problems).

If you're dealing with a modem/router combo issued by an ISP or a router with SIP ALG forced on, you may have
to use voip4.freephoneline.ca:6060 for the Proxy Server. The purpose of voip4.freephoneline.ca:6060 is to circumvent
faulty SIP ALG features in routers.

C) a router that allows you to set QoS or assign highest priority to your ATA or IP Phone over all other devices on your LAN (local area network),

For a very general description of what QoS can do for you, visit https://www.voipmechanic.com/qos-for-voip.htm.
The basic idea is if you're torrenting or have a bunch of other computers, smartphones, tablets, etc. downloading and uploading (hogging all your available bandwidth), you don't want
your ATA not to have access to enough bandwidth to make or receive calls properly. So QoS or a Bandwidth Monitor feature (which is just another form of QoS) is a really good idea for VoIP users.

I often get an occasional relative complaining to me, "Hey my calls sound choppy." And then when I go visit, some kids are playing MMOs on a computer, while another person is downloading a huge file,
and another person is backing up files to a cloud service all at the same time someone else is trying to talk on the phone. All those devices, without QoS enabled, are fighting over available bandwidth along with the ATA.

and D) A router that lets you adjust both Unreplied and Assured UDP timeouts.

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; for Grandstream, the setting is SIP OPTIONS Keep Alive Interval) < 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, 15, 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 ... #p28059363.

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

Asuswrt-Merlin
Ubiquiti
Mikrotik
pfSense
Tomato
DD-WRT


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



ISPs do not issue customers routers that can do all four things I just listed. Typically it's far better to have your own router with strong QoS functions and a restricted cone NAT firewall,
disable whatever SIP ALG feature is enabled in the router, and stick whatever modem/router combo your ISP gives you into bridge mode. For Bell Hubs, visit http://forums.redflagdeals.com/please-s ... r-1993629/. For Rogers, visit https://www.rogers.com/customer/support ... ridgemodem.
--

Funny part, is I got 1 call that came in about 1hr ago, but that's it Nothing since. I've even tried calling from a fongo number I have on my cell phone and it does the same.

That sounds as though a NAT hole is closing after a certain period that follows after rebooting the router.

1) What brand and model modem, modem/router combo, gateway, or Hub are you using?
If it's a modem/router combo device, hub, or gateway, ensure that it's in bridge mode, and especially check to ensure SIP ALG is disabled. This is important if the ISP pushed new firmware to the device, and if, consequently, some settings were reset. If it's just a regular modem without a router built into it, then that doesn't matter.

2) Are you still using the Asus router listed in your profile? Asus routers should not require SIP Passthrough to be disabled to work with FPL, but the ISP's device, if it isn't just a straight modem without a router built into it, should be in bridge mode. If you're not using the Asus router in your profile, what brand and model router are you using?

[Liptonbrisk]

If I use the Old desktop app, I can see the incoming ring, but when I answer, I don't hear anything.

That could be SIP ALG or NAT firewall related. The RTP audio stream is being blocked or not routed to the LAN IP of your computer. Pay attention to steps i, ii, and iv below. RTP ports used are UDP 13000 and UDP 13001. That differs from the RTP ports used in the ATA.

For the Freephoneline Windows desktop app . . .

Make sure that you're not muting anything (microphone/speakers), and that you tested to ensure your mic is working before fiddling around with the Windows app: http://win10faq.com/fix-microphone-settings/

And make sure you test incoming calls for 1-way audio issues before paying anything to FPL (you'll need a mic and headphones/speakers to test). Test on a computer that's connected to your router (without DMZ or port forwarding enabled). Should you encounter 1-way audio issues, look for a feature called SIP ALG in your router (you may need to call your ISP if you're using a modem/router combo) and disable that feature.

Steps i,ii, and iv below are for help dealing with 1-way audio issues with Freephoneline Windows desktop application.


from http://forums.redflagdeals.com/fongo-at ... #p27011164

You can try the Freephoneline desktop app for free: https://www.freephoneline.ca/downloadDesktopApplication
It requires 32-bit Java to run. If you have problems installing the desktop app, visit http://forum.fongo.com/viewtopic.php?f= ... 63&p=74810.


A.Use winmtr https://sourceforge.net/projects/winmtr/

B. For Freephoneline.ca (based in Ontario), test to voip.freephoneline.ca (let winmtr ping about 100 times), voip2.freephoneline.ca, and voip4.freephoneline.ca. You can copy text to clipboard and paste your results (do not post your own IP public address though) and post them for others to examine if you want.

C. Look at the very last hop or line. Take a look at your average ping--and your maximum. You want those values to be relatively close.
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), you should probably avoid FPL.

I get between 11 (voip.freephoneline.ca and voip2.freephoneline.ca)-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.

Try the free FPL desktop app first: https://www.fongo.com/app/desktop/

Make sure that you're not muting anything (microphone/speakers), and that you tested to ensure your mic is working before fiddling around with the app: http://win10faq.com/fix-microphone-settings/

And make sure you test incoming calls for 1-way audio issues. Test on a computer that's connected to your router (without DMZ or port forwarding enabled). Should you encounter 1-way audio issues, look for a feature called SIP ALG in your router (you may need to call your ISP if you're using a modem/router combo) and disable that feature. You should not need to do so with Asus routers or those running Asuswrt-Merlin, but you do need to in the ISP's device (better still to put it in bridge mode).


i. Typically it's better to have your own router and to stick whatever modem/router combo your ISP gives you into bridge mode.

ii. Disable SIP ALG in your own router. Many modem/router combos that are issued by ISPs have faulty SIP ALG/SPI functions enabled, with no way to disable them. These features can mangle SIP headers. If you don't know how to disable SIP ALG, contact your router's brand or contact your ISP.

To understand why SIP ALG is often a serious headache visit https://www.voip-info.org/routers-sip-alg/ (scroll down to "SIP ALG Problems")

iii. Properly enable QoS in your router for your computer that's running the Freephoneline desktop app (and ensure no other programs are running on your computer that are hogging bandwidth while using the Freephoneline desktop app). Refer to your router's manual or contact your ISP if you were issued a modem/router combo from them (typically those routers suck and have horrible or absent QoS functions).

I'm not a huge fan of this website, but it suffices for an explanation of QoS: http://www.voipmechanic.com/qos-for-voip.htm
Avoid anything it says about the G.729


iv. If you still get one-way audio issues with the Freephoneline desktop app, you may need to port forward, which is a security risk (and not advisable).

The FPL desktop app uses ports 5060-5061,6060-6061,13000-13001 if you're going to port forward for the desktop app (you need to port forward to the LAN IP of the computer you're using. For most home networks the IP will begin 192.168.xxx.x). Refer to your router's manual to learn how to port forward (if your router came from your ISP, contact your ISP).

I would start just by port forwarding 13000-13001 only, which is for RTP (audio packets). If that still doesn't work, you can try adding 6060 or 6061. The most dangerous ports to forward are 5060-5061 and really shouldn't be necessary if you're forwarding 6060 or 6061 anyway. I guess if all else fails, forward all of them: 5060, 5061,6060, 6061,13000, and 13001.

These are all UDP ports.

5060, 5061, 6060, and 6061 should be alternate SIP ports.

Only port forward if all else fails (and only do it temporarily, since it's a security risk).

[Liptonbrisk]

For your ATA, I suggest going through pages 40, 41, and 42 from download/file.php?id=2162 under the heading, "Are you getting one way audio issues with an OBi200/202 and Freephoneline? Are incoming calls not ringing? Can you not hear one side of the conversation (you can hear the caller, but the caller can't hear you or vice versa)?".

Try switching ProxyServer to voip4.freephoneline.ca:6060. If that works, the problem is likely SIP ALG related. The purpose of voip4.freephoneline.ca:6060 is to circumvent SIP ALG.


Dial ***1
Enter the IP address you're told into your web browser. Login to your ATA.
Navigate to Status>>Call Status.
While a call is incoming, check call status.

Afterwards, check Status>>Call History.
If the incoming call isn't listed, it never reached your ATA.
If the incoming call never reached the ATA, ensure that both X_UsePublicAddressInVia and X_DiscoverPublicAddress are enabled in the ATA.
Those settings are found by navigating to Service Providers-->ITSP Profile (FPL)-->SIP.
Also ensure your ISP's modem/router combo is in bridge mode, and if you can't get it in bridge mode, ensure, at least, that SIP ALG is disabled in it.

If the call is listed but you didn't hear anything, pay close attention to step 11 on page 41 at download/file.php?id=2162. The RTP audio stream isn't being received.

Then check to see if the incoming call is listed in FPL's call history at https://www.freephoneline.ca/callLogs.


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, consequently, incoming calls will not work 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, the FPL desktop application, or with another device. Registration is required for incoming calls. It is not required for outgoing calls. A more significant concern, though, is that multiple registration attempts can lead to temporary IP bans. The more devices being used can make the temporary ban happen more quickly. Note that each time you reboot or restart your ATA or FPL desktop application, it's attempting to register with Freephoneline again. Multiple registration attempts within a short period can result in a temporary IP ban. Each time you reboot your ATA it's attempting to register with FPL's proxy server.

Do not test the ATA while the FPL desktop app is running and vice versa when using both with the same FPL account.

To check registration status in the ATA
Dial ***1
Enter the IP address you're told into your web browser. Login to your ATA.
Navigate to Status>>System Status

Lastly, this is always proper device reboot order:

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 only after the router is fully up and running.

[Liptonbrisk]

By the way, incoming calls are still working for me on voip.freephoneline.ca

I also tested with the desktop app and Fongo Mobile.

If there is a problem, I can't reproduce it at the moment.

Make sure you reboot modem-->router-->ATA in that order, making sure that each device is fully up and running before turning on the next one.

If you have access to a smartphone SIP app, try using cellular data (not Wi-Fi) to see if you can reproduce the problem.
If you can, then submit a ticket: https://support.fongo.com/hc/en-us/requests/new.
Choose "my account inquiry" for the final issue type.

Also, please let me know if you still have the problem using cellular data on a smartphone SIP app. If you do, I'll try reaching out to ask about a potential larger issue.

[emporium]

I'd like to thank you for all the recommendations. You are awesome.

After further investigation, I swapped out my Asus router (running asuswrt-merlin firmware) with a ubiquiti edgerouter Lite I had lying around.
Well, everything worked flawlessly with close to default settings.. So obviously it was something in the router that was causing the issue. So put back the old Asus router, and started checking all the settings one by one.

Low an behold I found the problem. Under the WAN section, NAT passthrough. For some reason my SIP passthrough was set to "enabled + NAT helper". Changed it to disabled, saved and rebooted, and all came back to normal.

I find it strange how it was working before (for so many years) with that setting. I checked even my previous ASUS router (which I decommissioned nearly 3 years ago) and that setting was also the same on that. Somehow, something else changed that made this setting have the effect that we all expect from this setting. I never experienced any issues in the past even with that setting enabled. Maybe something change at the ISP level (proxies, routing, etc..) that now caused this to have an apparent effect.

Anyhow, I really appreciate all your input.

[Liptonbrisk]

Under the WAN section, NAT passthrough. For some reason my SIP passthrough was set to "enabled + NAT helper".

That's the default setting in Merlin.

Changed it to disabled, saved and rebooted, and all came back to normal.

The NAT Helper option is only listed that way in Merlin firmware (as opposed to official Asus firmware), and NAT Helper is the ALG. Merlin firmware no longer supports RT-AC3200 after firmware version 384.13_10 (released 28-June-2020). I don't remember how NAT Helper behaved in 384.13_10, and I would have been using an RT-AC86U in June 2020. I always had NAT Helper enabled (and incoming calls worked fine, obviously) until I read about a potential security risk. I don't remember exactly when I stopped using NAT helper. I mention the RT-AC3200 because it's in your profile.

In fact, Merlin describes the risk here: https://www.snbforums.com/threads/vulne ... ost-657216.

The NAT Slipstream attack is the one that uses ALGs helpers to potentially compromise clients. I recommend making sure none of the settings on the NAT Passthrough page is set to "Enabled + NAT Helper", they should be either "Enabled" or "Disabled". I haven't tested this, but I would expect that ensuring NAT helpers are disabled to be enough to prevent this attack vector.

Those ALG are generally not needed by modern clients. For instance, I have both an ATA (for my home phone) and a direct IP phone (for work) here, both work fine without the need for an ALG helper.

It's curious to me, then, why the default setting for SIP Passthrough is "Enabled + NAT Helper" in Merlin firmware. It seems to me the default setting should be "Enabled" instead.
He could have a good reason that I'm oblivious to, I suppose.

"NAT Helper" = ALG. So if it's not showing "NAT Helper" then it means the ALG aren't used.

I'm using Merlin 386.2_4 (I always use the latest version) with an AX model Asus router, and SIP Passthrough works with Freephoneline with SIP Passthrough set to whatever option I choose, provided I'm using the recommended settings in this guide: download/file.php?id=2162.

For security, I avoid "+NAT Helper" now.

"Disabled" means block the SIP port (UDP 5060). "Disabled" still works with Freephoneline with both X_UsePublicAddressInVia and X_DiscoverPublicAddress enabled in the ATA.

"Enabled" means the ALG isn't being used, but NAT traffic is allowed to pass through. This will set set your WAN IP with UDP 5060 for external SIP packets. Freephoneline works with SIP Passthrough set to "Enabled" on all servers.

"Enabled+NAT Helper" means allow NAT traffic to pass through and also enable the ALG. I never use this setting anymore, but I just tested, and Freephoneline works for incoming and outgoing calls with NAT Helper enabled.

In official Asus firmware, "Enabled" for SIP Passthrough is the same as Merlin's "Enabled + NAT Helper".

I find it strange how it was working before (for so many years) with that setting

It's always worked for me, but it's been awhile since I've tested with NAT helper enabled, and it’s possible behaviour for that setting changed with specific firmware versions.
I'm not going to bother guessing what happened without looking at a syslog from your ATA and router, and I just don't get paid enough to do that , particularly since your issue is resolved.
I'm glad it is! Enjoy your weekend!

[EliG]

I ran into a similar issue today. A friend with an FPL number alerted me that my FPL number stopped responding in the last 2-3 days.

I did two test calls:

1. Fongo app to FPL: no incoming call. Fongo app failed to connect. Fongo and FPL are two different accounts.
2. cell to FPL: worked fine

My setup:

SPA112 + Asus RT-AC68U (stock firmware). I've had this setup for a long time without issues.

I checked SIP Passthrough setting in the router. It was set to "enabled". I changed it to "disabled" and retried the tests.

1. Fongo app to FPL: the issue is fixed
2. cell to FPL: still works

I will do FPL to FPL test tomorrow.

ADDED: I swear the issue happened on its own without me touching anything in the ATA or the router.

[Liptonbrisk]

A friend with an FPL number alerted me that my FPL number stopped responding in the last 2-3 days.

1) Does your friend have SIP ALG enabled in any device and/or not have the ISP's device (if it's not just a modem) in bridge mode?

2) What ATA or IP Phone is your friend using? If it's the same as yours, does your friend have
these settings enabled?

Navigate to Voice-->SIP

Handle VIA received should be yes
Handle VIA rport should be yes
Substitute VIA Addr should be yes

Asus RT-AC68U (stock firmware).

While I don't want to make people do something they don't want, you may wish to consider switching to Merlin due to point D from https://forum.fongo.com/viewtopic.php?f ... 182#p78900.

Fongo and FPL are two different accounts.

Yes, it's impossible for them not to be.

By the way, Fongo Mobile/Home Phone to FPL and FPL to FPL calls are SIP URI calls, which differ from calls originating outside Fibernetics' network.


Should you ever experience all incoming calls failing (not just Fibernetics to Fibernetics), navigate to Voice-->Line in your ATA-->Set SIP Port to a random number between 30000 and 60000.
Submit settings, reboot the ATA, and then test with an incoming call. If that works, the problem is due to NAT corruption developing between the ATA and the router (switch to Merlin as noted above and adjust UDP timeouts to satisfy the conditions listed). I would do this anyway right now to help thwart potential SIP Scanners.

I checked SIP Passthrough setting in the router. It was set to "enabled".

As a result of the security issue I mentioned earlier, I recommend keeping that setting disabled. It's the same as having NAT Helper enabled in Merlin.
The ALG is on.

ADDED: I swear the issue happened on its own without me touching anything in the ATA or the router.

NAT corruption can develop between routers and ATAs without users doing anything, but what you're describing does suggest something else.
I've been using FPL since 2010, and, probably until sometime in 2020, whenever I used Asus routers, I had ALG on without incoming call issues (both stock and Merlin).
I've had ALG off since then.

I can call from FPL/Fongo/anything to FPL with SIP Passthrough set to Enabled + NAT Helper right now in Merlin firmware version 386.2_4 without issue.
There is nothing I can change in the SIP Passthrough setting in Merlin to not make any incoming call not work.

I could dig out another Asus router from my basement to test with official Asus firmware, but it's not worth the effort. It's simpler and safer to just keep SIP Passthrough off in official Asus firmware or NAT Helper off in Merlin.

[Liptonbrisk]

I will do FPL to FPL test tomorrow.
.

Thanks for your feedback.

Before testing, please follow the steps below, step by step, down the list.

1. If you have a modem/router combo or gateway issued by your ISP, please ensure that it's in bridge mode.

2. Ensure you're using the lastest Asus firmware version for your router: https://www.asus.com/ca-en/networking-i ... k_Download
Please let us know what firmware version you'll be using.


3) Check to see whether you've accidentally enabled Caller ID block on your ATA. Dial *68 to remove caller ID blocking on all outbound calls.
Don't use "Anonymous" for display name in your ATA. Don't use or accidentally dial *67.

4. In your ATA, navigate to Voice-->Line (whichever you use for FPL)-->Supplementary Service Subscription-->Block CID Serv:
a) change to no
b) Click "submit"

5) Login to your ATA. Specify a high random SIP port in your ATA between 30000 and 60000.
Navigate to Voice-->Line 1 (or whatever you're using for FPL)-->SIP settings, change SIP Port to a random number between 30000 and 60000.
Do not use the same random SIP port for any other Line. Always choose a different random local SIP port for each Line you're using.

Using a high random SIP port may help to avoid SIP Scanners (or hackers).
Also, changing local SIP port will reset a potential corrupted NAT association that developed between your router and ATA.

6. Navigate to Voice-->SIP-->NAT Support Parameters, and make sure that the following settings are enabled:

a)Handle VIA received-->yes
b)Handle VIA rport-->yes
c)Substitute VIA Addr-->yes
d) NAT Keep Alive Interval--> 20 seconds

e) click "Save Settings" button

This helps to ensure the RTP audio stream is being sent to your WAN IP as opposed to your LAN IP.

If the people you are calling are also using SPA/PAP ATAs, check to ensure they’re using those settings as well.

7. Navigate to Voice-->Line (whichever you use for FPL)-->NAT settings
a) NAT Mapping Enable should be yes
b) NAT Keep Alive Enable should be yes
c) NAT Keep Alive Msg should be $NOTIFY

d) click "Save Settings" button if changes were made

8. Navigate to Voice-->SIP-->SIP Timer Values (sec)
Reg Retry Intvl should be 120 seconds

Click "Save Settings" button if changes were made

https://support.freephoneline.ca/hc/en- ... redentials

Many older guides for FPL don't include this setting.

9. Proper device reboot order is always modem (wait for it to be fully up before turning on your)-->router (ensure Wi-Fi SSIDs are populated first on your devices)-->ATA (wait for router to be fully up and running before turning on ATA). That's always proper device reboot order. Please reboot your devices now in that order.

10. Test calls.

It's clearly safer to just keep SIP Passthrough off in official Asus firmware or NAT Helper off in Merlin, and since SIP ALG off works, I'm just going to recommend not using it.

[EliG]

Liptonbrisk, thank you so much. That was very helpful.

First, a correction. I got the bolded part wrong:

A friend with an FPL number alerted me that my FPL number stopped responding in the last 2-3 days.

Friend was calling from a Fido cell. She wasn't getting ringtones when dialing my FPL number. She tried again today. The issue is fixed.

We did the test before I adjusted the settings in the ATA (as per your recommendations). I am guessing that disabling SIP Passthrough in the router did the trick.

Asus RT-AC68U (stock firmware).

While I don't want to make people do something they don't want, you may wish to consider switching to Merlin due to point D from viewtopic.php?f=8&t=20182#p78900.

Thank you for pointing this out. I will consider it.

Fongo and FPL are two different accounts.

Yes, it's impossible for them not to be.

Sorry, I wasn't sure. Spelled it out just to be safe.

I checked SIP Passthrough setting in the router. It was set to "enabled".

As a result of the security issue I mentioned earlier, I recommend keeping that setting disabled. It's the same as having NAT Helper enabled in Merlin.
...
I could dig out another Asus router from my basement to test with official Asus firmware, but it's not worth the effort. It's simpler and safer to just keep SIP Passthrough off in official Asus firmware or NAT Helper off in Merlin.

Yes, I will keep it disabled.

Before testing, please follow the steps below, step by step, down the list.

Done. I went down the list step by step and made a few adjustments.

Thank you again. I really appreciate your help.

[Liptonbrisk]

We did the test before I adjusted the settings in the ATA (as per your recommendations). I am guessing that disabling SIP Passthrough in the router did the trick.

Behaviour with SIP Passthrough changed awhile ago in an older Asus firmware version. Do you happen to know what firmware version you were using?

It would be interesting to test with the new changes you've made and the latest Asus router firmware version. If you'd like to test again, please follow these steps:

1) Enable SIP Passthrough.
2) Reboot Router. Wait for it to be completely up and running.
3). Reboot ATA.
4) Have your friend call you on Fido.

Afterwards, disable SIP Passthrough again and keep it off. Please let me know the version of the Asus router firmware version used.

Sorry, I wasn't sure. Spelled it out just to be safe.

No reason to apologize. I do appreciate the feedback. Thank you.

That was very helpful.

I'm glad I helped. Enjoy the rest of your weekend!

[EliG]

We did the test before I adjusted the settings in the ATA (as per your recommendations). I am guessing that disabling SIP Passthrough in the router did the trick.

Behaviour with SIP Passthrough changed awhile ago in an older Asus firmware version. Do you happen to know what firmware version you were using?

I was running 3.0.0.4.386_41634 (2021/01/18)

The latest version is 3.0.0.4.386_43129 (2021/05/21)

It would be interesting to test with the new changes you've made and the latest Asus router firmware version. If you'd like to test again, please follow these steps:

1) Enable SIP Passthrough.
2) Reboot Router. Wait for it to be completely up and running.
3). Reboot ATA.
4) Have your friend call you on Fido.

Afterwards, disable SIP Passthrough again and keep it off. Please let me know the version of the Asus router firmware version used.

Upgraded to 3.0.0.4.386_43129, rebooted devices and re-ran the tests.

SIP Passthrough enabled
* friend's Fido cell: cannot connect
* Fongo app running on iPad: cannot connect
* my Petro-Canada cell: works fine

SIP Passthrough disabled
* all of the above work fine

I find it strange that Fido and Petro-Canada cells behave differently. Both run on Rogers network.

I left SIP Passthrough disabled.

[Liptonbrisk]

Thank you. That's pretty useful.
I'd ask for a syslog from the ATA, but it's really not going to change what needs to be done anyway.
Something has happened that requires ALG off now in Asus firmware that didn't before, and since ALG presents a security risk, it's better just to have it off.
Thanks again! I appreciate you testing for me.

[SeanO2000]

i had the same issue on the same day. the sip alg / disabled worked for me too. funny how we all had this on the same day......

thanks everyone

[Liptonbrisk]

B) a router that lets you disable SIP ALG if it's buggy,

To understand why SIP ALG often causes horrible problems, please visit
https://www.voip-info.org/routers-sip-alg/ (scroll down to the section on SIP ALG problems).

If you're dealing with a modem/router combo issued by an ISP or a router with SIP ALG forced on, you may have
to use voip4.freephoneline.ca:6060 for the Proxy Server. The purpose of voip4.freephoneline.ca:6060 is to circumvent
faulty SIP ALG features in routers.

Keeping SIP ALG off has been advised on these forums for years when encountering problems, so I expect many didn't notice a change in their service.
SIP ALG enabled didn't use to affect FPL with stock Asus firmware, but it appears to now.

[jawsont]

Guys, I cannot thank you enough. I've been beating myself in the face with this problem for days and only just found this thread. For me it manifested itself as no incoming calls from LANDLINES, but CELLPHONES worked ok to call in from (go figure). No wonder I was confused - I was thinking something like our phone providers were doing something wonky and blocking VOIP calls etc... I have tinkered with nearly every imaginable setting on my obihai not thinking it might be a router setting. Strange. I haven't changed anything on it to my knowledge (also running Asus Merlin!!!). NAT+enabled was the problem for me too. I switched it to enabled and got a successful call from my parents landline when testing.

THANK YOU ALL SO MUCH FOR THIS. Virtual beer in your mailboxes!

[edit: and having read the rest of the posts in the thread, now SIP passthrough is DISABLED since it would appear it's security vulnerability]

[Liptonbrisk]

now SIP passthrough is DISABLED

It's just the +NAT Helper part that is the ALG in Merlin. This differs from stock Asus firmware where "Enabled" means the ALG is on.
Enabled in Merlin does not.

https://www.snbforums.com/threads/vulne ... ost-657234

"NAT Helper" = ALG. So if it's not showing "NAT Helper" then it means the ALG aren't used.