Caller ID Superfecta

I don't think doing this would take very long, but sources that are meant or US numbers will probably fail. As long as they fail gracefully we should be alright.

I do want to see a couple of weeks of bug-free operation before we start working on new features like this though. We'll give a couple of weeks for forum members to report bugs.

I completely agree.

Here is another scenario to think about while discussing other number formats. (http://pbxinaflash.com/forum/showpost.php?p=26968&postcount=54)
Basically - User has multiple DID providers. Two of them pass the CID number as a 10 digit number. The other passes it as 11 digits with a one at the front. This messes up look ups from the asterisk phone book as these numbers get cached as 11 digit.

The previous solution was to make a small mod to make sure the numbers were all being stored in 11 digits no matter which provider it was.

User doesn't want to have to manual mod each new revision, I agree. We need to Consider ways to address this type of issue as we consider other numeric formats from other countries than the US.

We could take two approaches to this as I see it (there could be other approaches).

In allowing international phone numbers, we could never care about the length of the phone number. The script would accept the length of the phone number and attempt to process it at whatever length given. So in the case of the forum user you referenced, if his provider passed 11 digits, the script would process using all 11 digits. Preliminary testing indicates that at least some of the sources will return results if a "1" is added to the front of phone numbers.
The limitation to this approach is that if his other provider passes 10 digits, then a second lookup occurs, and the results aren't gotten from cache

The second approach would be to allow the user to define their country code in the UI, and the length of phone numbers without the country code. This may have negative effects on people who call international a lot, particularly for those who are located in Europe.

Look at my ticket 151 that could provide a framework to solve these issues.

Sources that need valid US and Canadian numbers are now checking for that validation in the individual source files. The limitations on phone number formatting has been moved out of the main module. This means the module should now support other phone number formats.