Aller au contenu principal

7. RTP Translators and Mixers (Traducteurs et mélangeurs RTP)

En plus des systèmes terminaux, RTP prend en charge la notion de « traducteurs » (translators) et de « mélangeurs » (mixers), qui peuvent être considérés comme des « systèmes intermédiaires » au niveau RTP. Bien que ce support ajoute une certaine complexité au protocole, le besoin de ces fonctions a été clairement établi par des expériences avec des applications audio et vidéo multicast sur l'Internet. Les exemples d'usage de traducteurs et de mélangeurs donnés à la section 2.3 proviennent de la présence de pare-feux et de connexions à faible bande passante, qui sont tous deux susceptibles de demeurer.

7.1 General Description (Description générale)​

Un traducteur/mélangeur RTP connecte deux ou plusieurs « nuages » (clouds) au niveau transport. Typiquement, chaque nuage est défini par un réseau commun et un protocole de transport (par exemple IP/UDP) plus une adresse multicast et un port de destination au niveau transport, ou une paire d'adresses et de ports unicast. (Des traducteurs de protocole de niveau réseau, tels que IP version 4 vers IP version 6, peuvent être présents à l'intérieur d'un nuage de manière invisible à RTP.) Un système peut servir de traducteur ou de mélangeur pour un certain nombre de sessions RTP, mais chacun est considéré comme une entité logiquement séparée.

Afin d'éviter de créer une boucle quand un traducteur ou un mélangeur est installé, les règles suivantes DOIVENT être observées :

  • Chacun des nuages connectés par des traducteurs et des mélangeurs participant à une session RTP DOIT soit être distinct de tous les autres dans au moins un de ces paramètres (protocole, adresse, port), soit être isolé au niveau réseau des autres.

  • Une dérivée de la première règle est qu'il NE DOIT PAS y avoir de multiples traducteurs ou mélangeurs connectés en parallèle à moins que par un certain arrangement ils ne partitionnent l'ensemble des sources à transférer.

De même, tous les systèmes terminaux RTP qui peuvent communiquer à travers un ou plusieurs traducteurs ou mélangeurs RTP partagent le même espace SSRC, c'est-à-dire que les identificateurs SSRC DOIVENT être uniques parmi tous ces systèmes terminaux. La section 8.2 décrit l'algorithme de résolution de collision par lequel les identificateurs SSRC sont maintenus uniques et les boucles sont détectées.

Il peut y avoir de nombreuses variétés de traducteurs et de mélangeurs conçus pour différents buts et applications. Quelques exemples consistent à ajouter ou retirer le chiffrement, changer l'encodage des données ou les protocoles sous-jacents, ou répliquer entre une adresse multicast et une ou plusieurs adresses unicast. La distinction entre traducteurs et mélangeurs est que un traducteur fait passer les flux de données de différentes sources séparément, tandis qu'un mélangeur les combine pour former un nouveau flux :

  • Traducteur : Transfère les paquets RTP avec leur identificateur SSRC intact ; cela rend possible pour les récepteurs d'identifier les sources individuelles même si les paquets de toutes les sources passent à travers le même traducteur et portent l'adresse source réseau du traducteur. Certains types de traducteurs feront passer les données intactes, mais d'autres PEUVENT changer l'encodage des données et donc le type de charge utile RTP et l'horodatage. Si plusieurs paquets de données sont ré-encodés en un seul, ou vice versa, un traducteur DOIT assigner de nouveaux numéros de séquence aux paquets sortants. Les pertes dans le flux de paquets entrants peuvent induire des trous correspondants dans les numéros de séquence sortants. Les récepteurs ne peuvent pas détecter la présence d'un traducteur à moins qu'ils ne sachent par un autre moyen quel type de charge utile ou quelle adresse de transport était utilisé par la source originale.

  • Mélangeur : Reçoit des flux de paquets de données RTP d'une ou plusieurs sources, change possiblement le format des données, combine les flux d'une certaine manière puis transfère le flux combiné. Puisque la temporisation parmi les multiples sources d'entrée ne sera généralement pas synchronisée, le mélangeur effectuera des ajustements de temporisation parmi les flux et générera sa propre temporisation pour le flux combiné, de sorte qu'il est la source de synchronisation. Ainsi, tous les paquets de données transférés par un mélangeur DOIVENT être marqués avec le propre identificateur SSRC du mélangeur. Afin de préserver l'identité des sources originales ayant contribué au paquet mélangé, le mélangeur DEVRAIT insérer leurs identificateurs SSRC dans la liste d'identificateurs CSRC suivant l'en-tête RTP fixe du paquet. Un mélangeur qui est lui-même aussi une source contributrice pour un paquet DEVRAIT inclure explicitement son propre identificateur SSRC dans la liste CSRC pour ce paquet.

    Pour certaines applications, il PEUT être acceptable qu'un mélangeur n'identifie pas les sources dans la liste CSRC. Toutefois, cela introduit le danger que des boucles impliquant ces sources ne puissent pas être détectées.

L'avantage d'un mélangeur sur un traducteur pour des applications comme l'audio est que la bande passante de sortie est limitée à celle d'une seule source même quand plusieurs sources sont actives côté entrée. Cela peut être important pour les liens à faible bande passante. L'inconvénient est que les récepteurs côté sortie n'ont aucun contrôle sur quelles sources sont transférées ou coupées (muted), à moins qu'un mécanisme ne soit implémenté pour le contrôle à distance du mélangeur. La régénération de l'information de synchronisation par les mélangeurs signifie aussi que les récepteurs ne peuvent pas faire de synchronisation inter-média des flux originaux. Un mélangeur multi-média pourrait le faire.

       [E1]                                    [E6]
        |                                       |
 E1:17 |                                 E6:15 |
        |                                       |   E6:15
        V  M1:48 (1,17)         M1:48 (1,17)    V   M1:48 (1,17)
       (M1)-------------><T1>-----------------><T2>-------------->[E7]
        ^                 ^     E4:47           ^   E4:47
 E2:1 |           E4:47 |                     |   M3:89 (64,45)
        |                 |                     |
       [E2]              [E4]     M3:89 (64,45) |
                                                  |        legend:
[E3] --------->(M2)----------->(M3)------------|        [End system]
        E3:64        M2:12 (64)  ^                       (Mixer)
                                 | E5:45                 <Translator>
                                 |
                                [E5]          source: SSRC (CSRCs)
                                              ------------------->

Figure 3 : Exemple de réseau RTP avec systèmes terminaux, mélangeurs et traducteurs

Un ensemble de mélangeurs et de traducteurs est montré à la figure 3 pour illustrer leur effet sur les identificateurs SSRC et CSRC. Dans la figure, les systèmes terminaux sont montrés comme des rectangles (nommés E), les traducteurs comme des triangles (nommés T) et les mélangeurs comme des ovales (nommés M). La notation « M1:48(1,17) » désigne un paquet provenant d'un mélangeur M1, identifié par la valeur SSRC (aléatoire) 48 de M1 et deux identificateurs CSRC, 1 et 17, copiés à partir des identificateurs SSRC des paquets de E1 et E2.

7.2 RTCP Processing in Translators (Traitement RTCP dans les traducteurs)​

En plus de transférer les paquets de données, peut-être modifiés, les traducteurs et les mélangeurs DOIVENT aussi traiter les paquets RTCP. Dans de nombreux cas, ils démonteront les paquets RTCP composés reçus des systèmes terminaux pour agréger l'information SDES et modifier les paquets SR ou RR. La retransmission de cette information peut être déclenchée par l'arrivée du paquet ou par le minuteur d'intervalle RTCP du traducteur ou du mélangeur lui-même.

Un traducteur qui ne modifie pas les paquets de données, par exemple un qui réplique simplement entre une adresse multicast et une adresse unicast, PEUT simplement transférer aussi les paquets RTCP non modifiés. Un traducteur qui transforme la charge utile d'une certaine manière DOIT faire les transformations correspondantes dans l'information SR et RR afin qu'elle reflète toujours les caractéristiques des données et la qualité de réception. Ces traducteurs NE DOIVENT PAS simplement transférer les paquets RTCP. En général, un traducteur NE DEVRAIT PAS agréger les paquets SR et RR de différentes sources en un seul paquet car cela réduirait la précision des mesures de délai de propagation basées sur les champs LSR et DLSR.

  • Information d'émetteur SR : Un traducteur ne génère pas sa propre information d'émetteur, mais transfère les paquets SR reçus d'un nuage vers les autres. Le SSRC est laissé intact mais l'information d'émetteur DOIT être modifiée si requise par la traduction. Si un traducteur change l'encodage des données, il DOIT changer le champ « compte d'octets de l'émetteur » (sender's byte count). S'il combine aussi plusieurs paquets de données en un paquet de sortie, il DOIT changer le champ « compte de paquets de l'émetteur » (sender's packet count). S'il change la fréquence d'horodatage, il DOIT changer le champ « horodatage RTP » dans le paquet SR.

  • Blocs de rapport de réception SR/RR : Un traducteur transfère les rapports de réception reçus d'un nuage vers les autres. Notez qu'ils circulent dans la direction opposée aux données. Le SSRC est laissé intact. Si un traducteur combine plusieurs paquets de données en un paquet de sortie, et change donc les numéros de séquence, il DOIT faire la manipulation inverse pour les champs de perte de paquets et le champ « numéro de séquence étendu reçu » (extended last sequence number). Cela peut être complexe. Dans le cas extrême, il peut n'y avoir aucune manière significative de traduire les rapports de réception, donc le traducteur PEUT ne passer aucun rapport de réception du tout, ou un rapport synthétique basé sur sa propre réception. La règle générale est de faire ce qui a du sens pour une traduction particulière.

    Un traducteur n'a pas besoin d'un identificateur SSRC propre, mais PEUT choisir d'en allouer un dans le but d'envoyer des rapports sur ce qu'il a reçu. Ceux-ci seraient envoyés à tous les nuages connectés, chacun correspondant à la traduction du flux de données tel qu'envoyé à ce nuage, puisque les rapports de réception sont normalement multicast à tous les participants.

  • SDES : Les traducteurs transfèrent typiquement sans changement l'information SDES qu'ils reçoivent d'un nuage vers les autres, mais PEUVENT, par exemple, décider de filtrer l'information SDES non-CNAME si la bande passante est limitée. Les CNAME DOIVENT être transférés pour permettre au mécanisme de détection de collision d'identificateur SSRC de fonctionner. Un traducteur qui génère ses propres paquets RR DOIT envoyer l'information SDES CNAME le concernant vers les mêmes nuages vers lesquels il envoie ces paquets RR.

  • BYE : Les traducteurs transfèrent les paquets BYE inchangés. Un traducteur qui est sur le point de cesser de transférer des paquets DEVRAIT envoyer un paquet BYE à chaque nuage connecté contenant tous les identificateurs SSRC qui étaient auparavant transférés vers ce nuage, incluant le propre identificateur SSRC du traducteur s'il a envoyé des rapports de sa propre initiative.

  • APP : Les traducteurs transfèrent les paquets APP inchangés.

7.3 RTCP Processing in Mixers (Traitement RTCP dans les mélangeurs)​

Puisqu'un mélangeur génère un nouveau flux de données propre, il ne fait pas du tout passer les paquets SR ou RR et génère plutôt une nouvelle information pour les deux côtés.

  • Information d'émetteur SR : Un mélangeur ne fait pas passer l'information d'émetteur des sources qu'il mélange car les caractéristiques des flux de source sont perdues dans le mélange. En tant que source de synchronisation, le mélangeur DEVRAIT générer ses propres paquets SR avec l'information d'émetteur sur le flux de données mélangé et les envoyer dans la même direction que le flux mélangé.

  • Blocs de rapport de réception SR/RR : Un mélangeur génère ses propres rapports de réception pour les sources dans chaque nuage et les envoie seulement au même nuage. Il NE DOIT PAS envoyer ces rapports de réception vers les autres nuages et NE DOIT PAS transférer les rapports de réception d'un nuage vers les autres car les sources n'y seraient pas des SSRC (seulement des CSRC).

  • SDES : Les mélangeurs transfèrent typiquement sans changement l'information SDES qu'ils reçoivent d'un nuage vers les autres, mais PEUVENT, par exemple, décider de filtrer l'information SDES non-CNAME si la bande passante est limitée. Les CNAME DOIVENT être transférés pour permettre au mécanisme de détection de collision d'identificateur SSRC de fonctionner. (Un identificateur dans une liste CSRC générée par un mélangeur pourrait entrer en collision avec un identificateur SSRC généré par un système terminal.) Un mélangeur DOIT envoyer l'information SDES CNAME le concernant vers les mêmes nuages vers lesquels il envoie des paquets SR ou RR.

    Puisque les mélangeurs ne transfèrent pas les paquets SR ou RR, ils extrairont typiquement les paquets SDES d'un paquet RTCP composé. Pour minimiser la surcharge, des morceaux des paquets SDES PEUVENT être agrégés en un seul paquet SDES qui est alors empilé sur un paquet SR ou RR provenant du mélangeur. Un mélangeur qui agrège des paquets SDES utilisera plus de bande passante RTCP qu'une source individuelle car les paquets composés seront plus longs, mais cela est approprié puisque le mélangeur représente multiples sources. De même, un mélangeur qui transfère les paquets SDES tels quels transmettra des paquets RTCP à un débit supérieur au débit d'une source unique, mais là encore cela est correct puisque les paquets proviennent de multiples sources. Le débit de paquets RTCP peut être différent de chaque côté du mélangeur.

    Un mélangeur qui n'insère pas d'identificateurs CSRC PEUT aussi s'abstenir de transférer les CNAME SDES. Dans ce cas, les espaces d'identificateur SSRC dans les deux nuages sont indépendants. Comme mentionné précédemment, ce mode de fonctionnement crée un danger que des boucles ne puissent pas être détectées.

  • BYE : Les mélangeurs DOIVENT transférer les paquets BYE. Un mélangeur qui est sur le point de cesser de transférer des paquets DEVRAIT envoyer un paquet BYE à chaque nuage connecté contenant tous les identificateurs SSRC qui étaient auparavant transférés vers ce nuage, incluant le propre identificateur SSRC du mélangeur s'il a envoyé des rapports de sa propre initiative.

  • APP : Le traitement des paquets APP par les mélangeurs est spécifique à l'application.

7.4 Cascaded Mixers (Mélangeurs en cascade)​

Une session RTP peut impliquer un ensemble de mélangeurs et de traducteurs comme montré à la figure 3. Si deux mélangeurs sont en cascade, tels que M2 et M3 dans la figure, les paquets reçus par un mélangeur ont pu déjà être mélangés et peuvent inclure une liste CSRC avec de multiples identificateurs. Le second mélangeur DEVRAIT construire la liste CSRC pour le paquet sortant en utilisant les identificateurs CSRC des paquets d'entrée déjà mélangés et les identificateurs SSRC des paquets d'entrée non mélangés. Cela est montré dans l'arc de sortie du mélangeur M3 étiqueté M3:89(64,45) dans la figure. Comme dans le cas des mélangeurs qui ne sont pas en cascade, si la liste CSRC résultante a plus de 15 identificateurs, le reste ne peut pas être inclus.