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)
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.
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.
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.
York & Asveren Informational [Page 1]
RFC 8496 P-Charge-Info October 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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].
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:
o P-Asserted-Identity
o From (in the absence of 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].)
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.
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.
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.
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.
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.
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.
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.
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.
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.
5.1. Applicability Statement for the P-Charge-Info Header Field
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.
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:
o the SIP proxy on the originating network;
o a PSTN gateway acting as a SIP UA; or
o an application server generating billing information.
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.
The P-Charge-Info header field may be inserted by PSTN gateways or application servers acting as a SIP UA.
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.
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
York & Asveren Informational [Page 5]
RFC 8496 P-Charge-Info October 2018
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).
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.
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.
A SIP proxy that does not support this extension will pass any received P-Charge-Info header field unmodified, in compliance with RFC 3261.
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.
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.
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.
The syntax of the P-Charge-Info header field is described as follows:
P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec) ; name-addr and addr-spec are specified in RFC 3261
The SIP URI contained in the name-addr/addr-spec is the billing indicator that is passed between the parties.
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:
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.
York & Asveren Informational [Page 7]
RFC 8496 P-Charge-Info October 2018
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.
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.
Therefore, a SIP entity MUST remove and ignore the P-Charge-Info header field when it is received from an untrusted entity.
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.
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.
Therefore, a SIP entity MUST remove the P-Charge-Info header field when it is sent to an untrusted entity.
[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>.
[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>.
[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>.
[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>.
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-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:
o Billing-Correlation-ID, a globally unique identifier
o Financial-Entity-ID
o RKS-Group-ID (record-keeping server)
The P-DCS-Billing-Info header field may also include a variety of additional parameters.
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.
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
York & Asveren Informational [Page 10]
RFC 8496 P-Charge-Info October 2018
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.)
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.
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.
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.
Authors' Addresses
Dan York Individual Keene, NH United States of America
Email: dyork@lodestar2.com
Tolga Asveren Ribbon Communications 3 Paragon Way, Suite 100 Freehold, NJ 007728 United States of America