For Linksys/Cisco ATAs with incoming call issues/1-way audio

[Liptonbrisk]

Always visit https://status.fongo.com/ first to check for reported issues.

Please read #28 down below and also understand that NAT corruption can develop between a router and ATA without a user doing anything (no matter how long FPL has been working for someone).

Check all cables and cords to ensure they're all secure (try a different phone as well).

Device registration is a requirement for incoming calls but not for outgoing ones. Only one registration is permitted per FPL account at any time. A single line on an ATA is one registration. A SIP app is another.

For Asus router users following the steps below, first login to your router’s web UI.
Navigate to Advanced Settings–>Administration–>System (tab)–>Basic Config–>
Change “Enable WAN down browser redirect notice” to "No".
Click “Apply”. That fixes potential problems with an ATA attempting to register with 10.0.0.1
when it's booted before the ISP's modem is fully up and running first (after a power outage, for example).



Follow the steps, step by step, down the list, please. Some ATA models may have menu locations that differ slightly, but they should be very similar.

1. If you're using a modem/router combo, gateway, or hub issued by your ISP (and are NOT using your own additional separate router), contact your ISP to ask for assistance for disabling SIP ALG in the modem/router combo, gateway, or hub. Disable SIP ALG. Refer to point 1 from viewtopic.php?f=8&t=20199.

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).


2. Make sure whatever modem/router combo, gateway, or hub your ISP gave you is in bridge mode if (and only if) you are using your own separate router as well. Call/contact your ISP if you have to.

For Bell and Virgin Hubs, I find it's often simpler to perform PPPoE login in your own router (this is PPPoE Passthrough) and disable Wi-Fi in the hub. You will need the PPPoE Username and Password from Bell or Virgin.

For Rogers, visit https://www.rogers.com/customer/support ... ridgemodem.
Shaw users will have to call Shaw to enable bridge mode at the time of this post.

For Telus Wi-Fi Hubs, put LAN port 1 on the Hub in bridge mode. Then connect your router to LAN port 1.
Alternatively, contact Telus and ask them how to enable bridge mode.


3. If you're using your own router in addition to the gateway or hub provided by your ISP, ensure SIP ALG or SIP Passthrough (Asus routers) is disabled in your own router. Refer to your router's manual.

4. Disable DMZ and all port forwarding in your router. Port forwarding is a security risk. Only port forward if you have no other choice.

5. a) If you're using an Ubiquiti router, disable jumbo frames.

b) This may affect pfSense users (and some others), depending on configuration: don't block incoming UDP connections from 208.85.218.146 and 208.85.218.147 if you want to hear audio. At the time of this post, those are the RTP IP addresses. Those IPs may eventually change.

6. If your ATA is connected to the internet using a third party VPN service, disable the VPN while troubleshooting.

7. Login at https://www.freephoneline.ca/voicemailSettings
Ensure "Rings Before Voicemail" is greater than 1.

8. While troubleshooting incoming call issues, disable Follow Me: login at https://www.freephoneline.ca/followMeSettings.

9. a) Dial ****
b) Then dial 110#
c) Enter the IP address you hear into a web browser.
d) Login to your ATA.
e) Always choose the admin login and advanced view menus (select "advanced" in the upper right).

For Linksys RT31P2, try logging in at http://192.168.15.1/Voice_adminPage.htm
Or try adding "/Voice_adminPage.htm" (without the quotation marks) after the Linksys RT31P2's LAN IP in a web browser.


10. A. Under User 1 and User 2 tabs

B. Select Advanced View

C. Under Supplementary Service Settings

Ensure

a) DND setting is set to NO
b) Block ANC Setting is set to NO
c) DND Activated is set to NO

D. Under User 1 and User 2 tabs (both of these, if your ATA offers both tabs--and if you're using both with Freephoneline; otherwise just choose the tab you're using with FPL)

Check Call Forward Settings

a) Cfwd All Dest

That field should be blank. If there's a phone number there you don't recognize, you were hacked.
Make that field blank.

b) Cfwd Busy Dest

That field should be blank. If there's a phone number there you don't recognize, you were hacked.
Make that field blank.


c) Cfwd No Ans Dest

That field should be blank. If there's a phone number there you don't recognize, you were hacked.
Make that field blank.

Submit all changes/Save Settings if changes were made.

11. If you have an SPA3102 (or an ATA with a PSTN line option) and don't have a traditional telephone landline service (aren't using PSTN), then

a) navigate to Voice tab-->Line 1 tab-->VoIP Fallback To PSTN, and set "Auto PSTN Fallback:" to "No".
Click "Submit All Changes" if changes were made.

and

b) navigate to Voice tab-->PSTN Line tab-->set Line enable to "No"
Click "Submit all Changes" if changes were made.

Note that the "Phone" port on the back of the SPA3102 is for calls made using Line 1. The "Line" port on the back of the ATA is for the PSTN Line (connecting to a traditional telephone service).

12. Navigate to Voice tab-->Line 1 tab (or whichever Line you're using for FPL)-->SIP settings, and change (local) SIP Port to a random number between 30000 and 60000. Specify a high random (UDP) SIP port in your ATA between 30000 and 60000. Just choose a UDP port number in that range. If you already have a random number in that range entered, choose a new random number within the same range, and enter it.

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. Never use UDP port 5060.

Using a high random SIP port may help to bypass SIP ALG, and it also helps 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 due to a UDP timeout issue (if a similar problem arises in the future, repeat this step, and change to a different port number within the same range).

Save settings/Submit all settings.

Reboot ATA.

Test incoming calls at this point. I just want to check at this point to see whether changing local SIP Port helped. If it did, the problem was NAT corruption or a UDP timeout (refer to point 28 down below) related issue in your router, which changing SIP Port helped to reset.


13. Log back into your ATA using a web browser. If you could be dealing with a SIP ALG problem (ISP's hub or gateway has SIP ALG on with no way for user to disable it or if you can't figure out how to disable SIP ALG in your own router), navigate to the Line used for FPL-->Proxy and Registration->-Proxy. Use "voip4.freephoneline.ca:6060" (without the quotation marks) to help avoid any potential SIP ALG bug (even if SIP Passthrough is disabled in stock Asus firmware, try voip4.freephoneline.ca:6060 if you're experiencing issues). You should be testing with voip4.freephoneline.ca:6060 if you're getting 1-way audio problems (one side hears audio, and the other side doesn't). Anyone can use voip4.freephoneline.ca:6060, even people who don't use Rogers. If you have 1-way audio problems, use it.


(Also remember to enter your SIP Username, SIP Password, and anything else from the PDF configuration guides on the Fongo forums; I’m just emphasizing important settings). They are located at viewforum.php?f=15.



14. Navigate to Voice tab-->Line tab (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

15. In your ATA, navigate to Voice tab-->Line tab (whichever you use for FPL)-->Proxy and Registration-->Register Expires needs to be 3600 seconds

save settings

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

Do this to avoid 15 minute call disconnections with Freephoneline.


17. Navigate to Voice tab-->SIP tab-->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

This helps to ensure data is sent back to your public IP address as opposed to your LAN IP address (192.100.1.x, for example). If Freephoneline were to send data to 192.100.1.x, it would never reach you. It needs to be sent to your WAN or public IP address first before your router can send or route data to your ATA's local IP address.

Enabling this setting helps to ensure one-way audio issues don't occur.


d) NAT Keep Alive Interval should be 20 seconds

e) Stun enable: No
f) Stun Test enable: No
g) Delete the STUN Server field if anything is listed


Using STUN creates an additional point of failure. When the STUN server goes down, so does your FPL service.

h) click "Save Settings" button


18. Navigate to Voice tab-->SIP tab-->SIP Timer Values (sec)
Reg Retry Intvl needs to be 120 seconds at least.

Click "Save Settings" button if changes were made

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


19. Save/submit settings. Turn off modem, router, and ATA. Turn on modem. Wait for it to be fully up and running first. Turn on router. Wait for router to be fully up and transmitting data first. Lastly, turn on ATA after everything else is up and running. That's always the proper device boot order. ATA should always be booted last in the chain. 1. Modem (wait) -->2. Router (wait)-->3. ATA

[Liptonbrisk]

20. Login at https://www.freephoneline.ca/showSipSettings.
SIP Status needs to indicate "Connected", and SIP User Agent should reflect the device you're using.

21. Login to your ATA. Navigate to Voice tab-->Info tab-->Line (used for FPL) Status (this is not a tab)-->Registration State
Ensure your Line is registered.

Unless you own two VoIP unlock keys, you can't register two ATA lines with your FPL account simultaneously.

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


22. Test incoming calls, preferably with a traditional landline or regular (non-VoIP) cellular number so that you don't have to spend time troubleshooting the other side of the call too. If incoming calls work at this point, you can stop at this step, but I suggest reading step 28 regardless.


23. If incoming calls are not working, login at https://www.freephoneline.ca/callLogs to confirm whether incoming calls are reaching your FPL account (they should be if incoming calls are reaching your FPL voicemail message). Only calls that are answered in some manner (including being answered by FPL's voicemail system) will appear in FPL's call list. Calls that aren't answered aren't listed. Duration is rounded to the next minute. Check the disconnect reason.

Incoming calls must reach FPL first in order for them to also reach your ATA.

24. To check to see whether the most recent incoming call is reaching your ATA, Login to it, and navigate to Voice tab-->Info tab-->Line (used for FPL) Status (this is not the Line tab; you should be on the Info tab still)-->Last Caller Number. You'll see the most recent incoming call number that reached your ATA. Unfortunately, you can also only see the most recent number (not past ones).

25. If incoming calls are not reaching your ATA but are reaching FPL’s voicemail system, attach the ATA directly to the ISP's (gateway or hub in bridge mode) modem via ethernet cable and detach everything else from the modem. Test briefly for incoming calls. If incoming calls suddenly start working properly, you've narrowed down the problem to something involving your router. Keep in mind your ATA will not be protected by your router's firewall during this step. After testing, revert back (reattach everything and disable bridge mode if you had to enable it during this step); that is, ensure your ATA is protected by a firewall again.


26. If you can't ping voip.freephoneline.ca, voip2.freephoneline.ca, or voip4.freephoneline.ca when connected to your ISP's hub, gateway, or modem, that may indicate a DNS problem with your ISP.

The simplest way to check for a DNS problem is to replace “voip4.freephoneline.ca:6060” with “163.213.111.21:6060” (without the quotation marks) for proxy in step 13 above. If your FPL line suddenly registers afterwards, you’re dealing with a DNS problem with the ATA. However, if the IP address for voip4.freephoneline.ca ever changes, FPL will stop working for you again.

You could try using https://www.quad9.net/ or any alternate DNS servers you want in your ATA. You may want to double check your DNS entries in your ATA, regardless, if FPL still isn’t registered at this point.



Ensure you can ping or reach FPL's SIP servers. If you can't, you (or your ATA) may be experiencing a DNS issue.

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

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

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

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

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

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

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

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

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

Bad jitter can produce broken-up audio or choppiness during phone calls. Severe jitter (or large ping spikes) can cause calls to drop (and incoming calls won’t arrive while the ping spike is occurring). Ping affects delay.

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

[Liptonbrisk]

27. If none of that helps, then, unfortunately, you're pretty much stuck with port forwarding your RTP (UDP) port range 16384-16482 from your router to your ATA. For reference, that range can be found under SIP-->RTP Parameters-->RTP Port Min and RTP Port Max. You're going to want to double check those numbers in your ATA. RTP packets need to reach your ATA in order for you get incoming audio. Quite often, when the one way audio issue occurs, this is the problem. RTP packets are not reaching your ATA. Ideally, one should not have to port forward in order to achieve proper two-way audio, since port forwarding does create security issues. Port forwarding should only be done when everything else fails.

Refer to the port forwarding section of your router manual to learn how to port forward to your ATA.

Especially don't block incoming UDP connections from 208.85.218.146 and 208.85.218.147 if you want to hear audio. Those are the RTP IPs used by FPL at the time this post was written.

If you have to also port forward the UDP port chosen in step 12 to hear audio, something is likely amiss with the router firmware version being used.




28. Lastly, 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) < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (or Reg Retry Intvl in your ATA)

“<“ 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, NAT Keep Alive Interval 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 (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
OpenWrt


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.


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.

[Liptonbrisk]

(continuing point 28 above)



a. Asuswrt-Merlin

i) Login to router's web UI
ii) Navigate to General-->Tools-->Other Settings
iii) Change "UDP Timeout: Assured" to 115 seconds if the failed registration retry timer in your ATA or IP Phone is 120 seconds for Freephoneline.
iv) Change "UDP Timeout: Unreplied" to 15 seconds if the NAT Keep-alive Interval in your ATA or IP Phone is 20 seconds for Freephoneline.
v) Click "Apply"


b. Ubiquiti

i) Login to Unifi Controller
ii) Navigate to Routing & Firewall-->Firewall-->Settings-->State Timeouts
iii) Change "UDP Stream" to 115 seconds if the failed registration retry timer in your ATA or IP Phone is 120 seconds for Freephoneline.
iv) Change "UDP Other" to 15 seconds if the NAT Keep-alive Interval in your ATA or IP Phone is 20 seconds for Freephoneline.
v) Click "Apply Settings" (Save changes made).


c. Mikrotik

i) Use Winbox: https://download2.mikrotik.com/routeros ... winbox.exe
To learn how to connect to your router, visit https://wiki.mikrotik.com/wiki/Manual:Winbox. Connect to your router and login.
ii) Enter "ip firewall connection tracking set udp-stream-timeout=115s" (without the quotation marks) if the failed registration retry timer in your ATA or IP Phone is 120 seconds for Freephoneline.
iii) Enter "ip firewall connection tracking set udp-timeout=15s" (without the quotation marks) if the NAT Keep-alive Interval in your ATA or IP Phone is 20 seconds for Freephoneline.

d. pfSense

UDP Multiple is UDP Assured
UDP Single is UDP Unreplied
Based on https://www.netgate.com/docs/pfsense/bo ... l-nat.html

i) Login to pfSense GUI.
ii) Navigate to System-->Advanced-->Firewall & NAT-->Firewall Optimization Options
Scroll down to "State Timeouts".
iii) Change UDP First (udp.first) to 115 seconds if the failed registration retry timer in your ATA or IP Phone in your ATA or IP Phone is 120 seconds for Freephoneline.
iv) Change UDP Single (udp.single) to 15 seconds if the NAT Keep-alive Interval in your ATA or IP Phone is 20 seconds for Freephoneline.
iv) Change UDP Multiple (udp.multiple) to 115 seconds if the failed registration retry timer in your ATA or IP Phone in your ATA or IP Phone is 120 seconds for Freephoneline.
v) Save settings


e. Tomato

i) Login to router's web UI
ii) Navigate to Avanced-->Conntrack / Netfilter-->UDP Timeout
iii) Change "UDP Timeout: Assured" to 115 seconds if the failed registration retry timer in your ATA or IP Phone is 120 seconds for Freephoneline.
iv) Change "UDP Timeout: Unreplied" to 15 seconds if the NAT Keep-alive Interval in your ATA or IP Phone is 20 seconds for Freephoneline.
v) Click "Save"

f. DD-WRT (I've never used DD-WRT and am not able to test whether this works)

i) Login to router web UI.
ii) Navigate to Administration-->Commands (use command shell). Or SSH/Telnet into your router.

Enter the following:
iii) "echo 115 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream" (without the quotation marks) if the failed registration retry timer in your ATA or IP Phone is 120 seconds for Freephoneline.
iv) "echo 15 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout" (without the quotation marks) if the NAT Keep-alive Interval in your ATA or IP Phone is 20 seconds for Freephoneline.

Note: It's possible these changes may not be saved in DD-WRT after rebooting.
https://www.linksysinfo.org/index.php?t ... ost-274528

To persist changes after reboot, you need to add your command to crontab or "startup scripts".
In my case I had to shove the damn assignment into crontab, because either the startup command fails sometimes or the value gets reset eventually

One of these two UDP settings is adjustable in DD-WRT web UI at Administration-->Management-->IP Filter Settings-->UDP Timeout (in seconds), but depending on the firmware version used, the single UDP timeout setting that is adjustable differs.


g. OpenWrt

Add the following (or change) to /etc/sysctl.conf

i) net.netfilter.nf_conntrack_udp_timeout_stream=115 if the failed registration retry timer in your ATA or IP Phone is 120 seconds for Freephoneline.
ii) net.netfilter.nf_conntrack_udp_timeout=15 if the NAT Keep-alive Interval in your ATA or IP Phone is 20 seconds for Freephoneline

Then run sysctl -p to load the new settings from the file.