JOHN-SBK wrote:
It look like disabling SIP ALG may have fixed it.
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, people 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.
It's late and I can't call anyone to test it
Visit
http://thetestcall.blogspot.com/Dial the 416 or 250 number, and then press #. Then press 4 for music on hold. After one song finishes, press the # again to play the next song.
but I called my cell phone and made it to 16 minutes. Will test longer calls in the next few days.
I'm trying to figure out if the problem involves a specific server, but because I can't reproduce the issue it's hard for me to test.
I tried a smartphone SIP app called Acrobits Groundwire using cellular data a little while ago, which completely bypasses my router. And I tried voip.freephoneline.ca on Groundwire because I figured most people are using voip.freephoneline.ca. I was able to call a Telus mobile number for 17 minutes without any problems. So, I hung up.
The 60+ minute call today was using voip2.freephoneline.ca on an OBi202 ATA. My router firmware uses Asuswrt-Merlin. The SIP ALG feature in Asus routers is called SIP Passthrough. In Merlin firmware, my SIP Passthrough setting is set to "Enabled + NAT helper", which works fine with Freephoneline.
I'd need to look at SIP traces (logs) where someone is having the problem and also check that person's firewall logs. That's a lot of work for me that I just don't have time for.
There is probably something a little different in the way the new FPL hardware and/or configuration works
I suspect something has changed, but the change doesn't appear to be affecting me at the moment.
For reference, my ATA is a Linksys PAP2-NA with firmware 3.1.22(LS), and my router is a Netgear WNR3500L with the latest firmware 1.2.2.48.
What brand and model modem are you using? If it's a modem/router combo or gateway, ensure that it's in bridge mode.
Do the following steps, slowly and carefully, step by step:
1. Before beginning the steps below make sure whatever modem/router combo your ISP gave you is in bridge mode if you are using your own router. Call/contact your ISP if you have to. For Bell Hubs, visit
http://forums.redflagdeals.com/please-s ... r-1993629/2. Disable DMZ and all port forwarding in your router. Port forwarding is a security risk.
3. In your PAP2T, Navigate to Line 1 (or whatever you're using for FPL)-->SIP settings, and change SIP Port to a random number between 30000 and 60000. Do this for security reasons. Also, this step may help to temporarily address a corrupted NAT association that's developed between a router and ATA.
4. In your PAP2T, Navigate to the 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 RTP (the streaming audio packets sent by FPL's server) packets are sent to your public WAN IP address as opposed to your LAN IP address (nowhere/outer space) .
d) NAT Keep Alive Intvl should be 20
(discussed earlier)
5. Navigate to Line (whatever you use for FPL)-->NAT settings
a) NAT Mapping enabled --> yes
b) NAT Keep alive enabled --> yes
6. Navigate to Voice-->SIP-->SIP Timer Values (sec)
a. Reg Retry Intvl should be 120 seconds
https://support.freephoneline.ca/hc/en- ... redentialsThis step is not related to your problem, but old guides didn't include this setting.
You may not be able to do this step:
7. 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 < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (Reg Retry Intvl)
“<“ 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, 17, 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, third party firmware for Asus routers, does offer easy access to these two
settings, which are found under General–>Tools-->Other settings. In part, for this reason, I tend to use Asus routers
that work with Asuswrt-Merlin. However, my understanding is that third party Tomato firmware has these two settings
as well. So if your router supports Tomato firmware, that may be another option. I will not be held responsible for failed firmware updates.
Apparently, Mikrotik routers also allow users to change both Assured and Unreplied UDP timeout settings:
https://forums.redflagdeals.com/recomme ... 2115672/2/.
The keep alive interval for FPL is 20. The SIP Registration Failure Retry Wait Time is 120. I use 17 for UDP
Unreplied Timeout and 117 for UDP Assured Timeout.
8. After changing and savings settings, reboot your devices. Proper device reboot order is always modem (wait for it to be fully up and running)-->router (wait for Wi-Fi SSIDs to populate and broadcast first)-->ATA
in that order.
Then test another call.