Summary

  • RFC 9878 corrects contradictory rules for six 3GPP SIP P-Headers and permits P-Access-Network-Info and P-Charging-Vector in an ACK only when a 2xx response triggered that ACK.
  • Legal placement proves that a field may travel in that message. It does not prove who inserted it, whether its value is complete, or whether a related bearer event and charge were correct.
  • A defensible billing trail joins message context, protected-hop provenance, directional transit data, NPLI age, bearer events, CDRs, rating policy and a reviewable outcome.

A proxy receives a 200 response to an INVITE. The response carries an SDP answer that triggers a bearer change. The proxy obtains Network Provided Location Information, adds P-Access-Network-Info to the ACK, and also carries a P-Charging-Vector. A downstream system sees both fields and marks the charging record complete.

The first part of that sequence can be compliant with RFC 9878. The last part is still a separate decision.

Published in November 2025, RFC 9878 updates RFC 7315 and obsoletes RFC 7976. It repairs contradictions left between the definitions of private SIP headers and an old summary of which requests and responses could contain them. The repair matters because different readings produced different implementations. Yet the document changes message admissibility, not the epistemic status of every value carried inside an admissible message.

The small word that controls the ACK

Two headers expose the boundary most clearly. P-Access-Network-Info may contain NPLI, including a network-provided access or location value. P-Charging-Vector may carry an IMS charging identity and operator identifiers. RFC 9878 allows both in an ACK when the ACK was triggered by a 2xx response. It says they shall not be included in ACKs triggered by non-2xx responses.

That qualifier is protocol state, not editorial nuance. RFC 3261 gives ACK different transaction treatment after successful and unsuccessful final responses. A record that stores only method=ACK has already discarded the condition that made these fields permissible. The final response class, dialog identifiers, CSeq, direction and the proxy that handled the transition belong in the evidence.

RFC 9878's NPLI example explains why the new path exists. An SDP answer in a 2xx response to INVITE can lead a proxy to initiate bearer-modification procedures. The network may need the location information at that modification event for its Call Data Records. The ACK is the next suitable request in which the proxy can provide it.

This establishes a transport need. It does not establish that a particular NPLI value was fresh, that the proxy was authorised to assert it, that the bearer modification completed, or that a tariff applied. “Needed for correct billing” describes the role of a data element in the specified IMS process. It is not a rule that the element alone settles a disputed invoice.

A corrected matrix, not a universal licence

The rest of the update shows how narrow placement rules are. P-Associated-URI belongs in REGISTER 2xx responses rather than the REGISTER request. P-Called-Party-ID is permitted in a defined list of requests, now including REFER, but not indiscriminately in responses. P-Visited-Network-ID can occur in non-100 responses but is excluded from several request methods. P-Charging-Function-Addresses remains excluded from ACK and CANCEL.

These are useful parser and forwarding rules. They do not say a registered field name is trustworthy wherever it parses. The IANA SIP Parameters registry gives implementations common names and parameter references. Registration is not certification of a message instance.

RFC 9878 also warns that deployed implementations may not have adopted the corrected rules. A missing field could reflect old software, local policy, a failed enrichment step or an inapplicable use case. An unexpected field could reflect an old interpretation, a malformed message or a boundary failure. Neither observation names the cause without version and path evidence.

Trust is carried hop by hop

RFC 7315 confines these mechanisms to private administrative settings or relationships between trusted domains. A proxy may insert its own network-provided access information when it has appropriate knowledge. It must remove sensitive network-provided data before sending outside the trusted domain. Content received from an untrusted entity cannot have its validity guaranteed and should be deleted according to local policy.

Charging vectors are deliberately mutable. Trusted proxies may insert, read, modify or remove parameters. Hop-by-hop integrity protection is therefore required where an untrusted intermediary could interfere, but end-to-end immutability would defeat legitimate proxy processing. A clean header at the destination does not reveal which hop supplied each value unless the operation recorded that custody separately.

transit-ioi makes completeness even harder. RFC 7315 allows several transit values, but screening and trust rules can delete them or replace them with void entries. RFC 9878 adds that transit operators may be selected independently for each SIP method and request direction, based on load, cost, percentage or time. The route observed for INVITE cannot silently be reused as the route for ACK, the opposite direction or the entire commercial session.

NPLI adds privacy risk. Access information can include sensitive cell-level data. The rules require a protected private domain and removal at its boundary. An organisation that copies raw headers into a broad analytics lake may preserve syntax while violating the trust model that made the syntax tolerable.

Build an evidence join, not a green bit

The minimum record starts with the raw request or response, its receive time, method, status class, dialog and transaction coordinates, direction, software version and active rule set. For every P-Header, preserve the trusted ingress, inserting or modifying actor, protected-hop result and before/after fingerprint. For NPLI, keep source type, acquisition time, precision and purpose. For a charging vector, retain ICID, related ICID and the directional sequence of operator identifiers without pretending absence means non-participation.

Then join signalling to a separate bearer event and CDR. Record whether establishment, modification or deactivation actually occurred; which SDP answer was involved; what rating rule consumed the event; how the invoice line was calculated; and who can correct it. The join may fail. That is a useful operational state, not an invitation to fill the gap with the header.