Caller ID Superfecta

From patrick in pbxiaf forum

Ok, that's not so easy..
The ENUM cid lookup in freepbx is in fact:
exten => cidlookup_1,1,Set(CALLERID=${TXTCIDNAME})})
exten => cidlookup_1,n,Return()

not really an ENUM lookup :-(

Actually - I had thought we would bypass the FreePBX enum lookup. Its trying to do phone number ==> IP, right?

We would need to code the script to ask for the (oft times available) extended data to retreive the names.

Thoughts?

Posted a script using EnumQuery.com here http://pbxinaflash.com/forum/showthread.php?p=41878#post41878

Please test and give feedback

This is pretty cool - sorry it took so long to get you feedback.

When tested against a known number registered with e164.org.

It seems queries sent to enumquery.com have to include the leading 1 - so format of (123)456-7890 (ten digit) doesnt work, we have to send them 11 Digits.

Here is the result:
Test User'>data:,CN=Test User sip sip:ENUM@csgt.us result details no records in e164.info (0.7.4.1.3.8.2.0.6.7.1.e164.info) result details no records in enum.org (0.7.4.1.3.8.2.0.6.7.1.enum.org) result details New query Enter a phone number (with country and area code) to perform another query:

The actual registered name is: Test User. So parsing adjustments must be made to stop the reesults after the name.

This is a GREAT start. I hope you will still have time to work on this so we can add it to the data sources. Its a natural since well all use voip. :)

More info:

Often times, this source works as expected.

17602831428 Works and returns: Test User1
17602831429 Failes with these results:

Sample User'>data:,CN=Sample User result details no records in e164.info (9.2.4.1.3.8.2.0.6.7.1.e164.info) result details no records in enum.org (9.2.4.1.3.8.2.0.6.7.1.enum.org) result details New query Enter a phone number (with country and area code) to perform another query:
result took 0.5480 seconds.

After saving the record again in e164.org, the result changed to this:
Sample User'>data:,CN=Sample User x-address

The only difference was how many times I had saved the record. I have no explanation.

We do need to figure out how to sent the leading 1 thought (for NAPA numbers) and country code format for others - right?

I tested this data source by editing line 24 from:
$url = "http://enumquery.com/lookup?e164=" . $loc_number;
to read:
$url = "http://enumquery.com/lookup?e164=1" . $loc_number;

This causes it to work fine - but its a kludge and it will only work for people in north america (NAPA) this way.

I think the solution is to add configuration options to thei data source (like many of the others have) that will allow the user to specific special characters, leading character, country codes, or the like when they need to.

Zorka - I am interested in your thoughts on this. I think this is a GREAT additonal source, and its soo close tobe ready for release. I support we could release it just for north america users now - but Id rather see ifyou have anyything up your sleeve to modify it to work outside that area as well.

Added to live update - with notes that it only works for 1NXXNXXXXXX numbers at this time.