Workerman 不适合独立实现 GB28181 完整接入，因其缺乏 SIP 协议栈、RTP/PS 媒体处理、NAT 穿透等能力；仅宜承担设备状态同步、心跳代理、目录聚合、告警透传等非媒体层业务逻辑。
Workerman 本身不是为 GB28181 这类强状态、多协议耦合的视频信令场景设计的，直接用它“从零手写”完整 GB28181 接入，会踩大量坑，不推荐。
它适合做轻量级信令中转、心跳代理或设备状态桥接，但无法替代专业媒体服务层。真要跑通 GB28181，得明确分清楚：哪些交给 Workerman，哪些必须交给 ZLMediaKit / EasyGBS / YiheCode Server 等专用流媒体服务。
为什么不能只靠 Workerman 实现 GB28181 完整接入
GB28181 不是 HTTP API，它是一套组合协议栈：
- 信令层依赖 SIP（含 REGISTER/INVITE/BYE/NOTIFY），需处理对话（Dialog）、事务（Transaction）、重传、ACK 匹配、CSeq 递增、Via/Branch 校验
- 媒体层依赖 RTP over UDP/TCP + PS 封装 + 时间戳同步 + SDP 协商（如
a=rtpmap:96 PS/90000） - 还要支持心跳保活、目录订阅、移动位置上报、历史录像检索等扩展 XML 交互
Workerman 的 TCP/UDP Worker 可以收发原始 SIP 包或 RTP 包，但它：
- 没有内置 SIP 解析器，
sip_parse_message()得自己写，且要覆盖 RFC3261 所有边界 case - 不管理 Dialog 生命周期，INVITE 后的 ACK、200 OK 重传、CANCEL 处理极易出错
- 无法处理 PS 流的 PTS/DTS 同步、RTP 序列号/时间戳跳变、丢包补偿（尤其在 4G/弱网下）
- 不提供 H.264/H.265 编码、PS 打包、音视频复用等媒体能力
简单说：Workerman 是“快递员”，而 GB28181 要求你同时是“海关+调度中心+物流分拣站+包装车间”。
哪些 GB28181 子功能可以用 Workerman 安全承接
适合交由 Workerman 承担的，是与业务逻辑强相关、与媒体流解耦、无实时性硬要求的部分：
- 设备注册状态同步：监听 ZLMediaKit 的 HTTP 回调（如
/index/api/getDeviceInfo），用Workerman把在线状态推送到内部 OA 或工单系统 - 心跳代理：让设备注册到
Workerman的 SIP Server（需集成sip.js或node-sip类库），再由它转发 REGISTER 到真实 GB28181 平台，用于灰度切流或协议审计 - 目录聚合：用
Workerman定时调用多个 GB28181 平台的/api/v1/devices接口，合并返回统一设备列表给前端 - 告警透传：接收平台通过 NOTIFY 上报的告警 XML，解析后转成 MQTT 消息发往 IoT 平台，或存入 Redis 队列供下游消费
关键点：所有这些都不碰 RTP 流、不参与 SDP 协商、不封装 PS、不处理音视频帧——只做“协议翻译”和“消息路由”。
Workerman + ZLMediaKit 的典型协作架构
真实项目里更可行的路径是分层协作：
- 设备端 →
ZLMediaKit（监听udp://0.0.0.0:5060，处理 SIP 注册、INVITE、RTP 接收、PS 封装、WebRTC/FLV 转发） -
ZLMediaKit通过 HTTP 回调（如on_flow_report、on_server_started）通知Workerman服务 -
Workerman启动一个HttpServer，暴露/v1/gb28181/status给运维查设备数，或/v1/gb28181/control接收云台指令并转成 SIP INFO 发给 ZLMediaKit - 历史录像检索这类耗时操作，
Workerman收到请求后，异步调用 ZLMediaKit 的/index/api/getRecordList，加缓存、限流、熔断
这种结构下，Workerman 的角色是“胶水层”，ZLMediaKit 才是协议执行主体。强行把 SIP/RTP 全塞进 Workerman，等于用螺丝刀当电焊机用——能动，但烫手还伤设备。
最容易被忽略的兼容性雷区
- GB28181–2022 新增的
MobilePosition订阅和加密信令（TLS/SRTP）支持，Workerman默认 UDP Worker 无法处理 DTLS 握手，必须换用ssl://或引入openssl扩展手动解包 - 多网段部署时，设备 NAT 类型（Full Cone / Restricted / Port Restricted）直接影响 RTP 端口映射，
Workerman无 NAT 穿透能力，必须依赖 ZLMediaKit 的ice_servers或 STUN 配置 - 某些国标平台（如部分公安专网部署）强制要求 SIP Via 头带
received和rport，Workerman原生不自动补全，需在收到包后手动解析 IP:Port 并重写头字段
这些细节不会出现在 demo 代码里，但上线后第一周就会触发大面积注册失败或拉流黑屏。与其花三天调试 Workerman 的 SIP 分片重装逻辑，不如直接用 ZLMediaKit 提供的 gb28181_server 模块，它已通过 GB/T 28181–2022 全项认证。
