In larger installations you often find the problem of employees or guests picking up one of your internal extensions and dialing one of you main DID numbers. The usual reason for this is that they know how to navigate your IVR menus, but don't necessarily know the direct internal extension number of the person or department they wish to reach. Human nature being what it is, they take the path of least resistance and dial your external number, which by default will use two external voice channels and possibly even two trunks, for which you might be charged per-minute usage rates (depending on your provider).
If you have registered all your DID's with an ENUM registry, such as e164.org, then you can simply make your ENUM trunk your first choice for all outgoing calls, and the calls should come right back to your system (in effect never leaving your FreePBX box). But what if you have never registered your numbers with an ENUM registry, or for some reason it's not working as you think it should? Well, here's an alternate method that is easily changeable as you add or remove DID's:
First, create a CUSTOM trunk. For the Custom Dial String, use this:
Local/$OUTNUM$@from-trunk
In the Dial Rules, make adjustments for any differences between the way you would dial the number, and the DID your provider sends. To illustrate what I mean, let's suppose that you are in the United States and allow 7 and 11 digit dialing of local numbers, but your provider sends a 10 digit DID. Let's further assume the DID is 9998675309, so internally people might dial 1-999-867-5309 or just 867-5309. So in your trunk Dial Rules you might have this:
1|9998675309 999+8675309
The idea is to convert whatever people might dial internally to match the DID your provider sends, so that it will be recognized as a valid DID for an inbound route. I do suggest doing each DID separately rather than using a pattern that fits multiple DID's because someday you might get a DID from a different provider that sends DID's in a different format (perhaps eleven digits rather than ten) and this would "break" your generic patterns - however if you plan to use only one provider and have many DID's from that provider, you could use more generic patterns such as (in keeping with the above example):
1|NXXNXXXXXX 999+NXXXXXX
Second, create a new Outbound Route. Name it something like Local-DID-Loopback, check the Intra Company Route box if you want looped calls to show the local extension number in the Caller ID (you probably do want that), and then in the Dial Patterns simply list all your DIDs as people might dial them from inside your system. So, again in keeping with the above example DID of 999-867-5309 and your system allowing 7-digit or 11-digit dialing, you'd use the following Dial Patterns:
19998675309 8675309
In case you are wondering, you could strip the leading 1 (in this example) in the route Dial Pattern, for example using 1|9998675309 - it would make no difference whether this is done at the route or trunk level. As your final step in creating the route, you'd simply select the CUSTOM trunk you created in the first step as the only available trunk for calls using this route.
Note that after you submit the changes for the route, you need to move it to a higher priority than your normal routes that would otherwise handle these calls, so keep clicking the up-arrow next to the route name until it is higher in priority than any of your other routes (except for your emergency routes, which should always have the highest priority). Then click the orange "Apply Configuration Changes" bar to make your new trunk and route active.
The method shown above may be a bit more difficult to set up initially, but it is the easiest to reconfigure as you add or remove DIDs. However, perhaps you prefer a more direct approach - or maybe you want special routing of such calls (maybe you want to send them to a recording that says "Stop being lazy, and look up the extension number!", or perhaps something slightly more helpful). What you could do is create one or more new Misc Applications. In that case, you'd make the Feature Code of each Misc Application the DID number as your users would dial it internally (not necessarily the DID) - so if we again use the above example, we'd have to create two new Misc Applications, one using 19998675309 as the Feature Code and the other using just 8675309 as the Feature Code. Then you just send each number to the destination you prefer, whether it be your main IVR, a recording, or some other destination.
There are two problems with this method - it gets a bit unwieldy to maintain if you have more than a handful of DID's, and perhaps more significantly, it doesn't automatically track changes you make in your Inbound Routes. That's good if you want to give calls to these numbers different treatment than what outside callers would receive, but bad if you want callers to get whatever an outside caller would get when dialing one of your numbers.
Even if you use another method to handle your DID's that are associated with Inbound Routes, this method can be used to handle numbers for which you don't have a DID/Inbound Route. For example, if you have a provider that lets you have more than one number associated with a trunk, but regardless of the number dialed always sends the same DID, you may not have an Inbound Route for the other number(s) associated with that trunk. You could use the Misc Application method to intercept and reroute those secondary numbers, if dialed from an internal extension.
Using any of the methods mentioned above may help save your bandwidth, and possibly some money that would otherwise be paid in unnecessary per-minute charges!