Hi Lorne - this one I think might be a question you might be best placed to answer? It’s re: this thread where you fixed the module
Just got a spam call, and wondered why Caller ID superfecta didn’t “protect us” from it, given that when I run the number through Caller ID superfecta test, it’s shown to be a SPAM caller. It should have gone to Lenny, I thought.
When looking at the inbound route it’s set to send calls through Caller ID superfecta and indeed this did happen as the caller ID geographic region was set to ‘LONDON’ which is one of my lookup sources. However, this lookup source is BELOW the lookup source which would have flagged the call as spam?
My logs are here and as you can see at about line 62 Superfecta sets the caller ID to London.
In the demo, the caller ID would be set to SPAM, but it looks like in reality this may not happen??
During a live lookup, the lookup sources are polled one by one from top to bottom and the polling stops as soon as it finds a name. Keeping in mind that Superfecta’s primary purpose is to provide a CID name, if you’re using Superfecta for spam interception then you must order your lookup sources to ensure the spam flagging is done before the name sources.
But that’s the thing - the caller ID source "who called UK" which flagged the call as spam in demo testing IS higher than "Telco data" - but Telco Data set the Caller ID and Who Called UK didn’t.
that’s because what you’re looking at is the demo view of superfecta. The number was already cached because I’d received a spammy call on it already. I was then running the number through the tester to find out why superfecta didn’t take action.
I can’t see (please show me, I’m sure it’s me being daft?) where in my log it clearly shows the number was cached? All I can see is that initially it has ‘LANDLINE’ which is what my ATA sends the CNAME as, and then superfecta sets it to LONDON…
There are no verbose historical logs of Superfecta decisions to my knowledge, but what that log shows is that the call came in with the CID Name (CIDN) of LANDLINE. Then Superfecta assigned the CIDN of LONDON.
You know that, I know that. But you are then attempting to say that superfecta does not run correctly, when it obviously does.
Do you actually understand how the SPAM databases are made? They are all crowd sourced, and put up for sale/use. Every list service tries something to differentiate itself from the next, blah, blah, blah. But int he end it is a list service that is crowd sourced.
Why is it crowd sourced? Because there is no accountability on spoofing CID on the global phone network. Some carriers add in restrictions, but that doesn’t matter to the spammers, they just use a carrier that does not.
Because CID is spoofed, the CID sent are very typically randomized. Though typically not on every call, but in batches. Once a number is reported enough and flagged as spam, the spammer moves on to a new number. The better spammers most certainly subscribe to the same SPAM lists that their victims use.
But did you catch the key here that applies to you? The number was not yet listed as SPAM by your service when the call came in. Thus superfecta did exactly what it was supposed to do.
Jared, I’m glad you could get around to posting that condescending answer.
You’re wrong, of course - and if you can wait an hour or so, I’ll show you why. Got to get kids to bed.
You’ve got to a place where your overconfidence means you no longer assess matters logicially. You just bullishly decide you’re more experienced (which is true) ergo you’re always right (which you’re not able to be all of the time)
EDIT: Ok, so took me a bit longer than an hour to return to this, but here’s why you’re wrong. You’ve made several wrong assumptions in your post, but chief among them is your conviction that the number wasn’t listed as spam when the call came in. Well, it was. The number has 2,600+ reports against its name and isn’t newly classified spam/dangerous nor was it on a knife edge number of reports whether or not its about to be reclassified. I checked the number about a minute after I got the spammy call.
So to reiterate, what seems to be happening is that in demo mode, superfecta + whocalleduk seem to work correctly, but in live mode, not so much.
What I’ll try to do later on today is spoof a call from that number and see what happens.
Quick and dirty way to generate an inbound call with spoofed CID:
[from-internal-custom]
exten => _9999X.,1,Noop(Entering user defined context [from-internal-custom] in extensions_custom.conf)
exten => _9999X.,n,Set(CALLERID(number)=${EXTEN:4})
exten => _9999X.,n,Goto(from-trunk,xxxxxxxxx,1) ; substitute actual DID in place of x's to match inbound route
exten => _9999X.,n,Hangup
From a local extension dial 9999 plus the digits of the CID you want to spoof
Thanks Lorne that will save me a bunch of time and messing about.
I’ve given it a try, and again, it hasn’t worked as expected:
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: Launched AGI Script /var/www/html/admin/modules/superfecta/agi/superfecta.agi
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Executing Scheme..
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Scheme Asked is: ALL
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: The DID is: [01709622111](tel:01709622111)
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: The CNUM is: [02035987307 ](tel:02035987307)
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: The CNAME is: SALESOFFICE
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi:
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Starting scheme Default
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Converting result to UTF-8
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Setting caller id to: London
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Setting channel variable SUPERFECTA_NEW: London
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Setting channel variable SUPERFECTA_OLD: SALES OFFICE
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: CID Determined to be: 'London'
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: /var/www/html/admin/modules/superfecta/agi/superfecta.agi: Attempting to set lookupcid
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] res_agi.c: <PJSIP/20-00000bd6>AGI Script /var/www/html/admin/modules/superfecta/agi/superfecta.agi completed, returning 0
[2019-09-16 14:07:16] VERBOSE[18272][C-00003a27] pbx.c: Executing [[01709622111](tel:01709622111)@from-trunk:22] Set("PJSIP/20-00000bd6", "CALLERID(name)=London") in new stack
A quick look at the GUI for the Superfecta demo and for the first time when I’ve tested this number today in the demo view it shows this! Every other time today it’s shown the same stats as the website itself shows.
Executing WhoCalled UK
Searching https://who-called.co.uk/Number/[02035987307 ] ...
Number of Searches: 0
Search Threshhold : 10
Number of Comments: 0
Comment Threshold : 0
result took 0.3903 seconds
So it looks like the problem might be intermittent or it might be with the module itself or the lookup source? If you go to the web view of whocalledUK you can clearly see that the number of searches is 2,600+.
Still doesn’t explain the superfecta caching issue though…
I genuinely still find all this really interesting and fun to experiment with.
The website may not be consistently returning the same content. Turn up the verbosity when you’re testing and you may catch it returning a captcha page or some other result other than expected.
