苏黎世贝勒爷1. GB28181与RTSP双轨割裂：融合网关要解决的真实痛点
做安防流媒体接入这些年，我最大的感受就是“碎”。一个稍微正式点的项目，摄像机品牌能有七八种，平台协议更是五花八门：上级监管平台要求GB28181国标接入，园区本地平台习惯走RTSP直接拉流，有些老设备只支持ONVIF或者厂商私有SDK。GB28181与RTSP作为国内视频接入最主流的两套协议，一个偏“信令严谨”，一个偏“简单直接”，长期各管一摊，导致视频接入层的代码被协议绑死，改一个厂家就要动一遍主流程。这篇文章，我想围绕基于GB28181与RTSP的企业级视频融合网关项目，把架构设计、源码实现、联调排错和性能调优完整梳理一遍，给正在做视频接入平台、运维平台、AI分析中台的研发同学一个可以直接落地的参考。
1.1 两种协议各管一摊：为什么视频接入总是被“协议绑架”
先聊GB28181。它的全称是“公共安全视频监控联网系统信息传输、交换、控制技术要求”，本质上是一套基于SIP的信令体系，加上RTP承载的媒体通道。设备通过SIP REGISTER注册到平台，平台通过MESSAGE查询目录，通过INVITE邀请设备推流，还支持云台控制、报警上报、语音对讲、录像检索和级联。媒体面上，设备推上来的码流通常是PS封装的RTP包，里面裹着H.264/H.265视频或G.711音频。这套协议的价值在于“设备管理”能力很强，适合大规模组网，一个平台可以挂几千路设备，且所有信令都有标准格式，理论上不同厂家的设备都能互通。
RTSP就完全是另一套思路。它本是流媒体播放的控制协议，OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN五连招，拿到SDP后，客户端就知道媒体格式和端口，然后RTP/RTCP开始传输裸流。IPC的RTSP接口通常不带复杂的设备管理能力，只有“取流”这一个动作，但好处是灵巧，URL一给就能播，VLC、ffmpeg、ExoPlayer都能直接打开。海康的取流地址长这样：rtsp://admin:password@192.168.1.13:554/Streaming/Channels/101，大华则是rtsp://admin:password@192.168.1.14:554/cam/realmonitor?channel=1&subtype=0。
问题就出在这里。当你的系统需要同时服务“上级国标平台”和“本地播放器”时，就会陷入两套协议来回切换的泥潭。业务层想要的是deviceId + channelId → 一路可播放视频流，但底层却一会儿是SIP消息、一会儿是RTSP URL，一会儿又要处理PS封装，代码里到处是if (protocol == "GB28181")这样的分支。我见过一个项目，接入层堆了四套网关注册逻辑，每加一个厂家就要新增一个适配器，最后所有人的精力都被耗在“跟协议吵架”上，真正的业务功能反而没时间做。
1.2 典型业务场景中的融合诉求
往细了说，融合网关要解决的不是某一个场景，而是下面这几类高频场景一起出现：
场景一：多品牌设备统一接入上级平台。 一个企业园区里可能有海康、大华、宇视、华为智选这些设备，它们的私有SDK千差万别，但都支持GB28181或RTSP。统一的融合网关先把这些设备纳管起来，再以一台“虚拟国标设备”的身份向上级平台注册，上级平台只要对接一个网关就行，不用面对几十个厂家。
场景二：本地平台与播放端需要快速取流。 大屏解码器、Web管理端、移动App想要播放视频时，走RTSP是最省事的。但摄像头分散在不同的IP段，有的在NAT后面，直接给播放端RTSP地址根本不现实。网关把取流逻辑收口以后，播放端只跟网关要流，网关负责去设备侧拉流，再统一转发出来。
场景三：AI分析服务要拿裸流。 现在很多AI中台不愿意对接千奇百怪的厂商协议，它们只认RTSP或GB28181标准流。网关注册完一路通道后，可以直接给AI服务器输出一路干净的RTSP流，省去AI侧适配DevSDK的成本。
场景四：移动端和浏览器播放。 安卓原生不支持直接播放RTSP，浏览器更是碰都不能碰，必须把RTSP转成HLS、HTTP-FLV或WebRTC。网关在做协议转换的同时，顺带做输出端的封装转换，这样前端团队不用关心原始设备是什么协议，只管跟网关要流。
1.3 “视频融合网关”到底是什么，不是什么
很多人把“视频融合网关”跟“视频转码服务器”“NVR”“AI盒子”搞混，动手之前必须先把边界划清楚。
融合网关的核心工作是信令适配和媒体转发。它把GB28181设备和RTSP设备统一抽象成“设备 + 通道”模型，对外提供一致的信令和媒体输出。它不做转码，至少第一版绝不做。视频从设备侧进来是什么编码，转发出去就是什么编码，只在中间做PS解封装和RTP重打包。做转码意味着CPU/GPU开销成倍上涨，而大部分场景根本不需要，H.264/H.265直接透传已经能满足核心需求。
它也不是NVR，不做录像存储和回放调度，虽然国标本身有录像检索接口，但那是锦上添花的功能，不应该主导架构设计。它更不是AI分析服务器，别指望在网关里跑算法，网关的职责是让视频“通”，不是让视频“懂”。
理清这个边界之后，你再看整个技术选型，会发现事情简单很多：核心是会话管理能力，而不是媒体处理能力。这也是我后面设计架构时始终坚持的原则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 融合网关架构设计：接入层、会话层与转发层的职责划分
我第一版网关把所有功能堆在一个服务里，当时还觉得“短小精悍”，结果一接上下级级联就崩了。后来重新设计，把系统分成了四层：接入层、会话管理层、媒体转发层、能力输出层。每层只干一件事，彼此通过接口通信，这样不论接入GB28181、RTSP，还是以后接ONVIF、私有SDK，主流程都不需要大改。
2.1 整体分层设计与数据流转路径
整个网关的数据流是这样的：
设备侧 → 接入层（GB28181应答SIP信令接收RTP，RTSP客户端主动拉流） → 会话管理层（维护设备表、通道表、实时会话表） → 媒体转发层（收到RTP包，解析PS封装，重新打包成标准RTP/裸流） → 能力输出层（以RTSP Server、HTTP-FLV、HLS、WebRTC等方式发给播放端）。
信令流和数据流是分离的。信令流走的是短连接/会话内消息，数据流走的是常驻的RTP通道。设计API的时候，我要求每一层都不允许直接操作其他层的内部状态，只能通过定义好的接口调用，否则代码很快会被散落的全局变量拖垮。