从呼叫者 ID 中了解名称查找

适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题： 2015-03-09

统一消息 (UM) 使用关于呼叫方或被叫方的信息来进行名称查找。 此查找使呼叫者的名称可以包含在以下情形中：

• 在未接来电通知中

• 当呼叫方名称位于 Active Directory 或被叫方的个人联系人中时，呼叫者为启用了 UM 的用户留下语音邮件的时间

目录

呼叫者 ID

名字查找过程

改进的 E.164 号码解析

等效拨号计划组

呼叫者 ID

呼叫者 ID 是由电话公司提供的一种服务， 可用于告诉接收到呼叫的用户所接收到的电话号码、呼叫方的名字，以及关于此呼叫的其他信息。 此信息是使用呼叫信号在串行电缆上传送的。 当电话公司的 PBX 或 IP PBX 收到呼叫时，此呼叫将包含如下呼叫识别信息：

• 呼叫方号码

• 被叫方号码

• 表明如下内容的状态代码：

  • 响铃无应答（电话响了，但被叫方未应答。）

  • 电话线的状态或情况

  • 线路繁忙（呼叫已连接，但线路繁忙。）

  • 始终呼叫转移（传入呼叫始终转移到其他号码。）

• 呼叫使用的线路或端口号

名字查找过程

统一消息使用两个数据源来接收有关呼叫方的信息，并将其映射到呼叫者的名字中。 Active Directory 和个人联系人。 如果名字查找过程成功，则呼叫方的名字将插入到语音邮件和未接来电通知中（如果已为被叫方启用这些功能）。 如果接收到传入呼叫，则呼叫方信息将传送到统一消息服务器。 呼叫方可从组织内部或外部进行呼叫。

在 Microsoft Exchange Server 2007 统一消息中，由于响铃无应答或线路繁忙而被转移到统一消息服务器的呼叫将得到答复，并将创建语音邮件。 在呼叫被应答后，Exchange 2007 统一消息会尝试解析呼叫者 ID。这样，它就可以将名称而不是号码插入到发件人信息中。

在 Exchange 2007 中，对语音邮件进行的名称查找是使用与被叫者在同一拨号计划中的呼叫者的相关信息通过下列方式之一来进行的：

• 使用 EUM 代理地址。

• 从接收呼叫的用户的个人联系人。

• 如果安装了 Exchange 2007 Service Pack 1 (SP1) 并且 Exchange 2007 已与 MicrosoftOffice Communications Server 2007 或 Office Communications Server 2007 R2 集成，则使用 Active Directory 中的 msRTCSIP-Line 属性。

在 Microsoft Exchange Server 2010 中，名称查找方法与 Exchange 2007 中使用的方法不同。 Exchange 2010 中使用以下步骤从呼叫方信息中查找名称：

1. 如果呼叫者已从 Outlook Voice Access 登录其邮箱，或者呼叫者使用 Microsoft 统一通信客户端（如 Microsoft Office Communicator 2007 或 Communicator Phone Edition）进行呼叫，则使用呼叫者的名称。 呼叫者的身份是已知的，因为他们在使用 Outlook Voice Access、Office Communicator 2007 或 Communicator Phone Edition 时已经过身份验证。

2. 使用 Active Directory 中的一个或多个 EUM 代理地址。 如果代理地址包含“@”符号，它将被视为 SIP URI。 如果代理地址以“+”字符开头，则将它视为 E.164 号码。 如果代理地址中未出现上述任何字符，则将该代理地址视为被叫方所在的同一拨号计划中或等效拨号计划中的分机号码。

3. 如果呼叫者 ID 是有效的 SIP URI，则使用 Active Directory 并通过 EUM 代理地址解析该 SIP URI。

4. 如果呼叫者 ID 是有效的 E.164 号码，则使用 Active Directory 将该号码解析为呼叫方名称。 为正确解析号码，必须在被叫方的已启用 UM 的邮箱上手动配置 UMCallingLineIds 参数。 当您不希望公布 Active Directory 中的电话号码（如个人移动电话号码），但仍希望使用此电话号码来解析呼叫方的名称时，此配置非常有用。

5. 使用 Active Directory 启发式匹配（如果已启用）将号码解析为呼叫方名称。拨号计划中必须启用 Active Directory 启发式匹配，并且 Active Directory 中的用户帐户必须使用以下一个或多个字段（例如家庭电话号码或移动电话号码）填充，才能使其正常工作。

6. 使用被叫方的个人联系人将号码解析为呼叫方名称。

下图显示了当统一消息服务器尝试从所提供的呼叫方进行名字查找时所执行的步骤。

从呼叫方信息进行名字查找

返回顶部

改进的 E.164 号码解析

在 Exchange 2010 统一消息中，使用四种新方法来改进呼叫者 ID 到呼叫方名称的解析。 这四种方法是：

• 主叫号码

• 编号计划格式

• Active Directory heuristics

• 拨号计划等效组

主叫号码

在 Exchange 2007 中，E.164 号码解析受到限制，且在有些情况下，无法返回未接来电通知中或被叫方在其邮箱中收到的语音邮件中呼叫者的名称。 需要一种能力来为启用了 UM 的用户应用 E.164 号码或一组号码，并使用这些号码来帮助解析来自其他用户或组织外部呼叫者的传入号码。

UM 服务器将从呼叫者 ID 获取 E.164 号码，将其转换为 E.164 号码，然后只需查找 Active Directory 或启用了 UM 的用户的个人联系人中的呼叫者的名称。 但是，如果 Exchange 统一消息未与 Communications Server 2007 R2 或 Microsoft Lync Server 2010 集成，则无法使用 E.164。

在 Exchange 2010 中，向 Active Directory 架构添加了名为 msExchUMCallingLineIDs 的多值属性。 此属性使 UM 服务器能够获取 E.164 号码或一组号码，转换该号码或这组号码，然后执行名称查找。 此属性可以包含映射到特定用户的一组号码，并且可以在用户的 Active Directory 对象上进行配置。 例如，您可以将号码 4255551010、14255551010 和 +14255551010 添加到特定用户的 msExchUMCallingLineIDs 属性。 尽管此列表中的最后一个号码是 E.164 号码，但不需要格式正确的 E.164 号码。 您可以添加与包含数字的有效电话号码类似的任何电话号码，这些数字可以使用加号 (+) 开头。

注意：
msExchUMCallingLineIDs 属性不限于启用了 UM 的用户，可以为 Active Directory 中的所有用户进行配置。

下图显示对于某个用户的 msExchUMCallingLineIDs 属性，多个电话号码所在的位置。

主叫号码和 msExchUMCallingLineIDs 属性

msRTCSIP-Line 是安装 Communications Server 2007 R2 或 Lync Server 2010 后存在于 Active Directory 收件人对象中的 Communications Server 2007 R2 或 Microsoft Lync Server 2010 架构属性。 统一消息的 msExchUMCallingLineIDs 属性用于呼叫者 ID 到名称的解析，其方式与 Communications Server 2007 R2 或 Lync Server 2010 中使用 msRTCSIP-Line 属性的方式完全相同。统一消息服务器将使用 msRTCSIP-Line 属性将呼叫者 ID 解析为名称，但 Exchange 统一消息不授予管理员使用任何方法（包括统一消息 cmdlet）更改或编辑此属性的能力。

Communications Server 2007 R2 或 Lync Server 2010 指定 msRTCSIP-Line 属性的格式和验证。 不允许统一消息管理员对此属性进行更改的原因有两个。

• 只有正确地管理此属性，Communications Server 2007 R2 或 Lync Server 2010 才能将呼叫正确地路由到目标统一通信设备。 如果允许统一消息配置此属性，则统一消息和 Communications Server 2007 R2 或 Lync Server 2010 都将必须分担验证和管理工作。

• msRTCSIP-Line 不是很灵活，因为它是单值属性。 作为 Exchange 统一消息管理员，您最可能希望通过为用户包含 E.164 格式号码来为其设置多个电话号码。

出于这些原因，Exchange 2010 收件人架构将 msExchUMCallingLineIDs 属性作为多值和索引属性包括在内。 当要添加、删除或更改特定用户的电话号码时，将使用 Set-User cmdlet 的 UMCallingLineIds 参数添加或删除号码。 添加、删除或更改 msExchUMCallingLineIDs 属性中的号码后，无须执行任何其他操作。

下表显示了 UMCallingLineIds 参数的 cmdlet、类型、说明和默认设置。

UMCallingLineIds 参数说明

Get-User 和 Set-User cmdlet 将对 msExchUMCallingLineIDs 属性进行读写操作。 如果呼叫者 ID 未通过 msExchUMCallingLineIDs 属性正确解析，UM 随后将查看在用户的 msRTCSIP-Line 属性中配置的电话号码。

返回顶部

拨号计划的编号计划格式

除了添加 UMCallingLineIds 参数来帮助将呼叫者的 ID 解析为呼叫者的名称之外，UM 服务器还必须能够从 UMCallingLineId 获取号码（如 51010、555-1010 和 4255551010）并将其扩展为格式正确的 E.164 电话号码。 Set-UMDialPlan cmdlet 的 NumberingPlanFormats 参数用于执行此操作。

用于向 UM 拨号计划添加编号计划格式的语法如下：

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

如果要以这种方式将呼叫者 ID 解析为呼叫方名称，有两个要求：

• 必须为每个用户正确设置 E.164 号码。 但是，在 Active Directory 中配置每个收件人可能需要一些时间。

• 必须配置 UM 服务器可用来映射传入呼叫者 ID 并将其转换为格式正确的 E.164 电话号码的规则。 分机号码长度 ID 即是此类规则的一个示例。

Exchange 2010 统一消息服务器可以使用号码屏蔽将非规范的号码（如 5 位数字的分机号码）更改为更规范的形式（如 E.164 格式）。

号码掩码用于定义电话号码格式，统一消息服务器将使用该格式确定为用户拨出的电话号码，或在传入呼叫的转换头中使用的电话号码。 为传入呼叫和传出拨号规则执行号码屏蔽。 例如，91xxxxxxxxx 就是有效的号码掩码。 例如，当拨出电话的号码（如 4255551010）与拨号规则条目上的 91xxxxxxxxxx 号码掩码匹配时，统一消息服务器将替换与拨打的号码匹配的最右侧数字。 在此示例中，拨打的电话号码中有 10 位数字，这些数字用“x”表示。 由于这些数字匹配，UM 服务器将拨打 914255551010。此字段只能包含数字和字符 x。同样的过程也用于传入呼叫。

NumberingPlanFormats 参数是一个多值属性，当与 UM 拨号计划关联的 UM 服务器收到呼叫者 ID 号码（该号码随后可扩展为格式正确的 E.164 号码）时，可使用该属性。

下表显示了 NumberingPlanFormats 参数的 cmdlet、类型、说明和默认设置。

NumberPlanFormats 参数说明

在 Exchange 2007 统一消息中，拨号计划中的国际号码格式用于通过创建 E.164 电话号码来增强呼叫者 ID 解析。 E.164 电话号码随后可在 UM 服务器使用 msRTCSIPLine 属性搜索呼叫者的电话号码时使用。

在 Exchange 2010 统一消息中，已添加等效拨号计划组来增强呼叫者 ID 解析，从而扩大搜索范围。 通过在每个拨号计划中配置编号计划格式（这有助于将呼叫者 ID 转换为 E.164 格式），可以实现这一点。 有关等效拨号计划的详细信息，请参阅本主题中后面的等效拨号计划组。

例如，考虑有 20,000 名员工的公司。 该公司将需要为其员工提供 20,000 个唯一的直接拨入 (DID) 电话号码。 但是，该公司无法获得连续 DID 范围（如 425-555-xxxx 到 425-556-xxxx）中的号码。 第一组员工（10,000 名）具有号码前缀 425-567-xxxx，第二组员工（10,000 名）具有号码前缀 425-678-xxxx。

假设管理员为这 20,000 名员工创建了一个 UM 拨号计划，并且对每个用户使用 5 位数的分机号码。 当 PBX 接收呼叫时，PBX 将发送 5 位数的呼叫者 ID。但是，当该公司从旧版 PBX 迁移到 IP PBX 时，这些用户将位于两个单独的 PBX 中（每个用户使用自己的 5 位数 UM 拨号计划）。 这些用户迁移到 IP PBX 后，呼叫者 ID 名称解析将开始失败，只有 5 位数分机号码（而非呼叫者名称）将显示在语音邮件中。

发生这种情况是因为只在由这些前缀共享的 UM 拨号计划中配置了一个国际号码格式。 因此，只有一半启用了 UM 的用户将创建格式正确的 E.164 号码。 而且，用户位于不同的 PBX 拨号计划中。 所以，即使在 UM 拨号计划中启用了等效拨号计划，也并非对呼叫者启用 UM，并且呼叫者的分机号码将不会解析为名称。

NumberingPlanFormats 参数可用于解决该问题。 对于每个 UM 拨号计划，存在一个 msExchangeUMCallingLineIDFormats 属性，可以使用 NumberPlanFormats 参数配置此属性来指定一个或多个电话号码掩码（这些电话号码掩码可以将呼叫者 ID 解析为 Active Directory 中名称）。 下图显示了此属性和编号计划格式。

编号计划格式和 msExchangeCallingLineIDFormats 属性

当 UM 服务器应答传入呼叫时，它会读取呼叫者 ID。UM 服务器将从上到下分析所配置的号码计划格式的列表，直到未找到匹配项或号码掩码中的 x 被视为通配符的数字中存在冲突。 发生这种情况时，UM 服务器将尝试将传入呼叫的呼叫者 ID 反向填充到每个号码掩码中。 对于其号码前缀为 425-567-xxxx 和 425-678-xxxx 的员工，数字“7”和“8”是将为呼叫 ID 号码选择正确掩码所依据的键。 UM 服务器成功反向填充编号计划格式模式后，它将获取生成的 E.164 号码并针对 msExchUMCallingLineIDs 属性执行查找。 如果此查找失败，UM 服务器将针对 msRTCSip-Line 属性执行查找。

统一消息管理员必须检查不明确和无意义的编号计划格式规则，并重新配置它们。 不明确的编号计划格式规则是两个或多个规则，在这些规则中，最右侧字符完全相同且等于在拨号计划中配置的位数。 无意义的编号计划格式规则是这样一种规则，即该规则在最右侧某个数字之外的任何位置具有通配符，最右侧数字等于在拨号计划中配置的分机号码位数。

返回顶部

Active Directory Heuristics

除了 UM 主叫号码和编号计划格式外，Exchange 2010 统一消息还启用 Active Directory 启发式方法。

在 Exchange 2007 中，当尝试将传入呼叫的呼叫者 ID 解析为名称时，呼叫者 ID 解析不包括 Active Directory 中用户对象的电话字段。 这是因为：

• “电话”选项卡及“电话号码”字段中的字段未编制索引且不可搜索。

• “电话”选项卡及“电话号码”字段中的字段可能未采用标准化格式。

下图显示了 Exchange 2010 中的这些字段。

“电话”选项卡字段

Active Directory 中某个用户对象的“电话”选项卡上的“电话号码”字段有重大问题。 该字段对所插入号码的格式没有验证或限制。 这意味着这些号码未采用标准化格式。 下列潜在问题会阻止将呼叫者 ID 解析为名称：

• 管理员没有在“电话号码”字段中输入号码。

• 管理员根本没有使用“电话”选项卡输入电话号码。

• 输入 E.164 号码时未使用任何圆括号、连字符或正确的空格。

• 号码未采用正确的 E.164 格式。 正确格式的示例包括：

  • (425) 555-1010

  • (425) 555-1234 x51010

  • (425) 555-1234 ext. 51010

  • 425-555-1010

  • 425.555.1010

  • 425/555-1010

  • 1425-555-1010

• 既使用了分机号码，又使用了国际号码。 显示同时使用分机号码和国际号码的示例包括：

  • +7890

  • +441234567890

  • +44(1)234567890

  • +44 (0)1 2345 6789

Exchange 2010 统一消息服务器在尝试解析呼叫者 ID 时，将查询 Active Directory 以检查最多 8 个 Active Directory 属性（同时检查 EUM 代理地址以及 msExchUMCallingLineIDs 和 msRTCSIP-Line 属性）。每个拨号计划中有一个 msExchAllowHeuristicADCallingLineIDResolution 属性。 默认情况下，当您创建 UM 拨号计划时，msExchAllowHeuristicADCallingLineIDResolution 属性设置为 true。

可以使用 Set-UMDialPlan cmdlet 启用或禁用 Active Directory heuristics。 下表显示了 AllowHeuristicADCallingLineIdResolution 参数的 UM 拨号计划 cmdlet、类型、说明和默认设置。

AllowHeuristicADCallingLineIdResolution 参数说明

在启用 Active Directory 启发式方法后，UM 将使用电话号码字段，例如为 Active Directory 中的用户配置的家庭电话号码或移动电话号码。 但是，无法选择要包括哪个电话字段。 Active Directory 中的用户的以下电话属性将用于将呼叫者 ID 解析为名称：

• telephoneNumber

• homePhone

• mobile

• facsimileTelephoneNumber

• otherTelephone

• otherHomePhone

• otherMobile

• otherFacsimileTelephoneNumber

如果使用 Set-User cmdlet 填充某个用户的一个或多个电话属性，则必须运行 GalGrammarGenerator.exe –u 来更新每个用户的 DTMF 映射。 如果在安装统一消息服务器角色或使用 Exchange 命令行管理程序之外的程序之前填充电话字段或更新电话号码，还必须在为电话号码字段编制索引之前运行 Galgrammargenerator.exe –u。 有关如何运行 GalGrammarGenerator.exe 的详细信息，请参阅下列主题之一：

• 更新 UM 服务器上的语音语法文件

• 了解自动语音识别目录查找

返回顶部

等效拨号计划组

有时 UM 拨号计划的数量可能变得难以处理，原因可能是林的数量已增加或单个林中 UM 拨号计划的数量已增加。 为了提供一种伸缩性更强的解决方案，已在 Exchange 2010 统一消息中增加了一个新的 Active Directory 对象： 等效拨号计划组。 等效拨号计划组是 Active Directory 中的一个容器对象，将包含来自单独 Active Directory 林的等效拨号计划。

等效拨号计划组可与两个 Active Directory 属性一起使用：

• msExchangeUMEquivalenceDialPlan

• msExchangeUMEquivalentDialPlanPhoneContexts

已向 Exchange 2010 统一消息中增加了等效拨号计划的概念，以使 UM 管理员可将在同一 PBX 编号计划中但分为不同拨号计划的两个拨号计划相关联。 两个拨号计划可能会包含在一个 PBX 编号计划中，例如，当两个单独拨号计划中的用户彼此相邻而坐，并可使用分机号码拨打彼此，但由于与电话基础结构无关而存在于不同的拨号计划中的情况下。

注意：
分机号码在拨号计划中必须唯一，但它们在等效拨号计划组中也必须唯一。

对于每个拨号计划，两个或多个拨号计划可以有一个等效拨号计划电话上下文，这些拨号计划应该是一个拨号计划但已经分开。 可以为其他拨号计划添加名称并链接到其他拨号计划。 为其输入名称或链接到的拨号计划可以在同一 Active Directory 林中，也可在不同林中。 在添加等效拨号计划时，拨号计划的电话上下文将自动添加到等效拨号计划组中。

在添加具有不同电话上下文的多个拨号计划后，当统一消息服务器中传入呼叫时，它将不只查找具有同一电话上下文的 EUM 代理地址，而是查看具有列在等效拨号计划中的电话上下文的 EUM 代理地址。 只要拨号计划列在等效拨号计划中，并且只发送呼叫者 ID，则来自两个拨号计划的所有统一消息用户的号码都将正确解析为名称。

下表显示了 EquivalentDialPlanPhoneContexts 参数的 cmdlet、类型、说明和默认设置。

EquivalentDialPlanPhoneContexts 参数说明

例如，使用拨号计划的等效拨号计划电话上下文，可以运行以下命令来将两个 UM 拨号计划添加到一个等效拨号计划组中。

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

如果呼叫者的分机与该命令中指定的三个拨号计划中任一个上的任何启用了 UM 的用户匹配，分机号码将解析为呼叫者的名称。

返回顶部

 © 2010 Microsoft Corporation。保留所有权利。