Groupe de travail Réseau	I. Johansson, Ericsson AB
Request for Comments: 5506	M. Westerlund, Ericsson AB
RFC mises à jour : 3550, 3711, 4585	avril 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Prise en charge du protocole de contrôle du transport en temps réel à taille réduite (RTCP) : opportunités et conséquences

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent mémoire discute des avantages et inconvénients qui découlent de permettre aux paquets du protocole de contrôle du transport en temps réel (RTCP, Real-time Transport Control Protocol) d'être transmis avec une taille réduite. La taille peut être réduite si les règles sur la façon de créer des paquets composés mentinnées dans la RFC 3550 sont supprimées ou changées. Sur la base de cette analyse, le présent mémoire définit certains changements aux règles pour permettre d'envoyer des messages de rétroaction comme paquets RTCP à taille réduite sous certaines conditions quand on utilise le profil RTP/AVPF (profil audio-visuel du protocole de transport en temps réel avec rétroactions) (RFC 4585). Le présent document met à jour les RFC 3550, RFC 3711, et RFC 4585.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Cas d'utilisation et raisons de la conception	3
3.1 Paquets RTCP composés (fondements)	3
3.2. Cas d'utilisation de RTCP à taille réduite	3
3.3 Avantages de RTCP à taille réduite	4
3.4 Problèmes de RTCP à taille réduite	5
4. Utilisation de RTCP à taille réduite avec AVPF	6
4.1 Définition de RTCP à taille réduite	7
4.2 Considérations d'algorithme	7
5. Signalisation	8
6. Considérations sur la sécurité	8
7. Considérations relatives à l'IANA	8
8. Remerciements	9
9. Références	9
9.1 Références normatives	9
9.2 Références pour information	10
Adresse des auteurs	10

 	1.	Introduction

Dans RTP [RFC3550] il est actuellement obligatoire d'envoyer des paquets du protocole de contrôle RTP (RTCP, RTP Control Protocol) comme des paquets composés contenant au moins un rapport d'envoyeur (SD, Sender Report) ou un rapport de receveur (RR, Receiver Report) suivi par un paquet de description de source (SDES, Source Description) contenant au moins l'élément CNAME. Il y a de bonnes raisons pour cela, comme discuté ci-dessous (voir le paragraphe  3.1) ; cependant, il n'en résulte pas que les paquets RTCP minimaux soient très grands.

Le profil RTP/AVPF [RFC4585] spécifie de nouveaux types de paquet RTCP pour les messages de rétroaction. Certains de ces messages de rétroaction auraient avantage à être transmis avec un délai minimal. AVPF fournit des mécanismes pour prendre cela en charge ; cependant, dans des environnements de liaison à faible débit, ces messages peuvent quand même consommer une grande quantité de ressources et peuvent introduire un délai supplémentaire par le temps qu'il faut pour envoyer complètement le paquet composé dans le réseau. Il est donc souhaitable d'envoyer juste la rétroaction, sans les autres parties d'un paquet RTCP composé. Le présent mémoire propose un tel mécanisme pour cela et d'autres cas d'utilisation, comme discuté au paragraphe 3.2.

Les avantages de RTCP à taille réduite sont discutés au paragraphe 3.3.

Les inconvénients de l'utilisation de RTCP à taille réduite sont discutés au paragraphe 3.4. Ces inconvénients doivent être pris en compte et font partie de la motivation de ce document.

Finalement, le présent document définit comment AVPF est mis à jour pour permettre la transmission de RTCP à taille réduite d'une façon qui n'affecte pas de façon substantielle les mécanismes que fournissent les paquets composés ; voir les détails à la Section 4. La connexion à AVPF (ou SAVPF [RFC5124]) est motivée par le fait que RTCP à taille réduite est principalement avantageux pour les besoins des rétroactions conduites par l'événement et les modes RTCP d'AVPF précoce et de rétroaction immédiate rendent cela possible.

Le présent document met à jour les [RFC3550], [RFC3711], et [RFC4585].

 	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],.

Les conventions de dénomination pour RTCP sont souvent confuses. Voici une liste de termes de RTCP et de leur signification. Voir aussi au paragraphe 6.1 de la [RFC3550] et au paragraphe 3.1 de la [RFC4585] pour les détails.

Paquet RTCP : peut être de différents types ; il contient une partie d'en-tête fixe suivie par des éléments structurés selon le type de paquet RTCP.

Datagramme de couche inférieure : peut être interprété comme la charge utile UDP. Ce peut cependant être, selon le transport, une charge utile TCP ou du protocole de contrôle d'encombrement de datagrammes (DCCP, Datagram Congestion Control Protocol) ou quelque chose d'autre. Synonyme de "protocole sous-jacent" défini à la Section 3 de la [RFC3550].

Paquet RTCP composé : collection de deux paquets RTCP ou plus. Un paquet RTCP composé est transmis dans un datagramme de couche inférieure. Il doit contenir au moins un paquet RTCP RR ou SR et un paquet SDES avec l'élément CNAME. Souvent "composé" est omis, l'interprétation du paquet RTCP dépend donc du contexte.

Paquet RTCP composé minimal : paquet RTCP composé qui contient le paquet RTCP RR ou SR et le paquet SDES avec l'élément CNAME dans un ordre spécifié.

Paquet RTCP composé complet : paquet RTCP composé qui se conforme aux exigences sur les paquets RTCP composés  minimaux et contient plus de paquets RTCP.

Paquet RTCP à taille réduite : peut contenir un ou plusieurs paquets RTCP mais ne suit pas les règles de RTCP composé définies au paragraphe 6.1 de la [RFC3550] et n'est donc ni minimal ni RTCP composé complet. Voir la définition complète au paragraphe 4.1.

 	3.	Cas d'utilisation et raisons de la conception
 	3.1	Paquets RTCP composés (fondements)
Le paragraphe 6.1 de la [RFC3550] spécifie qu'un paquet RTCP doit être envoyé comme un paquet RTCP composé consistant en au moins deux paquets RTCP individuels, d'abord un rapport d'envoyeur (SR) ou un rapport de receveur (RR) suivi par des paquets supplémentaires incluant un paquet SDES obligatoire contenant un élément CNAME pour l'identifiant de source transmetteuse. Voici une brève description de l'utilisation de ces types de paquet RTCP.

1.	Les rapports d'envoyeur et de receveur (voir le paragraphe 6.4 de la [RFC3550]) fournissent au participant à la session RTP l'identifiant de la source de synchronisation (SSRC, Synchronization Source) de tous les participants à la session RTP. Avoir tous les participants qui envoient ces paquets périodiquement permet à chacun de déterminer le nombre actuel de participants. Cette information est utilisée dans l'algorithme de programmation de transmission. Donc, c'est particulièrement important pour que les nouveaux participants puissent rapidement établir une bonne estimation de la taille du groupe. Y manquer résulterait en ce que les envoyeurs RTCP consommeraient trop de bande passante.

2.	Avant qu'un nouveau participant à une session ait envoyé de paquet RTP ou RTCP, il peut aussi éviter des collisions de SSRC avec toutes les SSRC qu'il voit avant cette transmission. Donc la possibilité de voir une proportion substantielle des sources participantes minimise le risque de collision lors du choix de la SSRC.

3.	Les rapports d'envoyeur et de receveur contiennent des statistiques de base utilisables pour surveiller le transport et donc permettre l'adaptation. Ces rapports deviennent plus utiles si ils sont envoyés régulièrement, car le receveur d'un rapport peut effectuer des analyses pour trouver des tendances entre les rapports individuels. Quand elles sont utilisées pour l'adaptation de la transmission des supports, les informations deviennent plus utiles si leur réception est plus fréquente, au moins jusqu'à ce qu'un rapport par temps d'aller-retour (RTT, round-trip time) soit réalisé. Donc, il n'y a dans la plupart des cas aucune raison de ne pas inclure de rapport d'envoyeur ou de receveur dans chaque paquet RTCP.

4.	L'élément CNAME SDES (voir le paragraphe 6.5.1 de la [RFC3550]) existe pour permettre aux receveurs de déterminer quels flux de supports devraient être synchronisés les uns avec les autres, dans une session RTP et entre des sessions RTP différentes portant des types de supports différents. Donc, il est important de recevoir rapidement cela pour chaque envoyeur de supports dans la session lors de la jonction à une session RTP.

5.	Les rapports d'envoyeur (SR) sont utilisés en combinaison avec le mécanisme SDES CNAME ci-dessus pour synchroniser plusieurs flux RTP, comme de l'audio et de la vidéo. Après avoir déterminé quels flux de supports devraient être synchronisés en utilisant le champ CNAME, le receveur utilise les champs d'horodatage NTP et RTP de  rapport d'envoyeur pour établir la synchronisation.

6.	L'élément CNAME SDES permet aussi à un participant à une session de détecter des collisions de SSRC et de les séparer des boucles d'acheminement. La SSRC de 32 bits, choisie au hasard a une certaine probabilité de collision. Le CNAME est utilisé comme plus long identifiant canonique d'une instance de point d'extrémité particulier qui est liée à une SSRC. Si ce lien n'est pas reçu et gardé actif, le receveur ne peut pas détecter une collision de SSRC, c'est-à-dire, deux différents CNAME utilisant la même SSRC. Il ne peut pas non plus détecter une boucle d'acheminement de niveau RTP, avec pour résultat que les mêmes SSRC et CNAME arrivent de plusieurs adresses de source de couche inférieure.

En recevant ce qui est mentionné ci-dessus, il est évident que le SR/RR et le CNAME sont tous deux très importants pour que les nouveaux participants à une session soient capables d'utiliser les supports reçus et pour éviter d'inonder le réseau avec des rapports RTCP. De plus, la nature dynamique des informations fournies les rendraient moins utiles si elles ne sont pas envoyées régulièrement.

Les paragraphes qui suivent décrivent les cas où RTCP à taille réduite est avantageux et vont aussi montrer les problèmes possibles qui doivent être considérés.

 	3.2.	Cas d'utilisation de RTCP à taille réduite
Quelques cas d'utilisation de RTCP à taille réduite sont indiqués ci-dessous.

Signalisation du plan de contrôle : le bouton poussoir sur cellulaire (PoC, Push-to-talk over Cellular) de l'alliance mobile ouverte (OMA, Open Mobile Alliance) [OMA-PoC] utilise RTCP à taille réduite pour transmettre certains événements.  Le service PoC de l'OMA est principalement utilisé sur des liaisons cellulaires capables de transport IP, comme le service général de paquet radio (GPRS, General Packet Radio Service) du système mondial de connexions mobiles (GSM, Global System for Mobile Connections).

Signalisation de contrôle de codec : un exemple qui peut être utilisé avec RTCP à taille réduite est, par exemple, celui des messages de demande du taux binaire de flux de supports maximum temporaire (TMMBR, Temporary Maximum Media Stream Bitrate Request) comme spécifié dans la [RFC5104], qui signalent une demande de changement du débit binaire d'un codec. Ces messages bénéficient de l'usage de RTCP à taille réduite dans des conditions de mauvais canal, car RTCP à taille réduite a plus de chances d'être transmis avec succès que de plus grands RTCP composés. Ceci est critique, car ces messages vont probablement survenir quand les conditions du canal sont mauvaises. D'autres exemples d'usage de contrôle de codec pour RTCP à taille réduite se trouvent dans [MTSI-3GPP].

Rétroaction : un exemple de scénario de rétroaction qui bénéficierait de RTCP à taille réduite est celui de flux vidéo avec des NACK génériques. Dans les cas où le RTT est plus court que la profondeur de mémoire tampon du receveur, le NACK générique peut être utilisé pour demander la retransmission des paquets manquants, améliorant donc considérablement la qualité d'exécution. Si les paquets de NACK générique sont transmis comme des RTCP à taille réduite, l'exigence de bande passante pour RTCP va être minimale, permettant des rétroactions plus fréquentes. Comme dans le cas du contrôle de codec, il est important que ces paquets puissent être transmis avec aussi peu de délai que possible. Une autre utilisation intéressante de RTCP à taille réduite est dans les cas où des rétroactions régulières sont nécessaires, comme décrit au paragraphe 3.3.

Rapports d'état : une idée proposée est de transmettre de petits rapports de mesure ou d'état dans des RTCP à taille réduite, et de partager le RTCP composé minimal et de transmettre les RTCO individuels séparément. Les rapports d'état peuvent être utilisés par les points d'extrémité ou par d'autres boîtes de surveillance du réseau dans le réseau. L'avantage  est que, avec certaines technologies d'accès radio, les petits paquets sont plus robustes aux mauvaises conditions radio que les grands paquets. De plus, avec de petits paquets (rapports) il y a moins de risque que les paquets de rapport affectent le canal sur lequel ils rapportent. Un autre avantage est qu'il est possible, avec RTCP à taille réduite, de permettre, par exemple, qu'un rapport d'état anonyme soit transmis sans chiffrement. C'est quelque chose qui peut être bénéfique, par exemple, pour les besoins de la surveillance du réseau.

 	3.3	Avantages de RTCP à taille réduite
Comme mentionné dans l'introduction, la plupart des avantages de l'utilisation de paquets RTCP à taille réduite existent dans les cas où le débit binaire RTCP disponible est limité. C'est parce que ils peuvent devenir substantiellement plus petits que les paquets composés. Un paquet composé est forcé de contenir à la fois un RR ou un SR et l'élément SDES CNAME. Le RR contenant un bloc de rapport pour une seule source fait 32 octets, un SR fait 52 octets. Les deux peuvent être plus grands si ils contiennent des blocs de rapport pour plusieurs sources. Le paquet SDES contenant un élément CNAME va faire 10 octets plus la longueur de la chaîne CNAME. Ici, il est raisonnable que la chaîne de CNAME soit au moins de 10 octets pour obtenir une résistance décente à la collision. Si la forme recommandée de usager@hôte est utilisée, alors la plupart des chaînes vont faire plus de 20 caractères. Donc, un RTCP à taille réduite peut devenir plus petit d'au moins 70 à 80 octets que le paquet composé.

Pour les liaisons à faible débit binaire, les avantages de cette réduction de taille sont les suivants :

o	Pour les liaisons où le taux de perte de paquet croît avec la taille de paquet, les plus petits paquets ont moins de chances d'être éliminés. Les liaisons radio sont un exemple de telles liaisons. Dans le monde cellulaire, il existe des liaisons qui sont optimisées pour traiter des paquets RTP dont la dimension est étudiée pour porter de la parole compressée. Cela augmente la capacité et la couverture des services vocaux dans un réseau sans fil donné. Les paquets RTCP composés minimaux font couramment 2 à 3 fois la taille d'un paquet RTP portant de la parole compressée. Si le paquet de parole sur un tel support a une probabilité de perte de paquet de p, alors le paquet RTCP va subir une probabilité de perte de 1-(1-p)^x, où x est le nombre de fragments dont le paquet composé va être constitué à la couche de liaison, c'est-à-dire, couramment 2 ou 3 fragments.

o	Il y a un temps de mise en série plus court, c'est-à-dire, le temps que prend la liaison pour transmettre le paquet. Pour les liaisons les plus lentes, ce temps peut être substantiel. Par exemple, transmettre 120 octets sur une interface de liaison capable de 30 kbit/s prend 32 millisecondes (ms), en supposant un taux de transmission uniforme.

Dans les cas où RTCP à taille réduite porte des rétroactions importantes et sensibles au délai, un temps de mise en série plus court et la plus faible probabilité de pertes sont toutes deux importantes pour permettre les meilleures fonctions possibles. Avoir un taux de perte de paquet bien supérieur pour les paquets de rétroaction que celui des paquets de supports choque quand on essaye d'effectuer l'adaptation du support pour, par exemple, traiter le changement de performances présent à la bordure de cellule dans un système  cellulaire.

Pour des applications à débit binaire élevé, il n'y a généralement pas de problème pour fournir des débits binaires suffisants à RTCP. Quand on utilise AVPF, on peut utiliser le paramètre "trr-int" pour réduire l'intervalle de rapport régulier à approximativement un par RTT ou moins. Comme dans la plupart des cas, il n'y a pas de raisons de fournir des rapports réguliers plus fréquents, toute la bande passante supplémentaire peut alors être utilisée pour les messages de rétroaction. L'avantage de RTCP à taille réduite est limité dans ce cas, mais existe. Un exemple typique est la vidéo qui utilise des NACK génériques dans les cas où le RTT est faible. Utiliser un RTCP à taille réduite réduirait la quantité totale de bits utilisés pour RTCP. Ceci est principalement applicable si le nombre de rapports est grand. Cela résulterait aussi en moindres délais de traitement et moins de complexité pour les paquets de rétroaction, car ils n'ont pas besoin d'interroger la base de données de RTCP pour construire les bons messages.

Comme la taille de message pose généralement moins de problèmes à des débits élevés, il est aussi possible de transmettre plusieurs RTCP dans chaque datagramme de couche inférieure dans ce cas. La motivation de RTCP à taille réduite dans ce cas n'est pas la taille, mais plutôt d'éviter les frais généraux supplémentaires causés par l'inclusion des éléments SR/RR et SDES CNAME dans chaque RTCP transmis.

Indépendamment du type de liaison, il y a des avantages supplémentaires à l'envoi de rétroaction dans un petit RTCP à taille réduite. Les applications qui utilisent RTCP AVPF en mode RTCP précoce ou rétroaction immédiate ont besoin d'envoyer de fréquentes rétroactions commandées par les événements. Dans ces circonstances, le risque que la bande passante RTCP devienne trop élevée durant les périodes de lourde signalisation de rétroaction est réduit.

Dans les cas où des rétroactions régulières sont nécessaires, comme dans le profil en cours de développement pour le contrôle de taux favorable à TCP pour RTP [TCP-FRIEND], la taille des RTCP composés peut résulter en exigences de bande passante très élevées si le délai d'aller-retour est court. Pour cette application particulière, RTCP à taille réduite donne une amélioration très substantielle.

 	3.4	Problèmes de RTCP à taille réduite
Cette section décrit les problèmes connus de RTCP à taille réduite et fait aussi une brève analyse de leurs effeets et des moyens de les corriger.

 	3.4.1	Boîtiers de médiation
Les boîtiers de médiation dans le réseau peuvent éliminer le RTCP qui ne suit pas les règles mentionnées au paragraphe 6.1 de la RFC 3550. De nouveaux types de rapport peuvent être interprétés comme inconnus par le boîtier de médiation. Par exemple, si le numéro de type de la charge utile est 207 au lieu de 200 ou 201, il peut être traité comme inconnu. Cela pourrait avoir pour effet, par exemple, que le RTCP composé passerait tandis que le RTCP à taille réduite serait perdu.

La vérification de la livraison de RTCP à taille réduite est discutée au paragraphe 4.2.1.

 	3.4.2	Validation de paquet
Un paquet RTCP à taille réduite va être éliminé par le code de validation de paquet de l'Appendice A de la [RFC3550]. Cela a plusieurs impacts :

Validation de paquet affaiblie : le code de validation de paquet doit être réécrit pour accepter RTCP à taille réduite. En particulier, cela affecte le paragraphe 9.1 de la [RFC3550] en ce sens que la vérification d'en-tête doit tenir compte de ce que les numéros de type de charge utile pour le (premier) RTCP dans le datagramme de couche inférieure peuvent différer de 200 ou 201 (SR ou RR). Un effet potentiel de ce changement est une validation beaucoup plus faible que les paquets reçus sont réellement des paquets RTCP et non des paquets d'un autre type livrés à tort. Donc, une certaine attention devrait être portée à s'assurer que la meilleure validation possible est disponible, par exemple, de restreindre RTCP à taille réduite à contenir seulement des types spécifiques de paquet RTCP qui sont de préférence signalés session par session. Cependant, l'application d'un mécanisme de sécurité pour l'authentification de source sur les paquets va fournir une protection bien plus forte.

Vieux receveurs RTP :  tout receveur RTCP sans un code de validation de paquet mis à jour va éliminer le RTCP à taille réduite, ce qui signifie que le receveur ne va pas voir, par exemple, les messages de rétroaction contenus. L'effet de cela dépend du type de message de rétroaction et du rôle du receveur. Par exemple, cela peut causer une complète perte de fonction dans le cas d'une tentative d'envoi d'un message NACK à taille réduite (voir le paragraphe 6.2.1 de la [RFC4585]) à un envoyeur de supports non mis à jour dans une session utilisant le schéma de retransmission défini par la [RFC4588]. Ce type d'élimination affecterait aussi la suppression de rétroaction définie dans l'AVPF. Le résultat serait une partition des receveurs au sein de la session, les vieux receveurs voyant seulement les messages de rétroaction de RTCP composé, et les plus récents qui voient les deux. Dans ce cas, les vieux receveurs peuvent envoyer des messages de rétroaction pour des événements déjà rapportés dans le RTCP à taille réduite.

Considérations de bande passante : l'élimination de RTCP à taille réduite affecterait le calcul de transmission RTCP en ce que la valeur de "avg_rtcp_size" deviendrait plus grande que pour les receveurs RTP qui excluent le RTCP à taille réduite dans ce calcul (en supposant que les RTCP à taille réduite sont plus petits que les composés). Donc, ces envoyeurs sous utiliseraient le débit binaire disponible et enverraient avec un plus long intervalle que les receveurs à jour. Pour la plupart des sessions, cela ne devrait pas être un problème. Cependant, pour des sessions avec une grande portion de RTCP à taille réduite, les receveurs mis à jour pourraient périmer prématurément les envoyeurs non mis à jour. Ceci n'a cependant que peu de chances de se produire, car le temps entre les transmissions de RTCP composé devrait devenir cinq fois celui qui est utilisé par les envoyeurs de RTCP à taille réduite pour que cela se produise.

Calcul de avg_rtcp_size : de longs intervalles entre des RTCP composés avec de nombreux RTCP à taille réduite entre eux peuvent conduire à un calcul d'une valeur de avg_rtcp_size qui varie beaucoup dans le temps. Les recherches montrent que bien qu'il varie, ce n'est pas un problème suffisant pour obliger à d'autres changements ou plus de complexité de l'algorithme de programmation de RTCP.

 	3.4.3	Chiffrement/authentification
Le protocole sûr de transport en temps réel (SRTP, Secure Real-time Transport Protocol) présente un problème pour RTCP à taille réduite. Le paragraphe 3.4 de la [RFC3711] déclare "SRTCP DOIT recevoir des paquets conformes à cette exigence en ce sens que la première partie DOIT être un rapport d'envoyeur ou un rapport de receveur."

En examinant comment SRTP traite les paquets, il devient évident que SRTP n'a pas de réelle dépendance au fait que le premier paquet soir un paquet SR ou RR. Ce qui est nécessaire est l'en-tête commun de paquet RTCP, qui est présent dans tous les types de paquets, avec une SSRC. La conclusion est donc qu'il est possible d'utiliser RTCP à taille réduite avec SRTP. Néanmoins, comme cela implique un changement aux règles de la [RFC3711], des changements dans les mises en œuvre de SRTP PEUVENT devenir nécessaires.

 	3.4.4	Multiplexage RTP et RTCP sur le même accès
Dans les applications dans lesquelles des multiplex RTP et RTCP sont sur le même accès, comme défini dans la [RFC5761], il faut veiller à s'assurer que le démultiplexage est fait correctement même quand les paquets RTCP sont de taille réduite. L'inconvénient de RTCP à taille réduite est qu'il existe plus de valeurs représentant les paquets RTCP, ce qui réduit l'espace de type de charge utile RTP disponible. Cependant, la Section 4 de la [RFC5761] exige déjà que la gamme de type de charge utile RTP correspondante ne soit pas utilisée lorsque ce multiplexage est effectué.

 	3.4.5	Compression d'en-tête
Deux problèmes se rapportent à la compression d'en-tête. Les changements possibles feront l'objet de travaux futurs :

o	Identification du numéro de type de charge utile : l'algorithme  de compression robuste d'en-tête RoHC, Robust Header Compression) [RFC3095] a besoin de créer des contextes de compression différents pour RTP et RTCP pour des performances optimales. Si RTP et RTCP sont multiplexés sur le même accès, la classification peut être fondée sur les numéros de type de charge utile. L'algorithme de classification doit ici reconnaître le fait que le numéro de type de charge utile pour (le premier) RTCP peut différer de 200 ou 201.

o	Compression de RTCP : aucune méthode de compression d'en-tête définie par l'IETF ne compresse RTCP ; cependant, si de telles méthodes étaient développées à l'avenir, ces méthodes devront tenir compte de RTCP à taille réduite.

 	4.	Utilisation de RTCP à taille réduite avec AVPF

Sur la base de l'analyse ci-dessus, il semble faisable de permettre la transmission de RTCP à taille réduite sous certaines restrictions :

o	Tout d'abord, il est important que les paquets de RTCP composés soient transmis à des intervalles réguliers pour assurer que les mécanismes effectués par les paquets composés, comme le rapport des rétroactions, fonctionnent. Le suivi de la taille de session et du nombre de participants doit être encore mentionné, car cela assure que la bande passante RTCP reste limitée indépendamment du nombre des participants à la session.

o	Ensuite, comme les paquets RTCP composés sont aussi utilisés pour établir et maintenir la synchronisation entre les supports, tout nouveau participant qui se joint à une session va devoir recevoir le RTCP composé de la part du ou des envoyeurs de supports.

Cela implique que la transmission régulière de RTCP composé DOIT être maintenue pendant toute une session RTP. RTCP à taille réduite DEVRAIT être restreint à l'utilisation comme extra RTCP (par exemple, des rétroactions) envoyé dans des cas où un paquet RTCP composé régulier n'aurait autrement pas été envoyé.

L'usage de RTCP à taille réduite DEVRA seulement être fait dans les sessions RTP opérant en AVPF [RFC4585] ou SAVPF [RFC5124] en mode RTCP précoce ou rétroaction immédiate. RTCP à taille réduite NE DEVRA PAS être envoyé tant qu'au moins un RTCP composé n'a pas été envoyé. En mode rétroaction immédiate, tous les messages  de rétroaction PEUVENT être envoyés comme RTCP à taille réduite. En mode RTCP précoce, un message de rétroaction programmé pour transmission comme RTCP précoce, c'est-à-dire, pas un RTCP régulier, PEUT être envoyé comme RTCP à taille réduite. Tous les RTCP qui sont programmés pour transmission comme RTCP réguliers DEVRONT être envoyés comme RTCP composés comme indiqué par AVPF [RFC4585].

 	4.1	Définition de RTCP à taille réduite
Un paquet RTCP à taille réduite est un paquet RTCP avec les propriétés suivantes qui le font différer de la définition du paquet RTCP composé donnée au paragraphe 6.1 de la [RFC3550] :
o	contient un ou plusieurs paquets RTCP,
o	permet tout type de paquet RTCP ; cependant, voir le paragraphe 4.2.1,
o	NE DOIT PAS être utilisé pour les rapports RTCP réguliers (programmés),
o	NE DOIT PAS être utilisé avec le profil RTP/AVP [RFC3551] ou le profil RTP/SAVP [RFC3711].

 	4.2	Considérations d'algorithme
 	4.2.1	Vérification de livraison
Si une application utilise RTCP à taille réduite, il est important de vérifier que les paquets RTCP à taille réduite atteignent réellement les participants à la session. Comme souligné aux paragraphes 3.4.1 et 3.4.2, des paquets peuvent être éliminés sur le chemin ou au point d'extrémité.

Quelques règles de vérification sont RECOMMANDÉES pour s'assurer d'une robuste transmission et réception de RTCP et pour résoudre les problèmes identifiés quand RTCP à taille réduite est utilisé :

o	Le problème du point d'extrémité peut être résolu en introduisant une signalisation qui informe si tous les participants à la session sont capables de RTCP à taille réduite. Voir la Section 5.

o	Le problème du boîtier de médiation est plus difficile, et on va être obligé d'utiliser une heuristique pour déterminer si les paquets RTCP à taille réduite sont ou non livrés. La méthode utilisée pour détecter la réussite de la livraison des paquets RTCP à taille réduite dépend du type de paquet. Les types de paquet RTCP pour lesquel une livraison réussie peut être détectée sont :
*	Rapports d'envoyeur (SR) : la transmission réussie d'un rapport d'envoyeur peut être vérifiée par l'inspection de l'écho d'horodatage dans le rapport de receveur (RR) reçu. Cela peut aussi être utilisé comme méthode pour vérifier si RTCP à taille réduite peut être en fait utilisé.
*	Paquets RTCP de rétroaction : dans de nombreux cas, les messages de rétroaction envoyés en utilisant RTCP à taille réduite vont résulter en une indication explicite ou implicite qu'ils ont été reçus. Un exemple en est la retransmission RTP [RFC4588] qui résulte d'un message NACK [RFC4585]. Un autre exemple est le message de notification de débit binaire de flux de support maximum temporaire (TMMBN, Temporary Maximum Media Stream Bitrate Notification) résultant d'une demande de débit binaire de flux de support maximum temporaire (TMMBR, Temporary Maximum Media Stream Bitrate Request) [RFC5104]. Un troisième exemple est la présence d'un point de rafraîchissement de décodeur [RFC5104] dans le flux de supports de vidéo résultant de la demande Intra complète qui a été envoyée.

Les types de paquet RTCP pour lesquels il n'est pas possible de réussir à détecter la livraison NE DEVRAIENT PAS être transmis comme des paquets RTCP à taille réduite sauf si ils sont transmis dans le même datagramme de couche inférieure qu'un autre type de paquet RTCP pour lequel la réussite de livraison peut être détectée.

o	Un algorithme pour détecter l'échec permanent de livraison de RTCP à taille réduite DOIT être utilisé par toute application qui utilise RTCP à taille réduite. Les détails de cet algorithme dépendent de l'application et sortent donc du domaine d'application du présent document.

Si la vérification échoue, il est fortement RECOMMANDÉ que seul RTCP composé, conformément aux règles de la RFC 3550, soit transmis.

 	4.2.2	Un ou plusieurs RTCP dans  un RTCP à taille réduite
Le résultat de la définition du paragraphe 4.1 peut être que la taille résultante de RTCP à taille réduite peut devenir supérieure à celle d'un paquet RTCP composé régulièrement programmé. Pour les applications qui utilisent des types d'accès qui sont sensibles à la taille de paquet (voir le point 2 du paragraphe 3.3) il est fortement RECOMMANDÉ que l'utilisation de RTCP à taille réduite soit limitée à la transmission d'un seul paquet RTCP dans chaque datagramme de couche inférieure. La méthode pour déterminer le besoin de cela sort du domaine d'application de ce document.

En général, comme l'avantage de grands paquets RTCP à taille réduite est très limité, il est fortement RECOMMANDÉ de transmettre plutôt les grands paquets RTCP à taille réduite comme des paquets RTCP composés.

 	4.2.3	Application de RTCP composé
Comme discuté précédemment, il est important que la transmission de RTCP composé se produise à des intervalles réguliers. Cependant, cela ne va se produire qu'autant que les envoyeurs RTCP suivent l'algorithme de programmation d'AVPF défini au paragraphe 3.5 de la [RFC4585]. Cela découle de ce que tous les RTCP réguliers DOIVENT être des RTCP composés complets. Noter qu'il y a aussi l'exigence que l'envoi de RTCP régulier soit en mode Rétroaction immédiate.

 	4.2.4	Mode retour immédiat
Le paragraphe 3.3 de la [RFC4585] donne l'option d'utiliser le mode d'AVPF rétroaction immédiate tant que la taille de groupe reste en dessous d'une certaine limite. Comme les transmissions utilisant RTCP à taille réduite peuvent réduire la demande de bande passante, de telles transmissions ouvrent aussi la possibilité d'une utilisation plus libérale du mode de rétroaction immédiate.

 	5.	Signalisation

Le présent document définit un attribut "a=rtcp-rsize" du protocole de description de session (SDP, Session Description Protocol) [RFC4566] pour indiquer si le participant à la session est capable de prendre en charge RTCP à taille réduite pour les applications qui utilisent SDP pour la configuration des sessions RTP. Il est EXIGÉ qu'un participant qui propose l'utilisation de RTCP à taille réduite devra lui-même prendre en charge la réception de RTCP à taille réduite.

Un client offreur qui souhaite utiliser RTCP à taille réduite DOIT inclure l'attribut "a=rtcp-rsize" dans l'offre SDP. Si "a=rtcp-rsize" est présent dans l'offre SDP, le répondant qui prend en charge RTCP à taille réduite et souhaite l'utiliser DEVRA inclure l'attribut "a=rtcp-rsize" dans la réponse.

 1.	Dans l'usage déclaratif de SDP, comme dans le protocole de flux en temps réel (RTSP, Real Time Streaming Protocol) [RFC2326] et le protocole d'annonce de session (SAP, Session Announcement Protocol) [RFC2974], la présence de l'attribut indique que le participant à la session PEUT utiliser des paquets RTCP à taille réduite dans ses transmissions RTCP.

 	6.	Considérations sur la sécurité

Les considérations sur la sécurité de RTP [RFC3550] et de AVPF [RFC4585] s'appliquent aussi à RTCP à taille réduite. La réduction de la force de validation pour les paquets reçus sur l'accès RTCP peut résulter en un plus haut degré d'acceptation de données parasites comme étant des données RTCP réelles. Cette vulnérabilité peut être traitée par l'usage de tout mécanisme de sécurité qui assure l'authentification ; un de ces mécanismes est SRTP [RFC3711].

 	7.	Considérations relatives à l'IANA

Suivant les lignes directrices de la [RFC4566], l'IANA a enregistré un nouvel attribut SDP :
o	Nom de contact, adresse de messagerie, et numéro de téléphone : les auteurs de la RFC 5506
o	Nom d'attribut : rtcp-rsize
o	Forme longue du npm d'attribut : RTCP à taille réduite
o	Type d'attribut : niveau support
o	Soumis à un jeu de caractères : non

Cet attribut définit la prise en charge de RTCP à taille réduite, c'est-à-dire, la possibilité de transmettre du RTCP qui ne se conforme pas aux règles de RTCP composé définies dans la RFC 3550. C'est un attribut de propriété, qui ne prend pas de valeur.

 	8.	Remerciements

Les auteurs tiennent à remercier toutes les personnes qui ont fourni des retours sur ce document. Un merci particulier à Colin Perkins.

Ce document contient aussi du texte copié des [RFC3550], [RFC4585], et [RFC3711]. On saisit cette opportunité pour remercier les auteurs de ces documents.

 	9.	Références
 	9.1	Références normatives

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

[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)

[RFC4585]	J. Ott et autres, "Profil RTP étendu pour rétroaction fondée sur le protocole de contrôle de transport en temps réel (RTCP) (RTP/AVPF)", juillet 2006. (P.S., MàJ par RFC8108)

[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.)

 	9.2	Références pour information

[MTSI-3GPP]	3GPP, "Specification : 3GPP TS 26.114" (v8.2.0 ou ultérieure) http://www.3gpp.org/ftp/Specs/html-info/26-series.htm, mars 2007.

[OMA-PoC]	Open Mobile Alliance, "Specification : Push to talk Over Cellular User Plane", http://member.openmobilealliance.org/ftp/public_documents/poc/Permanent_documents/OMA-TS-PoC_UserPlane-V2_0-20080507-C.zip, novembre 2006.

[RFC2326]	H. Schulzrinne, A. Rao et R. Lanphier, "Protocole de flux directs en temps réel (RTSP)", avril 1998. (Remplacée par RFC7826)

[RFC2974]	M. Handley, C. Perkins, E. Whelan, "Protocole d'annonce de session (SAP)", octobre 2000. (Expérimentale)

[RFC3095]	C. Bormann et autres, "Compression d'en-tête robuste (ROHC) : cadre et quatre profils", juillet 2001. (MàJ par RFC3759, RFC4815) (P.S.)

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

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

[RFC4588]	J. Rey et autres, "Format de charge utile de retransmission RTP", juillet 2006. (P.S.)

[RFC5104]	S. Wenger et autres, "Messages de contrôle de codec dans le profil audio-visuel RTP avec rétroaction (AVPF)", février  2008. (P.S. ; MàJ par RFC7728, RFC8082)

[RFC5761]	C. Perkins, M. Westerlund, "Multiplexage de paquets de données et de contrôle RTP sur un seul accès", avril 2010. (MàJ RFC3550, RFC3551). (P. S., MàJ par RFC8035)

[TCP-FRIEND]	Gharai, L., "RTP with TCP Friendly Rate Control", Travail en cours, juillet 2007.

 	Adresse des auteurs

Ingemar Johansson	Magnus Westerlund	
Ericsson AB	Ericsson AB	
Laboratoriegrand 11	Faeroegatan 6	
SE-971 28 Lulea	SE-164 80 Stockholm	
SWEDEN	SWEDEN	
téléphone : +46 73 0783289	téléphone : +46 10 7148287	
mél : ingemar.s.johansson@ericsson.com	mél : magnus.westerlund@ericsson.com