Finding balance with the FCC Robocall list

There has been much discussion over the FCC robocall list and why it’s the greatest thing since canned bread or why drinking bleach would be a better choice. Current implementations all leave something to be desired.
So currently folks are downloading and parsing a massive csv into astdb to take advantage of the blacklist.

Here are my issues with this implementation:

  • This puts over 97,000 entries in your astdb. To begin with this is madness. There is no reason you should push that much of any kind of data into astdb.

  • Every week you have to insert a new list, which takes about 5-10 minutes. This is likely not an issue for most as they likely use a cron job.

  • This process as discovered by one user can render GUI based management difficult if not impossible.

  • The numbers on this list have had a complaint by someone. The complaints do not have to be valid. This list is not vetted and filtered. Anyone could potentially report anyone and suddenly you are not getting calls from them. One company on the list is Fedex. Using the import method, fedex can’t call you. It seems like a terrible idea to block almost a million callers without a second thought.

  • Data normalization. Caller ID is not one size fits all. Even between your trunks you may get 2 or 3 caller ID formats. One carrier may send +14805551212 another 4805551212, and finally 14805551212. The way blacklisting works is on an exact match. You would have to put 3 entries for each of the 97K numbers to satisfy a proper block.

These reasons are all why I have resisted any promotion of using this data. There has to be a better, perhaps sane way to use this data without falling into these pits. My knee jerk reaction was to put up an API. I could keep a sync’d copy of this list and superfecta could make calls to the web service. This clears up 1, 2, 3 and 5. We still fall into pit number 4. Well 3 out of 4 ain’t bad.

So I went to the FCC site and noticed a button. They have an API. I clicked on the API and discovered I can pass a phone number to them and get all the complaints back for a given number. This was kind of awesome!

So I put together a Superfecta source that I think solves 1, 2, 3, 5 and some of 4.

The source normalizes the number, calls the FCC API and counts the complaints. The more complaints, the more likely the number is a bad guy. By default the threshold is 2. For reference, Fedex mentioned above is at 2, so for their call to not be spam you would have to bump it to 3. Now you can use the data on any trunk without need for multiple formats. You don’t have to pollute your blacklist with 970K entries. No need to sync the data or wait a week for an update as the information is pulled in real time.

In the edge version of Superfecta, there is a new source called FCC Complaints. Give it a look and reclaim your blacklist!

If you are using a framework version of 13.0.96+ you can get Edge modules as follows.

To enable the edge track, go to “Advanced settings and set
“Set Module Admin to Edge mode” to “Yes”
Then go to module admin and click “Check Online”. Note this will show updates
for ALL modules in the edge track. Update the blacklist module.
Once finished go to “Advanced settings and set “Set Module Admin to Edge mode” to “No”
You may also upgrade from the command line with "fwconsole ma --edge upgrade blacklist”

For more information on what we are doing please follow @sangoma and @FreePBX on twitter.

If you find bugs please file a bug report at
FreePBX documentation on our wiki
Professional support services at


Very nice addition, tested a number and boom, there it is. Shame the lookup takes a little over 1.3 seconds to complete, not your fault by any means. Thanks for the work…

In all my testing I was getting about 300ms in Wisconsin

Could be latency on my end, just checked it again and it was much lower…

Does the FCC’s # of complaints reset itself after a period of time, or will FedEx’s phone number eventually go high enough to be blocked? Remember that many robocallers and Spam callers are just spoofing legitimate callers numbers.

I strongly recommend creating a whitelist module and a button in the IVR module to allow people to add themselves to the whitelist when they select a valid option off an IVR.

I’d like to be able to route inbound calls to the whitelist module. If the caller passes the whitelist, he can go straight to my preferred destination (time condition/ring group/etc) and if he fails the whitelist (new untrusted caller), I can send him to an alternate destination (such as voicemail or an IVR). Ideally, the IVR module would had a mechanism to let me designate one or more destination options as “add to whitelist.”

That way, new callers would get the business IVR. A robocall won’t select an option and will be disconnected. A human who selects a valid option gets added to the whitelist, and in the future, won’t hear the IVR.

No, the list never removes anything, it just adds complaints.

Yes a whitelist is a good idea, you would best use that to dynamically remove the blacklist entry after an update from the FCC as asterisk’s blacklist is very simple and just consults that part of astdb, if you use the superfecta module that would also need to modified to consult your whitelist also. One problem I can see is how would you know that a call has been blacklisted withoput consulting the call records or waiting for the offfended caller to contact you some other way.

pseudo code:

do while number in whitelist; remove from blacklist;done

I actually thought about this… it would only be about 5 lines. I just didn’t add it. I am in other projects at the moment I will add this in the near future. @lgaetz and @tm1000 are much more involved in the superfecta code, maybe they can answer if this is a feature that should be a source of its own that sets never spam or a global superfecta setting that does the same

In the next release I have added a whitelist field. any numbers in that box will not make an api call and will automatically pass as not spam

1 Like