Zusammenfassung

  • RFC 3261 behandelte die IPv6-Form von Via sent-by und received unterschiedlich; RFC 5118 verlangte für bekannte Interoperabilität, received mit und ohne Klammern anzunehmen, aber ohne Klammern zu senden.
  • Diese Adresse ist eine Beobachtung für den Rückweg. Sie beweist weder ursprüngliche Absicht, Benutzeridentität, organisatorische Autorität noch den Erfolg des Gesprächs.
  • Ein syntaktisch gültiger SIP-URI kann den vorgesehenen Port als letztes IPv6-Oktettpaar verschlucken. Parserakzeptanz und richtige Zielwahl benötigen deshalb getrennte Nachweise.

Ein Server empfängt ein Datagramm von einer Adresse, die nicht mit dem Via-sent-by übereinstimmt. Er ergänzt received, damit die Antwort den beobachteten Weg zurückfindet. Das ist wertvolle Netzwerkevidenz. Es ist aber keine Signatur des Absenders.

RFC 5118 zeigte, dass schon die Schreibweise dieser Evidenz uneinheitlich war. sent-by verwendete in RFC 3261 eine IPv6 reference in eckigen Klammern; received war als nackte IPv6 address definiert. Interoperabilitätstests fanden Implementierungen mit unterschiedlichen Annahmen.

Begrenzte Toleranz, kanonische Ausgabe

Die Empfehlung lautet: Ein received-Wert soll mit oder ohne Klammern geparst werden; beim Senden werden keine Klammern verwendet. Empfang und Ausgabe haben damit bewusst verschiedene Regeln.

Das ist keine Vollmacht für einen universellen „Fixer“. Entfernt eine Bibliothek überall Klammern, zerstört sie SIP-URIs. Verweigert sie jede historische Abweichung, erzeugt sie Ausfälle. Die Ausnahme muss Feld, Eingangsform, erzeugten Wert und Ausgangsform benennen.

Auch ihre Aussagekraft bleibt begrenzt. received belegt eine vom Transport beobachtete Quelladresse innerhalb eines bestimmten Vorgangs. NAT, Weiterleitung und Topologie können die sichtbare Adresse verändern. Der Wert authentifiziert keine Person und garantiert nicht, dass höhere SIP-Schichten oder Medien erfolgreich waren.

Der gültige URI mit dem falschen Ziel

RFC 5118 liefert die komplementäre Warnung. In sip:[2001:db8::10:5070] steht 5070 innerhalb der schließenden Klammer. Wollte der Autor Host 2001:db8::10 und Port 5070 ausdrücken, hat er eine andere, dennoch syntaktisch gültige Adresse erzeugt.

Der Parser findet keinen Port. Er nimmt 5070 als letzte 16-Bit-Gruppe. Das verifizierte Erratum 1311 präzisiert: Es handelt sich um das letzte Oktettpaar, nicht um ein einzelnes Oktett.

Die beabsichtigte Form wäre sip:[2001:db8::10]:5070. Beide können grün werden. Nur ein unabhängig festgehaltener Soll-Host und Soll-Port zeigen, ob die Semantik stimmt. Danach muss der tatsächlich gewählte Socket beobachtet werden.

Ein weiteres Beispiel ohne die für einen SIP-URI erforderlichen IPv6-Klammern soll mit 400 abgelehnt werden. RFC 5118 unterscheidet also strikte Ungültigkeit, gültige aber unerwartete Semantik und begründete Kompatibilitätstoleranz.

Kontext ist Bestandteil des Adresswerts

Im SIP-URI stehen Klammern; in einer SDP-Verbindungszeile nicht. Das Dokument kombiniert außerdem IPv4 und IPv6 über mehrere Via-Felder, verschiedene Familien für Audio und Video sowie IPv4-abgebildete IPv6-Adressen.

Eine zentrale Normalisierung, die nur Zeichenketten sieht, kann keine sichere Universalform erzeugen. Sie muss Feld, Grammatik und Verwendungszweck behalten. Sonst verwandelt ein einheitliches Datenmodell echte Unterschiede in stille Fehler.

Der beschriebene ABNF-Pfad mit einem zusätzlichen Doppelpunkt zeigt dieselbe Grenze. Ein Empfänger kann die Eingabe robust verstehen. Beim Weiterleiten sollte er den zusätzlichen Doppelpunkt entfernen. Input-Verständnis und Output-Custody sind zwei Aufgaben.

Exakte Bytes statt Bildschirmkopie

Lange SIP-Zeilen mussten im RFC umgebrochen werden. allOneLine aus RFC 4475 legt fest, wie sie rekonstruiert werden. RFC 5118 enthält zusätzlich ein codiertes Archiv mit bitgenauen Nachrichten.

Ein Copy-and-paste kann Leerzeichen, Zeilenenden oder Content-Length verändern. Ein Testlabor muss Quelle, Extraktion, Bytes, Länge und Hash erfassen. Normalisiert der Harness vor dem Parser, ist diese Transformation Teil des Ergebnisses.

Bitgenaue Eingabe macht den Test reproduzierbar, aber nicht allumfassend. RFC 5118 ist Informational, nicht normativ und nicht vollständig. Einige Fälle treffen nur den Parser, andere auch die Anwendung. Das Resultat gehört zu einem Build und einer Konfiguration.

Hinter der Adresse folgen weitere Entscheidungen

Aus einem Parserbaum folgt noch keine DNS- oder Routingentscheidung. Aus dem nächsten Hop folgt keine SIP-Antwort. Aus einer Antwort folgt kein Dialog. Aus einem Dialog folgt keine erreichbare Medienadresse. Aus Medienpaketen folgt kein Nutzererfolg.

Ein erfolgreiches Gespräch beweist umgekehrt keine einheitliche Interpretation. Alternative Contacts, ein vorgeschalteter Rewrite oder Fallback können eine Differenz verdecken.

Die Beweiskette braucht daher Rohbytes, Produktion, Baum, Absicht, Ausgangsnachricht, nächsten Hop, Transaktion, Dialog, Medien und Ergebnis. received bleibt ein wichtiger, aber kleiner Baustein dieser Kette.

Ein Testkorpus ist kein Mandat

Der nachhaltige Nutzen von RFC 5118 liegt in den Übergängen, die es sichtbar macht: Dokument zu Wire, Host zu Port, toleranter Eingang zu kanonischem Ausgang, Header zu Body, Parser zu Anwendung.

Wer diese Übergänge protokolliert, kann Verantwortung zuordnen. Wer nur „IPv6-fähig“ speichert, ersetzt technische Realität durch ein Etikett. Ein minimaler gemeinsamer Testbestand ist nützlich, solange lokale Betreiber über Risiko und Ausnahme entscheiden und die Folgen tragen.

Quellen