4 Multimedia QoS PDR 2013 T

Chapitre IV
Chapitre IV
Multimédia et Qualité de Service
(ref: Kurose & Ross)

4. Multimédia et QoS 1
Cours chap. 4
Tutorial IBM ch. 8 Multimedia, Qualité de Service:
(DiffServ + IntServ) Qu’est-ce?
Applications multimédia:
audio et vidéo en réseau
(“média continu”)
QoS
Le réseau fourni des
applications avec un niveau
de performance voulu pour
l’application en question.
1
Chapitre 4: Buts
Principes
• Classification des applications
• Identification les services réseau nécessaires aux
applications
• Tirer le meilleur du service “best effort”
• Mécanismes pour assurer une certaine QoS
Protocoles and Architectures
• Protocoles spécifiques pour le “best effort”
• Architectures pour la QoS
Applications réseau MM
Classes des applications Caractéristiques
MM: fondamentales:
1) Streaming de données • Sensibilité au délai de
audio and video transmission
enregistrées – Délai de bout-en-bout
2) Streaming de données – Jitter (gigue)
audio and video en direct • Mais tolérant aux
3) Audio and video en temps pertes: les pertes peu
réel fréquentes causent des
problèmes mineurs
Le Jitter (gigue) est la
• Contrairement aux
variabilité des retards des
données qui sont
paquets dans un même flux intolérantes aux pertes.
2
Streaming de Multimedia enregistré
Streaming:
❒ media enregistré à la source
❒ Transmission vers le client
❒ streaming: l’application démarre
du côté client avant que toutes les
données soient arrivées
❒ Contraintes temporelles pour les données
transmises: L’application ne doit pas être
interrompue
Streaming du multimedia enregistré:

Qu’est-ce? 3. vidéo reçue,
Jouée chez le
1. vidéo client
enregistrée 2. vidéo
Données
envoyée
Délai
réseau
temps
streaming: Le client
lance la vidéo avant d’avoir
complétement reçu les données
envoyées par le serveur
3
Streaming Multimedia enregistré:
Interactivité
❒ Fonctionnalité de type “DVD” : le client

can faire une pause, revenir en arrière,
aller en avant
❍ Un délai initial de 10 sec. est OK
❍ 1-2 sec pour une command : OK
❍ RTSP souvent utilisé
Streaming multimédia en temps réel

Exemples:
• Radio Internet (talk show)
• Evènement sportif en direct
Streaming
• Tempon (playback)
• Le playback peut être joué quelques dizaines de
secondes après la transmission.
• Contraintes temporelles malgré tout
Interactivité
• Impossible d’aller en avant (fast forward)
• Pause, rembobiner: Impossible!
4
Multimédia interactif, en temps réel
❒ Applications: téléphonie IP, vidéo

conférences, mondes interactifs
distribués
• Exigences pour le délai bout-en-bout:
– audio: < 150 msec bon, < 400 msec OK
• inclu des délais au niveau des applications
(packetization) et du réseau
• Délais plus importants: interactivité difficile
• Initialisation de session
– Comment l’appelant donne son adresse IP, son numéro de
port, ses algorithmes de codage?
Multimedia sur Internet

aujourd’hui
TCP/UDP/IP: “service best-effort”
• auune garantie sur le délai, perte
? ? ?
? ? ?
Mais vous avez dit que les applications ?
nécessitaient de la QoS et un niveau
? De performance pour être efficace ! ?
? ?
Les applications multimédia sur Internet
utilisent des techniques au niveau de
l’application pour limiter (au mieux) les
effets des pertes et du délai
5
Comment Internet devrait-il évoluer pour
mieux supporter les apps multimédia?
Philosophie des Services Philosophie des services
Intégrés: différenciés:
• Changements
fondammentaux d’Internet • Moins de changements
pour que les apps puissent dans l’infrastructure
réserver de la LB de bout-en- Internet, fournir des
bout. services de 1ère, 2ème
• A besoin d’un software classe.
complexe dans les hosts et
les routeurs
Laissez-faire
• Aucun changemnet majeur
• Plus de LB en cas de besoin
• Distribution de contenu,
multicast.
– Niveau applications Quel est votre opinion?
Quelques mots sur la compression

audio
• Signal analogique • Exemple:
échantilloné à un débit
constant 8,000 échant./sec, 256
– téléphone: 8’000 valeurs quantifiées->
échant./sec 64,000 b/s
– Musique CD : 44,100
échant./sec • Le récepteur le convertit
• Chaque échantillon est en signal analogique:
quantifié, i.e., arrondi – Réduction de la
– e.g., 28=256 valeurs qualité
quant. possible
• Chaque valeur quantifiée Débits (exemples)
est représentée par des • CD: 1.411 Mb/s
bits: 8 bits pour 256
valeurs • MP3: 96, 128, 160 kb/s
• Téléphonie internet: 5.3
- 13 kb/s
6
Quelques mots sur la compression
vidéo
• La video est une
séquence d’images à Exemples:
un rythme constant • MPEG 1 (CD-ROM) 1.5
– e.g. 24 images/sec Mb/s
• Les images digitales • MPEG2 (DVD) 3-6 Mb/s
sont une rangée de • MPEG4 (souvent utilisé
pixels
sur internet, < 1 Mbps)
• Chaque pixel est
représenté par des Recherche:
bits • Vidéo en couches
• Redondance (extensible)
– spatiale – S’adapte à la LB disponible
– temporelle
Chapitre 4
• Multimedia Networking • Beyond Best Effort
Applications • Scheduling and
• Streaming stored Policing Mechanisms
audio and video
– RTSP
• Integrated Services
• Real-time Multimedia: • RSVP
Internet Phone Case • Differentiated Services
Study
• Protocols for Real-
Time Interactive
Applications
– RTP,RTCP
– SIP
7
Streaming de données multimedia
enregistrées
Niveau applicatif
Techniques de Media Player
streaming pour tirer le
meilleur du service • Élimination du jitter
“best effort”: • Décompression
• Dissimulation des erreurs
– Mémoriser du côté
• GUI avec contrôle
client interactif
– Utiliser UDP au lieu
de TCP
– Codages multiples
pour le multimédia
Multimédia sur Internet: l’approche

la plus simple
• Audio et vidéo enregistrés dans un

fichier
• Fichiers transférés comme des objets
HTTP
– Reçus dans leur intégrité par le
client
– Joués par un “vidéo/audio player”
Pas de streaming audio/video :
❒ Non, “pipelining,” long délais avant de voir/entendre
qqch!
8
Multimédia sur Internet:
Approche streaming
❒ Le browser obtient un metafile

❒ Le browser lance un player, en passant le metafile
❒ Le player contacte le server
❒ Le server streams l’audio/video au player
Streaming d’un serveur streaming
• Cette architecture permet au protocole non-HTTP

d’échanger entre le serveur et le media player
• Peut aussi utiliser UDP à la place de TCP
9
Streaming Multimedia: Client
Buffering
Transmission vidéo
à débit constant
Réception
vidéo Débit constant
au client final
Données
Délai réseau
variable
mémorisée
Vidéo
Délai client time
• Mémorisation du côté client, le délai de playout

compense le délai du réseau
Streaming Multimédia: Mémorisation

du côté client
Débit de remplisage
variable, x(t) Débit constant, d
Vidéo mémorisée
• Mémorisation côté client, le délai de playout
compense le délai du réseau
10
Streaming Multimédia: UDP ou TCP?
UDP
• Le serveur envoie au débit voulu par le client (en
ignorant les encombrements du réseau!)
– Souvent le débit envoyé = débit de codage=débit constant
– Alors, débit de remplissage = débit constant – pertes de
paquets
• Délai de playout petit (2-5 secondes) pour compenser la
gigue du réseau
• Correction des erreurs: si le temps le permet
TCP
• Envoie au débit maximum
• Le débit de remplissage fluctue à cause du contrôle de
l’encombrement de TCP.
• Délai de playout plus grand: adouci le débit délivré
• HTTP/TCP passe plus facilement à travers les firewalls
Streaming Multimédia: débit client

1.5 Mbps encoding
28.8 Kbps encoding
Q: Comment faire avec des débits très différents à la

réception ?
❍ 28.8 Kb/s dialup
❍ 100Mb/s Ethernet
A: Le serveur mémorise, transmet de multiples
copies de vidéos, codées à des débits différents
11
User Control of Streaming Media:
RTSP
HTTP Ce qu’il ne fait pas:
• Pas prévu pour les • Ne défini pas comment
contenus MM l’audio/vidéo est
• Aucune commande pour encapsulée pour le
la retransmission rapide streaming à travers le
RTSP: RFC 2326 réseau
• Application client- • Ne dit pas comment le
serveur. média est transmoprté
(UDP ou TCP)
• Permet à l’usager de
contrôler: rembobiner, • Ne spécifie pas comment
aller en avant, pause, le media player mémorise
etc… l’audio/vidéo.
RTSP: contrôle hors bande

FTP utilise un canal de Les message RTSP
contrôle hors bande: messages sont aussi
• Un fichier est transféré envoyés hors bande :
sur une connexion TCP • Les messages de
• L’information de contrôle contrôle utilisent
(changement de différents numéros de
répertoire, effacement de port que le stream
fichiers, renommage,…) média: hors bande.
est envoyé à travers une – Port 554
connexion TCP séparée. • Le stream média est
• Les canaux “hors-bande” considéré “dans la
et “dans la bande” bande”.
utilisent des numéros de
ports différents.
12
Exemple RTSP
Scénario:
• Le metafile communique avec un browser web
• Le browser lance un player
• Le player met sur pied un connexion de contrôle
RTSP, une connexion de données au serveur de
streaming
• QuickTime, RealNetworks
Exemple de Metafile
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>
13
Opération RTSP
Chapitre 4
Applications • Scheduling and Policing
• Streaming stored Mechanisms
audio and video • Integrated Services
– RTSP • RSVP
• Real-time, Interactive • Differentiated Services
Multimedia: Internet
Phone Case Study
Time Interactive
Applications
– RTP,RTCP
– SIP
14
Applications interactives en
temps réel
• PC-2-PC phone On va regarder

– Les services de l’exemple du
messagerie téléphone PC-2-PC
instantanée les en détail
fournissent
• PC-2-phone
– Dialpad
– Net2phone
• Vidéoconférences
avec des Webcams
Multimédia interactif:
Téléphonie Internet
Introduction par un exemple
• Audio de celui qui parle: alternativement des
périodes de parole et de silence.
– 64 kb/s durant les périodes de parole
• Les paquets sont générés pendant les périodes de

parole
– Morceaux de 20 msec à 8 KB/sec: 160 B de données
• Un entête “application” est ajouté à chaque
morceau de 20 ms.
• Le tout est encapsulé dans un paquet UDP
• L’application envoie des paquets UDP dans un
socket chaque 20 ms quand on parle
15
Téléphonie internet:
Perte et retard de paquets
• Perte de paquets: Perte de datagramme IP à cause
d’un encombrement dans le réseau (mémoire d’un
buffer qui déborde dans un routeur)
• Retard: Le datagramme IP arrive trop tard à
destination pour pouvoir être utile
– retards: processing, files d’attente dans le réseau, retards
dans les systèmes terminaux (émetteurs, récepteurs)
– Retards maximum tolérables: 400 ms
• Tolérance à la perte: dépend du codage de la voix,
les pertes tolérables peuvent varier de 1% à 10%.
Gigue (jitter)
paquets
générés Paquets reçus
débit constant
Données
pour le client
(cumul)
Mémorisation
Variation
données
du retard dans
le réseau
(gigue, jitter)
retard time
• La différence de retard entre deux paquets

consécutifs peut être de plus de 20 ms.
16
Téléphonie internet:
Retard de lecture fixe
• Le destinataire attend exactement q msec après la
création d’un morceau de données avant de le
lire..
– t: origine du temps du morceau de
données. Lecture à t+q .
– Si les données arrivent après t+q: les
données sont perdues car elles arrivent trop
tard
• Compromis pour q:
– q important: moins de perte de paquets
– q petit: meilleure interactivité
Retard de lecture fixe

• L’émetteur génère des paquets chaque 20 msec.
• Le premier paquet arrive au temps r
• Le premier retard de lecture est fixé à p’-r
• Le second retard de lecture: commence à p-r
packets
packets loss
generated
packets
playout schedule
received
p' - r
playout schedule
p-r
time
r
p p'
17
Retard de lecture adaptatif, I
• But: minimiser le retard de lecture, garder les pertes
faibles
• Approche: ajuster le retard de lecture au fil de la
conversation :
– Estimer le retard dû au réseau, ajuster le délai de lecture
au fil de la conversation.
– Périodes de silence compressées et alongées.
– Morceaux de données joués toutes les 20 msec dans le
même discours.
t i = origine du temps du ième paquet
ri = heure d'arrivée du paquet i au niveau du destinataire
p i = heure de lecture du paquet i
ri − t i = temps de transmission de bout-en-bout
d i = moyenne approximative du temps de transmission après avoir reçu le ième paquet
di = (1 − u)di −1 + u( ri − ti )
Où u est une constante fixe (e.g., u = .01)
Retard de lecture adaptatif, II

Il est utile d’estimer l’écart-type moyen du temps de transmission, vi :
vi = (1 − u)vi −1 + u | ri − ti − di |
Les estimations di et vi sont calculées pour chaque paquet reçu, même si elles
ne servent qu’à déterminer le moment de lecture du premier paquet d’un
fragment de discours donné.
Pour le premier paquet d’un discours, son heure de lecture est:
pi = ti + d i + Kvi
où K est une constante positive.
18
Retard de lecture adaptatif, III
Q: Comment est-ce que le destinataire détermine si un
paquet est le premier d’une conversation?
• Sans perte, le destinataire observe les temps
d’arrivée.
– Différence de temps entre deux paquets> 20 msec --> un
nouveau discours commence.
• Avec des pertes, le destinataire doit observer les
temps d’arrivée et le numéros de séquence.
– Différence de temps entre deux paquets> 20 msec et
numéros de séquence sans trous de séquence --> un
nouveau discours commence.
Problèmes 5,6,7,8,9b
19
Récupération de paquets perdus (1)
Correction d’erreurs sans voie • Le retard de lecture doit
de retour (FEC): être fixé pour recevoir les
• Pour chaque groupe de n n+1 paquets
morceaux créer un OU • Compromis:
exlusif à partir des
– augmenter n: moins de
morceaux originaux
perte de LB
• Envoyer les n+1 morceaux,
– augmenter n: plus de
augmentant la LB d’un
retard de lecture
facteur de 1/n.
– augmenter n: il y a une
• On peut reconstruire
plus grande probabilité
l’original (n morceaux) s’il y
que 2 ou plus de
a au plus un morceau parmi
morceaux soient
les n+1 qui est perdu
perdus
2ème mécanisme FEC
• envoyer les données

avec une résolution
inférieure avec redondance
Par exemple:
Au lieu du flux original
PCM à 64 kb/s
utiliser un flux
GSM à 13 kb/s.
• Quand il n’y a pas de perte consécutive le récepteur

peut cacher les pertes.
• On peut adapter la méthode et associer plusieurs morceaux
entre eux à chaque morceau original.
20
Entrelacement
• Les morceaux sont séparés en plus • Si un paquet est perdu il nous
petites unités reste la grande partie du
• Par exemple, des unités de 4*5 message
msec par morceau • Pas d’overhead dû à la
• Les paquets contiennent des redondance
petites unités de chaque morceau • Mais ajoute un retard de lecture
Résumé: Multimedia sur Internet :

ensemble d’astuces
• utilisation d’UDP pour éviter les délais de TCP dûs
au contrôle de congestion pour les applications
sensibles au retard
• Du côté client retard de lecture adaptatif: à

compenser pour le délai
• Du côté serveur: adapter le débit à la largeur de
bande disponible entre le client et le serveur
– Choisi parmi les débits pré-encodés
– Débit de codage dynamique par le serveur
• Récupération des erreurs (sur UDP)
– FEC, entrelacement
– retransmissions, si nous avons le temps
– Cacher le erreurs
21
Problèmes 10,11
Chapitre 4
• Streaming stored Mechanisms
audio and video
– RTSP
• Real-time, Interactive • RSVP
Multimedia: Internet • Differentiated Services
Phone Case Study
Time Interactive
Applications
– RTP,RTCP
– SIP
22
Real-Time Protocol (RTP)
• RTP spécifie une • RTP fonctionne sur les
structure de paquet systèmes terminaux.
pour les paquets audio • Les paquets RTP sont
et vidéo encapsulés dans des
segments UDP
• RFC 1889.
• Interopérabilité: Si
• Les paquets RTP deux téléphones
fournissent internet utilisent RTP,
– Identification du type alors ils devraient être
de payload capables de
– Numéros de séquence communiquer
– Référence de temps ensemble.
RTP fonctionne au-dessus de UDP

Les librairies RTP libraries fournissent un interface
qui “étend” UDP: provide a transport-layer interface
that extend UDP:
• numéros de ports, adresses IP
• identification du type de payload
• numérotation des paquets
• référence de temps
23
Exemple RTP
• Considérez un flux de • L’entête RTP indique le
voix codé (PCM) de 64 type de codage audio
kb/s sur RTP. utilisé dans chaque
• L’application collecte les paquet
données codées en – L’émetteur peut
messages, e.g., chaque changer de codage
20 msec = 160 bytes. durant la conférence.
• Les messages audio + • L’entête RTP contient des
entête RTP forment un numéros de séquence et
paquet RTP, qui est une référence de temps.
encapsulé dans un
segment UDP.
RTP et QoS
• RTP ne fourni pas les mécanismes pour assurer la

transmission des données en un temps défini. Il ne
fourni d’ailleurs aucune garantie de qualité de
service.
• L’encapsulation est seulement vue dans les
systèmes terminaux: Elle n’est pas examinée dans
les routeurs intermédiaires.
– Les routeurs fournissant un service “best effort” ne font
pas un effort spécial pour permettre aux paquets RTP
d’arriver à temps à destination.
24
Entête RTP
Payload Type (7 bits): Indique le type de codage utilisé. Si l’émetteur

change le codage au milieu d’une conférence, il va informer le
récepteur avec ce champ.
•Payload type 0: PCM mu-law, 64 kb/s

•Payload type 3, GSM, 13 kb/s
•Payload type 7, LPC, 2.4 kb/s
•Payload type 26, Motion JPEG
•Payload type 31. H.261
•Payload type 33, MPEG2 video
Numéro de séquence (16 bits): Incrémente de un pour chaque paquet

RTP envoyé, peut être utilisé pour détecter des pertes de paquets et
restorer une séquence de paquets.
Entête RTP (2)
• Timestamp field (32 bytes long). Référence de

temps. Donne l’heure d’échantillonage du premier octet
du paquet.
– Pour l’audio la valeur affichée par cette horloge augmente
d’une unité à chaque période d’échantillonage (par
exemple, chaque 125 µsecs pour une horloge à 8 KHz)
– Si les morceaux générés par l’application contiennent 160
échantillons, la référence de temps augmente cette valeur
de 160 à chaque nouveau paquet RTP lorsque la source est
active. Si la source est inactive l’horloge augmente à un
rythme constant.
• SSRC field (32 bits long). Identifiant de la source de

synchronisation. Chaque flux d’une session RTP est
généralement doté d’un SSRC particulier.
25
Real-Time Control Protocol (RTCP)
• Fonctionne avec RTP. • Les statistiques incluent

• Chaque participant, dans le nombre de paquets
une session RTP, envoyés, perdus, gigue
transmet périodiquement etc,.
des paquets de contrôle • Le feedback peut être
à tous les autres utilisé pour contrôler la
participants. performance
• Chaque paquet RTCP – L’émetteur peut
contient des rapports de modifier sa
réception/émission transmission basé sur
– Les rapports statistiques les feedbacks reçus
sont utiles pour les
applications
RTCP - suite
- Au cours d’une session RTP chaque participant transmet des paquets

multicast. Tous les paquets RTP et RTCP appartenant à une session
utilisent des adresses multicast
- Les paquets RTP et RTCP sont différenciés les uns des autres
par l’usage de numéros de ports distincts
- Pour limiter le trafic, chaque participant réduit son trafic RTCP
Au fur et à mesure que le nombre de participants augmente
26
Paquets RTCP
Rapports des paquets de Description des
la destination: paquets de
• Fraction des paquets l’expéditeur:
perdus, du dernier • Adresse email de
numéro de séquence, l’émetteur, nom de
de la gigue moyenne. l’émetteur, SSRC du
Rapport des paquets de flux RTP associé.
l’émetteur: • Fourni une
• SSRC du flux RTP, correspondance
temps courant, entre le SSRC et le
nombre de paquets nom de l’utilisateur/
envoyés, nombre host.
d’octets envoyés.
Synchronisation des flux

• RTCP peut synchroniser
• Chaque paquet RTCP
différents flux multimédia
source contient:
dans une session RTP
– timestamp du paquet
• Quand une application de RTP
vidéoconférence génère – Temps de référence pour
un flux pour la vidéo et quand le paquet a été
un flux pour l’audio. créé.
• Les timestamps dans RTP • Les récepteurs peuvent
sont liés aux horloges utiliser cette association
d’échantillonage de pour synchroniser l’audio
l’audio et de la vidéo et la vidéo.
– Pas lié à un temps de
référence
27
Adaptation au débit RTCP
• RTCP essaie de limiter • Les 75 kb/s sont également
son trafic à 5% de la répartis parmi les
largeur de bande de la destinataires :
session. – Avec R destinataires,
Exemple chacun dispose de 75/R kb/
• Supposez qu’un s pour son trafic RTCP.
expéditeur envoie une • L’expéditeur envoyer du
vidéo à 2 Mb/s. Alors trafic RTCP à 25 kb/s.
RTCP va essayer de • Un participant détermine le
limiter son trafic à 100 temps de transmission des
kb/s. paquets RTCP en estimant la
• RTCP accorde 75% de taille moyenne des paquets
son débit aux RTCP divisé par le débit dont
destinataires et les 25% ils disposent.
restant à l’expéditeur.
Problèmes 12,16
28
SIP
• Session Initiation Protocol

• Vient de l’IETF
Vision de SIP à long terme
• Tous les appels téléphoniques et conférences vidéo
passeront par Internet
• Les gens sont identifiés par des noms ou des
adresses email, plutôt que par des numéros de
téléphone.
• Vous pouvez atteindre quelqu’un où qu’il soit
physiquement. Son adresse IP peut également être
quelconque.
Services SIP
• Initiation de session • Détermine l’adresse IP

– Fourni les mécanismes “instantanée” de
l’appelé.
pour un appelant
– L’adresse IP change
(auteur appel) d’aviser constament
l’appelé son souhait • Gestion d’appel
d’engager une – Ajout d’un nouveau
conversation flux de données
– Permet aux participants pendant l’appel
– Changement du codage
de s’entendre sur le pendant l’appel
codage à utiliser. – Invitation de nouveaux
– Fourni les mécanismes participants
pour terminer un appel. – Transfère et maintient
les appels
29
Etablissement d’un appel avec une
adresse IP connue
• Alice envoie un message INVITE
à Bob en indiquant son adresse IP
et son numéro de port. Préférence
de codage: loi µ PCM
• L’accusé de réception de Bob

(200 OK) indique le numéro de
port, adresse IP et codage préféré
(GSM)
• Les messages SIP peuvent être

envoyés sur TCP ou UDP; Ici sur
RTP/UDP.
• Numéro de port SIP par défault:

5060.
Etablissement d’un appel (suite)

• Négociation du codec: • Rejet de l’appel
– Supposons que Bob – Bob peut rejeter
n’ait pas de codeur avec l’appel en des
la loi µ. messages tels que
– Bob va répondre avec “occupé,” “absent,”
un “606 Not “payement exigé”
Acceptable” et lister les “interdit”.
codeurs dont il dispose. • Utilisation de RTP ou d’un
– Alice peut envoyer un autre protocole.
nouveau message
INVITE en choisissant
un codeur approprié.
30
Exemple de message SIP
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 167.180.112.24
From: sip:[email protected] • Ici nous ne connaissons
To: sip:[email protected] pas l’adresse IP de Bob.
Call-ID: [email protected] Des serveurs intermédiaires
Content-Type: application/sdp SIP sont nécessaires
Content-Length: 885
c=IN IP4 167.180.112.24 • Alice envoie et reçoit

m=audio 38060 RTP/AVP 0 des messages SIP
en utilisant le port de
Notes: défault 506.
• Syntaxe HTTP
• Alice spécifie avec “Via”:
• sdp = session description protocol
entête que le client SIP
• Identifiant d’appel unique pour envoie et reçoit, adresse IP,
chaque appel. messages sur UDP.
Conversion d’adresses de site de

l’utilisateur
• Un appelant désire • Les résultats peuvent
appeler quelqu’un être basés sur:
mais il ne connait – Moment du jour (travail,
maison)
que son nom ou son – appelant (le boss qui
adresse email. appelé à la maison)
• On a besoin d’obtenir – status de l’appelant
(appels envoyés sur une
l’adresse IP actuelle boite vocale quand on est
de l’appelé: déjà en conversation avec
– L’utilisateur voyage quelqu’un)
– Protocole DHCP Service fourni par des
– L’utilisateur a différents serveurs SIP :
appareils (PC, PDA,…) • Enregistrement à un serveur
SIP
• Serveur proxy SIP
31
SIP Registrar
❒ Quand Bob démarre un client, le client envoie un message
SIP REGISTER au serveur d’enregistrement de Bob
(fonction similaire voulue par Instant Messaging)
Register Message:
REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89
From: sip:[email protected]
To: sip:[email protected]
Expires: 3600
Proxy SIP
• Alice envoie le message d’invitation à son serveur

proxy
– Contient l’adresse sip:[email protected]
• Le proxy est responsable pour le routage des
messages vers le destinataire
– Éventuellement avec de multiples proxys.
• Le destinatire envoie la réponse à travers le même
ensemble de proxys.
• Le proxy retourne le message à Alice
– Contient l’adresse IP de Bob
• Note: le proxy is analogue à un serveur DNS local
32
Exemple
[email protected]
veut appeler
[email protected]
(1) Jim envoie un message INVITE

au proxy SIP de umass. (2) Le Proxy
Transmet la requête au serveur
de upenn (3) Le serveur de upenn
retourne une réponse de redirection
indiquant qu’il devrait essayer
[email protected]
(4) Le proxy de umass envoie un INVITE au serveur d’Eurécom. (5) Le
Serveur d’Eurécom transmet l’INVITE à l’adresse 197.87.54.21, qui est
l’adresse client SIP de Keith. (6-8) La réponse SIP est renvoyée (9) les deux
clients peuvent s’échanger les données directement.
Note: il y a des messages SIP ACK, qui ne sont pas montrés ici.
Comparaison avec H.323

• H.323 est un autre protocole • H.323 vient de l’ITU
de signalisation pour des (téléphonie).
applications vidéo/voix • SIP vient de l’IETF:
interactives Emprunte beacuoup de ses
• H.323 est complète. C’est un concepts de HTTP. SIP a un
suite de protocoles pour les “goût” d’internet, alors que
conférences multimédia: H.323 en a un de la
signalisation,enregistrement, téléphonie.
admission, contrôle, • SIP utilise le principe
transports, codecs,.. “KISS” : Keep it simple
• SIP est un seul composant. stupid.
Travaille de préférence avec
RTP. Peut être combiné avec
d’autres services/protocoles.
33
Chapitre 4
• Streaming stored audio and Mechanisms
video
– RTSP
• RSVP
• Real-time, Interactive
Multimedia: Internet Phone • Differentiated Services
Case Study
• Protocols for Real-Time
Interactive Applications
– RTP,RTCP
– SIP
Amélioration de la QoS dans les réseaux IP

Jusqu’à présent: “faire au mieux avec le best effort”
Dans le futur: la prochaine génération d’Internet avec
des garanties de QoS
– RSVP: signalisation pour la réservation des
ressources
– Services différenciés: garanties différentielles
– Services intégrés: garanties fermes
• Modèle simple
Pour les études de
partage et
d’encombrement:
34
Principes des garanties pour la QoS
• Exemple: 1Mb/s téléphone IP, FTP partagent une
ligne de 1.5 Mb/s.
– Des bursts FTP peuvent encombrer un routeur, causer des
pertes audio
– On désire donner la priorité à l’audio plutôt qu’à FTP
1er Principe
Le marquage des paquets permet aux routeurs de
différencier les paquets appartenant à des catégories
de trafic différentes.
Principes pour des garanties de QOS

(suite)
• Que se passe-t-il si les applications se comportent
mal (si les application audio envoient à un débit plus
élevé que le débit déclaré)
– policing: forcer la source à adhérer aux allocations de LB
• Marquer et policer dans les bords du réseau:
– similaire à ATM UNI (User Network Interface)
2 ème principe
Fournir une protection (isolation) pour les différents flux
35
(suite)
• Allouer une largeur de bande fixe par flux:
utilisation inefficace si le flux n’utilise pas cette
allocation
3ème principe
Tout en isolant les flux les uns des autres, il est
Souhaitable de laisser les ressources réseau libres
de se répartir de la manière la plus efficace

(suite)
• Basic fact of life: On ne peut pas supporter des
demandes de trafic au dela de la capacité de la
ligne
Principle 4
Admission d’appel: le flux déclare ses besoins. Le réseau
peut bloquer (occupé) s’il ne peut pas les satisfaire
36
Résumé des principes pour la QoS
Ayons un aperçu des mécanismes pour les atteindre …

Chapitre 4
video
– RTSP
Case Study
– RTP,RTCP
– SIP
37
Mécanismes d’ordonnancement et
de contrôle
• Mécanismes d’ordonnancement (scheduling): choix du
paquet suivant à mettre sur la ligne
• FIFO (first in first out) scheduling: envoyer dans
l’ordre d’arrivée
– Exemple dans le monde réel?
– Rejet de paquets: si un paquet arrive dans une file pleine: Qui
éliminer?
• Élimination de la queue: éliminer le paquet entrant
• priorité: éliminer sur la base de la priorité
• aléatoirement: éliminer aléatoirement
de contrôle (suite)
Mise en attente avec respect des priorités:
transmettre le paquet avec la priorité la plus haute
• Classes multiples, avec différentes priorités
– La classe peut dépendre du marquage ou des informations
de l’entête (e.g. IP source/dest, no de port, etc..)
– Exemple dans le monde réel?
38
Ordonnacement “round robin” (cyclique):
• Classes multiples
• Scanne les classes des files de manière cyclique,
servant un de chaque classe (si disponible)
• Exemple dans le monde réel?
Weighted Fair Queuing:
• Round Robin généralisé
• Chaque classe obtient un niveau de service (poids)
à chaque cycle
• Exemples dans le monde réel?
39
Problème 17
Mécanismes de contrôle
But: limiter le trafic pour ne pas excéder les
paramètres déclarés
Trois points de contrôle importants:
• (Long terme) Débit moyen: combien de paquets
peuvent être envoyés par unité de temps
– Question cruciale: quelle est la longueur de l’intervalle? 100
paquets par sec ou 6000 packets par min ont la même
moyenne!
• Débit de pointe: e.g., 6000 paquets par min. (ppm)
en moyenne; 1500 paquets par seconde en débit de
pointe
• (Max.) Grandeur du burst: Nombre max. de paquets
envoyés consécutivement (avec aucun vide)
40
Mécanismes de contrôle
Sceau percé: limite l’entrée à une grandeur de
burst et à un débit moyen.
• Le sceau peut contenir b jetons

• Les jetons sont générés au débit de r jetons/sec
jusqu’à ce que le sceeau soit plein
• Sur l’intervalle de longueur t: nombre de paquets
pouvant entrer dans le sceau est au plus égal à
(r t + b).
Mécanismes de contrôle (suite)

• Sceau percé, WFQ combinés pour fournir un temps
maximal d’attente pour le délai, i.e., garantie QoS!
token rate, r
arriving
traffic
bucket size, b
per-flow
rate, R
WFQ
D = b/R
max
41
Exercices 18, 19, 20
Chapitre 4
video
– RTSP
Case Study
– RTP,RTCP
– SIP
42
Services intégrés (IETF)
• Architecture pour fournir des garanties de QoS

dans des réseaux IP pour des sessions
individuelles
• Réservation de ressources: les routeurs
maintiennent des informations sur les états des
ressources allouées
• Admission/rejet de nouvelles requêtes d’appel:
Question: Est-ce qu’un nouveau flux peut être admis

Avec les garanties de performance voulues tout en ne
dégradant pas celles des flux déjà admis?
Intserv: Scénario de garantie de QoS

• Réservations de ressources
– Initiation d’appel, signalisation
(RSVP)
– trafic, déclaration de QoS
– Contrôle d’admission par élément
request/
reply
❍ QoS-sensitive
scheduling (e.g.,
WFQ)
43
Admission d’appel
Une nouvelle session doit:
• déclarer ses exigences QOS
– R-spec: défini la QoS demandée
• caractérise le trafic qu’il va envoyer dans le réseau
– T-spec: défini les caractéristiques de trafic
• Protocole de signalisation: on en a besoin pour
transporter les R-spec et T-spec aux routeurs (où
la réservation est exigée)
– RSVP
Intserv QoS: Modèles de service [rfc2211, rfc 2212]
Service garanti: Service à contrôle de charge:

• Cas le pire pour les arrivées de ❒ ”une qualité de service
trafic: policé par le sceau percé
approxime la QoS que le
• Simple (prouvé
mathématiquement) limite sur même flux recevrait d’un
le délai [Parekh 1992, Cruz élément réseau non
1988]
chargé”
Trafic Débit du jeton, r
arrivant
Grandeur du sceau, b
Débit par flux R
WFQ
D = b/R
max
44
Chapitre 4
video
– RTSP
Case Study
– RTP,RTCP
– SIP
Services différenciés de l’IETF

Problèmes avec Intserv:
• Etendue (Scalability): signalisation, maintenir un
état par flux est difficile pour un grand nombre de
flux
• Modèles de service flexibles: Intserv a seulement
deux classes. On aimerait des classes de service
“qualitatives”
– “comportement comme un câble”
– Distinction relative des services relative service distinction:
Platinum, Gold, Silver
Approche de Diffserv:
• Fonctions simples dans le coeur du réseau, relativement
complexes dans les bords (edge routeurs (périphérie), hosts)
• Ne défini pas des classes de service, fourni les composants
fonctionnels pour construire les classes de service
45
Architecture Diffserv
r marking
Edge router: scheduling
- Gestion du trafic par flux per-flow b
- Paquets marqués comme in- ..
profile et out-profile .
Core router:
- Gestion du trafic par flux per class
- Mémorisation et séquencement basé
sur le maquage sur les bords
-La préférence est donnée aux
paquets in-profile
- Assured Forwarding
Marquage dans les routeurs de périphérie

(Edge-router)
❒ profil: débit A pre-negocié rate A, sceau de dimension B
❒ Marquage de paquets à la périphérie basé sur un profil
par-flux Débit A
Paquets des
usagers
Possiblités de marquage:
❒ Marquage basé sur la classe: les paquets de différentes
classes sont marqués différemment
❒ Marquage intra classes: la portion du flux qui est conforme
est marquée différemment de celle qui est non conforme
46
Classification and Conditionnement
• Le paquet est marqué avec le champ Type of
Service (TOS) dans IPv4, et Traffic Class dans IPv6
• 6 bits sont utilisés pour le Differentiated Service
Code Point (DSCP). Il détermine quel PHB le
paquet va recevoir
• 2 bits sont actuellement inutilisés (CU)
Classification and Conditionnement
On peut vouloir limiter l’injection de trafic d’une

certaine classe:
• L’utilisateur déclare son profil de trafic (e.g., débit,
grandeur du burst)
• Le trafic est mesuré, et “profilé” si non conforme
47
Forwarding (PHB)
• PHB permet de d’accorder à chaque catégorie de

trafic le type de transmission.
• PHB ne spécifie pas quels mécanismes à utiliser
pour s’assurer d’un comportement avec une
certaine performance
• Exemples:
– La classe A obtient x% de la LB d’une ligne sortante sur
un intervalle de temps spécifié
– Les paquets de classe A partent en premier avant les
paquets de classe B
Forwarding (PHB)
Deux PHBs font actuellement l’obet de
débats à l’IETF:
• Expedited Forwarding: le débit de départ d’une
classe égale ou excède un débit spécifique
– Ligne logique avec un débit minimum garanti
• Assured Forwarding: 4 classes de trafic
– Chacun a une LB minimum garantie
– Chacun avec trois catégories de “préférence de perte”
48
Multimedia: Résumé
• Exigence des applications MM
• Faire au mieux avec le “best effort”
• Mécanismes d’ordonnancement et de
contrôle
• Prochaine génération d’Internet:
Intserv, RSVP, Diffserv
Exercices supplémentaires
49

4 Multimedia QoS PDR 2013 T

Transféré par

Droits d'auteur :

Formats disponibles

4 Multimedia QoS PDR 2013 T

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

4 Multimedia QoS PDR 2013 T

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre IV

Multimédia et Qualité de Service

(ref: Kurose & Ross)

Streaming du multimedia enregistré:

❒ Fonctionnalité de type “DVD” : le client

Streaming multimédia en temps réel

❒ Applications: téléphonie IP, vidéo

Multimedia sur Internet

Quelques mots sur la compression

Multimédia sur Internet: l’approche

• Audio et vidéo enregistrés dans un

❒ Le browser obtient un metafile

Streaming d’un serveur streaming

• Cette architecture permet au protocole non-HTTP

• Mémorisation du côté client, le délai de playout

Streaming Multimédia: Mémorisation

Streaming Multimédia: débit client

28.8 Kbps encoding

Q: Comment faire avec des débits très différents à la

RTSP: contrôle hors bande

• PC-2-PC phone On va regarder

• Les paquets sont générés pendant les périodes de

• La différence de retard entre deux paquets

Retard de lecture fixe

Retard de lecture adaptatif, II

Récupération de paquets perdus (2)

2ème mécanisme FEC

• envoyer les données

• Quand il n’y a pas de perte consécutive le récepteur

Résumé: Multimedia sur Internet :

• Du côté client retard de lecture adaptatif: à

RTP fonctionne au-dessus de UDP

• RTP ne fourni pas les mécanismes pour assurer la

Payload Type (7 bits): Indique le type de codage utilisé. Si l’émetteur

•Payload type 0: PCM mu-law, 64 kb/s

Numéro de séquence (16 bits): Incrémente de un pour chaque paquet

Entête RTP (2)

• Timestamp field (32 bytes long). Référence de

• SSRC field (32 bits long). Identifiant de la source de

• Fonctionne avec RTP. • Les statistiques incluent

- Au cours d’une session RTP chaque participant transmet des paquets

Synchronisation des flux

• Session Initiation Protocol

• Initiation de session • Détermine l’adresse IP

• L’accusé de réception de Bob

• Les messages SIP peuvent être

• Numéro de port SIP par défault:

Etablissement d’un appel (suite)

c=IN IP4 167.180.112.24 • Alice envoie et reçoit

Conversion d’adresses de site de

REGISTER sip:domain.com SIP/2.0

• Alice envoie le message d’invitation à son serveur

(1) Jim envoie un message INVITE

Comparaison avec H.323

Amélioration de la QoS dans les réseaux IP

Principes pour des garanties de QOS

Principes pour des garanties de QOS

Ayons un aperçu des mécanismes pour les atteindre …

• Le sceau peut contenir b jetons