使用直接路由规划媒体旁路
关于使用直接路由的媒体旁路
媒体旁路使你能够缩短媒体流量的路径并减少传输中的跃点数，以提高性能。 使用媒体旁路，媒体将保留在会话边界控制器 (SBC) 和客户端之间，而不是通过Microsoft Teams 电话发送媒体。 若要配置媒体旁路，SBC 和客户端必须位于同一位置或网络中。
可以使用 Set-CSOnlinePSTNGateway 命令控制每个 SBC 的媒体旁路，并将 -MediaBypass 参数设置为 true 或 false。 如果启用媒体旁路，并不意味着所有媒体流量都将保留在公司网络中。 本文介绍不同方案中的调用流。
下图演示了使用和不使用媒体旁路的呼叫流的差异。
如果没有媒体旁路，当客户端发出或接收呼叫时，SBC、Microsoft Teams 电话和 Teams 客户端之间的信令和媒体流，如下图所示：
但假设用户与 SBC 位于同一建筑物或网络中。 例如，假设位于法兰克福某栋大楼中的用户向 PSTN 用户拨打电话：
如果没有媒体旁路，媒体将流经阿姆斯特丹或都柏林 (Microsoft 数据中心部署) ，然后返回到法兰克福的 SBC。
之所以选择欧洲数据中心，是因为 SBC 位于欧洲，并且 Microsoft 使用离 SBC 最近的数据中心。 虽然此方法不会影响通话质量，因为大多数地理位置的 Microsoft 网络内的流量优化，但流量有一个不必要的循环。
使用媒体旁路，媒体直接保留在 Teams 用户和 SBC 之间，如下图所示：
媒体旁路在 Teams 客户端上使用称为交互式连接建立 (ICE) 的协议，在 SBC 上使用 ICE lite。 这些协议使直接路由能够使用最直接的媒体路径来获得最佳质量。 ICE 和 ICE Lite 是 WebRTC 标准。 有关这些协议的详细信息，请参阅 RFC 5245。
呼叫流和防火墙规划
呼叫流和防火墙规划取决于用户是否有权直接访问 SBC 的公共 IP 地址，以及用户是在网络内部还是外部。
如果用户可以直接访问 SBC 的公共 IP 地址，则调用流
如果用户可以直接访问 SBC 的公共 IP 地址，则调用流如下所示：
对于媒体旁路，Teams 客户端必须有权访问 SBC 的公共 IP 地址，即使从内部网络也是如此。 如果不需要直接媒体，媒体可以通过传输中继流动。
当用户与 SBC 位于同一建筑物和/或网络时，建议使用此流–从媒体路径中删除 Microsoft 云组件。
信号始终通过 Microsoft 云流动。
下图显示了启用媒体旁路、客户端为内部且客户端可以访问 SBC (直接媒体) 的公共 IP 地址时的调用流：
路径的箭头和数值与 Microsoft Teams 调用流一致。
SIP 信号始终采用路径 4 和 4' (，具体取决于流量) 的方向。 媒体保持本地并采用路径 5b。
如果用户无权访问 SBC 的公共 IP 地址，则调用流
以下方案描述了如果用户无权访问 SBC 的公共 IP 地址，则描述调用流。
例如，假设用户是外部用户，并且租户管理员决定不向 Internet 中的每个人打开 SBC 的公共 IP 地址，而只向 Microsoft 云开放。 流量的内部组件可以通过 Teams 传输中继流动。 比如以下几种情况：
使用 Teams 传输中继。
对于媒体旁路，Microsoft 使用的传输中继版本要求在 Teams 传输中继和 SBC (之间打开端口 50 000 到 59 999，我们计划在将来迁移到需要 3478-3481 个端口) 的版本。
下图显示了当启用了媒体旁路、客户端位于外部且客户端无法访问会话边界控制器的公共 IP 地址时， (媒体由 Teams 传输中继) 中继时，调用流。
路径的箭头和数值与 Microsoft Teams 调用流一致。
媒体通过路径 3、3'、4 和 4'进行中继。
如果用户在网络外部并且有权访问 SBC 的公共 IP，则呼叫流
注意
这不是建议的配置，因为它不会利用 Teams 传输中继。 相反，你应该考虑之前的情况，即用户无权访问 SBC 的公共 IP 地址。
下图显示了启用媒体旁路、客户端位于外部且客户端可以访问 SBC 的公共 IP 地址 (直接媒体) 时的调用流。
路径的箭头和数值符合 Microsoft Teams 调用流 一文。
SIP 信号始终采用路径 3 和 3' (，具体取决于流量) 的方向。 使用路径 2 的媒体流。
媒体处理器和传输中继的使用
Microsoft 云中有两个组件可以位于媒体流量的路径中：媒体处理器和传输中继。
媒体处理器是一个面向公众的组件，用于处理非旁路情况下的媒体，并处理语音应用程序的媒体。
媒体处理器始终位于最终用户非旁路呼叫的路径中，但对于绕过的调用，媒体处理器从不在路径中。 媒体处理器始终位于所有语音应用程序的路径中，例如呼叫寄存、组织自动助理和呼叫队列。
传输中继用于连接到最近的传输服务，以发送实时流量。
传输中继可能位于或可能不在绕过呼叫的路径中（源自或发往最终用户），具体取决于用户所在的位置和网络配置方式。
下图显示了两个调用流- 一个启用了媒体旁路，另一个禁用了媒体旁路。
注意
此图仅说明了源自或发往最终用户的流量。
媒体控制器是 Azure 中的微服务，用于分配媒体处理器并创建会话描述协议 (SDP) 产品/服务。
SIP 代理是一个组件，用于将 Teams 中使用的 HTTP REST 信号转换为 SIP。
下表总结了媒体处理器和传输中继之间的差异。
| 媒体处理器 | 传输中继 | |
|---|---|---|
| 最终用户非旁路呼叫的媒体路径中 | 总是 | 如果客户端无法直接访问媒体处理器 |
| 针对最终用户的绕过呼叫的媒体路径中 | 从来 没有 | 如果客户端无法访问公共 IP 地址上的 SBC |
| 在语音应用程序的媒体路径中 | 总是 | 从来 没有 |
| 可以 (B2BUA) 进行转码* | 是 | 否，仅在终结点之间中继音频 |
IP 范围包括：
- 52.112.0.0/14 (IP 地址从 52.112.0.0 到 52.115.255.255)
- 52.120.0.0/14 (IP 地址从 52.120.0.0 到 52.123.255.255)
注意
本文档中介绍的 IP 范围特定于直接路由，可能与 Teams 客户端建议的 IP 范围不同。
* 转码说明：
媒体处理器是 B2BUA，这意味着它可以更改编解码器 (例如，将 SILK 从 Teams 客户端更改为 MP，以及 MP 和 SBC) 之间的 G.711。
传输中继不是 B2BUA，这意味着客户端和 SBC 之间永远不会更改编解码器，即使流量通过中继流动也是如此。
如果为媒体旁路配置了中继，则使用 Teams 媒体处理器
在以下情况下，Teams 媒体处理器始终插入媒体路径中：
- 呼叫从 1：1 升级到组呼叫
- 呼叫将转到联合 Teams 用户
- 呼叫转接或转接给Skype for Business用户
确保 SBC 有权访问媒体处理器和传输中继范围，如下所述。
SIP 信号：FQDN
对于 SIP 信号，FQDN 和防火墙要求与非绕过情况的要求相同。
直接路由在以下 Microsoft 365 或 Office 365 环境中提供：
- Microsoft 365 或 Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
详细了解Office 365和美国政府环境，例如 GCC、GCC High 和 DoD。
Microsoft 365、Office 365 和 Office 365 GCC 环境
直接路由的连接点为以下三个 FQDN：
必须 首先尝试 sip.pstnhub.microsoft.com 全局 FQDN。 当 SBC 发送解析此名称的请求时，Microsoft Azure DNS 服务器将返回一个 IP 地址，该地址指向分配给 SBC 的主 Azure 数据中心。 分配基于数据中心的性能指标和与 SBC 的地理邻近度。 返回的 IP 地址对应于主 FQDN。
sip2.pstnhub.microsoft.com – 辅助 FQDN – 在地理上映射到第二个优先区域。
sip3.pstnhub.microsoft.com - 第三级 FQDN - 在地理上映射到第三个优先区域。
必须放置这三个 FQDN 才能：
通过查询第一个 FQDN) ， (负载较低且最接近分配的 SBC 数据中心提供最佳体验。
当从 SBC 建立到遇到临时问题的数据中心的连接时，提供故障转移。 有关详细信息，请参阅下面的故障转移机制。
FQDN sip.pstnhub.microsoft.com、 sip2.pstnhub.microsoft.com 和 sip3.pstnhub.microsoft.com 将解析为以下子网中的 IP 地址：
- 52.112.0.0/14
- 52.120.0.0/14
需要在防火墙中为所有这些 IP 范围打开端口，以允许传入和传出地址的传入和传出流量以发出信号。
Office 365 GCC DoD 环境
直接路由的连接点为以下 FQDN：
sip.pstnhub.dod.teams.microsoft.us – 全局 FQDN。 由于 Office 365 DoD 环境仅存在于美国数据中心，因此没有二级和三级 FQDN。
FQDN sip.pstnhub.dod.teams.microsoft.us 将解析为以下子网中的 IP 地址：
- 52.127.64.0/21
需要在防火墙中为所有这些 IP 范围打开端口，以允许传入和传出地址的传入和传出流量以发出信号。 如果防火墙支持 DNS 名称，则 FQDN sip.pstnhub.dod.teams.microsoft.us 将解析为所有这些 IP 子网。
Office 365 GCC 高环境
直接路由的连接点为以下 FQDN：
sip.pstnhub.gov.teams.microsoft.us – 全局 FQDN。 由于 GCC High 环境仅存在于美国数据中心，因此没有二级和三级 FQDN。
FQDN sip.pstnhub.gov.teams.microsoft.us 将解析为以下子网中的 IP 地址：
- 52.127.88.0/21
需要在防火墙中为所有这些 IP 范围打开端口，以允许传入和传出地址的传入和传出流量以发出信号。 如果防火墙支持 DNS 名称，则 FQDN sip.pstnhub.gov.teams.microsoft.us 将解析为所有这些 IP 子网。
SIP 信令：端口
对于提供直接路由的所有Office 365环境，端口要求相同：
- Microsoft 365 或 Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
必须使用以下端口：
| 交通 | 从 | 到 | 源端口 | 目标端口 |
|---|---|---|---|---|
| SIP/TLS | SIP 代理 | Sbc | 1024 - 65535 | 在 SBC 上定义 |
| SIP/TLS | Sbc | SIP 代理 | 在 SBC 上定义 | 5061 |
媒体流量：IP 和端口范围
如果直接连接可用，则媒体流量在 SBC 和 Teams 客户端之间流动;如果客户端无法使用公共 IP 地址访问 SBC，则通过 Teams 传输中继。
Teams 客户端与 SBC) 之间的直接媒体流量 (要求
客户端必须有权访问指定的端口 (请参阅 SBC 公共 IP 地址上的表) 。
注意
如果客户端位于内部网络中，则媒体会流向 SBC 的公共 IP 地址。 可以在 NAT 设备上配置头发固定，以便流量永远不会离开企业网络设备。
| 交通 | 从 | 到 | 源端口 | 目标端口 |
|---|---|---|---|---|
| UDP/SRTP | 客户端 | Sbc | 50000-50019 | 在 SBC 上定义 |
| UDP/SRTP | Sbc | 客户端 | 在 SBC 上定义 | 50000-50019 |
注意
如果网络设备可转换客户端的源端口，请确保在网络设备和 SBC 之间打开已转换的端口。
使用传输中继的要求
对于非旁路情况，传输中继的范围与媒体处理器 (相同，) ：
Microsoft 365、Office 365 和 Office 365 GCC 环境
- 52.112.0.0 /14 (IP 地址从 52.112.0.1 到 52.115.255.254)
Office 365 GCC DoD 环境
- 52.127.64.0/21
Office 365 GCC 高环境
- 52.127.88.0/21
下表显示了适用于所有环境的 Teams 传输中继 (端口范围) ：
| 交通 | 从 | 到 | 源端口 | 目标端口 |
|---|---|---|---|---|
| UDP/SRTP | 传输中继 | Sbc | 50000-59999 | 在 SBC 上定义 |
| UDP/SRTP | Sbc | 传输中继 | 在 SBC 上定义 | 50000–59999, 3478-3481 |
注意
Microsoft 建议 SBC 上每个并发调用至少两个端口。 由于 Microsoft 有两个版本的传输中继，因此需要满足以下条件：
v4，仅适用于端口范围 50000 到 59999
v6，适用于端口范围 3478 到 3481
使用媒体处理器的要求
媒体处理器始终位于语音应用程序和 Web 客户端的媒体路径中， (例如 Microsoft Edge 中的 Teams 客户端或 Google Chrome) 。 这些要求与非旁路配置的要求相同。
媒体流量的 IP 范围是：
Office 365和Office 365 GCC 环境
- 52.112.0.0 /14 (IP 地址从 52.112.0.1 到 52.115.255.254)
Office 365 GCC DoD 环境
- 52.127.64.0/21
Office 365 GCC 高环境
- 52.127.88.0/21
下表显示了适用于所有) 环境的媒体处理器 (端口范围：
| 交通 | 从 | 到 | 源端口 | 目标端口 |
|---|---|---|---|---|
| UDP/SRTP | 媒体处理器 | Sbc | 3478-3481 和 49152–53247 | 在 SBC 上定义 |
| UDP/SRTP | Sbc | 媒体处理器 | 在 SBC 上定义 | 3478-3481 和 49152–53247 |
为媒体旁路和非媒体旁路配置单独的中继
如果要从非媒体旁路迁移到媒体旁路，并希望在将所有使用情况迁移到媒体旁路之前确认功能，则可以创建单独的中继和单独的联机语音路由策略，以路由到媒体旁路中继并分配给特定用户。
高级配置步骤：
标识要测试媒体旁路的用户。
创建两个具有不同 FQDN 的单独中继：一个已启用媒体旁路;另一个不是。
两个中继指向同一 SBC。 TLS SIP 信号的端口必须不同。 媒体的端口必须相同。
创建新的联机语音路由策略，并将媒体旁路中继分配给与此策略的 PSTN 用法关联的相应路由。
将新的联机语音路由策略分配给已确定用于测试媒体旁路的用户。
以下示例演示了此逻辑。
| 用户集 | 用户数 | 在 OVRP 中分配的中继 FQDN | 已启用媒体旁路 |
|---|---|---|---|
| 具有非媒体旁路中继的用户 | 980 | sbc1.contoso.com:5061 | false |
| 具有媒体旁路中继的用户 | 20 | sbc2.contoso.com:5060 | true |
两个中继可以指向具有相同公共 IP 地址的同一 SBC。 SBC 上的 TLS 信令端口必须不同，如下图所示。 请注意，需要确保证书支持这两个中继。 在 SAN 中，需要有两个名称 (sbc1.contoso.com 和 sbc2.contoso.com) 或具有通配符证书。
有关如何在同一 SBC 上配置两个中继的信息，请参阅 SBC 供应商提供的文档：
媒体旁路支持的客户端终结点
所有独立 Teams 桌面客户端、Android 和 iOS 客户端以及Teams 电话设备都支持媒体旁路。
对于不支持媒体旁路的所有其他终结点，我们将调用转换为非旁路，即使它作为旁路呼叫启动也是如此。 此转换会自动进行，不需要管理员执行任何操作。 这包括Skype for Business 3PIP 电话，以及支持直接路由呼叫的 Teams Web 客户端， (基于 WebRTC 的客户端运行在 Microsoft Edge、Google Chrome、Mozilla Firefox) 。
另请参阅
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈