5. Utilisation de RTCP par les points d'extrémité qui envoient plusieurs flux média

RTCP est défini dans la Section 6 du [RFC3550]. La description du protocole est formulée en termes de comportement des « participants » d'une session RTP, en supposant que chaque point d'extrémité est un participant doté d'un seul SSRC. Toutefois, pour un fonctionnement correct dans les cas où les points d'extrémité possèdent plusieurs valeurs de SSRC, les implémentations DOIVENT (MUST) traiter chaque SSRC comme un participant distinct de la session RTP, de sorte qu'un point d'extrémité qui possède plusieurs SSRC compte comme plusieurs participants.

5.1. Exigence de rapport RTCP

Un point d'extrémité RTP qui possède plusieurs SSRC DOIT (MUST) traiter chaque SSRC comme un participant distinct de la session RTP. Chaque SSRC maintiendra ses propres informations d'état liées à RTCP et, par conséquent, disposera de son propre intervalle de rapport RTCP qui détermine le moment où il envoie des rapports RTCP. Si le mécanisme de [MULTI-STREAM-OPT] n'est pas utilisé, alors chaque SSRC enverra des rapports RTCP pour tous les autres SSRC, y compris ceux colocalisés au même point d'extrémité.

Si le point d'extrémité possède certains SSRC qui envoient des données et d'autres qui ne sont que des récepteurs, alors ils recevront des parts différentes de la bande passante RTCP et calculeront des intervalles de rapport RTCP de base différents. Sinon, tous les SSRC d'un point d'extrémité calculeront le même intervalle de rapport RTCP de base. Les intervalles de rapport réels de chaque SSRC sont randomisés de la manière habituelle, mais les rapports peuvent être agrégés comme décrit dans la Section 5.3.

5.2. Intervalle de rapport initial

Lorsqu'un participant rejoint une session unicast, le texte suivant de la Section 6.2 du [RFC3550] est pertinent : « Pour les sessions unicast... le délai avant l'envoi du paquet RTCP composé initial PEUT (MAY) être nul. » L'hypothèse de base est que cela devrait également s'appliquer dans le cas de plusieurs SSRC. La prudence est toutefois de mise lorsqu'un point d'extrémité (ou un middlebox) doté d'un grand nombre de SSRC rejoint une session unicast, car la transmission immédiate de nombreux rapports RTCP peut créer une rafale de trafic importante, entraînant une congestion transitoire et des pertes de paquets dues à des débordements de file d'attente.

Pour garantir que la rafale de trafic initiale générée par un point d'extrémité RTP ne soit pas plus importante que celle qui serait générée par une connexion TCP, un point d'extrémité RTP NE DOIT PAS (MUST NOT) envoyer plus de quatre paquets RTCP composés avec un délai initial nul lorsqu'il rejoint une session RTP, indépendamment du nombre de SSRC utilisés par le point d'extrémité. Chacun de ces paquets RTCP composés initiaux PEUT (MAY) inclure des rapports agrégés provenant de plusieurs SSRC, à condition que la taille totale du paquet RTCP composé ne dépasse pas la MTU et que l'avg_rtcp_size soit maintenu comme indiqué dans la Section 5.3.1. L'agrégation de rapports provenant de plusieurs SSRC dans les paquets RTCP composés initiaux permet à un nombre substantiel de SSRC de rendre compte immédiatement. Les points d'extrémité DEVRAIENT (SHOULD) donner la priorité aux rapports sur les SSRC qui sont susceptibles d'être les plus immédiatement utiles, par exemple pour les SSRC qui sont initialement des émetteurs.

Un point d'extrémité qui doit rendre compte d'un nombre de SSRC supérieur à ce qui tiendra dans les quatre rapports RTCP composés pouvant être envoyés immédiatement DOIT (MUST) envoyer les autres rapports plus tard, en suivant les règles habituelles de temporisation RTCP, y compris la reconsidération du minuteur. Ces rapports PEUVENT (MAY) être agrégés comme décrit dans la Section 5.3.

Remarque : ce qui précède est choisi pour correspondre à la fenêtre initiale maximale TCP de quatre paquets [RFC3390], et non aux fenêtres initiales TCP plus grandes pour lesquelles une expérimentation est en cours [RFC6928]. La raison en est un souhait d'être conservateur, puisqu'un point d'extrémité RTP commencera aussi, dans de nombreux cas, à envoyer des paquets de données RTP en même temps que ces paquets RTCP initiaux sont envoyés.

5.3. Agrégation des rapports en paquets RTCP composés

Comme indiqué dans la Section 5.1, un point d'extrémité doté de plusieurs SSRC doit traiter chaque SSRC comme un participant distinct lorsqu'il s'agit d'envoyer des rapports RTCP. Cela conduira chaque SSRC à envoyer un paquet RTCP composé à chaque intervalle de rapport. Comme ces paquets proviennent du même point d'extrémité, on pourrait raisonnablement s'attendre à ce qu'ils puissent être agrégés afin de réduire le surdébit. De fait, la Section 6.1 du [RFC3550] autorise les traducteurs et les mélangeurs RTP à agréger des paquets dans des circonstances similaires :

Il est RECOMMANDÉ (RECOMMENDED) que les traducteurs et les mélangeurs combinent les paquets RTCP individuels provenant des multiples sources qu'ils transfèrent en un seul paquet composé chaque fois que cela est possible, afin d'amortir le surdébit des paquets (voir la Section 7). Un exemple de paquet RTCP composé tel qu'il pourrait être produit par un mélangeur est présenté à la figure 1. Si la longueur globale d'un paquet composé devait dépasser la MTU du chemin réseau, il DEVRAIT (SHOULD) être segmenté en plusieurs paquets composés plus courts à transmettre dans des paquets séparés du protocole sous-jacent. Cela ne dégrade pas l'estimation de la bande passante RTCP, car chaque paquet composé représente au moins un participant distinct. Notez que chacun des paquets composés DOIT (MUST) commencer par un paquet SR ou RR.

Cela permet aux traducteurs et aux mélangeurs RTP de générer des paquets RTCP composés qui contiennent plusieurs paquets de rapport d'émetteur (Sender Report, SR) ou de rapport de récepteur (Receiver Report, RR) provenant de différents SSRC, ainsi que n'importe lequel des autres types de paquets. Il n'y a aucune restriction sur l'ordre dans lequel les paquets RTCP peuvent apparaître au sein du paquet composé, hormis la règle habituelle selon laquelle le paquet RTCP composé commence par un paquet SR ou RR. En raison de cette règle, les points d'extrémité RTP correctement implémentés seront capables de traiter les paquets RTCP composés qui contiennent des paquets RTCP relatifs à plusieurs SSRC.

En conséquence, les points d'extrémité qui utilisent plusieurs SSRC peuvent agréger les paquets RTCP envoyés par leurs différents SSRC en paquets RTCP composés, à condition 1) que les paquets RTCP composés résultants commencent par un paquet SR ou RR, 2) qu'ils maintiennent la taille moyenne des paquets RTCP comme décrit dans la Section 5.3.1, et 3) qu'ils ordonnancent la transmission des paquets et gèrent l'agrégation comme décrit dans la Section 5.3.2.

5.3.1. Maintien de AVG_RTCP_SIZE

L'algorithme d'ordonnancement RTCP du [RFC3550] fonctionne sur une base par SSRC. Chaque SSRC envoie un seul paquet RTCP composé à chaque intervalle de rapport RTCP. Lorsqu'un point d'extrémité utilise plusieurs SSRC, il est souhaitable d'agréger les paquets RTCP composés envoyés par ses SSRC, ce qui réduit le surdébit en formant un paquet RTCP composé plus grand. Cette agrégation peut être effectuée comme décrit dans la Section 5.3.2, à condition que le calcul de la taille moyenne des paquets RTCP soit mis à jour comme suit.

Les participants d'une session RTP mettent à jour leur estimation de la taille moyenne des paquets RTCP (avg_rtcp_size) chaque fois qu'ils envoient ou reçoivent un paquet RTCP (voir la Section 6.3.3 du [RFC3550]). Lorsqu'un paquet RTCP composé qui contient des paquets RTCP provenant de plusieurs SSRC est envoyé ou reçu, l'estimation avg_rtcp_size de chaque SSRC faisant l'objet du rapport est mise à jour à l'aide de div_packet_size plutôt que de la taille réelle du paquet :

avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size

où div_packet_size est packet_size divisé par le nombre de SSRC qui rendent compte dans ce paquet composé. Le nombre de SSRC qui rendent compte dans un paquet composé est déterminé en comptant le nombre de SSRC différents qui sont à l'origine de paquets RTCP SR ou RR au sein du paquet RTCP composé. Les paquets RTCP non composés (c'est-à-dire les paquets RTCP qui ne contiennent pas de paquet SR ou RR [RFC5506]) sont considérés comme rendant compte d'un seul SSRC.

Un participant qui ne suit pas la règle ci-dessus et utilise à la place la taille complète du paquet RTCP composé pour calculer avg_rtcp_size obtiendra un intervalle de rapport RTCP excessivement grand, d'un facteur proportionnel au nombre de SSRC agrégés dans les paquets RTCP composés et à la taille de l'ensemble de SSRC agrégés par rapport au nombre total de participants. Cet intervalle de rapport RTCP accru peut provoquer des expirations prématurées s'il est supérieur à cinq fois l'intervalle choisi par les SSRC qui comprennent le RTCP composé et agrègent les rapports de nombreux SSRC. Une MTU de 1500 octets peut contenir cinq rapports de taille typique dans un paquet RTCP composé, ce qui constitue donc une préoccupation réelle si les points d'extrémité agrègent des rapports RTCP provenant de plusieurs SSRC.

Le problème soulevé au paragraphe précédent est atténué par la modification du comportement d'expiration spécifiée dans la Section 7.1.2 de ce mémo. Cette atténuation est en place dans les cas où la bande passante RTCP est suffisamment élevée pour qu'un point d'extrémité, utilisant un avg_rtcp_size calculé sans tenir compte du nombre de SSRC qui rendent compte, puisse transmettre plus fréquemment qu'environ toutes les 5 secondes. Notez toutefois que les rapports RTCP du point d'extrémité non mis à jour restent affectés négativement, même si les expirations prématurées de ses SSRC sont évitées. Si la compatibilité avec des points d'extrémité non mis à jour est une préoccupation, le nombre de rapports provenant de différents SSRC agrégés dans un seul paquet RTCP composé DEVRAIT (SHOULD) soit être limité à deux rapports, soit ne pas utiliser d'agrégation du tout. Cela limitera l'intervalle de rapport RTCP du point d'extrémité non mis à jour à un maximum de deux fois l'intervalle de rapport RTCP qui serait choisi par un point d'extrémité suivant cette spécification.

5.3.2. Ordonnancement de RTCP lors de l'agrégation de plusieurs SSRC

Cette section révise et étend le comportement défini dans la Section 6.3 du [RFC3550], et dans la Section 3.5.3 du [RFC4585] si le profil RTP/AVPF ou le profil RTP/SAVPF est utilisé, concernant les actions à entreprendre lors de l'ordonnancement et de l'envoi de paquets RTCP lorsque plusieurs SSRC qui rendent compte agrègent leurs paquets RTCP dans le même paquet RTCP composé. Ces modifications des règles d'ordonnancement RTCP sont nécessaires pour maintenir des propriétés de temporisation RTCP importantes, notamment la distribution entre paquets, ainsi que le comportement lors d'arrivées massives (flash joins) et d'autres changements dans la composition de la session.

Les variables tn, tp, tc, T et Td utilisées ci-après sont définies dans la Section 6.3 du [RFC3550]. Les variables T_rr_interval et T_rr_last sont définies dans le [RFC4585].

Chaque point d'extrémité DOIT (MUST) ordonnancer la transmission RTCP indépendamment pour chacun de ses SSRC, en utilisant le calcul habituel de tn pour le profil RTP utilisé. Chaque fois que le minuteur tn expire pour un SSRC, le point d'extrémité DOIT (MUST) effectuer une reconsidération du minuteur RTCP et, le cas échéant, une suppression fondée sur T_rr_interval. Si le résultat indique qu'un paquet RTCP composé doit être envoyé par ce SSRC, et que la transmission n'est pas un paquet RTCP anticipé [RFC4585], alors le point d'extrémité DEVRAIT (SHOULD) tenter d'agréger dans le paquet RTCP composé les paquets RTCP d'autres SSRC dont l'envoi est prévu dans le futur, avant que ce paquet ne soit envoyé. La raison de limiter ou de ne pas effectuer l'agrégation pour des raisons de compatibilité ascendante est discutée dans la Section 5.3.1.

L'agrégation se déroule comme suit. Le point d'extrémité sélectionne le SSRC dont la valeur de tn est la plus petite après l'heure courante, tc, et prépare les paquets RTCP que ce SSRC enverrait si son minuteur tn expirait à tc. Si ces paquets RTCP tiennent dans le paquet RTCP composé en cours de génération, compte tenu de la MTU du chemin et des paquets RTCP ajoutés précédemment, alors ils sont ajoutés au paquet RTCP composé ; sinon, ils sont rejetés. Ce processus est répété pour chaque SSRC, par ordre croissant de tn, jusqu'à ce que le paquet RTCP composé soit plein ou que tous les SSRC aient été agrégés. À ce moment-là, le paquet RTCP composé est envoyé.

Lorsque le paquet RTCP composé est envoyé, le point d'extrémité DOIT (MUST) mettre à jour tp, tn et T_rr_last (le cas échéant) pour chaque SSRC qui a été inclus. Ces variables sont mises à jour comme suit :

1. Pour le premier SSRC qui a rendu compte dans le paquet RTCP composé, fixer à tc l'heure de transmission effective, tt, de ce SSRC.
2. Pour chaque SSRC supplémentaire qui a rendu compte dans le paquet RTCP composé, calculer l'heure de transmission que ce SSRC aurait eue s'il n'avait pas été agrégé dans le paquet RTCP composé. Celle-ci est obtenue en prenant tn pour ce SSRC, puis en effectuant la reconsidération et en mettant à jour tn jusqu'à ce que tp + T <= tn. Une fois cela fait, fixer à la valeur calculée de tn l'heure de transmission effective, tt, de ce SSRC. Si le profil RTP/AVPF ou le profil RTP/SAVPF est utilisé, alors la suppression fondée sur T_rr_interval NE DOIT PAS (MUST NOT) être utilisée dans ce calcul.
3. Calculer l'heure de transmission effective moyenne, tt_avg, pour le paquet RTCP composé à partir des valeurs de tt de tous les SSRC envoyés dans le paquet RTCP composé. Fixer à tt_avg la valeur de tp pour chacun des SSRC envoyés dans le paquet RTCP composé. Si le profil RTP/AVPF ou le profil RTP/SAVPF est utilisé, fixer à tt_avg la valeur de T_tt_last pour chaque SSRC envoyé dans le paquet RTCP composé.
4. Pour chacun des SSRC envoyés dans le paquet RTCP composé, calculer de nouvelles valeurs de tn à partir des paramètres mis à jour et des règles habituelles de temporisation RTCP, puis replanifier les minuteurs.

Lors de l'utilisation du profil RTP/AVPF ou du profil RTP/SAVPF, le mécanisme ci-dessus ne tente d'agréger les paquets RTCP que lorsque le paquet RTCP composé à envoyer n'est pas un paquet RTCP anticipé, et l'algorithme de la Section 3.5.3 du [RFC4585] contrôle donc l'ordonnancement RTCP. Si T_rr_interval == 0, ou si T_rr_interval != 0 et que l'option 1, 2a ou 2b de l'algorithme est choisie, alors le mécanisme ci-dessus met à jour les variables nécessaires. Cependant, si la transmission est supprimée conformément à l'option 2c de l'algorithme, alors tp est mis à jour à tc, car l'agrégation n'a pas eu lieu.

La reconsidération inverse DOIT (MUST) être effectuée conformément à la Section 6.3.4 du [RFC3550]. Dans certains cas, cela peut conduire à ce que la valeur de tp après la reconsidération inverse soit supérieure à tc. Ce n'est pas un problème, et cela a l'effet souhaité de rapprocher proportionnellement la valeur de tp de tc (ainsi que tn) à mesure que l'intervalle de rapport se réduit, en proportion directe de la taille de groupe réduite.

Il a été démontré par des simulations [Sim88] [Sim92] que l'algorithme ci-dessus maintient la distribution des temps de transmission entre paquets RTCP pour chaque SSRC et consomme la même quantité de bande passante que des paquets RTCP non agrégés. Avec cet algorithme, l'intervalle de transmission réel d'un SSRC déclenchant une transmission de paquet RTCP composé suit les règles de transmission habituelles. La valeur tp est fixée quelque part dans l'intervalle [0, 1.5/1.21828*Td] en avance sur tc. La valeur réelle est la moyenne d'une occurrence de tc et des heures de transmission randomisées des SSRC supplémentaires ; ainsi, la borne inférieure de l'intervalle est plus probable. Cela compense le biais qui serait autrement introduit en choisissant la plus petite valeur de tn parmi les N SSRC inclus dans l'agrégat.

L'algorithme gère également les cas où le nombre de SSRC pouvant être inclus dans un paquet agrégé varie. Un SSRC qui était auparavant agrégé et qui ne tient plus dans un paquet a toujours sa propre transmission planifiée selon les règles normales. Ainsi, il déclenchera une transmission en temps voulu, ou le SSRC sera inclus dans un autre agrégat. Le comportement de l'algorithme face aux changements de taille du groupe de SSRC est le suivant :

Sessions RTP où le nombre de SSRC augmente : lorsque la taille du groupe augmente, Td croît proportionnellement au nombre de nouveaux SSRC dans le groupe. Lorsque la reconsidération est effectuée en raison de l'expiration du minuteur tn, ce SSRC reconsidérera la transmission et, avec une certaine probabilité, replanifiera le minuteur tn. Cette partie de l'algorithme de reconsidération n'est affectée par l'algorithme ci-dessus que du fait que les valeurs de tp étaient dans le futur au lieu d'être fixées à l'heure de la dernière transmission réelle au moment de la mise à jour de tp.

Sessions RTP où le nombre de SSRC diminue : lorsque le groupe se réduit, la reconsidération inverse rapproche les valeurs de tp et tn de tc proportionnellement au nombre de SSRC qui quittent la session par rapport au nombre total de participants au moment de leur départ. On pourrait croire que le fait de fixer la valeur de tp dans le futur par rapport à tc a un effet négatif. Cependant, la raison de ce réglage est de compenser le biais causé par le choix de la plus petite valeur de tn parmi les N valeurs agrégées. Ce biais subsiste lors d'une réduction du nombre de SSRC. La reconsidération inverse compense la réduction indépendamment du fait que l'agrégation soit utilisée ou non. L'effet négatif pouvant survenir lors de la suppression d'un SSRC est que la valeur de tn la plus favorable appartenait au SSRC supprimé. Son impact se limite à retarder la transmission, dans le pire des cas, d'un intervalle de rapport.

En conclusion, les investigations menées n'ont trouvé aucun impact négatif significatif sur l'algorithme d'ordonnancement.

5.4. Utilisation du retour RTP/AVPF ou RTP/SAVPF

Cette section traite de la transmission de paquets de retour RTP/AVPF lorsque le point d'extrémité émetteur possède plusieurs SSRC. Les directives de cette section s'appliquent également aux points d'extrémité utilisant le profil RTP/SAVPF.

5.4.1. Choix du SSRC pour les paquets de retour

Lorsqu'un point d'extrémité RTP/AVPF possède plusieurs SSRC, il peut choisir le SSRC à utiliser comme source des paquets de retour RTCP qu'il envoie. Plusieurs facteurs peuvent influer sur ce choix :

• Les paquets de retour RTCP relatifs à un type de média particulier DEVRAIENT (SHOULD) être envoyés par un SSRC qui reçoit ce type de média. Par exemple, lorsque l'audio et la vidéo sont multiplexés dans une seule session RTP, les points d'extrémité utiliseront leur SSRC audio pour envoyer un retour sur l'audio reçu d'autres participants.
• Les paquets de retour RTCP et les messages de contrôle de codec RTCP qui sont des notifications ou des indications concernant des données RTP traitées par un point d'extrémité DOIVENT (MUST) être envoyés depuis le SSRC utilisé pour ces données RTP. Cela inclut les notifications relatives à une demande ou à une commande reçue précédemment [RFC4585][RFC5104].
• Si des SSRC distincts sont utilisés pour envoyer et recevoir des médias, alors le SSRC correspondant DEVRAIT (SHOULD) être utilisé pour le retour, car ils ont des fractions de bande passante RTCP différentes. Cela peut aussi affecter la question de savoir si le SSRC peut être utilisé en mode immédiat.
• Certains types de paquets de retour RTCP exigent une cohérence du SSRC utilisé. Par exemple, si une limitation de demande temporaire de débit maximal de flux média (Temporary Maximum Media Stream Bit Rate Request, TMMBR) [RFC5104] est définie par un SSRC, le même SSRC doit être utilisé pour lever cette limitation.
• Si plusieurs SSRC conviennent pour envoyer un retour, il peut être souhaitable d'utiliser un SSRC qui permet l'envoi du retour sous forme de paquet RTCP anticipé.

Lorsqu'un paquet de retour RTCP est envoyé dans le cadre d'un paquet RTCP composé qui agrège des rapports provenant de plusieurs SSRC, rien n'exige que le paquet composé contienne un paquet SR ou RR généré par l'émetteur du paquet de retour RTCP. Pour les paquets RTCP de taille réduite, l'agrégation de paquets de retour RTCP provenant de plusieurs sources n'est pas limitée davantage que par la Section 4.2.2 du [RFC5506].

5.4.2. Ordonnancement d'un paquet de retour RTCP

Lorsqu'un SSRC a besoin de transmettre un paquet de retour en mode anticipé, il DOIT (MUST) ordonnancer ce paquet en suivant l'algorithme de la Section 3.5 du [RFC4585], modifié comme suit :

• Pour déterminer si une session RTP est considérée comme une session point à point ou une session multipartite, un point d'extrémité DOIT (MUST) compter le nombre de valeurs de CNAME SDES RTCP distinctes utilisées par les SSRC listés dans le champ SSRC des paquets de données RTP qu'il reçoit et dans le champ « SSRC of sender » des paquets RTCP SR, RR, RTPFB ou PSFB qu'il reçoit. Une session RTP est considérée comme une session multipartite si plus d'un CNAME est utilisé par ces SSRC, sauf si la signalisation indique que la session doit être traitée comme point à point ou si des groupes de rapport RTCP [MULTI-STREAM-OPT] sont utilisés. Si des groupes de rapport RTCP sont utilisés, une session RTP est considérée comme une session point à point si le point d'extrémité ne reçoit qu'un seul groupe de rapport, et est considérée comme une session multipartite si plusieurs groupes de rapport sont reçus, ou si une combinaison de groupes de rapport et de SSRC ne faisant pas partie d'un groupe de rapport est reçue. Les points d'extrémité NE DOIVENT PAS (MUST NOT) déterminer si une session RTP est multipartite ou point à point en se fondant sur le type de connexion (unicast ou multicast) utilisé, ni sur le nombre de SSRC reçus.
• Lorsqu'il s'agit de vérifier s'il existe déjà un paquet RTCP composé planifié contenant des messages de retour (étape 2 de la Section 3.5.2 du [RFC4585]), cette vérification DOIT (MUST) être effectuée en tenant compte de tous les SSRC locaux.
• Si un SSRC n'est pas autorisé à envoyer un paquet RTCP anticipé, alors le message de retour PEUT (MAY) être mis en file d'attente pour être transmis dans le cadre de toute transmission anticipée ou planifiée régulière pouvant survenir dans la durée de vie utile maximale du message de retour (T_max_fb_delay). Cela modifie le comportement décrit au point 4a de la Section 3.5.2 du [RFC4585].

Le premier point ci-dessus spécifie une règle permettant de déterminer si une session RTP doit être considérée comme une session point à point ou comme une session multipartite. Cette règle est simple à implémenter, mais il est connu qu'elle classe incorrectement certaines sessions comme des sessions multipartites. Les problèmes connus sont les suivants :

Point d'extrémité doté de plusieurs contextes de synchronisation : un point d'extrémité faisant partie d'une session point à point peut avoir plusieurs contextes de synchronisation, par exemple du fait du transfert d'une source média externe vers une conversation interactive en temps réel. Dans ce cas, la classification considérera le pair comme deux points d'extrémité, alors que la transmission RTP/RTCP réelle sera sous le contrôle d'un seul point d'extrémité.

Middlebox de transfert sélectif : le middlebox de transfert sélectif (Selective Forwarding Middlebox, SFM) tel que défini dans la Section 3.7 du [RFC7667] contrôle la transmission et les configurations entre lui-même et chaque point d'extrémité pair individuellement. Il contrôle également entièrement les paquets RTCP transférés entre les différentes branches. Ainsi, ce type de middlebox peut être comparé au mélangeur RTP, qui utilise ses propres SSRC pour mélanger ou sélectionner les médias qu'il transfère, et qui sera classé comme une session RTP point à point par la règle ci-dessus.

Dans les cas ci-dessus, il est tout à fait raisonnable d'utiliser des groupes de rapport RTCP [MULTI-STREAM-OPT]. Si cette extension est utilisée, un point d'extrémité peut indiquer que la multitude de CNAME relève en fait du contrôle d'un seul point d'extrémité ou middlebox en n'utilisant qu'un seul groupe de rapport.

Les règles ci-dessus classeront également comme point à point certaines sessions où le point d'extrémité est connecté à un mélangeur RTP. Par exemple, le mélangeur pourrait agir comme passerelle vers une session RTP fondée sur le multicast à source unique (Any Source Multicast) pour le point d'extrémité considéré. Cependant, cela sera, dans la plupart des cas, acceptable, car le mélangeur RTP assure une séparation entre les deux parties de la session. Il incombe au mélangeur d'agir en conséquence dans chaque domaine.

Enfin, nous notons que des mécanismes de signalisation pourraient être définis pour remplacer ces règles lorsqu'elles conduiraient à une classification erronée.