GB/T 28181 是公共安全视频监控联网领域最核心的技术标准。随着 GB/T 28181-2022 于 2023 年正式实施，行业在设备接入、平台级联、媒体传输、安全认证等方面都面临着一次"体系级"的升级。
很多工程师以为新版本只是"加入 H.265、补充 AAC"这种小变动。
实际上，从编码封装到传输协商，从安全认证到业务字段，新标准带来的影响远比想象中更深。
本文从工程实现与协议栈升级的角度，系统梳理 2016 与 2022 版本之间的关键差异，便于开发者在实际编码、调试、平台接入中少走弯路。
一、视频编码：H.265 从"私有扩展"正式走向标准化
1. 2016 版的行业现状：各家自定义，互通困难
GB/T 28181-2016 并未正式收录 H.265/HEVC。
各厂家为了实现 4K/超高清传输，普遍采用以下私有方式：
-
在 PS 流中使用自己定义的 stream_type；
-
在 PES/PS Header 中加入私有扩展头；
-
平台端解析依赖"经验规则"和特征判断。
因此，即便设备都"支持 H.265 国标"，不同厂家的 PS 流仍然存在大量互通问题，解析端常常需要：
-
根据魔数猜格式；
-
为不同设备写多套兼容逻辑。
2. 2022 版的关键升级：H.265/HEVC 标准化纳入
GB/T 28181-2022 正式收录 H.265/HEVC 相关能力，对视频编码类型、PS 流封装、stream_type 映射关系进行了清晰定义。
其中最重要的包括：
-
H.264 使用标准 stream_type（例如 0x1B）
-
H.265/HEVC 使用标准 stream_type（例如 0x24）
-
音频编码（AAC、G.711A、G.711U、G.722.1 等）也明确了统一的取值方案
3. 工程影响
设备侧/SDK 必须升级：
-
PS 封装逻辑（PSM、PS Header、stream_type）
-
媒体能力协商（SDP 中明确 H.264/H.265 支持）
-
解析侧严格按照标准解析，不再依赖私有头判断格式
总结：
2016 版的 H.265 靠"约定俗成"，2022 版让它成为真正意义上的标准能力。
二、传输协议：TCP 主被动协商从"模糊"变成"规范"
1. 2016 版的问题：TCP 模式实现混乱
虽然 2016 版支持 RTP over TCP，但未明确：
-
谁是主动连接方？
-
谁负责监听？
-
如何穿透 NAT？
-
多平台之间如何协商 TCP 角色？
结果导致行业中长期存在：
-
双方都等待对方连（TCP 建不起来）
-
内网设备无法被公网平台主动连
-
不同厂商实现方式不一致，互通代价高
2. 2022 版解决方案：基于 a=setup 的 TCP 角色协商
GB/T 28181-2022 引入了更完善的 SDP 协商机制，包括：
-
a=setup:active（本端主动连接） -
a=setup:passive（本端被动监听） -
a=setup:actpass（双方都可以，根据对端决定）
这个机制极其关键，因为：
私网设备 → 公网平台的 TCP 传输终于有了标准化表达方式。
设备位于私网时，只需：
-
SDP 上声明
setup:active -
主动反向连接公网平台
即可实现稳定的 TCP 建立，大幅简化 NAT 场景。
3. 工程影响
SIP/SDP 模块必须：
-
正确解析
a=setup -
根据协商结果选择主动/被动连接
-
为 NAT 场景优先使用 active→passive 模式
-
避免因协商不一致造成 TCP 无法建立
三、音频编码：AAC 与多采样率成为标准化能力
2016 版中音频以 G.711 为主，AAC 虽被业界广泛使用，但标准化描述不完整。
2022 版的改进包括：
-
AAC 明确纳入规范
-
支持多采样率（8k / 16k / 32k / 44.1k / 48k 等）
-
PS 中 AAC 的 stream_type 明确
-
SDP 对 AAC 的参数格式（fmtp/config/profile-level-id）提出更严格要求
工程注意点：
-
AAC 在 SDP 中必须携带完整的
config（AudioSpecificConfig） -
ADTS 头的处理需符合 RTP/PS 封装要求
-
平台解析对
rtpmap和fmtp更为敏感
一句话：
2022 版让 AAC 从"也能用"变成"应当规范使用"。
四、安全体系：认证算法与加密要求全面增强
这是 2022 版中最具"时代意义"的部分。
标准增加了更严谨的安全要求，并与更高层的安全规范保持一致，使 28181 的链路安全、认证机制更接近现代化网络系统。
1. SIP 认证从单一 MD5 → 支持更高强度摘要算法
2016 版主要依赖 MD5。
2022 版增强为：
-
支持 SHA-256 等更安全的摘要算法
-
允许平台根据风险等级，限制或禁用 MD5
-
在安全等级较高的行业部署中，倾向直接要求 SHA-256
工程后果：
如果设备/SDK 的 SIP 协议栈只实现了 MD5，那么：
-
当平台要求使用 SHA-256 时会直接认证失败
-
即使平台短期允许兼容 MD5，也很可能在升级后逐步禁用
正确做法是：
-
同时实现 MD5 + SHA-256
-
根据平台挑战值自动判断使用哪个算法
2. 支持 TLS 加密信令链路
2022 标准明确支持：
-
SIP over TLS
-
更高等级场景下保护信令传输安全
这对应行业从"能通"向"安全可控"阶段的转变。
注意：
TLS 并非强制，但在政府/重点单位等高安全场景中，平台会要求启用。
3. 安全要求的总体趋势
可以归纳为：
平台更安全、更规范；设备需具备更强的安全适配能力。
五、业务层细节：坐标系、域别名、抓拍传输等全面规范化
2022 版不仅调整了协议层，还明确了许多"业务相关的工程约束"。
1. 坐标系统一为 CGCS2000
平台侧在地图展示、轨迹分析中要求使用国家统一坐标系。
这意味着设备侧必须按照以下逻辑：
-
若 GPS 原始数据是 WGS-84 → 转 CGCS2000
-
若来自 Android/iOS → 通常是 GCJ-02（火星坐标）→ 也必须转 CGCS2000
-
未转换将导致地图点位偏移明显（偏十几公里很常见）
2. 多级级联中的域别名与业务组织标识更清晰
新版标准进一步明确：
-
域编码
-
业务分组
-
组织管理结构
-
多域、多级级联的设备标识映射规则
对 SDK / 平台实现来说：
-
必须正确处理设备 ID、父级 ID、域别名等字段
-
需要维护跨域映射表
-
多平台级联时必须确保设备唯一性
3. 抓拍图片上传统一转向 HTTP/HTTPS
过去行业存在：
-
FTP 上传
-
私有 TCP 协议上传
-
HTTP/HTTPS 混用
2022 版规范要求逐步统一基于 HTTP/HTTPS 的接口模式：
-
更易与 AI 识别平台对接
-
更易跨网传输
-
更易实现鉴权与安全审计
六、从 2016 迁移到 2022：工程侧需要改哪些模块？
下图即"迁移清单"：
1. 协议栈层（SIP/SDP）
-
支持 SHA-256 鉴权
-
支持 TCP active/passive 协商
-
支持 actpass 模式与角色切换
-
可选支持 SIP over TLS
-
更严格的 SDP 生成与解析（编码能力更细化）
2. 媒体层（PS 封装 / RTP 打包）
-
使用标准 stream_type（尤其是 H.265 / AAC）
-
支持标准 PS Map
-
SDP 中正确表达 H.265/H.264/AAC
-
AAC 的 config 字段解析
-
RTP 打包更符合标准边界要求
3. 业务层
-
坐标系转换 CGCS2000
-
设备组织结构、域编码支持
-
抓拍/报警附件统一使用 HTTP/HTTPS 上传
-
设备目录树结构按新规范组织
七、工程实践：SDK 的"自适应策略"如何解决碎片化标准问题？
理想的 GB28181 SDK 应具备：
1. 自动识别平台版本
根据 SIP/SDP 握手阶段的字段差异判断对端是 2016 还是 2022 版本。
2. 智能编码能力协商
优先尝试 H.265 + AAC，若平台不支持则自动回落为 H.264 + G.711。
3. 主被动 TCP 自动切换
根据 SDP 的属性自动选择 active/passive/actpass 模式。
4. 安全能力可配置
MD5 与 SHA-256 并存，根据平台要求自动选择。
八、总结：GB/T 28181-2022 是一次"体系升级"，不是"小改小修"
对比 2016 版，新版标准的核心价值包括：
-
编码封装更统一（H.265/AAC 正式标准化）
-
媒体传输更可控（TCP 角色清晰、NAT 场景友好）
-
安全性更现代化（SHA-256、TLS）
-
业务字段更标准（CGCS2000、域别名、HTTP 上传）
对于开发者而言，迁移意味着：
不仅要改 SDP，而是要整体升级协议栈、媒体层、安全层和业务层逻辑。
Android平台GB28181接入模块技术接入说明
https://daniusdk.blog.csdn.net/article/details/128377797📎 CSDN官方博客：音视频牛哥-CSDN博客