摘要 一个县级平台项目，12 台摄像头，注册全通，目录只显示 3 台。厂家互相甩锅，我抓了 3 天包，最后发现问题藏在一个字母的大小写里。这篇文章复盘全过程，以及我现在怎么用工具 3 分钟定位同类问题。
正文 第一天：所有人都说不是自己的问题 项目现场，12 台摄像头，品牌混装：海康 6 台、大华 4 台、宇视 2 台。
平台是县里统一采购的国标平台。设备注册全部成功，平台能看到 12 台设备在线。但目录只显示 3 台通道。
设备厂家说：“我们设备注册都通了，目录也上报了，是平台没解析。” 平台厂家说：“我们平台没问题，是设备报文不标准。”
我打开 Wireshark，抓了一上午包。
满屏的 SIP：
MESSAGE sip:34020000002000000001@3402000000 SIP/2.0 ...
第二天：开始怀疑 XML 我逐字对比了能显示和不能显示的通道报文。
能显示的：不能显示的：等等。
a？
国标编码必须是 20 位纯数字。这台设备返回的编码最后一位是字母 a。
我一开始以为是设备固件 bug。但仔细看，是设备配置页面里，通道编码被人工填错了——现场施工的人把 01 填成了 0a，可能是手滑，也可能是复制粘贴时带了乱码。
平台侧校验严格，直接丢弃了这 9 个非法通道。所以只显示 3 台。
第三天：为什么这么难发现 问题本身很简单：DeviceID 不是 20 位纯数字。
但为什么抓了 3 天？
因为：
报文里 12 个 Item 都在，肉眼扫过去都像数字。
平台没有报错，只是“静默丢弃”。
设备厂家只看“注册成功”，不看目录内容。
平台厂家只看“收到 12 条”，不校验字段合法性。
Wireshark 不会告诉你哪个字段不规范。
故障现象和故障原因之间，隔着一层 XML。
现在我怎么做 现在遇到同类问题，我先跑一次 GBDoctor 的目录检测。
它会：
主动发 Catalog 查询
抓取设备应答报文
逐字段校验 XML
发现 DeviceID 不是 20 位纯数字时，直接标红
报告里写：
【阻断级】目录应答中 9 个通道 DeviceID 含非数字字符，平台已丢弃。 建议：检查设备通道编码，确保为 20 位纯数字。 海康：配置→网络→高级配置→平台接入→视频通道编码ID。 大华：主菜单→网络→平台接入→GB28181→通道编码。
3 分钟，定位。
这件事教会我什么 GB28181 联调最难的不是协议本身，是故障现象和故障原因之间的信息差。
设备说“我发了”
平台说“我没收到”或者“我收到了但没用”
中间没人告诉你“为什么没用”
一个字母的大小写，能吃掉三天。
如果你也在做国标项目，建议先体检，再抓包。
项目地址 Gitee：suoten/GBDoctor GitHub：suoten/GBDoctor 搜不到？在 Gitee 或 GitHub 搜索：GBDoctor 或 suoten GBDoctor
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70050062/viewspace-3183787/ ，如需转载，请注明出处，否则将追究法律责任。
