For Obihai devices with incoming call issues/1-way audio

[Liptonbrisk]

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

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

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

D. Avoid using STUN. Using STUN introduces an additional point of failure. When the STUN server goes down, so does your FPL service.
i) This setting can be found by logging into your Obihai ATA or IP Phone and navigating to Service Providers-->ITSP Profile used for Freephoneline-->General
ii) Uncheck STUNEnable
iii) Click "Submit", and reboot your Obihai ATA or IP Phone if changes were made.

E. 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 SP on an Obihai ATA counts as one registration. A SIP app is another.

F. 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 the problem with Obihai devices attempting to register with 10.0.0.1
when they are booted before the ISP's modem is fully and running first (after a power outage, for example).




Follow the steps, step by step, down the list, please. Some Obihai devices may have menu locations that differ slightly, but they should be very similar. These steps were intended mostly for Obihai OBi2xx/3xx/2xxx series ATA and IP Phones, but they may also apply to other OBi devices.

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. The Obitalk web portal (http://www.obitalk.com) can no longer be used. Dial ***1. Enter the IP address you hear into a web browser. Login. Default username and password is "admin" (without the quotation marks). Navigate to System Management-->Auto Provisioning-->OBiTalk Provisioning-->select Disabled for the method.

Save. Reboot device. (The original purpose was that afterwards, obitalk.com wouldn't overwrite whatever changes you make via the device's interface/web UI).



10. a) If you have an OBi202 or OBi302, ensure that AccessFromWAN is enabled in the ATA in order to log into it via WebUI.

Dial ***0 from the phone connected to the OBi202/OBi302
- Enter 30#
- Press 1 to Enter a New Value
- Press 1# to Enable
- Press 1 to Save

b) Now dial ***1. Enter the IP address you hear into a web browser if you want to use your Obihai device's web interface instead of Obitalk.com. Login. Default username and password are “admin” without the quotation marks.

11. Navigate to Voice Services-->SP (used for FPL) Service-->Calling Features

a) Ensure DoNotDisturbEnable is unchecked
b) Ensure CallForwardUnconditionalEnable is unchecked while troubleshooting
c) Ensure CallForwardOnBusyEnable is unchecked while troubleshooting
d) Ensure CallForwardOnNoAnswerEnable is unchecked while troubleshooting
e) Ensure AnonymousCallBlockEnable is unchecked

Submit/Save changes if any were made.

12. Navigate to Voice Services-->SP used for FPL Service-->_UserAgentPort

a) X_UserAgentPort should be a random UDP port number between 30000 and 60000. Just pick a port number in that range.
If you already have a random number in that range, simply enter a new one in that range.
By using a high random port you help to thwart SIP scanners/hackers.

Do not use the same X_UserAgentPort for any other SP. Pick a different X_UserAgentPort in the same range for other SPs.

Never use UDP 5060 for X_UserAgentPort.


b) Disable/uncheck X_AcceptSipFromRegistrarOnly if it is enabled in your Obihai device. That setting can be found by navigating to Voice Services-->SP Service (used for FPL)-->X_AcceptSipFromRegistrarOnly.

If that setting is enabled, incoming calls from Fongo Mobile and/or Fongo Home Phone to your FPL number may drop straight to voicemail when registered with voip.freephoneline.ca.


c) Submit/save settings.

d) Reboot ATA.

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


13. Login to ATA or Obitalk again (whichever method you use).



A. For OBi200/300/2182 or Obihai devices without a built-in router, navigate to Router Configuration-->WAN Settings-->Local DNS Records

B. For OBi202/302 or Obihai devices with a built-in router, navigate to System Management–>WAN Settings-->Local DNS Records



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), then
change line 1 to

Code: Select all

voip4.freephoneline.ca={voip.freephoneline.ca:5060,3},{voip2.freephoneline.ca:5060,2},{voip4.freephoneline.ca:6060,1}

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.

(don’t enter “code: Select all”)

submit/save settings

voip4.freephoneline.ca:6060 is used to help circumvent SIP ALG or when an ISP prevents you from using UDP 5060 properly.

In this example voip4.freephoneline.ca:6060 (1) is being given priority. If registration fails on voip4.freephoneline.ca:6060 (1), then the Obihai device will attempt to register with voip2.freephoneline.ca (2), and if the device fails to register on that server, it finally attempts to register with voip.freephoneline.ca (3).


14. Navigate to Service Providers-->ITSP Profile used for FPL-->SIP->

A. If you choose to follow the example listed in step 13, where voip4.freephoneline.ca={voip.freephoneline.ca:5060,3},{voip2.freephoneline.ca:5060,2},{voip4.freephoneline.ca:6060,1}, then

i. change ProxyServer to voip4.freephoneline.ca
ii. change ProxyServerPort to 6060

I strongly suggest trying voip4.freephoneline.ca:6060 if you're experiencing 1-way audio issues. In that case, don't use examples from B and C directly below this.


You can choose alternatives if you're not dealing with a SIP ALG issue. These are a couple of examples:

B. If, for example, you prefer to register primarily with voip2.freephoneline.ca instead of voip4.freephoneline.ca:6060, then use voip2.freephoneline.ca={voip.freephoneline.ca:5060,3},{voip2.freephoneline.ca:5060,1},{voip4.freephoneline.ca:6060,2} in step 13 instead.

Afterwards,

i. change ProxyServer to voip2.freephoneline.ca
ii. change ProxyServerPort to 5060

Here you're choosing to register with voip2.freephoneline.ca:5060 (1) first, then (2) voip4.freephoneline.ca (if voip2.freephoneline.ca fails registration), and finally (3) voip.freephoneline.ca (if both voip2.freephoneline.ca:5060 and voip4.freephoneline.ca:6060 fail registration).

C. If, for example, you prefer to register primarily with voip.freephoneline.ca instead of voip4.freephoneline.ca:6060, then use voip.freephoneline.ca={voip.freephoneline.ca:5060,1},{voip2.freephoneline.ca:5060,2},{voip4.freephoneline.ca:6060,3} in step 13 instead.

Afterwards,

i. change ProxyServer to voip.freephoneline.ca
ii. change ProxyServerPort to 5060

Here you're choosing to register with voip.freephoneline.ca:5060 (1) first, then (2) voip2.freephoneline.ca (if voip.freephoneline.ca fails registration), and finally (3) voip4.freephoneline.ca (if both voip.freephoneline.ca:5060 and voip2.freephoneline.ca:6060 fail registration).

Also remember to enter your SIP Username, SIP Password, and anything else from the PDF configuration guide on the Fongo forums; I’m just emphasizing important settings in this thread. The PDF guide is located at viewtopic.php?f=15&t=18805#p73839 (bottom of the first post).



D. Ensure RegistrationPeriod is 3600 seconds.

E. RegisterExpires should be 3600 seconds

As far as I can tell, that setting doesn't do anything though.

"Register Expires header value in seconds (not used at the moment)."
https://www.obitalk.com/info/documents/ ... nGuide.pdf (page 102)

F. X_RegistrationMargin can be left at default (blank)

"Number of seconds before current registration expires that the OBi should re- Register. If value is 0
or blank, OBi will determine a proper margin on its own. Note: Option not available on OBi100/OBi110"

At defaults, Obihai devices will attempt to register again after 3000 seconds (50 minutes), when RegistrationPeriod is 3600 seconds.

X_RegistrationMargin is used to specify when the Obihai device makes another registration attempt before registration expires in order to help ensure the Obihai device
never completely loses registration.


G. Ensure RegisterRetryInterval is 120 seconds.

H. Ensure X_DiscoverPublicAddress is enabled (it is by default)

I. Enable/check X_ProxyServerRedundancy (you will have to uncheck default box)

This enables server failover as described above.

J. Enable X_UsePublicAddressInVia (you will have to uncheck default box). OBi1xx series ATAs don't have this setting, I think.

This sends your public IP address (as determined by your Obihai device) in the VIA header that’s sent to Freephoneline’s server. 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 the data to the local IP address of your Obihai device.

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

K. Set X_CheckPrimaryFallbackInterval to 7200 seconds (you will have to uncheck the default box)

"Interval in seconds at which the device should check the primary fallback list of candidate servers."

This setting makes your Obihai device check every 2 hours to see whether the primary server can be used to register successfully (as specified in step 13).
If you've been temporarily IP banned by a specific proxy server, then 7200 seconds should be enough time for the ban to clear. In the past, Fongo Support instructed to turn off devices for
2 hours when that happened.

L. Disable/uncheck X_Use302ToCallForward (FPL doesn't permit 302 to Call Forward)

When X_Use302ToCallForward is enabled for FPL, forwarded calls drop to FPL's voicemail system. Disable X_Use302ToCallForward.

submit/save settings

15. Navigate to Voice Services-->SP used for FPL

i) X_KeepAliveEnable should be Checked/enabled
ii) X_KeepAliveExpires should be 20 seconds
iii) X_KeepAliveMsgType should be "notify" (OBi1xx series doesn't have the option to set a custom message here, I think)

submit/save settings

16. Turn off modem, router, and Obihai device. 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 Obihai device after everything else is up and running. That's always the proper device boot order. Obihai device should always be booted last in the chain. 1. Modem (wait) -->2. Router (wait)-->3. SIP device

[Liptonbrisk]

17. Login at https://www.freephoneline.ca/showSipSettings.

SIP Status needs to indicate "Connected", and SIP User Agent should reflect the device you're using.

18. Login to Obihai device. Check registration status for FPL in the Obihai device (Navigate to Status-->System Status-->SP used for FPL Service Status-->Status).

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

When there are multiple devices/softphones/SPs (on an ATA/IP Phone) using the same FPL account, only the most recent registration is valid. The previously registered device (or SP, 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 SP on your Obihai device. 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 SP on an Obihai device is one registration. A SIP app is another.


19. 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, you can stop at this step, but I suggest reading step 25 regardless.


20. If incoming calls are not working at this point, 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 on incoming calls). 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 Obihai device.

21. In your Obihai device (not at Obitalk), navigate to status-->call history to see whether calls are reaching your Obihai SIP device.

22. If incoming calls are not reaching your Obihai device but are reaching FPL’s voicemail system, attach the OBi device directly to the ISP's (gateway or hub in bridge mode) modem via ethernet cable. 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 Obihai device will not be protected by your router's firewall during this step. After testing, revert back; that is, ensure your Obihai device is protected by a firewall again.


23. 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 ProxyServer in step 14 above. If your FPL line suddenly registers afterwards, you’re dealing with a DNS problem with the Obihai device. 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 Obihai device. You may want to double check your DNS entries in your Obihai device, 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 Obihai device) 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 300 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; the incoming calls will go to FPL’s voicemail system instead). 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.


24. If none of that helps, then, unfortunately, you're pretty much stuck with port forwarding your RTP (UDP) port range 16660-16798 from your router to your Obihai device. For reference, that range can be found under ITSP Profile (FPL)-->RTP. Then look at LocalPortMin and LocalPortMax. RTP packets need to reach your SIP device (OBi) 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 Obihai device. 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 Obihai device. If you're only using the router given to you by your ISP, call your ISP.

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 find you also need to port forward X_UserAgentPort (refer to step 12 above) in order to hear audio, then something is likely amiss (bug) with the router firmware version being used.




25. Lastly, thanks to Mango, many of us now understand that in order for SIP devices (ATA and IP Phones) 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) < X_KeepAliveExpires (in your Obihai device) < UDP Assured Timeout (in your router) < RegisterRetryInterval (in Obihai device))

“<“ 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 X_KeepAliveExpires is greater than UDP Assured Timeout (often 180 by default in consumer routers): the NAT hole will close due to the Obihai device not communicating frequently enough with the SIP server. In turn, incoming calls may, intermittently, not reach the Obihai device. Again, X_KeepAlivesExpires 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 X_KeepAliveExpires interval for FPL is 20. RegisterRetryInterval is 120. I use 15 for UDP Unreplied Timeout and 115 for UDP Assured Timeout.

[Liptonbrisk]

(continuing point 25 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 (RegisterRetryInterval) 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 (X_KeepAliveExpires) 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 (RegisterRetryInterval) in your ATA or IP Phone is 120 seconds for Freephoneline.
iv) Change "UDP Other" to 15 seconds if the NAT Keep-alive Interval (X_KeepAliveExpires) 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 (RegisterRetryInterval) 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 (X_KeepAliveExpires) 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 (RegisterRetryInterval) 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 (X_KeepAliveExpires) 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 (RegisterRetryInterval) 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 (RegisterRetryInterval) 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 (X_KeepAliveExpires) 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 (RegisterRetryInterval) 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 (X_KeepAliveExpires) 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 (RegisterRetryInterval) 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 (X_KeepAliveExpires) in your ATA or IP Phone is 20 seconds for Freephoneline

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

You can check Obihai ATA light patterns at https://www.obitalk.com/info/faq/Troubl ... t-meanings and at https://www.obitalk.com/info/support/troubleshooting.

By the way, I'm not sure what will happen to Obitalk.com after 2023: https://www.obitalk.com/info/products/obi212.
You might want to get used to not being able to use it.

[Liptonbrisk]

Obitalk website is dead after October 31, 2024: https://support.hp.com/ca-en/document/i ... 1049883-16.
Don't use Obitalk.com anymore for Freephoneline.