Movatterモバイル変換

Internet Engineering Task Force (IETF)                           D. YorkRequest for Comments: 8496                                    IndividualCategory: Informational                                       T. AsverenISSN: 2070-1721                                    Ribbon Communications                                                            October 2018P-Charge-Info: A Private Header Field (P-Header) Extension to theSession 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; seeSection 2 of RFC 7841.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8496.York & Asveren                Informational                     [Page 1]

RFC 8496                      P-Charge-Info                 October 2018Copyright Notice   Copyright (c) 2018 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .32.  Requirements Language . . . . . . . . . . . . . . . . . . . .43.  Purpose of This Document  . . . . . . . . . . . . . . . . . .44.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .45.  The P-Charge-Info Header  . . . . . . . . . . . . . . . . . .5     5.1.  Applicability Statement for the P-Charge-Info Header           Field . . . . . . . . . . . . . . . . . . . . . . . . . .55.2.  Usage of the P-Charge-Info Header Field . . . . . . . . .55.2.1.  Procedures at the UA  . . . . . . . . . . . . . . . .55.2.2.  Procedures at the Proxy . . . . . . . . . . . . . . .65.3.  Use-Case Example  . . . . . . . . . . . . . . . . . . . .66.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .77.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .77.1.  Header Field  . . . . . . . . . . . . . . . . . . . . . .78.  Security Considerations . . . . . . . . . . . . . . . . . . .78.1.  Trust Relationship  . . . . . . . . . . . . . . . . . . .78.2.  Untrusted Peers . . . . . . . . . . . . . . . . . . . . .88.2.1.  Ingress from Untrusted Peers  . . . . . . . . . . . .88.2.2.  Egress to Untrusted Peers . . . . . . . . . . . . . .89.  References  . . . . . . . . . . . . . . . . . . . . . . . . .89.1.  Normative References  . . . . . . . . . . . . . . . . . .89.2.  Informative References  . . . . . . . . . . . . . . . . .9Appendix A.  Alternatives . . . . . . . . . . . . . . . . . . . .10A.1.  P-Charging-Vector . . . . . . . . . . . . . . . . . . . .10A.2.  P-DCS-Billing-Info  . . . . . . . . . . . . . . . . . . .10A.3.  P-Asserted-Identity . . . . . . . . . . . . . . . . . . .11   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .11   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .11York & Asveren                Informational                     [Page 2]

RFC 8496                      P-Charge-Info                 October 20181.  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 bySection 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 20182.  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 inBCP 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 withSection 4   of [RFC5727] in registering this header field with IANA.  It is noted   thatRFC 5727 specifically deprecates new usage of "P-" header   fields, but P-Charge-Info has been in deployment since before 2007   and predatesRFC 5727.  Given this, the authors believe that   P-Charge-Info is a "grandfathered case" perSection 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 20185.  The P-Charge-Info Header5.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 PSTNYork & 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 withRFC 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 20186.  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 inRFC 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 84968.  Security Considerations8.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 Peers8.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.  References9.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 inRFC2119 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 2018Appendix A.  AlternativesA.1.  P-Charging-Vector   P-Charging-Vector is defined inSection 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 inSection 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 toRFC5503, 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 toSection 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 requiredYork & 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.comYork & Asveren                Informational                    [Page 11]