RTP : protocole de transport - RFC

RFC 3550 page - 22 - Schulzrinne & autresC'est la fraction des paquets de données RTP provenant de la source de SSRC_n qui est perdue depuis que le précédentpaquet SR ou RR a été envoyé, exprimée par un nombre à virgule fixe avec la virgule binaire au bord gauche du champ.(Ceci est équivalent à prendre la partie entière après avoir multiplié la fraction de perte par 256.) Cette fraction se définitcomme le nombre de pertes de paquets divisée par le nombre de paquets attendus, comme défini au paragraphe suivant.Une mise en œuvre est donnée à l'Appendice A.3. Si la perte est négative du fait de duplications, la fraction de perte estréglée à zéro. Noter qu'un receveur ne peut pas dire que des paquets ont été perdus après le dernier reçu, et qu'il n'y aura pasde bloc de rapport de réception produit pour une source si tous les paquets provenant de cette source envoyés durant ledernier intervalle de rapport ont été perdus.nombre cumulé de paquets perdus : 24 bitsC'est le nombre total de paquets de données RTP provenant de la source de SSRC_n qui ont été perdus depuis le début de laréception. Ce nombre est défini comme le nombre de paquets attendus moins le nombre de paquets réellement reçus, danslequel le nombre de paquets reçus inclut tous ceux qui sont en retard ou dupliqués. Et donc, les paquets qui arrivent enretard ne sont pas comptés comme perdus, et la perte peut être négative si il y a des duplications. Le nombre de paquetsattendus est défini comme étant le dernier type étendu de charge utile reçu, comme défini ensuite, moins le type initial decharge utile reçu. Cela peut être calculé comme indiqué à l'Appendice A.3.plus haut type étendu de charge utile reçu : 32 bitsLes 16 bits de moindre poids contiennent le plus haut type de charge utile reçu dans un paquet de données RTP provenantde la source de SSRC_n, et les 16 bits de poids fort étendent ce type de charge utile avec le compte correspondant de cyclesde type de charge utile, qui peut être entretenu conformément à l'algorithme de l'Appendice A.1. Noter que différentsreceveurs au sein de la même session vont générer des extensions différentes au type de charge utile si leurs instants dedébut diffèrent de façon significative.gigue inter arrivée : 32 bitsC'est une estimation de la variance statistique du temps inter arrivée des paquets de données RTP, mesurée en unitésd'horodatage et exprimée par un entier non signé. La gigue inter arrivées J est définie comme étant l'écart type (valeurabsolue lissée) de la différence D de l'espacement de paquet chez le receveur comparée à l'envoyeur pour une paire depaquets. Comme montré dans l'équation ci-dessous, cela est équivalent à la différence du "temps de transit relatif" pour lesdeux paquets ; le temps de transit relatif est la différence entre l'horodatage RTP d'un paquet et l'horloge du receveur aumoment de l'arrivée, mesurés dans les mêmes unités.Si Si est l'horodatage RTP pour le paquet i, et si Ri est l'heure d'arrivée en unités d'horodatage RTP pour le paquet i, alorspour deux paquets i et j, D peut être exprimé parD(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)La gigue inter arrivée DEVRAIT être calculée en continu lorsque chaque paquet de données i est reçu de la sourceSSRC_n, en utilisant cette différence D pour ce paquet et le précédent paquet i-1 dans l'ordre d'arrivée (pas nécessairementen séquence), conformément à la formuleJ(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16Chaque fois qu'est produit un rapport de réception, la valeur courante de J est échantillonnée.Le calcul de la gigue DOIT se conformer à la formule spécifiée ici afin de permettre aux moniteurs indépendants du profilde faire des interprétations valides des rapports provenant des différentes mises en œuvre. Cet algorithme est l'estimateuroptimal de premier ordre et le paramètre gain 1/16 donne un bon rapport de réduction de bruit tout en conservant un taux deconvergence raisonnable [22]. Un exemple de mise en œuvre est donné à l'Appendice A.8. Voir au paragraphe 6.4.4 unediscussion sur les effets de la variation de la durée de paquet et du délai avant transmission.dernier horodatage SR (LSR) : 32 bitsLes 32 bits médians parmi les 64 de l'horodatage NTP (comme expliqué à la Section 4) reçus au titre du plus récent paquetSDR de rapport d'envoyeur RTCP provenant de la source SSRC_n. Si aucun SR n'a été encore reçu, le champ est mis àzéro.délai depuis le dernier SR (DLSR) : 32 bitsC'est le délai, exprimé en unités de 1/65536 s, entre la réception du dernier paquet SR de la source SSRC_n et l'envoi de cebloc de rapport de réception. Si aucun paquet SR n'a encore été reçu de SSRC_n, le champ DLSR est mis à zéro.Soit SSRC_r qui note le receveur produisant ce rapport de receveur. La source SSRC_n peut calculer le délai depropagation aller-retour au SSRC_r en enregistrant l'heure A à laquelle est reçu ce rapport de réception. Il calcule le tempstotal d'aller-retour A-LSR en utilisant le dernier champ d'horodatage SR (LSR), et en soustrayant ensuite ce champ pour