Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses

Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses Ericsson

Hirsalantie 11 Jorvas 02420 Finland christer.holmberg@ericsson.com

ETSI

650 route des Lucioles Sophia Antipolis cedex 06921 France Nevenka.Biondic@etsi.org

Cisco Systems, Inc.

7200-12 Kit Creek Road Research Triangle Park NC 27709 United States of America gsalguei@cisco.com

Deutsche Telekom

Deutsche-Telekom-Allee 9 Darmstadt 64295 Germany r.jesske@telekom.de www.telekom.com

ART sipcore 3GPP Visited ID 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 where they were 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 obsoletes RFC 7976. The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses. This document also makes updates to RFC 7315 in order to fix misalignments that occurred when RFC 3455 was obsoleted by RFC 7315.

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 .

Copyright Notice Copyright (c) 2025 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 () 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

. Introduction
. Misalignments and 3GPP Use Cases
- . General
- . Misalignments
- . 3GPP Use Cases
  - . General
  - . P-Access-Network-Info
  - . P-Charging-Vector
. Updates to RFC 7315
. IANA Considerations
. Security Considerations
. Operational considerations
. Changes since RFC 7976
. References
- . Normative References
- . Informative References
Acknowledgments
Authors' Addresses

Introduction The Third Generation Partnership Project (3GPP) has identified cases where different Session Initiation Protocol (SIP) private header extensions referred to as "P-" header fields, and defined in , need to be included in SIP requests and responses where they were not allowed according to . This document updates , in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document also makes updates to in order to fix misalignments that occurred when was updated and subsequently obsoleted by the publication of .

Misalignments and 3GPP Use Cases

General contains contradictory 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 are not aligned with the definitions and usage of the SIP "P-" header fields specified in . This section describes the misalignments that occurred when was updated and subsequently obsoleted by the publication of , and how they are fixed. Since 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 in order to support the use cases. updates , based on the misalignments and 3GPP use cases.

Misalignments The following updates are needed in order to fix the misalignments that occurred when was obsoleted by :

P-Associated-URI: Remove the statement that the header field can appear in the SIP REGISTER method.
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.
P-Access-Network-Info: Add a statement that the P-Access-Network- Info header field can appear in SIP responses.
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.
P-Charging-Function-Addresses: Add a statement that the P-Charging-Function-Addresses header field can appear in SIP responses.

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

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 the P-Visited-Network-ID header field can appear in all non-100 (Trying) responses.

3GPP Use Cases

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

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

P-Access-Network-Info The P-Access-Network-Info header field may contain the Network Provided Location Information (NPLI). The NPLI is described in . 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 . Based on operator policy, roaming agreement, or both, 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:

when the bearer establishment is triggered, or
at session release when the bearer deactivation is triggered, or
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 the SIP 2xx response to the SIP INVITE request. In such case, the NPLI needs to be provided within the SIP ACK request. However, does not allow the usage of the P-Access-Network-Info header field in a SIP ACK request. Upon reception of the SDP answer within a 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.

P-Charging-Vector 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, 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. The P-Charging-Vector header field shall not be included in SIP ACK requests triggered by non-2xx responses.

Updates to RFC 7315 This section contains the update to , in order to implement the misalignment fixes and the 3GPP requirements described in . In the old text, blank lines have been added for readability. 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 requests. The P-Visited-Network-ID header field can appear in all SIP requests and the associated non-100 response message except in ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, UPDATE. The P-Access-Network-Info header field can appear in all SIP requests and the associated non-100 responses, except in CANCEL requests, CANCEL responses, and ACK methods triggered by non-2xx responses. The P-Charging-Vector header field can appear in all SIP requests and the associated non-100 responses, except in CANCEL requests, CANCEL responses, and ACK requests 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 requests, CANCEL responses, and ACK requests.

IANA Considerations This document has no IANA actions.

Security Considerations The security considerations for these "P-" header fields are defined in . 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 (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 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 , 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 . The security and privacy considerations for the P-Visited-Network-ID header field are similar to those for the other SIP responses discussed in .

Operational considerations 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 , the updates are not seen to cause backward-compatibility concerns.

Changes since RFC 7976 The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses. Specifically, any SIP response message, with the exception of a 100 (Trying) response, may include a P-Visited-Network-ID header field.

References Normative References SIP: Session Initiation Protocol This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455. IP Multimedia Subsystem (IMS); Stage 2 3rd Generation Partnership Project IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 3rd Generation Partnership Project Informative References Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.

Acknowledgments The author would like to acknowledge the constructive feedback provided by , , and . Thanks to , , , and for providing comments on an earlier draft version of this document.

Authors' Addresses Ericsson