rfc2326.txt

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

          mode is useful for distributed teaching applications. Several
          parties in the conference may take turns "pushing the remote
          control buttons."

   Addition of media to an existing presentation:
          Particularly for live presentations, it is useful if the
          server can tell the client about additional media becoming
          available.

   RTSP requests may be handled by proxies, tunnels and caches as in
   HTTP/1.1 [2].

1.2 Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

1.3 Terminology

   Some of the terminology has been adopted from HTTP/1.1 [2]. Terms not
   listed here are defined as in HTTP/1.1.

   Aggregate control:
          The control of the multiple streams using a single timeline by
          the server. For audio/video feeds, this means that the client
          may issue a single play or pause message to control both the
          audio and video feeds.

   Conference:
          a multiparty, multimedia presentation, where "multi" implies
          greater than or equal to one.





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


   Client:
          The client requests continuous media data from the media
          server.

   Connection:
          A transport layer virtual circuit established between two
          programs for the purpose of communication.

   Container file:
          A file which may contain multiple media streams which often
          comprise a presentation when played together. RTSP servers may
          offer aggregate control on these files, though the concept of
          a container file is not embedded in the protocol.

   Continuous media:
          Data where there is a timing relationship between source and
          sink; that is, the sink must reproduce the timing relationship
          that existed at the source. The most common examples of
          continuous media are audio and motion video. Continuous media
          can be real-time (interactive), where there is a "tight"
          timing relationship between source and sink, or streaming
          (playback), where the relationship is less strict.

   Entity:
          The information transferred as the payload of a request or
          response. An entity consists of metainformation in the form of
          entity-header fields and content in the form of an entity-
          body, as described in Section 8.

   Media initialization:
          Datatype/codec specific initialization. This includes such
          things as clockrates, color tables, etc. Any transport-
          independent information which is required by a client for
          playback of a media stream occurs in the media initialization
          phase of stream setup.

   Media parameter:
          Parameter specific to a media type that may be changed before
          or during stream playback.

   Media server:
          The server providing playback or recording services for one or
          more media streams. Different media streams within a
          presentation may originate from different media servers. A
          media server may reside on the same or a different host as the
          web server the presentation is invoked from.





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


   Media server indirection:
          Redirection of a media client to a different media server.

   (Media) stream:
          A single media instance, e.g., an audio stream or a video
          stream as well as a single whiteboard or shared application
          group. When using RTP, a stream consists of all RTP and RTCP
          packets created by a source within an RTP session. This is
          equivalent to the definition of a DSM-CC stream([5]).

   Message:
          The basic unit of RTSP communication, consisting of a
          structured sequence of octets matching the syntax defined in
          Section 15 and transmitted via a connection or a
          connectionless protocol.

   Participant:
          Member of a conference. A participant may be a machine, e.g.,
          a media record or playback server.

   Presentation:
          A set of one or more streams presented to the client as a
          complete media feed, using a presentation description as
          defined below. In most cases in the RTSP context, this implies
          aggregate control of those streams, but does not have to.

   Presentation description:
          A presentation description contains information about one or
          more media streams within a presentation, such as the set of
          encodings, network addresses and information about the
          content.  Other IETF protocols such as SDP (RFC 2327 [6]) use
          the term "session" for a live presentation. The presentation
          description may take several different formats, including but
          not limited to the session description format SDP.

   Response:
          An RTSP response. If an HTTP response is meant, that is
          indicated explicitly.

   Request:
          An RTSP request. If an HTTP request is meant, that is
          indicated explicitly.

   RTSP session:
          A complete RTSP "transaction", e.g., the viewing of a movie.
          A session typically consists of a client setting up a
          transport mechanism for the continuous media stream (SETUP),
          starting the stream with PLAY or RECORD, and closing the



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


          stream with TEARDOWN.

   Transport initialization:
          The negotiation of transport information (e.g., port numbers,
          transport protocols) between the client and the server.

1.4 Protocol Properties

   RTSP has the following properties:

   Extendable:
          New methods and parameters can be easily added to RTSP.

   Easy to parse:
          RTSP can be parsed by standard HTTP or MIME parsers.

   Secure:
          RTSP re-uses web security mechanisms. All HTTP authentication
          mechanisms such as basic (RFC 2068 [2, Section 11.1]) and
          digest authentication (RFC 2069 [8]) are directly applicable.
          One may also reuse transport or network layer security
          mechanisms.

   Transport-independent:
          RTSP may use either an unreliable datagram protocol (UDP) (RFC
          768 [9]), a reliable datagram protocol (RDP, RFC 1151, not
          widely used [10]) or a reliable stream protocol such as TCP
          (RFC 793 [11]) as it implements application-level reliability.

   Multi-server capable:
          Each media stream within a presentation can reside on a
          different server. The client automatically establishes several
          concurrent control sessions with the different media servers.
          Media synchronization is performed at the transport level.

   Control of recording devices:
          The protocol can control both recording and playback devices,
          as well as devices that can alternate between the two modes
          ("VCR").

   Separation of stream control and conference initiation:
          Stream control is divorced from inviting a media server to a
          conference. The only requirement is that the conference
          initiation protocol either provides or can be used to create a
          unique conference identifier. In particular, SIP [12] or H.323
          [13] may be used to invite a server to a conference.





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


   Suitable for professional applications:
          RTSP supports frame-level accuracy through SMPTE time stamps
          to allow remote digital editing.

   Presentation description neutral:
          The protocol does not impose a particular presentation
          description or metafile format and can convey the type of
          format to be used. However, the presentation description must
          contain at least one RTSP URI.

   Proxy and firewall friendly:
          The protocol should be readily handled by both application and
          transport-layer (SOCKS [14]) firewalls. A firewall may need to
          understand the SETUP method to open a "hole" for the UDP media
          stream.

   HTTP-friendly:
          Where sensible, RTSP reuses HTTP concepts, so that the
          existing infrastructure can be reused. This infrastructure
          includes PICS (Platform for Internet Content Selection
          [15,16]) for associating labels with content. However, RTSP
          does not just add methods to HTTP since the controlling
          continuous media requires server state in most cases.

   Appropriate server control:
          If a client can start a stream, it must be able to stop a
          stream. Servers should not start streaming to clients in such
          a way that clients cannot stop the stream.

   Transport negotiation:
          The client can negotiate the transport method prior to
          actually needing to process a continuous media stream.

   Capability negotiation:
          If basic features are disabled, there must be some clean
          mechanism for the client to determine which methods are not
          going to be implemented. This allows clients to present the
          appropriate user interface. For example, if seeking is not
          allowed, the user interface must be able to disallow moving a
          sliding position indicator.

     An earlier requirement in RTSP was multi-client capability.
     However, it was determined that a better approach was to make sure
     that the protocol is easily extensible to the multi-client
     scenario. Stream identifiers can be used by several control
     streams, so that "passing the remote" would be possible. The
     protocol would not address how several clients negotiate access;
     this is left to either a "social protocol" or some other floor



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


     control mechanism.

1.5 Extending RTSP

   Since not all media servers have the same functionality, media
   servers by necessity will support different sets of requests. For
   example:

     * A server may only be capable of playback thus has no need to
       support the RECORD request.
     * A server may not be capable of seeking (absolute positioning) if
       it is to support live events only.
     * Some servers may not support setting stream parameters and thus
       not support GET_PARAMETER and SET_PARAMETER.

   A server SHOULD implement all header fields described in Section 12.

   It is up to the creators of presentation descriptions not to ask the
   impossible of a server. This situation is similar in HTTP/1.1 [2],
   where the methods described in [H19.6] are not likely to be supported
   across all servers.

   RTSP can be extended in three ways, listed here in order of the
   magnitude of changes supported:

     * Existing methods can be extended with new parameters, as long as
       these parameters can be safely ignored by the recipient. (This is
       equivalent to adding new parameters to an HTML tag.) If the
       client needs negative acknowledgement when a method extension is
       not supported, a tag corresponding to the extension may be added
       in the Require: field (see Section 12.32).
     * New methods can be added. If the recipient of the message does
       not understand the request, it responds with error code 501 (Not
       implemented) and the sender should not attempt to use this method