RTP : protocole de transport - RFC

RFC 3550 page - 14 - Schulzrinne & autreset que chaque participant puisse calculer sa part indépendamment. La bande passante du trafic de contrôle est en plus de labande passante de session pour le trafic de données. Il est RECOMMANDÉ que la fraction de la bande passante de sessionajoutée pour RTCP soit fixée à 5 %. Il est aussi RECOMMANDÉ que 1/4 de la bande passante RTCP soit dédiée auxparticipants qui envoient des données afin que dans les sessions qui ont un grand nombre de receveurs mais un petit nombred'envoyeurs, les nouveaux participants qui la rejoignent reçoivent plus rapidement le CNAME pour les sites d'envoi.Lorsque la proportion d'envoyeurs est supérieure à 1/4 des participants, les envoyeurs reçoivent leur proportion de la bandepassante RTCP complète. Bien que les valeurs de ces constantes et des autres dans le calcul d'intervalle ne soient pascritiques, tous les participants à la session DOIVENT utiliser les mêmes valeurs afin que le même intervalle soit calculé.Donc, ces constantes DEVRAIENT être fixées pour un profil particulier.Un profil PEUT spécifier que la bande passante du trafic de contrôle peut être un paramètre séparé de la session plutôtqu'un strict pourcentage de la bande passante de session. Utiliser un paramètre distinct permet des applications quis'adaptent à un débit de bande passante RTCP cohérent avec une bande passante de données "normale" qui est inférieure àla bande passante maximum spécifiée par le paramètre de bande passante de session.Le profil PEUT spécifier de plus que la bande passante du trafic de contrôle peut être divisée en deux paramètres de sessiondistincts entre les participants qui sont des envoyeurs actifs de données et ceux qui ne le sont pas ; appelons ces paramètresS et R. Suivant la recommandation que 1/4 de la bande passante RTCP soit dédiée aux envoyeurs de données, les valeursRECOMMANDÉES par défaut pour ces deux paramètres seraient respectivement 1,25 % et 3,75 %. Lorsque la proportiond'envoyeurs est supérieure à S/(S+R) des participants, les envoyeurs reçoivent leur proportion de la somme de cesparamètres. Utiliser deux paramètres permet que les rapports de réception RTCP soient entièrement éliminés pour unesession particulière en réglant à zéro la bande passante RTCP pour les non envoyeurs de données tout en conservant labande passante RTCP pour les envoyeurs de données non zéro de sorte que les rapports d'envoyeurs puissent toujours êtreenvoyés pour la synchronisation inter supports. L'élimination des rapports de réception RTCP N'EST PASRECOMMANDÉE parce qu'ils sont nécessaires pour les fonctions énumérées au début de la Section 6, et en particulier leretour sur la qualité de réception et le contrôle d'encombrement. Cependant, il peut être approprié de faire ainsi pour lessystèmes qui fonctionnent sur des liaisons unidirectionnelles ou pour les sessions qui n'ont pas besoin de retour sur laqualité de réception ou sur la vitalité des receveurs et ont d'autres moyens d'éviter l'encombrement.L'intervalle calculé entre les transmissions des paquets RTCP composés DEVRAIT aussi avoir une limite inférieure pouréviter d'avoir des salves de paquets qui excèdent la bande passante admise lorsque le nombre de participants est petit et quele trafic n'est pas lissé conformément à la loi des grands nombres. Il empêche aussi l'intervalle de rapport de devenir troppetit durant les coupures transitoires du genre partition de réseau de telle sorte que l'adaptation soit retardée lorsque lapartition se répare. Au démarrage de l'application, un délai DEVRAIT être imposé avant l'envoi du premier paquet RTCPcomposé pour laisser aux paquets RTCP le temps d'être reçus de la part des autres participants afin que l'intervalle derapport converge plus rapidement vers la valeur correcte. Ce délai PEUT être réglé à la moitié de l'intervalle minimum pourpermettre une notification plus rapide de la présence du nouveau participant. La valeur RECOMMANDÉE pour unintervalle fixe minimum est de 5 secondes.Une mise en œuvre PEUT régler l'intervalle RTCP minimum à une valeur plus petite inversement proportionnelle auparamètre de bande passante de session avec les limitations suivantes :ooooPour les sessions en diffusion groupée, seuls les envoyeurs de données actifs PEUVENT utiliser la valeur réduiteminimum pour calculer l'intervalle pour la transmission des paquets RTCP composés.Pour les sessions en envoi individuel, la valeur réduite PEUT être aussi bien utilisée par les participants qui ne sont pasdes envoyeurs de données actifs, et le délai avant l'envoi du paquet RTCP composé initial PEUT être zéro.Pour toutes les sessions, le minimum fixé DEVRAIT être utilisé lors du calcul de la temporisation de l'intervalle duparticipant (voir au paragraphe 6.3.5) de sorte que les mises en œuvre qui n'utilisent pas la valeur réduite pour latransmission des paquets RTCP ne soient pas prématurément périmées par les autres participants.La valeur RECOMMANDÉE en secondes pour le minimum réduit est de 360 divisé par la bande passante de sessionen kbit/s. Ce minimum est inférieur à 5 s pour les bandes passantes supérieures à 72 kbit/s.L'algorithme décrit au paragraphe 6.3 et à l'Appendice A.7 a été conçu pour satisfaire les objectifs exposés dans cettesection. Il calcule l'intervalle entre l'envoi des paquets RTCP composés pour diviser la bande passante de trafic de contrôleadmise entre les participants. Cela permet à une application de fournir une réponse rapide aux petites sessions où, parexemple, l'identification de tous les participants est importante, tout en s'adaptant automatiquement aux grandes sessions.L'algorithme incorpore les caractéristiques suivantes :oL'intervalle calculé entre les paquets RTCP est en proportion linéaire du nombre des membres du groupe. C'est cefacteur linéaire qui permet une somme constante de la quantité de trafic de contrôle entre tous les membres.