9 Connections (Verbindungen)

RTSP-Anfragen können auf verschiedene Weise übertragen werden:

persistente Transportverbindungen für mehrere Anfrage-Antwort-Transaktionen;
eine Verbindung pro Anfrage/Antwort-Transaktion;
verbindungsloser Modus.

Die Art der Transportverbindung wird durch die RTSP-URI (Abschnitt 3.2) festgelegt. Für das Schema „rtsp“ wird eine persistente Verbindung angenommen, während das Schema „rtspu“ RTSP-Anfragen ohne Verbindungsaufbau vorsieht.

Im Gegensatz zu HTTP erlaubt RTSP dem Medienserver, Anfragen an den Mediensclient zu senden. Dies wird jedoch nur bei persistenten Verbindungen unterstützt, da der Medienserver sonst keine zuverlässige Möglichkeit hat, den Client zu erreichen. Außerdem ist dies die einzige Art, bei der Anfragen vom Medienserver zum Client wahrscheinlich Firewalls passieren.

9.1 Pipelining (Pipelining)

Ein Client, der persistente Verbindungen oder den verbindungslosen Modus unterstützt, DARF seine Anfragen „pipelinen“ (d. h. mehrere Anfragen senden, ohne jeweils auf die Antwort zu warten). Ein Server MUSS seine Antworten auf diese Anfragen in derselben Reihenfolge senden, in der die Anfragen empfangen wurden.

9.2 Reliability and Acknowledgements (Zuverlässigkeit und Bestätigungen)

Anfragen werden vom Empfänger bestätigt, sofern sie nicht an eine Multicast-Gruppe gesendet werden. Gibt es keine Bestätigung, kann der Sender dieselbe Nachricht nach einem Timeout von einer Round-Trip-Zeit (RTT) erneut senden. Die Round-Trip-Zeit wird wie bei TCP (RFC 1123) [18] geschätzt, mit einem anfänglichen Wert von 500 ms. Eine Implementierung DARF die letzte RTT-Messung als Anfangswert für künftige Verbindungen zwischenspeichern.

Wird ein zuverlässiges Transportprotokoll zum Tragen von RTSP verwendet, DÜRFEN Anfragen NICHT erneut gesendet werden; die RTSP-Anwendung MUSS stattdessen auf die Zuverlässigkeit des darunterliegenden Transports vertrauen.

Wenn sowohl das zuverlässige Underlay wie TCP als auch die RTSP-Anwendung Anfragen erneut senden, kann jeder Paketverlust zu zwei Neuübertragungen führen. Der Empfänger kann die Anwendungsschicht-Neuübertragung typischerweise nicht nutzen, da der Transport-Stack die Anwendungs-Neuübertragung nicht ausliefert, bevor der erste Versuch den Empfänger erreicht hat. Wird der Paketverlust durch Überlast verursacht, verschärfen mehrfach Schichten übergreifende Neuübertragungen die Überlast.

Wird RTSP über ein LAN mit kleiner RTT eingesetzt, können Standardverfahren zur Optimierung anfänglicher TCP-RTT-Schätzungen, wie in T/TCP (RFC 1644) [22], von Nutzen sein.

Der Timestamp-Header (Abschnitt 12.38) vermeidet das Problem der Retransmissions-Mehrdeutigkeit [23, S. 301] und macht Karns Algorithmus überflüssig.

Jede Anfrage trägt eine Sequenznummer im CSeq-Header (Abschnitt 12.17), die für jede übertragene, unterscheidbare Anfrage um eins erhöht wird. Wird eine Anfrage mangels Bestätigung wiederholt, MUSS sie die ursprüngliche Sequenznummer tragen (d. h. die Nummer wird nicht erhöht).

Systeme, die RTSP implementieren, MÜSSEN RTSP über TCP tragen und DÜRFEN UDP unterstützen. Der Standardport des RTSP-Servers ist 554 für UDP und TCP.

Mehrere RTSP-Pakete mit demselben Kontroll-Endpunkt können in eine einzige PDU der unteren Schicht gepackt oder in einen TCP-Strom gekapselt werden. RTSP-Daten DÜRFEN mit RTP- und RTCP-Paketen verzahnt werden. Im Gegensatz zu HTTP MUSS eine RTSP-Nachricht immer dann ein Content-Length-Header-Feld enthalten, wenn die Nachricht eine Nutzlast hat. Andernfalls endet ein RTSP-Paket mit einer Leerzeile unmittelbar nach dem letzten Nachrichten-Header.