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

14.  Embedded (Interleaved) Binary Data

   In order to fulfill certain requirements on the network side, e.g.,
   in conjunction with network address translators that block RTP
   traffic over UDP, it may be necessary to interleave RTSP messages and
   media-stream data.  This interleaving should generally be avoided
   unless necessary since it complicates client and server operation and
   imposes additional overhead.  Also, head-of-line blocking may cause
   problems.  Interleaved binary data SHOULD only be used if RTSP is
   carried over TCP.  Interleaved data is not allowed inside RTSP
   messages.

   Stream data, such as RTP packets, is encapsulated by an ASCII dollar
   sign (36 decimal) followed by a one-octet channel identifier and the
   length of the encapsulated binary data as a binary, two-octet
   unsigned integer in network octet order (Appendix B of [RFC791]).
   The stream data follows immediately afterwards, without a CRLF, but
   including the upper-layer protocol headers.  Each dollar sign block
   MUST contain exactly one upper-layer protocol data unit, e.g., one
   RTP packet.

      Note that this mechanism does not support PDUs larger than 65535
      octets, which matches the maximum payload size of regular, non-
      jumbo IPv4 and IPv6 packets.  If the media delivery protocol
      intended to be used has larger PDUs than that, a definition of a
      PDU fragmentation mechanism will be required to support embedded
      binary data.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | "$" = 36      | Channel ID    | Length in octets              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : Binary data (Length according to Length field)                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Embedded Interleaved Binary Data Format

   The channel identifier is defined in the Transport header with the
   interleaved parameter (Section 18.54).

   When the transport choice is RTP, RTCP messages are also interleaved
   by the server over the TCP connection.  The usage of RTCP messages is
   indicated by including an interval containing a second channel in the
   interleaved parameter of the Transport header (see Section 18.54).
   If RTCP is used, packets MUST be sent on the first available channel

   that is higher than the RTP channel.  The channels are bidirectional,
   using the same Channel ID in both directions; therefore, RTCP traffic
   is sent on the second channel in both directions.

      RTCP is sometimes needed for synchronization when two or more
      streams are interleaved in such a fashion.  Also, this provides a
      convenient way to tunnel RTP/RTCP packets through the RTSP
      connection (TCP or TCP/TLS) when required by the network
      configuration and to transfer them onto UDP when possible.

     C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: npt, smpte, clock
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 2
           Date: Thu, 05 Jun 1997 18:57:18 GMT
           Transport: RTP/AVP/TCP;unicast;interleaved=5-6
           Session: OccldOFFq23KwjYpAnBbUr
           Accept-Ranges: npt
           Media-Properties: Random-Access=0.2, Immutable, Unlimited

     C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
           CSeq: 3
           Session: OccldOFFq23KwjYpAnBbUr
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 3
           Session: OccldOFFq23KwjYpAnBbUr
           Date: Thu, 05 Jun 1997 18:57:19 GMT
           RTP-Info: url="rtsp://example.com/bar.file"
             ssrc=0D12F123:seq=232433;rtptime=972948234
           Range: npt=0-56.8
           Seek-Style: RAP

     S->C: $005{2 octet length}{"length" octets data, w/RTP header}
     S->C: $005{2 octet length}{"length" octets data, w/RTP header}
     S->C: $006{2 octet length}{"length" octets  RTCP packet}

15.  Proxies

   RTSP Proxies are RTSP agents that are located in between a client and
   a server.  A proxy can take on the roles of both client and server
   depending on what it tries to accomplish.  RTSP proxies use two
   transport-layer connections: one from the RTSP client to the RTSP
   proxy and a second from the RTSP proxy to the RTSP server.  Proxies
   are introduced for several different reasons; those listed below are
   often combined.

   Caching Proxy:  This type of proxy is used to reduce the workload on
         servers and connections.  By caching the description and media
         streams, i.e., the presentation, the proxy can serve a client
         with content, but without requesting it from the server once it
         has been cached and has not become stale.  See Section 16.
         This type of proxy is also expected to understand RTSP endpoint
         functionality, i.e., functionality identified in the Require
         header in addition to what Proxy-Require demands.

   Translator Proxy:  This type of proxy is used to ensure that an RTSP
         client gets access to servers and content on an external
         network or gets access by using content encodings not supported
         by the client.  The proxy performs the necessary translation of
         addresses, protocols, or encodings.  This type of proxy is
         expected also to understand RTSP endpoint functionality, i.e.,
         functionality identified in the Require header in addition to
         what Proxy-Require demands.

   Access Proxy:  This type of proxy is used to ensure that an RTSP
         client gets access to servers on an external network.  Thus,
         this proxy is placed on the border between two domains, e.g., a
         private address space and the public Internet.  The proxy
         performs the necessary translation, usually addresses.  This
         type of proxy is required to redirect the media to itself or a
         controlled gateway that performs the translation before the
         media can reach the client.

   Security Proxy:  This type of proxy is used to help facilitate
         security functions around RTSP.  For example, in the case of a
         firewalled network, the security proxy requests that the
         necessary pinholes in the firewall are opened when a client in
         the protected network wants to access media streams on the
         external side.  This proxy can perform its function without
         redirecting the media between the server and client.  However,
         in deployments with private address spaces, this proxy is
         likely to be combined with the access proxy.  The functionality
         of this proxy is usually closely tied into understanding all
         aspects of the media transport.

   Auditing Proxy:  RTSP proxies can also provide network owners with a
         logging and auditing point for RTSP sessions, e.g., for
         corporations that track their employees usage of the network.
         This type of proxy can perform its function without inserting
         itself or any other node in the media transport.  This proxy
         type can also accept unknown methods as it doesn't interfere
         with the clients' requests.

   All types of proxies can also be used when using secured
   communication with TLS, as RTSP 2.0 allows the client to approve
   certificate chains used for connection establishment from a proxy;
   see Section 19.3.2.  However, that trust model may not be suitable
   for all types of deployment.  In those cases, the secured sessions do
   bypass the proxies.

   Access proxies SHOULD NOT be used in equipment like NATs and
   firewalls that aren't expected to be regularly maintained, like home
   or small office equipment.  In these cases, it is better to use the
   NAT traversal procedures defined for RTSP 2.0 [RFC7825].  The reason
   for these recommendations is that any extensions of RTSP resulting in
   new media-transport protocols or profiles, new parameters, etc., may
   fail in a proxy that isn't maintained.  This would impede RTSP's
   future development and usage.

15.1.  Proxies and Protocol Extensions

   The existence of proxies must always be considered when developing
   new RTSP extensions.  Most types of proxies will need to implement
   any new method to operate correctly in the presence of that
   extension.  New headers can be introduced and will not be blocked by
   older proxies.  However, it is important to consider if this header
   and its function are required to be understood by the proxy or if it
   can be simply forwarded.  If the header needs to be understood, a
   feature tag representing the functionality MUST be included in the
   Proxy-Require header.  Below are guidelines for analysis whether the
   header needs to be understood.  The Transport header and its
   parameters are extensible, which requires handling rules for a proxy
   in order to ensure a correct interpretation.

   Whether or not a proxy needs to understand a header is not easy to
   determine as they serve a broad variety of functions.  When
   evaluating if a header needs to be understood, one can divide the
   functionality into three main categories:

   Media modifying:  The caching and translator proxies modify the
      actual media and therefore need also to understand the request
      directed to the server that affects how the media is rendered.
      Thus, this type of proxy also needs to understand the server-side
      functionality.

   Transport modifying:  The access and the security proxy both need to
      understand how the media transport is performed, either for
      opening pinholes or translating the outer headers, e.g., IP and
      UDP or TCP.

   Non-modifying:  The audit proxy is special in that it does not modify
      the messages in other ways than to insert the Via header.  That
      makes it possible for this type to forward RTSP messages that
      contain different types of unknown methods, headers, or header
      parameters.

   An extension has to be classified as mandatory to be implemented for
   a proxy, if an extension has to be understood by a "Transport
   modifying" type of proxy.

15.2.  Multiplexing and Demultiplexing of Messages

   RTSP proxies may have to multiplex several RTSP sessions from their
   clients towards RTSP servers.  This requires that RTSP requests from
   multiple clients be multiplexed onto a common connection for requests
   outgoing to an RTSP server, and, on the way back, the responses be
   demultiplexed from the server to per-client responses.  On the
   protocol level, this requires that request and response messages be
   handled in both directions, requiring that there be a mechanism to
   correlate which request/response pair exchanged between proxy and
   server is mapped to which client (or client request).

   This multiplexing of requests and demultiplexing of responses is done
   by using the CSeq header field.  The proxy has to rewrite the CSeq in
   requests to the server and responses from the server and remember
   which CSeq is mapped to which client.  The proxy also needs to ensure
   that the order of the message related to each client is maintained.
   Section 18.20 defines the handling of how requests and responses are
   rewritten.