Groupe de travail Réseau	H. Schulzrinne, Columbia U.	
Request for Comments : 2326	A. Rao, Netscape	
Catégorie : En cours de normalisation	R. Lanphier, RealNetworks	
Traduction Claude Brière de L'Isle	avril 1998	

Protocole de flux directs en temps réel (RTSP)

Statut du présent Mémo
La présente RFC spécifie un protocole de normalisation pour la communauté de l'Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles de protocole de l'Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (1998). Tous droits réservés.

Résumé
Le protocole de flux directs en temps réel (RTSP, Real Time Streaming Protocol) est un protocole de niveau application pour le contrôle de la livraison de données avec des propriétés de temps réel. RTSP fournit un cadre de travail extensible pour permettre une livraison à la demande contrôlée de données en temps réel, telles que audio et vidéo. Les sources des données peuvent inclure à la fois des données alimentées en direct et des extraits mémorisés. Le présent protocole est destiné à contrôler plusieurs sessions de livraison de données, à fournir le moyen de choisir des canaux de livraison tels que UDP, UDP en diffusion groupée et TCP, et à fournir un moyen pour choisir les mécanismes de livraison fondés sur RTP (RFC 1889).

Table des Matières
1	Introduction
1.1	Objet
1.2	Exigences
1.3	Terminologie
1.4	Propriétés du protocole
1.5	Extensions à RTSP
1.6	Fonctionnement global
1.7	États de RTSP
1.8	Relations avec les autres protocoles
2	Conventions de notation
3	Paramètres du protocole
3.1	Version RTSP
3.2	URL RTSP
3.3	Identifiants de conférence
3.4	Identifiants de session
3.5	Horodatages relatifs à SMPTE
3.6	Heure d'exécution normale
3.7	Heure absolue
3.8	Étiquettes d'option
4	Message RTSP
4.1	Types de message
4.2	En-têtes de message
4.3	Corps de message
4.4	Longueur du message
5	Champs d'en-tête généraux
6	Demande
6.1	Ligne de demande
6.2	Champs d'en-tête de demande
7	Réponse
7.1	Ligne d'état
8	Entité
8.1	Champs d'en-tête d'entité
8.2	Corps d'entité
9	Connexions
9.1	Traitement en parallèle
9.2	Fiabilité et accusé de réception
10	Définitions de la méthode
10.1	OPTIONS
10.2	DESCRIBE
10.3	ANNOUNCE
10.4	SETUP
10.5	PLAY
10.6	PAUSE
10.7	TEARDOWN
10.8	GET_PARAMETER
10.9	SET_PARAMETER
10.10	REDIRECT
10.11	RECORD
10.12	Données binaires incorporées (entrelacées)
11	Définitions des codes d'état
11.1	2xx Réussite
11.2	3xx Redirection
11.3	4xx Erreur client
12	Définitions de champ d'en-tête
12.1	Accept
12.2	Codage de Accept
12.3	Accept-Language
12.4	Allow
12.5	Authorization
12.6	Bandwidth
12.7	Blocksize
12.8	Cache-Control
12.9	Conference
12.10	Connection
12.11	Content-Base
12.12	Content-Encoding
12.13	Content-Language
12.14	Content-Length
12.15	Content-Location
12.16	Content-Type
12.17	CSeq
12.18	Date
12.19	Expires
12.20	From
12.21	Host
12.22	If-Match
12.23	If-Modified-Since
12.24	Last-Modified
12.25	Location
12.26	Proxy-Authenticate
12.27	Proxy-Require
12.28	Public
12.29	Range
12.30	Referer
12.31	Retry-After
12.32	Require
12.33	RTP-Info
12.34	Scale
12.35	Speed
12.36	Server
12.37	Session
12.38	Timestamp
12.39	Transport
12.40	Unsupported
12.41	User-Agent
12.42	Vary
12.43	Via
12.44	WWW-Authentica
13	Mise en antémémoire
14	Exemples
14.1	Support à la demande (en envoi individuel)
14.2	Défilement d'un fichier conteneur
14.3	Fichiers conteneur d'un seul flux
14.4	Présentation d'un support de direct en utilisant la diffusion groupée
14.5	Exécuter un support dans une session existante
14.6	Enregistrement
15	Syntaxe
15.1	Syntaxe de base
16	Considérations pour la sécurité
Appendice A	Automates à états du protocole RTSP
A.1	Automate à états de client
A.2	Automate à état de serveur
Appendice B	Interaction avec RTP
Appendice C	Utilisation de SDP pour les descriptions de session RTSP
C.1	Définitions
C.2	Contrôle agrégé non disponible
C.3	Contrôle agrégé disponible
Appendice D	Mise en œuvre minimale de RTSP
D.1	Client
D.2	Serveur
Appendice E	Adresse des auteurs
Appendice F	Remerciements
Références
Déclaration complète de droits de reproduction

1	Introduction
1.1	Objet

Le protocole de flux direct en temps réel (RTSP, Real-Time Streaming Protocol) établit et contrôle un ou plusieurs flux à synchronisation temporelle de supports continus tels que l'audio et la vidéo. Il ne livre normalement pas lui-même les flux continus, bien que l'entrelacement du flux de support continu avec le flux de contrôle soit possible (voir au paragraphe 10.12). En d'autres termes, RTSP agit comme une "commande de réseau à distance" pour serveurs multimédia.

L'ensemble des flux à contrôler est défini par une description de présentation. Le présent mémoire ne définit pas de format pour une description de présentation.

Il n'y a aucune notion de connexion RTSP ; au lieu de cela, un serveur maintient une session étiquetée par un identifiant. Une session RTSP n'est en aucune façon liée à une connexion de niveau transport comme l'est une connexion TCP. Durant une session RTSP, un client RTSP peut ouvrir et fermer de nombreuses connexions de transport fiables avec le serveur pour émettre les demandes RTSP. Autrement, 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 porter le support continu. Le protocole est intentionnellement similaire dans sa syntaxe et son fonctionnement à HTTP/1.1 [2] de sorte que les mécanismes d'extension à HTTP peuvent dans la plupart des cas être aussi ajoutés à RTSP. Cependant, RTSP diffère sous un certain nombre d'aspects importants de HTTP :
*	RTSP introduit un certain nombre de nouvelles méthodes et a un identifiant de protocole différent.
*	Un serveur RTSP a besoin de conserver un état par défaut dans presque tous les cas, par opposition à la nature sans état de HTTP.
*	Un serveur et un client RTSP peuvent tous deux émettre des demandes.
*	Les données sont portées hors bande par un protocole différent. (Il y a une exception à cela.)
*	RTSP est défini comme utilisant ISO 10646 (UTF-8) plutôt que ISO 8859-1, en cohérence avec les efforts actuels d'internationalisation de HTML [3].
*	L'URI de demande contient toujours l'URI absolue. À cause de la rétro compatibilité avec une bévue historique, HTTP/1.1 [2] ne porte que le chemin absolu dans la demande et met le nom d'hôte dans un champ d'en-tête séparé.

Cela rend plus faciles les "hôtes virtuels", où un seul hôte avec une seule adresse IP héberge plusieurs arborescences documentaires.

Le protocole prend en charge les opérations suivantes :

Restitution du support à partir du serveur de support :
Le client peut demander une description de présentation via HTTP ou une autre méthode. Si la présentation va être en diffusion groupée, la description de présentation contient les adresses de diffusion groupée et les accès à utiliser pour le support continu. Si la présentation n'est à envoyer au client que via l'envoi individuel, le client fournit la destination pour des raisons de sécurité.

Invitation d'un serveur de support à une conférence :
Un serveur de support peut être "invité" à se joindre à une conférence existante, soit pour rejouer le support dans la présentation soit pour enregistrer tout ou partie du support dans une présentation. Ce mode est utile pour les applications d'enseignement réparties. Plusieurs parties à la conférence peuvent tour à tour "pousser les boutons de commande à distance."

Ajout d'un support à une présentation existante :
En particulier pour les présentations en direct, il est utile si le serveur peut dire au client ce qu'il en est des supports supplémentaires qui deviennent disponibles.

Les demandes RTSP peuvent être traitées par des mandataires, des tunnels et des antémémoires comme dans HTTP/1.1 [2].

1.2	Exigences

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUTAY", et "FACULTATIF" dans ces document sont à interpréter comme décrit dans la RFC 2119 [4].

1.3	Terminologie

Une partie de la terminologie est tirée de HTTP/1.1 [2]. Les termes qui ne figurent pas ici sont définis comme dans HTTP/1.1.

Contrôle agrégé : contrôle de plusieurs flux par le serveur en utilisant une seule ligne chronologique. Pour l'alimentation en audio/vidéo, cela signifie que le client peut émettre un seul message play ou pause pour commander les deux alimentations audio et vidéo.

Conférence : présentation multipartie multimédia, où "multi" implique supérieur ou égal à un.

Client : le client demande des données de support continues au serveur de supports.

Connexion : circuit virtuel de couche transport établie entre deux programmes pour les besoins de la communication.

Fichier conteneur : fichier qui peut contenir plusieurs flux de support qui comportent souvent une présentation lorsqu'ils sont exécutés ensemble. Les serveurs RTSP peuvent souvent agréger le contrôle sur ces fichiers, bien que le concept de fichier conteneur ne soit pas incorporé dans le protocole.

Support continu : données dans lesquelles il y a une relation de temps entre la source et le collecteur ; c'est-à-dire que le collecteur doit reproduire la relations de temps qui existait à la source. Les exemples les plus courants de support continu sont l'audio et la vidéo animée. Les supports continus peuvent être en temps réel (interactifs), lorsque il y a une relation "serrée" entre la source et le collecteur, ou en direct (réexécution), où la relation est moins stricte.

Entité : les informations transférées comme charge utile d'une demande ou réponse. Une entité consiste en méta informations sous la forme de champs d'en-tête d'entité et d'un contenu sous la forme d'un corps d'entité, comme décrit à la Section 8.

Initialisation de support : initialisation spécifique du type de données/codec. Cela inclut des choses comme les débits d'horloge, les tableaux de couleurs, etc. Toute information indépendante du transport qui est exigée d'un client pour la réexécution d'un flux de support survient dans la phase d'initialisation du support de l'établissement d'un flux.

Paramètre de support : paramètre spécifique d'un type de support qui peut être changé avant ou durant la réexécution du flux.

Serveur de support : serveur qui fournit des services de réexécution ou d'enregistrement pour un ou plusieurs flux de support. Différents flux de support au sein d'une présentation peut provenir de différent serveurs de supports. Un serveur de supports peut résider sur le même hôte ou un hôte différent comme le serveur de la Toile d'où la présentation est invoquée.

Adressage indirect de serveur de support : redirection d'un client de support sur un serveur de supports différent.

Flux (de support) : une seule instance de support, par exemple, un flux audio ou un flux vidéo aussi bien qu'un seul tableau blanc ou un groupe d'application partagée. Lorsque on utilise RTP, un flux consiste en tous les paquets RTP et RTCP créés par une source au sein d'une session RTP. Ceci est équivalent à la définition d'un flux DSM-CC ([5]).

Message : unité de base des communications RTSP, consistant en une séquence d'octets structurée satisfaisant à la syntaxe définie à la Section 15 et transmise via un protocole de connexion ou sans connexion.

Participant : membre d'une conférence. Un participant peut être une machine, par exemple, un enregistreur ou un serveur de réexécution.

Présentation : ensemble d'un ou plusieurs flux présentés au client comme un aliment de flux complet, utilisant une description de présentation comme défini ci-dessous. Dans la plupart des cas dans le contexte RTSP, cela implique le contrôle agrégé de ces flux, mais ce n'est pas obligatoire.

Description de présentation : une description de présentation contient des informations sur un ou plusieurs flux de support au sein d'une présentation, comme l'ensemble des codages, des adresses réseau et des informations sur le contenu. D'autres protocoles de l'IETF comme SDP (RFC 2327 [6]) utilisent le terme de "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.

Réponse : une réponse RTSP. Si on veut dire une réponse HTTP, c'est indiqué explicitement.

Demande  : une demande RTSP. Si on veut dire une demande HTTP, c'est indiqué explicitement.

Session RTSP : une "transaction" RTSP complète, par exemple, le visionnage d'un film. Une session consiste normalement en un s client qui établit un mécanisme de transport pour le flux de support continu (SETUP), qui commence le flux par PLAY ou RECORD, et ferme le flux avec TEARDOWN.

Initialisation du transport : négociation des informations de transport (par exemple, numéros d'accès, protocoles de transport) entre le client et le serveur.

1.4	Propriétés du protocole

RTSP a les propriétés suivantes :

Extensible : de nouvelles méthodes et paramètres peuvent être facilement ajoutés à RTSP.

Facile à analyser : RTSP peut être analysé par des analyseurs HTTP ou MIME standard.

Sûr : RTSP réutilise les mécanismes de sécurité de la Toile. Tous les mécanismes d'authentification HTTP tels que l'authentification de base (RFC 2068 [2, paragraphe 11.1]) et par résumé (RFC 2069 [8]) sont directement applicables. On peut aussi réutiliser les mécanismes de sécurité de la couche transport ou réseau.

Indépendant du transport : RTSP peut utiliser un protocole de datagrammes non fiabilisé (UDP) (RFC 768 [9]), un protocole de datagrammes fiable (RDP, RFC 1151, un protocole peu utilisé [10]) ou un protocole de flux fiable tel que TCP (RFC 793 [11]) car il met en œuvre la fiabilité de niveau application.

À capacité multiserveur : chaque flux de support au sein d'une présentation peut résider sur un serveur différent. Le client établit automatiquement plusieurs sessions de contrôle concurrentes avec les différents serveurs de supports. La synchronisation des supports est effectuée au niveau transport.

Contrôle des appareils d'enregistrement : le protocole peut contrôler aussi bien les appareils d'enregistrement que de réexécution, ainsi que les appareils qui peuvent alterner les deux modes ("VCR").

Séparation du contrôle de flux et de l'initialisation de conférence : Le contrôle de flux est séparé de l'invitation d'un serveur de supports à une conférence. La seule exigence est que le protocole d'initialisation de conférence fournisse ou puisse être utilisé pour créer un identifiant de conférence univoque. En particulier, SIP [12] ou la Recommandation UIT-T H.323 [13] peuvent être utilisés pour inviter un serveur à une conférence.

Convenable pour les applications professionnelles : RTSP prend en charge la précision du niveau de trame grâce aux horodatages SMPTE pour permettre l'édition numérique à distance.

Neutre pour la description de présentation : le protocole n'impose pas de description de présentation ou format de métafichier particulier et peut porter le type de format à utiliser. Cependant, la description de présentation doit contenir au moins un URI RTSP.

Facile pour mandataires et pare-feu : le protocole devrait être traité directement à la fois par les pare-feu d'application et de couche transport (SOCKS [14]). Un pare-feu peut avoie besoin de comprendre la méthode SETUP pour ouvrit un "trou" pour le flux de support UDP.

Facile pour HTTP : lorsque cela a un sens, RTSP réutilise les concepts de HTTP, de sorte que l'infrastructure existante puisse être réutilisée. Cette infrastructure comporte une PICS (plate-forme de choix de contenu Internet) [15,16]) pour associer des étiquettes à des contenus. Cependant, RTSP ne fait pas qu'ajouter des méthodes à HTTP car le support de contrôle continu exige un état du serveur dans la plupart des cas.

Contrôle approprié du serveur : si un client peut commencer un flux, il doit être capable d'arrêter un flux. Les serveurs ne devraient pas commencer la distribution de flux à des clients d'une façon telle que les clients ne puissent pas arrêter le flux.

Négociation du transport : le client peut négocier la méthode de transport avoir f'avoir réellement besoin de traiter un flux de support continu.

Négociation de capacité : si les caractéristiques de base sont désactivées, il doit y avoir un mécanisme clair pour que le client détermine quelles méthodes vont être mises en œuvre. Cela permet aux clients de présenter l'interface d'utilisateur appropriée. Par exemple, si la recherche n'est pas permise, l'interface d'utilisateur doit être capable d'interdire de déplacer un indicateur de position glissant.

Une exigence précédente de RTSP était la capacité multi-client. Cependant, il a été déterminé qu'une meilleure approche serait de s'assurer que le protocole était facilement extensible au scénario multi-client. Les identifiants de flux peuvent être utilisés par plusieurs flux de contrôle, de sorte que soit possible le "passage au client distant". Le protocole ne traiterait pas comment plusieurs clients négocient l'accès ; ceci est laissé soit à un "protocole social" soit à quelque autre mécanisme de contrôle plancher.

1.5	Extensions à RTSP

Comme tous les serveurs de supports n'ont pas les mêmes fonctionnalités, les serveurs de supports vont nécessairement prendre en charge des ensembles différents de demandes. Par exemple :

*	Un serveur peut n'être capable que de reproduction et n'aura donc pas besoin de prendre en charge la demande RECORD.
*	Un serveur peut n'être pas capable de recherche (positionnement absolu) si il ne prend en charge que des événements en direct.
*	Certains serveurs peuvent ne pas prendre en charge l'établissement des paramètres de flux et ne prendre donc pas en charge les paramètres GET_PARAMETER et SET_PARAMETER.

Un serveur DEVRAIT mettre en œuvre tous les champs d'en-tête décrits à la Section 12.

Il appartient aux créateurs des descriptions de présentation de ne pas demander l'impossible à un serveur. Cette situation est similaire à celle de HTTP/1.1 [2], où les méthodes décrites dans [H19.6] ne sont vraisemblablement pas prises en charge par tous les serveurs.

RTSP peut être étendu de trois façons, énumérées ci-après selon l'ordre de grandeur des changements pris en charge :

*	Les méthodes existantes peuvent être étendues par de nouveaux paramètres, pour autant que ces paramètres puissent être ignorés en toute sécurité par le receveur. (Ceci est équivalent à l'ajout de nouveaux paramètres à une étiquette HTML.) Si le client a besoin d'un accusé de réception négatif lorsque une extension de méthode n'est pas prise en charge, un étiquette correspondant à l'extension peut être ajoutée dans le champ Require: (voir au paragraphe 12.32).
*	De nouvelles méthodes peuvent être ajoutées. Si le receveur du message ne comprend pas la demande, il répond par un code d'erreur 501 (Non mis en œuvre) et l'envoyeur ne devrait pas essayer d'utiliser à nouveau cette méthode. Un client peut aussi utiliser la méthode OPTIONS pour enquêter sur les méthodes prises en charge par le serveur. Le serveur DEVRAIT faire la liste des méthodes qu'il prend en charge en utilisant l'en-tête de réponse Public.
*	Une nouvelle version du protocole peut être définie, ce qui permet de changer presque tous les aspects (excepté la position du numéro de version du protocole).

1.6	Fonctionnement global

Chaque présentation et chaque flux de support peut être identifié par un URI RTSP. La présentation globale et les propriétés du support dont la présentation est constituée sont définies par une description de fichier de présentation, dont le format sort du domaine d'application de la présente spécification. Le fichier de description de présentation peut être obtenu par le client en utilisant HTTP ou tout autre moyen tel que la messagerie électronique et n'est pas nécessairement mémorisé sur le serveur de supports.

Pour les besoins de la présente spécification, une description de présentation est supposée décrire une ou plusieurs présentations, chacune d'elles conservant un axe des temps commun. Pour simplifier l'exposé et sans perte des grandes lignes, on supposera que la description de présentation contient exactement une de ces présentations. Une présentation peut contenir plusieurs flux de supports.

Le fichier de description de présentation contient une description des flux de supports qui constituent la présentation, y compris leurs codages, langages, et autres paramètres qui permettent au client de choisir la combinaison de supports la plus appropriée. Dans cette description de présentation, chaque flux de support qui est individuellement contrôlable par RTSP est identifié par un URI RTSP, qui pointe sur le serveur de supports qui traite de flux de support particulier et désigne le flux mémorisé sur ce serveur. Plusieurs flux de supports peuvent être localisés sur des serveurs différents ; par exemple, des flux audio et vidéo peuvent être partagés entre des serveurs pour un partage de la charge. La description énumère aussi les méthodes de transport dont le serveur est capable.

À côté des paramètres des supports, il faut aussi déterminer l'adresse et l'accès du réseau de destination. Plusieurs modes de fonctionnement peuvent être distingués :

Envoi individuel : le support est transmis à la source de la demande RTSP, avec le numéro d'accès choisi par le client. Autrement, le support est transmis sur le même flux fiable que RTSP.

Diffusion groupée, le serveur choisissant l'adresse : le serveur de supports sélectionne l'adresse et l'accès de diffusion groupée. C'est le cas normal d'une transmission en direct ou de support presque à la demande.

Diffusion groupé, le client choisissant l'adresse : si le serveur doit participer à une conférence en diffusion groupée existante, l'adresse de diffusion groupe, l'accès et la clé de chiffrement sont données par la description de conférence, établies par des moyens qui sortent du domaine d'application de la présente spécification.

1.7	États de RTSP

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 survenir sur une connexion TCP alors que les données s'écoulent via UDP. Et donc, la livraison des données continue même si aucune demande RTSP n'est reçue par le serveur de supports. Aussi, durant sa durée de vie, un seul flux de supports peut être contrôlé par des demandes RTSP produites séquentiellement sur différentes connexions TCP. Donc, le serveur a besoin d'entretenir "l'état de session" pour être capable de corréler les demandes RTSP avec un flux. Les transitions d'état sont décrites dans l'Appendice A.

De nombreuses méthodes dans RTSP ne contribuent pas à un état. Cependant, celles qui suivent jouent un rôle central dans la définition de l'allocation et l'usage des ressources de flux sur le serveur : SETUP (établissement), PLAY (exécution), RECORD (enregistrement), PAUSE et TEARDOWN (suppression).

SETUP : amène le serveur à allouer des ressources pour un flux et débute une session RTSP.

PLAY et RECORD : débute la transmission des données sur un flux alloué via SETUP.

PAUSE : arrête temporairement un flux sans libérer de 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 (paragraphe 12.37) pour identifier la session RTSP dont l'état a été manipulé. Le serveur génère des identifiants de session en réponse aux demandes SETUP (paragraphe 10.4).

1.8	Relations avec les autres protocoles

RTSP a certains recouvrements de fonctionnalités avec HTTP. Il peut aussi interagir avec HTTP car le contact initial avec le contenu du flux est souvent fait à travers une page de la Toile. La spécification actuelle du protocole vise à permettre différents points de transfert entre un serveur de la Toile et le serveur de supports qui met en œuvre RTSP. Par exemple, la description de présentation peut être restituée en utilisant HTTP ou RTSP, ce qui réduit les allers-retours dans les scénarios fondés sur les navigateurs de la Toile, et permet aussi des serveurs et clients RTSP autonomes qui ne s'appuient pas du tout sur HTTP.

Cependant, RTSP diffère fondamentalement de HTTP en ce que la livraison des données a lieu hors bande dans un protocole différent. HTTP est un protocole asymétrique dans lequel le client produit des demandes et le serveur répond. Dans RTSP, le client et le serveur de supports peuvent tous deux produire des demandes. Les demandes RTSP ne sont pas elles non plus, sans état ; elles peuvent établir des paramètres et continuer à contrôler un flux de supports longtemps après qu'il ait été accusé réception de la demande.

La réutilisation des fonctionnalités de HTTP présente des avantages au moins dans deux domaines, ceux de la sécurité et des mandataires. Les exigences sont très similaires, aussi la capacité d'adopter le travail fait pour HTTP sur les antémémoires, les mandataires et l'authentification est précieuse.

Bien que la plupart des supports de temps réel utilisent RTP comme protocole de transport, RTSP n'est pas lié à RTP.

RTSP suppose l'existence d'un format de description de présentation qui puisse exprimer les propriétés à la fois statiques et temporelles d'une présentation contenant plusieurs flux de supports.

2	Conventions de notation

Comme beaucoup des définitions et de la syntaxe est identique à HTTP/1.1, la présente spécification se contente de citer les paragraphes où elles sont définies plutôt que de les recopier ici. Pour faire court, [Hx.y] doit être compris comme se référant au paragraphe x.y de la spécification HTTP/1.1 actuelle (RFC 2068 [2]).

Tous les mécanismes spécifiés dans le présent document sont décrits à la fois en prose et en format Backus-Naur augmenté (BNF) similaire à celui utilisé dans [H2.1]. Il est décrit en détails dans la RFC 2234 [16], à la différence près que cette spécification de RTSP conserve la notation "1#" pour les listes séparées par des virgules.

Dans le présent mémoire, on utilise des paragraphes en retrait pour expliquer les fondements et les motivations. Ceci est destiné à donner aux lecteurs qui n'étaient pas impliqués dans la rédaction de la spécification la compréhension du pourquoi les choses sont comme elles sont dans RTSP.

3	Paramètres du protocole
3.1	Version RTSP

[H3.1] s'applique, HTTP étant remplacé par RTSP.

3.2	URL RTSP

Les schémas "rtsp" et "rtspu" sont utilisés pour se référer aux ressources réseau via le protocole RTSP. Ce paragraphe définit la syntaxe et la sémantique spécifiques du schéma pour les URL RTSP.

rtsp_URL  	=   ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
host      	=   <Un nom de domaine d'hôte Internet légal d'adresse IP (en forme décimale séparée par des points), comme défini au paragraphe 2.1 de la RFC 1123 \cite{rfc1123}>
port      	=   *DIGIT

abs_path est défini dans [H3.2.1].

Noter que les identifiants de fragment et d'interrogation n'ont pas une signification bien définie pour l'instant, l'interprétation étant laissée au serveur RTSP.

Le schéma rtsp exige que les commandes soient produites via un protocole fiable (au sein de l'Internet, TCP), alors que le schéma rtspu identifie un protocole non fiable (au sein de l'Internet, UDP).

Si l'accès (port) est vide ou non donné, l'accès 554 est supposé. La sémantique est que la ressource identifiée peut être contrôlée par RTSP au serveur qui écoute pour les paquets de connexions TCP (schéma "rtsp") ou UDP (schéma "rtspu") sur cet accès de l'hôte, et l'URI de demande pour la ressource est rtsp_URL.

L'utilisation des adresses IP dans les URL DEVRAIT être évitée chaque fois que possible (voir la RFC 1924 [18]).

Une présentation ou un flux est identifié par un identifiant de support textuel, en utilisant le jeu de caractères et les conventions d'échappement [H3.2] des URL (RFC 1738 [19]). Les URL peuvent se référer à un flux ou à un agrégat de flux, c'est-à-dire, une présentation. En conséquence, les demandes décrites à la Section 10 peuvent s'appliquer soit à toute la présentation soit à un flux individuel au sein de la présentation. Noter que certaines méthodes de demande peuvent seulement s'appliquer aux flux et pas aux présentations et vice versa.

Par exemple, l'URL RTSP :
rtsp://media.example.com:554/twister/audiotrack
identifie le flux audio au sein de la présentation "twister", qui peut être contrôlée via des demandes RTSP produites sur une connexion TCP à l'accès 554 de l'hôte media.example.com.

Aussi, l'URL RTSP :
rtsp://media.example.com:554/twister
identifie la présentation "twister", qui peut être composée de flux audio et vidéo.

Cela n'implique pas une façon standard de référencer les flux dans les URL. La description de présentation définit les relations hiérarchiques dans la présentation et les URL pour les flux individuels. Une description de présentation peut nommer un flux "a.mov" et toute la présentation "b.mov".

Les composants de chemin d'un URL RTSP sont opaques au client et n'impliquent aucune structure particulière de système de fichiers pour le serveur.

Ce découplage permet aussi d'utiliser les descriptions de présentation avec des protocoles de contrôle de support non RTSP en remplaçant simplement le schéma dans l'URL.

3.3	Identifiants de conférence

Les identifiants de conférence sont opaques pour RTSP et sont codés à l'aide des méthodes de codage D'URI standard (c'est-à-dire, les LWS sont esquivées avec %). Ils peuvent contenir toutes les valeurs d'octet. L'identifiant de conférence DOIT être unique au monde. Pour H.323, la valeur conferenceID est à utiliser.

conference-id =   1*xchar

Les identifiants de conférence sont utilisés pour permettre aux sessions RTSP d'obtenir les paramètres des conférences multimédia auxquelles le serveur de supports participe. Ces conférences sont créées par des protocoles qui sortent du domaine d'application de la présente spécification, par exemple, H.323 [13] ou SIP [12]. Au lieu que le client RTSP fournisse explicitement les informations de transport, par exemple, il demande au serveur de supports d'utiliser à la place les valeurs de la description de conférence.

3.4	Identifiants de session

Les identifiants de session sont des chaînes opaques de longueur arbitraire. Le codage des espaces blanches linéaires doit être esquivé dans les URL. Un identifiant de session DOIT être choisi de façon aléatoire et DOIT être long d'au moins huit octets pour le rendre plus difficile à deviner. (Voir la Section 16.)

session-id   =   1*( ALPHA | DIGIT | safe )

3.5	Horodatages relatifs à SMPTE

Un horodatage relatif à SMPTE exprime le temps écoulé depuis le début de la séquence. Les horodatages relatifs sont exprimés comme des codes de temps SMPTE pour la précision d'accès au niveau de la trame. Le code horaire a le format heures:minutes:secondes:trames.sous-trames, avec l'origine au début de la séquence. Le format smpte par défaut est "SMPTE 30 drop", avec un débit de trame de 29,97 trames par seconde. D'autres codes SMPTE PEUVENT être pris en charge (tels que "SMPTE 25") grâce à l'utilisation en remplacement de "smpte time". Pour le champ "trames" dans la valeur de l'heure on peut supposer des valeurs de 0 à 29. La différence entre 30 et 29,97 trames par seconde est traitée en abandonnant les deux premiers indices de trame (valeurs 00 et 01) de chaque minute, excepté toutes les dixièmes minutes. Si la valeur de trame est zéro, elle peut être omise. Les sous trames sont mesurées en centièmes de trame.

smpte-range  =   smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type   =   "smpte" | "smpte-30-drop" | "smpte-25" 	; d'autres codes horaires peuvent être ajoutés
smpte-time   =   1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ]

Exemples :
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01

3.6	Heure d'exécution normale

L'heure d'exécution normale (NPT, Normal Play Time) indique la position absolue du flux par rapport au début de la présentation. L'horodatage consiste en une fraction décimale. La partie gauche de le la décimale peut être exprimée en secondes ou heures, minutes et secondes. La parte droite du point décimal mesure les fractions de seconde.

Le début d'une présentation correspond à 0,0 seconde. Les valeurs négatives ne sont pas définies. La constante spéciale est maintenant définie comme l'instant actuel d'un événement en direct. Elle ne peut être utilisée que pour des événements en direct.

NPT est défini comme dans DSM-CC: "Intuitivement, NPT est l'horloge que le visionneur associe à un programme. Il est souvent affiché numériquement sur un VCR. NPT avance normalement en mode d'exécution normale (échelle = 1), avance à un débit plus rapide lorsqu'il est en défilement rapide vers l'avant (ratio d'échelle positive haute ), diminue en passage inverse (ratio d'échelle négative haute) et est fixe en mode pause. NPT est (logiquement) équivalent aux codes d'heure SMPTE." [5]

npt-range	=   ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
npt-time	=   "now" | npt-sec | npt-hhmmss
npt-sec	=   1*DIGIT [ "." *DIGIT ]
npt-hhmmss	=   npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh	=   1*DIGIT	; tout nombre positif
npt-mm	=   1*2DIGIT	; 0 à 59
npt-ss	=   1*2DIGIT	; 0 à 59

Exemples :
npt=123.45-125
npt=12:05:35.3-
npt=now-

La syntaxe se conforme à ISO 8601. La notation npt-sec est optimisée pour la génération automatique, la notation ntp-hhmmss est pour l'usage du lecteur humain. La constante "now" permet aux clients de demander à recevoir l'alimentation en direct plutôt que la version mémorisée ou en différé. Ceci est nécessaire dans la mesure où ni l'heure absolue ni le temps zéro ne sont appropriés dans ce cas.

3.7	Heure absolue

L'heure absolue est exprimée par des horodatages ISO 8601, en utilisant l'UTC (GMT). Les fractions de seconde peuvent être indiquées.

utc-range	=   "clock" "=" utc-time "-" [ utc-time ]
utc-time	=   utc-date "T" utc-time "Z"
utc-date	=   8DIGIT	; < AAAAMMJJ >
utc-time	=   6DIGIT [ "." fraction ]	; < HHMMSS.fraction >

Exemple pour le 8 novembre 1996 à 14 h 37 et 20 et un quart de seconde UTC : 19961108T143720.25Z

3.8	Étiquettes d'option

Les étiquettes d'option sont des identifiants univoques utilisés pour désigner de nouvelles options dans RTSP. Ces étiquettes sont utilisées dans les champs d'en-tête Require (paragraphe 12.32) et Proxy-Require (paragraphe 12.27).

Syntaxe :

option-tag   	=   1*xchar

Le créateur d'une nouvelle option RTSP devrait soit précéder l'option avec un nom de domaine inversé (par exemple, "com.foo.mynewfeature" est un nom possible pour un dispositif dont l'inventeur peut être joint à "foo.com"), soit enregistrer la nouvelle option auprès de l'Autorité d'allocation des numéros de l'Internet (IANA).

3.8.1	Enregistrement d'étiquettes de nouvelle option auprès de l'IANA
Lors de l'enregistrement d'une nouvelle option RTSP, les informations suivantes devraient être fournies :
*	Nom et description de l'option. Le nom peut avoir une longueur quelconque, mais NE DEVRAIT PAS faire plus de vingt caractères. Le nom NE DOIT PAS contenir d'espaces, de caractères de contrôle ou de points.
*	Indication de qui a la responsabilité des modifications de l'option (par exemple, IETF, ISO, UIT-T, autre organisme de normalisation international, consortium ou société particulière ou groupe de sociétés) ;
*	Une référence à une description plus détaillée, si elle existe, par exemple (dans l'ordre de préférence) une RFC, un article publié, une demande de brevet, un rapport technique, un code source documenté ou un manuel informatique ;
*	Pour les options propriétaires, les informations de contact (adresses postale et électronique);

4	Message RTSP

RTSP est un protocole fondé sur le texte qui utilise le jeu de caractères ISO 10646 codé en UTF-8 (RFC 2279 [20]). Les lignes sont terminées par un CRLF, mais les receveurs devraient être prêts à interpréter d'eux-mêmes les CR et LF comme terminaisons de ligne.

Les protocoles fondés sur le texte rendent plus facile l'ajout de paramètres facultatifs auto descriptifs. Comme le nombre de paramètres et la fréquence des commandes sont faibles, l'efficacité du traitement n'est pas un problème. Les protocoles fondés sur le texte, permettent, si c'est fait avec soin, la mise en œuvre facile de prototypes de recherche en langages écrits tels que Tcl, Visual Basic et Perl.

Le jeu de caractères 10646 évite les changements compliqués de jeu de caractères, mais il est invisible à l'application tant que l'US-ASCII est utilisé. C'est aussi le codage utilisé pour RTCP. ISO 8859-1 traduit directement en Unicode avec un octet de poids fort de zéro. Les caractères de ISO 8859-1 avec le bit de poids fort établi (à 1) sont représenté par 1100001x 10xxxxxx. (Voir la RFC 2279 [20])

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

Les demandes contiennent des méthodes, l'objet sur lequel fonctionne la méthode et les paramètres pour décrire plus avant la méthode. Les méthodes sont idempotentes, sauf notation contraire. Les méthodes sont aussi conçues pour ne demander que peu ou pas de maintenance d'état au serveur de supports.

4.1	Types de message
Voir [H4.1]

4.2	En-têtes de message
Voir [H4.2]

4.3	Corps de message
Voir [H4.3]

4.4	Longueur du message

Lorsque un corps de message est inclus avec un message, la longueur de ce corps est déterminée par (dans l'ordre de préséance) :

1.	Tout message de réponse qui NE DOIT PAS inclure de corps de message (comme les réponses 1xx, 204, et 304) est toujours terminé par la première ligne vide après les champs d'en-tête, sans considération des champs d'en-tête de l'entité présents dans le message. (Note : Une ligne vide comporte seulement un CRLF.)

2.	Si un champ d'en-tête Longueur-de-contenu (paragraphe 12.14) est présent, sa valeur en octets représente la longueur du corps de message. Si ce champ d'en-tête n'est pas présent, on suppose une valeur de zéro.

3.	Par le serveur qui clôture la connexion. (La clôture de la connexion ne peut pas être utilisée pour indiquer la fin d'un corps de demande, car cela ne laisserait aucune possibilité au serveur de renvoyer une réponse.)

Noter que RTSP ne prend pas en charge (à présent) le codage de transfert "tronçonné" de HTTP/1.1 (voir [H3.6]) et exige la présence du champ d'en-tête Longueur-de-contenu.

Étant donnée la longueur modérée des descriptions de présentation retournées, le serveur devrait toujours être capable de déterminer sa longueur, même si il est généré de façon dynamique, rendant le codage de transfert tronqué inutile. Bien que la Longueur-de-contenu doive être présente si il y a un corps d'entité, les règles assurent un comportement raisonnable même si la longueur n'est pas explicitement donnée.

5	Champs d'en-tête généraux

Voir [H4.5], sauf que les en-têtes Pragma, Transfer-Encoding et Upgrade ne sont pas définis :

en-tête-général	=     Cache-Control	; paragraphe 12.8
	|       Connection	; paragraphe 12.10
	|       Date	; paragraphe 12.18
	|       Via	; paragraphe 12.43

6	Demande

Un message de demande provenant d'un client pour un serveur ou vice versa inclut, au sein de la première ligne de ce message, la méthode à appliquer à la ressource, l'identifiant de la ressource, et la version du protocole utilisée.

Demande	=	Ligne-de-demande	; paragraphe 6.1
	*(	en-tête-général	; paragraphe 5
	|	en-tête-de-demande	; paragraphe 6.2
	|	en-tête-d'entité )	; paragraphe 8.1
CRLF
[ corps-de-message ]	; paragraphe 4.3

6.1	Ligne de demande

Ligne-de-demande = Méthode SP URI-de-demande SP Version-RTSP CRLF

Méthode	=	"DESCRIBE"	; paragraphe 10.2
		"ANNOUNCE"	; paragraphe 10.3
	|	"GET_PARAMETER"	; paragraphe 10.8
	|	"OPTIONS"	; paragraphe 10.1
	|	"PAUSE"	; paragraphe 10.6
	|	"PLAY"	; paragraphe 10.5
	|	"RECORD"	; paragraphe 10.11
	|	"REDIRECT"	; paragraphe 10.10
	|	"SETUP"	; paragraphe 10.4
	|	"SET_PARAMETER"	; paragraphe 10.9
	|	"TEARDOWN"	; paragraphe 10.7
	|	extension-method

extension-method = jeton

Request-URI = "*" | absolute_URI

Version-RTSP = "RTSP" "/" 1*DIGIT "." 1*DIGIT

6.2	Champs d'en-tête de demande

en-tête-de-demande	 =	Accept	; paragraphe 12.1
	|	Accept-Encoding	; paragraphe 12.2
	|	Accept-Language	; paragraphe 12.3
	|	Authorization	; paragraphe 12.5
	|	From	; paragraphe 12.20
	|	If-Modified-Since	; paragraphe 12.23
	|	Range	; paragraphe 12.29
	|	Referer	; paragraphe 12.30
	|	User-Agent	; paragraphe 12.41

Noter qu'à la différence de HTTP/1.1 [2], les demandes RTSP contiennent toujours l'URL absolue (c'est-à dire, incluant le schéma, l'hôte et l'accès) plutôt que juste le chemin absolu.

HTTP/1.1 exige que les serveurs comprennent l'URL absolue, mais les clients sont supposés utiliser l'en-tête de demande de l'hôte. Ceci est nécessaire pour la rétrocompatibilité avec les serveurs HTTP/1.0, considération qui ne s'applique pas à RTSP.

L'astérisque "*" dans l'URI-de-demande signifie que la demande ne s'applique pas à une ressource particulière, mais au serveur lui-même, et n'est permise que quand la méthode utilisée ne s'applique pas nécessairement à une ressource. Un exemple serait :

OPTIONS * RTSP/1.0

7	Réponse

[H6] s'applique sauf que HTTP-Version est remplacé par RTSP-Version. Et aussi, RTSP définit des codes d'état supplémentaires et ne définit pas certains codes HTTP. Les codes de réponse valides et les méthodes avec lesquelles ils peuvent être utilisés sont définis au Tableau 1.

Après réception et interprétation d'un message de demande, le receveur répond par un message de réponse RTSP.

Réponse	=   Ligne d'état 	; paragraphe 7.1
	*(  en-tête-général	; paragraphe 5
	en-tête-de-réponse	; paragraphe 7.1.2
	en-tête-d'entité )	; paragraphe 8.1
CRLF
	[ corps-de-message ]	; paragraphe 4.3

7.1	Ligne d'état

La première ligne d'un message Réponse est la Ligne-d'état, qui comporte la version du protocole suivie par un code d'état numérique, et la phrase textuelle associée au code d'état, chaque élément étant séparé par des caractères SP. Aucun CR ni LF n'est admis sauf dans la séquence de CRLF finale.

Ligne-d'état 	=   Version-RTSP SP Code-d'État SP Phrase-de-Cause CRLF

7.1.1	Code d'état et phrase de cause
L'élément Code d'état est un code de résultat entier de trois chiffres de la tentative de comprendre et satisfaire la demande. Ces codes sont définis à la Section 11. La phrase de cause est destinée à donner une courte description textuelle du Code-d'état. Le code d'état est destiné à l'usage des automates et la phrase de cause est destinée à l'utilisateur humain. Le client n'est pas obligé d'examiner ou afficher la phrase de cause.

Le premier chiffre du code d'état définit la classe de réponse. Les deux derniers chiffres ne joue pas de rôle de catégorisation. Il y a cinq valeurs pour le premier chiffre :
*	1xx :	Information - Demande reçue, poursuite du traitement
*	2xx :	Réussite – L'action a été bien reçue, comprise et acceptée
*	3xx :	Redirection – Une autre action doit être entreprise afin d'achever le traitement de la demande
*	4xx :	Erreur client – La demande contient une mauvaise syntaxe ou ne peut être satisfaite
*	5xx :	Erreur du serveur - Le serveur a échoué à satisfaire une demande apparemment valide

Les valeurs individuelles des codes d'état numériques définis pour RTSP/1.0, et un ensemble donné à titre d'exemple des Phrases de cause correspondantes, sont présentées ci-dessous. Les phrases de cause qui figurent dans la liste donnée ici sont simplement recommandées – elles peuvent être remplacées par des équivalents locaux sans affecter le protocole. Noter que RTSP adopte la plupart des codes d'état HTTP/1.1 [2] et ajoute des codes d'état spécifiques de RTSP qui commencent par x50 pour éviter des conflits avec des codes d'état HTTP nouvellement définis.

Code-d'état	=     "100"	; Continuation	
	"200"	; OK	
	"201"	; Créé	
	"250"	; Restrictions d'espace de mémorisation	
	"300"	; Choix multiples	
	"301"	; Déplacement permanent	
	"302"	; Déplacement temporaire	
	"303"	; Voir un autre	
	"304"	; Non modifié	
	"305"	; Utiliser un mandataire	
	"400"	; Mauvaise demande	
	"401"	; Non autorisé	
	"402"	; Payement exigé	
	"403"	; Interdit	
	"404"	; Non trouvé	
	"405"	; Méthode non admise	
	"406"	; Non acceptable	
	"407"	; Authentification du mandataire exigée	
	"408"	; Fin de temporisation de la demande	
	"410"	; Parti	
	"411"	; Longueur exigée	
	"412"	; Échec de précondition	
	"413"	; Entité de demande trop longue	
	"414"	; URI de demande trop longue	
	"415"	; Type de support non pris en charge	
	"451"	; Paramètre non compris	
	"452"	; Conférence non trouvée	
	"453"	; Pas assez de bande passante	
	"454"	; Session non trouvée	
	"455"	; Méthode non valide dans cet état	
	"456"	; Champ d'en-tête non valide pour la ressource	
	"457"	; Gamme invalide	
	"458"	; Paramètre e lecture seule	
	"459"	; Opération agrégée non admise	
	"460"	; Seule une opération agrégée est admise	
	"461"	; Transport non pris en charge	
	"462"	; Destination injoignable	
	"500"	; Erreur interne du serveur	
	"501"	; Non mis en œuvre	
	"502"	; Mauvaise passerelle	
	"503"	; Service indisponible	
	"504"	; Fin de temporisation de passerelle	
	"505"	; Version RTSP non prise en charge	
	"551"	; Option non prise en charge	
code-d'extension

code-d'extension  =     3DIGIT

Phrase-de-cause	=     *<TEXT, à l'exclusion de CR, LF>

Les codes d'état RTSP sont extensibles. Il n'est pas exigé des applications RTSP qu'elles comprennent la signification de tous les codes d'état enregistrés, bien qu'une telle compréhension soit évidemment désirable. Cependant, les applications DOIVENT comprendre la classe de tout code d'état, comme indiqué par le premier chiffre, et traiter toute réponse non reconnue comme étant équivalente au code d'état x00 de cette classe, avec l'exception qu'une réponse non reconnue NE DOIT PAS être placée en antémémoire. Par exemple, si un code d'état non reconnu de 431 est reçu par le client, il peut en toute sécurité supposer qu'il y avait quelque chose qui n'allait pas dans sa demande et traiter la réponse comme si il avait reçu un code d'état de 400. Dans de tels cas, les agents d'utilisateur DEVRAIENT présenter à l'utilisateur l'entité retournée avec la réponse, car cette entité va vraisemblablement comporter des information lisibles par l'homme qui vont expliquer l'état inhabituel.

Code	Cause	Méthode	
100	Continuation	toutes	
200	OK	toutes	
201	Créé	RECORD	
250	Restrictions d'espace de mémorisation	RECORD	
300	Choix multiples	toutes	
301	Déplacement permanent	toutes	
302	Déplacement temporaire	toutes	
303	Voir un autre	toutes	
305	Non modifié	toutes	
400	Utiliser un mandataire	toutes	
401	Mauvaise demande	toutes	
402	Non autorisé	toutes	
403	Payement exigé	toutes	
404	Interdit	toutes	
405	Non trouvé	toutes	
406	Méthode non admise	toutes	
407	Non acceptable	toutes	
408	Authentification du mandataire exigée	toutes	
410	Fin de temporisation de la demande	toutes	
411	Parti	toutes	
412	Longueur exigée	DESCRIBE, SETUP	
413	Échec de précondition	toutes	
414	Entité de demande trop longue	toutes	
415	URI de demande trop longue	toutes	
451	Type de support non pris en charge	SETUP	
452	Paramètre non compris	SETUP	
453	Conférence non trouvée	SETUP	
454	Pas assez de bande passante	toutes	
455	Session non trouvée	toutes	
456	Méthode non valide dans cet état	toutes	
457	Champ d'en-tête non valide pour la ressource	PLAY	
458	Gamme invalide	SET_PARAMETER	
459	Paramètre e lecture seule	toutes	
460	Opération agrégée non admise	toutes	
461	Seule une opération agrégée est admise	toutes	
462	Transport non pris en charge	toutes	
500	Destination injoignable	toutes	
501	Erreur interne du serveur	toutes	
502	Non mis en œuvre	toutes	
503	Mauvaise passerelle	toutes	
504	Service indisponible	toutes	
505	Fin de temporisation de passerelle	toutes	
551	Version RTSP non prise en charge	toutes	

Tableau 1 : Codes d'état et leur usage avec les méthodes RTSP

7.1.2	Champs d'en-tête de réponse
Les champs d'en-tête de réponse permettent au receveur de la demande de passer des informations supplémentaires sur la réponse qui ne tiendraient pas dans la Ligne d'état. Ces champs d'en-tête donnent des informations sur le serveur et sur l'accès ultérieur aux ressources identifiées par l'URI de demande.

en-tête-de-réponse 	 =     Localisation	; paragraphe 12.25
	Proxy-Authenticate	; paragraphe 12.26	Public	; paragraphe 12.28
	Retry-After	; paragraphe 12.31
	Server	; paragraphe 12.36
	Vary	; paragraphe 12.42	WWW-Authenticate	; paragraphe 12.44

Les noms des champs d'en-tête de réponse ne peuvent être étendus de façon fiable qu'en combinaison avec un changement de la version du protocole. Cependant, des champs d'en-tête nouveaux ou expérimentaux PEUVENT recevoir la sémantique des champs d'en-tête de réponse si toutes les parties à la communication les reconnaissent comme étant des champs d'en-tête de réponse. Les champs d'en-tête non reconnus sont traités comme des champs d'en-tête d'entité.

8	Entité

Les messages Demande et Réponse PEUVENT transférer une entité si ils n'en sont pas autrement empêchés par la méthode de demande ou le code d'état de réponse. Une entité consiste en champs d'en-tête d'entité et en un corps d'entité, bien que certaines réponses ne comportent que les en-têtes d'entité.

Dans cette section, l'envoyeur et le receveur se réfèrent tous deux soit au client soit au serveur, selon celui qui envoie et celui qui reçoit l'entité.

8.1	Champs d'en-tête d'entité

Les champs d'en-tête d'entité définissent des méta informations facultatives sur le corps de l'entité, ou si il n'y a pas de corps, sur la ressource identifiée par la demande.

en-tête d'entité 	 =   Allow 	; paragraphe 12.4
	Content-Base	; paragraphe 12.11
	Content-Encoding	; paragraphe 12.12
	Content-Language	; paragraphe 12.13
	Content-Length	; paragraphe 12.14
	Content-Location	; paragraphe 12.15
	Content-Type	; paragraphe 12.16
	Expires	; paragraphe 12.19
	Last-Modified	; paragraphe 12.24
extension-header
	extension-header	=    message-header

Le mécanisme d'extension d'en-tête permet de définir des champs d'en-tête d'entité supplémentaires sans changer le protocole, mais ces champs ne peuvent pas être assurés d'être reconnaissables par le receveur. Les champs d'en-tête non reconnus DEVRAIENT être ignorés par le receveur et transmis par les mandataires.

8.2	Corps d'entité

Voir [H7.2]

9	Connexions

Les demandes RTSP peuvent être transmises de plusieurs façons différentes :
*	par des connexions de transport persistantes utilisées pour plusieurs transactions de demande/réponse ;
*	une connexion par transaction de demande/réponse ;
*	en mode sans connexion.

Le type de connexion de transport est défini par l'URI RTSP (paragraphe 3.2). Pour le schéma "rtsp", on suppose une connexion persistante, alors que le schéma "rtspu" appelle un envoi des demandes RTSP sans l'établissement d'une connexion.

À la différence de HTTP, RTSP permet au serveur de supports d'envoyer des demandes au client du support. Cependant, ceci n'est pris en charge que pour les connexions persistantes, car le serveur de supports n'a pas autrement de façon fiable d'atteindre le client. Aussi, c'est la seule façon dont les demandes du serveur de supports au client puissent traverser les pare-feu.

9.1	Traitement en parallèle

Un client qui prend en charge les connexions persistantes ou le mode sans connexion PEUT "traiter en parallèle" ses demandes (c'est - dire, envoyer plusieurs demandes sans attendre la réponse à chacune). Un serveur DOIT envoyer ses réponses aux demandes dans le même ordre que celui de la réception des demandes.

9.2	Fiabilité et accusé de réception

Le receveur accuse réception des demandes sauf si elles sont envoyées à un groupe de diffusion groupée. Si il n'y a pas d'accusé de réception, l'envoyeur peut renvoyer le même message après une temporisation d'un délai d'aller-retour (RTT, round-trip time). Le délai d'aller-retour est estimé comme dans TCP (RFC 1123) [17], avec une valeur d'aller-retour initiale de 500 ms. Une mise en œuvre PEUT mettre en antémémoire la dernière mesure du RTT comme valeur initiale pour les connexions futures.

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

Si le transport fiable sous-jacent, tel que TCP et l'application RTSP retransmettent tous deux des demandes, il est possible que chaque perte de paquet résulte en deux retransmissions. Le receveur ne peut normalement pas tirer parti de la retransmission de couche application car la pile de transport ne va pas livrer la retransmission de couche application avant que la première tentative ait atteint le receveur. Si la perte de paquet est causée par l'encombrement, plusieurs retransmissions à différentes couches vont exacerber l'encombrement.

Si RTSP est utilisé sur un LAN à faible RTT, les procédures standard d'optimisation des estimations de délai d'aller-retour TCP initial, telles que celles utilisées dans T/TCP (RFC 1644) [22], peuvent être bénéfiques.

L'en-tête Horodatage (paragraphe 12.38) est utilisé pour éviter le problème de l'ambiguïté de la retransmission  [23, p. 301] et éviter d'avoir besoin de l'algorithme de Karn.

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

Les systèmes qui mettent en œuvre RTSP DOIVENT prendre en charge le portage de RTSP sur TCP et PEUVENT prendre en charge UDP. L'accès par défaut pour le serveur RTSP est 554 à la fois pour UDP et TCP.

Un certain nombre de paquets RTSP destinés au même point d'extrémité de contrôle peuvent être empaqueté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. À la différence de HTTP, un message RTSP DOIT contenir un en-tête Longueur de contenu chaque fois que ce message contient une charge utile. Autrement, un paquet RTSP est terminé par une ligne vide immédiatement après le dernier en-tête de message.

10	Définitions de la méthode

Le jeton de méthode indique la méthode à effectuer sur la ressource identifiée par l'URI de demande. La méthode est sensible à la casse. De nouvelles méthodes pourront être définies à l'avenir. Les noms de méthode ne doivent pas commencer par un caractère $ (décimal 24) et doivent être un jeton. Les méthodes sont résumées au Tableau 2.

méthode	direction	objet	exigence	
DESCRIBE	C->S	P,S	recommandé	
ANNOUNCE	C->S, S->C	P,S	facultatif	
GET_PARAMETER	C->S, S->C	P,S	facultatif	
OPTIONS	C->S, S->C	P,S	exigé (S->C: facultatif)	
PAUSE	C->S	P,S	recommandé	
PLAY	C->S	P,S	exigé	
RECORD	C->S	P,S	facultatif	
REDIRECT	S->C	P,S	facultatif	
SETUP	C->S	S	exigé	
SET_PARAMETER	C->S, S->C	P,S	facultatif	
TEARDOWN	C->S	P,S	exigé	

Tableau 2 : Récapitulation des méthodes de RTSP, leur direction, et les objets sur lesquels elles fonctionnent 
(P : présentation, S : flux)

Notes sur le Tableau 2 : PAUSE est recommandé, mais non exigé en ce qu'un serveur pleinement fonctionnel peut être construit qui ne prenne pas en charge cette méthode, par exemple, pour une alimentation en direct. Si un serveur ne prend pas en charge une méthode particulière, il DOIT retourner "501 Non mis en œuvre" et un client NE DEVRAIT PAS essayer cette méthode à nouveau pour ce serveur.

10.1	OPTIONS

Le comportement est équivalent à celui qui est décrit dans [H9.2]. Une demande OPTIONS peut être produite à tout moment, par exemple, si le client va essayer une demande non standard. Elle n'a pas d'influence sur l'état du serveur.

Exemple :

C->S:  OPTIONS * RTSP/1.0
            CSeq: 1
            Require: implicit-play
            Proxy-Require: gzipped-messages

S->C:  RTSP/1.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

Noter que ce sont nécessairement des caractéristiques fictives (on peut espérer que nous n'avons pas délibérément inventé une vraie caractéristique utile juste pour avoir un bon exemple dans ce paragraphe).

10.2	DESCRIBE

La méthode DESCRIBE restitue la description d'une présentation ou d'un objet support identifié par l'URL de demande à partir d'un serveur. Elle peut utiliser l'en-tête Accept pour spécifier le format de description que comprend le client. Le serveur répond par une description de la ressource demandée. La paire de demande-réponse DESCRIBE constitue la phase d'initialisation du support de RTSP.

Exemple :

C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           Accept: application/sdp, application/rtsl, application/mheg

S->C: RTSP/1.0 200 OK
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Content-Type: application/sdp
           Content-Length: 376

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
           s=SDP Seminar
           i=Séminaire sur le protocole de description de session
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31
           m=whiteboard 32416 UDP WB
           a=orient:portrait

La réponse DESCRIBE DOIT contenir toutes les informations d'initialisation du support pour la ou les ressources qu'elle décrit. Si un client de support obtient une description de présentation d'une source autre que DESCRIBE et que la description contient un ensemble complet des paramètres d'initialisation du support, le client DEVRAIT utiliser ces paramètres et non demander alors une description pour le même support via RTSP.

De plus, les serveurs NE DEVRAIENT PAS utiliser la réponse DESCRIBE comme un moyen d'adressage indirect du support.

Des règles de base claires doivent être établies de sorte que les clients aient un moyen sans ambiguïté de savoir quand demander les informations d'initialisation du support via DESCRIBE, et quand ne pas le faire. En forçant une réponse DESCRIBE à contenir toute l'initialisation du support pour l'ensemble des flux qu'il décrit, et en déconseillant l'utilisation de DESCRIBE pour l'adressage indirect du support, nous évitons les problèmes de boucle qui pourraient résulter d'autres approches.

L'initialisation du support est une exigence pour tout système fondé sur RTSP, mais la spécification RTSP n'impose pas que ce soit fait via la méthode DESCRIBE. Il y a trois manières pour un client RTSP de recevoir les informations d'initialisation :
*	via la méthode DESCRIBE de RTSP ;
*	via un autre protocole (HTTP, pièce jointe de messagerie, etc.) ;
*	via la ligne de commande ou une entrée standard (travaillant donc comme une application d'aide à la navigation lancée avec un fichier SDP ou un autre format d'initialisation de support).

Dans l'intérêt de l'interopérabilité pratique, il est vivement recommandé que les serveurs minimaux prennent en charge la méthode DESCRIBE, et il est vivement recommandé que les clients minimaux prennent en charge la capacité d'agir comme une "application d'aide" qui accepte un fichier d'initialisation de support à partir d'une entrée standard, une ligne de commande, et/ou d'autres moyens qui soient appropriés à l'environnement opérationnel du client.

10.3	ANNOUNCE

La méthode ANNOUNCE sert à deux objets :

Lorsque elle est envoyée du client au serveur, ANNOUNCE envoie la description d'une présentation ou d'un objet de support identifié par l'URL de demande à un serveur. Lorsque elle est envoyée de serveur à client, ANNOUNCE met à jour la description de session en temps réel.

Si un nouveau flux de support est ajouté à une présentation (par exemple, durant une présentation en direct), toute la description de présentation devrait être envoyée à nouveau, plutôt que juste les composants additionnels, de sorte que les composants peuvent être supprimés.

Exemple :

C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Session: 47112344
           Content-Type: application/sdp
           Content-Length: 332

           v=0
           o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
           s=Séminaire SDP
           i=Un séminaire sur le protocole de description de session
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31

S->C: RTSP/1.0 200 OK
           CSeq: 312

10.4	SETUP

La demande SETUP pour un URI spécifie le mécanisme de transport à utiliser pour le flux de support. Un client peut produire une demande SETUP pour un flux qui est déjà en cours pour en changer les paramètres de transport, ce qu'un serveur PEUT permettre. Si il ne le permet pas, il DOIT répondre par l'erreur "455 Méthode non valide dans cet état". Pour le bénéfice de tout pare-feu intervenant, un client doit indiquer les paramètres de transport même si il n'a pas d'influence sur ces paramètres, par exemple, lorsque le serveur annonce une adresse de diffusion groupée fixée.

Comme SETUP comporte toutes les informations d'initialisation de transport, les pare-feu et autres appareils intermédiaires du réseau (qui ont besoin de cette information) s'épargnent la tâche la plus ardue d'analyse de la réponse DESCRIBE, qui a été réservée pour l'initialisation du support.

L'en-tête Transport spécifie les paramètres de transport acceptables au client pour la transmission des données ; la réponse va contenir les paramètres de transport choisis par le serveur.

C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
          CSeq: 302
          Transport: RTP/AVP;unicast;client_port=4588-4589

S->C: RTSP/1.0 200 OK
          CSeq: 302
          Date: 23 Jan 1997 15:35:06 GMT
          Session: 47112344
          Transport: RTP/AVP;unicast;client_port=4588-4589;server_port=6256-6257

Le serveur génère les identifiants de session en réponse aux demandes SETUP. Si une demande SETUP à un serveur comporte un identifiant de session, le serveur DOIT grouper cette demande d'établissement avec la session existante ou retourner l'erreur "459 Opération agrégée non admise" (voir au paragraphe 11.3.10).

10.5	PLAY

La méthode PLAY dit au serveur de commencer à envoyer les données via le mécanisme spécifié dans SETUP. Un client NE DOIT PAS produire une demande PLAY avant que les demandes SETUP en cours aient reçu un accusé de réception indiquant la réussite.

La demande PLAY positionne le temps d'exécution normal au début de la gamme spécifiée et délivre les flux de données jusqu'à ce que la fin de la gamme soit atteinte. Les demandes PLAY peuvent être traitées en parallèle (mises en file d'attente) ; un serveur DOIT mettre en file d'attente les demandes PLAY à exécuter dans l'ordre. C'est à dire qu'une demande PLAY qui arrive alors qu'une demande PLAY précédente est toujours active est retardée jusqu'à ce que la première soit achevée.

Cela permet une édition précise.

Par exemple, sans considérer si les deux demandes PLAY de l'exemple ci-dessous arrivent dans un étroit espace de temps, le serveur va d'abord exécuter les secondes 10 à 15, puis immédiatement après, les secondes 20 à 25, et finalement les secondes 30 à la fin.

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=10-15

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 836
           Session: 12345678
           Range: npt=20-25

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 837
           Session: 12345678
           Range: npt=30-

Voir d'autres exemples dans la description de la demande PAUSE.

Une demande PLAY sans en-tête Range (gamme) est légale. Le serveur commence à exécuter un flux depuis le début sauf si le flux a été mis en pause. Si un flux a été mis en pause via PAUSE, la livraison du flux reprend au point de pause. Si un flux est en cours d'exécution, une telle demande PLAY ne cause pas d'autre action et peut être utilisée par le client pour vérifier la vitalité du serveur.

L'en-tête Range peut aussi contenir un paramètre horaire. Ce paramètre spécifie une heure en UTC à laquelle la réexécution devrait commencer. Si le message est reçu après l'heure spécifiée, la réexécution commence immédiatement. Le paramètre d'heure peut être utilisé pour aider à la synchronisation de flux obtenus de différentes sources.

Pour un flux à la demande, le serveur réplique par la gamme réelle qui sera réexécutée. Cela peut différer de la gamme demandée si le verrouillage de la gamme demandée sur les frontières de trames valides est exigé pour la source du support. Si aucune gamme n'est spécifiée dans la demande, la position actuelle est retournée dans la réplique. L'unité de la gamme de la réplique est la même que celle de la demande.

Après l'exécution de la gamme désirée, la présentation est automatiquement mise en pause, comme si une demande PAUSE avait été produite.

L'exemple suivant exécute toute la présentation en commençant au code horaire SMPTE 0:10:20 jusqu'à la fin de la coupure. La réexécution doit commencer à 15 h 36 le 23 janvier 1997.

C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
           CSeq: 833
           Session: 12345678
           Range: smpte=0:10:20-;time=19970123T153600Z

S->C: RTSP/1.0 200 OK
           CSeq: 833
           Date: 23 Jan 1997 15:35:06 GMT
           Range: smpte=0:10:22-;time=19970123T153600Z

Pour réexécuter un enregistrement d'une présentation de direct, il peut être souhaitable d'utiliser des unités d'horloge :

C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: clock=19961108T142300Z-19961108T143520Z

S->C: RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:06 GMT

Un serveur de supports qui n'accepte que la réexécution DOIT prendre en charge le format npt et PEUT prendre en charge les formats clock et smpte.

10.6	PAUSE

La demande PAUSE cause l'interruption temporaire (halte) de la livraison du flux. Si l'URL de demande désigne un flux, seuls la réexécution et l'enregistrement de ce flux sont interrompus. Par exemple, pour l'audio, c'est équivalent à le rendre muet (muting). Si l'URL de demande désigne une présentation ou groupe de flux, la livraison de tous les flux actifs en cours de la présentation ou groupe est interrompue. Après la reprise de l'exécution ou de l'enregistrement, la synchronisation des pistes DOIT être maintenue. Toutes les ressources de serveur sont conservés, bien que les serveurs PUISSENT clore la session et libérer les ressources après la mise en pause pendant une durée spécifiée par le paramètre de temporisation de l'en-tête Session dans le message SETUP.

Exemple :

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 834
           Session: 12345678

S->C: RTSP/1.0 200 OK
           CSeq: 834
           Date: 23 Jan 1997 15:35:06 GMT

La demande PAUSE peut contenir un en-tête Range qui spécifie quand le flux ou la présentation doit être interrompu. On se réfère à ce point par le terme de "point de pause".L'en-tête doit contenir exactement une valeur et non une gamme horaire. L'heure d'exécution normale pour le flux est réglée au point de pause. La demande de pause devient effective la première fois que le serveur rencontre le point horaire spécifié dans une quelconque des demandes PLAY actuellement en cours. Si l'en-tête Range spécifie une heure en dehors des demandes PLAY actuellement en cours, l'erreur "457 Gamme invalide" est retournée. Si une unité de support (telle qu'une trame audio ou vidéo) commence sa présentation exactement au point de pause, elle n'est pas exécutée ou enregistrée. Si l'en-tête Range manque, la livraison du flux est interrompue immédiatement à réception du message et le point de pause est réglé à l'heure d'exécution normale actuelle.

Une demande PAUSE élimine toutes les demandes PLAY mises en file d'attente. Cependant, le point de pause DOIT être maintenu dans le flux de support. Une demande PLAY suivante sans en-tête Range reprend à partir du point de pause.

Par exemple, si le serveur a exécuté les demandes pour les gammes 10 à 15 et 20 à 29 qui étaient en cours et reçoit alors une demande de pause pour NPT 21, il va commencer à exécuter la seconde gamme et s'interrompre à NPT 21. Si la demande de pause est pour NPT 12 et que le serveur exécute NPT 13 dans son accomplissement de la première demande d'exécution, le serveur s'interrompt immédiatement. Si la demande de pause est pour NPT 16, le serveur s'interrompt après l'achèvement de la première demande d'exécution et élimine la seconde demande.

Dans un autre exemple, si un serveur a reçu des demandes d'exécution des gammes 10 à 15 puis 13 à 20 (c'est à dire des gammes qui se chevauchent), la demande PAUSE pour NPT=14 prendrait effet alors que le serveur exécute la première gamme, la seconde demande PLAY étant effectivement ignorée, en supposant que la demande PAUSE arrive avant que le serveur n'ait commencé d'exécuter la seconde gamme, qui chevauche la première. Sans considération du moment où arrive la demande PAUSE, il règle le NPT à 14.

Si le serveur a déjà envoyé les données au delà de l'heure spécifiée dans l'en-tête Range, un PLAY reprendrait quand même à ce point dans le temps, car il est supposé que le client a éliminé les données après ce point. Cela assure un cycle continu de pause/exécution sans trous.

10.7	TEARDOWN

La demande TEARDOWN arrête la livraison du flux pour l'URI donné, libérant les ressources qui lui sont associées. Si l'URI est l'URI de présentation pour cette présentation, aucun identifiant de session RTSP associé à la session n'est plus valide. À moins que tous les paramètres de transport soient définis par la description de session, une demande SETUP doit être produite avant que la session puisse être de nouveau exécutée.
Exemple :
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 892
           Session: 12345678
S->C: RTSP/1.0 200 OK
           CSeq: 892

10.8	GET_PARAMETER

La demande GET_PARAMETER restitue la valeur d'un paramètre d'une présentation ou flux spécifié dans l'URI. Le contenu de la réplique et réponse est laissé à l'initiative de la mise en œuvre. GET_PARAMETER sans corps d'entité peut être utilisé pour vérifier la vitalité du client ou du serveur ("ping").

Exemple :

S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter

C->S: RTSP/1.0 200 OK
           CSeq: 431
           Content-Length: 46
           Content-Type: text/parameters

           packets_received: 10
           jitter: 0.3838

La section "text/parameters" est seulement un exemple type pour un paramètre. Cette méthode est intentionnellement définie de façon vague afin que le contenu de la réplique et le contenu de la réponse soient définis après une expérimentation plus poussée.

10.9	SET_PARAMETER

Cette méthode demande de régler la valeur d'un paramètre pour une présentation ou un flux spécifié par l'URI.

Une demande DEVRAIT seulement contenir un seul paramètre pour permettre au client de déterminer pourquoi une demande particulière a échoué. Si la demande contient plusieurs paramètres, le serveur DOIT seulement agir sur la demande si tous les paramètres peuvent être réglés avec succès. Un serveur DOIT permettre qu'un paramètre soit réglé de façon répétée à la même valeur, mais il PEUT interdire de changer les valeurs des paramètres.

Note : les paramètres de transport pour le flux de support DOIVENT être réglés seulement avec la commande SETUP.

La restriction du réglage des paramètres de transport à SETUP est pour le bénéfice des pare-feu.

Les paramètres sont répartis de façon fine de sorte qu'il puisse y avoir des indications d'erreur plus significatives. Cependant, il peut être raisonnable de permettre le réglage de plusieurs paramètres si un réglage très fin est souhaitable. Imaginons un contrôle d'appareil où le client ne veut pas que la caméra fasse de vues panoramiques sauf si il peut aussi incliner sur l'angle droit en même temps.

Exemple :

C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 421
           Content-length: 20
           Content-type: text/parameters

           barparam: barstuff

S->C: RTSP/1.0 451 Paramètre invalide 

           CSeq: 421
           Content-length: 10
           Content-type: text/parameters

           barparam

La section "text/parameters" est seulement un type d'exemple de paramètre. Cette méthode est intentionnellement définie de façon vague afin que le contenu de la réplique et le contenu de la réponse soient définis après une expérimentation plus poussée.

10.10	REDIRECT

Une demande redirect informe le client qu'il doit se connecter à une autre localisation de serveur. Elle contient l'en-tête obligatoire Location, qui indique que le client devrait produire des demandes pour cette URL. Elle peut contenir le paramètre Range, qui indique quand la redirection prend effet. Si le client veut continuer d'envoyer ou recevoir des supports pour cet URI, le client DOIT produire à l'hôte désigné une demande TEARDOWN pour la session en cours et un SETUP pour la nouvelle session.

Cet exemple de demande redirige le trafic pour cet URI sur le nouveau serveur au moment d'exécution désigné :

S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 732
           Location: rtsp://bigserver.com:8001
           Range: clock=19960213T143205Z-

10.11	RECORD

Cette méthode initie l'enregistrement d'une gamme de données de support conformément à la description de présentation. L'horodatage reflète l'heure de début et de fin (en UTC). Si aucune gamme d'heure n'est donnée, utiliser l'heure de début ou de fin fournie dans la description de présentation. Si le session a déjà commencé, commencer l'enregistrement immédiatement.

Le serveur décide si il va mémoriser les données enregistrées sur l'URI de demande ou sous un autre URI. Si le serveur n'utilise pas l'URI de demande, la réponse DEVRAIT être 201 (Créée) et contenir une entité qui décrit l'état de la demande et se réfère à la nouvelle ressource, et un en-tête Location.

Un serveur de supports qui prend en charge l'enregistrement de présentations en direct DOIT prendre en charge le format de gamme d'horloge ; le format smpte n'a pas de sens.
Dans cet exemple, le serveur de supports était précédemment invité à la conférence indiquée.

C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
           CSeq: 954
           Session: 12345678
           Conference: 128.16.64.19/32492374

10.12	Données binaires incorporées (entrelacées)

Certains concepts de pare-feu et d'autres circonstances peuvent forcer un serveur à entrelacer des méthodes RTSP et des données de flux. Cet entrelaçage devrait généralement être évité sauf si il est nécessaire, parce qu'il complique le fonctionnement de client et de serveur et impose une redondance supplémentaire. Les données binaires entrelacées ne DEVRAIENT être utilisées que si RTSP est porté sur TCP.

Les données de flux telles que les paquets RTP sont encapsulées par un signe ASCII dollar (24 en hexadécimal), suivi par un identifiant de canal d'un octet, suivi par la longueur des données binaires encapsulées comme un entier binaire de deux octets dans l'ordre des octets du réseau. Les données de flux suivent immédiatement après, sans CRLF, mais incluant les en-têtes de protocole de couche supérieure. Chaque bloc $ contient exactement une unité de données de protocole de couche supérieure, par exemple, un paquet RTP.

L'identifiant de canal est défini dans l'en-tête Transport avec le paramètre entrelacé (paragraphe 12.39).

Lorsque le choix du transport est RTP, les messages RTCP sont aussi entrelacés par le serveur sur la connexion TCP. Par défaut, les paquets RTCP sont envoyés sur le premier canal disponible supérieur au canal RTP. Le client PEUT explicitement demander les paquets RTCP sur un autre canal. Cela est fait en spécifiant deux canaux dans le paramètre entrelacé de l'en-tête Transport (paragraphe 12.39).

RTCP est nécessaire à la synchronisation lorsque deux flux ou plus sont entrelacés de cette façon. De plus, cela fournit un moyen pratique pour tunneler les paquets RTP/RTCP à travers la connexion de contrôle TCP lorsque c'est exigé par la configuration du réseau et pour les transférer sur UDP lorsque possible.

C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP/TCP;interleaved=0-1

S->C: RTSP/1.0 200 OK
           CSeq: 2
           Date: 05 Jun 1997 18:57:18 GMT
           Transport: RTP/AVP/TCP;interleaved=0-1
           Session: 12345678

C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
           CSeq: 3
           Session: 12345678

S->C: RTSP/1.0 200 OK
           CSeq: 3
           Session: 12345678
           Date: 05 Jun 1997 18:59:15 GMT
           RTP-Info: url=rtsp://foo.com/bar.file;
             seq=232433;rtptime=972948234

S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

11	Définitions des codes d'état

Lorsque c'est applicable, les codes d'état HTTP [H10] sont réutilisés. Les codes d'état qui ont la même signification ne sont pas répétés ici. Voir au  Tableau 1 la liste des codes d'état qui peuvent être retournés par quelles demandes.

11.1	2xx Réussite
11.1.1	250 Espace de mémorisation faible
Le serveur retourne cet avertissement après avoir reçu une demande RECORD qu'il pourrait n'être pas capable de satisfaire complètement du fait d'un espace de mémorisation insuffisant. Si possible, le serveur devrait utiliser l'en-tête Range pour indiquer pendant combien de temps il pourrait être encore capable d'enregistrer. Comme d'autres processus pourraient simultanément consommer de l'espace mémoire sur le serveur, un client ne devrait prendre cela que comme une estimation.

11.2	3xx Redirection

Voir [H10.3].

Au sein de RTSP, redirection peut être utilisé pour l'équilibrage de charge ou pour rediriger des demandes de flux vers un serveur topologiquement plus proche du client. Les mécanismes pour déterminer la proximité topologique sortent du domaine d'application de la présente spécification.

11.3	4xx Erreur client
11.3.1	405 Méthode non admise
La méthode spécifiée dans la demande n'est pas admise pour la ressource identifiée dans l'URI de demande. La réponse DOIT inclure un en-tête Allow contenant une liste des méthodes valides pour la ressource demandée. Ce code d'état est aussi à utiliser si une demande tente d'utiliser une méthode non indiquée durant SETUP, par exemple, si une demande RECORD est produite bien que le paramètre de mode dans l'en-tête Transport ne spécifie que PLAY.
11.3.2	451 Paramètre non compris
Le receveur de la demande ne prend pas en charge un ou plusieurs paramètres contenus dans la demande.
11.3.3	452 Conférence introuvable
La conférence indiquée par un champ d'en-tête Conference est inconnue du serveur de supports.
11.3.4	453 Pas assez de bande passante
La demande a été refusée à cause d'une bande passante insuffisante. Cela peut, par exemple, être le résultat d'un échec de réservation de ressource.
11.3.5	454 Session introuvable
L'identifiant de session RTSP dans l'en-tête Session manque, est invalide, ou est périmé.
11.3.6	455 Méthode non valide dans cet état
Le client ou le serveur ne peut pas traiter cette demande dans son état actuel. La réponse DEVRAIT contenir un en-tête Allow pour rendre plus facile la récupération d'erreur.
11.3.7	456 Champ d'en-tête non valide pour la ressource
Le serveur n'a pas pu agir sur un en-tête de demande exigé. Par exemple, si PLAY contient le champ d'en-tête Range mais que le flux ne permet pas la recherche.
11.3.8	457 Gamme invalide
La valeur Range donnée est hors limites, par exemple, après la fin de la présentation.
11.3.9	458 Paramètre en Lecture seule
Le paramètre qui doit être réglé par SET_PARAMETER peut être lu mais pas modifié.
11.3.10	459 Opération agrégée non admise
La méthode requise ne peut pas être appliquée sur l'URL en question car c'est un URI agrégé (présentation). La méthode peut être appliquée sur une URL de flux.
11.3.11	460 Opération agrégée seule admise
La méthode requise ne peut pas être appliquée sur l'URL en question car ce n'est pas une URL agrégée (présentation). La méthode peut être appliquée sur l'URL de présentation.
11.3.12	461 Transport non pris en charge
Le champ Transport ne contenait pas une spécification de transport pris en charge.
11.3.13	462 Destination injoignable
Le canal de transmission des données n'a pas pu être établi parce que l'adresse du client n'a pu être jointe. Cette erreur sera très vraisemblablement le résultat d'une tentative d'un client de placer un paramètre Destination invalide dans le champ Transport.
11.3.14	551 Option non prise en charge
Une option données dans les champs Require ou Proxy-Require n'est pas prise en charge. L'en-tête non accepté devrait être retourné en déclarant l'option qui n'est pas prise en charge.

12	Définitions de champ d'en-tête

Les champs d'en-tête HTTP/1.1 [2] ou autres, non standard, qui ne sont pas actuellement sur cette liste n'ont pas de signification bien définie et DEVRAIENT être ignorés par le receveur.

Le Tableau 3 résume les champs d'en-tête utilisés par RTSP. Le type "g" désigne les en-têtes de demande généraux qu'on va trouver à la fois dans les demandes et les réponses, le type "R" désigne les en-têtes de demande, le type "r" désigne les en-têtes de réponse, et le type "e" désigne les champs d'en-têtes d'entité. Les champs marqués "req." dans la colonne marquée "support" DOIVENT être mis en œuvre par le receveur pour une méthode particulière, alors que les champs marqués "opt." sont facultatifs. Noter que tous les champs marqués "req." ne seront pas envoyés dans toutes les demandes de ce type. La mention "req." signifie seulement que le client (pour les en-têtes de réponse) et le serveur (pour les en-têtes de demande) DOIVENT mettre en œuvre les champs. La dernière colonne fait la liste des méthodes pour lesquelles le champ d'en-tête est significatif ; la désignation "entité" se réfère à toutes les méthodes qui retournent un corps de message. Dans la présente spécification, DESCRIBE et GET_PARAMETER entrent dans cette classe.

En-tête	type	support	méthodes	
Accept	R	opt.	entité	
Accept-Encoding	R	opt.	entité	
Accept-Language	R	opt.	toutes	
Allow	r	opt.	toutes	
Authorization	R	opt.	toutes	
Bandwidth	R	opt.	toutes	
Blocksize	R	opt.	toutes sauf OPTIONS, TEARDOWN	
Cache-Control	g	opt.	SETUP	
Conference	R	opt.	SETUP	
Connection	g	req.	toutes	
Content-Base	e	opt.	entity	
Content-Encoding	e	req.	SET_PARAMETER	
Content-Encoding	e	req.	DESCRIBE, ANNOUNCE	
Content-Language	e	req.	DESCRIBE, ANNOUNCE	
Content-Length	e	req.	SET_PARAMETER, ANNOUNCE	
Content-Length	e	req.	entité	
Content-Location	e	opt.	entité	
Content-Type	e	req.	SET_PARAMETER, ANNOUNCE	
Content-Type	r	req.	entité	
CSeq	g	req.	toutes	
Date	g	opt.	toutes	
Expires	e	opt.	DESCRIBE, ANNOUNCE	
From	R	opt.	toutes	
If-Modified-Since	R	opt.	DESCRIBE, SETUP	
Last-Modified	e	opt.	entité	
Proxy-Authenticate				
Proxy-Require	R	req.	toutes	
Public	r	opt.	toutes	
Range	R	opt.	PLAY, PAUSE, RECORD	
Range	r	opt.	PLAY, PAUSE, RECORD	
Referer	R	opt.	toutes	
Require	R	req.	toutes	
Retry-After	r	opt.	toutes	
RTP-Info	r	req.	PLAY	
Scale	Rr	opt.	PLAY, RECORD	
Session	Rr	req.	toutes sauf SETUP, OPTIONS	
Server	r	opt.	toutes	
Speed	Rr	opt.	PLAY	
Transport	Rr	req.	SETUP	
Unsupported	r	req.	toutes	
User-Agent	R	opt.	toutes	
Via	g	opt.	toutes	
WWW-Authenticate	r	opt.	toutes	

Tableau 3 : Récapitulation des champs d'en-tête RTSP

12.1	Accept

Le champ d'en-tête de demande Accept peut être utilisé pour spécifier certains types de contenus de description de présentation qui sont acceptables pour la réponse.

Le paramètre "niveau" pour les descriptions de présentation est défini de façon appropriée au titre de l'enregistrement du type MIME, et ne l'est pas ici.

Voir la syntaxe en [H14.1].

Exemple d'utilisation :
Accept: application/rtsl, application/sdp;level=2

12.2	Codage de Accept

Voir [H14.3]

12.3	Accept-Language

Voir [H14.4]. Noter que le langage spécifié s'applique à la description de présentation et à toutes les phrases de cause, et non au contenu du support.

12.4	Allow

Le champ d'en-tête de réponse Allow fait la liste des méthodes prises en charge par la ressource identifiée par l'URI de demande. L'objet de ce champ est d'informer de façon stricte le receveur des méthodes valides associées à la ressource. Un champ d'en-tête Allow doit être présent dans une réponse 405 (Méthode non admise).

Exemple d'utilisation :

Allow: SETUP, PLAY, RECORD, SET_PARAMETER

12.5	Authorization

Voir [H14.8]

12.6	Bandwidth

Le champ d'en-tête de demande Bandwidth décrit l'estimation de bande passante disponible pour le client, exprimée par un entier positif et mesurée en bits par seconde. La bande passante disponible pour le client peut changer durant une session RTSP, par exemple, du fait d'un recyclage de modem.
Bandwidth = "Bandwidth" ":" 1*DIGIT

Exemple :
     Bandwidth: 4000

12.7	Blocksize

Ce champ d'en-tête de demande est envoyé du client au serveur de supports pour demander au serveur la taille d'un paquet de support particulier. Cette taille de paquet n'inclut pas les en-têtes de couche inférieure tels que IP, UDP, ou RTP. Le serveur est libre d'utiliser une taille de bloc inférieure à celle demandée. Le serveur PEUT tronquer cette taille de paquet au plus proche multiple de la taille de bloc minimum, spécifique du support, ou la remplacer par la taille spécifique du support si nécessaire. La taille de bloc DOIT être un nombre décimal positif, mesuré en octets. Le serveur retourne seulement une erreur (416) si la valeur est syntaxiquement invalide.

12.8	Cache-Control

Le champ d'en-tête général Cache-Control est utilisé pour spécifier des directives qui DOIVENT être respectées par tous les mécanismes de mise en antémémoire le long de la chaîne demande/réponse.

Les directives de mise en antémémoire doivent être passées à travers un mandataire ou application de passerelle, sans considération de leur signification pour l'application, car les directives peuvent être applicables à tous les receveurs le long de la chaîne de demande/réponse. Il n'est pas possible de spécifier une directive d'antémémoire pour une antémémoire spécifique.

Cache-Control ne devrait être spécifié que dans une demande SETUP et sa réponse. Note : Cache-Control ne règle pas la mise en antémémoire des réponses comme pour HTTP, mais plutôt celle du flux identifié par la demande SETUP. Les réponses aux demandes RTSP ne sont pas à mettre en antémémoire, excepté les réponses à DESCRIBE.

Cache-Control	=   "Cache-Control" ":" 1#cache-directive
cache-directive	=   cache-request-directive |   cache-response-directive
cache-request-directive 	=   "no-cache" |   "max-stale" |   "min-fresh" |   "only-if-cached" |   cache-extension
cache-response-directive	=   "public" |  "private" |  "no-cache" |  "no-transform" |  "must-revalidate" |  "proxy-revalidate"
	|   "max-age" "=" delta-seconds |   cache-extension
cache-extension	=   token [ "=" ( token | quoted-string ) ]

no-cache :
Indique que le flux de support NE DOIT PAS être mis en antémémoire, nulle part. Cela permet à un serveur d'origine d'empêcher la mise en antémémoire même lorsque celles-ci ont été configurées pour retourner des réponses périmées aux demandes du client.

public :
Indique que le flux de support peut être mis dans toute antémémoire.

private :
Indique que le flux de support est destiné à un seul utilisateur et NE DOIT PAS être mis dans une antémémoire partagée. Une antémémoire privée (non partagée) peut mémoriser le flux de support.

no-transform :
Une antémémoire intermédiaire (mandataire) peut trouver utile de convertir le type de support de certains flux. Un mandataire peut, par exemple, convertir des formats de vidéo pour économiser l'espace d'antémémoire ou réduire la quantité de trafic sur une liaison lente. Des problèmes de fonctionnement sérieux peuvent cependant survenir lorsque ces transformations ont été appliquées à des flux destinées à certaines sortes d'applications. Par exemple, des applications pour l'imagerie médicale, l'analyse de données scientifiques et celles qui utilisent l'authentification de bout en bout dépendent toutes de la réception d'un flux identique au bit près au corps d'entité d'origine. Donc, si une réponse comporte la directive no-transform, une antémémoire ou mandataire intermédiaire NE DOIT PAS changer le codage du flux. À la différence de HTTP, RTSP ne fournit pas de transformation partielle à ce point, par exemple, pour permettre une traduction dans une langue différente.

only-if-cached :
Dans certains cas, comme ceux d'une très mauvaise connexité réseau, un client peut vouloir qu'une antémémoire ne retourne que les flux de supports qu'elle a mémorisé actuellement, et non recevoir ceux du serveur d'origine. Pour ce faire, le client peut inclure la directive only-if-cached dans une demande. Si elle reçoit cette directive, une antémémoire DEVRAIT soit répondre en utilisant un flux de support mis en antémémoire cohérent avec les autres contraintes de la demande, soit répondre par un état 504 (Fin de temporisation du routeur). Cependant, si un groupe d'antémémoires fonctionne comme un système unifié avec une bonne connexité interne, une telle demande PEUT être transmise au sein de ce groupe d'antémémoires.

max-stale :
Indique que le client est d'accord pour accepter un flux de supports qui a excédé son délai d'expiration. Si une valeur est allouée à max-stale, le client est alors d'accord pour accepter une réponse qui a excédé son délai d'expiration de pas plus que le nombre de secondes spécifié. Si aucune valeur n'est allouée à max-stale, le client est alors d'accord pour accepter une réponse périmée de tout age.

min-fresh :
Indique que le client est d'accord pour accepter un flux de supports dont la fraîcheur de durée de vie n'est pas inférieure à sont age actuel plus la durée spécifiée en secondes. C'est à dire que le client veut une réponse qui sera encore fraîche pendant au moins le nombre de secondes spécifié.

must-revalidate :
Lorsque la directive must-revalidate est présente dans une réponse SETUP reçue par une antémémoire, cette antémémoire NE DOIT PAS utiliser l'entrée après qu'elle soit devenue périmée pour répondre à une demande suivante sans d'abord la revalider auprès du serveur d'origine. C'est à dire que l'antémémoire doit faire à chaque fois une revalidation de bout en bout, si, sur la seule base du champ Expires du serveur d'origine, la réponse en antémémoire est périmée.

12.9	Conference

Ce champ d'en-tête de demande établit une connexion logique entre une conférence préétablie et un flux RTSP. L'identifiant de conférence ne doit pas être changé pour la même session RTSP.

Conference = "Conference" ":" conference-id 

Exemple :
     Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

Un code de réponse de 452 (452 Conférence non trouvée) est retourné si l'identifiant de conférence n'est pas valide.

12.10	Connection

Voir [H14.10]

12.11	Content-Base

Voir [H14.11]

12.12	Content-Encoding

Voir [H14.12]

12.13	Content-Language

Voir [H14.13]

12.14	Content-Length

Ce champ contient la longueur du contenu de la méthode (c'est-à-dire, après le double CRLF qui suit le dernier en-tête). À la différence de HTTP, il DOIT être inclus dans tous les messages qui portent du contenu au delà de la portion d'en-tête du message. Si il manque, une valeur par défaut de zéro est supposée. Il est interprété conformément à [H14.14].

12.15	Content-Location

Voir [H14.15]

12.16	Content-Type

Voir [H14.18]. Noter que les types de contenu convenables pour RTSP seront vraisemblablement restreints en pratique aux types descriptions de présentation et valeur de paramètres.

12.17	CSeq

Le champ CSeq spécifie le numéro de séquence d'une paire demande-réponse RTSP. Ce champ DOIT être présent dans toutes les demandes et les réponses. Pour chaque demande RTSP qui contient le numéro de séquence donné, il y aura une réponse correspondante portant le même numéro. Toute demande retransmise doit contenir le même numéro de séquence que l'original (c'est-à-dire que le numéro de séquence n'est pas incrémenté pour les retransmissions de la même demande).

12.18	Date

Voir [H14.19].

12.19	Expires

Le champ d'en-tête d'entité Expires donne une date et heure après laquelle la description ou flux de supports devrait être considérée comme périmée. L'interprétation dépend de la méthode :

Réponse DESCRIBE :
L'en-tête Expires indique une date et heure après laquelle la description devrait être considérée comme périmée.

Une entrée d'antémémoire périmée ne peut normalement pas être retournée par une antémémoire (soit une antémémoire de mandataire soit une antémémoire d'agent d'utilisateur) sauf si elle est d'abord validée auprès du serveur d'origine (ou auprès d'une antémémoire intermédiaire qui a une copie fraîche de l'entité). Vois à la Section 13 un exposé plus détaillé du modèle d'expiration.

La présence d'un champ Expires n'implique pas que la ressource d'origine va changer ou cesser d'exister à ce moment, avant, ou après.

Le format est une date et heure absolue comme défini par HTTP-date dans [H3.3] ; il DOIT être dans le format de date de la RFC1123 :

Expires = "Expires" ":" HTTP-date

Un exemple de son utilisation est

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Les clients et antémémoires RTSP/1.0 DOIVENT traiter les autres formats de date invalides, en particulier ceux qui comportent la valeur "0", comme étant survenus dans le passé (c'est-à-dire, "déjà expiré").

Pour marquer une réponse comme "déjà expirée," un serveur d'origine devrait utiliser une date Expires égale à la valeur de l'en-tête Date. Pour marquer une réponse comme "n'expire jamais," un serveur d'origine devrait utiliser une date Expires d'approximativement un an à partir de l'heure où la réponse est envoyée. Les serveurs RTSP/1.0 ne devraient pas envoyer de dates Expires de plus d'un an dans le futur.

La présence d'un champ d'en-tête Expires avec une valeur de date dans le futur sur un flux de supports qui autrement serait par défaut non mettable en antémémoire indique que le flux de supports est mettable en antémémoire, sauf indication contraire par un champ d'en-tête Cache-Control (paragraphe 12.8).

12.20	From

Voir [H14.22].

12.21	Host

Ce champ d'en-tête de demande HTTP n'est pas nécessaire pour RTSP. Il devrait être ignoré en silence s'il est envoyé.

12.22	If-Match

Voir [H14.25].

Ce champ est particulièrement utile pour s'assurer de l'intégrité de la description de présentation, à la fois dans le cas où on va la chercher via des moyens externes à RTSP (tels que HTTP), et dans le cas où la mise en œuvre de serveur garantit l'intégrité de la description entre le moment du message DESCRIBE et celui du message SETUP.

L'identifiant est opaque, et n'est donc pas spécifique d'un langage de description de session particulier.

12.23	If-Modified-Since

Le champ d'en-tête de demande If-Modified-Since est utilisé avec les méthodes DESCRIBE et SETUP pour les rendre conditionnelles. Si la variante demandée n'a pas été modifiée depuis l'heure spécifiée dans ce champ, une description ne sera pas retournée du serveur (DESCRIBE) ou un flux ne sera pas établi (SETUP). Au lieu de cela, une réponse 304 (non modifié) sera retournée sans aucun corps de message.

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Un exemple de ce champ est : If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

12.24	Last-Modified

Le champ d'en-tête d'entité Last-Modified indique la date et l'heure à laquelle le serveur d'origine estime que la description de présentation ou le flux de supports a été modifié pour la dernière fois. Voir [H14.29]. Pour les méthodes DESCRIBE ou ANNOUNCE, le champ d'en-tête indique la date et l'heure de la dernière modification de la description, pour SETUP celle de la dernière modification du flux de supports.

12.25	Location

Voir [H14.30].

12.26	Proxy-Authenticate

Voir [H14.33].

12.27	Proxy-Require

L'en-tête Proxy-Require est utilisé pour indiquer des caractéristiques en rapport avec le mandataire qui DOIVENT être prises en charge par le mandataire. Toute caractéristique d'en-tête Proxy-Require qui n'est pas prise en charge par le mandataire DOIT recevoir un accusé de réception négatif de la part du mandataire au client. Les serveurs devraient traiter ce champ de façon identique à celle du champ Require.

Voir au paragraphe 12.32 des précisions sur les mécanismes de ce message et un exemple d'utilisation.

12.28	Public

Voir [H14.35].
12.29	Range

Ce champ d'en-tête de demande et de réponse spécifie une gamme horaire. La gamme peut être spécifiée en nombre d'unités. La présente spécification définit les unités de gamme smpte (paragraphe 3.5), npt (paragraphe 3.6), et clock (paragraphe 3.7). Au sein de RTSP, les gammes d'octets [H14.36.1] ne sont pas significatives et NE DOIVENT PAS être utilisées. L'en-tête peut aussi contenir un paramètre d'heure en UTC, qui spécifie l'heure à laquelle l'opération est à effectuer. Les serveurs qui prennent en charge l'en-tête Range DOIVENT comprendre le format de gamme NPT et DEVRAIENT comprendre le format de gamme SMPTE. L'en-tête de réponse Range indique quelle gamme horaire est en fait exécutée ou enregistrée. Si l'en-tête Range est donné dans un format horaire qui n'est pas compris, le receveur devrait retourner "501 Non mis en œuvre".

Les gammes sont des intervalles semi ouverts, comportant le point inférieur, mais excluant le point supérieur. En d'autres termes, une gamme de a-b commence exactement à l'heure a, mais s'arrête juste avant b. Seule l'heure de début d'une unité de support telle qu'une trame vidéo ou audio est pertinente. Par exemple, supposons que des trames vidéo sont générées toutes les 40 ms. Une gamme de 10.0-10.1 inclurait une trame vidéo commençant à 10.0 ou plus tard et inclurait une trame vidéo commençant à 10.08, même si elle dure au delà de l'intervalle. D'un autre côté, une gamme de 10.0-10.08 exclurait la trame à 10.08.

Range            = "Range" ":" 1\#ranges-specifier [ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range

Exemple :  Range: clock=19960213T143205Z-;time=19970123T143720Z

La notation est similaire à celle utilisée pour l'en-tête byte-range de HTTP/1.1 [2]. Elle permet aux clients de choisir un extrait de l'objet support à exécuter d'un point donné jusqu'à la fin aussi bien que de la localisation actuelle jusqu'à un point donnée. Le début de la réexécution peut être programmé à partir de tout point futur, bien qu'un serveur puisse refuser de conserver les ressources de serveur pendant de longues périodes d'inactivité.

12.30	Referer

Voir [H14.37]. L'URL se réfère à celle de la description de présentation, normalement restituée via HTTP.

12.31	Retry-After

Voir [H14.38].

12.32	Require

L'en-tête Require est utilisé par les clients pour interroger le serveur sur les options qu'il peut ou non accepter. Le serveur DOIT répondre à cet en-tête en utilisant l'en-tête Non-accepté pour accuser réception négativement des options qui NE SONT PAS prises en charge.

Ceci est destiné à s'assurer que l'interaction client-serveur va se dérouler sans retard lorsque toutes les options sont comprises par les deux côtés, et seulement alentie si les options ne sont pas comprises (comme dans le cas ci-dessus). Pour une paire client-serveur bien assortie, l'interaction se déroule rapidement, économisant un aller-retour souvent exigé par le mécanisme de négociation. De plus, elle supprime aussi l'ambiguïté sur l'état lorsque le client exige des caractéristiques que le serveur ne comprend pas.

Require =   "Require" ":"  1#option-tag

Exemple :
C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 302
             Require: caractéristique-fantaisiste
             Paramètre-fantaisiste: funkystuff

S->C:   RTSP/1.0 551 Option non accepté
             CSeq: 302
             Non accepté : caractéristique-fantaisiste

C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 303

S->C:   RTSP/1.0 200 OK
             CSeq: 303

Dans cet exemple, "caractéristique-fantaisiste" est l'étiquette de caractéristique qui indique au client que le champ fictif Paramètre-fantaisiste est exigé. La relation entre "caractéristique-fantaisiste" et Paramètre-fantaisiste n'est pas communiquée via l'échange RTSP, car cette relation est une propriété immuable de "caractéristique-fantaisiste" et n'a donc pas besoin d'être transmise avec chaque échange.

Les mandataires et autres appareils intermédiaires DEVRAIENT ignorer les caractéristiques qui dans ce champ ne sont pas comprises. Si une extension particulière exige que les appareils intermédiaires la prennent en charge, l'extension devrait plutôt être étiquetée dans le champ Proxy-Require (voir au paragraphe 12.27).

12.33	RTP-Info

Ce champ est utilisé pour établir les paramètres spécifiques de RTP dans la réponse PLAY.

url :  Indique l'URL du flux auquel correspondent les paramètres RTP suivants.

seq : Indique le numéro de séquence du premier paquet du flux. Cela permet aux clients de traiter en douceur les paquets lors d'une recherche. Le client utilise cette valeur pour différencier les paquets qui ont été générés avant la recherche des paquets qui ont été générés après.

rtptime : Indique l'horodatage RTP qui correspond à la valeur de l'heure dans l'en-tête de réponse Range. (Note : Pour un contrôle agrégé, un flux particulier peut en réalité ne pas générer un paquet pour la valeur d'heure Range retournée ou impliquée. Et donc, il n'y à aucune garantie que le paquet ayant le numéro de séquence indiqué par seq ait réellement l'horodatage indiqué par rtptime.) Le client utilise cette valeur pour calculer la transposition de l'heure RTP en NPT.

Une transposition des horodatages RTP en horodatages NTP (horloge murale) est disponible via RTCP. Cependant, ces informations ne sont pas suffisantes pour générer une transposition des horodatages RTP en NPT. De plus, afin de s'assurer que ces informations sont disponibles au moment nécessaire (immédiatement au démarrage ou après une recherche), et qu'elles bénéficient d'une livraison fiable, cette transposition est placée dans le canal de contrôle RTSP.

Afin de compenser la dérive pour les longues présentations ininterrompues, les clients RTSP devraient de plus transposer de NPT en NTP, en utilisant les rapports d'envoi RTCP initiaux pour faire la transposition et les rapports ultérieurs pour vérifier la dérive par rapport à la transposition.

Syntaxe :
RTP-Info        = "RTP-Info" ":" 1#stream-url 1*parameter
stream-url       = "url" "=" url
parameter        = ";" "seq" "=" 1*DIGIT
                    | ";" "rtptime" "=" 1*DIGIT

Exemple :

RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
               url=rtsp://foo.com/bar.avi/streamid=1;seq=30211

12.34	Scale

Une valeur scale de 1 indique une exécution ou enregistrement normal à la vitesse de transmission de visualisation normale. Si elle est différente de 1, la valeur correspond à la vitesse par rapport à la vitesse de visualisation normale. Par exemple, un ratio de 2 indique deux fois la vitesse de visualisation normale ("avance rapide") et un ratio de 0,5 indique la moitié de la vitesse de visualisation normale. En d'autres termes, un ratio de 2 par rapport au temps d'exécution normal va deux fois plus vite que la vitesse de l'horloge murale. Pour chaque seconde écoulée (à l'horloge murale), 2 secondes de contenu seront délivrées. Une valeur négative indique la direction inverse.

Sauf s'il en est exigé autrement par le paramètre scale, le débit des données NE DEVRAIT PAS être changé. La mise en œuvre des changements de scale dépend du serveur et du type de support. Pour la vidéo, un serveur peut, par exemple, ne livrer que les trames clés ou des trames clés choisies. Pour l'audio, il peut faire un échelonnement temporel de l'audio tout en préservant la tonalité, ou, moins souhaitable, délivrer des fragments audio.

Le serveur devrait essayer d'approximer la vitesse de visualisation, mais peut restreindre la gamme des valeurs de scale qu'il accepte. La réponse DOIT contenir les valeurs réelles de scale choisies par le serveur.

Si la demande contient un paramètre Range, la nouvelle valeur de scale prendra effet à ce moment.

Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]

Exemple d'exécution en arrière à 3,5 fois la vitesse normale :  Scale: -3.5

12.35	Speed

Ce paramètre de champs d'en-tête de demande demande au serveur de livrer les données au client à une vitesse particulière, en fonction de la capacité du serveur et du désir de traiter le flux de supports à la vitesse donnée. La mise en œuvre par le serveur est FACULTATIVE. La valeur par défaut est le débit binaire du flux.

La valeur du paramètre est exprimée par un ratio décimal, par exemple, une valeur de 2,0 indique que les données sont à délivrer à deux fois la vitesse normale. Une vitesse de zéro est invalide. Si la demande contient un paramètre Range, la nouvelle vitesse prendra effet à ce moment.

Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]

Exemple : Speed: 2.5

L'utilisation de ce champ change la bande passante utilisée pour la livraison des données. Il est destiné à être utilisé dans des circonstances spécifiques où la vision anticipée de la présentation à une vitesse supérieure ou inférieure est nécessaire. Les développeurs devraient se souvenir que la bande passante de la session peut être négociée à l'avance (par des moyens autres que RTSP), et que donc la renégociation peut être nécessaire. Lorsque les données sont livrées sur UDP, il est fortement recommandé que soient utilisés des moyens tels que RTCP pour garder la trace des taux de perte de paquet.

12.36	Server

Voir [H14.39]

12.37	Session

Ce champ d'en-tête de demande et de réponse identifie une session RTSP commencée par le serveur de supports dans une réponse SETUP et terminée par TEARDOWN sur l'URL de présentation. L'identifiant de session est choisi par le serveur de supports (voir au paragraphe 3.4). Une fois qu'un client reçoit un identifiant Session, il DOIT le retourner pour toute demande en relation avec cette session. Un serveur n'a pas à établir un identifiant de session si il a d'autres moyens pour identifier une session, comme des URL générés de façon dynamique.

Session  = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]

Le paramètre timeout n'est admis que dans un en-tête de réponse. Le serveur l'utilise pour indiquer au client pendant combien de temps le serveur est prêt à attendre entre les commandes RTSP avant de clore la session du fait d'un manque d'activité (voir au paragraphe A). La temporisation est mesurée en secondes, avec une valeur par défaut de 60 secondes (1 minute).

Noter qu'un identifiant de session identifie une session RTSP à travers des sessions de transport ou des connexions. Des messages de contrôle pour plus d'un URL RTSP peuvent être envoyés au sein d'une seule session RTSP. Et donc, il est possible que des clients utilisent la même session pour contrôler de nombreux flux constituant une présentation, tant que tous les flux proviennent du même serveur. (Voir les exemples à la section 14). Cependant, plusieurs session "d'utilisateur" pour la même URL provenant du même client DOIVENT utiliser des identifiants de session différents.

L'identifiant de session est nécessaire pour distinguer plusieurs demandes de livraison pour la même URL provenant du même client.

La réponse 454 (Session non trouvée) est retournée si l'identifiant de session est invalide.

12.38	Timestamp

L'en-tête général timestamp décrit le moment où le client envoie la demande au serveur. La valeur de l'horodatage n'a de signification que pour le client et elle peut utiliser une échelle de temps quelconque. Le serveur DOIT faire écho avec exactement la même valeur et PEUT, si il a des informations précises à ce sujet, ajouter un nombre en virgule flottante qui indique le nombre de secondes qui se sont écoulées depuis qu'il a reçu la demande. L'horodatage est utilisé par le client pour calculer le temps d'aller-retour jusqu'au serveur afin qu'il puisse ajuster la valeur de temporisation pour les retransmissions.

Timestamp  = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay      =  *(DIGIT) [ "." *(DIGIT) ]

12.39	Transport

Cet en-tête de demande indique le protocole de transport à utiliser et configure ses paramètres tels que adresse de destination, compression, durée de vie de diffusion groupé et accès de destination pour un seul flux. Il règle les valeurs qui ne sont pas déjà déterminées par une description de présentation.

Les transports sont séparés par des virgules, et énumérés dans l'ordre de préférence. Des paramètres peuvent être ajoutés à chaque transport, séparés par le caractère deux-points.

L'en-tête Transport PEUT aussi être utilisé pour changer certains paramètres de transport. Un serveur PEUT refuser de changer les paramètres d'un flux existant.

Le serveur PEUT retourner un en-tête de réponse Transport dans la réponse pour indique les valeurs réellement choisies.

Un champ d'en-tête de demande Transport peut contenir une liste des options de transport acceptables pour le client. Dans ce cas, le serveur DOIT retourner une seule option qui a été réellement choisie.

La syntaxe de la spécification de transport est 

transport/profile/lower-transport.

La valeur par défaut pour les paramètres "lower-transport" est spécifique du profil. Pour RTP/AVP, le défaut est UDP.

Ci-dessous figurent les paramètres de configuration associés au transport :

- Paramètres généraux :

unicast | multicast (diffusion | diffusion groupée) :
Indication mutuellement exclusive de ce que la livraison en diffusion ou en diffusion groupée sera tentée. La valeur par défaut est la diffusion groupée. Les clients qui sont capables de traiter aussi bien la transmission en diffusion que celle en diffusion groupée DOIVENT indiquer cette capacité en incluant les deux spécifications de transport complètes avec des paramètres séparés pour chacune d'elles.

destination :
C'est l'adresse à laquelle sera envoyé un flux. Le client peut spécifier l'adresse de diffusion groupée avec le paramètre de destination. Pour éviter de devenir le complice involontaire d'une attaque de déni de service contrôlée à distance, un serveur DEVRAIT authentifier le client et DEVRAIT consigner de telles tentatives avant de permettre au client de diriger un flux de support sur une adresse non choisie par le serveur. Ceci est particulièrement important si les commandes RTSP sont produites via UDP, mais les mises en œuvre ne peuvent pas se reposer sur TCP seul comme moyen fiable d'identification du client. Un serveur NE DEVRAIT PAS permettre à un client de diriger les flux de support sur une adresse qui diffère de l'adresse dont proviennent les commandes.

source :
Si l'adresse de source pour le flux est différente de celle qui peut être déduite de l'adresse de point d'extrémité RTSP (le serveur en lecture ou le client en enregistrement), la source PEUT être spécifiée. Cette information peut aussi être disponible par SDP. Cependant, comme c'est plus une caractéristique de transport que d'initialisation du support, la source d'autorité pour cette information devrait être dans la réponse à SETUP.

layers :
C'est le nombre de couches de diffusion groupée à utiliser pour ce flux de supports. Les couches sont envoyées aux adresses consécutives en commençant à l'adresse de destination.

mode :
Le paramètre mode indique les méthodes à prendre en charge pour cette session. Les valeurs valides sont PLAY et RECORD. Si il n'est pas fourni, la valeur par défaut est PLAY.

append :
Si le paramètre mode comporte RECORD, le paramètre append indique que les données de support doivent être ajoutées à la ressource existante plutôt que de s'y substituer. Si l'ajout est demandé et si le serveur ne l'accepte pas, il DOIT refuser la demande plutôt que réécrire la ressource identifiée par l'URI. Le paramètre append est ignoré si le paramètre mode ne contient pas RECORD.

interleaved :
Le paramètre interleaved implique de mixer le flux de support avec le flux de contrôle dans le protocole utilisé quel qu'il soit par le flux de contrôle, en utilisant le mécanisme défini au paragraphe 10.12. L'argument donne le numéro de canal à utiliser dans la déclaration $. Ce paramètre peut être spécifié dans une gamme, par exemple, interleaved=4-5 dans les cas où le choix du transport pour le flux de support l'exige.

Cela permet à RTP/RTCP d'être traité de façon similaire à celle utilisée avec UDP, c'est-à-dire, un canal pour RTP et l'autre pour RTCP.

- Paramètres spécifiques de la diffusion groupée :

ttl:
durée de vie de la diffusion groupée

- Paramètres spécifiques de RTP :

port :
Ce paramètre fournit la paire d'accès RTP/RTCP pour une session en diffusion groupée. Il est spécifié comme une gamme, par exemple, port=3456-3457.

client_port:
Ce paramètre fournit la paire d'accès RTP/RTCP en envoi individuel sur laquelle le client a choisi de recevoir les données du support et les informations de contrôle. Il est spécifié comme une gamme, par exemple, client_port=3456-3457.

server_port:
Ce paramètre fournit la paire d'accès RTP/RTCP en envoi individuel sur laquelle le serveur a choisi de recevoir les données du support et les informations de contrôle. Il est spécifié comme une gamme, par exemple, server_port=3456-3457.

ssrc:
Le paramètre ssrc indique la valeur SSRC [24, Sec. 3] de RTP qui devrait être (demande) ou sera (réponse) utilisée par le serveur de supports. Ce paramètre n'est valide que pour la transmission en envoi individuel. Il identifie la source de synchronisation à associer au flux de supports.

Transport           =    "Transport" ":" 1\#transport-spec
transport-spec      =    transport-protocol/profile[/lower-transport] *parameter
transport-protocol  =    "RTP"
profile             =    "AVP"
lower-transport     =    "TCP" | "UDP"
parameter           =    ( "unicast" | "multicast" )
                       |    ";" "destination" [ "=" address ]
                       |    ";" "interleaved" "=" channel [ "-" channel ]
                       |    ";" "append"
                       |    ";" "ttl" "=" ttl
                       |    ";" "layers" "=" 1*DIGIT
                       |    ";" "port" "=" port [ "-" port ]
                       |    ";" "client_port" "=" port [ "-" port ]
                       |    ";" "server_port" "=" port [ "-" port ]
                       |    ";" "ssrc" "=" ssrc
                       |    ";" "mode" = <"> 1\#mode <">
ttl                 =    1*3(DIGIT)
port                =    1*5(DIGIT)
ssrc                =    8*8(HEX)
channel             =    1*3(DIGIT)
address             =    host
mode                =    <"> *Method <"> | Method

Exemple :
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
                RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

L'en-tête Transport se restreint à la description d'un seul flux RTP. (RTSP peut aussi contrôler plusieurs flux comme une seule entité.) L'intégrer au titre de RTSP plutôt que de s'appuyer sur une multitude de formats de description de session simplifie grandement la conception des pare-feu.

12.40	Unsupported

L'en-tête de réponse Unsupported (Non pris en charge) fait la liste des caractéristiques qui ne sont pas prises en charge par le serveur. Au cas où la caractéristique a été spécifiée via le champ Proxy-Require (paragraphe 12.32), si il y a un mandataire sur le chemin entre le client et le serveur, le mandataire DOIT insérer une réplique du message avec un message d'erreur "551 Option Non acceptée".

Voir au paragraphe 12.32 un exemple d'utilisation.

12.41	User-Agent
Voir [H14.42]

12.42	Vary
Voir [H14.43]

12.43	Via
Voir [H14.44].

12.44	WWW-Authentica
Voir [H14.46].

13	Mise en antémémoire

Dans HTTP, les paires réponse-demande sont mises en antémémoire. RTSP en diffère de façon significative à cet égard. Les réponses ne sont pas mettables en antémémoire, à l'exception de la description de présentation retournée par DESCRIBE ou incluse avec ANNOUNCE. (Comme les réponses pour tout sauf DESCRIBE et GET_PARAMETER ne retournent aucune donnée, les mettre en antémémoire n'est pas un problème pour ces demandes.) Cependant, il est souhaitable pour les données de supports en continu, normalement livrées hors bande par rapport à RTSP, d'être mises en antémémoire, tout comme la description de session.

À réception d'une demande SETUP ou PLAY, un mandataire s'assure s'il s'agit d'une copie à jour du contenu de support en continu et de sa description. Il peut déterminer si la copie est à jour en produisant respectivement une demande SETUP ou DESCRIBE, et en comparant l'en-tête Last-Modified avec celui de la copie en antémémoire. Si la copie n'est pas à jour, il modifie les paramètres de transport de SETUP comme approprié et transmet la demande au serveur d'origine. Les commandes de contrôle suivantes, telles que PLAY ou PAUSE passent alors le mandataire sans modification. Le mandataire délivre les données de support continues au client, en en faisant éventuellement une copie locale pour une réutilisation ultérieure. Le comportement exact permis à l'antémémoire est donné par les directives de réponse d'antémémoire décrites au paragraphe 12.8. Une antémémoire DOIT répondre à toutes les demandes DESCRIBE si elle dessert actuellement le flux pour le demandeur, car il est possible que des détails de niveau inférieur de la description du flux aient changé sur le serveur d'origine.

Noter qu'une antémémoire RTSP, à la différence de celle de HTTP, est de la variété "raccourci". Plutôt que de restituer toute la ressource du serveur d'origine, l'antémémoire copie simplement les données du flux lors de leur passage vers le client. Et donc cela n'introduit pas de latence supplémentaire.

Pour le client, une antémémoire de mandataire RTSP apparaît comme un serveur de supports régulier, et pour le serveur d'origine du support, comme un client. Juste comme une antémémoire HTTP doit mémoriser le type de contenu, le langage du contenu, et ainsi de suite pour les objets qu'elle met en mémoire, une antémémoire de supports doit mémoriser la description de présentation. Normalement, une antémémoire élimine toutes les références de transport (c'est-à-dire, les informations de diffusion groupée) de la description de présentation, car elles sont indépendantes de la livraison des données de l'antémémoire au client. Les informations sur les codages restent les mêmes. Si l'antémémoire est capable de traduire les données de support mémorisées, elle va créer une nouvelle description de présentation avec toutes les possibilités de codage qu'elle peut offrir.

14	Exemples

Les exemples suivants se réfèrent aux formats de description de flux qui ne sont pas standard, tels que RTSL. Ces exemples ne sont pas à utiliser comme référence pour ces formats.

14.1	Support à la demande (en envoi individuel)

Le client C demande un film aux serveurs de supports A (audio.example.com) et V (video.example.com). La description du support est mémorisée sur un serveur de la Toile W. La description du support contient des descriptions de la présentation et tous ses flux, y compris les codecs qui sont disponibles, les types de charge utile RTP dynamiques, la pile de protocole, et des informations de contenu telles que le langage ou les restrictions de copyright. Elle peut aussi donner une indication sur la durée du film.

Dans cet exemple, le client n'est intéressé que par la dernière partie du film.

C->W: GET /twister.sdp HTTP/1.1
           Host: www.example.com
           Accept: application/sdp

W->C: HTTP/1.0 200 OK
           Content-Type: application/sdp
           v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           m=audio 0 RTP/AVP 0
           a=control:rtsp://audio.example.com/twister/audio.en
           m=video 0 RTP/AVP 31
           a=control:rtsp://video.example.com/twister/video

C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 1
           Transport: RTP/AVP/UDP;unicast;client_port=3056-3057

A->C: RTSP/1.0 200 OK
           CSeq: 1
           Session: 12345678
           Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;server_port=5000-5001

C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 1
           Transport: RTP/AVP/UDP;unicast;client_port=3058-3059

V->C: RTSP/1.0 200 OK
           CSeq: 1
           Session: 23456789
           Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;server_port=5002-5003

C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 2
           Session: 23456789
           Range: smpte=0:10:00-

V->C: RTSP/1.0 200 OK
           CSeq: 2
           Session: 23456789
           Range: smpte=0:10:00-0:20:00
           RTP-Info: url=rtsp://video.example.com/twister/video;seq=12312232;rtptime=78712811

C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 2
           Session: 12345678
           Range: smpte=0:10:00-

A->C: RTSP/1.0 200 OK
           CSeq: 2
           Session: 12345678
           Range: smpte=0:10:00-0:20:00
           RTP-Info: url=rtsp://audio.example.com/twister/audio.en;seq=876655;rtptime=1032181

C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 3
           Session: 12345678

A->C: RTSP/1.0 200 OK
           CSeq: 3

C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 3
           Session: 23456789

V->C: RTSP/1.0 200 OK
           CSeq: 3

Bien que les pistes audio et vidéo soient sur deux serveurs différents, et puissent commencer à des instants légèrement différents et dériver l'une par rapport à l'autre, le client peut synchroniser les deux en utilisant les méthodes RTP standard, en particulier l'échelle des temps contenue dans les rapports d'envoi de RTCP.

14.2	Défilement d'un fichier conteneur

Pour les besoins de cet exemple, un fichier conteneur est une entité de stockage dans laquelle plusieurs types de supports en continu appartenant à la même présentation d'utilisateur final sont présentes. En fait, le fichier conteneur représente une présentation RTSP, chacun de ses composants étant des flux RTSP. Les fichiers conteneurs sont un moyen largement utilisé pour mémoriser de telles présentations. Bien que les composants soient transportés comme des flux indépendants, il est souhaitable de maintenir un contexte commun pour ces flux à l'extrémité serveur.

Cela permet au serveur de garder facilement une seule bretelle de stockage. Cela permet aussi de traiter également tous les flux dans le cas d'une attribution de priorité aux flux par le serveur.

Il est aussi possible que l'auteur de la présentation souhaite empêcher une restitution sélective des flux par le client afin de préserver l'effet artistique de la présentation combinée des supports. De même, dans une présentation enfermée dans des limites aussi serrées, il est souhaitable d'être capable de contrôler tout les flux via un seul message de contrôle en utilisant une URL agrégée.

Ci-après figure un exemple de l'utilisation d'une seule session RTSP pour contrôler plusieurs flux. Il illustre aussi l'utilisation d'URL agrégées.

Le client C demande une présentation au serveur de supports M. Le film est stocké dans un fichier conteneur. Le client a obtenu une URL RTSP pour le fichier conteneur.

C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1

M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 164

           v=0
           o=- 2890844256 2890842807 IN IP4 172.16.2.93
           s=RTSP Session
           i=Exemple d'utilisation de session RTSP
           a=control:rtsp://foo/twister
           t=0 0
           m=audio 0 RTP/AVP 0
           a=control:rtsp://foo/twister/audio
           m=video 0 RTP/AVP 26
           a=control:rtsp://foo/twister/video

C->M: SETUP rtsp://foo/twister/audio RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001

M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001
           Session: 12345678

C->M: SETUP rtsp://foo/twister/video RTSP/1.0
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003
           Session: 12345678

M->C: RTSP/1.0 200 OK
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9004-9005
           Session: 12345678

C->M: PLAY rtsp://foo/twister RTSP/1.0
           CSeq: 4
           Range: npt=0-
           Session: 12345678

M->C: RTSP/1.0 200 OK
           CSeq: 4
           Session: 12345678
           RTP-Info: url=rtsp://foo/twister/video;seq=9810092;rtptime=3450012

C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
           CSeq: 5
           Session: 12345678

M->C: RTSP/1.0 460 Fonctionnement agrégé seul permis
           CSeq: 5

C->M: PAUSE rtsp://foo/twister RTSP/1.0
           CSeq: 6
           Session: 12345678

M->C: RTSP/1.0 200 OK
           CSeq: 6
           Session: 12345678

C->M: SETUP rtsp://foo/twister RTSP/1.0
           CSeq: 7
           Transport: RTP/AVP;unicast;client_port=10000

M->C: RTSP/1.0 459  Fonctionnement agrégé non admis
           CSeq: 7

Dans le premier cas d'échec, le client essaye une pause d'un flux (ici, la vidéo) de la présentation. Ceci est refusé par le serveur pour cette présentation. Dans le second cas, L'URL agrégée ne peut pas être utilisée pour SETUP et un message de contrôle est exigé pour chaque flux pour établir les paramètres de transport.

Cela garde la syntaxe de l'en-tête Transport simple et permet une analyse facile des informations de transport par les pare-feu.

14.3	Fichiers conteneur d'un seul flux

Certains serveurs RTSP peuvent traiter tous les fichiers comme si ils étaient des "fichiers conteneurs", alors que d'autres serveurs peuvent ne pas prendre en charge un tel concept. À cause de cela, les clients DEVRAIENT utiliser les règles établies dans la description de session pour les URL de demandes, plutôt que de supposer qu'une URL cohérente peut toujours être utilisée partout. Voici un exemple de la façon dont un serveur multi-flux peut espérer que sera traité un fichier d'un seul flux :

Accept: application/x-rtsp-mh, application/sdp
          CSeq: 1

S->C  RTSP/1.0 200 OK
          CSeq: 1
          Content-base: rtsp://foo.com/test.wav/
          Content-type: application/sdp
          Content-length: 48

          v=0
          o=- 872653257 872653257 IN IP4 172.16.2.187
          s=mu-law wave file
          i=audio test
          t=0 0
          m=audio 0 RTP/AVP 0
          a=control:streamid=0

C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;mode=play
          CSeq: 2

S->C  RTSP/1.0 200 OK
          Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;server_port=6970-6971;mode=play
          CSeq: 2
          Session: 2034820394

C->S  PLAY rtsp://foo.com/test.wav RTSP/1.0
          CSeq: 3
          Session: 2034820394

S->C  RTSP/1.0 200 OK
          CSeq: 3
          Session: 2034820394
          RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;seq=981888;rtptime=3781123

Noter l'URL différent dans la commande SETUP, puis le repli sur l'URL agrégé dans la commande PLAY. Cela prend tout son sens lorsque il y a plusieurs flux avec un contrôle agrégé, mais est moins qu'intuitif dans le cas particulier om le nombre de flux est un.

Dans ce cas particulier, il est recommandé que les serveurs soient indulgents pour la mise en œuvre qui envoie :

C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          CSeq: 3

Dans le pire des cas, les serveurs devraient renvoyer :

S->C  RTSP/1.0 460 Fonctionnement agrégé seul admis
          CSeq: 3

On espère aussi que les mises en œuvre de serveur sont aussi indulgentes pour ce qui suit :

C->S  SETUP rtsp://foo.com/test.wav RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode=play
          CSeq: 2

Comme il y seulement un flux dans ce fichier, il n'y a pas d'ambiguïté sur ce que cela signifie.

14.4	Présentation d'un support de direct en utilisant la diffusion groupée

Le serveur de supports M choisit l'adresse et l'accès de diffusion groupée. Ici, on suppose que le serveur de la Toile ne contient qu'un pointeur sur la description complète, alors que le serveur de supports M entretient la description complète.

C->W: GET /concert.sdp HTTP/1.1
           Host: www.example.com

W->C: HTTP/1.1 200 OK
           Content-Type: application/x-rtsl

           <session>
             <track src="rtsp://live.example.com/concert/audio">
           </session>

C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 1

M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 44

           v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           m=audio 3456 RTP/AVP 0
           a=control:rtsp://live.example.com/concert/audio
           c=IN IP4 224.2.0.1/16

C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;multicast

M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=224.2.0.1;port=3456-3457;ttl=16
           Session: 0456804596

C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 3
           Session: 0456804596

M->C: RTSP/1.0 200 OK
           CSeq: 3
           Session: 0456804596

14.5	Exécuter un support dans une session existante

Un participant C à une conférence veut que le serveur de supports M lise une bande de démonstration dans une conférence existante. C indique au serveur de supports que les adresses réseau et les clés de chiffrement ont déjà été données par la conférence, de sorte qu'elles ne devraient pas être choisies par le serveur. L'exemple omet les réponses de simple ACK.

C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 1
           Accept: application/sdp

M->C: RTSP/1.0 200 1 OK
           Content-type: application/sdp
           Content-Length: 44

           v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           i=See above
           t=0 0
           m=audio 0 RTP/AVP 0

C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=225.219.201.15;port=7000-7001;ttl=127
           Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=225.219.201.15;port=7000-7001;ttl=127
           Session: 91389234234
           Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 3
           Session: 91389234234

M->C: RTSP/1.0 200 OK
           CSeq: 3

14.6	Enregistrement

Le client C de participant à une conférence demande au serveur de supports M d'enregistrer les portions audio et vidéo d'une réunion. Le client utilise la méthode ANNOUNCE pour fournir des méta informations sur la session enregistrée au serveur.

C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
           CSeq: 90
           Content-Type: application/sdp
           Content-Length: 121

           v=0
           o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
           s=IETF Meeting, Munich - 1
           i=La trente huitième réunion de l'IETF se tiendra à Munich, Allemagne
           u=http://www.ietf.org/meetings/Munich.html
           e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
           p=IETF Channel 1 +49-172-2312 451
           c=IN IP4 224.0.1.11/127
           t=3080271600 3080703600
           a=tool:sdr v2.4a6
           a=type:test
           m=audio 21010 RTP/AVP 5
           c=IN IP4 224.0.1.11/127
           a=ptime:40
           m=video 61010 RTP/AVP 31
           c=IN IP4 224.0.1.12/127

M->C: RTSP/1.0 200 OK
           CSeq: 90

C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
           CSeq: 91
           Transport: RTP/AVP;multicast;destination=224.0.1.11;port=21010-21011;mode=record;ttl=127

M->C: RTSP/1.0 200 OK
           CSeq: 91
           Session: 50887676
           Transport: RTP/AVP;multicast;destination=224.0.1.11;port=21010-21011;mode=record;ttl=127

C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
           CSeq: 92
           Session: 50887676
           Transport: RTP/AVP;multicast;destination=224.0.1.12;port=61010-61011;mode=record;ttl=127

M->C: RTSP/1.0 200 OK
           CSeq: 92
           Transport: RTP/AVP;multicast;destination=224.0.1.12;port=61010-61011;mode=record;ttl=127

C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
           CSeq: 93
           Session: 50887676
           Range: clock=19961110T1925-19961110T2015

M->C: RTSP/1.0 200 OK
           CSeq: 93

15	Syntaxe

La syntaxe de RTSP est décrite en format Backus-Naur augmenté (BNF) comme utilisé dans la RFC 2068 [2].

15.1	Syntaxe de base

OCTET	=  <toute séquence de données de 8 bits	
CHAR	= <tout caractère US-ASCII (octets 0 - 127)>	
UPALPHA	= <toute lettre majuscule US-ASCII "A".."Z">	
LOALPHA	= <toute lettre minuscule US-ASCII "a".."z">	
ALPHA	= UPALPHA | LOALPHA	
DIGIT	= <tout chiffre US-ASCII "0".."9">	
CTL	= <tout caractère de contrôle US-ASCII (octets 0 - 31) et DEL (127)>	
CR	= <US-ASCII CR, retour chariot (13)>	
LF 	= <US-ASCII LF, saut à la ligne (10)>	
SP	= <US-ASCII SP, espace (32)>	
HT	= <US-ASCII HT, tabulation horizontale (9)>	
<">	= <US-ASCII, double guillemets (34)>	
CRLF	= CR LF	
LWS	= [CRLF] 1*( SP | HT )	
TEXT	= <tout OCTET sauf CTL>	
tspecials	= "(" | ")" | "<" | ">" | "@" "," | ";" | ":" | "\" | <"> "/" | "[" | "]" | "?" | "=" "{" | "}" | SP | HT	
jeton	= 1*<tout CHAR sauf CTL ou tspecials>	
quoted-string	= ( <"> *(qdtext) <"> )	
qdtext	= <tout TEXT sauf <">>	
quoted-pair	= "\" CHAR	
en-tête-de-message	= nom-de-champ ":" [ valeur-de-champ ] CRLF	
nom-de-champ	= jeton	
valeur-de-champ	= *( contenu-de-champ | LWS )	
contenu-de-champ	= <les OCTET constituant la valeur-de-champ et comportant *TEXT ou des combinaisons de jeton, tspecials, et quoted-string>	
safe	=  "\$" | "-" | "_" | "." | "+"	
extra	=  "!" | "*" | "$'$" | "(" | ")" | ","	
hex	=  DIGIT | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f"	
échappement	=  "\%" hex hex	
réservé	=  ";" | "/" | "?" | ":" | "@" | "&" | "="	
non-réservé	=  alpha | digit | safe | extra	
xchar	=  non-réservé | réservé | échappement	

16	Considérations pour la sécurité

À cause de la similarité de la syntaxe et de l'usage entre serveurs RTSP et serveurs HTTP, les considérations pour la sécurité mentionnées dans [H15] s'appliquent. En particulier, prière de noter ce qui suit :

Mécanisme d'authentification :
RTSP et HTTP ont des schémas d'authentification communs, et devraient donc suivre les mêmes prescriptions à l'égard de l'authentification. Voir en [H15.1] les questions d'authentification du client, et en [H15.2] les questions concernant la prise en charge de plusieurs mécanismes d'authentification.

Abus des informations de connexion de serveur :
Les serveurs RTSP et HTTP ont vraisemblablement des mécanisme de connexion similaires, et devraient donc être également sur leurs gardes pour protéger le contenu de ces journaux de connexion afin de protéger la confidentialité des utilisateurs des serveurs. Voir dans [H15.3] les recommandations pour les serveurs HTTP en ce qui concerne les journaux des serveurs.

Transfert d'informations sensibles :
Il n'y a pas de raison de croire que les informations transférées via RTSP pourraient être moins sensibles que celles normalement transmises via HTTP. Donc, toutes les précautions concernant la protection de la confidentialité des données et de l'utilisateur s'appliquent aux mises en œuvre de clients, serveurs et mandataires RTSP. Voir des précisions dans [H15.4].

Attaques fondées sur les noms de fichier et de chemin :
Bien que les URL RTSP soient des bretelles opaques qui n'ont pas nécessairement de sémantique de système de fichier, il est prévu que de nombreuses mises en œuvre vont traduire des portions des URL de demande directement en appels au système de fichiers. Dans de tels cas, les systèmes de fichiers DEVRAIENT suivre les précautions soulignées dans [H15.5], telles que la vérification de ".." dans les composants de chemin.

Informations personnelles :
Les clients RTSP sont souvent instruits des mêmes informations que les clients HTTP (nom d'utilisateur, situation, etc.) et ils devraient donc être égaux. Voir dans [H15.6] des recommandations supplémentaires.

Questions de confidentialité en relation avec les en-têtes Accept :
Comme beaucoup des mêmes en-têtes "Accept" existent dans RTSP et dans HTTP, les avertissements donnés dans [H15.7] à l'égard de leur utilisation devraient être suivis.

Mystification du DNS
Vraisemblablement, étant donné les plus longs temps de connexion normalement associés aux sessions RTSP par rapport aux sessions HTTP, les optimisations du DNS du client RTSP devraient être moins répandues. Néanmoins, les recommandations données dans [H15.8] sont également pertinentes pour toute mise en œuvre qui voudrait s'appuyer sur une transposition DNS en IP pour aller au delà d'une seule utilisation de la transposition.

En-têtes Location et mystification :
Si un seul serveur prend en charge plusieurs organisations qui ne se font pas mutuellement confiance, il doit alors vérifier les valeurs des en-têtes Location et Content-Location dans les réponses générées sous le contrôle des dites organisations pour s'assurer qu'elles ne tentent pas d'invalider des ressources sur lesquelles elles n'ont pas autorité. ([H15.9])

En plus des recommandations de la spécification HTTP actuelle (RFC 2068 [2] (au moment de la rédaction du présent document) les futures spécifications de HTTP pourraient fournir des lignes directrices additionnelles sur les questions de sécurité.

Les considérations suivantes sont ajoutées pour les mises en œuvre de RTSP.

Attaque de déni de service concentrée :
Le protocole offre l'opportunité d'une attaque de déni de service contrôlée à distance. L'attaquant peut initier des flux de trafic pour une ou plusieurs adresses IP en les spécifiant comme destination dans des demandes SETUP. Bien que l'adresse IP de l'attaquant puisse être connue dans ce cas, ce n'est pas toujours utile pour empêcher de nouvelles attaques ou pour s'assurer de l'identité des attaquants. Et donc, un serveur RTSP ne DEVRAIT permettre des destinations spécifiées par le client pour les flux de trafic initiés par RTSP que si le serveur a vérifié l'identité du client, soit dans une base de données des usagers connus utilisant les mécanismes d'authentification RTSP (de préférence l'authentification par résumé ou quelque chose de plus fort) soit d'autres moyens sécurisés.

Capture de session :
Comme il n'y a pas de relation entre une connexion de couche transport et une session RTSP, il est possible à un client malintentionné de produire des demandes avec des identifiants de session aléatoires qui affecteraient des clients pas trop soupçonneux. Le serveur DEVRAIT utiliser un identifiant de session grand, aléatoire et non séquentiel pour minimiser les risques de cette sorte d'attaque.

Authentification :
Les serveurs DEVRAIENT mettre en œuvre les deux authentifications de base et par résumé [8]. Dans les environnements qui exigent une sécurité plus serrée pour les messages de commandes, le flux de contrôle RTSP peut être chiffré.

Questions de flux :
RTSP ne traite que du contrôle de flux. Les questions de la livraison du flux ne sont pas couvertes dans cette section, ni dans le reste du présent mémoire. Les mises en œuvre de RTSP vont très vraisemblablement s'appuyer sur d'autres protocoles tels que RTP, la diffusion groupée sur IP, RSVP et IGMP, et devraient se reporter aux considérations pour la sécurité données dans ces spécifications et les autres qui sont applicables.

Comportement suspect persistant :
Les serveurs RTSP DEVRAIENT retourner le code d'erreur 403 (Interdit) à réception d'une seule instance de comportement qui leur semble comporter un risque pour la sécurité. Les serveurs RTSP DEVRAIENT aussi être attentifs aux tentatives de sondage des faiblesses du serveur et de ses points d'entrée et PEUVENT déconnecter arbitrairement les clients qui sont réputés violer une politique de sécurité locale et ignorer leurs autres demandes.

Appendice A	Automates à états du protocole RTSP

Les machines à état de client et serveur RTSP décrivent le comportement du protocole de l'initialisation de la session RTSP à la terminaison de la session RTSP.

L'état est défini objet par objet. Un objet est identifié de façon univoque par l'URL du flux et l'identifiant de session RTSP. Toute demande/réplique qui utilise des URL agrégés notant des présentations RTSP composées de plusieurs flux aura un effet sur l'état individuel de tous les flux. Par exemple, si le film/présentation contient deux flux /film/audio et /film/vidéo, la commande suivante :

PLAY rtsp://foo.com/movie RTSP/1.0
CSeq: 559
Session: 12345678

aura alors un effet sur les états du flux film/audio et du flux film/vidéo.

Cet exemple n'implique pas une façon standard de représenter les flux dans les URL ou une relation au système de fichiers. Voir le paragraphe 3.2.

Les demandes OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER n'ont aucun effet sur l'état du client ou du serveur et ne sont donc pas mentionnées dans les tableaux d'état.

A.1	Automate à états de client

Le client peut supposer les états suivants :

Init :	SETUP a été envoyé, on attend une réplique.

Ready :	la réplique à SETUP a été reçue ou une réplique PAUSE a été reçue pendant un état Playing.

Playing :	la réplique PLAY a été reçue.

Recording :	la réplique RECORD a été reçue.

En général, le client change d'état à réception des répliques aux demandes. Noter que certaines demandes deviennent effectives à un moment ou position dans le futur (comme avec PAUSE), et l'état change aussi en conséquence. Si un SETUP explicite n'est pas exigé pour l'objet (par exemple, il est disponible via un groupe de diffusion), l'état commence à Ready. Dans ce cas, il y a seulement deux états, Ready et Playing. Le client change aussi d'état de Playing/Recording à Ready lorsque la fin de la gamme demandée est atteinte.

La colonne "prochain état" indique l'état supposé après la réception d'une réponse de succès (2xx). Si une demande donne un code d'état de 3xx, l'état devient Init, et un code d'état de 4xx ne donne pas de changement dans cet état. Les messages qui ne sont pas sur la liste pour chaque état NE DOIVENT PAS être produits par le client dans cet état, à l'exception des messages qui n'affectent pas l'état, qui sont énumérés ci-dessus. Recevoir un REDIRECT du serveur est équivalent à recevoir un état redirect 3xx du serveur.

État	message envoyé	prochain état après réponse	
Init	SETUP	Ready	
	TEARDOWN	Init	
Ready	PLAY	Playing	
	RECORD	Recording	
	TEARDOWN	Init	
	SETUP	Ready	
Playing	PAUSE	Ready	
	TEARDOWN	Init	
	PLAY	Playing	
	SETUP	Playing (transport changé)	
Recording	PAUSE	Ready	
	TEARDOWN	Init	
	RECORD	Recording	
	SETUP	Recording (transport changé)	

A.2	Automate à état de serveur

Le serveur peut supposer les états suivants :

Init :	C'est l'état initial, aucun SETUP valide n'a été encore reçu.

Ready :	Le dernier SETUP reçu est réussi,la réplique est envoyée ou après playing, le dernier PAUSE reçu a réussi, la réplique est envoyée.

Playing :	Le dernier PLAY reçu est réussi, la réplique est envoyée. les données sont en cours d'envoi.

Recording :	Le serveur enregistre les données du support.

En général, le serveur change d'état à réception de demandes. Si le serveur est dans l'état Playing ou Recording et en mode d'envoi individuel, il PEUT revenir à Init et terminer la session RTSP si il n'a pas reçu des informations de "bonne santé", telles que des rapports RTCP ou des commandes RTSP, de la part du client pendant un intervalle défini, avec une valeur par défaut de une minute. Le serveur peut déclarer une autre valeur de temporisation dans l'entête de réponse Session (paragraphe 12.37). Si le serveur est dans l'état Ready, il PEUT revenir à Init si il ne reçoit pas une demande RTSP pendant un intervalle de plus d'une minute. Noter que certaines demandes (telles que PAUSE) peuvent ne devenir effectives qu'à un moment ou position situé dans le futur, et l'état du serveur changera au moment approprié. Le serveur revient de l'état Playing ou  Recording à l'état Ready à la fin de la gamme demandée par le client.

Le message REDIRECT, lorsque il est envoyé, produit immédiatement son effet sauf si il a un en-tête Range qui spécifie quand le redirect est effectif. Dans un tel cas, l'état du serveur va aussi changer au moment approprié.

Si aucun SETUP explicite n'est exigé pour l'objet, l'état commence à Ready et il y a seulement deux états, Ready et Playing.

La colonne "prochain état" indique l'état supposé après l'envoi d'une réponse de succès (2xx). Si une demande résulte en un code d'état de 3xx, l'état devient Init. Un code d'état de 4xx ne résulte en aucun changement.

État	message reçu	état suivant	
Init	SETUP	Ready	
	TEARDOWN	Init	
Ready	PLAY	Playing	
	SETUP	Ready	
	TEARDOWN	Init	
	RECORD	Recording	
Playing	PLAY	Playing	
	PAUSE	Ready	
	TEARDOWN	Init	
	SETUP	Playing	
Recording	RECORD	Recording	
	PAUSE	Ready	
	TEARDOWN	Init	
	SETUP	Recording	

Appendice B	Interaction avec RTP

RTSP permet aux clients de supports de contrôler des sections choisies, non contiguës, de présentations de supports, de rendre ces flux avec une couche de supports RTP [24]. La couche de support restituant le flux RTP ne devrait pas être affectée par des bonds dans NPT. Et donc, les numéros de séquence RTP et les horodatages RTP DOIVENT être continus et monotones à travers les bonds de NPT.

Par exemple, supposons une fréquence d'horloge de 8000 Hz, un intervalle de mise en paquet de 100 ms et un numéro de séquence initial et un horodatage de zéro. D'abord, on exécute NPT de 10 à 15, puis on fait un saut et on exécute NPT de 18 à 20. Le premier segment est présenté sous forme de paquets RTP avec des numéros de séquence de 0 à 49 et des horodatages de 0 à 39 200. Le second segment consiste en paquets RTP avec des numéros de séquence de 50 à 69, avec des horodatages de 40 000 à 55 200.

On ne peut pas supposer que le client RTSP peut communiquer avec l'agent de supports RTP, car les deux processus peuvent être indépendants. Si l'horodatage RTP montre le même trou que le NPT, l'agent de supports va supposer qu'il y a une pause dans la présentation. Si le bond dans NPT est assez grand, l'horodatage RTP peut revenir à zéro et l'agent de supports peut croire que les paquets ultérieurs sont des duplications des paquets qui viennent juste d'être exécutés.

Pour certains types de données, une intégration serrée entre la couche RTSP et la couche RTP sera nécessaire. Cela n'empêche en aucune façon la restriction ci-dessus. Des clients de support RTSP/RTP combinés devraient utiliser le champ RTP-Info pour déterminer si les paquets RTP entrants ont été envoyés avant ou après une recherche.

Pour l'audio en continu, le serveur DEVRAIT régler le bit marqueur RTP au commencement du service d'une nouvelle demande PLAY. Cela permet au client d'effectuer l'adaptation de délai d'exécution.

Pour l'échelonnement (voir au paragraphe 12.34) les horodatages RTP devraient correspondre au temps de lecture. Par exemple, lors de l'exécution d'une vidéo enregistrée à 30 trames/s à une échelle de deux et une vitesse (paragraphe 12.35) de un, le serveur va abandonner chaque seconde trame pour maintenir les paquets vidéo et les livrer avec l'espacement normal d'horodatage de 3 000 par trame, mais NPT va augmenter de 1/15 seconde pour chaque trame vidéo.

Le client peut maintenir un affichage correct de NPT en notant la valeur de l'horodatage RTP du premier paquet qui arrive après le repositionnement. Le paramètre sequence de l'en-tête RTP-Info (paragraphe 12.33) fournit le premier numéro de séquence du prochain segment.

Appendice C	Utilisation de SDP pour les descriptions de session RTSP

Le protocole de description de session (SDP, Session Description Protocol, RFC 2327 [6]) peut être utilisé pour décrire des flux ou présentations dans RTSP. Un tel usage est limité à la spécification de moyens d'accès et au codages pour :

contrôle agrégé :
Une présentation composée de flux provenant d'un ou plusieurs serveurs qui ne sont pas disponibles pour le contrôle agrégé. Une telle description est normalement restituée par HTTP ou d'autres moyens non RTSP. Cependant, ils peuvent être reçus avec des méthodes ANNOUNCE.

contrôle non agrégé :
Une présentation composée de plusieurs flux provenant d'un seul serveur qui sont disponibles pour le contrôle agrégé. Une telle description est normalement retournée en réplique à une demande DESCRIBE sur une URL, ou reçue dans une méthode ANNOUNCE.

Le présent appendice décrit comment un fichier SDP, restitué, par exemple, par HTTP, détermine le fonctionnement d'une session RTSP. Il décrit aussi comment un client devrait interpréter un contenu SDP retourné en réplique à une demande DESCRIBE. SDP ne fournit aucun mécanisme par lequel un client puisse distinguer, sans l'intervention de l'homme, entre plusieurs flux de supports à rendre simultanément et un ensemble de solutions alternatives (par exemple, deux flux audio dans des langues différentes).

C.1	Définitions

Les termes "niveau-session", "niveau-support" et les autres noms de clé/attribut et valeurs utilisés dans le présent appendice sont à utiliser comme défini dans SDP (RFC 2327 [6]).

C.1.1	URL de contrôle
L'attribut "a=control:" est utilisé pour porter l'URL de contrôle. Cet attribut est utilisé à la fois pour la description de session et celle du support. Si il est utilisé pour un support individuel, il indique l'URL à utiliser pour contrôler ce flux de support particulier. Si il se trouve au niveau session, l'attribut indique l'URL pour le contrôle agrégé.

Exemple : a=control:rtsp://example.com/foo

Cet attribut peut contenir des URL relatives et absolues, suivant les règles et conventions établies dans la RFC 1808 [25]. Les mises en œuvre devraient chercher une URL de base dans l'ordre suivant :
1.	le champ RTSP Content-Base
2.	le champ RTSP Content-Location
3.	l'URL de la demande RTSP.

Si cet attribut contient seulement un astérisque (*), l'URL est alors traitée comme si elle était une URL vide incorporée, et qui hérite donc de l'URL de base entière.

C.1.2	Flux de supports
Le champ "m=" est utilisé pour énumérer les flux. On suppose que tous les flux spécifiés seront rendus avec la synchronisation appropriée. Si la session est en envoi individuel, le numéro d'accès sert de recommandation du serveur au client ; le client a encore à l'inclure dans sa demande SETUP et peut ignorer cette recommandation. Si le serveur n'a pas de préférence, il DEVRAIT régler la valeur du numéro d'accès à zéro.

Exemple :  m=audio 0 RTP/AVP 31

C.1.3	Types de charge utile
Le ou les types de charge utile sont spécifiés dans le champ "m=". Au cas où le type de charge utile est un type de charge utile statique de la RFC 1890 [1], aucune autre information n'est exigée. Au cas où c'est un type de charge utile dynamique, l'attribut de support "rtpmap" est utilisé pour spécifier ce qu'est le support. Le "nom de codage" au sein de l'attribut "rtpmap" peut être un de ceux spécifiés dans la RFC 1890 (Sections 5 et 6), ou un codage expérimental avec un préfixe "X-" comme spécifié dans SDP (RFC 2327 [6]). Les paramètres spécifiques du codec ne sont pas spécifiés dans ce champ, mais plutôt dans l'attribut "fmtp" décrit ci-dessous. Les mises en œuvre qui cherchent à enregistrer de nouveaux codages devraient suivre la procédure de la RFC 1890 [1]. Si le type de support n'est pas assorti au profil AV de RTP, il est alors recommandé de créer un nouveau profil et d'utiliser le nom de profil approprié au lieu de "RTP/AVP" dans le champ "m=".

C.1.4	Paramètres spécifiques du format
Les paramètres spécifiques du format sont portés en utilisant l'attribut de support "fmtp". La syntaxe de l'attribut "fmtp" est spécifique du ou des codages auxquels cet attribut se réfère. Noter que l'intervalle de mise en paquet est porté dans l'attribut "ptime".

C.1.5	Gamme de présentation
L'attribut "a=range" définit la gamme de temps total de la session mémorisée. (La longueur des sessions de direct peut être déduite des paramètres "t" et "r".) Sauf si la présentation contient des flux de supports de différentes durées, l'attribut de gamme est un attribut de niveau session. L'unité est spécifiée d'abord, suivie par la gamme de valeur. Les unîtés et leurs valeurs sont telles que définies aux paragraphes 3.5, 3.6 et 3.7.

Exemples :
a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203

C.1.6	Heure de disponibilité
Le champ "t=" DOIT contenir des valeurs convenables pour les heures de début et de fin aussi bien pour le contrôle de flux agrégé que non agrégé. Avec le contrôle agrégé, le serveur DEVRAIT indiquer une valeur d'heure d'arrêt pour laquelle il garantit que la description est valide, et une heure de début qui soit égale ou antérieure à l'heure à laquelle la demande DESCRIBE a été reçue. Il PEUT aussi indiquer des heures de début et de fin de 0, signifiant que la session est toujours disponible. Avec le contrôle non agrégé, les valeurs devraient refléter la période réelle pour laquelle la session est disponible en accord avec la sémantique de SDP, et ne dépendent pas d'autres moyens (tels que la durée de vie de la page de la Toile qui contient la description) à cette fin.

C.1.7	Information de connexion
Dans SDP, le champ "c=" contient l'adresse de destination du flux de supports. Cependant, pour les flux à la demande en envoi individuel et certains flux en diffusion groupée, l'adresse de destination est spécifiée par le client via la demande SETUP. Sauf si le contenu du support a une adresse de destination fixée, le champ "c=" est à régler à une valeur nulle convenable. Pour les adresses du type "IP4", cette valeur est "0.0.0.0".

C.1.8	Étiquette d'entité
L'attribut facultatif "a=etag" identifie une version de la description de session. Il est opaque au client. Les demandes SETUP peuvent inclure cet identifiant dans le champ If-Match (voir le paragraphe 12.22) pour ne permettre l'établissement de session que si cette valeur d'attribut correspond toujours à celle de la description en cours. La valeur de l'attribut est opaque et peut contenir tout caractère permis au sein des valeurs d'attribut de SDP.

Exemple : a=etag:158bb3e7c7fd62ce67f12b533f06b83a

On pourrait objecter que le champ "o=" apporte une fonctionnalité identique. Cependant, il le fait d'une manière qui mettrait des contraintes sur les serveurs qui ont besoin de prendre en charge plusieurs types de description de session autres que SDP pour la même partie de contenu de support.

C.2	Contrôle agrégé non disponible

Si une présentation ne prend pas en charge le contrôle agrégé et si plusieurs sections de supports sont spécifiées, chaque section DOIT avoir l'URL de contrôle spécifiée via l'attribut "a=control:".

Exemple :
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=Je viens d'une page de la Toile
t=0 0
c=IN IP4 0.0.0.0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.com/movie.vid

Noter que la position de l'URL de contrôle dans la description implique que le client établisse des sessions de contrôle RTSP distinctes pour les serveurs audio.com et video.com.

Il est recommandé qu'un fichier SDP contienne les informations d'initialisation de support complètes même si il est livré au client de support à travers des moyens non RTSP. Cela est nécessaire car il n'y a aucun mécanisme pour indiquer que le client devrait demander des informations de flux de support plus détaillées via DESCRIBE.

C.3	Contrôle agrégé disponible

Dans ce scénario, le serveur a plusieurs flux qui peuvent être contrôlés comme un tout. Dans ce cas, il y a deux attributs de niveau support "a=control:", qui sont utilisés pour spécifier les URL du flux, et un attribut de niveau session "a=control:" qui est utilisé comme URL de demande pour le contrôle agrégé. Si l'URL de niveau support est une URL relative, elle se résout en URL absolue conformément au paragraphe C.1.1 ci-dessus.

Si la présentation comporte seulement un flux, l'attribut "a=control:" de niveau support peut être omis. Cependant, si la présentation contient plus d'un flux, chaque section de flux de support DOIT contenir son propre attribut "a=control".

Exemple :
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I contain
i=<more info>
t=0 0
c=IN IP4 0.0.0.0
a=control:rtsp://example.com/movie/
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2

Dans cet exemple, il est exigé du client qu'il établisse une seule session RTSP vers le serveur, et utilise respectivement les URL rtsp://example.com/movie/trackID=1 et rtsp://example.com/movie/trackID=2 pour établir les flux vidéo et audio. L'URL rtsp://example.com/movie/ contrôle tout le film.

Appendice D	Mise en œuvre minimale de RTSP
D.1	Client

Une mise en œuvre de client DOIT être capable de faire ce qui suit :

*	Générer les demandes suivantes : SETUP, TEARDOWN, et soit PLAY (c'est-à-dire, un client de lecture minimal) soit RECORD (c'est-à-dire, un client d'enregistrement minimal). Si RECORD est mis en œuvre, ANNOUNCE doit aussi être mis en œuvre.
*	Inclure les en-têtes suivants dans les demandes : CSeq, Connection, Session, Transport. Si ANNOUNCE est mis en œuvre, elle doit avoir également la capacité d'inclure les en-têtes Content-Language, Content-Encoding, Content-Length, et Content-Type.
*	Analyser et comprendre les en-têtes suivants dans les réponses : CSeq, Connection, Session, Transport, Content-Language, Content-Encoding, Content-Length, Content-Type. Si RECORD est mis en œuvre, l'en-tête Location doit aussi être compris. Les mises en œuvre conformes à RTP devraient aussi mettre en œuvre RTP-Info.
*	Comprendre la classe de chaque code d'erreur reçu et notifier à l'utilisateur final, s'il en est un présent, les codes d'erreur des classes 4xx et 5xx. Les exigences de notification peuvent être assouplies si l'utilisateur final ne le veut explicitement pas pour un ou tous les codes d'état.
*	S'attendre et répondre aux demandes asynchrones provenant du serveur, telles que ANNOUNCE. Cela ne signifie pas nécessairement qu'il devrait mettre en œuvre la méthode ANNOUNCE, mais simplement qu'il DOIT répondre positivement ou négativement à toute demande reçue du serveur.

Bien que ce ne soit pas exigé, ce qui suit est vivement recommandé au moment de cette publication pour l'interopérabilité pratique avec les mises en œuvre initiales et/ou pour être un "bon citoyen".

*	mettre en œuvre RTP/AVP/UDP comme transport valide.
*	Inclure l'en-tête Agent-d'utilisateur.
*	Comprendre les descriptions de session SDP comme défini dans l'Appendice C.
*	Accepter que les formats d'initialisation de supports (tels que SDP) provenant d'une entrée standard, la ligne de commande, ou les autres moyens appropriés à l'environnement de fonctionnement agissent comme une "application d'aide" pour d'autres applications (telles que les navigateurs de la Toile).

Il peut y avoir des applications RTSP différentes de celles initialement envisagées par les contributeurs à la spécification RTSP pour lesquelles les exigences ci-dessus n'ont pas de sens. Donc, les recommandations ci-dessus servent seulement de lignes directrices plutôt que d'exigences strictes.

D.1.1	Lecture de base
Pour prendre en charge la lecture à la demande des flux de supports, le client DOIT de plus être capable de faire ce qui suit :
*	générer la demande PAUSE ;
*	mettre en œuvre la méthode REDIRECT, et l'en-tête Location.

D.1.2	Authentification activée
Afin d'accéder aux présentations de supports provenant de serveurs RTSP qui exigent l'authentification, le client DOIT de plus être capable de faire ce qui suit :
*	reconnaître le code d'état 401 ;
*	analyser et inclure l'en-tête WWW-Authenticate ;
*	mettre en œuvre l'authentification de base et l'authentification par résumé.

D.2	Serveur

Une mise en œuvre minimale de serveur DOIT être capable de faire ce qui suit :

*	Mettre en œuvre les méthodes suivantes : SETUP, TEARDOWN, OPTIONS et soit PLAY (pour un serveur de lecture minimal) soit RECORD (pour un serveur d'enregistrement minimal). Si RECORD est mis en œuvre, ANNOUNCE devrait aussi être mis en œuvre.
*	Inclure les en-têtes suivants dans les réponses : Connection, Content-Length, Content-Type, Content-Language, Content-Encoding, Transport, Public. La capacité d'inclure l'en-tête Location devrait être mise en œuvre si la méthode RECORD l'est. Les mises en œuvre conformes à RTP devraient aussi mettre en œuvre le champ RTP-Info.
*	Analyser et répondre correctement aux en-têtes suivants dans les demandes : Connection, Session, Transport, Require.

Bien que non exigé, ce qui suit est vivement recommandé au moment de cette publication pour l'interopérabilité pratique avec les mises en œuvre initiales et/ou pour être un "bon citoyen" :
*	mettre en œuvre RTP/AVP/UDP comme transport valide,
*	inclure l'en-tête Server,
*	mettre en œuvre la méthode DESCRIBE,
*	générer des descriptions de session SDP comme défini à l'Appendice C.

Il peut y avoir des applications RTSP différentes de celles initialement envisagées par les contributeurs à la spécification RTSP pour lesquelles les exigences ci-dessus n'ont pas de sens. Donc, les recommandations ci-dessus servent seulement de lignes directrices plutôt que d'exigences strictes.

D.2.1	Lecture de base
Pour prendre en charge la lecture à la demande des flux de support, le serveur DOIT de plus être capable de faire ce qui suit :
*	Reconnaître l'en-tête Range, et retourner une erreur si la recherche n'est pas prise en charge.
*	Mettre en œuvre la méthode PAUSE.

De plus, afin de prendre en charge les caractéristiques d'interface d'utilisateur couramment acceptées, ce qui suit est vivement recommandé pour les serveurs de supports à la demande :
*	Inclure et analyser l'en-tête Range, avec des unités NPT. La mise en œuvre des unités SMPTE est recommandée.
*	Inclure la longueur dans la présentation du support dans les informations d'initialisation du support.
*	Inclure les transpositions des horodatages spécifiques des données en NPT. Lorsque RTP est utilisé, la portion rtptime du champ RTP-Info peut être utilisée pour transposer les horodatages en NPT.

Les mises en œuvre de client peuvent utiliser la présence des informations de longueur pour déterminer si la coupure peut être recherchée, et désactiver de façon visible les caractéristiques de recherche pour les coupures dont les informations de longueur ne sont pas disponibles. Une utilisation courante de la longueur de présentation est de mettre en œuvre une "barre glissante" qui sert à la fois d'indicateur de progression et d'outil de positionnement de la chronologie.

Les transpositions des horodatages RTP en NPT sont nécessaires pour assurer un positionnement correct de la barre glissante.

D.2.2	Authentification activée
Afin de traiter correctement l'authentification du client, le serveur DOIT de plus être capable de faire ce qui suit :
*	Générer le code d'état 401 lorsque l'authentification est exigée pour la ressource.
*	Analyser et inclure l'en-tête WWW-Authenticate.
*	Mettre en œuvre l'authentification de base et l'authentification par résumé.

Appendice E	Adresse des auteurs

Henning Schulzrinne	Anup Rao	Robert Lanphier	
Dept. of Computer Science	Netscape Communications Corp.	RealNetworks	
Columbia University	501 E. Middlefield Road	1111 Third Avenue Suite 2900	
1214 Amsterdam Avenue	Mountain View, CA 94043	Seattle, WA 98101	
New York, NY 10027	USA	USA	
USA	mél : anup@netscape.com	mél : robla@real.com	
mél : schulzrinne@cs.columbia.edu			

Appendice F	Remerciements

Le présent mémoire se fonde sur les fonctionnalités du document RTSP original soumis en octobre 1996. Il emprunte aussi le format et les descriptions de HTTP/1.1.

Le présent document a beaucoup bénéficié des commentaires de tous ceux qui ont participé au groupe de travail MMUSIC. En plus de ceux  déjà mentionnés, les personnes suivantes ont contribué à cette spécification :
Rahul Agarwal, Torsten Braun, Brent Browning, Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, John K. Ho, Philipp Hoschka, Anne Jones, Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Rob McCool, David Oran, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Igor Plotnikov, Pinaki Shah, David Singer, Jeff Smith, Alexander Sokolsky, Dale Stammen et John Francis Stracke.

Références

[1]	[RFC1890]	H. Schulzrinne, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", janvier 1996. (Obsolète, voir RFC3551) (P.S.)

[2]	[RFC2068]	R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Protocole de transfert Hypertext -- HTTP/1.1", janvier 1997. (Obsolète, voir RFC2616) (P.S.)

[3]	[RFC2070]	F. Yergeau, G. Nicol, G. Adams, M. Duerst, "Internationalisation du langage de balisage Hypertext", janvier 1997. (Obsolète, voir RFC2854) (Historique)

[4]	[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[5]	ISO/CEI, "Technologies de l'information – codage générique des images animées et des informations audio associées - Partie 6 : extension pour les supports de mémorisation numérique et le contrôle," Projet de norme internationale ISO 13818-6, Organisation internationale de normalisation ISO/CEI JTC1/SC29/WG11, Genève, CH, nov. 1995.

[6]	[RFC2327]	M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998.

[7]	[RFC2069]	J. Franks, P. Hallam-Baker et J. Hostetler, "Extension à HTTP : authentification d'accès par résumé", janvier 1997. (Obsolète, voir RFC2617) (P.S.)

[8]	[RFC0768]	J. Postel, "Protocole de datagramme d’utilisateur", (STD 6), 28 août 1980.

[9]	[RFC1151]	C. Partridge et R. Hinden, "Version 2 du protocole de données fiables (RDP)", avril 1990.

[10]	[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", (STD 7), septembre 1981.

[11]	H. Schulzrinne, "A comprehensive multimedia control architecture for the Internet," dans Proc. International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), (St. Louis, Missouri), mai 1997.

[12]	Recommandation UIT-T H.323, "Systèmes et équipements de visiophone pour réseaux de zone locale qui fournissent une qualité de service non garantie", Genève, CH, mai 1996.

[13]	[RFC1961]	P. McMahon, "Méthode d'authentification GSS-API pour SOCKS version 5", juin 1996. (P.S.)

[14]	J. Miller, P. Resnick et D. Singer, "Rating services and rating systems (and their machine readable descriptions)," Recommandation REC-PICS-services-961031, W3C (World Wide Web Consortium), Boston, Massachusetts, oct. 1996.

[15]	J. Miller, T. Krauskopf, P. Resnick et W. Treese, "PICS label distribution label syntax and communication protocols," Recommandation REC-PICS-labels-961031, W3C (World Wide Web Consortium), Boston, Massachusetts, oct. 1996.

[16]	[RFC2234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997.

[17]	[RFC1123]	R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.

[18	][RFC1924]	R. Elz, "Représentation compacte des adresses IPv6", 1er avril 1996. (Information)

[19]	[RFC1738]	T. Berners-Lee et autres, "Localisateurs uniformes de ressource (URL)", décembre 1994. (P.S., voir les RFC 4248 et 4266)

[20]	[RFC2279]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", janvier 1998. (Obsolète, voir RFC3629) (D.S.)

[21]	[RFC1644]	R. Braden, "T/TCP – Extensions à TCP pour spécification fonctionnelle de transactions", juillet 1994. (Exp.)

[22]	W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. Reading, Massachusetts: Addison-Wesley, 1994.

[23]	[RFC1889]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996.

[24]	[RFC1808]	R. Fielding, "Localisateurs relatifs de ressource uniforme", juin 1995.

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1998). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.