0. 先说结论
高速上的摄像头不是一批装的，所以"把所有流拉过来"这件事，比听起来难得多。
如果只能记住一句话：先做汇聚层，再上 AI 检测。顺序反了，算法吃的就是脏数据。
下面按这条顺序拆：现实约束 → 两条路径怎么选 → 汇聚层怎么分层 → 落地时最容易出问题的地方。
1. 高速场景和园区监控，根本不是一回事
很多人拿园区监控的经验直接套高速，第一步就踩坑。差别在这几处：
| 维度 | 园区/楼宇 | 高速公路 |
|---|---|---|
| 建设方式 | 一次性建设 | 分期分批，跨度常达十年以上 |
| 品牌型号 | 1~2 个厂家 | 4~8 个厂家很常见 |
| 网络 | 局域网，条件好 | 跨通信站/收费站，多网域，NAT 普遍 |
| 点位分布 | 集中 | 线性分布，几十公里起步 |
| 带宽 | 富余 | 逐级收敛，上行带宽紧张 |
| 在线率要求 | 一般 | 高，且要求可举证 |
结论：高速场景的第一约束不是"能不能识别"，而是"能不能拿到稳定、完整、时间准确的流"。这也是为什么接入层必须单独设计。
2. 两条主流路径：级联 vs 直取
| 维度 | GB/T 28181 级联 | RTSP / 私有 SDK 直取 |
|---|---|---|
| 适用 | 多品牌混装、需要向上级平台级联 | 单网络域、型号统一、新建路段 |
| 优势 | 国标通用，目录/信令/回放口径统一 | 链路短，延迟低，实现简单 |
| 代价 | 信令与目录逻辑复杂，联调工作量大 | 厂商差异大，型号一多就炸 |
| 典型场景 | 存量路段利旧改造 | 新建路段、前端直采 |
| 跨网能力 | 强（有标准级联模型） | 弱（依赖网络可达） |
一句话选型建议：存量混装路段优先走 28181；单一网络域内的新建段可以 RTSP 直取。多数实际项目是两者并存。
3. 汇聚层建议这样分层
┌──────────────┐
│ 应用层 │ 调阅 / 拼接 / AI 事件检测 / 告警
├──────────────┤
│ 汇聚层 │ 统一目录、统一转码、统一时钟、统一鉴权
├──────────────┤
│ 接入层 │ 28181 / RTSP / 私有 SDK 协议适配
└──────────────┘
↓
前端摄像头（多品牌、多年代、多网域）关键设计点：
- 接入层只做协议适配，不做业务。它的唯一职责是把不管什么来源的流，变成统一的内部格式。
- 汇聚层必须统一三件事：点位命名与桩号映射、时间戳来源、流转封装格式。这三样不统一，后面做 AI 检测和事后取证会一路踩坑。
- 接入层与检测层解耦。GPU 资源扩缩、算法版本升级，都不应该动接入层。
4. GB/T 28181 落地时，必须提前对齐的参数
注意：以下不是"照抄配置"，而是联调前必须逐项确认并且双方签字对齐的清单。绝大多数接入失败，都是这里某一项没对齐。
【网络与信令】
□ 传输协议：UDP 还是 TCP（跨 NAT、丢包严重时必须改 TCP）
□ SIP 服务器 IP / 端口 / 信令端口与媒体端口是否放行
□ SIP 域、SIP 服务器 ID、设备 ID 编码是否符合 20 位编码规则
□ 是否有多级级联：上下级平台的域、ID、级联层级
【注册与心跳】
□ 注册鉴权方式（含算法）与密码
□ 注册有效期与重注册策略
□ 心跳周期与超时判定
【目录】
□ 目录订阅方式、订阅周期、是否支持增量
□ 目录里的点位编码与物理桩号是否一一对应
□ 点位的在线/离线状态如何判定
【媒体流】
□ 主码流/子码流选择与码率上限
□ 封装格式（PS over RTP / 裸流）
□ 是否支持 TCP 被动/主动模式切换
【时间】
□ 前端设备是否接入 NTP
□ 平台侧校时策略最后那一组时间，是最容易被忽略又最致命的。设备时钟不同步，复盘时录像是错位的，取证直接用不了。
5. RTSP 直取的几个常见坑
如果走直取，这几处值得提前预判：
- 鉴权方式不统一：各家对 Digest / Basic 的实现细节有差异，有些还有私有鉴权，写死了就换不了设备。
- 传输协议选择：UDP 起不来就换 TCP（RTSP interleaved），不要死磕。跨网场景下 TCP 几乎是必选项。
- 子码流才是检测用流：检测任务不要拉主码流，带宽和算力都扛不住。通常是主码流录像取证、子码流 AI 检测。
- 断流重连：TCP 连接假死很难发现，必须做应用层心跳 + 自动重连，否则"在线"是假的。
6. 排查清单（这节可以直接存下来当手册）
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 注册不上 | SIP 服务器地址/端口、域编码位数、鉴权算法不一致 | 抓包看 SIP 4xx 响应码，逐项比对第 4 节清单 |
| 注册成功但没目录 | 未发目录订阅 / 订阅后设备未响应 | 检查订阅周期与设备侧是否开启目录推送 |
| 有目录点播无流 | SDP 协商失败 / 媒体端口不通 / 码流类型不匹配 | 抓包看 Invite 与 200OK，确认媒体端口可达 |
| 有流但花屏/卡顿 | UDP 丢包、码率超过链路承载、缓存不足 | 改 TCP 传输；降子码流码率；查链路丢包率 |
| 时间戳不对/回放错位 | 前端未校时 | 全网点位接入同一 NTP 源，禁止人工改设备时间 |
| 偶发断流不自愈 | 连接假死、无重连机制 | 加应用层心跳与指数退避重连 |
7. 最后：顺序不能反
这两年接触的项目里，效果差的几乎都是同一个原因------前端还没汇聚干净，就急着上算法。
接入层解决"拿得到、看得全、时间准"，汇聚层解决"统一口径"，然后才轮到事件检测解决"找得快"。三步的顺序反了，后面每一步都在给前一步还债。
关于算力估算口径和多厂家格式对比，我整理了一份《高速视频监控·AI事件检测选型清单》，包括接入方式对比表、GPU 资源估算口径、延迟指标怎么定三个部分。需要的评论或私信【云监方案】，我发你。