Why would this bug posted be marked as invalid. The order of checking makes the blacklist useless when the privacy manager is enabled.
If that is the case, why even have the privacy manger, I was under the impression it was there to help the blacklist when no CID was presented (as most telemarkerters hide it)…
To not even give it consideration is uncalled for…
I have seen several requests for adding notes to the blacklist numbers. However, Blacklist feature is based on the Asterisk function LookupBlacklist that uses astDB for storing the blacklisted numbers. It is stored as /blacklist/121212 : 1 where 121212 is the blacklisted number.
To be able to use notes in Blacklist an other function has to be developed that can hold notes together with the blacklisted number. If someone does that and provide the code for it, I am sure that we would look into integrate that into FreePBX.
You can implement the caller ID validation by defining a pattern in an inbound route and set the destination to an announcement of your choice. So as the last guy said, forget about that as every country has different patterns and you can accomplish this yourself already.
My suggestions are to allow more flexibility. A field to enter short notes on a number in the black list or date of when it was added might be handy.
The ability to be able to set a destination other than the default SIT tones for numbers in the black list would also be handy.
Yes you can blacklist a number using an inbound route and add notes to it, but that area gets cluttered up fast. I’d prefer to only use inbound routes for patterns (groups of numbers) not individual numbers.
The bug was closed due to the fact that it is invalid.
The call flow for an inbound route is detailed here:
The is NOTHING preventing the caller to enter a bogus CID and checking Blasklist after the caller have entered a CID is pointless.
You could use Call Screening defined per extension instead.
I can understand both positions and thus would like to allow for some discussion. My personal opinion is that blacklist is to block CIDs as delivered from the telco since users can input what ever they want in the privacy manager.
On the other hand, I can also see the argument that you may still want to blacklist a call based on CID once someone has entered that CID, even if they can easily call back and enter a different CID. (As they may not be smart enough to do that).
However, this opens up more questions (just to complicate matters). Once we obtain their CID, do we also now route the call based on that new CID if there is CID based routing setup? (Or maybe it already happens auto-magically - I’ve never tried. Given the way DID/CID routing is implemented there could actually be some very strange behavior that happens as a result of this - even in the current implementation).
Question is - if we move blacklist after privacy manager, are there other side effects that we are not considering. For example, we pickup a fax that we may have rejected?
Looking at the current flow, there is one thing I do believe should be changed: cidlookup should come after privacy manager. And I would say that the fact that it does not IS a bug.
So despite my opinion that it is probably fine as it it, I’m am open to discussion. I will also venture to say that moving privacy manager first would solve the cidlookup issue and have the by-product of the request for the blacklist change (if discussion points us in that direction).
No matter what, its not a bug if its by design. You can contest the design, but its not a bug by definition.
My initial reaction is that its poor design. However, that would mean interactively intercepting and then potentially going to a sit tone, not a good thing.
I think that everyone would be happy if the design afforded the flexibility to go either way. No one way is definitively right for every users situation.
-Ted-
I can see doing this either way. I don’t know how much good it will to to have someone manually enter what could be a bogus caller id and avert the blacklist.
If the goal here is to thwart telemarketers, have all calls to the DID with no caller id go to a special IVR, just for telemarketers with two choices, press 0 to enter the normal call route or timeout which hangs up. I have discovered that my inbound IVR eliminates about 95% of telemarketers, just because they are using auto-dialers and their computer doesn’t know that it needs to push buttons. To implement this, we would need code built into FreePBX to identify “no-callerid” and make it a choice in the inbound routes choices. I think Ward implemented a pretty good piece of code a couple of years ago to do that.
Well, I have to agree that allowing someone input their CID after receiving the call is clearly a loop hole in the system. Then again, a lot of the people you block like that aren’t too savvy or are machines. Of course, if we were to take a minor change, I’d say move the blacklist check after answering and allowing the caller to input a CID manually. At least you can go into your blacklist and put the all 0s and 12345 that tend to come through.
Now for an extra dollar, I’d suggest a different approach. Maybe change it to something like “CID Validation” and give you the option to enable it on the trunk, inbound route, or an extension. And give the admin more flexibility and it would give different avenues if say:
No CID Delivered / Blocked / Anonymous
Invalid CID (ie too short, doesn’t match NXXNXXNXXXX or 1NXXNXXXX, all zeroes, all 1s, etc.)
Out of Area (restrict incoming calls to a certain area code)
Blacklisted / Whitelisted
And the destinations could be something like:
Play “We’re sorry, you CID was not delivered properly. Please hangup, unblock your number, and try your call again” then hangup
Play “Your CID was not delivered. Please enter it so your call my be delivered accordingly” User enters CID, CID Validation is processed again.
The standard greeting if you’re blacklisted… “be-de-bee We’re sorry…”
If OoA Play “The number you called cannot be contacted from your area.”
Custom response “You’ve reach XYZ Company. Your CID was not delivered properly. As a security precaution, this call cannot be completed. Please unblock your number and call back. If you fell you have reach this record in error, please hangup and dial 678-555-1212 for customer service.”
I think something like that would be more useful, robust, easily replace the current outdated module, and should be very simple to code.
Just a few thoughts off the top of my head… Let me know what you think…
Marv
My concern is that FreePBX is used all over the world. In Sweden we have phone number that can be 04012345 (or even +4640123456) to 041081234567 and I am sure that there are a lot of weird phone number in the world that can end up in your pbx. So just detecting NXXNXXNXXXX or 1NXXNXXXX is not a valid solution. That would limit the function to US only. And to catch all combination could render a blacklist that is a mile long.
My vote is that we (as it is now) first check for a valid incoming CID, then act on it.
When the call goes to the Privacy Manager, well, then it is up to the called party to decide what to do.
Next thing to consider is that not every person knows what a valid callerID is. They will (if they don’t get bored and stop call you) try to enter whatever number to get the call through.
Comments? They are welcome.