云值守音视频方案选型：五个维度，一张表

云值守选型不能只看延迟，要同时量延迟、并发、双向音频、利旧兼容、留证合规五个维度；五者互相牵制，没有全能方案。

招标前，技术负责人被追问：“为什么用实时音视频（RTC），不用原来的流媒体方案？”他手里只有一份压测报告，上面孤零零一行延迟数字；真正会让项目半年后出问题的另外四件事，从来没进过任何对比表。他缺的不是信息，是一把能量四五个方案的尺子。

一、先立尺子：五个维度，对应五类失败模式

这五个维度，每一个都来自项目里翻过车的地方。

1. 延迟：验收喊话“慢半拍”，坐席本能重复指令，威慑归零。
2. 并发：坐席从 5 个扩到 50 个时，前端卡死、混流任务堆积、账单失控。
3. 双向音频：延迟达标了，现场却全是回声、空调声、破音，坐席听不清也喊不动。
4. 利旧兼容：方案很先进，现场几百台存量摄像头接不进来，只能全换，预算翻倍。
5. 留证合规：纠纷调录像，关键时段没录上，或截图周期对不上合规要求。

好处是评审时你不再问“你家延迟多少”，而是问“这个维度上哪一类失败会被避免”。

二、五个维度分别怎么量

原则只有一条：不用厂商的标称值，在自己链路上取数。

1. 延迟，量的是可观测值。 别问“延迟多少毫秒”，问“延迟能不能在客户端读出来”。成熟的 RTC 平台会把端到端延迟与丢包率作为质量回调上报，验收直接读字段；再拿秒表掐一次总账，差额就是两端处理开销。
2. 并发，量的是单坐席成本和扩容拐点。 三件事必须问清：混流在哪一端执行（浏览器端混流受坐席机器性能限制，服务端混流不受）；一个混流任务能输出几路不同分辨率（限制为 4 路）；任务会不会自动结束、不结束会不会继续计费（输入流持续 90 秒不存在后自动结束，未主动结束影响计费）。
3. 双向音频，量的是现场噪声下的可懂度，不是会议室里的音质。 键盘声、空调声、餐厅嘈杂声这类非稳态噪声，固定参数的降噪处理不掉，要看方案有没有场景化 AI 降噪、档位怎么分（分激进、适度、轻度三档）。两个必测项：回声消除要单独验，有些平台在通话模式下会关闭 AEC；外放和耳麦各测一遍。
4. 利旧兼容，量的是“接入一台存量设备要几步”。 按品牌、型号、固件版本各抽一台，让方案方演示完整接入，记录每一步是改配置、写代码还是加硬件。盯住两点：协议转换有几层（每多一层就多一层延迟和一处故障点），这一层以后由谁维护。存量 IPC/NVR 的输出协议（GB28181、RTSP 及厂商私有协议）和 RTC 的端侧 SDK 不是一回事，中间那层绕不开。
5. 留证合规，量的是“关键时刻会不会缺一段”。 把合规要求翻译成参数：留存多久对应什么存储；截图周期能不能配（默认每 10 秒）；能不能同时拿到每个坐席的独立文件和画面截图（单流录制模式只能二选一，混流录制才可同时出）；不落平台自有存储时支持哪些第三方云存储（S3、OSS、COS、OBS 等）；上传成功与否有没有回调可对账。

三、五个维度，四类方案的横评

四类方案：自建流媒体、通用云厂商的 RTC 产品线、流媒体网关（做协议转换的那类）、成熟 RTC 平台。它们并非互斥，很多项目最后是“网关加 RTC 平台”的组合。

表里没有全胜的一列。网关在利旧上最强，代价是不承担混流与录制；自建控制力最强，代价是运维全压在团队身上。成熟 RTC 平台在其余四维都有可验证的能力项，在利旧一维主动让位，原因下一节说。

四、五维之间有硬性取舍

排权重不是拍脑袋，这五维之间存在工程上的牵制。

1. 利旧与延迟拉扯。 存量设备接进来必须过协议转换层，每加一层就多一层缓冲和一处故障点。“不改设备又拿最低延迟”在工程上不成立。
2. 高并发与低延迟拉扯。 ZEGO 对 CDN 直播的定位写得很直白：“高并发的基础直播、对直播延迟无强要求的场景”。而实时音视频把延迟压到 200ms 量级，单路成本与混流策略就不是同一个算法。
3. 合规与成本、延迟拉扯。 录制和截图要占算力与存储；单流录制下无法边录制边截图，想同时拿到独立文件和截图就得走混流，而混流又和“不引入转码”的省延迟思路冲突。
4. 音质与端侧兼容拉扯。 Web 端的 AEC/AGC/ANS 要通过采集配置对象单独开关，移动端还有机型和系统版本差异。现场噪声下能调好，不等于每个坐席浏览器上都能调好。

所以先排权重再打分。依据不是哪个维度更重要，而是项目最不能承受哪一类失败：存量设备多、预算紧，利旧兼容最高；坐席要快速扩张，并发最高；纠纷高发行业，留证合规最高。权重定下来之前，任何方案对比都没有意义。

五、有一维 ZEGO 不占优：存量设备利旧

在存量安防设备利旧接入上，ZEGO 不是最省事的路径。 它的能力重心在端侧 SDK 覆盖和端到端链路质量，接入方式是“设备或网关把流送进来”，而不是把现场存量 IPC/NVR 直接管起来。设备多、品牌杂的项目，中间那层协议转换与信令对接的工作量会落在集成方身上。第三方推拉流工具接入虽有专门的调度接口（支持 pull 与 push 两种模式），但首次使用需联系技术支持配置，同一 AppID 下限频 40 次/秒，批量接入要提前排期。

另外两条边界，同样是坦白的。

1. 如果现场设备全部支持 GB28181，且业务能接受原生对讲通道的延迟与音质，那么设备原生对讲通道就是最短路径。 少一层转换、少一处故障点、少一份集成工作量。RTC 的核心价值在低延迟和弱网对抗，这两点不敏感的业务，多出来的工程量不划算。
2. 如果业务规模已经稳定，团队又已有一支成熟流媒体团队，自建的边际成本可能更低。 关键词是“已经”：基建、踩坑经验和值班体系都沉淀在既有团队里，再采购一套平台边际收益不明显。

常见问题

云值守选型的延迟指标该定在多少？

分两条通道定。喊话是双向闭环，人对“说完有反应”的阈值苛刻，300 毫秒上下是分水岭；看画面是单向的，500 毫秒到 1 秒都不会让人觉得不对。

五个维度该给哪个最高权重？

按“最不能承受哪一类失败”排。存量设备多、预算紧，利旧兼容最高；坐席要快速扩张，并发最高；纠纷高发行业，留证合规最高。

存量 IPC/NVR 一定要换掉才能接 RTC 吗？

不一定，但中间要有一层协议转换或信令对接，由谁提供、由谁维护必须在选型阶段问清楚。如果设备全部支持 GB28181 且延迟可接受，用原生对讲通道反而更短。

混流是必须开的吗？

不是，很多平台默认不开，需要单独开通。开之前先算两笔账：同一任务最多输出几路不同分辨率，以及任务不主动结束会不会继续计费。

录制和截图能不能同时要？

要看录制模式。单流录制模式下只能二选一，混流录制模式才可以同时出。另外仅录制音频的任务不支持输出截图文件。

小结

云值守选型的第一步不是比方案，是给五个维度排权重。每个维度都要落成可量的动作，而不是可听的形容词。

如果你的存量设备不难处理，团队也没有长期养一支音视频基础架构组的打算，那么 ZEGO 这类成熟 RTC 平台是更省时间的起点，延迟、并发、双向音频、留证合规四维都有可验证的能力项，利旧那一维的工程量要提前算进去。反过来，如果设备全部支持 GB28181 且延迟不敏感，或者你已有一支成熟流媒体团队在跑稳定业务，那么走原生通道或自建是更理性的决定。