摘要

  • RFC 3087 允许 SIP 客户端或代理通过不同的 Request-URI 指定应用的起始状态：留言、播放某段问候、取信，或先要求输入 PIN。
  • URI 选择的是本地配置的行为；它不证明来电者是谁、是否有权访问邮箱、呼叫为何被转接，也不证明留言已经存下或被人听到。

呼叫到了，旧电话网的线索却散了

传统语音信箱常从被叫号码、主叫号码和转接原因推断下一步。占线时播放一段问候，无人接听时播放另一段；用户从自己的办公电话取信，系统甚至可以少问一次邮箱号码。这种便利建立在一串信任上：交换机提供的每个字段都得保持它在本地网络中的含义。

SIP 让路径变得更灵活，也让这种推断变得危险。请求可以连续经过多个代理并多次改变实际目标，To 字段仍可能保留最初的逻辑收件人。RFC 3087 举了一个短而尖锐的例子：A 呼叫 B，B 把全部呼叫转给 C，C 又把呼叫转进自己的语音信箱。信箱若只看 To: B 来找存储区，便会为错误的人打开邮箱。

RFC 3087 于 2001 年 4 月以 Informational 文档发布。它没有增加新的 SIP 方法或首部，而是利用 RFC 2543 已有的差异：代理可以改写 Request-URI，To 则不是同一种当前路由目标。只要当前目标能够指向一项服务，它也就能够指向这项服务的某个初始状态。

因此，真正的变化不在报文多了一个字段，而在责任的位置改变了。语音应用不再从残缺的历史信号猜测上下文；上游路由决策把所选上下文明确交给它。

同一座语音信箱可以开很多扇门

文档为一个用户设想了多组 SIP 身份。一扇门接收普通问候后的留言；另一扇门播放占线问候；还可以有特殊问候。取信也能分成不同入口：某个 URI 面向已经通过 SIP 认证的请求，另一个入口则先在语音通道里索要 PIN。通用入口甚至先询问要访问哪一个邮箱。

“找到我”代理可以选择这些入口。尝试完所有联系地址仍无人接听，它就转向普通留言入口；收到各处均占线的结果，它可以转向占线问候；用户启用免打扰时，又可以选择另一项服务。信箱收到的是已选择的当前目标，不必再从 To、From 和电话交换机遗留下来的习惯中复原上游判断。

不过，URI 里的可读词语并不是标准化指令。RFC 3087 特别告诫应用，不要对助记字符串施加固定语义。运营者可以使用 deposit、一串号码、带参数的用户名称，或其他有效 SIP URI；应用应依据配置把任意已配置身份映射到行为。这个词典归系统所有者控制。

这也规定了证据边界。抓包里出现 busy，可以帮助人阅读，却不能独自证明之前真的发生了占线。它只能证明某一跳收到过这串目标。要确认其含义与来源，还需要当时生效的配置版本，以及代理为何进行改写的记录。

找到哪扇门，不等于拿到了钥匙

取信场景把服务选择与准入分得最清楚。语音信箱可以信任一条具有安全通信关系的来源，让保护代理代为认证；也可以根据 SIP 认证结果允许访问。认证失败或根本没有认证时，服务或代理能够把请求改写到需要输入 PIN 的入口。

因此，某个“用户专属取信 URI”只是选择取信流程，并未授予取信权限。真正的准入来自信任关系、SIP 凭证或 PIN。即使网关认出了 PSTN 来电号码，也只是运营者选择相信的一项观察，并非正在说话那个人的密码学身份证明。

RFC 3087 的详细呼叫流程全部假定语音信箱前有保护代理，而且二者之间存在信任关系。其安全章节没有创造新的保护机制，只把实现者带回 SIP 本身的安全约束。

一份网络记录因而只能支持有限的事实链：代理收到了 INVITE；它选择了某个 Request-URI；应用接受了这个目标；某种认证分支被执行；RTP 会话建立。任何一项都不能单独证明来电者拥有邮箱、上游转接原因真实、PIN 没有泄露、录音已持久保存，或后来真的有人听过。

本地约定还不是跨厂商语言

RFC 3261 后来取代早期 SIP 规范，但保留了核心机制：Request-URI 表示当前被寻址的用户或服务，代理选择目标时会替换它。之后的 History-Info 规范为携带重定向历史提供了办法。这些记录帮助区分“当前目标”和“走过的路径”，却不能反向证明某个 RFC 3087 系统采用了它们。

2006 年发布的 RFC 4458 更能说明局限。它为语音信箱和交互式语音应用规定了 target 与 cause URI 参数。其理由很务实：各厂商当然可以把本地映射做成可配置项，但仅靠配置，呼叫控制、网关和统一消息系统之间仍没有共同的邮箱与原因表达。

RFC 3087 解决的是一项架构问题：让 URI 成为应用上下文的控制面，同时不把当前目标与逻辑身份混为一谈。RFC 4458 解决的是互操作问题：为跨实现传递的两项信息建立共同词汇。后者的出现并不能证明前者成功、失败或曾被广泛部署。

这段历史真正留下的是证据链的形状。最初呼叫目标、当前 Request-URI、代理改写原因、本地映射表、认证结果、所选菜单、媒体会话和存储回执相互关联，却不是同一事实。把上下文放进路由，能够减少猜测；它不会把路由变成身份。

来源

  1. https://www.rfc-editor.org/info/rfc3087
  2. https://www.rfc-editor.org/rfc/rfc3087.html
  3. https://www.rfc-editor.org/rfc/rfc3087.txt
  4. https://datatracker.ietf.org/doc/rfc3087/
  5. https://www.rfc-editor.org/errata/rfc3087
  6. https://www.rfc-editor.org/rfc/rfc2543.html
  7. https://www.rfc-editor.org/rfc/rfc3261.html
  8. https://www.rfc-editor.org/rfc/rfc4244.html
  9. https://www.rfc-editor.org/rfc/rfc4458.html
  10. https://www.rfc-editor.org/rfc/rfc3326.html
  11. https://www.rfc-editor.org/rfc/rfc5411.html
  12. https://www.rfc-editor.org/rfc/rfc7044.html