Multiple Work Phone Numbers _ Address book issue? RRS feed

  • Question

  • We are using enterprise voice.

    The issue impacts a limited number of users. When I look at the options for calling a user in communicator two work phone numbers are listed.

    The two work phone numbers are the same but formatted slightly differently

    Further one number works while the other doesn't. ie one will fail when you click on it and choose call.


    For example one number is listed as +44 (0) 207 xxx while the other is listed as +440207xxx

    It is the second number which isn't working

    Looking in AD there is only the +44 (0) 207 number. I have no entry for the user in outlook. The user has not published any other numbers in communicator.


    We do have a number of normalization rules in Company_Phone_Number_Normalization_Rules.txt

    Key one for this is

    # +44 (0) ddd-dddd. Look for numbers which start (+44) (0) or some combination of + 44 0


    Thanks for any help





    Wednesday, October 1, 2008 2:51 PM


  • That is exactly what Matt and I have seen on a few occasions with RCC+CUPS deployments.  I haven't tracked done a root-cause as the issue seemed to 'jump around' between users and we couldn't find a commonality.  I chalked it up to 'bugginess' for the time-being.


    Thursday, October 2, 2008 6:01 PM

All replies

  • Does OC display both numbers under the user as Work, or is one labeled as Work and the other shown as Other?  Are you positive that the otherTelephone attribute is not populated in AD?  It's in the Other... button in ADUC next to the work number.


    That said, I have seen this quirky behavior on multiple occasions and it has something to do with how the ABS normalization operates.  I've seen different users with identical number strings show single or double entries in OC and it appears to arbitrarily change on it's own as well.  Maybe the order of your normalization rules needs to be played around with?

    Thursday, October 2, 2008 1:18 PM
  • Thanks for the reply _


    Like you I was wondering if it was other etc or another number in AD but checking the user I see the following


    In Communicator, I click on the more options by the phone symbol.

    In the drop down I see


    +44 (0) 207 ....


    +44 (0) 776 ...



    (Same number as the first work number but without spaces, brackets etc)

    New Number

    Communicator Call


    in AD I have had a good look at his phone numbers

    He has the main tel no (with no others), mobile (with no others) and a Fax number (with no other and which is not listed in communicator)


    The rule to take out +44 (0) is the first in the list.








    Thursday, October 2, 2008 1:32 PM
  • That is exactly what Matt and I have seen on a few occasions with RCC+CUPS deployments.  I haven't tracked done a root-cause as the issue seemed to 'jump around' between users and we couldn't find a commonality.  I chalked it up to 'bugginess' for the time-being.


    Thursday, October 2, 2008 6:01 PM
  • Thanks. I suspected that might be the case.


    Friday, October 3, 2008 7:11 AM
  • Has anyone ever found a resolution to this?  I'm having the same issue, two work #'s, one showing correctly, the other showing as +nnnnnnnnnn format.
    Thursday, July 30, 2009 9:25 PM
  • Note that the way Alistair describes the numbers in AD is really not what is recommended. The 0 or (0) is definitely not a good thing. Could be part of the issue.
    Monday, August 10, 2009 7:39 PM
  • I have an idea about this with the help of Microsoft.  We are seeing the same behavior in our shop and it appears to have turned up after we made some changes to our tel URIs and RNL(Address Book Rules). 

    We made the changes last night and told our users to sign out/in on all of their endpoints, MOC, Tanjays, CoMo, etc.  For those who did before the 1:30 Address Book run, their info shows up with a single correct work number.  It appears that those who didn't have 2 work numbers, 1 being the "new" one and one being the one generated in the prior day's Address Book run appearing when you right click them and hover over Call in MOC.

    According to Microsoft, this will "clear" up in a few days after all the users have signed out/signed in their end points.  They way they explained it to me, and pardon me if I butcher it, when an end point comes on line publishes it's info to the presence engine it also publishes the user's phone numbers as the particular MOC end point knows it.  If you have several end points that have used different versions of the Address Book database, they could publish different phone numbers.  In our case, before the change, the Work number was formatted as +9999 and afterwards as +13334449999 so the presence engine got two versions of the work number and decided to publish both back to the contact's subscribers!  I was able to verify this a few ways, firstly I looked in my galcontacts at one of the contacts with two work numbers.  I found that contact's work number with the new formatting +13334449999 but did not find a work number formatted as +9999.  On Microsoft's suggestion I ran a dbanalyze /report /user:<<sip address>> against the user with the 2 work numbers and under "Static Publications" and one of the contact cards, I found a contact card like this:

    Category Name    : contactCard
    Container Number : 300
    Instance Number  : 3
    Version          : 50
    LastPubTime      : 8/21/2009 7:26:06 PM
    ExpiresAt        : NULL
    Data             : <contactCard xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard"><company>Enabling Technologies</company><title>Project Manager</title><phone type="work"><uri>tel:+9999</uri><displayString>333-444-9999</displayString></phone><phone type="mobile"><uri>tel:+19999999999</uri><displayString>999-999-9999</displayString></phone></contactCard>

    Note a few things here: Firstly, the record was created over 6 days ago, secondly note the tel: is using the old format!  According to Microsoft this is showing what's going on.  Again, I think the answer I got from them was to make sure all the users signed out/in and wait a few days for it to clear up.

    I hope this helps and welcome any comments.


    John Miller
    Enabliing Technologies
    Thursday, August 27, 2009 2:18 PM