Zusammenfassung

  • Mit leerem rport bittet ein SIP-Client darum, die Antwort an die tatsächlich beobachtete Quelladresse und den Quellport zu schicken. Empfang beweist den Rückweg dieser Transaktion unter der damaligen NAT-Bindung.
  • Tuple, Bindung, Flow, Registrierung, Transaktion, Dialog und Nutzerergebnis haben eigene Lebensdauern. Wer sie als ein einziges „erreichbar“ speichert, kann den späteren Bruch nicht mehr einer Schicht zuordnen.

Ein Proxy lauscht auf zwei Adressen und mehreren Ports. Die Anfrage kommt auf einem bestimmten Socket an. Hinter dem Client hat ein Übersetzer Adresse und Port verändert. Für die Antwort genügt es nicht, irgendeinen gesunden Ausgang des Dienstes zu wählen. Sie muss von demselben Server-Endpunkt stammen, den die NAT-Zuordnung bereits gesehen hat.

Genau diese enge Aufgabe beschreibt RFC 3581. Das im August 2003 auf dem Standards Track veröffentlichte Dokument ergänzt den obersten Via-Eintrag um rport. Es korrigiert die Rückleitung einer Antwort. Sein eigener IAB-Abschnitt warnt davor, die dabei gelernte Adresse als dauerhafte Lösung für Registrierung und Record-Route zu verwenden.

Die alte Zielberechnung bestand aus zwei Quellen

SIP über UDP nahm ursprünglich die Ziel-IP aus dem empfangenen Paket, den Zielport aber aus sent-by im obersten Via. Das erlaubte einen gemeinsamen Hörpunkt. Bei NAT konnte jedoch die IP auf die öffentliche Seite zeigen, während der Header noch den privaten Port enthielt.

Der Client sendet rport ohne Wert. Er behauptet keinen öffentlichen Port, sondern fordert die Beobachtung des Servers an. Der Server trägt den gesehenen Port in rport und die Adresse in received ein, selbst wenn sie mit sent-by übereinstimmt.

Bei unzuverlässigem Unicast ohne maddr geht die Antwort an received:rport. Sie muss außerdem vom Empfangssocket des Servers kommen. Ein symmetrisches NAT kann die Bindung über beide Enden bestimmen; der ausgehende Server-Port ist daher keine austauschbare Implementierungsangabe.

Die Regel lautet nicht, dem Via blind zu vertrauen. Sie bindet die Antwort an eine frische Beobachtung der konkreten Transaktion.

Ein beobachteter Port besitzt keine Identität

Steht im Via 10.1.1.1:4540, während der Proxy 192.0.2.1:9988 sieht, kann das zweite Paar die richtige Antwortadresse sein. Es bezeichnet aber weder den Menschen noch die Address-of-Record, die UA-Instanz oder ein dauerhaft reserviertes öffentliches Socket.

Auch die Beweisschritte bleiben getrennt. Leeres rport belegt den Wunsch des Clients. Ein numerischer Wert belegt die Eintragung des Servers. Erst der Empfang beim Client belegt die vollständige Rückleitung. Selbst dieser Empfang sagt nichts über Ablaufzeit oder Zugänglichkeit von einem anderen Cluster-Knoten.

Ein belastbarer Receipt verbindet Branch, Call-ID, CSeq, ursprüngliches und ergänztes Via, Wire-Tuple, Proxy-Instanz, Eingangsinterface, Ausgangssocket, Response-Code und Client-Empfang. reachable=true ohne Beobachter und Gültigkeitsfenster ist keine nachprüfbare Aussage.

Stateless verschiebt Zustand in die Nachricht

Ein stateful Proxy kann den Eingangssocket bis zur Antwort merken. Ein stateless Proxy hält zwischen Anfrage und Antwort keinen lokalen Zustand. RFC 3581 erlaubt ihm deshalb, Zieladresse und Port in den eigenen Via-Eintrag zu codieren und später wieder auszulesen.

Die Provenienz verschwindet nicht. Sie wechselt den Träger. Wird im Logging nur der logische Dienstname gespeichert, lässt sich das reale Interface nicht rekonstruieren. Der Load Balancer kann zwei Prozesse als gleichwertig ansehen, während das NAT nur Pakete eines davon annimmt.

Deshalb sind Dienstverfügbarkeit, Instanzgesundheit und symmetrischer Pfad einer Transaktion verschiedene Kontrollflächen. Ein grüner Clusterstatus beweist den letzten Punkt nicht.

Die Bindung kann vor dem INVITE enden

RFC 3581 verlangt, dass die NAT-Bindung für die Dauer der Transaktion besteht. Nicht-INVITE-Transaktionen galten gegenüber typischen UDP-Zeiten als kurz. Ein INVITE kann beliebig lange auf eine endgültige Antwort warten. Darum empfiehlt das Dokument weitere Übertragungen ungefähr alle zwanzig Sekunden, auch nach einer provisorischen Antwort.

Der Aufwand zeigt die Grenze: Das Tuple enthält keine Ablaufzeit. Eine erfolgreiche Zwischenantwort ist kein Lease. Schweigen, NAT-Neustart, geänderte Richtlinie oder Failover können den Pfad löschen, obwohl SIP-Identität und Registrierung unverändert erscheinen.

Das Dokument verwies auf die Lifetime-Erkennung aus RFC 3489 und warnte bereits vor deren Unzuverlässigkeit. RFC 5389 löste RFC 3489 ab, später löste RFC 8489 RFC 5389 ab. Historische Annahmen sind keine aktuelle Messung. Zu bewahren sind tatsächlicher Verkehr, letzter Erfolg, Refresh-Intervall und Unsicherheit.

Address Fixing überträgt nicht die versteckten Bedingungen

Aus received und rport kann ein Client sein öffentlich gesehenes Tuple lernen. Es in Contact oder Record-Route einzusetzen, macht daraus scheinbar eine Adresse für künftige Anfragen. RFC 3581 ordnet diesen Gebrauch als UNSAF ein und beschreibt seine Brüchigkeit.

Die Bindung kann extrem häufige Re-Registrierung verlangen. Ein symmetrisches NAT akzeptiert unter Umständen nur den ursprünglichen Server als Gegenstelle. Ein anderes Cluster-Mitglied liest denselben Contact, bleibt aber draußen. War der REGISTER-Empfänger ein Proxy statt des Registrars, müssen spätere Anfragen diesen Proxy passieren; RFC 3327 Path drückt diese Abhängigkeit aus.

Im Portwert fehlen erlaubter Remote-Peer, Ablauf, Edge-Proxy und Cluster-Affinität. Das Kopieren des Wertes kopiert seine Voraussetzungen nicht.

Als Ausstieg verlangte RFC 3581 eine Lösung, bei der der Client den selbst eröffneten Connection/Flow für eingehende Requests benennen kann, Server-Cluster ausdrücklich behandelt werden und keine extreme Last entsteht. RFC 5626 realisierte SIP Outbound mit registrierten Flows, mehreren Pfaden, Keepalives und Failure Detection. RFC 6314 empfiehlt diesen Ansatz für Client-Server-NAT-Praxis.

Die späteren Bausteine bleiben getrennt. RFC 6223 sagt ausdrücklich, dass Keepalive kein Connection Reuse definiert. RFC 5923 behandelt umgekehrte Requests auf verbindungsorientierten Transporten. RFC 5627 liefert eine stabile GRUU für eine UA-Instanz. Ein Pong wählt keine Registrierung, ein Flow-Token autorisiert keinen Nutzer, eine URI beweist kein Klingeln und keine Medien.

Sicherheit erweitert die Aussage nicht

Quelladresse und Port können vertraulich sein. RFC 3581 nennt SIP über TLS zum Schutz der Signalisierung. Auf TCP/TLS liefert rport vor allem die Sicht des Servers; es ist nicht die Ursache für UDP-NAT-Durchquerung.

Ein Angreifer zwischen den Endpunkten kann rport entfernen und den Rückweg stören. Integrität kann die Änderung verhindern. Sie beweist weder die Kontrolle über das öffentliche Tuple noch verlängert sie die Bindung. Der IANA-Eintrag koordiniert Syntax, nicht Implementation oder Erreichbarkeit.

Die Beweiskette braucht daher eigene Autoritäten: Authentisierung für Identität, Wire-Beobachtung für das Transaction-Tuple, Socket-Provenienz für die Antwort, Path oder Flow für spätere Requests, Registrar-Zustand für die Contact-Auswahl, Route Set für den Dialog und separate Resultate für Klingeln, Annahme, Medien und Anwendung.

Beweisgrenze

Dieser Artikel nennt keinen Carrier, keine PBX, keinen SIP-Anbieter, UA, Proxy, Registrar, NAT-Hersteller, Cluster, Teilnehmer, Call, Incident oder Medienausgang. Standards Track ist kein Deployment-Beleg.

RFC 3261 liefert Via und Transaktion, RFC 3327 Path, RFC 3424 den UNSAF-Rahmen. RFC 3489 ist historischer Kontext; RFC 5389 und RFC 8489 markieren die STUN-Entwicklung. RFC 5626, RFC 6314, RFC 5923, RFC 6223 und RFC 5627 trennen Outbound, NAT-Praxis, Wiederverwendung, Keepalive und stabile UA-Routen. IANA ersetzt keinen Laufzeitnachweis.

Heng Lus Running-Code Primacy und Minimum Initial Specification sind offengelegte redaktionelle Perspektiven. Sie verlangen Prüfung des laufenden Pfads und eine kleine gemeinsame Regel. Sie sind kein Beleg für Autorenabsicht oder Nutzung.

Die belastbare Schlussfolgerung ist eng: Der Server kannte für eine Antwort den Rückweg. Er kannte damit noch nicht die künftige Erreichbarkeit.

Quellen