3gpp-24.229中文版R7

3GPP TS 24.229 V7.0.0 (2005-06)
Technical Specification

基于SIP和SDP的IP多媒体呼叫控制协议
Stage 3
(Release 7)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners’ Publications Offices.

Keywords
UMTS, Network, IP, SIP, SDP, multimedia

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2005, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

4 概述 6
4.1 IMS各网元SIP、SDP以及其他协议的协作 6
4.2 URI和地址的分配 7
4.2A 传送机制 8
4.3 IMS网元的路由策略 8
4.4 可信域 8
4.5 IMS计费相关策略 9
4.5.1 总述 9
4.5.2 IMS计费标识(ICID) 9
4.5.3 接入网计费信息 10
4.5.4 Inter operator identifier (IOI) 固有运营标识 10
4.5.5 计费功能地址 11
5 SIP的应用 11
5.1 UE的处理过程 11
5.1.1 注册和认证 11
5.1.2 订阅和通知 20
5.1.2A 应用于除了REGISTER以外的所有方法（method）的通用流程 20
5.1.3 初始呼叫－起呼情形 22
5.1.4 初始呼叫－终呼情形 24
5.1.5 呼叫释放 25
5.1.6 紧急业务 25
5.2 P-CSCF的处理过程 25
5.2.1 概述 25
5.2.2 注册 26
5.2.3 订阅注册用户状态事件包 29
5.2.4 多公有用户标识的注册 30
5.2.5 注销 31
5.2.6 除了REGISTER方法之外的对所有对话和单独事务的一般处理 32
5.2.7 初始INVITE 39
5.2.8 呼叫释放 40
5.2.9 后续请求 42
5.2.10 紧急业务 42
5.2.11 Void 43
5.3 I-CSCF执行的步骤 43
5.3.1 注册过程 43
5.3.2 初始请求 45
5.3.3 I-CSCF中的THIG功能 47
5.3.4 无 50
5.4 S-CSCF执行过程 50
5.4.1 认证和鉴权 50
5.4.2 订阅和通知 59
5.4.3 除了被S-CSCF终止的请求之外所有对话和单独事务的一般处理 61
5.4.4 呼叫发起 67
5.4.5 呼叫释放 68
5.4.6 呼叫相关请求 70
5.4.7 71
5.5 MGCF的流程 71
5.5.1 一般情形 71
5.5.2 订阅和通知 71
5.5.3 呼叫的发起 71
5.5.4 呼叫释放 73
5.5.5 呼叫相关的请求 73
5.5.6其他初始请求 74
5.6 BGCF的流程 74
5.6.1 概要 74
5.6.2 会话发起事务 74
5.7 应用服务器(AS)流程 75
5.7.1 普通应用服务器(AS)流程 75
5.7.2 应用服务器(AS)用作终止UA或者重定向服务器 77
5.7.3 应用服务器(AS)扮演初始UA 77
5.7.4 应用服务器(AS)扮演SIP proxy 77
5.7.5 AS执行第三方呼叫控制 77
5.7.6 void 78
5.8 MRFC流程 78
5.8.1 概要 78
5.8.2 呼叫发起 79
5.8.3 呼叫释放 79
5.8.4 呼叫相关的请求 80
5.8.5 其他的初始请求 81
5.9 IMS-ALG 81
5.9.1 概要 81
6 有关SDP应用的用法 81
6.1 UE上执行的步骤 81
6.2 在P-CSCF上的步骤 83
6.3 在S-CSCF 上的过程 84
6.4 MGCF执行的步骤 84
6.4.1 呼叫起源于电路域网络 84
6.4.2 中止于电路交换网络的呼叫 84
6.5 MRFC执行的步骤 85
6.6 AS上执行的步骤 85
6.7 在IMS-ALG上执行的步骤 85
7 现有文件中的扩展 85
7.1 SIP methods defined within the present document 85
7.2 SIP头在现有文件中的定义 86
7.2.0 General 86
7.2.1 无 87
7.2.2 无 87
7.2.3 无 87
7.2.4 无 87
7.2.5 无 87
7.2.6 无 87
7.2.7 无 87
7.2.8 无 87
7.2.9 无 87
7.2.10 无 87
7.2A 扩展现有文件中定义的SIP头 87
7.2A.1 扩展WWW-authenticate 头 87
7.2A.2 对认证头的扩展 88
7.2A.3 Tokenized-by参数定义 89
7.2A.4 P-Access-Network-Info头 89
7.2A.5 P-Charging-Vector header P-Charging-Vector头 90
7.2A.6 Orig parameter definition Orig参数的定义 92
7.3 在现有文档中定义的可选标签 93
7.4 在现有文档中定义Status-codes 93
7.5 现有文档中定义会话 93
7.6 3GPP IMSXML体，版本1 93
7.6.1 综述 93
7.6.2 文档类型的定义 93
7.6.3 DTD描述 94
7.7 SIP定时器 95
7.8 IMS定时器 96
8 SIP信令压缩 97
8.1 在UE上SIP压缩的过程 97
8.1.1 SIP压缩 97
8.1.2 SIP请求压缩和向P-CSCF传递响应 97
8.1.3 从P-CSCF中收到的SIP请求和响应的解压缩 98
8.2 在P-CSCF上的压缩过程 98
8.2.1 SIP压缩 98
8.2.2 压缩传递给UE的SIP请求和响应 98
8.2.3 解压从UE收到的SIP请求和响应 98
9 当接入到IM CN子系统，IP连接接入网方面 99
9.1 介绍 99
9.2 在UE上的过程 99
9.2.1 连接到IP-CAN，发现P-CSCF 99
9.2.2 Handling of the IP-CAN 处理IP-CAN 99
9.2.3 应用分岔响应的特殊需求 100

4 概述
4.1 IMS各网元SIP、SDP以及其他协议的协作
SIP协议定义了一些功能实体来实现所支持的功能，附录A中定义了每个实体角色。每个IMS功能实体都有各自的接口，包括Gm、Mg、Mi、Mj、Mk、Mm、Mr 、 Mw、ISC接口，如附录A所述这些接口支持SIP协议。根据下文各实体角色，附录A详述了各接口的功能和约束。
3GPP TS 23.002 [2]中定义Gm、Mg、Mi、Mj、Mk、Mm、Mw各接口。
3GPP TS 23.228 [7]中定义了Mr接口。
3GPP TS 23.228 [7]第4.2.4章节定义了ISC接口。

• UE（用户设备）提供用户代理功能。本文第5.1章节描述了UE中SIP的特例及新增功能；第6.1章节描述了SDP的特例及新增功能；第8.1章节描述了信令压缩的特例及新增功能；B2.2章节描述了UE的接入过程。
• P-CSCF提供代理功能。第5.2章节描述了SIP的特例及新增功能；第6.2章节描述了SDP的特例及新增功能；第8.2章节描述了信令压缩的特例及新增功能；B2.2章节描述了UE的接入过程。在5.2章节中所述特定环境下，P-CSCF将提供具有新增功能的用户代理功能，新增功能如下：
  a) 作为订阅者或者事件信息的接收者，并且
  b) 当P-CSCF发起释放对话时，P-CSCF将执行UA功能， 即使P-CSCF为其他会话扮演代理角色，当P-CSCF发起释放会话时，它也是充当UA角色
• I-CSCF将提供代理功能。第5.3章节描述了I-CSCF的特例及新增功能。
• S-CSCF将提供代理功能。第5.4章节描述了S-CSCF的特例及新增功能。第6.3章节描述了SDP的特例及新增功能。在5.4章节中所述特定环境下，S-CSCF将提供具有新增功能的用户代理功能，新增功能如下：
  a) S-CSCF作为注册机。当作为注册机或者执行第三方注册时，S-CSCF提供UA功能；
  b) 作为事件信息的通知者，S-CSCF提供UA功能；
  c) 通过发送消息的方法提供了消息机制，此时S-CSCF提供UA功能；
  d) 当S-CSCF发起释放对话时，S-CSCF提供UA功能，即使S-CSCF为其他会话扮演代理角色，当S-CSCF发起释放会话时，其也充当UA角色
• MGCF（媒体网关控制功能）将提供代理功能。第5.5章节描述了MGCF的特例及新增功能。第6.4章节描述了SDP的特例及新增功能。
• BGCF（出口网关控制功能）将提供代理功能。第5.6章节描述了BGCF的特例及新增功能。
• AS（应用服务器）作为终端UA，或者重定向服务器（在3GPP TS 23.218 [5] 第9.1.1.1节定义）提供UA功能，第5.7.2章节描述了特例及新增功能，第6.6章节描述了SDP的特例及新增功能。
• AS作为发起UA（3GPP TS 23.218 [5] 第 9.1.1.2节定义）将提供UA功能，本文第5.7.3章节描述了特例及新增功能，第6.6章节描述了SDP的特例及新增功能。
• AS作为SIP代理（3GPP TS 23.218 [5] 第9.1.1.3章节定义）提供代理功能，第5.7.4章节描述了特例及新增功能。
• AS执行第三方会话控制（3GPP TS 23.218 [5] 第9.1.1.4节定义）将提供UA功能，第5.7.5章节描述了特例及新增功能。第6.6章节描述了SDP的特例及新增功能。
  注1： 第5.7及子章节定义了AS对应SIP的需求，其它需求在3GPP TS 23.218 [5]中进行了定义。
• 当AS接收第三方注册请求时，执行UA功能，第5.7节对特例及新增功能进行了描述。
• MRFC（多媒体资源控制功能）将提供代理功能。第5.8章节描述了MGCF的特例及新增功能。第6.5章节描述了SDP的特例及新增功能。
• IMS-ALG（IMS应用层网关）将提供代理功能。第5.8章节描述了MGCF的特例及新增功能。第6.5章节描述了SDP的特例及新增功能。
  根据上文所述的功能，P-CSCF、 I-CSCF、 S-CSCF、 BGCF能够执行UA功能，基于RFC 3261 [26]描述的原因，UA可以提供服务器功能并返回一个最终响应。
  注2： 附录A可以改变参考说明书的需求状况。表A.4 和表 A.162关注引用的SIP标准中的性能。表A.317 和表 A.328关注应用的SDP标准的性能。余下的表在这些初始表格基础上建立。
  注3： 本段定义的分配角色来源于IETF SIP规范的基本需求部分，并考虑了进一步需求。一些额外的需求将代理角色改变为B2BUA角色。除了第5.2a节进行了完全描述，基于其它考虑，P-CSCF执行代理需求。当注册事件订阅时， P-CSCF不执行IETF中RFC的UA需求，而执行B2BUA角色。
  注4 ： 除了第5章以及RFC3261中的描述，提供Proxy功能的实体将透传接收和响应。所以这些实体不修改消息体。如果本地策略应用限制数据被传送，功能实体将呈现UA角色，并拒绝这个请求，或者如果一个响应被限制时，传送该响应，然后发送BYE释放会话。
  4.2 URI和地址的分配
  为了SIP和SDP的应用，下列一些前提需要满足：

1. I-CSCFs在注册时就分配了SIP URIS，其他的IMS网元也被分配了URIs，比如P-CSCF的sip:P-CSCF.home1.net和sip:@P-CSCF.home1.net都是有效的SIP URIs。如果用户部分存在，用户部分是地址的基本部分，在复制和移动过程中不可被忽略。这些逻辑实体地址的指派是由运营商决定的。比如说一个SIP URI被指派给所有的I-CSCFs，根据IP能力在所有的网元之间进行负荷分担。或者每个I-CSCF被分配一个SIP URI，根据DNS SRV 能力在各个网元之间负荷分担。
2. 所有的IMS网元被分配IPv6地址，在3GPP TS 23.221 [6] 第5.1章节中描述了相关的限制。
3. 签约者被归属网络分配一个私有用户标识PVI，ISIM应用中包含了PVI，如果ISIM不存在，但是USIM存在时，PVI是可获得的(参见5.1.1.1A)。在UE的SIP应用中，用到了该私有用户标识。
   注意： SIP URIs可以被任何公有DNSs、私有DNS或者等同实体所决定。
4. 签约者在归属网络中被分配一个或多个公有用户标识PUI，公有用户标识有SIP URI的形式如RFC 3261 [26]所述，或者电话URI形式如RFC 3966 [22] 所述。如果存在ISIM应用时，至少一个公有标识包含在ISIM应用中。当没有ISIM应用，有USIM应用时，UE发送一个临时的公有用户标识（参看第5.1.1.1A节）。注册后，对于UE的所有SIP应用，用户的公有标识都是可用的。
5. 公有用户标识可以被多个UE共享。一个专有公有用户标识可以同时被多个UE注册，这些UE拥有不同的私有用户标识和不同的联系地址。当刷新注册或者注销一个公有用户标识和该PUI相关联系地址时，UE将用同样的私有用户标识，该私有标识就是在初始注册时使用的，与该公有用户标识和联系地址是相对应的。
6. 根据3GPP TS 23.221 [6] 第5.1节描述了相应的限制（参看9.2.1节），为了接入IMS系统，UE被分配IPV6前缀。
   4.2A 传送机制
   本文档没有提出RFC3261第18章描述的信令传输协议的需求，但是根据RFC 3261 [26] 第18.1.1节描述了处理过程，UE和IMS网元能够传输大于1300字节的SIP消息，甚至存在一个实体检查大于1500字节的最大传输单元大小。
   对于初始注册请求 ，UE和P-CSCF运用第5.1.1.2 和5.2.2节描述端口进行传输。除了初始注册请求外，UE和P-CSCF在接收、发送请求和响应的端口是3GPP TS 33.203 节中所描述的受保护端口。
   4.3 IMS网元的路由策略
   RFC3261中描述了每个IMS功能实体将采用松散路由去处理SIP请求。当在非IMS网络中I-CSCF或者S-CSCF可以以严格路由操作，在RFC3261中定义了路由的处理过程，确保I-CSCF和S-CSCF能够将松散和严格路由协同工作。
   4.4 可信任域
   RFC3325提供了在可信任域中确定标识的存在和信任。对于IMS系统，可信域是指在同一个运营域中，所有的网元( 如P-CSCF, I-CSCF, S-CSCF, BGCF. MGCF, MRFC, 和所有的非第三方服务提供商提供的AS) 。另外，在运营可信域以外的其它IMS节点，根据是否与远程网络存在内部连接的协议，来决定是否属于该可信域。与网络存在内部连接协议的SIP实体属于该可信域。第三方服务商提供的应用服务器AS不属于可信域。当SIP信令通过可信域的边界时，SIP功能实体将去除P-Asserted-Identity头。

编者按：决定节点是否属于可信域的机制还没有最终确定。
可信域是用P-Asserted-Identity头进行标识的。5.4节标识了P-Access-Network-Info头去除的特殊情况。

注意：除了第5段说明的流程外，RFC3325还应用了关于P-Asserted-Identity头和超出可信域的内容的传送的流程。
4.5 IMS计费相关策略
4.5.1 概要
下面段落描述了计费相关策略，便于理解第5章计费处理过程。3GPP TS 32.240 和3GPP TS 32.260进一步阐述了计费相关知识。
在离线和在线计费时，IMS产生和利用如下的相关信息：

1. IMS 计费标识；
2. 接入网计费信息；
3. 固有运营标识
4. 计费功能地址
   a. 计费收集功能
   b. 事件计费功能
   在IMS中，如何产生和使用这些参数，在下面章节中将进一步描述。如7.2A.5章节中的定义，计费的相关信息在P-Charging-Vector头中进行编码。P-Charging-Vector头包含了下面的参数：icid、接口网络计费信息和ioi。
   在RFC3455中定义了P-Charging-Function-Addresses头，在线和离线计费功能地址就编码在其中。P-Charging-Function-Addresses头包含了下面的参数：CCF和ECF。
   4.5.2 IMS计费标识(ICID)
   ICID是会话层的数据，它被IMS网元共享使用，包括主呼和被呼的IMS中的AS。当IMS网元产生计费数据记录CDRs时，ICID同样用于会话无关的息（如订阅请求、通知请求、消息请求）。
   在一个SIP事务中的第一个IMS实体产生ICID，并将此值保存到SIP请求消息中P-Charging-Vector消息头的icid参数中。对话不同于会话，仅仅在INVITE请求产生ICID，而对于其它事务，每个SIP请求都将产生ICID。如3GPP TS 32.260指出了ICID的格式。P-CSCF在发起呼叫时产生ICID。如果在接收到的初始请求中没有ICID（如呼叫部分不是IMS系统），I-CSCF将为终呼产生ICID。AS作为发起UA时产生ICID。MGCF在PSTN发起会话时产生ICID。每个网元在处理SIP消息时，从CDR中抽出ICID为后续使用。当接收到其它网络的移动终端呼叫时，I-CSCF和S-CSCF同样允许产生一个新的ICID。
   注册消息是一个特例，当P-CSCF收到注册消息时，同样在P-Charging-Vector头中产生ICID。ICID的有效期在3GPP TS 32.260中进行了描述。
   在任何请求中包含了P-Charging-Vector头，该头中包含了ICID参数。但是P-Charging-Vector头是不传递给UE的。
   ICID同样经PDF从P-CSCF到IP-CAN。该接口功能不在本文阐述范围内。
   4.5.3 接入网计费信息
   4.5.3.1 概述
   接入网计费信息是媒体层的数据，它是由IMS用于会话的网元共享使用的，包括主呼和被呼。GPRS计费信息（GGSN标识和PDP上下文）是接入网计费信息的示例。
   4.5.3.2 接入网计费信息
   IP-CAN为IMS提供了接入网计费信息。IMS的CDR与IP-CAN的CDR是关联的，接入网计费信息是在承载层与会话层上进行关联的。
   当资源被分配到IP-CAN时，产生接入网计费信息。接入网计费信息经过PDF通过Go和Gq接口，从IP-CAN传送到P-CSCF。当会话媒体流增加和删除的时候，接入网计费信息将被更新的。P-CSCF向S-CSCF提供接入网计费信息。当在线预付费应用时，S-CSCF可能将接入网计费信息传给AS。起呼网络和终呼网络各自用自身网络的接入网计费信息，在呼叫方和被叫方网络是不共享接入网计费信息的。接入网计费信息也不可能传给外部扩展AS。
   接入网计费信息保存在P-Charging-Vector头中。
   4.5.4 Inter operator identifier (IOI)固有运营标识
   固有运营标识IOI是全局唯一的标识，它由运营网络商、业务提供商、内容提供商所共享。在运营网络商、业务提供商、内容提供商之间存在两种交互的IOI实例。一是发起侧的实例，orig-ioi；另一个终呼侧的，term-ioi。
   在发起网络侧，S-CSCF在P-Charging-Vector头中加入orig-ioi参数，此参数在初始请求中对运营网络进行标识。同样在初始请求消息中，P-Charging-Vector头中不考虑term-ioi参数。当S-CSCF接收到请求的响应时，从响应消息中获得term-ioi参数，该参数则标记了响应的运营网络。
   终呼网络的S-CSCF从请求消息中P-Charging-Vector头，获得orig-ioi，该参数标识了请求发起方的运营网络。终呼网络中的S-CSCF在发送的响应消息中，将term-ioi参数加入P-Charging-Vector头，该参数是响应网络的标识。
   当对话/会话由PSTN/PLMN发起时，MGCF负责加上orig-ioi参数。当对话/会话终止在PSTN/PLMN时，MGCF负责加上term-ioi。
   不可以在网络中传输。只有当MGCF和S-CSCF被BGCF和I-CSCF代理时， IOI可以发送到AS用于计费。
   4.5.5 计费功能地址
   计费功能地址是由归属网络中的IMS网元描述的，它是基于会话层的（无论发起方还是被叫方），它为每个网元发送计费信息提供了一个公共的位置。计费收集功能CCF地址用于离线计费。事件计费功能ECF地址用于在线计费。
   在SIP请求和响应消息体中，P-Charging-Function-Addresses头中可以包括多个CCF和ECF地址参数。至少包括一个CCF地址，额外的地址在各自网络中用作其他用途。ECF用于在线计费，其它ECF地址同样用于其它用途。CCF和ECF地址从归属网络，通过Cx接口从HSS中获得，并经S-CSCF传到下面网元。在归属网络中，计费功能地址经S-CSCF传到其它网元，但是不会传送到拜访网络和UE。当P-CSCF属于拜访网络时，P-CSCF获得计费功能地址的方法不在本文阐述范围内。AS经过ISC接口从S-CSCF处获得计费功能地址。CCF和ECF地址可能如预配置的地址那样分配。AS同样可以通过Sh接口从HSS中获得计费功能地址。
   5 SIP的应用
   5.1 UE的处理过程
   5.1.1 注册和认证
   5.1.1.1 概述
   UE将注册用户的公有标识（参看表A4/1，并依赖于主要能力）。当一个UE同时在不同点注册多个公有用户标识时，对于这些公有用户标识的刷新注册、注销、订阅用户状态的事件包，可以不一致。
   5.1.1.1A ISIM中包含参数
   如果存在ISIM时，ISIM应用总是用于IMS认证，3GPP TS 33.203中进行了描述。在向IMS初始注册前，ISIM要预配置所有必须参数，参数如下：

• PVI私有用户标识；
• 一个或多个公有用户标识
• 用于登记SIP注册请求的归属网络域名
  当UE配置UICC（通用集成电路卡）而没有包含ISIM应用时，UE将：
• 产生私有用户标识；
• 产生一个临时公有用户标识；
• 产生用于登记SIP注册请求的归属网络域名。
  正如C.2章节所述：
  临时公有用户标识仅仅用于注册请求，如初始注册、刷新注册、移动初始注销。如果成功注册后，UE将获得相应的公有用户标识，UE将在后续非注册请求中用任意一个公有用户标识。
  如果临时公有用户标识是被禁止的，UE仍不会向用户显示临时公有用户标识。如果临时公有用户标识在被UE接收的P-Associated-URI头中，则该标识不会被禁止的。如果由于某种原因，UE不能够得到上面段落中的参数，则用到这些参数的请求不会被UE处理，也不能够注册到IMS中去。
  5.1.1.2 初始注册
  当UE获得IP地址，发现P-CSCF，能够建立基于SIP信令的IP承载后，UE可以用contact地址注册一个公有用户标识。但是，UE收到注册请求的最终响应后，或者请求超时，才可以发起新的注册进程。
  在P-CSCF发现过程中，P-CSCF向UE通知一个端口号，UE发送初始注册请求消息到该端口。如果P-CSCF没有通知UE端口号，则UE就将初始注册消息发送到默认端口，见RFC3261中的描述。
  如5.1.1.1A所述，UE可能在注册中获得公有用户标识、私有用户标识、用于Request-URI中的域名。公有用户标识也可以由终端用户输入。
  发送注册请求时，UE将在注册消息中加入如下头字段：
  a) 鉴权头，包括用户名，设置为用户私有标识；
  b) From头，包括将被注册的公有用户标识；
  c) To头，包括将被注册的公有用户标识的SIP URI。
  d) Contact头，包含UE的IP地址，有主端口参数或者FQDN。如果注册请求消息是被安全关联保护的，则UE将在主端口参数中，包括被保护的服务器端口号。
  e) Via头，包含sent-by域值，该字段中包括IP地址或者FQDN。如果注册请求消息被安全关联保护，则UE将在sent-by字段中，包括被保护的服务器端口号。
  注1 ： 如果UE在Contact头主参数和Via头的sent-by字段中指名FQDN值，则必须保证FQDN解决（比如反向DNS查找）IP地址与安全关联绑定关系。
  注2 ： 对于每一对安全关联UE绑定2个端口，被保护的客户端口和服务器端口。端口值在3GPP TS 33.203 中有详述。
  f) Expires头，或者在Contact头中包含expries参数，表示注册有效持续时间，推荐为600000秒。
  注3： 注册机（S-CSCF）可能根据网络策略，降低注册有效时间。注册机中定义了注册有效最小时间（即刷新注册时间），如果UE希望的时间小于该最小时间，则注册机回复423（间隔太短）响应给UE。
  g) Request-URI设置了归属网络的域名的SIP URI；
  h) Security-Client头，包括UE支持的安全机制、UE支持的IPsec层算法、以及安全关联设置的参数。UE将支持两对安全关联，见3GPP TS 33.203 中定义。安全关联的参数语法参见3GPP TS 33.203 的附录H。UE将支持“ipsec-3gpp”安全机制，见RFC3329。UE将支持HMAC-MD5-96 (见RFC 2403 [20C]) 和 HMAC-SHA-1-96 (见RFC 2404 [20D]) IPsec 层的算法，并支持RFC3329中定义的处理过程。
  i) Supportde头，包含选项标记“path”；
  j) 如果存在安全关联，P-Access-Network-Info头中将包括接入网技术；
  一旦接收到200OK响应，UE将：
  a) 存储To头字段中的公有用户标识的注册刷新时间；
  b) 存储P-Associated-URI 头中URIs列表，该列表URIs是与注册的公有用户标识关联的；
  c) 存储P-Associated-URI头中第一个URI作为默认公有用户标识；
  d) 如果在P-Associated-URI头中没有包括的公有用户标识，认为是被禁止的；
  e) 为了为新的对话和事务建立预先路由，UE将存储 Service-Route头中列表；
  f)设置安全关联的周期，取预先存在的安全关联的生命周期（如果存在的话）和完全注册期加上30ｓ的最大值。
  当UE接收到401（鉴权未通过）响应消息时，ＵＥ的行为参看5.1.1.5.1节。
  一旦接收到423（间隔太短）响应，UE将发送另外一个注册请求，新的请求中Expries值最少比423响应消息中Min-Expires头中的最小值来的大。
  5.1.1.3 初始订阅注册状态事件包
  一旦接收到初始注册的2xx最终响应，UE将基于注册机（S-CSCF）中的公有用户标识，订阅注册事件包。
  如果初始注册时使用的公有用户标识是被禁止的，则UE将用默认公有用户标识订阅注册状态。如果初始注册时使用的公有用户标识没有被禁止，则UE即可以使用默认公有用户标识，或者初始注册的公有用户标识，订阅注册状态。
  在发送订阅SUBSCRIBE请求时，UE将在消息体中加入如下头：
  a) Request-URI中设置为UE希望订阅的目标，如包含着用于订阅的公有用户标识；
  b) From头，设置为用于订阅的公有用户标识的SIP URI；
  c) To头，设置用于订阅的公有用户标识
  d) Event头，设置“reg”事件包；
  e) Expries头，值推荐设置为60000s，作为订阅刷新周期；
  f) P-Access-Network-Info头中保存接入网信息；
  g) Contact头中保存着和初始注册消息中一样的，在P地址或者FQDN，以及受保护的服务器端口值；
  一旦收到订阅请求的2xx响应，UE将保存已经建立的对话信息，以及响应消息中Expries字段中刷新时间值。
  如果要求继续订阅，则UE将用reg事件包，为先前注册的公有用户标识自动刷新订阅。自动刷新时间要求：当初始订阅大于1200s时，在时间到期前600s；或者当初始订阅小于1200s时，在时间到一半时。
  5.1.1.4 用户发起的刷新注册
  UE可以在任何时刻，用contact地址，刷新注册先前已经注册的公有用户标识。
  除非用户或者应用决定不要求连续注册，否则UE将进行刷新注册。刷新时间要求如下：如果初始注册刷新时间大于1200s，则在时间到期前600s进行刷新；如果刷新时间小于1200s，则在时间到达一半时进行刷新；或者如RFC3840所述，UE更新能力的时候，进行刷新。
  UE将通过安全关联对注册请求进行保护，参看3GPP TS 33.203 。如果IK可用，将建立早注册状态。根据5.1.1.1节所述过程，UE将从注册消息中，获得公有用户标识、私有用户标识、域名。
  当发送不带挑战响应的注册请求时，UE将在消息中加入如下头：
  a) Authorization头，用户名中设置为私有用户标识；
  b) From头，设置为将被注册的公有用户标识的URI；
  c) To头，设置为将被注册的公有用户标识的URI；
  d) Contact头，设置为UE的IP地址主端口参数或者FQDN，以及与安全关联绑定的受保护的服务器端口；
  e) Via头，在sent-by域中，设置为UE的IP地址或者UE的FQDN，以及与安全关联绑定的受保护的服务器端口；
  注1 ： 如果UE在Contact头主参数和Via头的sent-by字段中指名FQDN值，则必须保证FQDN解决IP地址与安全关联绑定关系。
  注2 ： 对于每一对安全关联UE绑定2个端口，被保护的客户端口和服务器端口。端口值在3GPP TS 33.203 中有详述
  f) Expires头，或者在Contact头中包含expries参数，表示注册有效持续时间，推荐为600000秒。
  注3： 注册机（S-CSCF）可能根据网络策略，降低注册有效时间。注册机中定义了注册有效最小时间（即刷新注册时间），如果UE希望的时间小于该最小时间，则注册机回复423（间隔太短）响应给UE。
  g) Request-URI设置了归属网络的域名；
  h) Security-Client头，包括UE支持的安全机制、UE支持的IPsec层算法、以及安全关联设置的参数。UE将支持两对安全关联，见3GPP TS 33.203 中定义和RFC3329。
  i) Security-Verify头，包含上一次成功认证410响应中Security-Server头中的内容；
  j) Supported头，包含选项标记“path”；
  k) P-Access-Network-Info头，设置为接入网络信息（参看7.2.A.4）
  一旦接收到刷新请求的200OK响应，UE将：
  a) 存储To头字段中的公有用户标识的新注册刷新时间；
  b) 存储P-Associated-URI 头中URIs列表，该列表URIs是与注册的公有用户标识关联的；
  c) 为了为新的对话和事务建立预先路由，UE将存储 Service-Route头中列表；
  d) 设置安全关联的周期，取预先存在的安全关联的生命周期和完全注册期加上３０ｓ的值，两者中最大值。
  将UE收到请求对应的401（未鉴权）响应时，UE行为参见5.1.1.5.1。
  一旦接收到423（间隔太短）响应，UE将发送另外一个注册请求，新的请求中Expries值最少比423响应消息中Min-Expires头中的最小值来的大。
  一旦接收到408（请求超时）或者500（服务器错误）或者504（服务器超时）响应，UE将执行5.1.1.2节描述的初始注册处理流程。
  当UE中定时器F（SIP定义的定时器，对于非Invite事务总时间）超时时，将：

1. 结束所以进行中的对话和事务，并释放他们；
2. 根据9.2.2的处理流程，释放用于媒体传输的IP-CAN承载资源；
   a) 在9.2.1节描述了，从发现的P-CSCF地址列表中，选择一个不同的P-CSCF地址；
   b) 如果UE联系所有P-CSCF地址，都没有响应，UE可能如9.2.1所述，获得一组新的P-CSCF地址；
   c) 执行5.1.1.2描述的初始注册流程；
   注 4 ： 基于ICMP（网间控制报文协议）消息，决定了除了定时器F超时外，其他方法是否触发上述执行操作选项。
   如果连续5次初始注册不成功，在30分钟内，UE将禁止自动发起新的初始注册。
   5.1.1.5 认证
   5.1.1.5.1 概述
   在注册和刷新注册流程中需要认证。当网络要求认证或者再认证时，对于发起的注册请求，UE将接收到401（未认证）响应。
   一旦接收到401（未认证）响应，UE将作如下操作：
3. 获得RAND和AUTN参数值；
4. 如3GPP TS 33.203描述，检查接收到的挑战信息的有效性。如：本地计算出的XMAC必须与从AUTN参数中获得的MAN匹配；从挑战信息中AUTN参数中获得的SQN必须在正确的范围内。
5. 根据RFC3329检查Security-Server header头的存在属性。如果该头不存在或者没有包含安全关联设置的必须的参数（参看3GPP TS 33.203附录H），UE将废弃认证处理流程，用一个新的Call-ID发送一个新的注册请求。
   如果401（未鉴权）响应被认为是有效的，则UE将执行如下操作：
6. 如3GPP TS 33.203 的描述，计算RES响应，并从RAND中获得CK、IK；
7. UE基于接收到的401响应中的静态列表和参数，以及发送的注册请求消息Security-Client头中的能力，设置一套临时的安全关联配置。UE设置安全关联配置时，首选P-CSCF返回的同时又是UE支持的最高级别的机制和算法，IK作为共享密钥。UE将用P-CSCF返回的响应消息中的Security-Server头内容设置安全关联。UE将为临时安全关联配置，并设置临时SIP层生命期，为注册等待认证定时器值。
8. 发送第二条注册请求，该请求消息体采用临时安全关联设置进行保护。在第一条请求消息内容外，第二条注册请求还包括鉴权头，鉴权头中包括私有用户标识，以及基于RES和其他参数由UE计算得到的挑战响应，计算方法见RFC3310。第二条注册请求中同样要求插入 Security-Client头，内容如第一条注册请求。同时UE在第二条注册请求中还将插入Security-Verify头，反映出401响应中Security-Server头内容。UE将对第二条注册请求进行完整性保护。该请求中的Call-ID要求与截带挑战信息的401响应的Call-ID值相同。
   一旦收到带有完整性保护的注册请求的200ok响应，UE将

• 改变安全关联的临时设置，去建立一个新的安全关联，比如设置SIP层生命期，该时间值取先前存在的安全关联SIP层生命期和完成注册的生命期加30s的值中的最大值。
• 后续发往P-CSCF的消息将用新的安全关联设置。
  注1 ： 在上述情况下，UE将基于新的安全关联配置向P-CSCF发送请求。基于UDP层，发往P-CSCF的响应将采用新的安全关联；基于TCP层，发往P-CSCF的响应将采用与接收到请求的安全关联一样的设置。
  当第一条请求或者收到从P-CSCF基于新建立的安全关联的响应后，UE将删除老的安全关联设置，以及关联密钥，但要求在所有老的安全关联基础上的SIP事务全部完成后。
  当临时SIP层生命期到期UE还没有收到最终200OK响应，或者UE收到403（禁止）响应时，UE将认为注册失败。此时，UE将删除试图建立的临时安全关联设置，用老的安全关联。如果UE认为老的安全关联不再被P-CSCF激活，UE将根据5.1.1.2节描述，发送不受保护的注册请求。
  当401（未认证）响应被认为是无效的，ＵＥ将进行一定的操作，见5.1.1.5.3中的定义。
  5.1.1.5.2 网络发起的再认证
  在任一时刻，UE可能收到NOTIFY请求，该请求截带与注册事件包相关的信息，如果：
• 中的状态属性元素设置为“active”；
• 在 子元素中，子元素值设置为UE已经注册的contact地址。
• 中子元素事件属性设置为“shortened” ；
  UE将：

1. 用子元素中expriy值，修改公有用户标识的expiration值。
2. 如果需要，通过发起5.1.1.4中表述的刷新注册，在适当时候开始重认证过程（5.4.1.6中描述的S-CSCF处理结果）
   注意： 当认证一个给出的私有用户标识时，S-CSCF将利用该私有标识已经注册的子元素expiry值，去缩短expiry值。如果中对应的公有用户标识，同时被不同的私有用户标识注册，那么该元素不会改变。如果元素没有修改，UE将不可以发起刷新注册流程。
   5.1.1.5.3 异常案例
   如果对于401（未鉴权）响应，MAC和SQN是不正确的，UE将向S-CSCF发送进一步注册，指出挑战信息无效，具体案例如下：

• 当UE认为MAC参数无效时，后续注册请求将不再包含认证响应、没有AUTS参数；
• 当UE认为SQN超出了范围时，后续注册请求将包含AUTS参数，没有认证挑战响应（参看3GPP TS 33.102 [18]）。
  UE一旦检测到上述情况出现，UE将：
• 如果安全关联有效（参看3GPP TS 33.203 ），将采用存在的安全关联，发送注册请求。
• 在注册请求中加入新的Security-Client头，设置为支持的安全机制、IPsec层算法、及其他参数。
• 不创建临时安全关联设置。
  UE仅仅连续响应两次无效的挑战信息，当发生连续两次无效挑战信息时，UE必须等待特定时间后，才可以再次发起注册请求。
  5.1.1.5A 基于保密的Ipv6地址改变
  在RFC 2462 [20E]中描述了无状态地址的自动配置，其中定义了UE如何用IPv6前缀和接口标识，构建一个完全IPv6地址。如果UE接收到一个IPv6前缀，UE将出于保密的考虑改变IPv6地址的接口标识，见RFC 3041 [25A]的描述。但是这样将导致IMS服务的不连续性。
  注意 ： 下面描述的流程将终止所有已建立的对话、事务、临时断开ＵＥ与IMS的联系，直到执行新的注册。基于此，UE被推荐提供一个流程有限的使用，确保终端用户最大程度的连续服务。
  为了保密考虑，改变IPv6地址，UE将：

1. 终止所有正在进行的会话（包括对话）和事务（注册事件包的订阅）；
2. 如5.1.1.4所述，注销所有已注册的公有用户标识；
3. 根据RFC3041，构建一个新的IPv6地址；
4. register the public user identities that were deregistered in step 2 above, as follows: 按照下面的操作，注册上面第二步中注销的公有用户标识；
   a) 如5.1.1.2执行初始注册；
   b)并，如5.1.1.3所述执行向注册事件包的订阅
5. 在IPv6地址开始变化前，订阅其他事件包。

5.1.1.6 用户发起的注销
UE可以在任意时刻注销一个公有用户标识，该标识先前已经与contact地址注册。
UE将用安全关联对注册请求进行完整性保护，参看3GPP TS 33.203 ，就如建立一个早注册。UE将从注册消息中，获得用户的公有用户标识、私有用户标识、域名，见5.1.1.A节。
首先UE发送一个用于注销的注册请求，而后UE将释放所有与被注销的公有用户标识相关的对话，或者释放隐式注册的多个公有标识。
在发送注册请求时，UE将对该消息添加消息头，具体处理如下：
a) Authorization头，在username字段中设置为私有用户标识；
b) From头，设置将被注销的公有用户标识的SIP URI；
c) To头，设置将被注销的公有用户标识的SIP URI；
d) contact头，设置为“*”，或者UE的IP地址主端口参数，或者FQDN和与安全关联绑定的受保护的服务器端口值；
e) Via头，在sent-by域中，设置为UE的IP地址或者FQDN，以及与安全关联绑定的受保护的服务器端口值；
注1 ： 如果UE在Contact头主参数和Via头的sent-by字段中指名FQDN值，则必须保证FQDN解决IP地址与安全关联绑定关系。
f) Expires头，或者contact头expries参数，设置为0；
g) Request-URI设置为归属网络域名的SIP URI；
h) P-Access-Network-Info头设置为接入网信息（参看7.2A.4节）
一旦接收到注册请求的200OK响应，UE将删除所有与公有用户标识相关的信息。
如果不是多个公有用户标识被注册，UE将删除安全关联和关联密钥。
如果所有公有用户标识被注销，安全关联被删除，UE将考虑订阅来取消注册事件包（如，ＵＥ发送一个订阅消息，消息中expires值设置为0）

注意： 在隐式注册过程中，对一个公有标识注册时，其他公有用户标识也被注册，但对该公有标识发起的注销，UE收到200OK注销响应后，UE删除UE与P-CSCF之间建立的安全关联。所以后续SIP信令（如包含注销事件的NOTIFY请求）不会到达UE。
5.1.1.7 网络发起的注销
见5.1.1.3节，在订阅注册事件包时，UE一旦接收到对话中NOTIFY请求，请求中包括一个或者多个元素，这些元素都是UE已经注册的。

• 状态属性设置为"terminated"，并且事件设置为"rejected" 或"deactivated"；或者
  

• 状态属性设置为"active"，<contact>元素中与状态属性相关的设置为"terminated"，相关的事件属性设置为“rejected”
  

UE将删除所有与那些公有用户标识相关的信息。当事件属性是"deactivated"时，UE将开始初始注册，见 5.1.1.2.。当事件属性是"rejected"时，UE将释放所有与公有用户标识相关的对话。
一旦接收到NOTIFY请求，UE将删除与P-CSCF之间的安全关联：

• 如果中状态属性设置为"terminated"（也就是所有公有用户标识被注销），并且订阅状态Subscription-State头重包含"terminated"；或者
• 如果每个元素都是被ＵＥ注册的，其中状态属性设置为"terminated" 或者"active"，且中的状态属性是"terminated"。
  UE将对应于接收到的NOTIFY请求的服务器事务（RFC3261中定义）终止，UE将删除与P-CSCF之间的安全关联。
  注 1 ： 删除安全关联是内部处理流程，不包括任何SIP流程。
  注 2： 如果所有的公有用户表示或者注册的contact地址都被注销，且安全关联也被删除，则UE认为注册事件包的订阅将被终止（比如UE发送订阅请求，请求中expires头为0；或者NOTIFY请求中Subscription-State 头设置为"terminated"）。
  注 3 ： 当P-CSCF删除与UE建立的安全关联，后续SIP信令（如包含注销的NOTIFY消息）将不会到达UE。
  5.1.2 订阅和通知
  5.1.2.1 通知多个注册的公有用户标识
  一旦接收到订阅请求的2xx响应，UE将维持产生的对话（对话的标识是由Call-ID, To 和 From组成）。
  在订阅注册事件包而产生的对话中，一旦接收到一个NOTIFY请求，UE将执行下面操作：
• 如果状态属性是"active"，UE将存储指示的公有用户标识，作为已注册用户；
• 如果状态属性是"terminated"，UE将存储指示的公有用户标识，作为注销用户。
  注意： 在S-CSCF中注册一个公有用户标识时，可能自动注册多个公有用户标识。通常这些自动或者隐式注册的公有用户标识属于同样的业务配置，并且对UE来说是不可用的。隐式注册的公有用户标识可能属于不同的业务配置。这里描述的处理流程提供了不同的机制（注册请求的200OK响应）去通知UE关于这些自动注册的公有用户标识。
  5.1.2.2 产生订阅请求
  对于包含Retry-After头的初始订阅请求，如果UA接收到503（服务器不可用）响应，直到Retry-After头中周期时间到期，否则UE不会自动发起请求。

5.1.2A 应用于除了REGISTER以外的所有方法（method）的通用流程
5.1.2A.1 起呼（MO）情形
本节的流程适用于除了REGISTER之外其他方法的请求和响应。
当UE发送任何请求，UE将：
――在与UE相关Via头中包含有被保护的服务器端口；并且
――如果包含有contact头，在任何contact头包含有被保护服务器端口.
UE丢弃任何来自P-CSCF的非注册和鉴权流程的没有经过完整性保护的SIP响应。关于UE在注册和鉴权流程中的要求在5.1.1节描述。
与RFC3325[34]一致，对于一个对话初始请求或者独立事务的请求，UE可能插入P-Preferred-Identity头，作为在IM CN子系统内产生asserted（确定的）标识的线索（hint）。UE在P-Preferred-Identity头中可能包含以下信息：
――用户注册过的用户公有标识；
――用户公有标识，该标识是由Notify请求的注册状态事件包（registration-state even packaget）返回的，是没有后续的注销或者没有过期的隐含注册的结果；或者
――任何其他的公有标识，该标识假使被本规范之外的某一机制进行注册。
.注1：在5.1.1.1节描述的临时公有标识不适合在P-Preferred-Identity头中使用；
.注2：在P-Preferred-Identity中使用电话号码时，网络流程要求国际公用通信号码；
.注3：许多头都可能显示用户标识的信息。在要求的隐私的地方，实现者应该考虑到其他消息头可能暴露标识信息。RFC3323[33]节4.1中对这些相关头进行了考虑。
在要求隐私的情形，对于对话的初始请求或者独立事务的请求，UE设置From头为“Anonymous（匿名）”。
注4：基于任何隐私指定的From头的内容不应该依赖于网络修改，该隐私可能由UE隐私指示中的用户或者网络签约或者网络策略来指定。因此，只要是明显地要求隐私，用户应该包含“Anonymous”。用户有隐私要求，终端制造商不应自动从公有标识或者其他保存或者从UICC获得的值包含在该From消息头中。如果在最终实现的配置上没有明确表示优先采用隐私还是不隐私的情况下，实现的时候采用隐私。对于要求标识自己的用户，并且和IM CN子系统以外的SIP目的端建立呼叫，同时目的端没有实现RFC3325[34]，在From头中需要包含一个确定的值，而不是Anonymous。
依照RFC3323[33]，UE可能指示由P-CSCF产生的P-Asserted-Identity的隐私，在RFC3325[34]包含有另外的要求。
在对话的任何请求，以及对话内的后续请求（除了ACK请求和CANCEL请求）或者响应（除了CANCEL响应）中或者一个独立方法的任何请求中，UE将插入P-Access-Network-Info消息头。UE利用带有IP-CAN当前附着点的P-Access-Network-Info消息头表明了接入网络技术（见7.2A.4节）。
注5：在对话期间，UE的IP-CAN附着点可能会变（如，UE连接到不同的cell）。UE在对话内的请求或者响应中携带的P-Access-Network-Info头应该为当前附着点（如当前的cell信息）；
UE将为所有新的对话和独立事务形成适当的预加载（preloaded）Route消息头。UE依次按照P-CSCF URI(包含重发现流程获得的IP地址或者FQDN，注册流程获得的保护端口)，以及从注册或者重注册的200OK响应保存下来的Service-Route值的顺序形成Route消息头表。
当SIP事务超时，如UE的timer B，timer F或者timer H超时，UE可能按照timer F超时进行后续处理，见5.1.1.4节。
注6：这些动作是否可以被其他方法触发取决于实现的选项。
5.1.2A.2 终呼（MT）情形
本节的流程对于除了REGISTER之外的其他方法的请求和响应适用。
当UE发送任何响应，UE将：
――如果存在contact头，则包含有被保护的服务器端口。
UE丢弃任何来自P-CSCF的非注册和鉴权流程的没有经过完整性保护的SIP请求。
对于注册和鉴权的流程UE的要求在5.1.1中描述。
UE能指示P-Asserted-Identity隐私，P-Asserted-Identity按照RFC3323[33]由P-CSCF产生，在RFC3325[34]包含有另外的要求。
注1：在终呼的情形中，本版本还没有为UE提供hint（线索）形式的P-Preferred-Identity。
注2：许多头都可能显示用户标识的信息。在要求的隐私的地方，实现者应该考虑到其他头可能暴露标识信息。RFC3323[33]节4.1中对这些相关头进行了考虑。
在对话请求的任何响应，以及对话内的后续请求（除了CANCEL请求）或者响应（除了CANCEL响应）中或者一个Standalone单独方法的任何响应中，UE将插入P-Access-Network-Info消息头。UE利用带有IP-CAN当附着点的P-Access-Network-Info消息头表明了接入网络技术（见7.2A.4节）。
5.1.3 初始呼叫－起呼情形
5.1.3.1 初始INVITE请求
5.1.3.1.1 概要
5.1.3.1节描述了UE发起的初始INVITE的流程。使用“资源管理和SIP综合”扩展（本节即为SIP 预置资源(precondition)机制，见RFC 3312 [30]定义，被draft-ietf-sip-rfc3312-update [64]更新，使用该机制的请求即称为一个前提(a precondition)）的缺省行为在5.1.3.1.2.1节进行描述。当以下条件存在，可能进行没有预置资源(precondition)的初始会话：
――当远程节点不支持precondition机制，见5.1.3.1.3；或者
――当特殊的业务不要求precondition机制，见5.1.3.1.4。
编者按：什么时候使用non-precondition流程/资源预留的细化规则要么来自stage 2要么包含在3GPP TS 23.228规范中。
UE可能通过在初始INVITE请求中的Request-Disposition头包含”no-fork”的指示来显示proxy代理不fork INVITE请求，见RFC3841[56B]描述。
注1：依照RFC3261[26]，表A.4指出UE要求能对forking的支持。例如，如果UE能够支持一定数量的并发事务或者早对话，UE可能接受或者拒绝forked响应。
当收到某一个早对话的最终响应时，UE继续建立SIP会话。UE并不会将任何当前的早对话处理成已经建立的对话。因此，收到INVITE的后续最终200(OK)响应（例如，由于forking），UE将：
1） 用ACK请求确认该响应；并且
2） 为了终止该对话发送BYE请求给该对话。
如果UA发送初始INVITE请求收到503（业务无效）响应，并且包含有Retry-After头，UE只有在Retry-After头指示的周期后才会自动重新发起请求。
如果UE发送初始INVITE请求收到的488(非可接受)响应，UE应该发送一个新的INVITE请求，包含有SDP（按照6.1节流程所述）。
注2：如果新请求不发送，不会与UE达成共识或者和用户交互，导致没有迎合用户需求的SDP描述一个会话。

5.1.3.1.2 起呼UE要求的“资源管理和SIP综合”
使用preconditions产生初始INVITE请求时，UE将：
――标识对可靠临时响应的支持，并使用Supported头来指定这一点；
――标识对preconditions机制的需求，并使用Require头指定这一点。
当初始的INVITE已经产生并发送，接下来的流程和5.1.3.1.1描述的流程一样。
如果UE接收了对初始的INVITE请求的420（错误扩展）响应，响应消息的Unsupported头带有“precondition”可选tag，UE将：
a) 忽略该此会话，并不重发在Require带有“precondition”可选tag的INVITE请求，或者
b) 通过在使用precondition机制时降低需求，尽量完成这次会话并按5.1.3.1.3和6.1描述的流程进行。

5.1.3.1.3起呼UE要求“资源管理和SIP综合”而终呼UE不支持
对初始INVITE请求，收到420（错误扩展）响应，该响应在Unsupported头中包含有“precondition”可选tag，此时流程开始。
此时，UE可能产生INVITE请求向初始的INVITE的同样的目的地址发送。当产生新的INVITE请求时，UE将：

1. 和初始INVITE请求一样，带有From,To, Call-ID头以及Request-URI；
2. 在Supported头中包含“precondition”可选tag；
   3)按照6.1节描述的一样使用非激活模式的SDP设置每个媒体流，为了阻止终端侧发送媒体，而起呼侧还没有资源预留；并且
   4)按照正规流程前转INVITE请求。
   收到包含有远端SDP的临时响应或者最终响应时，UE将：
3. 如果是按照RFC3261[26]和RFC3262[27]定义的正规的SIP流程一样，回SIP确认响应；并且
4. 发起正常的资源预留机制。
   当以上的INVITE事务成功完成，并且本地资源预留流程完成时，UE产生和前转re-INVITE请求，包含：
5. From，To，Call-ID头；并且
   2）以前设置的非激活模式的媒体流的SDP设置为激活（sendrecv,sendonly或者recvonly）模式，按照6.1节流程完成。

5.1.3.1.4起呼UE不要求的“资源管理和SIP综合”
起呼UE建立会话不要求precondition机制，此流程开始。
UE产生的初始INVITE请求中可能在Supported头中包含有“precondition”。
当初始的INVITE请求产生并前转后，接下来的流程按照5.1.3.1.1中描述进行。

5.1.4 初始呼叫－终呼情形

5.1.4.1 初始INVITE请求
5.1.4.1.1 一般情形
终呼UE对入呼的初始INVITE请求主要依赖于下列条件：
――对“资源管理和SIP综合”扩展（本节即为SIP 前提(precondition)机制，见RFC 3312 [30]定义，被draft-ietf-sip-rfc3312-update [64]更新，使用该机制的请求即称为一个前提(a precondition)）的特殊业务需求；以及
――特殊的业务不要求precondition时的UE配置。
编者按：关于什么时候使用non-precondition流程/资源预留的具体规则可以从stage2获得或者在3GPP TS23.228获得。
如果收到初始INVITE请求，终呼UE要么通过被请求的业务要么通过本地配置要求资源管理的综合。
如果终呼UE要求资源管理，并且：
a) 收到的INVITE请求中Require头包含有“precondition”可选tag，终呼UE将按5.1.4.1.2执行；
b) 收到的INVITE请求中Require头没包含“precondition”可选tag，并且基于本地配置，终呼UE又需要使用precondition机制，终呼UE将按5.1.4.1.3进行；或者
c) 收到的INVITE请求中Require头没包含“precondition”可选tag，并且基于本地配置，终呼UE也不需要使用precondition机制，终呼UE将按5.1.4.1.4进行；

如果终呼UE不要求资源管理，并且：
a) 收到的INVITE请求中Require头包含“precondition”可选tag，终呼按照5.1.4.1.2进行，例如，为了完成起呼UE的需求，终呼UE将使用precondition机制；或者
b) 收到的INVITE请求中Require头没包含“precondition”可选tag，终呼按照5.1.4.1.4进行。
注意：按照RFC3261[26],表A.4表明了UE对forking的支持。
编者按：以上note需要更加进一步的研究。

5.1.4.1.2 终呼和起呼都要求“资源管理和SIP的综合”
终呼UE产生了对初始INVITE请求的第一次响应，响应Require头包含有“precondition”可选tag，UE将指示可靠临时响应的需求并使用Require头来指明。UE只有在本地资源预留成功并且最终用户接受呼叫后，才发送200（OK）响应给初始INVITE请求。

5.1.4.1.3起呼不使用“资源管理和SIP的综合”
收到的初始INVITE请求消息的Require头中没有“precondition”可选tag，并且终呼要求precondition机制，终呼UE将回421（要求扩展Extension Required）响应，响应在Require消息头中的值指示需要扩展。

5.1.4.1.4终呼和起呼都不要求“资源管理和SIP的综合”
收到初始INVITE请求在Require头中没有“precondition”可选tag，并且终呼UE被配置为不要求precondition机制，UE将：

1. 发送零个或者多个临时响应（如183）；并且
2. 当资源有效并且呼叫被最终用户接受后，发送200（OK）响应。

5.1.5 呼叫释放
void

5.1.6 紧急业务
当UE检测到所拨号码为紧急号码时，UE不会通过IMS建立一个紧急会话。UE将按照3GPP TS 24.008[8]使用CS域。
UE发送INVITE请求后收到380（Alternative Service）响应，响应中包含有XML消息体，该消息体又包含带有设置为“emergency”子元素的元素，UE将自动：
――发送ACK请求给P-CSCF，作为正常的SIP流程；
――通过3GPP TS 24.008[8]建立紧急呼叫。
UE也可能通过带有文本描述的元素的给用户指示。
总之，在MS操作模式C中UE不能执行紧急呼叫。
5.2 P-CSCF的处理过程
5.2.1 概述
P-CSCF将支持Path和Service-Route头。
注1 ： Path头仅仅应用在REGISTER请求和它的200OK响应中。Service-Route头应用于注册请求的200OK响应消息中。
P-CSCF在向UE发送任何请求或者响应时，在发送消息前，P-CSCF将：

• 如果存在P-Charging-Function-Addresses 和P-Charging-Vector头时，需要去除该头字段。
  一旦P-CSCF接收到UE发出的任何响应或者请求，P-CSCF将：
• 如果存在P-Charging-Function-Addresses 和P-Charging-Vector头时，需要去除该头字段。同时，P-CSCF忽略该头字段中的数据。
• 在传递该消息时，可以插入先前保存的数据到the P-Charging-Function-Addresses 和P-Charging-Vector 头中。
  注2： 如果P-CSCF部署在拜访网络时，它将不接收S-CSCF和I-CSCF发送来的消息的P-Charging-Function-Addresses头。替而代之，P-CSCF通过其他方法获得计费功能地址。
  When the P-CSCF receives any request or response containing the P-Media-Authorization header from the S-CSCF, the P-CSCF shall remove the header. 当P-CSCF接收到来自S-CSCF的任何请求和响应，P-CSCF将去除消息体中P-Media-Authorization头。
  注3： 如果基于本地策略业务应用时，P-CSCF将插入P-Media-Authorization头，见5.2.7.2 和5.2.7.3。
  注4： P-CSCF将对发往UE的注册和认证以外的SIP消息，进行安全性保护。P-CSCF将丢弃没有完整性保护的sip消息（注册和认证消息除外）。注册和认证处理中完整性保护和检查在5.2.2中进行了定义。
  除了305（用户代理）响应，P-CSCF不会重复回复3xx响应。
  5.2.2 注册
  根据RFC3261描述，P-CSCF将用SIP默认端口接收初始注册请求。P-CSCF同样准备用UE在发现P-CSCF过程中获得的端口号，进行接收初始注册请求。当P-CSCF接收到一个UE发起的注册请求，P-CSCF将：

1. 在消息体中插入一个Path头，包含下面条目：

• 标识P-CSCF的SIP URI值；
• 对目标路径的请求路由指示（如从S-CSCF到P-CSCF），期望作为移动终端案例。这个指示可能是URI的参数中，或URI的用户部分的字符串，或者一个URI的端口号。

2. 插入Require头，包括“path”选项标签；
3. 插入P-Charging-Vector头，设置icid参数，参看3GPP TS 32.260 [17]中的描述；
4. 当注册请求受到认证过程中的完整性保护且包括认证挑战响应，或者该请求在成功认证后安全关联创建且没有认证挑战响应时，在Authorization头中，插入"integrity-protected"参数值设置为"yes"，其他情况该参数设置为“No”。
5. 当注册请求没有完整性保护时，将检查Security-Client是否存在。如果存在，则去除并保存之，如果不存在，P-CSCF则回复4xx响应。
6. 当注册请求带有完整性保护，则P-CSCF将：
   a) 检查受保护请求的安全关联。如果安全关联是一个临时的，于是请求消息中期望带上Security-Verify 和 a Security-Client头。如果没有这个头，P-CSCF将返回4xx响应。如果有这个头，P-CSCF将对比请求消息中Security-Verify和P-CSCF发送给UE的认证消息中Security-Server内容，以及请求中Security-Client和被挑战注册请求中Security-Client内容。如果不匹配，可能存在中间攻击。该请求应该被拒绝，通过发送4xx响应。如果匹配，P-CSCF将去除Security-Verify 和 the Security-Client头。
   b) 如果注册请求中安全关联已经建立，则：

• 消息体中如果有Security-Verify头，则P-CSCF将去除之；
• Security-Client头中包含新的参数值，如果缺少该头或者必须的参数，P-CSCF将返回4xx响应。
• P-CSCF将传递消息给S-CSCF前，将保存并去除Security-Client头中内容；
  c) P-CSCF将检查具有完整性保护的注册消息中Authorization头中的私有用户标识是否与先前被挑战或被认证的私有用户标识一致。如果不同，P-CSCF回复403（禁止）响应。

7. 插入P-Visited-Network-ID头，设置为先前提供的，用于标识拜访网络的值。
8. 决定归属网络的I-CSCF，并将请求消息发往该I-CSCF。
   如果被选择的I-CSCF：

• 不响应注册请求，仅作为中继，或者
• 对于注册请求，发送3xx（重定向）响应和480（临时无效）响应，
  则P-CSCF将选择一个新的I-CSCF，并发送初始的注册请求。
  注1： I-CSCF的列表可以是RFC3263中描述获得，或者在P-CSCF中设定的。
  如果P-CSCF传递注册请求到I-CSCF失败，P-CSCF将发送408（请求超时）响应或者504（服务器超时）响应，参看RFC3261处理过程。
  当P-CSCF接收到注册请求的401（未鉴权）响应时：

1. 删除与ＵＥ之间，临时建立的安全关联；
2. 移除４０１响应消息中的CK IK参数，并与对应的私有用户标识和临时安全关联进行绑定。当移除CK、IK后，P-CSCF将传递401响应给UE。
3. 插入Security-Server头，头中包括P-CSCF静态安全列表和3GPP TS 33.203 附录H中描述的安全关联参数。在RFC3329中，P-CSCF将支持"ipsec-3gpp"安全机制。在Ipsec层算法上， P-CSCF 将支持HMAC-MD5-96 (RFC 2403 [20C]) 和HMAC-SHA-1-96 (RFC 2404 [20D]) ；
4. 利用UE和P-CSCF之间私有用户标识的临时SIP层生命期，建立一个临时安全关联。进一步描述参看3GPP TS 33.203 [19] 和 RFC 3329 [48]。P-CSCF将设置临时SIP层生命期为临时安全关联等待注册鉴权时间。
5. 用注册请求受保护的安全关联向UE发送401响应，或者用注册请求没有受保护的安全关联发送响应。
   注2： S-CSCF发送到UE的401挑战响应，作为注册的响应，P-CSCF插入Security-Server头。P-CSCF在注册过程中，和UE之间协商和设置两套安全关联设置，S-CSCF将对UE进行认证。进一步的描述参看3GPP TS 33.203 [19]。
   当P-CSCF接收到注册请求的200OK响应时，P-CSCF将检查Expires头或者contact头中expires中的值。如果值不等于0，P-CSCF将：
6. 按照顺序保存Service-Route头列表，P-CSCF将为各个公有用户标识保存注册有效期。P-CSCF将用列表作为可用路由信息。如果注册是刷新注册，P-CSCF将取代已存在的Service-Route列表。
7. 关联Service-Route头列表和已注册的公有用户标识（难道不同pui会不同的Service-Route？）；
8. 存储P-Associated-URI头中，与注册的公有用户标识相关联的公有用户标识。
9. 存储P-Associated-URI头列表中第一公有用户标识作为默认公有用户标识，以便后续使用。
   注3： 当多个公有用户标识注册时，P-CSCF可能存储多个默认公有用户标识。
10. 存储P-Charging-Function-Addresses中的值；
11. 如果安全关联有效，设置安全关联的SIP层生命期，采用先前存在的安全关联生命期和完成的注册生命期加上30s，两者间的最大值。
12. 如果存在的是临时安全关联，则改变其为新的安全关联设置，比如采用先前存在的安全关联生命期和完成的注册生命期加上30s，两者间的最大值来设置SIP层生命期。
13. 采用请求消息采用的安全关联的保护措施，进行200OK响应的保护。
    当P-CSCF从UE接收到基于新的安全关联的SIP消息（包括注册请求），而P-CSCF侧还没有使用新的安全关联，则：
14. 减少安全关联老的设置的SIP层生命期为64T1（如果当前值大于64T1）；
15. 对后续给UE的消息采用新建立的安全设置（如将新建立的安全关联投入使用）。
    注４： 在上述情况下，P-CSCF将基于新建立的安全关联 发送请求到UE。在UDP层，发送给UE的响应采用新建立的安全关联；在TCP层，发送给UE的响应采用与请求一致的安全关联。
    注5： 当从UE接收到SIP消息（包括注册请求）采用一套不同于P-CSCF新建立的安全关联设置，P-CSCF将不会对安全关联设置采取任何行为。
    当老的安全关联的SIP层生命期到期，如SIP层生命期小于64*T1，并且新建立安全关联还未建立使用，对后续发往UE的消息，P-CSCF将用新建立的安全关联（见注３）。
    当P-CSCF发送注册请求的200OK响应中，包括re-authentication，P-CSCF将：
16. 保持用于重认证的注册请求的安全关联设置；
    2)保存在认证过程中新建立的安全关联；
17. 如果存在其他安全关联设置，删除之；
18. 对于后续发送给UE的请求，继续使用用于重认证的注册请求的安全关联设置。
    当发送决定初始认证的注册请求的200OK响应时，如初始注册请求未受保护，P-CSCF将：
19. 保存在认证过程中创建的安全关联设置；
20. 如果存在其他安全关联设置，删除之；
21. 在后续发给UE的消息，采用新建立的安全关联设置。
    注6 ： P-CSCF保持着两套路由头列表。第一套路由头列表是注册时创建的，仅用于UE发起的初始请求。这个列表对每个公有用户标识的注册有效。第二套路由列表是在从初始Invite消息和关联响应的Record Route头中构建的，用于对话的过程中。一旦对话终止，则丢弃第二套路由列表。
    当SIP层生命期超时，P-CSCF将从Ipsec数据库中删除安全关联。
    表5.2.2-1概述了安全关联在P-CSCF中的处理：
    表5.2.2.1 P-CSCF中安全关联的处理
    临时安全关联设置 新建立的安全关联 老的安全关联设置
    接收到的SIP消息基于新建立的安全关联，但新建立的安全关联还未使用 无反应 投入使用 如果SIP层生命期大于64T1，则将生命期减为64T1
    接收到的SIP消息基于老的安全关联 无反应 无反应 无反应
    老安全关联将在64*T1时超时 无反应 投入使用 无反应
    对于注册请求发送一个401的响应 移除先前存在的临时安全关联 无反应 无反应
    发送决定重认证得注册请求的200OK响应， 改变为新的安全关联设置 转换并作为老的安全关联 继续使用初始重认证时老的安全关联，删除所有其他老的安全关联设置
    发送决定初始认证的注册请求的200OK响应 改变到新建立的安全关联并投入使用 转换到老的安全关联，并删除新的 删除

5.2.3 订阅注册用户状态事件包
一旦接收到用户注册请求的200OK响应，P-CSCF将向S-CSCF订阅注册事件包，RFC3680中有描述。

1. 产生一个订阅请求，包括下面元素：

• Request-URI设置为P-CSCF希望订阅的源，比如默认公有用户标识的SIP URI；
• From头，设置为P-CSCF的SIP URI；
• To头，设置为包含默认公有用户标识的SIP URI；
• Event头，设置为“reg”；
• Expires头，设置为注册请求200OK响应中Expires头的值大；
• P-Asserted-Identity头，设置P-CSCF的SIP URI，该P-CSCF是在用户注册Path头中插入的那个P-CSCF。
• P-Charging-Vector头，包括TS 32.260描述的icid参数；

2. 决定归属网络的I-CSCF（如用DNS服务）；了
   发送订阅请求去I-CSCF前的处理过程见RFC3261。
   一旦接收到订阅请求的2xx响应，P-CSCF将存储已建立的对话的信息，和Expires头中的超期时间值。
   如果要求连续订阅，则在先前注册的公有用户标识超期前600s，或者当初始订阅超期时间大于1200s时，在超期前600s时，或者当初始订阅超期时间小于1200s时，在超过一半时间时，P-CSCF将用注册事件包自动刷新订阅。
   5.2.4 多公有用户标识的注册
   一旦接收到订阅请求的2xx响应，P-CSCF将维持产生的对话（对话是通过Call-ID, To 和From标识的）
   在订阅注册事件包过程中产生了对话，一旦接收到一个关于该对话的NOTIFY请求，P-CSCF将执行如下操作：
3. 对于每个公有用户标识，各自的中的状态属性设置为"active"时；

• 隶属于下的中状态属性设置为"active"；
• 隶属于下的下中，设置为UE的contact地址；
• 中event属性设置为"registered" or “created”；
  P-CSCF将：
• 绑定注册的公有用户标识与各个用户的contact信息。
• 增加公有用户标识到用户已注册的公有用户标识列表中；

2. 对于每个公有用户标识，各自的中的状态属性设置为"active"时；

• 隶属于下的中状态属性设置为"terminated"；
• 隶属于下的下中，设置为UE的contact地址；
• 中event属性设置为"deactivated", “expired”, “probation”, “unregistered”, 或者 “rejected”；
  P-CSCF将认为指示的共有用户标识将为用户而注销，并释放各自用户该公有标识的存储信息。

3. 对于每个公有用户标识，各自的中的状态属性设置为"terminated"时；

• 隶属于下的下中，设置为UE的contact地址；
• contact>中event属性设置为"deactivated", “expired”, “probation”, “unregistered”, 或者 “rejected”；
  P-CSCF将认为指示的公有用户标识将为UE而注销，并释放各自用户这些公有标识的所有存储信息，并从用户已经注册的公有用户标识列表中移除这个公有用户标识。
  如果用PVI注册的所有PUI都被注销了，P-CSCF将接收到来自S—CSCF的NOTIFY请求，该请求可以如5.4.2.1.2所述，订阅状态设置为"terminated"。如果该请求的订阅状态没有设置为"terminated"，P-CSCF可能不订阅注册事件包，或者让订阅超时。

注1： 一旦收到一个NOTIFY请求，且请求消息中Subscription-State头设置为"terminated"，P-CSCF认为订阅注册事件包终止（比如P-CSCF已经发送了一个订阅请求，请求中Expires头为0）。
注2： 当用户注册一个公有用户标识时，S-CSCF可能隐式注册多个公有用户标识。下面段落提供了一套机制通知P-CSCF关于隐式注册的多个公有用户标识。
5.2.5 注销
5.2.5.1 用户发起的注销
当P-CSCF接收到注册请求的200OK响应时，P-CSCF将检查消息体Expries头和/或Contact头中expires字段中的值。如果值为0，P-CSCF将：

1. 去除To头中的拥有用户标识，并且从已注册的公有用户标识列标重去除所有关联的公有用户标识和存储的信息。
2. 检查是否UE已经留下其它已注册的公有用户标识。当所有UE已注册的公有用户标识都被注销了，P-CSCF将删除与UE间的安全关联，在服务器事务（见RFC3261）执行注销终止后。
   注 1 ： 一旦接收到NOTIFY请求，请求中中状态属性设置为"terminated"（如所有公有用户标识都被注销）和Subscription-State头设置为"terminated"，P-CSCF认为订阅注册注册事件包终止（就如P-CSCF发送一个订阅请求，请求中Expries头设置为0）。
   注 2 ： 目前没有区分注册请求和注销请求的需求，P-CSCF因为管理原因，可以区分注册和注销请求，但是在SIP层处理注册和注销是没有差别的。
   注 3 ： 当注册请求仅对应于一个已注册公有用户标识，但隐式注册关系到其它几个公有用户标识，当P-CSCF发送该请求的200OK响应，P-CSCF将去除和UE间的安全关联。所有后续SIP信令无法到达UE。
   5.2.5.2 网络发起的注销
   一旦接收到关于订阅注册事件包产生的对话的NOTIFY消息，见5.2.3中描述，消息体中保护一个或者多个元素，都是UE已经注册的。

• state属性设置为"terminated"；
• state属性设置为"active"，且中state状态设置为"terminated"，关联的事件属性设置为"rejected" 或"deactivated"；
  P-CSCF将去除这些公有用户标识的的所有存储信息，去除该用户已经注册的公有用户标识列表。
  一旦接收到NOTIFY请求，请求中state属性为"terminated"（也就是所有公有用户标识都注销），且Subscription-State头设置为"terminated"或者当所有公有用户标识都注销，P-CSCF将降低与UE间的安全关联。
  注 1 ： P-CSCF和UE间的安全关联降低等级，允许包含注销事件得NOTIFY请求到达UE。
  注 2 ： 当P-CSCF接收到NOTIFY请求，请求中Subscription-State头为"terminated"，P-CSCF认为订阅事件包终止（也就是像P-CSCF向S-CSCF发送一个订阅请求，请求中Expires设置为0）。
  5.2.6 除了REGISTER方法之外的对所有对话和单独事务的一般处理
  5.2.6.1 介绍
  5.2.6节及其下面小节的流程对除了REGISTER方法以外的所有请求和响应适用。
  5.2.6.2 MO和MT的决定
  当接收了一个初始请求或者目标刷新或者单独事务，P-CSCF：
  ――如果请求利用了终呼的信息，将按照5.2.6.4节描述的来执行终呼流程。在注册时终呼信息被增加到Path消息头（即P-CSCF入口）（见5.2.2节），例如，消息从特定的端口获得或者最顶端Route头包含了特殊的用户部分或者参数。
  ――如果以上信息没有被请求使用，则执行起呼流程，见5.2.6.3节所述。

5.2.6.3 UE发起的请求
当P-CSCF收到对话或者单独事务的初始请求，并且请求中P-Preferred-Identity头匹配已经注册的公有用户标识，P-CSCF确定该公有用户标识为请求发起者。
当P-CSCF收到对话或者单独事务的初始请求，并且请求中P-Preferred-Identity头不匹配任何一个已经注册的公有用户标识，或者请求没有包含P-Preferred-Identity头，P-CSCF将缺省的公有用户标识确定为请求发起者。如果有一个以上的缺省公有用户标识，P-CSCF从中随机抽取一个。
注1：From头不构成任何确定流程的部分。
当P-CSCF从UE收到的对话或者单独事务的初始请求，并且关于请求的发起者的Service-Route列表存在，P-CSCF将：

1. 验证收到的在Service-Route头（在最后一次成功注册或者重注册期间）中的URI列表是否和接收的请求中的预加载的Route头是否匹配。不是整个字符串而是一个一个URI进行验证。如果验证失败，P-CSCF要么：
   a) 返回400（Bad Request）响应，响应可能存在包含有警告代码399的Warning头；P-CSCF不会前转该请求，并且不将继续Step 2以后的操作；或者
   b)使用注册或者重注册回的最后200OK响应消息所带的Service-Route头替换预加载Route头；
2. 增加自己的地址到Via头。按照RFC3261[26]流程，P-CSCF的Via头以包含P-CSCF端口号的格式，以及：
   a) P-CSCF 的可以解析为IP地址的FQDN，或者
   b) P-CSCF的IP地址；
3. 当增加自己的SIP URI到Record-Route头顶部，按照包含P-CSCF端口号（等待被叫的后续请求）的格式，以及：
   a) P-CSCF 的可以解析为IP地址的FQDN，或者
   b) P-CSCF的IP地址；
4. 如果存在P-Preferred-Identity头，则要移除，并插入P-Asserted-Identity消息头，代表请求发起者的值；
5. 按照规范3GPP TS 32.260[17]增加带有icid参数的P-Charging-Vector；并且
6. 如果是INVITE请求，还要保存请求中Contact, CSeq, 以及Record-Route头的值，以便必要的时候P-CSCF能够释放会话；
   (完成以上步骤后)，按照RFC3261，基于最顶端 Route头，前转该请求。

当P-CSCF收到以上请求的1XX或者2xx响应，P-CSCF将：

1. 保存P-Charging-Function-Addresses消息头的值；
2. 保存Record-Route的列表；
3. 保存Dialog ID，并且与会话的私有用户标识和公有用户标识关联；
4. 重新填写自己的Record Route为与主叫协商的被保护服务器的端口号，依照RFC3485[55]附加压缩参数；并且
   注2：对于每一对安全关联，P-CSCF关联两个端口，一个是保护服务器端口，一个是保护客户端端口。如何选择保护端口，参照3GPP TS 33.203[19]。
5. 如果该响应与INVITE请求相对应，保存Contact, From, To 和Record-Route头，以便必要时能够释放会话。
   在按照RFC3261[26]进行前转响应到UE之前，需要进行以上操作。

当P-CSCF收到UE发送的对话的目标刷新请求，P-CSCF将：

1. 验证请求的发起者是否关联了一个对话：
   a) 如果请求没有与请求发起者有关的现存的会话，P-CSCF将向发起者发送403（Forbidden）响应。响应可能保护带有warn-code 399的Warning头。P-CSCF不将前转该请求。不需要其他的操作；或者
   b) 如果请求有与请求发起者有关的现存的会话，P-CSCF继续下面的步骤；
2. 验证请求中的Record-Route头列表和本地保存的同一个对话的列表是否匹配。验证是按一个一个URI进行比较，而不是整个字符串匹配。如果匹配失败，P-CSCF将：
   a) 返回400（Bad Request）响应。响应可能包含带有warn-code 399的Warning头；P-CSCF也不前转该请求，同时也不进行Step 3以后的步骤；或者
   b) 使用本地保存的同一个对话的Recodr-Route中的列表替换Route头的值。
3. 增加自己的地址到Via头。按照RFC3261[26]流程，P-CSCF的Via头以包含P-CSCF端口号的格式，以及：
   a) P-CSCF 的可以解析为IP地址的FQDN，或者
   b) P-CSCF的IP地址；
   4）当增加自己的SIP URI到Record-Route头顶部，按照包含P-CSCF端口号（等待被叫的后续请求）的格式，以及：
   a) P-CSCF 的可以解析为IP地址的FQDN，或者
   b) P-CSCF的IP地址；
4. 对于INVITE对话（例如，由INVITE请求发起的对话），用请求中的Contact和CSeq头替换本地保存的，以便P-CSCF必要时能够释放会话；
   注3：只有收到1xx或者2xx响应，保存的contact和CSeq才有效。对于其他情形，以前的仍然有效。
   按照RFC 3261[26]流程，基于最顶端Route进行前转请求之前，需要进行以上步骤。

当P-CSCF收到以上请求（刷新）的1xx或者2xx响应后，P-CSCF将：

1. 和收到初始请求的响应一样，需要重新填写自己的Record Route为与主叫协商的被保护服务器的端口号，依照RFC3486[55]附加压缩参数；并且
2. 使用响应中携带的Contact头值取代保存的Contact头，以便P-CSCF在必要的时候释放会话。
   在按照RFC 3261[26]流程进行前转响应到UE之前，进行以上操作。
   当P-CSCF收到来自单独事务的UE的请求，并且对于请求发起者的Service-Route头列表存在，P-CSCF将：
3. 验证收到的在Service-Route头（在最后一次成功注册或者重注册期间）中的URI列表是否和接收的请求中的预加载的Route头是否匹配。不是整个字符串而是一个一个URI进行验证。如果验证失败，P-CSCF要么：
   a) 返回400（Bad Request）响应，响应可能存在包含有警告代码399的Warning头；P-CSCF不会前转该请求，并且不将继续Step 2以后的操作；或者
   b)使用注册或者重注册回的最后200OK响应消息所带的Service-Route头替换预加载Route头；
4. 如果存在P-Preferred-Identity头，则要移除，并插入P-Asserted-Identity头，代表请求发起者的值；并且
5. 增加带有icid参数P-Charging-Vector头 ，见3GPP TS 32.260[17];
   (完成以上步骤后)，按照RFC3261，基于最顶端Route头，前转该请求。

当收到以上请求(单独事务)的响应，P-CSCF将：
1)保存P-Charging-Function-Addresses头的值；
完成以上步骤后，按照RFC3261[26]前转该响应到UE。

当P-CSCF收到来自UE的后续请求，但不是目标刷新请求（包括关联一个已经存在的对话，但是该方法未知），P-CSCF将：

1. 验证请求的发起者是否关联了一个对话：
   a) 如果请求没有与请求发起者有关的现存的会话，P-CSCF将向发起者发送403（Forbidden）响应。响应可能包含带有warn-code 399的Warning头。P-CSCF不将前转该请求。不需要其他的操作；或者
   b) 如果请求有与请求发起者有关的现存的会话，P-CSCF继续下面的步骤；
2. 验证请求中的Record-Route头列表和本地保存的同一个对话的列表是否匹配。验证是按一个一个URI进行比较，而不是整个字符串匹配。如果匹配失败，P-CSCF将：
   a) 返回400（Bad Request）响应。响应可能包含带有warn-code 399的Warning头；P-CSCF也不前转该请求，同时也不进行Step 3以后的步骤；或者
   b) 使用本地保存的同一个对话的Recodr-Route中的列表替换Route头的值。
3. 对于非INVITE对话，增加一个带有icid参数的P-Charging-Vector头，见3GPP TS 32.260[17]; 并且
   4）对于INVITE对话，使用收到的请求中的Cseq替换保存的Cseq头，以便P-CSCF必要时能够释放会话。
   按照RFC 3261[26]流程，基于最顶端 Route进行前转请求之前，需要进行以上步骤。

当P-CSCF收到UE的未知方法的请求（未与存在对话关联），并且存在该请求发起者的Service-Route头，P-CSCF将：

1. 验证Service-Route 头（最后一次成功注册或者重新注册获得）中包含的URI列表是否为请求中预加载Route头的子集。验证是一个一个URI进行，而不是整个字符串。如果验证失败，P-CSCF将：
   a) 返回400（Bad Request）响应。响应可能包含带有warn-code 399的Warning头；P-CSCF不前转该请求，并且不进行Step 2以后的步骤；或者
   b) 使用最后一次注册的200OK响应中的Route头的值代替请求中Route头；并且
2. 如果存在P-Preferred-Identity头，移除该头，插入P-Asserted-Identity头，代表当前请求的发起者。
   在按照RFC 3261[26]流程，基于Route头进行前转请求之前，进行以上操作。
   5.2.6.4 请求在UE终止
   当P-CSCF接收一个对话的初始请求，并且该请求去往UE，在前转该请求之前，P-CSCF将：
3. 转换Record-Route头成Route头列表，并保存该Route头列表；
4. 如果请求为INVITE请求，保存请求中Contact, CSeq, 以及Record-Route头值，以便P-CSCF必要时能够释放会话；
5. 当增加自己的SIP URI到Record-Route头顶部，并保存该列表，按照RFC 3486[55]的格式构建的P-CSCF SIPURI ，其中包含comp参数，以及在UE和P-CSCF建立安全关联时的被保护服务器端口号，以及
   a) P-CSCF 的可以解析为IP地址的FQDN，该地址为UE和P-CSCF建立安全关联建立时的；或者
   b) UE和P-CSCF建立安全关联建立时的P-CSCF的IP地址；
6. 当增加自己的地址到接收的Via头列表顶部，并保存该列表，按照RFC 3486[55]的格式构建的P-CSCF SIPURI ，其中包含comp参数，以及在UE和P-CSCF建立安全关联时的被保护服务器端口号，以及
   a) P-CSCF 的可以解析为IP地址的FQDN，该地址为UE和P-CSCF建立安全关联建立时的；或者
   b) UE和P-CSCF建立安全关联建立时的P-CSCF的IP地址；
   注1：对于每一对安全关联，P-CSCF关联两个端口，一个是保护服务器端口，一个是保护客户端端口。如何选择保护端口，参照3GPP TS 33.203[19]。
7. 保存收到的P-Charging-Function-Addresses头；
8. 移除并保存来自收到的P-Charging_Vector头的icid参数；并且
9. 保存P-Called-Party-ID头。
   完成以上操作后，按照RFC 3261[26]的流程前转该请求到UE。
   当收到以上请求的1xx或2xx响应时，P-CSCF将：
10. 如果存在P-Preferred-Identity头，移除之，并插入P-Asserted-Identity头，该头的值来自于请求时候保存的P-Called-Party-ID头；
    2） 验证收到的响应中的P-CSCF的Via头的值和同一个对话接收请求时保存的Via值是否匹配。验证是按照一个一个Via头进行，而不是整个字符串进行。如果验证失败，P-CSCF将：
    a) 丢弃该响应；或者
    b) 使用请求时的Via头取代此时Via头值；
11. 验证收到的响应中的P-CSCF的Record-Route头的值和同一个对话接收请求时保存的Record-Route值是否匹配。验证是按照一个一个Record-Route消息头进行，而不是整个字符串进行。如果验证失败，P-CSCF将：
    a) 丢弃该响应；或者
    b) 使用请求时的Record-Route头取代此时Record-Route头值，并且重新写它自己的Record-Route的端口号，等待主叫方后续请求，同时移除comp参数；
    如果验证成功，P-CSCF重新写它自己的Record-Route的端口号，等待主叫方后续请求，同时移除comp参数；
12. 保存Dialog ID，并与会话中私有用户标识和公有用户标识关联；并且
13. 如果为INVITE请求的响应，需要保存Contact, To ,From以及Record-Route头，以便P-CSCF能够必要时释放会话；
    完成以上操作，按照RFC3262[26]流程进行前转响应。
    当P-CSCF收到以上请求的其他响应，P-CSCF将：
14. 验证收到的响应中的P-CSCF的Via头的值和同一个对话接收请求时保存的Via值是否匹配。验证是按照一个一个Via头进行，而不是整个字符串进行。如果验证失败，P-CSCF将：
    a) 丢弃该响应；或者
    b) 使用请求时的Via头取代此时Via头值；
    完成以上操作，按照RFC3261[26]流程进行前转响应。

当P-CSCF收到对话的目标刷新的请求，该请求发往UE，在前转该消息之前，P-CSCF将：

1. 当增加自己的地址到接收的Via头列表顶部，并保存该列表，按照RFC 3486[55]的格式构建的P-CSCF SIPURI ，其中包含comp参数，以及在UE和P-CSCF建立安全关联时的被保护服务器端口号，以及
   a) P-CSCF 的可以解析为IP地址的FQDN，该地址为UE和P-CSCF建立安全关联建立时的；或者
   b) UE和P-CSCF建立安全关联建立时的P-CSCF的IP地址；
   注2：对于每一对安全关联，P-CSCF关联两个端口，一个是保护服务器端口，一个是保护客户端端口。如何选择保护端口，参照3GPP TS 33.203[19]。
2. 当增加自己的SIP URI到Record-Route头顶部，并保存该列表，按照RFC 3486[55]的格式构建的P-CSCF SIPURI ，其中包含comp参数，以及在UE和P-CSCF建立安全关联时的被保护服务器端口号，以及
   a) P-CSCF 的可以解析为IP地址的FQDN，该地址为UE和P-CSCF建立安全关联建立时的；或者
   b) UE和P-CSCF建立安全关联建立时的P-CSCF的IP地址；
3. 对于INVITE对话，使用所收到的Contact和CSeq头替代保存的，以便P-CSCF能够必要时释放会话。
   注3：只有在收到请求后的1xx或2xx响应后，替换的Contact头才有效。其他情形仍然使用旧的值。
   完成以上操作，按照RFC3261[26]前转该请求到UE。
   当P-CSCF收到以上请求的1xx或者2xx响应后，P-CSCF将：
4. 验证收到的响应中的P-CSCF的Via头的值和同一个对话接收请求时保存的Via值是否匹配。验证是按照一个一个Via头进行，而不是整个字符串进行。如果验证失败，P-CSCF将：
   a) 丢弃该响应；或者
   b) 使用请求时的Via头取代此时Via头值；
   2)重新填写自己Record-Route的端口号，同响应初始请求一样的值。移除comp参数，并且
5. 用收到响应的Contact替换本地保存的Contact值，以便P-CSCF必要时能够释放会话；
   完成以上操作后，按照RFC 3261[26]流程前转该响应消息。

当P-CSCF收到以上请求的其他响应，P-CSCF将：

1. 验证收到的响应中的P-CSCF的Via头的值和同一个对话接收请求时保存的Via值是否匹配。验证是按照一个一个Via头进行，而不是整个字符串进行。如果验证失败，P-CSCF将：
   a) 丢弃该响应；或者
   b) 使用请求时的Via头取代此时Via头值；
2. 重新填写自己Record-Route的端口号，用以等待来自主叫方后续请求，移除comp参数；
   完成以上操作后，按照RFC3261[26]的流程前转该响应。

当收到发往UE的某单独事务或者未知的方法（没有和存在的对话产生关联）的请求，P-CSCF在前转该消息之前，将：

1. 当增加自己的地址到接收的Via头列表顶部，并保存该列表，按照RFC 3486[55]的格式构建的P-CSCF SIPURI ，其中包含comp参数，以及在UE和P-CSCF建立安全关联时的被保护服务器端口号，以及
   a) P-CSCF 的可以解析为IP地址的FQDN，该地址为UE和P-CSCF建立安全关联建立时的；或者
   b) UE和P-CSCF建立安全关联建立时的P-CSCF的IP地址；
   注4：对于每一对安全关联，P-CSCF关联两个端口，一个是保护服务器端口，一个是保护客户端端口。如何选择保护端口，参照3GPP TS 33.203[19]。
2. 保存收到的P-Charging-Function-Addresses头，
3. 移除和保存P-Charging-Vector头的icid参数，并且
4. 保存P-Called-Party-ID 头，
   完成以上操作后，按照RFC3261[26]的流程前转该请求。

当收到以上请求的响应后，P-CSCF将：

1. 验证收到的响应中的P-CSCF的Via头的值和同一个对话接收请求时保存的Via值是否匹配。验证是按照一个一个Via头进行，而不是整个字符串进行。如果验证失败，P-CSCF将：
   a) 丢弃该响应；或者
   b) 使用请求时的Via头取代此时Via头值；
   2）如果存在P-Preferred-Identity头，移除之，插入P-Asserted-Identity头，其中的值填写请求时的 P-Called-Party-ID的值；
   完成以上操作后，按照RFC3261[26]的流程前转该响应。

当收到发往UE的非目标刷新的后续请求（包含与现存会话关联，但是方法未知的请求），P-CSCF在前转该消息之前，将：
1)在接收到消息的Via头列表顶部增加自己的地址，并保存该列表，按照RFC 3486[55]的格式构建的P-CSCF SIPURI ，其中包含comp参数，以及在UE和P-CSCF建立安全关联时的被保护服务器端口号，以及
a) P-CSCF 的可以解析为IP地址的FQDN，该地址为UE和P-CSCF建立安全关联建立时的；或者
b) UE和P-CSCF建立安全关联建立时的P-CSCF的IP地址；
注5：对于每一对安全关联，P-CSCF关联两个端口，一个是保护服务器端口，一个是保护客户端端口。如何选择保护端口，参照3GPP TS 33.203[19]。
2) 移除和保存P-Charging-Vector头的icid参数，并且
3) 对于INVITE对话，使用收到的请求的Cseq代替本地保存的Cseq。
完成以上操作后，按照RFC3261[26]的流程前转该请求到UE。
当收到以上请求的任何响应，P-CSCF将：

1. 验证收到的响应中的P-CSCF的Via头的值和同一个对话接收请求时保存的Via值是否匹配。验证是按照一个一个Via头进行，而不是整个字符串进行。如果验证失败，P-CSCF将：
   a) 丢弃该响应；或者
   b) 使用请求时的Via头取代此时Via头值；
   完成以上操作后，按照RFC3261[26]的流程前转该响应。

5.2.7 初始INVITE
5.2.7.1 简介
除了遵从5.2.6节的初始请求的流程外，初始INVITE请求还需要遵从本节的流程。

5.2.7.2 起呼（MO）情形
当P-CSCF收到UE的INVITE请求时，可能要求周期性的刷新，以免P-CSCF的状态挂起。如果P-CSCF要求周期性刷新会话，将采用在draft-ietf-sip-session-timer[58]clause8中描述的流程。
注1:刷新请求会话要求被至少一个UE支持。该功能不能自动授予，例如，至少有一个参与的UE支持。
P-CSCF对所有INVITE请求响应100(Trying)临时响应。
如规范RFC3313[31]所描述，收到初始INVITE请求的响应后，P-CSCF将：
――如果PDF生成了媒体授权令牌（例如，采用基于业务的本地策略控制），插入包含有该媒体授权令牌的P-Media-Authorization头。
注2： 特别地，第一个183（Session Progress）响应包含了SDP 应答，其中包含有一个或者更多地“m=”媒体描述，但是也有可能的是，响应没有包含SDP应答或者SDP没有包含任何“m=”媒体描述。然而，媒体授权令牌的生成是独立于“m=”的媒体描述，它不管是否有该描述，都将在P-Media-Authorization头中将令牌发送到UE。同一个授权令牌使用到会话结束为止。为获得更多细节，参照3GPP TS29.207[12]。
只要P-CSCF中计费信息有效，P-CSCF也将包含access-network-charging-info参数（通过Go和Gq接口，由PDF获得），该参数存在于UE发送到P-CSCF的第一个请求中的P-Charging-Vector头中。例如，在本地资源预留完成后。特别是，如果远端UA支持“SIP和资源管理综合”扩展，且第一个请求为UPDATE，或者远端UA不支持“SIP和资源管理综合”扩展，且第一个请求为re-INVITE。关于接入网络计费信息地更多细节见5.2.7.4节。

5.2.7.3 终呼(MT)情形
当P-CSCF接收到需要发往UE的INVITE请求时，可能要求周期性的刷新，以免P-CSCF的状态挂起。如果P-CSCF要求周期性刷新会话，将采用在draft-ietf-sip-session-timer[58]clause8中描述的流程。
注1:刷新请求会话要求被至少一个UE支持。该功能不能自动授予，例如，至少有一个参与的UE支持。
当P-CSCF收到发往UE的初始请求，将在Request-URI中包含UE的URI，以及一个唯一的预加载的Route头。收到的初始INVITE请求也有Record-Route头列表。在前转该初始请求到Request-URI的URI时，P-CSCF将：
――如果按照RFC3313[31]规范，PDF生成的媒体授权令牌（例如，采用基于业务的本地策略控制），就将该令牌插入P-Media-Authorization头。
注2：特别地，第一个183（Session Progress）响应包含了SDP 应答，其中包含有一个或者更多地“m=”媒体描述，但是也有可能的是，响应没有包含SDP应答或者SDP没有包含任何“m=”媒体描述。然而，媒体授权令牌的生成是独立于“m=”的媒体描述，它不管是否有该描述，都将在P-Media-Authorization头中将令牌发送到UE。同一个授权令牌使用到会话结束为止。为获得更多细节，参照3GPP TS29.207[12]。
另外，P-CSCF将给所有INVITE请求回100（Trying）临时响应。
只要P-CSCF中计费信息有效，P-CSCF就将包含access-network-charging-info参数（通过Go和Gq接口，由PDF获得），该参数存在于UE发送到P-CSCF的第一请求或者初始响应中的P-Charging-Vector头中。例如，本地资源预留完成后。特别是，如果远端UA支持“SIP和资源管理地综合”扩展，且第一个响应是180（Ringinig）或者200（OK），或者远端UA不支持“SIP和资源管理地综合”扩展，且第一个请求为re-INVITE。关于接入网络计费信息地更多细节见5.2.7.4节。

5.2.7.4 接入网络计费信息
如7.2A.5中描述的，P-CSCF将在P-Charging-Vector头中包含access-network-charging-info参数。

5.2.8 呼叫释放
5.2.8.1 P-CSCF发起释放
5.2.8.1.1 当前正在建立的会话的取消
对于正在建立的多媒体会话，P-CSCF收到无线覆盖无效的指示，将发送CANCEL请求来取消对话，流程描述见RFC3261[26]。
5.2.8.1.2 已经存在的会话的释放
对于已经存在的会话，P-CSCF收到无线接口资源无效的指示（如来自PDF的忽略会话的请求），将按照以下步骤释放会话：

1. 如果P-CSCF服务于会话的主叫用户，将产生BYE请求，该请求基于保存的与对话相关的信息，包括：

――Request-URI，被叫提供的Contact头；
――To消息头，收到的初始INVITE请求的200OK响应中的To头；
――From消息头，初始请求INVITE中的From头；
――Call-ID消息头，初始INVITE请求中的Call-ID头；
――Cseq消息头，从主叫到被叫的Cseq，增量加1；
――Route消息头，对话的到被叫的路由信息；
――更多的消息头，基于本地策略或者被请求会话释放的原因。
2) 如果P-CSCF服务会话的被叫用户，将产生BYE请求，该请求基于保存的与对话相关的信息，包括：
――Request-URI，主叫提供的Contact头；
――To消息头，收到的初始INVITE请求的From头；
――From消息头，收到的初始请求INVITE对应的200（OK）响应中的To头；
――Call-ID消息头，初始INVITE请求中的Call-ID头；
――Cseq消息头，从被叫到主叫的Cseq，增量加1；
――Route消息头，对话的到主叫的路由信息；
――更多的头，基于本地策略或者被请求会话释放的原因。
3) 发送BYE请求到被指示的用户。
4) 收到BYE请求的2xx响应，将删除所有对话和多媒体会话相关的信息。

5.2.8.1.3 异常情形
对于一个P-CSCF发起会话释放的对话，P-CSCF收到一个请求，此时，P-CSCF将终结接收到的请求，并回481（Call/Transaction Does Not Exist）响应。

5.2.8.1.4 由于注册超期删除安全关联导致存在的对话释放
安全关联被删除后，如果用户相关的对话仍然激活，P-CSCF丢弃所有该对话的消息，不与P-CSCF的对等实体执行任何SIP事务。
注：与此同时，P-CSCF通过Gq接口指示会话终止。

5.2.8.2 其他实体发起的呼叫释放
当P-CSCF收到对应现存对话BYE请求的2xx响应，P-CSCF将删除保存的所有与该对话相关的信息。

5.2.8.3 会话超期
如果P-CSCF请求周期性刷新会话，并且P-CSCF获得会话将被刷新的指示，当会话定时器超时，P-CSCF将删除所有保存的与会话相关的信息。
注：P-CSCF也将通过Gq接口指示IP-CAN会话终止。

5.2.9 后续请求
5.2.9.1 起呼情形
P-CSCF将对所有reINVITE请求回应100（Trying）临时响应。
对于从UE发送的reINVITE请求，当P-CSCF发送UPDATE请求到S-CSCF时，P-CSCF将在P-Charging-Vector头中包括更新过的access-network-charging-info参数。见5.2.7.4获得更多关于接入网络计费信息的信息。

5.2.9.2 终呼情形
P-CSCF将对所有reINVITE请求回应100（Trying）临时响应。
对于发往UE的reINVITE请求，当P-CSCF发送200（OK）响应（该INVITE请求的）到S-CSCF时，P-CSCF将在P-Charging-Vector头中包括更新过的access-network-charging-info参数。见5.2.7.4获得更多关于接入网络计费信息的信息。

5.2.10 紧急业务
P-CSCF保存一个可配置的本地紧急号码以及紧急URI的列表，例如，那些被运营商用来进行紧急业务属于P-CSCF处理的号码。另外，P-CSCF保存一个漫游伙伴的紧急号码和紧急URI的可配置列表，该列表关联MCC和MNC号码。
注：在全网中，确定的SIP URI可能按照紧急URI分类。
P-CSCF通过可配置列表，从来自UE的所有INVITE请求中的Request URI检查出紧急号码和紧急URI。如果P-CSCF发现INVITE请求中的Request-Uri和这些列表中的某一个匹配，它将不前转该INVITE请求。P-CSCF将为该INVITE请求响应380（Alternative Service）响应。
为了决定该INVITE请求是否为去往漫游国家的紧急中心（例如，检查漫游伙伴的列表），P-CSCF将收到的P-Access-Network-info头中的MCC和MNC域和自己的MCC和MNC号码进行比较。
P-CSCF将在380（Alternative Service）响应中包含Content-Type头，该头的值设置为关联3GPP IMS XML消息体的MIME类型，描述见7.6.1节。
P-CSCF在3GPP IMS XML消息体中包含：
a) 一个元素，设置为alternative业务参数；
b) 一个子元素，设置“emergency”来指示这是一个紧急呼叫；并且
c) 一个子元素，设置为运营商配置原因。

5.2.11 Void
5.3 I-CSCF执行的步骤
5.3.1 注册过程
5.3.1.1总体描述
在注册过程I-CSCF扮演有状态Proxy的角色。
5.3.1.2 正常情况
当I-CSCF收到一个Register请求，如3GPP TS 29.228 [14]中描述的I-CSCF开始向HSS查询用户注册位置
注：不同的UE,每一个都有自己的私用用户标识, UE注册私有标识，私有标识可能被公有标识共享。如TS 29.228 [14]描述的UE向同一个S-CSCF上注册属于这些UE的所有用户公有标识。
执行向HSS查询用户注册信息的过程前，I-CSCF向HSS查询用户注册位置。I-CSCF确定将查询哪个HSS，如3GPP TS 29.228 [14]描述的确定HSS可能是查询（订阅位置功能）SLF实体的结果。
如果来自HSS的用户注册位置查询响应包含一个有效的SIP URI，I-CSCF将：
1)在Server-Name AVP中，将收到的REGISTER请求中Request-URI位替换成从HSS收到的响应中的SIP URI
2)如果需要进行拓扑隐藏，执行5.3.3中描述的过程
3)向指定的S-CSCF发送REGISTER请求消息
如果来自HSS的注册位置查询响应中包含能力列表，I-CSCF将

1. 选出一个S-CSCF，这个SCFCF满足需要的强制性的能力。如果有多个S-CSCF满足需要的强制性的能力，选出的S-CSCF是除满足必要能力外，又满足最多可选能力的S-CSCF，这些可选能力是额外的也是需要的；
2. 将收到的REGISTER请求中的Request-URI替换成S-CSCF的URI；
3. 如果需要进行拓扑隐藏，需要执行5.3.3中描述的过程；
4. 向被选的S-CSCF发送REGISTER请求消息;
   如果来自HSS用户注册位置查询请求中包含一列能力和一个有效的SIP URI，I-CSCF首先用SIP URI 选择S-CSCF，如果该S-CSCF是不可达的，I-CSCF将选择一个如5.3.1.3异常情况中描述的新的S-CSCF。
   当I-CSCF收到与REGISTER请求匹配的2xx响应，I-CSCF将2xx响应透传到P-CSCF
   5.3.1.3 异常情况
   在SLF查询时，如果SLF没有发送HSS的地址到I-CSCF，I-CSCF将发送403（禁止）响应到UE，响应中包含一个警告头，警告头中包含399警告码
   如果HSS对用户注册位置请求发送一个拒绝响应，I-CSCF将发送一个403（拒绝）响应。响应中包含一个警告头，警告头中包含一个399拒绝码
   如果用户注册位置查询过程没有完成，原因如：超时或者收到来自HSS的错误信息，I-CSCF将返回480（临时不可得）响应到UE。
   如果一个被选的S-CSCF：

• 不响应注册请求，I-CSCF重发REGISTER请求。或者
• 对应注册请求返回3××响应或者480（临时不可得）响应;
  同时:
• 注册请求的认证头中不包含" integrity-protected(完整性保护)”参数；或者
• 认证头包含的"integrity-protected"参数的值不是“yes”；
  那么：
• 如果I-CSCF收到来自HSS的一列能力，按照 5.3.1.2描述的，根据HSS指出的能力， I-CSCF将选择一个新的S-CSCF。在同一个注册过程中，新选择的S-CSCF将不是以前选择的S-CSCF中的任何一个。或者
• 如果I-CSCF已经从HSS收到了一个有效的SIP URI，因为这个S-CSCF已经安排给其他共享同一个用户公有标识的UE，I-CSCF向HSS请求一列能力，收到这些能力，按照5.3.1.2描述的，依据HSS指出的能力，I-CSCF将选择一个新的S-CSCF。在同一个注册过程中，新选择的S-CSCF将不是以前选择的S-CSCF中的任何一个。
  如果一个被选的S-CSCF不响应REGISTER请求，I-CSCF重发注册请求，并且注册请求中包含一个认证头。该认证头带有"integrity-protected"参数，并且该参数设为“yes”。按照RFC3261中描述的过程，I-CSCF将向用户返回480（请求超时）或504（服务器超时）响应
  如果I-CSCF不能选择一个满足HSS指出的必要能力的S-CSCF，，I-CSCF将向用户返回一个600（忙）响应。
  5.3.2 初始请求
  5.3.2.1 正常过程
  对于初始请求，I-CSCF扮演一个有状态的Proxy。
  I-CSCF将验证所有的请求是否来组一个可信任域，如果请求来自一个非可信域，I-CSCF将：

1. 如果该请求是注册请求，发送403（拒绝）响应；
2. 如果请求不是注册请求。移走请求中可能包含的所有的P-Asserted-Identity头、所有P-Access-Network-Info头，所有P-Charging-Vector头和所有P-Charging-Function-Addresses头，同时
   3）继续下面的过程
   如果请求来自可信域，I-CSCF将执行下面的过程
   注意1：依据3GPP TS 33.210 [19A]描述的I-CSCF可能发现请求是否来自一个可信域
   当I-CSCF收到一个用于对话或者单独事务的初始请求，I-CSCF将：
3. 如果Request-URI中包含一个pres：或者一个im：URI，那么将pres：或者im:URI转换成用户公有标识，同时把收到入呼请求中的Request-URI替换成用户的公有标识；同时

注意2：因为pres: 和im: 查询，在指向I-CSCF的DNS中必须广播SRV记录
2) 如果请求中不包含一个Route头，那么检查Request-URI的域名是否和I-CSCF中配置的PSI子域中的一个匹配。如果匹配，通过内置的DNS 机制将Request-URI转换成PSI归属的AS的IP地址，且不要启动用户位置查询过程。否则如3GPP TS 29.228 [14]中描述的，I-CSCF将开始向HSS查询被叫用户位置，被叫用户在Request-URI中被指明。向HSS查询用户位置前，I-CSCF判断向哪个HSS查询，如GPP TS 29.228中描述的，HSS的地址可能是查询订阅位置功能（SLF）的结果。
当I-CSCF收到Invite请求，I-CSCF可能需要定期刷新会话，避免I-CSCF处于挂死状态。如果I-CSCF要求进行会话刷新，他将应用draft-ietf-sip-session-timer [58] clause 8中描述的过程
注意3：请求会话更新需要被至少终端中的一个UE支持，这个功能不能自动被授予，例如：至少涉及的UE的其中的一个需要支持它
如果I-CSCF能将Request-URI转换成PSI归属的AS的IP地址，它将

1. 存储从P-Charging-Vector头中得到的icid参数值，同时保留P-Charging-Vector头中的icid参数。如果P-Charging-Vector头中没有icid参数，那么I-CSCF将生成一个新的icid，icid是一个全局唯一的变量，并把新生成icid存储在P-Charging-Vector头中
2. 如果需要拓扑隐藏，应用 5.3.3描述的过程，同时
   3）将请求直接发给PSI归属的AS中
   当成功查询用户位置时，当响应包含被分配的S-CSCF的URI时，I-CSCF将
3. 将从HSS中获得的URI作为topmost Route头插入；
4. 存储从P-Charging-Vector 头中获得的icid参数，同时保留P-Charging-Vector头中的icid参数。如果P-Charging-Vector中没有icid参数，那么生成新的icid参数，icid参数是一个全局唯一的变量，将新生成的icid插入P-Charging-Vector头中
5. 如果需要进行拓扑应藏，执行 5.3.3中描述的过程，同时
   4）依据topmost Route头路由请求消息
   当成功的查询了用户的位置，当响应中包含所需的S-CSCF能力，I-CSCF将
6. 按照3GPP TS 29.228 [14]描述的方法，选择一个S-CSCF；
7. 将被选的S-CSCF的URI作为topmost Route头域值插入
8. 执行上段步骤2和步骤3描述的过程（当正确查询用户位置，响应中包含被安排的S-CSCF的URI），同时
9. 将请求消息发给被选择的S-CSCF
   当查询用户位置不成功，从HSS返回的响应指出用户不存在，I-CSCF将返回一个合适的表示查询失败的SIP响应。用户不在其归属网络时，这个响应可能是404（找不到）或者是604（任何地方都不存在）。
   当查询用户位置失败，从HSS返回的响应表明用户没有被注册和没有服务提供给这个用户，ISCSF将返回一个合适的响应表明查询失败。如果用户被验证是一个合法用户，但是此时该用户没有被注册，同时没有服务提供给该未注册的用户，这个响应可能是480（临时不可得）
   当ICSCS收到一个用于对话或者单独事务的初始请求，请求中包含一个指向自己的单独的路由头，根据路由头的内容，I-CSCF将判断是否需要HSS查询或者隐藏。如果需要HSS查询，I-CSCF执行的过程是没有Router头呈现时描述的过程。如果I-CSCF判断对于出呼请求需要隐藏，I-CSCF将
10. 把从Router头中移走自己的SIP URI；
11. 执行5.3.3描述的过程，同时
    3） 依靠Request-URI头域路由请求
    当I-CSCF收到一个用于对话和单独事务的初始请求，请求中包含多个Router头，ICSCS将：
12. 从topmost Route头中移走自己的SIP URI；
13. 应用5.3.3描述的过程，同时
    3）按照topmost Route头传递请求
    注意4 :为了保持和SIP一致，I-CSCF可能将自己的可路由的SIP URI添加到针对于任何请求的Record-Route头的顶部，这个工作独立于请求是否是初始请求或者是否需要执行拓扑隐藏。如果Record-Route 头不在对话初始请求中，P-CSCF将忽略任何一个Record-Route头。
    当I-CSCF收到针对初始请求的响应（如183或者2××响应），如果P-Charging-Function-Addresses头显示，I-CSCF将存储P-Charging-Function-Addresses头中值。如果下一跳不在当前网络中，I-CSCF转发该请求消息前，将移走P-Charging-Function-Addresses头。
    I-CSCF正要发送初始INVITE请求到S-CSCF时，当I-CSCF收到来自S-CSCF的305响应时， 如3261 [26]描述的，I-CSCF将初始Invite请求发给305响应Contact域中指出的 SIP URI。
    5.3.2.2 异常情况
    SLF查询时，如果SLF没有向I-CSCF发送HSS地址，I-CSCF将向UE返回404响应。
    如果I-CSCF收到用户位置查询的否定响应，I-CSCF将返回404响应
    如果I-CSCF收到一个Cancel请求，并且I-CSCF发现内部状态表明Hss的Cx事务处理未决（pending），I-CSCF将

• 向CANCEL返回200OK响应，同时
• 用487回答最初的请求，请求被中止。
  注意：I-CSCF将丢弃任何后续的从HSS发来的（或者未决）Cx回答消息
  除了305（用户代理）响应,仅当 3××响应中包含的URI的域名部分和I-CSCF的域名相同，I-CSCF可能将递归3××响应。同样，如果URI是一个IP地址，如果这个本地所知的IP地址转换成代表域名的地址，代表域名的地址和I-CSCF的域名相同，I-CSCF也将进行重定向。
  5.3.3 I-CSCF中的THIG功能
  5.3.3.1 综述
  网络中需要拓扑隐藏，将执行下面的功能。网络需要拓扑隐藏被成为隐藏网络。
  注意1：因为请求和响应是进行单独处理，所以在一个I-CSCF（THIG）中不需要保存状态信息
  I-CSCF(THIG)将对于所有揭示拓扑信息的头应用拓扑隐藏。这些揭示拓扑信息的头是： Via, Route, Record-Route, Service-Route。
  当收到一个入呼的REGISTER请求，该请求需要应用拓扑隐藏，请求中包含一个路径头，I-CSCF(THIG)将添加一个I-CSCF(THIG)的可路由的SIP URI到路径头的顶部。I-CSCF(THIG)可能在被插入的SIP URI中包含一个指示器。指示器确定从I-CSCF收到的后续请求的方向以便确定终呼手机。例如：从S-CSCF到P-CSCF。I-CSCF(THIG)可能用不同的方法编码这个指示器，如：URI中的唯一参数，URI用户名部分的字符串，或者URI中指明的端口号。

注意2：任何后续的包含方向指示器（在路由头中）的请求，或者到达特定的端口的请求，表示是由S-CSCF发往P-CSCF的。
当收到一个必须应用拓扑隐藏的的入呼初始请求并且该请求包含一个Router头时，I-CSCF（THIG）将把自己的可路由的SIP URI添加到Record-Route头顶部
如果收到一个必须被拓扑隐藏的的出呼的初始请求，并且请求中包含一个P-Charging-Function-Addresses头，在转发该消息前，I-CSCF将移走P-Charging-Function-Addresses头。
5.3.3.2为实现拓扑隐藏进行的加密
当收到一个来自隐藏拓扑结构网络的出呼请求/响应，为了实现拓扑隐藏的目的，I-CSCF（THIG）将加密。I-CSCF做的工作如下：

1. 除UE外隐藏网络的一个或者多个特定实体添加的头值用作加密输入；
2. 当执行加密时，不改变用于加密的头的顺序
3. 用一个被加密的字符串，所有被加密的字符串来自用于加密的连续的头实体，不管被加密的字符串是否在分离连续的头中显示或者不管他们是否是在一个头中用逗号分离的串中的连续的实体。
4. 以’username@realm’的格式构造一个NAI，NAI中用户名部分是加密的字符串，realm是加密网络的名字
5. NAI生成后，添加"tokenized-by=”标签，把它设置为加密网络名的值
   6）除NAI结果，为指定的头生成一个合法的内容。如：为Via头预先设定"SIP/2.0/UDP"或者"sip:“对Route和Record-Route头预先设置"sip:”
   注意1：即使加密指定的头中同一个网络的连续的实体，也将导致只有一个加密的头内容，例如：
   Via: SIP/2.0/UDP I-CSCF1_s.home1.net;lr,
   SIP/2.0/UDP Token( SIP/2.0/UDP S-CSCF1.home1.net;lr,
   SIP/2.0/UDP P-CSCF1.home1.net;lr)@home1.net;
   tokenized-by=home1.net,
   SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]

注意2：如果同一个网络的多个实体在同一类型头中，但是他们是不连续的，那么这些实体被标识成不同的字符串，例如
Route: sip:I-CSCF1_s.home1.net;lr,
sip:Token(sip:S-CSCF1.home1.net;lr)@home1.net;tokenized-by=home1.net,
sip:as1.foreign.net;lr,
sip:Token(sip:S-CSCF1.home1.net;lr,
sip:P-CSCF1.home1.net;lr)@home1.net;tokenized-by=home1.net,
sip:[5555::aaa:bbb:ccc:ddd]

5.3.3.3 用于拓扑隐藏的解密
为达到网络拓扑隐藏的目的，收到或者发送起呼请求/响应到拓扑隐藏网络时，I-CSCF将执行解密。I-CSCF将

1. 在入呼消息的所有头中， I-CSCF隶属的网络鉴别被加密的NAI
2. 使用这些NAI中的用户信息部分，这些用户信息携带隐藏网络的标识，隐藏网络标识存放在作为解密输入的tokenized-by tag标识值中;
3. 将被加密字符串最为NAI用户部分，其支持发送协议（对于Via头如：“SIP/2.0/UDP”）或者URI方案，
   4）将收到的携带加密信息的头中所有内容替换成解密结果
   例子： 应用于Via头的一个加密内容 如：
   Via: SIP/2.0/UDP Token(SIP/2.0/UDP S-CSCF1.home1.net;lr,
   SIP/2.0/UDP P-CSCF1.home1.net;lr)@home1.net;tokenized-by=home1.net

将被如下实体取代：
Via: SIP/2.0/UDP S-CSCF1.home1.net;lr, SIP/2.0/UDP P-CSCF1.home1.net;lr

注意:这些解密的动机是如通过隐藏拓扑结构的网络正确路由响应。在拓扑隐藏的网络中避免回环现象或者在如Record-Route头中允许网络实体改变他们的内容
5.3.4 无
5.4 S-CSCF执行过程
5.4.1 认证和鉴权
5.4.1.1 介绍
S-CSCF扮演属于IM CN子系统和带有用户公有标识的所有UA的SIP注册服务器，S-CSCF支持使用Path和Service-Route头。S-CSCF也支持Require和Supported头。Path头只用在REGISTER请求和它的响应200OK中。Service-Route头只用在REGISTER响应的200OK中。对于REGISTER请求S-CSCF不扮演重定向服务器的角色
网络运营商定义每次注册的最小和最大次数。这个值在S-CSCF中提供
在 5.4.2.1.2中描述了通知关于自动被注册用户共有身份的过程
5.4.1.2 初始注册和用户初始重注册
5.4.1.2.1 无保护注册
注意1：任何被UE发送的不受保护的REGISTER请求都被看作是初始注册请求。S-CSCF收到正确认证挑战应答后，该挑战应答在受完整性保护的REGISTER请求中，返回对应该请求的200OK最终响应
注意2：通常收到被保护的Expires头等于0的注册请求。但是可能在某些错误的情况下收到不被保护的Expires头等于0的注册请求。下面举出异常情况情况下执行过程例子。
当收到一个不带"integrity-protected"参数的或者在认证头中"integrity-protected"参数设为“No”的REGISTER请求，因为，一个已经注册的用户共有身份对应一个相同的用户私有身份，但是带有一个新的联系信息（例如：没有注销的以前用的信息，用户漫游到其他网络），S-CSCF将
1)执行某过程，该过程应用于收到的不带"integrity-protected"参数，或者认证头中的"integrity-protected"参数设为“No”的REGISTER请求，该过程同时应用于用户的公有标识。
2）如果认证通过并且以前的注册没有过期，SCSCS将执行网络处初始注销过程，在5.4.1.5中描述了以前的联系信息
当收到不带"integrity-protected"参数或者认证头中"integrity-protected"参数设为“No”的注册请求，如果这个注册请求不是用于和同一个用户私有身份相关的已经注册的用户公有标识。S-CSCF将

1. 根据收到注册请求中的To头中收到的用户公有标识和REGISTER请求的认证头中的用户名中收到的用户私有身份鉴别用户
2. 检查是否注册请求中包括P-Visited-Network头，如果包括，用这个头的值鉴别被访问的网络。
   3）选择一个对应于该用户的认证向量。如果没有对应该用户的认证向量，按照3GPP TS 29.228 [14]描述的S-CSCF执行完和HSS的Cx多媒体认证过程，按照3GPP TS 33.203 [19]描述的S-CSCF选择一个认证向量
   和HSS进行Cx多媒体认证过程前，S-CSCF判断查询哪个HSS，按照3GPP TS 29.228 [14]描述的查询哪个HSS是查询SLF实体的结果
   注意3：此时，通过把SIP UPI传递给HSS ，S-CSCF通知HSS 该S-CSCF为用户提供当前的注册服务。HSS将用这个信息定位后续的应用于对话和单独事务的目标是S-CSCF的用户入呼初始请求
   注意4：当把SIPURI传递给HSS，S-CSCF将把将要联系的传输协议和端口号包含在SIPURI中
   4）存储P-Charging-Vector头中得到的ICID参数
3. 通过生成对应于REGISTER请求的401（无认证）响应挑战用户，响应中包含一个认证头他传输

• 在realm中包含归属网络的标识
• 在nonce中包含RAND和AUTN参数和对应于UE的可选的服务器的描述数据
• 在algorithm域中包含安全机制，他们是AKAv1-MD5
• 在ik中包含用于P-CSCF的IK（完整密钥）参数
• 在ck中包含P-CSCF使用的Ck（加密密钥）参数（见7.2A.1）

6. 为了以后再同步情况下使用，存储401响应中使用的RAND参数。如果S-CSCF中有了RAND参数，S-CSCF将用最新得到的401响应中用的RAND取代已存的RAND。
7. 相UE发送生成的这个401响应
8. 启动定时器reg-await-auth，用它监视收到的下一个注册请求
   如果收到的注册请求中标识S-CSCF以前发送给UE的挑战消息UE认为是无效的，S-CSCF将停止reg-await-aut定时器，执行 5.4.1.2.3描述的过程
   5.4.1.2.2有保护注册
   当用户没有进行当前认证时（比如 没有等待注册认证定时器工作）：
   当收到认证头中"integrity-protected"设为“yes”的注册请求消息，S-CSCF根据收到的To头中的用户的共有身份和收到的REGISTER请求认证头中的用户私有身份鉴别用户。
9. 检查用户是否需要重新认证
   S-CSCF可以对任何注册请求进行认证，同时对于没有值为“Yes”的"integrity-protected"参数的注册请求消息总是进行认证。
   如果用户需要重新认证，S-CSCF将执行5.4.1.2.1,中描述的初始注册过程。如果用户不需要重新认证，S-CSCF将按照这段中下面的步骤执行
10. 检查REGISTER请求中是否包含有效时间和效时间的值。如果Expires头是0。S-CSCF将执行5.4.1.4中描述的注销过程。如果Expires头不为0，S-CSCF将检查从To头中收到的用户共有身份是否已经被注册。如果没有被注册，S-CSCF从上面的步骤5开始执行。否则S-CSCF将从上面的步骤6开始执行
    如果这个用户的reg-await-auth定时器运行，S-CSCF将
11. 检查请求中的Call-ID是否和401响应中的Call-ID一致，这个401响应携带最后的挑战。如果Call-ID匹配，S-CSCF将执行下面的过程
12. 停止reg-await-auth定时器
13. 检查被包括的认证头是否包含
    a) username中包含用户的私有身份
    b) algorithm包含算法，算法是AKAv1-MD5
    c) Response中包括认证过程需要的认证挑战应答
    如果包括认证挑战应答，S-CSCF将仅执行这段中下面的步骤
14. 将检查收到的挑战应答认证和期望的认证挑战响应（按照RFC 3310 [49]描述的S-CSCF使用XRES和其他参数计算得到的）是否一致。为认证向量一部分，XRES参数从HSS中得到。如果从UE得到的挑战应答响应和S-CSCF计算的期望的响应一致，S-CSCF将执行下面的步骤
15. 当执行完和HSS的Cx服务器分配过程，按照3GPP TS 29.228 [14]描述的，存储下面的本地数据信息
    a) 和注册的用户公有标识相关的一列用户公有标识。包括注册中使用的公有标识和因为收到注册请求隐式被注册的用户共有身份。每个被定义的用户公有标识或者被禁止或者不被禁止
    b) 所有对应正在被注册的用户公有标识的所有服务profile包含初始过滤原则（已经被注册的初始过滤原则和公共部分的初始过滤原则被存储，没有被注册的部分被保留方便用户以后使用－如果用户变成未注册，将保留S-CSCF）
    注意1：可能收到多于一个初始过滤原则。因为一些隐含注册的用户公有标识，这些标识是同一个用户描述的一部分，属于不同的服务框架。
    6） 绑定每一个非禁止的被注册的用户公有标识和所有被注册的联系信息。联系信息包括Contact中的所有的头参数和所有联合的URI参数和为以后使用存储的信息
    注意2：对于一个用户标识这里可以得到多于一个的联系信息
    注意3：被禁止的用户公有标识不和联系信息绑定
    7）检查在REGISTER请求中是否包含Path头，从Path头中的一列内容中构造一列预载的Route头，S-CSCF保存一个有序的preloaded Route头，把他们和REGISTER消息中得到的联系信息绑定在一起
    注意4：如果这个注册是一个刷新注册，那么一列pre-loaded Router已经存在
16. 通过检查REGISTER请求中的Expire头的值，确定注册时间。根据本地的策略S-CSCF减少注册时间，发送423响应指明允许的最短的注册时间
17. 存储P-Charging-Vector头中的icid参数
18. 生成对应于REGISTER请求的200OK响应，包括
    a) 一列收到的Path头
    b) P-Associated-URI头包含一列用户的公有标识，他们和注册过的用户公有标识相关，在HSS提供给S-CSCF的一列用户公有标识中的第一个URI表示S-CSCF使用的默认的用户公有标识。被认为是默认公有标识的公有标识必须是已经被注册的用户公有标识。S-CSCF将把默认的用户公有标识替换成P-Associated-URI头中呈现的一列URI中的第一个条目，如 5.2.6.3描述的默认的用户公有标识和P-Asserted-Identity头协作被P-CSCF使用，S-CSCF将不向P-Associated-URI头中的一列URI中添加被禁止的用户公有标识。
    c) Service-Route头包含

• 如果定义S-CSCF的SIP URI包含一个指示：把通过服务路由请求（例如：从P-CSCF到S-CSCF）看成是对应于移动发起者的事情。这个指示可能在URI参数中，URI的用户部分的特征串或是URI中的一个端口号
• 如果网络需要拓扑隐藏，在入口的最上端SIP URI定义一个I-CSCF（THIG）
  d) 如果P-CSCF和S-CSCF在同一个网络中，P-Charging-Function-Addresses头包含从HSS中得到的值。如果P-CSCF和S-CSCF在同一个网络中通过REGISTER请求中P-Visited-Network-ID头的内容可以确定这个值。
  d) 联系头列出了对应这个用户公有标识的所有联系地址
  注意5：这里可能有其他的可以得到的联系地址。其他用户已经注册到同一个用户公有标识

11. 发送已经生成的200（OK）响应到UE
12. 按照5.4.1.7描述的发送一个第三方注册请求，每个AS匹配用于注册事件的从HSS得到的过滤原则
    注意6：如果注册是一个刷新注册，在地方数据库中存在过滤原则
13. .处理用户为在Expire头显示的时间内已经注册
    5.4.1.2.3 异常事件
    如果包含来自UE的挑战响应的REGISTER请求和期望的REGISTER请求不一致，请求中认证头有一个"integrity-protected"参数，参数被设为“yes”，S-CSCF将

• 发送403响应到UE，S-CSCF认为此次认证失败。S-CSCF将不更改订阅服务用户的注册状态
  注意1：如果UE以前被注册过，直到注册有效期超期，他保持被注册

如果在挑战信息中MAC无效，当支持截带挑战响应的注册请求消息中，没有认证挑战响应和AUTS参数，则S-CSCF将：

• 向UE响应403（禁止）响应。S-CSCF将不更新订阅服务用户的状态
  注意 2：如果UE以前被注册过，直到注册有效期超期，他保持被注册状态
  如果从UE来的注册请求包含一个认证挑战应答，挑战应答表明认证挑战是无效的（包含的AUTS参数表明这点）。S-CSCF将从HSS中获得新的认证向量。为了表明同步，当获取新的认证向量时，S-CSCF将包括从UE得到的AUTS和已经存储的RAND），当得到来自HSS的新的认证向量，S-CSCF将
• 发送401响应目的是用这些新的向量开始后续的认证
• 如果认证被抛弃，响应403消息。S-CSCF将更新被签约用户的注册状态。.
  注意3：如果用户已经被注册,注册有效期超时之前保持注册状态
  注意4：由于UE仅响应两个连续的无效的挑战，S-CSCF将两次发送401响应，响应中包含一个新的挑战
  如果来自UE的注册有效刷新时间太短以至于S-CSCF无法接收，S-CSCF将
• 对注册请求回423（间隔太短）响应，该响应中包含一个Min-Expires头，该头包含S-CSCF可接收的最短刷新时间
  当收到一个对应于第三方注册请求的失败的注册响应，依据过滤原则中的信息，S-CSCF将发起网络初始注销过程。如果过滤原则不包含关于和AS有关的失败的S-CSCF指令，S-CSCF将不初始网络注销过程
  如果来自UE的REGISTER请求Contact头包含多个SIP URI，S-CSCF将存储
• 选择带有最高的“q”值的内容
• 带有最高“q”值的contact头中的内容，或者
• 依据本地策略，S-CSCF确定的内容
  上述内容包含在200（OK）响应中
  NOTE 5: If the timer reg-await-auth expires, the S-CSCF will consider the authentication to have failed. If the public user identity was already registered, the S-CSCF will leave it as registered described in 3GPP TS 33.203 [19].
  注意5：如果reg-await-auth定时器超时，S-CSCF将认为认证失败，如果已经注册了用户公有标识，如3GPP TS 33.203 [19]描述的S-CSCF将不认为它已经被注册
  如果S-CSCF收到认证头中"integrity-protected"参数设为"yes"的REGISTER请求，因为从REGISTER请求To头中得到的用户公有标识和从REGISTER请求的认证头中得到的用户私有标识同在S-CSCF上被注册的任何标识不同，S-CSCF将
• 向UE回500（服务器内在错误）响应
  5.4.1.3 认证和重认证
  如 5.4.1.2描述的在注册过程中执行认证和重认证过程
  5.4.1.4 用户初始的注销
  当S-CSCF收到一个Expires头域包含0值的注册请求，S-CSCF将
• 检查在认证头中"integrity-protected"参数是否设为"yes"，这表明收到的注册请求是受保护的，如果"integrity-protected"参数设为“yes”S-CSCF仅执行下面的步骤
• 释放每个包括该用户的多媒体会话。这些会话由P-Asserted-Identity头中的用户公有标识表示用户发起或者应用5.4.5.1.2的步骤使用隐含注册用户公有标识的UE发起
• 如果该公有标识仅被UE注册，注销To头中的用户公有标识和隐含注册用户公有标识。否则，S-CSCF将仅删除被UE注册的联系地址
• 如 5.4.1.7描述的。发送一个第三方注册请求到每个满足过滤原则的AS。该过滤原则应用于REGISTER事件从HSS上得到，同时
• .如果这是一个针对当前注册的用户公有标识和其相关的一套隐含注册的注销请求（例如：没有其他的被注册）同时，有一个活跃的多媒体会话，会话包括用户，应用 5.4.5.1.2描述的步骤释放每一个对媒体会话。当前注册的共有用户标识或者某一个隐含注册用户公有标识发起这个会话，
  如果该UE的所有用户公有标识被注销，S-CSCF可能认为UE和P-CSCF订阅注册事件包被取消（例如，UE发送一个带有包含0的Expires头的订阅请求）
  如果REGISTER请求认证头不包含"integrity-protected"参数或者"integrity-protected"参数值设为"no"，S-CSCF将应用5.4.1.2.1描述的过程
  完成上面的过程同时完成3GPP TS 29.228 [14]描述的和HSS交互的Cx服务器分配过程，对于一个或者多个用户公有标识，S-CSCF将从本地数据库更新或者移走这些用户公有标识、用户的注册状态和相关的服务描述（依据S-CSCF的策略，S-CSCF能请求HSS或者保存或清除这些数据，因为S-CSCF分配给这个用户
  5.4.1.5 网络初始注销
  注意1：网络初始注销事件发生在S-CSCF上，注销事件从HSS中得到或者是S-CSCF的内部事件
  在网络初始注销当前注册的用户公有标识和他相关的一套隐含注册用户公有标识之前，这些标识已经用相同的联系信息被注册（例如没有其他的公有标识用这个联系信息注册），因为还有属于这个联系信息的激活的多媒体会话，按照下段描述的S-CSCF将释放属于这个联系信息的多媒体会话。这个多媒体会话对应同一个用户公有标识。如果用其他的联系信息注册，将保持不变
  网络初始注销前，因为还有和这个用户或者联系信息有关的多媒体会话激活，S-CSCF将根据下面的场景应用 5.4.5.1.2描述的步骤不释放、释放一些或者释放所有这些多媒体会话
• 当S-CSCF不希望UE刷新注册，（例如按照上面描述的S-CSCF在通知请求的元中设置属性事件为“拒绝”）S-CSCF将释放所有的和正在被注销的用户公有标识相关的会话，用户公有标识包括隐式注册的用户公有标识。
• 当S-CSCF希望UE刷新注册（例如S-CSCF将通知请求的属性事件的元设置为"deactivated"），S-CSCF将仅释放包括当前用户的会话。这个会话由被注销的其中一个用户公有标识发起，公有标识包括隐式注册的用户公有标识
  当应用于一个或者多个用户公有标识的网络初始注销事件发生，这些公有标识和一个或者多个联系信息有关，S-CSCF将向订阅各自自注册事件的所有订阅服务用户发送NOTIFY请求。对于每个NOTIFY请求，S-CSCF将

1. 在订阅时，设置Request-URI和Route头为被保存的路由信息
2. 设置事件头为"reg"值
3. 在NOTIFY请求体中，包含和许多用户公有标识一样的元，S-CSCF知道哪个用户拥有这个用户公有标识
4. 设置每个元的aor属性为一个用户公有标识
   a) 设置每个元的子元的资源的子元为UE提供的联系地址
   b) 如果用户公有标识：
   i) 已经被注销那么

• 设置元中的状态属性为“terminated “
• 设置元中的状态属性为"terminated"
• 如果S-CSCF希望UE刷新注册，设置元的事件属性为"deactivated"。如果S-CSCF不希望UE刷新注销，设置元的事件属性为"rejected"
  ii)已经保持被注册，那么
  I) 设置元的状态属性为"active"
  II) 设置元的状态属性设置为
• 因为联系地址被移走，设置元的状态属性为"terminated"，如果S-CSCF希望UE刷新注册，设置事件属性元为"deactivated"，如果S-CSCF不希望用户刷新注册，设置事件属性元为"rejected"
• 因为联系地址保持不变化，保持元为未更改的

注意2：对于一个用户公有标识，可以有多于一个的联系信息可用。当注销这个UE时，S-CSCF仅修改元，UE用他的私有用户标识注册该元。如果其他UE用不同的用户私有身份注册，同一个用户公有标识的元保持不变。
2) 如3GPP TS 32.260 [17]描述的在一个P-Charging-Vector头上加icid参数
在NOTIFY 请求中S-CSCF将仅包括非禁止的用户共有身份
同时，如 5.4.1.7描述的，S-CSCF将发送一个第三方注册请到每一个AS求，这些AS和从HSS得到的过滤匹配原则，好像从用户注销用户公有标识或联合用户公有标识那里得到等价的REGISTER请求。
In case of the deregistration of the old contact information when the UE is roaming, registration is done in a new network and the previous registration has not expired, on completion of the above procedures, the S-CSCF shall remove the registration information related to the old contact from the local data.
当UE漫游时，注销老的联系信息，在新的网络中进行注册，同时上次注册没有到期，和上面的过程相比，S-CSCF将从本地数据库中移走与老的联系信息相关的注册信息
否则，和上面的步骤相比，因为一个或者多个用户公有标识和同一个用户私有标识相连，S-CSCF将注销这些用户公有标识和相关的一些隐含注册的用户公有标识。和与HSS交互的的Cx服务器分配过程相比，如3GPP TS 29.228 [14]描述的，S-CSCF将从本地数据库中更新或者移走这列和同一个用户私有标识有关的用户公有标识、他们的注册状态和相关的的服务描述（依据运营商的策略，S-CSCF能请求HSS或者保存或者清楚，因为S-CSCF分配给给了这个服务订阅者）。同与HSS的Cx注册中止过程相比，如3GPP TS 29.228 [14]描述的，S-CSCF将从本地数据库中移走这些用户共有身份，他们的注册状态和相关的服务描述
5.4.1.6 网络初始的刷新注册
按照5.4.1.2描述的，基于一些可能的运营商设置的触发方法，在任何时间S-CSCF可以请求订阅服务用户重新认证
如果S-CSCF被通知一个用户私有标识需要被重新认证，由于订阅用户的注册事件包，S-CSCF将在所有的对话中生成一个NOTIFY请求，这些对话已经被建立，对于每个NOTIFY请求，S-CSCF将

1. 在订阅时，设置Request-URI和Route头为已经保存的路由信息
2. 设置Event头为"reg"
3. 在NOTIFY请求体中，包含和许多用户公有标识一样的元，S-CSCF知道哪个用户拥有这个用户公有标识
   a) 每个元的子元的子元为UE提供的联系地址
   b) 设每个置元中的aor属性为用户的公有标识
   c) 设置每个元的状态属性为“active“
   d) 设置元的状态属性为“active“
   e) 设置被UE注册的元的事件属性为"shortened"
   e) 设置被UE注册了的每个元的有效期为运营商定义的值
   注意1：对于一个用户公有标识这里由多于一个可以获得的联系信息。S-CSCF将仅修改UE用他的私有用户标识最初注册的元。如果UE用不同的用户私有标识注册用户公有标识，S-CSCF将不修改对应相同用户公有标识的元
   4） .按照3GPP TS 32.260 [17]描述的将icid参数写到P-Charging-Vector中
   然后S-CSCF将等待用户的重新认证（见5.4.1.2）
   注意2：因为是S-CSCF中的内部过程，可能发生网络初始重认证
   在NOTIFY 请求中，S-CSCF将仅包含非禁止的共有用户标识.
   当产生NOTIFY请求，S-CSCF将缩短和这个用户私有用户标识有关的所有注册的有效生命周期目的是让运营商定义这个值，这个值能让用户重新被认证
   5.4.1…7 通知应用服务器有关注册状态
   在注册过程中，如果AS是可信域的一部分，S-CSCF将向AS发送的第三方注册的注册请求中包含一个P-Access-Network-Info信息（和从来自的UE的注册请求中得到的值一样）。如果AS不是可信域的一部分，S-CSCF将不包括P-Access-Network-Info头，对注册请求的任何响应中S-CSCF将不包括一个P-Access-Network-Info头
   如果5.4.1.2、5.4.1.4 或者 5.4.1.5描述的注册过程成功。S-CSCF将向每个AS发送带有下面信息的第三方注册请求
   a) Request-URI，他包含AS的SIP URI
   b) From头，他包含S-CSCF的SIPURI
   c) 根据运营商的配置，To头或者包含用户公有标识，该用户公有标识与从UE那里得到的REGISTER请求中包含的公有标识一样，或者包含被注册的一个隐含注册共有用户标识。
   d) ontact头，包含S-CSCF的SIP URI
   e) 对于初始注册和用户初始刷新注册（ 5.4.1.2），Expires头包含值和S-CSCF返回的200（OK）中值相同， 从UE处得到该响应，该响应对应REGISTER请求
   f) 对于用户初始的注销和网络初始的注销，Expires头包含0值
   g) 对于初始注册或者用户初始的刷新注册，如果这里的过滤信息表明需要包含HSS向REGISTER事件提供的数据（例如HSS可能提供给AS特定数据以便在第三方注册中被包括）。（看3GPP TS 29.228 [14]）如果这里有对应于AS的HSS过滤原则中提供的服务信息XML元，那么按照 7.6描述的，S-CSCF将在XML元中的注册请求消息体中包含该XML元。因为消息中包含IM CN子系统XML体，S-CSCF将设置Content-Type头的值以便76描述的MIME类型
   h) 对于初始注册和用户初始的刷新注册，the P-Charging-Vector header包含相同的icid参数，icid参数从来自UE的最初注册请求中得到。
   i) 对于初始注册和用户初始的刷新注册，如果被发到归属网络的S-CSCF，P-Charging-Function-Addresses头包含从HSS中得到的值
   如果S-CSCF没有成功收到对应与第三方注册请求的一个SIP响应，或者收到408响应或者收到5××响应，S-CSCF将

• 按照3GPP TS 29.228 [14]描述的，如果在过滤原则中定义的默认处理表明"SESSION_CONTINUED"值或者没有表明默认处理。不需要别的处理
• 按照3GPP TS 29.228 [14]描述的，如果在过滤原则中定义的默认处理表明"SESSION_TERMINATED"值，如 5.4.1.5.描述的，S-CSCF将初始网络初始注销
  5.4.2 订阅和通知
  5.4.2.1 订阅S-CSCF事件
  5.4.2.1.1 订阅提供注册状态的事件
  当一个前往S-CSCF的入呼的SUBSCRIBE请求到来，请求中包含带有reg事件包的事件头，S-CSCF将

1. 依据本地的策略，检查是否请求是由一个订阅服务的用户产生，该订阅服务的用户被授权订阅这个特殊用户的注册状态。被授权的订阅服务的用户包括

• 这个特殊用户拥有的所有用户公有标识，S-CSCF知道这些用户公有标识，这些公有标识不是被禁止的
• 所有被Path头定义的实体（如：P-CSCF，对于他用户被附上）
• 在初始过滤原则中被列出的和不属于第三方业务提供的AS
  注意：S-CSCF发现从SUBSCRIBE请求中得到的P-Asserted-Identity中的用于认证描述的标识

2. 生成2××响应承认收到SUBSCRIBE请求并且如RFC 3680 [43]描述的指明认证描述是成功的

• 一个Expires头，生成和SUBSCRIBE头中的Expires头或者一样或者小些的值
• 一个Contact头，设成在S-CSCF中生成的标识，这个标识将用于使SUBSCRIBE更新相互联系
  然后，S-CSCF将执行 5.4.2.1.2描述的通知有关注册状态的过程
  5.4.2.1.2 通知有关注册状态
  对于已经建立的所有对话的NOTIFY请求，由于订阅用户的注册事件包，S-CSCF将
  1)设置Request-URI和Route头为订阅过程中被保存的路由信息
  2)设置Event头为"reg"值

3. in the body of the NOTIFY request, include as many elements as many public user identities the S-CSCF is aware of the user owns;在NOTIFY请求消息中，包括和S-CSCF知道用户拥有的用户公有标识一样的许多元
4. 设置元中的aor属性为一个用户公有标识
   a) 设置元的每个子元中的子元为各个UE提供的联系地址；同时
   b) i:如果使用户的共有身份
   I) :已经被注销（例如：没有活跃的联系信息留下）那么

• 设置 元中的状态属性为"terminated"
• 设置每个元中的状态属性为"terminated"
• 按照RFC 3680 [43]设置每个元的事件属性为"deactivated"，“expired”, “unregistered”, “rejected"或者"probation”

如果用户的共有身份已经被注销并且在NOTIFY请求中注销已经被指出，同时没有新的刷新注册发生。在下面的NOTIFY请求中将不包括他的元
II):已经被注册那么

• 照RFC 3680 [43]将元设置为REGISTER请求的联系头中包含的任何额外的头参数
• 如果元中的状态属性没有设成"active"，将它设为"active"，否则将他保持不便，或者
• 为了使联系地址被注册，设置元中的状态属性为"active"，同时设置元中的事件属性为"registered"，或者
• 为了使联系地址保持不便，将元保持不便，或者
  III)已经被自动注册，以前没有被自动注册
• ;按照RFC 3680 [43]，将元设置成初始注册请求的联系头中包含的任一额外头参数。
• ;将元中的状态属性设置为"active"
• 将元的状态属性设置为"active"，同时
• 将元的事件属性设置为"created"，同时
  5） 按照3GPP TS 32.260 [17]描述的设置P-Charging-Vector为icid参数
  在NOTIFY请求中S-CSCF仅包括非禁止的用户公有标识
  例如：如果注册了sip:user1_public1@home1.net，用户公有标识
  自动注册sip:user1_public2@home1.ne。因此NOTIFY请求消息体中的各位是
  <?xml version="1.0"?>
  
  
  
  sip:[5555::aaa:bbb:ccc:ddd]
  
  
  
  
  
  sip:[5555::aaa:bbb:ccc:ddd]
  
  
  
  

当发送带有所有状态属性设为"terminated" 的元的一个最终的NOTIFY请求（如所有的用户公有标识已经被注销或者到期），通过将Subscription-State头设置成"terminated"，S-CSCF也将中止订阅注册事件包
当UE的联系地址被注销，（如在UE中没有元设为"active"），S-CSCF认为订阅属于UE的注册事件包被丢弃。（例如，好像UE已经发送了Expires头包含0值的一个订阅请求）
在NOTIFY 请求中S-CSCF将仅包含一个非禁止的用户公有标识
5.4.3 除了被S-CSCF终止的请求之外所有对话和单独事务的一般处理
5.4.3.1 起呼或者终呼的决定
收到一个初始化请求或者目标刷新请求或者一个单独事务，S-CSCF将：
――如果请求利用了一些信息来起呼，将执行如5.4.3.2节的起呼流程。这些信息在注册的时候被添加到Service-Route头(S-CSCF的entry，见5.4.1.2节)，例如，在某一特定端口收到消息或者最顶端Route包含一个特殊的用户部分或者参数，或者
――如果最顶端Route包含“orig”参数，执行起呼的流程，如5.4.3.2节。S-CSCF将从最顶端Route头删除“orig”参数。
――如果请求没有利用这些信息，执行5.4.3.3节的终呼流程。

5.4.3.2 被服务的用户发起的请求
当S-CSCF收到来自被服务的用户或者PSI的对话初始请求或单独事务请求，在前转这些请求前，S-CSCF将：
编者按：需要注意，如果请求来自信任域，例如在一个信任域的实体，S-CSCF仅仅执行下列步骤。

1. 确定请求的P-Asserted-Identity头是否包含一个禁止公有用户标识。如果该头包含有被禁止的公有用户标识，S-CSCF将产生403（Forbidden）响应拒绝请求。响应可能包含带有warn-code 399的Warning头。否则，继续以下流程；
   注1：如果P-Asserted-Identity头包含了一个被禁止的公有用户标识，直接或者间接地，收到的信息来自非兼容地实体，该实体应该已经产生了非禁止公有标识地内容。
2. 从最顶端Route头删除自己的SIP URI；
3. 检查入呼的最顶端Route头是否存在S-CSCF以前放置的初始Dialog ID。如果存在，表示该请求与一个存在的对话关联，是从AS发送过来，响应以前发送到AS的请求。
4. 检查初始请求是否匹配下一个基于P-Asserted-Identity的公有用户标识的未执行的初始过滤规则，按照3GPP TS 23.218 [5]描述的优先顺序，如果匹配，S-CSCF将：
   a) 插入AS URI到Route头作为topmost entry，后面紧跟自己的URI（S-CSCF），如5.4.3.4；并且
   b) 如果AS在信任域以外，S-CSCF将删除请求中P-Access-Network-Info头以及它的值，如果AS在信任域之内，S-CSCF在前转到AS的请求中保持P-Access-Network-Info头以及它的值；
   注2：依赖于处理过滤规则的结果，S-CSCF可能在处理出呼 Request URI之前联系了一个或者更多AS。
5. 如果在入呼请求的最顶端 route头没有初始Dialog ID，保存P-Charging-Vector头的icid参数的值以及保持P-Charging-Vector头的icid参数的值。可选地，当前转该消息时，S-CSCF可能产生一个新地全局唯一地icid，在P-Charging-Vector头插入新的icid参数。如果S-CSCF产生新的icid，它将负责维护后续消息中这两个icid值。
6. 如果在入呼请求的topmost route没有初始Dialog Id，在P-Charging_Vector头插入一个orig-ioi参数。S-CSCF设置orig-ioi参数的值标识发送网络。S-CSCF不包含term-ioi参数。
7. 如果在入呼请求的topmost route没有初始Dialog Id，且消息前转到S-CSCF归属域，包括到AS，插入P-Charging-Function-Addresses头，该头的值从HSS获得；
8. 如果在入呼请求的topmost route没有初始Dialog Id，并且S-CSCF知道了P-Asserted-Identity中SIP URI相关联的tel-URI，需要增加第二个P-Asserted-Identity头包含tel-URI；
9. 如果请求没有前转到AS并且出呼Request-URI是tel URI，S-CSCF将使用ENUM/DNS翻译机制（格式规范见RFC 3761[24]）将E.164地址（见RFC3966[22]）翻译成一个全局可路由的SIP URI。ENUM数据库方面超出本文档范围。如果翻译失败，该请求可能前转到BGCF或者发起者归属域其他合适的实体（如MRFC来放音），或者S-CSCF可能发送一个合适的SIP响应给发起者。如果出呼Request-URI是pres URI或者im URI，S-CSCF将前转该请求如RFC 3861[63]所示。在这种情况下，S-CSCF不修改收到的Request-URI。
   10)如果存在topmost Route，则使用其中的URI决定目的地址（如，DNS接入），否则，基于Request-URI。如果目的地址是IP地址类型而不是IM CN子系统使用地IP地址类型，如果IM CN子系统支持不同地址类型地交互，S-CSCF将前转该请求到IMS-ALG。
10. 如果网络需要隐藏本地策略，将I-CSCF(THIG)的地址放到topmost Route头中；
11. 在来自一个被服务用户的对话初始请求，要么：
    ――如果请求路由到信任域的AS，S-CSCF可能决定是否Record-Route。如何决定由S-CSCF根据收到的请求的一些信息来配置的。这些信息可能被用作初始过滤规则。如果请求被record-routed，S-CSCF将产生Record-Route头包含自己的SIP URI；或者
    ――如果请求被路由到别处，产生一个Record-Route头，包含自己SIP URI。
    注3：对于由PSI发起的请求，S-CSCF可能决定是否record-route。
    编者按：需要说明的是在处理PSI发起的请求时，S-CSCF怎样决定是否将自己的地址填入Record-Route头。这可能是运营商策略的一部分。
12. 基于目的用户(Request-URI)，前转消息前，删除P-Access-Network-Info；
13. 基于SIP路由流程路由请求；并且
14. 如果请求是INVITE请求，保存Contact,Cseq并且Record-Route头，以便S-CSCF必要时能够释放会话。
    如果S-CSCF没有收到响应，或者收到408（Request TimeOut）响应或者来自AS的一个5xx响应，S-CSCF将：
    ――如果在过滤规则中定义的缺省处理为“SESSION-CONTINUED”(见3GPP TS 29.228[14])或者没有缺省处理指示，从step 4开始执行流程；并且
    ――如果在过滤规则中定义的缺省处理为“SESSION-TERMINATED”(见3GPP TS 29.228[14])，要么前转这收到的响应，要么发送408（Request Timeout）响应或者5xx响应给被服务的UE（不再验证最低优先级的过滤规则并且不进行更多的处理）。
    如果S-CSCF收到来自AS的任何最终响应，它将前转该响应给被服务的UE（不验证最低优先级的过滤规则并且不进行更多的处理）。
    当S-CSCF接收到以上请求的任何响应，S-CSCF可能：
15. 通过RFC 3323[33]和RFC3325[34]对P-Asserted-Identity头采用privacy隐私请求。
    注4：P-Asserted-Identity头正常出现在1xx或者2xx响应中。
    注5：RFC 3325规范描述了除了信任域边界的隐私应用的流程之外其他可选流程。
    当S-CSCF收到以上包含有term-ioi请求的任何响应，S-CSCF将保存P-Charging-Vector头中收到的term-ioi参数的值(如果存在的话)。term-ioi参数标识响应消息的发送网络。如果下一跳是AS，term-ioi和orig-ioi参数仅仅保持在P-Charging-Vector头。
    当S-CSCF收到对话初始请求的1xx或者2xx响应，如果该响应对应一个INVITE请求，S-CSCF将保存响应中的Contact和Record-Route头，以便必要时能释放会话。
    发送了一个在SDP offer（“c=”参数）包含IPv6地址初始INVITE请求后，S-CSCF收到一个错误响应，表明使用的IP地址类型不被IM CN子系统支持（例如，S-CSCF收到包含有301 Warning头指示“不兼容的地址格式”的488响应），S-CSCF将：
    ――分叉该初始INVITE请求到IMS-ALG；或者
    ――处理错误响应并根据Via头前转该响应。
    当S-CSCF收到对话的来自被服务用户一个目标刷新请求，在前转该请求之前，S-CSCF将：
16. 从最顶端的Route头删除自己的URI；
17. 产生包含自己SIP URI的Record-Route头；
18. 如果该请求是一个INVITE请求，保存请求中的Contact和Record-Route头，以便S-CSCF必要时能释放会话。
19. 如果请求将被路由到目的用户（Request-URI）或者请求被路由到信任域之外的AS，删除P-Access-Network-Info消息头；并且
20. 基于最顶端Route头进行路由。
    当S-CSCF收到对话目标刷新请求的1xx或者2xx响应，如果响应对应一个INVITE请求，S-CSCF将保存响应中的Contact和Record-Route头，以便S-CSCF必要时能释放会话。

当S-CSCF收到对话的来自被服务用户的后续请求而不是一个目标刷新请求，在前转该请求之前，S-CSCF将：

1. 从最顶端的Route头删除自己的URI；
2. 在这种情况下，请求被路由到目的用户（Request-URI）或者请求被路由到信任域之外的AS，删除P-Access-Network-Info头；并且
3. 基于最顶端Route头进行路由。
   除了305（Use Proxy）响应外，S-CSCF不会（recurse on）产生3xx响应。

5.4.3.3 终止于被服务用户的请求
当S-CSCF接收一个对话的初始请求或者一个单独事务的请求，该请求是去往静态预配置PSI或者注册过的被服务用户，在前转该请求之前，S-CSCF将：

1. 确定请求的Request-URI中是否包含有一个被禁止的公有用户标识。如果Request URI包含有被禁止的公有用户标识，S-CSCF将通过产生404（Not Found）响应拒绝该请求。否则，继续下面的步骤；
2. 删除最顶端Route头中自己URI；
3. 检查入呼的topmost Route头是否存在S-CSCF以前放置的初始Dialog ID。
   ――如果存在，表示该请求与一个存在的对话关联，是从AS发送过来，响应以前发送到AS的请求。
   ――如果不存在，表示该请求是第一次访问S-CSCF，并且这种情况S-CSCF保存请求中的Request-URI。
4. 如果在入呼请求的最顶端的Route头包含有初始Dialog Id，检查Request-URI和保存的Request-URI是否相等。如果不匹配，则：
   a) 如果是INVITE请求，保存Contact, Cseq以及Record-Route头，以便S-CSCF必要时能够释放该会话；并且
   b) 按照最顶端Route头前转该请求，并跳过以下步骤。
   如果匹配，按照优先级顺序检查初始请求与下面未被执行的初始过滤规则是否匹配，关于SIP 方法采用过滤规则见3GPP TS 23.218[5]的6.5节描述。如果存在匹配的过滤规则，插入AS URI到最顶端的Route头，紧接着插入自己的URI到Route头，见5.4.3.4描述。
   注1：依赖于处理过滤规则的结果，S-CSCF可能在处理出呼 Request URI之前联系了一个或者更多AS。
5. 如果在入呼请求的最顶端 route没有初始Dialog Id，且消息前转到S-CSCF归属域，包括到AS，插入P-Charging-Function-Addresses头，该头的值从HSS获得；
6. 如果在入呼请求的最顶端route头没有初始Dialog ID，保存P-Charging-Vector头的icid参数的值以及保持P-Charging-Vector头的icid参数的值。
7. 如果在入呼请求的最顶端route没有初始Dialog Id，保存在P-Charging_Vector头中orig-ioi参数（如果存在）。orig-ioi参数的值标识请求消息发送网络。如果下一跳为AS，orig-ioi参数仅仅在P-Charging-Vector保持。
8. 如果有必要，按照RFC 3841[56B]执行主叫和被叫能力的匹配；
9. 对于请求中没有Route头的情形，从目的公有用户标识，注册或者重注册预加载Route列表，按照5.4.1.2节描述决定，另外，S-CSCF将：
   a) 使用以前的步骤建立Route头；
   b) 从目的公用用户标识，注册或者重注册保存的可达的Contact URI决定，如5.4.1.2所述。如果对于目的公有用户标识保存有一个以上的联系地址，S-CSCF将：
   ――如果Request Disposition头被设置“no-fork”，构建Request-URI时采用最高的qvalue参数。没有提供qvalue参数的，S-CSCF将本地决定采用哪一个联系地址；否则
   ――分叉该请求或者基于初始REGISTER请求contact头的qvalue参数执行连续查找，如RFC3261[26]。没有提供qvalue参数的，S-CSCF将根据RFC 3841[56B]的Request Disposition头指示决定采用哪一个联系地址。如果Request Disposition头也没有提供，S-CSCF将本地决定是否分叉或者执行对联系地址的查找；
   c) 按照以前步骤决定的Contact URI内容构建Request-URI；并且
   d) 插入包含请求中Request-URI的P-Called-Party-ID头。
10. 如果请求是INVITE请求，保存Contact,Cseq并且Record-Route头，以便S-CSCF必要时能够释放会话。
11. 可选地，根据RFC 3323[33]和RFC 3325[34]对P-Asserted-Identity头采用隐私请求。
    注2： RFC 3325规范指定了除了信任域边界的私密应用流程之外其他可选流程。
12. 对于一个对话的初始请求的情形：
    ――如果请求路由到信任域的AS，S-CSCF可能决定是否Record-Route。如何决定由S-CSCF根据收到的请求的一些信息来配置的。这些信息可能被用作初始过滤规则。如果请求被record-routed，S-CSCF将产生Record-Route头包含自己的SIP URI；或者
    ――如果请求被路由到别处，产生一个Record-Route头，包含自己SIP URI。
13. 基于最顶端Route头前转该请求。
    如果S-CSCF没有收到响应，或者收到408（Request TimeOut）响应或者来自AS的一个5xx响应，S-CSCF将：
    ――如果在过滤规则中定义的缺省处理为“SESSION-CONTINUED”(见3GPP TS 29.228[14])或者没有缺省处理指示，从step 4开始执行流程；并且
    ――如果在过滤规则中定义的缺省处理为“SESSION-TERMINATED”(见3GPP TS 29.228[14])，要么前转这收到的响应，要么发送408（Request Timeout）响应或者5xx响应给被服务的UE（没有验证最低优先级的过滤规则并且没有进行更多的处理）。
    如果S-CSCF收到来自AS的任何最终响应，它将前转该响应给被服务的UE（没有验证最低优先级的过滤规则并且没有进行更多的处理）。
    当S-CSCF收到对话的初始请求或者单独事务的请求，该请求发往一个没被注册的用户，S-CSCF将：
    1)如果S-CSCF没有用户配置，发起S-CSCF注册/注销通知，用来下载相关用户配置（例如，为没注册的用户）以及通知HSS用户没有注册，但是S-CSCF将评估没有注册的用户的业务触发，见3GPP TS 29.228[14]描述。
14. 执行上一节的步骤1，2和3（当S-CSCF收到一个对话的初始请求或者单独事务请求，该请求发往注册过的被服务的用户）；并且
15. 执行上一节的步骤4,5,6,7,8,10,12和13（当S-CSCF收到一个对话的初始请求或者单独事务请求，该请求发往注册过的被服务的用户）.
    如果不需要与AS联系，S-CSCF将返回适当的不成功的SIP响应。该响应可能是480（Temporarily unavailable）并且终止这些流程。
    当S-CSCF收到一个对话初始请求（不管该用户是否注册）的1xx或者2xx响应，S-CSCF将：
16. 如果是INVITE请求的响应，保存响应中Contact和Record-Route头以便S-CSCF必要时能够释放会话；
17. 在出呼响应的P-Charging-Vector中插入term-ioi参数。S-CSCF将设置term-ioi参数的值标识响应的发送网络，并且设置orig-ioi的值为以前接收的orig-ioi的值；
    3)如果 S-CSCF知道了P-Asserted-Identity头SIP URI相关联的tel URI，S-CSCF将增加第二个P-Asserted-Identity头，包含tel URI；并且
18. 如果响应发送到发起用户，S-CSCF可能根据本地策略和目的用户(Request-URI)删除P-Access-Network-Info头。
    当S-CSCF收到一个单独事务请求的响应（不管用户是否注册过），如果 S-CSCF知道了P-Asserted-Identity头SIP URI相关联的tel URI，S-CSCF将增加第二个P-Asserted-Identity头，包含tel URI。如果响应前转到信任域的AS，S-CSCF将保持P-Access-Network-Info头，否则，S-CSCF将删除P-Access-Network-Info头。
    当S-CSCF收到单独事务请求的200（OK）响应，S-CSCF将：
19. 如果消息在S-CSCF归属域前转，插入P-Charging-Function-Address头，填写从HSS获得值。并且
20. 在出呼响应的P-Charging-Vector中插入term-ioi参数。S-CSCF将设置term-ioi参数的值标识响应的发送网络，并且设置orig-ioi的值为以前接收的orig-ioi的值。
    当S-CSCF收到一个对话的目标刷新请求，该请求发往一个被服务的用户，在前转该请求之前，S-CSCF将：
21. 从最顶端Route头删除自己的URI；
22. 如果该请求为INVITE请求，需要保存请求中的Contact, Cseq以及Record-Route头，以便S-CSCF必要时能够释放该会话；
23. 产生包含自己SIP URI的Record-Route头；并且
24. 基于最顶端Route头前转该请求。
    当S-CSCF收到对话的目标刷新请求的1xx或者2xx响应（不管该用户是否被注册），S-CSCF将：
25. 如果是对INVITE请求的响应，保存响应中的Record-Route头和Contact头，以便S-CSCF必要时能够释放该会话；并且
26. 如果响应前转到信任域的AS，S-CSCF将保持P-Access-Network-Info头，否则，删除该消息头。
    当S-CSCF收到后续请求而不是目标刷新请求，该请求发往被服务的用户，在前转该请求之前，S-CSCF将：
27. 删除最顶端Route头中自己的URI；并且
28. 基于最顶端Route头前转该请求。
    当S-CSCF收到对话的后续请求而不是目标刷新请求的响应，如果该响应前转到信任域的AS，S-CSCF将保持P-Access-Network-Info头，否则，S-CSCF将删除该消息头。
    除了305(Use Proxy)响应外，S-CSCF不递回3xx响应。

5.4.3.4 初始对话标识(Original dialog identifier)
初始对话标识是一个应用特殊的令牌，在前转该请求到AS之前，S-CSCF将该令牌编码到S-CSCF自己的URI形成Route消息头。这也许因为S-CSCF是产生和销毁该值的唯一实体。
令牌标识了请求的初始对话，因此作为B2BUA的AS改变对话，当请求返回到S-CSCF，S-CSCF能够标识初始对话。该令牌可能按不同方式进行编码，如，在S-CSCF URI的用户部分的一个字符串，S-CSCF URI的一个参数或者S-CSCF URI的一个端口号。
S-CSCF将确认选择的值是唯一的，所以当收到后续消息后，S-CSCF可能需要确认该值并且在通过AS的相关的对话建立关联。

5.4.3.5 void
5.4.4 呼叫发起
5.4.4.1 初始INVITE
当S-CSCF收到一个INVITE请求，不管是来自被服务的用户还是发往被服务的用户，S-CSCF可能要求周期性会话刷新，以免S-CSCF状态挂起。如果S-CSCF要求会话被刷新，将采用draft-ietf-sip-session-timer[58]clause 8的描述的流程。
注1：刷新会话的请求要求至少一个UE支持。这种功能不能自动授予，例如，至少参与的UE至少有一个需要支持。
当S-CSCF收到初始INVITE请求，该请求发往被服务的用户，它将：
a) 通过SDP offer（“c=”参数）来检查是否包含不被IM CN子系统支持的IP地址类型；或者
b) 没有检查SDP直接处理初始INVITE请求。
注2：如果SDP offer包含了不被IM CN子系统支持的IP 地址类型，S-CSCF将接收到包含有301Warning头的488(Not Acceptable Here)，指示“不兼容的网络地址格式”。
随后，当S-CSCF通过SDP offer来检查到包含有不被IM CN子系统支持的IP地址类型(例如a情形或者b)，S-CSCF将：
――返回305（Use Proxy）响应给I-CSCF，响应的Contact包含有IMS-ALG的SIP URI或者
――前转该初始INVITE请求到IMS-ALG。当前转该初始INVITE请求时，S-CSCF不将插入SIP URI到Record-Route头。

5.4.4.2 后续请求
5.4.4.2.1 起呼情形
当S-CSCF收到1xx或者2xx响应，如果该消息前转到S-CSCF归属域，包含到AS，S-CSCF将插入P-Charging-Funcition-Addresses消息头，其中填写从HSS中获得的值。
当S-CSCF收到包含有access-network-charging-info参数（在P-Charging-Vector头中）的请求，S-CSCF将保存该参数。当该请求前转到AS时，将保持该参数。然而，当请求前转到S-CSCF的归属域之外，不包含该参数。
当S-CSCF收到任何与起呼对话或者单独事务相关的请求或者响应（除了ACK请求和CANCEL请求和响应），在前转该消息到S-CSCF归属域，包括到AS时，S-CSCF可能插入以前保存的P-Charging-Vector和P-Charging_Function-Addresses头。
5.4.4.2.2 终呼情形
当S-CSCF收到1xx或者2xx响应，如果该消息前转到S-CSCF归属域，包含到AS，S-CSCF将插入P-Charging-Funcition-Address头，其中填写从HSS中获得的值。
当S-CSCF收到包含有access-network-charging-info参数（在P-Charging-Vector头中）的180（Ringing）或者200（OK）(对INVITE)响应时，S-CSCF将保存该参数。当该响应前转到AS时，将保持该参数。然而，当该响应前转到S-CSCF的归属域之外，不能包含该参数。
当S-CSCF收到任何与起呼对话或者单独事务相关的请求或者响应（除了ACK请求和CANCEL请求和响应），在前转该消息到S-CSCF归属域，包括到AS时，S-CSCF可能插入以前保存的P-Charging-Vector和P-Charging_Function-Addresses消息头。

5.4.5 呼叫释放
5.4.5.1 S-CSCF发起的会话释放
5.4.5.1.1 取消当前正在建立的会话
当收到网络内部释放当前正在建立的会话指示时，S-CSCF将通过发送CANCEL请求取消相关的对话，流程描述见RFC 3261[26]。

5.4.5.1.2 对已经存在的会话的释放
当收到对已经存在的多媒体会话的释放的指示，S-CSCF将：

1. 基于保存的与对话相关的信息为被叫用户产生第一个BYE请求，信息包括：
   ――一个request-URI，设置为被叫用户提供的保存的Contact头；
   ――To消息头，设置为对应初始请求的200OK响应的To消息头值；
   ――From消息头，设置初始INVITE请求的From头值；
   ――Call-ID头，设置初始INVITE请求的Call-ID头值；
   ――CSeq头，设置为保存从主叫到被叫方向的CSeq值，增量加1；
   ――Route头，设置为该对话保存的到被叫的路由信息；
   ――其他别的消息头，基于本地策略或者释放会话的原因。
2. 基于保存的与对话相关的信息为主叫用户产生第一个BYE请求，信息包括：
   ――一个request-URI，设置为主叫用户提供的保存的Contact头；
   ――To消息头，设置为对应初始请求的From消息头值；
   ――From消息头，设置对应初始INVITE请求的200OK响应的To消息头值；
   ――Call-ID头，设置对应初始INVITE请求的200OK响应的Call-ID头值；
   ――CSeq头，设置为保存从被叫到主叫方向的CSeq值，增量加1－如果没有保存该对话的Cseq，将产生和采用一个有效范围的随机数，作为Cseq；
   ――Route头，设置为该对话保存的到主叫的路由信息；
   ――其他别的消息头，基于本地策略或者释放会话的原因。
3. 如果S-CSCF服务的是主叫用户，对待第一个BYE消息像是直接从主叫用户接收到的，例如，发送它到内部业务控制，并且根据结果进一步发送到被叫用户；
4. 如果S-CSCF服务主叫用户，直接向主叫用户发送第二个BYE请求；
5. 如果S-CSCF服务被叫用户，直接向被叫用户发送第一个BYE请求；
6. 如果S-CSCF服务被叫用户，对待第二个BYE消息像是直接从被叫用户接收到的，例如，发送它到内部业务控制，并且根据结果进一步发送到主叫用户；
   收到以上两个BYE请求的2xx响应时，S-CSCF将释放对话相关和多媒体会话相关的所有信息。

5.4.5.1.2A 由于注册超期释放存在的对话
当唯一注册过的公有用户标识(关联隐式注册集，但是没有其他注册过的公有用户标识)的生命期到期时，还仍有激活的包含该用户的多媒体会话，该会话由当前注册过的用户或者隐式注册集中的一个发起的会话，S-CSCF将采用5.4.5.1.2步骤释放每一个多媒体会话。

5.4.5.1.3 异常情形
当对话被S-CSCF发起释放会话，这时收到对话请求，S-CSCF将终止被接收的请求，并且回481（Call/Transaction Dose Not Exist）响应。

5.4.5.2 被其他实体发起的会话释放
收到匹配已经存在的对话的对应BYE请求的2xx响应时，S-CSCF将删除所有保存的与对话相关的信息。

5.4.5.3 会话超期
S-CSCF请求会话周期性刷新，并且S-CSCF获得会话将被刷新的指示，当会话定时器超时后，S-CSCF将删除所有保存的和对话相关的信息。

5.4.6 呼叫相关请求
5.4.6.1 reINVITE
5.4.6.1.1 Determination of served user
void
5.4.6.1.2 起呼情形
对于来自UE的reINVITE请求，当S-CSCF接收了UPDATE请求，S-CSCF将保存被更新的来自P-Charging-Vector头的access-network-charging-info参数。当该请求前转到AS时，S-CSCF将保持该参数。然而，当UPDATE请求前转到S-CSCF归属域之外的网络，S-CSCF在P-Charging-Vector头不包含该参数。
对于来自UE的reINVITE请求，如果请求前转到信任域之内的AS，S-CSCF将保持P-Access-Network-Info头，S-CSCF将删除该头。

5.4.6.1.3 终呼情形
对于发往UE的reINVITE请求，当S-CSCF收到对应该INVITE的200（OK）响应时，将保持更新的来自P-Charging-Vector头的access-network-charging-info参数。当该响应前转到AS时，S-CSCF将保持该参数。然而，当200OK响应前转到S-CSCF归属域之外的网络，S-CSCF在P-Charging-Vector头包含该参数（对吗？？应该是不包含该参数）。

5.4.7
void
5.5 MGCF的流程
5.5.1 一般情形
MGCF尽管作为UA，但是不发起任何关联它的地址的注册。在一个IM CN子系统内，假使通过点对点分配能假使了解这些地址。因此，MGCF不会采用表A.4/1和依赖该表的主要能力。
MGCF不支持path和service-Route头的使用。
当MGCF发送任何和对话相关的请求或者响应时，在发送这些消息之前，MGCF可能插入以前被保存在P-Charging-Vector和P-Charging-Function-Addresses的值。

5.5.2 订阅和通知
void
5.5.3 呼叫的发起
5.5.3.1 初始INVITE
5.5.3.1.1 电路交换网络发起的呼叫
当MGCF收到来自电路交换网络的入呼指示时，MGCF将：
――产生和发送INVITE请求到I-CSCF；
――使用E.164地址的“tel”格式设置Request-URI；
――设置Supported头为“100rel”（见RFC 3312[30]被draft-eitf-sip-rfc3312-update[64]更新的）；
――包含P-Asserted-Identity头，依赖域与电路交换网络相应的信息；
――产生一个新的，全局唯一的icid参数，并插入到P-Charging-Vector头，并且
――插入orig-ioi参数到P-Charging-Vector头。orig-ioi参数设置的值标识了MGCF所在的发送网络并且不包含term-ioi参数。
当MGCF接收对应对话的初始请求的1xx或者2xx响应，将保存收到的P-Charging-Vector头的term-ioi参数（如果存在）。term-ioi参数标识了响应消息的发送网络。

5.5.3.1.2 终止于电路交换的呼叫
当MGCF收到初始化INVITE请求，该请求包含由带有“100rel”指示的Supported消息头，MGCF将：
――保存P-Charging-Vector消息头的orig-ioi参数（如果存在）。orig-ioi参数标识请求消息的发送网络；
――发送100（Trying）响应；
――在MGW匹配了编码方式或者没有要求编码方式以后，发送183“Session Progress”响应：
――设置值为“100rel”的Require消息头；
――保存P-Charging-Function-Addresses头的值；
――保存P-Charging-vector消息头的icid参数；并且
――在P-Charging-Vector头中插入term-ioi参数。term-ioi参数设置的值标识MGCF所在的网络。
如果初始化INVITE请求要求编码方式并且MGCF没发现一个与MGW中匹配的有效的编码，MGCF将：
――如果编码方式被接收但是没有有效值，发送503（Service Unavailable）响应；或者
――如果编码方式类型不支持，并且在消息体的SDP中指示编码方式被MGCF/MGW支持，发送488（Not Acceptable Here）响应

5.5.3.2 后续请求
5.5.3.2.1 电路交换网络发起的呼叫
当MGCF收到对应INVITE请求的183响应，MGCF将：
――保存接收的P-Charging-Function-Addresses头的值。
当以下条件被满足后，MGCF将发送UPDATE请求：
――3GPP TS 29.153[11B]描述的条件；并且
――MGCF接收到对应PRACK请求的200（OK）响应

5.5.3.2.2 在电路交换网络终止的呼叫
当MGCF收到对出呼到电路交换网络的被叫方的振铃指示，MGCF将：
――发送180（Ringing）响应给UE。
当MGCF收到为出呼到电路交换网络的被叫方的应答指示时，MGCF将：
――发送200（OK）响应到UE。如果相应信息来自电路交换网络，200(OK)响应将包含P-Asserted-Identity头。

5.5.4 呼叫释放
5.5.4.1 电路交换发起的呼叫释放
当MGCF收到来自电路交换网络的呼叫释放指示，MGCF将：
――发送BYE请求到UE。
5.5.4.2 IM CN子系统发起的呼叫释放
注：到电路交换网络的释放另外要求信令流程，而不是MGCF的SIP，这已经超出了本文档范围。
5.5.4.3 MGW发起的呼叫释放
当MGCF收到来自MGW的承载失去了的指示，MGCF将：
――发送BYE请求到UE；并且
――可能包含Error-Info头，该消息头带有一个指针指示附加信息：承载失去。
5.5.5 呼叫相关的请求
5.5.5.1 ReINVITE
5.5.5.1.1 电路交换发起的呼叫
void
5.5.5.1.2 终止于电路交换的呼叫
当MGCF收到保持/继续操作的reINVITE请求，MGCF将：
――发送100（Trying）响应；
――与MGW交互执行保持/继续媒体流操作，发送200（OK）响应。

5.5.6其他初始请求
当MGCF对OPTIONS请求进行200（OK）响应时，MGCF可能包含带有DTMF能力的指示和MGCF/MGW的编码支持的消息体。
注： 请求MGCF/MGW能力的具体接口没有在该版本文档中描述。期间，可能还会有其他解决方案。

5.6 BGCF的流程
5.6.1 概要
BGCF不支持path , Service-Route的使用。
当BGCF收到对话相关的或者独立事务的任何请求或者响应（除了ACK请求和CANCEL请求和响应）时，在前转消息前，BGCF可能插入以前保持的P-Charging-Vector和P-Charging-Function-Addresses消息头的值。
除了305（Use Proxy）相应之外，只有当3xx响应中包含的URI的域名部分和BGCF的域名一样，BGCF才可能传递该3xx响应。同样的，URI如果是IP地址，只有该IP地址能被本地确认为和BGCF所属的域相同，才能传递该3xx响应。
5.6.2 会话发起事务
BGCF收到INVITE请求后，BGCF将前转该请求到本网络中的MGCF或者到另外一个包含有MGCF的网络。BGCF不必在INVITE请求中Record-Route。当下一实体可能时扮演UA的MGCF时，BGCF不采用RFC3323[33]与私密有关的流程。BGCF将保存P-Charging-Function-Addresses消息头的值。BGCF保存收到的P-Charging-Vector消息头的icid参数的值并保持该参数。
注1：通过怎样的手段前转MGCF还是其他网络超出了本文档的范围，但是可能采用查找外部数据库或者BGCF内部数据配置的手段。
当BGCF收到INVITE请求，如果BGCF插入自己到Record-Route头，BGCF可能要求周期性刷新会话以免BGCF的状态被挂起。如果BGCF请求会话刷新，采用draft-ietf-sip-session-timer[58]clause8描述的流程进行。
注2：会话刷新的请求必须至少有一个UE支持。这个功能不会自动授予，例如，至少有一个参与的UE支持。

5.7 应用服务器(AS)流程
5.7.1 普通应用服务器(AS)流程
5.7.1.1 注册状态的通知
AS可能支持REGISTER方法，以便发现用户的注册状态。如果到达的REGISTER中包含有用户的注册状态并且AS支持注册方法，AS将保存Expires参数，产生200（OK）响应或者一个合适的失败响应。对于成功的情况，200(OK)响应将包含Expires值，并等于REGISTER请求所带的。AS保存REGISTER请求中的P-Charging-Function-Addresses头，也保存P-Charging-Vector头的icid参数。
收到第三方REGISTER请求，AS可能the AS may subscribe to the reg event package for the public user identity registered at the users registrar (S-CSCF) as described in RFC 3680 [43].
。。。。。。。。。。。。
5.7.1.2 提取计费相关的信息
5.7.1.3 接入网信息
5.7.1.4 AS的用户标识验证

5.7.1.5 请求授权
一旦AS验证用户标识，AS要么拥有了被验证的用户标识，要么认为用户是匿名。
如果用户被认为是匿名的，AS检查为该请求定义的授权是策略决定是否允许匿名请求。如果匿名请求被允许，AS可能继续请求的功能，否则AS不继续请求的功能。
如果是用户标识，AS将采用请求功能相关的授权策略来检查是否允许该请求的功能。授权策略可能要求验证过的用户标识。
如果请求授权，AS继续请求的流程。
如果请求没有授权，AS将：
――拒绝请求，通过请求定义的流程，例如，发送403（Forbidden）响应；或者
――发送2xx最后响应，如果授权策略要求拒绝被请求的功能，而要求显示给用户的是请求被授予了。
5.7.1.6 事件通知throttling
。。。。。。。。。。。。。。。。。
5.7.2 应用服务器(AS)用作终止UA或者重定向服务器
当AS作为终止的UA，AS按照5.1.4节定义的
5.7.3 应用服务器(AS)扮演初始UA
5.7.4 应用服务器(AS)扮演SIP proxy
当AS作为SIP proxy时，从S-CSCF接收到请求，在前转该请求之前，将：
――从最顶端的Route头删除自己的URI，并且
――执行请求的业务，基于最顶端Route路由请求。
在前转请求回S-CSCF之前，AS可能根据业务逻辑修改SIP请求。
按照RFC 3841[56B]，如果Request-Disposition头的fork指示被设置为“no-fork”，AS不fork请求。
作为SIP proxy的AS收到IM CN子系统的XML消息体，将直接放在前转消息中。

5.7.5 AS执行第三方呼叫控制
5.7.5.1 概要
AS执行第三方呼叫控制，扮演的是B2BUA角色。存在两种第三方呼叫控制：
――路由B2BUA：AS收到S-CSCF的请求，终止该请求，并基于收到的请求产生一个新请求。
――发起B2BUA：一个AS发起两个请求，但是在AS上是逻辑上连接的。
B2BUA AS在内部管理两个对话之间的映射消息头。负责关联对话标识，并决定什么是否将一个对话的消息翻译到另外一个对话的消息，或者执行其他功能。这些决定超出了本文档的范围。
5.7.5.2 呼叫发起
5.7.5.2.1 初始INVITE
5.7.5.2.2 后续请求
void
5.7.5.3 呼叫释放
5.7.5.4 呼叫相关请求
5.7.5.5 其他初始请求
5.7.6 void
5.8 MRFC流程
5.8.1 概要
尽管MRFC扮演的是UA，但是它怎样让自己关联的地址被其他实体知道，已经超出了本规范的范围。
当MRFC发送对话相关的或者单独事务的任何请求或者响应（除了ACK请求和CANCEL请求和响应），在发送这些消息前，MRFC可能插入以前保存的P-Charging-Vector和P-Charging-Function-Addresses消息头。
5.8.2 呼叫发起
5.8.2.1 初始INVITE
5.8.2.1.1 终止于MRFC的情形
5.8.2.1.1.1 简介
5.8.2.1.1.2 Tones and announcements
5.8.2.1.1.3 Ad-hoc 会议
5.8.2.1.1.4 编码转换
5.8.2.1.2 MRFC发起的情形
5.8.2.2 后续请求
5.8.2.2.1 Tones and announcements
5.8.3 呼叫释放
5.8.3.1 S-CSCF发起呼叫释放
5.8.3.1.1 Tones and announcements
5.8.3.2 MRFC发起的呼叫释放
5.8.3.2.1 Tones and announcements
5.8.3.2.2 编码转换
5.8.4 呼叫相关的请求
5.8.4.1 ReINVITE
5.8.4.1.1 MRFC终止的情形
5.8.4.1.1.1 Ad-hoc会议
5.8.4.1.2 MRFC-originating case
无
5.8.4.2 REFER
5.8.4.2.1 MRFC-terminating case
Void.
5.8.4.2.2 MRFC-originating case
Void.
5.8.4.2.3 REFER initiating a new session
Void.
5.8.4.2.4 REFER replacing an existing session
Void.
5.8.4.3 INFO
Void.
5.8.5 其他的初始请求
5.9 IMS-ALG
5.9.1 概要
IMS-ALG扮演了B2BUA。IMS-ALG将内部映射两个对话之间的消息头，该对话由IMS-ALG管理。IMS-ALG负责关联Dialog ID并且决定什么时候简单地从一个对话到另外一个对话消息的转化，或者什么时候执行其他功能。IMS-ALG尽管扮演的是UA，但是不使用自己关联的地址发起任何注册。在IM CN子系统中通过端对端的管理认为知道了该UA。IMS-ALG不支持Path和Service-Route消息头。
当IMS-ALG从一个不支持IM CN子系统中使用的IP地址类型的SIP网络接收了一个初始的INVITE请求，IMS-ALG将产生一个新的初始INVITE请求并前转到I-CSCF。
IMS-ALG内部功能在3GPP TS 29.162[11A]中定义。
6 有关SDP应用的用法

6.1 UE上执行的步骤
UE使用的SDP的用法

1. 为了授权媒体流，P-CSCF和S-CSCF必须有能力检测SDP的有效载荷。因此，UE将不能加密SDP的有效载荷。
2. UE产生的INVITE请求中包含SDP有效载荷。SDP有效载荷将反映主叫用户的终端能力和用于会话的用户参数。UE将用第一次列出的最优的编解码排列SDP有效载荷
   3．在Require头（表明对“资源管理和SIP的综合”的需求和本条以后被认为是前提机制同时在RFC 3312 [30]中定义，在draft-ietf-sip-rfc3312-update [64]中更新）中如果SIP请求包含一个"precondition"可选标签，用分段的状态类型，主叫用户将表明用于会话所期望的QoS。在初始的INVITE请求中，UE将表明强制的本地QoS，同时表明还不满意这个前提，例如UE将包括包括下面的预处理
   a=des: qos mandatory local sendrecv
   a=curr: qos local none

在Require头中如果SIP请求不包含"precondition"可选标签，UE将不能表示它要求的本地的QoS。通过包含下面的前提，UE可能表明对于可选的本地的QoS它的期望。
a=des:qos optional local sendrecv
在5.1.3.1.3中描述的，在第一个UE发送的SDP offer中，通过包含一个"a=inactive"列，UE将设置每一个媒体流为不活跃模式。draft-ietf-mmusic-sdp-new [39].中描述了这个步骤
注意1：当设置媒体为不活跃模式时，UE可以在第一个SDP offer中包含合适的用于RS和RR修改者的合适的值，同时关联带宽以便阻止收到RTCP包，并且也不发送任何RTCP报
3．提供从UE收到的INVITE请求，请求中包含带有一个"m="媒体描述的或者多个SDP offer，同时按照5.1.4.1.2描述的使用前提机制。UE发送的第一个183临时响应包含对从INVITE中得到的SDP的回答。这里书的回答将反映被叫终端的能力和用户参数
5.1.4.1.5中描述的，没有必须执行用于资源保存综合的详细的SDP过程
在5.1.4.1.4中描述的事件在第一个UE发送的SDP回答中，通过包含“a=inactive“列，UE将设置每个媒体流为不活跃模式。按照draft-ietf-mmusic-sdp-new [39]中描述的过程
在活跃模式中如果UE正在设置一个或者多个媒体流，将应用draft-ietf-mmusic-sdp-new [39]中描述的带有设置媒体流方向的过程
5. 当UE发送带有SDP载荷的一个183（会话过程）响应，载荷中包括一个或者多个"m="媒体描述。如果主叫UE支持前提机制，被叫UE请求确认发起点的资源预留的结果。
6. 在会话建立中，如果SDP载荷用于改变会话描述或者因为RFC 3261中描述的SIP准则，当在消息中SDP载荷必须被包括时，Sip消息将仅包含SDP载荷。
7．对于应用RTP/RTCP 的"video"和"audio媒体类型，利用"b="媒体描述UE将定义用于每个媒体流需要的带宽，同时在SDP中定义AS带宽修改者
按照RFC 3556 [56]描述的的指定需要，如果在SDP中的媒体列表明RTP/RTCP的使用，另外在媒体水平"b="列表明"AS"带宽修改者。UE将包括两个媒体水平"b="列，一个用于"RS"带宽修改者，另一个用于"RR"带宽修改者
对于另一个媒体流包括"b="媒体描述，"b="参数的值或者空值将反映被分配的在3GPP TS 29.208 [13]中定义的QoS
注意2：在一个参与双方都激活的双方会话中，RTCP接受者报告没有被发送，因此，RR带宽修改者将得到0值
8. 如described in RFC 2833 [23]描述的，UE将把MIME子类型"telephone-event"包括在SDP中的"m="媒体描述者中，SDP是用于支持RTP包中的DTMF载荷和audio编解码的音频媒体流
9. UE将监视SIP请求和响应中包含的SDP，按照RFC 3524 [54]寻找可能的分组媒体流的指示，同时按照IP-CAN特殊过程，执行合适的动作目的是建立应用与媒体的IP-CAN承载建立。（见使用GPRS实现 IP-CAN 的B.2.2.5）
10. 按照RFC 3261 [26] and RFC 3311 [29]，如果IP-CAN承载被拒绝或者修改，如果UE受到影响，UE将更新远端SIP实体
11．按照 5.1.3.1描述的，如果UE建立用于INVITE请求的SDP ,该请求在收到488（在这里不能接收）响应后生成，UE将包括SDP载荷，SDP载荷含有被允许媒体类型子集，编解码和来自与同一个会话建立请求相关的所有488响应有效载荷的其他参数。（例如，建立会话的请求是一套用于同一会话建立的INVITE请求）按照488响应的SDP载荷中编解码的顺序，UE将排列SDP载荷的编解码
NOTE 3: UE可能用不同的策略试图建立一个穿越多个网络的会话同时可能潜在的需要发送多个INVITE请求和收到来自不同cscf节点的多个488响应。因此当建立一个新的INVITE请求时，UE考虑与同一会话建立相关的收到的488响应中的SDP内容。
12.当UE收到一个初始的INVITER请求，请求中包括含有UE不支持的IP地址类型（在"c=“参数中）的SDP offer，带有201警告头的488响应回答该INVITE请求。其中的警告头表明“不兼容的网络地址格式”
6.2 在P-CSCF上的步骤
当P-CSCF收到任何含有SDP offer的SIP请求，P-CSCF将检查收到的SDP中的媒体参数。根据本地的策略，如果P-CSCF发现任何网络上不允许的媒体参数，P-CSCF将返回含有SDP载荷的488响应。这个SDP载荷包含所有的媒体类型，编解码方法和按照本地策略允许的其他SDP参数。或者依据P-CSCF运营商配置包含这些允许参数的子集。子集可能依靠收到的SIP请求的的内容。在488响应中建立的SDP载荷和如RFC 3261 [26]描述的488响应中的UAS建立的SDP时同一个动作。P-CSCF将用首次列出的性能最优的编解码排列SDP的载荷。如果SDP offer被加密，P-CSCF可能拒绝请求
当P-CSCF收到含有SDP offer又不同于200（oK）响应的SIP响应，P-CSCF将不检查收到的SDP offer中的媒体参数。P-CSCF将检查以后的含有对这个offer的SDP回答的请求。并且如果需要（例如，UE产生的SDP回答违背了本地策略），P-CSCF将返回一个包含SDP载荷允许的本地策略的488响应。如果SDP回答被加密，P-CSCF将拒绝后续的请求
当P-CSCF收到包含SDPoffer 的200（oK）响应，P-CSCF将检查收到的SDP中的媒体参数。如果依据本地策略，S-CSCF发现任何网络上不允许的媒体参数，P-CSCF将向前转发SDP offer同时收到含有SDP回答的ACK请求，按照5.2.8.1.2描述的他将立即中止会话。如果SDP offer被加密，P-CSCF将向前转发SDPoffer而同时收到含有SDP回答的ACK请求，如 5.2.8.1.2描述的它将立即中止会话
当终结会话建立的P-CSCF收到初始的INVITE请求，或者用于发起会话的P-CSCF收到对应INVITE请求的183响应，P-CSCF可能按照RFC 3524 [54]描述的更改SDP目的是按照本地策略向UE指明成组的特殊的媒体流。这个策略用于确定是否P-CSCF将请求UE保持在不同IP-CAN承载中的成组的媒体流和确定不同媒体流和IP-CAN承载之间的关系（见 B.2.2.5用GPRS执行 IP-CAN）
P-CSCF将应用和保持来自包含SDP的初始请求或者响应同时贯穿整个SIP会话的SDP中的相同的策略。如果媒体流被添加同时成组的媒体流应用于会话，P-CSCF将按照RFC 3524 [54]修改SDP目的是向UE指出媒添加的媒体流将被分组到新的组中或者被分组到已经存在的组的一个中。P-CSCF将不指出在SDP中重组的媒体流。
如果在初始注册请求或者183响应中不指明成组的媒体流，对于额外的媒体流，P-CSCF不会将RFC 3524 [54]应用于SDP。
如果有，P-CSCF将监视"b=RS” 和"b=RR"列目的是发现RTCP需要的带宽分配
6.3 在S-CSCF 上的过程
当S-CSCF收到任何含有SDP offer的SIP请求，S-CSCF将检查收到的SDP中的媒体参数。如果依据本地策略或者订阅，S-CSCF发现任何不允许的媒体参数，S-CSCF将返回一个488响应，响应中包含SDP载荷。这个SDP载荷包含所有的媒体类型，编解码和其他依据本地策略和用户订阅或者依据S-CSCF运营商配置允许的SDP参数，这些被允许参数的子集。这个子集可能依靠收到的SIP请求的内容。在488响应中SCSF将建立一个SDP载荷，建立过程和RFC 3261 [26]中描述的在488响应中UAS建立SDP的动作一样。如果SDP offer加密，S-CSCF可能拒绝请求
当S-CSCF收到一个包含SDP offer并且不同于200（OK）响应的SIP响应，S-CSCF将不检查受到的SDP offer中的媒体参数。但是S-CSCF将将检查后续包含对这个offer回答的请求，S-CSCF将返回488响应，响应中包含本地策略允许的SDP载荷。如果SDP回答被加密，S-CSCF可能拒绝后续的请求
当S-CSCF收到一个200（OK）响应，响应中包含SDP offer，S-CSCF将检查收到的SDP中的媒体参数。如果依据本地策略或者订阅，S-CSCF发现任何不允许的媒体参数，S-CSCF向前转发SDP offer同时收到包含SDP 回答的ACK请求，按照 5.4.5.1.2描述的，S-CSCF将立即中止会话。
6.4 MGCF执行的步骤
6.4.1 呼叫起源于电路域网络
按照 6.1 和 A.3.2定义的，MGFC使用SDP和UE使用SDP一样，下面描述了一些例外

• 在MGCF产生的INVITER请求中，MGCF将指明预处理当前的状态，当发送一个SDP，在SDP中将不包括"i=", “u=”, “e=”, “p=”, “r=”, 和 "z="描述，同时在SDP中收到它将忽略他们
  当MGCF产生和发送一个用于在电路交换网上发起呼叫的INVITE请求，MGCF将

• 将SDP和联合MGW支持的编解码组装在一起（见3GPP TS 26.235 [10]用于支持的codecs）同时

• 为了支持DTMF，将SDP和RFC 2833 [23]描述的MIME子类型"telephone-event"组装在一起
  当MGCF对INVITE请求的收到183响应，MGCF将

• 检查SDP指出的被支持的编解码.
  6.4.2 中止于电路交换网络的呼叫
  按照 6.1 和 A.3.2定义的，MGFC使用SDP和UE使用SDP一样，下面描述了一些例外

• 当MGCF发送一个带有SDP载荷的183响应，如果这里有任何保留的无法执行的，在初始点他将仅请求确认资源预留的结果，
  当发送一个SDP，MGCF将不在SDP中包括"i=", “u=”, “e=”, “p=”, “r=”, 和 "z="描述，同时当在SDP中收到这些描述，将忽略他们
  当MGCF收到一个初始的INVITE请求，MGCF将

• 检查与被请求SDP匹配的编解码，该编解码包含如RFC 2833 [23]描述的MIME子类型"telephone-event"
  当MGCF生成和发送对应于初始INVITE请求的一个183响应，MGCF将

• 设置SDP表明被选的编解码，编解码包含RFC 2833 [23]描述的MIME子类型"telephone-event
  6.5 MRFC执行的步骤
  .无
  6.6 AS上执行的步骤
  由于AS可能提供一个范围广的不同的服务，扮演源UA、目标UA或者第三方呼叫控制的角色的AS使用SDP的过程依靠依靠提供给UA的服务同时还依靠远端UA的能力。关于使用，除了下面一段和A.3中描述的对SDP能力的需要，没有特殊的需要。

1. 如果AS产生的INVITE请求中包含SDP载荷，AS有能力反映源AS的能力、希望的QoS和在SDP载荷中对会话预处理的需要
2. 当AS发送一个带有SDP载荷的183响应，载荷中包含一个或者多个"m="媒体类型，在初始点AS有能力请求确认资源预留的结果
   6.7 在IMS-ALG上执行的步骤
   IMS-ALG执行的步骤和源UA和目的UA执行的步骤一致。IMS-ALG扮演一个B2BUA角色。在3GPP TS 29.162 [11A]中描述了源UA和目的UA将对SDP消息的处理
   7 现有文件中的扩展
   7.1 SIP methods defined within the present document
   在现有的文档中没有被定义的SIP方法
   7.2 SIP头在现有文件中的定义
   7.2.0 General
   在现有的文档中没有被定义的SIP头
   7.2.1 无
   7.2.2 无
   7.2.3 无
   7.2.4 无
   7.2.5 无
   7.2.6 无
   7.2.7 无
   7.2.8 无
   7.2.9 无
   7.2.10 无
   7.2A 扩展现有文件中定义的SIP头
   7.2A.1 扩展WWW-authenticate 头
   7.2A.1.1 介绍
   这个扩展定义一个用于401响应的WWW-Authenticate头新的认证参数（auth-para）。401是对注册消息的响应。更多的消息，见RFC 2617 [21]中的3.2.1节
   7.2A.1.2 语法
   . 在7.4中描述了auth-param的语法
   Table 7.4: Syntax of auth-param

auth-param = 1#( integrity-key / cipher-key )
integrity-key = “ik” EQUAL ik-value
cipher-key = “ck” EQUAL ck-value
ik-value = LDQUOT *(HEXDIG) RDQUOT
ck-value = LDQUOT *(HEXDIG) RDQUOT

7.2A.1.3 Operation 操作
如 5.4描述的认证过程，这个认证参数在401响应中的 WWW-authenticate认证头中使用
在401响应中的给WWW.-Authenticate头附加一个完整性密钥参数。P-CSCF存储完整性密钥的值同时从认证头中移走完整性密钥参数，然后将剩下的响应传递给UE.
在401响应中S-CSCF将加密密钥附加到WWW-Authenticate头中，P-CSCF将从认证头中移走加密密钥，然后将剩下的响应传递给UE。如果使用加密，P-CSCF将存储加密密钥的值
7.2A.2 对认证头的扩展
7.2A.2.1 介绍
这个扩展定义了一个新的 认证参数，该参数用于REGISTER请求中的认证头。需要更多的消息，见RFC 2617 [21] 3.2.2节.
7.2A.2.2 语法
在 7.5表格中定义了用于认证头的认证参数的语法
Table 7.5: Syntax of auth-param for Authorization header

auth-param = “integrity-protected” EQUAL (“yes” / “no”)

7.2A.2.3 操作
P-CSCF将认证参数插到来自UE的所有认证请求的认证头中。auth-param参数中的"integrity protected"按照 5.2.2描述的设置。按照5.4.1描述的S-CSCF使用这个信息决定挑战哪个不挑战哪个注册请求
7.2A.3 Tokenized-by参数定义
7.2A.3.1 介绍
tokenized-by参数是一个扩展参数，按照 5.3.3.1定义的将它附加到各种SIP头的被加密的实体上
7.2A.3.2 语法
在 7.6中定义了tokenized-by参数的语法
Table 7.6: Syntax of tokenized-by-param

uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / tokenized-by-param / other-param
tokenized-by-param = “tokenized-by” EQUAL hostname

IETF RFC 3261 [26]中提出用于uri-parameter的BNF，因此需要修改
7.2A.3.3 Operation 操作
当网络配置隐藏被激活，SIP头中所有的字符串被加密后，I-CSCF(THIG)添加tokenized-by参数。参数的值是加密信息的网络的域名
7.2A.4 P-Access-Network-Info头
7.2A.4.1 介绍
P-Access-Network-Info头是对包含与特殊接入拓扑结构相关的信息的扩展
7.2A.4.2 语法
在RFC 3455 [52]中描述了P-Access-Network-Info头的语法
7.2A.4.3 对P-Access-Network-Info头的其他编码规则
UE将组装P-Access-Network-Info头，5.1中有详细的描述，内容如下：

1. 按照使用的合适的无限技术，access-type被设为"3GPP-GERAN",“3GPP-UTRAN-FDD”, “3GPP-UTRAN-TDD”, “3GPP-CDMA2000”, “IEEE-802.11a” 或者"IEEE-802.11b"中的一种
   2）如果接入类型域设为"3GPP-GERAN"，cgi-3gpp参数设为从UE的底层获取的全局蜂窝标识。全局蜂窝标识是MCC、LAC和CI的串连，在3GPP TS 23.003 [3]中有描述。因此，“cgi-3gpp"参数的值是以文本形式编码的，如下所示：
   Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length code of 16 bits using full hexadecimal representation) and CI (fixed length code of 16 bits using a full hexadecimal representation);
   以最重要的比特开始，MCC（3 digits），MNC (依靠MCC的值2 or 3 digits)，LAC（使用完全的十六进制表示法的固定长度的码）和CI（使用完全的十六进制表示法的固定长度的码）
   3)如果接入类型域是"3GPP-UTRAN-FDD”, “3GPP-UTRAN-TDD” 或 “3GPP-CDMA2000”，"utran-cell-id-3gpp"参数设置成MCC, MNC, LAC（如3GPP TS 23.003 [3]描述的）和UMTS蜂窝身份（3GPP TS 25.331 [9A]中描述的）的串连。这些是从UE的底层得到的。以文本串的形式编码，如下所示：
   Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length code of 16 bits using full hexadecimal representation) and UMTS Cell Identity (fixed length code of 28 bits).
   以最重要的比特开始，MCC (3 digits)，MNC (依靠MCC 的值2 or或者3 digits)，LAC（使用完全的十六进制表示法的固定长度的码）和UMTS 蜂窝标识（使用完全的十六进制表示法的固定长度的码）
2. 如果接入类型域设为"IEEE-802.11a"或者 "IEEE-WLAN-802.11b"一种，接入信息参数设为控制。这个标准没有定义这个参数使用的值
   7.2A.5 P-Charging-Vector header P-Charging-Vector头
   7.2A.5.1 Introduction 介绍
   P-Charging-Vector header是对IM CN子系统功能实体需要的特殊的计费相关信息的扩展
   7.2A.5.2 语法
   7.2A.5.2.1 总的介绍
   P-Charging-Vector 头域的语法在RFC 3455 [52]中描述。按照接入技术的特殊描述，依靠IP-CAN的类型这里有其他的用于这个头的编码类型。
   表 7.3描述的是对RFC 3455 [52]中定义的P-Charging-Vector头的3Gpp专用扩展
   Table 7.3: Syntax of extensions to P-Charging-Vector header
   P-Charging-Vector的语法扩展

access-network-charging-info = (gprs-charging-info / i-wlan-charging-info / generic-param)
gprs-charging-info = ggsn SEMI auth-token [SEMI pdp-info-hierarchy] (SEMI extension-param)
ggsn = “ggsn” EQUAL gen-value
pdp-info-hierarchy = “pdp-info” EQUAL LDQUOT pdp-info (COMMA pdp-info) RDQUOT
pdp-info = pdp-item SEMI pdp-sig SEMI gcid [SEMI flow-id]
pdp-item = “pdp-item” EQUAL DIGIT
pdp-sig = “pdp-sig” EQUAL (“yes” / “no”)
gcid = “gcid” 1HEXDIG
auth-token = “auth-token” EQUAL 1HEXDIG
flow-id = “flow-id” EQUAL “(” “{” 1DIGIT COMMA 1DIGIT “}” (COMMA “{” 1DIGIT COMMA 1*DIGIT “}”)")"
extension-param = token [EQUAL token]
i-wlan-charging-info = “pdg”

access-network-charging-info参数是来自P-Charging-Vector头的当前charge-params成分的实例
access-network-charging-info参数包括对不同类型的接入网的可选性定义。在下面的条目中给出了这些参数的描述
接入网的计费姓习不包括在用于与会话无关的sip信令的P-Charging-Vector中
当接入网计费信息被包含在P-Charging-Vector中，从Go/Gq参考接口中不能获得必要的信息那么将包含空或者0值
7.2A.5.2.2 在IP－CAN中的GPRS
GPRS是初始被支持的接入网络（gprs-charging-info参数）。对于GPRS，有下面的成分被跟踪：GGSN的地址（ggsn参数），媒体认证标识（认证标识参数），和pdp-info参数，pdp-info参数中含有用于一个或者更多PDP上下文的信息。pdp-info包含一个或者多个在参数集合（(pdp-sig, gcid, 或者flow-id）中的pdp-item值。pdp-item的值是一个唯一的值，它标识了在P-Charging-Vector头中的每一个PDP相关的计费信息。如果IM CN子系统发信号PDP上下文(pdp-sig参数)、联合的GPRS计费标识（gcid参数），和一个标识符（flow-id参数）每个PDP上下文是一个指示器。flow-id参数包含一列圆括号，用圆括号定流标识符的界限。流标识符确定来自SIP信令的SDP中的联合的m-列和每个m-列的相关顺序的端口号。PDP上下文信息应用这些SIP信令。flow-id参数的语义的描述见3GPP TS 29.207 [12]附录C。通过PDF的Go接口和Gq 接口gcid，ggsn地址和flow-id参数从GGSN传到P-CSCF。Go接口的描述见3GPP TS 29.207 [12]，Gq接口的描述见3GPP TS 29.209 [13A]
gcid值已二进制的格式在P-CSCF上得到（见3GPP TS 29.207 [12]）。把gcid放到gcid参数中前，P-CSCF将把它编码成16进制的格式。收到这个头，节点将收到的gcid从16进制转化成2进制格式
接入网的计费信息不包含在用于SIP信令的的P-Charging-Vector中，这个SIP信令对于会话是不可得的。这个会话用一个一般目的的PDP上下文（对于SIP信令和媒体）或者会话不需要媒体认证
7.2A.5.2.3 I-WLAN as IP-CAN 最为IP-CAN的I-WLAN
接入网计费信息参数是来自当前计费向量头计费参数组成部分的的一个实例
这个协议的版本定义了使用"pdg"，因为"pdg"包含在计费向量头中，这个协议的版本中没有其他用在WLAN的扩展定义
7.2A.5.3 Operation 操作
头的操作在 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 和 5.8中有描述.
7.2A.6 Orig parameter definition Orig参数的定义
注意：按照draft-ietf-sip-uri-parameter-reg-0，所有的SIP和SIP URI参数必须在RFC中文档化以便被IANA注册。被注册的SIP或者SIPs URI参数将被认为是“保留字段”。3GPP将认为在RFC中描述了这些参数，同时IANA注册了。当这些发生，7.2A.6将被删除
7.2A.6.1 Introduction 介绍
"orig"参数是一个uri-parameter目的是告诉S-CSCF必须执行代替目的服务的源服务
7.2A.6.2 Syntax 语法
orig参数的语法吉安7.7中的定义
Table 7.7: Syntax of orig parameter

uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / orig / other-param
orig = “orig”

应用于uri-parameter 的BNF从IETF RFC 3261 [26]中得到，因此需要需要修改
7.2A.6.3 Operation 操作
当这些初始请求代表用户，AS将orig参数附加到S-CSCF地址上。无论orig参数是否在他的地址的下一个呈现，S-CSCF将运行原始的服务
7.3 在现有文档中定义的可选标签
在现有文档中没有定义可选标签
7.4 在现有文档中定义Status-codes
在现有文档中没有定义Status-codes
7.5 现有文档中定义会话
现有的文档中没有定义会话类型的描述
7.6 3GPP IMSXML体，版本1
7.6.1 综述
这里描述了文档类型定义，这被应用到3GPP IMCN子系统的XML体。按照需要，任何SIP用户代理或者proxy可以插入或者移走3GPP IMCN子系统XML体或者移走插入它的一部分3GPPImCN子系统将不被转发到3GPP网络以外
3GPP IMS XML和MINE类型的联合是"application/3gpp-ims+xml"
7.6.2 文档类型的定义
按照XML的语法定义，在7.7中定义了文档类型
Table 7.7: IM CN subsystem XML body, version 1 DTD

<?xml version="1.0" ?>

<!ELEMENT ims-3gpp (
	alternative-service?, service-info?)>
<!ATTLIST ims-3gpp version CDATA #REQUIRED>

<!-- service-info element: The transparent data received from HSS for AS -->
<!ELEMENT service-info				(#CDATA)>

<!-- alternative-service: alternative-service used in emergency sessions -->
<!ELEMENT alternative-service	(type, reason)>
<!ELEMENT type					(emergency)>
<!ELEMENT reason				(#PCDATA)>

]>

7.6.3 DTD描述
按照7.7中定义的文档类型，这里描述了IMS文档类型类型定义元
: 这是IMS XML体的一个根元，它将一直被呈现。在当前的文档中这个版本描述是1
: 从HSS中得到的透明元作为一个特殊的出发点在可选元中被放置
: 在当前的文档中，可选服务作为响应被使用目的是在IM CN子系统中试图建立一个应急会话。元描述一个可选的服务，该服务回教能够成功。通过服务类想信息可选服务被描述。可能引起为什么建议使用可选服务的原因可能被包括。
The element contains a element that indicates the type of alternative service. In the present document, the element contains only the value “emergency”.
元包含一个元，元表明可选服务的类型。在目前的文档中，元仅包含"emergency"值
元包含一个说明性的文档，原因说明了为什么会话建立被重定向。UE用这个信息提供给用户指示。
7.7 SIP定时器
在一些场景中RFC 3261 [26]定义的定时器需要被修改，以便兼容空中接口处理时进入的时延。表7.8中显示了用于IM CN子系统的被推荐的值
表7.8第一栏列出，标题是“SIP 定时器”，在RFC 3261 [26]中命名了定时器
第二栏，标题是”在IM CN子系统网元间应用的值”,列出了当相互通讯时，网元（例如：P-CSCF, S-CSCF, MGCF）建议使用的值。当不包含空中接口时，这些值和RFC 3261 [26]中推荐的一致
第三栏，标题时“UE上应用的值“列出了推荐UE使用的值。为了兼容空中接口的延时，需要修改RFC 3261 [26]
第四栏标题是“应用在P-CSCF传向UE的值“列出了当穿越空中接口，推荐P-CSCF使用的值。需要修改RFC 3261 [26]
最后一栏反映了在RFC 3261 [26].中定义的定时器的含义
Table 7.8: SIP timers
SIP Timer Value to be applied between IM CN subsystem elements Value to be applied at the UE Value to be applied at the P-CSCF toward a UE Meaning
T1 500ms default 2s default 2s default 建立RTT
T2 4s 16s 16s 对于non-INVITE请求和INVITE响应的最大传递间隔
T4 5s 17s 17s 在网络中保持的消息的最大持续时间
Timer A initially T1 initially T1 initially T1 仅用于UDP的，INVITE请求传递间隔
Timer B 64T1 64T1 64T1 INVITE传递中间停止定时器
Timer C > 3min > 3 min > 3 min Proxy INVITE 处理中间停止时间
Timer D > 32s for UDP >128s >128s 对响应转发等待时间
0s for TCP/SCTP 0s for TCP/SCTP 0s for TCP/SCTP
Timer E initially T1 initially T1 initially T1 non-INVITE请求转发间隔，仅应用与UDP
Timer F 64T1 64T1 64T1 non-INVITE处理中间停止时间
Timer G initially T1 initially T1 initially T1 INVITE响应转发间隔
Timer H 64T1 64T1 64T1 收到ACK的等待时间
Timer I T4 for UDP T4 for UDP T4 for UDP ACK转发等待时间
0s for TCP/SCTP 0s for TCP/SCTP 0s for TCP/SCTP
Timer J 64T1 for UDP 64T1 for UDP 64T1 for UDP 等待non-INVITE请求转发时间
0s for TCP/SCTP 0s for TCP/SCTP 0s for TCP/SCTP
Timer K T4 for UDP T4 for UDP T4 for UDP 等待响应转发时间
0s for TCP/SCTP 0s for TCP/SCTP 0s for TCP/SCTP

7.8 IMS定时器
7.9中描述了用于IM CN子系统的定时器的必须的值
Table 7.9: IM CN subsystem
Timer Value to be applied at the UE Value to be applied at the P-CSCF Value to be applied at the S-CSCF Meaning
reg-await-auth not applicable not applicable 4 minutes 在UE的认证过程中，这个定时器被S-CSCF使用，这个定时器的使用细节间5.4.1.2. 如果2次定时器 F，认证过程可能发生在最危险的情况下这里定时器F的值是128秒

注意: UE和P-CSCF使用reg-await-auth定时器的值去设置SIP层面上的临时使用的一套安全关联的生命周期
8 SIP信令压缩
8.1 在UE上SIP压缩的过程
8.1.1 SIP压缩
UE将支持RFC 3320 [32]中定义的信令压缩。当使用信令压缩，UE将发送一个按照RFC 3486 [55]压缩的SIP消息。什么时候UE生成一个容积是执行的细节，但是直到安全关联建立以后菜建立一个容器。当UE被注销，容积完成。在安全关联中收到消息，才允许状态生成和声明
注意：在注册时交换编解码将组织会话建立过程中不必要的延时
注意：draft-ietf-rohc-sigcomp-sip-01 [79]能指明额外交换和分类的必要
UE将支持RFC 3485 [42].描述的SIP字典。如果使用压缩，UE将使用字典压缩第一条消息
当信令压缩被使用时，应用如下：

• 必须满足状态内存长度大于0以便为UDVM字编码提供空间和实现动态压缩的可能，状态内存最少4096bite，这是最小值
• 解压内存长度最起码8192字节，这是最小的值
  8.1.2 SIP请求压缩和向P-CSCF传递响应
  按照 8.1.1描述的UE将压缩请求和传递到P-CSCF的响应
  注意1：执行SIP消息的压缩是可选的，但是，压缩是被强力推荐的
  注意2：用于支持压缩是强制的，UE可能发送第一条被压缩的消息，信令压缩提供了机制目的是允许UE知道在P-CSCF上的状态是否生成
  8.1.3 从P-CSCF中收到的SIP请求和响应的解压缩
  按照 8.1.1，UE将解压从P-CSCF收到的被压缩的请求和响应
  如果UE发现在P-CSCF上的解压失败，将应用专门的机制同时作为例子，可能包括重新安排压缩和改变压缩算法。
  8.2 在P-CSCF上的压缩过程
  8.2.1 SIP压缩
  P-CSCF将支持RFC 3320 [32]中定义的信令压缩。当使用信令压缩是，按照RFC 3486 [55]P-CSCF将发送被压缩的SIP消息。当P-CSCF生成执行特殊功能的容器，但是一套安全关联建立后代能生成容器。当用户注销是，容器完成。仅因为收到来自安全关联的消息，状态生命和建立被允许
  P-CSCF将支持RFC 3485 [42].描述的SIP字典。如果使用压缩，P-CSCF将使用字典压缩第一条消息
  P-CSCF
  注意：在注册时交换编解码将组织会话建立过程中不必要的延时
  注意: draft-ietf-rohc-sigcomp-sip-01 [79]能指明额外交换和分类的必要
  当信令压缩被使用时，应用如下：
• 必须满足状态内存长度大于0以便为UDVM字编码提供空间和实现动态压缩的可能，状态内存最少4096bite，这是最小值
• 解压内存长度最起码8192字节，这是最小的值
  8.2.2 压缩传递给UE的SIP请求和响应
  按照8.2.1，P-CSCF将压缩发送给UE的请求和响应
  注意：执行SIP消息的压缩是可选的，但是，压缩是被强力推荐的
  8.2.3 解压从UE收到的SIP请求和响应
  按照 8.2.1，P-CSCF将解压从UE收到的被压缩的请求和响应
  如果P-CSCF发现在UE端的解压失败，将应用专门的恢复机制，作为例子，回复机制可能包含重新安排压缩或者更换算法
  9 当接入到IM CN子系统，IP连接接入网方面
  9.1 介绍
  UE接入IMS和IM CN子系统自身执行IP－CAN支持的服务以便在UE和IMS间提供包模式通讯。在这节中详细说明了UE使用这些包模式服务的总需求
  对于每个IP-CAN，针对每个IP-CAN的细节部分可能分开描述
  9.2 在UE上的过程
  9.2.1 连接到IP-CAN，发现P-CSCF
  和IM CN子系统通讯前，UE将
  a) establish a connection with the IP-CAN; 建立和IP-CAN的连接
  b) 使用IETF标准(如DHCP 或 IPCP)或者使用针对于UE当前使用的IP-CAN技术的专用协议，获取IP地址。UEl连接到IM CN子系统的整个过程中，如：从初始注册最起码持续到最后一个注销，获取IP地址的方法是固定的。
  c) 获取P-CSCF的地址
  获取P-CSCF的地址的方法是.
  I. 应用应用于IPv6的动态主机配置方法，这些协议是RFC 3315 [40] 和 DHCPv6 Sip服务器选项 RFC 3319 [41].
  UE将
• 在DHCP查询中，请求一列P-CSCF的SIP服务器的域名和一列域名服务器，或者
• 请求一列P-CSCF的IPV6地址的SIP服务器
  II. 通过执行IP-CAN技术支持的过程获取P-CSCF的地址（如GPRS）
  当查询P-CSCF地址时，UE能自由选择方法1和2
  如RFC 3315 [40]定义的UE可能请求DNSIPV6地址
  9.2.2 Handling of the IP-CAN 处理IP-CAN
  UE将确保和SIP会话相关的IP-CAN上的媒体流能够获得合适的资源
  GPRS is described in annex B. I-WLAN is described in annex D.
  在附录B中描述了GPRS，在附录D中描述了I-WLAN
  9.2.3 应用分岔响应的特殊需求
  由于在第二个临时响应到来前UE不知道发生分岔。UE按照第一个临时响应的需求，申请无线/承载资源。对于每个后续收到的临时响应，依靠SDP会话的需求，执行不同的动作
• UE有足够的无线/承载资源以便处理后续响应的SDP指明的媒体
• UE必须请求额外的无线/承载资源以便适应后续临时响应的的SDP描述的媒体
  注意1：当收到多个分岔响应，UE请求的资源 “逻辑或”多个多个响应表明的资源以便避免不必要的资源分配。UE不能请求比最初INVITE请求提议多的资源
  注意2：当应用基于本地策略的服务，UE收到用于与同一会话相关的分岔的请求和响应的一样的认证标识
  当从早对话中收到第一个相对与INVITE 请求的200 (OK)最终响应，UE使用这个会话需要的无线/承载资源建立SIP会话。按照收到的相对与INVITE请求的第一个200（OK）最终响应，UE将释放所有不需要的无线/承载资源。