2. Scénarios d'utilisation de RTP (RTP Use Scenarios)
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 ce pour quoi RTP peut être utilisé. Dans ces exemples, RTP est transporté au-dessus d'IP et UDP, et suit les conventions établies par le profil pour l'audio et la vidéo spécifié dans le RFC compagnon 3551.
2.1 Conférence audio multicast simple (Simple Multicast Audio Conference)
Un groupe de travail de l'IETF se réunit pour discuter du dernier document de protocole, en utilisant les services multicast IP d'Internet pour les communications vocales. Par le biais d'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 est utilisé pour les paquets de contrôle (RTCP). Ces informations d'adresse et de port sont distribuées 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é dans la Section 9.1, auquel cas une clé de chiffrement doit également être générée et distribuée. Les détails exacts de ces mécanismes d'allocation et de distribution sont au-delà de la portée de RTP.
L'application de conférence audio utilisée par chaque participant à la conférence envoie des données audio en petits morceaux d'une durée de, disons, 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 afin que les émetteurs puissent changer l'encodage pendant une conférence, par exemple, pour accommoder un nouveau participant connecté via une liaison à faible bande passante ou réagir aux indications de congestion du réseau.
Internet, comme d'autres réseaux de paquets, perd et réordonne occasionnellement les paquets et les retarde de quantités de temps variables. Pour faire face à ces déficiences, l'en-tête RTP contient des informations de synchronisation et un numéro de séquence qui permettent aux récepteurs de reconstruire la synchronisation produite par la source, de sorte que dans cet exemple, les morceaux d'audio sont joués de manière contiguë par le haut-parleur toutes les 20 ms. Cette reconstruction de synchronisation est effectuée séparément pour chaque source de paquets RTP dans la conférence. Le numéro de séquence peut également être utilisé par le récepteur pour estimer combien de paquets sont perdus.
Étant donné que les membres du groupe de travail rejoignent et quittent pendant la conférence, il est utile de savoir qui participe à tout moment et dans quelle mesure ils reçoivent les données audio. À cette fin, chaque instance de l'application audio dans la conférence multicast périodiquement un rapport de réception plus le nom de son utilisateur sur le port RTCP (contrôle). Le rapport de réception indique dans quelle mesure l'orateur actuel est 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 sous réserve des limites de bande passante de contrôle. Un site envoie le paquet RTCP BYE (Section 6.6) lorsqu'il quitte la conférence.
2.2 Conférence audio et vidéo (Audio and Video Conference)
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. C'est-à-dire que 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. Il n'y a pas de couplage direct au niveau RTP entre les sessions audio et vidéo, sauf qu'un utilisateur participant aux deux sessions doit utiliser le même nom distingué (canonique) dans les paquets RTCP pour les deux afin que les sessions puissent être associées.
Une motivation pour cette séparation est de permettre à certains participants de la conférence de ne recevoir qu'un seul média s'ils le choisissent. Une explication supplémentaire est donnée dans la Section 5.2. Malgré la séparation, la lecture synchronisée de l'audio et de la vidéo d'une source peut être réalisée en utilisant les informations de synchronisation transportées dans les paquets RTCP pour les deux sessions.
2.3 Mixeurs et traducteurs (Mixers and Translators)
Jusqu'à présent, nous avons supposé que tous les sites souhaitent recevoir des données multimédia dans le même format. Cependant, cela peut ne pas toujours être approprié. Considérez le cas où les participants d'une zone sont connectés via une liaison à faible 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é réduite, un relais de niveau RTP appelé mixeur peut être placé près de la zone à faible bande passante. Ce mixeur 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 à bande passante inférieure et transmet le flux de paquets à bande passante inférieure via la liaison à faible débit. Ces paquets peuvent être unicast à un seul destinataire ou multicast sur une adresse différente à plusieurs destinataires. L'en-tête RTP inclut un moyen pour les mixeurs d'identifier les sources qui ont contribué à un paquet mixé afin qu'une indication correcte de l'orateur puisse être fournie aux récepteurs.
Certains des participants prévus à la conférence audio peuvent être connectés avec des liaisons à large bande passante mais peuvent ne pas être directement accessibles via le multicast IP. Par exemple, ils peuvent être derrière un pare-feu au niveau de l'application qui ne laisse passer aucun paquet IP. Pour ces sites, le mixage peut ne pas être nécessaire, auquel cas un autre type de relais de niveau RTP appelé traducteur 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 envoie à nouveau sous forme de paquets multicast à un groupe multicast restreint au réseau interne du site.
Les mixeurs et traducteurs peuvent être conçus à diverses fins. Un exemple est un mixeur vidéo qui met à l'échelle 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 qui ne comprennent que ST-II, ou la traduction d'encodage paquet par paquet de flux vidéo provenant de sources individuelles sans resynchronisation ni mixage. Les détails du fonctionnement des mixeurs et traducteurs sont donnés dans la Section 7.
2.4 Encodages en couches (Layered Encodings)
Les applications multimédia devraient être capables d'ajuster le débit de transmission pour correspondre à la capacité du récepteur ou pour s'adapter à la congestion du réseau. De nombreuses implémentations placent la responsabilité de l'adaptabilité du débit à 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, où le plus petit tuyau du maillage réseau dicte la qualité et la fidélité de la « diffusion » multimédia en direct globale.
Au lieu de cela, la responsabilité de l'adaptation du débit peut être placée chez les récepteurs en combinant un encodage en couches avec un système de transmission en couches. Dans le contexte de RTP sur multicast IP, la source peut répartir les couches progressives d'un signal représenté hiérarchiquement 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 ne rejoignant que le sous-ensemble approprié des groupes multicast.
Les détails de l'utilisation de RTP avec des encodages en couches sont donnés dans les Sections 6.3.9, 8.3 et 11.