Forward all incoming calls to an external number

[stylo323]

Hello,
Our company is going to be out of office for a week and I need to make our freePBX to forward all of the incoming calls to an external numer during that period.
Our internal numbers start with 4 and 5, and I’ve tried setting up an inbound route:
For example if numbers are 012334xx, where 4xx is the internal number, I’ve set up the following route: “_001233[45]xx”, and set it to forward to a misc destination with the external number.
But it doesn’t work, when I call any of our numbers the phones still ring and the call is not forwarded.

[david55]

I think your problem is that an exact match always wins over a wild card one.

Also X in patterns is case sensitive. Lower case x will only match lower case x.

[stylo323]

I see. So what solution can I use then?

[david55]

My first point assumes a straightforward Asterisk way of doing things, but FreePBX may do things in a way where the first pattern matches, rather than the best. (E.g. putting each match in an included context of its own.)

However, using x for X would need correcting, even then, so I guess the first thing is to try that.

Based on the user guide, which is rather out of date, it is only outbound routes where order is settable.

Do you really have 100s of inbound routes. If not, you probably want to redefine them for the duration, if you want to use the GUI.

If you are happy using custom code, you can probably create a custom context that rewrites the DID to a special one for your holiday mode.

As far as I can see the primary support for holidays is done on a per extension basis, not in terms of large blocks of extensions, but there may be a commercial or newer module of which I’m not aware…

[stylo323]

Tried replacing x with X, but still getting the same result.
We have about 60 extensions, but some of them are in the 400 range, others in 500.

[mcgrathr (Mc GRATH Ricardo)]

@stylo323

set up the following route: “_001233[45]xx

Have you checked priority inbound route order, were the previous settings still before the new settings?

[mahbell]

@mcgrathr

Have you checked priority inbound route order, were the previous settings still before the new settings?

@david55 already answered this, exact matches trump wildcard entries.

@lgaetz has done multiple writeups on dynamic routes, which I think would serve you well here

Using Dynamic Routes for Call Flow Control

The Call Flow Control module works great for giving user control over how calls get branched, provided you have exactly two destinations. Once you have more than 2 destinations, the CFC module technically can work by chaining them together, but doesn’t work well at all for that. Branching call flow based on a condition is what Dynamic Routes does best, and it can easily handle multiple destinations. Over this past long holiday weekend, I tested this setup. For this use case, suppose you have so…

[david55]

Exact matches trump in pure Asterisk, but I did point out that FreePBX does have order sensitivity for outbound routes, although I couldn’t find any documentation for such on inbound routes, in the wiki, which is based on FreePBX 13. However, things may have changed since the documentation.

In pure Asterisk you would have (with some liberties with syntax details):

[context]
EXTEN => pattern1,1,Goto(dest1)
EXTEN => pattern2,s,Goto(dest2)
EXTEN => pattern3,s,Goto(dest3)

Which allows efficient searching of the patterns, finds the best match, and is order independent.

However FreePBX might do:

[context]
INCLUDE => search1
INCLUDE => search2
INCLUDE => search3

[search1]
EXTEN => pattern1,1,Goto(dest1)
[search2]
EXTEN => pattern2,1,Goto(dest2)
[search3]
EXTEN => pattern3,1,Goto(dest3)

which means each pattern has to be matched from the start, first match wins, and order is significant.

It must be doing the second for outbound routes. Maybe it does so for inbound ones as well The worst case would be that it does so for inbound routes, but doesn’t allow you to control the order. You should, however, check the actual forms on the version you are using to find out if a position setting field has been added to inbound routes since the documentation was written.

[mcgrathr (Mc GRATH Ricardo)]

Two out of Three, logic analogy.

[david55]

I’ve looked at the source code and I’m fairly sure the inbound route handling uses the raw asterisk structure, with one variation, that there are two sets of matching rules selected by the Caller ID is Primary option.

What is definitely the case, is that there is no user control of the order of the matching rules. They are done on a simple database sort of the extension pattern, followed by the caller ID pattern. That will actually mean that patterns sort first, but because they are done the simple way, the order doesn’t matter.

The reason I rejected dynamic routes was that you seem to need to set them individually for each extension, unless they allow you to provide an expression for the extension number.

[mahbell]

@david55

The reason I rejected dynamic routes was that you seem to need to set them individually for each extension, unless they allow you to provide an expression for the extension number.

I believe you could use one dynamic route to accomplish what the user is looking for, but @lgaetz would know best.