To simplify things a bit, think of VoIP calls using SIP as e-mails. There is a TO: and a FROM: header. The TO is the called number and the FROM is the calling number, or the Caller ID.
TO:+18005551212
FROM:+18885552121
The good news is OCS can and will normalize the TO or called number via normalization rules in the Location Profile that is configured in the Voice Properties. The bad news is OCS cannot normalize the number in the FROM: header, or Caller ID.
This means that OCS can't really provide any caller ID information right? Wrong. It can, but only for contacts that exist in either the Active Directory or your personal contacts in Outlook. How it does this is where it gets confusing.
In typical OCS deployments the calls coming in to the Communicator client (MOC) will have both the TO and FROM numbers in E.164 format. The TO will have been normalized by the rules either on the Mediation Server or the OCS Front-End Server. The FROM will have been normalized from the Gateway. If not, this must be configured. Otherwise caller ID information for all inbound calls will fail.
The Address Book Server component of OCS also contains a set of normalization rules that it uses to build the address book. The rules are different that those in the Location Profile. As a matter of fact, they don't even use the same syntax as those in the Location Profile. The purpose of these rules are to normalize numbers that are stored in Active Directory and your personal contacts in Outlook. When these numbers are normalized they are put into the address book file which the MOC downloads daily.
When a call is received by MOC, MOC looks in its local copy of the address book, called galcontacts.db, and tries to match the FROM number to an entry in the file. If one is found, it then displays the Name and Phone Number for the person calling.
So what if the numbers in Active Directory or your personal contacts aren't normalized to E.164? Then there is no match and therefore no caller ID. The generic built-in normalization rules that the Address Book Server use are often good enough, but in some cases you may need to create custom rules for your organization. Microsoft provides a sample set of customized rules called Sample_Company_Phone_Number_Normalization_Rules.txt. There are many different articles explaining how to rename this sample and use it. I don't recommend it. Once you use a set of custom rules, the generic default rules are ignored.
Refer to the sample for the correct syntax and create a custom one specific for the organization.
There are a few things you can do to test what rules are in use today and the results. The best thing to do is see the contents of the galcontacts.db. This can be done by adding the following registry entry.
HKCU\Software\Microsoft\Communicator Dword: DumpContactsToCsvFile Value=1
This key dumps the contents to a file called Contacts.csv. The file is accessed directly from MOC. Select Tools -> View Received Files
