Réseaux Multimédia et Qualité de Service Objectifs

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
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
2011
Note :
Si on attend le flux complet
<=> transfert de fichier
RMMQoS-chap1
7
Données cumulées
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
2011
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
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 28=256 valeurs
possibles
chaque échantillon codé
–  256 valeurs => 8 bits
2011
•  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
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
Gigue
réception
au client
délai réseau
variable
(gigue)
joué à
un débit
constant
données
bufferisées
données
cumulées
transmission
à 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
• 
peut être généralisé à k redondance pour n info
–  inconvénient : débit utilisé augmenté de 1/n
–  délai augmenté (groupe de n+1) au décodage
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
des blocs
DCT
Quantification
Quantification
différentielle
RLE
encodage
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
(b)
(a)
(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 2i é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
Codeur MPEG
Régulateur
débit
+
DCT
-
(Q)
Input
Image prédite
Q-1
Pre
processing
Encodeur
longueur
variable
Quantificateur
IDCT
+
compensation
mouvement
mémoire
image
Vecteur mouvement
Mémoire
image
Buffer
Output
Estimation
RMMQoS-chap1
mouvement
2011
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
Multimédia : protocoles
Application
signalisation
Qualité de service
Transport média
Media
(H. 261, MPEG)
H. 323
SIP
RTSP
RSVP
RTCP
RTP
Noyau
TCP
UDP
IPv4, IPv6
PPP
2011
ATM
RMMQoS-chap1
Ethernet
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
Architecture
émetteur
envoie RTP et RTCP
reçoit RTCP
récepteur
reçoit RTP et RTCP
envoie RTCP
possibilité plusieurs récepteurs
⇒ multicast
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
Débit
0
MIC/PCMU
Codage voix
8 kHz
64 kbit/sec
GSM
8 kHz
4,8 kbit/s
9
G.722
16 kHz
48 à 64 kbit/s
14
3
MPEG Audio
90 kHz
--
15
G. 728
8 kHz
16 kbit/s
24- vidéo ou combiné
2011
Type de profil
Format vidéo
26
JPEG animé
31
H.261
32
MPEG 1 vidéo
33
MPEG 2 vidéo
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.
– 
– 
– 
– 
2011
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
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
Translator 2
Récepteur
De E1 : SSRC =12
E1: SSRC =12
De E1 : SSRC =12
E2 : SSRC =3
De E2 : SSRC =3
2011
RMMQoS-chap1
De E2 : SSRC =3
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
Récepteur
Mixer 1
E1: SSRC =12
De M1 : SSRC =32 CSRC {12,3}
E2 : SSRC =3
Emetteur 2
2011
RMMQoS-chap1
79
27