Work Number displays as '+' on Phone Edition and fails on attempted dial

The post below comes courtesy of one of the partners in our voice program. I took the liberty of modifying the format of his email alias to reduce spam. He provided permission to include the details of his auto signature. I am also retaining the use of the term Tanjay in the body of the message given many do know this code name and may help in searches.

Mark Hickson
Practice Lead – Microsoft Unified Communications
Professional Services
UNIS LUMIN – Technology Based Business Solutions
mhickson (at) unislumin.com

Recently I noticed that work numbers for contacts were appearing as simply ‘+’ on my Tanjay phones.  Attempting to dial this number would fail (not surprisingly!).  If I entered digits on the Tanjay manually, however, my normalization rules would take effect and the number would both appear and dial correctly.

This is a particularly poor quality picture (sorry!) of my Tanjay exhibiting this behavior…

My company has 3-digit internal extensions, so in Active Directory in each User’s Telephone (i.e. Work) number field there is 3 digits, such as “328”.  I have a normalization rule in OCS that adds a ‘+’ … so “328” becomes “+328”.  This normalization occurs correctly when entering digits on the Tanjay, and the call succeeds.  The work number, however, listed on my Users’ contacts cards displayed only ‘+’.  It should have shown “+XXX”.

This is what my Active Directory User properties look like…

At the same time that I was trying to figure out my Tanjay problem, I had a another problem within Office Communicator.  These same 3-digit extensions would appear in the contact card for users, but they would appear without the ‘+’.  So “328” would be displayed just as “328” and not “+328”.  (I would have expected that the behavior be the same on both clients – so either both displayed just “+” or both displayed just “328”)

Furthermore, attempting to dial this number in a click-to-call scenario (i.e. selecting the number from the list of numbers for a Contact) would result in a failed dial.  Communicator would attempt to dial “328” and not a normalized “+328”.  Once again, typing in “328” in the MOC Find box would result in a correctly normalized number of “+328” and a successful dial.

So, to summarize…

MOC

Displayed number on contact card:  “328”

Click-to-call “328”:  FAIL

Enter digits “328”:  Normalize to “+328” and SUCCESS

Tanjay

Displayed number on contact card:  “+”

Click-to-call “+”:  FAIL

Enter digits “328”:  Normalize to “+328” and SUCCESS

In the end, fixing one problem fixed them both.  Gotta love it when that happens!  :)  Here’s what I did…

I needed to place a normalization rule in a file called Company_Phone_Number_Normalization_Rules.txt in the ABS shared folder.  The rule is a standard 3-digit normalization rule, like I have in my Enterprise Voice settings for the Location Profile.  In the file, it looks like this…

##

## ddd

##

(\d{3})

+$1

The first part with the # characters is just a comment, the (\d{3}) line is the pattern to match, and the +$1 is the translation.

I also had to enable the use of both Generic and Custom rules on the Address Book Server.  This is done using the ABSConfig.exe utility that comes with the Resource Kit Tools.  It looks like this…

Now, initially I didn’t think this did anything because the display of the 3-digit number on my contact card in MOC did not change – it still displayed “328”.  Dialing the number, however, started to work!  Turns out the displayed number and the dialed number are different.  Both of these numbers come from the local GalContacts.db file.  Opening the file (in Notepad) and inspecting it revealed data that looks like this…

Of note here is that my extension “328” is included twice, once simply as “328” and once as “tel:+328”.  So the conclusion here is that the “328” is used for display in my contact card on MOC and the “+328” is used as the number dialed in a click-to-call scenario.  Before I made the changes to the ABS Server, both of these numbers were just “328”, for example “328” and “tel:328”.

Now, I mentioned earlier that changes made to correct one problem also corrected the other.  The day after I made these changes the phantom “+” on my Tanjays disappeared!  The reason makes perfect sense…

Numbers dialed as a result of digits being entered are subject to normalization rules specified against the Location Profile in your Enterprise Voice settings.  This is true for both MOC and Tanjay as both download the normalization rules on sign-in.  This is why number display and dialing worked fine on both devices.

Numbers listed on users’ contact cards come from Active Directory and normalization rules for these numbers are applied by the Address Book Server.  So once the normalization rule for “XXX to +XXX” was added to the Normalization Rules text file and the Address Book Server was configured to use them, the Work numbers were correctly normalized and made available to both MOC and Tanjay.  It turns out Tanjay uses a slightly different set of Address Book Server files (a reduced set of information to decrease download time) but both clients rely on ABS to perform normalization for these numbers.

I hope that my experience will save you time in troubleshooting, but more importantly help you gain a better understanding of what’s going on behind the scenes because that’s what I got out of this experience, apart from solving a very large company-wide problem, of course!  :)

Cheers,

Mark