IMS解决方案统一维护手册协议专题 SIP协议

IMS 解决方案统一维护手册-协议专题-SIP 协议
IMS
维护指导手册
Issue 01
Date 2011-02-10
内部使用
华为技术有限公司
华为技术有限公司为客户提供全方位的技术支持，用户可与就近的华为办事处联系，也可直接与公司总部联
系。
华为技术有限公司
地址：深圳市龙岗区坂田华为总部办公楼邮编：518129
网址： http://www.huawei.com
客户服务电话： 0755-28560000 4008302118
客户服务传真： 0755-28560111
客户服务邮箱： support@huawei.com
版权所有 © 华为技术有限公司 2010。保留一切权利。

非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传
播。
商标声明
和其他华为商标均为华为技术有限公司的商标。
本文档提及的其他所有商标或注册商标，由各自的所有人拥有。
注意
由于产品版本升级或其他原因，本文档内容会不定期进行更新。除非另有约定，本文档仅作为使用指导，本
文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。
IMS 维护指导手册关于本文档
关于本文档
拟制信息
作者魏跃锋 00108078 时间 2011-02-10
评审刘翔 00160693、陈春时间 2011-04-22
华 00135570 、毛辉
55498、肖慧 66904、
刘华 58382、张帮芹
00149223 、孙远东
00113700 、董愔
48268
签发时间
内容简介
本文档介绍了 IMS SIP 信令方面的基础知识和相关问题的处理方法。本文档包含以下内
容：
 SIP 协议简介
 IMS 相关信令流程
 SIP 相关数据配置
 SIP 信令问题处理方法
 案例
希望本文可以帮助您解决维护中遇到的问题，如您发现本文中有错误、描述不清等问题，
或者对本文有任何意见和建议，您可以随时发送邮件至 liuxiang@huawei.com 或
zhangmingyu@huawei.com 进行反馈，总部将指定产品专家闭环解决资料问题，提高资
料质量。
问题反馈，请一线创建 iCare 问题单，并按照如下方式操作：

iCare 问题单标题：“统一维护资料”意见反馈：《IMS XX 类-XX-维护指导手册》
为了您的意见能及时准确处理，请您详细指出问题的位置，并尽可能的留下您的联系
电话。
Issue 01 (2011-02-10) 华为技术有限公司 I

IMS 维护指导手册关于本文档
Issue 01 (2011-02-10) 华为技术有限公司 II

IMS 维护指导手册修改记录
修改记录
文档版本修改说明发布日期作者签发
1.00 第一次正式发布魏跃锋(00108078)
1.01 根据检视意见修魏跃锋(00108078)
改
1.02 根据检视意见修魏跃锋(00108078)
改
Issue 01 (2011-02-10) 华为技术有限公司 II

IMS 维护指导手册目录
目录
1 SIP 介绍 SIP 协议概述...................................................................................................................5

1.1 SIP 是什么.........................................................................................................................................................5
1.2 SIP 发展历史.....................................................................................................................................................5
1.3 常用 SIP 协议标准............................................................................................................................................6
2 相关知识..........................................................................................................................................1
2.1 SIP 基本概念.....................................................................................................................................................1
2.1.1 SIP 相关术语............................................................................................................................................1
2.1.2 SIP 消息..................................................................................................................................................12
2.2 SIP 协议常见头域...........................................................................................................................................22
2.2.1 重要头域................................................................................................................................................22
2.2.2 常用头域................................................................................................................................................26
2.2.3 重要头域参数........................................................................................................................................35
2.3 SIP 呼叫路由机制...........................................................................................................................................36
2.3.1 响应消息路由........................................................................................................................................36
2.3.2 请求消息路由........................................................................................................................................36
2.4 SIP 协议在 IMS 中的应用..............................................................................................................................38
2.5 SIP 消息分发机制...........................................................................................................................................40
2.5.1 ATS9900 SIP 消息分发..........................................................................................................................40
2.5.2 CSC3300 SIP 消息分发.........................................................................................................................41
2.5.3 UGC3200 SIP 消息分发........................................................................................................................42
2.6 常见 SIP 流程..................................................................................................................................................44
2.6.1 用户注册注销流程................................................................................................................................44
2.6.2 用户基本呼叫流程................................................................................................................................44
2.6.3 媒体协商................................................................................................................................................47
2.6.4 临时响应可靠传输流程........................................................................................................................49
2.6.5 UPDATE 流程........................................................................................................................................51
2.6.6 re-INVITE 流程......................................................................................................................................52
2.6.7 SIP 心跳机制..........................................................................................................................................53
2.6.8 SIP-I/SIP-T 中继呼叫流程....................................................................................................................60
2.6.9 SIP 的 DTMF 传递机制.........................................................................................................................63
2.6.10 SIP 传真................................................................................................................................................65
Issue 01 (2011-02-10) 华为技术有限公司 i

IMS 维护指导手册目录
2.6.11 回铃音、异常音流程..........................................................................................................................65
3 SIP 相关配置.................................................................................................................................67
3.1 基本呼叫配置.................................................................................................................................................67
3.2 SIP 心跳配置...................................................................................................................................................67
3.2.1 设备级 OPTION 心跳配置....................................................................................................................67
3.2.2 会话级 Session timer 心跳配置.............................................................................................................70
3.3 SIP 协议定时器配置.......................................................................................................................................72
3.3.2 T1 定时器配置.......................................................................................................................................72
3.3.3 T2 定时器配置.......................................................................................................................................74
3.3.4 TB 定时器配置。..................................................................................................................................75
3.4 SIP 的 DTMF 收号配置..................................................................................................................................75
3.5 SIP 头域相关配置...........................................................................................................................................76
3.5.1 ATS9900 头域相关配置........................................................................................................................76
3.5.2 SBC 头域相关配置................................................................................................................................77
3.5.3 UGC 头域相关配置...............................................................................................................................78
4 故障处理........................................................................................................................................79
4.1 呼叫失败类故障.............................................................................................................................................79
4.1.1 问题分析与处理....................................................................................................................................79
4.1.2 典型案例................................................................................................................................................82
4.2 SIP 呼叫接通后断话类故障...........................................................................................................................87
4.2.1 问题分析与处理....................................................................................................................................88
4.2.2 典型案例................................................................................................................................................88
5 缩略语............................................................................................................................................95
Issue 01 (2011-02-10) 华为技术有限公司 ii

IMS 信令类-SIP 协议-维护指导手册插图目录
插图目录
图 2-1 早期对话......................................................................................................................................................3
图 2-2 主叫使用 Bye...............................................................................................................................................3
图 2-3 主叫发送 CANCEL......................................................................................................................................4
图 2-4 被叫发送失败响应......................................................................................................................................4
图 2-5 最终对话......................................................................................................................................................5
图 2-6 使用 Bye 终结 Confirmed Dialog................................................................................................................6
图 2-7 成功响应的 INVITE 事务...........................................................................................................................7
图 2-8 失败响应的 INVITE 事务...........................................................................................................................7
图 2-9 非 INIVTE 事务样例...................................................................................................................................8
图 2-10 SIP 请求消息结构....................................................................................................................................17
图 2-11 响应消息结构..........................................................................................................................................20
图 2-12 响应消息的路由......................................................................................................................................36
图 2-13 请求消息路由样例 1................................................................................................................................37
图 2-14 请求消息路由样例 2................................................................................................................................38
图 2-15 请求消息路由样例 3................................................................................................................................38
图 2-16 SIP 协议在 IMS 中的应用.......................................................................................................................39
图 2-17 SIP 协议栈................................................................................................................................................39
图 2-18 ATS9900 SIP 消息模块间分发示意图....................................................................................................40
图 2-19 CSC3300 SIP 消息模块间分发示意图...................................................................................................42
图 2-20 UGC3200 SIP 消息模块间分发示意图..................................................................................................43
图 2-21 SIP 用户基本呼叫流程............................................................................................................................45
图 2-22 基本呼叫关键头域..................................................................................................................................45
图 2-23 SDP 媒体描述样例..................................................................................................................................48
图 2-24 媒体协商 O/A 模型..................................................................................................................................49
图 2-25 支持 180 可靠传输流程样例...................................................................................................................50
Issue 01 (2011-02-10) 华为技术有限公司 iii

IMS 信令类-SIP 协议-维护指导手册插图目录
图 2-26 UPDATE 流程样例..................................................................................................................................52
图 2-27 Re-INVITE-200 协商...............................................................................................................................53
图 2-28 200 和 ACK 完成协商.............................................................................................................................53
图 2-29 周期性的设备级心跳..............................................................................................................................54
图 2-30 启发式的设备级心跳..............................................................................................................................54
图 2-31 Session timer 心跳....................................................................................................................................56
图 2-32 ISUP 原因值转换为 SIP 状态码.............................................................................................................60
图 2-33 SIP 状态码转换转换为 ISUP 原因值.....................................................................................................61
图 3-1 心跳配置说明............................................................................................................................................68
图 3-2 T1/T2/TB 定时器关系图...........................................................................................................................72
图 3-3 编解码类型与 CODECID 映射关系表.....................................................................................................79
图 4-1 RTP 分析....................................................................................................................................................85
图 4-2 案例截图 1..................................................................................................................................................87
图 4-3 案例截图 2..................................................................................................................................................87
图 4-4 案例截图 3..................................................................................................................................................88
图 4-5 案例截图 4..................................................................................................................................................88
图 4-6 案例截图 1..................................................................................................................................................90
图 4-7 案例截图 2..................................................................................................................................................91
图 4-8 案例截图 1..................................................................................................................................................94
图 4-9 案例截图 2..................................................................................................................................................94
图 4-10 案例截图 3................................................................................................................................................95
图 4-11 案例截图 1................................................................................................................................................97
图 4-12 案例截图 2................................................................................................................................................97
图 4-13 案例截图 3（主叫侧 ATS 收到的 200 OK(INVITE)消息）.................................................................97
图 4-14 案例截图 3（主叫侧 ATS 收到的 200 OK(INVITE)消息）.................................................................98
Issue 01 (2011-02-10) 华为技术有限公司 iv

IMS 维护指导手册 SIP 介绍 SIP 协议概述
1 SIP 介绍 SIP 协议概述
1.1 SIP 是什么

 SIP 是 Session Initialization Protocol （会话初始协议）的缩写；IETF 制订的多媒
体通信系统框架协议之一，但是 SIP 单独不能完成多媒体呼叫，必须要与其他协
议
一起才能组建完整的多媒体通信系统，与 RTP/RTCP、SDP、MGCP、DNS 等协议
配合共同完成多媒体会话过程。
 IP 网上的呼叫控制协议，用来初始（建立）、更改和终止一个或者多个参与者的会
话的协议，这些会话包括多媒体会议、网络呼叫等。
 只描述建立/更改/终止一个会话，并不描述会话的内容，所以可以承载任何会话内
容，如语音/视频/游戏等。
 一种应用层协议，独立于下面的传输层协议，可以承载在不同的传输协议上，如
UDP/TCP/TLS/SCTP。
 纯文本协议 (H.323 和 BICC 都是二进制协议)，和 IP 网上的 HTTP/SMTP 等协议类
似。
 一种易于扩展的协议，比如：
SIP-T/SIP-I：通过对消息头域和消息体的扩展，支持 SIP 和 ISUP 的互通；
IM/Presence：支持及时消息和异步事件通知；
3GPP 扩展：3G R5 IP 域的呼叫控制协议；
目前仍在不断的发展中。
 端到端的协议，SIP 网络中的终端具有智能，服务器只需要维护很少的状态。
1.2 SIP 发展历史

 源于 1996 年的 MBone 实验室。
 1999/3，IETF 的 MMUSIC 工作组推出 SIP 的标准 RFC2543。
 1999/9，IETF 成立了 SIP 工作组，负责 SIP 的相关标准的制订。
Issue 01 (2011-02-10) 华为技术有限公司 5

 RFC2543 从 bis00 发展到了 bis09，于 2002 年 6 月通过了 SIP 的基本纲领

RFC3261，
这是 SIP 协议的核心规范。
 接着， RFC3262，RFC3263，RFC3264，RFC3265 相继通过，这 5 个 RFC 构成了
SIP 协议的基础，也是 SIP 协议扩展规范的一部分。
 现在更多的 RFC 和草案被引入到 SIP 中，包括支持 Presence 和 Instant Message 等。
1.3 常用 SIP 协议标准

Reference Title Usage Description
Number
RFC2045 Multipurpose Internet Mail Extensions 多用途的 Internet 邮件扩展

(MIME) Part One: Format of Internet 第一部分：消息体格式
Message Bodies
RFC2046 Multipurpose Internet Mail Extensions 多用途的 Internet 邮件扩展

(MIME) Part Two:Media Types 第二部分：媒体类型
RFC 2327 SDP: Session Description Protocol SDP 协议标准文档
RFC 2543 SIP: Session Initiation Protocol SIP 协议标准基础文档 1999

年 3 月版
RFC 2617 HTTP Authentication: Basic and Digest HTTP 鉴权

Access Authentication
RFC 2833 RTP Payload for DTMF Digits, Telephony 2833 协议标准文档
Tones and Telephony Signals
RFC 2976 The SIP INFO Method INFO 消息用来携带信息，

如 digit 信息等
RFC 3261 SIP: Session Initiation Protocol SIP 协议标准基础文档 2002

年 6 月版（RFC 2543 废
弃）
RFC 3262 Reliability of Provisional Responses in 扩展 SIP 协议来提供临时响

Session Initiation Protocol 应的可靠传输(这里的扩展
是相对 RFC3261 只提供协
议基础来说的，并非是私有
扩展)
RFC 3264 An Offer/Answer Model with Session Offer/Answer 媒体协商机制

Description Protocol (SDP)

RFC 3265 Session Initiation Protocol (SIP)-Specific SIP 事件和通知机制标准文

Event Notification 档
RFC 3311 The Session Initiation Protocol (SIP) UPDATE 方法提供媒体改向

UPDATE Method
RFC 3312 Integration of Resource Management and SIP 资源预留

Session Initiation Protocol (SIP)
RFC 3323 A Privacy Mechanism for the Session SIP 提供匿名机制，如 CLI
Initiation Protocol (SIP) 类业务
RFC 3325 Private Extensions to the Session Initiation SIP 提供匿名机制，如 CLI
Protocol (SIP) for Asserted Identity within 类业务
Trusted Networks
RFC 3326 The Reason Header Field for the Session Reason 头域用来在请求或响
Initiation Protocol (SIP) 应中携带产生的原因
RFC 3372 Session Initiation Protocol for Telephones PSTN-SIP 交互机制

(SIP-T): Context and Architectures
RFC 3398 Integrated Services Digital Network (ISDN) ISUP 协议和 SIP 协议的映
User Part (ISUP) to Session Initiation 射关系（IETF 标准组织）
Protocol (SIP) Mapping
RFC 3420 Internet Media Type message/sipfrag 定义 message/sipfrag 类型
RFC 3515 The Session Initiation Protocol (SIP) Refer REFER 方法指示接受方用
Method 指定方法去联系第三方，可
以用来实现 Call Transfer 等
业务
RFC 3550 RTP: A Transport Protocol for Real-Time RTP 传输协议

Applications
RFC 3555 MIME Type Registration of RTP Payload 定义了 RTP Payload 格式，
Formats 如：audio/PCMA
RFC 3578 Mapping of Integrated Services Digital ISUP 重叠发码信令和 SIP

Network (ISDN) User Part (ISUP) Overlap 消息的映射关系。IMS 不遵
Signalling to the Session Initiation Protocol 循该 RFC，采用 INFO 消息
(SIP) 支持重叠发码
RFC 3824 Using E.164 numbers with the Session SIP 协议中 E.164 号码应用
Initiation Protocol (SIP)

RFC 3842 A Message Summary and Message Waiting 定义了 SIP 协议的留言灯格
Indication Event Package for the Session 式
Initiation Protocol (SIP).
RFC 3891 The Session Initiation Protocol (SIP) Replaces 头域用来将一个新

"Replaces" Header 对话替换一个已经存在的对
话，可以用来实现 Attended
Transfer, Call pickup 等业务
RFC 3892 The Session Initiation Protocol (SIP) Referred-By 头域携带了

Referred-By Mechanism Referrer 的 URI 标志
RFC 3966 The tel URI for Telephone Numbers 定义了 tel URI
Q.1912.5 Interworking between Session Initiation SIP 和 ISUP 的交互映射关

Protocol (SIP) and Bearer Independent Call 系（ITU-T 标准组织）
Control Protocol or ISDN User Part
RFC 4028 Session Timers in the Session Initiation SIP 对话的心跳机制

Protocol (SIP)
RFC 4032 Update to the Session Initiation Protocol RFC3312 的更新版，资源预

(SIP)Preconditions Framework 留
RFC 4244 An Extension to the Session Initiation 定义了在 SIP 请求中携带历

Protocol (SIP) for Request History 史信息的机制，新定义了
Information History-info 头域
draft-ietf-sipping-service-examples-10 SIP Service Examples
draft-levy-sip-diversion-08 Diversion Indication in SIP
draft-mahy-iptel-cpc-02.txt The Calling Party's Category

tel URI Parameter
(the draft standardized by ETSI)

2 相关知识
2.1 SIP 基本概念

SIP 协议能够支持下列五种多媒体通信的信令功能：
 用户定位：确定参加通信的终端用户的位置。
 用户通信能力协商：确定通信的媒体类型和参数。
 用户意愿交互：确定被叫是否乐意参加某个通信。
 建立呼叫：包括向被叫“振铃”，确定主叫和被叫的呼叫参数。
 呼叫处理和控制：包括呼叫重定向、呼叫转移、终止呼叫等等。
2.1.1 SIP 相关术语

1. 会话（Session）
Session 是主被叫间的一次音频、视频的通讯，其包含一个或多个对话，除了信令层次
的 Dialog 外，还包含了媒体信息的协商。
Session 也有一个创建、修改、终结的过程，Session 只能由 INVITE 创建；INVTE 事务
在创建 Dialog 的同时，也创建了一个 Session。
Session 的修改是通过 INVITE/UPDATE 消息中携带的 SDP 消息体来完成的。
Session 的终结和 Dialog 的终结方法相同。主、被叫间的媒体协商遵循 RFC 3264
（Offer/Answer）模型，这里不详细阐述，见 2.6.1 章节。
2. 对话（Dialog）
对话是 SIP 主叫和被叫间的一个端到端的信令联系，不涉及任何消息体的信息（不涉
及
任何媒体的信息）。一个 SIP 对话包括如下状态参数：
 Dialog-id：由 Call-ID、remote tag（即 To tag）、local tag（即 From tag）组成。
 A local sequence number：对于 UAC 为 CSeq 头域的数字部分，对于 UAS 则设置为

空值。
 A remote sequence number：对于 UAS 为 CSeq 头域的数字部分，对于 UAC 则设置
为空值。
 A local URI：对于 UAC 为 From 头域的 URI，对于 UAS 为 To 头域的 URI。
 A remote URI：对于 UAC 为 To 头域的 URI，对于 UAS 为 From 头域的 URI。
 Remote target：对于 UAS 为请求中 Contact 头域的 URI，对于 UAC 为响应
中 Contact 头域的 URI。
 A boolean flag called “secure”：对于 UAS，如果请求是通过 TLS 过来的，并且
Request-URI 包含一个 SIPS URI,”secure”标志将
被赋值成为 TRUE；对于 UAC，如果请求是通过
TLS 发送的，并且 Request-URI 包含一个 SIPS
URI,
那么”secure”标志被设置成为 TRUE。
 A route set：对于 UAS，该值设置为请求中 Record-Route 的 URIs，如果没有
Record-Route，则 route set 设置为空值；对于 UAC，该值设置为响应中
Record-Route 的 URIs，如果没有 Record-Route，则 route set 设置为
空值。
上述参数的详细描述可参见 RFC 3261 第 12 章。
对话也有一个创建/修改/销毁的过程。
在 RFC 3261 里面定义，只有 INVITE 才能创建对话；
RFC 3265 里面定义，INVITE 和 SUBSCRIBE 都可以创建对话；
RFC 3515 里面定义，REFER 可以创建对话；
对话（Dialog）分为早期对话（Early Dialog）和最终对话（Confirmed Dialog）。
1) 早期对话（Early Dialog）
图1.1 早期对话
如上图，当收到带 To Tag 的 1xx 响应（非 100）时，进入 Early Dialog 状态。
Issue 01 (2011-02-10) 华为技术有限公司 10

在 Early Dialog 状态下，主叫和被叫间可以发送其他事务。如果对话没有建立，则不允

许发送呼叫内的新事务，上图中的 UPDATE 消息就是一个新事务，对于新事务，CSeq
头域里面的序列号必须比前一个事务加 1，如上图中 INVITE 消息的 Cseq 等于 1，
UPDATE 消息的 Cseq 等于 2。
早期对话可以用如下方式终结：
 主叫发送 Bye 消息释放，如下图
图1.2 主叫使用 Bye
 主叫发送 CANCEL，被叫回失败响应，如下图
图1.3 主叫发送 CANCEL
 被叫发送失败响应，如下图
Issue 01 (2011-02-10) 华为技术有限公司 11

图1.4 被叫发送失败响应
在 Early Dialog 状态下，被叫不能发送 BYE 来终结对话（Dialog）；只能通过发送失败

响应来终结。
2) 最终对话（Confirmed Dialog）
图1.5 最终对话
如上图，被叫发送 200 OK 后，进入了 Confirmed Dialog 状态；主叫收到 200 OK 后，

进入了 Confirmed Dialog 状态；后续可以通过 INVITE（也叫做 re-INVITE）/UPDATE
Issue 01 (2011-02-10) 华为技术有限公司 12

修改对话的状态；与早期对话建立一样，进入最终对话后，可以发起呼叫内的其他事
务，
比如上图中的 Re-INVITE 消息就属于新的事务。
进入 Confirmed Dialog 后，主叫或者被叫都能通过 BYE 消息来终结 Dialog，如下图：
图1.6 使用 Bye 终结 Confirmed Dialog
3. 事务 (Transaction)
事务是指请求与响应的交互过程，一个事务由一个请求消息、零个或者多个临时响应，
以及一个最终响应构成。事物概念的详细描述可参见 RFC 3261 第 17 章。
事务以 Via 头域中的 branch 参数作为唯一标识，RFC 3261 第 8.1.1.7 中规定 branch 参数
必须以“z9hG4bK”开始。
事务主要分为两类：INVITE 事务（采用三次握手方式）、非 INVITE 事务（采用两次
握手方式）以及特殊事务，INVITE 事务和非 INVITE 事务按照状态机的不同，进一步
分为四类事务：
3) INVITE 客户端事务
4) INVITE 服务端事务
5) 非 INVITE 客户端事务
6) 非 INVITE 服务端事务。
1) INVITE 事务
Issue 01 (2011-02-10) 华为技术有限公司 13

图1.1 成功响应的 INVITE 事务
如上图所示，INVITE、100、180、200 都属于同一事务
对于 INVITE 收到成功响应(即 2XX 响应）的情况，ACK 不属于 INVITE 事务，而属于

单独的事务。
图1.2 失败响应的 INVITE 事务
如上图所示，对应收到失败响应的 INVITE 事务，INVITE、100、180、3XX~6XX、ACK

消息都属于同一事务。
2) 非 INVITE 事务
Issue 01 (2011-02-10) 华为技术有限公司 14

图1.3 非 INIVTE 事务样例
对于非 INVITE 事务，一般不存在临时响应，只有最终响应。有很多请求消息及其响应

都是属于非 INVITE 事务，比如 Prack、Bye、Option、Subscribe、Message 等。
3) 特殊的事务
ACK 事务和 CANCEL 事务都是比较特殊的事务。
ACK 事务：对于 200 of INVITE 的确认事务，是一个单独的事务。也就是说，一个消息
就是一个事务，如图 1.1 所示。
CANCEL 事务：CANCEL 事务只能用于 CANCEL INVITE 事务，而不能用于 CANCEL
非
INVITE 事务；CANCEL 事务的 branch 参数和 INVITE 的相同。CANCEL 事务只能在
收到 INVITE 的临时响应后（包括 100），最终响应之前发送。CANCEL
是一个逐跳的事务（关于逐跳的概念后续说明）。
4) 事务的匹配
客户端事务中匹配应答，当客户端的传输层收到一个应答后，需要决定一个客户端事
务来处理这个应答，一个应答基于以下情况来匹配一个客户端事务：
 应答的 branch 值是否与创建这个事务的请求的 branch 值一致。
 应答中 CSeq 头域的方法参数与创建这个事务的请求方法一样。
当一个请求被分发时，将会有多个应答，这些应答的 branch 值一样，但 To 头域的 tag
不一样。
服务端事务中匹配请求，在服务端通过以下方法来匹配一个请求和事务：
 请求的 branch 值与创建这个事务的 branch 值一样。
 Top Via 中 Sent-by 与创建该事务的请求一样。
 请求的 method 与创建这个事务的请求方法一样，例外情况是 ACK。
 当 branch 不存在，又或者不包含“z9hG4bk”时，对于 Invite 请求，使用 Request-
URI，
To tag，From tag，call-ID，CSeq 和 Top Via 来匹配。
Issue 01 (2011-02-10) 华为技术有限公司 15

对于其他的请求方法，匹配一个事务的情况如下：使用 Request-URI，To tag，From

tag，
call-ID，CSeq 和 Top Via 来匹配。
4. 统一资源定位符（URI）
为了能正确传送协议消息，SIP 还需解决两个重要的问题。一是寻址，即采用什么
样的地址形式标识终端用户；二是用户定位（下面介绍）。SIP 沿用 WWW 技术解决这
两个问题。寻址采用 SIP URL（Uniform Resource Locators），按照 RFC 2396 规定的
URI
规则定义其语法，特别是用户名字段可以是电话号码，以支持 IP 电话网关寻址，实现
IP 电话和 PSTN 的互通。
SIP URL 的一般结构为：
sip：用户名:口令@主机:端口;传送参数;用户参数;方法参数;生存期参数;
服务器地址参数？头部名＝头部值
“sip”表示需采用 SIP 协议和所指示的端系统通信。
“用户名”可以由任意字符组成，一般可取类似于 E-mail 用户名形式，也可以是电话号
码（IMS 目前开户时用户名是全局电话号码，如+867552878000）。
“主机”可为主机域名或 IPv4 地址（IMS 目前开户时主机部分是域名）。
“端口”指示请求消息送往的端口号，其缺省值为 5060，即公开的 SIP 端口号。该参数
只有当主机为 IP 地址时，才会携带。
“口令”可以置于 SIP URL 中，但一般不建议这样做，因为其安全性是有问题的。
“传送参数”指示采用 TCP 还是 UDP 传送，缺省值为 UDP。
“用户参数”，SIP URL 的一个特定功能是允许主机类型为 IP 电话网关，此时，用户名
可以为一般的电话号码。由于 BNF 语法表示无法区分电话号码和一般的
用户名，因此，在域名后增加了“User 参数”字段。该字段有两个可选值：
IP 和 phone，当其设定为“phone”时，表示用户名为电话号码，对应的端
系统为 IP 电话网关。
“方法参数”指示所用的方法（操作）。
“生存期参数”指示 UDP 多播数据包的寿命，仅当传送参数为 UDP、服务器地址参数为
多播地址时才能使用。
“服务器地址参数”指示和该用户通信的服务器的地址，它覆盖“主机”字段中的地址，
通常为多播地址。
“传送参数”、“生存期参数”、“服务器地址参数”和“方法参数”均属于 URL 参数，只
能在重定向地址，即后面所说的 Contact 字段中才能使用。
Issue 01 (2011-02-10) 华为技术有限公司 16

下面给出若干个 SIP URL 的示例：

sip:+8675555500200@ims.hw.com
s+8675555500200 为用户名，ims.hw.com 为用户所在的主机域名。
sip: +8675555500200@127.0.0.1:5061;User=phone
+8675555500200 为用户名，127.0.0.1 为主机的 IP 地址，5061 为主机端口号。User
参数为“phone”时表示用户名为电话号码。
sip:alice@ ims.hw.com;method=REGISTER
Alice 为用户名，ims.hw.com 为主机域名。方法参数为“登记”。
另外，IMS 主要支持两种 URI 格式：SIP URL 和 TEL URI。IMS 中，SIP URI 结构一般
为：
sip：用户名:口令@主机:端口;用户参数;方法参数
下面描述一下 TEL URI。TEL URI 的一般结构为（RFC 3966 对 TEL URI 格式有详细介
绍）：
tel：telephone-subscriber
telephone-subscriber 可以是全局号码或者本地号码。
IMS TEL URI 样例如下：
 包括国家码、地区码的国际号码
tel:+86-755-7770001
 只包括国家码的国际号码
tel:+86-13456789012
tel:+8613456789012
 国内号码
tel:0755-7770001;phone-context=+86
tel:07557770001;phone-context=+86
 用户号码
tel: 7770001;phone-context=+86-755
tel: 7770001;phone-context=+86755
进一步的信息可以参考 RFC 3966。
5. 代理、代理服务器（Proxy、Proxy Server）
作为一个逻辑网络实体代表客户端转发请求或者响应，可以同时作为客户端和服务器
端。代理服务器有三种形态：Stateless、Stateful 和 Call Stateful，其可以采用分支、循环等
方式向多个地址尝试转发请求。
Issue 01 (2011-02-10) 华为技术有限公司 17

代理服务器的主要功能：路由、认证鉴权、计费监控、呼叫控制、业务提供等。在华为
IMS 解决方案中，CSC3300 兼任代理服务器的角色。进一步信息请参考 RFC 3261 第 16
章。
6. 重定向服务器（Redirect Server）
重定向服务器将请求中的目的地址映射为零个或多个新的地址，然后返回给客户端，
客户端直接再次向这些新的地址发起请求。重定向服务器并不接收或者拒绝呼叫，主要
完成路由功能，与注册过程配合可以支持 SIP 终端的移动性。在华为 IMS 解决方案中，
ATS9900 可以兼任重定向服务器的角色。进一步信息请参考 RFC 3261 第 8.3 章。
7. 注册员（Registrar）
注册员为接收注册请求的服务器，通常与 Proxy 或者 Redirect Server 共存。注册员需要
将注册请求中的地址映射关系保存到数据库中，供后续的相关呼叫过程使用，同时可
以提供定位服务。在华为 IMS 解决方案中，CSC3300 和 ATS9900 都可以兼任注册员的
角色。进一步信息请参考 RFC 3261 第 10 章。
8. 用户助理（User Agent）
用来发起或者接收请求的逻辑实体称为 User Agent。在华为 IMS 解决方案中，
ATS9900、UGC3200 可以兼任用户助理的角色。进一步信息请参考 RFC 3261 第 8 章。
9. 客户端助理（User Agent Client）

发起请求的一方称为 UAC（User Agent Client），举例 SIP Phone 就是 UAC 的一种实际
形态，同时 IMS 中，ATS9900 也可以是 UAC。进一步信息请参考 RFC 3261 第 8 章。
10. 服务端助理（User Agent Server）

接收请求的一方称为 UAS（User Agent Server），举例 ATS9900 就是 UAS 的一种实际
形态。进一步信息请参考 RFC 3261 第 8 章。
UAC 和 UAS 的划分是针对一个事务而言的。
11. 端（End）和跳（Hop）
SIP 网络中 UA 叫做端；SIP 网络中，UA 和下一个 Proxy 之间，Proxy 和下一个
Proxy，Proxy 和下一个 UA 之间，叫做一跳；有些消息是端到端（E2E）传送，中间设
备（比如 Porxy）直接透明传输即可，事务的可靠性是靠 UA 来保证的；有些消息是逐
跳发送，事务的可靠性由经过的每一个实体保证。
2.1.2 SIP 消息
SIP 消息采用文本方式编码，分为两类：请求消息和响应消息。
Issue 01 (2011-02-10) 华为技术有限公司 18

12. SIP 请求消息类型

用于客户端为了激活按特定操作而发给服务器的 SIP 消息，包括
INVITE 、ACK、OPTIONS、BYE、CANCEL 和 REGISTER 消息等，各消息功能如表 2-1
所示。
表1.1 请求消息
请求消息消息含义
发起会话请求，邀请用户加入一个会话，会话描述含于消息体中。
对于两方呼叫来说，主叫方在会话描述中指示其能够接受的媒体
类型及其参数。被叫方必需在成功响应消息的消息体中指明其希
INVITE 望接受哪些媒体，还可以指示其将发送的媒体。
如果收到的是关于参加会议的邀请，被叫方可以根据 Call-ID 或
者会话描述中的标识确定用户已经加入该会议，并返回成功响应
消息。
证实已收到对于 INVITE 请求的最终响应。该消息仅和 INVITE 消

ACK
息配套使用。
BYE 结束会话
CANCEL 取消尚未完成的请求，对于已完成的请求（即已收到最终响应的
请求，比如 200 OK）则没有影响。
REGISTER 注册。在 IMS 中一般用于用户发起注册、注销、刷新注册等请求。
查询服务器能力。在 IMS 中一般用于设备间心跳状态检测，进一

OPTION
步信息请参考 RFC4028。
临时可靠性响应，证实已收到 1XX 临时响应，进一步信息请参

PRACK
考 RFC 3262。
传递额外信息请求。在 IMS 中一般用于放音指示、二次收号，进

INFO
一步信息请参考 RFC 2976。
订阅请求。在 IMS 中一般用于用户注册状态、ua-profile 的订阅，

SUBSCRIBE
进一步信息请参考 RFC 3265。
订阅通知请求。在 IMS 中，NOTIFY 消息是与 SUBSCRIBE 消息

NOTIFY 配合使用的，NOTIFY 为 SUBSCRIBE 的最终响应，进一步信息
请参考 RFC 3265。
会话建立早期或确定阶段修改会话属性，更新会话参数请求。在
UPDATE IMS 中一般用于媒体更新、会话心跳检测，进一步信息请参考
RFC 3311。
Issue 01 (2011-02-10) 华为技术有限公司 19

立即消息。在 IMS 中一般用于留言灯指示（MWI）业务，进一步

MESSAGE
信息请参考 RFC 3428。
指示接收方联系第三方请求，REFER 请求的发送者指引其接收
REFER 者去访问 REFER 请求中所标识的资源。在 IMS 中一般用于点击
类呼叫、呼叫转移、会议等业务，进一步信息请参考 RFC 3515。
客户端向状态代理发布它的事件状态。在 IMS 中暂无应用，进一

PUBLISH
步信息请参考 RFC 3903。
13. SIP 响应消息类型

用于对请求消息进行响应，指示呼叫的成功或失败状态。不同类的响应消息由状态码来
区分。状态码包含三位整数，状态码的第一位用于定义响应类型，另外两位用于进一步
对响应进行更加详细的说明。各响应消息分类和含义如表 2-2 所示。
表1.1 响应消息
序号状态码消息功能
表示已经接收到请求消息，正在对其进行处理，一次呼
临时响应
叫中临时响应可以有多个。
100 表示请求消息已收到，可以防止对局请求超时重传。
180 振铃
1XX
181 呼叫正在前转。在 IMS 中主要用于前转业务。
182 排队
183 呼叫处理中
成功响应表示请求已经被成功接受、处理。
200 OK
2XX
Accepted，指示订阅请求已被初步接受，但还需等到最
202 终决策，最终决策将在 NOTIFY 请求中给出。进一步信
息请参考 RFC 3265。
重定向响应表示需要采取进一步动作，以完成该请求。
3XX
300 多重选择
Issue 01 (2011-02-10) 华为技术有限公司 20

301 永久迁移
302 临时迁移
303 其它
305 使用代理
380 代换服务
4XX 表示请求消息中包含语法错误或者 SIP 服务器不能完成

客户端错误
对该请求消息的处理。
400 错误请求
401 无权
402 要求付款
403 禁止
404 没有发现
405 不允许的方法
406 不接受
407 要求代理权
408 请求超时
410 消失
413 请求实体太大
414 请求 URI 太大
415 不支持的媒体类型
416 不支持的 URI 方案
420 分机无人接听
421 要求转机
Issue 01 (2011-02-10) 华为技术有限公司 21

423 间隔太短
480 暂时无人接听
481 呼叫腿/事务不存在
482 相环探测
483 跳频太高
484 地址不完整
485 不清楚
486 线路忙
487 终止请求
488 此处不接受
491 代处理请求
493 难以辨认
服务端错误表示 SIP 服务器故障不能完成对正确消息的处理。
500 内部服务器错误
501 没实现的
502 无效网关
5XX
503 不提供此服务
504 服务器超时
505 SIP 版本不支持
513 消息太长
6XX 全局故障表示请求不能在任何 SIP 服务器上实现。
600 全忙
Issue 01 (2011-02-10) 华为技术有限公司 22

603 拒绝
604 都不存在
606 不接受
14. SIP 请求消息结构
图1.1 SIP 请求消息结构
上图是 SIP 请求命令的格式，由起始行、消息头和消息体组成。通过换行符区（CRLF）

分消息头中的每一条参数行。对于不同的请求消息，有些参数可选。
请求消息头域及参数请参考 2.2 节所述。
 请求消息示例
下面是 SIP 请求消息编码的示例（ATS 发送的 INVITE 消息）：
Issue 01 (2011-02-10) 华为技术有限公司 23
INVITE tel:+8675580002901 SIP/2.0
From: <sip:+867556650001@ims.hw.com>;tag=1ccb6df3
To: <sip:66500002@ims.hw.com;user=phone>
CSeq: 1 INVITE
Call-ID: 20973e49f7c52937fc6be224f9e52543@ats9900.ats.ims.hw.com
Via: SIP/2.0/UDP 154.112.2.51:5061;branch=z9hG4bKliv0vdlwdrrydvgrpix0pgx0w
Contact: <sip:+867556650001@ 154.112.2.51:5060>
Supported: 100rel
Max-Forwards:70
Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,
NOTIFY,MESSAGE,REFER
Content-Length:230
Content-Type: application/sdp
v=0
o=HwATS9900 1073741831 1073741831 IN IP4 154.112.2.51
s=Sip Call
c=IN IP4 191.134.110.3
t=0 0
m=audio 10002 RTP/AVP 8 0 4 18
a=rtpmap:8 PCMA/8000
a=rtpmap 0 PCMU/8000
a=rtpmap 4 G723/8000
a=rtpmap 18 G729/8000
第一行：请求起始行。INVITE 请求消息。请求 URI，即被邀用户的当前地址为“tel:

+8675580002901”。SIP 版本号为 2.0。
第二行：From 字段。指明请求发起方的地址为“< sip:+867556650001@ ims.hw.com >”。
标记为“1ccb6df3”，用于共享同一 SIP 地址的不同用户用相同的 Call-ID 发起呼叫邀请
时，对用户进行区分。
第三行：To 字段。指明请求接收方的地址为“< sip:66500002@ims.hw.com;user=phone
>”。
从 From 和 To 字段，可以看出：
用户标识为“sip:+867556650001@ ims.hw.com”的用户呼叫用户标识为“tel:
+8675580002901”的用户。终端类型可以为 SIP、GPON、MSAN、AGCF 等。
Issue 01 (2011-02-10) 华为技术有限公司 24

第四行：Cseq 字段。用于将 INVITE 请求和其触发的响应、对应的 ACK、CANCEL 请求

相关联。
第五行：Call-ID 字段。该字段唯一标识一个特定的邀请，全局唯一。Call-ID 为
“20973e49f7c52937fc6be224f9e52543@
ats9900.ats.ims.hw.com”，“ats9900.ats.ims.hw.com”为发起呼叫的主机的域名，
20973e49f7c52937fc6be224f9e52543 为本地标识。
第六行：Via 字段。该字段用于指示该请求历经的路径。“SIP/2.0/UDP”表示发送的协议，
协议名为“SIP”，协议版本为 2.0，传输层为 UDP；“154.112.2.51:5061”表示发送方 ATS
IP 地址为 154.112.2.51，端口号为 5061；“branch=z9hG4bkbc427dad6”为分支参数，IMS
并行分发请求时标记各个分支。
第七行：Contact 字段。指示其后的请求（如 BYE 请求）可以直接发往< sip:
+867556650001@ 154.112.2.51:5060>，而不必借助 Via 字段。
第八行：100rel 扩展，该字段为 100 类响应消息的可靠传输提供了相应的机制。
第九行：Max-Forwards 字段。表示该请求到达其目的地址所允许经过的中转站的最大值
为 70。
第十行：Allow 字段。给出 IP 地址为 154.112.2.51 的设备支持的请求消息类型列表。
第十一～十二行：Content-Length 字段，表示消息长度为 230 个字节。
第十三行：Content-Type 字段，表示消息中携带的消息体是单消息体且为 SDP。
第十四行：空行，表示下面为 SDP 会话描述。
第十五行：SDP 协议版本号，目前为 0 版本。
第十六行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户
主机地址）以及会话标识和会话版本号。“HwATS9900”为用户名，用户名是用户在发起
主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“-”。第一个
“1073741831”为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网
络类型、地址类型、地址）构成会话的全球唯一的标识符。第二个“1073741831”为版本号，
指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。
其基本要求是会话数据修改后，其版本号应递增。“IN”指网络类型，为文本串形式，目
前规定的“IN”为 Internet。“IP4”指地址类型，为文本串形式，目前已定义的有“IP4”和
“IP6”两种。“154.112.2.51”为创建会话的主机的 IP 地址。对于 IP4 地址类型，可以是域名
全称或点分十进制 IP4 地址表示形式。对于 IP6 地址类型，可以是域名全称或压缩文本
IP6 地址表示形式。
第十七行：会话名。每个会话描述必需有一个且只有一个会话名。
第十八行：连接数据。网络类型和地址类型目前的定义值仅限于 IN 和
IP4 。“191.134.110.3”为 ATS（IP 地址：154.112.2.51）控制下的终端的 IP 地址。
第十九行：时间描述，给出会话激活的时间区段，允许会话周期性发生。 “0”表示起始
时间。该字段的格式为 t：<起始时间><终止时间>。其中起始时间和终止时间值为
NTP（Network Time Protocol）时间值的十进制表示，单位为秒。
第二十行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为
音频。目前定义的媒体类型有 5 种：音频、视频、应用、数据和控制。“10002”指明媒体流
发往的传送层端口，即终端的 UDP 端口号。“RTP/AVP”为传送层协议，其值和“c”行中
的地址类型有关，对于 IP4 来说，大多数媒体业务流都在 RTP/UDP 上传送，已定义如
下两类协议：RTP/AVP，音频/视频应用文档，在 UDP 上传送；Udp，UDP 协议。“8 0 4
18”对于音频和视频来说，就是 RTP 音频/视频应用文档中定义的媒体静荷类型。表示会
话中所有这些格式都可能被用到，但第一个格式是会话的缺省格式。进一步信息请参考
RFC 2327。
Issue 01 (2011-02-10) 华为技术有限公司 25
该行总体表示，缺省 A 律 PCM 编码单信道音频信号，其在 RTP 音频/视频应用文档中

的静态静荷类型号为 8 ，该信号发往 UDP 端口 10002。
第二十一～二十四行：rtpmap 属性行，指明从 RTP 静荷类型至编码的映射关系。该行的
格式为：a: rtpmap:<静荷类型><编码名>/<时钟速率>[/<编码参数>]。其中，<编码参数>
指的就是音频信道数，对于视频信号尚无编码参数。
15. SIP 响应消息结构
图1.1 响应消息结构
如上图所示是 SIP 响应消息的格式，由起始行、消息头和消息体组成。通过换行符区分

消息头中的每一行参数。对于不同的响应消息，有些参数可选。
响应消息头域及参数请参考 2.2 节所述。
 响应消息示例
下面是 SIP 响应消息编码的示例：
SIP/2.0 180 Ringing
From: <sip:+867556650001@ ims.hw.com>;tag=1ccb6df3
Issue 01 (2011-02-10) 华为技术有限公司 26

To: <sip:66500002@ims.hw.com;user=phone>;tag=58877b85
Cseq:1 INVITE
Call-ID: 20973e49f7c52937fc6be224f9e52543@ats9900.ats.ims.hw.com
Via: SIP/2.0/UDP 154.112.2.51:5061;branch=z9hG4bkbc427dad6
Require:100rel
RSeq:1
Contact:< sip:+867556650001@ 154.112.2.51:5060;transport=udp>
Content-Length:157
Content-Type:application/sdp
v=0
o= HwATS9900 1073741824 1073741824 IN IP4 154.112.2.51
s=Sip Call
c=IN IP4 191.134.110.3
t=0 0
m=audio 30016 RTP/AVP 8
第一行：SIP 协议，版本号为 2.0。状态码为 180。“Ringing”为注释短语。表示向被叫送振

铃。
第二行、第三行：请参考“SIP 请求消息类型”小节。
第四行：Cseq 字段。用于将 INVITE 请求和其触发的响应、对应的 ACK、CANCEL 请求
相关联。该响应消息和上文中的请求消息 Cseq 字段相同，均为“1 INVITE”，表明该响
应消息由上文中的请求消息触发。
第五～第十一行：请参考“SIP 请求消息类型”小节。
第十二行：空行，表示下面为 SDP 会话描述。
第十三行：SDP 协议版本号，目前为 0 版本。
第十四行：会话拥有者/创建者和会话标识，用于给出会话的发起者（其用户名和用户
主机地址）以及会话标识和会话版本号。“HwATS9900”为用户名，用户名是用户在发起
主机上的登录名，如果主机不支持用户标识的概念，该字段标记为“-”。第一个
“1073741824”为会话标识，会话标识为一数字串，使得多元组（用户名、会话标识、网
络类型、地址类型、地址）构成会话的全球唯一的标识符。第二个“1073741824”为版本号，
指该会话公告的版本。供代理服务器检测同一会话的若干个公告哪一个是最新的公告。
其基本要求是会话数据修改后，其版本号应递增。“IN”指网络类型，为文本串形式，目
前规定的“IN”为 Internet。“IP4”指地址类型，为文本串形式，目前已定义的有“IP4”和
“IP6”两种。“154.112.2.51”为创建会话的主机的 IP 地址。
第十五行：会话名。每个会话描述必须有一个且只有一个会话名。
第十六行：连接数据。网络类型和地址类型目前的定义值仅限于 IN 和
IP4 。“191.134.110.3”为 ATS（IP 地址：154.112.2.51）控制下的终端的 IP 地址。
Issue 01 (2011-02-10) 华为技术有限公司 27

第十七行：时间描述，给出会话激活的时间区段，允许会话周期性发生。
第十八行：媒体级描述，该部分给出只适用于该媒体流的信息。“audio”表示媒体类型为
音频。“30016”指明媒体流发往的传送层端口，即终端的 UDP 端口号。“RTP/AVP”为传送
层协议，其值和“c”行中的地址类型有关，对于 IP4 来说，大多数媒体业务流都在
RTP/UDP 上传送，已定义如下两类协议：RTP/AVP，音频/视频应用文档，在 UDP 上
传送；Udp，UDP 协议。“8”就是 RTP 音频/视频应用文档中定义的媒体静荷类型。
第十九行：rtpmap 属性行，指明从 RTP 静荷类型至编码的映射关系。RTP 静荷类型“8”
对应的编码为 PCMA。
2.2 SIP 协议常见头域

SIP 消息使用头域来携带 SIP 实体的属性、消息体的属性、参数等信息。每一个 SIP 消息
都可以携带一个或多个 SIP 头域。在 IMS 解决方案中，
ATS9900、CSC3300、UGC3200、SE2300 等网元，各种呼叫、业务的处理，都与头域紧密
相关。
2.2.1 重要头域
SIP 协议中最基本、最重要头域是 From、To、Via、Call-ID、Cseq、Max-Forwards 等 6 个头
域。
1. From
From 头域用于携带请求发起者的 URI 信息。以呼叫为例，可以是呼叫中的主叫也可以
是被叫。From 头域中号码可以是 TEL URI 也可以是 SIP URI，消息样例如下示。
From: “81002020”<sip:+8675581002020@ims.hw.com>;tag=45f84802
From: “Anonymous”<sip:anonymous@anonymous.invalid>;tag=45f84802
From 头域中必须包含一个由 UAC 产生的“tag”参数，用于关联一个对话。
From 头域定义于 RFC 3261。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 From 头域的处理如下。
 ATS9900
ATS 收到的初始响应 INVITE 消息后，如果 INVITE 消息中无 P-Asserted-Identity 头
域，则从 From 头域中获取主叫号码。在被叫侧 ATS，会根据号码显示业务对 From
头域中的主叫号码进行调整。同时，ATS 在发出去的消息中，将 CCU 模块号携带
在 From 头域的 tag 参数和消息跟踪句柄中，如：tag=pwve1gz0-CC-20-TRC-
5303，CC-20 即表示用户所在 CCU 模块号为 20，TRC-5303 表示跟踪句柄为 5303。
 CSC3300
CSCF 收到的初始响应 INVITE 消息后，如果 INVITE 消息中无 P-Served-User、P-
Asserted-Identity 头域，则从 From 头域中获取主叫号码（在用户未注册且局方容灾
场景下，CSCF 使用 From 头域中的号码去 HSS 下载用户数据）。
 UGC3200
UGC 收到的初始响应 INVITE 消息后，如果 INVITE 消息中无 P-Asserted-Identity
头域，则从 From 头域中获取主叫号码，在 SI 与 ISUP 互通场景下，UGC 将 From
Issue 01 (2011-02-10) 华为技术有限公司 28

头域中的号码转换为 Generic Number，具体 SIP 与 ISUP 消息转换，请参考统一维

护资料之《IMS 互通类-IMS 与 CS 互通描述-维护指导手册.doc》。同时，UGC 在发
出的初始请求 INVITE 消息中，会将 UGC 网元的 CCU 模块号携带在 tag 参数和消
息跟踪句柄中，如：tag=pwqwmodw-CC-1003-TRC-261955，CC-1003 即表示用户
所在 CCU 模块号为 1003，TRC-261955 表示跟踪句柄为 261955。
2. To
To 头域用于携带请求接收者的 URI 信息。To 头域中的号码可以是 TEL URI 也可以是
SIP URI，一般情况下，To 头域中的号码信息与 Request-URI 中的号码信息是一致的。
To 头域消息样例如下示。
To: <tel:81002021>
在初始请求和会话外请求中，To 头域中不存在“tag”参数，会话内任何响应和请求都存
在“tag”参数。
To 头域定义于 RFC 3261。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 To 头域的处理如下。
 ATS9900
基本呼叫场景下，ATS 对 To 头域无特殊处理，ATS 发出消息中的 To 头域与收到
消息中一致。注册场景下，ATS 会使用 To 头域中的号码去 HSS 下载用户及业务数
据。
 CSC3300
基本呼叫场景下，CSCF 对 To 头域无特殊处理，ATS 发出消息中的 To 头域与收到
消息中一致。注册场景下，CFCF 会使用 To 头域中的号码去 HSS 下载用户及业务
数据。
 UGC3200
无特殊处理。
3. Call-ID
Call-ID 头域用于唯一标识一次邀请或者一次注册，在对话中的任一 UA 的所有请求和
所有应答的 Call-ID 必须一致。Call-ID 消息样例如下示。
Call-ID: yy1hd0v4z40exgrvgzl40h144d4d04ve@ATS.ats01.ims.hw.com.201
注意：Call-ID 是大小写敏感的，即其中的某个字符大小写不一致，Call-ID 是不同的。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 Call-ID 头域的处理如下。
 ATS9900
ATS 作为 B2BUA 的角色，因此一次呼叫过程中，ATS 收到的消息和 ATS
发出的消息中 Call-ID 是不一致的, ATS 发出的消息 Call-ID 头域包含 ATS 的主机名
和 CCU 模块号，如：Call-ID: 1gilgzr4wx4x4rr0wr4ldhlr@ATS.ats01.ims.com.20。
 CSC3300
无特殊处理，不会修改该头域的参数值。
 UGC3200
Issue 01 (2011-02-10) 华为技术有限公司 29

无特殊处理， UGC 网元发出的消息中包含有 UGC 网元的相关信息，如：

Call-ID: g854k1j5587g85n8m4k882kgghk4l4hn@CGPV1R002SIPCOM
4. Via
Via 头域用于携带请求经过的 SIP 实体和路由响应信息。Via 头域消息样例如下示。
Via: SIP/2.0/UDP 5.1.182.18:5061;branch=z9hG4bKuild4yuuf4gltvsutmwsdwtyw ;
Role=3;Dpt=7684_16;TRC=b5c-ffffffff,
Via: SIP/2.0/UDP 5.1.180.22:5060;branch=z9hG4bKmhpelrqh0op7xosmknlronloo;
X-DispCookie=1003;X-DispMsg=1400;X-TrunkGroup=19
在 SIP 协议中，Via 头域用于一次请求中，后续响应的路由。Via 头域中必须包含一个分
支(branch)参数。这个参数用于区分请求创建的事务。这个参数客户端和服务器都会使用。
Via 头域是一个多值头域，域值是有顺序的。
Via 头域定义于 RFC 3261。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 Via 头域的处理如下。
 ATS9900
ATS 会将 Via 头域中其他网元的 IP 地址和端口信息删除，发出去的消息中 Via 为
ATS 网元的 IP 地址和端口，如：收到的消息中 Via 头域的值为： Via:
SIP/2.0/UDP 154.112.8.22:5060;branch=z9hG4bKux0xccuuddhxzmwovauvoyov8;
Role=3;Dpt=7684_16;TRC=ffffffff-ffffffff,SIP/2.0/UDP 154.112.8.22:5060;
branch=z9hG4bKpv7ve88ukfm88upf8ul7vvtle;Role=3;Dpt=7674_16,SIP/2.0/UDP
154.112.8.30:5061;branch=z9hG4bKlegxdz0riihwrh1zd4dvevryv
发出的消息中 Via 头域的值为：Via: SIP/2.0/UDP
5.1.180.18:5061;branch=z9hG4bKuzx4ltduzlg4ntfumdmxflnsv
 CSC3300
CSC 在发出的消息 Via 头域中增加自身网元的 IP 地址、端口号和 dpt 参数，dpt 参
数中会携带 CSC 网元 SCU 模块号,如：Dpt=7674_16(7674 是十六进制)。
 UGC3200
UGC 在发出的初始请求 INVITE 消息 Via 头域中增加自身网元的 IP 地址、端口号、
X-DispCookie 参数，X-DispMsg 参数和 X-TrunkGroup，如：Via: SIP/2.0/UDP
5.1.180.22:5060;branch=z9hG4bK0pmlohrl0mrpwdsrh7sp0ssro;X-DispCookie=1003;X-
DispMsg=1401;X-TrunkGroup=10
其中，X-DispCookie 参数携带 UGC 网元 CCU 模块号，X-DispMsg 参数携带 UGC
网元 BSG 模块号，X-TrunkGroup 携带中继群号。
5. Cseq
Cseq 头域用于表示请求的顺序号，RFC3261 中用于事务标识。它是由一个方法
（method）和一系列的顺序号码组成。方法（method）必须和请求的方法一致。对于
对话外的非 REGISTER 请求来说，顺序号码可以是任意的。
Cseq 头域的消息样例如下示。
Issue 01 (2011-02-10) 华为技术有限公司 30

CSeq: 1 INVITE
Cseq 头域定义于 RFC 3261。
上述五个头域（From、To、Call-ID、Via、Cseq）必须出现在每个 SIP 消息中。
6. Max-Forwards
Max-Forwards 头域用于标识一个实体能够经过 SIP 实体数，是一个计数器，用于限制
出现请求消息的死循环。RFC 3261 8.1.1.6 中规定 UAC 发起的请求消息中，Max-
Forwards 的值应该为 70，后续消息每经过一跳，值会逐跳减 1。
Max-Forwards 头域消息样例如下示。
Max-Forwards: 70
Max-Forwards 头域定义于 RFC 3261。
2.2.2 常用头域
16. Route
Route 头域用于强制一个请求经过一个 proxy 路由列表。Route 头域是一个多值头域，域
值是有顺序的。
Route 头域消息样例如下示。
Route: <sip:154.112.8.30:5060;lr>,<sip:154.112.8.22;lr;ORGDLGID=17217-5;Dpt=7684_6;
TRC=b5c-ffffffff>
Route 头域定义于 RFC 3261。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 Route 头域的处理如下。
 ATS9900
ATS 会将 Route 头域中 ATS 网元的 IP 地址和端口信息删除，如：收到的消息中
Route 头域的值为：Route: <sip:154.112.8.30:5060;lr;orig>,<sip:154.112.8.22;lr;
ORGDLGID=16976-1;Dpt=7674_6;TRC=b89-ffffffff> 发出的消息中
Via 头域的值为：Route: <sip:154.112.8.22;lr;ORGDLGID=16976-1;
Dpt=7674_6;TRC=b89-ffffffff>
 CSC3300
CSC 在发出的消息 Route 头域中增加自身网元的 IP 地址、端口号、dpt 参数和
ORGDLGID 参数，dpt 参数中会携带 CSC 网元 SCU 模块号,如：Dpt=7674_16(7674
是十六进制)， ORGDLGID 参数用于关联呼叫。
 UGC3200
UGC 发出的初始请求 INVITE 消息 Route 头域中为消息接收网元的 IP 地址、端口号。
Issue 01 (2011-02-10) 华为技术有限公司 31

17. Record-Route
Record-Route 头域是 proxy 在请求中增加的，用于强制会话中的后续请求经过本
proxy 。Record-Route 头域是一个多值头域，域值是有顺序的。
Route 头域消息样例如下示。
Record-Route: <sip:154.112.8.22;lr;Dpt=7674_136;Role=3;CxtId=4;spln=S;
X-HwB2bUaCookie=844;TRC=b5c-ffffffff>
Record-Route 头域定义于 RFC 3261。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 Record-Route 头域的处理
如下。
 ATS9900
ATS 会将收到消息中的 Record-Route 头域删除，发出的消息中无此头域。
 CSC3300
CSC 在发出的消息中增加 Record-Route 头域，头域中增加自身网元的 IP 地址、端
口号和 dpt 等参数。
 UGC3200
无特殊处理。
18. Contact
Contact 头域携带了一个 URI，这个 URI 的含义取决于是在请求还是在应答中。在请求
中，该 URI 是主叫用户的 URI 信息，在响应中，则是被叫用户的 URI 信息。
在 SIP 协议中，Contact、Record-Route、Route 等三个头域将用于请求的后续路由，参见
2.3.2 示。
Contact 头域消息样例如下示。
Contact: <sip:+8675581002020@191.134.110.3:5060;transport=udp>
Contact 头域定义于 RFC 3261。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 Contact 头域的处理如下。
 ATS9900
ATS 会将收到消息 Contact 头域中的 IP 地址和端口号改为 ATS 网元的 IP 地址和端
口。
 CSC3300
• 注册场景下，如果用户已注册，S-CSCF 会根据 Contact 头域中的 IP 地址和端
口判断与用户已注册的 IP 地址和端口不一致，则 S-CSCF 会刷新用户的注册
信息，并将原有旧的 IP 地址用户注销。
• 呼叫场景下，被叫 S-CSCF 会将 Contact 头域中的信息填写在 Request-URI 中。
 UGC3200
UGC 会将收到消息 Contact 头域中的 IP 地址和端口号改为 ATS 网元的 IP 地址和端
口。
Issue 01 (2011-02-10) 华为技术有限公司 32

19. Privacy
Privacy 头域用于决定用户是否隐藏身份标识，一般是与 P-Asserted-Identity、From 来使
用。
Privacy 头域的消息样例如下示。
Privacy: none
Privacy 头域定义于 RFC 3323，协议中规定此头域的值有：
id 、none、header、session、user、critical。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 Privacy 头域的处理如下。
 ATS9900
ATS 会根据号码显示类业务对 Privacy 头域进行处理，这里不详细阐述。
 CSC3300
CSC 网元对于 Privacy 头域无特殊处理。
 UGC3200
在 SIP 与 ISUP 互通场景下，UGC 网元会根据 Privacy 头域中的值进行转换，具体
请参考统一维护资料之《IMS 互通类-IMS 与 CS 互通描述-维护指导手册.doc》。
20. Supported
Supported 头域用于列举所有 UAC 和 UAS 支持的 SIP 扩展方法。Supported 头域包含了
一个 option tag 的列表，表示这个 UAS 或者 UAC 所支持的 SIP 扩展方法。
Supported 头域的消息样例如下示。
Supported: 100rel, timer, in-band-dtmf, precondition
Supported 头域定义于 RFC 3261 20.37。
在 IMS 解决方案中，CSC3300、ATS9900、UGC3200 将根据该头域的值确定对端支持
的扩展方法。此头域的常见值有：100rel、timer、in-band-dtmf、precondition、history-
info 等。
21. Require
Require 头域用于 UAC 告诉 UAS 处理请求时需要 UAS 支持的扩展方法。如果 UAC 要
求 UAS 能够支持扩展，以便 UAS 能够处理 UAC 的特定请求，那么它必须在请求头中
增加一个 Require 头域来说明处理本特定请求需要什么样的一个扩展 option tags。此头
域一般与 Supported 头域同时使用。
Require 头域的消息样例如下示。
Require：100rel, timer
Require 头域定义于 RFC 3261 20.32。
22. Session-Expires
Session-Expires 头域用于指示会话刷新的时长。此头域只能放在 INVITE 或 UPDATE 请
求以及 INVITE 或 UPDATE 请求的 200 OK 响应中，一般用于 Session timer 会话心跳检
测机制中，该头域与 Min-SE 头域是同时使用的。此头域的最小值为 90s。
Issue 01 (2011-02-10) 华为技术有限公司 33
Session-Expires 头域的消息样例如下示。
Session-Expires: 1800; refresher=uac
Session-Expires 头域定义于 RFC 4028。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 Session-Expires 头域的处
理如下。
 ATS9900
收到的请求消息中，如果携带有 Session-Expires 头域和 Min-SE 头域，ATS 则会检
查消息中 Session-Expires 头域值是否在配置范围内（配置可参见 3.2.2），如果
Session-Expires 头域中的值小于配置的最小值，则回 Session Interval Too Small 响
应；因为 ATS 作为 B2BUA 的角色，发出的消息中 Session-Expires 值根据配置填写。
 CSC3300
CSC 网元会检查收到的消息中 Session-Expires 头域的值和 Min-SE 头域的值，如果
值小于 CSC 网元的配置值（配置可参见 3.2.2），则回 Session Interval Too Small 响
应；如果大于 CSC 网元的配置值，则透传。
 UGC3200
UGC 网元会检查收到的消息中 Session-Expires 头域的值和 Min-SE 头域的值，如果
值小于 CSC 网元的配置值（配置可参见 3.2.2），则回 Session Interval Too Small 响
应。
23. History-Info
History-Info 头域用于记录呼叫过程中目标被更改的信息。
History-Info 头域的消息样例如下示。
History-Info: <tel:+8676928050080>;index=1; <tel:+8676928050085>;index=1.1
History-Info 头域定义于 RFC 4244。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 History-Info 头域的处理如
下。
 ATS9900
ATS 对于 History-Info 头域的处理，主要应用于前转类业务，ATS 会将前转业务方
号码打包在第一跳中，即 index 为 1，将前转目的方号码打包放在第一跳之后。ATS
配置前转次数为 5,因此 ATS 会检查 History-Info 头域中的 Index 值，如果值大于
5， ATS 将拒绝呼叫。
 CSC3300
CSC 网元对于 History-Info 头域无特殊处理。
 UGC3200
在 SIP 与 ISUP 互通场景下，UGC 网元会根据 History-Info 头域转换为 ISUP，具体
请参考统一维护资料之《IMS 互通类-IMS 与 CS 互通描述-维护指导手册.doc》。
Issue 01 (2011-02-10) 华为技术有限公司 34

24. Reason
Reason 头域用于失败错误响应（如 3xx、456xx）中携带 Q850 失败原因值和状态码。在
ITUT Q850 协议中定义了 Reason 头域中的 Q850 原因值。
Reason 头域定义于 RFC3326。
在 IMS 解决方案中，CSC3300、ATS9900、UGC3200 等网元在回的错误响应中，会添
加上头域，指示失败原因。Reason 头域一般与 Warning 头域同时出现。
Reason 头域的消息样例如下示。
Reason: Q.850;cause=14;text="Subcriber ported",SIP;cause=410;text="Gone"
25. Warning
Warning 用于给应答的状态添加附加说明使用的。Warning 头域值是在应答中包含的，
并且包括了一个 3 位的警告代码，主机信息，和警告正文。
在 IMS 解决方案中，CSC3300、ATS9900、UGC3200、SBC 等网元主动释放呼叫时，
会在对应的错误响应中添加上该头域，以指示哪个网元发生错误。同时通过错误响应消
息中的 Warning 头域内容，也可以定位到该错误响应是哪个网元产生的。
Warning 头域的消息样例如下示。
Warning: 399 19804.7074.ATS.ats01.ims.huawei.com.20.337 "The callee is not registered"
Warning 头域的消息样例中，“399”表示 3 位的警告代码，在 IMS 发出的错误响应中，
该值一直是固定的。“19804.7074.ATS.ats01.ims.huawei.com.20.337”由主机部分生成，
包括内部模块文件代码、网元名、网元主机名等信息；“The callee is not registered”表
示产生错误的原因。因此判断错误响应消息的来源时，只需要看主机信息即可区分产生
失败响应的网元，需要注意的是，由协议栈产生的错误响应中，警告正文部分比较特
殊，警告正文部分以字符“SS”、“SSF”开始，
如下示。
Warning: 399 5.1.180.2 "SS060003F156L888[00000] Cancel received on initial invite"
Warning: 399 5.1.180.2 "SSF60003F156L888[00000] Cancel received on initial invite"
协议栈释放原因参考文档：
协议栈主动发请求
或应答的总结.doc
IMS 各网元错误响应消息 Warning 头域样例见表 1.1 示。

Warning 头域定义于 RFC 3261 20.43。
表1.1 IMS 各网元 Warning 头域样例表
Warning 头域样例网元
Warning: 399 P. ims.hw.com.261.006.301.0007-5815 "Top route P-CSCF

error"
Issue 01 (2011-02-10) 华为技术有限公司 35

Warning: 399 0513300840.I.ims.hw.com.260.005.116.04- I-CSCF

05.0140e. "Invalid User"
Warning: 399 S. ims.hw.com.261.006.302.001e-8100b.400100ea S-CSCF

"Route Address Not Found"
Warning: 399 19804.7074.ATS.ats01.ims.huawei.com.20.337 "The ATS

callee is not registered"
Warning: 399 CGPV1R2.SIPCOM "3398 UGC

SIPAPP_CR_ReleaseRecv 3079 Receive Sipsl Relealse msg."
Warning: 399 SE2X00 "SBC ReasonCode:2008" SBC
Warning: 399 MRFC

0448700241.MRFC.ims.hw.com.250.005.105.0000005E.0000000
0 "Apply mrfp fail"
26. Path
Path 头域用于注册过程中携带 P-CSCF 的域名信息、终端的 IP 地址和端口，以及 Dpt 参
数给 S-CSCF 网元，当用户做被叫时，S-CSCF 网元。
Path 头域的消息样例如下示。
Path: <sip:term@pcscf.ims.huawei.com;lr;IP=191.134.110.3;PORT=5061;Dpt=7672_86>
Path 头域定义于 RFC 3327。
在 IMS 解决方案中， CSC3300 网元对 Path 头域的处理如下。
 CSC3300
CSC3300 中的 P-CSCF 网元在发给 S-CSCF 网元的用户注册 REGISTER 消息中添加
Path 头域，Path 头域中填写的是 P-CSCF 的主机名，呼叫时当用户做被叫时，S-
CSCF 根据 Path 头域中的信息能够快速定位到 P-CSCF 网元。
27. Service-Route
Service-Route 头域用于注册过程中 S-CSCF 将自身信息携带给 P-CSCF，以便于呼叫时
的 P-CSCF 寻址。
Service-Route 头域的消息样例如下示。
Service-Route: <sip:orig@scscf.ims.huawei.com;lr;Dpt=7674_a35b1246;ca= ffffffff>
Service-Route 头域定义于 RFC 3608。
在 IMS 解决方案中，CSC3300 网元对 Service-Route 头域的处理如下。
 CSC3300
Issue 01 (2011-02-10) 华为技术有限公司 36

注册过程中，CSC3300 中的 S-CSCF 在发给 P-CSCF 的用户注册 REGISTER 响应

200 OK 消息中添加 Service-Route 头域，Service-Route 头域中填写的是 S-CSCF 的
主机名，呼叫时当用户做主叫时，P-CSCF 根据 Service-Route 中的信息，能够快速
定位到 S-CSCF。
28. P-Access-Network-Info
P-Access-Network-Info 头域是一个 3GPP 扩展头域，用于携带接入网信息，它向 IMS 网
络指示终端 UE 通过哪种技术接入到 IMS。
P-Access-Network-Info 头域的消息样例如下示。
P-Access-Network-Info: IEEE-802.11;"location-info=191.134.110.3"
P-Access-Network-Info 头域定义于 RFC 3455。
在 IMS 解决方案中，SBC、CSC3300、ATS9900 网元对 P-Access-Network-Info 头域的处
理如下。
 SBC
如果终端发送给 SBC 的注册 REGISTER 消息和初始 INVITE 消息中无 P-Access-
Network-Info 头域，SBC 会在发个 P-CSCF 的注册 REGISTER 消息和初始 INVITE
消息中添加上 P-Access-Network-Info 头域，P-Access-Network-Info 头域中包含有
SBC 域名信息和终端的 IP 地址信息。
 CSC3300
• 注册和呼叫场景下，如果终端发送给 P-CSCF 的注册 REGISTER 消息和初始
INVITE 消息中无 P-Access-Network-Info 头域，P-CSCF 会在发给 I-CSCF 的注
册 REGISTER 消息和初始 INVITE 消息中添加上 P-Access-Network-Info 头域，
P-Access-Network-Info 头域中包含有接入网类型和接入的 IP 地址信息。
• 紧急呼叫场景下，S-CSCF 会根据 P-Access-Network-Info 的 SBC 域名信息和终
端的 IP 地址信息来选择相应的紧急呼叫中心来路由。
 ATS9900
ATS 会将 P-Access-Network-Info 头域中的信息携带在话单的 AVP：
P_ACCESS_NETWORK_INFO 中。
29. P-Visited-Network-ID
P-Visited-Network-ID 头域是一个 3GPP 扩展头域，用于携带用户所在的拜访网络。
P-Visited-Network-ID 头域的消息样例如下示。
P-Visited-Network-ID: "pcscf.ims.hw.com"
P-Visited-Network-ID 头域定义于 RFC 3455。
在 IMS 解决方案中，CSC3300、ATS9900 网元对 P-Visited-Network-ID 头域的处理如下。
 CSC3300
注册场景下，如果终端发送给 P-CSCF 的注册 REGISTER 消息中无 P-Visited-
Network-ID 头域，P-CSCF 会在发给 I-CSCF 的注册 REGISTER 消息中添加上 P-
Access-Network-Info 头域，P-Visited-Network-ID 头域中为 P-CSCF 的域名信息。进
一步信息请参考《IMS 基本知识类-注册维护指导手册》。
Issue 01 (2011-02-10) 华为技术有限公司 37

 ATS9900
ATS 会将 P-Visited-Network-ID 头域中的信息携带在话单的 AVP：
P_VISITED_NETWORK_INFO 中。
30. P-Charging-Vector
P-Charging-Vector 头域是一个 3GPP 扩展头域，用于携带 IMS 计费 ID 和运营商标识。该
头域包含两个参数：ICID 值和 IOI 信息（包括 orig 和 term），其中，在一路会话中，
ICID 值是全局唯一的，IOI 信息与用户所在的运营商相关。
P-Charging-Vector 头域消息样例如下示。
P-Charging-Vector: icid-
value="467eff9d377cfc6d2ad9ae1b70613134.3509234699.82958.20";orig-
ioi=ims.hw.com;term-ioi=ims.hw.com
P-Charging-Vector 头域定义于 RFC 3455。
在 IMS 解决方案中，CSC3300、ATS9900 网元对 P-Charging-Vector 头域的处理如下。
 CSC3300
注册场景下，如果终端发送给 P-CSCF 的注册 REGISTER 消息中无 P-Charge-Vector
头域，P-CSCF 会在发给 I-CSCF 的注册 REGISTER 消息中添加上 P-Access-
Network-Info 头域，P-Visited-Network-ID 头域中为 P-CSCF 随即生成的 icid 信息。
 ATS9900
ATS 会将 P-Charge-Vector 头域中的 icid 信息携带在话单的 AVP：
IMS_CHARGE_IDENTIFIER 中，CCF 会根据此 AVP 关联整个呼叫过程的话单。
31. P-Charge-Function-Address
P-Charge-Function-Address 头域是一个 3GPP 扩展头域，用于携带计费功能地址。
在 IMS 解决方案中，此头域由 CSC3300 中的 S-CSCF 网元产生，携带的计费功能地址
一般为 IMS 域内的计费实体，如 CCF（离线计费）、ECF（事件计费）。
P-Charging-Function-Address 头域消息样例如下示。
P-Charging-Function-Addresses: ccf=ccf.ims.hw.com;ecf=ecf.ims.hw.com
P-Charging-Function-Address 头域定义于 RFC 3455。
32. P-Associated-URI
P-Associated-URI 头域是一个 3GPP 扩展头域，用于携带注册用户所关联的其他身份，
即 URI 信息。
P-Associated-URI 头域消息样例如下示。
P-Associated-URI: <sip:+8675581002020@ims.huawei.com>,<sip:
+8675581002020@ims.hw.com;user=phone>
注意：由于 P-Associated-URI 只为传递 SIP URI 而定义，因此他将包含的与注册用户有
关的 TEL URI 都使用 SIP URI 的格式来表示。
P-Associated-URI 头域定义于 RFC 3455。
Issue 01 (2011-02-10) 华为技术有限公司 38

在 IMS 解决方案中，CSC3300 网元对 P-Associated-URI 头域的处理如下。

 CSC3300
注册场景下，S-CSCF 在发送给 P-CSCF 的注册 REGISTER 响应 200 OK 消息中添
加上 P-Associated-URI 头域，P-Associated-URI 头域中为该注册用户的开户的
IMPU 信息。
33. P-Preferred-Identity
P-Preferred-Identity 头域是一个 SIP 扩展头域，用于终端携带自身注册的公共用户身份
给代理服务器。
在 IMS 解决方案中，此头域应用于呼叫场景中，CSC3300 中的 P-CSCF 的网元将构造
P-Asserted-Identity 头域替代此头域，并带给 S-CSCF 网元。
P-Preferred-Identity 头域消息样例如下示。
P-Preferred-Identity: <sip:+8675581002020@ims.hw.com>
P-Preferred-Identity 头域定义于 RFC 3325。
在 IMS 解决方案中，CSC3300 网元对 P-Preferred-Identity 头域的处理如下。
 CSC3300
呼叫场景下，P-CSCF 根据终端发送给 P-CSCF 的初始 INVITE 消息携带的 P-Preferred-
Identity 头域中的 IMPU 信息，构造 P-Asserted-Identity 头域，携带在发送给 S-CSF 的
INVITE 消息中。
34. P-Asserted-Identity
P-Asserted-Identity 头域是一个 SIP 扩展头域，用户携带用户的真实用户身份给代理服
务器。此头域中可以包含一个或两个身份标识，一个为 TEL URI，另一个为 SIP URI。
P-Asserted-Identity 头域消息样例如下示。
P-Asserted-Identity: <sip:+8675581002020@ims.huawei.com>,<tel:+8675581002020>
P-Asserted-Identity 头域定义于 RFC 3325。
在 IMS 解决方案中，ATS9900、CSC3300、UGC3200 等网元对 P-Asserted-Identity 头域的
处理如下。
 ATS9900
ATS 收到的初始响应 INVITE 消息后，则从 P-Asserted-Identity 头域中获取主叫号
码。在被叫侧 ATS，ATS 会根据号码显示业务对 P-Asserted-Identity 头域中的主叫号
码进行调整。
 CSC3300
CSCF 收到的初始响应 INVITE 消息后，如果 INVITE 消息中无 P-Served-User 头域，
则从 P-Asserted-Identity 头域中获取主叫号码,去 HSS 上下载用户数据。
 UGC3200
UGC 收到的初始响应 INVITE 消息后，从 P-Asserted-Identity 头域中获取主叫号码，
在 SI 与 ISUP 互通场景下，UGC 将 P-Asserted-Identity 头域中的号码转换为 Caller
Issue 01 (2011-02-10) 华为技术有限公司 39

Number，具体 SIP 与 ISUP 消息转换，请参考统一维护资料之《IMS 互通类-IMS 与

CS 互通描述-维护指导手册.doc》。
35. P-Profile-Key
P-Profile-Key 是一个 3GPP 扩展头域，用于携带 Proxy 查询用户数据使用的关键信息。
P-Profile-Key 头域消息样例如下示。
P-Profile-Key: <sip:+867558100!.*!@ims.hw.com>
P-Profile-Key 头域定义于 RFC 5002。
在 IMS 解决方案中，此头域主要用于 PBX 的通配 IMPU 方案。
2.2.3 重要头域参数
SIP 协议中某些头域携带了一些关联对话等重要参数，主要有 branch 和 tag 两个参数。
36. branch
Via 头域的一个参数，用于表示一个唯一的事务；以魔鬼数字 z9hG4bK 开头，样例如
下示。
Via: SIP/2.0/UDP 5.1.182.18:5061;branch=z9hG4bKuild4yuuf4gltvsutmwsdwtyw
;Role=3;Dpt=7684_16;TRC=b5c-ffffffff,
37. tag
tag 用于 From，To 头域；From Tag, To Tag 和 Call-ID 一起表示一个对话，样例如下示。
From: “81002020”<sip:+8675581002020@ims.hw.com>;tag=45f84802
2.3 SIP 呼叫路由机制

SIP 的路由机制主要包括响应消息的路由和请求消息的路由。
2.3.1 响应消息路由
SIP 响应经过的路径和请求完全相同，SIP 请求消息每经过一个节点，每个节点都会将
自身地址添加到请求消息的 VIA 头域顶端。
Issue 01 (2011-02-10) 华为技术有限公司 40

图1.1 响应消息的路由
UAS 将请求中的 Via 地址原样拷贝到响应里面，当 Proxy 接收到响应时，检查顶端的

Via 是否是自己，如果是，将顶端的 Via 删除，并检查下一个 Via 地址，将响应发送到
下一个 Via 地址，如果没有下一个 Via 地址，则表示这个响应应此到此终结。
2.3.2 请求消息路由
对于 SIP 请求消息的路由，需要了解 Record-Route、Route、Contact 这几个头域的使用机
制。需要了解 UAC、UAS 是如何维护自己的路由集的。
图1.2 请求消息路由样例 1
SIP 初始请求消息可能会经过很多的 Proxies，可能是通过 DNS 查询，也可能是预配置

的路由。对于后续的请求，没有必要经过初始请求经过的每个 Proxies。如上图，UA1 呼
Issue 01 (2011-02-10) 华为技术有限公司 41

叫 UA2，初始 INVITE 请求经过了 Proxy1、Proxy2、Proxy3。为了节省路径，后续请求可

以不经过 Proxy2，直接走 Proxy1、Proxy3；
中间 Proxy 可以根据自身策略决定后续请求是否需要经过自己，如果需要，则中间
Proxy 需要在请求中插入 Record-Route 头域，这个头域包含了自己的地址，如果不需要，
则不用插入 Record-Route 头域。Record-Route 头域与 Via 头域类似，是一个栈结构。
当 UAS 收到请求消息后，将请求消息中的 Record-Route 头域保存为自己的路由集，将
请求消息中的 Contact 作为 Remote Target，并在响应消息中将 Record-Route 头域带回给
UAC。当 UAC 收到响应消息后，将 Record-Route 头域保存的地址反序保存为自己的路
由集，将响应消息中的 Contact 作为 Remote Target。
当 UA 需要发起后续请求时，将 Remote Target 作为 Request-URI，并将将生成的路由集
拷贝到 Route 头域中，如果存在 Route，则将请求路由到 Route 的第一个值；否则将请
求路由到 Remote Target.。
当 Proxy 收到后续请求，检查最顶端的 Route 是否是自己，如果是，则将其删除；检查
是否还有 Route，如果有，则将请求路由到 Route 的第一个值，如果无，则将请求路由
到 Request-URI 指向的值。如下图所示（图中 m 是 Contact 头域缩写，RR 是 Record-
Route 头域缩写）
如上图，通过 INVITE 及 200 响应的交互，主被叫确定了自己的路由集，后续请求就可以按

照路由集进行路由了，如下图所示 BYE 请求路由情况。
Issue 01 (2011-02-10) 华为技术有限公司 42

2.4 SIP 协议在 IMS 中的应用

SIP 协议是 IMS 控制层协议，是用于建立、改变或结束多媒体会话的应用层协议，与
RTP/RTCP、SDP、DNS 等协议配合，共同完成 IMS 中的会话建立及媒体协商。IMS 中主
要应用于 Mw、Ut、ISC、Mi、Mg、Mj、Mk、Mr 等接口，SIP 协议在 IMS 中的应用如下图
示所示。
图1.5 SIP 协议在 IMS 中的应用
Issue 01 (2011-02-10) 华为技术有限公司 43

SIP 协议栈是 IMS 解决方案中各网元处理 SIP 协议的组件平台，SIP 协议栈的架构如下

图示。目前 ATS9900、CSC3300、UGC3200 等网元使用的协议栈都是基于中央软件平台
的 VPP SIP 组件。
SIP 协议承载在 IP 网，网络层协议为 IP，传输层协议可用 TCP 或 UDP，目前 IMS 解决
方案中，商用局中推荐使用 UDP 协议。
图1.6 SIP 协议栈
2.5 SIP 消息分发机制

在 IMS 解决方案中，各网元信令上都是通过 SIP 消息来进行协商的，下文将介绍
ATS9900、CSC3300、UGC3200 等网元 SIP 消息分发机制。
2.5.1 ATS9900 SIP 消息分发

从消息处理上看，ATS9900 收到 SIP 消息后需要进行二级分发，ATS9900 SIP 消息模块
间分发示意图如下示。
Issue 01 (2011-02-10) 华为技术有限公司 44

图1.7 ATS9900 SIP 消息模块间分发示意图
IP 报文下行的分发处理，是使用 DPU Kernel 实现。DPU Kernel 是 IFM 模块的一部分，

DPU Kernel 是使用 Linux 操作系统中的 Netfilter 机制实现。
一级分发是指由 IFM 模块/DPUKernel 到 MSG 模块/BSG 模块（SIP 消息的分发不涉及

BSG 模块），一级分发又分为：
• 上行分发（IFM → MSG）
P1、P2：IFM 模块收到初始 SIP 请求消息后，首先根据 Call-ID 去查询 HASH 记录
表，如果查询到记录则将消息分发至对应的 MSG 模块，否则，IFM 将根据 MSG
的 CPU 占用率轮选一个 MSG 模块。
P8、P9：后续收到响应消息后，DPU Kernel 根据 Top Via 头域中的端口号选择到
MSG 模块。实际上，下行分发时，ATS 会在 Via 头域中添加上 MSG 模块
对应的端口号。
• 下行分发（MSG → IFM/DPU Kernel）
P6、P12：MSG 模块收到 CCU 模块的请求消息后，不需要选择 IFM 模块，消息直
接从 DPU Kernel 发送出去。
二级分发是指由 MSG 模块到 CCU 模块/CXU 模块，二级分发又分为：
• 上行分发（MSG → CCU/CXU）
Issue 01 (2011-02-10) 华为技术有限公司 45

P3、P4：MSG 模块收到初始 SIP 请求消息后，MSG 模块根据用户 IMPU 去 CDB 查

询 CCU/CXU 模块号和 USN 号。用户注册时，CDB 模块会给此用户分配分发记录，
即用户所在的 CCU/CXU 模块号和 USN 号。因此，如果查询到此用户存在分发记
录，则 MSG 模块将消息发给用户所在的 CCU 模块号；如果查询不到用户的分发
记录，则 CDB 模块根据各 CCU/CXU 的负载情况，给此用户分配一个 CCU 模块和
此 CCU/CXU 模块上一个空闲的 USN 号，返回给 MSG，MSG 根据返回结果将消
息分发到 CCU/CXU 模块。
对于非初始事物请求，MSG 根据从消息 From/To 头域中 tag 参数取出 CCU 模块号，
直接分发指定的 CCU 进程上去。ATS9900 发出的 SIP 消息在 TO 或者 FROM 头域
tag 参数中包含处理此呼叫的 CCU 进程的模块号，例如 ATS9900 发出的 INVITE 消
息：
From: <sip:+867556650001@ims.hw.com>;tag=yegwvwrx-CC-201-TRC-51457
P10：后续收到响应消息后，MSG 根据下行分发时保存的 CCU/CXU 模块号，来进
行上行分发。
• 下行分发（CCU/CXU → MSG）
P5、P11：CCU/CXU 模块对于下行分发是根据 MSG 模块的负载平衡原则，选择一
个 CPU 占用率小的 MSG 来进行轮选分发的。
2.5.2 CSC3300 SIP 消息分发

CSC3300 的 SIP 消息分发机制与 ATS9900 的处理机制不同，CSC3300 会根据内部处理
决定是否需要 SCU 模块进行二次分发处理。CSC3300 SIP 消息模块间分发示意图如下示
（以 P/I/S 合设为例）。
图1.8 CSC3300 SIP 消息模块间分发示意图
CSC3300 的消息分发主要基于消息中的 Dpt 参数，通过 Dpt 参数可以获得 SCU 模块号，

Dpt 参数获取原则如下。
如果消息是 SIP 请求，则搜索消息中的 Top Route 头域的 Dpt 参数；如果消息是 SIP 响
应，则搜索消息中的 Top Via 头域的 Dpt 参数。
P1、P2：DPU 模块收到 SIP 消息后，如果是 SIP 初始请求，则根据 IP + Port 查询分发表，
查询成功则分发到对应 SCU，并通过内部端口标识为需要 SCU 进行二次分发；查询失
败，则轮选一个 SCU 模块，插入临时记录，分发到对应 SCU，并通过内部端口标识为
Issue 01 (2011-02-10) 华为技术有限公司 46

需要 SCU 进行二次分发；如果是非初始请求，则根据上述 Dpt 参数获取原则，从 Dpt

参数中获取 SCU 模块号，分发给对应 SCU，并标识为不需要 SCU 进行二次分发；如
果是 SIP 响应，则根据上述 Dpt 参数获取原则，从 Dpt 参数中获取 SCU 模块号，分发
给对应 SCU，并标识为不需要 SCU 进行二次分发。
在 P/I/S 分设的情况下，I-CSCF 的分发是根据消息中的 Call-Id 查询 Hash 表得到 SCU 模
块号的。
P3、P4：此步骤描述 SCU 进行二次分发处理的过程，对于非初始请求，则不需要进行
二次分发处理。CDB 收到 SCU1 的查询请求后，根据用户 IMPU 查询 IMPU 分发表，查
询成功则返回查询响应并携带查询到的 SCU 模块号；查询失败则优选发送消息的 SCU
模块号。
P5：如果查询到的 SCU 模块号与本模块号一致，则将消息分发到本 SCU 业务模块；否
则，将消息到对应的 SCU 模块。
P6、P7：SCU 将消息发给 DPU。
2.5.3 UGC3200 SIP 消息分发

从消息处理上看，UGC3200 收到 SIP 消息后需要进行二级分发，UGC3200 SIP 消息模
块间分发示意图如下示。
图1.9 UGC3200 SIP 消息模块间分发示意图
一级分发是指由 IFM 模块/DPUKernel 到 BSG 模块/MSG 模块（SIP 消息的分发不涉及

MSG 模块）。
Issue 01 (2011-02-10) 华为技术有限公司 47

P1、P2：IFM 模块收到初始 SIP 请求消息后，根据 BSG 模块的负载情况选择一个 BSG

模块，并保存 Call-ID 与选择的 BSG 模块的对应关系。
P3：BSG 模块收到消息后，根据 CCU 模块负载情况轮选一个 CCU 模块，并通过 TXN
上下文 ID 将 BSG 模块号带给 CCU，通过 TU 层和 TXT 上下文关联 ID 来绑定后续响应
消息。
P4：CCU 收到消息处理完成后，根据 BSG 模块负载情况轮选一个 BSG 模块，并将
CCU 模块号耦合进 To 头域的 Tag 参数中，Contact 头域中设置端口号为 SIP 知名端口号
（一般取 SIP 协议的知名端口号 5060）。
P5、P6：BSG 模块根据本地 IP 地址和端口确定 IFM 模块号，并将消息发给该 IFM 模块，
通过 DPU Kernel 转发出去。
P7、P8：后续收到响应消息，IFM 根据 Via 头域中的 X-DispMsg 参数的到 BSG 模块，
并将消息发给该模块。
P9：BSG 模块根据 P10 处理中的 TU 层和 TXT 上下文关联来获取 CCU 模块号，并将消
息发给该 CCU 模块。
P10：当 CCU 模块需要回响应消息时，根据 P3 处理中的 TU 层和 TXT 上下文关联来获
取 BSG 模块号，并将消息发给该 BSG 模块。
P11、P12：BSG 模块根据本地 IP 地址和端口确定 IFM 模块号，并将消息发给该 IFM 模
块，通过 DPU Kernel 转发出去。
2.6 常见 SIP 流程
下面主要讲解 IMS 中涉及的常见 SIP 流程。
2.6.1 用户注册注销流程
38. 注册流程
注册消息中关键头域包括 From、To、Contact 及 Expire，其他头域请参考“SIP 请求消息
类型”一节。用户注册基本流程详细描述，请参考统一维护资料之《IMS 业务类-注册注
销-维护指导手册.doc》。
39. 注册鉴权流程
在 IMS 解决方案中，最常用的鉴权方式有：HTTP Digest 鉴权、SIP Digest 鉴权（MD5
鉴权）。HTTP-DIGEST 鉴权流程如图 2-21 示。注册鉴权流程详细描述，请参考统一维
护资料之《IMS 业务类-注册注销-维护指导手册.doc》。
40. 注销流程
请参考统一维护资料之《IMS 业务类-注册注销-维护指导手册.doc》。
2.6.2 用户基本呼叫流程
用户基本呼叫需要区分有鉴权和没有鉴权的场景，用户基本呼叫鉴权方式采用的是
HTTP-DIGEST 方式鉴权（参考 RFC 2617），与注册鉴权类似，只有用户密码正确及
源 IP 地址与注册 IP 地址相同才允许呼叫。在 IMS 解决方案对用户发起的呼叫是否鉴权
Issue 01 (2011-02-10) 华为技术有限公司 48

取决于 S-CSCF 网元的配置，与注册鉴权配置相同。不同的是，注册鉴权，鉴权响应是

401 消息，而基本呼叫鉴权，IMS 回的鉴权响应消息是 407 消息。
SIP 用户基本呼叫流程图如图 2-22 示，此流程图为没有鉴权的场景，主要描述主叫侧
流程。
图1.1 SIP 用户基本呼叫流程
在 IMS 解决方案中，IMS 域内基本呼叫主要处理网元为 CSC3300、ATS990，与 CS 域的

互通基本呼叫主要处理网元为 CSC3300、ATS990、UGC3200，UGC3200 处理部分请参
考统一维护资料之《IMS 业务类-IMS 与 CS 互通-维护指导手册.doc》。基本呼叫中，
CSC3300、ATS9900 对消息中主要关注的头域、请求行，如下图示。
关于基本呼叫流程及 IMS 中各网元详细处理描述，请参考统一维护资料之《IMS 业务
类-号码分析与路由-维护指导手册.doc》
Issue 01 (2011-02-10) 华为技术有限公司 49

图1.2 基本呼叫关键头域
头域网元作用描述
Request-URI CSC3300 1、携带被叫号码信息；

ATS9900 2、ATS9900 根据配置将其调整为
全局格式号码
UGC3200
From ATS9900 1、用于主叫号码显示

UGC3200 2、 ATS9900/UGC3200 从 tag 参数
中解析 CCU 模块号
Contact CSC3300 用于请求消息的后续路由，如

UPDATE、Prack 等
ATS9900
UGC3200
Via CSC3300 1、用于消息的后续路由；

ATS9900 2、CSC3300 从中解析 SUC 模块号
UGC3200 3、UGC 从中解析 CCU/MSG 模块
号
Route/Record-Route CSC3300 1、用于请求消息后续路由；

ATS9900 2、CSC3300 从中解析模块号
UGC3200
P-Preferred-Identity CSC3300 P-CSCF 根据此头域获取用户公用

身份，使用 P-Asserted-Identity 头
域替换该头域。
P-Asserted-Identity CSC3300 1、从此头域中获取主叫号码信息；

ATS9900 2、用于主叫号码显示。
UGC3200
P-Charge-Vector CSC3300 用于获取计费话单中的 icid 信息

ATS9900
UGC3200
P-Access-Network-Info CSC3300 用于携带接入网相关信息

ATS9900
Issue 01 (2011-02-10) 华为技术有限公司 50

2.6.3 媒体协商
通讯信息是通过语音、数据、传真、视频等来转递的，通常我们将语音、数据、传真、视频
等称之为媒体，IMS 作为软交换设备要完成一个呼叫的接续和建立，需要参与通讯端
点之间的媒体处理和协商。
既然有媒体，就涉及媒体的表示及协商。
41. 媒体的表示
SIP 基本呼叫中媒体的表示是通过 SDP（Session Description Protocol）协议描述的，主
要可以参考 RFC 2327。媒体主要包括如下信息
 媒体类型（比如音频 audio、视频 video、数据、传真 fax 等）
 传输协议（比如 RTP/UDP/IP 等）
 编解码（比如 G711a、G711u、G723、G729 等音频编解码和
H.261 、H263、H264、MPEG 等视频编解码等）
 媒体收发 IP 地址及端口
 打包时长
图1.1 SDP 媒体描述样例
Issue 01 (2011-02-10) 华为技术有限公司 51

在此不讲述所有的参数的描述方法，主要描述几个重要的参数，见上图中标注的红色
方框。通常需要关注一下几个方面：
 关注媒体类型，主要是音频 audio、视频 video 等。
 关注 RTP 包收发 IP 地址及端口，当遇到呼叫类问题需要抓取 RTP 包分析时，往往
需要检查 RTP 包发送的源及目的地址是否与 SIP 信令中 SDP 协商的地址、端口一
致。
关注使用的编解码，主被叫是否协商到相同的编解码，每一个编解码对应一个
Payload Type 值，Payload Type 值分静态 Payload Type 和动态 Payload Type 两类，
值在 0～95 之间为静态；值在 96～127 之间为动态。对于静态编解码，协议规定
其对应一个固定的 Payload Type 值，比如上图中的 PCMA 编码对应 8，PCMU 对
应 0；对于动态编解码，Payload Type 值没有固定，只是每次呼叫中从 96~127 中
选择一个即可，比如上图中的 telephone-event（即 DTMF---2388，参见 RFC
2833）的 Payload Type 值为 101，即为动态的。更多信息请参考 RFC 3551。
 关注打包时长，很多呼叫类问题可能是因为主被叫打包时长不一致所致。
 关注媒体方向，媒体方向有四种取值：sendrecv（既发既收）、sendonly（只发送）
recvonly（只接收）、inactive（不发不收）。
42. 协商机制
媒体协商是通过 O/A（offer/Answer）机制保证的，在 RFC 3264 中有描述。
图1.1 媒体协商 O/A 模型
SDP 协议只描述了媒体的表述，SIP 呼叫传送 SDP 到对端是通过 SIP 消息完成的。对于

响应消息，协议规定只有可靠的临时响应和成功的最终响应才能携带媒体。
Offerer 向对端提供 SDP，其中包含自己支持的媒体，可以是 INVITE、200、UPDATE 等
消息；Answer 根据 Offer 选择自己能够支持并且愿意使用的媒体流以及媒体流的参数，
并向对端返回 SDP，完成媒体协商过程，可以是可靠 18X、200、ACK 等消息。
当呼叫参与方需要增加媒体、删除媒体、修改 IP 地址或端口、使用其他编解码、修改媒体
类型及修改媒体属性等行为时就可以向对方发起一次 Offer。
SIP 消息完成媒体协商的消息组合有：
 INVITE 和可靠 18X(INVITE)消息携带 SDP 完成媒体协商。
 可靠 18X(INVITE)和 PRACK 消息携带 SDP 完成媒体协商。
 INVITE 和 200(INVITE)消息携带 SDP 完成媒体协商。
 200(INVITE)和 ACK 消息携带 SDP 完成媒体协商。
 PRACK 和 200(PRACK)消息携带 SDP 完成媒体协商。
Issue 01 (2011-02-10) 华为技术有限公司 52
 UPDATE 和 200(UPDATE)消息携带 SDP 完成媒体协商。

上面媒体协商消息组合，在 IMS 中都支持。媒体协商详细描述请参考统一维护资料之
《IMS 协议类-媒体协商-维护指导手册.doc》
===========================
RFC3261 中的相关协议依据
以下协议内容均来自 RFC 3261 13.2.1
In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The
usage of offers and answers is further restricted. For the initial INVITE transaction, the rules are:
o The initial offer MUST be in either an INVITE or, if not there,in the first reliable non-failure message
from the UAS back to the UAC. In this specification, that is the final 2xx response.
上面协议部分说明了：
初始请求必须在 invite 或者第一个非失败的可靠响应中。可以匹配到下列媒体协商消息对：
INVITE 和可靠 18X(INVITE)消息携带 SDP 完成媒体协商。
可靠 18X(INVITE)和 PRACK 消息携带 SDP 完成媒体协商。
INVITE 和 200(INVITE)消息携带 SDP 完成媒体协商。
200(INVITE)和 ACK 消息携带 SDP 完成媒体协商。
也同时说明，如果 invite 不携带 SDP，如果有 18X 响应并且可靠，则 18X 必须携带 SDP，否则
不符合协议上述描述。同时下面结论也是成立的：
如果 invite 不携带 SDP，18X 不可靠，则 200（invite）必须携带 SDP。
o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS
back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response
to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the
answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial INVITE.
这句话说明如果初始请求在 invite 中，响应必须在非失败的响应中。说明了下列媒体协商消息对：
INVITE 和可靠 18X(INVITE)消息携带 SDP 完成媒体协商。
INVITE 和 200(INVITE)消息携带 SDP 完成媒体协商。
o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer
MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response).
假如初始请求是非失败的可靠响应，那么 answer 必须在这个响应的确认消息中。
这句话说明了下列媒体协商消息对：
可靠 18X(INVITE)和 PRACK 消息携带 SDP 完成媒体协商。
200(INVITE)和 ACK 消息携带 SDP 完成媒体协商。
o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in
requests based on rules specified for that method, but only if it has received answers to any previous offers,
and has not sent any offers to which it hasn't gotten an answer.
在第一个 offer 应答完成后，UAC 才可以发送后续 offer。
这句话的意思可引申如下：如果 invite 和可靠的 18X 完成了媒体协商，UAC 可以使用下列消息对
进行媒体重协商。
PRACK 和 200(PRACK)消息携带 SDP 完成媒体协商。
UPDATE 和 200(UPDATE)消息携带 SDP 完成媒体协商。
Issue 01 (2011-02-10) 华为技术有限公司 53

o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent
offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can
never generate subsequent offers until completion of the initial transaction.
一旦 UAS 发送 offer 请求或者接受了 answer 后，UAS 不能在初始 invite 的响应中发送 offer。
UAS 只能在 invite 事务结束后才能发起媒体改向。这句话的意思可引申如下：如果 INVITE 和可
靠的 18X 完成了媒体协商，200（invite）再携带媒体是非法的。
2.6.4 临时响应可靠传输流程
SIP 协议 RFC 3261 中定义，非 100 类临时响应消息的传输是不可靠的，即 UAS 发送临
时响应后并不能保证 UAC 能够接收到该消息，非 100 类临时响应消息允许丢失。如果
需要在该响应消息中携带媒体信息，那么就必须保证该消息能够可靠的传输到对端。所
以在 RFC 3262 里制定了临时响应的可靠性传输机制，引入了“100rel”的协商机制，通
过 Supported 和 Require 头域来实现。同时引入 PRACK，200（PRACK）消息。
图1.2 支持 180 可靠传输流程样例
上图即为支持 180 可靠传输的呼叫流程。临时可靠响应消息可以由 UAC 发起，也可以

由 UAS 发起。
1. UAS 发可靠临时响应的条件：
 如果 UAS 收到的初始 INVITE 消息包括头域 Supported:100rel，UAS 就可以发一个
可靠临时响应。
 如果初始 INVITE 包括头域 Requier:100rel，UAS 就必须发一个可靠临时响应，如
果 UAS 不支持这种功能就回 420 响应消息。
 可以可靠发送的临时响应只能是 101－199，100 应答不可以。原因是 100 应答只能
是逐跳的，而可靠临时响应机制是端到端的，
Issue 01 (2011-02-10) 华为技术有限公司 54

 如果对端的请求没有携带 Supported 头域或 Require 头域，或者携带了这两个头域，

但在这两个头域里没有表明可靠临时响应这种特性，就是没有 100rel，UAS 不能
发送可靠临时响应。
 如果一个 UA 作为 PROXY，也可以发可靠临时应答，但不能为同一个对话里的请
求回 100rel 应答。
 如果对话里第一个可靠临时应答没有匹配上 PRACK，就不能发第二个可靠临时应
答。第一个之后就没有这种限制，但协议建议最好是等前一个可靠临时应答被承认
后再发第二个可靠临时应答。
UAS 发送可靠的 1XX 临时响应时，必须携带 Require 头域和 Rseq 头域，Rseq 的取值范

为：1～2 的 31 次方－1，同时必须是单步递增的，此值的作用范围为一个事务，意思
是说，对于不同请求的可靠临时响应，其 Rseq 的值可以相同。
另外在一个可靠的临时应答没有回 PRACK 前，UAS 可以为初始 INVITE 请求回非
2XX 应答。
2. 如果 UAC 想要对端发送可靠临时响应消息，需要在初始化 INVITE 请求里包括

Require:100rel。当客户端收到可靠的临时响应时，需要回应 PRACK 消息，PRACK
消息必须携带 Rack 头域，此头域包括两个数字码和一个方法，第一个数字码为对
应可靠临时响应的 Rseq 中的数字码，后面的数字码和方法是可靠临时响应的的
Cseq 值。
3. 临时响应可靠传输的引入同时，引入了新的媒体协商 O/A 交互，媒体协商概念请
参考节。
 如果 UAC 收到一个带 OFFER 的可靠的临时响应，它必须在相应 PRACK 中产生一
个 ANSWER，IMS 目前不支持此功能。
 如果 UAC 收到一个带 ANSWER 的可靠的临时响应，它可以在相应 PRACK 中产
生另外一个 OFFER，IMS 目前只支持收到带 ANSWER 的可靠临时响应，不支持
在相应的 PRACK 中产生另外一个 OFFER。
 如果 UAS 收到一个带 OFFER 的 PRACK，它必须在相应 PRACK 的 200 响应中产
生一个 ANSWER。
2.6.5 UPDATE 流程
UPDATE 方法是在 RFC 3311 中引入的，主要用于在早期对话中更新会话参数，比如更
新媒体流中的编解码、媒体流方向等，在早期对话中，主叫或被叫可以多次发送
UPDATE 更新媒体。通话后，主叫或者被叫也可以发送 UPDATE 更新媒体，不过协议
不建议这样使用，因为通话后一般使用 Re-INVITE 更新媒体。另外 UPDATE 可以作为
Session timer 心跳检测消息使用，请参考 2.6.7。
Issue 01 (2011-02-10) 华为技术有限公司 55

图1.3 UPDATE 流程样例
如上图，当 INVITE 消息携带主叫媒体，18X 消息携带媒体并且支持可靠传输，则

INVITE、18X 完成了一次媒体协商，在收到被叫的最终响应（2XX～6XX 消息）之前，
如果主叫或者被叫需要更新媒体，则必须发送 UPDATE 消息来达到此目的。
2.6.6 re-INVITE 流程
在已经存在的对话中发送的 INVITE 请求消息称为 re-INVITE 消息。它与初始 INVITE
消息的区别是 re-INVITE 消息中 To 头域存在 Tag 参数，而初始 INVITE 的 To 头域不存
在 Tag 参数。
通话建立后，主叫或者被叫需要修改媒体，可以通过发送 Re-INVITE 携带新的媒体再
次进行媒体协商，协商主要有两种方式：INVITE 和 200 完成协商、200 和 ACK 完成协
商。
 INVITE 和 200 完成协商
Issue 01 (2011-02-10) 华为技术有限公司 56

图1.4 Re-INVITE-200 协商
 200 和 ACK 完成协商
图1.5 200 和 ACK 完成协商
唯一区别是 INVITE 不带 SDP，200 和 ACK 携带 SDP，不再赘述。
2.6.7 SIP 心跳机制

SIP 心跳分为 OPTION 心跳和 Session timer 心跳，即设备级心跳和会话级心跳。
在 IMS 解决方案中，SIP 心跳主要应用于以下场景。
• OPTION 心跳应用于容灾场景，保证设备之间通信正常。
• Session timer 心跳应用于呼叫会话保活场景，避免呼叫吊死。
SIP 心跳相关配置，请参考 3.1 节所示。
43. OPTION 心跳
OPTION 心跳即设备级心跳，在与其他厂商对接时，建议都打开，但是打开前需要对
方确认支持此功能。
Issue 01 (2011-02-10) 华为技术有限公司 57

在 IMS 解决方案中，使用设备级心跳探测 IMS 设备之间通信是否正常，检测路由是否

可用，以便为呼叫选择路由提供依据。当设备间通信或链路故障后，可以选择其他状态
正常的设备来完成呼叫。
设备级心跳有两种方式：一种是周期性的设备级心跳，即网元每隔固定的时间向对端
发送 OPTION 消息进行检测，如图 1.1；一种是启发式的设备级心跳，即给对端发送
INVITE 消息后，无响应或超时，网元首先发 OPTION 进行确认，如果仍然无响应，则
认为对端故障，如图 1.2。启发式的设备级心跳一般应用于容灾场景中。
图1.1 周期性的设备级心跳
图1.2 启发式的设备级心跳
图 1.1，ATS9900 每个一定间隔给 CSC3300 发送 OPTION 消息。在 IMS 解决方案中，可

以配置是否发送心跳，如果配置不发送心跳，则此表示设备之间的通信永远是可用的，
即使网络已经故障；当配置使用心跳后，IMS 会每隔一定间隔(可配置)发送 OPTION 消
息给对端网元，只要收到响应（除 408、504 外）都认为对端状态正常。如果收不到任何
响应或者收到 408、504 响应，则认为对端状态故障。
OPTION 心跳消息样例：
OPTIONS sip:160.29.1.4:5060 SIP/2.0
Via: SIP/2.0/UDP 160.28.1.8:5061;branch=z9hG4bKb001b3471
Call-ID: 662261a8583794c7f9c34fde094c9912@160.28.1.8
From: <sip:160.28.1.8:5061>;tag=842f3e0c
To: <sip:160.29.1.4>
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0
Issue 01 (2011-02-10) 华为技术有限公司 58
粗体部分为对端地址。
CSC3300、ATS9900 其中之一可以是其他厂商设备，也可以为 SIP 终端，IMS 与 SIP 终
端之间的呼叫也是可以发送 OPTION 消息检测是否终结。
44. Session timer 心跳

Session Timer 功能主要用于 SIP 会话保活，即周期性的给对端发送一个 re-Invite 或
Update，来侦测对端是否已经终结。这样可以避免网络故障 BYE 消息丢失后，呼叫吊
死情况的发生，流程图请参考 Error: Reference source not found。Seesion timer 机制请参
考 RFC 4028。
Session timer 心跳引入了“timer”标签的协商机制，通过 Supported 和 Require 头域实现，
同时新增 Session-Expires、Min-SE 两个头域，通过这两个头域可以实现 Session timer 心
跳时长的协商。下面先介绍这两个关键头域、timer 标签及 422 响应功能。
 Session-Expires 头域
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds *(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
功能说明：此头域用于传送会话刷新的时间间隔以及进行刷新协商。可以在
Invite 、Update 及其 2XX 应答中。头域中最小时间间隔为 90 秒。
 Min-SE 头域
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
功能说明：此头域用于指示最小的会话刷新间隔。此值最小为 90 秒。除 422 应答外，
其他的应答中严禁包括此头域。
 timer 标签
用于指示是否支持会话刷新功能。如果 UAC 支持此功能，应此在除 ACK 之外的每个
请求的 Supported 头域中增加‘timer’标签，不建议在 Require 中增加，此功能只需要
UAC 或 UAS 一端支持即可完成会话刷新。
 422（Session Interval Too Small）应答
功能说明：UAS 或 Proxy 指示收到请求中的 Session-Expires 所指定的刷新时间小于本
地可以接收的最小值，此应答中必须包括 Min-SE 头域。
Issue 01 (2011-02-10) 华为技术有限公司 59

图1.1 Session timer 心跳
注：上图中画出主叫侧相关流程，SIP UE、ATS9900 支持 Session timer 功能，CSC3300

的 Session timer 功能关闭。
在 IMS 解决方案中，ATS9900 作为 B2BUA，其角色可以是 UAC，也可以是 UAS。对于

主叫终端来说，主叫侧 ATS9900 是 UAS，对于被叫侧来说，主叫侧 ATS 是作为 UAC。
在 ATS9900 网元 Session timer 功能开启情况下，不论终端是否支持 Session timer 功能，
ATS 都会向两侧发送 UPDATE/re-INVITE 来进行 Session timer 检测。
如上图所示消息，SIP UE 发送 INVITE 给 CSC3300/ATS9900，消息样例如下：

INVITE tel:81002021 SIP/2.0
Via: SIP/2.0/UDP 154.112.8.22:5060;branch=z9hG4bKuu88mlgem8;Role=3;Dpt=7674_16
Call-ID: ZdmAg32675-ID00000004-H11M027S57@191.134.110.3
Issue 01 (2011-02-10) 华为技术有限公司 60
From: <sip:+8675581002020@ims.hw.com>;tag=45ff921a、
To:< tel:81002021>
CSeq: 1 INVITE
Max-Forwards: 69
Supported: timer
Contact: <sip:+8675581002020@191.134.110.3:5060;transport=udp>
Session-Expires: 300
Min-SE: 90
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,
UPDATE,MESSAGE,REFER
User-Agent: MC-1.1.6.3
Content-Length: 231
v=0
o=+8675581002020 3383350077 0 IN IP4 191.134.110.3
s=TOMORROW
c=IN IP4 191.134.110.3
t=3383350077 0
m=audio 10002 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
其中 Supported: timer 表示 SIP UE 支持 Session timer 心跳，Session-Expires: 300
表示 SIP UE 希望 Session timer 心跳时长是 300s，Min-SE: 90 表示心跳时长不得小于
90s。
如上图所示消息 200 (INVITE)，ATS9900 发送 200 响应给 SIP UE，消息样例如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 154.112.8.30:5061;branch=z9hG4bKlrpdylpelyegrx1hilv4dy1pg
Call-ID: ggeppgi4yire0ezir1wpwyrhyire0ezi@ATS.ats01.ims.huawei.com.20
Record-Route: <sip:154.112.8.21;lr;Role=3;CxtId=3;Dpt=7676_216;spln=IS;X-
HwB2bUaCookie=1036;TRC=ffffffff-
Issue 01 (2011-02-10) 华为技术有限公司 61

ffffffff>,<sip:154.112.8.22;lr;Dpt=7674_136;Role=3;CxtId=3;spln=S;X-
HwB2bUaCookie=1035;TRC=ffffffff-ffffffff>
From: <sip:+8675581002020@ims.hw.com;user=phone>;tag=y1x1dgi0-CC-20-TRC-5378
To: <tel:81002021>;tag=0hiihw1r-CC-20-TRC-5379
CSeq: 1 INVITE
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,
UPDATE,MESSAGE,REFER
Session-Expires: 300;refresher=uas
Require: timer
Contact: <sip:154.112.8.30:5060>
P-Asserted-Identity: <sip:+8675581002021@ims.hw.com;user=phone>
P-Access-Network-Info: IEEE-802.11;"location-info=191.134.110.3"
P-Charging-Vector: icid-
value="467eff9d377cfc6d2ad9ae1b70613134.3509580959.88697.20";orig-
ioi=ims.hw.com;term-ioi=ims.hw.com
Content-Length: 187
v=0
o=HuaweiATS9900 7 7 IN IP4 154.112.8.30
s=Sip Call
c=IN IP4 191.134.110.3
t=0 0
m=audio 10004 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
其中 Session-Expires: 300;refresher=uac 表示最终心跳时长为 300s，refresher=uas 表示发
送心跳方为 uas，即 ATS9900。Require: timer 表示本次呼叫需要发送 Session timer 心跳。
200 响应中的 Session-Expires 值即为协商后的最终心跳时长。一般在一半心跳时长左右
需要发送心跳消息，如上图中 UPDATE 消息，样例如下：
UPDATE sip:+8675581002020@191.134.110.3:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 154.112.8.30:5061;branch=z9hG4bKvp4dw4vvz1ewdhyywwl1ehhdw
Route: <sip:154.112.8.22;lr;Role=3;CxtId=4;Dpt=7674_136;spln=PS;X-
HwB2bUaCookie=927 >
Issue 01 (2011-02-10) 华为技术有限公司 62

From: <tel:81002021>;tag=pvyxr1di-CC-20-TRC-5378
To: <sip:+8675581002020@ims.huawei.com>;tag=45ff921a
CSeq: 1 UPDATE
Min-SE: 600
Supported: timer
Max-Forwards: 70
Contact: <sip:154.112.8.30:5060>
Content-Length: 0
如果对端呼叫仍然存在，则回应 200 响应，否则回应失败响应，比如 481。

200 消息样例如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 154.112.8.30:5061;branch=z9hG4bK14epvewhegxphvghd1ypwhp00
From: <tel:81002021>;tag=pvyxr1di-CC-20-TRC-5378
To: <sip:+8675581002020@ims.hw.com>;tag=45ff921a
CSeq: 1 UPDATE
Require: timer
Contact: < sip:+8675581002020@191.134.110.3:5060;transport=udp>
Content-Length: 0
一般情况下 IMS 发送的 Session timer 心跳消息采用 UPDATE 方法，除非对端不支持
UPDATE，IMS 发送 UPDATE 后收到 405 Method Not Allowed 响应，IMS 会改发 re-
INVITE 作为心跳消息。
心跳时长及心跳发起方可以通过 UPDATE/200 或者 re-INVITE/200 再次协商。
通话双方确认由哪一端来执行刷新，执行刷新的一方在会话刷新超时的一半时间内必
须发出 RE-INVITE 或 UPDATE。
进一步的信息请参考 RFC 4028。
2.6.8 SIP-I/SIP-T 中继呼叫流程

45. SIP-I/SIP-T 概述
SIP-I 是由 ITU-T 标准化组织定义的，英文全称是 SIP with encapsulated ISUP。参考标准
是 Q.1912.5 与 TRQ.2815。
Issue 01 (2011-02-10) 华为技术有限公司 63
SIP-T 由 IETF 标准化组织定义，英文全称是 Session Initiation Protocol for Telephones，

参考文档是 RFC 3372、RFC 3398。
46. 流程描述
请参考统一维护资料之《IMS 互通类-IMS 与 CS 互通-维护指导手册.doc》。
47. SIP 消息与释放原因值映射

SIP 消息与 ISUP 消息信令间映射关系，请参考统一维护资料之《IMS 互通类-IMS 与 CS
互通-维护指导手册.doc》。此节仅用于描述 SIP 状态码与 ISUP 原因值、ISUP 原因值与
SIP 状态码的转换关系。如下图示。
图1.1 ISUP 原因值转换为 SIP 状态码

4xx/5xx/6xx SIP Cause Code
Message
404 Not Found Cause value No. 1 (unallocated (unassigned) number)
500 Server Internal error Cause value No 2 (no route to network)
500 Server Internal error Cause value No 3 (no route to destination)
500 Server Internal error Cause value No. 4 (Send special information
tone)
404 Not Found Cause value No. 5 (Misdialled trunk prefix)
486 Busy Here Cause value No. 17 (user busy)
480 Temporarily Cause value No 18 (no user responding)
unavailable
480 Temporarily Cause value No 19 (no answer from the user)
unavailable
480 Temporarily Cause value No. 20 (subscriber absent)
unavailable
603 Decline Cause value No 21 (call rejected), Location = 000 /
user (U)
480Temporarily Cause value No 21 (call rejected) , Location <> 000 /
unavailable user (U)
410 Gone Cause value No 22 (number changed)
433 Anonymity Disallowed. Cause value No. 24 (call rejected due to ACR
(NOTE 1) supplementary service)
480 Temporarily Cause value No 25 (Exchange routing error)
unavailable
502 Bad Gateway Cause value No 27 (destination out of order)
484 Address Incomplete Cause value No. 28 invalid number format (address
incomplete)
500 Server Internal error Cause value No 29 (facility rejected)
480 Temporarily Cause value No 31 (normal unspecified) (class default)
unavailable (NOTE 2)
486 Busy here if Cause value in the Class 010 (resource unavailable,
Diagnostics indicator Cause value No 34)
includes the (CCBS
indicator = CCBS possible)
else 480 Temporarily
unavailable
500 Server Internal error Cause value in the Class 010
(resource unavailable, Cause value No’s. 38, 41, 42,
43, 44, & 47) (47 is class default)
500 Server Internal error Cause value No 50 (requested facility no subscribed)
500 Server Internal error Cause value No 57 (bearer capability not authorised)
Issue 01 (2011-02-10) 华为技术有限公司 64

4xx/5xx/6xx SIP Cause Code

Message
500 Server Internal error Cause value No 58 (bearer capability not presently)
500 Server Internal error Cause value No 63 (service option not available,
unspecified)
(class default)
500 Server Internal error Cause value in the Class 100 (service or option not
implemented, Cause value No’s. 65, 70 & 79) 79 is
class default
500 Server Internal error Cause value No 88 (incompatible destination)
404 Not Found Cause value No 91 (invalid transit network selection)
500 Server Internal error Cause value No 95 (invalid message)
(class default)
500 Server Internal error Cause value No 97 (Message type non-existent or
not implemented)
500 Server Internal error Cause value No 99 (information element/parameter
non-existent or not implemented))
480 Temporarily Cause value No. 102 (recovery on timer expiry)
unavailable
500 Server Internal error Cause value No 110 (Message with unrecognised
Parameter, discarded)
500 Server Internal error Cause value No. 111 (protocol error, unspecified)
(class default)
480 Temporarily Cause value No. 127 (interworking unspecified)
unavailable (class default)
NOTE 1: Anonymity Disallowed, RFC 5079 [77] refers
NOTE 2: Class 1 and class 2 have the same default value.
图1.2 SIP 状态码转换转换为 ISUP 原因值

 (cause code) 4xx/5xx/6xx SIP Message
127 (interworking unspecified) 400 Bad Request
127 (interworking unspecified) 401 Unauthorized
127 (interworking unspecified) 402 Payment Required
127 (interworking unspecified) 403 Forbidden
1 (Unallocated number) 404 Not Found
127 (interworking unspecified) 405 Method Not Allowed
127 (interworking unspecified) 406 Not Acceptable
127 (interworking unspecified) 407 Proxy authentication required
127 (interworking unspecified) 408 Request Timeout
22 (Number changed) 410 Gone
127 (interworking unspecified) 413 Request Entity too long
127 (interworking unspecified) 414 Request-URI too long
127 (interworking unspecified) 415 Unsupported Media type
127 (interworking unspecified) 416 Unsupported URI scheme
127 (interworking unspecified) 420 Bad Extension
127 (interworking unspecified) 421 Extension required
Issue 01 (2011-02-10) 华为技术有限公司 65

 (cause code) 4xx/5xx/6xx SIP Message

127 (interworking unspecified) 423 Interval Too Brief
24 (call rejected due to ACR 433 Anonymity Disallowed.(NOTE 1)

supplementary service)
20 Subscriber absent 480 Temporarily Unavailable
127 (interworking unspecified) 481 Call/Transaction does not exist
127 (interworking unspecified) 482 Loop detected
127 (interworking unspecified) 483 Too many hops
28 (Invalid Number format) 484 Address Incomplete
127 (interworking unspecified) 485 Ambiguous
17 (User busy) 486 Busy Here
127 (Interworking unspecified) or 487 Request terminated

not interworked. (NOTE 2)
127 (interworking unspecified) 488 Not acceptable here
127 (interworking unspecified) 493 Undecipherable
127 (interworking unspecified) 500 Server Internal error
127 (interworking unspecified) 501 Not implemented
127 (interworking unspecified) 502 Bad Gateway
127 (interworking unspecified) 503 Service Unavailable
127 (interworking unspecified) 504 Server timeout
127 (interworking unspecified) 505 Version not supported
127 (interworking unspecified) 513 Message too large
127 (interworking unspecified) 580 Precondition failure
17 (User busy) 600 Busy Everywhere
21 (Call rejected) 603 Decline
1 (unallocated number) 604 Does not exist anywhere
127 (interworking unspecified) 606 Not acceptable
NOTE 1: Anonymity Disallowed, RFC 5079 [77] refers.

NOTE 2: No interworking if the O-MGCF previously issued a CANCEL request for
the INVITE.
NOTE 3: The 4xx/5xx/6xx SIP responses that are not covered in this table are not
interworked.
关于 SIP-I、SIP-T 的进一步信息，请参考：
SIP-I：RFC3204、RFC3372、RFC3398
SIP-T：ITU-T Q.1912.5
2.6.9 SIP 的 DTMF 传递机制

在 IMS 解决方案中，DTMF 的收号流程主要是由 UGC/UMG 处理完成。
Issue 01 (2011-02-10) 华为技术有限公司 66

48. 场景描述
SIP 支持两种 DTMF 传递方式：带内和带外。
带内即 DTMF 在用户面传送，带外即 DTMF 在信令面传送。
带内：通过编解码的协商来确定 DTMF 带内传输使用的编解码方式、编解码速率以及支
持的事件。对于编解码方式现在统一使用 telephone-event 编解码，时钟速率一般为
8000。带内 DTMF 是 3GPP 中标准的 DTMF 传送方法。对于传递 DTMF 的 telephone-
event 编解码，可以参照 rfc2833 协议，通过 SDP 中的 fmtp 来表示。
带外：SIP 可以通过 INFO 消息来带外传输 DTMF。该做法为华为私有扩展使用方法，
只适用与华为 MSC 对接的局点。
49. DTMF 的带内流程

带内 DTMF 的发送流程：
UGC 发送 DTMF，进入 START DTMF 流程，UGC 检测本端为带内传输则发送

SMMSG_SEND_DTMF_REQ 消息给 MGW，收到 MGW 的
SMMSG_SEND_DTMF_RSP；
UGC 停止发送 DTMF， UGC 检测本端为带内传输则发送 SMMSG_STOP_DTMF_REQ
消息给 MGW，收到 MGW 的 SMMSG_STOP_DTMF_RSP；
带内 DTMF 的接收流程：
Issue 01 (2011-02-10) 华为技术有限公司 67

带内 DTMF 检测统一由呼叫的被叫侧进行检测。当收到 Connect ack 后，判断是否需要

进行 DTMF 检测，若需要则发 DTMF 检测事件请求给 MGW；
MGW 检测到 DTMF 信号后，会通过 DTMF 报告事件发给 UGC，UGC 进行响应的处理。
50. DTMF 的带外流程
MGW 上报远端 DTMF 的检测消息，SIP 需要将检测到的 DTMF 发送出局，如果本端为

带外传输则发送 INFO 消息出局。
相关说明：
1、SIP 的 DTMF 是由命令“ADD SIPTG”的参数“DTMF 传递方式”配置的，缺省是带内
传输，但带内传输并不能完全由配置决定，在配置为带内且编解码协商成功的情况下
才使用带内传输，否则使用带外传输。
2、主叫带内被叫带外方式时，需要下发DTMF检测，原则为呼叫的被叫侧下发。主叫发
往被叫的DTMF信号由被叫检测出来之后通过带外方式发送；被叫发往主叫的DTMF信
号由被叫侧带外收号之后传递给主叫，由主叫侧带内传递。
3、主叫带外被叫带内的方式需要被叫下发DTMF检测。主叫发往被叫的DTMF信号由主
叫带外收号之后传递给被叫，由被叫侧带内发送。被叫发往主叫的DTMF信号由被叫检
测出来之后通过带外方式通过主叫侧发送。
4、主被叫都是带外方式则都通过带外互通。
5、主被叫都是带内方式则由MGW带内自动实现。
2.6.10 SIP 传真
请参考统一维护资料之《IMS 业务类-传真-维护指导手册.doc》。
2.6.11 回铃音、异常音流程
请参考统一维护资料之《IMS 业务类-回铃音及异常音播放-维护指导手册.doc》。
Issue 01 (2011-02-10) 华为技术有限公司 68

IMS 维护指导手册 SIP 相关配置
3 SIP 相关配置
如下的数据配置命令，各网元均以 IMS8.1 配套版本命令形式为准，其他版本仅做

参考。
3.1 基本呼叫配置
这部分基本数据配置可以参考 IMS8.1 配置文档《31184673-HUAWEI IMS IP 多媒体子
系统解决方案产品文档-(V200R008C01_03)》中如下章节所示。
安装与描述 –> 初始配置 -> 配置 IMS 域内呼叫数据
3.2 SIP 心跳配置

SIP 心跳机制相关知识请参考 2.6.7 节。
3.2.1 设备级 OPTION 心跳配置

在 IMS 解决方案中，一个呼叫经过的网元较多，为确保每个网元都知道对端网元
的状态是正常还是故障，且容灾场景里，某网元主用设备故障后，需要切换到备
用设备，因此需要 IMS 中的网元配置支持 OPTION 心跳。
1. ATS9900
• 配置命令
通过 MOD OPTCCP 命令配置，R003C01 版本如下图。

MOD OPTCCP:OPTGRP=0,NRMINTER=10,FALINTER=20,BLKAGINGT=60,
CTOF=1,FTON=1,ACTOPTCHK=TRUE;
容灾场景下，建议打开该开关。建议“确认态 OPTIONS 检测的时间间隔”时长为
10s，“故障态 OPTIONS 检测的时间间隔”为 20s。
Issue 01 (2011-02-10) 华为技术有限公司 69

• 说明
MOD OPTCCP 主要是配置启发式的设备心跳涉及到定时器，以及发送 OPTION 消

息次数等参数。从图 1.1 中可以看出，如果 ATS 给 CSC 发送 INVITE 消息后，无临
时 100Trying 等响应时，ATS 会将 CSC 的 IP 地址加入到黑名单中，并向 CSC 发送
OPTION 消息进行检测，确认是否故障，发送 OPTION 消息的次数由参数“正常态
转到故障态的检测次数”决定，默认为 1 次，发送 OPTION 消息的间隔时长由参数
“确认态 OPTIONS 检测的时间间隔”决定，默认时长是 10s。如果发送的 OPTION 消
息认为响应，则 ATS 确认对端 CSC 故障。在故障态下，ATS 每隔“故障态
OPTIONS 检测的事件间隔”发送 OPTION 给 CSC 确认是否恢复正常，默认时长为
20s，发送次数由参数“故障态转到正常态的检测次数”决定，默认是 1 次，即如果
ATS 给 CSC 发送 OPTION 消息后，收到 200 OK 响应，则 ATS 会再发送一次，如
果再次收到 200 OK，则将 CSC 的 IP 地址从黑名单中剔除。
ATS 网元与 CSC、MRFC 之间有 OPTION 心跳。
图1.1 心跳配置说明
2. CSC3300 配置
Issue 01 (2011-02-10) 华为技术有限公司 70

• 配置命令
通过 MOD OPTCCP 命令配置，R008C01 版本如下图。

MOD OPTCCP:SYSCP=SYSPARAM,OPTCCPID=IndexID,CINTERVAL=10,
FINTERVAL=20,C2FTIMES=3,F2NTIMES=1,OPTCHKTAG=Y,OPTPT=180,
OPTTT=3;
容灾场景下，建议打开该开关。建议“确认态检测时间间隔”时长为 10s，“故障态检
测时间间隔”时长为 20s，“确认态转到故障态的检测次数”为 3 次，“故障态转到正
常态的检测次数”为 1 次。
• 说明
CSC 的配置与 ATS 配置及处理原理基本一致，可参数上一小节中 ATS 的处理说明。

3. UGC3200 配置
• 配置命令
通过 MOD SIPTG 命令配置，R008C01 版本如下图。

MOD SIPTG: TGN="aa", T100=30, T200=10, MTOUTS=3, DHBEAT=YES;
容灾场景下，建议打开该开关。建议“T100 定时器时长”为 30s，“T200 定时器时长”
为 10s，“心跳检测最大超时次数”为 3 次。
• 说明
Issue 01 (2011-02-10) 华为技术有限公司 71

“T100 定时器时长”表示中继状态正常情况下，UGC 发送 OPTION 消息的时间间

隔；“T200 定时器时长”表示中继状态故障情况下，UGC 发送 OPTION 消息的时间
间隔。“T100 定时器时长”与“T200 定时器时长”的关系是：T100≥3*T200。
4. SBC 配置
• 配置命令
R008C01 版本配置命令如下示。
容灾场景下，建议打开该开关。
5. AGCF 配置
通过 MOD DNSRR 命令配置，R010C05 版本如下图。
MOD DNSRR: UHB=YES;
注意：除了上述配置外，还需要设置软参 P493 BIT9 为 0，AGCF 收到 OPTION 消

息后会回应 200 响应消息。
MOD FSFP: ID=493, ModType=P1, Bit=9, BitVal=0;
容灾场景下，建议打开该开关。建议“异常心跳时长”为 30s，“正常心跳时长”为
60s，“心跳失败次数”为 3 次。
3.2.2 会话级 Session timer 心跳配置

为确保会话过程中 IP 承载长时间故障后，能及时释放正在呼叫的资源，防止用户资源
吊死，需要通过 Session timer 心跳机制来解决此问题，避免用户呼叫多计费的问题。在
IMS 解决方案中，建议打开 ATS 网元的 Session Timer 配置开关，Session Timer 心跳检
测时长为 600s。
1. ATS9900 配置
通过 MOD SIPCFG 命令配置，R003C01 版本如下图。
MOD SIPCFG: UST=YES, MSI=90, SI=600;
Issue 01 (2011-02-10) 华为技术有限公司 72

2. CSC3300 配置
通过 MOD STMR 命令配置，R008C01 版本如下图。
MOD STMR: STEN=Y, SE=300, MINSE=90;
3. UGC3200 配置
通过 MOD SIPTG 命令配置，R008C01 版本如下图。
MOD SIPTG: ISST=START;
4. SBC 配置
R008C01 版本配置命令如下示。
1) 手工设置方式
a．执行命令 system-view，进入系统视图。
b．执行命令 sbc function-entity function-entity-index，进入功能实体视图
Issue 01 (2011-02-10) 华为技术有限公司 73

C．执行命令 sbc timer sip call-session time-length，配置 SIP 会话的最大时长。

time-length：对于 SIP 会话，取值范围是 0～14400 分钟。
sbc timer sip call-session 0 表示 SE2600 从不主动中断 SIP 会话。
缺省情况下，SIP 会话最大时长为 720 分钟。
2) 报文协商方式
a．执行命令 system-view，进入系统视图。
b．执行命令 sbc function-entity function-entity-index，进入功能实体视图。
c．执行命令 sbc sip session-timer enable，使能 Session-Expires 头域的定时器。
5. AGCF 配置
AGCF 不支持主动发起会话 Session timer 心跳检测。
3.3 SIP 协议定时器配置

在 RFC3261 中提到了 T1、T2、TB 定时器的概念，这三个定时器主要用于定义消息传送
超时后，消息重发的规则。T1、T2 和 TB 定时器的关系如图 1.2 示。
图1.2 T1/T2/TB 定时器关系图
3.3.1 T1 定时器配置
T1 定时器在 RFC 3261 17.1.1 中定义。T1 定时器主要用于消息重发的间隔。T1 是一个估
计的循环时间（round-trip time，RTT），缺省设置成为 500ms。几乎所有的事务定时
器都以 T1 为单位，并且调整 T1 的值也就调整了那些定时器的值。不建议修改 T1 定时
器的值。
1. ATS9900 配置
Issue 01 (2011-02-10) 华为技术有限公司 74


MOD SIPCFG: T1=5;
2. CSC3300 配置
通过 MOD SIPPP 命令配置，R008C01 版本如下图。
MOD SIPPP: SIPID=32, SIPPV=500;
3. UGC3200 配置
通过 MOD FLEXTIMER 命令配置，R008C01 版本如下图。
4. AGCF 配置
通过 SET SIPCFG 命令配置，R010C05 版本如下图。
3.3.2 T2 定时器配置
T2 定时器是用于指示 INVITE 应答的最大重传时间间隔，缺省值为 4s。即重传时间的
最大时长为 4s，第一次重传的时长为 T1 定时器，后续是 2*T1 的时长来重传，直到重
发的间距是 T2 为止。不建议修改 T2 定时器的值。
1. ATS9900 配置
Issue 01 (2011-02-10) 华为技术有限公司 75


MOD SIPCFG: T2=40;
2. CSC3300 配置
3. UGC3200 配置
MOD FLEXTIMER: T2=40;
4. AGCF 配置
通过 SET SIPCFG 命令配置，R010C05 版本如下图。
3.3.3 TB 定时器配置。
TB 定时器是用于定义 INVITE 请求超时时间的定时器。此定时器与 T1 定时器紧紧相关，
一般是 T1 的倍数时长，默认是 32s，即 64 倍的 T1。非容灾场景下，不建议修改 TB 定
时器的值；容灾场景下，建议修改为 5s，即 10*T1。
1. ATS9900 配置
MOD SIPCFG: TB=64;
Issue 01 (2011-02-10) 华为技术有限公司 76

2. CSC3300 配置
3. UGC3200 配置
MOD FLEXTIMER: TB=32;
4. SBC 配置
无。
3.4 SIP 的 DTMF 收号配置

相关知识请参考 2.6.9 节。
在 IMS 解决方案中，UGC 默认是支持 2833 编解码的，只需要在 UGC 上配置 DTMF 的
传输方式是带内还是带外。通过命令 ADD SIPTG 的参数”DTMF 传输方式”来控制的，
如下图。
DTMF 传输方式缺省是带内传输，但带内传输并不能完全由配置决定，在配置为带内
且编解码协商成功的情况下才使用带内传输，否则使用带外传输。
在 UMG 上，是通过命令 SET RFC2833 对 2833 的 DTMF 传输参数进行控制的，详细请
参考 UMG 产品指导文档，此处不作详细阐述。
Issue 01 (2011-02-10) 华为技术有限公司 77

3.5 SIP 头域相关配置

3.5.1 ATS9900 头域相关配置
1. P-Asserted-Identity 头域 URI 顺序调整
通过 MOD SFP 命令配置 3044 号软参，该软参的作用如下示。
PAI 头域里既有 TEL 又有 SIP 类型的 URI 时控制 PAI 中 URI 类型的先后顺序。
缺省值 = 0
= 0 : 如果收到的 PAI 头域里第一个是 SIP URI 第二个是 TEL URI，则发送消息时保
持顺序不变。
= 1 : 如果收到的 PAI 头域里第一个是 SIP URI 第二个是 TEL URI, 则发送消息时调
整先后顺序。
2. Request-URI 请求行号码转换
通过 MOD SIPCFG 命令配置 Request-URI 中号码格式转换，即如果收到的号码为
SIP URI，可以通过该配置将其转换为 TEL URI。R003C01 版本如下图。
MOD SIPCFG: SFPARA=SIPURI_TRANSTO_TEL-1;
3. From 头域号码格式变换
通过 MOD SIPCFG 命令配置，将主叫侧 ATS9900 发出的消息中 FROM 头域中的号
码为 SIP URI 格式。R003C01 版本如下图。
4. P-Asserted-Identity/From 头域号码变换
通过 MOD SIPCFG 命令配置，将 P-Asserted-Identity/From 中的 TEL URI 转换为 SIP
URI。R003C01 版本如下图。
Issue 01 (2011-02-10) 华为技术有限公司 78

3.5.2 SBC 头域相关配置

1. 转发不带 Max-Forwards 的 SIP 消息配置
2. 丢弃头域异常的 SIP 消息功能配置
3.5.3 UGC 头域相关配置

1. P-Asserted-Identity 头域 URI 格式配置
MOD SIPTG 命令的参数“业务控制软件参数”勾选为“预留业务 8”时，UGC 出局携
带的 P-Asserted-Identity 头域 URI 格式是 SIP 格式，否则为 TEL 格式。
2. Request-URI 格式变换配置
MOD SIPTG 命令的参数“业务控制软件参数”勾选为“预留业务 10”时，UGC 出局到
IMS 携带的 Request-URI 中号码格式为 SIP 格式（不带 user=phone），默认携带
user=phone。
Issue 01 (2011-02-10) 华为技术有限公司 79

3. Request-URI 格式配置
MOD SIPTG 命令的参数“业务控制软件参数”勾选为“预留业务 12”时，UGC 出局到
IMS 携带的 Request-URI 中号码格式为 SIP 格式，默认为 TEL 格式。
注意：预留业务 12 优先级低于预留业务 10。
Issue 01 (2011-02-10) 华为技术有限公司 80

IMS 维护指导手册故障处理
4 故障处理
序号常见问题问题处理
1 呼叫失败类请查看 Error: Reference
source not found
2 接通后断话请查看 Error: Reference
source not found
4.1 呼叫失败类故障
呼叫失败引起的原因可能很多，在此文档中主要介绍由于设备处理不符
合 SIP 协议等原因引起的呼叫无法成功建立，对于由于其他原因引起的
呼叫失败，请参考 IMS 各网元产品指导文档。
4.1.1 问题分析与处理
【故障描述】
 呼叫失败
 主被叫双不通或单通
【可能的故障原因】
序号故障原因备注
1 配置错误呼叫失败
2 网络故障呼叫失败
3 设备故障呼叫失败
4 协议处理错误呼叫失败
【故障分析及处理】
Issue 01 (2011-02-10) 华为技术有限公司 81
在按照如下步骤处理前，可以先检查一下 IMS 各网元主机进程运行是否

正常，CRC 校验是否正常（STR CRC/CHK DATA 命令）。
呼叫失败类问题，原因有很多，也很复杂，主要按照下面的步骤分析。
步骤 1 首先确认 IMS 下各网元基本配置是否配置，各网元基本配置数据请参考
网元产品指导手册描述，在此不作阐述。
步骤 2 其次需要保证网络通畅，包括终端与 IMS、IMS 各网元之间的信令网络
通畅，同时保证语音视频承载网络也通畅。
步骤 3 保证终端已经在 IMS 注册成功，可以使用 EXP USRINF 命令
（CSCF）/DSP GURS（ATS）查询终端的注册状态。
步骤 4 如果上面的步骤都没有发现问题，打开 CSC/ATS（域内呼叫）或
CSC/ATS/UGC（域外呼叫）SIP 消息跟踪（包括内部模块间及外部信令
跟踪），分析 SIP 信令是否正常。
(1) 判断消息跟踪是否有失败响应消息，如：500、403、400、404 等。
(2) 根据失败响应消息中的 Warning 头域，判断是 IMS 哪个网元释放呼
叫，Warning 头域的判断方法请参考 24 节；如果不是 IMS 网元释放，
请联系其他网元分析。
(3) 根据 Warning 头域中的警告正文部分初步判断问题原因。如果是 ATS
释放呼叫，可以将 Warning 头域拷贝至 ATS 的工具《ATS9900
Warning Header Error Code Table.xls》，对 Warning 头域进行解析后，
根据提示进行检查；如果是协议栈释放呼叫，则可以根据状态码和
Warning 头域中的描述查看 24 节的协议参考文档，根据文档中的提
示分析定位。
步骤 5 如果信令上没有问题，则可以使用 Ethereal/Wireshark 软件抓取 RTP 包分
析主被叫终端的 RTP 交互情况。通过 Ethereal/Wireshark 分析出媒体流信
息并结合信令看是否正确。注意，如果在终端与 IMS 直接使用了 SBC 作
信令和媒体代理，则可以使用 RemoteCapture 工具在 SBC 上抓取信令和
RTP 包。
步骤 6 如果 RTP 包存在问题，请联系终端或相关网元的技术支持。
Issue 01 (2011-02-10) 华为技术有限公司 82

图1.1 RTP 分析
----结束
4.1.2 典型案例
51. 案例 1： IMS 与中兴 SBC 对接，用户基本呼叫 S-CSCF 发送 BYE 消息

【案例描述】
Issue 01 (2011-02-10) 华为技术有限公司 83

某局将 SIP 终端下挂在中兴 SBC 下测试出现呼叫失败，S-CSCF 发送

BYE 消息，用我司 SBC 下挂用户测试正常。组网如下：
S-CSCF 地址：10.185.168.7 P-CSCF 核心侧地址：10.185.168.10
中兴 SBC：10.185.169.130 P-CSCF 接入侧地址：10.185.168.228
【案例分析】
此问题需要首先从信令方面分析。
1. 从信令看，S-CSCF 给 P-CSCF 发送 BYE 消息，消息中提示“Wait
Peer Ack Timeout for INVITE”。根据该提示查看 24 节的协议栈文档，
可以知道原因是由于 S-CSCF 没有收到 200 OK 的 ACK 响应，导致
超时发送 BYE 消息释放呼叫。如 Error: Reference source not found 示。
2. 分析前面呼叫流程，P-CSCF 给主叫发送 200 OK(INVITE)消息后，
收到了 SBC 的 ACK 响应，但是 P-CSCF 没有将 ACK 前传给 S-
CSCF。如 Error: Reference source not found 示。
3. P-CSCF 将 ACK 消息转发给 S-CSCF 的原因是由于 ACK 消息中缺少
了参数。按照请求消息的路由（参考 2.3.2 节示），此时 SBC 作为
UAC，按照 RFC-3261 12.1.2 的描述，UAC 应该将 200
OK(INVITE)消息中的 Record-Route 原样填写放在 ACK 中的 Route
头域中，但是中兴 SBC 却不是。P-CSCF 发给 SBC 的 200 OK 消息
Record-Route 头域如 Error: Reference source not found 示， SBC 返回
的 ACK 响应中 Route 头域如 Error: Reference source not found 示。
Issue 01 (2011-02-10) 华为技术有限公司 84

图1.1 案例截图 1
Issue 01 (2011-02-10) 华为技术有限公司 85

4. 从上图消息中可以看出，中兴 SBC 后续 ACK 信息中构造的 ROUTE

头域，不符合 RFC-3261 协议 12.1.2 UAC Behavior，没有完全拷贝
华为 P-CSCF 200 OK 消息中的 Record-Route（缺少 X-
HwB2bUaCookie=15 参数）
附：协议原文如下：
The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and
preserving all URI parameters.
【问题解决】
中兴 SBC 按照 RFC3261 协议规定修改。
52. 案例 2：SIP 终端使用显转业务，ATS 回 400 错误

【案例描述】
Issue 01 (2011-02-10) 华为技术有限公司 86

SIP 终端与 IMS 对接，测试显示转移业务，用户在发起转移的时候，

ATS 回 400 错误，导致发起转移失败。组网如下：
【案例分析】
1. 检测网络及配置均正常，通过信令分析，发现 ATS 收到终端发起转
移的 Refer 消息后，回 400 BAD REQUEST 错误响应，消息如下：
Issue 01 (2011-02-10) 华为技术有限公司 87

2. 根据消息中 400 BAD REQUEST 消息 Warning 头域，

Warning: 399 19600.0.ATS.ats1.zj.ctcims.cn.1
"SS010000F00150L01228[5406] Mandatory Header Absent"
参考 24 节可以判断是 ATS 回送的错误，并且是协议栈释放。根据 24
节的协议栈参考文档，释放的原因是由于 REFER 消息中的某个头域
非法导致。
3. 使用 SIP 解霸工具，解析 REFER 消息发现， Refer-To 头域解析失败，
因此可以判断是由于 Refer-To 头域非法导致。
关于 Refer-To 头域的正确语法，请参考 RFC 3515 2.1 节。

【问题解决】
SIP UE 按照协议修改 Refer-To 头域为正确格式。
Issue 01 (2011-02-10) 华为技术有限公司 88

4.2 SIP 呼叫接通后断话类故障

呼叫接通后断话引起的原因可能很多，在此文档中主要介绍由于设备处
理不符合 SIP 协议等原因引起的呼叫接通后断话，对于由于其他原因导
致的呼叫接通后断话, 请参考 IMS 各网元产品指导文档。
4.2.1 问题分析与处理
【故障描述】
 SIP 呼叫接通后断话
【可能的故障原因】
序号故障原因备注
1 网络故障呼叫接通后断话
2 协议对接错误呼叫接通后断话
【故障分析及处理】
呼叫接通后断话类问题，原因很多，也很复杂。主要按照下面的步骤分析
步骤 2 首先确认用户是否注销，可以使用 EXP USRINF 命令（CSCF）/DSP
GURS（ATS）查询终端的注册状态。
步骤 3 其次确认 IMS 各网元是否打开会话级 Session timer 心跳功能（配置请参
考 3.2.2 节）以及终端是否支持会话级 Session timer 心跳功能。如果 IMS
各网元配置不支持会话级 Session timer 心跳功能，且终端也不支持会话
级 Session timer 心跳功能，则导致断话；或者 Session timer 的协商结果
为由 UAC 发起检测，但是 UAC 却没有发起检测，从而导致断话。
步骤 4 如果上面的步骤都没有发现问题，打开 CSC/ATS（域内呼叫）或
CSC/ATS/UGC（域外呼叫）SIP 消息跟踪（包括内部模块间及外部信令
跟踪），分析 SIP 信令是否正常。
(1) 判断消息跟踪是否有失败响应消息，如：500、403、400、404 等。
(2) 根据失败响应消息中的 Warning 头域，判断是 IMS 哪个网元释放呼
叫，Warning 头域的判断方法请参考节 24 节；如果不是 IMS 网元释
放，请联系其他网元分析。
(3) 根据 Warning 头域中的警告正文部分初步判断问题原因。如果是 ATS
释放呼叫，可以将 Warning 头域拷贝至 ATS 的工具《ATS9900
Warning Header Error Code Table.xls》，对 Warning 头域进行解析后，
根据提示进行检查；如果是协议栈释放呼叫，则可以根据状态码和
Warning 头域中的描述查看下面文档，根据文档中的提示分析定位。
步骤 5 如果不是 IMS 网元释放呼叫，请联系其他网元分析。
Issue 01 (2011-02-10) 华为技术有限公司 89

4.2.2 典型案例
案例 1：S-CSCF 通话过程中发送 408 错误。

【案例描述】
主叫：+865512376159
被叫：13956018973
组网：
ATS IP 地址：10.185.156.11 S-CSCF IP 地址：10.185.156.6
P-CSCF IP 地址：10.185.156.5 MGCF IP 地址：10.185.156.15
呼叫建立后，主叫用户和被叫用户并没有挂机，通话大约 17 分钟后，S-
CSCF 网元发出 408 Request Timeout 消息，继而呼叫断开。
【案例分析】
1. 这个问题可以从内部消息跟踪入手，首先确认释放呼叫的网元，根
据 408 Request Timeout 消息中的 Warning 头域确认释放原因。从内部
消息跟踪可以看出，是 S-CSCF 发送 408 消息，Warning 头域中释放
原因是“No Response From Network"”，消息截图如下。
Issue 01 (2011-02-10) 华为技术有限公司 90

2. 从消息中可以看出，S-CSCF 发送 408 的原因是由于没有收到

UPDATE 对应的 200 OK 响应导致的，而这个 UPDATE 是由 ATS 主
动发起的，根据 UPDATE 消息内容，可以看出此 UPDATE 消息是用
于会话 Session timer 心跳检测的。
3. 根据 44 节关于 Session timer 心跳原理，呼叫协商的结果是由 ATS 主

动发起 Session timer 心跳检测，时长为 1000s，即 500s 发起检测。从
Error: Reference source not found 可以看出，ATS 进行后两次 Session
Issue 01 (2011-02-10) 华为技术有限公司 91

timer 心跳检测，第二次发出的 UPDATE 消息没有收到由终端发出的

响应。
4. 根据 RFC 3261 中规定，后一次请求消息中的 Request-URI 是根据前
一次响应中 contact 头域来填写的，因此 UPDATE 消息的路由是根据
消息中 Request-URI 来路由的。分析 SBC 与 AR 设备之间的抓包，AR
设备发给 SBC 的第一个 UPDATE 200 OK 响应消息如下图示。发现
200 OK 消息 contact 头域中的地址为 192.168.1.85，此 IP 地址为一个
私网 IP 地址。因此，当 SBC 第二次收到 UPDATE 消息时，会根据保
存的 contact 头域中的地址，即 192.168.1.85 来进行转发，但由于该
IP 为一个私网 IP 地址，所以第二 UPDATE 无法转发给终端，从而导
致 S-CSCF 超时释放呼叫。
【问题解决】
（1）优化网络。
（2）将 AR 设备的 SIP ALG（ALG：Application Layer Gateway 应用层
网关）功能关闭，NAT 转换功能使用 SBC 来完成。
案例 2：ATS 通话过程中发送 BYE 消息。

【案例描述】
主叫：+3622396117
被叫：+3696396118
组网：
ATS IP 地址：192.168.1.5 S-CSCF IP 地址：10.23.28.70
Issue 01 (2011-02-10) 华为技术有限公司 92

P-CSCF IP 地址：10.23.28.68
呼叫建立后，主叫用户和被叫用户并没有挂机，通话大约 10 分钟后，
ATS 网元发出 BYE 消息，继而呼叫断开。
【案例分析】
这个问题可以直接从消息跟踪分析入手，并发现问题。分析步骤如下。
1. 从 ATS 网元内部消息跟踪可以看到，呼叫建立 10 分钟后，ATS 发
送 BYE 消息，并提示“Session Timer Expires Timeout”，消息截图如
下。查看协议参考文档，该提示说明，UAC 或 UAS 在 Expires 内没
有发起 Session timer 心跳检测，导致呼叫释放。
Issue 01 (2011-02-10) 华为技术有限公司 93

2. 从上图中，可以发现 ATS 在呼叫通话 5 分钟后，发送的 UPDATE 消

息，从消息中可以看出是发给被叫 ATS 的 Session timer 心跳检测消
息。
3. 根据基本呼叫协商的 Session timer 结果可以看出（200 OK(INVITE)

消息），对于主叫侧和被叫侧，都指示由 UAC 发起 Session timer 心
跳检测。主叫侧，主叫用户+3622396117 是 UAC 角色，被叫侧，主
叫 ATS 是 UAC 角色。
图1.6 案例截图 3（主叫侧 ATS 收到的 200 OK(INVITE)消息）
Issue 01 (2011-02-10) 华为技术有限公司 94

图1.7 案例截图 3（主叫侧 ATS 收到的 200 OK(INVITE)消息）
4. 根据以上分析可以得出，正常情况下，主叫用户作为 UAC 应该发

送 Session timer 心跳请求，主叫侧 ATS 对被叫侧来说是作为 UAC
应该发送 Session timer 心跳请求。但主叫用户没有发起 Session timer
心跳检测请求。
【问题解决】
打开主叫用户+3622396117 的 Session timer 心跳功能。
Issue 01 (2011-02-10) 华为技术有限公司 95

IMS 维护指导手册缩略语
5 缩略语
缩略语英文全称中文全称
PSTN Public Switched Telephone 公用交换电话网

Network
SIP Session Initiation Protocol 会话初始化协议
UMG Universal Media Gateway 通用媒体网关
IAD Integrated Access Device 集成/综合接入设备
MGCP Media Gateway Control Protocol 媒体网关控制协议
ISUP Integrated Services Digital ISDN 用户部分

Network User Part
SDP Session Description Protocol 会话描述协议
UAC User Agent Client 代理客户端
UAS User Agent Server 代理服务端
3GPP 3rd Generation Partnership 第三代移动通信标准
Project 化的伙伴项目
AGCF Access Gateway Control 接入网关控制器
Function
ATS Advanced Telephony Server 通用语音服务器
CCF Charging Collection Function 计费收集功能
BGCF Breakout Gateway Control 出口网关控制功能
Function
CSCF Call Session Control Function 呼叫会话控制功能
HSS Home Subscriber Server 归属用户服务器
I-CSCF Interrogating-CSCF 查询 CSCF
isue 01 (2011-02-10) 华为技术有限公司 96

IMS 维护指导手册缩略语
IMPI IM Private Identity IP 多媒体私有标识

IMPU IM Public Identity IP 多媒体公共标识
IMS IP Multimedia Subsystem IP 多媒体子系统
IM-SSF IP Multimedia Service Switching IP 多媒体业务交换功
Function 能
MRFC Multimedia Resource Function 多媒体资源功能控制
Controller 器
MRFP Multimedia Resource Function 多媒体资源功能处理
Process 器
P-CSCF Proxy-CSCF 代理-CSCF
RTP Real-time Transport Protocol 实时传输协议
S-CSCF Serving-CSCF 服务-SCSCF
SDP Session Description Protocol 会话描述协议
isue 01 (2011-02-10) 华为技术有限公司 97

IMS解决方案统一维护手册 协议专题 SIP协议

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IMS解决方案统一维护手册 协议专题 SIP协议

Uploaded by

Copyright:

Available Formats

IMS 解决方案统一维护手册-协议专题-SIP 协议

客户服务电话： 0755-28560000 4008302118

版权所有 © 华为技术有限公司 2010。 保留一切权利。

问题反馈，请一线创建 iCare 问题单，并按照如下方式操作：

Issue 01 (2011-02-10) 华为技术有限公司 I

Issue 01 (2011-02-10) 华为技术有限公司 II

Issue 01 (2011-02-10) 华为技术有限公司 II

1 SIP 介绍 SIP 协议概述...................................................................................................................5

Issue 01 (2011-02-10) 华为技术有限公司 i

Issue 01 (2011-02-10) 华为技术有限公司 ii

图 2-2 主叫使用 Bye...............................................................................................................................................3

图 2-3 主叫发送 CANCEL......................................................................................................................................4

图 2-6 使用 Bye 终结 Confirmed Dialog................................................................................................................6

图 2-7 成功响应的 INVITE 事务...........................................................................................................................7

图 2-8 失败响应的 INVITE 事务...........................................................................................................................7

图 2-9 非 INIVTE 事务样例...................................................................................................................................8

图 2-10 SIP 请求消息结构....................................................................................................................................17

图 2-13 请求消息路由样例 1................................................................................................................................37

图 2-14 请求消息路由样例 2................................................................................................................................38

图 2-15 请求消息路由样例 3................................................................................................................................38

图 2-16 SIP 协议在 IMS 中的应用.......................................................................................................................39

图 2-17 SIP 协议栈................................................................................................................................................39

图 2-18 ATS9900 SIP 消息模块间分发示意图....................................................................................................40

图 2-19 CSC3300 SIP 消息模块间分发示意图...................................................................................................42

图 2-20 UGC3200 SIP 消息模块间分发示意图..................................................................................................43

图 2-21 SIP 用户基本呼叫流程............................................................................................................................45

图 2-23 SDP 媒体描述样例..................................................................................................................................48

图 2-24 媒体协商 O/A 模型..................................................................................................................................49

图 2-25 支持 180 可靠传输流程样例...................................................................................................................50

Issue 01 (2011-02-10) 华为技术有限公司 iii

图 2-26 UPDATE 流程样例..................................................................................................................................52

图 2-27 Re-INVITE-200 协商...............................................................................................................................53

图 2-28 200 和 ACK 完成协商.............................................................................................................................53

图 2-31 Session timer 心跳....................................................................................................................................56

图 2-32 ISUP 原因值转换为 SIP 状态码.............................................................................................................60

图 2-33 SIP 状态码转换转换为 ISUP 原因值.....................................................................................................61

图 3-2 T1/T2/TB 定时器关系图...........................................................................................................................72

图 3-3 编解码类型与 CODECID 映射关系表.....................................................................................................79

图 4-1 RTP 分析....................................................................................................................................................85

图 4-2 案例截图 1..................................................................................................................................................87

图 4-3 案例截图 2..................................................................................................................................................87

图 4-4 案例截图 3..................................................................................................................................................88

图 4-5 案例截图 4..................................................................................................................................................88

图 4-6 案例截图 1..................................................................................................................................................90

图 4-7 案例截图 2..................................................................................................................................................91

图 4-8 案例截图 1..................................................................................................................................................94

图 4-9 案例截图 2..................................................................................................................................................94

图 4-10 案例截图 3................................................................................................................................................95

图 4-11 案例截图 1................................................................................................................................................97

图 4-12 案例截图 2................................................................................................................................................97

图 4-13 案例截图 3（主叫侧 ATS 收到的 200 OK(INVITE)消息）.................................................................97

图 4-14 案例截图 3（主叫侧 ATS 收到的 200 OK(INVITE)消息）.................................................................98

Issue 01 (2011-02-10) 华为技术有限公司 iv

1 SIP 介绍 SIP 协议概述

1.1 SIP 是什么

1.2 SIP 发展历史

Issue 01 (2011-02-10) 华为技术有限公司 5

 RFC2543 从 bis00 发展到了 bis09，于 2002 年 6 月通过了 SIP 的基本纲领

1.3 常用 SIP 协议标准

RFC2045 Multipurpose Internet Mail Extensions 多用途的 Internet 邮件扩展

RFC2046 Multipurpose Internet Mail Extensions 多用途的 Internet 邮件扩展

RFC 2327 SDP: Session Description Protocol SDP 协议标准文档

RFC 2543 SIP: Session Initiation Protocol SIP 协议标准基础文档 1999

IMS解决方案统一维护手册协议专题 SIP协议

IMS解决方案统一维护手册协议专题 SIP协议

版权所有 © 华为技术有限公司 2010。保留一切权利。