rogee/go-sip
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: record Zhongding debug evidence and deployment blockers

Browse Source
This commit is contained in:
rogee
2026-10-08 17:23:28 +08:00
parent 310a14f9b3
commit 31ebda9600
2 changed files with 72 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+1
View File
@@ -85,6 +85,7 @@
- 使用者批准独立的测试专用 `deploys/test/saas-mock/` 仅模拟缺失的 SaaS：从 0600 的静态快照提供五类正式 HTTP 配置，在专用 RabbitMQ vhost 中由模拟 SaaS 预建现行拓扑；不在 Dispatcher 内注入快照；默认不发布外呼消息，只有受限脚本已为同一 `event_id`/线路/原始号码启动抓包后，才可显式单次 MQ 投递；不替代 Agent/Asterisk/AI/OSS。测试用正式入口必须同时具备只读配置、专用 MQ、真实 Agent/Asterisk/AI/录音/OSS、逐通确认和拨号前活跃抓包证据，缺一项不得试拨。此模拟不构成真实 SaaS 签收。
- 开发按 TDD 分批，小步提交；不得覆盖使用者现存修改/未跟踪文件，不自动清理、迁移或覆盖任何现存 SQLite、spool、outbox 和 Agent 恢复文件。旧 `.executions` 及恢复根目录中旧 `.uploads`、`.upload-locks`、逐执行 `state.json` 的发现须只读失败关闭，现存未交付事实由使用者确认处置。真实云账号、EIP、线路、拨号、生产部署和共享数据操作分别需要明确授权。
- 2026-10-08 使用者指定中鼎改为 `222.186.130.228:5060`、主叫保持 `mbkq`，ENV 与 SaaS 测试 SIP revision 15 已更新，其余两线未变；源码 `310a14f` 的 Agent/Dispatcher 与 sip-call 已部署。获批独立工具 DEBUG 只实际发出一通：1 个 INVITE transaction、6 包（5 次协议重传），0 SIP 回复、未接通；原 `unknown` 结果保留，后续精确原通道 404 的操作者证据先私密落盘后才恢复本通原始配置，未改写为正式终结结果。Agent active、Dispatcher 保持原来 inactive、Asterisk 未重启。新版拒绝旧 SQLite 6 表/version 2，使用者未批准替代运行目录，不能自动迁移、清理或以新空库绕过；恢复后的业务中鼎 AOR 仍为旧地址，不能把工具临时加载等同于持久业务配置生效。DEBUG 还确认 transport 未设外部信令/媒体地址、报文公布私网地址，但旧中鼎抓包在同样设置下仍返回 480，不能把此次无回复唯一归因于 NAT 或断言供应商故障；未修改静态 transport、重启 Asterisk或重复盲拨。现场与回归边界见 [`docs/evidence/zhongding-new-ip-sip-call-debug-20261008.md`](docs/evidence/zhongding-new-ip-sip-call-debug-20261008.md)。
- 2026-10-08 使用者批准独立测试工具 [`cmd/sip-call`](cmd/sip-call/README.md)：单独编译，以 `sip-call call --sip <线路.env> <原始号码>` 自动加载固定 ENV、临时配置并核对原生 Asterisk，仅拨一通，不接 SaaS/MQ/AI/OSS，不重拨、不换线；业务 Agent/其他 ARI 应用须停止，活动通话或旧测试配置阻断执行。仅 `--debug/-D` 才使用 tcpdump/tshark 收集本通证据；不带参数只报告原生通道事实，不编造 SIP/媒体/抓包事实。`sip-go-agent agent` 同样增加 `--debug/-D`，默认不依赖外部 tcpdump/抓包凭证；调试复用现有抓证脚本并在拨号前严格核对活跃凭证，不能静默降级。HEP 真实 SIP 响应、业务授权、时段、额度及未知执行保留规则不变。开发核验已完成；2026-10-08 经使用者另行确认，独立工具及按当前表生成的三份 0600 ENV 已部署到登记测试机 `rogee` 用户的 `~/sip-call/`，未更新业务 Agent/Dispatcher、未加载或改动既有 Asterisk 线路、未拨号或调用 AI。默认运行不调用抓包工具；使用者进一步要求生产和测试安装环境均统一预装 tcpdump/tshark，不按环境跳过，但抓包仍须显式 `--debug/-D`，不足时不能静默降级。登记测试机现已安装并核对 tcpdump 4.99.5、TShark 4.4.19 的 SIP/RTP 解析能力；未开启抓包或更改抓包权限，不能把工具安装当作逐通抓证、线路接通或生产签收。部署来源、文件 hash 和只读主机事实见 [`docs/evidence/sip-call-test-deployment-20261008.md`](docs/evidence/sip-call-test-deployment-20261008.md)。独立工具不属于生产发布制品，也不授权真实试拨。
## SaaS、Dispatcher 与 Agent 的现行边界
docs/evidence/zhongding-new-ip-sip-call-debug-20261008.md
+71
View File
@@ -0,0 +1,71 @@
# 中鼎新地址与独立 SIP 工具 DEBUG 核验（2026-10-08）
## 授权及范围
使用者指定中鼎服务地址改为 `222.186.130.228:5060`，主叫保持 `mbkq`，其他字段不变；批准同时部署最新 Agent/Dispatcher 与独立 sip-call，并给出一个号码用于无 AI 的连通测试。首次工具在拨号前失败后，使用者批准在工具问题修复后继续验证，无需重复确认；随后要求利用 DEBUG 区分工具、网络和供应商问题。本次没有因供应商不回复而重复拨号，没有换线、AI/OSS 请求或其他生产主机操作。
- 现场 `~/sip-call/zhongding.env` 只替换 `SIP_SERVER`，保留无前缀、UDP、IP/none、无需 REGISTER、PCMA、原有等待/保持参数。另两份 ENV hash 不变。
- 当前测试 SaaS 的 `sip.json` 只改变中鼎 `server_host`，并按现行规则把 SIP revision 从 14 增至 15；其余两条 trunk 的 JSON 内容逐项一致。原字节及 SQLite 均私密备份。
- 不带 DEBUG 不自动抓包；本通显式 `-D`，拨号前启动 PJSIP logger 和限目标 IP 的 tcpdump。仅该次临时 systemd 进程赋予 CAP_NET_RAW，没有改变工具 file capability、普通用户组或长期权限。
## 代码、部署及回归
源码提交 `310a14f9b359a81813569bccc05ae08d614b2601`；现行 Schema 固定为 `9bbf281675fbdcd53065fa87b54d65ae14f4b7ed`。
| 制品 | SHA-256 |
| --- | --- |
| sip-call | `f182ddb286847a999592aea8c875ff511d527eb031492f00849bea1fec9e7691` |
| sip-go-agent | `8c6c6f1f12239dafedda59264a8a2dc5831f6ce3e5129698f3660ed2b7ccdbb9` |
业务版本安装在 `/opt/sip-go-agent/releases/nonprod-zhongding-20261008-310a14f/`；当前两角色 unit 使用专用 drop-in 指向该版本，不覆盖旧发布目录。Agent active，实际进程 executable 路径已核对；Dispatcher 保持原来的 inactive，不能声称业务 Dispatcher 已通过现场启动。Asterisk 保持 active、MainPID 777461 未变，最终 0 活动通道；本次没有重启 Asterisk。
本地 `make check`、当前合同/Proto 校验、全仓 race、vet、构建、发布门禁、实际隔离 RabbitMQ/HTTPS/mTLS 端到端通过；排除生成代码的业务覆盖率 **71.6%**。这不构成生产发布批准。
### 两个工具问题
1. 测试机不提供可选别名 `pjsip reload`。Asterisk CLI 对不存在的命令仍返回退出码 0，旧代码把它误当成功，随后运行态核验阻止了拨号。现场不拨号诊断证实 `module reload res_pjsip.so` 可用且能加载/恢复期望 endpoint/AOR。修复同时覆盖配置加载、恢复和精确成功响应校验，并保留异常输出 hash；有先失败后通过的回归测试。
2. 旧终结核验在 Hangup 后只读一次通道。本通原始记录为 `unknown`，后续对原通道精确只读查询返回 404；原始即时读取没有完整诊断信息，**不能声称已经重现并唯一证明其 unknown 的原因**。改为使用独立有界上下文等待原通道确实消失，只有相同通道的 404 或真实终结事件才证明结束；读失败、仍存在或超时明确报错，Hangup 仍只提交一次。增加异步消失/持续存在/读取失败测试，以及脱敏 execution_id、readbacks、HTTP 状态日志。现场 opt-in 诊断只 Create/Hangup、不调用 Dial，使用新版逻辑确认精确通道 404；不算新的真实外呼，也不替代原通话的原生终结回报。
## 本通真实事实
首次命令在拨号前退出，未发 INVITE。修复后只实际发起 **1 通**：
- 原始 INVITE transaction **1 个**，包 **6 个**，其余 5 个是同一 Call-ID/CSeq/Via branch 的协议重传，不是重拨。
- 时间约为 0、0.504、1.506、3.507、7.508、15.508 秒。
- 目标 `222.186.130.228`，UDP 源/目标端口均 5060；抓包方向为实际 outgoing。
- 主叫 `mbkq` 与获批原始号码核对通过，无号码前缀变化。
- Wireshark 未判定畸形包；Request-Line/CSeq 正确，静态 RTP payload 8（PCMA）存在；六个包的声明 Content-Length 与实际 SDP 长度均 236。
- 捕获 **0 SIP 回复**、0 RTP；未接通。捕获仅限该服务器 IP，不能用零 RTP 证明所有其他媒体地址均无流量。
- 原工具结果是 `unknown` / answer_wait deadline / end_confirmed=false，原字节保留；不改写为成功或正式终结结果。
| 原始证据 | SHA-256 |
| --- | --- |
| 本通 capture.pcap | `4f9c4d85c8518172ea7f886603dda7f01e3704ce1991231de43e86e5dae0161f` |
| 本通原 result.json | `df9eb9dd7965edbf041951268cf67780e52f7abdd7d9c74399556720460a744f` |
精确原通道 404、无活动通道及原配置 hash 在操作前私密记录后，恢复的是本通保存的原始 `pjsip.conf` 字节；仅在当前文件与本工具追加的 `#tryinclude` 精确一致时才执行，未覆盖其他变动。临时 endpoint 已移除；原 unknown 结果、抓包和临时配置备份完整保留，没有修改业务 inbox/outbox 或清理旧执行。
## DEBUG：能排除什么，仍不能排除什么
### 已观察到
- 工具确实交给原生 Asterisk 发出了目标正确、主叫/号码/PCMA/长度正确的 INVITE。不是“工具没有发包”，目前没有畸形 SIP 的证据。
- 本机路由：eth0 经 `172.16.0.253` 发出，源地址 `172.16.0.125`。nftables 列表为空；不能据此代签云网络、EIP 或所有其他过滤机制。
- transport 的 `external_signaling_address`、`external_media_address`、`local_net` 为空，`allow_reload=false`。实际 Via/Contact/SDP 均公布 `172.16.0.125`；Via 带 rport。公网通信的地址配置存在缺项，尤其不能据此保证媒体回传可用。
- 同一主机的既有中鼎旧地址抓包（hash `a62b9c98f4813711e36b10ce64b0642cd6bd8e32822cea32d6473187c990df44`）显示：向 `60.171.24.90` 发 INVITE 时 Via/Contact/SDP 同样是 `172.16.0.125`，却收到来自旧服务器的 SIP 480。该历史事实不能批准重拨，但说明“私网公告地址”本身不是此次无 SIP 回复的充分证据。
### 结论边界
新地址的 UDP 服务、链路可达性、供应商对测试机公网源地址的接纳条件，都尚未由对端事实确认。仅凭本机 outgoing 抓包，无法证明包已经抵达新服务器，也无法在“中途被丢弃”和“服务器收到后不回复”之间作唯一判断。当前证据更应核对新地址/服务/线路授权，而不是继续改 INVITE 或反复拨号。需要供应商按本次时间窗核对是否收到来自登记测试机公网地址的 INVITE，并提供接纳/拒绝事实。
本次没有修改静态 transport、重启 Asterisk、调整防火墙、替换鉴权方式或增加 REGISTER；不能用未验证的 NAT 改动冒充“无回复已修复”。
## Dispatcher 与配置生效的独立缺口
正常 Dispatcher 原来已停止。为了同步新 SIP 配置，曾尝试相同旧数据目录的独立 `sip-only` 入口，但新版显式拒绝现存 SQLite **6 表/version 2** 布局，不建立兼容或偷偷迁移。没有 SIP 加载成功记录，没有消耗业务任务或新呼叫。
使用者没有批准新建替代数据目录，而要求优先做 DEBUG，故没有绕开旧数据库。当前新地址已存在于 ENV 和 SaaS 测试快照，独立工具也已真实向其发包；恢复后的 Asterisk **业务**中鼎 AOR 仍为旧地址。不能把临时工具加载当成持久业务配置已更新，也不能把业务制品已安装写成 Dispatcher 运行已验收。旧数据的后续处置和业务配置实际同步仍需明确决定。
## 私密记录
本机：`.local/zhongding-deploy-20261008-1QoPL6/final-evidence/`（0700，文件 0600）。现场：`~/.zhongding-deploy-20261008-AVIRIF/` 及该通 `~/sip-call/results/`。公开文档仅保留上述脱敏结论、计数和 hash，不附号码、完整 SIP、凭据、录音或对话。