Embed Size (px)
Citation preview
Le streaming des média à la demande sur Internet
S. Natkin
Février 2005
Objectifs
• Transfert de flux de données multimédia synchrones en diffusion, pour être joués en temps réel
• Par opposition au téléchargement des média
• Sans interactions « rapides »: radio pas téléphone
Application MPEG 4:critères de classification
• Contraintes temporellesLes applications sont classées selon qu'elles sont en temps réel ou non.
• Symétrie des moyens de transmissionLes applications sont soit symétriques, soit asymétriques.
• InteractivitéLes applications peuvent être interactives ou non interactives.
Application MPEG 4:les classes
Temps réel symétrique interactive classe 1
non interactive sans application
non symétrique interactive classe 2
non interactive sans application
non temps réel symétrique interactive classe 3
non interactive sans application
non symétrique interactive classe 4
non interactive classe 5
Application MPEG 4:Exemple classe 1
• Visiotéléphonie
• Vidéotéléphonie multiple
• Vidéoconférence
• Travail de groupe
• Classe distante symétrique
• Expertise distante symétrique
Application MPEG 4:Exemple classe 2
• Expertise distante asymétrique
• Contrôle distant et télésurveillance
• Collecte d'informations
• Classe distante asymétrique
Application MPEG 4:Exemple classe 3 et 4
Classe 3• Messages multimédia
Classe 4
• Récupération de bases d'informations
• Jeux
Description d’une session cliente de type SMIL
Architecture type
Serveur vidéo 1Flux S3
Serveur audio 1Flux S1
Serveur audio 2Flux S2
PC 1 :S1+S2
PC2 : S1+S2+S3
Téléphone : S1
TVI : S3
Terminologie « floue »revisitée par SN
• Objet média : unité continue et homogène de données d’un type définit existant (fichier) ou créé par captation ou synthèse en temps réel
• Flux (stream) multimédia: transfert de données résultant du transport d’un objet média
• Session : Vue homogéne pour un utilisateur ou un ensemble d’utilisateur interagissant via le réseau et utilisant des objets mutimédia des ressources disponibles et opérations possibles sur ces ressources
• Conférence: Ensemble d’utilisateurs ou d’entités informatiques ayant en commun un ou plusieurs flux multimédia
Synchronisation
• La synchronisation peut être relative: démarrer le flux audio1 7 s après la fin du flux vidéo2
• Ou absolue :démarrer le flux audio1 au time code 00:07:00 du flux vidéo2
• Evènementielle : démarrer le flux audio1 lorsque l’utilisateur clique sur le bouton start
• Ou continue: le time code du flux audio et vidéo doivent être égales
Sources
• Les sources des media peuvent être multiples (locales ou téléchargées, sur des serveurs distincts)
• Les capacités de traitement des serveurs inégales et peu prévisibles
• Les modes de compression sont variables: pré compression ou compression à la demande, adaptatives ou non adaptative
Problèmes techniques• Assurer sur le client un débit constant• Les messages étant traités dans l’ordre d’émission• Délivrés selon des unités d’échantillonnage (une image un
échantillon sonore)• Selon une séquence synchrone• et en synchronisant les différentes sources• sur un réseau dont la technologie gère très mal les garanties de
qualité de service• gérer la diffusion: groupes de serveurs vers groupes de clients
Plus accessoirement:• Décrire les flux et sources multimédia• Assurer la sécurité du transfert (gestion des droits sur les media)• Optimiser l’utilisation des ressources réseau
Architecture de base
Compresseuradaptatif
CompresseurNon adaptatif
Protocole de streaming
Décompresseur
Protocole de signalisation
Mesure de QosMesure de Qos
Flux noncompressé
Protocole de sessionDe streaming
Serveur Client
Une vue générale des protocoles temps réel
– Protocole de description du flux et de session : SDP, SMIL...
– Contôle du flux: RTSP
– Transport: RTP
– Réservation des ressources: RSVP, DiffServ
Architecture Internet
• and the result…
Problème de synchronisation du flux
Internet est un réseau dont les performances sont très variables : les datagrammes peuvent traverser un nombre très variables de routeurs plus ou moins chargés. Les temps de propagation entre deux nœuds identiques de deux datgrammes identiques datagrammes peuvent varier de façon considérable (dans un rapport 1:100)
Exemple
Emission délai réception Diffusion jigue0 4 4 7 04 14 18 21 108 5 13 25 0
12 9 21 29 016 19 35 37 418 20 38 47 622 9 31 51 024 5 29 55 028 5 33 59 0
Délai moyen 10 ms, temps de décompression 3ms
Solution le bidon percé
• Comment transformer un débit asynchrone en un débit synchrone
Principe du protocole
• Mesure du temps de traversée max T
• Chargement d’un tampon 2 a 3 T
• Démarrage de l’écoute
tampon
Flux entrant
ecoute
Exemple
Emission délai réception Ddiff File Fdif1 0 4 4 35 1,2,3,4,5,7,8 382 4 14 18 39 2,3,4,5,7,8,9 423 8 5 13 43 3,4,5,6,7,8,9 464 12 9 21 47 4,5,6,7,8,9 505 16 19 35 51 5,6,7,8,9 546 20 20 40 55 6,7,8,9 587 24 9 33 59 7,8,9 628 28 5 33 63 8,9 669 32 5 37 67 9 70
Exemple qui ne marche pas
Emission délai réception Ddiff File Fdif1 0 4 4 21 1,2,3,4 242 4 14 18 25 2,3,4 283 8 5 13 29 3,4 324 12 9 21 33 4 365 16 19 35 38 5,7,8 416 20 20 40 43 6,7,8,9 467 24 9 33 47 7,8,9 508 28 5 33 51 8,9 549 32 5 37 55 9 58
1
1
Mesure du QOS
• Nombre de paquets arrivés en retard (Jigue)
• Nombre de paquet perdus
• Délais A/R
• ….
Compensation d’erreur
• Pertes de messages• Il est souvent préférable de ne rien faire que de
retarder le flux• Donc peut difficilement reposer sur une technique de
détection par acquit et réémission (en général UDP et IP)
• A fortiori en diffusion• Certains messages peuvent être perdus sans trop de
dégats (les trames B en MPEG2 par exemple)• Sinon il faut utiliser d’autre techniques
Compensation d’erreurpar entrelacement
Dans RealAudioTampons de 240 ms:12 blocs de 20 ms
D’ou une attente d’au moins 5,2 s
Compensation d’erreurpar code correcteur d’erreur
Différentes autres approches avec des parités horizontales et verticales (comparable au RAID)
Historique
• IETF Audio/Video Transport WG– RTPv1 RFC 1889 (January 1996)– RTPv2 draft-ietf-avt-rtp-new-09.txt (March 2001)
• Real-Time Protocol (RTP)– « a framing protocol for real-time applications »– Ne gère aucun mécanisme de QOS pour le temps réel
• Real-Time Control Protocol (RTCP)– Mécanisme de mesure et de contrôle d’effort (comme
ICMP) sans aucune garantie
Principes de conception
• Flexible mécanismes de bases qui peuvent être instanciés (H261, MPEG1/2/...)
• Peut s’appuyer sur des protocoles variés(UDP/IP, réseaux ATM privés...)
• Support de la diffusion: unicast, multicast, de 2 to
• Sépare le contrôle et les données, certaines fonctions peuvent être déléguées à d’autres protocoles (i.e. RTSP)
• Un scénario:– A working group obtains an IP multicast address and a pair
of ports through some allocation mechanism.– One port for audio, one for control– The address and the ports are distributed to intended
participants.– The participants send audio data in small chucks, 20ms
duration. Each chuck of audio data is preceded with a RTP header, which indicates the type of encoding.
– The Internet may occasionally lose or reorder packets or delay the packet in variable amount time. To help the receiver reconstruct the timing produced by the sender, RTP header also include timing and sequence number information.
– Since the member may join and leave a group dynamically, it is useful to know who is participating and the audio quality at a given time. This task is done through RTCP.
Fonctions de gestion des donneés dans RTP
Label de contenu (content labelling)• Identification de la source • Détection des pertes• reséquencement
Gestion du temps• synchronisation intra-média : principe du bidon
percé• inter-media synchronisation: gestion d’un time
code commun inter-média
Utilisation type
– Sur UDP– Port UDP déterminé par ailleurs– port RTCP = port UDP pour RTP + 1– Un média par session RTP/RTCP (i.e. port
pair)
Indicateur de temps
• Temps RTP – Valeur initiale aléatoire et indépendante pour chaque flux– RTP timestamp dans chaque message– Incrémentée du temps séparant la date de l’échantillon
courant moins la date de l’échantillon précédent • Temps NTP (wallclock time)
– temps absolu (format de Network Time Protocol)– présent dans chaque rapport RTCP de l’émetteur
(Sender Report)– destiné à la synchronisation inter média
PDU 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 |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| contributing source (CSRC) identifiers || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| payload (audio, video...) || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ...| padding | count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Contenu des champs
• P: Padding (1 bit), si les données sont plus petites que la taille du message (alignements à 4 octets).
• X: Extension(1 bit), l’en tête fixe est suivi d’un en tête variable (dépendant des applications).
• M: Marker, pour distinguer les évènements importants.• PT: Payload type, type de contenu (PCM, ADPCM, etc)• Timestamps: date RTP associée au premier octet de l’échantillon• Sequence number field: Incrémenté à chaque PDU• Synchronization SouRCe (SSRC)
– Identifie la source de façon unique– Choisie aléatoirement (pas de nom unique négocié et faible
probabilité de collisiosn• Contributing SouRCe (CSRC) : Liste (dont le cardinal est donné par CC)
qui identifie les sources avant traitement par un “mixer”
Mixers et Translators
• Mixers– Multiplexe les flots de plusieurs média en un seul
pour diminuer le débit sur un réseau commuté– Peut modifier le codage et la compression– Définit une nouvelle source et un nouveau SSRC;
SSRCs original dans la liste
• Translators– Transformateur de protocole, translateur
d’adresse (firewall…)– Conserve les flots et les SSRCs originaux
Mixer
end system 1
end system 2
mixer end system 3from ES1: SSRC=6
from ES2: SSRC=23from M: SSRC=52CSRC list={6, 23}
On ne mixe que des données de même type (audio, vidéo)Facilite la diffusion par multiplexage en cas de voies non homogènes
Translator
end system 1
end system 2
transl.1from ES1: SSRC=6
from ES2: SSRC=23transl.2
from ES2: SSRC=23from ES1: SSRC=6
authorized tunnel
firewallfrom ES2: SSRC=23from ES1: SSRC=6
Généralités sur RTCP
Transmission périodique de messages de contrôle qui servent– De mesure de la QOS– de mesure d’écoute (nombre de récepteur– A identifier une source par un nom unique
CNAME (par exemple user@host) qui ne change pas (contrairement au SSRC)
Permet d’établir une relation entre plusieurs flux de même origine sur le client
PDU RTCP• SR sender reports
statistiques (données transmises tx et données reçues rx) des émetteurs (serveurs) actifs
• RR receiver reports
statistiques rx des récepteurs ou des émetteurs actifs au-delà de 31 sources
• SDES source description,
comprenant CNAME• BYE Départ du groupe• APP
PDU pour des extensions spécifiques aux application
RTCP généralitées
• Distribution– Comme RTP c’est une diffusion de nm – Plusieurs messages RTCP peuvent être
concaténés par des translators/mixers (compound packet)
• Gestion de la charge générée– Charge RTCP < 5% du total RTP+RTCP
basée sur l’évaluation du nombre de participantpériode RTCP = f(nombre de participants)
– Au moins 25% de la charge RTCP est destiné aux information issues de la source
Permet, entre autre d’identifie rapidement les sources
PDU SR
– SSRC de la source– NTP timestamp date d’émission du rapport– RTP timestamp estampille correspondante RTP– packet count nombre total de messages envoyés– octet count– Suivi par une liste de rapport récepteur…
– exemple:
SRsenderreport
receiverreport
receiverreportS
SR
C
SS
RC
SS
RC
source 2 source 3
RTCP packet
• SR: sender report
V=2 p rc PT=SR=200 length SSRC of sender NTP timestamp, MSW NTP timestamp, LSW RTP timestamp Sender’s packet count Sender’s octet count SSRC_1 (SSRC of first source), block 1 Sender’s packet count fraction lost cumulative number of packets lost extended highest sequence number received interarrival jitter last SR (LSR) delay since last SR (DLSR) SSRC_2 (SSRC of second source), begin block 2 …. profile-specific extensions
• RR: receiver report
V=2 p rc PR=RR=201 length
SSRC of sender
SSRC of first source, begin block 1
Fraction lost (FL) cumlative number of packets lost
extended highest sequence number received
interarrival jitter
last SR (LSR)
delay since last SR (DLSR)
SSRC of second source, begin block 2
…….
profile-specific extensions
PDU RR– SSRC de la source identifie la source sur laquelle porte le
rapport– fraction lost depuis l’envoi de la dernière PDU RR (SR)
(= int(256*lost/expected))– cumul des messages perdus– Plus grand numéro de séquence de messages reçus
Permet d’estimer expected– interarrival jitter J=J+(|D(i-1,i)|-J)/16
avec D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
– LSR date de la dernière SR reçue– DLSR temps écoulé depuis la réception de cette SR
Délai AR à réception d’une RR: Date de réception-LSR-DLSR
PDU SDES
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| SC | PT=SDES=202 | length | header
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
| SSRC/CSRC_1 | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_2 | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Champs de SDES
• Pour chaque source peut contenir – CNAME– NAME nom d’utilisateur– EMAIL – PHONE– LOC (localisation géogra^hique)– TOOL (application)– NOTE – PRIV (extension privé)
Example of RTCP compound packet
SRsenderreport
receiverreport
receiverreportS
SR
C
SS
RC
SS
RC
source 2 source 3
RTCP packet 1
SDES CNAME PHONE
SS
RC
RTCP packet 2
compound packet(single UDP datagram)
profiles RTP
RTP peut être instancié pour chaque média– Exemple: MPEG1/2– Selon la recommandation
• RFC 2736, December 1999– Avec pour but
« every packet received must be usefull !!! »– Pour adapter les caractéristique du réseau (UDP/IP
en particulier) aux contraintes du flux: ce qui est inutile, ce qui est important
Exemple de problème à résoudre: gestion de la fragmentation
application data unit
fragment 1 fragment 2 fragment 3
application
RTP
network tx
fragment 2fragment 1
LOST
RTP
uncomplete data!!!application useless!!!
Src
Rx
Implantations
Bell Labs, Columbia Univ., Massachusetts Univ. RTP Library
Version: 3.0 Beta (4/1997)
An RTP implementations by the standard authors, source code available.
http://www.bell-labs.com/topic/swdist/• Limburgs Universitair Centrum JVOIPLIB
Version: 1.0 (11/2000)
JVOIPLIB is an object-oriented Voice over IP (VoIP) library written in C++.
http://lumumba.luc.ac.be/jori/jvoiplib/jvoiplib.html • JavaSoft/Sun Microsystems Java Media Framework
RTP application and library for audio/video session playback over IP networks.
http://java.sun.com/products/java-media • Limburgs Universitair Centrum and Universiteit Maastricht JRTPLIB
Version: 2.4 (7/2000)
JRTPLIB (Jori's RTP library) is a C++ library.
http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html • Live.com LIVE.COM Streaming Media
Version: 1.0 (October 2000)
This C++ code, distributed under a LGPL licence, forms a set of libraries that can be used within RTP/RTCP streaming
applications, or can be extended to support additional media types and codecs (in addition to MP3 audio).
http://live.sourceforge.net/• UCL Common Multimedia Library
Version: 1.2.8 (May 2001)
The UCL common multimedia library implements a number of algorithms and protocols (including RTP) needed by a number of our applications.
http://www-mice.cs.ucl.ac.uk/multimedia/software/common/index.html
RTSP
Généralités RTSP
• IETF standard– RFC 2326
• Real-Time Streaming Protocol– Agit comme un gestionnaire réparti des
conférences MM
• Réalise les operations suivantes:– Recherche d’un média sur un serveur– Gestion des participants à une conférence– Suivi du déroulemnet
Principe du protocole (2)
– Mode caractère– Independant du protocole support– Intégre toute syntaxe de description (sdp, xml,
etc.)– Ressemble à HTTP mais
• Requêtes dans le deux sens (clients serveur)• Contexte de session coté serveur• Donnée transférée par une autre voie (hors bande)
– En point à point ou en diffusion
URL RTSP
• présentationrtsp://media.example.com:554/twister
• Une piste audio de la présentationrtsp://media.example.com:554/twister/audio
• Hierarchie des noms de présentation hiérachie des média hiérachie des fichiers
Exemple d’échange
PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video;
seq=12312232;rtptime=78712811
seq# for request/response pair
session identifier
method to apply URL RTSP version
play starting at that offset for anundefined durationstatus codeversion
seq# for request/response pair
session identifier
reason phrase
Méthodes RTSP• Principales
– SETUP: Allocation par le serveur des ressources et début de session– PLAY: Lire un flux– PAUSE: Arrêt temporaire de lecture– TEARDOWN: Fin de session, libération des ressources
• Annexes– OPTIONS: Liste des méthodes utilisable– ANNOUNCE: modifie la description d’un objet média– DESCRIBE: demande la descrition détaillée d’un objet média– RECORD: Demande d’enregistrement d’un flux– REDIRECT: re direction d’un client vers un nouveau serveur– SET_PARAMETER:d’un périphérique ou de l’encodage d’un média
Paramètres• Accept media description formats• Accept-Encoding encoding of media format• Accept-Language human language• Authorization basic and digest authentication• Bandwidth client bandwidth available• Conference conference identifier• From name of requestor• If-Modified-Since conditional retrieval• Range time range to play• Referer how did we get here?• Scale (play time)/(real time)• Speed speed-up delivery• User-Agent software• Cache Possibilté de stocker l’objet média en cache
Intégration dans le Web
1. web avec le guide des programmes 2. qui pointe sur une description de la preésentation (say,
SMIL):<session>
<group><track src="rtsp://audio.mtv.com/movie"><track src="rtsp://video.mtv.com/movie">
</group>
</session>3. RTSP gère la session4. RSVP réserve les resources5. RTP transporte les données6. RTCP contrôle le transport
Exemple (1): media à la demande, point à point
videoserver
audioserver
media descr.web serverclient
step 1: get description (in SDP format)
step 2: open streams with RTSP
step 3: play
step 4: teardown
CW A V
Exemple (2)
clientC
web server
W
mediaserversA & V
HTTP GET
presentation description (sdp)
SETUP
PLAY
RTP audio/video
RTCP
TEARDOWN
Example (2) : réception des descrpteurs via HTTP
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
Example (3): ouverture des flux de média
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
A->C: RTSP/1.0 200 OK CSeq: 1 Session: 12345678 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; server_port=5000-5001
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
V->C: RTSP/1.0 200 OK CSeq: 1 Session: 23456789 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; server_port=5002-5003
Exemple (4) play
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video;
seq=12312232;rtptime=78712811
Exemple (5) play
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
seq=876655;rtptime=1032181
– NB: use standard RTP synchronization methods for lip-sync!
Exemple6, Teardown
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 3
Session: 12345678
A->C: RTSP/1.0 200 OK
CSeq: 3
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 3
Session: 23456789
V->C: RTSP/1.0 200 OK
CSeq: 3
Gestion du temps (1)
• NPT (normal play time)– position relative au début de l’objet ou de la
présentation spécifiée– deuxformats:
hours:minutes:seconds.subseconds
seconds.subseconds
– exemple:npt= 10:07:00- 10:07:33
npt=121.45-125
Gestion du temps (2)
• SMPTE– relative to au début d’un objet média– format:
hours:minutes:seconds:frames.subframes
– exemple:smpte-30-drop=10:07:00-10:07:33:05.01
• Temps absolu– selon ISO 8601, using UTC/GMT– exemple: current time is 20010829T114501.00Z
date(yyyymmdd)
heure(hhmmss.sub)
Gestion du temps (3)
• Permet une gestion du temps absolu – exemple:
start playing movie at 20010829T114501.00Z, at npt= 10:07:00
– Peut servir à la sychronisation répartie– A la précision de NTP près
• Permet une certaine forme d’édition des média (genre smil)
communications RTSP
• Trois modes d’utilisation du transport dans le sens client/serveur– connexion de transport persistante (TCP) pour une suite de – Une connexion (TCP) par requêtes/réponses (mode HTTP 1.0)– Sans connexion (UDP)
• Définit par l’ URL:– « rtsp » connexion de transport persistante– « rtspu » sans connexion
• Seul les connexions de transports persistantes sont utilisées dans le sens serveur/client
Invitation
Invite un serveur d’ajouter un flux d’un nouveau media dans une présentation existante
client utilise SETUP et les patamètres transport/conference
Invitation d’un serveur d’ajouter un objet sonore à une connexion
C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 1 Accept: application/sdp
M->C: RTSP/1.0 200 1 OK Content-type: application/sdp Content-Length: 44
v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session i=See above t=0 0 m=audio 0 RTP/AVP 0
suiteC->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2 Transport: RTP/AVP;multicast;destination=225.219.201.15; port=7000-7001;ttl=127 Conference: [email protected]%20StarrM->C: RTSP/1.0 200 OK CSeq: 2 Transport: RTP/AVP;multicast;destination=225.219.201.15; port=7000-7001;ttl=127 Session: 91389234234 Conference: [email protected]%20Starr
C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 3 Session: 91389234234M->C: RTSP/1.0 200 OK CSeq: 3
Implémentations (by Schulzrinne)• Apple Darwin QuickTime Streaming Server
server MacOS, unix SDP open source, full RTP/RTSP server • Apple QuickTime 4
client MacOS, Windows SDP QuickTime 4 also supports importing SDP files that describe multicasts, with standard decoders.
• Cern Wrtp • Columbia University rtspd
server NT, Solaris SDP no container files • Entera Entera Lightweight Streaming Application
server Window, unix SDP • IBM RTSP Toolkit • KOM TU-Damstadt KOM-Player
player Linux, AIX SDP MPEG-1 System; alternative RTSP server for IBM's VideoCharger • nCUBE Corporation rtspsrv
server Transit SDP Delivers MPEG-2 video over ATM, QAM, or DVB-ASI; no RTP delivery. • Oracle Corporation Oracle Video Server
client, server Windows, unix SDP MPEG-1 Systems, MPEG-2 Transport, AVI codecs. ATM, QAM, IP, DVB-ASI. No RTP delivery.
• Real Networks Real Networks proxy kit (firewall)
• Real Networks Real Networks server Windows, unix SDP, RTSL
• Real Networks RealServer G2 server Windows, unix SDP, SMIL supports RTP for RTP-based clients
• Real Networks "Hosting" server server Windows, unix Streams .au and .wav files over RTP when configured for multicast.
• Sun JMF 2.1 client Solaris, Windows, MacOS
• Sun MediaCentral server server Solaris
• Vovida server Linux Open source, RECORD and PLAY
Bibliographie
• General
– Schulzrinne, IRT (Internet Real-Time) lab, http://www.cs.columbia.edu/~hgs/research/IRT
• RTP
– Schulzrinne, Casner, Frederick, Jacobson, « RTP, a tranport protocol for real-time applications », IETF, work in progress, <draft-ietf-avt-rtp-new-09.txt>, March 2001.
– Schulzrinne, RTP home page, http://www.cs.columbia.edu/~hgs/rtp/
• RTSP
– Schulzrinne, Rao, Lanphier, « Real-Time Streaming Protocol (RTSP) », IETF, Request For Comments 2327, April 1998.
– Schulzrinne, RTSP home page, http://www.cs.columbia.edu/ ~hgs/rtsp/
