3. Definitions (Définitions)

Charge utile RTP (RTP payload) : Les données transportées par RTP dans un paquet, par exemple des échantillons audio ou des données vidéo compressées. Le format et l'interprétation de la charge utile dépassent le cadre de ce document.
Paquet RTP (RTP packet) : Un paquet de données composé de l'en-tête RTP fixe, d'une liste éventuellement vide de sources contributrices (voir ci-dessous) et des données de charge utile. Certains protocoles sous-jacents peuvent exiger qu'un encapsulement du paquet RTP soit défini. Typiquement, un paquet du protocole sous-jacent contient un seul paquet RTP, mais plusieurs paquets RTP PEUVENT y être contenus si la méthode d'encapsulement le permet (voir la section 11).
Paquet RTCP (RTCP packet) : Un paquet de contrôle composé d'une partie d'en-tête fixe similaire à celle des paquets de données RTP, suivie d'éléments structurés qui varient selon le type de paquet RTCP. Les formats sont définis à la section 6. Typiquement, plusieurs paquets RTCP sont envoyés ensemble sous forme de paquet RTCP composé (compound RTCP packet) dans un seul paquet du protocole sous-jacent ; cela est rendu possible par le champ de longueur dans l'en-tête fixe de chaque paquet RTCP.
Port : « L'abstraction que les protocoles de transport utilisent pour distinguer plusieurs destinations au sein d'un ordinateur hôte donné. Les protocoles TCP/IP identifient les ports à l'aide de petits entiers positifs. » [12] Les sélecteurs de transport (TSEL, transport selectors) utilisés par la couche de transport OSI sont équivalents aux ports. RTP dépend du protocole de couche inférieure pour fournir un mécanisme tel que les ports afin de multiplexer les paquets RTP et RTCP d'une session.
Adresse de transport (Transport address) : La combinaison d'une adresse réseau et d'un port qui identifie un point de terminaison au niveau transport, par exemple une adresse IP et un port UDP. Les paquets sont transmis d'une adresse de transport source vers une adresse de transport de destination.
Type de média RTP (RTP media type) : Un type de média RTP est l'ensemble des types de charge utile qui peuvent être transportés au sein d'une seule session RTP. Le profil RTP assigne les types de média RTP aux types de charge utile RTP.
Session multimédia (Multimedia session) : Un ensemble de sessions RTP concurrentes parmi un groupe commun de participants. Par exemple, une visioconférence (qui est une session multimédia) peut contenir une session RTP audio et une session RTP vidéo.
Session RTP (RTP session) : Une association entre un ensemble de participants communiquant avec RTP. Un participant peut être impliqué dans plusieurs sessions RTP en même temps. Dans une session multimédia, chaque média est typiquement transporté dans une session RTP séparée avec ses propres paquets RTCP, à moins que l'encodage lui-même ne multiplexe plusieurs médias dans un seul flux de données. Un participant distingue plusieurs sessions RTP par la réception de sessions différentes utilisant des paires d'adresses de transport de destination différentes, où une paire d'adresses de transport comprend une adresse réseau plus une paire de ports pour RTP et RTCP. Tous les participants d'une session RTP peuvent partager une paire d'adresses de transport de destination commune, comme dans le cas du multicast IP, ou les paires peuvent être différentes pour chaque participant, comme dans le cas d'adresses réseau unicast individuelles et de paires de ports. Dans le cas unicast, un participant peut recevoir de tous les autres participants de la session en utilisant la même paire de ports, ou peut utiliser une paire de ports distincte pour chacun.

La caractéristique distinctive d'une session RTP est que chacune maintient un espace complet et séparé d'identificateurs SSRC (défini ci-après). L'ensemble des participants inclus dans une session RTP comprend ceux qui peuvent recevoir un identificateur SSRC transmis par l'un quelconque des participants, soit dans RTP en tant que SSRC ou CSRC (également défini ci-dessous), soit dans RTCP. Par exemple, considérons une conférence à trois parties implémentée en utilisant UDP unicast, chaque participant recevant des deux autres sur des paires de ports séparées. Si chaque participant renvoie uniquement à un autre participant un retour RTCP sur les données reçues de celui-ci, alors la conférence est composée de trois sessions RTP point à point séparées. Si chaque participant fournit aux deux autres participants un retour RTCP sur sa réception d'un autre participant, alors la conférence est composée d'une seule session RTP multi-parties. Ce dernier cas simule le comportement qui se produirait avec une communication multicast IP entre les trois participants.

Le cadre RTP permet les variations définies ici, mais un protocole de contrôle ou une conception d'application particulier imposera généralement des contraintes sur ces variations.
Source de synchronisation (SSRC, Synchronization source) : La source d'un flux de paquets RTP, identifiée par un identificateur SSRC numérique de 32 bits porté dans l'en-tête RTP de sorte à ne pas dépendre de l'adresse réseau. Tous les paquets d'une source de synchronisation font partie du même espace de temporisation et de numéros de séquence, de sorte qu'un récepteur groupe les paquets par source de synchronisation pour la lecture. Les exemples de sources de synchronisation incluent l'émetteur d'un flux de paquets dérivé d'une source de signal telle qu'un microphone ou une caméra, ou un mélangeur RTP (voir ci-dessous). Une source de synchronisation peut modifier son format de données, par exemple l'encodage audio, au fil du temps. L'identificateur SSRC est une valeur choisie aléatoirement et censée être globalement unique au sein d'une session RTP particulière (voir la section 8). Un participant n'a pas besoin d'utiliser le même identificateur SSRC pour toutes les sessions RTP d'une session multimédia ; la liaison des identificateurs SSRC est fournie via RTCP (voir la section 6.5.1). Si un participant génère plusieurs flux dans une session RTP, par exemple à partir de caméras vidéo séparées, chacun DOIT être identifié comme un SSRC différent.
Source contributrice (CSRC, Contributing source) : Une source d'un flux de paquets RTP qui a contribué au flux combiné produit par un mélangeur RTP (voir ci-dessous). Le mélangeur insère une liste des identificateurs SSRC des sources ayant contribué à la génération d'un paquet particulier dans l'en-tête RTP de ce paquet. Cette liste est appelée liste CSRC. Une application exemple est la conférence audio où un mélangeur indique tous les locuteurs dont la parole a été combinée pour produire le paquet sortant, permettant au récepteur d'indiquer le locuteur actuel, même si tous les paquets audio contiennent le même identificateur SSRC (celui du mélangeur).
Système terminal (End system) : Une application qui génère le contenu à envoyer dans des paquets RTP et/ou consomme le contenu des paquets RTP reçus. Un système terminal peut agir comme une ou plusieurs sources de synchronisation dans une session RTP particulière, mais typiquement une seule.
Mélangeur (Mixer) : Un système intermédiaire qui reçoit des paquets RTP d'une ou plusieurs sources, modifie éventuellement le format des données, combine les paquets d'une certaine manière, puis transfère un nouveau paquet RTP. Puisque la temporisation entre plusieurs sources d'entrée ne sera généralement pas synchronisée, le mélangeur effectuera des ajustements de temporisation entre les flux et générera sa propre temporisation pour le flux combiné. Ainsi, tous les paquets de données provenant d'un mélangeur seront identifiés comme ayant le mélangeur pour source de synchronisation.
Traducteur (Translator) : Un système intermédiaire qui transfère les paquets RTP en laissant intact leur identificateur de source de synchronisation. Les exemples de traducteurs incluent les dispositifs qui convertissent les encodages sans mélange, les réplicateurs du multicast vers l'unicast, et les filtres au niveau application dans les pare-feu.
Moniteur (Monitor) : Une application qui reçoit les paquets RTCP envoyés par les participants à une session RTP, en particulier les rapports de réception, et estime la qualité de service actuelle pour la surveillance de distribution, le diagnostic de panne et les statistiques à long terme. La fonction de moniteur est susceptible d'être intégrée dans l'(les) application(s) participant à la session, mais peut aussi être une application séparée qui ne participe pas autrement et n'envoie ni ne reçoit les paquets de données RTP (puisqu'ils sont sur un port séparé). Ce sont ce qu'on appelle des moniteurs tiers (third-party monitors). Il est également acceptable pour un moniteur tiers de recevoir les paquets de données RTP mais de ne pas envoyer de paquets RTCP ni d'être autrement compté dans la session.
Moyens non-RTP (Non-RTP means) : Protocoles et mécanismes qui peuvent être nécessaires en plus de RTP pour fournir un service utilisable. En particulier, pour les conférences multimédias, un protocole de contrôle peut distribuer les adresses multicast et les clés de chiffrement, négocier l'algorithme de chiffrement à utiliser, et définir des correspondances dynamiques entre les valeurs de type de charge utile RTP et les formats de charge utile qu'elles représentent pour les formats qui n'ont pas de valeur de type de charge utile prédéfinie. Des exemples de tels protocoles incluent le protocole SIP (Session Initiation Protocol, RFC 3261 [13]), la recommandation ITU H.323 [14] et les applications utilisant SDP (RFC 2327 [15]), telles que RTSP (RFC 2326 [16]). Pour les applications simples, le courrier électronique ou une base de données de conférence peuvent également être utilisés. La spécification de tels protocoles et mécanismes dépasse le cadre de ce document.