11.  Capability Handling

   This section describes the available capability-handling mechanism
   that allows RTSP to be extended.  Extensions to this version of the
   protocol are basically done in two ways.  Firstly, new headers can be
   added.  Secondly, new methods can be added.  The capability-handling
   mechanism is designed to handle both cases.

   When a method is added, the involved parties can use the OPTIONS
   method to discover whether it is supported.  This is done by issuing
   an OPTIONS request to the other party.  Depending on the URI, it will
   either apply in regard to a certain media resource, the whole server
   in general, or simply the next hop.  The OPTIONS response MUST
   contain a Public header that declares all methods supported for the
   indicated resource.

   It is not necessary to use OPTIONS to discover support of a method,
   as the client could simply try the method.  If the receiver of the
   request does not support the method, it will respond with an error
   code indicating the method is either not implemented (501) or does
   not apply for the resource (405).  The choice between the two
   discovery methods depends on the requirements of the service.

   Feature tags are defined to handle functionality additions that are
   not new methods.  Each feature tag represents a certain block of
   functionality.  The amount of functionality that a feature tag
   represents can vary significantly.  For example, a feature tag can
   represent the functionality a single RTSP header provides.  Another
   feature tag can represent much more functionality, such as the
   "play.basic" feature tag (Section 11.1), which represents the minimal
   media delivery for playback implementation.

   Feature tags are used to determine whether the client, server, or
   proxy supports the functionality that is necessary to achieve the
   desired service.  To determine support of a feature tag, several
   different headers can be used, each explained below:

   Supported:  This header is used to determine the complete set of
         functionality that both client and server have, in general, and
         is not dependent on a specific resource.  The intended usage is
         to determine before one needs to use a functionality that it is
         supported.  It can be used in any method, but OPTIONS is the
         most suitable as it simultaneously determines all methods that
         are implemented.  When sending a request, the requester
         declares all its capabilities by including all supported
         feature tags.  This results in the receiver learning the
         requester's feature support.  The receiver then includes its
         set of features in the response.

   Proxy-Supported:  This header is used in a similar fashion as the
         Supported header, but instead of giving the supported
         functionality of the client or server, it provides both the
         requester and the responder a view of the common functionality
         supported in general by all members of the proxy chain between
         the client and server; it does not depend on the resource.
         Proxies are required to add this header whenever the Supported
         header is present, but proxies may also add it independently of
         the requester.

   Require:  This header can be included in any request where the
         endpoint, i.e., the client or server, is required to understand
         the feature to correctly perform the request.  This can, for
         example, be a SETUP request, where the server is required to
         understand a certain parameter to be able to set up the media
         delivery correctly.  Ignoring this parameter would not have the
         desired effect and is not acceptable.  Therefore, the endpoint
         receiving a request containing a Require MUST negatively
         acknowledge any feature that it does not understand and not
         perform the request.  The response in cases where features are
         not supported is 551 (Option Not Supported).  Also, the
         features that are not supported are given in the Unsupported
         header in the response.

   Proxy-Require:  This header has the same purpose and behavior as
         Require except that it only applies to proxies and not the
         endpoint.  Features that need to be supported by both proxies
         and endpoints need to be included in both the Require and
         Proxy-Require header.

   Unsupported:  This header is used in a 551 (Option Not Supported)
         error response, to indicate which features were not supported.
         Such a response is only the result of the usage of the Require
         or Proxy-Require headers where one or more features were not
         supported.  This information allows the requester to make the
         best of situations as it knows which features are not
         supported.

11.1.  Feature Tag: play.basic

   An implementation supporting all normative parts of this
   specification for the setup and control of playback of media uses the
   feature tag "play.basic" to indicate this support.  The appendices
   (starting with letters) are not part of the functionality included in
   the feature tag unless the appendix is explicitly specified in a main
   section as being a required appendix.

      Note: This feature tag does not mandate any media delivery
      protocol, such as RTP.

      In RTSP 1.0, there was a minimal implementation section.  However,
      that was not consistent with the rest of the specification.  So,
      rather than making an attempt to explicitly enumerate the features
      for play.basic, this specification has to be taken as a whole and
      the necessary features normatively defined as being required are
      included.

12.  Pipelining Support

   Pipelining is a general method to improve performance of request/
   response protocols by allowing the requesting agent to have more than
   one request outstanding and to send them over the same persistent
   connection.  For RTSP, where the relative order of requests will
   matter, it is important to maintain the order of the requests.
   Because of this, the responding agent MUST process the incoming
   requests in their sending order.  The sending order can be determined
   by the CSeq header and its sequence number.  For TCP, the delivery
   order will be the same, between two agents, as the sending order.
   The processing of the request MUST also have been finished before
   processing the next request from the same agent.  The responses MUST
   be sent in the order the requests were processed.

   RTSP 2.0 has extended support for pipelining beyond the capabilities
   in RTSP 1.0.  As a major improvement, all requests involved in
   setting up and initiating media delivery can now be pipelined,
   indicated by the Pipelined-Request header (see Section 18.33).  This
   header allows a client to request that two or more requests be
   processed in the same RTSP session context that the first request

   creates.  In other words, a client can request that two or more media
   streams be set up and then played without needing to wait for a
   single response.  This speeds up the initial start-up time for an
   RTSP session by at least one RTT.

   If a pipelined request builds on the successful completion of one or
   more prior requests, the requester must verify that all requests were
   executed as expected.  A common example will be two SETUP requests
   and a PLAY request.  In case one of the SETUP requests fails
   unexpectedly, the PLAY request can still be successfully executed.
   However, the resulting presentation will not be as expected by the
   requesting client, as only a single media instead of two will be
   played.  In this case, the client can send a PAUSE request, correct
   the failing SETUP request, and then request it be played.

13.  Method Definitions

   The method indicates what is to be performed on the resource
   identified by the Request-URI.  The method name is case sensitive.
   New methods may be defined in the future.  Method names MUST NOT
   start with a $ character (decimal 36) and MUST be a token as defined
   by the ABNF [RFC5234] in Section 20.  The methods are summarized in
   Table 7.

    +---------------+-----------+--------+-------------+-------------+
    | method        | direction | object | Server req. | Client req. |
    +---------------+-----------+--------+-------------+-------------+
    | DESCRIBE      | C -> S    | P,S    | recommended | recommended |
    |               |           |        |             |             |
    | GET_PARAMETER | C -> S    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    |               | S -> C    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    | OPTIONS       | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    |               | S -> C    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    | PAUSE         | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    | PLAY          | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    | PLAY_NOTIFY   | S -> C    | P,S    | required    | required    |
    |               |           |        |             |             |
    | REDIRECT      | S -> C    | P,S    | optional    | required    |
    |               |           |        |             |             |
    | SETUP         | C -> S    | S      | required    | required    |
    |               |           |        |             |             |
    | SET_PARAMETER | C -> S    | P,S    | required    | optional    |
    |               |           |        |             |             |
    |               | S -> C    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    | TEARDOWN      | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    |               | S -> C    | P      | required    | required    |
    +---------------+-----------+--------+-------------+-------------+

                     Table 7: Overview of RTSP Methods

      Note on Table 7: This table covers RTSP methods, their direction,
      and on what objects (P: presentation, S: stream) they operate.
      Further, it indicates whether a server or a client implementation
      is required (mandatory), recommended, or optional.

      Further note on Table 7: the GET_PARAMETER is optional.  For
      example, a fully functional server can be built to deliver media
      without any parameters.  However, SET_PARAMETER is required, i.e.,
      mandatory to implement for the server; this is due to its usage
      for keep-alive.  PAUSE is required because it is the only way of
      leaving the Play state without terminating the whole session.

   If an RTSP agent does not support a particular method, it MUST return
   a 501 (Not Implemented) response code and the requesting RTSP agent,
   in turn, SHOULD NOT try this method again for the given agent/
   resource combination.  An RTSP proxy whose main function is to log or
   audit and not modify transport or media handling in any way MAY
   forward RTSP messages with unknown methods.  Note that the proxy
   still needs to perform the minimal required processing, like adding
   the Via header.

13.1.  OPTIONS

   The semantics of the RTSP OPTIONS method is similar to that of the
   HTTP OPTIONS method described in Section 4.3.7 of [RFC7231].
   However, in RTSP, OPTIONS is bidirectional in that a client can send
   the request to a server and vice versa.  A client MUST implement the
   capability to send an OPTIONS request and a server or a proxy MUST
   implement the capability to respond to an OPTIONS request.  In
   addition to this "MUST-implement" functionality, clients, servers and
   proxies MAY provide support both for sending OPTIONS requests and for
   generating responses to the requests.

   An OPTIONS request may be issued at any time.  Such a request does
   not modify the session state.  However, it may prolong the session
   lifespan (see below).  The URI in an OPTIONS request determines the
   scope of the request and the corresponding response.  If the Request-
   URI refers to a specific media resource on a given host, the scope is
   limited to the set of methods supported for that media resource by
   the indicated RTSP agent.  A Request-URI with only the host address
   limits the scope to the specified RTSP agent's general capabilities
   without regard to any specific media.  If the Request-URI is an
   asterisk ("*"), the scope is limited to the general capabilities of
   the next hop (i.e., the RTSP agent in direct communication with the
   request sender).

   Regardless of the scope of the request, the Public header MUST always
   be included in the OPTIONS response, listing the methods that are
   supported by the responding RTSP agent.  In addition, if the scope of
   the request is limited to a media resource, the Allow header MUST be
   included in the response to enumerate the set of methods that are
   allowed for that resource unless the set of methods completely
   matches the set in the Public header.  If the given resource is not
   available, the RTSP agent SHOULD return an appropriate response code,
   such as 3rr or 4xx.  The Supported header MAY be included in the
   request to query the set of features that are supported by the
   responding RTSP agent.

   The OPTIONS method can be used to keep an RTSP session alive.
   However, this is not the preferred way of session keep-alive
   signaling; see Section 18.49.  An OPTIONS request intended for
   keeping alive an RTSP session MUST include the Session header with
   the associated session identifier.  Such a request SHOULD also use
   the media or the aggregated control URI as the Request-URI.

   Example:

     C->S:  OPTIONS rtsp://server.example.com RTSP/2.0
            CSeq: 1
            User-Agent: PhonyClient/1.2
            Proxy-Require: gzipped-messages
            Supported: play.basic

     S->C:  RTSP/2.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
            Supported: play.basic, setup.rtp.rtcp.mux, play.scale
            Server: PhonyServer/1.1


   Note that the "gzipped-messages" feature tag in the Proxy-Require is
   a fictitious feature.

13.2.  DESCRIBE

   The DESCRIBE method is used to retrieve the description of a
   presentation or media object from a server.  The Request-URI of the
   DESCRIBE request identifies the media resource of interest.  The
   client MAY include the Accept header in the request to list the
   description formats that it understands.  The server MUST respond
   with a description of the requested resource and return the
   description in the message body of the response, if the DESCRIBE
   method request can be successfully fulfilled.  The DESCRIBE reply-
   response pair constitutes the media initialization phase of RTSP.

   The DESCRIBE response SHOULD contain all media initialization
   information for the resource(s) that it describes.  Servers SHOULD
   NOT use the DESCRIBE response as a means of media indirection by
   having the description point at another server; instead, using the
   3rr responses is RECOMMENDED.

      By forcing a DESCRIBE response to contain all media initialization
      information for the set of streams that it describes, and
      discouraging the use of DESCRIBE for media indirection, any
      looping problems can be avoided that might have resulted from
      other approaches.

   Example:

     C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
           CSeq: 312
           User-Agent: PhonyClient/1.2
           Accept: application/sdp, application/example

     S->C: RTSP/2.0 200 OK
           CSeq: 312
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer/1.1
           Content-Base: rtsp://server.example.com/fizzle/foo/
           Content-Type: application/sdp
           Content-Length: 358

           v=0
           o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.example.com/lectures/sdp.ps
           e=seminar@example.com (Seminar Management)
           c=IN IP4 0.0.0.0
           a=control:*
           t=2873397496 2873404696
           m=audio 3456 RTP/AVP 0
           a=control:audio
           m=video 2232 RTP/AVP 31
           a=control:video

   Media initialization is a requirement for any RTSP-based system, but
   the RTSP specification does not dictate that this is required to be
   done via the DESCRIBE method.  There are three ways that an RTSP
   client may receive initialization information:

   o  via an RTSP DESCRIBE request

   o  via some other protocol (HTTP, email attachment, etc.)

   o  via some form of user interface

   If a client obtains a valid description from an alternate source, the
   client MAY use this description for initialization purposes without
   issuing a DESCRIBE request for the same media.  The client should use
   any MTag to either validate the presentation description or make the
   session establishment conditional on being valid.

   It is RECOMMENDED that minimal servers support the DESCRIBE method,
   and highly recommended that minimal clients support the ability to
   act as "helper applications" that accept a media initialization file
   from a user interface, or other means that are appropriate to the
   operating environment of the clients.

13.3.  SETUP

   The description below uses the following states in a protocol state
   machine that is related to a specific session when that session has
   been created.  The state transitions are driven by protocol
   interactions.  For additional information about the state machine,
   see Appendix B.

   Init: Initial state.  No session exists.

   Ready:  Session is ready to start playing.

   Play: Session is playing, i.e., sending media-stream data in the
         direction S->C.

   The SETUP request for a URI specifies the transport mechanism to be
   used for the streamed media.  The SETUP method may be used in two
   different cases, namely, creating an RTSP session and changing the
   transport parameters of media streams that are already set up.  SETUP
   can be used in all three states, Init, Ready, and Play, to change the
   transport parameters.  Additionally, Init and Ready can also be used
   for the creation of the RTSP session.  The usage of the SETUP method
   in the Play state to add a media resource to the session is
   unspecified.

   The Transport header, see Section 18.54, specifies the media-
   transport parameters acceptable to the client for data transmission;
   the response will contain the transport parameters selected by the
   server.  This allows the client to enumerate, in descending order of
   preference, the transport mechanisms and parameters acceptable to it,
   so the server can select the most appropriate.  It is expected that
   the session description format used will enable the client to select
   a limited number of possible configurations that are offered as
   choices to the server.  All transport-related parameters SHALL be
   included in the Transport header; the use of other headers for this
   purpose is NOT RECOMMENDED due to middleboxes, such as firewalls or
   NATs.

   For the benefit of any intervening firewalls, a client MUST indicate
   the known transport parameters, even if it has no influence over
   these parameters, for example, where the server advertises a fixed-
   multicast address as destination.

      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 client MUST include the Accept-Ranges header in the request,
   indicating all supported unit formats in the Range header.  This
   allows the server to know which formats it may use in future session-
   related responses, such as a PLAY response without any range in the
   request.  If the client does not support a time format necessary for
   the presentation, the server MUST respond using 456 (Header Field Not
   Valid for Resource) and include the Accept-Ranges header with the
   range unit formats supported for the resource.

   In a SETUP response, the server MUST include the Accept-Ranges header
   (see Section 18.5) to indicate which time formats are acceptable to
   use for this media resource.

   The SETUP 200 OK response MUST include the Media-Properties header
   (see Section 18.29).  The combination of the parameters of the Media-
   Properties header indicates the nature of the content present in the
   session (see also Section 4.7).  For example, a live stream with time
   shifting is indicated by

   o  Random access set to Random-Access,

   o  Content Modifications set to Time-Progressing, and

   o  Retention set to Time-Duration (with specific recording window
      time value).

   The SETUP 200 OK response MUST include the Media-Range header (see
   Section 18.30) if the media is Time-Progressing.

   A basic example for SETUP:

     C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 302
           Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
                      RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: npt, clock
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 302
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer/1.1
           Session: QKyjN8nt2WqbWw4tIYof52;timeout=60
           Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
                      "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
                      "198.51.100.241:6257"; ssrc=2A3F93ED
           Accept-Ranges: npt
           Media-Properties: Random-Access=3.2, Time-Progressing,
                             Time-Duration=3600.0
           Media-Range: npt=0-2893.23

   In the above example, the client wants to create an RTSP session
   containing the media resource "rtsp://example.com/foo/bar/baz.rm".
   The transport parameters acceptable to the client are either RTP/AVP/
   UDP (UDP per default) to be received on client port 4588 and 4589 at
   the address the RTSP setup connection comes from or RTP/AVP
   interleaved on the RTSP control channel.  The server selects the
   RTP/AVP/UDP transport and adds the address and ports it will send and
   receive RTP and RTCP from, and the RTP SSRC that will be used by the
   server.

   The server MUST generate a session identifier in response to a
   successful SETUP request unless a SETUP request to a server includes
   a session identifier or a Pipelined-Requests header referencing an
   existing session context.  In that latter case, the server MUST
   bundle this SETUP request into the existing session (aggregated
   session) or return a 459 (Aggregate Operation Not Allowed) error code
   (see Section 17.4.23).  An aggregate control URI MUST be used to
   control an aggregated session.  This URI MUST be different from the
   stream control URIs of the individual media streams included in the
   aggregate (see Section 13.4.2 for aggregated sessions and for the
   particular URIs see Appendix D.1.1).  The aggregate control URI is to
   be specified by the session description if the server supports
   aggregated control and aggregated control is desired for the session.

   However, even if aggregated control is offered, the client MAY choose
   not to set up the session in aggregated control.  If an aggregate
   control URI is not specified in the session description, it is
   normally an indication that non-aggregated control should be used.

   The SETUP of media streams in an aggregate that has not been given an
   aggregated control URI is unspecified.

      While the session ID sometimes carries enough information for
      aggregate control of a session, the aggregate control URI is still
      important for some methods such as SET_PARAMETER where the control
      URI enables the resource in question to be easily identified.  The
      aggregate control URI is also useful for proxies, enabling them to
      route the request to the appropriate server, and for logging,
      where it is useful to note the actual resource on which a request
      was operating.

   A session will exist until it is either removed by a TEARDOWN request
   or is timed out by the server.  The server MAY remove a session that
   has not demonstrated liveness signs from the client(s) within a
   certain timeout period.  The default timeout value is 60 seconds; the
   server MAY set this to a different value and indicate so in the
   timeout field of the Session header in the SETUP response.  For
   further discussion, see Section 18.49.  Signs of liveness for an RTSP
   session include any RTSP requests from a client that contain a
   Session header with the ID for that session, as well as RTCP sender
   or receiver reports if RTP is used to transport the underlying media
   stream.  RTCP sender reports may, for example, be received in session
   where the server is invited into a conference session and are thus
   valid as a liveness indicator.

   If a SETUP request on a session fails for any reason, the session
   state, as well as transport and other parameters for associated
   streams, MUST remain unchanged from their values as if the SETUP
   request had never been received by the server.

13.3.1.  Changing Transport Parameters

   A client MAY issue a SETUP request for a stream that is already set
   up or playing in the session to change transport parameters, which a
   server MAY allow.  If it does not allow the changing of parameters,
   it MUST respond with error 455 (Method Not Valid in This State).  The
   reasons to support changing transport parameters include allowing
   application-layer mobility and flexibility to utilize the best
   available transport as it becomes available.  If a client receives a
   455 error when trying to change transport parameters while the server
   is in Play state, it MAY try to put the server in Ready state using
   PAUSE before issuing the SETUP request again.  If that also fails,

   the changing of transport parameters will require that the client
   perform a TEARDOWN of the affected media and then set it up again.
   For an aggregated session, not tearing down all the media at the same
   time will avoid the creation of a new session.

   All transport parameters MAY be changed.  However, the primary usage
   expected is to either change the transport protocol completely, like
   switching from Interleaved TCP mode to UDP or vice versa, or to
   change the delivery address.

   In a SETUP response for a request to change the transport parameters
   while in Play state, the server MUST include the Range header to
   indicate at what point the new transport parameters will be used.
   Further, if RTP is used for delivery, the server MUST also include
   the RTP-Info header to indicate at what timestamp and RTP sequence
   number the change will take place.  If both RTP-Info and Range are
   included in the response, the "rtp_time" parameter and start point in
   the Range header MUST be for the corresponding time, i.e., be used in
   the same way as for PLAY to ensure the correct synchronization
   information is available.

   If the transport-parameters change that happened while in Play state
   results in a change of synchronization-related information, for
   example, changing RTP SSRC, the server MUST include the necessary
   synchronization information in the SETUP response.  However, the
   server SHOULD avoid changing the synchronization information if
   possible.

13.4.  PLAY

   This section describes the usage of the PLAY method in general, for
   aggregated sessions, and in different usage scenarios.

13.4.1.  General Usage

   The PLAY method tells the server to start sending data via the
   mechanism specified in SETUP and which part of the media should be
   played out.  PLAY requests are valid when the session is in Ready or
   Play state.  A PLAY request MUST include a Session header to indicate
   to which session the request applies.

   Upon receipt of the PLAY request, the server MUST position the normal
   play time to the beginning of the range specified in the received
   Range header, within the limits of the media resource and in
   accordance with the Seek-Style header (Section 18.47).  It MUST
   deliver stream data until the end of the range if given, until a new
   PLAY request is received, until a PAUSE request (Section 13.5) is
   received, or until the end of the media is reached.  If no Range

   header is present in the PLAY request, the server SHALL play from
   current pause point until the end of media.  The pause point defaults
   at session start to the beginning of the media.  For media that is
   time-progressing and has no retention, the pause point will always be
   set equal to NPT "now", i.e., the current delivery point.  The pause
   point may also be set to a particular point in the media by the PAUSE
   method; see Section 13.6.  The pause point for media that is
   currently playing is equal to the current media position.  For time-
   progressing media with time-limited retention, if the pause point
   represents a position that is older than what is retained by the
   server, the pause point will be moved to the oldest retained
   position.

   What range values are valid depends on the type of content.  For
   content that isn't time-progressing, the range value is valid if the
   given range is part of any media within the aggregate.  In other
   words, the valid media range for the aggregate is the union of all of
   the media components in the aggregate.  If a given range value points
   outside of the media, the response MUST be the 457 (Invalid Range)
   error code and include the Media-Range header (Section 18.30) with
   the valid range for the media.  Except for time-progressing content
   where the client requests a start point prior to what is retained,
   the start point is adjusted to the oldest retained content.  For a
   start point that is beyond the media front edge, i.e., beyond the
   current value for "now", the server SHALL adjust the start value to
   the current front edge.  The Range header's stop point value may
   point beyond the current media edge.  In that case, the server SHALL
   deliver media from the requested (and possibly adjusted) start point
   until the first of either the provided stop point or the end of the
   media.  Please note that if one simply wants to play from a
   particular start point until the end of media, using a Range header
   with an implicit stop point is RECOMMENDED.

   If a client requests to start playing at the end of media, either
   explicitly with a Range header or implicitly with a pause point that
   is at the end of media, a 457 (Invalid Range) error MUST be sent and
   include the Media-Range header (Section 18.30).  It is specified
   below that the Range header also must be included in the response and
   that it will carry the pause point in the media, in the case of the
   session being in Ready State.  Note that this also applies if the
   pause point or requested start point is at the beginning of the media
   and a Scale header (Section 18.46) is included with a negative value
   (playing backwards).

   For media with random access properties, a client may indicate which
   policy for start point selection the server should use.  This is done
   by including the Seek-Style header (Section 18.47) in the PLAY

   request.  The Seek-Style applied will affect the content of the Range
   header as it will be adjusted to indicate from what point the media
   actually is delivered.

   A client desiring to play the media from the beginning MUST send a
   PLAY request with a Range header pointing at the beginning, e.g.,
   "npt=0-".  If a PLAY request is received without a Range header and
   media delivery has stopped at the end, the server SHOULD respond with
   a 457 (Invalid Range) error response.  In that response, the current
   pause point MUST be included in a Range header.

   All range specifiers in this specification allow for ranges with an
   implicit start point (e.g., "npt=-30").  When used in a PLAY request,
   the server treats this as a request to start or resume delivery from
   the current pause point, ending at the end time specified in the
   Range header.  If the pause point is located later than the given end
   value, a 457 (Invalid Range) response MUST be returned.

   The example below will play seconds 10 through 25.  It also requests
   that the server deliver media from the first random access point
   prior to the indicated start point.

     C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
           CSeq: 835
           Session: ULExwZCXh2pd0xuFgkgZJW
           Range: npt=10-25
           Seek-Style: RAP
           User-Agent: PhonyClient/1.2

   Servers MUST include a Range header in any PLAY response, even if no
   Range header was present in the request.  The response MUST use the
   same format as the request's Range header contained.  If no Range
   header was in the request, the format used in any previous PLAY
   request within the session SHOULD be used.  If no format has been
   indicated in a previous request, the server MAY use any time format
   supported by the media and indicated in the Accept-Ranges header in
   the SETUP request.  It is RECOMMENDED that NPT is used if supported
   by the media.

   For any error response to a PLAY request, the server's response
   depends on the current session state.  If the session is in Ready
   state, the current pause point is returned using a Range header with
   the pause point as the explicit start point and an implicit stop
   point.  For time-progressing content, where the pause-point moves
   with real-time due to limited retention, the current pause point is
   returned.  For sessions in Play state, the current playout point and

   the remaining parts of the range request are returned.  For any media
   with retention longer than 0 seconds, the currently valid Media-Range
   header SHALL also be included in the response.

   A PLAY response MAY include a header carrying synchronization
   information.  As the information necessary is dependent on the media-
   transport format, further rules specifying the header and its usage
   are needed.  For RTP the RTP-Info header is specified, see
   Section 18.45, and used in the following example.

   Here is a simple example for a single audio stream where the client
   requests the media starting from 3.52 seconds and to the end.  The
   server sends a 200 OK response with the actual play time, which is 10
   ms prior (3.51), and the RTP-Info header that contains the necessary
   parameters for the RTP stack.

   C->S: PLAY rtsp://example.com/audio RTSP/2.0
         CSeq: 836
         Session: ULExwZCXh2pd0xuFgkgZJW
         Range: npt=3.52-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 836
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer/1.0
         Range: npt=3.51-324.39
         Seek-Style: First-Prior
             Session: ULExwZCXh2pd0xuFgkgZJW
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.51
         Media duration=0.16 seconds

   The server replies with the actual start point that will be
   delivered.  This may differ from the requested range if alignment of
   the requested range to valid frame boundaries is required for the
   media source.  Note that some media streams in an aggregate may need
   to be delivered from even earlier points.  Also, some media formats
   have a very long duration per individual data unit; therefore, it
   might be necessary for the client to parse the data unit, and select
   where to start.  The server SHALL also indicate which policy it uses
   for selecting the actual start point by including a Seek-Style
   header.

   In the following example, the client receives the first media packet
   that stretches all the way up and past the requested playtime.  Thus,
   it is the client's decision whether to render to the user the time
   between 3.52 and 7.05 or to skip it.  In most cases, it is probably
   most suitable not to render that time period.

   C->S: PLAY rtsp://example.com/audio RTSP/2.0
         CSeq: 836
         Session: ZGGyCJOs8xaLkdNK2dmxQO
         Range: npt=7.05-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 836
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer/1.0
             Session: ZGGyCJOs8xaLkdNK2dmxQO
         Range: npt=3.52-
         Seek-Style: First-Prior
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.52
         Duration=4.15 seconds

   After playing the desired range, the presentation does NOT change to
   the Ready state, media delivery simply stops.  If it is necessary to
   put the stream into the Ready state, a PAUSE request MUST be issued.
   A PLAY request while the stream is still in the Play state is legal
   and can be issued without an intervening PAUSE request.  Such a
   request MUST replace the current PLAY action with the new one
   requested, i.e., being handled in the same way as if as the request
   was received in Ready state.  In the case that the range in the Range
   header has an implicit start time ("-endtime"), the server MUST
   continue to play from where it currently was until the specified
   endpoint.  This is useful to change the end to at another point than
   in the previous request.

   The following example plays the whole presentation starting at SMPTE
   time code 0:10:20 until the end of the clip.  Note: the RTP-Info
   headers have been broken into several lines, where subsequent lines
   start with whitespace as allowed by the syntax.

   C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
         CSeq: 833
         Session: N465Wvsv0cjUy6tLqINkcf
         Range: smpte=0:10:20-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 833
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Session: N465Wvsv0cjUy6tLqINkcf
         Server: PhonyServer/1.0
         Range: smpte=0:10:22-0:15:45
         Seek-Style: Next
         RTP-Info:url="rtsp://example.com/twister.en"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   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/2.0
         CSeq: 835
         Session: N465Wvsv0cjUy6tLqINkcf
         Range: clock=19961108T142300Z-19961108T143520Z
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 835
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Session: N465Wvsv0cjUy6tLqINkcf
         Server: PhonyServer/1.0
         Range: clock=19961108T142300Z-19961108T143520Z
         Seek-Style: Next
         RTP-Info:url="rtsp://example.com/meeting.en"
            ssrc=0D12F123:seq=53745;rtptime=484589019

13.4.2.  Aggregated Sessions

   PLAY requests can operate on sessions controlling a single media
   stream and on aggregated sessions controlling multiple media streams.

   In an aggregated session, the PLAY request MUST contain an aggregated
   control URI.  A server MUST respond with a 460 error (Only Aggregate
   Operation Allowed) if the client PLAY Request-URI is for a single
   media.  The media in an aggregate MUST be played in sync.  If a
   client wants individual control of the media, it needs to use
   separate RTSP sessions for each media.

   For aggregated sessions where the initial SETUP request (creating a
   session) is followed by one or more additional SETUP requests, a PLAY
   request MAY be pipelined (Section 12) after those additional SETUP
   requests without awaiting their responses.  This procedure can reduce
   the delay from the start of session establishment until media playout
   has started with one RTT.  However, a client needs to be aware that
   using this procedure will result in the playout of the server state
   established at the time of processing the PLAY, i.e., after the
   processing of all the requests prior to the PLAY request in the
   pipeline.  This state may not be the intended one due to failure of
   any of the prior requests.  A client can easily determine this based
   on the responses from those requests.  In case of failure, the client
   can halt the media playout using PAUSE and try to establish the
   intended state again before issuing another PLAY request.

13.4.3.  Updating Current PLAY Requests

   Clients can issue PLAY requests while the stream is in Play state and
   thus updating their request.

   The important difference compared to a PLAY request in Ready state is
   the handling of the current play point and how the Range header in
   the request is constructed.  The session is actively playing media
   and the play point will be moving, making the exact time a request
   will take effect hard to predict.  Depending on how the PLAY header
   appears, two different cases exist: total replacement or
   continuation.  A total replacement is signaled by having the first
   range specification have an explicit start value, e.g., "npt=45-" or
   "npt=45-60", in which case the server stops playout at the current
   playout point and then starts delivering media according to the Range
   header.  This is equivalent to having the client first send a PAUSE
   and then a new PLAY request that isn't based on the pause point.  In
   the case of continuation, the first range specifier has an implicit
   start point and an explicit stop value (Z), e.g., "npt=-60", which
   indicate that it MUST convert the range specifier being played prior
   to this PLAY request (X to Y) into (X to Z) and continue as if this
   was the request originally played.  If the current delivery point is
   beyond the stop point, the server SHALL immediately pause delivery.
   As the request has been completed successfully, it shall be responded
   to with a 200 OK response.  A PLAY_NOTIFY with end-of-stream is also
   sent to indicate the actual stop point.  The pause point is set to
   the requested stop point.

   The following is an example of this behavior: The server has received
   requests to play ranges 10 to 15.  If the new PLAY request arrives at
   the server 4 seconds after the previous one, it will take effect

   while the server still plays the first range (10-15).  The server
   changes the current play to continue to 25 seconds, i.e., the
   equivalent single request would be PLAY with "range: npt=10-25".

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=10-15
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=10-15
           Seek-Style: Next
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792482193


     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=-25
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Date: Thu, 23 Jan 1997 15:35:09 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=14-25
           Seek-Style: Next
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934239921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792842193

   A common use of a PLAY request while in Play state is changing the
   scale of the media, i.e., entering or leaving fast forward or fast
   rewind.  The client can issue an updating PLAY request that is either
   a continuation or a complete replacement, as discussed above this
   section.  Below is an example of a client that is requesting a fast
   forward (scale = 2) without giving a stop point and then a change
   from fast forward to regular playout (scale = 1).  In the second PLAY

   request, the time is set explicitly to be wherever the server
   currently plays out (npt=now-) and the server responds with the
   actual playback point where the new scale actually takes effect
   (npt=02:17:27.144-).

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2034
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=now-
           Scale: 2.0
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 2034
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=02:17:21.394-
           Seek-Style: Next
           Scale: 2.0
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792482193


   [playing in fast forward and now returning to scale = 1]

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2035
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=now-
           Scale: 1.0
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 2035
           Date: Thu, 23 Jan 1997 15:35:09 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=02:17:27.144-
           Seek-Style: Next
           Scale: 1.0
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934239921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792842193

13.4.4.  Playing On-Demand Media

   On-demand media is indicated by the content of the Media-Properties
   header in the SETUP response when (see also Section 18.29):

   o  the Random Access property is set to Random-Access;

   o  the Content Modifications property is set to Immutable;

   o  the Retention property is set to Unlimited or Time-Limited.

   Playing on-demand media follows the general usage as described in
   Section 13.4.1.

13.4.5.  Playing Dynamic On-Demand Media

   Dynamic on-demand media is indicated by the content of the Media-
   Properties header in the SETUP response when (see also
   Section 18.29):

   o  the Random Access property is set to Random-Access;

   o  the Content Modifications property is set to Dynamic;

   o  the Retention property is set to Unlimited or Time-Limited.

   Playing on-demand media follows the general usage as described in
   Section 13.4.1 as long as the media has not been changed.

   There are two ways for the client to be informed about changes of
   media resources in Play state.  The first being that the client will
   receive a PLAY_NOTIFY request with the Notify-Reason header set to
   media-properties-update (see Section 13.5.2).  The client can use the
   value of the Media-Range header to decide further actions, if the
   Media-Range header is present in the PLAY_NOTIFY request.  The second
   way is that the client issues a GET_PARAMETER request without a body
   but including a Media-Range header.  The 200 OK response MUST include
   the current Media-Range header (see Section 18.30).

13.4.6.  Playing Live Media

   Live media is indicated by the content of the Media-Properties header
   in the SETUP response when (see also Section 18.29):

   o  the Random Access property is set to No-Seeking;

   o  the Content Modifications property is set to Time-Progressing;

   o  the Retention property's Time-Duration is set to 0.0.

   For live media, the SETUP 200 OK response MUST include the Media-
   Range header (see Section 18.30).

   A client MAY send PLAY requests without the Range header.  If the
   request includes the Range header, it MUST use a symbolic value
   representing "now".  For NPT, that range specification is "npt=now-".
   The server MUST include the Range header in the response, and it MUST
   indicate an explicit time value and not a symbolic value.  In other
   words, "npt=now-" cannot be used in the response.  Instead, the time
   since session start is recommended, expressed as an open interval,
   e.g., "npt=96.23-".  An absolute time value (clock) for the
   corresponding time MAY be given, i.e., "clock=20030213T143205Z-".
   The Absolute Time format can only be used if the client has shown
   support for it using the Accept-Ranges header.

13.4.7.  Playing Live with Recording

   Certain media servers may offer recording services of live sessions
   to their clients.  This recording would normally be from the
   beginning of the media session.  Clients can randomly access the
   media between now and the beginning of the media session.  This live
   media with recording is indicated by the content of the Media-
   Properties header in the SETUP response when (see also
   Section 18.29):

   o  the Random Access property is set to Random-Access;

   o  the Content Modifications property is set to Time-Progressing;

   o  the Retention property is set to Time-Limited or Unlimited

   The SETUP 200 OK response MUST include the Media-Range header (see
   Section 18.30) for this type of media.  For live media with
   recording, the Range header indicates the current delivery point in
   the media and the Media-Range header indicates the currently
   available media window around the current time.  This window can
   cover recorded content in the past (seen from current time in the
   media) or recorded content in the future (seen from current time in
   the media).  The server adjusts the delivery point to the requested
   border of the window.  If the client requests a delivery point that
   is located outside the recording window, e.g., if the requested point
   is too far in the past, the server selects the oldest point in the
   recording.  The considerations in Section 13.5.3 apply if a client
   requests delivery with scale (Section 18.46) values other than 1.0
   (normal playback rate) while delivering live media with recording.

13.4.8.  Playing Live with Time-Shift

   Certain media servers may offer time-shift services to their clients.
   This time shift records a fixed interval in the past, i.e., a sliding
   window recording mechanism, but not past this interval.  Clients can
   randomly access the media between now and the interval.  This live
   media with recording is indicated by the content of the Media-
   Properties header in the SETUP response when (see also
   Section 18.29):

   o  the Random Access property is set to Random-Access;

   o  the Content Modifications property is set to Time-Progressing;

   o  the Retention property is set to Time-Duration and a value
      indicating the recording interval (>0).

   The SETUP 200 OK response MUST include the Media-Range header (see
   Section 18.30) for this type of media.  For live media with
   recording, the Range header indicates the current time in the media
   and the Media-Range header indicates a window around the current
   time.  This window can cover recorded content in the past (seen from
   current time in the media) or recorded content in the future (seen
   from current time in the media).  The server adjusts the play point
   to the requested border of the window, if the client requests a play
   point that is located outside the recording windows, e.g., if
   requested too far in the past, the server selects the oldest range in
   the recording.  The considerations in Section 13.5.3 apply if a
   client requests delivery using a scale (Section 18.46) value other
   than 1.0 (normal playback rate) while delivering live media with
   time-shift.