7. Considérations RTCP pour les flux à débits disparates

Une session RTP possède un seul ensemble de paramètres qui configurent la bande passante de session. Il s'agit des fractions RTCP des émetteurs et des récepteurs (par exemple, les lignes SDP « b=RR: » et « b=RS: » [RFC3556]) et des paramètres du profil RTP/AVPF [RFC4585] (par exemple, trr-int) si ce profil (ou son extension sécurisée, RTP/SAVPF [RFC5124]) est utilisé. Par conséquent, l'intervalle de rapport RTCP de base, avant randomisation, sera le même pour chaque SSRC émetteur d'une session RTP. De même, chaque SSRC récepteur d'une session RTP aura le même intervalle de rapport de base, bien que celui-ci puisse différer de l'intervalle de rapport choisi par les SSRC émetteurs. Cet intervalle de rapport RTCP uniforme pour tous les SSRC peut entraîner l'envoi de rapports RTCP plus souvent, ou trop rarement, que ce qui est jugé souhaitable pour un flux RTP.

Par exemple, considérons un scénario dans lequel un flux audio émettant à quelques dizaines de kilobits par seconde est multiplexé dans une session RTP avec un flux vidéo de haute qualité de plusieurs mégabits. Si la bande passante de session est configurée en fonction du débit d'émission vidéo et que la fraction de bande passante RTCP par défaut de 5 % de la bande passante de session est utilisée, il est probable que la bande passante RTCP dépasse le débit d'émission audio. Si l'intervalle RTCP minimal réduit décrit dans la Section 6.2 du [RFC3550] est alors utilisé dans la session, comme cela convient pour la vidéo où un retour rapide sur les images I endommagées est souhaité, l'intervalle de rapport uniforme pour tous les émetteurs pourrait signifier que les sources audio sont censées envoyer des paquets RTCP plus souvent qu'elles n'envoient de paquets de données audio. Ce déséquilibre de bande passante peut être réduit par un réglage minutieux des paramètres RTCP, en particulier trr_int lorsque le profil RTP/AVPF est utilisé, mais ne peut pas être entièrement évité, car il est inhérent à la conception des règles de temporisation RTCP et affecte toutes les sessions RTP qui contiennent des flux dont les bandes passantes sont fortement déséquilibrées.

Des débits média différents ou des comportements RTCP souhaités différents peuvent également se produire avec des SSRC portant le même type de média. Un cas courant en conférence multipartite est celui où un petit nombre de flux vidéo sont affichés en haute résolution, tandis que les autres sont affichés sous forme de vignettes à basse résolution, le choix de celui qui est affiché en haute résolution étant contrôlé par l'activité vocale. Ici, les différences portent à la fois sur le débit média réel et sur les choix relatifs aux messages de retour qui pourraient être nécessaires. D'autres exemples de différences pouvant exister sont dus à l'usage prévu d'une source média. Une source média portant la vidéo de l'orateur dans une conférence est différente d'une caméra de documents. Les paramètres de base pouvant différer dans ce cas sont la fréquence d'images, le délai de bout en bout acceptable et la fidélité du rapport signal sur bruit (Signal-to-Noise Ratio, SNR) de l'image. Ces différences affectent non seulement les débits binaires nécessaires, mais aussi les comportements de transmission possibles, les mécanismes de réparation utilisables, les messages de retour que le contrôle et la réparation exigent, les exigences de transmission de ces messages de retour, et la surveillance de l'acheminement du flux RTP. D'autres scénarios similaires peuvent également exister.

L'envoi de plusieurs types de média dans une seule session RTP fait que cette session contient plus de SSRC que si chaque type de média était envoyé dans une session RTP séparée. Par exemple, si deux participants envoient chacun un flux RTP audio et un flux RTP vidéo dans une seule session RTP, cette session comprendra quatre SSRC ; mais si des sessions RTP séparées avaient été utilisées pour l'audio et la vidéo, chacune de ces deux sessions RTP ne comprendrait que deux SSRC. Par conséquent, l'envoi de plusieurs flux RTP dans une session RTP augmente la quantité de rapports croisés entre les SSRC, puisque chaque SSRC rend compte de tous les autres SSRC de la session. Cela augmente la taille des rapports RTCP, ce qui les fait envoyer moins souvent que ce ne serait le cas si des sessions RTP séparées étaient utilisées pour une bande passante RTCP donnée.

Enfin, lorsqu'une session RTP contient plusieurs types de média, il est important de noter que les rapports de qualité de réception RTCP, les messages de retour et les blocs de rapport étendus utilisés peuvent ne pas s'appliquer à tous les types de média. Les points d'extrémité devront prendre en compte le type de média de chaque SSRC et n'envoyer ou ne traiter que les rapports et les retours qui s'appliquent à ce SSRC particulier et à son type de média. Les solutions de signalisation peuvent présenter des lacunes lorsqu'il s'agit d'indiquer qu'un ensemble particulier de rapports RTCP ou de messages de retour ne s'applique qu'à un type de média particulier au sein d'une session RTP.

Du point de vue de RTCP, on peut donc constater qu'il y a des avantages à utiliser des sessions RTP séparées pour chaque source média, plutôt que d'envoyer plusieurs sources média dans une seule session RTP. Cependant, ces avantages sont souvent compensés par la nécessité de réduire l'utilisation de ports et de faciliter la traversée de NAT/pare-feu, obtenue en combinant les sources média dans une seule session RTP. Les sections suivantes examinent plus en détail certains des problèmes liés à l'utilisation de RTCP dans des sessions comportant plusieurs sources média.

7.1. Expiration des SSRC

Divers problèmes ont été identifiés concernant l'expiration des valeurs de SSRC lors de l'envoi de plusieurs flux RTP dans une session RTP.

7.1.1. Problèmes avec le paramètre T_rr_interval de RTP/AVPF

Le profil RTP/AVPF inclut une méthode permettant d'éviter que les rapports RTCP réguliers ne soient envoyés trop souvent. Ce mécanisme est décrit dans la Section 3.5.3 du [RFC4585] ; il est contrôlé par le paramètre T_rr_interval. Il fonctionne comme suit. Lorsqu'un rapport RTCP régulier est envoyé, une nouvelle valeur aléatoire, T_rr_current_interval, est générée, tirée uniformément dans l'intervalle allant de 0,5 à 1,5 fois T_rr_interval. Si un paquet RTCP régulier doit être envoyé plus tôt que T_rr_current_interval secondes après le paquet RTCP régulier précédent, et qu'il n'y a aucun message de retour à envoyer, alors ce paquet RTCP régulier est supprimé et le paquet RTCP régulier suivant est planifié. Le T_rr_current_interval est recalculé chaque fois qu'un paquet RTCP régulier est envoyé. L'avantage de la suppression est d'éviter de gaspiller de la bande passante lorsqu'il n'y a rien qui exige des transmissions RTCP fréquentes, tout en permettant d'utiliser la bande passante configurée lorsque le retour est nécessaire.

Malheureusement, ce mécanisme de suppression fausse la distribution des intervalles d'envoi RTCP par rapport aux intervalles de rapport RTCP réguliers. Les règles de temporisation RTCP standard, y compris la reconsidération et le facteur de compensation, font que les intervalles entre l'envoi de paquets RTCP ont une distribution biaisée vers la borne supérieure de l'intervalle [0.5/1.21828, 1.5/1.21828]*Td, où Td est l'intervalle de rapport RTCP déterministe calculé. Avec Td = 5 s, cette distribution couvre l'intervalle [2.052 s, 6.156 s]. En comparaison, les règles de suppression RTP/AVPF agissent dans un intervalle qui est de 0,5 à 1,5 fois T_rr_interval ; pour T_rr_interval = 5s, cela donne [2,5 s, 7,5 s].

L'effet de ce qui précède est que le temps entre paquets RTCP consécutifs lors de l'utilisation de la suppression par T_rr_interval peut devenir important. L'intervalle de temps maximal entre l'envoi d'un paquet RTCP régulier et le suivant, lorsque T_rr_interval est utilisé, se produit lorsque T_rr_current_interval prend sa valeur maximale et qu'un paquet RTCP régulier est supprimé à la fin de la période de suppression, puis que le paquet RTCP régulier suivant est planifié après son plus grand intervalle de rapport possible. En prenant le pire cas des deux intervalles, on obtient un temps maximal entre deux rapports RTCP de 1,5T_rr_interval + 1,5/1.21828Td.

Ce comportement peut être surprenant lorsque Td et T_rr_interval ont la même valeur. C'est-à-dire lorsque T_rr_interval est configuré pour correspondre à l'intervalle de rapport RTCP régulier. Dans ce cas, on pourrait s'attendre à ce que les paquets RTCP réguliers soient envoyés selon leur planification habituelle, mais que les paquets de retour puissent être envoyés plus tôt. Cependant, le problème mentionné ci-dessus fait que les paquets RTCP sont en réalité envoyés dans l'intervalle [0.5Td, 2.731Td] avec une distribution fortement non uniforme, plutôt que dans l'intervalle [0.41Td, 1.23Td]. Cela est peut-être inattendu, mais ne constitue pas un problème en soi. Toutefois, lorsqu'il est associé à des pertes de paquets, cela soulève la question de l'expiration prématurée.

7.1.2. Éviter une expiration prématurée

Dans RTP/AVP [RFC3550], le comportement d'expiration est simple ; il est de 5 fois Td, où Td est calculé avec une valeur de Tmin de 5 secondes. En d'autres termes, si la bande passante RTCP configurée permet un intervalle de rapport RTCP moyen inférieur à 5 secondes, l'expiration est de 25 secondes sans activité du SSRC (RTP ou RTCP) ; sinon, l'expiration est de 5 intervalles de rapport moyens.

RTP/AVPF [RFC4585] introduit différents comportements d'expiration selon la valeur de T_rr_interval. Lorsque T_rr_interval vaut 0, il utilise le même calcul d'expiration que RTP/AVP. Cependant, lorsque T_rr_interval est non nul, il remplace Tmin dans le calcul de l'expiration, probablement pour accélérer la détection des SSRC expirés. Toutefois, l'utilisation d'un T_rr_interval non nul a deux conséquences sur le comportement de RTP.

Premièrement, en raison de la suppression, le nombre de paquets RTP et RTCP envoyés par un SSRC qui n'est pas un émetteur RTP actif peut devenir très faible, en raison du problème discuté dans la Section 7.1.1. Comme l'intervalle entre paquets RTCP peut atteindre 2,73Td, un point d'extrémité peut en fait ne transmettre qu'un seul paquet RTCP au cours d'une période de 5Td. Les longs intervalles entraînent moins de paquets RTCP, au point qu'une seule perte de paquet RTCP peut parfois entraîner l'expiration d'un SSRC.

Deuxièmement, les modifications apportées par RTP/AVPF aux règles d'expiration réduisent la robustesse face à une mauvaise configuration. Il est courant d'utiliser RTP/AVPF configuré de manière à ce que les paquets RTCP puissent être envoyés fréquemment afin de permettre un retour rapide ; toutefois, cela rend les expirations très sensibles à T_rr_interval. Par exemple, si deux SSRC sont configurés, l'un avec T_rr_interval = 0,1 s et l'autre avec T_rr_interval = 0,6 s, alors cette petite différence fera que le SSRC ayant le T_rr_interval le plus court fera expirer l'autre s'il cesse d'envoyer des paquets RTP, puisque l'autre intervalle de rapport RTCP est plus de cinq fois le sien. Lorsque RTP/AVP est utilisé, ou RTP/AVPF avec T_rr_interval = 0, cela ne pose pas de problème, car la période d'expiration sera de 25 s, et les différences entre les bandes passantes RTCP configurées ne peuvent provoquer des expirations prématurées que lorsque les intervalles de rapport sont supérieurs à 5 s et diffèrent d'un facteur cinq. Pour limiter la portée de telles mauvaises configurations problématiques, nous définissons une mise à jour des règles d'expiration de RTP/AVPF dans la Section 7.1.4.

7.1.3. Interopérabilité entre RTP/AVP et RTP/AVPF

Si des points d'extrémité mettant en œuvre les profils RTP/AVP et RTP/AVPF (ou leurs variantes sécurisées) sont combinés au sein d'une seule session RTP, et que les points d'extrémité RTP/AVPF utilisent un T_rr_interval non nul nettement inférieur à 5 secondes, il existe un risque que les points d'extrémité RTP/AVPF fassent expirer prématurément les SSRC des points d'extrémité RTP/AVP, en raison de leurs règles d'expiration RTCP différentes. Inversement, si les points d'extrémité RTP/AVPF utilisent un T_rr_interval nettement supérieur à 5 secondes, il existe un risque que les points d'extrémité RTP/AVP fassent expirer les SSRC des points d'extrémité RTP/AVPF.

Mélanger des points d'extrémité utilisant deux profils RTP différents au sein d'une seule session RTP n'est PAS RECOMMANDÉ (NOT RECOMMENDED). Cependant, si des profils RTP mélangés sont utilisés et que les points d'extrémité RTP/AVPF ne sont pas mis à jour pour suivre la Section 7.1.4 de ce mémo, alors la session RTP/AVPF DEVRAIT (SHOULD) être configurée pour utiliser T_rr_interval = 4 secondes afin d'éviter les expirations prématurées.

Le choix de T_rr_interval = 4 secondes pour l'interopérabilité peut sembler étrange. Intuitivement, cette valeur devrait être de 5 secondes, afin que RTP/AVP et RTP/AVPF utilisent la même période d'expiration. Cependant, le comportement décrit dans la Section 7.1.1 montre que les intervalles de rapport RTP/AVPF réels peuvent être plus longs que prévu. Fixer T_rr_interval = 4 secondes donne des intervalles RTCP réels proches de ceux attendus par RTP/AVP, ce qui garantit l'interopérabilité.

7.1.4. Règles mises à jour d'expiration des SSRC

Pour garantir l'interopérabilité et éviter les expirations prématurées, tous les SSRC d'une session RTP DOIVENT (MUST) utiliser le même comportement d'expiration. Cependant, les spécifications précédentes sont incohérentes à cet égard. Afin d'éviter les problèmes d'interopérabilité, ce mémo met à jour les règles d'expiration comme suit :

• Pour les profils RTP/AVP, RTP/SAVP, RTP/AVPF et RTP/SAVPF, l'intervalle d'expiration DOIT (SHALL) être calculé à l'aide d'un multiplicateur de cinq fois l'intervalle de rapport RTCP déterministe. Autrement dit, l'intervalle d'expiration DOIT (SHALL) être 5*Td.
• Pour les profils RTP/AVP, RTP/SAVP, RTP/AVPF et RTP/SAVPF, le calcul de Td, aux seules fins du calcul de l'expiration d'un participant, DOIT (SHALL) être effectué avec une valeur de Tmin de 5 secondes et non avec l'intervalle minimal réduit, même si l'intervalle minimal réduit est utilisé pour calculer les intervalles de transmission des paquets RTCP.

Cela modifie le comportement des profils RTP/AVPF ou RTP/SAVPF lorsque T_rr_interval != 0. Plus précisément, le premier paragraphe de la Section 3.5.4 du [RFC4585] est mis à jour pour utiliser Tmin au lieu de T_rr_interval dans le calcul de l'expiration pour les entités RTP/AVPF.

7.2. Réglage des transmissions RTCP

Ce sous-paragraphe examine les réglages qui peuvent être effectués pour réduire les inconvénients des intervalles de paquets RTCP partagés. D'abord, les possibilités existantes pour le profil RTP/AVP [RFC3551] sont énumérées, puis les outils supplémentaires fournis par RTP/AVPF [RFC4585].

7.2.1. RTP/AVP et RTP/SAVP

Lors de l'utilisation des profils RTP/AVP ou RTP/SAVP, les options de réglage des intervalles de rapport RTCP se limitent à la bande passante des émetteurs et des récepteurs RTCP, et au fait de savoir si l'intervalle RTCP minimal est mis à l'échelle en fonction de la bande passante. Comme l'algorithme d'ordonnancement inclut à la fois la randomisation et la reconsidération, on ne peut pas simplement calculer l'intervalle de transmission moyen attendu à l'aide de la formule de Td donnée dans la Section 6.3.1 du [RFC3550]. Cependant, en examinant les entrées de cette expression, ainsi que les règles de randomisation et de reconsidération, nous pouvons commencer à comprendre le comportement de l'intervalle de transmission RTCP.

Commençons par quelques observations de base :

1. Sauf si l'intervalle RTCP minimal mis à l'échelle est utilisé, Td, avant randomisation et reconsidération, ne peut jamais être inférieur à Tmin. La valeur par défaut de Tmin est de 5 secondes.
2. Si l'intervalle RTCP minimal mis à l'échelle est utilisé, Td peut descendre jusqu'à 360 divisé par la bande passante de la session RTP en kilobits par seconde. Dans SDP, la bande passante de la session RTP est signalée à l'aide d'une ligne « b=AS ». Une bande passante de session RTP de 72 kbps fait que Tmin vaut 5 secondes. Une bande passante de session RTP de 360 kbps donne bien sûr un Tmin de 1 seconde, et pour obtenir un Tmin égal à une fois par image pour un flux vidéo à 25 images par seconde, il faut une bande passante de session RTP de 9 Mbps. L'utilisation du profil RTP/AVPF ou RTP/SAVPF permet des rapports RTCP plus fréquents pour une même bande passante, comme discuté ci-dessous.
3. La valeur de Td évolue avec le nombre de SSRC et la taille moyenne des rapports RTCP afin de maintenir constante la bande passante RTCP globale.
4. L'intervalle de transmission réel pour une valeur de Td se situe dans l'intervalle [0.5Td/1.21828, 1.5Td/1.21828], et la distribution est biaisée, en raison de la reconsidération, la majeure partie de la masse de probabilité se situant au-dessus de Td. Cela signifie, par exemple, que pour Td = 5 s, l'intervalle de transmission réel sera distribué dans l'intervalle [2.052 s, 6.156 s], avec une tendance vers la moitié supérieure de l'intervalle. Notez que le paramètre Tmin limite la valeur de Td avant que la randomisation et la reconsidération ne soient appliquées, de sorte que l'intervalle de transmission réel couvrira une plage s'étendant en dessous de Tmin.

Compte tenu de ce qui précède, nous pouvons calculer le nombre de SSRC, n, qu'une session RTP avec 5 % de la bande passante de session affectée à RTCP peut prendre en charge tout en maintenant Td égal à Tmin. Cela nous indiquera sur combien de flux RTP nous pouvons rendre compte, en maintenant le surdébit RTCP dans des limites acceptables. Nous faisons deux hypothèses qui simplifient le calcul : que tous les SSRC sont des émetteurs, et qu'ils envoient tous des paquets RTCP composés comprenant un paquet SR avec n-1 blocs de rapport, suivi d'un paquet SDES contenant une valeur de CNAME de 16 octets [RFC7022] (ces paquets RTCP varieront en taille entre 54 et 798 octets selon n, jusqu'au maximum de 31 blocs de rapport pouvant être inclus dans un paquet SR). Si nous introduisons cette taille de paquet, ainsi qu'une fraction de bande passante RTCP de 5 %, dans le calcul de l'intervalle RTCP de la Section 6.3.1 du [RFC3550], et que nous calculons la valeur de n nécessaire pour donner Td = Tmin pour l'intervalle minimal mis à l'échelle, nous trouvons que n=9 SSRC peuvent être pris en charge (indépendamment de l'intervalle, en raison de la manière dont l'intervalle de rapport évolue avec la bande passante de session). Nous constatons que pour prendre en charge davantage de SSRC sans modifier l'intervalle minimal mis à l'échelle, nous devons augmenter la fraction de bande passante RTCP au-delà de 5 % ; modifier la bande passante de session vers une valeur plus élevée réduirait le Tmin. Cependant, si l'allocation par défaut de 5 % de la bande passante RTCP est utilisée, une augmentation permettra de prendre en charge davantage de SSRC pour une cible de Td fixée.

Sur la base de ce qui précède, lors de l'utilisation du profil RTP/AVP ou du profil RTP/SAVP, la limitation clé pour des rapports RTCP rapides dans les petites sessions unicast sera la valeur de Tmin. La bande passante de session RTP configurée dans RTCP doit être suffisamment élevée pour atteindre les objectifs de rapport de l'application, en suivant les règles relatives à l'intervalle RTCP minimal mis à l'échelle.

7.2.2. RTP/AVPF et RTP/SAVPF

Lors de l'utilisation de RTP/AVPF ou RTP/SAVPF, nous disposons d'un outil supplémentaire puissant pour régler les transmissions RTCP : le paramètre T_rr_interval. L'utilisation de ce paramètre permet des intervalles de rapport RTCP courts ; alternativement, il offre la possibilité d'envoyer fréquemment un retour RTCP sans envoyer fréquemment de rapports RTCP réguliers.

L'utilisation du profil RTP/AVPF ou RTP/SAVPF avec T_rr_interval fixé à une valeur supérieure à zéro mais inférieure à Tmin permet un retour RTCP plus fréquent que les profils RTP/AVP ou RTP/SAVP, pour une bande passante RTCP donnée. Cela se produit parce que Tmin est fixé à zéro après la transmission du rapport RTCP initial, ce qui fait que l'intervalle de rapport pour les paquets ultérieurs est déterminé par le calcul habituel fondé sur la bande passante RTCP, avec Tmin=0, et par le T_rr_interval. Cela a pour effet que nous ne sommes plus limités par l'intervalle minimal (qu'il s'agisse du minimum par défaut de 5 secondes ou de l'intervalle minimal réduit). Ce sont plutôt la bande passante RTCP et le T_rr_interval qui sont les facteurs déterminants, ce qui permet un retour plus rapide. Les applications qui tiennent à un retour RTCP régulier rapide devraient envisager d'utiliser le profil RTP/AVPF ou RTP/SAVPF, même si elles n'utilisent pas les fonctionnalités de retour de ce profil.

L'utilisation du profil RTP/AVPF ou RTP/SAVPF permet d'envoyer fréquemment des paquets de retour RTCP sans exiger pour autant l'envoi fréquent de rapports RTCP réguliers, puisque T_rr_interval limite la cadence à laquelle les paquets RTCP réguliers peuvent être envoyés, tout en permettant l'envoi de paquets de retour RTCP. Les applications qui peuvent utiliser des paquets de retour pour certains flux RTP, par exemple les flux vidéo, mais qui ne veulent pas de rapports réguliers fréquents pour d'autres flux RTP, peuvent configurer le T_rr_interval à une valeur telle que les rapports réguliers pour l'audio et la vidéo se situent à un niveau jugé acceptable pour l'audio. Elles pourraient alors utiliser des paquets de retour, qui incluront des paquets RTCP SR/RR sauf si des paquets de retour RTCP de taille réduite [RFC5506] sont utilisés, pour les rapports vidéo. Cela permet de consacrer la bande passante RTCP disponible au retour qui présente le plus d'utilité pour l'application.

L'utilisation de T_rr_interval exige encore de déterminer des valeurs appropriées pour la bande passante RTCP. De fait, cela peut rendre ce choix encore plus important, car il est plus susceptible d'affecter le comportement et les performances de RTCP que lors de l'utilisation du profil RTP/AVP ou RTP/SAVP, dans la mesure où moins de limitations affectent la transmission RTCP.

Lorsque T_rr_interval est non nul, certaines configurations doivent être évitées. Si la bande passante RTCP choisie est telle que la valeur de Td est inférieure à T_rr_interval, mais proche de celle-ci, alors l'intervalle de transmission réel des paquets RTCP réguliers peut devenir très grand, comme discuté dans la Section 7.1.1. Par conséquent, pour une configuration où l'on souhaite avoir Td inférieur à T_rr_interval, il est RECOMMANDÉ (RECOMMENDED) de viser pour Td des valeurs inférieures à 1/4 de T_rr_interval, ce qui fait que l'intervalle devient [0.5T_rr_interval, 1.81T_rr_interval].

Avec les profils RTP/AVPF ou RTP/SAVPF, l'utilisation de T_rr_interval = 0 est utile et conduit à un comportement où la transmission RTCP n'est limitée que par la bande passante, c'est-à-dire sans aucune limitation liée à Tmin. Cela permet des rapports RTCP réguliers plus fréquents que ce qui peut être obtenu avec le profil RTP/AVP. De nombreuses configurations de RTCP ne consommeront pas toute la bande passante qui leur a été configurée, mais cette configuration consommera ce qui lui a été donné. Notez que le même comportement sera obtenu tant que T_rr_interval est inférieur à 1/3 de Td, car cela empêche T_rr_interval d'affecter la transmission.

Il n'existe aucune méthode permettant d'utiliser des intervalles de rapport RTCP réguliers différents selon le type de média ou le flux RTP individuel, autre que l'utilisation d'une session RTP distincte pour chaque type ou flux.