Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7826

Real-Time Streaming Protocol Version 2.0

Pages: 318
Proposed Standard
Obsoletes:  2326
Part 11 of 13 – Pages 240 to 267
First   Prev   Next

Top   ToC   RFC7826 - Page 240   prevText

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>.
Top   ToC   RFC7826 - Page 241
   [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>.
Top   ToC   RFC7826 - Page 242
   [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>.
Top   ToC   RFC7826 - Page 243
   [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>.
Top   ToC   RFC7826 - Page 244
   [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>.
Top   ToC   RFC7826 - Page 245

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>.
Top   ToC   RFC7826 - Page 246
   [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>.
Top   ToC   RFC7826 - Page 247
   [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.
Top   ToC   RFC7826 - Page 248

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.
Top   ToC   RFC7826 - Page 249
   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
Top   ToC   RFC7826 - Page 250
   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
Top   ToC   RFC7826 - Page 251
   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.
Top   ToC   RFC7826 - Page 252
   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
Top   ToC   RFC7826 - Page 253
   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
Top   ToC   RFC7826 - Page 254
   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.
Top   ToC   RFC7826 - Page 255
   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
Top   ToC   RFC7826 - Page 256
   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
Top   ToC   RFC7826 - Page 257
   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
Top   ToC   RFC7826 - Page 258
   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
Top   ToC   RFC7826 - Page 259
   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
Top   ToC   RFC7826 - Page 260
   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:
Top   ToC   RFC7826 - Page 261
   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
Top   ToC   RFC7826 - Page 262
   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
Top   ToC   RFC7826 - Page 263

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-
Top   ToC   RFC7826 - Page 264
   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.
Top   ToC   RFC7826 - Page 265
   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
Top   ToC   RFC7826 - Page 266
   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
Top   ToC   RFC7826 - Page 267
   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.



(page 267 continued on part 12)

Next Section