12.07.2015 Views

RTP : protocole de transport - RFC

RTP : protocole de transport - RFC

RTP : protocole de transport - RFC

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!