Summary

  • RFC 9878 updates RFC 7315 because its statements about which SIP requests and responses may carry several 3GPP P-Headers became contradictory or no longer matched 3GPP use cases.
  • The replacement is a per-header, per-message matrix. It is not a blanket permission and it does not authenticate a received value.
  • ACK handling depends on the response that triggered it: a 2xx-triggered ACK is not equivalent to an ACK triggered by a non-2xx response.

RFC 7315 supplied the base definitions and security assumptions for private 3GPP network use, but its applicability text could lead implementations to different conclusions. RFC 9878 replaces those rules and obsoletes RFC 7976. It removes REGISTER-request use for P-Associated-URI, removes response use for P-Called-Party-ID, and adds REFER-request use for P-Called-Party-ID.

The matrix also says that P-Visited-Network-ID may occur in associated non-100 responses. It is not allowed in ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, or UPDATE requests. This extends the response rule associated with RFC 7976 beyond registration responses. A receiver should therefore validate both the field and the message context rather than apply a general “response allowed” or “request allowed” rule.

The sharpest operational distinction concerns ACK. P-Access-Network-Info may appear in an ACK triggered by a 2xx response, but not in CANCEL or in an ACK triggered by a non-2xx response. The field can carry privacy-sensitive, network-provided location information used in IMS charging events. Presence is consequently a protocol-scope fact, not permission to disclose location outside the RFC 7315 privacy boundary.

P-Charging-Vector may appear in a 2xx-triggered ACK and in associated non-100 responses, but not in CANCEL or in an ACK triggered by a non-2xx response. Its transit-ioi can identify transit operators selected independently by request and direction. P-Charging-Function-Addresses is allowed in associated non-100 responses but excluded from CANCEL and ACK requests.

These fields remain bounded by RFC 7315 assumptions about private networks and trusted entities. Those assumptions must not be extended to the open Internet. Nor does an allowed field become authentic, accurate, safe, or evidence of billing correctness merely because RFC 9878 permits its presence. RFC 9878 is an informational update, not an Internet Standards Track specification.

Sources