Superfecta.agi Gets Name From Fop2 Phonebook w/o Real Number

I just got a call from a gov. agent in the Permits section of their division. Standard, day-to-day stuff that. This time, something weird happened, and I’d like to ask anyone reading this for help understanding what happened.

The call rang in on my desk phone as a co-worker “Bob Dobbins”, phone number = “30”. (Three-Zero, nothing more) I respond instantly when my co-workers call, so I didn’t waste a breath picking it up to find a kind, confused clerk from the Permits office of a local county regarding a job we’ve taken on. I’ve done the phone thing long enough to handle the call, but the weird number piqued my curiosity.

So I went to the Asterisk logs & pulled the entire SIP session up to the point I handed the call off to a Representative, to suss out wtf that was all about. Maybe it’s SOP for FOP or maybe it is a bug, I’m asking you.

The module pbx.c did its usual “executing …” steps & as usual executed “/var/www/html/admin/modules/superfecta/agi/superfecta.agi”. When the res_agi.c module launched the superfecta.agi script, this is what it logged:
CID Superfecta is Answering the Channel
CID Superfecta: Scheme is ALL
CID Superfecta: The DID passed from Asterisk is: 9045551212 (our DID for one remote office)
CID Superfecta: The number passed from Asterisk is: 30 (unedited except to trim timestamp)
CID Superfecta: The CID name passed from Asterisk is: 30 (unedited except to trim timestamp)
CID Superfecta: Executing Scheme…
CID Superfecta: CID Determined to be: ‘Bob Dobbins’ (of course that’s his real name – NOT)
CID Superfecta: Attempting to set lookupcid
CID Superfecta: Success!

Since Bob is a co-worker, the Dynamic Routes module sent the call to a Ring Group which is why it rang my desk. (In the server closet, by myself, I couldn’t hear any other extensions ring & being busy I didn’t take the time to check the ever-open FOP2 page.)

So I guess it’s safe to assume the gov’t agency pushed out the ‘30’ as their Caller ID, maybe; but what happened in FreePBX??

So seeing it was Superfecta, I went to Admin->CID Superfecta & found it just as I’d left it: with Data Source Name = FOP2 Phonebook then Asterisk Phonebook then FreePBX User Mgr & none others selected.

Scrolled down to “Test a phone number against the selected sources.” With the Debug Level set to ALL, I entered my own # to test, which got hits on all 3 sources as it should.

Now for the weird part:

I entered “30” (just three-zero) as the test phone number.

Bob Dobbins popped up in the results list from FOP2 Phonebook!!! He is in it, but has his proper cell number as Phone 1, nothing as Phone2. No “30”. I tried a couple of other non-phone-numbers & each one pulls up a name from our FOP2 Phonebook!!

I’m curious to know what logic superfecta.agi uses to pull names.

Anyone else get the same result? Admin->CID Superfecta with Data Source Name = FOP2 Phonebook then “Test a phone number against the selected sources.” with a non-phone number?

Anyone care to drop me a clue as to where I can make it stop doing that?? I’m hoping someone knows where to look in asterisk.visual_phonebook, or at least can say why this happens. It certainly lowers my expectations of superfecta.agi, and FreePBX in general.

Thank you for reading and thank you for any thoughtful answers.


Here is the code used to search FOP2. I may have written it originally, but more likely I was just the last to touch it, since I have almost zero experience with FOP2 and I have no recollection of testing it.

The MySQL query is done with a regex so partial matches are possible. If you store a phone number of 1-555-444-3333, and you receive a call from Caller ID of 5554443333, that would be a match. An unintended consequence of this flexibility is that both 5544 and 33 would also be matchs. The idea is that things like leading ones or numbers stored with parentheses and hyphens will not prevent a lookup match. It is also expected that inbound calls will not have wildly different number of digits than the stored numbers.

You can add CID rules for the scheme to prevent running lookups on inbound calls with short CID such as the example noted.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.