摘要

  • RFC 3326 允许 SIP 请求携带发送原因，原因可以来自 SIP 状态码，也可以来自电信互通中的 Q.850 原因值。
  • 该字段不会改变 SIP 处理：CANCEL 仍负责取消；Reason 可以说明另一条分支已经接通。

一条支路接通，其他支路仍需停止

代理把 INVITE 分送到多个支路。一处返回 200 OK，其他电话却可能还在响。代理于是向其余支路发送 CANCEL。停止振铃的是 SIP 的 CANCEL 方法，不是描述事情经过的头字段。

RFC 3326 于 2002 年 12 月发布，为代理提供了附加说明的方式：Reason: SIP;cause=200;text="Call completed elsewhere"。接收端服务据此可以区分“另一支路已接听”和“呼叫者在接通前放弃”。这一区别可能影响未接来电记录或用户界面，而当下的协议动作并没有变化。

这种分离是 RFC 3326 的核心设计。SIP 已有用于响应的状态码，但同一种请求可能出于不同原因发出；而发起请求通常不会携带触发它的那份响应。Reason 把原因附到据此采取行动的请求上。它是解释性元数据，不是第二条命令通道。

原因值属于各自的协议空间

RFC 3326 用协议名称限定原因值。SIP 表示 cause 是 SIP 状态码；Q.850 表示它是 ITU-T 电信信令体系中的十进制原因值。这样，网关可以在 SIP 消息中保留来自传统电话网络的释放原因。单独一个数字并不足够，协议标签说明数字来自哪套编号体系。

text 参数便于人阅读，却不掌握协议处理权。原因值来自已标明协议的词汇表；实际的方法、状态和事务上下文仍由消息本身定义。把 cause=200 当作一份响应，或把 Q.850 数字当作 SIP 状态，都是把两种控制面混为一谈。

该字段也不保证所有实现都理解它。RFC 3326 允许实现忽略自己不认识的值，并明确指出 Reason 不影响协议处理。即使终端丢弃说明，请求仍按 SIP 规则运行。这使扩展能服务于应用逻辑，却不会变成呼叫基本状态的隐含前提。

分叉可能遮住的一份响应

规范还把 Reason 与分叉请求中的异构错误响应问题联系起来。一个 INVITE 的不同支路可能返回不同的最终失败。代理通常要等支路结果齐备后才决定向上游发送什么，因此另一支路尚未完成时，有用的错误可能无法及时呈现。RFC 3326 提出一种可能用途：把最终状态封装进临时响应。

这里的措辞不能夸大：这是候选机制，不是每次分叉都能暴露全部错误的保证，也不是已部署服务解决问题的证据。Reason 提供的是原因容器；它没有规定普遍适用的失败排序政策，也没有取代 SIP 响应处理。

后续扩展仍保留了边界

RFC 8606 后来为 Q.850 原因增加 ISUP 位置参数，使信令可以在信息可得时保留释放发生的位置。RFC 9366 则调整了同一协议值只能出现一次的旧规则，但前提是登记的协议定义了多值的含义。两者都让来源信息更具体，却没有把 Reason 变成执行动作。

这也是一段有用的协议史。RFC 3087 探索 Request-URI 如何作为本地服务选择上下文；RFC 3326 则把原因附在已经选定的 SIP 动作上。前者选择请求要去哪里，后者解释请求为何发出。两者都不能单独证明身份认证、访问授权、完整通话历史或下游结果。

来源

  1. https://www.rfc-editor.org/rfc/rfc3326.html
  2. https://www.rfc-editor.org/info/rfc3326/
  3. https://www.rfc-editor.org/rfc/rfc3261.html
  4. https://www.rfc-editor.org/rfc/rfc9366.html
  5. https://www.rfc-editor.org/rfc/rfc8606.html
  6. https://www.rfc-editor.org/rfc/rfc5411.html
  7. https://www.rfc-editor.org/rfc/rfc4411.html