本部分添加了与 混合服务有关的关键配置项目的相关背景信息。

如果想要成功部署 Webex 设备的混合通话功能，以下几点至关重要。我们特别强调这些项目的原因如下：

• 我们希望详加解释，以便于您能够理解它们在混合部署中的角色并感到放心。

• 它们是确保云和内建环境之间安全部署的必要前提条件。

• 应将它们视为前期准备活动：相较于用户界面中的典型配置，它们设置起来的时间可能会稍久一些，因此请预留一段时间以将这些项目设置妥当。

• 在环境中设置好这些项目后，其他 混合服务配置便会顺利进行。

Expressway-C 和 Expressway-E 对部署 允许使用 防火墙穿越技术进行与 Internet 之间的呼叫。此部署方案可安全地将您的本地呼叫控制系统与 Webex 连接起来。

由于防火墙穿越体系结构，Expressway-C 和 Expressway-E 不要求在隔离区 (DMZ) 防火墙上开放任何入站端口。但在互联网防火墙上必须开放入站的 TCP SIP 信令端口和 UDP 媒体端口才能让传入呼叫通过。您必须预留时间以在企业防火墙上打开相应端口。

下图显示的是防火墙穿越架构：

例如，对于使用 SIP 协议的企业对企业 (B2B) 入站呼叫，TCP 端口 5060 和 5061（5061 用于 SIP TLS）以及用于多种服务（如语音、视频、内容共享、双视频等）的 UDP 媒体端口必须在外部防火墙上打开。要开放哪些媒体端口取决于并发呼叫的数量与服务数量。

您可以将 Expressway 上的 SIP 侦听端口配置为 1024 至 65534 之间的任意值。同时，必须在公共 DNS SRV 记录中传播此值与协议类型，且必须在互联网防火墙上打开该值。

虽然标准设置是 SIP TCP 使用 5060，SIP TLS 使用 5061，但并不会阻止使用其他端口，如以下示例所示。

示例

在此例中，我们假定端口 5062 用于入站 SIP TLS 呼叫。

包含两个 Expressway 服务器的集群的 DNS SRV 记录类似于：

_sips._tcp.example.com SRV 服务位置：

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV 服务位置：

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

上述记录表示，使用传输类型 TLS 和侦听端口号 5062，以相同的负载分配（优先级与权重）将呼叫定向至 us-expe1.example.com 和 us-expe2.example.com。

网络（指互联网）外部设备向企业域用户 (user1@example.com) 发起 SIP 呼叫时，必须查询 DNS 以了解要使用哪一种传输类型、端口号、如何均衡流量负载以及向哪些 SIP 服务器发送呼叫。

如果 DNS 条目包含 _sips._tcp，则该条目指定 SIP TLS。

TLS 是客户端/服务器协议，在最通用的实现中使用证书进行验证。在企业对企业呼叫情境中，TLS 客户端为主叫设备，TLS 服务器为被叫设备。客户端通过 TLS 检查服务器证书，如果证书检查失败，将断开呼叫连接。客户端无需证书。

下图显示的是 TLS 握手：

但是，TLS 规范声明服务器也可以通过在 TLS 握手协议期间向客户端发送“证书请求”消息来检查客户端证书。此消息对服务器到服务器的连接很有帮助，例如在 Expressway-E 和 Webex 云之间建立的通话。这种概念称为具有相互认证的 TLS，在与 Webex 集成时是必需的。

主叫方和被叫方都会检查对方的证书，如下图所示：

云与 Expressway 相互检查身份。例如，如果证书中的云身份（CN 或 SAN）与 Expressway 上已配置的身份不匹配，则连接断开。

如果开启相互验证，Expressway-E 会一直请求客户端证书。结果，移动和远程访问 (MRA) 无法正常工作，因为在大多数情况下，证书不会部署到 Jabber 客户端。在企业对企业情境中，如果主叫实体无法提供证书，呼叫则将断开连接。

我们建议您将非 5061 的值用于具有相互验证的 TLS，如端口 5062。Webex Hybrid Services 使用与 B2B 相同的 SIP TLS 记录。如果使用端口 5061，其他一些无法提供 TLS 客户端证书的服务将无法运行。

如果现有记录已用于企业对企业通信，我们建议在 Control Hub 中将企业域的子域指定为 SIP 目标，并相应地创建一个公共 DNS SRV 记录，如下所示：

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

同一条高速公路上的企业对企业 (B2B)、移动和远程访问以及 Webex 流量

企业对企业 (B2B) 和移动及远程访问 (MRA) 呼叫使用端口 5061 进行 SIP TLS 通信，Webex 流量使用端口 5062 进行 SIP TLS 通信并进行相互认证。

域所有权检查是身份验证的一部分。域名验证是 Webex 云平台实施的一项安全措施和身份验证，用于证明您是您所声称的那个人。

身份检查分两个阶段执行：

1. 域所有权检查。此步骤涉及三种类型的域，且属于一次性验证检查：

   • 电子邮件域

   • Expressway-E DNS 域

   • 目录 URI 域

2. Expressway-E DNS 名称所有权检查。此步骤通过具有相互验证的 TLS 的实施得以执行，包括在云与 Expressway 上使用公共证书。不同于域身份检查，此步骤在向/从云发起/接收的任何呼叫期间执行。

域名所有权检查的重要性

Webex 云平台会执行域名所有权检查以确保安全性。如果未执行此检查，则将面临身份盗窃这一潜在威胁。

以下案例详述了未执行域所有权检查可能导致的后果。

一家域名为“hacker.com”的公司收购了Webex Hybrid Services。另外一家域设置为“example.com”的公司也在使用混合服务。Example.com 公司的其中一位总经理名叫 Jane Roe，其目录 URI 为 jane.roe@example.com。

Hacker.com 公司的管理员将她的其中一个目录 URI 设置为 jane.roe@example.com，同时将电子邮件地址设置为 jane.roe@hacker.com。她可以这样设置的原因是，在此例中云并不检查 SIP URI 域。

接下来，她登录了 Webex 应用程序。 jane.roe@hacker.com. 她拥有该域，验证电子邮件已被阅读并得到答复，因此得以成功登录。最后，她拨打了同事约翰·多伊的电话。 john.doe@example.com 来自她的 Webex 应用。John 正坐在办公室里，他在视频设备上看到了一通来自 jane.roe@example.com 的呼叫；那是与该电子邮件帐户关联的目录 URI。

他不禁想道：“她目前人在国外，或许需要某些重要的资料。” 他接听了电话，假冒的 Jane Roe 索要一些重要文档。她解释说她的设备坏了，又因为她在旅行途中，因此让他将文档发送至她的私人电子邮件地址：jane.roe@hacker.com。就这样，公司在 Jane Roe 回到办公室后才意识到重要信息已外泄。

Example.com 公司有很多方法来防范来自互联网的欺诈电话，但 Webex 云的职责之一是确保从 Webex 拨打电话的任何人的身份都是正确的，而不是伪造的。

为了验证身份，Webex 要求该公司证明其拥有混合呼叫中使用的域名。否则，混合服务将无法运行。

为确保此所有权，要求进行以下两个域验证步骤：

1. 证明公司拥有电子邮件域、Expressway-E 域和目录 URI 域。

   • 以上所有域都必须可路由且可被公共 DNS 服务器识别。

   • 为证明所有权，DNS 管理员必须输入 DNS 文本记录 (TXT)。TXT 记录是 DNS 中的一种资源类型，使您能够将某些随意的无格式文本与主机或其他名称关联起来。

   • DNS 管理员必须将该 TXT 记录输入必须证明所有权的区域中。完成该步骤后，Webex 云平台会对该域执行 TXT 记录查询。

   • 如果 TXT 查询成功，并且结果与从 Webex 云生成的令牌匹配，则域得到验证。

   • 例如，如果管理员希望 Webex Hybrid Services 在其域名“example.com”上运行，则必须证明她拥有该域名。

   • 她通过 https://admin.webex.com开始验证过程，创建一个 TXT 记录来匹配 Webex 云生成的令牌：

     

   • 然后，DNS 管理员为该域创建一个 TXT 记录，其值设置为 123456789abcdef123456789abcdef123456789abcdef123456789abcdef，如下例所示：

     

   • 此时，云可以验证域 example.com 的 TXT 记录是否与令牌相匹配。

   • 云执行 TXT DNS 查找：

     

   • 鉴于该 TXT 值与令牌值相匹配，此种匹配证明管理员向公共 DNS 添加了其域的 TXT 记录，从而证明了她拥有该域。

2. Expressway-E DNS 名称所有权检查。

   • 云必须核实 Expressway-E 拥有受云所信任的某个认证中心确认的身份。Expressway-E 管理员必须向上述某个认证中心请求 Expressway-E 的公共证书。为颁发证书，认证中心基于域验证检查（针对域验证证书）或组织验证检查（针对组织验证证书）执行身份验证过程。

   • 向/从云发起/接收的呼叫取决于已颁发给 Expressway-E 的证书。如果该证书无效，则呼叫断开。

Webex 设备连接器必须与 Webex 通信，混合通话功能才能正常工作。

Webex 设备连接器部署在内部网络中，它与云通信的方式是通过出站 HTTPS 连接——与任何连接到 Web 服务器的浏览器所使用的连接类型相同。

与 Webex 云的通信使用 TLS 协议。Webex Device Connector 是 TLS 客户端，Webex 云是 TLS 服务器。因此，Webex 设备连接器会检查服务器证书。

认证中心使用其私有密钥签署服务器证书。拥有公共密钥的任何人都能对该签名进行解码，并可证明是同一认证中心签发的该证书。

如果 Webex Device Connector 需要验证云端提供的证书，则必须使用签署该证书的证书颁发机构的公钥来解码签名。认证中心的证书中包含公共密钥。要与云使用的证书颁发机构建立信任，这些受信任证书颁发机构的证书列表必须位于 Webex 设备连接器信任存储中。

在与设备通信时，该工具使用您提供的受信任证书。目前实现方法是将它们放在 [home folder]/.devicestool/certs中。

穿越对中的 Expressway-E 同样需要认证中心的证书列表。Expressway-E 使用 SIP 和 TLS 与 Webex 云通信，并通过相互认证来强制执行。Expressway-E 仅信任来自云端和发往云端的呼叫，前提是云端在 TLS 连接建立期间提供的证书的 CN 或 SAN 与 Expressway 上为 DNS 区域配置的主题名称（“callservice.webex.com”）匹配。认证中心仅在完成身份检查后才会发布证书。要获得签名证书，必须证明对 callservice.webex.com 域名的所有权。因为我们（思科）拥有该域名，DNS 名称“callservice.webex.com”直接证明远程对等方确实是 Webex。

calendar Connector 通过Webex帐户将日历连接器与 Microsoft Exchange 2013、2016、2019 或 Office 365 集成。Exchange 中的应用程序模拟管理角色让应用程序能够模拟组织中的用户，代表该用户执行任务。应用程序模拟角色必须在 Exchange 中配置，并且用作 Expressway-C 界面上 Exchange 配置的一部分。

Microsoft 推荐使用 Exchange 模拟帐户来完成此任务。Expressway-C 管理员无需知道密码，因为可由 Exchange 管理员在 Expressway-C 界面中输入该值。即便 Expressway-C 管理员拥有对 Expressway-C 框的根访问权，密码也不会明确显示。与 Expressway-C 上的其他密码一样，该密码也将采用相同的凭证加密机制进行加密存储。

为了提高安全性，请按照《Cisco Webex 混合日历服务部署指南》中的步骤启用 TLS，以确保 EWS 有线连接的安全。

为了提高安全性，请按 部署 Expressway Calendar Connector for Microsoft Exchange 中的步骤启用 TLS，以确保 EWS 有线连接的安全。