locked
How does background normalization work for dialing out?

    Question

  • I have some confusion regarding how many times a number gets normalized before being sent to the Mediation server for an outound call.

     

    I know that the Fontend OCS pool has a default location profile which contains normalization rules and these rules come into play when someone manually types a phone number in the MOC and you can actually see the normalized phone number as you are typing the number. As far as I know, the normalized number is the one that gets sent to the mediation/media server for outbound call. Then there are normalization rules in the Company_Phone_Number_Normalization_Rules.txt file which get applied to the phone numbers stored in AD. The phone numbers get displayed in the format they are actually stored in AD but when someone actually uses them to make a call, the normalized version based on the rules in the above file get used. So, my question is - do these normalized numbers in the address book get normalized again based on location profiles before they sent to the mediation server of the location profile is bypassed in this case?

     

    Thanks,

    AK

    Friday, November 21, 2008 7:16 PM

Answers

  • My problem is now resolved and I think I can explain what happened.

     

    There are two separate phone numners 5xxxx and +1 (222) 333 xxxx stored in AD as work number and business 2 number and the normalization rules normalize both of them to +5xxxx. When the address book generation takes place, it stores the first number (work 5xxxx) and its normalized value (+5xxxx) and when is processes the second number, it finds that its normalized form has already been stored for that user and skips it. As a result, only the 5 digit work number shows up for users in the address book and not their full business 2 number. This works fine or me because the full number is not necessary for the MOC clients as long as their 5-digit number is there and it can be dialed. The reason for my problem earlier was that the full number was not getting normalized for some reason but becasue it included a '+' sign in the AD field, it was getting included in the address book separately but was not dialable. After I deleted all address book files and did a regenur followed by a sync, the full numbers went away from the address book and that solved the problem of misconfigured numbers. In my assessment, I think that the address book generation process is buggy and does not do a very good job when generating the delta files. I have had much more luck deleting the address book files and regenerating them from scratch especially for problems that require normalization rule changes.

     

    AK

    Friday, December 05, 2008 3:03 PM

All replies

  • If you in any case dial a number with "+" in front of the number there is no normalization

    So if you number from AD has a "+" sign then no normalization will be performed

     

    You can easily try this by dialing for example a number that translates via normalization and then put a "+" in front you will see that it will not normalize

     

    Friday, November 21, 2008 8:55 PM
  • I will try an explain my problem with an example:

     

    A contact in AD has the work number set to 51234 and has the second work number set to +1 (222) 333 1234.

     

    The Mediation server is connected to a PBX that recognizes numbers in 5xxxx format and dials them. I have a location profile that has normaloization rules that change 5xxxx to +5xxxx, and also change +1 (222) 333 xxxx to +5xxxx. I have identical rules in the company specific file where numbers are translated the same way.

     

    When I go to my MOC client and manually type the number 51234 or +1 (222) 333 1234, it changes them to +51234 in the display underneath the address window and dials them successfully. Now if I open this contact from the address book by typing their name and clicking "Call" from their contect menu, I see numbers 51234 and +1 (222) 333 1234 displayed. If I select the 5 digit number (51234) it dials successfully but if I choose the other number [+1 (222) 333 1234], it fails to dial. Something is not getting translated correctly when I am dialing the full number from the address book.

     

    Thanks,

    AK

    Friday, November 21, 2008 9:34 PM
  • Why do you need 2 numbers?

    One for OCS and one for PBX?

    The LineURI must be populated with telephone number and that is the one OCS recognizes (seems to be +51234 which is not exactly a correct number, it should have full number with country code)

     

    So the other number is routed through OCS because no one actually has that number

    Maybe there are no routes for this number through the mediation server

    Maybe this number is also not recognized by PBX

     

    Friday, November 21, 2008 9:43 PM
  • It is simply becasue people are used to 5 digit extensions for along time so we left those in the main business number but added their full version as a separate number for readability in case they need to provide it to someone outside the company. Nothing is going directly to OCS inbound because we have not rolled out Enterprise Voice yet. Everything is going through the PBX for now. The route is set to accept all numbers. So, whether I dial the 5 digit number or the full number, it should all get sent to the PBX. Because both numbers are visible, users are likely to click either one and what I am trying to do with nromalization rules is to make both numbers get translated to the an identical 5 digit number with the + appended in front of it. The PBX knows how to dial 5 digit numbers and I can validate this because I can dial either format manually...just not from the address book.

     

    Hope this explains the reason for the way it is setup.

     

    AK

     

    Friday, November 21, 2008 9:54 PM
  • The only option is to configure Enterprise Voice correctly with full E.164 numbers

    And use Normalization to full E.164 numbers

    Tuesday, November 25, 2008 11:40 PM
  • My problem is now resolved and I think I can explain what happened.

     

    There are two separate phone numners 5xxxx and +1 (222) 333 xxxx stored in AD as work number and business 2 number and the normalization rules normalize both of them to +5xxxx. When the address book generation takes place, it stores the first number (work 5xxxx) and its normalized value (+5xxxx) and when is processes the second number, it finds that its normalized form has already been stored for that user and skips it. As a result, only the 5 digit work number shows up for users in the address book and not their full business 2 number. This works fine or me because the full number is not necessary for the MOC clients as long as their 5-digit number is there and it can be dialed. The reason for my problem earlier was that the full number was not getting normalized for some reason but becasue it included a '+' sign in the AD field, it was getting included in the address book separately but was not dialable. After I deleted all address book files and did a regenur followed by a sync, the full numbers went away from the address book and that solved the problem of misconfigured numbers. In my assessment, I think that the address book generation process is buggy and does not do a very good job when generating the delta files. I have had much more luck deleting the address book files and regenerating them from scratch especially for problems that require normalization rule changes.

     

    AK

    Friday, December 05, 2008 3:03 PM