Section 2. Protocol Overview

This section provides an informative overview of the different
   mechanisms in the RTSP 2.0 protocol to give the reader a high-level
   understanding before getting into all the specific details.  In case
   of conflict with this description and the later sections, the later
   sections take precedence.  For more information about use cases
   considered for RTSP, see Appendix E.
   RTSP 2.0 is a bidirectional request and response protocol that first
   establishes a context including content resources (the media) and
   then controls the delivery of these content resources from the
   provider to the consumer.  RTSP has three fundamental parts: Session
   Establishment, Media Delivery Control, and an extensibility model
   described below.  The protocol is based on some assumptions about
   existing functionality to provide a complete solution for client-
   controlled real-time media delivery.
   RTSP uses text-based messages, requests and responses, that may
   contain a binary message body.  An RTSP request starts with a method
   line that identifies the method, the protocol, and version and the
   resource on which to act.  The resource is identified by a URI and
   the hostname part of the URI is used by RTSP client to resolve the
   IPv4 or IPv6 address of the RTSP server.  Following the method line
   are a number of RTSP headers.  These lines are ended by two
   consecutive carriage return line feed (CRLF) character pairs.  The
   message body, if present, follows the two CRLF character pairs, and
   the body's length is described by a message header.  RTSP responses
   are similar, but they start with a response line with the protocol
   and version followed by a status code and a reason phrase.  RTSP
   messages are sent over a reliable transport protocol between the
   client and server.  RTSP 2.0 requires clients and servers to
   implement TCP and TLS over TCP as mandatory transports for RTSP
   messages.
2.1.  Presentation Description
   RTSP exists to provide access to multimedia presentations and content
   but tries to be agnostic about the media type or the actual media
   delivery protocol that is used.  To enable a client to implement a
   complete system, an RTSP-external mechanism for describing the
   presentation and the delivery protocol(s) is used.  RTSP assumes that
   this description is either delivered completely out of band or as a
   data object in the response to a client's request using the DESCRIBE
   method (Section 13.2).
   Parameters that commonly have to be included in the presentation
   description are the following:
   o  The number of media streams;
   o  the resource identifier for each media stream/resource that is to
      be controlled by RTSP;
   o  the protocol that will be used to deliver each media stream;
   o  the transport protocol parameters that are not negotiated or vary
      with each client;
   o  the media-encoding information enabling a client to correctly
      decode the media upon reception; and
   o  an aggregate control resource identifier.
   RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
   resources and aggregates under common control (see Section 4.2).
   This specification describes in Appendix D how one uses SDP [RFC4566]
   for describing the presentation.
2.2.  Session Establishment
   The RTSP client can request the establishment of an RTSP session
   after having used the presentation description to determine which
   media streams are available, which media delivery protocol is used,
   and the resource identifiers of the media streams.  The RTSP session
   is a common context between the client and the server that consists
   of one or more media resources that are to be under common media
   delivery control.
   The client creates an RTSP session by sending a request using the
   SETUP method (Section 13.3) to the server.  In the Transport header
   (Section 18.54) of the SETUP request, the client also includes all
   the transport parameters necessary to enable the media delivery
   protocol to function.  This includes parameters that are
   preestablished by the presentation description but necessary for any
   middlebox to correctly handle the media delivery protocols.  The
   Transport header in a request may contain multiple alternatives for
   media delivery in a prioritized list, which the server can select
   from.  These alternatives are typically based on information in the
   presentation description.
   When receiving a SETUP request, the server determines if the media
   resource is available and if one or more of the of the transport
   parameter specifications are acceptable.  If that is successful, an
   RTSP session context is created and the relevant parameters and state
   is stored.  An identifier is created for the RTSP session and
   included in the response in the Session header (Section 18.49).  The
   SETUP response includes a Transport header that specifies which of
   the alternatives has been selected and relevant parameters.
   A SETUP request that references an existing RTSP session but
   identifies a new media resource is a request to add that media
   resource under common control with the already-present media
   resources in an aggregated session.  A client can expect this to work
   for all media resources under RTSP control within a multimedia
   content container.  However, a server will likely refuse to aggregate
   resources from different content containers.  Even if an RTSP session
   contains only a single media stream, the RTSP session can be
   referenced by the aggregate control URI.
   To avoid an extra round trip in the session establishment of
   aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e.,
   the client can send multiple requests back-to-back without waiting
   first for the completion of any of them.  The client uses a client-
   selected identifier in the Pipelined-Requests header (Section 18.33)
   to instruct the server to bind multiple requests together as if they
   included the session identifier.
   The SETUP response also provides additional information about the
   established sessions in a couple of different headers.  The Media-
   Properties header (Section 18.29) includes a number of properties
   that apply for the aggregate that is valuable when doing media
   delivery control and configuring user interface.  The Accept-Ranges
   header (Section 18.5) informs the client about range formats that the
   server supports for these media resources.  The Media-Range header
   (Section 18.30) informs the client about the time range of the media
   currently available.
2.3.  Media Delivery Control
   After having established an RTSP session, the client can start
   controlling the media delivery.  The basic operations are "begin
   playback", using the PLAY method (Section 13.4) and "suspend (pause)
   playback" by using the PAUSE method (Section 13.6).  PLAY also allows
   for choosing the starting media position from which the server should
   deliver the media.  The positioning is done by using the Range header
   (Section 18.40) that supports several different time formats: Normal
   Play Time (NPT) (Section 4.4.2), Society of Motion Picture and
   Television Engineers (SMPTE) Timestamps (Section 4.4.1), and absolute
   time (Section 4.4.3).  The Range header also allows the client to
   specify a position where delivery should end, thus allowing a
   specific interval to be delivered.
   The support for positioning/searching within media content depends on
   the content's media properties.  Content exists in a number of
   different types, such as on-demand, live, and live with simultaneous
   recording.  Even within these categories, there are differences in
   how the content is generated and distributed, which affect how it can
   be accessed for playback.  The properties applicable for the RTSP
   session are provided by the server in the SETUP response using the
   Media-Properties header (Section 18.29).  These are expressed using
   one or several independent attributes.  A first attribute is Random-
   Access, which indicates whether positioning is possible, and with
   what granularity.  Another aspect is whether the content will change
   during the lifetime of the session.  While on-demand content will be
   provided in full from the beginning, a live stream being recorded
   results in the length of the accessible content growing as the
   session goes on.  There also exists content that is dynamically built
   by a protocol other than RTSP and, thus, also changes in steps during
   the session, but maybe not continuously.  Furthermore, when content
   is recorded, there are cases where the complete content is not
   maintained, but, for example, only the last hour.  All of these
   properties result in the need for mechanisms that will be discussed
   below.
   When the client accesses on-demand content that allows random access,
   the client can issue the PLAY request for any point in the content
   between the start and the end.  The server will deliver media from
   the closest random access point prior to the requested point and
   indicate that in its PLAY response.  If the client issues a PAUSE,
   the delivery will be halted and the point at which the server stopped
   will be reported back in the response.  The client can later resume
   by sending a PLAY request without a Range header.  When the server is
   about to complete the PLAY request by delivering the end of the
   content or the requested range, the server will send a PLAY_NOTIFY
   request (Section 13.5) indicating this.
   When playing live content with no extra functions, such as recording,
   the client will receive the live media from the server after having
   sent a PLAY request.  Seeking in such content is not possible as the
   server does not store it, but only forwards it from the source of the
   session.  Thus, delivery continues until the client sends a PAUSE
   request, tears down the session, or the content ends.
   For live sessions that are being recorded, the client will need to
   keep track of how the recording progresses.  Upon session
   establishment, the client will learn the current duration of the
   recording from the Media-Range header.  Because the recording is
   ongoing, the content grows in direct relation to the time passed.
   Therefore, each server's response to a PLAY request will contain the
   current Media-Range header.  The server should also regularly send
   (approximately every 5 minutes) the current media range in a
   PLAY_NOTIFY request (Section 13.5.2).  If the live transmission ends,
   the server must send a PLAY_NOTIFY request with the updated Media-
   Properties indicating that the content stopped being a recorded live
   session and instead became on-demand content; the request also
   contains the final media range.  While the live delivery continues,
   the client can request to play the current live point by using the
   NPT timescale symbol "now", or it can request a specific point in the
   available content by an explicit range request for that point.  If
   the requested point is outside of the available interval, the server
   will adjust the position to the closest available point, i.e., either
   at the beginning or the end.
   A special case of recording is that where the recording is not
   retained longer than a specific time period; thus, as the live
   delivery continues, the client can access any media within a moving
   window that covers, for example, "now" to "now" minus 1 hour.  A
   client that pauses on a specific point within the content may not be
   able to retrieve the content anymore.  If the client waits too long
   before resuming the pause point, the content may no longer be
   available.  In this case, the pause point will be adjusted to the
   closest point in the available media.
2.4.  Session Parameter Manipulations
   A session may have additional state or functionality that affects how
   the server or client treats the session or content, how it functions,
   or feedback on how well the session works.  Such extensions are not
   defined in this specification, but they may be covered in various
   extensions.  RTSP has two methods for retrieving and setting
   parameter values on either the client or the server: GET_PARAMETER
   (Section 13.8) and SET_PARAMETER (Section 13.9).  These methods carry
   the parameters in a message body of the appropriate format.  One can
   also use headers to query state with the GET_PARAMETER method.  As an
   example, clients needing to know the current media range for a time-
   progressing session can use the GET_PARAMETER method and include the
   media range.  Furthermore, synchronization information can be
   requested by using a combination of RTP-Info (Section 18.45) and
   Range (Section 18.40).
   RTSP 2.0 does not have a strong mechanism for negotiating the headers
   or parameters and their formats.  However, responses will indicate
   request-headers or parameters that are not supported.  A priori
   determination of what features are available needs to be done through
   out-of-band mechanisms, like the session description, or through the
   usage of feature tags (Section 4.5).
2.5.  Media Delivery
   This document specifies how media is delivered with RTP [RFC3550]
   over UDP [RFC768], TCP [RFC793], or the RTSP connection.  Additional
   protocols may be specified in the future as needed.
   The usage of RTP as a media delivery protocol requires some
   additional information to function well.  The PLAY response contains
   information to enable reliable and timely delivery of how a client
   should synchronize different sources in the different RTP sessions.
   It also provides a mapping between RTP timestamps and the content-
   time scale.  When the server wants to notify the client about the
   completion of the media delivery, it sends a PLAY_NOTIFY request to
   the client.  The PLAY_NOTIFY request includes information about the
   stream end, including the last RTP sequence number for each stream,
   thus enabling the client to empty the buffer smoothly.
2.5.1.  Media Delivery Manipulations
   The basic playback functionality of RTSP enables delivery of a range
   of requested content to the client at the pace intended by the
   content's creator.  However, RTSP can also manipulate the delivery to
   the client in two ways.
   Scale:  The ratio of media-content time delivered per unit of
      playback time.
   Speed:  The ratio of playback time delivered per unit of wallclock
      time.
   Both affect the media delivery per time unit.  However, they
   manipulate two independent timescales and the effects are possible to
   combine.
   Scale (Section 18.46) is used for fast-forward or slow-motion control
   as it changes the amount of content timescale that should be played
   back per time unit.  Scale > 1.0, means fast forward, e.g., scale =
   2.0 results in that 2 seconds of content being played back every
   second of playback.  Scale = 1.0 is the default value that is used if
   no scale is specified, i.e., playback at the content's original rate.
   Scale values between 0 and 1.0 provide for slow motion.  Scale can be
   negative to allow for reverse playback in either regular pace
   (scale = -1.0), fast backwards (scale < -1.0), or slow-motion
   backwards (-1.0 < scale < 0).  Scale = 0 would be equal to pause and
   is not allowed.
   In most cases, the realization of scale means server-side
   manipulation of the media to ensure that the client can actually play
   it back.  The nature of these media manipulations and when they are
   needed is highly media-type dependent.  Let's consider two common
   media types, audio and video.
   It is very difficult to modify the playback rate of audio.
   Typically, no more than a factor of two is possible while maintaining
   intelligibility by changing the pitch and rate of speech.  Music goes
   out of tune if one tries to manipulate the playback rate by
   resampling it.  This is a well-known problem, and audio is commonly
   muted or played back in short segments with skips to keep up with the
   current playback point.
   For video, it is possible to manipulate the frame rate, although the
   rendering capabilities are often limited to certain frame rates.
   Also, the allowed bitrates in decoding, the structure used in the
   encoding, and the dependency between frames and other capabilities of
   the rendering device limits the possible manipulations.  Therefore,
   the basic fast-forward capabilities often are implemented by
   selecting certain subsets of frames.
   Due to the media restrictions, the possible scale values are commonly
   restricted to the set of realizable scale ratios.  To enable the
   clients to select from the possible scale values, RTSP can signal the
   supported scale ratios for the content.  To support aggregated or
   dynamic content, where this may change during the ongoing session and
   dependent on the location within the content, a mechanism for
   updating the media properties and the scale factor currently in use,
   exists.
   Speed (Section 18.50) affects how much of the playback timeline is
   delivered in a given wallclock period.  The default is Speed = 1
   which means to deliver at the same rate the media is consumed.
   Speed > 1 means that the receiver will get content faster than it
   regularly would consume it.  Speed < 1 means that delivery is slower
   than the regular media rate.  Speed values of 0 or lower have no
   meaning and are not allowed.  This mechanism enables two general
   functionalities.  One is client-side scale operations, i.e., the
   client receives all the frames and makes the adjustment to the
   playback locally.  The second is delivery control for the buffering
   of media.  By specifying a speed over 1.0, the client can build up
   the amount of playback time it has present in its buffers to a level
   that is sufficient for its needs.
   A naive implementation of Speed would only affect the transmission
   schedule of the media and has a clear impact on the needed bandwidth.
   This would result in the data rate being proportional to the speed
   factor.  Speed = 1.5, i.e., 50% faster than normal delivery, would
   result in a 50% increase in the data-transport rate.  Whether or not
   that can be supported depends solely on the underlying network path.
   Scale may also have some impact on the required bandwidth due to the
   manipulation of the content in the new playback schedule.  An example
   is fast forward where only the independently decodable intra-frames
   are included in the media stream.  This usage of solely intra-frames
   increases the data rate significantly compared to a normal sequence
   with the same number of frames, where most frames are encoded using
   prediction.
   This potential increase of the data rate needs to be handled by the
   media sender.  The client has requested that the media be delivered
   in a specific way, which should be honored.  However, the media
   sender cannot ignore if the network path between the sender and the
   receiver can't handle the resulting media stream.  In that case, the
   media stream needs to be adapted to fit the available resources of
   the path.  This can result in a reduced media quality.
   The need for bitrate adaptation becomes especially problematic in
   connection with the Speed semantics.  If the goal is to fill up the
   buffer, the client may not want to do that at the cost of reduced
   quality.  If the client wants to make local playout changes, then it
   may actually require that the requested speed be honored.  To resolve
   this issue, Speed uses a range so that both cases can be supported.
   The server is requested to use the highest possible speed value
   within the range, which is compatible with the available bandwidth.
   As long as the server can maintain a speed value within the range, it
   shall not change the media quality, but instead modify the actual
   delivery rate in response to available bandwidth and reflect this in
   the Speed value in the response.  However, if this is not possible,
   the server should instead modify the media quality to respect the
   lowest speed value and the available bandwidth.
   This functionality enables the local scaling implementation to use a
   tight range, or even a range where the lower bound equals the upper
   bound, to identify that it requires the server to deliver the
   requested amount of media time per delivery time, independent of how
   much it needs to adapt the media quality to fit within the available
   path bandwidth.  For buffer filling, it is suitable to use a range
   with a reasonable span and with a lower bound at the nominal media
   rate 1.0, such as 1.0 - 2.5.  If the client wants to reduce the
   buffer, it can specify an upper bound that is below 1.0 to force the
   server to deliver slower than the nominal media rate.
2.6.  Session Maintenance and Termination
   The session context that has been established is kept alive by having
   the client show liveness.  This is done in two main ways:
   o  Media-transport protocol keep-alive.  RTP Control Protocol (RTCP)
      may be used when using RTP.
   o  Any RTSP request referencing the session context.
   Section 10.5 discusses the methods for showing liveness in more
   depth.  If the client fails to show liveness for more than the
   established session timeout value (normally 60 seconds), the server
   may terminate the context.  Other values may be selected by the
   server through the inclusion of the timeout parameter in the session
   header.
   The session context is normally terminated by the client sending a
   TEARDOWN request (Section 13.7) to the server referencing the
   aggregated control URI.  An individual media resource can be removed
   from a session context by a TEARDOWN request referencing that
   particular media resource.  If all media resources are removed from a
   session context, the session context is terminated.
   A client may keep the session alive indefinitely if allowed by the
   server; however, a client is advised to release the session context
   when an extended period of time without media delivery activity has
   passed.  The client can re-establish the session context if required
   later.  What constitutes an extended period of time is dependent on
   the client, server, and their usage.  It is recommended that the
   client terminate the session before ten times the session timeout
   value has passed.  A server may terminate the session after one
   session timeout period without any client activity beyond keep-alive.
   When a server terminates the session context, it does so by sending a
   TEARDOWN request indicating the reason.
   A server can also request that the client tear down the session and
   re-establish it at an alternative server, as may be needed for
   maintenance.  This is done by using the REDIRECT method
   (Section 13.10).  The Terminate-Reason header (Section 18.52) is used
   to indicate when and why.  The Location header indicates where it
   should connect if there is an alternative server available.  When the
   deadline expires, the server simply stops providing the service.  To
   achieve a clean closure, the client needs to initiate session
   termination prior to the deadline.  In case the server has no other
   server to redirect to, and it wants to close the session for
   maintenance, it shall use the TEARDOWN method with a Terminate-Reason
   header.
2.7.  Extending RTSP
   RTSP is quite a versatile protocol that supports extensions in many
   different directions.  Even this core specification contains several
   blocks of functionality that are optional to implement.  The use case
   and need for the protocol deployment should determine what parts are
   implemented.  Allowing for extensions makes it possible for RTSP to
   address additional use cases.  However, extensions will affect the
   interoperability of the protocol; therefore, it is important that
   they can be added in a structured way.
   The client can learn the capability of a server by using the OPTIONS
   method (Section 13.1) and the Supported header (Section 18.51).  It
   can also try and possibly fail using new methods or require that
   particular features be supported using the Require (Section 18.43) or
   Proxy-Require (Section 18.37) header.
   The RTSP, in itself, can be extended in three ways, listed here in
   increasing order of the magnitude of changes supported:
   o  Existing methods can be extended with new parameters, for example,
      headers, as long as these parameters can be safely ignored by the
      recipient.  If the client needs negative acknowledgment when a
      method extension is not supported, a tag corresponding to the
      extension may be added in the field of the Require or Proxy-
      Require headers.
   o  New methods can be added.  If the recipient of the message does
      not understand the request, it must respond with error code 501
      (Not Implemented) so that the sender can avoid using this method
      again.  A client may also use the OPTIONS method to inquire about
      methods supported by the server.  The server must list the methods
      it supports using the Public response-header.
   o  A new version of the protocol can be defined, allowing almost all
      aspects (except the position of the protocol version number) to
      change.  A new version of the protocol must be registered through
      a Standards Track document.
   The basic capability discovery mechanism can be used to both discover
   support for a certain feature and to ensure that a feature is
   available when performing a request.  For a detailed explanation of
   this, see Section 11.
   New media delivery protocols may be added and negotiated at session
   establishment, in addition to extensions to the core protocol.
   Certain types of protocol manipulations can be done through parameter
   formats using SET_PARAMETER and GET_PARAMETER.