Groupe de travail Réseau	J. Ott, Helsinki University of Technology	
Request for Comments : 4585	S. Wenger, Nokia	
Catégorie : Sur la voie de la normalisation	N. Sato, Oki	
	C. Burmeister & J. Rey, Matsushita	
Traduction Claude Brière de L'Isle	juillet 2006	

Profil RTP étendu pour rétroaction fondée sur le protocole de contrôle de transport en temps réel (RTCP) (RTP/AVPF)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
Les flux de supports en temps réel qui utilisent RTP sont, dans une certaine mesure, résistants à la perte de paquet. Les receveurs peuvent utiliser les mécanismes de base du protocole de contrôle en temps réel (RTCP, Real-time Transport Control Protocol) pour rapporter des statistiques de réception de paquet et donc permettre à l'envoyeur d'adapter son comportement de transmission à moyen terme. C'est le seul moyen pour la rétroaction et la réparation d'erreur fondée sur la rétroaction (à côté de quelques mécanismes spécifiques du codec). Le présent document définit une extension au profil audio visuel (AVP, Audio-visual Profile) qui permet aux receveurs de fournir, statistiquement, plus de rétroactions immédiates aux envoyeurs et permet donc de mettre en œuvre une adaptation à court terme et des mécanismes efficaces fondés sur le retour. Ce profil de retour précoce (AVPF) conserve les contraintes de bande passante de l'AVP pour RTCP et préserve l'adaptabilité aux grands groupes.
Table des matières
1. Introduction	2
1.1 Définitions	2
1.2 Terminologie	3
2. Formats de paquet RTP et RTCP et comportement du protocole	3
2.1 RTP	3
2.2 Protocoles de transport sous-jacents	4
3. Règles pour les rétroactions de RTCP	4
3.1 Paquets composés de rétroactions RTCP	4
3.2 Grandes lignes de l'algorithme	5
3.3 Modes de fonctionnement	5
3.4 Définitions et vue d'ensemble de l'algorithme	7
3.5 Algorithme de programmation AVPF RTCP	8
3.6 Considérations sur la taille de groupe	11
3.7 Résumé des étapes de décision	12
4. Définitions SDP	13
4.1 Identification de profil	13
4.2 Attribut de capacité de rétroactions RTCP	13
4.3 Modificateurs de bande passante RTCP	15
4.4 Exemples	15
5. Interfonctionnement et coexistence des entités AVP et AVPF	17
6. Format du message de rétroaction RTCP	17
6.1 Format de paquet commun pour les messages de rétroaction	18
6.2 Messages de rétroaction de couche Transport	19
6.3 Messages de rétroaction spécifiques de la charge utile	20
6.4 Messages de rétroaction de couche Application	23
7. Retours précoces et contrôle d'encombrement	24
8. Considérations sur la sécurité	24
9. Considérations relatives à l'IANA	25
10. Remerciements	27
11. Références	28
11.1 Références normatives	28
11.2 Références pour information	28
Adresse des auteurs	29
Déclaration complète de droits de reproduction	29
 	1.	Introduction

Les flux de supports en temps réel qui utilisent RTP sont, dans une certaine mesure, résistants aux pertes de paquets. RTP [RFC3550] fournit tous les mécanismes nécessaires pour restaurer l'ordre et rythme présents chez l'envoyeur pour reproduire correctement un flux de supports chez un receveur. RTP fournit aussi des rétroactions continuelles sur la qualité de réception globale de tous les receveurs – permettant pas là à l'envoyeur d'adapter à moyen terme (de l'ordre de plusieurs secondes à quelques minutes) son schéma de codage et son comportement de transmission à la qualité de service (QS) observée du réseau. Cependant, sauf pour quelques mécanismes spécifiques de la charge utile [RFC2032], RTP n'a pas de dispositions pour des rétroactions en temps utile qui permettraient à un envoyeur de réparer le flux de supports immédiatement à travers les retransmissions, un contrôle rétroactif de la correction d'erreur directe (FEC, Forward Error Correction) ou un mécanisme spécifique du support pour certains codecs vidéo, comme le choix de l'image de référence.

Les mécanismes actuellement disponibles avec RTP pour améliorer la résilience à l'erreur incluent le codage audio redondant [RFC2198], le codage vidéo redondant [RFC2429], la FEC de niveau RTP [RFC2354], et les considérations générales sur la transmission plus robuste de flux de supports [RFC2733]. Ces mécanismes peuvent être appliqués de façon préventive (augmentant par là la bande passante d'un certain flux de supports). Autrement, dans des groupes suffisamment petits avec de petits délais d'aller retour (RTT, round-trip time) les envoyeurs peuvent effectuer une réparation à la demande, en utilisant les mécanismes et/ou approches spécifiques du codage de supports ci-dessus. Noter que "petit groupe" et "RTT suffisamment petit" sont toux deux très dépendants de l'application.

Le présent document spécifie un profil RTP modifié pour conférences audio et vidéo avec contrôle minimal fondé sur les [RFC3550] et [RFC3551] au moyen de deux modifications/ajouts. D'abord, pour réaliser une rétroaction en temps utile, on introduit le concept de messages RTCP précoces ainsi que les algorithmes qui permettent de faibles délais de rétroaction dans les petits groupes de diffusion groupée (et en empêchant l'explosion de rétroactions dans les grands). Une considération particulière est apportée aux scénarios de point à point. Ensuite, un petit nombre de messages de rétroaction d'utilité générale ainsi qu'un format pour les informations de rétroaction spécifiques des codecs et des applications sont définis pour la transmission dans les charges utiles RTCP.

 	1.1	Définitions
On applique les définitions de RTP/RTCP [RFC3550] et du "Profil RTP pour les conférences audio et vidéo avec contrôle minimal" [RFC3551]. De plus, les définitions suivantes sont utilisées dans le présent document :

Mode RTCP précoce : mode de fonctionnement dans lequel un receveur d'un flux de supports est souvent (mais pas toujours) capable de rapporter des événements intéressants à l'envoyeur peu après qu'ils surviennent. Dans le mode RTCP précoce, les paquets RTCP sont transmis en accord avec les règles de temps définies dans le présent document.

Paquet RTCP précoce : c'est un paquet qui est transmis plus tôt qu'il ne serait permis si il suivait l'algorithme de programmation de la [RFC3550], parce qu'un "événement" a été observé par un receveur. Les paquets RTCP précoces peuvent être envoyés en mode de rétroaction immédiate et en mode RTCP précoce. L'envoi d'un paquet RTCP précoce est aussi appelé l'envoi d'une rétroaction précoce dans le présent document.

Événement : observation faite par le receveur d'un flux de supports qui est (potentiellement) intéressant pour l'envoyeur – comme la perte de paquets ou la réception de paquets, perte de trame, etc. -- et donc utile à rapporter à l'envoyeur au moyen d'un message de rétroaction.

Message de rétroaction : un message RTCP comme défini dans le présent document est utilisé pour convoyer des informations sur des événements observés chez un receveur -- en plus des informations d'état à long terme du receveur qui sont portées dans les rapports de receveur RTCP – en retour à l'envoyeur des flux de supports. Pour être clair, le message de rétroaction est appelé un message FB (feedback, rétroaction) dans le présent document.

Seuil de rétroaction (FB) : le seuil de rétroaction indique la transition entre le mode de rétroaction immédiate et le mode RTCP précoce. Pour un scénario multi parties, le seuil de rétroaction indique la taille maximum de groupe à laquelle, en moyenne, chaque receveur est capable de rapporter immédiatement chaque événement à l'envoyeur, c'est-à-dire, au moyen d'un paquet RTCP précoce sans avoir à attendre son intervalle RTCP régulièrement programmé. Ce seuil est très dépendant du type de rétroaction à fournir, de la qualité de service du réseau (par exemple, probabilité et distribution de perte de paquets) codec et schéma de mise en paquets utilisé, bande passante de session, et exigences de l'application. Noter que les algorithmes ne dépendent pas de ce que tous les envoyeurs et receveurs s'accordent sur la même valeur de seuil. Il est simplement destiné à fournir une indication conceptuelle aux concepteurs d'applications et n'est pas utilisé dans des calculs.  Pour être clair, le terme de seuil de rétroaction est appelé seuil de rétroaction tout au long de ce document.

Mode de rétroaction immédiate : mode de fonctionnement dans lequel chaque receveur d'un flux de supports est, statistiquement, capable de rapporter chaque événement intéressant immédiatement à l'envoyeur du flux de supports. Dans le mode de rétroaction immédiate, les messages FB RTCP sont transmis en accord avec les règles de temps définies dans le présent document.

Paquet de supports : c'est un paquet RTP.

Mode RTCP régulier : mode de fonctionnement dans lequel aucune transmission préférée de messages FB n'est permise. À la place, les messages RTCP sont envoyés en suivant les règles de la [RFC3550]. Néanmoins, de tels messages RTCP peuvent contenir des informations de rétroaction comme défini dans le présent document.

Paquet RTCP régulier : paquet RTCP qui n'est pas envoyé comme un paquet RTCP précoce.

Envoyeur RTP : c'est une entité RTP qui transmet des paquets de supports ainsi que des paquets RTCP et reçoit des paquets réguliers ainsi que des paquets RTCP précoces (c'est-à-dire, de rétroaction). Noter que l'envoyeur RTP est un rôle logique et que la même entité RTP peut agir en même temps comme receveur RTP.

Receveur RTP : entité RTP qui reçoit des paquets de supports ainsi que des paquets RTCP et transmet des paquets réguliers ainsi que des paquets RTCP précoces (c'est-à-dire, de rétroaction). Noter que le receveur RTP est un rôle logique et que la même entité RTP peut agir en même temps comme envoyeur RTP.

 	1.2	Terminologie
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119] et indiquent les niveaux d'exigences pour les mises en œuvre conformes.

 	2.	Formats de paquet RTP et RTCP et comportement du protocole
 	2.1	RTP
Les règles définies dans la [RFC3551] s'appliquent aussi à ce profil, sauf pour les règles mentionnées ci-dessous :

Type de paquets RTCP : deux types supplémentaires de paquets RTCP sont enregistrés et les messages FB correspondants pour porter les informations de rétroaction sont définis à la Section 6 du présent mémoire.

Intervalles de rapport RTCP : le présent document décrit trois modes de fonctionnement qui influencent les intervalles de rapport RTCP (voir le paragraphe 3.2). En mode RTCP régulier, toutes les règles de la [RFC3550] s'appliquent excepté pour l'intervalle minimal recommandé de cinq secondes entre deux rapports RTCP provenant de la même entité RTP. Dans les deux modes de rétroaction immédiate et de RTCP précoce, l'intervalle minimal de cinq secondes entre deux rapports RTCP est abandonné, et de plus, les règles spécifiées à la Section 3 s'appliquent si des paquets RTCP contenant des messages FB (définis à la Section 4) sont à transmettre.

Les règles établies dans la [RFC3550] peuvent être outrepassées par des descriptions de session qui spécifient des paramètres différents (par exemple, pour le partage de bande passante allouée à RTCP pour respectivement les envoyeurs et les receveurs). Pour les sessions définies en utilisant le protocole de description de session (SDP, Session Description Protocol) [RFC4566], les règles de la [RFC3556] s'appliquent.

Contrôle d'encombrement : les mêmes règles de base que détaillées dans la [RFC3551] s'appliquent. Au delà de cela, à la Section 7, d'autres considérations sont données sur l'impact de la rétroaction et de la réaction de l'envoyeur aux messages FB.

 	2.2	Protocoles de transport sous-jacents
RTP est destiné à être utilisé par dessus des protocoles de transport non fiables, incluant UDP et le protocole de contrôle d'encombrement de datagrammes (DCCP, Datagram Congestion Control Protocol). Ce paragraphe décrit brièvement les spécificités au delà du fonctionnement de RTP introduites par la rétroaction RTCP spécifiée dans ce mémoire.

UDP : UDP fournit une livraison au mieux des datagrammes en point à point ainsi que pour les communications de diffusion groupée. UDP ne prend pas en charge le contrôle de l'encombrement ni la réparation d'erreurs. La rétroaction fondée sur RTCP définie dans le présent mémoire est capable de fournir une prise en charge minimale de réparation d'erreur limitée. Comme il n'est pas garanti que la rétroaction RTCP fonctionne sur des échelles de temps suffisamment petites (de l'ordre du RTT) la rétroaction RTCP ne convient pas pour la prise en charge du contrôle d'encombrement. Le présent mémoire traite du fonctionnement en envoi individuel et en diffusion groupée.

DCCP : DCCP [RFC4340] fournit des flux de datagrammes à encombrement contrôlé mais non fiable pour des communications en envoi individuel. Avec le contrôle d'encombrement fondé sur TCP avec contrôle de débit en douceur (TFRC, TCP Friendly Rate Control) [RFC3448] (CCID 3), DCCP convient particulièrement bien pour les communications audio et vidéo. Les messages d'accusé de réception de DCCP peuvent fournir des rapports détaillés de rétroaction sur les datagrammes reçus et manqués (et donc sur l'encombrement).

Lorsque on fonctionne avec RTP sur DCCP, le contrôle d'encombrement est effectué à la couche DCCP et aucun mécanisme supplémentaire n'est exigé à la couche RTP. De plus, un envoyeur capable de rétroaction RTCP peut démultiplier la rétroaction plus fréquente fondée sur DCCP et donc un receveur peut s'abstenir d'utiliser les messages génériques de rétroaction (supplémentaires) lorsque approprié.

 	3.	Règles pour les rétroactions de RTCP
 	3.1	Paquets composés de rétroactions RTCP
Deux composants constituent la rétroaction fondée sur RTCP décrite dans le présent document :

o	Les rapports d'état sont contenus dans les paquets de rapport d'envoyeur (SR, Sender Report) / rapport reçu (RR, received report) et sont transmis à des intervalles réguliers au titre des paquets RTCP composés (qui incluent aussi des descriptions de source (SDES, source description) et éventuellement d'autres messages) ; ces rapports d'état fournissent une indication globale de la récente qualité de réception d'un flux de supports.

o	Les messages FB comme défini dans le présent document qui indiquent la perte ou la réception de parties particulières d'un flux de supports (ou fournissent d'autres formes de rétroaction assez immédiate sur les données reçues). Les règles pour la transmission de messages FB sont introduites dans le présent document.

Les messages FB RTCP sont simplement un autre type de paquet RTCP (voir la Section 4). Donc, plusieurs messages FB PEUVENT être combinés dans un seul paquet RTCP composé et ils PEUVENT aussi être envoyés combinés avec d'autres paquets RTCP.

Les paquets RTCP composés qui contiennent des messages FB comme défini dans le présent document DOIVENT contenir les paquets RTCP dans l'ordre défini dans la [RFC3550] :
o	un préfixe de chiffrement FACULATIF qui DOIT être présent si le ou les paquets RTCP sont à chiffrer en accord avec le paragraphe 9.1 de la [RFC3550].
o	Un SR ou RR OBLIGATOIRE.
o	Un SDES OBLIGATOIRE, qui DOIT contenir l'élément CNAME ; tous les autres éléments SDES sont FACULATIFS.
o	Un ou plusieurs messages FB.

Les messages FB DOIVENT être placés dans le paquet composé après les paquets RTCP RR et SDES définis dans la [RFC3550]. L'ordre par rapport aux autres extensions RTCP n'est pas défini.

Deux types de paquets RTCP composés portant des paquets de rétroaction sont utilisés dans ce document :

a) Paquet minimal de rétroaction RTCP composé
Un paquet minimal de rétroaction RTCP composé DOIT contenir seulement les informations obligatoires dont la liste figure ci-dessus : un préfixe de chiffrement si nécessaire, exactement un RR ou SR, exactement une SDES avec seulement l'élément CNAME présent, et le ou les messages FB. C'est pour minimiser la taille du paquet RTCP transmis pour porter la rétroaction et donc pour maximiser la fréquence à laquelle la rétroaction peut être fournie tout en adhérant aux limitations de bande passante RTCP.
Ce format de paquet DEVRAIT être utilisé chaque fois qu'un message FB RTCP est envoyé au titre d'un paquet RTCP précoce. Ce type de paquet est appelé un paquet RTCP composé minimal dans le présent document.

b) Paquet de rétroaction RTCP composé complet
Un paquet de rétroaction RTCP composé complet PEUT contenir tout nombre supplémentaire de paquets RTCP (des RR supplémentaires, d'autres éléments de SDES, etc.). Les règles d'ordre ci-dessus DOIVENT être respectées.
Ce format de paquet DOIT être utilisé chaque fois qu'un message FB RTCP est envoyé au titre d'un paquet RTCP régulier ou en mode RTCP régulier. Il PEUT aussi être utilisé pour envoyer des messages FB RTCP en mode de rétroaction immédiate ou en mode RTCP précoce. Ce type de paquet est appelé un paquet RTCP composé complet dans le document.

Les paquets RTCP qui ne contiennent pas de message FB sont appelés des paquets RTCP non FB. Ces paquets DOIVENT suivre les règles de format de la [RFC3550].

 	3.2	Grandes lignes de l'algorithme
Les messages FB font partie du flux de contrôle RTCP et sont donc soumis aux contraintes de bande passante RTCP. Cela signifie, en particulier, qu'il se peut qu'il ne soit pas possible de rapporter immédiatement à l'envoyeur un événement observé chez un receveur. Cependant, la valeur de rétroaction donnée à un envoyeur diminue normalement avec le temps -- en termes de qualité des supports perçue par l'utilisateur à l'extrémité de réception, et/ou le coût requis pour réaliser la réparation du flux de supports.

RTP [RFC3550] et le profil RTP [RFC3551] couramment utilisé spécifient les règles sur quand des paquets RTCP composés devraient être envoyés. Le présent document modifie ces règles afin de permettre aux applications de rapporter les événements en temps utile (par exemple, perte ou réception de paquets RTP) et de s'accommoder des algorithmes qui utilisent des messages FB.

L'algorithme de transmission RTCP modifié peut être présenté comme suit : tant qu'aucun message FB n'a à être transporté, les paquets RTCP composés sont envoyés suivant les règles de RTP [RFC3550] – sauf que l’intervalle minimum de cinq secondes entre rapports RTCP n'est pas appliqué. Donc, l'intervalle entre les rapports RTCP est seulement déduit de la taille moyenne de paquet RTCP et de la part de bande passante RTCP disponible pour l'entité RTP/RTCP. Facultativement, un intervalle minimum entre paquets RTCP réguliers peut être appliqué.

Si un receveur détecte le besoin d'envoyer un message FB, il peut le faire plus tôt que le prochain intervalle de rapport RTCP régulier (pour lequel il serait programmé suivant l'algorithme RTCP régulier ci-dessus). La suppression des rétroactions est utilisée pour éviter une explosion de rétroactions dans les sessions multi parties : le receveur attend pendant un (court) intervalle de fluctuation aléatoire pour vérifier si il voit un message FB correspondant provenant de tout autre receveur rapportant le même événement. Noter que pour les sessions en point à point il n'y a pas ce délai. Si un message FB correspondant provenant d'un autre membre est reçu, ce receveur s'abstient d'envoyer le message FB et continue de suivre le programme régulier de transmission RTCP. Dans le cas où le receveur n'a pas encore vu un message FB correspondant provenant d'un autre membre, il vérifie si il lui est permis d'envoyer une rétroaction précoce. Si l'envoi de rétroaction précoce est permis, le receveur envoie le message FB au titre d'un paquet RTCP composé minimal. La permission d'envoyer une rétroaction précoce dépend du type du précédent paquet RTCP envoyé par ce receveur et de l'heure d'envoi du message précédent de rétroaction précoce.

Les messages FB peuvent aussi être envoyés au titre de paquets RTCP composés complets, qui sont transmis conformément à la [RFC3550] (sauf la limite inférieure de cinq secondes) en intervalles réguliers.

 	3.3	Modes de fonctionnement
La rétroaction fondée sur RTCP peut opérer dans un des trois modes (Figure 1) décrits ci-dessous. Le mode de fonctionnement est juste une indication de si le receveur va ou non, en moyenne, être capable de rapporter en temps utile tous les événements à l'envoyeur ; le mode n'influence pas l'algorithme utilisé pour programmer la transmission des messages FB.

Et, selon la qualité de réception et l'état surveillé en local de la session RTP, les receveurs individuels peuvent ne pas s'accorder (et n'ont pas à le faire) sur une perception commune du mode de fonctionnement actuel.

a)	Mode de rétroaction immédiate : dans ce mode, la taille de groupe est en-dessous du seuil de rétroaction, qui donne à chaque partie receveuse une bande passante suffisante pour transmettre les paquets de rétroaction RTCP pour l'objet prévu. Cela signifie que, pour chaque receveur, il y a assez de bande passante pour rapporter chaque événement au moyen d'un paquet de rétroaction RTCP virtuellement "immédiat".

Le seuil de taille de groupe est une fonction d'un certain nombre de paramètres incluant (mais sans nécessairement s'y limiter) : le type de rétroaction utilisé (par exemple, ACK ou NACK) bande passante, taux de paquets, probabilité et distribution de perte de paquets, type des supports, codec, et fréquence (pire cas ou observée) des événements à rapporter (par exemple, trames reçues, perte de paquet).

Estimé en gros, soit N le nombre moyen d'événements à rapporter par intervalle T par un receveur, B la fraction de bande passante RTCP pour ce receveur, et R la taille moyenne de paquet RTCP, puis le receveur opère en mode de rétroaction immédiate tant que N ≤ B*T/R.

b)	mode RTCP précoce : dans ce mode, la taille de groupe et les autres paramètres ne permettent plus à chaque receveur de réagir à chaque événement qui vaudrait d'être rapporté (ou qui devrait l'être). Mais la rétroaction peut encore être faite suffisamment souvent pour que cela permette à l'envoyeur d'adapter la transmission de flux de supports en conséquence et par là d'augmenter la qualité globale d’exécution du support.

En utilisant la notation ci-dessus, le mode RTCP précoce peut être en gros caractérisé par N > B*T/R comme "limite inférieure". Une estimation d'une limite supérieure est plus difficile. En réglant N=1, on obtient pour un R et B donnés l'intervalle T = R/B comme intervalle moyen entre les événements à rapporter. Cette information peut être utilisée comme indication pour déterminer si la transmission précoce des paquets RTCP est ou non utile.

c)	Mode RTCP régulier : à partir d'une certaine taille de groupe, il n'est plus utile de fournir du tout de rétroaction pour les événements individuels provenant des receveurs – parce que l'échelle de temps dans laquelle la rétroaction pourrait être fournie et/ou parce que dans les grands groupes, le ou les envoyeurs n'ont plus aucune chance de réagir aux rétroactions individuelles.

Aucun seuil précis de taille de groupe ne peut être spécifié auquel ce mode commence mais, visiblement, cette limite correspond à la limite du mode RTCP précoce spécifiée au point b) ci-dessus.

Comme l'algorithme de rétroaction décrit dans le présent document s'adapte en douceur, il n'est pas besoin d'un accord entre les participants sur les valeurs précises des seuils de FB respectifs au sein du groupe. Donc, les limites entre tous ces modes sont lâches.

 rétroaction ACK
     V
     :<- - - -  rétroaction NACK - - - ->//
     :
     :Mode rétroaction||
     : immédiate      ||Mode RTCP précoce   Mode RTCP régulier 
     :<==============>||<===============>//<=================>
     :                ||
    -+----------------||-----------------//------------------> taille de groupe
     2                ||
Seuil de FB spécifique d'application = f(taux de données, perte de paquets, codec, ...)

Figure 1 : Modes de fonctionnement

Comme déclaré précédemment, les seuils respectifs de FB dépendent d'un certain nombre de paramètres techniques (du codec, du transport, du type de rétroaction utilisé, etc.) mais aussi des scénarios d'application respectifs. Le paragraphe 3.6 fournit des indications utiles (mais pas de calculs précis) sur l'estimation de ces seuils.

 	3.4	Définitions et vue d'ensemble de l'algorithme
Les éléments suivants d'informations d'état doivent être conservés par receveur (tirés largement de la [RFC3550]). Noter que toutes les variables (sauf au point h) ci-dessous) sont calculées indépendamment chez chaque receveur. Donc, leurs valeurs locales peuvent différer à tout moment.

a) Soit "envoyeurs" le nombre d'envoyeurs actifs dans le session RTP.

b) Soit "membres" l'estimation courante du nombre de receveurs dans la session RTP.

c) Soient tn et tp l'heure de la prochaine (dernière) transmission de RR RTCP RR programmée calculée avant la reconsidération du temporisateur.

d) Soit Tmin l'intervalle minimal entre les paquets RTCP selon la [RFC3550]. À la différence de la [RFC3550], le Tmin initial est réglé à une seconde pour permettre un échantillonnage de taille de groupe avant d'envoyer le premier paquet RTCP. Après l'envoi du premier paquet RTCP, Tmin est réglé à 0.

e) Soit T_rr l'intervalle après lequel, ayant juste envoyé un paquet RTCP régulièrement programmé, un receveur voudrait programmer la transmission de son prochain paquet RTCP régulier. Cette valeur est obtenue suivant les règles de la [RFC3550] mais avec Tmin comme défini dans le présent document : T_rr = T (l'intervalle "calculé" comme défini dans la [RFC3550]) avec tn = tp + T. T_rr se réfère toujours à la dernière valeur de T qui a été calculée (à cause d'une reconsidération ou pour déterminer tn). T_rr est aussi considéré comme l'intervalle RTCP régulier dans ce document.

f) Soit t0 l'heure à laquelle un événement qui est à rapporter est détecté par un receveur.

g) Soit T_dither_max l'intervalle maximum pour lequel un paquet de rétroaction RTCP PEUT être encore retardé pour empêcher les explosions de sessions multi parties ; la valeur pour T_dither_max est calculée dynamiquement sur la base de T_rr (ou peut être déduite au moyen d'un autre mécanisme commun à tous les receveurs RTP qui sera spécifié à l'avenir). Pour les sessions point à point (c'est-à-dire, les sessions avec exactement deux membres sans changement attendu de la taille de groupe, par exemple, des sessions de flux directs en envoi individuel) T_dither_max est réglé à 0.

h) Soit T_max_fb_delay la limite supérieure au sein de laquelle la rétroaction à un événement doit être rapportée à l'envoyeur pour être utile. Cette valeur est spécifique de l'application, et aucune valeur n'est définie dans ce document.

i) Soit te l'heure à laquelle un paquet de rétroaction est programmé.

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

k) Soit allow_early une variable booléenne qui indique si le receveur peut actuellement transmettre des messages FB avant son prochain intervalle RTCP tn régulièrement programmé. Cette variable est utilisée pour diminuer les rétroactions envoyées par un seul receveur. allow_early est réglé à FAUX après une transmission précoce de rétroaction et est réglé à VRAI aussitôt qu'a lieu la prochaine transmission RTCP régulière.

l) Soit avg_rtcp_size la moyenne mobile de la taille de paquet RTCP comme défini dans la [RFC3550].

m) Soit T_rr_interval un intervalle minimal FACULTATIF à utiliser entre les paquets RTCP réguliers. Si T_rr_interval = 0, alors cette variable n'a aucun impact sur le fonctionnement global de l'algorithme de rétroaction RTCP. Si T_rr_interval != 0, alors le prochain paquet RTCP régulier ne sera pas programmé T_rr après la dernière transmission RTCP régulière (c'est-à-dire, à tp+T_rr). Le prochain paquet RTCP régulier va plutôt être retardé jusqu'à au moins T_rr_interval après la dernière transmission RTCP régulière, c'est-à-dire, il va être programmé à ou après tp+T_rr_interval. Noter que T_rr_interval n'affecte pas le calcul de T_rr et tp ; les paquets RTCP réguliers programmés pour transmission avant tp+T_rr_interval vont plutôt être supprimés si, par exemple, ils ne contiennent pas de message FB. Le T_rr_interval n'affecte pas la programmation de la transmission des paquets RTCP précoces.

Note : fournir T_rr_interval comme variable indépendante est destiné à minimiser la rétroaction RTCP régulière (et donc la consommation de bande passante) comme nécessaire pour l'application tout en permettant en plus d'utiliser plus fréquemment les paquets RTCP précoces pour fournir une rétroaction en temps utile. Ce but ne pourrait pas être atteint en réduisant la bande passante RTCP globale car la réduction de bande passante RTCP impacterait aussi la fréquence de rétroaction précoce.

n) Soit t_rr_last le moment auquel le dernier paquet RTCP régulier a été programmé et envoyé, c'est-à-dire, n'a pas été supprimé à cause de T_rr_interval.

o) Soit T_retention la fenêtre de temps pour laquelle les messages FB passés sont mémorisés par une entité AVPF. Ceci est pour assurer que la suppression de rétroaction fonctionne aussi pour les entités qui ont reçu des messages FB d'autres entités avant de remarquer l'événement de rétroaction lui-même. T_retention DOIT être réglé au moins à 2 secondes.

p) Soit M*Td la valeur de temporisation pour qu'un receveur soit considéré inactif (comme défini dans la [RFC3550]).

La situation de rétroaction pour rapporter un événement à un receveur est décrite à la Figure 2. À l'instant t0, un tel événement (par exemple, une perte de paquets) est détecté chez le receveur. Le receveur décide – sur la base de la bande passante actuelle, de la taille de groupe, et autres paramètres spécifiques de l'application – qu'un message FB doit être renvoyé à l'envoyeur.

Pour éviter une explosion de paquets de rétroaction dans les sessions multi parties, le receveur DOIT retarder la transmission du paquet de rétroaction RTCP d'un délai aléatoire de T_fd (avec le nombre aléatoire également réparti sur l'intervalle [0, T_dither_max]). La transmission du paquet RTCP composé DOIT alors être programmée pour te = t0 + T_fd.

Le paramètre T_dither_max est déduit de l'intervalle RTCP régulier, T_rr, qui à son tour, se fonde sur la taille de groupe.  Un futur document pourrait aussi spécifier un autre calcul pour T_dither_max (par exemple, fondé sur le RTT) si il peut être assuré que tous les receveurs RTP vont utiliser le même mécanisme pour calculer T_dither_max.

Pour un certain scénario d'application, un receveur peut déterminer une limite supérieure pour le délai acceptable local des messages FB : T_max_fb_delay. Si une estimation a priori ou le calcul réel de T_dither_max indique que cette limite supérieure PEUT être violée (par exemple, parce que T_dither_max > T_max_fb_delay) le receveur PEUT décider de ne pas envoyer du tout de rétroaction parce que le gain réalisable est considéré insuffisant.

Si un paquet RTCP précoce est programmé, l'intervalle de temps pour le prochain paquet RTCP régulier DOIT être mis à jour en conséquence pour avoir un nouveau tn (tn=tp+2*T_rr) et un nouveau tp (tp=tp+T_rr) après coup. C'est pour assurer que la bande passante RTCP moyenne à court terme utilisée avec la rétroaction précoce n'excède pas la bande passante utilisée sans rétroaction précoce.

      événement détecté à rapporter
                |
                |  gamme de rétroaction RTCP
                |   (T_max_fb_delay)
                vXXXXXXXXXXXXXXXXXXXXXXXXXXX     ) )
   |---+--------+-------------+-----+------------| |--------+--->
       |        |             |     |            ( (        |
       |       t0            te                             |
       tp                                                   tn
                 \_______  ________/
                         \/
                   T_dither_max

Figure 2 : Rapport d'événement et paramètres pour la programmation de RTCP précoce

 	3.5	Algorithme de programmation AVPF RTCP
Soit S0 un envoyeur actif (parmi S envoyeurs) et soit N le nombre de receveurs avec R un de ces receveurs.

Supposons que R a vérifié qu'utiliser les mécanismes de rétroaction est raisonnable dans la constellation actuelle (qui est très spécifique de l'application et n'est donc pas spécifiée dans ce document).

Supposons de plus que T_rr_interval est 0, si aucun intervalle minimal entre paquets RTCP réguliers n'est à appliquer, ou si T_rr_interval est réglé à une valeur significative, comme donnée par l'application. Cette valeur note alors l'intervalle minimal entre paquets RTCP réguliers.

Avec cela, le receveur R DOIT utiliser les règles suivantes pour transmettre un ou plusieurs messages FB comme paquet RTCP composé minimal ou complet.

 	3.5.1	Initialisation
Initialement, R DOIT régler allow_early = VRAI et t_rr_last = NaN (Not-a-Number (pas un nombre) c'est-à-dire, une valeur invalide qui peut être distinguée d'une heure valide).

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

 	3.5.2	Transmission précoce de rétroactions
Supposons que R a programmé la transmission du dernier paquet RR RTCP régulier à tp (et a envoyé ou supprimé ce paquet à tp) et a programmé la prochaine transmission (incluant une possible reconsidération selon la [RFC3550]) pour tn = tp + T_rr. Supposons aussi que la transmission du dernier paquet RTCP régulier s'est produite à t_rr_last.

L'algorithme de rétroaction précoce comporte alors les étapes suivantes :

1. À l'instant t0, R détecte le besoin de transmettre un ou plusieurs messages FB, par exemple, parce que des "unités" de supports doivent recevoir un accusé de réception (ACK) ou un accusé de réception négatif (NACK) et qu'il trouve que fournir des informations de rétroaction est potentiellement utile pour l'envoyeur.

2. R vérifie d'abord si il y a déjà un paquet RTCP composé contenant un ou plusieurs messages FB programmés pour la transmission (comme paquet RTCP régulier ou précoce).

2a) Si il en est ainsi, le nouveau message FB DOIT être inclus dans le paquet programmé; la programmation du paquet RTCP composé en attente DOIT rester inchangée. Quand on fait ainsi, les informations de rétroaction disponibles DEVRAIENT être fusionnées pour produire aussi peu de messages FB que possible. Cela termine les actions immédiates à effectuer.

2b) Si aucun paquet RTCP composé n'est déjà programmé pour transmission, un nouveau paquet RTCP composé (minimal ou complet) DOIT être créé et l'intervalle minimal pour T_dither_max DOIT être choisi comme suit :
i) Si la session est en point à point, alors  : T_dither_max = 0.
i) Si la session est multi parties, alors  : T_dither_max = l * T_rr, avec l = 0,5.
La valeur pour T_dither_max PEUT être calculée différemment (par exemple, fondée sur le RTT) qui DOIT alors être spécifiée dans un futur document. Cette future spécification DOIT assurer que tous les receveurs RTP utilisent le même mécanisme pour calculer T_dither_max.
Les valeurs données ci-dessus pour T_dither_max sont les valeurs minimales. Des considérations de rétroaction spécifiques de l'application peuvent justifier d'augmenter T_dither_max au delà de cette valeur. Ceci est à la discrétion de la mise en œuvre.

3.	Ensuite, R DOIT vérifier si son prochain paquet RTCP régulier va être dans les limites de temps pour le paquet RTCP précoce déclenché à t0, c'est-à-dire, si t0 + T_dither_max > tn.
3a) Si il en est ainsi, un paquet RTCP précoce NE DOIT PAS être programmé ; le message FB DOIT plutôt être mémorisé pour être inclus dans le paquet RTCP régulier programmé pour tn. Cela achève les actions immédiates à entreprendre.
3b) Autrement, on effectue les étapes suivantes.

4.	R DOIT vérifier si il est autorisé à transmettre un paquet RTCP précoce, c'est-à-dire, allow_early == VRAI, ou non.
4a) Si allow_early == FAUX, alors R DOIT vérifier l'heure du prochain paquet RTCP régulier programmé :
1. Si tn - t0 < T_max_fb_delay, alors la rétroaction pourrait encore être utile à l'envoyeur, en dépit du rapport tardif. Donc, R PEUT créer un message FB RTCP à inclure dans le paquet RTCP régulier pour transmission à tn.
2. Autrement, R DOIT éliminer le message FB RTCP.
Cela achève les actions immédiates à entreprendre.
4b) Si allow_early == VRAI, alors R DOIT programmer un paquet RTCP précoce pour te = t0 + RND * T_dither_max, RND étant une fonction pseudo aléatoire également répartie entre 0 et 1.

5.	R DOIT détecter les chevauchements de messages FB reçus d'autres membres de la session RTP et les messages FB que R veut envoyer. Donc, quand il est membre d'une session RTP, R DOIT continuellement surveiller l'arrivée de paquets RTCP composés (minimaux) et mémoriser chaque message FB contenu dans ces paquets RTCP pendant au moins T_retention. Quand il programme la transmission de ses propres message FB en suivant les étapes 1 à 4 ci-dessus, R DOIT vérifier chaque message FB mémorisé et nouvellement reçu provenant des paquets RTCP reçus durant l'intervalle [t0 - T_retention ; te] et agir comme suit :
5a) Si R comprend la sémantique du message FB reçu et si le contenu du message est un sur-ensemble de la rétroaction que R voulait envoyer, alors R DOIT éliminer son propre message FB et DOIT reprogrammer la transmission du prochain paquet RTCP régulier pour tn (comme calculé plus haut).
5b) Si R comprend la sémantique du message FB reçu et si le contenu du message n'est pas un sur-ensemble de la rétroaction que R voulait envoyer, alors R DEVRAIT transmettre son propre message FB comme programmé. Si il y a un recouvrement entre les informations de rétroaction à envoyer et les informations de rétroaction reçues, la quantité de rétroaction transmise appartient à R : R PEUT laisser ses informations de rétroaction être envoyées inchangées, R PEUT aussi éliminer les redondances entre sa propre rétroaction et celles reçues jusqu'à présent des autres membre de la sessions.
5c) Si R ne comprend pas la sémantique du message de FB reçu, R PEUT garder son propre message FB programmé comme paquet RTCP précoce, ou R PEUT reprogrammer la transmission du prochain paquet RTCP régulier pour tn (comme calculé plus haut) et PEUT ajouter le message FB au message RTCP maintenant programmé régulièrement.

Note : avec 5c), la réception de messages FB inconnus ne peut pas conduire à la suppression de la rétroaction chez un receveur particulier. Par conséquent, un certain événement peut causer que M différents types de messages FB (qui sont tous appropriés mais pas mutuellement compris) soient programmés, de sorte qu'un "grand" groupe de receveurs peut effectivement être partitionné en au plus M groupes. Parmi les membres de chacun de ces M groupes, la suppression de rétroaction va se faire suivant 5a et 5b mais aucune suppression ne va arriver à travers les groupes. Par suite, O(M) messages FB RTCP peuvent être reçus par l'envoyeur. Donc, il y a des chances d'une explosion de rétroactions très limitée. Cependant, comme le ou les envoyeurs et tous les receveurs constituent la même application utilisant le même ensemble de codecs dans la même session RTP, on peut supposer en toute sécurité qu'il n'y aura que de petites divergences de sémantique pour les messages de FB et donc, M est supposé être petit dans le cas général. De plus, étant donné que O(M) messages FB sont distribués au hasard sur un intervalle de temps de T_dither_max, on trouve que le nombre limité résultant de paquets RTCP composés supplémentaires (a) n'est pas supposé submerger l'envoyeur et (b) devrait être convoyé car tous contiennent des éléments d'information complémentaires.

6.	Si les message FB de R n'ont pas été supprimés par un autre receveur de messages FB comme en 5, quand te est atteint, R DOIT transmettre le paquet RTCP composé (minimal) contenant son ou ses messages FB. R DOIT alors régler allow_early = FAUX, DOIT recalculer tn = tp + 2*T_rr, et DOIT régler tp au tn précédent. Aussitôt que le nouveau tn calculé est atteint, sans considérer si R envoie son prochain paquet RTCP régulier ou le supprime à cause de T_rr_interval, il DOIT régler allow_early = VRAI à nouveau.

 	3.5.3	Transmission RTCP régulière
Les paquets RTCP composés complets DOIVENT être envoyés à des intervalles réguliers. Ces paquets PEUVENT aussi contenir un ou plusieurs messages FB. La transmission des paquets RTCP réguliers est programmée comme suit :

Si T_rr_interval == 0, alors la transmission DOIT suivre les règles spécifiées aux paragraphes 3.2 et 3.4 de ce document et DOIT adhérer aux ajustements de tn spécifiés au paragraphe 3.5.2 (c'est-à-dire, sauter une transmission régulière si une transmission de paquet RTCP précoce s'est produite). La reconsidération du temporisateur a lieu quand tn est atteint comme spécifié dans la [RFC3550]. Le paquet RTCP régulier est transmis après la reconsidération du temporisateur. Chaque fois qu'un paquet RTCP régulier est envoyé ou supprimé, allow_early DOIT être réglé à VRAI et tp, tn DOIVENT être mis à jour conformément à la [RFC3550]. Après la première transmission d'un paquet RTCP régulier, Tmin DOIT être réglé à 0.

Si T_rr_interval != 0, alors le calcul des temps de transmission DOIT suivre les règles spécifiées aux paragraphes 3.2 et 3.4 de ce document et DOIT adhérer aux ajustements de tn spécifiés au paragraphe 3.5.2 (c'est-à-dire, sauter une transmission  régulière si une transmission RTCP précoce s'est produite). La reconsidération du temporisateur a lieu quand tn est atteint comme spécifié dans la [RFC3550]. Après la reconsidération du temporisateur, les actions suivantes sont effectuées :

1.	Si aucun paquet RTCP régulier n'a été envoyé avant (c'est-à-dire, si t_rr_last == NaN) alors un paquet RTCP régulier DOIT être programmé. Les messages FB mémorisés PEUVENT être inclus dans le paquet RTCP régulier. Après l'envoi du paquet programmé, t_rr_last DOIT être réglé à tn. Tmin DOIT être réglé à 0.

2	Autrement, une valeur T_rr_current_interval temporaire est calculée comme suit :
T_rr_current_interval = RND*T_rr_interval
avec RND comme fonction pseudo aléatoire distribuée équitablement entre 0,5 et 1,5. Cette valeur fluctuante est utilisée pour déterminer une des solutions de remplacement suivantes :

2a) Si t_rr_last + T_rr_current_interval ≤ tn, alors un paquet RTCP régulier DOIT être programmé. Les messages FB RTCP mémorisés PEUVENT être inclus dans le paquet RTCP régulier. Après l'envoi du paquet programmé, t_rr_last DOIT être réglé à tn.

2b) Si t_rr_last + T_rr_current_interval > tn et si des messages FB RTCP ont été mémorisés et attendent la transmission, un paquet RTCP DOIT être programmé pour transmission à tn. Ce paquet RTCP PEUT être un paquet RTCP régulier ou minimal (à la discrétion de la mise en œuvre) et le paquet RTCP composé DOIT inclure le ou les message FB RTCP mémorisés. t_rr_last DOIT rester inchangé.

2c) Autrement (si t_rr_last + T_rr_current_interval > tn mais aucun message FB RTCP mémorisé n'attend la transmission), le paquet RTCP composé DOIT être supprimé (c'est-à-dire, il NE DOIT PAS être programmé). t_rr_last DOIT rester inchangé.

Dans tous les quatre cas ci-dessus (1, 2a, 2b, et 2c) allow_early DOIT être réglé à VRAI (éventuellement après l'envoi du paquet RTCP régulier) et tp et tn DOIVENT être mis à jour suivant les règles de la [RFC3550] sauf pour le minimum de cinq secondes.

 	3.5.4	Autres considérations
Si T_rr_interval != 0, alors le calcul de fin de temporisation pour les entités RTP/AVPF (paragraphe 6.3.5 de la [RFC3550]) DOIT être modifié pour utiliser T_rr_interval au lieu de Tmin pour calculer Td et donc M*Td pour la temporisation des entités RTP.

Chaque fois qu'un paquet RTCP composé est envoyé ou reçu – minimal ou composé complet, précoce ou régulier – la variable avg_rtcp_size DOIT être mise à jour en conséquence (voir la [RFC3550]) et les calculs suivants de tn DOIVENT utiliser la nouvelle avg_rtcp_size (taille moyenne RTCP).

 	3.6	Considérations sur la taille de groupe
Ce paragraphe fournit des lignes directrices sur les tailles de groupe auxquelles les divers modes de rétroaction peuvent être utilisés.

 	3.6.1	Mode ACK
La session RTP DOIT avoir exactement deux membres et sa taille de groupe NE DOIT PAS croître, c'est-à-dire, ce DOIT être une communication en point à point. Des adresses d'envoi individuel DEVRAIENT être utilisées dans la description de session.

Pour une communication unidirectionnelle ainsi que bidirectionnelle entre deux parties, 2,5 % de la bande passante de session RTP est disponible pour le trafic RTCP provenant des receveurs, incluant de rétroaction. Pour un flux de 64 kbit/s, cela donne 1600 bit/s pour RTCP. Si on suppose une moyenne de 96 octets (= 768 bits) par paquet RTCP, un receveur peut rapporter deux événements par seconde à l'envoyeur. Si des accusés de réception pour 10 événements sont collectés dans chaque message FB, alors 20 événements peuvent être acquittés par seconde. À 256 kbit/s, 8 événements pourraient être rapportés par seconde ; donc, les ACK peuvent être envoyés avec une granularité plus fine (par exemple, en combinant seulement trois ACK par message FB).

À partir de 1 Mbit/s, un receveur va être capable d'accuser réception de chaque trame individuelle (pas de paquet !) dans un flux vidéo de 30 trame/s.

Les stratégies de ACK DOIVENT être définies pour fonctionner correctement avec ces limitations de bande passante. Une indication de si les ACK sont permis ou non pour une session et, si ils le sont, quelle stratégie de ACK devrait être utilisée, PEUT être convoyée par des mécanismes hors bande, par exemple, des attributs spécifiques du support dans une description de session utilisant SDP.

 	3.6.2	Mode NACK
Des accusés de réception négatifs (et d'autres types de rétroaction exhibant des caractéristiques de rapport similaires) DOIVENT être utilisés pour toutes les sessions avec une taille de groupe qui peut croître à plus de deux. Bien sûr, les NACK PEUVENT être utilisés aussi pour des communications en point à point.

Si l'utilisation de paquets RTCP précoces devrait être considérée dépend d'un certain nombre de paramètres incluant la bande passante de session, le codec, le type particulier de rétroaction, et du nombre d'envoyeurs et receveurs.

Les paramètres les plus importants quand on détermine le mode de fonctionnement sont l'intervalle minimal admis entre deux paquets RTCP (T_rr) composés et le nombre moyen d'événements qu'on présume devoir être rapportés par intervalle de temps (plus, bien sûr, leur répartition dans le temps). L'intervalle minimum peut être déduit de la bande passante RTCP disponible et de la taille moyenne espérée d'un paquet RTCP. Le nombre d'événements à rapporter (par exemple, par seconde) peut être déduit du taux de perte de paquets et du taux de transmission de paquets de l'envoyeur. À partir de ces deux valeurs, la taille de groupe admissible pour le mode de rétroaction immédiate peut être calculé.

Comme mentionné au paragraphe 3.3 : soit N le nombre moyen d'événements à rapporter par intervalle T par un receveur, B la fraction de bande passante RTCP pour ce receveur particulier, et R la taille moyenne de paquet RTCP, puis le receveur opère en mode de rétroaction immédiate tant que N ≤ B*T/R.

La limite supérieure pour le mode RTCP précoce dépend alors seulement de la dégradation de qualité acceptable, c'est-à-dire, combien d'événements par intervalle de temps peuvent n'être pas rapportés.

Comme mentionné au paragraphe 3.3, en utilisant la notation ci-dessus, le mode RTCP précoce peut être en gros caractérisé par N > B*T/R comme "limite inférieure". Une estimation de la limite supérieure est plus difficile. En prenant N=1, on obtient pour R et B donnés l'intervalle T = R/B comme intervalle moyen entre événements à rapporter. Cette information peut être utilisée comme indication pour déterminer si la transmission précoce des paquets RTCP est ou non utile.

Exemple : si une vidéo à 256 kbit/s avec 30 trame/s est transmise sur un réseau avec une taille de MTU de 1 500 octets, alors dans la plupart des cas, chaque trame va tenir dans un paquet conduisant à un taux de paquets de 30 paquets par seconde. Si il se produit 5 % de perte de paquets dans le réseau (également distribuée, aucune inter dépendance entre receveurs) alors chaque receveur va, en moyenne, avoir à rapporter 3 paquets perdus toutes les deux secondes. En supposant un seul envoyeur et plus de trois receveurs, cela donne 3,75  % de la bande passante RTCP allouée aux receveurs et donc 9,6 kbit/s. En supposant de plus qu'une taille de 120 octets pour le paquet RTCP composé moyen permet d'envoyer 10 paquets RTCP par seconde ou 20 en deux secondes. Si chaque receveur a besoin de rapporter trois paquets perdus par deux secondes, cela donne une taille maximum de groupe de 6-7 receveurs si tous les événements de perte sont rapportés. Les règles pour la transmission des paquets RTCP précoces devraient fournir une souplesse suffisante pour que la plupart de ces rapports interviennent en temps utile.

Étendre cet exemple pour déterminer la limite supérieure pour le mode RTCP précoce pourrait donner lieu aux considérations suivantes : supposons que le schéma de codage sous-jacent et l'application (ainsi que les utilisateurs tolérants) permette de l'ordre d'une perte sans réparation toutes les deux secondes. Donc, le nombre de paquets à rapporter par chaque receveur diminue de deux par deux secondes et augmente la taille du groupe à 10. En supposant de plus qu'un certain nombre de pertes de paquet sont corrélées, le trafic de rétroaction est encore réduit et des tailles de groupe d'environ 12 à 16 (peut-être même 20) peuvent être raisonnablement bien prises en charge en utilisant le mode RTCP précoce. Noter que toutes ces considérations se fondent sur des statistiques et vont échouer dans certains cas.

 	3.7	Résumé des étapes de décision
 	3.7.1	Conseils généraux
Avant même de considérer si elle envoie ou non les informations de rétroaction RTCP, une application doit déterminer si ce mécanisme est applicable :

1)	Une application doit décider si – pour le ratio actuel de taux de paquets avec le délai maximum de rétroaction associé (spécifique de l'application) et le temps d'aller-retour actuellement observé (si disponible) – les mécanismes de rétroaction peuvent être appliqués. Cette décision peut se fonder sur (et révisée dynamiquement ensuite) les statistiques de réception RTCP ainsi que des mécanismes hors bande.

2)	L'application doit décider – pour un certain taux d'erreurs observé, la bande passante allouée, le taux de trame/paquet, et la taille de groupe – si des mécanismes de rétroaction peuvent être appliqués. Les statistiques régulières de réception RTCP fournissent aussi des apports précieux à cette étape.

3)	Si l'application décide d'envoyer une rétroaction, l'application doit suivre les règles de transmission des paquets RTCP précoces ou réguliers contenant des messages FB.

4)	Le type de rétroaction RTCP envoyé ne devrait pas dupliquer l'information disponible à l'envoyeur à partir d'un protocole de transport de couche inférieure. C'est-à-dire, si le protocole de transport fournit des accusés de réception négatifs ou positifs sur la réception de paquet (comme DCCP) le receveur devrait éviter de répéter les mêmes informations à la couche RTCP (c'est-à-dire, s'abstenir d'envoyer des NACK génériques).

 	3.7.2	Attributs de session de supports
Les sessions de supports sont normalement décrites en utilisant des mécanismes hors bande pour convoyer les adresses de transport, les information de codec, etc., entre envoyeur(s) et receveur(s). Un tel mécanisme est à deux étapes : un format utilisé pour décrire une session de supports et un autre mécanisme pour transporter cette description.

Dans l'IETF, le protocole de description de session (SDP, Session Description Protocol) est actuellement utilisé pour décrire les sessions de supports tandis que des protocoles comme SIP, le protocole d'annonce de session (SAP, Session Announcement Protocol), le protocole de flux directs en temps réel (RTSP, Real Time Streaming Protocol), et HTTP (entre autres) sont utilisés pour porter les descriptions.

Un format de description de session de supports PEUT inclure des paramètres pour indiquer que des mécanismes de rétroaction RTCP sont pris en charge dans cette session et quels mécanismes de rétroaction PEUVENT être appliqués.

Pour ce faire, le profil "AVPF" DOIT être indiqué au lieu de "AVP". Plus d'attributs peuvent être définis pour montrer quels types de rétroaction sont pris en charge.

La Section 4 contient la spécification de la syntaxe pour la prise en charge de la rétroaction RTCP avec SDP. Les spécifications similaires pour d'autres formats de description de session de supports sortent du domaine d'application de de document.

 	4.	Définitions SDP

Cette Section définit un certain nombre de paramètres SDP supplémentaires qui sont utilisés pour décrire une session. Tous sont définis comme des attributs de niveau support.

 	4.1	Identification de profil
Le profil AV défini dans la [RFC3556] est appelé "AVP" dans le contexte, par exemple, du protocole de description de session (SDP) [RFC4566]. Le profil spécifié dans le présent document est appelé "AVPF".

Les informations de rétroaction suivant les règles modifiées de répartition dans le temps telles que spécifiées dans le présent document NE DOIVENT PAS être envoyées pour une session de supports particulière si la description pour cette session n'indique pas l'utilisation du profil "AVPF" (exclusivement ou conjointement avec d'autres profils AV).

 	4.2	Attribut de capacité de rétroactions RTCP
Un nouvel attribut SDP spécifique de format de charge utile est défini pour indiquer la capacité d'utiliser la rétroaction RTCP comme spécifiée dans le présent document : "a=rtcp-fb". L'attribut "rtcp-fb" DOIT seulement être utilisé comme attribut de support SDP et NE DOIT PAS être fourni au niveau session. L'attribut "rtcp-fb" DOIT seulement être utilisé dans les sessions de supports pour lesquelles "AVPF" est spécifié.

L'attribut "rtcp-fb" DEVRAIT être utilisé pour indiquer quels messages FB RTCP PEUVENT être utilisés dans cette session de supports pour le type de charge utile indiquée. Un caractère générique de type de charge utile ("*") PEUT être utilisé pour indiquer que l'attribut de rétroaction RTCP s'applique à tous les types de charges utiles. Si plusieurs types de rétroaction sont pris en charge et/ou si la même rétroaction devra être spécifiée pour un sous ensemble de type de charges utiles, plusieurs lignes "a=rtcp-fb" DOIVENT être utilisées.

Si aucun attribut "rtcp-fb" n'est spécifié, les receveurs RTP PEUVENT envoyer une rétroaction en utilisant d'autres paquets de rétroaction RTCP convenables comme défini pour le type de support concerné. Les receveurs RTP NE DOIVENT PAS compter sur la réaction des envoyeurs RTP à un message FB. L'envoyeur RTP PEUT choisir d'ignorer des messages de rétroaction.

Si un ou plusieurs attributs "rtcp-fb" sont présents dans une description de session de supports, les receveurs RTCP pour la ou les sessions de supports contenant l'attribut "rtcp-fb"  :
o	DOIVENT ignorer tous les attributs "rtcp-fb" dont ils ne comprennent pas pleinement la sémantique (c'est-à-dire, où ils ne comprennent pas la signification de toutes les valeurs dans la ligne "a=rtcp-fb") ;
o	DEVRAIENT fournir des informations de rétroaction comme spécifié dans le présent document en utilisant tout paquet de rétroaction RTCP comme spécifié dans un des attributs "rtcp-fb" pour cette session de supports ;
o 	NE DOIVENT PAS utiliser d'autres messages FB que ceux mentionnés dans une des lignes de l'attribut "rtcp-fb".

Quand utilisé en conjonction avec le modèle offre/réponse [RFC3264], l'offreur PEUT présenter un ensemble de ces attributs AVPF à son homologue. Le répondant DOIT retirer tous les attributs qu'il ne comprend pas ainsi que ceux qu'il ne prend pas en charge en général ou ne souhaite pas utiliser dans cette session de supports particulière. Le répondant NE DOIT PAS ajouter de paramètres de rétroaction à la description de supports et NE DOIT PAS altérer les valeurs de ces paramètres. La réponse lie la session de supports, et l'offreur ainsi que le répondant DOIVENT utiliser seulement les mécanismes de rétroaction négociés de cette façon. L'offreur et le répondant PEUVENT tous deux décider indépendamment d'envoyer des messages FB RTCP de seulement un sous ensemble des mécanismes de rétroaction négociés, mais ils DEVRAIENT réagir de façon appropriée à tous les types de messages FB négociés quand ils les reçoivent.

Les envoyeurs RTP DOIVENT être prêts à recevoir toutes sortes de messages FB RTCP et DOIVENT éliminer en silence tous les messages FB RTCP qu'ils ne comprennent pas.

La syntaxe de l'attribut "rtcp-fb" est comme suit (les types de rétroaction et les paramètres facultatifs sont tous insensibles à la casse) :

(Dans l'ABNF suivant, fmt, SP, et CRLF sont utilisés comme défini dans la [RFC4566].)

rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF

rtcp-fb-pt = "*"          ; le caractère générique s'applique à tous les formats / fmt définis dans la spécification de SDP

rtcp-fb-val = "ack" rtcp-fb-ack-param / "nack" rtcp-fb-nack-param / "trr-int" SP 1*DIGIT / rtcp-fb-id rtcp-fb-param

rtcp-fb-id = 1*(alpha-numérique / "-" / "_")

rtcp-fb-param = SP "app" [SP chaîne d'octets] / SP jeton [SP chaîne d'octets] / ; vide

rtcp-fb-ack-param  = SP "rpsi" / SP "app" [SP chaîne d'octets] / SP jeton [SP chaîne d'octets] / ; vide

rtcp-fb-nack-param = SP "pli" / SP "sli" / SP "rpsi" / SP "app" [SP chaîne d'octets] / SP jeton [SP chaîne d'octets] / ; vide

Les littéraux de la grammaire ci-dessus ont la sémantique suivante :

Type de retour "ack" : ce type de rétroaction indique que des accusés de réception positifs pour la rétroaction sont acceptés. Le type de rétroaction "ack" DOIT être utilisé seulement si la session de supports est autorisée à opérer en mode ACK comme défini au paragraphe 3.6.1. Des paramètres DOIVENT être fournis pour distinguer les différents types de rétroaction d'accusé de réception positif. Le paramètre "rpsi" indique l'utilisation de la rétroaction Indication de choix d'image de référence (RPSI, Reference Picture Selection Indication) comme défini au paragraphe 6.3.3. Si le paramètre "app" est spécifié, cela indique l'utilisation de la rétroaction de couche application. Dans ce cas, des paramètres supplémentaires suivant "app" PEUVENT être utilisés pour différentier les divers types de rétroaction de couche application. Le présent document ne définit aucun paramètre spécifique de "app". D'autres paramètres pour "ack" POURRONT être définis dans d'autres documents.

Type de retour "nack" : ce type de rétroaction indique que des accusés de réception négatifs sont pris en charge pour la rétroaction. Le type de rétroaction "nack", sans paramètre, indique l'utilisation du format de rétroaction générique NACK comme défini au paragraphe 6.2.1. Les trois paramètres suivants sont définis dans le présent document pour être utilisés avec "nack" en conjonction avec le type de support "video" :
o "pli" indique l'utilisation de la rétroaction Indication de perte d'image comme défini au paragraphe 6.3.1.
o "sli" indique l'utilisation de la rétroaction Indication de perte de tranche comme défini au paragraphe 6.3.2.
o "rpsi"indique l'utilisation de la rétroaction Indication de choix d'image de référence comme défini au paragraphe 6.3.3.

"app" indique l'utilisation de la rétroaction de couche application. Des paramètres supplémentaires après "app" PEUVENT être fournis pour différencier les différents types de rétroaction de couche application. Aucun paramètre spécifique de "app" n'est défini dans ce document. D'autres paramètres pour "nack" POURRONT être définis dans d'autres documents.

Autres types de rétroaction <rtcp-fb-id> : d'autres documents PEUVENT définir des types supplémentaires de rétroaction ; pour permettre l'extension de la grammaire pour ces cas, rtcp-fb-id est introduit comme bouche-trou. Un nouveau nom de schéma de rétroaction DOIT être unique (et donc DOIT être enregistré par l'IANA). Avec un nouveau nom, sa sémantique, les formats de paquet (si nécessaire), et ses règles de fonctionnement DOIVENT être spécifiés.

Intervalle minimum RTCP régulier "trr-int" : l'attribut "trr-int" est utilisé pour spécifier l'intervalle minimum T_rr_interval entre deux paquets réguliers (composés complets) RTCP en millisecondes pour cette session de supports. Si "trr-int" n'est pas spécifié, une valeur par défaut de 0 est supposée.

Noter qu'il est supposé que des informations plus spécifiques sur la rétroaction de couche application (comme défini au paragraphe 6.4) vont être portées comme types et paramètres de rétroaction définis ailleurs. Donc, aucune autre disposition pour des types et paramètres n'est prise dans ce document.

D'autres types de rétroaction ainsi que d'autres paramètres peuvent être définis dans d'autres documents.

Il appartient aux receveurs d'envoyer ou non des informations de rétroaction et aux envoyeurs de décider d'utiliser ou non la rétroaction fournie.

 	4.3	Modificateurs de bande passante RTCP
Les allocations standard de bande passante RTCP comme définies dans la [RFC3550] et la [RFC3551] PEUVENT être outrepassées par des modificateurs de bande passante qui définissent explicitement la bande passante RTCP maximale. Pour l'utilisation avec SDP, de tels modificateurs sont spécifiés dans la [RFC3556] : "b=RS:<bw>" et "b=RR:<bw>" PEUVENT être utilisés pour allouer une bande passante différente (mesurée en bits par seconde) aux envoyeurs et respectivement receveurs RTP. Les règles de préséance de la [RFC3556] s'appliquent pour déterminer la bande passante réelle à utiliser par les envoyeurs et receveurs.

Les applications qui opèrent sciemment sur des liaison très asymétriques (comme les liaisons par satellite) DEVRAIENT utiliser ce mécanisme pour réduire le taux de rétroaction pour les flux à forte bande passante pour empêcher un encombrement déterministe du chemin de rétroaction.

 	4.4	Exemples
Exemple 1 : la description de session suivante indique une session constituée d'audio et de DTMF [RFC2833] pour une communication en point à point dans laquelle le flux DTMF utilise des NACK génériques. Cette description de session pourrait être contenue dans un message SIP INVITE, 200 OK, ou ACK pour indiquer que son envoyeur est capable de, et veut recevoir une rétroaction pour le flux DTMF qu'il transmet.

v=0
o=alice 3203093520 3203093520 IN IP4 host.exemple.com
s=support avec rétroaction
t=0 0
c=IN IP4 host.exemple.com
m=audio 49170 RTP/AVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Cela permet à l'envoyeur et au receveur de fournir une transmission fiable des événements DTMF dans une session audio. En supposant un flux audio à 64 kbit/s avec un receveur, le receveur a 2,5 % de la bande passante RTCP disponible pour le flux d'accusé de réception négatif, c'est-à-dire, 250 octets par seconde ou environ deux messages RTCP de rétroaction chaque seconde. Donc, le receveur peut communiquer individuellement jusqu'à deux paquets audio DTMF manquants par seconde.

Exemple 2 : la description de session suivante indique une session de diffusion groupée en vidéo seule (utilisant H.261 ou H.263+) avec la source de vidéo qui accepte les NACK génériques pour les codecs et le choix d'image de référence pour H.263. Une telle description peut avoir été convoyée en utilisant le protocole d'annonce de session (SAP).

v=0
o=alice 3203093520 3203093520 IN IP4 host.exemple.com
s=video en diffusion groupée avec rétroaction
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi

L'envoyeur peut utiliser un NACK générique entrant comme indication pour envoyer un nouvel intra-trame aussitôt que possible (le contrôle de l'encombrement le permettant).
La réception d'un message Indication de choix d'image de référence (RPSI) permet à l'envoyeur d'éviter d'envoyer une grosse intra-trame ; à la place, il peut continuer d'envoyer des inter-trames, et cependant, choisir la trame indiquée comme nouvelle référence de codage.

Exemple 3 : la description de session suivante définit la même session de supports que dans l'exemple 2 mais permet un mode de fonctionnement mixte d'entités RTP AVP et AVPF (voir aussi au paragraphe suivant). Noter que les deux descriptions de supports utilisent les mêmes adresses ; cependant, deux lignes m= sont nécessaires pour porter les informations sur les deux profils RTP applicables.

v=0
o=alice 3203093520 3203093520 IN IP4 host.exemple.com
s=vidéo en diffusion groupée avec rétroaction
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi

Noter que ces deux lignes m= DEVRAIENT être groupées par un mécanisme approprié pour indiquer que les deux sont des alternatives qui portent en fait le même contenu. Un exemple de cadre qui peut réaliser cela est défini dans la [RFC3388].

Dans cet exemple, les receveurs capables de rétroaction RTCP vont obtenir un avantage occasionnel à rapporter plus tôt les événements à l'envoyeur (ce qui peut bénéficier au groupe entier). En moyenne, cependant, tous les receveurs RTP vont fournir la même quantité de rétroaction. L'interfonctionnement entre entités AVP et AVPF est discuté en profondeur dans la section suivante.

 	5.	Interfonctionnement et coexistence des entités AVP et AVPF

Le profil AVPF défini dans ce document est une extension du profil AVP défini dans la [RFC3551]. Les deux profils suivent les mêmes règles de base (incluant la limite supérieure de bande passante pour RTCP et les allocations de bande passante aux envoyeurs et receveurs). Donc, envoyeurs et receveurs utilisant l'un ou l'autre des deux profils peuvent être mêlés dans une seule session (voir l'exemple 3 du paragraphe 4.5).

AVP et AVPF sont définis de façon que, du point de vue de la robustesse, les entités RTP n'aient pas besoin de connaître les entités de l'autre profil : elles ne vont pas perturber le fonctionnement de chaque autre. Cependant, la qualité du support présenté peut en souffrir.

Les considérations suivantes s'appliquent aux envoyeurs et receveurs dans une session combinée.

Entités AVP (envoyeurs et receveurs)
Les envoyeurs AVP vont recevoir des paquets de rétroaction RTCP des receveurs AVPF et ignorer ces paquets. Ils vont voir un espacement occasionnel plus serré des messages RTCP (par exemple, violant la règle des cinq secondes) par des entités AVPF. Comme les contraintes globales de bande passante sont respectées par les deux types d'entités, elles vont quand même obtenir leur part de la bande passante RTCP. Cependant, alors que les entités AVP sont liées par la règle de cinq secondes, selon la taille de groupe et la bande passante de session, les entités AVPF peuvent fournir de plus fréquents rapports RTCP que les entités AVP. Aussi, les rapports globaux peuvent diminuer légèrement lorsque les entités AVPF peuvent envoyer de plus gros paquets RTCP composés (du fait des paquets RTCP supplémentaires).
Si T_rr_interval est utilisé comme limite inférieure entre paquets RTCP réguliers, T_rr_interval est suffisamment grand (par exemple, T_rr_interval > M*Td selon le paragraphe 6.3.5 de la [RFC3550]) et si aucun paquet RTCP précoce n'est envoyé par les entités AVPF, les entités AVP peuvent accidentellement considérer ces membres du groupe AVPF comme périmés et donc sous estimer la taille du groupe. Donc, si des entités AVP peuvent être impliquées dans une session de supports, T_rr_interval NE DEVRAIT PAS être de plus de cinq secondes.

Entités AVPF (envoyeurs et receveurs)
Si le T_rr calculé dynamiquement est suffisamment petit (par exemple, moins d'une seconde) les entités AVPF peuvent accidentellement considérer des membres du groupe AVP comme périmés et donc sous estimer la taille du groupe. Donc, si des entités AVP peuvent être impliquées dans une session de supports, T_rr_interval DEVRAIT être utilisé et DEVRAIT être réglé à cinq secondes.

Envoyeurs AVPF
Les envoyeurs AVPF ne vont recevoir des informations de rétroaction que des receveurs AVPF. Si ils s'appuient sur la rétroaction pour fournir la qualité de support cible, la qualité réalisée pour les receveurs AVP peut être sous optimale.

Receveurs AVPF
Les receveurs AVPF DEVRAIENT envoyer des paquets de rétroaction RTCP précoces seulement si toutes les entités envoyeuses dans la session de supports prennent AVPF en charge. Les receveurs AVPF PEUVENT envoyer des informations de rétroaction au titre des paquets RTCP composés régulièrement programmés suivant les règles de rythme de la [RFC3551] et aussi dans les sessions de supports opérant en mode mixte. Cependant, le receveur qui fournit la rétroaction NE DOIT PAS compter sur une réaction de l'envoyeur à la rétroaction.

 	6.	Format du message de rétroaction RTCP

Cette Section définit le format des messages de rétroaction RTCP à faible délai. Ces messages sont classés en trois catégories comme suit :
-	messages FB de couche Transport
-	messages FB spécifiques de charge utile
-	messages FB de couche Application

Les messages FB de couche Transport sont destinés à transmettre des informations de rétroaction générales, c'est-à-dire, des informations indépendantes du codec particulier ou de l'application utilisée. Les informations sont supposées être générées et traitées à la couche Transport/RTP. Actuellement, seul un message générique d'accusé de réception négatif (NACK) est défini.

Les messages FB spécifiques de charge utile transportent des informations qui sont spécifiques d'un certain type de charge utile et vont être générés et traités à la "couche" codec. Le présent document définit un en-tête commun à utiliser en conjonction avec tous les messages FB spécifiques de charge utile. La définition des messages spécifiques est laissée aux spécifications de format de charge utile RTP ou aux documents supplémentaires de format de rétroaction.

Les messages FB de couche Application fournissent un moyen de porter de façon transparente la rétroaction de l'application du receveur à celle de l'envoyeur. Les informations contenues dans un tel message ne sont pas supposées faire l'objet d'une action à la couche Transport/RTP ou codec. Les données à échanger entre deux instances d'application sont généralement définies dans la spécification du protocole d'application et donc peuvent être identifiées par l'application de sorte qu'il n'est pas besoin d'informations externes supplémentaires. Donc, le présent document définit seulement un en-tête commun à utiliser avec tous les messages FBl de couche application. Du point de vue d'un protocole, un message FB de couche application est traité comme un cas particulier de message FB spécifique de charge utile.

Note : le traitement approprié de certains messages FB du côté de l'envoyeur des supports peut exiger que l'envoyeur sache à quel type de charge utile le message FB se réfère. La plupart du temps, cette connaissance peut probablement être déduite d'un flux de supports utilisant un seul type de charge utile. Cependant, si plusieurs codecs sont utilisés simultanément (par exemple, avec audio et DTMF) ou quand des changements de codec surviennent, le type d'informations de charge utile peut devoir être convoyé explicitement au titre du message FB. Ceci s'applique à tous les messages FB spécifiques de charge utile ainsi que de couche application. Il appartient à la spécification d'un message FB de définir comment les informations de type de charge utile sont transmises.

Le présent document définit deux messages FB de couche transport et trois spécifiques de charge utile (vidéo) ainsi que un seul conteneur pour les messages FB de couche application. Des messages FB supplémentaires de couche transport et spécifiques de charge utile PEUVENT être définis dans d'autres documents et DOIVENT être enregistrés par l'IANA (voir la Section 9).

La syntaxe générale et la sémantique pour les types de message FB RTCP ci-dessus sont décrites dans les paragraphes qui suivent.

 	6.1	Format de paquet commun pour les messages de rétroaction
Tous les messages FB DOIVENT utiliser un format de paquet commun décrit à la Figure 3 :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|   FMT   |       PT      |          Longueur             |
+---+-+---------+---------------+---------------+---------------+
|                  SSRC de paquet envoyeur                      |
+---------------+---------------+---------------+---------------+
|                  SSRC de source du support                    |
+---------------+---------------+---------------+---------------+
:            Informations de contrôle de rétroaction            :
:                                                               :

Figure 3 : Format de paquet commun pour les messages de rétroaction

Les champs V, P, SSRC, et Longueur sont définis dans la spécification RTP [RFC3551]. Leur signification respective est résumée ci-dessous :

version (V) : 2 bits. Ce champ identifie la version RTP. La version actuelle est 2.

Bourrage (P) : 1 bit. Si il est établi (à 1) le bit de bourrage indique que le paquet contient des octets de bourrage supplémentaires à la fin qui ne font pas partie des informations de contrôle mais sont inclus dans le champ Longueur.

Type de messages de rétroaction (FMT, Feedback Message Type) : 5 bits. Ce champ identifie le type du message FB et est interprété par rapport au type (rétroaction de couche transport, spécifique de charge utile, ou de couche application). Les valeurs pour chacun des trois types de rétroaction sont définis dans les paragraphes qui suivent.

Type de charge utile (PT, Payload Type) : 8 bits. C'est le type de paquet RTCP qui identifie le paquet comme étant un message FB RTCP. Deux valeurs sont définies par l'IANA :

Nom	Valeur	Description
RTPFB	205	message FB de couche Transport
PSFB	206	message FB spécifique de charge utile

Longueur : 16 bits. La longueur de ce paquet en mots de 32 bits moins un, incluant l'en-tête et tout bourrage. C'est en ligne avec la définition du champ Longueur utilisée dans les rapports d'envoyeur et receveur RTCP [RFC4566].

SSRC du paquet envoyeur : 32 bits. pour le générateur de ce paquet.

SSRC de la source des supports : 32 bits. Identifiant de la source de synchronisation de la source des supports à laquelle cet élément d'informations de rétroaction se rapporte.

Informations de contrôle de rétroaction (FCI, Feedback Control Information) : longueur variable. Les trois paragraphes qui suivent définissent quelles informations supplémentaires PEUVENT être incluses dans le message FB pour chaque type de rétroaction : rétroaction de couche transport, spécifique de charge utile, ou rétroaction de couche application. Noter que d'autres contenus de FCI PEUVENT être spécifiés dans d'autres documents.

Chaque paquet de rétroaction RTCP DOIT contenir au moins un message FB dans le champ FCI. Les paragraphes 6.2 et 6.3 définissent pour chaque type de FCI si plusieurs messages FB PEUVENT ou non être compressés dans un seul champ FCI. Si c'est le cas, ils DOIVENT être du même type, c'est-à-dire, même FMT. Si plusieurs types de messages de rétroaction, c'est-à-dire plusieurs FMT, doivent être convoyés, alors plusieurs messages FB RTCP DOIVENT être générés et DEVRAIENT être enchaînés dans le même paquet RTCP composé.

 	6.2	Messages de rétroaction de couche Transport
Les messages FB de couche Transport sont identifiés par la valeur RTPFB comme messages de type RTCP.

Un seul message FB de couche transport d'utilité générale est défini dans ce document : NACK générique. Il est identifié au  moyen du paramètre FMT comme suit :
0 : non alloué
1 : NACK générique
2-30 : non alloués
31 : réservé pour future expansion de l'espace de numéro d'identifiant

Les paragraphes qui suivent définissent les formats du champ FCI pour ce type de message FB. De futurs messages génériques de rétroaction POURRONT être définis à l'avenir.

 	6.2.1	NACK générique
Le message NACK générique est identifié par PT=RTPFB et FMT=1.
Le champ FCI DOIT contenir au moins un NACK générique et PEUT en contenir plus d'un.

Le NACK générique est utilisé pour indiquer la perte de un ou plusieurs paquets RTP. Le ou les paquets perdus sont identifiés au moyen d'un identifiant de paquet et d'un gabarit binaire.

La rétroaction NACK générique NE DEVRAIT PAS être utilisée si le protocole de transport sous-jacent est capable de fournir des informations de rétroaction similaires à l'envoyeur (comme ce peut être le cas, par exemple, avec DCCP).
Le champ Informations de contrôle de rétroaction (FCI, Feedback Control Information) a la syntaxe suivante (Figure 4) :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PID                |             BLP               |
+---------------+---------------+---------------+---------------+

Figure 4 : Syntaxe du message NACK générique

PID (identifiant de paquet) : 16 bits. Le champ PID est utilisé pour spécifier un paquet perdu. Le champ PID se réfère au numéro de séquence RTP du paquet perdu.

BLP (bitmask of following lost packets) : 16 bits. Le gabarit binaire des paquets perdus suivants permet de rapporter la perte d'un des 16 paquets RTP qui suivent immédiatement le paquet RTP indiqué par le PID. La définition du BLP est identique à celle donnée dans la [RFC2032]. En notant comme bit 1 le bit de moindre poids du BLP, et comme bit 16 le bit de poids fort, le bit i du gabarit binaire est réglé à 1 si le receveur n'a pas reçu le paquet RTP  numéro (PID+i) (modulo 2^16) et indique que ce paquet est perdu ; le bit i est réglé à 0 autrement. Noter que l'envoyeur NE DOIT PAS supposer qu'un receveur a reçu un paquet parce que son gabarit binaire était réglé à 0. Par exemple, le bit de moindre poids du BLP va être réglé à 1 si le paquet correspondant au PID et le paquet suivant ont été perdus. Cependant, l'envoyeur ne peut pas conclure que les paquets PID+2 à PID+16 ont été reçus simplement parce que les bits 2 à 15 du BLP sont à 0 ; tout ce que l'envoyeur sait est que le receveur ne les a pas rapportés comme perdus pour l'instant.

La longueur du message FB DOIT être réglée à 2+n, avec n étant le nombre de NACK génériques contenus dans le champ FCI.

Le message NACK générique se réfère implicitement au type de charge utile par le ou les numéros de séquence.

 	6.3	Messages de rétroaction spécifiques de la charge utile
Les messages FB spécifiques de charge utile sont identifiés par la valeur PT=PSFB comme type de message RTCP.

Trois messages FB spécifiques de charge utile sont définis pour l'instant, plus un message FB de couche application. Ils sont identifiés au moyen du paramètre FMT comme suit :
0 : non alloué
1 : indication de perte d'image (PLI, Picture Loss Indication)
2 : indication de perte de tranche (SLI, Slice Loss Indication)
3 : indication de choix d'image de référence (RPSI, Reference Picture Selection Indication)
4-14 : non alloué
15 :  message FB de couche application (AFB, Application layer FB)
16-30 : non alloué
31 : réservé pour une future expansion de l'espace de numéros de séquence

Les paragraphes qui suivent définissent les formats de FCI pour les messages FB spécifiques de charge utile, le paragraphe  6.4 définit le format de FCI pour le message FB de couche application.

 	6.3.1	Indication de perte d'image (PLI)
Le message FB PLI est identifié par PT=PSFB et FMT=1.

Il DOIT y avoir exactement une PLI contenue dans le champ FCI.

 	6.3.1.1	Sémantique
Avec le message Indication de perte d'image, un décodeur informe le codeur de la perte d'un nombre indéfini de données vidéo codées appartenant à une ou plusieurs images. Quand utilisé en conjonction avec tout schéma de codage vidéo qui se fonde sur la prédiction inter images, un codeur qui reçoit un PLI est informé que la chaîne de prédiction peut être cassée. L'envoyeur PEUT réagir au PLI en transmettant une intra-image pour réaliser la resynchronisation (rendant ce message effectivement similaire au message FIR comme défini dans la [RFC2032]) ; cependant, l'envoyeur DOIT envisager le contrôle de l'encombrement comme mentionné à la Section 7, qui PEUT restreindre sa capacité à envoyer une intra trame.

D'autres spécifications de charge utile RTP comme la [RFC2032] définissent déjà un mécanisme de rétroaction pour certains codecs. Une application qui prend en charge les deux schémas DOIT utiliser le mécanisme de rétroaction défini dans la présente spécification quand elle envoie une rétroaction. Pour la rétro compatibilité, une telle application DEVRAIT aussi être capable de recevoir et réagir au schéma de rétroaction défini dans le format de charge utile RTP respectif, si c'est exigé par ce format de charge utile.

 	6.3.1.2	Format de message
PLI n'exige pas de paramètre. Donc, le champ Longueur DOIT être 2, et il NE DOIT PAS y avoir d'informations de contrôle de rétroaction.

La sémantique de ce message FB est indépendante du type de charge utile.

 	6.3.1.3	Règles de rythme
Le rythme suit les règles mentionnées à la Section 3. Dans les systèmes qui emploient à la fois le PLI et d'autres types de rétroaction, il peut être conseillé de suivre les règles de rythme de RR RTCP régulier pour PLI, car PLI n'est pas aussi critique en matière de délai que les autres types de FB.

 	6.3.1.4	Remarques
Les messages PLI déclenchent normalement l'envoi d'intra images complètes. Les intra images sont plusieurs fois plus grandes que les (inter-) images prédites. Leur taille est indépendante de l’heure à laquelle elles sont générées. Dans la plupart des environnements, en particulier quand on emploie des liaisons à bande passante limitée, l'utilisation d'une intra-image implique un délai permis qui est un multiple significatif de la durée de trame normale. Un exemple : si le taux d'envoi de trame est 10 trame/s, et si une intra-image est supposée être 10 fois de la taille d'une inter image, une pleine seconde de latence va alors devoir être acceptée. Dans un tel environnement, il n'y a pas besoin d'un court délai particulier pour l'envoi du message FB. Donc, attendre le prochain intervalle de temps possible permis par les règles de rythme de RTCP selon la [RFC3551] avec Tmin=0 n'a pas d'impact négatif sur les performances du système.

 	6.3.2	Indication de perte de tranche (SLI)
Le message FB SLI est identifié par PT=PSFB et FMT=2.

Le champ FCI DOIT contenir au moins une et PEUT contenir plus d'une SLI.

 	6.3.2.1	Sémantique
Avec l'indication de perte de tranche, un décodeur peut informer un codeur qu'il a détecté la perte ou la corruption d'un ou plusieurs macroblocs consécutifs dans l'ordre d'examen (voir ci-dessous). Ce message FB NE DOIT PAS être utilisé pour les codecs vidéo avec des tailles de macroblocs non uniformes, dynamiquement changeables comme H.263 avec Annexe Q activée. Dans un tel cas, un codeur ne peut pas toujours identifier la région spatiale corrompue.

 	6.3.2.2	Format
L'indication de perte de tranche utilise un champ FCI supplémentaire, dont le contenu est décrit à la Figure 6. La longueur du message FB DOIT être réglée à 2+n, n étant le nombre de SLI contenues dans le champ FCI.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Premier       |        Nombre           |    PID    |
+---------------+-+-+-+-+-+---------------+-+-+-+-+-+-----------+

Figure 6 : Syntaxe de l'indication de perte de tranche (SLI)

Premier : 13 bits. Adresse de macrobloc (MB) du premier macrobloc perdu. Le numérotage de MB est fait de telle façon que le MB du coin supérieur gauche de l'image est considéré comme le MB numéro 1 et le numéro pour chaque MB augmente de gauche à droite et ensuite de haut en bas dans l'ordre d'examen de l'effectif (de sorte que si il y a un total de N MB dans une image, le MB en bas à droite est considéré comme MB numéro N).

Nombre : 13 bits. Nombre de MB perdus, dans l'ordre d'examen comme mentionné ci-dessus.

PID : 6 bits. Les six bits de moindre poids de l'identifiant spécifique du codec qui est utilisé pour référencer l'image dans laquelle la perte du ou des MB s'est produite. Pour de nombreux codecs vidéo, le PID est identique à la référence temporelle.

L'applicabilité de ce message FB est limitée à un petit ensemble de codecs vidéo ; donc, aucune information explicite de type de charge utile n'est fournie.

 	6.3.2.3	Règles de temps
L'efficacité des algorithmes utilisant l'indication de perte de tranche est très réduite quand l'indication n'est pas transmise à temps. La compensation du mouvement propage des pixels corrompus qui ne sont pas rapportés comme étant corrompus. Donc, l'utilisation de l'algorithme discuté à la Section 3 est fortement recommandée.

 	6.3.2.4	Remarques
Le terme "tranche" est défini et utilisé ici dans le sens de MPEG-1  : un nombre de macroblocs consécutifs dans l'ordre d'examen. Les normes plus récentes de codage vidéo ont parfois une compréhension différente du terme "tranche". Dans H.263 (1998), par exemple, il existe un concept de "tranche rectangulaire". La perte d'une tranche rectangulaire peut conduire à la nécessité d'envoyer plus d'une SLI afin d'identifier précisément la région des MB perdus/endommagés.

Le premier champ des FCI définit le premier macrobloc d'une image comme 1 et non 0, comme on pourrait le croire. Cela a été fait pour aligner cette spécification sur le mécanisme comparable disponible dans la Recommandation UIT-T [H.245]. Le nombre maximum de macroblocs dans une image (2**13 ou 8192) correspond à la taille maximum d'image de la plupart des codecs vidéo de l'UIT-T et ISO/CEI. Si de futurs codecs vidéo offrent de plus grandes tailles d'images et/ou de plus petites tailles de macrobloc, un message FB supplémentaire devra être défini. Les six bits de moindre poids du champ Référence temporelle sont réputés être suffisants pour indiquer l'image dans laquelle la perte s'est produite.

La réaction à une SLI ne fait pas partie de cette spécification. Une façon normale de réagir à une SLI est d'utiliser le rafraîchissement intra pour la région spatiale affectée.

Des algorithmes ont été rapportés qui gardent trace des régions affectées par la compensation de mouvement, afin de permettre une transmission des intra macroblocs à toutes ces zones, sans considération du rythme de la FB (voir H.263 (2000) Appendice I [H.263] et [IEEE.87]). Bien que le rythme des FB soit moins critique quand ces algorithmes sont utilisés que si ils ne le sont pas, il a été observé que ces algorithmes corrigent de larges parties de l'image et donc, ont à transmettre un volume de données très supérieur dans le cas de FB retardées.

 	6.3.3	Indication de choix d'image de référence (RPSI)
Le message FB RPSI est identifié par PT=PSFB et FMT=3.

Il DOIT y avoir exactement une RPSI contenue dans le champ FCI.

 	6.3.3.1	Sémantique
Les normes modernes de codage vidéo comme MPEG-4 visuel version 2 [ISO.14496-2] ou H.263 version 2 [H.263] permettent d'utiliser de plus anciennes images de référence que les plus récentes pour le codage prédictif. Normalement, une file d'attente "premier entré premier sorti" d'images de référence est tenue. Si un codeur a appris une perte de synchronisation entre codeur et décodeur, une image de référence connue comme correcte peut être utilisée. Comme cette image de référence est temporellement plus loin que normalement, l'image résultante codée prédictivement va utiliser plus de bits.

MPEG-4 et H.263 définissent toutes deux un format binaire pour la "charge utile" d'un message RPSI qui inclut des informations comme l'identifiant temporel de l'image endommagée et la taille de la région endommagée. Cette chaîne de bits est normalement petite (deux douzaines de bits) de longueur variable, et auto-contenue, c'est-à-dire, elle contient toutes les informations nécessaires pour effectuer le choix de l'image de référence.

MPEG-4 et H.263 permettent toutes deux l'utilisation de RPSI avec aussi des informations de rétroaction positive. C'est-à-dire que les images (ou tranches) qui ont été décodées sans erreur sont rapportées. Noter que toute forme de rétroaction positive NE DOIT PAS être utilisée quand on est dans une session multi parties (le rapport de rétroaction positive sur des images de référence individuelles aux intervalles RTCP n'est pas supposé être très utilisé de toutes façons).

 	6.3.3.2	Format
La FCI pour le message RPSI suit le format décrit à la Figure 7 :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      PB       |0|Type de ch. u| Chaîne binaire RPSI native    |
+---------------+-+-------------+---------------+---------------+
|   défini selon le codec    ...                |  Bourrage (0) |
+---------------+---------------+---------------+---------------+

Figure 7 : Syntaxe de l'indication de choix d'image de référence (RPSI)

PB : 8 bits. Nombre de bits non utilisés requis pour bourrer la longueur du message RPSI à un multiple de 32 bits.

0 : 1 bit. DOIT être réglé à zéro à l'émission et ignoré à réception.

Type de charge utile : 7 bits. Indique le type RTP de charge utile dans le contexte où la chaîne binaire RPSI native DOIT être interprétée.

Chaîne binaire RPSI native : longueur variable. Les informations de RPSI comme définies par le vidéo codec.

Bourrage : #PB bits. Un nombre de bits réglés à zéro pour compléter le contenu du message RPSI jusqu'à la prochaine limite de 32 bits. Le nombre de bits de bourrage DOIT être indiqué par le champ PB.

 	6.3.3.3	Règles de temps
RPSI est encore plus critique au délai que les algorithmes qui utilisent SLI. C'est parce que plus le message RPSI est ancien, plus le codeur doit dépenser de bits pour rétablir la synchronisation codeur-décodeur. Voir dans [IEEE.87] des informations sur les frais généraux de RPSI pour certains scénarios de taux de perte de trames.

Donc, les messages RPSI devraient normalement être envoyés aussitôt que possible, en employant l'algorithme de la Section 3.

 	6.4	Messages de rétroaction de couche Application
Les messages FB de couche Application sont un cas particulier de message spécifique de la charge utile et sont identifiés par PT=PSFB et FMT=15. Il DOIT y avoir exactement un message FB de couche application contenu dans le champ FCI, sauf si la structure du message FB de couche application elle-même permet la mise en pile (par exemple, au moyen d'une taille fixe ou d'un indicateur de longueur explicite).

Ces messages sont utilisés pour transporter des données définies par l'application directement de l'application du receveur à celle de l'envoyeur. Les données transportées ne sont pas identifiées par le message FB. Donc, l'application DOIT être capable d'identifier la charge utile du message.

Généralement, les applications définissent leur propre jeu de messages, par exemple, les messages NEWPRED dans MPEG-4 [ISO.14496-2] (portés dans des paquets RTP conformément à la [RFC3016]) ou les messages FB dans H.263/Annexes N, U [H.263] (mis en paquet selon la [RFC2429]). Ces messages n'ont pas besoin d'informations supplémentaires provenant du message RTCP. Donc, le message d'application est simplement placé dans le champ FCI qui suit et le champ Longueur est réglé en conséquence.

Message d'application (FCI) : longueur variable. Ce champ contient le message original d'application qui devrait être transporté du receveur à la source. Le format dépend de l'application. La longueur de ce champ est variable. Si les données d'application ne sont pas alignées sur une limite de 32 bits, des bits et octets de bourrage DOIVENT être ajoutés pour réaliser l'alignement sur 32 bits.  L'identification du bourrage dépend de la couche Application et n'est pas définie dans cette spécification.

La spécification du message FB de couche application DOIT définir si le message a ou non besoin d'être interprété spécifiquement dans le contexte d'un certain codec (identifié par le type de charge utile RTP). Si une référence au type de charge utile est exigée pour un traitement approprié, la spécification du message FB de couche application DOIT définir un moyen de communiquer les informations de type de charge utile au titre de la spécification du message FB de couche application elle-même.

 	7.	Retours précoces et contrôle d'encombrement

Dans les Sections précédentes, les messages FB ont été définis ainsi que les règles de rythme selon lesquelles envoyer ces messages. La façon de réagir à la rétroaction reçue dépend de l'application utilisant les mécanismes de rétroaction et donc sort du domaine d'application du présent document.

Cependant, sut toutes les applications, il y a une exigence commune de contrôle de l'encombrement (en rapport avec TCP) sur le flux de supports comme défini dans les [RFC3550] et [RFC3551] quand on fonctionne dans un environnement de réseau au mieux.

On devrait noter que la rétroaction RTCP elle-même est insuffisante pour les besoins du contrôle de l'encombrement car il est probable qu'elle opère à des échelles de temps beaucoup plus lentes que les autres mécanismes de rétroaction de couche transport (qui opèrent généralement de l'ordre du RTT). Donc, des mécanismes supplémentaires sont requis pour effectuer un contrôle de l'encombrement approprié.

Un algorithme de contrôle de l'encombrement qui partage la bande passante disponible de façon raisonnablement équitable entre les connexions TCP en compétition, par exemple, TFRC [RFC3448], DOIT être utilisé pour déterminer le taux de données pour les flux de supports dans les limites de l'envoyeur RTP et des capacités de la session de supports si la session RTP/AVPF est transmise dans un environnement au mieux.

 	8.	Considérations sur la sécurité
Les paquets RTP qui transportent des informations avec le format de charge utile proposé sont l'objet des considérations de sécurité discutées dans la spécification RTP [RFC3550] et dans la spécification du profil RTP/AVP [RFC3551]. Ce profil ne spécifie aucun service de sécurité supplémentaire.

Ce profil modifie le comportement de rythme de RTCP et élimine l'intervalle RTCP minimum de cinq secondes et permet qu'une rétroaction plus précoce soit fournie par les receveurs. Les membres du groupe de la session RTP associée (prétendant éventuellement représenter un grand nombre d'entités) peuvent perturber le fonctionnement de RTCP en envoyant de grands nombres de paquets RTCP, réduisant par là la bande passante RTCP disponible pour les rapports RTCP réguliers ainsi que pour les messages FB précoces. (Noter qu'une entité n'a pas besoin d'être un membre d'un groupe de diffusion groupée pour causer ces effets.) De même, des membres malveillants peuvent envoyer de très gros messages RTCP, augmentant par là la variable avg_rtcp_size et réduisant la bande passante RTCP effectivement disponible.

Les informations de rétroaction peuvent être supprimées si des paquets de rétroaction RTCP inconnus sont reçus. Cela introduit le risque qu'un membre malveillant du groupe réduise la rétroaction précoce en transmettant simplement des paquets de rétroaction RTCP spécifiques de charge utile avec des contenus aléatoires qui ne sont pas reconnus par les receveurs (de sorte qu'ils vont supprimer la rétroaction) ou par l'envoyeur (de sorte qu'aucune action de réparation ne va être effectuée).

Un membre malveillant du groupe peut aussi rapporter des taux de pertes arbitrairement élevés dans les informations de rétroaction pour amener l'envoyeur à réduire la transmission des données et augmenter la quantité d'informations redondantes ou à effectuer d'autres actions pour traiter la perte de paquets prétendue (par exemple, envoyer moins de trames ou diminuer la qualité audio/video). Il peut en résulter une dégradation de la qualité du flux de supports reproduit.

Finalement, un membre malveillant du groupe peut agir comme un grand nombre de membres du groupe et par là obtenir une part artificiellement grande de la bande passante de rétroaction précoce et réduire la réactivité des autres membres du groupe – causant même éventuellement la fin de leur fonctionnement en mode de rétroaction immédiate ou précoce et donc sapant tout l'objet de ce profil.

Les envoyeurs ainsi que les receveurs DEVRAIENT se comporter de façon prudente quand ils observent des comportements de rapport étranges. Pour des rapports de défaillance excessifs provenant d'un ou quelques receveurs, l'envoyeur PEUT décider de ne plus considérer ces rétroactions quand il adapte son comportement de transmission pour le flux de supports. Dans tous les cas, les envoyeurs et receveurs DEVRAIENT quand même respecter la bande passante RTCP maximale mais s'assurer qu'ils sont capables de transmettre au moins régulièrement les paquets RTCP programmés. Les envoyeurs DEVRAIENT considérer attentivement comment ajuster leur bande passante de transmission quand ils rencontrent un comportement de rapport étrange ; ils NE DOIVENT PAS augmenter leur bande passante de transmission même si ils ignorent la rétroaction suspecte.

Les attaques utilisant des paquets RTCP falsifiés (réguliers ainsi que précoces) peuvent être évitées par l'authentification de tous les messages RTCP. Cela peut être réalisé en utilisant le profil AVPF avec le profil RTP sécurisé comme défini dans la [RFC3711] ; comme pré requis, une combinaison appropriée de ces deux profils (un "SAVPF") est en cours de spécification [RFC5124]. Noter que, quand on emploie l'authentification de groupe (par opposition à l'authentification de source) les attaques susmentionnées peuvent être menées par des membres du groupe, malveillants ou au mauvais fonctionnement, qui sont en possession du bon matériel de chiffrement.

 	9.	Considérations relatives à l'IANA

Les informations de contact suivantes devront être utilisées pour tous les enregistrements inclus ici :

Contact : Joerg Ott
                mailto :jo@acm.org
                tel :+358-9-451-2460

Le profil de rétroaction comme extension du profil pour conférences audio-visuelles avec contrôle minimal a été enregistré pour le protocole de description de session (spécifiquement le type "proto") : "RTP/AVPF".

Protocole SDP ("proto") :

Nom : RTP/AVPF
Forme longue : Profil RTP étendu avec rétroaction fondée sur RTCP
Type de nom : proto
Type d'attribut : niveau support seulement
Objet : RFC 4585
Référence : RFC 4585

Attribut SDP ("att-field") :

Nom d'attribut : rtcp-fb
Forme longue : paramètre de rétroaction RTCP
Type de nom : att-field
Type d'attribut : niveau support seulement
Soumis à un jeu de caractères : non
Objet : RFC 4585
Référence :  RFC 4585
Valeurs : voir ce document et les enregistrements ci-dessous

Un nouveau registre a été établi pour l'attribut "rtcp-fb", avec les enregistrements suivants créés initialement : "ack", "nack", "trr-int", et "app" comme défini dans le document.

Valeur initiale d'enregistrement pour l'attribut "rtcp-fb"
Nom de la valeur : ack
Nom long : accusé de réception positif
Référence : RFC 4585.

Nom de la valeur : nack
Nom long : accusé de réception négatif
Référence : RFC 4585.

Nom de la valeur : trr-int
Nom long : intervalle minimal de rapport de receveur
Référence : RFC 4585.

Nom de la valeur : app
Nom long : paramètre définipar l'application
Référence : RFC 4585.

D'autres entrées peuvent être enregistrées sur la base du premier arrivé premier servi. Chaque nouvel enregistrement doit indiquer le nom de paramètre et la syntaxe des éventuels arguments supplémentaires. Pour chaque nouvel enregistrement, il est obligatoire qu'un document permanent, stable, et publiquement accessible existe qui spécifie la sémantique du paramètre enregistré, la syntaxe et la sémantique de ses paramètres ainsi que les formats correspondants de paquet de rétroaction (si nécessaire). Les procédures générales d'enregistrement de la [RFC4566] s'appliquent.

Pour l’usage de "ack" et "nack", un sous registre joint a été établi qui enregistre initialement les valeurs suivantes :

Valeur initiale d'enregistrement pour les valeurs d'attribut "ack" et "nack" :
Nom de la valeur : sli
Nom long : Indication de perte de tranche
Utilisable avec : nack
Référence : RFC 4585.

Nom de la valeur : pli
Nom long : Indication de perte d'image
Utilisable avec : nack
Référence : RFC 4585.

Nom de la valeur : rpsi
Nom long : Indication du choix d'image de référence
Utilisable avec : ack, nack
Référence : RFC 4585.

Nom de la valeur : app
Nom long : rétroaction de couche application
Utilisable avec : ack, nack
Référence : RFC 4585.

D'autres entrées peuvent être enregistrées sur la base du premier arrivé premier servi. Chaque enregistrement doit indiquer le nom du paramètre et la syntaxe des éventuels arguments supplémentaires, et si le paramètre est applicable à la rétroaction "ack" ou "nack" ou aux deux ou à un paramètre d'attribut "rtcp-fb" différent. Pour chaque nouvel enregistrement, il est obligatoire qu'un document permanent, stable, et publiquement accessible existe qui spécifie la sémantique du paramètre enregistré, la syntaxe et la sémantique de ses paramètres ainsi que les formats correspondants de paquet de rétroaction (si nécessaire). Les procédures générales d'enregistrement de la [RFC4566] s'appliquent.

Deux types de paquet de contrôle RTCP : pour la classe des messages FB de couche transport ("RTPFB") et pour la classe de messages FB spécifiques de charge utile ("PSFB"). Selon la Section 6, RTPFB=205 et PSFB=206 ont été ajoutés au registre RTCP.

Types de paquet de contrôle RTP RTCP (PT) :
Nom : RTPFB
Nom long : rétroaction RTP générique
Valeur : 205
Référence : RFC 4585.

Nom : PSFB
Nom long : spécifique de charge utile
Valeur : 206
Référence :RFC 4585.

Comme AVPF définit des types supplémentaires de charge utile RTCP, l'espace correspondant de type de charge utile RTP  "réservé" (72-76, comme défini dans la [RFC3551]) a été étendu en conséquence.

Un nouveau sous registre a été établi pour les valeurs de FMT pour les deux types de charge utile RTPFB et PSFB, avec les enregistrements initiaux créés :

Dans la gamme RTPFB, les deux valeurs de format (FMT) suivantes sont enregistrées initialement :
Nom : NACK générique
Nom long : accusé de réception négatif générique
Valeur : 1
Référence : RFC 4585.

Nom : Extension
Nom long : Réservé pour futures extensions
Valeur : 31
Référence : RFC 4585.

Dans la gamme PSFB, les cinq valeurs de format (FMT) suivantes sont enregistrées initialement :
Nom : PLI
Nom long : Indication de perte d'image
Valeur : 1
Référence : RFC 4585.

Nom : SLI
Nom long : Indication de perte de tranche
Valeur : 2
Référence : RFC 4585.

Nom : RPSI
Nom long :  Indication du choix d'image de référence
Valeur : 3
Référence : RFC 4585.

Nom : AFB
Nom long : rétroaction de couche application
Valeur : 15
Référence : RFC 4585.

Nom : Extension
Nom long : Réservé pour futures extensions.
Valeur : 31
Référence : RFC 4585.

D'autres entrées peuvent être enregistrées suivant les règles de "spécification exigée" comme défini dans la [RFC2434]. Chaque enregistrement doit indiquer la valeur de FMT, si il y a un message FB spécifique qui va dans le champ FCI, et si plusieurs messages FB peuvent ou non être mis en pile dans un seul champ FCI. Pour chaque nouvel enregistrement, il est obligatoire qu'un document permanent, stable, et publiquement accessible existe qui spécifie la sémantique du paramètre enregistré, ainsi que la syntaxe et la sémantique du message FB associé (s'il en est). Les procédures générales d'enregistrement de la [RFC4566] s'appliquent.

 	10.	Remerciements

Le présent document est un produit du groupe de travail Transport audio-visuel (AVT, Audio-Visual Transport) de l'IETF. Les auteurs tiennent à remercier Steve Casner et Colin Perkins de leurs commentaires et suggestions ainsi que de leurs réponses à de nombreuses questions. Les auteurs tiennent aussi à remercier particulièrement Magnus Westerlund de sa relecture et de ses précieuses suggestions, ainsi que Shigeru Fukunaga pour ses contributions au format et à la sémantique du message FB.

Merci aussi à Andreas Buesching et aux personnels de Panasonic de leurs simulations et de la première mise en œuvre indépendante du profil de rétroaction.

 	11.	Références
 	11.1	Références normatives

[RFC2032]	T. Turletti et C. Huitema, "Format de charge utile RTP pour les flux vidéo H.261", octobre 1996. (Obs. voir RFC4587)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par  RFC8843)

[RFC3448]	M. Handley, S. Floyd, J. Padhye, J. Widmer, "Contrôle de débit convivial sur TCP (TFRC) : Spécification du protocole", janvier 2003. (Obsolète, voir RFC5348) (P.S.)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC3551]	H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003. (MàJ par RFC8860)

[RFC3556]	S. Casner, "Modificateurs de bande passante du protocole de description de session (SDP) pour la bande passante du protocole de contrôle de RTP (RTCP)", juillet 2003. (P.S.)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

 	11.2	Références pour information

[H.245]	Recommandation UIT-T H.245, "Protocole de contrôle pour communications multimédia", mai 2006.

[H.263]	Recommandation UIT-T H.263, "Codage vidéo pour communication à bas débit", novembre 2000.

[IEEE.87]	B. Girod, N. Faerber, "Feedback-based error control for mobile video transmission", Proceedings IEEE, Vol. 87, No. 10, pp. 1707 - 1723, octobre 1999.

[ISO.14496-2]	ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology - Coding of audio-visual objects - Part2: Visual", 2001.

[RFC2198]	C. Perkins et autres, "Charge utile RTP pour données audio redondantes", septembre 1997. (P.S.)

[RFC2354]	C. Perkins et O. Hodson, "Options pour réparer un support de direct", juin 1998. (Information)

[RFC2429]	C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger et C. Zhu, "Format de charge utile RTP pour la version 1998 de la Rec. UIT-T H.263 Vidéo (H.263+)", octobre 1998. (Obs. Voir RFC 4629)

[RFC2733]	J. Rosenberg et H. Schulzrinne, "Format de charge utile RTP pour la correction d'erreur directe générique", décembre  1999. (Obsolète, voir RFC5109) (P.S.)

[RFC2833]	H. Schulzrinne, S. Petrack, "Charge utile RTP pour chiffres DTMF, tonalités téléphoniques et signaux téléphoniques", mai  2000. (Obsolète, voir RFC4733, RFC4734) (P.S.)

[RFC3016]	Y. Kikuchi et autres, "Format de charge utile RTP pour flux audio/vidéo MPEG-4", novembre 2000. (Obs., voir RFC6416) (P.S.)

[RFC3388]	G. Camarillo, G. Eriksson, J. Holler et H. Schulzrinne, "Groupage des lignes de support dans le protocole de description de session (SDP)", décembre 2002. (Remplacée par RFC5888)

[RFC3448]	M. Handley, S. Floyd, J. Padhye, J. Widmer, "Contrôle de débit convivial sur TCP (TFRC) : Spécification du protocole", janvier 2003. (Obsolète, voir RFC5348) (P.S.)

[RFC3711]	M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004. (P.S.)

[RFC4340]	E. Kohler et autres, "Protocole de contrôle d'encombrement de datagrammes (DCCP)", mars 2006. (P.S.) (MàJ par 6773)

[RFC5124]	J. Ott, E. Carrara, "Profil étendu de RTP sécurisé pour les rétroactions fondées sur le protocole de contrôle du transport en temps réel (RTCP)", février 2008. (P.S.)

 	Adresse des auteurs
Joerg Ott	Stephan Wenger	Noriyuki Sato	
Helsinki University of Technology (TKK)	Nokia Research Center	Oki Electric Industry Co., Ltd.	
Networking Laboratory	P.O. Box 100	1-16-8 Chuo, Warabi-city	
PO Box 3000	33721 Tampere	Saitama 335-8510	
FIN-02015 TKK	Finland	Japan	
Finland	mél : stewe@stewe.org 	mél : sato652@oki.com 	
mél : jo@acm.org 			

Jose Rey	Carsten Burmeister	
Panasonic R&D Center Germany GmbH	Panasonic R&D Center Germany GmbH	
Monzastr. 4c	mél : carsten.burmeister@eu.panasonic.com 	
D-63225 Langen, Germany		
mél : jose.rey@eu.panasonic.com 		

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.