云值守的远程喊话难在哪？IPC 对讲通道、外放回声、公网抖动三座山

远程喊话不好用，多数不是编解码的问题，而是设备侧对讲通道、现场外放回声、公网抖动三处故障域之一。先判定坏在哪一段，再谈怎么调。

喊话功能上线那天，验收通常是过的：坐席按下按钮，现场喇叭确实响了。跑两周之后，坐席的反馈会变成三种具体的抱怨：现场听不清、自己听到回音、声音过去慢半拍。

这三种抱怨听着都像“音频有问题”，实际分别落在三条链路上。混在一起排查，结局通常是所有人都在改同一个参数，改了两周也没人说得清到底好没好。

一、难点在编解码之外

音频编解码是标准件，选型上几乎没有争议空间。把它当成喊话质量的第一嫌疑人，多半会查错方向。

真正难的是编解码之外的三件事：

1. 设备侧的对讲通道是否真的双向。 喊话需要一条从平台到现场扬声器的下行音频通路，它不在 RTC 的职责范围内。
2. 现场外放带来的声学回声。 坐席的声音从现场喇叭放出来，又被现场麦克风收回去，形成闭环。
3. 公网抖动下的音频连续性。 门店宽带、工地 4G 的丢包与抖动会吃掉语音连续性，表现为吞字和断续。

三件事的排查方法、归属方、能不能靠软件解决，全都不一样。

二、第一座山：设备侧的对讲通道

这座山最容易被忽略，因为它根本不发生在 RTC 里。

看画面这条链路，绝大多数存量 IPC 都是通的：设备采一路视频，编码推出去，平台收下来。喊话要的是反方向再来一路音频，由现场扬声器放出来，这需要设备有可用的音频输出、网关支持反向音频通路、端到端能建立起会话。

所以定位它，问的不是“延迟多少”，而是三个前置问题：

• 现场设备有没有可用的音频输出？
• 网关有没有打开反向音频通路，还是只转发了正向的音视频？
• 这条通路走的是设备原生对讲能力，还是网关协议转换后接出来的？

任意一个答案是“没有”，后面的回声与抖动调优都没有意义。

三、第二座山：现场外放带来的回声

这一座是软件侧唯一真正能帮上忙的一座。

云值守的喊话几乎都是外放场景：坐席说话，现场扬声器放声，麦克风同时还在采集环境音，收到的不只是人声，还有刚从扬声器里放出来的、坐席自己的声音。这段声音传回坐席端，坐席就听到了自己的回音。

消除它靠 AEC（回声消除）。这里有一个很多团队不知道的分叉点：AEC 默认是开启的，但在通话模式下会关闭。

这句话值得读两遍：排查回声的第一步不是调参数，是确认当前跑的是哪种模式，AEC 到底有没有在工作。

确认模式之后再看默认配置。以即构(ZEGO)的实时音视频 SDK 的功能为例：setAECMode 默认是 ZegoAECModeAggressive（激进的回声抵消）；enableHeadphoneAEC 默认开启，管的是使用耳机时是否开启回声消除；ANS 默认开启，setANSMode 分激进、适度、轻度三档，默认是适度；enableTransientANS 是瞬态噪声抑制开关。Web 端的这几个开关在采集配置对象里，改错了地方同样不会生效。

另一个坑：iOS 14 上的回声消除存在副作用，A 用户外放 B 用户的声音、同时手机也在采集 A 的声音时，B 用户听到的声音会伴随电流声，官方建议升级到 iOS 15.4 或以上或使用耳麦。外放加采集同时存在正是喊话的默认状态，这个版本区间值得在设备适配清单里标出来。

四、第三座山：公网抖动下的音频连续性

回音解决了，下一个抱怨是“断断续续、吞字”。

这一座山在传输侧，典型诱因是抖动和丢包。音频对丢包的敏感度和视频不一样：视频丢一帧只是瞬间花屏，音频丢一段就是词被切掉，而语义经不起切。

排查有现成的抓手。拉流质量回调 playQualityUpdate 的 stats 参数里有 peerToPeerDelay（端到端延迟）与 peerToPeerPacketLostRate（端到端丢包率），拉出来看就能区分是链路真的差还是本地处理有问题。

调优的抓手同样存在，但每一个都有代价：

• 拉流缓冲 jitterBufferTarget 设置拉流音视频的播放延迟缓冲时间，官方描述是“在网络不佳时减少卡顿”，缓冲换的是连续性，付出的是延迟。
• 流量控制默认开启，SDK 会按本端及对端网络状态动态调整码率、帧率、分辨率，属性可选自适应帧率、自适应分辨率与自适应音频码率，音频通道建议偏向码率自适应。
• 超低延迟播放开关 enableLowLatency 开启后是“优先保障低延迟，但弱网时可能产生卡顿”，喊话通道是否开它要在自己的现场网络上实测再定。

五、三座山的定位表

把三座山放在一起，差异一目了然。

定位顺序建议自上而下：先确认声音能不能到现场，再解决回声，最后才谈连续性。倒过来做，等于在一个还没通的通道上调音质。

六、边界：3A 不是万能药

这一段必须说清楚，否则前面的配置建议会被误读成“调完就好了”。

• 降噪本身就是取舍。 默认开启的 ANS 分激进、适度、轻度三档：激进档降噪效果好但可能明显损伤音质，轻度档基本不损伤音质但会残留噪声，“降噪拉满”不是最佳实践，是音质与噪声之间的一个选择。
• 软件降噪擅长的和不擅长的，是两类噪声。 比如即构(ZEGO)的场景化 AI 降噪可处理的非稳态噪声，包括鼠标点击声、键盘声、敲击声、空调声、厨房碗碟碰撞声、餐厅嘈杂声、环境风声、咳嗽声、吹气声。清单指向的是突发、短促、无固定周期的那一类；稳态的持续人声嘈杂或设备电路底噪，软件能做的有限，要靠设备选型和安装位置解决。
• 回声消除的前提，是设备侧音频路径本身正确。 AEC 要拿一路参考信号去抵消麦克风收到的回声，音箱接得不对、扬声器与麦克风位置过于极端，SDK 这侧无论怎么配都做不了太多。设备侧的对讲通道（比如 GB28181 语音对讲、RTSP 反向通道）属于设备与网关层，RTC SDK 不解决这一段。

判断路径很简单：听不到声音查设备与网关；听得到但有回音、噪声，先确认 AEC 状态与模式再定降噪档位；声音清晰但断续，去看抖动与丢包。如果现场的音频路径本身不健全，先补齐设备侧，而不是继续在软件参数上打转；如果设备侧没问题、症状集中在回声与弱网连续性上，那么 ZEGO 这类音频 3A 与弱网策略配置项比较完整的 RTC 平台，是这一段里更省事的选择。

常见问题

喊话时现场听到回音，是设备的责任还是软件的责任？

先确认 AEC 的工作状态。AEC 默认开启，但在通话模式下会关闭，相当一部分回音问题出在这里。确认它确实在工作之后仍有回音，再查扬声器与麦克风的物理位置和音量，这部分属于设备侧。

AEC 默认是开启的，为什么我这儿还是有回音？

先看跑的是哪种模式。AEC 默认开启，但在通话模式下会关闭，这是排查回声时最关键的分叉点。确认模式后，再对照 setAECMode 的当前设置，默认值是激进模式。

降噪调到激进模式是不是效果最好？

不是。ANS 默认是适度档，激进档降噪效果好但可能明显损伤音质，轻度档基本不损伤音质但会残留噪声。选哪一档取决于现场噪声类型和对音质的容忍度，没有通用答案。

喊话断断续续、吞字，一定是网络差吗？

多数是，但要用数据确认。读拉流质量回调 playQualityUpdate 里的 peerToPeerDelay 与 peerToPeerPacketLostRate，丢包率明显则问题在链路；指标正常而听感依然断续，回到设备侧与本地处理上查。

存量 IPC 只有一路音频输入，能不能做双向对讲？

取决于设备是否有可用的音频输出、网关是否支持并打开了反向音频通路。任意一项缺失，喊话就没有落地条件，这部分属于设备与网关层，RTC SDK 不解决。先做一次绕开平台的现场放音测试确认。

小结

“喊话不好用”不是一个问题，是三个问题的统称。设备侧的对讲通道决定声音能不能到现场，软件侧的 3A 配置决定现场听不听得到自己，网络侧的抖动与丢包决定语音连不连得上。三段的归属方、可调空间和代价都不一样，混在一起调就是碰运气。

可执行的做法是三步：先做一次绕开平台的现场放音测试，确认通道是通的；再确认 AEC 的工作状态与当前模式；最后读链路的端到端延迟与丢包率，判断连续性问题属于谁。三步做完，你能得到一句可以直接说给团队听的话：问题在哪一段，下一步谁去改。