Unable to login to server

[mharvey500]

Hi, I am getting unable to login to server about every day or so in Registration State. I have Thomson cable modem, a router with ports forwarded to the ATA and DMZ to the ATA, and a Linksys PAP2T ATA.
Could this be due to the modem DHCP renewal? Power cycling the ATA does not help, but toggling the proxy between voip.freephoneline.ca and voip2.freephoneline.ca does work.

[Liptonbrisk]

Hi, I am getting unable to login to server about every day or so in Registration State . . . toggling the proxy between voip.freephoneline.ca and voip2.freephoneline.ca does work

Provide the full error message, please.

If registration status is failing, keep in mind that if your ATA attempts to register more than 5 times in 5 minutes, you'll be temporarily IP banned by the specific Freephoneline SIP server your ATA was attempting to register with. At that point, switching to a different FPL SIP server works, until you're temporarily banned on that server too.

These registration timers are very important:

http://support.freephoneline.ca/hc/en-u ... redentials (official FPL settings)
i) Registration Interval:
3600 seconds (1 hour)

ii) Registration Expiry:
3600 seconds (1 hour)

iii) Failed Registration Re-Try Interval:
120 seconds

Double check your settings in your ATA.

1. Navigate to SIP-->SIP Timer Values

a) Change Reg Retry Intvl to 120
b) Change Reg Retry Long Intvl to 120


2. Navigate to RTP Parameters

a) ensure RTP Packet Size is 0.02
b) ensure NAT Keep Alive Intvl is 20

3. Navigate to Line (FPL)-->NAT Settings

a) ensure NAT Keep Alive Enable is Yes
b) ensure NAT Keep Alive Msg is $NOTIFY

4. Navigate to Line (FPL)-->Proxy and Registration

a) ensure Register Expires is 3600


Sometimes the registration issue can also occur if a corrupted NAT connection has developed between the router and the ATA.
In some cases, changing local SIP port is the most effective way of, temporarily, fixing this.The problem can arise due to the router's UDP timeout being in excess of the ATA's Failure Retry timer.
When the problem is occurring, in your PAP2T, Navigate to Line 1 (or whatever you're using for FPL)-->SIP settings, change SIP Port to a random number between 30000 and 60000. If the problem disappears,
the issue was the router's UDP timeout being in excess of the ATA's Failure Retry timer.

Using a high random local SIP port also helps to thwart SIP scanners and may help circumvent faulty SIP ALG features in routers.

[Liptonbrisk]

a router with ports forwarded to the ATA and DMZ to the ATA, and a Linksys PAP2T ATA.

Port fowarding and, in particular, using DMZ are about the worst possible things you could be doing. Those are huge security risks. You risk being hacked and also are exposing your ATA to SIP Scanners that are looking for open ports to allow crackers access to your ATA and devices on your LAN. Typically, the only reason why someone would be port forwarding to using DMZ is because he or she encountered one-way audio issues.


Taken from http://forums.redflagdeals.com/freephon ... ip-821229/

i. 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. If your ISP only gave you a modem, you don't need to enable bridge mode.

ii. Disable DMZ and all port forwarding in your router. Port forwarding is a security risk.


1) Make sure your ringer is enabled on your phone.

2) Log into your PAP2T

A. Under User 1 and User 2 tabs (both of these)

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)

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.

3. In your PAP2T, Navigate to Line 1 (or whatever you're using for FPL)-->SIP settings, change SIP Port to a random number between 30000 and 60000


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

5. Retest
When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.

Then retest by calling your FPL phone number. If the problem is solved, don't continue.

6. If there are still problems, try disabling the SIP ALG feature in whatever router or modem/router combo it is that you're using:
http://www.obihai.com/faq/sip-alg/calling-out
I'm of the opinion Apple routers don't offer this feature, but you might as well check. If you manage to disable SIP ALG in the router, then retest.

DLINK router users may need to log into the admin page of their router, click the "Advanced" tab and then "Firewall Settings",
navigate to "Application Level Gateway (ALG) Configuration", and uncheck SIP: http://www.support.dlink.com/emulators/ ... dv_dmz.htm

If you received a modem/router combo, from your ISP ask your ISP. It is typically better to stick the modem/router combo from your ISP in bridge mode and use an external router.

See here for an example on how to disable SIP ALG in a router: http://www.obihai.com/faq/sip-alg/disable-alg



Save settings.
Turn off both router and ATA. Turn on router. Wait for router to be fully up and transmitting data. Turn on ATA.
Then retest by calling your FPL phone number. If the problem is solved, don't continue.

7. Try Proxyserver voip4.freephoneline.ca:6060
visit http://forum.fongo.com/viewtopic.php?f=15&t=16294 (look at page 6 of the .pdf)

Retest. When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.

Then retest by calling your FPL phone number. If the problem is solved, don't continue.

voip4.freephoneline.ca:6060 is a SIP server whose purpose is to help those with SIP ALG issues (can't disable it in the user's router, for example).



8. Try this at your own risk: use voip3.freephoneline.ca as the proxyserver

voip3.freephoneline.ca is intended for testing purposes only--or for those who receive explicit permission to use it. Using it for an extended period may get your account banned. However, if using voip3.freephoneline.ca does work, you should open up a ticket with support and let them know that you can't get two-way audio any other way: https://support.fongo.com/anonymous_requests/new. Ask for a "forced registration."

If no responds to your support ticket, provide the ticket number in a private message to Fongo Support: http://forum.fongo.com/ucp.php?i=pm&mode=compose&u=7852

FPL configures its SIP servers differently than many other VoIP providers.
voip3.freephoneline.ca conforms more to the norm. But using it without permission can get your account banned.
If you'd like to avoid getting your account banned, use Proxyserver voip.freephoneline.ca, voip2.freephoneline.ca, or voip4.freephoneline.ca:6060 instead and skip to step #10.

9. Retest. When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.

Then retest by calling your FPL phone number.

10. 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. If a router was given to you by your ISP, call your ISP.

11. Retest. When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.


Then retest by calling your FPL phone number.

12. If all else fails open a support ticket at https://support.fongo.com/anonymous_requests/new to see what they say. Request a "forced registration."
If no responds to your support ticket, provide the ticket number in a private message to Fongo Support: http://forum.fongo.com/ucp.php?i=pm&mode=compose&u=7852

When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.

[mharvey500]

a) Change Reg Retry Intvl to 120
b) Change Reg Retry Long Intvl to 120

... change SIP Port to a random number between 30000 and 60000. If the problem disappears,
the issue was the router's UDP timeout being in excess of the ATA's Failure Retry timer.

Hi and thanks for the help. The correct error message is "Can't connect to login server". So I made the above changes, after changing Reg Retry Intvl and Reg Retry Long Intvl, the behaviour stayed the same. Within a day I would get the error.
Then I tried a random SIP Port in the suggested range. It went online right away, and stayed online for several days, then get the error again. So the fix was temporary but as you say it proves my router has a problem UDP timeouts. I assume this means I need to change my router or get an ATA that will plug in between the modem and router, which I happen to have (Grandstream HT 502).

[Liptonbrisk]

Unfortunately, I am not familiar with your router, so I'm not going to be able to help you further with it. The best person to address this problem is probably Mango, but I'm not sure whether he'd be familiar with your router's firmware either. It's difficult for someone to become familiar with all consumer routers.

The following conditions needs to be satisfied:

UDP Unreplied Timeout (in your router) < Keep-alive Interval (in your ATA) < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (in your ATA)

< means less than

Keep-alive interval with FPL is 20, and SIP Registration Failure Retry wait time is 120 for FPL.

You would need to have access to both the UDP Unreplied Timeout and UDP Assured Timeout settings in your router and be able to change them. Possibly you would need to use third party router firmware in order to accomplish this.

I use 10 seconds for UDP Unreplied timeout and 100 for UDP Assured Timeout.

In third party Asus Merlin firmware, for Asus routers, for example, these settings can be found under Tools-->Other settings, and they're called UDP Timeout: Unreplied and UDP Timeout: Assured.
https://asuswrt.lostrealm.ca/

My understanding is that third party Tomato firmware also has those two settings available as well.

Could this be due to the modem DHCP renewal?

When your 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 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. This may the problem that you are encountering. If UDP Unreplied timeout is, for example, 10, and the Keep Alive Interval is 20, then the corrupted connection will timeout or close. A new connection will be created, and everything will work fine.

But your problem could also be due, possibly, to the failed retry timer being in excess of the Assured UDP timeout as well.

So, if you don't have access to UDP Unreplied Timeout setting in your router, maybe try 35 for the Keep-alive Interval in your ATA. Please note, however, that I have no idea what value the UDP Unreplied timeout is set to in your router. I'm just guessing that it's 30.

If I had to guess your settings are
30 > 20 < 180 > 120

So, I'm guessing the Buffalo router's defaults are 30 for unreplied and 180 assured UDP timeouts.

You could try changing the NAT Keep alive interval to 35 and the failed retry timer to 200.
30 < 35 < 180 < 200

Ideally it would be better to change the UDP settings in your router instead.

[mharvey500]

DD-WRT is not stable on Buffalo WHR-600D so I will not attempt to flash it. To get the router out of the picture, I installed a Grandstream HT502 ATA between the modem and the router and it is running much more stable. Only one glitch, one time an outgoing call had no audio both ways. The Linksys supplied dial plan is not compatible so I use the Grandstream default dial plan {*xx|[2-9]xxxxxxxxx|1[2-9]xxxxxxxxx|0xxx+}.

[Liptonbrisk]

DD-WRT is not stable on Buffalo WHR-600D so I will not attempt to flash it.

DD-WRT is not Asus Merlin nor Tomato, neither of which your Buffalo router appears to work with, unfortunately.

If you wanted to continue using it, you could try you could try changing the NAT Keep alive interval in your PAP2T to 35 and the failed retry timer to 200 (both Reg Retry Intvl: and
Reg Retry Long Intvl:), which, if I'm right about the default UDP Unreplied Timeout and UDP Assured Timeout values in your Buffalo router would satisfy the following conditions:

UDP Unreplied Timeout (in your router) < Keep-alive Interval (in your ATA) < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (in your ATA)

30 < 35 < 180 < 200

The Linksys supplied dial plan is not compatible so I use the Grandstream default dial plan {*xx|[2-9]xxxxxxxxx|1[2-9]xxxxxxxxx|0xxx+}.

That makes sense since none of the Grandstream PDF configuration guides for Freephoneline suggest changing the default dial plan: http://forum.fongo.com/viewforum.php?f=15.