Understanding Name Lookups from a Caller ID
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Unified Messaging (UM) uses information about the calling and called parties to perform a name lookup. This lookup enables a caller's name to be included in the following situations:
In a missed call notification
When a caller leaves a voice message for a UM-enabled user if the calling party's name is located in Active Directory or in the called party's personal contacts
Contents
Caller ID
Name Lookup Process
Improved E.164 Number Resolution
Equivalent Dial Plan Groups
Caller ID
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
Name Lookup Process
Unified Messaging uses two data sources to receive information about the calling party and to map it to the name of the caller: Active Directory and personal Contacts. When the name lookup process is successful, the name of the calling party will be inserted into voice mail messages and missed call notifications if they've been enabled for the called party. When an incoming call is received, the calling party information is passed to a Unified Messaging server. The caller can be calling from inside or outside your organization.
In Microsoft Exchange Server 2007 Unified Messaging, a call that was diverted to a Unified Messaging server because of a ring-no-answer or busy condition is answered and a voice message is taken. After the call is answered, Exchange 2007 Unified Messaging tries to resolve the caller ID. It does this so that it can insert a name, rather than a number, into the sender information.
In Exchange 2007, name lookups for voice mail messages are done by using information about a caller who's in the same dial plan as the user being called in one of the following ways:
Using an EUM proxy address.
From the personal Contacts of the user receiving the call.
Using the msRTCSIP-Line attribute in Active Directory if Service Pack 1 (SP1) for Exchange 2007 was installed and Exchange 2007 was integrated with Microsoft Office Communications Server 2007 or Office Communications Server 2007 R2.
In Microsoft Exchange Server 2010, the name lookup methods differ from those used in Exchange 2007. The following steps are used in Exchange 2010 to look up a name from the calling party's information:
The caller's name is used if the caller signed in to their mailbox from Outlook Voice Access or if they use a Microsoft Unified Communications client such as Microsoft Office Communicator 2007 or Communicator Phone Edition to place the call. The caller's identity is known because they've been authenticated when they use Outlook Voice Access, Office Communicator 2007, or Communicator Phone Edition.
The EUM proxy address or addresses in Active Directory are used. If the proxy address contains an '@' sign, it's considered a SIP URI. If the proxy address begins with a '+' character, it's considered to be an E.164 number. If neither of these characters is present, the proxy address is considered an extension within the same dial plan as the called party or an equivalent dial plan.
If the caller ID is a valid SIP URI, Active Directory is used to resolve the SIP URI using the EUM proxy address or addresses.
If the caller ID is a valid E.164 number, Active Directory is used to resolve the number to the calling party's name. For this to work correctly, you must have manually configured the UMCallingLineIds parameter on the UM-enabled mailbox for the called party. This configuration is useful when you don't want to publish a telephone number, such as a personal mobile phone number, in Active Directory, but still want to resolve the calling party's name by using this phone number.
Active Directory heuristic matching is used, if it's enabled, to resolve the number to the calling party's name. Active Directory heuristic matching must be enabled on the dial plan, and the user's account in Active Directory must be populated with one or more of the fields, such as telephone number, home, or mobile, for this to work correctly.
The personal Contacts of the called party are used to resolve the number to the calling party's name.
The following figure shows the steps that are performed by a Unified Messaging server when it tries to perform a name lookup from the calling party information that's provided.
Name lookups from calling party information
Return to top
Improved E.164 Number Resolution
In Exchange 2010 Unified Messaging, four new methods are used to improve resolution of the caller ID to the calling party's name. The four methods are:
Calling line IDs
Numbering plan formats
Active Directory heuristics
Dial plan equivalency groups
Calling Line IDs
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.
Calling line IDs and 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
Cmdlets | Type | Description | Default |
---|---|---|---|
Set-User Get-User |
Microsoft.Exchange.Data.MultiValuedProperty |
The UMCallingLineIds parameter specifies telephone numbers or extensions that can be mapped to a UM-enabled user. You can specify more than one telephone number for each user, separated by a comma. This parameter accepts digits less than 128 characters and may include an optional plus sign (+) preceding the numbers. Each UM-enabled user must have a unique UMCallingLineIds parameter value. |
empty |
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
Number Plan Formats for Dial Plans
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:
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
Cmdlets | Type | Description | Default |
---|---|---|---|
Set- DialPlan Get-DialPlan |
Microsoft.Exchange.Data.MultiValuedProperty |
The NumberingPlanFormats parameter specifies one or more phone number masks that can be used for resolving caller ID to names of users in Active Directory. |
empty |
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.
Numbering plan formats and msExchangeCallingLineIDFormats attribute
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
Active Directory Heuristics
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.
Telephone Tab Fields
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
Cmdlets | Type | Description | Default |
---|---|---|---|
Set-UMDialPlan Get-UMDialPlan |
System.Boolean |
The AllowHeuristicADCallingLineIdResolution parameter specifies whether to allow calling line ID resolution using telephone number fields that may be configured in Active Directory. When this parameter is set to $true, the telephone numbers, such as those defined on the Telephones tab and the telephone number for a user in Active Directory, are used. Setting this parameter to $true allows resolution of calling IDs for both UM-enabled and non-UM-enabled users. You may want to set this parameter to $false if the telephone numbers for users aren't in a standard format. If the telephone numbers aren't in a standard format, the Unified Messaging server may be unable to correctly resolve the caller ID to the name of a user consistently. |
Enabled |
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:
Return to top
Equivalent Dial Plan Groups
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
Cmdlets | Type | Description | Default |
---|---|---|---|
Set- DialPlan Get-DialPlan |
Microsoft.Exchange.Data.MultiValuedProperty |
The EquivalentDialPlanPhoneContexts parameter specifies the name of an equivalency dial plan. This parameter can be used when two UM dial plans exist but are in different forests or when a Private Branch eXchange (PBX) numbering plan spans two UM dial plans. Adding the name of the equivalency dial plan enables name lookups using a caller ID to search in the user's dial plan but then also search for a name for the calling line ID in any equivalent dial plans that are configured. |
empty |
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.
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
© 2010 Microsoft Corporation. All rights reserved.