Phone number normalization is the process of translating number strings that are entered in various formats into a single standard format. Enterprise Voice requires normalized phone numbers to:

• Provide a consistent reference for reverse number lookup. Reverse number lookup is the process of mapping a user’s number to a corresponding SIP URI for the purpose of routing calls over the IP network to multiple user endpoints, including Office Communicator, Office Communicator Phone Edition, and call-handling options such as call forwarding and call answering.
  
  
• Identify and apply phone usage authorization (comparable to traditional "class of service" options) for the calling party.
  
  
• Route calls to the appropriate media gateway.
  
  

Office Communicator continues to rely on the Address Book Server for the phone number normalization that it requires for reverse number lookup.

Office Communications Server normalizes phone numbers prior to performing reverse number lookup. If the normalized number matches the designated primary work number of a user with an Active Directory identity, the call is distributed to the endpoints that are associated with that user's SIP URI. If the server does not find a match, which means that the target number is probably outside the enterprise, the Outbound Routing component checks the caller's phone usage record to determine whether a call to that number is authorized and then either directs the call to the appropriate media gateway or notifies the caller that the call is not allowed.

Phone number normalization is usually done to the E.164 format, but Office Communications Server can translate to other formats if you are using a private numbering system or using a gateway or PBX that does not support E.164.

Organizations that conduct business in more than one geographic location require some way to translate identical phone number strings into numbers that are valid for each location. A traditional PBX system solves this problem by maintaining separate numbering plans for each site. When a PBX receives a call to a particular user extension, there is no ambiguity about the appropriate destination, because the PBX is configured only for the site where it is deployed. The Enterprise Voice infrastructure, however, is quite different. Unlike the site-specific PBX, Enterprise Voice is distributed across the enterprise network, and dialing, say, extension 50100 reaches one number in Redmond and other, different numbers in Dallas, London, or Singapore.

The solution is location profiles. A location profile is a named set of normalization rules that translate phone numbers for a named location or user to a single standard format (usually E.164, but other formats are supported) for purposes of phone authorization and call routing. The normalization rules define how phone numbers expressed in various formats are routed for the named location. The same number string can be interpreted and translated differently, depending on the locale from which it is dialed.

Because the Enterprise Voice solution aims to provide a seamless experience to end users as they transition from an existing telephony system, it is critical that dialing habits be preserved through the transition. For example, if Bob at site A used to dial 12345 to reach Joe, it should be possible for him to continue to be able to reach Joe by dialing 12345 after he has moved to Enterprise Voice.

A large organization might need a separate location profile for each location where it maintains an office. If your organization has a legacy PBX deployed, as most do, you can use its dial plan to create location profiles.

When a user makes a call to a destination that is not referenced as the desired phone format or SIP URI (user URI), the clients include a phone-context attribute that specifies the name of the location profile that needs to be used to translate the number.

For example: INVITE SIP:5550100;phone-context=redmond@contoso.com

However, if the client includes a phone-context value of user-default instead of a location profile (for example: INVITE SIP:5550100;phone-context=user-default), Enterprise Voice applications look up and use the per-user location profile assigned to that user.

The following mechanisms configure Enterprise Voice clients with the appropriate location profiles.

Office Communicator

• The Configure Users Wizard assigns location profiles to individual users, and in-band provisioning then sends the per-user location profiles to the users.
  
  
• Each Office Communications Server pool is configured with a location profile. If a per-user location profile is not assigned to a user, in-band provisioning sends the pool-level default location profile.
  
  
• Because a pool can serve multiple locations, the pool-level location profile might not be sufficient. Therefore, Office Communicator also supports configuring the location profile for the user by means of Group Policy objects (GPO).
  
  

Microsoft Office Communicator Phone Edition

• The per-user location profile or a list of supported location profiles and the pool-level default is sent to the device by means of in-band provisioning.
  
  
• Users can set a default location profile by using the user interface of the device. Each location profile has an ordered list of normalization rules, which are used to translate a dialed number. A normalization rule contains the following:
  
  
  • Number pattern– regular expression
    
    
  • Translation– translation pattern
    
    
  For example:
  
  NormRule1     ^5(\d{4})$     +1425555$1
  
  This rule translates the dialed number 50100 to the E.164 format +14255550100. The regular expression (^5(\d{4})$) matches any number that starts with the numeral 5 followed by any four digits.
  
  

Note:
The order of the normalization rules in a location profile is significant because the first rule that matches is used to translate the number. If no match is found, an error response is sent to the caller.

Figure 1 illustrates three location profiles for locations in Redmond, Dallas, and New York and contains some example normalization rules that are contained as part of the location profiles.

Figure 1. Location profiles for Redmond, Dallas, and New York

Phone usage records provide a quick, simple way to assign call permissions to users as well as to facilitate route prioritization and selection. For example, a temporary contract employee might not be authorized to make long-distance calls, or only certain employees or workgroups might be allowed to place international calls. A phone usage record is an arbitrary label that you create to identify a category of call destinations. Examples include Local, Area Code, State, Province, USA, Singapore, and International. In this regard, phone usage records are similar to what in traditional telephony is known as "class of service." Phone usage records, however, offer greater flexibility because they are applied to both user policies and routes, making it possible to formulate very precise phone authorizations for both individuals and groups.

By assigning phone usage records to both user policies and outbound call routes, you indicate which users are allowed to make calls that use particular routes. When a user places a call, Office Communications Server matches the caller with a list of routes, as deifined in the next section of this document. If the phone usage record for the route also appears in the voice policy assigned to the caller, the call is allowed to go through. If none of the routes assigned to the phone usage record can be used for the called number, the server refuses the call.

The following steps are involved in using phone usage records:

1. Administrators create policies that contain a set of phone-usage attributes.
   
   

   Note:
   The sequence of phone usage attributes in the policy is significant; we recommend that you arrange attributes from most-preferred to least-preferred.

2. Users are assigned a policy based on their calling privileges.
   
   
3. Routes are assigned phone usage records, which serve to match routes with the users who are authorized to use them. That is, users can place calls that use only the routes for which they have matching phone usage records.
   
   

When Office Communications Server determines that a dialed number needs to be routed to a PSTN gateway, the routing table is queried to determine the optimal gateway for the call.

The policy of the calling user (or a user transferring the call), along with the dialed number, determines the gateway to which the call should be routed. The following example illustrates the logic used by the routing application.

	Copy Code
routeList = null; foreach ( usage in caller.usages ) – order of usages matters foreach ( route in routesWithUsage[ usage ] ) if ( route.RegexPattern.Matches ( targetPhoneNumber ) ) routeList.Append ( route );

The following are examples of failover logic related to gateway selection:

• When there are multiple gateways that serve a particular route, a round-robin algorithm is used to distribute the calls across the multiple gateways.
  
  
• Each gateway is configured with a maximum number of failed call attempts before traffic to the gateway is throttled. The default number of attempts is 10, but this value can be changed by using a Windows Management Instrumentation (WMI) script. For a particular call, a given gateway cannot be attempted more than once. If all gateways that serve a particular route are marked as unavailable, the server drops the call and notifies the client. You can also configure a gateway to be removed from the selection logic for some period of time. The unresponsive gateway is removed from the list of available gateways for increasing periods of time, up to a maximum of 60 minutes, during which time the server repeatedly attempts to elicit a positive response. After receiving a positive response, the server returns the gateway to the list of available gateways.
  
  

Figure 2. Example of routing logic

Note:
Only calls from users who are enabled for Enterprise Voice are routed by using the previously defined procedure. If no match is found in the routing table, the call is refused.

For details, including examples and best practice recommendations, see Planning for Voicein the Planning and Architecture documentation.