Zusammenfassung

  • RFC 3485 machte gemeinsames SIP/SDP-Material schon in der ersten SigComp-Nachricht referenzierbar, weil jede Implementierung denselben unveränderlichen, bytegenauen Zustand besaß.
  • Die lesbaren Listen der Anhänge erklärten die Herkunft; verbindlich waren Binärwert, Kennung, Länge und exakt adressierte Ausschnitte aus Abschnitt 3.

Die erste Nachricht besitzt keine gemeinsam erlebte Vergangenheit. Ein Kompressor kann noch nicht auf frühere Header oder Sitzungsbeschreibungen verweisen. RFC 3485 stellte deshalb vorab dasselbe Wörterbuch an beide Enden.

Damit dies ohne Aushandlung funktionierte, musste das Wörterbuch einzigartig und dauerhaft sein. Jede SIP/SDP-SigComp-Implementierung sollte es tragen. Es durfte sich nicht mit SIP oder SDP weiterentwickeln. So entfiel vor der ersten Nachricht die Frage nach der Version am entfernten Ende.

Vereinbart war ein genauer SigComp-Zustand. Abschnitt 3 legte vollständige Kennung, Länge 0x12E4, minimale Zugriffslänge sechs Oktette und alle Bytes fest. Das STATE-ACCESS-Beispiel nutzte ein sechs Oktette langes Präfix nach SigComps Suchregeln und fand damit denselben Gesamtzustand.

Die Anhänge A und B führten SIP- und SDP-Strings, Prioritäten, Offsets, Längen und Quellen verständlich auf, waren aber informativ. Normativ war die Binärdarstellung. Gleiche Wörter mit nur einem anders angeordneten Byte ergaben nicht denselben Zustand.

Der Wert verband String- und Tabellenbereich. Der Stringbereich enthielt das Material als Teilfolgen. Die Tabelle speicherte eine Ein-Byte-Länge und einen Zwei-Byte-Offset, dem 1024 hinzugefügt waren, sodass ein an UDVM-Adresse 1024 geladener Zustand direkt referenziert werden konnte.

Gemeinsame Fragmente überlappten. Ein Präfix konnte mehreren Headern dienen; Antwortcodes erhielten Einträge allein und zusammen mit vorgeschlagenem Grundtext. Der Code war normativ, der Wortlaut nicht. Verschiedene logische Einträge konnten dieselben Bytes verwenden.

Formatierung gehörte zum Treffer. Die Strings waren groß-/kleinschreibungssensitiv und enthielten oft vorheriges CRLF, Doppelpunkt und erwartetes Leerzeichen. Eine grammatisch gültige SIP-Nachricht mit anderem Whitespace konnte weniger profitieren. Bedeutungsähnlichkeit war keine Bytegleichheit.

Prioritäten eins bis fünf waren Entwurfsschätzungen, keine Messdaten. Kleine Zahlen bedeuteten erwartete Häufigkeit und beeinflussten die Lage für effiziente Algorithmen. Sie bewiesen keine spätere Verkehrsverteilung.

Zugleich ermöglichten sie Speicher-Ausschnitte. Die RFC gab genaue Offsets und Längen für Priorität eins, eins bis zwei, eins bis drei und eins bis vier an. Ein kleiner Ausschnitt war keine neue Version, sondern ein Bereich desselben unveränderlichen Zustands.

Ein Auditvermerk „Wörterbuch verwendet“ reicht daher nicht. Präfixkennung, Offset, Länge, String- oder Tabellenbereich und Prioritätsausschnitt müssen erhalten bleiben. Selbst dann ist nur Zugriff belegt, nicht erfolgreiche Dekompression.

Dekompression beweist wiederum keine gültige SIP/SDP-Semantik, Authentisierung, Zustellung oder Sitzung. RFC 3320 besitzt UDVM-Ausführung und Zustandsautorisierung, RFC 3321 die Lebensdauer dynamischer Zustände, RFC 3322 das Leistungsmodell. RFC 3485 besitzt nur den vorinstallierten Zustand.

RFC 3486 regelte die SIP-Signalisierung, RFC 4464 erläuterte Nutzung, RFC 4465 testete Zugriff, RFC 4896 klärte die Anordnung und RFC 5049 verlangte Unterstützung. RFC 5112 schuf ein anderes Präsenzwörterbuch, statt dieses still zu ändern.

Die Sicherheitssektion verwies auf RFC 3320 und sah kein zusätzliches bekanntes Risiko. Das machte Kompression nicht zur Authentisierung. Die Kennung belegt weder Identität noch Berechtigung, Integrität, Zustellung oder Sitzungserfolg.

Auch ein Einsatz oder gemessener Kompressionsgrad wurde nicht belegt. Die Konstruktion versprach Nutzen für die erste Nachricht, doch Algorithmus, Inhalt, Format, Ausschnitt und Link bestimmen reale Werte.

Nach Heng Lus Realitätsebenen prüft man zuerst Hash, Kennung und Länge des Gesamtzustands. Dann sichert man Präfix und STATE-ACCESS-Operanden, löst den Bytebereich auf und vergleicht die Dekompressionsspur. Protokollgültigkeit, Authentisierung, Transport und Ergebnis folgen getrennt.

RFC 3485 gab der ersten Nachricht geliehene Vergangenheit. Sie blieb nur gemeinsam, weil das Wörterbuch kein editierbares Nachschlagewerk, sondern ein versiegeltes Bytefeld ohne zweite Auflage war.

Quellen