Section 4. Protocol Parameters

4.1.  RTSP Version
   This specification defines version 2.0 of RTSP.
   RTSP uses a "<major>.<minor>" numbering scheme to indicate versions
   of the protocol.  The protocol versioning policy is intended to allow
   the sender to indicate the format of a message and its capacity for
   understanding further RTSP communication rather than the features
   obtained via that communication.  No change is made to the version
   number for the addition of message components that do not affect
   communication behavior or that only add to extensible field values.
   The <minor> number is incremented when the changes made to the
   protocol add features that do not change the general message parsing
   algorithm but that may add to the message semantics and imply
   additional capabilities of the sender.  The <major> number is
   incremented when the format of a message within the protocol is
   changed.  The version of an RTSP message is indicated by an RTSP-
   Version field in the first line of the message.  Note that the major
   and minor numbers MUST be treated as separate integers and that each
   MAY be incremented higher than a single digit.  Thus, RTSP/2.4 is a
   lower version than RTSP/2.13, which, in turn, is lower than
   RTSP/12.3.  Leading zeros SHALL NOT be sent and MUST be ignored by
   recipients.
4.2.  RTSP IRI and URI
   RTSP 2.0 defines and registers or updates three URI schemes "rtsp",
   "rtsps", and "rtspu".  The usage of the last, "rtspu", is unspecified
   in RTSP 2.0 and is defined here to register the URI scheme that was
   defined in RTSP 1.0.  The "rtspu" scheme indicates unspecified
   transport of the RTSP messages over unreliable transport means (UDP
   in RTSP 1.0).  An RTSP server MUST respond with an error code
   indicating the "rtspu" scheme is not implemented (501) to a request
   that carries a "rtspu" URI scheme.
   The details of the syntax of "rtsp" and "rtsps" URIs have been
   changed from RTSP 1.0.  These changes include the addition of:
   o  Support for an IPv6 literal in the host part and future IP
      literals through a mechanism defined in [RFC3986].
   o  A new relative format to use in the RTSP elements that is not
      required to start with "/".
   Neither should have any significant impact on interoperability.  If
   IPv6 literals are needed in the RTSP URI, then that RTSP server must
   be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol.
   If an RTSP 1.0 client attempts to process the URI, the URI will not
   match the allowed syntax, it will be considered invalid, and
   processing will be stopped.  This is clearly a failure to reach the
   resource; however, it is not a signification issue as RTSP 2.0
   support was needed anyway in both server and client.  Thus, failure
   will only occur in a later step when there is an RTSP version
   mismatch between client and server.  The second change will only
   occur inside RTSP message headers, as the Request-URI must be an
   absolute URI.  Thus, such usages will only occur after an agent has
   accepted and started processing RTSP 2.0 messages, and an agent using
   RTSP 1.0 only will not be required to parse such types of relative
   URIs.
   This specification also defines the format of RTSP IRIs [RFC3987]
   that can be used as RTSP resource identifiers and locators on web
   pages, user interfaces, on paper, etc.  However, the RTSP request
   message format only allows usage of the absolute URI format.  The
   RTSP IRI format MUST use the rules and transformation for IRIs to
   URIs, as defined in [RFC3987].  This allows a URI that matches the
   RTSP 2.0 specification, and so is suitable for use in a request, to
   be created from an RTSP IRI.
   The RTSP IRI and URI are both syntax restricted compared to the
   generic syntax defined in [RFC3986] and [RFC3987]:
   o  An absolute URI requires the authority part; i.e., a host identity
      MUST be provided.
   o  Parameters in the path element are prefixed with the reserved
      separator ";".
   The "scheme" and "host" parts of all URIs [RFC3986] and IRIs
   [RFC3987] are case insensitive.  All other parts of RTSP URIs and
   IRIs are case sensitive, and they MUST NOT be case mapped.
   The fragment identifier is used as defined in Sections 3.5 and 4.3 of
   [RFC3986], i.e., the fragment is to be stripped from the IRI by the
   requester and not included in the Request-URI.  The user agent needs
   to interpret the value of the fragment based on the media type the
   request relates to; i.e., the media type indicated in Content-Type
   header in the response to a DESCRIBE request.
   The syntax of any URI query string is unspecified and responder
   (usually the server) specific.  The query is, from the requester's
   perspective, an opaque string and needs to be handled as such.
   Please note that relative URIs with queries are difficult to handle
   due to the relative URI handling rules of RFC 3986.  Any change of
   the path element using a relative URI results in the stripping of the
   query, which means the relative part needs to contain the query.
   The URI scheme "rtsp" requires that commands be issued via a reliable
   protocol (within the Internet, TCP), while the scheme "rtsps"
   identifies a reliable transport using secure transport (TLS
   [RFC5246]); see Section 19.
   For the scheme "rtsp", if no port number is provided in the authority
   part of the URI, the port number 554 MUST be used.  For the scheme
   "rtsps", if no port number is provided in the authority part of the
   URI port number, the TCP port 322 MUST be used.
   A presentation or a stream is identified by a textual media
   identifier, using the character set and escape conventions of URIs
   [RFC3986].  URIs may refer to a stream or an aggregate of streams;
   i.e., a presentation.  Accordingly, requests described in Section 13
   can apply to either the whole presentation or an individual stream
   within the presentation.  Note that some request methods can only be
   applied to streams, not presentations, and vice versa.
   For example, the RTSP URI:
      rtsp://media.example.com:554/twister/audiotrack
   may identify the audio stream within the presentation "twister",
   which can be controlled via RTSP requests issued over a TCP
   connection to port 554 of host media.example.com.
   Also, the RTSP URI:
      rtsp://media.example.com:554/twister
   identifies the presentation "twister", which may be composed of audio
   and video streams, but could also be something else, such as a random
   media redirector.
      This does not imply a standard way to reference streams in URIs.
      The presentation description defines the hierarchical
      relationships in the presentation and the URIs for the individual
      streams.  A presentation description may name a stream "a.mov" and
      the whole presentation "b.mov".
   The path components of the RTSP URI are opaque to the client and do
   not imply any particular file system structure for the server.
      This decoupling also allows presentation descriptions to be used
      with non-RTSP media control protocols simply by replacing the
      scheme in the URI.
4.3.  Session Identifiers
   Session identifiers are strings of a length between 8-128 characters.
   A session identifier MUST be generated using methods that make it
   cryptographically random (see [RFC4086]).  It is RECOMMENDED that a
   session identifier contain 128 bits of entropy, i.e., approximately
   22 characters from a high-quality generator (see Section 21).
   However, note that the session identifier does not provide any
   security against session hijacking unless it is kept confidential by
   the client, server, and trusted proxies.
4.4.  Media-Time Formats
   RTSP currently supports three different media-time formats defined
   below.  Additional time formats may be specified in the future.
   These time formats can be used with the Range header (Section 18.40)
   to request playback and specify at which media position protocol
   requests actually will or have taken place.  They are also used in
   description of the media's properties using the Media-Range header
   (Section 18.30).  The unqualified format identifier is used on its
   own in Accept-Ranges header (Section 18.5) to declare supported time
   formats and also in the Range header (Section 18.40) to request the
   time format used in the response.
4.4.1.  SMPTE-Relative Timestamps
   A timestamp may use a format derived from a Society of Motion Picture
   and Television Engineers (SMPTE) specification and expresses time
   offsets anchored at the start of the media clip.  Relative timestamps
   are expressed as SMPTE time codes [SMPTE-TC] for frame-level access
   accuracy.  The time code has the format:
      hours:minutes:seconds:frames.subframes
   with the origin at the start of the clip.  The default SMPTE format
   is "SMPTE 30 drop" format, with a frame rate of 29.97 frames per
   second.  Other SMPTE codes MAY be supported (such as "SMPTE 25")
   through the use of "smpte-type".  For SMPTE 30, the "frames" field in
   the time value can assume the values 0 through 29.  The difference
   between 30 and 29.97 frames per second is handled by dropping the
   first two frame indices (values 00 and 01) of every minute, except
   every tenth minute.  If the frame and the subframe values are zero,
   they may be omitted.  Subframes are measured in hundredths of a
   frame.
   Examples:
     smpte=10:12:33:20-
     smpte=10:07:33-
     smpte=10:07:00-10:07:33:05.01
     smpte-25=10:07:00-10:07:33:05.01
4.4.2.  Normal Play Time
   Normal Play Time (NPT) indicates the stream-absolute position
   relative to the beginning of the presentation.  The timestamp
   consists of two parts: The mandatory first part may be expressed in
   either seconds only or in hours, minutes, and seconds.  The optional
   second part consists of a decimal point and decimal figures and
   indicates fractions of a second.
   The beginning of a presentation corresponds to 0.0 seconds.  Negative
   values are not defined.
   The special constant "now" is defined as the current instant of a
   live event.  It MAY only be used for live events and MUST NOT be used
   for on-demand (i.e., non-live) content.
   NPT is defined as in Digital Storage Media Command and Control
   (DSMb;CC) [ISO.13818-6.1995]:
      Intuitively, NPT is the clock the viewer associates with a
      program.  It is often digitally displayed on a DVD player.  NPT
      advances normally when in normal play mode (scale = 1), advances
      at a faster rate when in fast-scan forward (high positive scale
      ratio), decrements when in scan reverse (negative scale ratio) and
      is fixed in pause mode.  NPT is (logically) equivalent to SMPTE
      time codes.
   Examples:
     npt=123.45-125
     npt=12:05:35.3-
     npt=now-
   The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the
   time elapsed since presentation start, with two different notations
   allowed:
   o  The npt-hhmmss notation uses an ISO 8601 extended complete
      representation of the time of the day format (Section 5.3.1.1 of
      [ISO.8601.2000] ) using colons (":") as separators between hours,
      minutes, and seconds (hh:mm:ss).  The hour counter is not limited
      to 0-24 hours; up to nineteen (19) hour digits are allowed.
      *  In accordance with the requirements of the ISO 8601 time
         format, the hours, minutes, and seconds MUST all be present,
         with two digits used for minutes and for seconds and with at
         least two digits for hours.  An NPT of 7 minutes and 0 seconds
         is represented as "00:07:00", and an NPT of 392 hours, 0
         minutes, and 6 seconds is represented as "392:00:06".
      *  RTSP 1.0 allowed NPT in the npt-hhmmss notation without any
         leading zeros to ensure that implementations don't fail; for
         backward compatibility, all RTSP 2.0 implementations are
         REQUIRED to support receiving NPT values, hours, minutes, or
         seconds, without leading zeros.
   o  The npt-sec notation expresses the time in seconds, using between
      one and nineteen (19) digits.
   Both notations allow decimal fractions of seconds as specified in
   Section 5.3.1.3 of [ISO.8601.2000], using at most nine digits, and
   allowing only "." (full stop) as the decimal separator.
   The npt-sec notation is optimized for automatic generation; the npt-
   hhmmss notation is optimized for consumption by human readers.  The
   "now" constant allows clients to request to receive the live feed
   rather than the stored or time-delayed version.  This is needed since
   neither absolute time nor zero time are appropriate for this case.
4.4.3.  Absolute Time
   Absolute time is expressed using a timestamp based on ISO 8601
   [ISO.8601.2000].  The date is a complete representation of the
   calendar date in basic format (YYYYMMDD) without separators (per
   Section 5.2.1.1 of [ISO.8601.2000]).  The time of day is provided in
   the complete representation basic format (hhmmss) as specified in
   Section 5.3.1.1 of [ISO.8601.2000], allowing decimal fractions of
   seconds following Section 5.3.1.3 requiring "." (full stop) as
   decimal separator and limiting the number of digits to no more than
   nine.  The time expressed MUST use UTC (GMT), i.e., no time zone
   offsets are allowed.  The full date and time specification is the
   eight-digit date followed by a "T" followed by the six-digit time
   value, optionally followed by a full stop followed by one to nine
   fractions of a second and ended by "Z", e.g., YYYYMMDDThhmmss.ssZ.
      The reasons for this time format rather than using "Date and Time
      on the Internet: Timestamps" [RFC3339] are historic.  We continue
      to use the format specified in RTSP 1.0.  The motivations raised
      in RFC 3339 apply to why a selection from ISO 8601 was made;
      however, a different and even more restrictive selection was
      applied in this case.
   Below are three examples of media time formats, first, a request for
   a clock format range request for a starting time of November 8, 1996
   at 14 h 37 min and 20 1/4 seconds UTC playing for 10 min and 5
   seconds, followed by a Media-Properties header's "Time-Limited" UTC
   property for the 24th of December 2014 at 15 hours and 00 minutes,
   and finally a Terminate-Reason header "time" property for the 18th of
   June 2013 at 16 hours, 12 minutes, and 56 seconds:
     clock=19961108T143720.25Z-19961108T144725.25Z
     Time-Limited=20141224T1500Z
     time=20130618T161256Z
4.5.  Feature Tags
   Feature tags are unique identifiers used to designate features in
   RTSP.  These tags are used in Require (Section 18.43), Proxy-Require
   (Section 18.37), Proxy-Supported (Section 18.38), Supported
   (Section 18.51), and Unsupported (Section 18.55) header fields.
   A feature tag definition MUST indicate which combination of clients,
   servers, or proxies to which it applies.
   The creator of a new RTSP feature tag should either prefix the
   feature tag with a reverse domain name (e.g.,
   "com.example.mynewfeature" is an apt name for a feature whose
   inventor can be reached at "example.com") or register the new feature
   tag with the Internet Assigned Numbers Authority (IANA).  (See
   Section 22, "IANA Considerations".)
   The usage of feature tags is further described in Section 11, which
   deals with capability handling.
4.6.  Message Body Tags
   Message body tags are opaque strings that are used to compare two
   message bodies from the same resource, for example, in caches or to
   optimize setup after a redirect.  Message body tags can be carried in
   the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9).
   MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]).
   A message body tag MUST be unique across all versions of all message
   bodies associated with a particular resource.  A given message body
   tag value MAY be used for message bodies obtained by requests on
   different URIs.  The use of the same message body tag value in
   conjunction with message bodies obtained by requests on different
   URIs does not imply the equivalence of those message bodies.
   Message body tags are used in RTSP to make some methods conditional.
   The methods are made conditional through the inclusion of headers;
   see Section 18.24 and Section 18.26 for information on the If-Match
   and If-None-Match headers, respectively.  Note that RTSP message body
   tags apply to the complete presentation, i.e., both the presentation
   description and the individual media streams.  Thus, message body
   tags can be used to verify at setup time after a redirect that the
   same session description applies to the media at the new location
   using the If-Match header.
4.7.  Media Properties
   When an RTSP server handles media, it is important to consider the
   different properties a media instance for delivery and playback can
   have.  This specification considers the media properties listed below
   in its protocol operations.  They are derived from the differences
   between a number of supported usages.
   On-demand:  Media that has a fixed (given) duration that doesn't
      change during the lifetime of the RTSP session and is known at the
      time of the creation of the session.  It is expected that the
      content of the media will not change, even if the representation,
      such as encoding, or quality, may change.  Generally, one can
      seek, i.e., request any range, within the media.
   Dynamic On-demand:  This is a variation of the on-demand case where
      external methods are used to manipulate the actual content of the
      media setup for the RTSP session.  The main example is content
      defined by a playlist.
   Live:  Live media represents a progressing content stream (such as
      broadcast TV) where the duration may or may not be known.  It is
      not seekable, only the content presently being delivered can be
      accessed.
   Live with Recording:  A live stream that is combined with a server-
      side capability to store and retain the content of the live
      session and allow for random access delivery within the part of
      the already-recorded content.  The actual behavior of the media
      stream is very much dependent on the retention policy for the
      media stream; either the server will be able to capture the
      complete media stream or it will have a limitation in how much
      will be retained.  The media range will dynamically change as the
      session progress.  For servers with a limited amount of storage
      available for recording, there will typically be a sliding window
      that moves forward while new data is made available and older data
      is discarded.
   To cover the above usages, the following media properties with
   appropriate values are specified.
4.7.1.  Random Access and Seeking
   Random access is the ability to specify and get media delivered
   starting from any time (instant) within the content, an operation
   called "seeking".  The Media-Properties header will indicate the
   general capability for a media resource to perform random access.
   Random-Access:  The media is seekable to any out of a large number of
      points within the media.  Due to media-encoding limitations, a
      particular point may not be reachable, but seeking to a point
      close by is enabled.  A floating-point number of seconds may be
      provided to express the worst-case distance between random access
      points.
   Beginning-Only:  Seeking is only possible to the beginning of the
      content.
   No-Seeking:  Seeking is not possible at all.
   If random access is possible, as indicated by the Media-Properties
   header, the actual behavior policy when seeking can be controlled
   using the Seek-Style header (Section 18.47).
4.7.2.  Retention
   The following retention policies are used by media to limit possible
   protocol operations:
   Unlimited:  The media will not be removed as long as the RTSP session
      is in existence.
   Time-Limited:  The media will not be removed before the given
      wallclock time.  After that time, it may or may not be available
      anymore.
   Time-Duration:  The media (on fragment or unit basis) will be
      retained for the specified duration.
4.7.3.  Content Modifications
   The media content and its timeline can be of different types, e.g.
   pre-produced content on demand, a live source that is being generated
   as time progresses, or something that is dynamically altered or
   recomposed during playback.  Therefore, a media property for content
   modifications is needed and the following initial values are defined:
   Immutable:  The content of the media will not change, even if the
      representation, such as encoding or quality changes.
   Dynamic:  The content can change due to external methods or triggers,
      such as playlists, but this will be announced by explicit updates.
   Time-Progressing:  As time progresses, new content will become
      available.  If the content is also retained, it will become longer
      as everything between the start point and the point currently
      being made available can be accessed.  If the media server uses a
      sliding-window policy for retention, the start point will also
      change as time progresses.
4.7.4.  Supported Scale Factors
   A particular media content item often supports only a limited set or
   range of scales when delivering the media.  To enable the client to
   know what values or ranges of scale operations that the whole content
   or the current position supports, a media properties attribute for
   this is defined that contains a list with the values or ranges that
   are supported.  The attribute is named "Scales".  The "Scales"
   attribute may be updated at any point in the content due to content
   consisting of spliced pieces or content being dynamically updated by
   out-of-band mechanisms.
4.7.5.  Mapping to the Attributes
   This section shows examples of how one would map the above usages to
   the properties and their values.
   Example of On-Demand:
      Random Access: Random-Access=5.0, Content Modifications:
      Immutable, Retention: Unlimited or Time-Limited.
   Example of Dynamic On-Demand:
      Random Access: Random-Access=3.0, Content Modifications: Dynamic,
      Retention: Unlimited or Time-Limited.
   Example of Live:
      Random Access: No-Seeking, Content Modifications: Time-
      Progressing, Retention: Time-Duration=0.0
   Example of Live with Recording:
      Random Access: Random-Access=3.0, Content Modifications: Time-
      Progressing, Retention: Time-Duration=7200.0