Internet Engineering Task Force (IETF) D. York
Request for Comments: 8496 Individual
Category: Informational T. Asveren
ISSN: 2070-1721 Ribbon Communications
October 2018
Internet Engineering Task Force (IETF) D. York
Request for Comments: 8496 Individual
Category: Informational T. Asveren
ISSN: 2070-1721 Ribbon Communications
October 2018
P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)
P-Charge-Info：会话启动协议（SIP）的专用头字段（P-Header）扩展
Abstract
摘要
This text documents the current usage of P-Charge-Info, an existing Session Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged. This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA.
本文记录了P-Charge-Info的当前使用情况，P-Charge-Info是一个现有的会话发起协议（SIP）私有报头字段（P-header），用于传递有关被收费方的计费信息。该P-Header目前由多家设备供应商和运营商在生产中使用，至少从2007年开始使用。本文档详细说明了此标题字段在IANA中的注册。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8496.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8496.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Purpose of This Document . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. The P-Charge-Info Header . . . . . . . . . . . . . . . . . . 5
5.1. Applicability Statement for the P-Charge-Info Header
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Usage of the P-Charge-Info Header Field . . . . . . . . . 5
5.2.1. Procedures at the UA . . . . . . . . . . . . . . . . 5
5.2.2. Procedures at the Proxy . . . . . . . . . . . . . . . 6
5.3. Use-Case Example . . . . . . . . . . . . . . . . . . . . 6
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.1. Trust Relationship . . . . . . . . . . . . . . . . . . . 7
8.2. Untrusted Peers . . . . . . . . . . . . . . . . . . . . . 8
8.2.1. Ingress from Untrusted Peers . . . . . . . . . . . . 8
8.2.2. Egress to Untrusted Peers . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Alternatives . . . . . . . . . . . . . . . . . . . . 10
A.1. P-Charging-Vector . . . . . . . . . . . . . . . . . . . . 10
A.2. P-DCS-Billing-Info . . . . . . . . . . . . . . . . . . . 10
A.3. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Purpose of This Document . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. The P-Charge-Info Header . . . . . . . . . . . . . . . . . . 5
5.1. Applicability Statement for the P-Charge-Info Header
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Usage of the P-Charge-Info Header Field . . . . . . . . . 5
5.2.1. Procedures at the UA . . . . . . . . . . . . . . . . 5
5.2.2. Procedures at the Proxy . . . . . . . . . . . . . . . 6
5.3. Use-Case Example . . . . . . . . . . . . . . . . . . . . 6
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.1. Trust Relationship . . . . . . . . . . . . . . . . . . . 7
8.2. Untrusted Peers . . . . . . . . . . . . . . . . . . . . . 8
8.2.1. Ingress from Untrusted Peers . . . . . . . . . . . . 8
8.2.2. Egress to Untrusted Peers . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Alternatives . . . . . . . . . . . . . . . . . . . . 10
A.1. P-Charging-Vector . . . . . . . . . . . . . . . . . . . . 10
A.2. P-DCS-Billing-Info . . . . . . . . . . . . . . . . . . . 10
A.3. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
In certain network configurations, several network entities have found it useful to decouple the identity of the caller (what is normally thought of as "Caller ID") from the identity/number used for billing purposes. This document records the current usage of P-Charge-Info, a private SIP header field, to provide simple billing information and details the registration of this header field with IANA as required by Section 4 of [RFC5727].
在某些网络配置中，几个网络实体发现将呼叫者的身份（通常被认为是“呼叫者ID”）与用于计费目的的身份/号码分离是有用的。本文件记录了P-Charge-Info（一个专用SIP报头字段）的当前使用情况，以提供简单的计费信息，并根据[RFC5727]第4节的要求详细说明了该报头字段在IANA中的注册。
In a typical configuration, the identity of the caller, commonly referred to as "Caller ID" by end users, is derived from one of the following SIP header fields:
在典型配置中，呼叫者的身份（终端用户通常称为“呼叫者ID”）来自以下SIP头字段之一：
o P-Asserted-Identity
o P-恒等式
o From (in the absence of P-Asserted-Identity)
o From（在没有P-Asserted-Identity的情况下）
(NOTE: Some service providers have also used the Remote-Party-ID header field, but this was never standardized and was replaced by P-Asserted-Identity in [RFC3325].)
（注意：一些服务提供商也使用了远程方ID报头字段，但该字段从未标准化，在[RFC3325]中被P-Asserted-Identity替换。）
This identity/number is typically presented to the receiving user agent (UA), where it is usually displayed for the end user. It is also typically used for billing purposes by the network entities involved in carrying the session.
该标识/号码通常呈现给接收用户代理（UA），在那里通常为最终用户显示。它还通常用于承载会话的网络实体的计费目的。
However, in some network configurations, the "Caller ID" presented to the receiving UA may be different from the number to be used for billing purposes.
然而，在一些网络配置中，呈现给接收UA的“呼叫者ID”可能不同于用于计费目的的号码。
In this case, there exists a need for a way to pass an additional billing identifier that can be used between network entities in order to correctly bill for services.
在这种情况下，需要一种方法来传递可在网络实体之间使用的附加计费标识符，以便正确地为服务计费。
Several carriers, application providers, and equipment providers have been using the P-Charge-Info header field since at least 2007 as a simple mechanism to exchange this billing identifier.
至少自2007年以来，一些运营商、应用程序提供商和设备提供商一直在使用P-Charge-Info报头字段作为交换此计费标识符的简单机制。
This document specifies the use of the P-Charge-Info header field in INVITE requests. The header field might be useful in other SIP messages, but such use is beyond the scope of this document.
本文档指定在邀请请求中使用P-Charge-Info标头字段。header字段在其他SIP消息中可能有用，但这种使用超出了本文档的范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The key words describe requirements needed to interoperate with existing usage.
关键词描述了与现有用法互操作所需的需求。
This document has been prepared to document the existing deployed usage of the P-Charge-Info header field and to comply with Section 4 of [RFC5727] in registering this header field with IANA. It is noted that RFC 5727 specifically deprecates new usage of "P-" header fields, but P-Charge-Info has been in deployment since before 2007 and predates RFC 5727. Given this, the authors believe that P-Charge-Info is a "grandfathered case" per Section 4 of RFC 5727.
编制本文件的目的是记录P-Charge-Info报头字段的现有部署使用情况，并遵守[RFC5727]第4节在IANA注册该报头字段的规定。值得注意的是，RFC 5727特别反对“P-”标题字段的新用法，但P-Charge-Info自2007年之前开始部署，早于RFC 5727。鉴于此，作者认为，根据RFC 5727第4节，P-Charge-Info是一个“祖传案例”。
The simplest use case for P-Charge-Info is an enterprise environment where each SIP endpoint has a direct number that is passed by the enterprise SIP proxy across to a SIP proxy at a SIP service provider who provides connectivity to the Public Switched Telephone Network (PSTN). Rather than cause the SIP service provider to have to track each individual direct number for billing purposes, the enterprise SIP proxy sends, in the P-Charge-Info header field, a single billing identifier that the SIP service provider uses for billing purposes.
P-Charge-Info最简单的用例是企业环境，其中每个SIP端点都有一个直接号码，该号码由企业SIP代理传递给SIP服务提供商的SIP代理，该SIP服务提供商提供到公共交换电话网络（PSTN）的连接。企业SIP代理在P-Charge-Info报头字段中发送SIP服务提供商用于计费目的的单个计费标识符，而不是使SIP服务提供商必须跟踪每个单独的直接号码以进行计费。
As another example, a hosted telephony provider or hosted voice-application provider may have a large SIP network with customers who are distributed over a very large geographic area and use local-market PSTN numbers, although the network has only a very few actual PSTN interconnection points.
作为另一个示例，托管电话提供商或托管语音应用提供商可以具有大型SIP网络，其中客户分布在非常大的地理区域上，并且使用本地市场PSTN号码，尽管该网络只有很少的实际PSTN互连点。
The customers may all have local phone numbers, yet outgoing calls are actually routed across a SIP network and out specific PSTN gateways or across specific SIP connections to other SIP service providers. The hosted provider may want to pass a billing identifier to its SIP service providers either for the purpose of simplicity in billing or to obtain better rates from the SIP service providers.
客户可能都有本地电话号码，但呼出电话实际上是通过SIP网络和特定的PSTN网关或通过特定的SIP连接路由到其他SIP服务提供商的。托管提供商可能希望将计费标识符传递给其SIP服务提供商，以简化计费或从SIP服务提供商获得更好的费率。
The P-Charge-Info header field is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.
P-Charge-Info标头字段适用于单个私有管理域内或不同管理域之间的域间信任关系。
The P-Charge-Info header field is used to convey information about the identity of the party to be charged. The P-Charge-Info header field is typically inserted into a SIP request, usually an INVITE, by one of the following:
P-Charge-Info标头字段用于传递有关待收费方身份的信息。P-Charge-Info标头字段通常通过以下方式之一插入到SIP请求（通常是邀请）中：
o the SIP proxy on the originating network;
o 发起网络上的SIP代理；
o a PSTN gateway acting as a SIP UA; or
o 充当SIP-UA的PSTN网关；或
o an application server generating billing information.
o 生成计费信息的应用服务器。
P-Charge-Info is to be used by the SIP entity that provides billing services for a session. This could be an entity that is generating billing records or another entity interacting with it. Upon receipt of an INVITE request with the P-Charge-Info header field, such an entity MAY use the value present in P-Charge-Info as indicating the party responsible for the charges associated with the session. This decision, for example, could be based on local policy.
P-Charge-Info将由为会话提供计费服务的SIP实体使用。这可能是一个正在生成账单记录的实体或与之交互的另一个实体。在接收到带有P-Charge-Info头字段的INVITE请求时，这样的实体可以使用P-Charge-Info中存在的值来指示负责与会话相关联的费用的一方。例如，这一决定可能基于当地政策。
The P-Charge-Info header field may be inserted by PSTN gateways or application servers acting as a SIP UA.
PSTN网关或充当SIP UA的应用服务器可以插入P-Charge-Info报头字段。
The P-Charge-Info header field is ignored by an end-user UA and should not normally be received by such a UA. It MUST NOT be sent to an end-user UA, as this would provide information to the UA about the party to be charged; providing such information may cause security-related issues; for example, calling-party information would be known by the UA for an otherwise anonymous call. A UA SHOULD ignore it if it receives this header. Similarly, an end-user UA originating a SIP message SHOULD NOT insert this header field.
最终用户UA忽略P-Charge-Info标头字段，并且此类UA通常不应接收该字段。不得将其发送给最终用户UA，因为这将向UA提供有关被收费方的信息；提供此类信息可能导致安全相关问题；例如，对于其他匿名呼叫，UA将知道主叫方信息。如果UA收到此标头，则应忽略它。类似地，发起SIP消息的最终用户UA不应插入此头字段。
A PSTN gateway or application server acting as a UA MAY use the content of the P-Charge-Info header field present in an INVITE request it received as the identity to be charged for the session for billing-related procedures, e.g., in a billing record or during interaction with another entity generating billing records. A PSTN
作为UA的PSTN网关或应用服务器可以使用其接收到的INVITE请求中存在的P-Charge-Info报头字段的内容作为与计费相关的过程（例如，在计费记录中或在与生成计费记录的另一实体交互期间）的会话的计费标识。公用电话网
gateway or application server acting as a UA MAY use the content of the P-Charge-Info header field to populate information about the identity of the party to charge in another type of signaling, such as ISDN User Part (ISUP).
充当UA的网关或应用服务器可以使用P-Charge-Info报头字段的内容来填充关于要在另一类型信令（例如ISDN用户部分（ISUP））中计费的一方的身份的信息。
A SIP proxy that supports this extension and receives a request, typically a SIP INVITE, MAY insert a P-Charge-Info header field. The contents of the inserted header field may be decided based on local policy or by querying an external entity to determine the identity of the party to be charged.
支持此扩展并接收请求（通常为SIP INVITE）的SIP代理可以插入P-Charge-Info头字段。插入的报头字段的内容可以基于本地策略或通过查询外部实体来确定要收费方的身份来确定。
When a proxy receives an INVITE request, it MAY use the content of the P-Charge-Info header field contained in the request for billing-related procedures, e.g., in a billing record or during interaction with another entity that is generating billing records.
当代理收到INVITE请求时，它可以使用计费相关程序请求中包含的P-Charge-Info头字段的内容，例如，在计费记录中或在与生成计费记录的另一实体交互期间。
A SIP proxy that does not support this extension will pass any received P-Charge-Info header field unmodified, in compliance with RFC 3261.
根据RFC 3261，不支持此扩展的SIP代理将不经修改地传递任何收到的P-Charge-Info头字段。
A proxy supporting this extension MUST remove the P-Charge-Info header field before sending a request to a UA that is not acting as a PSTN gateway or appropriate application server, if the role of the UA is known.
如果UA的角色已知，则支持此扩展的代理必须在向不充当PSTN网关或相应应用程序服务器的UA发送请求之前删除P-Charge-Info标头字段。
The content of the P-Charge-Info header field is typically just a SIP/tel URI used as a billing indicator. An example could be as simple as one of:
P-Charge-Info报头字段的内容通常只是用作计费指示符的SIP/tel URI。一个简单的例子可以是：
P-Charge-Info: <sip:+14075550134@example.net;user=phone>
P-Charge-Info: <sip:+14075550134@example.net;user=phone>
P-Charge-Info: <sip:+12345550167@example.com>
P-Charge-Info: <sip:+12345550167@example.com>
P-Charge-Info: <sips:1234@example.com>
P-Charge-Info: <sips:1234@example.com>
P-Charge-Info: <tel:+14075551234>
P-Charge-Info: <tel:+14075551234>
Any other applicable SIP URI could be used.
可以使用任何其他适用的SIPURI。
This RFC contains the definition of one or more SIP header fields that allow choosing between addr-spec and name-addr when constructing header-field values. [RFC8217] prohibits the use of addr-spec if its value would contain a comma, semicolon, or question mark.
此RFC包含一个或多个SIP头字段的定义，允许在构造头字段值时在addr spec和name addr之间进行选择。[RFC8217]如果addr spec的值包含逗号、分号或问号，则禁止使用addr spec。
The private header field specified here is described in both prose and an augmented Backus-Naur Form (BNF) defined in [RFC5234]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementors need to be familiar with the notation and contents of [RFC3261] and [RFC5234] to understand this document.
此处指定的私有标头字段以散文和[RFC5234]中定义的扩展的Backus Naur格式（BNF）进行了描述。此外，几个BNF定义是从SIP继承的，这里不再重复。实施者需要熟悉[RFC3261]和[RFC5234]的符号和内容才能理解本文档。
The syntax of the P-Charge-Info header field is described as follows:
P-Charge-Info标头字段的语法描述如下：
P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec) ; name-addr and addr-spec are specified in RFC 3261
P-Charge-Info=“P-Charge-Info”HCOLON（名称addr/addr spec）；名称addr和addr spec在RFC 3261中指定
The SIP URI contained in the name-addr/addr-spec is the billing indicator that is passed between the parties.
名称addr/addr spec中包含的SIPURI是双方之间传递的计费指示符。
This specification registers a new proprietary SIP header field according to the procedures defined in [RFC5727].
本规范根据[RFC5727]中定义的程序注册一个新的专有SIP头字段。
The P-Charge-Info private header field has been registered in the "Header Fields" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry as follows:
已在“会话启动协议（SIP）参数”注册表的“header Fields”子区域中注册了P-Charge-Info私有标头字段，如下所示：
Header Field Name: P-Charge-Info
标题字段名称：P-Charge-Info
Compact Form: none
紧凑型：无
Reference: RFC 8496
参考：RFC 8496
Given that the information contained in the P-Charge-Info header field will be used for billing purposes, the proxies and other SIP entities that share this information MUST have a trust relationship.
鉴于P-Charge-Info报头字段中包含的信息将用于计费目的，因此共享此信息的代理和其他SIP实体必须具有信任关系。
If an untrusted entity were inserted between the trusted entities, it could potentially interfere with the billing records for the call. If the SIP connections are not made over a private network, a mechanism for securing the confidentiality and integrity of the SIP connection MUST be used to protect the information. One such mechanism could be TLS encryption of the SIP signaling stream.
如果在受信任的实体之间插入不受信任的实体，则可能会干扰呼叫的计费记录。如果SIP连接不是通过专用网络进行的，则必须使用保护SIP连接的机密性和完整性的机制来保护信息。一种这样的机制可以是SIP信令流的TLS加密。
If the P-Charge-Info header field was accepted by a SIP entity from an untrusted peer, there is the potential for fraud if the untrusted entity sent incorrect information, either inadvertently or maliciously.
如果SIP实体从不受信任的对等方接受P-Charge-Info报头字段，则如果不受信任的实体无意或恶意发送错误信息，则可能存在欺诈。
Therefore, a SIP entity MUST remove and ignore the P-Charge-Info header field when it is received from an untrusted entity.
因此，当从不受信任的实体接收到P-Charge-Info头字段时，SIP实体必须删除并忽略该字段。
If the P-Charge-Info header field was sent by a SIP entity to an untrusted peer, there is potential for exposure of network information that is internal to a trust domain. For instance, the untrusted entity may learn the identities of public SIP proxies used within the trust domain, which could then potentially be directly attacked.
如果SIP实体将P-Charge-Info报头字段发送给不受信任的对等方，则可能会暴露信任域内部的网络信息。例如，不受信任的实体可以了解在信任域内使用的公共SIP代理的身份，然后可能直接受到攻击。
If an implementation does not strip P-Charge-Info from the message where specified in this document, it introduces serious privacy risks. Examples include revealing third-party billing relationships that might be sensitive, as well as unmasking the identity of callers who wish to remain anonymous. Depending on circumstances, the latter case may result in unwanted harassment and even physical harm to the calling party.
如果实施未从本文档中指定的消息中删除P-Charge-Info，则会带来严重的隐私风险。例如，披露可能敏感的第三方计费关系，以及揭露希望保持匿名的呼叫者的身份。根据情况，后一种情况可能会对呼叫方造成不必要的骚扰，甚至身体伤害。
Therefore, a SIP entity MUST remove the P-Charge-Info header field when it is sent to an untrusted entity.
因此，SIP实体在发送给不受信任的实体时必须删除P-Charge-Info头字段。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, DOI 10.17487/RFC5727, March 2010, <https://www.rfc-editor.org/info/rfc5727>.
[RFC5727]Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，DOI 10.17487/RFC5727，2010年3月<https://www.rfc-editor.org/info/rfc5727>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8217] Sparks, R., "Clarifications for When to Use the name-addr Production in SIP Messages", RFC 8217, DOI 10.17487/RFC8217, August 2017, <https://www.rfc-editor.org/info/rfc8217>.
[RFC8217]Sparks，R.“关于何时在SIP消息中使用名称addr Production的澄清”，RFC 8217，DOI 10.17487/RFC82172017年8月<https://www.rfc-editor.org/info/rfc8217>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<https://www.rfc-editor.org/info/rfc3325>.
[RFC5503] Andreasen, F., McKibben, B., and B. Marshall, "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", RFC 5503, DOI 10.17487/RFC5503, March 2009, <https://www.rfc-editor.org/info/rfc5503>.
[RFC5503]Andreasen，F.，McKibben，B.，和B.Marshall，“支持分组电缆分布式呼叫信令体系结构的专用会话发起协议（SIP）代理到代理扩展”，RFC 5503，DOI 10.17487/RFC5503，2009年3月<https://www.rfc-editor.org/info/rfc5503>.
[RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July 2014, <https://www.rfc-editor.org/info/rfc7315>.
[RFC7315]Jesske，R.，Drage，K.，和C.Holmberg，“3GPP会话启动协议（SIP）的专用头（P头）扩展”，RFC 7315，DOI 10.17487/RFC7315，2014年7月<https://www.rfc-editor.org/info/rfc7315>.
P-Charging-Vector is defined in Section 4.6 of [RFC7315] and used by the 3GPP to carry information related to the charging of a session. There are, however, some differences in the semantics associated with P-Charging-Vector and P-Charge-Info. P-Charging-Vector is mainly used to carry information for correlation of multiple charging records generated for a single session. On the other hand, P-Charge-Info is used to convey information about the party to be billed for a call. Furthermore, P-Charging-Vector has a mandatory icid-value parameter that is a globally unique value to identify the session for which the charging information is generated. Such a globally unique identifier is not necessary when carrying information about the user to be billed when it is attached to the corresponding session-related signaling.
P-Charging-Vector在[RFC7315]的第4.6节中定义，并由3GPP用于承载与会话计费相关的信息。然而，与P-Charge-Vector和P-Charge-Info相关的语义存在一些差异。P-Charging-Vector主要用于携带针对单个会话生成的多个计费记录的相关信息。另一方面，P-Charge-Info用于传递关于要为呼叫计费的一方的信息。此外，P-Charging-Vector具有强制性的icid值参数，该参数是全局唯一的值，用于标识为其生成计费信息的会话。当携带关于将要计费的用户的信息时，这种全局唯一标识符不是必需的，当该用户被连接到相应的会话相关信令时。
P-DCS-Billing-Info is defined in Section 7 of [RFC5503] and used for passing billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. For many billing situations, particularly the very large-scale residential telephone networks for which this header field is designed, P-DCS-Billing-Info is an excellent solution. However, this ability to address a range of situations adds complexity. According to RFC 5503, the following information is mandatory to include in each use of the P-DCS-Billing-Info header field:
[RFC5503]第7节定义了P-DCS-Billing-Info，用于在PacketCable分布式呼叫信令体系结构中的受信任实体之间传递计费信息。对于许多计费情况，尤其是设计此报头字段的非常大规模的住宅电话网络，P-DCS-billing-Info是一个极好的解决方案。然而，这种处理一系列情况的能力增加了复杂性。根据RFC 5503，每次使用P-DCS-Billing-Info报头字段时必须包含以下信息：
o Billing-Correlation-ID, a globally unique identifier
o 计费关联ID，一个全局唯一标识符
o Financial-Entity-ID
o 金融实体ID
o RKS-Group-ID (record-keeping server)
o RKS组ID（记录保存服务器）
The P-DCS-Billing-Info header field may also include a variety of additional parameters.
P-DCS-Billing-Info标头字段还可能包括各种附加参数。
While this may work well in many billing scenarios, there are other billing scenarios that do not need this level of complexity. In those simpler scenarios, all that is needed is a number to use for billing. P-Charge-Info provides this simple solution for simple billing scenarios.
虽然这在许多计费场景中都能很好地工作，但也有其他计费场景不需要这种复杂程度。在那些简单的场景中，所需要的只是一个用于计费的数字。P-Charge-Info为简单的计费场景提供了这个简单的解决方案。
Additionally, according to Section 7.3 of RFC 5503, it is mandatory for a UA to create a Billing-Correlation-ID and insert this into the P-DCS-Billing-Info header field (along with the other required
此外，根据RFC 5503第7.3节的规定，UA必须创建计费关联ID，并将其插入P-DCS-Billing-Info报头字段（以及其他所需的
information) sent in the initial SIP INVITE. This again makes sense for the residential-telephone-service environment for which this header field is designed. In contrast, P-Charge-Info is designed to be used among proxies and not at all by normal user agents. (P-Charge-Info may, though, be used by user agents associated with PSTN gateways.)
信息）在初始SIP邀请中发送。这同样适用于设计此标头字段的住宅电话服务环境。相比之下，P-Charge-Info设计用于代理之间，而不是由普通用户代理使用。（不过，与PSTN网关相关联的用户代理可能会使用P-Charge-Info。）
Early reviewers of this document asked why the P-Asserted-Identity header field documented in [RFC3325] could not be used. As mentioned in the use-case example above, P-Asserted-Identity is used to indicate the identity of the calling party. However, in this instance, the requirement is to provide an additional identity of the SIP-to-PSTN interconnect point.
本文档的早期审阅者询问为什么不能使用[RFC3325]中记录的P-Asserted-Identity标头字段。如上面的用例示例所述，P-Asserted-Identity用于指示呼叫方的身份。然而，在这种情况下，要求提供SIP到PSTN互连点的附加标识。
It would be typical to find both P-Asserted-Identity and P-Charge-Info used in a SIP exchange. P-Asserted-Identity would be used to provide the caller identity that would be displayed to the end user as "Caller ID", while P-Charge-Info would provide the billing identifier used for the billing associated with the call.
通常会在SIP交换中同时找到P-Asserted-Identity和P-Charge-Info。P-Asserted-Identity将用于提供将作为“呼叫者ID”显示给最终用户的呼叫者标识，而P-Charge-Info将提供用于与呼叫相关联的计费的计费标识符。
Acknowledgements
致谢
The authors thank the following people for their comments: Keith Drage, Miguel Garcia, Sumit Garg, John Haluska, Juha Heinanen, Christer Holmberg, Paul Kyzivat, Adam Roach, Jonathan Rosenberg, Henning Schulzrinne, Tom Taylor, and Glen Wang.
作者感谢以下人士的评论：Keith Drage、Miguel Garcia、Sumit Garg、John Haluska、Juha Heinanen、Christer Holmberg、Paul Kyzivat、Adam Roach、Jonathan Rosenberg、Henning Schulzrinne、Tom Taylor和Glen Wang。
Authors' Addresses
作者地址
Dan York Individual Keene, NH United States of America
Dan York个人基恩，美国新罕布什尔州
Email: dyork@lodestar2.com
Email: dyork@lodestar2.com
Tolga Asveren Ribbon Communications 3 Paragon Way, Suite 100 Freehold, NJ 007728 United States of America
美国新泽西州自由保有权100号套房Paragon路3号托尔加·阿斯维伦带状通信公司，邮编：007728
Email: tasveren@rbbn.com
Email: tasveren@rbbn.com