Network settings and VOIP phone issues

Did you set-up QoS (Quality of Service) on your router to give priority to your phone adapter?

Also, before "May this year", before the problem started, was there fewer devices connecting to the router?

If so, maybe your router is not sturdy enough for so many devices and a stronger, more reliable router is needed?

Perhaps you would permit me to ask some questions that may help us diagnose the problem. If you don't know the answer, let me know and I'll help you find it.

1) When the problem is occurring, can you use your computer to access the HT502's internal configuration web page? If no, do the lights on your router indicate the network cable is still connected?

2) Have you ever tried to change the Local SIP Port to some other number while you are having the problem? If so, did that make it temporarily work?

3) Please set the following on your ATA:
SIP Registration Failure Retry Wait Time: 600
Use Random Port: Yes

4) Please enter your DD-WRT and navigate to Administration >> Commands. In Command Shell, paste the following, and then click Run Commands. Let me know the result.

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp*

5) Next time the problem happens, do nothing for 10 minutes if possible. If the device does not auto-recover, change your Local SIP Port to 20123 and see if that temporarily solves the problem. If THAT does not solve the problem, navigate to Administration >> Commands from within your DD-WRT router and run the following:

grep ht.502.ip.address /proc/net/ip_conntrack

Post the result here, masking your public IP address (if it appears) to protect your privacy. After that, you can powercycle devices or whatever else you need to do to get it back online.

I'll watch this thread for updates.

Temporel wrote: ↑Did you set-up QoS (Quality of Service) on your router to give priority to your phone adapter?

Also, before "May this year", before the problem started, was there fewer devices connecting to the router?

If so, maybe your router is not sturdy enough for so many devices and a stronger, more reliable router is needed?

Thank you for you response.

I went into DD-WRT config page, NAT/QoS -> QoS and added the MAC address of the phone adaptor to "MAC priority list" and gave it an "exempt" priority. That didn't seem to do anything.

My memory is not clear, but I know at least one of the tablets in my house was purchased after around that time.

PianoGuy wrote: ↑Perhaps you would permit me to ask some questions that may help us diagnose the problem. If you don't know the answer, let me know and I'll help you find it.

1) When the problem is occurring, can you use your computer to access the HT502's internal configuration web page? If no, do the lights on your router indicate the network cable is still connected?

2) Have you ever tried to change the Local SIP Port to some other number while you are having the problem? If so, did that make it temporarily work?

3) Please set the following on your ATA:
SIP Registration Failure Retry Wait Time: 600
Use Random Port: Yes

4) Please enter your DD-WRT and navigate to Administration >> Commands. In Command Shell, paste the following, and then click Run Commands. Let me know the result.

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp*

5) Next time the problem happens, do nothing for 10 minutes if possible. If the device does not auto-recover, change your Local SIP Port to 20123 and see if that temporarily solves the problem. If THAT does not solve the problem, navigate to Administration >> Commands from within your DD-WRT router and run the following:

grep ht.502.ip.address /proc/net/ip_conntrack

Post the result here, masking your public IP address (if it appears) to protect your privacy. After that, you can powercycle devices or whatever else you need to do to get it back online.

I'll watch this thread for updates.

Thank you for finding my post, as you promised.

1) When the problem is occurring, I can't use my computer to access the ATA's internal configuration page. Instead, I connect a laptop to the ATA's LAN port and access the configuration page from the laptop. And no there is no light on the router's port #4, which is where the ATA is connected to the router. For your information, the lamp for WAN on ATA isn't lighted either. Only power and LAN (connected to the laptop) lamps.

2) Yes, I tried it. That was what the tech support person at voip.ms suggested I do. Tried changing it from 5060 (default) to 5080. It didn't do anything for me.

3) Tried it, but nothing.

4) I get

65
120

5) You wanted me to replace ht.502.ip.address with the ATA's ip address, correct? I tried running the command just like I ran the command in your instruction 4), but it didn't do anything for me. The splash popup says "Processing... please, wait" but when it's gone, I am just back on the command page. I tried the command with both the WAN IP address (192.168.1.146) and LAN IP address (192.168.2.1) of the ATA as well as ht.502.ip.address but none of the commands returned anything.


For your further information, it's not like the it works most of the time but loses connection sometimes. On the contrary, it's disconnected all the time. For some reason, just now, when I went into DD-WRT configuration page, the ATA (whose ip is 192.168.1.146, as noted above) was on the "Active Client" list for maybe two second, but then when the page auto refreshed, it was no longer on that list but instead was now on "DHCP Client" list.

Another further piece of information in case it may help, the ATA's internal config page says that the phone on port FXS 1 (where my phone is connected) is not registered, but when I go to voip.ms's account settings page and click on "check registration status" button, it says my account is registered.

monotious wrote: ↑ This setup has been used for the main home phone for quite some time. But starting in May this year, the phone adapter keeps losing connection to the router.

The best method to avoid these issues is to install a sip proxy on your router such as Siproxd.

coolspot wrote: ↑The best method to avoid these issues is to install a sip proxy on your router such as Siproxd.

Thanks.

I ran searches on sip proxy and siproxd, but this seems to be beyond my ability and understanding.

monotious wrote: ↑Thanks.

I ran searches on sip proxy and siproxd, but this seems to be beyond my ability and understanding.

Install DD-WRT VOIP edition, it has SIPatH sip proxy installed: http://dd-wrt.com/wiki/index.php/What_i ... e_Versions

So far we know:
1) ATA is up, as you're able to access its configuration by the LAN port.
2/3/5) Corrupted NAT association seems unlikely, although it does seem to be missing. This may indicate a Register Expiration that is too long.
4) UDP timeouts seem to be appropriate.

Let us try a few more things.

1) Please change the network cable between the router and the ATA, if you have not already done that. Also please inspect the WAN port on your ATA for physical damage such as bent pins.

2) Set Reply to ICMP on WAN port and also WAN side HTTP/Telnet access to Yes. This should allow you to access the HT502's configuration without attaching your laptop to the LAN port. If you ever decide to connect your ATA directly to your modem, you should change these back. Next time the problem happens, you should be able to tell whether or not the WAN port is working by accessing the ATA's internal configuration page.

3) Set up a static IP address for the ATA. Pick any IP that is outside of the DD-WRT's DHCP range. Use the same subnet mask and default router as usual. For DNS Server 1/2, please use 8.8.4.4 and 208.67.222.222.

4) On the Advanced Settings tab, please set Keep-alive Interval to 75. (This must be greater than 65 and less than 120, which you obtained in the last step 4).

5) On the FXS PortX tab, set the following if not already set:
NAT Traversal: Keep-Alive
SIP Registration: Yes
Register Expiration: 3
Reregister before Expiration: 0
SIP Registration Failure Retry Wait Time: 180. (Earlier I told you 600 - this only needs to be greater than the 120 you obtained in the last step 4).
Allow Incoming SIP Messages from SIP Proxy Only: Yes (Not causing your problem - but good security practice).

Let me know how things go.

PianoGuy wrote: ↑So far we know:
1) ATA is up, as you're able to access its configuration by the LAN port.
2/3/5) Corrupted NAT association seems unlikely, although it does seem to be missing. This may indicate a Register Expiration that is too long.
4) UDP timeouts seem to be appropriate.

Let us try a few more things.

1) Please change the network cable between the router and the ATA, if you have not already done that. Also please inspect the WAN port on your ATA for physical damage such as bent pins.

2) Set Reply to ICMP on WAN port and also WAN side HTTP/Telnet access to Yes. This should allow you to access the HT502's configuration without attaching your laptop to the LAN port. If you ever decide to connect your ATA directly to your modem, you should change these back. Next time the problem happens, you should be able to tell whether or not the WAN port is working by accessing the ATA's internal configuration page.

3) Set up a static IP address for the ATA. Pick any IP that is outside of the DD-WRT's DHCP range. Use the same subnet mask and default router as usual. For DNS Server 1/2, please use 8.8.4.4 and 208.67.222.222.

4) On the Advanced Settings tab, please set Keep-alive Interval to 75. (This must be greater than 65 and less than 120, which you obtained in the last step 4).

5) On the FXS PortX tab, set the following if not already set:
NAT Traversal: Keep-Alive
SIP Registration: Yes
Register Expiration: 3
Reregister before Expiration: 0
SIP Registration Failure Retry Wait Time: 180. (Earlier I told you 600 - this only needs to be greater than the 120 you obtained in the last step 4).
Allow Incoming SIP Messages from SIP Proxy Only: Yes (Not causing your problem - but good security practice).

Let me know how things go.

Thank you so much! I think this resolved the issue! I'll still list out what I did below in steps, but it looks like 5) is what solved it.

1) As it turns out, there must have been a problem with the cable. When I used new cable, both the lamp on the router and the lamp on the ATA lighted up, and the phone worked. But it must not have been the only problem, as the phone works only for a while. After I replaced the cable, or every time I pull out and reconnect the cable, I can get incoming calls, but this status lasts for only about 2 minutes or so. After that, incoming call doesn't work any more. However, outgoing call seems to work after that point, and once I place an outgoing call, I now seem to have another 2 minutes or so of period during which incoming call works. I am happy that we seem to be making a progress here.

2) I did as you told me and I can access the config page from the computer. Thanks.

3) I went into ATA config and under basic settings, clicked on the radio button for static IP and did the following:

IP Address: 192.168.1.254
Subnet Mask: 255.255.0.0
Default Router: 192.168.1.1
DNS Server 1: 8.8.4.4
DNS Server 2: 208.67.222.222

It's still showing the same behaviour described in 1).
(By the way, just out of curiosity, when I tried setting the static IP to 192.168.1.255, it didn't connect, but when I used 192.168.1.254, it seems to work. Do you know why? I thought numbers up to 255 were allowed. DHCP range goes from 100 to 149.)

4) I changed it from default 20 to 75. Still the same.

5) I changed the setting as follows:

NAT traversal: from No to keep-alive

SIP registration: it was already yes, so I left it as it

Register Expiration: It was 60, changed to 3

Reregister before expiration: already 0, so left as is

sip registration failure retry wait time: 600 (as you advised before) to 180

This seems to have done it. Now I can get incoming calls even after waiting a long time.

I will keep my eyes on this for a few days and see if it continues to work without giving further problems.

Based on everything I told you, do you have a sense of what the problem was? I'd be curious, although I am not sure if I'll understand it. You mentioned NAT association, Register Expiration and UDT Timeouts, but I don't know what these terms mean. Naturally, I am only a user and don't understand the technicalities of voip.

And what do you think of coolspot's suggestion about installing SIP proxy on the router?

Anyway, thank you so much, you basically solved a months old problem that's been nagging me in my life. I am so happy I caught your attention with this. It would've been nice if the tech support person at voip.ms was as knowledgeable and dedicated as you are. You made my day.

It's great to hear that things are working.

monotious wrote: ↑(By the way, just out of curiosity, when I tried setting the static IP to 192.168.1.255, it didn't connect, but when I used 192.168.1.254, it seems to work. Do you know why? I thought numbers up to 255 were allowed. DHCP range goes from 100 to 149.)

.255 would be the "broadcast address". You can use .1 through .254 - though on a home/SOHO network, .1 is typically used by the router, so you can actually use .2 through .254. As it turns out, you're correct that 1) and 5) solved your problem and the static IP is not really necessary. (It was just a guess in an attempt to avoid going back-and-forth with you too many times.) You can change back to DHCP if you want, or just leave it as is - it won't matter either way.

monotious wrote: ↑Based on everything I told you, do you have a sense of what the problem was?

It sounds like a bad cable was at least contributing to your problem. The other problem was timeouts. When you register to VoIP.ms, your router "remembers" this connection for (as we discovered earlier) 120 seconds. That is why when you first plugged your cable in, you were able to receive calls for about two minutes. We set up keep-alive every 75 seconds so that the connection would remain active permanently. Satisfying the following equation will make things work properly:

UDP Unreplied Timeout (65) < Keep-alive Interval (75) < UDP Assured Timeout (120) < SIP Registration Failure Retry Wait Time (180)

monotious wrote: ↑And what do you think of coolspot's suggestion about installing SIP proxy on the router?

I like to keep things as simple as possible. I think your service can be made to work properly without going to the trouble of setting up a SIP proxy.

monotious wrote: ↑It would've been nice if the tech support person at voip.ms was as knowledgeable and dedicated as you are.

Some of the VoIP.ms techs are morons. This is basic stuff that a level 1 tech should be able to do on their first day.

PianoGuy wrote: ↑Some of the VoIP.ms techs are morons. This is basic stuff that a level 1 tech should be able to do on their first day.

You pay for what you get right - voip.ms is basically a no support service.

In retrospect, I possibly shouldn't have insulted their staff. It could just as easily be bad management. If they can't solve something like this, they must not even have a script or a flow chart to follow.

Yeah, I think they were trying too, and like coolspot says, it's a no support service. I knew just enough to follow the instructions for the initial setup but I guess I should know a bit more in case trouble happens.

Is there any web resource that I can read to get myself a bit more familiar with how VOIP works? I want to be able to do basic troubleshooting myself too.

ATA config's got so many setting options but hardly any of them make sense to me. Knowing what some of the options are about will help.

PianoGuy wrote: ↑In retrospect, I possibly shouldn't have insulted their staff. It could just as easily be bad management. If they can't solve something like this, they must not even have a script or a flow chart to follow.

Yeah, based my experience with their support, it's non-existent... Thankfully I haven't had to use them much, although right now I am battling a weird call transfer issue.

I guess that is why Anveo has taken pay per issue support model.

monotious wrote: ↑ATA config's got so many setting options but hardly any of them make sense to me. Knowing what some of the options are about will help.

You can start with the ATA manual, although most of the times the manufacturers poorly document the settings. I think it's because they expect service providers to be buying the hardware - and if the provider (i.e. Vonage, Teksavvy, etc.) run into an issue configuring the device, they would just call the manufacturer/professional services directly.