summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8496.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8496.txt')
-rw-r--r--doc/rfc/rfc8496.txt619
1 files changed, 619 insertions, 0 deletions
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: <sip:+14075550134@example.net;user=phone>
+
+ P-Charge-Info: <sip:+12345550167@example.com>
+
+ P-Charge-Info: <sips:1234@example.com>
+
+ P-Charge-Info: <tel:+14075551234>
+
+ 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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+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,
+ <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>.
+
+ [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>.
+
+ [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>.
+
+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,
+ <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>.
+
+ [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>.
+
+ [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>.
+
+
+
+
+
+
+
+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]
+