Somewhere in FreePBX 2.7 or thereabouts, it became know that there was a feature of FreePBX Outbound Route dial patterns, were you could use a /CallerID extension. This (among other things) basically lets you limit the use of an Outbound Route to a particular extension or group of extensions. It’s a very useful feature, but wasn’t widely announced or promoted at the time. I finally figured out why.
Thing is, it’s NOT a FreePBX feature, it’s a feature of Asterisk. Anywhere in an Asterisk dial plan where you have a line that starts with
exten => _somepattern,…
you can use the Caller ID modifier, like this:
exten => _somepattern/callerid,…
In which case the pattern won’t be matched unless the current Caller ID number (which on an internal call is the number of the calling extension) matches whatever you’ve replaced callerid with. Callerid can itself be a number or a pattern.
The real kick in the head is that it appears this feature has been around for a LONG time. It was definitely in Asterisk 1.4. Yet virtually none of the documentation you see on Asterisk even mentions this feature. It might as well have been an “Easter Egg” hidden in the software, for all anyone knew of it. Well, I finally figured out why — the Asterisk folks hung a “cute” name on it, and it stuck.
They called it ex-girlfriend logic. The idea is that you can use it to stop an ex-girlfriend from bothering a particular user on your system (at least in raw Asterisk, though I don’t think that’s directly supported in FreePBX). Besides being a bit sexist, it’s also about the last terminology anyone would think to Google on if they were trying to find out about this feature. So while people were writing third-party modules like Custom Contexts and Outbound Route Permissions in FreePBX, it now turns out that essentially the same basic functionality was there all along, but hardly anyone (at least in the FreePBX world) knew about it until around about the time of FreePBX 2.7 or so. If you can find anything at all about this feature in “official” Asterisk documentation (that doesn’t include third-party sites!), you’re a better searcher than I.
Makes you wonder if there are any OTHER cool features in Asterisk that are hidden in plain sight, under unfortunate descriptive names that no one would ever think to use when searching for such a feature!
Want some technical info why I didn’t use that back when I wrote routepermissions?
Because it makes a REALLY MESSY dialplan.
Also, back then you couldn’t use wildcards when matching CIDs, which I believe you can now.
exten => 200/123,1,Do stuff
exten => 200/123,2,Do more stuff
exten => 200/123,3,Look. Stuff to do.
exten => 200/124,1,Do stuff
exten => 200/124,2,Do more stuff
exten => 200/124,3,Look. Stuff to do.
exten => 200/125,1,Do stuff
exten => 200/125,2,Do more stuff
exten => 200/125,3,Ooh Different stuff.
… and so on.
And from my perspective, the maintainability of that would have been impossible. With routepermissions, you assign a permission at the extension level, rather than messing around with trunks.
But. You want something else cool? Hmm. How about, if you’re well and truly sick of ‘Comedian Mail’, you could roll your own now. Check all the ‘Minivm’ functions. ‘core show application minivm[tab]’
Rob,
The problem is that each method has its advantages and drawbacks.
The big objection I always had to Custom Contexts, besides the fact that it wasn’t exactly the easiest thing to figure out how to use, was the infernal priority dropdowns. If you added a new Outbound Route, then you had to go through and change all the stupid priorities in every one of your Custom Contexts. I hated that for the same reason I hate the new method of entering Outbound Route patterns – it turned something that should have been easy into something that could be a very cumbersome process, where you were mostly doing repetitive “grunt work” that required no creativity whatsoever (which meant I’d probably screw it up, because after the third or fourth time my mind would be far, far away).
Your Outbound Route Permissions actually wasn’t a bad solution at all, and I used it on our Asterisk 1.4 box (finally retired a couple of weeks ago) for MANY months. The problem seemed to be explaining how to use it to other people. To me it all seemed quite intuitive, but other people would look at it and for some reason just couldn’t visualize the call flow. I imagine some of those people won’t “get” the /CallerID syntax either, but to me it seems easier to explain to others, even though I’m comfortable using either method. Also, until you updated the module yesterday, I wasn’t sure if compatibility would be maintained with future FreePBX releases. I think there’s certainly still a place for that module, but as with many things in life, where there is a choice of tools to do a job, some people will feel more comfortable using one than another (and some will pick the wrong tool for the job due to lack of experience, but what can you do?).
What I really wish the Asterisk folks would do is expand the syntax to allow multiple CID definitions. To play off of your example:
exten => 200/123&245&_3XX,1,Do stuff
exten => 200/123&245&_3XX,2,Do more stuff
exten => 200/123&245&_3XX,3,Look. Stuff to do.
That would mean that the dial plan would be executed if the Caller ID was 123, 245, OR any extension in the _3XX range. That way, you could specify multiple extensions or groups of extensions even if they did not share a common pattern. I don’t venture into the Asterisk forums, so if anyone would case to put in a feature request for this, please feel free — I don’t care who gets the credit for suggesting the feature.
Thanks for the history lesson.
Quote:
“the … Caller ID … which on an internal call is the number of the calling extension”
This is often, but not always, true. I have been burned by this thinking in the past. Given the lack of documentation for this feature, I am quick to point out that it is easy (and in many cases desirable) to modify the Caller ID of an extension so that it is different from the extension number. If you have an extension defined, and the Caller ID field is populated with a value other than the extension number, then you can expect rules as described above to follow the Caller ID of the extension, not the extension number.
L Gaetz: Actually, I was burned by that once also. I have two systems I’m involved with, and until a couple of weeks ago one of them was still running Asterisk 1.4. So, I simply shipped all Google Voice traffic to the other (1.8) system to let it handle it. Of course, on that system I still had to break out the outbound routes by Google Voice accounts.
Can you guess the problem? Once the calls left the 1.4 box, they bore the Outbound CID assigned to that extension. So on the 1.8 system, I had to use THAT after the forward slash, rather than the extension number. When I first set that up, it took me a few minutes to figure out what the problem was!
Quote:
“they bore the Outbound CID assigned to that extension”
Been there. Not sure when the checkbox for “intra-company route” showed up in FreePBX, but it nicely solves that problem (and introduces other ones)
NOTICE: All comments above this one were imported from the original Michigan Telephone Blog and may or may not be relevant to the edited article above.