wdiff rfc9878v1.txt rfc9878.txt

Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 9878 N. Biondic
Obsoletes: 7976 Ericsson
Updates: 7315 G. Salgueiro
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 R. Jesske
Deutsche Telekom
October 2025

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

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 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 updated and
subsequently obsoleted by the publication of 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
https://www.rfc-editor.org/info/rfc9878.

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. Misalignments and 3GPP Use Cases
2.1. General
2.2. Misalignments
2.3. 3GPP Use Cases
2.3.1. General
2.3.2. P-Access-Network-Info
2.3.3. P-Charging-Vector
3. Updates to RFC 7315
4. IANA Considerations
5. Security Considerations
6. Operational considerations
7. Changes since RFC 7976
8. Acknowledgments
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses

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 where
they were 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 to [RFC7315] in order to fix
misalignments that occurred when [RFC3455] was updated and
subsequently obsoleted by the publication of [RFC7315].

2. Misalignments and 3GPP Use Cases

2.1. General

[RFC7315] 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 Section 5.7 of [RFC7315] are not aligned with the
definitions and usage of the SIP "P-" header fields specified in
Section 4 of [RFC7315]. This section describes the misalignments
that occurred when [RFC3455] was updated and subsequently obsoleted
by the publication of [RFC7315], and how they are fixed.

| NOTE: In the case of the P-Called-Party-ID header field,
| allowing it in PUBLISH requests was done deliberately 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
that occurred when [RFC3455] was obsoleted by [RFC7315]:

* 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 [RFC7315]:

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

2.3. 3GPP Use Cases

2.3.1. 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 [TS24.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
[TS23.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, 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 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,
[RFC7315] 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.

2.3.3. P-Charging-Vector

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

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 contains the update to Section 5.7 of [RFC7315], in
order to implement the misalignment fixes and the 3GPP requirements
described in Section 2. In the old text, blank lines have been added
for readability.

Old text:

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.

4. IANA Considerations

This document has no IANA actions.

5. 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
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
Section 6.4 of [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 Section 6.3 of [RFC7315].

6. 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 [TS24.229], the updates are not
seen to cause backward-compatibility concerns.

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

8. 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 an earlier draft version of this document.

9. References

9.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, "IP Multimedia Subsystem (IMS); Stage 2", Version
13.6.0, Release 13, 3GPP
TS 23.228, June 2016,
<https://www.3gpp.org/ftp//Specs/
archive/23_series/23.228/23228-g30.zip>.
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=821>.

[TS24.229] 3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", Version 13.6.0, Release 13, 3GPP TS 24.229, June 2016, <https://www.3gpp.org/ftp/Specs/
archive/24_series/24.229/24229-d60.zip>.
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1055>.

9.2. Informative References

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

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.ext@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
Telekom Allee 9
64295 Darmstadt
Germany
Email: r.jesske@telekom.de
URI: www.telekom.com