FusionPBX Basic Configuration: Creating an Inbound Route

Previous article: FusionPBX Basic Configuration: Creating a Gateway to an Asterisk server and an Outbound Route

The intent of these articles are to show you how to do a few basic things in FusionPBX and to give you a little bit of the “flavor” of it. Both FusionPBX itself and this article are works in progress, and particularly if you are reading this within the first week or so after I post it (or even the first YEAR in this case), you might want to check back later since there is a high likelihood I will have made edits and corrections. If you haven’t yet installed FusionPBX, see Installing FusionPBX successfully — Part 1: Installing Debian Linux and Installing FusionPBX successfully — Part 2: Installing FusionPBX for information on that.

Assuming that you have by now created a Gateway to another server, you still need some way to direct incoming calls, and that is where Inbound Routes come in. To create a new Inbound Route, from the main menu go to Dialplan|inbound Routes, and the page that will list Inbound Routes (once you have created one or more) will appear. Click the icon on the right hand side of the page to add a new Inbound Route, and this page should appear:

FusionPBX Inbound Call Routing – Add Route

Some of the main Actions available include Call Center, Call Group, Conferences, Destinations, Extensions, FAX, FIFO, Gateways, Hunt Groups, IVR Menu, Language, Recordings, Ring Groups, Time Conditions, Voicemail, and Other. Many of the actions have sub-items, for example, under Extensions or Voicemail you see a list of your extensions, and can route calls to the extension directly or to its voicemail, or you could send them to a Ring Group that encompasses multiple extensions. The “Other” category will be interesting to the technically proficient; in a basic installation its sub-items include answer, bridge, db, export, global_set, group, hangup, info, javascript, lua, perl, relect, set, sleep, transfer, and other (the latter just lets you enter your own Action Application). I suppose that perhaps this menu could get expanded further if you add or enable other modules.

Typically you might enter a route name in the Route field, a DID number in the Destination Number field, a destination such as a particular extension, voicemail box, Ring Group, IVR, etc., and optionally a Description of the route.  The Order is only important if you have more than one inbound route that could act on the same incoming call, and in that case you may want to change it to give certain routes higher precedence.  As will be explained later, you are not limited to using a destination number as the criteria for routing an inbound call, so it is possible that an incoming call could be processed through any of two or more inbound routes, and in that case you’ll probably want to define the order in which these routes are processed.

If, under the Action dropdown, you select an extension, it will actually be converted to string consisting of the string “transfer:” followed by the extension number, followed by the string ” XML default”, so if you selected extension 1000 as the extension, what would actually be placed in that field is transfer:1000 XML default.

After you have created an Inbound Route it’s possible to go back into it and edit the contents of certain fields.  Why would you want to do that?  Well, consider that in the previous article, I set up a Gateway to an Asterisk server, and one thing I wanted was for users on that server to be able to dial an extension number and reach users on the FusionPBX server.  It’s easy enough to pass the calls from Asterisk to FusionPBX, but without an Inbound Route, FusionPBX won’t know what to do with them.  While, in theory, I could set up a separate Inbound Route for each extension, it would be much easier to have one Inbound Route to handle calls to all extensions, and it turns out that is possible.  However, there’s a small issue on the way to making that happen.

Let’s say that I tried to set up an Inbound Route that would handle only extension 9999 (I would not really give an extension the number 9999, but that’s not what I really want to do anyway, so it doesn’t matter at this point).  You would think that I could set up an incoming route for a single extension, like this:

FusionPBX Inbound Call Routing – Attempt to add 4 digit extension

The problem is that at some point in the past, some code was inserted that won’t let that happen.  The reasons for it may not be valid any longer, but it still exists, and therefore when you click the Save button you get this error message:

FusionPBX Inbound Call Routing – Error message

I am told that this is something that will be fixed in the next release, because there is now no good reason for restricting an incoming number to 5 or more digits (also this error message lies – an attempt to use a five digit number gets the same error.  You have to use a six digit or longer number to avoid the error).  Now, those of you who have read my rants about “The Software I Have Come To Hate” know that one of my pet peeves is its syntax checking, and the fact that it won’t let you do things that are perfectly valid as far as the underlying PBX software is concerned.  The difference is that the other software attempts to actively thwart you in any attempt you might make to bypass its syntax checking (unless you bypass that software altogether and write custom dialplan), whereas in FusionPBX a message like this is only a minor inconvenience.

So let’s try that again, this time using a six digit number to get past the error message:

FusionPBX Inbound Call Routing – Add Route using 6 digit number

After clicking “Save”, it shows up in the list of Inbound Routes:

FusionPBX Inbound Route List showing 6 digit inbound route

FusionPBX Inbound Call Routing – Inbound Routes List

Of course, this is not what was actually desired, for three reasons. First, the destination that was picked wasn’t actually a valid one — “transfer” is specified as the Action, but it doesn’t specify where the calls should be transferred.   Second, the number of digits is wrong (6 vs. the desired 4) and third, the route should accept a range of incoming numbers (any four digit number, not just 9999) and send those calls to the correct extensions. Fortunately, all this is actually possible!

Clicking on the icon to edit the Inbound Route that was just created will bring up a page that is labeled Dialplan for some reason (why is it not called Edit Inbound Call Routing, just for the sake of consistency?):

FusionPBX Inbound Call Routing – Edit Route

Note the Conditions and Actions lines at the bottom of the page. They correspond to individual lines in the relevant FreeSWITCH configuration file, and note that each one can be edited individually by clicking on the edit icon next to the line!  In this case, both the second and third lines are wrong, so those two lines both need to be edited.  For example, the second line (the destination_number) can be edited as follows:

FusionPBX Inbound Route Dialplan Detail Edit screen

Here a digit “6” in the Data line regular expression has been changed to “4“, making the new string ^(\d{4})$ to allow four digit numbers, thereby vanquishing the syntax checking error (for those that may not be regular expression experts, everything between the parenthesis is evaluated and captured, and placed in a variable called $1, which is used in the next rule).  Clicking the Save button brings back the Dialplan screen, and then clicking the edit icon next to the third line (transfer) brings up this page, which is edited as shown:

FusionPBX Inbound Route Dialplan Detail Edit screen (second edit)

What got changed here was the Data line, to $1 XML default.  By using the $1 variable, which was set by the regular expression in the previous rule, it allows any incoming number from 0000 through 9999 to be sent to a corresponding extension number, if one exists.  And how did I know to do that, you might ask?  Well, I didn’t.  I got a little help from mcrane (the FusionPBX author) in the #fusionpbx IRC channel.  Making both these changes allows direct incoming calls to four-digit extensions from another server on the same network.  After clicking Save, the Dialplan page reappears, where a couple more changes are made:

FusionPBX Inbound Call Routing – Edit Route (4 digit extensions)

In the above, the Name has been changed to 4-digits, the Number to 9999 (I don’t think what’s in those fields really matters once the Conditions and Actions have been changed, but I could be wrong, and it’s good to have something relevant in the Name and Number fields), Continue has been set to false, and a Description has been added.  After making these changes and clicking Save, this page reappears, showing that the Inbound Route has been entered correctly:

FusionPBX Inbound Call Routing – Inbound Routes List after edits

I think the above illustrates two important points. First of all, in FusionPBX, you are not hamstrung by the author’s ideas about what you should or should not be able to enter. If you know what you are doing, it’s easy to get around any syntax checking issues. And second, you probably won’t need to resort to something akin to writing a custom context in an Asterisk-based installation just to get around one small bit of dialplan that’s not doing what you need it to do. I’m sure there may be situations where it’s not this simple, but if you feel like your current software sometimes treats you like an idiot and insists on holding your hand (and occasionally slapping it) even when you know what you’re doing, then maybe you should check out FusionPBX.

Now, if you are used to using certain other software, you may notice that there’s no field for a Caller ID number, so you might think that you can’t route calls according to the Caller ID number, but that would not be correct.  Let’s take a look at how that might be done.  From the page that lists the Inbound Routes (the page shown in the image just above), click the icon with the + on it to add a new Inbound Route.  When that screen comes up, you could start by filling it in as shown here:

FusionPBX – Creating an Inbound Route that uses the Caller ID number

This assumes that 5551212 is the CallerID Number we want to trigger on, and that we selected Extension 1000 as the destination from the dropdown in the Action field.  If we just saved it this way and didn’t do anything else, it would be wanting to trigger on calls with a DID of 5551212, which is not what we want in this case.  So we would click the Save button and then when the page that lists the Inbound Routes comes up, we’d find the newly-created Inbound Route and click the edit button next to it, which would show this page:

FusionPBX – Editing an Inbound Route that uses the Caller ID number

Under “Conditions and Actions”, you can see that the second line shows the correct number, but not the correct type – the destination number (DID) is not the desired criteria to use as a condition in this situation.  Clicking on the edit button next to that line brings up this page:

FusionPBX – Editing an Inbound Route that uses the Caller ID number – changing Dialplan Detail

As you can see, clicking on the “Type” dropdown on this page reveals that it’s not only possible to use the CallerID number as a way to determine where to send a call, but there are many other choices as well!  Do you suppose that being able to route by CallerID Name might be useful sometimes?  Or that maybe there might be a need to examine a field in the SIP INVITE packet for routing purposes?

One other thing I’ll mention about the above page — in the Data field (which is obscured by the dropdown menu in the above screenshot), the pattern shown is ^5551212$ BUT this could be changed to any regular expression.  So, you could trigger on the CallerID number and then look for a pattern of invalid numbers (for example, numbers with “area codes” that begin with 0 or 1), and send such numbers to hangup or some other “black hole” destination on your system. Anyway, after changing the Type and saving the change, we wind up back at the “Dialplan” screen:

FusionPBX – Inbound Route that uses the Caller ID number now works as intended

And now the Conditions and Actions section shows the correct Type on the second line.  I will also point out that at the right hand side of that section, there is an Add button, which means you could add additional conditions.

While this may not be exactly what you are used to, it may well offer more flexibility than the software you are using now.  The ability to trigger on Caller ID name is a feature I’ve wanted for dealing with certain annoying “spam” callers that seem to have a multitude of phone numbers, but that are “nice” enough to always use the same Caller ID name.

For more information on Inbound Routes, see the following FusionPBX Wiki pages:

Inbound Routes
Getting Started

If you can add to our knowledge about Inbound Routes in FusionPBX, or can help clarify anything in this article, the comment section is open.

Next article: FusionPBX Basic Configuration: Using Google Voice

1 Comment

  1. Bill said

    Thanks. I’m enjoying the series.

RSS feed for comments on this post

Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 136 other followers

%d bloggers like this: