23.  References

23.1.  Normative References

   [FIPS180-4]
              National Institute of Standards and Technology (NIST),
              "Federal Information Processing Standards Publication:
              Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4,
              August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <http://www.rfc-editor.org/info/rfc768>.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,
              <http://www.rfc-editor.org/info/rfc2616>.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, DOI 10.17487/RFC2617, June 1999,
              <http://www.rfc-editor.org/info/rfc2617>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              DOI 10.17487/RFC3551, July 2003,
              <http://www.rfc-editor.org/info/rfc3551>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <http://www.rfc-editor.org/info/rfc3629>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              DOI 10.17487/RFC3830, August 2004,
              <http://www.rfc-editor.org/info/rfc3830>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
              January 2005, <http://www.rfc-editor.org/info/rfc3987>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <http://www.rfc-editor.org/info/rfc4086>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35, RFC
              7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfc-
              editor.org/info/rfc7595>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
              and RTP Control Protocol (RTCP) Packets over Connection-
              Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
              2006, <http://www.rfc-editor.org/info/rfc4571>.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              DOI 10.17487/RFC4585, July 2006,
              <http://www.rfc-editor.org/info/rfc4585>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [RFC4738]  Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
              RSA-R: An Additional Mode of Key Distribution in
              Multimedia Internet KEYing (MIKEY)", RFC 4738,
              DOI 10.17487/RFC4738, November 2006,
              <http://www.rfc-editor.org/info/rfc4738>.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
              2008, <http://www.rfc-editor.org/info/rfc5124>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <http://www.rfc-editor.org/info/rfc5646>.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, DOI 10.17487/RFC5751, January
              2010, <http://www.rfc-editor.org/info/rfc5751>.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761,
              DOI 10.17487/RFC5761, April 2010,
              <http://www.rfc-editor.org/info/rfc5761>.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888,
              DOI 10.17487/RFC5888, June 2010,
              <http://www.rfc-editor.org/info/rfc5888>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <http://www.rfc-editor.org/info/rfc6838>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
              DOI 10.17487/RFC7232, June 2014,
              <http://www.rfc-editor.org/info/rfc7232>.

   [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
              "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
              RFC 7233, DOI 10.17487/RFC7233, June 2014,
              <http://www.rfc-editor.org/info/rfc7233>.

   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
              RFC 7234, DOI 10.17487/RFC7234, June 2014,
              <http://www.rfc-editor.org/info/rfc7234>.

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <http://www.rfc-editor.org/info/rfc7235>.

   [RFC7615]  Reschke, J., "HTTP Authentication-Info and Proxy-
              Authentication-Info Response Header Fields", RFC 7615,
              DOI 10.17487/RFC7615, September 2015,
              <http://www.rfc-editor.org/info/rfc7615>.

   [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
              Digest Access Authentication", RFC 7616,
              DOI 10.17487/RFC7616, September 2015,
              <http://www.rfc-editor.org/info/rfc7616>.

   [RFC7617]  Reschke, J., "The 'Basic' HTTP Authentication Scheme",
              RFC 7617, DOI 10.17487/RFC7617, September 2015,
              <http://www.rfc-editor.org/info/rfc7617>.

   [RFC7825]  Goldberg, J., Westerlund, M., and T. Zeng, "A Network
              Address Translator (NAT) Traversal Mechanism for Media
              Controlled by Real-Time Streaming Protocol (RTSP)",
              RFC 7825, DOI 10.17487/RFC7825, December 2016,
              <http://www.rfc-editor.org/info/rfc7825>.

   [RTP-CIRCUIT-BREAKERS]
              Perkins, C. and V. Singh, "Multimedia Congestion Control:
              Circuit Breakers for Unicast RTP Sessions", Work in
              Progress, draft-ietf-avtcore-rtp-circuit-breakers-13,
              February 2016.

   [SMPTE-TC] Society of Motion Picture and Television Engineers, "ST
              12-1:2008 For Television -- Time and Control Code",
              DOI 10.5594/SMPTE.ST12-1.2008, February 2008,
              <http://ieeexplore.ieee.org/servlet/
              opac?punumber=7289818>.

   [TS-26234] 3rd Generation Partnership Project (3GPP), "Transparent
              end-to-end Packet-switched Streaming Service (PSS);
              Protocols and codecs", Technical Specification 26.234,
              Release 13, September 2015,
              <http://www.3gpp.org/DynaReport/26234.htm>.

23.2.  Informative References

   [ISO.13818-6.1995]
              International Organization for Standardization,
              "Information technology -- Generic coding of moving
              pictures and associated audio information - part 6:
              Extension for DSM-CC", ISO Draft Standard 13818-6:1998,
              October 1998,
              <http://www.iso.org/iso/home/store/catalogue_tc/
              catalogue_detail.htm?csnumber=25039>.

   [ISO.8601.2000]
              International Organization for Standardization, "Data
              elements and interchange formats - Information interchange
              - Representation of dates and times", ISO/IEC Standard
              8601, December 2000.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <http://www.rfc-editor.org/info/rfc791>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <http://www.rfc-editor.org/info/rfc1123>.

   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
              RFC 2068, DOI 10.17487/RFC2068, January 1997,
              <http://www.rfc-editor.org/info/rfc2068>.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326,
              DOI 10.17487/RFC2326, April 1998,
              <http://www.rfc-editor.org/info/rfc2326>.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,
              <http://www.rfc-editor.org/info/rfc2663>.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
              October 2000, <http://www.rfc-editor.org/info/rfc2974>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <http://www.rfc-editor.org/info/rfc3339>.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              DOI 10.17487/RFC4145, September 2005,
              <http://www.rfc-editor.org/info/rfc4145>.

   [RFC4567]  Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
              Carrara, "Key Management Extensions for Session
              Description Protocol (SDP) and Real Time Streaming
              Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July
              2006, <http://www.rfc-editor.org/info/rfc4567>.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              DOI 10.17487/RFC4588, July 2006,
              <http://www.rfc-editor.org/info/rfc4588>.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
              <http://www.rfc-editor.org/info/rfc4855>.

   [RFC4856]  Casner, S., "Media Type Registration of Payload Formats in
              the RTP Profile for Audio and Video Conferences",
              RFC 4856, DOI 10.17487/RFC4856, February 2007,
              <http://www.rfc-editor.org/info/rfc4856>.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
              February 2008, <http://www.rfc-editor.org/info/rfc5104>.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              DOI 10.17487/RFC5245, April 2010,
              <http://www.rfc-editor.org/info/rfc5245>.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,
              <http://www.rfc-editor.org/info/rfc5389>.

   [RFC5583]  Schierl, T. and S. Wenger, "Signaling Media Decoding
              Dependency in the Session Description Protocol (SDP)",
              RFC 5583, DOI 10.17487/RFC5583, July 2009,
              <http://www.rfc-editor.org/info/rfc5583>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <http://www.rfc-editor.org/info/rfc5905>.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,
              <http://www.rfc-editor.org/info/rfc6298>.

   [Stevens98]
              Stevens, W., Fenner, B., and A. Rudoff, "Unix Networking
              Programming, Volume 1: The Sockets Networking API (3rd
              Edition)", 1998.

Appendix A.  Examples

   This section contains several different examples trying to illustrate
   possible ways of using RTSP.  The examples can also help with the
   understanding of how functions of RTSP work.  However, remember that
   these are examples and the normative and syntax descriptions in the
   other sections take precedence.  Please also note that many of the
   examples have been broken into several lines, where following lines
   start with whitespace as allowed by the syntax.

A.1.  Media on Demand (Unicast)

   This is an example of media-on-demand streaming of media stored in a
   container file.  For the purposes of this example, a container file
   is a storage entity in which multiple continuous media types
   pertaining to the same end-user presentation are present.  In effect,
   the container file represents an RTSP presentation, with each of its
   components being RTSP-controlled media streams.  Container files are
   a widely used means to store such presentations.  While the
   components are transported as independent streams, it is desirable to
   maintain a common context for those streams at the server end.

      This enables the server to keep a single storage handle open
      easily.  It also allows treating all the streams equally in case
      of any prioritization of streams by the server.

   It is also possible that the presentation author may wish to prevent
   selective retrieval of the streams by the client in order to preserve
   the artistic effect of the combined media presentation.  Similarly,
   in such a tightly bound presentation, it is desirable to be able to
   control all the streams via a single control message using an
   aggregate URI.

   The following is an example of using a single RTSP session to control
   multiple streams.  It also illustrates the use of aggregate URIs.  In
   a container file, it is also desirable not to write any URI parts
   that are not kept when the container is distributed, like the host
   and most of the path element.  Therefore, this example also uses the
   "*" and relative URI in the delivered SDP.

   Also, this presentation description (SDP) is not cacheable, as the
   Expires header is set to an equal value with date indicating
   immediate expiration of its validity.

   Client C requests a presentation from media server M.  The movie is
   stored in a container file.  The client has obtained an RTSP URI to
   the container file.

   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: Fri, 20 Dec 2013 10:20:32 +0000
         Content-Type: application/sdp
         Content-Length: 271
         Content-Base: rtsp://example.com/twister.3gp/
         Expires: Fri, 20 Dec 2013 12:20:32 +0000

         v=0
         o=- 2890844256 2890842807 IN IP4 198.51.100.5
         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
         m=video 0 RTP/AVP 26
         a=control: trackID=4

   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;unicast;dest_addr=":8000"/":8001"
         Accept-Ranges: npt, smpte, clock

   M->C: RTSP/2.0 200 OK
         CSeq: 2
         Server: PhonyServer/1.0
         Transport: RTP/AVP;unicast; ssrc=93CB001E;
                    dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
                    src_addr="198.51.100.5:9000"/"198.51.100.5:9001"
         Session: OccldOFFq23KwjYpAnBbUr
         Expires: Fri, 20 Dec 2013 12:20:33 +0000
         Date: Fri, 20 Dec 2013 10:20:33 +0000
         Accept-Ranges: npt
         Media-Properties: Random-Access=0.02, Immutable, Unlimited

   C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Require: play.basic
         Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
         Session: OccldOFFq23KwjYpAnBbUr
         Accept-Ranges: npt, smpte, clock

   M->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/1.0
         Transport: RTP/AVP;unicast; ssrc=A813FC13;
                    dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
                    src_addr="198.51.100.5:9002"/"198.51.100.5:9003";

         Session: OccldOFFq23KwjYpAnBbUr
         Expires: Fri, 20 Dec 2013 12:20:33 +0000
         Date: Fri, 20 Dec 2013 10:20:33 +0000
         Accept-Range: NPT
         Media-Properties: Random-Access=0.8, Immutable, Unlimited

   C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
         CSeq: 4
         User-Agent: PhonyClient/1.2
         Range: npt=30-
         Seek-Style: RAP
         Session: OccldOFFq23KwjYpAnBbUr

   M->C: RTSP/2.0 200 OK
         CSeq: 4
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:20:34 +0000
         Session: OccldOFFq23KwjYpAnBbUr
         Range: npt=30-634.10
         Seek-Style: RAP
         RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
            ssrc=0D12F123:seq=12345;rtptime=3450012,
           url="rtsp://example.com/twister.3gp/trackID=1"
            ssrc=4F312DD8:seq=54321;rtptime=2876889

   C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
         CSeq: 5
         User-Agent: PhonyClient/1.2
         Session: OccldOFFq23KwjYpAnBbUr

   # Pause happens 0.87 seconds after starting to play

   M->C: RTSP/2.0 200 OK
         CSeq: 5
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:20:35 +0000
         Session: OccldOFFq23KwjYpAnBbUr
         Range: npt=30.87-634.10

   C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
         CSeq: 6
         User-Agent: PhonyClient/1.2
         Range: npt=30.87-634.10
         Seek-Style: Next
         Session: OccldOFFq23KwjYpAnBbUr

   M->C: RTSP/2.0 200 OK
         CSeq: 6
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:22:13 +0000
         Session: OccldOFFq23KwjYpAnBbUr
         Range: npt=30.87-634.10
         Seek-Style: Next
         RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
            ssrc=0D12F123:seq=12555;rtptime=6330012,
           url="rtsp://example.com/twister.3gp/trackID=1"
            ssrc=4F312DD8:seq=55021;rtptime=3132889

   C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0
         CSeq: 7
         User-Agent: PhonyClient/1.2
         Session: OccldOFFq23KwjYpAnBbUr

   M->C: RTSP/2.0 200 OK
         CSeq: 7
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:31:53 +0000

A.2.  Media on Demand Using Pipelining

   This example is basically the example above (Appendix A.1), but now
   utilizing pipelining to speed up the setup.  It requires only two
   round-trip times until the media starts flowing.  First of all, the
   session description is retrieved to determine what media resources
   need to be set up.  In the second step, one sends the necessary SETUP
   requests and the PLAY request to initiate media delivery.

   Client C requests a presentation from media server M.  The movie is
   stored in a container file.  The client has obtained an RTSP URI to
   the container file.

   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: Fri, 20 Dec 2013 10:20:32 +0000
         Content-Type: application/sdp
         Content-Length: 271
         Content-Base: rtsp://example.com/twister.3gp/
         Expires: Fri, 20 Dec 2013 12:20:32 +0000

         v=0
         o=- 2890844256 2890842807 IN IP4 192.0.2.5
         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
         m=video 0 RTP/AVP 26
         a=control: trackID=4

   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;unicast;dest_addr=":8000"/":8001"
         Accept-Ranges: npt, smpte, clock
         Pipelined-Requests: 7654

   C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Require: play.basic
         Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
         Accept-Ranges: npt, smpte, clock
         Pipelined-Requests: 7654

   C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
         CSeq: 4
         User-Agent: PhonyClient/1.2
         Range: npt=0-
         Seek-Style: RAP
         Pipelined-Requests: 7654

   M->C: RTSP/2.0 200 OK
         CSeq: 2
         Server: PhonyServer/1.0
         Transport: RTP/AVP;unicast;
                    dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
                    src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
                    ssrc=93CB001E
         Session: OccldOFFq23KwjYpAnBbUr
         Expires: Fri, 20 Dec 2013 12:20:32 +0000
         Date: Fri, 20 Dec 2013 10:20:32 +0000
         Accept-Ranges: npt
         Pipelined-Requests: 7654
         Media-Properties: Random-Access=0.2, Immutable, Unlimited

   M->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/1.0
         Transport: RTP/AVP;unicast;
                    dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
                    src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
                    ssrc=A813FC13
         Session: OccldOFFq23KwjYpAnBbUr
         Expires: Sat, 21 Dec 2013 10:20:32 +0000
         Date: Fri, 20 Dec 2013 10:20:32 +0000
         Accept-Range: NPT
         Pipelined-Requests: 7654
         Media-Properties: Random-Access=0.8, Immutable, Unlimited

   M->C: RTSP/2.0 200 OK
         CSeq: 4
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:20:32 +0000
         Session: OccldOFFq23KwjYpAnBbUr
         Range: npt=0-623.10
         Seek-Style: RAP
         RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
            ssrc=0D12F123:seq=12345;rtptime=3450012,
           url="rtsp://example.com/twister.3gp/trackID=1"
            ssrc=4F312DD8:seq=54321;rtptime=2876889
         Pipelined-Requests: 7654

A.3.  Secured Media Session for On-Demand Content

   This example is basically the above example (Appendix A.2), but now
   including establishment of SRTP crypto contexts to get a secured
   media delivery.  First of all, the client attempts to fetch this
   insecurely, but the server redirects to a URI indicating a
   requirement on using a secure connection for the RTSP messages.  The
   client establishes a TCP/TLS connection, and the session description
   is retrieved to determine what media resources need to be set up.  In
   the this session description, secure media (SRTP) is indicated.  In
   the next step, the client sends the necessary SETUP requests
   including MIKEY messages.  This is pipelined with a PLAY request to
   initiate media delivery.

   Client C requests a presentation from media server M.  The movie is
   stored in a container file.  The client has obtained an RTSP URI to
   the container file.

   Note: The MIKEY messages below are not valid MIKEY messages and are
   Base64-encoded random data to represent where the MIKEY messages
   would go.

   C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
         CSeq: 1
         User-Agent: PhonyClient/1.2

   M->C: RTSP/2.0 301 Moved Permanently
         CSeq: 1
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:25:32 +0000
         Location: rtsps://example.com/twister.3gp

   C->M: Establish TCP/TLS connection and verify server's
         certificate that represents example.com.
         Used for all below RTSP messages.

   C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0
         CSeq: 2
         User-Agent: PhonyClient/1.2

   M->C: RTSP/2.0 200 OK
         CSeq: 2
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:25:33 +0000
         Content-Type: application/sdp
         Content-Length: 271
         Content-Base: rtsps://example.com/twister.3gp/
         Expires: Fri, 20 Dec 2013 12:25:33 +0000

         v=0
         o=- 2890844256 2890842807 IN IP4 192.0.2.5
         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/SAVP 0
         a=control: trackID=1
         m=video 0 RTP/SAVP 26
         a=control: trackID=4

   C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Require: play.basic
         Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001";
            MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl
         Accept-Ranges: npt, smpte, clock
         Pipelined-Requests: 7654

   C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0
         CSeq: 4
         User-Agent: PhonyClient/1.2
         Require: play.basic
         Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003";
            MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ=
         Accept-Ranges: npt, smpte, clock
         Pipelined-Requests: 7654

   C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0
         CSeq: 5
         User-Agent: PhonyClient/1.2
         Range: npt=0-
         Seek-Style: RAP
         Pipelined-Requests: 7654

   M->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/1.0
         Transport: RTP/SAVP;unicast;
            dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
            src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
            ssrc=93CB001E;
            MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x
         Session: OccldOFFq23KwjYpAnBbUr
         Expires: Fri, 20 Dec 2013 12:25:34 +0000
         Date: Fri, 20 Dec 2013 10:25:34 +0000
         Accept-Ranges: npt
         Pipelined-Requests: 7654
         Media-Properties: Random-Access=0.2, Immutable, Unlimited

   M->C: RTSP/2.0 200 OK
         CSeq: 4
         Server: PhonyServer/1.0
         Transport: RTP/SAVP;unicast;
            dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
            src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
            ssrc=A813FC13;
            MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00
         Session: OccldOFFq23KwjYpAnBbUr
         Expires: Fri, 20 Dec 2013 12:25:34 +0000
         Date: Fri, 20 Dec 2013 10:25:34 +0000
         Accept-Range: NPT
         Pipelined-Requests: 7654
         Media-Properties: Random-Access=0.8, Immutable, Unlimited

   M->C: RTSP/2.0 200 OK
         CSeq: 5
         Server: PhonyServer/1.0
         Date: Fri, 20 Dec 2013 10:25:34 +0000
         Session: OccldOFFq23KwjYpAnBbUr
         Range: npt=0-623.10
         Seek-Style: RAP
         RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4"
            ssrc=0D12F123:seq=12345;rtptime=3450012,
           url="rtsps://example.com/twister.3gp/trackID=1"
            ssrc=4F312DD8:seq=54321;rtptime=2876889;
         Pipelined-Requests: 7654

A.4.  Media on Demand (Unicast)

   An alternative example of media on demand with a few more tweaks is
   the following.  Client C requests a movie distributed from two
   different media servers A (audio.example.com) and V
   (video.example.com).  The media description is stored on a web server
   W.  The media description contains descriptions of the presentation
   and all its streams, including the codecs that are available and the
   protocol stack.

   In this example, the client is only interested in the last part of
   the movie.

   C->W: GET /twister.sdp HTTP/1.1
         Host: www.example.com
         Accept: application/sdp

   W->C: HTTP/1.1 200 OK
         Date: Wed, 23 Jan 2013 15:35:06 GMT
         Content-Type: application/sdp
         Content-Length: 278
         Expires: Thu, 24 Jan 2013 15:35:06 GMT

         v=0
         o=- 2890844526 2890842807 IN IP4 198.51.100.5
         s=RTSP Session
         e=adm@example.com
         c=IN IP4 0.0.0.0
         a=range:npt=00:00:00-01:49:34
         t=0 0
         m=audio 0 RTP/AVP 0
         a=control:rtsp://audio.example.com/twister/audio.en
         m=video 0 RTP/AVP 31
         a=control:rtsp://video.example.com/twister/video

   C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
         CSeq: 1
         User-Agent: PhonyClient/1.2
         Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
                    RTP/AVP/TCP;unicast;interleaved=0-1
         Accept-Ranges: npt, smpte, clock

   A->C: RTSP/2.0 200 OK
         CSeq: 1
         Session: OccldOFFq23KwjYpAnBbUr
         Transport: RTP/AVP/UDP;unicast;
                    dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
                    src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
         Date: Wed, 23 Jan 2013 15:35:12 +0000
         Server: PhonyServer/1.0
         Expires: Thu, 24 Jan 2013 15:35:12 +0000
         Cache-Control: public
         Accept-Ranges: npt, smpte
         Media-Properties: Random-Access=0.02, Immutable, Unlimited

   C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
         CSeq: 1
         User-Agent: PhonyClient/1.2
         Transport: RTP/AVP/UDP;unicast;
                    dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
                    RTP/AVP/TCP;unicast;interleaved=0-1
         Accept-Ranges: npt, smpte, clock

   V->C: RTSP/2.0 200 OK
         CSeq: 1
         Session: P5it3pMo6xHkjUcDrNkBjf
         Transport: RTP/AVP/UDP;unicast;
            dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
            src_addr="198.51.100.5:5002"/"198.51.100.5:5003"
         Date: Wed, 23 Jan 2013 15:35:12 +0000
         Server: PhonyServer/1.0
         Cache-Control: public
         Expires: Thu, 24 Jan 2013 15:35:12 +0000
         Accept-Ranges: npt, smpte
         Media-Properties: Random-Access=1.2, Immutable, Unlimited

   C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
         CSeq: 2
         User-Agent: PhonyClient/1.2
         Session: P5it3pMo6xHkjUcDrNkBjf
         Range: smpte=0:10:00-

   V->C: RTSP/2.0 200 OK
         CSeq: 2
         Session: P5it3pMo6xHkjUcDrNkBjf
         Range: smpte=0:10:00-1:49:23
         Seek-Style: First-Prior
         RTP-Info: url="rtsp://video.example.com/twister/video"
                   ssrc=A17E189D:seq=12312232;rtptime=78712811
         Server: PhonyServer/2.0
         Date: Wed, 23 Jan 2013 15:35:13 +0000

   C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
         CSeq: 2
         User-Agent: PhonyClient/1.2
         Session: OccldOFFq23KwjYpAnBbUr
         Range: smpte=0:10:00-

   A->C: RTSP/2.0 200 OK
         CSeq: 2
         Session: OccldOFFq23KwjYpAnBbUr
         Range: smpte=0:10:00-1:49:23
         Seek-Style: First-Prior
         RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
                   ssrc=3D124F01:seq=876655;rtptime=1032181
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:35:13 +0000

   C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Session: OccldOFFq23KwjYpAnBbUr

   A->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000

   C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Session: P5it3pMo6xHkjUcDrNkBjf

   V->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/2.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000

   Even though the audio and video track are on two different servers
   that may start at slightly different times and may drift with respect
   to each other over time, the client can perform initial
   synchronization of the two media using RTP-Info and Range received in
   the PLAY responses.  If the two servers are time synchronized, the
   RTCP packets can also be used to maintain synchronization.

A.5.  Single-Stream Container Files

   Some RTSP servers may treat all files as though they are "container
   files", yet other servers may not support such a concept.  Because of
   this, clients needs to use the rules set forth in the session
   description for Request-URIs rather than assuming that a consistent
   URI may always be used throughout.  Below is an example of how a
   multi-stream server might expect a single-stream file to be served:

   C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0
         Accept: application/x-rtsp-mh, application/sdp
         CSeq: 1
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 1
         Content-base: rtsp://foo.example.com/test.wav/
         Content-type: application/sdp
         Content-length: 163
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000
         Expires: Thu, 24 Jan 2013 15:36:52 +0000

         v=0
         o=- 872653257 872653257 IN IP4 192.0.2.5
         s=mu-law wave file
         i=audio test
         c=IN IP4 0.0.0.0
         t=0 0
         a=control: *
         m=audio 0 RTP/AVP 0
         a=control:streamid=0

   C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0
         Transport: RTP/AVP/UDP;unicast;
            dest_addr=":6970"/":6971";mode="PLAY"
         CSeq: 2
         User-Agent: PhonyClient/1.2
         Accept-Ranges: npt, smpte, clock

   S->C: RTSP/2.0 200 OK
         Transport: RTP/AVP/UDP;unicast;
             dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
             src_addr="198.51.100.5:6970"/"198.51.100.5:6971";
             mode="PLAY";ssrc=EAB98712
         CSeq: 2
         Session: NYkqQYKk0bb12BY3goyoyO
         Expires: Thu, 24 Jan 2013 15:36:52 +0000
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000
         Accept-Ranges: npt
         Media-Properties: Random-Access=0.5, Immutable, Unlimited

   C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Session: NYkqQYKk0bb12BY3goyoyO

   S->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000
         Session: NYkqQYKk0bb12BY3goyoyO
         Range: npt=0-600
         Seek-Style: RAP
         RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0"
            ssrc=0D12F123:seq=981888;rtptime=3781123

   Note the different URI in the SETUP command and then the switch back
   to the aggregate URI in the PLAY command.  This makes complete sense
   when there are multiple streams with aggregate control, but it is
   less than intuitive in the special case where the number of streams
   is one.  However, the server has declared the aggregated control URI
   in the SDP; therefore, this is legal.

   In this case, it is also required that servers accept implementations
   that use the non-aggregated interpretation and use the individual
   media URI, like this:

   C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Session: NYkqQYKk0bb12BY3goyoyO

A.6.  Live Media Presentation Using Multicast

   The media server M chooses the multicast address and port.  Here, it
   is assumed that the web server only contains a pointer to the full
   description, while the media server M maintains the full description.

   C->W: GET /sessions.html HTTP/1.1
         Host: www.example.com

   W->C: HTTP/1.1 200 OK
         Content-Type: text/html

         <html>
           ...
           <a href "rtsp://live.example.com/concert/audio">
              Streamed Live Music performance </a>
           ...
         </html>


   C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 1
         Supported: play.basic, play.scale
         User-Agent: PhonyClient/1.2

   M->C: RTSP/2.0 200 OK
         CSeq: 1
         Content-Type: application/sdp
         Content-Length: 183
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000
         Supported: play.basic

         v=0
         o=- 2890844526 2890842807 IN IP4 192.0.2.5
         s=RTSP Session
         t=0 0
         m=audio 3456 RTP/AVP 0
         c=IN IP4 233.252.0.54/16
         a=control: rtsp://live.example.com/concert/audio
         a=range:npt=0-

   C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 2
         Transport: RTP/AVP;multicast;
              dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
         Accept-Ranges: npt, smpte, clock
         User-Agent: PhonyClient/1.2

   M->C: RTSP/2.0 200 OK
         CSeq: 2
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000
         Transport: RTP/AVP;multicast;
              dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
              ;ssrc=4D12AB92/0DF876A3
         Session: qHj4jidpmF6zy9v9tNbtxr
         Accept-Ranges: npt, clock
         Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0


   C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 3
         Session: qHj4jidpmF6zy9v9tNbtxr
         User-Agent: PhonyClient/1.2

   M->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/1.0
         Date: Wed, 23 Jan 2013 15:36:52 +0000
         Session: qHj4jidpmF6zy9v9tNbtxr
         Seek-Style: Next
         Range:npt=1256-
         RTP-Info: url="rtsp://live.example.com/concert/audio"
                   ssrc=0D12F123:seq=1473; rtptime=80000

A.7.  Capability Negotiation

   This example illustrates how the client and server determine their
   capability to support a special feature, in this case, "play.scale".
   The server, through the client request and the included Supported
   header, learns that the client supports RTSP 2.0 and also supports
   the playback time scaling feature of RTSP.  The server's response
   contains the following feature-related information to the client; it
   supports the basic media delivery functions (play.basic), the
   extended functionality of time scaling of content (play.scale), and
   one "example.com" proprietary feature (com.example.flight).  The
   client also learns the methods supported (Public header) by the
   server for the indicated resource.

   C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
         CSeq: 1
         Supported: play.basic, play.scale
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 1
         Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER
         Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE
         Server: PhonyServer/2.0
         Supported: play.basic, play.scale, com.example.flight

   When the client sends its SETUP request, it tells the server that it
   requires support of the play.scale feature for this session by
   including the Require header.

   C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Transport: RTP/AVP/UDP;unicast;
                    dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
                    RTP/AVP/TCP;unicast;interleaved=0-1
         Require: play.scale
         Accept-Ranges: npt, smpte, clock
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 3
         Session: OccldOFFq23KwjYpAnBbUr
         Transport: RTP/AVP/UDP;unicast;
            dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
            src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
         Server: PhonyServer/2.0
         Accept-Ranges: npt, smpte
         Media-Properties: Random-Access=0.8, Immutable, Unlimited

Appendix B.  RTSP Protocol State Machine

   The RTSP session state machine describes the behavior of the protocol
   from RTSP session initialization through RTSP session termination.
   It is probably easiest to think of this as the server's state and
   then view the client as needing to track what it believes the
   server's state will be based on sent or received RTSP messages.
   Thus, in most cases, the state tables below can be read as: if the
   client does X, and assuming it fulfills any prerequisite(s), the
   (server) state will move to the new state and the indicated response
   will returned.  However, there are also server-to-client
   notifications or requests, where the action describes what

   notification or request will occur, its requisites, what new state
   will result after the server has received the response, as well as
   describing the client's response to the action.

   The State machine is defined on a per-session basis, which is
   uniquely identified by the RTSP session identifier.  The session may
   contain one or more media streams depending on state.  If a single
   media stream is part of the session, it is in non-aggregated control.
   If two or more are part of the session, it is in aggregated control.

   The below state machine is an informative description of the
   protocol's behavior.  In case of ambiguity with the earlier parts of
   this specification, the description in the earlier parts take
   precedence.

B.1.  States

   The state machine contains three states, described below.  For each
   state, there exists a table that shows which requests and events are
   allowed and whether they will result in a state change.

   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.

B.2.  State Variables

   This representation of the state machine needs more than its state to
   work.  A small number of variables are also needed, and they are
   explained below.

   NRM:  The number of media streams that are part of this session.

   RP:   Resume point, the point in the presentation time line at which
         a request to continue playing will resume from.  A time format
         for the variable is not mandated.

B.3.  Abbreviations

   To make the state tables more compact, a number of abbreviations are
   used, which are explained below.

   IFI:  IF Implemented.

   md:   Media

   PP:   Pause Point, the point in the presentation timeline at which
         the presentation was paused.

   Prs:  Presentation, the complete multimedia presentation.

   RedP: Redirect Point, the point in the presentation timeline at which
         a REDIRECT was specified to occur.

   SES:  Session.