Internet Engineering Task Force (IETF) R. Jesske
Request for Comments: 7315 Deutsche Telekom
Obsoletes: 3455 K. Drage
Category: Informational Alcatel-Lucent
ISSN: 2070-1721 C. Holmberg
Ericsson
July 2014
Internet Engineering Task Force (IETF) R. Jesske
Request for Comments: 7315 Deutsche Telekom
Obsoletes: 3455 K. Drage
Category: Informational Alcatel-Lucent
ISSN: 2070-1721 C. Holmberg
Ericsson
July 2014
Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP
针对3GPP的会话发起协议（SIP）的专用报头（P-Header）扩展
Abstract
摘要
This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.
本文档描述了3GPP使用的一组私有报头（P-header）会话发起协议（SIP）字段及其适用性，这些字段仅限于特定环境。P-header字段用于合作伙伴实施的网络中的各种目的，包括计费和关于呼叫所经过网络的信息。本文件淘汰RFC 3455。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7315.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7315.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overall Applicability ...........................................3
2. Conventions .....................................................3
3. Overview ........................................................3
4. SIP Private Header Fields .......................................4
4.1. The P-Associated-URI Header Field ..........................4
4.1.1. Applicability Statement for the
P-Associated-URI Header Field .......................5
4.1.2. Usage of the P-Associated-URI Header Field ..........5
4.2. The P-Called-Party-ID Header Field .........................6
4.2.1. Applicability Statement for the
P-Called-Party-ID Header Field .....................10
4.2.2. Usage of the P-Called-Party-ID Header Field ........11
4.3. The P-Visited-Network-ID Header Field .....................12
4.3.1. Applicability Statement for the
P-Visited-Network-ID Header Field ..................12
4.3.2. Usage of the P-Visited-Network-ID Header Field .....13
4.4. The P-Access-Network-Info Header Field ....................17
4.4.1. Applicability Statement for the
P-Access-Network-Info Header Field .................18
4.4.2. Usage of the P-Access-Network-Info Header ..........18
4.5. The P-Charging-Function-Addresses Header Field ............19
4.5.1. Applicability Statement for the
P-Charging-Function-Addresses Header Field .........20
4.5.2. Usage of the P-Charging-Function-Addresses
Header Field .......................................21
4.6. The P-Charging-Vector Header Field ........................23
4.6.1. Applicability Statement for the
P-Charging-Vector Header Field .....................25
4.6.2. Usage of the P-Charging-Vector Header Field ........25
4.6.3. Usage of the transit-ioi ...........................27
4.6.4. Usage of the related-icid ..........................28
1. Overall Applicability ...........................................3
2. Conventions .....................................................3
3. Overview ........................................................3
4. SIP Private Header Fields .......................................4
4.1. The P-Associated-URI Header Field ..........................4
4.1.1. Applicability Statement for the
P-Associated-URI Header Field .......................5
4.1.2. Usage of the P-Associated-URI Header Field ..........5
4.2. The P-Called-Party-ID Header Field .........................6
4.2.1. Applicability Statement for the
P-Called-Party-ID Header Field .....................10
4.2.2. Usage of the P-Called-Party-ID Header Field ........11
4.3. The P-Visited-Network-ID Header Field .....................12
4.3.1. Applicability Statement for the
P-Visited-Network-ID Header Field ..................12
4.3.2. Usage of the P-Visited-Network-ID Header Field .....13
4.4. The P-Access-Network-Info Header Field ....................17
4.4.1. Applicability Statement for the
P-Access-Network-Info Header Field .................18
4.4.2. Usage of the P-Access-Network-Info Header ..........18
4.5. The P-Charging-Function-Addresses Header Field ............19
4.5.1. Applicability Statement for the
P-Charging-Function-Addresses Header Field .........20
4.5.2. Usage of the P-Charging-Function-Addresses
Header Field .......................................21
4.6. The P-Charging-Vector Header Field ........................23
4.6.1. Applicability Statement for the
P-Charging-Vector Header Field .....................25
4.6.2. Usage of the P-Charging-Vector Header Field ........25
4.6.3. Usage of the transit-ioi ...........................27
4.6.4. Usage of the related-icid ..........................28
5. Formal Syntax ..................................................28
5.1. P-Associated-URI Header Syntax ............................29
5.2. P-Called-Party-ID Header Syntax ...........................29
5.3. P-Visited-Network-ID Header Syntax ........................29
5.4. P-Access-Network-Info Header Syntax .......................29
5.5. P-Charging-Function-Addresses Header Syntax ...............31
5.6. P-Charging-Vector Header Syntax ...........................32
5.7. New Headers ...............................................33
6. Security Considerations ........................................33
6.1. P-Associated-URI Header Field .............................33
6.2. P-Called-Party-ID Header Field ............................34
6.3. P-Visited-Network-ID Header Field .........................34
6.4. P-Access-Network-Info Header Field ........................35
6.5. P-Charging-Function-Addresses Header Field ................36
6.6. P-Charging-Vector Header Field ............................36
7. IANA Considerations ............................................37
8. Contributors and Acknowledgements ..............................38
9. References .....................................................39
9.1. Normative References ......................................39
9.2. Informative References ....................................39
Appendix A. Changes from RFC 3455 .................................41
5. Formal Syntax ..................................................28
5.1. P-Associated-URI Header Syntax ............................29
5.2. P-Called-Party-ID Header Syntax ...........................29
5.3. P-Visited-Network-ID Header Syntax ........................29
5.4. P-Access-Network-Info Header Syntax .......................29
5.5. P-Charging-Function-Addresses Header Syntax ...............31
5.6. P-Charging-Vector Header Syntax ...........................32
5.7. New Headers ...............................................33
6. Security Considerations ........................................33
6.1. P-Associated-URI Header Field .............................33
6.2. P-Called-Party-ID Header Field ............................34
6.3. P-Visited-Network-ID Header Field .........................34
6.4. P-Access-Network-Info Header Field ........................35
6.5. P-Charging-Function-Addresses Header Field ................36
6.6. P-Charging-Vector Header Field ............................36
7. IANA Considerations ............................................37
8. Contributors and Acknowledgements ..............................38
9. References .....................................................39
9.1. Normative References ......................................39
9.2. Informative References ....................................39
Appendix A. Changes from RFC 3455 .................................41
The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions apply only to private networks and are not appropriate for use in an Internet environment. The mechanisms specified here were designed to satisfy the requirements specified in the 3GPP Release 5 requirements on SIP [RFC4083] for which either no general-purpose solution was planned (where insufficient operational experience was available to understand if a general solution would be needed) or for which a more general solution is not yet mature. For more details about the assumptions made about these extensions, consult the Applicability subsection for each extension.
本文档中指定的SIP扩展对网络拓扑、SIP和较低层之间的链接以及可传递信任的可用性做出了某些假设。这些假设仅适用于专用网络，不适合在Internet环境中使用。此处规定的机制旨在满足3GPP第5版SIP[RFC4083]要求中规定的要求，该要求要么没有规划通用解决方案（没有足够的操作经验来理解是否需要通用解决方案）或者一个更普遍的解决方案尚未成熟。有关这些扩展的假设的更多详细信息，请参阅每个扩展的适用性小节。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The 3GPP uses SIP as the protocol to establish and tear down multimedia sessions in the context of its IP Multimedia Subsystem (IMS), as described in the 3GPP TS 23.228 [TS23.228] and 3GPP TS
3GPP使用SIP作为协议，在其IP多媒体子系统（IMS）的上下文中建立和中断多媒体会话，如3GPP TS 23.228[TS23.228]和3GPP TS中所述
24.229 [TS24.229]. RFC 3455 [RFC3455] defines SIP private header extensions (referred to as P-headers) that are required by the 3GPP specification. Note that the requirements for these extensions are documented in RFC 4083 [RFC4083]. This document obsoletes RFC 3455 [RFC3455]. This document updates existing P-header descriptions to address additional requirements that are needed for 3GPP Release 11. Each of the P-headers is described in the sections below.
24.229[TS24.229]。RFC 3455[RFC3455]定义了3GPP规范所需的SIP专用报头扩展（称为P报头）。注意，RFC 4083[RFC4083]中记录了这些扩展的要求。本文件淘汰了RFC 3455[RFC3455]。本文档更新现有的P-header描述，以解决3GPP版本11所需的其他需求。以下各节介绍了每个P-Header。
This extension allows a registrar to return a set of associated URIs for a registered SIP address-of-record. We define the P-Associated-URI header field, used in the 200 (OK) response to a REGISTER request. The P-Associated-URI header field contains the set of associated URIs that are associated with the registered address-of-record.
此扩展允许注册器为已注册的SIP记录地址返回一组关联的URI。我们定义P-Associated-URI头字段，用于对寄存器请求的200（OK）响应。P-Associated-URI头字段包含与记录的注册地址关联的关联URI集。
In addition to the address-of-record, an associated URI is a URI that the service provider has allocated to a user. A registrar contains information that allows zero or more URIs to be associated with an address-of-record. Usually, all these URIs (the address-of-record and the associated URIs) are allocated for the usage of a particular user. This extension to SIP allows the User Agent Client (UAC) to know, upon a successful authenticated registration, which other URIs, if any, the service provider has associated with an address-of-record URI.
除了记录地址之外，相关联的URI是服务提供者分配给用户的URI。注册器包含允许零个或多个URI与记录地址关联的信息。通常，所有这些URI（记录地址和关联的URI）都分配给特定用户使用。SIP的此扩展允许用户代理客户端（UAC）在成功进行身份验证注册后，知道服务提供商已将哪些其他URI（如果有的话）与记录URI的地址关联。
Note that, in standard SIP usage [RFC3261], the registrar does not register the associated URIs on behalf of the user. Only the address-of-record that is present in the To header field of the REGISTER is registered and bound to the contact address. The only information conveyed is that the registrar is aware of other URIs that can be used by the same user.
注意，在标准SIP用法[RFC3261]中，注册器不代表用户注册关联的URI。只有寄存器的To头字段中存在的记录地址被注册并绑定到联系人地址。所传达的唯一信息是注册器知道同一用户可以使用的其他URI。
A situation may be possible, however, in which an application server (or even the registrar itself) registers any of the associated URIs on behalf of the user by means of a third-party registration. However, this third-party registration is out of the scope of this document. A UAC MUST NOT assume that the associated URIs are registered.
然而，可能存在这样一种情况，即应用服务器（甚至注册器本身）通过第三方注册来代表用户注册任何关联uri。但是，此第三方注册不在本文件范围内。UAC不得假定关联的URI已注册。
If a UAC wants to check whether any of the associated URIs is registered, it can do so by mechanisms specified outside this document, e.g., the UA MAY send a REGISTER request with the To header field value set to any of the associated URIs and without a Contact header field. The 200 (OK) response will include a Contact header
如果UAC想要检查是否注册了任何关联的URI，它可以通过本文档之外指定的机制进行检查，例如，UA可以向任何关联的URI发送一个注册请求，该请求的to头字段值设置为任何关联的URI，并且没有联系人头字段。200（正常）响应将包括一个联系人标题
field with the list of addresses-of-record that have been registered with contact addresses. If the associated URI is not registered, the UA MAY register it prior to its utilization.
字段，其中包含已使用联系人地址注册的记录地址列表。如果相关联的URI没有注册，UA可以在其使用之前注册它。
The P-Associated-URI header field is applicable in SIP networks where the SIP provider allows a set of identities that a user can claim (in header fields like the From header field) in requests that the UA generates. Furthermore, it assumes that the provider knows the entire set of identities that a user can legitimately claim and that the user is willing to restrict its claimed identities to that set. This is in contrast to normal SIP usage, where the From header field is explicitly an end-user-specified field.
P-Associated-URI报头字段适用于SIP网络，其中SIP提供者允许用户在UA生成的请求中声明一组标识（在报头字段中，如From报头字段中）。此外，它假设提供者知道用户可以合法声明的整个身份集，并且用户愿意将其声明的身份限制在该集。这与正常的SIP用法不同，在正常的SIP用法中，From头字段显式地是最终用户指定的字段。
The registrar inserts the P-Associated-URI header field into the 200 (OK) response to a REGISTER request. The header field value is populated with a list of URIs that are associated to the address-of-record.
注册器将P-Associated-URI头字段插入到对注册请求的200（OK）响应中。标头字段值由与记录地址关联的URI列表填充。
If the registrar supports the P-Associated-URI header field extension and there is at least one associated URI, then the registrar MUST insert the P-Associated-URI header field in all the 200 (OK) responses to a REGISTER request. The absence of a P-Associated-URI header field indicates that there are no associated URIs for the registered address-of-record.
如果注册器支持P-Associated-URI头字段扩展，并且至少有一个相关联的URI，那么注册器必须在对注册请求的所有200（OK）响应中插入P-Associated-URI头字段。缺少P-Associated-URI头字段表示记录的注册地址没有关联的URI。
A UAC may receive a P-Associated-URI header field in the 200 (OK) response for a REGISTER request. The presence of a header field in the 200 (OK) response for a REGISTER request implies that the extension is supported at the registrar.
UAC可以在针对寄存器请求的200（OK）响应中接收P关联URI报头字段。在注册请求的200（OK）响应中存在头字段意味着注册器支持扩展。
The header field value contains a list of one or more associated URIs to the address-of-record. The UAC MAY use any of the associated URIs to populate the From header field value, or any other SIP header field value that provides information of the identity of the calling party, in a subsequent request.
标头字段值包含记录地址的一个或多个关联URI的列表。UAC可以在后续请求中使用任何相关联的URI来填充From报头字段值，或者填充提供呼叫方身份信息的任何其他SIP报头字段值。
The UAC MAY check whether or not the associated URI is registered. This check can be done, e.g., by populating the To header field value in a REGISTER request sent to the registrar and without a Contact header field. The 200 (OK) response will include a Contact header field with the list of address-of-record that have been registered
UAC可以检查关联的URI是否已注册。例如，可以通过在发送给注册器的注册请求中填充To头字段值来完成该检查，而不需要联系人头字段。200（确定）响应将包括一个联系人标题字段，其中包含已注册的记录地址列表
with contact addresses. As described in SIP [RFC3261], the 200 (OK) response may contain a Contact header field with zero or more values (zero meaning the address-of-record is not registered).
有联系地址。如SIP[RFC3261]中所述，200（OK）响应可能包含一个具有零或多个值的联系人标头字段（零表示记录地址未注册）。
A registrar that receives and authorizes a REGISTER request MAY associate zero or more URIs with the registered address-of-record.
接收并授权注册请求的注册人可将零个或多个URI与注册记录地址关联。
If the address-of-record under registration does not have any associated URIs, the P-Associated-URI header field SHALL NOT be included.
如果正在注册的记录地址没有任何关联的URI，则不应包括P-associated-URI头字段。
Otherwise, a registrar that supports this specification MUST include a P-Associated-URI header field in the 200 (OK) response to a REGISTER request that contains a contact header. The header field MUST be populated with a comma-separated list of URIs that are associated to the address-of-record under registration.
否则，支持此规范的注册器必须在对包含联系人标头的注册请求的200（OK）响应中包含P-Associated-URI标头字段。标头字段必须填充一个逗号分隔的URI列表，这些URI与注册中记录的地址关联。
This header is not intended to be used by proxies -- a proxy does not add, read, modify, or delete the header field; therefore, any proxy MUST relay this header field unchanged.
此标头不供代理使用--代理不会添加、读取、修改或删除标头字段；因此，任何代理都必须不更改地中继此标头字段。
A proxy server inserts a P-Called-Party-ID header field, typically in an INVITE request, en route to its destination. The header is populated with the Request-URI received by the proxy in the request. The User Agent Server (UAS) identifies to which address-of-record, out of several registered addresses-of-record, the invitation was sent (for example, the user may be simultaneously using one personal SIP URI and one business SIP URI to receive invitation to sessions). The UAS can use the information to render different distinctive audiovisual alerting tones, depending on the URI used to receive the invitation to the session.
代理服务器通常在一个INVITE请求中插入一个P-Call-Party-ID头字段，该字段在发送到目的地的途中。标头由请求中的代理接收的请求URI填充。用户代理服务器（UAS）识别在多个注册的记录地址中向哪个记录地址发送了邀请（例如，用户可以同时使用一个个人SIP URI和一个业务SIP URI来接收会话邀请）。UAS可以根据用于接收会话邀请的URI，使用该信息呈现不同的独特视听警报音。
Users in the 3GPP IP Multimedia Subsystem (IMS) may get one or several SIP URIs (address-of-record) to identify the user. For example, a user may get one business SIP URI and one personal SIP URI. As an example of utilization, the user may make available the business SIP URI to coworkers and may make available the personal SIP URI to members of the family.
3GPP IP多媒体子系统（IMS）中的用户可以获得一个或多个SIP uri（记录地址）来识别用户。例如，用户可以获得一个业务SIP URI和一个个人SIP URI。作为利用的示例，用户可以向同事提供业务SIP URI，并且可以向家庭成员提供个人SIP URI。
At a certain point in time, both the business SIP URI and the personal SIP URI are registered in the SIP registrar, so both URIs can receive invitations to new sessions. When the user receives an invitation to join a session, he/she should be aware of which of the registered SIP URIs this session was sent to.
在某个时间点，业务SIPURI和个人SIPURI都在SIP注册器中注册，因此这两个URI都可以接收新会话的邀请。当用户收到加入会话的邀请时，他/她应该知道该会话发送到哪个已注册的SIPURI。
This requirement is stated in the 3GPP Release 5 requirements on SIP [RFC4083].
该要求在SIP[RFC4083]的3GPP第5版要求中有说明。
The problem arises during the terminating side of a session establishment. At that time, the SIP proxy that is serving a UA gets an INVITE request, and the SIP server retargets the SIP URI that is present in the Request-URI, and replaces that SIP URI with the SIP URI published by the user in the Contact header field of the REGISTER request at registration time.
问题出现在会话建立的终止端。此时，服务于UA的SIP代理获得INVITE请求，并且SIP服务器重新定位请求URI中存在的SIP URI，并用用户在注册时在注册请求的联系人报头字段中发布的SIP URI替换该SIP URI。
One can argue that the To header field conveys the semantics of the called user, and therefore, this extension to SIP is not needed. Although the To header field in SIP may convey the called party ID in most situations, there are two particular cases when the above assumption is not correct:
可以说To header字段传达了被调用用户的语义，因此不需要对SIP进行此扩展。尽管在大多数情况下，SIP中的To报头字段可能会传递被叫方ID，但当上述假设不正确时，有两种特殊情况：
1. The session has been forwarded, redirected, etc., by previous SIP proxies, before arriving to the proxy that is serving the called user.
1. 在到达为被叫用户服务的代理之前，会话已被先前的SIP代理转发、重定向等。
2. The UAC builds an INVITE request and the To header field is not the same as the Request-URI.
2. UAC构建一个INVITE请求，并且To头字段与请求URI不同。
The problem of using the To header field is that this field is populated by the UAC and not modified by proxies in the path. If the UAC, for any reason, did not populate the To header field with the address-of-record of the destination user, then the destination user is not able to distinguish to which address-of-record the session was destined.
使用To header字段的问题在于，该字段由UAC填充，而不是由路径中的代理修改。如果UAC出于任何原因未将目标用户的记录地址填充到“收件人”标题字段，则目标用户无法区分会话的目的地址。
Another possible solution to the problem is built upon the differentiation of the Contact header field value between different address-of-record at registration time. The UA can differentiate each address-of-record it registers by assigning a different Contact header field value. For example, when the UA registers the address-of-record sip:id1, the Contact header field value can be sip:id1@ua, while the registration of the address-of-record sip:id2 can be bound to the Contact header field value sip:id2@ua.
该问题的另一个可能解决方案是在注册时区分不同记录地址之间的联系人标头字段值。UA可以通过分配不同的联系人标头字段值来区分其注册的每个记录地址。例如，当UA注册记录sip:id1的地址时，联系人头字段值可以是sip:id1@ua，而记录sip:id2的地址注册可以绑定到联系人标头字段值sip:id2@ua.
The solution described above assumes that the UA explicitly registers each of its addresses-of-record, and therefore, it has full control over the contact address values assigned to each registration.
上述解决方案假设UA显式注册其记录的每个地址，因此，UA完全控制分配给每个注册的联系人地址值。
However, if the UA does not have full control of its registered addresses-of-record, because of, e.g., a third-party registration, the solution does not work. This may be the case of the 3GPP registration, where the UA may have previously indicated to the network, by means outside of SIP, that some other addresses-of-record may be automatically registered when the UA registers a particular address-of-record. The requirement is covered in the 3GPP Release 5 requirements on SIP [RFC4083].
但是，如果UA由于第三方注册等原因无法完全控制其注册的记录地址，则解决方案不起作用。这可能是3GPP注册的情况，其中UA先前可能已经通过SIP之外的方式向网络指示，当UA注册特定的记录地址时，可以自动注册一些其他记录地址。SIP[RFC4083]上的3GPP第5版要求涵盖了该要求。
In the next paragraphs, we show an example of the problem, in the case in which there has been some sort of call forwarding in the session, so that the UAC is not aware of the intended destination URI in the current INVITE request.
在接下来的段落中，我们将展示一个问题示例，在这种情况下，会话中存在某种呼叫转发，因此UAC不知道当前INVITE请求中的预期目标URI。
We assume that a UA is registering to its proxy (P1).
我们假设UA正在向其代理（P1）注册。
Scenario UA --- P1
Scenario UA --- P1
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
The user also registers his personal URI to his/her registrar.
用户还向其注册者注册其个人URI。
F2 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1827 REGISTER
Contact: <sip:user1@192.0.2.4>
F2 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1827 REGISTER
Contact: <sip:user1@192.0.2.4>
Later, the proxy/registrar (P1) receives an INVITE request from another proxy (P2) destined to the user's business SIP address-of-record. We assume that this INVITE request has undergone some sort of forwarding in the past, and as such, the To header field is not populated with the SIP URI of the user. In this case, we assume that the session was initially addressed to sip:other-user@othernetwork.com. The SIP server at othernetwork.com has forwarded this session to sip:user1-business@example.com.
稍后，代理/注册器（P1）从目的地为用户的业务SIP记录地址的另一代理（P2）接收邀请请求。我们假设这个INVITE请求在过去经历过某种转发，因此，To头字段没有填充用户的SIPURI。在本例中，我们假设会话最初是指向sip:other的-user@othernetwork.com. othernetwork.com上的SIP服务器已将此会话转发给SIP:user1-business@example.com.
Scenario UA --- P1 --- P2
Scenario UA --- P1 --- P2
F3 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F3 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
The proxy P1 retargets the user and replaces the Request-URI with the SIP URI published during registration time in the Contact header field value.
代理P1重定用户的目标，并将请求URI替换为联系人标头字段值中注册期间发布的SIP URI。
F4 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F4 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
When the UAS receives the INVITE request, it cannot determine whether it got the session invitation due to his registration of the business or the personal address-of-record. Neither the UAS nor proxies / application servers can provide this user a service based on the destination address-of-record of the session.
当UAS收到邀请请求时，它无法确定是否由于其业务注册或个人记录地址而收到了会话邀请。UAS和代理/应用服务器都不能基于会话记录的目标地址向该用户提供服务。
We solve this problem by allowing the proxy that is responsible for the home domain (as defined in SIP) of the user to insert a P-Called-Party-ID header field that identifies the address-of-record to which this session is destined.
我们通过允许负责用户的主域（如SIP中定义的）的代理插入一个P-Call-Party-ID头字段来解决这个问题，该头字段标识该会话的目标记录地址。
If this SIP extension is used, the proxy serving the called user will get the message flow F5, it will populate the P-Called-Party-ID header field in message flow F6 with the contents of the Request-URI in F4. This is show in flows F5 and F6 below:
如果使用此SIP扩展，为被叫用户服务的代理将获得消息流F5，它将用F4中请求URI的内容填充消息流F6中的P-called-Party-ID头字段。这在下面的流F5和F6中显示：
F5 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F5 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F6 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
P-Called-Party-ID: <sip:user1-business@example.com>
CSeq: 101 INVITE
F6 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
P-Called-Party-ID: <sip:user1-business@example.com>
CSeq: 101 INVITE
When the UA receives the INVITE request F6, it can determine the intended address-of-record of the session and apply whatever service is needed for that address-of-record.
当UA收到INVITE请求F6时，它可以确定会话的预期记录地址，并为该记录地址应用所需的任何服务。
The P-Called-Party-ID header field is applicable when the UAS needs to be aware of the intended address-of-record that was present in the Request-URI of the request, before the proxy retargets to the contact address. The UAS may be interested in applying different audiovisual alerting effects or other filtering services, depending on the intended destination of the request. It is especially valuable when the UAS has registered several addresses-of-record to his registrar, and therefore, the UAS is not aware of the address-of-record that was present in the INVITE request when it hit his proxy/registrar, unless this extension is used.
当UAS需要在代理重新定位到联系人地址之前知道请求的请求URI中存在的预期记录地址时，P-Called-Party-ID头字段适用。UAS可能对应用不同的视听警报效果或其他过滤服务感兴趣，这取决于请求的预期目的地。当UAS已向其注册官注册了多个记录地址时，这一点尤其重要，因此，除非使用此扩展名，否则UAS不知道INVITE请求中出现的记录地址。
P-Called-Party-ID header field and the History-Info header field: At the time RFC 3455 [RFC3455] was written, the History-Info header field was a long way from specification. This header has now been specified and approved in RFC 7044 [RFC7044]. It is acknowledged that the History-Info header field will provide equivalent coverage to that of the P-Called-Party-ID header field. However, the P-Called-Party-ID header field is used entirely within the 3GPP system and does not appear to SIP entities outside that of a single 3GPP operator.
P-Called-Party-ID头字段和历史信息头字段：在编写RFC 3455[RFC3455]时，历史信息头字段与规范相差甚远。该标题现已在RFC 7044[RFC7044]中指定和批准。众所周知，历史信息标题字段将提供与P-Party-ID标题字段相同的覆盖范围。然而，P-Called-Party-ID报头字段完全在3GPP系统内使用，并且对于单个3GPP运营商之外的SIP实体来说似乎不存在。
The P-Called-Party-ID header field provides proxies and the UAS with the address-of-record that was present in the Request-URI of the request, before a proxy retargets the request. This information is intended to be used by subsequent proxies in the path or by the UAS.
P-Called-Party-ID头字段在代理重新定位请求之前，向代理和UAS提供请求的请求URI中存在的记录地址。此信息旨在供路径中的后续代理或UAS使用。
Typically, a SIP proxy inserts the P-Called-Party-ID header field prior to retargetting the Request-URI in the SIP request. The header field value is populated with the contents of the Request-URI, prior to replacing it with the contact address.
通常，SIP代理在SIP请求中重新定位请求URI之前插入P-Call-Party-ID头字段。在用联系人地址替换请求URI之前，先用请求URI的内容填充标头字段值。
A UAC MUST NOT insert a P-Called-Party-ID header field in any SIP request or response.
UAC不得在任何SIP请求或响应中插入P-Called-Party-ID头字段。
A UAS may receive a SIP request that contains a P-Called-Party-ID header field. The header field will be populated with the address-of-record received by the proxy in the Request-URI of the request, prior to its forwarding to the UAS.
UAS可以接收包含P-Call-Party-ID头字段的SIP请求。在将请求转发到UAS之前，将使用代理在请求的请求URI中接收到的记录地址填充头字段。
The UAS MAY use the value in the P-Called-Party-ID header field to provide services based on the called party URI, such as, e.g., filtering of calls depending on the date and time, distinctive presentation services, distinctive alerting tones, etc.
UAS可以使用P被叫方ID报头字段中的值来提供基于被叫方URI的服务，例如，根据日期和时间过滤呼叫、独特的呈现服务、独特的警报音等。
A proxy that has access to the contact information of the user can insert a P-Called-Party-ID header field in any of the requests indicated in Section 5.7. When included, the proxy MUST populate the header field value with the contents of the Request-URI present in the SIP request that the proxy received.
有权访问用户联系信息的代理可以在第5.7节所述的任何请求中插入P-Call-Party-ID头字段。包含时，代理必须使用代理收到的SIP请求中存在的请求URI的内容填充标头字段值。
It is necessary that the proxy that inserts the P-Called-Party-ID header field has information about the user, in order to prevent a wrong delivery of the called party ID. This information may, for example, have been learned through a registration process.
插入P-Call-Party-ID头字段的代理必须具有有关用户的信息，以防止错误传递被叫方ID。例如，该信息可能是通过注册过程获得的。
A proxy or application server that receives a request containing a P-Called-Party-ID header field MAY use the contents of the header field to provide a service to the user based on the URI of that header field value.
接收包含P-call-Party-ID报头字段的请求的代理服务器或应用服务器可以使用报头字段的内容基于该报头字段值的URI向用户提供服务。
A SIP proxy MUST NOT insert a P-Called-Party-ID header field in REGISTER requests.
SIP代理不能在注册请求中插入P-Call-Party-ID头字段。
3GPP networks are composed of a collection of so-called home networks, visited networks, and subscribers. A particular home network may have roaming agreements with one or more visited networks. The effect of this is that when a mobile terminal is roaming, it can use resources provided by the visited network in a transparent fashion.
3GPP网络由所谓的家庭网络、访问网络和订户的集合组成。特定家庭网络可以与一个或多个访问的网络签订漫游协议。其效果是，当移动终端漫游时，它可以以透明的方式使用被访问网络提供的资源。
One of the conditions for a home network to accept the registration of a UA roaming to a particular visited network, is the existence of a roaming agreement between the home and the visited network. There is a need to indicate to the home network which network is the visited network that is providing services to the roaming UA.
家庭网络接受向特定到访网络漫游的UA的注册的条件之一是家庭和到访网络之间存在漫游协议。需要向归属网络指示哪个网络是向漫游UA提供服务的被访问网络。
3GPP user agents always register to the home network. The REGISTER request is proxied by one or more proxies located in the visited network towards the home network. For the sake of a simple approach, it seems sensible that the visited network includes an identification that is known to the home network. This identification should be globally unique, and it takes the form of a quoted-text string or a token. The home network may use this identification to verify the existence of a roaming agreement with the visited network, and to authorize the registration through that visited network.
3GPP用户代理始终注册到家庭网络。注册请求由位于到访网络中朝向家庭网络的一个或多个代理来代理。为了简单的方法，访问的网络包括家庭网络已知的标识似乎是明智的。此标识应该是全局唯一的，并且采用带引号的文本字符串或标记的形式。归属网络可使用该标识来验证与到访网络的漫游协议的存在，并通过该到访网络授权注册。
Note that P-Visited-Network-ID information reveals the location of the user, to the level of the coverage area of the visited network. For a national network, for example, P-Visited-Network-ID would reveal that the user is in the country in question.
请注意，P-visted-Network-ID信息根据访问网络的覆盖区域级别显示用户的位置。例如，对于一个国家网络，P-visted-network-ID将显示用户所在国家。
4.3.1. Applicability Statement for the P-Visited-Network-ID Header Field
4.3.1. P-VISTER-Network-ID头字段的适用性声明
The P-Visited-Network-ID header field is applicable whenever the following circumstances are met:
只要满足以下条件，P-VISTER-Network-ID标头字段就适用：
1. There is transitive trust in intermediate proxies between the UA and the home network proxy via established relationships between the home network and the visited network, supported by the use of standard security mechanisms, e.g., IPsec, Authentication and Key Agreement (AKA), or Transport Layer Security (TLS).
1. UA和家庭网络代理之间通过家庭网络和访问网络之间建立的关系存在中间代理中的可传递信任，该关系由标准安全机制（例如，IPsec、身份验证和密钥协议（AKA）或传输层安全（TLS））的使用支持。
2. An endpoint is using resources provided by one or more visited networks (a network to which the user does not have a direct business relationship).
2. 端点正在使用一个或多个已访问网络（用户与之没有直接业务关系的网络）提供的资源。
3. A proxy that is located in one of the visited networks wants to be identified at the user's home network.
3. 位于其中一个访问网络中的代理希望在用户的家庭网络上进行标识。
4. There is no requirement that every visited network need be identified at the home network. Those networks that want to be identified make use of this extension. Those networks that do not want to be identified do nothing.
4. 不需要在家庭网络中标识每个访问的网络。那些想要被识别的网络利用这个扩展。那些不想被识别的网络什么也不做。
5. A commonly pre-agreed text string or token identifies the visited network at the home network.
5. 通常预先约定的文本字符串或令牌标识家庭网络中的访问网络。
6. The UAC sends a REGISTER request or dialog-initiating request (e.g., INVITE request) or a standalone request outside a dialog (e.g., OPTIONS request) to a proxy in a visited network.
6. UAC向访问网络中的代理发送注册请求或对话框启动请求（例如，邀请请求）或对话框外部的独立请求（例如，选项请求）。
7. The request traverses, en route to its destination, a first proxy located in the visited network and a second proxy located in the home network or its destination is the registrar in the home network.
7. 请求在到达其目的地的途中穿过位于被访问网络中的第一代理和位于家庭网络中的第二代理，或者其目的地是家庭网络中的注册器。
8. The registrar or home proxy verifies and authorizes the usage of resources (e.g., proxies) in the visited network.
8. 注册器或归属代理验证并授权访问网络中资源（例如代理）的使用。
The P-Visited-Network-ID header field assumes that there is trust relationship between a home network and one or more transited visited networks. It is possible for other proxies between the proxy in the visited network that inserts the header, and the registrar or the home proxy, to modify the value of P-Visited-Network-ID header field. Therefore, intermediaries participating in this mechanism MUST apply a hop-by-hop integrity-protection mechanism such as IPsec or other available mechanisms in order to prevent such attacks.
P-visted-Network-ID报头字段假定家庭网络和一个或多个转机访问的网络之间存在信任关系。在插入报头的到访网络中的代理和注册者或归属代理之间的其他代理可以修改P-visted-network-ID报头字段的值。因此，参与此机制的中介体必须应用逐跳完整性保护机制，如IPsec或其他可用机制，以防止此类攻击。
The P-Visited-Network-ID header field is used to convey to the registrar or home proxy in the home network the identifier of a visited network. The identifier is a text string or token that is known by both the registrar or the home proxy at the home network and the proxies in the visited network.
P-visted-Network-ID报头字段用于将到访网络的标识符传递给家庭网络中的注册器或家庭代理。标识符是一个文本字符串或令牌，家庭网络中的注册者或家庭代理以及到访网络中的代理都知道该文本字符串或令牌。
Typically, the home network authorizes the UA to roam to a particular visited network. This action requires an existing roaming agreement between the home and the visited network.
通常，归属网络授权UA漫游到特定的访问网络。此操作需要家庭和访问网络之间的现有漫游协议。
While it is possible for a home network to identify one or more visited networks by inspecting the domain name in the Via header fields, this approach has a heavy dependency on DNS. It is an option for a proxy to populate the Via header field with an IP address, for example, and in the absence of a reverse DNS entry, the IP address will not convey the desired information.
虽然家庭网络可以通过检查Via报头字段中的域名来识别一个或多个访问的网络，但这种方法对DNS有很大的依赖性。例如，代理可以选择使用IP地址填充Via标头字段，并且在没有反向DNS条目的情况下，IP地址将不会传递所需的信息。
Any SIP proxy in the visited network that receives any of the requests indicated in Section 5.7 MAY insert a P-Visited-Network-ID header field when it forwards the request. In case a REGISTER request or other request is traversing different administrative domains (e.g., different visited networks), a SIP proxy MAY insert a new P-Visited-Network-ID header field if the request does not contain a P-Visited-Network-ID header field with the same network identifier as its own network identifier (e.g., if the request has traversed other different administrative domains).
受访网络中接收第5.7节所述任何请求的任何SIP代理在转发请求时可插入P-VISTER-network-ID头字段。如果注册请求或其他请求正在穿越不同的管理域（例如，不同的访问网络），则如果请求不包含具有与其自身网络标识符相同的网络标识符的P-visted-Network-ID报头字段，则SIP代理可以插入新的P-visted-Network-ID报头字段（例如，如果请求已穿越其他不同的管理域）。
Note also that, there is no requirement for this header field value to be readable in the proxies. Therefore, a first proxy MAY insert an encrypted header field that only the registrar can decrypt. If the request traverses a second proxy located in the same administrative domain as the first proxy, the second proxy may not be able to read the contents of the P-Visited-Network-ID header field. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header field, and therefore, it will insert a new P-Visited-Network-ID header field value (hopefully with the same identifier that the first proxy inserted, although perhaps, not encrypted). When the request arrives at the registrar or proxy in the home network, it will notice that the header field value is repeated (both the first and the second proxy inserted it). The decrypted values should be the same, because both proxies where part of the same administrative domain. While this situation is not desirable, it does not create any harm at the registrar or proxy in the home network.
还要注意的是，不要求该头字段值在代理中可读。因此，第一代理可以插入只有注册器才能解密的加密报头字段。如果请求遍历与第一个代理位于同一管理域中的第二个代理，则第二个代理可能无法读取P-visted-Network-ID报头字段的内容。在这种情况下，第二代理将考虑其访问的网络标识符在标头字段的值中不存在，因此，它将插入一个新的P- VisualNETWork-ID头字段值（希望与第一代理插入的标识符相同，尽管可能未加密）。当请求到达家庭网络中的注册器或代理时，它将注意到报头字段值被重复（第一个和第二个代理都将其插入）。解密的值应该相同，因为两个代理都属于同一管理域。虽然这种情况不可取，但不会对家庭网络中的注册器或代理造成任何损害。
The P-Visited-Network-ID header field is normally used at registration. However, this extension does not preclude other usages. For example, a proxy located in a visited network that does not maintain registration state MAY insert a P-Visited-Network-ID header field into any standalone request outside a dialog or a request that creates a dialog. At the time of writing this document, the only requests that create dialogs are INVITE requests [RFC3261], SUBSCRIBE requests [RFC6665], and REFER requests [RFC3515].
P-visted-Network-ID头字段通常在注册时使用。但是，此扩展并不排除其他用途。例如，位于已访问网络中且不保持注册状态的代理可以将P-visted-network-ID头字段插入到对话框外部的任何独立请求或创建对话框的请求中。在编写本文档时，创建对话框的请求只有INVITE请求[RFC3261]、SUBSCRIBE请求[RFC6665]和REFER请求[RFC3515]。
In order to avoid conflicts with identifiers, especially when the number of roaming agreements between networks increase, care must be taken when selecting the value of the P-Visited-Network-ID header field. The identifier MUST be globally unique to avoid duplications. Although there are many mechanisms to create globally unique identifiers across networks, one such mechanism is already in operation, and that is DNS. The P-Visited-Network-ID header field does not have any connection to DNS, but the values in the header field can be chosen from the DNS entry representing the domain name of the network. This guarantees the uniqueness of the value.
为了避免与标识符冲突，特别是当网络之间的漫游协议数量增加时，在选择P-visted-Network-ID报头字段的值时必须小心。标识符必须是全局唯一的，以避免重复。尽管有许多机制可以跨网络创建全局唯一标识符，但其中一种机制已经在运行，即DNS。P-visted-Network-ID标头字段与DNS没有任何连接，但标头字段中的值可以从表示网络域名的DNS条目中选择。这保证了值的唯一性。
In the context of the network to which the header fields defined in this document apply, a User Agent has no knowledge of the P-Visited-Network-ID when sending the REGISTER request. Therefore, UACs MUST NOT insert a P-Visited-Network-ID header field in any SIP message.
在本文档中定义的头字段适用的网络上下文中，用户代理在发送注册请求时不知道P-visted-network-ID。因此，UACs不得在任何SIP消息中插入P-visted-Network-ID头字段。
A SIP proxy that is located in a visited network MAY insert a P-Visited-Network-ID header field in any of the requests indicated in Section 5.7. The header field MUST be populated with the contents of a text string or a token that identifies the administrative domain of the network where the proxy is operating towards the user's home network.
位于到访网络中的SIP代理可以在第5.7节中指示的任何请求中插入P-visted-network-ID头字段。标头字段必须填充文本字符串或令牌的内容，该文本字符串或令牌标识代理正在向用户家庭网络操作的网络的管理域。
A SIP proxy or registrar which is located in the home network can use the contents of the P-Visited-Network-ID header field as an identifier of one or more visited networks that the request traversed. The proxy or registrar in the home network may take local-policy-driven actions based on the existence (or nonexistence) of a roaming agreement between the home and the visited networks. This means, for instance, the authorization of the actions of the request is based on the contents of the P-Visited-Network-ID header field.
位于家庭网络中的SIP代理或注册器可以使用P-visted-network-ID报头字段的内容作为请求所穿越的一个或多个已访问网络的标识符。归属网络中的代理或注册器可以基于归属网络和到访网络之间存在（或不存在）漫游协议而采取本地策略驱动的动作。这意味着，例如，请求操作的授权基于P-visted-Network-ID报头字段的内容。
A SIP proxy that is located in the home network MUST delete this header field when forwarding the message outside the home network administrative domain, in order to retain the user's privacy.
当在家庭网络管理域之外转发消息时，位于家庭网络中的SIP代理必须删除此标头字段，以保留用户的隐私。
A SIP proxy that is located in the home network SHOULD delete this header field when the home proxy has used the contents of the header field or the request is routed based on the called party's identification, even when the request is not forwarded outside the home network administrative domain.
当家庭代理使用了报头字段的内容，或者根据被叫方的标识路由请求时，即使请求未转发到家庭网络管理域之外，位于家庭网络中的SIP代理也应删除该报头字段。
Note that a received P-Visited-Network-ID from a UA is not allowed and MUST be deleted when the request is forwarded.
请注意，不允许从UA接收到P-VISTER-Network-ID，并且在转发请求时必须将其删除。
We present an example in the context of the scenario shown in the following network diagram:
我们在以下网络图所示场景的上下文中提供了一个示例：
Scenario UA --- P1 --- P2 --- REGISTRAR
Scenario UA --- P1 --- P2 --- REGISTRAR
This example shows the message sequence for a REGISTER transaction originating from UA eventually arriving at the REGISTRAR. P1 is an outbound proxy in the visited network for UA. In this case, P1 inserts the P-Visited-Network-ID header field. Then, P1 routes the REGISTER request to REGISTRAR via P2.
此示例显示了源自UA并最终到达注册器的注册事务的消息序列。P1是UA访问网络中的出站代理。在这种情况下，P1插入P-visted-Network-ID报头字段。然后，P1经由P2将注册请求路由到注册器。
Message sequence for REGISTER using P-Visited-Network-ID header field:
使用P-VISTER-Network-ID头字段的寄存器的消息序列：
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
F1 Register UA -> P1
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:user1-business@example.com
From: sip:user1-business@example.com;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
In flow F2, proxy P1 adds its own identifier in a quoted string to the P-Visited-Network-ID header field.
在流F2中，代理P1在带引号的字符串中将自己的标识符添加到P-visted-Network-ID头字段中。
F2 Register P1 -> P2
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP p1@visited.net;branch=z9hG4bK203igld
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashd8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
P-Visited-Network-ID: "Visited network number 1"
F2 Register P1 -> P2
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP p1@visited.net;branch=z9hG4bK203igld
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashd8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
P-Visited-Network-ID: "Visited network number 1"
Finally, in flow F3, proxy P2 decides to insert its own identifier, derived from its own domain name to the P-Visited-Network-ID header field.
最后，在流F3中，代理P2决定将其自己的标识符（从其自己的域名派生）插入到P-visted-Network-ID报头字段中。
F3 Register P2 -> REGISTRAR
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP p2@other.net;branch=z9hG4bK2bndnvk
Via: SIP/2.0/UDP p1@visited.net;branch=z9hG4bK203igld
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashd8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
P-Visited-Network-ID: other.net,"Visited network number 1"
F3 Register P2 -> REGISTRAR
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP p2@other.net;branch=z9hG4bK2bndnvk
Via: SIP/2.0/UDP p1@visited.net;branch=z9hG4bK203igld
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashd8
To: sip:user1-personal@example.com
From: sip:user1-personal@example.com;tag=346249
Call-ID: 2Q3817637684230998sdasdh10
CSeq: 1826 REGISTER
Contact: <sip:user1@192.0.2.4>
P-Visited-Network-ID: other.net,"Visited network number 1"
This section describes the P-Access-Network-Info header field. This header field is useful in SIP-based networks that also provide Layer 2 (L2) / Layer 3 (L3) connectivity through different access technologies. SIP UAs may use this header field to relay information about the access technology to proxies that are providing services. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP UA may use this header field to pass information about the access network such as radio access technology and radio cell identity to its home service provider.
本节介绍P-Access-Network-Info标题字段。此标头字段在基于SIP的网络中非常有用，这些网络还通过不同的接入技术提供第2层（L2）/第3层（L3）连接。SIP UAs可以使用该报头字段将关于接入技术的信息中继到提供服务的代理。然后，服务代理可以使用该信息来优化UA的服务。例如，3GPP UA可以使用该报头字段向其家庭服务提供商传递关于接入网络的信息，例如无线接入技术和无线小区标识。
For the purpose of this extension, we define an access network as the network providing the L2/L3 IP connectivity, which, in turn, provides a user with access to the SIP capabilities and services provided.
出于此扩展的目的，我们将接入网络定义为提供L2/L3 IP连接的网络，该网络反过来为用户提供对所提供SIP功能和服务的访问。
In some cases, the SIP server that provides the user with services may wish to know information about the type of access network that the UA is currently using. Some services are more suitable or less suitable depending on the access type, and some services are of more value to subscribers if the access network details are known by the SIP proxy that provides the user with services.
在某些情况下，向用户提供服务的SIP服务器可能希望知道关于UA当前使用的接入网络类型的信息。根据接入类型，一些服务更适合或更不适合，并且如果向用户提供服务的SIP代理知道接入网络细节，则一些服务对订阅者更有价值。
In other cases, the SIP server that provides the user with services may simply wish to know crude location information in order to provide certain services to the user. For example, many of the location-based services available in wireless networks today require the home network to know the identity of the cell the user is being served by.
在其他情况下，向用户提供服务的SIP服务器可能仅仅希望知道粗略的位置信息，以便向用户提供某些服务。例如，当今无线网络中可用的许多基于位置的服务要求家庭网络知道用户所服务的小区的身份。
Some regulatory requirements exist mandating that for cellular radio systems, the identity of the cell where an emergency call is established is made available to the emergency authorities.
一些监管要求规定，对于蜂窝无线电系统，建立紧急呼叫的蜂窝的身份可提供给应急机构。
The SIP server that provides services to the user may desire to have knowledge about the access network. This is achieved by defining a new private SIP extension header field, P-Access-Network-Info header field. This header field carries information relating to the access network between the UAC and its serving proxy in the home network.
向用户提供服务的SIP服务器可能希望了解接入网络。这是通过定义一个新的私有SIP扩展头字段P-Access-Network-Info头字段来实现的。该报头字段携带与UAC及其在家庭网络中的服务代理之间的接入网络相关的信息。
A proxy providing services based on the P-Access-Network-Info header field must consider the trust relationship to the UA or outbound proxy including the P-Access-Network-Info header field.
基于P Access NETWORK-FIN报头字段提供代理的代理必须考虑到UA或出站代理的信任关系，包括P Access NETWORK-FIN报头字段。
4.4.1. Applicability Statement for the P-Access-Network-Info Header Field
4.4.1. P-Access-Network-Info标题字段的适用性声明
This mechanism is appropriate in environments where SIP services are dependent on SIP elements knowing details about the IP and lower-layer technologies used by a UA to connect to the SIP network. Specifically, the extension requires that the UA know the access technology it is using, and that a proxy desires such information to provide services. Generally, SIP is built on the everything over IP and IP over everything principle, where the access technology is not relevant for the operation of SIP. Since SIP systems generally should not care or even know about the access technology, this SIP extension is not for general SIP usage.
这种机制适用于SIP服务依赖于SIP元素的环境，SIP元素了解UA连接到SIP网络所使用的IP和较低层技术的详细信息。具体而言，该扩展要求UA了解其使用的接入技术，并且代理希望此类信息提供服务。通常，SIP基于IP上的一切和IP上的一切原则，其中接入技术与SIP的操作无关。由于SIP系统通常不应该关心甚至不知道接入技术，因此此SIP扩展不适用于一般的SIP使用。
The information revealed in the P-Access-Network-Info header field is potentially very sensitive. Proper protection of this information depends on the existence of specific business and security relationships amongst the proxies that will see SIP messages containing this header field. It also depends on explicit knowledge of the UA of the existence of those relationships. Therefore, this mechanism is only suitable in environments where the appropriate relationships are in place, and the UA has explicit knowledge that they exist.
P-Access-Network-Info报头字段中显示的信息可能非常敏感。此信息的适当保护取决于代理之间是否存在特定的业务和安全关系，代理将看到包含此标头字段的SIP消息。它还取决于UA对这些关系存在的明确认识。因此，该机制仅适用于具有适当关系的环境，且UA明确知道这些关系的存在。
When a UA generates a SIP request or response that it knows is going to be securely sent to its SIP proxy that is providing services, the UA inserts a P-Access-Network-Info header field into field the SIP message. This header contains information on the access network that the UA is using to get IP connectivity. The header is typically ignored by intermediate proxies between the UA and the SIP proxy that is providing services. The proxy providing services can inspect the header and make use of the information contained there to provide appropriate services, depending on the value of the header. Before proxying the request onwards to an untrusted administrative network domain, this proxy strips the header from the message.
当UA生成一个SIP请求或响应时，它知道该请求或响应将被安全地发送到其提供服务的SIP代理，UA会在SIP消息的字段中插入一个P-Access-Network-Info头字段。此标头包含UA用于获取IP连接的接入网络信息。UA和提供服务的SIP代理之间的中间代理通常会忽略报头。提供服务的代理可以检查报头，并根据报头的值利用其中包含的信息提供适当的服务。在将请求代理到不受信任的管理网络域之前，此代理会从消息中删除标头。
Additionally, the first outbound proxy, if in possession of appropriate information, can also add a P-Access-Network-Info header field with its own information.
此外，第一个出站代理如果拥有适当的信息，还可以添加一个P-Access-Network-Info头字段，其中包含自己的信息。
A UA that supports this extension and is willing to disclose the related parameters MAY insert the P-Access-Network-Info header field in any SIP request or response.
支持该扩展并且愿意公开相关参数的UA可以在任何SIP请求或响应中插入P-Access-Network-Info报头字段。
The UA inserting this information MUST have a trust relationship with the proxy that is providing services to protect its privacy by deleting the header before forwarding the message outside of the proxy's domain. This proxy is typically located in the home network.
插入此信息的UA必须与提供服务的代理建立信任关系，以通过在将消息转发到代理的域之外之前删除标头来保护其隐私。此代理通常位于家庭网络中。
In order to avoid the deletion of the header, there MUST also be a transitive trust in intermediate proxies between the UA and the proxy that provides the services. This trust is established by business agreements between the home network and the access network, and generally supported by the use of standard security mechanisms, e.g., IPsec, AKA, and TLS.
为了避免删除头，UA和提供服务的代理之间的中间代理中还必须存在可传递的信任。该信任由家庭网络和接入网络之间的业务协议建立，并且通常由标准安全机制（例如，IPsec、AKA和TLS）的使用来支持。
A proxy MUST NOT modify the value of the P-Access-Network-Info header field.
代理不得修改P-Access-Network-Info标头字段的值。
A proxy in possession of appropriate information about the access technology MAY insert a P-Access-Network-Info header field with its own values. A proxy sending towards an untrusted entity MUST remove any P-Access-Network-Info header field containing a "network-provided" value.
拥有关于接入技术的适当信息的代理可以插入具有其自身值的P-access-Network-Info报头字段。向不受信任的实体发送的代理必须删除包含“网络提供”值的任何P-Access-Network-Info标头字段。
A proxy that is providing services to the UA, can act upon any information present in the P-Access-Network-Info header field value, if is present, to provide a different service depending on the network or the location through which the UA is accessing the server. For example, for cellular radio access networks, the SIP proxy located in the home network MAY use the cell ID to provide basic localized services.
向UA提供服务的代理可以根据P-Access-Network-Info标头字段值中存在的任何信息（如果存在）来提供不同的服务，具体取决于UA访问服务器的网络或位置。例如，对于蜂窝无线电接入网络，位于家庭网络中的SIP代理可以使用小区ID来提供基本的本地化服务。
A proxy that provides services to the user is typically located in the home network and is therefore trusted. It MUST delete the header when the SIP signaling is forwarded to a SIP server located in an untrusted administrative network domain. The SIP server providing services to the UA uses the access network information that is of no interest to other proxies located in different administrative domains.
向用户提供服务的代理通常位于家庭网络中，因此是可信的。当SIP信令转发到位于不受信任的管理网络域中的SIP服务器时，它必须删除报头。向UA提供服务的SIP服务器使用位于不同管理域中的其他代理不感兴趣的接入网络信息。
3GPP has defined a distributed architecture that results in multiple network entities becoming involved in providing access and services. There is a need to inform each SIP proxy involved in a transaction about the common charging functional entities to receive the generated charging records or charging events.
3GPP定义了一种分布式体系结构，使得多个网络实体参与提供接入和服务。需要将公共计费功能实体告知交易中涉及的每个SIP代理，以接收生成的计费记录或计费事件。
The solution provided by 3GPP is to define two types of charging functional entities: Charging Collection Function (CCF) and Event Charging Function (ECF). CCF is used for offline charging (e.g., for postpaid account charging). ECF is used for online charging (e.g., for pre-paid account charging). There may be more than a single instance of CCF and ECF in a network, in order to provide redundancy in the network. In case there are more than a single instance of either the CCF or the ECF addresses, implementations SHOULD attempt sending the charging data to the ECF or CCF address, starting with the first address of the sequence (if any) in the P-Charging-Function-Addresses header field. If the first address of the sequence is not available, then the next address (ccf-2 or ecf-2) MUST be used if available. The CCF and ECF addresses MAY be passed during the establishment of a dialog or in a standalone transaction. More detailed information about charging can be found in 3GPP TS 32.240 [TS32.240] and 3GPP TS 32.260 [TS32.260].
3GPP提供的解决方案是定义两种类型的计费功能实体：计费收集功能（CCF）和事件计费功能（ECF）。CCF用于离线收费（例如，用于支付后账户收费）。ECF用于在线收费（例如，预付费账户收费）。为了在网络中提供冗余，网络中可能有多个CCF和ECF实例。如果CCF或ECF地址存在多个实例，则实施应尝试将计费数据发送到ECF或CCF地址，从P-charging-Function-addresses标头字段中序列的第一个地址（如果有）开始。如果序列的第一个地址不可用，则必须使用下一个地址（ccf-2或ecf-2）（如果可用）。CCF和ECF地址可以在建立对话框期间或在独立事务中传递。有关充电的更多详细信息，请参见3GPP TS 32.240[TS32.240]和3GPP TS 32.260[TS32.260]。
We define the SIP private header field P-Charging-Function-Addresses header field. A proxy MAY include this header field, if not already present, in either the initial request or response for a dialog or in the request and response of a standalone transaction outside a dialog. When present, only one instance of the header MUST be present in a particular request or response.
我们定义了SIP私有报头字段P-Charging-Function-Addresses报头字段。代理可以在对话框的初始请求或响应中，或者在对话框外部的独立事务的请求和响应中包含此标头字段（如果尚未存在）。当存在时，特定请求或响应中只能存在一个标头实例。
The mechanisms by which a SIP proxy collects the values to populate the P-Charging-Function-Addresses header field values are outside the scope of this document. However, as an example, a SIP proxy may have preconfigured these addresses or may obtain them from a subscriber database.
SIP代理收集值以填充P-Charging-Function-Addresses标头字段值的机制不在本文档的范围内。然而，作为示例，SIP代理可以预先配置这些地址，或者可以从订户数据库获取这些地址。
4.5.1. Applicability Statement for the P-Charging-Function-Addresses Header Field
4.5.1. P-Charging-Function-Addresses标头字段的适用性声明
The P-Charging-Function-Addresses header field is applicable within a single private administrative domain where coordination of charging is required, for example, according to the architecture specified in 3GPP TS 32.240 [TS32.240].
P-Charging-Function-Addresses报头字段适用于需要协调计费的单个私有管理域，例如，根据3GPP TS 32.240[TS32.240]中指定的架构。
The P-Charging-Function-Addresses header field is not included in a SIP message sent outside of the own administrative domain. The header is not applicable if the administrative domain does not provide a charging function.
P-Charging-Function-Addresses标头字段不包括在自己的管理域之外发送的SIP消息中。如果管理域不提供计费功能，则标头不适用。
The P-Charging-Function-Addresses header field is applicable whenever the following circumstances are met:
只要满足以下条件，P-Charging-Function-Addresses标头字段就适用：
1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE request) or a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UA向位于专用网络管理域中的代理发送寄存器或对话框启动请求（例如，邀请请求）或对话框外部的独立事务请求。
2. A registrar, proxy, or UA that is located in the administrative domain of the private network wants to generate charging records.
2. 位于专用网络管理域中的注册商、代理或UA希望生成计费记录。
3. A registrar, proxy, or UA that is located in the private network has access to the addresses of the charging function entities for that network.
3. 位于专用网络中的注册器、代理或UA可以访问该网络的计费功能实体的地址。
4. There are other proxies that are located in the same administrative domain of the private network and that generate charging records or charging events. The proxies want to send, by means outside SIP, the charging information to the same charging collecting entities than the first proxy.
4. 其他代理位于专用网络的同一管理域中，并生成计费记录或计费事件。代理希望通过SIP之外的方式将计费信息发送到与第一个代理不同的计费收集实体。
A SIP proxy that receives a SIP request MAY insert a P-Charging-Function-Addresses header field prior to forwarding the request, if the header was not already present in the SIP request. The header filed contains one or more parameters that contain the hostnames or IP addresses of the nodes that are willing to receive charging information.
接收SIP请求的SIP代理可以在转发请求之前插入P-Charging-Function-Addresses报头字段，前提是该报头尚未出现在SIP请求中。标头字段包含一个或多个参数，其中包含愿意接收计费信息的节点的主机名或IP地址。
A SIP proxy that receives a SIP request that includes a P-Charging-Function-Addresses header field can use the hostnames or IP addresses included in the value, as the destination of charging information or charging events. The means to send those charging information or events are outside the scope of this document, and usually, do not use SIP for that purpose.
接收包含P-Charging-Function-Addresses标头字段的SIP请求的SIP代理可以使用该值中包含的主机名或IP地址作为计费信息或计费事件的目标。发送这些收费信息或事件的方式不在本文档的范围内，通常不使用SIP。
This document does not specify any procedure at the UA located outside the administrative domain of a private network, with regard to the P-Charging-Function-Addresses header field. Such UAs need not understand this header.
本文件未规定位于专用网络管理域之外的UA上关于P-Charging-Function-Addresses报头字段的任何程序。此类UAs不需要理解此标头。
However, it might be possible that a UA is located within the administrative domain of a private network (e.g., a Public Switched Telephone Network (PSTN) gateway, or conference mixer), and it may have access to the addresses of the charging entities. In this case,
然而，UA可能位于专用网络（例如，公共交换电话网（PSTN）网关或会议混频器）的管理域内，并且它可能可以访问计费实体的地址。在这种情况下,，
a UA MAY insert the P-Charging-Function-Addresses header field in a SIP request or response when the next hop for the message is a proxy or UA located in the same administrative domain. Similarly, such a UA MAY use the contents of the P-Charging-Function-Addresses header field in communicating with the charging entities.
当消息的下一跳是位于同一管理域中的代理或UA时，UA可以在SIP请求或响应中插入P-Charging-Function-Addresses报头字段。类似地，这样的UA可以在与计费实体通信时使用P-Charging-Function-Addresses报头字段的内容。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Function-Addresses header field MAY insert a P-Charging-Function-Addresses header field prior to forwarding the message. The header is populated with a list of the addresses of one or more charging entities where the proxy should send charging-related information.
支持此扩展并接收不带P-Charging-Function-Addresses报头字段的请求或响应的SIP代理可以在转发消息之前插入P-Charging-Function-Addresses报头字段。标头由一个或多个收费实体的地址列表填充，代理应在其中发送收费相关信息。
If a proxy that supports this extension receives a request or response with the P-Charging-Function-Addresses header field, it MAY retrieve the information from the header field to use with application-specific logic, i.e., charging. If the next hop for the message is within the administrative domain of the proxy, then the proxy SHOULD include the P-Charging-Function-Addresses header field in the outbound message. However, if the next hop for the message is outside the administrative domain of the proxy, then the proxy MUST remove the P-Charging-Function-Addresses header field.
如果支持此扩展的代理接收到带有P-Charging-Function-Addresses标头字段的请求或响应，则它可以从标头字段检索信息，以用于特定于应用程序的逻辑，即计费。如果消息的下一个跃点位于代理的管理域内，则代理应在出站消息中包含P-Charging-Function-Addresses标头字段。但是，如果消息的下一个跃点位于代理的管理域之外，则代理必须删除P-Charging-Function-Addresses标头字段。
We present an example in the context of the scenario shown in the following network diagram:
我们在以下网络图所示场景的上下文中提供了一个示例：
Scenario UA1 --- P1 --- P2 --- UA2
Scenario UA1 --- P1 --- P2 --- UA2
In this scenario, we assume that P1 and P2 belong to the same administrative domain.
在这个场景中，我们假设P1和P2属于同一个管理域。
The example below shows the message sequence for an INVITE transaction originating from UA1 and eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case, P1 inserts charging information. Then, P1 routes the request via P2 to UA2.
下面的示例显示了源自UA1并最终到达UA2的INVITE事务的消息序列。P1是UA1的出站代理。在这种情况下，P1插入充电信息。然后，P1通过P2将请求路由到UA2。
Message sequence for INVITE using P-Charging-Function-Addresses header field:
使用P-Charging-Function-Addresses标头字段的INVITE的消息序列：
F1 Invite UA1 -> P1
INVITE sip:ua2@home1.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:ua2@home1.net
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
F1 Invite UA1 -> P1
INVITE sip:ua2@home1.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:ua2@home1.net
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
F2 Invite P1 -> P2
INVITE sip:ua2@home1.net SIP/2.0
Via: SIP/2.0/UDP p1@home1.net:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:ua2@home1.net
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Function-Addresses:
ccf=192.0.8.1; ecf=192.0.8.3,
ccf-2=192.0.8.2; ecf-2=192.0.8.4
F2 Invite P1 -> P2
INVITE sip:ua2@home1.net SIP/2.0
Via: SIP/2.0/UDP p1@home1.net:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:ua2@home1.net
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Function-Addresses:
ccf=192.0.8.1; ecf=192.0.8.3,
ccf-2=192.0.8.2; ecf-2=192.0.8.4
Now both P1 and P2 are aware of the IP addresses of the entities that collect charging record or charging events. Both proxies can send the charging information to the same entities.
现在P1和P2都知道收集充电记录或充电事件的实体的IP地址。两个代理都可以向相同的实体发送收费信息。
3GPP has defined a distributed architecture that results in multiple network entities becoming involved in providing access and services. Operators need the ability and flexibility to charge for the access and services as they see fit. This requires coordination among the network entities (e.g., SIP proxies), which includes correlating charging records generated from different entities that are related to the same session.
3GPP定义了一种分布式体系结构，使得多个网络实体参与提供接入和服务。运营商需要在他们认为合适的情况下对接入和服务收费的能力和灵活性。这需要网络实体（例如，SIP代理）之间的协调，这包括关联从与同一会话相关的不同实体生成的计费记录。
The correlation information includes, but is not limited to, a globally unique charging identifier that makes the billing effort easy.
相关信息包括但不限于使计费工作容易的全球唯一计费标识符。
A charging vector is defined as a collection of charging information. The charging vector MAY be filled in during the establishment of a dialog or standalone transaction outside a dialog. The information inside the charging vector MAY be filled in by multiple network entities (including SIP proxies) and retrieved by multiple network
充电向量定义为充电信息的集合。收费向量可以在建立对话框或对话框外部的独立事务期间填写。计费向量内的信息可由多个网络实体（包括SIP代理）填充并由多个网络实体检索
entities. There are three types of correlation information to be transferred: the IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value, and the Inter Operator Identifier (IOI).
实体。有三种类型的相关信息需要传输：IMS计费标识（ICID）值、创建ICID值的SIP代理的地址和操作员间标识符（IOI）。
ICID is a charging value that identifies a dialog or a transaction outside a dialog. It is used to correlate charging records. ICID MUST be a globally unique value. One way to achieve globally uniqueness is to generate the ICID using two components: a locally unique value and the hostname or IP address of the SIP proxy that generated the locally unique value.
ICID是一个收费值，用于标识对话或对话外的交易。它用于关联充电记录。ICID必须是全局唯一的值。实现全局唯一性的一种方法是使用两个组件生成ICID：本地唯一值和生成本地唯一值的SIP代理的主机名或IP地址。
The IOI identifies both the originating and terminating networks involved in a SIP dialog or transaction outside a dialog. There MAY be an IOI generated from each side of the dialog to identify the network associated with each side.
IOI标识SIP对话或对话外部事务中涉及的发起和终止网络。可能会从对话框的每一侧生成一个IOI，以标识与每一侧关联的网络。
Additionally, in a multi-network environment, one or more transit IOI identifiers MAY be included along the path of the SIP dialog or transaction outside a dialog. Due to network policy, a void value MAY be included instead of the transit network name. The void value is used to indicate that a transit network appeared but due to operator policy the network name is not shown.
另外，在多网络环境中，一个或多个传输IOI标识符可沿SIP对话或对话外部的事务的路径包括。由于网络策略，可能会包含一个void值，而不是公交网络名称。void值用于指示出现了公交网络，但由于运营商的政策，网络名称未显示。
Furthermore, in a multi-service provider environment, one or more transit IOIs MAY be included along the path of the SIP dialog or transaction outside a dialog. Due to service provider policy, a void value MAY be included instead of the transit service provider. The void value is used to indicate that a transit appeared but due to service provider policy the service provider name is not shown.
此外，在多服务提供商环境中，一个或多个传输ioi可沿SIP对话框的路径或对话框外部的事务包括。根据服务提供商的政策，可能会包含无效值，而不是公交服务提供商。void值用于指示出现了传输，但由于服务提供商策略，未显示服务提供商名称。
There is also expected to be access network charging information, which consists of network-specific identifiers for the access level (e.g., Universal Mobile Telecommunications System (UMTS) radio access network or IEEE 802.11b). The details of the information for each type of network are not described in this memo.
预计还将存在接入网络计费信息，该信息包括接入级别的网络特定标识符（例如，通用移动通信系统（UMTS）无线接入网络或IEEE 802.11b）。本备忘录中未说明每种类型网络的详细信息。
We define the SIP private header P-Charging-Vector header field. A proxy MAY include this header, if not already present, in either the initial request or response for a dialog, or in the request and response of a standalone transaction outside a dialog. When present, only one instance of the header MUST be present in a particular request or response.
我们定义了SIP私有报头P-Charging-Vector报头字段。代理可能会在对话框的初始请求或响应中，或在对话框外部的独立事务的请求和响应中包含此标头（如果尚未存在）。当存在时，特定请求或响应中只能存在一个标头实例。
The mechanisms by which a SIP proxy collects the values to populate the P-Charging-Vector header field are outside the scope of this document.
SIP代理收集值以填充P-Vector头字段的机制不在本文档的范围内。
The P-Charging-Vector header field is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.
P-Charging-Vector标头字段适用于单个私有管理域内或不同管理域之间，其中域之间存在信任关系。
The P-Charging-Vector header field is not included in a SIP message sent to another network if there is no trust relationship. The header is not applicable if the administrative domain manages charging in a way that does not require correlation of records from multiple network entities (e.g., SIP proxies).
如果不存在信任关系，则发送到另一个网络的SIP消息中不包括P-Charging-Vector头字段。如果管理域以不需要多个网络实体（例如，SIP代理）的记录关联的方式管理计费，则报头不适用。
The P-Charging-Vector header field is applicable whenever the following circumstances are met:
只要满足以下条件，P-Charging-Vector标头字段就适用：
1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE) or mid-dialog request (e.g., UPDATE) or a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UA向位于专用网络管理域中的代理发送寄存器或对话框启动请求（如INVITE）、中间对话框请求（如UPDATE）或对话框外部的独立事务请求。
2. A registrar, proxy, or UA that is located in the administrative domain of the private network wants to generate charging records.
2. 位于专用网络管理域中的注册商、代理或UA希望生成计费记录。
3. A proxy or UA that is located in the administrative domain of the private network has access to the charging correlation information for that network.
3. 位于专用网络的管理域中的代理或UA可以访问该网络的计费相关信息。
4. Optionally, a registrar, proxy, or UA that is part of a second administrative domain in another private network, whose SIP requests and responses are traversed through, en route to/from the first private network, wants to generate charging records and correlate those records with those of the first private network. This assumes that there is a trust relationship between both private networks.
4. 可选地，作为另一专用网络中的第二管理域的一部分的注册器、代理或UA，其SIP请求和响应在往返于第一专用网络的途中被穿越，想要生成计费记录并将这些记录与第一专用网络的记录相关联。这假定两个专用网络之间存在信任关系。
The P-Charging-Vector header field is used to convey charging-related information, such as the globally unique IMS Charging Identity (ICID) value.
P-Charging-Vector报头字段用于传送与充电相关的信息，例如全球唯一IMS充电标识（ICID）值。
Typically, a SIP proxy that receives a SIP request that does not contain a P-Charging-Vector header field MAY insert it, with those parameters that are available at the SIP proxy.
通常，接收不包含P-Vector报头字段的SIP请求的SIP代理可以使用SIP代理上可用的那些参数将其插入。
A SIP proxy that receives a SIP request that contains a P-Charging-Vector header field can use the values, such as the globally unique ICID, to produce charging records.
接收包含P-Charging-Vector头字段的SIP请求的SIP代理可以使用这些值（例如全局唯一ICID）来生成计费记录。
This document does not specify any procedure at a UA located outside the administrative domain of a private network (e.g., PSTN gateway or conference mixer), with regard to the P-Charging-Vector header field. UAs need not understand this header.
本文件未规定位于专用网络（例如，PSTN网关或会议混音器）管理域之外的UA处关于P-Charging-Vector报头字段的任何程序。UAs不需要理解此标题。
However, it might be possible that a UA be located within the administrative domain of a private network (e.g., a PSTN gateway, or conference mixer), and it may interact with the charging entities. In this case, a UA MAY insert the P-Charging-Vector header field in a SIP request or response when the next hop for the message is a proxy or UA located in the same administrative domain. Similarly, such a UA MAY use the contents of the P-Charging-Vector header field in communicating with the charging entities.
然而，UA可能位于专用网络（例如，PSTN网关或会议混频器）的管理域内，并且它可能与计费实体交互。在这种情况下，当消息的下一跳是位于同一管理域中的代理或UA时，UA可以在SIP请求或响应中插入P-Vector报头字段。类似地，这样的UA可以在与计费实体通信时使用P-Charging-Vector报头字段的内容。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Vector header field MAY insert a P-Charging-Vector header field prior to forwarding the message. The header is populated with one or more parameters, as described in the syntax, including but not limited to, a globally unique charging identifier.
支持该扩展并接收不带P-Charging-Vector报头字段的请求或响应的SIP代理可以在转发消息之前插入P-Charging-Vector报头字段。如语法中所述，使用一个或多个参数填充报头，包括但不限于全局唯一的计费标识符。
If a proxy that supports this extension receives a request or response with the P-Charging-Vector header field, it MAY retrieve the information from the header value to use with application-specific logic, i.e., charging. If the next hop for the message is within the trusted domain, then the proxy SHOULD include the P-Charging-Vector header field in the outbound message. If the next hop for the message is outside the trusted domain, then the proxy MAY remove the P-Charging-Function-Addresses header field.
如果支持此扩展的代理接收到带有P-Charging-Vector头字段的请求或响应，则它可以从头值检索信息，以用于特定于应用程序的逻辑，即充电。如果消息的下一个跃点位于受信任域内，则代理应在出站消息中包含P-Charging-Vector头字段。如果消息的下一个跃点位于受信任域之外，则代理可能会删除P-Charging-Function-Addresses标头字段。
Per local application-specific logic, the proxy MAY modify the contents of the P-Charging-Vector header field prior to sending the message.
根据本地应用程序特定逻辑，代理可以在发送消息之前修改P-Vector报头字段的内容。
We present an example in the context of the scenario shown in the following network diagram:
我们在以下网络图所示场景的上下文中提供了一个示例：
Scenario UA1 --- P1 --- P2 --- UA2
Scenario UA1 --- P1 --- P2 --- UA2
This example shows the message sequence for an INVITE transaction originating from UA1 and eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case, P1 inserts charging information. Then, P1 routes the call via P2 to UA2.
此示例显示源自UA1并最终到达UA2的INVITE事务的消息序列。P1是UA1的出站代理。在这种情况下，P1插入充电信息。然后，P1通过P2将呼叫路由到UA2。
Message sequence for INVITE using P-Charging-Vector header field:
使用P-Vector头字段的INVITE的消息序列：
F1 Invite UA1 -> P1
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
F1 Invite UA1 -> P1
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
F2 Invite P1 -> P2
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP P1@home1.net:5060;branch=z9hG4bK34ghi7a
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Vector: icid-value=1234bc9876e;
icid-generated-at=192.0.6.8;
orig-ioi=home1.net
F2 Invite P1 -> P2
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP P1@home1.net:5060;branch=z9hG4bK34ghi7a
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Vector: icid-value=1234bc9876e;
icid-generated-at=192.0.6.8;
orig-ioi=home1.net
The transit-ioi is added to the P-Charging-Vector header field when traversing transit networks. It is allowed to have multiple transit-ioi values within one SIP message or response. The values within the response are independent from the values set up within the request.
当穿越公交网络时，公交ioi被添加到P-Charging-Vector报头字段。允许在一条SIP消息或响应中有多个传输ioi值。响应中的值独立于请求中设置的值。
The element could be added either by a transit network itself or by the succeeding network at the entry point where the preceding network is known. Based on network policy, a void value can be used.
该元素可以由公交网络本身添加，也可以由前面网络已知的入口点处的后续网络添加。根据网络策略，可以使用void值。
Depending on the call scenario, each transit network can add either a transit network name or a void value. However, it cannot be guaranteed that all the values that are added will appear within the P-Charging-Vector header field.
根据呼叫场景，每个公交网络可以添加公交网络名称或void值。但是，不能保证添加的所有值都会出现在P-Charging-Vector标头字段中。
Some networks can screen the P-Charging-Vector header field and delete transit-ioi values, e.g., networks not supporting this value. There are scenarios where the appearance of the transit-ioi values of all networks is needed to have a correct end-to-end view.
一些网络可以屏蔽P-Charging-Vector报头字段并删除传输ioi值，例如，不支持该值的网络。在某些情况下，所有网络的传输ioi值的外观都需要具有正确的端到端视图。
The policies of adding, modifying, and deleting transit-ioi values are out of the scope of this document.
添加、修改和删除传输ioi值的策略不在本文档的范围内。
The transit-ioi contains an indexed value that MUST be incremented with each value added to the P-Charging-Vector header field.
transit ioi包含一个索引值，该值必须随着每个值添加到P-Charging-Vector标头字段而递增。
A void value has no index. By adding the next value, the index has to be incremented by the number of void entries +1.
void值没有索引。通过添加下一个值，索引必须增加无效条目数+1。
Procedures described within Section 4.5.2.2 apply. A transit-ioi MAY be added or modified by a proxy. A deletion of the transit-ioi or a entry within the tranist-ioi could appear depending on the network policy and trust rules. This is also valid by replacing the transit-ioi with a void value.
第4.5.2.2节中描述的程序适用。运输ioi可由代理添加或修改。根据网络策略和信任规则，可能会删除传输ioi或传输ioi中的条目。通过使用void值替换transit ioi，这也是有效的。
The UAS acting as a B2BUA MAY add the related-icid into the P-Charging-Vector header field into SIP request or SIP responses. For example, the UAS can include the related-icid in a response to an INVITE request when the received INVITE request creates a new call leg towards the same remote end. The value of the related-icid is the icid value of the original dialog towards the remote end.
充当B2BUA的UAS可以将相关icid添加到P-Charging-Vector报头字段中，并将其添加到SIP请求或SIP响应中。例如，当接收到的INVITE请求向同一远端创建新的呼叫分支时，UAS可以在对INVITE请求的响应中包括相关icid。相关icid的值是指向远程端的原始对话框的icid值。
Procedures described within Section 4.5.2.2 apply. A related-icid and "related-icid-generated-at" MAY be added or modified by a proxy. A deletion of the elements could appear depending on the network policy and trust rules.
第4.5.2.2节中描述的程序适用。可通过代理添加或修改相关icid和“在生成的相关icid”。根据网络策略和信任规则，可能会删除元素。
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 5234 [RFC5234]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementors need to be familiar with the notation and contents of SIP [RFC3261] and [RFC5234] to understand this document.
本文件中规定的所有机制均以散文和RFC 5234[RFC5234]中定义的增广巴科斯诺尔形式（BNF）进行了描述。此外，几个BNF定义是从SIP继承的，这里不再重复。实施者需要熟悉SIP[RFC3261]和[RFC5234]的符号和内容才能理解本文档。
The syntax of the P-Associated-URI header field is described as follows:
P-Associated-URI头字段的语法描述如下：
P-Associated-URI = "P-Associated-URI" HCOLON [p-aso-uri-spec] *(COMMA p-aso-uri-spec) p-aso-uri-spec = name-addr *(SEMI ai-param) ai-param = generic-param
P-Associated-URI=“P-Associated-URI”HCOLON[P-aso-URI-spec]*（逗号P-aso-URI-spec）P-aso-URI-spec=name addr*（半人工智能参数）人工智能参数=generic参数
The syntax of the P-Called-Party-ID header field is described as follows:
P-Called-Party-ID头字段的语法描述如下：
P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec called-pty-id-spec = name-addr *(SEMI cpid-param) cpid-param = generic-param
P-Called-Party-ID=“P-Called-Party-ID”HCOLON调用pty ID spec调用pty ID spec=name addr*（半cpid参数）cpid param=generic param
The syntax of the P-Visited-Network-ID header field is described as follows:
P-visted-Network-ID头字段的语法描述如下：
P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON
vnetwork-spec
*(COMMA vnetwork-spec)
vnetwork-spec = (token / quoted-string)
*(SEMI vnetwork-param)
vnetwork-param = generic-param
P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON
vnetwork-spec
*(COMMA vnetwork-spec)
vnetwork-spec = (token / quoted-string)
*(SEMI vnetwork-param)
vnetwork-param = generic-param
The syntax of the P-Access-Network-Info header field is described as follows:
P-Access-Network-Info标头字段的语法描述如下：
P-Access-Network-Info = "P-Access-Network-Info" HCOLON
access-net-spec *(COMMA access-net-spec)
access-net-spec = (access-type / access-class)
*(SEMI access-info)
access-type = "IEEE-802.11" / "IEEE-802.11a" /
"IEEE-802.11b" / "IEEE-802.11g" /
"IEEE-802.11n" /
"IEEE-802.3" / "IEEE-802.3a" /
"IEEE-802.3ab" / "IEEE-802.3ae" /
"IEEE-802.3ak" / "IEEE-802.3ah" /
P-Access-Network-Info = "P-Access-Network-Info" HCOLON
access-net-spec *(COMMA access-net-spec)
access-net-spec = (access-type / access-class)
*(SEMI access-info)
access-type = "IEEE-802.11" / "IEEE-802.11a" /
"IEEE-802.11b" / "IEEE-802.11g" /
"IEEE-802.11n" /
"IEEE-802.3" / "IEEE-802.3a" /
"IEEE-802.3ab" / "IEEE-802.3ae" /
"IEEE-802.3ak" / "IEEE-802.3ah" /
"IEEE-802.3aq" / "IEEE-802.3an" /
"IEEE-802.3e" / "IEEE-802.3i" /
"IEEE-802.3j" / "IEEE-802.3u" /
"IEEE-802.3y" / "IEEE-802.3z" /
"3GPP-GERAN" /
"3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" /
"3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" /
"3GPP2-1X-Femto" / "3GPP2-UMB" /
"3GPP2-1X-HRPD" / "3GPP2-1X" /
"ADSL" / "ADSL2" / "ADSL2+" / "RADSL" /
"SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" /
"VDSL" / "IDSL" /
"DOCSIS" / "GSTN" / "GPON" / " XGPON1" /
"DVB-RCS2" / token
access-class = "3GPP-GERAN" / "3GPP-UTRAN" /
"3GPP-E-UTRAN" / "3GPP-WLAN" /
"3GPP-GAN" / "3GPP-HSPA" /
"3GPP2" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
dsl-location / i-wlan-node-id /
ci-3gpp2 / eth-location /
ci-3gpp2-femto / fiber-location /
np / gstn-location /local-time-zone /
dvb-rcs2-node-id / extension-access-info
np = "network-provided"
extension-access-info = gen-value
cgi-3gpp = "cgi-3gpp" EQUAL
(token / quoted-string)
utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL
(token / quoted-string)
i-wlan-node-id = "i-wlan-node-id" EQUAL
(token / quoted-string)
dsl-location = "dsl-location" EQUAL
(token / quoted-string)
eth-location = "eth-location" EQUAL
(token / quoted-string)
fiber-location = "fiber-location" EQUAL
(token / quoted-string)
ci-3gpp2 = "ci-3gpp2" EQUAL
(token / quoted-string)
ci-3gpp2-femto = "ci-3gpp2-femto" EQUAL
(token / quoted-string)
gstn-location = "gstn-location" EQUAL
(token / quoted-string)
dvb-rcs2-node-id = "dvb-rcs2-node-id" EQUAL
quoted-string
local-time-zone = "local-time-zone" EQUAL
quoted-string
"IEEE-802.3aq" / "IEEE-802.3an" /
"IEEE-802.3e" / "IEEE-802.3i" /
"IEEE-802.3j" / "IEEE-802.3u" /
"IEEE-802.3y" / "IEEE-802.3z" /
"3GPP-GERAN" /
"3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" /
"3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" /
"3GPP2-1X-Femto" / "3GPP2-UMB" /
"3GPP2-1X-HRPD" / "3GPP2-1X" /
"ADSL" / "ADSL2" / "ADSL2+" / "RADSL" /
"SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" /
"VDSL" / "IDSL" /
"DOCSIS" / "GSTN" / "GPON" / " XGPON1" /
"DVB-RCS2" / token
access-class = "3GPP-GERAN" / "3GPP-UTRAN" /
"3GPP-E-UTRAN" / "3GPP-WLAN" /
"3GPP-GAN" / "3GPP-HSPA" /
"3GPP2" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
dsl-location / i-wlan-node-id /
ci-3gpp2 / eth-location /
ci-3gpp2-femto / fiber-location /
np / gstn-location /local-time-zone /
dvb-rcs2-node-id / extension-access-info
np = "network-provided"
extension-access-info = gen-value
cgi-3gpp = "cgi-3gpp" EQUAL
(token / quoted-string)
utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL
(token / quoted-string)
i-wlan-node-id = "i-wlan-node-id" EQUAL
(token / quoted-string)
dsl-location = "dsl-location" EQUAL
(token / quoted-string)
eth-location = "eth-location" EQUAL
(token / quoted-string)
fiber-location = "fiber-location" EQUAL
(token / quoted-string)
ci-3gpp2 = "ci-3gpp2" EQUAL
(token / quoted-string)
ci-3gpp2-femto = "ci-3gpp2-femto" EQUAL
(token / quoted-string)
gstn-location = "gstn-location" EQUAL
(token / quoted-string)
dvb-rcs2-node-id = "dvb-rcs2-node-id" EQUAL
quoted-string
local-time-zone = "local-time-zone" EQUAL
quoted-string
operator-specific-GI = "operator-specific-GI" EQUAL (token / quoted-string) utran-sai-3gpp = "utran-sai-3gpp" EQUAL (token / quoted-string)
特定于运营商的GI=“特定于运营商的GI”相等（令牌/带引号的字符串）utran-sai-3gpp=“utran-sai-3gpp”相等（令牌/带引号的字符串）
The access-info MAY contain additional information relating to the access network. The values for "cgi-3gpp", "utran-cell-id-3gpp", "i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto", and "gstn-location" are defined in 3GPP TS 24.229 [TS24.229].
接入信息可以包含与接入网络相关的附加信息。3gpp TS 24.229[TS24.229]中定义了“cgi-3gpp”、“utran-cell-id-3gpp”、“i-wlan-node-id”、“dsl位置”、“ci-3gpp2”、“ci-3gpp2-femto”和“gstn位置”的值。
The syntax for the P-Charging-Function-Addresses header field is described as follows:
P-Charging-Function-Addresses标头字段的语法描述如下：
P-Charging-Addresses = "P-Charging-Function-Addresses" HCOLON
charge-addr-params *(COMMA charge-addr-params)
charge-addr-params = charge-addr-param *(SEMI charge-addr-param)
charge-addr-param = ccf / ecf / ccf-2 /ecf-2 / generic-param
ccf = "ccf" EQUAL gen-value
ecf = "ecf" EQUAL gen-value
ccf-2 = "ccf-2" EQUAL gen-value
ecf-2 = "ecf-2" EQUAL gen-value
P-Charging-Addresses = "P-Charging-Function-Addresses" HCOLON
charge-addr-params *(COMMA charge-addr-params)
charge-addr-params = charge-addr-param *(SEMI charge-addr-param)
charge-addr-param = ccf / ecf / ccf-2 /ecf-2 / generic-param
ccf = "ccf" EQUAL gen-value
ecf = "ecf" EQUAL gen-value
ccf-2 = "ccf-2" EQUAL gen-value
ecf-2 = "ecf-2" EQUAL gen-value
The P-Charging-Function-Addresses header field contains one or two addresses of the ECF (ecf and ecf-2) or CCF (ccf and ccf-2). The first address of the sequence is ccf or ecf. If the first address of the sequence is not available, then the next address (ccf-2 or ecf-2) MUST be used if available.
P-Charging-Function-Addresses标头字段包含ECF（ECF和ECF-2）或CCF（CCF和CCF-2）的一个或两个地址。序列的第一个地址是ccf或ecf。如果序列的第一个地址不可用，则必须使用下一个地址（ccf-2或ecf-2）（如果可用）。
The syntax for the P-Charging-Vector header field is described as follows:
P-Charging-Vector标头字段的语法描述如下：
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value
*(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi / term-ioi /
transit-ioi / related-icid /
related-icid-gen-addr / generic-param
icid-value = "icid-value" EQUAL gen-value
icid-gen-addr = "icid-generated-at" EQUAL host
orig-ioi = "orig-ioi" EQUAL gen-value
term-ioi = "term-ioi" EQUAL gen-value
transit-ioi = "transit-ioi" EQUAL transit-ioi-list
transit-ioi-list = DQUOTE transit-ioi-param
*(COMMA transit-ioi-param) DQUOTE
transit-ioi-param = transit-ioi-indexed-value /
transit-ioi-void-value
transit-ioi-indexed-value = transit-ioi-name "."
transit-ioi-index
transit-ioi-name = ALPHA *(ALPHA / DIGIT)
transit-ioi-index = 1*DIGIT
transit-ioi-void-value = "void"
related-icid = "related-icid" EQUAL gen-value
related-icid-gen-addr = "related-icid-generated-at" EQUAL host
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value
*(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi / term-ioi /
transit-ioi / related-icid /
related-icid-gen-addr / generic-param
icid-value = "icid-value" EQUAL gen-value
icid-gen-addr = "icid-generated-at" EQUAL host
orig-ioi = "orig-ioi" EQUAL gen-value
term-ioi = "term-ioi" EQUAL gen-value
transit-ioi = "transit-ioi" EQUAL transit-ioi-list
transit-ioi-list = DQUOTE transit-ioi-param
*(COMMA transit-ioi-param) DQUOTE
transit-ioi-param = transit-ioi-indexed-value /
transit-ioi-void-value
transit-ioi-indexed-value = transit-ioi-name "."
transit-ioi-index
transit-ioi-name = ALPHA *(ALPHA / DIGIT)
transit-ioi-index = 1*DIGIT
transit-ioi-void-value = "void"
related-icid = "related-icid" EQUAL gen-value
related-icid-gen-addr = "related-icid-generated-at" EQUAL host
The P-Charging-Vector header field contains icid-value as a mandatory parameter. The icid-value represents the IMS charging ID, and contains an identifier used for correlating charging records and events. The first proxy that receives the request generates this value.
P-Charging-Vector标头字段包含icid值作为强制参数。icid值表示IMS充电ID，并包含用于关联充电记录和事件的标识符。接收请求的第一个代理将生成此值。
The icid-gen-addr parameter contains the hostname or IP address of the proxy that generated the icid-value.
icid gen addr参数包含生成icid值的代理的主机名或IP地址。
The orig-ioi and term-ioi parameters contain originating and terminating interoperator identifiers. They are used to correlate charging records between different operators. The originating IOI represents the network responsible for the charging records in the originating part of the session or standalone request. Similarly, the terminating IOI represents the network responsible for the charging records in the terminating part of the session or standalone request.
orig ioi和term ioi参数包含起始和终止的互操作标识符。它们用于关联不同操作员之间的充电记录。发起IOI表示负责会话或独立请求发起部分中计费记录的网络。类似地，终止IOI表示负责会话或独立请求的终止部分中的计费记录的网络。
The transit-ioi parameter contains values with each of them, respectively, representing a transit interoperator identifier. It is used to correlate charging records between different networks. The transit-ioi represents the network responsible for the records in the transit part of the session or standalone request.
transit ioi参数包含分别表示transit互操作器标识符的值。它用于关联不同网络之间的充电记录。传输ioi表示负责会话或独立请求传输部分记录的网络。
The related-icid parameter contains the icid-value of a related charging record when more than one call leg is associated with one session. This optional parameter is used for correlation of charging information between two or more call legs related to the same remote-end dialog.
当多个呼叫分支与一个会话相关联时，相关icid参数包含相关计费记录的icid值。此可选参数用于关联与同一远程端对话框相关的两个或多个呼叫分支之间的计费信息。
The related-icid-gen-addr parameter contains the hostname or IP address of the proxy that generated the related-icid.
相关icid gen addr参数包含生成相关icid的代理的主机名或IP地址。
Applications using the P-Charging-Vector header field within their own applicability are allowed to define generic-param extensions without further reference to the IETF specification process.
允许在其自身适用范围内使用P-Vector报头字段的应用程序定义通用参数扩展，而无需进一步参考IETF规范过程。
The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all responses. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses. The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL. The P-Charging-Vector header field can appear in all SIP methods except CANCEL. The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL.
P-Associated-URI头字段可以出现在SIP REGISTER method和2xx resonses中。P-Called-Party-ID头字段可以出现在SIP INVITE、OPTIONS、PUBLISH、SUBSCRIBE和MESSAGE方法以及所有响应中。P-visted-Network-ID报头字段可以出现在除ACK、BYE和CANCEL以及所有响应之外的所有SIP方法中。P-Access-Network-Info头字段可以出现在除ACK和CANCEL之外的所有SIP方法中。P-Charging-Vector头字段可以出现在除CANCEL之外的所有SIP方法中。P-Charging-Function-Addresses标头字段可以出现在除ACK和CANCEL之外的所有SIP方法中。
The information returned in the P-Associated-URI header field is not viewed as particularly sensitive. Rather, it is simply informational in nature, providing openness to the UAC with regard to the automatic association performed by the registrar. If end-to-end protection is not used at the SIP layer, it is possible for proxies between the registrar and the UA to modify the contents of the header value.
P-Associated-URI头字段中返回的信息并不被视为特别敏感。相反，它本质上只是信息性的，就注册官执行的自动关联向UAC提供了开放性。如果在SIP层未使用端到端保护，则注册器和UA之间的代理可以修改报头值的内容。
The lack of encryption, either end-to-end or hop-by-hop, may lead to leak some privacy regarding the list of authorized identities. For instance, a user who registers an address-of-record of sip:user1@example.com may get another SIP URI associated as sip:first.last@example.com returned in the P-Associated-URI header field value.
由于缺乏端到端或逐跳加密，可能会泄漏有关授权身份列表的一些隐私。例如，注册sip记录地址的用户：user1@example.com可能会获取另一个与SIP:first关联的SIP URI。last@example.com在P-Associated-URI标头字段值中返回。
An eavesdropper could possibly collect the list of identities a user is registered. This can have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop and where a trust relationship equivalent with that defined in RFC 3325 [RFC3325] between entities exists. That is, the privacy of the user relies on the other entities in the session not disclosing information that they have learned about the user.
窃听者可能会收集用户注册的身份列表。这可能涉及隐私问题。为了缓解此问题，此扩展应仅在安全环境中使用，其中SIP消息的加密提供端到端或逐跳，并且实体之间存在与RFC 3325[RFC3325]中定义的信任关系等效的信任关系。也就是说，用户的隐私依赖于会话中的其他实体不披露他们了解到的关于用户的信息。
While the P-Associated-URI header field value allows the implicit registration of a bundle of URIs with one REGISTER Message, the impact of security using the P-Associated-URI header field is no higher than using separate REGISTER messages for each of the URIs.
虽然P-Associated-URI头字段值允许使用一条注册消息隐式注册一组URI，但使用P-Associated-URI头字段的安全性影响并不高于为每个URI使用单独的注册消息。
Due to the nature of the P-Called-Party-ID header field, this header does not introduce any significant security concern. It is possible for an attacker to modify the contents of the header. However, this modification will not cause any harm to the session establishment.
由于P-Called-Party-ID报头字段的性质，该报头不会引入任何重要的安全问题。攻击者有可能修改标头的内容。但是，此修改不会对会话建立造成任何损害。
An eavesdropper could possibly collect the list of identities a user has registered. This can have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop.
窃听者可能会收集用户已注册的身份列表。这可能涉及隐私问题。为了缓解此问题，此扩展应仅在安全环境中使用，其中SIP消息的加密提供端到端或逐跳。
Normally, within a 3GPP environment, the P-Called-Party-ID is not sent towards end users but may be exchanged between carriers where other security mechanisms than SIP encryption are used.
通常，在3GPP环境中，P-Party-ID不发送给最终用户，而是可以在使用SIP加密以外的其他安全机制的载波之间交换。
The P-Visited-Network-ID header field assumes that there is trust relationship between a home network and one or more transited visited networks. It is possible for other proxies between the proxy in the visited network that inserts the header, and the registrar or the home proxy, to modify the value of P-Visited-Network-ID header field. Therefore, intermediaries participating in this mechanism MUST apply a hop-by-hop integrity-protection mechanism such as IPsec or other available mechanisms in order to prevent such attacks.
P-visted-Network-ID报头字段假定家庭网络和一个或多个转机访问的网络之间存在信任关系。在插入报头的到访网络中的代理和注册者或归属代理之间的其他代理可以修改P-visted-network-ID报头字段的值。因此，参与此机制的中介体必须应用逐跳完整性保护机制，如IPsec或其他可用机制，以防止此类攻击。
A Trust Domain is formally defined in RFC 3324 [RFC3324]. For the purposes of this document, we refer to the 3GPP trust domain as the collection of SIP proxies and application servers that are operated by a 3GPP network operator and are compliant with the requirements expressed in 3GPP TS 24.229 [TS24.229].
信任域在RFC 3324[RFC3324]中正式定义。在本文档中，我们将3GPP信任域称为由3GPP网络运营商操作并符合3GPP TS 24.229[TS24.229]中所述要求的SIP代理和应用服务器的集合。
This extension assumes that the access network is trusted by the UA (because the UA's home network has a trust relationship with the access network), as described earlier in this document.
此扩展假定接入网络受UA信任（因为UA的家庭网络与接入网络具有信任关系），如本文档前面所述。
This extension assumes that the information added to the header by the UAC should be sent only to trusted entities and MUST NOT be used outside of the trusted administrative network domain.
此扩展假定UAC添加到标头的信息应仅发送给受信任的实体，并且不得在受信任的管理网络域之外使用。
The SIP proxy that provides services to the user, utilizes the information contained in this header to provide additional services and UAs are expected to provide correct information. However, there are no security problems resulting from a UA inserting incorrect information. Networks providing services based on the information carried in the P-Access-Network-Info header field will therefore need to trust the UA sending the information. A rogue UA sending false access network information will do no more harm than to restrict the user from using certain services.
向用户提供服务的SIP代理利用此标头中包含的信息提供附加服务，UAs应提供正确的信息。但是，不存在由于UA插入错误信息而导致的安全问题。因此，基于P-Access-Network-Info报头字段中携带的信息提供服务的网络需要信任发送信息的UA。流氓UA发送虚假访问网络信息的危害不会比限制用户使用某些服务更大。
The mechanism provided in this document is designed primarily for private systems like 3GPP. Most security requirements are met by way of private standardized solutions.
本文档中提供的机制主要针对3GPP等专用系统设计。大多数安全要求都是通过专用标准化解决方案来满足的。
For instance, 3GPP will use the P-Access-Network-Info header field to carry relatively sensitive information like the cell ID. Therefore, the information MUST NOT be sent outside of the 3GPP domain.
例如，3GPP将使用P-Access-Network-Info报头字段来携带相对敏感的信息，如小区ID。因此，信息不得发送到3GPP域之外。
The UA is aware -- if it is a 3GPP UA -- that it is operating within a trusted domain.
UA知道——如果它是3GPP UA——它在可信域内运行。
The 3GPP UA is aware of whether or not a secure association to the home network domain for transporting SIP signaling is currently available, and, as such, the sensitive information carried in the P-Access-Network-Info header field MUST NOT be sent in any initial unauthenticated and unprotected requests (e.g., REGISTER).
3GPP UA知道用于传输SIP信令的到家庭网络域的安全关联当前是否可用，因此，P-Access-network-Info报头字段中携带的敏感信息不得在任何初始未经验证和未受保护的请求（例如，寄存器）中发送。
Any UA that is using this extension and is not part of a private trusted domain should not consider the mechanism as secure, and, as such, MUST NOT send sensitive information in the P-Access-Network-Info header field.
任何使用此扩展而不是私有信任域的UA不应认为该机制是安全的，因此，在PACCESS-NETWORK-FIN报头字段中不必发送敏感信息。
Any proxy that is operating in a private trust domain where the P-Access-Network-Info header field is supported is REQUIRED to delete the header, if it is present, from any message prior to forwarding it outside of the trusted domain.
在支持P-Access-Network-Info头字段的私有信任域中运行的任何代理都需要在将消息转发到受信任域之外之前从任何消息中删除头（如果存在）。
A proxy receiving a message containing the P-Access-Network-Info header field from an untrusted entity is not able to guarantee the validity of the contents. Thus, this content SHOULD be deleted based on local policy.
从不受信任的实体接收包含P-Access-Network-Info标头字段的消息的代理无法保证内容的有效性。因此，应根据当地政策删除此内容。
It is expected as normal behavior that proxies within a closed network will modify the values of the P-Charging-Function-Addresses header field and insert it into a SIP request or response. However, the proxies that share this information MUST have a trust relationship.
通常情况下，封闭网络中的代理会修改P-Charging-Function-Addresses标头字段的值，并将其插入SIP请求或响应中。但是，共享此信息的代理必须具有信任关系。
If an untrusted entity were inserted between trusted entities, it could potentially substitute a different charging function address. Therefore, an integrity-protection mechanism such as IPsec or other available mechanisms MUST be applied in order to prevent such attacks. Since each trusted proxy MAY need to view or modify the values in the P-Charging-Function-Addresses header field, the protection should be applied on a hop-by-hop basis.
如果在受信任的实体之间插入不受信任的实体，则可能会替换不同的计费功能地址。因此，必须应用完整性保护机制，如IPsec或其他可用机制，以防止此类攻击。由于每个受信任代理可能需要查看或修改P-Charging-Function-Addresses标头字段中的值，因此应逐跳应用保护。
It is expected as normal behavior that proxies within a closed network will modify the values of the P-Charging-Vector header field and insert it into a SIP request or response. However, these proxies that share this information MUST have a trust relationship.
通常情况下，封闭网络中的代理会修改P-Vector头字段的值，并将其插入到SIP请求或响应中。但是，这些共享此信息的代理必须具有信任关系。
If an untrusted entity were inserted between trusted entities, it could potentially interfere with the charging correlation mechanism. Therefore, an integrity-protection mechanism such as IPsec or other available mechanisms MUST be applied in order to prevent such attacks. Since each trusted proxy MAY need to view or modify the values in the P-Charging-Vector header field, the protection should be applied on a hop-by-hop basis.
如果在受信任的实体之间插入不受信任的实体，则可能会干扰计费关联机制。因此，必须应用完整性保护机制，如IPsec或其他可用机制，以防止此类攻击。由于每个受信任代理可能需要查看或修改P-Charging-Vector头字段中的值，因此应逐跳应用保护。
This document defines several private SIP extension header fields (beginning with the prefix "P-" ).
本文档定义了几个专用SIP扩展头字段（以前缀“P-”开头）。
This document obsoletes [RFC3455] but uses the same SIP header field names. The references in the "Header Fields" registry and "Header Field Parameters and Parameter Values" registry have been updated to [RFC3455] to this document.
本文档废弃[RFC3455]，但使用相同的SIP头字段名。“标题字段”注册表和“标题字段参数和参数值”注册表中的参考已更新为本文档的[RFC3455]。
The following extensions are registered as private extension header fields:
以下扩展已注册为专用扩展标头字段：
Header Field Name: P-Associated-URI Compact Form: none Reference: RFC 7315
标题字段名称：P-Associated-URI压缩格式：无引用：RFC 7315
Header Field Name: P-Called-Party-ID Compact Form: none Reference: RFC 7315
标题字段名称：P-Called-Party-ID压缩格式：无引用：RFC 7315
Header Field Name: P-Visited-Network-ID Compact Form: none Reference: RFC 7315
标题字段名称：P-Visited-Network-ID压缩格式：无参考：RFC 7315
Header Field Name: P-Access-Network-Info Parameter Name: ci-3gpp Parameter Name: ci-3gpp2 Parameter Name: ci-3gpp2-femto Parameter Name: dsl-location Parameter Name: dvb-rcs2-node-id Parameter Name: eth-location Parameter Name: fiber-location Parameter Name: gstn-location Parameter Name: i-wlan-node-id Parameter Name: local-time-zone Parameter Name: operator-specific-GI Parameter Name: utran-cell-id-3gpp Parameter Name: utran-sai-3gpp Compact Form: none Reference: RFC 7315
标题字段名称：P-Access-Network-Info参数名称：ci-3gpp参数名称：ci-3gpp2参数名称：ci-3gpp2-femto参数名称：dsl位置参数名称：dvb-rcs2-node-id参数名称：eth位置参数名称：光纤位置参数名称：gstn位置参数名称：i-wlan-node-id参数名称：本地时区参数名称：特定于运营商的GI参数名称：utran-cell-id-3gpp参数名称：utran-sai-3gpp压缩格式：无参考：RFC 7315
Header Field Name: P-Charging-Function-Addresses Parameter Name: ccf Parameter Name: ccf-2 Parameter Name: ecf Parameter Name: ecf-2 Compact Form: none Reference: RFC 7315
标题字段名称：P-Charging-Function-Addresses参数名称：ccf参数名称：ccf-2参数名称：ecf参数名称：ecf-2压缩格式：无参考：RFC 7315
Header Field Name: P-Charging-Vector Parameter Name: icid-value Parameter Name: icid-generated-at Parameter Name: orig-ioi Parameter Name: related-icid Parameter Name: related-icid-generated-at Parameter Name: term-ioi Parameter Name: transit-ioi Compact Form: none Reference: RFC 7315
标题字段名称：P-Charging-Vector参数名称：icid值参数名称：参数名称处生成的icid:原始ioi参数名称：相关icid参数名称：参数名称处生成的相关icid:术语ioi参数名称：传输ioi压缩格式：无参考：RFC 7315
The authors would like to thank James Yu and Atle Monrad for their extensive review, Dean Willis for his expert review, and Mary Barnes for the proto review. The authors would like to acknowledge the constructive feedback and contributions provided by Peter Leis, Joergen Axell, and Jan Holm.
作者要感谢James Yu和Atle Monrad的广泛评论，感谢Dean Willis的专家评论，感谢Mary Barnes的原型评论。作者要感谢Peter Leis、Joergen Axell和Jan Holm提供的建设性反馈和贡献。
The extensions described in [RFC3455] were originally specified in several documents. Miguel Garcia-Martin authored the P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID header fields. Duncan Mills authored the P-Access-Network-Info header. Eric Henrikson authored the P-Charging-Function-Addresses and P-Charging-Vector headers. Rohan Mahy assisted in the incorporation of these extensions into a single document.
[RFC3455]中描述的扩展最初在多个文档中指定。Miguel Garcia Martin编写了P-Associated-URI、P-Called-Party-ID和P-Visited-Network-ID头字段。Duncan Mills编写了P-Access-Network-Info标题。Eric Henrikson编写了P-Charging-Function-Addresses和P-Charging-Vector头文件。Rohan Mahy协助将这些扩展合并到一个文件中。
The listed authors of [RFC3455] were Miguel Garcia-Martin, Eric Henrikson and Duncan Mills.
[RFC3455]的作者包括米格尔·加西亚·马丁、埃里克·亨利克森和邓肯·米尔斯。
The [RFC3455] authors thanked Andrew Allen, Gabor Bajko, Gonzalo Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Jonathan Rosenberg, Ya-Ching Tan, and the 3GPP CN1 WG members for their comments on [RFC3455].
[RFC3455]作者感谢Andrew Allen、Gabor Bajko、Gonzalo Camarillo、Keith Drage、Georg Mayer、Dean Willis、Rohan Mahy、Jonathan Rosenberg、Ya Ching Tan和3GPP CN1工作组成员对[RFC3455]的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[TS24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 12.4.0, March 2014.
[TS24.229]3GPP，“基于会话发起协议（SIP）和会话描述协议（SDP）的IP多媒体呼叫控制协议；第3阶段”，3GPP TS 24.229 12.4.02014年3月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]Watson，M.，“网络断言身份的短期要求”，RFC 33242002年11月。
[RFC3325] 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.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003.
[RFC3455]Garcia Martin，M.，Henrikson，E.，和D.Mills，“第三代合作伙伴关系项目（3GPP）会话启动协议（SIP）的专用头（P头）扩展”，RFC 3455，2003年1月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC4083] Garcia-Martin, M., "Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)", RFC 4083, May 2005.
[RFC4083]Garcia Martin，M.，“输入第三代合作伙伴关系项目（3GPP）第5版对会话启动协议（SIP）的要求”，RFC 40832005年5月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665]Roach，A.，“SIP特定事件通知”，RFC 66652012年7月。
[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, February 2014.
[RFC7044]Barnes，M.，Audet，F.，Schubert，S.，van Elburg，J.，和C.Holmberg，“请求历史信息会话启动协议（SIP）的扩展”，RFC 7044，2014年2月。
[TS23.228] 3GPP, "P Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 12.4.0, March 2014.
[TS23.228]3GPP，“多媒体子系统（IMS）；第2阶段”，3GPP TS 23.228 12.4.012014年3月。
[TS32.240] 3GPP, "Telecommunication management; Charging management; Charging architecture and principles", 3GPP TS 32.240 12.3.0, March 2013.
[TS32.240]3GPP，“电信管理；计费管理；计费架构和原则”，3GPP TS 32.240 12.3.012013年3月。
[TS32.260] 3GPP, "Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging", 3GPP TS 32.260 10.3.0, April 2011.
[TS32.260]3GPP，“电信管理；充电管理；IP多媒体子系统（IMS）充电”，3GPP TS 32.260 10.3.0，2011年4月。
1. Procedures for the P-Associated-URI header field at a proxy. RFC 3455 indicates that it defines no procedures for the P-Associated-URI header field at a proxy. What is implicitly meant here is that the proxy does not add, read, modify, or delete the header; therefore, RFC 3261 proxy procedures only apply to the header.
1. 代理上P-Associated-URI头字段的过程。RFC 3455表示它没有为代理上的P-Associated-URI头字段定义任何过程。这里隐含的意思是代理不添加、读取、修改或删除标题；因此，RFC 3261代理过程仅适用于标头。
2. P-Called-Party-ID header field and the History-Info header field: At the time RFC 3455 was written, the History-Info header field was a long way from specification. This header has now been specified and approved in RFC 7044. It is acknowledged that the History-Info header field will provide equivalent coverage to that of the P-Called-Party-ID header field. However, the P-Called-Party-ID header field is used entirely within the 3GPP system and does not appear to SIP entities outside that of a single 3GPP operator.
2. P-Called-Party-ID头字段和历史信息头字段：在编写RFC 3455时，历史信息头字段与规范相去甚远。该标题现已在RFC 7044中指定和批准。众所周知，历史信息标题字段将提供与P-Party-ID标题字段相同的覆盖范围。然而，P-Called-Party-ID报头字段完全在3GPP系统内使用，并且对于单个3GPP运营商之外的SIP实体来说似乎不存在。
3. Procedures at the UA for the P-Charging-Function Addresses header field: The text in Section 4.5.2.1 of RFC 3455 does not adequately take into account procedures for UAs located inside the private network, e.g., as gateways and such that may play a full part in network charging procedures. Section 4.5.2.1 is replaced with new text.
3. UA中P-Charging-Function Addresses标头字段的程序：RFC 3455第4.5.2.1节中的文本未充分考虑位于专用网络内的UAs的程序，例如，作为网关以及可能在网络计费程序中发挥全部作用的UAs。第4.5.2.1节替换为新文本。
4. The text in Section 4.6.2.1 of RFC 3455 does not adequately take into account procedures for UAs located inside the private network, e.g., as gateways and such that may play a full part in network charging procedures. Section 4.6.2.1 is now replaced with new text.
4. RFC 3455第4.6.2.1节中的文本未充分考虑位于专用网络内的UAs的程序，例如，作为网关，以及可能在网络计费程序中发挥全部作用的UAs。第4.6.2.1节现在替换为新文本。
5. Recognition of additional values of access technology in the P-Access-Network-Info header field (Section 4.4): A number of new access technologies are contemplated in 3GPP, and the reuse of IMS to support Next Generation Networks (NGN) is also resulting in new access technologies. Values for access technologies are defined explicitly in RFC 3455, and no IANA procedures are defined to maintain a separate registry. In particular, the new values: "IEEE 802.11", "IEEE-802.11g", "IEEE-802.11n", "ADSL" / "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", "IEEE-802.3ak", "IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y", "IEEE-802.3z", and "IEEE-802.3y" are defined.
5. 在P-access-Network-Info报头字段中识别接入技术的附加值（第4.4节）：3GPP中考虑了许多新的接入技术，并且复用IMS以支持下一代网络（NGN）也产生了新的接入技术。访问技术的值在RFC 3455中明确定义，并且没有定义IANA过程来维护单独的注册表。特别是，新值：“IEEE 802.11”、“IEEE-802.11g”、“IEEE-802.11n”、“ADSL”/“ADSL2”、“ADSL2+”、“RADSL”、“SDSL”、“HDSL”、“HDSL2”、“G.SHDSL”、“VDSL”、“IDSL”、“IEEE-802.3”、“IEEE-802.3a”、“IEEE-802.3e”、“IEEE-802.3i”、“IEEE-802.3j”、“IEEE-802.3u”、“IEEE-802.3ab”、“IEEE-802.3ak”、“IEEE-802.3aq”、“IEEE-802.3an”、“IEEE-802.3y”，定义了“IEEE-802.3z”和“IEEE-802.3y”。
6. Replacement of existing value of access technology in the P-Access-Network-Info header field (Section 4.4): The value of "3GPP-CDMA2000" was replaced long ago in 3GPP2 by three new values: "3GPP2-1X", "3GPP2-1X-HRPD", and "3GPP2-UMB". It is not believed that there was any deployment of the "3GPP-CDMA2000" value.
6. 替换P-access-Network-Info报头字段中接入技术的现有值（第4.4节）：3GPP2中的“3GPP-CDMA2000”值很久以前就被三个新值替换：“3GPP2-1X”、“3GPP2-1X-HRPD”和“3GPP2-UMB”。不相信存在任何部署“3GPP-CDMA2000”值的情况。
7. Network-provided P-Access-Network-Info header field: The P-Access-Network-Info header field may additionally be provided by proxies within the network. This does not impact the values provided by a UA; rather, the header is repeated. Such values are identified by the string "network-provided". A special class of values are defined for use here, as the same granularity of values may not be possible as for those available from the UA: "3GPP-GERAN", "3GPP-UTRAN", "3GPP-WLAN", "3GPP-GAN", and "3GPP-HSPA". Outbound proxies remove P-Access-Network-Info header fields containing the "network-provided" value.
7. 网络提供的P-Access-Network-Info报头字段：P-Access-Network-Info报头字段还可以由网络内的代理提供。这不会影响UA提供的值；相反，标题是重复的。这些值由字符串“提供的网络”标识。此处定义了一类特殊的值以供使用，因为可能无法使用与UA可用的值相同的粒度：“3GPP-GERAN”、“3GPP-UTRAN”、“3GPP-WLAN”、“3GPP-GAN”和“3GPP-HSPA”。出站代理删除包含“网络提供”值的P-Access-Network-Info头字段。
8. Definition of additional parameters to the P-Charging-Vector header field: Section 5.6 of RFC 3455 defines the syntax of the P-Charging-Vector header field. Additional parameters were considered too application specific for specification in RFC 3455, but it was acknowledged that they would exist, and indeed additional specification of such parameters, relating to specific access technologies, has occurred in 3GPP. Therefore, this update states that applications using the P-Charging-Vector header field within their own applicability are allowed to define generic-param extensions without further reference to the IETF specification process.
8. P-Charging-Vector标头字段附加参数的定义：RFC 3455第5.6节定义了P-Charging-Vector标头字段的语法。对于RFC 3455中的规范来说，附加参数被认为过于特定于应用，但是已经承认它们将存在，并且确实，与特定接入技术相关的此类参数的附加规范已经在3GPP中出现。因此，本更新声明，允许在其自身适用范围内使用P-Charging-Vector报头字段的应用程序定义通用参数扩展，而无需进一步参考IETF规范过程。
9. In Section 5.7, it was added that the P-Called-Party-ID can appear in the PUBLISH method.
9. 在第5.7节中，添加了P-Party-ID可以出现在发布方法中。
10. Referencing: RFC 3427 was deleted from the References section as it was not used within the document. Various informative references have now been published as RFCs and have been updated to include the appropriate RFC number. References to 3GPP TS 32.200 were replaced by references to 3GPP TS 32.240 [TS32.240], which is the successor specification. References to 3GPP TS 32.225 were replaced by references to 3GPP TS 32.260 [TS32.260], which is the successor specification. The referencing style was changed to symbolic references. Dates have been removed from all 3GPP references (i.e., latest version applies).
10. 参考：RFC 3427已从参考部分删除，因为它未在文档中使用。各种信息性参考文献现已作为RFC发布，并已更新，以包括适当的RFC编号。对3GPP TS 32.200的引用被对3GPP TS 32.240[TS32.240]的引用所取代，后者是后续规范。对3GPP TS 32.225的引用被对3GPP TS 32.260[TS32.260]的引用所取代，后者是后续规范。引用样式已更改为符号引用。日期已从所有3GPP参考中删除（即，最新版本适用）。
11. Various editorial changes in alignment with style used in RFC 3261 such as placing response code text in parentheses and using words "request" and "response" in association with method names have been applied.
11. 与RFC 3261中使用的样式一致的各种编辑更改，例如将响应代码文本放在括号中，并将“请求”和“响应”与方法名称关联使用。
Authors' Addresses
作者地址
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
罗兰·杰西克德国电信海因里希·赫兹大街3-7号达姆施塔特64307德国
Phone: +4961515812766
EMail: r.jesske@telekom.de
Phone: +4961515812766
EMail: r.jesske@telekom.de
Keith Drage Alcatel-Lucent Quadrant, StoneHill Green, Westlea Swindon, Wilts UK
基思·德拉吉·阿尔卡特·朗讯象限，英国威尔特郡斯温顿威斯特利亚斯通希尔格林
EMail: drage@alcatel-lucent.com
EMail: drage@alcatel-lucent.com
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com