4 RTSP Message (RTSP-Nachricht)

RTSP ist ein textbasiertes Protokoll und verwendet den Zeichensatz ISO 10646 in UTF-8-Kodierung (RFC 2279 [21]). Zeilen enden mit CRLF, Empfänger sollten jedoch auch CR und LF allein als Zeilenenden interpretieren können.

Textbasierte Protokolle erleichtern das Hinzufügen optionaler Parameter in selbstbeschreibender Weise. Da die Anzahl der Parameter und die Häufigkeit von Befehlen gering ist, ist Verarbeitungseffizienz kein Anliegen. Textbasierte Protokolle erlauben bei sorgfältiger Gestaltung auch eine einfache Implementierung von Forschungsprototypen in Skriptsprachen wie Tcl, Visual Basic und Perl.

Der Zeichensatz 10646 vermeidet knifflige Zeichensatzwechsel, bleibt für die Anwendung jedoch unsichtbar, solange US-ASCII verwendet wird. Dies ist auch die Kodierung für RTCP. ISO 8859-1 lässt sich direkt in Unicode mit einem höherwertigen Oktett von null abbilden. ISO-8859-1-Zeichen mit gesetztem höchstwertigem Bit werden als 1100001x 10xxxxxx dargestellt. (Siehe RFC 2279 [21].)

RTSP-Nachrichten können über jedes unterlagige Transportprotokoll übertragen werden, das 8-bit-sauber ist.

Anfragen enthalten Methoden, das Objekt, auf das die Methode wirkt, und Parameter zur weiteren Beschreibung der Methoden. Methoden sind idempotent, sofern nicht anders angegeben. Sie sind außerdem so konzipiert, dass am Medienserver nur wenig oder kein Zustand gepflegt werden muss.

4.1 Message Types (Nachrichtentypen)

Siehe [H4.1]

4.2 Message Headers (Nachrichtenköpfe)

Siehe [H4.2]

4.3 Message Body (Nachrichtenkörper)

Siehe [H4.3]

4.4 Message Length (Nachrichtenlänge)

Wenn einer Nachricht ein Nachrichtenkörper beigefügt ist, wird dessen Länge durch eines der folgenden Kriterien bestimmt (in der Reihenfolge der Vorrangigkeit):

Jede Antwortnachricht, die MUST NOT einen Nachrichtenkörper enthalten darf (wie die Antworten 1xx, 204 und 304), endet stets bei der ersten Leerzeile nach den Header-Feldern, unabhängig von den in der Nachricht vorhandenen entity-header-Feldern. (Hinweis: Eine Leerzeile besteht nur aus CRLF.)
Ist ein Content-Length-Header-Feld (Abschnitt 12.14) vorhanden, gibt sein Wert in Bytes die Länge des message-body an. Fehlt dieses Header-Feld, wird null angenommen.
Durch Schließen der Verbindung durch den Server. (Das Schließen der Verbindung kann nicht das Ende eines Anfragekörpers signalisieren, da dem Server sonst keine Möglichkeit bliebe, eine Antwort zurückzusenden.)

Beachten Sie, dass RTSP (derzeit) die „chunked“-Transfer-Codierung von HTTP/1.1 nicht unterstützt (siehe [H3.6]) und die Anwesenheit des Content-Length-Header-Feldes verlangt.

Angesichts der mäßigen Länge zurückgegebener Präsentationsbeschreibungen sollte der Server stets in der Lage sein, deren Länge zu bestimmen, selbst wenn sie dynamisch erzeugt wird, wodurch die Chunked-Transfer-Codierung entbehrlich wird. Obwohl Content-Length vorhanden sein muss, wenn es einen Entitätskörper gibt, sorgen die Regeln für ein angemessenes Verhalten auch dann, wenn die Länge nicht ausdrücklich angegeben ist.