Résumé

  • Un SETUP réussi créait chez le serveur un contexte RTSP et renvoyait son identifiant de Session ; ni la description SDP ni la seule ouverture d'une connexion TCP ne créaient cet état.
  • La session pouvait emprunter plusieurs connexions successives, mais son identifiant ne remplaçait ni l'URI correcte, ni l'état de la méthode, ni l'authentification, ni la vérification du chemin média.
  • Le serveur ne gardait le contexte qu'en présence de signes d'activité acceptables. TEARDOWN, expiration ou autre fin pouvaient transformer la commande suivante en 454 Session Not Found.

Une télécommande n'était pas son fil

RTSP est né pour commander des médias continus sans nécessairement les transporter. Une requête demandait de préparer, lire, suspendre ou arrêter ; les paquets audio et vidéo pouvaient circuler par RTP sur d'autres ports. Le protocole empruntait à HTTP sa lisibilité, mais il devait conserver entre les requêtes l'état d'une expérience en cours.

En 1998, RFC 2326 formula le choix sans détour : il n'existait pas de « connexion RTSP » à laquelle toute la séance serait attachée. Le serveur conservait une session portant un identifiant. Le client pouvait ouvrir puis fermer plusieurs connexions fiables au fil de cette même session.

TCP gardait bien sûr une fonction. Il acheminait un ordre, une réponse et parfois même des données entrelacées. Mais la disparition de cette voie ne constituait pas l'ordre d'effacer le contexte. Une prise débranchée empêchait d'appuyer sur le bouton suivant ; elle ne signifiait pas automatiquement que l'appareil avait oublié la sélection, le transport négocié et la position logique.

Cette séparation évitait de confondre deux durées : celle d'un canal de messages et celle d'un état de commande conservé à distance.

Décrire une présentation ne réservait rien

Le client pouvait d'abord recevoir une description de présentation. RFC 4566 définit SDP comme un format pour annoncer les médias, leurs encodages, leurs adresses de transport et d'autres métadonnées. SDP n'est ni un protocole de transport ni un moteur de commande.

Le mot session présent dans les deux univers prête à confusion. Un document SDP peut indiquer qu'une présentation contient une piste audio, une vidéo et des références de contrôle. Il ne prouve pas que le serveur a réservé des ports, retenu une option de transport ou ouvert un contexte pour ce spectateur.

La frontière opérationnelle était SETUP. Le client nommait une ressource média et proposait les paramètres nécessaires à sa livraison. S'il acceptait, le serveur choisissait une solution, stockait les paramètres et créait l'état que les commandes ultérieures modifieraient. RFC 7826, qui remplaça RTSP 1.0 en 2016, nomme explicitement cet ensemble le contexte de session RTSP.

La réponse SETUP donnait aussi un identifiant choisi par le serveur dans le champ Session. La description disait ce qu'il était possible de commander. La réponse disait ce que ce serveur venait effectivement d'accepter. L'une ne pouvait servir de preuve pour l'autre.

Le second nom désignait une mémoire du serveur

L'URI média désignait une ressource. L'identifiant de Session distinguait plusieurs contextes de livraison associés à cette ressource. Un même client pouvait ainsi lancer deux séances portant sur la même URI sans demander au serveur de les deviner à partir de la connexion.

RTSP 1.0 exigeait une chaîne opaque, aléatoire et longue d'au moins huit octets. RTSP 2.0 resserra le contrat : de 8 à 128 caractères, génération cryptographiquement aléatoire et recommandation d'environ 128 bits d'entropie. Le renvoi à RFC 4086 concernait la qualité de l'aléa et la difficulté de deviner le nom.

Ce renforcement n'en fit pas une identité. RFC 7826 précise que l'identifiant ne protège pas contre le détournement de session s'il n'est pas gardé confidentiel par le client, le serveur et les relais de confiance. Une valeur imprévisible peut réduire la découverte au hasard ; elle ne dit pas qui la présente ni si cette personne a encore droit au contenu.

RTSP utilisait pour cela les mécanismes d'authentification de la famille HTTP. Digest, défini par RFC 7616, possède sa propre épreuve, ses justificatifs, son nonce et ses moyens de limiter les rejeux. Le champ Session et la réponse d'authentification pouvaient coexister parce qu'ils répondaient à deux questions : quel état faut-il retrouver, et quel demandeur agit dans quel espace de protection ?

Retrouver l'état ne disait pas sur quelle ressource agir

Après SETUP, PLAY, PAUSE ou TEARDOWN transportaient l'identifiant. Une nouvelle connexion TCP pouvait donc reprendre le dialogue avec l'état existant. Toutefois, la requête conservait son URI et la méthode restait soumise à l'état courant.

Le contrôle agrégé rend cette limite visible. Plusieurs pistes d'une présentation peuvent partager une même ligne de temps : un seul PLAY doit alors démarrer l'audio et la vidéo. Une nouvelle requête SETUP peut demander d'ajouter une piste au contexte existant. Pourtant, RFC 7826 maintient une URI de contrôle agrégé distincte. Elle aide les relais à router l'ordre, indique la ressource visée et donne aux journaux une portée intelligible.

Connaître le numéro interne du dossier ne donne donc pas le droit d'appliquer n'importe quel verbe à n'importe quelle URI du dossier. RTSP séparait l'absence de session, l'emploi d'une méthode invalide dans l'état présent et l'erreur de portée agrégée. Cette grammaire empêchait qu'une clé de recherche pratique absorbe toute l'autorité du protocole.

Elle protégeait aussi l'état déjà accepté. Si un SETUP destiné à ajouter une ressource échouait, RTSP 2.0 imposait de laisser la session, le transport et les flux existants dans la situation où ils se seraient trouvés sans cette requête. Une extension ratée ne pouvait produire une demi-réécriture silencieuse.

Une connexion pouvait porter plusieurs séances

RTSP 2.0 oblige les serveurs à accepter des connexions TCP persistantes et transitoires. Un client peut envoyer SETUP et PLAY, fermer TCP, puis ouvrir plus tard un autre canal pour PAUSE. La perte d'une connexion causée par l'expiration d'un état NAT peut ainsi être surmontée au niveau de l'application.

La relation inverse existe également : une connexion persistante peut porter des commandes relatives à plusieurs sessions. Le socket n'est donc pas la clé de la séance. Pour éviter que le serveur ne sache plus où envoyer une requête vers le client, RTSP 2.0 limite toutefois chaque session à une seule connexion utilisée à un instant donné. Cette règle choisit le canal courant ; elle ne fusionne pas sa durée avec celle du contexte.

Le trajet média constitue encore une troisième réalité. SETUP peut négocier RTP sur UDP ou l'entrelacement avec le contrôle, mais la traversée effective d'un NAT ou d'un pare-feu demande des essais de connectivité. RFC 7825 adapte ICE aux médias commandés par RTSP précisément parce qu'une session valide peut coexister avec des couples d'adresses inutilisables. Session retrouve l'état ; ICE et les paquets montrent si le chemin fonctionne.

La mémoire devait recevoir des preuves de vie

Un serveur ne pouvait conserver indéfiniment tous les contextes abandonnés. La réponse SETUP pouvait annoncer le délai maximal entre deux commandes ou autres signes d'activité ; sans indication, la valeur était de 60 secondes. Dans RTSP 2.0, ce paramètre n'apparaît que dans une réponse et sa durée ne change pas pendant la session établie.

Toute requête RTSP référant le contexte pouvait montrer une activité. Pour un simple entretien, SET_PARAMETER sans corps était la méthode privilégiée. Lorsqu'un transport RTP était en place, des rapports RTCP pouvaient également compter. RFC 3550 définit ces rapports d'émetteur et de réception ; RFC 7826 les associe au tuple réseau et aux sources du serveur pour en tirer un indice de présence.

L'indice reste statistique. Les rapports suivent un calendrier et peuvent se perdre. On peut rendre une fausse expiration extrêmement improbable sans démontrer qu'une image a été affichée, qu'un humain regarde, que PLAY a produit un effet durable ou que l'autorisation commerciale reste valable. La preuve de vie justifie la conservation de l'état du protocole, rien de plus.

L'identifiant pouvait survivre dans la mémoire du client après la session

La fin normale utilisait TEARDOWN. À l'échelle agrégée, il arrêtait le groupe et détruisait le contexte ; selon l'état, un TEARDOWN ciblé pouvait retirer une seule ressource, la dernière suppression mettant fin à la session. Une expiration, une redirection terminale ou une panne irrécupérable pouvait aboutir au même résultat.

Répéter ensuite les mêmes caractères ne recréait pas l'état. Le code 454 Session Not Found signalait un identifiant absent, invalide ou expiré. Le client pouvait avoir parfaitement mémorisé la chaîne ; le serveur ne lui devait plus aucun dossier vivant.

Le mécanisme ne plaçait donc pas la session dans le jeton. Il rendait adressable un enregistrement révocable. Connexion, Session, URI, authentification, chemin média et activité formaient une chaîne d'indices dont aucun maillon ne pouvait jouer tous les rôles.