Caller ID Superfecta

Version 2.2.x of Caller ID Superfecta: THE MODULE provides for multiple CID Schemes.

Theory of Operation
If you have DIDs in different countries, you would create a different scheme for each country.

As a general rule, the most effective use of CID Schemes would be:

• create one scheme per country in which you have DIDs.
• Create additional schemes for specific/non standard DIDs when you need to use a filter to change the way the number is presented.

Some sources - such as infobel, also accept parameters such as `Default Country`.
This source does support multi country per default, but the purpose of the country option is only to recognize a phone number that would come without a country code in front.

If your DID/trunk is in one country, that's the country you need to put in this option, as your provider will present national numbers without country code.

You probably wont want to try a national number against all the infobel sources. It would take a few seconds per source and you can have false answers as the same number can be allocated in different countries.

Zap Trunk Provided data source and CID Rules (8/11/10)
At least one user has reported issues when using the Trunk Provided data source in conjunction with CID rules and Zap trunks. When used within a single scheme, this combination produces unexpected (poor) results.

The best way to configure multiple data sources that include "Trunk Provided" and CID rules is to separate them into at least two different Schemes.

In the first scheme, have only the Trunk Provided data source with no CID rules.

In a subsequent scheme, include all of the remaing lookup sources and any necessary CID rules.

Asterisk Phonebook and multiple schemes (8/23/10)
Individual data sources that require different CID rules for the same incoming CID can be separated into different schemes, each with different CID rules. Take this real world example: suppose you want to use the Asterisk Phonebook as a lookup source, and you have imported thousands of numbers from another source. Further suppose that the numbers are not stored consistently, they are a mix of 7 digit, 10 digit or 11 digit numbers (we are assuming North America). In this case there is also a mix of ZAP and VOIP trunks so the incoming CID could be 7 digits, 10 digits or 11 digits. In the above example, even editing all of the phonebook numbers such that they were all the same number of digits would not solve the problem because of inconsistent incoming CID. Schemes to the rescue. Scheme#1 passes the CID to the phonebook with no CID rules. Scheme#2 passes the CID to the phonebook with 7 digits only, so create CID rules that strip off the incoming local 1NPA. Scheme#3 passes CID to the phonebook with 10 digits, so create CID rules to strip off the leading 1 and also append your local NPA to 7 digit numbers. Scheme #4 passes CID with 11 digits, create CID rules to add the digit 1 to 10 digit numbers and 1NPA to 7 digit numbers.