Please read before posting

[Liptonbrisk]

Please visit https://status.fongo.com/ to ensure there are no reported issues.

- Always disable Follow Me while testing for problems related to incoming calls.

- If your ATA, IP Phone, or SIP app is connected to the internet using a third party VPN service, disable the VPN and test calls again if you're experiencing a problem.

- When you login your FPL (website) account online and see "Your SIP Settings", those recommended settings listed under that heading, unless you've manually entered them, don't reflect the settings presently entered in your ATA, IP Phone, or SIP app. Everyone sees the same settings, except SIP username and SIP password.

- Avoid using STUN. Using STUN introduces an additional point of failure. When the STUN server goes down, so does your FPL service.





Hi,

If you require troubleshooting assistance, please provide the following information in your post:

1) the brand and model of the modem provided by or used with your ISP,

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


Here are examples for disabling SIP ALG in gateways:


i) Hitron CGN3ACSMR and CODA-4582 series gateway modem/router combo from Rogers (and possibly other ISPs)


Open your web browser, and login at 192.168.0.1. Default username is cusadmin.
Select the “Basic” tab and disable “SIP ALG.” Click the “save changes” button.

ii) HItron CODA--4680 from Fizz and possibly other ISPs

- Open an Internet browser, and enter 192.168.0.1 in the address bar.
- Login
Username: cusadmin
Password: **enter your Wi-Fi password**
- Select Basic Settings
- Select Gateway Function tab
- Select Disabled for SIP ALG
- Save changes


iii) Arris XB6 from Rogers

Open your web browser, and login at 10.0.0.1
Navigate to Advanced-->Options.
Uncheck the SIP box.
Click "Apply".


iv) SageMcom F@st3896 V2 from Cogeco

Open your web browser, and login at 192.168.0.1
Default username is "admin"
Password is located on the sticker on the back of the gateway.
Navigate to Access Control-->Advanced Options.
Turn off SIP ALG.
Click "Apply".

Be careful not to reset the F@st3896 gateway. Otherwise, SIP ALG will turn back on.

v) Technicolor XB7 from Rogers

Note that there isn't an option to disable SIP ALG in a (Technicolor CGM4331COM) XB7 (Gen 2) gateway with this Rogers firmware version:
eMTA & DOCSIS Software Version: Prod_21.1_d31 & Prod_21.1
Software Image Name: CGM4331COM_5.2p12s1_PROD_sey

According to a tier 2 rep at Rogers, SIP ALG is enabled by default in XB7 with no way to disable it.
I'm not sure whether that representative is correct (the part about SIP ALG being enabled). However, the response from Rogers seems to coincide with what's happening in Xfinity/Comcast XB7's in the U.S.: https://forums.xfinity.com/conversation ... 66f45f8df1. If you are experiencing issues with a Rogers XB7, try voip4.freephoneline.ca:6060 along with a high, random local SIP Port (X_UserAgentPort should be a random port number between 30000 and 60000 with Obihai ATAs and Obihai IP Phones, and SIP Port, found by navigating to Voice-->whatever Line you're using for FPL-->SIP settings, should be a random number between 30000 and 60000 when using a Linksys/Cisco ATA).

vi) XB8 (Gen 3) has just been released from Rogers

I have no information yet concerning whether SIP ALG can be disabled in the XB8.
A tier 2 rep mentioned that Rogers is moving towards locking out administration setting changes for users, so it's doubtful that SIP ALG can be disabled in the XB8, but we'll have to wait to confirm.
His reasoning is that if you can't disable SIP ALG in XB7, it's unlikely XB8 will offer the capacity to disable SIP ALG either.

vii) Bell Giga Hub

Open your web browser, and login at 192.168.2.1 with your administration password.
Navigate to "Advanced tools & settings"-->"Networking"
Disable "SIP ALG".

viii) Nokia Beacon 6 (and possibly other models)

To connect to the web GUI while connected to the Nokia WiFi network:

In a web browser go to 192.168.18.1


To connect to the web GUI wile connected with the Beacon connected directly to a computer:

Connect the device's LAN port to your computer with an Ethernet cable
Set the configuration mode to manual and use the IP address 192.168.18.100 and subnet 255.255.255.0
Go to 192.168.18.1 on a web browser

"Select Security > DMZ and ALG from the top-level menu in the Ethernet Gateway window"
Uncheck "SIP" and save.

ix) Distributel's Deco X50 (and possibly other TP-Link Deco models)

a) Set up and use the TP-Link Deco app: :
- Download the app from the Apple App Store or Google Play Store.
-On your smartphone, connected to your Wi-Fi network, create a TP-Link login ID and password, and sign in.
Afterwards, you can use the same password to login using a web browser at tplinkdeco.net if you wish.

b) Launch the Deco App. Then navigate to More -> Advanced -> NAT Forwarding-> SIP ALG to disable the feature. Turn the SIP ALG slider to the off position.


x) Nettis 4422 modem from Carry Telecom

Q : DSL - My VoIP phone does not work with Netis 4422 modem.
A: Please download the newest Netis firmware file, and update the firmware file netis1228.img for your modem. The new firmware has been tested and working
with most of Voip phone providers



b) If you are also using your own separate router in addition to the one supplied by your ISP, then you should be enabling bridge mode instead in the modem/router combo, gateway, or hub issued by your ISP.

i) For Bell Hubs, visit http://forums.redflagdeals.com/please-s ... r-1993629/. 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. Giga Hub firmware needs to be version 1.15.1 or later for PPPoE Passthrough.

ii) For Distributel, login to your Distributel account to locate your PPPoE username and password. Distributel also requires VLAN (tagging) ID 40 with Priority 0, according to a rep. You will need to enter that information into your router for PPPoE passthrough. You can then attach your router to the Nokia ONT.

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

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




c) Afterwards, disable SIP ALG in your own separate router if you own one. Here is an example: https://kb.netgear.com/30796/How-do-I-d ... -interface.

When using official Asus router firmware, SIP ALG is called SIP Passthrough (Navigate to Advanced Settings–>WAN–>NAT Passthrough). Disable SIP Passthrough.

In Asuswrt-Merlin, also disable SIP Passthrough.


2) the brand and model of your router and firmware version used,

a) 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 Hubs, visit http://forums.redflagdeals.com/please-s ... r-1993629/.

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.
Giga Hub firmware needs to be version 1.15.1 or later for PPPoE Passthrough.

If you're using Bell's Giga Hub and don't have the option to enable PPPoE passthrough in your own router, then,(and only if you can't do PPPoE in your own router), add your router's MAC address to Giga Hub's DMZ:

- Enter 192.168.2.1 in a web browser, and log in using the administration password.
- Navigate to “Advanced Tools and Settings”-->“DMZ”.
- Enable “DMZ”.
- Enable/check “Advanced DMZ”.
- For “Device”, enter the MAC address for your eero router (it should be listed). If it's not listed, refer to your router's documentation. MAC addresses appear in this format: 2C:8B:6G:6E:F3:C9 (for example).



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.


b) If you are also using your own separate router in addition to the one supplied by your ISP, then disable SIP ALG in your own router. Here is an example:
https://www.obitalk.com/info/faq/sip-alg/disable-alg.

i) Asus routers

- When using official Asus router firmware, SIP ALG is called SIP Passthrough (Navigate to Advanced Settings–>WAN–>NAT Passthrough). Disable SIP Passthrough.

- When using Asuswrt-Merlin firmware, also disable SIP Passthrough.

- For Asus router users, 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 a SIP device (ATA, IP Phone) attempting to register with 10.0.0.1
when it's booted before the modem is fully up and running first (after a power outage, for example).

- A number of people have been trying to eliminate Bell Hubs from their setups completely by removing
the module inside it and using a TP-LINK MC220L or something else. At the time of this post being
written, NAT acceleration must be disabled in this setup in order for SIP services, including
Freephoneline, to work properly. In your router, navigate to Advanced Settings-->LAN-->Switch
Control-->NAT Acceleration. Select "disable." Click "apply."Then reboot your modem, router (wait for
Wi-Fi SSIDs to populate first before rebooting ATA), and your ATA or IP Phone, in that order.
If you do require NAT Acceleration to be enabled, don’t use VLAN with Asus routers.


ii) Ubiquiti routers

If you're an Ubiquiti router user, disable jumbo frames.




3) the brand and model of your ATA, IP Phone, or smartphone (if you're using a SIP app or Freephoneline's desktop app, specify the name of the app and version) and firmware version used,

4) the proxy server your ATA or IP Phone is using (for example, voip.freephoneline.ca, voip2.freephoneline.ca, or voip4.freephoneline.ca:6060),

5) the registration status in your ATA or IP Phone and also "SIP status" after logging in at https://www.freephoneline.ca/showSipSettings

Please note that if "SIP User Agent" reflects a different device than the one you're using, someone else is likely using your Freephoneline VoIP unlock key.
Only one registration is permitted at any time per Freephoneline VoIP unlock key. Registration is a requirement for incoming calls but not for outgoing calls.

6) If applicable, please also login at https://www.freephoneline.ca/callLogs and provide the date and time of the failed call and, especially, the "Disconnect reason".
Check and confirm that the "To" and "From" fields represent numbers you expect.

7) Similarly (with respect to #6), if your ATA or IP Phone has call logs, please check your call log history to see whether any useful information, such as a 3 digit SIP error code is listed.
If so, please provide that information.

8) If you heard an error message, especially a 3 digit SIP error code, please provide it.

9) This is always proper device reboot order:

A.Turn off modem, router and ATA (or IP Phone or close SIP App).

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 (or IP Phone or open SIP app) only after the router is fully up and running.

The SIP device (ATA, IP Phone, or SIP app) should be the last device powered on in the device chain.



The first 3 pieces of information requested are often important.

Thank you

[Liptonbrisk]

(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://www.ietf.org/rfc/rfc3489.txt (scroll down to "NAT Variations").
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.

Also, scroll all the way down to the final post in this thread.



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 Notify Keep Alive Interval) < UDP Assured Timeout or UDP Stream (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_KeepAlivesExpires (SIP Notify Keep Alive Interval) is supposed to be 20 with FPL.



I asked an A.I. to present an analogy to help people understand. I'm not sure that it helps, but here it is:

The Goal:

These timing rules help your internet phone work reliably by coordinating your router and your phone adapter. We'll use the analogy of keeping Your Pet (the connection) ready for Your Friend (the phone company) based on Your House Rules (the router's settings), while also showing the technical setting names.

The Formula / The Timing Rules (Analogy + Technical Names + Example Times):

Your Quick 'Give Up' Time (Router UDP Unreplied Timeout) (15s) < Your 'Stay Alert!' Command (Phone Adapter NAT Keep-alive Interval) (20s) <
Pet's 'Wanders Off/Falls Asleep' Time (Router UDP Assured Timeout) (115s) < Your 'Start Fresh Search' Wait (Phone Adapter SIP Reg. Retry Wait Time) (120s)

(Remember, "<" means the time on the left must be shorter than the time on the right.)

Explaining Each Part and Why It's Necessary:

Why Your Quick 'Give Up' Time (Router UDP Unreplied Timeout = 15s) MUST BE LESS THAN Your 'Stay Alert!' Command (Adapter NAT Keep-alive Interval = 20s):

Analogy: If you first call your pet but it completely ignores you, the House Rules (Router) make you stop that specific attempt very quickly (after 15 seconds, the UDP Unreplied Timeout).

Necessity: This needs to happen before your regular "Stay Alert!" command (the phone adapter's 20s NAT Keep-alive Interval) is due. This quickly clears failed connection states from the router's memory so they don't interfere with the keep-alive process for your working connection.

Why Your 'Stay Alert!' Command (Adapter NAT Keep-alive Interval = 20s) MUST BE LESS THAN Pet's 'Wanders Off/Falls Asleep' Time (Router UDP Assured Timeout = 115s):

Analogy: You keep your pet ready by giving it the "Stay Alert!" command frequently (every 20 seconds, your adapter's NAT Keep-alive Interval). The House Rule (Router) only considers the pet "asleep" if it gets no attention for a much longer time (115 seconds, the UDP Assured Timeout).

Necessity: Your frequent keep-alive commands (every 20s) must arrive more often than the router's inactivity timeout (115s). This guarantees your commands reset the router's timer, keeping the connection state active and the path open so Your Friend can interact (you can receive calls).

Why Pet's 'Wanders Off/Falls Asleep' Time (Router UDP Assured Timeout = 115s) MUST BE LESS THAN Your 'Start Fresh Search' Wait (Adapter SIP Reg. Retry Wait Time = 120s):

Analogy: If you stop giving commands (connection fails) and the pet does fall asleep according to the House Rules (after 115s of no commands, the router's UDP Assured Timeout expires), you have a rule to wait until 120s (your adapter's SIP Reg. Retry Wait Time) before starting the whole "find the pet" routine again (a full reconnect).

Necessity: The pet needs to be considered fully "asleep" (the router must close the old connection state after 115s) before you start the big wake-up process (the adapter attempts re-registration at 120s). This ensures the adapter tries to establish a completely fresh connection state instead of potentially trying to reuse the old one that the router just closed, leading to a cleaner recovery.

In Conclusion:

Each timing rule and its place in the sequence is necessary. By setting the router's UDP Unreplied and UDP Assured timeouts correctly in relation to the phone adapter's NAT Keep-alive Interval and SIP Registration Retry Wait Time, you create a system that handles failed attempts efficiently, keeps active connections alive reliably, and recovers cleanly after disruptions. This coordination is key to stable internet phone service.

Here's another analogy:

Yes, while different analogies work for different people, I do think the "Temporary Access Pass" (or Security Desk) analogy is generally the most apt and accurate for explaining these concepts to adult newcomers compared to the pet analogy. It maps more directly to the idea of temporary permissions (NAT states) managed by a system (the router/firewall) with specific time-based rules for validation and expiry.

Here's the explanation using that analogy, presented in the same detailed manner as the previous response:

The Goal:

This formula (Unreplied < Keep-Alive < Assured < Retry) provides essential timing rules to make your internet phone service reliable. It coordinates the timers on your router (Security Desk) and your phone adapter (You) to correctly manage your connection (Access Pass) to the phone company server (Someone Specific inside).

The Analogy Setup:

Your Router: The Security Desk at an event/building, managing access.
Your Phone Adapter: You, needing access.
The Internet Connection State: A temporary Access Pass issued by Security.
The Phone Company Server: Someone Specific inside the event you need to communicate with.

The Formula / The Timing Rules (Security Desk Analogy + Technical Names + Example Times):

Security's Failed Request Timeout (Router UDP Unreplied Timeout) (15s) < Your Pass Validation Interval (Phone Adapter NAT Keep-alive Interval) (20s) < Security's Inactivity Timeout (Router UDP Assured Timeout) (115s) < Your Re-Application Wait Time (Phone Adapter SIP Reg. Retry Wait Time) (120s)

(Remember, "<" means the time on the left must be shorter than the time on the right.)

Why Each Step in the Formula is Necessary:

1) Why Security's Failed Request Timeout (Router UDP Unreplied Timeout = 15s) MUST BE LESS THAN Your Pass Validation Interval (Adapter NAT Keep-alive Interval = 20s):

Analogy Explanation: If you ask Security for an Access Pass but the person inside doesn't quickly confirm, Security cancels that request very fast (after 15 seconds, the UDP Unreplied Timeout).

Necessity: This quick cancellation needs to happen before your next regular Pass Validation check (every 20 seconds, the NAT Keep-alive Interval) might occur for other active passes. This prevents failed connection attempts from cluttering the router's state table and potentially interfering with the keep-alive process for established connections. It cleans up errors efficiently.

2) Why Your Pass Validation Interval (Adapter NAT Keep-alive Interval = 20s) MUST BE LESS THAN Security's Inactivity Timeout (Router UDP Assured Timeout = 115s):

Analogy Explanation: You keep your active Access Pass valid by showing it to Security frequently (every 20 seconds, your adapter's NAT Keep-alive Interval). Security only cancels an active pass due to inactivity if they don't see it validated for a much longer time (115 seconds, the UDP Assured Timeout).

Necessity: Your frequent validation (keep-alive signal) must occur more often than Security's deadline for assuming inactivity. This guarantees that your keep-alives reset the router's UDP Assured Timeout timer, keeping the NAT state active and the communication path open so Someone Specific inside can reach you (you can receive incoming calls).

3) Why Security's Inactivity Timeout (Router UDP Assured Timeout = 115s) MUST BE LESS THAN Your Re-Application Wait Time (Adapter SIP Reg. Retry Wait Time = 120s):

Analogy Explanation: If your connection fails and you stop validating your pass, Security will cancel the pass after 115 seconds of inactivity (the UDP Assured Timeout expires). You have a rule that you must wait until 120 seconds (your adapter's SIP Reg. Retry Wait Time) before going back to apply for a completely new pass.

Necessity: Security (the router) needs to have fully closed the old, inactive connection state (at 115s) before you (the phone adapter) attempt a full reconnection/re-registration (at 120s). This forces the adapter to establish a fresh connection state, preventing potential errors or conflicts that could arise from trying to use the state that the router just invalidated. It ensures a clean recovery process.

In Conclusion:

Each part of this timing formula is necessary for robust internet phone operation over NAT. Setting the router's UDP Unreplied and UDP Assured timeouts correctly relative to the phone adapter's NAT Keep-alive Interval and SIP Registration Retry Wait Time handles initial failures, maintains active connections, and ensures clean recovery, preventing many common VoIP frustrations.

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-AX86U at this time), 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.



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.

[Liptonbrisk]

(continuing point D 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.


-----
Guides you should be following are located at viewforum.php?f=15.

Lastly, VoIP Unlock key Credentials can be found at https://support.freephoneline.ca/hc/en- ... redentials.

[Liptonbrisk]

Did I mention SIP ALG might cause problems? How about a security issue?

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.

Note that numerous browsers are now implementing mitigation methods by blocking certain ports used by these protocols.

RMerlin is the developer of Asuswrt-Merlin firmware. He is referring to settings in Merlin router firmware.

NAT slipstreaming involving ALGs, including SIP ALG, doesn't just apply to Asuswrt-Merlin, of course: https://samy.pl/slipstream/. It's a potential issue for everyone.