WVP-GB28181平台与SIP协议详解

在视频监控领域，GB28181国标协议已成为实现设备互联互通的核心标准。本文将从WVP-GB28181平台的技术架构与功能特性，以及SIP协议在GB28181中的具体应用两个维度，系统梳理这一技术体系。

一、WVP-GB28181平台

1.1 什么是WVP-GB28181

WVP-GB28181（WEB VIDEO PLATFORM）是一个基于GB28181-2016标准实现的开箱即用的网络视频平台，负责实现核心信令与设备管理后台部分。它支持NAT穿透，兼容海康、大华、宇视等主流品牌的IPC、NVR接入，并支持国标级联。

该项目采用MIT许可协议，完全开源，已被广泛应用于智慧园区、安防监控、物联网等项目中。

1.2 核心架构：信令与媒体分离

WVP平台最核心的设计理念是**“信令与媒体分离”** 。整个系统由两个核心组件构成：

WVP-GB28181-pro（信令控制层） ：基于Java SpringBoot开发，不处理任何视频数据，只负责“发号施令”——处理SIP信令（设备注册、保活、云台控制、目录查询），并管理ZLMediaKit集群。

ZLMediaKit（流媒体引擎层） ：基于C++高性能网络框架开发，负责视频流的接收（RTP）、转协议（RTSP/RTMP/HTTP-FLV/WebRTC/HLS）和分发。

平台整体架构如下：

┌─────────────────────────────────────────────────────────┐
│                   客户端浏览器                            │
│              http://ip:18080 (Web UI)                    │
└──────────────────────┬──────────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────────┐
│                   WVP-PRO 应用                            │
│         GB28181 信令服务 (SIP 端口:5060)                  │
│         设备管理、用户认证、录像计划                        │
└──────────┬──────────────────────────────┬───────────────┘
           │                              │
┌──────────▼──────────┐    ┌─────────────▼────────────────┐
│  ZLMediaKit 流媒体   │    │      MySQL + Redis            │
│  • RTSP 554         │    │  • 设备信息存储                │
│  • RTMP 1935        │    │  • 用户数据管理                │
│  • HTTP 8081        │    │  • 会话缓存                   │
│  • WebRTC 10000     │    │  • 配置存储                   │
└─────────────────────┘    └───────────────────────────────┘

一次完整的视频播放流程如下：

1. 用户在浏览器点击“播放”，向WVP发起请求；
2. WVP向ZLMediaKit申请一个接收端口（SSRC）；
3. WVP通过SIP协议向摄像头发送INVITE指令，SDP中包含ZLMediaKit的IP和端口；
4. 摄像头根据指令，将视频流（PS封装的RTP包）推送到ZLMediaKit；
5. ZLMediaKit将流转码/封装后，返回播放地址给客户端。

1.3 主要功能特性

WVP平台覆盖了视频监控平台的核心业务需求：

• 设备接入：支持国标设备（IPC、NVR、平台）接入，同时支持RTSP、RTMP推流设备和非国标设备的拉流代理接入
• 视频预览：支持主码流/子码流切换，无限制接入路数（取决于服务器性能）
• 云台控制：控制设备转向、拉近拉远、预置位查询与设置
• 录像回放：查询NVR/IPC上的录像，支持指定时间播放与下载
• 国标级联：支持向上级平台注册级联，多平台级联，跨网视频预览
• 多协议输出：直接输出RTSP、RTMP、HTTP-FLV、WebSocket-FLV、HLS、WebRTC多种协议流地址
• 语音对讲：支持设备端语音对讲功能
• 报警处理：支持报警事件订阅与通知
• 网络校时：支持国标网络校时

1.4 部署与配置

WVP支持Docker一键部署，典型命令如下：

docker run --env WVP_IP="你的IP" -it \
  -p 18080:18080 \
  -p 30000-30500:30000-30500/udp \
  -p 30000-30500:30000-30500/tcp \
  -p 80:80 -p 5060:5060 -p 5060:5060/udp \
  648540858/wvp_pro

WVP的核心SIP配置集中在application-base.yml的sip:配置段中：

sip:
  ip: 127.0.0.1          # WVP监听网卡IP
  port: 8116             # SIP服务监听端口
  domain: 3402000000     # SIP域，宜采用国标ID前10位
  id: 34020000002000000001  # WVP的20位国标编码
  password:              # 设备注册时校验的密码

设备侧需要填写与WVP侧一致的SIP信息才能成功注册，包括上级平台SIP端口、SIP域、SIP ID和密码。

在性能优化方面，生产环境推荐使用TCP被动模式传输视频流，以解决UDP丢包导致的花屏问题；JVM参数建议大型部署使用-Xms8g -Xmx16g -XX:+UseG1GC。

二、SIP协议详解

2.1 SIP协议概述

SIP（Session Initiation Protocol，会话初始协议）是一个应用层的点对点控制（信令）协议，用于创建、修改和终止一个或多个参与者之间的会话。这些会话包括Internet电话呼叫、多媒体分发等。SIP由RFC 3261定义，是GB28181协议的核心信令基础。

SIP借鉴了HTTP的设计思路，是一种基于文本的协议，报文结构与HTTP类似，包括起始行、头域字段和消息体。

2.2 SIP消息结构

每一条SIP消息由三部分组成：起始行（Start Line）、头域（Header Fields）和消息体（Body）。

请求消息的起始行为请求行，格式为：

Request-Line = Method SP Request-URI SP SIP-Version CRLF

例如：INVITE sip:34020000001320000001@3402000000 SIP/2.0。

响应消息的起始行为状态行，格式为：

Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

例如：SIP/2.0 200 OK。

头域包含多个字段，常见的有：

头域	作用
Via	记录请求经过的路径，用于响应回传
From	请求发起方标识
To	请求接收方标识
Call-ID	全局唯一标识一次会话
CSeq	命令序号，用于匹配请求与响应
Contact	直接通信的地址
Content-Type	消息体的类型（如application/sdp）
Content-Length	消息体长度

头域以一个空行（CRLF）结束，其后是可选的消息体。在GB28181中，SDP（Session Description Protocol）作为消息体用于描述媒体会话参数，XML作为消息体用于控制指令。

2.3 SIP方法

SIP定义了多种请求方法，每种方法表示不同的操作意图：

方法	作用	GB28181中的应用
REGISTER	向服务器注册位置信息	设备向平台注册、平台向级联上级注册
INVITE	邀请用户或服务参与会话	请求设备推送视频流
ACK	确认已收到INVITE的最终响应	确认200 OK响应
BYE	终止已建立的会话	停止视频流推送
CANCEL	取消正在进行的请求	取消尚未完成的请求
OPTIONS	查询服务器能力	设备能力查询
MESSAGE	传递即时消息	发送XML控制指令、心跳保活
INFO	传递会话中的控制信息	录像回放控制、语音对讲

其中，INVITE方法的成功响应会在消息体中指明被叫方希望接收的媒体类型，SIP代理、重定向服务器和用户代理服务器都必须支持INVITE方法。

2.4 SIP响应码

SIP响应码按首位数字分为六类：

响应码类别	含义	典型示例
1xx	临时响应（Informational）	100 Trying、180 Ringing
2xx	成功响应（Success）	200 OK
3xx	重定向（Redirection）	301 Moved Permanently、302 Moved Temporarily
4xx	客户端错误（Client Error）	401 Unauthorized、404 Not Found
5xx	服务器错误（Server Error）	501 Not Implemented
6xx	全局错误（Global Failure）	603 Decline

在GB28181的注册流程中，401 Unauthorized和200 OK是最关键的两个响应码。

2.5 SIP在GB28181中的具体应用

注册与认证流程

GB28181设备注册采用SIP REGISTER方法，并配合摘要认证机制，流程如下：

1. 设备（SIP代理）向SIP服务器发送REGISTER请求；
2. SIP服务器返回401 Unauthorized响应，在WWW-Authenticate头域中给出认证体制和参数（包含随机数nonce）；
3. 设备根据收到的认证参数，重新发送REGISTER请求，在Authorization头域中携带包含认证信息的信任书；
4. SIP服务器验证通过后返回200 OK，注册成功。

实时视频点播流程

实时视频点播是GB28181中最核心的业务场景，采用INVITE方法实现，涉及三方呼叫控制：

1. 媒体流接收者向SIP服务器发送INVITE消息，SDP中s字段为“Play”表示实时点播；
2. SIP服务器向媒体服务器发送INVITE消息（不携带SDP）；
3. 媒体服务器回复200 OK，携带SDP，描述接收媒体流的IP、端口、媒体格式；
4. SIP服务器向媒体流发送者（设备）发送INVITE请求，携带媒体服务器回复的SDP，并增加y字段描述SSRC值；
5. 设备回复200 OK，携带SDP，描述发送媒体流的IP、端口、媒体格式和SSRC字段。

在WVP平台中，SIPCommander负责生成面向设备的出站请求，SIPCommanderForPlatform负责生成面向上级平台的出站请求，SIPProcessorObserver负责将接收到的SIP请求路由到对应的处理器。

心跳保活

GB28181设备注册成功后，会定时发送保活消息。保活消息采用MESSAGE方法携带设备状态信息，SIP服务器收到后返回200 OK。如果服务器超时收不到保活消息，则判断设备离线。

三、总结

WVP-GB28181平台通过 “信令与媒体分离” 的架构设计，将SIP信令控制交给Java后端（WVP），将流媒体处理交给C++流媒体引擎（ZLMediaKit），实现了高解耦、高扩展的系统结构。其优势在于：只要设备支持GB28181标准，无需适配厂商私有协议即可直接接入；ZLM原生支持WebRTC，浏览器无需插件即可低延迟播放。

而SIP协议作为GB28181的信令基础，以其基于文本的简洁设计、灵活的方法扩展机制和完善的认证体系，承载了设备注册、会话控制、指令下发等核心功能。理解SIP协议的消息结构、方法语义和响应码机制，是掌握GB28181平台开发和运维的关键基础。