2. RTP Use Scenarios (Scénarios d'utilisation de RTP)
Les sections suivantes décrivent certains aspects de l'utilisation de RTP. Les exemples ont été choisis pour illustrer le fonctionnement de base des applications utilisant RTP, et non pour limiter les usages possibles de RTP. Dans ces exemples, RTP est transporté au-dessus d'IP et d'UDP, et suit les conventions établies par le profil pour l'audio et la vidéo spécifié dans le document compagnon RFC 3551.
2.1 Simple Multicast Audio Conference (Conférence audio multicast simple)
Un groupe de travail de l'IETF se réunit pour discuter du dernier document de protocole, en utilisant les services multicast IP de l'Internet pour les communications vocales. Par un mécanisme d'allocation, le président du groupe de travail obtient une adresse de groupe multicast et une paire de ports. Un port est utilisé pour les données audio, et l'autre pour les paquets de contrôle (RTCP). Cette information d'adresse et de port est distribuée aux participants prévus. Si la confidentialité est souhaitée, les paquets de données et de contrôle peuvent être chiffrés comme spécifié à la section 9.1, auquel cas une clé de chiffrement doit également être générée et distribuée. Les détails précis de ces mécanismes d'allocation et de distribution dépassent le cadre de RTP.
L'application de conférence audio utilisée par chaque participant envoie les données audio par petits morceaux, disons d'une durée de 20 ms. Chaque morceau de données audio est précédé d'un en-tête RTP ; l'en-tête RTP et les données sont à leur tour contenus dans un paquet UDP. L'en-tête RTP indique quel type d'encodage audio (tel que PCM, ADPCM ou LPC) est contenu dans chaque paquet, de sorte que les émetteurs peuvent changer l'encodage au cours d'une conférence, par exemple pour accueillir un nouveau participant connecté via un lien à faible bande passante ou pour réagir à des indications d'encombrement du réseau.
L'Internet, comme d'autres réseaux par paquets, perd et réordonne occasionnellement des paquets, et les retarde de quantités de temps variables. Pour faire face à ces altérations, l'en-tête RTP contient des informations de temporisation et un numéro de séquence qui permettent aux récepteurs de reconstruire la temporisation produite par la source, de sorte que, dans cet exemple, les morceaux audio sont restitués de façon contiguë par le haut-parleur toutes les 20 ms. Cette reconstruction temporelle est effectuée séparément pour chaque source de paquets RTP de la conférence. Le numéro de séquence peut également être utilisé par le récepteur pour estimer le nombre de paquets perdus.
Puisque les membres du groupe de travail rejoignent et quittent la conférence au fil du temps, il est utile de savoir qui participe à un moment donné et avec quelle qualité ils reçoivent les données audio. À cette fin, chaque instance de l'application audio dans la conférence diffuse périodiquement un rapport de réception (reception report) ainsi que le nom de son utilisateur sur le port RTCP (de contrôle). Le rapport de réception indique à quel point le locuteur actuel est bien reçu et peut être utilisé pour contrôler les encodages adaptatifs. En plus du nom d'utilisateur, d'autres informations d'identification peuvent également être incluses dans la limite de la bande passante de contrôle. Un site envoie le paquet RTCP BYE (section 6.6) lorsqu'il quitte la conférence.
2.2 Audio and Video Conference (Conférence audio et vidéo)
Si les médias audio et vidéo sont tous deux utilisés dans une conférence, ils sont transmis sous forme de sessions RTP séparées. Autrement dit, des paquets RTP et RTCP séparés sont transmis pour chaque média en utilisant deux paires de ports UDP différentes et/ou des adresses multicast différentes. Il n'y a pas de couplage direct au niveau RTP entre les sessions audio et vidéo, si ce n'est qu'un utilisateur participant aux deux sessions doit utiliser le même nom distingué (canonical) dans les paquets RTCP des deux, afin que les sessions puissent être associées.
Une motivation de cette séparation est de permettre à certains participants de la conférence de ne recevoir qu'un seul média s'ils le souhaitent. Une explication complémentaire est donnée à la section 5.2. Malgré cette séparation, une lecture synchronisée de l'audio et de la vidéo d'une source peut être obtenue en utilisant les informations de temporisation transportées dans les paquets RTCP des deux sessions.
2.3 Mixers and Translators (Mélangeurs et traducteurs)
Jusqu'à présent, nous avons supposé que tous les sites souhaitent recevoir les données média dans le même format. Cependant, cela n'est pas toujours approprié. Considérons le cas où des participants d'une zone sont connectés via un lien bas débit à la majorité des participants à la conférence qui bénéficient d'un accès réseau haut débit. Au lieu de forcer tout le monde à utiliser un encodage audio à bande passante réduite et de qualité inférieure, un relais de niveau RTP appelé mélangeur (mixer) peut être placé près de la zone bas débit. Ce mélangeur resynchronise les paquets audio entrants pour reconstruire l'espacement constant de 20 ms généré par l'émetteur, mélange ces flux audio reconstruits en un seul flux, traduit l'encodage audio en un encodage à plus faible bande passante et transfère le flux de paquets à bande passante réduite à travers le lien bas débit. Ces paquets peuvent être envoyés en unicast à un destinataire unique ou en multicast sur une adresse différente à plusieurs destinataires. L'en-tête RTP inclut un moyen pour que les mélangeurs identifient les sources ayant contribué à un paquet mélangé, afin qu'une indication correcte du locuteur puisse être fournie aux récepteurs.
Certains des participants prévus à la conférence audio peuvent être connectés par des liens à haute bande passante mais ne pas être directement joignables via le multicast IP. Par exemple, ils peuvent se trouver derrière un pare-feu au niveau application (application-level firewall) qui ne laisse passer aucun paquet IP. Pour ces sites, le mélange peut ne pas être nécessaire, auquel cas un autre type de relais de niveau RTP appelé traducteur (translator) peut être utilisé. Deux traducteurs sont installés, un de chaque côté du pare-feu, celui de l'extérieur acheminant tous les paquets multicast reçus via une connexion sécurisée vers le traducteur à l'intérieur du pare-feu. Le traducteur à l'intérieur du pare-feu les renvoie sous forme de paquets multicast vers un groupe multicast restreint au réseau interne du site.
Les mélangeurs et les traducteurs peuvent être conçus à diverses fins. Un exemple est un mélangeur vidéo qui redimensionne les images de personnes individuelles dans des flux vidéo séparés et les compose en un seul flux vidéo pour simuler une scène de groupe. D'autres exemples de traduction incluent la connexion d'un groupe d'hôtes ne parlant que IP/UDP à un groupe d'hôtes ne comprenant que ST-II, ou la traduction d'encodage paquet par paquet de flux vidéo de sources individuelles sans resynchronisation ni mélange. Les détails du fonctionnement des mélangeurs et des traducteurs sont donnés à la section 7.
2.4 Layered Encodings (Encodages en couches)
Les applications multimédias doivent être capables d'ajuster le débit de transmission pour correspondre à la capacité du récepteur ou pour s'adapter à l'encombrement du réseau. De nombreuses implémentations placent la responsabilité de l'adaptation du débit (rate-adaptivity) à la source. Cela ne fonctionne pas bien avec la transmission multicast en raison des exigences de bande passante conflictuelles des récepteurs hétérogènes. Le résultat est souvent un scénario de plus petit dénominateur commun (least-common denominator), où le plus petit tuyau du maillage réseau dicte la qualité et la fidélité de la « diffusion » multimédia en direct globale.
À la place, la responsabilité de l'adaptation du débit peut être placée au niveau des récepteurs en combinant un encodage en couches (layered encoding) avec un système de transmission en couches. Dans le contexte de RTP sur multicast IP, la source peut répartir (stripe) les couches progressives d'un signal hiérarchiquement représenté sur plusieurs sessions RTP, chacune transportée sur son propre groupe multicast. Les récepteurs peuvent alors s'adapter à l'hétérogénéité du réseau et contrôler leur bande passante de réception en rejoignant uniquement le sous-ensemble approprié des groupes multicast.
Les détails de l'utilisation de RTP avec des encodages en couches sont donnés aux sections 6.3.9, 8.3 et 11.