简介基于Java实现的GB28181国标平台JGB28181面向安防监控与视频联网开发者用于快速搭建符合GB/T 28181协议的接入服务。压缩包共49个文件以43个Java源码为主配合2个XML、1个properties、1个YAML配置及Maven构建文件整体仅64KB轻量易部署。项目支持设备注册与恢复、目录查询、实时视频流TCP被动/UDP等核心功能适合具备一定Java基础、需要理解国标信令交互或进行二次开发的中高级工程师参考学习。通过修改config.properties中的参数即可编译运行便于快速验证信令流程阅读源码可借鉴平台的分层结构、消息解析与设备状态管理逻辑配合README.md可快速上手Maven与yml文件也展示了工程配置方式。已有4241人学习下载适合用作GB28181入门与落地的参考资料。1. JGB28181是什么一个Java实现的国标平台解决跨厂商设备接入的难题做安防平台集成的人早晚会撞上同一个需求把不同厂商的 IPC、NVR、DVR 统一接到自己的系统里。每家都有自己的 SDK但没人愿意挨个适配好在国标 GB/T 28181 规定了统一的信令和媒体交互方式。JGB28181 就是这样一个纯 Java 实现的 GB28181 平台侧组件用 SIP 协议对接设备用 RTP 接收媒体流再转给上层业务或播放端。它解决的是“协议互通”这一层问题让上层平台不用关心设备是哪家生产的。如果你正在做视频监控平台或者要给现有的 Java 系统加国标接入能力这个技术方向值得投入。它不是什么黑匣子从注册信令、心跳报文到媒体流包每一环都可以抓包验证。我在模拟项目 X 里从零搭过一套中间分别踩过注册鉴权、SSRC 未对齐、TCP 被动模式连不通这些坑基本把 GB28181 平台侧的常见问题都摸了一遍。下面按“协议原理→信令实现→媒体对接→排查→进阶”的顺序把能够复现的路径讲清楚顺带给出依赖、端口和超时参数你可以直接照着搭一个最小可用平台。2. 从SIP到媒体流GB28181协议核心与Java技术选型2.1 GB28181协议栈与平台需要处理的六个基础流程GB28181 本质上把 SIP 当作信令通道把 RTP 当作媒体通道。平台侧要做的核心事情是先让设备注册上来然后能查询目录、能点播、能回放、能控制云台。这六个基础流程都有固定的 SIP 消息组合平台所有业务功能几乎都建立在这几套交互之上。流程主要 SIP 方法关键字段设备注册REGISTERTo 标签、Authorization 摘要鉴权设备心跳MESSAGEContent-Type 为 MANSCDP XMLBody 里带 Keepalive目录查询MESSAGEBody 带 Catalog 查询 XML返回设备列表实时点播INVITE / ACKSDP 中携带 ssrc、媒体格式和收流地址录像回放INVITE / ACKSDP 中带 Download时间范围放在 t 字段云台控制MESSAGEBody 带 Control XML指令如 PTZ 方向、变倍设备推流时RTP 包的 Payload 最常见的是 96对应 PSMPEG Program Stream。也有部分设备支持 98/97分别对应 H.264 裸流和 H.265 裸流。平台在 SDP 协商时就要把这些格式全部列出来并按设备返回的 session 描述决定后续解析方式。还有一个容易被忽略的流程设备报警会通过 NOTIFY 主动上报平台侧要做好这个方法的应答否则设备侧会产生事件积压。2.2 Java侧协议栈选型JAIN SIP还是自研SIP解析很多 Java 团队第一次接触这个方向会去找 SIP Servlet 容器比如 JAIN SIP 加应用服务器。它确实能处理 SIP 事务状态机但部署重量大而且 GB28181 里的 MANSCDP XML、设备编码规则、国标地址格式这些内容并没有现成绑定。调试一条 SIP 消息还要翻容器日志对平台开发者来说不太友好。我一般会选择用 Netty 直接承载 UDP/TCP 监听自己写一个轻量 SIP 消息解析器。这个解析器只需要处理请求行、Via、From、To、Call-ID、CSeq、Contact、Expires、Authorization 这些标准头再把 body 里的 XML 单独拉出来解析。这样做的好处是信令状态机完全在自己手里遇到不符合预期的消息可以打印原始报文快速定位也容易接到 Spring Boot 里统一管理。项目结构可以保持得非常克制一个核心模块专注 SIP 解析和事务管理一个接入模块处理设备状态一个 API 模块对外暴露点播、回放接口。核心依赖只需要引入 Netty 和 Spring Boot下面这个 pom 片段可以作参考。dependency groupIdio.netty/groupId artifactIdnetty-all/artifactId version4.1.100.Final/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependencyNetty 版本不必写死选项目当前的稳定版即可。如果你是刚起步我建议先不要引入 SIP Servlet 容器因为 GB28181 设备的兼容性问题往往需要你直接看原始信令报文自研解析器能让你快速埋点打日志而不是在一个黑盒容器里猜状态。当然如果团队已经有很成熟的 Mobicents 经验继续用也没问题只是后续排障路径会不太一样。2.3 媒体流转发自己写RTP接收还是交给开源流媒体软件信令是 Java 的强项但媒体流转发不是。GB28181 设备普遍向平台发 RTP 包里面封装的是 PS 流。直接从 PS 流里解出 H.264/H.265 裸流还要处理 RTP 时间戳、SSRC、丢包重排序、I 帧定位这属于媒体工程和 Java 业务关系不大。硬要用 Java 从头写一套 PS 解复用短期内能跑通但长期面对几百路并发和不同设备丢包行为会非常吃力。常见做法是平台只做 SIP 信令和媒体协商把媒体端口信息配置给一个独立的流媒体软件让它去接收 RTP、解析 PS、再向上层输出 RTSP/FLV/HLS。Java 平台通过 HTTP API 调用流媒体软件完成点播和收流。这个拆分方式让系统稳定也便于后续横向扩展。成熟的开源流媒体软件都提供这类收流接口以 GB28181 方式对接时只需要告诉它本机监听端口和是否使用 TCP 模式。如果项目规模很小只有一两路点播可以用 Java 写一个简单的 RTP 转发进程只做 UDP 接收再转发给播放器或推流端不做解复用和转码。这样也能满足简单预览。但从可维护性讲我不建议把媒体复杂逻辑写进业务后台里一旦并发上来GC、锁、线程调度都会被媒体链路拖累那才是真正让人头疼的问题。3. 信令模块落地用Java写一个能跑通的SIP注册与心跳处理3.1 用Netty绑定UDP 5060端口起步一个SIP监听器SIP 默认端口是 5060最常见的是 UDP 承载。用 Netty 绑定 UDP 端口这件事本身很简单但不少项目会忽略接收缓冲区的大小。设备数量上来以后UDP 包堆积会直接导致注册和心跳丢包那排查起来真的很玄学。建议把 SO_RCVBUF 和 SO_SNDBUF 都显式调大并打开 SO_REUSEADDR。下面这段代码是 UDP 监听的最小骨架。EventLoopGroup group new NioEventLoopGroup(1); try { Bootstrap b new Bootstrap(); b.group(group) .channel(NioDatagramChannel.class) .option(ChannelOption.SO_REUSEADDR, true) .option(ChannelOption.SO_RCVBUF, 1024 * 1024) .handler(new ChannelInitializerDatagramChannel() { Override protected void initChannel(DatagramChannel ch) { ch.pipeline().addLast(new SipMessageDecoder()); ch.pipeline().addLast(new SipServerHandler()); } }); b.bind(5060).sync().channel().closeFuture().await(); } finally { group.shutdownGracefully(); }EventLoop 的线程数不要设得太大SIP 消息本身不需要大量计算一个 EventLoop 负责 UDP 读取就够。收到消息后的业务处理要交给后端线程池避免 Netty IO 线程被阻塞。如果你的平台同时绑定多个 IP 地址可以创建多个 Bootstrap分别绑定不同 IP 或端口但这需要把设备域名的对应关系管理好不要出现同一设备在不同地址上反复注册。3.2 解析SIP报文从ByteBuf到SipMessageSIP 报文是文本协议头部和 body 之间有一个空行。解析时不能简单按换行切因为 body 里的 XML 也可能带换行。正确做法是先读到空行再从 Content-Length 头读取 body 字节数。下面这个 Decoder 是简化版本主要演示解析入口。public class SipMessageDecoder extends ByteToMessageDecoder { Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) { byte[] bytes new byte[in.readableBytes()]; in.readBytes(bytes); String raw new String(bytes, StandardCharsets.UTF_8); // 简化处理按 \r\n\r\n 拆头尾 int pos raw.indexOf(\r\n\r\n); if (pos 0) { return; } String headPart raw.substring(0, pos); String body raw.substring(pos 4); SipMessage msg new SipMessage(); // 设置首行例如 REGISTER sip:xxx SIP/2.0 msg.setStartLine(headPart.split(\r\n)[0]); // 解析头部键值body 单独存 MapString, String headers parseHeaders(headPart); msg.setHeaders(headers); msg.setBody(body); out.add(msg); } }这里有一个关键点UDP 不一定保证报文完整如果网络分片导致一个 SIP 包被拆成多个 UDP 包这个 Decoder 会直接丢弃。实际生产中SIP 报文通常很小很少触发 IP 分片但有一种情况很常见设备发送的 XML body 特别长超过了 MTU导致分片。遇到这种情况平台侧不应盲目调大 Netty 的 maxFrameLength而应该要求设备配合缩短 XML 数据长度或者改用 TCP 承载信令。3.3 注册与鉴权401挑战和MD5摘要GB28181 的注册鉴权采用 SIP 摘要认证流程是平台收到 REGISTER如果请求头里没有 Authorization就返回 401 并带上 Nonce设备收到 401 后用密码计算摘要再次发起 REGISTER平台校验通过后返回 200。这段逻辑看起来简单实际翻车点很多最常见的是请求 URI 计算不一致。下面是最小可运行的鉴权处理逻辑。void onRegister(SipMessage req) { String uri req.getHeader(To); String deviceId parseDeviceId(uri); if (req.getHeader(Authorization) null) { String nonce generateNonce(); nonceStore.put(deviceId, nonce); sendResponse(req, 401, buildChallenge(nonce)); return; } String nonce nonceStore.get(deviceId); if (nonce null) { sendResponse(req, 403, Nonce expired); return; } // 计算摘要注意 uri 必须与设备请求中的 Request-URI 一致 String expected md5( md5(devicePassword : nonce) : req.getHeader(Authorization) ); String received extractDigest(req.getHeader(Authorization)); if (expected.equalsIgnoreCase(received)) { devices.put(deviceId, new DeviceStatus(req.getSourceAddress())); sendResponse(req, 200, buildOK()); } else { sendResponse(req, 403, Bad password); } }Nonce 不能永不过期一般保存 3 分钟即可。密码获取方式分两种一种是从设备的国标配置里读另一种是平台把密码写入设备。无论哪种平台侧存储的密码必须和计算时使用的字符完全一致不能有前后空格或大小写差异。建议在调试模式下把 expected 和 received 都打出来这是一眼定位问题最快的办法。3.4 心跳处理设备在线状态与离线判定设备心跳大部分通过 MESSAGE 方法发送body 是一个 MANSCDP 的 Keepalive XML。平台收到后要更新设备的最后心跳时间同时要用一个定时任务扫描所有设备超过阈值就标记离线。如果直接依赖数据库去判断在线状态几百台设备就会把库拖垮正确做法是把状态放在内存里异步落库。心跳超时时间建议设置成设备心跳间隔的 3 倍以上。有的设备默认心跳间隔 60 秒网络稍微抖动就收不到一两个包如果你设 120 秒就很容易误判离线。这个超时也要区分设备类型可以在设备注册时带一个心跳间隔参数平台按实际间隔动态计算。// 设备心跳处理 if (body.contains(Keepalive)) { String deviceId extractXml(body, DeviceID); DeviceStatus status devices.get(deviceId); if (status ! null) { status.setLastHeartbeat(System.currentTimeMillis()); status.setAlive(true); } }定时离线巡检我用的是固定周期调度比如每 30 秒跑一次。检查逻辑是遍历设备列表用当前时间减去最后心跳时间超过阈值就把状态置为离线并触发上层告警。设备重新注册后再次上线不需要额外处理历史会话因为 SIP 的Call-ID 会变化。4. 点播与媒体流对接把摄像头视频拉回平台的完整路径4.1 实时点播的SIP信令流程平台主动发起INVITE实时点播是平台作为 UAC 向设备发送 INVITE设备返回 200 OK 后平台回 ACK。INVITE 的关键在 SDP设备会按照 SDP 里指定的 IP、端口、SSRC 推送 RTP 流。SDP 里用的媒体格式要覆盖设备可能支持的 96、98、97不能只写一种否则有些设备不会回 200。下面这段代码演示 SDP 字符串的拼接逻辑。String sdp v0\r\n o platformId 0 0 IN IP4 localIp \r\n sPlay\r\n cIN IP4 localIp \r\n t0 0\r\n mvideo mediaPort RTP/AVP 96 98 97\r\n arecvonly\r\n artpmap:96 PS/90000\r\n artpmap:98 H264/90000\r\n artpmap:97 H265/90000\r\n assrc: ssrc \r\n;mvideo 后面的端口就是平台接收媒体流的端口这个端口要和实际绑定监听的端口完全一致。如果平台使用了流媒体软件收流这里填的端口就必须是流媒体软件分配出来的收流端口而不是平台的某个业务端口。很多黑屏问题都出在这里设备按照 SDP 发了一个端口但真正收流的地方根本没监听。还有一个容易忽略的参数arecvonly。写了它设备就不会期待平台反向推流或者建立复杂的媒体会话不写部分设备会进入双向媒体协商导致点播迟迟不开始。4.2 接收RTP流并判断是否可用排序、SSRC校验、RTCP处理如果媒体流由 Java 进程直接接收需要在 UDP 端口上持续读包判断 RTP 头里的 SSRC 是否和 SDP 下发的 SSRC 一致。很多设备使用固定 SSRC但也有一些设备每次会话重新生成所以平台侧不应该把 SSRC 写死成预期值而是要允许前几个包校准。下面是一个简化版的 RTP 接收循环。rtpSocket new DatagramSocket(mediaPort); byte[] buf new byte[65535]; while (running) { DatagramPacket dp new DatagramPacket(buf, buf.length); rtpSocket.receive(dp); if (dp.getLength() 12) continue; int ssrc ((buf[8] 0xFF) 24) | ((buf[9] 0xFF) 16) | ((buf[10] 0xFF) 8) | (buf[11] 0xFF); if (expectSsrc 0) { expectSsrc ssrc; // 首包校准 } else if (ssrc ! expectSsrc) { continue; } // 按 RTP seq 做排序交给 PS 解析器 payloadQueue.offer(Arrays.copyOfRange(buf, 12, dp.getLength())); }RTP 包做好排序非常必要。网络抖动会导致乱序PS 流是按连续 RTP 包组包的一旦乱序解出来的图像会出现马赛克甚至直接卡住。建议在收到包后先做一个小窗口排序比如 50 个包以内按序列号重排超过 50 的直接丢弃避免堆积。同时平台需要响应 RTCP 包因为设备在推流时也会发送 RTCP RR/SR平台如果完全忽略 RTCP部分设备会认为对端异常继而降低码率或停止推流。4.3 把PS流转给流媒体软件Java进程内的RTP转发如果 Java 平台已经通过信令协商好媒体端口但不想承担解复用压力可以让流媒体软件在另一个端口收流。最直接的落地方式是Java 收到 RTP 包后去掉 RTP 头把载荷用本机 UDP 转发给流媒体软件收流端口让流媒体软件完成 PS 解析和输出。这种方式适合媒体规模不大或者需要完全掌控转发策略的场景。更推荐的做法是让流媒体软件直接收设备的 RTP由流媒体软件提供收流端口和收流地址Java 平台拿到这些信息后写在 INVITE 的 SDP 里这样 RTP 包不经过 Java 进程时延和抖动都能更低。// 假设 mediaServer 是流媒体软件的客户端封装 MediaPort mp mediaServer.createRtpServer(localIp, 0, GB28181, false); String mediaPort String.valueOf(mp.getPort()); String mediaIp mp.getIp(); // 把 mediaIp 和 mediaPort 拼入 SDP 的 c 和 mvideo 行这里有一个边界需要注意流媒体软件如果和平台部署在不同机器SDP 里的 c 和 o 要填流媒体软件所在的 IP不能填平台自身的 IP。设备向这个 IP 推流平台信令所在机器的防火墙需要放行媒体端口范围。很多团队在初调时只用 TCP 模式设备推流出来一堆连接但服务器防火墙只开了 5060导致信令通了媒体全挂这类问题排查起来非常耗时。5. 设备接入常见问题排查注册失败、黑屏、离线反复的现场处理5.1 注册失败401之后一直403现象设备一直报注册失败平台日志显示平台返回了 401设备也带了 Authorization 重新注册但每次校验都返回 403。原因最常见的是 Nonce 过期后设备还在用旧的 Authorization 请求或者平台生成的 Nonce 没有和后端存储绑定。另一个高频原因是请求 URI 不一致有些设备注册时 Request-Line 写的是REGISTER sip:34020000001320000001192.168.1.10 SIP/2.0而 Authorization 摘要里的 uri 也带上 IP平台计算摘要时如果拿纯域名或纯 IP 去算就会不一致。解决先把平台日志里的 expected 和 received 摘要值打出来对比。两者不一致就检查 password、nonce、uri 三个输入。Nonce 校验放宽到 5 分钟避免设备因时间偏差重发失败。同时把密码存储在单独配置表里不使用全局统一密码覆盖因为不同设备可能被人为改成不同密码。5.2 点播黑屏设备推了流但画面不出来现象INVITE 信令流程全部走通ACK 也发了但播放器一直黑屏。抓包能看到设备发来了 RTP 包平台也收到了就是不出画面。原因最常见的是 RTP 包里的 SSRC 和 SDP 下发的 ssrc 不一致设备实际使用的 SSRC 可能是随机生成的平台如果按固定 SSRC 过滤包就会把所有 RTP 包都丢弃。其次是 PS 封装问题一些设备没有严格按照 PS 标准封装直接发了裸 H.264平台还在用 PS 解析自然什么都解不出来。解决抓包后先看 RTP 报文里 SSRC 字段和平台日志里的入流会话 SSRC 对比。如果不同就在平台侧放开 SSRC 限制用首包校准。再看 RTP Payload Type 是否和 SDP 协商的一致比如协商的是 96实际发的是 98那就说明设备没有按 SDP 来需要在 INVITE 里去掉 96 只保留 98 强制设备走裸流或者根据实际 PT 动态选择解析器。5.3 设备频繁离线心跳超时导致反复上下线现象设备上线后每隔几分钟就掉线又上线平台操作日志里全是 REGISTER 和心跳消息设备列表一直闪动。原因心跳超时阈值设得太短。很多设备心跳间隔 65 秒平台设置的超时是 120 秒理论上有两次心跳缓冲但如果中间有一次网络抖动导致丢包就会出现误判。还有一个隐性原因是心跳 MESSAGE 里带的主体是 MANSCDP XML平台解析时如果只匹配Keepalive而忽略了 namespace 或者大小写差异也会把有效心跳当作无效报文。解决把心跳超时统一设成 180 秒并让设备在线状态在超时后不立即删除而是先进入可疑状态等待下一个心跳。同时完善 MANSCDP XML 解析不要用字符串 contains 判断尽量用 XML 解析框架避免Keepalive里多了空格或者属性导致误判。对于 NAT 环境设备通过公网接入时还要在 NAT 设备上配置 UDP 端口映射的老化时间避免映射失效导致信令绕路。5.4 录像回放一直转圈INVITE里的Download参数不对现象平台发起录像回放播放器一直等待没有任何视频流到达。原因GB28181 的回放和实时点播在 SDP 上语义不同。实时点播的 sPlay回放需要 sDownload如果不带 Download设备可能默认回话是实时流不回历史录像。另一个原因是回放的时间段没有正确写到 SDP 的 t 字段里设备无法判断要回放哪段时间。解决在 INVITE 的 SDP 里显式设置sDownload同时把开始时间和结束时间按 NTP 格式写在t0 0或t开始 结束中。设备返回的 200 OK 如果携带了 media 信息平台要选择视频流并回 ACK。可以对比实时点播和回放的 INVITE 报文通常一眼就能看出差异。5.5 平台收不到设备心跳UDP源端口的变化现象设备注册成功后平台在短时间内能收到心跳但过了一段时间就判定离线设备侧却显示自己在正常发送。原因很多设备在 NAT 或者多出口网络中UDP 包的源端口每隔一段时间会变化。平台如果按照第一次收到设备的源 IP 和端口去匹配后续端口变化后设备状态就被认为断连。另外平台往旧的源端口回复心跳响应设备也收不到。解决用设备 ID 作为设备身份标识每次收到来自该设备 ID 的信令时用最新包的源 IP 和端口更新设备状态里的信令地址。所有发给该设备的响应和之后的 INVITE 都发往最新地址而不是用注册时的地址。模拟项目 X 里就吃过这个亏后来统一改成了设备 ID 索引当前信令地址模型这条坑基本消失。6. 验证与进阶用抓包和自动化压测确认平台可用再谈集群化6.1 抓包验证看信令用sngrep看媒体用Wireshark刚开始调 JGB28181 时不要只在日志里看抓包是最快的方式。信令层面用 sngrep 实时监听 5060 端口能看到完整的注册和点播 SIP 流程哪一步没响应、哪一步回码不对都一目了然。媒体层面用 tcpdump 抓一段时间再导入 Wireshark 分析 RTSP/RTP 流确认设备是否真的在推流。sngrep -d any port 5060 tcpdump -i any udp port 5060 or udp portrange 10000-20000 -w gb28181.pcap抓包时注意把媒体端口范围也抓进去不要只抓 5060。Wireshark 打开 pcap 后可以按 RTP 流过滤查看包的 sequence 是否有跳变、是否出现乱序再通过 RTP Stream 分析窗口看丢包率。如果设备推的是 PS 流Wireshark 能识别出来并且显示出第一个字节的 00 00 01 BA 起始码这样就能确认 PS 封装是否正常。这些验证手段能帮你把绝大多数“信令通了但不稳定”的疑难杂症缩小到具体一层。6.2 自动化冒烟测试用脚本模拟设备注册与心跳平台加入新功能后不能每次都靠真机手动验证。我习惯准备一个简单的模拟国标设备脚本用 Netcat 往平台发 REGISTER 和 MESSAGE 心跳再观察平台是否返回 200。这样能在没有真实摄像头的情况下跑通链路也可以顺便压一下信令节点的吞吐量。for i in $(seq 1 100); do (echo REGISTER sip:34020000001320000001127.0.0.1 SIP/2.0 echo Via: SIP/2.0/UDP 127.0.0.1:$((5000i));branchz9hG4bK-$i echo From: sip:34020000001320000001127.0.0.1;tag$i echo To: sip:34020000001320000001127.0.0.1 echo Call-ID: smoke-$i echo CSeq: 1 REGISTER echo Max-Forwards: 70 echo Content-Length: 0 echo) | nc -u -w1 127.0.0.1 5060 done脚本里每条消息用不同源端口和 Call-ID能避免平台按连接去重。压测时观察平台日志里响应耗时和线程池活跃度。如果发现响应延迟上升优先看 Netty 的 worker 线程是否被阻塞。需要强调每种设备的 SIP 交互细节存在差异脚本只能做冒烟不能完全替代真机兼容性测试但至少能帮你迅速回归信令模块避免部门后合并代码把协议栈改坏。6.3 集群化扩展信令无状态化、设备绑定与媒体分派上百路以内单机平台完全没有问题。但如果你要把平台做到上千路必须把信令、媒体和业务拆开。信令节点可以做成无状态SIP 事务状态不落本地注册信息放到外部缓存用设备 ID 做一致性哈希绑定到具体节点。这样设备每次发消息都能被路由到正确的节点也不会因为节点重启导致设备状态丢失。媒体分派建议用哈希算法把设备 ID 映射到固定媒体节点同一路设备的所有媒体流落在同一个节点上减少跨节点拉流。如果设备跨机房接入信令和媒体的网络路径要分别评估最好让媒体流不经过业务节点直接由流媒体节点接收和分发。JGB28181 这类平台最忌讳的就是把信令和媒体揉在一个进程里一旦媒体流量上来SIP 事务响应延迟会直接影响注册和心跳所以集群化第一步就是把两者从部署上切干净。另外Netty 线程模型在集群化后要重新调参。Worker 线程数不要设置成 CPU 核数的很多倍一般不超过核数的 2 倍接入设备数增加时把心跳处理放到独立线程池避免注册洪峰占满点播事务线程。我在模拟项目 X 中早期就是用单线程池处理所有 SIP 消息某次设备批量重启时报文堆积平台直接失去响应换成多线程池加权轮询后才真正把稳定性捡回来。最后提一个习惯每次改动信令或媒体相关代码我都会先看一次抓包文件确认消息交互顺序没有变化。GB28181 平台的兼容性很大程度上不是靠代码写得多优美而是靠对协议细节的敬畏。多留一份抓包记录少熬一次夜。希望帮到你。本文还有配套的精品资源点击获取