Zusammenfassung

  • History-Info bewahrt die von unterstützenden Vermittlern offengelegten Request-URIs einer initialen oder dialogfremden Anfrage. hi-index bildet einen geordneten Verzweigungsbaum; rc, mp und np beschreiben drei Arten von Ziel- oder Next-Hop-Änderungen.
  • Die Erweiterung ist optional. Alte oder stellvertretend eingefügte Einträge, noch offene Zweige und gewollte Anonymisierung können die sichtbare Geschichte verkürzen. TLS/SIPS schützt nicht vor jeder Änderung durch einen bereits vertrauten Vermittler.
  • Belastbare Verantwortlichkeit verbindet den Baum mit Regelversion, Betreiberidentität, Datenquelle, Zweigzustand, Datenschutzverarbeitung, Folge-Transaktion und beobachtetem Ergebnis. Der Verlauf beschreibt eine Umleitung; er verleiht keine Umleitungsbefugnis.

Ein Prüfbericht ohne Entscheidungsträger

Ein Bereitschaftsdienst soll Anrufe zunächst an die regionale Leitstelle und nur bei deren Ausfall an einen externen Partner weitergeben. Nach einer Beschwerde zeigt das Monitoring einen makellosen History-Info-Baum: öffentliche Nummer, Leitstellenadresse, Partnerplattform. Die Indizes sind gültig, der letzte Zweig erhielt eine positive Antwort. Der Prüfbericht nennt den Ablauf deshalb „regelkonform“.

Im Bericht fehlt ausgerechnet die Regel.

Der Baum kann belegen, welche Ziel-URIs die beobachtete Nachricht enthielt. Er sagt nicht automatisch, welche Konfiguration aktiv war, wer sie freigab, ob die Standortdaten aktuell waren, ob der interne Zweig noch lief, ob eine Datenschutzgrenze ein Ziel verbarg, ob ein On-Path-Vermittler Einträge änderte oder ob beim Partner tatsächlich eine zuständige Person und ein funktionierender Medienpfad erreicht wurden.

RFC 7044 löst ein klar umrissenes Signalisierungsproblem. Beim normalen Retargeting ersetzt eine neue Request-URI die alte. History-Info bewahrt die ansonsten verlorenen Ziele initialer oder dialogfremder Anfragen. Die Spezifikation legt nicht fest, welche lokale Weiterleitungsregel institutionell zulässig ist.

Die laufende Regel entscheidet, der Header berichtet

Nach RFC 3261 ermittelt ein Proxy sein Ziel etwa über einen Location Service, eine Redirect-Antwort, Routeninformation oder lokale Konfiguration. Die ausgehende Request-URI bezeichnet den aktuellen Empfänger. Frühere Zielvorstellungen können ohne Zusatzmechanismus verschwinden.

RFC 7044 nennt es Retargeting, wenn eine Instanz die Request-URI anhand ihrer Zielermittlungsregeln ändert und die Anfrage weiterleitet. Der laufende Code in Proxy, PBX, B2BUA oder Anwendung erzeugt die operative Entscheidung. History-Info übermittelt einen Teil ihrer Spur.

Die IETF definiert das gemeinsame Format. Das IANA-Verzeichnis der SIP-Parameter registriert History-Info, histinfo, history, rc, mp und np. Registrierung weist Zuteilung nach, nicht Implementierung, Vollständigkeit oder Berechtigung einer lokalen Umleitung.

Auch der zeitliche Umfang ist eng. Der Mechanismus gilt für initiale oder dialogfremde Anfragen. Nachrichten in einem etablierten Dialog, Medien, Aufzeichnung, Bedienoberfläche, Abrechnung und menschliches Ergebnis brauchen eigene Belege.

Baumkoordinaten sind keine Uhr

Jeder Eintrag enthält eine Ziel-URI und einen hi-index. Nichtnegative, durch Punkte getrennte Ganzzahlen ordnen den Eintrag ein. Ein Kind verlängert den Index seines Elternknotens; ein Fork erzeugt Geschwister. Die Ausgabe folgt einer Preorder-Reihenfolge, damit der Empfänger die Struktur rekonstruieren kann.

So bleiben parallele Zweige von aufeinanderfolgenden Umleitungen unterscheidbar. Dennoch ist der Index kein Zeitstempel. Er misst keine Verzögerung, synchronisiert keine Knoten und beweist nicht, welcher Zweig zuerst abgeschlossen wurde.

Drei Mechanismusparameter beschreiben die Kante:

  • rc: Die Request-URI änderte sich, der Zielnutzer blieb aus Sicht des Knotens derselbe, etwa bei der Auflösung einer öffentlichen Adresse zu einem Contact.
  • mp: Die Anfrage wurde einem anderen Zielnutzer oder einer anderen Address-of-Record zugeordnet.
  • np: Nur der nächste Hop änderte sich; die Request-URI blieb unverändert.

Das sind Klassifikationen des einfügenden Knotens. rc beweist keine institutionelle Identität. mp enthält keine Genehmigung. np bestätigt nicht die Vertrauenswürdigkeit des nächsten Hops. Ein korrektes Etikett muss immer noch mit Regel und Quelldaten abgeglichen werden.

Warum Lücken zum korrekten Modell gehören

Die Unterstützung ist freiwillig. histinfo wird in Supported angekündigt und nicht über Require oder Proxy-Require jedem Hop aufgezwungen. Ein nicht unterstützender Knoten kann die sichtbare Kette ohne Fehlverhalten unterbrechen.

Einträge des abgelösten RFC 4244 können ebenfalls weiterlaufen. RFC 7044 verlangt ihre Weitergabe, untersagt jedoch erfundene rc-, mp- oder np-Angaben für nicht beobachtete alte Entscheidungen. Ein fehlender Parameter bedeutet möglicherweise Altbestand, nicht fehlendes Retargeting.

Passt die empfangene Request-URI nicht zum letzten Eintrag, fügt der Empfänger einen Eintrag im Namen des vorherigen Knotens hinzu. Sicher ist nur, dass sich das Ziel änderte. Weil der Empfänger den Mechanismus nicht sah, darf er ihn nicht klassifizieren. Der Lückeneintrag ist bewusst weniger aussagekräftig.

Forking erzeugt eine weitere Grenze. RFC 7044 zeigt einen Zweig mit 200, während ein Geschwisterzweig noch wartet. In der erfolgreichen Antwort kann kein zukünftiges Resultat des offenen Zweigs stehen. Eine am Gewinner erfasste Geschichte kann valide und trotzdem unvollständig sein.

Datenschutz kann Zweige absichtlich verbergen. Schon RFC 4244 zeigt, dass ein Upstream-Knoten dann ein Ziel erneut versuchen kann, weil er den privaten früheren Versuch nicht kennt. Datenschutz und Optimierung stehen hier in Spannung. Anwendungen brauchen sichere Defaults für Teilwissen.

Eine belastbare Aussage lautet deshalb: „Diese Nachrichtenkopie enthielt an diesem Messpunkt diese Einträge.“ Für „Das war der gesamte Weg“ reicht der Header allein nicht.

Reason bleibt eine Protokollerklärung

History-Info kann Reason-Information im URI-Headers-Teil tragen. RFC 3326 definiert unter anderem SIP- und Q.850-Ursachen und lässt mehrere Protokollräume zu. RFC 7044 nutzt solche Werte für bestimmte Fehlerantworten und Timeouts.

Damit lässt sich erklären, warum ein Zweig nach „besetzt“ oder Zeitablauf weiterlief. Der Wert beweist nicht die menschliche Absicht hinter einer Regel, ihre Legitimität, die Wahrhaftigkeit des meldenden Systems oder die geschäftliche Grundursache. Ohne Integritätsschutz kann er verändert oder entfernt werden. Seine Herkunft aus Nachricht, Instanz und Messpunkt gehört zum Datensatz.

Das Errata-Verzeichnis zu RFC 7044 führt drei Reported-Einträge zu Lückenindex, Antwortklassen für Reason und einem redaktionellen Verweis sowie zwei Rejected-Einträge. Reported bedeutet nicht Verified. Es sind Prüfpunkte für konkrete Implementierungen, keine bereits geltende Neufassung.

Datenschutz macht die sichtbare Wahrheit absichtlich kleiner

Alte Ziel-URIs können private Geräte, Aliasnamen, interne Abteilungen, Mailboxen und Netztopologie offenlegen. RFC 3323 erklärt, warum SIP-Datenschutz häufig Vermittler braucht: Sie erzeugen selbst Routinginformationen.

RFC 7044 ergänzt den Privacy-Wert history. Schutz kann die relevante Geschichte oder einzelne Einträge umfassen. Eine Domäne darf interne Pfade auch dann schützen, wenn die eingehende Anfrage keinen Schutz verlangt. Ein UAS kann das endgültige Ziel vor dem Ursprung verbergen. Ein Grenzdienst kann die URI durch eine Adresse unter anonymous.invalid ersetzen.

Das kann korrekte Datenschutzverarbeitung sein und ist nicht automatisch feindliche Manipulation. Es begrenzt aber die nachgelagerte Aussage. Der Datensatz sollte Grenze, Richtlinienversion, Transformation und eine geschützt zugängliche Zuordnung für berechtigte Prüfer nennen.

Zielauswahl und Zielverbergung sind unterschiedliche Befugnisse. Eine pauschale „Normalisierung“ darf beide Entscheidungen nicht unsichtbar machen.

TLS sichert den Kanal, nicht jede Aussage

RFC 7044 empfiehlt TLS nachdrücklich oder setzt eine sichere Umgebung voraus. SIPS wehrt in seinem Vertrauensmodell beliebige Off-Path-Änderungen ab. On-Path-Vermittler müssen History-Info jedoch lesen und ergänzen.

Ein böswilliger oder kompromittierter Vermittler kann Einträge löschen, umsortieren oder umschreiben. RFC 7044 erklärt ausdrücklich, dass der Mechanismus dies weder verhindert noch erkennt. Der Header ist so sicher wie die übrigen SIP-Header auf dem Weg, nicht sicherer.

Deshalb gehören TLS-Peer, Zertifikatsergebnis, Vertrauensdomäne, Nachrichtenfingerabdruck und Messpunkt in die Beweiskette. „Über SIPS transportiert“ ist keine Ende-zu-Ende-Beglaubigung aller Erzähler.

Die Anwendung muss ihre Leseregel offenlegen

RFC 7044 verlangt Anwendungsdefaults für fehlende oder unvollständige Historie. Unterschiedliche Dienste dürfen unterschiedliche rc-Positionen benötigen.

Eine Unternehmens-PBX und eine Verbraucher-Mailbox können eine andere relevante angerufene Identität wählen. Wurde der Anruf vor dem Unternehmenseingang weitergeleitet, kann „nimm das erste rc“ eine externe Person fälschlich zum Unternehmensziel machen. RFC 4458 zeigt für Voicemail, dass target- und cause-Information je nach Unterstützung und Pfad in der aktuellen Request-URI oder in History-Info stehen kann.

Die Anwendung muss Zweck, vertrauenswürdige Domänen, Lücken- und Datenschutzbehandlung sowie Konfliktregel benennen. Das entspricht Heng Lus schmaler gemeinsamer Ausgangsspezifikation: Koordination im gemeinsamen Layer, normale Folgeentscheidungen bei den Beteiligten mit Kontext und Risiko. Die lokale Regel darf deshalb nicht verborgen und als Protokollurteil ausgegeben werden.

Das Entscheidungsdossier neben dem Baum

Bewahrt werden zunächst Methode, empfangene und gesendete Request-URI, Call-ID, CSeq, Via branch, Zeit, Messpunkt und kontrollierter Fingerabdruck.

Empfangener und gesendeter Baum bleiben getrennt: Reihenfolge, Index, URI, rc/mp/np-Verweis, Reason, Privacy, Altformat, Parsergebnis und stellvertretender Lückeneintrag. Unbekannte Mechanismen werden nicht ergänzt.

Die Entscheidung erhält ihren eigenen Nachweis: Regel-ID und Version, Abfragequelle, Ergebnis, Redirect-Antwort, Kandidaten, Auswahl, Fallback, Zweigerzeugung, Serviceidentität, Mandant, Eigentümer, Freigabe und Gültigkeit.

Vertrauen und Datenschutz werden ebenfalls getrennt: Ein- und Ausgangsdomäne, TLS-Peer, Transformation, Richtlinie, geschützte Zuordnung, Rechte und Aufbewahrung.

Schließlich folgen Zweigtransaktionen, Antworten, Timeout, CANCEL, Gewinner, B2BUA-Beinzuordnung, Dialog, Medien, Anwendung, Aufzeichnung, Abrechnung und Beschwerde.

Widersprüche bleiben stehen: Der Gewinner kennt einen vorhandenen Bruder nicht. rc widerspricht der Mandantengrenze. Reason passt nicht zum Anwendungslog. Ein B2BUA hat einen schönen Baum, aber keine Beinkarte. 200 existiert ohne Audio. Wer daraus „Pfad genehmigt“ macht, gewinnt Macht durch Verdichtung.

Quellen