GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8496

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8496.txt · Last modified: 2018/10/31 21:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki