Die Verbindung starb. Die Sitzung nicht: Wie RTSP Zustand jenseits von TCP hielt

Zusammenfassung

• Erst ein erfolgreiches SETUP erzeugte einen Steuerungskontext auf dem Server und lieferte eine Session-Kennung; weder eine SDP-Beschreibung noch ein offener TCP-Kanal taten das.
• Der Kontext konnte einen Wechsel der Steuerungsverbindung überleben. Seine Kennung ersetzte aber weder die richtige URI und den gültigen Methodenstatus noch Authentisierung oder einen erreichbaren Medienpfad.
• Der Server bewahrte den Zustand nur mit hinreichenden Lebenszeichen. TEARDOWN, Timeout oder ein anderer Abschluss konnten dazu führen, dass derselbe Wert beim nächsten Befehl nur noch 454 Session Not Found auslöste.

Die Fernbedienung hing nicht dauerhaft am Kabel

Ein Streaming-System muss zwei Lebenszeiten verwalten. PLAY und PAUSE sind kurze Nachrichten; die vereinbarte Lieferung von Bild und Ton dauert länger. Auch die TCP-Verbindung, die einen Befehl trägt, kann früher enden als die Auswahl der Spuren, der Transportparameter und der gemeinsamen Zeitleiste.

RFC 2326 formulierte die Lösung 1998 ungewöhnlich deutlich: Es gebe keine Vorstellung einer RTSP-Verbindung. Der Server hielt eine durch eine Kennung markierte Sitzung, die von einer Transportverbindung wie TCP unabhängig war. Ein Client konnte während eines Steuerungskontexts mehrere zuverlässige Verbindungen öffnen und schließen.

TCP blieb trotzdem nötig. Befehle brauchten einen Hinweg, Antworten einen Rückweg, und Medien ließen sich sogar in den Steuerkanal einbetten. Getrennt wurden nicht die technischen Aufgaben, sondern ihre Lebenszeiten. Wenn ein Kabel abgezogen wird, kommt der nächste Tastendruck nicht an. Daraus folgt nicht, dass das Gerät die ausgewählte Präsentation, reservierten Ressourcen oder den Abspielzustand vergessen muss.

Eine Beschreibung war noch keine Reservierung

Vor der Steuerung erhielt ein Client häufig eine Präsentationsbeschreibung. SDP aus RFC 4566 stellt Medientypen, Formate, Adressen und weitere Metadaten dar. Es ist ein Format, kein Protokoll, das eine Transportzusage ausführt oder Serverzustand anlegt.

Da beide Schichten von einer Sitzung sprechen, entsteht leicht eine falsche Gleichsetzung. Ein SDP-Dokument kann Audio und Video auflisten und Steuerungsverweise enthalten. Es beweist nicht, dass der Server Ports reserviert, Puffer angelegt oder für diesen Client eine Transportalternative akzeptiert hat.

Diese Grenze überschritt SETUP. Der Client nannte eine Medienressource und bot Transportparameter an. Der Server wählte bei Erfolg eine zulässige Alternative, speicherte sie und gab das Ergebnis zurück. RFC 7826, die RTSP-2.0-Spezifikation von 2016, bezeichnete dies ausdrücklich als Anlegen eines RTSP session context. Die Beschreibung beantwortete, was angeboten wird; das erfolgreiche SETUP, welchen Zustand der Server tatsächlich übernommen hat.

Die zweite Adresse zeigte auf Erinnerung, nicht auf Inhalt

Die Medien-URI bezeichnete das steuerbare Objekt. Die Session-Kennung unterschied einen angenommenen Lieferkontext von einem anderen, auch wenn beide dieselbe URI verwendeten. RTSP 1.0 verlangte einen undurchsichtigen Zufallswert von mindestens acht Oktetten. RTSP 2.0 begrenzte ihn auf 8 bis 128 Zeichen, forderte kryptographische Zufälligkeit und empfahl ungefähr 128 Bit Entropie.

Der Verweis auf RFC 4086 betraf Vorhersagbarkeit. Eine schwache Erzeugung erleichtert es Dritten, fremde Kennungen zu erraten. Hohe Entropie macht aus der Zeichenfolge jedoch keine Berechtigung. RFC 7826 warnte, dass sie ohne Vertraulichkeit zwischen Client, Server und vertrauenswürdigen Proxys nicht gegen Sitzungsübernahme schützt.

Für die Identität und die Befugnis gab es eine eigene Schicht. Digest nach RFC 7616 arbeitet etwa mit Herausforderung, Anmeldedaten, Nonce und Schutz gegen Wiederholung. Session beantwortete: Welcher gespeicherte Kontext? Authentisierung beantwortete: Welcher Anfordernde wird in welchem Schutzbereich akzeptiert? Beide Werte konnten im selben Request stehen, weil sie nicht austauschbar waren.

Eine bekannte Kennung hob die URI nicht auf

Nach SETUP führte der Client die Session-Kennung in PLAY, PAUSE, TEARDOWN und weiteren kontextbezogenen Anforderungen mit. So konnte ein späterer TCP-Kanal denselben Serverzustand erreichen. Die Request-URI blieb dennoch erforderlich.

Das zeigt sich bei einer aggregierten Sitzung. Audio und Video können eine Zeitleiste teilen und gemeinsam auf PLAY reagieren. Eine Operation für das Ganze muss trotzdem an die korrekte aggregate control URI gehen, nicht an die Adresse einer einzelnen Spur. Die URI hilft dem Proxy beim Routing, benennt die Ressource und begrenzt den Protokoll- und Protokollierungsbereich.

Die Kennung mag genügen, um einen internen Datensatz zu finden. Sie entscheidet nicht, ob eine Methode im aktuellen Zustand zulässig ist oder auf welche Ressource sie wirken darf. RTSP unterschied deshalb eine fehlende Sitzung, eine im Zustand unzulässige Methode und eine aggregierte Operation im falschen Bereich. Ein bequemer Index sollte Ressourcenidentität, Zustandsautomat und Befugnis nicht in ein Feld pressen.

Auch fehlgeschlagene Erweiterungen wurden begrenzt. Scheiterte ein SETUP, das eine weitere Ressource zu einem vorhandenen Kontext hinzufügen sollte, mussten die frühere Sitzung und ihr Transportzustand so bleiben, als wäre der fehlgeschlagene Versuch nie eingetroffen. Ein Teilfehler durfte eine bestehende Vereinbarung nicht still verändern.

Mehrere Sitzungen pro Verbindung, mehrere Verbindungen pro Sitzung

RTSP 2.0 verlangte von Servern sowohl dauerhafte als auch vorübergehende TCP-Verbindungen. Ein Client konnte SETUP und PLAY senden, den Kanal schließen und für PAUSE einen neuen öffnen. Damit ließ sich etwa der Verlust einer TCP-Verbindung nach Ablauf eines NAT-Zustands überstehen, ohne die Präsentation vollständig neu aufzubauen.

Umgekehrt konnte eine dauerhafte Verbindung Befehle für mehrere RTSP-Sitzungen transportieren. Der Socket war daher kein Sitzungsbezeichner. Zu einem Zeitpunkt sollte ein Akteur für eine bestimmte Sitzung nur eine Verbindung benutzen, damit der Server den Weg für selbst initiierte Requests kennt. Diese Regel wählte den aktuellen Steuerkanal; sie koppelte die Lebensdauer des Zustands nicht wieder an ihn.

Der Medienpfad blieb eine weitere Ebene. RTP konnte über ausgehandelte UDP-Ports laufen oder in den Steuerstrom eingebettet sein. Ein gültiger Kontext bewies noch nicht, dass Kandidaten NAT und Firewall durchqueren. RFC 7825 passte ICE gerade deshalb an RTSP-gesteuerte Datagramm-Medien an. Session sagte, welchen Zustand ein Befehl betrifft; ICE prüfte, ob Pakete tatsächlich einen Weg haben.

Fortdauer musste durch Lebenszeichen verdient werden

Verlassene Kontexte durfte ein Server nicht unbegrenzt behalten. Die Session-Antwort konnte den Zeitraum bis zum nächsten Request oder einem anderen anerkannten Lebenszeichen mitteilen; ohne abweichenden Wert galten 60 Sekunden. In RTSP 2.0 war timeout nur ein Antwortparameter und durfte während einer bestehenden Sitzung nicht in seiner Länge geändert werden.

Jede RTSP-Anforderung, die auf den Kontext verwies, konnte Aktivität belegen. Für reines Keep-alive empfahl RTSP 2.0 ein leeres SET_PARAMETER. In RTP-Systemen konnte auch RTCP beitragen. RFC 3550 definierte Sender- und Empfängerberichte über Medienquellen und Empfang; bei passender Quelle und Netzwerktupel durften sie anzeigen, dass die Clientseite noch anwesend war.

Dieser Nachweis blieb statistisch. RTCP-Berichte kommen nach einem Zeitplan und können verloren gehen. Sie beweisen weder, dass eine Person zugesehen hat, noch dass ein Bild dekodiert, eine geschäftliche Leistung erfüllt oder ein Abonnement weiterhin berechtigt war. Ein Lebenszeichen rechtfertigte die Aufbewahrung von Protokollzustand; es war keine Quittung für das Medienerlebnis.

Die Zeichenfolge konnte den Zustand überleben

TEARDOWN beendete die Lieferung regulär. Auf aggregierter Ebene konnte es die gemeinsame Wiedergabe stoppen und den Kontext zerstören. Ein erlaubtes TEARDOWN auf Medienebene entfernte eine Komponente; mit der letzten endete die Sitzung. Auch Timeout, eine abschließende Umleitung oder ein nicht behebbarer Fehler konnten den Zustand beseitigen.

Hinter dieser Grenze erweckte die alte Kennung nichts wieder zum Leben. 454 Session Not Found galt für eine fehlende, ungültige oder abgelaufene Session. Der Client konnte exakt dieselben Zeichen gespeichert haben, obwohl der Server keinen lebenden Datensatz mehr dazu besaß.

Darin liegt die anhaltende Lehre des Mechanismus: Die Kennung enthielt die Sitzung nicht. Sie adressierte einen widerruflichen, vom Server kontrollierten Datensatz. Verbindungskontinuität, Besitz des Werts, URI-Bereich, Authentisierung, Medienerreichbarkeit und Aktivität lieferten verschiedene Belege. Keiner durfte sich als alle anderen ausgeben.