1. Introduction
Ce mémorandum spécifie le protocole de transport en temps réel (Real-time Transport Protocol, RTP), qui fournit des services de livraison de bout en bout pour les données ayant des caractéristiques en temps réel, telles que l'audio et la vidéo interactifs. Ces services incluent l'identification du type de charge utile, la numérotation de séquence, l'horodatage et la surveillance de la livraison. Les applications exécutent généralement RTP au-dessus d'UDP pour utiliser ses services de multiplexage et de somme de contrôle ; les deux protocoles contribuent à des parties de la fonctionnalité du protocole de transport. Cependant, RTP peut être utilisé avec d'autres protocoles de réseau ou de transport sous-jacents appropriés (voir Section 11). RTP prend en charge le transfert de données vers plusieurs destinations en utilisant la distribution multicast si elle est fournie par le réseau sous-jacent.
Notez que RTP lui-même ne fournit aucun mécanisme pour assurer une livraison en temps opportun ou fournir d'autres garanties de qualité de service, mais s'appuie sur les services de couche inférieure pour le faire. Il ne garantit pas la livraison ni n'empêche la livraison hors séquence, et ne suppose pas que le réseau sous-jacent soit 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 de paquets de l'émetteur, mais les numéros de séquence peuvent également être utilisés pour déterminer l'emplacement approprié d'un paquet, par exemple dans le 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édia multi-participants, il n'est pas limité à cette application particulière. Le stockage de données continues, la simulation distribuée interactive, le badge actif et les applications de contrôle et de mesure peuvent également trouver RTP applicable.
Ce document définit RTP, composé de deux parties étroitement liées :
-
le protocole de transport en temps réel (Real-time Transport Protocol, RTP), pour transporter des données ayant des propriétés en temps réel.
-
le protocole de contrôle RTP (RTP Control Protocol, RTCP), pour surveiller la qualité de service et transmettre des informations sur les participants à une session en cours. Ce dernier aspect de RTCP peut être suffisant pour les sessions « faiblement contrôlées », c'est-à-dire lorsqu'il n'y a pas de contrôle d'adhésion explicite et de configuration, mais il n'est pas nécessairement destiné à prendre en charge toutes les exigences de communication de contrôle d'une application. Cette fonctionnalité peut être entièrement ou partiellement subsumée par un protocole de contrôle de session séparé, qui dépasse le cadre de ce document.
RTP représente un nouveau style de protocole suivant les principes de tramage au niveau de l'application et de traitement de couche intégré proposés par Clark et Tennenhouse [10]. C'est-à-dire que RTP est destiné à être malléable pour fournir les informations requises par une application particulière et sera souvent intégré dans le traitement de l'application plutôt que d'être implémenté comme une couche séparée. RTP est un cadre de protocole qui est délibérément incomplet. Ce document spécifie les fonctions qui devraient être 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 qui nécessiterait une analyse, RTP est destiné à être adapté par des modifications et/ou des ajouts aux en-têtes selon les besoins. Des exemples sont donnés dans les 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 Section 13) :
-
un document de spécification de profil, qui définit un ensemble de codes de type de charge utile et leur mappage aux formats de charge utile (par exemple, encodages de médias). Un profil peut également définir des extensions ou des modifications à RTP qui sont spécifiques à une classe particulière d'applications. Typiquement, une application fonctionnera sous un seul profil. Un profil pour les données audio et vidéo peut être trouvé dans le RFC compagnon 3551 [1].
-
des documents de spécification de format de charge utile, 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 sur les services en temps réel et les algorithmes pour leur mise en œuvre ainsi qu'une discussion de fond sur certaines des décisions de conception de RTP peut être trouvée dans [11].
1.1 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 BCP 14, RFC 2119 [2] et indiquent les niveaux d'exigence pour les implémentations RTP conformes.