7826
PROPOSED STANDARD
Real-Time Streaming Protocol Version 2.0
Authors: H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling
Date: December 2016
Area: art
Working Group: mmusic
Stream: IETF
Obsoletes:
RFC 2326
Abstract
This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).
RFC 7826
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 7826 Columbia University
Obsoletes: <a href="./rfc2326">2326</a> A. Rao
Category: Standards Track Cisco
ISSN: 2070-1721 R. Lanphier
M. Westerlund
Ericsson
M. Stiemerling, Ed.
University of Applied Sciences Darmstadt
December 2016
<span class="h1">Real-Time Streaming Protocol Version 2.0</span>
Abstract
This memorandum defines the Real-Time Streaming Protocol (RTSP)
version 2.0, which obsoletes RTSP version 1.0 defined in <a href="./rfc2326">RFC 2326</a>.
RTSP is an application-layer protocol for the setup and control of
the delivery of data with real-time properties. RTSP provides an
extensible framework to enable controlled, on-demand delivery of
real-time data, such as audio and video. Sources of data can include
both live data feeds and stored clips. This protocol is intended to
control multiple data delivery sessions; provide a means for choosing
delivery channels such as UDP, multicast UDP, and TCP; and provide a
means for choosing delivery mechanisms based upon RTP (<a href="./rfc3550">RFC 3550</a>).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7826">http://www.rfc-editor.org/info/rfc7826</a>.
<span class="grey">Schulzrinne, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction ...................................................<a href="#page-10">10</a>
<a href="#section-2">2</a>. Protocol Overview ..............................................<a href="#page-11">11</a>
<a href="#section-2.1">2.1</a>. Presentation Description ..................................<a href="#page-12">12</a>
<a href="#section-2.2">2.2</a>. Session Establishment .....................................<a href="#page-12">12</a>
<a href="#section-2.3">2.3</a>. Media Delivery Control ....................................<a href="#page-14">14</a>
<a href="#section-2.4">2.4</a>. Session Parameter Manipulations ...........................<a href="#page-15">15</a>
<a href="#section-2.5">2.5</a>. Media Delivery ............................................<a href="#page-16">16</a>
<a href="#section-2.5.1">2.5.1</a>. Media Delivery Manipulations .......................<a href="#page-16">16</a>
<a href="#section-2.6">2.6</a>. Session Maintenance and Termination .......................<a href="#page-19">19</a>
<a href="#section-2.7">2.7</a>. Extending RTSP ............................................<a href="#page-20">20</a>
<a href="#section-3">3</a>. Document Conventions ...........................................<a href="#page-21">21</a>
<a href="#section-3.1">3.1</a>. Notational Conventions ....................................<a href="#page-21">21</a>
<a href="#section-3.2">3.2</a>. Terminology ...............................................<a href="#page-21">21</a>
<a href="#section-4">4</a>. Protocol Parameters ............................................<a href="#page-25">25</a>
<a href="#section-4.1">4.1</a>. RTSP Version ..............................................<a href="#page-25">25</a>
<a href="#section-4.2">4.2</a>. RTSP IRI and URI ..........................................<a href="#page-25">25</a>
<a href="#section-4.3">4.3</a>. Session Identifiers .......................................<a href="#page-28">28</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<a href="#section-4.4">4.4</a>. Media-Time Formats ........................................<a href="#page-28">28</a>
<a href="#section-4.4.1">4.4.1</a>. SMPTE-Relative Timestamps ..........................<a href="#page-28">28</a>
<a href="#section-4.4.2">4.4.2</a>. Normal Play Time ...................................<a href="#page-29">29</a>
<a href="#section-4.4.3">4.4.3</a>. Absolute Time ......................................<a href="#page-30">30</a>
<a href="#section-4.5">4.5</a>. Feature Tags ..............................................<a href="#page-31">31</a>
<a href="#section-4.6">4.6</a>. Message Body Tags .........................................<a href="#page-32">32</a>
<a href="#section-4.7">4.7</a>. Media Properties ..........................................<a href="#page-32">32</a>
<a href="#section-4.7.1">4.7.1</a>. Random Access and Seeking ..........................<a href="#page-33">33</a>
<a href="#section-4.7.2">4.7.2</a>. Retention ..........................................<a href="#page-34">34</a>
<a href="#section-4.7.3">4.7.3</a>. Content Modifications ..............................<a href="#page-34">34</a>
<a href="#section-4.7.4">4.7.4</a>. Supported Scale Factors ............................<a href="#page-34">34</a>
<a href="#section-4.7.5">4.7.5</a>. Mapping to the Attributes ..........................<a href="#page-35">35</a>
<a href="#section-5">5</a>. RTSP Message ...................................................<a href="#page-35">35</a>
<a href="#section-5.1">5.1</a>. Message Types .............................................<a href="#page-36">36</a>
<a href="#section-5.2">5.2</a>. Message Headers ...........................................<a href="#page-36">36</a>
<a href="#section-5.3">5.3</a>. Message Body ..............................................<a href="#page-37">37</a>
<a href="#section-5.4">5.4</a>. Message Length ............................................<a href="#page-37">37</a>
<a href="#section-6">6</a>. General-Header Fields ..........................................<a href="#page-37">37</a>
<a href="#section-7">7</a>. Request ........................................................<a href="#page-39">39</a>
<a href="#section-7.1">7.1</a>. Request Line ..............................................<a href="#page-40">40</a>
<a href="#section-7.2">7.2</a>. Request-Header Fields .....................................<a href="#page-42">42</a>
<a href="#section-8">8</a>. Response .......................................................<a href="#page-43">43</a>
<a href="#section-8.1">8.1</a>. Status-Line ...............................................<a href="#page-43">43</a>
<a href="#section-8.1.1">8.1.1</a>. Status Code and Reason Phrase ......................<a href="#page-43">43</a>
<a href="#section-8.2">8.2</a>. Response Headers ..........................................<a href="#page-47">47</a>
<a href="#section-9">9</a>. Message Body ...................................................<a href="#page-47">47</a>
<a href="#section-9.1">9.1</a>. Message Body Header Fields ................................<a href="#page-48">48</a>
<a href="#section-9.2">9.2</a>. Message Body ..............................................<a href="#page-49">49</a>
<a href="#section-9.3">9.3</a>. Message Body Format Negotiation ...........................<a href="#page-49">49</a>
<a href="#section-10">10</a>. Connections ...................................................<a href="#page-50">50</a>
<a href="#section-10.1">10.1</a>. Reliability and Acknowledgements .........................<a href="#page-50">50</a>
<a href="#section-10.2">10.2</a>. Using Connections ........................................<a href="#page-51">51</a>
<a href="#section-10.3">10.3</a>. Closing Connections ......................................<a href="#page-54">54</a>
<a href="#section-10.4">10.4</a>. Timing Out Connections and RTSP Messages .................<a href="#page-56">56</a>
<a href="#section-10.5">10.5</a>. Showing Liveness .........................................<a href="#page-57">57</a>
<a href="#section-10.6">10.6</a>. Use of IPv6 ..............................................<a href="#page-58">58</a>
<a href="#section-10.7">10.7</a>. Overload Control .........................................<a href="#page-58">58</a>
<a href="#section-11">11</a>. Capability Handling ...........................................<a href="#page-60">60</a>
<a href="#section-11.1">11.1</a>. Feature Tag: play.basic ..................................<a href="#page-62">62</a>
<a href="#section-12">12</a>. Pipelining Support ............................................<a href="#page-62">62</a>
<a href="#section-13">13</a>. Method Definitions ............................................<a href="#page-63">63</a>
<a href="#section-13.1">13.1</a>. OPTIONS ..................................................<a href="#page-65">65</a>
<a href="#section-13.2">13.2</a>. DESCRIBE .................................................<a href="#page-66">66</a>
<a href="#section-13.3">13.3</a>. SETUP ....................................................<a href="#page-68">68</a>
<a href="#section-13.3.1">13.3.1</a>. Changing Transport Parameters .....................<a href="#page-71">71</a>
<a href="#section-13.4">13.4</a>. PLAY .....................................................<a href="#page-72">72</a>
<a href="#section-13.4.1">13.4.1</a>. General Usage .....................................<a href="#page-72">72</a>
<a href="#section-13.4.2">13.4.2</a>. Aggregated Sessions ...............................<a href="#page-77">77</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<a href="#section-13.4.3">13.4.3</a>. Updating Current PLAY Requests ....................<a href="#page-78">78</a>
<a href="#section-13.4.4">13.4.4</a>. Playing On-Demand Media ...........................<a href="#page-81">81</a>
<a href="#section-13.4.5">13.4.5</a>. Playing Dynamic On-Demand Media ...................<a href="#page-81">81</a>
<a href="#section-13.4.6">13.4.6</a>. Playing Live Media ................................<a href="#page-81">81</a>
<a href="#section-13.4.7">13.4.7</a>. Playing Live with Recording .......................<a href="#page-82">82</a>
<a href="#section-13.4.8">13.4.8</a>. Playing Live with Time-Shift ......................<a href="#page-83">83</a>
<a href="#section-13.5">13.5</a>. PLAY_NOTIFY ..............................................<a href="#page-83">83</a>
<a href="#section-13.5.1">13.5.1</a>. End-of-Stream .....................................<a href="#page-84">84</a>
<a href="#section-13.5.2">13.5.2</a>. Media-Properties-Update ...........................<a href="#page-86">86</a>
<a href="#section-13.5.3">13.5.3</a>. Scale-Change ......................................<a href="#page-87">87</a>
<a href="#section-13.6">13.6</a>. PAUSE ....................................................<a href="#page-89">89</a>
<a href="#section-13.7">13.7</a>. TEARDOWN .................................................<a href="#page-92">92</a>
<a href="#section-13.7.1">13.7.1</a>. Client to Server ..................................<a href="#page-92">92</a>
<a href="#section-13.7.2">13.7.2</a>. Server to Client ..................................<a href="#page-93">93</a>
<a href="#section-13.8">13.8</a>. GET_PARAMETER ............................................<a href="#page-94">94</a>
<a href="#section-13.9">13.9</a>. SET_PARAMETER ............................................<a href="#page-96">96</a>
<a href="#section-13.10">13.10</a>. REDIRECT ................................................<a href="#page-98">98</a>
<a href="#section-14">14</a>. Embedded (Interleaved) Binary Data ...........................<a href="#page-101">101</a>
<a href="#section-15">15</a>. Proxies ......................................................<a href="#page-103">103</a>
<a href="#section-15.1">15.1</a>. Proxies and Protocol Extensions .........................<a href="#page-104">104</a>
<a href="#section-15.2">15.2</a>. Multiplexing and Demultiplexing of Messages .............<a href="#page-105">105</a>
<a href="#section-16">16</a>. Caching ......................................................<a href="#page-106">106</a>
<a href="#section-16.1">16.1</a>. Validation Model ........................................<a href="#page-107">107</a>
<a href="#section-16.1.1">16.1.1</a>. Last-Modified Dates ..............................<a href="#page-108">108</a>
<a href="#section-16.1.2">16.1.2</a>. Message Body Tag Cache Validators ................<a href="#page-108">108</a>
<a href="#section-16.1.3">16.1.3</a>. Weak and Strong Validators .......................<a href="#page-108">108</a>
16.1.4. Rules for When to Use Message Body Tags
and Last-Modified Dates ..........................<a href="#page-110">110</a>
<a href="#section-16.1.5">16.1.5</a>. Non-validating Conditionals ......................<a href="#page-112">112</a>
<a href="#section-16.2">16.2</a>. Invalidation after Updates or Deletions .................<a href="#page-112">112</a>
<a href="#section-17">17</a>. Status Code Definitions ......................................<a href="#page-113">113</a>
<a href="#section-17.1">17.1</a>. Informational 1xx .......................................<a href="#page-113">113</a>
<a href="#section-17.1.1">17.1.1</a>. 100 Continue .....................................<a href="#page-113">113</a>
<a href="#section-17.2">17.2</a>. Success 2xx .............................................<a href="#page-113">113</a>
<a href="#section-17.2.1">17.2.1</a>. 200 OK ...........................................<a href="#page-113">113</a>
<a href="#section-17.3">17.3</a>. Redirection 3xx .........................................<a href="#page-113">113</a>
<a href="#section-17.3.1">17.3.1</a>. 300 ..............................................<a href="#page-114">114</a>
<a href="#section-17.3.2">17.3.2</a>. 301 Moved Permanently ............................<a href="#page-114">114</a>
<a href="#section-17.3.3">17.3.3</a>. 302 Found ........................................<a href="#page-114">114</a>
<a href="#section-17.3.4">17.3.4</a>. 303 See Other ....................................<a href="#page-115">115</a>
<a href="#section-17.3.5">17.3.5</a>. 304 Not Modified .................................<a href="#page-115">115</a>
<a href="#section-17.3.6">17.3.6</a>. 305 Use Proxy ....................................<a href="#page-115">115</a>
<a href="#section-17.4">17.4</a>. Client Error 4xx ........................................<a href="#page-116">116</a>
<a href="#section-17.4.1">17.4.1</a>. 400 Bad Request ..................................<a href="#page-116">116</a>
<a href="#section-17.4.2">17.4.2</a>. 401 Unauthorized .................................<a href="#page-116">116</a>
<a href="#section-17.4.3">17.4.3</a>. 402 Payment Required .............................<a href="#page-116">116</a>
<a href="#section-17.4.4">17.4.4</a>. 403 Forbidden ....................................<a href="#page-116">116</a>
<a href="#section-17.4.5">17.4.5</a>. 404 Not Found ....................................<a href="#page-116">116</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<a href="#section-17.4.6">17.4.6</a>. 405 Method Not Allowed ...........................<a href="#page-117">117</a>
<a href="#section-17.4.7">17.4.7</a>. 406 Not Acceptable ...............................<a href="#page-117">117</a>
<a href="#section-17.4.8">17.4.8</a>. 407 Proxy Authentication Required ................<a href="#page-117">117</a>
<a href="#section-17.4.9">17.4.9</a>. 408 Request Timeout ..............................<a href="#page-117">117</a>
<a href="#section-17.4.10">17.4.10</a>. 410 Gone ........................................<a href="#page-118">118</a>
<a href="#section-17.4.11">17.4.11</a>. 412 Precondition Failed .........................<a href="#page-118">118</a>
<a href="#section-17.4.12">17.4.12</a>. 413 Request Message Body Too Large ..............<a href="#page-118">118</a>
<a href="#section-17.4.13">17.4.13</a>. 414 Request-URI Too Long ........................<a href="#page-118">118</a>
<a href="#section-17.4.14">17.4.14</a>. 415 Unsupported Media Type ......................<a href="#page-119">119</a>
<a href="#section-17.4.15">17.4.15</a>. 451 Parameter Not Understood ....................<a href="#page-119">119</a>
<a href="#section-17.4.16">17.4.16</a>. 452 Illegal Conference Identifier ...............<a href="#page-119">119</a>
<a href="#section-17.4.17">17.4.17</a>. 453 Not Enough Bandwidth ........................<a href="#page-119">119</a>
<a href="#section-17.4.18">17.4.18</a>. 454 Session Not Found ...........................<a href="#page-119">119</a>
<a href="#section-17.4.19">17.4.19</a>. 455 Method Not Valid in This State ..............<a href="#page-119">119</a>
<a href="#section-17.4.20">17.4.20</a>. 456 Header Field Not Valid for Resource .........<a href="#page-119">119</a>
<a href="#section-17.4.21">17.4.21</a>. 457 Invalid Range ...............................<a href="#page-120">120</a>
<a href="#section-17.4.22">17.4.22</a>. 458 Parameter Is Read-Only ......................<a href="#page-120">120</a>
<a href="#section-17.4.23">17.4.23</a>. 459 Aggregate Operation Not Allowed .............<a href="#page-120">120</a>
<a href="#section-17.4.24">17.4.24</a>. 460 Only Aggregate Operation Allowed ............<a href="#page-120">120</a>
<a href="#section-17.4.25">17.4.25</a>. 461 Unsupported Transport .......................<a href="#page-120">120</a>
<a href="#section-17.4.26">17.4.26</a>. 462 Destination Unreachable .....................<a href="#page-120">120</a>
<a href="#section-17.4.27">17.4.27</a>. 463 Destination Prohibited ......................<a href="#page-120">120</a>
<a href="#section-17.4.28">17.4.28</a>. 464 Data Transport Not Ready Yet ................<a href="#page-121">121</a>
<a href="#section-17.4.29">17.4.29</a>. 465 Notification Reason Unknown .................<a href="#page-121">121</a>
<a href="#section-17.4.30">17.4.30</a>. 466 Key Management Error ........................<a href="#page-121">121</a>
<a href="#section-17.4.31">17.4.31</a>. 470 Connection Authorization Required ...........<a href="#page-121">121</a>
<a href="#section-17.4.32">17.4.32</a>. 471 Connection Credentials Not Accepted .........<a href="#page-121">121</a>
<a href="#section-17.4.33">17.4.33</a>. 472 Failure to Establish Secure Connection ......<a href="#page-121">121</a>
<a href="#section-17.5">17.5</a>. Server Error 5xx ........................................<a href="#page-122">122</a>
<a href="#section-17.5.1">17.5.1</a>. 500 Internal Server Error ........................<a href="#page-122">122</a>
<a href="#section-17.5.2">17.5.2</a>. 501 Not Implemented ..............................<a href="#page-122">122</a>
<a href="#section-17.5.3">17.5.3</a>. 502 Bad Gateway ..................................<a href="#page-122">122</a>
<a href="#section-17.5.4">17.5.4</a>. 503 Service Unavailable ..........................<a href="#page-122">122</a>
<a href="#section-17.5.5">17.5.5</a>. 504 Gateway Timeout ..............................<a href="#page-123">123</a>
<a href="#section-17.5.6">17.5.6</a>. 505 RTSP Version Not Supported ...................<a href="#page-123">123</a>
<a href="#section-17.5.7">17.5.7</a>. 551 Option Not Supported .........................<a href="#page-123">123</a>
<a href="#section-17.5.8">17.5.8</a>. 553 Proxy Unavailable ............................<a href="#page-123">123</a>
<a href="#section-18">18</a>. Header Field Definitions .....................................<a href="#page-124">124</a>
<a href="#section-18.1">18.1</a>. Accept ..................................................<a href="#page-134">134</a>
<a href="#section-18.2">18.2</a>. Accept-Credentials ......................................<a href="#page-135">135</a>
<a href="#section-18.3">18.3</a>. Accept-Encoding .........................................<a href="#page-135">135</a>
<a href="#section-18.4">18.4</a>. Accept-Language .........................................<a href="#page-136">136</a>
<a href="#section-18.5">18.5</a>. Accept-Ranges ...........................................<a href="#page-137">137</a>
<a href="#section-18.6">18.6</a>. Allow ...................................................<a href="#page-138">138</a>
<a href="#section-18.7">18.7</a>. Authentication-Info .....................................<a href="#page-138">138</a>
<a href="#section-18.8">18.8</a>. Authorization ...........................................<a href="#page-138">138</a>
<a href="#section-18.9">18.9</a>. Bandwidth ...............................................<a href="#page-139">139</a>
<a href="#section-18.10">18.10</a>. Blocksize ..............................................<a href="#page-140">140</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<a href="#section-18.11">18.11</a>. Cache-Control ..........................................<a href="#page-140">140</a>
<a href="#section-18.12">18.12</a>. Connection .............................................<a href="#page-143">143</a>
<a href="#section-18.13">18.13</a>. Connection-Credentials .................................<a href="#page-143">143</a>
<a href="#section-18.14">18.14</a>. Content-Base ...........................................<a href="#page-144">144</a>
<a href="#section-18.15">18.15</a>. Content-Encoding .......................................<a href="#page-145">145</a>
<a href="#section-18.16">18.16</a>. Content-Language .......................................<a href="#page-145">145</a>
<a href="#section-18.17">18.17</a>. Content-Length .........................................<a href="#page-146">146</a>
<a href="#section-18.18">18.18</a>. Content-Location .......................................<a href="#page-146">146</a>
<a href="#section-18.19">18.19</a>. Content-Type ...........................................<a href="#page-148">148</a>
<a href="#section-18.20">18.20</a>. CSeq ...................................................<a href="#page-148">148</a>
<a href="#section-18.21">18.21</a>. Date ...................................................<a href="#page-150">150</a>
<a href="#section-18.22">18.22</a>. Expires ................................................<a href="#page-151">151</a>
<a href="#section-18.23">18.23</a>. From ...................................................<a href="#page-151">151</a>
<a href="#section-18.24">18.24</a>. If-Match ...............................................<a href="#page-152">152</a>
<a href="#section-18.25">18.25</a>. If-Modified-Since ......................................<a href="#page-152">152</a>
<a href="#section-18.26">18.26</a>. If-None-Match ..........................................<a href="#page-153">153</a>
<a href="#section-18.27">18.27</a>. Last-Modified ..........................................<a href="#page-154">154</a>
<a href="#section-18.28">18.28</a>. Location ...............................................<a href="#page-154">154</a>
<a href="#section-18.29">18.29</a>. Media-Properties .......................................<a href="#page-154">154</a>
<a href="#section-18.30">18.30</a>. Media-Range ............................................<a href="#page-156">156</a>
<a href="#section-18.31">18.31</a>. MTag ...................................................<a href="#page-157">157</a>
<a href="#section-18.32">18.32</a>. Notify-Reason ..........................................<a href="#page-158">158</a>
<a href="#section-18.33">18.33</a>. Pipelined-Requests .....................................<a href="#page-158">158</a>
<a href="#section-18.34">18.34</a>. Proxy-Authenticate .....................................<a href="#page-159">159</a>
<a href="#section-18.35">18.35</a>. Proxy-Authentication-Info ..............................<a href="#page-159">159</a>
<a href="#section-18.36">18.36</a>. Proxy-Authorization ....................................<a href="#page-159">159</a>
<a href="#section-18.37">18.37</a>. Proxy-Require ..........................................<a href="#page-160">160</a>
<a href="#section-18.38">18.38</a>. Proxy-Supported ........................................<a href="#page-160">160</a>
<a href="#section-18.39">18.39</a>. Public .................................................<a href="#page-161">161</a>
<a href="#section-18.40">18.40</a>. Range ..................................................<a href="#page-162">162</a>
<a href="#section-18.41">18.41</a>. Referrer ...............................................<a href="#page-164">164</a>
<a href="#section-18.42">18.42</a>. Request-Status .........................................<a href="#page-164">164</a>
<a href="#section-18.43">18.43</a>. Require ................................................<a href="#page-165">165</a>
<a href="#section-18.44">18.44</a>. Retry-After ............................................<a href="#page-166">166</a>
<a href="#section-18.45">18.45</a>. RTP-Info ...............................................<a href="#page-167">167</a>
<a href="#section-18.46">18.46</a>. Scale ..................................................<a href="#page-169">169</a>
<a href="#section-18.47">18.47</a>. Seek-Style .............................................<a href="#page-170">170</a>
<a href="#section-18.48">18.48</a>. Server .................................................<a href="#page-171">171</a>
<a href="#section-18.49">18.49</a>. Session ................................................<a href="#page-172">172</a>
<a href="#section-18.50">18.50</a>. Speed ..................................................<a href="#page-173">173</a>
<a href="#section-18.51">18.51</a>. Supported ..............................................<a href="#page-174">174</a>
<a href="#section-18.52">18.52</a>. Terminate-Reason .......................................<a href="#page-175">175</a>
<a href="#section-18.53">18.53</a>. Timestamp ..............................................<a href="#page-175">175</a>
<a href="#section-18.54">18.54</a>. Transport ..............................................<a href="#page-176">176</a>
<a href="#section-18.55">18.55</a>. Unsupported ............................................<a href="#page-183">183</a>
<a href="#section-18.56">18.56</a>. User-Agent .............................................<a href="#page-184">184</a>
<a href="#section-18.57">18.57</a>. Via ....................................................<a href="#page-184">184</a>
<a href="#section-18.58">18.58</a>. WWW-Authenticate .......................................<a href="#page-185">185</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<a href="#section-19">19</a>. Security Framework ...........................................<a href="#page-185">185</a>
<a href="#section-19.1">19.1</a>. RTSP and HTTP Authentication ............................<a href="#page-185">185</a>
<a href="#section-19.1.1">19.1.1</a>. Digest Authentication ............................<a href="#page-186">186</a>
<a href="#section-19.2">19.2</a>. RTSP over TLS ...........................................<a href="#page-187">187</a>
<a href="#section-19.3">19.3</a>. Security and Proxies ....................................<a href="#page-188">188</a>
<a href="#section-19.3.1">19.3.1</a>. Accept-Credentials ...............................<a href="#page-189">189</a>
<a href="#section-19.3.2">19.3.2</a>. User-Approved TLS Procedure ......................<a href="#page-190">190</a>
<a href="#section-20">20</a>. Syntax .......................................................<a href="#page-192">192</a>
<a href="#section-20.1">20.1</a>. Base Syntax .............................................<a href="#page-193">193</a>
<a href="#section-20.2">20.2</a>. RTSP Protocol Definition ................................<a href="#page-195">195</a>
<a href="#section-20.2.1">20.2.1</a>. Generic Protocol Elements ........................<a href="#page-195">195</a>
<a href="#section-20.2.2">20.2.2</a>. Message Syntax ...................................<a href="#page-198">198</a>
<a href="#section-20.2.3">20.2.3</a>. Header Syntax ....................................<a href="#page-201">201</a>
<a href="#section-20.3">20.3</a>. SDP Extension Syntax ....................................<a href="#page-209">209</a>
<a href="#section-21">21</a>. Security Considerations ......................................<a href="#page-209">209</a>
<a href="#section-21.1">21.1</a>. Signaling Protocol Threats ..............................<a href="#page-210">210</a>
<a href="#section-21.2">21.2</a>. Media Stream Delivery Threats ...........................<a href="#page-213">213</a>
<a href="#section-21.2.1">21.2.1</a>. Remote DoS Attack ................................<a href="#page-215">215</a>
<a href="#section-21.2.2">21.2.2</a>. RTP Security Analysis ............................<a href="#page-216">216</a>
<a href="#section-22">22</a>. IANA Considerations ..........................................<a href="#page-217">217</a>
<a href="#section-22.1">22.1</a>. Feature Tags ............................................<a href="#page-218">218</a>
<a href="#section-22.1.1">22.1.1</a>. Description ......................................<a href="#page-218">218</a>
<a href="#section-22.1.2">22.1.2</a>. Registering New Feature Tags with IANA ...........<a href="#page-218">218</a>
<a href="#section-22.1.3">22.1.3</a>. Registered Entries ...............................<a href="#page-219">219</a>
<a href="#section-22.2">22.2</a>. RTSP Methods ............................................<a href="#page-219">219</a>
<a href="#section-22.2.1">22.2.1</a>. Description ......................................<a href="#page-219">219</a>
<a href="#section-22.2.2">22.2.2</a>. Registering New Methods with IANA ................<a href="#page-219">219</a>
<a href="#section-22.2.3">22.2.3</a>. Registered Entries ...............................<a href="#page-220">220</a>
<a href="#section-22.3">22.3</a>. RTSP Status Codes .......................................<a href="#page-220">220</a>
<a href="#section-22.3.1">22.3.1</a>. Description ......................................<a href="#page-220">220</a>
<a href="#section-22.3.2">22.3.2</a>. Registering New Status Codes with IANA ...........<a href="#page-220">220</a>
<a href="#section-22.3.3">22.3.3</a>. Registered Entries ...............................<a href="#page-221">221</a>
<a href="#section-22.4">22.4</a>. RTSP Headers ............................................<a href="#page-221">221</a>
<a href="#section-22.4.1">22.4.1</a>. Description ......................................<a href="#page-221">221</a>
<a href="#section-22.4.2">22.4.2</a>. Registering New Headers with IANA ................<a href="#page-221">221</a>
<a href="#section-22.4.3">22.4.3</a>. Registered Entries ...............................<a href="#page-222">222</a>
<a href="#section-22.5">22.5</a>. Accept-Credentials ......................................<a href="#page-223">223</a>
<a href="#section-22.5.1">22.5.1</a>. Accept-Credentials Policies ......................<a href="#page-223">223</a>
<a href="#section-22.5.2">22.5.2</a>. Accept-Credentials Hash Algorithms ...............<a href="#page-224">224</a>
<a href="#section-22.6">22.6</a>. Cache-Control Cache Directive Extensions ................<a href="#page-224">224</a>
<a href="#section-22.7">22.7</a>. Media Properties ........................................<a href="#page-225">225</a>
<a href="#section-22.7.1">22.7.1</a>. Description ......................................<a href="#page-225">225</a>
<a href="#section-22.7.2">22.7.2</a>. Registration Rules ...............................<a href="#page-226">226</a>
<a href="#section-22.7.3">22.7.3</a>. Registered Values ................................<a href="#page-226">226</a>
<a href="#section-22.8">22.8</a>. Notify-Reason Values ....................................<a href="#page-226">226</a>
<a href="#section-22.8.1">22.8.1</a>. Description ......................................<a href="#page-226">226</a>
<a href="#section-22.8.2">22.8.2</a>. Registration Rules ...............................<a href="#page-226">226</a>
<a href="#section-22.8.3">22.8.3</a>. Registered Values ................................<a href="#page-227">227</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<a href="#section-22.9">22.9</a>. Range Header Formats ....................................<a href="#page-227">227</a>
<a href="#section-22.9.1">22.9.1</a>. Description ......................................<a href="#page-227">227</a>
<a href="#section-22.9.2">22.9.2</a>. Registration Rules ...............................<a href="#page-227">227</a>
<a href="#section-22.9.3">22.9.3</a>. Registered Values ................................<a href="#page-228">228</a>
<a href="#section-22.10">22.10</a>. Terminate-Reason Header ................................<a href="#page-228">228</a>
<a href="#section-22.10.1">22.10.1</a>. Redirect Reasons ................................<a href="#page-228">228</a>
<a href="#section-22.10.2">22.10.2</a>. Terminate-Reason Header Parameters ..............<a href="#page-229">229</a>
<a href="#section-22.11">22.11</a>. RTP-Info Header Parameters .............................<a href="#page-229">229</a>
<a href="#section-22.11.1">22.11.1</a>. Description .....................................<a href="#page-229">229</a>
<a href="#section-22.11.2">22.11.2</a>. Registration Rules ..............................<a href="#page-229">229</a>
<a href="#section-22.11.3">22.11.3</a>. Registered Values ...............................<a href="#page-230">230</a>
<a href="#section-22.12">22.12</a>. Seek-Style Policies ....................................<a href="#page-230">230</a>
<a href="#section-22.12.1">22.12.1</a>. Description .....................................<a href="#page-230">230</a>
<a href="#section-22.12.2">22.12.2</a>. Registration Rules ..............................<a href="#page-230">230</a>
<a href="#section-22.12.3">22.12.3</a>. Registered Values ...............................<a href="#page-230">230</a>
<a href="#section-22.13">22.13</a>. Transport Header Registries ............................<a href="#page-231">231</a>
<a href="#section-22.13.1">22.13.1</a>. Transport Protocol Identifier ...................<a href="#page-231">231</a>
<a href="#section-22.13.2">22.13.2</a>. Transport Modes .................................<a href="#page-233">233</a>
<a href="#section-22.13.3">22.13.3</a>. Transport Parameters ............................<a href="#page-233">233</a>
<a href="#section-22.14">22.14</a>. URI Schemes ............................................<a href="#page-234">234</a>
<a href="#section-22.14.1">22.14.1</a>. The "rtsp" URI Scheme ...........................<a href="#page-234">234</a>
<a href="#section-22.14.2">22.14.2</a>. The "rtsps" URI Scheme ..........................<a href="#page-235">235</a>
<a href="#section-22.14.3">22.14.3</a>. The "rtspu" URI Scheme ..........................<a href="#page-237">237</a>
<a href="#section-22.15">22.15</a>. SDP Attributes .........................................<a href="#page-238">238</a>
<a href="#section-22.16">22.16</a>. Media Type Registration for text/parameters ............<a href="#page-238">238</a>
<a href="#section-23">23</a>. References ...................................................<a href="#page-240">240</a>
<a href="#section-23.1">23.1</a>. Normative References ....................................<a href="#page-240">240</a>
<a href="#section-23.2">23.2</a>. Informative References ..................................<a href="#page-245">245</a>
<a href="#appendix-A">Appendix A</a>. Examples .............................................<a href="#page-248">248</a>
<a href="#appendix-A.1">A.1</a>. Media on Demand (Unicast) ................................<a href="#page-248">248</a>
<a href="#appendix-A.2">A.2</a>. Media on Demand Using Pipelining .........................<a href="#page-251">251</a>
<a href="#appendix-A.3">A.3</a>. Secured Media Session for On-Demand Content ..............<a href="#page-254">254</a>
<a href="#appendix-A.4">A.4</a>. Media on Demand (Unicast) ................................<a href="#page-257">257</a>
<a href="#appendix-A.5">A.5</a>. Single-Stream Container Files ............................<a href="#page-260">260</a>
<a href="#appendix-A.6">A.6</a>. Live Media Presentation Using Multicast ..................<a href="#page-263">263</a>
<a href="#appendix-A.7">A.7</a>. Capability Negotiation ...................................<a href="#page-264">264</a>
<a href="#appendix-B">Appendix B</a>. RTSP Protocol State Machine ..........................<a href="#page-265">265</a>
<a href="#appendix-B.1">B.1</a>. States ...................................................<a href="#page-266">266</a>
<a href="#appendix-B.2">B.2</a>. State Variables ..........................................<a href="#page-266">266</a>
<a href="#appendix-B.3">B.3</a>. Abbreviations ............................................<a href="#page-266">266</a>
<a href="#appendix-B.4">B.4</a>. State Tables .............................................<a href="#page-267">267</a>
<a href="#appendix-C">Appendix C</a>. Media-Transport Alternatives .........................<a href="#page-272">272</a>
<a href="#appendix-C.1">C.1</a>. RTP ......................................................<a href="#page-272">272</a>
<a href="#appendix-C.1.1">C.1.1</a>. AVP ..................................................<a href="#page-272">272</a>
<a href="#appendix-C.1.2">C.1.2</a>. AVP/UDP ..............................................<a href="#page-273">273</a>
<a href="#appendix-C.1.3">C.1.3</a>. AVPF/UDP .............................................<a href="#page-274">274</a>
<a href="#appendix-C.1.4">C.1.4</a>. SAVP/UDP .............................................<a href="#page-275">275</a>
<a href="#appendix-C.1.5">C.1.5</a>. SAVPF/UDP ............................................<a href="#page-277">277</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<a href="#appendix-C.1.6">C.1.6</a>. RTCP Usage with RTSP .................................<a href="#page-278">278</a>
<a href="#appendix-C.2">C.2</a>. RTP over TCP .............................................<a href="#page-279">279</a>
<a href="#appendix-C.2.1">C.2.1</a>. Interleaved RTP over TCP .............................<a href="#page-280">280</a>
<a href="#appendix-C.2.2">C.2.2</a>. RTP over Independent TCP .............................<a href="#page-280">280</a>
<a href="#appendix-C.3">C.3</a>. Handling Media-Clock Time Jumps in the RTP Media Layer ...<a href="#page-284">284</a>
<a href="#appendix-C.4">C.4</a>. Handling RTP Timestamps after PAUSE ......................<a href="#page-287">287</a>
<a href="#appendix-C.5">C.5</a>. RTSP/RTP Integration ....................................<a href="#page-290">290</a>
<a href="#appendix-C.6">C.6</a>. Scaling with RTP .........................................<a href="#page-290">290</a>
<a href="#appendix-C.7">C.7</a>. Maintaining NPT Synchronization with RTP Timestamps ......<a href="#page-290">290</a>
<a href="#appendix-C.8">C.8</a>. Continuous Audio .........................................<a href="#page-290">290</a>
<a href="#appendix-C.9">C.9</a>. Multiple Sources in an RTP Session .......................<a href="#page-290">290</a>
C.10. Usage of SSRCs and the RTCP BYE Message during an RTSP
Session .................................................<a href="#page-290">290</a>
<a href="#appendix-C.11">C.11</a>. Future Additions ........................................<a href="#page-291">291</a>
<a href="#appendix-D">Appendix D</a>. Use of SDP for RTSP Session Descriptions .............<a href="#page-292">292</a>
<a href="#appendix-D.1">D.1</a>. Definitions .............................................<a href="#page-292">292</a>
<a href="#appendix-D.1.1">D.1.1</a>. Control URI ..........................................<a href="#page-292">292</a>
<a href="#appendix-D.1.2">D.1.2</a>. Media Streams ........................................<a href="#page-294">294</a>
<a href="#appendix-D.1.3">D.1.3</a>. Payload Type(s) ......................................<a href="#page-294">294</a>
<a href="#appendix-D.1.4">D.1.4</a>. Format-Specific Parameters ...........................<a href="#page-294">294</a>
<a href="#appendix-D.1.5">D.1.5</a>. Directionality of Media Stream .......................<a href="#page-295">295</a>
<a href="#appendix-D.1.6">D.1.6</a>. Range of Presentation ................................<a href="#page-295">295</a>
<a href="#appendix-D.1.7">D.1.7</a>. Time of Availability .................................<a href="#page-296">296</a>
<a href="#appendix-D.1.8">D.1.8</a>. Connection Information ...............................<a href="#page-297">297</a>
<a href="#appendix-D.1.9">D.1.9</a>. Message Body Tag .....................................<a href="#page-297">297</a>
<a href="#appendix-D.2">D.2</a>. Aggregate Control Not Available ..........................<a href="#page-298">298</a>
<a href="#appendix-D.3">D.3</a>. Aggregate Control Available ..............................<a href="#page-298">298</a>
<a href="#appendix-D.4">D.4</a>. Grouping of Media Lines in SDP ...........................<a href="#page-299">299</a>
<a href="#appendix-D.5">D.5</a>. RTSP External SDP Delivery ...............................<a href="#page-300">300</a>
<a href="#appendix-E">Appendix E</a>. RTSP Use Cases .......................................<a href="#page-300">300</a>
<a href="#appendix-E.1">E.1</a>. On-Demand Playback of Stored Content .....................<a href="#page-300">300</a>
<a href="#appendix-E.2">E.2</a>. Unicast Distribution of Live Content .....................<a href="#page-302">302</a>
<a href="#appendix-E.3">E.3</a>. On-Demand Playback Using Multicast .......................<a href="#page-303">303</a>
<a href="#appendix-E.4">E.4</a>. Inviting an RTSP Server into a Conference ................<a href="#page-303">303</a>
<a href="#appendix-E.5">E.5</a>. Live Content Using Multicast .............................<a href="#page-304">304</a>
<a href="#appendix-F">Appendix F</a>. Text Format for Parameters ...........................<a href="#page-305">305</a>
<a href="#appendix-G">Appendix G</a>. Requirements for Unreliable Transport of RTSP ........<a href="#page-305">305</a>
<a href="#appendix-H">Appendix H</a>. Backwards-Compatibility Considerations ...............<a href="#page-306">306</a>
<a href="#appendix-H.1">H.1</a>. Play Request in Play State ...............................<a href="#page-307">307</a>
<a href="#appendix-H.2">H.2</a>. Using Persistent Connections .............................<a href="#page-307">307</a>
<a href="#appendix-I">Appendix I</a>. Changes ..............................................<a href="#page-307">307</a>
<a href="#appendix-I.1">I.1</a>. Brief Overview ...........................................<a href="#page-308">308</a>
<a href="#appendix-I.2">I.2</a>. Detailed List of Changes .................................<a href="#page-309">309</a>
Acknowledgements .................................................<a href="#page-316">316</a>
Contributors ....................................................<a href="#page-317">317</a>
Authors' Addresses ...............................................<a href="#page-318">318</a>
<span class="grey">Schulzrinne, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This memo defines version 2.0 of the Real-Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-layer protocol for the setup
and control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers.
The protocol operates between RTSP 2.0 clients and servers, but it
also supports the use of proxies placed between clients and servers.
Clients can request information about streaming media from servers by
asking for a description of the media or use media description
provided externally. The media delivery protocol is used to
establish the media streams described by the media description.
Clients can then request to play out the media, pause it, or stop it
completely. The requested media can consist of multiple audio and
video streams that are delivered as time-synchronized streams from
servers to clients.
RTSP 2.0 is a replacement of RTSP 1.0 [<a href="./rfc2326" title=""Real Time Streaming Protocol (RTSP)"">RFC2326</a>] and this document
obsoletes that specification. This protocol is based on RTSP 1.0 but
is not backwards compatible other than in the basic version
negotiation mechanism. The changes between the two documents are
listed in <a href="#appendix-I">Appendix I</a>. There are many reasons why RTSP 2.0 can't be
backwards compatible with RTSP 1.0; some of the main ones are as
follows:
o Most headers that needed to be extensible did not define the
allowed syntax, preventing safe deployment of extensions;
o the changed behavior of the PLAY method when received in Play
state;
o the changed behavior of the extensibility model and its mechanism;
and
o the change of syntax for some headers.
There are so many small updates that changing versions became
necessary to enable clarification and consistent behavior. Anyone
implementing RTSP for a new use case in which they have not installed
RTSP 1.0 should only implement RTSP 2.0 to avoid having to deal with
RTSP 1.0 inconsistencies.
This document is structured as follows. It begins with an overview
of the protocol operations and its functions in an informal way.
Then, a set of definitions of terms used and document conventions is
<span class="grey">Schulzrinne, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
introduced. These are followed by the actual RTSP 2.0 core protocol
specification. The appendices describe and define some
functionalities that are not part of the core RTSP specification, but
which are still important to enable some usages. Among them, the RTP
usage is defined in <a href="#appendix-C">Appendix C</a>, the Session Description Protocol
(SDP) usage with RTSP is defined in <a href="#appendix-D">Appendix D</a>, and the "text/
parameters" file format <a href="#appendix-F">Appendix F</a>, are three normative specification
appendices. Other appendices include a number of informational parts
discussing the changes, use cases, different considerations or
motivations.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Protocol Overview</span>
This section provides an informative overview of the different
mechanisms in the RTSP 2.0 protocol to give the reader a high-level
understanding before getting into all the specific details. In case
of conflict with this description and the later sections, the later
sections take precedence. For more information about use cases
considered for RTSP, see <a href="#appendix-E">Appendix E</a>.
RTSP 2.0 is a bidirectional request and response protocol that first
establishes a context including content resources (the media) and
then controls the delivery of these content resources from the
provider to the consumer. RTSP has three fundamental parts: Session
Establishment, Media Delivery Control, and an extensibility model
described below. The protocol is based on some assumptions about
existing functionality to provide a complete solution for client-
controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may
contain a binary message body. An RTSP request starts with a method
line that identifies the method, the protocol, and version and the
resource on which to act. The resource is identified by a URI and
the hostname part of the URI is used by RTSP client to resolve the
IPv4 or IPv6 address of the RTSP server. Following the method line
are a number of RTSP headers. These lines are ended by two
consecutive carriage return line feed (CRLF) character pairs. The
message body, if present, follows the two CRLF character pairs, and
the body's length is described by a message header. RTSP responses
are similar, but they start with a response line with the protocol
and version followed by a status code and a reason phrase. RTSP
messages are sent over a reliable transport protocol between the
client and server. RTSP 2.0 requires clients and servers to
implement TCP and TLS over TCP as mandatory transports for RTSP
messages.
<span class="grey">Schulzrinne, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Presentation Description</span>
RTSP exists to provide access to multimedia presentations and content
but tries to be agnostic about the media type or the actual media
delivery protocol that is used. To enable a client to implement a
complete system, an RTSP-external mechanism for describing the
presentation and the delivery protocol(s) is used. RTSP assumes that
this description is either delivered completely out of band or as a
data object in the response to a client's request using the DESCRIBE
method (<a href="#section-13.2">Section 13.2</a>).
Parameters that commonly have to be included in the presentation
description are the following:
o The number of media streams;
o the resource identifier for each media stream/resource that is to
be controlled by RTSP;
o the protocol that will be used to deliver each media stream;
o the transport protocol parameters that are not negotiated or vary
with each client;
o the media-encoding information enabling a client to correctly
decode the media upon reception; and
o an aggregate control resource identifier.
RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
resources and aggregates under common control (see <a href="#section-4.2">Section 4.2</a>).
This specification describes in <a href="#appendix-D">Appendix D</a> how one uses SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>]
for describing the presentation.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Session Establishment</span>
The RTSP client can request the establishment of an RTSP session
after having used the presentation description to determine which
media streams are available, which media delivery protocol is used,
and the resource identifiers of the media streams. The RTSP session
is a common context between the client and the server that consists
of one or more media resources that are to be under common media
delivery control.
The client creates an RTSP session by sending a request using the
SETUP method (<a href="#section-13.3">Section 13.3</a>) to the server. In the Transport header
(<a href="#section-18.54">Section 18.54</a>) of the SETUP request, the client also includes all
<span class="grey">Schulzrinne, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
the transport parameters necessary to enable the media delivery
protocol to function. This includes parameters that are
preestablished by the presentation description but necessary for any
middlebox to correctly handle the media delivery protocols. The
Transport header in a request may contain multiple alternatives for
media delivery in a prioritized list, which the server can select
from. These alternatives are typically based on information in the
presentation description.
When receiving a SETUP request, the server determines if the media
resource is available and if one or more of the of the transport
parameter specifications are acceptable. If that is successful, an
RTSP session context is created and the relevant parameters and state
is stored. An identifier is created for the RTSP session and
included in the response in the Session header (<a href="#section-18.49">Section 18.49</a>). The
SETUP response includes a Transport header that specifies which of
the alternatives has been selected and relevant parameters.
A SETUP request that references an existing RTSP session but
identifies a new media resource is a request to add that media
resource under common control with the already-present media
resources in an aggregated session. A client can expect this to work
for all media resources under RTSP control within a multimedia
content container. However, a server will likely refuse to aggregate
resources from different content containers. Even if an RTSP session
contains only a single media stream, the RTSP session can be
referenced by the aggregate control URI.
To avoid an extra round trip in the session establishment of
aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e.,
the client can send multiple requests back-to-back without waiting
first for the completion of any of them. The client uses a client-
selected identifier in the Pipelined-Requests header (<a href="#section-18.33">Section 18.33</a>)
to instruct the server to bind multiple requests together as if they
included the session identifier.
The SETUP response also provides additional information about the
established sessions in a couple of different headers. The Media-
Properties header (<a href="#section-18.29">Section 18.29</a>) includes a number of properties
that apply for the aggregate that is valuable when doing media
delivery control and configuring user interface. The Accept-Ranges
header (<a href="#section-18.5">Section 18.5</a>) informs the client about range formats that the
server supports for these media resources. The Media-Range header
(<a href="#section-18.30">Section 18.30</a>) informs the client about the time range of the media
currently available.
<span class="grey">Schulzrinne, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Media Delivery Control</span>
After having established an RTSP session, the client can start
controlling the media delivery. The basic operations are "begin
playback", using the PLAY method (<a href="#section-13.4">Section 13.4</a>) and "suspend (pause)
playback" by using the PAUSE method (<a href="#section-13.6">Section 13.6</a>). PLAY also allows
for choosing the starting media position from which the server should
deliver the media. The positioning is done by using the Range header
(<a href="#section-18.40">Section 18.40</a>) that supports several different time formats: Normal
Play Time (NPT) (<a href="#section-4.4.2">Section 4.4.2</a>), Society of Motion Picture and
Television Engineers (SMPTE) Timestamps (<a href="#section-4.4.1">Section 4.4.1</a>), and absolute
time (<a href="#section-4.4.3">Section 4.4.3</a>). The Range header also allows the client to
specify a position where delivery should end, thus allowing a
specific interval to be delivered.
The support for positioning/searching within media content depends on
the content's media properties. Content exists in a number of
different types, such as on-demand, live, and live with simultaneous
recording. Even within these categories, there are differences in
how the content is generated and distributed, which affect how it can
be accessed for playback. The properties applicable for the RTSP
session are provided by the server in the SETUP response using the
Media-Properties header (<a href="#section-18.29">Section 18.29</a>). These are expressed using
one or several independent attributes. A first attribute is Random-
Access, which indicates whether positioning is possible, and with
what granularity. Another aspect is whether the content will change
during the lifetime of the session. While on-demand content will be
provided in full from the beginning, a live stream being recorded
results in the length of the accessible content growing as the
session goes on. There also exists content that is dynamically built
by a protocol other than RTSP and, thus, also changes in steps during
the session, but maybe not continuously. Furthermore, when content
is recorded, there are cases where the complete content is not
maintained, but, for example, only the last hour. All of these
properties result in the need for mechanisms that will be discussed
below.
When the client accesses on-demand content that allows random access,
the client can issue the PLAY request for any point in the content
between the start and the end. The server will deliver media from
the closest random access point prior to the requested point and
indicate that in its PLAY response. If the client issues a PAUSE,
the delivery will be halted and the point at which the server stopped
will be reported back in the response. The client can later resume
by sending a PLAY request without a Range header. When the server is
about to complete the PLAY request by delivering the end of the
content or the requested range, the server will send a PLAY_NOTIFY
request (<a href="#section-13.5">Section 13.5</a>) indicating this.
<span class="grey">Schulzrinne, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
When playing live content with no extra functions, such as recording,
the client will receive the live media from the server after having
sent a PLAY request. Seeking in such content is not possible as the
server does not store it, but only forwards it from the source of the
session. Thus, delivery continues until the client sends a PAUSE
request, tears down the session, or the content ends.
For live sessions that are being recorded, the client will need to
keep track of how the recording progresses. Upon session
establishment, the client will learn the current duration of the
recording from the Media-Range header. Because the recording is
ongoing, the content grows in direct relation to the time passed.
Therefore, each server's response to a PLAY request will contain the
current Media-Range header. The server should also regularly send
(approximately every 5 minutes) the current media range in a
PLAY_NOTIFY request (<a href="#section-13.5.2">Section 13.5.2</a>). If the live transmission ends,
the server must send a PLAY_NOTIFY request with the updated Media-
Properties indicating that the content stopped being a recorded live
session and instead became on-demand content; the request also
contains the final media range. While the live delivery continues,
the client can request to play the current live point by using the
NPT timescale symbol "now", or it can request a specific point in the
available content by an explicit range request for that point. If
the requested point is outside of the available interval, the server
will adjust the position to the closest available point, i.e., either
at the beginning or the end.
A special case of recording is that where the recording is not
retained longer than a specific time period; thus, as the live
delivery continues, the client can access any media within a moving
window that covers, for example, "now" to "now" minus 1 hour. A
client that pauses on a specific point within the content may not be
able to retrieve the content anymore. If the client waits too long
before resuming the pause point, the content may no longer be
available. In this case, the pause point will be adjusted to the
closest point in the available media.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Session Parameter Manipulations</span>
A session may have additional state or functionality that affects how
the server or client treats the session or content, how it functions,
or feedback on how well the session works. Such extensions are not
defined in this specification, but they may be covered in various
extensions. RTSP has two methods for retrieving and setting
parameter values on either the client or the server: GET_PARAMETER
(<a href="#section-13.8">Section 13.8</a>) and SET_PARAMETER (<a href="#section-13.9">Section 13.9</a>). These methods carry
the parameters in a message body of the appropriate format. One can
also use headers to query state with the GET_PARAMETER method. As an
<span class="grey">Schulzrinne, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
example, clients needing to know the current media range for a time-
progressing session can use the GET_PARAMETER method and include the
media range. Furthermore, synchronization information can be
requested by using a combination of RTP-Info (<a href="#section-18.45">Section 18.45</a>) and
Range (<a href="#section-18.40">Section 18.40</a>).
RTSP 2.0 does not have a strong mechanism for negotiating the headers
or parameters and their formats. However, responses will indicate
request-headers or parameters that are not supported. A priori
determination of what features are available needs to be done through
out-of-band mechanisms, like the session description, or through the
usage of feature tags (<a href="#section-4.5">Section 4.5</a>).
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Media Delivery</span>
This document specifies how media is delivered with RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]
over UDP [<a href="./rfc768" title=""User Datagram Protocol"">RFC768</a>], TCP [<a href="./rfc793" title=""Transmission Control Protocol"">RFC793</a>], or the RTSP connection. Additional
protocols may be specified in the future as needed.
The usage of RTP as a media delivery protocol requires some
additional information to function well. The PLAY response contains
information to enable reliable and timely delivery of how a client
should synchronize different sources in the different RTP sessions.
It also provides a mapping between RTP timestamps and the content-
time scale. When the server wants to notify the client about the
completion of the media delivery, it sends a PLAY_NOTIFY request to
the client. The PLAY_NOTIFY request includes information about the
stream end, including the last RTP sequence number for each stream,
thus enabling the client to empty the buffer smoothly.
<span class="h4"><a class="selflink" id="section-2.5.1" href="#section-2.5.1">2.5.1</a>. Media Delivery Manipulations</span>
The basic playback functionality of RTSP enables delivery of a range
of requested content to the client at the pace intended by the
content's creator. However, RTSP can also manipulate the delivery to
the client in two ways.
Scale: The ratio of media-content time delivered per unit of
playback time.
Speed: The ratio of playback time delivered per unit of wallclock
time.
Both affect the media delivery per time unit. However, they
manipulate two independent timescales and the effects are possible to
combine.
<span class="grey">Schulzrinne, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Scale (<a href="#section-18.46">Section 18.46</a>) is used for fast-forward or slow-motion control
as it changes the amount of content timescale that should be played
back per time unit. Scale > 1.0, means fast forward, e.g., scale =
2.0 results in that 2 seconds of content being played back every
second of playback. Scale = 1.0 is the default value that is used if
no scale is specified, i.e., playback at the content's original rate.
Scale values between 0 and 1.0 provide for slow motion. Scale can be
negative to allow for reverse playback in either regular pace
(scale = -1.0), fast backwards (scale < -1.0), or slow-motion
backwards (-1.0 < scale < 0). Scale = 0 would be equal to pause and
is not allowed.
In most cases, the realization of scale means server-side
manipulation of the media to ensure that the client can actually play
it back. The nature of these media manipulations and when they are
needed is highly media-type dependent. Let's consider two common
media types, audio and video.
It is very difficult to modify the playback rate of audio.
Typically, no more than a factor of two is possible while maintaining
intelligibility by changing the pitch and rate of speech. Music goes
out of tune if one tries to manipulate the playback rate by
resampling it. This is a well-known problem, and audio is commonly
muted or played back in short segments with skips to keep up with the
current playback point.
For video, it is possible to manipulate the frame rate, although the
rendering capabilities are often limited to certain frame rates.
Also, the allowed bitrates in decoding, the structure used in the
encoding, and the dependency between frames and other capabilities of
the rendering device limits the possible manipulations. Therefore,
the basic fast-forward capabilities often are implemented by
selecting certain subsets of frames.
Due to the media restrictions, the possible scale values are commonly
restricted to the set of realizable scale ratios. To enable the
clients to select from the possible scale values, RTSP can signal the
supported scale ratios for the content. To support aggregated or
dynamic content, where this may change during the ongoing session and
dependent on the location within the content, a mechanism for
updating the media properties and the scale factor currently in use,
exists.
Speed (<a href="#section-18.50">Section 18.50</a>) affects how much of the playback timeline is
delivered in a given wallclock period. The default is Speed = 1
which means to deliver at the same rate the media is consumed.
Speed > 1 means that the receiver will get content faster than it
regularly would consume it. Speed < 1 means that delivery is slower
<span class="grey">Schulzrinne, et al. Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
than the regular media rate. Speed values of 0 or lower have no
meaning and are not allowed. This mechanism enables two general
functionalities. One is client-side scale operations, i.e., the
client receives all the frames and makes the adjustment to the
playback locally. The second is delivery control for the buffering
of media. By specifying a speed over 1.0, the client can build up
the amount of playback time it has present in its buffers to a level
that is sufficient for its needs.
A naive implementation of Speed would only affect the transmission
schedule of the media and has a clear impact on the needed bandwidth.
This would result in the data rate being proportional to the speed
factor. Speed = 1.5, i.e., 50% faster than normal delivery, would
result in a 50% increase in the data-transport rate. Whether or not
that can be supported depends solely on the underlying network path.
Scale may also have some impact on the required bandwidth due to the
manipulation of the content in the new playback schedule. An example
is fast forward where only the independently decodable intra-frames
are included in the media stream. This usage of solely intra-frames
increases the data rate significantly compared to a normal sequence
with the same number of frames, where most frames are encoded using
prediction.
This potential increase of the data rate needs to be handled by the
media sender. The client has requested that the media be delivered
in a specific way, which should be honored. However, the media
sender cannot ignore if the network path between the sender and the
receiver can't handle the resulting media stream. In that case, the
media stream needs to be adapted to fit the available resources of
the path. This can result in a reduced media quality.
The need for bitrate adaptation becomes especially problematic in
connection with the Speed semantics. If the goal is to fill up the
buffer, the client may not want to do that at the cost of reduced
quality. If the client wants to make local playout changes, then it
may actually require that the requested speed be honored. To resolve
this issue, Speed uses a range so that both cases can be supported.
The server is requested to use the highest possible speed value
within the range, which is compatible with the available bandwidth.
As long as the server can maintain a speed value within the range, it
shall not change the media quality, but instead modify the actual
delivery rate in response to available bandwidth and reflect this in
the Speed value in the response. However, if this is not possible,
the server should instead modify the media quality to respect the
lowest speed value and the available bandwidth.
<span class="grey">Schulzrinne, et al. Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
This functionality enables the local scaling implementation to use a
tight range, or even a range where the lower bound equals the upper
bound, to identify that it requires the server to deliver the
requested amount of media time per delivery time, independent of how
much it needs to adapt the media quality to fit within the available
path bandwidth. For buffer filling, it is suitable to use a range
with a reasonable span and with a lower bound at the nominal media
rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the
buffer, it can specify an upper bound that is below 1.0 to force the
server to deliver slower than the nominal media rate.
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Session Maintenance and Termination</span>
The session context that has been established is kept alive by having
the client show liveness. This is done in two main ways:
o Media-transport protocol keep-alive. RTP Control Protocol (RTCP)
may be used when using RTP.
o Any RTSP request referencing the session context.
<a href="#section-10.5">Section 10.5</a> discusses the methods for showing liveness in more
depth. If the client fails to show liveness for more than the
established session timeout value (normally 60 seconds), the server
may terminate the context. Other values may be selected by the
server through the inclusion of the timeout parameter in the session
header.
The session context is normally terminated by the client sending a
TEARDOWN request (<a href="#section-13.7">Section 13.7</a>) to the server referencing the
aggregated control URI. An individual media resource can be removed
from a session context by a TEARDOWN request referencing that
particular media resource. If all media resources are removed from a
session context, the session context is terminated.
A client may keep the session alive indefinitely if allowed by the
server; however, a client is advised to release the session context
when an extended period of time without media delivery activity has
passed. The client can re-establish the session context if required
later. What constitutes an extended period of time is dependent on
the client, server, and their usage. It is recommended that the
client terminate the session before ten times the session timeout
value has passed. A server may terminate the session after one
session timeout period without any client activity beyond keep-alive.
When a server terminates the session context, it does so by sending a
TEARDOWN request indicating the reason.
<span class="grey">Schulzrinne, et al. Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
A server can also request that the client tear down the session and
re-establish it at an alternative server, as may be needed for
maintenance. This is done by using the REDIRECT method
(<a href="#section-13.10">Section 13.10</a>). The Terminate-Reason header (<a href="#section-18.52">Section 18.52</a>) is used
to indicate when and why. The Location header indicates where it
should connect if there is an alternative server available. When the
deadline expires, the server simply stops providing the service. To
achieve a clean closure, the client needs to initiate session
termination prior to the deadline. In case the server has no other
server to redirect to, and it wants to close the session for
maintenance, it shall use the TEARDOWN method with a Terminate-Reason
header.
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. Extending RTSP</span>
RTSP is quite a versatile protocol that supports extensions in many
different directions. Even this core specification contains several
blocks of functionality that are optional to implement. The use case
and need for the protocol deployment should determine what parts are
implemented. Allowing for extensions makes it possible for RTSP to
address additional use cases. However, extensions will affect the
interoperability of the protocol; therefore, it is important that
they can be added in a structured way.
The client can learn the capability of a server by using the OPTIONS
method (<a href="#section-13.1">Section 13.1</a>) and the Supported header (<a href="#section-18.51">Section 18.51</a>). It
can also try and possibly fail using new methods or require that
particular features be supported using the Require (<a href="#section-18.43">Section 18.43</a>) or
Proxy-Require (<a href="#section-18.37">Section 18.37</a>) header.
The RTSP, in itself, can be extended in three ways, listed here in
increasing order of the magnitude of changes supported:
o Existing methods can be extended with new parameters, for example,
headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgment when a
method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy-
Require headers.
o New methods can be added. If the recipient of the message does
not understand the request, it must respond with error code 501
(Not Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server must list the methods
it supports using the Public response-header.
<span class="grey">Schulzrinne, et al. Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to
change. A new version of the protocol must be registered through
a Standards Track document.
The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is
available when performing a request. For a detailed explanation of
this, see <a href="#section-11">Section 11</a>.
New media delivery protocols may be added and negotiated at session
establishment, in addition to extensions to the core protocol.
Certain types of protocol manipulations can be done through parameter
formats using SET_PARAMETER and GET_PARAMETER.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Document Conventions</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Notational Conventions</span>
All the mechanisms specified in this document are described in both
prose and the Augmented Backus-Naur form (ABNF) described in detail
in [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
Indented paragraphs are used to provide informative background and
motivation. This is intended to give readers who were not involved
with the formulation of the specification an understanding of why
things are the way they are in RTSP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The word, "unspecified" is used to indicate functionality or features
that are not defined in this specification. Such functionality
cannot be used in a standardized manner without further definition in
an extension specification to RTSP.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Terminology</span>
Aggregate control: The concept of controlling multiple streams using
a single timeline, generally one maintained by the server. A
client, for example, uses aggregate control when it issues a
single play or pause message to simultaneously control both the
audio and video in a movie. A session that is under aggregate
control is referred to as an "aggregated session".
<span class="grey">Schulzrinne, et al. Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Aggregate control URI: The URI used in an RTSP request to refer to
and control an aggregated session. It normally, but not always,
corresponds to the presentation URI specified in the session
description. See <a href="#section-13.3">Section 13.3</a> for more information.
Client: The client is the requester of media service from the media
server.
Connection: A transport-layer virtual circuit established between
two programs for the purpose of communication.
Container file: A file that may contain multiple media streams that
often constitute a presentation when played together. The concept
of a container file is not embedded in the protocol. However,
RTSP servers may offer aggregate control on the media streams
within these files.
Continuous media: Data where there is a timing relationship between
source and sink; that is, the sink needs to reproduce the timing
relationship that existed at the source. The most common examples
of continuous media are audio and motion video. Continuous media
can be real time (interactive or conversational), where there is a
"tight" timing relationship between source and sink or it can be
streaming where the relationship is less strict.
Feature tag: A tag representing a certain set of functionality,
i.e., a feature.
IRI: An Internationalized Resource Identifier is similar to a URI
but allows characters from the whole Universal Character Set
(Unicode/ISO 10646), rather than the US-ASCII only. See [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>]
for more information.
Live: A live presentation or session originates media from an event
taking place at the same time as the media delivery. Live
sessions often have an unbound or only loosely defined duration
and seek operations may not be possible.
Media initialization: The datatype- or codec-specific
initialization. This includes such things as clock rates, color
tables, etc. Any transport-independent information that is
required by a client for playback of a media stream occurs in the
media initialization phase of stream setup.
Media parameter: A parameter specific to a media type that may be
changed before or during stream delivery.
<span class="grey">Schulzrinne, et al. Standards Track [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Media server: The server providing media-delivery services for one
or more media streams. Different media streams within a
presentation may originate from different media servers. A media
server may reside on the same host or on a different host from
which the presentation is invoked.
(Media) Stream: A single media instance, e.g., an audio stream or a
video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP
packets created by a media source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in
<a href="#section-20">Section 20</a> and transmitted over a transport between RTSP agents.
A message is either a request or a response.
Message body: The information transferred as the payload of a
message (request or response). A message body consists of meta-
information in the form of message body headers and content in the
form of an arbitrary number of data octets, as described in
<a href="#section-9">Section 9</a>.
Non-aggregated control: Control of a single media stream.
Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation
description as defined below. Presentations with more than one
media stream are often handled in RTSP under aggregate control.
Presentation description: A presentation description contains
information about one or more media streams within a presentation,
such as the set of encodings, network addresses, and information
about the content. Other IETF protocols, such as SDP ([<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>]),
use the term "session" for a presentation. The presentation
description may take several different formats, including but not
limited to SDP format.
Response: An RTSP response to a request. One type of RTSP message.
If an HTTP response is meant, it is indicated explicitly.
Request: An RTSP request. One type of RTSP message. If an HTTP
request is meant, it is indicated explicitly.
Request-URI: The URI used in a request to indicate the resource on
which the request is to be performed.
<span class="grey">Schulzrinne, et al. Standards Track [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
RTSP agent: Either an RTSP client, an RTSP server, or an RTSP proxy.
In this specification, there are many capabilities that are common
to these three entities such as the capability to send requests or
receive responses. This term will be used when describing
functionality that is applicable to all three of these entities.
RTSP session: A stateful abstraction upon which the main control
methods of RTSP operate. An RTSP session is a common context; it
is created and maintained on a client's request and can be
destroyed by either the client or server. It is established by an
RTSP server upon the completion of a successful SETUP request
(when a 200 OK response is sent) and is labeled with a session
identifier at that time. The session exists until timed out by
the server or explicitly removed by a TEARDOWN request. An RTSP
session is a stateful entity; an RTSP server maintains an explicit
session state machine (see <a href="#appendix-B">Appendix B</a>) where most state
transitions are triggered by client requests. The existence of a
session implies the existence of state about the session's media
streams and their respective transport mechanisms. A given
session can have one or more media streams associated with it. An
RTSP server uses the session to aggregate control over multiple
media streams.
Origin server: The server on which a given resource resides.
Seeking: Requesting playback from a particular point in the content
time line.
Transport initialization: The negotiation of transport information
(e.g., port numbers, transport protocols) between the client and
the server.
URI: A Universal Resource Identifier; see [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]. The URIs used
in RTSP are generally URLs as they give a location for the
resource. As URLs are a subset of URIs, they will be referred to
as URIs to cover also the cases when an RTSP URI would not be a
URL.
URL: A Universal Resource Locator is a URI that identifies the
resource through its primary access mechanism rather than
identifying the resource by name or by some other attribute(s) of
that resource.
<span class="grey">Schulzrinne, et al. Standards Track [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Parameters</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. RTSP Version</span>
This specification defines version 2.0 of RTSP.
RTSP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
the sender to indicate the format of a message and its capacity for
understanding further RTSP communication rather than the features
obtained via that communication. No change is made to the version
number for the addition of message components that do not affect
communication behavior or that only add to extensible field values.
The <minor> number is incremented when the changes made to the
protocol add features that do not change the general message parsing
algorithm but that may add to the message semantics and imply
additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is
changed. The version of an RTSP message is indicated by an RTSP-
Version field in the first line of the message. Note that the major
and minor numbers MUST be treated as separate integers and that each
MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a
lower version than RTSP/2.13, which, in turn, is lower than
RTSP/12.3. Leading zeros SHALL NOT be sent and MUST be ignored by
recipients.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. RTSP IRI and URI</span>
RTSP 2.0 defines and registers or updates three URI schemes "rtsp",
"rtsps", and "rtspu". The usage of the last, "rtspu", is unspecified
in RTSP 2.0 and is defined here to register the URI scheme that was
defined in RTSP 1.0. The "rtspu" scheme indicates unspecified
transport of the RTSP messages over unreliable transport means (UDP
in RTSP 1.0). An RTSP server MUST respond with an error code
indicating the "rtspu" scheme is not implemented (501) to a request
that carries a "rtspu" URI scheme.
The details of the syntax of "rtsp" and "rtsps" URIs have been
changed from RTSP 1.0. These changes include the addition of:
o Support for an IPv6 literal in the host part and future IP
literals through a mechanism defined in [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>].
o A new relative format to use in the RTSP elements that is not
required to start with "/".
<span class="grey">Schulzrinne, et al. Standards Track [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Neither should have any significant impact on interoperability. If
IPv6 literals are needed in the RTSP URI, then that RTSP server must
be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol.
If an RTSP 1.0 client attempts to process the URI, the URI will not
match the allowed syntax, it will be considered invalid, and
processing will be stopped. This is clearly a failure to reach the
resource; however, it is not a signification issue as RTSP 2.0
support was needed anyway in both server and client. Thus, failure
will only occur in a later step when there is an RTSP version
mismatch between client and server. The second change will only
occur inside RTSP message headers, as the Request-URI must be an
absolute URI. Thus, such usages will only occur after an agent has
accepted and started processing RTSP 2.0 messages, and an agent using
RTSP 1.0 only will not be required to parse such types of relative
URIs.
This specification also defines the format of RTSP IRIs [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>]
that can be used as RTSP resource identifiers and locators on web
pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The
RTSP IRI format MUST use the rules and transformation for IRIs to
URIs, as defined in [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>]. This allows a URI that matches the
RTSP 2.0 specification, and so is suitable for use in a request, to
be created from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] and [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>]:
o An absolute URI requires the authority part; i.e., a host identity
MUST be provided.
o Parameters in the path element are prefixed with the reserved
separator ";".
The "scheme" and "host" parts of all URIs [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] and IRIs
[<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>] are case insensitive. All other parts of RTSP URIs and
IRIs are case sensitive, and they MUST NOT be case mapped.
The fragment identifier is used as defined in Sections <a href="#section-3.5">3.5</a> and <a href="#section-4.3">4.3</a> of
[<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>], i.e., the fragment is to be stripped from the IRI by the
requester and not included in the Request-URI. The user agent needs
to interpret the value of the fragment based on the media type the
request relates to; i.e., the media type indicated in Content-Type
header in the response to a DESCRIBE request.
The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requester's
perspective, an opaque string and needs to be handled as such.
<span class="grey">Schulzrinne, et al. Standards Track [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Please note that relative URIs with queries are difficult to handle
due to the relative URI handling rules of <a href="./rfc3986">RFC 3986</a>. Any change of
the path element using a relative URI results in the stripping of the
query, which means the relative part needs to contain the query.
The URI scheme "rtsp" requires that commands be issued via a reliable
protocol (within the Internet, TCP), while the scheme "rtsps"
identifies a reliable transport using secure transport (TLS
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]); see <a href="#section-19">Section 19</a>.
For the scheme "rtsp", if no port number is provided in the authority
part of the URI, the port number 554 MUST be used. For the scheme
"rtsps", if no port number is provided in the authority part of the
URI port number, the TCP port 322 MUST be used.
A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs
[<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]. URIs may refer to a stream or an aggregate of streams;
i.e., a presentation. Accordingly, requests described in <a href="#section-13">Section 13</a>
can apply to either the whole presentation or an individual stream
within the presentation. Note that some request methods can only be
applied to streams, not presentations, and vice versa.
For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com.
Also, the RTSP URI:
rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio
and video streams, but could also be something else, such as a random
media redirector.
This does not imply a standard way to reference streams in URIs.
The presentation description defines the hierarchical
relationships in the presentation and the URIs for the individual
streams. A presentation description may name a stream "a.mov" and
the whole presentation "b.mov".
The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server.
<span class="grey">Schulzrinne, et al. Standards Track [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the
scheme in the URI.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Session Identifiers</span>
Session identifiers are strings of a length between 8-128 characters.
A session identifier MUST be generated using methods that make it
cryptographically random (see [<a href="./rfc4086" title=""Randomness Requirements for Security"">RFC4086</a>]). It is RECOMMENDED that a
session identifier contain 128 bits of entropy, i.e., approximately
22 characters from a high-quality generator (see <a href="#section-21">Section 21</a>).
However, note that the session identifier does not provide any
security against session hijacking unless it is kept confidential by
the client, server, and trusted proxies.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Media-Time Formats</span>
RTSP currently supports three different media-time formats defined
below. Additional time formats may be specified in the future.
These time formats can be used with the Range header (<a href="#section-18.40">Section 18.40</a>)
to request playback and specify at which media position protocol
requests actually will or have taken place. They are also used in
description of the media's properties using the Media-Range header
(<a href="#section-18.30">Section 18.30</a>). The unqualified format identifier is used on its
own in Accept-Ranges header (<a href="#section-18.5">Section 18.5</a>) to declare supported time
formats and also in the Range header (<a href="#section-18.40">Section 18.40</a>) to request the
time format used in the response.
<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>. SMPTE-Relative Timestamps</span>
A timestamp may use a format derived from a Society of Motion Picture
and Television Engineers (SMPTE) specification and expresses time
offsets anchored at the start of the media clip. Relative timestamps
are expressed as SMPTE time codes [<a href="#ref-SMPTE-TC" title=""ST 12-1:2008 For Television -- Time and Control Code"">SMPTE-TC</a>] for frame-level access
accuracy. The time code has the format:
hours:minutes:seconds:frames.subframes
with the origin at the start of the clip. The default SMPTE format
is "SMPTE 30 drop" format, with a frame rate of 29.97 frames per
second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
through the use of "smpte-type". For SMPTE 30, the "frames" field in
the time value can assume the values 0 through 29. The difference
between 30 and 29.97 frames per second is handled by dropping the
first two frame indices (values 00 and 01) of every minute, except
every tenth minute. If the frame and the subframe values are zero,
they may be omitted. Subframes are measured in hundredths of a
frame.
<span class="grey">Schulzrinne, et al. Standards Track [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Examples:
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01
<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Normal Play Time</span>
Normal Play Time (NPT) indicates the stream-absolute position
relative to the beginning of the presentation. The timestamp
consists of two parts: The mandatory first part may be expressed in
either seconds only or in hours, minutes, and seconds. The optional
second part consists of a decimal point and decimal figures and
indicates fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined.
The special constant "now" is defined as the current instant of a
live event. It MAY only be used for live events and MUST NOT be used
for on-demand (i.e., non-live) content.
NPT is defined as in Digital Storage Media Command and Control
(DSMb;CC) [<a href="#ref-ISO.13818-6.1995">ISO.13818-6.1995</a>]:
Intuitively, NPT is the clock the viewer associates with a
program. It is often digitally displayed on a DVD player. NPT
advances normally when in normal play mode (scale = 1), advances
at a faster rate when in fast-scan forward (high positive scale
ratio), decrements when in scan reverse (negative scale ratio) and
is fixed in pause mode. NPT is (logically) equivalent to SMPTE
time codes.
Examples:
npt=123.45-125
npt=12:05:35.3-
npt=now-
<span class="grey">Schulzrinne, et al. Standards Track [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
The syntax is based on ISO 8601 [<a href="#ref-ISO.8601.2000">ISO.8601.2000</a>] and expresses the
time elapsed since presentation start, with two different notations
allowed:
o The npt-hhmmss notation uses an ISO 8601 extended complete
representation of the time of the day format (Section 5.3.1.1 of
[<a href="#ref-ISO.8601.2000">ISO.8601.2000</a>] ) using colons (":") as separators between hours,
minutes, and seconds (hh:mm:ss). The hour counter is not limited
to 0-24 hours; up to nineteen (19) hour digits are allowed.
* In accordance with the requirements of the ISO 8601 time
format, the hours, minutes, and seconds MUST all be present,
with two digits used for minutes and for seconds and with at
least two digits for hours. An NPT of 7 minutes and 0 seconds
is represented as "00:07:00", and an NPT of 392 hours, 0
minutes, and 6 seconds is represented as "392:00:06".
* RTSP 1.0 allowed NPT in the npt-hhmmss notation without any
leading zeros to ensure that implementations don't fail; for
backward compatibility, all RTSP 2.0 implementations are
REQUIRED to support receiving NPT values, hours, minutes, or
seconds, without leading zeros.
o The npt-sec notation expresses the time in seconds, using between
one and nineteen (19) digits.
Both notations allow decimal fractions of seconds as specified in
Section 5.3.1.3 of [<a href="#ref-ISO.8601.2000">ISO.8601.2000</a>], using at most nine digits, and
allowing only "." (full stop) as the decimal separator.
The npt-sec notation is optimized for automatic generation; the npt-
hhmmss notation is optimized for consumption by human readers. The
"now" constant allows clients to request to receive the live feed
rather than the stored or time-delayed version. This is needed since
neither absolute time nor zero time are appropriate for this case.
<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>. Absolute Time</span>
Absolute time is expressed using a timestamp based on ISO 8601
[<a href="#ref-ISO.8601.2000">ISO.8601.2000</a>]. The date is a complete representation of the
calendar date in basic format (YYYYMMDD) without separators (per
Section 5.2.1.1 of [<a href="#ref-ISO.8601.2000">ISO.8601.2000</a>]). The time of day is provided in
the complete representation basic format (hhmmss) as specified in
Section 5.3.1.1 of [<a href="#ref-ISO.8601.2000">ISO.8601.2000</a>], allowing decimal fractions of
seconds following <a href="#section-5.3.1.3">Section 5.3.1.3</a> requiring "." (full stop) as
decimal separator and limiting the number of digits to no more than
nine. The time expressed MUST use UTC (GMT), i.e., no time zone
offsets are allowed. The full date and time specification is the
<span class="grey">Schulzrinne, et al. Standards Track [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
eight-digit date followed by a "T" followed by the six-digit time
value, optionally followed by a full stop followed by one to nine
fractions of a second and ended by "Z", e.g., YYYYMMDDThhmmss.ssZ.
The reasons for this time format rather than using "Date and Time
on the Internet: Timestamps" [<a href="./rfc3339" title=""Date and Time on the Internet: Timestamps"">RFC3339</a>] are historic. We continue
to use the format specified in RTSP 1.0. The motivations raised
in <a href="./rfc3339">RFC 3339</a> apply to why a selection from ISO 8601 was made;
however, a different and even more restrictive selection was
applied in this case.
Below are three examples of media time formats, first, a request for
a clock format range request for a starting time of November 8, 1996
at 14 h 37 min and 20 1/4 seconds UTC playing for 10 min and 5
seconds, followed by a Media-Properties header's "Time-Limited" UTC
property for the 24th of December 2014 at 15 hours and 00 minutes,
and finally a Terminate-Reason header "time" property for the 18th of
June 2013 at 16 hours, 12 minutes, and 56 seconds:
clock=19961108T143720.25Z-19961108T144725.25Z
Time-Limited=20141224T1500Z
time=20130618T161256Z
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Feature Tags</span>
Feature tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (<a href="#section-18.43">Section 18.43</a>), Proxy-Require
(<a href="#section-18.37">Section 18.37</a>), Proxy-Supported (<a href="#section-18.38">Section 18.38</a>), Supported
(<a href="#section-18.51">Section 18.51</a>), and Unsupported (<a href="#section-18.55">Section 18.55</a>) header fields.
A feature tag definition MUST indicate which combination of clients,
servers, or proxies to which it applies.
The creator of a new RTSP feature tag should either prefix the
feature tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com") or register the new feature
tag with the Internet Assigned Numbers Authority (IANA). (See
<a href="#section-22">Section 22</a>, "IANA Considerations".)
The usage of feature tags is further described in <a href="#section-11">Section 11</a>, which
deals with capability handling.
<span class="grey">Schulzrinne, et al. Standards Track [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Message Body Tags</span>
Message body tags are opaque strings that are used to compare two
message bodies from the same resource, for example, in caches or to
optimize setup after a redirect. Message body tags can be carried in
the MTag header (see <a href="#section-18.31">Section 18.31</a>) or in SDP (see <a href="#appendix-D.1.9">Appendix D.1.9</a>).
MTag is similar to ETag in HTTP/1.1 (see <a href="./rfc2068#section-3.11">Section 3.11 of [RFC2068]</a>).
A message body tag MUST be unique across all versions of all message
bodies associated with a particular resource. A given message body
tag value MAY be used for message bodies obtained by requests on
different URIs. The use of the same message body tag value in
conjunction with message bodies obtained by requests on different
URIs does not imply the equivalence of those message bodies.
Message body tags are used in RTSP to make some methods conditional.
The methods are made conditional through the inclusion of headers;
see <a href="#section-18.24">Section 18.24</a> and <a href="#section-18.26">Section 18.26</a> for information on the If-Match
and If-None-Match headers, respectively. Note that RTSP message body
tags apply to the complete presentation, i.e., both the presentation
description and the individual media streams. Thus, message body
tags can be used to verify at setup time after a redirect that the
same session description applies to the media at the new location
using the If-Match header.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. Media Properties</span>
When an RTSP server handles media, it is important to consider the
different properties a media instance for delivery and playback can
have. This specification considers the media properties listed below
in its protocol operations. They are derived from the differences
between a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't
change during the lifetime of the RTSP session and is known at the
time of the creation of the session. It is expected that the
content of the media will not change, even if the representation,
such as encoding, or quality, may change. Generally, one can
seek, i.e., request any range, within the media.
Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is content
defined by a playlist.
<span class="grey">Schulzrinne, et al. Standards Track [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be
accessed.
Live with Recording: A live stream that is combined with a server-
side capability to store and retain the content of the live
session and allow for random access delivery within the part of
the already-recorded content. The actual behavior of the media
stream is very much dependent on the retention policy for the
media stream; either the server will be able to capture the
complete media stream or it will have a limitation in how much
will be retained. The media range will dynamically change as the
session progress. For servers with a limited amount of storage
available for recording, there will typically be a sliding window
that moves forward while new data is made available and older data
is discarded.
To cover the above usages, the following media properties with
appropriate values are specified.
<span class="h4"><a class="selflink" id="section-4.7.1" href="#section-4.7.1">4.7.1</a>. Random Access and Seeking</span>
Random access is the ability to specify and get media delivered
starting from any time (instant) within the content, an operation
called "seeking". The Media-Properties header will indicate the
general capability for a media resource to perform random access.
Random-Access: The media is seekable to any out of a large number of
points within the media. Due to media-encoding limitations, a
particular point may not be reachable, but seeking to a point
close by is enabled. A floating-point number of seconds may be
provided to express the worst-case distance between random access
points.
Beginning-Only: Seeking is only possible to the beginning of the
content.
No-Seeking: Seeking is not possible at all.
If random access is possible, as indicated by the Media-Properties
header, the actual behavior policy when seeking can be controlled
using the Seek-Style header (<a href="#section-18.47">Section 18.47</a>).
<span class="grey">Schulzrinne, et al. Standards Track [Page 33]</span><span id="page-34" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h4"><a class="selflink" id="section-4.7.2" href="#section-4.7.2">4.7.2</a>. Retention</span>
The following retention policies are used by media to limit possible
protocol operations:
Unlimited: The media will not be removed as long as the RTSP session
is in existence.
Time-Limited: The media will not be removed before the given
wallclock time. After that time, it may or may not be available
anymore.
Time-Duration: The media (on fragment or unit basis) will be
retained for the specified duration.
<span class="h4"><a class="selflink" id="section-4.7.3" href="#section-4.7.3">4.7.3</a>. Content Modifications</span>
The media content and its timeline can be of different types, e.g.
pre-produced content on demand, a live source that is being generated
as time progresses, or something that is dynamically altered or
recomposed during playback. Therefore, a media property for content
modifications is needed and the following initial values are defined:
Immutable: The content of the media will not change, even if the
representation, such as encoding or quality changes.
Dynamic: The content can change due to external methods or triggers,
such as playlists, but this will be announced by explicit updates.
Time-Progressing: As time progresses, new content will become
available. If the content is also retained, it will become longer
as everything between the start point and the point currently
being made available can be accessed. If the media server uses a
sliding-window policy for retention, the start point will also
change as time progresses.
<span class="h4"><a class="selflink" id="section-4.7.4" href="#section-4.7.4">4.7.4</a>. Supported Scale Factors</span>
A particular media content item often supports only a limited set or
range of scales when delivering the media. To enable the client to
know what values or ranges of scale operations that the whole content
or the current position supports, a media properties attribute for
this is defined that contains a list with the values or ranges that
are supported. The attribute is named "Scales". The "Scales"
attribute may be updated at any point in the content due to content
consisting of spliced pieces or content being dynamically updated by
out-of-band mechanisms.
<span class="grey">Schulzrinne, et al. Standards Track [Page 34]</span><span id="page-35" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h4"><a class="selflink" id="section-4.7.5" href="#section-4.7.5">4.7.5</a>. Mapping to the Attributes</span>
This section shows examples of how one would map the above usages to
the properties and their values.
Example of On-Demand:
Random Access: Random-Access=5.0, Content Modifications:
Immutable, Retention: Unlimited or Time-Limited.
Example of Dynamic On-Demand:
Random Access: Random-Access=3.0, Content Modifications: Dynamic,
Retention: Unlimited or Time-Limited.
Example of Live:
Random Access: No-Seeking, Content Modifications: Time-
Progressing, Retention: Time-Duration=0.0
Example of Live with Recording:
Random Access: Random-Access=3.0, Content Modifications: Time-
Progressing, Retention: Time-Duration=7200.0
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. RTSP Message</span>
RTSP is a text-based protocol that uses the ISO 10646 character set
in UTF-8 encoding per <a href="./rfc3629">RFC 3629</a> [<a href="./rfc3629" title=""UTF-8, a transformation format of ISO 10646"">RFC3629</a>]. Lines MUST be terminated
by a CRLF.
Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if used carefully, also allow easy
implementation of research prototypes in scripting languages such
as Python, PHP, Perl and TCL.
The ISO 10646 character set avoids character-set switching, but is
invisible to the application as long as US-ASCII is being used. This
is also the encoding used for text fields in RTCP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
A request contains a method, the object the method is operating upon,
and parameters to further describe the method. Methods are
idempotent unless otherwise noted. Methods are also designed to
require little or no state maintenance at the media server.
<span class="grey">Schulzrinne, et al. Standards Track [Page 35]</span><span id="page-36" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Message Types</span>
RTSP messages are either requests from client to server or from
server to client, and responses in the reverse direction. Request
(<a href="#section-7">Section 7</a>) and response (<a href="#section-8">Section 8</a>) messages use a format based on
the generic message format of <a href="./rfc5322">RFC 5322</a> [<a href="./rfc5322" title=""Internet Message Format"">RFC5322</a>] for transferring
bodies (the payload of the message). Both types of messages consist
of a start-line, zero or more header fields (also known as
"headers"), an empty line (i.e., a line with nothing preceding the
CRLF) indicating the end of the headers, and possibly the data of the
message body. The ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] below is for illustration only; the
formal message specification is presented in <a href="#section-20.2.2">Section 20.2.2</a>.
generic-message = start-line
*(rtsp-header CRLF)
CRLF
[ message-body-data ]
start-line = Request-Line / Status-Line
In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line or Status-Line is expected. In other
words, if the agent is reading the protocol stream at the beginning
of a message and receives any number of CRLFs first, it MUST ignore
all of the CRLFs.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Message Headers</span>
RTSP header fields (see <a href="#section-18">Section 18</a>) include general-header, request-
header, response-header, and message body header fields.
The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by a request-header or
response-header field, and ending with the message body header
fields.
Multiple header fields with the same field-name MAY be present in a
message if and only if the entire field-value for that header field
is defined as a comma-separated list. It MUST be possible to combine
the multiple header fields into one "field-name: field-value" pair,
without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. The
order in which header fields with the same field-name are received is
therefore significant to the interpretation of the combined field
value; thus, a proxy MUST NOT change the order of these field-values
when a message is forwarded.
<span class="grey">Schulzrinne, et al. Standards Track [Page 36]</span><span id="page-37" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Unknown message headers MUST be ignored (skipping over the header to
the next protocol element, and not causing an error) by an RTSP
server or client. An RTSP proxy MUST forward unknown message
headers. Message headers defined outside of this specification that
are required to be interpreted by the RTSP agent will need to use
feature tags (<a href="#section-4.5">Section 4.5</a>) and include them in the appropriate
Require (<a href="#section-18.43">Section 18.43</a>) or Proxy-Require (<a href="#section-18.37">Section 18.37</a>) header.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Message Body</span>
The message body (if any) of an RTSP message is used to carry further
information for a particular resource associated with the request or
response. An example of a message body is an SDP message.
The presence of a message body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see
<a href="#section-18.17">Section 18.17</a>) and Content-Type header (see <a href="#section-18.19">Section 18.19</a>). A
message body MUST NOT be included in a request or response if the
specification of the particular method (see Method Definitions
(<a href="#section-13">Section 13</a>)) does not allow sending a message body. In case a
message body is received in a message when not expected, the message
body data SHOULD be discarded. This is to allow future extensions to
define optional use of a message body.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Message Length</span>
An RTSP message that does not contain any message body is terminated
by the first empty line after the header fields (note: an empty line
is a line with nothing preceding the CRLF.). In RTSP messages that
contain message bodies, the empty line is followed by the message
body. The length of that body is determined by the value of the
Content-Length header (<a href="#section-18.17">Section 18.17</a>). The value in the header
represents the length of the message body in octets. If this header
field is not present, a value of zero is assumed, i.e., no message
body present in the message. Unlike an HTTP message, an RTSP message
MUST contain a Content-Length header whenever it contains a message
body. Note that RTSP does not support the HTTP/1.1 "chunked"
transfer coding (see <a href="./rfc7230#section-4.1">Section 4.1 of [RFC7230]</a>).
Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding
unnecessary.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. General-Header Fields</span>
General headers are headers that may be used in both requests and
responses. The general-headers are listed in Table 1:
<span class="grey">Schulzrinne, et al. Standards Track [Page 37]</span><span id="page-38" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
+--------------------+----------------+
| Header Name | Defined in |
+--------------------+----------------+
| Accept-Ranges | <a href="#section-18.5">Section 18.5</a> |
| | |
| Cache-Control | <a href="#section-18.11">Section 18.11</a> |
| | |
| Connection | <a href="#section-18.12">Section 18.12</a> |
| | |
| CSeq | <a href="#section-18.20">Section 18.20</a> |
| | |
| Date | <a href="#section-18.21">Section 18.21</a> |
| | |
| Media-Properties | <a href="#section-18.29">Section 18.29</a> |
| | |
| Media-Range | <a href="#section-18.30">Section 18.30</a> |
| | |
| Pipelined-Requests | <a href="#section-18.33">Section 18.33</a> |
| | |
| Proxy-Supported | <a href="#section-18.38">Section 18.38</a> |
| | |
| Range | <a href="#section-18.40">Section 18.40</a> |
| | |
| RTP-Info | <a href="#section-18.45">Section 18.45</a> |
| | |
| Scale | <a href="#section-18.46">Section 18.46</a> |
| | |
| Seek-Style | <a href="#section-18.47">Section 18.47</a> |
| | |
| Server | <a href="#section-18.48">Section 18.48</a> |
| | |
| Session | <a href="#section-18.49">Section 18.49</a> |
| | |
| Speed | <a href="#section-18.50">Section 18.50</a> |
| | |
| Supported | <a href="#section-18.51">Section 18.51</a> |
| | |
| Timestamp | <a href="#section-18.53">Section 18.53</a> |
| | |
| Transport | <a href="#section-18.54">Section 18.54</a> |
| | |
| User-Agent | <a href="#section-18.56">Section 18.56</a> |
| | |
| Via | <a href="#section-18.57">Section 18.57</a> |
+--------------------+----------------+
Table 1: The General Headers Used in RTSP
<span class="grey">Schulzrinne, et al. Standards Track [Page 38]</span><span id="page-39" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Request</span>
A request message uses the format outlined below regardless of the
direction of a request, whether client to server or server to client:
o Request line, containing the method to be applied to the resource,
the identifier of the resource, and the protocol version in use;
o Zero or more Header lines, which can be of the following types:
general-headers (<a href="#section-6">Section 6</a>), request-headers (<a href="#section-7.2">Section 7.2</a>), or
message body headers (<a href="#section-9.1">Section 9.1</a>);
o One empty line (CRLF) to indicate the end of the header section;
o Optionally, a message body, consisting of one or more lines. The
length of the message body in octets is indicated by the Content-
Length message header.
<span class="grey">Schulzrinne, et al. Standards Track [Page 39]</span><span id="page-40" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Request Line</span>
The request line provides the key information about the request: what
method, on what resources, and using which RTSP version. The methods
that are defined by this specification are listed in Table 2.
+---------------+----------------+
| Method | Defined in |
+---------------+----------------+
| DESCRIBE | <a href="#section-13.2">Section 13.2</a> |
| | |
| GET_PARAMETER | <a href="#section-13.8">Section 13.8</a> |
| | |
| OPTIONS | <a href="#section-13.1">Section 13.1</a> |
| | |
| PAUSE | <a href="#section-13.6">Section 13.6</a> |
| | |
| PLAY | <a href="#section-13.4">Section 13.4</a> |
| | |
| PLAY_NOTIFY | <a href="#section-13.5">Section 13.5</a> |
| | |
| REDIRECT | <a href="#section-13.10">Section 13.10</a> |
| | |
| SETUP | <a href="#section-13.3">Section 13.3</a> |
| | |
| SET_PARAMETER | <a href="#section-13.9">Section 13.9</a> |
| | |
| TEARDOWN | <a href="#section-13.7">Section 13.7</a> |
+---------------+----------------+
Table 2: The RTSP Methods
The syntax of the RTSP request line has the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>], RTSP requests identify the
resource through an absolute RTSP URI (including scheme, host, and
port) (see <a href="#section-4.2">Section 4.2</a>) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, but
clients are supposed to use the Host request-header. This is
purely needed for backward compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP.
<span class="grey">Schulzrinne, et al. Standards Track [Page 40]</span><span id="page-41" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
An asterisk "*" can be used instead of an absolute URI in the
Request-URI part to indicate that the request does not apply to a
particular resource but to the server or proxy itself, and is only
allowed when the request method does not necessarily apply to a
resource.
For example:
OPTIONS * RTSP/2.0
An OPTIONS in this form will determine the capabilities of the server
or the proxy that first receives the request. If the capability of
the specific server needs to be determined, without regard to the
capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's address.
For example:
OPTIONS rtsp://example.com RTSP/2.0
<span class="grey">Schulzrinne, et al. Standards Track [Page 41]</span><span id="page-42" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Request-Header Fields</span>
The RTSP headers in Table 3 can be included in a request, as request-
headers, to modify the specifics of the request.
+---------------------+----------------+
| Header | Defined in |
+---------------------+----------------+
| Accept | <a href="#section-18.1">Section 18.1</a> |
| | |
| Accept-Credentials | <a href="#section-18.2">Section 18.2</a> |
| | |
| Accept-Encoding | <a href="#section-18.3">Section 18.3</a> |
| | |
| Accept-Language | <a href="#section-18.4">Section 18.4</a> |
| | |
| Authorization | <a href="#section-18.8">Section 18.8</a> |
| | |
| Bandwidth | <a href="#section-18.9">Section 18.9</a> |
| | |
| Blocksize | <a href="#section-18.10">Section 18.10</a> |
| | |
| From | <a href="#section-18.23">Section 18.23</a> |
| | |
| If-Match | <a href="#section-18.24">Section 18.24</a> |
| | |
| If-Modified-Since | <a href="#section-18.25">Section 18.25</a> |
| | |
| If-None-Match | <a href="#section-18.26">Section 18.26</a> |
| | |
| Notify-Reason | <a href="#section-18.32">Section 18.32</a> |
| | |
| Proxy-Authorization | <a href="#section-18.36">Section 18.36</a> |
| | |
| Proxy-Require | <a href="#section-18.37">Section 18.37</a> |
| | |
| Referrer | <a href="#section-18.41">Section 18.41</a> |
| | |
| Request-Status | <a href="#section-18.42">Section 18.42</a> |
| | |
| Require | <a href="#section-18.43">Section 18.43</a> |
| | |
| Terminate-Reason | <a href="#section-18.52">Section 18.52</a> |
+---------------------+----------------+
Table 3: The RTSP Request-Headers
Detailed header definitions are provided in <a href="#section-18">Section 18</a>.
<span class="grey">Schulzrinne, et al. Standards Track [Page 42]</span><span id="page-43" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
New request-headers may be defined. If the receiver of the request
is required to understand the request-header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require
header to ensure the processing of the header.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Response</span>
After receiving and interpreting a request message, the recipient
responds with an RTSP response message. Normally, there is only one,
final, response. Responses using the response code class 1xx is the
only class for which there MAY be sent one or more responses prior to
the final response message.
The valid response codes and the methods they can be used with are
listed in Table 4.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Status-Line</span>
The first line of a response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence.
<RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF
<span class="h4"><a class="selflink" id="section-8.1.1" href="#section-8.1.1">8.1.1</a>. Status Code and Reason Phrase</span>
The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully
defined in <a href="#section-17">Section 17</a>. The reason phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended
for use by automata and the reason phrase is intended for the human
user. The client is not required to examine or display the reason
phrase.
The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. There are
five values for the first digit:
1xx: Informational - Request received, continuing process
2xx: Success - The action was successfully received, understood, and
accepted
3rr: Redirection - Further action needs to be taken in order to
complete the request (3rr rather than 3xx is used as 304 is
excluded; see <a href="#section-17.3">Section 17.3</a>)
<span class="grey">Schulzrinne, et al. Standards Track [Page 43]</span><span id="page-44" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid
request
The individual values of the numeric status codes defined for RTSP
2.0, and an example set of corresponding reason phrases, are
presented in Table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopted most HTTP/1.1
[<a href="./rfc2068" title=""Hypertext Transfer Protocol -- HTTP/1.1"">RFC2068</a>] status codes and then added RTSP-specific status codes
starting at x50 to avoid conflicts with future HTTP status codes that
are desirable to import into RTSP. All these codes are RTSP specific
and RTSP has its own registry separate from HTTP for status codes.
RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with an exception for unknown 3xx
codes, which MUST be treated as a 302 (Found). The reason for that
exception is that the status code 300 (Multiple Choices in HTTP) is
not defined for RTSP. A response with an unrecognized status code
MUST NOT be cached. For example, if an unrecognized status code of
431 is received by the client, it can safely assume that there was
something wrong with its request and treat the response as if it had
received a 400 status code. In such cases, user agents SHOULD
present to the user the message body returned with the response,
since that message body is likely to include human-readable
information that will explain the unusual status.
+------+---------------------------------+--------------------------+
| Code | Reason | Method |
+------+---------------------------------+--------------------------+
| 100 | Continue | all |
| | | |
| 200 | OK | all |
| | | |
| 301 | Moved Permanently | all |
| | | |
| 302 | Found | all |
| | | |
| 303 | See Other | n/a |
| | | |
| 304 | Not Modified | all |
| | | |
<span class="grey">Schulzrinne, et al. Standards Track [Page 44]</span><span id="page-45" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
| 305 | Use Proxy | all |
| | | |
| 400 | Bad Request | all |
| | | |
| 401 | Unauthorized | all |
| | | |
| 402 | Payment Required | all |
| | | |
| 403 | Forbidden | all |
| | | |
| 404 | Not Found | all |
| | | |
| 405 | Method Not Allowed | all |
| | | |
| 406 | Not Acceptable | all |
| | | |
| 407 | Proxy Authentication Required | all |
| | | |
| 408 | Request Timeout | all |
| | | |
| 410 | Gone | all |
| | | |
| 412 | Precondition Failed | DESCRIBE, SETUP |
| | | |
| 413 | Request Message Body Too Large | all |
| | | |
| 414 | Request-URI Too Long | all |
| | | |
| 415 | Unsupported Media Type | all |
| | | |
| 451 | Parameter Not Understood | SET_PARAMETER, |
| | | GET_PARAMETER |
| | | |
| 452 | reserved | n/a |
| | | |
| 453 | Not Enough Bandwidth | SETUP |
| | | |
| 454 | Session Not Found | all |
| | | |
| 455 | Method Not Valid in This State | all |
| | | |
| 456 | Header Field Not Valid for | all |
| | Resource | |
| | | |
| 457 | Invalid Range | PLAY, PAUSE |
| | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER |
| | | |
<span class="grey">Schulzrinne, et al. Standards Track [Page 45]</span><span id="page-46" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
| 459 | Aggregate Operation Not Allowed | all |
| | | |
| 460 | Only Aggregate Operation | all |
| | Allowed | |
| | | |
| 461 | Unsupported Transport | all |
| | | |
| 462 | Destination Unreachable | all |
| | | |
| 463 | Destination Prohibited | SETUP |
| | | |
| 464 | Data Transport Not Ready Yet | PLAY |
| | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | |
| 466 | Key Management Error | all |
| | | |
| 470 | Connection Authorization | all |
| | Required | |
| | | |
| 471 | Connection Credentials Not | all |
| | Accepted | |
| | | |
| 472 | Failure to Establish Secure | all |
| | Connection | |
| | | |
| 500 | Internal Server Error | all |
| | | |
| 501 | Not Implemented | all |
| | | |
| 502 | Bad Gateway | all |
| | | |
| 503 | Service Unavailable | all |
| | | |
| 504 | Gateway Timeout | all |
| | | |
| 505 | RTSP Version Not Supported | all |
| | | |
| 551 | Option Not Supported | all |
| | | |
| 553 | Proxy Unavailable | all |
+------+---------------------------------+--------------------------+
Table 4: Status Codes and Their Usage with RTSP Methods
<span class="grey">Schulzrinne, et al. Standards Track [Page 46]</span><span id="page-47" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Response Headers</span>
The response-headers allow the request recipient to pass additional
information about the response that cannot be placed in the Status-
Line. This header gives information about the server and about
further access to the resource identified by the Request-URI. All
headers currently classified as response-headers are listed in
Table 5.
+------------------------+----------------+
| Header | Defined in |
+------------------------+----------------+
| Authentication-Info | <a href="#section-18.7">Section 18.7</a> |
| | |
| Connection-Credentials | <a href="#section-18.13">Section 18.13</a> |
| | |
| Location | <a href="#section-18.28">Section 18.28</a> |
| | |
| MTag | <a href="#section-18.31">Section 18.31</a> |
| | |
| Proxy-Authenticate | <a href="#section-18.34">Section 18.34</a> |
| | |
| Public | <a href="#section-18.39">Section 18.39</a> |
| | |
| Retry-After | <a href="#section-18.44">Section 18.44</a> |
| | |
| Unsupported | <a href="#section-18.55">Section 18.55</a> |
| | |
| WWW-Authenticate | <a href="#section-18.58">Section 18.58</a> |
+------------------------+----------------+
Table 5: The RTSP Response Headers
Response-header names can be extended reliably only in combination
with a change in the protocol version. However, the usage of feature
tags in the request allows the responding party to learn the
capability of the receiver of the response. A new or experimental
header can be given the semantics of response-header if all parties
in the communication recognize them to be a response-header.
Unrecognized headers in responses MUST be ignored.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Message Body</span>
Some request and response messages include a message body, if not
otherwise restricted by the request method or response status code.
The message body consists of the content data itself (see also
<a href="#section-5.3">Section 5.3</a>).
<span class="grey">Schulzrinne, et al. Standards Track [Page 47]</span><span id="page-48" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification, can have a
message body; the purpose of the message body is defined in each
case. All 4xx and 5xx responses MAY also have a message body to
carry additional response information. Generally, a message body MAY
be attached to any RTSP 2.0 request or response, but the content of
the message body MAY be ignored by the receiver. Extensions to this
specification can specify the purpose and content of message bodies,
including requiring their inclusion.
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the message
body.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Message Body Header Fields</span>
Message body header fields define meta-information about the content
data in the message body. The message body header fields are listed
in Table 6.
+------------------+----------------+
| Header | Defined in |
+------------------+----------------+
| Allow | <a href="#section-18.6">Section 18.6</a> |
| | |
| Content-Base | <a href="#section-18.14">Section 18.14</a> |
| | |
| Content-Encoding | <a href="#section-18.15">Section 18.15</a> |
| | |
| Content-Language | <a href="#section-18.16">Section 18.16</a> |
| | |
| Content-Length | <a href="#section-18.17">Section 18.17</a> |
| | |
| Content-Location | <a href="#section-18.18">Section 18.18</a> |
| | |
| Content-Type | <a href="#section-18.19">Section 18.19</a> |
| | |
| Expires | <a href="#section-18.22">Section 18.22</a> |
| | |
| Last-Modified | <a href="#section-18.27">Section 18.27</a> |
+------------------+----------------+
Table 6: The RTSP Message Body Headers
<span class="grey">Schulzrinne, et al. Standards Track [Page 48]</span><span id="page-49" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
The extension-header mechanism allows additional message body header
fields to be defined without changing the protocol, but these fields
cannot be assumed to be recognizable by the recipient. Unrecognized
header fields MUST be ignored by the recipient and forwarded by
proxies.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Message Body</span>
An RTSP message with a message body MUST include the Content-Type and
Content-Length headers. When a message body is included with a
message, the data type of that content data is determined via the
Content-Type and Content-Encoding header fields.
Content-Type specifies the media type of the underlying data. There
is no default media format and the actual format used in the body is
required to be explicitly stated in the Content-Type header. By
being explicit and always requiring the inclusion of the Content-Type
header with accurate information, one avoids the many pitfalls in a
heuristic-based interpretation of the body content. The user
experience of HTTP and email have suffered from relying on such
heuristics.
Content-Encoding may be used to indicate any additional content-
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. The
default encoding is 'identity', i.e. no transformation of the message
body.
The Content-Length of a message is the length of the content,
measured in octets.
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. Message Body Format Negotiation</span>
The content format of the message body is provided using the Content-
Type header (<a href="#section-18.19">Section 18.19</a>). To enable the responder of a request to
determine which media type it should use, the requester may include
the Accept header (<a href="#section-18.1">Section 18.1</a>) in a request to identify supported
media types or media type ranges suitable to the response. In case
the responder is not supporting any of the specified formats, then
the request response will be a 406 (Not Acceptable) error code.
The media types that may be used on requests with message bodies need
to be determined through the use of feature tags, specification
requirement, or trial and error. Trial and error works because when
the responder does not support the media type of the message body, it
will respond with a 415 (Unsupported Media Type).
<span class="grey">Schulzrinne, et al. Standards Track [Page 49]</span><span id="page-50" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
The formats supported and their negotiation is done individually on a
per method and direction (request or response body) direction.
Requirements on supporting particular media types for use as message
bodies in requests and response SHALL also be specified on a per-
method and per-direction basis.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Connections</span>
RTSP messages are transferred between RTSP agents and proxies using a
transport connection. This transport connection uses TCP or TCP/TLS.
This transport connection is referred to as the "connection" or "RTSP
connection" within this document.
RTSP requests can be transmitted using the two different connection
scenarios listed below:
o persistent - a transport connection is used for several request/
response transactions;
o transient - a transport connection is used for each single
request/response transaction.
<a href="./rfc2326">RFC 2326</a> attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side effect of this is that
RTSP requests MUST NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast
environments.
Certain RTSP headers, such as the CSeq header (<a href="#section-18.20">Section 18.20</a>), which
may appear to be relevant only to connectionless transport scenarios,
are still retained and MUST be implemented according to this
specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see <a href="#section-12">Section 12</a>).
It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP
connection.
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Reliability and Acknowledgements</span>
Since RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP level.
Instead, the implementation must rely on the underlying transport to
<span class="grey">Schulzrinne, et al. Standards Track [Page 50]</span><span id="page-51" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
provide reliability. The RTSP implementation may use any indication
of reception acknowledgment of the message from the underlying
transport protocols to optimize the RTSP behavior.
If both the underlying reliable transport, such as TCP, and the
RTSP application retransmit requests, each packet loss or message
loss may result in two retransmissions. The receiver typically
cannot take advantage of the application-layer retransmission
since the transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver.
If the packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the
congestion.
Lack of acknowledgment of an RTSP request should be handled within
the constraints of the connection timeout considerations described
below (<a href="#section-10.4">Section 10.4</a>).
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Using Connections</span>
A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (<a href="#section-4.2">Section 4.2</a>)
allows the client to specify the port it will contact the server on,
and defines the default port to use if one is not explicitly given.
In addition to the registered default ports, i.e., 554 (rtsp) and 322
(rtsps), there is an alternative port 8554 registered. This port may
provide some benefits over non-registered ports if an RTSP server is
unable to use the default ports. The benefits may include
preconfigured security policies as well as classifiers in network
monitoring tools.
An RTSP client opening a TCP connection to access a particular
resource as identified by a URI uses the IP address and port derived
from the host and port parts of the URI. The IP address is either
the explicit address provided in the URI or any of the addresses
provided when performing A and AAAA record DNS lookups of the
hostname in the URI.
A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault tolerance.
They also allow for application-layer mobility. A server-and-
client pair that supports transient connections can survive the
<span class="grey">Schulzrinne, et al. Standards Track [Page 51]</span><span id="page-52" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
loss of a TCP connection; e.g., due to a NAT timeout. When the
client has discovered that the TCP connection has been lost, it
can set up a new one when there is need to communicate again.
A persistent connection is RECOMMENDED to be used for all
transactions between the server and client, including messages for
multiple RTSP sessions. However, a persistent connection MAY be
closed after a few message exchanges. For example, a client may use
a persistent connection for the initial SETUP and PLAY message
exchanges in a session and then close the connection. Later, when
the client wishes to send a new request, such as a PAUSE for the
session, a new connection would be opened. This connection may be
either transient or persistent.
An RTSP agent MAY use one connection to handle multiple RTSP sessions
on the same server. The RTSP agent SHALL NOT use more than one
connection per RTSP session at any given point.
Having only one connection in use at any time avoids confusion
regarding on which connection any server-to-client requests shall
be sent. Using a single connection for multiple RTSP sessions
also saves complexity by enabling the server to maintain less
state about its connection resources on the server. Not using
more than one connection at a time for a particular RTSP session
avoids wasting connection resources and allows the server to track
only the most recently used client-to-server connection for each
RTSP session as being the currently valid server-to-client
connection.
RTSP allows a server to send requests to a client. However, this can
be supported only if a client establishes a persistent connection
with the server. In cases where a persistent connection does not
exist between a server and its client, due to the lack of a signaling
channel, the server may be forced to silently discard RTSP messages,
and it may even drop an RTSP session without notifying the client.
An example of such a case is when the server desires to send a
REDIRECT request for an RTSP session to the client but is not able to
do so because it cannot reach the client. A server that attempts to
send a request to a client that has no connection currently to the
server SHALL discard the request.
Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client.
Because of the likely failure of server-to-client established
connections, the server will not even attempt establishing any
connection.
<span class="grey">Schulzrinne, et al. Standards Track [Page 52]</span><span id="page-53" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Queuing of server-to-client requests has been considered.
However, a security issue exists as to how it might be possible to
authorize a client establishing a new connection as being a
legitimate receiver of a request related to a particular RTSP
session, without the client first issuing requests related to the
pending request. Thus, it would be likely to make any such
requests even more delayed and less useful.
The sending of client and server requests can be asynchronous events.
To avoid deadlock situations, both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be
queued up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. A potential
issue is that outstanding requests may time out despite being
processed by the peer; this can be due to the response being caught
in the queue behind a number of requests that the RTSP agent is
processing but that take some time to complete. To avoid this
problem, an RTSP agent should buffer incoming messages locally so
that any response messages can be processed immediately upon
reception. If responses are separated from requests and directly
forwarded for processing, not only can the result be used
immediately, the state associated with that outstanding request can
also be released. However, buffering a number of requests on the
receiving RTSP agent consumes resources and enables a resource
exhaustion attack on the agent. Therefore, this buffer should be
limited so that an unreasonable number of requests or total message
size is not allowed to consume the receiving agent's resources. In
most APIs, having the receiving agent stop reading from the TCP
socket will result in TCP's window being clamped, thus forcing the
buffering onto the sending agent when the load is larger than
expected. However, as both RTSP message sizes and frequency may be
changed in the future by protocol extensions, an agent should be
careful about taking harsher measurements against a potential attack.
When under attack, an RTSP agent can close TCP connections and
release state associated with that TCP connection.
To provide some guidance on what is reasonable, the following
guidelines are given. It is RECOMMENDED that:
o an RTSP agent should not have more than 10 outstanding requests
per RTSP session;
o an RTSP agent should not have more than 10 outstanding requests
that are not related to an RTSP session or that are requesting to
create an RTSP session.
<span class="grey">Schulzrinne, et al. Standards Track [Page 53]</span><span id="page-54" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (see <a href="#section-12">Section 12</a>).
RTSP agents can send requests to multiple different destinations,
either server or client contexts over the same connection to a proxy.
Then, the proxy forks the message to the different destinations over
proxy-to-agent connections. In these cases when multiple requests
are outstanding, the requesting agent MUST be ready to receive the
responses out of order compared to the order they where sent on the
connection. The order between multiple messages for each destination
will be maintained; however, the order between response from
different destinations can be different.
The reason for this is to avoid a head-of-line blocking situation.
In a sequence of requests, an early outstanding request may take
time to be processed at one destination. Simultaneously, a
response from any other destination that was later in the sequence
of requests may have arrived at the proxy; thus, allowing out-of-
order responses avoids forcing the proxy to buffer this response
and instead deliver it as soon as possible. Note, this will not
affect the order in which the messages sent to each separate
destination were processed at the request destination.
This scenario can occur in two cases involving proxies. The first is
a client issuing requests for sessions on different servers using a
common client-to-proxy connection. The second is for server-to-
client requests, like REDIRECT being sent by the server over a common
transport connection the proxy created for its different connecting
clients.
<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>. Closing Connections</span>
The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT
close a connection until all RTSP sessions being managed through the
connection have been timed out (<a href="#section-18.49">Section 18.49</a>). A server SHOULD NOT
close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, the server should wait for a reasonable
amount of time for the client to receive and act upon the TEARDOWN
<span class="grey">Schulzrinne, et al. Standards Track [Page 54]</span><span id="page-55" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
response and then initiate the connection closing. The server SHOULD
wait at least 10 seconds after sending the TEARDOWN response before
closing the connection.
This is to ensure that the client has time to issue a SETUP for a
new session on the existing connection after having torn the last
one down. Ten seconds should give the client ample opportunity to
get its message to the server.
A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code.
Certain error responses such as 460 (Only Aggregate Operation
Allowed) (<a href="#section-17.4.24">Section 17.4.24</a>) are used for negotiating capabilities
of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent
implementation of advanced or special types of requests or result
in extra overhead for the client when testing for new features.
On the other hand, keeping connections open after sending an error
response poses a Denial-of-Service (DoS) security risk
(<a href="#section-21">Section 21</a>).
The server MAY close a connection if it receives an incomplete
message and if the message is not completed within a reasonable
amount of time. It is RECOMMENDED that the server wait at least 10
seconds for the completion of a message or for the next part of the
message to arrive (which is an indication that the transport and the
client are still alive). Servers believing they are under attack or
that are otherwise starved for resources during that event MAY
consider using a shorter timeout.
If a server closes a connection while the client is attempting to
send a new request, the client will have to close its current
connection, establish a new connection, and send its request over the
new connection.
An RTSP message SHOULD NOT be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in
<a href="#section-5">Section 5</a>.
<span class="grey">Schulzrinne, et al. Standards Track [Page 55]</span><span id="page-56" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
<span class="h3"><a class="selflink" id="section-10.4" href="#section-10.4">10.4</a>. Timing Out Connections and RTSP Messages</span>
Receivers of a request (responders) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requester) SHOULD wait for a
sufficient time for a response before concluding that the responder
will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that the processing of a request will take
longer than 5 seconds, it SHOULD send a 100 (Continue) response as
soon as possible. It SHOULD continue sending a 100 response every 5
seconds thereafter until it is ready to send the final response to
the requester. After sending a 100 response, the responder MUST send
a final response indicating the success or failure of the request.
A requester SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request.
After receiving a 100 response, the requester SHOULD continue waiting
for further responses. If more than 10 seconds elapse without
receiving any response, the requester MAY assume that the responder
is unresponsive and abort the connection by closing the TCP
connection.
In some cases, multiple RTSP sessions share the same transport
connection; abandoning a request and closing the connection may have
significant impact on those other sessions. First of all, other RTSP
requests may have become queued up due to the request taking a long
time to process. Secondly, those sessions also lose the possibility
to receive server-to-client requests. To mitigate that situation,
the RTSP client or server SHOULD establish a new connection and send
any requests that are queued up or that haven't received a response
on this new connection. Thirdly, to ensure that the RTSP server
knows which connection is valid for a particular RTSP session, the
RTSP agent SHOULD send a keep-alive request, if no other request will
be sent immediately for that RTSP session, for each RTSP session on
the old connection. The keep-alive request will normally be a
SET_PARAMETER with a session header to inform the server that this
agent cares about this RTSP session.
A requester SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the
responder. The requester is capable of determining the Round-Trip
Time (RTT) of the request/response cycle using the Timestamp header
(<a href="#section-18.53">Section 18.53</a>) in any RTSP request.
<span class="grey">Schulzrinne, et al. Standards Track [Page 56]</span><span id="page-57" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
The 10-second wait was chosen for the following reasons. It gives
TCP time to perform a couple of retransmissions, even if operating
on default values. It is short enough that users may not abandon
the process themselves. However, it should be noted that 10
seconds can be aggressive on certain types of networks. The
5-second value for 1xx messages is half the timeout giving a
reasonable chance of successful delivery before timeout happens on
the requester side.
<span class="h3"><a class="selflink" id="section-10.5" href="#section-10.5">10.5</a>. Showing Liveness</span>
RTSP requires the client to periodically show its liveness to the
server or the server may terminate any session state. Several
different protocol mechanism include in their usage a liveness proof
from the client. These mechanisms are RTSP requests with a Session
header to the server; if RTP & RTCP is used for media data transport
and the transport is established, the RTCP message proves liveness;
or through any other used media-transport protocol capable of
indicating liveness of the RTSP client. It is RECOMMENDED that a
client not wait to the last second of the timeout before trying to
send a liveness message. The RTSP message may take some time to
arrive safely at the receiver, due to packet loss and TCP
retransmissions. To show liveness between RTSP requests being issued
to accomplish other things, the following mechanisms can be used, in
descending order of preference:
RTCP: If RTP is used for media transport, RTCP SHOULD be used. If
RTCP is used to report transport statistics, it will
necessarily also function as a keep-alive. The server can
determine the client by network address and port together with
the fact that the client is reporting on the server's RTP
sender sources (synchronization source (SSRCs)). A downside of
using RTCP is that it only gives statistical guarantees of
reaching the server. However, the probability of a false
client timeout is so low that it can be ignored in most cases.
For example, assume a session with a 60-second timeout and
enough bitrate assigned to RTCP messages to send a message from
client to server on average every 5 seconds. That client has,
for a network with 5% packet loss, a probability of failing to
confirm liveness within the timeout interval for that session
of 2.4*E-16. Sessions with shorter timeouts, much higher
packet loss, or small RTCP bandwidths SHOULD also implement one
or more of the mechanisms below.
<span class="grey">Schulzrinne, et al. Standards Track [Page 57]</span><span id="page-58" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
SET_PARAMETER: When using SET_PARAMETER for keep-alives, a body
SHOULD NOT be included. This method is the RECOMMENDED RTSP
method to use for a request intended only to perform keep-
alives. RTSP servers MUST support the SET_PARAMETER method, so
that clients can always use this mechanism.
GET_PARAMETER: When using GET_PARAMETER for keep-alives, a body
SHOULD NOT be included, dependent on implementation support in
the server. Use the OPTIONS method to determine if there is
method support or simply try.
OPTIONS: This method is also usable, but it causes the server to
perform more unnecessary processing and results in bigger
responses than necessary for the task. The reason is that the
server needs to determine the capabilities associated with the
media resource to correctly populate the Public and Allow
headers.
The timeout parameter of the Session header (<a href="#section-18.49">Section 18.49</a>) MAY be
included in a SETUP response and MUST NOT be included in requests.
The server uses it to indicate to the client how long the server is
prepared to wait between RTSP commands or other signs of life before
closing the session due to lack of activity (see <a href="#appendix-B">Appendix B</a>). The
timeout is measured in seconds, with a default of 60 seconds. The
length of the session timeout MUST NOT be changed in an established
session.
<span class="h3"><a class="selflink" id="section-10.6" href="#section-10.6">10.6</a>. Use of IPv6</span>
Explicit IPv6 [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] support was not present in RTSP 1.0. RTSP
2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and RTSP
headers. Although the general URI format envisages potential future
new versions of the literal IP address, usage of any such new version
would require other modifications to the RTSP specification (e.g.,
address fields in the Transport header (<a href="#section-18.54">Section 18.54</a>)).
<span class="h3"><a class="selflink" id="section-10.7" href="#section-10.7">10.7</a>. Overload Control</span>
Overload in RTSP can occur when servers and proxies have insufficient
resources to complete the processing of a request. An improper
handling of such an overload situation at proxies and servers can
impact the operation of the RTSP deployment, and probably worsen the
situation. RTSP defines the 503 (Service Unavailable) response
(<a href="#section-17.5.4">Section 17.5.4</a>) to let servers and proxies notify requesting proxies
and RTSP clients about an overload situation. In conjunction with
<span class="grey">Schulzrinne, et al. Standards Track [Page 58]</span><span id="page-59" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
the Retry-After header (<a href="#section-18.44">Section 18.44</a>), the server or proxy can
indicate the time after which the requesting entity can send another
request to the proxy or server.
There are two scopes of such 503 answers. The first scope is for an
established RTSP session, where the request resulting in the 503
response as well as the response itself carries a Session header
identifying the session that is suffering overload. This response
only applies to this particular session. The other scope is the
general RTSP server as identified by the host in the Request-URI.
Such a 503 answer with any Retry-After header applies to all requests
that are not session specific to that server, including a SETUP
request intended to create a new RTSP session.
Another scope for overload situations exists: the RTSP proxy. To
enable an RTSP proxy to signal that it is overloaded, or otherwise
unavailable and unable to handle the request, a 553 response code has
been defined with the meaning "Proxy Unavailable". As with servers,
there is a separation in response scopes between requests associated
with existing RTSP sessions and requests to create new sessions or
general proxy requests.
Simply implementing and using the 503 (Service Unavailable) and 553
(Proxy Unavailable) response codes is not sufficient for properly
handling overload situations. For instance, a simplistic approach
would be to send the 503 response with a Retry-After header set to a
fixed value. However, this can cause a situation in which multiple
RTSP clients again send requests to a proxy or server at roughly the
same time, which may again cause an overload situation. Another
situation would be if the "old" overload situation is not yet
resolved, i.e., the length indicated in the Retry-After header was
too short for the overload situation to subside.
An RTSP server or proxy in an overload situation must select the
value of the Retry-After header carefully, bearing in mind its
current load situation. It is REQUIRED to increase the timeout
period in proportion to the current load on the server, i.e., an
increasing workload should result in an increased length of the
indicated unavailability. It is REQUIRED not to send the same value
in the Retry-After header to all requesting proxies and clients, but
to add a variation to the mean value of the Retry-After header.
A more complex case may arise when a load-balancing RTSP proxy is in
use. This is the case when an RTSP proxy is used to select amongst a
set of RTSP servers to handle the requests or when multiple server
addresses are available for a given server name. The proxy or client
may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable)
response code from one of its RTSP servers or proxies, or a TCP
<span class="grey">Schulzrinne, et al. Standards Track [Page 59]</span><span id="page-60" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
timeout (if the server is even unable to handle the request message).
The proxy or client simply retries the other addresses or configured
proxies, but it may also receive a 503 (Service Unavailable) or 553
(Proxy Unavailable) response or TCP timeouts from those addresses.
In such a situation, where none of the RTSP servers/proxies/addresses
can handle the request, the RTSP agent has to wait before it can send
any new requests to the RTSP server. Any additional request to a
specific address MUST be delayed according to the Retry-After headers
received. For addresses where no response was received or TCP
timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
That timer MUST be doubled for each additional failure to connect or
receive response until the value exceeds 30 minutes when the timer's
mean value may be set to 30 minutes. It is REQUIRED not to set the
same value in the timer for each scheduling, but instead to add a
variation to the mean value, resulting in picking a random value
within the range of 0.5 to 1.5 times the mean value.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Capability Handling</span>
This section describes the available capability-handling mechanism
that allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. Firstly, new headers can be
added. Secondly, new methods can be added. The capability-handling
mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS
method to discover whether it is supported. This is done by issuing
an OPTIONS request to the other party. Depending on the URI, it will
either apply in regard to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response MUST
contain a Public header that declares all methods supported for the
indicated resource.
It is not necessary to use OPTIONS to discover support of a method,
as the client could simply try the method. If the receiver of the
request does not support the method, it will respond with an error
code indicating the method is either not implemented (501) or does
not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service.
Feature tags are defined to handle functionality additions that are
not new methods. Each feature tag represents a certain block of
functionality. The amount of functionality that a feature tag
represents can vary significantly. For example, a feature tag can
represent the functionality a single RTSP header provides. Another
feature tag can represent much more functionality, such as the
"play.basic" feature tag (<a href="#section-11.1">Section 11.1</a>), which represents the minimal
media delivery for playback implementation.
<span class="grey">Schulzrinne, et al. Standards Track [Page 60]</span><span id="page-61" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Feature tags are used to determine whether the client, server, or
proxy supports the functionality that is necessary to achieve the
desired service. To determine support of a feature tag, several
different headers can be used, each explained below:
Supported: This header is used to determine the complete set of
functionality that both client and server have, in general, and
is not dependent on a specific resource. The intended usage is
to determine before one needs to use a functionality that it is
supported. It can be used in any method, but OPTIONS is the
most suitable as it simultaneously determines all methods that
are implemented. When sending a request, the requester
declares all its capabilities by including all supported
feature tags. This results in the receiver learning the
requester's feature support. The receiver then includes its
set of features in the response.
Proxy-Supported: This header is used in a similar fashion as the
Supported header, but instead of giving the supported
functionality of the client or server, it provides both the
requester and the responder a view of the common functionality
supported in general by all members of the proxy chain between
the client and server; it does not depend on the resource.
Proxies are required to add this header whenever the Supported
header is present, but proxies may also add it independently of
the requester.
Require: This header can be included in any request where the
endpoint, i.e., the client or server, is required to understand
the feature to correctly perform the request. This can, for
example, be a SETUP request, where the server is required to
understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore, the endpoint
receiving a request containing a Require MUST negatively
acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are
not supported is 551 (Option Not Supported). Also, the
features that are not supported are given in the Unsupported
header in the response.
Proxy-Require: This header has the same purpose and behavior as
Require except that it only applies to proxies and not the
endpoint. Features that need to be supported by both proxies
and endpoints need to be included in both the Require and
Proxy-Require header.
<span class="grey">Schulzrinne, et al. Standards Track [Page 61]</span><span id="page-62" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
Unsupported: This header is used in a 551 (Option Not Supported)
error response, to indicate which features were not supported.
Such a response is only the result of the usage of the Require
or Proxy-Require headers where one or more features were not
supported. This information allows the requester to make the
best of situations as it knows which features are not
supported.
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Feature Tag: play.basic</span>
An implementation supporting all normative parts of this
specification for the setup and control of playback of media uses the
feature tag "play.basic" to indicate this support. The appendices
(starting with letters) are not part of the functionality included in
the feature tag unless the appendix is explicitly specified in a main
section as being a required appendix.
Note: This feature tag does not mandate any media delivery
protocol, such as RTP.
In RTSP 1.0, there was a minimal implementation section. However,
that was not consistent with the rest of the specification. So,
rather than making an attempt to explicitly enumerate the features
for play.basic, this specification has to be taken as a whole and
the necessary features normatively defined as being required are
included.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Pipelining Support</span>
Pipelining is a general method to improve performance of request/
response protocols by allowing the requesting agent to have more than
one request outstanding and to send them over the same persistent
connection. For RTSP, where the relative order of requests will
matter, it is important to maintain the order of the requests.
Because of this, the responding agent MUST process the incoming
requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP, the delivery
order will be the same, between two agents, as the sending order.
The processing of the request MUST also have been finished before
processing the next request from the same agent. The responses MUST
be sent in the order the requests were processed.
RTSP 2.0 has extended support for pipelining beyond the capabilities
in RTSP 1.0. As a major improvement, all requests involved in
setting up and initiating media delivery can now be pipelined,
indicated by the Pipelined-Request header (see <a href="#section-18.33">Section 18.33</a>). This
header allows a client to request that two or more requests be
processed in the same RTSP session context that the first request
<span class="grey">Schulzrinne, et al. Standards Track [Page 62]</span><span id="page-63" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
creates. In other words, a client can request that two or more media
streams be set up and then played without needing to wait for a
single response. This speeds up the initial start-up time for an
RTSP session by at least one RTT.
If a pipelined request builds on the successful completion of one or
more prior requests, the requester must verify that all requests were
executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP requests fails
unexpectedly, the PLAY request can still be successfully executed.
However, the resulting presentation will not be as expected by the
requesting client, as only a single media instead of two will be
played. In this case, the client can send a PAUSE request, correct
the failing SETUP request, and then request it be played.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Method Definitions</span>
The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case sensitive.
New methods may be defined in the future. Method names MUST NOT
start with a $ character (decimal 36) and MUST be a token as defined
by the ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] in <a href="#section-20">Section 20</a>. The methods are summarized in
Table 7.
<span class="grey">Schulzrinne, et al. Standards Track [Page 63]</span><span id="page-64" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
+---------------+-----------+--------+-------------+-------------+
| method | direction | object | Server req. | Client req. |
+---------------+-----------+--------+-------------+-------------+
| DESCRIBE | C -> S | P,S | recommended | recommended |
| | | | | |
| GET_PARAMETER | C -> S | P,S | optional | optional |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| OPTIONS | C -> S | P,S | required | required |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| PAUSE | C -> S | P,S | required | required |
| | | | | |
| PLAY | C -> S | P,S | required | required |
| | | | | |
| PLAY_NOTIFY | S -> C | P,S | required | required |
| | | | | |
| REDIRECT | S -> C | P,S | optional | required |
| | | | | |
| SETUP | C -> S | S | required | required |
| | | | | |
| SET_PARAMETER | C -> S | P,S | required | optional |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| TEARDOWN | C -> S | P,S | required | required |
| | | | | |
| | S -> C | P | required | required |
+---------------+-----------+--------+-------------+-------------+
Table 7: Overview of RTSP Methods
Note on Table 7: This table covers RTSP methods, their direction,
and on what objects (P: presentation, S: stream) they operate.
Further, it indicates whether a server or a client implementation
is required (mandatory), recommended, or optional.
Further note on Table 7: the GET_PARAMETER is optional. For
example, a fully functional server can be built to deliver media
without any parameters. However, SET_PARAMETER is required, i.e.,
mandatory to implement for the server; this is due to its usage
for keep-alive. PAUSE is required because it is the only way of
leaving the Play state without terminating the whole session.
<span class="grey">Schulzrinne, et al. Standards Track [Page 64]</span><span id="page-65" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
If an RTSP agent does not support a particular method, it MUST return
a 501 (Not Implemented) response code and the requesting RTSP agent,
in turn, SHOULD NOT try this method again for the given agent/
resource combination. An RTSP proxy whose main function is to log or
audit and not modify transport or media handling in any way MAY
forward RTSP messages with unknown methods. Note that the proxy
still needs to perform the minimal required processing, like adding
the Via header.
<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>. OPTIONS</span>
The semantics of the RTSP OPTIONS method is similar to that of the
HTTP OPTIONS method described in <a href="./rfc7231#section-4.3.7">Section 4.3.7 of [RFC7231]</a>.
However, in RTSP, OPTIONS is bidirectional in that a client can send
the request to a server and vice versa. A client MUST implement the
capability to send an OPTIONS request and a server or a proxy MUST
implement the capability to respond to an OPTIONS request. In
addition to this "MUST-implement" functionality, clients, servers and
proxies MAY provide support both for sending OPTIONS requests and for
generating responses to the requests.
An OPTIONS request may be issued at any time. Such a request does
not modify the session state. However, it may prolong the session
lifespan (see below). The URI in an OPTIONS request determines the
scope of the request and the corresponding response. If the Request-
URI refers to a specific media resource on a given host, the scope is
limited to the set of methods supported for that media resource by
the indicated RTSP agent. A Request-URI with only the host address
limits the scope to the specified RTSP agent's general capabilities
without regard to any specific media. If the Request-URI is an
asterisk ("*"), the scope is limited to the general capabilities of
the next hop (i.e., the RTSP agent in direct communication with the
request sender).
Regardless of the scope of the request, the Public header MUST always
be included in the OPTIONS response, listing the methods that are
supported by the responding RTSP agent. In addition, if the scope of
the request is limited to a media resource, the Allow header MUST be
included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code,
such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the
responding RTSP agent.
<span class="grey">Schulzrinne, et al. Standards Track [Page 65]</span><span id="page-66" ></span>
<span class="grey"><a href="./rfc7826">RFC 7826</a> RTSP 2.0 December 2016</span>
The OPTIONS method can be used to keep an RTSP session alive.
However, this is not the preferred way of session keep-alive
signaling; see <a href="#section-18.49">Section 18.49</a>. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with
the associated session identifier. Such a request SHOULD also use
the media or the aggregated control URI as the Request-URI.
Example:
C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages
Supported: play.basic
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1
Note that the "gzipped-messages" feature tag in the Proxy-Require is
a fictitious feature.