云值守远程喊话方案对比：GB28181 语音对讲、RTSP backchannel、RTC SDK
内容提要
远程喊话有三条路线：GB28181语音对讲、RTSP反向通道、RTC SDK，适用条件不同。喊话为单向，对讲需双向拾音回传。选型按序问四个问题：设备是否支持原生通道、是否双向、品牌是否统一、延迟要求多少。四条全通则用原生通道，否则考虑RTC。RTC音频处理在SDK侧、参数可调，但需新增网关，带来联调、运维和新故障点成本。
延伸解读
喊话与对讲：一字之差，验收两重天
文章指出，喊话是单向推送，对讲需双向拾音回传。许多项目验收时坐席听不到现场回应，根因是通道设计只有下行。选型时若笼统问“支不支持语音对讲”，容易忽略回传能力。应明确区分业务是否需要听到现场回应：加油站、停车场等需判断对方反应的场景，单向通道不够用；工地提示、驱离警告等只需传递信息的场景，单向即可。
音频处理位置决定调优空间与成本
原生通道的音频处理在设备侧，降噪、增益、回声消除效果出厂定型，平台侧难以调整。RTC 路线的音频处理在 SDK 侧，参数可逐项配置，如 AEC、AGC、ANS 及瞬态噪声抑制，但可调项多也意味着调错概率高。以即构 RTC SDK 为例，这些参数开放给开发者，但档位取舍必须在现场噪声条件下实测，不能照搬默认值。
RTC 不是延迟更低的保证，而是可观测性更强
文章澄清，RTC 路线在传输段和播放段可控性更强，端到端延迟与丢包率可直接读取，但网关转换环节可能带来开销，整体延迟未必低于原生通道。原生通道通常经平台多级转发，延迟不可控，只能实测。因此，延迟要求应作为选型的最后一个问题，而非第一个。低于 300 毫秒对话感成立，超过 500 毫秒坐席会本能重复喊话。
引入 RTC 前，先算清网关带来的三类成本
文章强调，若存量设备全部支持原生对讲通道且实测延迟达标，用原生通道就是最短路径。RTC 路线需新增网关做协议转换，带来接入联调、长期运维和一个新故障点三类成本。只有当设备不支持原生通道、原生通道只有单向、多品牌混布、延迟实测不达标这四条中至少命中一条时，RTC 才值得进入候选。选型本质是在音频质量主动权与新增网关成本之间权衡。
Q&A
远程喊话和对讲有什么区别？
喊话是单向的，平台把音频推到现场设备喇叭，现场能听到；对讲是双向的，除了下行，还要把设备侧麦克风采集的声音回传，让坐席听到现场。
云值守远程喊话选型时应该按什么顺序问哪四个问题？
按顺序问：1. 存量设备支持原生对讲通道吗？2. 原生通道是双向的，还是只有喊话没有拾音？3. 设备品牌是否统一？4. 要求的喊话延迟是多少？顺序不能乱，前一个是后一个的前提。
GB28181语音对讲、RTSP反向通道和RTC SDK在音频处理位置上有什么不同？
GB28181语音对讲和RTSP反向通道的音频处理在设备侧，平台侧拿到的是处理完的音频流，调不动；RTC SDK的音频处理在SDK侧，是一组可以逐项配置的参数。
什么情况下不需要引入RTC？
如果存量设备全部支持原生对讲通道，实测延迟又在业务容忍范围内，用原生通道就是最短路径，不必引入RTC。因为RTC路线要新增一层网关，带来接入联调、长期运维和新故障点三类成本，而收益接近于零。
RTC SDK的音频处理参数有哪些可调项？
以即构（ZEGO）的RTC SDK为例，可调项包括：回声消除（AEC）默认开启但在通话模式下自动关闭；自动增益控制（AGC）默认开启；降噪（ANS）默认开启，分激进、适度、轻度三档；瞬态噪声抑制可单独开启；以及针对空调声、键盘声、环境风声等非稳态噪声的场景化AI降噪。
喊话有回声，是通道选错了还是配置问题？
先确认回声消除发生在设备侧还是SDK侧。RTC路线里AEC默认开启但在通话模式下会关闭，这个默认值需要核对。另外iOS 14上存在外放场景的回声消除副作用，官方建议升级到iOS 15.4或以上，或改用耳麦。
