| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "410" ; Gone
| "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "451" ; Parameter Not Understood
| "452" ; Conference Not Found
| "453" ; Not Enough Bandwidth
| "454" ; Session Not Found
| "455" ; Method Not Valid in This State
| "456" ; Header Field Not Valid for Resource
| "457" ; Invalid Range
| "458" ; Parameter Is Read-Only
| "459" ; Aggregate operation not allowed
| "460" ; Only aggregate operation allowed
| "461" ; Unsupported transport
| "462" ; Destination unreachable
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; RTSP Version not supported
| "551" ; Option not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.
Code reason
100 Continue all
200 OK all
201 Created RECORD
250 Low on Storage Space RECORD
300 Multiple Choices all
301 Moved Permanently all
302 Moved Temporarily all
303 See Other all
305 Use Proxy all
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
410 Gone all
411 Length Required all
412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all
414 Request-URI Too Long all
415 Unsupported Media Type all
451 Invalid parameter SETUP
452 Illegal Conference Identifier SETUP
453 Not Enough Bandwidth SETUP
454 Session Not Found all
455 Method Not Valid In This State all
456 Header Field Not Valid all
457 Invalid Range PLAY
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all
461 Unsupported Transport all
462 Destination Unreachable all
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
551 Option not support all
Table 1: Status codes and their usage with RTSP methods
7.1.2 Response Header Fields
The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the
server and about further access to the resource identified by the
Request-URI.
response-header = Location ; Section 12.25
| Proxy-Authenticate ; Section 12.26
| Public ; Section 12.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44
Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields.
8 Entity
Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers.
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields
Entity-header fields define optional metainformation about the
entity-body or, if no body is present, about the resource identified
by the request.
entity-header = Allow ; Section 12.4
| Content-Base ; Section 12.11
| Content-Encoding ; Section 12.12
| Content-Language ; Section 12.13
| Content-Length ; Section 12.14
| Content-Location ; Section 12.15
| Content-Type ; Section 12.16
| Expires ; Section 12.19
| Last-Modified ; Section 12.24
| extension-header
extension-header = message-header
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2 Entity Body
See [H7.2]
9 Connections
RTSP requests can be transmitted in several different ways:
* persistent transport connections used for several
request-response transactions;
* one connection per request/response transaction;
* connectionless mode.
The type of transport connection is defined by the RTSP URI (Section
3.2). For the scheme "rtsp", a persistent connection is assumed,
while the scheme "rtspu" calls for RTSP requests to be sent without
setting up a connection.
Unlike HTTP, RTSP allows the media server to send requests to the
media client. However, this is only supported for persistent
connections, as the media server otherwise has no reliable way of
reaching the client. Also, this is the only way that requests from
media server to client are likely to traverse firewalls.
9.1 Pipelining
A client that supports persistent connections or connectionless mode
MAY "pipeline" its requests (i.e., send multiple requests without
waiting for each response). A server MUST send its responses to those
requests in the same order that the requests were received.
9.2 Reliability and Acknowledgements
Requests are acknowledged by the receiver unless they are sent to a
multicast group. If there is no acknowledgement, the sender may
resend the same message after a timeout of one round-trip time (RTT).
The round-trip time is estimated as in TCP (RFC1123) [18], with an
initial round-trip value of 500 ms. An implementation MAY cache the
last RTT measurement as the initial value for future connections.
If a reliable transport protocol is used to carry RTSP, requests MUST
NOT be retransmitted; the RTSP application MUST instead rely on the
underlying transport to provide reliability.
If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, it is possible that each packet
loss results in two retransmissions. The receiver cannot typically
take advantage of the application-layer retransmission since the
transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver.
If the packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the congestion.
If RTSP is used over a small-RTT LAN, standard procedures for
optimizing initial TCP round trip estimates, such as those used in
T/TCP (RFC1644) [22], can be beneficial.
The Timestamp header (Section 12.38) is used to avoid the
retransmission ambiguity problem [23, p. 301] and obviates the need
for Karn's algorithm.
Each request carries a sequence number in the CSeq header (Section
12.17), which is incremented by one for each distinct request
transmitted. If a request is repeated because of lack of
acknowledgement, the request MUST carry the original sequence number
(i.e., the sequence number is not incremented).
Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
support UDP. The default port for the RTSP server is 554 for both UDP
and TCP.
A number of RTSP packets destined for the same control end point may
be packed into a single lower-layer PDU or encapsulated into a TCP
stream. RTSP data MAY be interleaved with RTP and RTCP packets.
Unlike HTTP, an RTSP message MUST contain a Content-Length header
whenever that message contains a payload. Otherwise, an RTSP packet
is terminated with an empty line immediately following the last
message header.
10 Method Definitions
The method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive. New
methods may be defined in the future. Method names may not start with
a $ character (decimal 24) and must be a token. Methods are
summarized in Table 2.
method direction object requirement
DESCRIBE C->S P,S recommended
ANNOUNCE C->S, S->C P,S optional
GET_PARAMETER C->S, S->C P,S optional
OPTIONS C->S, S->C P,S required
(S->C: optional)
PAUSE C->S P,S recommended
PLAY C->S P,S required
RECORD C->S P,S optional
REDIRECT S->C P,S optional
SETUP C->S S required
SET_PARAMETER C->S, S->C P,S optional
TEARDOWN C->S P,S required
Table 2: Overview of RTSP methods, their direction, and what
objects (P: presentation, S: stream) they operate on
Notes on Table 2: PAUSE is recommended, but not required in that a
fully functional server can be built that does not support this
method, for example, for live feeds. If a server does not support a
particular method, it MUST return "501 Not Implemented" and a client
SHOULD not try this method again for this server.
10.1 OPTIONS
The behavior is equivalent to that described in [H9.2]. An OPTIONS
request may be issued at any time, e.g., if the client is about to
try a nonstandard request. It does not influence server state.
Example:
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Note that these are necessarily fictional features (one would hope
that we would not purposefully overlook a truly useful feature just
so that we could have a strong example in this section).
10.2 DESCRIBE
The DESCRIBE method retrieves the description of a presentation or
media object identified by the request URL from a server. It may use
the Accept header to specify the description formats that the client
understands. The server responds with a description of the requested
resource. The DESCRIBE reply-response pair constitutes the media
initialization phase of RTSP.
Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
The DESCRIBE response MUST contain all media initialization
information for the resource(s) that it describes. If a media client
obtains a presentation description from a source other than DESCRIBE
and that description contains a complete set of media initialization
parameters, the client SHOULD use those parameters and not then
request a description for the same media via RTSP.
Additionally, servers SHOULD NOT use the DESCRIBE response as a means
of media indirection.
Clear ground rules need to be established so that clients have an
unambiguous means of knowing when to request media initialization
information via DESCRIBE, and when not to. By forcing a DESCRIBE
response to contain all media initialization for the set of streams
that it describes, and discouraging use of DESCRIBE for media
indirection, we avoid looping problems that might result from other
approaches.
Media initialization is a requirement for any RTSP-based system,
but the RTSP specification does not dictate that this must be done
via the DESCRIBE method. There are three ways that an RTSP client
may receive initialization information:
* via RTSP's DESCRIBE method;
* via some other protocol (HTTP, email attachment, etc.);
* via the command line or standard input (thus working as a browser
helper application launched with an SDP file or other media
initialization format).
In the interest of practical interoperability, it is highly
recommended that minimal servers support the DESCRIBE method, and
highly recommended that minimal clients support the ability to act
as a "helper application" that accepts a media initialization file
from standard input, command line, and/or other means that are
appropriate to the operating environment of the client.
10.3 ANNOUNCE
The ANNOUNCE method serves two purposes:
When sent from client to server, ANNOUNCE posts the description of a
presentation or media object identified by the request URL to a
server. When sent from server to client, ANNOUNCE updates the session
description in real-time.
If a new media stream is added to a presentation (e.g., during a live
presentation), the whole presentation description should be sent
again, rather than just the additional components, so that components
can be deleted.
Example:
C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Content-Type: application/sdp
Content-Length: 332
v=0
o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
S->C: RTSP/1.0 200 OK
CSeq: 312
10.4 SETUP
The SETUP request for a URI specifies the transport mechanism to be
used for the streamed media. A client can issue a SETUP request for a
stream that is already playing to change transport parameters, which
a server MAY allow. If it does not allow this, it MUST respond with
error "455 Method Not Valid In This State". For the benefit of any
intervening firewalls, a client must indicate the transport
parameters even if it has no influence over these parameters, for
example, where the server advertises a fixed multicast address.
Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media
initialization.
The Transport header specifies the transport parameters acceptable to
the client for data transmission; the response will contain the
transport parameters selected by the server.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
The server generates session identifiers in response to SETUP
requests. If a SETUP request to a server includes a session
identifier, the server MUST bundle this setup request into the
existing session or return error "459 Aggregate Operation Not
Allowed" (see Section 11.3.10).
10.5 PLAY
The PLAY method tells the server to start sending data via the
mechanism specified in SETUP. A client MUST NOT issue a PLAY request
until any outstanding SETUP requests have been acknowledged as
successful.
The PLAY request positions the normal play time to the beginning of
the range specified and delivers stream data until the end of the
range is reached. PLAY requests may be pipelined (queued); a server
MUST queue PLAY requests to be executed in order. That is, a PLAY
request arriving while a previous PLAY request is still active is
delayed until the first has been completed.
This allows precise editing.
For example, regardless of how closely spaced the two PLAY requests
in the example below arrive, the server will first play seconds 10
through 15, then, immediately following, seconds 20 to 25, and
finally seconds 30 through the end.
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
See the description of the PAUSE request for further examples.
A PLAY request without a Range header is legal. It starts playing a
stream from the beginning unless the stream has been paused. If a
stream has been paused via PAUSE, stream delivery resumes at the
pause point. If a stream is playing, such a PLAY request causes no
further action and can be used by the client to test server liveness.
The Range header may also contain a time parameter. This parameter
specifies a time in UTC at which the playback should start. If the
message is received after the specified time, playback is started
immediately. The time parameter may be used to aid in synchronization
of streams obtained from different sources.
For a on-demand stream, the server replies with the actual range that
will be played back. This may differ from the requested range if
alignment of the requested range to valid frame boundaries is
required for the media source. If no range is specified in the
request, the current position is returned in the reply. The unit of
the range in the reply is the same as that in the request.
After playing the desired range, the presentation is automatically
paused, as if a PAUSE request had been issued.
The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. The playback is to start
at 15:36 on 23 Jan 1997.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z
S->C: RTSP/1.0 200 OK
CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z
For playing back a recording of a live presentation, it may be
desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
CSeq: 835
Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT
A media server only supporting playback MUST support the npt format
and MAY support the clock and smpte formats.
10.6 PAUSE
The PAUSE request causes the stream delivery to be interrupted
(halted) temporarily. If the request URL names a stream, only
playback and recording of that stream is halted. For example, for
audio, this is equivalent to muting. If the request URL names a
presentation or group of streams, delivery of all currently active
streams within the presentation or group is halted. After resuming
playback or recording, synchronization of the tracks MUST be
maintained. Any server resources are kept, though servers MAY close
the session and free resources after being paused for the duration
specified with the timeout parameter of the Session header in the
SETUP message.
Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
The PAUSE request may contain a Range header specifying when the
stream or presentation is to be halted. We refer to this point as the
"pause point". The header must contain exactly one value rather than
a time range. The normal play time for the stream is set to the pause
point. The pause request becomes effective the first time the server
is encountering the time point specified in any of the currently
pending PLAY requests. If the Range header specifies a time outside
any currently pending PLAY requests, the error "457 Invalid Range" is
returned. If a media unit (such as an audio or video frame) starts
presentation at exactly the pause point, it is not played or
recorded. If the Range header is missing, stream delivery is
interrupted immediately on receipt of the message and the pause point
is set to the current normal play time.
A PAUSE request discards all queued PLAY requests. However, the pause
point in the media stream MUST be maintained. A subsequent PLAY
request without Range header resumes from the pause point.
For example, if the server has play requests for ranges 10 to 15 and
20 to 29 pending and then receives a pause request for NPT 21, it
would start playing the second range and stop at NPT 21. If the pause
request is for NPT 12 and the server is playing at NPT 13 serving the
first play request, the server stops immediately. If the pause
request is for NPT 16, the server stops after completing the first
play request and discards the second play request.
As another example, if a server has received requests to play ranges
10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE
request for NPT=14 would take effect while the server plays the first
range, with the second PLAY request effectively being ignored,
assuming the PAUSE request arrives before the server has started
playing the second, overlapping range. Regardless of when the PAUSE
request arrives, it sets the NPT to 14.
If the server has already sent data beyond the time specified in the
Range header, a PLAY would still resume at that point in time, as it
is assumed that the client has discarded data after that point. This
ensures continuous pause/play cycling without gaps.
10.7 TEARDOWN
The TEARDOWN request stops the stream delivery for the given URI,
freeing the resources associated with it. If the URI is the
presentation URI for this presentation, any RTSP session identifier
associated with the session is no longer valid. Unless all transport
parameters are defined by the session description, a SETUP request
has to be issued before the session can be played again.
Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
10.8 GET_PARAMETER
The GET_PARAMETER request retrieves the value of a parameter of a
presentation or stream specified in the URI. The content of the reply
and response is left to the implementation. GET_PARAMETER with no
entity body may be used to test client or server liveness ("ping").
Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
packets_received
jitter
C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
The "text/parameters" section is only an example type for
parameter. This method is intentionally loosely defined with the
intention that the reply content and response content will be
defined after further experimentation.
10.9 SET_PARAMETER
This method requests to set the value of a parameter for a
presentation or stream specified by the URI.
A request SHOULD only contain a single parameter to allow the client
to determine why a particular request failed. If the request contains
several parameters, the server MUST only act on the request if all of
the parameters can be set successfully. A server MUST allow a
parameter to be set repeatedly to the same value, but it MAY disallow
changing parameter values.
Note: transport parameters for the media stream MUST only be set with
the SETUP command.
Restricting setting transport parameters to SETUP is for the
benefit of firewalls.
The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client does
not want the camera to pan unless it can also tilt to the right
angle at the same time.
Example:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam
The "text/parameters" section is only an example type for
parameter. This method is intentionally loosely defined with the
intention that the reply content and response content will be
defined after further experimentation.
10.10 REDIRECT
A redirect request informs the client that it must connect to another
server location. It contains the mandatory header Location, which
indicates that the client should issue requests for that URL. It may
contain the parameter Range, which indicates when the redirection
takes effect. If the client wants to continue to send or receive
media for this URI, the client MUST issue a TEARDOWN request for the
current session and a SETUP for the new session at the designated
host.
This example request redirects traffic for this URI to the new server
at the given play time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
10.11 RECORD
This method initiates recording a range of media data according to
the presentation description. The timestamp reflects start and end
time (UTC). If no time range is given, use the start or end time
provided in the presentation description. If the session has already
started, commence recording immediately.
The server decides whether to store the recorded data under the
request-URI or another URI. If the server does not use the request-
URI, the response SHOULD be 201 (Created) and contain an entity which
describes the status of the request and refers to the new resource,
and a Location header.
A media server supporting recording of live presentations MUST
support the clock range format; the smpte format does not make sense.
In this example, the media server was previously invited to the
conference indicated.
C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374
10.12 Embedded (Interleaved) Binary Data
Certain firewall designs and other circumstances may force a server
to interleave RTSP methods and stream data. This interleaving should
generally be avoided unless necessary since it complicates client and
server operation and imposes additional overhead. Interleaved binary
data SHOULD only be used if RTSP is carried over TCP.
Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (24 hexadecimal), followed by a one-byte channel identifier,
followed by the length of the encapsulated binary data as a binary,
two-byte integer in network byte order. The stream data follows
immediately afterwards, without a CRLF, but including the upper-layer
protocol headers. Each $ block contains exactly one upper-layer
protocol data unit, e.g., one RTP packet.
The channel identifier is defined in the Transport header with the
interleaved parameter(Section 12.39).
When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. As a default, RTCP packets are
sent on the first available channel higher than the RTP channel. The
client MAY explicitly request RTCP packets on another channel. This
is done by specifying two channels in the interleaved parameter of
the Transport header(Section 12.39).
RTCP is needed for synchronization when two or more streams are
interleaved in such a fashion. Also, this provides a convenient way
to tunnel RTP/RTCP packets through the TCP control connection when
required by the network configuration and transfer them onto UDP
when possible.
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 12345678
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes RTCP packet}
11 Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 1 for a
listing of which status codes may be returned by which requests.
11.1 Success 2xx
11.1.1 250 Low on Storage Space
The server returns this warning after receiving a RECORD request that
it may not be able to fulfill completely due to insufficient storage
space. If possible, the server should use the Range header to
indicate what time period it may still be able to record. Since other
processes on the server may be consuming storage space
simultaneously, a client should take this only as an estimate.
11.2 Redirection 3xx
See [H10.3].
Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the
scope of this specification.
11.3 Client Error 4xx
11.3.1 405 Method Not Allowed
The method specified in the request is not allowed for the resource
identified by the request URI. The response MUST include an Allow
header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a
method not indicated during SETUP, e.g., if a RECORD request is
issued even though the mode parameter in the Transport header only
specified PLAY.
11.3.2 451 Parameter Not Understood
The recipient of the request does not support one or more parameters
contained in the request.
11.3.3 452 Conference Not Found
The conference indicated by a Conference header field is unknown to
the media server.
11.3.4 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation
failure.
11.3.5 454 Session Not Found
The RTSP session identifier in the Session header is missing,
invalid, or has timed out.
11.3.6 455 Method Not Valid in This State
The client or server cannot process this request in its current
state. The response SHOULD contain an Allow header to make error
recovery easier.
11.3.7 456 Header Field Not Valid for Resource
The server could not act on a required request header. For example,
if PLAY contains the Range header field but the stream does not allow
seeking.
11.3.8 457 Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the
presentation.
11.3.9 458 Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can be read but not
modified.
11.3.10 459 Aggregate Operation Not Allowed
The requested method may not be applied on the URL in question since
it is an aggregate (presentation) URL. The method may be applied on a
stream URL.
11.3.11 460 Only Aggregate Operation Allowed
The requested method may not be applied on the URL in question since
it is not an aggregate (presentation) URL. The method may be applied
on the presentation URL.
11.3.12 461 Unsupported Transport
The Transport field did not contain a supported transport
specification.
11.3.13 462 Destination Unreachable
The data transmission channel could not be established because the
client address could not be reached. This error will most likely be
the result of a client attempt to place an invalid Destination
parameter in the Transport field.
11.3.14 551 Option not supported
An option given in the Require or the Proxy-Require fields was not
supported. The Unsupported header should be returned stating the
option for which there is no support.
12 Header Field Definitions
HTTP/1.1 [2] or other, non-standard header fields not listed here
currently have no well-defined meaning and SHOULD be ignored by the
recipient.
Table 3 summarizes the header fields used by RTSP. Type "g"
designates general request headers to be found in both requests and
responses, type "R" designates request headers, type "r" designates
response headers, and type "e" designates entity header fields.
Fields marked with "req." in the column labeled "support" MUST be
implemented by the recipient for a particular method, while fields
marked "opt." are optional. Note that not all fields marked "req."
will be sent in every request of this type. The "req." means only
that client (for response headers) and server (for request headers)
MUST implement the fields. The last column lists the method for which
this header field is meaningful; the designation "entity" refers to
all methods that return a message body. Within this specification,
DESCRIBE and GET_PARAMETER fall into this class.
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
Content-Encoding e req. DESCRIBE, ANNOUNCE
Content-Language e req. DESCRIBE, ANNOUNCE
Content-Length e req. SET_PARAMETER, ANNOUNCE
Content-Length e req. 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
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
Overview of RTSP header fields
12.1 Accept
The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the
response.
The "level" parameter for presentation descriptions is properly
defined as part of the MIME type registration, not here.
See [H14.1] for syntax.
Example of use:
Accept: application/rtsl, application/sdp;level=2
12.2 Accept-Encoding
See [H14.3]
12.3 Accept-Language
See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media
content.
12.4 Allow
The Allow response header field lists the methods supported by the
resource identified by the request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the
resource. An Allow header field must be present in a 405 (Method not
allowed) response.
Example of use:
Allow: SETUP, PLAY, RECORD, SET_PARAMETER
12.5 Authorization
See [H14.8]
12.6 Bandwidth
The Bandwidth request header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to modem retraining.
Bandwidth = "Bandwidth" ":" 1*DIGIT
Example:
Bandwidth: 4000
12.7 Blocksize
This request header field is sent from the client to the media server
asking the server for a particular media packet size. This packet
size does not include lower-layer headers such as IP, UDP, or RTP.
The server is free to use a blocksize which is lower than the one
requested. The server MAY truncate this packet size to the closest
multiple of the minimum, media-specific block size, or override it
with the media-specific size if necessary. The block size MUST be a
positive decimal number, measured in octets. The server only returns
an error (416) if the value is syntactically invalid.
12.8 Cache-Control
The Cache-Control general header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the
request/response chain.
Cache directives must be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache-
directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does not govern the caching of
responses as for HTTP, but rather of the stream identified by the
SETUP request. Responses to RTSP requests are not cacheable, except
for responses to 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:
Indicates that the media stream MUST NOT be cached anywhere.
This allows an origin server to prevent caching even by caches
that have been configured to return stale responses to client
requests.
public:
Indicates that the media stream is cacheable by any cache.
private:
Indicates that the media stream is intended for a single user
and MUST NOT be cached by a shared cache. A private (non-
shared) cache may cache the media stream.
no-transform:
An intermediate cache (proxy) may find it useful to convert
the media type of a certain stream. A proxy might, for
example, convert between video formats to save cache space or
to reduce the amount of traffic on a slow link. Serious
operational problems may occur, however, when these
transformations have been applied to streams intended for
certain kinds of applications. For example, applications for
medical imaging, scientific data analysis and those using
end-to-end authentication all depend on receiving a stream
that is bit-for-bit identical to the original entity-body.
Therefore, if a response includes the no-transform directive,
an intermediate cache or proxy MUST NOT change the encoding of
the stream. Unlike HTTP, RTSP does not provide for partial
transformation at this point, e.g., allowing translation into
a different language.
only-if-cached:
In some cases, such as times of extremely poor network
connectivity, a client may want a cache to return only those
media streams that it currently has stored, and not to receive
these from the origin server. To do this, the client may
include the only-if-cached directive in a request. If it
receives this directive, a cache SHOULD either respond using a
cached media stream that is consistent with the other
constraints of the request, or respond with a 504 (Gateway
Timeout) status. However, if a group of caches is being
operated as a unified system with good internal connectivity,
such a request MAY be forwarded within that group of caches.
max-stale:
Indicates that the client is willing to accept a media stream
that has exceeded its expiration time. If max-stale is
assigned a value, then the client is willing to accept a
response that has exceeded its expiration time by no more than
the specified number of seconds. If no value is assigned to
max-stale, then the client is willing to accept a stale
response of any age.
min-fresh:
Indicates that the client is willing to accept a media stream
whose freshness lifetime is no less than its current age plus
the specified time in seconds. That is, the client wants a
response that will still be fresh for at least the specified
number of seconds.
must-revalidate:
When the must-revalidate directive is present in a SETUP
response received by a cache, that cache MUST NOT use the
entry after it becomes stale to respond to a subsequent
request without first revalidating it with the origin server.
That is, the cache must do an end-to-end revalidation every
time, if, based solely on the origin server's Expires, the
cached response is stale.)
12.9 Conference
This request header field establishes a logical connection between a
pre-established conference and an RTSP stream. The conference-id must
not be changed for the same RTSP session.
Conference = "Conference" ":" conference-id Example:
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
A response code of 452 (452 Conference Not Found) is returned if the
conference-id is not valid.
12.10 Connection
See [H14.10]
12.11 Content-Base
See [H14.11]
12.12 Content-Encoding
See [H14.12]
12.13 Content-Language
See [H14.13]
12.14 Content-Length
This field contains the length of the content of the method (i.e.
after the double CRLF following the last header). Unlike HTTP, it
MUST be included in all messages that carry content beyond the header
portion of the message. If it is missing, a default value of zero is
assumed. It is interpreted according to [H14.14].
12.15 Content-Location
See [H14.15]
12.16 Content-Type
See [H14.18]. Note that the content types suitable for RTSP are
likely to be restricted in practice to presentation descriptions and
parameter-value types.
12.17 CSeq
The CSeq field specifies the sequence number for an RTSP request-
response pair. This field MUST be present in all requests and
responses. For every RTSP request containing the given sequence
number, there will be a corresponding response having the same
number. Any retransmitted request must contain the same sequence
number as the original (i.e. the sequence number is not incremented
for retransmissions of the same request).
12.18 Date
See [H14.19].
12.19 Expires
The Expires entity-header field gives a date and time after which the
description or media-stream should be considered stale. The
interpretation depends on the method:
DESCRIBE response:
The Expires header indicates a date and time after which the
description should be considered stale.
A stale cache entry may not normally be returned by a cache (either a
proxy cache or an user agent cache) unless it is first validated with
the origin server (or with an intermediate cache that has a fresh
copy of the entity). See section 13 for further discussion of the
expiration model.
The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that
time.
The format is an absolute date and time as defined by HTTP-date in
[H3.3]; it MUST be in RFC1123-date format:
Expires = "Expires" ":" HTTP-date
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0 clients and caches MUST treat other invalid date formats,
especially including the value "0", as having occurred in the past
(i.e., "already expired").
To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server should use an Expires
date approximately one year from the time the response is sent.
RTSP/1.0 servers should not send Expires dates more than one year in
the future.
The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field (Section 12.8).
12.20 From
See [H14.22].
12.21 Host
This HTTP request header field is not needed for RTSP. It should be
silently ignored if sent.
12.22 If-Match
See [H14.25].
This field is especially useful for ensuring the integrity of the
presentation description, in both the case where it is fetched via
means external to RTSP (such as HTTP), or in the case where the
server implementation is guaranteeing the integrity of the
description between the time of the DESCRIBE message and the SETUP
message.
The identifier is an opaque identifier, and thus is not specific to
any particular session description language.
12.23 If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (not modified)
response will be returned without any message-body.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
12.24 Last-Modified
The Last-Modified entity-header field indicates the date and time at
which the origin server believes the presentation description or
media stream was last modified. See [H14.29]. For the methods
DESCRIBE or ANNOUNCE, the header field indicates the last
modification date and time of the description, for SETUP that of the
media stream.
12.25 Location
See [H14.30].
12.26 Proxy-Authenticate
See [H14.33].
12.27 Proxy-Require
The Proxy-Require header is used to indicate proxy-sensitive features
that MUST be supported by the proxy. Any Proxy-Require header
features that are not supported by the proxy MUST be negatively