GB28181 设备注册失败：401、403 和超时的区别在哪
设备列表里就是不出那一台。翻日志的时候大家嘴上说的都是“注册失败”，但实际看到的东西压根不是一回事：有人是一屏 401 反复刷，有人只有孤零零一行 403，还有人抓下来的 pcap 里包数少得可疑，甚至整个文件是空的。
这三类的故障点分别落在网络、凭据、平台侧的设备记录上。拿同一套办法去试，结果就是在改密码、换端口、重启平台之间来回打转，一晚上过去什么也没定下来。
所以先别急着想“注册失败该怎么办”。先确认平台给你的第一个响应是什么——看到的东西不同，要查的地方完全不同。
一、401 不是拒绝，是平台在要密码
GB28181 的注册沿用 HTTP 摘要认证，套在 SIP 上，但它是两次 REGISTER，不是一次。
第一轮设备不带任何凭据就发 REGISTER。平台没法验证它，只能回 401 Unauthorized，在 WWW-Authenticate 里给出 realm 和 nonce。第二轮设备拿这两个值算出摘要、带 Authorization 重发，这才轮到 200 OK 或者 403。
也就是说，401 出现在每一次成功注册的前半段。它本身不代表任何失败。
看到 401 就去改密码，是这一步最常见的误判。 密码真错的时候，绝大多数平台回的是 403。这一条我没在每一家上验过，各家实现多少有出入，你要图快，最快的办法是把平台端的密码故意改错一位，看它回什么码，比自己猜准。
| 你看到的 | 说明什么 | 接着查哪 |
|---|---|---|
| 一次 401，紧跟 200 OK | 正常握手 | 这关过了，去看心跳 |
| 多次 401，始终没有 200 | 摘要对不上，或者平台在反复挑战 | realm、nonce、username |
| 401 之后回 403 | 凭据送到了，平台判定不通过 | 密码、设备是否登记 |
| 一个包都没有 | 消息没到，或者回复没回来 | 网络、传输协议、SIP 域 |
顺手贴三段报文，字段是照标准写的，你现场的值会不一样。第一轮请求：
REGISTER sip:34020000002000000001@3402000000 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.64:5060;rport;branch=z9hG4bK743291
From: <sip:34020000001320000001@3402000000>;tag=812536814
To: <sip:34020000001320000001@3402000000>
Call-ID: 3000000001
CSeq: 1 REGISTER
Contact: <sip:34020000001320000001@192.168.1.64:5060>
Max-Forwards: 70
Expires: 3600
Content-Length: 0平台的挑战：
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.64:5060;rport;branch=z9hG4bK743291
From: <sip:34020000001320000001@3402000000>;tag=812536814
To: <sip:34020000001320000001@3402000000>;tag=3258012
Call-ID: 3000000001
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="3402000000", nonce="a3f1c9d2e8b74560"
Content-Length: 0第二轮，请求行没变，CSeq 加一，多了一行 Authorization：
REGISTER sip:34020000002000000001@3402000000 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.64:5060;rport;branch=z9hG4bK849107
From: <sip:34020000001320000001@3402000000>;tag=812536814
To: <sip:34020000001320000001@3402000000>
Call-ID: 3000000001
CSeq: 2 REGISTER
Contact: <sip:34020000001320000001@192.168.1.64:5060>
Authorization: Digest username="34020000001320000001", realm="3402000000",
nonce="a3f1c9d2e8b74560", uri="sip:34020000002000000001@3402000000",
response="9f2b0c7d5e1a4836bc04d7f2e9135a68"
Expires: 3600
Content-Length: 0response 是算出来的，算法就是 RFC 2617 那一套：
HA1 = MD5(username : realm : password)
HA2 = MD5("REGISTER" : uri)
response = MD5(HA1 : nonce : HA2)这三个输入没有一个能靠猜。username 是设备编码；realm 要取 401 响应里的那个，不是设备配置页上那个“SIP 域”；uri 必须和 REGISTER 请求行的 URI 逐字符一致。任何一处换成设备端自己填的值，算出来就是另一串，平台要么回 403，要么再挑战一次。
二、一个包都没有：先证明消息到没到
这一类最难，因为没有错误信息可看。平台不是拒绝了你，是压根没理你。
定位办法只有一条，两边同时抓：
# 设备侧（IPC 所在网段 / 模拟器所在的机器）
tcpdump -i any -n -s0 port 5060 -w device.pcap
# 平台侧
tcpdump -i any -n port 5060结果无非三种走向。设备侧有、平台侧没有，中间被拦了或者路由不通；两边都有，说明平台收到了包却没回，那往下看第三节；设备侧也没有，是设备压根没发出去，问题在设备配置上，跟平台没关系。
前者再往下拆，按我见到的频率排是这四种：
1. 传输协议不匹配。 平台只监听 TCP，设备发的是 UDP，或者反过来。这个现象很干净：设备侧显示注册超时，平台侧一行日志都没有，你拿 nc -vz 去测端口甚至还是通的——它测的是 TCP，跟 UDP 没有关系。UDP 本来就没有握手，“没有响应”是它能给出的唯一反馈。
2. SIP 域 / 服务器编码填错。 包确实到了，平台一看 To 里的域不是自己的，直接丢弃。不打日志，也不回错误码。这是“网络明明通、平台就是没反应”里最常见的一种。判据很土但有效：把请求行里的域名和平台 SIP 配置里的域，一个字符一个字符对。
3. 防火墙或云安全组。 平台上 netstat 看端口在听，从外面就是进不来。注意安全组是按方向放行的，只看入站规则里有没有 5060 不够。
4. 平台 SIP 服务没起来。 端口被占的时候进程起不来，日志里一般有 bind: address already in use。
三、401 一直来：摘要没对上
连着三次以上 401、始终等不到 200，问题基本就落在设备算摘要这一步了。我见过的原因有三种。
最多的一种是 realm 用错了。不少设备把配置里的“SIP 域”直接当 realm 送出去。这两个值经常是相同的（都是 20 位服务器编码的前 10 位），所以平时看不出来；一旦平台配的 realm 和注册域不一样，设备怎么填都不对。
第二种是 nonce 过期没重算。平台侧的 nonce 是有有效期的，过期后回 401，有的还带一个 stale=true，意思是“凭据格式没问题，拿新 nonce 重算一遍”。设备如果拿旧的硬重试，就会一直 401 下去。
第三种是 username 填错。摘要里的 username 是平台找设备的依据，填成 admin 这类自定义值，平台按它查不到设备，只能继续挑战。
还有一种反向情况要留意：有些平台在密码错误时不做 403，而是继续回 401。设备于是无限重试，日志一屏 401，看起来像“协议不兼容”。分辨的办法是看 401 里的 nonce 变不变——每条都不一样，说明平台还在挑战；一直不变，那就是设备在重发旧凭据。
四、302：注册被转走了
平台返回 302 Moved Temporarily，Contact 里指向另一个 SIP 服务。多级平台、前置负载均衡、注册重定向都会这样。
正确处理是按 Contact 里的地址重新发一轮 REGISTER，而不是当失败、对着原地址重试。症状很好认：一直 302，永远到不了 200，而日志里有一行 Contact 指向别的 IP。
五、403：认出来了，但不让进
403 的意思是凭据收到了，平台也看懂了，只是不接受。按顺序查这四件事：
- 密码错。这是绝大多数情况。注意是平台侧那个“设备接入密码”，不是网页登录密码。
- 设备没在平台登记，而平台关掉了“允许自动注册”。
- 设备编码和已有设备撞了。有的平台对第二次注册直接拒掉。
- IP 不在白名单里，或者在黑名单里。
403、404、400 在这个场景里意思差不多，都是“平台不认这台设备”，只是各家选哪个码回并不统一。有的对未登记设备回 404；有的把黑名单里的 IP 直接丢包，连码都不回。后一种的表现和第二节的“一个包都没有”看不出区别，只能到平台的黑名单设置里去排除。
六、200 OK 之后又掉线，是另一件事
注册成功了，但设备列表里的在线状态反复跳，那就别再往注册上查。这种情况最有用的线索是掉线的间隔：
| 掉线间隔 | 成因 |
|---|---|
| 十几秒，两台设备轮流掉 | 设备编码重复，后注册的把前一个顶掉 |
| 约 180 秒 | 心跳没发出去，或者平台收不到 |
| 约 3600 秒 | 注册有效期到期没续 |
| 无规律，几分钟到十几分钟 | NAT 映射表超时 |
180 秒和 3600 秒这两个数不是巧合：国标默认心跳 60 秒一次，连续 3 次没收到就判离线；注册有效期 3600 秒。这两项各平台都能改，所以先确认平台配置里的实际值，再拿实测间隔去对，一半的原因当场就能排掉。
七、设备侧日志长什么样
一次成功的注册，在设备侧是四条记录：REGISTER、401、REGISTER、200 OK。过滤器切到 REGISTER，列表里就该只剩这四条，加上后面周期性的续注册。
不过真排查的时候，我更常用全部方法混排的视图，因为它能直接看出注册通过之后紧接着发生了什么：
OK · 注册成功 expires=3600s 其实是这一轮的起点；expires 的 3600 正好是第六节里说的注册有效期。看混排而不是只看 REGISTER，是为了第二类问题：注册成功，平台却一个 Catalog 都没发。这时候注册那四条的回码全对，后面一条目录消息都没有，说明平台压根没往下走，问题在平台侧的设备配置，跟认证没关系。
至于 REGISTER 出现两次，那是正常的，第一轮第二轮各一条。如果你看到四条以上 REGISTER 只有一条 200，那是在重传：UDP 首包丢了会按 T1 计时器重发，偶尔一次无所谓，连续三次以上说明第二轮那条响应根本没被处理，回第三节查摘要。
八、拿第一个响应当岔路口
前面按错误码分开讲，是因为每种情况的成因差得远，混在一起看容易乱。真到了现场，顺序反过来更省事：先确认第一个响应是什么，再决定往哪查。
要是连“第一个响应是什么”都确定不了，那就属于第二节的情况了。先抓包，别在平台界面上反复刷新。
九、注册过了，不等于接进来了
注册只是第一道门。过了之后还有三件事要验，缺哪一件，现场都还是“接不进来”：
- 设备能连续在线 10 分钟以上，状态不跳（心跳正常）
- 平台查目录能返回通道，数量和实际一致
- 点播能出画面——这是媒体链路，和信令是两回事
手上没有摄像机也能把这三步跑完，做法见没有摄像头，怎么把国标平台联调跑通。要跨 2016 / 2022 两个版本对接，先看一眼两个版本的差异对照，能省掉一轮“以为是设备不支持、其实是没开兼容模式”的往返。
需要一台现成的模拟设备，可以看 UVP-28181-SIM（Android）或 UVP-28181-SIM-DESKTOP（Windows / macOS，可批量拉起虚拟设备）。SIP 日志能按方法过滤，也带时序图。只把测试设备接入你拥有或获得授权测试的平台。