Network Working Group J. van Elburg
Request for Comments: 5502 Ericsson Telecommunicatie B.V.
Category: Informational April 2009
Network Working Group J. van Elburg
Request for Comments: 5502 Ericsson Telecommunicatie B.V.
Category: Informational April 2009
The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem
3GPP IP多媒体（IM）核心网络（CN）子系统的SIP P服务用户专用报头（P报头）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation.
本文档指定SIP P-SERVERED-User P-header。此标头字段解决了在ISC（IMS服务控制）接口上的S-CSCF（服务呼叫会话控制功能）和AS（应用服务器）之间的第三代合作伙伴关系项目（3GPP）IMS（IP多媒体子系统）中发现的问题。此标头字段传递服务用户的身份以及适用于此特定通信会话和应用程序调用的会话案例。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Definitions .....................................................3
3.1. Identity, Network Asserted Identity, Trust Domain,
and Spec(T) ................................................3
3.2. Served User ................................................3
4. Scenarios .......................................................4
4.1. General ....................................................4
4.2. Diversion: Continue on Terminating Leg, but Finish
Subsequent Terminating iFC First ...........................5
4.3. Diversion: Create New Originating Leg and Provide
Originating iFC Processing .................................6
4.4. Call Out of the Blue: on Behalf of User B, but
Service Profile of Service Identity C.......................8
5. Requirements ....................................................8
6. P-Served-User Header Field Definition ...........................9
7. Proxy Behavior ..................................................9
7.1. Generating the P-Served-User Header ........................9
7.2. Consuming the P-Served-User Header ........................10
8. Applicability ..................................................10
9. IANA Considerations ............................................11
10. Security Considerations .......................................11
11. Acknowledgments ...............................................11
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................12
Appendix A. Why the History-Info Header Is Not Suitable to
Convey the Served User Information on the ISC
Interface ............................................13
A.1. Semantics ................................................13
A.2. Additional Observations ..................................13
A.3. Conclusion ................................................14
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Definitions .....................................................3
3.1. Identity, Network Asserted Identity, Trust Domain,
and Spec(T) ................................................3
3.2. Served User ................................................3
4. Scenarios .......................................................4
4.1. General ....................................................4
4.2. Diversion: Continue on Terminating Leg, but Finish
Subsequent Terminating iFC First ...........................5
4.3. Diversion: Create New Originating Leg and Provide
Originating iFC Processing .................................6
4.4. Call Out of the Blue: on Behalf of User B, but
Service Profile of Service Identity C.......................8
5. Requirements ....................................................8
6. P-Served-User Header Field Definition ...........................9
7. Proxy Behavior ..................................................9
7.1. Generating the P-Served-User Header ........................9
7.2. Consuming the P-Served-User Header ........................10
8. Applicability ..................................................10
9. IANA Considerations ............................................11
10. Security Considerations .......................................11
11. Acknowledgments ...............................................11
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................12
Appendix A. Why the History-Info Header Is Not Suitable to
Convey the Served User Information on the ISC
Interface ............................................13
A.1. Semantics ................................................13
A.2. Additional Observations ..................................13
A.3. Conclusion ................................................14
The 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses SIP (RFC 3261 [2]) as its main signaling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [9] and 3GPP TS 24.229 [11].) 3GPP has identified issues with the linking in of a SIP application server that are most appropriately resolved by defining a new SIP P-header, according to the procedures in RFC 3427 [5].
第三代合作伙伴计划（3GPP）IMS（IP多媒体子系统）使用SIP（rfc3261[2]）作为其主要信令协议。（有关IMS的更多信息，可在3GPP TS 23.228[9]和3GPP TS 24.229[11]中找到详细说明）。3GPP已确定SIP应用服务器的接入问题，根据RFC 3427[5]中的程序，通过定义新的SIP P报头最合适地解决了这些问题。
The remainder of this document is organized as follows. Section 4 outlines the problem by using particular service scenarios, and Section 5 discusses the requirements derived from these scenarios. Section 6 defines the P-Served-User header field, which meets those requirements, Section 7 specifies the proxy behavior for the new header field, and Section 8 discusses the applicability and scope of this new header field. Section 9 registers the P-Served-User header field with the IANA, and Section 10 discusses the security properties of the environment where this header field is intended to be used.
本文件的其余部分组织如下。第4节通过使用特定的服务场景概述了问题，第5节讨论了从这些场景派生的需求。第6节定义了满足这些要求的P-Served-User标头字段，第7节指定了新标头字段的代理行为，第8节讨论了此新标头字段的适用性和范围。第9节向IANA注册P-SERVERED-User头字段，第10节讨论打算使用该头字段的环境的安全属性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The terms Identity, Network Asserted Identity, Trust Domain, and Spec(T) in this document are specified in RFC 3324 [3].
RFC 3324[3]中规定了本文件中的术语标识、网络断言标识、信任域和规范（T）。
The served user to a proxy or AS (Application Server) is the user whose service profile is accessed by that proxy or AS when an initial request is received that is originated by, originated on behalf of, or terminated to that user. This profile in turn provides some useful information (preferences or permissions) for processing at a proxy and, potentially, at an AS.
代理或AS（应用服务器）的服务用户是指其服务配置文件被该代理访问的用户，或在接收到由该用户发起、代表该用户发起或终止的初始请求时被该用户访问的用户。此配置文件反过来提供了一些有用的信息（首选项或权限），用于在代理上以及在AS上进行处理。
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 allocated 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 allocated to that user.
在3GPP IMS（IP多媒体子系统）中，S-CSCF（服务CSCF）是SIP代理，用作注册器并处理分配给它的用户的发起和终止会话状态。这意味着由特定用户发起的任何呼叫或终止给该特定用户的任何呼叫将通过分配给该用户的S-CSCF。
At the moment that an S-CSCF is allocated for a specific user, a user profile is downloaded to the S-CSCF from the HSS (Home Subscriber Server) over the Cx interface, see 3GPP TS 29.228 [12]. This user profile tells the S-CSCF whether the user is allowed to originate or terminate calls or whether an AS needs to be linked in over the ISC interface. The user profile information that determines whether a particular initial request needs to be sent to a particular AS is called the initial Filter Criteria (iFC), see for example 3GPP TS 23.218 [8].
在为特定用户分配S-CSCF时，用户配置文件通过Cx接口从HSS（家庭订户服务器）下载到S-CSCF，参见3GPP TS 29.228[12]。此用户配置文件告知S-CSCF是否允许用户发起或终止呼叫，或者AS是否需要通过ISC接口链接。确定特定初始请求是否需要发送给特定用户的用户简档信息称为初始过滤标准（iFC），例如参见3GPP TS 23.218[8]。
For an S-CSCF to be able to meet its responsibilities, it needs to determine on which user's behalf it is performing its tasks and which session case is applicable for the particular request. (For a definition of session case, see 3GPP TS 29.228 [12]). The session case distinguishes the originating and terminating call cases and determines whether or not the particular user is registered.
为了使S-CSCF能够履行其职责，它需要确定代表哪个用户执行其任务，以及哪个会话案例适用于特定请求。（有关会话情况的定义，请参见3GPP TS 29.228[12]）。会话情况区分发起和终止呼叫情况，并确定特定用户是否已注册。
When the S-CSCF determines that for an incoming initial request the originating call case applies, it determines the served user by looking at the P-Asserted-Identity header field (RFC 3325 [4]), which carries the network asserted identity of the originating user. When, after processing the iFC for this initial request, the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of determining the session case and the served user. Since it should come to the same conclusion that this is an originating session case, it also has to look at the P-Asserted-Identity header field to determine the served user.
当S-CSCF确定对于传入初始请求，发起呼叫情况适用时，它通过查看P-Asserted-Identity报头字段（RFC 3325[4]）来确定服务用户，该字段携带发起用户的网络断言标识。当在处理该初始请求的iFC之后，S-CSCF决定将该请求转发给AS时，AS必须经历确定会话情况和被服务用户的类似过程。由于应该得出相同的结论，即这是一个原始会话情况，因此还必须查看P-Asserted-Identity报头字段以确定服务用户。
When the S-CSCF determines that for an incoming initial request the terminating call case applies, it determines the served user by looking at the Request-URI (RFC 3261 [2]), which carries the identity of the intended terminating user. When, after processing the iFC for this initial request, the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of determining the session case and the served user. Since it should come to the same conclusion that this is a terminating session case, it also has to look at the Request-URI to determine the served user.
当S-CSCF确定对于传入的初始请求终止呼叫情况适用时，它通过查看带有预期终止用户的身份的请求URI（RFC 3261[2]）来确定服务用户。当在处理该初始请求的iFC之后，S-CSCF决定将该请求转发给AS时，AS必须经历确定会话情况和被服务用户的类似过程。由于应该得出相同的结论，即这是一个终止会话的情况，因此还必须查看请求URI以确定服务用户。
In the originating case, it can be observed that while the P-Asserted-Identity header field just represents the originating user when it enters the S-CSCF, it is overloaded with another meaning when it is sent to an AS over the ISC interface. This other meaning is that it serves as a representation of the served user.
在发起情况下，可以观察到，虽然P-Asserted-Identity报头字段在其进入S-CSCF时仅表示发起用户，但当其通过ISC接口发送到AS时，它被另一含义重载。另一个意思是，它作为服务用户的表示。
In the terminating case, a similar overloading happens to the Request-URI; while it first only represented the identity of the intended terminating user, it is overloaded with another meaning when it is sent to an AS over the ISC interface. This other meaning is that it serves as a representation of the served user.
在终止情况下，请求URI也会发生类似的重载；虽然它首先只表示预期终止用户的身份，但当它通过ISC接口发送到AS时，它会被另一种含义重载。另一个意思是，它作为服务用户的表示。
In basic call scenarios, this does not show up as a problem, but once more complicated service scenarios (notably forwarding services) need to be realized, it poses severe limitations. Such scenarios are brought forward in the following subsections.
在基本的呼叫场景中，这并不是一个问题，但一旦需要实现更复杂的服务场景（尤其是转发服务），它就会带来严重的限制。这些场景在以下小节中提出。
4.2. Diversion: Continue on Terminating Leg, but Finish Subsequent Terminating iFC First
4.2. 转移：继续终止分支，但首先完成后续终止
Imagine a service scenario where a user B has a terminating service that diverts the call to a different destination but is required to still execute subsequent terminating services for the same user. This means that this particular user has multiple iFC configured that are applicable for an incoming initial request. When the S-CSCF receives an initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI.
设想一个服务场景，其中用户B有一个终止服务，该服务将呼叫转移到不同的目的地，但仍需要为同一用户执行后续终止服务。这意味着该特定用户配置了多个适用于传入初始请求的iFC。当S-CSCF接收到初始INVITE请求时，它分析该请求并确定会话情况是针对终止注册用户的，然后通过查看请求URI将被服务用户确定为用户B。
Now the S-CSCF starts the iFC processing. The first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts user B's diversion service by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header. This allows the S-CSCF to correlate an INVITE coming from an AS over the ISC interface to the existing session that forwarded the INVITE to the AS in the first place.
现在，S-CSCF开始iFC处理。与INVITE请求匹配的第一个iFC通过将AS和s-CSCF自己的主机名添加到路由标头，使INVITE通过ISC接口转发到承载用户B的转接服务的AS。S-CSCF将原始对话标识符（ODI）添加到路由头上S-CSCF自己的主机名中。这允许S-CSCF通过ISC接口将来自AS的邀请与首先将邀请转发给AS的现有会话相关联。
When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Based on some criteria, the diversion service concludes that the request needs to be diverted to another user or application C. It does this by changing the Request-URI to C. Optionally, it records the Request-URI history by using the History- Info header field (RFC 4244 [7]). Then the AS removes
当AS接收到初始INVITE请求时，它分析该请求并确定会话情况是针对终止注册用户的，然后通过查看请求URI将服务用户确定为用户B。根据一些标准，转移服务得出结论，请求需要转移到另一个用户或应用程序C。它通过将请求URI更改为C来实现这一点。还可以选择使用history-Info标头字段（RFC 4244[7]）记录请求URI历史。然后，AS移除
itself from the Route header and routes the INVITE request back to the S-CSCF by using the topmost Route header field.
它本身从路由标头发送，并使用最顶端的路由标头字段将INVITE请求路由回S-CSCF。
When the S-CSCF receives the INVITE over the ISC interface, it can see that the Route header contains its own hostname and an ODI that correlates to an existing terminating session for user B. This can be used by the S-CSCF to analyze whether there are still unexecuted iFC. (Note that the current behavior of the S-CSCF on receiving an INVITE with a changed Request-URI is to terminate the iFC processing and to route the request based on the new Request-URI value.)
当S-CSCF通过ISC接口接收到INVITE时，它可以看到路由头包含自己的主机名和与用户B的现有终止会话相关的ODI。S-CSCF可以使用这一点来分析是否还有未执行的iFC。（请注意，S-CSCF在接收具有更改请求URI的邀请时的当前行为是终止iFC处理并基于新请求URI值路由请求。）
The process repeats itself. The INVITE is forwarded to the AS that is associated with this particular iFC. When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user C by looking at the Request-URI. This is clearly wrong, as the user being served is still user B.
这个过程会重复。邀请将转发给与此特定iFC关联的AS。当AS接收到初始INVITE请求时，它分析该请求并确定会话情况是针对终止注册用户的，然后通过查看请求URI将服务用户确定为用户C。这显然是错误的，因为被服务的用户仍然是用户B。
This scenario clearly shows the problem that occurs when the Request-URI is overloaded with the meanings "intended target identity" and "served user" with the operation as described in Section 4.1. And it shows that this use case can not be realized without introducing a mechanism that conveys information about the served user from the S-CSCF to the AS. Use of the History-Info element does not solve this problem as it does not tell the AS which user is being served; it just presents a history of diversions that might not be even caused by the systems serving this particular user. A more detailed analysis on why the History-Info header field can't be used is provided in Appendix A.
该场景清楚地显示了当请求URI被重载为“预期目标标识”和“服务用户”时发生的问题，操作如第4.1节所述。它表明，如果不引入一种机制，将服务用户的信息从S-CSCF传输到AS，这个用例是无法实现的。历史信息元素的使用并不能解决这个问题，因为它不能告诉as哪个用户正在被服务；它只是提供了一个转移的历史记录，这些转移甚至可能不是由服务于该特定用户的系统引起的。附录A中提供了关于为什么不能使用历史信息标题字段的更详细分析。
4.3. Diversion: Create New Originating Leg and Provide Originating iFC Processing
4.3. 改道：创建新的始发航段并提供始发iFC处理
Imagine a service scenario where a user B has a terminating service that diverts the call to a different destination. It is required that a forwarded call leg is handled as an originating call leg and that originating services for user B are executed. This means that this particular user has one or more iFC configured that are applicable for an outgoing initial request.
设想一个服务场景，其中用户B有一个将呼叫转移到不同目的地的终止服务。要求将转发的呼叫段作为发起呼叫段处理，并执行针对用户B的发起服务。这意味着该特定用户配置了一个或多个适用于传出初始请求的iFC。
When the S-CSCF receives an initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI.
当S-CSCF接收到初始INVITE请求时，它分析该请求并确定会话情况是针对终止注册用户的，然后通过查看请求URI将被服务用户确定为用户B。
Now the S-CSCF starts the iFC processing. The first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts user B's diversion service by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header. This allows the S-CSCF to correlate an INVITE coming from an AS over the ISC interface to the existing session that forwarded the INVITE to the AS in the first place.
现在，S-CSCF开始iFC处理。与INVITE请求匹配的第一个iFC通过将AS和s-CSCF自己的主机名添加到路由标头，使INVITE通过ISC接口转发到承载用户B的转接服务的AS。S-CSCF将原始对话标识符（ODI）添加到路由头上S-CSCF自己的主机名中。这允许S-CSCF通过ISC接口将来自AS的邀请与首先将邀请转发给AS的现有会话相关联。
When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Based on some criteria, the diversion service concludes that the request needs to be diverted to another user or application C. It does this by changing the Request-URI to C. Optionally, it records the Request-URI history by using the History-Info header field (RFC 4244 [7]). Then the AS removes itself from the Route header. To make sure that the request is handled as a new originating call on behalf of user B, the AS adds the "orig" parameter to the topmost route header. Then it routes the INVITE request back to the S-CSCF by using this topmost Route header field.
当AS接收到初始INVITE请求时，它分析该请求并确定会话情况是针对终止注册用户的，然后通过查看请求URI将服务用户确定为用户B。根据一些标准，转移服务得出结论，请求需要转移到另一个用户或应用程序C。它通过将请求URI更改为C来实现这一点。还可以选择使用历史信息头字段（RFC 4244[7]）记录请求URI历史。然后AS将自己从路由头中移除。为了确保请求作为代表用户B的新发起呼叫处理，as将“orig”参数添加到最顶端的路由报头。然后，它使用这个最上面的路由头字段将INVITE请求路由回S-CSCF。
When the S-CSCF receives the INVITE over the ISC interface, it can see that the topmost Route header contains its own hostname and an "orig" parameter. Because the topmost Route header contains the "orig" parameter, the S-CSCF concludes that the INVITE should be handled as if a call is originated by the served user. The served user is determined from the P-Asserted-Identity header to be user A. This is clearly wrong, as the user being served is and should be user B.
当S-CSCF通过ISC接口接收INVITE时，它可以看到最顶端的路由头包含自己的主机名和“orig”参数。因为最顶端的路由报头包含“orig”参数，所以S-CSCF得出结论，应该像处理由服务用户发起的呼叫一样处理邀请。从P-Asserted-Identity报头确定被服务的用户是用户A。这显然是错误的，因为被服务的用户是并且应该是用户B。
For the sake of discussion, let's assume that the S-CSCF can determine that the served user is user B. Then the procedure would continue as follows: The S-CSCF starts the originating iFC processing, the first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts an originating service of user B by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header.
为了便于讨论，让我们假设s-CSCF可以确定服务用户是用户B。然后该过程将继续如下：s-CSCF开始原始iFC处理，与INVITE请求匹配的第一个iFC通过将AS和S-CSCF自己的主机名添加到路由报头，使INVITE通过ISC接口转发到承载用户B的原始服务的AS。S-CSCF将原始对话标识符（ODI）添加到路由头上S-CSCF自己的主机名中。
The INVITE is forwarded to the AS that is associated with this particular iFC. When the AS receives the initial INVITE request, it analyzes the request and determines that the session case is for an originating registered user, then it determines the served user to be user A by looking at the P-Asserted-Identity. This is clearly wrong, as the user being served is and should be user B.
邀请将转发给与此特定iFC关联的AS。当AS接收到初始INVITE请求时，它分析该请求并确定会话情况是针对发起注册用户的，然后通过查看P-Asserted-Identity将被服务用户确定为用户A。这显然是错误的，因为被服务的用户是并且应该是用户B。
This scenario clearly shows the problem that occurs when the P-Asserted-Identity is overloaded with the meanings "call originator" and "served user" with the operation as described in Section 4.1. And it shows that this use case can not be realized without introducing a mechanism that conveys information about the served user from the S-CSCF to the AS and from the AS to the S-CSCF. Use of the History-Info element does not solve this problem as it does not tell the AS which user is being served, but just presents a history of diversions that might not be even caused by the systems serving this particular user. A more detailed analysis on why the History-Info header field can't be used is provided in Appendix A.
该场景清楚地显示了当P-Asserted-Identity在第4.1节中描述的操作中被含义“呼叫发起人”和“服务用户”重载时发生的问题。并且它表明，如果不引入一种机制，将关于服务用户的信息从S-CSCF传递到AS，并从AS传递到S-CSCF，则无法实现该用例。使用History Info元素并不能解决这个问题，因为它不能告诉as正在为哪个用户服务，而只是提供了一个转移的历史记录，这些转移甚至可能不是由为这个特定用户服务的系统引起的。附录A中提供了关于为什么不能使用历史信息标题字段的更详细分析。
4.4. Call Out of the Blue: on Behalf of User B, but Service Profile of Service Identity C
4.4. 突然呼叫：代表用户B，但服务标识C的服务配置文件
There are services that need to be able to initiate a call, whereby the call appears to be coming from a user B but the service profile on behalf of service identity C needs to be executed in the S-CSCF.
存在需要能够发起呼叫的服务，其中呼叫似乎来自用户B，但是代表服务标识C的服务配置文件需要在S-CSCF中执行。
When a call needs to appear as coming from user B, that means that the P-Asserted-Identity needs to contain B's identity. This is because the Originating Identity Presentation (OIP) service as defined in 3GPP TS 24.173 [10] uses the P-Asserted-Identity to present the call originator. This makes sense because that is the main meaning expressed by the P-Asserted-Identity header field.
当呼叫需要显示为来自用户B时，这意味着P-Asserted-Identity需要包含B的标识。这是因为3GPP TS 24.173[10]中定义的发起标识表示（OIP）服务使用P-Asserted-Identity来表示呼叫发起者。这是有意义的，因为这是P-Asserted-Identity头字段表示的主要含义。
It is clear that no INVITE request can be constructed currently that would achieve both requirements expressed in the first paragraph, because the P-Asserted-Identity is overloaded with two meanings on the ISC interface. When the S-CSCF will receive this request, it will determine that the served user is user B, which is not what we want to achieve.
很明显，目前无法构造任何INVITE请求来满足第一段中所述的两个要求，因为P-Asserted-Identity在ISC接口上重载了两种含义。当S-CSCF将接收到该请求时，它将确定所服务的用户是用户B，这不是我们想要实现的。
This section lists the requirements derived from the previous scenarios:
本节列出了从前面的场景派生的需求：
1. To be able to offer real-world application services, it is required that the identity of the served user can be conveyed on the ISC interface (see 3GPP TS 23.218 [8]).
1. 为了能够提供真实世界的应用服务，需要在ISC接口上传达被服务用户的身份（参见3GPP TS 23.218[8]）。
2. To be able to offer appropriate services to the served user, it is required that in addition to the served user identity the session case is conveyed.
2. 为了能够向被服务用户提供适当的服务，除了被服务用户身份之外，还需要传达会话情况。
This document defines the SIP P-Served-User P-header. This header field can be added to initial requests for a dialog or standalone requests, which are routed between nodes in a Trust Domain for P-Served-User. The P-Served-User P-header contains an identity of the user that represents the served user. The "sescase" parameter may be used to convey whether the initial request is originated by or destined for the served user. The "regstate" parameter may be used to indicate whether the initial request is for a registered or unregistered user.
本文档定义了SIP P-SERVERED-User P-header。此标头字段可以添加到对话的初始请求或独立请求中，这些请求在P-SERVERED-User信任域中的节点之间路由。P-Served-User P-header包含代表服务用户的用户标识。“sescase”参数可用于传达初始请求是由被服务用户发起还是目的地为被服务用户。“regstate”参数可用于指示初始请求是针对已注册用户还是未注册用户。
The augmented Backus-Naur Form (BNF) (RFC 5234 [6]) syntax of the P-Served-User header field is as follows:
P-SERVERED-User报头字段的扩充Backus Naur Form（BNF）（RFC 5234[6]）语法如下：
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"
registration-state-param = "regstate" EQUAL "unreg" / "reg"
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"
registration-state-param = "regstate" EQUAL "unreg" / "reg"
EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are defined in RFC 3261 [2].
EQUAL、HCOLON、SEMI、name addr、addr spec和generic param在RFC 3261[2]中定义。
The following is an example of a P-Served-User header field:
以下是P-SERVERED-User报头字段的示例：
P-Served-User: <sip:user@example.com>; sescase=orig; regstate=reg
P-Served-User: <sip:user@example.com>; sescase=orig; regstate=reg
Proxies that support the header MUST only insert the header in initial requests for a dialog or in standalone requests when the following conditions hold:
当以下条件成立时，支持标头的代理只能在对话框的初始请求或独立请求中插入标头：
o The proxy has the capability to determine the served user for the current request.
o 代理能够确定当前请求的服务用户。
o The next hop is part of the same Trust Domain for P-Served-User.
o 下一跳是P-Served-User的同一信任域的一部分。
When the above conditions do not hold, the proxy MUST NOT insert the header.
当上述条件不成立时，代理不得插入标头。
A proxy that supports the header MUST, upon receiving from a trusted node the P-Served-User header in initial requests for a dialog or in standalone requests, take the value of the P-Served-User header to represent the served user in operations that require such information.
支持标头的代理必须在从受信任节点接收到对话初始请求或独立请求中的P-SERVERED-User标头时，采用P-SERVERED-User标头的值来表示需要此类信息的操作中的服务用户。
A proxy that supports the header MUST remove the header from requests or responses when the header was received from a node outside the Trust Domain for P-Served-User before further forwarding the message.
当从P-SERVERED-User信任域之外的节点接收到标头时，支持标头的代理必须从请求或响应中删除标头，然后才能进一步转发消息。
A proxy that supports the header MUST remove the header from requests or responses when the next hop is a node outside the Trust Domain for P-Served-User before further forwarding the message.
当下一个跃点是P-SERVERED-User信任域之外的节点时，支持标头的代理必须从请求或响应中删除标头，然后才能进一步转发消息。
According to RFC 3427 [5], P-headers have a limited applicability. Specifications of P-headers, such as this RFC, need to clearly document the useful scope of the proposal and explain its limitations and why it is not suitable for the general use of SIP on the Internet.
根据RFC 3427[5]，P型封头的适用性有限。P-Header规范（如本RFC）需要清楚地记录提案的有用范围，并解释其局限性以及为什么不适合在Internet上普遍使用SIP。
The use of the P-Served-User header field extensions is only applicable inside a Trust Domain for served user. 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标头字段扩展的使用仅适用于受服务用户的信任域内。这种信任域中的节点明确地相互信任，以传递服务用户，并负责在信任域之外保留该信息。网络确定服务用户的方式以及为特定服务用户执行的策略不在本文档的范围内。
The served user information lacks an indication of who or what specifically determined the served user, and so it must be assumed that the Trust Domain determined the served user. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain.
服务用户信息缺乏关于谁或什么具体地确定了服务用户的指示，因此必须假设信任域确定了服务用户。因此，只有从已知为信任域成员的节点安全地接收信息时，信息才有意义。
Because the served user typically only has validity in one administrative domain, it is in general not suitable for inter-domain use or use in the Internet at large.
由于被服务用户通常仅在一个管理域中具有有效性，因此通常不适合域间使用或在因特网中广泛使用。
Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and that can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network like 3GPP IMS.
尽管存在这些限制，但仍有足够有用的专门部署满足上述假设，并且可以接受由此产生的限制，以保证该机制的信息发布。一个示例部署是类似3GPP IMS的封闭网络。
This document defines a new SIP header field: P-Served-User. This header field has been registered by the IANA in the SIP Parameters registry under the Header Fields subregistry.
本文档定义了一个新的SIP头字段：P-Served-User。IANA已在SIP参数注册表的header Fields子区下注册了此header field。
The P-Served-User header field defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physically protecting the network. In any case, the environment where the P-Served-User header field will be used ensures the integrity and the confidentiality of the contents of this header field.
本文档中定义的P-SERVERD-User标头字段将用于元素受信任且攻击者不应访问这些元素之间的协议消息的环境中。网元之间的流量保护有时通过使用IPsec实现，有时通过物理保护网络实现。在任何情况下，将使用P-Served-User头字段的环境都将确保该头字段内容的完整性和机密性。
The Spec(T) that defines the Trust Domain for P-Served-User MUST require that member nodes understand the P-Served-User header extension.
定义P-SERVERED-User信任域的规范（T）必须要求成员节点理解P-SERVERED-User头扩展。
There is a security risk if a P-Served-User header field is allowed to propagate out of the Trust Domain where it was generated. In that case, user-sensitive information would be revealed. To prevent such a breach from happening, proxies MUST NOT insert the header when forwarding requests to a hop that is located outside the Trust Domain. When forwarding the request to a node in the Trust Domain, proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another proxy in the Trust Domain that understands the header, such as the home proxy. There is no automatic mechanism to learn the support for this specification. Proxies MUST remove the header when forwarding requests to nodes that are not in the Trust Domain or when the proxy does not have knowledge of any other proxy included in the route set that will remove it before it is routed to any node that is not in the Trust Domain.
如果允许P-SERVERED-User头字段传播到生成它的信任域之外，则存在安全风险。在这种情况下，用户敏感信息将被泄露。为了防止这种破坏发生，代理在将请求转发到位于信任域之外的跃点时不得插入头。将请求转发到信任域中的节点时，除非代理充分了解路由集包括信任域中理解报头的另一个代理（如主代理），否则不得插入报头。没有自动机制来学习对该规范的支持。当将请求转发到不在信任域中的节点时，或者当代理不知道路由集中包含的任何其他代理将在其路由到不在信任域中的任何节点之前将其删除时，代理必须删除标头。
Alf Heidermark, Hubert Przybysz, and Erik Rolin for the discussion that led to the solution written down in this document. Spencer Dawkins for performing the expert review. Jon Peterson for performing the AD review. Gonzalo Camarillo, Paul Kyzivat, Nils Haenstroem, Arunachalam Venkatraman, Mikael Forsberg, Miguel Garcia, Jozsef Varga, Keith Drage, Tim Polk, and Cullen Jennings for providing improvements. Francis Dupont for performing the general area review. Sandy Murphy for performing the security area review.
Alf Heidermark、Hubert Przybysz和Erik Rolin进行了讨论，得出了本文中所述的解决方案。感谢斯宾塞·道金斯执行专家评审。乔恩·彼得森负责执行广告评论。冈萨洛·卡马里洛、保罗·基齐瓦特、尼尔斯·海恩斯特罗姆、阿鲁纳恰拉姆·文卡特拉曼、米凯尔·福斯堡、米格尔·加西亚、约瑟夫·瓦尔加、基思·德雷格、蒂姆·波尔克和卡伦·詹宁斯为改进提供了帮助。Francis Dupont负责执行一般区域审查。桑迪·墨菲负责执行安全区域审查。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[3] 沃森，M.，“网络断言身份的短期要求”，RFC 33242002年11月。
[4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[4] Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中用于断言身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[5] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[6] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[7] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[7] Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[8] 3GPP, "IP Multimedia (IM) session handling; IM call model; Stage 2", 3GPP TS 23.218 V7.
[8] 3GPP，“IP多媒体（IM）会话处理；IM呼叫模型；第2阶段”，3GPP TS 23.218 V7。
[9] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 V7.
[9] 3GPP，“IP多媒体子系统（IMS）；第2阶段”，3GPP TS 23.228 V7。
[10] 3GPP, "IMS multimedia telephony communication service and supplementary services; Stage 3", 3GPP TS 24.173 V7.
[10] 3GPP，“IMS多媒体电话通信业务和补充业务；第3阶段”，3GPP TS 24.173 V7。
[11] 3GPP, "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 V7.
[11] 3GPP，“基于会话发起协议（SIP）和会话描述协议（SDP）的互联网协议（IP）多媒体呼叫控制协议；第3阶段”，3GPP TS 24.229 V7。
[12] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 V7.
[12] 3GPP，“IP多媒体（IM）子系统Cx和Dx接口；信令流和消息内容”，3GPP TS 29.228 V7。
Appendix A. Why the History-Info Header Is Not Suitable to Convey the Served User Information on the ISC Interface
附录A.为什么历史信息标题不适合在ISC界面上传达所服务的用户信息
The History-Info (as specified in RFC 4244 [7]) holds a record of subsequent Request-URI values that are put on an initial request during its processing in the network.
历史信息（如RFC 4244[7]中所述）保存了后续请求URI值的记录，这些URI值在网络中处理初始请求期间被放在初始请求上。
If it would be possible at all to use the History-Info header for the purpose of communicating the served user, then again the same overloading would occur as the one that we are trying to get rid of (Section 4.2). In this case, we overload the particular History-Info header field's hi-entry with the meaning "historic target identity" and "served user".
如果可以使用历史信息头与服务用户通信，那么同样会出现我们试图消除的过载（第4.2节）。在这种情况下，我们用“历史目标标识”和“服务用户”来重载特定历史信息标题字段的hi条目。
Another reason that the History-Info header can not solve the requirements as expressed in this document is that, in originating session case scenarios, the served user is currently determined from the P-Asserted-Identity, as that header field contains the asserted originating user's identity. The History-Info header, being a record of Request-URIs, can never be a solution for this case.
历史信息报头无法解决本文档中表达的需求的另一个原因是，在发起会话案例场景中，当前根据P-Asserted-Identity确定服务用户，因为报头字段包含断言的发起用户的标识。历史信息头作为请求URI的记录，永远不能成为这种情况的解决方案。
Looking at the call-out-of-the-blue scenario (Section 4.4), it is impossible to construct a History-Info header for an INVITE request on behalf of user C that appears to come from user B and targets user D that would express the served user C without violating the original semantics of the History-Info header according to (RFC 4244 [7]).
查看蓝色调用场景（第4.4节），不可能为代表用户C的INVITE请求构造历史信息报头，该请求似乎来自用户B，目标用户D将表示服务用户C，而不会违反历史信息报头的原始语义，根据（RFC 4244[7]）。
The purpose of the History-Info header is a header that has an end-to-end application. For the purpose of informing an AS on the ISC interface, this is overkill.
历史信息标头的用途是具有端到端应用程序的标头。为了在ISC接口上通知AS，这是过分的。
At the moment that the AS receives an initial INVITE over the ISC interface, this INVITE may have passed a vast number of proxies that may or may not have added history information. On top of that, the request may have traversed several AS instances for the same served user. In case several subsequent iFC are active, all these AS instances may perform a forwarding. This means that it is not possible to define an algorithm that points out which hi-entry of a History-Info header should represent the served user. In other words, a History-Info header field with n entries expresses a branch of depth n. Any or none of these elements could be the served user identity.
当AS通过ISC接口接收到初始邀请时，此邀请可能传递了大量代理，这些代理可能添加了历史信息，也可能没有添加历史信息。最重要的是，对于同一个服务用户，请求可能已经遍历了多个AS实例。如果几个后续iFC处于活动状态，则所有这些AS实例都可以执行转发。这意味着不可能定义一个算法来指出历史信息头的哪个hi条目应该代表服务用户。换句话说，具有n个条目的历史信息头字段表示深度n的分支。这些元素中的任何一个或任何一个都不能是服务用户标识。
The History-Info header does not comply with the second requirement as expressed in Section 5, as it does not have a means to express the session case in a natural way.
历史信息标题不符合第5节中的第二个要求，因为它没有以自然方式表达会话案例的方法。
Each observation in the previous subsections, alone, is enough to disregard the History-Info header as an information element that is suitable for transporting the served user information over the ISC interface.
仅前面小节中的每个观察就足以忽略历史信息报头，将其作为适合通过ISC接口传输服务用户信息的信息元素。
Note that this does not prohibit the use of the P-Served-User header and the History-Info header in the same request. In fact that will be a quite likely scenario for network-based diversion services like, for example, the Communication Diversion service as specified in (3GPP TS 24.173 [10]).
注意，这并不禁止在同一请求中使用P-Served-User报头和History-Info报头。事实上，对于基于网络的转移服务，例如（3GPP TS 24.173[10]）中指定的通信转移服务，这将是一个非常可能的场景。
Author's Address
作者地址
Hans Erik van Elburg Ericsson Telecommunicatie B.V. Ericssonstraat 2 Rijen 5121 ML Netherlands
Hans Erik van Elburg Ericsson Telecommunicatie B.V.Ericssonstraat 2 Rijen 5121 ML荷兰
EMail: HansErik.van.Elburg@ericsson.com
EMail: HansErik.van.Elburg@ericsson.com