Evaluating CallerID (CID) based solely on the number is a design flaw of FreePBX. At FreePBX’s heart it relies almost exclusively on the CID number instead of the CID name. Their design makes little allowance for evaluating the CID name. The Dynamic Route module changes this, as it allows you to evaluate the caller by looking at the name, and then allows you to route based on that (on either that alone or together with the number).
There’s a feature in the Inbound Route and the Ring Group (and maybe others) that allows you to set the CID Prefix (their description is “You can optionally prefix the CallerID name. ie: If you prefix with “Sales:”, a call from John Doe would display as “Sales:John Doe” on the extensions that ring.”). Another example might be to have it show the last 4 of the DID. This would allow someone who needs to respond differently to various DIDs to do so.
There’s a problem with the logic behind this in how FreePBX applies the CID Prefix. If you set the CID Prefix in the Inbound Route it changes the CID name string, and any evaluation of that string can be different depending on the which number a caller came in on. This can and will interfere with future evaluations of that string for modules such as Dynamic Routes. An example of that interference might be that you add the last 4 digits of the DID, and when using regex in the dynamic route it evaluates differently. Let’s say months or years later someone alters the Inbound Route CID Prefix and that person isn’t aware that they need to change the Dynamic Route query to reflect the changes in the CID Prefix.
Because of the way that the CID Prefix works (when set in the Inbound Route) using the CID name to evaluate it in the Dynamic Route will cause the evaluation to fail. For instance, I have an MySQL database with blacklisted callers based on their name. I use a select statement to pull the record from the database via the Dynamic Route module. If the Incoming Route CID Prefix has been added/changed then the Dynamic Route SQL Select statement will not match the name in the database, and hence the results will always show a non-match and the whole purpose behind that becomes pointless.
Adding a CID Prefix on the Inbound Route while evaluating only the CID number does not cause it to fail — as it does not modify the string of the number.
As you can see this is a design flaw. The assumption is that the name is never part of the evaluation process. This is wrong.
In today’s world where anyone can set up an Asterisk server and configure their CID to spoof it, the name becomes increasingly important. We need to be able to evaluate the CID name instead of, or in addition to, the number. If we can’t evaluate the name instead of only the number we’d end up with a list of spoofed numbers resulting in an incredibly long list of numbers that really shouldn’t be in the list. Using a Dynamic Route with an SQL database back-end where you add names to the database becomes more important than ever as it allows us to evaluate the names instead of relying on that spoofed number.
It is difficult to know where the flaw actually manifests itself. Did they really mean to alter the CID name using the CID Prefix at this point in the call’s flow? It’s hard to know if this is solely a Dynamic Route module, an Asterisk or a FreePBX flaw.
If you design your FreePBX system to have an Inbound Route CID Prefix this changes the CID name string, and if you have a back-end database (such as mysql) or even use regex to evaluate the CID name, your evaluation will fail, unless you add a bunch of complexity in the design of the Dynamic Route. For instance, you’d need to have a different Dynamic Route for any given Inbound Route.
Let’s say you have a CID prefix of “2293:” for the phone number ending in 2293. The name would be changed by this to have 2293: <CID name>. When evaluating that against the database or regex expression it will fail. If you have a second Inbound Route based on another number (ending in 2233) you’d then need a different set of Dynamic Routes based on that. See what I’m getting at? You add more dynamic routes that have to evaluate the CID Prefix in conjunction with with the CID name. If you have a 3rd number or more you’d have additional complexity. It would be possible to use an OR operator in your dynamic route evaluation string, but that adds even greater amount of complexity.
The only time using a CID prefix works (without adding a bunch of this complexity) is after the Inbound Route — after any evaluation based on the name. There is a CID Prefix also in the Ring Group. If you add it here the CID Prefix won’t be evaluated. If you refrain from adding it to the Inbound Route CID prefix you may not have all the information that you want displayed on your phone’s display.