根据您的要求，我将继续撰写系列文章的第二篇。本篇将深入讲解 SIP 协议的结构基础、核心实体角色，以及最常用的 SIP 方法集。
VoLTE高清语音技术精要（二）：SIP协议基础与核心方法集深度解析
1. 导论：SIP通信模型的基石
在上一篇中，我们宏观地介绍了 IMS（IP Multimedia Subsystem）的架构及其核心信令协议 SIP（Session Initiation Protocol）的定位。SIP 是一个基于文本的、请求-响应式的应用层控制协议，专门用于在 IP 网络上建立、修改和终止多媒体会话。
本章将聚焦于 SIP 协议的基础结构，这是理解后续所有 IMS 流程（如注册、呼叫建立）的前提。我们将剖析 SIP 通信模型中的基本实体角色，理解 SIP 消息的文本结构，并详细介绍 IMS 网络中关键的 SIP 方法集（Method）。
2. 核心实体角色：UA、UAC、UAS 与 B2BUA
SIP 协议的核心交互遵循客户端-服务器模型。然而，SIP 实体通常是灵活的，可以根据消息的流向动态地扮演不同的角色。
2.1 用户代理 (UA)、客户端 (UAC) 和服务器 (UAS)
SIP 通信模型的基础是用户代理（User Agent, UA）。
| 实体 | 缩略语 | 核心定义 | SIP 事务中的职责 | 来源 |
|---|---|---|---|---|
| 用户代理 | UA | 一个逻辑上的端点，包含了 UAC 和 UAS 两个部分，能够创建和处理 SIP 消息。终端设备 (UE) 是最常见的 UA。 | 参与 SIP 通信的整体逻辑实体。 | |
| 用户代理客户端 | UAC | 请求的发起方。 | 负责创建并发送 SIP 请求。 | |
| 用户代理服务器 | UAS | 请求的接收方。 | 负责处理收到的 SIP 请求，并生成相应的 SIP 响应。 |
专家解读：角色的动态性
UAC 和 UAS 是逻辑角色，而非固定的设备身份。在 IMS 核心网中，一个网元（如 P-CSCF 或 S-CSCF）在转发请求时充当代理（Proxy），但在处理响应时，它又扮演服务器的角色。例如：
- 呼叫建立：UE 发送 INVITE 请求，此时 UE 是 UAC，接收请求的 S-CSCF 是 UAS。
- 呼叫释放：如果 S-CSCF 因为会话超时主动清理资源，向 UE 发送 BYE 请求，此时 S-CSCF 变为 UAC，UE 变为 UAS。
2.2 背靠背用户代理 (B2BUA) 的特殊角色
B2BUA (Back-to-Back User Agent) 是一种特殊的、复合型的 SIP 实体。IMS 核心网中的许多重要网元，如 AS (应用服务器) 和 SBC (会话边界控制器)，通常以 B2BUA 模式运行。
B2BUA 的核心特征：
- 对话终结与重建：它在逻辑上由一个 UAS 和一个 UAC 紧密耦合而成。
- 完全独立：它作为 UAS 接收并终止第一个 SIP 对话（对话 A），然后作为 UAC 重新发起第二个全新的 SIP 对话（对话 B）。
- 拓扑隐藏：由于它创建了全新的对话，两侧的对话标识（Call-ID、From-tag、To-tag）通常是不同的。这使得 B2BUA 能够对网络拓扑和会话状态进行控制和隐藏。
在 IMS 中的应用：AS（例如 MMTel AS）在处理主叫业务时，通常扮演 B2BUA 角色，终结来自 S-CSCF 的 INVITE，执行业务逻辑，然后用一个新的 INVITE 请求发回 S-CSCF，以便重新路由到被叫网络。
3. SIP 消息的结构与语法
SIP 协议采用文本编码（UTF-8 字符集），这使得其消息内容具有良好的可读性。SIP 消息的统一格式由三个部分构成：
- 起始行（Start-Line）
- 消息头域（Message-Header）
- 可选的消息体（Message-Body）
| 消息组成部分 | SIP 请求消息 (Request) | SIP 响应消息 (Response) | 作用 | 来源 |
|---|---|---|---|---|
| 起始行 | 请求行 (Request-Line) | 状态行 (Status-Line) | 定义消息类型和处理结果。 | |
| 消息头域 | 必选：Via, To, From, CSeq, Call-ID, Max-Forwards | 必选：Via, To, From, CSeq, Call-ID | 传递会话路由、标识和控制信息。 | |
| 消息体 | 可选，由 Content-Type 和 Content-Length 描述 | 可选，由 Content-Type 和 Content-Length 描述 | 承载会话净荷（最常见的是 SDP）。 |
3.1 起始行：请求行与状态行
（1）请求行（Request-Line）
用于 SIP 请求消息的起始行。它包含三个元素：方法 (Method)、请求 URI (Request-URI) 和 SIP 版本。
- Request-URI：指示请求的初始目标地址，是决定请求路由的第一要素。它可以是 SIP URI、SIPS URI 或 TEL URI。
示例：
INVITE sip:[email protected] SIP/2.0
（2）状态行（Status-Line）
用于 SIP 响应消息的起始行。它包含三个元素：SIP 版本、状态码 (Status-Code) 和文字描述 (Reason Phrase)。
| 状态码 (Status Code) | 范围 | 含义 | IMS 关键应用 | 来源 |
|---|---|---|---|---|
| 1xx | 100 - 199 | 临时响应，请求正在处理，会话可能尚未建立。 | 100 Trying（已收到请求）、183 Session Progress（媒体协商）。 | |
| 2xx | 200 - 299 | 成功响应，请求已被接受和处理。 | 200 OK（呼叫建立成功/注册成功/BYE成功）。 | |
| 3xx | 300 - 399 | 重定向响应，请求需要进一步行动。 | 302 Moved Temporarily（用于呼叫前转业务，要求重新发往 Contact URI）。 | |
| 4xx | 400 - 499 | 客户端错误，请求无效或无法在该服务器上完成。 | 401 Unauthorized（鉴权挑战），486 Busy Here（被叫忙）。 | |
| 5xx | 500 - 599 | 服务器错误，服务器无法完成有效请求。 | 503 Service Unavailable（服务器临时过载）。 | |
| 6xx | 600 - 699 | 全局错误，请求在任何服务器上都无法完成。 | 600 Busy Everywhere（所有终端都忙）。 |
3.2 消息体：SDP 的承载
SIP 消息的消息体是可选的，用于承载会话相关的净荷信息。消息体类型由 Content-Type 头域指定。
在 IMS 网络中，消息体最主要的作用是承载 SDP (Session Description Protocol，会话描述协议)。
- 目的：SDP 用于描述多媒体会话的属性（如媒体类型、编解码器、传输地址和端口）。
- 机制：SIP 承载 SDP，实现了 提议/应答 (Offer/Answer) 模型。
- 提议 (Offer)：由一方发出（通常在
INVITE或UPDATE请求中），描述其支持的媒体能力和接收地址。 - 应答 (Answer)：由另一方回复（通常在
183 Session Progress或200 OK响应中），确定双方都支持的媒体参数和其接收地址。
- 提议 (Offer)：由一方发出（通常在
通过 SDP 协商，通信双方就媒体流的参数达成一致，RTP（实时传输协议）媒体流随后才能建立。
4. URI 格式：IMS 寻址与号码规则
IMS 路由和寻址的核心基于 URI (Uniform Resource Identifier)。SIP 协议要求 IMS 网元能够处理多种 URI 格式。
| URI 类型 | 格式/示例 | 核心用途 | IMS 路由机制要求 | 来源 |
|---|---|---|---|---|
| SIP URI | sip:user@host | 标识用户或网络实体；IMS 域内路由的基础。 | 必须支持。E.164 号码需转换为 SIP URI 进行路由。 | |
| SIPS URI | sips:user@host | 与 SIP URI 相同，但强制要求采用安全的传输机制 (如 TLS)。 | 任何支持 TLS 的 IMS 实现都必须支持 SIPS URI。 | |
| TEL URI | tel:+861012345678 | 基于 E.164 编码格式的电话号码表示，遵循 RFC 3966。 | 用于拨叫 E.164 号码，在 S-CSCF 或 I-CSCF 需要查询 ENUM/DNS 转换为 SIP URI。 | |
| URN | urn:service:sos | 统一资源名称，用于标识服务而非特定地址。 | 紧急呼叫场景下使用（如 sos、police），由 E-CSCF 处理。 |
运营商的号码规则与路由转换
在运营商网络中，SIP 路由对 URI 格式有严格要求：
- E.164 转换：E.164 格式的公共用户标识（PUI）不用于 IMS 直接路由，必须先转换成 SIP URI 格式。S-CSCF/I-CSCF 会通过查询 ENUM/DNS 服务将 TEL URI 转换为 SIP URI。
- 号码携带：如果主叫用户拨叫的被叫号码仅为 E.164 号码，终端（UA）发往网络的被叫号码形式可以是 TEL URI 格式，或者 SIP URI 格式（其中
userinfo部分是 E.164 号码，host部分是归属域名，并包含user=phone参数）。user=phone参数：在 SIP URI 中，携带user=phone参数可以明确指示 URI 的用户部分是一个电话用户。
5. SIP 核心方法集：IMS 中的信令指令
SIP 方法（Method）定义了请求要执行的操作。在 IMS 核心网中，以下方法最为关键：
5.1 注册与定位方法
| 方法名 | 核心功能 | IMS 场景应用 | 关联关键头域 | 来源 |
|---|---|---|---|---|
| REGISTER | 用户注册和注销。 | 绑定用户逻辑身份（AOR/IMPU）与物理可达地址（Contact URI）。 | To/From (AOR), Contact (绑定地址), Expires (注册有效期), Path / Service-Route。 |
5.2 会话建立与终止方法
| 方法名 | 核心功能 | IMS 场景应用 | 事务特性 | 来源 |
|---|---|---|---|---|
| INVITE | 发起或修改会话。 | VoLTE/VoNR 呼叫的起始；携带 SDP Offer。 | INVITE 事务，必须通过 ACK 确认 2xx 最终响应（三次握手）。 | |
| ACK | 对 INVITE 最终响应的确认。 | 确保会话建立的可靠性，完成 INVITE 事务的最后一步。 | 不属于 INVITE 事务本身，但用于确认 INVITE 最终响应。 | |
| BYE | 终止一个已建立的会话。 | 通话中任一方挂机后释放会话资源。 | 非 INVITE 事务，无须 ACK 确认。必须在对话内发送。 | |
| CANCEL | 取消一个未决的请求。 | 主叫在被叫振铃阶段（未收到 2xx）挂断时使用。 | 独立事务，逐跳传输。 |
注意：BYE 与 CANCEL 的区别
- BYE：用于终止已建立的对话（已收到 2xx 响应）。
- CANCEL：用于取消未完成的事务（例如，正在发送
180 Ringing临时响应时）。
5.3 会话控制与增强方法
| 方法名 | 核心功能 | IMS 场景应用 | 关联机制/要求 | 来源 |
|---|---|---|---|---|
| PRACK | 可靠地确认临时响应 (1xx)。 | 配合 Require: 100rel 标签，用于可靠地传输振铃信息或 SDP Offer/Answer。 | 必须包含 Rseq（响应序列号）头域。 | |
| UPDATE | 会话属性修改和会话刷新。 | 1. 资源预留（Precondition 机制）。2. 会话定时器的心跳刷新。 | 通常用于会话内，可不携带 SDP 消息体（刷新时）。 | |
| OPTIONS | 查询对端能力；链路心跳。 | IMS 网元之间周期性发送，探测对端网元是否故障。 | 如果 Max-Forwards=0，服务器可响应，作为链路检测。 |
6. 信令日志实战分析：请求与响应的生命周期
我们将以一个简化的 IMS 呼叫建立事务为例，分析请求行、状态行和核心方法集如何协同工作，完成一次 SIP 事务的生命周期。
场景： 主叫 UE 发起 INVITE 请求，经过 S-CSCF，最终被被叫 UAS 接受。
6.1 INVITE 请求（UAC → UAS）
UE 发起的 INVITE 消息是 请求行 的典型代表。
| 消息行/头域 | 示例值 | 关键作用分析 | 来源 |
|---|---|---|---|
| 请求行 | INVITE sip:[email protected] SIP/2.0 | 方法：INVITE，目标是建立会话。Request-URI：指示请求的初始目标。 | |
| Via | SIP/2.0/UDP 6.6.6.6:5060;branch=z9hG4bK... | 记录 UE 的地址，并生成 branch 参数（标识事务）。 | |
| From | <sip:[email protected]>;tag=a48s | 逻辑发起方，tag 参数是对话标识的一半。 | |
| To | <sip:[email protected]> | 逻辑接收方，不带 tag（请求在对话外）。 | |
| CSeq | 1 INVITE | 序列号（1）和方法（INVITE），用于事务和消息排序。 | |
| Content-Type | application/sdp | 指示消息体为 SDP，承载 Offer。 |
6.2 183 临时响应（UAS → UAC）
被叫方 UAS 收到 INVITE 后，在振铃前返回 183 响应，是 状态行 和 可靠临时响应 的体现。
| 消息行/头域 | 示例值 | 关键作用分析 | 来源 |
|---|---|---|---|
| 状态行 | SIP/2.0 183 Session Progress | 状态码 183：会话正在进展中。 | |
| To | <sip:[email protected]>;tag=b77t | UAS 在响应中添加 tag。Call-ID + From-tag + To-tag 共同建立早期对话（Early Dialog）。 | |
| RSeq | 1 | 响应序列号，配合 100rel（可靠临时响应）使用。 | |
| Contact | <sip:[email protected]> | 被叫的实际可达地址。 |
6.3 200 OK 最终响应与 ACK 确认
当被叫摘机后，UAS 发送 200 OK 响应，标志着呼叫成功，并建立最终对话（Confirmed Dialog）。
-
200 OK（INVITE）：
- 状态行：
SIP/2.0 200 OK，呼叫成功。 - To Tag：沿用 183 响应中添加的 tag，确保对话一致性。
- SDP：携带 SDP Answer，完成媒体协商。
- 会话定时器：通常会包含
Session-Expires和refresher参数，用于协商会话续期机制。
- 状态行：
-
ACK（UAC → UAS）：
- 方法：
ACK，完成 INVITE 事务的可靠握手。 - CSeq：序号必须与对应的 INVITE 请求一致。
- 路由：ACK 需遵循 INVITE 响应中 Record-Route 建立的路由集。
- 方法：
7. 本章小结
SIP 协议通过 UAC/UAS 的角色动态转换，以及结构化的起始行、头域和消息体，实现了高效的会话控制。IMS 网络严格依赖 SIP 协议定义的方法（如 INVITE, REGISTER, BYE）来控制会话生命周期，并使用 TEL URI/SIP URI 进行地址寻址和路由转换。尤其需要注意 B2BUA 在 AS/SBC 等网元中的应用，它是实现业务逻辑和拓扑隐藏的关键机制。
工程师进阶思考 (FAQ)
Q1：为什么 IMS 网络要求将 E.164 格式的 PUI 转换成 SIP URI 格式进行路由？
A1： IMS 网络是基于 IP 的多媒体系统，其核心路由机制（如 DNS/ENUM 查询和 Route/Record-Route 处理）是为 SIP URI 设计的。SIP URI 格式 (sip:user@host) 具有明确的域名 (host) 部分，这使得 SIP 代理（如 I-CSCF 和 S-CSCF）可以方便地使用标准的 DNS 协议查询下一跳的 IP 地址或全称域名 (FQDN)。如果直接使用 TEL URI，IMS 网元必须首先将其转换为 SIP URI 或通过其他机制确定归属域，才能进行高效的跨域路由和 S-CSCF 寻址。
Q2：INVITE 事务的 ACK 消息和 BYE 事务的 200 OK 响应，哪个属于 SIP 事务的一部分？
A2： 根据 RFC 3261 对事务的定义：
- BYE 事务：BYE 请求和其最终响应（
200 OK）构成一个完整的非 INVITE 事务（Regular Transaction）。 - INVITE 事务：如果 INVITE 的最终响应是非 2xx 失败响应（如 4xx, 5xx, 6xx），则 ACK 属于该事务的一部分。但是，如果 INVITE 的最终响应是 2xx 成功响应（如
200 OK），则用于确认 2xx 的 ACK 请求被视为一个独立的事务，不属于 INVITE 事务本身。
Q3：在 IMS 注册流程中，REGISTER 消息的 Request-URI、From 头域和 Contact 头域各扮演什么角色？
A3： 这三个字段在 REGISTER 流程中分工明确：
- Request-URI：指示请求的目标服务器，即归属网络的域名（例如
sip:ims.home.com），URI 中不能包含用户部分和 ”@“。P-CSCF 会根据这个域名查询 I-CSCF 地址。 - From/To：都填写要注册的公共用户标识（AOR/IMPU）。它们代表用户的逻辑身份，是注册的主体。
- Contact：填写 UE 当前的物理可达地址（如 IP 地址和端口），并包含
expires参数。注册的本质就是将 From/To 定义的逻辑身份与 Contact 定义的物理地址进行绑定。
请您发出“请继续”指令，我将开始撰写第三篇。