Section 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.
13.5.  PLAY_NOTIFY
   The PLAY_NOTIFY method is issued by a server to inform a client about
   an asynchronous event for a session in Play state.  The Session
   header MUST be presented in a PLAY_NOTIFY request and indicates the
   scope of the request.  Sending of PLAY_NOTIFY requests requires a
   persistent connection between server and client; otherwise, there is
   no way for the server to send this request method to the client.
   PLAY_NOTIFY requests have an end-to-end (i.e., server-to-client)
   scope, as they carry the Session header, and apply only to the given
   session.  The client SHOULD immediately return a response to the
   server.
   PLAY_NOTIFY requests MAY use both an aggregate control URI and
   individual media resource URIs, depending on the scope of the
   notification.  This scope may have important distinctions for
   aggregated sessions, and each reason for a PLAY_NOTIFY request needs
   to specify the interpretation as well as if aggregated control URIs
   or individual URIs may be used in requests.
   PLAY_NOTIFY requests can be used with a message body, depending on
   the value of the Notify-Reason header.  It is described in the
   particular section for each Notify-Reason if a message body is used.
   However, currently there is no Notify-Reason that allows the use of a
   message body.  In this case, there is a need to obey some limitations
   when adding new Notify-Reasons that intend to use a message body: the
   server can send any type of message body, but it is not ensured that
   the client can understand the received message body.  This is related
   to DESCRIBE (see Section 13.2 ); but, in this particular case, the
   client can state its acceptable message bodies by using the Accept
   header.  In the case of PLAY_NOTIFY, the server does not know which
   message bodies are understood by the client.
   The Notify-Reason header (see Section 18.32) specifies the reason why
   the server sends the PLAY_NOTIFY request.  This is extensible and new
   reasons can be added in the future (see Section 22.8).  In case the
   client does not understand the reason for the notification, it MUST
   respond with a 465 (Notification Reason Unknown) (Section 17.4.29)
   error code.  This document defines how servers can send PLAY_NOTIFY
   with Notify-Reason values of these types:
   o  end-of-stream (see Section 13.5.1);
   o  media-properties-update (see Section 13.5.2);
   o  scale-change (see Section 13.5.3).
13.5.1.  End-of-Stream
   A PLAY_NOTIFY request with the Notify-Reason header set to end-of-
   stream indicates the completion or near completion of the PLAY
   request and the ending delivery of the media stream(s).  The request
   MUST NOT be issued unless the server is in the Play state.  The end
   of the media stream delivery notification may be used either to
   indicate a successful completion of the PLAY request currently being
   served or to indicate some error resulting in failure to complete the
   request.  The Request-Status header (Section 18.42) MUST be included
   to indicate which request the notification is for and its completion
   status.  The message response status codes (Section 8.1.1) are used
   to indicate how the PLAY request concluded.  The sender of a
   PLAY_NOTIFY MAY issue an updated PLAY_NOTIFY, in the case of a
   PLAY_NOTIFY sent with wrong information.  For instance, a PLAY_NOTIFY
   was issued before reaching the end-of-stream, but some error occurred
   resulting in that the previously sent PLAY_NOTIFY contained a wrong
   time when the stream will end.  In this case, a new PLAY_NOTIFY MUST
   be sent including the correct status for the completion and all
   additional information.
   PLAY_NOTIFY requests with the Notify-Reason header set to end-of-
   stream MUST include a Range header and the Scale header if the scale
   value is not 1.  The Range header indicates the point in the stream
   or streams where delivery is ending with the timescale that was used
   by the server in the PLAY response for the request being fulfilled.
   The server MUST NOT use the "now" constant in the Range header; it
   MUST use the actual numeric end position in the proper timescale.
   When end-of-stream notifications are issued prior to having sent the
   last media packets, this is made evident because the end time in the
   Range header is beyond the current time in the media being received
   by the client, e.g., "npt=-15", if npt is currently at 14.2 seconds.
   The Scale header is to be included so that it is evident if the media
   timescale is moving backwards or has a non-default pace.  The end-of-
   stream notification does not prevent the client from sending a new
   PLAY request.
   If RTP is used as media transport, an RTP-Info header MUST be
   included, and the RTP-Info header MUST indicate the last sequence
   number in the sequence parameter.
   For an RTSP Session where media resources are under aggregated
   control, the media resources will normally end at approximately the
   same time, although some small differences may exist, on the scale of
   a few hundred milliseconds.  In those cases, an RTSP session under
   aggregated control SHOULD send only a single PLAY_NOTIFY request.  By
   using the aggregate control URI in the PLAY_NOTIFY request, the RTSP
   server indicates that this applies to all media resources within the
   session.  In cases in which RTP is used for media delivery,
   corresponding RTP-Info needs to be included for all media resources.
   In cases where one or more media resources have a significantly
   shorter duration than some other resources in the aggregated session,
   the server MAY send end-of-stream notifications using individual
   media resource URIs to indicate to agents that there will be no more
   media for this particular media resource related to the current
   active PLAY request.  In such cases, when the remaining media
   resources come to the end of the stream, they MUST send a PLAY_NOTIFY
   request using the aggregate control URI to indicate that no more
   resources remain.
   A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
   MUST NOT carry a message body.
   This example request notifies the client about a future end-of-stream
   event:
     S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 854
           Notify-Reason: end-of-stream
           Request-Status: cseq=853 status=200 reason="OK"
           Range: npt=-145
           RTP-Info:url="rtsp://example.com/fizzle/foo/audio"
              ssrc=0D12F123:seq=14783;rtptime=2345962545,
              url="rtsp://example.com/fizzle/video"
              ssrc=789DAF12:seq=57654;rtptime=2792482193
           Session: CDtUJfDQXJWtJ7Iqua2xOi
           Date: Mon, 08 Mar 2010 13:37:16 GMT
     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2
           Session: CDtUJfDQXJWtJ7Iqua2xOi
13.5.2.  Media-Properties-Update
   A PLAY_NOTIFY request with a Notify-Reason header set to media-
   properties-update indicates an update of the media properties for the
   given session (see Section 18.29) or the available media range that
   can be played as indicated by the Media-Range header (Section 18.30).
   PLAY_NOTIFY requests with Notify-Reason header set to media-
   properties-update MUST include a Media-Properties and Date header and
   SHOULD include a Media-Range header.  The Media-Properties header has
   session scope; thus, for aggregated sessions, the PLAY_NOTIFY request
   MUST use the aggregated control URI.
   This notification MUST be sent for media that are time-progressing
   every time an event happens that changes the basis for making
   estimates on how the available for play-back media range will
   progress with wall clock time.  In addition, it is RECOMMENDED that
   the server send these notifications approximately every 5 minutes for
   time-progressing content to ensure the long-term stability of the
   client estimation and allow for clock skew detection by the client.
   The time between notifications should be greater than 1 minute and
   less than 2 hours.  For the reasons just explained, requests MUST
   include a Media-Range header to provide current Media duration and a
   Range header to indicate the current playing point and any remaining
   parts of the requested range.
      The recommendation for sending updates every 5 minutes is due to
      any clock skew issues.  In 5 minutes, the clock skew should not
      become too significant as this is not used for media playback and
      synchronization, it is only for determining which content is
      available to the user.
   A PLAY_NOTIFY request with Notify-Reason header set to media-
   properties-update MUST NOT carry a message body.
    S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           Date: Tue, 14 Apr 2008 15:48:06 GMT
           CSeq: 854
           Notify-Reason: media-properties-update
           Session: CDtUJfDQXJWtJ7Iqua2xOi
           Media-Properties: Time-Progressing,
                 Time-Limited=20080415T153919.36Z, Random-Access=5.0
           Media-Range: npt=00:00:00-01:37:21.394
           Range: npt=01:15:49.873-
     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2
           Session: CDtUJfDQXJWtJ7Iqua2xOi
13.5.3.  Scale-Change
   The server may be forced to change the rate of media time per
   playback time when a client requests delivery using a scale
   (Section 18.46) value other than 1.0 (normal playback rate).  For
   time-progressing media with some retention, i.e., the server stores
   already-sent content, a client requesting to play with scale values
   larger than 1 may catch up with the front end of the media.  The
   server will then be unable to continue to provide content at scale
   larger than 1 as content is only made available by the server at
   scale = 1.  Another case is when scale < 1 and the media retention is
   Time-Duration limited.  In this case, the delivery point can reach
   the oldest media unit available, and further playback at this scale
   becomes impossible as there will be no media available.  To avoid
   having the client lose any media, the scale will need to be adjusted
   to the same rate at which the media is removed from the storage
   buffer, commonly scale = 1.0.
   Another case is when the content itself consists of spliced pieces or
   is dynamically updated.  In these cases, the server may be required
   to change from one supported scale value (different than scale = 1.0)
   to another.  In this case, the server will pick the closest value and
   inform the client of what it has picked.  In these cases, the media
   properties will also be sent, updating the supported scale values.
   This enables a client to adjust the scale value used.
   To minimize impact on playback in any of the above cases, the server
   MUST modify the playback properties, set scale to a supportable
   value, and continue delivery of the media.  When doing this
   modification, it MUST send a PLAY_NOTIFY message with the Notify-
   Reason header set to "scale-change".  The request MUST contain a
   Range header with the media time when the change took effect, a Scale
   header with the new value in use, a Session header with the
   identifier for the session to which it applies, and a Date header
   with the server wallclock time of the change.  For time-progressing
   content, the Media-Range and the Media-Properties headers at this
   point in time also MUST be included.  The Media-Properties header
   MUST be included if the scale change was due to the content changing
   what scale values ("Scales") are supported.
   For media streams delivered using RTP, an RTP-Info header MUST also
   be included.  It MUST contain the rtptime parameter with a value
   corresponding to the point of change in that media and optionally the
   sequence number.
   PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated
   control URI in the request.  The scale change for any aggregated
   session applies to all media streams that are part of the aggregate.
   A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
   MUST NOT carry a message body.
     S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           Date: Tue, 14 Apr 2008 15:48:06 GMT
           CSeq: 854
           Notify-Reason: scale-change
           Session: CDtUJfDQXJWtJ7Iqua2xOi
           Media-Properties: Time-Progressing,
                 Time-Limited=20080415T153919.36Z, Random-Access=5.0
           Media-Range: npt=00:00:00-01:37:21.394
           Range: npt=01:37:21.394-
           Scale: 1
           RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
               ssrc=0D12F123:rtptime=2345962545,
               url="rtsp://example.com/fizzle/foo/videotrack"
               ssrc=789DAF12:seq=57654;rtptime=2792482193
     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2
           Session: CDtUJfDQXJWtJ7Iqua2xOi
13.6.  PAUSE
   The PAUSE request causes the stream delivery to immediately be
   interrupted (halted).  A PAUSE request MUST be made either with the
   aggregated control URI for aggregated sessions, resulting in all
   media being halted, or with the media URI for non-aggregated
   sessions.  Any attempt to mute a single media with a PAUSE request in
   an aggregated session MUST be responded to with a 460 (Only Aggregate
   Operation Allowed) error.  After resuming playback, 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/2.0
           CSeq: 834
           Session: OoOUPyUwt0VeY9fFRHuZ6L
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
                   Session: OoOUPyUwt0VeY9fFRHuZ6L
           Range: npt=45.76-75.00
   The PAUSE request causes stream delivery to be interrupted
   immediately on receipt of the message, and the pause point is set to
   the current point in the presentation.  That pause point in the media
   stream needs to be maintained.  A subsequent PLAY request without a
   Range header resumes from the pause point and plays until media end.
   The pause point after any PAUSE request MUST be returned to the
   client by adding a Range header with what remains unplayed of the
   PLAY request's range.  For media with random access properties, if
   one desires to resume playing a ranged request, one simply includes
   the Range header from the PAUSE response and includes the Seek-Style
   header with the Next policy in the PLAY request.  For media that is
   time-progressing and has retention duration=0, the follow-up PLAY
   request to start media delivery again MUST use "npt=now-" and not the
   answer given in the response to PAUSE.
     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: OccldOFFq23KwjYpAnBbUr
           Range: npt=10-30
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer/1.0
           Range: npt=10-30
           Seek-Style: First-Prior
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=4FAD8726:seq=57654;rtptime=2792482193
           Session: OccldOFFq23KwjYpAnBbUr
   After 11 seconds, i.e., at 21 seconds into the presentation:
     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: OccldOFFq23KwjYpAnBbUr
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:17 GMT
           Server: PhonyServer/1.0
           Range: npt=21-30
           Session: OccldOFFq23KwjYpAnBbUr
   If a client issues a PAUSE request and the server acknowledges and
   enters the Ready state, the proper server response, if the player
   issues another PAUSE, is still 200 OK.  The 200 OK response MUST
   include the Range header with the current pause point.  See examples
   below:
     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: OccldOFFq23KwjYpAnBbUr
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Session: OccldOFFq23KwjYpAnBbUr
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Range: npt=45.76-98.36
     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: OccldOFFq23KwjYpAnBbUr
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Session: OccldOFFq23KwjYpAnBbUr
           Date: 23 Jan 1997 15:35:07 GMT
           Range: npt=45.76-98.36
13.7.  TEARDOWN
13.7.1.  Client to Server
   The TEARDOWN client-to-server request stops the stream delivery for
   the given URI, freeing the resources associated with it.  A TEARDOWN
   request can be performed on either an aggregated or a media control
   URI.  However, some restrictions apply depending on the current
   state.  The TEARDOWN request MUST contain a Session header indicating
   to what session the request applies.  The TEARDOWN request MUST NOT
   include a Terminate-Reason header.
   A TEARDOWN using the aggregated control URI or the media URI in a
   session under non-aggregated control (single media session) MAY be
   done in any state (Ready and Play).  A successful request MUST result
   in that media delivery being immediately halted and the session state
   being destroyed.  This MUST be indicated through the lack of a
   Session header in the response.
   A TEARDOWN using a media URI in an aggregated session can only be
   done in Ready state.  Such a request only removes the indicated media
   stream and associated resources from the session.  This may result in
   a session returning to non-aggregated control, because it only
   contains a single media after the request's completion.  A session
   that will exist after the processing of the TEARDOWN request MUST, in
   the response to that TEARDOWN request, contain a Session header.
   Thus, the presence of the Session header indicates to the receiver of
   the response if the session is still extant or has been removed.
   Example:
     C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 892
           Session: OccldOFFq23KwjYpAnBbUr
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 892
           Server: PhonyServer/1.0
13.7.2.  Server to Client
   The server can send TEARDOWN requests in the server-to-client
   direction to indicate that the server has been forced to terminate
   the ongoing session.  This may happen for several reasons, such as
   server maintenance without available backup, or that the session has
   been inactive for extended periods of time.  The reason is provided
   in the Terminate-Reason header (Section 18.52).
   When an RTSP client has maintained an RTSP session that otherwise is
   inactive for an extended period of time, the server may reclaim the
   resources.  That is done by issuing a TEARDOWN request with the
   Terminate-Reason set to "Session-Timeout".  This MAY be done when the
   client has been inactive in the RTSP session for more than one
   Session Timeout period (Section 18.49).  However, the server is NOT
   RECOMMENDED to perform this operation until an extended period of
   inactivity of 10 times the Session-Timeout period has passed.  It is
   up to the operator of the RTSP server to actually configure how long
   this extended period of inactivity is.  An operator should take into
   account, when doing this configuration, what the served content is
   and what this means for the extended period of inactivity.
   In case the server needs to stop providing service to the established
   sessions and there is no server to point at in a REDIRECT request,
   then TEARDOWN SHALL be used to terminate the session.  This method
   can also be used when non-recoverable internal errors have happened
   and the server has no other option than to terminate the sessions.
   The TEARDOWN request MUST be made only on the session aggregate
   control URI (i.e., it is not allowed to terminate individual media
   streams, if it is a session aggregate), and it MUST include the
   following headers: Session and Terminate-Reason.  The request only
   applies to the session identified in the Session header.  The server
   may include a message to the client's user with the "user-msg"
   parameter.
   The TEARDOWN request may alternatively be done on the wildcard URI
   "*" and without any session header.  The scope of such a request is
   limited to the next-hop (i.e., the RTSP agent in direct communication
   with the server) and applies, as well, to the RTSP connection between
   the next-hop RTSP agent and the server.  This request indicates that
   all sessions and pending requests being managed via the connection
   are terminated.  Any intervening proxies SHOULD do all of the
   following in the order listed:
   1.  respond to the TEARDOWN request
   2.  disconnect the control channel from the requesting server
   3.  pass the TEARDOWN request to each applicable client (typically
       those clients with an active session or an unanswered request)
      Note: The proxy is responsible for accepting TEARDOWN responses
      from its clients; these responses MUST NOT be passed on to either
      the original server or the target server in the redirect.
13.8.  GET_PARAMETER
   The GET_PARAMETER request retrieves the value of any specified
   parameter or parameters for a presentation or stream specified in the
   URI.  If the Session header is present in a request, the value of a
   parameter MUST be retrieved in the specified session context.  There
   are two ways of specifying the parameters to be retrieved.
   The first approach includes headers that have been defined to be
   usable for this purpose.  Headers for this purpose should allow
   empty, or stripped value parts to avoid having to specify bogus data
   when indicating the desire to retrieve a value.  The successful
   completion of the request should also be evident from any filled out
   values in the response.  The headers in this specification that MAY
   be used for retrieving their current value using GET_PARAMETER are
   listed below; additional headers MAY be specified in the future:
   o  Accept-Ranges
   o  Media-Range
   o  Media-Properties
   o  Range
   o  RTP-Info
   The other way is to specify a message body that lists the
   parameter(s) that are desired to be retrieved.  The Content-Type
   header (Section 18.19) is used to specify which format the message
   body has.  If the receiver of the request does not support the media
   type used for the message body, it SHALL respond using the error code
   415 (Unsupported Media Type).  The responder to a GET_PARAMETER
   request MUST use the media type of the request for the response.  For
   additional considerations regarding message body negotiation, see
   Section 9.3.
   RTSP agents implementing support for responding to GET_PARAMETER
   requests SHALL implement the "text/parameters" format (Appendix F).
   This to ensure that at least one known format for parameters is
   implemented and, thus, prevent parameter format negotiation failure.
   Parameters specified within the body of the message must all be
   understood by the request-receiving agent.  If one or more parameters
   are not understood a 451 (Parameter Not Understood) MUST be sent
   including a body listing the parameters that weren't understood.  If
   all parameters are understood, their values are filled in and
   returned in the response message body.
   The method can also be used without a message body or any header that
   requests parameters for keep-alive purposes.  The keep-alive timer
   has been updated for any request that is successful, i.e., a 200 OK
   response is received.  Any non-required header present in such a
   request may or may not have been processed.  Normally, the presence
   of filled-out values in the header will be indication that the header
   has been processed.  However, for cases when this is difficult to
   determine, it is recommended to use a feature tag and the Require
   header.  For this reason, it is usually easier if any parameters to
   be retrieved are sent in the body, rather than using any header.
   Example:
     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 431
           User-Agent: PhonyClient/1.2
           Session: OccldOFFq23KwjYpAnBbUr
           Content-Length: 26
           Content-Type: text/parameters
           packets_received
           jitter
     C->S: RTSP/2.0 200 OK
           CSeq: 431
           Session: OccldOFFq23KwjYpAnBbUr
           Server: PhonyServer/1.1
           Date: Mon, 08 Mar 2010 13:43:23 GMT
           Content-Length: 38
           Content-Type: text/parameters
           packets_received: 10
           jitter: 0.3838
13.9.  SET_PARAMETER
   This method requests the setting of the value of a parameter or a set
   of parameters for a presentation or stream specified by the URI.  If
   the Session header is present in a request, the value of a parameter
   MUST be retrieved in the specified session context.  The method MAY
   also be used without a message body.  It is the RECOMMENDED method to
   be used in a request sent for the sole purpose of updating the keep-
   alive timer.  If this request is successful, i.e., a 200 OK response
   is received, then the keep-alive timer has been updated.  Any non-
   required header present in such a request may or may not have been
   processed.  To allow a client to determine if any such header has
   been processed, it is necessary to use a feature tag and the Require
   header.  Due to this reason it is RECOMMENDED that any parameters are
   sent in the body rather than using any header.
   When using a message body to list the parameter(s) desired to be set,
   the Content-Type header (Section 18.19) is used to specify which
   format the message body has.  If the receiver of the request is not
   supporting the media type used for the message body, it SHALL respond
   using the error code 415 (Unsupported Media Type).  For additional
   considerations regarding message body negotiation, see Section 9.3.
   The responder to a SET_PARAMETER request MUST use the media type of
   the request for the response.  For additional considerations
   regarding message body negotiation, see Section 9.3.
   RTSP agents implementing support for responding to SET_PARAMETER
   requests SHALL implement the text/parameters format (Appendix F).
   This is to ensure that at least one known format for parameters is
   implemented and, thus, prevent parameter format negotiation failure.
   A request is RECOMMENDED to 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.  If the receiver of the
   request does not understand or cannot locate a parameter, error 451
   (Parameter Not Understood) MUST be used.  When a parameter is not
   allowed to change, the error code is 458 (Parameter Is Read-Only).
   The response body MUST contain only the parameters that have errors.
   Otherwise, a body MUST NOT be returned.  The response body MUST use
   the media type of the request for the response.
   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 connected to border RTSP proxies.
      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/2.0
           CSeq: 421
           User-Agent: PhonyClient/1.2
           Session: iixT43KLc
           Date: Mon, 08 Mar 2010 14:45:04 GMT
           Content-length: 20
           Content-type: text/parameters
           barparam: barstuff
     S->C: RTSP/2.0 451 Parameter Not Understood
           CSeq: 421
           Session: iixT43KLc
           Server: PhonyServer/1.0
           Date: Mon, 08 Mar 2010 14:44:56 GMT
           Content-length: 20
           Content-type: text/parameters
           barparam: barstuff
13.10.  REDIRECT
   The REDIRECT method is issued by a server to inform a client that the
   service provided will be terminated and where a corresponding service
   can be provided instead.  This may happen for different reasons.  One
   is that the server is being administered such that it must stop
   providing service.  Thus, the client is required to connect to
   another server location to access the resource indicated by the
   Request-URI.
   The REDIRECT request SHALL contain a Terminate-Reason header
   (Section 18.52) to inform the client of the reason for the request.
   Additional parameters related to the reason may also be included.
   The intention here is to allow a server administrator to do a
   controlled shutdown of the RTSP server.  That requires sufficient
   time to inform all entities having associated state with the server
   and for them to perform a controlled migration from this server to a
   fall-back server.
   A REDIRECT request with a Session header has end-to-end (i.e.,
   server-to-client) scope and applies only to the given session.  Any
   intervening proxies SHOULD NOT disconnect the control channel while
   there are other remaining end-to-end sessions.  The REQUIRED Location
   header MUST contain a complete absolute URI pointing to the resource
   to which the client SHOULD reconnect.  Specifically, the Location
   MUST NOT contain just the host and port.  A client may receive a
   REDIRECT request with a Session header, if and only if, an end-to-end
   session has been established.
   A client may receive a REDIRECT request without a Session header at
   any time when it has communication or a connection established with a
   server.  The scope of such a request is limited to the next-hop
   (i.e., the RTSP agent in direct communication with the server) and
   applies to all sessions controlled, as well as the connection between
   the next-hop RTSP agent and the server.  A REDIRECT request without a
   Session header indicates that all sessions and pending requests being
   managed via the connection MUST be redirected.  The Location header,
   if included in such a request, SHOULD contain an absolute URI with
   only the host address and the OPTIONAL port number of the server to
   which the RTSP agent SHOULD reconnect.  Any intervening proxies
   SHOULD do all of the following in the order listed:
   1.  respond to the REDIRECT request
   2.  disconnect the control channel from the requesting server
   3.  connect to the server at the given host address
   4.  pass the REDIRECT request to each applicable client (typically
       those clients with an active session or an unanswered request)
      Note: The proxy is responsible for accepting REDIRECT responses
      from its clients; these responses MUST NOT be passed on to either
      the original server or the redirected server.
   A server that needs to terminate a session or all its sessions and
   lacks an alternative server to redirect to, SHALL instead use
   TEARDOWN requests.
   When no Terminate-Reason "time" parameter is included in a REDIRECT
   request, the client SHALL perform the redirection immediately and
   return a response to the server.  The server shall consider the
   session to be terminated and can free any associated state after it
   receives the successful (2xx) response.  The server MAY close the
   signaling connection upon receiving the response, and the client
   SHOULD close the signaling connection after sending the 2xx response.
   The exception to this is when the client has several sessions on the
   server being managed by the given signaling connection.  In this
   case, the client SHOULD close the connection when it has received and
   responded to REDIRECT requests for all the sessions managed by the
   signaling connection.
   The Terminate-Reason header "time" parameter MAY be used to indicate
   the wallclock time by which the redirection MUST have taken place.
   To allow a client to determine that redirect time without being time
   synchronized with the server, the server MUST include a Date header
   in the request.  The client should have terminated the session and
   closed the connection before the redirection time-line terminated.
   The server MAY simply cease to provide service when the deadline time
   has been reached, or it can issue a TEARDOWN requests to the
   remaining sessions.
   If the REDIRECT request times out following the rules in
   Section 10.4, the server MAY terminate the session or transport
   connection that would be redirected by the request.  This is a
   safeguard against misbehaving clients that refuse to respond to a
   REDIRECT request.  This action removes any incentive of not
   acknowledging the reception of a REDIRECT request.
   After a REDIRECT request has been processed, a client that wants to
   continue to receive media for the resource identified by the Request-
   URI will have to establish a new session with the designated host.
   If the URI given in the Location header is a valid resource URI, a
   client SHOULD issue a DESCRIBE request for the URI.
      Note: The media resource indicated by the Location header can be
      identical, slightly different, or totally different.  This is the
      reason why a new DESCRIBE request SHOULD be issued.
   If the Location header contains only a host address, the client may
   assume that the media on the new server is identical to the media on
   the old server, i.e., all media configuration information from the
   old session is still valid except for the host address.  However, the
   usage of conditional SETUP using MTag identifiers is RECOMMENDED as a
   means to verify the assumption.
   This example request redirects traffic for this session to the new
   server at the given absolute time:
     S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 732
           Location: rtsp://s2.example.com:8001/fizzle/foo
           Terminate-Reason: Server-Admin ;time=19960213T143205Z
           Session: uZ3ci0K+Ld-M
           Date: Thu, 13 Feb 1996 14:30:43 GMT
     C->S: RTSP/2.0 200 OK
           CSeq: 732
           User-Agent: PhonyClient/1.2
           Session: uZ3ci0K+Ld-M