Section Appendix I. Changes

This appendix briefly lists the differences between RTSP 1.0
   implementers of RTSP 2.0, it is recommended to read carefully through
   this memo and not to rely on the list of changes below to adapt from
   RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards
   mechanism.
I.1.  Brief Overview
   The following protocol elements were removed in RTSP 2.0 compared to
   RTSP 1.0:
   o  the RECORD and ANNOUNCE methods and all related functionality
      (including 201 (Created) and 250 (Low On Storage Space) status
      codes);
   o  the use of UDP for RTSP message transport (due to missing interest
      and to broken specification);
   o  the use of PLAY method for keep-alive in Play state.
   The following protocol elements were added or changed in RTSP 2.0
   compared to RTSP 1.0:
   o  RTSP session TEARDOWN from the server to the client;
   o  IPv6 support;
   o  extended IANA registries (e.g., transport headers parameters,
      transport-protocol, profile, lower-transport, and mode);
   o  request pipelining for quick session start-up;
   o  fully reworked state machine;
   o  RTSP messages now use URIs rather than URLs;
   o  incorporated much of related HTTP text ([RFC2616]) in this memo,
      compared to just referencing the sections in HTTP, to avoid
      ambiguities;
   o  the REDIRECT method was expanded and diversified for different
      situations;
   o  Includes a new section about how to set up different media-
      transport alternatives and their profiles in addition to lower-
      layer protocols.  This caused the appendix on RTP interaction to
      be moved to the new section instead of being in the part that
      describes RTP.  The section also includes guidelines what to
      consider when writing usage guidelines for new protocols and
      profiles;
   o  Added an asynchronous notification method PLAY_NOTIFY.  This
      method is used by the RTSP server to asynchronously notify clients
      about session changes while in Play state.  To a limited extent,
      this is comparable with some implementations of ANNOUNCE in RTSP
      1.0 not intended for Recording.
I.2.  Detailed List of Changes
   RTSP 2.0.  Note that this list does not reflect minor changes in
   wording or correction of typographical errors.
   o  The section on minimal implementation was deleted.  Instead, the
      main part of the specification defines the core of RTSP 2.0.
   o  The Transport header has been changed in the following ways:
      *  The ABNF has been changed to define that extensions are
         possible and that unknown parameters result in servers ignoring
         the transport specification.
      *  To prevent backwards compatibility issues, any extension or new
         parameter requires the usage of a feature tag combined with the
         Require header.
      *  Syntax ambiguities with the Mode parameter have been resolved.
      *  Syntax error with ";" for multicast and unicast has been
         resolved.
      *  Two new addressing parameters have been defined: src_addr and
         dest_addr.  These replace the parameters "port", "client_port",
         "server_port", "destination", and "source".
      *  Support for IPv6 explicit addresses in all address fields has
         been included.
      *  To handle URI definitions that contain ";" or ",", a quoted-URI
         format has been introduced and is required.
      *  IANA registries for the transport header parameters, transport-
         protocol, profile, lower-transport, and mode have been defined.
      *  The Transport header's interleaved parameter's text was made
         more strict and uses formal requirements levels.  It was also
         clarified that the interleaved channels are symmetric and that
         it is the server that sets the channel numbers.
      *  It has been clarified that the client can't request of the
         server to use a certain RTP SSRC, using a request with the
         transport parameter SSRC.
      *  Syntax definition for SSRC has been clarified to require 8HEX.
         It has also been extended to allow multiple values for clients
         supporting this version.
      *  Clarified the text on the Transport header's "dest_addr"
         parameters regarding what security precautions the server is
         required to perform.
   o  The Range formats have been changed in the following way:
      *  The NPT format has been given an initial NPT identifier that
         must now be used.
      *  All formats now support initial open-ended formats of type
         "npt=-10" and also format only "Range: smpte" ranges for usage
         with GET_PARAMETER requests.
      *  The npt-hhmmss notation now follows ISO 8601 more strictly.
   o  RTSP message handling has been changed in the following ways:
      *  RTSP messages now use URIs rather than URLs.
      *  It has been clarified that a 4xx message due to a missing CSeq
         header shall be returned without a CSeq header.
      *  The 300 (Multiple Choices) response code has been removed.
      *  Rules for how to handle the timing out RTSP messages have been
         added.
      *  Extended Pipelining rules allowing for quick session startup.
      *  Sequence numbering and proxy handling of sequence numbers have
         been defined, including cases when responses arrive out of
         order.
   o  The HTTP references have been updated to first RFCs 2616 and 2617
      and then to RFC 7230-7235.  Most of the text has been copied and
      then altered to fit RTSP into this specification.  The Public and
      the Content-Base headers have also been imported from RFC 2068 so
      that they are defined in the RTSP specification.  Known effects on
      RTSP due to HTTP clarifications:
      *  Content-Encoding header can include encoding of type
         "identity".
   o  The state machine section has been completely rewritten.  It now
      includes more details and is also more clear about the model used.
   o  An IANA section has been included that contains a number of
      registries and their rules.  This will allow us to use IANA to
      keep track of RTSP extensions.
   o  The transport of RTSP messages has seen the following changes:
      *  The use of UDP for RTSP message transport has been deprecated
         due to missing interest and to broken specification.
      *  The rules for how TCP connections are to be handled have been
         clarified.  Now it is made clear that servers should not close
         the TCP connection unless they have been unused for significant
         time.
      *  Strong recommendations why servers and clients should use
         persistent connections have also been added.
      *  There is now a requirement on the servers to handle non-
         persistent connections as this provides fault tolerance.
      *  Added wording on the usage of Connection:Close for RTSP.
      *  Specified usage of TLS for RTSP messages, including a scheme to
         approve a proxy's TLS connection to the next hop.
   o  The following header-related changes have been made:
      *  Accept-Ranges response-header has been added.  This header
         clarifies which range formats can be used for a resource.
      *  Fixed the missing definitions for the Cache-Control header.
         Also added to the syntax definition the missing delta-seconds
         for max-stale and min-fresh parameters.
      *  Put requirement on CSeq header that the value is increased by
         one for each new RTSP request.  A recommendation to start at 0
         has also been added.
      *  Added a requirement that the Date header must be used for all
         messages with a message body and the Server should always
         include it.
      *  Removed the possibility of using Range header with Scale header
         to indicate when it is to be activated, since it can't work as
         defined.  Also, added a rule that lack of Scale header in a
         response indicates lack of support for the header.  feature
         tags for scaled playback have been defined.
      *  The Speed header must now be responded to in order to indicate
         support and the actual speed going to be used.  A feature tag
         is defined.  Notes on congestion control were also added.
      *  The Supported header was borrowed from SIP [RFC3261] to help
         with the feature negotiation in RTSP.
      *  Clarified that the Timestamp header can be used to resolve
         retransmission ambiguities.
      *  The Session header text has been expanded with an explanation
         on keep-alive and which methods to use.  SET_PARAMETER is now
         recommended to use if only keep-alive within RTSP is desired.
      *  It has been clarified how the Range header formats are used to
         indicate pause points in the PAUSE response.
      *  Clarified that RTP-Info URIs that are relative use the Request-
         URI as base URI.  Also clarified that the used URI must be the
         one that was used in the SETUP request.  The URIs are now also
         required to be quoted.  The header also expresses the SSRC for
         the provided RTP timestamp and sequence number values.
      *  Added text that requires the Range to always be present in PLAY
         responses.  Clarified what should be sent in case of live
         streams.
      *  The headers table has been updated using a structure borrowed
         from SIP.  Those tables convey much more information and should
         provide a good overview of the available headers.
      *  It has been clarified that any message with a message body is
         required to have a Content-Length header.  This was the case in
         RFC 2326, but could be misinterpreted.
      *  ETag has changed its name to MTag.
      *  To resolve functionality around MTag, the MTag and If-None-
         Match header have been added from HTTP with necessary
         clarification in regard to RTSP operation.
      *  Imported the Public header from HTTP (RFC 2068 [RFC2068]) since
         it has been removed from HTTP due to lack of use.  Public is
         used quite frequently in RTSP.
      *  Clarified rules for populating the Public header so that it is
         an intersection of the capabilities of all the RTSP agents in a
         chain.
      *  Added the Media-Range header for listing the current
         availability of the media range.
      *  Added the Notify-Reason header for giving the reason when
         sending PLAY_NOTIFY requests.
      *  A new header Seek-Style has been defined to direct and inform
         how any seek operation should/have been performed.
   o  The Protocol Syntax has been changed in the following way:
      *  All ABNF definitions are updated according to the rules defined
         in RFC 5234 [RFC5234] and have been gathered in a separate
         section (Section 20).
      *  The ABNF for the User-Agent and Server headers have been
         corrected.
      *  Some definitions in the introduction regarding the RTSP session
         have been changed.
      *  The protocol has been made fully IPv6 capable.
      *  The CHAR rule has been changed to exclude NULL.
   o  The Status codes have been changed in the following ways:
      *  The use of status code 303 (See Other) has been deprecated as
         it does not make sense to use in RTSP.
      *  The never-defined status code 411 "Length Required" has been
         completely removed.
      *  When sending response 451 (Parameter Not Understood) and 458
         (Parameter Is Read-Only), the response body should contain the
         offending parameters.
      *  Clarification on when a 3rr redirect status code can be
         received has been added.  This includes receiving 3rr as a
         result of a request within an established session.  This
         provides clarification to a previous unspecified behavior.
      *  Removed the 201 (Created) and 250 (Low On Storage Space) status
         codes as they are only relevant to recording, which is
         deprecated.
      *  Several new status codes have been defined: 464 (Data Transport
         Not Ready Yet), 465 (Notification Reason Unknown), 470
         (Connection Authorization Required), 471 (Connection
         Credentials Not Accepted), and 472 (Failure to Establish Secure
         Connection).
   o  The following functionality has been deprecated from the protocol:
      *  The use of Queued Play.
      *  The use of PLAY method for keep-alive in Play state.
      *  The RECORD and ANNOUNCE methods and all related functionality.
         Some of the syntax has been removed.
      *  The possibility to use timed execution of methods with the time
         parameter in the Range header.
      *  The description on how rtspu works is not part of the core
         specification and will require external description.  Only that
         it exists is mentioned here and some requirements for the
         transport are provided.
   o  The following changes have been made in relation to methods:
      *  The OPTIONS method has been clarified with regard to the use of
         the Public and Allow headers.
      *  Added text clarifying the usage of SET_PARAMETER for keep-alive
         and usage without a body.
      *  PLAY method is now allowed to be pipelined with the pipelining
         of one or more SETUP requests following the initial that
         generates the session for aggregated control.
      *  REDIRECT has been expanded and diversified for different
         situations.
      *  Added a new method PLAY_NOTIFY.  This method is used by the
         RTSP server to asynchronously notify clients about session
         changes.
   o  Wrote a new section about how to set up different media-transport
      alternatives and their profiles as well as lower-layer protocols.
      This caused the appendix on RTP interaction to be moved to the new
      section instead of being in the part that describes RTP.  The new
      section also includes guidelines what to consider when writing
      usage guidelines for new protocols and profiles.
   o  Setup and usage of independent TCP connections for transport of
      RTP has been specified.
   o  Added a new section describing the available mechanisms to
      determine if functionality is supported, called "Capability
      Handling".  Renamed option-tags to feature tags.
   o  Added a Contributors section with people who have contributed
      actual text to the specification.
   o  Added a section "Use Cases" that describes the major use cases for
      RTSP.
   o  Clarified the usage of a=range and how to indicate live content
      that are not seekable with this header.
   o  Text specifying the special behavior of PLAY for live content.
   o  Security features of RTSP have been clarified:
      *  HTTP-based authorization has been clarified requiring both
         Basic and Digest support
      *  TLS support has been mandated
      *  If one implements RTP, then SRTP and defined MIKEY-based key-
         exchange must be supported
      *  Various minor mitigations discussed or resulted in protocol
         changes.
Acknowledgements
   This memorandum defines RTSP version 2.0, which is a revision of the
   Proposed Standard RTSP version 1.0 defined in [RFC2326].  The authors
   of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert Lanphier.
   Both RTSP version 1.0 and RTSP version 2.0 borrow format and
   descriptions from HTTP/1.1.
   Robert Sparks and especially Elwyn Davies provided very valuable and
   detailed reviews in the IETF Last Call that greatly improved the
   document and resolved many issues, especially regarding consistency.
   This document has benefited greatly from the comments of all those
   participating in the MMUSIC WG.  In addition to those already
   mentioned, the following individuals have contributed to this
   specification:
   Rahul Agarwal, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten
   Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen
   Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Spencer
   Dawkins, Kelly Djahandari, Martin Dunsmuir, Adrian Farrel, Stephen
   Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Grignon,
   Christian Groves, V.  Guruprasad, Peter Haight, Mark Handley, Brad
   Hefta-Gaub, Volker Hilt, John K.  Ho, Patrick Hoffman, Go Hori,
   Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders
   Klemets, Ruth Lang, Barry Leiba, Stephanie Leif, Jonathan Lennox,
   Eduardo F.  Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob
   McCool, Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria
   Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins,
   Pekka Pessi, Igor Plotnikov, Pete Resnick, Peter Saint-Andre, Holger
   Schmidt, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff
   Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, Geetha
   Srikantan, Scott Taylor, David Walker, Stephan Wenger, Dale R.
   Worley, and Byungjo Yoon, and especially Flemming Andreasen.
Contributors
   The following people have made written contributions that were
   included in the specification:
   o  Tom Marshall contributed text on the usage of 3rr status codes.
   o  Thomas Zheng contributed text on the usage of the Range in PLAY
      responses and proposed an earlier version of the PLAY_NOTIFY
      method.
   o  Sean Sheedy contributed text on the timeout behavior of RTSP
      messages and connections, the 463 (Destination Prohibited) status
      code, and proposed an earlier version of the PLAY_NOTIFY method.
   o  Greg Sherwood proposed an earlier version of the PLAY_NOTIFY
      method.
   o  Fredrik Lindholm contributed text about the RTSP security
      framework.
   o  John Lazzaro contributed the text for RTP over Independent TCP.
   o  Aravind Narasimhan contributed by rewriting "Media-Transport
      Alternatives" (Appendix C) and making editorial improvements on a
      number of places in the specification.
   o  Torbjorn Einarsson has done some editorial improvements of the
      text.
Authors' Addresses
   Henning Schulzrinne
   Columbia University
   1214 Amsterdam Avenue
   New York, NY  10027
   United States of America
   Email: schulzrinne@cs.columbia.edu
   Anup Rao
   Cisco
   United States of America
   Email: anrao@cisco.com
   Rob Lanphier
   San Francisco, CA
   United States of America
   Email: robla@robla.net
   Magnus Westerlund
   Ericsson
   Faeroegatan 2
   Stockholm  SE-164 80
   Sweden
   Email: magnus.westerlund@ericsson.com
   Martin Stiemerling (editor)
   University of Applied Sciences Darmstadt
   Haardtring 100
   64295 Darmstadt
   Germany
   Email: mls.ietf@gmail.com
   URI:   http://www.stiemerling.org