14 Examples (Exemples)
14 Examples (Exemples)
Les exemples suivants font référence à des formats de description de flux qui ne sont pas des normes, tels que RTSL. Ces exemples ne doivent pas servir de référence pour ces formats.
14.1 Media on Demand (Unicast)
Le client C demande un film aux serveurs média A (audio.example.com) et V (video.example.com). La description est stockée sur le serveur web W. Elle contient la présentation et tous les flux, codecs, types de charge utile RTP dynamiques, pile de protocoles et informations telles que la langue ou les restrictions de droits d'auteur. Elle peut aussi indiquer la chronologie du film.
Ici, le client ne s'intéresse qu'à la fin du film.
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
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
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
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
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
Même si les pistes sont sur deux serveurs et peuvent démarrer à des instants légèrement différents ou dériver, le client peut les synchroniser avec les méthodes RTP standard, en particulier l'échelle de temps des rapports d'émetteur RTCP.
14.2 Streaming of a Container file
Un fichier conteneur est une entité de stockage contenant plusieurs types de média continu pour la même présentation utilisateur final ; il représente une présentation RTSP dont les composants sont des flux RTSP. Il est souhaitable de maintenir un contexte commun côté serveur.
Cela permet un seul descripteur de stockage ouvert et un traitement équitable en cas de priorisation.
L'auteur peut aussi vouloir empêcher la récupération sélective des flux. Une URL agrégée permet de tout contrôler avec un seul message.
Exemple d'une session RTSP unique pour plusieurs flux et d'URLs agrégées. Le client C demande une présentation au serveur M ; le film est dans un fichier conteneur.
C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1
M->C: RTSP/1.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 164
v=0 o=- 2890844256 2890842807 IN IP4 172.16.2.93 s=RTSP Session i=An Example of RTSP Session Usage a=control:rtsp://foo/twister t=0 0 m=audio 0 RTP/AVP 0 a=control:rtsp://foo/twister/audio m=video 0 RTP/AVP 26 a=control:rtsp://foo/twister/video
C->M: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=8000-8001
M->C: RTSP/1.0 200 OK CSeq: 2 Transport: RTP/AVP;unicast;client_port=8000-8001; server_port=9000-9001 Session: 12345678
C->M: SETUP rtsp://foo/twister/video RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003 Session: 12345678
M->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003; server_port=9004-9005 Session: 12345678
C->M: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 4 Range: npt=0- Session: 12345678
M->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 RTP-Info: url=rtsp://foo/twister/video; seq=9810092;rtptime=3450012
C->M: PAUSE rtsp://foo/twister/video RTSP/1.0 CSeq: 5 Session: 12345678
M->C: RTSP/1.0 460 Only aggregate operation allowed CSeq: 5
C->M: PAUSE rtsp://foo/twister RTSP/1.0 CSeq: 6 Session: 12345678
M->C: RTSP/1.0 200 OK CSeq: 6 Session: 12345678
C->M: SETUP rtsp://foo/twister RTSP/1.0 CSeq: 7 Transport: RTP/AVP;unicast;client_port=10000
M->C: RTSP/1.0 459 Aggregate operation not allowed CSeq: 7
Premier échec : pause d'un seul flux interdite par le serveur. Second : l'URL agrégée ne peut pas servir à SETUP ; un message par flux est requis. Cela simplifie l'en-tête Transport pour les pare-feu.
14.3 Single Stream Container Files
Certains serveurs RTSP traitent tous les fichiers comme des « fichiers conteneur », d'autres ne supportent pas ce concept. Pour cette raison, les clients DEVRAIENT appliquer les règles de la description de session pour les URL de requête, plutôt que de supposer qu'une URL cohérente peut toujours être utilisée. Voici comment un serveur multi-flux pourrait attendre qu'un fichier à flux unique soit servi :
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
S->C RTSP/1.0 200 OK CSeq: 1 Content-base: rtsp://foo.com/test.wav/ Content-type: application/sdp Content-length: 48
v=0 o=- 872653257 872653257 IN IP4 172.16.2.187 s=mu-law wave file i=audio test t=0 0 m=audio 0 RTP/AVP 0 a=control:streamid=0
C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 Transport: RTP/AVP/UDP;unicast; client_port=6970-6971;mode=play CSeq: 2
S->C RTSP/1.0 200 OK Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; server_port=6970-6971;mode=play CSeq: 2 Session: 2034820394
C->S PLAY rtsp://foo.com/test.wav RTSP/1.0 CSeq: 3 Session: 2034820394
S->C RTSP/1.0 200 OK CSeq: 3 Session: 2034820394 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; seq=981888;rtptime=3781123
Notez l'URL différente dans SETUP, puis le retour à l'URL agrégée dans PLAY. C'est logique avec plusieurs flux et contrôle agrégé, mais peu intuitif lorsqu'il n'y a qu'un flux.
Dans ce cas particulier, il est recommandé que les serveurs tolèrent les implémentations qui envoient :
C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 CSeq: 3
Au pire, les serveurs devraient renvoyer :
S->C RTSP/1.0 460 Only aggregate operation allowed CSeq: 3
On espère aussi que les serveurs tolèrent :
C->S SETUP rtsp://foo.com/test.wav RTSP/1.0 Transport: rtp/avp/udp;client_port=6970-6971;mode=play CSeq: 2
Comme il n'y a qu'un seul flux, ce n'est pas ambigu.
14.4 Live Media Presentation Using Multicast
Le serveur M choisit l'adresse et le port multicast. Le web ne contient qu'un pointeur ; M détient la description complète.
C->W: GET /concert.sdp HTTP/1.1 Host: www.example.com
W->C: HTTP/1.1 200 OK Content-Type: application/x-rtsl
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 1
M->C: RTSP/1.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 44
v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session m=audio 3456 RTP/AVP 0 a=control:rtsp://live.example.com/concert/audio c=IN IP4 224.2.0.1/16
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 2
Transport: RTP/AVP;multicast
M->C: RTSP/1.0 200 OK CSeq: 2 Transport: RTP/AVP;multicast;destination=224.2.0.1; port=3456-3457;ttl=16 Session: 0456804596
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 3 Session: 0456804596
M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596
14.5 Playing media into an existing session
Le participant C veut que M rejoue une démo dans une conférence existante ; adresses et clés viennent de la conférence. Les ACK simples sont omis.
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
C->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]%20Starr
M->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: 91389234234
M->C: RTSP/1.0 200 OK CSeq: 3
14.6 Recording
C demande à M d'enregistrer audio et vidéo de la réunion ; ANNOUNCE fournit les métadonnées.
C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 CSeq: 90 Content-Type: application/sdp Content-Length: 121
v=0 o=camera1 3080117314 3080118787 IN IP4 195.27.192.36 s=IETF Meeting, Munich - 1 i=The thirty-ninth IETF meeting will be held in Munich, Germany u=http://www.ietf.org/meetings/Munich.html e=IETF Channel 1 [email protected] p=IETF Channel 1 +49-172-2312 451 c=IN IP4 224.0.1.11/127 t=3080271600 3080703600 a=tool:sdr v2.4a6 a=type:test m=audio 21010 RTP/AVP 5 c=IN IP4 224.0.1.11/127 a=ptime:40 m=video 61010 RTP/AVP 31 c=IN IP4 224.0.1.12/127
M->C: RTSP/1.0 200 OK CSeq: 90
C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0 CSeq: 91 Transport: RTP/AVP;multicast;destination=224.0.1.11; port=21010-21011;mode=record;ttl=127
M->C: RTSP/1.0 200 OK CSeq: 91 Session: 50887676 Transport: RTP/AVP;multicast;destination=224.0.1.11; port=21010-21011;mode=record;ttl=127
C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0 CSeq: 92 Session: 50887676 Transport: RTP/AVP;multicast;destination=224.0.1.12; port=61010-61011;mode=record;ttl=127
M->C: RTSP/1.0 200 OK CSeq: 92 Transport: RTP/AVP;multicast;destination=224.0.1.12; port=61010-61011;mode=record;ttl=127
C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 CSeq: 93 Session: 50887676 Range: clock=19961110T1925-19961110T2015
M->C: RTSP/1.0 200 OK CSeq: 93