Réseaux Multimédia et Qualité de Servicepansiot/enseignement/RMM/RMM_c… · 1 2011 RMMQoS-chap1 1 Réseaux Multimédia et Qualité de Service M2 RISE 2011-2012 JJ Pansiot 2011

1

2011 RMMQoS-chap1 1

Réseaux Multimédia et Qualité de Service

M2 RISE

2011-2012

JJ Pansiot

2011 RMMQoS-chap1 2

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 3

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

2

2011 RMMQoS-chap1 4

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 5

Multimédia, Qualité de Service? Applications multimédia : flux continus audio/ vidéo à travers le réseau

Le réseau fournit aux applications le niveau de performance nécessaire à leur bon fonctionnement

QoS

2011 RMMQoS-chap1 6

Applications Multimédia 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

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”

3

2011 RMMQoS-chap1 7

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 8

Streaming de média enregistrés

1. video enregistrée

2. video émise

3. video reçue et jouée par le client

Don

nées

cum

ulée

s

streaming : à cet instant le client joue alors que le serveur émet

délai réseau

temps

2011 RMMQoS-chap1 9

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

4

2011 RMMQoS-chap1 10

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)


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


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)

5


Multimedia interactif “temps réel”

•  initialisation de session –  comment l’appelé annonce son adresse/port,

codage ? - voir protocoles SIP, H323


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


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

6


Audio


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

•  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


Exemple

(a) signal (b) échantillonnage. (c) quantification sur 4 bits

7


Compression audio et l’oreille

(a)  seuil d’audibilité/fréquence ~ bande passante oreille

(b) effet de masquage


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


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)

8


Streaming Audio

Le logiciel client “média player” met les données dans un buffer, et les joue ensuite


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


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é

9


transmission à débit constant

donn

ées

cum

ulée

s

temps

délai réseau variable (gigue)

réception au client joué à

un débit constant

délai de playout

donn

ées

buff

eris

ées

Gigue

•  délai de réception entre deux paquets –  > 20 ms ou < 20 ms

•  remplissage variable du buffer


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é


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

10


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


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.


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

11


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


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


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

12


Média Vidéo


Video analogique

Format de balayage NTSC.


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

13


Codage JPEG : vue générale

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

préparation des blocs DCT Quantification Quantification

différentielle RLE encodage statistique


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


Codage JPEG : DCT

(a) Un bloc de la matrice Y (ou U, V) (b) les coefficients DCT

(a) (b)

14


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)


Codage JPEG : sérialisation et RLE

Ordre de parcours en “zig-zag” des coefficients => sérialisation.

Suite de 0 : RLE


Codage MPEG

Synchronisation des flux audio et vidéo dans MPEG-1.

15


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


Codeur MPEG

Pre processing

Mémoire image

+ - DCT

compensation mouvement

Estimation mouvement

mémoire image

+

IDCT

Quantificateur (Q)

Régulateur débit

Encodeur longueur variable

Buffer Q-1

Output Input

Imag

e pr

édite

Vect

eur m

ouve

men

t


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

16


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é


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


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)

17


Architecture distribution VoD


Serveurs VoD

Hiérarchie de stockage Volume/rapidité.


Architecture Serveur VoD

18


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)


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 …


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

19


Multimédia : protocoles

IPv4, IPv6

UDP TCP

PPP ATM Ethernet

Media (H. 261, MPEG)

H. 323 SIP RTSP RSVP RTCP

RTP

signalisation Qualité de service Transport média

App

licat

ion

Noy

au


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)


Architecture émetteur

envoie RTP et RTCP reçoit RTCP

récepteur reçoit RTP et RTCP envoie RTCP

possibilité plusieurs récepteurs ⇒ multicast

20


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


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


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

21


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 !


RTP : Exemples de profils (PT) audio/video

Type de profil Format audio Taux d'échantillonnage

Débit

0 MIC/PCMU Codage voix

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

Type de profil Format vidéo

26 JPEG animé

31 H.261

32 MPEG 1 vidéo

33 MPEG 2 vidéo

0 à 23 audio

24- vidéo ou combiné


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

22


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


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 …


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

23


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


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!


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 |!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!

24


•  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)

SR (suite)


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 |!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+!


•  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

RTCP : Format message (RR)

25


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, …


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 :-))


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

26


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 ?


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


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

Emetteur 2

Récepteur

E1: SSRC =12

E2 : SSRC =3

De E1 : SSRC =12

De E2 : SSRC =3

De E1 : SSRC =12

De E2 : SSRC =3

Translator 1 Translator 2

27


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

Emetteur 2

Récepteur

E1: SSRC =12

E2 : SSRC =3

De M1 : SSRC =32 CSRC {12,3}

Mixer 1

Documents

Réseaux Multimédia et Qualité de Servicepansiot/enseignement/RMM/RMM_c… · 1 2011 RMMQoS-chap1 1 Réseaux Multimédia et Qualité de Service M2 RISE 2011-2012 JJ Pansiot 2011