Caller ID Superfecta

Dev believes that 9 is the best choice - using the nine right-most numbers for typical 10 digit (USA) users, and the 9 (native) digits used by the EU, this default should work for most users without change.

We are awaiting user validation that 9 digits dies indeed match for both 10 digit and 9 digit users, then this updated source will be released.

Updated by patrick_elx
We can maybe add in the flyby a comment saying that if you are in a NANPA country the best value would be 10.
You want to put this value at the max significant digits for your scheme. It can be different for different users. But starting out of the box with 9 is a one size fit all to start with.

updated by tshif
testing results from mr. Mundy:
Sorry for delay. Database match fails when set to 9. American Airlines = 8004337300. Setting to 9 and searching for 8004337300 fails. Also search for 004337300 fails. So I recommend you set 10 as default.
--wm

Updated by tshif
More thoughts from Ward:

Just thinking out loud... Seems to me it would make more sense with AsteriDex and SugarCRM to match whatever number of characters are passed as the CallerID number, e.g. 12345 would search for all matches on 12345 and return the first one. 1234567890 would search for a match on that and return the first one. Because of MySQL indexing, right-to-left substrings are difficult to implement.

seems that the 00 at the begining of a number are ignored.
Maybe need to be forced as a string?

If the number sent has less than filter_length, only the number of digits should be matched.
If more than filter length, only rightmost filter length will be tested.

The introduction of these were for people storing information with international dialing code. If they have one source in their scheme, that's not a problem as you can put a filter to transform $thenumber to whatever way you want.
It become more complex when you have these numbers in one format in your database, and in another format in another source (web source or other database). That's why matching by number of digit was a way to alleviate it.

we can maybe add a filter length=0 to disable it for people who don't need it.

I'll try to have a look to fix the problem with the ignored leading zeros and to add the filter_length=0 option.

Is there really an issue here anymore? It looks like both Asteridex and SugarCRM both incorporate the "Filter Length" for the purpose of only matching a user specified number of rightmost digits. For situations where you need to search with different CID rules for different sources this can be easily accomplished by creating two different schemes.

Workaround can be accomplished with multiple schemes.