From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8496.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc8496.txt (limited to 'doc/rfc/rfc8496.txt') diff --git a/doc/rfc/rfc8496.txt b/doc/rfc/rfc8496.txt new file mode 100644 index 0000000..c1e382a --- /dev/null +++ b/doc/rfc/rfc8496.txt @@ -0,0 +1,619 @@ + + + + + + +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. + +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 + + + + + + +York & Asveren Informational [Page 2] + +RFC 8496 P-Charge-Info October 2018 + + +1. Overview + + 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. + + + + + + + + + +York & Asveren Informational [Page 3] + +RFC 8496 P-Charge-Info October 2018 + + +2. Requirements Language + + 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. + +3. Purpose of This Document + + 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. + +4. Use Cases + + 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. + + + + + + + +York & Asveren Informational [Page 4] + +RFC 8496 P-Charge-Info October 2018 + + +5. The P-Charge-Info Header + +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. + +5.2. Usage of the P-Charge-Info Header Field + + 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. + +5.2.1. Procedures at the UA + + 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). + +5.2.2. Procedures at the Proxy + + 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. + +5.3. Use-Case Example + + 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: + + P-Charge-Info: + + P-Charge-Info: + + P-Charge-Info: + + Any other applicable SIP URI could be used. + + + + + + + + + +York & Asveren Informational [Page 6] + +RFC 8496 P-Charge-Info October 2018 + + +6. Formal Syntax + + 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. + +7. IANA Considerations + + This specification registers a new proprietary SIP header field + according to the procedures defined in [RFC5727]. + +7.1. Header Field + + 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: + + Header Field Name: P-Charge-Info + + Compact Form: none + + Reference: RFC 8496 + +8. Security Considerations + +8.1. Trust Relationship + + 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. + +8.2. Untrusted Peers + +8.2.1. Ingress from Untrusted Peers + + 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. + +8.2.2. Egress to Untrusted Peers + + 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. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + + + +York & Asveren Informational [Page 8] + +RFC 8496 P-Charge-Info October 2018 + + + [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, + . + + [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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr + Production in SIP Messages", RFC 8217, + DOI 10.17487/RFC8217, August 2017, + . + +9.2. Informative References + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [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, + . + + [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, . + + [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, . + + + + + + + +York & Asveren Informational [Page 9] + +RFC 8496 P-Charge-Info October 2018 + + +Appendix A. Alternatives + +A.1. P-Charging-Vector + + 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. + +A.2. P-DCS-Billing-Info + + 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.) + +A.3. P-Asserted-Identity + + 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 + + Email: tasveren@rbbn.com + + + + + +York & Asveren Informational [Page 11] + -- cgit v1.2.3