Zusammenfassung

  • RFC 9878 erlaubt P-Access-Network-Info und P-Charging-Vector in einem durch 2xx ausgelösten ACK, schließt sie aber im ACK zu einer Nicht-2xx-Antwort aus.
  • Der zulässige Ort belegt nicht, wer den Wert eingesetzt hat, wie aktuell er war, ob die Bearer-Änderung gelang oder ob der berechnete Preis geschuldet war.
  • Eine belastbare Spur verbindet SIP-Kontext, Hop-Provenienz, NPLI, richtungsabhängige Transits, Bearer-Ereignis, CDR, Tarifregel und anfechtbares Ergebnis.

In einer komprimierten Betriebsdatenbank sehen zwei ACK-Nachrichten leicht gleich aus. Eine folgt auf 200 OK, die andere auf eine fehlgeschlagene endgültige Antwort. Wird nur die Methode gespeichert, verschwindet genau der Unterschied, von dem die Zulässigkeit zweier abrechnungsnaher Header abhängt.

Der im November 2025 veröffentlichte RFC 9878 aktualisiert RFC 7315 und ersetzt RFC 7976. Er beseitigt Widersprüche zwischen den Definitionen der privaten SIP-Header und einer alten Zusammenfassung ihrer erlaubten Nachrichten. Das beendet Interpretationsspielraum zwischen Implementierungen. Es bescheinigt jedoch keine einzelne Nutzlast.

Der Erfolgszweig zählt

P-Access-Network-Info kann Network Provided Location Information, kurz NPLI, transportieren. P-Charging-Vector kann IMS-Abrechnungsidentitäten und Betreiberkennungen führen. Beide dürfen im ACK vorkommen, wenn eine 2xx-Antwort dieses ACK ausgelöst hat. Im ACK zu einer Nicht-2xx-Antwort dürfen sie nicht vorkommen.

RFC 3261 behandelt das ACK nach Erfolg auch transaktional anders als das ACK nach Fehlschlag. Ein Nachweis braucht daher die endgültige Antwortklasse, Call-ID, Tags, CSeq, Richtung und den Proxy, der den Übergang verarbeitet hat. Ein nacktes ACK ist keine ausreichende Ereignisbeschreibung.

Der NPLI-Fall erklärt den neuen Weg. Eine 2xx-Antwort auf INVITE kann eine SDP-Antwort enthalten, die einen Proxy zur Änderung des Bearers veranlasst. Das IMS-CDR soll die Standortinformation zu diesem Zeitpunkt erfassen. Der Proxy kann NPLI beschaffen und im folgenden ACK mitgeben.

Damit ist der Transportbedarf begründet. Nicht bewiesen sind Aktualität und Berechtigung der NPLI, der tatsächliche Abschluss der Bearer-Änderung, die Zuordnung zum richtigen Dialog oder die Anwendbarkeit eines Tarifs. „Für korrekte Abrechnung erforderlich“ ist eine Prozessanforderung und kein Beweisprivileg für ein einzelnes Feld.

Sechs Header, unterschiedliche Grenzen

Die weiteren Korrekturen sind ebenso schmal. P-Associated-URI gehört in 2xx-Antworten auf REGISTER. P-Called-Party-ID ist für eine aufgezählte Gruppe von Anfragen einschließlich REFER vorgesehen, nicht pauschal für Antworten. P-Visited-Network-ID ist in Nicht-100-Antworten möglich, aber aus mehreren Methoden ausgeschlossen. P-Charging-Function-Addresses bleibt in ACK und CANCEL unzulässig.

Diese Matrix beantwortet eine Parserfrage. Sie sagt nicht, welcher Akteur zum Schreiben befugt war. Auch das IANA-Verzeichnis der SIP-Parameter standardisiert Namen und Verweise; es zertifiziert keine beobachtete Nachricht.

RFC 9878 weist zudem auf nicht aktualisierte Implementierungen hin. Ein fehlender Header kann alte Software, lokale Policy, einen nicht einschlägigen Fall oder einen Fehler bedeuten. Ein unerwarteter Header kann aus der früheren Lesart, einem Defekt oder einem nicht vertrauenswürdigen Eingang stammen. Ohne Versions- und Pfaddaten ist weder Konformität noch Missbrauch festgestellt.

Legitime Änderungen hinterlassen sonst keine Herkunft

RFC 7315 begrenzt die Mechanismen auf private Verwaltungsdomänen oder Domänen mit Vertrauensbeziehung. Ein Proxy mit geeigneten Informationen darf einen eigenen network-provided-Wert hinzufügen. Vor der Weitergabe an eine nicht vertrauenswürdige Stelle muss sensible Information entfernt werden. Von dort empfangene Inhalte können nicht als gültig garantiert werden.

Der Charging Vector ist absichtlich veränderbar. Vertrauenswürdige Proxies dürfen Parameter einfügen, lesen, ändern oder entfernen. Integritätsschutz muss deshalb Hop für Hop greifen: Ein Angreifer soll nicht eingreifen, ein berechtigter Vermittler aber schon. Der fertige Header am Ziel erzählt ohne gesondertes Custody-Protokoll nicht, wer welchen Wert beigetragen hat.

Auch transit-ioi ist kein vollständiger Reiseplan. Werte können gefiltert, gelöscht oder durch Leerwerte ersetzt werden. Nach RFC 9878 kann die Transitauswahl für jede SIP-Methode und jede Anfragerichtung neu nach Last, Kosten, Quote oder Tageszeit erfolgen. Der INVITE-Pfad darf nicht als ACK-Pfad oder als Route der gesamten Sitzung verbucht werden.

NPLI bringt ein Datenschutzrisiko hinzu. Es kann sensible Funkzellen- oder Zugangsinformation enthalten. Das Vertrauensmodell verlangt Schutz innerhalb der Domäne und Entfernung an ihrer Grenze. Eine ungezielte Kopie aller SIP-Signale in einen breit zugänglichen Data Lake bewahrt Bytes, aber nicht Zweckbindung.

Die Rechnung braucht eine nachrechenbare Verknüpfung

Zu sichern sind Rohmeldung, Empfangszeit, Antwortklasse, Dialog- und Transaktionskoordinaten, Richtung, Proxy-Version und gültige Platzierungsregel. Für jeden P-Header kommen vertrauenswürdiger Eintritt, einfügender oder ändernder Akteur, Hop-Schutz und Vorher-/Nachher-Fingerprint hinzu. NPLI braucht Quelle, Erhebungszeit, Granularität und erlaubten Zweck.

Erst danach wird mit SDP-Antwort, tatsächlicher Einrichtung, Änderung oder Freigabe des Bearers, CDR, Rating-Regel und Rechnungszeile verbunden. Eine ICID hilft beim Korrelieren; sie schafft keinen Zahlungsanspruch. Schlägt die Verknüpfung fehl, lautet der Zustand „abzugleichen“ und nicht „durch Header bestätigt“.