Zusammenfassung

  • In einer erfolgreichen REGISTER-Antwort kann ein Registrar einen geordneten Service-Route-Vektor liefern. Der User Agent darf ihn speichern und später als vorgegebenes Route-Set verwenden.
  • Der Vektor belegt die damalige Konfiguration. Er belegt weder die spätere Nutzung noch die konkrete DNS- und Transportauswahl, den Durchlauf jedes Proxys, die Dienstfunktion oder den Sitzungserfolg.

RFC 3608 wurde im Oktober 2003 auf dem Standards Track veröffentlicht. Es definiert eine SIP-Erweiterung und deren Lebenszyklus, nicht die Beobachtung eines heutigen Betreibernetzes.

Ein Proxy-Name wirkt stabiler, als er ist. Er steht in der Registrierungsantwort, wird in einer Datenbank gespeichert und taucht Monate später in einem Audit auf. Aus dieser Beständigkeit der Zeichenfolge entsteht schnell die Behauptung, der Verkehr habe einen stabilen, kontrollierten Weg genommen. Tatsächlich liegen zwischen Zeichenfolge und Verbindung mehrere Entscheidungen, deren Zustand sich unabhängig ändert.

RFC 3608 beginnt mit einem eng begrenzten Vorgang. Ein Registrar kann in einer 2xx-Antwort auf REGISTER Service-Route-Werte zurückgeben. Der User Agent kann sie mit dem address-of-record verknüpfen. Bei einer späteren Ausgangsanfrage kann er sie in derselben Reihenfolge in Route übernehmen. Der Mechanismus verteilt also eine Routenempfehlung, nicht eine Vollzugsbescheinigung.

Schon der gespeicherte Zustand hat einen Lebenszyklus. Eine erfolgreiche Neuregistrierung aktualisiert ihn. Fehlt Service-Route in der neuen Antwort, muss der alte Zustand gelöscht werden. Wird die Registrierung abgelehnt oder läuft sie ohne Erneuerung ab, soll der User Agent die Route verwerfen. Ohne REGISTER-Instanz, Call-ID, CSeq, Contact, Zeit, Ablauf und Erneuerungslinie ist ein gespeicherter Vektor nicht zeitlich einordenbar.

Bei der Verwendung kommt lokale Politik hinzu. Ein Gerät in einem besuchten Netz benötigt vielleicht zuerst einen lokalen Ausgangsproxy. Ein anderes setzt eine konfigurierte outbound-proxy-Regel ein. RFC 3608 überlässt die Kombination mit dem Service-Route-Set der Implementierung, verlangt aber eine funktionierende lokale Route. Der Home-Registrar kennt gewöhnlich nicht die gesamte Topologie des besuchten Netzes.

Deshalb ist Service-Route nicht Path. Nach RFC 3327 können Proxys während REGISTER einen Path aufbauen, damit spätere Anfragen aus der Home-Domain den registrierten Contact erreichen. Service-Route läuft konzeptionell zum User Agent und dient dessen ausgehenden Anfragen. Beide verwenden route-ähnliche Syntax, gehören aber verschiedenen Richtungen und Beweisfragen.

Auch Route und Via sind keine Synonyme. Route enthält noch abzuarbeitende Routing-Vorgaben. Via wird beim Weiterleiten ergänzt und trägt zur Rückführung der Antwort bei. Ein Name in Route ist Absicht. Eine korrelierte Via-Beobachtung ist ein stärkerer Hinweis auf Weiterleitung. Sie beweist trotzdem nicht, dass im Proxy eine bestimmte Policy-, Logging- oder Charging-Funktion ausgeführt wurde.

Dann folgt RFC 3263. DNS kann aus einer SIP-Domain mehrere Ziele und Transporte liefern. TTLs laufen ab, Prioritäten und Gewichte wirken, ein Ziel scheitert, ein anderes wird versucht. Lokale Regeln können die Auswahl ändern. Derselbe URI-Text kann deshalb zu einem anderen IP-Endpunkt, Port oder Transport führen. Wer nur den Service-Route-String speichert, verliert die operative Auflösung.

Transportzustand ist ein weiteres Glied. RFC 5626 beschreibt outbound flows und flow tokens. RFC 5923 beschreibt connection reuse. Ein vorhandener oder wiederverwendeter Kanal kann gut belegt sein, ohne dass damit die konkrete untersuchte Anfrage auf diesem Kanal belegt wäre. Noch weniger folgt daraus, dass der vorgesehene Dienst ausgeführt und das Endziel erreicht wurde.

Die Integrität der Registrierungsantwort bleibt wichtig. RFC 3608 warnt vor eingefügten oder veränderten Service-Route-Werten und empfiehlt Authentisierung und Integritätsschutz. Ein erfolgreicher Schutz stärkt die Aussage über Herausgeber und Inhalt der Konfiguration. Er friert weder DNS noch Verfügbarkeit noch spätere Programmlogik ein.

Für eine belastbare Kette braucht es getrennte Belege. Der Konfigurationsbeleg enthält die vollständige REGISTER-Antwort, Identität, geordnete Werte, Schutzstatus, Zeit und Gültigkeit. Der Intentionsbeleg enthält die tatsächlich erzeugte Anfrage nach lokaler Komposition. Der Auflösungsbeleg enthält DNS-Antworten, TTL, gewähltes Ziel, Transport und Ausweichversuche.

Der Durchlaufbeleg erfordert zeitlich passende Beobachtungen an den erwarteten Knoten. Der Dienstbeleg stammt aus der betreffenden Funktion selbst und nennt Policy-Version, Entscheidung und Fehler. Der Ergebnisbeleg beschreibt SIP-Antwort, Dialog und gegebenenfalls Medien- oder Anwendungserfolg. Session-ID aus RFC 7989 kann vorhandene Belege verbinden, aber keine fehlende Ausführung ersetzen.

Diese Trennung macht Störungen lokalisierbar. Der Registrar kann einen falschen Vektor liefern. Der Client kann einen abgelaufenen behalten. DNS kann auf eine nicht verfügbare Instanz zeigen. Ein Proxy kann korrekt weiterleiten und dennoch den Dienst auslassen. Signalisierung kann gelingen, während Medien scheitern. All das verträgt sich mit einer erfolgreichen Registrierung.

Vollständige Daueraufzeichnung ist nicht erforderlich. Aufbewahrung kann begrenzt, Erfassung risikobasiert, Identität pseudonymisiert und Zugriff eingeschränkt werden. Entscheidend ist die Symmetrie: Je schmaler der erhaltene Beleg, desto schmaler muss die spätere Behauptung sein.

RFC 3608 belässt die gemeinsame Schicht klein. Es definiert die Form und Alterung einer Routenempfehlung; die konkrete Zukunft entsteht durch lokal laufenden Code. Eine Organisation überschreitet diese Grenze, wenn sie die alte Konfiguration zur Autorität über spätere DNS-, Transport- und Dienstereignisse macht.