Aller au contenu principal

3. Réduction des délais de synchronisation RTP

Trois extensions RTP rétrocompatibles sont définies pour réduire le délai de synchronisation possible : un intervalle RTCP initial réduit pour les émetteurs SSM, un message de demande de resynchronisation rapide et des extensions d'en-tête RTP pouvant transporter des métadonnées de synchronisation en bande.

3.1. Intervalle RTCP initial réduit pour les émetteurs SSM​

Dans les sessions SSM où le délai de synchronisation initiale est important, l'émetteur RTP PEUT fixer le délai avant l'envoi du paquet RTCP composé initial à zéro, et envoyer son premier paquet RTCP immédiatement après avoir rejoint la session SSM. Il s'agit d'une modification purement locale à l'émetteur qui peut être mise en œuvre en tant qu'option configurable. Les récepteurs RTP dans une session SSM, envoyant une rétroaction RTCP en monodiffusion, NE DOIVENT PAS envoyer de paquets RTCP avec un délai initial nul ; les règles de temporisation définies dans la [RFC5760] s'appliquent sans changement aux récepteurs.

3.2. Demande de resynchronisation rapide​

Le format général d'un message de rétroaction de couche de transport RTP/AVPF est présenté dans la figure 4 (voir la [RFC4585] pour plus de détails).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|   FMT   | PT=RTPFB=205  |           longueur            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC de l'émetteur du paquet                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC de la source média                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :            Informations de contrôle de rétroaction (FCI)      :
     :                                                               :

             Figure 4 : Message de rétroaction de couche de transport RTP/AVPF

Un nouveau type de message de rétroaction, RTCP-SR-REQ, est défini avec FMT = 5. La partie Informations de contrôle de rétroaction (FCI) du message de rétroaction DOIT être vide. L'SSRC de l'émetteur du paquet indique le membre qui est incapable de synchroniser les flux média, tandis que l'SSRC de la source média indique l'émetteur du média qu'il est incapable de synchroniser. La longueur DOIT être égale à 2.

Si le profil RTP/AVPF [RFC4585] est utilisé, ce message de rétroaction PEUT être envoyé par un récepteur pour indiquer qu'il est incapable de synchroniser certains flux média, et qu'il souhaite que la source média transmette un paquet RTCP SR dès que possible (dans les limites des règles de temporisation RTCP pour le feedback anticipé). Lorsqu'elle reçoit une telle indication, une source média qui comprend le paquet RTCP-SR-REQ DEVRAIT générer un paquet RTCP SR dès que possible tout en respectant les règles de feedback anticipé RTCP. Si l'utilisation de RTCP non composé [RFC5506] a été préalablement négociée, la demande de rétroaction et la réponse RTCP SR peuvent être envoyées sous forme de paquets RTCP non composés. Le paquet RTCP-SR-REQ PEUT être répété une fois par intervalle de rapport RTCP si aucun paquet RTCP SR ne parvient. La source média peut ignorer les paquets RTCP-SR-REQ si son calendrier habituel de transmission des métadonnées de synchronisation peut raisonnablement permettre au récepteur de synchroniser les flux média dans un délai raisonnable.

Lors de l'utilisation de sessions SSM avec rétroaction en monodiffusion, il est possible que la cible de rétroaction et la source média ne soient pas situées au même endroit. Si une cible de rétroaction reçoit un message de rétroaction RTCP-SR-REQ dans un tel cas, la demande doit être transmise à la source média. Le mécanisme à utiliser pour transmettre ces demandes n'est pas défini ici.

Si la cible de rétroaction fournit une interface de gestion de réseau, il pourrait être utile de fournir un journal des récepteurs qui envoient des paquets de rétroaction RTCP-SR-REQ et de ceux qui n'en envoient pas, puisque ceux qui n'en envoient pas verront une synchronisation de flux plus lente.

3.3. Livraison en bande des métadonnées de synchronisation​

Le mécanisme d'extension d'en-tête RTP défini dans la [RFC5285] peut être adapté pour transporter un horodatage OPTIONNEL au format NTP dans les paquets de données RTP. Si un tel horodatage est inclus, il DOIT correspondre au même instant temporel que l'horodatage RTP dans l'en-tête du paquet, et DOIT être dérivé de la même horloge utilisée pour générer les horodatages au format NTP inclus dans les paquets RTCP SR. À condition de connaître la correspondance SSRC vers CNAME, soit par la réception préalable d'un paquet RTCP CNAME, soit par signalisation hors bande [RFC5576], le récepteur peut utiliser les informations fournies comme entrée de l'algorithme de synchronisation, exactement de la même manière que si un paquet RTCP SR supplémentaire avait été reçu pour le flux.

Deux variantes sont définies pour cette extension d'en-tête. La première variante étend l'en-tête RTP avec un horodatage au format NTP de 64 bits tel que défini dans la [RFC5905]. La deuxième variante transporte la partie inférieure des Seconds sur 24 bits d'un horodatage au format NTP et les 32 bits de la Fraction d'un horodatage au format NTP. Les formats des deux variantes sont présentés dans la figure 5 et la figure 6.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |       numéro de séquence      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                          horodatage                           |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |            identifiant de source de synchronisation (SSRC)    |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |           longueur=3          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-A  | L=7   |  Format d'horodatage NTP - Secondes (bit 0-23)|x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |NTP Sec.(24-31)|  Format d'horodatage NTP - Fraction (bit 0-23)|e
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
     |NTP Frc.(24-31)|    0 (pad)    |    0 (pad)    |    0 (pad)    |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         données de charge                     |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 5 : Variante A / Extension d'en-tête RTP NTP 64 bits
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |       numéro de séquence      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                          horodatage                           |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |            identifiant de source de synchronisation (SSRC)    |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |           longueur=2          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-B  | L=6   |  Format d'horodatage NTP - Secondes (bit 8-31)|x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |           Format d'horodatage NTP - Fraction (bit 0-31)       |e
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         données de charge                     |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 6 : Variante B / Extension d'en-tête RTP NTP 56 bits

Un horodatage au format NTP PEUT être inclus dans n'importe quel paquet RTP choisi par l'émetteur, mais il est RECOMMANDÉ lors de l'exécution d'une récupération de l'ordre de décodage basée sur l'horodatage pour les codecs en couches transportés dans plusieurs flux RTP, comme spécifié plus en détail dans la section 4.1. Cette extension d'en-tête DEVRAIT également être envoyée dans les paquets RTP correspondant à un point d'accès aléatoire vidéo, et dans les paquets audio associés, pour permettre une synchronisation rapide pour les nouveaux arrivants tardifs dans les sessions multimédias et dans les scénarios de commutation vidéo.

Remarque : L'inclusion d'une extension d'en-tête RTP réduira l'efficacité de la compression d'en-tête RTP, si elle est utilisée. De plus, les boîtiers intermédiaires qui ne comprennent pas les extensions d'en-tête peuvent les supprimer ou ne pas mettre à jour le contenu selon ce mémorandum.

Dans tous les cas, que des horodatages au format NTP en bande soient inclus ou non, des paquets RTCP SR réguliers DOIVENT être envoyés pour assurer la rétrocompatibilité avec les récepteurs qui synchronisent les flux RTP selon la [RFC3550], et la robustesse face aux boîtiers intermédiaires (traducteurs RTP) qui pourraient supprimer les extensions d'en-tête RTP. Si la variante B / extension d'en-tête RTP NTP 56 bits est utilisée, les rapports d'émetteur RTCP DOIVENT être utilisés pour dériver les 8 bits supérieurs des Secondes pour l'horodatage au format NTP.

Lorsque le SDP est utilisé, l'utilisation des extensions d'en-tête RTP définies ci-dessus DOIT être indiquée comme spécifié dans la [RFC5285]. Par conséquent, les URI suivants DOIVENT être utilisés :

  • L'URI utilisé pour signaler l'utilisation de la variante A / extension d'en-tête RTP NTP 64 bits dans le SDP est "urn:ietf:params:rtp-hdrext:ntp-64".

  • L'URI utilisé pour signaler l'utilisation de la variante B / extension d'en-tête RTP NTP 56 bits dans le SDP est "urn:ietf:params:rtp-hdrext:ntp-56".

L'utilisation de ces extensions d'en-tête RTP peut grandement améliorer l'expérience utilisateur dans le surf sur les chaînes IPTV et dans certains scénarios de visioconférence interactive. Les outils de gestion de réseau qui tentent de surveiller l'expérience utilisateur peuvent souhaiter consigner quelles sessions signalent et utilisent ces extensions.

Dernière mise à jour le