3 Protocol Parameters (Paramètres du protocole)

3.1 RTSP Version (Version RTSP)

[H3.1] s'applique, en remplaçant HTTP par RTSP.

3.2 RTSP URL (URL RTSP)

Les schémas « rtsp » et « rtspu » servent à désigner des ressources réseau via le protocole RTSP. La présente section définit la syntaxe et la sémantique propres au schéma pour les URL RTSP.

rtsp_URL  =   ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
host      =   <Nom de domaine Internet légal ou adresse IP en notation décimale pointée, tel que défini à la section 2.1 de RFC 1123>
port      =   *DIGIT

abs_path est défini dans [H3.2.1].

Notez que les identificateurs de fragment et de requête n'ont pas de sens bien défini à ce stade, l'interprétation étant laissée au serveur RTSP.

Le schéma rtsp exige que les commandes soient émises via un protocole fiable (sur Internet, TCP), tandis que le schéma rtspu identifie un protocole non fiable (sur Internet, UDP).

Si le port est vide ou absent, le port 554 est supposé. La sémantique est que la ressource identifiée peut être contrôlée par RTSP sur le serveur qui écoute les connexions TCP (schéma « rtsp ») ou les paquets UDP (schéma « rtspu ») sur ce port de l'hôte, et que le Request-URI de la ressource est rtsp_URL.

L'utilisation d'adresses IP dans les URL SHOULD être évitée chaque fois que possible (voir RFC 1924 [19]).

Une présentation ou un flux est identifié par un identifiant textuel de média, en utilisant le jeu de caractères et les conventions d'échappement [H3.2] des URL (RFC 1738 [20]). Les URL peuvent désigner un flux ou un agrégat de flux, c'est-à-dire une présentation. En conséquence, les requêtes décrites à la section 10 peuvent s'appliquer soit à la présentation entière, soit à un flux individuel au sein de la présentation. Notez que certaines méthodes de requête ne peuvent s'appliquer qu'aux flux, pas aux présentations, et inversement.

Par exemple, l'URL RTSP :

rtsp://media.example.com:554/twister/audiotrack

identifie le flux audio au sein de la présentation « twister », qui peut être contrôlé via des requêtes RTSP émises sur une connexion TCP vers le port 554 de l'hôte media.example.com.

De même, l'URL RTSP :

rtsp://media.example.com:554/twister

identifie la présentation « twister », qui peut être composée de flux audio et vidéo.

Cela n'implique pas de manière standard de référencer les flux dans les URL. La description de présentation définit les relations hiérarchiques dans la présentation et les URL des flux individuels. Une description de présentation peut nommer un flux « a.mov » et la présentation entière « b.mov ».

Les composants de chemin de l'URL RTSP sont opaques pour le client et n'impliquent aucune structure de système de fichiers particulière côté serveur.

Ce découplage permet également d'utiliser des descriptions de présentation avec des protocoles de contrôle média non RTSP en remplaçant simplement le schéma dans l'URL.

3.3 Conference Identifiers (Identifiants de conférence)

Les identifiants de conférence sont opaques pour RTSP et sont encodés selon les méthodes d'encodage URI standard (c'est-à-dire que LWS est échappé avec %). Ils peuvent contenir toute valeur d'octet. L'identifiant de conférence MUST être globalement unique. Pour H.323, la valeur conferenceID doit être utilisée.

conference-id =   1*xchar

Les identifiants de conférence permettent aux sessions RTSP d'obtenir des paramètres à partir des conférences multimédias auxquelles le serveur média participe. Ces conférences sont créées par des protocoles hors du périmètre de la présente spécification, par ex. H.323 [13] ou SIP [12]. Au lieu que le client RTSP fournisse explicitement des informations de transport, par exemple, il demande au serveur média d'utiliser les valeurs figurant dans la description de conférence.

3.4 Session Identifiers (Identifiants de session)

Les identifiants de session sont des chaînes opaques de longueur arbitraire. Les espaces blancs linéaires doivent être échappés en URL. Un identifiant de session MUST être choisi aléatoirement et MUST comporter au moins huit octets afin de rendre son devinette plus difficile. (Voir la section 16.)

session-id   =   1*( ALPHA | DIGIT | safe )

3.5 SMPTE Relative Timestamps (Horodatages relatifs SMPTE)

Un horodatage relatif SMPTE exprime le temps par rapport au début du clip. Les horodatages relatifs sont exprimés comme codes temporels SMPTE pour une précision d'accès au niveau frame. Le code temporel a le format heures:minutes:secondes:frames.sous-frames, avec l'origine au début du clip. Le format smpte par défaut est le format « SMPTE 30 drop », avec un débit de 29,97 images par seconde. D'autres codes SMPTE MAY être pris en charge (tels que « SMPTE 25 ») par l'utilisation alternative de « smpte time ». Le champ « frames » dans la valeur temporelle peut prendre les valeurs 0 à 29. La différence entre 30 et 29,97 images par seconde est gérée en supprimant les deux premiers indices d'image (valeurs 00 et 01) de chaque minute, sauf toutes les dixièmes minutes. Si la valeur de frame est zéro, elle peut être omise. Les sous-frames sont mesurées en centièmes d'image.

smpte-range  =   smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type   =   "smpte" | "smpte-30-drop" | "smpte-25" ; d'autres timecodes peuvent être ajoutés
smpte-time   =   1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ]

Exemples : smpte=10:12:33:20- smpte=10:07:33- smpte=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01

3.6 Normal Play Time (Temps de lecture normale)

Le normal play time (temps de lecture normale, NPT) indique la position absolue du flux par rapport au début de la présentation. L'horodatage consiste en une fraction décimale. La partie à gauche du point décimal peut être exprimée en secondes ou en heures, minutes et secondes. La partie à droite du point décimal mesure des fractions de seconde.

Le début d'une présentation correspond à 0,0 seconde. Les valeurs négatives ne sont pas définies. La constante spéciale now est définie comme l'instant courant d'un événement en direct. Elle ne peut être utilisée que pour les événements en direct.

Le NPT est défini comme dans DSM-CC : « Intuitivement, le NPT est l'horloge que le spectateur associe à un programme. Elle est souvent affichée numériquement sur un magnétoscope. Le NPT avance normalement en mode lecture normale (scale = 1), plus vite en avance rapide (ratio d'échelle positif élevé), diminue en retour arrière (ratio d'échelle négatif élevé) et est fixe en mode pause. Le NPT est (logiquement) équivalent aux codes temporels SMPTE. » [5]

npt-range    =   ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
npt-time     =   "now" | npt-sec | npt-hhmmss
npt-sec      =   1*DIGIT [ "." *DIGIT ]
npt-hhmmss   =   npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh       =   1*DIGIT     ; tout nombre positif
npt-mm       =   1*2DIGIT    ; 0-59
npt-ss       =   1*2DIGIT    ; 0-59

Exemples : npt=123.45-125 npt=12:05:35.3- npt=now-

La syntaxe est conforme à ISO 8601. La notation npt-sec est optimisée pour la génération automatique, la notation npt-hhmmss pour la lecture humaine. La constante « now » permet aux clients de demander de recevoir le flux en direct plutôt que la version stockée ou retardée. Ceci est nécessaire car ni l'heure absolue ni l'instant zéro ne conviennent dans ce cas.

3.7 Absolute Time (Temps absolu)

Le temps absolu est exprimé comme des horodatages ISO 8601, en UTC (GMT). Des fractions de seconde peuvent être indiquées.

utc-range    =   "clock" "=" utc-time "-" [ utc-time ]
utc-time     =   utc-date "T" utc-time "Z"
utc-date     =   8DIGIT                    ; < YYYYMMDD >
utc-time     =   6DIGIT [ "." fraction ]   ; < HHMMSS.fraction >

Exemple pour le 8 novembre 1996 à 14 h 37 min 20,25 s UTC :

19961108T143720.25Z

3.8 Option Tags (Balises d'option)

Les balises d'option sont des identifiants uniques utilisés pour désigner de nouvelles options dans RTSP. Ces balises sont utilisées dans les champs d'en-tête Require (section 12.32) et Proxy-Require (section 12.27).

Syntaxe :

option-tag   =   1*xchar

Le créateur d'une nouvelle option RTSP devrait soit préfixer l'option par un nom de domaine inversé (par ex. « com.foo.mynewfeature » convient pour une fonction dont l'inventeur est joignable sur « foo.com »), soit enregistrer la nouvelle option auprès de l'Internet Assigned Numbers Authority (IANA).

3.8.1 Registering New Option Tags with IANA (Enregistrer de nouvelles balises d'option auprès de l'IANA)

Lors de l'enregistrement d'une nouvelle option RTSP, les informations suivantes devraient être fournies :

Nom et description de l'option. Le nom peut être de longueur quelconque, mais SHOULD ne pas dépasser une vingtaine de caractères. Le nom MUST NOT contenir d'espaces, de caractères de contrôle ni de points.
Indication de qui détient le contrôle des changements sur l'option (par exemple IETF, ISO, ITU-T, autres organismes de normalisation internationale, un consortium ou une entreprise ou un groupe d'entreprises particulier) ;
Une référence à une description plus détaillée, si disponible, par exemple (par ordre de préférence) un RFC, un article publié, un dépôt de brevet, un rapport technique, du code source documenté ou un manuel informatique ;
Pour les options propriétaires, des coordonnées (adresse postale et courriel) ;