WVP-GB28181-pro 是国内基于 GB/T 28181 国标协议的视频监控管理平台,2020 年 GitHub 上 648540858/wvp-GB28181-pro 仓库 star 数已经超过 4k。它的核心是用 JAIN SIP 协议栈做信令服务,把 GB28181 设备(摄像头、NVR、平台)注册到平台,然后做实时视频流转发、云端录像、录像回放、级联、报警等。本文从源码层做一次完整剖析。
本文写于 2020 年 9 月——WVP-GB28181-pro 1.x 时代。该项目至今仍在持续迭代。
一、GB28181 协议基础
GB/T 28181-2016《安全防范视频监控联网系统信息传输、交换、控制技术要求》是中国公安部主导的国标协议,用于把不同厂商的摄像头/NVR 统一接入到一个平台上。
1.1 协议核心特征
- 信令协议:SIP(RFC 3261)+ SDP
- 传输层:UDP(默认)/ TCP
- 媒体流:RTP/RTCP(基于 RTSP 推流或 PS 封装的 RTP)
- 编解码:H.264 / H.265 / SVAC
- 核心交互:注册、目录查询、实时点播、回放、下载、报警、级联
1.2 GB28181 与 ONVIF 的区别
| 维度 | GB28181 | ONVIF |
|---|---|---|
| 国别 | 中国国标 | 国际标准 |
| 协议 | SIP | HTTP + RTSP |
| 推送方式 | 主动注册 + 平台调度 | 设备发现 + RTSP 拉流 |
| 主要场景 | 平安城市、雪亮工程 | 企业园区、商业楼宇 |
| 厂商支持 | 海康/大华/宇视/科达 | Axis/Bosch/Hanwha |
二、WVP-GB28181-pro 项目架构
2.1 项目定位
WVP-GB28181-pro 是纯 Java 实现的 GB28181 国标信令网关 + 流媒体服务:
- 前端:Vue + Element UI(管理摄像头、用户、回放、录像)
- 后端:Spring Boot + JAIN SIP + ZLMediaKit(流媒体)
- 存储:MySQL(设备信息)+ Redis(信令缓存)+ MinIO/阿里 OSS(录像)
2.2 核心模块
| |
2.3 关键依赖
| |
三、SIP 信令栈核心:JAIN SIP API
3.1 SipProvider 实现
WVP 使用的 JAIN SIP 协议栈在 gov.nist.javax.sip 包下:
| |
三个核心能力:
- 发送 SIP 消息(REGISTER / INVITE / MESSAGE / BYE)
- 接收 SIP 消息(响应 + 异步事件)
- 管理 SIP 事务 + 对话(事务超时、重传)
3.2 SipListener 接口
| |
WVP 中所有 SIP 入口都通过 SipListener 接收,然后分发给具体的 ISIPProcessorObserver 处理。
四、SipLayer 服务端源码剖析
4.1 SipLayer 完整结构
| |
4.2 关键设计点
1. 双协议监听(TCP/UDP):
- GB28181 设备通常用 UDP 5060 端口
- 高级设备或跨网段用 TCP 5060 端口
- 同一进程需要同时维护两套
SipProvider
2. 多 IP 监听:
- 多网卡服务器需要监听所有 IP
tcpSipProviderMap/udpSipProviderMap按 IP 维度维护monitorIps列表去重,防止重复 bind
3. 启动顺序 @Order(10):
- Spring Boot
CommandLineRunner启动后立即初始化 @Order(10)保证在 Spring 主流程就绪后才启动 SIP- 失败的 SIP 初始化不会阻断 Web 服务
五、完整调用链:设备注册到目录查询
5.1 时序图
| |
5.2 调用链详解
阶段 1:设备注册
| |
阶段 2:心跳保活
| |
阶段 3:目录查询(Catalog Query)
| |
六、请求处理统一入口:ISIPRequestProcessor
6.1 处理器接口
| |
6.2 内置处理器
WVP 内部为每种 SIP 请求都实现了一个 ISIPRequestProcessor:
| Method | 处理器 | 用途 |
|---|---|---|
REGISTER | RegisterRequestProcessor | 设备注册 |
MESSAGE | MessageRequestProcessor | 消息分发(心跳/目录/报警) |
INVITE | InviteRequestProcessor | 实时点播 |
BYE | ByeRequestProcessor | 结束点播 |
SUBSCRIBE | SubscribeRequestProcessor | 事件订阅 |
ACK | AckRequestProcessor | INVITE 确认 |
OPTIONS | OptionsRequestProcessor | 能力探测 |
6.3 派发器实现
| |
设计模式:策略模式 + 依赖注入——新增请求类型只需要新增一个 ISIPRequestProcessor 实现,Spring 自动扫描注册。
七、流媒体集成:ZLMediaKit
WVP 本身不做媒体流转发,它把流媒体的工作交给 ZLMediaKit(一个基于 C++ 的高性能流媒体服务):
| |
7.1 ZLMediaKit 角色
- 接收端:通过 RTP 接收 PS 流(来自 GB28181 设备)
- 转换端:把 PS 流转换为 RTMP/HLS/WebRTC
- 分发端:把转换后的流推给浏览器/移动端/录像
7.2 WVP 调用 ZLMediaKit 的方式
| |
八、关键坑点与实战经验
8.1 SIP 端口冲突
| |
8.2 设备注册失败
| 现象 | 原因 | 解决 |
|---|---|---|
| 401 Unauthorized | 设备密码错误 | 检查 UserSetting 配置 |
| 408 Request Timeout | 网络不通 | 检查防火墙 + 端口 |
| 480 Temporarily Unavailable | 平台未就绪 | 检查 ZLMediaKit 状态 |
8.3 视频流拉不到
| 现象 | 原因 | 解决 |
|---|---|---|
| ZLMediaKit 返回错误 | 流地址配置错误 | 检查 stream_id |
| 客户端黑屏 | 编解码不兼容 | 强制转码 |
| 录像文件 0 字节 | 录制路径权限 | chown 给 WVP 用户 |
九、写在最后
WVP-GB28181-pro 的成功在于:
- 选型准确——Java 做信令网关(生态成熟、Spring Boot 快速开发)
- 解耦清晰——SIP 信令 + 媒体流分离(ZLMediaKit 处理高吞吐)
- 实战性强——适配海康/大华/宇视主流厂商设备
- 社区活跃——issue 响应快,文档持续更新
个人建议:
- 想要自建视频监控平台:WVP + ZLMediaKit 是国内最成熟的组合
- 商业项目:考虑EasyCVR / TSINGSEE 等商业产品(带 UI 和运维)
- 国家级项目:需要支持GB28181-2022 新国标(WVP 已部分支持)
参考资料
- GB/T 28181-2016 协议规范
- WVP-GB28181-pro GitHub
- ZLMediaKit 官方文档
- [JAIN SIP API 文档](https://docs.oracle.com/cd/E13203_01/tuxedo/tux90/ sip_java/javax/sip/SipListener.html)
十、2024+ 视角:GB28181-2022、AI 视频分析与 WebRTC 播放
本文写于 2020 年 9 月,WVP-GB28181-pro 至今仍是最活跃的国标信令网关。下面补充 2024-2026 行业关键变化:GB28181-2022 新国标、AI 视频分析、WebRTC 浏览器播放、ZLMediaKit 演进。
10.1 GB28181-2022 新国标:协议升级到"互联网友好"
GB/T 28181-2022 在 2023 年正式实施,对开发影响最大的是 4 件事:
- TCP 协议从可选升级到推荐——2020 时代用 UDP 5060 是默认,2024+ 因为防火墙/NAT,TCP 已成为企业内部部署首选
- H.265/HEVC 强制支持——
eladmin之类的旧版本 WVP 客户端无法解码 H.265 流,2024+ WVP-GB28181-pro 默认带 H.265 解码 - 信令通道支持 HTTPS / WSS——2020 时代 SIP 走 UDP 明文,2024+ 公安部等保 2.0 三级要求信令加密
- 多级级联 + 跨域互联——上/下级平台鉴权从 IP 白名单升级到 OAuth 2.0
WVP-GB28181-pro 在 2024 年的 2.0+ 版本(社区称为 WVP-PRO v2)已经默认兼容 2016 + 2022 双协议。
10.2 WVP 项目的关键演进(2020 → 2026)
| 维度 | 2020(v1.x) | 2024+(v2.x) |
|---|---|---|
| Spring Boot | 2.4.x | 3.2.x |
| JDK | 8 | 17 / 21 |
| SIP 协议栈 | jain-sip-ri 1.3.0-91 | mjSIP 或 RestComm 替代(社区维护) |
| 流媒体 | ZLMediaKit HTTP API | ZLMediaKit 25.x + SRS 5.x 双支持 |
| 前端 | Vue 2 + Element UI | Vue 3 + TypeScript + Vben |
| 协议支持 | GB28181-2016 | GB28181-2016 + 2022 双协议 |
| AI 集成 | 无 | 内置 AI 视频分析插件(火焰/安全帽/人脸) |
10.3 AI 视频分析:从"看到"到"看懂"
2020 年的 WVP 主要是"信令 + 流转",2024-2026 的核心增量是 AI 视频分析:
- 海康/大华原生 AI 摄像头(内置 NPU)——边缘推理,云端只收告警
- 云端 AI 分析插件(基于 YOLOv8 / RT-DETR)——WVP 接入 RTSP 流后调用 AI 服务,实现"事后分析 + 实时告警"
- 多模态大模型(LLaVA、GPT-4V)——2025-2026 的 WVP 高级版本可以"上传一张图,问 AI 视频里发生了什么"
实战架构(2025 主流):
| |
单纯做信令网关的 WVP 价值在 2025 年正在被压缩,“WVP + ZLMediaKit + AI 分析"的三件套才是完整方案。
10.4 WebRTC 浏览器播放:解决 H5 时代痛点
2020 年的痛点:浏览器只能看 HLS(延迟 3-5 秒)或 RTMP(需要 Flash)。2024+ 的方案:
- ZLMediaKit 内置 WebRTC——浏览器直接
<video>标签播放,延迟 <500ms - WVP 把 GB28181 PS 流推到 ZLMediaKit → 转 WebRTC——完整链路延迟 <1s
- WHEP / WHIP 协议——2024 年成为 WebRTC 与 GB28181 互通的事实标准
实际项目里:
| |
10.5 实战补充(2024-2026)
- K8s 部署:WVP + ZLMediaKit 全部跑在 K8s,VIP 改成 K8s Service(不再需要 Keepalived)
- 可观测性:WVP 接入 Prometheus + Grafana,SIP 注册成功率、在线设备数、流转发 QPS 全部可视化
- 安全加固:
- SIP 端口从 5060 改 5061(WSS 加密)
- Redis 加 TLS
- ZLMediaKit 的 HTTP API 加 JWT 鉴权
- 大规模部署:单 WVP 实例承载 5000+ 设备,集群方案需要 2024+ 的 WVP-PRO 商业版
10.6 个人总结:WVP 5 年的变化
2020 年做视频监控 = 信令网关 + 拉流分发
2024 年做视频监控 = 信令网关 + 流媒体 + AI 分析 + 浏览器低延迟
2026 年做视频监控 = 全套 + 多模态 AI + 边缘计算
WVP-GB28181-pro 这个项目 5 年来依然是国内 Java 视频监控的"事实标准”——只是从"信令网关"演变成了"AI 视频平台入口"。
