rfc2326.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,497 行 · 第 1/5 页

   smpte-range  =   smpte-type "=" smpte-time "-" [ smpte-time ]
   smpte-type   =   "smpte" | "smpte-30-drop" | "smpte-25"
                                   ; other timecodes may be added
   smpte-time   =   1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
                       [ "." 1*2DIGIT ]

   Examples:
     smpte=10:12:33:20-
     smpte=10:07:33-
     smpte=10:07:00-10:07:33:05.01
     smpte-25=10:07:00-10:07:33:05.01

3.6 Normal Play Time

   Normal play time (NPT) indicates the stream absolute position
   relative to the beginning of the presentation. The timestamp consists
   of a decimal fraction. The part left of the decimal may be expressed
   in either seconds or hours, minutes, and seconds. The part right of
   the decimal point measures fractions of a second.

   The beginning of a presentation corresponds to 0.0 seconds. Negative
   values are not defined. The special constant now is defined as the
   current instant of a live event. It may be used only for live events.

   NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the
   viewer associates with a program. It is often digitally displayed on
   a VCR. NPT advances normally when in normal play mode (scale = 1),
   advances at a faster rate when in fast scan forward (high positive
   scale ratio), decrements when in scan reverse (high negative scale
   ratio) and is fixed in pause mode. NPT is (logically) equivalent to
   SMPTE time codes." [5]

   npt-range    =   ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
   npt-time     =   "now" | npt-sec | npt-hhmmss
   npt-sec      =   1*DIGIT [ "." *DIGIT ]
   npt-hhmmss   =   npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
   npt-hh       =   1*DIGIT     ; any positive number
   npt-mm       =   1*2DIGIT    ; 0-59
   npt-ss       =   1*2DIGIT    ; 0-59

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

     The syntax conforms to ISO 8601. The npt-sec notation is optimized
     for automatic generation, the ntp-hhmmss notation for consumption
     by human readers. The "now" constant allows clients to request to



Schulzrinne, et. al.        Standards Track                    [Page 17]

RFC 2326              Real Time Streaming Protocol            April 1998


     receive the live feed rather than the stored or time-delayed
     version. This is needed since neither absolute time nor zero time
     are appropriate for this case.

3.7 Absolute Time

     Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT).
     Fractions of a second may be indicated.

     utc-range    =   "clock" "=" utc-time "-" [ utc-time ]
     utc-time     =   utc-date "T" utc-time "Z"
     utc-date     =   8DIGIT                    ; < YYYYMMDD >
     utc-time     =   6DIGIT [ "." fraction ]   ; < HHMMSS.fraction >

     Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
     UTC:

     19961108T143720.25Z

3.8 Option Tags

   Option tags are unique identifiers used to designate new options in
   RTSP. These tags are used in Require (Section 12.32) and Proxy-
   Require (Section 12.27) header fields.

   Syntax:

     option-tag   =   1*xchar

   The creator of a new RTSP option should either prefix the option with
   a reverse domain name (e.g., "com.foo.mynewfeature" is an apt name
   for a feature whose inventor can be reached at "foo.com"), or
   register the new option with the Internet Assigned Numbers Authority
   (IANA).

3.8.1 Registering New Option Tags with IANA

   When registering a new RTSP option, the following information should
   be provided:

     * Name and description of option. The name may be of any length,
       but SHOULD be no more than twenty characters long. The name MUST
       not contain any spaces, control characters or periods.
     * Indication of who has change control over the option (for
       example, IETF, ISO, ITU-T, other international standardization
       bodies, a consortium or a particular company or group of
       companies);




Schulzrinne, et. al.        Standards Track                    [Page 18]

RFC 2326              Real Time Streaming Protocol            April 1998


     * A reference to a further description, if available, for example
       (in order of preference) an RFC, a published paper, a patent
       filing, a technical report, documented source code or a computer
       manual;
     * For proprietary options, contact information (postal and email
       address);

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]




Schulzrinne, et. al.        Standards Track                    [Page 19]

RFC 2326              Real Time Streaming Protocol            April 1998


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.



Schulzrinne, et. al.        Standards Track                    [Page 20]

RFC 2326              Real Time Streaming Protocol            April 1998


       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.






Schulzrinne, et. al.        Standards Track                    [Page 21]

RFC 2326              Real Time Streaming Protocol            April 1998


     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.