Zusammenfassung

  • In RFC 2543 unterschied ein branch vor allem die Kopien eines gegabelten Requests. RFC 3261 machte ihn verpflichtend und verlangte – mit engen Ausnahmen – Eindeutigkeit über Raum und Zeit.
  • z9hG4bK ist weder Geheimnis noch Berechtigungsnachweis. Das Präfix zeigt an, dass die kompakte neue Zuordnungsregel gilt; ohne es bleibt der mehrteilige Altverfahren-Vergleich.
  • Eine Wiederholung derselben Übertragung behält ihren Branch, ein neuer Weiterleitungsversuch bekommt einen neuen. CANCEL und ACK nach einer Nicht-2xx-Antwort verwenden den alten Branch absichtlich wieder.

Zunächst bezeichnete der Branch nur einen Arm der Gabelung

Ein SIP-Request kann mehrere Proxys durchlaufen. Jeder Hop legt seinen Via-Wert oben auf den Stapel. Ein zustandsbehafteter Proxy erzeugt für jedes Ziel, das er ausprobiert, eine eigene Client-Transaktion; die Antworten folgen den Via-Schichten zurück.

Schon RFC 2543 kannte den Parameter branch. Sein Versprechen war jedoch begrenzt. Ein forkender Proxy musste parallele, ansonsten gleiche Request-Kopien auseinanderhalten und gab jeder einen innerhalb dieses Forks eindeutigen Wert. Ein Proxy ohne Fork durfte darauf verzichten.

Der Branch war deshalb nur ein Indiz unter mehreren. Für die Zuordnung wurden außerdem To, From, Call-ID, CSeq und der oberste Via-Wert herangezogen. Das funktionierte, doch ein Server durfte aus einem beliebigen Branch noch keine allgemeine, zeitlich unbegrenzte Transaktionsidentität ableiten.

Genau darin lag das Kompatibilitätsproblem. Ändert ein Standard die Bedeutung eines bestehenden Feldes, weiß der Absender, welche Erzeugungsregel er befolgt hat. Der Empfänger trägt dagegen das Risiko einer falschen Annahme. Ohne Kennzeichen müsste er den Implementierungsstand anhand von Hersteller, Netzposition oder beobachtetem Verhalten erraten.

RFC 3261 schrieb den Regelwechsel in den Wert selbst

RFC 3261 verschärfte 2002 den Vertrag. Ein User-Agent-Client musste jeden Request mit einem obersten Via versehen, und dieses Via musste einen Branch enthalten. Abgesehen von ausdrücklich beschriebenen Fällen sollte der Wert für sämtliche Requests des Clients räumlich und zeitlich eindeutig sein.

Zugleich musste der Branch mit z9hG4bK anfangen. Die sieben Zeichen wurden gewählt, weil eine RFC-2543-Implementierung sie mit hoher Wahrscheinlichkeit nicht zufällig erzeugte. Sie codieren weder Datum noch Hersteller, Route oder Benutzer. Sie sagen lediglich: Der restliche Wert wurde unter der neuen Eindeutigkeitsregel gebildet.

Der Ausdruck „Magic Cookie“ klingt aus heutiger Sicht nach Browserzustand, Passwort oder kryptografischer Challenge. Tatsächlich ist das Präfix ein Versionszeuge. Es markiert die Interpretationsgeneration direkt in dem Feld, dessen Verpflichtung sich geändert hat. Der Empfänger braucht keine Registry und keine institutionelle Vermutung; er prüft die Zeichenfolge lokal.

Ein stärkeres Versprechen machte die Prüfung kürzer

Bei einem Request mit Cookie sucht eine Server-Transaktion nach der Kombination aus Branch im obersten Via, dessen sent-by und der Methode. Für ACK gilt eine schmale Ausnahme: Bestätigt es eine endgültige Nicht-2xx-Antwort, gehört es zur gesuchten INVITE-Transaktion. sent-by bleibt nötig, weil zwei Clients denselben Branch versehentlich oder absichtlich verwenden können.

Fehlt das Präfix, unterstellt der Server nicht nachträglich die neue Garantie. Er fällt auf die RFC-2543-kompatible Prüfung von Request-URI, Tags, Call-ID, CSeq und Via zurück. SIP erhielt damit zwei erkennbare Kompatibilitätsmengen, ohne alte Nachrichten stillschweigend umzudeuten.

Antworten werden mit dem obersten Via-Branch und der CSeq-Methode verbunden. Die Methode ist entscheidend, denn CANCEL benutzt zwar den Branch seines Ziels, bleibt aber eine eigene Transaktion. Der Token grenzt Kandidaten ein; er ersetzt nicht die Semantik der übrigen Felder.

Die Abläufe in RFC 3665 zeigen den Maßstab: Beim Hinweg fügt jeder Proxy Via und Branch hinzu, beim Rückweg wird die jeweilige Schicht entfernt. Ein Branch bezeichnet die Transaktion zwischen benachbarten Rollen, nicht den gesamten Anruf.

Derselbe Versuch muss denselben Beleg reproduzieren

Ein zustandsbehafteter Proxy vergibt für jeden ausgehenden Versuch einen neuen Branch. Fällt ein Ziel aus und wird eine andere Adresse probiert, beginnt eine neue Client-Transaktion. Kommt ein Request nach geänderten Verarbeitungseingaben zum Proxy zurück, kann es sich um eine zulässige Spirale statt um eine Schleife handeln; für Loop Detection lassen sich diese Eingaben in einen abtrennbaren Branch-Bestandteil aufnehmen.

Eine Retransmission ist der Gegenfall. Sie wiederholt denselben Versuch und muss denselben Branch tragen. Nur dann findet der Server den vorhandenen Zustand und sendet die gespeicherte Antwort erneut, statt die Aktion ein zweites Mal auszuführen.

Für einen stateless Proxy wird das zur Konstruktionsaufgabe. Er führt keine Tabelle vorheriger Pakete, darf aber auch nicht bei jedem Empfang neue Zufallsdaten erzeugen. RFC 3261 verlangt deshalb, den stabilen Anteil aus Request-Feldern und Konfiguration abzuleiten, die sich bei einer Retransmission nicht ändern. Eindeutigkeit und Reproduzierbarkeit müssen gleichzeitig gelten.

CANCEL teilt die Spur, aber nicht das Schicksal

CANCEL soll genau den noch offenen Request auf demselben Hop-by-Hop-Pfad finden. Es übernimmt Request-URI, Call-ID, Tags, CSeq-Nummer, oberstes Via und Branch; nur die CSeq-Methode wird zu CANCEL. So kann selbst ein stateless Proxy dieselbe Weiterleitungsentscheidung wiederholen.

Trotzdem bildet CANCEL eine eigene Transaktion. Ein Server kann sie mit 200 beantworten und den ursprünglichen INVITE separat mit 487 oder einer anderen endgültigen Antwort abschließen. Möglicherweise hatte bereits eine Finalantwort das Rennen gewonnen. Ein erfolgreich bearbeitetes CANCEL beweist nicht, dass das Ergebnis des INVITE nachträglich verschwand.

RFC 3261 trennte beide Vorgänge ausdrücklich, nachdem RFC 2543 sie stärker miteinander verschränkt hatte. Die Branch-Wiederverwendung schafft Korrelation, keine gemeinsame Lebensdauer.

Die Antwortklasse trennt zwei Arten von ACK

Folgt ACK auf eine endgültige Nicht-2xx-Antwort, bleibt es innerhalb der INVITE-Transaktion. Es übernimmt oberstes Via und Branch, ändert die Methode und wird von der Transaktionszustandsmaschine aufgenommen. Derselbe Proxy-Pfad, der den Fehlschlag bearbeitete, beendet dessen Wiederholungen.

Nach einer 2xx-Antwort gelten andere Grenzen. Ein Fork kann mehrere angenommene Dialoge hervorbringen, und jeder Erfolg muss den Anrufer erreichen. Der User-Agent-Core bestätigt ihn Ende-zu-Ende, folgt der Dialogroute und konstruiert ein Via mit neuem Branch. Dieses ACK liegt außerhalb der ursprünglichen Hop-by-Hop-INVITE-Transaktion.

Die Trennung schützt reale Information. Die Wiederverwendung beim Fehlschlag lässt bestehenden Zustand genau eine Finalantwort beruhigen. Der neue Austausch beim Erfolg verhindert, dass eine Zwischenstation die Bestätigung für ein weiteres angenommenes Ziel verschluckt.

Spätere Reparaturen änderten die Lebensdauer, nicht den Identitätsvertrag

Eine bessere Zuordnung beseitigte nicht jeden Fehler der Zustandsautomaten. RFC 4320 korrigierte Antwort- und Timeout-Verhalten für Nicht-INVITE-Transaktionen. RFC 6026 führte später den Zustand Accepted und Timer L ein, damit ein Server nach einer 2xx-Antwort genügend INVITE-Zustand für Wiederholungen behält.

RFC 6026 bewahrt außerdem einen Sonderpfad für ein altes ACK, dessen Branch kein RFC-3261-Cookie trägt. Das Detail bestätigt die fortdauernde Funktion des Markers: Die Haltedauer des Zustands lässt sich reparieren, doch der Empfänger muss weiterhin erkennen, welches Identitätsversprechen tatsächlich geliefert wurde. RFC 5359 dokumentiert spätere Dienstabläufe mit dieser Konvention; es belegt die spezifizierte Grammatik, nicht den Marktanteil konkreter Implementierungen.

Was das Präfix nie beweisen konnte

Jeder kann z9hG4bK schreiben. Das Präfix authentifiziert keinen Benutzer, autorisiert keinen Anruf, schützt keine Nachrichtenintegrität und beweist nicht, dass der Rest wirklich eindeutig ist. TLS kann einen Hop schützen, Digest Authentication einen Credential-Anspruch stützen und lokale Policy einen Request ablehnen. Keine dieser Befugnisse stammt aus dem Cookie.

Auch ist eine Transaktion kein Dialog. Call-ID und Tags identifizieren Dialogbeziehungen, Route Sets lenken spätere Requests, und Medienaushandlung samt RTP folgt eigenem Zustand. Eine korrekte Branch-Zuordnung belegt nur, dass die eingegangene Nachricht zur lokal gefundenen Transaktion gehört.

Die historische Leistung ist gerade in ihrer Begrenzung stark. SIP änderte den Vertrag eines Feldes und machte die neue Regel prüfbar, ohne Vertrauen in die behauptete Herkunft zu verlangen. Sieben sichtbare Zeichen wählten ein ausführbares Verfahren – und beanspruchten keine Autorität jenseits dieses Verfahrens.

Quellen und Grenzen der Aussage

Die geschlossene Belegsammlung umfasst RFC 2543, RFC 3261, RFC 3665, RFC 4320, RFC 5359 und RFC 6026. Sie tragen Protokollgeschichte, Zuordnungsregeln, Beispielabläufe und spätere Korrekturen. Sie belegen weder heutige Verbreitung noch Produktkonformität, Gesprächsqualität oder das tatsächliche Ausbleiben von Kollisionen.