摘要 GB28181 接入是链式流程：注册→保活→目录→点播→媒体流。任何一环断裂，后面都无法进行。GBDoctor 用分段推进引擎，自动定位断点。本文解析其状态机设计与实现。

1. 链式依赖

注册成功 → 才能发保活    保活稳定 → 才能查目录    目录完整 → 才能点播    点播成功 → 才能收 RTP    如果注册都没通，测目录毫无意义。分段推进的核心：按顺序执行，遇到阻断级问题立即停止，并报告断点。

1. 状态机设计

type Stage int

const ( StageRegister Stage = iota StageKeepalive StageCatalog StageInvite StageRTP StageClock StageDeviceInfo StagePTZ StageAlarm StageRecord StageVoice StageGB2022 )

type StageResult struct { Stage     Stage Passed    bool Blocking  bool Issues    []Issue Evidence  []Evidence Duration  time.Duration }

type Engine struct { stages  []Stage results map[Stage]*StageResult ctx     *DiagContext }

func (e *Engine) Run() *Report { for _, s := range e.stages { res := e.runStage(s) e.results[s] = res if res.Blocking { break } } return e.buildReport() }

1. 每个阶段的实现

以注册阶段为例：

func (e *Engine) runRegister() *StageResult { res := &StageResult{Stage: StageRegister} // 1. 发送 REGISTER // 2. 等待 401 或 200 // 3. 若 401，计算 Authorization 重发 // 4. 等待 200 OK // 5. 记录报文证据 // 6. 匹配规则 if timeout { res.Blocking = true res.Issues = append(res.Issues, Issue{ Title: "注册超时无响应", // ... }) } return res } 保活阶段：发送 Keepalive，等待 200 OK，检查周期。

目录阶段：发 Catalog，收应答，校验 XML。

点播阶段：发 INVITE，收 200 OK，解析 SDP。

媒体流阶段：收 RTP，统计丢包、SSRC。

1. 超时与重试

每个阶段有独立超时：

const ( RegisterTimeout  = 5 * time.Second KeepaliveTimeout = 3 * time.Second CatalogTimeout   = 10 * time.Second InviteTimeout    = 10 * time.Second RTPTimeout       = 15 * time.Second ) 重试策略：注册重试 3 次，保活重试 2 次，目录重试 2 次。重试仍失败则标记阻断。

1. 证据链收集

每个阶段收发的报文都存入 Evidence：

type Evidence struct { Timestamp time.Time Direction string // "send" / "recv" Raw       []byte Summary   string SHA256    string } 报告里可展开查看原始报文，并附 SHA-256 指纹，作为举证材料。

1. 报告中的断点可视化

注册 ●──●──✗──○──○──○    (✅通) (✅通) (✗断在目录) (未测) …    用 ● 表示通过，✗ 表示阻断，○ 表示未测。一眼看出断在哪。

1. 总结

分段推进引擎把 GB28181 接入从“黑盒”变成“白盒”。它不追求一次测完所有项，而是按依赖顺序推进，遇到阻断立即停止并报告断点。这符合现场排查的真实逻辑：先通注册，再谈其他。

项目地址 Gitee：suoten/GBDoctor GitHub：suoten/GBDoctor 搜不到？在 Gitee 或 GitHub 搜索：GBDoctor 或 suoten GBDoctor