SOLVED Registration vs reachable issues

[rjm]

I am confused. My phones are becoming unreachable during the night on one system.

When I do a sip show peers in the cli I see all my phones are unreachable. If I do a sip show registry, I see only my registered trunk presently.

Then I core restart when convenient, asterisk restarts, and all my phones become reachable. But when I do a sip show registry, none of the phones are registered.

My goal is to get my phones registered all the time.

I have p32 registry expiration set to 5 in an attempt to re-register frequently thinking this will keep the phones alive. But now I am thinking that I have the backwards. That what I really want is for them to expire less frequently.

So I have a two part question. What keeps a phone reachable? I thought that NAT did that (the phones are currently set to Auto).

And also, what setting makes a phone stay registered and keep the port open?

I am also having some long lag time issues, so this is compounding the problem in understanding the issues. Oh, and all the phones are off site so I can't play with them.

 

[billsimon]

Some more thoughts on this puzzle.

The purpose of registration is to let the server know where the phone is (IP address and port, for the most part). It can also be used as a keep-alive mechanism by causing the phone to send packets through the NAT often enough to prevent the NAT from shutting the port.

Depending on how aggressive your NAT is at cleaning up its tables and shutting the port, using registration for this purpose may be a huge waste of resources. Registration packets are much larger than the empty packets phones typically use for their NAT Keep-Alive routines and add extra burden to the server.

If the phones aren't moving about and the NAT is remaining open thanks to the phone's keepalive routine, then there is no need for the server's probing of the phones with OPTIONS packets (done with the qualify statement). If those OPTIONS packets are getting lost but everything else is actually working ok, set qualify=no on the extension configurations and see how it goes. Then Asterisk won't automatically detect lag or unreachability. It will just try sending calls to the registration it has for the phone.

 

[rjm]

Thanks Bill! Excellent advice, as always. I did try to set qualify to no and then do a core reset but anywhere that was set to qualify no did not become reachable. So I am trying something different. I noticed that if the response time falls below the qualify time, that the extension will be TAKEN OFFLINE AND CONSIDERED UNREACHABLE! That seems to be exactly what is happening every time Comcast hiccups which occurs through the night for some reason.

So here is what I am trying now. Hoping that qualifyfreq is the same thing as qualify time, I have raised qualifyfreq from 15 to 60 or 90. I have done this in a pattern so it should be pretty easy to see what is working in the am.

I'll keep you posted. Thanks again for your help.

 

[hbonath]

Another thing to add to Bill's excellent advise is to look at your gateway's NAT settings. You want to adjust your UDP timeout to be fairly high (600 seconds maybe) for SIP. SONICWALLS for example notoriously have a low default UDP timeout of like 30s which causes exactly what you describe.

 

[rjm]

Thanks hbonath! I appreciate it!

 

[rjm]

For posterity and other folks pulling out hair, here is what I think was going on.

I had set qualifyfreq down to 15 due to my misunderstanding of what it does.

This never presented an issue before, but in the past week I started to connect some dots and watching my systems closer. I started to notice that the phones started to become unreachable through the night. IDK if it was always this way or just something sudden, but it was happening every night when I looked. One customer complained of having to power cycle the phones too often. (dot 57 connects to dot 58, starting to see a picture here).

Watching ISP lag times, I noticed that every so often Comcast would lag heavily. These lags were closely associated with the phones falling off of the earth. (dot 58 to dot 59) Resetting the system solved the problem, but also restarting Asterisk solved the problem! (dot 60)... So now I am figuring that it is not a NAT issue and is something else.

I set up a test and set some extensions at qualifyfreq=15, some at 60 and some at 90. But I haven't had a phone drop out in two days. What?!? (still looking for that dot)

Make a long story short, I think that when the ISP lagged sufficiently, qualify timed out. When qualify timed out, Asterisk considered the phone unreachable, and took it off line. Resetting Asterisk brought them all back. And finally, that the ISP's involved have been less laggy in the past few days eliminating the symptoms.

I left the qualifyfreq settings alone so at some point something will probably fail. If I find anything different, I'll amend this post.