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

# 对 Connect 客户中的音频质量问题进行故障排除
<a name="troubleshoot-audio-quality"></a>

**目标受众**  
本指南假设您是一名 IT 管理员，具有调查网络、电话和工作站问题的经验，并且您可以访问 Connect Customer 联系人记录中的数据。

音频质量问题——断断续续的音频或机器人音频、回声、延迟、单向音频、嗡嗡声或死气——可能源于通话路径上的任何地方。此页面是诊断它们的起点。*它可以帮助您缩小问题发生路径的范围，然后将您引导到解决问题的专业主题。*

**呼叫断开连接**  
本页介绍音频*质量*。如果来电掉线或断开连接，而不是听起来不好，请参阅。[在联系人记录 DisconnectDetails 中使用来排除呼叫断开连接故障](troubleshoot-call-disconnects.md)

## 开始之前：收集这些信息
<a name="troubleshoot-audio-quality-before-you-begin"></a>

在开始之前，请收集受影响呼叫的以下信息。您需要它来进行调查，并在必要时向 Support 提起诉 AWS 讼。
+ **症状描述** — 音频听起来像什么（断断续续、机器人、回声、单向、嗡嗡声、死气、延迟）以及谁的声音受到影响。你可以在步骤 1 中使用它。
+ **实例 Amazon 资源名称 (ARN)**-请参阅。[找到你的 Connect 客户实例 ID 或 ARN](find-instance-arn.md)
+ **ContactId**每个受影响的呼叫（提供 3-5 个示例，不得超过 24 小时）。
+ **发生时间**，包括时区（尽可能以协调世界时 (UTC) 记录）。
+ 每个示例的@@ **通话录音**。

如果您无法直接获得录音，请代理或客户查看录音并确认：
+ **谁的音频质量下降了—— **代理**还是最终客户。**
+ 录音中是否**真的可以听**到报告的降级。

**先决条件**  
在进行故障排除之前，请确保基本知识：代理工作站满足[最低硬件要求](ccp-agent-hardware.md)，代理使用[支持的浏览器](connect-supported-browsers.md)。

## 步骤 1：识别症状
<a name="troubleshoot-audio-quality-step1"></a>

使用症状跳转到最可能的原因。如果您的症状未列出，或者您不确定，请继续步骤 2。


| 症状 | 最有可能的区域 | 去哪里 | 
| --- | --- | --- | 
| Windows 11 重启后第一次通话时没有音频（“中断”） | 工作站（网络接口 card/services） | [使用 Windows 11 时，系统重启后首次通话时出现 CCP 音频问题](common-ccp-issues.md#ccp-windows-11-audio-issues-after-reboot) | 
| 双向没有音频（任何一方都听不见对方的声音），重启后不行 | 联系人控制面板 (CCP) 设置、麦克风访问或端口 | [联系人控制面板（CCP）问题](common-ccp-issues.md)，[如何解决我的 Amazon Connect CCP 中通话期间音频停止的问题？ （AWS re: Post）](https://repost.aws/knowledge-center/connect-call-audio-not-working) | 
| 一方听不到另一方的声音（单向音频） | 独占 mic/speaker 控制或网络地址转换 (NAT) | [One-way 来自客户的音频](common-ccp-issues.md#ccp-oneway-issues), [解决网络中的通话质量和断线问题](network-ts.md) | 
| 特工的音频中持续嗡嗡作响 | Headset/browser 采样率不匹配 | [座席音频设备发出嗡嗡声：验证头带式耳机和浏览器的采样率](verify-sample-rate.md) | 
| 未接来电/ “无法访问麦克风”/“初始化失败” /网络 Real-Time 通信 (WebRTC) 超时 | CCP 设置、权限或端口 | [联系人控制面板（CCP）问题](common-ccp-issues.md) | 
| Echo（特工能听见自己的声音） | Mic/speaker 反馈 | [解决座席工作站的通话质量和断线问题](agent-ts.md) | 
| Choppy/broken、延迟或 distorted/robotic 音频 | 网络或工作站 | 继续步骤 2 | 

## 步骤 2：确定范围
<a name="troubleshoot-audio-quality-step2"></a>

受影响代理的数量会从你先看的地方发生变化。
+ **单个代理 — 专注于该代理****的工作站（步骤 5，工作站**路径）和头戴式耳机。
+ **同一位置或层次结构中的多个代理** ——怀疑存在**本地网络**问题（路由器、互联网服务提供商 (ISP) 或局域网 (LAN)）或推送到这些计算机的软件或操作系统更新。
+ **分布在多个地点（远程和办公室内）的代理** ——怀疑**组织级别**的网络更改或自动更新。 browser/OS

使用[AgentHierarchyGroups](ctr-data-model.md#ctr-AgentHierarchyGroups)和[DeviceInfo](ctr-data-model.md#ctr-deviceinfo)从接触记录中识别受影响的人群。有关影响分析的更多信息，请参阅[使用联系记录中的 `QualityMetrics` 来解决音频质量问题](sop-audio-qa.md)。

**提示**  
如果问题发生在所有受影响代理的特定日期，请检查在该日期推送的网络基础架构更改、浏览器自动更新或操作系统补丁。

## 步骤 3：使用呼叫路径定位问题
<a name="troubleshoot-audio-quality-step3"></a>

当代理使用联系人控制面板 (CCP) 时，呼叫将通过以下路径：

**(1) 头戴式耳机 → (2) 座席 device/CCP → (3) 座席网络 → (4) Connect Customer → (5) 电话网络 → (6) End-customer 设备**

Connect Customer 在第 (4) 点录制每个呼叫，因此录音捕捉的音频与到达 Connect Customer 时完全相同。录音是一条分界线。如果在录**音中可以听到降级，则**表示音频在到达 Connect Custom **er 之前**已经降级（路径 1—3）。如果录音**听起来很干净**，但参与者报告了音频不好，则质量下降发生**在第 4 点之后**，在通往听众的路径上。

使用下表将您观察到的内容与结论以及下一步的方向进行配对。


| 谁的音频被降级了 | 降级**正在**录制中 | 降级**不**在录音中 | 
| --- | --- | --- | 
| 代理（客户听到的代理人的声音） | 在到达 Connect Customer（头戴式耳机、设备或代理网络（1、2 和 3）之前，音频已降级。转至步骤 4。 | Connect Customer 的音频干净利落了，但客户听到了降级 — 电话网络或最终客户端（5 和 6）。转至步骤 6。 | 
| End-customer（客服人员听到的客户声音） | 音频在到达入站端（电话网络或最终客户设备（5 和 6）的 Connect Customer 之前已降级。转至步骤 6。 | Connect Customer 的音频干净利落，但代理听到了降级的声音，即代理网络、设备或头戴式耳机（1、2 和 3）。转至步骤 4。 | 

**Multi-party 和电话会议**  
对于会议或多方通话，请将此录音本地化逻辑应用于每段（每段 ContactId），而不是应用于整个呼叫。

**没有可用的录音**  
如果您无法从录制中确定受影响的路径，或者没有可用的录音，请继续执行步骤 4 以提取指标，这样可以独立定位问题。

## 步骤 4：收集诊断数据（代理端，路径 1、2 和 3）
<a name="troubleshoot-audio-quality-step4"></a>

按顺序运行这些。每个都链接到其完整程序。

1. **端点测试实用程序**-在受影响代理的计算机上，验证 WebRTC 支持、媒体设备访问、每个区域的延迟（**目标低于** 300 毫秒）和所需的端口。下载 JSON 结果。请参阅[使用端点测试实用程序验证与 Connect Customer 的连接](check-connectivity-tool.md)。

1. **QualityMetrics 从联系人记录**中——致电[DescribeContact](https://docs.aws.amazon.com/connect/latest/APIReference/API_DescribeContact.html)并查看：
   + **`QualityScore`**（1.00 = 差，5.00 = 极好），便于快速阅读。
   + **`PotentialQualityIssues`**：`HighPacketLoss`、`HighJitterBuffer` 或 `HighRoundTripTime`。列表为空表示未检测到任何问题。请参阅[使用联系记录中的 `QualityMetrics` 来解决音频质量问题](sop-audio-qa.md)。

1. **CCP 日志** — 如果有，请下载它们并在 CCP 日志解析器中将其打开。在受影响的呼叫期间检查 ERROR-level 条目和 WebRTC 指标`PacketLoss`：`JitterBufferMillis`，（> 30 毫秒表示异常）`RoundTripTime`、（> 300 毫秒表示异常）。请参阅[下载并查看 Connect 客户联系控制面板 (CCP) 日志](download-ccp-logs.md)。

1. **Amazon CloudWatch** — 检查问题发生期间是否`ToInstancePacketLossRate`超过 **20%**。有关检查此指标的更多信息，请参阅[解决 Amazon Connect 音频质量问题 (AWS re: Pos](https://repost.aws/knowledge-center/connect-audio-quality-issues) t)。当丢包率远低于 20% 时，音频质量可能会降低；此阈值表示存在严重问题，需要网络团队立即参与。

然后根据你发现的内容进行分支：
+ **发现异常指标** → 视为**网络**问题（步骤 5，网络路径）。
+ **没有异常指标** → 视为**工作站**问题（步骤 5，工作站路径）。

## 步骤 5：解决代理端问题
<a name="troubleshoot-audio-quality-step5"></a>

### 网络（路径 3）
<a name="troubleshoot-audio-quality-network"></a>

代理网络异常`PacketLoss``JitterBuffer``RoundTripTime`、、或高`ToInstancePacketLossRate`点。请检查：
+ **虚拟专用网络 (VPN)**-如果没有 VPN（直接连接），问题会重现吗？ 如果需要 VPN，是否为实时流量启用了隧道分割？
+ **Wi-Fi 与有线相比** — 它会在有线连接上重现吗？
+ **Firewall/proxy/NAT**—是否允许 UDP 3478（媒体）、TCP 443 和 websocket 流量？ 尽可能使用带有保持活跃状态的静态 NAT。
+ **带宽争用** — 大型文件传输还是带宽密集型应用程序同时运行？
+ **到区域的距离**-代理离实例的 AWS 区域是否很远？ （与高值相关`RoundTripTime`。）

完整程序:[解决网络中的通话质量和断线问题](network-ts.md). 有关指标解释的更多信息，请参阅[使用联系记录中的 `QualityMetrics` 来解决音频质量问题](sop-audio-qa.md)。

### 工作站（路径 1/2）
<a name="troubleshoot-audio-quality-workstation"></a>

没有异常的网络指标指向头戴式耳机、设备或软件。请检查：
+ **头戴式耳机** — 有线与无线；有线头戴式耳机能解决这个问题吗？ 确认它符合[头戴式耳机的最低要求](ccp-agent-hardware.md#ccp-agent-headset)。
+ **音频增强**-如果启用，禁用它能解决问题吗？ 请注意以下限制：
  + **语音隔离只能与有线头戴式耳机一起使用。**对于无线或混合设置，请改用**噪音抑制**。
  + 音频增强功能至少需要 **4 核 CPU /4 个 vCPU**。
  + **使用 Connect Customer 音频优化（WebRTC 重定向）时不支持音频增强；VDI 本地浏览器访问支持音频增强。**如果同时配置了音频增强和 Connect Customer 音频优化，则可能存在这种冲突。请参阅[在 Connect Customer 中为座席启用音频增强功能](audio-enhancement.md)。
+ **嗡嗡声** —验证 headset/browser 采样率是否为 48000。请参阅[座席音频设备发出嗡嗡声：验证头带式耳机和浏览器的采样率](verify-sample-rate.md)。
+ **浏览器或操作系统**-检查最近的更新；回滚到上一个工作版本能否解决这个问题？ 确认[支持的浏览器](connect-supported-browsers.md)。
+ **虚拟桌面基础架构 (VDI)** — 对于 Citrix 或 Omnissa WorkSpaces，请确保通过参数配置 WebRTC 重定向。`VDIPlatform`请参阅[使用代理工作区优化 Citrix WorkSpaces、Amazon 和 Omnissa 云桌面的音频](optimize-audio-cdd.md)。
+ **设备独占控制**-检查其他应用程序是否已独占控制权。 mic/speaker请参阅[One-way 来自客户的音频](common-ccp-issues.md#ccp-oneway-issues)。
+ **自定义 CCP** — 如果您使用自定义 CCP，问题会在默认 CCP 上重现吗？
+ **Windows 11 在重启后首次通话** — 如果仅在重启后的第一次通话中音频出现故障，请应用服务启动类型修复程序（qWave、ndisuio.sys、dmw、、）。AppushSvc SstpSvc RasMan请参阅[使用 Windows 11 时，系统重启后首次通话时出现 CCP 音频问题](common-ccp-issues.md#ccp-windows-11-audio-issues-after-reboot)。

完整程序：[解决座席工作站的通话质量和断线问题](agent-ts.md)以及[提高 Amazon Connect 联络中心座席工作站的通话质量（规范性指导）](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html)。

## 步骤 6：解决最终customer/telephony 问题（路径 4/5 /6）
<a name="troubleshoot-audio-quality-step6"></a>

当降级处于终端状态时，您无法在代理工作站上对其进行修复。customer/telephony 在打开案例之前，请尝试隔离消息来源：
+ **更改通话环境** — 让最终客户尝试其他设备、网络或运营商。
+ **查看常见因素** ——问题是否与特定的运营商、直接向内拨号 (DID) 号码或地理区域有关？ 如果它与特定的国家或号码类型相关，请在 Amazon Connect 网站上的 [Amazon Connect 电信覆盖指南中确认该国家/地区的覆盖范围](https://d1v2gagwb6hfe1.cloudfront.net/Amazon_Connect_Telecoms_Coverage.pdf)和任何已知的电话限制。
+ **检查来电转移-是否有其他系统将呼叫**转接给 Connect 客户？ 如果是，直接拨打 Connect Customer 而不进行转接会出现问题吗？
+ **测试多个数字** — 尝试使用多个目的地和来源号码，以查看问题是否与特定数字有关。

如果这些更改后问题仍然存在，请向 Support 提交 AWS 案例。

## 第 7 步：联系之前 AWS 支持
<a name="troubleshoot-audio-quality-step7"></a>

如果故障排除后问题仍然存在，请[打开一个**不超过 24 小时的 3-5 个示例**的案](open-case-troubleshoot-audio.md)例，其中包括：
+ 实例 ARN 和对症状的描述（谁的声音以及如何——断断续续、没有音频、回声等）。
+ ContactIds、时间戳 (UTC) 和联系人记录快照。
+ 电话录音附在案子上。
+ 对于最终客户问题：最终客户的电话号码（最后 4 位数字可能被屏蔽）和 Connect 客户电话号码。
+ 测试结果：浏览器测试、网络测试、备用机器测试、**端点测试实用程序 JSON 导出**，以及**运行 Ping 和 MTR 后的观察结果**。
+ 代理环境详细信息： VPN/firewall/VDI 配置、头戴式耳机类型和音频增强模式。
+ CCP 类型（默认与自定义）以及受影响呼叫的下载的 CCP 日志。
+ 问题的频率及其开始时间（UTC）。 date/time 

**在受影响的呼叫后立即下载 CCP 日志**  
CCP 日志仅在当前浏览器会话中保留。如果代理关闭或刷新 CCP 选项卡，浏览器会丢弃日志——在受影响的呼叫之后尽快下载日志。