3.4. Définitions et aperçu de l'algorithme (Definitions and Algorithm Overview)

Les éléments d'état suivants doivent être maintenus par récepteur (largement repris de [1]). Notez que toutes les variables (sauf au point h) ci-dessous) sont calculées indépendamment à chaque récepteur. Par conséquent, leurs valeurs locales peuvent différer à un instant donné.

a) Soit senders le nombre d'émetteurs actifs dans la session RTP.

b) Soit members l'estimation courante du nombre de récepteurs dans la session RTP.

c) Soient tn et tp les instants de la prochaine (respectivement dernière) transmission RTCP RR planifiée, calculés avant la reconsideration du temporisateur.

d) Soit Tmin l'intervalle minimal entre paquets RTCP selon [1]. Contrairement à [1], la valeur initiale de Tmin est fixée à 1 seconde pour permettre un échantillonnage de la taille du groupe avant le premier paquet RTCP. Après l'envoi du premier paquet RTCP, Tmin est mis à 0.

e) Soit T_rr l'intervalle après lequel, venant d'envoyer un paquet RTCP régulier planifié, un récepteur planifierait l'envoi de son prochain paquet RTCP régulier. Cette valeur est obtenue selon les règles de [1] mais avec Tmin tel que défini dans le présent document : T_rr = T (l'« intervalle calculé » défini dans [1]) avec tn = tp + T. T_rr désigne toujours la dernière valeur de T calculée (en raison de la reconsideration ou pour déterminer tn). T_rr est aussi appelé intervalle RTCP régulier (Regular RTCP interval) dans ce document.

f) Soit t0 l'instant auquel un événement à signaler est détecté par un récepteur.

g) Soit T_dither_max l'intervalle maximal pendant lequel un paquet de feedback RTCP MAY être retardé en plus pour éviter les implosions dans les sessions multipoint ; la valeur de T_dither_max est calculée dynamiquement à partir de T_rr (ou MAY être dérivée par un autre mécanisme commun à tous les récepteurs RTP à spécifier ultérieurement). Pour les sessions point à point (c'est-à-dire avec exactement deux membres sans changement de taille de groupe attendu, par ex. streaming unicast), T_dither_max est fixé à 0.

h) Soit T_max_fb_delay la borne supérieure dans laquelle le feedback relatif à un événement doit être rapporté à l'émetteur pour rester utile. Cette valeur est propre à l'application ; aucune valeur n'est définie dans ce document.

i) Soit te l'instant auquel un paquet de feedback est planifié.

j) Soit T_fd le délai réel (randomisé) pour la transmission d'un message FB en réponse à un événement à l'instant t0.

k) Soit allow_early une variable booléenne indiquant si le récepteur peut transmettre des messages FB avant son prochain intervalle RTCP régulier planifié tn. Cette variable sert à limiter le feedback d'un seul récepteur. allow_early est mis à FALSE après une transmission de feedback anticipé et à TRUE dès que la prochaine transmission RTCP régulière a lieu.

l) Soit avg_rtcp_size la moyenne mobile de la taille des paquets RTCP telle que définie dans [1].

m) Soit T_rr_interval un intervalle minimal OPTIONNEL entre paquets RTCP réguliers. Si T_rr_interval == 0, cette variable n'a pas d'impact sur le fonctionnement global de l'algorithme de feedback RTCP. Si T_rr_interval != 0, le prochain paquet RTCP régulier n'est pas planifié T_rr après la dernière transmission RTCP régulière (c'est-à-dire à tp+T_rr). À la place, le prochain paquet RTCP régulier est retardé d'au moins T_rr_interval après la dernière transmission RTCP régulière, c'est-à-dire planifié à ou après tp+T_rr_interval. Notez que T_rr_interval n'affecte pas le calcul de T_rr et tp ; les paquets RTCP réguliers planifiés avant tp+T_rr_interval seront supprimés s'ils ne contiennent par exemple aucun message FB. T_rr_interval n'affecte pas la planification des paquets RTCP anticipés.

Note : Fournir T_rr_interval comme variable indépendante vise à minimiser le feedback RTCP régulier (et donc la consommation de bande passante) selon les besoins de l'application tout en permettant des paquets RTCP anticipés plus fréquents pour un feedback opportun. Cet objectif ne pourrait pas être atteint en réduisant la bande passante RTCP globale, car une telle réduction impacterait aussi la fréquence du feedback anticipé.

n) Soit t_rr_last l'instant auquel le dernier paquet RTCP régulier a été planifié et envoyé, c'est-à-dire n'a pas été supprimé en raison de T_rr_interval.

o) Soit T_retention la fenêtre temporelle pendant laquelle les messages FB passés sont stockés par une entité AVPF. Cela garantit que la suppression du feedback fonctionne aussi pour les entités ayant reçu des messages FB d'autres entités avant de constater elles-mêmes l'événement de feedback. T_retention MUST être d'au moins 2 secondes.

p) Soit M*Td la valeur de temporisation au-delà de laquelle un récepteur est considéré inactif (tel que défini dans [1]).

La situation de feedback pour un événement à signaler chez un récepteur est illustrée à la figure 2. À l'instant t0, un tel événement (par ex. une perte de paquet) est détecté. Le récepteur décide — en fonction de la bande passante, de la taille du groupe et d'autres paramètres propres à l'application — qu'un message FB doit être renvoyé à l'émetteur.

Pour éviter une implosion de paquets de feedback en sessions multipoint, le récepteur MUST retarder la transmission du paquet de feedback RTCP d'une durée aléatoire T_fd (nombre aléatoire uniformément distribué dans l'intervalle [0, T_dither_max]). La transmission du paquet RTCP composé MUST alors être planifiée pour te = t0 + T_fd.

Le paramètre T_dither_max est dérivé de l'intervalle RTCP régulier T_rr, lui-même fondé sur la taille du groupe. Un document ultérieur MAY spécifier d'autres calculs pour T_dither_max (par ex. basés sur l'aller-retour) s'il peut être garanti que tous les récepteurs RTP utiliseront le même mécanisme.

Pour un scénario d'application donné, un récepteur MAY déterminer une borne supérieure au délai local acceptable des messages FB : T_max_fb_delay. Si une estimation a priori ou le calcul effectif de T_dither_max indique que cette borne MAY être violée (par ex. parce que T_dither_max > T_max_fb_delay), le récepteur MAY décider de n'envoyer aucun feedback, le gain étant jugé insuffisant.

Si un paquet RTCP anticipé est planifié, le créneau pour le prochain paquet RTCP régulier MUST être mis à jour en conséquence avec un nouveau tn (tn=tp+2*T_rr) puis un nouveau tp (tp=tp+T_rr). Cela garantit que la bande passante RTCP moyenne à court terme avec feedback anticipé ne dépasse pas celle sans feedback anticipé.

            event to
            report
            detected
               |
               |  RTCP feedback range
               |   (T_max_fb_delay)
               vXXXXXXXXXXXXXXXXXXXXXXXXXXX     ) )
|---+--------+-------------+-----+------------| |--------+--->
    |        |             |     |            ( (        |
    |       t0            te                             |
    tp                                                   tn
              \_______  ________/
                      \/
                T_dither_max

     Figure 2: Event report and parameters for Early RTCP scheduling