做安防集成、融合通信或应急指挥项目的人，几乎每天都会碰到三个词：RTSP、ONVIF、GB/T 28181。
刚接触时很容易迷糊：它们不都是用来“看监控画面”的吗？为什么有的设备只要给一个地址就能拉流，有的却必须先配置国标编码才能上云？
其实这三者不是“谁替代谁”的竞争关系，而是同一条视频链路里分工不同的三个角色：一个负责把画面搬过来，一个负责把不同厂家的设备统一管起来，一个负责把画面跨过公网送到上级平台。下面按这三个角色分别说清楚，最后给出一张对比表和一套选型顺序。
RTSP：只负责搬运画面的极简协议
RTSP（Real Time Streaming Protocol，实时流传输协议）由 IETF 定义在 RFC 2326（1.0 版）和 RFC 7826（2.0 版）中，本质上是一个“网络遥控器”。
它默认使用 554 端口，只负责发送播放、暂停、停止等控制指令；真正的音视频数据包交给底层的 RTP 协议搬运。这种“控制与媒体分离”的设计，让它足够轻，也足够快。
核心特点：轻量级、延迟极低（局域网内通常在 1～2 秒甚至更低），几乎所有网络摄像机都原生支持。
主要局限：它只管“拉流看画面”，不管设备发现，也不管云台转动；而且采用客户端主动拉流的模式，一旦摄像机位于路由器或 4G/5G 内网的 NAT 后面，外网平台就很难直接连上。
另外，现代浏览器已经不能直接播放 RTSP，通常需要流媒体服务器把它转成 WebRTC、HTTP-FLV 或 HLS 才能在网页里播放。这两个问题我们在RTSP 拉流与 GB/T 28181 拉流的区别和视频接入网关的 WebRTC 能力中分别展开过。
典型场景：局域网 NVR 录像、AI 算法抽帧取流、VLC 播放器单路画面预览。
ONVIF：打破品牌墙的“局域网管家”
早期不同厂家的摄像机互不兼容，海康的录像机接不上大华的球机，项目里经常要为“混品牌”单独做适配。ONVIF 就是在这个背景下出现的开放接口标准，充当多品牌设备之间的“翻译官”。
需要注意的是：ONVIF 本身并不传输视频流。它通过 HTTP/SOAP 协议统一了设备发现、参数配置、云台控制（PTZ）与告警事件上报；真正拉取画面时，底层调用的依然是 RTSP。
常用的三个 Profile 规范
- Profile S：覆盖早期的基础音视频流与云台控制。ONVIF 已宣布逐步停止支持，新项目不建议再按 S 规范选型。
- Profile T：当前主流规范，支持 H.264/H.265 编码、图像参数调节与移动侦测告警。
- Profile M：面向 AI 智能分析，支持结构化元数据与目标识别事件传输。
主要局限：依赖局域网组播发现，同样不擅长跨公网 NAT 穿透；跨品牌混接时，个别参数（例如对焦、预置位）仍可能因为厂家实现对不齐而需要单独调试。
典型场景：园区、工厂、写字楼等局域网环境下，把多品牌摄像机混合接入同一套 NVR 或综合管理平台（VMS）。
GB/T 28181：跨网联动的“国家标准体系”
面对“雪亮工程”、平安城市、应急指挥这类跨省跨市、成千上万路设备的联网需求，只在局域网里好用的协议显然不够用。
我国为此制定了国家标准 GB/T 28181，现行最新版为 GB/T 28181-2022（替代 2016 版，于 2023 年 7 月正式实施）。
它最关键的变化是把连接方向反转了：信令层采用电信级的 SIP 协议，由前端设备或下级平台主动向上级公网平台注册，天然绕开了内网穿透的难题；媒体层采用基于 RTP 封装的 PS 流向上级推送，同时支持上下级平台级联、历史录像回放与语音对讲。
换句话说，RTSP 是“我去找设备要画面”，GB/T 28181 是“设备主动把画面送到平台”。方向一变，公网部署、权限管理和平台级联就都顺了。
典型场景：4G/5G 移动布控球、执法记录仪公网回传、无人机图传接入指挥中心、跨地域集团化视频上云。
一张表看清三者的差别
把前面三节放在一起，区别主要集中在定位、信令机制和跨网能力上：
| 协议 | 核心定位 | 信令与传输 | 跨网能力 | 典型应用 |
|---|---|---|---|---|
| RTSP | 音视频拉流协议 | RTSP 控制 + RTP 传输，554 端口 | 弱，依赖客户端主动连接 | 局域网 NVR 取流、AI 抽帧、单路预览 |
| ONVIF | 局域网设备管理标准 | HTTP/SOAP 控制 + RTSP 取流 | 弱，依赖局域网组播发现 | 园区、厂区多品牌摄像机混合接入 VMS |
| GB/T 28181 | 跨网视频联网国标 | SIP 信令 + RTP/PS 流主动推送 | 强，设备主动向平台注册 | 公安天网、应急指挥、4G/5G 布控球、无人机回传 |
需要说明的是，表格里的“强”和“弱”只针对跨网能力。如果项目本来就集中在一个局域网里，为了跨网专门去上国标平台，反而会增加编目、注册和运维的负担。
实际项目里，它们通常是一起用的
真实项目中很少有“只用一个协议”的情况，更常见的组合是这样：
- 前端摄像机用 ONVIF 被平台发现并纳管，配好编码参数、云台预置位和告警规则；
- 平台取流时走 RTSP，拿到低延迟的原始码流做录像、AI 分析和本地上屏；
- 需要跨公网共享时，再由平台或接入网关用 GB/T 28181 注册到上级平台，完成级联、回放和对讲。
这也是视频接入网关、流媒体服务器存在的意义：把三种接入方式收敛到一台设备上，再按业务需要转换成 WebRTC、HTTP-FLV、HLS 等格式分发出去。协议之间的转换关系，可以参考推流、拉流、转发、转码分别是什么意思和视频接入、转发与转码的概念区分。
选型顺序：三句话定协议
- 只要看画面、图省事，局域网直接拉 RTSP；
- 多品牌混接、还要转云台，局域网优选 ONVIF；
- 要上公网云平台、做跨级联动与应急回传，必须上 GB/T 28181。
判断顺序建议这样走：先看摄像机在哪里（集中在局域网，还是分散在公网），再看谁管谁（本地 NVR，还是上级平台统一编目），最后才看带宽和延迟要求。这三步定下来，协议基本也就定了。
三个常见问题
RTSP 能在浏览器里直接播放吗？
不能。浏览器不提供 RTSP 播放能力，需要服务端把码流转成 WebRTC、HTTP-FLV 或 HLS。对延迟敏感选 WebRTC 或 HTTP-FLV，对兼容性和分发规模敏感选 HLS。
ONVIF 能不能跨公网接入？
标准本身面向局域网，跨公网要靠端口映射或 VPN，稳定性和安全性都不理想。跨公网的项目，优先选择设备侧支持 GB/T 28181 主动注册的方案。
上了 GB/T 28181 是不是就不需要 RTSP 了？
不是。国标解决的是注册、编目、级联和跨网传输，平台内部取流、AI 分析和本地上屏依然大量使用 RTSP。两者是配合关系，不是替代关系。
小结
RTSP 负责搬运画面，ONVIF 负责统一纳管，GB/T 28181 负责跨网联网。把这三个角色分清楚，设备选型、平台对接和现场排障都会顺畅很多。
真正的难点从来不是记住协议名字，而是判断清楚这段视频要经过几个网、由谁来管、又要在哪些屏幕上出现。
相关产品与方案
如果项目里同时存在监控、无人机、会议终端和上级平台，可以先用一台接入网关把协议收敛起来：
- 视频接入网关 VGW1000：支持 GB/T 28181、RTSP、ONVIF 等监控协议接入，可输出 RTSP、GB/T 28181、HTTP-FLV、HLS、WebRTC 等格式，具备 4 路 1080P 硬件转码能力，适合解决多协议互通和浏览器播放问题。
- 视频推流网关：面向现场无人机、布控球和记录仪的回传，兼容 RTMP、RTSP、GB/T 28181、WebRTC 等接入与输出方式，适合 4G/5G 和卫星链路。
- 视频转码服务器 PRN1600：支持 RTSP、RTMP、HLS、WebRTC、GB/T 28181 等协议互转，可并发处理 16 路 1080P，用于把不同厂家的旧码流统一成平台需要的格式。
联网规模较大的项目，可以先看视频监控联网解决方案，再确定接入路数、输出格式和上级平台对接方式。