View a markdown version of this page

对 Connect 客户中的音频质量问题进行故障排除 - Amazon Connect Customer
开始之前：收集这些信息步骤 1：识别症状步骤 2：确定范围步骤 3：使用呼叫路径定位问题步骤 4：收集诊断数据（代理端，路径 1、2 和 3）步骤 5：解决代理端问题步骤 6：解决最终customer/telephony 问题（路径 4/5 /6）第 7 步：联系之前 AWS 支持

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

对 Connect 客户中的音频质量问题进行故障排除

目标受众

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

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

呼叫断开连接

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

开始之前：收集这些信息

在开始之前，请收集受影响呼叫的以下信息。您需要它来进行调查，并在必要时向 Support 提起诉 AWS 讼。

  • 症状描述 — 音频听起来像什么（断断续续、机器人、回声、单向、嗡嗡声、死气、延迟）以及谁的声音受到影响。你可以在步骤 1 中使用它。

  • 实例 Amazon 资源名称 (ARN)-请参阅。找到你的 Connect 客户实例 ID 或 ARN

  • ContactId每个受影响的呼叫（提供 3-5 个示例，不得超过 24 小时）。

  • 发生时间，包括时区（尽可能以协调世界时 (UTC) 记录）。

  • 每个示例的@@ 通话录音。

如果您无法直接获得录音，请代理或客户查看录音并确认：

  • 谁的音频质量下降了—— 代理还是最终客户。

  • 录音中是否真的可以听到报告的降级。

先决条件

在进行故障排除之前，请确保基本知识：代理工作站满足最低硬件要求，代理使用支持的浏览器。

步骤 1：识别症状

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

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

步骤 2：确定范围

受影响代理的数量会从你先看的地方发生变化。

  • 单个代理 — 专注于该代理的工作站（步骤 5，工作站路径）和头戴式耳机。

  • 同一位置或层次结构中的多个代理 ——怀疑存在本地网络问题（路由器、互联网服务提供商 (ISP) 或局域网 (LAN)）或推送到这些计算机的软件或操作系统更新。

  • 分布在多个地点（远程和办公室内）的代理 ——怀疑组织级别的网络更改或自动更新。 browser/OS

使用AgentHierarchyGroups和DeviceInfo从接触记录中识别受影响的人群。有关影响分析的更多信息，请参阅使用联系记录中的 QualityMetrics 来解决音频质量问题。

提示

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

步骤 3：使用呼叫路径定位问题

当代理使用联系人控制面板 (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）

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

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

  2. QualityMetrics 从联系人记录中——致电DescribeContact并查看：

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

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

然后根据你发现的内容进行分支：

  • 发现异常指标 → 视为网络问题（步骤 5，网络路径）。

  • 没有异常指标 → 视为工作站问题（步骤 5，工作站路径）。

步骤 5：解决代理端问题

网络（路径 3）

代理网络异常PacketLossJitterBufferRoundTripTime、、或高ToInstancePacketLossRate点。请检查：

  • 虚拟专用网络 (VPN)-如果没有 VPN（直接连接），问题会重现吗？ 如果需要 VPN，是否为实时流量启用了隧道分割？

  • Wi-Fi 与有线相比 — 它会在有线连接上重现吗？

  • Firewall/proxy/NAT—是否允许 UDP 3478（媒体）、TCP 443 和 websocket 流量？ 尽可能使用带有保持活跃状态的静态 NAT。

  • 带宽争用 — 大型文件传输还是带宽密集型应用程序同时运行？

  • 到区域的距离-代理离实例的 AWS 区域是否很远？ （与高值相关RoundTripTime。）

完整程序:解决网络中的通话质量和断线问题. 有关指标解释的更多信息，请参阅使用联系记录中的 QualityMetrics 来解决音频质量问题。

工作站（路径 1/2）

没有异常的网络指标指向头戴式耳机、设备或软件。请检查：

完整程序：解决座席工作站的通话质量和断线问题以及提高 Amazon Connect 联络中心座席工作站的通话质量（规范性指导）。

步骤 6：解决最终customer/telephony 问题（路径 4/5 /6）

当降级处于终端状态时，您无法在代理工作站上对其进行修复。customer/telephony 在打开案例之前，请尝试隔离消息来源：

  • 更改通话环境 — 让最终客户尝试其他设备、网络或运营商。

  • 查看常见因素 ——问题是否与特定的运营商、直接向内拨号 (DID) 号码或地理区域有关？ 如果它与特定的国家或号码类型相关，请在 Amazon Connect 网站上的 Amazon Connect 电信覆盖指南中确认该国家/地区的覆盖范围和任何已知的电话限制。

  • 检查来电转移-是否有其他系统将呼叫转接给 Connect 客户？ 如果是，直接拨打 Connect Customer 而不进行转接会出现问题吗？

  • 测试多个数字 — 尝试使用多个目的地和来源号码，以查看问题是否与特定数字有关。

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

第 7 步：联系之前 AWS 支持

如果故障排除后问题仍然存在，请打开一个不超过 24 小时的 3-5 个示例的案例，其中包括：

  • 实例 ARN 和对症状的描述（谁的声音以及如何——断断续续、没有音频、回声等）。

  • ContactIds、时间戳 (UTC) 和联系人记录快照。

  • 电话录音附在案子上。

  • 对于最终客户问题：最终客户的电话号码（最后 4 位数字可能被屏蔽）和 Connect 客户电话号码。

  • 测试结果：浏览器测试、网络测试、备用机器测试、端点测试实用程序 JSON 导出，以及运行 Ping 和 MTR 后的观察结果。

  • 代理环境详细信息： VPN/firewall/VDI 配置、头戴式耳机类型和音频增强模式。

  • CCP 类型（默认与自定义）以及受影响呼叫的下载的 CCP 日志。

  • 问题的频率及其开始时间（UTC）。 date/time

在受影响的呼叫后立即下载 CCP 日志

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