概念介绍
大约 8 分钟vmsvmsgb28181
国标监控概述
国标监控(VMS)把符合 GB/T 28181-2016 的视频设备接入到 BladeX 多租户体系,与 IoT 设备 / 告警 / 工作流 / 规则引擎共用同一套基础设施。
核心价值:
- 国标合规:严格按 GB/T 28181-2016 实现 SIP 信令、SDP 协商、MANSCDP+xml 报文,覆盖强制与推荐消息类型
- 多租户原生:平台级 SIP 配置 + 设备级租户绑定,跨租户全链路隔离
- 协议解耦:协议层不感知业务表,业务层不感知 SIP 细节,通过 SPI 单向依赖
- 资源安全:SSRC 黑名单防串台、CLOSE_PENDING 状态机防 ZLM 端口泄漏、订阅自动续约防中断
- 观测完整:Prometheus 指标 + 结构化日志 + 进程内 Spring 事件三位一体
- 存储抽象:抓图/录像走 OSS,支持 MinIO / 阿里云 / 腾讯云 / 华为云 / 七牛云
一、先认识几个基础概念
一句话定位
国标监控本质就两件事:① 让各家摄像头用统一"语言"接入平台(国标 SIP);② 把摄像头的视频转成浏览器能播的格式(ZLM)。 看懂下面几个词,后面所有内容都能顺下来。
用大白话理解每个词
| 词 | 大白话 | 生活类比 | 技术一句话 |
|---|---|---|---|
| 国标 / GB28181 | 国家定的"监控设备怎么和平台对话"的标准 | 让海康/大华/宇视的摄像头都说"普通话",平台才能统一接入 | GB/T 28181-2016,一套基于 SIP 的信令规范 |
| SIP | 国标信令底层借用的"打电话"协议 | 摄像头给平台"打电话":注册上线、被叫开播、挂断 | RFC 3261;REGISTER / INVITE / BYE 等 |
| ZLMediaKit(ZLM) | 专门搬运视频的"流媒体中转站" | 视频的"中转仓库 + 格式转换插座" | 开源流媒体服务器,收 RTP 流、转 FLV/HLS |
| 推流(push) | 把视频主动发出去 | 摄像头往中转站"寄包裹" | 设备把 RTP/PS 流推给 ZLM |
| 拉流(pull) | 观看端主动来取视频 | 你从中转站"取包裹" | 浏览器从 ZLM 拉 WS-FLV/HLS 播放 |
| RTP / PS | 设备推流用的"打包格式"(裸流) | 没拆封的快递,拿到也直接看不了 | 浏览器播不了,必须由 ZLM 转封装 |
| 通道(Channel) | 设备里的"一路画面" | 一台 NVR 接 16 路摄像头 = 1 个设备、16 个通道 | 点视频永远用 channelId,详见 核心概念 |
信令 vs 媒体——最关键的一组区分
国标监控的数据分两条互不混用的路:
- 信令(控制指令) 走 SIP:谁上线了、开始播这一路、云台往右转、有告警了…… 走的是"命令",数据量极小。
- 媒体(画面本身) 走 ZLM:真正的视频流。设备推流进来、浏览器拉流出去。
记住这句:SIP 负责"指挥",ZLM 负责"搬运视频"。 平台是中间的总调度。
它们怎么串起来——一张图看懂
完整串一遍(一次直播发生了什么)
你在浏览器点开一路摄像头(通道)→ 平台用国标 SIP 给这台摄像头"打电话"(INVITE),让它把画面推流(RTP/PS)到 ZLM → ZLM 把浏览器播不了的裸流转成 WS-FLV → 平台把这个拉流地址给浏览器 → 浏览器去 ZLM 拉流播放。
整个过程里:摄像头只管推、浏览器只管拉、ZLM 管中转转码、平台用 SIP 和 REST 两头指挥。 后面的协议、配置、操作,都是把这条主线讲细。
二、技术选型
| 维度 | 选型 |
|---|---|
| SIP 信令栈 | jain-sip(RFC 3261 完整实现,UDP + TCP 双栈 5060) |
| 流媒体服务 | ZLMediaKit(收 RTP/PS 流 + 转 WS-FLV / HLS / RTMP 分发);支持租户级多节点、按并发自动负载 |
三、整体架构
国标监控模块在 BladeX-Links 平台中以「协议层 / 业务层 / 前端层」三层架构组织,通过 SPI 单向依赖隔离协议细节与业务编排。
| 角色 | 职责 |
|---|---|
| 前端 | 通道树导航 + 直播/回放播放器 + PTZ 控件 + 抓图/录像/告警面板 |
| 平台业务层 | 接入编排 + 多租户隔离 + 异步任务调度 + OSS 上传 + 监控指标采集 |
| 国标设备 | 主动 REGISTER + Keepalive 心跳 + 响应 INVITE/Catalog/PTZ + 主动上报告警/GPS/目录变更 |
| 流媒体服务 | 接收设备 RTP 流 + Hook 通知平台 + 转 WS-FLV/HLS/RTMP 分发 |
| 上级平台 | (可选)接收本平台作为下级注册 + Keepalive + Catalog 查询 |
四、核心能力
| 类别 | 能力描述 |
|---|---|
| 设备接入 | 自动接入(AUTO)/ 手动注册(MANUAL 白名单,未登记设备 403)双模式 + 设备独立密码覆盖平台默认 + REGISTER + Digest 鉴权(RFC 2069 与 qop=auth 自动适配)+ Keepalive 心跳超时下线 + 设备信息/状态/参数三件套异步查询 |
| 媒体节点 | 租户级 ZLM 节点增删改 + 按并发最低全自动选节点(配几个即几元集群)+ on_server_keepalive 心跳在线状态 + 默认节点启动植入零回归 |
| 目录同步 | Catalog 主动查询分批 SN 聚合 + Catalog Subscribe 订阅式增量推送 + 行政区划自动建分组树 |
| PTZ 控制 | 8 方向 + 缩放 + 预置位 set/call/remove + 远程预置位列表同步 |
| 告警上行 | Alarm Notify 解析(报警方式 + 类型 + 子事件三段成对传递) + 异步桥接告警引擎 + Alarm Subscribe 订阅(支持优先级/类型/时段过滤) + 60s 去重 |
| 实时点播 | INVITE/ACK/BYE in-dialog + Subject 头按国标 §9.6.1 构造 + 主/子码流切换(SDP 多厂商兼容字段) + WS-FLV/HLS/RTMP 拉流 URL |
| 历史回放 | INVITE Playback + INFO MANSRTSP 控制(播放/暂停/倍速/拖动) |
| 设备控制 | 远程重启 + 本地录像启停 + 校时(强制 UTC+8 北京时间) |
| 抓图 | 有流直抓 / 无流自动开流 + 等流就绪二次校验 + OSS 存储 |
| 录像下载 | INVITE Download(s=Download + downloadspeed 加速取流)+ 流媒体录制 → OSS 异步搬运,轮询流下线判完成 + 状态机驱动 |
| 录像计划 | Cron 调度 + 两阶段异步执行(同步启动 + 定时回调收尾) + OSS 归档 + 自动过期清理 |
| 设备分组 | 行政区划自动建树 + 业务分组多对多 |
| GPS 上报 | MobilePosition 订阅 + Notify 解析 + WGS84 合理性校验 |
| 国标级联 | 作为下级:主动注册 + 401 二次鉴权(双 Digest 模式自动切换,Call-ID 按 RFC 3261 §22.4 复用)+ Keepalive + 响应上级 Catalog 查询 / SUBSCRIBE / INVITE 被点播 / Control 转发 / BYE,三路收敛(上级 BYE / 下级断流 / ACK 超时 + GC 兜底)保证级联 session 生命周期闭环 |
| 多租户隔离 | 全链路 tenant_id + 协议入站反查 + 跨租户结果缓存校验 |
| 可观测 | 6 个 vms_* Prometheus 指标 + 进程内 Spring 事件(VmsAlarmPersistedEvent / DeviceOnline·OfflineEvent) |
| 资源管理 | SSRC 黑名单防串台 + 流会话状态机自愈 + 订阅自动续约 + 设备重连恢复 |
五、多租户隔离原理
平台与设备之间有三条独立入站路径,每条都必须在进入业务逻辑前完成租户上下文注入。
| 入站路径 | 租户来源 | 防越权措施 |
|---|---|---|
| 前端 REST | JWT 解析 | BladeX 框架租户拦截器自动注入 SQL 条件 |
| 设备 SIP | deviceId → platform → tenantId 反查(Caffeine 缓存) | 反查失败的设备整条报文丢弃 |
| 流媒体 Hook | SSRC → 会话.tenantId 直接读 | 会话不存在时 hook 直接忽略 |
异步查询响应(设备查询/抓图/录像下载等)的中间结果都绑定写入时的租户 ID, 读取时校验当前请求租户一致才返回,跨租户读取一律返回 null。