RTP : protocole de transport - RFC

RFC 3550 page - 4 - Schulzrinne & autresdélais variables. Pour tenir compte de ces dégradations, l'en-tête RTP contient des informations horaires et un numéro deséquence qui permet au receveur de reconstruire l'horaire produit par la source, de sorte que dans cet exemple, des tronçonsaudio sont joués de façon contiguë au haut-parleur toutes les 20 ms. Cette reconstruction horaire est effectuée séparémentpour chaque source de paquets RTP dans la conférence. Le numéro de séquence peut aussi être utilisé par le receveur pourestimer combien de paquets sont perdus.Comme les membres du groupe de travail se joignent à la conférence et la quittent en cours, il est utile de savoir quiparticipe à un moment donné et dans quel état sont reçues les données audio. À cette fin, chaque instance de l'applicationaudio dans la conférence envoie périodiquement en diffusion groupée un rapport de réception plus le nom de l'utilisateursur l'accès RTCP (de contrôle). Le rapport de réception indique comment le haut-parleur actuel reçoit et il peut être utilisépour contrôler le codage adaptatif. En plus du plan d'utilisateur, d'autres informations d'identification peuvent aussi êtreincluses sous réserve des limites de la bande passante de contrôle. Un site envoie le paquet RTCP BYE (paragraphe 6.6)lorsque il quitte la conférence.2.2 Conférence audio et vidéoSi les supports audio et vidéo sont tous deux utilisés dans une conférence, ils sont transmis dans des sessions RTPdistinctes. C'est à dire que des paquets RTP et RTCP séparés sont transmis pour chaque support utilisant deux pairesd'accès UDP et/ou adresses de diffusion groupée différentes. Il n'y a pas de couplage direct au niveau RTP entre lessessions audio et vidéo, sauf qu'un usager participant aux deux sessions devrait utiliser le même nom distinctif (canonique)dans les paquets RTCP pour les deux, de sorte que les sessions puissent être associées.Un des motifs de cette séparation est de permettre à certains participants à la conférence de ne recevoir qu'un des supportssi tel est leur choix. De plus amples explications sont données au paragraphe 5.2. En dépit de cette séparation, laprésonorisation synchronisée des flux audio et vidéo d'une source peut être réalisée en utilisant les informations temporellesportées dans les paquets RTCP des deux sessions.2.3 Mélangeurs et traducteursJusqu'à présent, nous avons supposé que tous les sites veulent recevoir les données des supports dans le même format.Cependant, cela peut n'être pas toujours approprié. Considérons le cas où les participants dans une zone sont connectés aumoyen d'une liaison à bas débit à la majorité des participants à la conférence qui eux jouissent d'un accès par réseau hautdébit. Au lieu de forcer tout le monde à utiliser le codage audio à faible bande passante, de qualité réduite, un relais auniveau RTP appelé un mélangeur peut être placé près de la zone à faible bande passante. Ce mélangeur resynchronise lespaquets audio entrants pour reconstruire l'espacement constant de 20 ms généré par l'envoyeur, mixe les flux audioreconstruits en un seul flux, traduit le codage audio dans la bande passante inférieure et transmet le flux de paquets debande passante inférieure sur la liaison à basse vitesse. Ces paquets peuvent être en envoi individuel à un seul destinataireou en diffusion groupée à une adresse différente pour plusieurs receveurs. L'en-tête RTP inclut un moyen pour que lesmélangeurs identifient les sources qui contribuent à un paquet mixé de façon que l'indication correcte de la personne quiparle puisse être fournie aux receveurs.Certains des participants prévus à la conférence audio peuvent être connectés par des liaisons à forte bande passante qui nesont pas forcément joignables directement par une diffusion groupée IP. Par exemple, ils peuvent être derrière un pare-feude niveau application qui ne laissera passer aucun paquet IP. Pour ces sites, le mixage peut n'être pas nécessaire, auquel casun autre type de relais de niveau RTP appelé un traducteur peut être utilisé. Deux traducteurs sont installés, un de chaquecôté du pare-feu, celui de l'extérieur servant d'entonnoir pour tous les paquets en diffusion groupée reçus à travers uneconnexion sécurisée vers le traducteur à l'intérieur du pare-feu. Le traducteur à l'intérieur du pare-feu les envoie à nouveaucomme paquets en diffusion groupée à un groupe de diffusion groupée restreint au réseau interne du site.Les mélangeurs et traducteurs peuvent être conçus pour une grande variété d'objets. Voici l'exemple d'un mélangeur vidéoqui échelonne les images d'individus en flux vidéo séparés et les compose en un seul flux vidéo pour simuler une scène degroupe. D'autres exemples de traduction sont la connexion d'un groupe d'hôtes ne parlant que IP/UDP à un groupe d'hôtesqui ne comprennent que le ST-II, ou la traduction du codage paquet par paquet de flux vidéo de sources individuelles sansresynchronisation ni mixage. Les détails du fonctionnement des mélangeurs et traducteurs sont donnés à la Section 7.2.4 Codages selon les couchesLes applications multimédia devraient être capables d'ajuster le débit de transmission de façon à correspondre à la capacitédu receveur ou à s'adapter à l'encombrement du réseau. De nombreuses mises en œuvre placent la responsabilité del'adaptation du débit à la source. Cela ne fonctionne pas bien avec la transmission en diffusion groupée à cause desexigences de bande passante contradictoires de récepteurs hétérogènes. Le résultat est souvent un scénario de plus petit