抓包拆解国标GB28181：摄像头注册到国标GB28181视频平台EasyGBS到画面播放，中间都发生了什么？

现场最常听到的一句话是：“网络是通的，我在电脑上ping平台地址通得很，怎么设备就是不在线？”ping通只能证明IP层可达，证明不了国标信令通。GB28181是应用层协议，一台摄像头要在国标GB28181公网平台EasyGBS平台上“活”起来，得依次跑完注册、鉴权、保活、点播四段对话。

任何一段卡住，平台上的表现都是同一个词——离线，但原因可能相隔十万八千里。本文按时间顺序，把一次完整的国标接入拆开讲清楚，并给出三类高频故障的排查顺序表。工具不用复杂，一台装有抓包软件的笔记本，或者平台侧的报文诊断能力就够了。

1、第一个报文：REGISTER，设备主动报到

国标接入是设备主动注册，不是平台去拉设备。摄像头上电后，会按照配置好的SIP服务器地址、端口、服务器编码和自身设备编码，向平台发出第一条REGISTER消息，相当于进门先喊一声“我到了”。

这条消息里，有三个字段决定了后面所有对话能不能成立：

一是设备编码，也就是那串20位的国标ID。

它是国标GB28181软件EasyGBS平台识别设备的唯一凭据。编码写错一位、两台设备重号、或者把通道编码当成设备编码填进去，注册对话从第一步就废了。

二是SIP服务器编码与域。

它告诉平台“这台设备认为自己在跟谁说话”。域填错的情况很典型：平台收到了包，但认为这封信不是写给自己的，于是不作任何回应。抓包上看到的现象是只有单向的包，没有回应。

三是Contact与Via中声明的设备自身地址和端口。

国标视频分析平台EasyGBS平台后续所有消息都要按这个地址回。设备在内网、出口做了地址转换时，这里带出来的往往是内网地址，这就为后面的“注册成功但点播没画面”埋下了伏笔。

抓包时如果连REGISTER都看不到，问题一定在设备侧或网络可达性：服务器地址或端口填错、设备根本没有启用国标接入、或者UDP包被中间防火墙丢掉了。这一步与平台配置无关，在平台上反复改参数是白费功夫。

具体到端口数值，各部署版本请以配套的使用手册端口说明为准；设备侧需要填写的服务器地址、端口、编码等参数，来自平台的国标接入配置页面。

2、401不是报错：被误判最多的鉴权环节

第一次REGISTER之后，平台通常会回一个401，并在消息里带上鉴权挑战参数。很多工程师看到401的第一反应是“密码错了”，然后开始反复改密码——这恰恰是最浪费时间的一种排查。

国标采用的是基于摘要的挑战—响应鉴权，密码不在网络上明文传输。平台给出挑战值，设备用挑战值和本地配置的鉴权密码算出响应，再发起第二次REGISTER。所以一次完整的注册至少是四步对话：REGISTER→401→REGISTER（带响应）→200OK。

这四步分别对应的现场结论：

看得到第一次REGISTER，但平台没有任何回应。查设备编码是否合法、平台的信令端口是否放通、SIP服务是否在运行。设备侧编码错误和平台侧端口不通，在这一步的表现是一样的，要靠抓包区分。

有401，但设备不发第二次REGISTER。问题在设备侧：这款设备可能没有开启鉴权响应，或者固件对摘要算法的支持与平台不一致。去设备的网页端确认鉴权开关，必要时升级固件或改用平台侧的无鉴权接入方式。

有第二次REGISTER，但平台仍回4xx。这时才是真正的鉴权失败。逐字核对鉴权密码，特别注意区分两个东西：平台登录密码和设备在平台上的注册密码，项目上把它们混为一谈的情况非常多。

回了200OK。注册成功，同时留意响应里携带的有效期字段，它决定了这台设备需要多久重新注册一次。

一条经验：动手改配置之前，先把当前抓包文件存一份。项目上大量的“改了一圈又改回来”，都是因为手上没有留证据。

3、200OK之后：在线状态靠心跳续命

注册成功只是起点，不是终点。国标设备需要周期性发送保活消息，平台侧在连续若干个周期收不到之后，就会把设备判定为离线。具体的心跳周期与超时次数，以设备侧配置和平台侧配置为准。

这一段最常见的坑有两类。

第一类是NAT会话老化。设备在内网，出口做了地址转换。UDP会话长时间没有流量，中间设备的会话表项会被清掉，之后设备发出的心跳能出去，平台的回应却回不来。典型表现是“每隔一段时间就掉线，重启一下又好了，过一阵子再来一次”。

对策有两个方向：缩短设备侧心跳周期，让会话始终有流量；或者改用TCP传输，用长连接维持会话，EasyGBS的协议接入层兼容TCP与UDP双向传输，可以按需切换。

第二类是把“在线”和“有画面”混为一谈。国标视频分析平台EasyGBS具备按需拉流机制：没有人观看的通道只保留SIP心跳，不持续拉流，以此降低服务器带宽与算力消耗。所以“设备在线，但点开画面要等一两秒才出来”是设计使然，不是故障；反过来，如果设备在线状态频繁跳变，那问题一定在心跳链路上，跟流媒体没关系。

还有一点值得利用：平台侧已经把日志全量留存、SIP报文诊断、设备故障自动告警做进了同一套运维能力，排查时不必每次都跑到现场。先在平台侧看报文诊断与日志，确认对话停在哪一步，再决定要不要上抓包工具。

4、真正出图的那一步：INVITE与SDP

很多人以为注册成功就能看画面。其实点播是另一段完全独立的对话：平台向设备发INVITE，请求指定通道的媒体流；设备回200OK，并在SDP中写明自己要用哪个地址、哪组端口、什么封装格式和编码把流送过来；平台回ACK，会话建立；随后RTP媒体流开始传输，平台完成接收与转封装，再分发成浏览器、小程序、大屏能直接播放的格式。

这里有两个必须想明白的点。

第一，信令和媒体分开走。注册通不代表媒体通。媒体流使用另一组端口，防火墙上只放通了信令端口，就会出现“设备显示在线、点播一直转圈、最后超时”的经典现象。反过来也成立：媒体端口全通但信令不通，设备根本注册不上。排查时不要用一个的连通性去推断另一个。

第二，SDP里写的地址，未必是设备以为的那个地址。跨网段、NAT环境、多网卡设备，经常在SDP中带出内网地址，平台按这个地址去收流自然收不到。这是“有信令、无画面”这一类故障里占比最高的原因。

再往大一点的规模看，信令和媒体甚至可能不在同一台机器上。国标GB28181视频平台EasyGBS的SIP网关模式把SIP信令收敛到统一入口，再按负载策略分发到后端各服务节点，而RTP媒体流由设备与目标节点直接建立连接，不经过网关，网关只负责注册、保活、点播与回放、云台控制这类信令代理。

抓包时的直接含义是：在网关上只能看到信令，看不到媒体。要判断媒体问题，必须到后端节点或设备侧去抓。

5、三类故障的排查顺序

把上面的四段对话串起来，现场最常见的三类问题就各有各的排查路径，不必再靠重启碰运气。

需要提醒的是，如果部署规模到了需要集群的程度，排查路径要再加一层：先分清问题出在网关的信令层还是后端节点的媒体层。这也正是SIP网关模式的设计价值之一——接入问题定位在网关，业务与媒体问题定位在后端节点，故障边界是清楚的。

6、上线前五分钟自检清单

最后给一张可以直接照着做的清单，建议在批量接入前先拿一台设备走一遍。

说到底，国标接入这件事难在“看不见”。设备列表上只有一个在线或离线，但底下是四段完整的对话。把对话拆开看，故障就从“重启试试”变成了“停在第几步”。