RFC 7976

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

📅 published September 2016, from ietf

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

Okay bestie, here's the whole deal at a glance 🦋

  • Request for Comments: 7976
  • Title: Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses
  • Authors: C. Holmberg (Ericsson), N. Biondic (Ericsson), G. Salgueiro (Cisco)
  • Category: Informational
  • ISSN: 2070-1721
  • Date: September 2016
  • Updates: RFC 7315 💅
  • Obsoletes: nothing listed here

Abstract 💜

So, 3GPP noticed that some of the SIP private header extensions, the ones called "P-" header fields and defined in RFC 7315, need to show up in SIP requests and responses where RFC 7315 currently says no way 🙈 This doc updates RFC 7315 so those affected "P-" header fields are allowed in those spots.

It also fixes some misalignments that showed up when RFC 3455 got updated and obsoleted by RFC 7315. Lowkey important clean-up 🧹✨

Status of This Memo 🎀

This document is not an Internet Standards Track specification. It's published for informational purposes, so it isn't a standard, just good info 🌸

It's a product of the Internet Engineering Task Force (IETF), which means it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full scoop 💖

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7976 🔥

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified 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 . . . . . . . . . . . . . . . . . . .   7
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction 💖

So 3GPP found cases where different SIP [RFC3261] private header extensions, the "P-" header fields defined in [RFC7315], need to be included in SIP requests and responses that RFC 7315 doesn't currently allow. This document updates RFC 7315 so the affected "P-" header fields can show up in those requests and responses. Main character moment 👑

This doc also updates RFC 7315 to fix misalignments that happened when RFC 3455 [RFC3455] got updated and obsoleted by RFC 7315. Clean-up arc 🧚

The "P-" header fields are mostly used in (and in most cases only defined for) networks run by 3GPP, where the updates in this document are already defined in [TS.3GPP.24.229]. So the updates aren't expected to cause backward-compatibility problems, which is honestly so iconic 🌈

2. Misalignments and 3GPP Use Cases 🦋

2.1. General

RFC 7315 has statements that contradict each other about using SIP "P-" header fields in SIP requests and responses. That leaves it open to interpretation, so implementations can end up doing different things 😭 The statements in Section 5.7 of that RFC don't line up with how the SIP "P-" header fields are defined and used in Section 4. This section covers the misalignments that happened when RFC 3455 was updated and obsoleted by RFC 7315, plus how they get fixed.

NOTE: For the P-Called-Party-ID header field, letting it into PUBLISH requests was done on purpose in RFC 7315. So it isn't counted as a misalignment, periodt 💅

Since RFC 7315 came out, 3GPP has defined new use cases that need the RFC to be updated. This section walks through those 3GPP use cases and the updates RFC 7315 needs to support them ✨

Section 3 updates RFC 7315 based on the misalignments and the 3GPP use cases 🎀

2.2. Misalignments

These updates are needed to fix the misalignments between RFCs 7315 and 3455:

  • 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-Visited-Network-ID: Delete the statement that the P-Visited-Network-ID header field can appear in SIP responses. Add a statement that the P-Visited-Network-ID header field cannot appear in the SIP NOTIFY, PRACK, INFO, and UPDATE methods.
  • 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.

2.3. 3GPP Use Cases

2.3.1. General

These updates are needed to implement the 3GPP use cases 🧁

  • P-Access-Network-Info: Add a statement that the P-Access-Network-Info header field can appear in the SIP ACK method when it's triggered by a SIP 2xx response.
  • P-Charging-Vector: Add a statement that the P-Charging-Vector header field can appear in the SIP ACK method when it's triggered by a SIP 2xx response.

The following sections go through each individual "P-" header field and the 3GPP use cases behind 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 that has the right info about the access technology might insert a P-Access-Network-Info header field with its own values. Those values are identified by the string "network-provided", which is defined in RFC 7315. Depending on operator policy and/or roaming agreement, the local time of the visited network may be included too 🌸

The Call Data Records (CDRs) generated within the IP Multimedia Subsystem (IMS) have to contain the NPLI so billing stays correct 💸 When an IMS session gets modified, the NPLI also needs to be stored, because the user's location at the moment of the modification may create a charging event. For 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 proxy may trigger the bearer modification after it receives a Session Description Protocol (SDP) answer within a SIP 2xx response to the SIP INVITE request. In that case, the NPLI needs to be provided within the SIP ACK request. The catch is that RFC 7315 doesn't allow the P-Access-Network-Info header field in a SIP ACK request 😤

When a proxy gets the SDP answer within a SIP 2xx response on the SIP INVITE request, it might start procedures to get the NPLI, and it 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

RFC 7315 defines an Inter Operator Identifier (IOI) so that different operators involved in a SIP dialog, or in a transaction outside a dialog, can identify each other by exchanging operator identification information within the P-Charging-Vector header field 🦋

In interconnection scenarios with multiple operators, one or more transit operators can sit between the originating and terminating operators. The identities of those 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 each direction of request. A transit network only knows about an individual SIP request, so transit network selection is an independent decision for every request. It could be based on load, cost, percentage, time of day, and other factors 🎲 That's why the P-Charging-Vector header field, which carries the transit IOI information, needs to be included in each SIP request and response. However, RFC 7315 doesn't allow 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 🙅‍♀️

To be continued in Part 2! Section 3 (Updates to RFC 7315) is up next, along with Security Considerations, References, Acknowledgments, and Authors' Addresses 🎀

3. Updates to RFC 7315 ✨

okay bestie, this section is the actual fix. It updates Section 5.7 of [RFC7315] so the misalignment fixes and the 3GPP requirements from Section 2 finally line up 💅 Here's what the header fields looked like before, then what they look like now.

Old text:

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

New text:

  • P-Associated-URI: SIP REGISTER 2xx responses only 🎀
  • P-Called-Party-ID: INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.
  • P-Visited-Network-ID: all SIP methods except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE.
  • P-Access-Network-Info: all SIP methods and non-100 responses, except CANCEL methods, CANCEL responses, and ACK methods triggered by non-2xx responses.
  • P-Charging-Vector: all SIP methods and non-100 responses, except CANCEL methods, CANCEL responses, and ACK methods triggered by non-2xx responses.
  • P-Charging-Function-Addresses: all SIP methods and non-100 responses, except CANCEL methods, CANCEL responses, and ACK methods. 🦋

4. Security Considerations 🔐

okay this part is serious, so read it carefully 🫶

The security considerations for these "P-" header fields are defined in [RFC7315]. This spec lets some header fields show up in messages where they weren't allowed before. The security considerations and assumptions in [RFC7315] (for example, only sending information to trusted entities) also apply to those messages.

It also goes the other way. This spec stops some header fields from showing up in messages where they used to be allowed. That doesn't cause any security issues by itself, but implementors need to be aware that implementations may not have been updated to match this document. So they need to take proper action when a header field appears, or doesn't appear, in a message where it should (or shouldn't). 😭

This document adds the ability to include P-Access-Network-Info in ACK requests. As [RFC7315] explains, 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]. 🌸

Heads up: P-Access-Network-Info can carry the user's location. Treat it like the sensitive info it is, and only send it to trusted entities. ✨

5. References 📚

5.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, http://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, http://www.rfc-editor.org/info/rfc7315.

[TS.3GPP.23.228] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 23.228 13.6.0, June 2016, http://www.3gpp.org/ftp/Specs/html-info/23228.htm.

[TS.3GPP.24.229] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 24.229 13.6.0, June 2016, http://www.3gpp.org/ftp/Specs/html-info/24229.htm.

5.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, http://www.rfc-editor.org/info/rfc3455.

Acknowledgments 🫶

Huge thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach for reviewing the document and leaving comments. You're all iconic 👑

Authors' Addresses 🧚

Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

Email: christer.holmberg@ericsson.com


Nevenka Biondic
Ericsson
Krapinska 45
Zagreb  10002
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
📦 where this page comes from