了解统一消息拨号计划
适用于: Exchange Server 2010 SP2, Exchange Server 2010 SP3
上一次修改主题: 2009-12-10
统一消息 (UM) 拨号计划是运行 Microsoft Exchange Server 2010 统一消息以及在网络上成功部署统一消息所必不可少的。下列各节讨论 UM 拨号计划以及在网络上部署 Exchange 2010 统一消息时如何使用 UM 拨号计划。
UM 拨号计划概述
尽管统一消息在部署期间必须创建并配置许多 Active Directory 对象,但是 UM 拨号计划对象是统一消息系统的中心组件。UM 拨号计划对象是在 Exchange 2010 中创建的 Active Directory 组织级对象。它代表共享公用用户分机号码的专用交换机 (PBX) 的组或分组。实际上也就是,拨号计划中 PBX 或 IP PBX 托管的所有用户的分机都包含相同的位数。用户在拨打其他用户的电话分机时,可以不必为分机加拨特殊号码,也不必拨打完整的电话号码。
UM 拨号计划镜像了电话服务拨号计划。电话拨号计划是在 PBX 或 IP PBX 上配置的。
有关电话组件的详细信息,请参阅了解电话概念和组件。
在统一消息中可以存在下列 UM 拨号计划拓扑:
代表拥有一台 PBX 或 IP PBX 的组织的部分分机或所有分机的一个拨号计划。
代表拥有多台联网 PBX 或 IP PBX 的组织的部分分机或所有分机的一个拨号计划。
代表拥有一台 PBX 或 IP PBX 的组织的部分分机或所有分机的多个拨号计划。
代表拥有多台 PBX 或 IP PBX 的组织的部分分机或所有分机的多个拨号计划。
属于同一拨号计划的用户具有下列特征:
在拨号计划中唯一标识用户邮箱的分机号码。
可以只使用分机号码呼叫拨号计划中的其他成员或向拨号计划中的其他成员发送语音邮件。
有关如何启用用户的统一消息的详细信息,请参阅为用户启用统一消息。
在 Exchange 2010 统一消息中实施 UM 拨号计划可以确保用户电话分机是唯一的。在某些电话网络中,可以存在多台 PBX 或 IP PBX。在此类电话网络中,Active Directory 中可能会存在两个拥有相同电话分机号的用户。UM 拨号计划可以解决这种情况。可以将这两个用户放到两个单独的 UM 拨号计划中。这样可以使其分机都是唯一的。
注意: |
---|
用户只能是一个 UM 拨号计划的成员。也可以使用 UM 拨号计划为用户组设置一组公用策略。例如,可以为不同的 UM 拨号计划启用不同的语言,也可以为不同的 UM 拨号计划启用不同的功能。 |
下图说明了如何在拥有一个林和多个物理站点的组织中使用 UM 拨号计划。
拥有多个物理站点的组织中单个林中的 UM 拨号计划
拨号计划的工作方式
将电话网络与 Exchange 2010 统一消息集成在一起时,必须通过一个硬件设备(称为 IP 网关)将电话网络与基于 IP 的网络连接在一起。IP 网关将电话网络中的电路交换协议转换为数据交换协议(例如 IP)。组织中的每个 IP 网关用 Active Directory 中的 UM IP 网关对象表示。有关 UM IP 网关的详细信息,请参阅了解统一消息 IP 网关。
Exchange 2010 统一消息要求创建至少一个 UM 拨号计划,并要求有统一消息服务器和 UM IP 网关与该 UM 拨号计划相关联。在 Exchange 2010 计算机上安装统一消息服务器角色之后,必须将统一消息服务器与至少一个 UM 拨号计划相关联,之后该服务器才能应答呼叫。也可以将一台统一消息服务器与多个 UM 拨号计划关联。将统一消息服务器与 UM 拨号计划关联之后,必须创建 UM IP 网关并将其与已创建的 UM 拨号计划关联。
重要说明: |
---|
每次创建 UM 拨号计划时,都会创建 UM 邮箱策略。UM 邮箱策略将命名为<拨号计划名称>默认策略。 |
如果在创建第一个 UM IP 网关时指定了 UM 拨号计划,则还会创建默认 UM 智能寻线。通过在 Active Directory 中创建和关联这些对象,统一消息服务器可以接收来自 IP 网关的呼叫,然后为与 UM 拨号计划关联的用户处理传入呼叫。呼叫传入 IP 网关时,它将呼叫转接到统一消息服务器,统一消息服务器尝试将用户的分机号码与关联的 UM 拨号计划进行匹配。
有关如何将统一消息服务器添加到 UM 拨号计划中的详细信息,请参阅向拨号计划添加 UM 服务器。
拨号计划的类型
统一资源标识符 (URI) 是一个字符串,用来标识或命名资源。在统一消息中,URI 的主要用途是允许 IP 语音 (VoIP) 设备通过特定的协议与其他设备通信。URI 定义了用于呼叫方及被叫方信息的命名和编号格式或方案,该信息包含在传入或传出呼叫的会话初始协议 (SIP) 标头中。
Exchange 2010 统一消息中创建的 UM 拨号计划类型取决于组织中受 IP 网关、PBX 或 IP PBX 支持的 URI 类型。在创建拨号计划时,应了解 PBX 或 IP PBX 所支持的特定 URI 类型。可以在 UM 拨号计划上配置以下三种格式或 URI 类型:
电话分机
SIP URI
E.164
在统一消息中,每次创建拨号计划时,默认情况下创建的拨号计划将使用电话分机 URI 格式类型。不过,在使用“新建拨号计划向导”或 New-UMDialPlan cmdlet 创建拨号计划时可以配置 URI 类型。在创建拨号计划后,将无法更改该 URI 类型。
电话分机
电话分机 URI 类型是 UM 拨号计划中最常见的类型,与 PBX 和 IP 网关配合使用。在配置电话分机 (TelExtn) 拨号计划时,IP 网关和 IP PBX 必须支持电话分机 (TelExtn) URI 类型。当 IP 网关或 IP PBX 与拨号计划关联的统一消息服务器通信时,必须配置该拨号计划才能支持 TelExtn URI 类型。一般情况下,目前大多数 PBX 都支持电话分机 URI 类型。但 IP 网关和 UM 拨号计划也必须支持电话分机 URI 类型。
当 PBX 或 IP PBX 接到呼叫而启用 UM 的用户无法应答呼叫时,PBX 或 IP PBX 将把该呼叫转发给 IP 网关。在 SIP 包(该包由统一消息服务器从 IP 网关中接收)的标头中,呼叫方和被叫方信息将采用以下某种格式列出:
电话:512345
512345@<IP 地址>
所用的电话分机 (TelExtn) 格式基于 IP 网关或 IP PBX 的配置。
SIP URI
会话初始协议 (SIP) 是一种用于初始化交互用户会话(其中包括一些多媒体元素,如视频、音频、聊天和游戏)的标准协议。SIP 是一种基于请求到响应的协议,它回答来自客户端的请求和来自服务器的响应。客户端由 SIP URL 标识。可以通过任何传输协议(如 UDP 或 TCP)发送请求。SIP 通过选择通信介质和介质参数来确定用于会话的终结点。
在创建新拨号计划时,可以选择创建 SIP URI 拨号计划,该计划可用于已经部署了 Microsoft Office Communications Server 2007 的环境中或者具有 IP PBX 的组织中。不过,在具有 IP PBX 的组织中,IP PBX 还必须支持 SIP URI 和 SIP 路由。
SIP URI 是 SIP 寻址方案,用于使用 SIP 呼叫其他人。换言之,SIP URI 就是用户的 SIP 电话号码。SIP URI 类似于电子邮件地址,并用以下格式书写:sip*:<用户名>@<域或 IP 地址>*:端口。当通过启用了 SIP 的 IP PBX 或 IP 网关向统一消息服务器发送呼叫时,该设备将只发送位于 SIP 标头中呼叫方或被叫方的 SIP URI,而不包括分机号码。
E.164
E.164 是一种标准的编号格式,它定义了在公用电话交换网 (PSTN) 和一些数据网络中所使用的国际公用电信编号计划。E.164 定义了电话号码的格式。E.164 号码最多可有 15 位数,并且一般在电话号码的数字前有一个加号 (+)。若要通过电话拨打 E.164 格式的电话号码,所拨的号码中必须包括正确的国际呼叫前缀。在公用电话系统的 E.164 编号计划中,每个指定的号码都包含一个国家/地区代码 (CC)、一个国内目的地代码 (NDC) 和一个订阅者号码 (SN)。
在创建新拨号计划时,可以选择创建 E.164 拨号计划。不过,如果创建和配置 E.164 拨号计划,PBX 和 IP PBX 必须支持 E.164 路由。统一消息服务器从与 E.164 拨号计划关联的 IP 网关接收的 SIP 标头将包括呼叫方和被叫方信息的 E.164 格式的电话号码,并且将采用以下格式列出:电话:+14255550123。
VoIP 安全性
安装了 Exchange 2010 的统一消息服务器可以在不安全、SIP 安全或安全模式下与 IP 网关、IP PBX 和其他 Exchange 2010 计算机进行通信,具体取决于 UM 拨号计划的配置方式。由于将统一消息服务器配置为在 TCP 端口 5060 上侦听不安全的请求,同时在 TCP 端口 5061 上侦听安全的请求,因此可以在拨号计划中配置的任何模式下运行统一消息服务器。统一消息服务器可以与单个或多个 UM 拨号计划关联,并且可以与具有不同的 VoIP 安全设置的拨号计划相关联。可以将单个统一消息服务器与配置为使用不安全、SIP 安全和安全模式组合的拨号计划关联。
默认情况下,创建 UM 拨号计划时,它将使用不安全模式进行通信;与 UM 拨号计划关联的统一消息服务器通过使用非加密方式处理与 IP 网关、IP PBX 及其他 Exchange 2010 计算机之间的往来数据。在非安全模式下,实时传输协议 (RTP) 媒体通道与 SIP 信号信息都不会进行加密。可以使用 Exchange 命令行管理程序中的 Get-UMDialPlan cmdlet 来确定特定 UM 拨号计划的安全设置。
可以将统一消息服务器配置为使用相互传输层安全性 (MTLS) 对从其他设备和服务器发送和接收的 SIP 和 RTP 通信进行加密。当向 UM 拨号计划添加统一消息服务器并将拨号计划配置为使用 SIP 安全模式时,仅加密 SIP 信号通信,RTP 媒体通道仍使用未加密的 TCP。但是,如果将统一消息服务器添加到 UM 拨号计划并将拨号计划配置为使用安全模式,则加密 SIP 信号通信和 RTP 媒体通道。使用安全实时传输协议 (SRTP) 的加密信号媒体通道还将使用相互 TLS 来加密 VoIP 数据。
在创建新拨号计划时或在创建拨号计划之后,可以通过在命令行管理程序中使用 EMC 或 Set-UMDialPlan cmdlet 来配置 VoIP 安全模式。将 UM 拨号计划配置为使用 SIP 安全或安全模式时,与该 UM 拨号计划关联的统一消息服务器将加密 SIP 信号通信或 RTP 媒体通道,或者同时加密两者。但是,为了能够与统一消息服务器互相收发加密数据,必须正确配置 UM 拨号计划,并且 IP 网关或 IP PBX 等设备必须支持 Mutual-TLS。
有关 VoIP 安全和 UM 拨号计划的详细信息,请参阅了解统一消息 VoIP 安全性。
Outlook Voice Access
下列两种类型的呼叫者将使用 UM 拨号计划中配置的订阅者访问号码来访问统一消息系统:未经身份验证的呼叫者和经过身份验证的呼叫者。当呼叫者拨打拨号计划中配置的订阅者访问号码时,则在输入包括语音邮件分机和 PIN 在内的信息之前,这些呼叫者将被视为匿名呼叫者或未经身份验证的呼叫者。但是,为匿名呼叫者或未经身份验证的呼叫者提供的唯一选项是目录搜索功能。呼叫者输入其语音邮件分机号和 PIN 后,系统将对其进行身份验证,并给予他们访问其邮箱的权限。呼叫者获取对系统的访问权限后,可以使用 Outlook Voice Access 功能。Outlook Voice Access 是一系列语音提示,该提示给予呼叫者访问电子邮件、语音邮件、日历和其他信息的权限。Outlook Voice Access 可使经过身份验证的呼叫者使用双音多频 (DTMF)(也称为按键)或语音输入在其邮箱中导航个人信息、发出呼叫或查找用户。
重要说明: |
---|
在某些公司(特别是东亚的公司)中,营业室电话键上可能未显示字母。这样的话,如果不了解键映射的工作原理,几乎就无法运用使用按键输入的读出姓名功能。默认情况下,Exchange 2010 统一消息使用 E.161 键映射。例如,2=ABC、3=DEF、4=GHI、5=JKL、6=MNO、7=PQRS、8=TUV、9=WXYZ。 在输入字母和数字的组合(例如“Jim1092”)时,数字将映射到其自身。为正确输入电子邮件别名“Jim1092”,用户必须按数字 5461092。同时,对于 A-Z 和 0-9 以外的字符,不存在对应的电话键。因此,不应输入这些字符。例如,电子邮件别名“jim.wilson”应输入为 546945766。即使要输入的字符有 10 个,用户也只能输入 9 个数字,因为句点 (.) 没有对应的数字。 |
订阅者访问号码
创建 UM 拨号计划之后,您需要至少添加一个订阅者访问号码。订阅者访问号码也称为引导号码。此号码供 Outlook Voice Access 用户用来访问其邮箱,并使他们可以搜索目录。
默认情况下,创建 UM 拨号计划时,不会配置订阅者访问号码。若要启用订阅者访问,必须配置至少一个电话号码或分机号码。订阅者访问号码中的字母数字字符数不能超过 20 个。在拨号计划上配置此号码后,此号码将显示在 Microsoft Office Outlook 2007、Outlook 2010 和 Outlook Web App 语音邮件选项中。
可以在 UM 拨号计划上使用“输入要关联的电话号码”字段添加使用 Outlook Voice Access 统一消息系统时用户将呼叫的电话号码或分机号码。大多数情况下,应当输入分机号码或外部电话号码。但是,由于此字段接受字母数字字符,因此,如果正在使用 IP PBX,则可以使用 SIP URI。
根据组织需求的不同,您可能需要一个或多个订阅者访问号码。您可以在一个 UM 拨号计划中配置一个订阅者访问号码,也可以在一个 UM 拨号计划中配置多个订阅者访问号码,但是您不能配置一个跨多个 UM 拨号计划的订阅者访问号码。
© 2010 Microsoft Corporation。保留所有权利。