Caller ID is a service that's provided by telephone companies. It can tell a person who's receiving a call the telephone number, and sometimes the name, of the person who's calling and other information about the call. This information is sent over a serial cable by using call signaling. When a call is received by a PBX or IP PBX from a telephone company, the call includes calling identification information such as the following:

• The calling party's number
  
  
• The called party's number
  
  
• Status codes that indicate such things as the following:
  
  
  • Ring-no-answer (The phone rang, but the called party didn't answer.)
    
    
  • The state or condition of the telephone line
    
    
  • Line busy (The call connected, but the line is busy.)
    
    
  • Call forward always (The incoming call is always forwarded to another number.)
    
    
• The line or port number that's being used for the call
  
  

In Exchange 2007, E.164 number resolution was limited and, in some cases, couldn't return the name of the caller in a missed call notification or in the voice message that the called party received in their mailbox. What was needed was the ability to apply an E.164 number or set of numbers for an UM-enabled user and to use these numbers to help resolve an incoming number from another user or a caller from outside the organization.

The UM server would take the E.164 number from the caller ID, convert it into an E.164 number, and then just do a lookup for the name of the caller in Active Directory or in the UM-enabled user's personal Contacts. However, without Exchange Unified Messaging being integrated with Communications Server 2007 R2 or Microsoft Lync Server 2010, an E.164 couldn't be used.

In Exchange 2010, a multivalued attribute named msExchUMCallingLineIDs was added to the Active Directory schema. This attribute enables a UM server to take an E.164 number or set of numbers, convert the number or numbers, and then perform a name lookup. This attribute can contain a list of numbers that are mapped to a specific user and can be configured on the user's Active Directory object. For example, you could add the numbers, 4255551010, 14255551010, and +14255551010 to the msExchUMCallingLineIDs attribute for a specific user. Although the last number in this list is an E.164 number, a correctly formatted E.164 number isn't required. You can add any phone number that looks like a valid phone number that contains digits, and those digits can, optionally, begin with a plus (+) sign.

Note:
The msExchUMCallingLineIDs attribute isn't limited to UM-enabled users and can be configured for all users in Active Directory.

The following figure shows where multiple phone numbers are located for a user on the msExchUMCallingLineIDs attribute.

msRTCSIP-Line is a Communications Server 2007 R2 or Microsoft Lync Server 2010 schema attribute that exists on an Active Directory recipient object when Communications Server 2007 R2 or Lync Server 2010 is installed. The msExchUMCallingLineIDs attribute for Unified Messaging is used for caller ID to name resolution in very much the same way the msRTCSIP-Line attribute is used in Communications Server 2007 R2 or Lync Server 2010. A Unified Messaging server will use the msRTCSIP-Line attribute to resolve a caller ID to a name, but Exchange Unified Messaging doesn't grant administrators the ability to change or edit this attribute using any method, including Unified Messaging cmdlets.

Communications Server 2007 R2 or Lync Server 2010 specifies the format and validation of the msRTCSIP-Line attribute. There are two reasons Unified Messaging administrators aren't allowed to make changes to the attribute.

• Communications Server 2007 or R2 Lync Server 2010 depends on the correct administration of this attribute to correctly route calls to the intended Unified Communications device. If Unified Messaging were allowed to configure this attribute, both Unified Messaging and Communications Server 2007 R2 or Lync Server 2010 would have to share in the validation and administration.
  
  
• The msRTCSIP-Line isn't very flexible because it's single valued. As an Exchange Unified Messaging administrator, you'd most likely want to provision more than one phone number for a user by including an E.164 formatted number for them.
  
  

For these reasons, the Exchange 2010 recipient schema includes the msExchUMCallingLineIDs attribute as a multivalued and indexed property. When you want to add, remove, or change the phone numbers for a specific user, you'll add or remove numbers by using the UMCallingLineIds parameter for the Set-User cmdlet. After you add, remove, or change the numbers on the msExchUMCallingLineIDs attribute, no further action is needed.

The following table shows the cmdlets, type, description, and the default setting for the UMCallingLineIds parameter.

UMCallingLineIds parameter description

The Get-User and Set-User cmdlets will read and write to the msExchUMCallingLineIDs attribute. If a caller ID isn't correctly resolved using the msExchUMCallingLineIDs attribute, UM will then look at the phone number that's configured on msRTCSIP-Line attribute for a user.

Return to top

In addition to the UMCallingLineIds parameter that was added to help resolve a caller ID to the name of the caller, the UM server must also have the ability to take numbers from the UMCallingLineId, such as 51010, 555-1010, and 4255551010 and extend them into a correctly formatted E.164 phone number. The NumberingPlanFormats parameter on the Set-UMDialPlan cmdlet is used to do this.

The syntax for adding numbering plan formats to a UM dial plan is:

	Copy Code
Set-UMDialplan -identity MyUMDialPlan -NumberingPlanFormats "425567xxxx","425678xxxx"

There are two requirements if you want to resolve caller ID to calling party name this way:

• Each user must be correctly provisioned with E.164 numbers. However, configuring each recipient in Active Directory make take some time.
  
  
• Rules that a UM server can use to map incoming caller IDs and convert them into correctly formatted E.164 phone numbers must be configured. An example of such a rule is extension length IDs.
  
  

An Exchange 2010 Unified Messaging server can change non-canonical numbers, such as an extension number of 5 digits, into more canonical forms like the E.164 format by using number masking.

A number mask is used to define the telephone number format that a Unified Messaging server uses to determine what outgoing telephone number it will dial for a user or the phone number that's used in the diversion header of an incoming call. Number masking is done for both incoming calls and outgoing dialing rules. An example of a valid number mask is 91xxxxxxxxx. For example, when an outgoing call is made to a number like 4255551010, the 91xxxxxxxxxx number mask on the dialing rule entry the Unified Messaging server replaces the right-most digits that are matched to the dialed number. In this example, there are 10 digits in the phone number that is dialed and 10 digits (represented by 'x'). Since these digits match, the UM server will dial 914255551010. This field can contain only numbers and the character x. The same process is used for incoming calls.

The NumberingPlanFormats parameter is a multivalued property and is used when a caller ID number is received by a UM server that's associated with a UM dial plan that can then be expanded into a correctly formatted E.164 number.

The following table shows the cmdlets, type, description, and default setting for the NumberingPlanFormats parameter.

NumberPlanFormats parameter description

In Exchange 2007 Unified Messaging, the International number format on a dial plan was used to enhance caller ID resolution by creating an E.164 phone number. The E.164 phone number would then be used when the UM server searched for the phone number for the caller using the msRTCSIPLine attribute.

In Exchange 2010 Unified Messaging, equivalent dial plan groups have been added to enhance caller ID resolution to widen the scope of the search. This is done by configuring the numbering plan format on each dial plan, which will help to convert the caller ID into the E.164 format. For details about equivalent dial plans, see Equivalent Dial Plan Groups later in this topic.

For example, consider a company that has 20,000 employees. This company would need 20,000 unique Direct Inward Dial (DID) telephone numbers for its employees. However, the company couldn’t get numbers within consecutive DID ranges, for example, 425-555-xxxx to 425-556-xxxx. Instead, the first group of 10,000 employees had the number prefix 425-567-xxxx, and the second group of 10,000 employees had the number prefix 425-678-xxxx.

Say the administrator creates a single UM dial plan for these 20,000 employees and uses a 5-digit extension for each user. When a call is received by the PBX, the PBX will send the 5-digit caller ID. However, when the company migrates from a legacy PBX to an IP PBX, the users will be on two separate PBXs, each with its own 5-digit UM dial plan. After the users are migrated to the IP PBX, the caller ID name resolution will start to fail, and only the 5-digit extension will appear in the voice message, instead of the caller's name.

This happens because only a single International number format is configured on the UM dial plan that's shared by these two prefixes. Therefore, only half the UM-enabled users will have correctly formatted E.164 numbers created. Also, the users are on different PBX dial plans. So even if an equivalent dial plan is enabled on the UM dial plan, the caller isn't UM enabled, and the caller's extension number won't resolve to a name.

The NumberingPlanFormats parameter can be used to resolve this issue. For each UM dial plan, there's an msExchangeUMCallingLineIDFormats attribute that can be configured using the NumberPlanFormats parameter to specify one or more phone number masks that can resolve caller IDs to names in Active Directory. The following figure shows this attribute and the numbering plan formats.

When a UM server answers an incoming call, it reads the caller ID. The UM server will parse the list of configured number plan formats from the top down until a match is not found or there's a conflict in the digits where x in the number mask is treated as a wild-card. When this happens, the UM server will try to back fill the caller ID for the incoming call into each number mask. In the case of the employees whose number prefixes are 425-567-xxxx, and 425-678-xxxx, the digits “7” and “8” are the keys by which a correct mask will be selected for the calling ID number. After the UM server successfully back fills a numbering plan format pattern, it takes the E.164 number that's generated and performs a lookup against the msExchUMCallingLineIDs attribute. If that lookup fails, the UM server performs a lookup against the msRTCSip-Line attribute.

Unified Messaging administrators must check for ambiguous and nonsensical numbering plan format rules and reconfigure them. Ambiguous numbering plan format rules are two or more rules in which the right-most characters are identical and equal the number of digits configured on the dial plan. A nonsensical numbering plan format rule is one that has a wildcard character in any position other than one of the right-most digits that equals the number of digits in the extension numbers that are configured on the dial plan.

Return to top

In addition to UM calling line IDs and numbering plan formats, Exchange 2010 Unified Messaging enables Active Directory heuristics.

In Exchange 2007, caller ID resolution doesn't include telephone fields on the user's object in Active Directory when trying to resolve the caller ID on an incoming call to a name. This is because:

• The fields located on the Telephones tab and Telephone number field aren't indexed and searchable.
  
  
• The fields located on the Telephones tab and in the Telephone number field may not be in a standardized format.
  
  

The following figure shows these fields in Exchange 2010.

There's a major problem with the Telephone number field on the Telephones tab on a user's object in Active Directory. The field contains no validation or limits for formatting the numbers that are inserted. This means that there's no standardized format for these numbers. Here are the potential issues that prevent resolution of a caller ID to a name:

• The administrator didn't enter a number in the Telephone number field.
  
  
• The administrator doesn't use the Telephones tab at all for phone numbers.
  
  
• E.164 numbers are entered without any parentheses, hyphens, or the correct spaces.
  
  
• The numbers aren't in the correct E.164 format. Examples of the correct format include the following:
  
  
  • (425) 555-1010
    
    
  • (425) 555-1234 x51010
    
    
  • (425) 555-1234 ext. 51010
    
    
  • 425-555-1010
    
    
  • 425.555.1010
    
    
  • 425/555-1010
    
    
  • 1425-555-1010
    
    
• Both extensions and international numbers are used. Examples that show both extensions and international numbers used together include the following:
  
  
  • +7890
    
    
  • +441234567890
    
    
  • +44(1)234567890
    
    
  • +44 (0)1 2345 6789
    
    

An Exchange 2010 Unified Messaging server will query Active Directory to examine up to 8 Active Directory attributes, together with the EUM proxy addresses and the msExchUMCallingLineIDs and msRTCSIP-Line attributes, when it tries to resolve a caller ID. There is an msExchAllowHeuristicADCallingLineIDResolution attribute on each dial plan. By default, the msExchAllowHeuristicADCallingLineIDResolution attribute is set to true when you create a UM dial plan.

You can use the Set-UMDialPlan cmdlet to enable or disable Active Directory heuristics. The following table shows the UM dial plan cmdlets, type, description, and default setting for the AllowHeuristicADCallingLineIdResolution parameter.

AllowHeuristicADCallingLineIdResolution parameter description

After you enable Active Directory heuristics, UM will use the phone number fields, such as telephone number, home, or mobile, that are configured for a user who's in Active Directory. However, there’s no way to select which of the phone fields to include. The following telephone attributes for a user in Active Directory will be used to resolve a caller ID to a name:

• telephoneNumber
  
  
• homePhone
  
  
• mobile
  
  
• facsimileTelephoneNumber
  
  
• otherTelephone
  
  
• otherHomePhone
  
  
• otherMobile
  
  
• otherFacsimileTelephoneNumber
  
  

If you use the Set-User cmdlet to populate one or more of the telephone attributes for a user, you must run GalGrammarGenerator.exe –u to update the DTMF map for each user. If you populate the phone fields or update phone numbers before you install the Unified Messaging server role or use a program other than the Exchange Management Shell, you’ll also have to run Galgrammargenerator.exe –u before the telephone number fields will be indexed. For more information about how to run GalGrammarGenerator.exe, see one of the following topics:

• Update the Speech Grammar Files on a UM Server
  
  
• Understanding Automatic Speech Recognition Directory Lookups
  
  

Return to top

Sometimes the number of UM dial plans can become unwieldy, either because the number of forests has increased or because the number of UM dial plans in a single forest has been increased. To provide a more scalable solution, a new Active Directory object has been added in Exchange 2010 Unified Messaging: equivalent dial plan group. An equivalent dial plan group is a container object in Active Directory that will contain equivalent dial plans that are from separate Active Directory forests.

Two Active Directory attributes are used with equivalent dial plan groups:

• msExchangeUMEquivalenceDialPlan
  
  
• msExchangeUMEquivalentDialPlanPhoneContexts
  
  

The concept of an equivalent dial plan has been added in Exchange 2010 Unified Messaging to allow UM administrators to connect two dial plans that are in the same PBX numbering plan but are broken into two dial plans. Two dial plans might be contained in a single PBX numbering plan, for example, when users in the two separate dial plans sit next to each other and can dial each other using an extension number but exist in different dial plans for reasons unrelated to the telephony infrastructure.

Note:
Extension numbers must be unique within a dial plan, but they must also be unique within an equivalent dial plan group.

For every dial plan, there can be an equivalent dial plan phone context for two or more dial plans that should be one dial plan but have been separate. You can add names for other dial plans and link to other dial plans. The dial plans you enter names for or link to can be in the same Active Directory forest or in different forests. When you add an equivalent dial plan, the dial plan’s phone context will be automatically added to the equivalent dial plan group.

After you have added multiple dial plans with different phone contexts, when a call comes in the Unified Messaging server, instead of only looking for EUM proxy addresses that have the same phone context, it will look at EUM proxy addresses that have the phone context listed on an equivalent dial plan. As long as the dial plan is listed as an equivalent dial plan, and only the caller ID is being sent, then all Unified Messaging users' numbers from both dial plans will be resolved correctly to a name.

The following table shows the cmdlets, type, description, and default setting for the EquivalentDialPlanPhoneContexts parameter.

EquivalentDialPlanPhoneContexts parameter description

For example, by having equivalent dial plan phone contexts on a dial plan, you could run the following command to add two UM dial plans to a single equivalent dial plan group.

	Copy Code
Set-UMDialPlan -identity MyUMDialPlan1 -EquivalentDialPlanPhoneContexts "dialplan2.contoso.com, dialplan3.contoso.com".

If the extension of a caller matches any UM-enabled user on any of the three dial plans specified in the command, the extension number will be resolved to a name of the caller.

Return to top