黑河市all1. 视频接入的痛点：当每个品牌都自带一座孤岛
我最早接触这类项目，是在一个园区安防改造的单子里。园区里前前后后装了三批摄像头，既有海康的，也有大华的，还有一批杂牌IPC，各自带着自己的NVR和管理平台。甲方的要求很简单：希望在一个界面上看完所有画面，还要能把这些视频流喂给AI算法做人形检测和区域入侵报警。结果一调研发现，每套系统都有自己的账号体系、私有SDK、专属流地址格式，连录像回放都没法统一。
这就是典型的品牌孤岛问题。设备厂商卖硬件的同时，一定会配套自己的平台软件，而这些平台在设计上就天然倾向于封闭。你买了海康的摄像头，他希望你用海康的NVR和iVMS；你买了大华的设备，他又希望你用大华的PSS。表面上说是"开放SDK"，但实际上每个SDK的接口风格、流媒体协议、事件回调机制都不一样，想让它们互相配合，代价极高。更麻烦的是，厂商对SDK的维护周期普遍比较短，设备固件一升级，SDK的兼容性就会出问题。
当项目规模小，比如就十几个摄像头，这个问题还不明显，最多是多开几个客户端窗口而已。可一旦规模上到几百路，甚至跨园区、跨区域，每次都逐个品牌对接SDK，终端侧要适配的抓流协议就五花八门，平台侧也没有统一的数据模型，算法接入方更是一头雾水。AI公司想做的只是"拿到干净的视频流，跑模型，输出结果"，而不是去理解每个品牌的私有协议。这个时候，基于GB28181和RTSP的统一接入架构就成了唯一务实的选择。
1.1 一个统一的接入层，能解决什么
先说结论：统一接入层的核心价值，不是把协议"翻译"过来，而是把设备——尤其是不同品牌的设备——抽象成一套标准模型。模型之上，信令、媒体、事件、AI推理全部走标准接口，业务层不需要关心对面是什么牌子、什么型号、走什么私有协议。
比如GB28181设备国标编号有固定结构，前8位是中心编码，中间是类型和行业编码，后面是序号。不管你是海康还是大华，只要能注册上来，平台维护的就是这串编号，而不是IP、端口、用户名、密码这些运维层面的信息。这样一来，设备云台控制、录像检索、语音对讲、报警上报所有这些能力，都能通过国标信令统一触发，业务层只依赖国标协议。
1.2 项目里的真实痛点：接入和算法是两层问题
还有一个很容易被忽略的点：视频接入和AI能力是两层问题。很多项目经理把这两件事混在一起谈，结果就是"接摄像头"和"跑算法"被放到一个合同里，没有清晰的分层。等到实施的时候，AI厂商说视频流格式不对，设备厂商说算法平台兼容不了自己的码流，互相扯皮，项目就卡住了。
我后来在架构设计里，刻意把接入层和AI分析层解耦。接入层只负责拿到原始视频流，统一转成标准格式，AI层通过标准接口（比如RTSP拉流或WebRTC订阅）去消费这些流。至于设备端是GB28181还是RTSP，那是接入层的事。这样做的好处是，算法升级、替换、增加一个新的检测项，都不需要重新连一遍摄像头。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 协议选型逻辑：为什么是GB28181与RTSP双栈，而不是SDK
很多人在设计视频平台时会纠结：到底用GB28181还是RTSP？以我的经验，这不是一个二选一的问题，而是一个"主备"和"场景"的问题。
GB28181是国标，它的全称叫《安全防范视频监控联网系统信息传输、交换、控制技术要求》，从根上就是为"跨品牌、跨平台的视频监控联网"设计的。它基于SIP信令，媒体层面使用RTP/RTCP，天然支持设备注册、实时音视频点播、历史录像检索与回放、云台控制、语音对讲、报警事件上报等一系列能力。如果你要对接的是大量新增设备，或者项目本身有安防合规要求，GB28181是绕不开的。
RTSP则更适合存量设备和局域网场景。很多老项目里已经布了一大批摄像头，它们可能没有国标能力，或者国标接入不稳定，但RTSP取流是一定支持的。而且RTSP实现简单、直观，调试起来非常方便，一个VLC播放器加上一个取流地址，就能验证链路通不通。所以在设备数量不大、网络环境受控的局域网场景，RTSP反而是最优解。
2.1 GB28181和RTSP在信令与媒体上的本质区别
GB28181信令用的是SIP（Session Initiation Protocol），本质上就是那套VoIP领域用了很多年的会话控制协议。设备上线后向SIP服务器发起REGISTER注册，之后平台要预览，就发INVITE请求，协商出RTP传输通道，设备开始推流。平台要录像回放，就发对应的SIP消息去拉历史流。GB28181还规定了设备目录的查询机制，平台可以定期向设备上报目录结构，这样即使设备端增删了通道，平台也能及时发现。
RTSP则是L5的应用层协议，由客户端发起DESCRIBE、SETUP、PLAY等命令，服务端（摄像头或NVR）响应，媒体同样走RTP。它的设计更接近"播放器"模型，侧重点播而非联网管理。所以RTSP通常只能做取流，做不了复杂的设备管理、报警联动、语音广播这些能力。
用一个不严谨但好懂的类比：GB28181更像一个电话交换机系统，SIP负责"拨号、挂断、转接"这些会话动作，RTP是电话里的语音内容；RTSP则像你去VCD店租一张光盘，你告诉店员要哪张（PLAY），店员放给你看，但不能让你控制整个店的库存。
2.2 双栈设计不是叠加，而是分层兜底
在实际架构里，我倾向于把GB28181作为主力接入协议，RTSP作为兜底和扩展。比如新部署的摄像头，优先注册到GB28181网关；老型号或者第三方特殊设备，如果国标注册不上，就退回到RTSP方式接入。
这里有个细节：RTSP并不是"不标准"，它本身就是标准协议。只是它在设备发现、目录管理、事件上报这些能力上不如GB28181完整。比如你想统一管理一百个摄像头，用RTSP你得手动维护一个IP和账号密码清单，新增一台设备都要改配置；用GB28181，设备上线后自动注册，平台通过目录查询拿到通道信息，基本不需要人工干预。
所以，双栈架构中，两条路径最终汇入同一个流媒体网关。网关拿到的是rtsp流或者国标推上来的RTP流，统一转封装成平台内部的标准流格式，后续是转WebRTC给浏览器用、还是转HLS给移动端用、还是直接喂给AI算法，都是流媒体网关的事，和接入侧协议无关。
2.3 为什么SDK接入不是首选
很多厂商的SDK文档厚厚一摞，功能看起来也全，但SDK自带很多"暗坑"：动态库依赖冲突、回调函数不回调、网络断开重连机制不透明、调试过程基本靠厂商技术支持远程操作。而且SDK和特定硬件版本绑定很紧，固件升一次级，SDK接口可能就变了。
在平台型项目里，SDK接入做得越多，系统越脆弱。每一个品牌都要单独维护一套SDK封装模块，单独处理异常、升级、兼容性，后期维护成本几乎是线性增长的。而GB28181和RTSP是协议级对接，平台侧只需要维护协议栈，不依赖任何一家厂商的私有库。设备没了可以换品牌，协议栈不用改。
3. 统一接入平台架构：从摄像机到AI输出的全链路设计
架构设计上，我把整个平台从物理设备到最终应用分了四层：接入层、媒体层、智能层、业务层。每一层的职责单一，层与层之间通过标准接口交互，这样无论前端设备怎么杂、后端业务怎么变，中间层都能稳得住。
3.1 四层架构：接入层、媒体层、智能层、业务层
接入层是距离设备最近的一层，主要做协议适配。它在GB28181侧就是一个SIP服务器（通常也叫SIP网关），负责接收设备注册、维护在线状态、处理目录查询、发起实时点播和录像回放；在RTSP侧则是一组拉流代理，周期性和摄像头保持心跳，按需拉RTSP流。
媒体层是所有视频流的"总枢纽"。核心组件是一个流媒体网关，比如ZLMediaKit，它接收接入层汇聚过来的流，做转封装、多协议输出。这里也是做录像、转发、截图、推流给AI的中枢。媒体层设计的关键是"一入多出"：一路原始流进来，可以同时输出RTSP、RTMP、HLS、HTTP-FLV、WebRTC等多种格式，供不同的下游消费。下游不用关心上游是谁。
智能层跑的是AI推理服务，从媒体层订阅视频流，执行目标检测、人脸抓拍、车牌识别、烟火检测等算法任务，把结构化结果（比如目标框、置信度、事件类型、发生时间）输出给业务层。智能层和业务层的交互通过消息队列（比如RabbitMQ或Kafka）解耦，算法产生的事件异步写入消息队列，业务层消费后触发告警、联动、存储。
业务层就是最终用户看到的东西：Web管理界面、客户端、APP。负责展示视频墙、事件列表、设备树、录像检索，也负责用户权限管理、操作日志等。
3.2 核心模块拆解：SIP网关、流媒体网关、设备目录、AI算子
平台落地时，有几个模块必须单独拎出来讲。
SIP网关：这是GB28181接入的门面。它并不是一台独立服务器，而是一个服务进程，监听SIP的UDP/TCP端口（默认5060）。设备配置好国标编号和SIP服务器地址后，上线就发REGISTER。SIP网关要负责响应注册请求、维护注册状态、处理业务信令。典型实现是WVP-PRO里的SIP模块，或者直接基于eXosip、Doubango这类SIP库自己封装。网关的稳定性直接决定系统能不能"看到"设备。
流媒体网关：我选型时首选ZLMediaKit，它的核心优势在于协议转换能力极强，能从GB28181的RTP推流中解析出原始流，同时支持通过RTSP拉流。它内部维护一个流表，每个流都有唯一的流ID，下游通过流ID拉流，这比直接依赖设备地址靠谱得多。ZLMediaKit还内置了FFmpeg，用来做音频转码、视频GOP缓存、HLS切片。
设备目录服务：这层向上提供设备树，向下屏蔽协议差异。无论设备是GB28181注册上来的，还是RTSP手动添加的，在目录服务里都统一映射成"区域→分组→通道"三级结构。海康的设备有"行政区划→组织→设备→通道"，大华的体系也类似，统一映射时需要保留国家标准的中心编码和通道编码，不能只图省事用自增ID。
AI算子容器：智能层采用的是"算子容器"模式，每个算法模型打包成一个独立的容器或进程，通过标准输入输出和媒体网关交互。比如一个人形检测算子，它订阅某些通道的视频流，按预设帧率抽帧分析，把结果上报到算法消息队列。算子的增加、停用、升级都不影响其他模块。
3.3 视频流处理链路：从推流到AI推理，中间经历了什么
一路视频流从设备到最终被AI消费，具体的链路是这样的：
摄像头启动后，通过GB28181注册到SIP网关。当业务层请求预览某通道时，SIP网关向设备发送INVITE，设备进入推流状态，通过RTP将PS流（Program Stream，节目流）推送到流媒体网关。PS流是国标里规定的封装格式，里面可以包含视频、音频、甚至私有数据。流媒体网关收到PS流后，需要做解复用和转封装，把PS流里的H.264/H.265视频帧、G.711音频帧提取出来，再封装成标准FLV或MP4，存储在内部流表里。
如果设备走RTSP接入，链路更简单：流媒体网关直接像普通播放器一样向摄像头发RTSP请求，摄像头吐出RTP包，网关接收后同样做解封装、转封装，进入流表。
AI推理服务的流程是：从流媒体网关拉取一路或某几路视频流，先做解码，然后按设定的抽帧间隔（比如每2秒一帧）取帧，送入模型推理。推理完成后，把结果写入消息队列。业务层的告警服务订阅这个队列，一旦发现置信度超阈值的目标，就生成一条带截图和短视频的事件记录。
这里有个取舍值得说：AI分析时到底该不该让流媒体网关负责转码？我的建议是尽量别做二次编码。AI推理只需要解出原始YUV或RGB帧，不需要重新编码。如果AI服务直接拉RTSP流自己解码，就能绕开转码带来的性能损耗和画质损失。只有当你要把某个检测结果保存成证据视频，或者做低码率的远程回传时，才在流媒体网关侧转码。
3.4 国标编码与通道映射：数字编号里藏着整个组织架构
GB28181的一大特点是，设备编码不仅仅是一个标识，它本身就携带了行政区域、设备类型、安装场所、设备序号等信息。
一个典型的20位国标设备编码长这样：前8位是中心编码，对应区划，比如34020000代表某个地市；第9、10位是行业编码，111表示社会公共安全；第11、12位是类型编码，131表示IP摄像机，132表示NVR之类；第13位是具体安装场所，第14到20位才是设备序号。通道编码则是在设备编码基础上扩展，第11、12位换成132/134等标识通道类型，第13到20位也变化，规则很多，但殊途同归。
平台在实现设备目录时，最好直接采用国标编码作为内部主键。这样和公安平台、上级平台级联时，能直接对上号，不需要额外做映射。我见过一些项目，内部用自增ID，结果级联时发现国标编码对不上，还要写一堆转换逻辑，这种返工极其痛苦。
4. 开源方案选型：WVP-PRO、ZLMediaKit、Mediatrix等组件的取舍
说到落地实现，就绕不开开源生态。这一节讲几个我反复对比、实测过的组件，以及它们在统一接入架构中所处的位置。
4.1 WVP-PRO：国标信令与设备管理的一站式选择
WVP-PRO是目前国内社区使用最广泛的GB28181视频平台开源项目之一。它默认内置了整套GB28181 SIP信令服务，支持设备注册、目录查询、实时预览、录像回放、云台控制、语音对讲。它还把设备管理、用户权限、Docker化部署都做了，基本上拿来就能跑。
我个人比较认可WVP-PRO的一点是，它的SIP模块对国标协议的兼容性做了很多打磨，尤其是对海康、大华这类主流设备的信令行为做了适配。比如很多摄像头的SIP注册周期是3600秒，但有些设备固件版本有Bug，注册过期后没有重新注册，WVP-PRO能通过定时检查在线状态主动发消息来兜底。
它还与ZLMediaKit深度集成，通过配置把流媒体网关的地址、端口、流ID规则都串好。业务层拿到的播放地址是统一生成的，不需要关心设备是从哪路注册上来的。
4.2 ZLMediaKit：媒体层的中枢
ZLMediaKit是一个C++开发的高性能流媒体服务器，支持RTSP、RTMP、HTTP-FLV、HLS、WebRTC、SRT等协议。它既是服务器，又能作为客户端去拉流，这正好满足视频接入架构里"一入多出"的需求。
ZLMediaKit在GB28181场景里扮演的角色是RTP接收端。国标设备推流时，ZLMediaKit监听RTP端口，解析PS流，把H.264/H.265视频和音频解出来，注册成内部流。下游想预览，走的还是ZLMediaKit的接口。由于它原生支持WebRTC输出，解决了浏览器播放低延迟视频的难题——用户不用装插件，也不用装ActiveX控件，直接打开网页就能看。
这里要提醒一句：ZLMediaKit的功能很强大，但配置项也不少。比如enable_audio、add_mute_audio、gop_cache这些参数，默认值虽然能跑，但在实际项目中几乎都要根据场景调整。比如开启GOP缓存后，新客户端连上来能秒开，但代价是延迟会略微增加；如果你对延迟极度敏感，可以做更精细的配置。
4.3 选型对比：为什么不用Monibuca、Mediatrix、FFmpeg硬拉流
在选型过程中，我也对比过Monibuca（Go语言流媒体服务器）、Mediatrix（原名MediaMTX，轻量RTSP转WebRTC/RTSP代理）、以及直接用FFmpeg命令去拉流的方案。
Monibuca的设计理念和ZLMediaKit类似，也支持多协议，生态不错，但在GB28181 RTP收流这块，ZLMediaKit的成熟度更高，社区里的国标案例也更多。Mediatrix这个名字在热搜里高频出现，它确实很轻量，尤其适合"把单路RTSP转成WebRTC给浏览器播放"这种简单需求，但它没有一个完整的管理平台配套，做几百路设备接入时，设备列表、信令交互、录像回放这些能力都要自己重新造轮子。直接FFmpeg拉流更是只适合临时调试，一个进程管一路视频，视频一断流进程就挂，完全没有守护机制。
所以我的结论是：平台级项目选WVP-PRO + ZLMediaKit组合，轻量级边缘盒子或者单设备调试，才考虑Mediatrix。选型不是看单个组件多强，而是看你需要它承担什么职责。
4.4 自定义开发时的协议栈与媒体层接口设计
如果你不想用WVP-PRO这种完整平台，想自己开发一套，那需要关注的协议栈包括：SIP协议栈（比如eXosip、PJSIP、Doubango）、RTP/RTCP处理、PS流解析、H.264/H.265的RTP打包与解包。媒体层接口则要定义清楚几个核心动作：接入流（AddStream）、移除流（RemoveStream）、拉流鉴权（CheckStreamAuth）、录像查询与回放（QueryRecord / PlayRecord）。
接口设计有个容易被忽视的原则：接口要尽量"粗"，避免让业务层操心媒体细节。比如业务层调用"Play(channelId)"，平台返回一个统一的播放地址（WebRTC或HTTP-FLV），这就够了。不要暴露底层是RTSP还是RTP，这会让上层应用和底层协议耦合在一起。
5. 私有化部署与日常运维：从0到1的落地清单
项目标题里写了"私有化部署"，这一节专门讲这件事。私有化部署不意味着随便在一台服务器上装个Docker就完事，它牵涉到硬件选型、网络规划、安全策略、日常监控，每一步都得想清楚。
5.1 服务器选型：并发路数决定配置基线
先估算并发路数。这里有两个口径：接入路数和同时预览/分析路数。接入路数可以很大，比如一个园区接了500路摄像头，但真正同时打开视频预览的可能只有几十路，AI分析可能只有几十路。所以服务器配置先按"同时预览 + 同时分析"来估。
简单公式：每路1080P H.264的码流约4Mbps，如果同时看50路，峰值带宽就是200Mbps，光交换机端口就得是千兆起步，核心交换机甚至要考虑万兆。CPU方面，ZLMediaKit主要是网络IO和拷贝操作，对CPU消耗相对可控，但AI推理就完全是另一回事了——YOLO类模型跑在CPU上，1080P单路推理大概需要3到6个核，跑十路就很吃力了。所以AI推理强烈建议用GPU或NPU，比如NVIDIA的T4、A10，或者国产的昇腾310、瑞芯微RK3588这类边缘算力。
实际的部署拓扑，通常是这样的：一台SIP+流媒体+业务服务混合服务器，一台或多台AI推理服务器。混合服务器建议至少8核16G内存，系统盘SSD 200G以上，如果要做录像存储，数据盘按"码率 × 存储时长"来算。比如50路4Mbps存储30天，是50×4Mbps÷8×3600×24×30=约64.8TB，这个量级不是单盘能扛的，得考虑NVR或分布式存储。
5.2 Docker Compose编排：一套能跑通全栈的配置思路
WVP-PRO和ZLMediaKit都有官方Docker镜像，编排起来比较简单。完整一套包括四类容器：数据库（MySQL）、缓存（Redis）、媒体网关（ZLMediaKit）、业务平台（WVP）。我习惯用docker-compose把这些串起来。
编排时最需要注意的是端口映射。GB28181的SIP服务通常监听UDP/TCP 5060，流媒体网关要暴露多个端口：RTSP 554、RTMP 1935、HTTP-FLV/WebRTC的端口（ZLMediaKit默认HTTP 80、RTSP 554、RTMP 1935、RTP代理端口10000左右）。如果你在公网部署，还要考虑SIP和RTP端口是否需要额外映射到NAT上。
WVP-PRO配置时需要指定ZLMediaKit的API地址和流媒体端口。它内部的application.yml里有一堆和媒体网关相关的配置项，包括media.rtp-ip、media.rtp-port-range、media.stream-ip、sip.ip、sip.port等。常见坑是多个网卡时，sip.ip配置成了内网IP，导致公网设备注册不上，或者stream-ip配置错误导致播放地址回环。
5.3 网络规划与安全策略：哪些端口不该暴露
私有化部署一般在内网跑，但如果是跨地域联网，就需要公网或专网通道。这时候安全策略要提前定好，不要图省事把所有端口都映射到公网。
建议的端口策略：
- SIP服务端口：仅向可信任的设备和上级平台开放，如果非必须，不要暴露到公网。
- 流媒体服务端口：对外只暴露给业务反向代理，比如Nginx上代理HTTP-FLV/WebRTC端口，对外只留443，内部端口不直接暴露。
- 数据库、Redis、API管理端口：只允许内网访问。
- 设备流：如果摄像头在内网，通过GB28181注册时，视频流也走内网，不经过公网。
另外一个容易被忽视的坑是防火墙的UDP策略。GB28181的SIP信令和媒体RTP都可能走UDP，很多企业的防火墙默认放行TCP但丢UDP包，导致设备注册时SIP信令通了（TCP方式），但预览时RTP拉流却一直黑屏。排这类问题，要看防火墙有没有配UDP的端口和会话超时规则。
5.4 日常监控：除了看进程还得看流量
运维监控这块，常规的CPU、内存、磁盘监控肯定要有，但视频平台还有几个特色指标：设备在线率、注册成功率、推流成功率、拉流失败率、录像存储余量。
设备在线率很好理解，一个GB28181平台几百路设备，总有几台因为网络抖动、断电掉线。平台要有定时巡检机制，跑一个定时任务去查SIP注册状态，不在线的设备标记出来，生成告警。日志上，SIP信令的OSD（日志级别）可以调到DEBUG排查问题，但生产环境建议调成INFO，防止日志量太大把磁盘打满。ZLMediaKit它的ffmpeg日志和相关流媒体日志也要定期清理。
6. 我踩过的坑：协议协商、延迟、浏览器播放与语音对讲
最后写几个实际项目里最常遇到的坑，这些坑在官方文档里往往写得不够详细，但凡是做过视频接入的人，基本都碰过其中一两个。
6.1 GB28181注册403：最常见的"伪故障"
海康摄像头接入GB28181平台时，注册返回403，是最常见的问题之一。403在SIP里表示"禁止"，但具体原因往往不是服务器拒绝，而是设备配置和服务器之间没对齐。常见的几个原因：
- SIP服务器ID和设备配置的SIP服务器编号不一致。设备里会填一个"SIP服务器编号"，很多项目默认填成平台的国标编码34020000002000000001，但平台实际监听时的SIP域可能不是这个，注册校验一比对，直接403。
- 密码或者认证方式不匹配。国标支持Digest摘要认证，设备端填的密码和平台存的密码不一致，也会403。
- 设备侧配置了错误的传输协议。有的摄像头默认SIP用UDP，但平台只开了TCP，或者反过来，注册包能到但回应一直不对。
排查这类问题的思路是打开SIP端口的抓包，看REGISTER请求的报文内容，重点看Authorization字段里的username和response，对照平台日志就能看出来是ID不匹配还是密码错误。不要一看到403就重启服务，先看协议报文。
6.2 RTSP取流地址格式：每个品牌都有自己的"暗号"
RTSP取流地址看起来很标准，但真实格式五花八门。海康常见的是rtsp://user:pass@ip:554/Streaming/Channels/101，主码流和子码流分别用101、102表示；大华常见的是rtsp://user:pass@ip:554/cam/realmonitor?channel=1&subtype=0；有些杂牌摄像头用的是Open Network Video Interface Forum风格的rtsp://ip:554/media/video1。这些格式不同，但底层都是RTSP标准，区别只在URL路径的语义。
所以做RTSP接入时，不要把取流地址写死在逻辑里。平台要允许运维人员在添加设备时自定义URL模板或直接粘贴完整地址，用一种"标准格式 + 自定义覆盖"的模式。我见过有的团队写死海康的格式，然后拿它去拉大华的流，自然是拉不出来的。
6.3 浏览器播放RTSP的误区：转封装不是转码
"浏览器能直接播放RTSP吗"这个问题，是热搜里出现频率极高的。答案是：不能，但可以"变通"。RTSP的底层是TCP/UDP上的RTP流，浏览器里的WebRTC和HTML5 video都不原生支持RTSP。通行的做法是让流媒体网关把RTSP流转成WebRTC或HTTP-FLV，再推给浏览器。
这里必须说清：转封装和转码是两回事。ZLMediaKit把RTSP流转成WebRTC，通常做的是转封装和payload打包，不涉及重新编码，所以CPU开销小、延迟低（可以做到几百毫秒）。而HLS方案要切片，延迟会到几秒甚至十几秒。如果业务要求低延迟（比如实时对讲、远程操纵），选WebRTC；如果能接受一定延迟（比如轮巡大屏），HLS也没问题。
实测下来，用ZLMediaKit输出WebRTC，配合WPF的播放页面，在局域网内首帧秒开、延迟约300到500毫秒，效果相当不错。但要注意WebRTC的UDP传输在某些网络环境下会被限制，需要提前测一下网络策略。
6.4 语音对讲没有声音：音频编码与双向流的坑
GB28181支持语音对讲，但很多项目在第一次调语音时都会发现：平台能听到设备端的声音，但设备听不到平台的声音，或者反过来，全是杂音、没有声音。这里的问题几乎都出在音频编码协商上。
国标对讲里，设备端通常支持PCMA/PCMU（G.711A/G.711U）编码，但有些设备只支持AAC或者只支持特定的采样率。平台向设备发送INVITE时要带上音频媒体描述，如果编码不匹配，设备就拒绝或者直接静音。另外，语音对讲是双向的，不只是平台播放设备侧的音频，还要把平台的音频流通过RTP发给设备。很多平台的实现里，只管接收设备的音频，没实现发送音频的通道，结果对讲功能就变成了"单向监听"。
踩过坑之后，我的建议是：先在设备端把语音编码强制设置为G.711A，并且把双向流都抓包确认RTP是双向的。如果设备指向的是NVR而不是IPC，还要确认NVR的语音对讲通道是否指向哪个物理枪机，不同NVR的通道配置差别很大。
6.5 AI推理对视频流的影响：别让算法把平台拖垮
最后聊一个非协议层但很容易被忽略的坑：AI推理服务拉流会显著增加流媒体网关的压力。
假设平台有100路视频要跑算法，每路视频都以原始码流4Mbps拉出来，流媒体网关就要同时向算法服务输出100路4Mbps的流，这100路的网络开销会占掉大量带宽。更聪明的方式是让算法服务通过GB28181平台内部接口直接拉取内部流表，或者用ZLMediaKit支持的"按需拉流"模式：算法要分析某一路时，平台才去设备侧拉流，分析完就自动停止，避免常开占用带宽和资源。
我实测过的项目里，跑30路人形检测，算法服务直接从原始流抽帧分析，CPU和GPU占比都还不错，但如果采用"每路实时转码再喂给算法"的方式，CPU直接飙到95%以上。所以AI推理链路一定要设计成"原始流解码抽帧"，而不是"转码后喂帧"。这个思路，我每次评审新项目时都要重新强调一遍。
总结一下我的体会：视频接入架构没有银弹，GB28181和RTSP各有自己的适用边界，私有化部署的核心是让平台逻辑和设备型号解耦。只要接入层、媒体层、AI层分开设计，所有品牌设备都能在同一个体系下工作。这比我最初做那个园区项目时一个个适配厂商SDK要稳妥得多。