在很多项目中，GB28181常被简单理解为“设备通过SIP注册，再向平台发送一路PS流”。这种理解能够解释最基础的点播流程，却无法解释为什么同样标称支持GB28181的两个系统，仍会在注册认证、目录查询、TCP媒体连接、H.265封装、语音广播、历史回放等环节出现大量兼容问题。

从大牛直播SDK（SmartMediaKit）的实践视角看，GB28181并不是一个孤立的流媒体协议，而是一套建立在TCP/IP、SIP、SDP、RTP、PS、XML以及多种音视频编码标准之上的视频资源联网体系。它解决的核心问题也不仅是“视频怎么传”，而是设备如何被发现、如何被统一编码和管理、平台如何按需调度媒体、控制指令如何到达终端，以及不同厂商、不同层级、不同网络中的视频资源如何形成一个可运营的系统。

现行版本为GB/T 28181—2022，于2022年12月30日发布、2023年7月1日实施；GB/T 28181—2016已经废止，但由于存量平台数量庞大，工程上仍必须长期兼容2016和2022两个版本。国家标准全文公开系统

一、GB28181的本质：视频资源联网标准，而不是单一传输协议

GB28181的价值可以概括为五个层次。

第一层是资源身份。标准为设备、通道、平台、行政区域、业务分组和虚拟组织建立统一编码及目录组织方式，使跨区域、跨部门和跨厂商的视频资源能够被唯一标识。

第二层是设备在线管理。设备通过SIP完成注册、鉴权、注册刷新和注销，通过心跳维持在线状态。平台不需要一直接收视频，也能够知道设备是否在线、具备哪些通道和能力。

第三层是业务控制。平台可以查询目录、设备信息和设备状态，也可以下发云台控制、预置位、录像、抓拍、语音广播、设备配置等指令。

第四层是媒体会话调度。平台需要实时视频时，通过INVITE和SDP与设备协商媒体地址、端口、编码和传输方式；会话结束时通过BYE释放资源。

第五层才是媒体传输。编码后的音视频经过PS或ES封装，再通过RTP over UDP或RTP over TCP发送。

因此，GB28181与RTSP、RTMP、SRT、WHIP/WHEP并不处于完全相同的产品维度。后几者更多解决媒体发布、订阅或者可靠传输问题，而GB28181同时包含资源目录、身份认证、设备控制、事件订阅、历史录像、位置上报和平台级联。

这也是为什么一个成熟的GB28181设备接入模块，不能只是“实现一个SIP客户端，再调用FFmpeg发送PS流”。

二、GB28181背后的RFC与标准体系

GB28181没有重新发明互联网协议栈，而是按照视频监控业务需要，对多项IETF、ITU-T和ISO/IEC标准进行组合和约束。

层次	主要标准	在GB28181中的作用
会话信令	RFC 3261	SIP注册、点播、会话建立、释放及事务管理
独立消息	RFC 3428	使用SIP MESSAGE承载设备查询、控制、应答和通知
事件订阅	RFC 3265、RFC 6665	SUBSCRIBE/NOTIFY订阅目录、报警、位置、PTZ状态等事件
会话描述	RFC 4566	SDP描述媒体地址、端口、格式、时间范围和传输方式
实时传输	RFC 3550、RFC 3551	RTP/RTCP报文、序列号、时间戳、SSRC及负载类型
PS over RTP	RFC 2250、ISO/IEC 13818-1	将音视频复用为PS，再承载于RTP
TCP承载	RFC 4571	在面向连接的TCP通道中为RTP/RTCP增加长度分帧
回放控制	RFC 2976	通过SIP INFO承载MANSRTSP播放控制命令
H.264 ES传输	RFC 3984	H.264基本流的RTP负载格式
H.265 ES传输	RFC 7798	HEVC/H.265的RTP负载格式
AAC ES传输	RFC 3640	MPEG-4 AAC的RTP负载格式
第三方呼叫控制	RFC 3725	平台参与的第三方会话控制模型
时间同步	RFC 2030等	设备校时和时间基准
视频编码	ITU-T H.264、H.265	视频码流语法、档次和级别
音频编码	ITU-T G.711、G.722.1等	语音广播、对讲和视音频传输
安全扩展	GB 35114	较高安全等级下的身份认证、加密和完整性保护

这里有一个容易忽视的工程原则：RFC版本会继续演进，但国标符合性应以GB/T 28181所引用和约束的版本为基准。

例如RFC 3984后来被RFC 6184替代，RFC 3265也被RFC 6665更新，但对接一个具体国标平台时，不能因为存在更新的RFC，就擅自改变对端期待的字段、状态机或者负载格式。互联网标准的“最新版”与国标工程中的“兼容版本”，并不总是同一个概念。

三、信令层：真正困难的是状态机，而不是拼接SIP文本

1. 注册与认证

设备通常通过REGISTER向平台登记自己的SIP URI和可达地址。平台可返回401 Unauthorized，要求设备携带摘要认证信息重新注册；成功后返回200 OK。

GB/T 28181—2022增加注册重定向能力。设备可先注册到统一入口，由入口返回302及实际SIP节点地址，从而支持平台集群的负载均衡和故障转移。这使设备端不能再把平台地址简单看成永远不变的单一IP。

2. 心跳与目录

心跳通常通过SIP MESSAGE承载MANSCDP XML消息。它不仅是“定时发一个包”，还参与在线状态判断。心跳间隔、超时次数、网络切换、前后台状态和平台响应都需要形成明确的设备状态机。

目录查询同样通过MESSAGE完成，但SIP层的200 OK只表示“消息已经收到”，并不等于目录业务已经完成。设备还需要发送一个新的MESSAGE作为业务应答，平台再对该MESSAGE回复200 OK。

因此，一个目录查询可能同时出现：

1. 平台发送MESSAGE查询；
2. 设备回复SIP 200 OK；
3. 设备发送MESSAGE目录应答；
4. 平台回复SIP 200 OK。

MANSCDP中的SN用于关联业务请求和业务响应。若将SIP事务成功与业务执行成功混为一谈，就会出现“抓包显示全部200 OK，但平台仍然没有目录”的典型问题。

3. 订阅与主动通知

目录变化、移动位置、报警和PTZ位置等持续性事件，不适合由平台高频轮询，因此GB28181使用SUBSCRIBE/NOTIFY模型。

订阅关系需要管理有效期、刷新、终止、Dialog状态和网络异常恢复。设备报警、状态异常等信息还可以不经过订阅，直接通过MESSAGE主动上报。

对于Android和鸿蒙NEXT移动终端，这种机制尤其重要：人员位置、车辆位置、巡检轨迹和设备状态都是动态信息，平台需要得到的是持续事件流，而不是一张静态设备表。

四、媒体会话：INVITE只是起点，SDP决定整条链路

平台发起实时点播时，通过SIP INVITE携带SDP。SDP主要描述：

• 媒体接收地址和端口；
• RTP over UDP还是RTP over TCP；
• TCP连接的主动方和被动方；
• PS还是音视频ES；
• H.264、H.265、G.711A、AAC等编码格式；
• Payload Type；
• SSRC及媒体流标识；
• 实时点播、历史回放、文件下载或者语音对讲；
• 历史媒体的开始时间和结束时间；
• 主码流、子码流等码流编号。

设备返回200 OK和自己的SDP后，平台发送ACK，媒体传输才进入稳定阶段。会话结束时，任意一方可通过BYE终止。

这里必须区分三个概念：

• SIP信令传输使用UDP或TCP；
• RTP媒体传输也可以使用UDP或TCP；
• SIP使用TCP并不代表媒体自动使用TCP。

另外，SDP中的active和passive描述的是谁发起TCP连接，不代表谁发送媒体。媒体方向与TCP建连方向是两个不同维度。很多跨平台对接失败，就源于把“媒体发送方”等同于“TCP客户端”。

UDP与TCP如何选择

RTP over UDP路径短、实时性好，不会因为丢包重传引入队头阻塞，适合网络质量较好的局域网和低延迟场景；但公网、移动网络和复杂防火墙环境下，更容易出现丢包、端口受限和NAT映射失效。

RTP over TCP能够利用可靠字节流传输，在复杂网络中通常更容易建立稳定链路，但必须依据RFC 4571进行RTP分帧，并处理粘包、拆包、重连、发送阻塞和积压控制。TCP保证的是有序可靠到达，并不天然保证实时性。如果发送队列持续增长，画面可能越来越“稳定”，延迟却越来越大。

成熟实现需要根据链路状态限制缓存，必要时主动丢弃过期媒体数据，而不是无限等待TCP将所有历史帧发送出去。

五、PS、RTP、时间戳：媒体互通的核心细节

GB28181中最常见的媒体路径是：

编码器输出H.264/H.265和音频数据，复用为MPEG-PS，再将PS切分到多个RTP包中发送。

PS层需要正确生成Pack Header、System Header、Program Stream Map和PES。RTP层还要正确处理：

• 序列号连续性；
• 90kHz视频时间戳；
• SSRC与会话的一致性；
• Payload Type；
• RTP分片边界；
• Marker位策略；
• 音视频时间基准换算；
• GOP开始与关键帧参数集；
• TCP承载时的长度前缀。

2022版正式加强了H.265和AAC支持：H.265在PSM中的流类型为0x24，AAC为0x0F；同时扩展了SDP中的分辨率、音频参数和码流编号描述。H.265的RTP负载格式关联RFC 7798，AAC关联RFC 3640。

​

但“支持H.265”绝不只是把SDP里的H264改成H265。还涉及：

• VPS、SPS、PPS的提取与发送；
• IRAP关键帧识别；
• PS Program Stream Map流类型；
• 对端平台是否真的具备H.265解码能力；
• 设备硬编码器输出格式是否符合封装要求；
• 参数集改变后的会话处理；
• 不同平台对Payload Type和SDP属性的兼容差异。

这也是拥有成熟音视频内核的重要性：GB28181接入的下半部分，本质上仍然是一个完整的实时音视频工程。

六、2022版的意义：从“视频联网”走向“设备运营”

相较2016版，GB/T 28181—2022的变化不只是增加两个编码格式，而是开始补齐大规模设备运营能力。

注册重定向

通过302将设备调度到不同SIP节点，为平台集群、负载均衡和故障转移提供标准化基础。

H.265与AAC

面向高清和更高质量音频场景，补充编码、封装、RTP负载及SDP描述要求。

图像抓拍

平台可以下发抓拍参数，设备完成抓拍和上传后，再发送完成通知。值得注意的是，标准定义了抓拍控制及结果通知，但没有完全限定图片上传的HTTP鉴权和存储接口，项目仍需约定URL、Token、SessionID等细节。

存储卡与录像配置

增加存储卡状态查询、格式化，以及录像计划、预录、延时录像等配置，为前端存储运维提供更统一的接口。

云台与目标跟踪

增加更精确的PTZ位置控制、位置查询、状态订阅、巡航轨迹和目标跟踪能力，使平台不再局限于传统的上下左右控制。

多路径级联

面对平台网状互联和多上级汇聚，标准增加路径记录和优选机制。其价值在于：同一资源存在多条访问路径时，平台能够识别路径、选择路径，并在局部故障时切换。

协议版本标识

2022版通过X-GB-Ver标识协议版本，其中1.0、2.0、3.0分别对应2011、2016和2022版。现实中，平台通常需要兼容多个版本，不能假设所有设备会同步升级。

设备软件升级

标准增加升级命令和结果通知，但升级包格式、下载服务和具体升级策略仍由厂商系统负责。这反映出GB28181的边界：它负责跨厂商业务协同，但不会替代设备自身的完整管理平台。

七、Android平台：让通用智能终端成为国标前端设备

传统GB28181前端主要是IPC、NVR和固定式监控设备。Android工业终端的加入，将设备形态扩展到了执法记录仪、智能安全帽、车载终端、无人机地面站、巡检终端、UVC摄像头网关和移动布控设备。

SmartMediaKit的Android平台SmartGBD支持终端以国标前端设备形态接入GB/T 28181—2016/2022平台，覆盖注册、心跳、目录、点播、位置、语音、抓拍、历史视音频和云台控制等流程。SmartMediaKit Android GB28181接入SDK

​

其价值不仅是支持手机摄像头，而是建立了多源媒体适配能力：

• 接入Camera2、屏幕、Unity等编码前YUV/RGB数据；
• 接入外部H.264/H.265、AAC等编码后数据；
• 接入无人机、采集卡和行业硬件输出的码流；
• 拉取IPC的RTSP/RTMP流，再转换接入GB28181平台；
• 与本地录像、RTMP推送、RTSP服务等模块组合运行。

这使Android终端既可以作为采集设备，也可以作为协议网关。例如，一个不支持国标的RTSP摄像头，可由Android终端拉流后，以标准目录资源的方式注册到上级GB28181平台。

Android版本的工程优势主要体现在设备生态成熟、硬件种类丰富、摄像头与外设接入方便，以及适合存量行业终端改造。但Android设备型号碎片化明显，不同厂商在硬编码器、音频采集、后台运行和网络策略方面存在差异，SDK必须把这些差异隔离在媒体内核和设备适配层，而不能暴露给上层业务。

八、鸿蒙NEXT：国标接入进入原生国产终端体系

鸿蒙NEXT的价值并不是简单复制一个Android版本，而是让国标视频能力进入新的原生应用和国产化终端生态。

SmartMediaKit鸿蒙NEXT GB28181设备接入模块采用ArkTS、NAPI与Native C/C++分层架构：ArkTS负责业务界面、权限、参数和状态管理；NAPI负责跨语言调用及事件回调；Native内核负责SIP信令、采集编码、PS封装、RTP发送、录像和资源生命周期管理。SmartMediaKit鸿蒙NEXT GB28181接入SDK

​

当前方案可覆盖：

• GB/T 28181—2016、2022平台接入；
• 注册、注册刷新、注销和心跳保活；
• 设备目录查询应答；
• 平台按需点播和INVITE会话协商；
• 屏幕及麦克风数据接入；
• H.264/H.265视频编码；
• G.711A/AAC音频对接；
• 音视频PS封装；
• RTP over UDP与RTP over TCP被动模式；
• MobilePosition位置上报；
• 语音广播及平台语音播放；
• 状态反馈、事件回调和本地MP4录像；
• 与RTMP推流、轻量级RTSP服务组合运行。

其中，“按需启动”对于鸿蒙NEXT移动终端尤其重要。设备未被平台点播时，可以只保持注册和心跳，不持续开启采集、编码和媒体发送；收到INVITE后再建立媒体链路。这样既符合GB28181的平台调度模型，也能减少空闲功耗、发热和带宽占用。

鸿蒙NEXT版本的技术难点主要集中在ArkTS与Native线程边界、异步回调生命周期、Surface及媒体资源管理、应用前后台切换、权限变化和网络切换。真正可用的SDK必须把这些平台问题与GB28181协议状态机统一处理，否则上层应用会同时面对SIP状态、媒体状态和系统生命周期三套复杂逻辑。

九、Android与鸿蒙NEXT并不是两套孤立实现

维度	Android SmartGBD	鸿蒙NEXT SmartGBD
主要终端	存量行业设备、执法仪、安全帽、车载、网关	国产化移动终端、政企终端、巡检和指挥设备
应用接入层	Java/Kotlin与JNI	ArkTS、NAPI与Native C/C++
数据源特点	摄像头、屏幕、UVC、外部编码数据、RTSP/RTMP	屏幕、麦克风及原生媒体能力，逐步扩展行业数据源
协议能力	功能覆盖较完整，适合复杂项目	覆盖设备接入核心链路，强调原生鸿蒙集成
共同内核价值	编码、PS封装、RTP、录像、协议状态管理	复用成熟Native音视频与国标能力
共同目标	将终端抽象成标准国标设备	将终端纳入既有视频监管和指挥体系

跨平台SDK真正应该统一的，不是UI和接口名称，而是协议语义：相同的注册状态、相同的会话模型、相同的时间戳策略、相同的PS/RTP封装逻辑、相同的错误分类，以及可对照的事件回调。

只有底层语义统一，Android与鸿蒙NEXT终端接入同一平台时，平台侧才不会面对两套行为完全不同的“国标设备”。

十、SmartMediaKit的技术优势：从协议符合走向工程可用

1. 完整国标链路，而非单点功能

注册成功只是第一步。目录、点播、媒体传输、位置、语音、录像、抓拍和会话释放共同决定一个设备能否真正进入业务系统。

2. 信令内核与音视频内核一体化

很多方案能够处理SIP，却缺少稳定的采集、编码、PS封装和RTP发送；另一些方案具备推流能力，却缺少完整国标状态机。SmartMediaKit的优势在于两部分能够在同一套SDK体系内协同。

3. 编码前、编码后与网络流统一接入

业务可以输入原始YUV/PCM，也可以输入编码后的H.264/H.265/AAC，还可以把RTSP/RTMP网络流转换为国标资源。这种数据源抽象决定了SDK能否覆盖摄像头终端、无人机、车载系统和协议网关等不同产品。

4. 按需采集与资源控制

平台点播时才开启采集、编码和发送，会话结束及时释放资源。对于移动终端，这不仅是性能优化，更是电量、温度、隐私和系统稳定性的基本要求。

5. 多链路协同

GB28181负责接入上级监管平台，RTSP负责局域网分发，RTMP可用于互联网直播，本地录像负责证据留存。不同协议不是互相取代，而是服务于不同网络边界和业务目标。

十一、真正的互联互通，发生在规范之外

GB28181建立了统一框架，但“符合标准”不必然等于“接入所有平台都一次成功”。工程现场仍然需要面对：

• 2016与2022版长期并存；
• 部分平台没有正确识别X-GB-Ver；
• SIP头域大小写、空格和URI格式差异；
• 200 OK与业务应答被错误混用；
• TCP主动、被动角色理解不一致；
• SSRC、Payload Type和SDP属性存在厂商习惯；
• 平台宣称支持H.265，媒体服务器却无法解码；
• PS Map、PES长度、时间戳或关键帧处理不规范；
• 移动网络切换后注册仍在线，但媒体地址已经失效；
• 设备时间不准导致录像检索、证据时间线和平台校验异常；
• 摘要认证只能解决基础身份认证，不能代替完整的数据安全体系。

因此，商业级GB28181 SDK的竞争力，不只是“支持多少条命令”，还包括状态机是否稳定、异常是否可恢复、资源是否能正确释放、日志能否定位问题，以及面对不同平台行为时是否具备足够的兼容性。

结语

GB28181真正建立的，是一种面向大规模视频资源的组织与调度能力。

SIP解决设备和会话的控制，SDP完成媒体协商，RTP负责实时传输，PS承载音视频复用，MANSCDP描述设备业务，MANSRTSP控制历史媒体，统一编码和目录体系则把分散的视频资源组织成可查询、可控制、可调度的网络。

Android和鸿蒙NEXT的加入，使GB28181终端不再局限于传统IPC。执法记录仪、安全帽、无人机、车载设备、巡检终端乃至协议转换网关，都可以成为平台中的标准资源节点。

从SmartMediaKit的视角看，GB28181设备接入的最终目标并不是“把一条流推上去”，而是把复杂的移动终端、行业数据源和异构网络，稳定地纳入既有视频监管、应急指挥与行业协同体系。这才是GB28181在移动化、国产化和智能化时代仍然具有生命力的根本原因。

---

📎 CSDN官方博客：音视频牛哥-CSDN博客