Caller ID Superfecta: THE MODULE

[troycarpenter]

Hmmmm

Seems I'm having a similar problem to Troy here. I never installed Ward's script, so I can't compare.

I updated callerid.php to turn on debug ($debug='1') and started poking in some "known" phone numbers with the url you provided.

No matter what number I put in the return was always city/state and land line (or cellular where appropriate). Never an actual name was returned...

The problem that was giving me the "land line" or "Cell phone" has been fixed...it was a difference between that version of module callerid with Wards script which has since been resolved.

For the other, it's because your callerID is falling mainly to WhitePages. That is still common for me. The problem I was pointing out is when there WAS an Anywho entry for a person, it was being missed and falling through to white pages.

For cell phones, if the name isn't already in Asteridex, then it always shows up as "cell phone". I don't think the Cellular system in the US likes to share callerID information.

 

[mbellot]

Troy,

Thanks for the additional info. It appears there was another "gotcha"...

Turns out all the land line numbers I used for testing are unlisted.

I'll try some more tonight after the kids are in bed.

 

[BillG]

Well, everything looks pretty much the same between the 2 scripts except for the integration with FreePBX. Yet one works and the other doesn't. And I don't really need to change it via FreePBX anyway, so....

 

[tshif]

Well, everything looks pretty much the same between the 2 scripts except for the integration with FreePBX. Yet one works and the other doesn't. And I don't really need to change it via FreePBX anyway, so....

Bill Ive been following along with your problem - but I don't know what to make of it. The errors reported during debug are surely telling. I just don't know what they are telling. Naturally, I haven't been able to reproduce your exact variety of errors - but Id sure like to understand them better.

 

[BillG]

Bill Ive been following along with your problem - but I don't know what to make of it. The errors reported during debug are surely telling. I just don't know what they are telling. Naturally, I haven't been able to reproduce your exact variety of errors - but Id sure like to understand them better.

Thanks... Odd that I'm the only one this is happening to (story of my life.) Also odd that my old script had stopped working too. But I haven't been able to get to the bottom of either one. I'd be happy to troubleshoot and try to work it out if it would help anyone else, but at least now I have something that works.

 

[tshif]

Bill - I'm always in favor of a better understanding -especially when failures are concerned.

I really think it has something to do with web services, or perhaps Apache security on your pbx. Perhaps - permissions on one or more of the folders involved.

I'm not sure what I mean by that yet, but consider:

The very same callerid.php exists both inside the module, and in the standalone deployment, baring very few changes.

When you use the url directly in the browser, it fails; With the debug mode returning authoritative failure messages. This means the script isn't crashing, or failing to run; Its reports suggest that its failing to connect to the sources its listing.

Presumable, this is whats happening when the module is called upon as configured in FreePBX Caller ID lookup sources.

When the same code, un-modularized, is called upon as configured in FreePBX Caller ID lookup sources, it runs and produces results.

So - since its the same code, being called by the same configuration - the only difference I can think of is where the callerid.php is being run from. In the case of the module, the callerid.php script is run from http://pbxaddress/admin/modules/superfecta/callerid.php.

When the standard callerid.php is run, I beleive its located in the root of the html folder. (Im doing this by memory - so double check that last path) That's the only difference I can think of.

So - here's a good test then.

1. Have the Superfecta Module Installed, and properly configured via the web interface - just as if you were going to use it for real.
2. Copy the callerip.php script from /admin/modules/superfecta/ to the location from which you normally run the un-modularized version of callerid.php. (Temporarily rename to un-modularized script to something else during this experiment)
3. In FreePBX, for your test inbound route, in Caller ID lookup Sources - select the un modularized version of the Superfecta.

Our goal is to trick the system into running the version of callerid.php that comes with the module - from the same location its successfully running the un modularized version.

So - test it out - call into the system and see if the results are good. My bet is this will work.

Not only that, but you'll still be able to manage the settings with the Modules User Interface - since you are now running the version of the script that knows how to look into the database for these settings.

If this does work - then something has disrupted the "normal" permissions to the module folder system - or something similar.

Before I go to far out on a limb - lets see if any of this holds water when you test it out.

- Tony

 

[BillG]

Thanks for the help. I'm thoroughly confused now because... it seems to work. Last night I had both scrips in the same superfecta directory, just slightly renamed. From the web interface I could run callerid.php just fine, but callerid1.php (which was the superfecta one) failed with the error messages above. But this morning when I tried again they both worked. I don't get it, but if I can't break it again there's nothing to fix. Gotta love computers...

 

[troycarpenter]

Question retracted...It seems I was running the wrong version of the script.

 

[tshif]

Question retracted...It seems I was running the wrong version of the script.

Troy - I had hoped the module was working for you. Is there anything I can do to assist?

 

[troycarpenter]

Troy - I had hoped the module was working for you. Is there anything I can do to assist?

Oh, it is working. Somehow an older version of the callerid.php script crept back onto my system and I was complaining about a problem I thought was fixed...which really was fixed because I was looking at the wrong script. I was starting to see the <strong> tags show up again in the whitepages lookups.

 

[tshif]

Thanks for the help. I'm thoroughly confused now because... it seems to work. Last night I had both scrips in the same superfecta directory, just slightly renamed. From the web interface I could run callerid.php just fine, but callerid1.php (which was the superfecta one) failed with the error messages above. But this morning when I tried again they both worked. I don't get it, but if I can't break it again there's nothing to fix. Gotta love computers...

Bill - sometimes "It just started working" is the best answer we can get. Sometimes - we have to go with the answer: Magic!

 

[jimmyswimmy]

superfecta superfailure

So I had a neat problem with the superfecta script. I use a GXW-4004 to run a cheap cordless phone in addition to some native SIP phones. Once I set up the superfecta caller ID module, and enabled that as a callerID source, the GXW-4004 stopped ringing. The other phones work. Asterisk reports that the GXW is circuit-busy. I enabled the debug output for the GXW and it showed nothing useful.

I looked through extensions_additional.conf which is where the callerid script is called from - and noticed a difference between the old callerid superfecta script and the new one. For the original superfecta script sans module (called as cidlookup_1) there is some extra code here. I don't see why this should make a difference, but it does - adding it makes things work right. (the new superfecta script with the module is cidlookup_2)

[cidlookup]
include => cidlookup-custom
exten => cidlookup_1,1,GotoIf($[${DB_EXISTS(cidname/${CALLERID(num)})} = 1]?cidlookup,cidlookup_return,1)
exten => cidlookup_1,n,Set(CALLERID(name)=${CURL(http://localhost:80/callerid.php?thenumber=${CALLERID(num)})})
exten => cidlookup_1,n,Set(DB(cidname/${CALLERID(num)})=${CALLERID(name)})
exten => cidlookup_1,n,Return()
exten => cidlookup_2,1,Set(CALLERID(name)=${CURL(http://127.0.0.1:80/admin/modules/superfecta/callerid.php?thenumber=${CALLERID(num)})})
exten => cidlookup_2,n,Return()
exten => cidlookup_return,1,LookupCIDName
exten => cidlookup_return,n,Return()

; end of [cidlookup]

Unfortunately I don't know how to modify the freepbx stuff to make this permanent - every time you make changes in freepbx it goes back to the original. If you could point me towards some more info on that it would be awesome.

 

[klingon888]

Try copying the entire code starting with [cidlookup] into the extensions_override_freepbx.conf file. This file is provided to override the code generated from freepbx.

 

[tshif]

Jimmy- The callerID Superfecta doesn't actually create any of the code you posted. This is created by FreePBX when you establish and select a look up source in the Caller ID Lookup Sources module.

I think this line:
exten => cidlookup_1,n,Set(DB(cidname/${CALLERID(num)})=${CALLERID(name)})

Is the result of your telling FreePBX to Cache its results in the Asterisk Phonebook.

Have you recently updated modules in FreePBX?

 

[jimmyswimmy]

I think this line... Is the result of your telling FreePBX to Cache its results in the Asterisk Phonebook.

Have you recently updated modules in FreePBX?

Hi tshif. Yep, you're correct. I had forgotten about that option in freepbx. Once it's set - cache results - I think it works properly, for the most part (have some auth error in the webserver that I need to hunt down).

So I guess this is a problem I would have to tackle with Grandstream. Strange how nothing at all gets logged anywhere (even with debug logging set). It must be some kind of timing issue, it's weird, but it works now. I'll try to run a stripped down version of the config files and see if I can replicate it... maybe...

And yes, my modules are all up to date. Thanks for the reminder about the freepbx caller id sources caching option.

 

[Mysterious]

I´ve tried your module on an german piaf system, tried to lookup to my sugarcrm but the only thing i get as callerid is the number of the caller without the first two digits. May i have to change something to fit the german language pack of sugar crm? My version ist the last one published here 1.0.3.3.

 

[tshif]

Interesting. You are the first person to provide any feedback about the SugarCRM option. The Superfecta is designed to work with 10 digit telephone number by default. What is the format of your Caller ID in Germany?

 

[jpeterman]

It is probably not his format, but that the sugarcrm code is missing in 1.0.3.3. It got dropped along the way. I just got this working yesterday and will hopefully post the correct code tomorrow so it can be rolled up.

 

[tshif]

Note: This article's download links are obsolete, but left here for archival purposes. Get the current code from the link in the very first post of this thread.

It is probably not his format, but that the sugarcrm code is missing in 1.0.3.3. It got dropped along the way. I just got this working yesterday and will hopefully post the correct code tomorrow so it can be rolled up.

Jeez - did I have version control issues with this module or what???

I think its time for a new version series. Must be 1.0.3 was jinxed!

Here it is everyone - with the SugarCRM code reinstated. (1.0.4).
(4/7/09 The above code is obsolete! All installations should be using this version)

Mysterious - would you upgrade to this version and let me know how the Sugar integration works out for you?
jpeterman - let me know if this works for you please - and sorry about letting the code fall out somehow. How embarrassing!

Tony

 

[Mysterious]

sadly it doesnt work. I only get back the called number not the name from sugarcrm. my nummber format is +49(7854)1234567. Changing ths to +4978541234567 doesnt really make an difference. At germany the maximum digits should be 15 digits with the international format 0049. with the short form +49 ist should be 13. May we could make some changes to the code which takes care of the extensions language ore an language field at he configuration of the freepbx plugin? MAy we could collect soem international formats here to make your impementation easier?