12 Header Field Definitions (Définitions des champs d'en-tête)
12 Header Field Definitions (Définitions des champs d'en-tête)
Les champs d'en-tête HTTP/1.1 [2] ou autres champs non standard non listés ici n'ont actuellement aucune signification bien définie et DEVRAIENT être ignorés par le destinataire.
Le tableau 3 résume les champs d'en-tête utilisés par RTSP. Le type « g » désigne les en-têtes généraux de requête présents dans les requêtes et les réponses, le type « R » les en-têtes de requête, le type « r » les en-têtes de réponse, et le type « e » les champs d'en-tête d'entité. Les champs marqués « req. » dans la colonne « support » DOIVENT être implémentés par le destinataire pour une méthode donnée, tandis que ceux marqués « opt. » sont facultatifs. Notez que tous les champs marqués « req. » ne seront pas envoyés dans chaque requête de ce type. « req. » signifie seulement que le client (pour les en-têtes de réponse) et le serveur (pour les en-têtes de requête) DOIVENT implémenter les champs. La dernière colonne liste la méthode pour laquelle ce champ d'en-tête est pertinent ; la mention « entity » renvoie à toutes les méthodes qui renvoient un corps de message. Dans cette spécification, DESCRIBE et GET_PARAMETER relèvent de cette classe.
| Header | type | support | methods |
|---|---|---|---|
| Accept | R | opt. | entity |
| Accept-Encoding | R | opt. | entity |
| Accept-Language | R | opt. | all |
| Allow | r | opt. | all |
| Authorization | R | opt. | all |
| Bandwidth | R | opt. | all |
| Blocksize | R | opt. | all but OPTIONS, TEARDOWN |
| Cache-Control | g | opt. | SETUP |
| Conference | R | opt. | SETUP |
| Connection | g | req. | all |
| Content-Base | e | opt. | entity |
| Content-Encoding | e | req. | SET_PARAMETER, DESCRIBE, ANNOUNCE |
| Content-Language | e | req. | DESCRIBE, ANNOUNCE |
| Content-Length | e | req. | SET_PARAMETER, ANNOUNCE, entity |
| Content-Location | e | opt. | entity |
| Content-Type | e | req. | SET_PARAMETER, ANNOUNCE |
| Content-Type | r | req. | entity |
| CSeq | g | req. | all |
| Date | g | opt. | all |
| Expires | e | opt. | DESCRIBE, ANNOUNCE |
| From | R | opt. | all |
| If-Modified-Since | R | opt. | DESCRIBE, SETUP |
| Last-Modified | e | opt. | entity |
| Proxy-Authenticate | r | opt. | all |
| Proxy-Require | R | req. | all |
| Public | r | opt. | all |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Range | r | opt. | PLAY, PAUSE, RECORD |
| Referer | R | opt. | all |
| Require | R | req. | all |
| Retry-After | r | opt. | all |
| RTP-Info | r | req. | PLAY |
| Scale | Rr | opt. | PLAY, RECORD |
| Session | Rr | req. | all but SETUP, OPTIONS |
| Server | r | opt. | all |
| Speed | Rr | opt. | PLAY |
| Transport | Rr | req. | SETUP |
| Unsupported | r | req. | all |
| User-Agent | R | opt. | all |
| Via | g | opt. | all |
| WWW-Authenticate | r | opt. | all |
Vue d'ensemble des champs d'en-tête RTSP
12.1 Accept
Le champ d'en-tête de requête Accept peut servir à indiquer certains types de contenu de description de présentation acceptables pour la réponse.
Le paramètre « level » pour les descriptions de présentation est correctement défini dans l'enregistrement du type MIME, pas ici.
Voir [H14.1] pour la syntaxe.
Exemple d'utilisation : Accept: application/rtsl, application/sdp;level=2
12.2 Accept-Encoding
Voir [H14.3].
12.3 Accept-Language
Voir [H14.4]. Notez que la langue indiquée s'applique à la description de présentation et aux éventuelles phrases de raison, pas au contenu média.
12.4 Allow
Le champ d'en-tête de réponse Allow liste les méthodes prises en charge par la ressource identifiée par l'URI de requête. Ce champ vise à informer strictement le destinataire des méthodes valides associées à la ressource. Un champ Allow DOIT être présent dans une réponse 405 (Method not allowed).
Exemple : Allow: SETUP, PLAY, RECORD, SET_PARAMETER
12.5 Authorization
Voir [H14.8].
12.6 Bandwidth
Le champ d'en-tête de requête Bandwidth décrit la bande passante estimée disponible pour le client, exprimée comme un entier positif en bits par seconde. La bande passante disponible peut varier pendant une session RTSP, par ex. en raison d'un réapprentissage du modem.
Bandwidth = "Bandwidth" ":" 1*DIGIT
Exemple : Bandwidth: 4000
12.7 Blocksize
Ce champ d'en-tête de requête est envoyé du client au serveur média pour demander une taille de paquet média particulière. Cette taille n'inclut pas les en-têtes des couches inférieures telles qu'IP, UDP ou RTP. Le serveur peut librement utiliser une taille inférieure à celle demandée. Le serveur PEUT tronquer cette taille au multiple le plus proche de la taille minimale spécifique au média, ou la remplacer par la taille spécifique au média si nécessaire. La taille de bloc DOIT être un nombre décimal positif, mesuré en octets. Le serveur ne renvoie une erreur (416) que si la valeur est syntaxiquement invalide.
12.8 Cache-Control
Le champ d'en-tête général Cache-Control sert à spécifier des directives que tous les mécanismes de mise en cache le long de la chaîne requête/réponse DOIVENT respecter.
Les directives de cache doivent être relayées par une application proxy ou passerelle, quelle que soit leur importance pour cette application, car elles peuvent s'appliquer à tous les destinataires de la chaîne. Il n'est pas possible de spécifier une directive de cache pour un cache particulier.
Cache-Control ne devrait être spécifié que dans une requête SETUP et sa réponse. Remarque : Cache-Control ne régit pas la mise en cache des réponses comme en HTTP, mais celle du flux identifié par la requête SETUP. Les réponses aux requêtes RTSP ne sont pas mises en cache, sauf les réponses à DESCRIBE.
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive |
cache-response-directive
cache-request-directive = "no-cache" |
"max-stale" |
"min-fresh" |
"only-if-cached" |
cache-extension
cache-response-directive = "public" |
"private" |
"no-cache" |
"no-transform" |
"must-revalidate" |
"proxy-revalidate" |
"max-age" "=" delta-seconds |
cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
no-cache : indique que le flux média NE DOIT PAS être mis en cache nulle part. Cela permet à un serveur d'origine d'empêcher la mise en cache même par des caches configurés pour renvoyer des réponses périmées.
public : indique que le flux média peut être mis en cache par tout cache.
private : indique que le flux média est destiné à un seul utilisateur et NE DOIT PAS être mis en cache par un cache partagé. Un cache privé (non partagé) peut mettre le flux en cache.
no-transform : un cache intermédiaire (proxy) peut trouver utile de convertir le type média d'un flux. Un proxy peut par exemple convertir entre formats vidéo pour économiser l'espace de cache ou réduire le trafic sur un lien lent. Des problèmes opérationnels graves peuvent toutefois survenir lorsque ces transformations ont été appliquées à des flux destinés à certains types d'applications. Par exemple, les applications d'imagerie médicale, d'analyse de données scientifiques et celles utilisant une authentification de bout en bout dépendent toutes de la réception d'un flux strictement identique bit à bit au corps d'entité d'origine. Par conséquent, si une réponse inclut la directive no-transform, un cache ou proxy intermédiaire NE DOIT PAS modifier l'encodage du flux. Contrairement à HTTP, RTSP ne prévoit pas à ce stade de transformation partielle, par ex. une traduction dans une autre langue.
only-if-cached : dans certains cas, par ex. en période de connectivité réseau extrêmement médiocre, un client peut vouloir qu'un cache ne renvoie que les flux média qu'il stocke actuellement et qu'il ne les reçoive pas du serveur d'origine. Pour cela, le client peut inclure la directive only-if-cached dans une requête. Si un cache reçoit cette directive, il DEVRAIT soit répondre en utilisant un flux média mis en cache cohérent avec les autres contraintes de la requête, soit répondre avec le statut 504 (Gateway Timeout). Toutefois, si un groupe de caches est exploité comme un système unifié avec une bonne connectivité interne, une telle requête PEUT être transmise à l'intérieur de ce groupe de caches.
max-stale : le client accepte un flux ayant dépassé son expiration. Si une valeur est assignée, l'écart maximal en secondes est borné ; sinon, toute réponse périmée est acceptée.
min-fresh : le client accepte un flux dont la durée de fraîcheur restante est au moins égale à l'âge actuel plus le nombre de secondes indiqué.
must-revalidate : lorsque la directive est présente dans une réponse SETUP reçue par un cache, ce cache NE DOIT PAS utiliser l'entrée après qu'elle soit devenue périmée sans revalidation avec l'origine, dès lors que la réponse en cache est périmée d'après Expires du serveur d'origine.
12.9 Conference
Ce champ d'en-tête de requête établit une connexion logique entre une conférence préétablie et un flux RTSP. L'identifiant de conférence ne doit pas changer pour la même session RTSP.
Conference = "Conference" ":" conference-id
Exemple : Conference: [email protected]%20Starr
Le code de réponse 452 (Conference Not Found) est renvoyé si l'identifiant est invalide.
12.10 Connection
Voir [H14.10].
12.11 Content-Base
Voir [H14.11].
12.12 Content-Encoding
Voir [H14.12].
12.13 Content-Language
Voir [H14.13].
12.14 Content-Length
Ce champ contient la longueur du contenu de la méthode (après le double CRLF suivant le dernier en-tête). Contrairement à HTTP, il DOIT être inclus dans tous les messages portant du contenu au-delà de la partie en-tête. S'il manque, une valeur par défaut de zéro est supposée. Interprétation selon [H14.14].
12.15 Content-Location
Voir [H14.15].
12.16 Content-Type
Voir [H14.18]. Les types de contenu adaptés à RTSP seront en pratique souvent limités aux descriptions de présentation et aux types paramètre-valeur.
12.17 CSeq
Le champ CSeq spécifie le numéro de séquence pour une paire requête-réponse RTSP. Ce champ DOIT être présent dans toutes les requêtes et réponses. Pour chaque requête RTSP avec un numéro donné, il existe une réponse correspondante avec le même numéro. Toute retransmission DOIT conserver le même numéro (pas d'incrément pour la même requête).
12.18 Date
Voir [H14.19].
12.19 Expires
Le champ d'en-tête d'entité Expires donne une date et une heure après lesquelles la description ou le flux média doit être considéré comme périmé. L'interprétation dépend de la méthode.
Réponse DESCRIBE : indique après quand la description est périmée.
Une entrée de cache périmée ne doit en principe pas être renvoyée sans validation avec l'origine. Voir la section 13.
La présence d'Expires n'implique pas que la ressource changera ou cessera d'exister à ce moment.
Le format est une date-heure absolue HTTP-date [H3.3] ; il DOIT être au format RFC1123-date :
Expires = "Expires" ":" HTTP-date
Exemple : Expires: Thu, 01 Dec 1994 16:00:00 GMT
Les clients et caches RTSP/1.0 DOIVENT traiter les formats de date invalides, y compris « 0 », comme étant dans le passé.
Pour marquer une réponse comme déjà expirée, utiliser une date Expires égale à Date. Pour « jamais », environ un an dans le futur. Les serveurs RTSP/1.0 ne devraient pas envoyer Expires à plus d'un an.
Sur un flux non mis en cache par défaut, un Expires futur indique que le flux est mis en cache, sauf indication contraire par Cache-Control (section 12.8).
12.20 From
Voir [H14.22].
12.21 Host
Ce champ d'en-tête HTTP n'est pas nécessaire pour RTSP. S'il est envoyé, il devrait être ignoré silencieusement.
12.22 If-Match
Voir [H14.25].
Particulièrement utile pour l'intégrité de la description de présentation, qu'elle soit récupérée hors RTSP (HTTP) ou garantie entre DESCRIBE et SETUP.
L'identifiant est opaque et non lié à un langage de description particulier.
12.23 If-Modified-Since
Utilisé avec DESCRIBE et SETUP pour les rendre conditionnels. Si la variante n'a pas été modifiée depuis la date indiquée, pas de description (DESCRIBE) ni de flux (SETUP) ; réponse 304 sans corps.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
Exemple : If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
12.24 Last-Modified
Indique la date et l'heure auxquelles le serveur d'origine estime que la description ou le flux a été modifié pour la dernière fois. Voir [H14.29]. Pour DESCRIBE ou ANNOUNCE : la description ; pour SETUP : le flux média.
12.25 Location
Voir [H14.30].
12.26 Proxy-Authenticate
Voir [H14.33].
12.27 Proxy-Require
L'en-tête Proxy-Require indique les fonctionnalités sensibles au proxy que le proxy DOIT prendre en charge. Toute fonctionnalité Proxy-Require non prise en charge par le proxy DOIT être accusée réception négativement vers le client si elle n'est pas supportée. Les serveurs devraient traiter ce champ de la même manière que le champ Require.
Voir la section 12.32 pour les détails mécaniques et un exemple d'utilisation.
12.28 Public
Voir [H14.35].
12.29 Range
Ce champ de requête et de réponse spécifie une plage temporelle. Cette spécification définit les unités smpte (3.5), npt (3.6) et clock (3.7). Les plages d'octets [H14.36.1] n'ont pas de sens en RTSP et NE DOIVENT PAS être utilisées. Un paramètre time en UTC peut indiquer quand l'opération prend effet. Un serveur qui prend en charge Range DOIT comprendre NPT et DEVRAIT comprendre SMPTE. La réponse Range indique la plage réellement lue ou enregistrée. Si le format temporel n'est pas compris, le destinataire devrait renvoyer « 501 Not Implemented ».
Les plages sont des intervalles semi-ouverts : borne inférieure incluse, supérieure exclue. Seul le début d'une unité média (image, trame audio) compte. Exemple : images vidéo toutes les 40 ms ; 10.0–10.1 inclut une image commençant à 10.08 même si elle dépasse ; 10.0–10.08 l'exclut.
Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range
Exemple : Range: clock=19960213T143205Z-;time=19970123T143720Z
La notation est similaire à celle de l'en-tête de plage d'octets HTTP/1.1 [2]. Elle permet au client de sélectionner un extrait de l'objet média, de lire d'un point donné jusqu'à la fin ainsi que de la position courante jusqu'à un point donné. Le début de la lecture peut être planifié à tout moment dans le futur, bien qu'un serveur puisse refuser de conserver des ressources serveur pendant de longues périodes d'inactivité.
12.30 Referer
Voir [H14.37]. L'URL est celle de la description de présentation, souvent via HTTP.
12.31 Retry-After
Voir [H14.38].
12.32 Require
Le champ Require est utilisé par les clients pour interroger le serveur sur des options qu'il peut ou ne peut pas prendre en charge. Le serveur DOIT répondre à cet en-tête en utilisant l'en-tête Unsupported pour accuser réception négativement des options qui ne sont PAS prises en charge.
Cela garantit que l'interaction client-serveur se poursuivra sans délai lorsque toutes les options sont comprises des deux côtés, et ne ralentira que si des options ne le sont pas (comme dans le cas ci-dessus). Pour une paire client-serveur bien assortie, l'interaction est rapide, évitant souvent un aller-retour exigé par des mécanismes de négociation. De plus, cela supprime l'ambiguïté d'état lorsque le client exige des fonctionnalités que le serveur ne comprend pas.
Require = "Require" ":" 1#option-tag
Exemple :
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 CSeq: 302 Require: funky-feature Funky-Parameter: funkystuff
S->C: RTSP/1.0 551 Option not supported CSeq: 302 Unsupported: funky-feature
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 CSeq: 303
S->C: RTSP/1.0 200 OK CSeq: 303
Dans cet exemple, « funky-feature » est l'étiquette de fonctionnalité qui indique au client que le champ fictif Funky-Parameter est requis. La relation entre « funky-feature » et Funky-Parameter n'est pas communiquée via l'échange RTSP, car cette relation est une propriété immuable de « funky-feature » et ne devrait donc pas être transmise à chaque échange.
Les proxys et autres dispositifs intermédiaires DEVRAIENT ignorer les fonctionnalités non comprises dans ce champ. Si une extension particulière exige que les dispositifs intermédiaires la prennent en charge, l'extension devrait être étiquetée dans le champ Proxy-Require à la place (voir section 12.27).
12.33 RTP-Info
Ce champ sert à définir des paramètres spécifiques à RTP dans la réponse PLAY.
url : indique l'URL du flux auquel correspondent les paramètres RTP suivants.
seq : indique le numéro de séquence du premier paquet du flux. Cela permet aux clients de traiter correctement les paquets lors d'un seek. Le client utilise cette valeur pour distinguer les paquets émis avant le seek de ceux émis après.
rtptime : indique l'horodatage RTP correspondant à la valeur temporelle de l'en-tête de réponse Range. (Remarque : pour le contrôle agrégé, un flux particulier peut ne pas générer de paquet pour la valeur temporelle de plage renvoyée ou implicite. Il n'y a donc aucune garantie que le paquet dont le numéro de séquence est indiqué par seq ait réellement l'horodatage indiqué par rtptime.) Le client utilise cette valeur pour calculer la correspondance entre le temps RTP et le NPT.
Une correspondance des horodatages RTP vers les horodatages NTP (horloge murale) est disponible via RTCP. Cette information ne suffit toutefois pas à produire une correspondance RTP vers NPT. De plus, afin de garantir que cette information est disponible au moment nécessaire (immédiatement au démarrage ou après un seek) et qu'elle est livrée de manière fiable, cette correspondance est placée sur le canal de contrôle RTSP.
Afin de compenser la dérive pour de longues présentations ininterrompues, les clients RTSP devraient en outre mapper le NPT vers le NTP, en utilisant les rapports d'émetteur RTCP initiaux pour établir la correspondance et les rapports ultérieurs pour vérifier la dérive par rapport à cette correspondance.
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
stream-url = "url" "=" url
parameter = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT
Exemple : RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
12.34 Scale
Une valeur d'échelle de 1 indique une lecture ou un enregistrement normal au débit de visionnage avant normal. Si elle n'est pas 1, la valeur correspond au rapport par rapport au débit de visionnage normal. Par exemple, un rapport de 2 indique le double du débit normal (« avance rapide ») et 0,5 la moitié. En d'autres termes, un rapport de 2 fait croître le temps de lecture normal au double du rythme de l'horloge murale : chaque seconde d'horloge murale, deux secondes de contenu sont livrées. Une valeur négative indique la direction inverse.
Sauf demande contraire du paramètre Speed, le débit de données ne DEVRAIT pas être modifié. La mise en œuvre des changements d'échelle dépend du serveur et du type de média. Pour la vidéo, le serveur peut par ex. ne livrer que des images clés ou des images clés sélectionnées. Pour l'audio, il peut mettre l'audio à l'échelle temporelle en préservant la hauteur ou, moins souhaitable, livrer des fragments audio.
Le serveur devrait tenter d'approcher le débit de visionnage, mais peut restreindre la plage de valeurs d'échelle prises en charge. La réponse DOIT contenir la valeur d'échelle réelle choisie par le serveur.
Si la requête contient un paramètre Range, la nouvelle valeur d'échelle prendra effet à ce moment.
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
Exemple de lecture en sens inverse à 3,5 fois le débit normal :
Scale: -3.5
12.35 Speed
Ce paramètre de champ d'en-tête de requête demande au serveur de livrer les données au client à une vitesse particulière, sous réserve de la capacité et de la volonté du serveur de servir le flux média à cette vitesse. La mise en œuvre par le serveur est FACULTATIVE. La valeur par défaut est le débit binaire du flux.
La valeur du paramètre est exprimée comme un rapport décimal ; par ex. 2,0 indique que les données doivent être livrées deux fois plus vite que la normale. Une vitesse nulle est invalide. Si la requête contient un paramètre Range, la nouvelle vitesse prendra effet à ce moment.
Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
Exemple : Speed: 2.5
L'utilisation de ce champ modifie la bande passante utilisée pour la livraison des données. Elle est destinée à des circonstances spécifiques où un aperçu de la présentation à un débit plus élevé ou plus bas est nécessaire. Les implémenteurs doivent garder à l'esprit que la bande passante de la session peut avoir été négociée au préalable (par d'autres moyens que RTSP), et qu'une renégociation peut donc être nécessaire. Lorsque les données sont livrées sur UDP, il est fortement recommandé d'utiliser des moyens tels que RTCP pour suivre les taux de perte de paquets.
12.36 Server
Voir [H14.39].
12.37 Session
Ce champ d'en-tête de requête et de réponse identifie une session RTSP démarrée par le serveur multimédia dans une réponse SETUP et close par TEARDOWN sur l'URL de présentation. L'identifiant de session est choisi par le serveur multimédia (section 3.4). Une fois l'identifiant Session reçu, le client DOIT le renvoyer pour toute requête liée à cette session. Le serveur n'a pas besoin d'identifiant s'il dispose d'autres moyens d'identification, par ex. des URL générées dynamiquement.
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
Le paramètre timeout n'est autorisé que dans l'en-tête de réponse. Le serveur l'utilise pour indiquer combien de temps il est prêt à attendre entre commandes RTSP avant de fermer la session pour inactivité (annexe A). Le timeout est en secondes, défaut 60.
Note : l'identifiant de session identifie une session RTSP au-delà des sessions ou connexions de transport. Des messages de contrôle pour plusieurs URL RTSP peuvent être envoyés dans une seule session RTSP ; le client peut donc utiliser la même session pour plusieurs flux d'une présentation tant qu'ils viennent du même serveur (exemple section 14). En revanche, plusieurs sessions « utilisateur » pour la même URL depuis le même client DOIVENT utiliser des identifiants différents.
L'identifiant distingue plusieurs demandes de livraison pour la même URL en provenance du même client.
Réponse 454 (Session Not Found) si l'identifiant est invalide.
12.38 Timestamp
L'en-tête général Timestamp indique quand le client a envoyé la requête au serveur. La valeur n'a de signification que pour le client et peut utiliser n'importe quelle échelle de temps. Le serveur DOIT renvoyer exactement la même valeur et PEUT, s'il dispose d'informations précises, ajouter un nombre flottant indiquant le nombre de secondes écoulées depuis la réception de la requête. Le client utilise l'horodatage pour calculer le temps aller-retour et ajuster le délai de retransmission.
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
12.39 Transport
Cet en-tête de requête indique quel protocole de transport utiliser et configure ses paramètres, tels que l'adresse de destination, la compression, le TTL multicast et le port de destination pour un flux unique. Il fixe les valeurs non déjà déterminées par la description de présentation.
Les transports sont séparés par des virgules, listés par ordre de préférence. Des paramètres peuvent être ajoutés à chaque transport, séparés par un point-virgule.
L'en-tête Transport PEUT aussi servir à modifier certains paramètres de transport. Un serveur PEUT refuser de modifier les paramètres d'un flux existant.
Le serveur PEUT renvoyer un en-tête Transport dans la réponse avec les valeurs réellement choisies.
Si l'en-tête de requête contient une liste d'options acceptables pour le client, le serveur DOIT renvoyer une seule option effectivement choisie.
La syntaxe du spécificateur de transport est transport/profile/lower-transport. La valeur par défaut de lower-transport dépend du profil ; pour RTP/AVP, la valeur par défaut est UDP.
Paramètres généraux :
unicast | multicast : indication mutuellement exclusive ; défaut multicast. Les clients capables des deux DOIVENT l'indiquer par deux transport-spec complets avec paramètres séparés.
destination : adresse vers laquelle le flux sera envoyé. Pour éviter de devenir l'auteur involontaire d'une attaque par déni de service à distance, un serveur DEVRAIT authentifier le client et consigner de telles tentatives avant d'autoriser la redirection d'un flux vers une adresse non choisie par le serveur. Particulièrement important si les commandes RTSP passent par UDP ; on ne peut pas s'appuyer sur TCP seul pour identifier le client. Un serveur NE DEVRAIT PAS autoriser la redirection vers une adresse différente de celle d'où viennent les commandes.
source : si l'adresse source du flux diffère de ce qui est déductible de l'adresse d'extrémité RTSP (serveur en lecture, client en enregistrement), la source PEUT être indiquée. L'autorité devrait être la réponse SETUP, pas seulement SDP.
layers : nombre de couches multicast pour ce flux ; les couches sont envoyées vers des adresses consécutives à partir de l'adresse de destination.
mode : méthodes à prendre en charge pour cette session ; valeurs valides PLAY et RECORD ; défaut PLAY.
append : si mode inclut RECORD, indique que les données média doivent s'ajouter à la ressource existante plutôt que l'écraser. Si l'ajout est demandé et non supporté, le serveur DOIT refuser plutôt que d'écraser la ressource identifiée par l'URI. Ignoré si mode ne contient pas RECORD.
interleaved : implique de mélanger le flux média avec le flux de contrôle (section 10.12) ; l'argument est le numéro de canal pour l'instruction $. Peut être une plage, ex. interleaved=4-5.
Spécifique multicast : ttl (durée de vie).
Spécifique RTP : port (paire RTP/RTCP multicast), client_port et server_port (paires unicast), ssrc (valeur SSRC ; valide seulement en unicast).
Transport = "Transport" ":" 1#transport-spec
transport-spec = transport-protocol/profile[/lower-transport] *parameter
transport-protocol = "RTP"
profile = "AVP"
lower-transport = "TCP" | "UDP"
parameter = ( "unicast" | "multicast" ) |
";" "destination" [ "=" address ] |
";" "interleaved" "=" channel [ "-" channel ] |
";" "append" |
";" "ttl" "=" ttl |
";" "layers" "=" 1*DIGIT |
";" "port" "=" port [ "-" port ] |
";" "client_port" "=" port [ "-" port ] |
";" "server_port" "=" port [ "-" port ] |
";" "ssrc" "=" ssrc |
";" "mode" "=" "\"" 1#Method "\"" | Method
ttl = 1*3(DIGIT)
port = 1*5(DIGIT)
ssrc = 8*8(HEX)
channel = 1*3(DIGIT)
address = host
Exemple : Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
Limité à un flux RTP ; simplifie les pare-feu.
12.40 Unsupported
Liste les fonctionnalités non prises en charge. Avec Proxy-Require et un proxy sur le chemin, le proxy DOIT insérer une réponse d'erreur « 551 Option Not Supported ». Voir 12.32.
12.41 User-Agent
Voir [H14.42].
12.42 Vary
Voir [H14.43].
12.43 Via
Voir [H14.44].
12.44 WWW-Authenticate
Voir [H14.46].