本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 使用联系记录中的 `QualityMetrics` 来解决音频质量问题
<a name="sop-audio-qa"></a>

**重要**  
本节中的主题和内容适用于具有调查网络和电话问题经验的 IT 管理员。  
您还需要熟悉如何访问 Amazon Connect 联系记录中的数据。

## 在哪里可以找到 QualityMetrics
<a name="find-qualitymetrics"></a>

Amazon Connect 会在每个已接通呼叫的联系记录 QualityMetrics 中提供。

QualityMetrics 是您在调用 [DescribeContact](https://docs.aws.amazon.com/connect/latest/APIReference/API_DescribeContact.html)API 时作为响应获得的联系人对象的一部分。下面的 `DescribeContact` 响应片段显示了这种形式：

```
 "QualityMetrics": { 
         "Agent": { 
            "Audio": { 
               "PotentialQualityIssues": [ "string" ],
               "QualityScore": number
            }
         },
         "Customer": { 
            "Audio": { 
               "PotentialQualityIssues": [ "string" ],
               "QualityScore": number
            }
         }
      },
```

QualityMetrics 也是你通过 Kinesis 点击率事件接收的[QualityMetrics](ctr-data-model.md#ctr-qualitymetrics)对象的一个子部分。

QualityMetrics 无法通过使用 Connect Customer 管理网站查看联系人记录来获得。

QualityMetrics 不是 EventBridge 活动的一部分。

## 通话质量问题的表现
<a name="call-quality-symptoms"></a>

以下是表明参与者媒体连接通话质量问题的常见表现列表。您可以在 Amazon Connect 参与者渠道的通话录音中观察到这些表现。
+ 音频不流畅/断断续续
  + 观察结果：音频流在媒体连接上被中断，听起来不流畅或断断续续，另一端的听众也能听到。
  + 潜在原因：可能是由于网络连接不佳导致数据包丢失，从而导致参与者对另一方听起来不流畅或断断续续。
+ 音频延迟
  + 观察结果：参与者体验到另一方的音频延迟。延迟音频的影响是呼叫方和座席之间的对话始终重叠。
  + 潜在原因：这可能是由于网络bandwidth/hardware/workstation拥塞受限造成的。
+ Echo
  + 观察结果：回声是指座席听到自己的声音延迟地向他们重复发回来。
  + 潜在原因：这通常是由于麦克风和扬声器之间的音频反馈造成的。
+ 背景噪音
  + 观察结果：外来的背景噪音，例如风扇声、打字声或联络中心的噪音，会让人难以听清呼叫方的声音。
+ 音频失真
  + 观察结果：一方听到另一方发出的声音失真、乱码或听起来像机器人的声音。
  + 潜在原因：这通常是带宽问题或硬件故障的信号。

## 分析对座席和通话的影响
<a name="analyze-impact-qa-metrics"></a>

建议将 [QualityMetrics](ctr-data-model.md#ctr-qualitymetrics) 数据与联系记录中的其他字段（例如 [`AgentHierarchyGroup`](ctr-data-model.md#ctr-AgentHierarchyGroups) 和 [`DeviceInfo`](ctr-data-model.md#ctr-deviceinfo)）一起使用，以确定受影响人群并发现任何趋势。利用这些信息回答下列问题，以了解总体影响：
+ 受影响的座席或通话占多大比例？
  + 场景 1：如果只有 1 个代理遇到问题，则可能与代理工作站有关，包括代理的操作系统和 browser/network 配置。
  + 场景 2：如果同一层次结构（例如，相同的地理位置或办公室）中的多个代理遇到音频质量问题，则可能是由于本地网络问题（modem/ISP/Router/LAN连接）或代理计算机最近软件升级所致。
  + 场景 3：多个代理（ and/or 在办公室远程办公）可能遇到此问题。检查 browser/system 配置中是否有更新，以及组织层面可能发生的任何网络更改。
+ 在给定的一天中，受影响的通话占多大比例？有多少通话受到影响？
+ 问题是在来电、去电时出现，还是两者都出现？
+ 实体是否将呼叫转接到 Amazon Connect？ 如果是，直接拨号到 Amazon Connect 时在没有通话质量问题的情况下是否会出现音频质量问题。

## 使用 `QualityMetrics`
<a name="troubleshoot-with-qa-metrics"></a>

Amazon Connect 在每个已接通呼叫的联系记录中提供 [QualityMetrics](ctr-data-model.md#ctr-qualitymetrics)。使用指标帮助您找出问题的根源。

`QualityMetrics` 包含以下信息：
+ **QualityScore**：使用数值估算整体音频质量。
  + 最小值：1.00（表示质量差）
  + 最高值：5.00（表示高质量）
+ **PotentialQualityIssues**：对于有潜在问题的通话，`PotentialQualityIssues` 会填充一个检测到的原因列表，其中包括 `HighPacketLoss`、`HighRoundTripTime` 或 `HighJitterBuffer`。如果列表为空，则表示没有检测到音频质量问题。

下面的列表说明了 `PotentialQualityIssues` 的潜在值，并提出了指导调查的原因。
+ `HighPacketLoss`：当此值出现在 `PotentialQualityIssues` 时，表明在参与者的出站音频（出口）流中发现了数据包丢失。
  + 原因：
    + 这可能发生在数据包在参与者和 Amazon Connect 终端节点之间穿越网络的路径中，这可能是由于 bad/poor 网络、网络拥塞、网络带宽受限所致。
    + 当参与者系统中的其他应用程序可能导致网络带宽不足时，也会出现这种情况。
+ `HighJitterBuffer`：这是浏览器内置缓冲区在网络穿越后纠正音频数据包顺序时引入的时间延迟。抖动缓冲区在确保设备通过网络接收到的数据包适当对齐以提供不失真音频方面发挥着重要作用。
  + 原因：
    + 如果参与者端出现拥塞（网络 and/or 硬件），则`JitterBuffer`会导致音频 delays/distorted 或音频断断续续。
    + 抖动缓冲区负责延迟媒体数据包的处理时间，刚好足以缩短传输时间，但抖动缓冲区过高会导致背景噪音或音频质量问题。
    + 如果抖动缓冲区超过 30 毫秒或变化非常频繁，则意味着网络拥塞或路由器网络带宽不足。高抖动也可能是由于相关设备的硬件问题造成的。
+ `HighRoundTripTime`：这是数据包通过 IP 网络从发送端点到接收端点再返回所需的时间，不包括在目的地的处理时间。高 RTT 会导致呼叫方在通话中遇到明显的延迟（语音重叠）。 RoundTripTime (RTT) 是参与者的设备与 Amazon Connect 终端节点之间的预计网络往返时间。
  + 原因：
    + 造成往返时间长的最常见原因是网络带宽低或受限。
    + 如果某个软件程序导致往返时间激增，则可能还会遇到往返时间过长的问题。过去，我们的一些客户曾报告说 VPN 应用程序是导致此问题的原因。
    + 如果代理的物理位置远离 Amazon Connect 实例的 AWS 区域，则会 RoundTripTime 增加延迟。
    + 通过虚拟桌面路由音频（而不是将 WebRTC 会话直接重定向到座席工作站）也可能导致往返时间过长。

## 后续步骤
<a name="troubleshoot-audio-nextsteps"></a>

在确定问题是 `HighPacketLoss`、`HighJitterBuffer` 还是 `HighRoundTripTime` 后，利用这些信息排除网络或座席设备的故障。请参阅以下主题：
+ [排除网络故障](network-ts.md)
+ [对座席的工作站进行故障排除](agent-ts.md)