沟通与协作

OCS 2007 如何利用语音功能

Rajesh Ramanathan

概览：

• 在 OCS 2007 中进行呼叫
• 如何保证呼叫的安全
• OCS 中执行多模会话
• 与 Exchange UM 集成以发送语言邮件

目录

基本语音呼叫
使用电话号码
保护呼叫
穿越 NAT 和防火墙
根据电话号码路由
入站路由
质量报告和故障排除
组合
多模行为和会话
语音邮件
结束语

Microsoft Office Communication Server (OCS) 2007 系列文章的第一部分讲述了如何博采 Live Communication Server (OCS) 2005 之长构建 OCS，

以提供更强大的企业级即时消息 (IM) 和状态显示功能，以及高级媒体和电话功能（请参阅 2008 年 2 月刊的《TechNet 杂志》**，网址为：technet.microsoft.com/magazine/cc194409）。本文将继续深入探讨 IP 语音 (VoIP) 方面的内容。我将解释在 OCS 系统中进行语音呼叫有多么简单，并分层介绍技术，以便随同对应的功能展示每个组件。

如之前文章提到的，可通过以下多种配置设置 OCS 向用户提供电话功能：

企业语音 它是一个使用 OCS 和 Microsoft® 中介服务器的完整统一通信解决方案，无需 PBX。Exchange 统一消息 (UM) 在此系统中提供语音邮件功能。从现在起，我将具有此服务的用户称为“UC 用户”。我还将使用术语“UC 端点”来指代此配置中的客户端。

集成了 PBX 的企业语音 此配置使用户在保留桌上现有 PBX 电话的同时从统一通信中受益。它允许并行设置 OCS 和 PBX，这样传入呼叫可同时对 Office Communicator 和 PBX 端点振铃。PBX 仍拥有呼叫路由且仍提供语音邮件服务。

远程呼叫控制 此功能将 PBX 电话用作主电话，并且允许通过 Office Communicator 客户端控制电话。

基本语音呼叫

在此我将重点介绍企业语音用户的工作机制。如 RFC 3261 所述，利用 SIP INVITE 机制在 OCS 系统中设置简单语音呼叫。OCS 服务器承担类似邮局主管的代理角色，在客户端（或端点）之间转播消息。只要创建实时会话（如呼叫或即时消息会话），客户端就会生成新的 SIP INVITE。如果通过应答（即，远程端点发送一个 200 OK 响应）确认 INVITE，即建立起呼叫（请参阅图 1）。

图 1 INVITE 格式和 200 OK

INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**

在图 2 中，Alice 通过在 Office Communicator (OC) 2007 中选择 Communicator Call 来呼叫 Bob，OC 2007 产生一个发往 Bob 的 SIP 统一资源标识符或 URI (sip:bob@example.com) 的 INVITE。INVITE 带有媒体端点（Alice 用于接收音频）的音频会话描述符（称为 SDP，代表 Session Description Protocol）。OCS 将 INVITE 插入 Bob 注册的 SIP 端点（例如，Communicator Phone Edition 和 Communicator 桌面）。INVITE 包含“发件人”标头 sip:alice@example.com；Bob 的客户端端点在反向名称查找 (RNL) 中使用它来查找名称 (Alice)，将其显示在传入呼叫通知中。

图 2 将呼叫路由到多个端点（单击此图像查看大图）

每个端点均显示有可全局路由用户代理 URI (GRUU)。GRUU 是 SIP 端点的唯一标识，它是在从 OCS 服务器注册的过程中获取的。GRUU 地址有助于路由 SIP 消息，因此一旦端点回答呼叫，就可直接使用 GRUU 地址在端点之间传送其他转换操作的后续 SIP 信号。

图 3 是后续过程，Bob 通过 Communicator 桌面进行应答。Bob 的 OC 发送一个 200 OK 消息来说明他接收音频的位置。一旦 OCS 代理检测到有端点做出了应答，它将取消对其他 Communicator Phone Edition 端点的呼叫。200 OK 响应到达 Alice 的 Communicator 端点后，两个 Communicator 端点均拥有充足的信息（IP 端口、加密参数等）来启动媒体。

图 3 从一个端点做出应答（单击此图像查看大图）

使用电话号码

到目前为止，我们看到了用户单击 Communicator Call 创建邀请。该过程与用户选择或键入电话号码时的情形有所不同：

• 客户端首先规范化电话号码并将其显示为 TEL URI（它根据 RFC 3966 的指示描述了电话号码所标识的资源）。
• 由于 OCS 服务器仅识别 SIP URI，因此客户端通过添加域后缀和 user=phone 标记来将 TEL URI 转换成对应的 SIP URI。
• 如果号码对应于内部用户，OCS 将直接路由邀请。如果为外部号码，邀请将路由到最近的 SIP-PSTN 网关。

对公共交换电话网络 (PSTN) 号码的某些呼叫要求在应答呼叫前建立媒体路径，这样才可播放远程通知或收集其他数字以完成呼叫。在此类情形下，PSTN 网关发送一个 183 会话进度指示符和一个音频 SDP。Communicator 使用此信息来在远程用户应答呼叫之前与一个目标端点建立双向媒体路径。

一旦之前的所有媒体路径均建立完毕，Communicator 将启用双音多频或 DTMF（电话信号音）键盘，这样用户可输入远程系统需要的任意其他数字。输入的所有 DTMF 数字均在媒体路径中作为 RFC 2833 数据包发送。PSTN 网关负责在 PSTN 端生成适当的 DTMF 语音信号。

请注意，如果 Bob 启用了对手机的同时振铃，OCS 代理将把呼叫路由到网关，并同时振铃 Bob 的其他 Communicator 端点。在此类情形中，OCS 代理指出插入在 183 会话进度响应中为活动状态，这使 Communicator 与 PSTN 网关建立一个仅执行接收的媒体通道。

保护呼叫

OC 建立的语音呼叫的一项关键功能是默认根据 RFC3711 中的定义使用安全实时传输协议 (SRTP) 来加密媒体。SRTP 提供机密性、消息身份验证和对 RTP 通信的重播保护。在建立呼叫的过程中，客户端自身之间协商安全功能，并根据 INVITE 机制交换加密密钥。

OC 的默认加密设置为“可选”，它允许两个 OC 端点建立加密的媒体通道。管理员可调整此设置以保证组织遵章守法。例如，可将其设置得更加严厉以强制对所有呼叫进行加密，或者全部关闭。

穿越 NAT 和防火墙

OCS 系统中的客户端使用交互式连接建立 (ICE) 技术来向网络地址转换 (NAT) 设备和防火墙后面的用户提供媒体连接性能，无需更改现有 NAT 组件。ICE 技术目前正由 Internet 工程任务组 (IETF) 进行标准化。每个客户端均了解通过区内置备机制为其提供服务的音频/视频 (A/V) 边缘服务器，并且在登录过程中维持到 A/V 边缘的验证链接。

在进行呼叫之前，客户端会在 A/V 边缘服务器（对于媒体中继）、NAT 或主机客户端本身的可能连接性位置（地址和端口，也称为候选对象）上分配资源。在发出会话初始协议 (SIP) INVITE 时，它会将此连接性信息包含在内。200 OK 应答携带对等方的类似候选对象信息。一旦每个端点都拥有一个对等候选对象列表，随后，完善的排名和检查机制就会选择两个对等方之间的最优路径，从而保证媒体的成功。

根据电话号码路由

由于以下因素，根据电话号码路由比基本呼叫机制更复杂：

• 组织可能有各种拨号计划，它们部署在内部，用于快速拨号。
• 号码可能以非标准格式存储（例如，用户可能在 Microsoft Office Outlook® 中保存七位字符串）。
• 存在多种映射到不同外部号码的策略。例如，可能阻止某些用户拨打国际长途。

OCS 系统要求电话号码为 RFC 3966 TEL URI 格式，这样才能正确路由它们。不是这种格式的号码需先进行转换，然后客户端才发送 INVITE。图 4 中的图表显示了 OCS 系统中的具体操作细节。

图 4 路由电话号码（单击此图像可查看较大视图）

客户端可用的号码可能来自各种来源。预规范化号码来自通讯簿服务 (ABS)（此服务使用管理员定义的规范化规则将号码转换成规范化的 E.164 格式）。一旦客户端向规范化号码发送 SIP INVITE，OCS 即应用转换过程来将号码映射成内部用户。

• 第 1 步显示输入系统的号码或是唯一（规范化，遵循 E.164 编号规划），或具有标识位置的电话上下文。这些号码将包含在 SIP INVITE 之内，发送给服务器。OCS 将 INVITE 路由到一个转换过程。
• 转换过程（第 2 步）尝试利用服务器侧的 RNL 将电话号码映射到 UC 端点。转换可将该号码的路由确定为某个出站路由或某个 UC 用户，如果无法正确转换号码，呼叫将失败且代码为 4xx。
• 如果号码转换成非 UC 或外部号码，在针对与呼叫方相关的号码应用策略（第 3A 步）后，它将发送到出站路由组件，此组件将 INVITE 重定向到适当的 SIP-PSTN 网关以便执行进一步处理。出站路由负责均衡网关间的呼叫负荷，或在必要时故障转移到备用网关。如果禁止对某个号码的访问，出站路由过程可能失败、拒绝呼叫并返回一个 SIP 403 响应代码。请注意，出站路由仅适用于呼叫方为 UC 用户的情形。如果不是这样，OCS 会尝试使用对该 URI 所设置网关的静态路由。
• 如果号码转换成 UC 用户的号码，INVITE 将路由到该用户的 SIP URI（第 3B 步）。入站路由是 OCS 的一项功能，仅适用于 UC 用户和目标为 SIP URI 的所有呼叫。正如您将看到的，入站路由将针对 UC 用户应用振铃超时、呼叫转发和语音邮件转发规则。

请注意，从规范化过程产生的号码可能由于客户端位置不同而有所不同。管理员可设定位置配置文件并分配特定于某个位置的号码转换规则（如四位拨号在该位置中的工作原理）。每个 UC 用户分配一个位置配置文件，系统中的所用客户端都使用区内置备来下载特定于自身位置配置文件的规则。接下来我将详细介绍入站路由。

入站路由

入站路由规则指定当系统中存在或不存在注册客户端时应如何路由到某个用户的呼叫。传入路由组件还负责根据显示状态向传入呼叫应用规则；例如，如果用户已将状态显示设为“请勿打扰”，则它可将传入呼叫发送到语音邮件。传入路由了解显示状态容器级别，并且自动拒绝来自阻止容器中用户的呼叫。图 5 显示了 OCS 入站路由组件支持选项的摘要。

图 5 入站路由功能

入站路由规则将包含在用户自置备信息之内，上载到服务器作为 XML 架构。图 6 展示了入站路由的工作原理。OCS 系统中某个用户的传入呼叫默认振铃此用户（显示为 "Me"）。如果未在振铃持续时间内应答呼叫，将默认向语音邮件发送无人应答呼叫。用户可选择立即转发到某个号码、另一个人或直接发到语音邮件来修改默认配置。

图 6 路由呼叫（在工作时间）（单击此图像可查看大图）

立即转发到另一个人或号码的任何呼叫均将导致该人员或号码的入站路由规则生效。用户也可设置到另一号码或人员的无人应答呼叫转发。

如果用户在转发规则内选中选项“仅在 Outlook 工作时间应用”，则将在工作时间应用图 6 中所示的规则，在其余时间默认振铃已注册端点。请注意，此行为要求组织部署了 Microsoft Exchange Server 2007 和 Outlook 2007 客户端，因为 Communicator 要使用来自 Exchange 2007 可用性 Web 服务的工作时间信息，并且利用 Outlook 2007 自动发现支持来获取服务器位置。

质量报告和故障排除

OCS 2007 系统中的客户端使用 RTAudio，尽管这种新一代的音频编码解码器可容忍不完美的网络状况，如抖动、数据包丢失等，但监视仍必不可少，这样管理员可找出并修复潜在的热点。OCS 2007 系统中的客户端在每次呼叫结束时向中央体验质量 (QoE) 服务器报告每个呼叫的质量，并提供详细的统计数据，包括带宽、丢失、抖动、平均意见分数（一种用户感受的度量方式）、使用的设备等等。其实现方式是将 SIP SERVICE 请求中的负载发送给 QoE 服务器（它的地址是利用区内置备机制编程确定的）。

请注意，所有客户端端点都是独立地向 QoE 服务器报告呼叫质量。如果由于信号中存在错误而导致呼叫失败，客户端也会向 OCS 报告同样的内容，提供一个存储库来存放客户端出现的所有错误。

组合

既然已了解建立呼叫的各个方面（包括输入号码、入站和出站路由以及连接性检查），让我们来总体看一看这个过程。图 7 总结了从用户开始呼叫起所发生的情况。OCS 系统中的客户端在建立呼叫过程中起着至关重要的作用，它们管理整个呼叫建立过程。OCS 参与了呼叫的初始路由，边缘服务器帮助客户端查找最优的媒体路由。现在让我们来看看接下来发生的情况 — 会话。

图 7 端对端呼叫流（单击图像可查看大图）

多模行为和会话

会话概念是 OCS 系统的核心。会话是两个或多个人之间的多模会话，可同时包括语音、视频和 IM，还有各种项目（如会话时的文件传输、Outlook 中的电子邮件或存储在 Microsoft Office OneNote® 中的笔记）。

以下几个会话因素可能对 OCS 客户端系统的设计产生影响：

• 会话中涉及的所有情态使用相同的窗口。如果将即时消息添加到音频会话中，它亦会在同一窗口内起作用。
• 可跨设备进行会话。用户可选择在 Communicator Phone Edition 上实现音频，但在 Communicator 桌面上使用 IM。
• 所有模式一起升级为会议：如果出现升级3，则必须一起升级会话的所有情态（无论情态当前位于哪个设备）。例如，如果音频模式位于 Communicator Phone Edition，而相同会话的 IM 模式位于 Communicator 桌面，则升级为会议可确保该会话的音频和 IM 有同一组参与者。
• 记录总体会话，但不记录个人会话。呼叫日志包含完整的会话信息，包括会话期间笔记、即时消息对答以及音频持续时间等详细信息。从而使用户在 Outlook 中打开呼叫日志时可方便地全面了解整个会话。
• 可从会话日志继续会话。OCS 客户端使用会话 ID（唯一标识设备和应用程序间会话的一个号码）归纳会话。当从旧会话的历史记录日志开始新会话时，将使用一个完善的机制来计算会话的增量。相同的会话 ID 还作为电子邮件 ID 存储在 Outlook 中。

会话 ID 包含在 SIP INVITE 中，作为自定义属性 Ms-Conversation-Id 传递。图 8 显示的事务首先添加语音，然后添加 IM。请注意，在多模会话结束时，存储在 Outlook 中的历史记录日志具有相同的会话 ID。

图 8 多模会话和会话 ID（单击此图像查看大图）

Exchange UM 是用于 OCS 2007 的语音邮件系统。OCS 仅将启用了 UC 的用户的呼叫路由到 Exchange UM。OCS 提供了多种用于与 Exchange UM 集成的功能：

• Communicator 电话 UI中的“呼叫语音邮件”（请参阅图 9）允许用户不必输入 PIN 即可管理 UM 邮箱、更改问候等，因为他已通过身份验证。
• Communicator UI 中的消息等待指示（请参阅图 10）允许用户在 Outlook 中打开语音邮件文件夹，而 Communicator Phone Edition 中的消息等待指示则允许用户直接通过电话播放语音消息。
• 可使用 Communicator 的 UI 将呼叫转发到语音邮件。
• 拒绝呼叫将自动路由到语音邮件。
• 从 Outlook 中的语音邮件项“在电话上播放”可直接振铃 Office Communicator 客户端。

图 9 Communicator 中的呼叫语音邮件选项

图 10 Communicator 中的消息等待指示

OC 用于接收语音邮件通知的机制与 Communicator Phone Edition 有所不同。OC 在 Outlook 的语音邮件搜索文件夹中注册新邮件通知并在此文件夹中报告新消息。Communicator 还使用“错过的对话”和“呼叫日志”。

结束语

我在此展示了语音呼叫在 OCS 2007 中的工作原理，该系统的构建基础是利用多个 RFC 的 SIP。在 OCS 中，客户端端点在管理呼叫方面起着重要的作用。默认情况下，会加密所有语音呼叫。OCS 具备灵活的组件，用于操控号码并管理其在系统中的流动。

会话是 OCS 中的中心概念，包括语音、IM 和视频。OCS 与 Exchange UM 相集成，并允许 Communicator 端点接收语音邮件通知，通过 Outlook 或直接从服务器访问语音邮件。

Rajesh Ramanathan 已经在通信行业工作了 14 年，他为 Office Communicator 2007 设计了语音协议、用户体验以及语音和会议。他目前是 Microsoft Office Communicator 团队的首席项目经理。可通过 rajeshra@microsoft.com 与 Rajesh 联系。

© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容。