locked
Customizing Company_Phone_Number_Normalization_Rules RRS feed

  • Question

  • I'm trying to find documentation on how to write your own custom normalization rules in the Company_Phone_Number_Normalization_Rules.txt file. Does anyone have any resources for this?

    I can't tell what this does, exactly, just by looking at it....or any other example in Sample_Company_Phone_Number_Normalization_Rules.txt for that matter.

    (\d\d\d)[\s()\-\./]*(\d\d\d\d)\s*[Xx]+(\d\d\d\d\d)
    +1425$1$2;ext=$3

    Tuesday, February 5, 2008 1:17 PM

All replies

  • I agree that the sample text file could use a little better explanation in the comments.

     

    Here are a couple links to get you started.

    http://www.regular-expressions.info/ (The parsing language is known as "Regular Expressions".)

    http://technet.microsoft.com/en-us/library/bb870362.aspx

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

    http://www.microsoft.com/technet/prodtechnol/office/livecomm/library/abs/lcsabs_7.mspx

     

    A few tips:

    • Unlike the EV dialing rules, ABS rules do not need to be encapsulated between ^ $, the ABS service automatically adds them when processing.
    • The client workstation stores the configuration file content in the registry key: HKEY_CURRENT_USER\Software\Microsoft\Communicator\PhoneNumberNormalizationRules

    Here's an example which is a bit easier to reverse-engineer. It will normalize any 10-digit format regardless of formatting (spaces, dash, (), etc) into +91xxxyyyzzzz.

     

    Code Snippet

    #

    # (312) 555-1212

    #

     

    \(?\s*(\d\d\d)\s*\)?[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)[\s]*

    +91$1$2$3

     

    And here's a more customized example; it will normalize a specific number block down to a 4 digit extension:

     

    Code Snippet
    #
    # 312-555-1600...1699
    #
    \(?\s*(312)\s*\)?[\s()\-\./]*(555)[\s()\-\./]*(16\d\d)[\s]*
    +$3

     

     

     

    Tuesday, February 5, 2008 2:43 PM
    Moderator
  • That particular rule looks for a 7 digit number with an extension on the end and normalizes it to add +1425 to the front and the proper e164 format for the extensions on the end.

     

    The enterprise voice route helper in the resource kit has an interface where you can build test cases and type in numbers to see how they normalize.  I'd recommend tinkering with that once you figure out the basic RegEx syntax.

     

    Tuesday, February 5, 2008 8:35 PM
    Moderator
  • I would much rather learn how to make these customized normalization rules on my own; but in the interest of time, at least for now if you could please, help me with the normalization rules I would need for these formats:

    ddd-ddd-dddd
    ddd-dddd
    ddd


    I'm a little surprised the built-in rules can't normalize these phone numbers in this format, but yet they all show up in the Invalid_AD_Phone_Numbers.txt

    There is one rule defined in the Company_Phone_Number_Normalization_Rules.txt for ddd-dddd. The normalization rule is:
    Code Snippet

    (\d\d\d)[\s()\-\./]*(\d\d\d\d)
    +1425$1$2




    But I assume I need to edit the "+1425" to our local area code to make this work properly.
    Wednesday, February 6, 2008 12:29 PM
  • I would much rather learn how to make these customized normalization rules on my own; but in the interest of time, at least for now if you could please, help me with the normalization rules I would need for these formats:

    ddd-ddd-dddd
    ddd-dddd
    ddd


    I'm a little surprised the built-in rules can't normalize these phone numbers in this format, but yet they all show up in the Invalid_AD_Phone_Numbers.txt

    There is one rule defined in the Company_Phone_Number_Normalization_Rules.txt for ddd-dddd. The normalization rule is:
    (\d\d\d)[\s()\-\./]*(\d\d\d\d)
    +1425$1$2

    But I assume I need to edit the "+1425" to our local area code to make this work properly.
    Wednesday, February 6, 2008 12:32 PM
  • Yes, just change the area code from your example. This would be for the 10 digit version...

    (\d\d\d)[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)
    +1$1$2$3

     

    Don't forget to add your digit after the plus to get an outside line.

     

    The resource kit book also has more examples and deployment scenarios for normalization...

    http://www.microsoft.com/MSPress/books/10482.aspx 

     

     

    Thursday, February 7, 2008 8:14 AM
  •  

    I don't understand this. I have the normalization rules configured to "Apply only company-specific normalization rules".

     

    In Company_Phone_Number_Normalization_Rules.txt I have the following:

     

    (\d\d\d)[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)
    +1860$1$2$3

    (\d\d\d)[\s()\-\./]*(\d\d\d\d)
    +1860$1$2

    (\d\d\d)
    $1

     

    This is supposed to normalize the three types of phone numbers we use in AD:

    ddd-ddd-dddd - mobile phone

    ddd-ddd - direct line

    ddd - extension

     

    Yet some inconsistent things are happening.

    Note: ALL users have these numbers in AD.

     

    1. Some contacts only have one number showing up, some have two, and some have four. None seem to only have the three.

    2. For the people that have four, I think there is a problem with my rules. I think the ddd-dddd numbers are being normalized twice. I'll end up with two mobile numbers for these contacts, one in the format ddd-ddd-ddd normalized properly, then another that shows up like +dddddddddd. Yet for some users, only the 1 normalized mobile number shows up.

     

    I feel like my rules might be processed more than once and are causing problems. Example, ddd could match all three of my rules. Any idea how I can fix this?

    Friday, February 8, 2008 3:06 PM
  • One important thing to point out is that Communicator will NOT display phone numbers pulled from AD attributes unless they are normalized into E.164 format.  So your last translation rule would correctly normalize the number, but OC will not show that in the client; this behavior is hard-coded.

     

    First off, take a look at the invalid file that is created and see if the rules are correctly prcessing the numbers.  Your current rule doesn't allow for numbers or characters preceeding the area-code, so make sure that your attributes are populated in a uniform pattern.

     

    When a number is processed it will start top-down, and the first correct normalization will translate the number and then stop, so put the more specific rules towards the top and more generic rules towars the bottom.

     

    One other tip: If a phone number is populated in AD, Communicator will display the number (assuming the criteria above is correctly met) regardless of the contacts Access Level.  The access levels only apply to phone number entered in the OC client's Phones Tab by the end user.  This is documented in the Office Communcator 2007 white paper.

    Friday, February 8, 2008 4:20 PM
    Moderator
  • Great information. I'm learning a lot more about this than I anticipated.

    Invalid_AD_Phone_Numbers.txt only has one error:

    Unmatched number: User: 'testaccount'  AD Attribute: 'telephoneNumber'  Number: 'none'

    ...which seems expected. From this, can I assume that all the numbers are sucessfully being normalized?

     

    I'm still unsure about the inconsistent display of numbers in communicator. I have two different things happening. For example, take two different active directory user accounts:

    User1

     Telephone Number: 256, Other: ddd-0305, Mobile: 860-ddd-7712

    User2

     Telephone Number: 237, Other: ddd-6967, Mobile: 860-ddd-8664

     

    Yet this is how the numbers show up in Communicator:

    User1 [no work number shows up]

     Mobile 860-ddd-8664

     Other ddd-6967

     

    User2 [work number shows up, but mobile is displayed twice]

     Work 237

     Mobile 860-ddd-8664
     Mobile +860ddd8664
     Other ddd-6967

     

    Why do you think I'm getting these inconsistent results? Every contact in Communicator is displaying their phone numbers using either of the two examples shown above.

    Friday, February 8, 2008 5:15 PM
  • I'm glad I wasn't the only one "seeing things"; a co-worker and I spent some time with MPSS customizing a RCC configuration and we saw the same issues.

     

    Although we did see some differences between LCS and OCS users (mid-migration), the more I looked, the more I saw the results (seemingly) arbitrarily changing over time.  The numbers sometimes displayed in different normalized formats, but it consistently affected only the display of the numbers in OC, the actual normalization (and thus, passing of the number string to RCC) worked 100% of the time.  So the numbers awalys dialed correctly, but their appearance in OC would randomly shift.

    Friday, February 8, 2008 5:28 PM
    Moderator
  •  

    That's not very encouraging. Well I suppose if the numbers are dialed correctly, that's what really matters. But that doesn't help for the work extensions that don't show up at all for some contacts. Any suggestions?
    Friday, February 8, 2008 5:42 PM
  • This blog entry helped me as well when I was configuring ABServer and the Normalization Rules txt file.

     

    http://blogs.technet.com/toml/archive/2008/06/02/work-number-displays-as-on-phone-edition-and-fails-on-attempted-dial.aspx

     

    Jamie Schwinn

    www.systmsny.net

     

     

    Friday, September 19, 2008 1:42 PM