I have an idea for a module. Before I propose it, please note that this is simply a suggestion if someone would like a project that might actually be useful. Personally, I would only be using this on a home system, and I don't actually need this module because I can do the same thing using custom dialplan, but that's possibly not something the average user would be able to do. As far as I am concerned, this is just an idea that I freely offer to whoever might want to run with it.
The basic problem we have today is that we can only blacklist calls by number, and only for the entire system. Before the big forum crash, with the help of lgaetz, TSM, and tm1000, I wrote some modifications to the Swiss Army Knife module to also allow blacklisting by Caller ID name. You can see these modifications by going to this page on Github but the reason it is labeled as NON WORKING CODE is because it requires a patch to FreePBX that most users won't have, though it hopefully will be available in future versions. But even that applied to all calls into a system.
BUT - there may be times that you want to give specific treatment to individual callers, but only in certain circumstances - for example, when they have called a specific DID or group of DID's.
So my idea is this: Build module that can create individual "special routing lists" that are themselves destinations. They would conceptually be somewhat similar to Time Conditions, in that you could create as many as you need and give each one a name. Each "special routing list" would contain either a list of caller ID names, caller ID numbers, or caller area codes - the latter would only compare the first three digits of a ten digit caller ID, or the three digits after the "1" in an eleven digit caller ID number that starts with "1".
Each time you create a new list, you would specify the name of the list, and the type of list - one of the three I just mentioned, though maybe other types could be added later. You could also optionally specify an extension number to associate with the list - more on that in a moment - and a description.
Then after creating the list you would populate it with numbers, names, or area codes. At the bottom of the page, just as with a time condition, there would be two sets of destinations - one to be taken if there is a match with an item on the list, and a default destination to be used if the number is not on the list.
Note that you could chain lists together, that is, make one a destination for another. So, just as an example, you could have a whitelist - calls that are put through immediately. You could then chain that to a blacklist - calls that are never to be put through. That could in in turn chain to a graylist, which might be a list of all toll free area codes, which you might send to something that makes the caller prove it's a human and not a robocall. And if it passes all those tests, meaning it's an unknown caller but not from a toll-free number, you might send them first to an announcement that says "This call may be monitored or recorded" before sending it to the desired extension, because that tends to scare off sales droids and others that wouldn't want you to have recorded evidence of the call. These are just examples, of course - you could pick any destinations you want for any of the lists.
Each list would itself be a destination, just like any other destination. Normally you might send one or more inbound routes to such a list, and then chain the call flow through as many lists as you need, with the last one having a default destination of your choosing.
I mentioned optionally associating each list with an extension number. Doing so would have no effect on call flow. Instead, what it would do is make the number, name, or area code list visible and available for editing in the user portal. Each user would see a list of the routing pages associated with their extension and the descriptions, and could add, remove, or edit numbers on the list. I don't know if it would be a good idea to allow them to modify the destinations (probably not) but really, that is up to whoever might create such a module.
If I were writing it I would store the lists in the Asterisk database, not in MySQL, and also I would avoid using AGI calls like the plague in order to minimize lookup time, which could be important in situations where more than one of these are chained. But, that is just me. If you write it, you can do it however you want. Again, it's just a suggestion, in case anyone might be looking for a project. And if by chance such a feature is already present in a new or upcoming release, then I apologize for wasting everyone's time.
The basic problem we have today is that we can only blacklist calls by number, and only for the entire system. Before the big forum crash, with the help of lgaetz, TSM, and tm1000, I wrote some modifications to the Swiss Army Knife module to also allow blacklisting by Caller ID name. You can see these modifications by going to this page on Github but the reason it is labeled as NON WORKING CODE is because it requires a patch to FreePBX that most users won't have, though it hopefully will be available in future versions. But even that applied to all calls into a system.
BUT - there may be times that you want to give specific treatment to individual callers, but only in certain circumstances - for example, when they have called a specific DID or group of DID's.
So my idea is this: Build module that can create individual "special routing lists" that are themselves destinations. They would conceptually be somewhat similar to Time Conditions, in that you could create as many as you need and give each one a name. Each "special routing list" would contain either a list of caller ID names, caller ID numbers, or caller area codes - the latter would only compare the first three digits of a ten digit caller ID, or the three digits after the "1" in an eleven digit caller ID number that starts with "1".
Each time you create a new list, you would specify the name of the list, and the type of list - one of the three I just mentioned, though maybe other types could be added later. You could also optionally specify an extension number to associate with the list - more on that in a moment - and a description.
Then after creating the list you would populate it with numbers, names, or area codes. At the bottom of the page, just as with a time condition, there would be two sets of destinations - one to be taken if there is a match with an item on the list, and a default destination to be used if the number is not on the list.
Note that you could chain lists together, that is, make one a destination for another. So, just as an example, you could have a whitelist - calls that are put through immediately. You could then chain that to a blacklist - calls that are never to be put through. That could in in turn chain to a graylist, which might be a list of all toll free area codes, which you might send to something that makes the caller prove it's a human and not a robocall. And if it passes all those tests, meaning it's an unknown caller but not from a toll-free number, you might send them first to an announcement that says "This call may be monitored or recorded" before sending it to the desired extension, because that tends to scare off sales droids and others that wouldn't want you to have recorded evidence of the call. These are just examples, of course - you could pick any destinations you want for any of the lists.
Each list would itself be a destination, just like any other destination. Normally you might send one or more inbound routes to such a list, and then chain the call flow through as many lists as you need, with the last one having a default destination of your choosing.
I mentioned optionally associating each list with an extension number. Doing so would have no effect on call flow. Instead, what it would do is make the number, name, or area code list visible and available for editing in the user portal. Each user would see a list of the routing pages associated with their extension and the descriptions, and could add, remove, or edit numbers on the list. I don't know if it would be a good idea to allow them to modify the destinations (probably not) but really, that is up to whoever might create such a module.
If I were writing it I would store the lists in the Asterisk database, not in MySQL, and also I would avoid using AGI calls like the plague in order to minimize lookup time, which could be important in situations where more than one of these are chained. But, that is just me. If you write it, you can do it however you want. Again, it's just a suggestion, in case anyone might be looking for a project. And if by chance such a feature is already present in a new or upcoming release, then I apologize for wasting everyone's time.