2. 注册失败第一现场先分清是“根本没出去”还是“出去了回不来”排障最忌讳一上来就改配置先给问题定性。我一般把注册失败分成三类设备压根没发请求、请求发出去了但平台没收到、平台收到了但回了错误码设备不认。定性方式很简单分别在平台服务器和NVR侧抓包看同一段时间内有没有SIP报文经过。怎么抓平台侧如果用的是Linux服务器tcpdump是最顺手的工具一条命令就能把5060端口的UDP流量全抓下来tcpdump -i any -s 0 -w livegbs_sip.pcap -v port 5060抓个两三分钟等NVR那边点一次“注册”按钮然后CtrlC结束。把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. 常见问题速查与排查心得最后把实战中反复遇到的坑整理成一张速查表。这张表我贴过很多次每次都有人反馈说救命因为排查顺序跟着走基本能定位八成问题。现象可能原因排查手段平台无任何SIP报文网络不通、端口被封、NVR未启用注册平台侧tcpdump抓包确认NVR IP能否ping通检查服务器安全组/防火墙是否放行UDP 5060有REGISTER请求但无响应平台未启动、SIP端口配置不一致、回包路由异常查看LiveGBS服务状态对比NVR配置的端口和平台监听端口抓包看回包是否发出响应401但设备不继续鉴权NVR密码错误或未设置在NVR国标配置里重新输入平台密码海康设备需要保存后重新触发注册响应403平台拒绝该设备注册检查设备国标编号是否在平台白名单确认通道数量是否超限响应404设备国标编号在平台不存在核对NVR的国标编号是否与LiveGBS中保存的编号完全一致注意去掉多余空格注册偶尔成功偶尔失败心跳超时、网络抖动、CGNAT映射老化检查NVR心跳周期和注册有效期设置排查物联网卡网络稳定性长期运行设备建议开TCP模式设备显示在线但无视频流摄像头通道未接入或编码格式不匹配海康NVR接入的摄像头需单独配置国标通道确认子码流编码为H.264/H.265检查平台能否收到INVITE请求平台显示在线但回调失败服务器公网端口未映射确认平台服务器端口做了公网映射且防火墙对UDP入站放行可用另一台公网机器用nc命令测试UDP端口连通性除了上表再分享几条从现场摸出来的经验。第一物联网卡设备注册不上时先查APN。很多物联网卡默认APN是通用互联网APN这类卡拿到的IP往往是运营商的大网私网IP出口经过CGNATUDP端口老化时间非常短。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一下遇到问题直接执行几分钟就能拿到第一手证据。这个习惯帮我省了无数次“重启一下试试”的低效沟通。