“作为下级级联到海康、大华、宇视这类第三方国标平台对方要我们提供国标编号、地址、端口号这三个东西到底该填什么”——这基本是 LiveGBS 相关对接群里被问得最多的问题几乎每周都能看到有人卡在这一步。我刚开始做平台级联的时候也懵过不同平台叫法还不一样有的界面写“SIP服务器ID”有的写“国标编号”有的写“设备编码”等折腾完一圈才发现很多人是把自己平台的信息和对方平台的信息搞反了。先直接说结论当你作为下级平台、对方作为上级平台时需要提供的三个参数分别对应 LiveGBS 自己的 SIP 服务器国标编号SIP Server ID、SIP 服务监听地址、SIP 服务监听端口。换句话说这是“你的国标编号、你的地址、你的端口”不是对方平台那套。这篇文章主要是给正在做 GB28181 平台对接的实施、开发和运维同学看的我会把这三个参数具体怎么确认、怎么填、填完怎么验证以及常见的注册失败排查思路一次讲清楚。标题里还带了“国标2022”所以最后我也会聊聊新版国标在级联对接里到底有哪些需要注意的变化。1. 先搞明白这三项是“谁”的三项很多对接失败的起点就错在这做过一次级联对接的人大概率都经历过这种场景对方给你发来一个接入信息收集表上面列着“国标编号、IP、端口”后面备注“请填写贵方平台信息”。你打开自己的 LiveGBS 后台看到一堆配置项一时不知道该抄哪个。这个时候最容易出现两种错误。第一种是把对方平台的国标编号填进去。有些厂商的界面会把上级平台的信息和本级平台的信息放在同一个页面字段名又差不多一不留神就抄串了。第二种是把自己 LiveGBS 的 Web 管理后台地址、Web 端口当成国标平台地址和端口填上去。这两个东西压根不是一个协议层面的东西Web 端口是 HTTP 访问用的SIP 端口才是信令通信用的。填错之后最典型的现象就是上级平台那边永远显示下级离线抓包发现根本没有 SIP 报文到达。要理解为什么填的是“自己的信息”得从级联的机制说起。GB28181 的平台级联本质上就是上级平台在自己的“下级域列表”里登记一个下级平台登记内容就是这个下级的 SIP 域、SIP 服务器 ID、访问地址和端口。登记完之后上级平台才能知道“在网络的哪个位置、用什么身份能找到这个下级”。这就像别人要给你汇钱必须先知道你的银行卡号、开户行而不是你先知道对方的卡号。你给上级平台提供的三个参数就是告诉它“我在 SIP 世界里叫什么、住哪、从哪个门进去能联系到我”。所以一个完整的级联对接其实需要两边交换各自的信息。下表列了双方需要互相提供的参数方便你在做对接表的时候直接对照着抄对接方向需要提供的信息在 LiveGBS 里的对应位置下级提供给上级下级 SIP 服务器国标编号SIP 配置中的“SIP Server ID / 国标编号”下级提供给上级下级 SIP 服务地址SIP 服务监听 IP 或公网映射地址下级提供给上级下级 SIP 服务端口SIP 端口默认 5060上级提供给下级上级 SIP 服务器国标编号级联配置中的“上级平台国标编号”上级提供给下级上级 SIP 服务 IP、端口级联配置中的“上级平台地址、端口”很多刚开始做对接的人看到这张表会觉得麻烦怎么两边都要填没错级联就是这么个双向关系。LiveGBS 作为下级它在发起注册的时候需要知道上级平台的 SIP 服务器 ID、IP 和端口否则它不知道要往哪发注册报文。而上级平台也需要知道下级这边的基本参数否则它无法识别这个下级是谁、从哪里来。两边各填各的但是两边填写的内容必须能互相咬合。举例来说你给上级平台提供的端口是 5060那上级平台填下级端口时就写 5060上级平台让你填它的地址你就填它给你的那个 SIP IP不能拿它 Web 后台的地址凑数。想通这一点后面所有配置都会顺很多。我见过不少项目卡在级联离线状态好几天最后发现不是参数填错而是压根没分清楚“哪一栏填对方的、哪一栏填自己的”。所以做级联之前我的习惯是先建一个对接信息文档把双方参数都列出来再用“本级/上级”两个前缀区分清楚最大程度避免复制粘贴时搞混。2. 三个字段逐项拆开编号规则、IP 选型、端口坑位知道要填“自己的”之后剩下的问题就是这三个值本身到底怎么确定。这里每一个字段背后都有不少细节尤其是碰到跨网段、多网卡、端口映射这些场景稍微不注意就会踩坑。2.1 国标编号是 20 位数字不是随便编一串就能用先说国标编号。在 GB28181 体系里SIP 服务器国标编号也就是 SIP Server ID是一串20 位数字。它的基本结构一般是这样前 8 位行政区划代码比如一个省级平台所在的区划就写省级的 8 位编码中间 2 位行业编码很多公网平台取“00”接下来 3 位设备类型编码SIP 服务器信令网关常见是111最后 7 位具体序号自己编排只要在域内唯一就行。举一个典型的例子34020000001110000001这种格式前半段代表行政区划和行业归属中间的111表明它是一个 SIP 信令服务器最后的序号用于区分域内不同设备。你看到很多厂商平台默认填的就是这种格式。不过这里有一个非常关键的提醒国标编号的行政区划编码部分一定要以平台部署所在地为准不能随手拿一个示例照抄。很多项目实施的时候为了方便直接复制了文档示例里的34020000001110000001结果上级平台校验编号后发现这个 SIP 域和行政区划对不上直接拒绝注册或者显示“未知下级”。最稳妥的做法是让上级平台的管理员给你分配一个符合规范的下级国标编号你直接拿那个编号填进 LiveGBS 的 SIP Server ID 里。如果对方让你自己定那就按“省市县区划编码 行业码 111 序号”的规则自行编一段并把这段编号同时填到 LiveGBS 本级配置和上级平台的下级信息里保持两边完全一致。在 LiveGBS 里这个参数通常叫“SIP Server ID”或者“国标编号”。打开管理后台找到 SIP 配置相关的菜单一般会看到它。它必须是一个完整的 20 位数字字符串不要带空格、横线或小数点。就是这一项后面所有注册信令里的 From 字段、认证用户名都会用到它一旦配置错了上级平台收到的请求就是“来路不明”的进而直接回 404 或 403。2.2 地址选型内网直连用内网跨网访问填映射地址地址这个字段看起来最简单实际翻车率也不低。它要填的是“上级平台能够访问到的 SIP 服务地址”。注意这里说的是“上级平台能够访问到”不是你自己ifconfig看到的那个 IP 就一定能用。分两种情况来理解如果上级平台和 LiveGBS 部署在同一个内网那直接填 LiveGBS 服务器的内网 IP 就行比如192.168.x.x。如果上级平台在外网或者和 LiveGBS 不在同一路由可达的网段那就得填经过 NAT 映射之后的公网 IP 或者端口映射后的地址。如果公司网络出口有公网 IP那就找网络管理员确认映射关系如果 LiveGBS 部署在云服务器上那就填云服务器的公网 IP并在安全组里放行 SIP 端口。多网卡服务器是另一个重灾区。一台服务器如果同时有内网口和公网口LiveGBS 的 SIP 服务监听地址配置必须选对网卡。你给上级平台填了公网 IP但 LiveGBS 只监听了内网网卡的地址那上级平台的信令就永远打不进来。反过来你给上级平台填了内网 IP但对方在公网侧报文根本路由不进来。所以地址选型的核心判断标准只有一个从上级平台角度看这个地址是不是可达的。如果有条件让上级平台侧的技术人员直接ping一下再 telnet 一下端口比自己瞎猜靠谱得多。有些平台也支持填写域名而不是 IP。如果你的环境里有内网 DNS 或者有固定的域名映射填域名也是可以的。但我不太建议在级联对接初期就用域名尤其是在两边的网络排查还没有做通之前域名解析问题会把简单问题复杂化。先用 IP 把链路打通等稳定了再考虑换成域名。2.3 端口5060 是默认但别忘了协议类型端口这个东西默认大家都会想到 5060。没错GB28181 的 SIP 信令默认端口就是 5060大部分国标平台默认也监听这个端口。但这里有几个很容易被忽略的点。第一SIP 协议有 UDP 和 TCP 两种传输方式GB28181 早期实现里绝大多数都是用 UDP。你在给上级平台填端口时通常默认对应 UDP。有些平台界面会专门让你选“UDP/TCP”这种情况必须和上级平台的 SIP 服务监听方式保持一致。比如上级平台那边只开了 TCP 5060你这边还按 UDP 往出发注册那就一直收不到响应。第二如果做了端口映射上级平台填的端口是映射后的外部端口不一定是 LiveGBS 实际监听的内部端口。比如 LiveGBS 服务器内网监听 5060但在出口路由器上把外网的15060映射到了内网5060那上级平台填的就是15060。这种情况下建议在做对接表的时候把“内网监听端口”和“对外提供端口”明确分开标注避免两边理解偏差。第三上下级平台的 SIP 端口不需要必须一致。这是很多人都有的一个误解。上级平台可能监听 5060也完全可能监听 7060。你作为下级给上级平台填的上级端口只要和上级平台实际监听的端口一致即可与你自己这边的 SIP 监听端口是多少没有任何关系。同理上级平台填你的端口也只需要对准你这边实际监听的端口。两个平台之间的端口是可以完全不同的。为了便于对照我习惯用一个表格来整理这三个参数的实际填法字段实际填什么常见坑国标编号LiveGBS 的 SIP Server ID20 位数字填成上级平台的编号或没按行政区划规范地址上级平台可访问的 SIP 服务 IP填内网 IP 但上级在外网多网卡选错端口LiveGBS 的 SIP 监听端口默认 5060填了 Web 端口做了 NAT 映射却填内网端口3. LiveGBS 侧三步拿参数抄对配置再发给对方搞清楚概念之后实操其实很快。下面我按步骤走一遍告诉你到哪找这三个参数、怎么确认它是对的以及在发对接表给对方之前自己先做哪几步自检。3.1 第一步在 LiveGBS 管理后台定位 SIP 配置登录 LiveGBS 的 Web 管理后台一般在左侧菜单里找“国标配置”或者“SIP 配置”这一类的菜单项。不同版本界面布局可能略有差异但核心参数就那几个SIP Server ID / 国标编号就是你对外要提供的 20 位编号SIP 服务监听地址/本机 IPLiveGBS 用于 SIP 通信的网卡 IPSIP 服务端口默认 5060也可能被改过。把这几个值记下来和上一节说的对外提供地址做一下区分。比如本机内网 IP 是192.168.10.88但对外映射后上级平台访问的是203.0.113.5那你给上级平台填地址时填的是后者。如果两者一样那就最省事。需要特别提醒的是如果你修改过 LiveGBS 的 SIP 端口、SIP Server ID 这类参数一般需要重启对应的国标服务进程才会完全生效。不要改完立刻往下走以为保存了就完事了。我遇到过几次对方说“我改了端口啊”但抓包发现实际监听端口还是旧的就是因为服务没有重启或者配置没重新加载。改完参数后建议顺手在服务器上用netstat -lnup | grep 5060确认一下监听状态确保配置真实生效了再继续。3.2 第二步确认本级域编码和认证密码别只盯着三个参数很多对接失败其实不是三个主参数填错而是漏了配套的“认证密码”和“域编码”。LiveGBS 作为下级向上级注册时信令里会携带 SIP 域信息并且要带摘要认证凭证。上级平台在添加下级的时候一般也需要配置一个“注册密码”或者“接入密码”。密码必须和 LiveGBS 里配置的注册密码一致否则信令能到但每次都在 401 之后认证失败。这里有个细节在 SIP 注册流程里401 响应是正常流程的一部分不代表失败。上级平台收到 REGISTER 之后会回一个 401里面带一个认证挑战码LiveGBS 收到后用配置的密码计算摘要响应再发第二次 REGISTER对方校验通过之后才回 200 OK。所以如果你抓包看到 401 反而说明网络和基本参数是通的重点检查密码就可以了。域编码这个东西不同平台的叫法也很多有的叫“SIP 域”有的叫“域 ID”。一般就是行政区划编码 行业编码那 10 位数字例如3402000000。在 LiveGBS 里本级域通常自动根据国标编号的前几位生成不用手动填。但你在配合上级平台填写对接表时如果对方问“下级域”你就要知道指的是这个而不是完整 20 位的 SIP Server ID。3.3 第三步在把参数发给对方之前自己做一次连通性自测别急着把对接表发出去。在 LiveGBS 服务器上先自测一下本机 SIP 监听确实正常再用上级平台给你的 IP 和端口反向测一下对方能不能通。这里最常用的两个命令是telnet和nc。如果是 Linux 服务器测 UDP 端口用ncnc -vuz -w 3 192.168.10.200 5060注意nc -u的探测在某些系统上不能完全保证准确因为 UDP 无连接端口是否开放本身就不像 TCP 那么明确。不过至少能看出来本机到目标的网络路径通不通。测 TCP 端口就直接用 telnettelnet 192.168.10.200 5060如果你的上级平台 SIP 监听的是 TCP 5060telnet 能连上就说明基本链路没问题。如果上级平台给的是一个公网映射地址就先 ping 通不通、再 telnet/nc 测端口通不通最后才涉及信令层面的问题。这一套做完基本能排除“地址填错”“防火墙拦截”“安全组没放行”这类纯网络问题。注意云服务器环境里除了操作系统本身的防火墙firewalld/iptables还要检查云平台的安全组规则。安全组没有放行对应 UDP 端口是云上部署最隐蔽的坑很多人在服务器上排查半天最后发现是安全组的事。4. 级联注册不成功按信令链路逐段排查参数都给过去了上级平台也把下级信息加上了结果状态还是“离线”。这时候不要急着反复改参数更不要一上来就把两边平台的配置全重做一遍。按信令链路的顺序一段一段排查通常很快就能定位。4.1 第一步抓包确认“信令有没有到家”排查级联问题第一件事永远是抓包。无论对方平台界面显示的日志多啰嗦都不如自己在服务器上直接看报文直观。在 LiveGBS 服务器上用 tcpdump 抓 SIP 端口tcpdump -i any port 5060 -s 0 -w /tmp/livegbs_sip.pcap然后让上级平台那边触发一下注册动作或者直接重启 LiveGBS 的国标服务让它重新主动发起注册。抓个两三分钟用 Wireshark 打开 pcap 文件看有没有 REGISTER 请求发出、有没有响应回来。这时候分三种情况本机发出了 REGISTER但完全没有响应报文问题基本在网络层地址填错、端口不通、路由不可达、防火墙丢包都有可能回到上一节的连通性自测逐项查。本机发出的 REGISTER 收到了 401说明信令已经打通到对方平台了接下来重点检查认证密码、摘要算法、编号是否匹配。本机压根没发出 REGISTER问题在 LiveGBS 本级配置先检查你是不是把级联配置里的上级平台地址、端口填对了再检查国标服务进程是否在正常运行、SIP 监听是否正常。抓包这件事很多新手会觉得难但它是排查网络问题效率最高的手段。你在这上面花的半小时大概率比在两边平台界面里瞎点一天要值得。有条件的最好在 LiveGBS 服务器和上级平台之间找一个汇聚点同时抓包这样能快速区隔是发送侧的问题、接收侧的问题还是中间链路的问题。没有条件那就先在 LiveGBS 这侧抓至少能判断报文有没有出得去。4.2 常见 SIP 状态码速查表看到这个码就明白该查什么SIP 协议的状态码比 HTTP 简单但含义准确记住的人不多。搞清下面这张表大部分注册问题都能自诊断状态码含义优先排查方向401未授权服务器要求客户端认证正常流程第一步重点检查密码是否一致403禁止访问认证未通过密码错误、摘要计算方式不对、编号不对404不存在找不到这个用户或平台国标编号在对方平台未登记或填错了编号408请求超时网络不通、信令被防火墙拦截、端口不对486线路忙对方平台资源问题重试或联系对方500服务器内部错误对方平台配置异常或版本兼容问题建议查平台侧日志这里要特意说一下 403 和 404 的区别。如果你在抓包里看到 REGISTER 之后跟着 403且反复重试都是 403那不用再怀疑网络了问题在身份认证。密码不一致、国标编号和用户名对不上是最大嫌疑。如果你看到 404那基本就是对方平台的下级列表里还没加你这个编号或者你填的 SIP Server ID 和对方登记的主键不一致。把这些状态码记下来在对接群里描述问题的时候也会高效很多——直接说“我这边抓包看到 REGISTER 后回 403”对方平台的技术支持一听就知道要查什么而不是来回问“你离线吗你看状态了吗”4.3 几个容易忽略的细节时间同步、大小写、注册周期信令层的参数都对了还有几个“元凶”级的小细节往往导致问题迟迟不能收敛。第一个是时间同步。GB28181 的 SIP 信令里带时间戳摘要认证也和时间有关联。LiveGBS 服务器和上级平台服务器之间时间差太大有可能导致认证一直失败或者信令校验不通过。这种问题很隐蔽因为你抓包看到的报文格式都对401 之后却始终认证失败。解决办法简单粗暴给 LiveGBS 服务器配好 NTP 时间同步并确保和上级平台的时间偏差在一分钟以内。第二个是密码和编号的大小写、前后空格。SIP 密码有些平台是严格区分大小写的从对接文档里复制过来时容易带一个看不见的换行符。国标编号虽然全是数字但有些平台界面有“自动补全”或者“格式校验”功能粘贴时可能把格式搞坏。每次填完我都建议肉眼读一遍再对比一下两边平台的配置截图确认完全一致。第三个是注册周期和心跳。GB28181 里下级平台通常每隔一段时间要重新注册一次同时用心跳报文维持在线状态。如果上级平台那边对注册周期有严格要求而 LiveGBS 侧的心跳间隔配置得和对方不匹配可能出现“刚注册完是在线几分钟后又掉线”的诡异现象。遇到这种间歇性离线的优先看两边的 SIP 心跳周期Keep Alive配置通常把数值改成一致问题就消失了。5. 2022 版标准和第三方平台对接时别忽略的额外事项标题里既然带了“国标2022”这个点也要说透。GB/T 28181-2022 是替代 2016 版的新版标准。很多实施人员对它的认知停留在“好像有新版本”的层面真正到了和第三方平台对接的时候才发现版本差异会直接影响配置策略。5.1 2022 版在级联相关的变化多数和“安全”有关和 2016 版相比2022 版在级联这个环节上最明显的变化集中在三块一是信令传输安全建议或要求支持 TLS 加密 SIP 信令二是密码安全策略对 SIP 认证密码的复杂度、摘要算法等提出了更高要求三是增加了国密相关能力也就是在设备接入、信令安全上支持国家密码算法。翻译成对接时的现实影响就是如果上级平台用的是支持 2022 版的新软件版本在添加下级平台时可能会多出“信令加密方式”“是否启用国密”“认证算法选择”这类选项。你在 LiveGBS 侧如果还是出厂默认配置没有启用对应能力两边对不上就会出现“参数都对、密码也对、就是不注册成功”的情况。不过据我实际接触到的项目情况目前市面上很多第三方平台在对接时默认仍然走的是兼容模式也就是优先按 2016 版的方式完成注册2022 版的新特性作为可选能力按需启用。所以对接时不用一上来就把所有新特性都打开先按双方平台默认模式把链路跑通然后再根据项目要求逐步启用安全功能。如果对方明确要求按 2022 版安全模式对接那就需要确认 LiveGBS 当前版本对 TLS、国密这些能力的支持情况再决定是否需要升级版本。5.2 实际对接第三方平台时的推进建议信息对称比什么都重要和容易和各种第三方国标平台做对接你会发现一个共同规律每个平台的术语体系不完全一样但底层的对接要素是同一套。有的平台叫“上级域”有的叫“中心平台”有的界面里甚至没有“下级”这个概念而是统一用“接入终端”来管理。这个时候不要被界面文案带偏抓住本质三要素就行SIP 服务器 ID、SIP 服务地址、SIP 服务端口再加一个认证密码。对接推进过程中我最常用的做法是先发一个标准对接信息表让对方填包含“上级平台国标编号、上级平台 SIP IP、上级平台 SIP 端口、传输协议UDP/TCP、是否启用加密、接入密码如有”然后我再把这些参数填到 LiveGBS 的级联配置里。同时我把 LiveGBS 这边的三个参数整理好回复给对方请对方填入他们的下级列表。两边同时填、同时核查能避免很多“我以为你填了你以为我填了”的歧义。另外遇到注册不上但抓包也看不出明显问题的时候不要忘了查平台侧日志。LiveGBS 有国标服务的日志第三方平台一般也有接入日志或信令日志。两边日志的时间戳一对上基本就能定位是谁的问题。别只盯着一边平台折腾级联是双向的排查也必须是双向的。5.3 上线前的最终配置清单照着做一遍能省一半联调时间最后把我自己的配置清单整理出来。每次做新的级联对接我都会照着过一遍虽然不是每一次都需要全部修改但至少能保证没有低级遗漏确认 LiveGBS 的 SIP Server ID 是 20 位合法编号与上级平台登记的下级编号一致确认 LiveGBS 的 SIP 监听端口已固定且防火墙/安全组已放行该端口确认给上级平台填写的地址从对方视角可达必要时做 NAT 映射确认上级平台的 SIP 服务器 ID、IP、端口已正确填入 LiveGBS 级联配置确认传输协议UDP/TCP两边一致确认注册密码两边一致且无多余空格确认服务器时间已通过 NTP 同步确认 LiveGBS 国标服务已重启配置已生效确认上级平台已添加下级信息并且状态为“可接入/在线”抓包验证 REGISTER/401/200 OK 的完整流程再谈后续拉流。这套流程做完绝大多数级联问题都能暴露出来。剩下的多半就是第三方平台自身实现差异那就属于“联系平台技术支持”的范畴了拿着抓包文件和状态码去问效率会高很多。按我自己的操作体会级联对接这件事情90% 的坑都出在信息不对等和参数配置不一致上。真正复杂的情况其实是少数。只要能在动手之前把“哪一栏填谁的”这个底层逻辑理清楚再配合抓包验证整个过程会比你想象中顺利得多。下一次再有人问“国标编号、地址、端口号怎么办”你就可以直接把本文发给他然后告诉他先分清楚“我是谁、我住哪、从哪个门找我”问题通常就解决了一半。