Aller au contenu principal

1. Introduction

1. Introduction

Ce document définit le type de paquet de rapport étendu (XR) pour le protocole de contrôle RTP (RTCP) [9], et définit comment l'utilisation des paquets XR peut être signalée par une application si elle utilise le protocole de description de session (SDP) [4]. Les paquets XR transmettent des informations au-delà de celles déjà contenues dans les blocs de rapport de réception des paquets de rapport d'émetteur (SR) ou de rapport de récepteur (RR) de RTCP. Les informations sont utiles dans tous les profils RTP et ne sont donc pas appropriées dans les extensions spécifiques au profil SR ou RR. Les informations utilisées pour la gestion de réseau entrent dans cette catégorie, par exemple.

La définition est répartie sur les trois sections qui suivent l'introduction. La section 2 définit le paquet XR comme composé d'un en-tête de huit octets suivi d'une série de composants appelés blocs de rapport. La section 3 définit le format commun, ou cadre, composé d'un champ de type et de longueur, requis pour tous les blocs de rapport. La section 4 définit plusieurs types de blocs de rapport spécifiques. D'autres types de blocs peuvent être définis dans de futurs documents selon les besoins.

Les types de blocs de rapport définis dans ce document se répartissent en trois catégories. La première catégorie se compose de rapports paquet par paquet sur les paquets RTP reçus ou perdus. Les rapports de la deuxième catégorie transmettent des informations de temps de référence entre les participants RTP. Dans la troisième catégorie, les rapports transmettent des métriques relatives aux réceptions de paquets, qui sont de nature récapitulative mais plus détaillées, ou d'un type différent, que celles transmises dans les paquets RTCP existants.

Au total, sept formats de blocs de rapport sont définis par ce document. Parmi ceux-ci, trois sont des types de blocs paquet par paquet:

  • Bloc de rapport RLE de perte (section 4.1): Codage de longueur de série des rapports concernant les pertes et les réceptions de paquets RTP.

  • Bloc de rapport RLE de duplication (section 4.2): Codage de longueur de série des rapports concernant les duplications de paquets RTP reçus.

  • Bloc de rapport des temps de réception de paquets (section 4.3): Une liste d'horodatages de réception de paquets RTP.

Il existe deux types de blocs liés au temps de référence:

  • Bloc de rapport de temps de référence du récepteur (section 4.4): Horodatages d'horloge murale côté récepteur. Avec le bloc de rapport DLRR mentionné ci-après, ceux-ci permettent aux non-émetteurs de calculer les temps d'aller-retour.

  • Bloc de rapport DLRR (section 4.5): Le délai depuis la réception du dernier bloc de rapport de temps de référence du récepteur. Un émetteur de données RTP qui reçoit un bloc de rapport de temps de référence du récepteur peut répondre avec un bloc de rapport DLRR, de la même manière que, dans le mécanisme déjà défini pour RTCP [9, section 6.3.1], un récepteur de données RTP qui reçoit l'horodatage NTP d'un émetteur peut répondre en remplissant le champ DLSR d'un bloc de rapport de réception RTCP.

Enfin, ce document définit deux types de blocs de métriques récapitulatives:

  • Bloc de rapport de résumé statistique (section 4.6): Statistiques sur les numéros de séquence de paquets RTP, les pertes, les duplications, la gigue et les valeurs TTL ou de limite de saut.

  • Bloc de rapport de métriques VoIP (section 4.7): Métriques pour la surveillance des appels voix sur IP (VoIP).

Avant de procéder aux définitions des paquets XR et des blocs de rapport, ce document fournit une déclaration d'applicabilité (section 1.1) qui décrit les contextes dans lesquels ces blocs de rapport peuvent être utilisés. Il définit également (section 1.2) l'utilisation normative de mots-clés, tels que MUST et SHOULD, tels qu'ils sont utilisés dans ce document.

Après les définitions des différents blocs de rapport, ce document décrit comment les applications qui utilisent SDP peuvent signaler leur utilisation (section 5). Le document se termine par une discussion (section 6) sur les considérations de numérotation pour l'Internet Assigned Numbers Authority (IANA), sur les considérations de sécurité (section 7), et avec des annexes qui fournissent des exemples de mise en œuvre des algorithmes discutés dans le texte.