6. RTP Control Protocol -- RTCP (Protocole de contrôle RTP -- RTCP)

Le protocole de contrôle RTP (RTCP, RTP control protocol) est basé sur la transmission périodique de paquets de contrôle à tous les participants de la session, en utilisant le même mécanisme de distribution que les paquets de données. Le protocole sous-jacent DOIT fournir le multiplexage des paquets de données et de contrôle, par exemple en utilisant des numéros de port distincts avec UDP. RTCP remplit quatre fonctions :

1. La fonction principale est de fournir un retour d'information sur la qualité de la distribution des données. C'est une partie intégrante du rôle de RTP en tant que protocole de transport et elle est liée aux fonctions de contrôle de flux et d'encombrement des autres protocoles de transport (voir la section 10 sur l'exigence de contrôle d'encombrement). Le retour d'information peut être directement utile pour le contrôle des encodages adaptatifs [18,19], mais les expériences avec le multicast IP ont montré qu'il est également critique d'obtenir un retour des récepteurs pour diagnostiquer les pannes dans la distribution. L'envoi de rapports de réception à tous les participants permet à celui qui observe des problèmes d'évaluer si ces problèmes sont locaux ou globaux. Avec un mécanisme de distribution tel que le multicast IP, il est aussi possible pour une entité telle qu'un fournisseur de service réseau qui n'est pas autrement impliqué dans la session de recevoir l'information de retour et d'agir comme moniteur tiers pour diagnostiquer les problèmes réseau. Cette fonction de retour d'information est accomplie par les rapports RTCP émetteur et récepteur, décrits ci-dessous à la section 6.4.

2. RTCP transporte un identificateur de niveau transport persistant pour une source RTP appelé nom canonique ou CNAME, section 6.5.1. Puisque l'identificateur SSRC peut changer si un conflit est découvert ou qu'un programme est redémarré, les récepteurs requièrent le CNAME pour suivre chaque participant. Les récepteurs peuvent aussi requérir le CNAME pour associer de multiples flux de données d'un participant donné dans un ensemble de sessions RTP liées, par exemple pour synchroniser l'audio et la vidéo. La synchronisation inter-média requiert aussi les horodatages NTP et RTP inclus dans les paquets RTCP par les émetteurs de données.

3. Les deux premières fonctions requièrent que tous les participants envoient des paquets RTCP, par conséquent le débit doit être contrôlé pour que RTP puisse passer à l'échelle d'un grand nombre de participants. En faisant envoyer à chaque participant ses paquets de contrôle à tous les autres, chacun peut observer indépendamment le nombre de participants. Ce nombre est utilisé pour calculer le débit auquel les paquets sont envoyés, comme expliqué à la section 6.2.

4. Une quatrième fonction, OPTIONNELLE, est de transmettre des informations minimales de contrôle de session, par exemple l'identification des participants à afficher dans l'interface utilisateur. Cela est susceptible d'être le plus utile dans les sessions « faiblement contrôlées » où les participants entrent et quittent sans contrôle d'appartenance ni négociation de paramètres. RTCP sert de canal commode pour atteindre tous les participants, mais il n'est pas nécessairement attendu de prendre en charge toutes les exigences de communication de contrôle d'une application. Un protocole de contrôle de session de niveau supérieur, qui dépasse le cadre de ce document, peut être nécessaire.

Les fonctions 1 à 3 DEVRAIENT être utilisées dans tous les environnements, mais particulièrement dans l'environnement multicast IP. Les concepteurs d'applications RTP DEVRAIENT éviter les mécanismes qui ne peuvent fonctionner qu'en mode unicast et ne passeront pas à l'échelle de nombres plus grands. La transmission RTCP PEUT être contrôlée séparément pour les émetteurs et les récepteurs, comme décrit à la section 6.2, pour les cas tels que des liens unidirectionnels où un retour des récepteurs n'est pas possible.

Note non normative : Dans l'approche de routage multicast appelée Multicast Spécifique à la Source (SSM, Source-Specific Multicast), il n'y a qu'un seul émetteur par « canal » (une paire adresse source, adresse de groupe), et les récepteurs (excepté la source du canal) ne peuvent pas utiliser le multicast pour communiquer directement avec les autres membres du canal. Les recommandations ici n'accommodent le SSM que par l'option de la section 6.2 de désactiver entièrement le RTCP des récepteurs. Des travaux futurs spécifieront l'adaptation de RTCP pour SSM afin que le retour des récepteurs puisse être maintenu.

6.1 RTCP Packet Format (Format des paquets RTCP)

Cette spécification définit plusieurs types de paquets RTCP pour transporter une variété d'informations de contrôle :

• SR : Rapport d'émetteur, pour les statistiques d'émission et de réception des participants qui sont des émetteurs actifs.

• RR : Rapport de récepteur, pour les statistiques de réception des participants qui ne sont pas des émetteurs actifs et, en combinaison avec SR, pour les émetteurs actifs rendant compte de plus de 31 sources.

• SDES : Éléments de description de source, incluant CNAME.

• BYE : Indique la fin de participation.

• APP : Fonctions spécifiques à l'application.

Chaque paquet RTCP commence par une partie fixe similaire à celle des paquets de données RTP, suivie d'éléments structurés qui PEUVENT être de longueur variable selon le type de paquet mais DOIVENT se terminer sur une limite de 32 bits. L'exigence d'alignement et un champ de longueur dans la partie fixe de chaque paquet sont inclus pour rendre les paquets RTCP « empilables ». Plusieurs paquets RTCP peuvent être concaténés sans séparateur intermédiaire pour former un paquet RTCP composé (compound RTCP packet) qui est envoyé dans un seul paquet du protocole de couche inférieure, par exemple UDP. Il n'y a pas de compte explicite des paquets RTCP individuels dans le paquet composé puisque les protocoles de couche inférieure sont censés fournir une longueur globale pour déterminer la fin du paquet composé.

Chaque paquet RTCP individuel dans le paquet composé peut être traité indépendamment sans exigence sur l'ordre ou la combinaison des paquets. Toutefois, afin d'accomplir les fonctions du protocole, les contraintes suivantes sont imposées :

• Les statistiques de réception (dans SR ou RR) devraient être envoyées aussi souvent que le permettent les contraintes de bande passante pour maximiser la résolution des statistiques, par conséquent chaque paquet RTCP composé transmis périodiquement DOIT inclure un paquet de rapport.

• Les nouveaux récepteurs ont besoin de recevoir le CNAME pour une source dès que possible pour identifier la source et commencer à associer les médias à des fins telles que la synchronisation labiale (lip-sync), donc chaque paquet RTCP composé DOIT aussi inclure le SDES CNAME sauf lorsque le paquet RTCP composé est scindé pour un chiffrement partiel comme décrit à la section 9.1.

• Le nombre de types de paquets qui peuvent apparaître en premier dans le paquet composé doit être limité pour augmenter le nombre de bits constants dans le premier mot et la probabilité de valider avec succès les paquets RTCP contre des paquets de données RTP mal adressés ou d'autres paquets sans rapport.

Ainsi, tous les paquets RTCP DOIVENT être envoyés dans un paquet composé d'au moins deux paquets individuels, avec le format suivant :

• Préfixe de chiffrement : Si et seulement si le paquet composé doit être chiffré selon la méthode de la section 9.1, il DOIT être préfixé par une quantité aléatoire de 32 bits redrawn pour chaque paquet composé transmis. Si un remplissage est requis pour le chiffrement, il DOIT être ajouté au dernier paquet du paquet composé.

• SR ou RR : Le premier paquet RTCP dans le paquet composé DOIT toujours être un paquet de rapport pour faciliter la validation d'en-tête comme décrit à l'appendice A.2. Cela est vrai même si aucune donnée n'a été envoyée ou reçue, auquel cas un RR vide DOIT être envoyé, et même si le seul autre paquet RTCP dans le paquet composé est un BYE.

• RR supplémentaires : Si le nombre de sources pour lesquelles des statistiques de réception sont rapportées dépasse 31, le nombre qui tiendra dans un paquet SR ou RR, alors des paquets RR supplémentaires DEVRAIENT suivre le paquet de rapport initial.

• SDES : Un paquet SDES contenant un élément CNAME DOIT être inclus dans chaque paquet RTCP composé, sauf comme noté à la section 9.1. D'autres éléments de description de source PEUVENT optionnellement être inclus si requis par une application particulière, sous réserve des contraintes de bande passante (voir la section 6.3.9).

• BYE ou APP : D'autres types de paquets RTCP, incluant ceux encore à définir, PEUVENT suivre dans n'importe quel ordre, excepté que BYE DEVRAIT être le dernier paquet envoyé avec un SSRC/CSRC donné. Les types de paquets PEUVENT apparaître plus d'une fois.

Un participant RTP individuel DEVRAIT envoyer un seul paquet RTCP composé par intervalle de rapport afin que la bande passante RTCP par participant soit estimée correctement (voir la section 6.2), excepté lorsque le paquet RTCP composé est scindé pour un chiffrement partiel comme décrit à la section 9.1. S'il y a trop de sources pour faire tenir tous les paquets RR nécessaires dans un seul paquet RTCP composé sans dépasser l'unité de transmission maximale (MTU, maximum transmission unit) du chemin réseau, alors seul le sous-ensemble qui tiendra dans une MTU DEVRAIT être inclus dans chaque intervalle. Les sous-ensembles DEVRAIENT être sélectionnés en tourniquet (round-robin) à travers de multiples intervalles afin que toutes les sources soient rapportées.

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

Une implémentation DEVRAIT ignorer les paquets RTCP entrants de types qui lui sont inconnus. Des types de paquets RTCP supplémentaires PEUVENT être enregistrés auprès de l'Internet Assigned Numbers Authority (IANA) comme décrit à la section 15.

si chiffré : entier aléatoire de 32 bits
|
|[--------- paquet --------][---------- paquet ----------][-paquet-]
|
|                rapports           morceau        morceau
V                récepteur          élément élément   élément élément
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
|                                                                  |
|<-----------------------  paquet composé ----------------------->|
|<--------------------------  paquet UDP ------------------------->|

#: identificateur SSRC/CSRC

              Figure 1 : Exemple de paquet RTCP composé

6.2 RTCP Transmission Interval (Intervalle de transmission RTCP)

RTP est conçu pour permettre à une application de passer à l'échelle automatiquement sur des tailles de session allant de quelques participants à des milliers. Par exemple, dans une conférence audio le trafic de données est intrinsèquement auto-limité car une ou deux personnes seulement parleront à la fois, donc avec une distribution multicast le débit de données sur un lien donné reste relativement constant indépendamment du nombre de participants. Toutefois, le trafic de contrôle n'est pas auto-limité. Si les rapports de réception de chaque participant étaient envoyés à un débit constant, le trafic de contrôle croîtrait linéairement avec le nombre de participants. Par conséquent, le débit doit être réduit en calculant dynamiquement l'intervalle entre les transmissions de paquets RTCP.

Pour chaque session, on suppose que le trafic de données est soumis à une limite agrégée appelée « bande passante de session » (session bandwidth) à diviser entre les participants. Cette bande passante pourrait être réservée et la limite appliquée par le réseau. S'il n'y a pas de réservation, il peut y avoir d'autres contraintes, selon l'environnement, qui établissent le maximum « raisonnable » pour que la session l'utilise, et ce serait la bande passante de session. La bande passante de session peut être choisie sur la base d'un coût ou d'une connaissance a priori de la bande passante réseau disponible pour la session. Elle est quelque peu indépendante de l'encodage média, mais le choix d'encodage peut être limité par la bande passante de session. Souvent, la bande passante de session est la somme des bandes passantes nominales des émetteurs attendus comme étant concurrentiellement actifs. Pour l'audio en téléconférence, ce nombre serait typiquement la bande passante d'un émetteur. Pour les encodages en couches, chaque couche est une session RTP séparée avec son propre paramètre de bande passante de session.

Le paramètre de bande passante de session est censé être fourni par une application de gestion de session lorsqu'elle invoque une application média, mais les applications média PEUVENT fixer une valeur par défaut basée sur la bande passante de données d'un émetteur unique pour l'encodage sélectionné pour la session. L'application PEUT aussi appliquer des limites de bande passante basées sur des règles de portée multicast ou d'autres critères. Tous les participants DOIVENT utiliser la même valeur pour la bande passante de session afin que le même intervalle RTCP soit calculé.

Les calculs de bande passante pour le trafic de contrôle et de données incluent les protocoles de transport et de réseau de couche inférieure (par exemple UDP et IP) puisque c'est ce dont le système de réservation de ressources aurait besoin de connaître. L'application peut aussi être censée connaître lesquels de ces protocoles sont en usage. Les en-têtes de niveau lien ne sont pas inclus dans le calcul puisque le paquet sera encapsulé avec différents en-têtes de niveau lien au cours de son voyage.

Le trafic de contrôle devrait être limité à une petite fraction connue de la bande passante de session : petite afin que la fonction principale du protocole de transport de transporter des données ne soit pas altérée ; connue afin que le trafic de contrôle puisse être inclus dans la spécification de bande passante donnée à un protocole de réservation de ressources, et afin que chaque participant puisse calculer indépendamment sa part. La bande passante du trafic de contrôle s'ajoute à la bande passante de session pour le trafic de données. Il est RECOMMANDÉ que la fraction de la bande passante de session ajoutée pour RTCP soit fixée à 5 %. Il est aussi RECOMMANDÉ que 1/4 de la bande passante RTCP soit dédiée aux participants qui envoient des données afin que dans les sessions avec un grand nombre de récepteurs mais un petit nombre d'émetteurs, les participants nouvellement arrivants reçoivent plus rapidement le CNAME pour les sites émetteurs. Lorsque la proportion d'émetteurs est supérieure à 1/4 des participants, les émetteurs obtiennent leur proportion de la bande passante RTCP complète. Bien que les valeurs de ces constantes et d'autres dans le calcul d'intervalle ne soient pas critiques, tous les participants de la session DOIVENT utiliser les mêmes valeurs afin que le même intervalle soit calculé. Par conséquent, ces constantes DEVRAIENT être fixées pour un profil particulier.

Un profil PEUT spécifier que la bande passante du trafic de contrôle peut être un paramètre de session séparé plutôt qu'un pourcentage strict de la bande passante de session. Utiliser un paramètre séparé permet aux applications à débit adaptatif de fixer une bande passante RTCP cohérente avec une bande passante de données « typique » qui est inférieure à la bande passante maximale spécifiée par le paramètre de bande passante de session.

Le profil PEUT en outre spécifier que la bande passante du trafic de contrôle peut être divisée en deux paramètres de session séparés pour les participants qui sont des émetteurs de données actifs et ceux qui ne le sont pas ; appelons les paramètres S et R. Suivant la recommandation que 1/4 de la bande passante RTCP soit dédiée aux émetteurs de données, les valeurs par défaut RECOMMANDÉES pour ces deux paramètres seraient 1,25 % et 3,75 %, respectivement. Lorsque la proportion d'émetteurs est supérieure à S/(S+R) des participants, les émetteurs obtiennent leur proportion de la somme de ces paramètres. Utiliser deux paramètres permet de désactiver entièrement les rapports de réception RTCP pour une session particulière en fixant la bande passante RTCP pour les non-émetteurs de données à zéro tout en gardant la bande passante RTCP pour les émetteurs de données non nulle afin que les rapports d'émetteur puissent toujours être envoyés pour la synchronisation inter-média. Désactiver les rapports de réception RTCP N'EST PAS RECOMMANDÉ car ils sont nécessaires pour les fonctions listées au début de la section 6, particulièrement le retour de qualité de réception et le contrôle d'encombrement. Toutefois, le faire peut être approprié pour les systèmes fonctionnant sur des liens unidirectionnels ou pour les sessions qui ne requièrent pas de retour sur la qualité de réception ou la présence des récepteurs et qui ont d'autres moyens d'éviter l'encombrement.

L'intervalle calculé entre les transmissions de paquets RTCP composés DEVRAIT aussi avoir une borne inférieure pour éviter que des rafales de paquets dépassent la bande passante autorisée lorsque le nombre de participants est petit et que le trafic n'est pas lissé selon la loi des grands nombres. Cela empêche aussi l'intervalle de rapport de devenir trop petit pendant des pannes transitoires comme une partition réseau telle que l'adaptation est retardée quand la partition se résorbe. Au démarrage de l'application, un délai DEVRAIT être imposé avant que le premier paquet RTCP composé soit envoyé pour laisser le temps de recevoir des paquets RTCP d'autres participants afin que l'intervalle de rapport converge plus rapidement vers la valeur correcte. Ce délai PEUT être fixé à la moitié de l'intervalle minimum pour permettre une notification plus rapide que le nouveau participant est présent. La valeur RECOMMANDÉE pour un intervalle minimum fixe est de 5 secondes.

Une implémentation PEUT réduire l'intervalle RTCP minimum à une valeur plus petite inversement proportionnelle au paramètre de bande passante de session avec les limitations suivantes :

• Pour les sessions multicast, seuls les émetteurs de données actifs PEUVENT utiliser la valeur minimum réduite pour calculer l'intervalle de transmission de paquets RTCP composés.

• Pour les sessions unicast, la valeur réduite PEUT être utilisée par les participants qui ne sont pas des émetteurs de données actifs aussi, et le délai avant l'envoi du premier paquet RTCP composé PEUT être nul.

• Pour toutes les sessions, le minimum fixe DEVRAIT être utilisé lors du calcul de l'intervalle d'expiration des participants (voir la section 6.3.5) afin que les implémentations qui n'utilisent pas la valeur réduite pour transmettre des paquets RTCP ne soient pas expirées par d'autres participants prématurément.

• La valeur RECOMMANDÉE pour le minimum réduit en secondes est 360 divisé par la bande passante de session en kilobits/seconde. Ce minimum est inférieur à 5 secondes pour des bandes passantes supérieures à 72 kb/s.

L'algorithme décrit à la section 6.3 et à l'appendice A.7 a été conçu pour répondre aux objectifs esquissés dans cette section. Il calcule l'intervalle entre l'envoi de paquets RTCP composés pour diviser la bande passante de trafic de contrôle autorisée entre les participants. Cela permet à une application de fournir une réponse rapide pour les petites sessions où, par exemple, l'identification de tous les participants est importante, tout en s'adaptant automatiquement aux grandes sessions. L'algorithme incorporé les caractéristiques suivantes :

• L'intervalle calculé entre les paquets RTCP croît linéairement avec le nombre de membres du groupe. C'est ce facteur linéaire qui permet une quantité constante de trafic de contrôle lorsqu'on la somme sur tous les membres.

• L'intervalle entre les paquets RTCP est varié aléatoirement sur la plage [0,5 ; 1,5] fois l'intervalle calculé pour éviter une synchronisation non intentionnelle de tous les participants [20]. Le premier paquet RTCP envoyé après avoir rejoint une session est aussi retardé par une variation aléatoire de la moitié de l'intervalle RTCP minimum.

• Une estimation dynamique de la taille moyenne du paquet RTCP composé est calculée, incluant tous les paquets reçus et envoyés, pour s'adapter automatiquement aux changements dans la quantité d'informations de contrôle transportées.

• Puisque l'intervalle calculé dépend du nombre de membres de groupe observés, il peut y avoir des effets de démarrage indésirables quand un nouvel utilisateur rejoint une session existante, ou que de nombreux utilisateurs rejoignent simultanément une nouvelle session. Ces nouveaux utilisateurs auront initialement de mauvaises estimations de l'appartenance au groupe, et donc leur intervalle de transmission RTCP sera trop court. Ce problème peut être significatif si de nombreux utilisateurs rejoignent la session simultanément. Pour traiter cela, un algorithme appelé « reconsidération de minuteur » (timer reconsideration) est employé. Cet algorithme implémente un mécanisme simple de repli (back-off) qui amène les utilisateurs à retenir la transmission de paquets RTCP si les tailles de groupe augmentent.

• Quand les utilisateurs quittent une session, soit avec un BYE soit par expiration, l'appartenance au groupe diminue, et donc l'intervalle calculé devrait diminuer. Un algorithme de « reconsidération inverse » (reverse reconsideration) est utilisé pour permettre aux membres de réduire plus rapidement leurs intervalles en réponse aux diminutions d'appartenance au groupe.

• Les paquets BYE reçoivent un traitement différent des autres paquets RTCP. Quand un utilisateur quitte un groupe, et souhaite envoyer un paquet BYE, il peut le faire avant son prochain paquet RTCP planifié. Toutefois, la transmission des BYE suit un algorithme de repli qui évite des inondations de paquets BYE si un grand nombre de membres quittent la session simultanément.

Cet algorithme peut être utilisé pour les sessions où tous les participants sont autorisés à envoyer. Dans ce cas, le paramètre de bande passante de session est le produit de la bande passante de l'émetteur individuel multipliée par le nombre de participants, et la bande passante RTCP est 5 % de celle-ci.

Les détails de l'opération de l'algorithme sont donnés dans les sections qui suivent. L'appendice A.7 donne un exemple d'implémentation.

6.2.1 Maintaining the Number of Session Members (Maintien du nombre de membres de session)

Le calcul de l'intervalle de paquet RTCP dépend d'une estimation du nombre de sites participant à la session. De nouveaux sites sont ajoutés au compte quand ils sont entendus, et une entrée pour chacun DEVRAIT être créée dans une table indexée par l'identificateur SSRC ou CSRC (voir la section 8.2) pour les suivre. De nouvelles entrées PEUVENT être considérées non valides jusqu'à ce que plusieurs paquets transportant le nouveau SSRC aient été reçus (voir l'appendice A.1), ou jusqu'à ce qu'un paquet RTCP SDES contenant un CNAME pour ce SSRC ait été reçu. Des entrées PEUVENT être supprimées de la table quand un paquet RTCP BYE avec l'identificateur SSRC correspondant est reçu, excepté que quelques paquets de données traînards pourraient arriver après le BYE et causer la recréation de l'entrée. À la place, l'entrée DEVRAIT être marquée comme ayant reçu un BYE puis supprimée après un délai approprié.

Un participant PEUT marquer un autre site inactif, ou le supprimer s'il n'est pas encore valide, si aucun paquet RTP ou RTCP n'a été reçu pendant un petit nombre d'intervalles de rapport RTCP (5 est RECOMMANDÉ). Cela fournit une certaine robustesse contre la perte de paquets. Tous les sites doivent avoir la même valeur pour ce multiplicateur et doivent calculer à peu près la même valeur pour l'intervalle de rapport RTCP afin que cette expiration fonctionne correctement. Par conséquent, ce multiplicateur DEVRAIT être fixé pour un profil particulier.

Pour les sessions avec un très grand nombre de participants, il peut être impossible de maintenir une table pour stocker l'identificateur SSRC et l'information d'état pour tous. Une implémentation PEUT utiliser l'échantillonnage SSRC, comme décrit dans [21], pour réduire les exigences de stockage. Une implémentation PEUT utiliser tout autre algorithme de performance similaire. Une exigence clé est que tout algorithme considéré NE DEVRAIT PAS sous-estimer substantiellement la taille du groupe, bien qu'il PEUT la surestimer.

6.3 RTCP Packet Send and Receive Rules (Règles d'envoi et de réception des paquets RTCP)

Les règles sur la façon d'envoyer, et que faire à la réception d'un paquet RTCP, sont esquissées ici. Une implémentation qui permet l'opération dans un environnement multicast ou un environnement unicast multipoint DOIT satisfaire aux exigences de la section 6.2. Une telle implémentation PEUT utiliser l'algorithme défini dans cette section pour satisfaire à ces exigences, ou PEUT utiliser un autre algorithme tant qu'il fournit des performances équivalentes ou meilleures. Une implémentation contrainte à une opération unicast à deux parties DEVRAIT encore utiliser la randomisation de l'intervalle de transmission RTCP pour éviter une synchronisation non intentionnelle de multiples instances opérant dans le même environnement, mais PEUT omettre les algorithmes de « reconsidération de minuteur » et de « reconsidération inverse » des sections 6.3.3, 6.3.6 et 6.3.7.

Pour exécuter ces règles, un participant de session doit maintenir plusieurs éléments d'état :

• tp : le dernier moment où un paquet RTCP a été transmis ;

• tc : le moment actuel ;

• tn : le prochain moment de transmission planifié d'un paquet RTCP ;

• pmembers : le nombre estimé de membres de session au moment où tn a été dernièrement recalculé ;

• members : l'estimation la plus récente du nombre de membres de session ;

• senders : l'estimation la plus récente du nombre d'émetteurs dans la session ;

• rtcp_bw : La bande passante RTCP cible, c'est-à-dire la bande passante totale qui sera utilisée pour les paquets RTCP par tous les membres de cette session, en octets par seconde. Ce sera une fraction spécifiée du paramètre de « bande passante de session » fourni à l'application au démarrage.

• we_sent : Drapeau qui est vrai si l'application a envoyé des données depuis que le 2e rapport RTCP précédent a été transmis.

• avg_rtcp_size : La taille moyenne du paquet RTCP composé, en octets, sur tous les paquets RTCP envoyés et reçus par ce participant. La taille inclut les en-têtes de protocole de transport et de réseau de couche inférieure (par exemple UDP et IP) comme expliqué à la section 6.2.

• initial : Drapeau qui est vrai si l'application n'a pas encore envoyé un paquet RTCP.

Beaucoup de ces règles font usage de l'« intervalle septième » entre les transmissions de paquets. Cet intervalle est décrit dans la section suivante.

6.3.1 Computing the RTCP Transmission Interval (Calcul de l'intervalle de transmission RTCP)

Pour maintenir la scalabilité, l'intervalle moyen entre les paquets d'un participant de session devrait croître avec la taille du groupe. Cet intervalle est appelé l'intervalle calculé. Il est obtenu en combinant un certain nombre des éléments d'état décrits ci-dessus. L'intervalle calculé T est alors déterminé comme suit :

1. Si le nombre d'émetteurs est inférieur ou égal à 25 % de l'appartenance (members), l'intervalle dépend de si le participant est un émetteur ou non (selon la valeur de we_sent). Si le participant est un émetteur (we_sent vrai), la constante C est fixée à la taille moyenne de paquet RTCP (avg_rtcp_size) divisée par 25 % de la bande passante RTCP (rtcp_bw), et la constante n est fixée au nombre d'émetteurs. Si we_sent n'est pas vrai, la constante C est fixée à la taille moyenne de paquet RTCP divisée par 75 % de la bande passante RTCP. La constante n est fixée au nombre de récepteurs (members - senders). Si le nombre d'émetteurs est supérieur à 25 %, émetteurs et récepteurs sont traités ensemble. La constante C est fixée à la taille moyenne de paquet RTCP divisée par la bande passante RTCP totale et n est fixée au nombre total de membres. Comme indiqué à la section 6.2, un profil RTP PEUT spécifier que la bande passante RTCP peut être explicitement définie par deux paramètres séparés (appelons-les S et R) pour les participants qui sont émetteurs et ceux qui ne le sont pas. Dans ce cas, la fraction 25 % devient S/(S+R) et la fraction 75 % devient R/(S+R). Notez que si R est nul, le pourcentage d'émetteurs n'est jamais supérieur à S/(S+R), et l'implémentation doit éviter la division par zéro.

2. Si le participant n'a pas encore envoyé de paquet RTCP (la variable initial est vraie), la constante Tmin est fixée à 2,5 secondes, sinon elle est fixée à 5 secondes.

3. L'intervalle déterministe calculé Td est fixé à max(Tmin, n*C).

4. L'intervalle calculé T est fixé à un nombre distribué uniformément entre 0,5 et 1,5 fois l'intervalle déterministe calculé.

5. La valeur résultante de T est divisée par e-3/2 = 1,21828 pour compenser le fait que l'algorithme de reconsidération de minuteur converge vers une valeur de la bande passante RTCP inférieure à la moyenne prévue.

Cette procédure donne un intervalle qui est aléatoire, mais qui, en moyenne, donne au moins 25 % de la bande passante RTCP aux émetteurs et le reste aux récepteurs. Si les émetteurs constituent plus d'un quart de l'appartenance, cette procédure divise la bande passante également entre tous les participants, en moyenne.

6.3.2 Initialization (Initialisation)

En rejoignant la session, le participant initialise tp à 0, tc à 0, senders à 0, pmembers à 1, members à 1, we_sent à faux, rtcp_bw à la fraction spécifiée de la bande passante de session, initial à vrai, et avg_rtcp_size à la taille probable du premier paquet RTCP que l'application construira plus tard. L'intervalle calculé T est alors calculé, et le premier paquet est planifié pour le moment tn = T. Cela signifie qu'un minuteur de transmission est fixé qui expire au moment T. Notez qu'une application PEUT utiliser toute approche désirée pour implémenter ce minuteur.

Le participant ajoute son propre SSRC à la table des membres.

6.3.3 Receiving an RTP or Non-BYE RTCP Packet (Réception d'un paquet RTP ou RTCP non-BYE)

Quand un paquet RTP ou RTCP est reçu d'un participant dont le SSRC n'est pas dans la table des membres, le SSRC est ajouté à la table, et la valeur de members est mise à jour une fois que le participant a été validé comme décrit à la section 6.2.1. Le même traitement survient pour chaque CSRC dans un paquet RTP validé.

Quand un paquet RTP est reçu d'un participant dont le SSRC n'est pas dans la table des émetteurs, le SSRC est ajouté à la table, et la valeur de senders est mise à jour.

Pour chaque paquet RTCP composé reçu, la valeur de avg_rtcp_size est mise à jour :

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

où packet_size est la taille du paquet RTCP juste reçu.

6.3.4 Receiving an RTCP BYE Packet (Réception d'un paquet RTCP BYE)

Sauf comme décrit à la section 6.3.7 pour le cas où un BYE RTCP doit être transmis, si le paquet reçu est un paquet RTCP BYE, le SSRC est vérifié contre la table des membres. S'il est présent, l'entrée est supprimée de la table, et la valeur de members est mise à jour. Le SSRC est alors vérifié contre la table des émetteurs. S'il est présent, l'entrée est supprimée de la table, et la valeur de senders est mise à jour.

De plus, pour rendre le débit de transmission des paquets RTCP plus adaptatif aux changements d'appartenance au groupe, l'algorithme de « reconsidération inverse » suivant DEVRAIT être exécuté quand un paquet BYE est reçu qui réduit members à une valeur inférieure à pmembers :

• La valeur de tn est mise à jour selon la formule suivante :

tn = tc + (members/pmembers) * (tn - tc)

• La valeur de tp est mise à jour selon la formule suivante :

tp = tc - (members/pmembers) * (tc - tp)

• Le prochain paquet RTCP est replanifié pour transmission au moment tn, qui est maintenant plus tôt.

• La valeur de pmembers est fixée égale à members.

Cet algorithme n'empêche pas l'estimation de la taille du groupe de chuter incorrectement à zéro pendant un court temps à cause d'expirations prématurées quand la plupart des participants d'une grande session quittent à la fois mais que certains restent. L'algorithme fait revenir l'estimation à la valeur correcte plus rapidement. Cette situation est assez inhabituelle et les conséquences sont suffisamment inoffensives pour que ce problème soit jugé seulement un souci secondaire.

6.3.5 Timing Out an SSRC (Expiration d'un SSRC)

À des intervalles occasionnels, le participant DOIT vérifier si l'un des autres participants expire. Pour ce faire, le participant calcule l'intervalle déterministe (sans le facteur de randomisation) calculé Td pour un récepteur, c'est-à-dire avec we_sent faux. Tout autre membre de session qui n'a pas envoyé de paquet RTP ou RTCP depuis le moment tc - MTd (M est le multiplicateur d'expiration, et vaut par défaut 5) expire. Cela signifie que son SSRC est supprimé de la liste des membres, et members est mis à jour. Une vérification similaire est effectuée sur la liste des émetteurs. Tout membre sur la liste des émetteurs qui n'a pas envoyé de paquet RTP depuis le moment tc - 2T (dans les deux derniers intervalles de rapport RTCP) est supprimé de la liste des émetteurs, et senders est mis à jour.

Si des membres expirent, l'algorithme de reconsidération inverse décrit à la section 6.3.4 DEVRAIT être exécuté.

Le participant DOIT effectuer cette vérification au moins une fois par intervalle de transmission RTCP.

6.3.6 Expiration of Transmission Timer (Expiration du minuteur de transmission)

Quand le minuteur de transmission de paquets expire, le participant effectue les opérations suivantes :

• L'intervalle de transmission T est calculé comme décrit à la section 6.3.1, incluant le facteur de randomisation.

• Si tp + T est inférieur ou égal à tc, un paquet RTCP est transmis. tp est fixé à tc, puis une autre valeur pour T est calculée comme à l'étape précédente et tn est fixé à tc + T. Le minuteur de transmission est fixé pour expirer à nouveau au moment tn. Si tp + T est supérieur à tc, tn est fixé à tp + T. Aucun paquet RTCP n'est transmis. Le minuteur de transmission est fixé pour expirer au moment tn.

• pmembers est fixé à members.

Si un paquet RTCP est transmis, la valeur de initial est fixée à FAUX. De plus, la valeur de avg_rtcp_size est mise à jour :

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

où packet_size est la taille du paquet RTCP juste transmis.

6.3.7 Transmitting a BYE Packet (Transmission d'un paquet BYE)

Quand un participant souhaite quitter une session, un paquet BYE est transmis pour informer les autres participants de l'événement. Afin d'éviter une inondation de paquets BYE quand de nombreux participants quittent le système, un participant DOIT exécuter l'algorithme suivant si le nombre de membres est supérieur à 50 quand le participant choisit de quitter. Cet algorithme usurpe le rôle normal de la variable members pour compter les paquets BYE à la place :

• Quand le participant décide de quitter le système, tp est réinitialisé à tc, le moment actuel, members et pmembers sont initialisés à 1, initial est fixé à 1, we_sent est fixé à faux, senders est fixé à 0, et avg_rtcp_size est fixé à la taille du paquet BYE composé. L'intervalle calculé T est calculé. Le paquet BYE est alors planifié pour le moment tn = tc + T.

• Chaque fois qu'un paquet BYE d'un autre participant est reçu, members est incrémenté de 1 indépendamment du fait que ce participant existe dans la table des membres ou non, et quand l'échantillonnage SSRC est utilisé, indépendamment du fait que le SSRC BYE serait inclus dans l'échantillon. members n'est PAS incrémenté quand d'autres paquets RTCP ou paquets RTP sont reçus, mais seulement pour les paquets BYE. De même, avg_rtcp_size est mis à jour seulement pour les paquets BYE reçus. senders n'est PAS mis à jour quand des paquets RTP arrivent ; il reste 0.

• La transmission du paquet BYE suit alors les règles pour transmettre un paquet RTCP régulier, comme ci-dessus.

Cela permet d'envoyer les paquets BYE immédiatement, tout en contrôlant leur usage total de bande passante. Dans le pire cas, cela pourrait causer aux paquets de contrôle RTCP d'utiliser deux fois la bande passante que d'habitude (10 %) -- 5 % pour les paquets RTCP non-BYE et 5 % pour BYE.

Un participant qui ne veut pas attendre que le mécanisme ci-dessus permette la transmission d'un paquet BYE PEUT quitter le groupe sans envoyer de BYE du tout. Ce participant sera finalement expiré par les autres membres du groupe.

Si l'estimation de la taille du groupe members est inférieure à 50 quand le participant décide de quitter, le participant PEUT envoyer un paquet BYE immédiatement. Alternativement, le participant PEUT choisir d'exécuter l'algorithme de repli BYE ci-dessus.

Dans les deux cas, un participant qui n'a jamais envoyé de paquet RTP ou RTCP NE DOIT PAS envoyer de paquet BYE quand il quitte le groupe.

6.3.8 Updating we_sent (Mise à jour de we_sent)

La variable we_sent contient vrai si le participant a envoyé un paquet RTP récemment, faux sinon. Cette détermination est faite en utilisant les mêmes mécanismes que pour gérer l'ensemble des autres participants listés dans la table des émetteurs. Si le participant envoie un paquet RTP quand we_sent est faux, il s'ajoute à la table des émetteurs et fixe we_sent à vrai. L'algorithme de reconsidération inverse décrit à la section 6.3.4 DEVRAIT être exécuté pour réduire possiblement le délai avant l'envoi d'un paquet SR. Chaque fois qu'un autre paquet RTP est envoyé, le moment de transmission de ce paquet est maintenu dans la table. L'algorithme normal d'expiration des émetteurs est alors appliqué au participant -- si un paquet RTP n'a pas été transmis depuis le moment tc - 2T, le participant se supprime de la table des émetteurs, décrémente le compte d'émetteurs, et fixe we_sent à faux.

6.3.9 Allocation of Source Description Bandwidth (Allocation de la bande passante de description de source)

Cette spécification définit plusieurs éléments de description de source (SDES) en plus de l'élément obligatoire CNAME, tels que NAME (nom personnel) et EMAIL (adresse email). Elle fournit aussi un moyen de définir de nouveaux types de paquets RTCP spécifiques à l'application. Les applications devraient faire preuve de prudence en allouant de la bande passante de contrôle à cette information supplémentaire car cela ralentira le débit auquel les rapports de réception et CNAME sont envoyés, altérant ainsi la performance du protocole. Il est RECOMMANDÉ qu'au plus 20 % de la bande passante RTCP allouée à un seul participant soit utilisée pour transporter l'information supplémentaire. De plus, il n'est pas prévu que tous les éléments SDES seront inclus dans chaque application. Ceux qui sont inclus DEVRAIENT se voir assigner une fraction de la bande passante selon leur utilité. Plutôt que d'estimer ces fractions dynamiquement, il est recommandé que les pourcentages soient traduits statiquement en comptes d'intervalle de rapport basés sur la longueur typique d'un élément.

Par exemple, une application peut être conçue pour envoyer seulement CNAME, NAME et EMAIL et pas d'autres. NAME pourrait être donné une priorité beaucoup plus haute qu'EMAIL parce que NAME serait affiché continuellement dans l'interface utilisateur de l'application, alors qu'EMAIL ne serait affiché que sur demande. À chaque intervalle RTCP, un paquet RR et un paquet SDES avec l'élément CNAME seraient envoyés. Pour une petite session fonctionnant à l'intervalle minimum, ce serait toutes les 5 secondes en moyenne. À tous les trois intervalles (15 secondes), un élément supplémentaire serait inclus dans le paquet SDES. Sept fois sur huit ce serait l'élément NAME, et à chaque huitième fois (2 minutes) ce serait l'élément EMAIL.

Quand de multiples applications opèrent de concert en utilisant une liaison inter-applications via un CNAME commun pour chaque participant, par exemple dans une conférence multimédia composée d'une session RTP pour chaque média, l'information SDES supplémentaire PEUT être envoyée dans une seule session RTP. Les autres sessions ne transporteraient que l'élément CNAME. En particulier, cette approche devrait être appliquée aux sessions multiples d'un schéma d'encodage en couches (voir la section 2.4).

6.4 Sender and Receiver Reports (Rapports d'émetteur et de récepteur)

Les paquets RTCP émetteur (SR, sender report) et récepteur (RR, receiver report) fournissent des statistiques de qualité de réception pour les médias. Les émetteurs de données réguliers (actifs) envoient des SR, et les récepteurs qui ne sont pas des émetteurs actifs envoient des RR. Les SR incluent à la fois les statistiques d'émission et de réception ; le champ additionnel est le plus utile quand un émetteur est aussi un récepteur.

Le format des paquets SR et RR, avec la présentation de leurs sous-champs, est le suivant :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                   |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                  profile-specific extensions                      |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

6.4.1 SR: Sender Report RTCP Packet (SR : paquet RTCP Rapport d'émetteur)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le format du paquet SR est le suivant :

• version (V) : 2 bits. Comme défini dans la section 5.1.

• remplissage (P) : 1 bit. Comme défini dans la section 5.1. Si le bit de remplissage est placé, ce paquet contient à la fin d'autres octets de remplissage qui ne font pas partie de l'information de contrôle. Le dernier octet de remplissage contient un compte de combien d'octets devraient être ignorés, lui-même inclus. Voir la section 6.6.1 pour la signification de remplissage pour le paquet composé. L'incrémentation n'est pas nécessaire si la longueur du paquet composé est un multiple de 4 octets.

• compte de rapport (RC, report count) : 5 bits. Le nombre de blocs de rapport de réception (reception report block) contenus dans ce paquet. Une valeur zéro est valide.

• type de paquet (PT, packet type) : 8 bits. Contient la constante 200 pour indiquer que ce paquet est un paquet RTCP SR.

• longueur (length) : 16 bits. La longueur de ce paquet RTCP en unités de 32 bits moins un ; cela inclut l'en-tête et tout remplissage. (La justification de la réduction d'un est que la valeur zéro est un choix valide dans le champ de longueur de 16 bits, alors que pour les en-têtes de protocole de couche supérieure la valeur zéro est presque toujours réservée pour une autre utilisation.) Cela est conforme au champ de longueur de 16 bits dans l'en-tête RTP fixe, décrit dans la section 5.1.

• SSRC de l'émetteur (SSRC of sender) : 32 bits. L'identificateur de la source de synchronisation pour le générateur de ce paquet.

• instant d'échantillonnage NTP (NTP timestamp) : 64 bits. Correspond à l'instant d'échantillonnage (voir la section 5.1) auquel les champs d'horodatage RTP et d'information d'émetteur dans ce rapport sont mesurés. En ce qui concerne les informations d'horodatage RTP, il n'est pas nécessaire que les horloges murales du participant soient synchronisées pour que les mesures d'horodatage NTP soient utiles. Contrairement à la plupart des machine à états, un participant n'a pas besoin d'utiliser le même horodatage NTP pour chaque paquet SR tant que la paire d'horodatages NTP et RTP est calculée à l'instant d'échantillonnage. Ce participant PEUT utiliser l'horloge murale de n'importe quel instant comme base d'horloge pour mesurer les instants d'échantillonnage, sans rapport avec l'horloge murale de n'importe quel autre participant. L'importance de ce champ est de permettre l'estimation et la synchronisation inter-média des paires d'horodatages RTP à partir de différentes sources de ce participant.

• horodatage RTP (RTP timestamp) : 32 bits. Correspond à l'instant d'échantillonnage NTP (ci-dessus) avec la même unité et le même décalage aléatoire que les horodatages RTP de la session de données. Cette correspondance peut être utilisée pour relier les horodatages RTP de médias indépendants dans une session multimédia, et pour mesurer le délai de bout en bout du flux média.

• compte de paquets de l'émetteur (sender's packet count) : 32 bits. Le nombre total de paquets RTP envoyés par l'émetteur depuis le début de la transmission jusqu'à l'instant d'échantillonnage inclus dans ce rapport. Ce compte DEVRAIT être réinitialisé si l'émetteur change son identificateur SSRC.

• compte d'octets de l'émetteur (sender's octet count) : 32 bits. Le nombre total d'octets de charge utile de média (c'est-à-dire pas incluant les en-têtes ni le remplissage) envoyés par l'émetteur dans les paquets de données RTP depuis le début de la transmission. Ce compte DEVRAIT être réinitialisé si l'émetteur change son identificateur SSRC. Ce champ peut être utilisé pour estimer le débit de charge utile moyen.

6.4.2 RR: Receiver Report RTCP Packet (RR : paquet RTCP Rapport de récepteur)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=RR=201   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                   |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                  profile-specific extensions                      |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Le format du paquet RR est le suivant :

• version (V), remplissage (P), compte de rapport (RC), type de paquet (PT), longueur (length) : comme définis pour le paquet SR (section 6.4.1).

• SSRC de l'émetteur de paquet (SSRC of packet sender) : 32 bits. L'identificateur de la source de synchronisation pour le générateur de ce paquet. Si un participant envoie des rapports de réception d'un seul média, de multiples médias d'une même session, ou de multiples médias de sessions multiples, le SSRC de paquet est celui du participant.

Un paquet RR ne contient pas d'information d'émetteur, mais suit le même format que le paquet SR à partir du champ de compte de rapport. Le format suivant est utilisé pour chaque bloc de rapport de réception si le compte de rapport est supérieur à zéro.

6.4.3 Extending the Sender and Receiver Reports (Extension des rapports d'émetteur et de récepteur)

Si un profil RTP définit des extensions d'information d'émetteur ou de récepteur au-delà de l'information de base, un profil SPÉCIFIQUE DE L'APPLICATION pourrait être défini pour les transporter au moyen d'un mécanisme de rapport d'extension. Une telle solution est spécifique à l'application et hors de portée de ce document. L'en-tête d'un paquet RTCP pourrait être suivi de sections d'extensions structurées et d'extension, mais celles-ci DEVRAIENT être définies indépendamment des mécanismes de longueur et de comptage fournis par RTCP pour les blocs de rapport de réception.

6.4.4 Analyzing Sender and Receiver Reports (Analyse des rapports d'émetteur et de récepteur)

On s'attend à ce que le retour sur la qualité de réception soit utile non seulement à l'émetteur, mais aussi aux autres récepteurs et aux moniteurs tiers. L'émetteur peut modifier ses transmissions en fonction du retour ; les récepteurs peuvent déterminer si les problèmes sont locaux, régionaux ou globaux ; les gestionnaires de réseau peuvent utiliser des moniteurs indépendants du profil qui ne reçoivent que les paquets RTCP et non les paquets de données RTP correspondants pour évaluer la performance de leurs réseaux pour la distribution multicast.

Des comptes cumulatifs sont utilisés tant dans l'information d'émetteur que dans les blocs de rapport de réception afin que des différences puissent être calculées entre n'importe quels deux rapports pour faire des mesures sur des périodes courtes et longues, et pour fournir une résilience contre la perte d'un rapport. La différence entre les deux derniers rapports reçus peut être utilisée pour estimer la qualité récente de la distribution. L'horodatage NTP est inclus afin que des débits puissent être calculés à partir de ces différences sur l'intervalle entre deux rapports. Puisque cet horodatage est indépendant de la fréquence d'horloge pour l'encodage des données, il est possible d'implémenter des moniteurs de qualité indépendants de l'encodage et du profil.

Un exemple de calcul est le taux de perte de paquets sur l'intervalle entre deux rapports de réception. La différence dans le nombre cumulatif de paquets perdus donne le nombre perdu pendant cet intervalle. La différence dans les numéros de séquence étendus reçus donne le nombre de paquets attendus pendant l'intervalle. Le rapport de ces deux valeurs est la fraction de perte de paquets sur l'intervalle. Ce rapport devrait égaler le champ fraction perdue si les deux rapports sont consécutifs, mais autrement il peut ne pas l'égaler. Le taux de perte par seconde peut être obtenu en divisant la fraction de perte par la différence des horodatages NTP, exprimée en secondes. Le nombre de paquets reçus est le nombre de paquets attendus moins le nombre perdu. Le nombre de paquets attendus peut aussi être utilisé pour juger de la validité statistique de toute estimation de perte. Par exemple, perdre 1 paquet sur 5 a une signification moindre que perdre 200 paquets sur 1000.

À partir de l'information d'émetteur, un moniteur tiers peut calculer le débit de charge utile moyen et le débit de paquets moyen sur un intervalle sans recevoir les données. Le rapport des deux donne la taille de charge utile moyenne. Si l'on peut supposer que la perte de paquets est indépendante de la taille des paquets, alors le nombre de paquets reçus par un récepteur particulier multiplié par la taille de charge utile moyenne (ou la taille de paquet correspondante) donne le débit apparent disponible pour ce récepteur.

En plus des comptes cumulatifs qui permettent des mesures de perte de paquets à long terme en utilisant les différences entre rapports, le champ fraction perdue fournit une mesure à court terme à partir d'un seul rapport. Cela devient plus important à mesure que la taille d'une session croît au point que l'information d'état de réception pourrait ne pas être conservée pour tous les récepteurs, ou que l'intervalle entre rapports devient assez long pour qu'un seul rapport ait pu être reçu d'un récepteur particulier.

Le champ gigue d'inter-arrivée (interarrival jitter) fournit une seconde mesure à court terme de l'encombrement du réseau. La perte de paquets suit l'encombrement persistant tandis que la mesure de gigue suit l'encombrement transitoire. La mesure de gigue peut indiquer un encombrement avant qu'il ne mène à une perte de paquets. Le champ gigue d'inter-arrivée n'est qu'un instantané de la gigue au moment d'un rapport et n'est pas destiné à être pris quantitativement. Plutôt, il est destiné à la comparaison à travers un certain nombre de rapports d'un récepteur dans le temps, ou de multiples récepteurs, par exemple au sein d'un même réseau, au même moment. Pour permettre la comparaison entre récepteurs, il est important que la gigue soit calculée selon la même formule par tous les récepteurs.

Parce que le calcul de gigue est basé sur l'horodatage RTP qui représente l'instant où le premier échantillon de données dans le paquet a été échantillonné, toute variation du délai entre cet instant d'échantillonnage et le moment où le paquet est transmis affectera la gigue calculée. Une telle variation de délai surviendrait pour des paquets audio de durée variable. Elle surviendrait aussi pour les encodages vidéo car l'horodatage est le même pour tous les paquets d'une trame, mais ces paquets ne sont pas tous transmis en même temps. La variation du délai jusqu'à la transmission réduit en effet la précision du calcul de gigue en tant que mesure du comportement du réseau lui-même, mais il est approprié de l'inclure considérant que le tampon de réception doit l'accommoder. Quand le calcul de gigue est utilisé comme mesure comparative, la composante (constante) due à la variation du délai jusqu'à la transmission s'annule, de sorte qu'un changement de la composante de gigue réseau peut alors être observé à moins qu'il ne soit relativement petit. Si le changement est petit, alors il est probablement sans conséquence.

6.5 SDES: Source Description RTCP Packet (SDES : paquet RTCP de description de source)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    SC   |  PT=SDES=202  |             length            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_1                          |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_2                          |
  2    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Le paquet SDES est une structure à trois niveaux composée d'un en-tête et de zéro ou plusieurs morceaux (chunks), chacun étant composé d'éléments décrivant la source identifiée dans ce morceau. Les éléments sont décrits individuellement dans les sections suivantes.

• version (V), remplissage (P), longueur (length) : Comme décrit pour le paquet SR (voir la section 6.4.1).

• type de paquet (PT) : 8 bits. Contient la constante 202 pour identifier ce paquet comme un paquet RTCP SDES.

• compte de source (SC, source count) : 5 bits. Le nombre de morceaux SSRC/CSRC contenus dans ce paquet SDES. Une valeur zéro est valide mais inutile.

Chaque morceau consiste en un identificateur SSRC/CSRC suivi d'une liste de zéro ou plusieurs éléments, qui transportent l'information sur le SSRC/CSRC. Chaque morceau commence sur une limite de 32 bits. Chaque élément consiste en un champ de type de 8 bits, un compte d'octets de 8 bits décrivant la longueur du texte (ainsi, n'incluant pas cet en-tête de deux octets), et le texte lui-même. Notez que le texte ne peut pas dépasser 255 octets, mais cela est cohérent avec le besoin de limiter la consommation de bande passante RTCP.

Le texte est encodé selon l'encodage UTF-8 spécifié dans la RFC 2279 [5]. US-ASCII est un sous-ensemble de cet encodage et ne requiert aucun encodage supplémentaire. La présence d'encodages multi-octets est indiquée en fixant le bit le plus significatif d'un caractère à un.

Les éléments sont contigus, c'est-à-dire que les éléments ne sont pas individuellement remplis jusqu'à une limite de 32 bits. Le texte n'est pas terminé par un caractère nul car certains encodages multi-octets incluent des octets nuls. La liste d'éléments dans chaque morceau DOIT être terminée par un ou plusieurs octets nuls, le premier étant interprété comme un type d'élément de zéro désignant la fin de la liste. Aucun octet de longueur ne suit l'octet de type d'élément nul, mais des octets nuls supplémentaires DOIVENT être inclus si nécessaire pour remplir jusqu'à la prochaine limite de 32 bits. Notez que ce remplissage est distinct de celui indiqué par le bit P dans l'en-tête RTCP. Un morceau avec zéro élément (quatre octets nuls) est valide mais inutile.

Les systèmes terminaux envoient un paquet SDES contenant leur propre identificateur de source (le même que le SSRC dans l'en-tête RTP fixe). Un mélangeur envoie un paquet SDES contenant un morceau pour chaque source contributrice à partir de laquelle il reçoit l'information SDES, ou plusieurs paquets SDES complets dans le format ci-dessus s'il y a plus de 31 telles sources (voir la section 7).

Les éléments SDES actuellement définis sont décrits dans les sections suivantes. Seul l'élément CNAME est obligatoire. Certains éléments montrés ici peuvent être utiles seulement pour des profils particuliers, mais les types d'éléments sont tous assignés à partir d'un espace commun pour promouvoir un usage partagé et simplifier les applications indépendantes du profil. Des éléments supplémentaires peuvent être définis dans un profil en enregistrant les numéros de type auprès de l'IANA comme décrit à la section 15.

6.5.1 CNAME: Canonical End-Point Identifier SDES Item (CNAME : élément SDES d'identificateur de point terminal canonique)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    CNAME=1    |     length    | user and domain name        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'identificateur CNAME a les propriétés suivantes :

• Puisque l'identificateur SSRC alloué aléatoirement peut changer si un conflit est découvert ou si un programme est redémarré, l'élément CNAME DOIT être inclus pour fournir la liaison entre l'identificateur SSRC et un identificateur pour la source (émetteur ou récepteur) qui reste constant.

• Comme l'identificateur SSRC, l'identificateur CNAME DEVRAIT aussi être unique parmi tous les participants au sein d'une session RTP.

• Pour fournir une liaison à travers les outils multimédias multiples utilisés par un participant dans un ensemble de sessions RTP liées, le CNAME DEVRAIT être fixe pour ce participant.

• Pour faciliter le moniteur tiers, le CNAME DEVRAIT être adapté à ce qu'un programme ou une personne localise la source.

Par conséquent, le CNAME DEVRAIT être dérivé algorithmiquement et non saisi manuellement, si possible. Pour satisfaire à ces exigences, le format suivant DEVRAIT être utilisé à moins qu'un profil ne spécifie une syntaxe ou une sémantique alternative. L'élément CNAME DEVRAIT avoir le format « user@host », ou « host » si un nom d'utilisateur n'est pas disponible comme sur les systèmes à utilisateur unique. Pour les deux formats, « host » est soit le nom de domaine pleinement qualifié (FQDN) de l'hôte à partir duquel proviennent les données en temps réel, formaté selon les règles spécifiées dans la RFC 1034 [6], la RFC 1035 [7] et la section 2.1 de la RFC 1123 [8] ; soit la représentation ASCII standard de l'adresse numérique de l'hôte sur l'interface utilisée pour la communication RTP. Par exemple, la représentation ASCII standard d'une adresse IP version 4 est la « décimale pointée » (dotted decimal), aussi connue sous le nom de dotted quad, et pour l'IP version 6, les adresses sont représentées textuellement comme des groupes de chiffres hexadécimaux séparés par des deux-points (avec des variantes détaillées dans la RFC 3513 [23]). D'autres types d'adresse sont censés avoir des représentations ASCII mutuellement uniques. Le nom de domaine pleinement qualifié est plus commode pour un observateur humain et peut éviter le besoin d'envoyer en plus un élément NAME, mais il peut être difficile ou impossible de l'obtenir de manière fiable dans certains environnements d'exploitation. Les applications qui peuvent être exécutées dans de tels environnements DEVRAIENT utiliser la représentation ASCII de l'adresse à la place.

Des exemples sont « [email protected] », « [email protected] » ou « doe@2201:056D::112E:144A:1E24 » pour un système multi-utilisateur. Sur un système sans nom d'utilisateur, des exemples seraient « sleepy.example.com », « 192.0.2.89 » ou « 2201:056D::112E:144A:1E24 ».

Le nom d'utilisateur DEVRAIT être sous une forme qu'un programme tel que « finger » ou « talk » pourrait utiliser, c'est-à-dire qu'il s'agit typiquement du nom de connexion plutôt que du nom personnel. Le nom d'hôte n'est pas nécessairement identique à celui dans l'adresse de courrier électronique du participant.

Cette syntaxe ne fournira pas d'identificateurs uniques pour chaque source si une application permet à un utilisateur de générer plusieurs sources à partir d'un hôte. Une telle application devrait s'appuyer sur le SSRC pour identifier plus avant la source, ou le profil pour cette application devrait spécifier une syntaxe supplémentaire pour l'identificateur CNAME.

Si chaque application crée son CNAME indépendamment, les CNAME résultants peuvent ne pas être identiques comme le requerrait une liaison à travers les outils multimédias multiples appartenant à un participant dans un ensemble de sessions RTP liées. Si une liaison inter-média est requise, il peut être nécessaire que le CNAME de chaque outil soit configuré de manière externe avec la même valeur par un outil de coordination.

Les auteurs d'applications devraient être conscients que les assignations d'adresses réseau privées telles que l'assignation Net-10 proposée dans la RFC 1918 [24] peuvent créer des adresses réseau qui ne sont pas globalement uniques. Cela conduirait à des CNAME non uniques si des hôtes avec des adresses privées et sans connectivité IP directe à l'Internet public ont leurs paquets RTP transférés vers l'Internet public à travers un traducteur de niveau RTP. (Voir aussi la RFC 1627 [25].) Pour traiter ce cas, les applications PEUVENT fournir un moyen de configurer un CNAME unique, mais la charge incombe au traducteur de traduire les CNAME d'adresses privées vers des adresses publiques si nécessaire pour empêcher que des adresses privées ne soient exposées.

6.5.2 NAME: User Name SDES Item (NAME : élément SDES de nom d'utilisateur)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NAME=2    |     length    | common name of source       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Il s'agit du nom réel utilisé pour décrire la source, par exemple « John Doe, Bit Recycler ». Il peut être sous toute forme désirée par l'utilisateur. Pour des applications telles que la conférence, cette forme de nom peut être la plus désirable à afficher dans les listes de participants, et par conséquent pourrait être envoyée le plus fréquemment de ces éléments autres que CNAME. Les profils PEUVENT établir de telles priorités. La valeur NAME est censée rester constante au moins pour la durée d'une session. Elle NE DEVRAIT PAS être considérée comme unique parmi tous les participants de la session.

6.5.3 EMAIL: Electronic Mail Address SDES Item (EMAIL : élément SDES d'adresse de courrier électronique)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    EMAIL=3    |     length    | email address of source     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'adresse de courrier électronique est formatée selon la RFC 2822 [9], par exemple « [email protected] ». La valeur EMAIL est censée rester constante pour la durée d'une session.

6.5.4 PHONE: Phone Number SDES Item (PHONE : élément SDES de numéro de téléphone)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    PHONE=4    |     length    | phone number of source      ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le numéro de téléphone DEVRAIT être formaté avec le signe plus remplaçant le code d'accès international. Par exemple, « +1 908 555 1212 » pour un numéro aux États-Unis.

6.5.5 LOC: Geographic User Location SDES Item (LOC : élément SDES de localisation géographique de l'utilisateur)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     LOC=5     |     length    | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Selon l'application, différents degrés de détail sont appropriés pour cet élément. Pour les applications de conférence, une chaîne comme « Murray Hill, New Jersey » peut suffire, tandis que pour un système de badge actif, des chaînes comme « Room 2A244, AT&T BL MH » pourraient être appropriées. Le degré de détail est laissé à l'implémentation et/ou à l'utilisateur, mais le format et le contenu PEUVENT être prescrits par un profil. La valeur LOC est censée rester constante pour la durée d'une session, excepté pour les hôtes mobiles.

6.5.6 TOOL: Application or Tool Name SDES Item (TOOL : élément SDES de nom d'application ou d'outil)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TOOL=6    |     length    |name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Une chaîne donnant le nom et éventuellement la version de l'application générant le flux, par exemple « videotool 1.2 ». Cette information peut être utile à des fins de débogage et est similaire aux en-têtes SMTP Mailer ou Mail-System-Version. La valeur TOOL est censée rester constante pour la durée d'une session.

6.5.7 NOTE: Notice/Status SDES Item (NOTE : élément SDES d'avis/statut)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NOTE=7    |     length    | note about the source       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Les sémantiques suivantes sont suggérées pour cet élément, mais ces sémantiques ou d'autres PEUVENT être explicitement définies par un profil. L'élément NOTE est destiné aux messages transitoires décrivant l'état courant de la source, par exemple « au téléphone, ne peut pas parler ». Ou, durant un séminaire, cet élément pourrait être utilisé pour transmettre le titre de l'exposé. Il devrait être utilisé seulement pour transporter une information exceptionnelle et NE DEVRAIT PAS être inclus de manière systématique par tous les participants car cela ralentirait le débit auquel les rapports de réception et CNAME sont envoyés, altérant ainsi la performance du protocole. En particulier, il NE DEVRAIT PAS être inclus comme élément dans le fichier de configuration d'un utilisateur ni généré automatiquement comme une citation-du-jour.

Puisque l'élément NOTE peut être important à afficher tant qu'il est actif, le débit auquel d'autres éléments non-CNAME tels que NAME sont transmis peut être réduit afin que l'élément NOTE puisse prendre cette part de la bande passante RTCP. Quand le message transitoire devient inactif, l'élément NOTE DEVRAIT continuer à être transmis quelques fois au même taux de répétition mais avec une chaîne de longueur zéro pour signaler aux récepteurs. Toutefois, les récepteurs DEVRAIENT aussi considérer l'élément NOTE inactif s'il n'est pas reçu pendant un petit multiple du taux de répétition, ou peut-être 20 à 30 intervalles RTCP.

6.5.8 PRIV: Private Extensions SDES Item (PRIV : élément SDES d'extensions privées)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     PRIV=8    |     length    | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |                  value string               ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cet élément est utilisé pour définir des extensions SDES expérimentales ou spécifiques à l'application. L'élément contient un préfixe consistant en une paire longueur-chaîne, suivi de la chaîne de valeur remplissant le reste de l'élément et transportant l'information désirée. Le champ de longueur de préfixe a une longueur de 8 bits. La chaîne de préfixe est un nom choisi par la personne définissant l'élément PRIV pour être unique par rapport aux autres éléments PRIV que cette application pourrait recevoir. Le créateur de l'application pourrait choisir d'utiliser le nom de l'application plus une identification de sous-type supplémentaire si nécessaire. Alternativement, il est RECOMMANDÉ que d'autres choisissent un nom basé sur l'entité qu'ils représentent, puis coordonnent l'usage du nom au sein de cette entité.

Notez que le préfixe consomme de l'espace dans la longueur totale de 255 octets de l'élément, donc le préfixe devrait être aussi court que possible. Cette facilité et la bande passante RTCP contrainte NE DEVRAIENT PAS être surchargées ; elle n'est pas destinée à satisfaire toutes les exigences de communication de contrôle de toutes les applications.

Les préfixes SDES PRIV ne seront pas enregistrés par l'IANA. Si une forme de l'élément PRIV s'avère d'utilité générale, il DEVRAIT plutôt lui être assigné un type d'élément SDES régulier enregistré auprès de l'IANA afin qu'aucun préfixe ne soit requis. Cela simplifie l'usage et augmente l'efficacité de transmission.

6.6 BYE: Goodbye RTCP Packet (BYE : paquet RTCP d'au revoir)

 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|    SC   |   PT=BYE=203  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                              ...                              :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) |     length    |               reason for leaving            ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le paquet BYE indique qu'une ou plusieurs sources ne sont plus actives.

• version (V), remplissage (P), longueur (length) : Comme décrit pour le paquet SR (voir la section 6.4.1).

• type de paquet (PT) : 8 bits. Contient la constante 203 pour identifier ce paquet comme un paquet RTCP BYE.

• compte de source (SC, source count) : 5 bits. Le nombre d'identificateurs SSRC/CSRC inclus dans ce paquet BYE. Une valeur de compte de zéro est valide, mais inutile.

Les règles pour savoir quand un paquet BYE doit être envoyé sont spécifiées aux sections 6.3.7 et 8.2.

Si un paquet BYE est reçu par un mélangeur, le mélangeur DEVRAIT transférer le paquet BYE avec les identificateurs SSRC/CSRC inchangés. Si un mélangeur s'arrête, il DEVRAIT envoyer un paquet BYE listant toutes les sources contributrices qu'il gère, ainsi que son propre identificateur SSRC. En option, le paquet BYE PEUT inclure un compte d'octets de 8 bits suivi de ce nombre d'octets de texte indiquant la raison du départ, par exemple « camera malfunction » ou « RTP loop detected ». La chaîne a le même encodage que celui décrit pour SDES. Si la chaîne remplit le paquet jusqu'à la prochaine limite de 32 bits, la chaîne n'est pas terminée par un caractère nul. Sinon, le paquet BYE DOIT être rempli avec des octets nuls jusqu'à la prochaine limite de 32 bits. Ce remplissage est distinct de celui indiqué par le bit P dans l'en-tête RTCP.

6.7 APP: Application-Defined RTCP Packet (APP : paquet RTCP défini par l'application)

 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| subtype |   PT=APP=204  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          name (ASCII)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   application-dependent data                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le paquet APP est destiné à un usage expérimental au fur et à mesure que de nouvelles applications et de nouvelles fonctionnalités sont développées, sans requérir l'enregistrement d'une valeur de type de paquet. Les paquets APP avec des noms non reconnus DEVRAIENT être ignorés. Après test, et si un usage plus large est justifié, il est RECOMMANDÉ que chaque paquet APP soit redéfini sans les champs de sous-type et de nom et enregistré auprès de l'IANA en utilisant un type de paquet RTCP.

• version (V), remplissage (P), longueur (length) : Comme décrit pour le paquet SR (voir la section 6.4.1).

• sous-type (subtype) : 5 bits. Peut être utilisé comme un sous-type pour permettre qu'un ensemble de paquets APP soit défini sous un nom unique, ou pour toute donnée dépendante de l'application.

• type de paquet (PT) : 8 bits. Contient la constante 204 pour identifier ce paquet comme un paquet RTCP APP.

• nom (name) : 4 octets. Un nom choisi par la personne définissant l'ensemble de paquets APP pour être unique par rapport aux autres paquets APP que cette application pourrait recevoir. Le créateur de l'application pourrait choisir d'utiliser le nom de l'application, puis coordonner l'allocation des valeurs de sous-type à d'autres qui veulent définir de nouveaux types de paquets pour l'application. Alternativement, il est RECOMMANDÉ que d'autres choisissent un nom basé sur l'entité qu'ils représentent, puis coordonnent l'usage du nom au sein de cette entité. Le nom est interprété comme une séquence de quatre caractères ASCII, les caractères majuscules et minuscules étant traités comme distincts.

• données dépendantes de l'application (application-dependent data) : longueur variable. Les données dépendantes de l'application peuvent ou non apparaître dans un paquet APP. Elles sont interprétées par l'application et non par RTP lui-même. Elles DOIVENT avoir une longueur multiple de 32 bits.