GB28181 对接踩坑实录：注册不上、目录不全、流卡顿，一次说清（附 2022 版变更清单）

做了两年多视频监控平台对接，GB28181 相关的坑基本踩了个遍。这篇文章我把注册、目录、点播、流传输四个环节的典型问题和排查思路给整理出来了，信令报文都是我实际抓包留下的，2022 版新增内容也标出来了。建议收藏，对接前过一遍能省不少通宵。

一、先纠正一个常见误解

很多人把 GB28181 理解成"一个视频协议"，我觉得这个说法不太对。

它本质上是一套基于 SIP 的信令体系 + PS 流封装 + RTP 传输的组合。控制面走 SIP（跟 VoIP 那套东西同源），媒体面走 RTP 打包的 PS 流。所以你会发现，做 GB28181 开发的人，调试工具和做 VoIP 的几乎是一样的------Wireshark 加上 SIP 过滤器就够了。

这带来了一个好处：网上 VoIP 的资料、开源的 SIP 协议栈，大部分思路可以迁移过来。坏处是，你会遇到一堆 VoIP 里也有的"祖传问题"：NAT 穿透、注册超时、信令路由......在监控场景里全部会重新出现一遍。

二、注册环节：REGISTER 报文里的三个必查项

设备注册是所有对接的第一步，也是最常出问题的一步。一个标准的注册流程长这样：

REGISTER sip:34020000002000000001@3402000000 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.64:5060;rport;branch=z9hG4bK1371463273
From: <sip:34020000001320000001@3402000000>;tag=2043466181
To: <sip:34020000001320000001@3402000000>
Call-ID: 1646267081
CSeq: 1 REGISTER
Contact: <sip:34020000001320000001@192.168.1.64:5060>
Max-Forwards: 70
Expires: 3600
Content-Length: 0

平台回 401 携带 WWW-Authenticate，设备再带上 Authorization（Digest 摘要认证）重新注册，这是正常流程。如果第一遍 REGISTER 就石沉大海，按顺序查三样东西：

1. ID 编码。 国标 ID 是 20 位数字，第 9-10 位是设备类型码。132 是网络摄像机，200 是平台/服务器。我见过不止一次，现场把平台 ID 配成了 132 开头，设备看着好像"注册成功"了，但是平台侧根本不走目录逻辑。11-13 位是行政区划码，也要和平台域一致，否则部分平台的域校验会直接拒绝。

2. 网络方向。 GB28181 默认设备主动向平台注册，所以检查设备侧能不能 ping 通平台的 5060（UDP）。有些公安/政务专网做了端口白名单，5060 放了，但设备侧配置的本地端口被出方向策略拦了------这种问题 ping 是 ping 不出来的，要在设备侧抓包确认有没有发出 REGISTER。

3. 密码认证算法。 2022 版把摘要算法从 MD5 升级到了 SHA-256，并且要求兼容。实际项目里遇到过新老设备混装：老设备只发 MD5，新平台按 2022 版只认 SHA-256，注册就失败了。平台侧最好两个算法都开着，按设备能力协商。

另外一个高频问题：注册成功后设备"掉线又上线"反复横跳。十有八九是 Expires 续约没对上 ------设备注册时带 Expires: 3600，但很多设备实际在到期前一半时间就发续约，如果平台侧 Session 超时配置比设备的续约周期还短，就会出现周期性掉线。把平台侧超时调到注册周期的 1.5 倍以上基本就好。

三、目录查询：Catalog 为什么要用异步收

注册成功后第一件事是拉设备目录，发一条 MESSAGE 信令：

<?xml version="1.0" encoding="GB2312"?>
<Query>
  <CmdType>Catalog</CmdType>
  <SN>10</SN>
  <DeviceID>34020000002000000001</DeviceID>
</Query>

然后设备回 200 OK，再通过 MESSAGE 分批推送目录项。坑在这里就出现了：

新手最常见的写法是同步等响应 ------发完 Catalog 就在那等 200 OK，等到了就认为目录收完了。错。200 OK 只表示设备收到了查询，真正的目录数据在后续的 MESSAGE 报文里，而且是分页的 ，每条 MESSAGE 带 SumNum（总数）和 SN（本次序号）。一个下挂 500 路的平台，目录可能分十几条 MESSAGE 推过来，中间还可能隔几秒。

正确的处理方式：

# 伪代码：异步聚合目录
pending_catalog[sn] = {
    "sum": None,       # 从 SumNum 字段拿
    "items": []
}

def on_message(msg):
    sn = msg.SN
    if sn in pending_catalog:
        pending_catalog[sn]["items"].extend(parse_items(msg))
        pending_catalog[sn]["sum"] = msg.SumNum
        if len(pending_catalog[sn]["items"]) >= pending_catalog[sn]["sum"]:
            finalize(sn)   # 收齐了

再加一个超时兜底（比如 30 秒没收齐就按已收到的处理并告警）。这个逻辑不复杂，但同步等响应的写法在设备多、网络抖的时候一定翻车。

还有个细节：目录 XML 的编码，标准里允许 GB2312，平台侧解析时注意别默认按 UTF-8 解，中文名称会乱码。

四、点播与流传输：a=setup 是 2022 版最重要的变化

实时点播走 INVITE，SDP 里声明媒体参数：

v=0
o=34020000001320000001 0 0 IN IP4 192.168.1.64
s=Play
c=IN IP4 192.168.1.100
t=0 0
m=video 6000 RTP/AVP 96
a=recvonly
a=rtpmap:96 PS/90000

这段 SDP 意思是：平台在 6000 端口收流，载荷类型 96 对应 PS 封装。到这里问题就来了------TCP 模式下，谁连谁？

2016 版对这件事是模糊的，导致行业里长期存在各种私有实现：双方都等对方连（TCP 建不起来）、内网设备公网平台连不进去，都是这个根源。2022 版引入了 a=setup 协商（active/passive/actpass），这才把角色讲清楚：

• 设备在内网、平台在公网：设备声明 a=setup:active，由设备主动反连平台的收流端口，NAT 问题直接绕过；
• 平台主动收：声明 passive，监听等待。

做平台开发的话，建议把三种角色都实现了，因为你永远不知道下一家对接的设备/平台只支持哪一种。

为什么 UDP 收流会卡成 PPT？ 排查方向按概率排：

1. 网络丢包。UDP 模式没有重传，公网或跨网段传输丢包率超过 2% 就能肉眼可见地花屏卡顿。这种场景应该切 TCP；
2. RTP 包长超过 MTU。PS 流一个 GoP 的 PES 包没切好，出来的 RTP 包 1500+ 字节，被中间设备分片或直接丢弃。抓包看 IP 层有没有 Fragment 标志；
3. 时间戳跳变。部分设备的 RTP 时间戳不做单调递增处理，跨网络抖动后播放端缓冲判断错乱。

五、PS 流解封装：H.265 的 stream_type 是 0x24

收到的 RTP 载荷是 PS 封装，解包后看 PSM 里的 stream_type：

• 0x1B：H.264
• 0x24：H.265（2022 版正式标准化，2016 版时代各家私有约定五花八门）
• 0x90：G711A，0x9C：G711U

2022 版之前，H.265 的 PS 封装各厂家"约定俗成"，解析端经常要根据魔数猜格式。如果你的解析代码里还留着 if (stream_type == 0x24 || 私有头判断) 这种逻辑，趁 2022 版铺开尽快收敛掉。

六、2022 版变更速查表

对接选型时经常被问"支持哪个版本的标准"，把主要差异列一下：

变更点	2016 版	2022 版
视频编码	H.264（H.265 靠私有约定）	H.265/HEVC 正式纳入，stream_type 0x24
TCP 角色	未明确，私有实现泛滥	a=setup: active/passive/actpass 标准协商
多码流	基本没有	a=streamnumber 字段，0 主码流、1 子码流
认证	MD5	SHA-256（兼容 MD5），支持 SIP over TLS
坐标系	不统一	统一 CGCS2000
其他	---	注册重定向/集群、X-GB-Ver: 3.0 头、RTP 时间戳要求

补充一个工程细节：2022 版从 2023 年 7 月 1 日实施，但存量设备大头还是 2016 版行为，平台必须双版本兼容，这一点在采购/招投标文件里要写清楚，否则验收时扯皮。

七、自研还是集成？一个务实的判断

最后聊下技术选型，这是被问得最多的问题。

GB28181 的信令栈本身不算难，开源的 WVP-GB28181-pro + ZLMediaKit 这套组合可以把平台侧架子搭起来，个人学习或小型项目完全够用。但要做商用级平台，要考虑的东西就多一层：多厂商设备兼容（上面每个坑都是兼容性成本）、级联、云台/订阅/录像回放全套信令、双版本并存、以及和业务系统（调度、告警、GIS）的集成。

我们去年做一个园区项目，需求是摄像头接入之外还要和调度系统打通------值班员在指挥界面上直接点某路监控放大、和对讲组一起联动。评估下来自研信令栈再加这层业务集成，人力账算不过来，最后是集成了华脉智联的 Hlink 调度平台：它把 GB28181 的接入、级联和 PS 流分发做成了现成服务，上层业务直接通过 API 拉流和联动，我们自己的精力放在了业务侧。当时对比过好几家方案，共同点是信令兼容性矩阵都要实测------不管选哪条路，拿现场实际用的那几个批次设备做一轮真实对接测试，比看任何参数表都有用。

八、对接排查 Checklist

收个尾，把全文的排查点压缩成一张清单，对接前对着过一遍：

• ID 编码：20 位、类型码（132/200）、行政区划码与平台域一致
• 网络方向：设备→平台 5060/UDP 可达，出方向策略确认
• 认证算法：MD5/SHA-256 双兼容
• 注册续约：平台 Session 超时 > 注册周期的 1.5 倍
• 目录：异步聚合 + SumNum 校验 + 超时兜底，XML 编码兼容 GB2312
• 点播：TCP 主被动三种角色都实现，UDP 卡顿先查丢包和 MTU
• 流解析：stream_type 按 2022 版标准（0x1B/0x24），去掉私有头依赖
• 版本：平台双版本兼容（2016/2022），验收标准写进合同