Skip to main content

Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses
draft-ietf-sipcore-rfc7976bis-00

Document Type Active Internet-Draft (sipcore WG)
Authors Christer Holmberg , Nevenka Biondic , Gonzalo Salgueiro , Roland Jesske
Last updated 2024-08-20
Replaces draft-sipcore-rfc7976bis
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-sipcore-rfc7976bis-00
dispatch                                                     C. Holmberg
Internet-Draft                                                N. Biondic
Obsoletes: 7976 (if approved)                                   Ericsson
Updates: 7315 (if approved)                                 G. Salgueiro
Intended status: Informational                       Cisco Systems, Inc.
Expires: 21 February 2025                                      R. Jesske
                                                        Deutsche Telekom
                                                          20 August 2024

    Updates to Private Header (P-Header) Extension Usage in Session
            Initiation Protocol (SIP) Requests and Responses
                  draft-ietf-sipcore-rfc7976bis-00.txt

Abstract

   The Third Generation Partnership Project (3GPP) has identified cases
   where different SIP private header extensions referred to as "P-"
   header fields, and defined in RFC 7315, need to be included in SIP
   requests and responses currently not allowed according to RFC 7315.
   This document updates RFC 7315, in order to allow inclusion of the
   affected "P-" header fields in such requests and responses.

   This document also makes updates for RFC 7315 in order to fix
   misalignments that occurred when RFC 3455 was updated and obsoleted
   by RFC 7315.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 21 February 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Holmberg, et al.        Expires 21 February 2025                [Page 1]
Internet-Draft          Update to Private Header             August 2024

   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Misalignments and 3GPP Use Cases  . . . . . . . . . . . . . .   3
     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Misalignments . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . .   4
       2.3.1.  General . . . . . . . . . . . . . . . . . . . . . . .   4
       2.3.2.  P-Access-Network-Info . . . . . . . . . . . . . . . .   4
       2.3.3.  P-Charging-Vector . . . . . . . . . . . . . . . . . .   5
   3.  Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Third Generation Partnership Project (3GPP) has identified cases
   where different Session Initiation Protocol (SIP) [RFC3261] private
   header extensions referred to as "P-" header fields, and defined in
   [RFC7315], need to be included in SIP requests and responses
   currently not allowed according to [RFC7315].  This document updates
   [RFC7315], in order to allow inclusion of the affected "P-" header
   fields in such requests and responses.

   This document also makes updates for [RFC7315] in order to fix
   misalignments that occurred when [RFC3455] was updated and obsoleted
   by [RFC7315].  As the "P-" header fields are mainly used in (and in
   most cases, only defined for) networks defined by the 3GPP, where the
   updates defined in this document are already defined
   [TS.3GPP.24.229], the updates are not seen to cause backward-
   compatibility concerns.

Holmberg, et al.        Expires 21 February 2025                [Page 2]
Internet-Draft          Update to Private Header             August 2024

2.  Misalignments and 3GPP Use Cases

2.1.  General

   [RFC7315] contains contradicting statements regarding the usage of
   SIP "P-" header fields in SIP requests and responses, which leave the
   presence of the SIP "P-" header fields in the SIP requests and
   responses open to interpretation and different implementations.
   Statements in Section 5.7 of that RFC are not aligned with the
   definitions and usage of the SIP "P-" header fields specified in
   Section 4.  This section describes the misalignments that occurred
   when [RFC3455] was updated and obsoleted by [RFC7315], and how they
   are fixed.

   NOTE: In the case of the P-Called-Party-ID header field, allowing it
   in PUBLISH requests was deliberately done in [RFC7315] .  Therefore,
   it is not considered a misalignment.

   Since [RFC7315] was published, 3GPP defined new use cases that
   require the RFC to be updated.  This section describes the 3GPP use
   cases behind the updates, and the updates needed to [RFC7315] in
   order to support the use cases.

   Section 3 updates [RFC7315], based on the misalignments and 3GPP use
   cases.

2.2.  Misalignments

   The following updates are needed in order to fix the misalignments
   between [RFC7315] and [RFC3455] :

   o P-Associated-URI: Remove the statement that the header field can
   appear in the SIP REGISTER method.

   o P-Called-Party-ID: Delete the statement that the P-Called-Party-ID
   header field can appear in SIP responses.  Add a statement that the
   P-Called-Party-ID header field can appear in the SIP REFER method.

   o P-Access-Network-Info: Add a statement that the P-Access-Network-
   Info header field can appear in SIP responses.

   o P-Charging-Vector: Add a statement that the P-Charging-Vector
   header field can appear in SIP responses.  Add a statement that the
   P-Charging-Vector header field cannot appear in the SIP ACK method.

   o P-Charging-Function-Addresses: Add a statement that the P-Charging-
   Function-Addresses header field can appear in SIP responses.

Holmberg, et al.        Expires 21 February 2025                [Page 3]
Internet-Draft          Update to Private Header             August 2024

   The following update is needed in order to clarify the usage of the
   header compared to RFCs 7315:

   o P-Visited-Network-ID: Add a statement that the P-Visited-Network-ID
   header field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE
   methods.  Add statement that P-Visited-Network-ID header field can
   appear in all non 100 (Trying) responses.

2.3.  3GPP Use Cases

2.3.1.  General

   The following updates are needed in order to implement the 3GPP use
   cases:

   o P-Access-Network-Info: Add statement that the P-Access-Network-
   Info header field can appear in the SIP ACK method when triggered by
   a SIP 2xx response.

   o P-Charging-Vector: Add statement that the P-Charging-Vector header
   field can appear in the SIP ACK method when triggered by a SIP 2xx
   response.

   This following sections describe, for individual "P-" header fields,
   the 3GPP use cases that are the basis for the updates.  The use cases
   are based on the procedures defined in [TS.3GPP.24.229].

2.3.2.  P-Access-Network-Info

   The P-Access-Network-Info header field may contain the Network
   Provided Location Information (NPLI).  The NPLI is described in
   [TS.3GPP.23.228].

   A proxy in possession of appropriate information about the access
   technology might insert a P-Access-Network-Info header field with its
   own values.  Such values are identified by the string "network-
   provided" defined in [RFC7315].  Based on operator policy and/or
   roaming agreement, the local time of the visited network may be
   included.

   The Call Data Records (CDRs) generated within the IP Multimedia
   Subsystem (IMS) have to contain the NPLI in order to guarantee
   correct billing.  When an IMS session is modified, the NPLI also
   needs to be stored as the location of the user at the time when the
   session is modified may generate a charging event.  In case of a
   session modification event at IMS, the NPLI needs to be provided:

   o when the bearer establishment is triggered, or

Holmberg, et al.        Expires 21 February 2025                [Page 4]
Internet-Draft          Update to Private Header             August 2024

   o at session release when the bearer deactivation is triggered, or

   o when the bearer modification is triggered, e.g., a QoS modification
   for the use of a newly negotiated codec.

   In some scenarios, the bearer modification may be triggered by the
   proxy upon reception of a Session Description Protocol (SDP) answer
   within SIP 2xx response to the SIP INVITE request.  In such case, the
   NPLI needs to be provided within the SIP ACK request.  However, RFC
   7315 does not allow the usage of the P-Access-Network-Info header
   field in SIP ACK request.

   Upon reception of the SDP answer within SIP 2xx response on the SIP
   INVITE request, a proxy may initiate procedures to obtain the NPLI
   and may include the P-Access-Network-Info header field with the NPLI
   in the SIP ACK request.

   The P-Access-Network-Info header field shall not be included in SIP
   ACK requests triggered by non-2xx responses.

2.3.3.  P-Charging-Vector

   The [RFC7315] defines an Inter Operator Identifier (IOI) to enable
   different operators involved in a SIP dialog or a transaction outside
   a dialog to identify each other by exchanging operator identification
   information within the P-Charging-Vector header field.

   In the interconnection scenarios in multi-operator environments,
   where one or more transit operators are between the originating and
   terminating operator, the identities of the involved transit
   operators are represented by a transit-ioi parameter of the P-
   Charging-Vector header field.

   Transit operators can be selected independently for each SIP method
   and direction of request.  A transit network will only have knowledge
   of an individual SIP request, and transit network selection will be
   an independent decision for each request and could be made based on
   load, cost, percentage, time of day, and other factors.  For this
   reason, it is necessary that the P-Charging-Vector header field,
   which carries the transit IOI information, is included in each SIP
   request and response.  However, [RFC7315] does not allow the usage of
   the P-Charging-Vector header field in the SIP ACK request.

   A SIP proxy that supports this extension and receives the SIP ACK
   request may include a P-Charging-Vector header field in the SIP ACK
   request.

Holmberg, et al.        Expires 21 February 2025                [Page 5]
Internet-Draft          Update to Private Header             August 2024

   The P-Charging-Vector header field shall not be included in SIP ACK
   requests triggered by SIP non-2xx responses.

3.  Updates to RFC 7315

   This section implements the update to Section 5.7 of [RFC7315], in
   order to implement the misalignment fixes and the 3GPP requirements
   described in Section 2.

   Old text:

   The P-Associated-URI header field can appear in SIP REGISTER method
   and 2xx resonses [sic].  The P-Called-Party-ID header field can
   appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE
   methods and all responses.  The P-Visited-Network-ID header field can
   appear in all SIP methods except ACK, BYE, and CANCEL and all
   responses.  The P-Access-Network-Info header field can appear in all
   SIP methods except ACK and CANCEL.  The P-Charging-Vector header
   field can appear in all SIP methods except CANCEL.  The P-Charging-
   Function-Addresses header field can appear in all SIP methods except
   ACK and CANCEL.

   New text:

   The P-Associated-URI header field can appear in SIP REGISTER 2xx
   responses.  The P-Called-Party-ID header field can appear in the SIP
   INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The
   P-Visited-Network-ID header field can appear in all SIP methods and
   the associated non-100 response message except ACK, BYE, CANCEL,
   NOTIFY, PRACK, INFO, UPDATE.  The P-Access-Network-Info header field
   can appear in all SIP methods and the associated non-100 responses,
   except in CANCEL methods, CANCEL responses, and ACK methods triggered
   by non-2xx responses.  The P-Charging-Vector header field can appear
   in all SIP methods and the associated non-100 responses, except in
   CANCEL methods, CANCEL responses, and ACK methods triggered by non-
   2xx responses.  The P-Charging-Function-Addresses header field can
   appear in all SIP methods and the associated non-100 responses,
   except in CANCEL methods, CANCEL responses, and ACK methods.

4.  Security Considerations

   The security considerations for these "P-" header fields are defined
   in [RFC7315].  This specification allows some header fields to be
   present in messages where they were previously not allowed, and the
   security considerations and assumptions described in [RFC7315] (e.g.,
   regarding only sending information to trusted entities) also apply to
   those messages.  In addition, this specification also disallows some
   header fields to be present in messages where they were previously

Holmberg, et al.        Expires 21 February 2025                [Page 6]
Internet-Draft          Update to Private Header             August 2024

   allowed.  That does not cause any security issues, but implementors
   need to be aware that implementations may not have been updated
   according to this document, and take proper actions if a header field
   occurs, or does not occur, in a message where it should occur (or
   occurs in a message where it should not occur).  This document adds
   the ability to include P-Access-Network-Info in ACK requests.  As
   documented in [RFC7315], P-Access-Network-Info may include privacy
   sensitive information, including the user's location.  The security
   and privacy considerations for P-Access-Network-Info in ACK requests
   are similar to those for the other SIP requests discussed in
   [RFC7315].  The security and privacy considerations for the P-
   Visited-Network-ID header field are similar to those for the other
   SIP responses discussed in [RFC7315].

5.  Acknowledgments

   The author would like to acknowledge the constructive feedback
   provided by Michael Kreipl, Charles Eckel and Paul Kyzivat Thanks to
   Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach for
   providing comments on the former version of the document.

6.  References

6.1.  Normative References

   [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>.

   [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>.

   [TS23-228] 3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; "IP
              multimedia call control protocol based on Session
              Initiation Protocol (SIP) and Session Description Protocol
              (SDP);", TS 23.228, V 13.6.0, June 2016.

6.2.  Informative References

Holmberg, et al.        Expires 21 February 2025                [Page 7]
Internet-Draft          Update to Private Header             August 2024

   [RFC3455]  Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
              Header (P-Header) Extensions to the Session Initiation
              Protocol (SIP) for the 3rd-Generation Partnership Project
              (3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003,
              <https://www.rfc-editor.org/info/rfc3455>.

   [TS24-229] 3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; IP
              multimedia call control protocol based on Session
              Initiation Protocol (SIP) and Session Description Protocol
              (SDP); Stage 3", TS 24.229, V 13.6.0, June 2016.

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   FI-02420 Jorvas
   Finland
   Email: christer.holmberg@ericsson.com

   Nevenka Biondic
   Ericsson
   Krapinska 45
   HR-10002 Zagreb
   Croatia
   Email: nevenka.biondic@ericsson.com

   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7200-12 Kit Creek Road
   Research Triangle Park,  NC 27709
   United States of America
   Email: gsalguei@cisco.com

   Roland Jesske
   Deutsche Telekom
   Ida-Rhodes-Str. 2
   64295 Darmstadt
   Germany
   Email: r.jesske@telekom.de
   URI:   www.telekom.de

Holmberg, et al.        Expires 21 February 2025                [Page 8]