Zusammenfassung

  • PRACK bestätigt eine bestimmte zuverlässige vorläufige Antwort. Ein 2xx auf PRACK ist deshalb keine Annahme des ursprünglichen INVITE.
  • RSeq, RAck, Dialog und CSeq halten Empfang, Reihenfolge, Offer/Answer und endgültige Rufentscheidung auseinander; auch erfolgreiches Signalisieren beweist keine Medienzustellung.

Eine Quittung für einen Zwischenstand

RFC 3261 beschreibt den langen Weg eines INVITE. Vor einer endgültigen Antwort kann ein User Agent mit 1xx melden, dass der gerufene Teilnehmer gesucht wird oder das Telefon klingelt. Antworten von 101 bis 199 können einen frühen Dialog erzeugen. In der Grundspezifikation werden diese Meldungen jedoch nicht zuverlässig zugestellt.

Das war besonders dort problematisch, wo ein vorläufiger Bescheid mehr als freundliche Fortschrittsanzeige war. Bei der Kopplung mit klassischen Telefonnetzen konnten frühe Zustände, Ansagen oder Sitzungsbeschreibungen für den weiteren Ablauf wichtig sein, obwohl der Ruf noch nicht angenommen war. Eine verlorene 1xx durfte nicht stillschweigend durch die spätere Endentscheidung ersetzt werden.

RFC 3262 ergänzte daher 100rel und die Methode PRACK. Steht 100rel unter Supported im INVITE, darf ein UAS eine vorläufige Antwort außer 100 zuverlässig senden. Steht es unter Require, muss es die entsprechende Zuverlässigkeit liefern oder die Erweiterungsanforderung zurückweisen. 100 Trying bleibt ausgenommen: Diese Antwort gilt nur von Hop zu Hop, während das neue Verfahren Ende zu Ende arbeitet.

Drei Koordinaten statt eines vagen Rufbezugs

Eine zuverlässig gesendete 1xx trägt Require: 100rel und ein RSeq. Der erste Wert wird aus dem in RFC 3262 festgelegten Bereich gewählt; der Nummernraum gehört zur einzelnen Transaktion. Derselbe Zahlenwert in zwei verschiedenen INVITE-Transaktionen ist daher kein gemeinsamer Identifikator.

Die Antwort wird ab T1 mit exponentiell wachsendem Abstand wiederholt. Erst ein passendes PRACK beendet diese Wiederholungen. Im RAck des PRACK stehen der RSeq-Wert, die CSeq-Nummer der bestätigten Antwort und deren Methodenname. Zusätzlich muss das PRACK demselben Dialog angehören. Die Quittung verweist somit auf einen konkreten Zwischenstand innerhalb einer konkreten Transaktion.

Passt das PRACK, erhält es eine 2xx-Antwort. Passt es zu keiner noch offenen zuverlässigen 1xx, antwortet der UAS mit 481. Entscheidend ist, welches Verb zu welcher Antwort gehört: Das 2xx schließt die PRACK-Transaktion erfolgreich ab. Es beantwortet nicht das INVITE, dessen endgültige Annahme, Umleitung oder Ablehnung weiter offen sein kann.

PRACK übernimmt also eine ACK-ähnliche Rolle, ist aber kein besonderer ACK-Typ. Es ist eine normale Nicht-INVITE-Anfrage im Dialog, wird über zustandsbehaftete Proxys von Hop zu Hop abgesichert und bekommt eine eigene Antwort. Gerade diese Eigenständigkeit ermöglicht es, den Empfang einer vorläufigen Antwort festzustellen, ohne die Semantik des Endergebnisses zu borgen.

Reihenfolge ist Teil der Zusage

Die Bestätigungen sind nicht kumulativ. RFC 3262 empfiehlt aus Gründen der Überlastkontrolle nur eine offene zuverlässige vorläufige Antwort und verbietet zumindest eine zweite, solange die erste noch unbestätigt ist. Danach muss RSeq jeweils genau um eins wachsen und darf nicht umlaufen.

Der UAC erkennt eine Wiederholung an Dialog-ID, CSeq und RSeq und verwirft sie, statt den Inhalt erneut auszuführen. Trifft eine spätere RSeq vor der erwarteten ein, darf sie weder mit PRACK bestätigt noch weiterverarbeitet werden. Ein Endgerät kann sie zwischenspeichern, bis die Lücke geschlossen ist. Zuverlässigkeit heißt hier nicht bloß „irgendwann angekommen“, sondern „der richtige Zwischenstand in der richtigen Ordnung“.

Bleibt ein PRACK 64*T1 lang aus, soll der UAS die ursprüngliche Anfrage mit 5xx zurückweisen. Damit bringt die Erweiterung eigene Betriebsrisiken mit: Timer, Dialogrouting, offene Antwortlisten und Sequenzen müssen übereinstimmen. Die Norm beschreibt die korrekte Reaktion, liefert aber keine Messung darüber, wie verbreitet oder fehlerfrei sie in heutigen Netzen umgesetzt ist.

Vorläufig ausgehandelt, noch nicht endgültig angenommen

Die schärfste Trennlinie zeigt sich bei Offer/Answer. Ein zuverlässiges 1xx kann eine Sitzungsbeschreibung tragen. Enthielt das INVITE bereits ein Angebot, kann dort die Antwort erscheinen. Enthielt es keines, kann die zuverlässige vorläufige Antwort das Angebot bringen; dann muss das PRACK die Antwort enthalten. Ein PRACK darf wiederum ein neues Angebot tragen, dessen Antwort im 2xx auf PRACK steht.

Die Medienparameter können damit bereits feststehen, bevor das INVITE endgültig beantwortet ist. RFC 3262 verlangt sogar, dass ein UAS die endgültige 2xx-Annahme des INVITE verzögert, wenn eine noch unbestätigte zuverlässige vorläufige Antwort eine Sitzungsbeschreibung enthielt. Die Bestätigung schützt dann die Integrität des Offer/Answer-Austauschs. Sie ersetzt dennoch nicht die Annahme der Einladung.

RFC 6337 präzisiert die Kombination. Selbst wenn beide User Agents 100rel beherrschen, muss nicht jede vorläufige Antwort zuverlässig sein. Bei einem INVITE mit Angebot ist das erste SDP in einer zuverlässigen, nicht fehlgeschlagenen Antwort die maßgebliche Antwort; ein vorheriges SDP in einer unzuverlässigen 1xx ist lediglich eine Vorschau.

RFC 3311 erlaubt mit UPDATE Änderungen in frühen und bestätigten Dialogen. Das erweitert die Zahl möglicher Offer/Answer-Wege, verschmilzt die Methoden aber nicht. INVITE, PRACK und UPDATE behalten getrennte Transaktionen, CSeq-Werte und Ergebnisse. Implementierungen müssen wissen, welcher Austausch abgeschlossen ist und welcher noch wartet.

Frühe Medien laufen auf einer anderen Beweislinie

RFC 3960 behandelt frühe Medien wie Freizeichen, Netzansagen oder interaktive Töne vor der endgültigen Antwort. SIP-Signalisierung und Medienpfad sind lose gekoppelt; Medien können unter Umständen beobachtet werden, bevor die passende Signalisierung eintrifft.

Daraus folgt eine wichtige Negativregel. Ein PRACK beweist weder, dass RTP-Pakete den Empfänger erreicht haben, noch dass ein Mensch eine Ansage gehört hat. Eine hörbare Ansage beweist umgekehrt nicht, dass das richtige RSeq mit dem richtigen RAck bestätigt wurde. Monitoring darf beide Beobachtungen korrelieren, aber nicht gegenseitig als Bevollmächtigung verwenden.

Auch die IANA-Registrierung hat eine begrenzte Aussage. Sie führt PRACK, RAck, RSeq und 100rel mit RFC 3262 als Referenz. Damit sind Namen und Zuständigkeit belegt, nicht heutige Nutzung, Interoperabilität oder korrekte Behandlung eines bestimmten Rufes.

Schließlich ist ein passender Sequenzwert kein Identitätsnachweis. RFC 3262 warnt, ein Angreifer könne PRACK einschleusen und dadurch die Wiederholung wichtiger vorläufiger Informationen beenden. PRACK soll deshalb wie andere Anfragen authentisiert werden. Ordentliche Zustandszuordnung und Vertrauen in den Absender sind zwei getrennte Prüfungen.

Quellen