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

Maîtrise Polyvalente

Internet et Multimédia

Cours 5 : Streaming et Signalisation

Plan

n Applications multimédia n Streaming d’audio et

vidéo stockés n RTSP

n Exemple de l’interactive:

téléphonie sur IP

n Applications en temps-

réel n SIP

Applications multimédia

n Les classes d’applications

n VWUHDPLQJ d’audio et vidéo stockés n VWUHDPLQJ d’audio et vidéo en direct n audio et vidéo interactives en temps réel

n VWUHDPLQJ = la lecture en transit

n Les caractéristiques n sensible aux délais n de bout en bout n la gigue

n résistant aux pertes

Streaming d’audio et vidéo stockés

n media est stocké à la source n transmis au client n streaming : le client commence la lecture DYDQW la fin de la réception n contrainte temporelle pour les données

qui restent à transmettre :

n qu’elles arrivent à temps pour la lecture

Le streaming

s e é n n o d e d é t i t n a u Q

2. vidéo envoyée

1. vidéo enregistrée

GpODL UpVHDX

3. vidéo reçue, lecture par le client

temps

VWUHDPLQJ(cid:29) 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

n )RQFWLRQQDOLWp(cid:3)PDJQpWRVFRSH(cid:3)(cid:29) le client peut arrêter, rembobiner, avancer n délai initial de 10 sec OK n 1-2 sec avant l’éxecution de la

commande OK

Streaming d’audio et vidéo en direct

Exemples n radio par Internet n transmission des matches sportives Streaming n mémoire tampon pour la lecture n la lecture peut s’effectuer plusieurs dizaines de

secondes après la transmission

n il y a toujours des contraintes temporelles Interactivité n avancer impossible n rembobiner, pause possible

Audio et vidéo interactives en temps réel

n applications : téléphonie sur IP, visioconférence, jeux interactifs, mondes virtuels

n délai de bout en bout requis :

n audio : < 150 ms bon, < 400 ms OK n vidéo : < 150 ms

n Le délai inclue le traitement par l’application :

n mise en paquets n compression

Plan

n Applications multimédia n Streaming d’audio et

vidéo stockés n RTSP

n Exemple de l’interactive:

téléphonie sur IP

n Applications en temps-

réel n SIP

Streaming d’audio et vidéo stockés

Techniques de streaming

au niveau applicatif pour faire face à un Internet moindre effort : n mise en mémoire

tampon du côté client

n UDP et TCP mixtes n plusieurs encodages

possible pour le multimédia

Lect eur Média

n suppression de la gigue n décompression n dissimulation d’erreurs n interface graphique avec contrôles pour l’interactivité

L’approche la plus simple

n audio et vidéo enregistré dans des fichiers n les fichiers sont transmis en tant qu’objets

HTTP n d’abord reçus complètement chez le client n transfert au lecteur après

audio et vidéo ne sont pas lise en transit : n pas de pipeline, délai de réception important

avant l’affichage

Une approche streaming

n le navigateur reçoit un PHWDILFKLHU par GET n le navigateur exécute le lecteur « plug-in » et lui passe le

metafichier

n le lecteur contacte le serveur n le serveur envois le flot audio/vidéo au lecteur en streaming

Une approche avec un serveur streaming

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

entre le serveur le lecteur multimédia.

n Permet l’utilisation de UDP au lieu de TCP.

s e é n n o d e d é t i t n a u Q

Mise en mémoire tampon du client

vidéo CBR

réception au client

lecture CBR du vidéo au client

GpODL YDULDEOH GX(cid:3)UpVHDX

n e

o é d v

e r i o m é m

délai au client avant lecture

temps

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

n mise en mémoire n délai avant la lecture au client

Détails de la mémoire

taux variable x(t)

taux constant d

vidéo en mémoire

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

Streaming du multimédia par UDP

n Le serveur émet avec un débit adéquat pour le client n spécialement s’il ignore les problèmes de congestion n débit émetteur = taux d’encodage (CBR) n débit récepteur = CBR – pertes de paquets

n Délais de démarrage courts (2-5 seconds) pour

compenser la gigue du délai

n Compensation de pertes : si la contrainte temporelle le

permet

Streaming du multimédia par TCP

n Le serveur émet au débit maximal permis par TCP

n Le débit récepteur varie à cause du contrôle de congestion

TCP

n Plus qu’on ajoute du délai au client, plus la lecture du

vidéo devient lisse

n HTTP/TCP passent plus facilement à travers les pare-

feux

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 ? n 28.8 Kb/s connexion par modem n 100Mb/s sur Ethernet

R : Le serveur garde et transmet de multiples copies de la vidéo encodé, avec des débits différents

RTSP « Real Time Streaming Protocol »

HTTP n Pas ciblé vers le multimédia n Pas de commandes pour avancer, rembobiner, etc.

Limites de RTSP : n pas de définition du codage audio/vidéo n pas de définition de la

RTSP : RFC 2326 n Protocole client-serveur au

niveau applicatif.

n Fonctionnalités fournies au client: avancer, rembobiner, pause, repositionnement, etc.…

couche transport : le media peut être transporté par UDP ou par TCP

n pas de définition de la

manière dont le client doit faire la mise en mémoire tampon d’audio ou vidéo

RTSP: un contrôle hors bande

RTSP : n Le flux multimédia est

l’intrabande

n Les messages de contrôle

RTSP utilisent un numéro de port hors-bande réservé. n Port 554

Comme avec FTP : n Dans FTP, un fichier est

transmis sur une connexion TCP.

n La signalisation de contrôle (changement de répertoire, effacement de fichier, renommément de fichier, etc.) est transmise sur une connexion TCP indépendante.

n Les canaux hors-bande et intrabande utilisent des numéros de ports différents.

RTSP : un exemple

Scénario: n un metafichier est transmis au navigateur n le navigateur exécute le lecteur n le lecteur construit :

n une connexion de contrôle RTSP n une connexion pour les données multimédia

Metafichier : exemple

<title>Twister</title> <session>

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

Fonctionnement du RTSP

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

Plan

n Applications multimédia n Streaming d’audio et

vidéo stockés n RTSP

n Exemple de l’interactive:

téléphonie sur IP

n Applications en temps-

réel n SIP

Applications interactives en temps réel

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

n téléphonie PC à PC

n fourni par les services

de messagerie instantanée n PC à téléphone

n Dialpad n Net2phone

n visioconférence avec

Webcam

Multimédia interactif : téléphonie sur IP

Notre exemple : n La voix alterne des périodes de son et de silence.

n 64 kb/s pendant une période de son

n Des paquets ne sont générés que durant des périodes de

son n échantillons de 20 msec à 8 Kbytes/sec: 160 bytes par trame

n Entête applicative ajouté à chaque trame. n Trame+entête sont encapsulés dans des segments UDP. n L’application envoi des segments UDP par le biais des sockets chaque 20 msec pendant une période de son.

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

n pertes de paquets : Les paquets IP peuvent être

perdu par cause de congestion (débordement des files d’attente)

n délai important : Un paquet IP peut être considéré

comme perdu s’il arrive trop tard au récepteur n délais dus au traitement, files d’attente, terminaux

(récepteur, émetteur)

n délai maximal tolérable : 400 ms audio, vidéo n tolérance aux pertes : dépend du type de

compression, de la compensation, de l’existence de FEC. n taux de pertes entre 1% et 10% peuvent être toléré

s e é n n o d e d é t i t n a u Q

Gigue de délai

transmission CBR

réception au client

lecteur CBR au client

GpODL GX(cid:3)UpVHDX YDULDEOH (cid:11)JLJXH(cid:12)

s e é n n o d

e r i o m é m n e

ndélai au client avant lecture

temps

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

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

Tampons de réception fixe

n Le récepteur diffuse chaque paquet exactement

q msecs après que la trame a été généré. n Si la trame a une estampille à l’instant t : il est

diffusé à l’instant t+q .

n Si la trame arrive après t+q : la trame est

considérée perdue

n Balance pour q:

n grand q: moins de pertes n petit q: meilleur interactivité

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

(cid:0)(cid:2)(cid:1)(cid:4)(cid:3)(cid:6)(cid:5)(cid:4)(cid:7)(cid:4)(cid:8)

(cid:10)(cid:11)(cid:7)(cid:6)(cid:12)(cid:6)(cid:7)(cid:6)(cid:13)

(cid:1)(cid:4)(cid:8)

(cid:7)(cid:4)(cid:14)

loss

(cid:0)(cid:2)(cid:1)(cid:15)(cid:3)(cid:15)(cid:5)(cid:4)(cid:7)(cid:4)(cid:8)

(cid:7)(cid:15)(cid:3)(cid:15)(cid:7)(cid:15)(cid:16)

(cid:17)(cid:15)(cid:7)(cid:15)(cid:14)

(cid:0)(cid:2)(cid:18)

(cid:1)(cid:4)(cid:19)(cid:4)(cid:20)(cid:22)(cid:21)(cid:15)(cid:8)(cid:11)(cid:9)(cid:15)(cid:3)(cid:6)(cid:23)(cid:2)(cid:7)(cid:15)(cid:14)(cid:11)(cid:21)(cid:2)(cid:18)

(cid:0)(cid:6)(cid:24)(cid:4)(cid:25)(cid:2)(cid:13)

(cid:0)(cid:2)(cid:18)

(cid:1)(cid:4)(cid:19)(cid:4)(cid:20)(cid:22)(cid:21)(cid:15)(cid:8)(cid:2)(cid:9)(cid:6)(cid:3)(cid:6)(cid:23)(cid:2)(cid:7)(cid:15)(cid:14)(cid:11)(cid:21)(cid:2)(cid:18)

(cid:0)(cid:26)(cid:25)(cid:2)(cid:13)

time

p’

Tampon adaptatif

n Buts :

n minimiser le délai de diffusion n maintien un taux de pertes bas

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

n Estimer le délai réseau, régler le délai de diffusion au début de

chaque période de son.

n Les périodes de silence sont compressées et élongées. n Les trames sont toujours diffusés chaque 20 msec pendant les

périodes de son.

(cid:9) (cid:9) (cid:13) (cid:7) (cid:7) Tampon adaptatif : calcul

timestamp

the

ith

packet

the

time

packet

is i

received

receiver

the

time

packet

is i

played

receiver

network

delay

for

ith

acket

i estimate

average

network

delay

after

receiving

ith

packet

r i p

r i d

= t

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

) GX

( UX

)

1 -

X est constant (e.g., X = .01).

Tampon adaptatif : calcul bis

L’écart type, Y (cid:28) , peut aussi être estimé :

) YX

1 -

| UX

-- W

G (cid:28) et Y (cid:28) 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 :

+= W

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.

(cid:27) (cid:27) (cid:27) (cid:27) (cid:29) (cid:29) (cid:29) (cid:29) (cid:29) (cid:30) (cid:30) (cid:30) (cid:30) Tampon adaptatif

Q : Comment le récepteur détermine que le paquet

est le premier d’une période de parole ?

n Sans pertes, le récepteur scrute les estampilles

successive. n Si la différence entre deux estampilles successive > 20

msec --> début de période de parole.

n Avec des pertes, il faut faire attention au numéros

de séquence aussi. n différence entre deux estampilles > 20 msec et

numéros de séquence successive --> début de période.

n Voir RTP/RTCP

Résistance contre les pertes (1)

« forward error correction » (FEC) : procédure simple n pour chaque groupe de n

n Le délai de diffusion est le temps de recevoir toutes les n+1 trames

trames, on crée une trame redondante n XOR sur les n trames n on envoi n+1 trames

n le débit augmente par 1/n n on peut reconstruire les n trames originales si on reçoit n des n+1 trames

n Echange :

n n plus grand

n moins on gaspille la

bande passante n plus de délai de

diffusion

n plus grande la

probabilité de perdre 2 trames sur n+1

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.

Résistance contre les pertes (3)

3ème procédure : entrelacement n les trames sont découpées en unités

plus petits

n par exemple, 4 unités de 5 msec par

trame

n chaque paquet contient des petits

unités de plusieurs trames

n si un paquet est perdu, on reçoit

toujours le plupart de chaque trame

n pas de surdébit de redondance n le délai de diffusion augmente

Bilan sur le multimédia interactif

n on utilise UDP

n éviter les délais induits par contrôle de congestion TCP

n le récepteur adapte son délai de diffusion n compensation pour les délais aléatoires

n le serveur gère le débit du flux en fonction de la bande passante

disponible sur le chemin client-serveur n choix parmi des encodages à différents débits n la choix peut être dynamique n compensation pour les pertes

n FEC, entrelacement n des retransmissions, si le temps permis n cacher des erreurs: redondances des flux

Plan

n Applications multimédia n Streaming d’audio et

vidéo stockés n RTSP

n Exemple de l’interactive:

téléphonie sur IP

n Applications en temps-

réel n SIP

SIP

n Session Initiation Protocol (RFC 3263)

La philosophie de SIP n Tous les appels téléphoniques et tous les

visioconférences vont avoir lieu dans l’Internet.

n On identifie les participants par nom ou par mél, non

par numéro de téléphone.

n On peut toujours joindre son correspondant

n n’importe où il se trouve n n’importe lequel adresse IP il utilise.

Les services SIP

n Etablissement de

connexion n Signalisation au

correspondant qu’on veut l’appeler

n Signalisation pour se

mettre d’accord sur les medias et l’encodage n Signalisation pour la

terminaison d’un appel.

n Recherche de l’adresse IP du correspondant n Mappage entre l’identifiant mnémonique et l’adresse IP actuelle n Gestion de l’appel

n Ajout de nouveaux flux de media en cours d’appel n Changement d’encodage

en cours d’appel

n Invitations aux autres n Transfert d’appel, mise en

garde

Exemple : établissement d’appel

Alice

Bob

• Alice invite Bob à communiquer (port 5060)

167.180.112.24

193.64.210.89

INVITE [email protected] c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0

port 5060

Bob’s terminal rings

port 5060

port 38060

200 OK c=IN IP4 193.64.210.89 m=audio 48753 RTP/AVP 3

ACK

port 5060

m Law audio

GSM

port 48753

time

• son message SIP invite contient son numéro de port et son adresse IP • il indique que Alice préfère de recevoir l’encodage PCM ulaw • Le message 200 OK de Bob indique

• son adresse IP et numéro de port pour la communication • sa préférence pour l’encodage GSM

• Les messages SIP peuvent être TCP or UDP; ici RTP/UDP.

Etablissement d’appel bis

n Rejet d’appel

n Bob peut rejeter des appels avec les réponses replies « occupé », « absent », « crédit insuffisant », ou « interdit ».

n Négociation de l’encodage: n Supposons que Bob ne

dispose pas de l’encodeur PCM ulaw.

n Bob répond par 606 Not

Acceptable Reply. Il fourni la liste des encodeurs dont il peut s’en servir.

n Alice peut ensuite envoyer un nouveau message INVITE, proposant un encodeur adapté.

Exemple d’un message SIP

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] Content-Type: application/sdp Content-Length: 885

c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0

A noter: n syntaxe HTTP n sdp = session description protocol n unicité d’identifiants Call-ID

• Dans ce cas, Alice ne connaît pas l’adresse IP de Bob. •Des serveurs intermediares sont nécessaires.

•Alice envoi et reçoit des messages SIP sur le numéro de port par défaut 5060.

• Alice indique dans l’entête Via que son client SIP envoi et reçoit par UDP.

Annuaire et localisation

n Comment appeler si on

n L’information fourni peut

connaît seulement le nom ou l’adresse mél ?

n Comment connaître l’adresse IP actuel du correspondant ? n le correspondant se déplace n il utilise le protocole DHCP n il a plusieurs appareils IP (PC,

PDA, voiture)

varier selon : n l’horaire (travail, maison) n celui qui appel (éviter qu’un appel professionnel est diriger vers le foyer) n l’état du correspondant (quand il est occupé, on dirige les appels vers le répondeur) Les serveurs SIP : n SIP registrar n SIP proxy

SIP Registrar

n 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:[email protected] To: sip:[email protected] Expires: 3600

SIP Proxy

n Alice envoi un message INVITE à son serveur proxy

n il contient l’adresse sip:[email protected]

n Le proxy est responsable for l’acheminement des

messages SIP vers le correspondant n les messages peuvent passer par plusieurs serveurs proxy

n Le correspondant envoi sa réponse via le même

ensemble de serveurs proxy.

n Le proxy fourni la réponse SIP à Alice n la réponse contient l’adresse IP de Bob

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

Appel de [email protected] vers [email protected]

(1) Jim envoi un message INVITE au SIP proxy de umass. (2) Le proxy renvoi le message vers le SIP registrar de upenn. (3) Le registrar de upenn répond avec un message REDIRECT, indiquant qu’il faut contacter [email protected]

Exemple

(cid:31)!

"89

’(cid:2)CD&

7(cid:2)’(cid:22)((cid:22)(

’(cid:6)B

(cid:31)!

"87(cid:22)9

:(cid:11);(cid:6)<

=(cid:22)>@?(cid:6)A(cid:6)A

’(cid:6)B

(cid:31)!

’(cid:6)CD&

’(cid:2)#(cid:6):

(cid:31)3

"4#(cid:11)%

’(cid:22)((cid:6))

(cid:31)!

"$#(cid:22)%

’(cid:11)((cid:6))

+(cid:4)2(cid:6),(cid:22)-

1(cid:6),(cid:11)-

/(cid:15)56-

*(cid:22)+

*(cid:22)+(cid:4),(cid:11)-

+(cid:4)*(cid:2).(cid:11)-

/(cid:6)0(cid:22)-

1(cid:2)2

(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.

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

Comparaison avec H.323

n H.323 est un autre protocole

n H.323 a été développé à

de signalisation pour l’interactive en temps réel

l’UIT (téléphonie).

n SIP a été développé à l’IETF:

n H.323 est un ensemble

Il est inspiré par HTTP.

n SIP est plus simple (et alors

plus efficace ?)

monolithique de protocoles pour le visioconférence : signalisation, enregistrement, contrôle d’admission, transport, et encodage. n SIP est un composant

modulaire. Il est compatible avec RTP. Il peut fonctionner avec d’autres protocoles et services aussi.

& & - = A ) 9 ? 9 = - = " 9 A ) 9 ? 9 ’ = 9 > - E 9