SIP 协议详解

会话发起协议（Session Initiation Protocol）· 依据 RFC 3261（SIP: Session Initiation Protocol，STD 67，2002 年 6 月）编写，并参考 RFC 3263（定位）、RFC 3264（offer/answer）、RFC 2617（HTTP Digest）、RFC 2327/4566（SDP）
RFC 3261 · SIP（STD 67）应用层信令协议文本协议 · UTF-8端口 5060 / 5061UDP·TCP·TLS·SCTP六标准方法

1.概述：SIP 是什么

SIP（Session Initiation Protocol，会话发起协议）是应用层的控制（信令）协议，用于创建、修改和终止与一个或多个参与者的会话（session）。这里的「会话」包括互联网电话呼叫、多媒体分发、多媒体会议。它不传输媒体本身——音视频走 RTP，SIP 只负责「谁来、在哪、怎么协商」。RFC 3261 第 1 章明确：SIP 是文本协议，使用 UTF-8 字符集，消息语法大量借鉴 HTTP/1.1，但SIP 不是 HTTP 的扩展。

1.1 设计要素（RFC 3261 §1）

RFC 3261 列出 SIP 的设计目标，理解这些目标才能理解它为什么长这样：

1.2 与 HTTP / SMTP 的异同

维度HTTP/1.1SIP/2.0
角色浏览器=客户端，服务器=服务器UA = UAC + UAS，二者可互换角色
承载TCP 为主UDP / TCP / TLS / SCTP 皆可
版本HTTP/1.0、HTTP/1.1 可比较固定 SIP/2.0，按字面比
消息边界支持 chunked禁用 chunked，靠 Content-Length

1.3 协议的分层结构（RFC 3261 §5）

SIP 自底向上分四层，理解分层是理解「为什么某些头必须由事务层加、某些由传输层填」的关键：

① 语法 / 编码层（Syntax & Encoding）—— 定义消息格式、ABNF、UTF-8 ② 事务层（Transaction Layer）—— 客户端 / 服务端事务，负贵重传、匹配响应、ACK（SIP 可靠性的核心，第 9 节） ③ 传输层（Transport Layer）—— 把消息发到下一跳（UDP/TCP/TLS/SCTP），填 Via 的 sent-by、maddr ④ 事务用户层（Transaction User, TU）—— UA 核心或状态代理核心，决定「收到响应后干什么」
一句话定位：SIP 处在 OSI L5 会话层 / L7 应用层（见 协议纵览 L5/L7）。它做「会话的建立、修改、终结」，媒体本身由 RTP/SRTP 承载，二者通过 SDP 在 SIP 消息体里协商。

2.协议构件：网络中的 SIP 实体

RFC 3261 §6 定义了五类逻辑实体。它们都是逻辑角色，一个物理设备（比如一台软交换）可以同时是代理、注册、重定向服务器和定位服务——实现上可合并，逻辑上要分清。

实体RFC 章职责
UA（用户代理）§8会话的两端终点：UAC 发请求，UAS 回响应
Proxy（代理）§16路由转发：确定下一跳、应用策略、认证
Redirect（重定向）§8.3 / §21.3返回 3xx，告知客户端去哪找被叫
Registrar（注册）§10处理 REGISTER，维护 AOR↔Contact 绑定
Location（定位服务）§10 / §16.5AOR → Contact 绑定的数据存储，被代理查询
典型呼叫路径（SIP 梯形 / trapezoid）：主叫 UA → 出局代理 → （可能多个）代理 → 入局代理 → 被叫 UA。代理之间逐跳转发，每一跳都是一对客户端/服务端事务（见 §9.1 Figure 4）。

3.重要术语与定义（RFC 3261 §3 / §6）

术语含义
AOR（地址-of-记录）用户的逻辑公开地址（sip:user@domain），与设备解耦
Contact（联系地址）UA 当前实际可达 URI，AOR 与设备的桥梁
Transaction（事务）请求 + 其全部响应；可靠性的基本单位
Dialog（对话）两个 UA 的端到端持续关系；含 dialog ID / 路由集
Call（呼叫）业务层概念，可含多条 Dialog
TU（事务用户）驱动事务的上一层逻辑（UA 核心 / 有状态代理）
悬停行查看术语详解 · 单击钉住
Transaction ≠ Dialog（最容易混的两个概念）：Transaction 是单条请求的可靠性单位（一个 INVITE 事务 = 一个 INVITE + 它的响应 + 可能的 ACK）；Dialog 是呼叫持续期间两端的关系（跨多个事务）。一个 Dialog 的建立通常由「一个 INVITE 事务成功（2xx）」触发，但 Dialog 存续期间还会产生 BYE、re-INVITE 等多个事务。

4.SIP 消息结构（RFC 3261 §7）

SIP 消息要么是客户端到服务器的请求，要么是服务器到客户端的响应。两者都由起始行 + 若干头字段 + 空行 + 可选消息体组成。起始行、每个头字段行、空行都必须以 CRLF 结尾；即使没有消息体，空行也必须存在。

generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line

4.1 请求行（Request-Line，§7.1）

请求以请求行开头，格式：Method SP Request-URI SP SIP-Version CRLF。元素间只允许单个 SP，不得有 LWS，不得有额外 CR/LF。

INVITE sip:bob@biloxi.com SIP/2.0 ; Method ∈ {INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS, …} ; SIP-Version 必须是字面 "SIP/2.0"（大小写不敏感，但发送必须大写） ; Request-URI 是被叫地址（SIP/SIPS URI 或 tel URI），不能含未转义空格、不能加 <>

4.2 状态行（Status-Line，§7.2）

响应以状态行开头：SIP-Version SP Status-Code SP Reason-Phrase CRLF。Status-Code 是 3 位整数，首位决定类别；Reason-Phrase 给人看，客户端可忽略。

SIP/2.0 200 OK ; 1xx 临时 / 2xx 成功 / 3xx 重定向 / 4xx 客户端错 / 5xx 服务端错 / 6xx 全局失败

4.3 头字段（§7.3）

头字段格式 field-name: field-value，多个同名头可合并为逗号分隔列表（例外：WWW-Authenticate / Authorization / Proxy-Authenticate / Proxy-Authorization 不能合并，且可多次出现）。头字段可多行折叠（续行以 SP/HT 开头）。头名字大小写不敏感；除非定义另有说明，field-value、参数名、参数值大小写不敏感，但引号字符串大小写敏感。

4.4 消息体（§7.4）与分帧（§7.5）

4.5 六（七）个必须出现的头字段（§8.1.1）

除 Content-Length 外，下列头字段几乎出现在每条请求里。悬停下表查看每个头的作用与取值规则：

头字段由谁加是否必须作用
Via每跳（UAC + 各代理）请求必须 m记录路径、匹配事务、指引响应返回
Max-ForwardsUAC请求必须 m限制跳数防环；默认 70
FromUAC请求必须 m发起者身份；携带 From-tag（dialog ID 的一部分）
ToUAC 写值，UAS 加 tag请求必须 m被叫身份；响应里加 To-tag（dialog ID 一部分）
Call-IDUAC请求必须 m关联一组消息；dialog ID 组件之一；大小写敏感
CSeqUAC请求必须 m事务序号与方法；dialog 内必须 +1 递增
ContactUAC（INVITE/REGISTER）INVITE 请求必须 m；REGISTER 必须 o本实例联系地址；INVITE 必含且唯一
悬停行查看头字段详解 · 单击钉住

5.请求方法（RFC 3261 §7.1 / §8–§15）

RFC 3261 定义了六个方法；扩展方法由标准 Track RFC 另行定义（见 §17）。下面是六个标准方法的语义与关键点：

方法用途关键语义（照 RFC 3261）
INVITE建立 / 修改会话带 SDP offer；唯一建 dialog 的请求；三次握手事务
ACK确认 INVITE 响应只配 INVITE；2xx 的 ACK 端到端、非 2xx 的属事务
BYE终止会话dialog 内；终结呼叫
CANCEL取消未决请求同 branch 标识原事务；配 487 终结原请求
REGISTER地址绑定（注册）To=AOR；Contact=当前地址；写定位服务
OPTIONS查询能力 / 保活探测对端能力；200 OK 带 Allow
六个方法之外：RFC 3261 明确「SIP 扩展（标准 Track RFC）可定义额外方法」。常见的有 INFO（RFC 2976，mid-call 信息）、REFER（RFC 3515，转接）、UPDATE（RFC 3311，早期修改会话、不建 dialog）、SUBSCRIBE/NOTIFY（RFC 6665，事件订阅）、MESSAGE（RFC 3428，即时消息）、PRACK（RFC 3262，对 1xx 的可靠确认）。详见 §17。

6.响应状态码（RFC 3261 §7.2 / §21）

状态码首位决定类别，后两位不参与分类。SIP/2.0 允许首位取值 1–6。

类别含义常见码（RFC 3261 §21 全列）
1xx 临时处理中100 / 180 / 181 / 182 / 183
2xx 成功成功200 OK
3xx 重定向重定向300 / 301 / 302 / 305 / 380
4xx 客户端错请求有误400/401/403/404/405/406/407/408/413/414/415/420/421/423/480/481/482/483/484/485/486/487/488/491/493
5xx 服务端错服务器失败500 / 501 / 502 / 503 / 504 / 505 / 513
6xx 全局失败全局不可达600 / 603 / 604 / 606
401 vs 407：401 Unauthorized 配 WWW-Authenticate，是用户-用户认证（被叫 UAS 挑战主叫）；407 Proxy Authentication Required 配 Proxy-Authenticate，是代理-用户认证（代理挑战用户）。二者认证机制都用 HTTP Digest（§22）。

7.头部字段详解（RFC 3261 §20）

§20 逐一定义头字段，「where」列说明它可出现在请求 (R) / 响应 (r) / 特定状态码后，「proxy」列说明代理可加(a)/改(m)/删(d)/必须可读(r)。下表浓缩自 §20 的 Table 2/3，给出每个头在六种方法（ACK/BYE/CAN/INV/OPT/REG）中的出现要求（m 必须 / o 可选 / c 从请求复制 / t 流式传输必须 / * 有消息体时必须 / - 不适用）：

头字段whereproxy六方法要求用途
Accept(-Encoding/-Language)R / 2xx / 415—INV:o / OPT:m* / 415:c能力/编码/语言协商
Alert-InfoR / 180arINV:o；180:ar替代振铃音
AllowR / r / 405—INV:o / OPT:m* / 405:m支持的方法清单
Authentication-Info2xx—INV/OPT/REG:oDigest 双向认证
AuthorizationR—各方法:o用户认证凭据
Call-ID（i）cr全部:m消息组关联；dialog ID 组件
Call-InfoR / 180arINV/OPT:o主被叫附加信息
Contact（m）R / 1xx / 2xx / 3xx—INV:m / 2xx:m / 3xx:o / REG:o联系地址；绑定/重定向
Content-*（c/e/l）—（l 为 ar）有体:t/*；流式:l 必须消息体元信息
CSeqcr全部:m事务排序/标识
Date—a各:o时间戳
Error-Info300–699a各:o错误附加信息
Expires——INV:o / REG:o过期时间
From（f）cr全部:m发起者；dialog ID 组件
In-Reply-To/Reply-To/SubjectR—INV:o呼叫关联/主题
Max-ForwardsRamr全部:m防环跳数
Min-Expires423—REG(423):m注册最小有效期
MIME-Version——各:oMIME 版本
Organization—ar各:o组织名
PriorityRarINV:o优先级
Proxy-Authenticate/-Authorization407 / 401 / Rar / drINV/OPT/REG:o(m@407)代理认证
Proxy-RequireRar各:o强制代理支持选项
Record-Route（r）/ Route（o）R / 2xx,18x / Rar / adrINV/OPT:o；REG:-路径记录/路由集
Require—arINV/OPT:c强制 UAS 支持选项
Retry-After404,413,480,486,500,503,600,603—各:o重试建议
Serverr—各:o服务器标识
Supported（k）/ UnsupportedR / 2xx / 420—INV/OPT/REG:o(m*@2xx)支持/不支持选项
Timestamp——各:o时延测量
To（t）c(1)r全部:m被叫；dialog ID 组件（远端 tag）
User-Agent——各:oUA 标识
Via（v）R / rcamr / dr全部:m路径/事务匹配/响应返回
Warningr—各:o警告信息
WWW-Authenticate401 / 407arINV/OPT/REG:m(@401)用户认证挑战
悬停行查看头字段详解 · 单击钉住（浓缩自 RFC 3261 §20 Table 2/3）

7.1 紧凑形式（Compact Form，§20.3）

当消息因 UDP MTU 限制可能过大时，可用缩写头名（语义不变，长/短形式可混用，实现必须都接受）：

缩写全称缩写全称
aAccept-Contact*lContent-Length
cContent-TypemContact
eContent-EncodingsSubject
fFromtTo
iCall-IDvVia
kSupporteduAllow-Events*
oEvent** 非 RFC 3261 定义，由后续扩展（如 RFC 3840/6665）引入
RFC 3261 明确规定的紧凑头：i=Call-ID、m=Contact、e=Content-Encoding、l=Content-Length、c=Content-Type、f=From、s=Subject、t=To、v=Via。其余（a/k/o/u 等）来自后续扩展 RFC。

8.SIP / SIPS URI 与寻址（RFC 3261 §19）

SIP 与 SIPS URI 标识一个通信资源，可印在网页/名片/邮件里，含足以发起并维持会话的信息。SIPS 表示「安全联系该资源」——UAC 到该 URI 所属域之间必须用 TLS，之后由域策略决定域内安全机制。

8.1 一般形式（§19.1.1）

sip:user:password@host:port;uri-parameters?headers sips:user:password@host:port;uri-parameters?headers （scheme 改为 sips）
组件含义与规则
user资源标识；可含 telephone-subscriber（建议 user=phone）
password语法允许但强烈不推荐（明文风险）
host目标主机（FQDN 或 IP）；推荐 FQDN
port缺省 5060（sip）/ 5061（sips 或 TLS）
;uri-parameterstransport/maddr/ttl/user/method/lr 等
?headers在 URI 里内联请求头（& 分隔）

8.2 示例（§19.1.3）与比较（§19.1.4）

sip:alice@atlanta.com sip:alice:secretword@atlanta.com;transport=tcp sips:alice@atlanta.com?subject=project%20x&priority=urgent sip:+1-212-555-1212:1234@gateway.com;user=phone sip:alice@192.0.2.4 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
URI 比较规则（§19.1.4）：SIP 与 SIPS URI 永远不等价（即使 user/host/port 全同）。同 scheme 比较忽略 user 大小写、主机大小写、% 转义形式、URI 参数顺序、显式缺省端口；但 user/password/host/port 的具体值、各参数值等都参与比较。这直接影响注册时 Contact 绑定的去重（§10.3）。

9.事务层与状态机（RFC 3261 §17）

事务（transaction）= 一个请求 + 对其的所有响应（0+ 临时响应、≥1 最终响应）。它有客户端侧（发请求、收响应）与服务端侧（收请求、发响应），分别嵌入 UA 或有状态代理里。事务层是 SIP 可靠性的核心：在 UDP 上自实现重传、匹配、ACK。

为什么 INVITE 的 ACK 特殊（§17 开头）：为了把所有 200 OK 都送到 UAC，UAS 独自负责重传 2xx，UAC 独自负责端到端 ACK——所以对 2xx 的 ACK 不算事务的一部分（由 UA 核心处理，每个代理只转发）；仅当最终响应非 2xx 时，ACK 才由事务层生成、属该事务。这就是 INVITE 事务要三次握手、非 INVITE 只需两次握手的根本原因。

9.1 INVITE 客户端事务（Figure 5）

Calling Proceeding Completed Terminated 1xx 300–699 +ACK Timer D 2xx→TU / Timer B / 传输出错 Timer A: UDP 重传, 起 T1 后翻倍 Timer D: 32s(UDP)/0(可靠) 初态; INVITE 发出

9.2 非 INVITE 客户端事务（Figure 6）

Trying Proceeding Completed Terminated 1xx 200–699 Timer K Timer F / 传输出错 Timer E: 重传, T1→min(2T1,T2) 封顶 T2 Timer K: T4(UDP)/0(可靠) 初态; 请求发出

9.3 INVITE 服务端事务（Figure 7）

Proceeding Completed Confirmed Terminated 300–699 ACK Timer I 2xx（重传由 TU 负责）/ Timer H 100 Trying 默认发(除非 TU 200ms 内回) Timer G: 响应重传 T1→T2 · Timer H=64T1 Timer I: T4(UDP)/0(可靠) · 吸收重传 ACK

9.4 非 INVITE 服务端事务（Figure 8）

Trying Proceeding Completed Terminated 临时响应 最终响应 Timer J 初态; 请求上送 TU; 重传丢弃 Timer J: 64T1(UDP)/0(可靠) · 按请求重传重发响应

9.5 定时器（§17，全部以 T1 为基准缩放）

定时器取值作用对象 / 含义
T1500 ms（默认）RTT 估计；事务重传/超时的基准
T24 s（默认）非 INVITE 重传间隔封顶
T45 s（默认）网络清消息时间；K/I 定时器基准
AT1 → 翻倍INVITE 请求重传（UDP）
B64×T1INVITE 客户端事务超时
D32s(UDP) / 0(可靠)INVITE 客户端吸收响应重传
ET1 → min(2T1,T2)非 INVITE 请求重传（UDP）
F64×T1非 INVITE 客户端事务超时
GT1 → min(2T1,T2)INVITE 服务端重发最终响应（UDP）
H64×T1INVITE 服务端等 ACK 超时
IT4(UDP) / 0(可靠)INVITE 服务端吸收多余 ACK
J64×T1(UDP) / 0(可靠)非 INVITE 服务端吸收请求重传
KT4(UDP) / 0(可靠)非 INVITE 客户端吸收响应重传

9.6 事务匹配规则（§17.1.3 / §17.2.3）

10.传输层（RFC 3261 §18）

传输层负责把消息送到下一跳。SIP 刻意支持多种传输，可靠性职责因传输而异：

传输行为可靠性职责
UDP每数据报一条消息；事务层重传；建议 ≤1300B不可靠；事务层补
TCP流式；Content-Length 分帧；忽略前导 CRLF可靠；事务层不重传
TLSsips 加密通道；端口 5061可靠+加密
SCTP面向消息；可靠；无需分帧可靠
可靠性分工一句话：UDP 上 SIP 自己在事务层用指数退避重传补可靠性（T1 翻倍到 T2/T4）；TCP/TLS/SCTP 把可靠性外包给传输层，事务层不重传。这与 BGP（整体外包 TCP）和 OSPF（自己在裸 IP 上造可靠性）的对比参见 BGP 页 / OSPF 页。

10.1 发送与错误（§18.1 / §18.4）

11.注册机制（RFC 3261 §10）

REGISTER 把AOR（To 头）绑定到当前 Contact，写入定位服务，供代理查询「这个用户现在在哪」。Request-URI 是注册服务器地址（不是被叫），From = 注册者。

11.1 注册器处理流程（§10.3，七步）

1. 检查 Request-URI：确认本服务器负责该域的注册 2. 检查 Supported：若要求本服务器不支持的选项 → 420 3. 认证 UAC（§22，通常 Digest） 4. 授权：确认已认证用户有权改该 AOR 的绑定 5. 从 To 头提取 AOR 6. 检查 Contact：为空 → 获取绑定列表；为 * 且无 Expires → 删除全部；否则按 Expires 处理每个绑定 7. 返回 200 OK（带更新后的 Contact 列表，含各绑定过期值）

11.2 绑定操作与 Expires（§10.2）

操作做法说明
添加 / 刷新Contact: <sip:...>;expires=N绑定 AOR↔Contact；到期需刷新
移除Contact: * 配合 Expires: 0注销全部 / 单条
获取无 Contact 的 REGISTER查询当前绑定
优先级Contact: <sip:...>;q=0.7多绑定分叉顺序
注册 ≠ 呼叫：REGISTER 只更新「地址↔位置」映射，不改变任何 dialog。一个 AOR 可同时绑多个 Contact（手机+软终端），来电时代理向所有 Contact 分叉（fork） INVITE，谁先 2xx 谁接，其余 CANCEL。

12.Dialog（RFC 3261 §12）

Dialog 是两个 UA 之间的端到端对等关系，仅由 INVITE 的 2xx 或 101–199（带 To tag）响应建立。它保存对话期内的路由集、序号、对端地址等状态。

12.1 dialog ID 与 tag（§12.1）

dialog ID = Call-ID + 本地 tag(local tag) + 远端 tag(remote tag) 本地 tag / 远端 tag 的分配： UAC：From-tag = 本地 tag；To（无 tag，dialog 外）→ 响应里 To-tag = 远端 tag UAS：To-tag = 本地 tag；From-tag（请求里）= 远端 tag ⇒ UAC 的 dialog ID = Call-ID + From-tag + To-tag(响应) UAS 的 dialog ID = Call-ID + To-tag + From-tag

12.2 路由集与 in-dialog 请求（§12.1 / §12.2）

环节route set 来源与顺序
UAC 收到 2xxRoute set = 响应 Record-Route 逆序
UAS 发 2xxRoute set = 请求 Record-Route 顺序
dialog 内发请求复用 route set；CSeq 必须 +1

12.3 终止（§12.3 / §15）

任一方发 BYE（dialog 内请求，CSeq 递增）即终止 dialog；收到 BYE 的 UAS 回 200 OK 后 dialog 拆除。也可靠失败响应（如 408/481/503）或事务失败隐式终止。

13.会话建立端到端示例（RFC 3261 §4 / §13 / §24）

下面是经典 SIP 梯形：主叫 Alice（atlanta.com）经出局/入局代理呼叫被叫 Bob（biloxi.com）。INVITE 带 SDP offer，200 OK 带 SDP answer，最后 ACK 确认。这正对应 RFC 3261 Figure 1 的消息流（此处简化为关键步骤）。

Alice UAC Proxy 1 Proxy 2 Bob UAS 1 INVITE (SDP offer) + Via(P1,P2) 2 100 Trying（逐跳） 3 180 Ringing 4 200 OK (SDP answer, To-tag) 5 ACK（端到端，经 Record-Route） RTP 媒体流（SDP 协商的地址/端口） Alice Bob

13.1 SDP offer / answer（§24，RFC 3264）

INVITE 消息体是 SDP offer（列出本端想用的媒体：音频/视频、编解码、地址、端口）；200 OK 消息体是 answer（从 offer 中选兼容项）。规则（RFC 3264 §6）：

offer/answer 与 re-INVITE：通话中想改媒体（如加视频、hold），不需 BYE 重建，而是发 re-INVITE（同 dialog 内，CSeq+1，是新事务但非新 dialog），携带新 SDP 重新 offer/answer（§14）。

14.代理行为与请求转发（RFC 3261 §16）

代理是 SIP 网络的路由核心。按是否保存状态分两类：

类型特点
有状态（Stateful）保存事务/dialog 状态；可认证、CANCEL、响应合并
无状态（Stateless）不保存状态；高吞吐；不能认证/CANCEL

14.1 有状态代理处理流程（§16.3–§16.7）

① 验证请求(§16.3)：合理语法 · URI scheme 支持 · Max-Forwards>0 · Proxy-Require 的选项都支持 · Proxy-Authorization 合规 ② 预处理路由(§16.4)：有 Route 头则 Request-URI 保持（走 Route 栈）；无 Route 则 Request-URI 即目标 ③ 确定目标(§16.5)：查定位服务得到 Contact 列表（可能多个 → 分叉 forking） ④ 转发每目标(§16.6)：复制请求 → Max-Forwards-1 → 可选加 Record-Route → 栈顶压入本代理 Via(新 branch) → 改 Request-URI 为下一跳 → 设 Timer C ⑤ 响应处理(§16.7)：删顶层 Via → 选最佳最终响应 → 转发上游

14.2 Record-Route 与 Route（宽松路由，§16.6 / §19.1.1）

Via 栈 vs Route 栈：Via 是响应回家的路（每跳压一个，响应时从栈顶逐个剥掉往回走）；Route 是后续请求去的路（dialog 内请求用，由 Record-Route 形成）。两者方向相反、目的不同，别混。

15.重定向与 CANCEL（RFC 3261 §8.3 / §9 / §21.3）

15.1 重定向服务器（§8.3）

重定向服务器不转发请求，而是回 3xx 响应，把「被叫当前地址」放在 Contact 里交给客户端，由客户端自己重新发请求到新地址。它是无状态的，不发起自己的事务。常见 3xx：

码含义用法
300多选Contact 给多个候选
301永久迁移更新地址缓存
302临时迁移本次用新 Contact 重发
305用代理经 Contact 代理
380替代服务Contact 给替代

15.2 CANCEL（§9）

CANCEL 取消一个仍在处理中的请求（典型：INVITE 已发但还没最终响应，主叫挂断）。关键点：

CANCEL 不能取消已完成的事务：若原请求已收到最终响应（事务已结束），CANCEL 找不到匹配事务，会被忽略——此时要终止会话得用 BYE，而不是 CANCEL。

16.认证与安全（RFC 3261 §22 / §23 / §26）

16.1 HTTP Digest 认证（§22）

SIP 复用 HTTP 认证框架（RFC 2617），两种场景：

场景挑战头流程
用户-用户401 + WWW-AuthenticateUAS 挑战；UAC 回 Authorization
代理-用户407 + Proxy-Authenticate代理挑战；UAC 回 Proxy-Authorization
response = H( H(A1) : nonce : nc : cnonce : qop : H(A2) ) // qop=auth 时 A1 = username : realm : password A2 = method : uri 401/407 响应本身不携带凭据缓存；nonce 防重放

16.2 S/MIME 端到端安全（§23）

16.3 TLS / SIPS（逐跳加密）

sips: URI 要求 UAC 到域边缘用 TLS，端口 5061；之后由域策略决定（可能仍走 TLS 或内部安全通道）。TLS 防窃听/中间人，但不解决「域内部是否可信」——它与 S/MIME 的端到端保护互补。

16.4 威胁模型与建议（§26）

威胁（§26.1）说明与对策
注册劫持认证注册；仅拥有者可改绑定
冒充服务器TLS/S/MIME/DNSSEC
篡改消息体S/MIME 保护 SDP
会话拆除dialog 内请求需正确 tag + 认证
DoS / 放大限重传/限速率/Max-Forwards
安全三件套：sips/TLS（逐跳加密）+ Digest 认证（身份）+ S/MIME（端到端签名/加密）。生产环境建议三者叠加——只做其一都留明显缺口（如仅 Digest 不防窃听，仅 TLS 不防域内部篡改）。

17.扩展方法（标准 Track RFC 定义）

RFC 3261 只定义六个方法，但明确允许扩展 RFC 增加新方法。以下是工程中常见、且已在标准 Track 落地的扩展方法：

方法RFC用途
INFORFC 2976通话中信息（DTMF 等）
REFERRFC 3515呼叫转接
UPDATERFC 3311早期修改会话（不建 dialog）
SUBSCRIBE / NOTIFYRFC 6665事件订阅/通知
MESSAGERFC 3428即时消息
PRACKRFC 3262可靠临时响应确认
扩展的「能力协商」：新方法/选项通过 Supported / Require / Proxy-Require 协商：要求对端必须支持用 Require（不支持回 420）；仅声明自己支持用 Supported。这正是 RFC 3261 §1「可扩展性」设计目标的落地机制。

18.示例报文（依据 RFC 3261 §24）

18.1 INVITE 与 200 OK（带 SDP）

INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 v=0 o=alice 2890844526 2890844526 IN IP4 pc33.atlanta.com s=- c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 8 97
SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844730 2890844730 IN IP4 192.0.2.4 s=- c=IN IP4 192.0.2.4 t=0 0 m=audio 3456 RTP/AVP 0 8 97
读报要点：注意 INVITE 的 To 无 tag（dialog 外），200 OK 的 To 带了 tag=a6c85cf（UAS 加）；Via 的 branch 以 z9hG4bK 开头；Call-ID/CSeq 两端一致；Contact 告诉对方后续请求发哪。ACK 随后由 Alice 端到端发出（branch 复用、方法改 ACK）。

18.2 REGISTER

REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 3600 Content-Length: 0

注意 REGISTER 的 Request-URI 是注册服务器（registrar.biloxi.com），而非被叫；To = AOR（bob@biloxi.com），Contact = 当前实际地址（192.0.2.4），Expires=3600 秒后绑定过期需刷新。

19.术语速查与文献

19.1 一页速查

概念一句话
端口sip: 5060（UDP/TCP/SCTP）；sips: / TLS 5061
版本字面 "SIP/2.0"，发送必须大写
六方法INVITE / ACK / BYE / CANCEL / REGISTER / OPTIONS
六必须头Via / Max-Forwards / From / To / Call-ID / CSeq（+建立 dialog 需 Contact）
branch cookie必须是 "z9hG4bK" 开头，全局唯一
Max-Forwards默认 70
事务定时器基准T1=500ms, T2=4s, T4=5s；B/H=64·T1, D=32s, G/J=64·T1, K/I=T4
dialog IDCall-ID + 本地 tag + 远端 tag
From-tag / To-tagUAC 加 From-tag；UAS 在响应加 To-tag
事务 vs dialog事务=单请求可靠性单位；dialog=呼叫持续关系（含多事务）
可靠性分工UDP 上事务层重传；TCP/TLS/SCTP 外包传输层
安全三件套sips/TLS + Digest 认证 + S/MIME

19.2 参考文献（RFC）

与同库其他页的关联：SIP 跑在 UDP/TCP 之上（TCP 页讲握手/重传，SIP 事务层在 UDP 上是「自己再造一层」）；媒体流是 RTP（基于 UDP）；SDP 见 RFC 4566。SIP 在 OSI 归 L5 会话层 / L7 应用层。