Call blocking by area code [solved]

Status
Not open for further replies.

mgcarley

New Member
Jul 17, 2023
2
1
3
39
For the past day or so I've been poking around looking at the call blocking feature, and while it's great for blocking a single number quickly and easily, I've been running up against an issue where I'm having to block entire area codes due to a substantial amount of calls being received that were just "dead air".

I'd started to mitigate the problem by screening calls on the extension in question, and when I'd pick up the phone and hear silence instead of a name, I could just hang up.

But even that is too distracting.

So I looked at my call logs and found that the calls tended to originate mostly from the NYC metro area (in this case, the destination is an NYC number, but I don't really know anybody in the area who'd be calling me on this number).

So I created a short recording telling any potential real people to reach out some other way, created a new inbound route (set to 99, which puts it above any of the standard incoming routes), and started tinkering, eventually stumbling across regex that worked.

condition destination_number ^\+?1?(2123334444)$ 0 0 true
condition caller_id_number ^(\+?1)?((212|347|516|518|646|716|718|845|917)[2-9]\d{6})$ 0 5 true
action lua streamfile.lua Restricted_Area_Code.mp3 0 10 true
action hangup 0 20 true

Unfortunately, this is probably a bit of an edge case - for someone who lives or works in the same area as their phone number, this solution probably won't work as well, but, for someone who registers a number in another state from where they or their business is located... it could be helpful.

Either way, there's no reason someone couldn't modify this to mitigate junk calls for their own situation, such as preventing calls from toll-free numbers:

^(\+?1)?(8(00|33|44|55|66|77|88)[2-9]\d{6})$

I don't believe the destination_number condition is necessary - this could potentially be set as a global rule for all destinations & extensions; and instead of a message you could simply send them to voicemail (but I don't want to keep getting a bunch of 3-second voicemails and/or emails with audio attachments, hence the hangup), or to an IVR, or something. I've also used a method where it requires input before calling the extension (basically a sound captcha... "dial 1357 to continue this call").
 
  • Like
Reactions: mcs3ss2

whut

Member
Dec 23, 2022
228
22
18
An IVR requiring caller input or extension call screen are useful aids as they require the caller to make interactive actions.
 

mgcarley

New Member
Jul 17, 2023
2
1
3
39
An IVR requiring caller input or extension call screen are useful aids as they require the caller to make interactive actions.
As mentioned in the final line of the post, I had that as well.

While it was a much easier option to implement, and while it drastically helped stop most of the robots, it also flummoxed certain people... namely call center staff at banks & whatnot - they'd call the number and when it would play the message, they wouldn't dial the input to actually be put through to me, instead they'd just come back to the original conversation and say they got voicemail and thus couldn't verify my identity or whatever.

The call screening on the extension is all good, but the problem with that is that even if the robot enters nothing, it still rings the extension or goes to voicemail (which then results in a voicemail email as well).

Outlying use cases, I know, but, necessity something something invention.
 
Status
Not open for further replies.