Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2326

Real Time Streaming Protocol (RTSP)

Pages: 92
Obsoleted by:  7826
Part 2 of 4 – Pages 19 to 41
First   Prev   Next

ToP   noToC   RFC2326 - Page 19   prevText
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]
ToP   noToC   RFC2326 - Page 20
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.
ToP   noToC   RFC2326 - Page 21
       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.
ToP   noToC   RFC2326 - Page 22
     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.
ToP   noToC   RFC2326 - Page 23
   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.
ToP   noToC   RFC2326 - Page 24
   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
ToP   noToC   RFC2326 - Page 25
   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
ToP   noToC   RFC2326 - Page 26
   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.
ToP   noToC   RFC2326 - Page 27
   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.
ToP   noToC   RFC2326 - Page 28
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
ToP   noToC   RFC2326 - Page 29
     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.
ToP   noToC   RFC2326 - Page 30
      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).
ToP   noToC   RFC2326 - Page 31
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
ToP   noToC   RFC2326 - Page 32
     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
ToP   noToC   RFC2326 - Page 33
           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
ToP   noToC   RFC2326 - Page 34
   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.
ToP   noToC   RFC2326 - Page 35
   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.
ToP   noToC   RFC2326 - Page 36
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
ToP   noToC   RFC2326 - Page 37
   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
ToP   noToC   RFC2326 - Page 38
     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
ToP   noToC   RFC2326 - Page 39
           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.
ToP   noToC   RFC2326 - Page 40
   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
ToP   noToC   RFC2326 - Page 41
           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)

Next Section