Extensions steadily become unreachable after PBX runs for a few days

What happens if you configure the phone to use a static SIP port?

I’m assuming SIP ALG isn’t in play?

In my case I have set static SIP ports to each of the extensions because they were causing problems not registering behind the local firewall. This solved that problem. My client is behind a simple fiber connection and from what I know the router they have doesn’t have a SIP ALG setting.

I am not sure how setting a phone to use a static port will help. The problem is not in evidence for 48 hours or more, then steadily builds. Rebooting the the PBX cures the problem for a further 48 hours, but the phone doesn’t know the PBX is rebooted. Can it be fixed through the PBX GUI or the endpoint manager? (the port)

Are your routers SonicWALL? This symptom is very typical for those devices.
If yes, switch to TCP for SIP transport, or adjust the UDP timeout on the router.
Or, even better, rip out the SonicWALL… They are horrible in general and especially with VoIP.

1 Like

Sorry to have been quiet on this. Shortly after my last response the info about the Phone apps hack reached me and I realised this machine was infected. After a lot of work the hack has been cleared up and the initial problem has gone.

Actually this does not appear to be over. Checking the system on Sunday night showed phones regularly dropping and coming back.
I didn’t reboot. I just made 1 minor config change and hit the apply config button. The phones stopped dropping!

What was your solution? Did you make a minor config change to the phone or to the PBX?

I wouldn’t say it is a solution. I made a config change to the PBX

“A” or a specific?

and that config change would be???

I added the server room phone to the pickup group

Same thing happening this evening. An extension drops for 60 seconds, then comes back. Happens every 5 minutes or so.
I created a conference, hit apply, the dropping stops.

I checked all the stats before I did that, CPU ticking over, plenty of spare RAM, nothing much on the network. HTOP output looks normal.

I see this happen occasionally. The PBX does not seem to be respecting the “qualify” timer in the extension settings. Usually changing it from the default 60 to something lower like 20 or 25 fixes it.

What exactly does this setting?

Whilst the following is for the deprecated driver, because the description is more complete, the current, chan_pjsip, driver has a similar option:

Is it the server that checks the extension or the extension that checks the server? And how does this effect the phone the extension is on?

The host refers to the host parameter in sip.conf (or pjsip.conf), which is the remote device, the phone in your case.

The device receives more traffic than it would, with the default parameters.

If the host actually represents an ITSP (trunk in FreePBX terms), the host may be doing a similar thing to make sure that Asterisk is still there.

I have set qualify to 20 to see what happens in my case.

I still have this problem. Some extensions I have set the qualify time to 20 seconds and they are just as likely to have a brief drop as any other extension.
I have changed the registration timeout down to 120 seconds and that makes no difference.
The puzzle is the errors build through the day. I have set an automatic reload for 5am. When I check the dashboard and logs in the morning, there are no unreachable moments recorded, but by mid evening they start becoming more frequent.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.