GB/T 28181 · 2016 → 2022
GB/T 28181-2022 与 2016 的区别：逐条对照
本文的变化清单依据 GB/T 28181-2022 前言中「主要技术变化」一节整理，并标注每一项对工程落地的影响。二手解读很多，判断依据应当回到标准原文。
一句话结论
2022 版不是「加了几个字段」。媒体编码、信令流程、运维命令、安全要求四块都动了，其中媒体编码和运维命令直接决定跨品牌设备能不能互通，302 注册重定向直接决定平台能不能做集群。
变化清单
| 标准位置 | 变化 | 工程上意味着什么 |
|---|---|---|
| 第 1 章 范围 | 更改范围，删除模拟接入、模数混合相关表述 | 标准聚焦纯数字联网，老模拟改造项目不再被本标准覆盖 |
| 3.1 术语 | 删除「监控点」「监控中心」等 7 个术语，更改「级联」「互联」等定义 | 级联（上下级从属）与互联（对等平台）不再混用，方案里别写错 |
| 3.2 缩略语 | 增加 PTZ | — |
| 4.3.1 协议结构图 | 媒体流通道增加 H.265、G.722.1、AAC | 这三样从厂商私有扩展变成国标能力 |
| 4.3.6 | 新增 RTP 时间戳要求 | 同一帧的 RTP 包时间戳必须相同，回放与取证时序才靠谱 |
| 5.4 / 5.6 | 更改网络传输带宽要求与视频帧率要求 | 高分辨率、大码流场景的指标口径变了 |
| 6.2、附录 C/F/G | 增加对 H.265、AAC 的支持 | 设备与平台都要在协商阶段正确声明 |
| 6.4 | 更改 SDP 协议引用 | 媒体协商参数以新引用为准 |
| 6.9、附录 A | 更改与其他系统的数据交换 | 对接第三方系统时以新版为准 |
| 6.10 | 更改信令字符集要求 | 中文设备名、告警内容乱码问题的根因在这一条 |
| 第 7 章 | 更改控制要求 | 云台、回放、对讲的控制语义更明确 |
| 第 8 章 | 更改传输、交换、控制安全性要求 | 安全从「能认证」升级为分级体系 |
| 9.1.1 | 更改注册和注销基本要求 | 注册流程细节变化，逐步设备要重新验 |
| 9.1.2.3 | 新增注册重定向 | 平台可以按节点负载把设备分到不同信令节点 |
| 9.3.1、A.2.1、A.2.3 | 更改设备控制与配置的基本要求及数据类型 | 命令字段更细，错误码更多 |
| 9.5.3、A.2.4.10~14 | 新增看守位信息查询、巡航轨迹列表查询、巡航轨迹查询、PTZ 精准状态查询、存储卡状态查询 | 这些运维动作终于有国标命令，不用再一家一套私有接口 |
一、媒体：H.265 才算「国标支持」
2016 版正文里没有 H.265 的定义。设备支持 H.265，是厂商自己在国标之外做的私有扩展，所以跨品牌对接时大概率不通，验收时也不能把它算成国标能力。
2022 版把它写进了协议结构图和附录，同时补了 G.722.1 与 AAC 音频。实际收益很直接：同画质下带宽和存储降到 H.264 的六成左右。但前提是两端都真的实现了——设备声明支持、平台能协商、封装能解析，缺一环就会退回 H.264，或者干脆点播失败。
二、RTP 时间戳：回放和取证的时序问题
4.3.6 新增的要求是：同一帧音视频对应的所有 RTP 包时间戳相同，不同帧的时间戳不同。听起来是细节，但它是回放卡顿、倍速异常、取证视频时间轴错乱的常见根因——2016 版没有这条约束，各家码流时序五花八门。
三、302 注册重定向：集群的门票
这是 2022 里对平台架构影响最大的一条。设备首次注册时，平台可以回一个 302 把它指向另一个信令节点，于是「一个 SIP 地址接一万台设备」变成「后面挂一组节点、按负载分配」。
2016 版没有这个机制，做大容量只能靠前置代理、DNS 轮询或者干脆堆单机性能。招标文件里如果写了「支持集群部署、支持万路接入」，这条通常是必答项。
四、运维命令标准化：抓拍、升级、巡航轨迹
新增的查询命令覆盖了日常运维里最费劲的几件事：看守位信息、巡航轨迹列表、巡航轨迹、PTZ 精准状态、存储卡状态。加上 9.3 对设备控制命令的细化，图像抓拍、远程升级、存储卡格式化这类动作有了标准命令可用。
对多品牌混合项目，这一条的价值是不用再为每个品牌写一套私有接口；对设备厂，价值是少维护一套 SDK。
五、字符集：中文乱码的根因
6.10 更改了信令字符集要求。工程上的表现就是：设备名叫「北门岗亭摄像机」而不是纯英文时，2016 时代经常出现乱码或截断。新版统一字符集要求后，这个问题在协议层有了明确答案——但前提是设备端也按新要求编码。
六、安全：第 8 章引用 GB 35114
2022 版把第 8 章的安全性要求整体改写，与 GB 35114 的安全体系对接，形成分级的框架：身份鉴别、信令完整性、媒体加密、访问控制、安全审计各有对应要求。
需要注意，标准给出的是能力框架，不等于每个项目都必须全量开启加密。实际开启范围取决于项目的等保等级、所在行业的联网验收要求，以及设备本身的能力。
七、跨版本对接边界
| 组合 | 能正常用 | 用不了 |
|---|---|---|
| 2016 设备 → 2022 平台 | 实时预览、基础回放、预置位与云台控制、三类基础报警、设备校时 | 302 重定向、国标抓拍、远程升级、巡航轨迹与存储卡相关命令、PTZ 精准状态、H.265 / AAC 的国标协商 |
| 2022 设备 → 2016 平台 | 同上（设备需开启 2016 兼容模式） | 同上；未开兼容模式时，2022 设备主动推送的新事件可能让老平台的解析出问题 |
结论很朴素：存量设备混接时，跨版本只能保证基础能力，高级功能必须在方案和验收范围里写清楚，别在验收现场才发现「抓拍」不在交付清单里。
八、怎么验证一台设备或平台到底是哪一版
最省事的办法是拿模拟器分别按 2016 和 2022 注册一次，对比平台返回的报文：注册响应、目录查询的字段、以及点播时 SDP 里的编码声明，差异一眼能看出来。UVP 的桌面端模拟器支持两个版本一键切换，SIP 报文可以逐条展开，专门就是为这类兼容性验证做的。
九、几个流传较广的说法，建议回原文核对
以下说法在部分二手解读里出现过，但在 2022 版前言列出的技术变化清单里找不到对应条目：
- 「2022 新增 SRT 协议支持」——前言清单与协议结构图里没有 SRT。
- 「强制 4K」——5.4 / 5.6 改的是带宽与帧率要求，没有强制分辨率指标。
- 「SIP over TLS 强制开启」——第 8 章是安全性要求的整体改写，具体是否强制取决于项目等级与设备能力，不宜直接写成「标准强制」。
写方案、编招标文件或者做兼容性声明之前，建议直接核标准正文。
常见问题
2016 的设备还能接 2022 的平台吗
能。基础能力（注册、预览、回放、云台、三类报警）正常，2022 新增的高级命令和 H.265 国标协商用不了。
平台要同时支持两个版本吗
存量项目几乎都需要。UVP-GB28181 同时支持 2016 与 2022，设备侧按实际版本接入即可。
2022 的设备接 2016 平台会怎样
建议在设备上开启 2016 兼容模式，关掉扩展事件、媒体固定 H.264。否则可能出现订阅中断或解析异常，而且现象很难定位。
新版一定比旧版好吗
不一定。2022 的能力要两端都实现了才有收益；一端不支持时，强行上 2022 只会多出一堆兼容性问题。