12 Header Field Definitions (Definitionen der Header-Felder)
12 Header Field Definitions (Definitionen der Header-Felder)
HTTP/1.1 [2] oder andere, hier nicht aufgeführte nicht standardisierte Header-Felder haben derzeit keine wohldefinierte Bedeutung und SOLLTEN vom Empfänger ignoriert werden.
Tabelle 3 fasst die von RTSP verwendeten Header-Felder zusammen. Typ „g“ bezeichnet allgemeine Anfrage-Header in Anfragen und Antworten, „R“ Anfrage-Header, „r“ Antwort-Header und „e“ Entitäts-Header-Felder. Felder mit „req.“ in der Spalte „support“ MÜSSEN vom Empfänger für die jeweilige Methode implementiert werden; „opt.“ ist optional. Nicht jedes mit „req.“ markierte Feld wird in jeder Anfrage dieses Typs gesendet. „req.“ bedeutet nur, dass Client (bei Antwort-Headern) und Server (bei Anfrage-Headern) diese Felder MÜSSEN implementieren. Die letzte Spalte nennt die Methode, für die das Header-Feld sinnvoll ist; „entity“ bezieht sich auf alle Methoden, die einen Nachrichtenkörper zurückgeben. In dieser Spezifikation fallen DESCRIBE und GET_PARAMETER in diese Klasse.
| 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 |
Überblick über RTSP-Header-Felder
12.1 Accept
Das Accept-Anfrage-Header-Feld kann nutzbar gemacht werden, um bestimmte für die Antwort akzeptable Inhaltstypen der Präsentationsbeschreibung anzugeben.
Der „level“-Parameter für Präsentationsbeschreibungen ist ordnungsgemäß Teil der MIME-Typ-Registrierung definiert, nicht hier.
Syntax siehe [H14.1].
Beispiel: Accept: application/rtsl, application/sdp;level=2
12.2 Accept-Encoding
Siehe [H14.3].
12.3 Accept-Language
Siehe [H14.4]. Die angegebene Sprache gilt für die Präsentationsbeschreibung und etwaige Begründungstexte, nicht für den Medieninhalt.
12.4 Allow
Das Allow-Antwort-Header-Feld listet die von der durch die Request-URI identifizierten Ressource unterstützten Methoden auf. Zweck ist, den Empfänger strikt über gültige Methoden zu informieren. Bei 405 (Method not allowed) MUSS ein Allow-Header-Feld vorhanden sein.
Beispiel: Allow: SETUP, PLAY, RECORD, SET_PARAMETER
12.5 Authorization
Siehe [H14.8].
12.6 Bandwidth
Das Bandwidth-Anfrage-Header-Feld beschreibt die geschätzte dem Client zur Verfügung stehende Bandbreite als positive Ganzzahl in Bit pro Sekunde. Die verfügbare Bandbreite kann während einer RTSP-Sitzung wechseln, z. B. durch Modem-Neueinwahl.
Bandwidth = "Bandwidth" ":" 1*DIGIT
Beispiel: Bandwidth: 4000
12.7 Blocksize
Dieses Anfrage-Header-Feld wird vom Client an den Medienserver gesendet, um eine bestimmte Medienpaketgröße anzufragen. Diese Größe schließt unterlagige Header wie IP, UDP oder RTP nicht ein. Der Server darf eine kleinere Blockgröße verwenden. Der Server KANN die Paketgröße auf das nächste Vielfache der minimalen medienspezifischen Blockgröße kürzen oder bei Bedarf durch die medienspezifische Größe ersetzen. Die Blockgröße MUSS eine positive Dezimalzahl in Oktetten sein. Der Server liefert nur bei syntaktisch ungültigem Wert einen Fehler (416).
12.8 Cache-Control
Das allgemeine Cache-Control-Header-Feld legt Anweisungen fest, die von allen Cache-Mechanismen entlang der Anfrage-/Antwortkette BEFOLGT werden MÜSSEN.
Cache-Anweisungen müssen von Proxy oder Gateway durchgereicht werden, unabhängig von ihrer Bedeutung für die Anwendung, da sie für alle Empfänger gelten können. Eine Cache-Anweisung für einen bestimmten Cache ist nicht möglich.
Cache-Control sollte nur in einer SETUP-Anfrage und deren Antwort angegeben werden. Hinweis: Cache-Control regelt nicht wie in HTTP das Caching von Antworten, sondern des durch SETUP identifizierten Stroms. Antworten auf RTSP-Anfragen sind nicht cachebar, außer Antworten auf 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: Der Medienstrom DARF NICHT irgendwo gecacht werden.
public: Der Medienstrom ist von jedem Cache cachebar.
private: Der Medienstrom ist für einen einzelnen Benutzer bestimmt und DARF NICHT von einem gemeinsam genutzten Cache gecacht werden. Ein privater Cache darf cachen.
no-transform: Ein Zwischencache (Proxy) kann es nützlich finden, den Medientyp eines Stroms zu wandeln. Ein Proxy kann z. B. zwischen Videoformaten konvertieren, um Cache-Platz zu sparen oder Verkehr auf einem langsamen Link zu reduzieren. Schwere Betriebsprobleme können entstehen, wenn solche Umwandlungen auf Ströme angewendet werden, die für bestimmte Anwendungen bestimmt sind (medizinische Bildgebung, wissenschaftliche Datenanalyse, Ende-zu-Ende-Authentisierung). Enthält die Antwort no-transform, DARF ein Zwischencache oder Proxy die Kodierung des Stroms NICHT ändern. Anders als HTTP sieht RTSP an dieser Stelle keine Teiltransformation vor, z. B. Übersetzung in eine andere Sprache.
only-if-cached: In manchen Fällen, z. B. bei extrem schlechter Netzanbindung, möchte der Client nur bereits gespeicherte Medienströme vom Cache, nicht vom Ursprungsserver. Dazu kann der Client only-if-cached mitsenden. Empfängt der Cache diese Anweisung, SOLLTE er entweder mit einem zum Rest der Anfrage passenden gecachten Strom antworten oder mit 504 (Gateway Timeout). Bilden mehrere Caches jedoch ein einheitliches System mit guter interner Anbindung, KANN die Anfrage innerhalb dieser Cache-Gruppe weitergeleitet werden.
max-stale: Der Client ist bereit, einen Strom zu akzeptieren, dessen Ablaufzeit überschritten ist. Ist max-stale mit Wert belegt, ist nur eine Überschreitung bis zu dieser Sekundenzahl akzeptabel ; ohne Wert akzeptiert der Client jede Alterung der abgelaufenen Antwort.
min-fresh: Der Client akzeptiert einen Strom, dessen verbleibende Frische mindestens dem aktuellen Alter plus der angegebenen Sekunden entspricht ; er will eine Antwort, die mindestens noch so viele Sekunden frisch bleibt.
must-revalidate: Ist must-revalidate in einer SETUP-Antwort eines Caches enthalten, DARF dieser Cache den Eintrag nach dem Veralten nicht ohne erneute Prüfung beim Ursprungsserver für eine Folgeanfrage verwenden, sobald die gecachte Antwort allein nach Expires des Ursprungs veraltet ist (Ende-zu-Ende-Revalidierung jedes Mal).
12.9 Conference
Dieses Anfrage-Header-Feld verbindet logisch eine bestehende Konferenz mit einem RTSP-Strom. Die conference-id darf für dieselbe RTSP-Sitzung nicht wechseln.
Conference = "Conference" ":" conference-id
Beispiel: Conference: [email protected]%20Starr
Bei ungültiger conference-id: Antwortcode 452 (Conference Not Found).
12.10 Connection
Siehe [H14.10].
12.11 Content-Base
Siehe [H14.11].
12.12 Content-Encoding
Siehe [H14.12].
12.13 Content-Language
Siehe [H14.13].
12.14 Content-Length
Enthält die Länge des Methodeninhalts (nach dem doppelten CRLF nach dem letzten Header). Anders als bei HTTP MUSS es in allen Nachrichten mit Inhalt jenseits des Header-Teils stehen. Fehlt es, wird Null angenommen. Auslegung gemäß [H14.14].
12.15 Content-Location
Siehe [H14.15].
12.16 Content-Type
Siehe [H14.18]. Praktisch beschränken sich geeignete Inhaltstypen oft auf Präsentationsbeschreibungen und Parameter-Wert-Typen.
12.17 CSeq
CSeq gibt die Sequenznummer für ein RTSP-Anfrage-/Antwort-Paar an. MUSS in allen Anfragen und Antworten vorhanden sein. Wiederholte Anfragen behalten dieselbe Nummer.
12.18 Date
Siehe [H14.19].
12.19 Expires
Gibt Datum und Uhrzeit an, nach denen Beschreibung oder Medienstrom als veraltet gilt. DESCRIBE-Antwort: Gültigkeit der Beschreibung. Veraltete Cache-Einträge dürfen normalerweise nicht ohne Validierung zurückgegeben werden (Abschnitt 13). Expires impliziert keine Änderung der Ressource zu diesem Zeitpunkt. Format: HTTP-date [H3.3], MUSS RFC1123-date sein.
Expires = "Expires" ":" HTTP-date
Beispiel: Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0-Clients und -Caches MÜSSEN ungültige Datumsformate einschließlich „0“ als in der Vergangenheit werten. Für „bereits abgelaufen“: Expires gleich Date; für „nie“: etwa ein Jahr in der Zukunft. Server sollten nicht mehr als ein Jahr voraus senden. Ein zukünftiges Expires bei standardmäßig nicht cachebarem Strom bedeutet Cachebarkeit, sofern Cache-Control nichts anderes sagt (Abschnitt 12.8).
12.20 From
Siehe [H14.22].
12.21 Host
Dieses HTTP-Anfrage-Header-Feld wird für RTSP nicht benötigt und sollte still ignoriert werden, falls gesendet.
12.22 If-Match
Siehe [H14.25]. Besonders nützlich für die Integrität der Präsentationsbeschreibung, ob extern (HTTP) geladen oder zwischen DESCRIBE und SETUP garantiert. Der Bezeichner ist opak.
12.23 If-Modified-Since
Mit DESCRIBE und SETUP bedingt. Wurde die Variante seit dem Zeitpunkt nicht geändert, keine Beschreibung bzw. kein Aufbau des Stroms; stattdessen 304 ohne Nachrichtenkörper.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
Beispiel: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
12.24 Last-Modified
Letzte Änderung der Beschreibung bzw. des Medienstroms laut Ursprungsserver [H14.29]. Bei DESCRIBE/ANNOUNCE die Beschreibung, bei SETUP der Strom.
12.25 Location
Siehe [H14.30].
12.26 Proxy-Authenticate
Siehe [H14.33].
12.27 Proxy-Require
Kennzeichnet vom Proxy MÜSSIG unterstützte proxy-sensitive Features. Nicht unterstützte MÜSSEN negativ quittiert werden. Server sollten das Feld wie Require behandeln. Details und Beispiel Abschnitt 12.32.
12.28 Public
Siehe [H14.35].
12.29 Range
Zeitbereich; Einheiten smpte (3.5), npt (3.6), clock (3.7). Byte-Bereiche [H14.36.1] sind in RTSP sinnlos und DÜRFEN NICHT verwendet werden. Optional „time“ in UTC. Server mit Range MÜSSEN NPT verstehen und SOLLTEN SMPTE. Unbekanntes Format: „501 Not Implemented“. Halboffene Intervalle; nur Startzeitpunkte von Medieneinheiten zählen (Beispiel 40-ms-Video wie im englischen Text).
Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range
Beispiel: Range: clock=19960213T143205Z-;time=19970123T143720Z
Analog HTTP/1.1 [2] Byte-Range; Auszug, Wiedergabe bis Ende, von aktueller Position bis Ziel; Startzeitpunkt in der Zukunft möglich, Server kann Ressourcen nicht vorhalten.
12.30 Referer
Siehe [H14.37]. URL der Präsentationsbeschreibung, typisch per HTTP.
12.31 Retry-After
Siehe [H14.38].
12.32 Require
Der Client fragt Optionen ab; der Server MUSS mit Unsupported negieren, was nicht unterstützt wird. So entfällt oft eine Verhandlungsrunde bei passenden Peers.
Require = "Require" ":" 1#option-tag
Beispiel:
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
„funky-feature“ ist das Feature-Tag; die Beziehung zu Funky-Parameter ist fest und wird nicht pro RTSP übertragen. Proxys SOLLTEN unbekannte Features ignorieren; erforderlicher Zwischensupport über Proxy-Require (12.27).
12.33 RTP-Info
Setzt RTP-Parameter in der PLAY-Antwort. url: Strom-URL; seq: erste Sequenznummer (Seek); rtptime: RTP-Zeitstempel zur Range-Antwort (bei Aggregate Control keine Garantie für Konsistenz mit seq). Mapping RTP→NTP allein reicht nicht für RTP→NPT; daher auf dem RTSP-Steuerkanal. Für Drift NPT↔NTP zusätzlich RTCP nutzen.
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
stream-url = "url" "=" url
parameter = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT
Beispiel: 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
1 = normale Wiedergabe/Aufzeichnung. Sonst Verhältnis zur Normalgeschwindigkeit; negativ rückwärts. Ohne abweichendes Speed SOLL die Datenrate unverändert bleiben. Antwort MUSS tatsächlichen Scale-Wert enthalten. Mit Range wirkt der neue Wert zu diesem Zeitpunkt.
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
Beispiel: Scale: -3.5
12.35 Speed
Bitte um Lieferung mit bestimmter Geschwindigkeit; Server-Implementierung OPTIONAL; Standard = Bitrate des Stroms. 2.0 = doppelt so schnell; Null ungültig; mit Range ab diesem Zeitpunkt wirksam.
Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
Beispiel: Speed: 2.5
Beeinflusst Bandbreite; bei UDP RTCP zur Verlusterfassung empfohlen.
12.36 Server
Siehe [H14.39].
12.37 Session
Identifiziert die RTSP-Sitzung (SETUP startet, TEARDOWN auf Präsentations-URL beendet). session-id vom Medienserver (Abschnitt 3.4). Client MUSS sie bei allen zugehörigen Anfragen zurücksenden. Server kann entfallen, wenn andere Identifikation existiert.
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
timeout nur in Antworten; Inaktivität bis Schließen (Anhang A); Sekunden, Standard 60. session-id überdauert Transportsitzungen; mehrere URLs in einer Sitzung möglich, wenn gleicher Server; mehrere Nutzer-Sitzungen für dieselbe URL vom selben Client MÜSSEN unterschiedliche IDs haben. 454 bei ungültiger ID.
12.38 Timestamp
Zeitpunkt des Client-Sendens; nur clientlokal relevant. Server MUSS denselben Wert echoen und KANN Verzögerung in Sekunden anhängen. Für RTT und Retransmissions-Timeout.
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
12.39 Transport
Wählt Transportprotokoll und Parameter (Zieladresse, Kompression, Multicast-TTL, Ports) für einen Strom; ergänzt die Präsentationsbeschreibung. Kommagetrennte Liste nach Präferenz; Parameter mit Semikolon. Änderung bestehender Ströme KANN der Server ablehnen. Bei Client-Liste MUSS der Server genau eine gewählte Option zurückgeben. Spezifikator: transport/profile/lower-transport; RTP/AVP-Default lower-transport = UDP.
Allgemein: unicast|multicast (Standard multicast); fähige Clients MÜSSEN zwei vollständige transport-spec senden. destination: Ziel; Server SOLLTE authentifizieren und Versuche loggen, bevor Medien zu fremden Adressen gelenkt werden; insbesondere bei UDP; TCP allein genügt nicht zur Client-Erkennung; Server SOLLTE Umleitung auf andere Adresse als Befehlsquelle nicht erlauben. source: falls nicht aus RTSP-Endpunkt ableitbar. layers, mode (PLAY|RECORD, Standard PLAY), append (nur mit RECORD; sonst ignorieren; ohne Support MUSS Anfrage abgelehnt werden statt Überschreiben), interleaved (Abschnitt 10.12, z. B. interleaved=4-5). Multicast: ttl. RTP: port, client_port, server_port, ssrc (nur 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
Beispiel: Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
Beschränkt auf einen RTP-Strom; vereinfacht Firewall-Design.
12.40 Unsupported
Listet nicht unterstützte Features. Bei Proxy-Require und Proxy auf dem Pfad MUSS der Proxy eine Antwort mit „551 Option Not Supported“ einfügen. Beispiel 12.32.
12.41 User-Agent
Siehe [H14.42].
12.42 Vary
Siehe [H14.43].
12.43 Via
Siehe [H14.44].
12.44 WWW-Authenticate
Siehe [H14.46].