à l’Université Pierre et Marie Curie, le 8 mars 2004

Maîtrise Polyvalente

Internet et Multimédia

Cours 5 : Streaming et Signalisation

Timur FRIEDMAN
transparents adaptés de &RPSXWHU1HWZRUNLQJ
copyright 1996-2002 J.F. Kurose et K.W. Ross
une partie des traductions grâce à Kavé SALAMATIAN

Plan
■ Applications multimédia
■ Streaming d’audio et
vidéo stockés
■ RTSP
■ Exemple de l’interactive:
téléphonie sur IP
■ Applications en temps-
réel
■ SIP

2
 Applications multimédia
■ Les classes d’applications
■ VWUHDPLQJ d’audio et vidéo stockés
■ VWUHDPLQJ d’audio et vidéo en direct
■ audio et vidéo interactives en temps réel
■ VWUHDPLQJ = la lecture en transit

■ Les caractéristiques
■ sensible aux délais
■ de bout en bout
■ la gigue
■ résistant aux pertes
3

Streaming d’audio et vidéo stockés

■ media est stocké à la source

■ transmis au client
■ streaming : le client commence la
lecture DYDQW la fin de la réception
■ contrainte temporelle pour les données
qui restent à transmettre :
■ qu’elles arrivent à temps pour la lecture

4
Quantité de données
Le streaming

2. vidéo
envoyée
1. vidéo 3. vidéo reçue,
enregistrée GpODL lecture par le client
UpVHDX
temps
VWUHDPLQJ A cet instant, le client
commence à afficher la vidéo alors
que le serveur continue de transmettre
le reste de la vidéo

L’intéractivité et les données stockées

■ )RQFWLRQQDOLWpPDJQpWRVFRSH le
client peut arrêter, rembobiner,
avancer
■ délai initial de 10 sec OK
■ 1-2 sec avant l’éxecution de la
commande OK

6
 Streaming d’audio et vidéo en direct
Exemples
■ radio par Internet
■ transmission des matches sportives
Streaming
■ mémoire tampon pour la lecture
■ la lecture peut s’effectuer plusieurs dizaines de
secondes après la transmission
■ il y a toujours des contraintes temporelles
Interactivité
■ avancer impossible
■ rembobiner, pause possible
7

Audio et vidéo interactives en temps réel

■ applications : téléphonie sur IP,

visioconférence, jeux interactifs,
mondes virtuels
■ délai de bout en bout requis :
■ audio : < 150 ms bon, < 400 ms OK
■ vidéo : < 150 ms
■ Le délai inclue le traitement par l’application :
■ mise en paquets
■ compression
8
 Plan
■ Applications multimédia
■ Streaming d’audio et
vidéo stockés
■ RTSP
■ Exemple de l’interactive:
téléphonie sur IP
■ Applications en temps-
réel
■ SIP

Streaming d’audio et vidéo stockés

Techniques de streaming
au niveau applicatif pour
faire face à un Internet Lect eur Média
moindre effort : ■ suppression de la gigue
■ mise en mémoire ■ décompression
tampon du côté client ■ dissimulation d’erreurs
■ interface graphique
■ UDP et TCP mixtes
avec contrôles pour
■ plusieurs encodages l’interactivité
possible pour le
multimédia

10
 L’approche la plus simple

■ audio et vidéo enregistré dans des fichiers

■ les fichiers sont transmis en tant qu’objets
HTTP
■ d’abord reçus complètement chez le client
■ transfert au lecteur après

audio et vidéo ne sont pas lise en transit :

■ pas de pipeline, délai de réception important
avant l’affichage
11

Une approche streaming

■ le navigateur reçoit un PHWDILFKLHU par GET

■ le navigateur exécute le lecteur « plug-in » et lui passe le
metafichier
■ le lecteur contacte le serveur
■ le serveur envois le flot audio/vidéo au lecteur en streaming
12
 Une approche avec un serveur streaming

■ Cet architecture permet l’utilisation d’un protocole non-HTTP

entre le serveur le lecteur multimédia.
■ Permet l’utilisation de UDP au lieu de TCP.
13

Mise en mémoire tampon du client

vidéo CBR
Quantité de données

réception
au client lecture CBR
du vidéo au client
GpODL
YDULDEOH
mémoire
vidéo en

GXUpVHDX

délai au client temps

avant lecture

■ Compensation pour le délai du réseau, la gigue :

■ mise en mémoire
■ délai avant la lecture au client
14
 Détails de la mémoire

taux
taux variable constant
x(t) d

vidéo en
mémoire

■ La mémoire tampon compense la gigue du délai

15

Streaming du multimédia par UDP

■ Le serveur émet avec un débit adéquat pour le client
■ spécialement s’il ignore les problèmes de congestion
■ débit émetteur = taux d’encodage (CBR)
■ débit récepteur = CBR – pertes de paquets
■ Délais de démarrage courts (2-5 seconds) pour
compenser la gigue du délai
■ Compensation de pertes : si la contrainte temporelle le
permet

16
 Streaming du multimédia par TCP
■ Le serveur émet au débit maximal permis par TCP
■ Le débit récepteur varie à cause du contrôle de congestion
TCP
■ Plus qu’on ajoute du délai au client, plus la lecture du
vidéo devient lisse
■ HTTP/TCP passent plus facilement à travers les pare-
feux

17

Clients hétérogènes
encodage à 1.5 Mb/s

encodage à 28.8 Kb/s

Q : Comment gérer plusieurs clients avec des

débits de réception hétérogènes ?
■ 28.8 Kb/s connexion par modem
■ 100Mb/s sur Ethernet
R : Le serveur garde et transmet de multiples
copies de la vidéo encodé, avec des débits
différents 18
 RTSP « Real Time Streaming Protocol »
HTTP Limites de RTSP :
■ Pas ciblé vers le multimédia ■ pas de définition du
■ Pas de commandes pour codage audio/vidéo
avancer, rembobiner, etc. ■ pas de définition de la
couche transport : le media
RTSP : RFC 2326 peut être transporté par
UDP ou par TCP
■ Protocole client-serveur au
■ pas de définition de la
niveau applicatif.
manière dont le client doit
■ Fonctionnalités fournies au
faire la mise en mémoire
client: avancer, rembobiner, tampon d’audio ou vidéo
pause, repositionnement,
etc.…
19

RTSP: un contrôle hors bande

Comme avec FTP : RTSP :
■ Dans FTP, un fichier est ■ Le flux multimédia est
transmis sur une connexion l’intrabande
TCP. ■ Les messages de contrôle
■ La signalisation de contrôle RTSP utilisent un numéro de
(changement de répertoire, port hors-bande réservé.
effacement de fichier, ■ Port 554
renommément de fichier, etc.)
est transmise sur une
connexion TCP indépendante.
■ Les canaux hors-bande et
intrabande utilisent des
numéros de ports différents.

20
 RTSP : un exemple
Scénario:
■ un metafichier est transmis au navigateur
■ le navigateur exécute le lecteur
■ le lecteur construit :
■ une connexion de contrôle RTSP
■ une connexion pour les données multimédia

21

Metafichier : exemple
<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>

22
 Fonctionnement du RTSP

23

RTSP : exemple d’un échange client-serveur

C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OK
Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231
Range: npt=0-

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231
Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231

S: 200 3 OK

24
 Plan
■ Applications multimédia
■ Streaming d’audio et
vidéo stockés
■ RTSP
■ Exemple de l’interactive:
téléphonie sur IP
■ Applications en temps-
réel
■ SIP

25

Applications interactives en temps réel

■ téléphonie PC à PC Examinons l’exemple

■ fourni par les services de téléphonie PC à
de messagerie PC
instantanée
■ PC à téléphone
■ Dialpad
■ Net2phone
■ visioconférence avec
Webcam
26
 Multimédia interactif : téléphonie sur IP
Notre exemple :
■ La voix alterne des périodes de son et de silence.
■ 64 kb/s pendant une période de son
■ Des paquets ne sont générés que durant des périodes de
son
■ échantillons de 20 msec à 8 Kbytes/sec: 160 bytes par trame
■ Entête applicative ajouté à chaque trame.
■ Trame+entête sont encapsulés dans des segments UDP.
■ L’application envoi des segments UDP par le biais des
sockets chaque 20 msec pendant une période de son.

27

Multimédia interactif : les pertes et les délais

■ pertes de paquets : Les paquets IP peuvent être

perdu par cause de congestion (débordement des
files d’attente)
■ délai important : Un paquet IP peut être considéré
comme perdu s’il arrive trop tard au récepteur
■ délais dus au traitement, files d’attente, terminaux
(récepteur, émetteur)
■ délai maximal tolérable : 400 ms audio, vidéo
■ tolérance aux pertes : dépend du type de
compression, de la compensation, de l’existence
de FEC.
■ taux de pertes entre 1% et 10% peuvent être toléré

28
 Gigue de délai

transmission
Quantité de données

CBR réception
au client lecteur CBR
au client
GpODL
GXUpVHDX

en mémoire
données
YDULDEOH
JLJXH

■délai au client temps

avant lecture

■ La différence entre les délais de deux paquets

consécutives peut être plus ou moins que 20 msec

29

Tampons de réception fixe

■ Le récepteur diffuse chaque paquet exactement
q msecs après que la trame a été généré.
■ Si la trame a une estampille à l’instant t : il est
diffusé à l’instant t+q .
■ Si la trame arrive après t+q : la trame est
considérée perdue
■ Balance pour q:
■ grand q: moins de pertes
■ petit q: meilleur interactivité

30
 Délai de diffusion fixe
• L’émetteur génère un paquet toutes les 20 msec durant la période de son.
• Le premier paquet est reçu à l’instant r
• Un programme de diffusion : commencer à p
• Deuxième programme de diffusion: commencer à p’
packets


 loss


 


   
  



  



time

r
p p’
31

Tampon adaptatif
■ Buts :
■ minimiser le délai de diffusion
■ maintien un taux de pertes bas

■ Stratégie : adapter le délai de diffusion

■ Estimer le délai réseau, régler le délai de diffusion au début de
chaque période de son.
■ Les périodes de silence sont compressées et élongées.
■ Les trames sont toujours diffusés chaque 20 msec pendant les
périodes de son.

32
 Tampon adaptatif : calcul
t i = timestamp of the ith packet
ri = the time packet i is received by receiver
p i = the time packet i is played at receiver
ri − t i = network delay for ith p acket
d i = estimate of average network delay after receiving ith packet

Estimation dynamique du délai moyen au récepteur :

G  = (1 − X )G  −1 + X( U − W )
X est constant (e.g., X = .01).

33

Tampon adaptatif : calcul bis

L’écart type, Y , peut aussi être estimé :

Y  = (1 − X ) Y  −1 + X | U − W − G  |
G et Y sont calculés pour chaque paquet, mais sont appliqués au début d’une
période de parole.

Pour le premier paquet d’une période de parole l’instant de diffusion est :

S  = W  + G  + .Y 
pour K un constant positif.

Les autres paquets de cette même période de parole,

sont diffusés dans une manière périodique.

34
 Tampon adaptatif
Q : Comment le récepteur détermine que le paquet
est le premier d’une période de parole ?
■ Sans pertes, le récepteur scrute les estampilles
successive.
■ Si la différence entre deux estampilles successive > 20
msec --> début de période de parole.
■ Avec des pertes, il faut faire attention au numéros
de séquence aussi.
■ différence entre deux estampilles > 20 msec et
numéros de séquence successive --> début de période.

■ Voir RTP/RTCP
35

Résistance contre les pertes (1)

« forward error correction »
(FEC) : procédure simple
■ pour chaque groupe de n
trames, on crée une
trame redondante
■ XOR sur les n trames
■ on envoi n+1 trames
■ le débit augmente par 1/n
■ Le délai de diffusion est
le temps de recevoir
toutes les n+1 trames
■ Echange :
■ n plus grand
■ moins on gaspille la
bande passante
■ plus de délai de

■ on peut reconstruire les n diffusion

trames originales si on ■ plus grande la

reçoit n des n+1 trames probabilité de perdre

2 trames sur n+1
36
 Résistance contre les pertes (2)
2ème procédure FEC
superposition d’un flux de
qualité inférieur

• par exemple, flux PCM

à 64 kb/s et flux redondant
GSM à 13 kbps.

• Le récepteur peut cacher toute perte non-consecutive.

37

Résistance contre les pertes (3)

3ème procédure : entrelacement

■ les trames sont découpées en unités
plus petits
■ par exemple, 4 unités de 5 msec par
trame
■ chaque paquet contient des petits
unités de plusieurs trames
■ si un paquet est perdu, on reçoit
toujours le plupart de chaque trame
■ pas de surdébit de redondance
■ le délai de diffusion augmente

38
 Bilan sur le multimédia interactif
■ on utilise UDP
■ éviter les délais induits par contrôle de congestion TCP

■ le récepteur adapte son délai de diffusion

■ compensation pour les délais aléatoires
■ le serveur gère le débit du flux en fonction de la bande passante
disponible sur le chemin client-serveur
■ choix parmi des encodages à différents débits
■ la choix peut être dynamique
■ compensation pour les pertes
■ FEC, entrelacement
■ des retransmissions, si le temps permis
■ cacher des erreurs: redondances des flux
39

Plan
■ Applications multimédia
■ Streaming d’audio et
vidéo stockés
■ RTSP
■ Exemple de l’interactive:
téléphonie sur IP
■ Applications en temps-
réel
■ SIP

40
 SIP
■ Session Initiation Protocol (RFC 3263)

La philosophie de SIP
■ Tous les appels téléphoniques et tous les
visioconférences vont avoir lieu dans l’Internet.
■ On identifie les participants par nom ou par mél, non
par numéro de téléphone.
■ On peut toujours joindre son correspondant
■ n’importe où il se trouve
■ n’importe lequel adresse IP il utilise.

41

Les services SIP

■ Etablissement de
connexion
■ Signalisation au
correspondant qu’on
veut l’appeler
■ Signalisation pour se
mettre d’accord sur les
medias et l’encodage
■ Signalisation pour la
terminaison d’un appel.
■ Recherche de l’adresse
IP du correspondant
■ Mappage entre l’identifiant
mnémonique et l’adresse
IP actuelle
■ Gestion de l’appel
■ Ajout de nouveaux flux de
media en cours d’appel
■ Changement d’encodage
en cours d’appel
■ Invitations aux autres
■ Transfert d’appel, mise en
garde
42
 Exemple : établissement d’appel
Alice
Bob
• Alice invite Bob à
communiquer (port 5060)
• son message SIP invite
167.180.112.24
INVITE bob@
193.64.210.89
contient son numéro de
c=IN IP4 16 193.64.210.89
m=audio 38
7.180.112.2
4
port et son adresse IP
060 RTP/A
VP 0
port 5060 Bob’s
• il indique que Alice
terminal rings préfère de recevoir
200 OK
c=IN IP4 193.64.
210.89
RTP/AVP 3
l’encodage PCM ulaw
m=audio 48753
port 5060 • Le message 200 OK de Bob
ACK indique
port 5060
• son adresse IP et
µ Law audio numéro de port pour la
port 38060
communication
• sa préférence pour
GSM
port 48753 l’encodage GSM
• Les messages SIP peuvent
être TCP or UDP; ici
time time RTP/UDP.
43

Etablissement d’appel bis

■ Négociation de l’encodage:
■ Rejet d’appel
■ Supposons que Bob ne
■ Bob peut rejeter des appels
dispose pas de l’encodeur
PCM ulaw. avec les réponses replies
« occupé », « absent »,
■ Bob répond par 606 Not
« crédit insuffisant », ou
Acceptable Reply. Il fourni la « interdit ».
liste des encodeurs dont il
peut s’en servir.
■ Alice peut ensuite envoyer un
nouveau message INVITE,
proposant un encodeur
adapté.

44
 Exemple d’un message SIP
INVITE sip:bob@domain.com SIP/2.0 • Dans ce cas, Alice ne
Via: SIP/2.0/UDP 167.180.112.24 connaît pas l’adresse IP
From: sip:alice@hereway.com de Bob.
To: sip:bob@domain.com •Des serveurs
Call-ID: a2e3a@pigeon.hereway.com intermediares sont
Content-Type: application/sdp nécessaires.
Content-Length: 885
•Alice envoi et reçoit
c=IN IP4 167.180.112.24 des messages SIP sur
m=audio 38060 RTP/AVP 0 le numéro de port par
défaut 5060.
A noter:
■ syntaxe HTTP • Alice indique dans
■ sdp = session description protocol l’entête Via que son
■ unicité d’identifiants Call-ID client SIP envoi et
reçoit par UDP.

45

Annuaire et localisation
■ Comment appeler si on ■ L’information fourni peut
connaît seulement le nom ou varier selon :
l’adresse mél ? ■ l’horaire (travail, maison)

■ Comment connaître l’adresse ■ celui qui appel (éviter qu’un

IP actuel du correspondant ? appel professionnel est

diriger vers le foyer)
■ le correspondant se déplace
■ l’état du correspondant
■ il utilise le protocole DHCP (quand il est occupé, on
■ il a plusieurs appareils IP (PC, dirige les appels vers le
PDA, voiture) répondeur)
Les serveurs SIP :
■ SIP registrar
■ SIP proxy

46
 SIP Registrar
■ Quand Bob allume son client SIP, le client envoi
un message SIP REGISTER message au Registrar
Server (comme dans la messagerie instantanée)

message REGISTER :

REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89
From: sip:bob@domain.com
To: sip:bob@domain.com
Expires: 3600

47

SIP Proxy
■ Alice envoi un message INVITE à son serveur proxy
■ il contient l’adresse sip:bob@domain.com
■ Le proxy est responsable for l’acheminement des
messages SIP vers le correspondant
■ les messages peuvent passer par plusieurs serveurs proxy
■ Le correspondant envoi sa réponse via le même
ensemble de serveurs proxy.
■ Le proxy fourni la réponse SIP à Alice
■ la réponse contient l’adresse IP de Bob

■ A noter : un proxy se ressemble à un serveur DNS

48
 Exemple
! "89 'CD& A ) 9 ? 9
Appel de jim@umass.edu = 7'(( - 'B =
vers keith@upenn.edu
! "
9 'CD& A ) 9 ? 9
(1) Jim envoi un message ! "879 :;<
2
' = 9 '#: > - E 9
INVITE au SIP proxy =>@?AA - 'B = 3
4
de umass. (2) Le proxy
renvoi le message vers 1 7 5
le SIP registrar de upenn. 8
6
(3) Le registrar de upenn
répond avec un message 9
3 "4#% & '()
REDIRECT, indiquant qu’il ! "$#% & '() +2,- 1,- /56- *+
*+,- +*.- /0- 12
faut contacter
keith@eurecom.fr
(4) Le proxy umass envoi un INVITE au registrar eurecom. (5) Le registrar eurecom
renvoi le message INVITE à 197.87.54.21, sur lequel tourne le client SIP de keith.
(6-8) réponse SIP (9) media envoyé directement entre les clients.

$QRWHU il y a aussi des acquittements SIP (pas montrés).

49

Comparaison avec H.323

■ H.323 est un autre protocole ■ H.323 a été développé à
de signalisation pour l’UIT (téléphonie).
l’interactive en temps réel ■ SIP a été développé à l’IETF:
■ H.323 est un ensemble Il est inspiré par HTTP.
monolithique de protocoles ■ SIP est plus simple (et alors
pour le visioconférence : plus efficace ?)
signalisation, enregistrement,
contrôle d’admission,
transport, et encodage.
■ SIP est un composant
modulaire. Il est compatible
avec RTP. Il peut fonctionner
avec d’autres protocoles et
services aussi.
50