Extensions steadily become unreachable after PBX runs for a few days

I wonder if anyone can help me figure out what is going on.
I have a customer who is setup on a Vultr hosted freepbx 15 and has about 25 extensionsAfter a few days the odd extension will become unreachable for 60 seconds, then come back as reachable. As time goes by other extensions will start to do the same. If I leave it another day it will become more common. These phones are in five or six different locations and the fault can happen in any location to any extension. It’s almost as thought the PBX is running out of resources, yet CPU use is ticking over around 2% and i have given it 2GB ram and it shows .5GB spare.
HTOP shows no runaway processes.

Any Ideas?

PBX Version:
15.0.17.64
PBX Distro:
12.7.8-2107-3.sng7
Asterisk Version:
15.7.4

I maintain a similar setup and I’m experiencing something similar. I have built a fail save that forwards calls to another location (one not connected to the PBX) in case all extensions get disconnected. I thought it could be an unstable internet connection, but seeing you have the same issue, it might be something else.

Thanks for replying. I don’t think its internet connection related as I am seeing it from multiple locations and the main site has a 1000Mbs leased line. It looks more like it is related to a problem building over time on the server.

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.