RFC 2326
Real Time Streaming Protocol (RTSP)
4 RTSP Message RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but receivers should be prepared to also interpret CR and LF by themselves as line terminators. Text-based protocols make it easier to add optional parameters in a self-describing manner. Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if done carefully, also allow easy implementation of research prototypes in scripting languages such as Tcl, Visual Basic and Perl. The 10646 character set avoids tricky character set switching, but is invisible to the application as long as US-ASCII is being used. This is also the encoding used for RTCP. ISO 8859-1 translates directly into Unicode with a high-order octet of zero. ISO 8859-1 characters with the most-significant bit set are represented as 1100001x 10xxxxxx. (See RFC 2279 [21]) RTSP messages can be carried over any lower-layer transport protocol that is 8-bit clean. Requests contain methods, the object the method is operating upon and parameters to further describe the method. Methods are idempotent, unless otherwise noted. Methods are also designed to require little or no state maintenance at the media server. 4.1 Message Types See [H4.1] 4.2 Message Headers See [H4.2] 4.3 Message Body See [H4.3]
4.4 Message Length When a message body is included with a message, the length of that body is determined by one of the following (in order of precedence): 1. Any response message which MUST NOT include a message body (such as the 1xx, 204, and 304 responses) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. (Note: An empty line consists of only CRLF.) 2. If a Content-Length header field (section 12.14) is present, its value in bytes represents the length of the message-body. If this header field is not present, a value of zero is assumed. 3. By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.) Note that RTSP does not (at present) support the HTTP/1.1 "chunked" transfer coding(see [H3.6]) and requires the presence of the Content-Length header field. Given the moderate length of presentation descriptions returned, the server should always be able to determine its length, even if it is generated dynamically, making the chunked transfer encoding unnecessary. Even though Content-Length must be present if there is any entity body, the rules ensure reasonable behavior even if the length is not given explicitly. 5 General Header Fields See [H4.5], except that Pragma, Transfer-Encoding and Upgrade headers are not defined: general-header = Cache-Control ; Section 12.8 | Connection ; Section 12.10 | Date ; Section 12.18 | Via ; Section 12.43 6 Request A request message from a client to a server or vice versa includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
Request = Request-Line ; Section 6.1
*( general-header ; Section 5
| request-header ; Section 6.2
| entity-header ) ; Section 8.1
CRLF
[ message-body ] ; Section 4.3
6.1 Request Line
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method = "DESCRIBE" ; Section 10.2
| "ANNOUNCE" ; Section 10.3
| "GET_PARAMETER" ; Section 10.8
| "OPTIONS" ; Section 10.1
| "PAUSE" ; Section 10.6
| "PLAY" ; Section 10.5
| "RECORD" ; Section 10.11
| "REDIRECT" ; Section 10.10
| "SETUP" ; Section 10.4
| "SET_PARAMETER" ; Section 10.9
| "TEARDOWN" ; Section 10.7
| extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
6.2 Request Header Fields
request-header = Accept ; Section 12.1
| Accept-Encoding ; Section 12.2
| Accept-Language ; Section 12.3
| Authorization ; Section 12.5
| From ; Section 12.20
| If-Modified-Since ; Section 12.23
| Range ; Section 12.29
| Referer ; Section 12.30
| User-Agent ; Section 12.41
Note that in contrast to HTTP/1.1 [2], RTSP requests always contain
the absolute URL (that is, including the scheme, host and port)
rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URL, but
clients are supposed to use the Host request header. This is purely
needed for backward-compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP.
The asterisk "*" in the Request-URI means that the request does not
apply to a particular resource, but to the server itself, and is only
allowed when the method used does not necessarily apply to a
resource. One example would be:
OPTIONS * RTSP/1.0
7 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some
HTTP codes. The valid response codes and the methods they can be used
with are defined in Table 1.
After receiving and interpreting a request message, the recipient
responds with an RTSP response message.
Response = Status-Line ; Section 7.1
*( general-header ; Section 5
| response-header ; Section 7.1.2
| entity-header ) ; Section 8.1
CRLF
[ message-body ] ; Section 4.3
7.1 Status-Line
The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code, and the
textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence.
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
7.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully
defined in Section 11. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason-
Phrase.
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:
* 1xx: Informational - Request received, continuing process
* 2xx: Success - The action was successfully received, understood,
and accepted
* 3xx: Redirection - Further action must be taken in order to
complete the request
* 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
* 5xx: Server Error - The server failed to fulfill an apparently
valid request
The individual values of the numeric status codes defined for
RTSP/1.0, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only recommended
- they may be replaced by local equivalents without affecting the
protocol. Note that RTSP adopts most HTTP/1.1 [2] status codes and
adds RTSP-specific status codes starting at x50 to avoid conflicts
with newly defined HTTP status codes.
Status-Code = "100" ; Continue
| "200" ; OK
| "201" ; Created
| "250" ; Low on Storage Space
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "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 (RFC 1123) [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 (RFC 1644) [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}
(page 41 continued on part 3)
