Reverse number lookup in Office Communicator

As part of my grand unified communications adventure (more on which later), I needed to get reverse number lookup (RNL) working with LCS. RNL is a simple concept: when you get a phone call from extension 1001, you want your computer to identify the caller as John Smith, not as ‘1001’.

Communicator looks up numbers using one of two sources:

• the address book produced by the Address Book Service on the LCS server; this is generated daily from whatever you’ve got in Active Directory.
• contacts in the user’s local Outlook address book (or Windows address book)

When you place a call to a Communicator user, the PBX sends a CSTA message that includes a device identifier, like this:

<deviceIdentifier>tel:1001; phonecontext=pbx.litware.com</deviceIdentifier>

(or maybe <deviceIdentifier> tel:+16175552702;ext=52702</deviceIdentifier>

Communicator will try to match the device identifier against one of the numbers it can see in the address book or the Outlook contact. If it matches, it displays the caller info; if not, you just get the number. You can add this information manually, but the preferred way to do this is to put the callers’ numbers into a multivalued attribute called proxyAddresses. However, we were in somewhat of a hurry. The simplest solution for us was to add the “TEL” URI of the associated extension into the “home” phone number field of each user object. This would more sensibly be done by a script, but for our lab environment, which only has a handful of extensions, it was a quick solution.

I also created phone normalization rules on the LCS AB server to ensure that the extension numbers and master phone number were properly represented. This was pretty easy, except that apparently you have to put the same rules in both the generic rule file (Generic_Phone_Number_Normalization_Rules.txt) and your site-specific rule file (Company_Phone_Number_Normalization_rules.txt). That’s because the “generic” normalization rule file is used to do on-the-fly normalization, while the “company” file is used to pre-normalize numbers before storing them in AD.

The normalization rules turn phone numbers into a normalized form. For example, 4-digit extensions (e.g. “1003”), extended numbers (e.g. “617-555-1212 x1003” or “617-557-2512;ext=72512”), and E.164-based numbers can all be converted into a consistent format. LCS includes a standardized set of normalization rules that will work for most sites; they include normalization for E.164 numbers, which is very handy if you’re working with contacts that have international numbers.

One other thing to watch out for: Communicator fetches the address book file once daily (apparently at 0130, though I wasn’t awake that late to test it.) If you do an abserver -syncnow on the LCS server to force an update, the client won’t get the updated address book, even if you quit and relaunch, until the next sync interval. It took me a while to figure this out; I couldn’t understand why the client wouldn’t pay attention to my changes. To speed things up, you can manually delete the GalContacts.db file from %userprofile%\appData\Local\Microsoft\Communicator, which will force Communicator to refetch the file. Of course, you won’t have to do this in a production environment.

Update: Duncan Blake of Microsoft pointed out two minor errors in my original post, which I’ve corrected– thanks, Duncan!