1. Introduction (Introduction)

Ce mémorandum spécifie le protocole de transport en temps réel (RTP, real-time transport protocol), qui fournit des services de livraison de bout en bout pour des données présentant des caractéristiques de temps réel, telles que l'audio et la vidéo interactifs. Ces services comprennent l'identification du type de charge utile (payload type), la numérotation de séquence, l'horodatage (timestamping) et le suivi de la livraison. Les applications exécutent généralement RTP au-dessus d'UDP afin d'utiliser ses services de multiplexage et de somme de contrôle ; les deux protocoles contribuent chacun à une partie des fonctionnalités du protocole de transport. Toutefois, RTP peut être utilisé avec d'autres protocoles réseau ou de transport sous-jacents appropriés (voir la section 11). RTP prend en charge le transfert de données vers plusieurs destinations au moyen d'une distribution multicast, si le réseau sous-jacent la fournit.

Il convient de noter que RTP ne fournit en lui-même aucun mécanisme garantissant une livraison en temps opportun, ni aucune autre garantie de qualité de service (QoS, quality-of-service) ; il s'appuie sur les services des couches inférieures pour ce faire. Il ne garantit pas la livraison ni n'empêche une livraison hors ordre, et ne suppose pas que le réseau sous-jacent est fiable et livre les paquets dans l'ordre. Les numéros de séquence inclus dans RTP permettent au récepteur de reconstruire la séquence des paquets de l'émetteur, mais les numéros de séquence peuvent aussi servir à déterminer la position correcte d'un paquet, par exemple lors du décodage vidéo, sans nécessairement décoder les paquets dans l'ordre.

Bien que RTP soit principalement conçu pour satisfaire les besoins des conférences multimédias à participants multiples, il n'est pas limité à cette application particulière. Le stockage de données continues, la simulation distribuée interactive, les badges actifs (active badge), ainsi que les applications de contrôle et de mesure peuvent également trouver RTP applicable.

Ce document définit RTP, constitué de deux parties étroitement liées :

• le protocole de transport en temps réel (RTP), destiné à transporter des données ayant des propriétés de temps réel ;

• le protocole de contrôle RTP (RTCP, RTP control protocol), destiné à surveiller la qualité de service et à transmettre des informations sur les participants à une session en cours. Ce dernier aspect de RTCP peut suffire pour des sessions « faiblement contrôlées » (loosely controlled), c'est-à-dire où il n'y a pas de contrôle de membres ni de configuration explicite, mais il n'est pas nécessairement destiné à couvrir l'ensemble des besoins de communication de contrôle d'une application. Cette fonctionnalité peut être totalement ou partiellement absorbée par un protocole de contrôle de session distinct, qui dépasse le cadre de ce document.

RTP représente un nouveau style de protocole suivant les principes du cadre au niveau application (application level framing) et du traitement de couche intégré (integrated layer processing) proposés par Clark et Tennenhouse [10]. Autrement dit, RTP est conçu pour être malléable afin de fournir l'information requise par une application particulière, et il est souvent intégré au traitement de l'application plutôt que d'être implémenté comme une couche séparée. RTP est un cadre de protocole délibérément incomplet. Ce document spécifie les fonctions attendues comme communes à toutes les applications pour lesquelles RTP serait approprié. Contrairement aux protocoles conventionnels dans lesquels des fonctions supplémentaires pourraient être accommodées en rendant le protocole plus général ou en ajoutant un mécanisme d'option nécessitant un analyseur syntaxique, RTP est conçu pour être adapté par des modifications et/ou des ajouts aux en-têtes selon les besoins. Des exemples sont donnés aux sections 5.3 et 6.4.3.

Par conséquent, en plus de ce document, une spécification complète de RTP pour une application particulière nécessitera un ou plusieurs documents compagnons (voir la section 13) :

• un document de spécification de profil (profile specification), qui définit un ensemble de codes de type de charge utile et leur correspondance avec des formats de charge utile (par exemple, des encodages multimédias). Un profil peut également définir des extensions ou des modifications de RTP spécifiques à une classe particulière d'applications. Une application donnée fonctionnera typiquement sous un seul profil. Un profil pour les données audio et vidéo se trouve dans le document compagnon RFC 3551 [1] ;

• des documents de spécification de format de charge utile (payload format specification), qui définissent comment une charge utile particulière, telle qu'un encodage audio ou vidéo, doit être transportée dans RTP.

Une discussion des services de temps réel et des algorithmes pour leur implémentation, ainsi qu'un arrière-plan sur certaines décisions de conception de RTP, se trouve dans [11].

1.1 Terminology (Terminologie)

Les mots clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans le BCP 14, RFC 2119 [2], et indiquent les niveaux d'exigence pour les implémentations RTP conformes.