Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7826

Real-Time Streaming Protocol Version 2.0

Pages: 318
Proposed Standard
Obsoletes:  2326
Part 4 of 13 – Pages 60 to 83
First   Prev   Next

Top   ToC   RFC7826 - Page 60   prevText

11. Capability Handling

This section describes the available capability-handling mechanism that allows RTSP to be extended. Extensions to this version of the protocol are basically done in two ways. Firstly, new headers can be added. Secondly, new methods can be added. The capability-handling mechanism is designed to handle both cases. When a method is added, the involved parties can use the OPTIONS method to discover whether it is supported. This is done by issuing an OPTIONS request to the other party. Depending on the URI, it will either apply in regard to a certain media resource, the whole server in general, or simply the next hop. The OPTIONS response MUST contain a Public header that declares all methods supported for the indicated resource. It is not necessary to use OPTIONS to discover support of a method, as the client could simply try the method. If the receiver of the request does not support the method, it will respond with an error code indicating the method is either not implemented (501) or does not apply for the resource (405). The choice between the two discovery methods depends on the requirements of the service. Feature tags are defined to handle functionality additions that are not new methods. Each feature tag represents a certain block of functionality. The amount of functionality that a feature tag represents can vary significantly. For example, a feature tag can represent the functionality a single RTSP header provides. Another feature tag can represent much more functionality, such as the "play.basic" feature tag (Section 11.1), which represents the minimal media delivery for playback implementation.
Top   ToC   RFC7826 - Page 61
   Feature tags are used to determine whether the client, server, or
   proxy supports the functionality that is necessary to achieve the
   desired service.  To determine support of a feature tag, several
   different headers can be used, each explained below:

   Supported:  This header is used to determine the complete set of
         functionality that both client and server have, in general, and
         is not dependent on a specific resource.  The intended usage is
         to determine before one needs to use a functionality that it is
         supported.  It can be used in any method, but OPTIONS is the
         most suitable as it simultaneously determines all methods that
         are implemented.  When sending a request, the requester
         declares all its capabilities by including all supported
         feature tags.  This results in the receiver learning the
         requester's feature support.  The receiver then includes its
         set of features in the response.

   Proxy-Supported:  This header is used in a similar fashion as the
         Supported header, but instead of giving the supported
         functionality of the client or server, it provides both the
         requester and the responder a view of the common functionality
         supported in general by all members of the proxy chain between
         the client and server; it does not depend on the resource.
         Proxies are required to add this header whenever the Supported
         header is present, but proxies may also add it independently of
         the requester.

   Require:  This header can be included in any request where the
         endpoint, i.e., the client or server, is required to understand
         the feature to correctly perform the request.  This can, for
         example, be a SETUP request, where the server is required to
         understand a certain parameter to be able to set up the media
         delivery correctly.  Ignoring this parameter would not have the
         desired effect and is not acceptable.  Therefore, the endpoint
         receiving a request containing a Require MUST negatively
         acknowledge any feature that it does not understand and not
         perform the request.  The response in cases where features are
         not supported is 551 (Option Not Supported).  Also, the
         features that are not supported are given in the Unsupported
         header in the response.

   Proxy-Require:  This header has the same purpose and behavior as
         Require except that it only applies to proxies and not the
         endpoint.  Features that need to be supported by both proxies
         and endpoints need to be included in both the Require and
         Proxy-Require header.
Top   ToC   RFC7826 - Page 62
   Unsupported:  This header is used in a 551 (Option Not Supported)
         error response, to indicate which features were not supported.
         Such a response is only the result of the usage of the Require
         or Proxy-Require headers where one or more features were not
         supported.  This information allows the requester to make the
         best of situations as it knows which features are not
         supported.

11.1. Feature Tag: play.basic

An implementation supporting all normative parts of this specification for the setup and control of playback of media uses the feature tag "play.basic" to indicate this support. The appendices (starting with letters) are not part of the functionality included in the feature tag unless the appendix is explicitly specified in a main section as being a required appendix. Note: This feature tag does not mandate any media delivery protocol, such as RTP. In RTSP 1.0, there was a minimal implementation section. However, that was not consistent with the rest of the specification. So, rather than making an attempt to explicitly enumerate the features for play.basic, this specification has to be taken as a whole and the necessary features normatively defined as being required are included.

12. Pipelining Support

Pipelining is a general method to improve performance of request/ response protocols by allowing the requesting agent to have more than one request outstanding and to send them over the same persistent connection. For RTSP, where the relative order of requests will matter, it is important to maintain the order of the requests. Because of this, the responding agent MUST process the incoming requests in their sending order. The sending order can be determined by the CSeq header and its sequence number. For TCP, the delivery order will be the same, between two agents, as the sending order. The processing of the request MUST also have been finished before processing the next request from the same agent. The responses MUST be sent in the order the requests were processed. RTSP 2.0 has extended support for pipelining beyond the capabilities in RTSP 1.0. As a major improvement, all requests involved in setting up and initiating media delivery can now be pipelined, indicated by the Pipelined-Request header (see Section 18.33). This header allows a client to request that two or more requests be processed in the same RTSP session context that the first request
Top   ToC   RFC7826 - Page 63
   creates.  In other words, a client can request that two or more media
   streams be set up and then played without needing to wait for a
   single response.  This speeds up the initial start-up time for an
   RTSP session by at least one RTT.

   If a pipelined request builds on the successful completion of one or
   more prior requests, the requester must verify that all requests were
   executed as expected.  A common example will be two SETUP requests
   and a PLAY request.  In case one of the SETUP requests fails
   unexpectedly, the PLAY request can still be successfully executed.
   However, the resulting presentation will not be as expected by the
   requesting client, as only a single media instead of two will be
   played.  In this case, the client can send a PAUSE request, correct
   the failing SETUP request, and then request it be played.

13. Method Definitions

The method indicates what is to be performed on the resource identified by the Request-URI. The method name is case sensitive. New methods may be defined in the future. Method names MUST NOT start with a $ character (decimal 36) and MUST be a token as defined by the ABNF [RFC5234] in Section 20. The methods are summarized in Table 7.
Top   ToC   RFC7826 - Page 64
    +---------------+-----------+--------+-------------+-------------+
    | method        | direction | object | Server req. | Client req. |
    +---------------+-----------+--------+-------------+-------------+
    | DESCRIBE      | C -> S    | P,S    | recommended | recommended |
    |               |           |        |             |             |
    | GET_PARAMETER | C -> S    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    |               | S -> C    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    | OPTIONS       | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    |               | S -> C    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    | PAUSE         | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    | PLAY          | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    | PLAY_NOTIFY   | S -> C    | P,S    | required    | required    |
    |               |           |        |             |             |
    | REDIRECT      | S -> C    | P,S    | optional    | required    |
    |               |           |        |             |             |
    | SETUP         | C -> S    | S      | required    | required    |
    |               |           |        |             |             |
    | SET_PARAMETER | C -> S    | P,S    | required    | optional    |
    |               |           |        |             |             |
    |               | S -> C    | P,S    | optional    | optional    |
    |               |           |        |             |             |
    | TEARDOWN      | C -> S    | P,S    | required    | required    |
    |               |           |        |             |             |
    |               | S -> C    | P      | required    | required    |
    +---------------+-----------+--------+-------------+-------------+

                     Table 7: Overview of RTSP Methods

      Note on Table 7: This table covers RTSP methods, their direction,
      and on what objects (P: presentation, S: stream) they operate.
      Further, it indicates whether a server or a client implementation
      is required (mandatory), recommended, or optional.

      Further note on Table 7: the GET_PARAMETER is optional.  For
      example, a fully functional server can be built to deliver media
      without any parameters.  However, SET_PARAMETER is required, i.e.,
      mandatory to implement for the server; this is due to its usage
      for keep-alive.  PAUSE is required because it is the only way of
      leaving the Play state without terminating the whole session.
Top   ToC   RFC7826 - Page 65
   If an RTSP agent does not support a particular method, it MUST return
   a 501 (Not Implemented) response code and the requesting RTSP agent,
   in turn, SHOULD NOT try this method again for the given agent/
   resource combination.  An RTSP proxy whose main function is to log or
   audit and not modify transport or media handling in any way MAY
   forward RTSP messages with unknown methods.  Note that the proxy
   still needs to perform the minimal required processing, like adding
   the Via header.

13.1. OPTIONS

The semantics of the RTSP OPTIONS method is similar to that of the HTTP OPTIONS method described in Section 4.3.7 of [RFC7231]. However, in RTSP, OPTIONS is bidirectional in that a client can send the request to a server and vice versa. A client MUST implement the capability to send an OPTIONS request and a server or a proxy MUST implement the capability to respond to an OPTIONS request. In addition to this "MUST-implement" functionality, clients, servers and proxies MAY provide support both for sending OPTIONS requests and for generating responses to the requests. An OPTIONS request may be issued at any time. Such a request does not modify the session state. However, it may prolong the session lifespan (see below). The URI in an OPTIONS request determines the scope of the request and the corresponding response. If the Request- URI refers to a specific media resource on a given host, the scope is limited to the set of methods supported for that media resource by the indicated RTSP agent. A Request-URI with only the host address limits the scope to the specified RTSP agent's general capabilities without regard to any specific media. If the Request-URI is an asterisk ("*"), the scope is limited to the general capabilities of the next hop (i.e., the RTSP agent in direct communication with the request sender). Regardless of the scope of the request, the Public header MUST always be included in the OPTIONS response, listing the methods that are supported by the responding RTSP agent. In addition, if the scope of the request is limited to a media resource, the Allow header MUST be included in the response to enumerate the set of methods that are allowed for that resource unless the set of methods completely matches the set in the Public header. If the given resource is not available, the RTSP agent SHOULD return an appropriate response code, such as 3rr or 4xx. The Supported header MAY be included in the request to query the set of features that are supported by the responding RTSP agent.
Top   ToC   RFC7826 - Page 66
   The OPTIONS method can be used to keep an RTSP session alive.
   However, this is not the preferred way of session keep-alive
   signaling; see Section 18.49.  An OPTIONS request intended for
   keeping alive an RTSP session MUST include the Session header with
   the associated session identifier.  Such a request SHOULD also use
   the media or the aggregated control URI as the Request-URI.

   Example:

     C->S:  OPTIONS rtsp://server.example.com RTSP/2.0
            CSeq: 1
            User-Agent: PhonyClient/1.2
            Proxy-Require: gzipped-messages
            Supported: play.basic

     S->C:  RTSP/2.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
            Supported: play.basic, setup.rtp.rtcp.mux, play.scale
            Server: PhonyServer/1.1


   Note that the "gzipped-messages" feature tag in the Proxy-Require is
   a fictitious feature.

13.2. DESCRIBE

The DESCRIBE method is used to retrieve the description of a presentation or media object from a server. The Request-URI of the DESCRIBE request identifies the media resource of interest. The client MAY include the Accept header in the request to list the description formats that it understands. The server MUST respond with a description of the requested resource and return the description in the message body of the response, if the DESCRIBE method request can be successfully fulfilled. The DESCRIBE reply- response pair constitutes the media initialization phase of RTSP. The DESCRIBE response SHOULD contain all media initialization information for the resource(s) that it describes. Servers SHOULD NOT use the DESCRIBE response as a means of media indirection by having the description point at another server; instead, using the 3rr responses is RECOMMENDED. By forcing a DESCRIBE response to contain all media initialization information for the set of streams that it describes, and discouraging the use of DESCRIBE for media indirection, any looping problems can be avoided that might have resulted from other approaches.
Top   ToC   RFC7826 - Page 67
   Example:

     C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
           CSeq: 312
           User-Agent: PhonyClient/1.2
           Accept: application/sdp, application/example

     S->C: RTSP/2.0 200 OK
           CSeq: 312
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer/1.1
           Content-Base: rtsp://server.example.com/fizzle/foo/
           Content-Type: application/sdp
           Content-Length: 358

           v=0
           o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.example.com/lectures/sdp.ps
           e=seminar@example.com (Seminar Management)
           c=IN IP4 0.0.0.0
           a=control:*
           t=2873397496 2873404696
           m=audio 3456 RTP/AVP 0
           a=control:audio
           m=video 2232 RTP/AVP 31
           a=control:video

   Media initialization is a requirement for any RTSP-based system, but
   the RTSP specification does not dictate that this is required to be
   done via the DESCRIBE method.  There are three ways that an RTSP
   client may receive initialization information:

   o  via an RTSP DESCRIBE request

   o  via some other protocol (HTTP, email attachment, etc.)

   o  via some form of user interface

   If a client obtains a valid description from an alternate source, the
   client MAY use this description for initialization purposes without
   issuing a DESCRIBE request for the same media.  The client should use
   any MTag to either validate the presentation description or make the
   session establishment conditional on being valid.
Top   ToC   RFC7826 - Page 68
   It is RECOMMENDED that minimal servers support the DESCRIBE method,
   and highly recommended that minimal clients support the ability to
   act as "helper applications" that accept a media initialization file
   from a user interface, or other means that are appropriate to the
   operating environment of the clients.

13.3. SETUP

The description below uses the following states in a protocol state machine that is related to a specific session when that session has been created. The state transitions are driven by protocol interactions. For additional information about the state machine, see Appendix B. Init: Initial state. No session exists. Ready: Session is ready to start playing. Play: Session is playing, i.e., sending media-stream data in the direction S->C. The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. The SETUP method may be used in two different cases, namely, creating an RTSP session and changing the transport parameters of media streams that are already set up. SETUP can be used in all three states, Init, Ready, and Play, to change the transport parameters. Additionally, Init and Ready can also be used for the creation of the RTSP session. The usage of the SETUP method in the Play state to add a media resource to the session is unspecified. The Transport header, see Section 18.54, specifies the media- transport parameters acceptable to the client for data transmission; the response will contain the transport parameters selected by the server. This allows the client to enumerate, in descending order of preference, the transport mechanisms and parameters acceptable to it, so the server can select the most appropriate. It is expected that the session description format used will enable the client to select a limited number of possible configurations that are offered as choices to the server. All transport-related parameters SHALL be included in the Transport header; the use of other headers for this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls or NATs. For the benefit of any intervening firewalls, a client MUST indicate the known transport parameters, even if it has no influence over these parameters, for example, where the server advertises a fixed- multicast address as destination.
Top   ToC   RFC7826 - Page 69
      Since SETUP includes all transport initialization information,
      firewalls and other intermediate network devices (which need this
      information) are spared the more arduous task of parsing the
      DESCRIBE response, which has been reserved for media
      initialization.

   The client MUST include the Accept-Ranges header in the request,
   indicating all supported unit formats in the Range header.  This
   allows the server to know which formats it may use in future session-
   related responses, such as a PLAY response without any range in the
   request.  If the client does not support a time format necessary for
   the presentation, the server MUST respond using 456 (Header Field Not
   Valid for Resource) and include the Accept-Ranges header with the
   range unit formats supported for the resource.

   In a SETUP response, the server MUST include the Accept-Ranges header
   (see Section 18.5) to indicate which time formats are acceptable to
   use for this media resource.

   The SETUP 200 OK response MUST include the Media-Properties header
   (see Section 18.29).  The combination of the parameters of the Media-
   Properties header indicates the nature of the content present in the
   session (see also Section 4.7).  For example, a live stream with time
   shifting is indicated by

   o  Random access set to Random-Access,

   o  Content Modifications set to Time-Progressing, and

   o  Retention set to Time-Duration (with specific recording window
      time value).

   The SETUP 200 OK response MUST include the Media-Range header (see
   Section 18.30) if the media is Time-Progressing.
Top   ToC   RFC7826 - Page 70
   A basic example for SETUP:

     C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 302
           Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
                      RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: npt, clock
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 302
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer/1.1
           Session: QKyjN8nt2WqbWw4tIYof52;timeout=60
           Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
                      "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
                      "198.51.100.241:6257"; ssrc=2A3F93ED
           Accept-Ranges: npt
           Media-Properties: Random-Access=3.2, Time-Progressing,
                             Time-Duration=3600.0
           Media-Range: npt=0-2893.23

   In the above example, the client wants to create an RTSP session
   containing the media resource "rtsp://example.com/foo/bar/baz.rm".
   The transport parameters acceptable to the client are either RTP/AVP/
   UDP (UDP per default) to be received on client port 4588 and 4589 at
   the address the RTSP setup connection comes from or RTP/AVP
   interleaved on the RTSP control channel.  The server selects the
   RTP/AVP/UDP transport and adds the address and ports it will send and
   receive RTP and RTCP from, and the RTP SSRC that will be used by the
   server.

   The server MUST generate a session identifier in response to a
   successful SETUP request unless a SETUP request to a server includes
   a session identifier or a Pipelined-Requests header referencing an
   existing session context.  In that latter case, the server MUST
   bundle this SETUP request into the existing session (aggregated
   session) or return a 459 (Aggregate Operation Not Allowed) error code
   (see Section 17.4.23).  An aggregate control URI MUST be used to
   control an aggregated session.  This URI MUST be different from the
   stream control URIs of the individual media streams included in the
   aggregate (see Section 13.4.2 for aggregated sessions and for the
   particular URIs see Appendix D.1.1).  The aggregate control URI is to
   be specified by the session description if the server supports
   aggregated control and aggregated control is desired for the session.
Top   ToC   RFC7826 - Page 71
   However, even if aggregated control is offered, the client MAY choose
   not to set up the session in aggregated control.  If an aggregate
   control URI is not specified in the session description, it is
   normally an indication that non-aggregated control should be used.

   The SETUP of media streams in an aggregate that has not been given an
   aggregated control URI is unspecified.

      While the session ID sometimes carries enough information for
      aggregate control of a session, the aggregate control URI is still
      important for some methods such as SET_PARAMETER where the control
      URI enables the resource in question to be easily identified.  The
      aggregate control URI is also useful for proxies, enabling them to
      route the request to the appropriate server, and for logging,
      where it is useful to note the actual resource on which a request
      was operating.

   A session will exist until it is either removed by a TEARDOWN request
   or is timed out by the server.  The server MAY remove a session that
   has not demonstrated liveness signs from the client(s) within a
   certain timeout period.  The default timeout value is 60 seconds; the
   server MAY set this to a different value and indicate so in the
   timeout field of the Session header in the SETUP response.  For
   further discussion, see Section 18.49.  Signs of liveness for an RTSP
   session include any RTSP requests from a client that contain a
   Session header with the ID for that session, as well as RTCP sender
   or receiver reports if RTP is used to transport the underlying media
   stream.  RTCP sender reports may, for example, be received in session
   where the server is invited into a conference session and are thus
   valid as a liveness indicator.

   If a SETUP request on a session fails for any reason, the session
   state, as well as transport and other parameters for associated
   streams, MUST remain unchanged from their values as if the SETUP
   request had never been received by the server.

13.3.1. Changing Transport Parameters

A client MAY issue a SETUP request for a stream that is already set up or playing in the session to change transport parameters, which a server MAY allow. If it does not allow the changing of parameters, it MUST respond with error 455 (Method Not Valid in This State). The reasons to support changing transport parameters include allowing application-layer mobility and flexibility to utilize the best available transport as it becomes available. If a client receives a 455 error when trying to change transport parameters while the server is in Play state, it MAY try to put the server in Ready state using PAUSE before issuing the SETUP request again. If that also fails,
Top   ToC   RFC7826 - Page 72
   the changing of transport parameters will require that the client
   perform a TEARDOWN of the affected media and then set it up again.
   For an aggregated session, not tearing down all the media at the same
   time will avoid the creation of a new session.

   All transport parameters MAY be changed.  However, the primary usage
   expected is to either change the transport protocol completely, like
   switching from Interleaved TCP mode to UDP or vice versa, or to
   change the delivery address.

   In a SETUP response for a request to change the transport parameters
   while in Play state, the server MUST include the Range header to
   indicate at what point the new transport parameters will be used.
   Further, if RTP is used for delivery, the server MUST also include
   the RTP-Info header to indicate at what timestamp and RTP sequence
   number the change will take place.  If both RTP-Info and Range are
   included in the response, the "rtp_time" parameter and start point in
   the Range header MUST be for the corresponding time, i.e., be used in
   the same way as for PLAY to ensure the correct synchronization
   information is available.

   If the transport-parameters change that happened while in Play state
   results in a change of synchronization-related information, for
   example, changing RTP SSRC, the server MUST include the necessary
   synchronization information in the SETUP response.  However, the
   server SHOULD avoid changing the synchronization information if
   possible.

13.4. PLAY

This section describes the usage of the PLAY method in general, for aggregated sessions, and in different usage scenarios.

13.4.1. General Usage

The PLAY method tells the server to start sending data via the mechanism specified in SETUP and which part of the media should be played out. PLAY requests are valid when the session is in Ready or Play state. A PLAY request MUST include a Session header to indicate to which session the request applies. Upon receipt of the PLAY request, the server MUST position the normal play time to the beginning of the range specified in the received Range header, within the limits of the media resource and in accordance with the Seek-Style header (Section 18.47). It MUST deliver stream data until the end of the range if given, until a new PLAY request is received, until a PAUSE request (Section 13.5) is received, or until the end of the media is reached. If no Range
Top   ToC   RFC7826 - Page 73
   header is present in the PLAY request, the server SHALL play from
   current pause point until the end of media.  The pause point defaults
   at session start to the beginning of the media.  For media that is
   time-progressing and has no retention, the pause point will always be
   set equal to NPT "now", i.e., the current delivery point.  The pause
   point may also be set to a particular point in the media by the PAUSE
   method; see Section 13.6.  The pause point for media that is
   currently playing is equal to the current media position.  For time-
   progressing media with time-limited retention, if the pause point
   represents a position that is older than what is retained by the
   server, the pause point will be moved to the oldest retained
   position.

   What range values are valid depends on the type of content.  For
   content that isn't time-progressing, the range value is valid if the
   given range is part of any media within the aggregate.  In other
   words, the valid media range for the aggregate is the union of all of
   the media components in the aggregate.  If a given range value points
   outside of the media, the response MUST be the 457 (Invalid Range)
   error code and include the Media-Range header (Section 18.30) with
   the valid range for the media.  Except for time-progressing content
   where the client requests a start point prior to what is retained,
   the start point is adjusted to the oldest retained content.  For a
   start point that is beyond the media front edge, i.e., beyond the
   current value for "now", the server SHALL adjust the start value to
   the current front edge.  The Range header's stop point value may
   point beyond the current media edge.  In that case, the server SHALL
   deliver media from the requested (and possibly adjusted) start point
   until the first of either the provided stop point or the end of the
   media.  Please note that if one simply wants to play from a
   particular start point until the end of media, using a Range header
   with an implicit stop point is RECOMMENDED.

   If a client requests to start playing at the end of media, either
   explicitly with a Range header or implicitly with a pause point that
   is at the end of media, a 457 (Invalid Range) error MUST be sent and
   include the Media-Range header (Section 18.30).  It is specified
   below that the Range header also must be included in the response and
   that it will carry the pause point in the media, in the case of the
   session being in Ready State.  Note that this also applies if the
   pause point or requested start point is at the beginning of the media
   and a Scale header (Section 18.46) is included with a negative value
   (playing backwards).

   For media with random access properties, a client may indicate which
   policy for start point selection the server should use.  This is done
   by including the Seek-Style header (Section 18.47) in the PLAY
Top   ToC   RFC7826 - Page 74
   request.  The Seek-Style applied will affect the content of the Range
   header as it will be adjusted to indicate from what point the media
   actually is delivered.

   A client desiring to play the media from the beginning MUST send a
   PLAY request with a Range header pointing at the beginning, e.g.,
   "npt=0-".  If a PLAY request is received without a Range header and
   media delivery has stopped at the end, the server SHOULD respond with
   a 457 (Invalid Range) error response.  In that response, the current
   pause point MUST be included in a Range header.

   All range specifiers in this specification allow for ranges with an
   implicit start point (e.g., "npt=-30").  When used in a PLAY request,
   the server treats this as a request to start or resume delivery from
   the current pause point, ending at the end time specified in the
   Range header.  If the pause point is located later than the given end
   value, a 457 (Invalid Range) response MUST be returned.

   The example below will play seconds 10 through 25.  It also requests
   that the server deliver media from the first random access point
   prior to the indicated start point.

     C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
           CSeq: 835
           Session: ULExwZCXh2pd0xuFgkgZJW
           Range: npt=10-25
           Seek-Style: RAP
           User-Agent: PhonyClient/1.2

   Servers MUST include a Range header in any PLAY response, even if no
   Range header was present in the request.  The response MUST use the
   same format as the request's Range header contained.  If no Range
   header was in the request, the format used in any previous PLAY
   request within the session SHOULD be used.  If no format has been
   indicated in a previous request, the server MAY use any time format
   supported by the media and indicated in the Accept-Ranges header in
   the SETUP request.  It is RECOMMENDED that NPT is used if supported
   by the media.

   For any error response to a PLAY request, the server's response
   depends on the current session state.  If the session is in Ready
   state, the current pause point is returned using a Range header with
   the pause point as the explicit start point and an implicit stop
   point.  For time-progressing content, where the pause-point moves
   with real-time due to limited retention, the current pause point is
   returned.  For sessions in Play state, the current playout point and
Top   ToC   RFC7826 - Page 75
   the remaining parts of the range request are returned.  For any media
   with retention longer than 0 seconds, the currently valid Media-Range
   header SHALL also be included in the response.

   A PLAY response MAY include a header carrying synchronization
   information.  As the information necessary is dependent on the media-
   transport format, further rules specifying the header and its usage
   are needed.  For RTP the RTP-Info header is specified, see
   Section 18.45, and used in the following example.

   Here is a simple example for a single audio stream where the client
   requests the media starting from 3.52 seconds and to the end.  The
   server sends a 200 OK response with the actual play time, which is 10
   ms prior (3.51), and the RTP-Info header that contains the necessary
   parameters for the RTP stack.

   C->S: PLAY rtsp://example.com/audio RTSP/2.0
         CSeq: 836
         Session: ULExwZCXh2pd0xuFgkgZJW
         Range: npt=3.52-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 836
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer/1.0
         Range: npt=3.51-324.39
         Seek-Style: First-Prior
             Session: ULExwZCXh2pd0xuFgkgZJW
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.51
         Media duration=0.16 seconds

   The server replies with the actual start point that will be
   delivered.  This may differ from the requested range if alignment of
   the requested range to valid frame boundaries is required for the
   media source.  Note that some media streams in an aggregate may need
   to be delivered from even earlier points.  Also, some media formats
   have a very long duration per individual data unit; therefore, it
   might be necessary for the client to parse the data unit, and select
   where to start.  The server SHALL also indicate which policy it uses
   for selecting the actual start point by including a Seek-Style
   header.
Top   ToC   RFC7826 - Page 76
   In the following example, the client receives the first media packet
   that stretches all the way up and past the requested playtime.  Thus,
   it is the client's decision whether to render to the user the time
   between 3.52 and 7.05 or to skip it.  In most cases, it is probably
   most suitable not to render that time period.

   C->S: PLAY rtsp://example.com/audio RTSP/2.0
         CSeq: 836
         Session: ZGGyCJOs8xaLkdNK2dmxQO
         Range: npt=7.05-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 836
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer/1.0
             Session: ZGGyCJOs8xaLkdNK2dmxQO
         Range: npt=3.52-
         Seek-Style: First-Prior
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.52
         Duration=4.15 seconds

   After playing the desired range, the presentation does NOT change to
   the Ready state, media delivery simply stops.  If it is necessary to
   put the stream into the Ready state, a PAUSE request MUST be issued.
   A PLAY request while the stream is still in the Play state is legal
   and can be issued without an intervening PAUSE request.  Such a
   request MUST replace the current PLAY action with the new one
   requested, i.e., being handled in the same way as if as the request
   was received in Ready state.  In the case that the range in the Range
   header has an implicit start time ("-endtime"), the server MUST
   continue to play from where it currently was until the specified
   endpoint.  This is useful to change the end to at another point than
   in the previous request.

   The following example plays the whole presentation starting at SMPTE
   time code 0:10:20 until the end of the clip.  Note: the RTP-Info
   headers have been broken into several lines, where subsequent lines
   start with whitespace as allowed by the syntax.
Top   ToC   RFC7826 - Page 77
   C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
         CSeq: 833
         Session: N465Wvsv0cjUy6tLqINkcf
         Range: smpte=0:10:20-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 833
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Session: N465Wvsv0cjUy6tLqINkcf
         Server: PhonyServer/1.0
         Range: smpte=0:10:22-0:15:45
         Seek-Style: Next
         RTP-Info:url="rtsp://example.com/twister.en"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   For playing back a recording of a live presentation, it may be
   desirable to use clock units:

   C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
         CSeq: 835
         Session: N465Wvsv0cjUy6tLqINkcf
         Range: clock=19961108T142300Z-19961108T143520Z
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 835
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Session: N465Wvsv0cjUy6tLqINkcf
         Server: PhonyServer/1.0
         Range: clock=19961108T142300Z-19961108T143520Z
         Seek-Style: Next
         RTP-Info:url="rtsp://example.com/meeting.en"
            ssrc=0D12F123:seq=53745;rtptime=484589019

13.4.2. Aggregated Sessions

PLAY requests can operate on sessions controlling a single media stream and on aggregated sessions controlling multiple media streams. In an aggregated session, the PLAY request MUST contain an aggregated control URI. A server MUST respond with a 460 error (Only Aggregate Operation Allowed) if the client PLAY Request-URI is for a single media. The media in an aggregate MUST be played in sync. If a client wants individual control of the media, it needs to use separate RTSP sessions for each media.
Top   ToC   RFC7826 - Page 78
   For aggregated sessions where the initial SETUP request (creating a
   session) is followed by one or more additional SETUP requests, a PLAY
   request MAY be pipelined (Section 12) after those additional SETUP
   requests without awaiting their responses.  This procedure can reduce
   the delay from the start of session establishment until media playout
   has started with one RTT.  However, a client needs to be aware that
   using this procedure will result in the playout of the server state
   established at the time of processing the PLAY, i.e., after the
   processing of all the requests prior to the PLAY request in the
   pipeline.  This state may not be the intended one due to failure of
   any of the prior requests.  A client can easily determine this based
   on the responses from those requests.  In case of failure, the client
   can halt the media playout using PAUSE and try to establish the
   intended state again before issuing another PLAY request.

13.4.3. Updating Current PLAY Requests

Clients can issue PLAY requests while the stream is in Play state and thus updating their request. The important difference compared to a PLAY request in Ready state is the handling of the current play point and how the Range header in the request is constructed. The session is actively playing media and the play point will be moving, making the exact time a request will take effect hard to predict. Depending on how the PLAY header appears, two different cases exist: total replacement or continuation. A total replacement is signaled by having the first range specification have an explicit start value, e.g., "npt=45-" or "npt=45-60", in which case the server stops playout at the current playout point and then starts delivering media according to the Range header. This is equivalent to having the client first send a PAUSE and then a new PLAY request that isn't based on the pause point. In the case of continuation, the first range specifier has an implicit start point and an explicit stop value (Z), e.g., "npt=-60", which indicate that it MUST convert the range specifier being played prior to this PLAY request (X to Y) into (X to Z) and continue as if this was the request originally played. If the current delivery point is beyond the stop point, the server SHALL immediately pause delivery. As the request has been completed successfully, it shall be responded to with a 200 OK response. A PLAY_NOTIFY with end-of-stream is also sent to indicate the actual stop point. The pause point is set to the requested stop point. The following is an example of this behavior: The server has received requests to play ranges 10 to 15. If the new PLAY request arrives at the server 4 seconds after the previous one, it will take effect
Top   ToC   RFC7826 - Page 79
   while the server still plays the first range (10-15).  The server
   changes the current play to continue to 25 seconds, i.e., the
   equivalent single request would be PLAY with "range: npt=10-25".

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=10-15
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=10-15
           Seek-Style: Next
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792482193


     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=-25
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Date: Thu, 23 Jan 1997 15:35:09 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=14-25
           Seek-Style: Next
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934239921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792842193

   A common use of a PLAY request while in Play state is changing the
   scale of the media, i.e., entering or leaving fast forward or fast
   rewind.  The client can issue an updating PLAY request that is either
   a continuation or a complete replacement, as discussed above this
   section.  Below is an example of a client that is requesting a fast
   forward (scale = 2) without giving a stop point and then a change
   from fast forward to regular playout (scale = 1).  In the second PLAY
Top   ToC   RFC7826 - Page 80
   request, the time is set explicitly to be wherever the server
   currently plays out (npt=now-) and the server responds with the
   actual playback point where the new scale actually takes effect
   (npt=02:17:27.144-).

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2034
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=now-
           Scale: 2.0
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 2034
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=02:17:21.394-
           Seek-Style: Next
           Scale: 2.0
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792482193


   [playing in fast forward and now returning to scale = 1]

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2035
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Range: npt=now-
           Scale: 1.0
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 2035
           Date: Thu, 23 Jan 1997 15:35:09 GMT
           Session: apzA8LnjQ5KWTdw0kUkiRh
           Server: PhonyServer/1.0
           Range: npt=02:17:27.144-
           Seek-Style: Next
           Scale: 1.0
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934239921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792842193
Top   ToC   RFC7826 - Page 81

13.4.4. Playing On-Demand Media

On-demand media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Immutable; o the Retention property is set to Unlimited or Time-Limited. Playing on-demand media follows the general usage as described in Section 13.4.1.

13.4.5. Playing Dynamic On-Demand Media

Dynamic on-demand media is indicated by the content of the Media- Properties header in the SETUP response when (see also Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Dynamic; o the Retention property is set to Unlimited or Time-Limited. Playing on-demand media follows the general usage as described in Section 13.4.1 as long as the media has not been changed. There are two ways for the client to be informed about changes of media resources in Play state. The first being that the client will receive a PLAY_NOTIFY request with the Notify-Reason header set to media-properties-update (see Section 13.5.2). The client can use the value of the Media-Range header to decide further actions, if the Media-Range header is present in the PLAY_NOTIFY request. The second way is that the client issues a GET_PARAMETER request without a body but including a Media-Range header. The 200 OK response MUST include the current Media-Range header (see Section 18.30).

13.4.6. Playing Live Media

Live media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29): o the Random Access property is set to No-Seeking; o the Content Modifications property is set to Time-Progressing;
Top   ToC   RFC7826 - Page 82
   o  the Retention property's Time-Duration is set to 0.0.

   For live media, the SETUP 200 OK response MUST include the Media-
   Range header (see Section 18.30).

   A client MAY send PLAY requests without the Range header.  If the
   request includes the Range header, it MUST use a symbolic value
   representing "now".  For NPT, that range specification is "npt=now-".
   The server MUST include the Range header in the response, and it MUST
   indicate an explicit time value and not a symbolic value.  In other
   words, "npt=now-" cannot be used in the response.  Instead, the time
   since session start is recommended, expressed as an open interval,
   e.g., "npt=96.23-".  An absolute time value (clock) for the
   corresponding time MAY be given, i.e., "clock=20030213T143205Z-".
   The Absolute Time format can only be used if the client has shown
   support for it using the Accept-Ranges header.

13.4.7. Playing Live with Recording

Certain media servers may offer recording services of live sessions to their clients. This recording would normally be from the beginning of the media session. Clients can randomly access the media between now and the beginning of the media session. This live media with recording is indicated by the content of the Media- Properties header in the SETUP response when (see also Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Time-Progressing; o the Retention property is set to Time-Limited or Unlimited The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) for this type of media. For live media with recording, the Range header indicates the current delivery point in the media and the Media-Range header indicates the currently available media window around the current time. This window can cover recorded content in the past (seen from current time in the media) or recorded content in the future (seen from current time in the media). The server adjusts the delivery point to the requested border of the window. If the client requests a delivery point that is located outside the recording window, e.g., if the requested point is too far in the past, the server selects the oldest point in the recording. The considerations in Section 13.5.3 apply if a client requests delivery with scale (Section 18.46) values other than 1.0 (normal playback rate) while delivering live media with recording.
Top   ToC   RFC7826 - Page 83

13.4.8. Playing Live with Time-Shift

Certain media servers may offer time-shift services to their clients. This time shift records a fixed interval in the past, i.e., a sliding window recording mechanism, but not past this interval. Clients can randomly access the media between now and the interval. This live media with recording is indicated by the content of the Media- Properties header in the SETUP response when (see also Section 18.29): o the Random Access property is set to Random-Access; o the Content Modifications property is set to Time-Progressing; o the Retention property is set to Time-Duration and a value indicating the recording interval (>0). The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) for this type of media. For live media with recording, the Range header indicates the current time in the media and the Media-Range header indicates a window around the current time. This window can cover recorded content in the past (seen from current time in the media) or recorded content in the future (seen from current time in the media). The server adjusts the play point to the requested border of the window, if the client requests a play point that is located outside the recording windows, e.g., if requested too far in the past, the server selects the oldest range in the recording. The considerations in Section 13.5.3 apply if a client requests delivery using a scale (Section 18.46) value other than 1.0 (normal playback rate) while delivering live media with time-shift.


(page 83 continued on part 5)

Next Section