path: root/doc/rfc/rfc8496.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L