locked
Enterprise Voice Route Helper disagreeing with abserver.exe RRS feed

  • Question

  • Hello,

     

    In my AD I have lots of telephone numbers in the North American format 555-123-4567 and as expected these appear in Invalid_AD_Phone_Numbers.txt.

     

    Using the Enterprise Voice Route Helper from the resource kit I created a normalisation rule as follows:

     

    Pattern: ^(\d{10})$

    Route: +1$1

     

    Using the test area of EVRH I type in my number (including the dashes), 555-123-4567 and this is normalised to +15551234567. Marvellous, just what I need.

     

    I take this normalisation rule and put it in my newly created Company_Phone_Number_Normalization_Rules.txt. Running abserver -dumprules confirms it has been recognised.

     

    Now here is the problem. When I try 'abserver -testphonenorm 555-123-4567' it does not find a match, even though EVRH did for the same rule.

     

    I try 'abserver -testphonenorm 5551234567' , (without the dashes in other words), and abserver returns a match from my Company_Phone_Number_Normalization_Rules.txt so I know the formatting of that file is correct and abserver sees it.

     

    So, what gives? Why does the result returned from EVRH normalise the number and abserver does not? I thought abserver was supposed to ignore dashes, parenthesis etc.?

     

    And my real question I suppose, is what normalisation rule would work with numbers including the dashes?

     

    Thanks.

    Friday, September 5, 2008 4:04 PM

Answers

  • So what you have unknowingly discovered is that (for whatever reason) the normalization rules used in Enterprise Voice don't have to be as specific as what the ABS uses in the normalization conifugration file.  Where as a simple rule in the route helper will work for both 555-1234 and 5551234, you have to specifically configure the ABS rules to handle the different potential seperating characters.

     

    Here's an example of a more detailed ABS translation rule that takes into account many characters, spaces, etc:

     

    Code Snippet
    #
    # 312-555-9500...9599
    #
    \(?\s*(312)\s*\)?[\s()\-\./]*(555)[\s()\-\./]*(95\d\d)[\s]*
    $3

     

     

    This rule works for 312-555-9555, 3125559555, 1 (312) 555 -9555, or even something wacky like 312-() -/5-5---5-95     5     5. Haha.

     

    Take a look at this some of the sample rules I have in this blog article:

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

     

    Friday, September 5, 2008 7:26 PM
    Moderator

All replies

  • So what you have unknowingly discovered is that (for whatever reason) the normalization rules used in Enterprise Voice don't have to be as specific as what the ABS uses in the normalization conifugration file.  Where as a simple rule in the route helper will work for both 555-1234 and 5551234, you have to specifically configure the ABS rules to handle the different potential seperating characters.

     

    Here's an example of a more detailed ABS translation rule that takes into account many characters, spaces, etc:

     

    Code Snippet
    #
    # 312-555-9500...9599
    #
    \(?\s*(312)\s*\)?[\s()\-\./]*(555)[\s()\-\./]*(95\d\d)[\s]*
    $3

     

     

    This rule works for 312-555-9555, 3125559555, 1 (312) 555 -9555, or even something wacky like 312-() -/5-5---5-95     5     5. Haha.

     

    Take a look at this some of the sample rules I have in this blog article:

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

     

    Friday, September 5, 2008 7:26 PM
    Moderator
  • Thanks for that, and for the blog link. All good stuff.

     

    I replaced my normalisation rule with yours and after I did I was able to use -testPhoneNorm to succesfully normalise numbers in my format of nnn-nnn-nnnn. I was however most upset to find your wacky example did not normalise, boo! (Yes I really did try :-))

     

    But anyway, even though -testPhoneNorm gives a positive result, I have reran -syncNow and -regenUR and rebooted all the servers but still I get the fateful event log error, "82346 total numbers failed to normalize". I check in Invalid_AD_Phone_Numbers.txt and all the same numbers are there, including ones that I can normalise manually using -testPhoneNorm. So I'm still a little stuck and don't know why it isn't working so any insight you might have would be useful.

     

    Thanks again.

    Monday, September 8, 2008 12:29 PM
  • What format are your phone numbers attributes poulated with in AD?  Are they consistent or are there a couple 'different' way that administrators are entering them?

     

    LOL @ trying that silly number string I put in the original post.

    Monday, September 8, 2008 12:46 PM
    Moderator
  • It's a global company so there are about a million different number formats in the GAL. The ones I am most concerned with though are all in the nnn-nnn-nnnn format, of which there are many thousands listed in Invalid_AD_Phone_Numbers.txt.

     

    If I manually enter these particular numbers in to test using abserver they normalise fine using your new rule, but still no joy when resynching the whole address book.

     

    Numbers in the GAL that are already correctly entered in E.164 format in AD do not have a problem and get imported to the OCS address book just fine. I am wondering if it would be OK to just delete all the .dabs and .lsabs files and try again as the system is not live yet?

    Monday, September 8, 2008 1:50 PM
  • I've never tried deleting the raw Addres Book files, so no telling if that would create more problems.  Your Invalid_... file will be regenerated after each pass, so if that is still filling up with invlaid entries then something else is still not quite right.  I vaguely remember some numbers passing the -TestPhoneNorm switch but still appearing in the Invalid file.  I don't recall what my specific issue was the first time I ran into that. 

     

    Check the event log for the messages that appear during -regenUR and -syncnow processes and see if those have any details that verify your rules are actualliung being processed correctly by the ABS.

    Monday, September 8, 2008 6:05 PM
    Moderator
  • Well I finally got it working by renaming the Files folder, creating a new Files folder and copying over Company_Phone_Number_Normalization_Rules.txt to the new empty Files folder. One quick reboot later and everything normalised as expected. I just need to add rules for my remaining 30,000 invalid entries and I'll be laughing.

     

    So what I take from this is that there is some sort of problem with the address book regeneration process. Thanks for all the input.

    Thursday, September 11, 2008 1:25 PM