RTP : protocole de transport - RFC

RFC 3550 page - 30 - Schulzrinne & autresLes données dépendantes de l'application peuvent apparaître ou non dans un paquet APP. Elles sont interprétées parl'application et non par RTP. Leur longueur DOIT être un multiple de 32 bits.7. Traducteurs et mixeurs RTPEn plus des systèmes d'extrémité, RTP prend en charge la notion de "traducteurs" et de "mixeurs", qui pourraient êtreconsidérés comme des "systèmes intermédiaires" au niveau de RTP. Bien que cette prise en charge ajoute de la complexitéau protocole, la nécessite de ces fonctions a été clairement établie par des expériences avec des applications audio et vidéoen diffusion groupée sur l'Internet. Les exemples d'utilisations de traducteurs et de mixeurs donnés au paragraphe 2.3proviennent de la présence de pare-feu et de connexions à faible bande passante, qui vont vraisemblablement durer.7.1 Description généraleUn traducteur/mixeur RTP connecte deux "nuages" de niveau transport ou plus. Normalement, chaque nuage est défini parun réseau commun et un protocole de transport (par exemple, IP/UDP) plus une adresse de diffusion groupée et un accès dedestination de niveau transport ou une paire d'adresses d'envoi individuel et d'accès. (Les traducteurs de protocole de niveautransport, tels que de IP version 4 en IP version 6, peuvent être présents au sein d'un nuage de façon invisible à RTP.) Unsystème peut servir de traducteur ou mixeur pour un certain nombre de sessions RTP, mais chacune est considérée commeune entité logique distincte.Afin d'éviter de créer une boucle lorsque un traducteur ou mixeur est installé, les règles suivantes DOIVENT être observées:ooChacun des nuages connectés par des traducteurs et mixeurs participant à une session RTP DOIT être distinct des autrespar au moins un de ces paramètres (protocole, adresse, accès), ou DOIT être isolé des autres au niveau réseau.Une déduction de la première règle est qu'il NE DOIT PAS y avoir plusieurs traducteurs ou mixeurs connectés enparallèle à moins que par quelque arrangement ils partitionnent l'ensemble des sources à transmettre.De même, tous les systèmes d'extrémité RTP qui peuvent communiquer à travers un ou plusieurs traducteurs ou mixeursRTP partagent le même espace de SSRC, c'est-à-dire que les identifiants de SSRC DOIVENT être uniques parmi tous cessystèmes d'extrémité. Le paragraphe 8.2 décrit l'algorithme de résolution de collision par lequel les identifiants de SSRCsont conservés uniques et les boucles détectées.Il peut y avoir de nombreuses variétés de traducteurs et mixeurs conçues pour différents objets et applications. Quelquesexemples sont d'ajouter ou retirer le chiffrement, changer le codage des données ou les protocoles sous-jacents, oudupliquer entre une adresse de diffusion groupée et une ou plusieurs adresses d'envoi individuel. La distinction entretraducteurs et mixeurs est qu'un traducteur passe séparément à travers les flux de données provenant de différentes sources,alors qu'un mixeur les combine pour former un nouveau flux:Traducteur :Il transmet les paquets RTP avec leur identifiant de SSRC intact ; cela donne aux receveurs la possibilité d'identifier lessources individuelles même si les paquets provenant de toutes les sources passent à travers le même traducteur et portentl'adresse réseau de source du traducteur. Certains types de traducteurs vont passer les données inchangées, mais d'autresPEUVENT changer le codage des données et donc le type de charge utile et l'horodatage des données RTP. Si plusieurspaquets de données sont recodés en un seul, ou vice versa, un traducteur DOIT allouer un nouveau type de charge utile auxpaquets sortants. Les pertes dans le flux entrant de paquets peuvent induire les trous correspondants dans les types decharge utile sortants. Les receveurs ne peuvent pas détecter la présence d'un traducteur à moins qu'ils ne sachent parquelque autre moyen quel type de charge utile ou d'adresse de transport a été utilisée par la source originale.Mixeur :Il reçoit les flux de paquets de données RTP d'une ou plusieurs sources, change éventuellement le format des données,combine les flux d'une certaine manière puis transmet le flux combiné. Comme l'écoulement temporel entre plusieurssources d'entrées n'est généralement pas synchronisé, le mixeur va faire des ajustements temporels entre les flux et générersa propre synchronisation pour le flux combiné, de sorte qu'il est la source de synchronisation. Et donc, tous les paquets dedonnées transmis par un mixeur DOIVENT être marqués avec le propre identifiant de SSRC du mixeur. Afin de préserverl'identité des sources originales qui contribuent au paquet mixé, le mixeur DEVRAIT insérer leurs identifiants de SSRCdans la liste des identifiants de CSRC suivis de l'en-tête RTP fixe du paquet. Un mixeur qui est aussi lui-même une sourcecontributive pour des paquets DEVRAIT explicitement inclure son propre identifiant de SSRC dans la liste de CSRC pource paquet.