CID Superfecta not working


I am trying to lookup CallerID names with CID Superfecta but it is not working :frowning:. I am using the FreePBX User Mgr as a source. In the User Manager I have added our Windows Active Directory. All users have a Work Phone Number and most of them also a Cell Phone Number. Most numbers are stored without a country code (more on that later). The current version of the CID Superfecta module is 16.0.18.

There are two main problems:

  1. When I debug/test run the schema in Superfecta only the name is returned when I am searching for the exact number. So if I am looking for the number with the country code and the number is stored without the country code, there is no name found.
  2. Even if the debug/test run returns the correct name it is not working on incoming calls at all.

Does someone have the same problems?

You have to activate Superfecta in the incoming route.
Within the Superfecta template you can define rules for CIDs. (e.g. remove country codes)

Thanks for your reply. I have already enabled Superfecta for the inbound routes (Sorry forgot to tell).
Removing the country codes would answer the first problem. Is there any way to remove also the “+” in the Superfecta CID Rules?

But why is it not even working when the test run in the schema successfully returns the name. So for example in the test run the number +49172XXXXXXX returns the correct name. But when I am actually calling from this number only the number +49172XXXXXXX is shown on my phone and my Zulu client.

1 Like

Thanks. I will give it a try.

I also could fix the second problem by downgrading the CID Superfecta module to version 16.0.14. Turns out version 16.0.18 is buggy. When you are checking for updates now version 16.0.14 is also the newest one.

Well it is still not working on incoming calls. So I guess I will have to stick with manually importing all contacts to the Asterisk Phonebook. This works at least.

I use Superfecta on a freePBX 16 system too…and it works.

Provide a call trace of a problem call via Pastebin. Providing Great Debug - Support Services - Documentation

Here is a screenshot of the test run scheme and the log file of the call. The name “Jonathan Francke” should be shown in the Zulu client. But it does not :frowning:

/var/log/asterisk/full:[2022-07-02 18:37:18] VERBOSE[8844][C-00000229] pbx.c: Executing [[email protected]:25] Set("PJSIP/Telekom-0000055a", "__CRM_LINKEDID=1656779838.6899") in new stack
/var/log/asterisk/full:[2022-07-02 18:37:19] VERBOSE[8844][C-00000229] pbx.c: Executing [[email protected]:1] Set("PJSIP/Telekom-0000055a", "TOUCH_MONITOR=1656779838.6899") in new stack
/var/log/asterisk/full:[2022-07-02 18:37:19] VERBOSE[8844][C-00000229] pbx.c: Executing [[email protected]:5] UserEvent("PJSIP/Telekom-0000055a", "zulu-call,eventtype:calling,extension:11,type:,url:,cnam:KzQ5MTUxMTgxNzQyMjc=,cnum:+491511817XXXX,lid:1656779838.6899,from:+491511817XXXX,to:11}") in new stack
/var/log/asterisk/full:[2022-07-02 18:37:26] VERBOSE[8844][C-00000229] pbx.c: Executing [[email protected]:4] NoOp("PJSIP/11-0000055b", "MASTER CHANNEL: 1656779839.6900 = 1656779838.6899") in new stack
/var/log/asterisk/full:[2022-07-02 18:37:26] VERBOSE[8844][C-00000229] pbx.c: Executing [[email protected]:4] NoOp("Local/[email protected];1", "MASTER CHANNEL: 1656779839.6901 = 1656779838.6899") in new stack
/var/log/asterisk/full:[2022-07-02 18:37:26] VERBOSE[8869][C-00000229] pbx.c: Executing [[email protected]:4] NoOp("PJSIP/9011-0000055c", "MASTER CHANNEL: 1656779839.6907 = 1656779838.6899") in new stack
/var/log/asterisk/full:[2022-07-02 18:37:26] VERBOSE[8844][C-00000229] pbx.c: Executing [[email protected]:4] NoOp("PJSIP/Telekom-0000055a", "MASTER CHANNEL: 1656779838.6899 = 1656779838.6899") in new stack
grep C-00000229 /var/log/asterisk/full | pastebin

When you dont read the full docs :roll_eyes:. Here is the full log.

You can see the Superfecta details starting at line 64 of your paste, name of scheme, cid name/number etc. If you are testing offline EXACTLY as it shows in the call trace, then the remaining possibility is that you have ‘Trunk Provided’ configured as a lookup source in the Superfecta scheme. If the sip provider sends the call to you with the Caller ID Name populated with a number then that string will be used when evaluating lookups on a live call. Obviously you can’t test offline what will happen with a trunk provided cname.

Unrelated to your issue, but it looks like the detemedian lookup is broken. If anyone is able to provide an updated URL to pass a reverse number search we can fix it.

What do you mean by testing offline? I am testing by calling from my cellphone to the pbx.
I had configured the “Trunk Provided” as a source but the “Contact Manager” was the first lookup source. Even if I disable the source “Trunk Provided” it is not working.
The number +491511817XXXX is exactly likes this saved as a contact in the Contact Manager (I have replaced the last 4 digits). The debug/test returns the correct result. For me it should work.

Today I have tested it with a different SIP provider (Easybell Germany). This provider is sending the CNUM and CNAME values without the country code. Like this 01511817XXXX instead of this +491511817XXXX. I have changed the number of the contact from +491511817XXXX to 01511817XXXX. And now superfecta is resolving the correct contact over this SIP trunk. So I assume there is maybe something wrong in superfecta when handling incoming calls with country codes.

I am located in Austria (=neighbour)…and I posted the solution above. So you just have to replace 43 with 49 and 01 with your local area code and it will work. (and adjust the digit number if necessary)

EDIT: you have to use YOUR trunk name (innosoft is an Austrian SIP trunk provider, sip or pjsip?)

Here is an older discussion…same topic…for Germany

…and you might change the title from “CID-Superfecta not working” to e.g. “CID-Superfecta not working - problem with country code” :wink:

Yes I did that and it works. Thank you for this solution. But I think it is more a work around. It would be nice if superfecta is able to handle country codes as well. And it is a little bit confusing that debugging the scheme is working with country codes.

Adjusting the format of the incoming call is never a workaround!

I don’t recall ever seeing a report of this before, where you get different results in testing vs. a live call. Are you able to repro this @Charles_Darwin? I assume it’s due to the leading + character, but no idea why because afaik all non digit chars are ignored for superfecta.

I always remove the +countrycode (=home country) and replace it with 0 on all of my systems. The reason is that I don’t use the +countrycode format in my phonebook. For foreign countries e.g. Germany I use 0049 instead of +49, so I don’t know if this behavior occurs…sorry :wink: