作为通信学院的专家讲师，我将根据您的要求，继续深度剖析 SIP 协议的核心机制。本篇将聚焦于 SIP 协议中最抽象，但也是最关键的三个层次化概念：事务（Transaction）、对话（Dialog）与会话（Session），并结合运营商规范，阐释它们如何在 IMS 网络中协同工作。

---

VoLTE高清语音技术精要（三）：SIP的生命周期：事务、对话与会话的哲学关系

1. 导论：状态维护的哲学

SIP（Session Initiation Protocol）协议运行在无状态的 IP 网络之上，但电信级语音业务本质上是有状态的：网络必须精确地知道用户何时开始呼叫、何时结束、媒体参数是什么，以便进行正确的路由、业务触发和计费。

为了在无状态的传输层上构建有状态的业务，SIP 协议设计了三层递进的上下文管理机制，共同构成了呼叫的完整生命周期：

1. 事务（Transaction）：最小的交互单元，处理一次请求和它的所有响应，确保请求的可靠传输和处理。
2. 对话（Dialog）：持续的信令上下文，用于维系通信双方从开始到结束之间的所有后续信令交互（如挂机、媒体修改）。
3. 会话（Session）：媒体层面的上下文，通过 SDP 描述，代表实际的 RTP 媒体流。

理解 IMS 网元（尤其是 P-CSCF 和 S-CSCF）如何在 SIP 消息中创建、维护、刷新和终止这三种状态，是掌握 IMS 呼叫控制逻辑的关键。

2. 事务（Transaction）：信令可靠传输的基础

事务是 SIP 协议中最基本的请求-响应交换单元。它确保了一个请求及其最终响应能够可靠地交付给下一跳服务器或最终的对端实体。

2.1 事务的定义与标识

一个 SIP 事务由以下元素组成：

1. 一个请求（Request）。
2. 零个或多个临时响应（Provisional Responses，1xx）。
3. 一个最终响应（Final Response，2xx-6xx）。

事务的唯一标识符是 Via 头域中的 branch 参数。branch 参数是一个以 z9hG4bK 开头（用于区分 RFC 3261 兼容的实现）的随机字符串，用于将请求和其对应的响应关联起来。

核心机制：事务的可靠性

SIP 事务通过重传和定时器机制来保证可靠性。RFC 3261 定义了一系列定时器（例如 T1, T2, B, F, G, H, I, J, K）来控制消息的重传间隔和事务的超时时长。

例如：

• T1 (500ms 默认值)：往返时间 (RTT) 估算值，用于计算重传间隔。
• Timer B (64*T1)：INVITE 事务的超时定时器。在 P-CSCF/BAC 的容灾场景中，如果终端（UE）在 Timer B 定时器内未收到 INVITE 请求的响应，UE 可能会释放呼叫。
• Timer F (64*T1)：非 INVITE 事务的超时定时器。在短信始呼流程中，如果终端在 Timer F 内没有收到响应，短信始呼失败。

2.2 INVITE 事务的特殊性与 ACK 的角色

INVITE 事务用于建立会话，其重要性使得它需要一个更严格的三次握手机制来确保会话状态的最终一致性。

事务类型	确认机制	ACK 消息的地位
INVITE 事务	如果最终响应是 2xx 成功响应，则 ACK 不被视为该事务的一部分，而是一个独立的事务。
INVITE 事务	如果最终响应是 非 2xx 失败响应（4xx-6xx），则 ACK 必须包含在该事务中，完成事务的最后一步。
非 INVITE 事务 (Regular Transaction)	请求 → 最终响应 (如 REGISTER, BYE, OPTIONS, PRACK)。	无须 ACK 确认。

重要性：在 IMS 呼叫中，ACK 消息是确保媒体流建立的关键一步。当 UAC 收到 INVITE 的 200 OK 后，必须回复一个 ACK 请求。这个 ACK 请求本身就是一个独立的事务，其路由必须遵循 Record-Route 记录的路径。

2.3 P-CSCF 对事务状态的维护要求

P-CSCF 作为接入层的第一跳，必须维护事务状态，以确保安全性和计费的连续性。

P-CSCF 行为	描述	来源
事务处理	P-CSCF 应给所有的 INVITE 请求回送 100 (Trying) 临时响应。100 Trying 响应与其他临时响应不同，它不会被有状态代理向上游转发。
会话状态检查	P-CSCF 在收到 UE 发起的后续请求或独立请求时，如果没有发现存在对应的对话，P-CSCF 应回复 403 (Forbidden) 响应，且不再转发该请求。
计费锚点	P-CSCF 收到 UE 发起的请求时，会插入 P-Charging-Vector 头域，并增加 icid 参数。此动作确保了计费的准确锚定。
Via 列表验证	P-CSCF 收到响应时，必须确认 Via 列表是否与同一对话的请求消息中保存的 Via 列表相匹配。如果不匹配，P-CSCF 应丢弃该响应或替换成保存的 Via 列表。

3. 对话（Dialog）：维系呼叫的信令上下文

对话是在 SIP 协议中的两个用户代理（UA）之间建立的端到端信令上下文，它定义了从呼叫建立到终止期间，所有后续信令交互（如 BYE, UPDATE, Re-INVITE）的路由和顺序。

3.1 对话的唯一标识符（三元组）

一个 SIP 对话由以下三元组唯一标识：

标识符	所在头域	作用	产生方
呼叫标识 (Call-ID)	Call-ID	呼叫的全局唯一标识符。	UAC (请求发起方)
本地标签 (Local Tag)	From 头域的 tag 参数	标识 UAC 侧的对话部分。	UAC (请求发起方)
远端标签 (Remote Tag)	To 头域的 tag 参数	标识 UAS 侧的对话部分。	UAS (响应接收方)

重要细节：初始的 INVITE 请求中，To 头域是不带 tag 参数的。当 UAS 收到 INVITE 并返回任何响应（1xx 或 2xx）时，它会在 To 头域中添加 tag，此时对话才开始建立上下文。

3.2 对话的生命周期：早期对话与确认对话

对话的建立可以发生在不同的时间点，定义了两种对话状态：

1. 早期对话 (Early Dialog)

   • 建立时机：UAC 收到初始 INVITE 请求的临时响应（180 Ringing, 183 Session Progress）且该响应携带了 To 标签。
   • 作用：主要用于承载预通话信令，例如可靠回铃（180 Ringing）、早期媒体协商（183 Session Progress 携带 SDP Offer/Answer）。
   • 终止：通常通过 CANCEL 请求取消未完成的 INVITE 事务而终止。

2. 最终对话 (Confirmed Dialog)

   • 建立时机：UAC 收到初始 INVITE 请求的 2xx 成功响应（如 200 OK）时。
   • 作用：正式确认会话建立。所有后续的呼叫控制信令（如 BYE, Re-INVITE, UPDATE）都通过这个最终对话的上下文进行传输。
   • 终止：通过 BYE 请求正常释放。

3.3 B2BUA：对话的终结者与重建者

B2BUA (Back-to-Back User Agent) 是 IMS 网络中一种特殊的 UA 实体，如 AS (应用服务器) 或 SBC/IBCF (边界控制器)。B2BUA 在实现业务逻辑和拓扑隐藏时发挥关键作用。

B2BUA 关键行为	描述	来源
角色转换	B2BUA 在逻辑上由一个 UAS 和一个 UAC 组成，它终止（Terminate）第一个对话，并重新发起（Originate）一个全新的对话。
对话隔离	B2BUA 会修改会话标识符：两侧的 Call-ID、From-tag 和 To-tag 通常不同。
IMS 应用	在呼叫流程中，AS（如 MMTel AS）通常扮演 B2BUA 角色。例如，AS 在业务处理完毕后，会创建一个新的 INVITE 请求返回给 S-CSCF，导致 Call-ID 和标签改变。
IBCF 行为	IBCF 也可配置应用层网关功能 (ALG) 和 B2BUA 角色，需要保存 Contact、CSeq 和 Record-Route 的值，以便在需要时释放会话。

4. 可靠临时响应（PRACK & 100rel）：IMS 语音质量的关键

在 IMS/VoLTE 场景中，临时响应（例如 183 Session Progress）往往承载着重要的媒体协商信息（SDP Offer/Answer），以及触发底层 QoS 资源预留的关键信息。因此，这些临时响应的可靠传输至关重要，SIP 引入了 100rel 扩展和 PRACK 方法（RFC 3262）来实现这一点。

4.1 100rel 机制的要素

100rel（Reliability of Provisional Responses）机制主要涉及以下三个 SIP 头域和方法：

元素	所在头域/方法	作用	来源
能力声明	Supported: 100rel	UAC 声明支持可靠临时响应。UAC 应该在所有 INVITE 请求中包含此项。
强制要求	Require: 100rel	UAC 强制要求 UAS 必须发送可靠临时响应。
序列号	RSeq	可靠临时响应（101-199）中必须包含的序列号，用于排序和确认。编号空间在单一事务内。
确认方法	PRACK	Provisional Response ACKnowledgement。用于确认可靠临时响应（1xx）。
确认头域	RAck	在 PRACK 请求中携带，指明被确认的 1xx 响应。格式为 RAck: <RSeq> <CSeq> <Method>。

注意：只有 101 到 199 的临时响应可以被可靠传输；100 Trying 响应不能被可靠传输，它只能逐跳传输 (hop-by-hop)。

4.2 PRACK 与媒体协商和 QoS 的关联

在 IMS/VoLTE 呼叫中，183 Session Progress 响应通常被配置为可靠临时响应：

1. SDP 承载：183 Session Progress 响应中通常会携带 SDP Answer（应答），从而在被叫方摘机前完成早期的媒体协商。
2. QoS 触发：在支持 Precondition 机制的流程中，183 Session Progress 的收发是触发通信双方（主叫侧和被叫侧）底层专用 QoS 流（承载）建立的关键信令步骤。
3. PRACK 回复：主叫终端收到可靠的 183 响应后，必须回复 PRACK 请求进行确认。如果 183 中携带了 Offer，UAC 必须在 PRACK 中携带 Answer。

运营商规范明确要求 IMS 实体支持 PRACK 机制：

• P-CSCF 转发：P-CSCF 收到主叫侧终端发来的 PRACK 确认消息，以及后续的 200 OK 响应，必须进行确认和转发。
• MGCF 互通：在 IMS 与 CS 域互通时，如果 MGCF 收到 INVITE 请求的 Supported 头域值为 100rel，MGCF 可能会发送 183 Session Progress 消息，其中 Require 头域设为 100rel，以确保可靠传输。

5. 会话（Session）与资源保活机制

会话是最高层次的概念，它与实际的多媒体流（如 RTP/RTCP）相关联。会话的成功建立基于 SIP 信令（INVITE/200 OK/ACK）和媒体描述协议（SDP）的 Offer/Answer 模型。

5.1 会话定时器：幽灵会话的克星

标准的 SIP 协议缺乏会话“心跳”机制。如果终端异常断开（如掉电或网络故障），网络将无法感知会话终止，导致幽灵会话（Ghost Session），占用 IMS 核心网宝贵的信令状态和底层 QoS 资源。

为解决此问题，IMS 引入了 会话定时器（Session Timer，RFC 4028） 机制。

核心原理：

1. 协商过期时间：通过 Session-Expires 头域协商会话的有效期（通常默认值为 1800 秒，即 30 分钟）。
2. 刷新方：通过 refresher 参数确定由哪一方负责刷新（uac 或 uas）。
3. 周期刷新：负责刷新的一方（例如 UAC）必须在 Session-Expires 超时前，周期性地发送 Re-INVITE 或 UPDATE 请求来“续期”。
4. 超时处理：如果定时器超时仍未收到刷新请求，网络网元（如 P-CSCF 或 S-CSCF）将认为会话异常中断，主动向对端发送 BYE 请求以释放所有相关资源。

运营商对 Session Timer 的要求：

网元	要求	来源
P-CSCF	应支持 session timer 功能，并要求周期性刷新会话，以免 P-CSCF 的状态挂起。P-CSCF 在会话超时后，应删除和会话相关的信息，并向主被叫两侧发送 BYE 请求。
S-CSCF	如果会话周期性地被刷新，且定时器超时后，S-CSCF 应删除所有与该对话相关的保存信息。
IBCF	当收到 INVITE 请求时，IBCF 要进行周期性会话刷新以防止出现悬挂状态。

5.2 会话释放：BYE 与 CANCEL 的界限

会话终止主要通过两种 SIP 方法实现：

方法	目的	适用场景	运营商处理要求（P-CSCF/S-CSCF）
BYE	终止一个已建立的会话。	在对话内发送，用于会话结束、挂机、或会话定时器超时引起的释放。	P-CSCF/S-CSCF 收到 2xx 响应后，应删除所有与对话和多媒体会话相关的信息。
CANCEL	取消一个未决的请求。	主叫在被叫摘机前（振铃阶段，未收到 2xx）挂断时使用。	P-CSCF 在释放过程中收到关于对话的请求时，应回送 481 (对话或者事务不存在) 响应。

6. 信令实战分析：事务、对话与可靠响应的建立

我们通过一个实际的 VoLTE 呼叫建立流程，来观察事务、对话标识和可靠临时响应的交互。

场景： 主叫 UE（10.1.1.1）呼叫被叫 UE，呼叫需要使用 100rel 机制进行可靠媒体协商。

6.1 INVITE 请求：对话/事务的开始

主叫 UE 发送 INVITE，启动 INVITE 事务。

消息行/头域	示例值	事务/对话/会话 关联	来源
请求行	INVITE sip:[email protected] SIP/2.0	方法：INVITE。
Via	SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bKab546...	事务：branch 参数标识了 INVITE 事务。
From	<sip:zhangsan@...>;tag=a48s	对话：tag (a48s) 是 From-tag，对话标识的一部分。
To	<sip:lisi@...>	对话：无 tag，对话尚未建立。
CSeq	1 INVITE	事务：序列号，用于标识事务顺序。
Require	100rel, precondition	机制：UAC 强制要求可靠响应和资源预留机制。
SDP 消息体	a=des:qos mandatory local sendrecv	会话：携带 SDP Offer，描述媒体能力和 Precondition 需求。

6.2 183 响应：早期对话建立与可靠性要求

被叫侧 IMS 网元返回 183 Session Progress，触发主叫侧的资源预留，并建立早期对话。

消息行/头域	示例值	事务/对话/会话 关联	来源
状态行	SIP/2.0 183 Session Progress	事务：临时响应 (1xx)。
To	<tel:lisi>;tag=b77t	对话：UAS 添加 To-tag (b77t)，对话上下文（早期对话）正式建立。
Require	100rel, precondition	机制：再次强调可靠传输，表明这是可靠临时响应。
RSeq	1	机制：可靠性序列号，必须包含在可靠临时响应中。
SDP 消息体	a=curr:qos local none	会话：携带 SDP Answer，包含 Precondition 的当前状态。

6.3 PRACK 请求：可靠确认与媒体协商

主叫 UE 收到可靠的 183 响应后，必须发送 PRACK 请求进行确认。PRACK 属于非 INVITE 事务。

消息行/头域	示例值	事务/对话/会话 关联	来源
请求行	PRACK sip:next.proxy.net SIP/2.0	方法：PRACK。
CSeq	3 PRACK	事务：独立事务，CSeq 序列号在 INVITE 事务的基础上递增（如 INVITE 为 1，则 PRACK 为 3）。
RAck	1 1 INVITE	机制：核心头域。确认 RSeq=1 的响应，该响应属于 CSeq=1 的 INVITE 方法。
对话标识	Call-ID, From-tag, To-tag	对话：PRACK 必须在已建立的早期对话上下文中传输。

6.4 200 OK (INVITE)：最终对话建立与会话参数确认

当呼叫被接通（被叫摘机）或所有先决条件满足后，被叫 UAS 返回最终 200 OK 响应，建立最终对话。

• 对话建立：200 OK 响应携带了与早期对话相同的 To-tag，将早期对话升级为最终对话。
• 会话定时器：响应中包含 Session-Expires: 1800; refresher=uac，确认了会话定时器机制，并指定主叫方（uac）负责周期性刷新。
• 最终确认：主叫终端收到此 200 OK 后，会发送 ACK 请求（作为独立事务）来完成 INVITE 事务的三次握手。

7. 本章小结

SIP 协议通过事务、对话和会话这三个层次化的概念，实现了电信级所需的复杂状态维护：

• 事务（由 Via 头域中的 branch 标识）是确保单个请求/响应可靠交付的最小单元，其中 INVITE 事务需要 ACK 进行可靠确认。
• 对话（由 Call-ID、From-tag 和 To-tag 标识）是贯穿会话生命周期的信令上下文，由 UAS 在响应中添加 To-tag 建立。B2BUA 通过重建 Call-ID 和标签来隔离对话。
• 会话（由 SDP Offer/Answer 定义）代表实际的媒体流，其状态通过 Session Timer 机制和周期性的 UPDATE/Re-INVITE 进行保活和刷新，以避免 IMS 网络的幽灵会话。
• PRACK/100rel 机制是 IMS 确保 183 Session Progress 等临时响应可靠传输的关键，对媒体协商和 QoS 资源预留至关重要。

---

工程师进阶思考 (FAQ)

Q1：P-CSCF 是如何通过检查对话 ID 来防御非法请求的？如果 P-CSCF 收到一个属于已存在对话的后续请求（例如 BYE），但该请求的 Route 头域与记录的 Record-Route 不匹配，P-CSCF 如何处理？

A1： P-CSCF 通过两种方式检查请求的合法性：对话存在性和路由一致性。

1. 对话存在性检查：P-CSCF 收到 UE 发起的后续请求（如 BYE 或 UPDATE）时，会查找本地存储的会话状态信息（Dialog ID，IMPU/IMPI）。如果 P-CSCF 无法发现对应的对话，则 P-CSCF 应回复 403 (Forbidden) 响应，且不再转发该请求。此外，当 P-CSCF 在释放对话的过程中收到关于该对话的请求时，P-CSCF 应该中止该请求，并回送响应 481 (对话或者事务不存在)。
2. 路由一致性检查：对于 UE 发起的目标刷新请求（如 Re-INVITE 或 UPDATE），P-CSCF 需要确认请求中的 Route 头域列表是否与同一对话中保存下来的 Record-Route 头域列表相匹配。如果不匹配，P-CSCF 应返回 400 响应，或用 Record-Route 消息头信息替换 Route 消息头。这种检查防止了对话内的请求被劫持或路由到错误的目的地。

Q2：IMS 呼叫中，为什么 UPDATE 方法比 Re-INVITE 更适合用于会话刷新（Session Refresh）？它们在功能上有何区别？

A2： UPDATE 方法（RFC 3311）更轻量级，更适合会话刷新。

1. 功能区别：Re-INVITE 和 UPDATE 都可以用于在已建立的对话中修改会话参数（例如媒体编解码器、地址、端口）。然而，INVITE（包括 Re-INVITE）事务流程复杂，需要三次握手 (INVITE → 200 OK → ACK)，且可能触发媒体协商或资源预留。UPDATE 事务属于非 INVITE 事务，只需要简单的两次握手 (UPDATE → 200 OK)，流程更简洁。
2. 刷新优化：在会话刷新（心跳）场景中，通常不需要修改 SDP，只需保持会话活性。UPDATE 可以在不携带 SDP 消息体的情况下发送（Content-Length: 0），专门用于刷新 Session-Expires 定时器。虽然 Re-INVITE 也可以用于刷新，但 IMS 网元通常配置为优先使用 UPDATE 进行周期性刷新，以减少信令开销和复杂性。此外，UPDATE 还是 Precondition 机制中用于同步资源状态的关键方法。

Q3：在 IMS 互通场景中，SIP-I 协议（SIP with Encapsulated ISUP）中的 SIP 消息和传统的 SIP 消息在事务处理上有什么特殊要求？

A3： SIP-I 主要用于 IMS 网关（如 BGCF 和 MGCF）与传统电路交换（CS/PSTN）网络互通。

1. SIP-I 封装 ISUP：SIP-I 消息的特殊之处在于其消息体中封装了传统的 ISUP（ISDN User Part）消息。MGCF 负责将 SIP 消息（如 INVITE）转换为 ISUP 消息（如 IAM，Initial Address Message），反之亦然。
2. PRACK/100rel 的要求：由于 IMS 到 PSTN 的互通对信令可靠性要求极高（如传输回铃音信息），运营商规范明确提到 PRACK 消息及其成功响应可携带 SDP 进行媒体协商，通常用于与 CS 域互通。MGCF 在收到 INVITE 消息中 Supported 头域值为 100rel 时，如果它发现对端有能力提供可靠的临时响应，则 MGCF 可能会在 183 Session Progress 中设置 Require: 100rel，以确保媒体协商的可靠性。
3. 计费信息转换：MGCF 在处理 SIP-I 消息时，还会存储和插入 P-Charging-Vector 头中的 orig-ioi 和 term-ioi 参数，用于跨域计费关联。这些信令处理确保了 SIP 事务在跨越 IMS 和 CS 域边界时的语义完整性和业务连续性。