Fun with Normalization / Reverse-name lookups

In a UM/OCS environment, where does OCS use Normalization rules / Reverse-Lookups - or is it Exchange doing the work?  Why or why not does some feature work?

In this article I'll look at :

• Toasts
• Exchange Missed call notifications
• Conversation history

With a Nortel CS1000 integrated system - it can get pretty confusing.

Toasts

Toasts are interpreted by the OCS client directly

1)  A user calls in from OCS and they have Enterprise voice enabled.

Result:  The user name is displayed correctly - the line URI is where the lookup occurs.

2) A user calls in from the PBX

Result:  If you have enabled the Mediation server to send the user name forward as descried in KB article:  http://support.microsoft.com/kb/972721/, then the name is displayed in the Toast.  Otherwise, you only see the number displayed.

Unfortunately, if you have a Tanjay device (ip8540 or cx700), this will fail (at least as of version 3.5.6907.82), the toast will still fail come up correctly both on your screen and on the Tanjay.   The Tanjay is apparently responsible for this when you have it connected to your PC via a USB cable.

3) User calls in from outside (local or long-distance)

Result:  If you have Caller-ID, the name shows up correctly.  If you do not - it will only show the phone number.

Missed Call Lookup (Exchange UM feature)

1) A user calls in from OCS and they have Enterprise voice enabled

Result: If they have Exchange UM enabled, then the name shows up correctly in your missed call notification.   If the number is associated with the wrong user - that name will appear.

2) A user calls in from the PBX

Result: If the user is Exchange UM enabled, then the name will show up correctly in the missed call notification.  If not, then just the phone number will show up.  Again, if their name is your contact list, it will show up correctly.

3) User calls in from outside (local or long-distance)

Result:  Only users in your Outlook Contact list will show up correctly here.

Conversation History  (Reverse AD lookup)

1) A user calls in from OCS and they have Enterprise voice enabled

Result: Conversation history shows up correctly with the user's name and information.

2) A user calls in from the PBX

Result:  The CS1000 uses "local numbers" in their tel:URI's.  From RFC 3996  "The tel URI for Telephone Numbers":

5.1.5. Local Numbers


Local numbers are unique only within a certain geographical area or a certain part of the telephone network, e.g., a private branch exchange (PBX), a state or province, a particular local exchange carrier, or a particular country. URIs with local phone numbers should only appear in environments where all local entities can successfully set up the call by passing the number to the dialing software. Digits needed for accessing an outside line, for example, are not included in local numbers. Local numbers SHOULD NOT be used unless there is no way to represent the number as a global number.

6. Examples


tel:+1-201-555-0123: This URI points to a phone number in the United States. The hyphens are included to make the number more human readable; they separate country, area code and subscriber number.

tel:7042;phone-context=example.com: The URI describes a local phone number valid within the context "example.com".

tel:863-1234;phone-context=+1-914-555: The URI describes a local phone number that is valid within a particular phone prefix.


Unless you store your numbers in AD in "local number" format (and normalize them as such), you will not get an Active Directory match and it will actually put in a hyperlink that is exactly in this format (since it does not get normalized) which is uncallable.  

I recommend normalizing it back to a global number format:

^\+?(\d{10})(;phone-context=dialstring)?$
+$

...will remove this and put it he number in "global number" format.   This of course, will require you to know what the strings mean and how to interpret them correctly.   This is another reason to avoid using the local number format.

If / when the PBX does go away, this will also make the transition easier.