Réseaux Multimédia et Qualité de Service M2 RISE 2011-2012 JJ Pansiot 2011 RMMQoS-chap1 1 Références Analyse structurée des réseaux, Jim Kurose, Keith Ross Pearson Education (en particulier chapitre 6 Les réseaux et le multimédia). Réseaux, 4ème édition, Andrew S. Tanenbaum, Pearson Education, (en particulier chapitre 7.4 Multimédia). An Engineering Approach to Computer Networking, S. Keshav, Addison Wesley, (en particulier chapitres 8 switching et 9 scheduling). 2011 RMMQoS-chap1 2 Objectifs Applications multimédia caractéristiques des flux multimédia Protocoles de bout en bout signalisation multimédia Dans le réseau mécanismes de commutation et ordonnancement = > QoS (Quality of Service = QdS ) architectures de QoS Application et signalisation multimédia (en particulier VoIP) : Emil Ivov Mécanismes et architectures pour la QoS : JJP 2011 RMMQoS-chap1 3 1
Remarque préliminaire Média : texte, image fixe, son, vidéo, Multimédia présence de plusieurs média texte et image. problèmes de codage, synchronisation, ce qui va nous intéresser média continus (audio, vidéo) interaction avec le réseau 2011 RMMQoS-chap1 4 Multimédia, Qualité de Service? Applications multimédia : flux continus audio/ vidéo à travers le réseau QoS Le réseau fournit aux applications le niveau de performance nécessaire à leur bon fonctionnement 2011 RMMQoS-chap1 5 Applications Multimédia Classes d applications MM 1) Streaming audio et/ou video préenregistrés 2) Streaming audio et/ou video en direct ( live ) 3) Applications audio et/ou video interactives temps-réel Principales caractéristiques: sensibles aux délais délai de bout en bout variation de délai : gigue (jitter) Tolérants aux pertes redondance de l information, adaptation récepteur Inverse des applications informatiques classiques : peu sensibles aux délais sensibles aux pertes 2011 RMMQoS-chap1 6 2
Données cumulées Streaming de média enregistrés Streaming media stocké à la source (ex VoD) transmis au client streaming: le client commence à jouer (restituer) avant que toutes les données soient arrivées pas de stockage en réception contrainte temporelle : les données doivent arriver à temps pour être jouées (playout) de façon continue Note : Si on attend le flux complet <=> transfert de fichier 2011 RMMQoS-chap1 7 Streaming de média enregistrés 1. video enregistrée 2. video émise délai réseau 3. video reçue et jouée par le client temps streaming : à cet instant le client joue alors que le serveur émet 2011 RMMQoS-chap1 8 Streaming de média enregistrés : Interactivité Fonctionnalité magnétoscope : le client peut faire pause, rembobiner, FF, etc 10 sec délai initial OK 1-2 sec avant effet commande OK Protocole RTSP souvent utilisé contrainte : les données doivent arriver à temps pour le playout 2011 RMMQoS-chap1 9 3
Streaming de média en direct Exemples radio sur internet télé sur Internet Streaming buffer de réception (playback, playout buffer) délai de playback peut être > 10s Interactivité pas de FF ( publicités :-(( pause, rembobiner possibles (buffer cyclique) 2011 RMMQoS-chap1 10 Streaming de média en direct En général 1 vers N difficulté à étendre duplication dans le réseau => multicast IP, routage multicast multicast applicatif hiérarchie de serveurs de contenu» délais 2011 RMMQoS-chap1 11 Multimedia interactif temps réel applications: téléphonie sur IP, vidéo conférence, applications distribuées interactives (jeu, ) contraintes délais de bout en bout: audio: < 150 msec bon, < 400 msec acceptable délai total : application (paquetisation, compression) et délai réseau délai supérieur empêche interactivité (cf satellite) 2011 RMMQoS-chap1 12 4
Multimedia interactif temps réel initialisation de session comment l appelé annonce son adresse/port, codage? - voir protocoles SIP, H323 2011 RMMQoS-chap1 13 Multimédia sur Internet basique TCP/UDP/IP: service best effort pas de garantie sur les délais (TCP,UDP), ni sur les pertes (UDP) avec TCP : correction de pertes => retransmission => augmente les délais et la gigue Actuellement les applications multimédia utilisent des techniques de niveau applicatif codage redondant, playback buffer, réseaux de distribution de contenu CDN Content Delivery Networks comme Akamai ou Pair à Pair pour cacher les limitations d internet 2011 RMMQoS-chap1 14 Solutions possibles pour le support du MM Architecture à intégration de service (IntServ) Changements dans internet pour que les applications puissent réserver de la Bande Passante (BP) de bout en bout (principes analogues à ATM) Nécessite des nouveaux logiciels complexes dans le réseau et les clients Architecture à différenciation de service (DiffServ) Moins de changement que IntServ, classe de service améliorée pour le MM Pas de changement du réseau pas de changement interne Surdimensionnement BP «overprovisionning» CDN, PàP, multicast applicatif 2011 RMMQoS-chap1 15 5
Audio 2011 RMMQoS-chap1 16 Compression audio basique Signal analogique échantillonné à intervalle constant téléphone classique : 8000 éch/sec CD audio : 44100 éch/sec chaque échantillon quantifié (arrondi) ex 2 8 =256 valeurs possibles chaque échantillon codé 256 valeurs => 8 bits Exemple du téléphone 8000 éch/sec, 256 valeurs =-> 64000 bps Le récepteur retransforme en signal analogique ( interpolation ) perte de qualité Exemples de débits CD: 1.411 Mbps MP3: 96, 128, 160 kbps téléphonie sur IP : 5,3 à 13 kbps 2011 RMMQoS-chap1 17 Exemple (a) signal (b) échantillonnage. (c) quantification sur 4 bits 2011 RMMQoS-chap1 18 6
Compression audio et l oreille (a) seuil d audibilité/fréquence ~ bande passante oreille (b) effet de masquage 2011 RMMQoS-chap1 19 Compression audio en pratique échantillonnage/compression par sous bande (par exemple 32 en Mpeg) quantification dépend de la sous-bande n envoyer que ce qui est audible 2011 RMMQoS-chap1 20 Paquetisation et Streaming Audio technique de l interleaving la perte d un paquet diminue le fréquence des paquets mais pas de trou silence (mais délai) 2011 RMMQoS-chap1 21 7
Streaming Audio Le logiciel client média player met les données dans un buffer, et les joue ensuite 2011 RMMQoS-chap1 22 Exemple téléphonie sur IP alternance périodes actives (parole) et silencieuses p.e. 64 kbps pendant activité paquets générés seulement pendant activité morceaux de 20 msec à 8 Ko/sec: 160 octets la couche appli ajoute un entête à chaque morceau puis encapsulé dans un datagramme UDP => un paquet UDP toutes les 20 ms (160+entêtes ) octets 2011 RMMQoS-chap1 23 Influence du réseau (audio interactive) pertes : un paquet IP peut se perdre (congestion réseau) pertes dues au délai un paquet arrivé trop tard est ignoré (p.e. paquet suivant déjà joué) délais : traitements et files d attentes dans le réseau délais de traitement aux extrémités (compression ) délai maximum tolérable environ: 400 ms tolérance aux pertes: dépend du codage, les pertes peuvent être cachées de 1% à 10% peut être toléré 2011 RMMQoS-chap1 24 8
données cumulées Gigue transmission à débit constant délai réseau variable (gigue) réception au client données bufferisées joué à un débit constant délai de playout temps délai de réception entre deux paquets > 20 ms ou < 20 ms remplissage variable du buffer 2011 RMMQoS-chap1 25 Délai fixe de playout Le récepteur essaie de jouer chaque morceau exactement d ms après sa génération le morceau a une estampille t (cf RTP) jouer morceau à t+d. si morceau arrive après t+d morceau ignoré Compromis grand d : moins de pertes de paquet petit d : meilleure interactivité 2011 RMMQoS-chap1 26 Délai de playout adaptatif Objectif : minimiser le délai de playout DP tout en gardant un taux de paquets hors délai faible Idée : ajuster dynamiquement le délai de playout Estimer le délai réseau et ajuster le DP au début de chaque période d activité Les périodes de silence sont allongées ou raccourcies suivant que DP augmente ou diminue Les morceaux sont toujours joués tous les 20 ms pendant activité estimation DP : moyenne glissante : nouveau_dp= (1-u)*ancien_DP + u*délai_dernier_paquet où u est un petit nombre p.e. 0,1 (contrôle la réactivité) cf estimation RTT dans TCP 2011 RMMQoS-chap1 27 9
DP adaptatif suite On peut aussi raffiner en estimant la variation de délai (gigue) nouvelle_gigue = (1-u) * ancienne_gigue + u * délai_paquet - DP le premier paquet d une période d activité est joué avec un délai DP + K * nouvelle_gigue où K est un paramètre fixe Les paquets suivants de la même période d activité sont joués à intervalle constant 2011 RMMQoS-chap1 28 DP adaptatif suite Comment déterminer le début d une période d activité en l absence de pertes différence des estampilles > 20 msec => nouvelle période avec pertes : regarder estampilles et numéros de séquence différence des estampilles > 20 msec et séquence sans trou => nouvelle période. 2011 RMMQoS-chap1 29 Traitement des pertes Utilisation de ARQ (exemple TCP) => ajoute au moins un RTT inutilisable en interactif Codes correcteurs (FEC): codes simples pour corriger les pertes ( erreurs) exemple codes Reed-Solomon pour chaque groupe de n paquets créer un paquet de redondance exemple OU exclusif des n paquets envoyer n+1 paquets, on peut reconstruire les n paquets si au plus un seul paquet perdu inconvénient : débit utilisé augmenté de 1/n délai augmenté (groupe de n+1) au décodage peut être généralisé à k redondance pour n info 2011 RMMQoS-chap1 30 10
Traitement des pertes (2) DP doit être augmenté pour traiter un groupe de n+1 paquets Compromis augmenter n, moins de BP gaspillée augmenter n, DP + grand -interactif augmenter n, plus grande probabilité de perte d au moins deux paquets 2011 RMMQoS-chap1 31 Traitement des pertes (3) Autre idée : 2 codages de qualités (et volume) différentes le n-ième paquet contient le n-ième morceau haute qualité morceau précédent en basse qualité (redondance) en réception si (n-1)-ième paquet perdu, remplacer par basse qualité paquet suivant perte devient baisse de qualité DP augmenté d un intervalle (ie 20 ms) coût en BP dépend du rapport entre les deux qualités Idée généralisée dans le codage en couche n qualités en couches complémentaires récepteur adapte nombre de couches à la BP 2011 RMMQoS-chap1 32 Traitement des pertes (4) Entrelaçage (interleaving) morceaux découpés en n sous-morceaux n sous-morceaux distribués dans n paquets consécutifs un paquet perdu => n morceaux altérés légèrement pas de BP supplémentaire augmente le DP traitement par groupe de n paquets au codage ET au décodage 2011 RMMQoS-chap1 33 11
Média Vidéo 2011 RMMQoS-chap1 34 Video analogique Format de balayage NTSC. 2011 RMMQoS-chap1 35 Codage vidéo une image de 1024 x 1024 pixels 24 bits par pixel => 3 Mo /image 25 images par seconde => 75 Mo/s = 600 Mb/s Nécessité de compresser fortement le signal redondance spatiale (plages uniformes) redondance temporelle (images successives) limitations de l oeil 2011 RMMQoS-chap1 36 12
Codage JPEG : vue générale préparation DCT Quantification Quantification encodage RLE des blocs différentielle statistique JPEG en mode avec pertes DCT = Transformée Cosinus Discrete RLE : Run Length Encoding AAAAAA => 6A Encodage statistique (ou entropique) Huffmann blocs plus fréquents ont un code plus court 2011 RMMQoS-chap1 37 Codage JPEG (décomposition en blocs) (a) entrée RGB 24 bits/pixel. (b) découpage en YIQ (NTSC) ou YUV ou Y Cr Cb. Luminance, chrominance, saturation 2011 RMMQoS-chap1 38 Codage JPEG : DCT (a) (b) (a) Un bloc de la matrice Y (ou U, V) (b) les coefficients DCT 2011 RMMQoS-chap1 39 13
Codage JPEG : quantification Quantification des coefficients obtenus après la DCT les coeff en haut à gauche (les + importants) sont moins arrondis Un coefficient de 2 i élimine les i bits de poids faible (et arrondi) 2011 RMMQoS-chap1 40 Codage JPEG : sérialisation et RLE Ordre de parcours en zig-zag des coefficients => sérialisation. Suite de 0 : RLE 2011 RMMQoS-chap1 41 Codage MPEG Synchronisation des flux audio et vidéo dans MPEG-1. 2011 RMMQoS-chap1 42 14
MPEG : redondance temporelle 3 images consécutives peu de changements entre images successives idées codage différentiel / image précédente (exemple fond) codage mouvement d un bloc 2011 RMMQoS-chap1 43 Mémoire image Pre processing Input Image prédite Codeur MPEG + - DCT compensation mouvement Régulateur débit Quantificateur (Q) Q -1 IDCT + mémoire image Vecteur mouvement Encodeur longueur variable Buffer Output Estimation 2011 RMMQoS-chap1 mouvement 44 Types de trames mpeg trame I (intra) compressée en utilisant cette trame uniquement compression modérée mais décodage facile trame P (predicted) Codée avec compensation de mouvement ( I ou P précédente) meilleure compression trame B (bidirectional) Codée avec compensation de mouvement (I ou P précédente ou suivante) entraîne des délais et un ré ordonnancement compression supplémentaire 2011 RMMQoS-chap1 45 15
exemple de GOP (Group of Picture) Remarque : on doit envoyer régulièrement des images I un récepteur peut arriver en cours de flux en cas de pertes de trames => compromis débit/fiabilité 2011 RMMQoS-chap1 46 Couches mpeg Hiérarchie d informations en couches (et donc entêtes) : couche Sequence : taille image, fréquence image, table de quantification, couche GOP (Group of Picture) : en général au moins une trame I couche image : estampillage, type d image (I,P,B), résolution, vecteurs de mouvements, couche Slices (tranche): position de la tranche, quantification codage tranche indépendant des autres : confinement d erreur couche Macrobloc (16 x 16) : position, vecteur de mouvements, quels blocs sont codés 2011 RMMQoS-chap1 47 codages et débits vidéo MPEG 1 : Qualité CD vidéo (1,5 Mbit/s) MPEG 2 : Qualité DVD (3 à 6 Mbit/s voir plus HDTV) TNT gratuite MPEG 4 (5 Kb/s à 4 Mb/s) /DivX TNT HD, HDTV, télé mobiles H261 (norme UIT-T) adaptée à la visioconférence et visiophonie (bas débit) techniques similaires à MPEG DCT, quantification, compensation mouvement, format CIF (360 x 288) 30 trames/s et QCIF (180 x 144) 2011 RMMQoS-chap1 48 16
Architecture distribution VoD 2011 RMMQoS-chap1 49 Serveurs VoD Hiérarchie de stockage Volume/rapidité. 2011 RMMQoS-chap1 50 Architecture Serveur VoD 2011 RMMQoS-chap1 51 17
Caractéristiques des flux multimédia contraintes de gigue playback buffer et de délai si interactif limite sur le buffer débits élevés (vidéo HD) débits variables (ex MPEG) tolérance aux pertes persistance rétinienne, rafraîchissement importance variable des données (images I, P, B de MPEG) diffusion (usage du multicast) 2011 RMMQoS-chap1 52 Multimédia et réseau Plusieurs mécanismes et protocoles Aux extrémités codage (compression, paquetisation, ) MPEG, H261, transport de bout en bout RTP/UDP contrôle du transport RTCP gestion des utilisateurs, sessions, flux SIP, H323, RTSP 2011 RMMQoS-chap1 53 MM et réseau Dans le réseau mécanismes de QoS (files, priorités, ) dans les routeurs/switchs gestion globale Intserv (intégration de services) réservation de ressources (RSVP) depuis extrémités Par flux Diffserv (services différenciés) marquage des paquets politique de QoS par classe 2011 RMMQoS-chap1 54 18
Noyau Application Multimédia : protocoles signalisation Qualité de service Transport média H. 323 SIP RTSP RSVP RTCP Media (H. 261, MPEG) RTP TCP UDP IPv4, IPv6 PPP ATM Ethernet 2011 RMMQoS-chap1 55 RTP/RTCP Paire de protocoles de l ietf groupe AVT Audio Video Transport RFC 1889 (1996) RTP : Real Time Protocol transporte les données RTCP: Real Time Control Protocol mécanismes de contrôle émetteurs et récepteurs Nouvelle version RFC 3550 (2003) 2011 RMMQoS-chap1 56 émetteur envoie RTP et RTCP reçoit RTCP récepteur reçoit RTP et RTCP envoie RTCP possibilité plusieurs récepteurs multicast Architecture 2011 RMMQoS-chap1 57 19
Multicast IP adresses de groupe 224.0.0.0/4 un paquet envoyé à cette adresse dupliqué dans le réseau reçu par tous les récepteurs nécessite routage multicast dans le réseau extensibilité en nombre de récepteurs 2011 RMMQoS-chap1 58 Architecture (suite) RTP/RTCP + UDP = fonctions de 3 couches OSI : transport + session + présentation RTP/RTCP peut fonctionner au dessus de protocoles de UDP (en théorie) RTP/RTCP fonctions dans l application (ex: JMF) Les messages RTP/RTCP ne sont pas interprétés par le réseau => pas d influence sur la QoS réseau permettent aux applis de s adapter modèle ALF : Application Level Framing 2011 RMMQoS-chap1 59 RTP : Vue générale Fonctionne au dessus d UDP (en général) Utilise l unicast ou le multicast Les données applicatives sont encapsulées dans des paquets RTP Protocole simple : Permet de déterminer la base de temps des différents flux estampilles Permet de détecter les pertes de paquets numérotation Identifier le contenu des paquets (MPEG audio, JPEG animé, etc.) payload type 2011 RMMQoS-chap1 60 20
Entête RTP 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 X CC M PT sequence number! timestamp! synchronization source (SSRC) identifier! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+!! CC : Nombre de CSRC qui suivent l entête RTP fixe P : padding présent X : extension d entête présente CSRC : contributing SRC (utilisé par mixer) PT : Identifie le format des données contenues dans le paquet RTP. Il existe un profil prédéfini pour assurer la correspondance entre le type de données et leur format (RFC 3551) SN : Incrémenté de 1 pour chaque paquet RTP émis. Valeur initiale aléatoire TS : Instant d'échantillonnage du 1er octet du paquet de données (gestion de la synchronisation et de la gigue). Valeur initiale aléatoire SSRC : Identifiant de la source d'émission des paquets synchronisés! 2011 RMMQoS-chap1 61 RTP : Exemples de profils (PT) audio/video 0 à 23 audio Type de profil Format audio Taux d'échantillonnage 0 MIC/PCMU Codage voix Débit 8 khz 64 kbit/sec 3 GSM 8 khz 4,8 kbit/s 9 G.722 16 khz 48 à 64 kbit/s 14 MPEG Audio 90 khz -- 15 G. 728 8 khz 16 kbit/s 24- vidéo ou combiné Type de profil Format vidéo 26 JPEG animé 31 H.261 32 MPEG 1 vidéo 33 MPEG 2 vidéo 2011 RMMQoS-chap1 62 RTP Le SSRC identifie la source d un flux adresse IP plusieurs flux => plusieurs SSRC correspondance établie en début de session RTCP (message SDES) le TS dépend fréquence d échantillonnage ex : audio à 8 KHz vidéo à 90 KHz 2011 RMMQoS-chap1 63 21
RTP : exemple audio audio échantillons 8 bits / 125 µs émetteur initialement TS et NS aléatoires (sécurité) répéter: noter timestamp premier échantillon TS accumule échantillons jusqu à max (ex : 160 = 20 ms) ou silence envoyer paquet RTP avec TS, NS NS := NS + 1 et recommencer 2011 RMMQoS-chap1 64 RTCP : RTP Control Protocol Protocole fonctionnant avec RTP optionnel Pour chaque flux RTP reçu, chaque récepteur génère un rapport de réception RTCP cyclique Pour chaque flux RTP émis, la source génère un rapport RTCP cyclique Permet de garder une trace de tous les participants à une session RTP Contrôler le débit auquel les participants transmettent leurs données RTP Permet à une source de changer de politique (codecs, etc ) contrôler le contrôle RTCP 2011 RMMQoS-chap1 65 RTCP : types de paquets SR : Sender Report = Rapport des émetteurs Statistiques d émission/réception RR : Receiver Report = Rapport des récepteurs Statistiques de réception BYE : Départ explicite SDES : Description de la source (CNAME, Email, etc.) APP: Extensions spécifiques à l application 2011 RMMQoS-chap1 66 22
RTCP (suite) Paquet RTCP Partie fixe similaire à l entête RTP Plusieurs paquets RTCP peuvent être concaténés p.e. combiner SR et RR => paquet composé (dans un paquet UDP) remarque : ports UDP port UDP pour un flux RTP choisi dynamiquement, en général pair (ex : 10000) port UDP pour signalisation RTCP en général RTP + 1 (ex : 10001) port doit être découvert au départ (voir SDP, SIP, ) => pas décodé automatiquement par wireshark/tcpdump 2011 RMMQoS-chap1 67 RTCP : Format message Sender Report SR 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 RC PT=SR=200 length header! SSRC of sender! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! NTP timestamp, most significant word sender! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info! NTP timestamp, least significant word! RTP timestamp! sender's packet count! sender's octet count! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! à suivre! 2011 RMMQoS-chap1 68 SR (suite) +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! SSRC_1 (SSRC of first source) report! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block! fraction lost cumulative number of packets lost 1! -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! extended highest sequence number received! interarrival jitter! last SR (LSR)! delay since last SR (DLSR)! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! SSRC_2 (SSRC of second source) report! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block! :... : 2! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! profile-specific extensions! 2011 RMMQoS-chap1 69 23
SR (suite) contient RC : Receiver Report count (# RR dans la paquet) Le SSRC du flux RTP La référence de temps quand le rapport a été émis (NTP timestamp) NTP Network Time Protocol (RFC 1305) le timestamp RTP Le nombre de paquets envoyés Le nombre d octets envoyés un rapport pour chaque source reçue (similaire RR) 2011 RMMQoS-chap1 70 RTCP : Format message (RR) 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 RC PT=RR=201 length header! SSRC of packet sender! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! SSRC_1 (SSRC of first source) report! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block! fraction lost cumulative number of packets lost 1! extended highest sequence number received! interarrival jitter! last SR (LSR)! delay since last SR (DLSR)! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! SSRC_2 (SSRC of second source) report! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block! :... : 2! +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+! profile-specific extensions! 2011 RMMQoS-chap1 71 RTCP : Format message (RR) Pour chaque flux RTP reçu Le SSRC du flux RTP La proportion de paquets perdus (obtenue en divisant le nombre de paquets perdus par le nombre de paquets envoyés au sein d un même flux RTP) -> peut déclencher un changement de codage de l émetteur. Le dernier numéro de séquence du flux RTP La gigue à la réception Dernier SR reçu (en temps : NTP timestamp arrondi) Délai passé depuis le dernier SR reçu 2011 RMMQoS-chap1 72 24
RTCP : message SDES Pour chaque flux (SSRC) émis fournit des informations seul info obligatoire CNAME chaîne ASCII a priori de la forme user@host CNAME stable entre flux différents changements d IP, de SSRC autres champs possibles : Email, Phone, 2011 RMMQoS-chap1 73 Intérêt des différents rapports Peuvent servir à la synchronisation des différents flux de données d une session RTP NTP timestamp Permet par exemple de synchroniser une bande audio avec une bande vidéo envoyés dans 2 flux RTP distincts par une source les timestamp RTP ne sont pas synchronisés entre eux Permet également d avoir des informations d identification des participants combien de récepteurs (s il y en a :-)) 2011 RMMQoS-chap1 74 RTP et QoS Une source peut adapter son émission Les sources reçoivent les RR Si pertes ou gigue trop importante possibilité de changer le PT un network manager peut exécuter un moniteur écoute les rapports RTCP 2011 RMMQoS-chap1 75 25
RTCP et multicast Extensibilité (passage au facteur d échelle) Le trafic RTCP ne doit pas représenter plus de 5% du total de la bande passante de la session Au moins 25% du trafic RTCP est utilisé pour les rapports de l émetteur problème important pour de grandes sessions ex 10 000 récepteurs d une vidéoconférence si chaque récepteur envoie RR tous les 100 paquets data => 100 fois plus de paquets RR que de data Comment limiter le débit global RTCP? 2011 RMMQoS-chap1 76 RTCP et multicast (suite) calculer somme débit moyen sources RTCP SR => D calculer nombre de récepteurs RTCP RR => #R calculer taille moyenne RR L dépend # sources fréquence rapports RR < 0,05 * D /(#R *L) Que se passe-t-il si #R augmente brusquement? => améliorations dans RFC 3550 2011 RMMQoS-chap1 77 RTP : Mixers et Translator 2 services RTP Translator : Envoie les flux de différentes sources séparément (transmet les paquets avec le SSRC intact : identification de la source initiale) Invisible par les récepteurs Permet le transcodage de flux (ex : limiter débit) Emetteur 1 Translator 1 Récepteur Translator 2 De E1 : SSRC =12 E1: SSRC =12 De E1 : SSRC =12 E2 : SSRC =3 De E2 : SSRC =3 De E2 : SSRC =3 2011 RMMQoS-chap1 78 Emetteur 2 26
RTP : Mixers et Translator Mixer : Combine les flux de différentes sources pour former un seul flux Devient la source de synchronisation Tous les paquets RTP sont «marqués» par le SSRC du mixer L identité des sources originales est inclue dans les options de l entête RTP (liste CSRC : contributing SRC) Emetteur 1 Mixer 1 Récepteur E1: SSRC =12 De M1 : SSRC =32 CSRC {12,3} E2 : SSRC =3 Emetteur 2 2011 RMMQoS-chap1 79 27