<strong>RFC</strong> 3550 page - 18 - Schulzrinne & autres6.3.5 Expiration <strong>de</strong> la temporisation d'un SSRCÀ <strong>de</strong>s intervalles occasionnels, le participant DOIT vérifier pour voir si un <strong>de</strong>s autres participants arrive en fin <strong>de</strong>temporisation. Pour ce faire, le participant calcule l'intervalle calculé déterministe (sans le facteur aléatoire) Td pour unreceveur, c'est-à-dire, avec we_sent faux. Tout autre membre <strong>de</strong> la session qui n'a pas envoyé un paquet <strong>RTP</strong> ou RTCP<strong>de</strong>puis le temps tc - MTd (M est le multiplicateur <strong>de</strong> temporisation, et prend la valeur 5 par défaut) est périmé. Cela signifieque son SSRC est retiré <strong>de</strong> la liste <strong>de</strong>s membres, et members est mis à jour. Une vérification similaire est effectuée sur laliste <strong>de</strong>s envoyeurs. Tout membre qui est sur la liste <strong>de</strong>s envoyeurs et n'a pas envoyé <strong>de</strong> paquet <strong>RTP</strong> <strong>de</strong>puis le temps tc - 2T(pendant les <strong>de</strong>ux <strong>de</strong>rniers intervalles <strong>de</strong> rapport RTCP) est retiré <strong>de</strong> la liste <strong>de</strong>s envoyeurs, et sen<strong>de</strong>rs est mis à jour.Si un membre est périmé, l'algorithme <strong>de</strong> reconsidération inverse décrit au paragraphe 6.3.4 DEVRAIT être effectué.Le participant DOIT effectuer cette vérification au moins une fois par intervalle <strong>de</strong> transmission RTCP.6.3.6 Expiration du temporisateur <strong>de</strong> transmissionLorsque le temporisateur <strong>de</strong> transmission <strong>de</strong> paquet arrive à expiration, le participant effectue les opérations suivantes :oooL'intervalle <strong>de</strong> transmission T est calculé comme décrit au paragraphe 6.3.1, y compris le facteur aléatoire.Si tp + T est inférieur ou égal à tc, un paquet RTCP est transmis. tp est réglé à tc, puis une autre valeur est calculée pourT comme à l'étape précé<strong>de</strong>nte et tn est réglé à tc + T. Le temporisateur <strong>de</strong> transmission est réglé pour arriver àexpiration à nouveau au moment tn. Si tp + T est supérieur à tc, tn est réglé à tp + T. Aucun paquet RTCP n'esttransmis. Le temporisateur <strong>de</strong> transmission est réglé pour arriver à expiration au moment tn.pmembers est réglé à members.Si un paquet RTCP est transmis, la valeur <strong>de</strong> initial est réglée à FAUX. De plus, la valeur <strong>de</strong> avg_rtcp_size est mise à jour :avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_sizeoù packet_size est la taille du paquet RTCP qui vient d'être transmis.6.3.7 Transmission d'un paquet BYELorsque un participant souhaite quitter une session, un paquet BYE est transmis pour informer les autres participants <strong>de</strong>l'événement. Afin d'éviter un flot <strong>de</strong> paquets BYE lorsque <strong>de</strong> nombreux participants quittent le système, un participantDOIT exécuter l'algorithme suivant si le nombre <strong>de</strong> membres est supérieur à 50 lorsque le participant choisit <strong>de</strong> partir. Cetalgorithme usurpe le rôle normal <strong>de</strong> la variable members pour compter à sa place le nombre <strong>de</strong> paquets BYE:oooLorsque le participant déci<strong>de</strong> <strong>de</strong> quitter le système, tp est remis à tc, l'heure actuelle, members et pmembers sontinitialisés à 1, initial est mis à 1, we_sent est mis à faux, sen<strong>de</strong>rs est mis à 0, et avg_rtcp_size est réglé à la taille dupaquet composé BYE. L'intervalle calculé T est calculé. Le paquet BYE est alors programmé pour l'instant tn = tc + T.Chaque fois qu'un paquet BYE provenant d'un autre participant est reçu, members est incrémenté <strong>de</strong> 1 sansconsidération du fait que ce participant existe ou non dans le tableau <strong>de</strong>s membres, et lorsque l'échantillonnage <strong>de</strong>SSRC est utilisé, sans considération <strong>de</strong> ce que le SSRC BYE <strong>de</strong>vrait être ou non inclus dans l'échantillon. membersN'EST PAS incrémenté lorsque d'autres paquets RTCP ou <strong>RTP</strong> sont reçus, mais seulement les paquets BYE. De même,avg_rtcp_size n'est mis à jour que pour les paquets BYE reçus. sen<strong>de</strong>rs N'EST PAS mis à jour lorsque <strong>de</strong>s paquets <strong>RTP</strong>arrivent ; il reste à 0.La transmission du paquet BYE suit alors les règles <strong>de</strong> transmission d'un paquet RTCP normal, comme ci-<strong>de</strong>ssus.Cela permet d'envoyer tout <strong>de</strong> suite les paquets BYE, et donc <strong>de</strong> contrôler leur utilisation totale <strong>de</strong> ban<strong>de</strong> passante. Dans lepire <strong>de</strong>s cas, cela pourrait être cause que les paquets <strong>de</strong> contrôle RTCP utilisent <strong>de</strong>ux fois plus <strong>de</strong> ban<strong>de</strong> passante que lanormale (10 %) – 5 % pour les paquets RTCP non BYE et 5 % pour BYE.Un participant qui ne veut pas attendre que le mécanisme ci-<strong>de</strong>ssus permette la transmission d'un paquet BYE PEUT quitterle groupe sans envoyer <strong>de</strong> BYE du tout. Ce participant va finalement être mis en fin <strong>de</strong> temporisation par les autresmembres du groupe.
<strong>RFC</strong> 3550 page - 19 - Schulzrinne & autresSi l'estimation <strong>de</strong> la taille du groupe est inférieure à 50 lorsque le participant déci<strong>de</strong> <strong>de</strong> le quitter, le participant PEUTenvoyer immédiatement un paquet BYE. Autrement, le participant PEUT choisir d'exécuter l'algorithme <strong>de</strong> sauvegar<strong>de</strong>BYE ci-<strong>de</strong>ssus.Dans l'un et l'autre cas, un participant qui n'a jamais envoyé <strong>de</strong> paquet <strong>RTP</strong> ou RTCP NE DOIT PAS envoyer un paquetBYE lorsque il quitte le groupe.6.3.8 Mise à jour <strong>de</strong> we_sentLa variable we_sent contient vrai si le participant a envoyé récemment un paquet <strong>RTP</strong>, faux autrement. Cette déterminationse fait en utilisant le même mécanisme que pour gérer l'ensemble <strong>de</strong>s autres participants énumérés dans le tableau <strong>de</strong>senvoyeurs. Si le participant envoie un paquet <strong>RTP</strong> lorsque we_sent est faux, il s'ajoute lui-même au tableau <strong>de</strong>s envoyeurset règle we_sent à vrai. L'algorithme <strong>de</strong> reconsidération inverse décrit au paragraphe 6.3.4 DEVRAIT être effectué pouréventuellement réduire le délai avant l'envoi d'un paquet SR. Chaque fois qu'un autre paquet <strong>RTP</strong> est envoyé, le temps <strong>de</strong>transmission <strong>de</strong> ce paquet est conservé dans le tableau. L'algorithme normal <strong>de</strong> temporisation d'envoi est alors appliqué auparticipant – si un paquet <strong>RTP</strong> n'a pas été transmis <strong>de</strong>puis tc - 2T, le participant se retire lui-même du tableau <strong>de</strong>senvoyeurs, décrémente le compte <strong>de</strong>s envoyeurs, et remet we_sent à faux.6.3.9 Allocation <strong>de</strong> ban<strong>de</strong> passante <strong>de</strong> <strong>de</strong>scription <strong>de</strong> sourceCette spécification définit plusieurs éléments <strong>de</strong> <strong>de</strong>scription <strong>de</strong> source (SDES) en plus <strong>de</strong> l'élément obligatoire CNAME,tels que NAME (nom <strong>de</strong> la personne) et EMAIL (adresse <strong>de</strong> messagerie). Elle fournit aussi un moyen pour définir <strong>de</strong>nouveaux types <strong>de</strong> paquet RTCP spécifiques <strong>de</strong> l'application. Les applications <strong>de</strong>vraient faire attention en allouant <strong>de</strong> laban<strong>de</strong> passante <strong>de</strong> contrôle à ces informations supplémentaires parce que cela va ralentir le taux d'envoi <strong>de</strong>s rapports <strong>de</strong>réception et <strong>de</strong>s CNAME, et donc dégra<strong>de</strong>r les performances du <strong>protocole</strong>. Il est RECOMMANDÉ que pas plus <strong>de</strong> 20 % <strong>de</strong>la ban<strong>de</strong> passante RTCP allouée à un seul participant ne soit utilisée pour porter les informations supplémentaires. De plus,il n'est pas prévu que tous les éléments <strong>de</strong> SDES soient inclus dans chaque application. Ceux qui sont inclus DEVRAIENTse voir allouer une fraction <strong>de</strong> la ban<strong>de</strong> passante conformément à leur utilité. Plutôt que d'estimer cette fraction <strong>de</strong> façondynamique, il est recommandé que les pourcentages soit traduits <strong>de</strong> façon statique dans les comptes d'intervalles <strong>de</strong>rapports sur la base <strong>de</strong> la longueur normale d'un élément.Par exemple, une application peut être conçue pour envoyer seulement CNAME, NAME et EMAIL et aucun <strong>de</strong>s autres.NAME peut avoir reçu une bien plus forte priorité que EMAIL parce que le NAME sera affiché en continu dans l'interfaced'utilisateur <strong>de</strong> l'application, alors que EMAIL ne sera affiché que sur <strong>de</strong>man<strong>de</strong>. À chaque intervalle RTCP, un paquet RRet un paquet SDES avec l'élément CNAME sera envoyé. Pour une petite session fonctionnant à l'intervalle minimum, ceserait toutes les 5 secon<strong>de</strong>s en moyenne. Chaque troisième intervalle (15 secon<strong>de</strong>s), un élément supplémentaire serait inclusdans le paquet SDES. Sept fois sur huit, cela sera l'élément NAME, et toutes les huitièmes fois (2 minutes) ce sera l'élémentEMAIL.Lorsque plusieurs applications fonctionnent <strong>de</strong> concert en utilisant une liaison trans-application à travers un CNAMEcommun pour chaque participant, par exemple dans une conférence multimédia composée d'une session <strong>RTP</strong> pour chaquesupport, les informations <strong>de</strong> SDES additionnelles PEUVENT être envoyées dans seulement une session <strong>RTP</strong>. Les autressessions vont porter seulement l'élément CNAME. En particulier, cette approche <strong>de</strong>vrait être appliquée aux multiplessessions d'un schéma <strong>de</strong> codage en couches (voir au paragraphe 2.4).6.4 Rapports d'envoyeur et <strong>de</strong> receveurLes receveurs <strong>RTP</strong> fournissent un retour <strong>de</strong> qualité <strong>de</strong> réception en utilisant les paquets <strong>de</strong> rapport RTCP qui peuventprendre une forme parmi <strong>de</strong>ux selon que le receveur est ou non aussi un envoyeur. La seule différence entre les formes <strong>de</strong>rapport d'envoyeur (SR) et <strong>de</strong> rapport <strong>de</strong> receveur (RR), à part le co<strong>de</strong> <strong>de</strong> type <strong>de</strong> paquet, est que le rapport d'envoyeurcomporte une section <strong>de</strong> 20 octets d'informations sur l'envoyeur qui est utilisée par les envoyeurs actifs. Le SR est produitsi un site a envoyé <strong>de</strong>s paquets <strong>de</strong> données durant l'intervalle écoulé <strong>de</strong>puis l'envoi du <strong>de</strong>rnier rapport ou du précé<strong>de</strong>nt,autrement, c'est le RR qui est produit.Les <strong>de</strong>ux formes SR et RR comportent zéro, un ou plusieurs blocs <strong>de</strong> rapport <strong>de</strong> réception, un pour chacune <strong>de</strong>s sources <strong>de</strong>synchronisation <strong>de</strong> laquelle ce receveur a reçu les paquets <strong>de</strong> données <strong>RTP</strong> <strong>de</strong>puis le <strong>de</strong>rnier rapport. Les rapports ne sontpas produits pour les sources contributives énumérées dans la liste <strong>de</strong> CSRC. Chaque bloc <strong>de</strong> rapport <strong>de</strong> réception donne<strong>de</strong>s statistiques sur les données reçues <strong>de</strong> la source particulière indiquée dans ce bloc. Comme un maximum <strong>de</strong> 31 blocs <strong>de</strong>rapport <strong>de</strong> réception va tenir dans un paquet SR ou RR, <strong>de</strong>s paquets RR supplémentaires DEVRAIENT être empilés aprèsle paquet initial SR ou RR comme nécessaire pour contenir les rapports <strong>de</strong> réception pour toutes les sources entenduesdurant l'intervalle écoulé <strong>de</strong>puis le <strong>de</strong>rnier rapport. Si il y a trop <strong>de</strong> sources pour faire tenir tous les paquets RR nécessaires