1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. If you had a PIAF Forum account in the vBulletin days, log in with your old credentials. Otherwise, sign up again and we'll get you back in business as soon as we can.
  3. A serious FreePBX vulnerability has been reported. Update your Framework Module immediately. Click here for details.
  4. Critical FreePBX vulnerability! Update your server immediately. Details here.

CID Superfecta 2.2.5 BETA 1 Now Available

Discussion in 'Add-On Install Instructions' started by lgaetz, Aug 8, 2011.

  1. lgaetz Pundit

    edit Oct. 18, 2011
    It has been more than two months since the original release of 2.2.5 Beta 1 without a single reported issue. Since efforts are being concentrated on version 3.x and given that there are no bugs to address, this module will probably not be re-released as 2.2.5 final.

    Caller ID Superfecta 2.2.5 BETA 1 is available for immediate download and testing. This is a maintenance release of the 2.2.x branch and incorporates the following bugs/fixes/features:
    • Revised to work unmodified with FreePBX version 2.9
    • Overhauled the live update mechanism
    • Includes several new and revised lookup sources that were previously only available via manual download and install
    • Fixed bug that would not permit rules to strip a leading zero
    • Minor edits and tweaks too numerous to identify individually.
    All users of FreePBX 2.9 and the Google Voice Module should be aware that the first attempt at patching the GV module for 2.9 compatibility will break CID Superfecta and possibly other modules as well. There are also issues if you are using FreePBX 2.9 and have the Hotel Style wakup calls Module installed. If you are running FreePBX 2.9 you need to check into this threadand stay on top of issues as they arise there.

    If you have read the above and you want to upgrade/install CID Superfecta 2.2.5 BETA 1, you can download it from this link:
    Code:
    http://www.pbxossa.org/files/superfecta/superfecta-2.2.5beta1.tgz
    Installation instructions are here. Since this is a BETA release, please report your experiences here (even successes) so that we can gauge the module's suitability for general release.

    PS: This will almost certainly be the last of the 2.x branch. The devs are actively working on 3.x. Anyone who is interested in helping out, adding their $0.02 or just rubbernecking can follow the progress of 3.x at github: https://github.com/POSSA/Caller-ID-Superfecta
    Last edited by lgaetz, Oct 7, 2013
  2. Just wanted to say THANK YOU to all involved in keeping Caller ID Superfecta alive and updated. In my opinion this is the most useful of the third party modules for FreePBX, particularly for Google Voice users who don't get any kind of caller name data at all from Google (for those that don't read my blog, I'll just say that I'm not the slightest bit happy with Google right now, but that's a whole other topic).

    I would also underscore the point about the Google Voice module. If you are running FreePBX 2.9 or think that there is ever any chance you will upgrade to 2.9 or beyond, do yourself a BIG favor and grab the latest revision of the GV module from the thread linked in the first post. Otherwise, when you do finally upgrade FreePBX and Superfecta stops working, you will be scratching your head and wondering why, unless you have a much better memory than I do. So get the revised GV module now, and save yourself a headache down the road.

    And thanks again, guys, for your hard work on this module!
  3. lgaetz Pundit

    For all whocalled.us lookup users

    Important announcement for all users of CID Superfecta and the whocalled.us lookup source. Please see this post.
  4. LesD Member

    As a recent user of PIAF I just installed CID Superfecta. With the assistance of lgaetz I have got it working and I must say it works very well.

    Just one observation. I'm not sure if the following is as it should be or a bug.

    I first tried a Filter length of 15 on the basis that it was the longest incoming number I could get and nothing was found - I assumed the compare would actually use the length of the CID received.

    I then reduced it to 11 which was the length of all the numbers stored in the address book and that also failed to find anything.

    Reducing it to 10 or less allowed it to work.
  5. lgaetz Pundit

    The filter length is used to ignore prefix characters if they are stored in the database. This seems to work well for North America where phone numbers are always 10 digits with or without a leading digit 1. So in my case, I would use a filter length of 10 so the leading one is always ignored if present in the phone book.

    In looking at the code for asteridex, it hasn't been revised in a long time. There are a few minor improvements that have been developed over the years that were not implemented. If you are keen to do a bit of testing, I think it is time to spruce this lookup source up a bit.
  6. LesD Member

    I would be happy to do some testing.
  7. lgaetz Pundit

    I have attached a file to this post for testing. Unfortunately I don't have Asteridex installed anywhere that I can test this with, so we may have a bit of trial and error here. Save the attached file, and rename it to *.php (txt is required to circumvent forum filters). Then navigate to:
    /var/www/html/admin/modules/superfecta/bin

    find the existing source-AsteriDex.php and rename it so you have a backup you can restore if necessary. Copy the attached renamed file to this folder and change user and perms to asterisk:asterisk 0775
  8. luckman212 Guru

    I think that file is missing the final ?> to close out the <?php tag.
  9. LesD Member

    What changes are you expecting to see?

    Please could you also please give the exact commands to make the user/perms changes - my Linux skills are very low at the moment - to save me Goggling for it.
  10. lgaetz Pundit

    It is missing and that is intentional.

    I have changed the MySQL query to be more flexible in case users store non-digit characters in the database. There is a mechanism to disable the filter length, and putting in a large filter length should have no effect on lookups.

    For point and click users (like me) Webmin is your friend, find File Manager from a java enabled browser and you are good to go. Via console/ssh the commands would be:
    Code:
    chown asterisk:asterisk source-AsteriDex.php
    chmod 0775 source-AsteriDex.php
  11. lgaetz Pundit

    Ok, I have a copy of the MySQL database setup for Asteridex 4 and my testing has proved ok. Unfortunately Asteridex doesn't have a date field (feature for v.5 perhaps?) so if the same number appears twice in the database you will get one at random, probably the one that was added first. Filter length is working better than before, and can be disabled by setting it to 0 (zero) or false. Because of the inner workings of Superfecta 2.x, setting it to false works better so I will revise the mouse over help before it gets pushed via live update. Any other comments?
  12. LesD Member

    I have now done some testing and results as follows:

    (I forgot to do the chown and chmod but it all worked so I assume the results have not been compromised)

    1. For me a filter length of 0 would not save - it reverted to 10.

    2. With a length of 15 I got good results - surprisingly so.

    Using a number with 13 digits such as 0012345678910 it returned the correct CID even though the number was actually stored with a 9 prefix (due to a problem I have - described in an other thread). Testing the number with the 9 prefix also found the right CID. Using an 8 instead of the 9 prefix failed.

    So even though we have a filter length of 15, it matches the trailing 12. Basically it is doing a best match and ignoring the 15 filter length. If only 11 characters are presented then it still matches, etc. This is perfect for me as having the extra 9 will not spoil the lookup.

    3. There is something odd with short CIDs.

    I created address entries with identical numbers of reducing lengths - from 10 to 4. 1234567890, 123456789, 23456789, 3456789, etc.

    Worked fine going down to 56789. For 6789, 789, 89 it always returned 56789. Trying just a 9 it returned a random one ending in 9.

    So it looks like overall the match that is coming back is the first exact match it finds but that may not actually be the right one if it finds a partial match first even though there may be an exact match as well.

    So in the UK for example, a national code 02088884444 could match an international entry like 002088884444 even though an exact entry also exists. A bit far fetched but possible.
  13. lgaetz Pundit

    That behavior is by design. It is anticipated that a user will not have a list of with widely varying number lengths. The way the source is written now, when you do a search for 123456 it will match that sequence of numbers no matter where it finds it in the database and ignores all non-digits in the process, so 123456 will match ALL of the following cases:

    345123456887ext44
    aaa123bbb456ccc789
    (555)1-2-3-4-5-6<>what ext4

    If multiple matches are found, it will only return one name, which I believe will be the entry that was entered in the database first, tho I am not sure about that. I assume that it's not a problem for you and that you were pushing the envelope so to speak.

    Regarding the filter length of 0 (zero), yes I discovered that quirk after I posted the source. I have since changed the mouseover help to use the word false if you want to disable the filter length.
  14. LesD Member

    The results I am getting in real life are just fine. Over the last few weeks I have been hunting for something like this and it was more by luck than judgement that I found it.
  15. lgaetz Pundit

    You don't need judgement if you have luck.

    You have got me thinking. It is certainly possible that someone might store extension numbers or something else which would result in a widely varying list. I wonder if it would be wise to do an initial search for an exact match and if that doesn't work then do a second search in the manner described above.

    I may tweak this a bit more and perhaps prevail upon your time again for a bit of testing.
  16. LesD Member

    Only too happy to oblige.
    ===========

    I do have a concern about scalability of all of this and wonder whether something could be done between the different folks looking after AsteriDex and CID Superfecta. I'm sure they are know to each other :)

    My only interest in CID lookups is via AsteriDex as it is local and database driven. Unless the whole business of lookup is well under a second I don't think it is much use. I tried some of the other lookups and they typically took 3 seconds to return nothing. To my mind that is useless for CID display purposes.

    My PC based address book has about 4000 names, many with multiple numbers. I wonder what would be the response time and the load on the system to do character pattern matching in real time, especially as there is no indexing to assist.

    With the addition of some derived columns in the database, suitably indexed, I'm sure the whole business could be scalable such that any size would not be an issue.

    At the moment I have extracted about 120 frequently used numbers and am only loading them.

    Has anyone tried using AsteriDex with thousands of entries?
  17. lgaetz Pundit

    My main system does MySQL lookups on a local database similar to AsteriDex but with a rather more complicated query. I have just under 1300 entries with no indexing for efficiency and get response times in 1-3 milliseconds with no noticeable load. In your case, with 4000 entries, unless you are running on underpowered hardware or have a huge incoming call volume, I would be surprised if you notice any lag.

    The superfecta cache is a MySQL query as well, and I suspect there are busy systems out there with thousands of entries in their cache. There have been no issues reported since my involvement with the project; over a year now.
  18. LesD Member

    OK, I will give it a go when time permits.

    Thank you
  19. repherb New Member

    Something changed from 2.2.4 to 2.2.5...

    Hi all, just wanted to report that 2.1.0 to 2.2.4 was not working on my fresh installs of PiaF 1.7.5.5.X and i am quite sure something was broken/bugged.

    I installed PiaF 1.7.5.5.3 and then uninstalled 2.2.4 and installed 2.2.5 Beta 1 via upload module in FreePBX 2.9.0.1, and lo and behold, IT WORKED FLAWLESSLY!! all sources are resolving and CID info is displaying perfectly.

    THANKS GUYS/GALS!!!
  20. ukstevef Guru

    Thanks for the feedback, glad to hear that you have it working again.

Share This Page