企业官网建设流程全解析

2. 注册失败第一现场：先分清是“根本没出去”还是“出去了回不来”

排障最忌讳一上来就改配置，先给问题定性。我一般把注册失败分成三类：设备压根没发请求、请求发出去了但平台没收到、平台收到了但回了错误码设备不认。定性方式很简单，分别在平台服务器和NVR侧抓包，看同一段时间内有没有SIP报文经过。

怎么抓？平台侧如果用的是Linux服务器，tcpdump是最顺手的工具，一条命令就能把5060端口的UDP流量全抓下来：

tcpdump -i any -s 0 -w livegbs_sip.pcap -v port 5060

抓个两三分钟，等NVR那边点一次“注册”按钮，然后Ctrl+C结束。把pcap文件拉到本地用Wireshark打开，过滤栏输入sip，如果一条SIP报文都没有，说明请求根本没到这个网络层面，问题大概率在设备侧或运营商链路；如果有SIP REGISTER请求但没有响应，说明请求到了平台但回包没回去，要么是平台没回，要么是回包路径被掐了；如果能看到401、403之类的响应，那问题就在SIP信令交互本身。

这里有个细节必须提醒：物联网卡很多走的不是普通宽带出口，而是运营商VPDN或专网APN，这类网络有个特点——NVR注册请求发出后，运营商网关会做一次网络地址和端口转换，如果平台返回的SIP消息里带的Via、Contact等字段还是内网IP，部分严格模式的SIP代理会直接丢弃。这就是为什么有些人平台侧明明看到请求进来了，却始终没有响应。所以抓包不只是看有没有包，还要看报文的IP地址、端口、Via头域是否合理。

我遇到过一次特别典型的案例：NVR和LiveGBS配置完全正确，平台侧抓包能看到REGISTER进来，但LiveGBS日志一直提示“未收到设备响应”。最后抓包发现，NVR发出的SIP报文的源IP是192.168.1.64，但Via头里写的Contact地址却是192.168.1.1（网关地址）。这是老版本海康固件的bug，某些网络环境下会把默认网关地址填进Contact字段。LiveGBS按Contact地址回包，结果包发到了网关而不是NVR本身。升级NVR固件后问题消失。所以抓包看到的现象和表象原因之间，往往还隔着一层配置或固件的坑。

3.2 Wireshark里这样过滤最快

很多人抓完包打开Wireshark，看到满屏UDP就懵了。这里给你一套我常用的过滤表达式，直接粘进去就能用：

sip

所有SIP信令报文。如果能抓到说明SIP层通了。

sip.CSeq.method == "REGISTER"

只看注册请求。NVR配置里点“注册”按钮的瞬间，这里应该出现至少一条。

sip.Status-Code == 401 || sip.Status-Code == 403 || sip.Status-Code == 404 || sip.Status-Code == 408

只看注册失败相关的响应码。401是未授权，需要带鉴权重发；403是禁止；404是找不到对应设备；408是请求超时。每种码对应的排查方向完全不同。

sip.To contains "34020000001320000001"

按设备国标编号过滤。一个平台下面挂几百路设备时，这个过滤能让你从海量报文中精准定位某台NVR。

udp.port == 5060

只看5060端口的UDP流量。如果信令端口自定义过，改成对应端口即可。用这个过滤能看到所有经过该端口的SIP报文，包括非标准格式的。

过滤完之后，重点看三个字段：Request-Line（请求行）里的目标URI是不是平台国标编号；Via头里的IP和端口跟实际来源是否一致；Contact头里的地址是否可达。这三个字段是SIP通信的基础，任何一个不对都会导致注册失败。

4. 常见问题速查与排查心得

最后把实战中反复遇到的坑整理成一张速查表。这张表我贴过很多次，每次都有人反馈说救命，因为排查顺序跟着走基本能定位八成问题。

除了上表，再分享几条从现场摸出来的经验。

第一，物联网卡设备注册不上时，先查APN。很多物联网卡默认APN是通用互联网APN，这类卡拿到的IP往往是运营商的大网私网IP，出口经过CGNAT，UDP端口老化时间非常短。NVR注册成功后，如果一段时间不发送心跳，CGNAT映射会自动回收，平台再回消息就找不到设备了。所以针对物联网卡场景，建议把NVR的注册有效期设短一些（比如300秒），心跳周期设成60秒，让设备频繁一点跟平台保持联络，反而比默认配置要稳定得多。

第二，NVR里“注册有效期”和“心跳周期”这两个参数很多人不重视。默认注册有效期可能是3600秒，心跳周期是60秒，但如果网络链路不稳定（物联网卡最常见），一次注册掉线后要等很长时间才能重新注册。我一般建议把注册有效期调到300秒，心跳周期调到30~60秒，这样即使链路闪断，设备也能在几分钟内自动恢复。代价是SIP信令流量会大一点，但对于物联网卡这种低带宽场景，这点流量完全可接受。

第三，千万别忽略NVR的系统时间。GB/T28181的SIP消息里携带Date头域，如果设备时间和平台时间差太多（超过几分钟），部分严格实现的平台会直接丢弃消息。物联网卡NVR如果没开NTP自动同步，长时间运行后时间偏移非常常见，表现就是“注册时好时坏”。现场排查时先对一下设备和服务器时间，不对就赶紧改。有一次我排查了整整一个下午，最后发现是NVR的时区设置成了UTC，跟北京时间差了8个小时，平台认为消息过期直接丢弃。

第四，抓包不只是排查手段，也是需求沟通的“证据”。很多时候现场反馈“注册不上”，但远程一看平台侧一切正常。这时候只要让现场在NVR上点一次注册，同时平台侧抓包，把抓包结果截图发给现场，问题归属就很清楚了。抓包文件是最好的沟通语言，比来回远程控制效率高十倍。

4.2 长时间抓包与性能注意事项

最后补充一个很多人问过的实操问题：现场网络不稳定，需要长时间抓包观察设备注册和保活情况，怎么抓才不丢包、不把服务器搞挂？

我的经验是：tcpdump长时间抓包，一定要加文件大小和轮转参数，不要一直往一个文件里写。命令大概是这样的：

tcpdump -i eth0 -s 0 -w /data/capture/sip_%Y%m%d_%H%M%S.pcap -G 3600 -C 512 -Z root port 5060

解释一下：-G 3600表示每隔3600秒（一小时）生成一个新文件，-C 512表示单个文件最大512MB，先到先触发轮转；-Z root是让tcpdump以root权限运行并创建文件，不然写文件权限会出问题。这样抓一天也就十几个文件，每个文件都能在Wireshark里正常打开，不至于生成一个几十GB的怪物文件。

抓完包分析时也有性能坑。如果pcap文件很大，Wireshark打开会卡半天，我的做法是先在这个文件上跑一遍tshark，把SIP报文单独抽出来：

tshark -r big_file.pcap -Y sip -w sip_only.pcap

这样SIP信令单独一个文件，几百MB能瘦身成几MB，后面想怎么看都行。如果还要看视频流相关的RTP包，再单独过滤rtp即可。

说到RTP，有个点值得一提：注册成功后视频流拉不起来，很多人又去抓SIP包，其实这时候SIP信令是通的，问题出在RTP媒体流上。RTP包默认走UDP端口范围较大，如果服务器防火墙只放行了5060端口，RTP流会被丢弃，表现为“设备在线但画面黑屏”。排查时抓包过滤rtp，看看有没有RTP包到达服务器，没有的话检查防火墙对UDP高端口（比如10000-20000）的放行策略。一些云服务器安全组默认只放行少数端口，这个坑踩的人特别多。

5. 这套方法论还能用到哪里

GB/T28181注册排查的这套思路，换个场景一样能用。现在很多项目里不只是海康NVR，还有大华、宇视、华为等各类前端设备接入LiveGBS或类似的国标平台，排查逻辑完全一致：先抓包定性，再逐层定位。抓包工具和过滤技巧也完全相同，只是SIP报文的User-Agent字段能从海康换成了别的厂商，但REGISTER、401、200 OK这些核心交互是一样的。

具体来说，以下几种情况都可以直接复用：

• 摄像头直接以GB/T28181方式接入平台，注册不上，按同样的思路抓包看SIP交互。
• 平台级联（下级平台向上级平台注册），抓包时留意Via和Route字段，级联场景的SIP路径比单设备要复杂，但排查链路一致。
• 报警布防、录像回放等高级信令交互异常，同样可以从SIP消息层面定位是请求没发出还是响应被丢弃。

另外，我注意到很多人在排查信令问题时习惯只看应用层日志，不看原始报文。LiveGBS的调试日志确实能显示不少信息，但日志是平台视角的，平台没收到报文它也不知道。而抓包是链路视角，能同时看到设备发出的内容、网络中间节点的处理（虽然中间节点不一定可见，但至少能确认报文是否到达服务器网卡）、平台是否回包。两者配合才是完整的排查闭环。只看日志不看包的排查方式，碰到中间链路问题时就抓瞎了。

我的建议是：服务器上常驻一个抓包脚本不是好做法，但至少要保证现场出问题时能在一分钟内开始抓包。我在服务器上一般提前放好抓包目录，写好tcpdump命令的快捷脚本，甚至alias一下，遇到问题直接执行，几分钟就能拿到第一手证据。这个习惯帮我省了无数次“重启一下试试”的低效沟通。