Section Appendix E. RTSP Use Cases

This appendix describes the most important and considered use cases
   for RTSP.  They are listed in descending order of importance in
   regard to ensuring that all necessary functionality is present.  This
   specification only fully supports usage of the two first.  Also, in
   these first two cases, there are special cases or exceptions that are
   not supported without extensions, e.g., the redirection of media
   delivery to an address other than the controlling agent's (client's).
E.1.  On-Demand Playback of Stored Content
   An RTSP-capable server stores content suitable for being streamed to
   a client.  A client desiring playback of any of the stored content
   uses RTSP to set up the media transport required to deliver the
   desired content.  RTSP is then used to initiate, halt, and manipulate
   the actual transmission (playout) of the content.  RTSP is also
   required to provide the necessary description and synchronization
   information for the content.
   The above high-level description can be broken down into a number of
   functions of which RTSP needs to be capable.
   Presentation Description:  Provide initialization information about
         the presentation (content); for example, which media codecs are
         needed for the content.  Other information that is important
         includes the number of media streams the presentation contains,
         the transport protocols used for the media streams, and
         identifiers for these media streams.  This information is
         required before setup of the content is possible and to
         determine if the client is even capable of using the content.
         This information need not be sent using RTSP; other external
         protocols can be used to transmit the transport presentation
         descriptions.  Two good examples are the use of HTTP [RFC7230]
         or email to fetch or receive presentation descriptions like SDP
         [RFC4566]
   Setup:  Set up some or all of the media streams in a presentation.
         The setup itself consists of selecting the protocol for media
         transport and the necessary parameters for the protocol, like
         addresses and ports.
   Control of Transmission:  After the necessary media streams have been
         established, the client can request the server to start
         transmitting the content.  The client must be allowed to start
         or stop the transmission of the content at arbitrary times.
         The client must also be able to start the transmission at any
         point in the timeline of the presentation.
   Synchronization:  For media-transport protocols like RTP [RFC3550],
         it might be beneficial to carry synchronization information
         within RTSP.  This may be due to either the lack of inter-media
         synchronization within the protocol itself or the potential
         delay before the synchronization is established (which is the
         case for RTP when using RTCP).
   Termination:  Terminate the established contexts.
   For this use case, there are a number of assumptions about how it
   works.  These are:
   On-Demand content:  The content is stored at the server and can be
         accessed at any time during a time period when it is intended
         to be available.
   Independent sessions:  A server is capable of serving a number of
         clients simultaneously, including from the same piece of
         content at different points in that presentations timeline.
   Unicast Transport:  Content for each individual client is transmitted
         to them using unicast traffic.
   It is also possible to redirect the media traffic to a different
   destination than that of the agent controlling the traffic.  However,
   allowing this without appropriate mechanisms for checking that the
   destination approves of this allows for Distributed DoS (DDoS).
E.2.  Unicast Distribution of Live Content
   This use case is similar to the above on-demand content case (see
   Appendix E.1), the difference is the nature of the content itself.
   Live content is continuously distributed as it becomes available from
   a source; i.e., the main difference from on-demand is that one starts
   distributing content before the end of it has become available to the
   server.
   In many cases, the consumer of live content is only interested in
   consuming what actually happens "now"; i.e., very similar to
   broadcast TV.  However, in this case, it is assumed that there exists
   no broadcast or multicast channel to the users, and instead the
   server functions as a distribution node, sending the same content to
   multiple receivers, using unicast traffic between server and client.
   This unicast traffic and the transport parameters are individually
   negotiated for each receiving client.
   Another aspect of live content is that it often has a very limited
   time of availability, as it is only available for the duration of the
   event the content covers.  An example of such live content could be a
   music concert that lasts two hours and starts at a predetermined
   time.  Thus, there is a need to announce when and for how long the
   live content is available.
   In some cases, the server providing live content may be saving some
   or all of the content to allow clients to pause the stream and resume
   it from the paused point, or to "rewind" and play continuously from a
   point earlier than the live point.  Hence, this use case does not
   necessarily exclude playing from other than the live point of the
   stream, playing with scales other than 1.0, etc.
E.3.  On-Demand Playback Using Multicast
   It is possible to use RTSP to request that media be delivered to a
   multicast group.  The entity setting up the session (the controller)
   will then control when and what media is delivered to the group.
   This use case has some potential for DoS attacks by flooding a
   multicast group.  Therefore, a mechanism is needed to indicate that
   the group actually accepts the traffic from the RTSP server.
   An open issue in this use case is how one ensures that all receivers
   listening to the multicast or broadcast receives the session
   presentation configuring the receivers.  This specification has to
   rely on an external solution to solve this issue.
E.4.  Inviting an RTSP Server into a Conference
   If one has an established conference or group session, it is possible
   to have an RTSP server distribute media to the whole group.
   Transmission to the group is simplest when controlled by a single
   participant or leader of the conference.  Shared control might be
   possible, but would require further investigation and possibly
   extensions.
   This use case assumes that there exists either a multicast or a
   conference focus that redistributes media to all participants.
   This use case is intended to be able to handle the following
   scenario: a conference leader or participant (hereafter called the
   "controller") has some pre-stored content on an RTSP server that he
   wants to share with the group.  The controller sets up an RTSP
   session at the streaming server for this content and retrieves the
   session description for the content.  The destination for the media
   content is set to the shared multicast group or conference focus.
   When desired by the controller, he/she can start and stop the
   transmission of the media to the conference group.
   There are several issues with this use case that are not solved by
   this core specification for RTSP:
   DoS:  To avoid an RTSP server from being an unknowing participant in
         a DoS attack, the server needs to be able to verify the
         destination's acceptance of the media.  Such a mechanism to
         verify the approval of received media does not yet exist;
         instead, only policies can be used, which can be made to work
         in controlled environments.
   Distributing the presentation description to all participants in the
   group:
            To enable a media receiver to correctly decode the content,
            the media configuration information needs to be distributed
            reliably to all participants.  This will most likely require
            support from an external protocol.
      Passing control of the session:  If it is desired to pass control
            of the RTSP session between the participants, some support
            will be required by an external protocol to exchange state
            information and possibly floor control of who is controlling
            the RTSP session.
E.5.  Live Content Using Multicast
   This use case in its simplest form does not require any use of RTSP
   at all; this is what multicast conferences being announced with SAP
   [RFC2974] and SDP are intended to handle.  However, in use cases
   where more advanced features like access control to the multicast
   session are desired, RTSP could be used for session establishment.
   A client desiring to join a live multicasted media session with
   cryptographic (encryption) access control could use RTSP in the
   following way.  The source of the session announces the session and
   gives all interested an RTSP URI.  The client connects to the server
   and requests the presentation description, allowing configuration for
   reception of the media.  In this step, it is possible for the client
   to use secured transport and any desired level of authentication; for
   example, for billing or access control.  An RTSP link also allows for
   load balancing between multiple servers.
   If these were the only goals, they could be achieved by simply using
   HTTP.  However, for cases where the sender likes to keep track of
   each individual receiver of a session, and possibly use the session
   as a side channel for distributing key-updates or other information
   on a per-receiver basis, and the full set of receivers is not known
   prior to the session start, the state establishment that RTSP
   provides can be beneficial.  In this case, a client would establish
   an RTSP session for this multicast group with the RTSP server.  The
   RTSP server will not transmit any media, but instead will point to
   the multicast group.  The client and server will be able to keep the
   session alive for as long as the receiver participates in the session
   thus enabling, for example, the server to push updates to the client.
   This use case will most likely not be able to be implemented without
   some extensions to the server-to-client push mechanism.  Here the
   PLAY_NOTIFY method (see Section 13.5) with a suitable extension could
   provide clear benefits.