Zusammenfassung

  • comp=sigcomp stand in dem URI oder Header, der die nächste Aktion steuerte: Request zum nächsten Hop, Response über das oberste Via sowie späterer Verkehr über Contact und Record-Route.
  • Das Merkmal erklärte Unterstützung und gegenwärtige Empfangsbereitschaft. Tatsächliche Kompression, SIP-Verarbeitung, Zustellung, Authentisierung und Gesprächsaufbau blieben eigene Nachweise.

Der Kontrollpunkt in RFC 3486 springt mit der Richtung. Beim Request entscheidet der Next-Hop-URI. Bei der Response entscheidet das oberste Via. Für spätere Requests verändern Contact und Record-Route, welcher Eintrag maßgeblich wird. Wer nur „SigComp an“ protokolliert, verliert diese Bewegung der Zuständigkeit.

Auslöser war eine kombinatorische Last. SIP nutzte NAPTR und SRV bereits zur Wahl von UDP, TCP oder SCTP. Zusätzliche DNS-Einträge für jede Kombination aus Transport, TLS und Kompression hätten die Zahl der Varianten vervielfacht. RFC 3486 verlegte das Signal in SIP. Ein Port konnte gewöhnliche und komprimierte Nachrichten annehmen; die oberen Cookie-Bits einer SigComp-Nachricht ermöglichten die Unterscheidung.

Die Schreibweise war knapp: comp=sigcomp. In einem SIP- oder SIPS-URI sollte der Request zum bezeichneten nächsten Hop komprimiert werden. Im obersten Via sollte die Response komprimiert zurücklaufen. Gleicher Text bedeutete nicht gleichen Geltungsbereich.

Der Parameter verband zwei Aussagen. Die bezeichnete Entität unterstützte SigComp und war bereit, komprimierte Nachrichten zu empfangen. Diese Bereitschaft war zeitbezogen. Eine vorhandene Implementierung verpflichtete den Empfänger nicht, Kompression auf jedem Pfad und zu jedem Zeitpunkt zu akzeptieren.

Deshalb durfte ein Client keinen komprimierten Request senden, solange die Unterstützung des Servers unbekannt war. Er konnte aber einen unkomprimierten Request mit dem Parameter im eigenen obersten Via senden. Ein fähiger Server durfte darauf komprimiert antworten. Hin- und Rückrichtung erhielten getrennte Entscheidungsgrundlagen.

Vor dem Dialog gab es noch kein Route Set. Manuelle Konfiguration war möglich; alternativ konnte der Client ein unkomprimiertes OPTIONS an den Outbound-Proxy senden. Dieser durfte in Contact einen alternativen URI mit comp=sigcomp zurückgeben. Das war ein Angebot für spätere Requests, kein Beleg für deren tatsächliche Drahtdarstellung.

Im Dialog trugen Contact und Record-Route die Präferenz weiter. Ein User Agent setzte den Parameter in Contact, wenn er künftige Requests komprimiert empfangen wollte. Ein Proxy, der im Pfad blieb, nutzte Record-Route. In der Response prüfte er den nächsten Upstream-Hop und fügte den Parameter in seinem Eintrag hinzu oder entfernte ihn. Die spätere Route wurde aktiv gestaltet.

Das Beispiel der RFC zeigt vier SIP-Elemente, aber nur die Nachrichten 1, 6 und 7 sind komprimiert. Ein Proxy empfängt einen komprimierten INVITE und leitet ihn unkomprimiert weiter. Eine Response ist auf einem Abschnitt gewöhnlich und auf dem nächsten komprimiert. Beim ACK ändert sich das Muster erneut. Ein Dialog konnte mehrere gleichzeitig gültige Kompressionszustände besitzen.

Auch Double Record-Routing vereinheitlichte sie nicht. Ein Proxy zwischen zwei Netzen konnte zwei Einträge für seine Schnittstellen setzen und so Umschreiben vermeiden. Dennoch durfte eine Seite komprimiert und die andere unkomprimiert bleiben. War der nächste Hop der Proxy selbst und verließ die Nachricht das Gerät nicht, durfte er trotz Parameter auf Kompression verzichten.

Im Fehlerfall fehlte womöglich sogar ein SIP-Fehler. Ein Server ohne SigComp konnte den komprimierten Request nicht bis zum Via parsen und kannte damit keine Rückadresse. Nach einem Transaction Timeout sollte der Client denselben Request unkomprimiert wiederholen. Das Schweigen erlaubte diesen Rückfall, bewies aber nicht dessen Ursache.

Bei TCP sollte der Client zusätzlich die alte Verbindung schließen und eine neue öffnen. Sonst konnte der inkompatible Server den Beginn der unkomprimierten Nachricht im bereits komprimiert begonnenen Stream nicht erkennen. Timeout, Wiederholung und Verbindungswechsel waren getrennte Ereignisse.

Der Parameter authentisierte seinen Urheber nicht. Wer ihn unerlaubt einfügte, konnte komprimierte Nachrichten zu einer nicht unterstützenden Entität lenken; deshalb verlangte die RFC geeignete Integritätsmechanismen. Dekompression erforderte zudem mehr Rechenleistung als bloßes Parsen und verschärfte Denial-of-Service-Risiken geringfügig.

Die IANA-Registrierung stabilisierte Namen, nicht Laufzeitwahrheit. RFC 3320 definierte SigComp, RFC 3485 das statische SIP/SDP-Wörterbuch. RFC 5049 aktualisierte später die SIP-Anwendung mit Ressourcenminima, Compartments und State Management. RFC 4077, RFC 4896, RFC 5112 und RFC 5626 ergänzten weitere Grenzen. Keine dieser Veröffentlichungen ist ein Einsatznachweis.

Für eine Rekonstruktion müssen Next-Hop-URI, oberstes Via, Contact, Route und Record-Route, Richtung, Integrität, Drahtbytes, Transport und Verbindung erhalten bleiben. OPTIONS-Erkennung und spätere Nutzung sind getrennt. Bei Schweigen kommen Timeout, unkomprimierte Wiederholung und neue TCP-Verbindung hinzu. Erst danach folgen Dekompression, SIP-Parsing, Authentisierung und Dialogergebnis.

RFC 3486 löste das DNS-Problem ohne eine Ende-zu-Ende-Fiktion. Die Marke durfte reisen, doch ihre Autorität endete am nächsten Hop. Gerade diese Begrenzung machte ihren Inhalt überprüfbar.

Quellen