All Circuits Busy - Inbound Line Also Dead Sometimes

General Help
1

Hi everyone, I’m brand new to FreePBX and just trying to get this going for a tinker project. Please consider my newness and I apologize in advance for any “FNG” frustrations!

I have FreePBX installed on an esxi virtual server from the SNG7-PBX16-64bit image, with appropriate NAT rules and forwarded ports on my pfSense firewall. When I initially boot the machine, inbound AND outbound calls seem to work perfectly.

Eventually, as the server is online, INBOUND calls no longer receive a ringing tone, just dead silence and the connection stays open with “Connecting…” displayed on my cell phone.

Once this occurs, I also observe that any OUTBOUND calls are met with a “All circuits are busy now.” message when I try to dial out.

The above occurs after an arbitrary amount of time, with no changes to configuration involved. Sometimes the system seems to recover and eventually allow calls in and out again. Whatever the issue is, it seems to affect inbound and outbound equally (ie. If one is affected, the other will be as well).

Here is an astrick log with pjsip verbose logging enabled:
pastebin.freepbx.org/view/3d634c36
This should be the same as recovered from the CDR log and CLI:
pastebin.freepbx.org/view/497eff68

This log represents trying to dial OUT and being met with the “All circuits are busy now” message.

I’ve renamed some of the DIDs and cellular numbers for obfuscation purposes.

If other logs are required, please advise and I will obtain and upload.

In my research I have already seen the latest thread on a similar issue (busy circuits) here:
community.freebox.org/t/all-circuits-busy/87977/9

I see the recommendation to adjust the Extension Outbound CallerID format, however my Extensions have their Outbound CID blank and I have my 10 digit DID listed in my Outbound Route CID. From what I understand, this should be applied, however I am seeing:

16763From: "Office" <sip:[email protected]:5060>;tag=99859dddb4
16764To: <sip:[email protected]:5060;user=phone>

I’m not sure why the From field isn’t picking up the Outbound Route CID?

2

This is normal. You are looking at the call from Aastra to the PBX. The INVITE from the PBX to VoIP.ms on line 17200 has a presumably valid caller ID.

However, on line 17247, VoIP.ms rejected the call, even before asking for authentication, so I believe that they did not recognize the source account. I’m not a VoIP.ms customer and don’t know the details, but try these trunk settings and see whether it gets further:

SIP Server: vancouver2.voip.ms (don’t use a numeric IP address)
From User: your VoIP.ms subaccount (same as what you have in Username)
From Domain: vancouver2.voip.ms (same as what you have in SIP Server)

Next, on line 17233, VoIP.ms said that the call arrived from your port 8335, even though Asterisk sent it from port 5060, so your router/firewall must have rewritten the source port. This may or may not cause trouble, depending on the NAT settings and behavior at VoIP.ms. If possible, set your firewall for “consistent NAT” or “disable source port rewriting” or similar.

Finally, the second log you posted was an incoming call that appeared to be unanswered and went to voicemail. If something was wrong (called phones didn’t ring, voicemail greeting didn’t play, etc.), please provide details.

If you still have trouble, paste new logs reflecting the changed settings.

1 Like
3

Thank you for the direction!

I just made some changes to my NAT rules as directed and will verify.

I will investigate the suggestions, my immediate question would be you recommending:
From Domain: vancouver2.voip.ms (same as what you have in SIP Server)

As this is the “From” (aka my PBX) field, wouldn’t that be my outbound IP address? That’s what I currently have it set to. Thanks for clarifying, I may be misunderstanding the field meaning.

4

Some providers require this to be their domain (the end users need to appear as if they are on the provider’s system). I’m not aware of any that would reject calls for this reason, so it seemed worthwhile to try.

1 Like
5

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