1. Introduction

Lors de l'utilisation de RTP pour fournir du contenu multimédia, il est souvent nécessaire de synchroniser la lecture des composants audio et vidéo d'une présentation. Ceci est réalisé en utilisant les informations contenues dans les paquets de rapport d'émetteur (SR) du protocole de contrôle RTP (RTCP) [RFC3550]. Ceux-ci sont envoyés périodiquement, et les composants d'une session multimédia ne peuvent pas être synchronisés tant que suffisamment de paquets RTCP SR n'ont pas été reçus pour chaque flux RTP afin de permettre au récepteur d'établir des correspondances entre l'horloge média utilisée pour chaque flux RTP et l'horloge de référence commune (au format NTP) utilisée pour établir la synchronisation.

Récemment, des inquiétudes ont été exprimées quant au fait que ce délai de synchronisation soit problématique pour certaines applications, par exemple celles utilisant le codage vidéo en couches ou à descriptions multiples. Ce mémorandum examine les opérations de synchronisation RTP et décrit le délai de synchronisation auquel on peut s'attendre. Trois extensions rétrocompatibles au mécanisme de synchronisation RTP de base sont proposées :

• Les règles de temporisation de transmission RTCP sont assouplies pour les expéditeurs de multidiffusion spécifique à la source (SSM), afin de réduire la latence de synchronisation initiale pour les grands groupes SSM. Voir la section 3.1.

• Une amélioration du profil RTP étendu pour la rétroaction basée sur le RTCP (RTP/AVPF) [RFC4585] est définie pour permettre aux récepteurs de demander des paquets RTCP SR supplémentaires, fournissant les métadonnées nécessaires pour synchroniser les flux RTP. Cela peut réduire le délai de synchronisation lors de l'adhésion à des sessions avec de grands intervalles de rapport RTCP, en présence de perte de paquets, ou lorsque des MCU à commutation vidéo sont employées. Voir la section 3.2.

• Deux extensions d'en-tête RTP sont définies, pour fournir des métadonnées de synchronisation en bande avec les paquets de données RTP. Ces extensions fournissent des métadonnées de synchronisation alignées avec les paquets de données RTP, et éliminent ainsi le besoin d'estimer le décalage d'horloge (clock skew) entre les flux avant la synchronisation. Elles peuvent également réduire le besoin de recevoir des paquets RTCP SR avant que les flux ne puissent être synchronisés, bien qu'elles n'éliminent pas le besoin de RTCP. Voir la section 3.3.

Le cas d'utilisation immédiat de ces extensions est de réduire le délai dû à la synchronisation lors de l'adhésion à une session vidéo en couches (par exemple, une session H.264/SVC (Scalable Video Coding) en mode Non-Interleaved Timestamp-based (NI-T) [AVT-RTP-SVC]). Les extensions ne sont toutefois pas spécifiques au codage en couches et peuvent être utilisées dans tout environnement où la latence de synchronisation est un problème.

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la RFC 2119 [RFC2119].

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]) ont des performances de synchronisation similaires à celles des groupes ASM (Topo-ASM), puisque le traducteur forme effectivement un groupe ASM.