从零理解GB28181-1(协议说明)
从 0 理解 GB28181：2016 与 2022 协议、报文格式、交互流程与数据库设计
本文面向后端工程师、视频平台研发和物联网平台开发者，系统梳理：
- GB28181 的协议架构、版本演进（2016 / 2022）及核心差异
- SIP、SDP、MANSCDP/XML 在协议栈中的分工
- 注册、保活、目录查询、录像查询、实时点播、回放等核心流程的报文格式与交互时序
- 落地一个可用平台所需的最小数据模型设计
1. GB28181 到底是什么
GB28181 是国内视频监控联网领域的核心标准协议，其设计目标包括：
- 统一前端设备（IPC、NVR、平台网关）与上级平台间的互联互通
- 规范设备注册、保活、目录同步、设备控制、实时预览、录像回放、告警通知等能力
- 消除对厂商私有协议的依赖
如果把它拆开看，GB28181 并不是单一协议，而是几层协议的组合：
- SIP：信令控制层——注册、消息、订阅、邀请、会话结束
- SDP：媒体协商描述层——接收 IP、端口、SSRC、传输模式等参数
- RTP/PS：媒体传输层——实际承载音视频流
- MANSCDP/XML：业务数据载体层——目录、设备信息、录像、保活、告警等业务消息
各层职责可类比如下：
| 协议层 | 类比 | 实际职责 |
|---|---|---|
| SIP | “打电话” | 建立和管理信令通道 |
| SDP | “告诉对方去哪儿接、怎么传” | 协商媒体传输参数 |
| RTP/PS | “把音视频发过去” | 承载实际的音视频数据 |
| XML | “说业务语义” | 承载目录查询、录像查询、状态上报等业务命令 |
2. 2016 与 2022 的关系
2.1 版本关系
目前工程里最常见的两个版本是：
- GB/T 28181-2016
- GB/T 28181-2022
实践里可以把它们理解为：
2016：当前绝大多数平台和设备互联的主流基础版本2022：在 2016 基础上的增强版，保留原有主流程，在能力表达、安全性、扩展字段、兼容细节上做增强
2.2 工程视角怎么理解兼容
“兼容 2022”在工程实践中存在三个层次：
| 层次 | 能力 | 覆盖面 |
|---|---|---|
| L1 | 能和 2022 设备跑通 2016 基础流程 | 大多数系统 |
| L2 | 支持 2022 版本标识（如 X-GB-Ver: 3.0） |
少部分系统 |
| L3 | 完整覆盖扩展字段、能力模型和安全要求 | 完整平台 |
2.3 可以抓住的核心差异
从落地角度，不必一开始把 2022 当成完全不同的协议：
- 主干流程没变：还是 REGISTER、MESSAGE、SUBSCRIBE、NOTIFY、INVITE、BYE
- 媒体流程没变：还是 SIP 协商 + SDP 描述 + RTP 传流
- 扩展能力增强：2022 对部分字段、能力表达和互联约束更完整
- 安全要求更重要：2022 更强调安全传输、安全管理、可扩展能力表达
因此，一个平台如果想同时支持 2016 和 2022，最常见的做法不是”做两套系统”，而是：
- 保持统一主干流程
- 在报文字段、版本头、能力集、扩展 XML、传输安全上做分支兼容
3. GB28181 的整体数据流
先看整体架构，理解系统内各组件的数据流向。
flowchart LR
A[前端设备 / NVR / 网关] -->|REGISTER / MESSAGE / NOTIFY / INVITE| B[GB28181 平台]
B -->|401/200/响应消息| A
B -->|HTTP API| C[业务系统 / Web 管理端]
B -->|SDP 协商| A
A -->|RTP/PS 音视频流| D[流媒体服务器]
D -->|HTTP-FLV / RTSP / HLS / WebRTC 等| C
B -->|MySQL| E[(关系数据库)]
B -->|Redis| F[(缓存/会话/在线状态)]
这张图表达了 4 个事实：
- 设备和平台之间走的是 SIP + XML + SDP
- 设备和流媒体服务之间走的是 RTP 音视频
- 平台对外给业务系统暴露的是 HTTP API
- 平台内部必须保存设备、通道、会话、在线状态、录像查询上下文
3.1 核心概念定义
以下术语是后续所有章节的基础，先做统一定义。
目录（Catalog）
在 GB28181 中，目录 是设备资源树或监控资源清单。它向上级平台声明：
- 设备下挂载了多少监控点
- 各资源的类型、国标 ID、层级关系和父节点
类比文件系统：根节点为 NVR 或区域，子节点为摄像机通道，支持多层嵌套。目录的核心用途：
- 为业务系统提供”资源树”视图
- 作为点播和录像查询的目标源
- 帮助平台识别设备的可用通道集合
设备（Device）
设备 是协议的接入主体，包括 IPC、NVR、编码器、网关和下级平台。作为会发起 REGISTER、响应 MESSAGE 和 INVITE 的协议参与者，其数据模型需记录：
- 身份标识与归属平台
- 注册地址与传输方式
- 在线状态与注册/保活时间戳
通道（Channel）
通道 是业务层实际操作的媒体资源单元。一台 NVR 下挂 32 路摄像机，通常对应 32 个通道。业务系统的操作对象不是”设备”，而是具体通道：
| 操作 | 实际目标 |
|---|---|
| 播放 | 某个通道 |
| 录像查询 | 某个通道 |
| 云台控制 | 某个通道对应的摄像机 |
简言之：设备是协议接入主体，通道是业务访问对象。
平台（Platform）
平台 是 GB28181 联网中的服务端/上级系统，负责接收注册、发起目录/录像查询、控制点播回放、对外暴露业务接口。在级联场景中，一个平台可能同时对下游扮演上级角色，对更高一级平台扮演下级角色。
流会话（Stream Session）
流会话 是一次实时点播、录像回放或下载所对应的媒体上下文，包含：
| 字段 | 用途 |
|---|---|
| Call-ID | SIP 会话关联键 |
| SSRC | 媒体流逻辑编号 |
| IP / Port | 流接收地址 |
| DeviceID / ChannelID | 关联设备和通道 |
| inviteType | PLAY / PLAYBACK / DOWNLOAD |
| status | INIT → TRYING → OK → CLOSED |
没有流会话管理，平台无法追踪”这路流是谁发的、何时建立、何时超时、BYE 后该释放什么资源”。
SSRC
SSRC（Synchronization Source）是一条 RTP 流的逻辑编号。工程上常见的约定：以 0 开头表示实时点播，以 1 开头表示录像回放——这不是协议强制规定，但已被广泛采用。
录像条目（Record Item）
录像查询返回的是 录像条目列表（非视频文件本体）。每条记录包含通道 ID、起止时间、类型、文件路径或资源标识。业务系统拿到列表后，由用户选中条目再发起回放或下载。
4. 协议分层：每层到底干什么
4.1 SIP——信令骨架
GB28181 的信令层基于 SIP 协议，核心方法如下：
| 方法 | 职责 |
|---|---|
REGISTER |
注册、续订、注销 |
MESSAGE |
承载业务 XML（目录查询、设备信息、录像信息等） |
SUBSCRIBE |
订阅目录、位置、告警等事件 |
NOTIFY |
推送订阅结果（目录变更、报警事件、移动位置） |
INVITE |
建立媒体会话（点播、回放、下载） |
BYE |
终止媒体会话 |
4.2 SDP——媒体协商描述
INVITE 携带的 SDP 描述了完整的媒体接收参数：
- 接收 IP 和端口
- 传输方式（UDP / TCP）
- 会话 SSRC
- 会话类型（实时预览 vs 录像回放）
- 回放的起止时间戳
4.3 MANSCDP/XML——业务数据载体
GB28181 的业务语义通过 XML 正文承载（而非 SIP Header），包括目录查询、设备信息、录像查询、保活、媒体状态通知等。工程上真正的开发工作量往往集中在 XML DTO 定义、序列化/反序列化和业务状态机处理上。
5. SIP 报文基础格式
5.1 REGISTER 报文
设备首次注册时，先发送一个无认证的 REGISTER 请求：
1 | REGISTER sip:34020000002000000001@192.168.1.10:5060 SIP/2.0 |
平台开启密码认证时，返回 401 Unauthorized 携带 Digest 质询参数：
1 | SIP/2.0 401 Unauthorized |
设备收到 401 后，携带 Authorization 头重新发起 REGISTER：
1 | REGISTER sip:34020000002000000001@192.168.1.10:5060 SIP/2.0 |
平台校验成功后返回 200 OK。
5.2 REGISTER 核心字段说明
From/To- 标识设备身份
Call-ID- 同一事务或会话的关联键
CSeq- 同一方法的序列号，必须递增
Contact- 告诉平台设备后续可达地址
Expires- 注册有效期
0通常表示注销
Authorization- Digest 认证信息
6. MANSCDP/XML 报文格式
6.1 目录查询 Query
平台请求某设备返回通道目录，通常通过 MESSAGE 发送 XML：
1 |
|
字段说明：
CmdType- 命令类型，这里是
Catalog
- 命令类型，这里是
SN- 命令序列号，用来匹配请求与响应
DeviceID- 目标设备 ID
设备返回的响应通常是：
1 |
|
6.2 设备信息查询 Query
1 |
|
典型返回字段包括：
- 设备名称
- 厂商
- 型号
- 固件版本
- 通道数
6.3 录像查询 Query
1 |
|
字段说明：
StartTime/EndTime- 录像检索时间范围
Secrecy- 保密属性，通常默认
0
- 保密属性，通常默认
Type- 查询类型，常见
all
- 查询类型，常见
返回时一般会带录像条目列表，每个条目包含：
- 录像文件路径
- 开始时间
- 结束时间
- 类型
- 地址或设备标识
6.4 保活消息
在工程实践中，设备保活最常见的是通过 MESSAGE 携带 MANSCDP/XML 上报；如果某些事件是由订阅关系触发，则可能通过 NOTIFY 承载。
因此，更准确的说法是：保活 XML 是业务消息体，具体承载方法要看设备实现和场景约束，但主流设备通常使用 MESSAGE。
1 |
|
平台收到后通常会：
- 刷新设备在线时间
- 延长在线 TTL
- 更新最后一次心跳时间
6.5 媒体状态消息
媒体状态消息在很多实现中也是通过 MESSAGE 承载 XML 正文，表示某个媒体会话状态发生了变化；如果它来自订阅事件上下文，也可能以 NOTIFY 形式出现。下例重点展示其 XML 结构：
1 |
|
这类消息常用于表示媒体状态变化，例如开始推流、停止推流或某种播放状态事件。
7. INVITE 与 SDP：媒体会话的核心
GB28181 的工程难点不在 REGISTER，而在 INVITE + SDP + RTP 的完整链路打通。
7.1 实时点播 INVITE 流程
平台发起 INVITE 前，需先从流媒体服务器申请一个可接收 RTP 的地址，例如：
| 参数 | 示例值 | 说明 |
|---|---|---|
| 媒体服务器 IP | 10.10.10.200 |
设备推流目标地址 |
| 接收端口 | 30000 |
RTP 监听端口 |
| SSRC | 0200000001 |
唯一流标识 |
将上述参数写入 SDP 后随 INVITE 发送。
7.2 实时点播 SDP 示例
1 | v=0 |
字段解释：
s=Play- 表示这是实时点播
c=IN IP4 10.10.10.200- 设备把媒体流发到这个地址
m=video 30000 RTP/AVP 96 98 99- 视频、端口 30000、使用 RTP/AVP、支持多个 payload type
a=recvonly- 平台这边只接收媒体
a=rtpmap- 定义 payload type 和编码映射
y=0200000001- SSRC
7.3 TCP 主动 / 被动模式
如果不是 UDP，而是 TCP 模式，SDP 里常见：
1 | a=setup:passive |
或：
1 | a=setup:active |
含义是：
active- 表示本端主动发起 TCP 连接
passive- 表示本端被动等待连接
7.4 回放 SDP 示例
录像回放和实时点播的最大区别，是要带时间范围：
1 | v=0 |
关键差异：
s=Playback- 表示不是实时流，而是历史录像回放
t=开始时间 结束时间- 使用 Unix 时间戳描述回放区间
u=通道ID:0- 常用于标识回放资源
y=1xxxxxxxxx- 很多实现会约定回放 SSRC 以
1开头，实时点播以0开头，便于区分
- 很多实现会约定回放 SSRC 以
7.5 INVITE 关键头 Subject
很多平台还会在 INVITE 中带一个 Subject：
1 | Subject: 34020000001310000001:0200000001,34020000002000000001:0 |
可以理解为：
- 前半部分：发送者通道与流标识
- 后半部分：接收者平台与接收流标识
不同厂家在这里的细节可能略有差异，但这类字段在联调时非常常见。
8. 五个最关键的交互流程图
8.1 设备注册流程
sequenceDiagram
participant D as 前端设备
participant P as GB28181 平台
participant DB as 数据库
participant C as 缓存
D->>P: REGISTER(不带认证)
P-->>D: 401 Unauthorized + WWW-Authenticate
D->>P: REGISTER(带 Authorization)
P->>DB: 保存设备基础信息
P->>C: 标记在线状态、刷新 TTL
P-->>D: 200 OK
8.2 保活流程
sequenceDiagram
participant D as 前端设备
participant P as GB28181 平台
participant C as 缓存
participant DB as 数据库
D->>P: MESSAGE Keepalive
P->>C: 刷新在线 TTL
P->>DB: 更新 keepalive_time / last_seen_time
P-->>D: 200 OK
8.3 目录查询流程
sequenceDiagram
participant Biz as 业务系统
participant P as GB28181 平台
participant D as 前端设备
participant DB as 数据库
Biz->>P: 请求设备目录
P->>D: MESSAGE(Query Catalog)
D-->>P: MESSAGE/Response(Catalog)
P->>DB: 保存或更新设备通道
P-->>Biz: 返回目录树/通道列表
8.4 实时点播流程
sequenceDiagram
participant Biz as 业务系统
participant P as GB28181 平台
participant M as 流媒体服务器
participant D as 前端设备
participant C as 缓存
Biz->>P: 请求实时预览(deviceId, channelId)
P->>M: 申请 RTP 接收端口
M-->>P: 返回 mediaIp/mediaPort
P->>D: INVITE + SDP(Play)
D-->>P: 100 Trying / 200 OK
D->>M: RTP/PS 推流
P->>C: 保存 callId、ssrc、streamId、超时信息
P-->>Biz: 返回播放地址
8.5 录像查询与回放流程
sequenceDiagram
participant Biz as 业务系统
participant P as GB28181 平台
participant D as 前端设备
participant M as 流媒体服务器
Biz->>P: 查询录像(start, end)
P->>D: MESSAGE(Query RecordInfo)
D-->>P: MESSAGE(Response RecordInfo)
P-->>Biz: 返回录像列表
Biz->>P: 请求录像回放(recordItem)
P->>M: 申请 RTP 端口
M-->>P: 返回 mediaIp/mediaPort
P->>D: INVITE + SDP(Playback)
D-->>P: 200 OK
D->>M: RTP/PS 回放流
P-->>Biz: 返回回放播放地址
9. 最小可用数据模型
如果目标是构建一个”能跑通核心流程”（非完整运营系统）的 GB28181 平台，数据层至少需要解决四个问题：
| # | 问题 | 对应实体 |
|---|---|---|
| 1 | 设备是谁 | Device |
| 2 | 设备下有哪些通道 | Channel |
| 3 | 设备当前是否在线 | 在线状态 |
| 4 | 点播/回放会话的上下文是什么 | Stream Session |
以下给出 4 张最小核心表的字段设计。
9.1 平台配置表 gb_platform
此表服务于协议运行（非业务展示）：
| 字段 | 类型 | 必要性 | 说明 |
|---|---|---|---|
| id | bigint | 必须 | 主键 |
| platform_id | varchar | 必须 | 平台国标 ID |
| sip_domain | varchar | 必须 | SIP 域，例如 3402000000 |
| sip_ip | varchar | 必须 | 对外监听 IP |
| sip_port | int | 必须 | SIP 端口 |
| transport | varchar | 必须 | UDP/TCP |
| auth_password | varchar | 建议 | REGISTER 鉴权密码 |
| charset | varchar | 必须 | 常见为 GB2312 或 UTF-8 |
| version_profile | varchar | 必须 | 2016 / 2022 |
为什么必须有：
- 没有
platform_id和sip_domain就没法构造 SIP URI - 没有
sip_ip/sip_port就没法接收设备注册和发送 INVITE - 没有
version_profile就很难做 2016/2022 分支兼容
9.2 设备表 gb_device
核心实体表。
| 字段 | 类型 | 必要性 | 说明 |
|---|---|---|---|
| id | bigint | 必须 | 主键 |
| device_id | varchar | 必须 | 设备国标 ID，唯一 |
| parent_platform_id | varchar | 必须 | 属于哪个平台 |
| name | varchar | 建议 | 设备名称 |
| ip | varchar | 必须 | 设备注册后的源 IP |
| port | int | 必须 | 设备注册后的源端口 |
| host_address | varchar | 必须 | ip:port，便于快速定位 |
| transport | varchar | 必须 | UDP/TCP |
| charset | varchar | 必须 | 设备使用的字符集 |
| password | varchar | 建议 | 单设备认证密码 |
| expires | int | 必须 | 注册有效期 |
| register_time | datetime | 必须 | 最近注册时间 |
| keepalive_time | datetime | 必须 | 最近保活时间 |
| status | tinyint | 必须 | 在线/离线 |
| local_ip | varchar | 必须 | 平台与设备通信时使用的本地 IP |
| stream_mode | varchar | 必须 | UDP/TCP-ACTIVE/TCP-PASSIVE |
| geo_coord_sys | varchar | 建议 | 坐标系 |
为什么这些字段缺一不可：
device_id：协议世界中的唯一主键ip/port/transport：后续 MESSAGE、INVITE、BYE 都要靠它发送expires/register_time/keepalive_time/status：没有这些就无法维护设备生命周期local_ip：多网卡部署时尤其关键，否则回包和 INVITE 很容易发错出口stream_mode：决定播放时使用 UDP 还是 TCP
9.3 通道表 gb_device_channel
很多平台误以为”设备在线就够了”，但业务层实际操作的对象是 通道。
| 字段 | 类型 | 必要性 | 说明 |
|---|---|---|---|
| id | bigint | 必须 | 主键 |
| device_id | varchar | 必须 | 所属设备 ID |
| channel_id | varchar | 必须 | 通道国标 ID |
| name | varchar | 必须 | 通道名称 |
| parent_id | varchar | 建议 | 父节点 ID |
| address | varchar | 建议 | 安装地址 |
| parental | tinyint | 建议 | 是否目录节点 |
| manufacturer | varchar | 可选 | 厂商 |
| model | varchar | 可选 | 型号 |
| status | tinyint | 建议 | 通道在线状态 |
最小必要字段是：
device_idchannel_idname
原因很简单：
- 目录展示离不开
name - 点播与录像查询必须指定
channel_id - 归属关系必须能从
device_id找到设备
9.4 流会话表 gb_stream_session
缺少此表，实时点播和回放将难以追踪和管理。
| 字段 | 类型 | 必要性 | 说明 |
|---|---|---|---|
| id | bigint | 必须 | 主键 |
| stream_id | varchar | 必须 | 平台内部流 ID |
| device_id | varchar | 必须 | 设备 ID |
| channel_id | varchar | 必须 | 通道 ID |
| call_id | varchar | 必须 | SIP Call-ID |
| ssrc | varchar | 必须 | 会话 SSRC |
| media_ip | varchar | 必须 | 流媒体接收 IP |
| media_port | int | 必须 | 流媒体接收端口 |
| invite_type | varchar | 必须 | PLAY / PLAYBACK / DOWNLOAD |
| start_time | datetime | 可选 | 回放开始时间 |
| end_time | datetime | 可选 | 回放结束时间 |
| status | varchar | 必须 | INIT / TRYING / OK / CLOSED |
| created_at | datetime | 必须 | 创建时间 |
| expires_at | datetime | 必须 | 会话超时时间 |
为什么一定要有：
- 没有
call_id，就没法正确处理对应的 200/失败响应和 BYE - 没有
ssrc，就没法管理流资源回收 - 没有
media_ip/media_port，就没法定位当前流的接收位置 - 没有
invite_type，实时与回放无法区分
9.5 缓存层
虽然本节讨论的是数据库设计，但工程上必须强调缓存的作用：
- 在线状态适合放缓存并带 TTL
- 实时点播会话适合放缓存并设置超时
- SSRC 池适合放缓存集合
如果全部只靠数据库，平台在高并发或设备量大的情况下会明显变重。
10. 核心状态机
GB28181 不是简单的”请求-响应”模型。一个可用平台至少需要维护 4 套状态机：
- 注册状态机
- 未注册 -> 挑战认证 -> 已注册 -> 续订 -> 注销
- 在线状态机
- 在线 -> 心跳刷新 -> 超时离线
- 目录状态机
- 发起查询 -> 等待响应 -> 分页/分批接收 -> 更新通道数据
- 媒体会话状态机
- INIT -> INVITE 已发送 -> TRYING -> OK -> 媒体中 -> BYE -> CLOSED
状态机设计不清晰时，典型故障包括：在线设备无法点播、流断开后会话未释放、录像查询结果与请求丢失关联、BYE 后资源泄漏。
11. 2016 与 2022 落地时最该注意什么
11.1 对 2016，先把主干流程做扎实
首次落地建议优先覆盖 2016 核心能力：
- REGISTER + Digest 认证
- Keepalive
- Catalog
- DeviceInfo
- RecordInfo
- Invite Play
- Invite Playback
- BYE
覆盖以上能力后，平台即具备基本可用性。
11.2 对 2022，不要只改版本号
很多人以为支持 2022 就是把版本号从 2.0 改成 3.0，这远远不够。
真正的 2022 适配，至少要考虑：
- 是否有版本配置开关
- XML 结构是否支持新增或扩展字段
- 流类型、码流标识、能力表达是否兼容
- 安全传输和认证策略是否满足更高要求
- 与 2016 对端通信时是否可以平滑降级
也就是说，2022 是一组”兼容增强”，不是一个字符串替换。
11.3 最稳妥的工程策略
建议采用”统一主流程 + 版本差异适配层”的方式：
- 主流程仍然是 REGISTER / MESSAGE / INVITE / BYE
- 版本差异收敛在：
- Header 版本标识
- XML DTO 字段
- SDP 扩展属性
- 安全与传输层配置
这样不会把系统拆成两套，维护成本最低。
12. 要点回顾
GB28181 = 用 SIP 管控制、用 XML 传业务、用 SDP 约定流、用 RTP 发音视频。
2016 vs 2022 的本质关系：
2016 是主干，2022 是增强；兼容 2022 不能只改版本头，还需补齐字段扩展、流程差异和安全能力。
13. 落地路线
从零构建 GB28181 平台，推荐按以下顺序推进：
- 先打通 SIP 基础收发
- 实现 REGISTER + 401/200 Digest 认证
- 实现 Keepalive 在线状态维护
- 实现 Catalog / DeviceInfo / RecordInfo 的 XML 收发
- 接入流媒体服务器，打通 INVITE + SDP + RTP
- 做流会话表和缓存超时清理
- 最后再做 2022 的版本扩展与安全增强
这是最稳的路线，也是工程上最务实的落地路径。
如果你准备继续往下做，下一步最值得深入的方向：
| 方向 | 核心挑战 |
|---|---|
| GB28181 注册中心 | 高并发注册、Digest 认证状态机、级联支持 |
| 流媒体接入层 | RTP 端口管理、PS 解复用、多协议输出 |
| 双版本兼容层 | 2016/2022 字段差异收敛、平滑降级 |
| 厂商兼容性处理 | 不同设备对标准实现的偏差与 workaround |
这四个方向，才是工程真正有深度的部分。
14. 常见术语速查
| 术语 | 全称 / 含义 |
|---|---|
| SIP | Session Initiation Protocol，会话发起协议，用于控制信令 |
| SDP | Session Description Protocol，会话描述协议，用于描述媒体参数 |
| RTP | Real-time Transport Protocol，实时传输协议，用于承载音视频数据 |
| PS | Program Stream（节目流），GB28181 中最常见的视频封装格式 |
| SSRC | Synchronization Source Identifier，同步源标识，用于标识一路流 |
| MANSCDP | GB28181 中定义的 XML 业务消息体系名称 |
| REGISTER | 注册 / 续订 / 注销（SIP 方法） |
| MESSAGE | 发送业务请求或响应（SIP 方法） |
| INVITE | 建立媒体会话（SIP 方法，用于点播、回放、下载） |
| BYE | 结束媒体会话（SIP 方法） |
| Catalog | 目录查询，获取设备的通道资源树 |
| RecordInfo | 录像查询，获取某通道的录像条目列表 |
| Keepalive | 保活通知，设备定期上报存活状态 |
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 优秀的螺丝工！
相关推荐
2026-04-05
从零理解GB28181-2(2022扩展点)
GB28181-2022 有哪些扩展点：从 2016 到 2022 的能力增强、云台控制与业务流程详解 本文聚焦 GB/T 28181-2022 的专题分析。上一篇解决”GB28181 是什么、怎么跑起来”，本文聚焦： 2022 相比 2016 到底多了什么——哪些是扩展点、哪些仅是约束细化 云台控制为何在 2022 语境下值得独立讨论 平台同时兼容 2016 与 2022 的协议分层架构设计 1. 结论先行：2022 是增强，不是重写从工程实现角度，GB/T 28181-2022 并非对 2016 的全面重写，而是在稳定主干上的增强： 协议层 2022 状态 SIP 信令 不变 SDP 媒体协商 不变 RTP 媒体传输 不变 MANSCDP/XML 数据格式 不变 2016 与 2022 的定位差异： 版本 定位 核心特征 2016 主干骨架 能互通、能点播、能回放 2022 行业级增强 控制更细、状态更全、能力表达更完整、安全要求更高 因此落地策略是：以 2016 主流程为基础，在字段、控制命令、能力集、媒体能...
2026-04-14
从零理解GB28181-3(流媒体接入)
如何设计 GB28181 的流媒体接入层：SRS6 与 ZLMediaKit 的接入流程、配置案例与交互说明 流媒体接入层是 GB28181 项目中最容易被低估、却实际最关键的模块。很多工程团队将精力集中在 SIP 注册、目录查询、录像查询上，却忽略了真正把流接进来、转出去、提供播放能力的——正是流媒体接入层。 本文聚焦四个核心问题： 为什么 GB28181 平台必须设计专门的流媒体接入层 SRS6 与 ZLMediaKit 在 GB28181 架构中的定位差异 平台、设备、流媒体服务器之间的交互流程 可落地的配置案例与平台设计要点 1. 为什么需要流媒体接入层GB28181 不是”只做信令”的协议。仅完成 SIP 部分，平台能覆盖的能力有限： SIP 能力覆盖 用户实际需求 设备注册、保活 实时看视频 目录查询、录像查询 回放录像 设备控制 Web / APP / 播放器同时分发 — HTTP-FLV / RTSP / HLS / WebRTC 输出 两者之间存在一个关键缺口：SIP 只管”让...
评论