企业官网建设流程全解析

“作为下级级联到海康、大华、宇视这类第三方国标平台，对方要我们提供国标编号、地址、端口号，这三个东西到底该填什么？”——这基本是 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 服务器 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 监听端口是多少没有任何关系。同理，上级平台填你的端口，也只需要对准你这边实际监听的端口。两个平台之间的端口是可以完全不同的。

为了便于对照，我习惯用一个表格来整理这三个参数的实际填法：

3. LiveGBS 侧三步拿参数：抄对配置再发给对方

搞清楚概念之后，实操其实很快。下面我按步骤走一遍，告诉你到哪找这三个参数、怎么确认它是对的，以及在发对接表给对方之前，自己先做哪几步自检。

3.1 第一步：在 LiveGBS 管理后台定位 SIP 配置

登录 LiveGBS 的 Web 管理后台，一般在左侧菜单里找“国标配置”或者“SIP 配置”这一类的菜单项。不同版本界面布局可能略有差异，但核心参数就那几个：

• SIP Server ID / 国标编号：就是你对外要提供的 20 位编号；
• SIP 服务监听地址/本机 IP：LiveGBS 用于 SIP 通信的网卡 IP；
• SIP 服务端口：默认 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 端口用nc：

nc -vuz -w 3 192.168.10.200 5060

注意，nc -u的探测在某些系统上不能完全保证准确，因为 UDP 无连接，端口是否开放本身就不像 TCP 那么明确。不过至少能看出来本机到目标的网络路径通不通。测 TCP 端口就直接用 telnet：

telnet 192.168.10.200 5060

如果你的上级平台 SIP 监听的是 TCP 5060，telnet 能连上就说明基本链路没问题。如果上级平台给的是一个公网映射地址，就先 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 简单，但含义准确记住的人不多。搞清下面这张表，大部分注册问题都能自诊断：

这里要特意说一下 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 上线前的最终配置清单：照着做一遍，能省一半联调时间

最后，把我自己的配置清单整理出来。每次做新的级联对接，我都会照着过一遍，虽然不是每一次都需要全部修改，但至少能保证没有低级遗漏：

1. 确认 LiveGBS 的 SIP Server ID 是 20 位合法编号，与上级平台登记的下级编号一致；
2. 确认 LiveGBS 的 SIP 监听端口已固定，且防火墙/安全组已放行该端口；
3. 确认给上级平台填写的地址，从对方视角可达，必要时做 NAT 映射；
4. 确认上级平台的 SIP 服务器 ID、IP、端口已正确填入 LiveGBS 级联配置；
5. 确认传输协议（UDP/TCP）两边一致；
6. 确认注册密码两边一致，且无多余空格；
7. 确认服务器时间已通过 NTP 同步；
8. 确认 LiveGBS 国标服务已重启，配置已生效；
9. 确认上级平台已添加下级信息，并且状态为“可接入/在线”；
10. 抓包验证 REGISTER/401/200 OK 的完整流程，再谈后续拉流。

这套流程做完，绝大多数级联问题都能暴露出来。剩下的多半就是第三方平台自身实现差异，那就属于“联系平台技术支持”的范畴了，拿着抓包文件和状态码去问，效率会高很多。

按我自己的操作体会，级联对接这件事情，90% 的坑都出在信息不对等和参数配置不一致上。真正复杂的情况其实是少数。只要能在动手之前把“哪一栏填谁的”这个底层逻辑理清楚，再配合抓包验证，整个过程会比你想象中顺利得多。下一次再有人问“国标编号、地址、端口号怎么办”，你就可以直接把本文发给他，然后告诉他先分清楚“我是谁、我住哪、从哪个门找我”，问题通常就解决了一半。