3 Protocol Parameters (Protokollparameter)

3.1 RTSP Version (RTSP-Version)

[H3.1] gilt sinngemäß, wobei HTTP durch RTSP ersetzt wird.

3.2 RTSP URL (RTSP-URL)

Die Schemes „rtsp“ und „rtspu“ dienen dazu, Netzressourcen über das RTSP-Protokoll zu bezeichnen. Dieser Abschnitt definiert die scheme-spezifische Syntax und Semantik für RTSP-URLs.

rtsp_URL  =   ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
host      =   <Ein zulässiger Internet-Host-Domainname oder eine IP-Adresse in Punkt-Dezimalnotation gemäß Abschnitt 2.1 von RFC 1123>
port      =   *DIGIT

abs_path ist in [H3.2.1] definiert.

Beachten Sie, dass Fragment- und Query-Identifikatoren derzeit keine klar definierte Bedeutung haben; die Auslegung bleibt dem RTSP-Server überlassen.

Das Scheme rtsp verlangt, dass Befehle über ein zuverlässiges Protokoll (im Internet TCP) ausgegeben werden, während das Scheme rtspu ein nicht zuverlässiges Protokoll (im Internet UDP) bezeichnet.

Ist der Port leer oder nicht angegeben, wird Port 554 angenommen. Die Semantik ist, dass die bezeichnete Ressource per RTSP durch den Server gesteuert werden kann, der auf diesem Port des Hosts TCP-Verbindungen (Scheme „rtsp“) bzw. UDP-Pakete (Scheme „rtspu“) annimmt, und dass der Request-URI für die Ressource rtsp_URL ist.

Die Verwendung von IP-Adressen in URLs SHOULD nach Möglichkeit vermieden werden (siehe RFC 1924 [19]).

Eine Präsentation oder ein Strom wird durch einen textuellen Medienbezeichner identifiziert unter Verwendung des Zeichensatzes und der Escape-Konventionen [H3.2] von URLs (RFC 1738 [20]). URLs können sich auf einen Strom oder auf eine Aggregation von Strömen, d. h. eine Präsentation, beziehen. Entsprechend können die in Abschnitt 10 beschriebenen Anfragen entweder auf die gesamte Präsentation oder auf einen einzelnen Strom innerhalb der Präsentation zutreffen. Beachten Sie, dass einige Anfragemethoden nur auf Ströme, nicht auf Präsentationen angewendet werden können und umgekehrt.

Beispiel: Die RTSP-URL

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

bezeichnet den Audiostream innerhalb der Präsentation „twister“, der mittels RTSP-Anfragen über eine TCP-Verbindung zu Port 554 des Hosts media.example.com gesteuert werden kann.

Ebenso bezeichnet die RTSP-URL

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

die Präsentation „twister“, die aus Audio- und Videoströmen bestehen kann.

Dies impliziert keine standardisierte Art, Ströme in URLs zu referenzieren. Die Präsentationsbeschreibung definiert die hierarchischen Beziehungen in der Präsentation und die URLs der einzelnen Ströme. Eine Präsentationsbeschreibung kann einen Strom „a.mov“ und die gesamte Präsentation „b.mov“ nennen.

Die Pfadkomponenten der RTSP-URL sind für den Client undurchsichtig und legen keine bestimmte Dateisystemstruktur auf dem Server nahe.

Diese Entkopplung erlaubt es zudem, Präsentationsbeschreibungen mit nicht-RTSP-Mediensteuerungsprotokollen zu verwenden, indem lediglich das Scheme in der URL ersetzt wird.

3.3 Conference Identifiers (Konferenzkennungen)

Konferenzkennungen sind für RTSP undurchsichtig und werden mit den üblichen URI-Kodierungsmethoden kodiert (d. h. LWS wird mit % escaped). Sie können jeden Oktettwert enthalten. Die Konferenzkennung MUST global eindeutig sein. Für H.323 ist der Wert conferenceID zu verwenden.

conference-id =   1*xchar

Konferenzkennungen ermöglichen es RTSP-Sitzungen, Parameter aus Multimedia-Konferenzen zu beziehen, an denen der Medienserver teilnimmt. Diese Konferenzen werden durch Protokolle außerhalb dieses Spezifikationsumfangs erzeugt, z. B. H.323 [13] oder SIP [12]. Anstatt dass der RTSP-Client ausdrücklich Transportinformationen liefert, kann er den Medienserver beispielsweise bitten, die Werte aus der Konferenzbeschreibung zu verwenden.

3.4 Session Identifiers (Sitzungskennungen)

Sitzungskennungen sind undurchsichtige Zeichenketten beliebiger Länge. Linearer Weißraum muss URL-escaped werden. Eine Sitzungskennung MUST zufällig gewählt werden und MUST mindestens acht Oktette lang sein, um Erraten zu erschweren. (Siehe Abschnitt 16.)

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

3.5 SMPTE Relative Timestamps (SMPTE-relative Zeitstempel)

Ein SMPTE-relativer Zeitstempel drückt die Zeit relativ zum Beginn des Clips aus. Relative Zeitstempel werden als SMPTE-Timecodes für Frame-genauen Zugriff dargestellt. Der Timecode hat das Format Stunden:Minuten:Sekunden:Frames.Subframes, mit dem Ursprung am Clip-Anfang. Das Standard-smpte-Format ist „SMPTE 30 drop“ mit einer Bildrate von 29,97 Bildern pro Sekunde. Weitere SMPTE-Codes MAY unterstützt werden (z. B. „SMPTE 25“) durch alternative Verwendung von „smpte time“. Das Feld „frames“ im Zeitwert kann die Werte 0 bis 29 annehmen. Der Unterschied zwischen 30 und 29,97 Bildern pro Sekunde wird behandelt, indem die ersten beiden Frame-Indizes (Werte 00 und 01) jeder Minute entfallen, außer jeder zehnten Minute. Ist der Frame-Wert null, kann er weggelassen werden. Subframes werden in Hundertsteln eines Frames gemessen.

smpte-range  =   smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type   =   "smpte" | "smpte-30-drop" | "smpte-25" ; weitere Timecodes können ergänzt werden
smpte-time   =   1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ]

Beispiele: 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 (Normalwiedergabezeit)

Die Normal play time (Normalwiedergabezeit, NPT) gibt die absolute Position des Stroms relativ zum Beginn der Präsentation an. Der Zeitstempel besteht aus einem Dezimalbruch. Der Teil links vom Dezimalpunkt kann in Sekunden oder in Stunden, Minuten und Sekunden angegeben werden. Der Teil rechts vom Dezimalpunkt misst Sekundenbruchteile.

Der Beginn einer Präsentation entspricht 0,0 Sekunden. Negative Werte sind nicht definiert. Die spezielle Konstante now ist als der aktuelle Moment eines Live-Ereignisses definiert und darf nur für Live-Ereignisse verwendet werden.

NPT ist wie in DSM-CC definiert: „Intuitiv ist NPT die Uhr, die der Zuschauer mit einem Programm verbindet. Sie wird oft digital auf einem Videorekorder angezeigt. NPT läuft im Normalwiedergabemodus (scale = 1) normal weiter, schneller im Schnellvorlauf (hoher positiver Skalenfaktor), verringert sich im Rücklauf (hoher negativer Skalenfaktor) und bleibt im Pausenmodus stehen. NPT ist (logisch) äquivalent zu SMPTE-Timecodes.“ [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     ; jede positive Zahl
npt-mm       =   1*2DIGIT    ; 0-59
npt-ss       =   1*2DIGIT    ; 0-59

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

Die Syntax entspricht ISO 8601. Die npt-sec-Notation ist für automatische Erzeugung optimiert, die npt-hhmmss-Notation für menschliche Leser. Die Konstante „now“ erlaubt es Clients, den Live-Feed statt der gespeicherten oder zeitverzögerten Version anzufordern. Dies ist nötig, weil weder absolute Zeit noch Nullzeit hier passend sind.

3.7 Absolute Time (Absolute Zeit)

Absolute Zeit wird als ISO-8601-Zeitstempel in UTC (GMT) ausgedrückt. Sekundenbruchteile können angegeben werden.

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 >

Beispiel für den 8. November 1996 um 14:37:20,25 UTC:

19961108T143720.25Z

3.8 Option Tags (Options-Tags)

Options-Tags sind eindeutige Kennungen zur Bezeichnung neuer Optionen in RTSP. Diese Tags werden in den Header-Feldern Require (Abschnitt 12.32) und Proxy-Require (Abschnitt 12.27) verwendet.

Syntax:

option-tag   =   1*xchar

Der Urheber einer neuen RTSP-Option sollte die Option entweder mit einem umgekehrten Domainnamen präfixieren (z. B. ist „com.foo.mynewfeature“ ein passender Name für eine Funktion, deren Erfinder unter „foo.com“ erreichbar ist), oder die neue Option bei der Internet Assigned Numbers Authority (IANA) registrieren.

3.8.1 Registering New Option Tags with IANA (Neue Options-Tags bei der IANA registrieren)

Bei der Registrierung einer neuen RTSP-Option sollten folgende Angaben gemacht werden:

Name und Beschreibung der Option. Der Name kann beliebig lang sein, sollte aber SHOULD höchstens zwanzig Zeichen umfassen. Der Name MUST NOT Leerzeichen, Steuerzeichen oder Punkte enthalten.
Angabe, wer die Änderungskontrolle über die Option hat (z. B. IETF, ISO, ITU-T, andere internationale Standardisierungsgremien, ein Konsortium oder ein bestimmtes Unternehmen oder eine Unternehmensgruppe);
Verweis auf eine weiterführende Beschreibung, falls vorhanden, z. B. (nach Präferenz) ein RFC, eine veröffentlichte Arbeit, eine Patentanmeldung, ein technischer Bericht, dokumentierter Quellcode oder ein Computerhandbuch;
Bei proprietären Optionen Kontaktinformationen (Post- und E-Mail-Adresse);