3.5. Algorithme de planification RTCP AVPF (AVPF RTCP Scheduling Algorithm)

Soit S0 un émetteur actif (parmi S émetteurs) et N le nombre de récepteurs, R étant l'un d'eux.

On suppose que R a vérifié que l'usage de mécanismes de feedback est raisonnable dans la constellation actuelle (ce qui est très dépendant de l'application et n'est donc pas spécifié ici).

On suppose en outre que T_rr_interval vaut 0 si aucun intervalle minimal entre paquets RTCP réguliers n'est imposé, ou que T_rr_interval est fixé à une valeur pertinente par l'application. Cette valeur désigne alors l'intervalle minimal entre paquets RTCP réguliers.

Avec cela, un récepteur R MUST appliquer les règles suivantes pour transmettre un ou plusieurs messages FB comme paquet RTCP composé minimal ou complet.

3.5.1. Initialisation

Initialement, R MUST fixer allow_early = TRUE et t_rr_last = NaN (Not-a-Number, c'est-à-dire une valeur invalide distinguable d'un temps valide).

De plus, l'initialisation des variables RTCP selon [1] s'applique, sauf pour la valeur initiale de Tmin. Pour une session point à point, Tmin initial vaut 0. Pour une session multipoint, Tmin est initialisé à 1,0 seconde.

3.5.2. Transmission de feedback anticipé

Supposons que R ait planifié le dernier paquet RTCP RR régulier pour tp (et l'ait envoyé ou supprimé à tp) et planifié la prochaine transmission (y compris reconsideration éventuelle selon [1]) pour tn = tp + T_rr. Supposons aussi que la dernière transmission RTCP régulière ait eu lieu à t_rr_last.

L'algorithme de feedback anticipé comprend alors les étapes suivantes :

1. À l'instant t0, R constate la nécessité de transmettre un ou plusieurs messages FB, par ex. parce que des « unités » média doivent être acquittées ou NACKées, et estime que fournir l'information de feedback peut être utile pour l'émetteur.

2. R vérifie d'abord s'il existe déjà un paquet RTCP composé contenant un ou plusieurs messages FB planifié pour transmission (anticipé ou régulier).

   2a) Si oui, le nouveau message FB MUST être inclus dans le paquet planifié ; la planification du paquet RTCP composé en attente MUST rester inchangée. Les informations de feedback disponibles SHOULD être fusionnées pour produire le moins de messages FB possible. Les actions immédiates sont terminées.

   2b) Si aucun paquet RTCP composé n'est déjà planifié, un nouveau paquet RTCP composé (minimal ou complet) MUST être créé et l'intervalle minimal pour T_dither_max MUST être choisi comme suit :

   i) Si la session est point à point,

   T_dither_max = 0.

   ii) Si la session est multipoint,

   T_dither_max = l * T_rr

   avec l=0,5.

   La valeur de T_dither_max MAY être calculée différemment (par ex. selon l'aller-retour), ce qui MUST alors être spécifié dans un document ultérieur. Une telle spécification MUST garantir que tous les récepteurs RTP utilisent le même mécanisme pour calculer T_dither_max.

   Les valeurs ci-dessus pour T_dither_max sont des valeurs minimales. Des considérations de feedback propres à l'application peuvent justifier d'augmenter T_dither_max au-delà ; cela relève de l'implémenteur.

3. R MUST alors vérifier si son prochain paquet RTCP régulier tomberait dans les limites temporelles du paquet RTCP anticipé déclenché à t0, c'est-à-dire si t0 + T_dither_max > tn.

   3a) Si oui, aucun paquet RTCP anticipé MUST être planifié ; les message(s) FB MUST être stockés pour inclusion dans le paquet RTCP régulier planifié pour tn. Fin des actions immédiates.

   3b) Sinon, les étapes suivantes s'appliquent.

4. R MUST vérifier s'il est autorisé à transmettre un paquet RTCP anticipé, c'est-à-dire si allow_early == TRUE ou non.

   4a) Si allow_early == FALSE, R MUST vérifier l'heure du prochain paquet RTCP régulier planifié :

   1. Si tn - t0 < T_max_fb_delay, le feedback peut encore être utile malgré un rapport tardif. R MAY créer un message RTCP FB à inclure dans le paquet RTCP régulier prévu à tn.

   2. Sinon, R MUST supprimer le message RTCP FB.

   Fin du déroulement immédiat.

   4b) Si allow_early == TRUE, R MUST planifier un paquet RTCP anticipé pour te = t0 + RND * T_dither_max, RND étant une fonction pseudo-aléatoire uniforme entre 0 et 1.

5. R MUST détecter les chevauchements entre les messages FB reçus des autres membres de la session RTP et ceux que R souhaite envoyer. Par conséquent, tant qu'il est membre de la session RTP, R MUST surveiller en continu l'arrivée de paquets RTCP composés (minimaux) et stocker chaque message FB contenu pendant au moins T_retention. En planifiant l'envoi de son propre message FB selon les étapes 1 à 4, R MUST examiner chaque message FB stocké et nouvellement reçu des paquets RTCP reçus pendant l'intervalle [t0 - T_retention ; te] et agir comme suit :

   5a) Si R comprend la sémantique du message FB reçu et que le contenu est un sur-ensemble du feedback que R voulait envoyer, R MUST supprimer son propre message FB et MUST replanifier la prochaine transmission RTCP régulière pour tn (tel que calculé auparavant).

   5b) Si R comprend la sémantique et que le contenu n'est pas un sur-ensemble, R SHOULD transmettre son propre message FB comme planifié. En cas de chevauchement entre le feedback à envoyer et celui reçu, la quantité transmise est à la discrétion de R : R MAY laisser son feedback inchangé, R MAY aussi supprimer la redondance entre son feedback et celui reçu des autres membres.

   5c) Si R ne comprend pas la sémantique, R MAY conserver son message FB planifié comme paquet RTCP anticipé, ou R MAY replanifier la prochaine transmission RTCP régulière pour tn et MAY ajouter le message FB au message RTCP désormais planifié régulièrement.

   Note : Avec 5c), la réception de messages FB inconnus peut ne pas entraîner de suppression du feedback chez un récepteur donné. Un même événement peut donc provoquer M types de messages FB (tous pertinents mais non mutuellement compris), partitionnant effectivement un « grand » groupe de récepteurs en au plus M groupes. La suppression du feedback a lieu au sein de chaque groupe (5a, 5b) mais pas entre groupes. L'émetteur peut recevoir O(M) messages RTCP FB ; risque d'implosion de feedback limitée. Comme émetteurs et récepteurs partagent la même application et les mêmes codecs dans la même session RTP, on peut supposer peu de divergence sémantique et M petit en général.

   Sachant de plus que les O(M) messages FB sont répartis aléatoirement sur T_dither_max, le nombre limité de paquets RTCP composés supplémentaires (a) ne devrait pas submerger l'émetteur et (b) devrait être transmis car ils apportent des informations complémentaires.

6. Si le(s) message(s) FB de R n'ont pas été supprimés par d'autres messages FB de récepteurs selon 5, à l'heure te, R MUST transmettre le paquet RTCP composé (minimal) contenant son(ses) message(s) FB. R MUST alors mettre allow_early = FALSE, recalculer tn = tp + 2*T_rr, et fixer tp à l'ancien tn. Dès que le nouveau tn est atteint, que R envoie ou supprime son prochain paquet RTCP régulier (par ex. à cause de T_rr_interval), il MUST remettre allow_early à TRUE.

3.5.3. Transmission RTCP régulière

Les paquets RTCP composés complets MUST être envoyés à intervalles réguliers. Ils MAY aussi contenir un ou plusieurs messages FB. La transmission des paquets RTCP réguliers est planifiée comme suit :

Si T_rr_interval == 0, la transmission MUST suivre les sections 3.2 et 3.4 et MUST respecter les ajustements de tn de la section 3.5.2 (sauter une transmission régulière si une transmission anticipée a eu lieu). La reconsideration du temporisateur a lieu à tn selon [1]. Le paquet RTCP régulier est envoyé après reconsideration. Chaque envoi ou suppression d'un paquet RTCP régulier, allow_early MUST être TRUE et tp, tn mis à jour selon [1]. Après la première transmission RTCP régulière, Tmin MUST être 0.

Si T_rr_interval != 0, le calcul des instants MUST suivre les sections 3.2 et 3.4 et les ajustements de tn de la section 3.5.2. Reconsideration à tn selon [1]. Après reconsideration :

1. Si aucun paquet RTCP régulier n'a encore été envoyé (t_rr_last == NaN), un paquet RTCP régulier MUST être planifié. Les messages FB stockés MAY y être inclus. Après envoi, t_rr_last MUST être tn. Tmin MUST être 0.

2. Sinon, une valeur temporaire T_rr_current_interval :

   T_rr_current_interval = RND*T_rr_interval

   avec RND uniforme entre 0,5 et 1,5. Cette valeur ditherée détermine :

   2a) Si t_rr_last + T_rr_current_interval <= tn, un paquet RTCP régulier MUST être planifié. Les messages RTCP FB stockés MAY y être inclus. Après envoi, t_rr_last MUST être tn.

   2b) Si t_rr_last + T_rr_current_interval > tn et des messages RTCP FB sont en attente, un paquet RTCP MUST être planifié à tn. Il MAY être minimal ou régulier (au choix de l'implémenteur) et MUST inclure les messages FB stockés. t_rr_last MUST rester inchangé.

   2c) Sinon (t_rr_last + T_rr_current_interval > tn sans FB en attente), le paquet composé MUST être supprimé (non planifié). t_rr_last MUST rester inchangé.

Dans tous les cas (1, 2a, 2b, 2c), allow_early MUST être TRUE (éventuellement après envoi) et tp, tn mis à jour selon [1], sauf minimum de cinq secondes.

3.5.4. Autres considérations

Si T_rr_interval != 0, le calcul de temporisation pour les entités RTP/AVPF (section 6.3.5 de [1]) MUST utiliser T_rr_interval à la place de Tmin pour Td et donc M*Td.

Chaque envoi ou réception d'un paquet RTCP composé — minimal ou complet, anticipé ou régulier —, la variable avg_rtcp_size MUST être mise à jour (voir [1]) et les calculs ultérieurs de tn MUST utiliser la nouvelle avg_rtcp_size.