Real-time Transport Control Protocol

Le protocole réseau RTCP (Real-time Transport Control Protocol) repose sur des transmissions périodiques de paquets de contrôle par tous les participants à une session multimédia.

C'est un protocole de contrôle des flux RTP, permettant de véhiculer des informations basiques sur les participants d'une session, et sur la qualité de service.

Le RTCP est un protocole couplé au RTP (Real-time Transport Protocol). Ses fonctionnalités de base et la structure de ses paquets sont définis dans la spécification RFC 3550 RTP, remplaçant sa standardisation originale datant de 1996 (RFC 1889).

RTCP fournit les statistiques de bandes passantes et des informations de contrôle pour un flux RTP. Il est couplé aux paquets RTP, mais ne transporte aucune information relative au média lui-même. Typiquement RTP sera envoyé sur un port UDP (User Datagram Protocol) de numéro pair ; le message RTCP couplé sera envoyé sur le port impair suivant. La fonction principale du RTCP est de fournir des informations sur la qualité de service (QoS) dans la distribution des médias en envoyant périodiquement des informations statistiques aux participants à une session de flux multimédia (audio ou vidéo).

Les statistiques RTCP rassemblent pour une connexion média des informations telles que le nombre d'octet et de paquets transmis, le nombre de paquets perdus, la gigue, et le Round-Trip delay Time. Une application peut utiliser cette information pour contrôler la qualité du service, et par exemple adapter le débit du flux vidéo en utilisant un autre codec.

RTCP lui-même ne fournit pas de méthodes de chiffrement de flux ou d'authentification. Ces mécanismes peuvent être mis en œuvre, par exemple, par le protocole Secure Real-time Transport Protocol (SRTP) défini dans la RFC 3711.

RTCP est encapsulé dans des paquets UDP tout comme RTP.

Fonctions protocole

RTCP offre trois fonctions de base utiles pour mettre en œuvre les sessions RTP :

• La fonction principale du RTCP est de rassembler des statistiques sur les aspects de la qualité de la distribution des médias au cours d'une session et de transmettre ces données à la source et aux autres participants de la session média. Ces informations peuvent être utilisées par la source pour l'encodage adaptatif des médias (codec) et la détection des défauts de transmission. Si la session est transportée sur un réseau Multicast, cela permet une surveillance non-intrusive de la qualité session.
• RTCP fournit un identificateur canonique de point final (CNAME) à tous les participants à la session. Même si un identificateur de source (SSRC) d'un flux RTP devrait être unique, la liaison instantanée des identificateurs de source à des points finaux peut changer au cours d'une session. Le CNAME établit une identification unique des points d'extrémité dans une instance d'application (utilisation multiple des outils de médias) et de surveillance par des tiers.
• Les rapports RTCP devraient être envoyés par tous les participants, même dans une session Multicast impliquant des milliers de destinataires. Ce trafic augmente proportionnellement avec le nombre de participants. Ainsi, pour éviter la congestion du réseau, le protocole doit inclure la gestion de bande passante de la session. Ce résultat est obtenu en contrôlant dynamiquement la fréquence des rapports de transmission. La consommation de bande passante RTCP ne devrait généralement pas dépasser 5 % de la bande passante totale de la session. En outre, 25 % de la bande passante RTCP devrait être réservée aux médias, à tout moment, de sorte que dans les grandes conférences, tout nouveau participant reçoive les identifiants CNAME des expéditeurs sans délai excessif.

Une quatrième, en option, est la mise à disposition des fonctions de contrôle de session, parce que RTCP est un moyen commode pour atteindre tous les participants de la session, alors que lui-même n'est pas RTP. RTP est transmis uniquement par une source de média.

Types de message

Introduction

RTCP distingue plusieurs types de paquets : rapport de l'expéditeur (RS), le rapport du récepteur (RR), la description des sources (SDES), et la fin d'une session (BYE). En outre, le protocole est extensible et permet des applications spécifiques aux paquets RTCP. Une extension basée sur les standards du RTCP est le type de paquet « rapport étendu » présenté par la RFC 3611.

Rapport de l'expéditeur (SR)

Le rapport expéditeur est envoyé périodiquement par les expéditeurs actifs d'une conférence pour présenter les statistiques de transmission et de réception pour tous les paquets RTP envoyés pendant l'intervalle. Le rapport d'un expéditeur inclut un timestamp (horodatage) absolu, qui est le nombre de secondes écoulées depuis minuit le 1^er janvier 1900. L'horodatage absolu permet au récepteur de synchroniser les messages RTP. Il est particulièrement important lorsque les deux flux audio et vidéo sont transmis simultanément, parce que les flux audio et vidéo utilisent chacun leur propre horodatage relatif.

Rapport du receveur (RR)

Le rapport du récepteur est pour les participants passifs, ceux qui n'ont pas envoyé de paquets RTP. Le rapport informe l'expéditeur et les autres récepteurs de la qualité de service.

Description de la source (SDES)

Le message Description Source est utilisé pour envoyer l'élément CNAME de participants à la session. Il peut également être utilisé pour fournir des informations supplémentaires telles que le nom, l'adresse e-mail, numéro de téléphone et l'adresse du propriétaire ou de contrôleur de la source.

Fin de la participation (BYE)

Une source envoie un message BYE pour arrêter un flux. Il permet à un point final d'annoncer qu'il quitte la conférence. Bien que d'autres sources peuvent détecter l'absence d'une source, ce message est une annonce directe. Il est également utile à un mélangeur médias.

Message spécifique à l'application (APP)

Le message spécifique à l'application fournit un mécanisme pour concevoir des extensions spécifiques à l'application du protocole RTCP.

Détails d'un paquet RTCP

Les informations montrées sont issues d'une capture de réseau à l'aide du logiciel d'analyse de paquets Wireshark.

La version du protocole (2 bits)

10.. .... = Version: RFC 1889 Version (2)

Extension du paquet, le nombre indiqué correspond au nombre d'octets supplémentaires ajoutés (1 bit)

..0. .... = Padding: False

Le nombre de blocs de rapports de réception contenus dans ce paquet, avec un maximum de 31 items (5 bits)

...0 0001 = Reception report count: 1

Le type de paquet (1 octet)

Packet type: Sender Report (200)

La taille du paquet (2 octets)

Length: 12 (52 bytes)

L'identifiant de l'envoyeur (4 octets)

Sender SSRC: 0x00001649 (5705)

La partie en seconde du marqueur de temps(4 octets)

Timestamp, MSW: 2208996180 (0x83aa9b54)

La partie en fraction (1/2^32 de secondes) de seconde du marqueur de temps (4 octets)

Timestamp, LSW: 592705486 (0x2353f7ce)

le marqueur de temps RTP (4 octets)

RTP timestamp: 4319120

Nombre de paquets envoyés (4 octets)

Sender's packet count: 13496

Nombre d'octets envoyés (4 octets)

Sender's octet count: 539840

Évolutivité dans les déploiements à grande échelle

Introduction

Dans les applications à grande échelle, comme dans Internet Protocol Television (IPTV), de très longs délais (quelques minutes à quelques heures) entre les rapports RTCP peuvent se produire, en raison du mécanisme RTCP de contrôle de la bande passante requis pour le contrôle de la congestion (voir Fonctions protocole). Les fréquences acceptables sont habituellement de moins d'une minute. Dans ces cas de figure, les rapports de statistiques envoyés par le récepteur risquent de ne pas être appropriés, tandis que leur évaluation par la source médias sera incohérente par rapport à l'état réel de la session.

Agrégation hiérarchique

L'agrégation hiérarchique (également connu sous le nom hiérarchie commentaires RTCP) est une optimisation du modèle de rétroaction RTCP. Son but est de repousser la limite du nombre maximum d'utilisateurs et d'améliorer la mesure de la QoS. Elle est utilisée avec le protocole Source-Specific Multicast, où une seule source est autorisée, comme dans l'IPTV. Un autre type de multicast utilisé pourrait être le protocole Any-Source Multicast, mais il n'est pas approprié pour des applications à grande échelle avec un nombre considérable d'utilisateurs.

En 2007, seuls les systèmes les plus modernes d'IPTV utilisent l'agrégation hiérarchique.