本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
解决 Connect Customer 中的音频质量问题
音频质量问题(不连贯或机器人音频、回声、延迟、单向音频、嗡嗡声或中断)可能源于通话路径上的任何地方。此页面是诊断它们的起点。它可以帮助您缩小问题发生的范围,然后引导您进入解决问题的专业主题。
呼叫断开
本页介绍音频质量。如果通话掉线或断开连接而不是听起来不好,请参阅。在联系人记录 DisconnectDetails 中使用来排除呼叫断开连接故障
目标受众
本指南假设您是一名具有调查网络、电话和工作站问题的经验的IT管理员,并且可以访问Connect Customer联系人记录中的数据。
开始之前:收集这些信息
在开始之前,为受影响的呼叫收集以下信息。您需要它进行调查,并在必要时向 AWS 支持部门提起诉讼。
-
症状描述 — 音频听起来像什么(断断续续、机器人、回声、单向、嗡嗡声、中断、延迟)以及谁的声音受到影响。你可以在步骤 1 中使用它。
-
实例亚马逊资源名称 (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
使用联系人记录DeviceInfo中的AgentHierarchyGroups和来识别受影响的人群。有关影响分析的更多信息,请参阅使用联系记录中的 QualityMetrics 来解决音频质量问题。
提示
如果所有受影响的代理均在特定日期出现问题,请检查该日期是否推送了网络基础架构更改、浏览器自动更新或操作系统补丁。
第 3 步:使用呼叫路径定位问题
当代理使用联系人控制面板 (CCP) 时,呼叫会通过以下路径:
(1) 头戴式耳机 device/CCP → (2) 代理 → (3) 代理网络 → (4) 连接客户 → (5) 电话网络 → (6) End-customer 设备
Connect Customer 在 (4) 点记录每一次通话,因此录音会准确捕捉到音频到达连接客户时的音频。录音是一条分界线。如果录音中可以听到降级效果,则音频在到达 Connect Customer 之前已经降级了(路径 1—3)。如果录音听起来很干净,但参与者报告的音频不好,则降级发生在第 4 点之后,即通往听者的路径上。
使用下表将观察到的结果与结论以及下一步的方向进行配对。
| 谁的音频被降级了 | 录音中有降级 | 录音中不包含降级 |
|---|---|---|
| 代理(客户听到的代理人的声音) | 在到达 Connect Customer(头戴式耳机、设备或代理网络)(1、2 和 3)之前,音频已降级。转到步骤 4。 | Connect Customer可以干净利落地收到音频,但客户听到了降级,包括电话网络或终端客户端(5和6)。转到步骤 6。 |
| End-customer(代理人听到的客户的声音) | 在传入端(电话网络或终端客户设备(5 和 6)的 Connect Customer 到达 Connect Customer 之前,音频已降级。转到步骤 6。 | Connect 客户收到的音频很干净,但客服听到了降级,即代理网络、设备或头戴式耳机(1、2 和 3)。转到步骤 4。 |
Multi-party 和电话会议
对于会议或多方通话,将此录音本地化逻辑应用于每段(每段 ContactId),而不是整个通话。
没有录音可用
如果您无法从录制中确定受影响的路径,或者没有可用的记录,请继续执行步骤 4 提取指标,这样可以独立地定位问题。
步骤 4:收集诊断数据(代理端、路径 1、2 和 3)
按顺序运行这些。每个都链接到其完整程序。
-
端点测试工具 — 从受影响代理的计算机上验证 WebRTC 支持、媒体设备访问权限、每个区域的延迟(目标低于 300 毫秒)和所需的端口。下载 JSON 结果。请参阅验证连接以将客户与端点测试实用程序连接起来。
-
QualityMetrics 来自联系人记录 —致电DescribeContact并查看:
-
QualityScore(1.00 = 较差,5.00 = 极好),便于快速阅读。 -
PotentialQualityIssues:HighPacketLoss、HighJitterBuffer或HighRoundTripTime。空列表表示未检测到任何问题。请参阅使用联系记录中的 QualityMetrics 来解决音频质量问题。
-
-
CCP 日志 — 如果有,请下载它们并在 CCP 日志解析器中将其打开。在受影响的呼叫期间检查 ERROR-level 条目和 WebRTC 指标:
PacketLoss、JitterBufferMillis(> 30 毫秒表示异常)、RoundTripTime(大于 300 毫秒表示异常)。请参阅下载并查看 Connect 客户联系人控制面板 (CCP) 日志。 -
亚马逊 CloudWatch —检查问题发生期间是否
ToInstancePacketLossRate超过 20%。有关检查此指标的更多信息,请参阅 Amazon Connect 音频质量问题疑难解答 (AWS re: POST)。丢包率远低于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)
没有异常的网络指标指向头戴式耳机、设备或软件。请检查:
-
头戴式耳机 — 有线与无线的比较;有线耳机能解决这个问题吗? 确认它符合最低头戴式耳机要求。
-
音频增强 —如果启用,禁用它能解决问题吗? 请注意以下限制:
-
语音隔离只能与有线头戴式耳机一起使用。对于无线或混合设置,请改用 “噪声抑制”。
-
音频增强要求至少 4 核 CPU /4 个 vCPU。
-
使用 Connect Customer 音频优化(WebRTC 重定向)时不支持音频增强;VDI 本地浏览器访问支持音频增强。如果同时配置了 “音频增强” 和 “Connect Customer” 音频优化,则该冲突很可能是原因。请参阅在 Connect Customer 中为代理启用音频增强。
-
-
嗡嗡声 —验证 headset/browser 采样率为 48000。请参阅座席音频设备发出嗡嗡声:验证头带式耳机和浏览器的采样率。
-
浏览器或操作系统 — 检查最近的更新;回滚到上一个工作版本能解决这个问题吗? 确认支持的浏览器。
-
虚拟桌面基础架构 (VDI) ——对于亚马逊 WorkSpacesCitrix、OmnissaAzure Virtual DesktopWindows 365、或,请确保通过参数配置 WebRTC 重定向。
VDIPlatform请参阅使用代理工作区优化亚马逊的音频 WorkSpaces,Citrix, Omnissa, Azure 虚拟桌面,以及 Windows 365 云桌面。 -
独占设备控制 —检查其他应用程序是否已独占控制。 mic/speaker请参阅One-way 来自客户的音频。
-
自定义 CCP —如果您使用自定义 CCP,问题是否会在默认 CCP 上重现?
-
Windows 11 在重启后首次通话 — 如果仅在重启后的第一次通话中出现音频故障,请应用服务启动类型的修复程序(qWave、ndisuio.sys、dmw、、)。AppushSvc SstpSvc RasMan请参阅使用 Windows 11 时,系统重启后首次通话时出现 CCP 音频问题。
完整程序:解决座席工作站的通话质量和断线问题以及提高亚马逊连接联络中心座席工作站的通话质量(规范性指导)。
第 6 步:解决最终customer/telephony 问题(路径 4/5 /6)
当降级到端时,你无法在代理工作站上修复它。customer/telephony 在开箱之前尽量隔离消息来源:
-
改变通话环境 ——让终端客户尝试不同的设备、网络或运营商。
-
检查一个共同因素 ——问题是否与特定的运营商、直拨电话 (DID) 号码或地理区域有关? 如果它与特定国家/地区或号码类型相关,请在 Amazon Connect 网站上的 Amazon Connect 电信覆盖指南
中确认该国家/地区的覆盖范围和任何已知的电话限制。 -
检查呼叫转移 — 另一个系统是否将呼叫转接到 Connect Customer? 如果是,直接拨打 Connect Customer 而不进行转接时会出现问题吗?
-
测试多个数字 —尝试使用多个目标号码和来源号码,看看问题是否出在特定的数字上。
如果这些更改后问题仍然存在,请向 AWS 支持部门提起诉讼。
第 7 步:联系之前 AWS 支持
如果问题在故障排除后仍然存在,请以 3-5 个不超过 24 小时的示例开启案例,并包括:
-
实例 ARN 和症状描述(谁的声音以及症状——断断续续、没有音频、回声等)。
-
ContactIds、时间戳 (UTC) 和联系人记录快照。
-
电话录音附在手机壳上。
-
对于最终客户问题:最终客户的电话号码(最后4位数字可能被屏蔽)和Connect客户电话号码。
-
测试结果:经过测试的浏览器、测试的网络、备用计算机测试、端点测试实用程序 JSON 导出以及您在运行 Ping 和 MTR 之后的观察结果。
-
代理环境详细信息: VPN/firewall/VDI 配置、头戴式耳机类型和音频增强模式。
-
CCP 类型(默认值与自定义相比)和受影响呼叫的下载的 CCP 日志。
-
问题的频率及其开始时间 (UTC)。 date/time
在受影响的通话后立即下载 CCP 日志
CCP 日志仅在当前浏览器会话中保留。如果代理关闭或刷新 CCP 选项卡,浏览器会丢弃日志——在受影响的呼叫后尽快下载这些日志。