Zusammenfassung

  • RFC 3327 ließ ausgewählte Proxys während REGISTER Path-URIs einfügen; der Registrar speicherte den geordneten Vektor mit einer Address-of-Record–Contact-Bindung, und der Heimat-Proxy übernahm ihn später in Route.
  • Path war bewusst kein vollständiges Verlaufsprotokoll: Ein durchlaufener Proxy konnte fehlen, ein anderer Knoten konnte eingetragen sein, der Registrar durfte den Vektor verändern und spätere lokale Richtlinien konnten weitere Routen ergänzen.

Der gespeicherte Ort war noch kein Lieferplan

Ein Endgerät registriert seine öffentliche SIP-Identität aus einem Zugangsnetz. Der Contact beschreibt den aktuellen Zielpunkt, und der Registrar akzeptiert die Zuordnung. Das Gerät kann jedoch hinter einem Edge-Proxy, einer Sicherheitsgrenze oder einem Dienst des besuchten Netzes liegen, den spätere Anfragen zwingend passieren müssen. Eine direkte Zustellung an den Contact kann notwendige Regeln umgehen oder an einer nur intern erreichbaren Adresse enden.

REGISTER hatte die erforderlichen Zwischenstellen gerade durchlaufen. Die grundlegende Registrierungssemantik verlangte aber nicht, diese Folge zusammen mit der Bindung zu bewahren. Nach Abschluss der Transaktion kannte die Datenbank den Zielpunkt, während der Heimat-Proxy den Weg dorthin verlor. Die erste Nachricht war angekommen; der für die zweite Nachricht nötige Kontext verschwand.

Path machte diesen Kontext explizit. Ein Proxy, der REGISTER bearbeitete, konnte eine URI hinzufügen, die bei künftigen Anfragen an das Endgerät verwendet werden sollte. Mehrere Werte bildeten einen geordneten Vektor. Der Registrar speicherte ihn zusammen mit der öffentlichen Adresse und dem konkreten Contact und spiegelte die akzeptierten Werte in der erfolgreichen Antwort. Wählte der Heimat-Proxy später diesen Contact, lud er den Vektor vor der Weiterleitung in die Route-Menge.

Die Bindung an den Contact war entscheidend. Eine Identität konnte Telefon, Rechner und Gateway über unterschiedliche Zugänge registrieren. Der Pfad eines Geräts gehörte nicht dem anderen. Eine Auffrischung über einen neuen Edge konnte den Vektor ersetzen; mit Ablauf der Bindung musste auch die Route enden. Ein statischer Benutzerpfad hätte die Topologie von gestern auf das Ziel von heute übertragen.

RFC 3263 löste eine benachbarte Aufgabe: SIP-Server einer Domain über DNS finden. Diese Entdeckung bestimmte den Einstieg in einen Dienst, nicht die flüchtige Kette vom Heimatnetz zu einem einzelnen registrierten Contact. Path begann dort, wo die Diensterkennung aufhörte.

Path war eine Vorschrift, keine Paketspur

Eine geordnete URI-Liste sieht wie der tatsächliche Weg von REGISTER aus. Die Spezifikation versprach das nicht. Ein Proxy konnte die Anfrage bearbeiten, ohne sich einzutragen. Ein topologiebewusster Proxy konnte die URI eines anderen Knotens einfügen, der später zuständig sein sollte. Der Registrar konnte den Vektor beim Speichern umformen. Der Heimat-Proxy konnte ihn mit einer vorhandenen Route oder einer Standardroute verbinden.

Path beschrieb damit eher eine künftige Verpflichtung als eine vergangene Beobachtung. Eine Paketaufzeichnung beweist, welche Werte an einem Messpunkt vorhanden waren. Sie beweist nicht, dass alle durchlaufenen Proxys aufgelistet, alle aufgelisteten Knoten zuvor durchlaufen oder alle später tatsächlich besucht wurden.

Eine belastbare Nachweiskette hält vier Belege getrennt: den beobachteten REGISTER-Verlauf, den deklarierten Path-Vektor, den vom Registrar akzeptierten oder transformierten Speicherzustand und die später realisierte Route. Abweichungen zwischen ihnen sind Hinweise auf Richtlinie, Fehler oder Missbrauch. Sie zu einer glatten Linie zu normalisieren, beseitigt die wichtigste Information.

Via trägt den Rückweg innerhalb einer Transaktion. Record-Route baut aus der dialogeröffnenden Anfrage den Pfad des aktuellen Dialogs. Path wird während der Registrierung für noch nicht bestehende Dialoge gelernt. Service-Route aus RFC 3608 zeigt in die Gegenrichtung: Der Registrar teilt dem Endgerät den Pfad für künftige ausgehende Dienstanfragen mit; Path teilt der Heimatseite den Weg zum Contact mit. Zeitpunkt, Richtung und Kontrollinstanz unterscheiden sich.

Die Spiegelung ermöglichte Kontrolle, aber keine Beglaubigung

Die erfolgreiche REGISTER-Antwort enthielt die gespeicherten Path-Werte. Ein normales Endgerät musste daraus keine eigene Route bilden und durfte sie ignorieren. Es konnte sie dennoch prüfen. Ein unerwarteter Proxy war ein Warnsignal dafür, dass sich ein Akteur in jede künftige Anfrage an die Bindung einschalten wollte.

Eine bösartige Einfügung wirkte über die einzelne Registrierung hinaus. Solange die Bindung bestand, konnte der eingetragene Knoten Anfragen abfangen. Das Löschen eines Werts konnte eine Pflichtkontrolle umgehen; eine Umordnung veränderte, wer Verkehr zuerst sah; eine undokumentierte Transformation verdeckte den Unterschied zwischen Antrag und Annahme.

RFC 3327 behandelte geeigneten Integritätsschutz und gegenseitige Authentisierung. Deren Aussage bleibt begrenzt. Eine erfolgreiche Prüfung kann zeigen, dass geschützte Bytes zwischen identifizierten Partnern unverändert blieben. Sie zeigt nicht, dass ein Knoten ehrlich, verfügbar oder zur Vertretung eines anderen Knotens befugt ist. Ebenso wenig belegt sie frühere oder künftige tatsächliche Durchleitung. Spiegelung schafft Sichtbarkeit, keine Wahrheit.

Die Warnung vor einem vom Endgerät selbst eingefügten Path verdeutlicht die Rollenfrage. Nachfolgende Proxys könnten eine solche URI als Anweisung eines Proxy-Peers lesen und später erwarten, dass das Gerät selbst Proxy-Aufgaben übernimmt. Korrekte Syntax heilt keine falsche Sprecherrolle. Einfüger, Hop und Vertrauensbeziehung gehören zur Bedeutung.

Spätere RFCs präzisierten die Umgebung

RFC 3327 erschien im Dezember 2002 und wurde später durch RFC 5626 aktualisiert. SIP Outbound ordnete Flows von Geräten hinter Netzgrenzen und die Rolle von Edge-Proxys systematischer. Damit wurde das Zusammenspiel von Registrierung, Flow und nutzbarem Rückweg genauer; Path wurde dadurch nicht zur vollständigen Verkehrshistorie.

RFC 5627 definierte GRUU zur routbaren Identifizierung einer Endgeräteinstanz. RFC 3680 legte Benachrichtigungen über Registrierungsereignisse fest. RFC 5922 behandelte SIP-Domain-Zertifikate. Die IANA-Liste der SIP-Parameter dokumentiert standardisierte Zuweisungen. Diese Quellen belegen Protokollverträge und Dokumententwicklung, nicht Verbreitung, Einsatz, Verfügbarkeit oder aktuelle Vertrauenswürdigkeit.

Die dauerhafte Leistung von RFC 3327 liegt in der Trennung von Identität, aktuellem Locator, vorgeschriebenem Weg und beobachteter Historie. Ein Netz kann die ersten beiden kennen und dennoch nicht zustellen. Es kann den künftigen Weg kennen und kaum etwas über den vergangenen wissen. Path machte den fehlenden Zustand speicherbar. Seine Grenze bleibt ebenso wichtig: Eine Route für morgen ist kein Beweis für gestern.

Quellen