1 Introduction
1 Introduction
1.1 Purpose
Le Real-Time Streaming Protocol (RTSP) établit et contrôle un ou plusieurs flux de médias continus synchronisés dans le temps, tels que l'audio et la vidéo. Il ne livre généralement pas les flux continus lui-même, bien que l'entrelacement du flux de médias continus avec le flux de contrôle soit possible (voir Section 10.12). En d'autres termes, RTSP agit comme une "télécommande réseau" pour les serveurs multimédias.
L'ensemble des flux à contrôler est défini par une description de présentation. Ce mémorandum ne définit pas de format pour une description de présentation.
Il n'y a pas de notion de connexion RTSP; au lieu de cela, un serveur maintient une session étiquetée par un identifiant. Une session RTSP n'est en aucun cas liée à une connexion de niveau transport telle qu'une connexion TCP. Pendant une session RTSP, un client RTSP peut ouvrir et fermer de nombreuses connexions de transport fiables vers le serveur pour émettre des requêtes RTSP. Alternativement, il peut utiliser un protocole de transport sans connexion tel que UDP.
Les flux contrôlés par RTSP peuvent utiliser RTP [1], mais le fonctionnement de RTSP ne dépend pas du mécanisme de transport utilisé pour transporter les médias continus. Le protocole est intentionnellement similaire dans sa syntaxe et son fonctionnement à HTTP/1.1 [2] afin que les mécanismes d'extension HTTP puissent dans la plupart des cas également être ajoutés à RTSP. Cependant, RTSP diffère de HTTP sur plusieurs aspects importants:
- RTSP introduit un certain nombre de nouvelles méthodes et possède un identifiant de protocole différent. * Un serveur RTSP doit maintenir un état par défaut dans presque tous les cas, contrairement à la nature sans état de HTTP. * Un serveur RTSP et un client peuvent tous deux émettre des requêtes. * Les données sont transportées hors bande par un protocole différent. (Il y a une exception à cela.) * RTSP est défini pour utiliser ISO 10646 (UTF-8) plutôt que ISO 8859-1, conformément aux efforts actuels d'internationalisation HTML [3]. * Le Request-URI contient toujours l'URI absolu. En raison de la rétrocompatibilité avec une erreur historique, HTTP/1.1 [2] ne transporte que le chemin absolu dans la requête et place le nom d'hôte dans un champ d'en-tête séparé.
Cela facilite "l'hébergement virtuel", où un seul hôte avec une adresse IP héberge plusieurs arborescences de documents.
Le protocole prend en charge les opérations suivantes:
Récupération de médias depuis un serveur média: Le client peut demander une description de présentation via HTTP ou une autre méthode. Si la présentation est diffusée en multicast, la description de présentation contient les adresses multicast et les ports à utiliser pour les médias continus. Si la présentation doit être envoyée uniquement au client via unicast, le client fournit la destination pour des raisons de sécurité.
Invitation d'un serveur média à une conférence: Un serveur média peut être "invité" à rejoindre une conférence existante, soit pour lire des médias dans la présentation, soit pour enregistrer tout ou partie des médias dans une présentation. Ce mode est utile pour les applications d'enseignement distribué. Plusieurs parties dans la conférence peuvent se relayer pour "appuyer sur les boutons de la télécommande".
Ajout de médias à une présentation existante: Particulièrement pour les présentations en direct, il est utile que le serveur puisse informer le client des médias supplémentaires devenant disponibles.
Les requêtes RTSP peuvent être traitées par des proxies, des tunnels et des caches comme dans HTTP/1.1 [2].
1.2 Requirements
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans RFC 2119 [4].
1.3 Terminology
Une partie de la terminologie a été adoptée de HTTP/1.1 [2]. Les termes non listés ici sont définis comme dans HTTP/1.1.
Aggregate control: Le contrôle de plusieurs flux utilisant une seule timeline par le serveur. Pour les flux audio/vidéo, cela signifie que le client peut émettre un seul message de lecture ou de pause pour contrôler les flux audio et vidéo.
Conference: une présentation multipartite, multimédia, où "multi" implique supérieur ou égal à un.
Client: Le client demande des données de médias continus au serveur média.
Connection: Un circuit virtuel de couche transport établi entre deux programmes dans le but de communication.
Container file: Un fichier qui peut contenir plusieurs flux de médias qui comprennent souvent une présentation lorsqu'ils sont lus ensemble. Les serveurs RTSP peuvent offrir un contrôle agrégé sur ces fichiers, bien que le concept de fichier conteneur ne soit pas intégré dans le protocole.
Continuous media: Données où il existe une relation temporelle entre la source et le récepteur; c'est-à-dire que le récepteur doit reproduire la relation temporelle qui existait à la source. Les exemples les plus courants de médias continus sont l'audio et la vidéo en mouvement. Les médias continus peuvent être en temps réel (interactifs), où il existe une relation temporelle "étroite" entre la source et le récepteur, ou en streaming (lecture), où la relation est moins stricte.
Entity: Les informations transférées comme charge utile d'une requête ou d'une réponse. Une entité se compose de méta-informations sous forme de champs d'en-tête d'entité et de contenu sous forme de corps d'entité, comme décrit dans la Section 8.
Media initialization: Initialisation spécifique au type de données/codec. Cela inclut des éléments tels que les taux d'horloge, les tables de couleurs, etc. Toute information indépendante du transport requise par un client pour la lecture d'un flux média se produit dans la phase d'initialisation média de la configuration du flux.
Media parameter: Paramètre spécifique à un type de média qui peut être modifié avant ou pendant la lecture du flux.
Media server: Le serveur fournissant des services de lecture ou d'enregistrement pour un ou plusieurs flux de médias. Différents flux de médias au sein d'une présentation peuvent provenir de différents serveurs de médias. Un serveur média peut résider sur le même hôte ou un hôte différent du serveur web à partir duquel la présentation est invoquée.
Media server indirection: Redirection d'un client média vers un serveur média différent.
(Media) stream: Une instance de média unique, par exemple un flux audio ou un flux vidéo ainsi qu'un tableau blanc unique ou un groupe d'applications partagées. Lors de l'utilisation de RTP, un flux consiste en tous les paquets RTP et RTCP créés par une source au sein d'une session RTP. Cela équivaut à la définition d'un flux DSM-CC ([5]).
Message: L'unité de base de communication RTSP, consistant en une séquence structurée d'octets correspondant à la syntaxe définie dans la Section 15 et transmise via une connexion ou un protocole sans connexion.
Participant: Membre d'une conférence. Un participant peut être une machine, par exemple un serveur d'enregistrement ou de lecture de médias.
Presentation: Un ensemble d'un ou plusieurs flux présentés au client comme un flux de médias complet, utilisant une description de présentation telle que définie ci-dessous. Dans la plupart des cas dans le contexte RTSP, cela implique un contrôle agrégé de ces flux, mais ce n'est pas obligatoire.
Presentation description: Une description de présentation contient des informations sur un ou plusieurs flux de médias au sein d'une présentation, telles que l'ensemble des encodages, les adresses réseau et les informations sur le contenu. D'autres protocoles IETF tels que SDP (RFC 2327 [6]) utilisent le terme "session" pour une présentation en direct. La description de présentation peut prendre plusieurs formats différents, y compris mais sans s'y limiter le format de description de session SDP.
Response: Une réponse RTSP. Si une réponse HTTP est signifiée, cela est indiqué explicitement.
Request: Une requête RTSP. Si une requête HTTP est signifiée, cela est indiqué explicitement.
RTSP session: Une "transaction" RTSP complète, par exemple le visionnage d'un film. Une session consiste généralement en un client configurant un mécanisme de transport pour le flux de médias continu (SETUP), démarrant le flux avec PLAY ou RECORD, et fermant le flux avec TEARDOWN.
Transport initialization: La négociation des informations de transport (par exemple, numéros de port, protocoles de transport) entre le client et le serveur.
1.4 Protocol Properties
RTSP a les propriétés suivantes:
Extendable: De nouvelles méthodes et paramètres peuvent être facilement ajoutés à RTSP.
Easy to parse: RTSP peut être analysé par des analyseurs HTTP ou MIME standard.
Secure: RTSP réutilise les mécanismes de sécurité web. Tous les mécanismes d'authentification HTTP tels que l'authentification basique (RFC 2068 [2, Section 11.1]) et l'authentification digest (RFC 2069 [8]) sont directement applicables. On peut également réutiliser les mécanismes de sécurité de la couche transport ou réseau.
Transport-independent: RTSP peut utiliser soit un protocole de datagramme non fiable (UDP) (RFC 768 [9]), un protocole de datagramme fiable (RDP, RFC 1151, peu utilisé [10]) ou un protocole de flux fiable tel que TCP (RFC 793 [11]) car il implémente une fiabilité au niveau application.
Multi-server capable: Chaque flux de médias au sein d'une présentation peut résider sur un serveur différent. Le client établit automatiquement plusieurs sessions de contrôle simultanées avec les différents serveurs de médias. La synchronisation des médias est effectuée au niveau transport.
Control of recording devices: Le protocole peut contrôler à la fois les appareils d'enregistrement et de lecture, ainsi que les appareils qui peuvent alterner entre les deux modes ("VCR").
Separation of stream control and conference initiation: Le contrôle du flux est séparé de l'invitation d'un serveur média à une conférence. La seule exigence est que le protocole d'initiation de conférence fournisse ou puisse être utilisé pour créer un identifiant de conférence unique. En particulier, SIP [12] ou H.323 [13] peuvent être utilisés pour inviter un serveur à une conférence.
Suitable for professional applications: RTSP prend en charge la précision au niveau trame grâce aux horodatages SMPTE pour permettre l'édition numérique à distance.
Presentation description neutral: Le protocole n'impose pas de format de description de présentation ou de métafichier particulier et peut transmettre le type de format à utiliser. Cependant, la description de présentation doit contenir au moins un URI RTSP.
Proxy and firewall friendly: Le protocole devrait être facilement géré par les pare-feu d'application et de couche transport (SOCKS [14]). Un pare-feu peut avoir besoin de comprendre la méthode SETUP pour ouvrir un "trou" pour le flux de médias UDP.
HTTP-friendly: Lorsque cela est raisonnable, RTSP réutilise les concepts HTTP, de sorte que l'infrastructure existante peut être réutilisée. Cette infrastructure inclut PICS (Platform for Internet Content Selection [15,16]) pour associer des étiquettes au contenu. Cependant, RTSP n'ajoute pas simplement des méthodes à HTTP car le contrôle des médias continus nécessite un état du serveur dans la plupart des cas.
Appropriate server control: Si un client peut démarrer un flux, il doit pouvoir l'arrêter. Les serveurs ne doivent pas commencer à diffuser vers les clients de manière à ce que les clients ne puissent pas arrêter le flux.
Transport negotiation: Le client peut négocier la méthode de transport avant d'avoir réellement besoin de traiter un flux de médias continu.
Capability negotiation: Si les fonctionnalités de base sont désactivées, il doit y avoir un mécanisme propre permettant au client de déterminer quelles méthodes ne seront pas implémentées. Cela permet aux clients de présenter l'interface utilisateur appropriée. Par exemple, si la recherche n'est pas autorisée, l'interface utilisateur doit pouvoir interdire le déplacement d'un indicateur de position coulissant.
Une exigence antérieure dans RTSP était la capacité multi-client. Cependant, il a été déterminé qu'une meilleure approche consistait à s'assurer que le protocole est facilement extensible au scénario multi-client. Les identifiants de flux peuvent être utilisés par plusieurs flux de contrôle, de sorte que "passer la télécommande" serait possible. Le protocole ne traiterait pas de la manière dont plusieurs clients négocient l'accès; cela est laissé soit à un "protocole social" soit à un autre mécanisme de contrôle d'accès.
1.5 Extending RTSP
Étant donné que tous les serveurs de médias n'ont pas la même fonctionnalité, les serveurs de médias supporteront nécessairement différents ensembles de requêtes. Par exemple:
- Un serveur peut être uniquement capable de lecture et n'a donc pas besoin de supporter la requête RECORD. * Un serveur peut ne pas être capable de recherche (positionnement absolu) s'il doit supporter uniquement des événements en direct. * Certains serveurs peuvent ne pas supporter la définition de paramètres de flux et donc ne pas supporter GET_PARAMETER et SET_PARAMETER.
Un serveur DEVRAIT implémenter tous les champs d'en-tête décrits dans la Section 12.
Il appartient aux créateurs de descriptions de présentation de ne pas demander l'impossible à un serveur. Cette situation est similaire dans HTTP/1.1 [2], où les méthodes décrites dans [H19.6] ne sont probablement pas supportées sur tous les serveurs.
RTSP peut être étendu de trois manières, listées ici par ordre de grandeur des changements supportés:
- Les méthodes existantes peuvent être étendues avec de nouveaux paramètres, tant que ces paramètres peuvent être ignorés en toute sécurité par le destinataire. (Cela équivaut à ajouter de nouveaux paramètres à une balise HTML.) Si le client a besoin d'un accusé de réception négatif lorsqu'une extension de méthode n'est pas supportée, une balise correspondant à l'extension peut être ajoutée dans le champ Require: (voir Section 12.32). * De nouvelles méthodes peuvent être ajoutées. Si le destinataire du message ne comprend pas la requête, il répond avec le code d'erreur 501 (Not implemented) et l'expéditeur ne devrait pas tenter d'utiliser cette méthode à nouveau. Un client peut également utiliser la méthode OPTIONS pour s'enquérir des méthodes supportées par le serveur. Le serveur DEVRAIT lister les méthodes qu'il supporte en utilisant l'en-tête de réponse Public. * Une nouvelle version du protocole peut être définie, permettant à presque tous les aspects (sauf la position du numéro de version du protocole) de changer.
1.6 Overall Operation
Chaque présentation et flux de médias peut être identifié par une URL RTSP. La présentation globale et les propriétés des médias dont la présentation est composée sont définies par un fichier de description de présentation, dont le format est en dehors de la portée de cette spécification. Le fichier de description de présentation peut être obtenu par le client en utilisant HTTP ou d'autres moyens tels que le courrier électronique et peut ne pas nécessairement être stocké sur le serveur média.
Aux fins de cette spécification, une description de présentation est supposée décrire une ou plusieurs présentations, chacune maintenant un axe de temps commun. Pour simplifier l'exposition et sans perte de généralité, il est supposé que la description de présentation contient exactement une telle présentation. Une présentation peut contenir plusieurs flux de médias.
Le fichier de description de présentation contient une description des flux de médias composant la présentation, y compris leurs encodages, langue et autres paramètres permettant au client de choisir la combinaison de médias la plus appropriée. Dans cette description de présentation, chaque flux de médias qui est individuellement contrôlable par RTSP est identifié par une URL RTSP, qui pointe vers le serveur média gérant ce flux de médias particulier et nomme le flux stocké sur ce serveur. Plusieurs flux de médias peuvent être situés sur différents serveurs; par exemple, les flux audio et vidéo peuvent être répartis sur plusieurs serveurs pour le partage de charge. La description énumère également les méthodes de transport que le serveur est capable d'utiliser.
Outre les paramètres de médias, l'adresse de destination réseau et le port doivent être déterminés. Plusieurs modes de fonctionnement peuvent être distingués:
Unicast: Les médias sont transmis à la source de la requête RTSP, avec le numéro de port choisi par le client. Alternativement, les médias sont transmis sur le même flux fiable que RTSP.
Multicast, server chooses address: Le serveur média choisit l'adresse multicast et le port. C'est le cas typique pour une transmission en direct ou quasi-média-à-la-demande.
Multicast, client chooses address: Si le serveur doit participer à une conférence multicast existante, l'adresse multicast, le port et la clé de chiffrement sont donnés par la description de conférence, établie par des moyens en dehors de la portée de cette spécification.
1.7 RTSP States
RTSP contrôle un flux qui peut être envoyé via un protocole séparé, indépendant du canal de contrôle. Par exemple, le contrôle RTSP peut se produire sur une connexion TCP tandis que les données circulent via UDP. Ainsi, la livraison de données continue même si aucune requête RTSP n'est reçue par le serveur média. De plus, pendant sa durée de vie, un seul flux de médias peut être contrôlé par des requêtes RTSP émises séquentiellement sur différentes connexions TCP. Par conséquent, le serveur doit maintenir un "état de session" pour pouvoir corréler les requêtes RTSP avec un flux. Les transitions d'état sont décrites dans la Section A.
De nombreuses méthodes dans RTSP ne contribuent pas à l'état. Cependant, les suivantes jouent un rôle central dans la définition de l'allocation et de l'utilisation des ressources de flux sur le serveur: SETUP, PLAY, RECORD, PAUSE et TEARDOWN.
SETUP: Fait en sorte que le serveur alloue des ressources pour un flux et démarre une session RTSP.
PLAY et RECORD: Démarre la transmission de données sur un flux alloué via SETUP.
PAUSE: Arrête temporairement un flux sans libérer les ressources du serveur.
TEARDOWN: Libère les ressources associées au flux. La session RTSP cesse d'exister sur le serveur.
Les méthodes RTSP qui contribuent à l'état utilisent le champ d'en-tête Session (Section 12.37) pour identifier la session RTSP dont l'état est manipulé. Le serveur génère des identifiants de session en réponse aux requêtes SETUP (Section 10.4).
1.8 Relationship with Other Protocols
RTSP a un certain chevauchement fonctionnel avec HTTP. Il peut également interagir avec HTTP dans la mesure où le contact initial avec le contenu en streaming doit souvent être effectué via une page web. La spécification de protocole actuelle vise à permettre différents points de transfert entre un serveur web et le serveur média implémentant RTSP. Par exemple, la description de présentation peut être récupérée en utilisant HTTP ou RTSP, ce qui réduit les allers-retours dans les scénarios basés sur un navigateur web, tout en permettant également des serveurs et clients RTSP autonomes qui ne dépendent pas du tout de HTTP.
Cependant, RTSP diffère fondamentalement de HTTP en ce que la livraison de données a lieu hors bande dans un protocole différent. HTTP est un protocole asymétrique où le client émet des requêtes et le serveur répond. Dans RTSP, le client média et le serveur média peuvent tous deux émettre des requêtes. Les requêtes RTSP ne sont pas non plus sans état; elles peuvent définir des paramètres et continuer à contrôler un flux de médias longtemps après que la requête a été acquittée.
La réutilisation de la fonctionnalité HTTP présente des avantages dans au moins deux domaines, à savoir la sécurité et les proxies. Les exigences sont très similaires, donc avoir la capacité d'adopter le travail HTTP sur les caches, proxies et l'authentification est précieux.
Bien que la plupart des médias en temps réel utiliseront RTP comme protocole de transport, RTSP n'est pas lié à RTP.
RTSP suppose l'existence d'un format de description de présentation qui peut exprimer les propriétés statiques et temporelles d'une présentation contenant plusieurs flux de médias.