9 Connections (Connexions)

Les requêtes RTSP peuvent être transmises de plusieurs manières :

connexions de transport persistantes utilisées pour plusieurs transactions requête-réponse ;
une connexion par transaction requête/réponse ;
mode sans connexion.

Le type de connexion de transport est défini par l'URI RTSP (section 3.2). Pour le schéma « rtsp », une connexion persistante est supposée, tandis que le schéma « rtspu » impose l'envoi des requêtes RTSP sans établir de connexion.

Contrairement à HTTP, RTSP permet au serveur média d'envoyer des requêtes au client média. Toutefois, ceci n'est pris en charge que pour les connexions persistantes, car sinon le serveur média n'a pas de moyen fiable d'atteindre le client. De plus, c'est le seul mode par lequel les requêtes du serveur média vers le client ont des chances de traverser les pare-feu.

9.1 Pipelining (Enchaînement)

Un client qui prend en charge les connexions persistantes ou le mode sans connexion PEUT « enchaîner » ses requêtes (c'est-à-dire envoyer plusieurs requêtes sans attendre chaque réponse). Un serveur DOIT envoyer ses réponses à ces requêtes dans le même ordre que celui où les requêtes ont été reçues.

9.2 Reliability and Acknowledgements (Fiabilité et accusés de réception)

Les requêtes sont acquittées par le récepteur sauf si elles sont envoyées à un groupe multicast. S'il n'y a pas d'accusé de réception, l'émetteur peut renvoyer le même message après un délai d'expiration d'un aller-retour (RTT). Le temps aller-retour est estimé comme en TCP (RFC 1123) [18], avec une valeur initiale de 500 ms. Une implémentation PEUT mettre en cache la dernière mesure RTT comme valeur initiale pour les connexions futures.

Si un protocole de transport fiable est utilisé pour porter RTSP, les requêtes NE DOIVENT PAS être retransmises ; l'application RTSP DOIT plutôt s'appuyer sur le transport sous-jacent pour la fiabilité.

Si à la fois le transport fiable sous-jacent tel que TCP et l'application RTSP retransmettent les requêtes, chaque perte de paquet peut entraîner deux retransmissions. Le récepteur ne peut généralement pas tirer parti de la retransmission au niveau application car la pile de transport ne livrera pas la retransmission applicative avant que la première tentative n'atteigne le récepteur. Si la perte de paquet est due à la congestion, de multiples retransmissions à différentes couches aggraveront la congestion.

Si RTSP est utilisé sur un LAN à faible RTT, les procédures standard d'optimisation des estimations initiales du RTT TCP, telles que celles utilisées dans T/TCP (RFC 1644) [22], peuvent être utiles.

L'en-tête Timestamp (section 12.38) sert à éviter le problème d'ambiguïté de retransmission [23, p. 301] et rend superflu l'algorithme de Karn.

Chaque requête porte un numéro de séquence dans l'en-tête CSeq (section 12.17), incrémenté de un pour chaque requête distincte transmise. Si une requête est répétée faute d'accusé de réception, la requête DOIT porter le numéro de séquence d'origine (c'est-à-dire que le numéro n'est pas incrémenté).

Les systèmes implémentant RTSP DOIVENT prendre en charge le transport de RTSP sur TCP et PEUVENT prendre en charge UDP. Le port par défaut du serveur RTSP est 554 pour UDP et TCP.

Un certain nombre de paquets RTSP destinés au même point de contrôle peuvent être regroupés dans une seule PDU de couche inférieure ou encapsulés dans un flux TCP. Les données RTSP PEUVENT être entrelacées avec des paquets RTP et RTCP. Contrairement à HTTP, un message RTSP DOIT contenir un en-tête Content-Length chaque fois que le message contient une charge utile. Sinon, un paquet RTSP se termine par une ligne vide immédiatement après le dernier en-tête de message.