- Real-time Transport Control Protocol
-
Pile de protocoles 7. Application 6. Présentation 5. Session 4. Transport 3. Réseau 2. Liaison 1. Physique Modèle Internet
Modèle OSILe protocole réseau RTCP (Real-time Transport Control Protocol) repose sur des transmissions périodiques de paquets de contrôle par tous les participants dans la session.
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 (Real-time Transport Protocol) (RTP). Ses fonctionnalités de base et sa structure des 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 pas de n'importe quel 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 pour les 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, pour en limiter la circulation en utilisant un autre codec.
RTCP lui-même ne fournit pas toutes les méthodes de chiffrement de flux ou d'authentification. Ces mécanismes peuvent être mis en œuvre, par exemple, avec le Secure Real-time Transport Protocol (SRTP) défini dans la RFC 3711.
RTCP est encapsulé dans un paquet UDP tout comme RTP.
Sommaire
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 l'au revoir (BYE). En outre, le protocole est extensible et permet des applications spécifiques des 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ée périodiquement par les expéditeurs active à une conférence pour présenter des statistiques de transmission et de réception pour tous les paquets RTP envoyés pendant l'intervalle. Le rapport comprend un émetteur timestamp absolu, qui est le nombre de secondes écoulées depuis minuit le 1 Janvier 1900. L'horodatage absolue permet au récepteur de synchroniser les messages RTP. Il est particulièrement important lorsque les deux audio et vidéo sont transmis simultanément, parce flux audio et vidéo usage indépendant horodatages relatifs.
- Rapport du receveur (RR)
- Le rapport 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 (TSRA)
- 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 de 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 blocks de rapport de reception contenue 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
La mesure du RTT
É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.
Description {{{Description}}}
Source Veuillez indiquer une source.
Date Auteur {{{Auteur}}}
Permission {{{Permission}}}
Wikimedia Foundation. 2010.
