Internet Engineering Task Force (IETF) M. Mohali
Request for Comments: 8498 Orange
Updates: 5502 February 2019
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Mohali
Request for Comments: 8498 Orange
Updates: 5502 February 2019
Category: Informational
ISSN: 2070-1721
A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)
会话发起协议（SIP）中发起呼叫转移（CDIV）会话情况的P-SERVERED-User报头字段参数
Abstract
摘要
The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.
P-Served-User报头字段是基于来自第三代合作伙伴关系项目（3GPP）IMS（IP多媒体子系统）的需求定义的，以便传递服务用户的身份、他/她的注册状态以及适用于该特定通信会话和应用程序调用的会话情况。会话案例是元数据，它捕获服务用户的会话状态，而不管服务用户是否已注册或会话是否与服务用户一起发起或终止。本文档通过定义新的P-SERVERED-User标题字段参数“orig cdiv”来更新RFC 5502。该参数表示在为服务用户调用呼叫转移（CDIV）服务后处理发起会话时代理使用的会话情况。本文档还修复了RFC 5502中的ABNF，并为在IP网络中使用P-SERVERED-User报头字段提供了更多指导。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8498.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8498.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Proxy Behavior and Parameter Handling . . . . . . . . . . . . 6
5. Clarification of RFC 5502 Procedures . . . . . . . . . . . . 7
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 9
7.1. Call Diversion Case . . . . . . . . . . . . . . . . . . . 9
7.2. Call Diversion and Privacy . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Proxy Behavior and Parameter Handling . . . . . . . . . . . . 6
5. Clarification of RFC 5502 Procedures . . . . . . . . . . . . 7
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 9
7.1. Call Diversion Case . . . . . . . . . . . . . . . . . . . 9
7.2. Call Diversion and Privacy . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
The P-Served-User header field [RFC5502] was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/her registration state, and the session case between a Serving Call Session Control Function (S-CSCF) and an Application Server (AS) on the IMS Service Control (ISC) interface. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. For more information on session cases and the IMS, a detailed description can be found in [TS.3GPP.24.229].
基于第三代合作伙伴项目（3GPP）IMS（IP多媒体子系统）的要求定义P服务用户报头字段[rfc502]，以便在服务呼叫会话控制功能（S-CSCF）和应用服务器（AS）之间传递服务用户的身份、他/她的注册状态和会话情况在IMS服务控制（ISC）接口上。会话案例是元数据，它捕获服务用户的会话状态，而不管服务用户是否已注册或会话是否与服务用户一起发起或终止。有关会话案例和IMS的更多信息，请参见[TS.3GPP.24.229]中的详细说明。
[RFC5502] defines the originating and terminating session cases for a registered or unregistered user. This document extends the P-Served-User header field to include the session case for a forwarded leg when both a CDIV service has been invoked and an originating service of the diverting user has to be triggered.
[RFC5502]定义注册或未注册用户的发起和终止会话情况。本文档扩展了P-SERVERED-User标头字段，以包括当CDIV服务已被调用且必须触发转移用户的原始服务时，转发分支的会话情况。
The sessioncase-param parameter of the P-Served-User header field is extended with the "orig-cdiv" parameter for this originating-after-CDIV session case.
P-Served-User标头字段的sessioncase param参数使用“orig cdiv”参数进行扩展，以用于此在cdiv会话之后发起的情况。
The following section defines usage of the "orig-cdiv" parameter of the P-Served-User header field, Section 3 discusses the applicability and scope of this new header field parameter, and Section 4 specifies the proxy behavior for handling the new header field parameter. Section 5 clarifies some of the [RFC5502] procedures, Section 6 describes the extended syntax and corrects the syntax of [RFC5502], Section 7 gives some call flow examples, Section 8 registers the P-Served-User header field parameters with IANA, and Section 9 discusses the security properties of the environment where this new header field parameter is intended to be used.
下一节定义了P-SERVERED-User标头字段的“orig cdiv”参数的用法，第3节讨论了此新标头字段参数的适用性和范围，第4节指定了处理新标头字段参数的代理行为。第5节澄清了一些[RFC5502]程序，第6节描述了扩展语法并更正了[RFC5502]的语法，第7节给出了一些调用流示例，第8节向IANA注册了P-SERVERED-User报头字段参数，第9节讨论了打算使用这个新的头字段参数的环境的安全属性。
In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) is a SIP proxy that serves as a registrar and handles originating and terminating session states for users assigned to it. This means that any call that is originated by a specific user or any call that is terminated to that specific user will pass through the S-CSCF that is assigned to that user.
在3GPP IMS（IP多媒体子系统）中，S-CSCF（服务CSCF）是SIP代理，充当注册器并为分配给它的用户处理发起和终止会话状态。这意味着由特定用户发起的任何呼叫或终止给该特定用户的任何呼叫将通过分配给该用户的S-CSCF。
At the moment that an S-CSCF is assigned to a specific user, the user profile is downloaded from the Home Subscriber Server (HSS) to that S-CSCF; see [TS.3GPP.29.228]. The user profile contains the list of actions to be taken by the S-CSCF for the served user depending on the session direction (originating or terminating) and the user state (registered or not) in the IMS network. With this user profile, the S-CSCF determines the current case and applies the corresponding actions such as forwarding the request to an AS. The AS then goes through a similar process of determining who is the current served user, what is his/her "registration state", and what is the "session case" of the session. [RFC5502] defines all those parameters and in particular the originating and terminating session cases.
在将S-CSCF分配给特定用户的时刻，将用户简档从归属订户服务器（HSS）下载到该S-CSCF；见[TS.3GPP.29.228]。用户简档包含S-CSCF根据IMS网络中的会话方向（发起或终止）和用户状态（注册或未注册）为被服务用户采取的动作的列表。使用此用户配置文件，S-CSCF确定当前情况并应用相应的操作，例如将请求转发给as。AS然后经历确定谁是当前服务用户、他/她的“注册状态”是什么以及会话的“会话情况”是什么的类似过程。[RFC5502]定义了所有这些参数，尤其是发起和终止会话情况。
In basic call scenarios, there is no particular issue for the S-CSCF and AS to know which scenario needs to be realized, but in case of CDIV services for which the session is re-targeted, the session cases defined in [RFC5502] pose some limitations as described in the following section.
在基本呼叫场景中，S-CSCF没有特别的问题，也不知道需要实现哪种场景，但是在会话被重新定位的CDIV服务的情况下，[RFC5502]中定义的会话案例造成了一些限制，如下节所述。
To illustrate the problem statement, let's imagine Alice trying to call Bob and Bob having a CDIV service activated towards Carol's address. In the case of a CDIV service, the received request is first treated as a terminating session case (at Bob's side), and the terminating filter criteria configured in the S-CSCF is performed. A filter criteria is information in the user profile that determines whether an initial request is sent to a particular AS. When the AS receives the call initiation request, the AS is able to determine the served user (Bob) and the session case (here "term") from the received P-Served-User header field content and is able to execute terminating services. When the CDIV service is executed (as a terminating service of Bob), the AS changes the target (Request-URI) of the session (toward Carol's address) and a new call leg is created. The served user becomes the diverting user. This new call leg could be considered as an originating call leg from the diverting user (Bob), but this is not the case. Indeed, the originating user remains the same (Alice), and some of the diverting user's originating services should not be triggered as if it was an originating call. For instance, the originating user identity (Alice) should not be restricted because the diverting user (Bob) has a privacy service for his own identity. The privacy of the diverting user should apply to information related to this user only (e.g., in the History-Info header field). In the same manner, some specific services will need to be triggered on the outgoing leg after a CDIV. Without a dedicated session case for originating-after-CDIV, the S-CSCF cannot trigger an originating service for the diverting user, nor can an AS execute the procedures for this particular session case.
为了说明问题陈述，让我们假设Alice试图给Bob打电话，Bob激活了指向Carol地址的CDIV服务。在CDIV服务的情况下，接收到的请求首先被视为终止会话情况（在Bob侧），并且执行在s-CSCF中配置的终止过滤标准。筛选条件是用户配置文件中的信息，用于确定初始请求是否发送到特定AS。当AS接收到呼叫发起请求时，AS能够根据接收到的P-served-user报头字段内容确定服务用户（Bob）和会话情况（这里是“术语”），并且能够执行终止服务。当执行CDIV服务（作为Bob的终止服务）时，as更改会话的目标（请求URI）（朝向Carol的地址），并创建一个新的呼叫分支。服务用户成为转移用户。这个新的呼叫分支可以被认为是来自转移用户（Bob）的原始呼叫分支，但事实并非如此。事实上，始发用户保持不变（Alice），并且一些转移用户的始发服务不应该像始发呼叫一样被触发。例如，不应限制原始用户标识（Alice），因为转移用户（Bob）具有针对其自身标识的隐私服务。转移用户的隐私应仅适用于与该用户相关的信息（例如，在历史信息标题字段中）。同样，在CDIV之后，一些特定的服务将需要在传出分支上触发。如果没有在CDIV之后发起的专用会话情况，S-CSCF无法为转移用户触发发起服务，AS也无法执行该特定会话情况的过程。
For this use case, this document creates a new parameter ("orig-cdiv") for the originating-after-CDIV session case to be embedded in the P-Served-User header field.
对于这个用例，本文档为要嵌入到P-SERVERED-User头字段中的发起后cdiv会话用例创建一个新参数（“orig cdiv”）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The use of the P-Served-User header field extensions is only applicable inside a Trust Domain [RFC3324] for the P-Served-User header field. Nodes in such a Trust Domain explicitly trust each other to convey the served user and to be responsible for withholding that information outside of the Trust Domain. The means by which the network determines the served user and the policies that are executed for a specific served user is outside the scope of this document.
P-SERVERED-User标头字段扩展的使用仅适用于P-SERVERED-User标头字段的信任域[RFC3324]内。这种信任域中的节点明确地相互信任，以传递服务用户，并负责在信任域之外保留该信息。网络确定服务用户的方式以及为特定服务用户执行的策略不在本文档的范围内。
The following section illustrates how this header field parameter can be used in a 3GPP network.
以下部分说明如何在3GPP网络中使用此报头字段参数。
For a terminating call, the following steps will be followed:
对于终止呼叫，将遵循以下步骤：
1. The S-CSCF receives the initial INVITE request for a terminating call and determines that the session case is for a terminating user as described in [RFC5502].
1. S-CSCF接收终止呼叫的初始INVITE请求，并确定会话情况适用于[RFC5502]中所述的终止用户。
2. The S-CSCF determines who is the served user by looking at the Request-URI and saves the current Request-URI.
2. S-CSCF通过查看请求URI来确定谁是服务用户，并保存当前请求URI。
3. The S-CSCF analyzes the filter criteria. It then sends the request to the AS of the served user as an INVITE that includes the P-Served-User header field with the "sescase" parameter set to "term" and the "regstate" set to the corresponding value in order to trigger execution of terminating services.
3. S-CSCF分析过滤标准。然后，它将请求作为邀请发送给服务用户的AS，其中包括P-served-user标头字段，其中“sescase”参数设置为“term”，而“regstate”设置为相应的值，以便触发终止服务的执行。
4. Based on some criteria, the AS concludes that the request has to be diverted to another target user or application. The AS replaces the received Request-URI with the new diverted-to address and stores the successive Request-URI(s) values by adding one or two History-Info header field entry(ies) [RFC7044] in the outgoing INVITE. In the History-Info header field, the served user address is tagged by using the mp-param header field parameter added in the newly created entry that contains the diverted-to address. The AS forwards the INVITE request back to the S-CSCF.
4. 根据一些标准，AS得出结论，请求必须转移到另一个目标用户或应用程序。AS将接收到的请求URI替换为新的转移到地址，并通过在传出的INVITE中添加一个或两个历史信息头字段条目[RFC7044]来存储连续的请求URI值。在History Info header字段中，通过使用在新创建的条目中添加的mp param header字段参数标记服务用户地址，该条目包含转移到的地址。AS将INVITE请求转发回S-CSCF。
5. When receiving back the INVITE request, the S-CSCF can see that the topmost Route header field contains its own hostname, but the Request-URI does not match the saved Request-URI. In this case, the S-CSCF updates the P-Served-User header field content by replacing the "sescase" parameter with the "orig-cdiv" parameter. The P-Served-User header field value remains unchanged.
5. 当接收回INVITE请求时，S-CSCF可以看到最顶端的路由头字段包含自己的主机名，但请求URI与保存的请求URI不匹配。在这种情况下，S-CSCF通过将“sescase”参数替换为“orig cdiv”参数来更新P-Served-User报头字段内容。P-SERVERED-User标头字段值保持不变。
6. The S-CSCF forwards the INVITE request to an AS that hosts the served user's (diverting user's) originating services, which need to be executed on the forwarded leg after a CDIV service.
6. S-CSCF将INVITE请求转发给承载服务用户（转移用户）的发起服务的AS，该服务需要在CDIV服务之后在转发的分支上执行。
7. When the AS receives the INVITE request, it determines that the session case is for the "orig-cdiv" session case and performs the originating services to be executed after retargeting for the diverting user (i.e., served user).
7. 当AS接收到INVITE请求时，它确定会话情况是针对“orig cdiv”会话情况的，并在为转移用户（即，服务用户）重定目标之后执行要执行的发起服务。
This document provides the following guidance for the handling of the P-Served-User header field that is missing in [RFC5502]:
本文档为[RFC5502]中缺少的P-SERVERED-User报头字段的处理提供了以下指导：
o The P-Served-User header field MUST NOT be repeated within a request for a particular session at a particular time for the reason that session cases are mutually exclusive. This document updates [RFC5502] to clearly state that the P-Served-User header field MUST NOT contain multiple values either comma-separated or header-separated. This document also updates the syntax of the header from [RFC5502] to reflect this uniqueness of parameter values.
o P-SERVERED-User标头字段不得在特定时间在特定会话的请求中重复，因为会话案例是互斥的。本文档更新[RFC5502]以明确说明P-SERVERED-User标头字段不得包含多个逗号分隔或标头分隔的值。本文档还更新了[RFC5502]中标题的语法，以反映参数值的唯一性。
o [RFC5502] does not clearly state what to do with the received P-Served-User header field when a call is diverted to another destination. This document highlights that there are several ways of handling the P-Served-User header field: the S-CSCF could store the previous "regstate" value and decide that the same value applies, the "regstate" may no longer be relevant after a diverting service so the S-CSCF removes it, or the "regstate" could be combined with the "orig-cdiv" session case to provide different services depending on whether the served user is registered or unregistered. These choices are implementation dependent.
o [RFC5502]未明确说明当呼叫转移到另一个目的地时，如何处理接收到的P-SERVERED-User报头字段。本文档强调有几种处理P-SERVERED-User标头字段的方法：S-CSCF可以存储以前的“regstate”值并决定应用相同的值，“regstate”在转移服务后可能不再相关，因此S-CSCF将其删除，或者“regstate”可以与“orig cdiv”组合会话案例，根据服务用户是已注册还是未注册提供不同的服务。这些选择取决于实现。
[RFC5502] defines the P-Served-User header field with the sessioncase-param parameter "sescase", which is specified as having "orig" and "term" as predefined values. This document defines an additional parameter, "orig-cdiv", for the sessioncase-param.
[RFC5502]使用sessioncase参数“sescase”定义P-SERVERED-User标头字段，该参数被指定为具有“orig”和“term”作为预定义值。本文档为sessioncase参数定义了一个附加参数“orig cdiv”。
Because this document extends the existing sessioncase-param parameter, and because errors have been identified in the syntax, this document corrects and extends the P-Served-User header field.
由于本文档扩展了现有的sessioncase param参数，并且在语法中发现了错误，因此本文档更正并扩展了P-Served-User头字段。
The extension of the sessioncase-param parameter to add the "orig-cdiv" session case is done in a way that fits the parameter format introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and maintains backward compatibility.
sessioncase param参数的扩展以添加“orig cdiv”会话案例，其方式符合3GPP[TS.3GPP.24.229]第11版中引入的参数格式，并保持向后兼容性。
"EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic-param" are defined in [RFC3261].
[RFC3261]中定义了“EQUAL”、“HCOLON”、“SEMI”、“name addr”、“addr spec”和“generic param”。
If the "addr-spec" contains a comma, question mark, or semicolon, the "name-addr" form MUST be used. The "name-addr" form requires the use of angle brackets (< and >).
如果“addr spec”包含逗号、问号或分号，则必须使用“name addr”形式。“name addr”表单需要使用尖括号（<和>）。
The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P-Served-User header field is described in [RFC5502].
P-SERVERED-User报头字段的扩充Backus Naur Form（ABNF）[RFC5234]语法如[RFC5502]所述。
This document updates [RFC5502] to correct the P-Served-User header field ABNF syntax and extend it as the following:
本文档更新[RFC5502]以更正P-SERVERED-User标头字段ABNF语法，并将其扩展如下：
P-Served-User = "P-Served-User" HCOLON PServedUser-value
*(SEMI served-user-param)
served-user-param = sessioncase-param
/ registration-state-param
/ generic-param
PServedUser-value = name-addr / addr-spec
sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv
registration-state-param = "regstate" EQUAL ("unreg" / "reg")
orig-cdiv = "orig-cdiv"
P-Served-User = "P-Served-User" HCOLON PServedUser-value
*(SEMI served-user-param)
served-user-param = sessioncase-param
/ registration-state-param
/ generic-param
PServedUser-value = name-addr / addr-spec
sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv
registration-state-param = "regstate" EQUAL ("unreg" / "reg")
orig-cdiv = "orig-cdiv"
Examples of possible P-Served-User header fields:
可能的P-SERVERED-User头字段示例：
P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg
or
P-Served-User: <sip:user@example.com>; orig-cdiv
or
P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg
P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg
or
P-Served-User: <sip:user@example.com>; orig-cdiv
or
P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg
This document allows choosing between "addr-spec" and "name-addr" when constructing the header field value. As specified in RFC 8217, the "addr-spec" form MUST NOT be used if its value would contain a comma, semicolon, or question mark [RFC8217].
在构造标题字段值时，本文档允许在“addr spec”和“name addr”之间进行选择。如RFC 8217所述，如果“addr spec”表单的值包含逗号、分号或问号[RFC8217]，则不得使用该表单。
The following call flow shows a session establishment when Alice calls Bob, who has a CDIV service that diverts to Carol when Bob is busy.
下面的调用流显示了Alice调用Bob时建立的会话，Bob有CDIV服务，Bob忙时会转到Carol。
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| INVITE F4 | |
| |-------------------------------->| |
| | 486 F5 | |
| |<--------------------------------| |
| | 486 F6 | | |
| |--------------->| | |
| | INVITE F7 | | |
| |<---------------| | |
| | INVITE F8 | | |
| |--------------->| | |
| | INVITE F9 | | |
| |<---------------| INVITE F10 |
| |------------------------------------------------->|
| | | | |
| | | | 180 F11 |
| | | 180 F12 |<---------------|
| | 180 F13 |<---------------| |
| 180 F14 |<---------------| | |
|<---------------| | | |
| | | | |
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| INVITE F4 | |
| |-------------------------------->| |
| | 486 F5 | |
| |<--------------------------------| |
| | 486 F6 | | |
| |--------------->| | |
| | INVITE F7 | | |
| |<---------------| | |
| | INVITE F8 | | |
| |--------------->| | |
| | INVITE F9 | | |
| |<---------------| INVITE F10 |
| |------------------------------------------------->|
| | | | |
| | | | 180 F11 |
| | | 180 F12 |<---------------|
| | 180 F13 |<---------------| |
| 180 F14 |<---------------| | |
|<---------------| | | |
| | | | |
[Alice calls Bob]
[爱丽丝打电话给鲍勃]
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F4 INVITE S-CSCF-B -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F4 INVITE S-CSCF-B -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
[Bob is busy. His CDIV when busy is invoked towards Carol]
[鲍勃很忙，忙时他的CDIV被调用给卡罗尔]
F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B
486 BUSY
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>;tag=es43sd
F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B
486 BUSY
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>;tag=es43sd
[Alice's call is diverted to Carol]
[爱丽丝的电话转到卡罗尔那里]
F7 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F7 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
[The forwarded leg to Carol is identified as an originating call after CDIV, which should not trigger all of Bob's originating services]
[转发至Carol的分支被识别为CDIV后的始发呼叫，这不应触发Bob的所有始发服务]
F8 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F8 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F9 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F9 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F10 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
F10 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Figure 1. P-Served-User During CDIV Service
图1。CDIV服务期间的P服务用户
The following call flow shows a CDIV use case for which Alice has no identity restriction service and Bob has an unconditional CDIV service towards Carol and an identity presentation restriction service.
下面的调用流显示了一个CDIV用例，其中Alice没有身份限制服务，Bob对Carol有无条件的CDIV服务和身份表示限制服务。
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| | |
| | INVITE F4 | | |
| |--------------->| | |
| | INVITE F5 | | |
| |<---------------| INVITE F6 | |
| |------------------------------------------------->|
| | | | |
| | | | 180 F7 |
| | | 180 F8 |<---------------|
| | 180 F9 |<---------------| |
| 180 F10 |<---------------| | |
|<---------------| | | |
| | | | |
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| | |
| | INVITE F4 | | |
| |--------------->| | |
| | INVITE F5 | | |
| |<---------------| INVITE F6 | |
| |------------------------------------------------->|
| | | | |
| | | | 180 F7 |
| | | 180 F8 |<---------------|
| | 180 F9 |<---------------| |
| 180 F10 |<---------------| | |
|<---------------| | | |
| | | | |
[Alice calls Bob]
[爱丽丝打电话给鲍勃]
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Supported: histinfo
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Supported: histinfo
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
[Bob's unconditional CDIV to Carol is triggered]
[触发了Bob对Carol的无条件CDIV]
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
[Alice's call is diverted to Carol]
[爱丽丝的电话转到卡罗尔那里]
F4 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F4 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F5 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F5 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
[Forwarded leg to Carol is identified as an originating call after CDIV that allows Bob's privacy service to be applied to his identity within the History-Info header field]
[转发至Carol的分支被识别为CDIV后的原始呼叫，允许Bob的隐私服务应用于历史信息标题字段中的身份]
F6 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
<sip:carol@192.0.2.7>;index=1.1.1;rc=1.1
F6 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
<sip:carol@192.0.2.7>;index=1.1.1;rc=1.1
Figure 2. P-Served-User When Privacy Requested
图2。当请求隐私时，P-SERVERED-User
The syntax of the P-Served-User header field [RFC5502] is updated in Section 4 of this document.
本文件第4节更新了P-SERVERED-User报头字段[RFC5502]的语法。
IANA has updated the existing row for the P-Served-User header field in the "Header Fields" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:
IANA已更新“会话启动协议（SIP）参数”注册表中“header Fields”子区域中P-SERVICED-User header字段的现有行：
Header Name Compact Form Reference
------------- ------------ ------------------
P-Served-User none [RFC5502][RFC8498]
Header Name Compact Form Reference
------------- ------------ ------------------
P-Served-User none [RFC5502][RFC8498]
IANA has added new rows for the P-Served-User header field parameters in the "Header Field Parameters and Parameter Values" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry (as per the registry created by [RFC3968]):
IANA已在“会话启动协议（SIP）参数”注册表中的“header field parameters and Parameter Values”（根据[RFC3968]创建的注册表）子域中为P-SERVICED-User header field参数添加了新行：
Header Field Parameter Name Predefined Values Reference
-------------- ---------------- ----------------- -------------
P-Served-User sescase Yes [RFC5502]
P-Served-User regstate Yes [RFC5502]
P-Served-User orig-cdiv No [RFC8498]
Header Field Parameter Name Predefined Values Reference
-------------- ---------------- ----------------- -------------
P-Served-User sescase Yes [RFC5502]
P-Served-User regstate Yes [RFC5502]
P-Served-User orig-cdiv No [RFC8498]
The security considerations in [RFC5502] apply.
[RFC5502]中的安全注意事项适用。
As the "orig-cdiv" parameter of the P-Served-User header field can be used to trigger applications when a call is diverted, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity. Thus, the P-Served-User header field is to be used in a trusted environment, and proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another trusted proxy.
由于P-Served-User报头字段的“orig cdiv”参数可用于在呼叫转移时触发应用程序，因此确保未经授权的SIP实体未将该参数添加到SIP消息中非常重要。因此，P-Served-User报头字段将在可信环境中使用，并且除非代理充分了解路由集包括另一个可信代理，否则不得插入报头。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, <https://www.rfc-editor.org/info/rfc3324>.
[RFC3324]Watson，M.，“网络断言身份的短期要求”，RFC 3324，DOI 10.17487/RFC3324，2002年11月<https://www.rfc-editor.org/info/rfc3324>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8217] Sparks, R., "Clarifications for When to Use the name-addr Production in SIP Messages", RFC 8217, DOI 10.17487/RFC8217, August 2017, <https://www.rfc-editor.org/info/rfc8217>.
[RFC8217]Sparks，R.“关于何时在SIP消息中使用名称addr Production的澄清”，RFC 8217，DOI 10.17487/RFC82172017年8月<https://www.rfc-editor.org/info/rfc8217>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <https://www.rfc-editor.org/info/rfc3968>.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理局（IANA）头字段参数注册表”，BCP 98，RFC 3968，DOI 10.17487/RFC3968，2004年12月<https://www.rfc-editor.org/info/rfc3968>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <https://www.rfc-editor.org/info/rfc7044>.
[RFC7044]Barnes，M.，Audet，F.，Schubert，S.，van Elburg，J.，和C.Holmberg，“请求历史信息会话启动协议（SIP）的扩展”，RFC 7044，DOI 10.17487/RFC70442014年2月<https://www.rfc-editor.org/info/rfc7044>.
[RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 2009, <https://www.rfc-editor.org/info/rfc5502>.
[RFC5502]van Elburg，J.，“3GPP IP多媒体（IM）核心网络（CN）子系统的SIP P服务用户专用报头（P报头）”，RFC 5502，DOI 10.17487/RFC5502，2009年4月<https://www.rfc-editor.org/info/rfc5502>.
[TS.3GPP.24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3", 3GPP TS 24.229 11.28.0, December 2018.
[TS.3GPP.24.229]3GPP，“基于会话发起协议（SIP）和会话描述协议（SDP）的IP多媒体呼叫控制协议；第3阶段”，3GPP TS 24.229 11.28.02018年12月。
[TS.3GPP.29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 15.1.0, September 2018.
[TS.3GPP.29.228]3GPP，“IP多媒体（IM）子系统Cx和Dx接口；信令流和消息内容”，3GPP TS 29.228 15.1.02018年9月。
Acknowledgments
致谢
The author wishes to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks to Dale Worley, Jean Mahoney, and Ben Campbell for their careful review of the document. Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer Holmberg.
作者希望感谢3GPP社区对本文档提供的指导、意见和评论。感谢Dale Worley、Jean Mahoney和Ben Campbell对该文件的仔细审查。多亏了保罗·基齐瓦特和亚当·罗奇。特别感谢克里斯特·霍姆伯格。
Author's Address
作者地址
Marianne Mohali Orange Orange Gardens, 44 avenue de la Republique Chatillon 92326 France
法国查蒂隆共和国大道44号玛丽安·莫哈里橙色花园92326
Email: marianne.mohali@orange.com
Email: marianne.mohali@orange.com