Route certain extensions to certain trunks (All circuits are busy now...)

FreePBX Configuration
1

FreePBX 15.0.24. Asterisk 16.28.0.

Yes, I’ve searched and read several discussions on this topic. What I’ve done failed in a way that I’ve not seen any coverage.

Honestly, I think I’ve stumbled upon a bug.

The quick background: Our organization has two departments with different DIDs on different trunks. Incoming calls work as I want. With outgoing calls, I want extensions 3XX to go out one trunk and all others (2XX at this point) to go out the other.

So I need two outbound routes, one with dial patterns that have a CallerID of 3XX and another outbound route with dial patterns that have no CallerID. (I’m talking about the right-most field in the Dial Patterns tab when editing an Outbound Route.)

The problem: I set up both trunks, with inbound and outbound routes, and 7, 10, and 11 digit dial patterns generated by the wizard. I don’t mess with the CallerIDs at this point, and just leave them blank.

Naturally, outgoing calls will use the first outbound route in the list. Doesn’t matter which I put first, both work. But as soon as I set the CallerID field in the dial pattern tab for the first outbound route, to 2XX or 3XX as is appropriate, it causes all outgoing calls to fail. The message is “All circuits are busy now.”

Even worse, if I clear the CallerID field from the dial patterns, it remains broken.

If I switch the order of the outbound routes, all calls start working (because the first route matches everything). If I switch them again, so that the one with something in the CallerID field of the dial patterns is first, it will work for the calls from extensions that match the dial patterns, but anything falling through to the second outbound route will fail.

So… By switching the order of the routes and applying the config, I can get it back to the state where the first route works (because it catches everything).

And… If I add something, 2XX, to the CallerID field of the dial patterns for the second route… It breaks both routes. If I then switch the order, so the route with the CallerID field set is the first route… The first route will work, but anything that doesn’t match fails.

Any suggestions?

2

If an attempted call fails to match any Outbound Route, the error announcement is “Your call cannot be completed as dialed”. The “All circuits are busy now” means the either that Trunk Sequence for Matched Routes contains no enabled trunks, or that the attempt to dial out on the trunk failed (not registered, qualify failed, or the provider rejected the call).

At the Asterisk command prompt, type
pjsip set logger on
or if for some reason you are using chan_sip trunks, type
sip set debug on
attempt an outbound call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here. If you are too new to post links, just post the last eight hex characters of the URL.

3

Thanks for the reply and the explanation.

Here’s the pastbin.

Edit: Actually, that one may have worked. I could swear that last night, dialing from a 3XX extension failed, but a 2XX extension (which matched the first outbound route) worked. Today, to my complete surprise, it’s the opposite. The first route is definitely matching 2XX extensions.

And just now I tried again. It switched back to the 3XX extension failing. Strange.

To be clear, I’ve changed nothing. Today, I’ve only done what I needed to get the pastebins.

Anyways here is a pastbin with it failing.

4

In both logs, VoIP.ms rejected the call:

<--- Received SIP response (510 bytes) from UDP:208.100.60.61:5060 --->
SIP/2.0 403 Forbidden

I believe this is because they require the username in the From header.
Please add to settings for the trunk in question:
From User: (same as Username)
From Domain: (same as SIP Server)

Retest. If it still fails, paste another log. Please ensure that Delete After is left at Keep Forever so future readers of this thread can follow along.

5

Thanks for the suggestion. I gave it a try, changing the ‘From User’ in trunk’s pjsip Settings, under the advanced tab. The ‘From User’ has been set to match the username under the general tab of the pjsip Settings. This is the VOIP.ms sub-account name that is associated with the DID.

Before and after making the change I get the “All circuits are busy now…” message on both sets of extensions. Unsurprisingly, incoming calls work perfectly.

Here’s a pastebin of the failure. It looks like it has changed to a ‘401 Unauthorized’.

6

It’s not a 401:

<--- Received SIP response (562 bytes) from UDP:208.100.60.61:5060 --->
SIP/2.0 503 Service Unavailable

It appears that From Domain was not set in the trunk. Set that and retest. If no luck, check caller ID settings, balance, etc. on the VoIP.ms portal. If still no luck, paste another log.

7

Yes, that’s interesting. There’s a 401 further up in the log, but a 503 shortly after. In the log I include below, lines 34 and 157 are 401s. The 503 is at line 233.

In any case, I’ve made absolutely sure that the from domain is set to the SIP server (ie. the VOIP.ms server that I’ve associated the DID with). I got similar results from extensions that would use either outbound trunk.

In this Youtube video, the fellow sets the From Domain to the IP address of the FreePBX server. That’s what I originally did and it worked, but only when I was using one trunk.

Here’s the link to a new pastebin.

8

None of the 401s in your log are errors; they are challenges for authorization and Asterisk and the Yealink responded properly.

I can’t see anything wrong with the INVITE that got the 503. Some guesses as to why VoIP.ms may have rejected the call:

  1. Some of the codecs offered confused them – try enabling only ulaw and alaw.
  2. Caller ID issue: you specified (on the portal) that your system will supply the caller ID (but it doesn’t), or you specified a fixed caller ID that is not a number you have with VoIP.ms and is not a number that they verified.
  3. Balance issue: You set up separate funding for your sub-accounts and gitzeltrunk does not have sufficient balance for the call.
  4. Calling permissions: The countries you allow for gitzeltrunk does not include Canada.
  5. Other restrictions, e.g. you set up the subaccount to only allow calls from specific IP addresses, which do not include your PBX.

The log at VoIP.ms may indicate why the attempted call failed.

If you have checked all of these and found no problems, I suggest opening a ticket with VoIP.ms, asking why the call was rejected.

9

Thanks for the explanation of the 401s.

The codecs might have been an issue. I’ve made sure that they match what is available from VoIP.ms.

Talked to VoIP.ms, the ‘From User’ being set to the subaccount name was a problem. It has to be set to the CallerID or just left blank. When I addressed that, the trunk began working.

With that resolved, I’m back to where I started. I can get either trunk’s outbound route working individually, but not together (routing based on extension/CallerID). I can have two outbound routes, and swap their order to send calls out one or the other. That will work. As soon as I put anything in the outbound route’s CallerID field (ie. ‘2XX’), submit, and apply, it mungs everything up. Calls to the second outbound route will fail with the “All circuits are busy now…” message. I have to tear down the outbound routes, inbound routes, and trunks, then reconfigure the trunks and routes to get things back to a sane state.

I had VoIP.ms run a trace. Here’s the salient bit of the conversation:

We are receiving your header like this:
From: sip:[email protected];tag=9328950a-e0e0-43e1-b5d9-864cb9e3a0dc
To: sip:[email protected];tag=as47acebba
Where our server is expecting something in this format:
Contact: < sip:[sipaccount]@[your_IP]:5060;transport=UDP >
From: “CallerID Name”< sip:[sipaccount]@[server].voip.ms;transport=UDP >;tag=b227be76
To: < sip:[Number]@[server].voip.ms;transport=UDP >

10

If you make a change and it breaks something (or not), and you undo that change, Submit and Apply Config you should be back where you were. If that’s not happening, you have a serious problem with Asterisk, FreePBX or the OS and it’s much more important to track down and fix it than to mess with routing details. Another possibility is that your change is triggering a security measure at VoIP.ms and they are blocking your IP address for some time. They should be able to tell you if that has been happening.

These two statements seem to be opposites. The first says to you must not send the subaccount name in the From header, but the second says that you must (unless by sipaccount they mean the main account number).

How have you set CallerID Number on the VoIP.ms portal for your subaccounts? Until you get the routing / trunk selection issues resolved, I suggest setting “Use one of my DIDs”, to eliminate the possibility of calls being rejected because of caller ID issues.

If you still have trouble, please paste the Asterisk log (not the console output) for a failing call. It will be several hundred lines.

11

The same thought occurred to me.

I actually spoke with two support people. The first immediately spotted the problem with the sub-account name (‘cdctrunk’) ending up in the ‘From’ line in the header (so ‘From: sip:[email protected];[…]’). When I cleared the ‘From User’ in FreePBX, and applied, it started working. At which point, I thought to myself: “Stewart mislead me.” Later, when the same problem appeared on the other trunk (‘gitzeltrunk’).The second support person’s sharing of the expected header format seemed to match what you had said. My faith was restored.

So before building a new FreePBX VPS with more resources, or dumping FreePBX for FusionPBX, I decided to try an alternative SIP provider to VoIP.ms, Flowroute. Fifteen minutes later everything was working, including outbound routes by extension. I think that VoIP.ms is somehow mixing up credentials between sub-accounts… Maybe. I’ve also had trouble with registrations today.

Things seem to be working for the moment.

12

On Flowroute, I recommend using IP authentication rather than registration. On the Interconnection section of their portal, look at the Inbound Routes and IP Authentication tabs. It’s more robust, as there is no possibility of missing incoming calls because of “lost registration”. It’s also a little more secure; if your PBX gets hacked there are no SIP credentials there to steal.

Also, since you send caller ID with each call, you don’t need multiple outbound routes or trunks. Just set the Outbound CID for each extension as desired, and don’t override that in the Outbound Route or the Trunk. (You can also do this with VoIP.ms, but the OP mentioned “two departments” and I thought that you may have wanted separate billing for them. AFAIK Flowroute does not offer this feature.)

If you are seeing significant CPU usage (when not making or taking calls), it’s possibly caused by attempted attacks. Take a look at the Asterisk log and lock down your system if there is malicious activity.

13

Thanks for the recommendations on Flowroute configuration. I see your point: Because they assign credentials, there is a risk of their getting leaked, which IP authentication avoids.

I see how setting the outbound CID for each extension would work. We may go that way, just because it allows us more freedom when assigning extensions.

The increased system load shortly followed my posting here, which may have lead to someone launching an attack. System load is hovering around 0.4 now. It jumps to about 2 whenever new configurations are applied.

At the moment, I have no issues. Thanks for all your help Stewart.

14

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