在 Microsoft Teams 中使用 CQD 管理通话和会议质量
本文将帮助你（Teams 管理员或支持人员和支持工程师）使用 Microsoft Teams 通话质量仪表板 (CQD) 开发监视和维护组织的通话和会议质量的过程。 我们的指南强调音频质量方案，因为你为改进音频体验所做的任何网络改进都将转化为视频和共享方面的改进。
本指南的关键是两个 特选 CQD 模板 - 建议先下载它们，然后再完成本文中的指南。
本文假定你已 设置 CQD。
要监视和维护的类别
在 Teams 中推出会议和语音后，需要计划进行持续监视和维护。 这样做可确保 Teams 始终以最佳方式运行。 此计划应包括下面列出的关键领域。 还应为质量指标建立目标，并制定计划，以便在问题发生时对其进行故障排除和隔离。
| 类别 | 描述 |
|---|---|
| 通话质量 |
按组织内部 (（例如 VPN、WiFi、有线) 或外部呼叫）细分指标 通过生成或网络细分指标 VPN 呼叫 使用 TCP、UDP 或代理的调用 |
| 呼叫可靠性 | 识别并修正任何网络或防火墙问题 深入了解呼叫设置和丢弃失败的百分比 了解大多数呼叫设置和丢弃失败发生在何处 |
| 用户调查 |
使用“评分我的呼叫”数据了解用户的实际体验 不良体验发生在何处？ 将不良体验与通话质量、可靠性和设备相关联 |
| Devices | 了解最常用的麦克风和扬声器及其对通话质量的影响 是否定期修补支持的音频、视频、USB 和 WiFi 驱动程序？ |
| 客户端 |
了解正在使用的客户端类型和版本及其对通话质量和可靠性的影响 |
通过不断评估和修正本文中所述的区域，可以降低它们对用户产生负面影响的可能性。 大多数用户问题可分为以下类别：
- 防火墙或代理配置不完整
- Wi-Fi 覆盖范围较小
- 带宽不足
- VPN
- 客户端版本和驱动程序不一致或过时
- 未优化或内置音频设备
- 子网或网络设备存在问题
在部署 Teams 或 Skype for Business Online 之前，通过适当的规划和设计，可以减少维护高质量体验所需的工作量。
本文重点介绍如何使用通话质量仪表板 (CQD) Online 作为报告和调查每个区域的主要工具，并特别强调音频以最大程度地提高采用率和影响。 为改善音频体验而对网络所做的任何改进也将直接转化为视频和桌面共享方面的改进。
为了加快评估速度，我们提供了 两个特选 CQD 模板 ：一个用于管理所有网络，另一个仅针对托管 (内部) 网络进行筛选。 尽管“所有网络”模板报表配置为显示生成和网络信息，但在你努力收集和上传建筑物信息时，仍可使用它们。 通过将生成信息上传到 CQD，服务可以通过添加自定义生成、网络和位置信息来增强报告，同时区分内部子网和外部子网。 有关详细信息，请阅读 生成映射。
目标受众
本文供合作伙伴和客户利益干系人使用，这些角色包括协作主管/架构师、顾问、变更管理/采用专家、支持/技术支持主管、网络主管、桌面主管和 IT 管理员。
什么是质量？
在此上下文中，质量是服务指标和用户体验的组合。
服务指标
服务指标由基于客户端的特定指标组成。 在每次调用期间，客户端收集调用的遥测数据，并在每次调用结束时提交一个报告，稍后可在 CQD 或 每用户呼叫分析中访问。 这些指标包括 (但不限于) ：
- 传入和传出) 差Stream (
- 设置失败率
- 删除失败率
低流速率
PSR) (较差的流速率表示组织质量较差的流的总体百分比。 此指标旨在突出显示组织可以集中精力对降低此值和改善用户体验产生最大影响的领域，这就是为什么 托管网络 在查看 PSR 时是主要关注点的原因。 外部用户也很重要，但调查因组织而异。 请考虑为外部用户提供最佳做法，并独立于整个组织调查外部调用。
CQD 中的实际度量值因工作负荷而异，但出于本文的目的，我们主要关注 音频差百分比 度量。 PSR 由下表中所述的五个网络指标平均值组成。 若要将流分类为差，只有一个指标需要超过定义的阈值。 CQD 提供“不良原因...”测量以更好地了解是什么条件导致流被分类为差。 若要了解详细信息，请阅读 CQD 中的Stream分类。
注意
CQD 提供“由于...”测量以更好地了解是什么条件导致流被分类为差。
音频质量不佳指标
| 指标平均值 | 说明 | 用户体验 |
|---|---|---|
| 抖动 >30 毫秒 | 这是连续数据包之间的平均延迟变化。 团队和Skype for Business可以通过缓冲来适应某些级别的抖动。 只有当抖动超过缓冲时，参与者才会注意到抖动的影响。 | 以不同速度到达的数据包会导致扬声器的声音听起来机器人。 |
| 数据包丢失率 >10% 或 0.1 | 这通常定义为丢失的数据包的百分比。 数据包丢失直接影响音频质量-从几乎不会影响到导致音频完全切断的背靠背突发丢失的小型单个丢失数据包。 | 丢弃的数据包未到达其预期目标会导致媒体出现间隙，导致音节和单词丢失，以及视频和共享断断续续。 |
| 往返时间 >500 毫秒 | 这是获取从点 A 到点 B 并返回到点 A 的 IP 数据包所需的时间。此网络传播延迟与两点之间的物理距离和光速有关，包括网络路径中各种设备产生的额外开销。 | 数据包到达目的地的时间过长会导致对讲机效果。 |
为什么我们更喜欢使用流而不是调用？
流让我们知道呼叫的哪个特定部分很差 - 传出或传入。 查看不良呼叫的呼叫分析时，请确定错误呼叫是由于呼叫者的流 (出站) 还是被调用方的流 (入站) 。 确定哪个流会影响通话质量对于会议来说更为重要。 如果你只查看通话数据，你将看到一个人参加了多少次会议，但你不会看到哪些人是活跃的演讲者，执行最多的屏幕共享。
通话数据提供使用情况指标，但不一定会导致通话质量不佳的根本原因。 通过查看流方向，可以识别各种因素，例如不在托管网络上的呼叫、来自非员工 (的呼叫，例如供应商或其他网络上) 的人。 在这些情况下，如果对方的网络连接不佳，则整个呼叫将被标记为差。 无法对外部因素执行任何操作，因此此数据无济于事。
Stream方向还可以帮助你识别有问题的设备或客户端。
例如，如果设备预算有限，并且希望仅为大量音频用户提供设备，请使用音频使用情况报告 (VoIP) 并筛选出站流和会议。 寻找使用内置麦克风说话的高音量音频用户 - 这些用户可能与通话质量较差 (相关，你可能希望为这些人提供音频设备) 。 为了更加清晰，可以筛选数据包利用率，以便将目标定位到特别高音量的音频用户。
另一个示例涉及屏幕共享。 如果客户正在使用旧的 Teams 客户端，屏幕共享性能可能会受到影响。 可以通过为执行大量屏幕共享的用户优先进行客户端升级来解决此问题。
通过确定流的哪个方向导致通话质量不佳，可以确定是否遇到 QoS 或带宽相关问题。 如果尚未完全实现 QoS，或者仅在客户端上标记数据包，而不在入站流中标记数据包，则可能会看到较差的呼叫质量。 通过查看流方向，可以更精细地了解特定方向的数据包丢失、延迟或抖动。
- 例如，假设用户在有线连接时抱怨机器人音频 (抖动) 。 通过查看流和方向，可以确定问题是否发生在入站流上，仅针对一组特定的子网。 将此信息提供给网络团队后，他们可以将其跟踪到未绕过媒体流量的错误配置 WAN 加速器。 网络团队重新配置 WAN 加速器后，抖动会消失，通话质量会提高。
设置失败率
设置失败率（也称为 CQD 中的 总呼叫设置失败百分比 度量值）是在调用开始时无法在终结点之间建立媒体路径的流数。
这表示无法建立的任何媒体流。 鉴于此问题对用户体验的影响严重性，目标是将此值尽可能减少到接近零。 此指标的高值在防火墙规则不完整的新部署中比成熟的部署更常见，但定期watch仍然很重要。
此指标的计算方法是将未能设置的流总数除以提交成功呼叫详细信息记录的流总数 (CDR) ：
- 设置失败率 = 总调用设置失败Stream计数/可用 CDR Stream计数总数
删除失败率
下降失败率（也称为 CQD 中的 总呼叫丢弃失败百分比 度量值）是媒体路径未正常终止的成功建立流的百分比。
这表示意外终止的任何媒体流。 尽管其影响不如无法设置的流严重，但它仍会对用户体验产生负面影响。 突然和频繁的媒体下降不仅会对用户体验产生严重影响，还会导致用户需要重新连接，导致工作效率下降， (不提及挫折) 。
该指标的计算方法是：将丢弃的流总数除以成功设置的流总数：
- 下降失败率 = 总呼叫丢弃Stream计数/总呼叫设置成功Stream计数
定义目标指标
本部分讨论用于评估服务运行状况的一些核心服务指标。 通过不断评估和推动努力使这些指标低于其定义的目标，你将帮助确保你的用户体验一致、可靠的通话质量。 首先，使用下表中建议的目标。 根据需要调整目标以满足业务目标。
| 网络类型 | 质量目标 | 可靠性目标 | ||
|---|---|---|---|---|
| 音频差Stream率 | 设置失败率 | 删除失败率 | ||
| All | 内部 | 2.0% | 0.5% | 2.0% |
| 整体 | 3.0% | 1.0% | 3.0% | |
| 会议 | 内部 | 2.0% | 0.5% | 2.0% |
| 有线内部 | 1.0% | 0.5% | 1.0% | |
| Wi-Fi 5 GHz 内部 | 1.0% | 0.5% | 1.0% | |
| Wi-Fi 2.4 GHz 内部 | 2.0% | 0.5% | 2.0% | |
| 整体 | 2.0% | 0.5% | 3.0% | |
| P2p | 内部 | 2.0% | 0.5% | 2.0% |
| 有线/Wi-Fi 5 GHz 内部 | 1.0% | 0.5% | 1.0% | |
| 有线/Wi-Fi 5 GHz 整体 | 2.0% | 1.0% | 1.0% | |
| 整体 | 2.0% | 1.0% | 3.0% | |
用户体验
分析用户体验比科学更艺术，因为此处收集的指标并不总是意味着网络或服务存在问题，而只是表示用户感知到问题。 CQD 包括一个内置调查机制（对我的呼叫 (RMC) 进行评分），以帮助衡量整体用户体验。 RMC 将让你从用户的角度深入了解以下问题：
- 我知道如何使用该解决方案吗？
- 该解决方案是否易于使用且直观，是否支持我的日常通信需求？
- 该解决方案是否帮助我完成工作？
- 我对解决方案的总体看法是什么？
- 无论身在何处，我都可以在任何时间点使用该解决方案吗？
- 是否可以设置和维护呼叫？
为我的呼叫评分
对我的呼叫进行评分 (RMC) 内置于 Teams 和Skype for Business中。 在每 10 次调用一次（即 10%）后，它会自动弹出。 此简短调查要求用户对呼叫进行评分，并提供一些上下文来说明通话质量可能很差的原因。 一两个评级被认为是差的，三到四个是好的，五个是优秀的。 虽然它有点滞后的指标，但这是一个有用的指标，用于发现服务指标可能错过的问题。
注意
人为因素：用户在通话质量良好时经常忽略调查，并在通话质量差时填写调查。 因此，即使服务指标良好，RMC 报告也可能偏向不良端。
可以使用 CQD 报告 RMC 用户响应，并且示例报表包含在 CQD 模板中。 但是，本文不会详细讨论它们。
客户端和设备就绪情况
你需要可靠的客户端和设备策略来帮助确保用户拥有一致且积极的用户体验。 一些关键原则驱动着每个就绪策略。
客户端就绪情况
使 Teams 客户端保持最新状态可确保用户始终获得最佳体验。 Microsoft 会向 Teams 客户端 发布频繁更新， (更新会在后台自行安装，除非你已关闭此功能， 我们不建议) 。 还必须记住修补网络、视频、USB 和音频驱动程序，因为它们经常被忽视，并可能影响通话和会议质量。 请考虑将网络、Wi-Fi、视频、USB 和音频驱动程序添加到当前的修补程序管理过程。
设备就绪情况
任何一种策略都比设备就绪策略对用户体验的影响更大。 例如，依赖笔记本电脑扬声器和麦克风的用户将在通话和会议中遇到大量背景噪音。 Teams 设计用于几乎任何设备，但如果遇到与设备相关的问题，检查 Phone for Teams。
质量类别
实施一组质量管理做法 - 这为你提供了良好的通话和会议质量的最佳机会。 良好的质量管理计划适用于以下类别：
网络：音频质量侧重于差Stream比率 (PSR) 指标、TCP 使用情况、有线和无线子网，以及识别 HTTP 代理和 VPN 的使用
端点： 音频设备和最新客户端
服务管理： 此类别包括两个部分：
首先，Microsoft 负责管理和维护 Teams 和Skype for Business联机服务。
第二个是组织管理的任务，以确保对服务的可靠访问，例如，在将基础结构添加到服务时更新生成信息和维护新Office 365 IP 地址的防火墙。
查看以下建议的任务列表，以保持质量。 应定期执行这些任务，例如每周执行一次。
服务管理任务
这些任务包括确保有足够的带宽访问服务而不使 Internet 链接饱和，验证服务质量 (QoS) 是否已在所有托管网络区域到位，以及保持防火墙上的Office 365 IP 范围。
网络任务
网络任务分为两类：可靠性和质量。 可靠性侧重于衡量用户成功拨打电话并保持连接的能力。 质量侧重于用户客户端在调用期间和结束之后发送到 Teams 和 Skype for Business Online 的聚合遥测数据。
鉴于可靠性对用户体验的严重影响，建议在深入了解质量之前评估和调查可靠性指标。
终结点任务
此类别中的main任务消除了常规 Teams 客户端更新的任何障碍。 默认情况下，除非你关闭此设置，否则 Teams 会定期 (自动更新，我们不建议) 。
你还应监视设备，并在发现与设备相关的问题时提供更新。
使用 CQD 管理通话质量
设置 CQD 后，即可开始使用它来管理组织的通话和会议质量。
Teams 性能的大多数问题分为以下类别：
- 防火墙或代理配置不完整
- Wi-Fi 覆盖范围较小
- 带宽不足
- VPN
- 客户端版本和驱动程序不一致或过时
- 未优化或内置音频设备
- 子网或网络设备存在问题
如果你在推出 Teams 之前花时间来评估这些领域并修正任何缺陷，你将减少为所有用户维护高质量 Teams 体验所需的工作量。 有关在为 Teams 推出做准备时评估网络方面的帮助，请阅读 Teams 顾问 和 为 Teams 准备网络。
使用 CQD 的期望
使用通话质量仪表板 (CQD) 深入了解使用 Teams 和Skype for Business服务进行的通话质量。 CQD 旨在帮助 Teams 和Skype for Business管理员和网络工程师优化网络，并密切关注质量、可靠性和用户体验。 CQD 查看整个组织的聚合遥测，其中整体模式可能变得明显;这使你可以进行明智的评估和计划修正。 CQD 提供指标报告，用于深入了解整体质量、可靠性和用户体验。
CQD 虽然可用于分析趋势和子网，但并不总是提供给定方案的特定原因。 请务必了解这一点，并在使用 CQD 时设置正确的预期：
- CQD 不会为每个方案提供根本原因
- CQD 将根据趋势呼吁区域进行进一步调查
CQD 报告概述
使用屏幕顶部的下拉菜单打开报表。 有关每个报表中提供的数据的列表，请阅读 CQD 报表中可用的数据。
2020 年 1 月新增功能： 下载适用于 CQD 的 Power BI 查询模板。 可用于分析和报告 CQD 数据的可自定义 Power BI 模板。
Teams 与 Skype for Business
CQD 可以在 Teams 和 Skype for Business 上报告。 但是，有时你可能希望开发报表来查看与Skype for Business分开的 Teams 遥测。
摘要报告
若要修改摘要报表页以仅查看 Teams 或Skype for Business，请从屏幕顶部选择“产品筛选器”下拉菜单，然后选择所需的产品。
详细报告
若要筛选所有详细报表，请在浏览器栏中将以下内容追加到 URL 的末尾：
/filter/[AllStreams].[Is Teams]|[FALSE]
例子：
https://cqd.teams.microsoft.com/cqd/#/1234567/2018-5/filter/[AllStreams].[Is Teams]|[FALSE]
有关 URL 筛选器的详细信息，请阅读本节后面的 筛选报告 。
若要筛选单个详细报表，请将筛选器 Is Teams 添加到报表，并将其设置为 True 或 False。
托管网络与非托管网络
默认情况下，CQD 中的所有终结点都分类为外部终结点。 引入生成文件后，我们可以开始查看托管终结点数据。 如前所述，CQD 中的网络定义为：
- 托管网络（通常称为内部网络或内部网络）可以受到组织的影响和控制。 这包括内部 LAN、远程 WAN 和 VPN。
- 非托管网络（通常称为外部网络或外部网络）不能受到组织的影响或控制。 非托管网络的一个示例是酒店或机场网络。
维度、度量值和筛选器
格式正确的 CQD 查询包含以下三个参数：
维 度： 我想如何透视数据。
措施： 我想报告的内容。
滤波器： 如何减少查询返回的数据集。
另一种方法是 维度 是分组函数， 度量值 是我感兴趣的数据， 筛选器 是我想如何将结果缩小到与查询相关的结果。
格式正确的查询的一个示例是，按子网 [维度] 为 Building 6 [Filter] 显示差流 [度量值]。 有关详细信息，请参阅 CQD 中可用的维度和度量值。
第一个与第二个
CQD 中的许多维度和度量值都分类为第一个或第二个。 CQD 不使用调用方/被调用方字段-这些字段已重命名 为第一 和第 二 个，因为调用方和被调用方之间有干预步骤。 以下逻辑确定首先标记为涉及的终结点：
如果 流或呼叫中涉及服务器，首先将始终是服务器终结点 (会议服务器、中介服务器等) 。
第二 个将始终是客户端终结点，除非流位于两个服务器终结点之间。
如果两个终结点类型相同，则首先选择哪个终结点基于用户代理类别的内部排序。 这样可以确保排序的一致性。
有关在两者相同时确定第一个或第二个终结点的详细信息，请参阅 CQD 中可用的维度和度量值。
Stream与呼叫
你需要了解调用和流之间的差异，以正确选择将在 CQD 中查看的维度或度量值。 尽管 CQD 的主要重点是流，但基于呼叫的度量也可用。
Stream：流仅存在于两个终结点之间。 每个方向只有一个流，通信需要两个流。 流可用于调查建筑物、网络或子网。 在某些情况下，呼叫和流都用于度量名称 (例如呼叫设置Stream或呼叫丢弃Stream) 。 这些仍被归类为流。
叫：调用是来自所有参与者的所有流的分组。 调用至少包含两个流。 单个调用将至少有两个终结点，每个终结点至少有一个流。
有关维度或度量值是引用调用还是流的其他指导，请参阅 CQD 中可用的维度和度量值
好、差和未分类的调用
通话分为“良好”、“差”或“未分类”。 让我们花点时间更详细地讨论每一个。
好或差： 好调用或差调用包括一个调用，该调用包含一组完整的服务指标，服务生成并接收了完整的 QoE 报告。 本文前面介绍了确定流是好还是差。
未分类： 未分类流不包含完整的服务指标集。 这些可以是短时间调用（通常小于 60 秒），其中无法计算平均值，并且未生成 QoE 报告。 调用未分类的最常见原因是数据包利用率很少或根本没有。 例如，通过静音加入会议且从不说话的参与者。 参与者正在接收媒体，但未传输媒体。 如果不传输媒体，CQD 将无法使用任何指标对终结点的出站媒体流进行分类。
若要了解详细信息，请阅读 CQD 中的Stream分类。
常见子网
公共子网是酒店、家庭网络、热点和类似区域使用的特定专用子网。 由于这些子网的广泛使用，因此难以会审。 如果组织使用这些常见子网之一，建议将网络移到另一个子网。 这将简化 CQD 中的报告。 如果已指出，“所有网络”模板中的报表已配置为排除这些子网，以消除它们作为质量不佳的来源。 通用子网定义如下：其影响因组织而异。
- 10.0.0.0/24
- 192.168.0.0/24
- 192.168.1.0/24
- 192.168.2.0/24
- 172.20.10.0/24
- 192.168.43.0/24
调查使用公共子网的托管网络时，需要使用“第二个自反本地 IP”维度对子网进行分组。 此维度包含终结点的公共 IP 地址。
可靠性调查
提高质量的第一步是评估整个组织的可靠性状态。 由于可靠性对于积极的用户体验至关重要，因此我们首先从两个衡量可靠性的组件开始：
安装失败： 无法建立调用。
删除失败： 呼叫已建立并意外终止。
在本部分中，我们将介绍调查这两个方面的方法。
注意
本文并未涵盖模板中包含的所有报表。 但是，下面介绍的调查方法仍然适用。 有关详细信息，请参阅各个报表说明。
安装失败
首先优先考虑修正此领域的设置失败，因为这些故障会对用户体验产生重大负面影响。
通过评估组织的总体安装失败百分比开始调查，然后通过构建或网络根据最高百分比确定调查区域的优先级。
设置失败趋势分析
此报表显示流的总数、流设置失败次数和流设置失败率。 指向任一列以显示其单个值。
分析
使用此报告，可以回答以下问题并确定下一步行动方案：
当前月份的总呼叫设置失败百分比是多少？
总呼叫设置失败百分比是否低于或高于定义的目标指标？
故障趋势是比上个月更糟还是更好？
故障趋势是增加、稳定还是减少？
不管你对这些问题的答案如何，请花时间使用配套子报告来进一步调查，以查找可能需要修正的任何单个建筑物或子网。 尽管总体故障率可能低于目标指标，但一个或多个建筑物或网络的故障率可能高于目标指标，需要进行调查。
设置失败调查
此摘要报告用于发现和隔离可能需要修正的任何建筑物或网络。
注意
请务必将“月份年”报表筛选器调整为当前月份。 选择 “编辑”，然后调整“ 月份年份 ”报表筛选器以保存新的默认月份。
修复
将第一次修正工作集中在故障量最大的建筑物或子网上。 这将最大限度地影响用户体验，并有助于快速降低组织呼叫设置失败的速率。 下表列出了 CQD 报告的安装失败的两个原因。
| 呼叫设置失败原因 | 典型原因 |
|---|---|
| 缺少 FW 深层数据包检查豁免规则 | 指示路径上的网络设备由于深度数据包检查规则而阻止建立媒体路径。 这可能是由于未正确配置防火墙规则。 在此方案中，TCP 握手成功，但 SSL 握手失败。 |
| 缺少 FW IP 块异常规则 | 指示路径上的网络设备阻止建立到 Microsoft 365 或Office 365网络的媒体路径。 这可能是由于代理或防火墙规则未正确配置为允许访问用于 Teams 的 IP 地址和端口，并Skype for Business流量。 |
开始修正时，可以将工作重点放在特定的建筑物或子网上。 如上表所示，这些问题是由防火墙或代理配置引起的。 查看下表中的选项，了解修正操作。
| 修复 | 指引 |
|---|---|
| 配置防火墙 | 请与网络团队协作，并针对Office 365 IP 地址列表验证防火墙配置。 验证 媒体子网 和端口是否包含在防火墙规则中。 验证是否在防火墙中打开 了必要的端口 。 应优先考虑 UDP，因为 TCP 被视为基于音频、视频和视频的屏幕共享的故障回复协议，其使用会影响通话质量。 旧版 RDP 应用程序共享仅使用 TCP。 |
删除失败
与安装失败代码不同，CQD 没有放置失败代码来指示发生放置失败的原因，这使得很难找出特定的根本原因。 若要更好地对删除失败进行会审，请使用推断方法。 通过修正媒体、修补客户端和驱动程序以及推动 Teams 和Skype for Business认证设备的使用，可以预期下降失败会被拒绝。
下降失败趋势分析
此报表显示音频流的总数、总丢弃失败次数和丢弃失败率。 指向任一列以显示其值。
分析
使用此类型的报表，可以回答以下问题：
- 当前的下降失败率是多少？
- 下降失败率是否低于定义的目标指标？
- 故障趋势是比上个月更糟还是更好？
- 故障趋势是增加、稳定还是减少？
无论上述问题的答案如何，请花时间使用子报告进行调查，以查找任何可能需要修正的建筑物或网络。 尽管总体下降故障率可能低于目标指标，但一个或多个建筑物或网络的下降故障率可能高于目标指标，需要调查。
删除失败调查
此处报告的失败表明呼叫意外中断，并导致负面的用户体验。 与趋势报告不同，这些报告提供了对需要进一步调查的特定子网的其他见解。
修复
使用包含的表报告，可以隔离网络中下降率高于已定义的目标指标的问题区域。 将第一次修正工作集中在总流计数最高的建筑物或子网上，以产生最大的影响。
呼叫中断的常见原因：
- 网络或 Internet 出口预配不足
- 在受约束的网络上未配置 QoS
- 较旧的客户端版本
- 用户行为
发现问题区域后，可以使用 每用户呼叫分析 进一步查看该生成中的用户的特定问题。 调用分析包含其他 EUII 数据，可用于进一步隔离删除失败的潜在原因。
无论下一步如何，最好通知支持人员已发现特定建筑物或子网的问题。 这使支持人员可以快速响应来电并更有效地对用户进行会审。 然后，可以向工程团队报告已标记的用户，以便进一步调查。
下表列出了管理和修正删除失败的一些常用方法。
| 修复 | 指引 |
|---|---|
| 网络/Internet | 拥塞：与网络团队协作，监视特定建筑物/子网的带宽，以确认存在过度使用的问题。 如果确实确认存在网络拥塞，请考虑增加该生成或应用 QoS 的带宽。 使用包含的质量差Stream摘要报告来查看问题子网中与抖动、延迟和数据包丢失相关的问题，因为这些问题通常位于丢弃的流之前。 QoS：如果增加带宽不切实际或成本高昂，请考虑实现 QoS。 此工具在管理拥堵流量方面非常有效，可以保证托管网络上的媒体数据包优先于非媒体流量。 或者，如果没有明确证据表明带宽是罪魁祸首，请考虑以下解决方案： 执行网络就绪情况评估：网络评估提供有关预期带宽使用情况、如何处理带宽和网络更改以及 Teams 和Skype for Business的建议网络做法的详细信息。 使用上表作为源，你将获得一个建筑物或子网列表，这些建筑物或子网是评估的优秀候选项。 |
| 客户端仅 (Skype for Business Online) | 某些较旧的Skype for Business客户端已知且记录了媒体可靠性问题。 查看来自多个受影响用户的呼叫分析报告，或在 CQD 中创建自定义客户端版本表报表，该报表筛选为具有总呼叫中断失败百分比度量的特定建筑物或子网。 此信息将帮助你了解该特定生成中的调用下降与客户端的特定版本之间是否存在关系。 |
| Devices | 如果设备是通话质量问题的罪魁祸首，请考虑更新有问题的设备。 若要了解详细信息，请阅读 Teams 电话 。 |
| 用户行为 | 如果确定网络、设备或客户端都不是问题，请考虑制定用户采用策略来指导用户如何以最佳方式加入和退出会议。 更智能的 Teams 和Skype for Business用户将为会议中的所有参与者带来更好的用户体验。 例如，通过关闭盖子) 而不退出会议，将笔记本电脑置于睡眠 (的用户将被归类为意外的呼叫中断。 |
质量调查
评估整个组织的音频质量状态的下一步是调查不良Stream速率 (PSR) 、TCP 和代理使用情况。 请务必记住，CQD 数据不会提供特定的根本原因，而是为你提供了可能的问题区域，以便开始与相应团队进行协作对话，以开展补救活动。
注意
本文未涵盖模板中包含的所有报表;但是，下面介绍的调查方法仍适用于这些报告。 有关详细信息，请参阅各个报表说明。
质量
PSR 百分比用于指示组织是否满足给定重点领域的定义指标目标。 请务必注意，即使高级百分比在定义的目标内，单个子网或建筑物也可能无法满足定义的目标，因此需要进一步调查。 例如，如果 4 月份的总体音频 PSR 百分比为 2%，这符合示例目标，则单个建筑物和子网的体验可能仍然不佳，具体取决于该 2% 的总体分布情况。
若要评估不良流的百分比，请使用质量报告。 提供了各种质量报告，用于查看整体、会议、两方、PSTN 呼叫、VPN 和会议室的指标。 提供每月、每周和每日报告来帮助完成此过程。 每周和每日报告仅限于托管网络模板，以提高其有效性并减少干扰。
质量趋势分析
趋势报表显示一段时间内的质量信息，用于帮助识别和了解每个相关领域的质量趋势。 如上所述，模板中包含用于调查质量的报告树：会议、双方、PSTN 呼叫、VPN 和会议室。 为了分析质量，调查过程是相同的。 但是，我们建议先从会议开始，因为会议质量的任何改进也会对所有其他方面产生积极影响。
注意
调查两方、PSTN 呼叫和会议室类似于调查会议。 重点是隔离质量最差的建筑物或子网，并确定质量不佳的原因。
重要
使用第二个 VPN 维度筛选基于 VPN 的报表。 此维度要求将 VPN 网络适配器正确注册为远程访问适配器。 VPN 供应商不能可靠地使用此标志，并且你的里程将因组织中部署的 VPN 供应商而异。 根据需要使用建筑物或网络名称修改 VPN 报告。
调查
使用这些报告，可以回答以下问题：
- 当前月份的总 PSR 是多少？
- PSR 是否低于定义的目标指标？
- PSR 是比前一个月差还是更好？
- PSR 趋势是增加、稳定还是下降？
无论上述问题的答案如何，请花时间使用子报告进行调查，以查找可能需要调查的任何建筑物或子网。 尽管总体 PSR 可能低于目标指标，但通常一个或多个建筑物或网络的 PSR 高于指标，需要修正。
质量调查
通过质量摘要报告，可以更深入地了解导致流被分类为差的原因，并帮助隔离托管网络中的问题区域。
尽管报表使用的维度可能略有不同，但每个报表将包括总流数、总差流数、PSR 以及由于原因导致的质量差的度量值。 已针对每个感兴趣的领域创建报告：会议、两方、PSTN 呼叫、VPN 和会议室。 托管网络模板包括其他报表，以利用通过生成文件上传的位置信息。
注意
由于常用子网的广泛使用，因此难以会审。 已向“所有网络”模板添加了显示客户端公共 IP (Second Reflexive Local IP) 的单独报表，以帮助修正使用公共网络的办公室。
修复
将修正工作重点放在具有最大流量的建筑物或子网上，因为这将最大程度地影响并有助于快速改善用户体验。 使用 RTT) 测量 (抖动、数据包丢失和往返时间来了解导致质量不佳的原因 () 可能存在多个问题：
- 抖动：媒体数据包以不同的速度到达，这会导致扬声器发出机器人声音。
- 数据包丢失：丢弃媒体数据包，这会产生缺少单词或音节的效果。
- RTT：媒体数据包需要很长时间才能到达目标，这会产生对讲机效果。
若要帮助调查质量问题，请使用 每用户呼叫分析。 使用呼叫分析，可以查看特定会议或用户的呼叫报告。 此报告将包含 EUII/PII 数据，在查找失败原因时非常有用。 在知道哪个建筑物受到影响后，跟踪该建筑物中的用户应该非常简单。
请不要忘记让支持人员知道这些网络遇到了质量问题，以便它们可以快速会审和响应来电。
| 修复 | 指引 |
|---|---|
| 网络 | 拥塞：过度使用或预配不足的网络可能会导致媒体质量问题。 请与网络团队协作，确定从用户到 Internet 出口点的网络连接是否具有足够的带宽来支持媒体。 执行网络就绪情况评估：网络评估提供有关预期带宽使用情况、如何处理带宽和网络更改以及 Teams 和Skype for Business的建议网络做法的详细信息。 使用上表作为源，你将获得一个建筑物或子网列表，这些建筑物或子网是评估的优秀候选项。 |
| 服务质量 (QoS) | QoS 是一种经过验证的工具，可帮助在拥挤的网络上确定数据包的优先级，以确保它们完好无损且按时到达目标。 请考虑在整个组织中实施 QoS，以最大程度地提高带宽受限的用户体验质量。 QoS 将帮助解决通常与高级别数据包丢失以及抖动和往返时间相关的问题。 |
| Wi-Fi | Wi-Fi 可能会对通话质量产生重大影响。 Wi-Fi 部署通常不考虑 VoIP 服务的网络要求，并且通常是质量不佳的根源。 有关优化 Wi-Fi 基础结构的详细信息，请参阅 有关 Wi-Fi 规划的文章。 无线驱动程序：确保无线驱动程序是最新的。 这将有助于缓解与过时驱动程序相关的任何不良用户体验。 许多组织在其修补周期中不包含无线驱动程序，这些驱动程序可能会多年未修补。 通过确保无线驱动程序是最新的，可以解决许多无线问题。 WMM：无线多媒体扩展 (WMM) （也称为 Wi-Fi 多媒体）为无线网络提供基本的 QoS 功能。 现代无线网络必须支持许多设备。 这些设备争用带宽，并可能导致 VoIP 服务的质量问题，其中速度和延迟至关重要。 有关详细信息，请咨询无线供应商，并考虑在无线网络上实施 WMM，以优先考虑Skype for Business和 Teams 媒体。 接入点密度：接入点可能相距太远或不在理想位置。 为了尽量减少潜在的干扰，请在会议室和没有墙壁或 Wi-Fi 信号较弱的其他物体遮挡的位置放置额外的接入点。 2.4 GHz 与 5 GHz：5 GHz 提供更少的背景干扰和更高的速度，在通过 Wi-Fi 部署 VoIP 时，应优先考虑。 但是，5 GHz 不如 2.4 GHz 强，并且不容易穿透墙壁。 查看你的建筑布局，以确定可以依赖哪个频率来获得最佳连接。 |
| 网络设备 | 大型组织可能会有数百个设备分布在网络中。 请与网络团队协作，确保从用户到 Internet 的网络设备保持最新。 |
| VPN | VPN 设备传统上不是为了处理实时媒体工作负载而设计的。 某些 VPN 配置禁止使用 UDP (这是媒体) 的首选协议，并且仅依赖于 TCP。 考虑实现 VPN 拆分隧道解决方案，以帮助减少 VPN 作为质量不佳的来源。 |
| 客户端 仅 (Skype for Business Online) |
确保定期更新所有客户端。 |
| Devices | 如果设备是通话质量问题的罪魁祸首，请考虑更新有问题的设备。 若要了解详细信息，请阅读 Teams 电话 。 |
| 司机 | 修补网络 (以太网和 Wi-Fi) 、音频、视频和 USB 驱动程序应是总体修补程序管理策略的一部分。 更新驱动程序可以解决许多质量问题。 |
| Wi-Fi 上的会议室 | 强烈建议会议室设备至少使用 1-Gbps 以太网连接连接到网络。 会议室设备通常包括多个音频和视频流，以及会议内容（如屏幕共享），并且具有比其他 Teams 或Skype for Business终结点更高的网络要求。 根据定义，会议室是固定设备，Wi-Fi 仅在安装期间提供权益。 会议室需要格外小心和注意，以确保使用这些设备的体验符合或超出预期。 会议室的质量问题通常会迅速升级，因为它们通常由高级员工使用。 除了便利) 之外，所有内容都相等 (，因此 Wi-Fi 性能通常低于有线连接。 随着“自带设备”策略的兴起和笔记本电脑的激增，Wi-Fi 接入点经常被过度利用。 在 Wi-Fi 网络上，实时媒体可能不会优先处理，这可能会导致使用高峰期出现质量问题。 这种繁重的使用可能恰逢会议，会议可能有十几个人出席，每个会议都有自己的笔记本电脑和智能手机，都连接到与会议室设备相同的 Wi-Fi 接入点。 Wi-Fi 仅应被视为移动安装的临时解决方案，或者当已正确预配 Wi-Fi 以支持基于实时的企业级媒体时。 |
TCP
传输控制协议 (TCP) 被视为故障回复传输，而不是实时媒体所需的主传输。 这是故障回复传输的原因，原因是 TCP 的有状态性质。 例如，如果在潜在网络上进行调用，并且媒体数据包被延迟，那么几秒钟前的数据包（这些数据包不再有用）会争相获取带宽以到达接收器，这可能会使情况变得更糟。 这使得音频愈合器缝合和拉伸音频，导致可听见的音像，通常以抖动的形式。
本部分中的报告不区分好流和差流。 鉴于首选 UDP，报告将 TCP 用于音频、视频和基于视频的屏幕共享， (VBSS) 。 提供较差的流速率有助于比较 UDP 质量与 TCP 质量，以便你可以专注于影响最大的工作。 TCP 使用主要是由不完整的防火墙规则引起的。 有关 Teams 和 Skype for Business Online 的防火墙规则的详细信息，请参阅 Microsoft 365 和 Office 365 URL 和 IP 地址范围。
注意
音频、视频和 VBSS 都首选 UDP 作为主要传输。 旧版 RDP 应用程序共享工作负荷仅使用 TCP。
TCP 用法
TCP 报告指示过去 7 个月的总体 TCP 使用情况。 本部分中的所有进一步报告将侧重于缩小 TCP 最常使用的特定建筑物和子网的范围。 单独的报告可用于会议和两方流。
调查
使用此报告，可以回答以下问题：
- 当前月份的 TCP 流总数是多少？
- 是比前一个月更糟还是更好？
- TCP 使用趋势是增加、稳定还是减少？
- TCP PSR 是否与总体 PSR 相同？
如果你注意到 TCP 使用趋势正在增加或高于正常的每月使用量，请花时间使用子报告进行调查，以查找可能需要修正的任何建筑物或网络。 理想情况下，你希望在托管网络上尽可能少地使用基于 TCP 的音频会话。
TCP 与 UDP
此报表标识基于音频、视频和基于视频的屏幕共享 (VBSS) 的最新月份 TCP 与 UDP 使用情况报告的量。
分析
尽管你希望 TCP 使用率尽可能低，但在正常部署中可能会看到一些 TCP 使用情况。 TCP 本身不会造成调用不佳，因此提供流速率以帮助确定 TCP 使用是否是质量不佳参与者。
TCP 调查
在提供的 CQD 模板中，使用“托管网络”或“所有网络”模板导航到“按生成 TCP 流”和“子网”报告。 为了调查 TCP 使用情况，此过程是相同的，因此我们将在此处讨论会议。
修复
此报表标识导致 TCP 使用量的特定建筑物和子网。 还包含一个附加报告，用于标识调用中使用的 Microsoft 中继 IP，以帮助隔离缺少的防火墙规则。 将修正工作重点放在具有最大 TCP 流量的建筑物上，以最大程度地提高影响。
使用 TCP 的最常见原因是防火墙或代理中缺少异常规则。 我们将在下一部分中讨论代理，因此现在请将工作重点放在防火墙上。 通过使用提供的生成或子网，可以确定需要更新的防火墙。
| 修复 | 指引 |
|---|---|
| 配置防火墙 | 验证是否已从防火墙中排除 Microsoft 365 或 Office 365 IP 端口和地址。 对于与媒体相关的 TCP 问题，请将初始工作集中在以下方面：
|
| 验证 | 使用 Microsoft 网络评估工具检查特定 Microsoft 365 的连接问题，或者从受影响的建筑物或子网Office 365 IP 地址和端口。 |
HTTP 代理
由于多种原因，HTTP 代理不是建立媒体会话的首选路径。 许多都包含深度数据包检查功能，这些功能可能会阻止完成与服务的连接并造成中断。 此外，几乎所有代理都强制 TCP，而不是允许 UDP，这是为了获得最佳音频质量而推荐的。
我们始终建议将客户端配置为直接连接到 Teams 并Skype for Business服务。 这对于基于媒体的流量尤其重要。
重要
建议上传 有效的生成文件 ，以便在分析代理使用情况时，可以区分内部音频流和外部音频流。
HTTP 代理用法
此模板部分中的 HTTP 代理流报告与 TCP 报告非常类似。 它不会查看调用是差还是好，而是看调用是否通过 HTTP 进行连接。
分析
你希望看到尽可能少的 HTTP 媒体流。 如果有流遍历代理，请咨询网络团队，确保适当的排除项到位，以便客户端直接路由到 Teams 或Skype for Business联机媒体子网。
如果组织中只有一个 Internet 代理，请验证正确的 Microsoft 365 或Office 365 URL 和 IP 地址范围排除项。 如果在组织中配置了多个 Internet 代理，请使用 HTTP 子报表来隔离哪个建筑物或子网受到影响。
对于无法绕过代理的组织，请确保将 Skype for Business 客户端配置为在代理后面正确登录，如文章中所述，Skype for Business应使用代理服务器登录，而不是尝试直接连接。
HTTP 代理调查
此报表标识导致 HTTP 使用的特定建筑物和子网。
修复
建议始终绕过Skype for Business和 Teams 的代理，尤其是媒体流量。 代理不会使Skype for Business更安全，因为它的流量已加密。 环境中可能会出现由于延迟和数据包丢失而引起的与性能相关的问题。 这些问题将导致音频、视频和屏幕共享的负面体验，而实时流至关重要。
HTTP 使用的最常见原因是代理中缺少异常规则。 通过使用提供的生成或子网，可以快速确定需要为媒体旁路配置哪个代理。
验证所需的 Microsoft 365 或 Office 365 FQDN 是否已添加到代理中的允许列表中。
终结点调查
本部分重点介绍有关客户端版本的报告任务以及认证设备的使用。 报告可用于概述客户端版本、客户端类型、捕获设备和驱动程序 (麦克风) 、视频捕获设备以及 Wi-Fi 供应商和驱动程序版本的使用情况。
注意
本文未涵盖模板中包含的所有报表;但是，下面介绍的调查方法仍然适用。 有关详细信息，请参阅各个报表说明。
客户端版本
这些报告侧重于识别正在使用Skype for Business客户端版本及其在环境中的相对量。
重要
目前，Teams 客户端通过 Azure 内容分发网络进行分发和更新，服务将保持最新状态。 因此，除非关闭自动更新，否则无需 (监视 Teams 客户端版本，我们不建议) 。
除非排除联合参与者数据，否则这些报告将包括来自联合终结点的客户端遥测数据。 若要排除联合终结点，必须为设置为组织的租户 ID 的第二个 租户 ID 添加查询筛选器。 或者，可以使用 URL 筛选器 来排除联合参与者遥测数据。
修复
推动高质量用户体验的一个关键部分是确保托管客户端运行最新版本的 Skype for Business，以及确保支持的音频、视频、网络和 USB 驱动程序是最新的。 这提供了几个好处，其中包括：
- 与管理多个版本相比，管理几个版本更容易。
- 它提供了一定程度的体验一致性。
- 这样可以更轻松地排查通话质量和可用性问题。
- Microsoft 会持续对产品进行常规改进和优化。 确保用户收到这些更新可降低遇到已解决的问题的风险。
将部署限制为不到 6 个月的客户端版本将改善整体用户体验，并通过减少需要支持的版本数来提高可管理性。
如果仅使用 Office 即点即用，则将自动在 6 个月的时段内。 无需执行进一步操作。
如果混合使用即点即用包和安装包 (MSI) ，则可以使用报告来验证 MSI 客户端是否正在定期更新。 如果你注意到客户端落后，请与负责管理 Office 更新的团队合作，并确保他们定期批准和部署客户端修补程序。
考虑并确保网络、视频、USB 和音频驱动程序也得到修补，这一点也很重要。 很容易忽略这些驱动程序，而不将它们包含在修补程序管理策略中。
可通过以下链接找到Skype for Business的版本号：
设备
若要利用麦克风设备报告，我们需要了解 MOS) (平均意见评分的概念。 MOS 是用于测量感知音频质量的黄金标准测量。 它表示为 0 到 5 的整数分级。
所有语音质量指标的基础是一个人如何感知语音质量。 因为它受人类感知的影响，所以本质上是主观的。 有几种不同的主观测试方法。 大多数语音质量度量都基于绝对分类分级 (ACR) 规模。
在 ACR 主观测试中，统计上相当多的人将他们的体验质量评为 1 (差) 到 5 (优秀) 。 分数的平均值是 MOS。 生成的 MOS 取决于向组公开的体验范围以及所分级的体验类型。
由于对实时通信系统进行语音质量的主观测试是不切实际的，因此 Microsoft Teams 和 Skype for Business通过使用高级算法客观地预测主观测试结果来生成 MOS 值。
可用的 MOS 和关联指标集提供了音频设备向用户提供的体验质量的视图。
通过为用户提供经过 Teams 和Skype for Business认证的设备，可以减少由于设备本身 (而遇到负面体验的可能性，例如，内置笔记本电脑扬声器和麦克风) 。 有关详细信息，请参阅认证计划和合作伙伴解决方案目录上的这些文章。
设备报告用于按音量和 MOS 分数评估设备使用情况， (音频仅) ，可在“客户端 & 设备”下的随附模板中找到。
重要
除非排除联合参与者数据，否则这些报告将包括来自联合终结点的客户端遥测数据。 若要排除联合终结点，必须为设置为组织的 租户 ID 的第二 个 租户 ID 添加查询筛选器。 通常，可以使用 URL 筛选器 来排除联合参与者遥测数据。
注意
查看此报表时，你可能会注意到，你会看到同一设备多次报告。 这是因为向 CQD 报告设备的方式。 硬件和 OS 区域设置的差异会导致报告设备数据的方式存在差异。
修复
通常，需要发现并逐步淘汰未经认证的设备，并将其替换为经过认证的设备。 查看设备报告时的一些注意事项包括：
- 正在使用的设备是否经过 Teams 和Skype for Business认证？
- 可以使用 每用户呼叫分析来识别特定设备的用户。 检查以确保他们拥有最新的设备驱动程序，并且他们的设备未通过 USB 集线器或扩展坞进行连接。
- 正在使用多少个不同版本的各种驱动程序？ 是否定期修补它们？ 确保定期修补音频、视频和 Wi-Fi 驱动程序将有助于消除这些驱动程序作为质量问题的根源，并使用户体验更具可预测性和一致性。
音频
下一个任务是确定 认证音频设备的总体使用情况。 建议至少 80% 的所有音频流使用经过认证的音频设备。 最好将麦克风设备报告导出到 Excel，以计算已认证或已批准的设备的使用情况。 组织通常会保留所有已批准的设备的列表，因此筛选和排序数据应非常简单。
视频
视频驱动程序对于保持更新也很重要。 确保视频卡定期修补将有助于排除视频驱动程序作为视频流质量不佳的来源。 使用 经过认证的视频设备 将有助于确保流畅和高质量的用户体验。 支持 H.264 本机编码的视频设备是首选，以减少视频会议期间的 CPU 使用率。
Wi-Fi
Wi-Fi 驱动程序还需要定期进行修补，并应包含在修补程序管理策略中。 通过维护最新的 Wi-Fi 驱动程序，可以纠正许多质量问题。 有关优化 Wi-Fi 基础结构的详细信息，请参阅 有关 Wi-Fi 规划的文章。
相关主题
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈