Random incoming busy signals and outgoing "All circuits are busy" issues

For the last two days, incoming callers are randomly getting busy signals instead of our IVR and outgoing callers are randomly getting an “All circuits are busy” message. The server has been in place for several months and this is a new behavior. We use FreePBX hosted on a rentpbx.com server and voip.ms for SIP service. My guess is that this would be some kind of connectivity issue between the two. Ping Plotter shows no problems between the office/phone locations and these two servers but that doesn’t mean that there isn’t connectivity issues between rentpbx and voip.ms. The following sample of log notice 3786 seems to show connectivity problems between RentPBX/FreePBX and voip.ms:

[2017-12-05 11:31:34] NOTICE[3786] chan_sip.c: Peer ‘voipmshisc’ is now UNREACHABLE! Last qualify: 1
[2017-12-05 11:31:46] NOTICE[3786] chan_sip.c: Peer ‘voipmshisc’ is now Reachable. (2000ms / 2000ms)
[2017-12-05 11:32:49] NOTICE[3786] chan_sip.c: Peer ‘voipmshisc’ is now Lagged. (3000ms / 2000ms)
[2017-12-05 11:32:59] NOTICE[3786] chan_sip.c: Peer ‘voipmshisc’ is now Reachable. (1ms / 2000ms)
[2017-12-05 11:37:03] NOTICE[3786] chan_sip.c: Peer ‘voipmshisc’ is now UNREACHABLE! Last qualify: 1
[2017-12-05 11:37:13] NOTICE[3786] chan_sip.c: Peer ‘voipmshisc’ is now Reachable. (1ms / 2000ms)

I’m I correct in my guess above about the source of this problem? If so, would you suggest troubleshooting by pointing to a different server at voip.ms to see if the problem goes away?

Thanks for your insight.

maybe check the connectivity from service provider or set sip timer or refresh bigger.

My first guess would be your network is overloaded. It’s taking 3 seconds to get packets back and forth.

My experience with voip.ms is that seeing the peer Lagged is commonplace and has no impact on call progress or quality. Seeing it go UNREACHABLE is a different story, and something you need to fix.

If I run an online bandwidth test and try to call our system from my cell phone, I usually get a busy signal until the bandwidth test it finished. I’m pretty sure it’s because we don’t have enough spare bandwidth at that time for a call. Try configuring traffic prioritization on your WAN firewall, or possibly increase your bandwidth.

Unreachable means they didn’t respond to a SIP Options (Keep-Alive) sent by you to them - this could be just them ignoring them, or more likely, that they are over-committed and they CAN’T respond in a timely manner - and this WOULD explain the ACB’s and Busy Signals - if they can’t open a session (inbound) or accept a session (outbound) in a timely manner, Asterisk gives up fairly quickly.

Also note that not getting a SIP response during a Call-Setup errors out MUCH faster than a call failing to route to a bad destination - SIP Response failures are not normal nor expected - SIP Progress and Call Setup failures ARE to be expected because of the size of the PSTN and the tendency for people to dial bad numbers.

Do you have any suggestions as to how we can fix that? If I set the qualify= number higher, will that help?

If you consider masking the symptom instead of fixing the problem a help, then yes that will help.

So how can I solve the problem? Is it possibly a config error on our side, or is it 100% their fault, assuming we can ping our remote server continuously?

The source of the busy signal and ACB message will tell you where the problem is. If they are coming from your PBX, your configuration is the problem. If they are coming from the provider, I’d start with making sure you have enough network between you and your provider, and if that’s adequate, make sure you have enough services from the provider.

Check your logs. If the call is never getting to you, the problem is outside your local PBX.

Having a similar problem the last few days as well. A very specific number (a business I work with) can call in to our PBX but also of a sudden I can’t call out to it. It was working through week before just fine. I get the same.e messages in my PBX logs as @matthewljensen

LOGS!

You need logs to help you find the problem. /var/log/asterisk/full is the log file for this.