4 RTSP Message (Message RTSP)

RTSP est un protocole textuel et utilise le jeu de caractères ISO 10646 en encodage UTF-8 (RFC 2279 [21]). Les lignes se terminent par CRLF, mais les récepteurs devraient aussi être prêts à interpréter CR et LF seuls comme fins de ligne.

Les protocoles textuels facilitent l'ajout de paramètres optionnels de manière auto-descriptive. Comme le nombre de paramètres et la fréquence des commandes sont faibles, l'efficacité de traitement n'est pas un souci. Les protocoles textuels, si ils sont conçus avec soin, permettent aussi une mise en œuvre aisée de prototypes de recherche dans des langages de script tels que Tcl, Visual Basic et Perl.

Le jeu de caractères 10646 évite les basculements délicats de jeux de caractères, mais reste invisible à l'application tant que US-ASCII est utilisé. C'est aussi l'encodage utilisé pour RTCP. ISO 8859-1 se traduit directement en Unicode avec un octet de poids fort nul. Les caractères ISO 8859-1 dont le bit le plus significatif est à 1 sont représentés comme 1100001x 10xxxxxx. (Voir RFC 2279 [21].)

Les messages RTSP peuvent être transportés sur tout protocole de transport de couche inférieure compatible 8 bits.

Les requêtes contiennent des méthodes, l'objet sur lequel la méthode opère et des paramètres pour décrire davantage la méthode. Les méthodes sont idempotentes, sauf indication contraire. Elles sont aussi conçues pour exiger peu ou pas de maintenance d'état sur le serveur média.

4.1 Message Types (Types de messages)

Voir [H4.1]

4.2 Message Headers (En-têtes de message)

Voir [H4.2]

4.3 Message Body (Corps du message)

Voir [H4.3]

4.4 Message Length (Longueur du message)

Lorsqu'un corps de message accompagne un message, la longueur de ce corps est déterminée par l'un des éléments suivants (par ordre de priorité) :

Toute réponse qui MUST NOT inclure de corps de message (telles que les réponses 1xx, 204 et 304) se termine toujours à la première ligne vide après les champs d'en-tête, quels que soient les champs entity-header présents dans le message. (Note : une ligne vide ne contient que CRLF.)
Si un champ d'en-tête Content-Length (section 12.14) est présent, sa valeur en octets représente la longueur du message-body. Si ce champ est absent, une valeur zéro est supposée.
Par fermeture de la connexion par le serveur. (La fermeture de la connexion ne peut pas servir à indiquer la fin d'un corps de requête, car cela ne laisserait aucune possibilité au serveur de renvoyer une réponse.)

Notez que RTSP ne prend pas (à ce jour) en charge le codage de transfert « chunked » de HTTP/1.1 (voir [H3.6]) et exige la présence du champ d'en-tête Content-Length.

Compte tenu de la longueur modérée des descriptions de présentation renvoyées, le serveur devrait toujours pouvoir en déterminer la longueur, même si elle est générée dynamiquement, ce qui rend le codage de transfert par chunks inutile. Même si Content-Length doit être présent s'il y a un corps d'entité, les règles garantissent un comportement raisonnable même si la longueur n'est pas donnée explicitement.