Section Appendix C. Media-Transport Alternatives

This section defines how certain combinations of protocols, profiles,
   and lower transports are used.  This includes the usage of the
   Transport header's source and destination address parameters:
   "src_addr" and "dest_addr".
C.1.  RTP
   This section defines the interaction of RTSP with respect to the RTP
   protocol [RFC3550].  It also defines any necessary media-transport
   signaling with regard to RTP.
   The available RTP profiles and lower-layer transports are described
   below along with rules on signaling the available combinations.
C.1.1.  AVP
   The usage of the "RTP Profile for Audio and Video Conferences with
   Minimal Control" [RFC3551] when using RTP for media transport over
   different lower-layer transport protocols is defined below in regard
   to RTSP.
   One such case is defined within this document: the use of embedded
   (interleaved) binary data as defined in Section 14.  The usage of
   this method is indicated by including the "interleaved" parameter.
   When using embedded binary data, "src_addr" and "dest_addr" MUST NOT
   be used.  This addressing and multiplexing is used as defined with
   use of channel numbers and the interleaved parameter.
C.1.2.  AVP/UDP
   This part describes the sending of RTP [RFC3550] over lower-
   transport-layer UDP [RFC768] according to the profile "RTP Profile
   for Audio and Video Conferences with Minimal Control" defined in
   [RFC3551].  Implementations of RTP/AVP/UDP MUST implement RTCP
   (Appendix C.1.6).  This profile requires one or two unidirectional or
   bidirectional UDP flows per media stream.  The first UDP flow is for
   RTP and the second is for RTCP.  Multiplexing of RTP and RTCP
   (Appendix C.1.6.4) MAY be used, in which case, a single UDP flow is
   used for both parts.  Embedding of RTP data with the RTSP messages,
   in accordance with Section 14, SHOULD NOT be performed when RTSP
   messages are transported over unreliable transport protocols, like
   UDP [RFC768].
   The RTP/UDP and RTCP/UDP flows can be established using the Transport
   header's "src_addr" and "dest_addr" parameters.
   In RTSP PLAY mode, the transmission of RTP packets from client to
   server is unspecified.  The behavior in regard to such RTP packets
   MAY be defined in future.
   The "src_addr" and "dest_addr" parameters are used in the following
   way for media delivery and playback mode, i.e., Mode=PLAY:
   o  The "src_addr" and "dest_addr" parameters MUST contain either 1 or
      2 address specifications.  Note that two address specifications
      MAY be provided even if RTP and RTCP multiplexing is negotiated.
   o  Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST
      contain either:
      *  both an address and a port number, or
      *  a port number without an address.
   o  The first address specification given in either of the parameters
      applies to the RTP stream.  The second specification, if present,
      applies to the RTCP stream, unless in the case RTP and RTCP
      multiplexing is negotiated where both RTP and RTCP will use the
      first specification.
   o  The RTP/UDP packets from the server to the client MUST be sent to
      the address and port given by the first address specification of
      the "dest_addr" parameter.
   o  The RTCP/UDP packets from the server to the client MUST be sent to
      the address and port given by the second address specification of
      the "dest_addr" parameter, unless RTP and RTCP multiplexing has
      been negotiated, in which case RTCP MUST be sent to the first
      address specification.  If no second pair is specified and RTP and
      RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
   o  The RTCP/UDP packets from the client to the server MUST be sent to
      the address and port given by the second address specification of
      the "src_addr" parameter, unless RTP and RTCP multiplexing has
      been negotiated, in which case RTCP MUST be sent to the first
      address specification.  If no second pair is specified and RTP and
      RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
   o  The RTP/UDP packets from the client to the server MUST be sent to
      the address and port given by the first address specification of
      the "src_addr" parameter.
   o  RTP and RTCP packets SHOULD be sent from the corresponding
      receiver port, i.e., RTCP packets from the server should be sent
      from the "src_addr" parameters second address port pair, unless
      RTP and RTCP multiplexing has been negotiated in which case the
      first address port pair is used.
C.1.3.  AVPF/UDP
   The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/
   AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP.
   All that is defined for AVP MUST also apply for AVPF.
   The usage of AVPF is indicated by the media initialization protocol
   used.  In the case of SDP, it is indicated by media lines ("m=")
   containing the profile RTP/AVPF.  That SDP MAY also contain further
   AVPF-related SDP attributes configuring the AVPF session regarding
   reporting interval and feedback messages to be used [RFC4585].  This
   configuration MUST be followed.
C.1.4.  SAVP/UDP
   The RTP profile "The Secure Real-time Transport Protocol (SRTP)"
   [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions
   using RTP.  All that is defined for AVP MUST also apply for SAVP.
   The usage of SRTP requires that a security context be established.
   The default key-management unless otherwise signaled SHALL be MIKEY
   in RSA-R mode as defined in Appendix C.1.4.1 and not according to the
   procedure defined in "Key Management Extensions for Session
   Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)"
   [RFC4567].  The reason is that RFC 4567 sends the initial MIKEY
   message in SDP, thus, both requiring the usage of the DESCRIBE method
   and forcing the server to keep state for clients performing DESCRIBE
   in anticipation that they might require key management.
   MIKEY is selected as the default method for establishing SRTP
   cryptographic context within an RTSP session as it can be embedded in
   the RTSP messages while still ensuring confidentiality of content of
   the keying material, even when using hop-by-hop TLS security for the
   RTSP messages.  This method also supports pipelining of the RTSP
   messages.
C.1.4.1.  MIKEY Key Establishment
   This method for using MIKEY [RFC3830] to establish the SRTP
   cryptographic context is initiated in the client's SETUP request, and
   the server's response to the SETUP carries the MIKEY response.  This
   ensures that the crypto context establishment happens simultaneously
   with the establishment of the media stream being protected.  By using
   MIKEY's RSA-R mode [RFC4738] the client can be the initiator and
   still allow the server to set the parameters in accordance with the
   actual media stream.
   The SRTP cryptographic context establishment is done according to the
   following process:
   1.   The client determines that SAVP or SAVPF shall be used from the
        media-description format, e.g., SDP.  If no other key-management
        method is explicitly signaled, then MIKEY SHALL be used as
        defined herein.  The use of SRTP with RTSP is only defined with
        MIKEY with keys established as defined in this section.  Future
        documents may define how an RTSP implementation treats SDP that
        indicates some other key mechanism to be used.  The need for
        such specification includes [RFC4567], which is not defined for
        use in RTSP 2.0 within this document.
   2.   The client SHALL establish a TLS connection for RTSP messages,
        directly or hop-by-hop with the server.  If hop-by-hop TLS
        security is used, the User method SHALL be indicated in the
        Accept-Credentials header.  Note that using hop-by-hop does
        allow the proxy to insert itself as a man in the middle.  This
        can also occur in the MIKEY exchange by the proxy providing one
        of its certificates rather than the server's in the Connection-
        Credentials header.  Therefore, the client SHALL validate the
        server certificate.
   3.   The client retrieves the server's certificate from a direct TLS
        connection or hop-by-hop from a Connection-Credentials header.
        The client then checks that the server certificate is valid and
        belongs to the server.
   4.   The client forms the MIKEY Initiator message using RSA-R mode in
        unicast mode as specified in [RFC4738].  The client SHOULD use
        the same certificate for TLS and MIKEY to enable the server to
        bind the two together.  The client's certificate SHALL be
        included in the MIKEY message.  The client SHALL indicate its
        SRTP capabilities in the message.
   5.   The MIKEY message from the previous step is base64-encoded
        [RFC4648] and becomes the value of the MIKEY parameter that is
        included in the transport specification(s) that specifies an
        SRTP-based profile (SAVP, SAVPF) in the SETUP request.
   6.   Any proxy encountering the MIKEY parameter SHALL forward it
        without modification.  A proxy that is required to understand
        the Transport specifications will need to understand SAVP/SAVPF
        with MIKEY to enable the default keying for SRTP-protected media
        streams.  If such a proxy does not support SAVP/SAVPF with
        MIKEY, it will discard the whole transport specification.  Most
        types of proxies can easily support SAVP and SAVPF with MIKEY.
        If a client encounters a proxy not supporting SAVP/SAVPF with
        MIKEY, the client should attempt bypassing that proxy.
   7.   The server, upon receiving the SETUP request, will need to
        decide upon the transport specification to use, if multiple are
        included by the client.  In the determination of which transport
        specifications are supported and preferred, the server SHOULD
        decode the MIKEY message to take the embedded SRTP parameters
        into account.  If all transport spec require SRTP but no MIKEY
        parameter or other supported keying method is included, the
        server SHALL respond with 403 (Forbidden).
   8.   Upon generating a response, the following outcomes can occur:
        *  A transport spec not using SRTP and MIKEY is selected.  Thus,
           the response will not contain any MIKEY parameters.
        *  A transport spec using SRTP and MIKEY is selected but an
           error is encountered in the MIKEY processing.  In this case,
           an RTSP error response code of 466 (Key Management Error)
           SHALL be used.  A MIKEY message describing the error MAY be
           included.
        *  A transport spec using SRTP and MIKEY is selected and a MIKEY
           response message can be created.  The server SHOULD use the
           same certificate for TLS and in MIKEY to enable the client to
           bind the two together.  If a different certificate is used,
           it SHALL be included in the MIKEY message.  It is RECOMMENDED
           that the envelope key-cache type be set to 'Cache' and that a
           single envelope key is reused for all MIKEY messages to the
           client.  That message is included in the MIKEY parameter part
           of the single selected transport specification in the SETUP
           response.  The server will set the SRTP parameters as
           preferred for this media stream within the supported range by
           the client.
   9.   The server transmits the SETUP response back to the client.
   10.  The client receives the SETUP response and, if the response code
        indicates a successful request, it decodes the MIKEY message and
        establishes the SRTP cryptographic context from the parameters
        in the MIKEY response.
   In the above method, the client's certificate may be self signed in
   cases where the client's identity is not necessary to authenticate
   and the security goal is only to ensure that the RTSP signaling
   client is the same as the one receiving the SRTP security context.
C.1.5.  SAVPF/UDP
   The RTP profile "Extended Secure RTP Profile for Real-time Transport
   Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is an
   RTP profile (SAVPF) that MAY be used in RTSP sessions using RTP.  All
   that is defined for AVPF MUST also apply for SAVPF.
   The usage of SRTP requires that a cryptographic context be
   established.  The default mechanism for establishing that security
   association is to use MIKEY[RFC3830] with RTSP as defined in
   Appendix C.1.4.1.
C.1.6.  RTCP Usage with RTSP
   RTCP has several usages when RTP is implemented for media transport
   as explained below.  Thus, RTCP MUST be supported if an RTSP agent
   handles RTP.
C.1.6.1.  Media Synchronization
   RTCP provides media synchronization and clock-drift compensation.
   The initial media synchronization is available from RTP-Info header.
   However, to be able to handle any clock drift between the media
   streams, RTCP is needed.
C.1.6.2.  RTSP Session Keep-Alive
   RTCP traffic from the RTSP client to the RTSP server MUST function as
   keep-alive.  This requires an RTSP server supporting RTP to use the
   received RTCP packets as indications that the client desires the
   related RTSP session to be kept alive.
C.1.6.3.  Bitrate Adaption
   RTCP Receiver reports and any additional feedback from the client
   MUST be used to adapt the bitrate used over the transport for all
   cases when RTP is sent over UDP.  An RTP sender without reserved
   resources MUST NOT use more than its fair share of the available
   resources.  This can be determined by comparing on short-to-medium
   terms (some seconds) the used bitrate and adapting it so that the RTP
   sender sends at a bitrate comparable to what a TCP sender would
   achieve on average over the same path.
   To ensure that the implementation's adaptation mechanism has a well-
   defined outer envelope, all implementations using a non-congestion-
   controlled unicast transport protocol, like UDP, MUST implement
   "Multimedia Congestion Control: Circuit Breakers for Unicast RTP
   Sessions" [RTP-CIRCUIT-BREAKERS].
C.1.6.4.  RTP and RTCP Multiplexing
   RTSP can be used to negotiate the usage of RTP and RTCP multiplexing
   as described in [RFC5761].  This allows servers and client to reduce
   the amount of resources required for the session by only requiring
   one underlying transport stream per media stream instead of two when
   using RTP and RTCP.  This lessens the server-port consumption and
   also the necessary state and keep-alive work when operating across
   NATs [RFC2663].
   Content must be prepared with some consideration for RTP and RTCP
   multiplexing, mainly ensuring that the RTP payload types used do not
   collide with the ones used for RTCP packet types.  This option likely
   needs explicit support from the content unless the RTP payload types
   can be remapped by the server and that is correctly reflected in the
   session description.  Beyond that, support of this feature should
   come at little cost and much gain.
   It is recommended that, if the content and server support RTP and
   RTCP multiplexing, this is indicated in the session description, for
   example, using the SDP attribute "a=rtcp-mux".  If the SDP message
   contains the "a=rtcp-mux" attribute for a media stream, the server
   MUST support RTP and RTCP multiplexing.  If indicated or otherwise
   desired by the client, it can include the Transport parameter "RTCP-
   mux" in any transport specification where it desires to use "RTCP-
   mux".  The server will indicate if it supports "RTCP-mux".  Servers
   and Clients SHOULD support RTP and RTCP multiplexing.
   For capability exchange, an RTSP feature tag for RTP and RTCP
   multiplexing is defined: "setup.rtp.rtcp.mux".
   To minimize the risk of negotiation failure while using RTP and RTCP
   multiplexing, some recommendations are here provided.  If the session
   description includes explicit indication of support ("a=rtcp-mux" in
   SDP), then an RTSP agent can safely create a SETUP request with a
   transport specification with only a single "dest_addr" parameter
   address specification.  If no such explicit indication is provided,
   then even if the feature tag "setup.rtp.rtcp.mux" is provided in a
   Supported header by the RTSP server or the feature tag included in
   the Required header in the SETUP request, the media resource may not
   support RTP and RTCP multiplexing.  Thus, to maximize the probability
   of successful negotiation, the RTSP agent is recommended to include
   two "dest_addr" parameter address specifications in the first or
   first set (if pipelining is used) of SETUP request(s) for any media
   resource aggregate.  That way, the RTSP server can accept RTP and
   RTCP multiplexing and only use the first address specification or, if
   not, use both specifications.  The RTSP agent, after having received
   the response for a successful negotiation of the usage of RTP and
   RTCP multiplexing, can then release the resources associated with the
   second address specification.
C.2.  RTP over TCP
   Transport of RTP over TCP can be done in two ways: over independent
   TCP connections using [RFC4571] or interleaved in the RTSP
   connection.  In both cases, the protocol MUST be "rtp" and the lower-
   layer MUST be TCP.  The profile may be any of the above specified
   ones: AVP, AVPF, SAVP, or SAVPF.
C.2.1.  Interleaved RTP over TCP
   The use of embedded (interleaved) binary data transported on the RTSP
   connection is possible as specified in Section 14.  When using this
   declared combination of interleaved binary data, the RTSP messages
   MUST be transported over TCP.  TLS may or may not be used.  If TLS is
   used, both RTSP messages and the binary data will be protected by
   TLS.
   One should, however, consider that this will result in all media
   streams going through any proxy.  Using independent TCP connections
   can avoid that issue.
C.2.2.  RTP over Independent TCP
   In this section, the sending of RTP [RFC3550] over lower-layer
   transport TCP [RFC793] according to "Framing Real-time Transport
   Protocol (RTP) and RTP Control Protocol (RTCP) Packets over
   Connection-Oriented Transport" [RFC4571] is described.  This section
   adapts the guidelines for using RTP over TCP within SIP/SDP [RFC4145]
   to work with RTSP.
   A client codes the support of RTP over independent TCP by specifying
   an RTP/AVP/TCP transport option without an interleaved parameter in
   the Transport line of a SETUP request.  This transport option MUST
   include the "unicast" parameter.
   If the client wishes to use RTP with RTCP, two address specifications
   need to be included in the "dest_addr" parameter.  If the client
   wishes to use RTP without RTCP, one address specification is included
   in the "dest_addr" parameter.  If the client wishes to multiplex RTP
   and RTCP on a single transport flow (see Appendix C.1.6.4), one or
   two address specifications are included in the "dest_addr" parameter
   in addition to the "RTCP-mux" transport parameter.  Two address
   specifications are allowed to facilitate successful negotiation when
   the server or content can't support RTP and RTCP multiplexing.
   Ordering rules of dest_addr ports follow the rules for RTP/AVP/UDP.
   If the client wishes to play the active role in initiating the TCP
   connection, it MAY set the setup parameter (see Section 18.54) on the
   Transport line to be "active", or it MAY omit the setup parameter, as
   active is the default.  If the client signals the active role, the
   ports in the address specifications in the "dest_addr" parameter MUST
   be set to 9 (the discard port).
   If the client wishes to play the passive role in TCP connection
   initiation, it MUST set the setup parameter on the Transport line to
   be "passive".  If the client is able to assume the active or the
   passive role, it MUST set the setup parameter on the Transport line
   to be "actpass".  In either case, the "dest_addr" parameter's address
   specification port value for RTP MUST be set to the TCP port number
   on which the client is expecting to receive the TCP connection for
   RTP, and the "dest_addr" address specification port value for RTCP
   MUST be set to the TCP port number on which the client is expecting
   to receive the TCP connection for RTCP.  In the case that the client
   wishes to multiplex RTP and RTCP on a single transport flow, the
   "RTCP-mux" parameter is included and one or two "dest_addr" parameter
   address specifications are included, as mentioned earlier in this
   section.
   Upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, if a
   server decides to accept this requested option, the 2xx reply MUST
   contain a Transport option that specifies RTP/AVP/TCP (without using
   the interleaved parameter and using the unicast parameter).  The
   "dest_addr" parameter value MUST be echoed from the parameter value
   in the client request unless the destination address (only port) was
   not provided; in which case, the server MAY include the source
   address of the RTSP TCP connection with the port number unchanged.
   In addition, the server reply MUST set the setup parameter on the
   Transport line, to indicate the role the server will play in the
   connection setup.  Permissible values are "active" (if a client set
   setup to "passive" or "actpass") and "passive" (if a client set setup
   to "active" or "actpass").
   If a server sets setup to "passive", the "src_addr" in the reply MUST
   indicate the ports on which the server is willing to receive a TCP
   connection for RTP and (if the client requested a TCP connection for
   RTCP by specifying two "dest_addr" address specifications) a TCP/
   RTCP connection.  If a server sets setup to "active", the ports
   specified in "src_addr" address specifications MUST be set to 9.  The
   server MAY use the "ssrc" parameter, following the guidance in
   Section 18.54.  The server sets only one address specification in the
   case that the client has indicated only a single address
   specification or in case RTP and RTCP multiplexing was requested and
   accepted by the server.  Port ordering for "src_addr" follows the
   rules for RTP/AVP/UDP.
   Servers MUST support taking the passive role and MAY support taking
   the active role.  Servers with a public IP address take the passive
   role, thus enabling clients behind NATs and firewalls a better chance
   of successful connect to the server by actively connecting outwards.
   Therefore, the clients are RECOMMENDED to take the active role.
   After sending (receiving) a 2xx reply for a SETUP method for a non-
   interleaved RTP/AVP/TCP media stream, the active party SHOULD
   initiate the TCP connection as soon as possible.  The client MUST NOT
   send a PLAY request prior to the establishment of all the TCP
   connections negotiated using SETUP for the session.  In case the
   server receives a PLAY request in a session that has not yet
   established all the TCP connections, it MUST respond using the 464
   (Data Transport Not Ready Yet) (Section 17.4.28) error code.
   Once the PLAY request for a media resource transported over non-
   interleaved RTP/AVP/TCP occurs, media begins to flow from server to
   client over the RTP TCP connection, and RTCP packets flow
   bidirectionally over the RTCP TCP connection.  Unless RTP and RTCP
   multiplexing has been negotiated; in which case, RTP and RTCP will
   flow over a common TCP connection.  As in the RTP/UDP case, client-
   to-server traffic on an RTP-only TCP session is unspecified by this
   memo.  The packets that travel on these connections MUST be framed
   using the protocol defined in [RFC4571], not by the framing defined
   for interleaving RTP over the RTSP connection defined in Section 14.
   A successful PAUSE request for media being transported over RTP/AVP/
   TCP pauses the flow of packets over the connections, without closing
   the connections.  A successful TEARDOWN request signals that the TCP
   connections for RTP and RTCP are to be closed by the RTSP client as
   soon as possible.
   Subsequent SETUP requests using a URI already set up in an RTSP
   session using an RTP/AVP/TCP transport specification may be ambiguous
   in the following way: does the client wish to open up a new TCP
   connection for RTP or RTCP for the URI, or does the client wish to
   continue using the existing TCP connections?  The client SHOULD use
   the "connection" parameter (defined in Section 18.54) on the
   Transport line to make its intention clear (by setting "connection"
   to "new" if new connections are needed, and by setting "connection"
   to "existing" if the existing connections are to be used).  After a
   2xx reply for a SETUP request for a new connection, parties should
   close the preexisting connections, after waiting a suitable period
   for any stray RTP or RTCP packets to arrive.
   The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that
   a security association be established.  The default mechanism for
   establishing that security association is to use MIKEY[RFC3830] with
   RTSP as defined Appendix C.1.4.1.
   Below, a rewritten version of the example "Media on Demand"
   (Appendix A.1) shows the use of RTP/AVP/TCP non-interleaved:
      C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
            CSeq: 1
            User-Agent: PhonyClient/1.2
      M->C: RTSP/2.0 200 OK
            CSeq: 1
            Server: PhonyServer/1.0
            Date: Wed, 23 Jan 2013 15:36:52 +0000
            Content-Type: application/sdp
            Content-Length: 227
            Content-Base: rtsp://example.com/twister.3gp/
            Expires: Thu, 24 Jan 2013 15:36:52 +0000
            v=0
            o=- 2890844256 2890842807 IN IP4 198.51.100.34
            s=RTSP Session
            i=An Example of RTSP Session Usage
            e=adm@example.com
            c=IN IP4 0.0.0.0
            a=control: *
            a=range:npt=00:00:00-00:10:34.10
            t=0 0
            m=audio 0 RTP/AVP 0
            a=control: trackID=1
      C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
            CSeq: 2
            User-Agent: PhonyClient/1.2
            Require: play.basic
            Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
                       setup=active;connection=new
            Accept-Ranges: npt, smpte, clock
      M->C: RTSP/2.0 200 OK
            CSeq: 2
            Server: PhonyServer/1.0
            Transport: RTP/AVP/TCP;unicast;
                       dest_addr=":9"/":9";
                       src_addr="198.51.100.5:53478"/"198.51.100:54091";
                       setup=passive;connection=new;ssrc=93CB001E
            Session: OccldOFFq23KwjYpAnBbUr
            Expires: Thu, 24 Jan 2013 15:36:52 +0000
            Date: Wed, 23 Jan 2013 15:36:52 +0000
            Accept-Ranges: npt
            Media-Properties: Random-Access=0.8, Immutable, Unlimited
      C->M: TCP Connection Establishment x2
      C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
            CSeq: 4
            User-Agent: PhonyClient/1.2
            Range: npt=30-
            Session: OccldOFFq23KwjYpAnBbUr
      M->C: RTSP/2.0 200 OK
            CSeq: 4
            Server: PhonyServer/1.0
            Date: Wed, 23 Jan 2013 15:36:54 +0000
            Session: OccldOFFq23KwjYpAnBbUr
            Range: npt=30-623.10
            Seek-Style: First-Prior
            RTP-Info:  url="rtsp://example.com/twister.3gp/trackID=1"
               ssrc=4F312DD8:seq=54321;rtptime=2876889
C.3.  Handling Media-Clock Time Jumps in the RTP Media Layer
   RTSP allows media clients to control selected, non-contiguous
   sections of media presentations, rendering those streams with an RTP
   media layer [RFC3550].  Two cases occur, the first is when a new PLAY
   request replaces an old ongoing request and the new request results
   in a jump in the media.  This should produce continuous media stream
   at the RTP layer.  A client may also immediately follow a completed
   PLAY request with a new PLAY request.  This will result in some gap
   in the media layer.  The below text will look into both cases.
   A PLAY request that replaces an ongoing PLAY request allows the media
   layer rendering the RTP stream to do so continuously without being
   affected by jumps in media-clock time.  The RTP timestamps for the
   new media range are set so that they become continuous with the
   previous media range in the previous request.  The RTP sequence
   number for the first packet in the new range will be the next
   following the last packet in the previous range, i.e., monotonically
   increasing.  The goal is to allow the media-rendering layer to work
   without interruption or reconfiguration across the jumps in media
   clock.  This should be possible in all cases of replaced PLAY
   requests for media that has random access properties.  In this case,
   care is needed to align frames or similar media-dependent structures.
   In cases where jumps in media-clock time are a result of RTSP
   signaling operations arriving after a completed PLAY operation, the
   request timing will result in that media becoming non-continuous.
   The server becomes unable to send the media so that it arrives timely
   and still carries timestamps to make the media stream continuous.  In
   these situations, the server will produce RTP streams where there are
   gaps in the RTP timeline for the media.  If the media has frame
   structure, aligning the timestamp for the next frame with the
   previous structure reduces the burden to render this media.  The gap
   should represent the time the server hasn't been serving media, e.g.,
   the time between the end of the media stream or a PAUSE request and
   the new PLAY request.  In these cases, the RTP sequence number would
   normally be monotonically increasing across the gap.
   For RTSP sessions with media that lacks random access properties,
   such as live streams, any media-clock jump is commonly the result of
   a correspondingly long pause of delivery.  The RTP timestamp will
   have increased in direct proportion to the duration of the paused
   delivery.  Note also that in this case the RTP sequence number should
   be the next packet number.  If not, the RTCP packet loss reporting
   will indicate as loss all packets not received between the point of
   pausing and later resuming.  This may trigger congestion avoidance
   mechanisms.  An allowed exception from the above recommendation on
   monotonically increasing RTP sequence number is live media streams,
   likely being relayed.  In this case, when the client resumes
   delivery, it will get the media that is currently being delivered to
   the server itself.  For this type of basic delivery of live streams
   to multiple users over unicast, individual rewriting of RTP sequence
   numbers becomes quite a burden.  For solutions that already cache
   media or perform time shifting, the rewriting should impose only a
   minor burden.
   The goal when handling jumps in media-clock time is that the provided
   stream is continuous without gaps in RTP timestamp or sequence
   number.  However, when delivery has been halted for some reason, the
   RTP timestamp, when resuming, MUST represent the duration that the
   delivery was halted.  An RTP sequence number MUST generally be the
   next number, i.e., monotonically increasing modulo 65536.  For media
   resources with the properties Time-Progressing and Time-Duration=0.0,
   the server MAY create RTP media streams with RTP sequence number
   jumps in them due to the client first halting delivery and later
   resuming it (PAUSE and then later PLAY).  However, servers utilizing
   this exception must take into consideration the resulting RTCP
   receiver reports that likely contain loss reports for all the packets
   that were a part of the discontinuity.  A client cannot rely on the
   fact that a server will align when resuming play, even if it is
   RECOMMENDED.  The RTP-Info header will provide information on how the
   server acts in each case.
      One cannot assume that the RTSP client can communicate with the
      RTP media agent, as the two may be independent processes.  If the
      RTP timestamp shows the same gap as the NPT, the media agent will
      assume that there is a pause in the presentation.  If the jump in
      NPT is large enough, the RTP timestamp may roll over and the media
      agent may believe later packets to be duplicates of packets just
      played out.  Having the RTP timestamp jump will also affect the
      RTCP measurements based on this.
   As an example, assume an RTP timestamp frequency of 8000 Hz, a
   packetization interval of 100 ms, and an initial sequence number and
   timestamp of zero.
      C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
        CSeq: 4
        Session: ymIqLXufHkMHGdtENdblWK
        Range: npt=10-15
        User-Agent: PhonyClient/1.2
      S->C: RTSP/2.0 200 OK
        CSeq: 4
        Session: ymIqLXufHkMHGdtENdblWK
        Range: npt=10-15
        RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
                  ssrc=0D12F123:seq=0;rtptime=0
   The ensuing RTP data stream is depicted below:
      S -> C: RTP packet - seq = 0,  rtptime = 0,     NPT time = 10s
      S -> C: RTP packet - seq = 1,  rtptime = 800,   NPT time = 10.1s
       . . .
      S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
   Upon the completion of the requested delivery, the server sends a
   PLAY_NOTIFY.
        S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
              CSeq: 5
              Notify-Reason: end-of-stream
              Request-Status: cseq=4 status=200 reason="OK"
              Range: npt=-15
              RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                 ssrc=0D12F123:seq=49;rtptime=39200
              Session: ymIqLXufHkMHGdtENdblWK
        C->S: RTSP/2.0 200 OK
              CSeq: 5
              User-Agent: PhonyClient/1.2
   Upon the completion of the play range, the client follows up with a
   request to PLAY from a new NPT.
   C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
         CSeq: 6
         Session: ymIqLXufHkMHGdtENdblWK
         Range: npt=18-20
         User-Agent: PhonyClient/1.2
   S->C: RTSP/2.0 200 OK
         CSeq: 6
         Session: ymIqLXufHkMHGdtENdblWK
         Range: npt=18-20
         RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=50;rtptime=40100
   The ensuing RTP data stream is depicted below:
      S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
      S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
       . . .
      S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
   In this example, first, NPT 10 through 15 are played, then the client
   requests the server to skip ahead and play NPT 18 through 20.  The
   first segment is presented as RTP packets with sequence numbers 0
   through 49 and timestamps 0 through 39,200.  The second segment
   consists of RTP packets with sequence numbers 50 through 69, with
   timestamps 40,100 through 55,200.  While there is a gap in the NPT,
   there is no gap in the sequence-number space of the RTP data stream.
   The RTP timestamp gap is present in the above example due to the time
   it takes to perform the second play request, in this case, 12.5 ms
   (100/8000).
C.4.  Handling RTP Timestamps after PAUSE
   During a PAUSE/PLAY interaction in an RTSP session, the duration of
   time for which the RTP transmission was halted MUST be reflected in
   the RTP timestamp of each RTP stream.  The duration can be calculated
   for each RTP stream as the time elapsed from when the last RTP packet
   was sent before the PAUSE request was received and when the first RTP
   packet was sent after the subsequent PLAY request was received.  The
   duration includes all latency incurred and processing time required
   to complete the request.
      RFC 3550 [RFC3550] states that: "the RTP timestamp for each unit
      [packet] would be related to the wallclock time at which the unit
      becomes current on the virtual presentation timeline".
      In order to satisfy the requirements of [RFC3550], the RTP
      timestamp space needs to increase continuously with real time.
      While this is not optimal for stored media, it is required for RTP
      and RTCP to function as intended.  Using a continuous RTP
      timestamp space allows the same timestamp model for both stored
      and live media and allows better opportunity to integrate both
      types of media under a single control.
   As an example, assume a clock frequency of 8000 Hz, a packetization
   interval of 100 ms, and an initial sequence number and timestamp of
   zero.
   C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
         CSeq: 4
         Session: ymIqLXufHkMHGdtENdblWK
         Range: npt=10-15
         User-Agent: PhonyClient/1.2
   S->C: RTSP/2.0 200 OK
         CSeq: 4
         Session: ymIqLXufHkMHGdtENdblWK
         Range: npt=10-15
         RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=0;rtptime=0
   The ensuing RTP data stream is depicted below:
      S -> C: RTP packet - seq = 0, rtptime = 0,    NPT time = 10s
      S -> C: RTP packet - seq = 1, rtptime = 800,  NPT time = 10.1s
      S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
      S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
   The client then sends a PAUSE request:
   C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
         CSeq: 5
         Session: ymIqLXufHkMHGdtENdblWK
         User-Agent: PhonyClient/1.2
   S->C: RTSP/2.0 200 OK
         CSeq: 5
         Session: ymIqLXufHkMHGdtENdblWK
         Range: npt=10.4-15
   20 seconds elapse and then the client sends a PLAY request.  In
   addition, the server requires 15 ms to process the request:
   C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
         CSeq: 6
         Session: ymIqLXufHkMHGdtENdblWK
         User-Agent: PhonyClient/1.2
   S->C: RTSP/2.0 200 OK
         CSeq: 6
         Session: ymIqLXufHkMHGdtENdblWK
         Range: npt=10.4-15
         RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=4;rtptime=164400
   The ensuing RTP data stream is depicted below:
      S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
      S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
      S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
   First, NPT 10 through 10.3 is played, then a PAUSE is received by the
   server.  After 20 seconds, a PLAY is received by the server that
   takes 15 ms to process.  The duration of time for which the session
   was paused is reflected in the RTP timestamp of the RTP packets sent
   after this PLAY request.
   A client can use the RTSP Range header and RTP-Info header to map NPT
   time of a presentation with the RTP timestamp.
   Note: in RFC 2326 [RFC2326], this matter was not clearly defined and
   was misunderstood commonly.  However, for RTSP 2.0, it is expected
   that this will be handled correctly and no exception handling will be
   required.
   Note further: it may be required to reset some of the state to ensure
   the correct media decoding and the usual jitter-buffer handling when
   issuing a PLAY request.
C.5.  RTSP/RTP Integration
   For certain data types, tight integration between the RTSP layer and
   the RTP layer will be necessary.  This by no means precludes the
   above restrictions.  Combined RTSP/RTP media clients should use the
   RTP-Info field to determine whether incoming RTP packets were sent
   before or after a seek or before or after a PAUSE.
C.6.  Scaling with RTP
   For scaling (see Section 18.46), RTP timestamps should correspond to
   the rendering timing.  For example, when playing video recorded at 30
   frames per second at a scale of two and speed (Section 18.50) of one,
   the server would drop every second frame to maintain and deliver
   video packets with the normal timestamp spacing of 3,000 per frame,
   but NPT would increase by 1/15 second for each video frame.
      Note: the above scaling puts requirements on the media codec or a
      media stream to support it.  For example, motion JPEG or other
      non-predictive video coding can easier handle the above example.
C.7.  Maintaining NPT Synchronization with RTP Timestamps
   The client can maintain a correct display of NPT by noting the RTP
   timestamp value of the first packet arriving after repositioning.
   The sequence parameter of the RTP-Info (Section 18.45) header
   provides the first sequence number of the next segment.
C.8.  Continuous Audio
   For continuous audio, the server SHOULD set the RTP marker bit at the
   beginning of serving a new PLAY request or at jumps in timeline.
   This allows the client to perform playout delay adaptation.
C.9.  Multiple Sources in an RTP Session
   Note that more than one SSRC MAY be sent in the media stream.  If it
   happens, all sources are expected to be rendered simultaneously.
C.10.  Usage of SSRCs and the RTCP BYE Message during an RTSP Session
   The RTCP BYE message indicates the end of use of a given SSRC.  If
   all sources leave an RTP session, it can, in most cases, be assumed
   to have ended.  Therefore, a client or server MUST NOT send an RTCP
   BYE message until it has finished using a SSRC.  A server SHOULD keep
   using an SSRC until the RTP session is terminated.  Prolonging the
   use of a SSRC allows the established synchronization context
   associated with that SSRC to be used to synchronize subsequent PLAY
   requests even if the PLAY response is late.
   An SSRC collision with the SSRC that transmits media does also have
   consequences, as it will normally force the media sender to change
   its SSRC in accordance with the RTP specification [RFC3550].
   However, an RTSP server may wait and see if the client changes and
   thus resolve the conflict to minimize the impact.  As media sender,
   SSRC change will result in a loss of synchronization context and
   require any receiver to wait for RTCP sender reports for all media
   requiring synchronization before being able to play out synchronized.
   Due to these reasons, a client joining a session should take care not
   to select the same SSRC(s) as the server indicates in the ssrc
   Transport header parameter.  Any SSRC signaled in the Transport
   header MUST be avoided.  A client detecting a collision prior to
   sending any RTP or RTCP messages SHALL also select a new SSRC.
C.11.  Future Additions
   It is the intention that any future protocol or profile regarding
   media delivery and lower transport should be easy to add to RTSP.
   This section provides the necessary steps that need to be met.
   The following things need to be considered when adding a new protocol
   or profile for use with RTSP:
   o  The protocol or profile needs to define a name tag representing
      it.  This tag is required to be an ABNF "token" to be possible to
      use in the Transport header specification.
   o  The useful combinations of protocol, profiles, and lower-layer
      transport for this extension need to be defined.  For each
      combination, declare the necessary parameters to use in the
      Transport header.
   o  For new media protocols, the interaction with RTSP needs to be
      addressed.  One important factor will be the media
      synchronization.  It may be necessary to have new headers similar
      to RTP info to carry this information.
   o  Discussion needs to occur regarding congestion control for media,
      especially if transport without built-in congestion control is
      used.
   See the IANA Considerations section (Section 22) for information on
   how to register new attributes.