2. Synchronisation des flux RTP
Les flux RTP sont synchronisés par les récepteurs sur la base des informations contenues dans les paquets RTCP SR générés par les émetteurs (plus précisément, l'horodatage au format NTP et l'horodatage RTP). La synchronisation exige qu'une horloge de référence commune DOIVE être utilisée pour générer les horodatages au format NTP dans un ensemble de flux qui doivent être synchronisés (c'est-à-dire que lors de la synchronisation de plusieurs flux RTP, les horodatages RTP pour chaque flux sont dérivés d'horloges séparées et spécifiques au média, mais les horodatages au format NTP dans les paquets RTCP SR de tous les flux à synchroniser DOIVENT être échantillonnés à partir de la même horloge). Pour obtenir une synchronisation plus rapide et plus précise, il est en outre RECOMMANDÉ que les émetteurs et les récepteurs utilisent une horloge de référence commune synchronisée au format NTP avec des propriétés communes, en particulier la base de temps, lorsque cela est possible (en reconnaissant que cela n'est souvent pas possible lorsque RTP est utilisé en dehors d'environnements contrôlés) ; les moyens par lesquels cette horloge de référence commune et ses propriétés sont signalés et distribués sortent du cadre de ce mémorandum.
Pour les sessions multimédias, chaque type de média (par exemple, audio ou vidéo) est envoyé dans une session RTP séparée, et le récepteur associe les flux RTP à synchroniser au moyen de l'élément identifiant de point final canonique (CNAME) inclus dans les paquets RTCP Source Description (SDES) générés par l'émetteur ou signalés hors bande [RFC5576]. Pour les médias en couches, différentes couches peuvent être envoyées dans différentes sessions RTP, ou en utilisant différentes valeurs de source de synchronisation (SSRC) au sein d'une seule session RTP ; dans les deux cas, le CNAME est utilisé pour identifier les flux à synchroniser. Pour assurer la synchronisation, un émetteur RTP DOIT donc envoyer des paquets RTCP composés périodiques conformément à la section 6 de la RFC 3550 [RFC3550].
Le cadencement de ces paquets RTCP composés périodiques dépendra du nombre de membres dans chaque session RTP, de la fraction de ceux qui envoient des données, de la bande passante de la session, de la fraction de bande passante RTCP configurée, et du fait que la session est en multidiffusion ou en monodiffusion (voir la RFC 3550, section 6.2 pour plus de détails). En résumé, une petite fraction, généralement 5 %, de la bande passante de la session est allouée au trafic de contrôle RTCP, et de cette fraction, un quart est alloué aux émetteurs RTP actifs, tandis que les récepteurs utilisent les trois quarts restants (ces fractions peuvent être configurées via le protocole de description de session (SDP) [RFC3556]). Chaque membre d'une session RTP dérive un intervalle de rapport RTCP basé sur ces fractions, selon que la session est en multidiffusion ou en monodiffusion, le nombre de membres qu'il a observés, et s'il envoie activement des données ou non. Il envoie ensuite un paquet RTCP composé en moyenne une fois par intervalle de rapport (le temps de transmission réel du paquet est randomisé dans la plage [0,5 ... 1,5] fois l'intervalle de rapport pour éviter la synchronisation des rapports).
Un intervalle de rapport minimum de 5 secondes est RECOMMANDÉ, sauf que le délai avant l'envoi du rapport initial "PEUT être fixé à la moitié de l'intervalle minimum pour permettre une notification plus rapide de la présence du nouveau participant" [RFC3550]. De plus, pour les sessions en monodiffusion, "le délai avant l'envoi du paquet RTCP composé initial PEUT être de zéro" [RFC3550]. En outre, pour les sessions en monodiffusion, et pour les émetteurs actifs dans une session en multidiffusion, l'intervalle de rapport minimum fixe PEUT être mis à l'échelle de "360 divisé par la bande passante de la session en kilobits/seconde. Ce minimum est inférieur à 5 secondes pour les bandes passantes supérieures à 72 kb/s" [RFC3550].
2.1. Délai de synchronisation initial
Une session multimédia comprend un ensemble de sessions RTP simultanées parmi un groupe commun de participants, utilisant une session RTP pour chaque type de média. Par exemple, une vidéoconférence (qui est une session multimédia) peut contenir une session RTP audio et une session RTP vidéo. Pour permettre à un récepteur de synchroniser les composants d'une session multimédia, un paquet RTCP composé contenant un paquet RTCP SR et un paquet RTCP SDES avec un élément CNAME DOIT être envoyé à chacune des sessions RTP de la session multimédia par chaque émetteur. Un récepteur ne peut pas synchroniser la lecture sur l'ensemble de la session multimédia tant que de tels paquets RTCP n'ont pas été reçus sur toutes les sessions RTP composantes. S'il n'y a pas de perte de paquets, cela donne un délai de synchronisation initial attendu égal au temps moyen mis pour recevoir le premier paquet RTCP dans la session RTP ayant l'intervalle de rapport RTCP le plus long. Cela variera entre les sessions RTP en monodiffusion et en multidiffusion.
Le délai de synchronisation initial pour les sessions en couches est similaire à celui des sessions multimédias. Les couches ne peuvent pas être synchronisées tant que les informations RTCP SR et CNAME n'ont pas été reçues pour chaque couche de la session.
2.1.1. Sessions en monodiffusion
Pour les sessions multimédias ou en couches en monodiffusion, les expéditeurs DEVRAIENT transmettre un paquet RTCP composé initial (contenant un paquet RTCP SR et un paquet RTCP SDES avec un élément CNAME) immédiatement après avoir rejoint chaque session RTP de la session multimédia. Les sessions RTP individuelles sont considérées comme ayant été rejointes une fois que toute signalisation en bande pour la traversée du NAT (par exemple, [RFC5245]) et/ou le cryptage de sécurité (par exemple, [RFC5764], [ZRTP]) est terminée, et que le chemin média est ouvert. Cela implique que le paquet RTCP initial est envoyé en parallèle avec le premier paquet de données, conformément aux directives de la RFC 3550 selon lesquelles "le délai avant l'envoi du paquet RTCP composé initial PEUT être de zéro" et, en l'absence de toute perte de paquets, les flux peuvent être synchronisés immédiatement.
On s'attend à ce que les trous d'épingle NAT, les trous de pare-feu, la qualité de service et les clés de sécurité média aient été négociés dans le cadre de la signalisation, qu'elle soit en bande ou hors bande, avant que le premier paquet RTCP ne soit envoyé. Cela devrait garantir que tous les boîtiers intermédiaires sont prêts à accepter le trafic et réduire la probabilité que le paquet RTCP initial soit perdu.
2.1.2. Sessions de multidiffusion spécifique à la source (SSM)
Pour les sessions en multidiffusion, le délai avant l'envoi du paquet RTCP initial, et donc le délai de synchronisation, varie en fonction de la bande passante de la session et du nombre de membres de la session. Pour une session multimédia ou en couches en multidiffusion, le délai de synchronisation moyen dépendra de la plus lente des sessions RTP composantes ; ce sera généralement la session ayant la bande passante la plus faible (en supposant que toutes les sessions RTP ont le même nombre de membres).
Lors de l'envoi à un groupe de multidiffusion, l'intervalle de rapport RTCP minimum réduit de 360 secondes divisé par la bande passante de la session en kilobits par seconde [RFC3550] doit être utilisé lorsque la latence de synchronisation est susceptible d'être un problème. De plus, comme d'habitude, l'intervalle de rapport est divisé par deux pour le premier paquet RTCP. En fonction de la bande passante de la session et du nombre de membres, cela donne les délais de synchronisation moyens présentés dans la figure 1.
Bande passante| Nombre de récepteurs :
de session | 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 5.47 5.47 5.47 5.47 5.47
16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73
32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 1 : Délai de synchronisation initial moyen en secondes
pour une session RTP avec 1 émetteur
Ces chiffres supposent un canal de multidiffusion spécifique à la source avec un seul émetteur actif, en supposant une taille moyenne de paquet RTCP de 70 octets. Ces intervalles sont suffisants pour la synchronisation labiale (lip-sync) sans délai excessif, mais pourraient être considérés comme ayant trop de latence pour synchroniser les parties d'un flux vidéo en couches.
L'intervalle RTCP est randomisé de la manière habituelle, de sorte que le délai de synchronisation minimum sera la moitié de ces intervalles, et le délai maximum sera de 1,5 fois ces intervalles. Notez également que ces intervalles RTCP sont calculés en supposant une connaissance parfaite du nombre de membres de la session.
2.1.3. Sessions de multidiffusion Any-Source (ASM)
Pour les sessions ASM, la fraction de membres qui sont des émetteurs joue un rôle important et provoque plus de variations dans l'intervalle moyen de rapport RTCP. Ceci est illustré par la figure 2 et la figure 3, qui montrent l'intervalle de rapport RTCP pour les mêmes bandes passantes de session et populations de récepteurs que la session SSM décrite dans la figure 1, mais pour des sessions avec 2 et 10 émetteurs, respectivement. On peut voir que le délai de synchronisation initial varie en fonction du nombre d'émetteurs (ceci afin de garantir que le trafic RTCP total de tous les membres du groupe ne croisse pas sans limite) et peut être nettement plus important que pour les groupes spécifiques à la source. Malgré cela, le temps de synchronisation initial reste acceptable pour la synchronisation labiale dans les scénarios typiques de visioconférence de groupe de taille petite à moyenne.
Notez que les groupes multi-émetteurs mis en œuvre à l'aide de l'unidiffusion multiple avec un traducteur RTP central (Topo-Translator dans la terminologie de [RFC5117]) ou un mélangeur (Topo-Mixer), ou certaines formes de MCU à commutation vidéo (Topo-Video-switch-MCU) distribuent les paquets RTCP à tous les membres du groupe, et évoluent donc de la même manière qu'un groupe ASM en ce qui concerne la latence de synchronisation initiale.
Bande passante| Nombre de récepteurs :
de session | 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 2 : Délai de synchronisation initial moyen en secondes
pour une session RTP avec 2 émetteurs
Bande passante| Nombre de récepteurs :
de session | 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Figure 3 : Délai de synchronisation initial moyen en secondes
pour une session RTP avec 10 émetteurs
2.1.4. Discussion
Pour les sessions en monodiffusion, le mécanisme existant basé sur le RTCP SR permet une synchronisation immédiate, à condition que le paquet RTCP initial ne soit pas perdu.
Pour les sessions SSM, le délai de synchronisation initial est suffisant pour la synchronisation labiale, mais peut être plus important que ce qui est souhaité pour certains codecs en couches. La raison pour laquelle on n'envoie pas de paquets RTCP immédiats pour les groupes en multidiffusion est d'éviter l'implosion des requêtes lorsqu'un grand nombre de membres rejoignent simultanément le groupe ("flash crowd"). Ce n'est pas un problème pour les émetteurs SSM, puisqu'il ne peut y avoir au plus qu'un seul émetteur. Il est donc souhaitable de permettre aux émetteurs SSM d'envoyer un RTCP SR immédiat lors de l'adhésion à une session (comme c'est actuellement autorisé pour les sessions en monodiffusion, qui ne souffrent pas non plus du problème d'implosion). Les récepteurs SSM utilisant la rétroaction en monodiffusion ne seraient pas autorisés à envoyer du RTCP immédiat. Pour les sessions ASM, l'implosion des réponses est une préoccupation, aucune modification des règles de temporisation RTCP n'est donc proposée.
Dans tous les cas, il est possible que le paquet RTCP SR initial soit perdu. Dans ce cas, le récepteur ne pourra pas synchroniser le média tant que l'intervalle de rapport ne sera pas écoulé et que le prochain paquet RTCP SR ne sera pas envoyé. Ceci est indésirable. La section 3.2 définit un nouveau message de rétroaction de couche de transport RTP/AVPF pour demander qu'un RTCP SR soit généré, permettant une resynchronisation rapide en cas de perte de paquet.
2.2. Synchronisation pour les nouveaux arrivants tardifs
La synchronisation entre les sessions RTP est potentiellement plus lente pour les arrivants tardifs que pour les participants présents au début de la session. Les raisons en sont de trois ordres :
-
Bon nombre des optimisations qui permettent la transmission rapide des paquets RTCP SR ne s'appliquent qu'au début d'une session. Cela signifie qu'un nouveau participant peut avoir à attendre un intervalle de rapport RTCP complet pour chaque session avant de recevoir les données nécessaires pour synchroniser les flux média. Cela pourrait potentiellement prendre plusieurs secondes, selon la bande passante de la session configurée et le nombre de participants.
-
Un délai de synchronisation supplémentaire provient de la nature des règles de temporisation RTCP. Les paquets sont générés en moyenne une fois par intervalle de rapport, mais avec des temps de transmission exacts randomisés à +/- 50 % pour éviter la synchronisation des rapports. Ceci est important pour éviter la congestion du réseau dans les sessions multidiffusées, mais cela signifie que le cadencement des rapports d'émetteur RTCP pour les différentes sessions RTP n'est pas synchronisé. En conséquence, un récepteur doit estimer le décalage sur l'horloge au format NTP afin d'aligner les horodatages RTP entre les sessions. Cette estimation est une partie essentielle d'une mise en œuvre de la synchronisation RTP et peut être effectuée avec une grande précision si l'on dispose de suffisamment de rapports. Cependant, la collecte de suffisamment de données RTCP SR pour effectuer cette estimation peut nécessiter la réception de plusieurs rapports RTCP, ce qui augmente encore le délai de synchronisation.
-
De nombreux codecs média ont la notion de points d'accès périodiques, de sorte qu'un récepteur nouvellement arrivé ne peut souvent commencer à décoder un flux média que lorsque les paquets correspondant au point d'accès ont été reçus. Ces points d'accès peuvent être envoyés moins souvent que les paquets RTCP SR, et peuvent donc être le facteur limitant pour commencer la lecture de média synchronisée pour les arrivants tardifs. L'extension RTP pour l'acquisition rapide basée sur l'unidiffusion des sessions RTP en multidiffusion [AVT-ACQUISITION-RTP] peut être utilisée pour réduire le temps mis pour recevoir les points d'accès dans certains scénarios.
Ces délais sont probablement un problème pour s'accorder sur une session RTP en multidiffusion en cours, ou pour les MCU à commutation vidéo.