All Circuits are Busy Now, Please try your call later

Here’s my setup:
3 dids (phone numbers) set on 3 trunks, each with its own user/password to connect to my voip provider. All show registered at the provider and all show registered on my phone Cisco SPA-508g.
3 outbound rules, 3 inbound rules, 3 extensions, each pointing to their respective route and each route to their trunk.
On each outbound rules, I have the Caller Id with the respective extension number.
All inbound calls work, all extensions to extension calls work, but for outbound calls, one extension works, and the other two get “all circuits are busy now, please try your call again later” msg followed by busy signal and disconnect.
This is the part that upsets the hell out of me, every single piece of configuration is exactly the same, so having a hard time to troubleshoot. Also, when I restart the system using fwconsole restart, then the extension that was working before goes into all circuits are busy mode, and another one starts working, but so far at any time only one extension works.
Any help is “very” welcome.
Logs from asterisk -rvvv are here https://pastebin.freepbx.org/view/437af328. Let me know if this is not the proper log and I’ll upload it. Thanks.

    -- Called PJSIP/4165568576@DVM
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [s@macro-dialout-trunk:28] NoOp("PJSIP/100-00000008", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 21") in new stack

On calls 2 and 3, the provider rejected the call. At the Asterisk command prompt, type
pjsip set logger on
and retry a failing call. The Asterisk log (and console) will now include a SIP trace and with luck the headers of the reject response will give a clue as to what’s wrong. If you paste a new log, it’s better to take the last lines of /var/log/asterisk/full, rather than the console, because the former includes timestamps on each entry.

Just guessing here, the provider may have a bug (or possibly a security feature) dealing with concurrent registrations from the same IP address and port. You could confirm or refute this hypothesis by deleting one trunk and setting it up as a chan_sip trunk. If my guess is correct, the chan_sip trunk will always work while one of the two pjsip trunks will fail. (You could later use multiple pjsip transports to get all three working.)

Who is this provider and why did you choose them? As you appear to be in the GTA, there are many choices where you could have a single account and a single trunk with as many DIDs and concurrent calls as you need. Also, since you are on AWS (with a static IP address), you could choose one with IP authentication, avoiding the possibility of lost registration.

Thanks for your reply. Provider is voip.ms, just using that as they are cheap (isn’t always the main reason?), but I’m very open to any other recommendations. About my setup, and I might not be using it properly, is to have inbound and outbound calls come from specific did. At Voip.ms, I do have a main account, and what they call sub-accounts (that I’m using it to connect), so what I will do as a test is to have only one trunk connecting to the main account and see how the calls flow thru in and out rules. If this doesn’t work, I will post another set of logs. Thanks a lot.

I recommend using a single sub-account for your trunk. Route the three DIDs to that sub-account and set the context for your trunk to from-pstn-toheader, which should allow the proper Inbound Route to be selected based on the called number. In the sub-account settings for CallerID Number, choose “I use a system capable of passing its own CallerID”. If you still have trouble, paste a log with SIP trace.

As to alternate providers, what is your approximate expected monthly minutes usage, in and out? Any other unusual requirements e.g. heavy international usage, special failover requirements, etc?

Changed to use just one trunk (main account), and it’s behaving exactly like before.
Funny thing is that when I outcall, for the Extension that works, it shows the number dialed, for the ones that do not work, it shows CID: Extension_Number instead.

Logs:
/var/log/asterisk/full
https://pastebin.freepbx.org/view/e87b35a6
pjsip set logger on
https://pastebin.freepbx.org/view/9fb2d07f

It’s working now, forgot that on the main trunk I wasn’t using any CID number, so as I added CID number in each outbound rules then it’s all working in and out, wonder why using the sub accounts didn’t work, but life is too short to figure it out, as at the end, the import thing is that it works now. I’m trying to create a process that I can repeat, as if/when AWS kills my instance, I can bring it up quickly again. Thanks for your help, Stewart1.

Also if you can recommend more Voip providers around GTA, it will be greatly appreciated.

VoIP.ms indeed rejected the call because the PBX sent the extension number as caller ID.

Confirm that for the extension, Outbound CID is in the format
"John Doe" <9054652345>
Also check that the Outbound Route does not specify Override Extension and is not an Intra-Company route, and the Trunk specifies Allow Any CID.

If all that is correct and you still have trouble, I’ll take a closer look at the log.

1 Like

Some providers that may be of interest for your application:
http://www.anveo.com/business/
https://www.callcentric.com/
Both, like VoIP.ms, offer sophisticated call processing. SMS but no MMS. Mandatory E911.

https://telnyx.com/
https://signalwire.com/
Basically dumb pipes, but can be configured for e.g. failover to mobile if PBX is unreachable. Free porting in. Free trials. SMS and MMS. Optional E911. Telnyx offers ANI (can see blocked caller ID); SignalWire prohibits sending caller ID that is not yours.

http://www.anveodirect.com/
https://www.voxbeam.com/
“Wholesale” providers with no monthly minimum. Outbound-only free trials. ANI. E911 not available.
AD has SMS but no MMS, simple failover to mobile. VB has no messaging at all, and no failover option suitable for small potatoes.

1 Like

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