Network Working Group M. Garcia-Martin
Request for Comments: 3455 Ericsson
Category: Informational E. Henrikson
Lucent
D. Mills
Vodafone
January 2003
Network Working Group M. Garcia-Martin
Request for Comments: 3455 Ericsson
Category: Informational E. Henrikson
Lucent
D. Mills
Vodafone
January 2003
Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
第三代合作伙伴关系项目（3GPP）会话启动协议（SIP）的专用报头（P-Header）扩展
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.
本文档描述了第三代合作伙伴关系项目（3GPP）使用的一组专用会话发起协议（SIP）头（P头），以及它们的适用性，这些适用性仅限于特定环境。P-header在合作伙伴使用的网络中用于各种目的，包括计费和关于呼叫所经过网络的信息。
Table of Contents
目录
1. Overall Applicability . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SIP Private Headers . . . . . . . . . . . . . . . . . . . . . 3
4.1 The P-Associated-URI header. . . . . . . . . . . . . . . . 3
4.1.1 Applicability statement for the
P-Associated-URI header. . . . . . . . . . . . . . . 4
4.1.2 Usage of the P-Associated-URI header . . . . . . . . 4
4.2 The P-Called-Party-ID header . . . . . . . . . . . . . . . 6
4.2.1 Applicability statement for the
P-Called-Party-ID header. . . . . . . . . . . . . . . 9
4.2.2 Usage of the P-Called-Party-ID header. . . . . . . . 10
4.3 The P-Visited-Network-ID header. . . . . . . . . . . . . . 11
4.3.1 Applicability statement for the
P-Visited-Network-ID header. . . . . . . . . . . . . 11
1. Overall Applicability . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SIP Private Headers . . . . . . . . . . . . . . . . . . . . . 3
4.1 The P-Associated-URI header. . . . . . . . . . . . . . . . 3
4.1.1 Applicability statement for the
P-Associated-URI header. . . . . . . . . . . . . . . 4
4.1.2 Usage of the P-Associated-URI header . . . . . . . . 4
4.2 The P-Called-Party-ID header . . . . . . . . . . . . . . . 6
4.2.1 Applicability statement for the
P-Called-Party-ID header. . . . . . . . . . . . . . . 9
4.2.2 Usage of the P-Called-Party-ID header. . . . . . . . 10
4.3 The P-Visited-Network-ID header. . . . . . . . . . . . . . 11
4.3.1 Applicability statement for the
P-Visited-Network-ID header. . . . . . . . . . . . . 11
4.3.2 Usage of the P-Visited-Network-ID header . . . . . . 12
4.4 The P-Access-Network-Info header . . . . . . . . . . . . . 15
4.4.1 Applicability Statement for the
P-Access-Network-Info header . . . . . . . . . . . . 16
4.4.2 Usage of the P-Access-Network-Info header . . . . . 17
4.5 The P-Charging-Function-Addresses header . . . . . . . . . 18
4.5.1 Applicability Statement for the
P-Charging-Function-Addresses header . . . . . . . . 18
4.5.2 Usage of the P-Charging-Function-Addresses
headerd. . . . . . . . . . . . . . . . . . . . . . . 19
4.6 The P-Charging-Vector header . . . . . . . . . . . . . . . 21
4.6.1 Applicability Statement for the
P-Charging-Vector header . . . . . . . . . . . . . . 22
4.6.2 Usage of the P-Charging-Vector header . . . . . . . 23
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 P-Associated-URI header syntax . . . . . . . . . . . . . . 25
5.2 P-Called-Party-ID header syntax. . . . . . . . . . . . . . 25
5.3 P-Visited-Network-ID header syntax . . . . . . . . . . . . 25
5.4 P-Access-Network-Info header syntax. . . . . . . . . . . . 25
5.5 P-Charging-Function-Addresses header syntax. . . . . . . . 26
5.6 P-Charging-Vector header syntax. . . . . . . . . . . . . . 26
5.7 Table of new headers . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 28
6.2 P-Called-Party-ID. . . . . . . . . . . . . . . . . . . . . 28
6.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 28
6.4 P-Access-Network-Info. . . . . . . . . . . . . . . . . . . 29
6.5 P-Charging-Function-Addresses. . . . . . . . . . . . . . . 30
6.6 P-Charging-Vector. . . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 30
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34
4.3.2 Usage of the P-Visited-Network-ID header . . . . . . 12
4.4 The P-Access-Network-Info header . . . . . . . . . . . . . 15
4.4.1 Applicability Statement for the
P-Access-Network-Info header . . . . . . . . . . . . 16
4.4.2 Usage of the P-Access-Network-Info header . . . . . 17
4.5 The P-Charging-Function-Addresses header . . . . . . . . . 18
4.5.1 Applicability Statement for the
P-Charging-Function-Addresses header . . . . . . . . 18
4.5.2 Usage of the P-Charging-Function-Addresses
headerd. . . . . . . . . . . . . . . . . . . . . . . 19
4.6 The P-Charging-Vector header . . . . . . . . . . . . . . . 21
4.6.1 Applicability Statement for the
P-Charging-Vector header . . . . . . . . . . . . . . 22
4.6.2 Usage of the P-Charging-Vector header . . . . . . . 23
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 P-Associated-URI header syntax . . . . . . . . . . . . . . 25
5.2 P-Called-Party-ID header syntax. . . . . . . . . . . . . . 25
5.3 P-Visited-Network-ID header syntax . . . . . . . . . . . . 25
5.4 P-Access-Network-Info header syntax. . . . . . . . . . . . 25
5.5 P-Charging-Function-Addresses header syntax. . . . . . . . 26
5.6 P-Charging-Vector header syntax. . . . . . . . . . . . . . 26
5.7 Table of new headers . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 28
6.2 P-Called-Party-ID. . . . . . . . . . . . . . . . . . . . . 28
6.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 28
6.4 P-Access-Network-Info. . . . . . . . . . . . . . . . . . . 29
6.5 P-Charging-Function-Addresses. . . . . . . . . . . . . . . 30
6.6 P-Charging-Vector. . . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 30
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34
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 are generally NOT APPLICABLE in the Internet as a whole. The mechanisms specified here were designed to satisfy the requirements specified in the 3GPP Release 5 requirements on SIP [4] for which either no general-purpose solution was planned, where insufficient operational experience was available to understand if a general solution is needed, or where 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和较低层之间的链接以及可传递信任的可用性做出了某些假设。这些假设通常不适用于整个互联网。此处规定的机制旨在满足3GPP第5版SIP[4]要求中规定的要求，该要求或未规划通用解决方案，或操作经验不足，无法理解是否需要通用解决方案，或更通用的解决方案尚未成熟。有关这些扩展的假设的更多详细信息，请参阅每个扩展的适用性小节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
The Third Generation Partnership Project (3GPP) has selected SIP as the protocol used to establish and tear down multimedia sessions in the context of its IP Multimedia Subsystem (IMS). (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [14] and 3GPP TS 24.229 [15]). 3GPP notified the IETF SIP and SIPPING working groups that existing SIP documents provided almost all the functionality needed to satisfy the requirements of the IMS, but that they required some additional functionality in order to use SIP for this purpose. These requirements [4] are documented in an Internet Draft which was submitted to the SIPPING Working Group. Some of these requirements are satisfied by chartered extensions, while other requirements were applicable to SIP, but not sufficiently general for the SIP Working Group to adopt. This document describes private extensions to address those requirements. Each extension, or set of related extensions is described in its own section below.
第三代合作伙伴计划（3GPP）选择SIP作为用于在其IP多媒体子系统（IMS）的上下文中建立和中断多媒体会话的协议。（有关IMS的更多信息，请参见3GPP TS 23.228[14]和3GPP TS 24.229[15]）。3GPP通知IETF SIP和SIPPING工作组，现有SIP文档提供了满足IMS需求所需的几乎所有功能，但它们需要一些额外的功能才能将SIP用于此目的。这些要求[4]记录在提交给啜饮工作组的互联网草案中。其中一些要求通过特许扩展得到满足，而其他要求则适用于SIP，但不足以使SIP工作组采用。本文档描述了满足这些需求的专用扩展。每个扩展或一组相关的扩展在下面自己的部分中进行了描述。
This extension allows a registrar to return a set of associated URIs for a registered 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 transports the set of Associated URIs to the registered address-of-record.
此扩展允许注册器为已注册的记录地址返回一组关联的URI。我们定义了P-Associated-URI头字段，用于对寄存器请求的200ok响应。P-Associated-URI头字段将关联的URI集传输到记录的注册地址。
An associated URI is a URI that the service provider has allocated to a user for his own usage. A registrar contains information that allows an address-of-record URI to be associated with zero or more URIs. Usually, all these URIs (the address-of-record URI and the associated URIs) are allocated for the usage of a particular user. This extension to SIP allows the UAC to know, upon a successful authenticated registration, which other URIs, if any, the service provider has associated to an address-of-record URI.
关联URI是服务提供商分配给用户供其使用的URI。注册器包含允许记录URI的地址与零个或多个URI关联的信息。通常，所有这些URI（记录URI的地址和关联的URI）都分配给特定用户使用。SIP的这个扩展允许UAC在成功的身份验证注册后知道服务提供者与记录URI地址相关联的其他URI（如果有的话）。
Note that, generally speaking, the registrar does not register the associated URIs on behalf of the user. Only the address-of-record which 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 to be used by the same user.
注意，一般来说，注册器并不代表用户注册关联的uri。只有寄存器的“收件人”头字段中的记录地址才被注册并绑定到联系人地址。传达的唯一信息是，注册器知道同一用户将使用其他URI。
It may be possible, however, that 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. The 200 OK response will include a Contact header with the list of registered contact addresses. If the associated URI is not registered, the UA MAY register it prior to its utilization.
如果UAC想要检查是否注册了任何关联的URI，它可以通过在本文档之外指定的机制来进行检查，例如，UA可以向任何关联的URI发送一个注册请求，其中to头字段值被设置为任何关联的URI，并且没有联系人头。200 OK响应将包括带有已注册联系人地址列表的联系人标题。如果相关联的URI没有注册，UA可以在其使用之前注册它。
The P-Associated-URI header is applicable in SIP networks where the SIP provider is allocating the set of identities that a user can claim (in headers like the From field) in requests that the UA generates. It furthermore 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 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 containing zero or more URIs that are associated to the address-of-record.
注册器将P-Associated-URI头字段插入到对注册请求的200ok响应中。标头字段值由包含与记录地址关联的零个或多个URI的列表填充。
If the registrar supports the P-Associated-URI header extension, then the registrar MUST always insert the P-Associated-URI header field in all the 200 OK responses to a REGISTER request, regardless of whether the REGISTER was an initial registration, re-registration, or de-registration and regardless of whether there are zero or more associated URIs.
如果注册器支持P-Associated-URI报头扩展，那么注册器必须始终在对注册请求的所有200个OK响应中插入P-Associated-URI报头字段，而不管该注册器是否为初始注册、重新注册，或取消注册，而不管是否有零个或多个关联URI。
A UAC may receive a P-Associated-URI header field in the 200 OK response for a REGISTER. The presence of the 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响应中存在header字段意味着注册器支持扩展。
The header value contains a list of zero or more associated URIs to the address-of-record URI. The UAC MAY use any of the associated URIs to populate the From header value, or any other SIP header value that provides information of the identity of the calling party, in a subsequent request.
标头值包含与记录URI地址相关联的零个或多个URI的列表。UAC可以在后续请求中使用任何相关联的URI来填充From报头值，或者填充提供呼叫方身份信息的任何其他SIP报头值。
The UAC MAY check whether the associated URI is registered or not. This check can be done, e.g., by populating the To header value in a REGISTER sent to the registrar and without a Contact header. The 200 OK response will include a Contact header with the list of registered contact addresses. As described in SIP [1], the 200 OK response may contain a Contact header field with zero or more values (zero meaning the address-of-record is not registered).
UAC可以检查关联的URI是否已注册。例如，可以通过在发送给注册器且没有联系人标头的寄存器中填充To标头值来完成此检查。200 OK响应将包括带有已注册联系人地址列表的联系人标题。如SIP[1]中所述，200 OK响应可能包含一个具有零或多个值的联系人标头字段（零表示记录地址未注册）。
A registrar that receives and authorizes a REGISTER request, may associate zero or more URIs with the address-of-record.
接收并授权注册请求的注册官可以将零个或多个URI与记录地址关联。
A registrar that supports this specification MUST include a P-Associated-URI header field in the 200 OK response to a REGISTER request. The header MUST be populated with a comma-separated list of SIP or SIPS URIs which are associated to the address-of-record under registration.
支持此规范的注册器必须在对注册请求的200 OK响应中包含一个P-Associated-URI头字段。必须使用与注册记录地址相关联的SIP或SIPS URI的逗号分隔列表填充标题。
In case the address-of-record under registration does not have any other SIP or SIPS URIs associated, the registrar MUST include an empty P-Associated-URI header value.
如果注册中记录的地址没有任何其他SIP或SIPS URI关联，则注册器必须包含空的P-associated-URI头值。
This memo does not define any procedure at the proxy.
本备忘录未定义代理的任何程序。
A proxy server inserts a P-Called-Party-ID header, 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 UAS identifies which address-of-record, out of several registered address-of-records, the invitation was sent to (for example, the user may be simultaneously using a personal and a business SIP URIs to receive invitation to sessions). The UAS may 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来接收会话邀请）。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 instance, a user may get a business SIP URI and a personal one. As an example of utilization, the user may make available the business SIP URI to co-workers 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 several 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 [4].
该要求在SIP[4]的3GPP第5版要求中有说明。
The problem arises during the terminating side of a session establishment, when the SIP proxy that is serving a UA gets an INVITE, and the SIP server retargets the SIP URI which is present in the Request-URI field, and replaces it by the SIP URI published by the user in the Contact header field of the REGISTER request at registration time. When the UAS receives the SIP INVITE, it cannot determine which address-of-record the request was sent to.
在会话建立的终止端期间，当服务于UA的SIP代理获得INVITE时，问题出现，并且SIP服务器重定存在于请求URI字段中的SIP URI的目标，并用用户在注册时在注册请求的联系人报头字段中发布的SIP URI替换它。当UAS收到SIP INVITE时，它无法确定将请求发送到哪个记录地址。
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 which 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 which address-of-record the session was destined.
使用To header字段的问题在于，该字段由UAC填充，而不是由路径中的代理修改。如果UAC出于任何原因没有将目标用户的记录地址填充到To header字段中，则目标用户无法区分会话的目标记录地址。
Another possible solution to the problem is built upon the differentiation of the Contact header 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 value. For instance, when the UA registers the address-of-record sip:id1, the Contact header value can be sip:id1@ua; the registration of sip:id2 can be bound to the Contact 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 address-of-record URIs, and therefore, it has full control over the contact address values assigned to each registration. However, in the case the UA does not have full control of its registered address-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 the network, by means outside of SIP, that some other address-of-record URIs 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 [4].
上述解决方案假设UA显式注册其记录URI的每个地址，因此，它可以完全控制分配给每个注册的联系人地址值。但是，如果UA因第三方注册等原因无法完全控制其注册记录地址，则解决方案不起作用。这可能是3GPP注册的情况，其中UA可能先前通过SIP之外的方式指示网络，当UA注册特定的记录地址时，可以自动注册某个其他记录地址uri。该要求包含在SIP[4]的3GPP第5版要求中。
In the next paragraphs we show an example of the problem, in the case 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.
在接下来的段落中，我们将展示一个问题示例，在会话中出现了某种呼叫转发，因此UAC不知道当前INVITE中的目标URI。
We assume that a User Agent (UA) is registering to his 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 from another proxy (P2) destined to the user's business SIP address-of-record. We assume that this SIP INVITE 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）的邀请。我们假设这个SIP 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 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, 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 or 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 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 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 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 specially valuable when the UAS has registered several address-of-record URIs 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向其注册官注册了多个记录地址URI时，这一点特别重要，因此，除非使用此扩展，否则UAS不知道INVITE请求中出现的记录地址。
Requirements for a more general solution are proposed in [12], but have not been adopted by SIP, nor a solution has been developed.
[12]中提出了更通用解决方案的要求，但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 prior to retargetting the Request-URI in the SIP request. The header value is populated with the contents of Request-URI, prior to replacing it with the Contact address.
通常，SIP代理在SIP请求中重新定位请求URI之前插入P-Call-Party-ID头。在将头值替换为联系人地址之前，先用请求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 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, MAY insert a P-Called-Party-ID header field in any of the requests indicated in the Table 1 (Section 5.7). The proxy MUST populate the header value with the contents of the Request-URI present in the SIP request that the proxy received.
有权访问用户联系信息的代理可以在表1（第5.7节）所示的任何请求中插入P-Call-Party-ID头字段。代理必须使用代理收到的SIP请求中存在的请求URI的内容填充头值。
It is necessary that the proxy which inserts the P-Called-Party-ID header has information about the user, in order to prevent a wrong delivery of the called party ID. This information may have been learned through a registration process, for instance.
插入P-Call-Party-ID头的代理必须具有有关用户的信息，以防止错误传递被叫方ID。例如，该信息可能是通过注册过程获知的。
A proxy or application server that receives a request containing a P-Called-Party-ID header may use the contents of the header to provide a service to the user based on the URI of that header value.
接收包含P-call-Party-ID报头的请求的代理或应用服务器可以使用报头的内容基于该报头值的URI向用户提供服务。
A SIP proxy MUST NOT insert a P-Called-Party-ID header 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. This has the effect 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 one 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 at the home network. This identification should be globally unique, and 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用户代理始终注册到家庭网络。注册请求由位于到访网络中朝向家庭网络的一个或多个代理来代理。为了简单的方法，访问的网络包括在家庭网络中已知的标识似乎是明智的。此标识应该是全局唯一的，并采用带引号的文本字符串或标记的形式。归属网络可使用该标识来验证与到访网络的漫游协议的存在，并通过该到访网络授权注册。
The P-Visited-Network-ID 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, and generally supported by the use of standard security mechanisms, e.g., IPsec, AKA, or 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 needs to be identified at the home network. Those networks that want to be identified make use of the extension defined in this document. 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 or dialog-initiating request (e.g., INVITE) or a standalone request outside a dialog (e.g., OPTIONS) to a proxy in a visited network.
6. UAC向访问的网络中的代理发送寄存器或对话框启动请求（例如，INVITE）或对话框外部的独立请求（例如，选项）。
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 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 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 that receives any of the requests indicated in Table 1 (Section 5.7) MAY insert a P-Visited-Network-ID header when it forwards the request. In case a REGISTER 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 if the request does not contain a P-Visited-Network-ID header with the same network identifier as its own network identifier (e.g., if the request has traversed other different administrative domains).
接收表1（第5.7节）中所示任何请求的任何SIP代理在转发请求时都可以插入P-Visited-Network-ID头。如果寄存器或其他请求正在穿越不同的管理域（例如，不同的访问网络），则如果请求不包含具有与其自身网络标识符相同的网络标识符的P-visted-Network-ID报头，则SIP代理可以插入新的P-visted-Network-ID报头（例如，如果请求已穿越其他不同的管理域）。
Note also that, there is not requirement for the header value to be readable in the proxies. Therefore, a first proxy may insert an encrypted header 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. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header, and therefore, it will insert a new P-Visited-Network-ID header 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 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 is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy
P-visted-Network-ID通常用于注册。但是，此扩展并不排除其他用途。例如，代理
located in a visited network that does not maintain registration state may insert a P-Visited-Network-ID header 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 [1], SUBSCRIBE [6] and REFER [11].
位于未保持注册状态的已访问网络中的用户可以在对话框外部的任何独立请求或创建对话框的请求中插入P-visted-network-ID头。在编写本文档时，创建对话框的请求只有INVITE[1]、SUBSCRIBE[6]和reference[11]。
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. The identifier should be a globally unique to avoid duplications. Although there are many mechanism to create globally unique identifiers across networks, one of such as mechanisms is already in operation, and that is DNS. The P-Visited-Network-ID does not have any connection to DNS, but the values in the header can be chosen from the own DNS entry representing the domain name of the network. This guarantees the uniqueness of the value.
为了避免与标识符发生冲突，特别是当网络之间的漫游协议数量增加时，在选择P-VISTER-Network-ID的值时必须小心。标识符应是全局唯一的，以避免重复。尽管有许多机制可以跨网络创建全局唯一标识符，但其中一种机制已经在运行，即DNS。P-visted-Network-ID与DNS没有任何连接，但是可以从表示网络域名的自己的DNS条目中选择标头中的值。这保证了值的唯一性。
User agent clients SHOULD NOT insert a P-Visited-Network-ID header in any SIP message.
用户代理客户端不应在任何SIP消息中插入P-visted-Network-ID头。
A SIP proxy which is located in a visited network MAY insert a P-Visited-Network-ID header field in any of the requests indicated in the Table 1 (Section 5.7). The header 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 at the user's home network.
位于受访网络中的SIP代理可以在表1（第5.7节）中指示的任何请求中插入P-VISTER-network-ID头字段。标头必须填充文本字符串或令牌的内容，以标识代理在用户家庭网络上运行的网络的管理域。
A SIP proxy or registrar which is located in the home network may use the contents of the P-Visited-Network-ID 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 not of a roaming agreement between the home and the visited networks. This means, for instance, authorize the actions of the request based on the contents of the P-Visited-Network-ID header.
位于家庭网络中的SIP代理或注册器可以使用P-visted-network-ID的内容作为请求所穿越的一个或多个到访网络的标识符。归属网络中的代理或注册器可基于归属网络与到访网络之间是否存在漫游协议而采取本地策略驱动的动作。这意味着，例如，基于P-visted-Network-ID报头的内容授权请求的操作。
A SIP proxy which is located in the home network MUST delete this header when forwarding the message outside the home network administrative domain, in order to retain the user's privacy.
当在家庭网络管理域之外转发消息时，位于家庭网络中的SIP代理必须删除此报头，以保留用户的隐私。
A SIP proxy which is located in the home network SHOULD delete this header when the home proxy has used the contents of the header or the request is routed based on the called party, even when the request is not forwarded outside the home network administrative domain.
当家庭代理使用了报头的内容或请求基于被叫方路由时，即使请求未转发到家庭网络管理域之外，位于家庭网络中的SIP代理也应删除该报头。
We present example in the context of the scenario presented in the following network diagram:
我们在以下网络图中所示场景的上下文中提供示例：
Scenario UA --- P1 --- P2 --- REGISTRAR
Scenario UA --- P1 --- P2 --- REGISTRAR
This example shows the message sequence for an REGISTER transaction originating from UA1 eventually arriving at REGISTRAR. P1 is an outbound proxy for UA1. In this case P1 also inserts the P-Visited-Network-ID header. P1 then routes the REGISTER request to the Registrar via P2.
此示例显示源自UA1并最终到达注册器的注册事务的消息序列。P1是UA1的出站代理。在这种情况下，P1还插入P-visted-Network-ID报头。P1然后通过P2将注册请求路由到注册器。
Message sequence for REGISTER using P-Visited-Network-ID header:
使用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 P2 adds its own identifier to the P-Visited-Network-ID header.
在流F2中，代理P2将其自己的标识符添加到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=z9hG4bKnashdt8
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=z9hG4bKnashdt8
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 his own identifier, derived from its own domain name.
最后，在流F3中，代理P2决定插入他自己的标识符，该标识符来自其自己的域名。
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=z9hG4bKnashdt8
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=z9hG4bKnashdt8
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. This header is useful in SIP-based networks that also provide layer 2/layer 3 connectivity through different access technologies. SIP User Agents may use this header 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 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层/第3层连接。SIP用户代理可以使用该报头将关于接入技术的信息中继到提供服务的代理。然后，服务代理可以使用该信息来优化UA的服务。例如，3GPP UA可以使用该报头将关于接入网络的信息（例如无线接入技术和无线小区标识）传递给其家庭服务提供商。
For the purpose of this extension, we define an access network as the network providing the layer 2/layer 3 IP connectivity which in turn provides a user with access to the SIP capabilities and services provided.
出于此扩展的目的，我们将接入网络定义为提供第2层/第3层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
在某些情况下，向用户提供服务的SIP服务器可能希望知道关于UA当前使用的接入网络类型的信息。有些服务更适合或不适合
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 which provides the user with services.
根据接入类型而定，如果为用户提供服务的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 knowledge about the access network. This is achieved by defining a new private SIP extension header, P-Access-Network-Info. This header 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及其在家庭网络中的服务代理之间的接入网络相关的信息。
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 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. 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 which 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 into 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, this proxy strips the header from the message.
当UA生成SIP请求或响应时，它知道该请求或响应将被安全地发送到其提供服务的SIP代理，UA将P-Access-Network-Info报头插入SIP消息中。此标头包含UA用于获取IP连接的接入网络信息。UA和提供服务的SIP代理之间的中间代理通常会忽略报头。提供服务的代理可以检查报头，并根据报头的值利用其中包含的信息提供适当的服务。在代理请求之前，此代理会将消息头从消息中剥离。
A UA that supports this extension and is willing to disclose the related parameters MAY insert the P-Access-Network-Info header in any SIP request or response.
支持该扩展并且愿意公开相关参数的UA可以在任何SIP请求或响应中插入P-Access-Network-Info报头。
The UA inserting this information MUST trust 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 do 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 insert or modify the value of the P-Access-Network-Info header.
代理不得插入或修改P-Access-Network-Info标头的值。
A proxy which is providing services to the UA, may act upon any information present in the P-Access-Network-Info header 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, the proxy typically located in the home network, and therefore trusted, MUST delete the header when the SIP signaling is forwarded to a SIP server located in
向用户提供服务的代理（通常位于家庭网络中，因此受信任）必须在SIP信令转发到位于家庭网络中的SIP服务器时删除报头
a non-trusted administrative network domain. The SIP server providing services to the UA uses the access network information and is of no interest to other proxies located in different administrative domains.
不受信任的管理网络域。向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 off-line charging (e.g., for postpaid account charging). ECF is used for on-line 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. 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.200 [16] and 3GPP TS 32.225 [17].
3GPP提供的解决方案是定义两种类型的计费功能实体：计费收集功能（CCF）和事件计费功能（ECF）。CCF用于离线收费（例如，用于支付后账户收费）。ECF用于在线收费（例如，预付费账户收费）。为了在网络中提供冗余，网络中可能有多个CCF和ECF实例。如果CCF或ECF地址存在多个实例，则实施应尝试将计费数据发送到ECF或CCF地址，从P-charging-Function-addresses报头中序列的第一个地址（如果有）开始。CCF和ECF地址可以在建立对话框期间或在独立事务中传递。有关充电的更多详细信息，请参见3GPP TS 32.200[16]和3GPP TS 32.225[17]。
We define the SIP private header P-Charging-Function-Addresses. 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. 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 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
4.5.1 P-Charging-Function-Addresses标头的适用性声明
The P-Charging-Function-Addresses header 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.200 [16].
P-Charging-Function-Addresses报头适用于需要协调计费的单个私有管理域，例如，根据3GPP TS 32.200[16]中规定的架构。
The P-Charging-Function-Addresses header 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.
在自己的管理域之外发送的SIP消息中不包括P-Charging-Function-Addresses标头。如果管理域不提供计费功能，则标头不适用。
The P-Charging-Function-Addresses header 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) or a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UA向位于专用网络管理域中的代理发送寄存器或对话框启动请求（例如，INVITE）或对话框外部的独立事务请求。
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 located in the same administrative domain of the private network, that are generated 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 prior to forwarding the request, if the header was not already present in the SIP request. The header value 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 may 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, with regard to the P-Charging-Function-Addresses header. 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 PSTN gateway, or conference mixer), and it may have access to the addresses of the charging entities. In this cases, a UA MAY insert the P-Charging-Function-Addresses header in a SIP request or response when the next hop for the message is a proxy located in the same administrative domain.
然而，UA可能位于专用网络（例如，PSTN网关或会议混频器）的管理域内，并且它可能可以访问计费实体的地址。在这种情况下，当消息的下一跳是位于同一管理域中的代理时，UA可以在SIP请求或响应中插入P-Charging-Function-Addresses报头。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Function-Addresses MAY insert a P-Charging-Function-Addresses header 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, 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 administrative domain of the proxy, then the proxy SHOULD include the P-Charging-Function-Addresses header 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.
如果支持此扩展的代理接收到带有P-Charging-Function-Addresses的请求或响应，则它可以从报头值中检索信息，以用于特定于应用程序的逻辑，即充电。如果消息的下一个跃点位于代理的管理域内，则代理应在出站消息中包含P-Charging-Function-Addresses头。但是，如果消息的下一个跃点位于代理的管理域之外，则代理必须删除P-Charging-Function-Addresses标头。
We present example in the context of the scenario presented in the following network diagram:
我们在以下网络图中所示场景的上下文中提供示例：
Scenario UA1 --- P1 --- P2 --- UA2
Scenario UA1 --- P1 --- P2 --- UA2
In the 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 eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case P1 also inserts charging information. P1 then routes the call via P2 to UA2.
下面的示例显示了源自UA1并最终到达UA2的INVITE事务的消息序列。P1是UA1的出站代理。在这种情况下，P1还插入充电信息。P1然后通过P2将呼叫路由到UA2。
Message sequence for INVITE using P-Charging-Function-Addresses:
使用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:ua1home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Function-Addresses: ccf=192.1.1.1; ccf=192.1.1.2;
ecf=192.1.1.3; ecf=192.1.1.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:ua1home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Function-Addresses: ccf=192.1.1.1; ccf=192.1.1.2;
ecf=192.1.1.3; ecf=192.1.1.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 it is not limited to, a globally unique charging identifier that makes easy the billing effort.
相关信息包括但不限于全球唯一的计费标识符，该标识符便于计费工作。
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 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 Identifiers (IOI).
充电向量定义为充电信息的集合。收费向量可以在建立对话框或对话框外部的独立事务期间填写。计费向量内的信息可由多个网络实体（包括SIP代理）填充并由多个网络实体检索。有三种类型的相关信息需要传输：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 host name 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 an IOI generated from each side of the dialog to identify the network associated with each side.
IOI标识SIP对话或对话外部事务中涉及的发起和终止网络。可以从对话框的每一侧生成IOI，以标识与每一侧关联的网络。
There is also expected to be access network charging information, which consists of network specific identifiers for the access level (e.g., 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. 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. 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 in the P-Charging-Vector are outside the scope of this document.
SIP代理收集要填充到P-Charging-Vector中的值的机制不在本文档的范围内。
The P-Charging-Vector header 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 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 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 a standalone transaction request outside a dialog to a proxy located in the administrative domain of a private network.
1. UA向位于专用网络管理域中的代理发送寄存器或对话框启动请求（例如，INVITE）或对话框外部的独立事务请求。
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 request and responses are traversed through, en-route to 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 is used to convey charging related information, such as the globally unique IMS charging identifier (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 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 may 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 the UA, with regard to the P-Charging-Vector header. UAs need not understand this header.
本文件未规定UA关于P-Charging-Vector报头的任何程序。UAs不需要理解此标题。
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Vector header MAY insert a P-Charging-Vector header prior to forwarding the message. The header is populated with one ore 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, 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
如果支持此扩展的代理接收到带有P-Charging-Vector报头的请求或响应，则它可以从报头值检索信息，以用于特定于应用程序的逻辑，即充电。如果消息的下一个跃点位于受信任域内，那么代理应该包括P-Charging-Vector
header 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.
出站消息中的标头。如果消息的下一个跃点位于受信任域之外，则代理可能会删除P-Charging-Function-Addresses标头。
Per local application specific logic, the proxy MAY modify the contents of the P-Charging-Vector header prior to sending the message.
根据本地应用程序特定逻辑，代理可以在发送消息之前修改P-Vector报头的内容。
We present example in the context of the scenario presented 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 eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case P1 also inserts charging information. P1 then routes the call via P2 to UA2.
此示例显示源自UA1并最终到达UA2的INVITE事务的消息序列。P1是UA1的出站代理。在这种情况下，P1还插入充电信息。P1然后通过P2将呼叫路由到UA2。
Message sequence for INVITE using P-Charging-Vector:
使用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
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
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
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [3]. 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 [1] and RFC 2234 [3] to understand this document.
本文件中规定的所有机制均以散文和RFC 2234[3]中定义的增广巴科斯诺尔形式（BNF）进行了描述。此外，几个BNF定义是从SIP继承的，这里不再重复。实施者需要熟悉SIP[1]和RFC 2234[3]的符号和内容才能理解本文档。
The syntax of the P-Associated-URI header 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=名称addr*（半人工智能参数）人工智能参数=通用参数
The syntax of the P-Called-Party-ID header 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 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 is described as follows:
P-Access-Network-Info标头的语法描述如下：
P-Access-Network-Info = "P-Access-Network-Info" HCOLON access-net-spec access-net-spec = access-type *(SEMI access-info)
P-Access-Network-Info=“P-Access-Network-Info”HCOLON访问网络规范访问网络规范=访问类型*（半访问信息）
access-type = "IEEE-802.11a" / "IEEE-802.11b" /
"3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN-TDD" /
"3GPP-CDMA2000" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
extension-access-info
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)
access-type = "IEEE-802.11a" / "IEEE-802.11b" /
"3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN-TDD" /
"3GPP-CDMA2000" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
extension-access-info
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)
The access-info may contain additional information relating to the access network. The values for "cgi-3gpp" and "utran-cell-id-3gpp" are defined in 3GPP TS 24.229 [15].
接入信息可以包含与接入网络相关的附加信息。3gpp TS 24.229[15]中定义了“cgi-3gpp”和“utran-cell-id-3gpp”的值。
The syntax for the P-Charging-Function-Addresses header is described as follows:
P-Charging-Function-Addresses标头的语法描述如下：
P-Charging-Addr = "P-Charging-Function-Addresses" HCOLON charge-addr-params *(SEMI charge-addr-params) charge-addr-params = ccf / ecf / generic-param ccf = "ccf" EQUAL gen-value ecf = "ecf" EQUAL gen-value
P-Charging-Addr=“P-Charging-Function-address”HCOLON charge Addr params*（半charge Addr params）charge Addr params=ccf/ecf/generic param ccf=“ccf”等发电价值ecf=“ecf”等发电价值
The syntax for the P-Charging-Vector header is described as follows:
P-Vector报头的语法描述如下：
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value
*(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi /
term-ioi / 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
P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value
*(SEMI charge-params)
charge-params = icid-gen-addr / orig-ioi /
term-ioi / 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
The P-Charging-Vector contains icid-value 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 host name or IP address of the proxy that generated the icid-value.
icid gen addr参数包含生成icid值的代理的主机名或IP地址。
The orig-ioi and term-ioi parameters represent, respectively, the 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表示负责会话或独立请求的终止部分中的计费记录的网络。
Table 1 extends the headers defined in this document to Table 2 in SIP [1], section 7.1 of the SIP-specific event notification [6], tables 1 and 2 in the SIP INFO method [8], tables 1 and 2 in Reliability of provisional responses in SIP [7], tables 1 and 2 in the SIP UPDATE method [9], tables 1 and 2 in the SIP extension for Instant Messaging [10], and table 1 in the SIP REFER method [11]:
表1将本文件中定义的标题扩展到SIP[1]中的表2、SIP特定事件通知[6]第7.1节、SIP信息方法[8]中的表1和表2、SIP[7]中临时响应可靠性中的表1和表2、SIP更新方法[9]中的表1和表2、即时消息SIP扩展[10]中的表1和表2，以及SIP参考方法[11]中的表1：
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Associated-URI 2xx - - - - - o
P-Called-Party-ID R amr - - - o o -
P-Visited-Network-ID R ad - - - o o o
P-Access-Network-Info dr - o - o o o
P-Charging-Vector admr - o - o o o
P-Charging-Function- adr - o - o o o
Addresses
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Associated-URI 2xx - - - - - o
P-Called-Party-ID R amr - - - o o -
P-Visited-Network-ID R ad - - - o o o
P-Access-Network-Info dr - o - o o o
P-Charging-Vector admr - o - o o o
P-Charging-Function- adr - o - o o o
Addresses
Header field SUB NOT PRA INF UPD MSG REF
___________________________________________________________
P-Associated-URI - - - - - - -
P-Called-Party-ID o - - - - o o
P-Visited-Network-ID o - - - - o o
P-Access-Network-Info o o o o o o o
P-Charging-Vector o o o o o o o
P-Charging-Function- o o o o o o o
Addresses
Header field SUB NOT PRA INF UPD MSG REF
___________________________________________________________
P-Associated-URI - - - - - - -
P-Called-Party-ID o - - - - o o
P-Visited-Network-ID o - - - - o o
P-Access-Network-Info o o o o o o o
P-Charging-Vector o o o o o o o
P-Charging-Function- o o o o o o o
Addresses
Table 1: Header field support
表1：标题字段支持
The information returned in the P-Associated-URI header 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. This attack, while potentially annoying, should not have significant impacts.
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 value. An eavesdropper could collect this information. If the user does not want to disclose the associated URIs, the eavesdropper could have gain access to private URIs. Therefore it is RECOMMENDED that this extension is used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop.
由于缺乏端到端或逐跳加密，可能会泄漏有关授权身份列表的一些隐私。例如，注册sip记录地址的用户：user1@example.com可能会获取另一个与SIP:first关联的SIP URI。last@example.com在P-Associated-URI头值中返回。窃听者可以收集这些信息。如果用户不想公开相关的URI，窃听者可以访问私有URI。因此，建议在安全环境中使用此扩展，在这种环境中，SIP消息的加密可以端到端或逐跳提供。
Due to the nature of the P-Called-Party-ID header, 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-call-Party-ID报头的性质，该报头不会引入任何重要的安全问题。攻击者有可能修改标头的内容。但是，此修改不会对会话建立造成任何损害。
An eavesdropper may collect the list of identities a user is registered. This may 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消息的加密提供端到端或逐跳。
The P-Visited-Network-ID header 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. Therefore intermediaries participating in this mechanism MUST apply a hop-by-hop integrity protection mechanism such us IPsec or other available mechanisms in order to prevent such attacks.
P-visted-Network-ID报头假定家庭网络和一个或多个转机访问的网络之间存在信任关系。在插入报头的到访网络中的代理和注册器或归属代理之间的其他代理可以修改P-visted-network-ID报头的值。因此，参与此机制的中介机构必须应用逐跳完整性保护机制，如us IPsec或其他可用机制，以防止此类攻击。
A Trust Domain is formally defined in the Short term requirements for Network Asserted Identity [13] document. For the purpose 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 [15].
信任域在网络断言身份的短期要求[13]文档中正式定义。在本文档中，我们将3GPP信任域称为由3GPP网络运营商操作并符合3GPP TS 24.229[15]中所述要求的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 should 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 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 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 SHOULD 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 SHOULD NOT send sensitive information in the P-Access-Network-Info header.
使用这个扩展而不是私有信任域的一部分的UA不应该认为该机制是安全的，因此不应该在P- Access NETWORK-FIN报头中发送敏感信息。
Any proxy that is operating in a private trust domain where the P-Access-Network-Info header 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头的私有信任域中运行的任何代理都需要在将消息转发到受信任域之外之前从任何消息中删除该头（如果存在）。
Therefore, a network that requires its UA to send information in the P-Access-Network-Info header must ensure that either that information is not of a sensitive nature or that the information is not sent outside of the trust domain.
因此，要求其UA在P-Access-network-Info报头中发送信息的网络必须确保该信息不具有敏感性质，或者该信息不发送到信任域之外。
A proxy receiving a message containing the P-Access-Network-Info header from a non-trusted entity is not able to guarantee the validity of the contents.
从不受信任的实体接收包含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 and insert it into a SIP request or response. However, these 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, 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 and insert it into a SIP request or response. However, these proxies that share this information MUST have a trust relationship.
通常情况下，封闭网络中的代理会修改P-Charging-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, 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-”开头）。
These extension headers have been included in the registry of SIP header fields defined in SIP [1]. Expert review as required for this process was provided by the SIP Working Group.
这些扩展头已包含在SIP[1]中定义的SIP头字段注册表中。SIP工作组提供了该过程所需的专家评审。
The following extensions are registered as private extension header fields:
以下扩展已注册为专用扩展标头字段：
RFC Number: RFC3455 Header Field Name: P-Associated-URI Compact Form: none
RFC编号：RFC3455标题字段名称：P-Associated-URI压缩格式：无
RFC Number: RFC3455 Header Field Name: P-Called-Party-ID Compact Form: none
RFC编号：RFC3455标题字段名称：P-Called-Party-ID紧凑格式：无
RFC Number: RFC3455 Header Field Name: P-Visited-Network-ID Compact Form: none
RFC编号：RFC3455标题字段名称：P-VITED-Network-ID压缩格式：无
RFC Number: RFC3455 Header Field Name: P-Access-Network-Info Compact Form: none
RFC编号：RFC3455标题字段名称：P-Access-Network-Info压缩格式：无
RFC Number: RFC3455 Header Field Name: P-Charging-Function-Addresses Compact Form: none
RFC编号：RFC3455标题字段名称：P-Charging-Function-Addresses压缩格式：无
RFC Number: RFC3455 Header Field Name: P-Charging-Vector Compact Form: none
RFC编号：RFC3455标题字段名称：P-Charging-Vector压缩格式：无
The extensions described in this document were originally specified in several documents. Miguel Garcia-Martin authored the P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID headers. 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.
本文档中描述的扩展最初在多个文档中指定。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 authors would like to thank 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 this document.
作者感谢Andrew Allen、Gabor Bajko、Gonzalo Camarillo、Keith Drage、Georg Mayer、Dean Willis、Rohan Mahy、Jonathan Rosenberg、Ya Ching Tan和3GPP CN1工作组成员对本文件的评论。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[4] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress.
[4] Garcia Martin，M.，“第三代合作伙伴关系项目（3GPP）发布5对会话启动协议（SIP）的要求”，正在进行中。
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[5] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[8] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[9] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[10] Campbell, B., Editor, Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[10] Campbell，B.，编辑，Rosenberg，J.，Schulzrinne，H.，Huitema，C.和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[11] Sparks, R., "The SIP Refer Method", Work in Progress.
[11] Sparks，R.，“SIP参考方法”，正在进行中。
[12] Barnes, M., "SIP Generic Request History Capability Requirements", Work in Progress.
[12] Barnes，M.，“SIP通用请求历史记录能力需求”，正在进行中。
[13] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[13] 沃森，M.，“网络断言身份的短期要求”，RFC 33242002年11月。
[14] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", 3GPP 23.228, September 2002, <ftp://ftp.3gpp.org/ Specs/archive/23_series/23.228/>.
[14] 3GPP，“TS 23.228:IP多媒体子系统（IMS）；第2阶段（发行版5）”，3GPP 23.228，2002年9月<ftp://ftp.3gpp.org/ 规格/存档/23_系列/23.228/>。
[15] 3GPP, "TS 24.229: IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", 3GPP 24.229, September 2002, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[15] 3GPP，“TS 24.229：基于SIP和SDP的IP多媒体呼叫控制协议；第3阶段（版本5）”，3GPP 24.229，2002年9月<ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[16] 3GPP, "TS 32.200: Telecommunication Management; Charging management; Charging principles (Release 5)", 3GPP 32.200, June 2002, <ftp://ftp.3gpp.org/Specs/archive/32_series/32.200/>.
[16] 3GPP，“TS 32.200：电信管理；计费管理；计费原则（第5版）”，3GPP 32.200，2002年6月<ftp://ftp.3gpp.org/Specs/archive/32_series/32.200/>.
[17] 3GPP, "TS 32.225: Telecommunication Management; Charging management; Charging Data Description for IP Multimedia Subsystem (Release 5)", 3GPP 32.225, September 2002, <ftp:// ftp.3gpp.org/Specs/archive/32_series/32.225/>.
[17] 3GPP，“TS 32.225：电信管理；计费管理；IP多媒体子系统的计费数据说明（第5版）”，3GPP 32.225，2002年9月，<ftp://ftp.3GPP.org/Specs/archive/32_series/32.225/>。
Authors' Addresses
作者地址
Miguel A. Garcia-Martin Ericsson Hirsalantie 11 Jorvas FIN-02420 Finland EMail: miguel.a.garcia@ericsson.com
Miguel A.Garcia Martin Ericsson Hirsalantie 11 Jorvas FIN-02420芬兰电子邮件：Miguel.A。garcia@ericsson.com
Eric Henrikson Lucent 11601 Willows Rd, Suite 100 Redmond, WA 98052 USA EMail: ehenrikson@lucent.com
Eric Henrikson-Lucent美国华盛顿州雷德蒙德市柳树路11601号100室，邮编：98052电子邮件：ehenrikson@lucent.com
Duncan Mills Vodafone The Courtyard, 2-4 London Road Newbury, Berkshire RG14 1JX UK EMail: duncan.mills@vf.vodafone.co.uk
邓肯·米尔斯·沃达丰庭院，伯克希尔郡纽伯里伦敦路2-4号RG14 1JX英国电子邮件：邓肯。mills@vf.vodafone.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。