摘要

  • History-Info 保存支持该扩展的 SIP 节点所公开的 Request-URI 变化；点分 hi-index 组成有序分叉树，rc、mp、np 分别描述同一目标用户的地址变化、映射到另一目标用户，以及只改变下一跳。
  • 这棵树可能经过不支持扩展的节点、旧版条目、推断补位、尚未完成的分支或隐私匿名化。TLS/SIPS 能阻挡路径外篡改，却不能证明每个受信中介都诚实。
  • 可辩护的改投决定还需要规则版本、执行者、查询输入、分支状态、隐私处理、下游事务和实际服务结果。历史能说明绕行经过，不能赋予绕行权力。

一棵漂亮的树，遮住了最重要的问题

设想一条受监管的服务热线。合同规定来电只能进入企业自营队列，但一名用户最终接通了外部承包商。运营团队调出 SIP 报文：History-Info 从公开号码开始，经过企业地址，最后指向承包商应用；索引连续，结构完整，终点还返回了 200。控制台因此显示“路由已验证”。

这份记录可以完全真实，却仍然无法回答投诉。

它说明在某个观察点上，参与系统公开了哪些 Request-URI。它没有说明是谁启用了转接规则、规则使用了哪一版目录、企业是否批准该承包商、是否另有被隐去或尚未返回的分支、隐私服务是否匿名化了内部目标、路径内中介是否改写过记录，也没有说明媒体是否真正建立、真人是否接听、承诺的服务是否交付。

问题不在于使用 History-Info，而在于让它替协议范围之外的权力发言。

RFC 7044 把 History-Info 定义为可选的请求历史扩展。它为初始请求或对话外请求保存普通改投会覆盖掉的目标 URI，帮助下游理解请求如何、为何到达。它没有把本地目标判定政策写成全球规则。

当前地址为何会抹掉来路

按照 RFC 3261，代理可以查询位置服务、遵循重定向、应用本地配置并把请求转向新目标。新的 Request-URI 对下一跳很清楚：现在去哪里。但在没有额外记录时，它未必说明刚才打算去哪里。

RFC 7044 所称的 retargeting，就是实体依据目标判定规则改变 Request-URI 并继续转发。History-Info 保存旧目标，让后续节点看到更长的来路。

这里有三件不能合并的事：运行中的代理选择了目标；报文记录了该选择的一部分；标准和注册表规定了记录格式。IANA SIP 参数注册表 收录 History-Info、histinfo、history 和 rc/mp/np，只证明这些名字获得分配，不证明某个部署支持、正确执行或有权改变路线。

范围也很窄。History-Info 面向初始请求和对话外请求，不是整个通话生命周期的总账。对话建立之后的信令、媒体、录音、坐席状态、计费和用户体验都需要各自证据。把它们压成一条“通话历史”，是应用自己的模型，不是 RFC 7044 给出的事实。

点号写出的是树，不是时间

每个历史条目都必须包含目标 URI 和 hi-index。索引由点号分隔的非负整数组成：子节点延长父节点索引，分叉形成兄弟节点；输出顺序采用先序遍历，使接收方可以重建树形。

这比一张平铺列表更准确。两个并行分支若被写成连续两行，很容易被误解为先后执行的两次政策决定；树能说明它们来自同一个父目标。

但索引不是墙上时间。数字不表示毫秒，不证明两个独立节点谁先执行，也不保证字典序靠后的分支更晚完成。一棵结构正确的树仍然需要报文时间戳、观察点和事务关联才能成为时间线。

三个机制参数进一步描述边的性质：

  • rc 表示 Request-URI 改变，但目标用户仍被认为相同，例如地址记录解析到注册 Contact 或别名；
  • mp 表示映射到另一目标用户或地址记录；
  • np 表示 Request-URI 没变，只改变了下一跳，例如宽松路由。

它们是插入节点对自身操作的分类，不是许可证。rc 不能证明两个身份在制度上属于同一责任主体；mp 不能证明跨用户映射获得批准；np 也不能证明下一跳可靠。格式正确，只能证明格式正确。

“没有写”至少有五种含义

第一，扩展本身是可选的。histinfo 放在 Supported 中，不通过 Require 或 Proxy-Require 强迫沿途每个节点参加。请求可能经过完全不知道 History-Info 的设备。

第二，旧节点可能仍携带已被取代的 RFC 4244 格式。RFC 7044 要求兼容这些条目，却禁止后来的节点替自己没有观察过的决定编造 rc、mp 或 np。机制参数缺失可能只是旧证据，而不是“没有发生改投”。

第三，接收方可能发现当前 Request-URI 与最后一条历史不一致。它应代表前一个实体补上一条 gap entry，诚实记录“目标确实变了”。因为它没有看到规则运行，不能给补位条目添加机制分类。这个空洞是事实，不应被控制台偷偷补成确定答案。

第四，分叉结果取决于观察时刻。RFC 7044 的示例中，一个分支先返回成功，另一个仍在等待。成功响应不可能包含尚未来到的未来结果。只看获胜分支的收集器，可能拿到有效但不完整的树。

第五，隐私政策可以合法隐藏分支。旧版 RFC 4244 的示例还说明，上游看不到私有分支时，可能再次尝试一个它不知道已尝试过的目标。隐私与路由优化之间存在真实张力。正确做法是为不完整数据设定安全默认值，而不是宣布可见列表就是全部现实。

因此，可靠表述应当是：“这份报文在这个观察点包含这些条目。”危险表述则是：“请求经过的所有地方都在这里。”

Reason 说明协议现象，不替人解释动机

History-Info 可以在 URI 的 headers 部分携带 Reason 信息。RFC 3326 定义 SIP 与 Q.850 等原因命名空间，也允许同时出现不同协议的原因。RFC 7044 用它记录特定非成功响应和超时。

它能解释一条分支为何继续：某目标报告忙，某节点等待超时。它不能证明人为什么设置转接、该响应是否诚实、用户是否同意，也不能自动成为商业故障的根因。若缺少完整性保护，Reason 还可能被删改；保存时必须带上来源实体、具体报文和观察点。

RFC 7044 勘误登记 中有一项 Reported 技术问题，质疑 Reason 应覆盖哪些响应类别；另有索引问题和交叉引用问题，此外还有两项 Rejected。Reported 不等于 Verified。工程人员应把它当作测试提醒，而不能把报告者的建议说成现行规范。

隐私会有意缩小可见现实

目标历史可能泄露个人设备、备用身份、内部分机、语音信箱和网络拓扑。RFC 3323 解释了 SIP 为何需要中介提供隐私：代理产生路由字段，终端无法在代理使用前先把它们删除。

RFC 7044 增加 Privacy: history。隐私可以覆盖相关历史，也可以针对某个条目。即使入站报文说不需要隐私，中介也可保护本域内部路由；接收方还可以避免向主叫方暴露最终到达目标。跨域隐私服务可把 URI 改成 anonymous.invalid 下的匿名地址。

匿名化不必然意味着恶意篡改。它可能正是政策要求。不过，下游得到的事实随之变窄：它可以证明某边界执行了匿名化，不能凭公开字段还原被隐藏的目标和政策。

因此必须分别记录“谁有权选择目标”和“谁有权隐藏目标”。若系统只留下“路线已规范化”，路由权和隐私权都会失去可审计性。

TLS 保护通道，不为所有中介背书

RFC 7044 强烈建议 TLS，或者只在安全环境中使用。SIPS 在其信任模型下可以阻止路径外任意参与者篡改报文。这并不等于端到端证明。

History-Info 得到的保护与同一路径上的其他 SIP 头相同，不多也不少。中介需要读取并追加它。恶意或被攻破的路径内中介仍可删除、重排或改写条目；RFC 7044 明确说该机制不能防止或检测这种行为。

所以“用了 TLS”和“历史经过端到端认证”是两句话。严谨系统要保存每个观察点的 TLS 对端、证书结果、信任域、报文指纹，并在重要边界两侧对账。

应用没有一个全球通用的“正确条目”

RFC 7044 要求应用为缺失和不完整数据定义默认行为。它还指出，不同业务会从不同条目中得到价值。

企业 PBX 与消费者语音信箱可能选择不同位置的 rc 条目来识别被叫方。若呼叫在进入企业前已经转接，粗暴使用“第一个 rc”就可能把企业外身份当作内部用户。RFC 4458 对语音信箱也给出类似边界：目标和 cause 信息可能在当前 Request-URI，也可能在 History-Info，取决于代理支持和具体路径。

树本身不会产生唯一选择器。应用必须公开自己的目的、信任哪些域、如何处理 gap 和隐私、条目冲突时采用什么规则。

这正符合 Heng Lu 所强调的最小初始规范：公共层提供足够的互操作结构，未来普通决策留给有上下文、承担后果的参与者。真正危险的不是本地解释，而是把隐藏的本地解释包装成协议自己的结论。

能经得住争议的证据链

第一层保存报文本身：方法、入站与出站 Request-URI、Call-ID、CSeq、Via branch、时间、观察点和受控指纹。

第二层原样保存收到与发出的树：顺序、hi-index、URI、rc/mp/np 引用、Reason、隐私标记、旧版状态、解析结果与补位条目。绝不替缺失机制猜答案。

第三层记录头字段没有承载的决定：目标规则 ID 与版本、查询数据源及结果、重定向响应、候选集、选择结果、回退顺序、分叉创建和执行身份。再把服务身份绑定到规则所有者、授权范围、启用时间、审批和紧急覆盖。

第四层专门记录信任与隐私：哪个域收发、认证了哪个 TLS 对端、哪项隐私政策生效、谁匿名化了什么、受保护映射保存在哪里以及谁能访问。

第五层跟踪执行和结果：各分支事务、响应、超时、CANCEL、获胜分支、B2BUA 上下游腿映射、对话、媒体、实际应用、录音、计费和投诉处理。

矛盾必须留下。一份成功响应可能缺少已知兄弟分支；rc 的“同一用户”可能与租户边界冲突；Reason 可能与应用日志不一致；B2BUA 的公开树正确但腿映射丢失；200 存在而媒体失败。把这些矛盾压成“路由已验证”，就是由数据压缩产生的权力。

来源