Basic usage of route prefixes to reroute calls from specific extensions

This document is to explain the usage of route prefixes to select a specific route for outgoing calls. It assumes you already have a good working knowledge of how FreePBX Outbound Routes and Trunks work - if your not certain of that, you may want to read Hints on Route Dial Patterns and Trunk Dial Rules before reading this document.

In the old days of telephone-company supplied PBX's, it was a common practice to require PBX users to dial "9" to get an outside line. Although you may not have viewed it this way, this was an early example of using a prefix to select a route - in this case, a route for local outgoing calls. By the way, it's no longer considered good practice to require users to dial a prefix for local calls, but you still find this relic of the past on many existing PBX systems.

Sometimes a company would purchase a "foreign exchange" (FX) line in another city. For example, a company in Detroit that had many customers in Windsor, Ontario might purchase a Windsor FX number. It would be set up to use a different prefix on the PBX, so employees might dial "9" for a local call in Detroit, and "8" for a local call in Windsor.

In a similar manner, a company might have wanted a line specifically dedicated for the use of certain executives. This might be "hidden" behind a code that regular employees weren't supposed to know. For example, dialing "77" might give the executives access to "their" line.

Note that in all cases, the routing prefix could not conflict with any other number in the user's number space. For example, if you used three digit extensions in the range 100-899, then you couldn't use "8" or "77" as dialing codes. You might have to use something like "99" for local calls, "98" for the FX line, and "977" for the "secret" trunk.

All of these were examples of using a prefix to route calls at the time of the call. The problem, of course, was that employees wouldn't always use the correct prefixes. The employee in Detroit might dial 9+1-519-NXXXXXX (where NXXXXXX is the local number) to place a call to Windsor, effectively making an expensive international call instead of a cheap local call. Or, a bored regular employee might start dialing random digits and discover the bosses' "secret" line. So, as soon as electronic switching came into use, methods were devised to take control away from the end user and put it in the system itself. The user would simply dial the number; the system would figure out how to route it (and whether the user should have access to any "special" trunks).

Now, one thing FreePBX excels in is selecting trunks based on the pattern dialed. And if you really want to (and still have your head stuck in the 1950's), you can still use the old-style manual prefixes with FreePBX. For example, if someone dials 9+1-800-555-1212, you can easily strip the 9 at either the route or trunk level (for now we will concentrate on routes). So in your route, you might have a pattern like 9|1800NXXXXXX, and similar patterns for other toll-free prefixes. Numbers before the | character are not sent to the trunk, so the 9 would be stripped off.

But, we don't NEED to use prefixes to select routes. Suppose we were actually replacing an old PBX in Detroit, and we brought the Detroit number into FreePBX on a ZAP/DAHDI channel, and the Windsor FX line in on on a second ZAP/DADHI channel. We'd have a trunk for each channel, and a route for each trunk. We'd then use a pattern like 1313NXXXXXX and/or 313NXXXXXX in one route to send Detroit area calls to the Detroit trunk. We could use patterns like 1519NXXXXXX and/or 519NXXXXXX in a different route to send all area code 519 calls to the Windsor trunk (I know that doesn't take into account that not all area code 519 calls are local to Windsor, but this is just an example).

So, users are relieved of the burden (or responsibility, depending on your point of view) of selecting the correct trunk for calls to a specific area. The system does that for them. And as noted above, out of the box FreePBX handles this very well.

The problem is that if we want to give a specific user's calls (or the calls of a group of users) different handling, up until recently there's been no way to do it natively in FreePBX. Sure, we could set up a manual prefix that the executives would dial to access the "boss route" and then strip it at the route level, but these are busy people (in their own eyes, anyway) and don't want to be bothered dialing prefixes. The problem is even worse if you have different departments that use different groups of trunks - sooner or later someone in one department will find out the "secret" dialing prefix that the other department's employees are supposed to use, and mischief will result.

Now you may be thinking ahead a bit and realize that if forcing users to dial 9 for a local call is no longer acceptable practice, then you need some way to distinguish between calls that stay on your system and calls that do not. In North America, many system administrators have adopted the practice of numbering all local extensions starting with 11 or 10, because no area code begins with 0 or 1. So, extensions might be numbered from 1000 through 1199, which allows for 200 extensions (and no conflict with any ten or eleven digit pattern used for "outside" calls). If you don't have anywhere near 200 extensions (and don't expect to), you might appropriate some of those unused extension numbers as dialing prefix codes. But that assumes that users would actually be dialing those codes, and that exactly what we'd like to avoid. (By the way - consider this a slightly off-topic sidebar - you can also use dialing timeouts on local extension numbers, and use the # key as a shortcut to avoid the timeout, which actually gives you more available extensions for the same amount of button depressions - but some people just can't seem to get the hang of pressing the # key at the end of a local extension number).

In any case, the principle is this. By default, if you dial a particular "outside" number, it will go out on the route that matches that pattern exactly, and that route would select one or more specific trunks. But you could have a second route, with the same dial patterns except prefixed by (for example) 1199| and then if someone dials 1199+that same "outside" number, the call would go out that route, the prefix would be stripped and the call would go out the trunks associated with that route. And you could have as many additional routes and route prefixes as you need.

If you're still following along at this point, let's now consider this: Suppose the user didn't have to dial the route prefix? In many endpoints, you can set up the dial rules so that if you dial a specific pattern, it will prepend a prefix before sending it to FreePBX. Since the user isn't manually dialing the prefix, we can use something a bit longer and perhaps more obscure. For example, we might use something like 000001 to access the first alternate route, 000002 for a second alternate route, etc. Since no "normal" number in any country that we're aware of begins with that many zeroes, it's safe to use something like that as a prefix pattern without risk of conflicting with something a user might actually dial. This also makes it easier to actually key the prefix to a particular extension, for example a route specifically for use by extension 1123 could be given the prefix 000023 (or even 000123), which makes it a bit more mnemonic when you are trying to figure out which route goes with a particular extension.

But instead of forcing the user to dial this prefix, or programming it into each endpoint individually, we now have the option to do this directly from within FreePBX. Unfortunately, the methods to do this are not part of the "official" FreePBX distribution yet.

The easiest method is to use the (at this point unsupported, third-party) Outbound Route Permissions module. When you use this module, it adds a new section to each extension's configuration page that lists each of your Outbound Routes. For each extension, you can allow or deny access to each route. But there is a third option - if you choose to deny access to the route, you can specify a "Redirect Prefix". This simply adds a route prefix to the number, the same as if the user had dialed it manually, and sends it back through the dialplan. So, you simply give "regular" users access to the "regular" routes, but deny access to the "special" routes (so even if they happen to know your internal routing prefix, it won't do them any good). Then you could give other users access to the "special" routes, but deny them access to the "regular" routes, while using a "Redirect Prefix" so that when they dial a call normally associated with that (regular) route in the normal manner, it will prepend the prefix and send the call through the system again, so the call will be processed just as if the user had dialed the prefix manually.

Now you may be wondering why you need the prefix at all - if you deny access to one route and use the same dialing patterns in another route, won't the call go out over the second route without the prefix? Well, we might wish it worked that way, but it doesn't. Remember that we are using Asterisk underneath FreePBX, and Asterisk doesn't work that way. At the ROUTE level, all numbers must be unique - if two routes have overlapping patterns, Asterisk will only match on the first.

So what you do is, you prepend the routing digits - but you let FreePBX do it instead of requiring the user to do it - and then send the call through a Outbound Route that strips the routing digits before sending the call to the appropriate trunk(s).

There are other methods to accomplish this. Instead of using the Outbound Route Permissions module, you can manually add the prefix using code in extensions_custom.conf - see How to give a particular extension different or restricted trunk access for outgoing calls for details. And, there is a third-party, unsupported Custom Contexts module that uses a different method of route selection. That module arguably allows more precise control, but many users (including the author of this document) find it more difficult to use if all you want to do is change the route access for certain extensions. Plus, the author of that module apparently has not had the time or interest to keep it updated, and there have already been issues with it not working after a FreePBX version update, although a patched version was released that corrected that issue. It is a more powerful module, but very few users really need all the functionality it provides (again, in the opinion of the author).

I hope this document has helped you understand a bit of the theory (and history) behind adding a prefix to certain calls to force them to use a particular Outbound Route (and, therefore, a particular trunk or group of trunks), and how this can be used to our advantage to force calls from a particular extension (or group of extensions) to use certain specific trunk(s) instead of the default trunk(s).

Note that although this document describes the rerouting of calls from particular extensions, the same technique can be used in other situations. As an example, one user had calls for two companies coming in on two different DID's, but at night they wanted to forward the calls to an answering service. In order for the answering service to get a different Caller ID for each company (so they could answer the call using the correct company name) it was desired to send the calls for each company out via a different trunk. But, FreePBX would only use the first Outbound Route that it found that matched the pattern for the answering service telephone number.

Originally, at night the calls were being sent to a single Misc. Destination that went to the answering service telephone number. Let's say that the answering service number was 5552368. Instead of making a single Misc. Destination forwarding to 5552368, the trick was to make two Misc. Destinations using (for example) 0000015552368 and 0000025552368 as the respective destinations, the creating two new Outbound Routes, with 000001|5552368 as the dial pattern for the first route, and 000002|5552368 as the dial pattern for the second route. Each new Outbound Route was set to select the correct trunk (a different one in each of the routes), and both Outbound Routes were placed higher in priority than the "general" Outbound Route that would normally handle calls to 5552368. Then, all that was left to do was to send each DID to the correct Misc. Destination (using a Time Condition) at night.