Normalizing Phone Numbers

Toate mesajele

• 28 aprilie 2008 22:50

  Moderator

   

   
  

  0

  I suggest ginving this a read to understand some of the behavior of the ABS and why some things don't appear as one would think:

  https://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=26

   

  To clarify, do you mean the numbers don't appear on the contacts in OCS, or the entire contact doesn't appear at all when searched for in the OC client?  If the former, you probably aren't getting the number nomralized into E.164 format (as explained in my blog entry), but if the latter then it doens't have anything to do with the Address Book Service and number normalization.
   
• 30 aprilie 2008 14:14

   

   
  

  0

  I started out with none of my Global Address contacts from AD showing when I searched in the OC.  I normalized our main 5 digit dialing scheme with (\d\d\d\d\d) in the Company_Phone_Number_Nomalization_Rules.txt file.

  This pulled most of the contacts in and allowed them to be searched in OC.

  Next I added this for the xxxxx/xxxxx numbers:

   

  \s*(\d\d\d\d\d)[/](\d\d\d\d\d)
  $1/$2;phone-context=microsoft.com

   

  This looked to normalize them as it passed the tests and removed them from the Invalid_AD_Phone_Numbers.txt file but the contacts do not show at all when searched for in the OC.

   

   

   
• 30 aprilie 2008 15:15

  Moderator

   

   
  

  0

  Once again, if the Contacts themselves don't even appear in OC when searching, that is not related to number normalization.  But if you mean that just the phone numbers for the contacts aren't appearing then that is because you are not normalizing the numbers into E.164 format.  OC will not display the numbers unless they are normalized ino that format (+13125551234).

   

   
• 30 aprilie 2008 20:31

   

   
  

  0

  The entire contact is not showing in OC when searching.

   
• 5 mai 2008 20:52

  Moderator

   

   
  

  0

  Just an idea here, how are you searching for Contacts in the Find bar?  Try typing in their actual sip address (instead of a Display Name) and see if that makes a difference.

   
• 8 mai 2008 19:28

   

   
  

  0

  Typing the SIP address did not make a difference.

   

  When I first started, nothing showed in my Communicator contacts except my local contact list.

   

  After I added (/d/d/d/d/d) to the normalization rules then our normal 5 digit number contacts (located in the Telephone Number section in AD) started to show in Communicator.

   

  The contacts with other numbers schemes such as:

   

  15154; 15385

  15015/18021

   

  are the only contacts that do not show in Communicator.

   

   

   

   

   
• 15 mai 2008 00:55

   

   
  

  0
  My experience in a RCC deployment has been that E.164 numbers are not required for proper display of the MOC address book. I've gone into more detail in a reply to Jeff's fantastic blog post linked above.
  
  Cameron
  
   
• 19 mai 2008 15:35

  Moderator

   

   
  

  0

  The behavior I've seen is that 10-digit numbers missing the + will not be displayed by the Office Comunnicator 2007 client when selecting numbers from the phone drop-down menu on the Contact.  One potential problem is that there are so manu different places to find phone number information in OC and Outlook than some people may be talking about different scnearios.

   

  But if you are seeing something different then there may be some specific environmental setting (or possibly a change in the latest round of OC client patches).  I have seen 4-digit number display without the +, but not 100% of the time.  There seems to be a +/- factor that effects the number display as even in my testing I would see a small amount of exceptions to almost every rule.

   
• 3 octombrie 2008 18:56

   

   
  

  0
  Jeff - I'm hoping this is an easy question for you, regarding those phone numbers and normalization.

  
  

  I've got the normalization working as far as I can tell. We have not hooked up a mediation server and latched OCS into CallManager yet, but that's coming soon. I'm curious, though, should the normalization rules apply to the numbers I see when I click the down arrow next to the phone icon by a person's name in Communicator? The numbers are still showing the Active Directory format (most are #####). Do the normalization rules kick in as OCS sends the number out to CallManager, or should the rules kick in while inside Communicator as well?

  
  

  Thanks,

  Paul
   
• 6 octombrie 2008 12:35

  Moderator

   

   
  

  0
  The behavior I've seen in that scenario is that numbers will display as normalized on the fly for strings typed into the Find bar, but not always on a clicked contact's numbers.  I swear it would show both normalized and unnormalized for the same and different users on different days with absolutely no changes to the AD attributes or the normalization rules; it was just not consistent.  But OC would always dial correctly as the normalized dial strings would be passed to CUPS correctly.  Do it was just a 'display thing'.  I was never able to have MS confirm that as the PSS team I was working with did not have an RCC deployment to test with.
   
• 7 noiembrie 2008 06:58

   

   
  

  0

  All this time I thought this was a problem with the way the number was being normalized.  I have created proper normalization entries in the Company_Phone_Number_Normalization_Rules.txt file and ran all tests to verify that the number is correclty normalized.  I am seeing inconsistent results in the MOC.  I see some 10 digit numbers like 3125551212 and others like +1 (312) 555-1212 which is how I would prefer it would be.  Is this the same inconsitency you are talking about? 

   

  Also 4 digit numbers entered show as 1078.  I have a rule created to change them to +1 (312) 555-1000 x1078 some show this way in MOC and some do not.  Very confusing.

   
• 7 noiembrie 2008 12:52

  Moderator

   

   
  

  0

  The problems I saw were only on how the number appeared under contacts names in OC. The actual normalization of the number string and passing off to the phone system (in RCC) always worked correctly, regardless of how the number string was displayed in OC.  So it was just a display issue, but looked quite confusing.

   
• 7 noiembrie 2008 16:01

   

   
  

  0

  That is correct.  My calls always go through but the display of the number is not in a nice format.  It just showes..

   

  3125551212 instead of +1 (312) 555-1212.  It used to until I apllied the October MOC update I am going to re-install it without the update and see what happens.

   

   

   

   
• 12 noiembrie 2008 23:05

   

   
  

  0

  I found out why the format is inconsistent.  IT all depends on the way the number is entered into AD.  If it is entered as 4255551212 it is displayed that way is MOC.

   

  If it is entered as +1 (425) 555-1212 it will show that way in MOC.  That was really buggin me, glad to see that working correctly.

   

   
• 13 noiembrie 2008 13:34

  Moderator

   

   
  

  0

  Just to point out that may not be be true in all cases. The largest environment that I saw those display issues had all numbers entered in AD in the exact same format (not E.164) and numbers displayed in OC would show as either the same as in AD or in E.164 format, and it's changed day-to-day on the same user/number when no changes were made to their AD attribute.  OCS always passed them as E.164 to CUPS.

   
• 13 noiembrie 2008 20:47

   

   
  

  0

  Hi Jeff,

   

  Thanks so much for your article it is really good. I went through my AD and set all them up in a standard but I didn't make them E.164. I was hoping to use the .txt file for this. I created my .txt file from your article with the standard syntex. The problem I facing is in Communicator it is not putting the +1. It is formatting everything else correctly but no "1". It puts the +. I have placed the example I am using. Any help would be great.

  ##
  ## Normalize all AD phone numbers to E.164
  ##
  \+?[\s()\-\./]*1?[\s()\-\./]*\(?\s*(\d\d\d)\s*\)?[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)[\s]*
  +1$1$2$3

  #
  # Test strings used with the "abserver.exe -testPhoneNorm" command to verify each rule
  #
  # (All Test strings below should be commented-out for proper operation, do not remove the initial '#')
  #

  #TestInput: (312) 555-9500 TestResult: +13125559500
  #TestInput: 303-350-2406 TestResult: +13003332332
  

  The test come back with Passed.

   

  Thanks in advanced

  
  Tony

   
• 13 noiembrie 2008 20:56

   

   
  

  0

  I'm sure you guys are on top of this already, but AD contacts and Outlook Contacts both get normalized into the same address book that Communicator presents with normalization rules applied differently based on their origin. The AD stuff gets normalized on the ABS, and the Outlook Contacts appear to get normalized by the client based on registry settings on the client. The net result is that the people you most often communicate with can show up multiple times in the Communicator address book (if you use different naming conventions in AD versus Contacts), and it can be tricky to identify if you are fighting with Contact normalization or AD normalization. Can't remember what I posted in Jeff's blog, so forgive me if I repeated myself... :-)

   

  Cameron

   
• 13 noiembrie 2008 21:29

  Moderator

   

   
  

  0
  Cameron, one thing I wanted to point out is that registry setting in OC (HKCU\Software\Microsoft\Communicator\PhoneNumberNormalizationRules) is actually created FROM the Address Book normalization file.  It's the entire file, stripped of any comments, with the default built-in rules add to the end of the string.
   
• 14 noiembrie 2008 04:28

   

   
  

  0

  Absolutely agree! I noticed that during our deployment. I guess the takeaway I should have focused on for other readers is if you don't consider every possible way people might enter a phone number for their Outlook Contacts, those contacts may show up in an unexpected fashion in the Communicator Address Book and dialing them may fail. Outlook seems to limit how you can enter a number to some degree, but there are still lots of supported permutations.

   

  Going down that rabbit hole eventually leads to you adding entries to your address book normalization file explicitly for normalizing your user's Outlook Contacts to support RCC. I probably have 40 normalization rules in my file on the ABS explicitly for Outlook Contacts. 

   

  Yours and Matt McGillen's blog posts really came in handy while I was fighting with an early RCC deployment. Thanks for putting your experiences online!

   

  Cameron

   

   
• 14 noiembrie 2008 13:10

  Moderator

   

   
  

  0

  Cameron,

   

  Glad our experiences could ease some pain for others

   

  I think this thread is proof enough that (barring complicated RCC deployments) corporations should start be following recommendations for populating and enforcing AD phone numbers attributes in E.164, as well as educating users on how best to store phone numbers in personal contacts.  These AB normalization rules can start to get out of hand quickly and become overly complex in time.

   

   
• 19 noiembrie 2008 17:28

   

   
  

  0

  Jeff Great post.

   

  i have a couple of questions about the normalization of outlook numbers. I have all my rules setup correctly on the ABS server and all normalization tests work find and normalize as expected. However some of the outlook numbers are not normalizaing the same.

   

  and it appears the reg key is not being updated. I am reviewing it now but wanted to see if you have run into this.

   

  thanks.

   

   
• 19 noiembrie 2008 17:43

   

   
  

  0

   

  I removed the entire value of the key and everything still works ok.  I am not quite sure how that key affects anything.