I'm just going to throw this out there and see if anyone else thinks it's a good idea. A lot of FreePBX users are using the Custom Contexts module when it's overkill for what they really want, which is number translations and restrictions on a per-extension or per-group-of-extensions basis. So I will propose a simplified module that creates translation/restriction sets. In the extensions configuration, each extension could optionally specify one (and only one) pre-defined translation/restriction set, using a drop-down menu. The set chosen would affect outgoing call placed by that extension only, and would never affect incoming calls. Other than extensions, the only other thing this module might possibly interact with is DISA, since it also allows outgoing calls.
The new module would allow users to create translation/restriction sets. Each set would filter outgoing calls based on dial patterns BEFORE those patterns are sent to the outgoing route logic. On the translation/restriction set page, each filter would be added one at a time (press submit after each addition) and existing filters would be displayed with a checkbox next to each; you could click a checkbox and then a DELETE button to delete existing filters. There would also be a place to name the translation/restriction set (this would then appear in the dropdown on the extension pages) and also a "destination if call blocked" selection area (which would show all the standard destinations known to the system).
When adding a new filter, there would be two text fields, one for the number to be matched - this would be the actual number that the user might dial - and the second box would be for the translation, if any. Some examples might be in order:
1XXXXXXXXXX | (Blank entry) - deny access to any 11 digit number starting with 1
1800NXXXXXX | # - If found in the second field, # would override any restriction for numbers matching that pattern, in other words this would say that calls to 1-800 numbers may go through despite the presence of the filter in the previous entry.
411 | 18005551212 - if 411 is dialed, translate it to 18005551212 (this is just an example, not something you'd actually want to do)
911 | (full 11 digit number for local 911 center) - this could be used if you have a remote extension and know the appropriate 11 digit number for their local 911 answering point (e.g. the one that the smaller cell phone companies use when sending calls to that 911 center).
As you can see, this is a very simplified pattern matching system. The first field can contain either a number or a pattern. The second field can contain a number, a # (which means to pass numbers matching the pattern unchanged despite any other less specific rules) or be blank, which means that call should go to the "blocked calls" destination.
Possible enhancements on the basic idea:
Now there is another thing that could be added to this, though I only throw this out as an "if it takes less than five minutes to code" idea, because probably not that many people would use it, but those who might want it would really appreciate it. And that is, you add a third field to set the outgoing caller ID. If left blank, it takes the Caller ID set by the extension, but if it is set then on calls matching the pattern in the first field it sets the outgoing Caller ID to the name and number in the third field. So you could do something like this:
1212NXXXXXX | # | My Big Company <2125552368> - to show your company's local 212 number on calls to the 212 area code
911 | (full 11 digit number for local 911 center) | {another local number at same location that is already in 911 database)
The beauty of this (I think) is its simplicity -- it simply sits as a shim in the outbound call flow and does nothing but number translations/restrictions. If you don't want someone to have access to a particular route, you simply include the same dial pattern definitions that are in that route (or something a bit more generic). Note that this is not nearly as flexible as Custom Contexts - for example, as described so far, you could not send some extensions to one route for a particular pattern and others to a different route. However, if you wanted that flexibility, an easy way to add that would be to allow digit prepending in the second field - this would increase the complexity of the code a bit, however. As an example:
1NXXNXXXXXX | 000001+#
In this example, whatever is before the + sign would be prepended to the original number (indicated by the #) before it is sent to the route logic. Now you could create a route that looks only for patterns starting with 000001 and strips those digits before sending the call to a trunk. So in this example, any call to a NANP number could be sent to a route that ONLY accesses "free" or low-cost trunks, and the route would strip the 000001 before sending to the trunk (using 000001|1NXXNXXXXXX in the dial pattern, for example).
The biggest advantage to this method is you don't have to worry about the priority drop-downs as you do in Custom Contexts, and also this is a far simpler method of achieving what (I would guess) the majority of Custom Context users really want, which is to be able to set up number translations or restrictions for a single extension or a group of extensions. By creating these definitions in such a way that they can be easily applied to one or more extensions, you would gain much additional flexibility.
One additional suggestion - On the page for each translation/restriction set, include a "clone" button that would simply create a new translation/restriction set already populated with the same data as the page you are on - that way, if someone builds a set with a number of entries and then only has to change one or two items for a particular extension, they don't have to re-enter all the data.
Also, I have suggested using two or three text boxes to enter each new filter: One for the number or pattern to match, one for the translation (which is left blank of the call is to be blocked), and perhaps one for a changed Caller ID (if relatively trivial to include). This would allow more "sanity checking" on each item, at the cost of not allowing the mass copying of filters from one FreePBX installation to another. There may be a better way to enter the filters, particularly in large installations, so I will just say upfront that it matters not to me how these filters are actually entered, as long as they can be.
Just an idea, and please keep in mind that some users probably would prefer to keep using Custom Contexts so it's not my intention to "break" that module. It's just my impression that Custom Contexts offers too much flexibility for some users and is a bit daunting to set up and maintain, particularly when you have to explicitly set a priority for each item.
