idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-40.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC2326, but the abstract doesn't seem to directly say this. It does mention RFC2326 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 10, 2014) is 3728 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'H10' is mentioned on line 5046, but not defined == Missing Reference: 'H15' is mentioned on line 9515, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 10182, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-pub-180-2' == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-04 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-20 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Possible downref: Non-RFC (?) normative reference: ref. 'TS-26234' -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group H. Schulzrinne 3 Internet-Draft Columbia University 4 Obsoletes: 2326 (if approved) A. Rao 5 Intended status: Standards Track Cisco 6 Expires: August 14, 2014 R. Lanphier 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 February 10, 2014 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-40 17 Abstract 19 This memorandum defines RTSP version 2.0 which obsoletes RTSP version 20 1.0 defined in RFC 2326. 22 The Real Time Streaming Protocol, or RTSP, is an application-layer 23 protocol for setup and control of the delivery of data with real-time 24 properties. RTSP provides an extensible framework to enable 25 controlled, on-demand delivery of real-time data, such as audio and 26 video. Sources of data can include both live data feeds and stored 27 clips. This protocol is intended to control multiple data delivery 28 sessions, provide a means for choosing delivery channels such as UDP, 29 multicast UDP and TCP, and provide a means for choosing delivery 30 mechanisms based upon RTP (RFC 3550). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 14, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 79 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 80 2.1. Presentation Description . . . . . . . . . . . . . . . . 11 81 2.2. Session Establishment . . . . . . . . . . . . . . . . . . 12 82 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 13 83 2.4. Session Parameter Manipulations . . . . . . . . . . . . . 15 84 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 16 85 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 16 86 2.6. Session Maintenance and Termination . . . . . . . . . . . 19 87 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 20 88 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 21 89 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 21 90 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 21 91 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 92 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24 93 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 94 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . . 27 95 4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 27 96 4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . . 28 97 4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 28 98 4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . . 30 99 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 30 100 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . . 31 101 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 31 102 4.7.1. Random Access and Seeking . . . . . . . . . . . . . . 32 103 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . . 33 104 4.7.3. Content Modifications . . . . . . . . . . . . . . . . 33 105 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . . 33 106 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . . 34 107 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 108 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 34 109 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 35 110 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 111 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 112 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 36 113 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38 115 7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 40 116 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42 117 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 42 118 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 42 119 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 120 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 46 121 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47 122 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48 123 9.3. Message Body Format Negotiation . . . . . . . . . . . . . 48 124 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 125 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49 126 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50 127 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 128 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 129 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 130 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 57 131 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 57 132 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 133 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 60 134 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 61 135 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 136 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 63 137 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 64 138 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 66 139 13.3.1. Changing Transport Parameters . . . . . . . . . . . 69 140 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 70 141 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 70 142 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 75 143 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 76 144 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 79 145 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 79 146 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 79 147 13.4.7. Playing Live with Recording . . . . . . . . . . . . 80 148 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 81 149 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 81 150 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 82 151 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 84 152 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 85 153 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 86 154 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 89 155 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 89 156 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 90 157 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91 158 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 93 159 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 95 160 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 97 161 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 162 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 101 163 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 102 164 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 165 16.1. Validation Model . . . . . . . . . . . . . . . . . . . 103 166 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 104 167 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 104 168 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 104 169 16.1.4. Rules for When to Use Message Body Tags and Last- 170 Modified Dates . . . . . . . . . . . . . . . . . . . 107 171 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 108 172 16.2. Invalidation After Updates or Deletions . . . . . . . . 108 173 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 109 174 17.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 109 175 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 109 176 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 110 177 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 110 178 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 110 179 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 111 180 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 111 181 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 111 182 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 111 183 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 111 184 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 112 185 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 112 186 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 112 187 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 112 188 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 113 189 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 113 190 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 113 191 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 113 192 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 113 193 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 114 194 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 114 195 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 114 196 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 114 197 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 114 198 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 115 199 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 115 200 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 115 201 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 115 202 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 115 203 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 116 204 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 116 205 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 116 206 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 116 207 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 116 208 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 116 209 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 116 210 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 116 211 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 117 212 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 117 213 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 117 214 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 117 215 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 117 216 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 117 217 17.4.32. 470 Connection Authorization Required . . . . . . . 118 218 17.4.33. 471 Connection Credentials not accepted . . . . . . 118 219 17.4.34. 472 Failure to establish secure connection . . . . . 118 220 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 118 221 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 118 222 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 118 223 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 118 224 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 119 225 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 119 226 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 119 227 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 119 228 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 119 229 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 120 230 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 131 231 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 131 232 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 132 233 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 133 234 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 134 235 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 134 236 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 135 237 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 135 238 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 136 239 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 136 240 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 137 241 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 139 242 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 140 243 18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 141 244 18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 141 245 18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 142 246 18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 143 247 18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 143 248 18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 144 249 18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 144 250 18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 146 251 18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 147 252 18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 148 253 18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 148 254 18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 149 255 18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 149 256 18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 150 257 18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 150 258 18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 151 259 18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 153 260 18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 153 261 18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 154 262 18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 154 263 18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 155 264 18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 155 265 18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 156 266 18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 156 267 18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 156 268 18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 157 269 18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 158 270 18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 160 271 18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 160 272 18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 161 273 18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 162 274 18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 162 275 18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 164 276 18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 165 277 18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 167 278 18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 167 279 18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 168 280 18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 169 281 18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 170 282 18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 170 283 18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 171 284 18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 178 285 18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 178 286 18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 179 287 18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 179 288 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 180 289 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 180 290 19.1.1. Digest Authentication . . . . . . . . . . . . . . . 181 291 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 182 292 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 183 293 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 184 294 19.3.2. User approved TLS procedure . . . . . . . . . . . . 185 295 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 296 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 187 297 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 189 298 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 190 299 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 192 300 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 196 301 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 205 302 21. Security Considerations . . . . . . . . . . . . . . . . . . . 205 303 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 206 304 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 209 305 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 210 306 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 211 307 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 212 308 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 213 309 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 214 310 22.1.2. Registering New Feature-tags with IANA . . . . . . . 214 311 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 214 312 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 215 313 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 215 314 22.2.2. Registering New Methods with IANA . . . . . . . . . 215 315 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 216 316 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 216 317 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 216 318 22.3.2. Registering New Status Codes with IANA . . . . . . . 216 319 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 217 320 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 217 321 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 217 322 22.4.2. Registering New Headers with IANA . . . . . . . . . 217 323 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 217 324 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 219 325 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 219 326 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 219 327 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 220 328 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 221 329 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 221 330 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 221 331 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 221 332 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 222 333 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 222 334 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 222 335 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 222 336 22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 223 337 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 223 338 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 223 339 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 223 340 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 223 341 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 224 342 22.10.2. Terminate-Reason Header Parameters . . . . . . . . 224 343 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 225 344 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 225 345 22.11.2. Registration Rules . . . . . . . . . . . . . . . . 225 346 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 225 347 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 225 348 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 226 349 22.12.2. Registration Rules . . . . . . . . . . . . . . . . 226 350 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 226 351 22.13. Transport Header Registries . . . . . . . . . . . . . . 227 352 22.13.1. Transport Protocol Identifier . . . . . . . . . . . 227 353 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 228 354 22.13.3. Transport Parameters . . . . . . . . . . . . . . . 229 355 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 230 356 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 230 357 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . 231 358 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . 232 359 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 233 360 22.16. Media Type Registration for text/parameters . . . . . . 234 361 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 235 362 23.1. Normative References . . . . . . . . . . . . . . . . . . 235 363 23.2. Informative References . . . . . . . . . . . . . . . . . 239 364 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 241 365 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 241 366 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 245 367 A.3. Secured Media Session for on Demand Content . . . . . . . 247 368 A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 250 369 A.5. Single Stream Container Files . . . . . . . . . . . . . . 254 370 A.6. Live Media Presentation Using Multicast . . . . . . . . . 256 371 A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 257 372 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 258 373 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 259 374 B.2. State variables . . . . . . . . . . . . . . . . . . . . . 259 375 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 259 376 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 260 377 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 264 378 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 379 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 265 380 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 265 381 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 266 382 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 267 383 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 269 384 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 269 386 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 271 387 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 271 388 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 272 389 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 276 390 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 280 391 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 282 392 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 282 393 C.7. Maintaining NPT synchronization with RTP timestamps . . . 282 394 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 282 395 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 282 396 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP 397 Session . . . . . . . . . . . . . . . . . . . . . . . . . 283 398 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 283 399 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 284 400 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 284 401 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 284 402 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 286 403 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 286 404 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 286 405 D.1.5. Directionality of media stream . . . . . . . . . . . 287 406 D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 287 407 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 288 408 D.1.8. Connection Information . . . . . . . . . . . . . . . 288 409 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 289 410 D.2. Aggregate Control Not Available . . . . . . . . . . . . . 289 411 D.3. Aggregate Control Available . . . . . . . . . . . . . . . 290 412 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 291 413 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 292 414 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 292 415 E.1. On-demand Playback of Stored Content . . . . . . . . . . 292 416 E.2. Unicast Distribution of Live Content . . . . . . . . . . 294 417 E.3. On-demand Playback using Multicast . . . . . . . . . . . 294 418 E.4. Inviting an RTSP server into a conference . . . . . . . . 295 419 E.5. Live Content using Multicast . . . . . . . . . . . . . . 296 420 Appendix F. Text format for Parameters . . . . . . . . . . . . . 296 421 Appendix G. Requirements for Unreliable Transport of RTSP . . . 297 422 Appendix H. Backwards Compatibility Considerations . . . . . . . 298 423 H.1. Play Request in Play State . . . . . . . . . . . . . . . 299 424 H.2. Using Persistent Connections . . . . . . . . . . . . . . 299 425 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 299 426 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 299 427 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 300 428 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 307 429 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 308 430 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 308 431 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 308 433 1. Introduction 435 This memo defines version 2.0 of the Real Time Streaming Protocol 436 (RTSP 2.0). RTSP 2.0 is an application-layer protocol for setup and 437 control over the delivery of data with real-time properties, 438 typically streaming media. Streaming media is, for instance, video 439 on demand or audio live streaming. Put simply, RTSP acts as a 440 "network remote control" for multimedia servers. 442 The protocol operates between RTSP 2.0 clients and servers, but also 443 supports the usage of proxies placed between clients and servers. 444 Clients can request information about streaming media from servers by 445 asking for a description of the media or use media description 446 provided externally. The media delivery protocol is used to 447 establish the media streams described by the media description. 448 Clients can then request to play out the media, pause it, or stop it 449 completely. The requested media can consist of multiple audio and 450 video streams that are delivered as time-synchronized streams from 451 servers to clients. 453 RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that 454 specification. This protocol is based on RTSP 1.0 but is not 455 backwards compatible other than in the basic version negotiation 456 mechanism. The changes are documented in Appendix I. There are many 457 reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but 458 some of the main ones are: 460 o Most headers that needed to be extensible did not define the 461 allowed syntax, preventing safe deployment of extensions; 463 o The changed behavior of the PLAY method when received in Play 464 state; 466 o Changed behavior of the extensibility model and its mechanism; 468 o The change of syntax for some headers. 470 In summary, there are so many small details that changing version 471 became necessary to enable clarification and consistent behavior. 472 Anyone implementing RTSP for a new usage where they have no installed 473 based of RTSP 1.0 should only implement RTSP 2.0 to avoid having to 474 deal with RTSP 1.0 inconsistencies. 476 This document is structured as follows. It begins with an overview 477 of the protocol operations and its functions in an informal way. 478 Then a set of definitions of terms used and document conventions is 479 introduced. It is followed by the actual RTSP 2.0 core protocol 480 specification. The appendixes describe and define some 481 functionalities that are not part of the core RTSP specification, but 482 which are still important to enable some usages. Among them, the RTP 483 usage is defined in Appendix C, the Session Description Protocol 484 (SDP) usage with RTSP is defined in Appendix D, and the text/ 485 parameters file format Appendix F, are three normative specification 486 appendixes. Others include a number of informational parts 487 discussing the changes, use cases, different considerations or 488 motivations. 490 2. Protocol Overview 492 This section provides an informative overview of the different 493 mechanisms in the RTSP 2.0 protocol, to give the reader a high level 494 understanding before getting into all the different details. In case 495 of conflict with this description and the later sections, the later 496 sections take precedence. For more information about use cases 497 considered for RTSP see Appendix E. 499 RTSP 2.0 is a bi-directional request and response protocol that first 500 establishes a context including content resources (the media) and 501 then controls the delivery of these content resources from the 502 provider to the consumer. RTSP has three fundamental parts: Session 503 Establishment, Media Delivery Control, and an extensibility model 504 described below. The protocol is based on some assumptions about 505 existing functionality to provide a complete solution for client 506 controlled real-time media delivery. 508 RTSP uses text-based messages, requests and responses, that may 509 contain a binary message body. An RTSP request starts with a method 510 line that identifies the method, the protocol and version and the 511 resource to act on. The resource is identified by a URI and the 512 hostname part of the URI is used by RTSP client to resolve the IPv4 513 or IPv6 address of the RTSP server. Following the method line are a 514 number of RTSP headers. This part is ended by two consecutive 515 carriage return line feed (CRLF) character pairs. The message body 516 if present follows the two CRLF and the body's length is described by 517 a message header. RTSP responses are similar, but start with a 518 response line with the protocol and version, followed by a status 519 code and a reason phrase. RTSP messages are sent over a reliable 520 transport protocol between the client and server. RTSP 2.0 requires 521 clients and servers to implement TCP, and TLS over TCP, as mandatory 522 transports for RTSP messages. 524 2.1. Presentation Description 526 RTSP exists to provide access to multi-media presentations and 527 content, but tries to be agnostic about the media type or the actual 528 media delivery protocol that is used. To enable a client to 529 implement a complete system, an RTSP-external mechanism for 530 describing the presentation and the delivery protocol(s) is used. 531 RTSP assumes that this description is either delivered completely out 532 of band or as a data object in the response to a client's request 533 using the DESCRIBE method (Section 13.2). 535 Parameters that commonly have to be included in the Presentation 536 Description are the following: 538 o Number of media streams; 540 o The resource identifier for each media stream/resource that is to 541 be controlled by RTSP; 543 o The protocol that each media stream is to be delivered over; 545 o Transport protocol parameters that are not negotiated or vary with 546 each client; 548 o Media encoding information enabling a client to correctly decode 549 the media upon reception; 551 o An aggregate control resource identifier. 553 RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media 554 resources and aggregates under common control (See Section 4.2). 556 This specification describes in Appendix D how one uses SDP [RFC4566] 557 for Presentation Description 559 2.2. Session Establishment 561 The RTSP client can request the establishment of an RTSP session 562 after having used the presentation description to determine which 563 media streams are available, which media delivery protocol is used 564 and the resource identifiers of the media streams. The RTSP session 565 is a common context between the client and the server that consists 566 of one or more media resources that are to be under common media 567 delivery control. 569 The client creates an RTSP session by sending a request using the 570 SETUP method (Section 13.3) to the server. In the "Transport" header 571 (Section 18.54) of the SETUP request, the client also includes all 572 the transport parameters necessary to enable the media delivery 573 protocol to function. This includes parameters that are pre- 574 established by the presentation description but necessary for any 575 middlebox to correctly handle the media delivery protocols. The 576 Transport header in a request may contain multiple alternatives for 577 media delivery in a prioritized list, which the server can select 578 from. These alternatives are typically based on information in the 579 presentation description. 581 The server determines if the media resource is available upon 582 receiving a SETUP request and if any of the transport parameter 583 specifications are acceptable. If that is successful, an RTSP 584 session context is created and the relevant parameters and state is 585 stored. An identifier is created for the RTSP session and included 586 in the response in the Session header (Section 18.49). The SETUP 587 response includes a Transport header that specifies which of the 588 alternatives has been selected and relevant parameters. 590 A SETUP request that references an existing RTSP session but 591 identifies a new media resource is a request to add that media 592 resource under common control with the already present media 593 resources in an aggregated session. A client can expect this to work 594 for all media resources under RTSP control within a multi-media 595 content. However, aggregating resources from different content are 596 likely to be refused by the server. Even if a RTSP session contains 597 only a single media, the RTSP session can be referenced by the 598 aggregate control URI. 600 To avoid an extra round trip in the session establishment of 601 aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., 602 the client can send multiple requests back-to-back without waiting 603 first for the completion of any of them. The client uses a client- 604 selected identifier in the Pipelined-Requests header (Section 18.33) 605 to instruct the server to bind multiple requests together as if they 606 included the session identifier. 608 The SETUP response also provides additional information about the 609 established sessions in a couple of different headers. The Media- 610 Properties header (Section 18.29) includes a number of properties 611 that apply for the aggregate that is valuable when doing media 612 delivery control and configuring user interface. The Accept-Ranges 613 header (Section 18.5) informs the client about which range formats 614 that the server supports with these media resources. The Media-Range 615 header (Section 18.30) informs the client about the time range of the 616 media currently available. 618 2.3. Media Delivery Control 620 After having established an RTSP session, the client can start 621 controlling the media delivery. The basic operations are Start by 622 using the PLAY method (Section 13.4) and Halt by using the PAUSE 623 method (Section 13.6). PLAY also allows for choosing the starting 624 media position from which the server should deliver the media. The 625 positioning is done by using the Range header (Section 18.40) that 626 supports several different time formats: Normal Play Time (NPT) 627 (Section 4.4.2), Society of Motion Picture and Television Engineers 628 (SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3). 629 The Range header does further allow the client to specify a position 630 where delivery should end, thus allowing a specific interval to be 631 delivered. 633 The support for positioning/searching within a media content depends 634 on the content's media properties. Content exists in a number of 635 different types, such as: on-demand, live, and live with simultaneous 636 recording. Even within these categories there are differences in how 637 the content is generated and distributed, which affect how it can be 638 accessed for playback. The properties applicable for the RTSP 639 session are provided by the server in the SETUP response using the 640 Media-Properties header (Section 18.29). These are expressed using 641 one or several independent attributes. A first attribute is Random 642 Access, which expresses if positioning can be done, and with what 643 granularity. Another aspect is whether the content will change 644 during the lifetime of the session. While on-demand content will be 645 provided in full from the beginning, a live stream being recorded 646 results in the length of the accessible content growing as the 647 session goes on. There also exists content that is dynamically built 648 by another protocol than RTSP and thus also changes in steps during 649 the session, but maybe not continuously. Furthermore, when content 650 is recorded, there are cases where not the complete content is 651 maintained, but, for example, only the last hour. All these 652 properties result in the need for mechanisms that will be discussed 653 below. 655 When the client accesses on-demand content that allows random access, 656 the client can issue the PLAY request for any point in the content 657 between the start and the end. The server will deliver media from 658 the closest random access point prior to the requested point and 659 indicate that in its PLAY response. If the client issues a PAUSE, 660 the delivery will be halted and the point at which the server stopped 661 will be reported back in the response. The client can later resume 662 by sending a PLAY request without a range header. When the server is 663 about to complete the PLAY request by delivering the end of the 664 content or the requested range, the server will send a PLAY_NOTIFY 665 request (Section 13.5) indicating this. 667 When playing live content with no extra functions, such as recording, 668 the client will receive the live media from the server after having 669 sent a PLAY request. Seeking in such content is not possible as the 670 server does not store it, but only forwards it from the source of the 671 session. Thus delivery continues until the client sends a PAUSE 672 request, tears down the session, or the content ends. 674 For live sessions that are being recorded the client will need to 675 keep track of how the recording progresses. Upon session 676 establishment the client will learn the current duration of the 677 recording from the Media-Range header. As the recording is ongoing 678 the content grows in direct relation to the passed time. Therefore, 679 each server's response to a PLAY request will contain the current 680 Media-Range header. The server should also regularly send 681 approximately every 5 minutes the current media range in a 682 PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, 683 the server must send a PLAY_NOTIFY request with the updated Media- 684 Properties indicating that the content stopped being a recorded live 685 session and instead became on-demand content; the request also 686 contains the final media range. While the live delivery continues 687 the client can request to play the current live point by using the 688 NPT timescale symbol "now", or it can request a specific point in the 689 available content by an explicit range request for that point. If 690 the requested point is outside of the available interval the server 691 will adjust the position to the closest available point, i.e., either 692 at the beginning or the end. 694 A special case of recording is that where the recording is not 695 retained longer than a specific time period, thus as the live 696 delivery continues the client can access any media within a moving 697 window that covers, for example, "now" to "now" minus 1 hour. A 698 client that pauses on a specific point within the content may not be 699 able to retrieve the content anymore. If the client waits too long 700 before resuming the pause point, the content may no longer be 701 available. In this case the pause point will be adjusted to the 702 closest point in the available media. 704 2.4. Session Parameter Manipulations 706 A session may have additional state or functionality that affects how 707 the server or client treats the session, content, how it functions, 708 or feedback on how well the session works. Such extensions are not 709 defined in this specification, but may be done in various extensions. 710 RTSP has two methods for retrieving and setting parameter values on 711 either the client or the server: GET_PARAMETER (Section 13.8) and 712 SET_PARAMETER (Section 13.9). These methods carry the parameters in 713 a message body of the appropriate format. One can also use headers 714 to query state with the GET_PARAMETER method. As an example, clients 715 needing to know the current media-range for a time-progressing 716 session can use the GET_PARAMETER method and include the media-range. 717 Furthermore, synchronization information can be requested by using a 718 combination of RTP-Info (Section 18.45) and Range (Section 18.40). 720 RTSP 2.0 does not have a strong mechanism for providing negotiation 721 of the headers, or parameters and their formats, that can be used. 723 However, responses will indicate request-headers or parameters that 724 are not supported. A priori determination of what features are 725 available needs to be done through out-of-band mechanisms, like the 726 session description, or through the usage of feature tags 727 (Section 4.5). 729 2.5. Media Delivery 731 This document specifies how media is delivered with RTP [RFC3550] 732 over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. Additional 733 protocols may be specified in the future based on demand. 735 The usage of RTP as media delivery protocol requires some additional 736 information to function well. The PLAY response contains information 737 to enable reliable and timely delivery of how a client should 738 synchronize different sources in the different RTP sessions. It also 739 provides a mapping between RTP timestamps and the content time scale. 740 When the server wants to notify the client about the completion of 741 the media delivery, it sends a PLAY_NOTIFY request to the client. 742 The PLAY_NOTIFY request includes information about the stream end, 743 including the last RTP sequence number for each stream, thus enabling 744 the client to empty the buffer smoothly. 746 2.5.1. Media Delivery Manipulations 748 The basic playback functionality of RTSP enables delivery of a range 749 of requested content to the client at the pace intended by the 750 content's creator. However, RTSP can also manipulate the delivery to 751 the client in two ways. 753 Scale: The ratio of media content time delivered per unit playback 754 time. 756 Speed: The ratio of playback time delivered per unit of wallclock 757 time. 759 Both affect the media delivery per time unit. However, they 760 manipulate two independent time scales and the effects are possible 761 to combine. 763 Scale (Section 18.46) is used for fast forward or slow motion control 764 as it changes the amount of content timescale that should be played 765 back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0 766 results in that 2 seconds of content is played back every second of 767 playback. Scale = 1.0 is the default value that is used if no Scale 768 is specified, i.e., playback at the content's original rate. Scale 769 values between 0 and 1.0 is providing for slow motion. Scale can be 770 negative to allow for reverse playback in either regular pace (Scale 771 = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards 772 (-1.0 < Scale < 0). Scale = 0 would be equal to pause and is not 773 allowed. 775 In most cases the realization of scale means server side manipulation 776 of the media to ensure that the client can actually play it back. 777 The nature of these media manipulations and when they are needed is 778 highly media-type dependent. Let's consider an example with two 779 common media types audio and video. 781 It is very difficult to modify the playback rate of audio. A maximum 782 of 10-30% is possible by changing the pitch-rate of speech. Music 783 goes out of tune if one tries to manipulate the playback rate by 784 resampling it. This is a well known problem and audio is commonly 785 muted or played back in short segments with skips to keep up with the 786 current playback point. 788 For video it is possible to manipulate the frame rate, although the 789 rendering capabilities are often limited to certain frame rates. 790 Also the allowed bitrates in decoding, the structure used in the 791 encoding and the dependency between frames and other capabilities of 792 the rendering device limits the possible manipulations. Therefore, 793 the basic fast forward capabilities often are implemented by 794 selecting certain subsets of frames. 796 Due to the media restrictions, the possible scale values are commonly 797 restricted to the set of realizable scale ratios. To enable the 798 clients to select from the possible scale values, RTSP can signal the 799 supported Scale ratios for the content. To support aggregated or 800 dynamic content, where this may change during the ongoing session and 801 dependent on the location within the content, a mechanism for 802 updating the media properties and the scale factor currently in use, 803 exists. 805 Speed (Section 18.50) affects how much of the playback timeline is 806 delivered in a given wallclock period. The default is Speed = 1 807 which means to deliver at the same rate the media is consumed. Speed 808 > 1 means that the receiver will get content faster than it regularly 809 would consume it. Speed < 1 means that delivery is slower than the 810 regular media rate. Speed values of 0 or lower have no meaning and 811 are not allowed. This mechanism enables two general functionalities. 812 One is client side scale operations, i.e., the client receives all 813 the frames and makes the adjustment to the playback locally. The 814 second is delivery control for buffering of media. By specifying a 815 speed over 1.0 the client can build up the amount of playback time it 816 has present in its buffers to a level that is sufficient for its 817 needs. 819 A naive implementation of Speed would only affect the transmission 820 schedule of the media and has a clear impact on the needed bandwidth. 821 This would result in the data rate being proportional to the speed 822 factor. Speed = 1.5, i.e., 50% faster than normal delivery, would 823 result in a 50% increase in the data transport rate. If that can be 824 supported or not depends solely on the underlying network path. 825 Scale may also have some impact on the required bandwidth due to the 826 manipulation of the content in the new playback schedule. An example 827 is fast forward where only the independently decodable intra frames 828 are included in the media stream. This usage of solely intra frames 829 increases the data rate significantly compared to a normal sequence 830 with the same number of frames, where most frames are encoded using 831 prediction. 833 This potential increase of the data rate needs to be handled by the 834 media sender. The client has requested that the media will be 835 delivered in a specific way, which should be honored. However, the 836 media sender cannot ignore if the network path between the sender and 837 the receiver can't handle the resulting media stream. In that case 838 the media stream needs to be adapted to fit the available resources 839 of the path. This can result in a reduced media quality. 841 The need for bitrate adaptation becomes especially problematic in 842 connection with the Speed semantics. If the goal is to fill up the 843 buffer, the client may not want to do that at the cost of reduced 844 quality. If the client wants to make local playout changes then it 845 may actually require that the requested speed be honored. To resolve 846 this issue, Speed uses a range so that both cases can be supported. 847 The server is requested to use the highest possible speed value 848 within the range which is compatible with the available bandwidth. 849 As long as the server can maintain a speed value within the range it 850 shall not change the media quality, but instead modify the actual 851 delivery rate in response to available bandwidth and reflect this in 852 the Speed value in the response. However, if this is not possible, 853 the server should instead modify the media quality to respect the 854 lowest speed value and the available bandwidth. 856 This functionality enables the local scaling implementation to use a 857 tight range, or even a range where the lower bound equals the upper 858 bound, to identify that it requires the server to deliver the 859 requested amount of media time per delivery time independent of how 860 much it needs to adapt the media quality to fit within the available 861 path bandwidth. For buffer filling, it is suitable to use a range 862 with a reasonable span and with a lower bound at the nominal media 863 rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the 864 buffer, it can specify an upper bound that is below 1.0 to force the 865 server to deliver slower than the nominal media rate. 867 2.6. Session Maintenance and Termination 869 The session context that has been established is kept alive by having 870 the client show liveness. This is done in two main ways: 872 o Media transport protocol keep-alive. RTP Control Protocol (RTCP) 873 may be used when using RTP. 875 o Any RTSP request referencing the session context. 877 Section 10.5 discusses the methods for showing liveness in more 878 depth. If the client fails to show liveness for more than the 879 established session timeout value (normally 60 seconds), the server 880 may terminate the context. Other values may be selected by the 881 server through the inclusion of the timeout parameter in the session 882 header. 884 The session context is normally terminated by the client sending a 885 TEARDOWN request (Section 13.7) to the server referencing the 886 aggregated control URI. An individual media resource can be removed 887 from a session context by a TEARDOWN request referencing that 888 particular media resource. If all media resources are removed from a 889 session context, the session context is terminated. 891 A client may keep the session alive indefinitely if allowed by the 892 server; however, a client is recommended to release the session 893 context when an extended period of time without media delivery 894 activity has passed. The client can re-establish the session context 895 if required later. What constitutes an extended period of time is 896 dependent on the client, server and their usage. It is recommended 897 that the client terminates the session before ten times the session 898 timeout value has passed. A server may terminate the session after 899 one session timeout period without any client activity beyond keep- 900 alive. When a server terminates the session context, it does that by 901 sending a TEARDOWN request indicating the reason. 903 A server can also request that the client tear down the session and 904 re-establish it at an alternative server, as may be needed for 905 maintenance. This is done by using the REDIRECT method 906 (Section 13.10). The Terminate-Reason header (Section 18.52) is used 907 to indicate when and why. The Location header indicates where it 908 should connect if there is an alternative server available. When the 909 deadline expires, the server simply stops providing the service. To 910 achieve a clean closure, the client needs to initiate session 911 termination prior to the deadline. In case the server has no other 912 server to redirect to, and wants to close the session for 913 maintenance, it shall use the TEARDOWN method with a Terminate-Reason 914 header. 916 2.7. Extending RTSP 918 RTSP is quite a versatile protocol which supports extensions in many 919 different directions. Even this core specification contains several 920 blocks of functionality that are optional to implement. The use case 921 and need for the protocol deployment should determine what parts are 922 implemented. Allowing for extensions makes it possible for RTSP to 923 reach out to additional use cases. However, extensions will affect 924 the interoperability of the protocol and therefore it is important 925 that they can be added in a structured way. 927 The client can learn the capability of a server by using the OPTIONS 928 method (Section 13.1) and the Supported header (Section 18.51). It 929 can also try and possibly fail using new methods, or require that 930 particular features are supported using the Require (Section 18.43) 931 or Proxy-Require (Section 18.37) header. 933 The RTSP protocol in itself can be extended in three ways, listed 934 here in increasing order of the magnitude of changes supported: 936 o Existing methods can be extended with new parameters, for example, 937 headers, as long as these parameters can be safely ignored by the 938 recipient. If the client needs negative acknowledgment when a 939 method extension is not supported, a tag corresponding to the 940 extension may be added in the field of the Require or Proxy- 941 Require headers. 943 o New methods can be added. If the recipient of the message does 944 not understand the request, it must respond with error code 501 945 (Not Implemented) so that the sender can avoid using this method 946 again. A client may also use the OPTIONS method to inquire about 947 methods supported by the server. The server must list the methods 948 it supports using the Public response-header. 950 o A new version of the protocol can be defined, allowing almost all 951 aspects (except the position of the protocol version number) to 952 change. A new version of the protocol must be registered through 953 an IETF standards track document. 955 The basic capability discovery mechanism can be used to both discover 956 support for a certain feature and to ensure that a feature is 957 available when performing a request. For a detailed explanation of 958 this see Section 11. 960 New media delivery protocols may be added and negotiated at session 961 establishment, in addition to extensions to the core protocol. 962 Certain types of protocol manipulations can be done through parameter 963 formats using SET_PARAMETER and GET_PARAMETER. 965 3. Document Conventions 967 3.1. Notational Conventions 969 Since a few of the definitions are identical to HTTP/1.1, this 970 specification only points to the section where they are defined 971 rather than copying it. For brevity, [HX.Y] is to be taken to refer 972 to Section X.Y of the HTTP/1.1 specification ([RFC2616]). 974 All the mechanisms specified in this document are described in both 975 prose and the Augmented Backus-Naur form (ABNF) described in detail 976 in [RFC5234]. 978 Indented paragraphs are used to provide informative background and 979 motivation. This is intended to give readers who were not involved 980 with the formulation of the specification an understanding of why 981 things are the way they are in RTSP. 983 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 984 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 985 "OPTIONAL" in this document are to be interpreted as described in 986 [RFC2119]. 988 The word, "unspecified" is used to indicate functionality or features 989 that are not defined in this specification. Such functionality 990 cannot be used in a standardized manner without further definition in 991 an extension specification to RTSP. 993 3.2. Terminology 995 Aggregate control: The concept of controlling multiple streams using 996 a single timeline, generally maintained by the server. A client, 997 for example, uses aggregate control when it issues a single play 998 or pause message to simultaneously control both the audio and 999 video in a movie. A session which is under aggregate control is 1000 referred to as an aggregated session. 1002 Aggregate control URI: The URI used in an RTSP request to refer to 1003 and control an aggregated session. It normally, but not always, 1004 corresponds to the presentation URI specified in the session 1005 description. See Section 13.3 for more information. 1007 Client: The client requests media service from the media server. 1009 Connection: A transport layer virtual circuit established between 1010 two programs for the purpose of communication. 1012 Container file: A file which may contain multiple media streams 1013 which often constitutes a presentation when played together. The 1014 concept of a container file is not embedded in the protocol. 1015 However, RTSP servers may offer aggregate control on the media 1016 streams within these files. 1018 Continuous media: Data where there is a timing relationship between 1019 source and sink; that is, the sink needs to reproduce the timing 1020 relationship that existed at the source. The most common examples 1021 of continuous media are audio and motion video. Continuous media 1022 can be real-time (interactive or conversational), where there is a 1023 "tight" timing relationship between source and sink, or streaming 1024 where the relationship is less strict. 1026 Feature-tag: A tag representing a certain set of functionality, 1027 i.e., a feature. 1029 IRI: Internationalized Resource Identifier, is similar to a URI, but 1030 allows characters from the whole Universal Character Set (Unicode/ 1031 ISO 10646), rather than the US-ASCII only. See [RFC3987] for more 1032 information. 1034 Live: Normally used to describe a presentation or session with media 1035 coming from an ongoing event. This generally results in the 1036 session having an unbound or only loosely defined duration, and 1037 sometimes no seek operations are possible. 1039 Media initialization: Datatype/codec specific initialization. This 1040 includes such things as clock rates, color tables, etc. Any 1041 transport-independent information which is required by a client 1042 for playback of a media stream occurs in the media initialization 1043 phase of stream setup. 1045 Media parameter: Parameter specific to a media type that may be 1046 changed before or during stream delivery. 1048 Media server: The server providing media delivery services for one 1049 or more media streams. Different media streams within a 1050 presentation may originate from different media servers. A media 1051 server may reside on the same host or on a different host from 1052 which the presentation is invoked. 1054 (Media) stream: A single media instance, e.g., an audio stream or a 1055 video stream as well as a single whiteboard or shared application 1056 group. When using RTP, a stream consists of all RTP and RTCP 1057 packets created by a source within an RTP session. 1059 Message: The basic unit of RTSP communication, consisting of a 1060 structured sequence of octets matching the syntax defined in 1061 Section 20 and transmitted over a connection-based transport. A 1062 message is either a Request or a Response. 1064 Message Body: The information transferred as the payload of a 1065 message (Request or response). A message body consists of meta- 1066 information in the form of message-body headers and content in the 1067 form of a message-body, as described in Section 9. 1069 Non-Aggregated Control: Control of a single media stream. 1071 Presentation: A set of one or more streams presented to the client 1072 as a complete media feed and described by a presentation 1073 description as defined below. Presentations with more than one 1074 media stream are often handled in RTSP under aggregate control. 1076 Presentation description: A presentation description contains 1077 information about one or more media streams within a presentation, 1078 such as the set of encodings, network addresses and information 1079 about the content. Other IETF protocols such as SDP ([RFC4566]) 1080 use the term "session" for a presentation. The presentation 1081 description may take several different formats, including but not 1082 limited to the session description protocol format, SDP. 1084 Response: An RTSP response to a Request. One type of RTSP message. 1085 If an HTTP response is meant, it is indicated explicitly. 1087 Request: An RTSP request. One type of RTSP message. If an HTTP 1088 request is meant, it is indicated explicitly. 1090 Request-URI: The URI used in a request to indicate the resource on 1091 which the request is to be performed. 1093 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 1094 RTSP proxy. In this specification, there are many capabilities 1095 that are common to these three entities such as the capability to 1096 send requests or receive responses. This term will be used when 1097 describing functionality that is applicable to all three of these 1098 entities. 1100 RTSP session: A stateful abstraction upon which the main control 1101 methods of RTSP operate. An RTSP session is a common context; it 1102 is created and maintained on client's request and can be destroyed 1103 by either the client or server. It is established by an RTSP 1104 server upon the completion of a successful SETUP request (when a 1105 200 OK response is sent) and is labeled with a session identifier 1106 at that time. The session exists until timed out by the server or 1107 explicitly removed by a TEARDOWN request. An RTSP session is a 1108 stateful entity; an RTSP server maintains an explicit session 1109 state machine (see Appendix B) where most state transitions are 1110 triggered by client requests. The existence of a session implies 1111 the existence of state about the session's media streams and their 1112 respective transport mechanisms. A given session can have one or 1113 more media streams associated with it. An RTSP server uses the 1114 session to aggregate control over multiple media streams. 1116 Origin Server: The server on which a given resource resides. 1118 Transport initialization: The negotiation of transport information 1119 (e.g., port numbers, transport protocols) between the client and 1120 the server. 1122 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 1123 RTSP are generally URLs as they give a location for the resource. 1124 As URLs are a subset of URIs, they will be referred to as URIs to 1125 cover also the cases when an RTSP URI would not be an URL. 1127 URL: Universal Resource Locator, is a URI which identifies the 1128 resource through its primary access mechanism, rather than 1129 identifying the resource by name or by some other attribute(s) of 1130 that resource. 1132 4. Protocol Parameters 1134 4.1. RTSP Version 1136 This specification defines version 2.0 of RTSP. 1138 RTSP uses a "." numbering scheme to indicate versions 1139 of the protocol. The protocol versioning policy is intended to allow 1140 the sender to indicate the format of a message and its capacity for 1141 understanding further RTSP communication, rather than the features 1142 obtained via that communication. No change is made to the version 1143 number for the addition of message components which do not affect 1144 communication behavior or which only add to extensible field values. 1146 The number is incremented when the changes made to the 1147 protocol add features which do not change the general message parsing 1148 algorithm, but which may add to the message semantics and imply 1149 additional capabilities of the sender. The number is 1150 incremented when the format of a message within the protocol is 1151 changed. The version of an RTSP message is indicated by an RTSP- 1152 Version field in the first line of the message. Note that the major 1153 and minor numbers MUST be treated as separate integers and that each 1154 MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a 1155 lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. 1156 Leading zeros SHALL NOT be sent and MUST be ignored by recipients. 1158 4.2. RTSP IRI and URI 1160 RTSP 2.0 defines and registers or updates three URI schemes "rtsp", 1161 "rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified 1162 in RTSP 2.0, and is defined here to register the URI scheme that was 1163 defined in RTSP 1.0. The "rtspu" scheme indicates unspecified 1164 transport of the RTSP messages over unreliable transport (UDP in RTSP 1165 1.0). An RTSP server MUST respond with an error code indicating the 1166 "rtspu" scheme is not implemented (501) to a request that carries a 1167 "rtspu" URI scheme. 1169 The details of the syntax of "rtsp" and "rtsps" URIs has been changed 1170 from RTSP 1.0. These changes are: 1172 o Support for IPV6 literal in host part and future IP literals 1173 through RFC 3986 defined mechanism. 1175 o A new relative format to use in the RTSP protocol elements that is 1176 not required to start with "/". 1178 Neither should have any significant impact on interoperability. If 1179 one is required to use IPv6 literals to reach an RTSP server, then 1180 that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully 1181 IPv6 capable protocol. If an RTSP 1.0 client attempts to process the 1182 URI it will not match the allowed syntax and be considered invalid 1183 and processing will be stopped. This is clearly a failure to reach 1184 the resource, however it is not a signification issue as RTSP 2.0 1185 support was needed anyway in both server and client. Thus failure 1186 will only occur in a later step when there is a RTSP version mismatch 1187 between client and server. The second change will only occur inside 1188 RTSP message headers, as the request URI must be an absolute URI. 1189 Thus such usages will only occur after an agent has accepted and 1190 started processing RTSP 2.0 messages, and an RTSP 1.0 only agent will 1191 not be required to parse such types of relative URIs. 1193 This specification also defines the format of the RTSP IRI [RFC3987] 1194 that can be used as RTSP resource identifiers and locators, in web 1195 pages, user interfaces, on paper, etc. However, the RTSP request 1196 message format only allows usage of the absolute URI format. The 1197 RTSP IRI format MUST use the rules and transformation for IRIs to 1198 URIs, as defined in [RFC3987]. This allows a URI that matches the 1199 RTSP 2.0 specification, and so is suitable for use in a request, to 1200 be created from an RTSP IRI. 1202 The RTSP IRI and URI are both syntax restricted compared to the 1203 generic syntax defined in [RFC3986] and [RFC3987]: 1205 o An absolute URI requires the authority part; i.e., a host identity 1206 MUST be provided. 1208 o Parameters in the path element are prefixed with the reserved 1209 separator ";". 1211 The "scheme" and "host" parts of all URIs [RFC3986] and IRIs 1212 [RFC3987] are case-insensitive. All other parts of RTSP URIs and 1213 IRIs are case- sensitive, and MUST NOT be case-mapped. 1215 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1216 [RFC3986], i.e., the fragment is to be stripped from the IRI by the 1217 requester and not included in the request URI. The user agent needs 1218 to interpret the value of the fragment based on the media type the 1219 request relates to; i.e., the media type indicated in Content-Type 1220 header in the response to DESCRIBE. 1222 The syntax of any URI query string is unspecified and responder 1223 (usually the server) specific. The query is, from the requester's 1224 perspective, an opaque string and needs to be handled as such. 1225 Please note that relative URI with queries are difficult to handle 1226 due to the RFC 3986 relative URI handling rules. Any change of the 1227 path element using a relative URI results in the stripping of the 1228 query, which means the relative part needs to contain the query. 1230 The URI scheme "rtsp" requires that commands are issued via a 1231 reliable protocol (within the Internet, TCP), while the scheme 1232 "rtsps" identifies a reliable transport using secure transport (TLS 1233 [RFC5246], see (Section 19). 1235 For the scheme "rtsp", if no port number is provided in the authority 1236 part of the URI, the port number 554 MUST be used. For the scheme 1237 "rtsps", if no port number is provided in the authority part of the 1238 URI port number, the TCP port 322 MUST be used. 1240 A presentation or a stream is identified by a textual media 1241 identifier, using the character set and escape conventions of URIs 1242 [RFC3986]. URIs may refer to a stream or an aggregate of streams; 1243 i.e., a presentation. Accordingly, requests described in 1244 (Section 13) can apply to either the whole presentation or an 1245 individual stream within the presentation. Note that some request 1246 methods can only be applied to streams, not presentations, and vice 1247 versa. 1249 For example, the RTSP URI: 1251 rtsp://media.example.com:554/twister/audiotrack 1253 may identify the audio stream within the presentation "twister", 1254 which can be controlled via RTSP requests issued over a TCP 1255 connection to port 554 of host media.example.com. 1257 Also, the RTSP URI: 1259 rtsp://media.example.com:554/twister 1261 identifies the presentation "twister", which may be composed of audio 1262 and video streams, but could also be something else like a random 1263 media redirector. 1265 This does not imply a standard way to reference streams in URIs. 1266 The presentation description defines the hierarchical 1267 relationships in the presentation and the URIs for the individual 1268 streams. A presentation description may name a stream "a.mov" and 1269 the whole presentation "b.mov". 1271 The path components of the RTSP URI are opaque to the client and do 1272 not imply any particular file system structure for the server. 1274 This decoupling also allows presentation descriptions to be used 1275 with non-RTSP media control protocols simply by replacing the 1276 scheme in the URI. 1278 4.3. Session Identifiers 1280 Session identifiers are strings of length 8-128 characters. A 1281 session identifier MUST be generated cryptographically random (see 1282 [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, 1283 i.e., approximately 22 characters from a high quality generator (see 1284 Section 21). However, note that the session identifier does not 1285 provide any security against session hijacking unless it is kept 1286 confidential by the client, server and trusted proxies. 1288 4.4. Media Time Formats 1290 RTSP currently supports three different media time formats defined 1291 below. Additional time formats may be specified in the future. 1292 These time formats can be used with the Range header (Section 18.40) 1293 to request playback and specify at which media position protocol 1294 requests actually will or have taken place. They are also used in 1295 description of the media's properties using the Media-Range header 1296 (Section 18.30). The unqualified format identifier is used on its 1297 own in Accept-Ranges header (Section 18.5) to declare supported time 1298 formats and also in the Range header (Section 18.40) to request the 1299 time format used in the response. 1301 4.4.1. SMPTE Relative Timestamps 1303 A Society of Motion Picture and Television Engineers (SMPTE) relative 1304 timestamp expresses time relative to the start of the clip. Relative 1305 timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame- 1306 level access accuracy. The time code has the format 1308 hours:minutes:seconds:frames.subframes, 1310 with the origin at the start of the clip. The default SMPTE format 1311 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1312 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1313 through the use of "smpte-type". For SMPTE 30, the "frames" field in 1314 the time value can assume the values 0 through 29. The difference 1315 between 30 and 29.97 frames per second is handled by dropping the 1316 first two frame indices (values 00 and 01) of every minute, except 1317 every tenth minute. If the frame and the subframe values are zero, 1318 they may be omitted. Subframes are measured in one-hundredth of a 1319 frame. 1321 Examples: 1323 smpte=10:12:33:20- 1324 smpte=10:07:33- 1325 smpte=10:07:00-10:07:33:05.01 1326 smpte-25=10:07:00-10:07:33:05.01 1328 4.4.2. Normal Play Time 1330 Normal play time (NPT) indicates the stream absolute position 1331 relative to the beginning of the presentation. The timestamp 1332 consists of two parts: the mandatory first part may be expressed in 1333 either seconds or hours, minutes, and seconds. The optional second 1334 part consists of a decimal point and decimal figures and indicates 1335 fractions of a second. 1337 The beginning of a presentation corresponds to 0.0 seconds. Negative 1338 values are not defined. 1340 The special constant "now" is defined as the current instant of a 1341 live event. It MAY only be used for live events, and MUST NOT be 1342 used for on-demand (i.e., non-live) content. 1344 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1345 the clock the viewer associates with a program. It is often 1346 digitally displayed on a VCR. NPT advances normally when in normal 1347 play mode (scale = 1), advances at a faster rate when in fast scan 1348 forward (high positive scale ratio), decrements when in scan reverse 1349 (negative scale ratio) and is fixed in pause mode. NPT is 1350 (logically) equivalent to SMPTE time codes." 1352 Examples: 1354 npt=123.45-125 1355 npt=12:05:35.3- 1356 npt=now- 1358 The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the 1359 time elapsed since presentation start, with two different notations 1360 allowed: 1362 o The npt-hhmmss notation uses an ISO 8601 extended complete 1363 representation of the time of the day format (Section 5.3.1.1 of 1364 [ISO.8601.2000] ) using colon (":") as separators between hours, 1365 minutes and seconds (hh:mm:ss). The hour counter is not limited 1366 to 0-24 hours; up to nineteen (19) digits of hours are allowed. 1368 o In accordance with the requirements of the ISO 8601 time format, 1369 the hours, minutes, and seconds MUST all be present, with two 1370 digits used for minutes and for seconds, and with a least two 1371 digits for hours. An NPT of 7 minutes and 0 seconds is 1372 represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 1373 6 seconds is represented as "392:00:06". 1375 o RTSP 1.0 allowed NPT in the npt-hhmmss notation without any 1376 leading zeros, to ensure that implementations doesn't fail if any 1377 implementation follows the RTSP 1.0 format, all implementations 1378 are REQUIRED to support receiving NPT values, hours, minutes or 1379 seconds, without leading zeros. 1381 o The npt-sec notation expresses the time in seconds, using between 1382 one and nineteen (19) digits. 1384 Both notations allow decimal fractions of seconds as specified in 1385 Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and 1386 allowing only "." (full stop) as the decimal separator. 1388 The npt-sec notation is optimized for automatic generation, the npt- 1389 hhmmss notation for consumption by human readers. The "now" constant 1390 allows clients to request to receive the live feed rather than the 1391 stored or time-delayed version. This is needed since neither 1392 absolute time nor zero time are appropriate for this case. 1394 4.4.3. Absolute Time 1396 Absolute time is expressed following a specific types of ISO 8601 1397 [ISO.8601.2000] based timestamps. The date is complete 1398 representation calendar date in basic format (YYYYMMDD) without 1399 separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day 1400 is provided in the complete representation basic format (hhmmss) as 1401 specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal 1402 fractions of seconds following Section 5.3.1.3 requiring "." (full 1403 stop) as decimal separator and limiting the number of digits to no 1404 more than nine (9). The time expressed MUST be using UTC (GMT), i.e. 1405 no timezone offsets allowed. The full date and time specification is 1406 the eight digit date followed by a "T" followed by the six digits 1407 time value, optionally followed by a full stop followed by one to 1408 nine fractions of a second and ended by "Z", e.g. 1409 YYYYMMDDThhmmss.ssZ. 1411 The reason for this time format rather than using "Date and Time 1412 on the Internet: Timestamps" [RFC3339] are historic and using the 1413 format specified in RTSP 1.0. The motivations raised in RFC 3339 1414 applies to why a selection from ISO 8601 was done, but a different 1415 and even more restrictive selection was applied in this case. 1417 Example for clock format range request for a starting time of 1418 November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC 1419 playing for 10 min and 5 seconds, a Media-Properties header's "Time- 1420 Limited UTC property for 24th of December 2014 at 15 hours and 00 1421 mins, and a Terminate-Readon headers "time" property for 18th of June 1422 2013 at 16 hours, 12 minutes and 56 seconds: 1424 clock=19961108T143720.25Z-19961108T144725.25Z 1425 Time-Limited=20141224T1500Z 1426 time=20130618T161256Z 1428 4.5. Feature-Tags 1430 Feature-tags are unique identifiers used to designate features in 1431 RTSP. These tags are used in Require (Section 18.43), Proxy-Require 1432 (Section 18.37), Proxy-Supported (Section 18.38), Supported 1433 (Section 18.51) and Unsupported (Section 18.55) header fields. 1435 A feature-tag definition MUST indicate which combination of clients, 1436 servers or proxies it applies to. 1438 The creator of a new RTSP feature-tag should either prefix the 1439 feature-tag with a reverse domain name (e.g., 1440 "com.example.mynewfeature" is an apt name for a feature whose 1441 inventor can be reached at "example.com"), or register the new 1442 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1443 IANA Section 22). 1445 The usage of feature-tags is further described in Section 11 that 1446 deals with capability handling. 1448 4.6. Message Body Tags 1450 Message body tags are opaque strings that are used to compare two 1451 message bodies from the same resource, for example in caches or to 1452 optimize setup after a redirect. Message body tags can be carried in 1453 the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9). 1454 MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]). 1456 A message body tag MUST be unique across all versions of all message 1457 bodies associated with a particular resource. A given message body 1458 tag value MAY be used for message bodies obtained by requests on 1459 different URIs. The use of the same message body tag value in 1460 conjunction with message bodies obtained by requests on different 1461 URIs does not imply the equivalence of those message bodies 1463 Message body tags are used in RTSP to make some methods conditional. 1464 The methods are made conditional through the inclusion of headers; 1465 see "If-Match" (Section 18.24) and "If-None-Match" (Section 18.26). 1466 Note that RTSP message body tags apply to the complete presentation; 1467 i.e., both the presentation description and the individual media 1468 streams. Thus message body tags can be used to verify at setup time 1469 after a redirect that the same session description applies to the 1470 media at the new location using the If-Match header. 1472 4.7. Media Properties 1474 When an RTSP server handles media, it is important to consider the 1475 different properties a media instance for delivery and playback can 1476 have. This specification considers the media properties listed below 1477 in its protocol operations. They are derived from the differences 1478 between a number of supported usages. 1480 On-demand: Media that has a fixed (given) duration that doesn't 1481 change during the life time of the RTSP session and is known at 1482 the time of the creation of the session. It is expected that the 1483 content of the media will not change, even if the representation, 1484 i.e., encoding, quality, etc, may change. Generally one can seek, 1485 i.e., request any range, within the media. 1487 Dynamic On-demand: This is a variation of the on-demand case where 1488 external methods are used to manipulate the actual content of the 1489 media setup for the RTSP session. The main example is a content 1490 defined by a playlist. 1492 Live: Live media represents a progressing content stream (such as 1493 broadcast TV) where the duration may or may not be known. It is 1494 not seekable, only the content presently being delivered can be 1495 accessed. 1497 Live with Recording: A Live stream that is combined with a server- 1498 side capability to store and retain the content of the live 1499 session, and allow for random access delivery within the part of 1500 the already recorded content. The actual behavior of the media 1501 stream is very much dependent on the retention policy for the 1502 media stream; either the server will be able to capture the 1503 complete media stream, or it will have a limitation in how much 1504 will be retained. The media range will dynamically change as the 1505 session progress. For servers with a limited amount of storage 1506 available for recording, there will typically be a sliding window 1507 that moves forward while new data is made available and older data 1508 is discarded. 1510 To cover the above usages, the following media properties with 1511 appropriate values are specified: 1513 4.7.1. Random Access and Seeking 1515 Random Access is the ability to specify and get media delivered 1516 starting from any time instant within the content, an operation 1517 called seeking. The Media-Properties header will indicate the 1518 general capability for a media resource to perform random access: 1520 Random-Access: The media is seekable to any out of a large number of 1521 points within the media. Due to media encoding limitations, a 1522 particular point may not be reachable, but seeking to a point 1523 close by is enabled. A floating point number of seconds may be 1524 provided to express the worst case distance between random access 1525 points. 1527 Beginning-Only: Seeking is only possible to the beginning of the 1528 content. 1530 No-seeking: Seeking is not possible at all. 1532 If random access is possible, as indicated by the Media-Properties 1533 header, the actual behavior policy when seeking can be controlled 1534 using the Seek-Style header (Section 18.47). 1536 4.7.2. Retention 1538 Media may have different retention policies in place that affect the 1539 operation on media. The following different media retention policies 1540 are defined: 1542 Unlimited: The media will not be removed as long as the RTSP session 1543 is in existence. 1545 Time-Limited: The media will not be removed before the given 1546 wallclock time. After that time it may or may not be available 1547 any more. 1549 Time-Duration: The media (on fragment or unit basis) will be 1550 retained for the specified duration. 1552 4.7.3. Content Modifications 1554 There is also the question of how the content may change over time 1555 for a given media resource: 1557 Immutable: The content of the media will not change, even if the 1558 representation, i.e., encoding, quality, etc., may change. 1560 Dynamic: The content can change due to external methods or triggers, 1561 such as playlists, but this will be announced by explicit updates. 1563 Time-Progressing: As time progresses new content will become 1564 available. If the content also is retained it will become longer 1565 as everything between the start point and the point currently 1566 being made available can be accessed. If the media server uses a 1567 sliding window policy for retention, the start point will also 1568 change as time progresses. 1570 4.7.4. Supported Scale Factors 1572 Content often supports only a limited set or range of scales when 1573 delivering the media. To enable the client to know what values or 1574 ranges of scale operations that the whole content or the current 1575 position supports, a media properties attribute for this is defined 1576 which contains a list with the values and/or ranges that are 1577 supported. The attribute is named "Scales". The "Scales" attribute 1578 may be updated at any point in the content due to content consisting 1579 of spliced pieces or content being dynamically updated by out-of-band 1580 mechanisms. 1582 4.7.5. Mapping to the Attributes 1584 This section shows examples of how one would map the above usages to 1585 the properties and their values. 1587 Example of On-demand: 1588 Random Access: Random-Access=5.0, Content Modifications: 1589 Immutable, Retention: Unlimited or Time-Limited. 1591 Example of Dynamic On-demand: 1592 Random Access: Random-Access=3.0, Content Modifications: Dynamic, 1593 Retention: Unlimited or Time-Limited. 1595 Example of Live: 1596 Random Access: No-seeking, Content Modifications: Time- 1597 Progressing, Retention: Time-Duration=0.0 1599 Example of Live with Recording: 1600 Random Access: Random-Access=3.0, Content Modifications: Time- 1601 Progressing, Retention: Time-Duration=7200.0 1603 5. RTSP Message 1605 RTSP is a text-based protocol and uses the ISO 10646 character set in 1606 UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. 1608 Text-based protocols make it easier to add optional parameters in 1609 a self-describing manner. Since the number of parameters and the 1610 frequency of commands is low, processing efficiency is not a 1611 concern. Text-based protocols, if done carefully, also allow easy 1612 implementation of research prototypes in scripting languages such 1613 as TCL, Visual Basic and Perl. 1615 The ISO 10646 character set avoids character set switching, but is 1616 invisible to the application as long as US-ASCII is being used. This 1617 is also the encoding used for RTCP [RFC3550]. 1619 A request contains a method, the object the method is operating upon, 1620 and parameters to further describe the method. Methods are 1621 idempotent unless otherwise noted. Methods are also designed to 1622 require little or no state maintenance at the media server. 1624 5.1. Message Types 1626 RTSP messages are either requests from client to server, or server to 1627 client, and responses in the reverse direction. Request (Section 7) 1628 and Response (Section 8) messages use a format based on the generic 1629 message format of RFC 5322 [RFC5322] for transferring bodies (the 1630 payload of the message). Both types of messages consist of a start- 1631 line, zero or more header fields (also known as "headers"), an empty 1632 line (i.e., a line with nothing preceding the CRLF) indicating the 1633 end of the headers, and possibly the data of the message body. The 1634 below ABNF [RFC5234] is for information and the formal message 1635 specification is present in Section 20.2.2. 1637 generic-message = start-line 1638 *(rtsp-header CRLF) 1639 CRLF 1640 [ message-body-data ] 1641 start-line = Request-Line | Status-Line 1643 In the interest of robustness, agents MUST ignore any empty line(s) 1644 received where a Request-Line or Status-Line is expected. In other 1645 words, if the agent is reading the protocol stream at the beginning 1646 of a message and receives any number of CRLFs first, it MUST ignore 1647 any of the CRLFs. 1649 5.2. Message Headers 1651 RTSP header fields (see Section 18) include general-header, request- 1652 header, response-header, and message-body header fields. 1654 The order in which header fields with differing field names are 1655 received is not significant. However, it is "good practice" to send 1656 general-header fields first, followed by request-header or response- 1657 header fields, and ending with the Message-body header fields. 1659 Multiple header fields with the same field-name MAY be present in a 1660 message if and only if the entire field-value for that header field 1661 is defined as a comma-separated list. It MUST be possible to combine 1662 the multiple header fields into one "field-name: field-value" pair, 1663 without changing the semantics of the message, by appending each 1664 subsequent field-value to the first, each separated by a comma. The 1665 order in which header fields with the same field-name are received is 1666 therefore significant to the interpretation of the combined field 1667 value, and thus a proxy MUST NOT change the order of these field 1668 values when a message is forwarded. 1670 Unknown message headers MUST be ignored (skipping over the header to 1671 the next protocol element, and not causing an error) by a RTSP server 1672 or client. An RTSP Proxy MUST forward unknown message headers. 1673 Message headers defined outside of this specification that are 1674 required to be interpreted by the RTSP agent will need to use feature 1675 tags (Section 4.5) and include them in the appropriate Require 1676 (Section 18.43) or Proxy-Require (Section 18.37) header. 1678 5.3. Message Body 1680 The message body (if any) of an RTSP message is used to carry further 1681 information for a particular resource associated with the request or 1682 response. An example of a message body is a Session Description 1683 Protocol (SDP) message. 1685 The presence of a message body in either a request or a response MUST 1686 be signaled by the inclusion of a Content-Length header (see 1687 Section 18.17) and Content-Type (see Section 18.19). A message body 1688 MUST NOT be included in a request or response if the specification of 1689 the particular method (see Method Definitions (Section 13)) does not 1690 allow sending a message body. In case a message body is received in 1691 a message when not expected the message body data SHOULD be 1692 discarded. This is to allow future extensions to define optional use 1693 of a message body. 1695 5.4. Message Length 1697 An RTSP Message that does not contain any message body is terminated 1698 by the first empty line after the header fields (Note: An empty line 1699 is a line with nothing preceding the CRLF.). In RTSP messages that 1700 contain message bodies the empty line is followed by the message 1701 body. The length of that body is determined by the value of the 1702 Content-Length header (Section 18.17). The value in the header 1703 represents the length of the message-body in octets. If this header 1704 field is not present, a value of zero is assumed, i.e., no message 1705 body present in the message. Unlike an HTTP message, an RTSP message 1706 MUST contain a Content-Length header whenever it contains a message 1707 body. Note that RTSP does not support the HTTP/1.1 "chunked" 1708 transfer coding (see [H3.6.1]). 1710 Given the moderate length of presentation descriptions returned, 1711 the server should always be able to determine its length, even if 1712 it is generated dynamically, making the chunked transfer encoding 1713 unnecessary. 1715 6. General Header Fields 1717 General headers are headers that may be used in both requests and 1718 responses. The general-headers are listed in Table 1: 1720 +--------------------+--------------------+ 1721 | Header Name | Defined in Section | 1722 +--------------------+--------------------+ 1723 | Accept-Ranges | Section 18.5 | 1724 | | | 1725 | Cache-Control | Section 18.11 | 1726 | | | 1727 | Connection | Section 18.12 | 1728 | | | 1729 | CSeq | Section 18.20 | 1730 | | | 1731 | Date | Section 18.21 | 1732 | | | 1733 | Media-Properties | Section 18.29 | 1734 | | | 1735 | Media-Range | Section 18.30 | 1736 | | | 1737 | Pipelined-Requests | Section 18.33 | 1738 | | | 1739 | Proxy-Supported | Section 18.38 | 1740 | | | 1741 | Range | Section 18.40 | 1742 | | | 1743 | RTP-Info | Section 18.45 | 1744 | | | 1745 | Scale | Section 18.46 | 1746 | | | 1747 | Seek-Style | Section 18.47 | 1748 | | | 1749 | Server | Section 18.48 | 1750 | | | 1751 | Session | Section 18.49 | 1752 | | | 1753 | Speed | Section 18.50 | 1754 | | | 1755 | Supported | Section 18.51 | 1756 | | | 1757 | Timestamp | Section 18.53 | 1758 | | | 1759 | Transport | Section 18.54 | 1760 | | | 1761 | User-Agent | Section 18.56 | 1762 | | | 1763 | Via | Section 18.57 | 1764 +--------------------+--------------------+ 1766 Table 1: The general headers used in RTSP 1768 7. Request 1770 A request message uses the format outlined below regardless of the 1771 direction of a request, client to server or server to client: 1773 o Request line, containing the method to be applied to the resource, 1774 the identifier of the resource, and the protocol version in use; 1776 o Zero or more Header lines, that can be of the following types: 1777 general-headers (Section 6), request-headers (Section 7.2), or 1778 message body headers (Section 9.1); 1780 o One empty line (CRLF) to indicate the end of the header section; 1782 o Optionally a message-body, consisting of one or more lines. The 1783 length of the message body in octets is indicated by the Content- 1784 Length message header. 1786 7.1. Request Line 1788 The request line provides the key information about the request: what 1789 method, on what resources and using which RTSP version. The methods 1790 that are defined by this specification are listed in Table 2. 1792 +---------------+--------------------+ 1793 | Method | Defined in Section | 1794 +---------------+--------------------+ 1795 | DESCRIBE | Section 13.2 | 1796 | | | 1797 | GET_PARAMETER | Section 13.8 | 1798 | | | 1799 | OPTIONS | Section 13.1 | 1800 | | | 1801 | PAUSE | Section 13.6 | 1802 | | | 1803 | PLAY | Section 13.4 | 1804 | | | 1805 | PLAY_NOTIFY | Section 13.5 | 1806 | | | 1807 | REDIRECT | Section 13.10 | 1808 | | | 1809 | SETUP | Section 13.3 | 1810 | | | 1811 | SET_PARAMETER | Section 13.9 | 1812 | | | 1813 | TEARDOWN | Section 13.7 | 1814 +---------------+--------------------+ 1816 Table 2: The RTSP Methods 1818 The syntax of the RTSP request line is the following: 1820 SP SP CRLF 1822 Note: This syntax cannot be freely changed in future versions of 1823 RTSP. This line needs to remain parsable by older RTSP 1824 implementations since it indicates the RTSP version of the message. 1826 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1827 resource through an absolute RTSP URI (including scheme, host, and 1828 port) (see Section 4.2) rather than just the absolute path. 1830 HTTP/1.1 requires servers to understand the absolute URI, but 1831 clients are supposed to use the Host request-header. This is 1832 purely needed for backward-compatibility with HTTP/1.0 servers, a 1833 consideration that does not apply to RTSP. 1835 An asterisk "*" can be used instead of an absolute URI in the 1836 Request-URI part to indicate that the request does not apply to a 1837 particular resource, but to the server or proxy itself, and is only 1838 allowed when the request method does not necessarily apply to a 1839 resource. 1841 For example: 1843 OPTIONS * RTSP/2.0 1845 An OPTIONS in this form will determine the capabilities of the server 1846 or the proxy that first receives the request. If the capability of 1847 the specific server needs to be determined, without regard to the 1848 capability of an intervening proxy, the server should be addressed 1849 explicitly with an absolute URI that contains the server's address. 1851 For example: 1853 OPTIONS rtsp://example.com RTSP/2.0 1855 7.2. Request Header Fields 1857 The RTSP headers in Table 3 can be included in a request, as request- 1858 headers, to modify the specifics of the request. 1860 +---------------------+--------------------+ 1861 | Header | Defined in Section | 1862 +---------------------+--------------------+ 1863 | Accept | Section 18.1 | 1864 | | | 1865 | Accept-Credentials | Section 18.2 | 1866 | | | 1867 | Accept-Encoding | Section 18.3 | 1868 | | | 1869 | Accept-Language | Section 18.4 | 1870 | | | 1871 | Authorization | Section 18.8 | 1872 | | | 1873 | Bandwidth | Section 18.9 | 1874 | | | 1875 | Blocksize | Section 18.10 | 1876 | | | 1877 | From | Section 18.23 | 1878 | | | 1879 | If-Match | Section 18.24 | 1880 | | | 1881 | If-Modified-Since | Section 18.25 | 1882 | | | 1883 | If-None-Match | Section 18.26 | 1884 | | | 1885 | Notify-Reason | Section 18.32 | 1886 | | | 1887 | Proxy-Authorization | Section 18.36 | 1888 | | | 1889 | Proxy-Require | Section 18.37 | 1890 | | | 1891 | Referrer | Section 18.41 | 1892 | | | 1893 | Request-Status | Section 18.42 | 1894 | | | 1895 | Require | Section 18.43 | 1896 | | | 1897 | Terminate-Reason | Section 18.52 | 1898 +---------------------+--------------------+ 1900 Table 3: The RTSP request headers 1902 Detailed header definitions are provided in Section 18. 1904 New request-headers may be defined. If the receiver of the request 1905 is required to understand the request-header, the request MUST 1906 include a corresponding feature tag in a Require or Proxy-Require 1907 header to ensure the processing of the header. 1909 8. Response 1911 After receiving and interpreting a request message, the recipient 1912 responds with an RTSP response message. Normally, there is only one, 1913 final, response. Only responses using the response code class 1xx, 1914 are allowed to send one or more 1xx response messages prior to the 1915 final response message. 1917 The valid response codes and the methods they can be used with are 1918 listed in Table 4. 1920 8.1. Status-Line 1922 The first line of a Response message is the Status-Line, consisting 1923 of the protocol version followed by a numeric status code and the 1924 textual phrase associated with the status code, with each element 1925 separated by SP characters. No CR or LF is allowed except in the 1926 final CRLF sequence. 1928 SP SP CRLF 1930 8.1.1. Status Code and Reason Phrase 1932 The Status-Code element is a 3-digit integer result code of the 1933 attempt to understand and satisfy the request. These codes are fully 1934 defined in Section 17. The Reason-Phrase is intended to give a short 1935 textual description of the Status-Code. The Status-Code is intended 1936 for use by automata and the Reason-Phrase is intended for the human 1937 user. The client is not required to examine or display the Reason- 1938 Phrase. 1940 The first digit of the Status-Code defines the class of response. 1941 The last two digits do not have any categorization role. There are 5 1942 values for the first digit: 1944 1xx: Informational - Request received, continuing process 1946 2xx: Success - The action was successfully received, understood, and 1947 accepted 1949 3rr: Redirection - Further action needs to be taken in order to 1950 complete the request (3rr rather than 3xx is used as 304 is 1951 excluded, see Section 17.3) 1953 4xx: Client Error - The request contains bad syntax or cannot be 1954 fulfilled 1956 5xx: Server Error - The server failed to fulfill an apparently valid 1957 request 1959 The individual values of the numeric status codes defined for RTSP/ 1960 2.0, and an example set of corresponding Reason-Phrases, are 1961 presented in Table 4. The reason phrases listed here are only 1962 recommended; they may be replaced by local equivalents without 1963 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1964 [RFC2616] status codes and adds RTSP-specific status codes starting 1965 at x50 to avoid conflicts with future HTTP status codes that are 1966 desirable to import into RTSP. All these codes are RTSP specific and 1967 RTSP has its own registry separate from HTTP for status codes. 1969 RTSP status codes are extensible. RTSP applications are not required 1970 to understand the meaning of all registered status codes, though such 1971 understanding is obviously desirable. However, applications MUST 1972 understand the class of any status code, as indicated by the first 1973 digit, and treat any unrecognized response as being equivalent to the 1974 x00 status code of that class, with an exception for unknown 3xx 1975 codes, which MUST be treated as a 302 (Found). The reason being that 1976 no 300 (Multiple Choices in HTTP) is defined for RTSP. An response 1977 with an unrecognized status code MUST NOT be cached. For example, if 1978 an unrecognized status code of 431 is received by the client, it can 1979 safely assume that there was something wrong with its request and 1980 treat the response as if it had received a 400 status code. In such 1981 cases, user agents SHOULD present to the user the message body 1982 returned with the response, since that message body is likely to 1983 include human-readable information which will explain the unusual 1984 status. 1986 +------+---------------------------------+--------------------------+ 1987 | Code | Reason | Method | 1988 +------+---------------------------------+--------------------------+ 1989 | 100 | Continue | all | 1990 | | | | 1991 | | | | 1992 | | | | 1993 | 200 | OK | all | 1994 | | | | 1995 | | | | 1996 | | | | 1997 | 301 | Moved Permanently | all | 1998 | | | | 1999 | 302 | Found | all | 2000 | | | | 2001 | 303 | reserved | n/a | 2002 | | | | 2003 | 304 | Not Modified | all | 2004 | | | | 2005 | 305 | Use Proxy | all | 2006 | | | | 2007 | | | | 2008 | | | | 2009 | 400 | Bad Request | all | 2010 | | | | 2011 | 401 | Unauthorized | all | 2012 | | | | 2013 | 402 | Payment Required | all | 2014 | | | | 2015 | 403 | Forbidden | all | 2016 | | | | 2017 | 404 | Not Found | all | 2018 | | | | 2019 | 405 | Method Not Allowed | all | 2020 | | | | 2021 | 406 | Not Acceptable | all | 2022 | | | | 2023 | 407 | Proxy Authentication Required | all | 2024 | | | | 2025 | 408 | Request Timeout | all | 2026 | | | | 2027 | 410 | Gone | all | 2028 | | | | 2029 | 412 | Precondition Failed | DESCRIBE, SETUP | 2030 | | | | 2031 | 413 | Request Message Body Too Large | all | 2032 | | | | 2033 | 414 | Request-URI Too Long | all | 2034 | | | | 2035 | 415 | Unsupported Media Type | all | 2036 | | | | 2037 | 451 | Parameter Not Understood | SET_PARAMETER, | 2038 | | | GET_PARAMETER | 2039 | | | | 2040 | 452 | reserved | n/a | 2041 | | | | 2042 | 453 | Not Enough Bandwidth | SETUP | 2043 | | | | 2044 | 454 | Session Not Found | all | 2045 | | | | 2046 | 455 | Method Not Valid In This State | all | 2047 | | | | 2048 | 456 | Header Field Not Valid | all | 2049 | | | | 2050 | 457 | Invalid Range | PLAY, PAUSE | 2051 | | | | 2052 | 458 | Parameter Is Read-Only | SET_PARAMETER | 2053 | | | | 2054 | 459 | Aggregate Operation Not Allowed | all | 2055 | | | | 2056 | 460 | Only Aggregate Operation | all | 2057 | | Allowed | | 2058 | | | | 2059 | 461 | Unsupported Transport | all | 2060 | | | | 2061 | 462 | Destination Unreachable | all | 2062 | | | | 2063 | 463 | Destination Prohibited | SETUP | 2064 | | | | 2065 | 464 | Data Transport Not Ready Yet | PLAY | 2066 | | | | 2067 | 465 | Notification Reason Unknown | PLAY_NOTIFY | 2068 | | | | 2069 | 466 | Key Management Error | all | 2070 | | | | 2071 | 470 | Connection Authorization | all | 2072 | | Required | | 2073 | | | | 2074 | 471 | Connection Credentials not | all | 2075 | | accepted | | 2076 | | | | 2077 | 472 | Failure to establish secure | all | 2078 | | connection | | 2079 | | | | 2080 | | | | 2081 | | | | 2082 | 500 | Internal Server Error | all | 2083 | | | | 2084 | 501 | Not Implemented | all | 2085 | | | | 2086 | 502 | Bad Gateway | all | 2087 | | | | 2088 | 503 | Service Unavailable | all | 2089 | | | | 2090 | 504 | Gateway Timeout | all | 2091 | | | | 2092 | 505 | RTSP Version Not Supported | all | 2093 | | | | 2094 | 551 | Option Not Supported | all | 2095 | | | | 2096 | 553 | Proxy Unavailable | all | 2097 +------+---------------------------------+--------------------------+ 2099 Table 4: Status codes and their usage with RTSP methods 2101 8.2. Response Headers 2103 The response-headers allow the request recipient to pass additional 2104 information about the response which cannot be placed in the Status- 2105 Line. This header gives information about the server and about 2106 further access to the resource identified by the Request-URI. All 2107 headers currently classified as response-headers are listed in 2108 Table 5. 2110 +------------------------+--------------------+ 2111 | Header | Defined in Section | 2112 +------------------------+--------------------+ 2113 | Authentication-Info | Section 18.7 | 2114 | | | 2115 | Connection-Credentials | Section 18.13 | 2116 | | | 2117 | Location | Section 18.28 | 2118 | | | 2119 | MTag | Section 18.31 | 2120 | | | 2121 | Proxy-Authenticate | Section 18.34 | 2122 | | | 2123 | Public | Section 18.39 | 2124 | | | 2125 | Retry-After | Section 18.44 | 2126 | | | 2127 | Unsupported | Section 18.55 | 2128 | | | 2129 | WWW-Authenticate | Section 18.58 | 2130 +------------------------+--------------------+ 2132 Table 5: The RTSP response headers 2134 Response-header names can be extended reliably only in combination 2135 with a change in the protocol version. However, the usage of 2136 feature-tags in the request allows the responding party to learn the 2137 capability of the receiver of the response. A new or experimental 2138 header can be given the semantics of response-header if all parties 2139 in the communication recognize them to be a response-header. 2140 Unrecognized headers in responses MUST be ignored. 2142 9. Message Body 2144 Some Request and Response messages include a message body, if not 2145 otherwise restricted by the request method or response status code. 2146 The message body consists of the content data itself (see also 2147 Section 5.3). 2149 The SET_PARAMETER and GET_PARAMETER requests and responses, and the 2150 DESCRIBE response as defined by this specification can have a message 2151 body; the purpose of the message body is defined in each case. All 2152 4xx and 5xx responses MAY also have a message body to carry 2153 additional response information. Generally a message body MAY be 2154 attached to any RTSP 2.0 request or response, but the content of the 2155 message body MAY be ignored by the receiver. Extensions to this 2156 specification can specify the purpose and content of message bodies, 2157 including requiring their inclusion. 2159 In this section, both sender and recipient refer to either the client 2160 or the server, depending on who sends and who receives the message 2161 body. 2163 9.1. Message-Body Header Fields 2165 Message-body header fields define meta-information about the content 2166 data in the message body. The message-body header fields are listed 2167 in Table 6. 2169 +------------------+--------------------+ 2170 | Header | Defined in Section | 2171 +------------------+--------------------+ 2172 | Allow | Section 18.6 | 2173 | | | 2174 | Content-Base | Section 18.14 | 2175 | | | 2176 | Content-Encoding | Section 18.15 | 2177 | | | 2178 | Content-Language | Section 18.16 | 2179 | | | 2180 | Content-Length | Section 18.17 | 2181 | | | 2182 | Content-Location | Section 18.18 | 2183 | | | 2184 | Content-Type | Section 18.19 | 2185 | | | 2186 | Expires | Section 18.22 | 2187 | | | 2188 | Last-Modified | Section 18.27 | 2189 +------------------+--------------------+ 2191 Table 6: The RTSP message-body headers 2193 The extension-header mechanism allows additional message-body header 2194 fields to be defined without changing the protocol, but these fields 2195 cannot be assumed to be recognizable by the recipient. Unrecognized 2196 header fields MUST be ignored by the recipient and forwarded by 2197 proxies. 2199 9.2. Message Body 2201 An RTSP message with a message body MUST include the Content-Type and 2202 Content-Length headers. When a message body is included with a 2203 message, the data type of that content data is determined via the 2204 header fields Content-Type and Content-Encoding. 2206 Content-Type specifies the media type of the underlying data. There 2207 is no default media format and the actual format used in the body is 2208 required to be explicitly stated in the Content-Type header. By 2209 being explicit and always require inclusion of the Content-Type 2210 header with accurate information one avoids the many pitfalls in 2211 heuristic based interpretation of the body content. These are issue 2212 HTTP and email have suffered from. 2214 Content-Encoding may be used to indicate any additional content 2215 codings applied to the data, usually for the purpose of data 2216 compression, that are a property of the requested resource. The 2217 default encoding is 'identity', i.e. no transformation of the message 2218 body. 2220 The Content-Length of a message is the length of the content, 2221 measured in octets. 2223 9.3. Message Body Format Negotiation 2225 The content format of the message body is provided using the Content- 2226 Type header (Section 18.19). To enable the responder of a request to 2227 determine which media type it should use, the requestor may include 2228 the Accept header (Section 18.1) in a request to identify supported 2229 media types or media type ranges suitable to the response. In case 2230 the responder is not supporting any of the specified formats, then 2231 the request response will be a 406 (Not Acceptable) error code. 2233 The media types that may be used on requests with message bodies need 2234 to be determined through the use of feature-tags, specification 2235 requirement or trial and error. Trial and error works because when 2236 the responder does not support the media type of the message body it 2237 will respond with a 415 (Unsupported Media Type). 2239 The formats supported and their negotiation is done individually on a 2240 per method and direction (request or response body) direction. 2241 Requirements on supporting particular media types for use as message 2242 bodies in requests and response SHALL also be specified on per method 2243 and direction basis. 2245 10. Connections 2247 RTSP Messages are transferred between RTSP agents and proxies using a 2248 transport connection. This transport connection uses TCP or TCP/TLS. 2249 This transport connection is referred to as the 'connection' or 'RTSP 2250 connection' within this document. 2252 RTSP requests can be transmitted using the two different connection 2253 scenarios listed below: 2255 o persistent - a transport connection is used for several request/ 2256 response transactions; 2258 o transient - a transport connection is used for each single request 2259 /response transaction. 2261 RFC 2326 attempted to specify an optional mechanism for transmitting 2262 RTSP messages in connectionless mode over a transport protocol such 2263 as UDP. However, it was not specified in sufficient detail to allow 2264 for interoperable implementations. In an attempt to reduce 2265 complexity and scope, and due to lack of interest, RTSP 2.0 does not 2266 attempt to define a mechanism for supporting RTSP over UDP or other 2267 connectionless transport protocols. A side-effect of this is that 2268 RTSP requests MUST NOT be sent to multicast groups since no 2269 connection can be established with a specific receiver in multicast 2270 environments. 2272 Certain RTSP headers, such as the CSeq header (Section 18.20), which 2273 may appear to be relevant only to connectionless transport scenarios 2274 are still retained and MUST be implemented according to the 2275 specification. In the case of CSeq, it is quite useful for matching 2276 responses to requests if the requests are pipelined (see Section 12). 2277 It is also useful in proxies for keeping track of the different 2278 requests when aggregating several client requests on a single TCP 2279 connection. 2281 10.1. Reliability and Acknowledgements 2283 Since RTSP messages are transmitted using reliable transport 2284 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 2285 Instead, the implementation must rely on the underlying transport to 2286 provide reliability. The RTSP implementation may use any indication 2287 of reception acknowledgment of the message from the underlying 2288 transport protocols to optimize the RTSP behavior. 2290 If both the underlying reliable transport such as TCP and the RTSP 2291 application retransmit requests, each packet loss or message loss 2292 may result in two retransmissions. The receiver typically cannot 2293 take advantage of the application-layer retransmission since the 2294 transport stack will not deliver the application-layer 2295 retransmission before the first attempt has reached the receiver. 2296 If the packet loss is caused by congestion, multiple 2297 retransmissions at different layers will exacerbate the 2298 congestion. 2300 Lack of acknowledgment of an RTSP request should be handled within 2301 the constraints of the connection timeout considerations described 2302 below (Section 10.4). 2304 10.2. Using Connections 2306 A TCP transport can be used for both persistent connections (for 2307 several message exchanges) and transient connections (for a single 2308 message exchange). Implementations of this specification MUST 2309 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 2310 allows the client to specify the port it will contact the server on, 2311 and defines the default port to use if one is not explicitly given. 2313 In addition to the registered default ports, i.e., 554 (rtsp) and 322 2314 (rtsps), there is an alternative port 8554 registered. This port may 2315 provide some benefits over non-registered ports if a RTSP server is 2316 unable to use the default ports. The benefits may include pre- 2317 configured security policies as well as classifiers in network 2318 monitoring tools. 2320 A RTSP client opening a TCP connection for accessing a particular 2321 resource as identified by a URI uses the IP address and port derived 2322 from the host and port parts of the URI. The IP address is either 2323 the explicit address provided in the URI or any of the addresses 2324 provided when performing A and AAAA record DNS lookups of the host 2325 name in the URI. 2327 A server MUST handle both persistent and transient connections. 2329 Transient connections facilitate mechanisms for fault tolerance. 2330 They also allow for application layer mobility. A server and 2331 client pair that support transient connections can survive the 2332 loss of a TCP connection; e.g., due to a NAT timeout. When the 2333 client has discovered that the TCP connection has been lost, it 2334 can set up a new one when there is need to communicate again. 2336 A persistent connection is RECOMMENDED to be used for all 2337 transactions between the server and client, including messages for 2338 multiple RTSP sessions. However, a persistent connection MAY be 2339 closed after a few message exchanges. For example, a client may use 2340 a persistent connection for the initial SETUP and PLAY message 2341 exchanges in a session and then close the connection. Later, when 2342 the client wishes to send a new request, such as a PAUSE for the 2343 session, a new connection would be opened. This connection may 2344 either be transient or persistent. 2346 An RTSP agent MAY use one connection to handle multiple RTSP sessions 2347 on the same server. The RTSP agent SHALL NOT use more than one 2348 connection per RTSP session at any given point. 2350 Having only one connection in use at any time avoids confusion on 2351 which connection any server to client requests shall be sent on. 2352 Using a single connection for multiple RTSP session also saves 2353 complexity by enabling the server to maintain less state about its 2354 connection resources on the server. Not using more than one 2355 connection at a time for a particular RTSP session avoids wasting 2356 connection resources and allows the server to track only the most 2357 recently used client to server connection for each RTSP session as 2358 being the currently valid server to client connection. 2360 RTSP allows a server to send requests to a client. However, this can 2361 be supported only if a client establishes a persistent connection 2362 with the server. In cases where a persistent connection does not 2363 exist between a server and its client, due to the lack of a signaling 2364 channel the server may be forced to silently discard RTSP messages, 2365 and may even drop an RTSP session without notifying the client. An 2366 example of such a case is when the server desires to send a REDIRECT 2367 request for an RTSP session to the client but is not able to do so 2368 because it cannot reach the client. A server that attempts to send a 2369 request to a client that has no connection currently to the server 2370 SHALL discard the request. 2372 Without a persistent connection between the client and the server, 2373 the media server has no reliable way of reaching the client. 2374 Because the likely failure of server to client established 2375 connections the server will not even attempt establishing any 2376 connection. 2378 Queuing of server to client requests has been considered. However 2379 a security issue exists as to how it might be possible to 2380 authorize a client establishing a new connection as being a 2381 legitimate receiver of a request related to a particular RTSP 2382 session, without the client first issuing requests related to the 2383 pending request. Thus, it would be likely to make any such 2384 requests even more delayed and less useful. 2386 The sending of client and server requests can be asynchronous events. 2387 To avoid deadlock situations both client and server MUST be able to 2388 send and receive requests simultaneously. As an RTSP response may be 2389 queued up for transmission, reception or processing behind the peer 2390 RTSP agent's own requests, all RTSP agents are required to have a 2391 certain capability of handling outstanding messages. A potential 2392 issue is that outstanding requests may timeout despite them being 2393 processed by the peer due to the response being caught in the queue 2394 behind a number of requests that the RTSP agent is processing but 2395 that take some time to complete. To avoid this problem an RTSP agent 2396 is recommended to buffer incoming messages locally so that any 2397 response messages can be processed immediately upon reception. If 2398 responses are separated from requests and directly forwarded for 2399 processing, not only can the result be used immediately, the state 2400 associated with that outstanding request can also be released. 2401 However, buffering a number of requests on the receiving RTSP agent 2402 consumes resources and enables a resource exhaustion attack on the 2403 agent. Therefore this buffer should be limited so that an 2404 unreasonable number of requests or total message size is not allowed 2405 to consume the receiving agent's resources. In most APIs, having the 2406 receiving agent stop reading from the TCP socket will result in TCP's 2407 window being clamped. Thus forcing the buffering onto the sending 2408 agent when the load is larger than expected. However, as both RTSP 2409 message sizes and frequency may be changed in the future by protocol 2410 extensions, an agent should be careful against taking harsher 2411 measurements against a potential attack. When under attack an RTSP 2412 agent can close TCP connections and release state associated with 2413 that TCP connection. 2415 To provide some guidance on what is reasonable the following 2416 guidelines are given. It is RECOMMENDED that: 2418 o an RTSP agent should not have more than 10 outstanding requests 2419 per RTSP session; 2421 o an RTSP agent should not have more than 10 outstanding requests 2422 that are not related to an RTSP session or that are requesting to 2423 create an RTSP session. 2425 In light of the above, it is RECOMMENDED that clients use persistent 2426 connections whenever possible. A client that supports persistent 2427 connections MAY "pipeline" its requests (see Section 12). 2429 RTSP Agents can send requests to multiple different destinations, 2430 either servers or client contexts over the same connection to a 2431 proxy. Then the proxy forks the message to the different 2432 destinations over proxy to agent connections. In these cases when 2433 multiple requests are outstanding the requesting agent MUST be ready 2434 to receive the responses out of order compared to the order they 2435 where sent on the connection. The order between multiple messages 2436 for each destination will be maintained, however, the order between 2437 response from different destinations can be different. 2439 The reason for this is to avoid a head-of-line blocking 2440 sitauation. In a sequence of requests an early outstanding 2441 request may take time to be processed at one destination. 2442 Simultaneously, a response from any other destination that was 2443 later in the sequence of requests, may have arrived at the proxy. 2444 Thus allowing out-of-order responses avoids forcing the proxy to 2445 buffer this response and instead deliver it as soon as possible. 2446 Note, this will not affect the order in which the messages sent to 2447 each separate destination were processed at request destination. 2449 This scenario can occur in two cases involving proxies. The first is 2450 a client issuing requests for sessions on different servers using a 2451 common client to proxy connection. The second is for server to 2452 client requests, like REDIRECT being sent by the server over a common 2453 transport connection the proxy created for its different connecting 2454 clients. 2456 10.3. Closing Connections 2458 The client MAY close a connection at any point when no outstanding 2459 request/response transactions exist for any RTSP session being 2460 managed through the connection. The server, however, SHOULD NOT 2461 close a connection until all RTSP sessions being managed through the 2462 connection have been timed out (Section 18.49). A server SHOULD NOT 2463 close a connection immediately after responding to a session-level 2464 TEARDOWN request for the last RTSP session being controlled through 2465 the connection. Instead, the server should wait for a reasonable 2466 amount of time for the client to receive and act upon the TEARDOWN 2467 response, and initiate the connection closing. The server SHOULD 2468 wait at least 10 seconds after sending the TEARDOWN response before 2469 closing the connection. 2471 This is to ensure that the client has time to issue a SETUP for a 2472 new session on the existing connection after having torn the last 2473 one down. 10 seconds should give the client ample opportunity to 2474 get its message to the server. 2476 A server SHOULD NOT close the connection directly as a result of 2477 responding to a request with an error code. 2479 Certain error responses such as "460 Only Aggregate Operation 2480 Allowed" (Section 17.4.25) are used for negotiating capabilities 2481 of a server with respect to content or other factors. In such 2482 cases, it is inefficient for the server to close a connection on 2483 an error response. Also, such behavior would prevent 2484 implementation of advanced/special types of requests or result in 2485 extra overhead for the client when testing for new features. On 2486 the other hand, keeping connections open after sending an error 2487 response poses a Denial of Service security risk (Section 21). 2489 The server MAY close a connection if it receives an incomplete 2490 message and if the message is not completed within a reasonable 2491 amount of time. It is RECOMMENDED that the server waits at least 10 2492 seconds for the completion of a message or for the next part of the 2493 message to arrive (which is an indication that the transport and the 2494 client are still alive). Servers believing they are under attack or 2495 otherwise starved for resources during that event MAY consider using 2496 a shorter timeout. 2498 If a server closes a connection while the client is attempting to 2499 send a new request, the client will have to close its current 2500 connection, establish a new connection and send its request over the 2501 new connection. 2503 An RTSP message SHOULD NOT be terminated by closing the connection. 2504 Such a message MAY be considered to be incomplete by the receiver and 2505 discarded. An RTSP message is properly terminated as defined in 2506 Section 5. 2508 10.4. Timing Out Connections and RTSP Messages 2510 Receivers of a request (responder) SHOULD respond to requests in a 2511 timely manner even when a reliable transport such as TCP is used. 2512 Similarly, the sender of a request (requester) SHOULD wait for a 2513 sufficient time for a response before concluding that the responder 2514 will not be acting upon its request. 2516 A responder SHOULD respond to all requests within 5 seconds. If the 2517 responder recognizes that processing of a request will take longer 2518 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 2519 possible. It SHOULD continue sending a 100 response every 5 seconds 2520 thereafter until it is ready to send the final response to the 2521 requester. After sending a 100 response, the responder MUST send a 2522 final response indicating the success or failure of the request. 2524 A requester SHOULD wait at least 10 seconds for a response before 2525 concluding that the responder will not be responding to its request. 2526 After receiving a 100 response, the requester SHOULD continue waiting 2527 for further responses. If more than 10 seconds elapses without 2528 receiving any response, the requester MAY assume that the responder 2529 is unresponsive and abort the connection by closing the TCP 2530 connection. 2532 In cases multiple RTSP sessions share the same transport connection, 2533 abandoning a request and closing the connection may have significant 2534 impact on those other sessions. First of all, other RTSP requests 2535 may have become queued up due to the request taking long time to 2536 process. Secondly also those sessions loose the possibility to 2537 receive server to client requests. To mitigate that situation the 2538 RTSP client or server SHOULD establish a new connection and send any 2539 queued up and non-responded requests on this new connection. 2540 Secondly, to ensure that the RTSP server knows which connection that 2541 is valid for a particular RTSP session, the RTSP agent SHOULD send a 2542 keep-alive request, if no other request will be sent immediately for 2543 that RTSP session, for each RTSP session on the old connection. The 2544 keep-alive request will normally be a SET_PARAMETER with a session 2545 header to inform the server that this agent cares about this RTSP 2546 session. 2548 A requester SHOULD wait longer than 10 seconds for a response if it 2549 is experiencing significant transport delays on its connection to the 2550 responder. The requester is capable of determining the round trip 2551 time (RTT) of the request/response cycle using the Timestamp header 2552 (Section 18.53) in any RTSP request. 2554 10 seconds was chosen for the following reasons. It gives TCP 2555 time to perform a couple of retransmissions, even if operating on 2556 default values. It is short enough that users may not abandon the 2557 process themselves. However, it should be noted that 10 seconds 2558 can be aggressive on certain type of networks. The 5 seconds 2559 value for 1xx messages is half the timeout giving a reasonable 2560 chance of successful delivery before timeout happens on the 2561 requester side. 2563 10.5. Showing Liveness 2565 RTSP requires the client to periodically show its liveness to the 2566 server or the server may terminate any session state. Several 2567 different protocol mechanism includes in their usage a liveness proof 2568 from the client. These mechanisms are; RTSP requests with a Session 2569 header to the server; if RTP & RTCP is used for media data transport 2570 and the transport is established the RTCP message proves liveness; or 2571 through any other used media transport protocol capable of indicating 2572 liveness of the RTSP client. It is RECOMMENDED that a client does 2573 not wait to the last second of the timeout before trying to send a 2574 liveness message. The RTSP message may take some time to arrive 2575 safely at the receiver, due to packet loss and TCP retransmissions. 2576 To show liveness between RTSP requests being issued to accomplish 2577 other things, the following mechanisms can be used, in descending 2578 order of preference: 2580 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 2581 RTCP is used to report transport statistics, it will 2582 necessarily also function as a keep-alive. The server can 2583 determine the client by network address and port together with 2584 the fact that the client is reporting on the server's RTP 2585 sender sources (SSRCs). A downside of using RTCP is that it 2586 only gives statistical guarantees of reaching the server. 2587 However, the probability of a false client timeout is so low 2588 that it can be ignored in most cases. For example, assume a 2589 session with 60 seconds timeout and enough bitrate assigned to 2590 RTCP messages to send a message from client to server on 2591 average every 5 seconds. That client has, for a network with 2592 5% packet loss, a probability of failing to confirm liveness 2593 within the timeout interval for that session of 2.4*E-16. 2594 Sessions with shorter timeouts, or much higher packet loss, or 2595 small RTCP bandwidths SHOULD also implement one or more of the 2596 mechanisms below. 2598 SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body 2599 SHOULD NOT be included. This method is the RECOMMENDED RTSP 2600 method to use for a request intended only to perform keep- 2601 alive. Support of SET_PARAMETER is mandatory for RTSP Servers 2602 to ensure clients can use this method. 2604 GET_PARAMETER: When using GET_PARAMETER for keep-alive, a body 2605 SHOULD NOT be included. Dependent on implementation support in 2606 server. Use OPTIONS method to determine if there are method 2607 support or simply try. 2609 OPTIONS: This method is also usable, but it causes the server to 2610 perform more unnecessary processing and results in bigger 2611 responses than necessary for the task. The reason is that the 2612 server needs to determine the capabilities associated with the 2613 media resource to correctly populate the Public and Allow 2614 headers. 2616 The timeout parameter of the Session header (Section 18.49) MAY be 2617 included in a SETUP response, and MUST NOT be included in requests. 2618 The server uses it to indicate to the client how long the server is 2619 prepared to wait between RTSP commands or other signs of life before 2620 closing the session due to lack of activity (see Appendix B). The 2621 timeout is measured in seconds, with a default of 60 seconds. The 2622 length of the session timeout MUST NOT be changed in an established 2623 session. 2625 10.6. Use of IPv6 2627 Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC 2628 2326). RTSP 2.0 has been updated for explicit IPv6 support. 2629 Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in 2630 URIs and RTSP headers. Although the general URI format envisages 2631 potential future new versions of the literal IP address, usage of any 2632 such new version would require other modifications to the RTSP 2633 specification (e.g. address fields in the Transport header 2634 (Section 18.54)). 2636 10.7. Overload Control 2638 Overload in RTSP can occur when servers and proxies have insufficient 2639 resources to complete the processing of a request. An improper 2640 handling of such an overload situation at proxies and servers can 2641 impact the operation of the RTSP deployment, and probably worsen the 2642 situation. RTSP defines the 503 (Service Unavailable) response 2643 (Section 17.5.4) to let servers and proxies notify requesting proxies 2644 and RTSP clients about an overload situation. In conjunction with 2645 the Retry-After header (Section 18.44) the server or proxy can 2646 indicate the time after which the requesting entity can send another 2647 request to the proxy or server. 2649 There are two scopes of such 503 answers, one for established RTSP 2650 sessions, where the request resulting in the 503 response as well as 2651 the response carries a Session header identifying the session which 2652 is suffering overload. This response only applies to this particular 2653 session. The other scope is the general RTSP server as identified by 2654 the host in the request URL. Such a 503 answer with any Retry-After 2655 header applies to all non-session specific requests to that server, 2656 including SETUP request intended to create a new RTSP session. 2658 Another scope for overload situation exists, which is the RTSP proxy. 2659 To enable an RTSP proxy to signal that it is overloaded, or otherwise 2660 unavailable and can't handle the request, a 553 response code has 2661 been defined with the meaning "Proxy Unavailable". As with servers, 2662 there is a separation in response scopes between requests associated 2663 with existing RTSP sessions, and requests to create new sessions or 2664 general proxy requests. 2666 Simply implementing and using the 503 (Service Unavailable) and 553 2667 (Proxy Unavailable) is not sufficient for properly handling overload 2668 situations. For instance, a simplistic approach would be to send the 2669 503 response with a Retry-After header set to a fixed value. 2670 However, this can cause the situation where multiple RTSP clients 2671 again send requests to a proxy or server at roughly the same time 2672 which may again cause an overload situation, or if the "old" overload 2673 situation is not yet solved, i.e., the length indicated in the Retry- 2674 After header was too short. 2676 An RTSP server or proxy in an overload situation must select the 2677 value of the Retry-After header carefully and bearing in mind its 2678 current load situation. It is REQUIRED to increase the timeout 2679 period in proportion to the current load on the server, i.e., an 2680 increasing workload should result in an increased length of the 2681 indicated unavailability. It is REQUIRED to not send the same value 2682 in the Retry-After header to all requesting proxies and clients, but 2683 to add a variation to the mean value of the Retry-After header. 2685 A more complex case may arise when a load balancing RTSP proxy is in 2686 use. This is the case when an RTSP proxy is used to select amongst a 2687 set of RTSP servers to handle the requests or when multiple server 2688 addresses are available for a given server name. The proxy or client 2689 may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) 2690 from one of its RTSP servers or proxies, or a TCP timeout (if the 2691 server is even unable to handle the request message). The proxy or 2692 client simply retries the other addresses or configured proxies, but 2693 may also receive a 503 (Service Unavailable) or 553 (Proxy 2694 Unavailable) response or TCP timeouts from those addresses. In such 2695 a situation, where none of the RTSP servers/proxies/addresses can 2696 handle the request, the RTSP agent has to wait before it can send any 2697 new requests to the RTSP server. Any additional request to a 2698 specific address MUST be delayed according to the Retry-After headers 2699 received. For addresses where no response was received or TCP 2700 timeout occurred, an initial wait timer SHOULD be set to 5 seconds. 2701 That timer MUST be doubled for each additional failure to connect or 2702 receive response until the value exceeds 30 minutes when the timers 2703 mean value may be set to 30 minutes. It is REQUIRED to not set the 2704 same value in the timer for each scheduling, but instead to add a 2705 variation to the mean value, resulting in picking a random value 2706 within the range from 0.5 to 1.5 times the mean value. 2708 11. Capability Handling 2710 This section describes the available capability handling mechanism 2711 which allows RTSP to be extended. Extensions to this version of the 2712 protocol are basically done in two ways. First, new headers can be 2713 added. Secondly, new methods can be added. The capability handling 2714 mechanism is designed to handle both cases. 2716 When a method is added, the involved parties can use the OPTIONS 2717 method to discover whether it is supported. This is done by issuing 2718 an OPTIONS request to the other party. Depending on the URI it will 2719 either apply in regards to a certain media resource, the whole server 2720 in general, or simply the next hop. The OPTIONS response MUST 2721 contain a Public header which declares all methods supported for the 2722 indicated resource. 2724 It is not necessary to use OPTIONS to discover support of a method, 2725 as the client could simply try the method. If the receiver of the 2726 request does not support the method it will respond with an error 2727 code indicating the method is either not implemented (501) or does 2728 not apply for the resource (405). The choice between the two 2729 discovery methods depends on the requirements of the service. 2731 Feature-tags are defined to handle functionality additions that are 2732 not new methods. Each feature-tag represents a certain block of 2733 functionality. The amount of functionality that a feature-tag 2734 represents can vary significantly. A feature-tag can for example 2735 represent the functionality a single RTSP header provides. Another 2736 feature-tag can represent much more functionality, such as the 2737 "play.basic" feature-tag (Section 11.1) which represents the minimal 2738 media delivery for playback implementation. 2740 Feature-tags are used to determine whether the client, server or 2741 proxy supports the functionality that is necessary to achieve the 2742 desired service. To determine support of a feature-tag, several 2743 different headers can be used, each explained below: 2745 Supported: This header is used to determine the complete set of 2746 functionality that both client and server have in general and 2747 is not dependent on a specific resource. The intended usage is 2748 to determine before one needs to use a functionality that it is 2749 supported. It can be used in any method, but OPTIONS is the 2750 most suitable one as it at the same time determines all methods 2751 that are implemented. When sending a request the requester 2752 declares all its capabilities by including all supported 2753 feature-tags. This results in the receiver learning the 2754 requester's feature support. The receiver then includes its 2755 set of features in the response. 2757 Proxy-Supported: This header is used similarly to the Supported 2758 header, but instead of giving the supported functionality of 2759 the client or server it provides both the requester and the 2760 responder a view of the common functionality supported in 2761 general by all members of the proxy chain between the two 2762 supports and not dependent on the resource. Proxies are 2763 required to add this header whenever the Supported header is 2764 present, but proxies may also add it independently of the 2765 requester. 2767 Require: This header can be included in any request where the end- 2768 point, i.e., the client or server, is required to understand 2769 the feature to correctly perform the request. This can, for 2770 example, be a SETUP request where the server is required to 2771 understand a certain parameter to be able to set up the media 2772 delivery correctly. Ignoring this parameter would not have the 2773 desired effect and is not acceptable. Therefore the end-point 2774 receiving a request containing a Require MUST negatively 2775 acknowledge any feature that it does not understand and not 2776 perform the request. The response in cases where features are 2777 not supported are 551 (Option Not Supported). Also the 2778 features that are not supported are given in the Unsupported 2779 header in the response. 2781 Proxy-Require: This header has the same purpose and workings as 2782 Require except that it only applies to proxies and not the end- 2783 point. Features that need to be supported by both proxies and 2784 end-points need to be included in both the Require and Proxy- 2785 Require header. 2787 Unsupported: This header is used in a 551 error response, to 2788 indicate which features were not supported. Such a response is 2789 only the result of the usage of the Require and/or Proxy- 2790 Require header where one or more features where not supported. 2791 This information allows the requester to make the best of 2792 situations as it knows which features are not supported. 2794 11.1. Feature Tag: play.basic 2796 An implementation supporting all normative parts of this 2797 specification for the setup and control of playback of media uses the 2798 feature tag "play.basic" to indicate this support. The appendices 2799 (starting with letters), are not part of the functionality include in 2800 the feature tag unless the appendix is explicitly specified in a main 2801 section as being a required appendix. 2803 Note: This feature tag does not mandate any media delivery 2804 protocol, such as RTP. 2806 In RTSP 1.0 there was a minimal implementation section. However, 2807 that was not consistent with the rest of the specification. So 2808 rather than making an attempt to explicitly enumerate the features 2809 for play.basic this specification has to be taken as a whole and 2810 the necessary features normatively defined as being required are 2811 included. 2813 12. Pipelining Support 2815 Pipelining is a general method to improve performance of request 2816 response protocols by allowing the requesting agent to have more than 2817 one request outstanding and send them over the same persistent 2818 connection. For RTSP, where the relative order of requests will 2819 matter, it is important to maintain the order of the requests. 2820 Because of this, the responding agent MUST process the incoming 2821 requests in their sending order. The sending order can be determined 2822 by the CSeq header and its sequence number. For TCP the delivery 2823 order will be the same between two agents, as the sending order. The 2824 processing of the request MUST also have been finished before 2825 processing the next request from the same agent. The responses MUST 2826 be sent in the order the requests were processed. 2828 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2829 The major improvement is to allow all requests involved in setting up 2830 and initiating media delivery to be pipelined after each other. This 2831 is accomplished by the utilization of the Pipelined-Requests header 2832 (see Section 18.33). This header allows a client to request that two 2833 or more requests are processed in the same RTSP session context which 2834 the first request creates. In other words, a client can request that 2835 two or more media streams are set-up and then played without needing 2836 to wait for a single response. This speeds up the initial startup 2837 time for an RTSP session by at least one RTT. 2839 If a pipelined request builds on the successful completion of one or 2840 more prior requests the requester must verify that all requests were 2841 executed as expected. A common example will be two SETUP requests 2842 and a PLAY request. In case one of the SETUP fails unexpectedly, the 2843 PLAY request can still be successfully executed. However, the 2844 resulting presentation will not be as expected by the requesting 2845 client, as only a single media instead of two will be played. In 2846 this case the client can send a PAUSE request, correct the failing 2847 SETUP request and then request it to be played. 2849 13. Method Definitions 2851 The method indicates what is to be performed on the resource 2852 identified by the Request-URI. The method name is case-sensitive. 2853 New methods may be defined in the future. Method names MUST NOT 2854 start with a $ character (decimal 36) and MUST be a token as defined 2855 by the ABNF [RFC5234] in the syntax chapter Section 20. The methods 2856 are summarized in Table 7. 2858 +---------------+-----------+--------+-------------+-------------+ 2859 | method | direction | object | Server req. | Client req. | 2860 +---------------+-----------+--------+-------------+-------------+ 2861 | DESCRIBE | C -> S | P,S | recommended | recommended | 2862 | | | | | | 2863 | GET_PARAMETER | C -> S | P,S | optional | optional | 2864 | | | | | | 2865 | | S -> C | P,S | optional | optional | 2866 | | | | | | 2867 | OPTIONS | C -> S | P,S | required | required | 2868 | | | | | | 2869 | | S -> C | P,S | optional | optional | 2870 | | | | | | 2871 | PAUSE | C -> S | P,S | required | required | 2872 | | | | | | 2873 | PLAY | C -> S | P,S | required | required | 2874 | | | | | | 2875 | PLAY_NOTIFY | S -> C | P,S | required | required | 2876 | | | | | | 2877 | REDIRECT | S -> C | P,S | optional | required | 2878 | | | | | | 2879 | SETUP | C -> S | S | required | required | 2880 | | | | | | 2881 | SET_PARAMETER | C -> S | P,S | required | optional | 2882 | | | | | | 2883 | | S -> C | P,S | optional | optional | 2884 | | | | | | 2885 | TEARDOWN | C -> S | P,S | required | required | 2886 | | | | | | 2887 | | S -> C | P | required | required | 2888 +---------------+-----------+--------+-------------+-------------+ 2890 Table 7: Overview of RTSP methods, their direction, and what objects 2891 (P: presentation, S: stream) they operate on. Further it indicates 2892 if a server or a client implementation are required (mandatory), 2893 recommended or if it is optional to implement the method. 2895 Note on Table 7: GET_PARAMETER is optional. For example, a fully 2896 functional server can be built to deliver media without any 2897 parameters. However, SET_PARAMETER is required, i.e., mandatory 2898 to implement for the server, this is due to its usage for keep- 2899 alive. PAUSE is required because it is the only way of leaving 2900 the Play state without terminating the whole session. 2902 If an RTSP agent does not support a particular method, it MUST return 2903 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2904 NOT try this method again for the given agent / resource combination. 2905 An RTSP proxy whose main function is to log or audit and not modify 2906 transport or media handling in any way MAY forward RTSP messages with 2907 unknown methods. Note that the proxy still needs to perform the 2908 minimal required processing, like adding the Via header. 2910 13.1. OPTIONS 2912 The semantics of the RTSP OPTIONS method is similar to that of the 2913 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2914 bi-directional, in that a client can send the request to a server and 2915 vice versa. A client MUST implement the capability to send an 2916 OPTIONS request and a server or a proxy MUST implement the capability 2917 to respond to an OPTIONS request. In addition to this "MUST 2918 implement" functionality, clients, servers and proxies MAY provide 2919 support both for sending OPTIONS requests and generating responses to 2920 the requests. 2922 An OPTIONS request may be issued at any time. Such a request does 2923 not modify the session state. However, it may prolong the session 2924 lifespan (see below). The URI in an OPTIONS request determines the 2925 scope of the request and the corresponding response. If the Request- 2926 URI refers to a specific media resource on a given host, the scope is 2927 limited to the set of methods supported for that media resource by 2928 the indicated RTSP agent. A Request-URI with only the host address 2929 limits the scope to the specified RTSP agent's general capabilities 2930 without regard to any specific media. If the Request-URI is an 2931 asterisk ("*"), the scope is limited to the general capabilities of 2932 the next hop (i.e., the RTSP agent in direct communication with the 2933 request sender). 2935 Regardless of the scope of the request, the Public header MUST always 2936 be included in the OPTIONS response listing the methods that are 2937 supported by the responding RTSP agent. In addition, if the scope of 2938 the request is limited to a media resource, the Allow header MUST be 2939 included in the response to enumerate the set of methods that are 2940 allowed for that resource unless the set of methods completely 2941 matches the set in the Public header. If the given resource is not 2942 available, the RTSP agent SHOULD return an appropriate response code 2943 such as 3rr or 4xx. The Supported header MAY be included in the 2944 request to query the set of features that are supported by the 2945 responding RTSP agent. 2947 The OPTIONS method can be used to keep an RTSP session alive. 2948 However, this is not the preferred way of session keep-alive 2949 signaling, see Section 18.49. An OPTIONS request intended for 2950 keeping alive an RTSP session MUST include the Session header with 2951 the associated session identifier. Such a request SHOULD also use 2952 the media or the aggregated control URI as the Request-URI. 2954 Example: 2956 C->S: OPTIONS rtsp://server.example.com RTSP/2.0 2957 CSeq: 1 2958 User-Agent: PhonyClient/1.2 2959 Proxy-Require: gzipped-messages 2960 Supported: play.basic 2962 S->C: RTSP/2.0 200 OK 2963 CSeq: 1 2964 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS 2965 Supported: play.basic, setup.rtp.rtcp.mux, play.scale 2966 Server: PhonyServer/1.1 2968 Note that some of the feature-tags in Supported and Proxy-Require are 2969 fictitious features. 2971 13.2. DESCRIBE 2973 The DESCRIBE method is used to retrieve the description of a 2974 presentation or media object from a server. The Request-URI of the 2975 DESCRIBE request identifies the media resource of interest. The 2976 client MAY include the Accept header in the request to list the 2977 description formats that it understands. The server MUST respond 2978 with a description of the requested resource and return the 2979 description in the message body of the response, if the DESCRIBE 2980 method request can be successfully fulfilled. The DESCRIBE reply- 2981 response pair constitutes the media initialization phase of RTSP. 2983 The DESCRIBE response SHOULD contain all media initialization 2984 information for the resource(s) that it describes. Servers SHOULD 2985 NOT use the DESCRIBE response as a means of media indirection by 2986 having the description point at another server; instead, using the 2987 3rr responses is RECOMMENDED. 2989 By forcing a DESCRIBE response to contain all media initialization 2990 information for the set of streams that it describes, and 2991 discouraging the use of DESCRIBE for media indirection, any 2992 looping problems can be avoided that might have resulted from 2993 other approaches. 2995 Example: 2997 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2998 CSeq: 312 2999 User-Agent: PhonyClient/1.2 3000 Accept: application/sdp, application/example 3002 S->C: RTSP/2.0 200 OK 3003 CSeq: 312 3004 Date: Thu, 23 Jan 1997 15:35:06 GMT 3005 Server: PhonyServer/1.1 3006 Content-Base: rtsp://server.example.com/fizzle/foo/ 3007 Content-Type: application/sdp 3008 Content-Length: 358 3010 v=0 3011 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46 3012 s=SDP Seminar 3013 i=A Seminar on the session description protocol 3014 u=http://www.example.com/lectures/sdp.ps 3015 e=seminar@example.com (Seminar Management) 3016 c=IN IP4 0.0.0.0 3017 a=control:* 3018 t=2873397496 2873404696 3019 m=audio 3456 RTP/AVP 0 3020 a=control:audio 3021 m=video 2232 RTP/AVP 31 3022 a=control:video 3024 Media initialization is a requirement for any RTSP-based system, but 3025 the RTSP specification does not dictate that this is required to be 3026 done via the DESCRIBE method. There are three ways that an RTSP 3027 client may receive initialization information: 3029 o via an RTSP DESCRIBE request 3031 o via some other protocol (HTTP, email attachment, etc.) 3033 o via some form of user interface 3035 If a client obtains a valid description from an alternate source, the 3036 client MAY use this description for initialization purposes without 3037 issuing a DESCRIBE request for the same media. The client should use 3038 any MTag to either validate the presentation description or make the 3039 session establishment conditional on being valid. 3041 It is RECOMMENDED that minimal servers support the DESCRIBE method, 3042 and highly recommended that minimal clients support the ability to 3043 act as "helper applications" that accept a media initialization file 3044 from a user interface, and/or other means that are appropriate to the 3045 operating environment of the clients. 3047 13.3. SETUP 3049 The description below uses the following states in a protocol state 3050 machine that is related to a specific session when that session has 3051 been created. The state transitions are driven by protocol 3052 interactions. For additional information about the state machine see 3053 Appendix B. 3055 Init: Initial state: no session exists. 3057 Ready: Session is ready to start playing. 3059 Play: Session is playing, i.e., sending media stream data in the 3060 direction S->C. 3062 The SETUP request for a URI specifies the transport mechanism to be 3063 used for the streamed media. The SETUP method may be used in two 3064 different cases; Create an RTSP session and change the transport 3065 parameters of already set up media stream(s). SETUP can be used in 3066 all three states; Init, and Ready, for both purposes and in PLAY to 3067 change the transport parameters. The usage of SETUP method in the 3068 Play state to add a media resource to the session is unspecified 3069 (Section 3.1). 3071 The Transport header, see Section 18.54, specifies the media 3072 transport parameters acceptable to the client for data transmission; 3073 the response will contain the transport parameters selected by the 3074 server. This allows the client to enumerate in descending order of 3075 preference the transport mechanisms and parameters acceptable to it, 3076 while the server can select the most appropriate. It is expected 3077 that the session description format used will enable the client to 3078 select a limited number of possible configurations that are offered 3079 to the server to choose from. All transport related parameters SHALL 3080 be included in the Transport header; the use of other headers for 3081 this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls 3082 or NATs. 3084 For the benefit of any intervening firewalls, a client MUST indicate 3085 the known transport parameters, even if it has no influence over 3086 these parameters, for example, where the server advertises a fixed 3087 multicast address as destination. 3089 Since SETUP includes all transport initialization information, 3090 firewalls and other intermediate network devices (which need this 3091 information) are spared the more arduous task of parsing the 3092 DESCRIBE response, which has been reserved for media 3093 initialization. 3095 The client MUST include the Accept-Ranges header in the request 3096 indicating all supported unit formats in the Range header. This 3097 allows the server to know which formats it may use in future session 3098 related responses, such as a PLAY response without any range in the 3099 request. If the client does not support a time format necessary for 3100 the presentation, the server MUST respond using 456 (Header Field Not 3101 Valid for Resource) and include the Accept-Ranges header with the 3102 range unit formats supported for the resource. 3104 In a SETUP response the server MUST include the Accept-Ranges header 3105 (see Section 18.5) to indicate which time formats are acceptable to 3106 use for this media resource. 3108 The SETUP response 200 OK MUST include the Media-Properties header 3109 (see Section 18.29 ). The combination of the parameters of the 3110 Media-Properties header indicates the nature of the content present 3111 in the session (see also Section 4.7). For example, a live stream 3112 with time shifting is indicated by 3114 o Random Access set to Random-Access, 3116 o Content Modifications set to Time Progressing, 3118 o Retention set to Time-Duration (with specific recording window 3119 time value). 3121 The SETUP response 200 OK MUST include the Media-Range header (see 3122 Section 18.30) if the media is Time-Progressing. 3124 A basic example for SETUP: 3126 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 3127 CSeq: 302 3128 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 3129 RTP/AVP/TCP;unicast;interleaved=0-1 3130 Accept-Ranges: npt, clock 3131 User-Agent: PhonyClient/1.2 3133 S->C: RTSP/2.0 200 OK 3134 CSeq: 302 3135 Date: Thu, 23 Jan 1997 15:35:06 GMT 3136 Server: PhonyServer/1.1 3137 Session: 47112344;timeout=60 3138 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ 3139 "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ 3140 "198.51.100.241:6257"; ssrc=2A3F93ED 3141 Accept-Ranges: npt 3142 Media-Properties: Random-Access=3.2, Time-Progressing, 3143 Time-Duration=3600.0 3144 Media-Range: npt=0-2893.23 3146 In the above example the client wants to create an RTSP session 3147 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 3148 The transport parameters acceptable to the client are either RTP/AVP/ 3149 UDP (UDP per default) to be received on client port 4588 and 4589 at 3150 the address the RTSP setup connection comes from or RTP/AVP 3151 interleaved on the RTSP control channel. The server selects the RTP/ 3152 AVP/UDP transport and adds the address and ports it will send and 3153 receive RTP and RTCP from, and the RTP SSRC that will be used by the 3154 server. 3156 The server MUST generate a session identifier in response to a 3157 successful SETUP request, unless a SETUP request to a server includes 3158 a session identifier or a Pipelined-Requests header referencing an 3159 existing session context, in which case the server MUST bundle this 3160 SETUP request into the existing session (aggregated session) or 3161 return error 459 (Aggregate Operation Not Allowed) (see 3162 Section 17.4.24). An Aggregate control URI MUST be used to control 3163 an aggregated session. This URI MUST be different from the stream 3164 control URIs of the individual media streams included in the 3165 aggregate (see Section 13.4.2 for aggregated sessions and for the 3166 particular URIs see Appendix D.1.1). The Aggregate control URI is to 3167 be specified by the session description if the server supports 3168 aggregated control and aggregated control is desired for the session. 3169 However, even if aggregated control is offered the client MAY chose 3170 to not set up the session in aggregated control. If an Aggregate 3171 control URI is not specified in the session description, it is 3172 normally an indication that non-aggregated control should be used. 3174 The SETUP of media streams in an aggregate which has not been given 3175 an aggregated control URI is unspecified. 3177 While the session ID sometimes carries enough information for 3178 aggregate control of a session, the Aggregate control URI is still 3179 important for some methods such as SET_PARAMETER where the control 3180 URI enables the resource in question to be easily identified. The 3181 Aggregate control URI is also useful for proxies, enabling them to 3182 route the request to the appropriate server, and for logging, 3183 where it is useful to note the actual resource that a request was 3184 operating on. 3186 A session will exist until it is either removed by a TEARDOWN request 3187 or is timed-out by the server. The server MAY remove a session that 3188 has not demonstrated liveness signs from the client(s) within a 3189 certain timeout period. The default timeout value is 60 seconds; the 3190 server MAY set this to a different value and indicate so in the 3191 timeout field of the Session header in the SETUP response. For 3192 further discussion see Section 18.49. Signs of liveness for an RTSP 3193 session are: 3195 o Any RTSP request from a client which includes a Session header 3196 with that session's ID. 3198 o If RTP is used as a transport for the underlying media streams, an 3199 RTCP sender or receiver report from the client(s) for any of the 3200 media streams in that RTSP session. RTCP Sender Reports may for 3201 example be received in sessions where the server is invited into a 3202 conference session and is valid for keep-alive. 3204 If a SETUP request on a session fails for any reason, the session 3205 state, as well as transport and other parameters for associated 3206 streams MUST remain unchanged from their values as if the SETUP 3207 request had never been received by the server. 3209 13.3.1. Changing Transport Parameters 3211 A client MAY issue a SETUP request for a stream that is already set 3212 up or playing in the session to change transport parameters, which a 3213 server MAY allow. If it does not allow changing of parameters, it 3214 MUST respond with error 455 (Method Not Valid In This State). The 3215 reasons to support changing transport parameters include allowing 3216 application layer mobility and flexibility to utilize the best 3217 available transport as it becomes available. If a client receives a 3218 455 when trying to change transport parameters while the server is in 3219 Play state, it MAY try to put the server in Ready state using PAUSE, 3220 before issuing the SETUP request again. If that also fails the 3221 changing of transport parameters will require that the client 3222 performs a TEARDOWN of the affected media and then to set it up 3223 again. For an aggregated session avoiding tearing down all the media 3224 at the same time will avoid the creation of a new session. 3226 All transport parameters MAY be changed. However, the primary usage 3227 expected is to either change the transport protocol completely, like 3228 switching from Interleaved TCP mode to UDP or vice versa, or to 3229 change the delivery address. 3231 In a SETUP response for a request to change the transport parameters 3232 while in Play state, the server MUST include the Range to indicate at 3233 what point the new transport parameters will be used. Further, if 3234 RTP is used for delivery, the server MUST also include the RTP-Info 3235 header to indicate at what timestamp and RTP sequence number the 3236 change will take place. If both RTP-Info and Range are included in 3237 the response the "rtp_time" parameter and start point in the Range 3238 header MUST be for the corresponding time, i.e., be used in the same 3239 way as for PLAY to ensure the correct synchronization information is 3240 available. 3242 If the transport parameters change while in Play state results in a 3243 change of synchronization related information, for example changing 3244 RTP SSRC, the server MUST provide in the SETUP response the necessary 3245 synchronization information. However, the server is RECOMMENDED to 3246 avoid changing the synchronization information if possible. 3248 13.4. PLAY 3250 This section describes the usage of the PLAY method in general, for 3251 aggregated sessions, and in different usage scenarios. 3253 13.4.1. General Usage 3255 The PLAY method tells the server to start sending data via the 3256 mechanism specified in SETUP and which part of the media should be 3257 played out. PLAY requests are valid when the session is in Ready or 3258 Play states. A PLAY request MUST include a Session header to 3259 indicate which session the request applies to. 3261 Upon receipt of the PLAY request, the server MUST position the normal 3262 play time to the beginning of the range specified in the received 3263 Range header, within the limits of the media resource and in 3264 accordance with the Seek-Style header (Section 18.47) and deliver 3265 stream data until the end of the range if given, until a new PLAY 3266 request is received, or until the end of the media is reached. If no 3267 Range header is present in the PLAY request the server SHALL play 3268 from current pause point until the end of media. The pause point 3269 defaults at session start to the beginning of the media. For media 3270 that is time-progressing and has no retention, the pause point will 3271 always be set equal to NPT "now", i.e., the current delivery point. 3272 The pause point may also be set to a particular point in the media by 3273 the PAUSE method, see Section 13.6. The pause point for media that 3274 is currently playing is equal to the current media position. For 3275 time-progressing media with time-limited retention, if the pause 3276 point represents a position that is older than what is retained by 3277 the server, the pause point will be moved to the oldest retained. 3279 What range values are valid depends on the type of content. For 3280 content that isn't time progressing the range value is valid if the 3281 given range is part of any media within the aggregate. In other 3282 words the valid media range for the aggregate is the union of all of 3283 the media components in the aggregate. If a given range value points 3284 outside of the media, the response MUST be the 457 (Invalid Range) 3285 error code and include the Media-Range header (Section 18.30) with 3286 the valid range for the media. Except for time progressing content 3287 where the client requests a start point prior to what is retained, 3288 the start point is adjusted to the oldest retained content. For a 3289 start point that is beyond the media front edge, i.e., beyond the 3290 current value for "now", the server SHALL adjust the start value to 3291 the current front edge. The Range header's stop point value may 3292 point beyond the current media edge. In that case, the server SHALL 3293 deliver media from the requested (and possibly adjusted) start point 3294 until the provided stop point, or the end of the media is reached 3295 prior to the specified stop point. Please note that if one simply 3296 wants to play from a particular start point until the end of media 3297 using a Range header with an implicit stop point is RECOMMENDED. 3299 If a client requests to start playing at the end of media, either 3300 explicitly with a Range header or implicitly with a pause point that 3301 is at the end of media, a 457 (Invalid Range) error MUST be sent and 3302 include the Media-Range header (Section 18.30). It is specified 3303 below that the Range header also must be included in the response and 3304 that it will carry the pause point in the media, in the case of the 3305 session being in Ready State. Note that this also applies if the 3306 pause point or requested start point is at the beginning of the media 3307 and a Scale header (Section 18.46) is included with a negative value 3308 (playing backwards). 3310 For media with random access properties a client may express its 3311 preference on which policy for start point selection the server shall 3312 use. This is done by including the Seek-Style header (Section 18.47) 3313 in the PLAY request. The Seek-Style applied will affect the content 3314 of the Range header as it will be adjusted to indicate from what 3315 point the media actually is delivered. 3317 A client desiring to play the media from the beginning MUST send a 3318 PLAY request with a Range header pointing at the beginning, e.g., 3319 "npt=0-". If a PLAY request is received without a Range header and 3320 media delivery has stopped at the end, the server SHOULD respond with 3321 a 457 "Invalid Range" error response. In that response, the current 3322 pause point MUST be included in a Range header. 3324 All range specifiers in this specification allow for ranges with an 3325 implicit start point (e.g., "npt=-30"). When used in a PLAY request, 3326 the server treats this as a request to start or resume delivery from 3327 the current pause point, ending at the end time specified in the 3328 Range header. If the pause point is located later than the given end 3329 value, a 457 (Invalid Range) response MUST be given. 3331 The example below will play seconds 10 through 25. It also requests 3332 the server to deliver media from the first Random Access Point prior 3333 to the indicated start point. 3335 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 3336 CSeq: 835 3337 Session: 12345678 3338 Range: npt=10-25 3339 Seek-Style: RAP 3340 User-Agent: PhonyClient/1.2 3342 Servers MUST include a "Range" header in any PLAY response, even if 3343 no Range header was present in the request. The response MUST use 3344 the same format as the request's range header contained. If no Range 3345 header was in the request, the format used in any previous PLAY 3346 request within the session SHOULD be used. If no format has been 3347 indicated in a previous request the server MAY use any time format 3348 supported by the media and indicated in the Accept-Ranges header in 3349 the SETUP request. It is RECOMMENDED that NPT is used if supported 3350 by the media. 3352 For any error response to a PLAY request, the server's response 3353 depends on the current session state. If the session is in Ready 3354 state, the current pause-point is returned using Range header with 3355 the pause point as the explicit start-point and an implicit stop- 3356 point. For time-progressing content where the pause-point moves with 3357 real-time due to limited retention, the current pause point is 3358 returned. For sessions in Play state, the current playout point and 3359 the remaining parts of the range request is returned. For any media 3360 with retention longer than 0 seconds the currently valid Media-Range 3361 header SHALL also be included in the response. 3363 A PLAY response MAY include a header carrying synchronization 3364 information. As the information necessary is dependent on the media 3365 transport format, further rules specifying the header and its usage 3366 are needed. For RTP the RTP-Info header is specified, see 3367 Section 18.45, and used in the following example. 3369 Here is a simple example for a single audio stream where the client 3370 requests the media starting from 3.52 seconds and to the end. The 3371 server sends a 200 OK response with the actual play time which is 10 3372 ms prior (3.51) and the RTP-Info header that contains the necessary 3373 parameters for the RTP stack. 3375 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3376 CSeq: 836 3377 Session: 12345678 3378 Range: npt=3.52- 3379 User-Agent: PhonyClient/1.2 3381 S->C: RTSP/2.0 200 OK 3382 CSeq: 836 3383 Date: Thu, 23 Jan 1997 15:35:06 GMT 3384 Server: PhonyServer/1.0 3385 Range: npt=3.51-324.39 3386 Seek-Style: First-Prior 3387 RTP-Info:url="rtsp://example.com/audio" 3388 ssrc=0D12F123:seq=14783;rtptime=2345962545 3390 S->C: RTP Packet TS=2345962545 => NPT=3.51 3391 Media duration=0.16 seconds 3393 The server replies with the actual start point that will be 3394 delivered. This may differ from the requested range if alignment of 3395 the requested range to valid frame boundaries is required for the 3396 media source. Note that some media streams in an aggregate may need 3397 to be delivered from even earlier points. Also, some media formats 3398 have a very long duration per individual data unit, therefore it 3399 might be necessary for the client to parse the data unit, and select 3400 where to start. The server SHALL also indicate which policy it uses 3401 for selecting the actual start point by including a Seek-Style 3402 header. 3404 In the following example the client receives the first media packet 3405 that stretches all the way up and past the requested playtime. Thus, 3406 it is the client's decision whether to render to the user the time 3407 between 3.52 and 7.05, or to skip it. In most cases it is probably 3408 most suitable not to render that time period. 3410 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3411 CSeq: 836 3412 Session: 12345678 3413 Range: npt=7.05- 3414 User-Agent: PhonyClient/1.2 3416 S->C: RTSP/2.0 200 OK 3417 CSeq: 836 3418 Date: Thu, 23 Jan 1997 15:35:06 GMT 3419 Server: PhonyServer/1.0 3420 Range: npt=3.52- 3421 Seek-Style: First-Prior 3422 RTP-Info:url="rtsp://example.com/audio" 3423 ssrc=0D12F123:seq=14783;rtptime=2345962545 3425 S->C: RTP Packet TS=2345962545 => NPT=3.52 3426 Duration=4.15 seconds 3428 After playing the desired range, the presentation does NOT change to 3429 the Ready state, media delivery simply stops. If it is necessary to 3430 put the stream into the Ready state, a PAUSE request MUST be issued 3431 to do that. A PLAY request while the stream is still in the Play 3432 state is legal, and can be issued without an intervening PAUSE 3433 request. Such a request MUST replace the current PLAY action with 3434 the new one requested, i.e., being handled in the same way as if as 3435 the request was received in Ready state. In the case that the range 3436 in Range header has an implicit start time ("-endtime"), the server 3437 MUST continue to play from where it currently was until the specified 3438 end point. This is useful to change the end to at another point than 3439 in the previous request. 3441 The following example plays the whole presentation starting at SMPTE 3442 time code 0:10:20 until the end of the clip. Note: The RTP-Info 3443 headers has been broken into several lines, where following lines 3444 start with whitespace as allowed by the syntax. 3446 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 3447 CSeq: 833 3448 Session: 12345678 3449 Range: smpte=0:10:20- 3450 User-Agent: PhonyClient/1.2 3452 S->C: RTSP/2.0 200 OK 3453 CSeq: 833 3454 Date: Thu, 23 Jan 1997 15:35:06 GMT 3455 Session: 12345678 3456 Server: PhonyServer/1.0 3457 Range: smpte=0:10:22-0:15:45 3458 Seek-Style: Next 3459 RTP-Info:url="rtsp://example.com/twister.en" 3460 ssrc=0D12F123:seq=14783;rtptime=2345962545 3462 For playing back a recording of a live presentation, it may be 3463 desirable to use clock units: 3465 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 3466 CSeq: 835 3467 Session: 12345678 3468 Range: clock=19961108T142300Z-19961108T143520Z 3469 User-Agent: PhonyClient/1.2 3471 S->C: RTSP/2.0 200 OK 3472 CSeq: 835 3473 Date: Thu, 23 Jan 1997 15:35:06 GMT 3474 Session: 12345678 3475 Server: PhonyServer/1.0 3476 Range: clock=19961108T142300Z-19961108T143520Z 3477 Seek-Style: Next 3478 RTP-Info:url="rtsp://example.com/meeting.en" 3479 ssrc=0D12F123:seq=53745;rtptime=484589019 3481 13.4.2. Aggregated Sessions 3483 PLAY requests can operate on sessions controlling a single media and 3484 on aggregated sessions controlling multiple media. 3486 In an aggregated session the PLAY request MUST contain an aggregated 3487 control URI. A server MUST respond with error 460 (Only Aggregate 3488 Operation Allowed) if the client PLAY Request-URI is for a single 3489 media. The media in an aggregate MUST be played in sync. If a 3490 client wants individual control of the media, it needs to use 3491 separate RTSP sessions for each media. 3493 For aggregated sessions where the initial SETUP request (creating a 3494 session) is followed by one or more additional SETUP requests, a PLAY 3495 request MAY be pipelined after those additional SETUP requests 3496 without awaiting their responses. This procedure can reduce the 3497 delay from start of session establishment until media play-out has 3498 started with one round trip time. However, a client needs to be 3499 aware that using this procedure will result in the playout of the 3500 server state established at the time of processing the PLAY, i.e., 3501 after the processing of all the requests prior to the PLAY request in 3502 the pipeline. This state may not be the intended one due to failure 3503 of any of the prior requests. A client can easily determine this 3504 based on the responses from those requests. In case of failure, the 3505 client can halt the media playout using PAUSE and try to establish 3506 the intended state again before issuing another PLAY request. 3508 13.4.3. Updating current PLAY Requests 3510 Clients can issue PLAY requests while the stream is in Play state and 3511 thus updating their request. 3513 The important difference compared to a PLAY request in Ready state is 3514 the handling of the current play point and how the Range header in 3515 the request is constructed. The session is actively playing media 3516 and the play point will be moving, making the exact time a request 3517 will take effect hard to predict. Depending on how the PLAY header 3518 appears two different cases exist: total replacement or continuation. 3519 A total replacement is signaled by having the first range 3520 specification have an explicit start value, e.g., "npt=45-" or 3521 "npt=45-60", in which case the server stops playout at the current 3522 playout point and then starts delivering media according to the Range 3523 header. This is equivalent to having the client first send a PAUSE 3524 and then a new PLAY request that isn't based on the pause point. In 3525 the case of continuation the first range specifier has an implicit 3526 start point and an explicit stop value (Z), e.g., "npt=-60", which 3527 indicate that it MUST convert the range specifier being played prior 3528 to this PLAY request (X to Y) into (X to Z) and continue as this was 3529 the request originally played. If the current delivery point is 3530 beyond the stop point, the server SHALL immediately pause delivery. 3531 As the request has been completed successfully it shall be responded 3532 with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to 3533 indicate the actual stop point. The pause point is set to the 3534 requested stop point. 3536 Following is an example of this behavior: The server has received 3537 requests to play ranges 10 to 15. If the new PLAY request arrives at 3538 the server 4 seconds after the previous one, it will take effect 3539 while the server still plays the first range (10-15). The server 3540 changes the current play to continue to 25 seconds, i.e., the 3541 equivalent single request would be PLAY with "range: npt=10-25". 3543 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3544 CSeq: 834 3545 Session: 12345678 3546 Range: npt=10-15 3547 User-Agent: PhonyClient/1.2 3549 S->C: RTSP/2.0 200 OK 3550 CSeq: 834 3551 Date: Thu, 23 Jan 1997 15:35:06 GMT 3552 Session: 12345678 3553 Server: PhonyServer/1.0 3554 Range: npt=10-15 3555 Seek-Style: Next 3556 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3557 ssrc=0D12F123:seq=5712;rtptime=934207921, 3558 url="rtsp://example.com/fizzle/videotrack" 3559 ssrc=789DAF12:seq=57654;rtptime=2792482193 3560 Session: 12345678 3562 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3563 CSeq: 835 3564 Session: 12345678 3565 Range: npt=-25 3566 User-Agent: PhonyClient/1.2 3568 S->C: RTSP/2.0 200 OK 3569 CSeq: 835 3570 Date: Thu, 23 Jan 1997 15:35:09 GMT 3571 Session: 12345678 3572 Server: PhonyServer/1.0 3573 Range: npt=14-25 3574 Seek-Style: Next 3575 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3576 ssrc=0D12F123:seq=5712;rtptime=934239921, 3577 url="rtsp://example.com/fizzle/videotrack" 3578 ssrc=789DAF12:seq=57654;rtptime=2792842193 3580 A common use of a PLAY request while in Play state is changing the 3581 scale of the media, i.e., entering or leaving fast forward or fast 3582 rewind. The client can issue an updating PLAY request that is either 3583 a continuation or a complete replacement, as discussed above this 3584 section. Below is an example of a client that is requesting a fast 3585 forward (scale=2) without giving a stop point and then change from 3586 fast forward to regular playout (scale = 1). In the second PLAY 3587 request the time is set explicitly to be where ever the server 3588 currently plays out (npt=now-) and the server responds with the 3589 actual playback point where the new scale actually takes effect 3590 (npt=02:17:27.144-). 3592 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3593 CSeq: 2034 3594 Session: 12345678 3595 Range: npt=now- 3596 Scale: 2.0 3597 User-Agent: PhonyClient/1.2 3599 S->C: RTSP/2.0 200 OK 3600 CSeq: 2034 3601 Date: Thu, 23 Jan 1997 15:35:06 GMT 3602 Session: 12345678 3603 Server: PhonyServer/1.0 3604 Range: npt=02:17:21.394- 3605 Seek-Style: Next 3606 Scale: 2.0 3607 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3608 ssrc=0D12F123:seq=5712;rtptime=934207921, 3609 url="rtsp://example.com/fizzle/videotrack" 3610 ssrc=789DAF12:seq=57654;rtptime=2792482193 3612 [playing in fast forward and now returning to scale = 1] 3614 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3615 CSeq: 2035 3616 Session: 12345678 3617 Range: npt=now- 3618 Scale: 1.0 3619 User-Agent: PhonyClient/1.2 3621 S->C: RTSP/2.0 200 OK 3622 CSeq: 2035 3623 Date: Thu, 23 Jan 1997 15:35:09 GMT 3624 Session: 12345678 3625 Server: PhonyServer/1.0 3626 Range: npt=02:17:27.144- 3627 Seek-Style: Next 3628 Scale: 1.0 3629 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3630 ssrc=0D12F123:seq=5712;rtptime=934239921, 3631 url="rtsp://example.com/fizzle/videotrack" 3632 ssrc=789DAF12:seq=57654;rtptime=2792842193 3634 13.4.4. Playing On-Demand Media 3636 On-demand media is indicated by the content of the Media-Properties 3637 header in the SETUP response by (see also Section 18.29): 3639 o Random Access property is set to Random-Access; 3641 o Content Modifications set to Immutable; 3643 o Retention set to Unlimited or Time-Limited. 3645 Playing on-demand media follows the general usage as described in 3646 Section 13.4.1. 3648 13.4.5. Playing Dynamic On-Demand Media 3650 Dynamic on-demand media is indicated by the content of the Media- 3651 Properties header in the SETUP response by (see also Section 18.29): 3653 o Random Access set to Random-Access; 3655 o Content Modifications set to Dynamic; 3657 o Retention set to Unlimited or Time-Limited. 3659 Playing on-demand media follows the general usage as described in 3660 Section 13.4.1 as long as the media has not been changed. 3662 There are two ways for the client to be informed about changes of 3663 media resources in Play state. The client will receive a PLAY_NOTIFY 3664 request with Notify-Reason header set to media-properties-update (see 3665 Section 13.5.2. The client can use the value of the Media-Range to 3666 decide further actions, if the Media-Range header is present in the 3667 PLAY_NOTIFY request. The second way is that the client issues a 3668 GET_PARAMETER request without a body but including a Media-Range 3669 header. The 200 OK response MUST include the current Media-Range 3670 header (see Section 18.30). 3672 13.4.6. Playing Live Media 3674 Live media is indicated by the content of the Media-Properties header 3675 in the SETUP response by (see also Section 18.29): 3677 o Random-Access set to No-Seeking; 3679 o Content Modifications set to Time-Progressing; 3681 o Retention with Time-Duration set to 0.0. 3683 For live media, the SETUP response 200 OK MUST include the Media- 3684 Range header (see Section 18.30). 3686 A client MAY send PLAY requests without the Range header. If the 3687 request includes the Range header it MUST use a symbolic value 3688 representing "now". For NPT that range specification is "npt=now-". 3689 The server MUST include the Range header in the response and it MUST 3690 indicate an explicit time value and not a symbolic value. In other 3691 words, "npt=now-" is not valid to be used in the response. Instead 3692 the time since session start is recommended expressed as an open 3693 interval, e.g., "npt=96.23-". An absolute time value (clock) for the 3694 corresponding time MAY be given, i.e., "clock=20030213T143205Z-". 3695 The Absolute Time format can only be used if client has shown support 3696 for it using the Accept-Ranges header. 3698 13.4.7. Playing Live with Recording 3700 Certain media servers may offer recording services of live sessions 3701 to their clients. This recording would normally be from the 3702 beginning of the media session. Clients can randomly access the 3703 media between now and the beginning of the media session. This live 3704 media with recording is indicated by the content of the Media- 3705 Properties header in the SETUP response by (see also Section 18.29): 3707 o Random Access set to Random-Access; 3709 o Content Modifications set to Time-Progressing; 3711 o Retention set to Time-Limited or Unlimited 3713 The SETUP response 200 OK MUST include the Media-Range header (see 3714 Section 18.30) for this type of media. For live media with 3715 recording, the Range header indicates the current delivery point in 3716 the media and the Media-Range header indicates the currently 3717 available media window around the current time. This window can 3718 cover recorded content in the past (seen from current time in the 3719 media) or recorded content in the future (seen from current time in 3720 the media). The server adjusts the delivery point to the requested 3721 border of the window. If the client requests a delivery point that 3722 is located outside the recording window, e.g., if the requested point 3723 is too far in the past, the server selects the oldest point in the 3724 recording. The considerations in Section 13.5.3 apply if a client 3725 requests delivery with Scale (Section 18.46) values other than 1.0 3726 (Normal playback rate) while delivering live media with recording. 3728 13.4.8. Playing Live with Time-Shift 3730 Certain media servers may offer time-shift services to their clients. 3731 This time shift records a fixed interval in the past, i.e., a sliding 3732 window recording mechanism, but not past this interval. Clients can 3733 randomly access the media between now and the interval. This live 3734 media with recording is indicated by the content of the Media- 3735 Properties header in the SETUP response by (see also Section 18.29): 3737 o Random Access set to Random-Access; 3739 o Content Modifications set to Time-Progressing; 3741 o Retention set to Time-Duration and a value indicating the 3742 recording interval (>0). 3744 The SETUP response 200 OK MUST include the Media-Range header (see 3745 Section 18.30) for this type of media. For live media with recording 3746 the Range header indicates the current time in the media and the 3747 Media Range indicates a window around the current time. This window 3748 can cover recorded content in the past (seen from current time in the 3749 media) or recorded content in the future (seen from current time in 3750 the media). The server adjusts the play point to the requested 3751 border of the window, if the client requests a play point that is 3752 located outside the recording windows, e.g., if requested too far in 3753 the past, the server selects the oldest range in the recording. The 3754 considerations in Section 13.5.3 apply, if a client requests delivery 3755 using a Scale (Section 18.46) value other than 1.0 (Normal playback 3756 rate) while delivering live media with time-shift. 3758 13.5. PLAY_NOTIFY 3760 The PLAY_NOTIFY method is issued by a server to inform a client about 3761 an asynchronous event for a session in Play state. The Session 3762 header MUST be presented in a PLAY_NOTIFY request and indicates the 3763 scope of the request. Sending of PLAY_NOTIFY requests requires a 3764 persistent connection between server and client, otherwise there is 3765 no way for the server to send this request method to the client. 3767 PLAY_NOTIFY requests have an end-to-end (i.e., server to client) 3768 scope, as they carry the Session header, and apply only to the given 3769 session. The client SHOULD immediately return a response to the 3770 server. 3772 PLAY_NOTIFY requests MAY use both aggregate control URI and 3773 individual media resource URIs depending on the scope of the 3774 notification. This scope may have important distinctions for 3775 aggregated sessions, and each reason for a PLAY_NOTIFY request needs 3776 to specify the interpretation and if aggregated control URIs or 3777 individual URIs may be used in requests. 3779 PLAY_NOTIFY requests can be used with a message body, depending on 3780 the value of the Notify-Reason header. It is described in the 3781 particular section for each Notify-Reason if a message body is used. 3782 However, currently there is no Notify-Reason that allows using a 3783 message body. In this case, there is a need to obey some limitations 3784 when adding new Notify-Reasons that intend to use a message body: the 3785 server can send any type of message body, but it is not ensured that 3786 the client can understand the received message body. This is related 3787 to DESCRIBE (see Section 13.2 ), but in this particular case the 3788 client can state its acceptable message bodies by using the Accept 3789 header. In the case of PLAY_NOTIFY, the server does not know which 3790 message bodies are understood by the client. 3792 The Notify-Reason header (see Section 18.32) specifies the reason why 3793 the server sends the PLAY_NOTIFY request. This is extensible and new 3794 reasons can be added in the future (see Section 22.8). In case the 3795 client does not understand the reason for the notification it MUST 3796 respond with a 465 (Notification Reason Unknown) (Section 17.4.30) 3797 error code. Servers can send PLAY_NOTIFY with these types: 3799 o end-of-stream (see Section 13.5.1); 3801 o media-properties-update (see Section 13.5.2); 3803 o scale-change (see Section 13.5.3). 3805 13.5.1. End-of-Stream 3807 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3808 indicates the completion or near completion of the PLAY request and 3809 the ending delivery of the media stream(s). The request MUST NOT be 3810 issued unless the server is in the Play state. The end of the media 3811 stream delivery notification may be used to indicate either a 3812 successful completion of the PLAY request currently being served, or 3813 to indicate some error resulting in failure to complete the request. 3814 The Request-Status header (Section 18.42) MUST be included to 3815 indicate which request the notification is for and its completion 3816 status. The message response status codes (Section 8.1.1) are used 3817 to indicate how the PLAY request concluded. The sender of a 3818 PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a 3819 PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY 3820 was issued before reaching the end-of-stream, but some error occurred 3821 resulting in that the previously sent PLAY_NOTIFY contained a wrong 3822 time when the stream will end. In this case a new PLAY_NOTIFY MUST 3823 be sent including the correct status for the completion and all 3824 additional information. 3826 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream 3827 MUST include a Range header and the Scale header if the scale value 3828 is not 1. The Range header indicates the point in the stream or 3829 streams where delivery is ending with the timescale that was used by 3830 the server in the PLAY response for the request being fulfilled. The 3831 server MUST NOT use the "now" constant in the Range header; it MUST 3832 use the actual numeric end position in the proper timescale. When 3833 end-of-stream notifications are issued prior to having sent the last 3834 media packets, this is evident as the end time in the Range header is 3835 beyond the current time in the media being received by the client, 3836 e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale 3837 header is to be included so that it is evident if the media time 3838 scale is moving backwards and/or have a non-default pace. The end- 3839 of-stream notification does not prevent the client from sending a new 3840 PLAY request. 3842 If RTP is used as media transport, a RTP-Info header MUST be 3843 included, and the RTP-Info header MUST indicate the last sequence 3844 number in the seq parameter. 3846 For an RTSP Session where media resources are under aggregated 3847 control the media resources will normally end at approximately the 3848 same time, although some small differences may exist, on the scale of 3849 a few hundred of milliseconds. In those cases a RTSP session under 3850 aggregated control SHOULD send only a single PLAY_NOTIFY request. By 3851 using the aggregate control URI in the PLAY_NOTIFY request the RTSP 3852 server indicates that this applies to all media resources within the 3853 session. In cases RTP is used for media delivery corresponding RTP- 3854 Info needs to be included for all media resources. In cases where 3855 one or more media resource has significantly shorter duration than 3856 some other resources in the aggregated session the server MAY send 3857 end-of-stream notifications using individual media resource URIs to 3858 indicate to agents that there will be no more media for this 3859 particular media resource related to the current active PLAY request. 3860 In such cases when the remaining media resources comes to end-of- 3861 stream they MUST send a PLAY_NOTIFY request using the aggregate 3862 control URI to indicate that no more resources remain. 3864 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3865 MUST NOT carry a message body. 3867 This example request notifies the client about a future end-of-stream 3868 event: 3870 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3871 CSeq: 854 3872 Notify-Reason: end-of-stream 3873 Request-Status: cseq=853 status=200 reason="OK" 3874 Range: npt=-145 3875 RTP-Info:url="rtsp://example.com/fizzle/foo/audio" 3876 ssrc=0D12F123:seq=14783;rtptime=2345962545, 3877 url="rtsp://example.com/fizzle/video" 3878 ssrc=789DAF12:seq=57654;rtptime=2792482193 3880 Session: uZ3ci0K+Ld-M 3881 Date: Mon, 08 Mar 2010 13:37:16 GMT 3883 C->S: RTSP/2.0 200 OK 3884 CSeq: 854 3885 User-Agent: PhonyClient/1.2 3886 Session: uZ3ci0K+Ld-M 3888 13.5.2. Media-Properties-Update 3890 A PLAY_NOTIFY request with Notify-Reason header set to media- 3891 properties-update indicates an update of the media properties for the 3892 given session (see Section 18.29) and/or the available media range 3893 that can be played as indicated by Media-Range (Section 18.30). 3894 PLAY_NOTIFY requests with Notify-Reason header set to media- 3895 properties-update MUST include a Media-Properties and Date header and 3896 SHOULD include a Media-Range header. The Media-Properties header has 3897 session scope, thus for aggregated sessions the PLAY_NOTIFY request 3898 MUST be using the aggregated control URI. 3900 This notification MUST be sent for media that are Time-Progressing 3901 every time an event happens that changes the basis for making 3902 estimates on how the available for play-back media range will 3903 progress with wall clock time. In addition it is RECOMMENDED that 3904 the server sends these notifications approximately every 5 minutes 3905 for time-progressing content to ensure the long-term stability of the 3906 client estimation and allowing for clock skew detection by the 3907 client. The time between notifications should be greater than 1 3908 minute and less than 2 hours. For the reasons just explained, 3909 requests MUST include a Media-Range header to provide current Media 3910 duration and a Range header to indicate the current playing point and 3911 any remaining parts of the requested range. 3913 The recommendation for sending updates every 5 minutes is due to 3914 any clock skew issues. In 5 minutes the clock skew should not 3915 become too significant as this is not used for media playback and 3916 synchronization, only for determining which content is available 3917 to the user. 3919 A PLAY_NOTIFY request with Notify-Reason header set to media- 3920 properties-update MUST NOT carry a message body. 3922 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3923 Date: Tue, 14 Apr 2008 15:48:06 GMT 3924 CSeq: 854 3925 Notify-Reason: media-properties-update 3926 Session: uZ3ci0K+Ld-M 3927 Media-Properties: Time-Progressing, 3928 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3929 Media-Range: npt=00:00:00-01:37:21.394 3930 Range: npt=01:15:49.873- 3932 C->S: RTSP/2.0 200 OK 3933 CSeq: 854 3934 User-Agent: PhonyClient/1.2 3935 Session: uZ3ci0K+Ld-M 3937 13.5.3. Scale-Change 3939 The server may be forced to change the rate of media time per 3940 playback time when a client requests delivery using a Scale 3941 (Section 18.46) value other than 1.0 (normal playback rate). For 3942 time progressing media with some retention, i.e., the server stores 3943 already sent content, a client requesting to play with Scale values 3944 larger than 1 may catch up with the front end of the media. The 3945 server will then be unable to continue to provide content at Scale 3946 larger than 1 as content is only made available by the server at 3947 Scale=1. Another case is when Scale < 1 and the media retention is 3948 time-duration limited. In this case the delivery point can reach the 3949 oldest media unit available, and further playback at this scale 3950 becomes impossible as there will be no media available. To avoid 3951 having the client lose any media, the scale will need to be adjusted 3952 to the same rate at which the media is removed from the storage 3953 buffer, commonly Scale = 1.0. 3955 Another case is when the content itself consists of spliced pieces or 3956 is dynamically updated. In these cases the server may be required to 3957 change from one supported scale value (different than Scale=1.0) to 3958 another. In this case the server will pick the closest value and 3959 inform the client of what it has picked. In these cases the media 3960 properties will also be sent updating the supported Scale values. 3961 This enables a client to adjust the Scale value used. 3963 To minimize impact on playback in any of the above cases the server 3964 MUST modify the playback properties and set Scale to a supportable 3965 value and continue delivery of the media. When doing this 3966 modification it MUST send a PLAY_NOTIFY message with the Notify- 3967 Reason header set to "scale-change". The request MUST contain a 3968 Range header with the media time when the change took effect, a Scale 3969 header with the new value in use, Session header with the identifier 3970 for the session it applies to and a Date header with the server 3971 wallclock time of the change. For time progressing content also the 3972 Media-Range and the Media-Properties at this point in time MUST be 3973 included. The Media-Properties header MUST be included if the scale 3974 change was due to the content changing what scale values that is 3975 supported. 3977 For media streams being delivered using RTP also a RTP-Info header 3978 MUST be included. It MUST contain the rtptime parameter with a value 3979 corresponding to the point of change in that media and optionally 3980 also the sequence number. 3982 PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated 3983 control URI in the request. The scale change for any aggregated 3984 session applies to all media streams part of the aggregate. 3986 A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" 3987 MUST NOT carry a message body. 3989 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3990 Date: Tue, 14 Apr 2008 15:48:06 GMT 3991 CSeq: 854 3992 Notify-Reason: scale-change 3993 Session: uZ3ci0K+Ld-M 3994 Media-Properties: Time-Progressing, 3995 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3996 Media-Range: npt=00:00:00-01:37:21.394 3997 Range: npt=01:37:21.394- 3998 Scale: 1 3999 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" 4000 ssrc=0D12F123:rtptime=2345962545, 4001 url="rtsp://example.com/fizzle/videotrack" 4002 ssrc=789DAF12:seq=57654;rtptime=2792482193 4004 C->S: RTSP/2.0 200 OK 4005 CSeq: 854 4006 User-Agent: PhonyClient/1.2 4007 Session: uZ3ci0K+Ld-M 4009 13.6. PAUSE 4011 The PAUSE request causes the stream delivery to immediately be 4012 interrupted (halted). A PAUSE request MUST be done either with the 4013 aggregated control URI for aggregated sessions, resulting in all 4014 media being halted, or the media URI for non-aggregated sessions. 4016 Any attempt to do muting of a single media with a PAUSE request in an 4017 aggregated session MUST be responded to with error 460 (Only 4018 Aggregate Operation Allowed). After resuming playback, 4019 synchronization of the tracks MUST be maintained. Any server 4020 resources are kept, though servers MAY close the session and free 4021 resources after being paused for the duration specified with the 4022 timeout parameter of the Session header in the SETUP message. 4024 Example: 4026 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4027 CSeq: 834 4028 Session: 12345678 4029 User-Agent: PhonyClient/1.2 4031 S->C: RTSP/2.0 200 OK 4032 CSeq: 834 4033 Date: Thu, 23 Jan 1997 15:35:06 GMT 4034 Range: npt=45.76-75.00 4036 The PAUSE request causes stream delivery to be interrupted 4037 immediately on receipt of the message and the pause point is set to 4038 the current point in the presentation. That pause point in the media 4039 stream needs to be maintained. A subsequent PLAY request without 4040 Range header resumes from the pause point and plays until media end. 4042 The pause point after any PAUSE request MUST be returned to the 4043 client by adding a Range header with what remains unplayed of the 4044 PLAY request's range. For media with random access properties, if 4045 one desires to resume playing a ranged request, one simply includes 4046 the Range header from the PAUSE response and includes the Seek-Style 4047 header with the Next policy in the PLAY request. For media that is 4048 time-progressing and has retention duration=0 the follow-up PLAY 4049 request to start media delivery again, MUST use "npt=now-" and not 4050 the answer given in the response to PAUSE. 4052 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 4053 CSeq: 834 4054 Session: 12345678 4055 Range: npt=10-30 4056 User-Agent: PhonyClient/1.2 4058 S->C: RTSP/2.0 200 OK 4059 CSeq: 834 4060 Date: Thu, 23 Jan 1997 15:35:06 GMT 4061 Server: PhonyServer/1.0 4062 Range: npt=10-30 4063 Seek-Style: First-Prior 4064 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 4065 ssrc=0D12F123:seq=5712;rtptime=934207921, 4066 url="rtsp://example.com/fizzle/videotrack" 4067 ssrc=4FAD8726:seq=57654;rtptime=2792482193 4068 Session: 12345678 4070 After 11 seconds, i.e., at 21 seconds into the presentation: 4071 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4072 CSeq: 835 4073 Session: 12345678 4074 User-Agent: PhonyClient/1.2 4076 S->C: RTSP/2.0 200 OK 4077 CSeq: 835 4078 Date: 23 Jan 1997 15:35:17 GMT 4079 Server: PhonyServer/1.0 4080 Range: npt=21-30 4081 Session: 12345678 4083 If a client issues a PAUSE request and the server acknowledges and 4084 enters the Ready state, the proper server response, if the player 4085 issues another PAUSE, is still 200 OK. The 200 OK response MUST 4086 include the Range header with the current pause point. See examples 4087 below: 4089 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4090 CSeq: 834 4091 Session: 12345678 4092 User-Agent: PhonyClient/1.2 4094 S->C: RTSP/2.0 200 OK 4095 CSeq: 834 4096 Session: 12345678 4097 Date: Thu, 23 Jan 1997 15:35:06 GMT 4098 Range: npt=45.76-98.36 4100 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4101 CSeq: 835 4102 Session: 12345678 4103 User-Agent: PhonyClient/1.2 4105 S->C: RTSP/2.0 200 OK 4106 CSeq: 835 4107 Session: 12345678 4108 Date: 23 Jan 1997 15:35:07 GMT 4109 Range: npt=45.76-98.36 4111 13.7. TEARDOWN 4113 13.7.1. Client to Server 4115 The TEARDOWN client to server request stops the stream delivery for 4116 the given URI, freeing the resources associated with it. A TEARDOWN 4117 request can be performed on either an aggregated or a media control 4118 URI. However, some restrictions apply depending on the current 4119 state. The TEARDOWN request MUST contain a Session header indicating 4120 what session the request applies to. The TEARDOWN request MUST NOT 4121 include a Terminate-Reason header. 4123 A TEARDOWN using the aggregated control URI or the media URI in a 4124 session under non-aggregated control (single media session) MAY be 4125 done in any state (Ready and Play). A successful request MUST result 4126 in that media delivery being immediately halted and the session state 4127 being destroyed. This MUST be indicated through the lack of a 4128 Session header in the response. 4130 A TEARDOWN using a media URI in an aggregated session can only be 4131 done in Ready state. Such a request only removes the indicated media 4132 stream and associated resources from the session. This may result in 4133 a session returning to non-aggregated control, because it only 4134 contains a single media after the request's completion. A session 4135 that will exist after the processing of the TEARDOWN request MUST in 4136 the response to that TEARDOWN request contain a Session header. Thus 4137 the presence of the Session header indicates to the receiver of the 4138 response if the session is still extant or has been removed. 4140 Example: 4142 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 4143 CSeq: 892 4144 Session: 12345678 4145 User-Agent: PhonyClient/1.2 4147 S->C: RTSP/2.0 200 OK 4148 CSeq: 892 4149 Server: PhonyServer/1.0 4151 13.7.2. Server to Client 4153 The server can send TEARDOWN requests in the server to client 4154 direction to indicate that the server has been forced to terminate 4155 the ongoing session. This may happen for several reasons, such as 4156 server maintenance without available backup, or that the session has 4157 been inactive for extended periods of time. The reason is provided 4158 in the Terminate-Reason header (Section 18.52). 4160 When a RTSP client has maintained a RTSP session that otherwise is 4161 inactive for an extended period of time the server may reclaim the 4162 resources. That is done by issuing a TEARDOWN request with the 4163 Terminate-Reason set to "Session-Timeout". This MAY be done when the 4164 client has been inactive in the RTSP session for more than one 4165 Session Timeout period (Section 18.49). However, the server is 4166 RECOMMENDED to not perform this operation until an extended period of 4167 inactivity of 10 times the Session Timeout period has passed. It is 4168 up to the operator of the RTSP server to actually configure how long 4169 this extended period of inactivity is. An operator should take into 4170 account when doing this configuration what the served content is and 4171 what this means for the extended period of inactivity. 4173 In case the server needs to stop providing service to the established 4174 sessions and there is no server to point at in a REDIRECT request, 4175 then TEARDOWN SHALL be used to terminate the session. This method 4176 can also be used when non-recoverable internal errors have happened 4177 and the server has no other option then to terminate the sessions. 4179 The TEARDOWN request MUST be done only on the session aggregate 4180 control URI (i.e., it is not allowed to terminate individual media 4181 streams, if it is a session aggregate) and MUST include the following 4182 headers; Session and Terminate-Reason headers. The request only 4183 applies to the session identified in the Session header. The server 4184 may include a message to the client's user with the "user-msg" 4185 parameter. 4187 The TEARDOWN request may alternatively be done on the wild card URI * 4188 and without any session header. The scope of such a request is 4189 limited to the next-hop (i.e., the RTSP agent in direct communication 4190 with the server) and applies, as well, to the RTSP connection between 4191 the next-hop RTSP agent and the server. This request indicates that 4192 all sessions and pending requests being managed via the connection 4193 are terminated. Any intervening proxies SHOULD do all of the 4194 following in the order listed: 4196 1. respond to the TEARDOWN request 4198 2. disconnect the control channel from the requesting server 4200 3. pass the TEARDOWN request to each applicable client (typically 4201 those clients with an active session or an unanswered request) 4203 Note: The proxy is responsible for accepting TEARDOWN responses 4204 from its clients; these responses MUST NOT be passed on to either 4205 the original server or the target server in the redirect. 4207 13.8. GET_PARAMETER 4209 The GET_PARAMETER request retrieves the value of any specified 4210 parameter or parameters for a presentation or stream specified in the 4211 URI. If the Session header is present in a request, the value of a 4212 parameter MUST be retrieved in the specified session context. There 4213 are two ways of specifying the parameters to be retrieved. 4215 The first is by including headers which have been defined such that 4216 you can use them for this purpose. Headers for this purpose should 4217 allow empty, or stripped value parts to avoid having to specify bogus 4218 data when indicating the desire to retrieve a value. The successful 4219 completion of the request should also be evident from any filled out 4220 values in the response. The headers in this specification that MAY 4221 be used for retrieving their current value using GET_PARAMETER are 4222 listed below; additional headers MAY be specified in the future: 4224 o Accept-Ranges 4226 o Media-Range 4228 o Media-Properties 4230 o Range 4231 o RTP-Info 4233 The other way is to specify a message body that lists the 4234 parameter(s) that are desired to be retrieved. The Content-Type 4235 header (Section 18.19) is used to specify which format the message 4236 body has. If the receiver of the request does not support the media 4237 type used for the message body, it SHALL respond using the error code 4238 415 (Unsupported Media Type). The responder to a GET_PARAMETER 4239 request MUST use the media type of the request for the response. For 4240 additional considerations regarding message body negotiation see 4241 Section 9.3. 4243 RTSP Agents implementing support for responding to GET_PARAMETER 4244 requests SHALL implement the text/parameters format (Appendix F). 4245 This to ensure that at least one known format for parameters is 4246 implemented and thus prevent parameter format negotiation failure. 4248 Parameters specified within the body of the message must all be 4249 understood by the request receiving agent. If one or more parameters 4250 are not understood a 451 (Parameter Not Understood) MUST be sent 4251 including a body listing these parameters that weren't understood. 4252 If all parameters are understood their values are filled in and 4253 returned in the response message body. 4255 The method can also be used without a message body or any header that 4256 requests parameters for keep-alive purpose. The keep-alive timer has 4257 been updated for any request that is successful, i.e., a 200 OK 4258 response is received. Any non-required header present in such a 4259 request may or may not have been processed. Normally the presence of 4260 filled out values in the header will be indication that the header 4261 has been processed. However, for cases when this is difficult to 4262 determine, it is recommended to use a feature-tag and the Require 4263 header. For this reason it is usually easier if any parameters to be 4264 retrieved are sent in the body, rather than using any header. 4266 Example: 4268 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4269 CSeq: 431 4270 User-Agent: PhonyClient/1.2 4271 Session: 12345678 4272 Content-Length: 26 4273 Content-Type: text/parameters 4275 packets_received 4276 jitter 4278 C->S: RTSP/2.0 200 OK 4279 CSeq: 431 4280 Session: 12345678 4281 Server: PhonyServer/1.1 4282 Date: Mon, 08 Mar 2010 13:43:23 GMT 4283 Content-Length: 38 4284 Content-Type: text/parameters 4286 packets_received: 10 4287 jitter: 0.3838 4289 13.9. SET_PARAMETER 4291 This method requests to set the value of a parameter or a set of 4292 parameters for a presentation or stream specified by the URI. The 4293 method MAY also be used without a message body. It is the 4294 RECOMMENDED method to be used in a request sent for the sole purpose 4295 of updating the keep-alive timer. If this request is successful, 4296 i.e., a 200 OK response is received, then the keep-alive timer has 4297 been updated. Any non-required header present in such a request may 4298 or may not have been processed. To allow a client to determine if 4299 any such header has been processed, it is necessary to use a feature 4300 tag and the Require header. Due to this reason it is RECOMMENDED 4301 that any parameters are sent in the body, rather than using any 4302 header. 4304 When using a message body to list the parameter(s) that are desired 4305 to be set the Content-Type header (Section 18.19) is used to specify 4306 which format the message body has. If the receiver of the request is 4307 not supporting the media type used for the message body, it SHALL 4308 respond using the error code 415 (Unsupported Media Type). For 4309 additional considerations regarding message body negotiation see 4310 Section 9.3. 4312 RTSP Agents implementing support for responding to SET_PARAMETER 4313 requests SHALL implement the text/parameters format (Appendix F). 4314 This to ensure that at least one known format for parameters is 4315 implemented and thus prevent parameter format negotiation failure. 4317 A request is RECOMMENDED to only contain a single parameter to allow 4318 the client to determine why a particular request failed. If the 4319 request contains several parameters, the server MUST only act on the 4320 request if all of the parameters can be set successfully. A server 4321 MUST allow a parameter to be set repeatedly to the same value, but it 4322 MAY disallow changing parameter values. If the receiver of the 4323 request does not understand or cannot locate a parameter, error 451 4324 (Parameter Not Understood) MUST be used. When a parameter is not 4325 allowed to change, the error code is 458 (Parameter Is Read-Only). 4326 The response body MUST contain only the parameters that have errors. 4327 Otherwise, a body MUST NOT be returned. The response body MUST use 4328 the media type of the request for the response. 4330 Note: transport parameters for the media stream MUST only be set with 4331 the SETUP command. 4333 Restricting setting transport parameters to SETUP is for the 4334 benefit of firewalls. 4336 The parameters are split in a fine-grained fashion so that there 4337 can be more meaningful error indications. However, it may make 4338 sense to allow the setting of several parameters if an atomic 4339 setting is desirable. Imagine device control where the client 4340 does not want the camera to pan unless it can also tilt to the 4341 right angle at the same time. 4343 Example: 4345 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4346 CSeq: 421 4347 User-Agent: PhonyClient/1.2 4348 Session: iixT43KLc 4349 Date: Mon, 08 Mar 2010 14:45:04 GMT 4350 Content-length: 20 4351 Content-type: text/parameters 4353 barparam: barstuff 4355 S->C: RTSP/2.0 451 Parameter Not Understood 4356 CSeq: 421 4357 Session: iixT43KLc 4358 Server: PhonyServer/1.0 4359 Date: Mon, 08 Mar 2010 14:44:56 GMT 4360 Content-length: 20 4361 Content-type: text/parameters 4363 barparam: barstuff 4365 13.10. REDIRECT 4367 The REDIRECT method is issued by a server to inform a client that the 4368 service provided will be terminated and where a corresponding service 4369 can be provided instead. This may happen for different reasons. One 4370 is that the server is being administered such that it must stop 4371 providing service. Thus the client is required to connect to another 4372 server location to access the resource indicated by the Request-URI. 4374 The REDIRECT request SHALL contain a Terminate-Reason header 4375 (Section 18.52) to inform the client of the reason for the request. 4376 Additional parameters related to the reason may also be included. 4377 The intention here is to allow a server administrator to do a 4378 controlled shutdown of the RTSP server. That requires sufficient 4379 time to inform all entities having associated state with the server 4380 and for them to perform a controlled migration from this server to a 4381 fall back server. 4383 A REDIRECT request with a Session header has end-to-end (i.e., server 4384 to client) scope and applies only to the given session. Any 4385 intervening proxies SHOULD NOT disconnect the control channel while 4386 there are other remaining end-to-end sessions. The REQUIRED Location 4387 header MUST contain a complete absolute URI pointing to the resource 4388 to which the client SHOULD reconnect. Specifically, the Location 4389 MUST NOT contain just the host and port. A client may receive a 4390 REDIRECT request with a Session header, if and only if, an end-to-end 4391 session has been established. 4393 A client may receive a REDIRECT request without a Session header at 4394 any time when it has communication or a connection established with a 4395 server. The scope of such a request is limited to the next-hop 4396 (i.e., the RTSP agent in direct communication with the server) and 4397 applies to all sessions controlled, as well as the connection between 4398 the next-hop RTSP agent and the server. A REDIRECT request without a 4399 Session header indicates that all sessions and pending requests being 4400 managed via the connection MUST be redirected. The Location header, 4401 if included in such a request, SHOULD contain an absolute URI with 4402 only the host address and the OPTIONAL port number of the server to 4403 which the RTSP agent SHOULD reconnect. Any intervening proxies 4404 SHOULD do all of the following in the order listed: 4406 1. respond to the REDIRECT request 4408 2. disconnect the control channel from the requesting server 4410 3. connect to the server at the given host address 4411 4. pass the REDIRECT request to each applicable client (typically 4412 those clients with an active session or an unanswered request) 4414 Note: The proxy is responsible for accepting REDIRECT responses 4415 from its clients; these responses MUST NOT be passed on to either 4416 the original server or the redirected server. 4418 When the server lacks any alternative server and needs to terminate a 4419 session or all sessions the TEARDOWN request SHALL be used instead. 4421 When no Terminate-Reason "time" parameter is included in a REDIRECT 4422 request, the client SHALL perform the redirection immediately and 4423 return a response to the server. The server shall consider the 4424 session as terminated and can free any associated state after it 4425 receives the successful (2xx) response. The server MAY close the 4426 signaling connection upon receiving the response and the client 4427 SHOULD close the signaling connection after sending the 2xx response. 4428 The exception to this is when the client has several sessions on the 4429 server being managed by the given signaling connection. In this 4430 case, the client SHOULD close the connection when it has received and 4431 responded to REDIRECT requests for all the sessions managed by the 4432 signaling connection. 4434 The Terminate-Reason header "time" parameter MAY be used to indicate 4435 the wallclock time by when the redirection MUST have taken place. To 4436 allow a client to determine that redirect time without being time 4437 synchronized with the server, the server MUST include a Date header 4438 in the request. The client should have terminated the session and 4439 closed the connection before the redirection time-line terminated. 4440 The server MAY simply cease to provide service when the deadline time 4441 has been reached, or it may issue TEARDOWN requests to the remaining 4442 sessions. 4444 If the REDIRECT request times out following the rules in Section 10.4 4445 the server MAY terminate the session or transport connection that 4446 would be redirected by the request. This is a safeguard against 4447 misbehaving clients that refuse to respond to a REDIRECT request. 4448 Thus, removing any incentive to not acknowledge the reception of a 4449 REDIRECT request. 4451 After a REDIRECT request has been processed, a client that wants to 4452 continue to receive media for the resource identified by the Request- 4453 URI will have to establish a new session with the designated host. 4454 If the URI given in the Location header is a valid resource URI, a 4455 client SHOULD issue a DESCRIBE request for the URI. 4457 Note: The media resource indicated by the Location header can be 4458 identical, slightly different or totally different. This is the 4459 reason why a new DESCRIBE request SHOULD be issued. 4461 If the Location header contains only a host address, the client may 4462 assume that the media on the new server is identical to the media on 4463 the old server, i.e., all media configuration information from the 4464 old session is still valid except for the host address. However, the 4465 usage of conditional SETUP using MTag identifiers is RECOMMENDED as a 4466 means to verify the assumption. 4468 This example request redirects traffic for this session to the new 4469 server at the given absolute time: 4471 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 4472 CSeq: 732 4473 Location: rtsp://s2.example.com:8001 4474 Terminate-Reason: Server-Admin ;time=19960213T143205Z 4475 Session: uZ3ci0K+Ld-M 4476 Date: Thu, 13 Feb 1996 14:30:43 GMT 4478 C->S: RTSP/2.0 200 OK 4479 CSeq: 732 4480 User-Agent: PhonyClient/1.2 4481 Session: uZ3ci0K+Ld-M 4483 14. Embedded (Interleaved) Binary Data 4485 In order to fulfill certain requirements on the network side, e.g., 4486 in conjunction with network address translators that block RTP 4487 traffic over UDP, it may be necessary to interleave RTSP messages and 4488 media stream data. This interleaving should generally be avoided 4489 unless necessary since it complicates client and server operation and 4490 imposes additional overhead. Also, head-of-line blocking may cause 4491 problems. Interleaved binary data SHOULD only be used if RTSP is 4492 carried over TCP. Interleaved data is not allowed inside RTSP 4493 messages. 4495 Stream data such as RTP packets is encapsulated by an ASCII dollar 4496 sign (36 decimal), followed by a one-octet channel identifier, 4497 followed by the length of the encapsulated binary data as a binary, 4498 two-octet unsigned integer in network octet order (Appendix B of 4499 [RFC0791]). The stream data follows immediately afterwards, without 4500 a CRLF, but including the upper-layer protocol headers. Each $ block 4501 MUST contain exactly one upper-layer protocol data unit, e.g., one 4502 RTP packet. 4504 Note that this mechanism does not support PDUs larger than 65535 4505 octets, which matches the maximum payload size of regular, non- 4506 jumbo IPv4 and IPv6 packets. If the media delivery protocol 4507 intended to be used has larger PDUs than that, definition of a PDU 4508 fragmentation mechanism will be required to support embedded 4509 binary data. 4511 0 1 2 3 4512 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4514 | "$" = 36 | Channel ID | Length in octets | 4515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4516 : Binary data (Length according to Length field) : 4517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4519 Figure 1: Embedded Interleaved Binary Data Format 4521 The channel identifier is defined in the Transport header with the 4522 interleaved parameter (Section 18.54). 4524 When the transport choice is RTP, RTCP messages are also interleaved 4525 by the server over the TCP connection. The usage of RTCP messages is 4526 indicated by including an interval containing a second channel in the 4527 interleaved parameter of the Transport header, see Section 18.54. If 4528 RTCP is used, packets MUST be sent on the first available channel 4529 higher than the RTP channel. The channels are bi-directional, using 4530 the same Channel ID in both directions, and therefore RTCP traffic is 4531 sent on the second channel in both directions. 4533 RTCP is sometimes needed for synchronization when two or more 4534 streams are interleaved in such a fashion. Also, this provides a 4535 convenient way to tunnel RTP/RTCP packets through the RTSP 4536 connection (TCP or TCP/TLS) when required by the network 4537 configuration and transfer them onto UDP when possible. 4539 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 4540 CSeq: 2 4541 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 4542 Accept-Ranges: npt, smpte, clock 4543 User-Agent: PhonyClient/1.2 4545 S->C: RTSP/2.0 200 OK 4546 CSeq: 2 4547 Date: Thu, 05 Jun 1997 18:57:18 GMT 4548 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 4549 Session: 12345678 4550 Accept-Ranges: npt 4551 Media-Properties: Random-Access=0.2, Immutable, Unlimited 4553 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 4554 CSeq: 3 4555 Session: 12345678 4556 User-Agent: PhonyClient/1.2 4558 S->C: RTSP/2.0 200 OK 4559 CSeq: 3 4560 Session: 12345678 4561 Date: Thu, 05 Jun 1997 18:57:19 GMT 4562 RTP-Info: url="rtsp://example.com/bar.file" 4563 ssrc=0D12F123:seq=232433;rtptime=972948234 4564 Range: npt=0-56.8 4565 Seek-Style: RAP 4567 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4568 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4569 S->C: $006{2 octet length}{"length" octets RTCP packet} 4571 15. Proxies 4573 RTSP Proxies are RTSP agents that are located in between a client and 4574 a server. A proxy can take on both the role as a client and as 4575 server depending on what it tries to accomplish. RTSP proxies use 4576 two transport layer connections, one from the RTSP client to the RTSP 4577 proxy and a second from the RTSP proxy to the RTSP server. Proxies 4578 are introduced for several different reasons and those listed below 4579 are often combined. 4581 Caching Proxy: This type of proxy is used to reduce the workload on 4582 servers and connections. By caching the description and media 4583 streams, i.e., the presentation, the proxy can serve a client 4584 with content, but without requesting it from the server once it 4585 has been cached and has not become stale. See the caching 4586 Section 16. This type of proxy is also expected to understand 4587 RTSP end-point functionality, i.e., functionality identified in 4588 the Require header in addition to what Proxy-Require demands. 4590 Translator Proxy: This type of proxy is used to ensure that an RTSP 4591 client gets access to servers and content on an external 4592 network or using content encodings not supported by the client. 4593 The proxy performs the necessary translation of addresses, 4594 protocols or encodings. This type of proxy is expected to also 4595 understand RTSP end-point functionality, i.e., functionality 4596 identified in the Require header in addition to what Proxy- 4597 Require demands. 4599 Access Proxy: This type of proxy is used to ensure that an RTSP 4600 client gets access to servers on an external network. Thus 4601 this proxy is placed on the border between two domains, e.g., a 4602 private address space and the public Internet. The proxy 4603 performs the necessary translation, usually addresses. This 4604 type of proxy is required to redirect the media to itself or a 4605 controlled gateway that performs the translation before the 4606 media can reach the client. 4608 Security Proxy: This type of proxy is used to help facilitate 4609 security functions around RTSP. For example when having a 4610 firewalled network, the security proxy requests that the 4611 necessary pinholes in the firewall are opened when a client in 4612 the protected network wants to access media streams on the 4613 external side. This proxy can perform its function without 4614 redirecting the media between the server and client. However, 4615 in deployments with private address spaces this proxy is likely 4616 to be combined with the access proxy. Anyway, the 4617 functionality of this proxy is usually closely tied into 4618 understanding all aspects of the media transport. 4620 Auditing Proxy: RTSP proxies can also provide network owners with a 4621 logging and audit point for RTSP sessions, e.g., for 4622 corporations that track their employees usage of the network. 4623 This type of proxy can perform its function without inserting 4624 itself or any other node in the media transport. This proxy 4625 type can also accept unknown methods as it doesn't interfere 4626 with the clients' requests. 4628 All types of proxies can also be used when using secured 4629 communication with TLS as RTSP 2.0 allows the client to approve 4630 certificate chains used for connection establishment from a proxy, 4631 see Section 19.3.2. However, that trust model may not be suitable 4632 for all types of deployment. In those cases, the secured sessions do 4633 by-pass the proxies. 4635 Access proxies SHOULD NOT be used in equipment like NATs and 4636 firewalls that aren't expected to be regularly maintained, like home 4637 or small office equipment. In these cases it is better to use the 4638 NAT traversal procedures defined for RTSP 2.0 4639 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 4640 that any extensions of RTSP resulting in new media transport 4641 protocols or profiles, new parameters, etc. may fail in a proxy that 4642 isn't maintained. This would impede RTSP's future development and 4643 usage. 4645 15.1. Proxies and Protocol Extensions 4647 The existence of proxies must always be considered when developing 4648 new RTSP extensions. Most types of proxies will need to implement 4649 any new method to operate correctly in the presence of that 4650 extension. New headers can be introduced and will not be blocked by 4651 older proxies. However, it is important to consider if this header 4652 and its function is required to be understood by the proxy or can be 4653 simply forwarded. If the header needs to be understood, a feature- 4654 tag representing the functionality MUST be included in the Proxy- 4655 Require header. Below are guidelines for analysis whether the header 4656 needs to be understood. The transport header and its parameters are 4657 extensible which on the other hand requires handling rules for a 4658 proxy in order to ensure a correct interpretation. 4660 Whether a proxy needs to understand a header is not easy to 4661 determine, as they serve a broad variety of functions. When 4662 evaluating if a header needs to be understood, one can divide the 4663 functionality into three main categories: 4665 Media modifying: The caching and translator proxies are modifying 4666 the actual media and therefore need to understand also the request 4667 directed to the server that affects how the media is rendered. 4668 Thus, this type of proxy needs to also understand the server side 4669 functionality. 4671 Transport modifying: The access and the security proxy both need to 4672 understand how the media transport is performed, either for 4673 opening pinholes or to translate the outer headers, e.g., IP and 4674 UDP or TCP. 4676 Non-modifying: The audit proxy is special in that it does not modify 4677 the messages in other ways than to insert the Via header. That 4678 makes it possible for this type to forward RTSP messages that 4679 contain different types of unknown methods, headers or header 4680 parameters. 4682 Based on the above classification, one should evaluate if the new 4683 functionality requires the Transport modifying type of proxies to 4684 understand it or not. 4686 15.2. Multiplexing and Demultiplexing of Messages 4688 RTSP proxies may have to multiplex multiple RTSP sessions from their 4689 clients towards RTSP servers. This requires that RTSP requests from 4690 multiple clients are multiplexed onto a common connection for 4691 requests outgoing to an RTSP server and on the way back the responses 4692 are demultiplexed from the server to per client responses. On the 4693 protocol level this requires that request and response messages are 4694 handled in both ways, requiring that there is a mechanism to 4695 correlate what request/response pair exchanged between proxy and 4696 server is mapped to what client (or client request). 4698 This multiplexing of requests and demultiplexing of responses is done 4699 by using the CSeq header field. The proxy has to rewrite the CSeq in 4700 requests to the server and responses from the server and remember 4701 what CSeq is mapped to what client. The proxy also needs to ensure 4702 that the order of the message related to each client is maintained. 4703 Section 18.20 is defining the handling of how requests and responses 4704 are rewritten. 4706 16. Caching 4708 In HTTP, request-response pairs are cached. RTSP differs 4709 significantly in that respect. Responses are not cacheable, with the 4710 exception of the presentation description returned by DESCRIBE. 4711 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4712 not return any data, caching is not really an issue for these 4713 requests.) However, it is desirable for the continuous media data, 4714 typically delivered out-of-band with respect to RTSP, to be cached, 4715 as well as the session description. 4717 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4718 has an up-to-date copy of the continuous media content and its 4719 description. It can determine whether the copy is up-to-date by 4720 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4721 Last-Modified header with that of the cached copy. If the copy is 4722 not up-to-date, it modifies the SETUP transport parameters as 4723 appropriate and forwards the request to the origin server. 4724 Subsequent control commands such as PLAY or PAUSE then pass the proxy 4725 unmodified. The proxy delivers the continuous media data to the 4726 client, while possibly making a local copy for later reuse. The 4727 exact allowed behavior of the cache is given by the cache-response 4728 directives described in Section 18.11. A cache MUST answer any 4729 DESCRIBE requests if it is currently serving the stream to the 4730 requester, as it is possible that low-level details of the stream 4731 description may have changed on the origin-server. 4733 Note that an RTSP cache, is of the "cut-through" variety. Rather 4734 than retrieving the whole resource from the origin server, the cache 4735 simply copies the streaming data as it passes by on its way to the 4736 client. Thus, it does not introduce additional latency. 4738 To the client, an RTSP proxy cache appears like a regular media 4739 server. To the media origin server an RTSP proxy cache appears like 4740 a client. Just as an HTTP cache has to store the content type, 4741 content language, and so on for the objects it caches, a media cache 4742 has to store the presentation description. Typically, a cache 4743 eliminates all transport-references (e.g., multicast information) 4744 from the presentation description, since these are independent of the 4745 data delivery from the cache to the client. Information on the 4746 encodings remains the same. If the cache is able to translate the 4747 cached media data, it would create a new presentation description 4748 with all the encoding possibilities it can offer. 4750 16.1. Validation Model 4752 When a cache has a stale entry that it would like to use as a 4753 response to a client's request, it first has to check with the origin 4754 server (or possibly an intermediate cache with a fresh response) to 4755 see if its cached entry is still usable. This is called "validating" 4756 the cache entry. To avoid having to pay the overhead of 4757 retransmitting the full response if the cached entry is good, and at 4758 the same time avoiding to pay the overhead of an extra round trip if 4759 the cached entry is invalid, the RTSP protocol supports the use of 4760 conditional methods. 4762 The key protocol features for supporting conditional methods are 4763 those concerned with "cache validators." When an origin server 4764 generates a full response, it attaches some sort of validator to it, 4765 which is kept with the cache entry. When a client (user agent or 4766 proxy cache) makes a conditional request for a resource for which it 4767 has a cache entry, it includes the associated validator in the 4768 request. 4770 The server then checks that validator against the current validator 4771 for the requested resource, and, if they match (see Section 16.1.3), 4772 it responds with a special status code (usually, 304 (Not Modified)) 4773 and no message body. Otherwise, it returns a full response 4774 (including message body). Thus, avoiding transmitting the full 4775 response if the validator matches, and avoiding an extra round trip 4776 if it does not match. 4778 In RTSP, a conditional request looks exactly the same as a normal 4779 request for the same resource, except that it carries a special 4780 header (which includes the validator) that implicitly turns the 4781 method (usually DESCRIBE or SETUP) into a conditional. 4783 The protocol includes both positive and negative senses of cache- 4784 validating conditions. That is, it is possible to request either 4785 that a method be performed if and only if a validator matches or if 4786 and only if no validators match. 4788 Note: a response that lacks a validator may still be cached, and 4789 served from cache until it expires, unless this is explicitly 4790 prohibited by a cache-control directive (see Section 18.11). 4791 However, a cache cannot do a conditional retrieval if it does not 4792 have a validator for the resource, which means it will not be 4793 refreshable after it expires. 4795 Media streams that are being adapted based on the transport capacity 4796 between the server and the cache makes caching more difficult. A 4797 server needs to consider how it views caching of media streams that 4798 it adapts and potentially instruct any caches to not cache such 4799 streams. 4801 16.1.1. Last-Modified Dates 4803 The Last-Modified header (Section 18.27) value is often used as a 4804 cache validator. In simple terms, a cache entry is considered to be 4805 valid if the cache entry was created after the Last-Modified time. 4807 16.1.2. Message Body Tag Cache Validators 4809 The MTag response-header field value, a message body tag, provides 4810 for an "opaque" cache validator. This might allow more reliable 4811 validation in situations where it is inconvenient to store 4812 modification dates, where the one-second resolution of RTSP-date 4813 values is not sufficient, or where the origin server wishes to avoid 4814 certain paradoxes that might arise from the use of modification 4815 dates. 4817 Message body tags are described in Section 4.6 4819 16.1.3. Weak and Strong Validators 4821 Since both origin servers and caches will compare two validators to 4822 decide if they represent the same or different entities, one normally 4823 would expect that if the message body (i.e., the presentation 4824 description) or any associated message body headers changes in any 4825 way, then the associated validator would change as well. If this is 4826 true, then this validator is a "strong validator." The Message body 4827 (i.e., the presentation description) or any associated message body 4828 headers is named an entity for a better understanding. 4830 However, there might be cases when a server prefers to change the 4831 validator only on semantically significant changes, and not when 4832 insignificant aspects of the entity change. A validator that does 4833 not always change when the resource changes is a "weak validator." 4835 Message body tags are normally "strong validators," but the protocol 4836 provides a mechanism to tag a message body tag as "weak." One can 4837 think of a strong validator as one that changes whenever the bits of 4838 an entity changes, while a weak value changes whenever the meaning of 4839 an entity changes. Alternatively, one can think of a strong 4840 validator as part of an identifier for a specific entity, while a 4841 weak validator is part of an identifier for a set of semantically 4842 equivalent entities. 4844 Note: One example of a strong validator is an integer that is 4845 incremented in stable storage every time an entity is changed. 4847 An entity's modification time, if represented with one-second 4848 resolution, could be a weak validator, since it is possible that 4849 the resource might be modified twice during a single second. 4851 Support for weak validators is optional. However, weak validators 4852 allow for more efficient caching of equivalent objects. 4854 A "use" of a validator is either when a client generates a request 4855 and includes the validator in a validating header field, or when a 4856 server compares two validators. 4858 Strong validators are usable in any context. Weak validators are 4859 only usable in contexts that do not depend on exact equality of an 4860 entity. For example, either kind is usable for a conditional 4861 DESCRIBE of a full entity. However, only a strong validator is 4862 usable for a sub-range retrieval, since otherwise the client might 4863 end up with an internally inconsistent entity. 4865 Clients MAY issue DESCRIBE requests with either weak validators or 4866 strong validators. Clients MUST NOT use weak validators in other 4867 forms of requests. 4869 The only function that the RTSP protocol defines on validators is 4870 comparison. There are two validator comparison functions, depending 4871 on whether the comparison context allows the use of weak validators 4872 or not: 4874 o The strong comparison function: in order to be considered equal, 4875 both validators MUST be identical in every way, and both MUST NOT 4876 be weak. 4878 o The weak comparison function: in order to be considered equal, 4879 both validators MUST be identical in every way, but either or both 4880 of them MAY be tagged as "weak" without affecting the result. 4882 A message body tag is strong unless it is explicitly tagged as weak. 4884 A Last-Modified time, when used as a validator in a request, is 4885 implicitly weak unless it is possible to deduce that it is strong, 4886 using the following rules: 4888 o The validator is being compared by an origin server to the actual 4889 current validator for the entity and, 4891 o That origin server reliably knows that the associated entity did 4892 not change more than once during the second covered by the 4893 presented validator. 4895 OR 4897 o The validator is about to be used by a client in an If-Modified- 4898 Since, because the client has a cache entry for the associated 4899 entity, and 4901 o That cache entry includes a Date value, which gives the time when 4902 the origin server sent the original response, and 4904 o The presented Last-Modified time is at least 60 seconds before the 4905 Date value. 4907 OR 4909 o The validator is being compared by an intermediate cache to the 4910 validator stored in its cache entry for the entity, and 4912 o That cache entry includes a Date value, which gives the time when 4913 the origin server sent the original response, and 4915 o The presented Last-Modified time is at least 60 seconds before the 4916 Date value. 4918 This method relies on the fact that if two different responses were 4919 sent by the origin server during the same second, but both had the 4920 same Last-Modified time, then at least one of those responses would 4921 have a Date value equal to its Last-Modified time. The arbitrary 60- 4922 second limit guards against the possibility that the Date and Last- 4923 Modified values are generated from different clocks, or at somewhat 4924 different times during the preparation of the response. An 4925 implementation MAY use a value larger than 60 seconds, if it is 4926 believed that 60 seconds is too short. 4928 If a client wishes to perform a sub-range retrieval on a value for 4929 which it has only a Last-Modified time and no opaque validator, it 4930 MAY do this only if the Last-Modified time is strong in the sense 4931 described here. 4933 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates 4935 This document adopt a set of rules and recommendations for origin 4936 servers, clients, and caches regarding when various validator types 4937 ought to be used, and for what purposes. 4939 RTSP origin servers: 4941 o SHOULD send a message body tag validator unless it is not feasible 4942 to generate one. 4944 o MAY send a weak message body tag instead of a strong message body 4945 tag, if performance considerations support the use of weak message 4946 body tags, or if it is unfeasible to send a strong message body 4947 tag. 4949 o SHOULD send a Last-Modified value if it is feasible to send one, 4950 unless the risk of a breakdown in semantic transparency that could 4951 result from using this date in an If-Modified-Since header would 4952 lead to serious problems. 4954 In other words, the preferred behavior for an RTSP origin server is 4955 to send both a strong message body tag and a Last-Modified value. 4957 In order to be legal, a strong message body tag MUST change whenever 4958 the associated entity value changes in any way. A weak message body 4959 tag SHOULD change whenever the associated entity changes in a 4960 semantically significant way. 4962 Note: in order to provide semantically transparent caching, an 4963 origin server MUST avoid reusing a specific strong message body 4964 tag value for two different entities, or reusing a specific weak 4965 message body tag value for two semantically different entities. 4966 Cache entries might persist for arbitrarily long periods, 4967 regardless of expiration times, so it might be inappropriate to 4968 expect that a cache will never again attempt to validate an entry 4969 using a validator that it obtained at some point in the past. 4971 RTSP clients: 4973 o If a message body tag has been provided by the origin server, MUST 4974 use that message body tag in any cache-conditional request (using 4975 If-Match or If-None-Match). 4977 o If only a Last-Modified value has been provided by the origin 4978 server, SHOULD use that value in non-subrange cache-conditional 4979 requests (using If-Modified-Since). 4981 o If both a message body tag and a Last-Modified value have been 4982 provided by the origin server, SHOULD use both validators in 4983 cache-conditional requests. 4985 An RTSP origin server, upon receiving a conditional request that 4986 includes both a Last-Modified date (e.g., in an If-Modified-Since 4987 header) and one or more message body tags (e.g., in an If-Match, If- 4988 None-Match, or If-Range header field) as cache validators, MUST NOT 4989 return a response status of 304 (Not Modified) unless doing so is 4990 consistent with all of the conditional header fields in the request. 4992 Note: The general principle behind these rules is that RTSP 4993 servers and clients should transmit as much non-redundant 4994 information as is available in their responses and requests. RTSP 4995 systems receiving this information will make the most conservative 4996 assumptions about the validators they receive. 4998 16.1.5. Non-validating Conditionals 5000 The principle behind message body tags is that only the service 5001 author knows the semantics of a resource well enough to select an 5002 appropriate cache validation mechanism, and the specification of any 5003 validator comparison function more complex than octet-equality would 5004 open up a can of worms. Thus, comparisons of any other headers are 5005 never used for purposes of validating a cache entry. 5007 16.2. Invalidation After Updates or Deletions 5009 The effect of certain methods performed on a resource at the origin 5010 server might cause one or more existing cache entries to become non- 5011 transparently invalid. That is, although they might continue to be 5012 "fresh," they do not accurately reflect what the origin server would 5013 return for a new request on that resource. 5015 There is no way for the RTSP protocol to guarantee that all such 5016 cache entries are marked invalid. For example, the request that 5017 caused the change at the origin server might not have gone through 5018 the proxy where a cache entry is stored. However, several rules help 5019 reduce the likelihood of erroneous behavior. 5021 In this section, the phrase "invalidate an entity" means that the 5022 cache will either remove all instances of that entity from its 5023 storage, or will mark these as "invalid" and in need of a mandatory 5024 revalidation before they can be returned in response to a subsequent 5025 request. 5027 Some RTSP methods MUST cause a cache to invalidate an entity. This 5028 is either the entity referred to by the Request-URI, or by the 5029 Location or Content-Location headers (if present). These methods 5030 are: 5032 o DESCRIBE 5034 o SETUP 5036 In order to prevent denial of service attacks, an invalidation based 5037 on the URI in a Location or Content-Location header MUST only be 5038 performed if the host part is the same as in the Request-URI. 5040 A cache that passes through requests for methods it does not 5041 understand SHOULD invalidate any entities referred to by the Request- 5042 URI. 5044 17. Status Code Definitions 5046 Where applicable, HTTP status [H10] codes are reused. See Table 4 in 5047 Section 8.1 for a listing of which status codes may be returned by 5048 which requests. All error messages, 4xx and 5xx MAY return a body 5049 containing further information about the error. 5051 17.1. Informational 1xx 5053 17.1.1. 100 Continue 5055 The client SHOULD continue with its request. This interim response 5056 is used to inform the client that the initial part of the request has 5057 been received and has not yet been rejected by the server. The 5058 client SHOULD continue by sending the remainder of the request or, if 5059 the request has already been completed, ignore this response. The 5060 server MUST send a final response after the request has been 5061 completed. 5063 17.2. Success 2xx 5065 This class of status code indicates that the client's request was 5066 successfully received, understood, and accepted. 5068 17.2.1. 200 OK 5070 The request has succeeded. The information returned with the 5071 response is dependent on the method used in the request. 5073 17.3. Redirection 3xx 5075 The notation "3xx" indicates response codes from 300 to 399 inclusive 5076 which are meant for redirection. The response code 304 is excluded, 5077 as it is not used for redirection and instead the "3rr" notation is 5078 used. The 304 response code appears here, rather than a 2xx response 5079 code which would have been appropriate, this as 304 has been used 5080 also in RTSP 1.0 [RFC2326]. 5082 Within RTSP, redirection may be used for load balancing or 5083 redirecting stream requests to a server topologically closer to the 5084 client. Mechanisms to determine topological proximity are beyond the 5085 scope of this specification. 5087 A 3rr code MAY be used to respond to any request. The Location 5088 header MUST be included in any 3rr response. It is RECOMMENDED that 5089 they are used if necessary before a session is established, i.e., in 5090 response to DESCRIBE or SETUP. However, in cases where a server is 5091 not able to send a REDIRECT request to the client, the server MAY 5092 need to resort to using 3rr responses to inform a client with an 5093 established session about the need for redirecting the session. If a 5094 3rr response is received for a request in relation to an established 5095 session, the client SHOULD send a TEARDOWN request for the session, 5096 and MAY reestablish the session using the resource indicated by the 5097 Location. 5099 If the Location header is used in a response it MUST contain an 5100 absolute URI pointing out the media resource the client is redirected 5101 to, the URI MUST NOT only contain the host name. 5103 In the event that an unknown 3rr status code is received, the agent 5104 SHOULD behave as if a 302 response code had been received 5105 (Section 17.3.3). 5107 17.3.1. 300 5109 This response code is not used in RTSP 2.0. 5111 17.3.2. 301 Moved Permanently 5113 The requested resource is moved permanently and resides now at the 5114 URI given by the Location header. The user client SHOULD redirect 5115 automatically to the given URI. This response MUST NOT contain a 5116 message-body. The Location header MUST be included in the response. 5118 17.3.3. 302 Found 5120 The requested resource resides temporarily at the URI given by the 5121 Location header. This response is intended to be used for many types 5122 of temporary redirects; e.g., load balancing. It is RECOMMENDED that 5123 the server set the reason phrase to something more meaningful than 5124 "Found" in these cases. The user client SHOULD redirect 5125 automatically to the given URI. This response MUST NOT contain a 5126 message-body. 5128 This example shows a client being redirected to a different server: 5130 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 5131 CSeq: 2 5132 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 5133 Accept-Ranges: npt, smpte, clock 5134 User-Agent: PhonyClient/1.2 5136 S->C: RTSP/2.0 302 Try Other Server 5137 CSeq: 2 5138 Location: rtsp://s2.example.com:8001/fizzle/foo 5140 17.3.4. 303 See Other 5142 This status code MUST NOT be used in RTSP 2.0. However, it was 5143 allowed in RTSP 1.0 [RFC2326]. 5145 17.3.5. 304 Not Modified 5147 If the client has performed a conditional DESCRIBE or SETUP (see 5148 Section 18.25) and the requested resource has not been modified, the 5149 server SHOULD send a 304 response. This response MUST NOT contain a 5150 message-body. 5152 The response MUST include the following header fields: 5154 o Date 5155 o MTag and/or Content-Location, if the header(s) would have been 5156 sent in a 200 response to the same request. 5158 o Expires and Cache-Control if the field-value might differ from 5159 that sent in any previous response for the same variant. 5161 This response is independent for the DESCRIBE and SETUP requests. 5162 That is, a 304 response to DESCRIBE does NOT imply that the resource 5163 content is unchanged (only the session description) and a 304 5164 response to SETUP does NOT imply that the resource description is 5165 unchanged. The MTag and If-Match headers may be used to link the 5166 DESCRIBE and SETUP in this manner. 5168 17.3.6. 305 Use Proxy 5170 The requested resource MUST be accessed through the proxy given by 5171 the Location field. The Location field gives the URI of the proxy. 5172 The recipient is expected to repeat this single request via the 5173 proxy. 305 responses MUST only be generated by origin servers. 5175 17.4. Client Error 4xx 5177 17.4.1. 400 Bad Request 5179 The request could not be understood by the server due to malformed 5180 syntax. The client SHOULD NOT repeat the request without 5181 modifications. If the request does not have a CSeq header, the 5182 server MUST NOT include a CSeq in the response. 5184 17.4.2. 401 Unauthorized 5186 The request requires user authentication. The response MUST include 5187 a WWW-Authenticate header (Section 18.58) field containing a 5188 challenge applicable to the requested resource. The client MAY 5189 repeat the request with a suitable Authorization header field. If 5190 the request already included Authorization credentials, then the 401 5191 response indicates that authorization has been refused for those 5192 credentials. If the 401 response contains the same challenge as the 5193 prior response, and the user agent has already attempted 5194 authentication at least once, then the user SHOULD be presented the 5195 message body that was given in the response, since that message body 5196 might include relevant diagnostic information. HTTP access 5197 authentication is explained in [RFC2617]. 5199 17.4.3. 402 Payment Required 5201 This code is reserved for future use. 5203 17.4.4. 403 Forbidden 5205 The server understood the request, but is refusing to fulfill it. 5206 Authorization will not help and the request SHOULD NOT be repeated. 5207 If the server wishes to make public why the request has not been 5208 fulfilled, it SHOULD describe the reason for the refusal in the 5209 message body. If the server does not wish to make this information 5210 available to the client, the status code 404 (Not Found) can be used 5211 instead. 5213 17.4.5. 404 Not Found 5215 The server has not found anything matching the Request-URI. No 5216 indication is given of whether the condition is temporary or 5217 permanent. The 410 (Gone) status code SHOULD be used if the server 5218 knows, through some internally configurable mechanism, that an old 5219 resource is permanently unavailable and has no forwarding address. 5220 This status code is commonly used when the server does not wish to 5221 reveal exactly why the request has been refused, or when no other 5222 response is applicable. 5224 17.4.6. 405 Method Not Allowed 5226 The method specified in the request is not allowed for the resource 5227 identified by the Request-URI. The response MUST include an Allow 5228 header containing a list of valid methods for the requested resource. 5229 This status code is also to be used if a request attempts to use a 5230 method not indicated during SETUP. 5232 17.4.7. 406 Not Acceptable 5234 The resource identified by the request is only capable of generating 5235 response message bodies which have content characteristics not 5236 acceptable according to the Accept headers sent in the request. 5238 The response SHOULD include a message body containing a list of 5239 available message body characteristics and location(s) from which the 5240 user or user agent can choose the one most appropriate. The message 5241 body format is specified by the media type given in the Content-Type 5242 header field. Depending upon the format and the capabilities of the 5243 user agent, selection of the most appropriate choice MAY be performed 5244 automatically. However, this specification does not define any 5245 standard for such automatic selection. 5247 If the response could be unacceptable, a user agent SHOULD 5248 temporarily stop receipt of more data and query the user for a 5249 decision on further actions. 5251 17.4.8. 407 Proxy Authentication Required 5253 This code is similar to 401 (Unauthorized) (Section 17.4.2), but 5254 indicates that the client must first authenticate itself with the 5255 proxy. The proxy MUST return a Proxy-Authenticate header field 5256 (Section 18.34) containing a challenge applicable to the proxy for 5257 the requested resource. 5259 17.4.9. 408 Request Timeout 5261 The client did not produce a request within the time that the server 5262 was prepared to wait. The client MAY repeat the request without 5263 modifications at any later time. 5265 17.4.10. 410 Gone 5267 The requested resource is no longer available at the server and the 5268 forwarding address is not known. This condition is expected to be 5269 considered permanent. If the server does not know, or has no 5270 facility to determine, whether or not the condition is permanent, the 5271 status code 404 (Not Found) SHOULD be used instead. This response is 5272 cacheable unless indicated otherwise. 5274 The 410 response is primarily intended to assist the task of 5275 repository maintenance by notifying the recipient that the resource 5276 is intentionally unavailable and that the server owners desire that 5277 remote links to that resource be removed. Such an event is common 5278 for limited-time, promotional services and for resources belonging to 5279 individuals no longer working at the server's site. It is not 5280 necessary to mark all permanently unavailable resources as "gone" or 5281 to keep the mark for any length of time -- that is left to the 5282 discretion of the owner of the server. 5284 17.4.11. 411 Length Required 5286 This error code is not defined for RTSP. This as the use of Content- 5287 Length (Section 18.17) is always required when message bodies are 5288 included in RTSP messages. 5290 17.4.12. 412 Precondition Failed 5292 The precondition given in one or more of the 'if-' request-header 5293 fields evaluated to false when it was tested on the server. See 5294 these sections for the 'if-' headers: If-Match Section 18.24, If- 5295 Modified-Since Section 18.25, and If-None-Match Section 18.26. This 5296 response code allows the client to place preconditions on the current 5297 resource meta information (header field data) and thus prevent the 5298 requested method from being applied to a resource other than the one 5299 intended. 5301 17.4.13. 413 Request Message Body Too Large 5303 The server is refusing to process a request because the request 5304 message body is larger than the server is willing or able to process. 5305 The server MAY close the connection to prevent the client from 5306 continuing the request. 5308 If the condition is temporary, the server SHOULD include a Retry- 5309 After header field to indicate that it is temporary and after what 5310 time the client MAY try again. 5312 17.4.14. 414 Request-URI Too Long 5314 The server is refusing to service the request because the Request-URI 5315 is longer than the server is willing to interpret. This rare 5316 condition is only likely to occur when a client has used a request 5317 with long query information, when the client has descended into a URI 5318 "black hole" of redirection (e.g., a redirected URI prefix that 5319 points to a suffix of itself), or when the server is under attack by 5320 a client attempting to exploit security holes present in some servers 5321 using fixed-length buffers for reading or manipulating the Request- 5322 URI. 5324 17.4.15. 415 Unsupported Media Type 5326 The server is refusing to service the request because the message 5327 body of the request is in a format not supported by the requested 5328 resource for the requested method. 5330 17.4.16. 451 Parameter Not Understood 5332 The recipient of the request does not support one or more parameters 5333 contained in the request. When returning this error message the 5334 sender SHOULD return a message body containing the offending 5335 parameter(s). 5337 17.4.17. 452 reserved 5339 This status code MUST NOT be used in RTSP 2.0. However, it was 5340 allowed in RTSP 1.0 [RFC2326]. 5342 17.4.18. 453 Not Enough Bandwidth 5344 The request was refused because there was insufficient bandwidth. 5345 This may, for example, be the result of a resource reservation 5346 failure. 5348 17.4.19. 454 Session Not Found 5350 The RTSP session identifier in the Session header is missing, 5351 invalid, or has timed out. 5353 17.4.20. 455 Method Not Valid in This State 5355 The client or server cannot process this request in its current 5356 state. The response MUST contain an Allow header to make error 5357 recovery possible. 5359 17.4.21. 456 Header Field Not Valid for Resource 5361 The server could not act on a required request-header. For example, 5362 if PLAY contains the Range header field but the stream does not allow 5363 seeking. This error message may also be used for specifying when the 5364 time format in Range is impossible for the resource. In that case 5365 the Accept-Ranges header MUST be returned to inform the client of 5366 which format(s) that are allowed. 5368 17.4.22. 457 Invalid Range 5370 The Range value given is out of bounds, e.g., beyond the end of the 5371 presentation. 5373 17.4.23. 458 Parameter Is Read-Only 5375 The parameter to be set by SET_PARAMETER can be read but not 5376 modified. When returning this error message the sender SHOULD return 5377 a message body containing the offending parameter(s). 5379 17.4.24. 459 Aggregate Operation Not Allowed 5381 The requested method may not be applied on the URI in question since 5382 it is an aggregate (presentation) URI. The method may be applied on 5383 a media URI. 5385 17.4.25. 460 Only Aggregate Operation Allowed 5387 The requested method may not be applied on the URI in question since 5388 it is not an aggregate control (presentation) URI. The method may be 5389 applied on the aggregate control URI. 5391 17.4.26. 461 Unsupported Transport 5393 The Transport field did not contain a supported transport 5394 specification. 5396 17.4.27. 462 Destination Unreachable 5398 The data transmission channel could not be established because the 5399 client address could not be reached. This error will most likely be 5400 the result of a client attempt to place an invalid dest_addr 5401 parameter in the Transport field. 5403 17.4.28. 463 Destination Prohibited 5405 The data transmission channel was not established because the server 5406 prohibited access to the client address. This error is most likely 5407 the result of a client attempt to redirect media traffic to another 5408 destination with a dest_addr parameter in the Transport header. 5410 17.4.29. 464 Data Transport Not Ready Yet 5412 The data transmission channel to the media destination is not yet 5413 ready for carrying data. However, the responding agent still expects 5414 that the data transmission channel will be established at some point 5415 in time. Note, however, that this may result in a permanent failure 5416 like 462 "Destination Unreachable". 5418 An example when this error may occur is in the case a client sends a 5419 PLAY request to a server prior to ensuring that the TCP connections 5420 negotiated for carrying media data was successfully established (In 5421 violation of this specification). The server would use this error 5422 code to indicate that the requested action could not be performed due 5423 to the failure of completing the connection establishment. 5425 17.4.30. 465 Notification Reason Unknown 5427 This indicates that the client has received a PLAY_NOTIFY 5428 (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to 5429 the client. 5431 17.4.31. 466 Key Management Error 5433 This indicates that there has been an error in a Key Management 5434 function used in conjunction with a request. For example usage of 5435 MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this 5436 error. 5438 17.4.32. 470 Connection Authorization Required 5440 The secured connection attempt needs user or client authorization 5441 before proceeding. The next hop's certificate is included in this 5442 response in the Accept-Credentials header. 5444 17.4.33. 471 Connection Credentials not accepted 5446 When performing a secure connection over multiple connections, an 5447 intermediary has refused to connect to the next hop and carry out the 5448 request due to unacceptable credentials for the used policy. 5450 17.4.34. 472 Failure to establish secure connection 5452 A proxy fails to establish a secure connection to the next hop RTSP 5453 agent. This is primarily caused by a fatal failure at the TLS 5454 handshake, for example due to server not accepting any cipher suites. 5456 17.5. Server Error 5xx 5458 Response status codes beginning with the digit "5" indicate cases in 5459 which the server is aware that it has erred or is incapable of 5460 performing the request The server SHOULD include a message body 5461 containing an explanation of the error situation, and whether it is a 5462 temporary or permanent condition. User agents SHOULD display any 5463 included message body to the user. These response codes are 5464 applicable to any request method. 5466 17.5.1. 500 Internal Server Error 5468 The server encountered an unexpected condition which prevented it 5469 from fulfilling the request. 5471 17.5.2. 501 Not Implemented 5473 The server does not support the functionality required to fulfill the 5474 request. This is the appropriate response when the server does not 5475 recognize the request method and is not capable of supporting it for 5476 any resource. 5478 17.5.3. 502 Bad Gateway 5480 The server, while acting as a gateway or proxy, received an invalid 5481 response from the upstream server it accessed in attempting to 5482 fulfill the request. 5484 17.5.4. 503 Service Unavailable 5486 The server is currently unable to handle the request due to a 5487 temporary overloading or maintenance of the server. The implication 5488 is that this is a temporary condition which will be alleviated after 5489 some delay. If known, the length of the delay MAY be indicated in a 5490 Retry-After header. If no Retry-After is given, the client SHOULD 5491 handle the response as it would for a 500 response. The client MUST 5492 honor the length, if given in the Retry-After header. 5494 Note: The existence of the 503 status code does not imply that 5495 a server must use it when becoming overloaded. Some servers 5496 may wish to simply refuse the connection. 5498 The response scope is dependent on the Request. If the request was 5499 in relation to an existing RTSP session, the scope of the overload 5500 response is to this individual RTSP session. If the request was non- 5501 session specific or intended to form a RTSP session it applies to the 5502 RTSP server identified by the host name in the request URI. 5504 17.5.5. 504 Gateway Timeout 5506 The server, while acting as a proxy, did not receive a timely 5507 response from the upstream server specified by the URI or some other 5508 auxiliary server (e.g., DNS) it needed to access in attempting to 5509 complete the request. 5511 17.5.6. 505 RTSP Version Not Supported 5513 The server does not support, or refuses to support, the RTSP protocol 5514 version that was used in the request message. The server is 5515 indicating that it is unable or unwilling to complete the request 5516 using the same major version as the client other than with this error 5517 message. The response SHOULD contain a message body describing why 5518 that version is not supported and what other protocols are supported 5519 by that server. 5521 17.5.7. 551 Option not supported 5523 A feature-tag given in the Require or the Proxy-Require fields was 5524 not supported. The Unsupported header MUST be returned stating the 5525 feature for which there is no support. 5527 17.5.8. 553 Proxy Unavailable 5529 The proxy is currently unable to handle the request due to a 5530 temporary overloading or maintenance of the proxy. The implication 5531 is that this is a temporary condition which will be alleviated after 5532 some delay. If known, the length of the delay MAY be indicated in a 5533 Retry-After header. If no Retry-After is given, the client SHOULD 5534 handle the response as it would for a 500 response. The client MUST 5535 honor the length, if given in the Retry-After header. 5537 Note: The existence of the 553 status code does not imply that 5538 a proxy must use it when becoming overloaded. Some proxies may 5539 wish to simply refuse the connection. 5541 The response scope is dependent on the Request. If the request was 5542 in relation to an existing RTSP session, the scope of the overload 5543 response is to this individual RTSP session. If the request was non- 5544 session specific or intended to form a RTSP session it applies to all 5545 such requests to this proxy. 5547 18. Header Field Definitions 5549 +---------------+----------------+--------+---------+------+ 5550 | method | direction | object | acronym | Body | 5551 +---------------+----------------+--------+---------+------+ 5552 | DESCRIBE | C -> S | P,S | DES | r | 5553 | | | | | | 5554 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 5555 | | | | | | 5556 | OPTIONS | C -> S, S -> C | P,S | OPT | | 5557 | | | | | | 5558 | PAUSE | C -> S | P,S | PSE | | 5559 | | | | | | 5560 | PLAY | C -> S | P,S | PLY | | 5561 | | | | | | 5562 | PLAY_NOTIFY | S -> C | P,S | PNY | R | 5563 | | | | | | 5564 | REDIRECT | S -> C | P,S | RDR | | 5565 | | | | | | 5566 | SETUP | C -> S | S | STP | | 5567 | | | | | | 5568 | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | 5569 | | | | | | 5570 | TEARDOWN | C -> S | P,S | TRD | | 5571 | | | | | | 5572 | | S -> C | P | TRD | | 5573 +---------------+----------------+--------+---------+------+ 5575 Table 8: Overview of RTSP methods, their direction, and what objects 5576 (P: presentation, S: stream) they operate on. Body notes if a method 5577 is allowed to carry body and in which direction, R = Request, 5578 r=response. Note: All error messages for statuses 4xx and 5xx are 5579 allowed to carry a body 5581 The general syntax for header fields is covered in Section 5.2. This 5582 section lists the full set of header fields along with notes on 5583 meaning, and usage. The syntax definition for header fields are 5584 present in Section 20.2.3. Throughout this section, [HX.Y] is used 5585 to reference Section X.Y of the HTTP/1.1 specification RFC 2616 5586 [RFC2616]. Examples of each header field are given. 5588 Information about header fields in relation to methods and proxy 5589 processing is summarized in Table 9, Table 10, Table 11, and 5590 Table 12. 5592 The "where" column describes the request and response types in which 5593 the header field can be used. Values in this column are: 5595 R: header field may only appear in requests; 5597 r: header field may only appear in responses; 5599 2xx, 4xx, etc.: A numerical value or range indicates response codes 5600 with which the header field can be used; 5602 c: header field is copied from the request to the response. 5604 G: header field is a general-header and may be present in both 5605 requests and responses. 5607 Note: General headers does not always use the "G" value in the where 5608 column. This is due to differencies when the header may be applied 5609 in requests compared to responses. When such differencies exist they 5610 are expressed using two differet rows, one with where being "R" and 5611 one with it being "r". 5613 The "proxy" column describes the operations a proxy may perform on a 5614 header field. An empty proxy column indicates that the proxy MUST 5615 NOT do any changes to that header, all allowed operations are 5616 explicitly stated: 5618 a: A proxy can add or concatenate the header field if not present. 5620 m: A proxy can modify an existing header field value. 5622 d: A proxy can delete a header field value. 5624 r: A proxy needs to be able to read the header field, and thus 5625 this header field cannot be encrypted. 5627 The rest of the columns relate to the presence of a header field in a 5628 method. The method names when abbreviated, are according to Table 8: 5630 c: Conditional; requirements on the header field depend on the 5631 context of the message. 5633 m: The header field is mandatory. 5635 m*: The header field SHOULD be sent, but clients/servers need to be 5636 prepared to receive messages without that header field. 5638 o: The header field is optional. 5640 *: The header field MUST be present if the message body is not 5641 empty. See Section 18.17, Section 18.19 and Section 5.3 for 5642 details. 5644 -: The header field is not applicable. 5646 "Optional" means that a Client/Server MAY include the header field in 5647 a request or response. The Client/Server behavior when receiving 5648 such headers varies, for some it may ignore the header field, in 5649 other cases it is a request to process the header. This is regulated 5650 by the method and header descriptions. Example of headers that 5651 require processing are the Require and Proxy-Require header fields 5652 discussed in Section 18.43 and Section 18.37. A "mandatory" header 5653 field MUST be present in a request, and MUST be understood by the 5654 Client/Server receiving the request. A mandatory response-header 5655 field MUST be present in the response, and the header field MUST be 5656 understood by the Client/Server processing the response. "Not 5657 applicable" means that the header field MUST NOT be present in a 5658 request. If one is placed in a request by mistake, it MUST be 5659 ignored by the Client/Server receiving the request. Similarly, a 5660 header field labeled "not applicable" for a response means that the 5661 Client/Server MUST NOT place the header field in the response, and 5662 the Client/Server MUST ignore the header field in the response. 5664 An RTSP agent MUST ignore extension headers that are not understood. 5666 The From and Location header fields contain a URI. If the URI 5667 contains a comma, or semicolon, the URI MUST be enclosed in double 5668 quotes ("). Any URI parameters are contained within these quotes. 5669 If the URI is not enclosed in double quote, any semicolon-delimited 5670 parameters are header-parameters, not URI parameters. 5672 +-------------------+------+------+----+----+-----+-----+-----+-----+ 5673 | Header | Wher | Prox | DE | OP | STP | PLY | PSE | TRD | 5674 | | e | y | S | T | | | | | 5675 +-------------------+------+------+----+----+-----+-----+-----+-----+ 5676 | Accept | R | | o | - | - | - | - | - | 5677 | | | | | | | | | | 5678 | Accept- | R | rm | o | o | o | o | o | o | 5679 | Credentials | | | | | | | | | 5680 | | | | | | | | | | 5681 | Accept-Encoding | R | r | o | - | - | - | - | - | 5682 | | | | | | | | | | 5683 | Accept-Language | R | r | o | - | - | - | - | - | 5684 | | | | | | | | | | 5685 | Accept-Ranges | G | r | - | - | m | - | - | - | 5686 | | | | | | | | | | 5687 | Accept-Ranges | 456 | r | - | - | - | m | - | - | 5688 | | | | | | | | | | 5689 | Allow | r | am | c | c | c | - | - | - | 5690 | | | | | | | | | | 5691 | Allow | 405 | am | m | m | m | m | m | m | 5692 | | | | | | | | | | 5693 | Authentication- | r | | o | o | o | o | o | o/- | 5694 | Info | | | | | | | | | 5695 | | | | | | | | | | 5696 | Authorization | R | | o | o | o | o | o | o | 5697 | | | | | | | | | | 5698 | Bandwidth | R | | o | o | o | o | - | - | 5699 | | | | | | | | | | 5700 | Blocksize | R | | o | - | o | o | - | - | 5701 | | | | | | | | | | 5702 | Cache-Control | G | r | o | - | o | - | - | - | 5703 | | | | | | | | | | 5704 | Connection | G | ad | o | o | o | o | o | o | 5705 | | | | | | | | | | 5706 | Connection- | 470, | ar | o | o | o | o | o | o | 5707 | Credentials | 407 | | | | | | | | 5708 | | | | | | | | | | 5709 | Content-Base | r | | o | - | - | - | - | - | 5710 | | | | | | | | | | 5711 | Content-Base | 4xx, | | o | o | o | o | o | o | 5712 | | 5xx | | | | | | | | 5713 | | | | | | | | | | 5714 | Content-Encoding | R | r | - | - | - | - | - | - | 5715 | | | | | | | | | | 5716 | Content-Encoding | r | r | o | - | - | - | - | - | 5717 | | | | | | | | | | 5718 | Content-Encoding | 4xx, | r | o | o | o | o | o | o | 5719 | | 5xx | | | | | | | | 5720 | | | | | | | | | | 5721 | Content-Language | R | r | - | - | - | - | - | - | 5722 | | | | | | | | | | 5723 | Content-Language | r | r | o | - | - | - | - | - | 5724 | | | | | | | | | | 5725 | Content-Language | 4xx, | r | o | o | o | o | o | o | 5726 | | 5xx | | | | | | | | 5727 | | | | | | | | | | 5728 | Content-Length | r | r | * | - | - | - | - | - | 5729 | | | | | | | | | | 5730 | Content-Length | 4xx, | r | * | * | * | * | * | * | 5731 | | 5xx | | | | | | | | 5732 | | | | | | | | | | 5733 | Content-Location | r | r | o | - | - | - | - | - | 5734 | | | | | | | | | | 5735 | Content-Location | 4xx, | r | o | o | o | o | o | o | 5736 | | 5xx | | | | | | | | 5737 | | | | | | | | | | 5738 | Content-Type | r | r | * | - | - | - | - | - | 5739 | | | | | | | | | | 5740 | Content-Type | 4xx, | ar | * | * | * | * | * | * | 5741 | | 5xx | | | | | | | | 5742 | | | | | | | | | | 5743 | CSeq | Gc | rm | m | m | m | m | m | m | 5744 | | | | | | | | | | 5745 | Date | G | am | o/ | o/ | o/* | o/* | o/* | o/* | 5746 | | | | * | * | | | | | 5747 | | | | | | | | | | 5748 | Expires | r | r | o | - | o | - | - | - | 5749 | | | | | | | | | | 5750 | From | R | r | o | o | o | o | o | o | 5751 | | | | | | | | | | 5752 | If-Match | R | r | - | - | o | - | - | - | 5753 | | | | | | | | | | 5754 | If-Modified-Since | R | r | o | - | o | - | - | - | 5755 | | | | | | | | | | 5756 | If-None-Match | R | r | o | - | o | - | - | - | 5757 | | | | | | | | | | 5758 | Last-Modified | r | r | o | - | o | - | - | - | 5759 | | | | | | | | | | 5760 | Location | 3rr | | o | o | o | o | o | o | 5761 +-------------------+------+------+----+----+-----+-----+-----+-----+ 5763 Table 9: Overview of RTSP header fields (A-L) related to methods 5764 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5766 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5767 | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | 5768 | | | xy | S | T | P | | | | 5769 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5770 | Media- | G | | - | - | m | m | m | - | 5771 | Properties | | | | | | | | | 5772 | | | | | | | | | | 5773 | Media-Range | G | | - | - | m | m | m | - | 5774 | | | | | | | | | | 5775 | MTag | r | r | o | - | o | - | - | - | 5776 | | | | | | | | | | 5777 | Pipelined- | G | amd | - | o | o | o | o | o | 5778 | Requests | | r | | | | | | | 5779 | | | | | | | | | | 5780 | Proxy- | 407 | amr | m | m | m | m | m | m | 5781 | Authenticate | | | | | | | | | 5782 | | | | | | | | | | 5783 | Proxy- | r | amd | o | o | o | o | o | o/- | 5784 | Authentication- | | r | | | | | | | 5785 | Info | | | | | | | | | 5786 | | | | | | | | | | 5787 | Proxy- | R | rd | o | o | o | o | o | o | 5788 | Authorization | | | | | | | | | 5789 | | | | | | | | | | 5790 | Proxy- Require | R | ar | o | o | o | o | o | o | 5791 | | | | | | | | | | 5792 | Proxy- Require | r | r | c | c | c | c | c | c | 5793 | | | | | | | | | | 5794 | Proxy- Supported | R | amr | c | c | c | c | c | c | 5795 | | | | | | | | | | 5796 | Proxy- Supported | r | | c | c | c | c | c | c | 5797 | | | | | | | | | | 5798 | Public | r | amr | - | m | - | - | - | - | 5799 | | | | | | | | | | 5800 | Public | 501 | amr | m | m | m | m | m | m | 5801 | | | | | | | | | | 5802 | Range | R | | - | - | - | o | - | - | 5803 | | | | | | | | | | 5804 | Range | r | | - | - | c | m | m | - | 5805 | | | | | | | | | | 5806 | Referrer | R | | o | o | o | o | o | o | 5807 | | | | | | | | | | 5808 | Request- Status | R | | - | - | - | - | - | - | 5809 | | | | | | | | | | 5810 | Require | R | | o | o | o | o | o | o | 5811 | | | | | | | | | | 5812 | Retry-After | 3rr,503 | | o | o | o | o | o | - | 5813 | | ,553 | | | | | | | | 5814 | | | | | | | | | | 5815 | Retry-After | 413 | | o | - | - | - | - | - | 5816 | | | | | | | | | | 5817 | RTP-Info | r | | - | - | c | c | - | - | 5818 | | | | | | | | | | 5819 | Scale | R | r | - | - | - | o | - | - | 5820 | | | | | | | | | | 5821 | Scale | r | amr | - | - | - | c | - | - | 5822 | | | | | | | | | | 5823 | Seek-Style | R | | - | - | - | o | - | - | 5824 | | | | | | | | | | 5825 | Seek-Style | r | | - | - | - | m | - | - | 5826 | | | | | | | | | | 5827 | Server | R | r | - | o | - | - | - | o | 5828 | | | | | | | | | | 5829 | Server | r | r | o | o | o | o | o | o | 5830 | | | | | | | | | | 5831 | Session | R | r | - | o | o | m | m | m | 5832 | | | | | | | | | | 5833 | Session | r | r | - | c | m | m | m | o | 5834 | | | | | | | | | | 5835 | Speed | R | adm | - | - | - | o | - | - | 5836 | | | r | | | | | | | 5837 | | | | | | | | | | 5838 | Speed | r | adm | - | - | - | c | - | - | 5839 | | | r | | | | | | | 5840 | | | | | | | | | | 5841 | Supported | R | amr | o | o | o | o | o | o | 5842 | | | | | | | | | | 5843 | Supported | r | amr | c | c | c | c | c | c | 5844 | | | | | | | | | | 5845 | Terminate-Reason | R | r | - | - | - | - | - | - | 5846 | | | | | | | | | | 5847 | Timestamp | R | adm | o | o | o | o | o | o | 5848 | | | r | | | | | | | 5849 | | | | | | | | | | 5850 | Timestamp | c | adm | m | m | m | m | m | m | 5851 | | | r | | | | | | | 5852 | | | | | | | | | | 5853 | Transport | G | mr | - | - | m | - | - | - | 5854 | | | | | | | | | | 5855 | Unsupported | r | | c | c | c | c | c | c | 5856 | | | | | | | | | | 5857 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 5858 | | | | | | | | | | 5859 | Via | R | amr | o | o | o | o | o | o | 5860 | | | | | | | | | | 5861 | Via | c | dr | m | m | m | m | m | m | 5862 | | | | | | | | | | 5863 | WWW- | 401 | | m | m | m | m | m | m | 5864 | Authenticate | | | | | | | | | 5865 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5867 Table 10: Overview of RTSP header fields (M-W) related to methods 5868 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5870 +---------------------------+-------+-------+-----+-----+-----+-----+ 5871 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5872 +---------------------------+-------+-------+-----+-----+-----+-----+ 5873 | Accept | R | arm | o | o | - | - | 5874 | | | | | | | | 5875 | Accept-Credentials | R | rm | o | o | o | - | 5876 | | | | | | | | 5877 | Accept-Encoding | R | r | o | o | o | - | 5878 | | | | | | | | 5879 | Accept-Language | R | r | o | o | o | - | 5880 | | | | | | | | 5881 | Accept-Ranges | G | rm | o | - | - | - | 5882 | | | | | | | | 5883 | Allow | 405 | amr | m | m | m | - | 5884 | | | | | | | | 5885 | Authentication-Info | r | | o/- | o/- | - | - | 5886 | | | | | | | | 5887 | Authorization | R | | o | o | o | - | 5888 | | | | | | | | 5889 | Bandwidth | R | | - | o | - | - | 5890 | | | | | | | | 5891 | Blocksize | R | | - | o | - | - | 5892 | | | | | | | | 5893 | Cache-Control | G | r | o | o | - | - | 5894 | | | | | | | | 5895 | Connection | G | | o | o | o | o | 5896 | | | | | | | | 5897 | Connection-Credentials | 470, | ar | o | o | o | - | 5898 | | 407 | | | | | | 5899 | | | | | | | | 5900 | Content-Base | R | | o | o | - | - | 5901 | | | | | | | | 5902 | Content-Base | r | | o | o | - | - | 5903 | | | | | | | | 5904 | Content-Base | 4xx, | | o | o | o | o | 5905 | | 5xx | | | | | | 5906 | | | | | | | | 5907 | Content-Encoding | R | r | o | o | - | - | 5908 | | | | | | | | 5909 | Content-Encoding | r | r | o | o | - | - | 5910 | | | | | | | | 5911 | Content-Encoding | 4xx, | r | o | o | o | o | 5912 | | 5xx | | | | | | 5913 | | | | | | | | 5914 | Content-Language | R | r | o | o | - | - | 5915 | | | | | | | | 5916 | Content-Language | r | r | o | o | - | - | 5917 | | | | | | | | 5918 | Content-Language | 4xx, | r | o | o | o | o | 5919 | | 5xx | | | | | | 5920 | | | | | | | | 5921 | Content-Length | R | r | * | * | - | - | 5922 | | | | | | | | 5923 | Content-Length | r | r | * | * | - | - | 5924 | | | | | | | | 5925 | Content-Length | 4xx, | r | * | * | * | * | 5926 | | 5xx | | | | | | 5927 | | | | | | | | 5928 | Content-Location | R | | o | o | - | - | 5929 | | | | | | | | 5930 | Content-Location | r | | o | o | - | - | 5931 | | | | | | | | 5932 | Content-Location | 4xx, | | o | o | o | o | 5933 | | 5xx | | | | | | 5934 | | | | | | | | 5935 | Content-Type | R | | * | * | - | - | 5936 | | | | | | | | 5937 | Content-Type | r | | * | * | - | - | 5938 | | | | | | | | 5939 | Content-Type | 4xx, | | * | * | * | * | 5940 | | 5xx | | | | | | 5941 | | | | | | | | 5942 | CSeq | R,c | mr | m | m | m | m | 5943 | | | | | | | | 5944 | Date | R | a | o | o | m | o | 5945 | | | | | | | | 5946 | Date | r | am | o | o | o | o | 5947 | | | | | | | | 5948 | Expires | r | r | - | - | - | - | 5949 | | | | | | | | 5950 | From | R | r | o | o | o | - | 5951 | | | | | | | | 5952 | If-Match | R | r | - | - | - | - | 5953 | | | | | | | | 5954 | If-Modified-Since | R | am | o | - | - | - | 5955 | | | | | | | | 5956 | If-None-Match | R | am | o | - | - | - | 5957 | | | | | | | | 5958 | Last-Modified | R | r | - | - | - | - | 5959 | | | | | | | | 5960 | Last-Modified | r | r | o | - | - | - | 5961 | | | | | | | | 5962 | Location | 3rr | | o | o | o | - | 5963 | | | | | | | | 5964 | Location | R | | - | - | m | - | 5965 | | | | | | | | 5966 | Media-Properties | R | amr | o | - | - | c | 5967 | | | | | | | | 5968 | Media-Properties | r | mr | c | - | - | - | 5969 | | | | | | | | 5970 | Media-Range | R | | o | - | - | c | 5971 | | | | | | | | 5972 | Media-Range | r | | c | - | - | - | 5973 | | | | | | | | 5974 | MTag | r | r | o | - | - | - | 5975 | | | | | | | | 5976 | Notify-Reason | R | | - | - | - | m | 5977 | | | | | | | | 5978 | Pipelined-Requests | R | amdr | o | o | - | - | 5979 | | | | | | | | 5980 | Proxy-Authenticate | 407 | amdr | m | m | m | - | 5981 | | | | | | | | 5982 | Proxy-Authentication-Info | r | amdr | o/- | o/- | - | - | 5983 | | | | | | | | 5984 | Proxy-Authorization | R | amdr | o | o | o | - | 5985 | | | | | | | | 5986 | Proxy-Require | R | ar | o | o | o | - | 5987 | | | | | | | | 5988 | Proxy-Supported | R | amr | c | c | c | - | 5989 | | | | | | | | 5990 | Proxy-Supported | r | | c | c | c | - | 5991 | | | | | | | | 5992 | Public | 501 | admr | m | m | m | - | 5993 +---------------------------+-------+-------+-----+-----+-----+-----+ 5995 Table 11: Overview of RTSP header fields (A-P) related to methods 5996 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5998 +------------------+---------+-------+-----+-----+-----+-----+ 5999 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 6000 +------------------+---------+-------+-----+-----+-----+-----+ 6001 | Range | R | | o | - | o | m | 6002 | | | | | | | | 6003 | Referrer | R | | o | o | o | - | 6004 | | | | | | | | 6005 | Request-Status | R | | - | - | - | c | 6006 | | | | | | | | 6007 | Require | R | r | o | o | o | - | 6008 | | | | | | | | 6009 | Retry-After | 3rr,503 | | o | o | - | - | 6010 | | | | | | | | 6011 | Retry-After | 413 | | o | o | - | - | 6012 | | | | | | | | 6013 | RTP-Info | R | r | o | - | - | C | 6014 | | | | | | | | 6015 | RTP-Info | r | r | c | - | - | - | 6016 | | | | | | | | 6017 | Scale | G | | - | - | - | c | 6018 | | | | | | | | 6019 | Seek-Style | G | | - | - | - | - | 6020 | | | | | | | | 6021 | Server | R | r | o | o | o | o | 6022 | | | | | | | | 6023 | Server | r | r | o | o | - | - | 6024 | | | | | | | | 6025 | Session | R | r | o | o | o | m | 6026 | | | | | | | | 6027 | Session | r | r | c | c | o | m | 6028 | | | | | | | | 6029 | Speed | G | | - | - | - | - | 6030 | | | | | | | | 6031 | Supported | R | adrm | o | o | o | - | 6032 | | | | | | | | 6033 | Supported | r | adrm | c | c | c | - | 6034 | | | | | | | | 6035 | Terminate-Reason | R | r | - | - | m | - | 6036 | | | | | | | | 6037 | Timestamp | R | adrm | o | o | o | - | 6038 | | | | | | | | 6039 | Timestamp | c | adrm | m | m | m | - | 6040 | | | | | | | | 6041 | Transport | G | mr | - | - | - | - | 6042 | | | | | | | | 6043 | Unsupported | r | arm | c | c | c | - | 6044 | | | | | | | | 6045 | User-Agent | R | r | m* | m* | - | - | 6046 | | | | | | | | 6047 | User-Agent | r | r | m* | m* | m* | m* | 6048 | | | | | | | | 6049 | Via | R | amr | o | o | o | - | 6050 | | | | | | | | 6051 | Via | c | dr | m | m | m | - | 6052 | | | | | | | | 6053 | WWW-Authenticate | 401 | | m | m | m | - | 6054 +------------------+---------+-------+-----+-----+-----+-----+ 6056 Table 12: Overview of RTSP header fields (R-W) related to methods 6057 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 6059 18.1. Accept 6061 The Accept request-header field can be used to specify certain 6062 presentation description and parameter media types [RFC6838] which 6063 are acceptable for the response to DESCRIBE and GET_PARAMETER 6064 requests. 6066 See Section 20.2.3 for the syntax. 6068 The asterisk "*" character is used to group media types into ranges, 6069 with "*/*" indicating all media types and "type/*" indicating all 6070 subtypes of that type. The media-range MAY include media type 6071 parameters that are applicable to that range. 6073 Each media-range MAY be followed by one or more accept-params, 6074 beginning with the "q" parameter for indicating a relative quality 6075 factor. The first "q" parameter (if any) separates the media-range 6076 parameter(s) from the accept-params. Quality factors allow the user 6077 or user agent to indicate the relative degree of preference for that 6078 media-range, using the qvalue scale from 0 to 1 (section 3.9). The 6079 default value is q=1. 6081 Example of use: 6083 Accept: application/example ;q=0.7, application/sdp 6085 Indicates that the requesting agent prefers the media type 6086 application/sdp through the default 1.0 rating but also accepts the 6087 application/example media type with a 0.7 quality rating. 6089 If no Accept header field is present, then it is assumed that the 6090 client accepts all media types. If an Accept header field is 6091 present, and if the server cannot send a response which is acceptable 6092 according to the combined Accept field value, then the server SHOULD 6093 send a 406 (not acceptable) response. 6095 18.2. Accept-Credentials 6097 The Accept-Credentials header is a request-header used to indicate to 6098 any trusted intermediary how to handle further secured connections to 6099 proxies or servers. See Section 19 for the usage of this header. It 6100 MUST NOT be included in server to client requests. 6102 In a request the header MUST contain the method (User, Proxy, or Any) 6103 for approving credentials selected by the requester. The method MUST 6104 NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY 6105 change it to "user" to take the role of user approving each further 6106 hop. If the method is "User" the header contains zero or more of 6107 credentials that the client accepts. The header may contain zero 6108 credentials in the first RTSP request to a RTSP server when using the 6109 "User" method. This is because the client has not yet received any 6110 credentials to accept. Each credential MUST consist of one URI 6111 identifying the proxy or server, the hash algorithm identifier, and 6112 the hash over that agent's ASN.1 distinguished encoding rules (DER) 6113 encoded certificate [RFC5280] in BASE64, according to Section 4 of 6114 [RFC4648] and where the padding bits are set to zero. All RTSP 6115 clients and proxies MUST implement the SHA-256[FIPS-pub-180-2] 6116 algorithm for computation of the hash of the DER encoded certificate. 6117 The SHA-256 algorithm is identified by the token "sha-256". 6119 The intention with allowing for other hash algorithms is to enable 6120 the future retirement of algorithms that are not implemented 6121 somewhere else than here. Thus the definition of future algorithms 6122 for this purpose is intended to be extremely limited. A feature tag 6123 can be used to ensure that support for the replacement algorithm 6124 exists. 6126 Example: 6128 Accept-Credentials:User 6129 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 6130 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 6132 18.3. Accept-Encoding 6134 The Accept-Encoding request-header field is similar to Accept, but 6135 restricts the content-codings (see Section 18.15),i.e., 6136 transformation codings of the message body, such as gzip compression, 6137 that are acceptable in the response. 6139 A server tests whether a content-coding is acceptable, according to 6140 an Accept-Encoding field, using these rules: 6142 1. If the content-coding is one of the content-codings listed in the 6143 Accept-Encoding field, then it is acceptable, unless it is 6144 accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of 6145 0 means "not acceptable.") 6147 2. The special "*" symbol in an Accept-Encoding field matches any 6148 available content-coding not explicitly listed in the header 6149 field. 6151 3. If multiple content-codings are acceptable, then the acceptable 6152 content-coding with the highest non-zero qvalue is preferred. 6154 4. The "identity" content-coding is always acceptable, i.e., no 6155 transformation at all, unless specifically refused because the 6156 Accept-Encoding field includes "identity;q=0", or because the 6157 field includes "*;q=0" and does not explicitly include the 6158 "identity" content-coding. If the Accept-Encoding field-value is 6159 empty, then only the "identity" encoding is acceptable. 6161 If an Accept-Encoding field is present in a request, and if the 6162 server cannot send a response which is acceptable according to the 6163 Accept-Encoding header, then the server SHOULD send an error response 6164 with the 406 (Not Acceptable) status code. 6166 If no Accept-Encoding field is present in a request, the server MAY 6167 assume that the client will accept any content coding. In this case, 6168 if "identity" is one of the available content-codings, then the 6169 server SHOULD use the "identity" content-coding, unless it has 6170 additional information that a different content-coding is meaningful 6171 to the client. 6173 18.4. Accept-Language 6175 The Accept-Language request-header field is similar to Accept, but 6176 restricts the set of natural languages that are preferred as a 6177 response to the request. Note that the language specified applies to 6178 the presentation description and any reason phrases, but not the 6179 media content. 6181 A language tag identifies a natural language spoken, written, or 6182 otherwise conveyed by human beings for communication of information 6183 to other human beings. Computer languages are explicitly excluded. 6184 The syntax and registry of RTSP 2.0 language tags is the same as that 6185 defined by [RFC5646]. 6187 Each language-range MAY be given an associated quality value which 6188 represents an estimate of the user's preference for the languages 6189 specified by that range. The quality value defaults to "q=1". For 6190 example: 6192 Accept-Language: da, en-gb;q=0.8, en;q=0.7 6194 would mean: "I prefer Danish, but will accept British English and 6195 other types of English." A language-range matches a language-tag if 6196 it exactly equals the full tag, or if it exactly equals a prefix of 6197 the tag, i.e., the primary-tag in the ABNF, such that the character 6198 following primary-tag is "-". The special range "*", if present in 6199 the Accept-Language field, matches every tag not matched by any other 6200 range present in the Accept-Language field. 6202 Note: This use of a prefix matching rule does not imply that 6203 language tags are assigned to languages in such a way that it is 6204 always true that if a user understands a language with a certain 6205 tag, then this user will also understand all languages with tags 6206 for which this tag is a prefix. The prefix rule simply allows the 6207 use of prefix tags if this is the case. 6209 In the process of selecting a language, each language-tag is assigned 6210 a qualification factor, i.e., if a language being supported by the 6211 client is actually supported by the server and what "preference" 6212 level the language achieves. The quality value (q-value) of the 6213 longest language-range in the field that matches the language-tag is 6214 assigned as the qualification factor for a particular language-tag. 6215 If no language-range in the field matches the tag, the language 6216 qualification factor assigned is 0. If no Accept-Language header is 6217 present in the request, the server SHOULD assume that all languages 6218 are equally acceptable. If an Accept-Language header is present, 6219 then all languages which are assigned a qualification factor greater 6220 than 0 are acceptable. 6222 18.5. Accept-Ranges 6224 The Accept-Ranges general-header field allows indication of the 6225 format supported in the Range header. The client MUST include the 6226 header in SETUP requests to indicate which formats are acceptable 6227 when received in PLAY and PAUSE responses, and REDIRECT requests. 6228 The server MUST include the header in SETUP and 456 error responses 6229 to indicate the formats supported for the resource indicated by the 6230 request URI. The header MAY be included in GET_PARAMETER request and 6231 response pairs. The GET_PARAMETER request MUST contain a Session 6232 header to identify the session context the request is related to. 6233 The requester and responder will indicate their capabilities 6234 regarding Range formats respectively. 6236 Accept-Ranges: npt, smpte, clock 6238 The syntax is defined in Section 20.2.3. 6240 18.6. Allow 6242 The Allow message-body header field lists the methods supported by 6243 the resource identified by the Request-URI. The purpose of this 6244 field is to inform the recipient of the complete set of valid methods 6245 associated with the resource. An Allow header field MUST be present 6246 in a 405 (Method Not Allowed) response. The Allow header MUST also 6247 be present in all OPTIONS responses where the content of the header 6248 will not include exactly the same methods as listed in the Public 6249 header. 6251 The Allow message-body header MUST also be included in SETUP and 6252 DESCRIBE responses, if the methods allowed for the resource are 6253 different from the complete set of methods defined in this memo. 6255 Example of use: 6257 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 6259 18.7. Authentication-Info 6261 The Authentication-Info response-header is used by the server to 6262 communicate some information regarding the successful authentication 6263 in the response message. This usage of this header is specified in 6264 [RFC2617] with some RTSP clarification in Section 19.1. This header 6265 MUST only be used in response messages related to client to server 6266 requests. 6268 18.8. Authorization 6270 An RTSP client that wishes to authenticate itself with a server using 6271 authentication mechanism from HTTP [RFC2617] , usually, but not 6272 necessarily, after receiving a 401 response, does so by including an 6273 Authorization request-header field with the request. The 6274 Authorization field value consists of credentials containing the 6275 authentication information of the user agent for the realm of the 6276 resource being requested. This header MUST only be used in client to 6277 server requests. 6279 If a request is authenticated and a realm specified, the same 6280 credentials SHOULD be valid for all other requests within this realm 6281 (assuming that the authentication scheme itself does not require 6282 otherwise, such as credentials that vary according to a challenge 6283 value or using synchronized clocks). Each client to server request 6284 MUST be individually authorized by including the Authorization header 6285 with the information. 6287 When a shared cache (see Section 16) receives a request containing an 6288 Authorization field, it MUST NOT return the corresponding response as 6289 a reply to any other request, unless one of the following specific 6290 exceptions holds: 6292 1. If the response includes the "max-age" cache-control directive, 6293 the cache MAY use that response in replying to a subsequent 6294 request. But (if the specified maximum age has passed) a proxy 6295 cache MUST first revalidate it with the origin server, using the 6296 request-headers from the new request to allow the origin server 6297 to authenticate the new request. (This is the defined behavior 6298 for max-age.) If the response includes "max-age=0", the proxy 6299 MUST always revalidate it before re-using it. 6301 2. If the response includes the "must-revalidate" cache-control 6302 directive, the cache MAY use that response in replying to a 6303 subsequent request. But if the response is stale, all caches 6304 MUST first revalidate it with the origin server, using the 6305 request-headers from the new request to allow the origin server 6306 to authenticate the new request. 6308 3. If the response includes the "public" cache-control directive, it 6309 MAY be returned in reply to any subsequent request. 6311 18.9. Bandwidth 6313 The Bandwidth request-header field describes the estimated bandwidth 6314 available to the client, expressed as a positive integer and measured 6315 in kilobits per second. The bandwidth available to the client may 6316 change during an RTSP session, e.g., due to mobility, congestion, 6317 etc. 6319 Clients may not be able to accurately determine the available 6320 bandwidth, for example because the first hop is not a bottleneck. 6321 For example most local area networks (LAN) will not be a bottleneck 6322 if the server is not in the same LAN. Thus link speeds of WLAN or 6323 Ethernet networks are normally not a basis for estimating the 6324 available bandwidth. Cellular devices or other devices directly 6325 connected to a modem or connection enabling device may more 6326 accurately estimate the bottleneck bandwidth and what is a reasonable 6327 share of it for RTSP controlled media. The client will also need to 6328 take into account other traffic sharing the bottleneck. For example 6329 by only assigning a certain fraction to RTSP and its media streams. 6330 It is RECOMMENDED that only clients that have accurate and explicit 6331 information about bandwidth bottlenecks uses this header. 6333 This header is not a substitute for proper congestion control. It is 6334 only a method providing an initial estimate and coarsely determines 6335 if the selected content can be delivered at all. 6337 Example: 6339 Bandwidth: 62360 6341 18.10. Blocksize 6343 The Blocksize request-header field is sent from the client to the 6344 media server asking the server for a particular media packet size. 6345 This packet size does not include lower-layer headers such as IP, 6346 UDP, or RTP. The server is free to use a blocksize which is lower 6347 than the one requested. The server MAY truncate this packet size to 6348 the closest multiple of the minimum, media-specific block size, or 6349 override it with the media-specific size if necessary. The block 6350 size MUST be a positive decimal number, measured in octets. The 6351 server only returns an error (4xx) if the value is syntactically 6352 invalid. 6354 18.11. Cache-Control 6356 The Cache-Control general-header field is used to specify directives 6357 that MUST be obeyed by all caching mechanisms along the request/ 6358 response chain. 6360 Cache directives MUST be passed through by a proxy or gateway 6361 application, regardless of their significance to that application, 6362 since the directives may be applicable to all recipients along the 6363 request/response chain. It is not possible to specify a cache- 6364 directive for a specific cache. 6366 Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, 6367 SET_PARAMETER and SETUP request and its response. Note: Cache- 6368 Control does not govern just the caching of responses as for HTTP, 6369 instead it also applies to the media stream identified by the SETUP 6370 request. The RTSP requests are generally not cacheable, for further 6371 information see Section 16. Below are the descriptions of the cache 6372 directives that can be included in the Cache-Control header. 6374 no-cache: Indicates that the media stream or RTSP response MUST NOT 6375 be cached anywhere. This allows an origin server to prevent 6376 caching even by caches that have been configured to return 6377 stale responses to client requests. Note, there is no security 6378 function preventing the caching of content. 6380 public: Indicates that the media stream or RTSP response is 6381 cacheable by any cache. 6383 private: Indicates that the media stream or RTSP response is 6384 intended for a single user and MUST NOT be cached by a shared 6385 cache. A private (non-shared) cache may cache the media 6386 streams. 6388 no-transform: An intermediate cache (proxy) may find it useful to 6389 convert the media type of a certain stream. A proxy might, for 6390 example, convert between video formats to save cache space or 6391 to reduce the amount of traffic on a slow link. Serious 6392 operational problems may occur, however, when these 6393 transformations have been applied to streams intended for 6394 certain kinds of applications. For example, applications for 6395 medical imaging, scientific data analysis and those using end- 6396 to-end authentication all depend on receiving a stream that is 6397 bit-for-bit identical to the original media stream or RTSP 6398 response. Therefore, if a response includes the no-transform 6399 directive, an intermediate cache or proxy MUST NOT change the 6400 encoding of the stream or response. Unlike HTTP, RTSP does not 6401 provide for partial transformation at this point, e.g., 6402 allowing translation into a different language. 6404 only-if-cached: In some cases, such as times of extremely poor 6405 network connectivity, a client may want a cache to return only 6406 those media streams or RTSP responses that it currently has 6407 stored, and not to receive these from the origin server. To do 6408 this, the client may include the only-if-cached directive in a 6409 request. If it receives this directive, a cache SHOULD either 6410 respond using a cached media stream or response that is 6411 consistent with the other constraints of the request, or 6412 respond with a 504 (Gateway Timeout) status. However, if a 6413 group of caches is being operated as a unified system with good 6414 internal connectivity, such a request MAY be forwarded within 6415 that group of caches. 6417 max-stale: Indicates that the client is willing to accept a media 6418 stream or RTSP response that has exceeded its expiration time. 6419 If max-stale is assigned a value, then the client is willing to 6420 accept a response that has exceeded its expiration time by no 6421 more than the specified number of seconds. If no value is 6422 assigned to max-stale, then the client is willing to accept a 6423 stale response of any age. 6425 min-fresh: Indicates that the client is willing to accept a media 6426 stream or RTSP response whose freshness lifetime is no less 6427 than its current age plus the specified time in seconds. That 6428 is, the client wants a response that will still be fresh for at 6429 least the specified number of seconds. 6431 must-revalidate: When the must-revalidate directive is present in a 6432 SETUP response received by a cache, that cache MUST NOT use the 6433 cache entry after it becomes stale to respond to a subsequent 6434 request without first revalidating it with the origin server. 6435 That is, the cache is required to do an end-to-end revalidation 6436 every time, if, based solely on the origin server's Expires, 6437 the cached response is stale. 6439 proxy-revalidate: The proxy-revalidate directive has the same 6440 meaning as the must-revalidate directive, except that it does 6441 not apply to non-shared user agent caches. It can be used on a 6442 response to an authenticated request to permit the user's cache 6443 to store and later return the response without needing to 6444 revalidate it (since it has already been authenticated once by 6445 that user), while still requiring proxies that service many 6446 users to revalidate each time (in order to make sure that each 6447 user has been authenticated). Note that such authenticated 6448 responses also need the public cache control directive in order 6449 to allow them to be cached at all. 6451 max-age: When an intermediate cache is forced, by means of a max- 6452 age=0 directive, to revalidate its own cache entry, and the 6453 client has supplied its own validator in the request, the 6454 supplied validator might differ from the validator currently 6455 stored with the cache entry. In this case, the cache MAY use 6456 either validator in making its own request without affecting 6457 semantic transparency. 6459 However, the choice of validator might affect performance. The 6460 best approach is for the intermediate cache to use its own 6461 validator when making its request. If the server replies with 6462 304 (Not Modified), then the cache can return its now validated 6463 copy to the client with a 200 (OK) response. If the server 6464 replies with a new message body and cache validator, however, 6465 the intermediate cache can compare the returned validator with 6466 the one provided in the client's request, using the strong 6467 comparison function. If the client's validator is equal to the 6468 origin server's, then the intermediate cache simply returns 304 6469 (Not Modified). Otherwise, it returns the new message body 6470 with a 200 (OK) response. 6472 18.12. Connection 6474 The Connection general-header field allows the sender to specify 6475 options that are desired for that particular connection. It MUST NOT 6476 be communicated by proxies over further connections. 6478 RTSP 2.0 proxies MUST parse the Connection header field before a 6479 message is forwarded and, for each connection-token in this field, 6480 remove any header field(s) from the message with the same name as the 6481 connection-token. Connection options are signaled by the presence of 6482 a connection-token in the Connection header field, not by any 6483 corresponding additional header field(s), since the additional header 6484 field may not be sent if there are no parameters associated with that 6485 connection option. 6487 Message headers listed in the Connection header MUST NOT include end- 6488 to-end headers, such as Cache-Control. 6490 RTSP 2.0 defines the "close" connection option for the sender to 6491 signal that the connection will be closed after completion of the 6492 response. For example, Connection: close in either the request or 6493 the response-header fields indicates that the connection SHOULD NOT 6494 be considered `persistent' (Section 10.2) after the current request/ 6495 response is complete. 6497 The use of the connection option "close" in RTSP messages SHOULD be 6498 limited to error messages when the server is unable to recover and 6499 therefore sees it necessary to close the connection. The reason is 6500 that the client has the choice of continuing using a connection 6501 indefinitely, as long as it sends valid messages. 6503 18.13. Connection-Credentials 6505 The Connection-Credentials response-header is used to carry the chain 6506 of credentials for any next hop that needs to be approved by the 6507 requester. It MUST only be used in server to client responses. 6509 The Connection-Credentials header in an RTSP response MUST, if 6510 included, contain the credential information (in form of a list of 6511 certificates providing the chain of certification) of the next hop 6512 that an intermediary needs to securely connect to. The header MUST 6513 include the URI of the next hop (proxy or server) and a BASE64 6514 (according to Section 4 of [RFC4648] and where the padding bits are 6515 set to zero) encoded binary structure containing a sequence of DER 6516 encoded X.509v3 certificates [RFC5280]. 6518 The binary structure starts with the number of certificates 6519 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 6520 by NR_CERTS number of 16 bit unsigned integers providing the size in 6521 octets of each DER encoded certificate. This is followed by NR_CERTS 6522 number of DER encoded X.509v3 certificates in a sequence (chain). 6523 This format is exemplified in Figure 2. The proxy or server's 6524 certificate must come first in the structure. Each following 6525 certificate must directly certify the one preceding it. Because 6526 certificate validation requires that root keys be distributed 6527 independently, the self-signed certificate which specifies the root 6528 certificate authority may optionally be omitted from the chain, under 6529 the assumption that the remote end must already possess it in order 6530 to validate it in any case. 6532 Example: 6534 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 6536 Where MIIDNTCC... is a Base64 encoding of the following structure: 6538 0 1 2 3 6539 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 6540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6541 | Number of certificates | Size of certificate #1 | 6542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6543 | Size of certificate #2 | Size of certificate #3 | 6544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6545 : DER Encoding of Certificate #1 : 6546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6547 : DER Encoding of Certificate #2 : 6548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6549 : DER Encoding of Certificate #3 : 6550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6552 Figure 2: Connection-Credentials header's Certificate Format Example 6554 18.14. Content-Base 6556 The Content-Base message-body header field may be used to specify the 6557 base URI for resolving relative URIs within the message body. 6559 Content-Base: rtsp://media.example.com/movie/twister/ 6561 If no Content-Base field is present, the base URI of an message body 6562 is defined either by its Content-Location (if that Content-Location 6563 URI is an absolute URI) or the URI used to initiate the request, in 6564 that order of precedence. Note, however, that the base URI of the 6565 contents within the message-body may be redefined within that 6566 message-body. 6568 18.15. Content-Encoding 6570 The Content-Encoding message-body header field is used as a modifier 6571 to the media-type. When present, its value indicates what additional 6572 content codings have been applied to the message body, and thus what 6573 decoding mechanisms must be applied in order to obtain the media-type 6574 referenced by the Content-Type header field. Content-Encoding is 6575 primarily used to allow a document to be compressed without losing 6576 the identity of its underlying media type. 6578 The content-coding is a characteristic of the message body identified 6579 by the Request-URI. Typically, the message body is stored with this 6580 encoding and is only decoded before rendering or analogous usage. 6581 However, an RTSP proxy MAY modify the content-coding if the new 6582 coding is known to be acceptable to the recipient, unless the "no- 6583 transform" cache-control directive is present in the message. 6585 If the content-coding of a message body is not "identity", then the 6586 message MUST include a Content-Encoding Message-body header that 6587 lists the non-identity content-coding(s) used. 6589 If the content-coding of a message body in a request message is not 6590 acceptable to the origin server, the server SHOULD respond with a 6591 status code of 415 (Unsupported Media Type). 6593 If multiple encodings have been applied to a message body, the 6594 content codings MUST be listed in the order in which they were 6595 applied, first to last from left to right. Additional information 6596 about the encoding parameters MAY be provided by other header fields 6597 not defined by this specification. 6599 18.16. Content-Language 6601 The Content-Language message-body header field describes the natural 6602 language(s) of the intended audience for the enclosed message body. 6603 Note that this might not be equivalent to all the languages used 6604 within the message body. 6606 Language tags are mentioned in Section 18.4. The primary purpose of 6607 Content-Language is to allow a user to identify and differentiate 6608 entities according to the user's own preferred language. Thus, if 6609 the body content is intended only for a Danish-literate audience, the 6610 appropriate field is 6612 Content-Language: da 6614 If no Content-Language is specified, the default is that the content 6615 is intended for all language audiences. This might mean that the 6616 sender does not consider it to be specific to any natural language, 6617 or that the sender does not know for which language it is intended. 6619 Multiple languages MAY be listed for content that is intended for 6620 multiple audiences. For example, a rendition of the "Treaty of 6621 Waitangi," presented simultaneously in the original Maori and English 6622 versions, would call for 6624 Content-Language: mi, en 6626 However, just because multiple languages are present within a message 6627 body does not mean that it is intended for multiple linguistic 6628 audiences. An example would be a beginner's language primer, such as 6629 "A First Lesson in Latin," which is clearly intended to be used by an 6630 English-literate audience. In this case, the Content-Language would 6631 properly only include "en". 6633 Content-Language MAY be applied to any media type -- it is not 6634 limited to textual documents. 6636 18.17. Content-Length 6638 The Content-Length message-body header field contains the length of 6639 the message body of the RTSP message (i.e., after the double CRLF 6640 following the last header). Unlike HTTP, it MUST be included in all 6641 messages that carry a message body beyond the header portion of the 6642 RTSP message. If it is missing, a default value of zero is assumed. 6643 Any Content-Length greater than or equal to zero is a valid value. 6645 18.18. Content-Location 6647 The Content-Location message-body header field MAY be used to supply 6648 the resource location for the message body enclosed in the message 6649 when that body is accessible from a location separate from the 6650 requested resource's URI. A server SHOULD provide a Content-Location 6651 for the variant corresponding to the response message body; 6652 especially in the case where a resource has multiple variants 6653 associated with it, and those entities actually have separate 6654 locations by which they might be individually accessed, the server 6655 SHOULD provide a Content-Location for the particular variant which is 6656 returned. 6658 As example, if an RTSP client performs a DESCRIBE request on a given 6659 resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", 6660 then the server may use additional information, such as the User- 6661 Agent header, to determine the capabilities of the agent. The server 6662 will then return a media description tailored to that class of RTSP 6663 agents. To indicate which specific description the agent receives 6664 the resource identifier ("rtsp://a.example.com/movie/ 6665 Plan9FromOuterSpace/FullHD.sdp") is provided in Content-Location, 6666 while the description is still a valid response for the generic 6667 resource identifier. Thus enabling both debugging and cache 6668 operation as discussed below. 6670 The Content-Location value is not a replacement for the original 6671 requested URI; it is only a statement of the location of the resource 6672 corresponding to this particular variant at the time of the request. 6673 Future requests MAY specify the Content-Location URI as the request 6674 URI if the desire is to identify the source of that particular 6675 variant. This is useful if the RTSP agent desires to verify if the 6676 resource variant is current through a conditional request. 6678 A cache cannot assume that a message body with a Content-Location 6679 different from the URI used to retrieve it can be used to respond to 6680 later requests on that Content-Location URI. However, the Content- 6681 Location can be used to differentiate between multiple variants 6682 retrieved from a single requested resource. 6684 If the Content-Location is a relative URI, the relative URI is 6685 interpreted relative to the Request-URI. 6687 Note, that Content-Location can be used in some cases to derive the 6688 base-URI for relative URI(s) present in session description formats. 6689 This needs to be taken into account when Content-Location is used. 6690 The easiest way to avoid needing to consider that issue is to include 6691 the Content-Base whenever the Content-Location is included. 6693 Note also, when using Media Tags in conjunction with Content-Location 6694 it is important that the different versions have different MTags, 6695 even if provided under different Content-Location URIs. This as they 6696 have still been provided under the same request URI. 6698 Note also, as in most cases the URI used in the DESCRIBE and the 6699 SETUP requests are different, the URI provided in a DESCRIBE Content- 6700 Location response can't directly be used in a SETUP request. Instead 6701 the extra step of resolving URIs combined with the media descriptions 6702 indication, like with SDP's a=control attribute. 6704 18.19. Content-Type 6706 The Content-Type message-body header indicates the media type of the 6707 message body sent to the recipient. Note that the content types 6708 suitable for RTSP are likely to be restricted in practice to 6709 presentation descriptions and parameter-value types. 6711 18.20. CSeq 6713 The CSeq general-header field specifies the sequence number (integer) 6714 for an RTSP request-response pair. This field MUST be present in all 6715 requests and responses. RTSP agents maintain a sequence number 6716 series for each responder to which they have an open message 6717 transport channel. For each new RTSP request an agent originates on 6718 a particular RTSP message transport the CSeq value MUST be 6719 incremented by one. The initial sequence number can be any number, 6720 however, it is RECOMMENDED to start at 0. Each sequence number 6721 series is unique between each requester and responder, i.e., the 6722 client has one series for its requests to a server and the server has 6723 another when sending requests to the client. Each requester and 6724 responder is identified by its socket address (IP address and port 6725 number), i.e., per direction of a TCP connection. Any retransmitted 6726 request MUST contain the same sequence number as the original, i.e., 6727 the sequence number is not incremented for retransmissions of the 6728 same request. The RTSP agent receiving requests MUST process the 6729 requests arriving on a particular transport in the order of the 6730 sequence numbers. Responses are sent in the order that they are 6731 generated. The RTSP response MUST have the same sequence number as 6732 was present in the corresponding request. A RTSP Agent receiving a 6733 response MAY receive the responses out of order compared to the order 6734 of the requests it sent. Thus, the agent MUST use the sequence 6735 number in the response to pair it with the corresponding request. 6737 The main purpose of the sequence number is to map responses to 6738 requests. 6740 The requirement to use a sequence number increment of one for each 6741 new request is to support any future specification of RTSP message 6742 transport over a protocol that does not provide in order delivery 6743 or is unreliable. 6745 The above rules relating to the initial sequence number may appear 6746 unnecessarily loose. The reason is to cater for some common 6747 behavior of existing implementations: When using multiple reliable 6748 connections in sequence it may still be easiest to use a single 6749 sequence number series for a client connecting with a particular 6750 server. Thus, the initial sequence number may be arbitrary 6751 depending on the number of previous requests. For any unreliable 6752 transport a stricter definition or other solution will be required 6753 to enable detection of any loss of the first request. 6755 When using multiple sequential transport connections, there is no 6756 protocol mechanism to ensure in order processing as the sequence 6757 number is scoped on the individual transport connection and its 6758 five tuple. Thus, there are potential issues with opening a new 6759 transport connection to the same host for which there already 6760 exists a transport connection with outstanding requests and 6761 previously despatched requests related to the same RTSP session. 6763 RTSP Proxies also need to follow the above rules. This implies that 6764 proxies that aggregate requests from multiple clients onto a single 6765 transport towards a server or a next hop proxy need to renumber these 6766 requests to form a unified sequence on that transport, fulfilling the 6767 above rules. A proxy capable of fulfilling some agent's request 6768 without emitting its own request (e.g., a caching proxy that fulfils 6769 a request from its cache), also causes a need to renumber as the 6770 number of received requests with a particular target, may not be the 6771 same as the number of emitted requests towards that target agent. A 6772 proxy that needs to renumber, needs to perform the corresponding 6773 renumbering back to the original sequence number for any received 6774 response before forwarding it back to the originator of the request. 6776 A client connected to a proxy, and using that transport to send 6777 requests to multiple servers creates a situation where it is quite 6778 likely to receive the responses out of order. This is because the 6779 proxy will establish separate transports from the proxy to the 6780 servers on which to forward the client's requests. When the 6781 responses arrive from the different servers they will be forwarded 6782 to the client in the order they arrive at the proxy and can be 6783 processed, not the order of the client's original sequence 6784 numbers. This is intentional to avoid some session's requests 6785 being blocked by another server's slow processing of requests. 6787 18.21. Date 6789 The Date general-header field represents the date and time at which 6790 the message was originated. The inclusion of the Date header in RTSP 6791 message follows these rules: 6793 o An RTSP message, sent either by the client or the server, 6794 containing a body MUST include a Date header, if the sending host 6795 has a clock; 6797 o Clients and servers are RECOMMENDED to include a Date header in 6798 all other RTSP messages, if the sending host has a clock; 6800 o If the server does not have a clock that can provide a reasonable 6801 approximation of the current time, its responses MUST NOT include 6802 a Date header field. In this case, this rule MUST be followed: 6803 Some origin server implementations might not have a clock 6804 available. An origin server without a clock MUST NOT assign 6805 Expires or Last-Modified values to a response, unless these values 6806 were associated with the resource by a system or user with a 6807 reliable clock. It MAY assign an Expires value that is known, at 6808 or before server configuration time, to be in the past (this 6809 allows "pre-expiration" of responses without storing separate 6810 Expires values for each resource). 6812 A received message that does not have a Date header field MUST be 6813 assigned one by the recipient if the message will be cached by that 6814 recipient. An RTSP implementation without a clock MUST NOT cache 6815 responses without revalidating them on every use. An RTSP cache, 6816 especially a shared cache, SHOULD use a mechanism, such as Network 6817 Time Protocol (NTP) [RFC5905], to synchronize its clock with a 6818 reliable external standard. 6820 The RTSP-date, a full date as specified by Section 3.3 of [RFC5322], 6821 sent in a Date header SHOULD NOT represent a date and time subsequent 6822 to the generation of the message. It SHOULD represent the best 6823 available approximation of the date and time of message generation, 6824 unless the implementation has no means of generating a reasonably 6825 accurate date and time. In theory, the date ought to represent the 6826 moment just before the message body is generated. In practice, the 6827 date can be generated at any time during the message origination 6828 without affecting its semantic value. 6830 Note: The RTSP 2.0 date format is defined to be the RFC 5322 full 6831 date format. This format is more flexible than the RFC 1123 date 6832 format used by RTSP 1.0. Thus implementations should use single 6833 spaces as recommended by RFC 5322 as separators and support 6834 receiving the obsolete format. 6836 Further Note that the syntax allow for a comment to be added at 6837 the end of the date. 6839 [RFC Editor please remove this note in brackets: Prior to version 6840 37 of the draft, rfc2326bis envisaged sticking with the RFC 1123 6841 format.] 6843 18.22. Expires 6845 The Expires message-body header field gives a date and time after 6846 which the description or media-stream should be considered stale. 6847 The interpretation depends on the method: 6849 DESCRIBE response: The Expires header indicates a date and time 6850 after which the presentation description (body) SHOULD be 6851 considered stale. 6853 SETUP response: The Expires header indicate a date and time after 6854 which the media stream SHOULD be considered stale. 6856 A stale cache entry may not normally be returned by a cache (either a 6857 proxy cache or an user agent cache) unless it is first validated with 6858 the origin server (or with an intermediate cache that has a fresh 6859 copy of the message body). See Section 16 for further discussion of 6860 the expiration model. 6862 The presence of an Expires field does not imply that the original 6863 resource will change or cease to exist at, before, or after that 6864 time. 6866 The format is an absolute date and time as defined by RTSP-date. An 6867 example of its use is 6869 Expires: Wed, 23 Jan 2013 15:36:52 +0000 6871 RTSP/2.0 clients and caches MUST treat other invalid date formats, 6872 especially including the value "0", as having occurred in the past 6873 (i.e., already expired). 6875 To mark a response as "already expired," an origin server should use 6876 an Expires date that is equal to the Date header value. To mark a 6877 response as "never expires," an origin server SHOULD use an Expires 6878 date approximately one year from the time the response is sent. RTSP 6879 /2.0 servers SHOULD NOT send Expires dates more than one year in the 6880 future. 6882 18.23. From 6884 The From request-header field, if given, SHOULD contain an Internet 6885 e-mail address for the human user who controls the requesting user 6886 agent. The address SHOULD be machine-usable, as defined by "mailbox" 6887 in [RFC1123]. 6889 This header field MAY be used for logging purposes and as a means for 6890 identifying the source of invalid or unwanted requests. It SHOULD 6891 NOT be used as an insecure form of access protection. The 6892 interpretation of this field is that the request is being performed 6893 on behalf of the person given, who accepts responsibility for the 6894 method performed. In particular, robot agents SHOULD include this 6895 header so that the person responsible for running the robot can be 6896 contacted if problems occur on the receiving end. 6898 The Internet e-mail address in this field MAY be separate from the 6899 Internet host which issued the request. For example, when a request 6900 is passed through a proxy the original issuer's address SHOULD be 6901 used. 6903 The client SHOULD NOT send the From header field without the user's 6904 approval, as it might conflict with the user's privacy interests or 6905 their site's security policy. It is strongly recommended that the 6906 user be able to disable, enable, and modify the value of this field 6907 at any time prior to a request. 6909 18.24. If-Match 6911 The If-Match request-header field is especially useful for ensuring 6912 the integrity of the presentation description, independent of how the 6913 presentation description was received. The presentation description 6914 can be fetched via means external to RTSP (such as HTTP) or via the 6915 DESCRIBE message. In the case of retrieving the presentation 6916 description via RTSP, the server implementation is guaranteeing the 6917 integrity of the description between the time of the DESCRIBE message 6918 and the SETUP message. By including the MTag given in or with the 6919 session description in an If-Match header part of the SETUP request, 6920 the client ensures that resources set up are matching the 6921 description. A SETUP request with the If-Match header for which the 6922 MTag validation check fails, MUST generate a response using 412 6923 (Precondition Failed). 6925 This validation check is also very useful if a session has been 6926 redirected from one server to another. 6928 18.25. If-Modified-Since 6930 The If-Modified-Since request-header field is used with the DESCRIBE 6931 and SETUP methods to make them conditional. If the requested variant 6932 has not been modified since the time specified in this field, a 6933 description will not be returned from the server (DESCRIBE) or a 6934 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 6935 response MUST be returned without any message-body. 6937 An example of the field is: 6939 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 6941 18.26. If-None-Match 6943 This request-header can be used with one or several message body tags 6944 to make DESCRIBE requests conditional. A client that has one or more 6945 message bodies previously obtained from the resource, can verify that 6946 none of those entities is current by including a list of their 6947 associated message body tags in the If-None-Match header field. The 6948 purpose of this feature is to allow efficient updates of cached 6949 information with a minimum amount of transaction overhead. As a 6950 special case, the value "*" matches any current entity of the 6951 resource. 6953 If any of the message body tags match the message body tag of the 6954 message body that would have been returned in the response to a 6955 similar DESCRIBE request (without the If-None-Match header) on that 6956 resource, or if "*" is given and any current entity exists for that 6957 resource, then the server MUST NOT perform the requested method, 6958 unless required to do so because the resource's modification date 6959 fails to match that supplied in an If-Modified-Since header field in 6960 the request. Instead, if the request method was DESCRIBE, the server 6961 SHOULD respond with a 304 (Not Modified) response, including the 6962 cache-related header fields (particularly MTag) of one of the message 6963 bodies that matched. For all other request methods, the server MUST 6964 respond with a status of 412 (Precondition Failed). 6966 See Section 16.1.3 for rules on how to determine if two message body 6967 tags match. 6969 If none of the message body tags match, then the server MAY perform 6970 the requested method as if the If-None-Match header field did not 6971 exist, but MUST also ignore any If-Modified-Since header field(s) in 6972 the request. That is, if no message body tags match, then the server 6973 MUST NOT return a 304 (Not Modified) response. 6975 If the request would, without the If-None-Match header field, result 6976 in anything other than a 2xx or 304 status, then the If-None-Match 6977 header MUST be ignored. (See Section 16.1.4 for a discussion of 6978 server behavior when both If-Modified-Since and If-None-Match appear 6979 in the same request.) 6981 The result of a request having both an If-None-Match header field and 6982 an If-Match header field is unspecified and MUST be considered an 6983 illegal request. 6985 18.27. Last-Modified 6987 The Last-Modified message-body header field indicates the date and 6988 time at which the origin server believes the presentation description 6989 or media stream was last modified. For the method DESCRIBE, the 6990 header field indicates the last modification date and time of the 6991 description, for SETUP that of the media stream. 6993 An origin server MUST NOT send a Last-Modified date which is later 6994 than the server's time of message origination. In such cases, where 6995 the resource's last modification would indicate some time in the 6996 future, the server MUST replace that date with the message 6997 origination date. 6999 An origin server SHOULD obtain the Last-Modified value of the message 7000 body as close as possible to the time that it generates the Date 7001 value of its response. This allows a recipient to make an accurate 7002 assessment of the message body's modification time, especially if the 7003 message body changes near the time that the response is generated. 7005 RTSP servers SHOULD send Last-Modified whenever feasible. 7007 18.28. Location 7009 The Location response-header field is used to redirect the recipient 7010 to a location other than the Request-URI for completion of the 7011 request or identification of a new resource. For 3rr responses, the 7012 location SHOULD indicate the server's preferred URI for automatic 7013 redirection to the resource. The field value consists of a single 7014 absolute URI. 7016 Note: The Content-Location header field (Section 18.18) differs from 7017 Location in that the Content-Location identifies the original 7018 location of the message body enclosed in the request. It is 7019 therefore possible for a response to contain header fields for both 7020 Location and Content-Location. Also, see Section 16.2 for cache 7021 requirements of some methods. 7023 18.29. Media-Properties 7025 This general-header is used in SETUP response or PLAY_NOTIFY requests 7026 to indicate the media's properties that currently are applicable to 7027 the RTSP session. PLAY_NOTIFY MAY be used to modify these properties 7028 at any point. However, the client SHOULD have received the update 7029 prior to any action related to the new media properties taking 7030 effect. For aggregated sessions, the Media-Properties header will be 7031 returned in each SETUP response. The header received in the latest 7032 response is the one that applies on the whole session from this point 7033 until any future update. The header MAY be included without value in 7034 GET_PARAMETER requests to the server with a Session header included 7035 to query the current Media-Properties for the session. The responder 7036 MUST include the current session's media properties. 7038 The media properties expressed by this header is the one applicable 7039 to all media in the RTSP session. For aggregated sessions, the 7040 header expressed the combined media-properties. As a result, 7041 aggregation of media MAY result in a change of the media properties, 7042 and thus the content of the Media-Properties header contained in 7043 subsequent SETUP responses. 7045 The header contains a list of property values that are applicable to 7046 the currently setup media or aggregate of media as indicated by the 7047 RTSP URI in the request. No ordering is enforced within the header. 7048 Property values should be grouped into a single group that handles a 7049 particular orthogonal property. Values or groups that express 7050 multiple properties SHOULD NOT be used. The list of properties that 7051 can be expressed MAY be extended at any time. Unknown property 7052 values MUST be ignored. 7054 This specification defines the following 4 groups and their property 7055 values: 7057 Random Access: 7059 Random-Access: Indicates that random access is possible. May 7060 optionally include a floating point value in seconds indicating 7061 the longest duration between any two random access points in 7062 the media. 7064 Beginning-Only: Seeking is limited to the beginning only. 7066 No-Seeking: No seeking is possible. 7068 Content Modifications: 7070 Immutable: The content will not be changed during the life-time 7071 of the RTSP session. 7073 Dynamic: The content may be changed based on external methods or 7074 triggers 7076 Time-Progressing: The media accessible progresses as wallclock 7077 time progresses. 7079 Retention: 7081 Unlimited: Content will be retained for the duration of the life- 7082 time of the RTSP session. 7084 Time-Limited: Content will be retained at least until the 7085 specified wallclock time. The time must be provided in the 7086 absolute time format specified in Section 4.4.3. 7088 Time-Duration: Each individual media unit is retained for at 7089 least the specified time duration. This definition allows for 7090 retaining data with a time based sliding window. The time 7091 duration is expressed as floating point number in seconds. 0.0 7092 is a valid value as this indicates that no data is retained in 7093 a time-progressing session. 7095 Supported Scale: 7097 Scales: A quoted comma separated list of one or more decimal 7098 values or ranges of scale values supported by the content in 7099 arbitrary order. A range has a start and stop value separated 7100 by a colon. A range indicates that the content supports fine 7101 grained selection of scale values. Fine grained allows for 7102 steps at least as small as one tenth of a scale value. A 7103 content is considered to support fine grained selection when 7104 the server in response to a given scale value can produce 7105 content with an actual scale that is less than 1 tenth of scale 7106 unit, i.e., 0.1, from the requested value. Negative values are 7107 supported. The value 0 has no meaning and MUST NOT be used. 7109 Examples of this header for on-demand content and a live stream 7110 without recording are: 7112 On-demand: 7113 Media-Properties: Random-Access=2.5, Unlimited, Immutable, 7114 Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" 7116 Live stream without recording/timeshifting: 7117 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 7119 18.30. Media-Range 7121 The Media-Range general-header is used to give the range of the media 7122 at the time of sending the RTSP message. This header MUST be 7123 included in SETUP response, and PLAY and PAUSE response for media 7124 that are Time-Progressing, and PLAY and PAUSE response after any 7125 change for media that are Dynamic, and in PLAY_NOTIFY request that 7126 are sent due to Media-Property-Update. Media-Range header without 7127 any range specifications MAY be included in GET_PARAMETER requests to 7128 the server to request the current range. The server MUST in this 7129 case include the current range at the time of sending the response. 7131 The header MUST include range specifications for all time formats 7132 supported for the media, as indicated in Accept-Ranges header 7133 (Section 18.5) when setting up the media. The server MAY include 7134 more than one range specification of any given time format to 7135 indicate media that has non-continuous range. The range 7136 specifications SHALL be ordered with the range with the lowest value 7137 or earliest start time first, followed by ranges with increasingly 7138 higher values or later start time. 7140 For media that has the Time-Progressing property, the Media-Range 7141 values will only be valid for the particular point in time when it 7142 was issued. As wallclock progresses so will also the media range. 7143 However, it shall be assumed that media time progresses in direct 7144 relationship to wallclock time (with the exception of clock skew) so 7145 that a reasonably accurate estimation of the media range can be 7146 calculated. 7148 18.31. MTag 7150 The MTag response-header MAY be included in DESCRIBE, GET_PARAMETER 7151 or SETUP responses. The message body tags (Section 4.6) returned in 7152 a DESCRIBE response, and the one in SETUP refers to the presentation, 7153 i.e., both the returned session description and the media stream. 7154 This allows for verification that one has the right session 7155 description to a media resource at the time of the SETUP request. 7157 However, it has the disadvantage that a change in any of the parts 7158 results in invalidation of all the parts. 7160 If the MTag is provided both inside the message body, e.g., within 7161 the "a=mtag" attribute in SDP, and in the response message, then both 7162 tags MUST be identical. It is RECOMMENDED that the MTag is primarily 7163 given in the RTSP response message, to ensure that caches can use the 7164 MTag without requiring content inspection. However, for session 7165 descriptions that are distributed outside of RTSP, for example using 7166 HTTP, etc. it will be necessary to include the message body tag in 7167 the session description as specified in Appendix D.1.9. 7169 SETUP and DESCRIBE requests can be made conditional upon the MTag 7170 using the headers If-Match (Section 18.24) and If-None-Match ( 7171 Section 18.26). 7173 18.32. Notify-Reason 7175 The Notify-Reason response-header is solely used in the PLAY_NOTIFY 7176 method. It indicates the reason why the server has sent the 7177 asynchronous PLAY_NOTIFY request (see Section 13.5). 7179 18.33. Pipelined-Requests 7181 The Pipelined-Requests general-header is used to indicate that a 7182 request is to be executed in the context created by a previous 7183 request(s). The primary usage of this header is to allow pipelining 7184 of SETUP requests so that any additional SETUP request after the 7185 first one does not need to wait for the session ID to be sent back to 7186 the requesting agent. The header contains a unique identifier that 7187 is scoped by the persistent connection used to send the requests. 7189 Upon receiving a request with the Pipelined-Requests the responding 7190 agent MUST look up if there exists a binding between this Pipelined- 7191 Requests identifier for the current persistent connection and an RTSP 7192 session ID. If that exists then the received request is processed 7193 the same way as if it contained the Session header with the found 7194 session ID. If there does not exist a mapping and no Session header 7195 is included in the request, the responding agent MUST create a 7196 binding upon the successful completion of a session creating request, 7197 i.e., SETUP. A binding MUST NOT be created, if the request failed to 7198 create an RTSP session. In case the request contains both a Session 7199 header and the Pipelined-Requests header the Pipelined-Requests MUST 7200 be ignored. 7202 Note: Based on the above definition at least the first request 7203 containing a new unique Pipelined-Requests will be required to be a 7204 SETUP request (unless the protocol is extended with new methods of 7205 creating a session). After that first one, additional SETUP requests 7206 or requests of any type using the RTSP session context may include 7207 the Pipelined-Requests header. 7209 When responding to any request that contained the Pipelined-Requests 7210 header the server MUST also include the Session header when a binding 7211 to a session context exists. An RTSP agent that knows the session 7212 identifier SHOULD NOT use the Pipelined-Requests header in any 7213 request and only use the Session header. This as the Session 7214 identifier is persistent across transport contexts, like TCP 7215 connections, which the Pipelined-Requests identifier is not. 7217 The RTSP agent sending the request with a Pipelined-Requests header 7218 has the responsibility for using a unique and previously unused 7219 identifier within the transport context. Currently only a TCP 7220 connection is defined as such transport context. A server MUST 7221 delete the Pipelined-Requests identifier and its binding to a session 7222 upon the termination of that session. Despite the previous mandate, 7223 RTSP agents are RECOMMENDED to not reuse identifiers to allow for 7224 better error handling and logging. 7226 RTSP Proxies may need to translate Pipelined-Requests identifier 7227 values from incoming requests to outgoing to allow for aggregation of 7228 requests onto a persistent connection. 7230 18.34. Proxy-Authenticate 7232 The Proxy-Authenticate response-header field MUST be included as part 7233 of a 407 (Proxy Authentication Required) response. The field value 7234 consists of a challenge that indicates the authentication scheme and 7235 parameters applicable to the proxy for this Request-URI. 7237 The HTTP access authentication process is described in [RFC2617]. 7238 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 7239 only to the current connection and SHOULD NOT be passed on to 7240 downstream agents. This header MUST only be used in response 7241 messages related to client to server requests. 7243 18.35. Proxy-Authentication-Info 7245 The Proxy-Authentication-Info response-header is used by the proxy to 7246 communicate some information regarding the successful authentication 7247 to the proxy in the message response. The content and usage of this 7248 header is described in the HTTP access authentication [RFC2617] that 7249 is also used by RTSP and clarified in Section 19.1. This header MUST 7250 only be used in response messages related to client to server 7251 requests. This header has hop by hop scope. 7253 18.36. Proxy-Authorization 7255 The Proxy-Authorization request-header field allows the client to 7256 identify itself (or its user) to a proxy which requires 7257 authentication. The Proxy-Authorization field value consists of 7258 credentials containing the authentication information of the user 7259 agent for the proxy and/or realm of the resource being requested. 7261 The HTTP access authentication process is described in [RFC2617]. 7262 Unlike Authorization, the Proxy-Authorization header field applies 7263 only to the next hop proxy. This header MUST only be used in client 7264 to server requests. 7266 18.37. Proxy-Require 7268 The Proxy-Require request-header field is used to indicate proxy- 7269 sensitive features that MUST be supported by the proxy. Any Proxy- 7270 Require header features that are not supported by the proxy MUST be 7271 negatively acknowledged by the proxy to the client using the 7272 Unsupported header. The proxy MUST use the 551 (Option Not 7273 Supported) status code in the response. Any feature-tag included in 7274 the Proxy-Require does not apply to the end-point (server or client). 7275 To ensure that a feature is supported by both proxies and servers the 7276 tag needs to be included in also a Require header. 7278 See Section 18.43 for more details on the mechanics of this message 7279 and a usage example. See discussion in the proxies section 7280 (Section 15.1) about when to consider that a feature requires proxy 7281 support. 7283 Example of use: 7285 Proxy-Require: play.basic 7287 18.38. Proxy-Supported 7289 The Proxy-Supported general-header field enumerates all the 7290 extensions supported by the proxy using feature-tags. The header 7291 carries the intersection of extensions supported by the forwarding 7292 proxies. The Proxy-Supported header MAY be included in any request 7293 by a proxy. It MUST be added by any proxy if the Supported header is 7294 present in a request. When present in a request, the receiver MUST 7295 in the response copy the received Proxy-Supported header. 7297 The Proxy-Supported header field contains a list of feature-tags 7298 applicable to proxies, as described in Section 4.5. The list is the 7299 intersection of all feature-tags understood by the proxies. To 7300 achieve an intersection, the proxy adding the Proxy-Supported header 7301 includes all proxy feature-tags it understands. Any proxy receiving 7302 a request with the header, MUST check the list and removes any 7303 feature-tag(s) it does not support. A Proxy-Supported header present 7304 in the response MUST NOT be modified by the proxies. These feature 7305 tags are the ones the proxy chain support in general, and is not 7306 specific to the request resource. 7308 Example: 7310 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 7311 Supported: foo, bar, blech 7312 User-Agent: PhonyClient/1.2 7314 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 7315 Supported: foo, bar, blech 7316 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 7317 Via: 2.0 pro.example.com 7319 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 7320 Supported: foo, bar, blech 7321 Proxy-Supported: proxy-foo, proxy-blech 7322 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7324 S->C: RTSP/2.0 200 OK 7325 Supported: foo, bar, baz 7326 Proxy-Supported: proxy-foo, proxy-blech 7327 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7328 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7330 18.39. Public 7332 The Public response-header field lists the set of methods supported 7333 by the response sender. This header applies to the general 7334 capabilities of the sender and its only purpose is to indicate the 7335 sender's capabilities to the recipient. The methods listed may or 7336 may not be applicable to the Request-URI; the Allow header field 7337 (Section 18.6) MAY be used to indicate methods allowed for a 7338 particular URI. 7340 Example of use: 7342 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7344 In the event that there are proxies between the sender and the 7345 recipient of a response, each intervening proxy MUST modify the 7346 Public header field to remove any methods that are not supported via 7347 that proxy. The resulting Public header field will contain an 7348 intersection of the sender's methods and the methods allowed through 7349 by the intervening proxies. 7351 In general, proxies should allow all methods to transparently pass 7352 through from the sending RTSP agent to the receiving RTSP agent, 7353 but there may be cases where this is not desirable for a given 7354 proxy. Modification of the Public response-header field by the 7355 intervening proxies ensures that the request sender gets an 7356 accurate response indicating the methods that can be used on the 7357 target agent via the proxy chain. 7359 18.40. Range 7361 The Range general-header specifies a time range in PLAY 7362 (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT 7363 (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and 7364 responses. It MAY be included in GET_PARAMETER requests from the 7365 client to the server with only a Range format and no value to request 7366 the current media position, whether the session is in Play or Ready 7367 state in the included format. The server SHALL, if supporting the 7368 range format, respond with the current playing point or pause point 7369 as the start of the range. If an explicit stop point was used in the 7370 previous PLAY request, then that value shall be included as stop 7371 point. Note that if the server is currently under any type of media 7372 playback manipulation affecting the interpretation of Range, like 7373 Scale, that is also required to be included in any GET_PARAMETER 7374 response to provide complete information. 7376 The range can be specified in a number of units. This specification 7377 defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock 7378 (Section 4.4.3) range units. While octet ranges (Byte Ranges) 7379 [H14.35.1] and other extended units MAY be used, their behavior is 7380 unspecified since they are not normally meaningful in RTSP. Servers 7381 supporting the Range header MUST understand the NPT range format and 7382 SHOULD understand the SMPTE range format. If the Range header is 7383 sent in a time format that is not understood, the recipient SHOULD 7384 return 456 (Header Field Not Valid for Resource) and include an 7385 Accept-Ranges header indicating the supported time formats for the 7386 given resource. 7388 Example: 7390 Range: clock=19960213T143205Z- 7392 The Range header contains a range of one single range format. A 7393 range is a half-open interval with a start and an end point, 7394 including the start point, but excluding the end point. A range may 7395 either be fully specified with explicit values for start point and 7396 end point, or have either start or end point be implicit. An 7397 implicit start point indicates the session's pause point, and if no 7398 pause point is set the start of the content. An implicit end point 7399 indicates the end of the content. The usage of both implicit start 7400 and end point is not allowed in the same range header, however, the 7401 exclusion of the range header has that meaning, i.e., from pause 7402 point (or start) until end of content. 7404 Regarding the half-open intervals; a range of A-B starts exactly 7405 at time A, but ends just before B. Only the start time of a media 7406 unit such as a video or audio frame is relevant. For example, 7407 assume that video frames are generated every 40 ms. A range of 7408 10.0-10.1 would include a video frame starting at 10.0 or later 7409 time and would include a video frame starting at 10.08, even 7410 though it lasted beyond the interval. A range of 10.0-10.08, on 7411 the other hand, would exclude the frame at 10.08. 7413 Please note the difference between NPT time scales' "now" and an 7414 implicit start value. Implicit value reference the current pause- 7415 point. While "now" is the currently ongoing time. In a time- 7416 progressing session with recording (retention for some or full 7417 time) the pause point may be 2 min into the session while now 7418 could be 1 hour into the session. 7420 By default, range intervals increase, where the second point is 7421 larger than the first point. 7423 Example: 7425 Range: npt=10-15 7427 However, range intervals can also decrease if the Scale header (see 7428 Section 18.46) indicates a negative scale value. For example, this 7429 would be the case when a playback in reverse is desired. 7431 Example: 7433 Scale: -1 7434 Range: npt=15-10 7436 Decreasing ranges are still half open intervals as described above. 7437 Thus, for range A-B, A is closed and B is open. In the above 7438 example, 15 is closed and 10 is open. An exception to this rule is 7439 the case when B=0 in a decreasing range. In this case, the range is 7440 closed on both ends, as otherwise there would be no way to reach 0 on 7441 a reverse playback for formats that have such a notion, like NPT and 7442 SMPTE. 7444 Example: 7446 Scale: -1 7447 Range: npt=15-0 7449 In this range both 15 and 0 are closed. 7451 A decreasing range interval without a corresponding negative Scale 7452 header is not valid. 7454 18.41. Referrer 7456 The Referrer request-header field allows the client to specify, for 7457 the server's benefit, the address (URI) of the resource from which 7458 the Request-URI was obtained. The URI refers to that of the 7459 presentation description, typically retrieved via HTTP. The Referrer 7460 request-header allows a server to generate lists of back-links to 7461 resources for interest, logging, optimized caching, etc. It also 7462 allows obsolete or mistyped links to be traced for maintenance. The 7463 Referrer field MUST NOT be sent if the Request-URI was obtained from 7464 a source that does not have its own URI, such as input from the user 7465 keyboard. 7467 If the field value is a relative URI, it SHOULD be interpreted 7468 relative to the Request-URI. The URI MUST NOT include a fragment 7469 identifier. 7471 Because the source of a link might be private information or might 7472 reveal an otherwise private information source, it is strongly 7473 recommended that the user be able to select whether or not the 7474 Referrer field is sent. For example, a streaming client could have a 7475 toggle switch for openly/anonymously, which would respectively enable 7476 /disable the sending of Referrer and From information. 7478 Clients SHOULD NOT include a Referrer header field in a (non-secure) 7479 RTSP request if the referring page was transferred with a secure 7480 protocol. 7482 18.42. Request-Status 7484 This request-header is used to indicate the end result for requests 7485 that take time to complete, such as PLAY (Section 13.4). It is sent 7486 in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report 7487 how the PLAY request concluded, either in success or in failure. The 7488 header carries a reference to the request it reports on using the 7489 CSeq number for the session indicated by the Session header in the 7490 request. It provides both a numerical status code (according to 7491 Section 8.1.1) and a human readable reason phrase. 7493 Example: 7494 Request-Status: cseq=63 status=500 reason="Media data unavailable" 7496 18.43. Require 7498 The Require request-header field is used by agents to ensure that the 7499 other end-point supports features that are required in respect to 7500 this request. It can also be used to query if the other end-point 7501 supports certain features, however, the use of the Supported general- 7502 header (Section 18.51) is much more effective in this purpose. In 7503 case any of the feature-tags listed by the Require header are not 7504 supported by the server or client receiving the request, it MUST 7505 respond to the request using the error code 551 (Option Not 7506 Supported) and include the Unsupported header listing those feature- 7507 tags which are NOT supported. This header does not apply to proxies, 7508 for the same functionality in respect to proxies see Proxy-Require 7509 header (Section 18.37) with the exception of media modifying proxies. 7510 Media modifying proxies, due to their nature of handling media in a 7511 way that is very similar to a server, do need to understand also the 7512 server's features to correctly serve the client. 7514 This is to make sure that the client-server interaction will 7515 proceed without delay when all features are understood by both 7516 sides, and only slow down if features are not understood (as in 7517 the example below). For a well-matched client-server pair, the 7518 interaction proceeds quickly, saving a round-trip often required 7519 by negotiation mechanisms. In addition, it also removes state 7520 ambiguity when the client requires features that the server does 7521 not understand. 7523 Example (Not complete): 7525 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 7526 CSeq: 302 7527 Require: funky-feature 7528 Funky-Parameter: funkystuff 7530 S->C: RTSP/2.0 551 Option not supported 7531 CSeq: 302 7532 Unsupported: funky-feature 7534 In this example, "funky-feature" is the feature-tag which indicates 7535 to the client that the fictional Funky-Parameter field is required. 7536 The relationship between "funky-feature" and Funky-Parameter is not 7537 communicated via the RTSP exchange, since that relationship is an 7538 immutable property of "funky-feature" and thus should not be 7539 transmitted with every exchange. 7541 Proxies and other intermediary devices MUST ignore this header. If a 7542 particular extension requires that intermediate devices support it, 7543 the extension should be tagged in the Proxy-Require field instead 7544 (see Section 18.37). See discussion in the proxies section 7545 (Section 15.1) about when to consider that a feature requires proxy 7546 support. 7548 18.44. Retry-After 7550 The Retry-After response-header field can be used with a 503 (Service 7551 Unavailable) or 553 (Proxy Unavailable) response to indicate how long 7552 the service is expected to be unavailable to the requesting client. 7553 This field MAY also be used with any 3rr (Redirection) response to 7554 indicate the minimum time the user-agent is asked to wait before 7555 issuing the redirected request. The value of this field can be 7556 either an RTSP-date or an integer number of seconds (in decimal) 7557 after the time of the response. 7559 Example: 7561 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 7562 Retry-After: 120 7564 In the latter example, the delay is 2 minutes. 7566 18.45. RTP-Info 7568 The RTP-Info general-header field is used to set RTP-specific 7569 parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY 7570 and GET_PARAMETER requests. For streams using RTP as transport 7571 protocol the RTP-Info header SHOULD be part of a 200 response to 7572 PLAY. 7574 The exclusion of the RTP-Info in a PLAY response for RTP 7575 transported media will result in a client needing to synchronize 7576 the media streams using RTCP. This may have negative impact as 7577 the RTCP can be lost, and does not need to be particularly timely 7578 in its arrival. Also functionality that informs the client from 7579 which packet a seek has occurred is affected. 7581 The RTP-Info MAY be included in SETUP responses to provide 7582 synchronization information when changing transport parameters, see 7583 Section 13.3. The RTP-Info header and the Range header MAY be 7584 included in a GET_PARAMETER request from client to server without any 7585 values to request the current playback point and corresponding RTP 7586 synchronization information. When the RTP-Info header is included in 7587 a Request the Range header MUST also be included (Note, Range header 7588 only MAY be used). The server response SHALL include both the Range 7589 header and the RTP-Info header. If the session is in Play state, 7590 then the value of the Range header SHALL be filled in with the 7591 current playback point and with the corresponding RTP-Info values. 7592 If the server is another state, no values are included in the RTP- 7593 Info header. The header is included in PLAY_NOTIFY requests with the 7594 Notify-Reason of end-of-stream to provide RTP information about the 7595 end of the stream. 7597 The header can carry the following parameters: 7599 url: Indicates the stream URI for which the following RTP parameters 7600 correspond, this URI MUST be the same as used in the SETUP 7601 request for this media stream. Any relative URI MUST use the 7602 Request-URI as base URI. This parameter MUST be present. 7604 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 7605 sequence number provided applies to. This parameter MUST be 7606 present. 7608 seq: Indicates the sequence number of the first packet of the stream 7609 that is direct result of the request. This allows clients to 7610 gracefully deal with packets when seeking. The client uses 7611 this value to differentiate packets that originated before the 7612 seek from packets that originated after the seek. Note that a 7613 client may not receive the packet with the expressed sequence 7614 number, and instead packets with a higher sequence number, due 7615 to packet loss or reordering. This parameter is RECOMMENDED to 7616 be present. 7618 rtptime: MUST indicate the RTP timestamp value corresponding to the 7619 start time value in the Range response-header, or if not 7620 explicitly given the implied start point. The client uses this 7621 value to calculate the mapping of RTP time to NPT or other 7622 media timescale. This parameter SHOULD be present to ensure 7623 inter-media synchronization is achieved. There exists no 7624 requirement that any received RTP packet will have the same RTP 7625 timestamp value as the one in the parameter used to establish 7626 synchronization. 7628 A mapping from RTP timestamps to Network Time Protocol (NTP) 7629 format timestamps (wallclock) is available via RTCP. However, 7630 this information is not sufficient to generate a mapping from RTP 7631 timestamps to media clock time (NPT, etc.). Furthermore, in order 7632 to ensure that this information is available at the necessary time 7633 (immediately at startup or after a seek), and that it is delivered 7634 reliably, this mapping is placed in the RTSP control channel. 7636 In order to compensate for drift for long, uninterrupted 7637 presentations, RTSP clients should additionally map NPT to NTP, 7638 using initial RTCP sender reports to do the mapping, and later 7639 reports to check drift against the mapping. 7641 Example: 7643 Range:npt=3.25-15 7644 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 7645 rtptime=12345678,url="rtsp://example.com/foo/video" 7646 ssrc=9A9DE123:seq=30211;rtptime=29567112 7648 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video 7649 a 90kHz RTP timestamp clock. Then the media synchronization is 7650 depicted in the following way. 7652 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 7653 Audio PA A 7654 Video V PV 7656 X: NPT time value = 3.25, from Range header. 7657 A: RTP timestamp value for Audio from RTP-Info header (12345678). 7658 V: RTP timestamp value for Video from RTP-Info header (29567112). 7659 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 7660 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 7661 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 7662 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 7664 18.46. Scale 7666 The Scale general-header indicates the requested or used view rate 7667 for the media resource being played back. A scale value of 1 7668 indicates normal play at the normal forward viewing rate. If not 1, 7669 the value corresponds to the rate with respect to normal viewing 7670 rate. For example, a ratio of 2 indicates twice the normal viewing 7671 rate ("fast forward") and a ratio of 0.5 indicates half the normal 7672 viewing rate. In other words, a ratio of 2 has content time increase 7673 at twice the playback time. For every second of elapsed (wallclock) 7674 time, 2 seconds of content time will be delivered. A negative value 7675 indicates reverse direction. For certain media transports this may 7676 require certain considerations to work consistent, see Appendix C.1 7677 for description on how RTP handles this. 7679 The transmitted data rate SHOULD NOT be changed by selection of a 7680 different scale value. The resulting bit-rate should be reasonably 7681 close to the nominal bit-rate of the content for Scale = 1. The 7682 server has to actively manipulate the data when needed to meet the 7683 bitrate constraints. Implementation of scale changes depends on the 7684 server and media type. For video, a server may, for example, deliver 7685 only key frames or selected frames. For audio, it may time-scale the 7686 audio while preserving pitch or, less desirably, deliver fragments of 7687 audio, or completely mute the audio. 7689 The server and content may restrict the range of scale values that it 7690 supports. The supported values are indicated by the Media-Properties 7691 header (Section 18.29). The client SHOULD only indicate request 7692 values to be supported. However, as the values may change as the 7693 content progresses a requested value may no longer be valid when the 7694 request arrives. Thus, a non-supported value in a request does not 7695 generate an error, only forces the server to choose the closest 7696 value. The response MUST always contain the actual scale value 7697 chosen by the server. 7699 If the server does not implement the possibility to scale, it will 7700 not return a Scale header. A server supporting Scale operations for 7701 PLAY MUST indicate this with the use of the "play.scale" feature-tag. 7703 When indicating a negative scale for a reverse playback, the Range 7704 header MUST indicate a decreasing range as described in 7705 Section 18.40. 7707 Example of playing in reverse at 3.5 times normal rate: 7709 Scale: -3.5 7710 Range: npt=15-10 7712 18.47. Seek-Style 7714 When a client sends a PLAY request with a Range header to perform a 7715 random access to the media, the client does not know if the server 7716 will pick the first media samples or the first random access point 7717 prior to the request range. Depending on use case, the client may 7718 have a strong preference. To express this preference and provide the 7719 client with information on how the server actually acted on that 7720 preference the Seek-Style general-header is defined. 7722 Seek-Style is a general-header that MAY be included in any PLAY 7723 request to indicate the client's preference for any media stream that 7724 has random access properties. The server MUST always include the 7725 header in any PLAY response for media with random access properties 7726 to indicate what policy was applied. A server that receives an 7727 unknown Seek-Style policy MUST ignore it and select the server 7728 default policy. A client receiving an unknown policy MUST ignore it 7729 and use the Range header and any media synchronization information as 7730 basis to determine what the server did. 7732 This specification defines the following seek policies that may be 7733 requested (see also Section 4.7.1): 7735 RAP: Random Access Point (RAP) is the behavior of requesting the 7736 server to locate the closest previous random access point that 7737 exists in the media aggregate and deliver from that. By 7738 requesting a RAP, media quality will be the best possible as all 7739 media will be delivered from a point where full media state can be 7740 established in the media decoder. 7742 CoRAP: Conditional Random Access Point (CoRAP) is a variant of the 7743 above RAP behavior. This policy is primarily intended for cases 7744 where there is larger distance between the random access points in 7745 the media. CoRAP is conditioned on that there is a Random Access 7746 Point closer to the requested start point than to the current 7747 pause point. This policy assumes that the media state existing 7748 prior to the pause is usable if delivery is continued. If the 7749 client or server knows that this is not the fact the RAP policy 7750 should be used. In other words: in most cases when the client 7751 requests a start point prior to the current pause point, a valid 7752 decoding dependency chain from the media delivered prior to the 7753 pause and to the requested media unit will not exist. If the 7754 server searched to a random access point the server MUST return 7755 the CoRAP policy in the Seek-Style header and adjust the Range 7756 header to reflect the position of the picked RAP. In case the 7757 random access point is further away and the server selects to 7758 continue from the current pause point it MUST include the "Next" 7759 policy in the Seek-Style header and adjust the Range header start 7760 point to the current pause point. 7762 First-Prior: The first-prior policy will start delivery with the 7763 media unit that has a playout time first prior to the requested 7764 time. For discrete media that would only include media units that 7765 would still be rendered at the request time. For continuous media 7766 that is media that will be rendered during the requested start 7767 time of the range. 7769 Next: The next media units after the provided start time of the 7770 range. For continuous framed media that would mean the first next 7771 frame after the provided time. For discrete media the first unit 7772 that is to be rendered after the provided time. The main usage 7773 for this case is when the client knows it has all media up to a 7774 certain point and would like to continue delivery so that a 7775 complete non-interrupted media playback can be achieved. Example 7776 of such scenarios include switching from a broadcast/multicast 7777 delivery to a unicast based delivery. This policy MUST only be 7778 used on the client's explicit request. 7780 Please note that these expressed preferences exist for optimizing the 7781 startup time or the media quality. The "Next" policy breaks the 7782 normal definition of the Range header to enable a client to request 7783 media with minimal overlap, although some may still occur for 7784 aggregated sessions. RAP and First-Prior both fulfill the 7785 requirement of providing media from the requested range and forward. 7786 However, unless RAP is used, the media quality for many media codecs 7787 using predictive methods can be severely degraded unless additional 7788 data is available as, for example, already buffered, or through other 7789 side channels. 7791 18.48. Server 7793 The Server general-header field contains information about the 7794 software used by the origin server to create or handle the request. 7795 The field can contain multiple product tokens and comments 7796 identifying the server and any significant subproducts. The product 7797 tokens are listed in order of their significance for identifying the 7798 application. 7800 Example: 7802 Server: PhonyServer/1.0 7804 If the response is being forwarded through a proxy, the proxy 7805 application MUST NOT modify the Server response-header. Instead, it 7806 SHOULD include a Via field (Section 18.57). If the response is 7807 generated by the proxy, the proxy application MUST return the Server 7808 response-header as previously returned by the server. 7810 18.49. Session 7812 The Session general-header field identifies an RTSP session. An RTSP 7813 session is created by the server as a result of a successful SETUP 7814 request and in the response the session identifier is given to the 7815 client. The RTSP session exists until destroyed by a TEARDOWN, 7816 REDIRECT or timed out by the server. 7818 The session identifier is chosen by the server (see Section 4.3) and 7819 MUST be returned in the SETUP response. Once a client receives a 7820 session identifier, it MUST be included in any request related to 7821 that session. This means that the Session header MUST be included in 7822 a request, using the following methods: PLAY, PAUSE, and TEARDOWN, 7823 and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, 7824 and REDIRECT, and MUST NOT be included in DESCRIBE. The Session 7825 header MUST NOT be included in the following methods, if these 7826 requests are pipelined and if the session identifier is not yet 7827 known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and 7828 GET_PARAMETER. 7830 In an RTSP response the session header MUST be included in methods, 7831 SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and 7832 REDIRECT, and if included in the request of the following methods it 7833 MUST also be included in the response, OPTIONS, GET_PARAMETER, and 7834 SET_PARAMETER, and MUST NOT be included in DESCRIBE responses. 7836 Note that a session identifier identifies an RTSP session across 7837 transport sessions or connections. RTSP requests for a given session 7838 can use different URIs (Presentation and media URIs). Note, that 7839 there are restrictions depending on the session which URIs that are 7840 acceptable for a given method. However, multiple "user" sessions for 7841 the same URI from the same client will require use of different 7842 session identifiers. 7844 The session identifier is needed to distinguish several delivery 7845 requests for the same URI coming from the same client. 7847 The response 454 (Session Not Found) MUST be returned if the session 7848 identifier is invalid. 7850 The header MAY include a parameter for session timeout period. If 7851 not explicitly provided this value is set to 60 seconds. As this 7852 affects how often session keep-alives are needed values smaller than 7853 30 seconds are not recommended. However, larger than default values 7854 can be useful in applications of RTSP that have inactive but 7855 established sessions for longer time periods. 7857 60 seconds was chosen as session timeout value due to: Resulting 7858 in not too frequent keep-alive messages and having low sensitivity 7859 to variations in request response timing. If one reduces the 7860 timeout value to below 30 seconds the corresponding request 7861 response timeout becomes a significant part of the session 7862 timeout. 60 seconds also allows for reasonably rapid recovery of 7863 committed server resources in case of client failure. 7865 18.50. Speed 7867 The Speed general-header field requests the server to deliver 7868 specific amounts of nominal media time per unit of delivery time, 7869 contingent on the server's ability and desire to serve the media 7870 stream at the given speed. The client requests the delivery speed to 7871 be within a given range with a lower and upper bound. The server 7872 SHALL deliver at the highest possible speed within the range, but not 7873 faster than the upper-bound, for which the underlying network path 7874 can support the resulting transport data rates. As long as any speed 7875 value within the given range can be provided the server SHALL NOT 7876 modify the media quality. Only if the server is unable to deliver 7877 media at the speed value provided by the lower bound shall it reduce 7878 the media quality. 7880 Implementation of the Speed functionality by the server is OPTIONAL. 7881 The server can indicate its support through a feature-tag, 7882 play.speed. The lack of a Speed header in the response is an 7883 indication of lack of support of this functionality. 7885 The speed parameter values are expressed as a positive decimal value, 7886 e.g., a value of 2.0 indicates that data is to be delivered twice as 7887 fast as normal. A speed value of zero is invalid. The range is 7888 specified in the form "lower bound - upper bound". The lower bound 7889 value may be smaller or equal to the upper bound. All speeds may not 7890 be possible to support. Therefore the server MAY modify the 7891 requested values to the closest supported. The actual supported 7892 speed MUST be included in the response. Note, however, that the use 7893 cases may vary and that Speed value ranges such as 0.7 - 0.8, 7894 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 7896 Example: 7898 Speed: 1.0-2.5 7900 Use of this header changes the bandwidth used for data delivery. It 7901 is meant for use in specific circumstances where delivery of the 7902 presentation at a higher or lower rate is desired. The main use 7903 cases are buffer operations or local scale operations. Implementors 7904 should keep in mind that bandwidth for the session may be negotiated 7905 beforehand (by means other than RTSP), and therefore re-negotiation 7906 may be necessary. To perform Speed operations the server needs to 7907 ensure that the network path can support the resulting bit-rate. 7908 Thus the media transport needs to support feedback so that the server 7909 can react and adapt to the available bitrate. 7911 18.51. Supported 7913 The Supported general-header enumerates all the extensions supported 7914 by the client or server using feature tags. The header carries the 7915 extensions supported by the message sending client or server. The 7916 Supported header MAY be included in any request. When present in a 7917 request, the receiver MUST respond with its corresponding Supported 7918 header. Note that the Supported header is also included in 4xx and 7919 5xx responses. 7921 The Supported header contains a list of feature-tags, described in 7922 Section 4.5, that are understood by the client or server. These 7923 feature tags are the ones the server or client support in general, 7924 and is not specific to the request resource. 7926 Example: 7928 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 7929 Supported: foo, bar, blech 7930 User-Agent: PhonyClient/1.2 7932 S->C: RTSP/2.0 200 OK 7933 Supported: bar, blech, baz 7935 18.52. Terminate-Reason 7937 The Terminate-Reason request-header allows the server when sending a 7938 REDIRECT or TEARDOWN request to provide a reason for the session 7939 termination and any additional information. This specification 7940 identifies three reasons for Redirections and may be extended in the 7941 future: 7943 Server-Admin: The server needs to be shutdown for some 7944 administrative reason. 7946 Session-Timeout: A client's session has been kept alive for extended 7947 periods of time and the server has determined that it needs to 7948 reclaim the resources associated with this session. 7950 Internal-Error An internal error that is impossible to recover from 7951 has occurred forcing the server to terminate the session. 7953 The Server may provide additional parameters containing information 7954 around the redirect. This specification defines the following ones. 7956 time: Provides a wallclock time when the server will stop providing 7957 any service. 7959 user-msg: An UTF-8 text string with a message from the server to the 7960 user. This message SHOULD be displayed to the user. 7962 18.53. Timestamp 7964 The Timestamp general-header describes when the agent sent the 7965 request. The value of the timestamp is of significance only to the 7966 agent and may use any timescale. The responding agent MUST echo the 7967 exact same value and MAY, if it has accurate information about this, 7968 add a floating point number indicating the number of seconds that has 7969 elapsed since it has received the request. The timestamp can be used 7970 by the agent to compute the round-trip time to the responding agent 7971 so that it can adjust the timeout value for retransmissions when 7972 running over an unreliable protocol. It also resolves retransmission 7973 ambiguities for unreliable transport of RTSP. 7975 Note that the present specification provides only for reliable 7976 transport of RTSP messages. The Timestamp general-header is 7977 specified in case the protocol is extended in the future to use 7978 unreliable transport. 7980 18.54. Transport 7982 The Transport general-header indicates which transport protocol is to 7983 be used and configures its parameters such as destination address, 7984 compression, multicast time-to-live and destination port for a single 7985 stream. It sets those values not already determined by a 7986 presentation description. 7988 A Transport request-header MAY contain a list of transport options 7989 acceptable to the client, in the form of multiple transport 7990 specification entries. Transport specifications are comma separated, 7991 listed in decreasing order of preference. Each transport 7992 specification consists of a transport protocol identifier, followed 7993 by any number of parameters, each parameter separated by a semicolon. 7994 A Transport request-header MAY contain multiple transport 7995 specifications using the same transport protocol Identifier. The 7996 server MUST return a Transport response-header in the response to 7997 indicate the values actually chosen if any. If no transport 7998 specification is supported, no transport header is returned and the 7999 response MUST use the status code 461 (Unsupported Transport) 8000 (Section 17.4.26). In case more than one transport specification was 8001 present in the request, the server MUST return the single transport 8002 specification (transport-spec) which was actually chosen, if any. 8003 The number of transport-spec entries is expected to be limited as the 8004 client will receive guidance on what configurations that are possible 8005 from the presentation description. 8007 The Transport header MAY also be used in subsequent SETUP requests to 8008 change transport parameters. A server MAY refuse to change 8009 parameters of an existing stream. 8011 The transport protocol identifier defines for each transport 8012 specification which transport protocol to use and any related rules. 8013 Each transport protocol identifier defines the parameters that are 8014 required to occur; additional optional parameters MAY occur. This 8015 flexibility is provided as parameters may be different and provide 8016 different options to the RTSP Agent. A transport specification may 8017 only contain one of any given parameter within it. A parameter 8018 consists of a name and optionally a value string. Parameters MAY be 8019 given in any order. Additionally, a transport specification may only 8020 contain either of the unicast or the multicast transport type 8021 parameter. The transport protocol identifier and all parameters need 8022 to be understood in a transport specification; if not, the transport 8023 specification MUST be ignored. An RTSP proxy of any type that uses 8024 or modifies the transport specification, e.g., access proxy or 8025 security proxy, MUST remove specifications with unknown parameters 8026 before forwarding the RTSP message. If that results in no remaining 8027 transport specification the proxy SHALL send a 461 (Unsupported 8028 Transport) (Section 17.4.26) response without any Transport header. 8030 The Transport header is restricted to describing a single media 8031 stream. (RTSP can also control multiple streams as a single 8032 entity.) Making it part of RTSP rather than relying on a 8033 multitude of session description formats greatly simplifies 8034 designs of firewalls. 8036 The general syntax for the transport protocol identifier is a list of 8037 slash separated tokens: 8039 Value1/Value2/Value3... 8041 Which for RTP transports take the form: 8043 RTP/profile/lower-transport. 8045 The default value for the "lower-transport" parameters is specific to 8046 the profile. For RTP/AVP, the default is UDP. 8048 There are two different methods for how to specify where the media 8049 should be delivered for unicast transport: 8051 dest_addr: The presence of this parameter and its values indicates 8052 the destination address or addresses (host address and port 8053 pairs for IP flows) necessary for the media transport. 8055 No dest_addr: The lack of the dest_addr parameter indicates that the 8056 server MUST send media to the same address from which the RTSP 8057 messages originates. 8059 The choice of method for indicating where the media is to be 8060 delivered depends on the use case. In some cases the only allowed 8061 method will be to use no explicit address indication and have the 8062 server deliver media to the source of the RTSP messages. 8064 For Multicast there is several methods for specifying addresses but 8065 they are different in how they work compared with unicast: 8067 dest_addr with client picked address: The address and relevant 8068 parameters, like TTL (scope), for the actual multicast group to 8069 deliver the media to. There are security implications 8070 (Section 21) with this method that need to be addressed if 8071 using this method because a RTSP server can be used as a Denial 8072 of Service (DoS) attacker on an existing multicast group. 8074 dest_addr using Session Description Information: The information 8075 included in the transport header can all be coming from the 8076 session description, e.g., the SDP c= and m= line. This 8077 mitigates some of the security issues of the previous methods 8078 as it is the session provider that picks the multicast group 8079 and scope. The client MUST include the information if it is 8080 available in the session description. 8082 No dest_addr: The behavior when no explicit multicast group is 8083 present in a request is not defined. 8085 An RTSP proxy will need to take care. If the media is not desired to 8086 be routed through the proxy, the proxy will need to introduce the 8087 destination indication. 8089 Below are the configuration parameters associated with transport: 8091 General parameters: 8093 unicast / multicast: This parameter is a mutually exclusive 8094 indication of whether unicast or multicast delivery will be 8095 attempted. One of the two values MUST be specified. Clients 8096 that are capable of handling both unicast and multicast 8097 transmission need to indicate such capability by including two 8098 full transport-specs with separate parameters for each. 8100 layers: The number of multicast layers to be used for this media 8101 stream. The layers are sent to consecutive addresses starting 8102 at the dest_addr address. If the parameter is not included, it 8103 defaults to a single layer. 8105 dest_addr: A general destination address parameter that can contain 8106 one or more address specifications. Each combination of 8107 protocol/profile/lower transport needs to have the format and 8108 interpretation of its address specification defined. For RTP/ 8109 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8110 containing a host address and port. Note, only a single 8111 destination parameter per transport spec is intended. The 8112 usage of multiple destinations to distribute a single media to 8113 multiple entities is unspecified. 8115 The client originating the RTSP request MAY specify the 8116 destination address of the stream recipient with the host 8117 address part of the tuple. When the destination address is 8118 specified, the recipient may be a different party than the 8119 originator of the request. To avoid becoming the unwitting 8120 perpetrator of a remote-controlled denial-of-service attack, a 8121 server MUST perform security checks (see Section 21.2.1) and 8122 SHOULD log such attempts before allowing the client to direct a 8123 media stream to a recipient address not chosen by the server. 8124 Implementations cannot rely on TCP as reliable means of client 8125 identification. If the server does not allow the host address 8126 part of the tuple to be set, it MUST return 463 (Destination 8127 Prohibited). 8129 The host address part of the tuple MAY be empty, for example 8130 ":58044", in cases when it is desired to specify only the 8131 destination port. Responses to requests including the 8132 Transport header with a dest_addr parameter SHOULD include the 8133 full destination address that is actually used by the server. 8134 The server MUST NOT remove address information present already 8135 in the request when responding unless the protocol requires it. 8137 src_addr: A general source address parameter that can contain one or 8138 more address specifications. Each combination of protocol/ 8139 profile/lower transport needs to have the format and 8140 interpretation of its address specification defined. For RTP/ 8141 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8142 containing a host address and port. 8144 This parameter MUST be specified by the server if it transmits 8145 media packets from another address than the one RTSP messages 8146 are sent to. This will allow the client to verify source 8147 address and give it a destination address for its RTCP feedback 8148 packets, if RTP is used. The address or addresses indicated in 8149 the src_addr parameter SHOULD be used both for sending and 8150 receiving of the media stream's data packets. The main reasons 8151 are threefold: First, indicating the port and source address(s) 8152 lets the receiver know where from the packets is expected to 8153 originate. Secondly, traversal of NATs is greatly simplified 8154 when traffic is flowing symmetrically over a NAT binding. 8155 Thirdly, certain NAT traversal mechanisms, needs to know to 8156 which address and port to send so called "binding packets" from 8157 the receiver to the sender, thus creating an address binding in 8158 the NAT that the sender to receiver packet flow can use. 8160 This information may also be available through SDP. 8161 However, since this is more a feature of transport than 8162 media initialization, the authoritative source for this 8163 information should be in the SETUP response. 8165 mode: The mode parameter indicates the methods to be supported for 8166 this session. Currently defined valid values are "PLAY". If 8167 not provided, the default is "PLAY". The "RECORD" value was 8168 defined in RFC 2326 and is in this specification unspecified 8169 but reserved. RECORD and other values may be specified in the 8170 future. 8172 interleaved: The interleaved parameter implies mixing the media 8173 stream with the control stream in whatever protocol is being 8174 used by the control stream, using the mechanism defined in 8175 Section 14. The argument provides the channel number to be 8176 used in the $ block (see Section 14) and MUST be present. This 8177 parameter MAY be specified as an interval, e.g., 8178 interleaved=4-5 in cases where the transport choice for the 8179 media stream requires it, e.g., for RTP with RTCP. The channel 8180 number given in the request is only a guidance from the client 8181 to the server on what channel number(s) to use. The server MAY 8182 set any valid channel number in the response. The declared 8183 channel(s) are bi-directional, so both end-parties MAY send 8184 data on the given channel. One example of such usage is the 8185 second channel used for RTCP, where both server and client send 8186 RTCP packets on the same channel. 8188 This allows RTP/RTCP to be handled similarly to the way that 8189 it is done with UDP, i.e., one channel for RTP and the other 8190 for RTCP. 8192 MIKEY: This parameter is used in conjunction with transport 8193 specifications that can utilize MIKEY [RFC3830] for security 8194 context establishment. So far only the SRTP based RTP profiles 8195 SAVP and SAVPF can utilize MIKEY and this is defined in 8196 Appendix C.1.4.1. This parameter can be included both in 8197 request and response messages. The binary MIKEY message SHALL 8198 be BASE64 [RFC4648] encoded before being included in the value 8199 part of the parameter, where the encoding adheres to the 8200 definition in Section 4 of RFC 4648 and where the padding bits 8201 are set to zero. 8203 Multicast-specific: 8205 ttl: multicast time-to-live for IPv4. When included in requests the 8206 value indicate the TTL value that the client requests the 8207 server to use. In a response, the value actually being used by 8208 the server is returned. A server will need to consider what 8209 values that are reasonable and also the authority of the user 8210 to set this value. Corresponding functions are not needed for 8211 IPv6 as the scoping is part of the IPv6 multicast address 8212 [RFC4291]. 8214 RTP-specific: 8216 These parameters MAY only be used if the media transport protocol is 8217 RTP. 8219 ssrc: The ssrc parameter, if included in a SETUP response, indicates 8220 the RTP SSRC [RFC3550] value(s) that will be used by the media 8221 server for RTP packets within the stream. It is expressed as 8222 an eight digit hexadecimal value. 8224 The ssrc parameter MUST NOT be specified in requests. The 8225 functionality of specifying the ssrc parameter in a SETUP 8226 request is deprecated as it is incompatible with the 8227 specification of RTP in RFC 3550[RFC3550]. If the parameter is 8228 included in the Transport header of a SETUP request, the server 8229 SHOULD ignore it, and choose appropriate SSRCs for the stream. 8230 The server SHOULD set the ssrc parameter in the Transport 8231 header of the response. 8233 RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing 8234 [RFC5761] on a single underlying transport stream / flow. The 8235 presence of this parameter in a SETUP request indicates the 8236 client's support and requires the server to use RTP and RTCP 8237 multiplexing. The client SHALL only include one transport 8238 stream in the Transport header specification. To provide the 8239 server with a choice between using RTP/RTCP multiplexing or 8240 not, two different transport header specifications must be 8241 included. 8243 The parameters setup and connection defined below MAY only be used if 8244 the media transport protocol of the lower-level transport is 8245 connection-oriented (such as TCP). However, these parameters MUST 8246 NOT be used when interleaving data over the RTSP connection. 8248 setup: Clients use the setup parameter on the Transport line in a 8249 SETUP request, to indicate the roles it wishes to play in a TCP 8250 connection. This parameter is adapted from [RFC4145]. The use 8251 of this parameter in RTP/AVP/TCP non-interleaved transport is 8252 discussed in Appendix C.2.2; the discussion below is limited to 8253 syntactic issues. Clients may specify the following values for 8254 the setup parameter: 8256 active: The client will initiate an outgoing connection. 8258 passive: The client will accept an incoming connection. 8260 actpass: The client is willing to accept an incoming 8261 connection or to initiate an outgoing connection. 8263 If a client does not specify a setup value, the "active" value 8264 is assumed. 8266 In response to a client SETUP request where the setup parameter 8267 is set to "active", a server's 2xx reply MUST assign the setup 8268 parameter to "passive" on the Transport header line. 8270 In response to a client SETUP request where the setup parameter 8271 is set to "passive", a server's 2xx reply MUST assign the setup 8272 parameter to "active" on the Transport header line. 8274 In response to a client SETUP request where the setup parameter 8275 is set to "actpass", a server's 2xx reply MUST assign the setup 8276 parameter to "active" or "passive" on the Transport header 8277 line. 8279 Note that the "holdconn" value for setup is not defined for 8280 RTSP use, and MUST NOT appear on a Transport line. 8282 connection: Clients use the connection parameter in a transport 8283 specification part of the Transport header in a SETUP request, 8284 to indicate the client's preference for either reusing an 8285 existing connection between client and server (in which case 8286 the client sets the "connection" parameter to "existing"), or 8287 requesting the creation of a new connection between client and 8288 server (in which cast the client sets the "connection" 8289 parameter to "new"). Typically, clients use the "new" value 8290 for the first SETUP request for a URL, and "existing" for 8291 subsequent SETUP requests for a URL. 8293 If a client SETUP request assigns the "new" value to 8294 "connection", the server response MUST also assign the "new" 8295 value to "connection" on the Transport line. 8297 If a client SETUP request assigns the "existing" value to 8298 "connection", the server response MUST assign a value of 8299 "existing" or "new" to "connection" on the Transport line, at 8300 its discretion. 8302 The default value of "connection" is "existing", for all SETUP 8303 requests (initial and subsequent). 8305 The combination of transport protocol, profile and lower transport 8306 needs to be defined. A number of combinations are defined in the 8307 Appendix C. 8309 Below is a usage example, showing a client advertising the capability 8310 to handle multicast or unicast, preferring multicast. Since this is 8311 a unicast-only stream, the server responds with the proper transport 8312 parameters for unicast. 8314 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 8315 CSeq: 302 8316 Transport: RTP/AVP;multicast;mode="PLAY", 8317 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8318 "192.0.2.5:3457";mode="PLAY" 8319 Accept-Ranges: npt, smpte, clock 8320 User-Agent: PhonyClient/1.2 8322 S->C: RTSP/2.0 200 OK 8323 CSeq: 302 8324 Date: Fri, 20 Dec 2013 10:20:32 +0000 8325 Session: 47112344 8326 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8327 "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ 8328 "192.0.2.224:6257";mode="PLAY" 8329 Accept-Ranges: npt 8330 Media-Properties: Random-Access=0.6, Dynamic, 8331 Time-Limited=20081128T165900 8333 18.55. Unsupported 8335 The Unsupported response-header lists the features not supported by 8336 the responding RTSP agent. In the case where the feature was 8337 specified via the Proxy-Require field (Section 18.37), if there is a 8338 proxy on the path between the client and the server, the proxy MUST 8339 send a response message with a status code of 551 (Option Not 8340 Supported). The request MUST NOT be forwarded. 8342 See Section 18.43 for a usage example. 8344 18.56. User-Agent 8346 The User-Agent general-header field contains information about the 8347 user agent originating the request or producing a response. This is 8348 for statistical purposes, the tracing of protocol violations, and 8349 automated recognition of user agents for the sake of tailoring 8350 responses to avoid particular user agent limitations. User agents 8351 SHOULD include this field with requests. The field can contain 8352 multiple product tokens and comments identifying the agent and any 8353 subproducts which form a significant part of the user agent. By 8354 convention, the product tokens are listed in order of their 8355 significance for identifying the application. 8357 Example: 8359 User-Agent: PhonyClient/1.2 8361 18.57. Via 8363 The Via general-header field MUST be used by proxies to indicate the 8364 intermediate protocols and recipients between the user agent and the 8365 server on requests, and between the origin server and the client on 8366 responses. The field is intended to be used for tracking message 8367 forwards, avoiding request loops, and identifying the protocol 8368 capabilities of all senders along the request/response chain. 8370 Multiple Via field values represents each proxy that has forwarded 8371 the message. Each recipient MUST append its information such that 8372 the end result is ordered according to the sequence of forwarding 8373 applications. 8375 Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by 8376 default, forward the names and ports of hosts within the private/ 8377 protected region. This information SHOULD only be propagated if 8378 explicitly enabled. If not enabled, the via-received of any host 8379 behind the firewall/NAT SHOULD be replaced by an appropriate 8380 pseudonym for that host. 8382 For organizations that have strong privacy requirements for hiding 8383 internal structures, a proxy MAY combine an ordered subsequence of 8384 Via header field entries with identical sent-protocol values into a 8385 single such entry. Applications MUST NOT combine entries which have 8386 different received-protocol values. 8388 18.58. WWW-Authenticate 8390 The WWW-Authenticate response-header field MUST be included in 401 8391 (Unauthorized) response messages. The field value consists of at 8392 least one challenge that indicates the authentication scheme(s) and 8393 parameters applicable to the Request-URI. This header MUST only be 8394 used in response messages related to client to server requests. 8396 The HTTP access authentication process is described in [RFC2617] with 8397 some clarification in Section 19.1. User agents are advised to take 8398 special care in parsing the WWW-Authenticate field value as it might 8399 contain more than one challenge, or if more than one WWW-Authenticate 8400 header field is provided, the contents of a challenge itself can 8401 contain a comma-separated list of authentication parameters. 8403 19. Security Framework 8405 The RTSP security framework consists of two high level components: 8406 the pure authentication mechanisms based on HTTP authentication, and 8407 the message transport protection based on TLS, which is independent 8408 of RTSP. Because of the similarity in syntax and usage between RTSP 8409 servers and HTTP servers, the security for HTTP is re-used to a large 8410 extent. 8412 19.1. RTSP and HTTP Authentication 8414 RTSP and HTTP share common authentication schemes, and thus follow 8415 the same usage guidelines as specified in [RFC2617] with the 8416 additions for digest authentication specified below in 8417 Section 19.1.1. Servers SHOULD implement both basic and digest 8418 [RFC2617] authentication. Clients MUST implement both basic and 8419 digest authentication [RFC2617] so that a server that requires the 8420 client to authenticate can trust that the capability is present. 8422 It should be stressed that using the HTTP authentication alone does 8423 not provide full control message security. Therefore, in 8424 environments requiring tighter security for the control messages, TLS 8425 SHOULD be used, see Section 19.2. Any RTSP message containing an 8426 Authorization header using basic authorization MUST be using a TLS 8427 connection with confidentiality protection enabled, i.e., no NULL 8428 encryption. 8430 In cases where there is a chain of proxies between the client and the 8431 server, each proxy may individually request the client or previous 8432 proxy to authenticate itself. This is done using the Proxy- 8433 Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36) 8434 and the Proxy-Authentication-Info (Section 18.35) headers. These 8435 headers are hop-by-hop headers and are only scoped to the current 8436 connection and hop. Thus if a proxy chain exists, a proxy connecting 8437 to another proxy will have to act as a client to authorize itself 8438 towards the next proxy. The WWW-Authenticate (Section 18.58), 8439 Authorization (Section 18.8) and Authentication-Info (Section 18.7) 8440 headers are end-to-end and must not be modified by proxies. 8442 This authentication mechanism works only for client to server 8443 requests as currently defined. This leaves server to client request 8444 outside of the context of TLS based communication more vulnerable to 8445 message injection attacks on the client. Based on the server to 8446 client methods that exist, the potential risks are various; hijacking 8447 (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks 8448 with uncertain results (SET_PARAMETER). 8450 19.1.1. Digest Authentication 8452 This section describes the modifications and clarifications required 8453 to apply the HTTP Digest authentication scheme to RTSP. The RTSP 8454 scheme usage is almost completely identical to that for HTTP 8455 [RFC2617]. These are based on the procedures defined for SIP 2.0 8456 [RFC3261]. 8458 The rules for Digest authentication follow those defined in 8459 [RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the 8460 following differences: 8462 1. Use the ABNF specified in this document, rather than the one in 8463 [RFC2617]. Consequently the following is assured: 8465 * Using the right RTSP URIs allowed in the challenge as well as 8466 in the digest. 8468 * Resolved the error in the "uri" parameter of the Authorization 8469 header in [RFC2617]. 8471 2. If MTags are used then the example procedure for choosing a nonce 8472 based on Etag can work based on replacing ETag with the MTag. 8474 3. As a clarification to the calculation of the A2 value for message 8475 integrity assurance in the Digest authentication scheme, 8476 implementers should assume, when the entity-body is empty (that 8477 is, when the RTSP messages have no message body) that the hash of 8478 the message-body resolves to the MD5 hash of an empty string, or: 8479 H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e". 8481 4. RFC 2617 notes that a cnonce value MUST NOT be sent in an 8482 Authorization (and by extension Proxy-Authorization) header field 8483 if no qop directive has been sent. Therefore, any algorithms 8484 that have a dependency on the cnonce (including "MD5-Sess") 8485 require that the qop directive be sent. Use of the "qop" 8486 parameter is optional in RFC 2617 for the purposes of backwards 8487 compatibility with RFC 2069; since this specification defines 8488 RTSP 2.0 there is no backwards compatibility issue with 8489 mandating. Thus, all RTSP agents MUST implement qop-options. 8491 19.2. RTSP over TLS 8493 RTSP agents MUST implement RTSP over TLS as defined in this section 8494 and the next Section 19.3. RTSP MUST follow the same guidelines with 8495 regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. 8496 RTSP over TLS is separated from unsecured RTSP both on the URI level 8497 and the port level. Instead of using the "rtsp" scheme identifier in 8498 the URI, the "rtsps" scheme identifier MUST be used to signal RTSP 8499 over TLS. If no port is given in a URI with the "rtsps" scheme, port 8500 322 MUST be used for TLS over TCP/IP. 8502 When a client tries to setup an insecure channel to the server (using 8503 the "rtsp" URI), and the policy for the resource requires a secure 8504 channel, the server MUST redirect the client to the secure service by 8505 sending a 301 redirect response code together with the correct 8506 Location URI (using the "rtsps" scheme). A user or client MAY 8507 upgrade a non secured URI to a secured by changing the scheme from 8508 "rtsp" to "rtsps". A server implementing support for "rtsps" MUST 8509 allow this. 8511 It should be noted that TLS allows for mutual authentication (when 8512 using both server and client certificates). Still, one of the more 8513 common ways TLS is used is to only provide server side authentication 8514 (often to avoid client certificates). TLS is then used in addition 8515 to HTTP authentication, providing transport security and server 8516 authentication, while HTTP Authentication is used to authenticate the 8517 client. 8519 RTSP includes the possibility to keep a TCP session up between the 8520 client and server, throughout the RTSP session lifetime. It may be 8521 convenient to keep the TCP session, not only to save the extra setup 8522 time for TCP, but also the extra setup time for TLS (even if TLS uses 8523 the resume function, there will be almost two extra round trips). 8524 Still, when TLS is used, such behavior introduces extra active state 8525 in the server, not only for TCP and RTSP, but also for TLS. This may 8526 increase the vulnerability to DoS attacks. 8528 There exists a potential security vulnerability when reusing TCP and 8529 TLS state for different resources (URIs). If two different host 8530 names point at the same IP address it can be desirable to re-use the 8531 TCP/TLS connection to that server. In that case the RTSP agent 8532 having the TCP/TLS connection MUST verify that the server certificate 8533 associated with the connection has a SubjectAltName matching the host 8534 name present in the URI for the resource an RTSP request is to be 8535 issued for. 8537 In addition to these recommendations, Section 19.3 gives further 8538 recommendations of TLS usage with proxies. 8540 19.3. Security and Proxies 8542 The nature of a proxy is often to act as a "man-in-the-middle", while 8543 security is often about preventing the existence of a "man-in-the- 8544 middle". This section provides clients with the possibility to use 8545 proxies even when applying secure transports (TLS) between the RTSP 8546 agents. The TLS proxy mechanism allows for server and proxy 8547 identification using certificates. However, the client cannot be 8548 identified based on certificates. The client needs to select between 8549 using the procedure specified below or using a TLS connection 8550 directly (by-passing any proxies) to the server. The choice may be 8551 dependent on policies. 8553 There are in general two categories of proxies, the transparent 8554 proxies (of which the client is not aware) and the non-transparent 8555 proxies (of which the client is aware). This memo specifies only 8556 non-transparent RTSP proxies, i.e., proxies visible to the RTSP 8557 client and RTSP server. An infrastructure based on proxies requires 8558 that the trust model is such that both client and servers can trust 8559 the proxies to handle the RTSP messages correctly. To be able to 8560 trust a proxy, the client and server also need to be aware of the 8561 proxy. Hence, transparent proxies cannot generally be seen as 8562 trusted and will not work well with security (unless they work only 8563 at the transport layer). In the rest of this section any reference 8564 to proxy will be to a non-transparent proxy, which inspects or 8565 manipulates the RTSP messages. 8567 HTTP Authentication is built on the assumption of proxies and can 8568 provide user-proxy authentication and proxy-proxy/server 8569 authentication in addition to the client-server authentication. 8571 When TLS is applied and a proxy is used, the client will connect to 8572 the proxy's address when connecting to any RTSP server. This implies 8573 that for TLS, the client will authenticate the proxy server and not 8574 the end server. Note that when the client checks the server 8575 certificate in TLS, it MUST check the proxy's identity (URI or 8576 possibly other known identity) against the proxy's identity as 8577 presented in the proxy's Certificate message. 8579 The problem is that for a proxy accepted by the client, the proxy 8580 needs to be provided information on which grounds it should accept 8581 the next-hop certificate. Both the proxy and the user may have rules 8582 for this, and the user should have the possibility to select the 8583 desired behavior. To handle this case, the Accept-Credentials header 8584 (See Section 18.2) is used, where the client can request the proxy/ 8585 proxies to relay back the chain of certificates used to authenticate 8586 any intermediate proxies as well as the server. The assumption that 8587 the proxies are viewed as trusted, gives the user a possibility to 8588 enforce policies to each trusted proxy of whether it should accept 8589 the next agent in the chain. However, it should be noted that not 8590 all deployments will return the chain of certificates used to 8591 authenticate any intermediate proxies as well as the server. An 8592 operator of such a deployment may want to hide its topology from the 8593 client. It should be noted well that the client does not have any 8594 insight into the proxy's operation. Even if the proxy is trusted, it 8595 can still return an incomplete chain of certificates. 8597 A proxy MUST use TLS for the next hop if the RTSP request includes a 8598 "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between 8599 client and proxy, or between proxy and proxy), even if the resource 8600 and the end server are not required to use it. The chain of proxies 8601 used by a client to reach a server and their TLS sessions MUST have 8602 commensurate security. Therefore a proxy MUST, when initiating the 8603 next hop TLS connection, use the incoming TLS connections cipher 8604 suite list, only modified by removing any cipher suites that the 8605 proxy does not support. In case a proxy fails to establish a TLS 8606 connection due to cipher suite mismatch between proxy and next hop 8607 proxy or server, this is indicated using error code 472 (Failure to 8608 establish secure connection). 8610 19.3.1. Accept-Credentials 8612 The Accept-Credentials header can be used by the client to distribute 8613 simple authorization policies to intermediate proxies. The client 8614 includes the Accept-Credentials header to dictate how the proxy 8615 treats the server/next proxy certificate. There are currently three 8616 methods defined: 8618 Any: which means that the proxy (or proxies) MUST accept whatever 8619 certificate is presented. This is of course not a recommended 8620 option to use, but may be useful in certain circumstances (such 8621 as testing). 8623 Proxy: which means that the proxy (or proxies) MUST use its own 8624 policies to validate the certificate and decide whether to 8625 accept it or not. This is convenient in cases where the user 8626 has a strong trust relation with the proxy. Reasons why a 8627 strong trust relation may exist are: personal/company proxy, 8628 proxy has a out-of-band policy configuration mechanism. 8630 User: which means that the proxy (or proxies) MUST send credential 8631 information about the next hop to the client for authorization. 8632 The client can then decide whether the proxy should accept the 8633 certificate or not. See Section 19.3.2 for further details. 8635 If the Accept-Credentials header is not included in the RTSP request 8636 from the client, then the "Proxy" method MUST be used as default. If 8637 another method than the "Proxy" is to be used, then the Accept- 8638 Credentials header MUST be included in all of the RTSP requests from 8639 the client. This is because it cannot be assumed that the proxy 8640 always keeps the TLS state or the user's previous preference between 8641 different RTSP messages (in particular if the time interval between 8642 the messages is long). 8644 With the "Any" and "Proxy" methods the proxy will apply the policy as 8645 defined for each method. If the policy does not accept the 8646 credentials of the next hop, the proxy MUST respond with a message 8647 using status code 471 (Connection Credentials not accepted). 8649 An RTSP request in the direction server to client MUST NOT include 8650 the Accept-Credentials header. As for the non-secured communication, 8651 the possibility for these requests depends on the presence of a 8652 client established connection. However, if the server to client 8653 request is in relation to a session established over a TLS secured 8654 channel, it MUST be sent in a TLS secured connection. That secured 8655 connection MUST also be the one used by the last client to server 8656 request. If no such transport connection exists at the time when the 8657 server desires to send the request, the server MUST discard the 8658 message. 8660 Further policies MAY be defined and registered, but should be done so 8661 with caution. 8663 19.3.2. User approved TLS procedure 8665 For the "User" method, each proxy MUST perform the following 8666 procedure for each RTSP request: 8668 o Setup the TLS session to the next hop if not already present 8669 (i.e., run the TLS handshake, but do not send the RTSP request). 8671 o Extract the peer certificate chain for the TLS session. 8673 o Check if a matching identity and hash of the peer certificate is 8674 present in the Accept-Credentials header. If present, send the 8675 message to the next hop, and conclude these procedures. If not, 8676 go to the next step. 8678 o The proxy responds to the RTSP request with a 470 or 407 response 8679 code. The 407 response code MAY be used when the proxy requires 8680 both user and connection authorization from user or client. In 8681 this message the proxy MUST include a Connection-Credentials 8682 header, see Section 18.13 with the next hop's identity and 8683 certificate. 8685 The client MUST upon receiving a 470 or 407 response with Connection- 8686 Credentials header take the decision on whether to accept the 8687 certificate or not (if it cannot do so, the user SHOULD be 8688 consulted). Using IP addresses in the next hop URI and certificates 8689 rather than domain names makes it very difficult for a user to 8690 determine if it should approve the next hop or not. Proxies are 8691 RECOMMENDED to use domain names to identify themselves in URIs and in 8692 the certificates. If the certificate is accepted, the client has to 8693 again send the RTSP request. In that request the client has to 8694 include the Accept-Credentials header including the hash over the DER 8695 encoded certificate for all trusted proxies in the chain. 8697 Example: 8699 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8700 CSeq: 2 8701 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8702 "192.0.2.5:4589" 8703 Accept-Ranges: npt, smpte, clock 8704 Accept-Credentials: User 8706 P->C: RTSP/2.0 470 Connection Authorization Required 8707 CSeq: 2 8708 Connection-Credentials: "rtsps://test.example.org"; 8709 MIIDNTCCAp... 8711 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8712 CSeq: 3 8713 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8714 "192.0.2.5:4589" 8715 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8716 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8717 Accept-Ranges: npt, smpte, clock 8719 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8720 CSeq: 3 8721 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8722 "192.0.2.5:4589" 8723 Via: RTSP/2.0 proxy.example.org 8724 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8725 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8726 Accept-Ranges: npt, smpte, clock 8728 One implication of this process is that the connection for secured 8729 RTSP messages may take significantly more round-trip times for the 8730 first message. A complete extra message exchange between the proxy 8731 connecting to the next hop and the client results because of the 8732 process for approval for each hop. However, if each message contains 8733 the chain of proxies that the requester accepts, the remaining 8734 message exchange should not be delayed. The procedure of including 8735 the credentials in each request rather than building state in each 8736 proxy, avoids the need for revocation procedures. 8738 20. Syntax 8740 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 8741 as defined in RFC 5234 [RFC5234]. It uses the basic definitions 8742 present in RFC 5234. 8744 Please note that ABNF strings, e.g., "Accept", are case insensitive 8745 as specified in section 2.3 of RFC 5234. 8747 The RTSP syntax makes use of the ISO 10646 character set in UTF-8 8748 encoding RFC 3629 [RFC3629]. 8750 20.1. Base Syntax 8752 RTSP header values can be folded onto multiple lines if the 8753 continuation line begins with a space or horizontal tab. All linear 8754 white space, including folding, has the same semantics as SP. A 8755 recipient MAY replace any linear white space with a single SP before 8756 interpreting the field value or forwarding the message downstream. 8757 This is intended to behave exactly as HTTP/1.1 as described in RFC 8758 2616 [RFC2616]. The SWS construct is used when linear white space is 8759 optional, generally between tokens and separators. 8761 To separate the header name from the rest of value, a colon is used, 8762 which, by the above rule, allows whitespace before, but no line 8763 break, and whitespace after, including a line break. The HCOLON 8764 defines this construct. 8766 OCTET = %x00-FF ; any 8-bit sequence of data 8767 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 8768 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 8769 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 8770 ALPHA = UPALPHA / LOALPHA 8771 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 8772 CTL = %x00-1F / %x7F ; any US-ASCII control character 8773 ; (octets 0 - 31) and DEL (127) 8774 CR = %x0D ; US-ASCII CR, carriage return (13) 8775 LF = %x0A ; US-ASCII LF, linefeed (10) 8776 SP = %x20 ; US-ASCII SP, space (32) 8777 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 8778 BACKSLASH = %x5C ; US-ASCII backslash (92) 8779 CRLF = CR LF 8781 LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space 8782 SWS = [LWS] ; Separating White Space 8783 HCOLON = *( SP / HT ) ":" SWS 8784 TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs 8785 tspecials = "(" / ")" / "<" / ">" / "@" 8786 / "," / ";" / ":" / BACKSLASH / DQUOTE 8787 / "/" / "[" / "]" / "?" / "=" 8788 / "{" / "}" / SP / HT 8789 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 8790 / %x41-5A / %x5E-7A / %x7C / %x7E) 8791 ; 1* 8792 quoted-string = ( DQUOTE *qdtext DQUOTE ) 8793 qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair 8794 / UTF8-NONASCII 8795 ; No DQUOTE and no "\" 8796 quoted-pair = "\\" / ( "\" DQUOTE ) 8797 ctext = %x20-27 / %x2A-7E 8798 / %x80-FF ; any OCTET except CTLs, "(" and ")" 8799 generic-param = token [ EQUAL gen-value ] 8800 gen-value = token / host / quoted-string 8801 safe = "$" / "-" / "_" / "." / "+" 8802 extra = "!" / "*" / "'" / "(" / ")" / "," 8803 rtsp-extra = "!" / "*" / "'" / "(" / ")" 8805 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 8806 / "a" / "b" / "c" / "d" / "e" / "f" 8807 LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 8808 ; lowercase "a-f" Hex 8809 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 8811 unreserved = ALPHA / DIGIT / safe / extra 8812 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 8814 base64 = *base64-unit [base64-pad] 8815 base64-unit = 4base64-char 8816 base64-pad = (2base64-char "==") / (3base64-char "=") 8817 base64-char = ALPHA / DIGIT / "+" / "/" 8819 SLASH = SWS "/" SWS ; slash 8820 EQUAL = SWS "=" SWS ; equal 8821 LPAREN = SWS "(" SWS ; left parenthesis 8822 RPAREN = SWS ")" SWS ; right parenthesis 8823 COMMA = SWS "," SWS ; comma 8824 SEMI = SWS ";" SWS ; semicolon 8825 COLON = SWS ":" SWS ; colon 8826 MINUS = SWS "-" SWS ; minus/dash 8827 LDQUOT = SWS DQUOTE ; open double quotation mark 8828 RDQUOT = DQUOTE SWS ; close double quotation mark 8829 RAQUOT = ">" SWS ; right angle quote 8830 LAQUOT = SWS "<" ; left angle quote 8832 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 8833 UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 8834 UTF8-1 = 8835 UTF8-2 = 8836 UTF8-3 = 8837 UTF8-4 = 8838 UTF8-tail = 8840 POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] 8841 FLOAT = ["-"] POS-FLOAT 8843 20.2. RTSP Protocol Definition 8844 20.2.1. Generic Protocol elements 8846 RTSP-IRI = schemes ":" IRI-rest 8847 IRI-rest = ihier-part [ "?" iquery ] 8848 ihier-part = "//" iauthority ipath-abempty 8849 RTSP-IRI-ref = RTSP-IRI / irelative-ref 8850 irelative-ref = irelative-part [ "?" iquery ] 8851 irelative-part = "//" iauthority ipath-abempty 8852 / ipath-absolute 8853 / ipath-noscheme 8854 / ipath-empty 8856 iauthority = < As defined in RFC 3987> 8857 ipath = ipath-abempty ; begins with "/" or is empty 8858 / ipath-absolute ; begins with "/" but not "//" 8859 / ipath-noscheme ; begins with a non-colon segment 8860 / ipath-rootless ; begins with a segment 8861 / ipath-empty ; zero characters 8863 ipath-abempty = *( "/" isegment ) 8864 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 8865 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 8866 ipath-rootless = isegment-nz *( "/" isegment ) 8867 ipath-empty = 0 8869 isegment = *ipchar [";" *ipchar] 8870 isegment-nz = 1*ipchar [";" *ipchar] 8871 / ";" *ipchar 8872 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 8873 / ";" *ipchar-nc 8874 ; non-zero-length segment without any colon ":" 8875 ; No parameter (; delimited) inside path. 8877 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 8878 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 8879 ; sub-delims is different from RFC 3987 8880 ; not including ";" 8882 iquery = < As defined in RFC 3987> 8883 iunreserved = < As defined in RFC 3987> 8884 pct-encoded = < As defined in RFC 3987> 8885 RTSP-URI = schemes ":" URI-rest 8886 RTSP-REQ-URI = schemes ":" URI-req-rest 8887 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 8888 RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel 8889 schemes = "rtsp" / "rtsps" / scheme 8890 scheme = < As defined in RFC 3986> 8891 URI-rest = hier-part [ "?" query ] 8892 URI-req-rest = hier-part [ "?" query ] 8893 ; Note fragment part not allowed in requests 8894 hier-part = "//" authority path-abempty 8896 RTSP-Relative = relative-part [ "?" query ] 8897 RTSP-REQ-Rel = relative-part [ "?" query ] 8898 relative-part = "//" authority path-abempty 8899 / path-absolute 8900 / path-noscheme 8901 / path-empty 8903 authority = < As defined in RFC 3986> 8904 query = < As defined in RFC 3986> 8906 path = path-abempty ; begins with "/" or is empty 8907 / path-absolute ; begins with "/" but not "//" 8908 / path-noscheme ; begins with a non-colon segment 8909 / path-rootless ; begins with a segment 8910 / path-empty ; zero characters 8912 path-abempty = *( "/" segment ) 8913 path-absolute = "/" [ segment-nz *( "/" segment ) ] 8914 path-noscheme = segment-nz-nc *( "/" segment ) 8915 path-rootless = segment-nz *( "/" segment ) 8916 path-empty = 0 8918 segment = *pchar [";" *pchar] 8919 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 8920 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 8921 ; non-zero-length segment without any colon ":" 8922 ; No parameter (; delimited) inside path. 8924 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 8925 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 8927 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 8928 / "*" / "+" / "," / "=" 8929 ; sub-delims is different from RFC 3986/3987 8930 ; not including ";" 8932 smpte-range = smpte-type [EQUAL smpte-range-spec] 8933 ; See section 4.4 8934 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 8935 / ( "-" smpte-time ) 8936 smpte-type = "smpte" / "smpte-30-drop" 8937 / "smpte-25" / smpte-type-extension 8938 ; other timecodes may be added 8939 smpte-type-extension = "smpte" token 8940 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 8941 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 8943 npt-range = "npt" [EQUAL npt-range-spec] 8944 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 8945 npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp 8946 npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] 8947 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] 8948 npt-hh = 2*19DIGIT ; any positive number 8949 npt-mm = 2*2DIGIT ; 0-59 8950 npt-ss = 2*2DIGIT ; 0-59 8951 npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp 8952 [ "." 1*9DIGIT ] # Compatibility format 8953 npt-hh-comp = 1*19DIGIT ; any positive number 8954 npt-mm-comp = 1*2DIGIT ; 0-59 8955 npt-ss-comp = 1*2DIGIT ; 0-59 8957 utc-range = "clock" [EQUAL utc-range-spec] 8958 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 8959 utc-time = utc-date "T" utc-clock "Z" 8960 utc-date = 8DIGIT 8961 utc-clock = 6DIGIT [ "." 1*9DIGIT ] 8963 feature-tag = token 8965 session-id = 1*256( ALPHA / DIGIT / safe ) 8967 extension-header = header-name HCOLON header-value 8968 header-name = token 8969 header-value = *(TEXT-UTF8char / LWS) 8971 20.2.2. Message Syntax 8972 RTSP-message = Request / Response ; RTSP/2.0 messages 8974 Request = Request-Line 8975 *((general-header 8976 / request-header 8977 / message-body-header) CRLF) 8978 CRLF 8979 [ message-body-data ] 8981 Response = Status-Line 8982 *((general-header 8983 / response-header 8984 / message-body-header) CRLF) 8985 CRLF 8986 [ message-body-data ] 8988 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 8990 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 8992 Method = "DESCRIBE" 8993 / "GET_PARAMETER" 8994 / "OPTIONS" 8995 / "PAUSE" 8996 / "PLAY" 8997 / "PLAY_NOTIFY" 8998 / "REDIRECT" 8999 / "SETUP" 9000 / "SET_PARAMETER" 9001 / "TEARDOWN" 9002 / extension-method 9004 extension-method = token 9006 Request-URI = "*" / RTSP-REQ-URI 9007 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 9009 message-body-data = 1*OCTET 9011 Status-Code = "100" ; Continue 9012 / "200" ; OK 9013 / "301" ; Moved Permanently 9014 / "302" ; Found 9015 / "303" ; See Other 9016 / "304" ; Not Modified 9017 / "305" ; Use Proxy 9018 / "400" ; Bad Request 9019 / "401" ; Unauthorized 9020 / "402" ; Payment Required 9021 / "403" ; Forbidden 9022 / "404" ; Not Found 9023 / "405" ; Method Not Allowed 9024 / "406" ; Not Acceptable 9025 / "407" ; Proxy Authentication Required 9026 / "408" ; Request Time-out 9027 / "410" ; Gone 9028 / "412" ; Precondition Failed 9029 / "413" ; Request Message Body Too Large 9030 / "414" ; Request-URI Too Large 9031 / "415" ; Unsupported Media Type 9032 / "451" ; Parameter Not Understood 9033 / "452" ; reserved 9034 / "453" ; Not Enough Bandwidth 9035 / "454" ; Session Not Found 9036 / "455" ; Method Not Valid in This State 9037 / "456" ; Header Field Not Valid for Resource 9038 / "457" ; Invalid Range 9039 / "458" ; Parameter Is Read-Only 9040 / "459" ; Aggregate operation not allowed 9041 / "460" ; Only aggregate operation allowed 9042 / "461" ; Unsupported Transport 9043 / "462" ; Destination Unreachable 9044 / "463" ; Destination Prohibited 9045 / "464" ; Data Transport Not Ready Yet 9046 / "465" ; Notification Reason Unknown 9047 / "466" ; Key Management Error 9048 / "470" ; Connection Authorization Required 9049 / "471" ; Connection Credentials not accepted 9050 / "472" ; Failure to establish secure connection 9051 / "500" ; Internal Server Error 9052 / "501" ; Not Implemented 9053 / "502" ; Bad Gateway 9054 / "503" ; Service Unavailable 9055 / "504" ; Gateway Time-out 9056 / "505" ; RTSP Version not supported 9057 / "551" ; Option not supported 9058 / extension-code 9060 extension-code = 3DIGIT 9062 Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) 9063 rtsp-header = general-header 9064 / request-header 9065 / response-header 9066 / message-body-header 9068 general-header = Accept-Ranges 9069 / Cache-Control 9070 / Connection 9071 / CSeq 9072 / Date 9073 / Media-Properties 9074 / Media-Range 9075 / Pipelined-Requests 9076 / Proxy-Supported 9077 / Range 9078 / RTP-Info 9079 / Scale 9080 / Seek-Style 9081 / Server 9082 / Session 9083 / Speed 9084 / Supported 9085 / Timestamp 9086 / Transport 9087 / User-Agent 9088 / Via 9089 / extension-header 9091 request-header = Accept 9092 / Accept-Credentials 9093 / Accept-Encoding 9094 / Accept-Language 9095 / Authorization 9096 / Bandwidth 9097 / Blocksize 9098 / From 9099 / If-Match 9100 / If-Modified-Since 9101 / If-None-Match 9102 / Notify-Reason 9103 / Proxy-Authorization 9104 / Proxy-Require 9105 / Referrer 9106 / Request-Status 9107 / Require 9108 / Terminate-Reason 9109 / extension-header 9111 response-header = Authentication-Info 9112 / Connection-Credentials 9113 / Location 9114 / MTag 9115 / Proxy-Authenticate 9116 / Proxy-Authentication-Info 9117 / Public 9118 / Retry-After 9119 / Unsupported 9120 / WWW-Authenticate 9121 / extension-header 9123 message-body-header = Allow 9124 / Content-Base 9125 / Content-Encoding 9126 / Content-Language 9127 / Content-Length 9128 / Content-Location 9129 / Content-Type 9130 / Expires 9131 / Last-Modified 9132 / extension-header 9134 20.2.3. Header Syntax 9136 Accept = "Accept" HCOLON 9137 [ accept-range *(COMMA accept-range) ] 9138 accept-range = media-type-range [SEMI accept-params] 9139 media-type-range = ( "*/*" 9140 / ( m-type SLASH "*" ) 9141 / ( m-type SLASH m-subtype ) 9142 ) *( SEMI m-parameter ) 9143 accept-params = "q" EQUAL qvalue *(SEMI generic-param ) 9144 qvalue = ( "0" [ "." *3DIGIT ] ) 9145 / ( "1" [ "." *3("0") ] ) 9146 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision 9147 cred-decision = ("User" [LWS cred-info]) 9148 / "Proxy" 9149 / "Any" 9150 / (token [LWS 1*header-value]) 9151 ; For future extensions 9152 cred-info = cred-info-data *(COMMA cred-info-data) 9154 cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg 9155 SEMI base64 9156 hash-alg = "sha-256" / extension-alg 9157 extension-alg = token 9158 Accept-Encoding = "Accept-Encoding" HCOLON 9160 [ encoding *(COMMA encoding) ] 9161 encoding = codings [SEMI accept-params] 9162 codings = content-coding / "*" 9163 content-coding = "identity" / token 9164 Accept-Language = "Accept-Language" HCOLON 9165 language *(COMMA language) 9166 language = language-range [SEMI accept-params] 9167 language-range = language-tag / "*" 9168 language-tag = primary-tag *( "-" subtag ) 9169 primary-tag = 1*8ALPHA 9170 subtag = 1*8ALPHA 9171 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges 9172 acceptable-ranges = (range-unit *(COMMA range-unit)) 9173 range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25" 9174 / "clock" / extension-format 9175 extension-format = token 9176 Allow = "Allow" HCOLON Method *(COMMA Method) 9177 Authentication-Info = "Authentication-Info" HCOLON auth-info 9178 auth-info = auth-info-entry *(COMMA auth-info-entry) 9179 auth-info-entry = nextnonce 9180 / message-qop 9181 / response-auth 9182 / cnonce 9183 / nonce-count 9184 nextnonce = "nextnonce" EQUAL nonce-value 9185 response-auth = "rspauth" EQUAL response-digest 9186 response-digest = DQUOTE *LHEX DQUOTE 9187 Authorization = "Authorization" HCOLON credentials 9188 credentials = basic-credential 9189 / digest-credential 9190 / other-response 9191 basic-credential = "Basic" LWS basic-credentials 9192 basic-credentials = base64 ; Base64 encoding of user-password 9193 user-password = basic-username ":" password 9194 basic-username = *CF-TEXT 9195 CF-TEXT = %x20-39 / %x3B-7E / %x80-FF ; TEXT without : 9196 password = *TEXT 9197 digest-credential = ("Digest" LWS digest-response) 9198 digest-response = dig-resp *(COMMA dig-resp) 9199 dig-resp = username / realm / nonce / digest-uri 9200 / dresponse / algorithm / cnonce 9201 / opaque / message-qop 9202 / nonce-count / auth-param 9203 username = "username" EQUAL username-value 9204 username-value = quoted-string 9205 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 9206 digest-uri-value = RTSP-REQ-URI 9207 message-qop = "qop" EQUAL qop-value 9208 cnonce = "cnonce" EQUAL cnonce-value 9209 cnonce-value = nonce-value 9210 nonce-count = "nc" EQUAL nc-value 9211 nc-value = 8LHEX 9212 dresponse = "response" EQUAL request-digest 9213 request-digest = LDQUOT 32LHEX RDQUOT 9214 auth-param = auth-param-name EQUAL 9215 ( token / quoted-string ) 9216 auth-param-name = token 9217 other-response = auth-scheme LWS auth-param 9218 *(COMMA auth-param) 9219 auth-scheme = token 9221 Bandwidth = "Bandwidth" HCOLON 1*19DIGIT 9223 Blocksize = "Blocksize" HCOLON 1*9DIGIT 9225 Cache-Control = "Cache-Control" HCOLON cache-directive 9226 *(COMMA cache-directive) 9227 cache-directive = cache-rqst-directive 9228 / cache-rspns-directive 9230 cache-rqst-directive = "no-cache" 9231 / "max-stale" [EQUAL delta-seconds] 9232 / "min-fresh" EQUAL delta-seconds 9233 / "only-if-cached" 9234 / cache-extension 9236 cache-rspns-directive = "public" 9237 / "private" 9238 / "no-cache" 9239 / "no-transform" 9240 / "must-revalidate" 9241 / "proxy-revalidate" 9242 / "max-age" EQUAL delta-seconds 9243 / cache-extension 9245 cache-extension = token [EQUAL (token / quoted-string)] 9246 delta-seconds = 1*19DIGIT 9248 Connection = "Connection" HCOLON connection-token 9249 *(COMMA connection-token) 9250 connection-token = "close" / token 9252 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 9253 cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64 9255 Content-Base = "Content-Base" HCOLON RTSP-URI 9256 Content-Encoding = "Content-Encoding" HCOLON 9257 content-coding *(COMMA content-coding) 9258 Content-Language = "Content-Language" HCOLON 9259 language-tag *(COMMA language-tag) 9260 Content-Length = "Content-Length" HCOLON 1*19DIGIT 9261 Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref 9262 Content-Type = "Content-Type" HCOLON media-type 9263 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 9264 m-type = discrete-type / composite-type 9265 discrete-type = "text" / "image" / "audio" / "video" 9266 / "application" / extension-token 9267 composite-type = "message" / "multipart" / extension-token 9268 extension-token = ietf-token / x-token 9269 ietf-token = token 9270 x-token = "x-" token 9271 m-subtype = extension-token / iana-token 9272 iana-token = token 9273 m-parameter = m-attribute EQUAL m-value 9274 m-attribute = token 9275 m-value = token / quoted-string 9277 CSeq = "CSeq" HCOLON cseq-nr 9278 cseq-nr = 1*9DIGIT 9279 Date = "Date" HCOLON RTSP-date 9280 RTSP-date = date-time ; 9281 date-time = 9282 Expires = "Expires" HCOLON RTSP-date 9283 From = "From" HCOLON from-spec 9284 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 9285 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 9286 addr-spec = RTSP-REQ-URI / absolute-URI 9287 absolute-URI = < As defined in RFC 3986> 9288 display-name = *(token LWS) / quoted-string 9289 from-param = tag-param / generic-param 9290 tag-param = "tag" EQUAL token 9291 If-Match = "If-Match" HCOLON ("*" / message-tag-list) 9292 message-tag-list = message-tag *(COMMA message-tag) 9293 message-tag = [ weak ] opaque-tag 9294 weak = "W/" 9295 opaque-tag = quoted-string 9296 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 9297 If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list) 9298 Last-Modified = "Last-Modified" HCOLON RTSP-date 9299 Location = "Location" HCOLON RTSP-REQ-URI 9300 Media-Properties = "Media-Properties" HCOLON [media-prop-list] 9301 media-prop-list = media-prop-value *(COMMA media-prop-value) 9302 media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) 9303 / "Beginning-Only" 9304 / "No-Seeking" 9305 / "Immutable" 9306 / "Dynamic" 9307 / "Time-Progressing" 9308 / "Unlimited" 9309 / ("Time-Limited" EQUAL utc-time) 9310 / ("Time-Duration" EQUAL POS-FLOAT) 9311 / ("Scales" EQUAL scale-value-list) 9312 / media-prop-ext 9313 media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] 9314 scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE 9315 scale-entry = scale-value / (scale-value COLON scale-value) 9316 scale-value = FLOAT 9317 Media-Range = "Media-Range" HCOLON [ranges-list] 9318 ranges-list = ranges-spec *(COMMA ranges-spec) 9319 MTag = "MTag" HCOLON message-tag 9320 Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val 9321 Notify-Reas-val = "end-of-stream" 9322 / "media-properties-update" 9323 / "scale-change" 9324 / Notify-Reason-extension 9325 Notify-Reason-extension = token 9326 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 9327 startup-id = 1*8DIGIT 9329 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list 9330 challenge-list = challenge *(COMMA challenge) 9331 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 9332 / ("Basic" LWS realm) 9333 / other-challenge 9334 other-challenge = auth-scheme LWS auth-param 9335 *(COMMA auth-param) 9336 digest-cln = realm / domain / nonce 9337 / opaque / stale / algorithm 9338 / qop-options / auth-param 9339 realm = "realm" EQUAL realm-value 9340 realm-value = quoted-string 9341 domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref 9342 *(1*SP RTSP-REQ-Ref ) RDQUOT 9343 nonce = "nonce" EQUAL nonce-value 9344 nonce-value = quoted-string 9345 opaque = "opaque" EQUAL quoted-string 9346 stale = "stale" EQUAL ( "true" / "false" ) 9347 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 9348 qop-options = "qop" EQUAL LDQUOT qop-value 9349 *("," qop-value) RDQUOT 9350 qop-value = "auth" / "auth-int" / token 9351 Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON auth-info 9352 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials 9353 Proxy-Require = "Proxy-Require" HCOLON feature-tag-list 9354 feature-tag-list = feature-tag *(COMMA feature-tag) 9355 Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] 9357 Public = "Public" HCOLON Method *(COMMA Method) 9359 Range = "Range" HCOLON ranges-spec 9361 ranges-spec = npt-range / utc-range / smpte-range 9362 / range-ext 9363 range-ext = extension-format [EQUAL range-value] 9364 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 9366 Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) 9367 Request-Status = "Request-Status" HCOLON req-status-info 9368 req-status-info = cseq-info LWS status-info LWS reason-info 9369 cseq-info = "cseq" EQUAL cseq-nr 9370 status-info = "status" EQUAL Status-Code 9371 reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE 9372 Require = "Require" HCOLON feature-tag-list 9373 RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec 9374 *(COMMA rtsp-info-spec)] 9375 rtsp-info-spec = stream-url 1*ssrc-parameter 9376 stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE 9377 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 9378 ri-parameter *(SEMI ri-parameter) 9379 ri-parameter = ("seq" EQUAL 1*5DIGIT) 9380 / ("rtptime" EQUAL 1*10DIGIT) 9381 / generic-param 9383 Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds) 9384 Scale = "Scale" HCOLON scale-value 9385 Seek-Style = "Seek-Style" HCOLON Seek-S-values 9386 Seek-S-values = "RAP" 9387 / "CoRAP" 9388 / "First-Prior" 9389 / "Next" 9390 / Seek-S-value-ext 9391 Seek-S-value-ext = token 9393 Server = "Server" HCOLON ( product / comment ) 9394 *(LWS (product / comment)) 9395 product = token [SLASH product-version] 9396 product-version = token 9397 comment = LPAREN *( ctext / quoted-pair) RPAREN 9399 Session = "Session" HCOLON session-id 9400 [ SEMI "timeout" EQUAL delta-seconds ] 9402 Speed = "Speed" HCOLON lower-bound MINUS upper-bound 9403 lower-bound = POS-FLOAT 9404 upper-bound = POS-FLOAT 9406 Supported = "Supported" HCOLON [feature-tag-list] 9407 Terminate-Reason = "Terminate-Reason" HCOLON TR-Info 9408 TR-Info = TR-Reason *(SEMI TR-Parameter) 9409 TR-Reason = "Session-Timeout" 9410 / "Server-Admin" 9411 / "Internal-Error" 9412 / token 9413 TR-Parameter = TR-time / TR-user-msg / generic-param 9414 TR-time = "time" EQUAL utc-time 9415 TR-user-msg = "user-msg" EQUAL quoted-string 9417 Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay] 9418 timestamp-value = *19DIGIT [ "." *9DIGIT ] 9419 delay = *9DIGIT [ "." *9DIGIT ] 9421 Transport = "Transport" HCOLON transport-spec 9422 *(COMMA transport-spec) 9423 transport-spec = transport-id *trns-parameter 9424 transport-id = trans-id-rtp / other-trans 9425 trans-id-rtp = "RTP/" profile ["/" lower-transport] 9426 ; no LWS is allowed inside transport-id 9427 other-trans = token *("/" token) 9428 profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token 9429 lower-transport = "TCP" / "UDP" / token 9430 trns-parameter = (SEMI ( "unicast" / "multicast" )) 9431 / (SEMI "interleaved" EQUAL channel ["-" channel]) 9432 / (SEMI "ttl" EQUAL ttl) 9433 / (SEMI "layers" EQUAL 1*DIGIT) 9434 / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) 9435 / (SEMI "mode" EQUAL mode-spec) 9436 / (SEMI "dest_addr" EQUAL addr-list) 9437 / (SEMI "src_addr" EQUAL addr-list) 9438 / (SEMI "setup" EQUAL contrans-setup) 9439 / (SEMI "connection" EQUAL contrans-con) 9440 / (SEMI "RTCP-mux") 9441 / (SEMI "MIKEY" EQUAL MIKEY-Value) 9442 / (SEMI trn-param-ext) 9443 contrans-setup = "active" / "passive" / "actpass" 9444 contrans-con = "new" / "existing" 9445 trn-param-ext = par-name [EQUAL trn-par-value] 9446 par-name = token 9447 trn-par-value = *(rtsp-unreserved / quoted-string) 9448 ttl = 1*3DIGIT ; 0 to 255 9449 ssrc = 8HEX 9450 channel = 1*3DIGIT ; 0 to 255 9451 MIKEY-Value = base64 9452 mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) 9453 mode = "PLAY" / token 9454 addr-list = quoted-addr *(SLASH quoted-addr) 9455 quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE 9456 host-port = ( host [":" port] ) 9457 / ( ":" port ) 9458 extension-addr = 1*qdtext 9459 host = < As defined in RFC 3986> 9460 port = < As defined in RFC 3986> 9461 Unsupported = "Unsupported" HCOLON feature-tag-list 9462 User-Agent = "User-Agent" HCOLON ( product / comment ) 9463 *(LWS (product / comment)) 9464 Via = "Via" HCOLON via-parm *(COMMA via-parm) 9465 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 9466 via-params = via-ttl / via-maddr 9467 / via-received / via-extension 9468 via-ttl = "ttl" EQUAL ttl 9469 via-maddr = "maddr" EQUAL host 9470 via-received = "received" EQUAL (IPv4address / IPv6address) 9471 IPv4address = < As defined in RFC 3986> 9472 IPv6address = < As defined in RFC 3986> 9473 via-extension = generic-param 9474 sent-protocol = protocol-name SLASH protocol-version 9475 SLASH transport-prot 9476 protocol-name = "RTSP" / token 9477 protocol-version = token 9478 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 9479 other-transport = token 9480 sent-by = host [ COLON port ] 9482 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 9484 20.3. SDP extension Syntax 9486 This section defines in ABNF the SDP extensions defined for RTSP. 9487 See Appendix D for the definition of the extensions in text. 9489 control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF 9491 a-range-def = "a=range:" ranges-spec CRLF 9493 a-mtag-def = "a=mtag:" message-tag CRLF 9495 21. Security Considerations 9497 The security considerations and threats around RTSP and its usage can 9498 be divided into considerations around the signaling protocol itself 9499 and the issues related to the media stream delivery. However, when 9500 it comes to mitigations of security threats, a threat depending on 9501 the media stream delivery may in fact be mitigated by a mechanism in 9502 the signaling protocol. 9504 There are several chapters and an appendix in this document that 9505 define security solutions for the protocol. These sections will be 9506 referenced when discussing the threats below. But the reader should 9507 take special notice of the Security Framework (Section 19) and the 9508 specification of how to use SRTP and its key-mangement 9509 (Appendix C.1.4) to achieve certain aspects of the media security. 9511 21.1. Signaling Protocol Threats 9513 This section focuses on issues related to the signaling protocol. 9514 Because of the similarity in syntax and usage between RTSP servers 9515 and HTTP servers, the security considerations outlined in [H15] apply 9516 also. 9518 Specifically, please note the following: 9520 Abuse of Server Log Information: A server is in the position to save 9521 personal data about a user's requests which might identify 9522 their media consumption patterns or subjects of interest. This 9523 information is clearly confidential in nature and its handling 9524 can be constrained by law in certain countries. RTSP servers 9525 will presumably have similar logging mechanisms to HTTP, and 9526 thus should be equally guarded in protecting the contents of 9527 those logs, thus protecting the privacy of the users of the 9528 servers. People using the RTSP protocol to provide media are 9529 responsible for ensuring that logging material is not 9530 distributed without the permission of any individuals that are 9531 identifiable by the published results. 9533 Transfer of Sensitive Information: There is no reason to believe 9534 that information transferred in RTSP message, such as the URI 9535 and the content of headers, especially the Server, Via, 9536 Referrer and From headers, may be any less sensitive than when 9537 used in HTTP. Therefore, all of the precautions regarding the 9538 protection of data privacy and user privacy apply to 9539 implementors of RTSP clients, servers, and proxies. See 9540 [H15.1.2] for further details. 9542 The RTSP methods defined in this document is primarily used to 9543 establish and control the delivery of the media data 9544 represented by the URI, thus the RTSP message bodies are 9545 generally less sensitive than the ones in HTTP. Where HTTP 9546 bodies could contain for example your medical records, in RTSP 9547 the sensitive video of your medical operation would be in the 9548 media stream over the media transport protocol, not in the RTSP 9549 message. Still one have to take note of what potential 9550 sensitive informative are included in the RTSP protocol. The 9551 protection of the media data is separate, can be applied 9552 directly between client and server, and is dependent on the 9553 media transport protocol in use. See Section 21.2 for further 9554 discussion. This possibility for separation of security 9555 between media resource content and the signalling protocol 9556 mitigates the risk of exposing the media content when using 9557 hop-by-hop security for RTSP signaling using proxies 9558 (Section 19.3). 9560 Attacks Based On File and Path Names: Though RTSP URIs are opaque 9561 handles that do not necessarily have file system semantics, it 9562 is anticipated that many implementations will translate 9563 portions of the Request-URIs directly to file system calls. In 9564 such cases, file systems SHOULD follow the precautions outlined 9565 in [H15.2], such as checking for ".." in path components. 9567 Personal Information: RTSP clients are often privy to the same 9568 information that HTTP clients are (user name, location, etc.) 9569 and thus should be equally sensitive. See [H15.1] for further 9570 recommendations. 9572 Privacy Issues Connected to Accept Headers: Since similar usages of 9573 the "Accept" headers exist in RTSP as in HTTP, the same caveats 9574 outlined in [H15.1.4] with regards to their use should be 9575 followed. 9577 DNS Spoofing: Presumably, given the longer connection times 9578 typically associated to RTSP sessions relative to HTTP 9579 sessions, RTSP client DNS optimizations should be less 9580 prevalent. Nonetheless, the recommendations provided in 9581 [H15.3] are still relevant to any implementation which attempts 9582 to rely on a DNS-to-IP mapping to hold beyond a single use of 9583 the mapping. 9585 Location Headers and Spoofing: If a single server supports multiple 9586 organizations that do not trust each another, then it MUST 9587 check the values of the Content-Location header fields in 9588 responses that are generated under control of said 9589 organizations to make sure that they do not attempt to 9590 invalidate resources over which they have no authority. 9591 ([H15.4]) 9593 In addition to the recommendations in the current HTTP specification 9594 (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 9595 2068 [RFC2068], future HTTP specifications may provide additional 9596 guidance on security issues. 9598 The following are added considerations for RTSP implementations. 9600 Session hijacking: Since there is no or little relation between a 9601 transport layer connection and an RTSP session, it is possible 9602 for a malicious client to issue requests with random session 9603 identifiers which could affect other clients of an unsuspecting 9604 server. To mitigate this the server SHALL use a large, random 9605 and non-sequential session identifier to minimize the 9606 possibility of this kind of attack. However, unless the RTSP 9607 signaling is always confidentiality protected, e.g., using TLS, 9608 an on-path attacker will be able to hijack a session. Another 9609 choice for preventing session hijacking is to use client 9610 authentication and only allow the authenticated client creating 9611 the session to access that session. 9613 Authentication: Servers SHOULD implement both basic and digest 9614 [RFC2617] authentication. In environments requiring tighter 9615 security for the control messages, the transport layer 9616 mechanism TLS [RFC5246] SHOULD be used. 9618 Suspicious behavior: RTSP servers upon detecting instances of 9619 behavior which is deemed a security risk SHOULD return error 9620 code 403 (Forbidden). RTSP servers SHOULD also be aware of 9621 attempts to probe the server for weaknesses and entry points 9622 and MAY arbitrarily disconnect and ignore further requests from 9623 clients which are deemed to be in violation of local security 9624 policy. 9626 TLS through proxies: If one uses the possibility to connect TLS in 9627 multiple legs (Section 19.3) one really needs to be aware of 9628 the trust model. That procedure requires full faith and trust 9629 in all proxies, which will be identified, that one allows to 9630 connect through. They are men in the middle and have access to 9631 all that goes on over the TLS connection. Thus it is important 9632 to consider if that trust model is acceptable in the actual 9633 application. Further discussion of the actual trust model is 9634 in Section 19.3. It is important to note what difference in 9635 security properties, if any, that may exist with the used media 9636 transport protocol and its security mechanism. Using SRTP and 9637 the MIKEY based key-establishment defined in Appendix C.1.4.1, 9638 enables to media key-establishment to done end-to-end without 9639 revealing the keys to the proxies. 9641 Resource Exhaustion: As RTSP is a stateful protocol and establishes 9642 resource usage on the server there is a clear possibility to 9643 attack the server by trying to overbook these resources to 9644 perform a denial of service attack. This attack can be both 9645 against ongoing sessions and to prevent others from 9646 establishing sessions. RTSP agents will need to have 9647 mechanisms to prevent single peers from consuming extensive 9648 amounts of resources. The methods for guarding against this 9649 are varied and depends on the agent's role and capabilities and 9650 policies. Each implementation has to carefully consider their 9651 methods and policies to mitigate this threat. For example 9652 regarding handling of connections there are recommendations in 9653 Section 10.7. 9655 The above threats and considerations have resulted in a set of 9656 security functions and mechanisms built into or used by the protocol. 9657 The signaling protocol relies on two security features defined in the 9658 Security Framework (Section 19) namely client authentication using 9659 HTTP authentication and TLS based transport protection of the 9660 signaling messages. Both of these mechanisms are required to be 9661 implemented by any RTSP agent. 9663 A number of different security mitigations have been designed into 9664 the protocol and will be instantiated if the specification is 9665 implemented as written, for example by ensuring sufficient amount of 9666 entropy in the randomly generated session identifiers when not using 9667 client authentication to minimize the risk of session hijacking. 9668 When client authentication is used the protection against hijacking 9669 will be greatly improved by scoping the accessible sessions to the 9670 one this client identity has created. Some of the above threats are 9671 such that the implementation of the RTSP functionality itself needs 9672 to consider which policy and strategy it uses to mitigate them. 9674 21.2. Media Stream Delivery Threats 9676 The fact that RTSP establishes and controls a media stream delivery 9677 results in a set of security issues related to the media streams. 9678 This section will attempt to analyze general threats, however the 9679 choice of media stream transport protocol, such as RTP will result in 9680 some differences in threats and what mechanisms exist to mitigate 9681 them. Thus it becomes important that each specification of a new 9682 media stream transport and delivery protocol usable by RTSP requires 9683 its own security analysis. This section includes one for RTP. 9685 The set of general threats from or by the media stream delivery 9686 itself are: 9688 Concentrated denial-of-service attack: The protocol offers the 9689 opportunity for a remote-controlled denial-of-service (DoS) 9690 attack, where the media stream is the hammer in that DoS attack. 9691 See Section 21.2.1. 9693 Media Confidentiality: The media delivery may contain content of any 9694 type and it is not possible in general to determine how sensitive 9695 this content is from a confidentiality point. Thus it is a strong 9696 requirement that any media delivery protocol provides a method for 9697 providing confidentiality of the actual media content. In 9698 addition to the media level confidentiality it becomes critical 9699 that no resource identifiers used in the signaling are exposed to 9700 an attacker as they may have human understandable names, or may be 9701 also available to the attacker so they can determine the content 9702 the user was delivered. Thus the signaling protocol must also 9703 provide confidentiality protection of any information related to 9704 the media resource. 9706 Media Integrity and Authentication: There are several reasons, such 9707 as discrediting the target, misinformation of the target, why an 9708 attacker will be interested in substituting the media stream sent 9709 out from the RTSP server with one of the attacker's creation or 9710 selection. Therefore it is important that the media protocol 9711 provides mechanisms to verify the source authentication, integrity 9712 and prevent replay attacks on the media stream. 9714 Scope of Multicast: If RTSP is used to control the transmission of 9715 media onto a multicast network the scope of the delivery must be 9716 considered. RTSP supports the TTL Transport header parameter to 9717 indicate this scope for IPv4. IPv6 has a different mechanism for 9718 scope boundary. However, such scope control has risks, as it may 9719 be set too large and distribute media beyond the intended scope. 9721 Below (Section 21.2.2) a protocol specific analysis of security 9722 considerations for RTP based media transport is done. In that 9723 section it is also made clear the requirements on implementing 9724 security functions for RTSP agents supporting media delivery over 9725 RTP. 9727 21.2.1. Remote Denial of Service Attack 9729 The attacker may initiate traffic flows to one or more IP addresses 9730 by specifying them as the destination in SETUP requests. While the 9731 attacker's IP address may be known in this case, this is not always 9732 useful in prevention of more attacks or ascertaining the attacker's 9733 identity. Thus, an RTSP server MUST only allow client-specified 9734 destinations for RTSP-initiated traffic flows if the server has 9735 ensured that the specified destination address accepts receiving 9736 media through different security mechanisms. Security mechanisms 9737 that are acceptable in order of increasing generality are: 9739 o Verification of the client's identity against a database of known 9740 users using RTSP authentication mechanisms (preferably digest 9741 authentication or stronger) 9743 o A list of addresses that have consented to be media destinations, 9744 especially considering user identity 9746 o Media path based verification 9747 The server SHOULD NOT allow the destination field to be set unless a 9748 mechanism exists in the system to authorize the request originator to 9749 direct streams to the recipient. It is preferred that this 9750 authorization be performed by the media recipient (destination) 9751 itself and the credentials passed along to the server. However, in 9752 certain cases, such as when the recipient address is a multicast 9753 group, or when the recipient is unable to communicate with the server 9754 in an out-of-band manner, this may not be possible. In these cases 9755 the server may chose another method such as a server-resident 9756 authorization list to ensure that the request originator has the 9757 proper credentials to request stream delivery to the recipient. 9759 One solution that performs the necessary verification of acceptance 9760 of media suitable for unicast based delivery is the Interactive 9761 Connectivity Establishment (ICE) [RFC5245] based NAT traversal method 9762 described in [I-D.ietf-mmusic-rtsp-nat]. This mechanism uses random 9763 passwords and a username so that the probability of unintended 9764 indication as a valid media destination is very low. In addition the 9765 server includes in its Session Traversal Utilities for NAT (STUN) 9766 [RFC5389] requests a cookie (consisting of random material) that the 9767 destination echoes back, thus the solution also safe-guards against 9768 having an off-path attacker being able to spoof the STUN checks. 9769 This leaves this solution vulnerable only to on-path attackers that 9770 can see the STUN requests go to the target of attack and thus forge a 9771 response. 9773 For delivery to multicast addresses there is a need for another 9774 solution which is not specified in this memo. 9776 21.2.2. RTP Security analysis 9778 RTP is a commonly used media transport protocol and has been the most 9779 common choice for RTSP 1.0 implementations. The core RTP protocol 9780 has been in use for a long time and it has well-known security 9781 properties and the RTP security consideration (Section 9 of 9782 [RFC3550]) needs to be reviewed. In perspective of the usage of RTP 9783 in context of RTSP the following properties should be noted: 9785 Stream Additions: RTP has support for multiple simultaneous media 9786 streams in each RTP session. As some use cases require support 9787 for non-synchronized adding and removal of media streams and their 9788 identifiers an attacker can easily insert additional media streams 9789 into a session context that according to protocol design is 9790 intended to be played out. Another threat vector is one of denial 9791 of service by exhausting the resources of the RTP session 9792 receiver, for example by using a large number of SSRC identifiers 9793 simultaneously. The strong mitigation of this is to ensure that 9794 one cryptographically authenticates any incoming packet flow to 9795 the RTP session. Weak mitigations like blocking additional media 9796 streams in session contexts easily lead to a denial of service 9797 vulnerability in addition to preventing certain RTP extensions or 9798 use cases which rely on multiple media streams, such as RTP 9799 retransmission [RFC4588] to function. 9801 Forged Feedback: The built in RTP control Protocol (RTCP) also 9802 offers a large attack surface for a couple of different types of 9803 attacks. One venue is to send RTCP feedback to the media sender 9804 indicating large amounts of packet loss and thus trigger a media 9805 bit-rate adaptation response from the sender resulting in lowered 9806 media quality and potentially shut down of the media stream. 9807 Another attack is to perform a resource exhaustion attack on the 9808 receiver by using many SSRC identifiers to create large state 9809 tables and increase the RTCP related processing demands. 9811 RTP/RTCP Extensions: RTP and RTCP extensions generally provide 9812 additional and sometimes extremely powerful tools to do denial of 9813 service or service disruption. For example the Code Control 9814 Message [RFC5104] RTCP extensions enables both locking down the 9815 bit-rate to low values and disruption of video quality by 9816 requesting Intra frames. 9818 Taking into account the above general discussion in Section 21.2 and 9819 the RTP specific discussion in this section it is clear that it is 9820 necessary that a strong security mechanism is supported to protect 9821 RTP. Therefore this specification has the following requirements on 9822 RTP security functions for all RTSP agents that handles media streams 9823 and where the media stream transport is done using RTP. 9825 RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] 9826 and thus the SAVP profile. In addition the secure AVP profile 9827 (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is 9828 implemented. This specification requires no additional cryptographic 9829 transforms or configuration values beyond those specified as 9830 mandatory to implement in RFC3711, i.e., AES-CM and HMAC-SHA1. The 9831 default key-management mechanism which MUST be implemented is the one 9832 defined in the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY 9833 implementation MUST implement the necessary functions for MIKEY-RSA-R 9834 mode [RFC4738] and in addition the SRTP parameter negotiation 9835 necessary to negotiate the supported SRTP transforms and parameters. 9837 22. IANA Considerations 9839 This section sets up a number of registries for RTSP 2.0 that should 9840 be maintained by IANA. These registries are separate from any 9841 registries existing for RTSP 1.0. For each registry there is a 9842 description of what it is required to contain, what specification is 9843 needed when adding an entry with IANA, and finally the entries that 9844 this document needs to register. See also the Section 2.7 "Extending 9845 RTSP". There is also an IANA registration of three SDP attributes. 9847 Registries or entries in registries which have been made for RTSP 1.0 9848 are not moved to RTSP 2.0. The registries and entries in registries 9849 of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry 9850 in a registry is also required in RTSP 2.0, it MUST follow the 9851 procedure defined below to allocate the registry or entry in a 9852 registry. 9854 The sections describing how to register an item uses some of the 9855 registration policies described in RFC 5226 [RFC5226], namely "First 9856 Come, First Served", "Expert Review, "Specification Required", and 9857 "Standards Action". 9859 RFC-Editor Note: Please replace all occurrences of RFCXXXX with 9860 the RFC number this specification receives when published. 9862 In case a registry requires a contact person, the authors, with 9863 Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are 9864 the contact persons for any entries created by this document. 9866 IANA will request the following information for any registration 9867 request: 9869 o A name of the item to register according to the rules specified by 9870 the intended registry. 9872 o Indication of who has change control over the feature (for 9873 example, IETF, ISO, ITU-T, other international standardization 9874 bodies, a consortium, a particular company or group of companies, 9875 or an individual); 9877 o A reference to a further description, if available, for example 9878 (in decreasing order of preference) an RFC, a published standard, 9879 a published paper, a patent filing, a technical report, documented 9880 source code or a computer manual; 9882 o For proprietary features, contact information (postal and email 9883 address); 9885 22.1. Feature-tags 9886 22.1.1. Description 9888 When a client and server try to determine what part and functionality 9889 of the RTSP specification and any future extensions that its counter 9890 part implements there is need for a namespace. This registry 9891 contains named entries representing certain functionality. 9893 The usage of feature-tags is explained in Section 11 and 9894 Section 13.1. 9896 22.1.2. Registering New Feature-tags with IANA 9898 The registering of feature-tags is done on a First Come, First Served 9899 [RFC5226] basis. 9901 The registry entry for a feature-tag has the following information: 9903 o The name of the feature-tag 9905 * If the registrant indicates that the feature is proprietary, 9906 IANA should request a vendor "prefix" portion of the name. The 9907 name will then be the vendor prefix followed by a "." followed 9908 by the rest of the provided feature name. 9910 * If the feature is not proprietary, then IANA need not collect a 9911 prefix for the name. 9913 o A one paragraph description of what the feature-tag represents 9915 o The applicability (server, client, proxy, or some combination) 9917 o A reference to a specification, if applicable 9919 Feature-tag names (including the vendor prefix) may contain any non- 9920 space and non-control characters. There is no length limit on 9921 feature-tags. 9923 Examples for a vendor tag describing a proprietary feature are: 9925 vendorA.specfeat01 9927 vendorA.specfeat02 9929 22.1.3. Registered entries 9931 The following feature-tags are defined in this specification and 9932 hereby registered. The change control belongs to the IETF. 9934 play.basic: The implementation for delivery and playback operations 9935 according to the core RTSP specification, as defined in this 9936 memo. Applies for both clients, servers and proxies. See 9937 Section 11.1. 9939 play.scale: Support of scale operations for media playback. Applies 9940 only for servers. See Section 18.46. 9942 play.speed: Support of the speed functionality for media delivery. 9943 Applies only for servers. See Section 18.50. 9945 setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as 9946 discussed in Appendix C.1.6.4. Applies for both client and 9947 servers and any media caching proxy. 9949 This should be represented by IANA as a table with the feature tags, 9950 contact person and their references. 9952 22.2. RTSP Methods 9954 22.2.1. Description 9956 Methods are described in Section 13. Extending the protocol with new 9957 methods allow for totally new functionality. 9959 22.2.2. Registering New Methods with IANA 9961 A new method is registered through an IETF Standards Action 9962 [RFC5226]. The reason is that new methods may radically change the 9963 protocol's behavior and purpose. 9965 A specification for a new RTSP method consist of the following items: 9967 o A method name which follows the ABNF rules for methods. 9969 o A clear specification what a request using the method does and 9970 what responses are expected. Which directions the method is used, 9971 C->S or S->C or both. How the use of headers, if any, modifies 9972 the behavior and effect of the method. 9974 o A list or table specifying which of the IANA registered headers 9975 that are allowed to be used with the method in request or/and 9976 response. The list or table SHOULD follow the format of tables in 9977 Section 18. 9979 o Describe how the method relates to network proxies. 9981 22.2.3. Registered Entries 9983 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 9984 GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, 9985 SET_PARAMETER, and TEARDOWN. The initial table of the registry is 9986 provided below. 9988 Method Directionality Reference 9989 ----------------------------------------------------- 9990 DESCRIBE C->S [RFCXXXX] 9991 GET_PARAMETER C->S, S->C [RFCXXXX] 9992 OPTIONS C->S, S->C [RFCXXXX] 9993 PAUSE C->S [RFCXXXX] 9994 PLAY C->S [RFCXXXX] 9995 PLAY_NOTIFY S->C [RFCXXXX] 9996 REDIRECT S->C [RFCXXXX] 9997 SETUP C->S [RFCXXXX] 9998 SET_PARAMETER C->S, S->C [RFCXXXX] 9999 TEARDOWN C->S, S->C [RFCXXXX] 10001 22.3. RTSP Status Codes 10003 22.3.1. Description 10005 A status code is the three digit number used to convey information in 10006 RTSP response messages, see Section 8. The number space is limited 10007 and care should be taken not to fill the space. 10009 22.3.2. Registering New Status Codes with IANA 10011 A new status code registration follows the policy of IETF Review 10012 [RFC5226]. New RTSP functionality requiring Status Codes should 10013 first be registered in the range x50-x99. Only when the range is 10014 full should registrations be done in the x00-x49 range, unless it is 10015 to adopt an HTTP extension also to RTSP. The reason is to enable any 10016 HTTP extension to be adopted to RTSP without needing to renumber any 10017 related status codes. A specification for a new status code specify 10018 the following: 10020 o The registered number. 10022 o A description of what the status code means and the expected 10023 behavior of the sender and receiver of the code. 10025 22.3.3. Registered Entries 10027 RFCXXXX, registers the numbered status code defined in the ABNF entry 10028 "Status-Code" except "extension-code" (that defines the syntax 10029 allowed for future extensions) in Section 20.2.2. 10031 22.4. RTSP Headers 10033 22.4.1. Description 10035 By specifying new headers a method(s) can be enhanced in many 10036 different ways. An unknown header will be ignored by the receiving 10037 agent. If the new header is vital for a certain functionality, a 10038 feature-tag for the functionality can be created and demanded to be 10039 used by the counter-part with the inclusion of a Require header 10040 carrying the feature-tag. 10042 22.4.2. Registering New Headers with IANA 10044 Registrations in the registry can be done following the Expert Review 10045 policy [RFC5226]. A specification is recommended to be provided, 10046 preferably an IETF RFC or other Standards Developing Organization 10047 specification. The minimal information in a registration request is 10048 the header name and the contact information. 10050 The expert reviewer verifies that the registration request contain 10051 the following information: 10053 o The name of the header. 10055 o An ABNF specification of the header syntax. 10057 o A list or table specifying when the header may be used, 10058 encompassing all methods, their request or response, the direction 10059 (C->S or S->C). 10061 o How the header is to be handled by proxies. 10063 o A description of the purpose of the header. 10065 22.4.3. Registered entries 10067 All headers specified in Section 18 in RFCXXXX are to be registered. 10068 The Registry is to include header name and reference. 10070 Furthermore the following legacy RTSP headers defined in other 10071 specifications are registered with header name, reference and 10072 description according to below list. Note: These references may not 10073 fulfill all of the above rules for registrations due to their legacy 10074 status. 10076 o x-wap-profile defined in [TS-26234]. The x-wap-profile request- 10077 header contains one or more absolute URLs to the requesting 10078 agent's device capability profile. 10080 o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff 10081 request-header contains a subset of a device capability profile. 10083 o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- 10084 warning is a response-header that contains error codes explaining 10085 to what extent the server has been able to match the terminal 10086 request in regards to device capability profile as described using 10087 x-wap-profile and x-wap-profile-diff headers. 10089 o x-predecbufsize defined in [TS-26234]. This response-header 10090 provides an RTSP agent with the TS 26.234 Annex G hypothetical 10091 pre-decoder buffer size. 10093 o x-initpredecbufperiod defined in [TS-26234]. This response-header 10094 provides an RTSP agent with the TS 26.234 Annex G hypothetical 10095 pre-decoder buffering period. 10097 o x-initpostdecbufperiod defined in [TS-26234]. This response- 10098 header provides an RTSP agent with the TS 26.234 Annex G post- 10099 decoder buffering period. 10101 o 3gpp-videopostdecbufsize defined in [TS-26234]. This response- 10102 header provides an RTSP agent with the TS 26.234 defined post- 10103 decoder buffer size usable for H.264 (AVC) video streams. 10105 o 3GPP-Link-Char defined in [TS-26234]. This request-header 10106 provides the RTSP server with the RTSP client's link 10107 characteristics as determined from the radio interface. The 10108 information that can be provided are guaranteed bit-rate, maximum 10109 bit-rate and maximum transfer delay. 10111 o 3GPP-Adaptation defined in [TS-26234]. This general-header is 10112 part of the bit-rate adaptation solution specified for PSS. It 10113 provides the RTSP client's buffer sizes and target buffer levels 10114 to the server and responses are used to acknowledge the support 10115 and values. 10117 o 3GPP-QoE-Metrics defined in [TS-26234]. This general-header is 10118 used by PSS RTSP agents to negotiate the quality of experience 10119 metrics that a client should gather and report to the server. 10121 o 3GPP-QoE-Feedback defined in [TS-26234]. This request-header is 10122 used by RTSP clients supporting PSS to report the actual values of 10123 the metrics gathered in its quality of experience metering. 10125 The use of "x-" is NOT RECOMMENDED but the above headers in the 10126 register list were defined prior to the clarification. 10128 22.5. Accept-Credentials 10130 The security framework's TLS connection mechanism has two 10131 registerable entities. 10133 22.5.1. Accept-Credentials policies 10135 This registry are for polices for a RTSP proxy's handling and 10136 verification of TLS certificates when establishing outbound TLS 10137 connection on clients behalf. In Section 19.3.1 three policies for 10138 how to handle certificates are specified. Further policies may be 10139 defined and registration is done through an IETF Standards Action 10140 [RFC5226]. The registration is required to contain the following 10141 information: 10143 o Name of the policy. 10145 o A describing text that explains how the policy works for handling 10146 the certificates. 10148 o A contact person. 10150 This specification registers the following values: 10152 Any: A policy requiring the proxy to accept any received 10153 certificate. 10155 Proxy: A policy where the proxy applies its own policies to 10156 determine which certificates are accepted or not. 10158 User: A policy where the certificate is required to be forwarded down 10159 the proxy chain to the client, thus allowing the user to 10160 decided to accept or refuse a certificate. 10162 22.5.2. Accept-Credentials hash algorithms 10164 The Accept-Credentials header (See Section 18.2) allows for the usage 10165 of other algorithms for hashing the DER records of accepted entities. 10166 The registration of any future algorithm is expected to be extremely 10167 rare and could also cause interoperability problems. Therefore the 10168 bar for registering new algorithms is intentionally placed high. 10170 Any registration of a new hash algorithm requires an IETF Standards 10171 Action [RFC5226]. The registration needs to fulfill the following 10172 requirement: 10174 o The algorithms identifier meeting the "token" ABNF requirement. 10176 o Provide a definition of the algorithm. 10178 The registered value is: 10180 Hash Alg. Id Reference 10181 ------------------------ 10182 sha-256 [RFCXXXX] 10184 22.6. Cache-Control Cache Directive Extensions 10186 There exists a number of cache directives which can be sent in the 10187 Cache-Control header. A registry for these cache directives is 10188 established by IANA. New registrations in this registry requires an 10189 IETF Standards Action or IESG Approval [RFC5226]. The registration 10190 needs to contain the following information. 10192 o Name of the directive 10194 o A definition of the parameter value, if any is allowed. 10196 o Specification if it is a request or response directive. 10198 o A describing text that explains how the cache directive is used 10199 for RTSP controlled media streams. 10201 o A contact person. 10203 This specification registers the following values: 10205 no-cache: 10207 public: 10209 private: 10211 no-transform: 10213 only-if-cached: 10215 max-stale: 10217 min-fresh: 10219 must-revalidate: 10221 proxy-revalidate: 10223 max-age: 10225 The registry should be represented as: Name of the directive, contact 10226 person and reference. 10228 22.7. Media Properties 10230 22.7.1. Description 10232 The media streams being controlled by RTSP can have many different 10233 properties. The media properties required to cover the use cases 10234 that were in mind when writing the specification are defined. 10235 However, it can be expected that further innovation will result in 10236 new use cases or media streams with properties not covered by the 10237 ones specified here. Thus new media properties can be specified. As 10238 new media properties may need a substantial amount of new definitions 10239 to correctly specify behavior for this property the bar is intended 10240 to be high. 10242 22.7.2. Registration Rules 10244 Registering a new media property is done following the Specification 10245 Required policy [RFC5226]. The Expert reviewer verifies that a 10246 registration request fulfill the following requirements. 10248 o Have an ABNF definition of the media property value name that 10249 meets "media-prop-ext" definition. 10251 o Define which media property group it belongs to or define a new 10252 group. 10254 o Description of all changes to the behavior of the RTSP protocol as 10255 result of these changes. 10257 o A Contact Person for the Registration. 10259 22.7.3. Registered Values 10261 This specification registers the ten values listed in Section 18.29. 10262 The registry should be represented as: Name of the media property, 10263 property group, contact person and reference. 10265 22.8. Notify-Reason header 10267 22.8.1. Description 10269 Notify-Reason values are used for indicating the reason the 10270 notification was sent. Each reason has its associated rules on what 10271 headers and information that may or must be included in the 10272 notification. New notification behaviors need to be specified to 10273 enable interoperable usage, thus a specification of each new value is 10274 required. 10276 22.8.2. Registration Rules 10278 Registrations for new Notify-Reason value follows the Specification 10279 Required policy [RFC5226]. The Expert Reviewer verifies that the 10280 request fulfills the following requirements: 10282 o An ABNF definition of the Notify reason value name that meets 10283 "Notify-Reason-extension" definition 10285 o Description of which headers shall be included in the request and 10286 response, when it should be sent, and any effect it has on the 10287 server client state. 10289 o A Contact Person for the Registration 10291 22.8.3. Registered Values 10293 This specification registers 3 values defined in the Notify-Reas-val 10294 ABNF, Section 20.2.3: 10296 end-of-stream: This Notify-Reason value indicates the end of a media 10297 stream. 10299 media-properties-update: This Notify-Reason value allows the server 10300 to indicate that the properties of the media has changed during 10301 the playout. 10303 scale-change: This Notify-Reason value allows the server to notify 10304 the client about a change in the Scale of the media. 10306 The registry entries should be represented in the registry as: Name, 10307 short description, contact and reference. 10309 22.9. Range Header Formats 10311 22.9.1. Description 10313 The Range header (Section 18.40) allows for different range formats. 10314 These range formats also needs an identifier to be used the Accept- 10315 Ranges header (Section 18.5). New range formats may be registered, 10316 but moderation should be applied as it makes interoperability more 10317 difficult. 10319 22.9.2. Registration Rules 10321 A registration follows the Specification Required policy [RFC5226]. 10322 The Expert Reviewer verifies that the request fulfills the following 10323 requirements: 10325 o An ABNF definition of the range format that fulfills the "range- 10326 ext" definition. 10328 o Define the range format identifier used in Accept-Ranges header 10329 according to the "extension-format" definition. 10331 o Rules for how one handles the range when using a negative Scale. 10333 o A Contact person for the registration. 10335 22.9.3. Registered Values 10337 The registry should be represented as: Range header format 10338 identifier, Name of the range format, contact person and reference. 10339 This specification registers the following values. 10341 npt: Normal Play Time 10343 clock: UTC Absolute Time format 10345 smpte: SMPTE Timestamps 10347 smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop) 10349 smpte-25: SMPTE Timestamps 25 Frames/sec 10351 22.10. Terminate-Reason Header 10353 The Terminate-Reason header (Section 18.52) has two registries for 10354 extensions. 10356 22.10.1. Redirect Reasons 10358 This registry contains reasons for session Termination that can be 10359 included in a Terminate-Reason header (Section 18.52). Registrations 10360 are following the policy of Expert Review [RFC5226]. The Expert 10361 Reviewer verifies that the registration contains the following 10362 information: 10364 o The value follows the Terminate-Reason ABNF, i.e., be a token. 10366 o That the specification provide a definition of what procedures are 10367 to be followed when a client receives this redirect reason. 10369 o A Contact Person 10371 This specification registers three values: 10373 o Session-Timeout 10375 o Server-Admin 10377 o Internal-Error 10379 The registry should be represented as: Name of the Redirect Reason, 10380 contact person and reference. 10382 22.10.2. Terminate-Reason Header Parameters 10384 This registry contains parameters that may be included in the 10385 Terminate-Reason header (Section 18.52) in addition to a reason. 10386 Registrations are done under the policy of Specification Required 10387 [RFC5226]. The Expert Reviewer verifies that the registration or the 10388 reference specification contains the following: 10390 o A Parameter Name. 10392 o A Parameter following the syntax allowed by the RTSP 2.0 10393 specification. 10395 o A Reference to the specification. 10397 o A contact person. 10399 This specification registers: 10401 o time 10403 o user-msg 10404 The registry should be represented as: Name of the Terminate Reason, 10405 contact person and reference. 10407 22.11. RTP-Info header parameters 10409 22.11.1. Description 10411 The RTP-Info header (Section 18.45) carries one or more parameter 10412 value pairs with information about a particular point in the RTP 10413 stream. RTP extensions or new usages may need new types of 10414 information. As RTP information that could be needed is likely to be 10415 generic enough and to maximize the interoperability, new registration 10416 requires Specification Required. 10418 22.11.2. Registration Rules 10420 Registrations for new RTP-Info values follows the policy of 10421 Specification Required [RFC5226]. The Expert Reviewer verifies that 10422 the registration and its reference contains the following 10423 information. 10425 o Have an ABNF definition that meets the "generic-param" definition. 10427 o A Reference to the specification. 10429 o A Contact Person for the Registration. 10431 22.11.3. Registered Values 10433 This specification registers the following parameter value pairs: 10435 o url 10437 o ssrc 10439 o seq 10441 o rtptime 10443 The registry should be represented as: Name of the parameter, contact 10444 person and reference. 10446 22.12. Seek-Style Policies 10447 22.12.1. Description 10449 Seek-Style Policies defines how the RTSP agent seeks in media content 10450 when given a position within the media content. New seek policies 10451 may be registered, however, a large number of these will complicate 10452 implementation substantially. The impact of unknown policies is that 10453 the server will not honor the unknown and use the server default 10454 policy instead. 10456 22.12.2. Registration Rules 10458 Registrations of new Seek-Style polices follows the policy of 10459 Specification Required [RFC5226]. The Expert Reviewer verifies that 10460 the registration fulfill the following requirements: 10462 o Have an ABNF definition of the Seek-Style policy name that meets 10463 "Seek-S-value-ext" definition 10465 o Short Description 10467 o A Contact Person for the Registration 10469 o Description of which headers shall be included in the request and 10470 response, when it should be sent, and any affect it has on the 10471 server client state. 10473 22.12.3. Registered Values 10475 This specification registers 4 values (Name - Short Description): 10477 o RAP - Using the closest Random Access Point prior or at the 10478 requested start position. 10480 o CoRAP - Conditional Random Access Point is like RAP, but only if 10481 the RAP is closer prior to the requested start position than 10482 current pause point. 10484 o First-Prior - The first-prior policy will start delivery with the 10485 media unit that has a playout time first prior to the requested 10486 start position. 10488 o Next - The next media units after the provided start position. 10490 The registry should be represented as: Name of the Seek-Style Policy, 10491 short description, contact person and reference. 10493 22.13. Transport Header Registries 10495 The transport header (Section 18.54) contains a number of parameters 10496 which have possibilities for future extensions. Therefore registries 10497 for these need to be defined. 10499 22.13.1. Transport Protocol Identifier 10501 A Transport Protocol Specification consists of a Transport Protocol 10502 Identifier, representing some combination of transport protocols, and 10503 any number of transport header parameters required or optional to use 10504 with the identified protocol specification. This registry contains 10505 the identifiers used by registered Transport Protocol Identifiers. 10507 A registration for the parameter transport protocol identifier 10508 follows the policy of Specification Required [RFC5226]. The expert 10509 reviewer verifies that the registration fulfill the following 10510 requirements: 10512 o A contact person or organization with address and email. 10514 o A value definition that are following the ABNF syntax definition 10515 of "transport-id" Section 20.2.3. 10517 o A descriptive text that explains how the registered value are used 10518 in RTSP, which underlying transport protocols that are used, and 10519 any required Transport header parameters. 10521 The registry should be represented as: The protocol ID string, 10522 contact person and reference. 10524 This specification registers the following values: 10526 RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in 10527 combination with the "RTP profile for audio and video 10528 conferences with minimal control" [RFC3551] over UDP. The 10529 usage is explained in RFC XXXX, Appendix C.1. 10531 RTP/AVP/UDP: the same as RTP/AVP. 10533 RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in 10534 combination with the "Extended RTP Profile for RTCP-based 10535 Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is 10536 explained in RFC XXXX, Appendix C.1. 10538 RTP/AVPF/UDP: the same as RTP/AVPF. 10540 RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in 10541 combination with the "The Secure Real-time Transport Protocol 10542 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 10543 XXXX, Appendix C.1. 10545 RTP/SAVP/UDP: the same as RTP/SAVP. 10547 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 10548 combination with the Extended Secure RTP Profile for Real-time 10549 Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 10550 [RFC5124] over UDP. The usage is explained in RFC XXXX, 10551 Appendix C.1. 10553 RTP/SAVPF/UDP: the same as RTP/SAVPF. 10555 RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10556 in combination with the "RTP profile for audio and video 10557 conferences with minimal control" [RFC3551] over TCP. The 10558 usage is explained in RFC XXXX, Appendix C.2.2. 10560 RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10561 in combination with the "Extended RTP Profile for RTCP-based 10562 Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is 10563 explained in RFC XXXX, Appendix C.2.2. 10565 RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10566 in combination with the "The Secure Real-time Transport 10567 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 10568 RFC XXXX, Appendix C.2.2. 10570 RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10571 in combination with the "Extended Secure RTP Profile for Real- 10572 time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 10573 SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 10574 XXXX, Appendix C.2.2. 10576 22.13.2. Transport modes 10578 The Transport Mode is a Transport header (Section 18.54) parameter, 10579 it is used to identify the general mode of media transport. The PLAY 10580 value registered defines a PLAYBACK mode, where media flows from 10581 Server to Client. 10583 A registration for the transport parameter mode follows the policy of 10584 IETF Standards Action [RFC5226]. The registration needs to meet the 10585 following requirements: 10587 o A value definition that are following the ABNF "token" definition 10588 Section 20.2.3. 10590 o A describing text that explains how the registered value are used 10591 in RTSP. 10593 This specification registers 1 value: 10595 PLAY: See RFC XXXX. 10597 The registry should be represented as: The Transport Mode value, 10598 contact person and reference. 10600 22.13.3. Transport Parameters 10602 Transport Parameters are different parameters used in a Transport 10603 Header's transport specification (Section 18.54) to provide 10604 additional information required beyond the transport protocol 10605 identifier to establish a functioning transport. 10607 A registration for parameters that may be included in the Transport 10608 header follows the policy of Specification Required [RFC5226]. The 10609 expert reviewer verifies that the registration fulfill the following 10610 requirements: 10612 o A Transport Parameter Name following the "token" ABNF definition. 10614 o A value definition, if the parameter takes a value, that are 10615 following the ABNF definition "trn-par-value" Section 20.2.3. 10617 o A describing text that explains how the registered value are used 10618 in RTSP. 10620 This specification registers all the transport parameters defined in 10621 Section 18.54. This is a copy of this list: 10623 o unicast 10625 o multicast 10627 o interleaved 10629 o ttl 10631 o layers 10633 o ssrc 10634 o mode 10636 o dest_addr 10638 o src_addr 10640 o setup 10642 o connection 10644 o RTCP-mux 10646 o MIKEY 10648 The registry should be represented as: The transport parameter name, 10649 contact person and reference. 10651 22.14. URI Schemes 10653 This specification updates two URI schemes, one previously registered 10654 "rtsp", and one missing in the registry "rtspu", previously only 10655 defined in the RTSP 1.0 [RFC2326], one new URI scheme "rtsps" is also 10656 registered. These URI schemes are registered in an existing registry 10657 (Uniform Resource Identifier (URI) Schemes) which is not created by 10658 this memo. Registrations are following RFC 4395[RFC4395]. 10660 22.14.1. The rtsp URI Scheme 10662 URI scheme name: rtsp 10664 Status: Permanent 10666 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10668 URI scheme semantics: The rtsp scheme is used to indicate resources 10669 accessible through the usage of the Real-time Streaming 10670 Protocol (RTSP). RTSP allows different operations on the 10671 resource identified by the URI, but the primary purpose is the 10672 streaming delivery of the resource to a client. However, the 10673 operations that are currently defined are: DESCRIBE, 10674 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10675 SETUP, SET_PARAMETER, and TEARDOWN. 10677 Encoding considerations: IRIs in this scheme are defined and needs 10678 to be encoded as RTSP URIs when used within the RTSP protocol. 10679 That encoding is done according to RFC 3987. 10681 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10682 2326), RTSP 2.0 (RFC XXXX) 10684 Interoperability considerations: The extensions in the URI syntax 10685 performed between RTSP 1.0 and 2.0 can create interoperability 10686 issues. The changes are: 10688 Support for IPV6 literal in host part and future IP literals 10689 through RFC 3986 defined mechanism. 10691 A new relative format to use in the RTSP protocol elements 10692 that is not required to start with "/". 10694 The above changes should have no impact on interoperability as 10695 in detail discussed in Section 4.2 of RFCXXXX. 10697 Security considerations: All the security threats identified in 10698 Section 7 of RFC 3986 apply also to this scheme. They need to 10699 be reviewed and considered in any implementation utilizing this 10700 scheme. 10702 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10704 Author/Change controller: IETF 10706 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10708 22.14.2. The rtsps URI Scheme 10710 URI scheme name: rtsps 10712 Status: Permanent 10714 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10716 URI scheme semantics: The rtsps scheme is used to indicate resources 10717 accessible through the usage of the Real-time Streaming 10718 Protocol (RTSP) over TLS. RTSP allows different operations on 10719 the resource identified by the URI, but the primary purpose is 10720 the streaming delivery of the resource to a client. However, 10721 the operations that are currently defined are: DESCRIBE, 10722 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10723 SETUP, SET_PARAMETER, and TEARDOWN. 10725 Encoding considerations: IRIs in this scheme are defined and needs 10726 to be encoded as RTSP URIs when used within the RTSP protocol. 10727 That encoding is done according to RFC 3987. 10729 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10730 2326), RTSP 2.0 (RFC XXXX) 10732 Interoperability considerations: The "rtsps" scheme was never 10733 officially defined for RTSP 1.0, however it has seen widespread 10734 use in actual deployments of RTSP 1.0. Therefore this section 10735 discusses the believed changes between the unspecified RTSP 1.0 10736 "rtsps" scheme and RTSP 2.0 definition. The extensions in the 10737 URI syntax performed between RTSP 1.0 and 2.0 can create 10738 interoperability issues. The changes are: 10740 Support for IPV6 literal in host part and future IP literals 10741 through RFC 3986 defined mechanism. 10743 A new relative format to use in the RTSP protocol elements 10744 that is not required to start with "/". 10746 The above changes should have no impact on interoperability as 10747 in detail discussed in Section 4.2 of RFCXXXX. 10749 Security considerations: All the security threats identified in 10750 Section 7 of RFC 3986 apply also to this scheme. They need to 10751 be reviewed and considered in any implementation utilizing this 10752 scheme. 10754 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10756 Author/Change controller: IETF 10758 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10760 22.14.3. The rtspu URI Scheme 10762 URI scheme name: rtspu 10764 Status: Permanent 10766 URI scheme syntax: See Section 3.2 of RFC 2326. 10768 URI scheme semantics: The rtspu scheme is used to indicate resources 10769 accessible through the usage of the Real-time Streaming 10770 Protocol (RTSP) over unreliable datagram transport. RTSP 10771 allows different operations on the resource identified by the 10772 URI, but the primary purpose is the streaming delivery of the 10773 resource to a client. However, the operations that are 10774 currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, 10775 REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and 10776 TEARDOWN. 10778 Encoding considerations: This scheme is not intended to be used with 10779 characters outside the US-ASCII repertoire. 10781 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10782 2326) 10784 Interoperability considerations: The definition of the transport 10785 mechanism of RTSP over UDP has interoperability issues. That 10786 makes the usage of this scheme problematic. 10788 Security considerations: All the security threats identified in 10789 Section 7 of RFC 3986 apply also to this scheme. They needs to 10790 be reviewed and considered in any implementation utilizing this 10791 scheme. 10793 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10795 Author/Change controller: IETF 10797 References: RFC 2326 10799 22.15. SDP attributes 10801 This specification defines three SDP [RFC4566] attributes that it is 10802 requested that IANA register. 10804 SDP Attribute ("att-field"): 10806 Attribute name: range 10807 Long form: Media Range Attribute 10808 Type of name: att-field 10809 Type of attribute: Media and session level 10810 Subject to charset: No 10811 Purpose: RFC XXXX 10812 Reference: RFC XXXX, RFC 2326 10813 Values: See ABNF definition. 10815 Attribute name: control 10816 Long form: RTSP control URI 10817 Type of name: att-field 10818 Type of attribute: Media and session level 10819 Subject to charset: No 10820 Purpose: RFC XXXX 10821 Reference: RFC XXXX, RFC 2326 10822 Values: Absolute or Relative URIs. 10824 Attribute name: mtag 10825 Long form: Message Tag 10826 Type of name: att-field 10827 Type of attribute: Media and session level 10828 Subject to charset: No 10829 Purpose: RFC XXXX 10830 Reference: RFC XXXX 10831 Values: See ABNF definition 10833 22.16. Media Type Registration for text/parameters 10835 Type name: text 10837 Subtype name: parameters 10839 Required parameters: 10841 Optional parameters: charset: The charset parameter is applicable to 10842 the encoding of the parameter values. The default charset is 10843 UTF-8, if the 'charset' parameter is not present. 10845 Encoding considerations: 8bit 10847 Security considerations: This format may carry any type of 10848 parameters. Some can have security requirements, like privacy, 10849 confidentiality or integrity requirements. The format has no 10850 built in security protection. For the usage it was defined the 10851 transport can be protected between server and client using TLS. 10852 However, care must be taken to consider if also the proxies are 10853 trusted with the parameters in case hop-by-hop security is used. 10854 If stored as a file in file system, the necessary precautions need 10855 to be taken in relation to the parameters requirements including 10856 object security such as S/MIME [RFC5751]. 10858 Interoperability considerations: This media type was mentioned as a 10859 fictional example in [RFC2326], but was not formally specified. 10860 This has resulted in usage of this media type which may not match 10861 its formal definition. 10863 Published specification: RFC XXXX, Appendix F. 10865 Applications that use this media type: Applications that use RTSP 10866 and have additional parameters they like to read and set using the 10867 RTSP GET_PARAMETER and SET_PARAMETER methods. 10869 Additional information: 10871 Magic number(s): 10873 File extension(s): 10875 Macintosh file type code(s): 10877 Person & email address to contact for further information: Magnus We 10878 sterlund (magnus.westerlund@ericsson.com) 10880 Intended usage: Common 10882 Restrictions on usage: None 10884 Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 10886 Change controller: IETF 10888 Addition Notes: 10890 23. References 10892 23.1. Normative References 10894 [FIPS-pub-180-2] 10895 National Institute of Standards and Technology (NIST), 10896 "Federal Information Processing Standards Publications 10897 (FIPS PUBS) 180-2: Secure Hash Standard", August 2002. 10899 [I-D.ietf-avtcore-rtp-circuit-breakers] 10900 Perkins, C. and V. Singh, "Multimedia Congestion Control: 10901 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 10902 avtcore-rtp-circuit-breakers-04 (work in progress), 10903 January 2014. 10905 [I-D.ietf-mmusic-rtsp-nat] 10906 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 10907 Address Translator (NAT) Traversal Mechanism for Media 10908 Controlled by Real-Time Streaming Protocol (RTSP)", draft- 10909 ietf-mmusic-rtsp-nat-20 (work in progress), February 2014. 10911 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 10912 August 1980. 10914 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 10915 793, September 1981. 10917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10918 Requirement Levels", BCP 14, RFC 2119, March 1997. 10920 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 10921 (IPv6) Specification", RFC 2460, December 1998. 10923 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 10924 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 10925 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 10927 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 10928 Leach, P., Luotonen, A., and L. Stewart, "HTTP 10929 Authentication: Basic and Digest Access Authentication", 10930 RFC 2617, June 1999. 10932 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 10934 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 10935 Jacobson, "RTP: A Transport Protocol for Real-Time 10936 Applications", STD 64, RFC 3550, July 2003. 10938 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 10939 Video Conferences with Minimal Control", STD 65, RFC 3551, 10940 July 2003. 10942 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10943 10646", STD 63, RFC 3629, November 2003. 10945 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 10946 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 10947 RFC 3711, March 2004. 10949 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 10950 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 10951 August 2004. 10953 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 10954 Resource Identifier (URI): Generic Syntax", STD 66, RFC 10955 3986, January 2005. 10957 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 10958 Identifiers (IRIs)", RFC 3987, January 2005. 10960 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 10961 Requirements for Security", BCP 106, RFC 4086, June 2005. 10963 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10964 Architecture", RFC 4291, February 2006. 10966 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 10967 Registration Procedures for New URI Schemes", BCP 35, RFC 10968 4395, February 2006. 10970 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 10971 Description Protocol", RFC 4566, July 2006. 10973 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 10974 and RTP Control Protocol (RTCP) Packets over Connection- 10975 Oriented Transport", RFC 4571, July 2006. 10977 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 10978 "Extended RTP Profile for Real-time Transport Control 10979 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 10980 2006. 10982 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 10983 Encodings", RFC 4648, October 2006. 10985 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 10986 RSA-R: An Additional Mode of Key Distribution in 10987 Multimedia Internet KEYing (MIKEY)", RFC 4738, November 10988 2006. 10990 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 10991 Real-time Transport Control Protocol (RTCP)-Based Feedback 10992 (RTP/SAVPF)", RFC 5124, February 2008. 10994 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 10995 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 10996 May 2008. 10998 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 10999 Specifications: ABNF", STD 68, RFC 5234, January 2008. 11001 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 11002 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 11004 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 11005 Housley, R., and W. Polk, "Internet X.509 Public Key 11006 Infrastructure Certificate and Certificate Revocation List 11007 (CRL) Profile", RFC 5280, May 2008. 11009 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 11010 October 2008. 11012 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 11013 Languages", BCP 47, RFC 5646, September 2009. 11015 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 11016 Mail Extensions (S/MIME) Version 3.2 Message 11017 Specification", RFC 5751, January 2010. 11019 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 11020 Control Packets on a Single Port", RFC 5761, April 2010. 11022 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 11023 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 11025 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 11026 Specifications and Registration Procedures", BCP 13, RFC 11027 6838, January 2013. 11029 [SMPTE_TC] 11030 Society of Motion Picture and Television Engineers, "SMPTE 11031 Standard for Television -- Time and Control Code, ST 11032 12M-1-2008", . 11034 [TS-26234] 11035 Third Generation Partnership Project (3GPP), "Transparent 11036 end-to-end Packet-switched Streaming Service (PSS); 11037 Protocols and codecs; Technical Specification 26.234", 11038 December 2002. 11040 23.2. Informative References 11042 [ISO.13818-6.1995] 11043 International Organization for Standardization, 11044 "Information technology - Generic coding of moving 11045 pictures and associated audio information - part 6: 11046 Extension for digital storage media and control", ISO 11047 Draft Standard 13818-6, November 1995. 11049 [ISO.8601.2000] 11050 International Organization for Standardization, "Data 11051 elements and interchange formats - Information interchange 11052 - Representation of dates and times", ISO/IEC Standard 11053 8601, December 2000. 11055 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 11056 1981. 11058 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 11059 and Support", STD 3, RFC 1123, October 1989. 11061 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 11062 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 11063 RFC 2068, January 1997. 11065 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 11066 Streaming Protocol (RTSP)", RFC 2326, April 1998. 11068 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 11069 Translator (NAT) Terminology and Considerations", RFC 11070 2663, August 1999. 11072 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 11073 Announcement Protocol", RFC 2974, October 2000. 11075 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 11076 A., Peterson, J., Sparks, R., Handley, M., and E. 11077 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 11078 June 2002. 11080 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 11081 with Session Description Protocol (SDP)", RFC 3264, June 11082 2002. 11084 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 11085 Internet: Timestamps", RFC 3339, July 2002. 11087 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 11088 the Session Description Protocol (SDP)", RFC 4145, 11089 September 2005. 11091 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 11092 Carrara, "Key Management Extensions for Session 11093 Description Protocol (SDP) and Real Time Streaming 11094 Protocol (RTSP)", RFC 4567, July 2006. 11096 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 11097 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 11098 July 2006. 11100 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 11101 Formats", RFC 4855, February 2007. 11103 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 11104 the RTP Profile for Audio and Video Conferences", RFC 11105 4856, February 2007. 11107 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 11108 "Codec Control Messages in the RTP Audio-Visual Profile 11109 with Feedback (AVPF)", RFC 5104, February 2008. 11111 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 11112 (ICE): A Protocol for Network Address Translator (NAT) 11113 Traversal for Offer/Answer Protocols", RFC 5245, April 11114 2010. 11116 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 11117 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 11118 October 2008. 11120 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 11121 Dependency in the Session Description Protocol (SDP)", RFC 11122 5583, July 2009. 11124 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 11125 Time Protocol Version 4: Protocol and Algorithms 11126 Specification", RFC 5905, June 2010. 11128 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 11129 "Computing TCP's Retransmission Timer", RFC 6298, June 11130 2011. 11132 [Stevens98] 11133 Stevens, W., "Unix Networking Programming - Volume 1, 11134 second edition", 1998. 11136 Appendix A. Examples 11138 This section contains several different examples trying to illustrate 11139 possible ways of using RTSP. The examples can also help with the 11140 understanding of how functions of RTSP work. However, remember that 11141 these are examples and the normative and syntax description in the 11142 other sections take precedence. Please also note that many of the 11143 examples contain syntax illegal line breaks to accommodate the 11144 formatting restriction that the RFC series impose. 11146 A.1. Media on Demand (Unicast) 11148 This is an example of media on demand streaming of a media stored in 11149 a container file. For purposes of this example, a container file is 11150 a storage entity in which multiple continuous media types pertaining 11151 to the same end-user presentation are present. In effect, the 11152 container file represents an RTSP presentation, with each of its 11153 components being RTSP controlled media streams. Container files are 11154 a widely used means to store such presentations. While the 11155 components are transported as independent streams, it is desirable to 11156 maintain a common context for those streams at the server end. 11158 This enables the server to keep a single storage handle open 11159 easily. It also allows treating all the streams equally in case 11160 of any prioritization of streams by the server. 11162 It is also possible that the presentation author may wish to prevent 11163 selective retrieval of the streams by the client in order to preserve 11164 the artistic effect of the combined media presentation. Similarly, 11165 in such a tightly bound presentation, it is desirable to be able to 11166 control all the streams via a single control message using an 11167 aggregate URI. 11169 The following is an example of using a single RTSP session to control 11170 multiple streams. It also illustrates the use of aggregate URIs. In 11171 a container file it is also desirable to not write any URI parts 11172 which are not kept, when the container is distributed, like the host 11173 and most of the path element. Therefore this example also uses the 11174 "*" and relative URI in the delivered SDP. 11176 Also this presentation description (SDP) is not cacheble, as the 11177 Expires header is set to an equal value with date indicating 11178 immediate expiration of its validity. 11180 Client C requests a presentation from media server M. The movie is 11181 stored in a container file. The client has obtained an RTSP URI to 11182 the container file. 11184 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11185 CSeq: 1 11186 User-Agent: PhonyClient/1.2 11188 M->C: RTSP/2.0 200 OK 11189 CSeq: 1 11190 Server: PhonyServer/1.0 11191 Date: Fri, 20 Dec 2013 10:20:32 +0000 11192 Content-Type: application/sdp 11193 Content-Length: 271 11194 Content-Base: rtsp://example.com/twister.3gp/ 11195 Expires: Fri, 20 Dec 2013 12:20:32 +0000 11197 v=0 11198 o=- 2890844256 2890842807 IN IP4 198.51.100.5 11199 s=RTSP Session 11200 i=An Example of RTSP Session Usage 11201 e=adm@example.com 11202 c=IN IP4 0.0.0.0 11203 a=control: * 11204 a=range:npt=00:00:00-00:10:34.10 11205 t=0 0 11206 m=audio 0 RTP/AVP 0 11207 a=control: trackID=1 11208 m=video 0 RTP/AVP 26 11209 a=control: trackID=4 11211 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11212 CSeq: 2 11213 User-Agent: PhonyClient/1.2 11214 Require: play.basic 11215 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11216 Accept-Ranges: npt, smpte, clock 11218 M->C: RTSP/2.0 200 OK 11219 CSeq: 2 11220 Server: PhonyServer/1.0 11221 Transport: RTP/AVP;unicast; ssrc=93CB001E; 11222 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11223 src_addr="198.51.100.5:9000"/"198.51.100.5:9001" 11224 Session: 12345678 11225 Expires: Fri, 20 Dec 2013 12:20:33 +0000 11226 Date: Fri, 20 Dec 2013 10:20:33 +0000 11227 Accept-Ranges: npt 11228 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11230 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11231 CSeq: 3 11232 User-Agent: PhonyClient/1.2 11233 Require: play.basic 11234 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11235 Session: 12345678 11236 Accept-Ranges: npt, smpte, clock 11238 M->C: RTSP/2.0 200 OK 11239 CSeq: 3 11240 Server: PhonyServer/1.0 11241 Transport: RTP/AVP;unicast; ssrc=A813FC13; 11242 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 11243 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11245 Session: 12345678 11246 Expires: Fri, 20 Dec 2013 12:20:33 +0000 11247 Date: Fri, 20 Dec 2013 10:20:33 +0000 11248 Accept-Range: NPT 11249 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11251 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11252 CSeq: 4 11253 User-Agent: PhonyClient/1.2 11254 Range: npt=30- 11255 Seek-Style: RAP 11256 Session: 12345678 11258 M->C: RTSP/2.0 200 OK 11259 CSeq: 4 11260 Server: PhonyServer/1.0 11261 Date: Fri, 20 Dec 2013 10:20:34 +0000 11262 Session: 12345678 11263 Range: npt=30-634.10 11264 Seek-Style: RAP 11265 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11266 ssrc=0D12F123:seq=12345;rtptime=3450012, 11267 url="rtsp://example.com/twister.3gp/trackID=1" 11268 ssrc=4F312DD8:seq=54321;rtptime=2876889 11270 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 11271 CSeq: 5 11272 User-Agent: PhonyClient/1.2 11273 Session: 12345678 11275 # Pause happens 0.87 seconds after starting to play 11277 M->C: RTSP/2.0 200 OK 11278 CSeq: 5 11279 Server: PhonyServer/1.0 11280 Date: Fri, 20 Dec 2013 10:20:35 +0000 11281 Session: 12345678 11282 Range: npt=30.87-634.10 11284 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11285 CSeq: 6 11286 User-Agent: PhonyClient/1.2 11287 Range: npt=30.87-634.10 11288 Seek-Style: Next 11289 Session: 12345678 11291 M->C: RTSP/2.0 200 OK 11292 CSeq: 6 11293 Server: PhonyServer/1.0 11294 Date: Fri, 20 Dec 2013 10:22:13 +0000 11295 Session: 12345678 11296 Range: npt=30.87-634.10 11297 Seek-Style: Next 11298 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11299 ssrc=0D12F123:seq=12555;rtptime=6330012, 11300 url="rtsp://example.com/twister.3gp/trackID=1" 11301 ssrc=4F312DD8:seq=55021;rtptime=3132889 11303 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 11304 CSeq: 7 11305 User-Agent: PhonyClient/1.2 11306 Session: 12345678 11308 M->C: RTSP/2.0 200 OK 11309 CSeq: 7 11310 Server: PhonyServer/1.0 11311 Date: Fri, 20 Dec 2013 10:31:53 +0000 11313 A.2. Media on Demand using Pipelining 11315 This example is basically the example above (Appendix A.1), but now 11316 utilizing pipelining to speed up the setup. It requires only two 11317 round trip times until the media starts flowing. First of all, the 11318 session description is retrieved to determine what media resources 11319 need to be setup. In the second step, one sends the necessary SETUP 11320 requests and the PLAY request to initiate media delivery. 11322 Client C requests a presentation from media server M. The movie is 11323 stored in a container file. The client has obtained an RTSP URI to 11324 the container file. 11326 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11327 CSeq: 1 11328 User-Agent: PhonyClient/1.2 11330 M->C: RTSP/2.0 200 OK 11331 CSeq: 1 11332 Server: PhonyServer/1.0 11333 Date: Fri, 20 Dec 2013 10:20:32 +0000 11334 Content-Type: application/sdp 11335 Content-Length: 271 11336 Content-Base: rtsp://example.com/twister.3gp/ 11337 Expires: Fri, 20 Dec 2013 12:20:32 +0000 11339 v=0 11340 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11341 s=RTSP Session 11342 i=An Example of RTSP Session Usage 11343 e=adm@example.com 11344 c=IN IP4 0.0.0.0 11345 a=control: * 11346 a=range:npt=00:00:00-00:10:34.10 11347 t=0 0 11348 m=audio 0 RTP/AVP 0 11349 a=control: trackID=1 11350 m=video 0 RTP/AVP 26 11351 a=control: trackID=4 11353 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11354 CSeq: 2 11355 User-Agent: PhonyClient/1.2 11356 Require: play.basic 11357 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11358 Accept-Ranges: npt, smpte, clock 11359 Pipelined-Requests: 7654 11361 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11362 CSeq: 3 11363 User-Agent: PhonyClient/1.2 11364 Require: play.basic 11365 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11366 Accept-Ranges: npt, smpte, clock 11367 Pipelined-Requests: 7654 11369 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11370 CSeq: 4 11371 User-Agent: PhonyClient/1.2 11372 Range: npt=0- 11373 Seek-Style: RAP 11374 Pipelined-Requests: 7654 11376 M->C: RTSP/2.0 200 OK 11377 CSeq: 2 11378 Server: PhonyServer/1.0 11379 Transport: RTP/AVP;unicast; 11380 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11381 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11382 ssrc=93CB001E 11383 Session: 12345678 11384 Expires: Fri, 20 Dec 2013 12:20:32 +0000 11385 Date: Fri, 20 Dec 2013 10:20:32 +0000 11386 Accept-Ranges: npt 11387 Pipelined-Requests: 7654 11388 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11390 M->C: RTSP/2.0 200 OK 11391 CSeq: 3 11392 Server: PhonyServer/1.0 11393 Transport: RTP/AVP;unicast; 11394 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11395 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11396 ssrc=A813FC13 11397 Session: 12345678 11398 Expires: Sat, 21 Dec 2013 10:20:32 +0000 11399 Date: Fri, 20 Dec 2013 10:20:32 +0000 11400 Accept-Range: NPT 11401 Pipelined-Requests: 7654 11402 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11404 M->C: RTSP/2.0 200 OK 11405 CSeq: 4 11406 Server: PhonyServer/1.0 11407 Date: Fri, 20 Dec 2013 10:20:32 +0000 11408 Session: 12345678 11409 Range: npt=0-623.10 11410 Seek-Style: RAP 11411 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11412 ssrc=0D12F123:seq=12345;rtptime=3450012, 11413 url="rtsp://example.com/twister.3gp/trackID=1" 11414 ssrc=4F312DD8:seq=54321;rtptime=2876889 11415 Pipelined-Requests: 7654 11417 A.3. Secured Media Session for on Demand Content 11419 This example is basically the above example (Appendix A.2), but now 11420 including establishment of SRTP crypto contexts to get a secured 11421 media delivery. First of all, the client attempts to fetch this 11422 insecurely, but the server redirects to a URI indicating a 11423 requirement on using a secure connection for the RTSP messages. The 11424 client establishes a TCP/TLS connections and the session description 11425 is retrieved to determine what media resources need to be setup. In 11426 the this session description secure media (SRTP) is indicated. In 11427 the next step, the client sends the necessary SETUP requests 11428 including MIKEY messages. This is pipeline with a PLAY request to 11429 initiate media delivery. 11431 Client C requests a presentation from media server M. The movie is 11432 stored in a container file. The client has obtained an RTSP URI to 11433 the container file. 11435 Note: The MIKEY messages below are not valid MIKEY message and are 11436 BASE64 encoded random data to represent where the MIKEY messages 11437 would go. 11439 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11440 CSeq: 1 11441 User-Agent: PhonyClient/1.2 11443 M->C: RTSP/2.0 301 Moved Permanently 11444 CSeq: 1 11445 Server: PhonyServer/1.0 11446 Date: Fri, 20 Dec 2013 10:25:32 +0000 11447 Location: rtsps://example.com/twister.3gp 11449 C->M: Establish TCP/TLS connection and verify server's 11450 certificate that is represents example.com. 11451 Used for all below RTSP messages. 11453 C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0 11454 CSeq: 2 11455 User-Agent: PhonyClient/1.2 11457 M->C: RTSP/2.0 200 OK 11458 CSeq: 2 11459 Server: PhonyServer/1.0 11460 Date: Fri, 20 Dec 2013 10:25:33 +0000 11461 Content-Type: application/sdp 11462 Content-Length: 271 11463 Content-Base: rtsps://example.com/twister.3gp/ 11464 Expires: Fri, 20 Dec 2013 12:25:33 +0000 11466 v=0 11467 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11468 s=RTSP Session 11469 i=An Example of RTSP Session Usage 11470 e=adm@example.com 11471 c=IN IP4 0.0.0.0 11472 a=control: * 11473 a=range:npt=00:00:00-00:10:34.10 11474 t=0 0 11475 m=audio 0 RTP/SAVP 0 11476 a=control: trackID=1 11477 m=video 0 RTP/SAVP 26 11478 a=control: trackID=4 11480 C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0 11481 CSeq: 3 11482 User-Agent: PhonyClient/1.2 11483 Require: play.basic 11484 Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001"; 11485 MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl 11486 Accept-Ranges: npt, smpte, clock 11487 Pipelined-Requests: 7654 11489 C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0 11490 CSeq: 4 11491 User-Agent: PhonyClient/1.2 11492 Require: play.basic 11493 Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003"; 11494 MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ= 11495 Accept-Ranges: npt, smpte, clock 11496 Pipelined-Requests: 7654 11498 C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0 11499 CSeq: 5 11500 User-Agent: PhonyClient/1.2 11501 Range: npt=0- 11502 Seek-Style: RAP 11503 Pipelined-Requests: 7654 11505 M->C: RTSP/2.0 200 OK 11506 CSeq: 3 11507 Server: PhonyServer/1.0 11508 Transport: RTP/SAVP;unicast; 11509 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11510 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11511 ssrc=93CB001E; 11512 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x 11513 Session: 12345678 11514 Expires: Fri, 20 Dec 2013 12:25:34 +0000 11515 Date: Fri, 20 Dec 2013 10:25:34 +0000 11516 Accept-Ranges: npt 11517 Pipelined-Requests: 7654 11518 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11520 M->C: RTSP/2.0 200 OK 11521 CSeq: 4 11522 Server: PhonyServer/1.0 11523 Transport: RTP/SAVP;unicast; 11524 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11525 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11526 ssrc=A813FC13; 11527 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 11528 Session: 12345678 11529 Expires: Fri, 20 Dec 2013 12:25:34 +0000 11530 Date: Fri, 20 Dec 2013 10:25:34 +0000 11531 Accept-Range: NPT 11532 Pipelined-Requests: 7654 11533 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11535 M->C: RTSP/2.0 200 OK 11536 CSeq: 5 11537 Server: PhonyServer/1.0 11538 Date: Fri, 20 Dec 2013 10:25:34 +0000 11539 Session: 12345678 11540 Range: npt=0-623.10 11541 Seek-Style: RAP 11542 RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" 11543 ssrc=0D12F123:seq=12345;rtptime=3450012, 11544 url="rtsps://example.com/twister.3gp/trackID=1" 11545 ssrc=4F312DD8:seq=54321;rtptime=2876889; 11547 Pipelined-Requests: 7654 11549 A.4. Media on Demand (Unicast) 11551 An alternative example of media on demand with a bit more tweaks is 11552 the following. Client C requests a movie distributed from two 11553 different media servers A (audio.example.com) and V ( 11554 video.example.com). The media description is stored on a web server 11555 W. The media description contains descriptions of the presentation 11556 and all its streams, including the codecs that are available, dynamic 11557 RTP payload types, the protocol stack, and content information such 11558 as language or copyright restrictions. It may also give an 11559 indication about the timeline of the movie. 11561 In this example, the client is only interested in the last part of 11562 the movie. 11564 C->W: GET /twister.sdp HTTP/1.1 11565 Host: www.example.com 11566 Accept: application/sdp 11568 W->C: HTTP/1.1 200 OK 11569 Date: Wed, 23 Jan 2013 15:35:06 GMT 11570 Content-Type: application/sdp 11571 Content-Length: 278 11572 Expires: Thu, 24 Jan 2013 15:35:06 GMT 11574 v=0 11575 o=- 2890844526 2890842807 IN IP4 198.51.100.5 11576 s=RTSP Session 11577 e=adm@example.com 11578 c=IN IP4 0.0.0.0 11579 a=range:npt=00:00:00-01:49:34 11580 t=0 0 11581 m=audio 0 RTP/AVP 0 11582 a=control:rtsp://audio.example.com/twister/audio.en 11583 m=video 0 RTP/AVP 31 11584 a=control:rtsp://video.example.com/twister/video 11586 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 11587 CSeq: 1 11588 User-Agent: PhonyClient/1.2 11589 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 11590 RTP/AVP/TCP;unicast;interleaved=0-1 11591 Accept-Ranges: npt, smpte, clock 11593 A->C: RTSP/2.0 200 OK 11594 CSeq: 1 11595 Session: 12345678 11596 Transport: RTP/AVP/UDP;unicast; 11597 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11598 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11599 Date: Wed, 23 Jan 2013 15:35:12 +0000 11600 Server: PhonyServer/1.0 11601 Expires: Thu, 24 Jan 2013 15:35:12 +0000 11602 Cache-Control: public 11603 Accept-Ranges: npt, smpte 11604 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11606 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 11607 CSeq: 1 11608 User-Agent: PhonyClient/1.2 11609 Transport: RTP/AVP/UDP;unicast; 11610 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", 11611 RTP/AVP/TCP;unicast;interleaved=0-1 11612 Accept-Ranges: npt, smpte, clock 11614 V->C: RTSP/2.0 200 OK 11615 CSeq: 1 11616 Session: 23456789 11617 Transport: RTP/AVP/UDP;unicast; 11618 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; 11619 src_addr="198.51.100.5:5002"/"198.51.100.5:5003" 11620 Date: Wed, 23 Jan 2013 15:35:12 +0000 11621 Server: PhonyServer/1.0 11622 Cache-Control: public 11623 Expires: Thu, 24 Jan 2013 15:35:12 +0000 11624 Accept-Ranges: npt, smpte 11625 Media-Properties: Random-Access=1.2, Immutable, Unlimited 11627 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 11628 CSeq: 2 11629 User-Agent: PhonyClient/1.2 11630 Session: 23456789 11631 Range: smpte=0:10:00- 11633 V->C: RTSP/2.0 200 OK 11634 CSeq: 2 11635 Session: 23456789 11636 Range: smpte=0:10:00-1:49:23 11637 Seek-Style: First-Prior 11638 RTP-Info: url="rtsp://video.example.com/twister/video" 11639 ssrc=A17E189D:seq=12312232;rtptime=78712811 11640 Server: PhonyServer/2.0 11641 Date: Wed, 23 Jan 2013 15:35:13 +0000 11643 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 11644 CSeq: 2 11645 User-Agent: PhonyClient/1.2 11646 Session: 12345678 11647 Range: smpte=0:10:00- 11649 A->C: RTSP/2.0 200 OK 11650 CSeq: 2 11651 Session: 12345678 11652 Range: smpte=0:10:00-1:49:23 11653 Seek-Style: First-Prior 11654 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 11655 ssrc=3D124F01:seq=876655;rtptime=1032181 11656 Server: PhonyServer/1.0 11657 Date: Wed, 23 Jan 2013 15:35:13 +0000 11659 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 11660 CSeq: 3 11661 User-Agent: PhonyClient/1.2 11662 Session: 12345678 11664 A->C: RTSP/2.0 200 OK 11665 CSeq: 3 11666 Server: PhonyServer/1.0 11667 Date: Wed, 23 Jan 2013 15:36:52 +0000 11669 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 11670 CSeq: 3 11671 User-Agent: PhonyClient/1.2 11672 Session: 23456789 11674 V->C: RTSP/2.0 200 OK 11675 CSeq: 3 11676 Server: PhonyServer/2.0 11677 Date: Wed, 23 Jan 2013 15:36:52 +0000 11679 Even though the audio and video track are on two different servers 11680 that may start at slightly different times and may drift with respect 11681 to each other over time, the client can perform initial 11682 synchronization of the two media using RTP-Info and Range received in 11683 the PLAY responses. If the two servers are time synchronized the 11684 RTCP packets can also be used to maintain synchronization. 11686 A.5. Single Stream Container Files 11688 Some RTSP servers may treat all files as though they are "container 11689 files", yet other servers may not support such a concept. Because of 11690 this, clients needs to use the rules set forth in the session 11691 description for Request-URIs, rather than assuming that a consistent 11692 URI may always be used throughout. Below is an example of how a 11693 multi-stream server might expect a single-stream file to be served: 11695 C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 11696 Accept: application/x-rtsp-mh, application/sdp 11697 CSeq: 1 11698 User-Agent: PhonyClient/1.2 11700 S->C: RTSP/2.0 200 OK 11701 CSeq: 1 11702 Content-base: rtsp://foo.example.com/test.wav/ 11703 Content-type: application/sdp 11704 Content-length: 163 11705 Server: PhonyServer/1.0 11706 Date: Wed, 23 Jan 2013 15:36:52 +0000 11707 Expires: Thu, 24 Jan 2013 15:36:52 +0000 11709 v=0 11710 o=- 872653257 872653257 IN IP4 192.0.2.5 11711 s=mu-law wave file 11712 i=audio test 11713 c=IN IP4 0.0.0.0 11714 t=0 0 11715 a=control: * 11716 m=audio 0 RTP/AVP 0 11717 a=control:streamid=0 11719 C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 11720 Transport: RTP/AVP/UDP;unicast; 11721 dest_addr=":6970"/":6971";mode="PLAY" 11722 CSeq: 2 11723 User-Agent: PhonyClient/1.2 11724 Accept-Ranges: npt, smpte, clock 11726 S->C: RTSP/2.0 200 OK 11727 Transport: RTP/AVP/UDP;unicast; 11728 dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; 11729 src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; 11730 mode="PLAY";ssrc=EAB98712 11731 CSeq: 2 11732 Session: 2034820394 11733 Expires: Thu, 24 Jan 2013 15:36:52 +0000 11734 Server: PhonyServer/1.0 11735 Date: Wed, 23 Jan 2013 15:36:52 +0000 11736 Accept-Ranges: npt 11737 Media-Properties: Random-Acces=0.5, Immutable, Unlimited 11739 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 11740 CSeq: 3 11741 User-Agent: PhonyClient/1.2 11742 Session: 2034820394 11744 S->C: RTSP/2.0 200 OK 11745 CSeq: 3 11746 Server: PhonyServer/1.0 11747 Date: Wed, 23 Jan 2013 15:36:52 +0000 11748 Session: 2034820394 11749 Range: npt=0-600 11750 Seek-Style: RAP 11751 RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" 11752 ssrc=0D12F123:seq=981888;rtptime=3781123 11754 Note the different URI in the SETUP command, and then the switch back 11755 to the aggregate URI in the PLAY command. This makes complete sense 11756 when there are multiple streams with aggregate control, but is less 11757 than intuitive in the special case where the number of streams is 11758 one. However, the server has declared the aggregated control URI in 11759 the SDP and therefore this is legal. 11761 In this case, it is also required that servers accept implementations 11762 that use the non-aggregated interpretation and use the individual 11763 media URI, like this: 11765 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 11766 CSeq: 3 11767 User-Agent: PhonyClient/1.2 11768 Session: 2034820394 11770 A.6. Live Media Presentation Using Multicast 11772 The media server M chooses the multicast address and port. Here, it 11773 is assumed that the web server only contains a pointer to the full 11774 description, while the media server M maintains the full description. 11776 C->W: GET /sessions.html HTTP/1.1 11777 Host: www.example.com 11779 W->C: HTTP/1.1 200 OK 11780 Content-Type: text/html 11782 11783 ... 11784 11785 Streamed Live Music performance 11786 ... 11787 11789 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 11790 CSeq: 1 11791 Supported: play.basic, play.scale 11792 User-Agent: PhonyClient/1.2 11794 M->C: RTSP/2.0 200 OK 11795 CSeq: 1 11796 Content-Type: application/sdp 11797 Content-Length: 183 11798 Server: PhonyServer/1.0 11799 Date: Wed, 23 Jan 2013 15:36:52 +0000 11800 Supported: play.basic 11802 v=0 11803 o=- 2890844526 2890842807 IN IP4 192.0.2.5 11804 s=RTSP Session 11805 t=0 0 11806 m=audio 3456 RTP/AVP 0 11807 c=IN IP4 233.252.0.54/16 11808 a=control: rtsp://live.example.com/concert/audio 11809 a=range:npt=0- 11811 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 11812 CSeq: 2 11813 Transport: RTP/AVP;multicast; 11814 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11815 Accept-Ranges: npt, smpte, clock 11816 User-Agent: PhonyClient/1.2 11818 M->C: RTSP/2.0 200 OK 11819 CSeq: 2 11820 Server: PhonyServer/1.0 11821 Date: Wed, 23 Jan 2013 15:36:52 +0000 11822 Transport: RTP/AVP;multicast; 11823 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11824 ;ssrc=4D12AB92/0DF876A3 11825 Session: 0456804596 11826 Accept-Ranges: npt, clock 11827 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 11829 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 11830 CSeq: 3 11831 Session: 0456804596 11832 User-Agent: PhonyClient/1.2 11834 M->C: RTSP/2.0 200 OK 11835 CSeq: 3 11836 Server: PhonyServer/1.0 11837 Date: Wed, 23 Jan 2013 15:36:52 +0000 11838 Session: 0456804596 11839 Seek-Style: Next 11840 Range:npt=1256- 11841 RTP-Info: url="rtsp://live.example.com/concert/audio" 11842 ssrc=0D12F123:seq=1473; rtptime=80000 11844 A.7. Capability Negotiation 11846 This example illustrates how the client and server determine their 11847 capability to support a special feature, in this case "play.scale". 11848 The server, through the clients request and the included Supported 11849 header, learns the client supports RTSP 2.0, and also supports the 11850 playback time scaling feature of RTSP. The server's response 11851 contains the following feature related information to the client; it 11852 supports the basic media delivery functions (play.basic), the 11853 extended functionality of time scaling of content (play.scale), and 11854 one "example.com" proprietary feature (com.example.flight). The 11855 client also learns the methods supported (Public header) by the 11856 server for the indicated resource. 11858 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 11859 CSeq: 1 11860 Supported: play.basic, play.scale 11861 User-Agent: PhonyClient/1.2 11863 S->C: RTSP/2.0 200 OK 11864 CSeq: 1 11865 Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER 11866 Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE 11867 Server: PhonyServer/2.0 11868 Supported: play.basic, play.scale, com.example.flight 11870 When the client sends its SETUP request it tells the server that it 11871 requires support of the play.scale feature for this session by 11872 including the Require header. 11874 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 11875 CSeq: 3 11876 User-Agent: PhonyClient/1.2 11877 Transport: RTP/AVP/UDP;unicast; 11878 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", 11879 RTP/AVP/TCP;unicast;interleaved=0-1 11880 Require: play.scale 11881 Accept-Ranges: npt, smpte, clock 11882 User-Agent: PhonyClient/1.2 11884 S->C: RTSP/2.0 200 OK 11885 CSeq: 3 11886 Session: 12345678 11887 Transport: RTP/AVP/UDP;unicast; 11888 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11889 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11890 Server: PhonyServer/2.0 11891 Accept-Ranges: npt, smpte 11892 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11894 Appendix B. RTSP Protocol State Machine 11896 The RTSP session state machine describes the behavior of the protocol 11897 from RTSP session initialization through RTSP session termination. 11898 It is probably easiest to think of this as the server's state and 11899 then view the the client as needing to track what it believes the 11900 server's state will be based on sent or received RTSP messages. Thus 11901 in most cases the state tables below can be read as: If the client 11902 does X, and assuming it fulfills any pre-requisite(s), the (server) 11903 state will move to the new state and the indicated response will 11904 returned. However, there are also server to client notifications or 11905 requests, where the action describes what notification or request 11906 will occur, its requisites and what new state will result after the 11907 server has received the response, as well as describing the client's 11908 response to the action. 11910 The State machine is defined on a per session basis which is uniquely 11911 identified by the RTSP session identifier. The session may contain 11912 one or more media streams depending on state. If a single media 11913 stream is part of the session it is in non-aggregated control. If 11914 two or more is part of the session it is in aggregated control. 11916 The below state machine is an informative description of the 11917 protocols behavior. In case of ambiguity with the earlier parts of 11918 this specification, the description in the earlier parts take 11919 precedence. 11921 B.1. States 11923 The state machine contains three states, described below. For each 11924 state there exists a table which shows which requests and events are 11925 allowed and whether they will result in a state change. 11927 Init: Initial state no session exists. 11929 Ready: Session is ready to start playing. 11931 Play: Session is playing, i.e., sending media stream data in the 11932 direction S->C. 11934 B.2. State variables 11936 This representation of the state machine needs more than its state to 11937 work. A small number of variables are also needed and they are 11938 explained below. 11940 NRM: The number of media streams part of this session. 11942 RP: Resume point, the point in the presentation time line at which 11943 a request to continue playing will resume from. A time format 11944 for the variable is not mandated. 11946 B.3. Abbreviations 11948 To make the state tables more compact a number of abbreviations are 11949 used, which are explained below. 11951 IFI: IF Implemented. 11953 md: Media 11954 PP: Pause Point, the point in the presentation time line at which 11955 the presentation was paused. 11957 Prs: Presentation, the complete multimedia presentation. 11959 RedP: Redirect Point, the point in the presentation time line at 11960 which a REDIRECT was specified to occur. 11962 SES: Session. 11964 B.4. State Tables 11966 This section contains a table for each state. The table contains all 11967 the requests and events that this state is allowed to act on. The 11968 events which are method names are, unless noted, requests with the 11969 given method in the direction client to server (C->S). In some cases 11970 there exist one or more requisite. The response column tells what 11971 type of response actions should be performed. Possible actions that 11972 are requested for an event include: response codes, e.g., 200, 11973 headers that need to be included in the response, setting of state 11974 variables, or setting of other session related parameters. The new 11975 state column tells which state the state machine changes to. 11977 The response to a valid request meeting the requisites is normally a 11978 2xx (SUCCESS) unless otherwise noted in the response column. The 11979 exceptions need to be given a response according to the response 11980 column. If the request does not meet the requisite, is erroneous or 11981 some other type of error occurs, the appropriate response code is to 11982 be sent. If the response code is a 4xx the session state is 11983 unchanged. A response code of 3rr will result in that the session is 11984 ended and its state is changed to Init. A response code of 304 11985 results in no state change. However, there are restrictions to when 11986 a 3rr response may be used. A 5xx response does not result in any 11987 change of the session state, except if the error is not possible to 11988 recover from. A unrecoverable error results in the ending of the 11989 session. As it in the general case can't be determined if it was a 11990 unrecoverable error or not the client will be required to test. In 11991 the case that the next request after a 5xx is responded with 454 11992 (Session Not Found) the client knows that the session has ended. For 11993 any request message that cannot be responded to within the time 11994 defined in Section 10.4, a 100 response must be sent. 11996 The server will timeout the session after the period of time 11997 specified in the SETUP response, if no activity from the client is 11998 detected. Therefore there exists a timeout event for all states 11999 except Init. 12001 In the case that NRM = 1 the presentation URI is equal to the media 12002 URI or a specified presentation URI. For NRM > 1 the presentation 12003 URI needs to be other than any of the medias that are part of the 12004 session. This applies to all states. 12006 +---------------+-----------------+---------------------------------+ 12007 | Event | Prerequisite | Response | 12008 +---------------+-----------------+---------------------------------+ 12009 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 12010 | | | | 12011 | DESCRIBE | | 200, Session description | 12012 | | | | 12013 | OPTIONS | Session ID | 200, Reset session timeout | 12014 | | | timer | 12015 | | | | 12016 | OPTIONS | | 200 | 12017 | | | | 12018 | SET_PARAMETER | Valid parameter | 200, change value of parameter | 12019 | | | | 12020 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 12021 +---------------+-----------------+---------------------------------+ 12023 Table 13: None state-machine changing events 12025 The methods in Table 13 do not have any effect on the state machine 12026 or the state variables. However, some methods do change other 12027 session related parameters, for example SET_PARAMETER which will set 12028 the parameter(s) specified in its body. Also all of these methods 12029 that allow Session header will also update the keep-alive timer for 12030 the session. 12032 +------------------+----------------+-----------+-------------------+ 12033 | Action | Requisite | New State | Response | 12034 +------------------+----------------+-----------+-------------------+ 12035 | SETUP | | Ready | NRM=1, RP=0.0 | 12036 | | | | | 12037 | SETUP | Needs Redirect | Init | 3rr Redirect | 12038 | | | | | 12039 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 12040 +------------------+----------------+-----------+-------------------+ 12042 Table 14: State: Init 12044 The initial state of the state machine, see Table 14 can only be left 12045 by processing a correct SETUP request. As seen in the table the two 12046 state variables are also set by a correct request. This table also 12047 shows that a correct SETUP can in some cases be redirected to another 12048 URI and/or server by a 3rr response. 12050 +-------------+------------------------+---------+------------------+ 12051 | Action | Requisite | New | Response | 12052 | | | State | | 12053 +-------------+------------------------+---------+------------------+ 12054 | SETUP | New URI | Ready | NRM +=1 | 12055 | | | | | 12056 | SETUP | URI Setup prior | Ready | Change transport | 12057 | | | | param | 12058 | | | | | 12059 | TEARDOWN | Prs URI, | Init | No session hdr, | 12060 | | | | NRM = 0 | 12061 | | | | | 12062 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 12063 | | | | NRM = 0 | 12064 | | | | | 12065 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | 12066 | | | | -= 1 | 12067 | | | | | 12068 | PLAY | Prs URI, No range | Play | Play from RP | 12069 | | | | | 12070 | PLAY | Prs URI, Range | Play | According to | 12071 | | | | range | 12072 | | | | | 12073 | PLAY | md URI, NRM=1, Range | Play | According to | 12074 | | | | range | 12075 | | | | | 12076 | PLAY | md URI, NRM=1 | Play | Play from RP | 12077 | | | | | 12078 | PAUSE | Prs URI | Ready | Return PP | 12079 | | | | | 12080 | SC:REDIRECT | Terminate-Reason | Ready | Set RedP | 12081 | | | | | 12082 | SC:REDIRECT | No Terminate-Reason | Init | Session is | 12083 | | time parameter | | removed | 12084 | | | | | 12085 | Timeout | | Init | | 12086 | | | | | 12087 | RedP | | Init | TEARDOWN of | 12088 | reached | | | session | 12089 +-------------+------------------------+---------+------------------+ 12091 Table 15: State: Ready 12093 In the Ready state, see Table 15, some of the actions are depending 12094 on the number of media streams (NRM) in the session, i.e., aggregated 12095 or non-aggregated control. A SETUP request in the Ready state can 12096 either add one more media stream to the session or, if the media 12097 stream (same URI) already is part of the session, change the 12098 transport parameters. TEARDOWN is depending on both the Request-URI 12099 and the number of media streams within the session. If the Request- 12100 URI is the presentations URI the whole session is torn down. If a 12101 media URI is used in the TEARDOWN request and more than one media 12102 exists in the session, the session will remain and a session header 12103 is returned in the response. If only a single media stream remains 12104 in the session when performing a TEARDOWN with a media URI the 12105 session is removed. The number of media streams remaining after 12106 tearing down a media stream determines the new state. 12108 +----------------+-----------------------+--------+-----------------+ 12109 | Action | Requisite | New | Response | 12110 | | | State | | 12111 +----------------+-----------------------+--------+-----------------+ 12112 | PAUSE | Prs URI | Ready | Set RP to | 12113 | | | | present point | 12114 | | | | | 12115 | End of media | All media | Play | Set RP = End of | 12116 | | | | media | 12117 | | | | | 12118 | End of range | | Play | Set RP = End of | 12119 | | | | range | 12120 | | | | | 12121 | PLAY | Prs URI, No range | Play | Play from | 12122 | | | | present point | 12123 | | | | | 12124 | PLAY | Prs URI, Range | Play | According to | 12125 | | | | range | 12126 | | | | | 12127 | SC:PLAY_NOTIFY | | Play | 200 | 12128 | | | | | 12129 | SETUP | New URI | Play | 455 | 12130 | | | | | 12131 | SETUP | Setuped URI | Play | 455 | 12132 | | | | | 12133 | SETUP | Setuped URI, IFI | Play | Change | 12134 | | | | transport | 12135 | | | | param. | 12136 | | | | | 12137 | TEARDOWN | Prs URI | Init | No session hdr | 12138 | | | | | 12139 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 12140 | | | | NRM=0 | 12141 | | | | | 12142 | TEARDOWN | md URI | Play | 455 | 12143 | | | | | 12144 | SC:REDIRECT | Terminate Reason with | Play | Set RedP | 12145 | | Time parameter | | | 12146 | | | | | 12147 | SC:REDIRECT | | Init | Session is | 12148 | | | | removed | 12149 | | | | | 12150 | RedP reached | | Init | TEARDOWN of | 12151 | | | | session | 12152 | | | | | 12153 | Timeout | | Init | Stop Media | 12154 | | | | playout | 12155 +----------------+-----------------------+--------+-----------------+ 12157 Table 16: State: Play 12159 The Play state table, see Table 16, contains a number of requests 12160 that need a presentation URI (labeled as Prs URI) to work on (i.e., 12161 the presentation URI has to be used as the Request-URI). This is due 12162 to the exclusion of non-aggregated stream control in sessions with 12163 more than one media stream. 12165 To avoid inconsistencies between the client and server, automatic 12166 state transitions are avoided. This can be seen at for example "End 12167 of media" event when all media has finished playing, the session 12168 still remains in Play state. An explicit PAUSE request needs to be 12169 sent to change the state to Ready. It may appear that there exist 12170 automatic transitions in "RedP reached" and "PP reached". However, 12171 they are requested and acknowledged before they take place. The time 12172 at which the transition will happen is known by looking at the range 12173 header. If the client sends a request close in time to these 12174 transitions it needs to be prepared for receiving error messages, as 12175 the state may or may not have changed. 12177 Appendix C. Media Transport Alternatives 12179 This section defines how certain combinations of protocols, profiles 12180 and lower transports are used. This includes the usage of the 12181 Transport header's source and destination address parameters 12182 "src_addr" and "dest_addr". 12184 C.1. RTP 12186 This section defines the interaction of RTSP with respect to the RTP 12187 protocol [RFC3550]. It also defines any necessary media transport 12188 signaling with regards to RTP. 12190 The available RTP profiles and lower layer transports are described 12191 below along with rules on signaling the available combinations. 12193 C.1.1. AVP 12195 The usage of the "RTP Profile for Audio and Video Conferences with 12196 Minimal Control" [RFC3551] when using RTP for media transport over 12197 different lower layer transport protocols is defined below in regards 12198 to RTSP. 12200 One such case is defined within this document: the use of embedded 12201 (interleaved) binary data as defined in Section 14. The usage of 12202 this method is indicated by including the "interleaved" parameter. 12204 When using embedded binary data the "src_addr" and "dest_addr" MUST 12205 NOT be used. This addressing and multiplexing is used as defined 12206 with use of channel numbers and the interleaved parameter. 12208 C.1.2. AVP/UDP 12210 This part describes sending of RTP [RFC3550] over lower transport 12211 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 12212 and Video Conferences with Minimal Control" defined in RFC 3551 12213 [RFC3551]. Implementations of RTP/AVP/UDP MUST implement RTCP 12214 (Appendix C.1.6). This profile requires one or two uni- or bi- 12215 directional UDP flows per media stream. The first UDP flow is for 12216 RTP and the second is for RTCP. Multiplexing of RTP and RTCP 12217 (Appendix C.1.6.4) MAY be used, in which case a single UDP flow is 12218 used for both parts. Embedding of RTP data with the RTSP messages, 12219 in accordance with Section 14, SHOULD NOT be performed when RTSP 12220 messages are transported over unreliable transport protocols, like 12221 UDP [RFC0768]. 12223 The RTP/UDP and RTCP/UDP flows can be established using the Transport 12224 header's "src_addr", and "dest_addr" parameters. 12226 In RTSP PLAY mode, the transmission of RTP packets from client to 12227 server is unspecified. The behavior in regards to such RTP packets 12228 MAY be defined in future. 12230 The "src_addr" and "dest_addr" parameters are used in the following 12231 way for media delivery and playback mode, i.e., Mode=PLAY: 12233 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 12234 2 address specifications. Note that two address specifications 12235 MAY be provided even if RTP and RTCP multiplexing is negotiated. 12237 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 12238 contain either: 12240 * both an address and a port number, or 12241 * a port number without an address. 12243 o The first address specification given in either of the parameters 12244 applies to the RTP stream. The second specification if present 12245 applies to the RTCP stream, unless in case RTP and RTCP 12246 multiplexing is negotiated where both RTP and RTCP will use the 12247 first specification. 12249 o The RTP/UDP packets from the server to the client MUST be sent to 12250 the address and port given by the first address specification of 12251 the "dest_addr" parameter. 12253 o The RTCP/UDP packets from the server to the client MUST be sent to 12254 the address and port given by the second address specification of 12255 the "dest_addr" parameter, unless RTP and RTCP multiplexing has 12256 been negotiated, in which case RTCP MUST be sent to the first 12257 address specification. If no second pair is specified and RTP and 12258 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12260 o The RTCP/UDP packets from the client to the server MUST be sent to 12261 the address and port given by the second address specification of 12262 the "src_addr" parameter, unless RTP and RTCP multiplexing has 12263 been negotiated, in which case RTCP MUST be sent to the first 12264 address specification. If no second pair is specified and RTP and 12265 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12267 o The RTP/UDP packets from the client to the server MUST be sent to 12268 the address and port given by the first address specification of 12269 the "src_addr" parameter. 12271 o RTP and RTCP Packets SHOULD be sent from the corresponding 12272 receiver port, i.e., RTCP packets from the server should be sent 12273 from the "src_addr" parameters second address port pair, unless 12274 RTP and RTCP multiplexing has been negotiated in which case the 12275 first address port pair is used. 12277 C.1.3. AVPF/UDP 12279 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 12280 AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. 12281 All that is defined for AVP MUST also apply for AVPF. 12283 The usage of AVPF is indicated by the media initialization protocol 12284 used. In the case of SDP it is indicated by media lines (m=) 12285 containing the profile RTP/AVPF. That SDP MAY also contain further 12286 AVPF related SDP attributes configuring the AVPF session regarding 12287 reporting interval and feedback messages to be used [RFC4585]. This 12288 configuration MUST be followed. 12290 C.1.4. SAVP/UDP 12292 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 12293 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 12294 using RTP. All that is defined for AVP MUST also apply for SAVP. 12296 The usage of SRTP requires that a security context is established. 12297 The default key-management unless otherwise signalled SHALL be MIKEY 12298 in RSA-R mode as defined in Appendix C.1.4.1, and not according to 12299 the procedure defined in "Key Management Extensions for Session 12300 Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" 12301 [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY 12302 message in SDP, thus both requiring the usage of the DESCRIBE method 12303 and forcing the server to keep state for clients performing DESCRIBE 12304 in anticipation that they might require key management. 12306 MIKEY is selected as default method for establishing SRTP 12307 cryptographic context within an RTSP session as it can be embedded in 12308 the RTSP messages, while still ensuring confidentiality of content of 12309 the keying material, even when using hop-by-hop TLS security for the 12310 RTSP messages. This method does also support pipelining of the RTSP 12311 messages. 12313 C.1.4.1. MIKEY Key Establishment 12315 This method for using MIKEY [RFC3830] to establish the SRTP 12316 cryptographic context is initiated in the client's SETUP request, and 12317 the server's response to the SETUP carries the MIKEY response. This 12318 ensures that the crypto context establishment happens simultaneously 12319 with the establishment of the media stream being protected. By using 12320 MIKEY's RSA-R mode [RFC4738] the client can be the initiator and 12321 still allow the server to set the parameters in accordance with the 12322 actual media stream. 12324 The SRTP cryptographic context establishment is done according to the 12325 following process: 12327 1. The client determines that SAVP or SAVPF shall be used from 12328 media description format, e.g., SDP. If no other key management 12329 method is explicitly signalled, then MIKEY SHALL be used as 12330 defined herein. The use of SRTP with RTSP is only defined with 12331 MIKEY with keys established as defined in this Section. Future 12332 documents may define how an RTSP implementation treats SDP that 12333 indicates some other key mechanism to be used. The need for 12334 such specification include [RFC4567] that is not defined for use 12335 in RTSP 2.0 within this document. 12337 2. The client SHALL establish a TLS connection for RTSP messages, 12338 directly or hop by hop with the server. If hop-by-hop TLS 12339 security is used, the User method SHALL be indicated in the 12340 Accept-Credentials header. Note that using hop-by-hop does 12341 allow the proxy to insert itself as a man in the middle also in 12342 the MIKEY exchange by providing one of its certificates, rather 12343 than the server's in the Connection-Credentials header. The 12344 client SHALL therefore validate the server certificate. 12346 3. The client retrieves the server's certificate from a direct TLS 12347 connection, or if hop by hop from Connection-Credentials header. 12348 The client then checks that the server certificate is valid and 12349 belongs to the server. 12351 4. The client forms the MIKEY Initiator message using RSA-R mode in 12352 unicast mode as specified in [RFC4738]. The client SHOULD use 12353 the same certificate for TLS and in MIKEY to enable the server 12354 to bind the two together. The client's certificate SHALL be 12355 included in the MIKEY message. The client SHALL indicate its 12356 SRTP capabilities in the message. 12358 5. The MIKEY message from the previous step is base64 [RFC4648] 12359 encoded and becomes the value of the MIKEY parameter that is 12360 included in the transport specification(s) that specifies a SRTP 12361 based profile (SAVP, SAVPF) in the SETUP request. 12363 6. Any proxy encountering the MIKEY parameter SHALL forward it 12364 without modification. A proxy requiring to understand transport 12365 specification which doesn't support SAVP/SAVPF with MIKEY will 12366 discard the whole transport specification. Most types of 12367 proxies can easily support SAVP and SAVPF with MIKEY. If 12368 possible bypassing the proxy should be tried. 12370 7. The server upon receiving the SETUP request, will need to decide 12371 upon the transport specification to use, if multiple are 12372 included by the client. In the determination of which transport 12373 specifications that are supported and preferred, the server 12374 SHOULD decode the MIKEY message to take the embedded SRTP 12375 parameters into account. If all transport specs require SRTP 12376 but no MIKEY parameter or other supported keying method is 12377 included, the server SHALL respond with 403. 12379 8. Upon generating a response the following outcomes can occur: 12381 * A transport spec not using SRTP and MIKEY is selected. Thus 12382 the response will not contain any MIKEY parameter. 12384 * A transport spec using SRTP and MIKEY is selected but an 12385 error is encountered in the MIKEY processing. In that case 12386 an RTSP error response code of 466 "Key Management Error" 12387 SHALL be used. A MIKEY message describing the error MAY be 12388 included. 12390 * A transport spec using SRTP and MIKEY is selected and a MIKEY 12391 response message can be created. The server SHOULD use the 12392 same certificate for TLS and in MIKEY to enable client to 12393 bind the two together. If a different certificate is used it 12394 SHALL be included in the MIKEY message. It is RECOMMENDED 12395 that the envelope key cache type is set to 'Cache' and that a 12396 single envelope key is reused for all MIKEY messages to the 12397 client. That message is included in the MIKEY parameter part 12398 of the single selected transport specification in the SETUP 12399 response. The server will set the SRTP parameters as 12400 preferred for this media stream within the supported range by 12401 the client. 12403 9. The server transmits the SETUP response back to the client. 12405 10. The client receives the SETUP response and if the response code 12406 indicates a successful request it decodes the MIKEY message and 12407 establishes the SRTP cryptographic context from the parameters 12408 in the MIKEY response. 12410 In the above method the client's certificate may be self-signed in 12411 cases where the client's identity is not necessary to authenticate 12412 and the security goal is only to ensure that the RTSP signaling 12413 client is the same as the one receiving the SRTP security context. 12415 C.1.5. SAVPF/UDP 12417 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 12418 (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in 12419 RTSP sessions using RTP. All that is defined for AVPF MUST also 12420 apply for SAVPF. 12422 The usage of SRTP requires that a cryptographic context is 12423 established. The default mechanism for establishing that security 12424 association is to use MIKEY[RFC3830] with RTSP as defined in 12425 Appendix C.1.4.1. 12427 C.1.6. RTCP usage with RTSP 12429 RTCP has several usages when RTP is used for media transport as 12430 explained below. Due to that RTCP MUST be supported if an RTSP agent 12431 handles RTP. 12433 C.1.6.1. Media synchronization 12435 RTCP provides media synchronization and clock drift compensation. 12436 The initial media synchronization is available from RTP-Info header. 12437 However, to be able to handle any clock drift between the media 12438 streams, RTCP is needed. 12440 C.1.6.2. RTSP Session keep-alive 12442 RTCP traffic from the RTSP client to the RTSP server MUST function as 12443 keep-alive. This requires an RTSP server supporting RTP to use the 12444 received RTCP packets as indications that the client desires the 12445 related RTSP session to be kept alive. 12447 C.1.6.3. Bit-rate adaption 12449 RTCP Receiver reports and any additional feedback from the client 12450 MUST be used to adapt the bit-rate used over the transport for all 12451 cases when RTP is sent over UDP. An RTP sender without reserved 12452 resources MUST NOT use more than its fair share of the available 12453 resources. This can be determined by comparing on short to medium 12454 term (some seconds) the used bit-rate and adapt it so that the RTP 12455 sender sends at a bit-rate comparable to what a TCP sender would 12456 achieve on average over the same path. 12458 To ensure that the implementation's adaptation mechanism has a well 12459 defined outer envelope, all implementations using a non-congestion 12460 controlled unicast transport protocol, like UDP, MUST implement 12461 Multimedia Congestion Control: Circuit Breakers for Unicast RTP 12462 Sessions [I-D.ietf-avtcore-rtp-circuit-breakers]. 12464 C.1.6.4. RTP and RTCP Multiplexing 12466 RTSP can be used to negotiate the usage of RTP and RTCP multiplexing 12467 as described in [RFC5761]. This allows servers and client to reduce 12468 the amount of resources required for the session by only requiring 12469 one underlying transport stream per media stream instead of two when 12470 using RTP and RTCP. This lessens the server port consumption and 12471 also the necessary state and keep-alive work when operating across 12472 Network and Address Translators [RFC2663]. 12474 Content must be prepared with some consideration for RTP and RTCP 12475 multiplexing, mainly ensuring that the RTP payload types used do not 12476 collide with the ones used for RTCP packet types. This option likely 12477 needs explicit support from the content unless the RTP payload types 12478 can be remapped by the server and that is correctly reflected in the 12479 session description. Beyond that support of this feature should come 12480 at little cost and much gain. 12482 It is recommended that if the content and server support RTP and RTCP 12483 multiplexing that this is indicated in the session description, for 12484 example using the SDP attribute "a=rtcp-mux". If the SDP message 12485 contains the a=rtcp-mux attribute for a media stream, the server MUST 12486 support RTP and RTCP multiplexing. If indicated or otherwise desired 12487 by the client it can include the Transport parameter "RTCP-mux" in 12488 any transport specification where it desires to use RTCP-mux. The 12489 server will indicate if it supports RTCP-mux. Servers and Clients 12490 SHOULD support RTP and RTCP multiplexing. 12492 For capability exchange, an RTSP feature tag for RTP and RTCP 12493 multiplexing is defined: "setup.rtp.rtcp.mux". 12495 To minimize the risk of negotiation failure while using RTP and RTCP 12496 multiplexing some recommendations are here provided. If the session 12497 description includes explicit indication of support (a=rtcp-mux in 12498 SDP), then a RTSP agent can safely create a SETUP request with a 12499 transport specification with only a single dest_addr parameter 12500 address specification. If no such explicit indication is provided, 12501 then even if the feature tag "setup.rtp.rtcp.mux" is provided in a 12502 Supported header by the RTSP server or the feature tag included in 12503 the Required header in the SETUP request, the media resource may not 12504 support RTP and RTCP multiplexing. Thus, to maximize the probability 12505 of successful negotiation the RTSP agent is recommended to include 12506 two dest_addr parameter address specifications in the first or first 12507 set (if pipelining is used) of SETUP request(s) for any media 12508 resource aggregate. That way the RTSP server can either accept RTP 12509 and RTCP multiplexing and only use the first address specification, 12510 and if not use both specifications. The RTSP agent after having 12511 received the response for a successful negotiation of the usage of 12512 RTP and RTCP multiplexing, can then release the resources associated 12513 with the second address specification. 12515 C.2. RTP over TCP 12517 Transport of RTP over TCP can be done in two ways: over independent 12518 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 12519 connection. In both cases the protocol MUST be "rtp" and the lower 12520 layer MUST be TCP. The profile may be any of the above specified 12521 ones; AVP, AVPF, SAVP or SAVPF. 12523 C.2.1. Interleaved RTP over TCP 12525 The use of embedded (interleaved) binary data transported on the RTSP 12526 connection is possible as specified in Section 14. When using this 12527 declared combination of interleaved binary data the RTSP messages 12528 MUST be transported over TCP. TLS may or may not be used. If TLS is 12529 used both RTSP messages and the binary data will be protected by TLS. 12531 One should, however, consider that this will result in all media 12532 streams go through any proxy. Using independent TCP connections can 12533 avoid that issue. 12535 C.2.2. RTP over independent TCP 12537 In this Appendix, it is described the sending of RTP [RFC3550] over 12538 lower transport layer TCP [RFC0793] according to "Framing Real-time 12539 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 12540 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 12541 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 12542 with RTSP. 12544 A client codes the support of RTP over independent TCP by specifying 12545 an RTP/AVP/TCP transport option without an interleaved parameter in 12546 the Transport line of a SETUP request. This transport option MUST 12547 include the "unicast" parameter. 12549 If the client wishes to use RTP with RTCP, two address specifications 12550 needs to be included in the dest_addr parameter. If the client 12551 wishes to use RTP without RTCP, one address specification is included 12552 in the dest_addr parameter. If the client wishes to multiplex RTP 12553 and RTCP on a single transport flow (see Appendix C.1.6.4), one or 12554 two address specifications are included in the dest_addr parameter in 12555 addition to the RTCP-mux transport parameter. Two address 12556 specifications are allowed to allow successful negotiation when 12557 server or content can't support RTP and RTCP multiplexing. Ordering 12558 rules of dest_addr ports follow the rules for RTP/AVP/UDP. 12560 If the client wishes to play the active role in initiating the TCP 12561 connection, it MAY set the "setup" parameter (See Section 18.54) on 12562 the Transport line to be "active", or it MAY omit the setup 12563 parameter, as active is the default. If the client signals the 12564 active role, the ports in the address specifications in the dest_addr 12565 parameter MUST be set to 9 (the discard port). 12567 If the client wishes to play the passive role in TCP connection 12568 initiation, it MUST set the "setup" parameter on the Transport line 12569 to be "passive". If the client is able to assume the active or the 12570 passive role, it MUST set the "setup" parameter on the Transport line 12571 to be "actpass". In either case, the dest_addr parameter's address 12572 specification port value for RTP MUST be set to the TCP port number 12573 on which the client is expecting to receive the TCP connection for 12574 RTP, and the dest_addr's address specification port value for RTCP 12575 MUST be set to the TCP port number on which the client is expecting 12576 to receive the TCP connection for RTCP. In the case that the client 12577 wishes to multiplex RTP and RTCP on a single transport flow, the 12578 RTCP-mux parameter is included and one or two dest_addr parameter 12579 address specifications are included, as mentioned earlier in this 12580 section. 12582 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 12583 server decides to accept this requested option, the 2xx reply MUST 12584 contain a Transport option that specifies RTP/AVP/TCP (without using 12585 the interleaved parameter, and with using the unicast parameter). 12586 The dest_addr parameter value MUST be echoed from the parameter value 12587 in the client request unless the destination address (only port) was 12588 not provided in which case the server MAY include the source address 12589 of the RTSP TCP connection with the port number unchanged. 12591 In addition, the server reply MUST set the setup parameter on the 12592 Transport line, to indicate the role the server will play in the 12593 connection setup. Permissible values are "active" (if a client set 12594 "setup" to "passive" or "actpass") and "passive" (if a client set 12595 "setup" to "active" or "actpass"). 12597 If a server sets "setup" to "passive", the "src_addr" in the reply 12598 MUST indicate the ports the server is willing to receive an TCP 12599 connection for RTP and (if the client requested an TCP connection for 12600 RTCP by specifying two dest_addr address specifications) an TCP/RTCP 12601 connection. If a server sets "setup" to "active", the ports 12602 specified in "src_addr" address specifications MUST be set to 9. The 12603 server MAY use the "ssrc" parameter, following the guidance in 12604 Section 18.54. The server sets only one address specification in the 12605 case that the client has indicated only a single address 12606 specification or in case RTP and RTCP multiplexing was requested and 12607 accepted by server. Port ordering for src_addr follows the rules for 12608 RTP/AVP/UDP. 12610 Servers MUST support taking the passive role and MAY support taking 12611 the active role. Servers with a public IP address take the passive 12612 role, thus enabling clients behind NATs and Firewalls a better chance 12613 of successful connect to the server by actively connecting outwards. 12614 Therefore the clients are RECOMMENDED to take the active role. 12616 After sending (receiving) a 2xx reply for a SETUP method for a non- 12617 interleaved RTP/AVP/TCP media stream, the active party SHOULD 12618 initiate the TCP connection as soon as possible. The client MUST NOT 12619 send a PLAY request prior to the establishment of all the TCP 12620 connections negotiated using SETUP for the session. In case the 12621 server receives a PLAY request in a session that has not yet 12622 established all the TCP connections, it MUST respond using the 464 12623 "Data Transport Not Ready Yet" (Section 17.4.29) error code. 12625 Once the PLAY request for a media resource transported over non- 12626 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 12627 client over the RTP TCP connection, and RTCP packets flow 12628 bidirectionally over the RTCP TCP connection. Unless RTP and RTCP 12629 multiplexing has been negotiated in which case RTP and RTCP will flow 12630 over a common TCP connection. As in the RTP/UDP case, client to 12631 server traffic on a RTP only TCP session is unspecified by this memo. 12632 The packets that travel on these connections MUST be framed using the 12633 protocol defined in [RFC4571], not by the framing defined for 12634 interleaving RTP over the RTSP connection defined in Section 14. 12636 A successful PAUSE request for a media being transported over RTP/AVP 12637 /TCP pauses the flow of packets over the connections, without closing 12638 the connections. A successful TEARDOWN request signals that the TCP 12639 connections for RTP and RTCP are to be closed by the RTSP client as 12640 soon as possible. 12642 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 12643 ambiguous in the following way: does the client wish to open up new 12644 TCP connection for RTP or RTCP for the URI, or does the client wish 12645 to continue using the existing TCP connections? The client SHOULD 12646 use the "connection" parameter (defined in Section 18.54) on the 12647 Transport line to make its intention clear (by setting "connection" 12648 to "new" if new connections are needed, and by setting "connection" 12649 to "existing" if the existing connections are to be used). After a 12650 2xx reply for a SETUP request for a new connection, parties should 12651 close the pre-existing connections, after waiting a suitable period 12652 for any stray RTP or RTCP packets to arrive. 12654 The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that 12655 a security association is established. The default mechanism for 12656 establishing that security association is to use MIKEY[RFC3830] with 12657 RTSP as defined Appendix C.1.4.1. 12659 Below, a rewriten version of the example "media on demand" 12660 (Appendix A.1) shows the use of RTP/AVP/TCP non-interleaved: 12662 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 12663 CSeq: 1 12664 User-Agent: PhonyClient/1.2 12666 M->C: RTSP/2.0 200 OK 12667 CSeq: 1 12668 Server: PhonyServer/1.0 12669 Date: Wed, 23 Jan 2013 15:36:52 +0000 12670 Content-Type: application/sdp 12671 Content-Length: 227 12672 Content-Base: rtsp://example.com/twister.3gp/ 12673 Expires: Thu, 24 Jan 2013 15:36:52 +0000 12675 v=0 12676 o=- 2890844256 2890842807 IN IP4 198.51.100.34 12677 s=RTSP Session 12678 i=An Example of RTSP Session Usage 12679 e=adm@example.com 12680 c=IN IP4 0.0.0.0 12681 a=control: * 12682 a=range:npt=00:00:00-00:10:34.10 12683 t=0 0 12684 m=audio 0 RTP/AVP 0 12685 a=control: trackID=1 12687 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 12688 CSeq: 2 12689 User-Agent: PhonyClient/1.2 12690 Require: play.basic 12691 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 12692 setup=active;connection=new 12693 Accept-Ranges: npt, smpte, clock 12695 M->C: RTSP/2.0 200 OK 12696 CSeq: 2 12697 Server: PhonyServer/1.0 12698 Transport: RTP/AVP/TCP;unicast; 12699 dest_addr=":9"/":9"; 12700 src_addr="198.51.100.5:53478"/"198.51.100:54091"; 12701 setup=passive;connection=new;ssrc=93CB001E 12702 Session: 12345678 12703 Expires: Thu, 24 Jan 2013 15:36:52 +0000 12704 Date: Wed, 23 Jan 2013 15:36:52 +0000 12705 Accept-Ranges: npt 12706 Media-Properties: Random-Access=0.8, Immutable, Unlimited 12708 C->M: TCP Connection Establishment x2 12710 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 12711 CSeq: 4 12712 User-Agent: PhonyClient/1.2 12713 Range: npt=30- 12714 Session: 12345678 12716 M->C: RTSP/2.0 200 OK 12717 CSeq: 4 12718 Server: PhonyServer/1.0 12719 Date: Wed, 23 Jan 2013 15:36:54 +0000 12720 Session: 12345678 12721 Range: npt=30-623.10 12722 Seek-Style: First-Prior 12723 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" 12724 ssrc=4F312DD8:seq=54321;rtptime=2876889 12726 C.3. Handling Media Clock Time Jumps in the RTP Media Layer 12728 RTSP allows media clients to control selected, non-contiguous 12729 sections of media presentations, rendering those streams with an RTP 12730 media layer [RFC3550]. Two cases occur, the first is when a new PLAY 12731 request replaces an old ongoing request and the new request results 12732 in a jump in the media. This should produce in the RTP layer a 12733 continuous media stream. A client may also directly following a 12734 completed PLAY request perform a new PLAY request. This will result 12735 in some gap in the media layer. The below text will look into both 12736 cases. 12738 A PLAY request that replaces an ongoing request allows the media 12739 layer rendering the RTP stream without being affected by jumps in 12740 media clock time. The RTP timestamps for the new media range is set 12741 so that they become continuous with the previous media range in the 12742 previous request. The RTP sequence number for the first packet in 12743 the new range will be the next following the last packet in the 12744 previous range, i.e., monotonically increasing. The goal is to allow 12745 the media rendering layer to work without interruption or 12746 reconfiguration across the jumps in media clock. This should be 12747 possible in all cases of replaced PLAY requests for media that has 12748 random-access properties. In this case care is needed to align 12749 frames or similar media dependent structures. 12751 In cases where jumps in media clock time are a result of RTSP 12752 signaling operations arriving after a completed PLAY operation, the 12753 request timing will result in that media becomes non-continuous. The 12754 server becomes unable to send the media so that it arrives timely and 12755 still carry timestamps to make the media stream continuous. In these 12756 cases the server will produce RTP streams where there are gaps in the 12757 RTP timeline for the media. In such cases, if the media has frame 12758 structure, aligning the timestamp for the next frame with the 12759 previous structure reduces the burden to render this media. The gap 12760 should represent the time the server hasn't been serving media, e.g., 12761 the time between the end of the media stream or a PAUSE request and 12762 the new PLAY request. In these cases the RTP sequence number would 12763 normally be monotonically increasing across the gap. 12765 For RTSP sessions with media that lacks random access properties, 12766 such as live streams, any media clock jump is commonly the result of 12767 a correspondingly long pause of delivery. The RTP timestamp will 12768 have increased in direct proportion to the duration of the paused 12769 delivery. Note also that in this case the RTP sequence number should 12770 be the next packet number. If not, the RTCP packet loss reporting 12771 will indicate as loss all packets not received between the point of 12772 pausing and later resuming. This may trigger congestion avoidance 12773 mechanisms. An allowed exception from the above recommendation on 12774 monotonically increasing RTP sequence number is live media streams, 12775 likely being relayed. In this case, when the client resumes 12776 delivery, it will get the media that is currently being delivered to 12777 the server itself. For this type of basic delivery of live streams 12778 to multiple users over unicast, individual rewriting of RTP sequence 12779 numbers becomes quite a burden. For solutions that anyway caches 12780 media, timeshifts, etc, the rewriting should be a minor issue. 12782 The goal when handling jumps in media clock time is that the provided 12783 stream is continuous without gaps in RTP timestamp or sequence 12784 number. However, when delivery has been halted for some reason the 12785 RTP timestamp when resuming MUST represent the duration the delivery 12786 was halted. RTP sequence number MUST generally be the next number, 12787 i.e., monotonically increasing modulo 65536. For media resources 12788 with the properties Time-Progressing and Time-Duration=0.0 the server 12789 MAY create RTP media streams with RTP sequence number jumps in them 12790 due to the client first halting delivery and later resuming it (PAUSE 12791 and then later PLAY). However, servers utilizing this exception must 12792 take into consideration the resulting RTCP receiver reports that 12793 likely contain loss reports for all the packets part of the 12794 discontinuity. A client cannot rely on that a server will align when 12795 resuming playing even if it is RECOMMENDED. The RTP-Info header will 12796 provide information on how the server acts in each case. 12798 One cannot assume that the RTSP client can communicate with the 12799 RTP media agent, as the two may be independent processes. If the 12800 RTP timestamp shows the same gap as the NPT, the media agent will 12801 assume that there is a pause in the presentation. If the jump in 12802 NPT is large enough, the RTP timestamp may roll over and the media 12803 agent may believe later packets to be duplicates of packets just 12804 played out. Having the RTP timestamp jump will also affect the 12805 RTCP measurements based on this. 12807 As an example, assume an RTP timestamp frequency of 8000 Hz, a 12808 packetization interval of 100 ms and an initial sequence number and 12809 timestamp of zero. 12811 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12812 CSeq: 4 12813 Session: abcdefgh 12814 Range: npt=10-15 12815 User-Agent: PhonyClient/1.2 12817 S->C: RTSP/2.0 200 OK 12818 CSeq: 4 12819 Session: abcdefgh 12820 Range: npt=10-15 12821 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12822 ssrc=0D12F123:seq=0;rtptime=0 12824 The ensuing RTP data stream is depicted below: 12826 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12827 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12828 . . . 12829 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 12831 Upon the completion of the requested delivery the server sends a 12832 PLAY_NOTIFY 12833 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 12834 CSeq: 5 12835 Notify-Reason: end-of-stream 12836 Request-Status: cseq=4 status=200 reason="OK" 12837 Range: npt=-15 12838 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 12839 ssrc=0D12F123:seq=49;rtptime=39200 12840 Session: abcdefgh 12842 C->S: RTSP/2.0 200 OK 12843 CSeq: 5 12844 User-Agent: PhonyClient/1.2 12846 Upon the completion of the play range, the client follows up with a 12847 request to PLAY from a new NPT. 12849 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12850 CSeq: 6 12851 Session: abcdefg 12852 Range: npt=18-20 12853 User-Agent: PhonyClient/1.2 12855 S->C: RTSP/2.0 200 OK 12856 CSeq: 6 12857 Session: abcdefg 12858 Range: npt=18-20 12859 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12860 ssrc=0D12F123:seq=50;rtptime=40100 12862 The ensuing RTP data stream is depicted below: 12864 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 12865 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 12866 . . . 12867 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 12869 In this example, first, NPT 10 through 15 is played, then the client 12870 requests the server to skip ahead and play NPT 18 through 20. The 12871 first segment is presented as RTP packets with sequence numbers 0 12872 through 49 and timestamp 0 through 39,200. The second segment 12873 consists of RTP packets with sequence number 50 through 69, with 12874 timestamps 40,100 through 55,200. While there is a gap in the NPT, 12875 there is no gap in the sequence number space of the RTP data stream. 12877 The RTP timestamp gap is present in the above example due to the time 12878 it takes to perform the second play request, in this case 12.5 ms 12879 (100/8000). 12881 C.4. Handling RTP Timestamps after PAUSE 12883 During a PAUSE / PLAY interaction in an RTSP session, the duration of 12884 time for which the RTP transmission was halted MUST be reflected in 12885 the RTP timestamp of each RTP stream. The duration can be calculated 12886 for each RTP stream as the time elapsed from when the last RTP packet 12887 was sent before the PAUSE request was received and when the first RTP 12888 packet was sent after the subsequent PLAY request was received. The 12889 duration includes all latency incurred and processing time required 12890 to complete the request. 12892 The RTP RFC [RFC3550] states that: The RTP timestamp for each unit 12893 [packet] would be related to the wallclock time at which the unit 12894 becomes current on the virtual presentation timeline. 12896 In order to satisfy the requirements of [RFC3550], the RTP 12897 timestamp space needs to increase continuously with real time. 12898 While this is not optimal for stored media, it is required for RTP 12899 and RTCP to function as intended. Using a continuous RTP 12900 timestamp space allows the same timestamp model for both stored 12901 and live media and allows better opportunity to integrate both 12902 types of media under a single control. 12904 As an example, assume a clock frequency of 8000 Hz, a packetization 12905 interval of 100 ms and an initial sequence number and timestamp of 12906 zero. 12908 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12909 CSeq: 4 12910 Session: abcdefg 12911 Range: npt=10-15 12913 User-Agent: PhonyClient/1.2 12915 S->C: RTSP/2.0 200 OK 12916 CSeq: 4 12917 Session: abcdefg 12918 Range: npt=10-15 12919 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12920 ssrc=0D12F123:seq=0;rtptime=0 12922 The ensuing RTP data stream is depicted below: 12924 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12925 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12926 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 12927 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 12929 The client then sends a PAUSE request: 12931 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 12932 CSeq: 5 12933 Session: abcdefg 12934 User-Agent: PhonyClient/1.2 12936 S->C: RTSP/2.0 200 OK 12937 CSeq: 5 12938 Session: abcdefg 12939 Range: npt=10.4-15 12941 20 seconds elapse and then the client sends a PLAY request. In 12942 addition the server requires 15 ms to process the request: 12944 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12945 CSeq: 6 12946 Session: abcdefg 12947 User-Agent: PhonyClient/1.2 12949 S->C: RTSP/2.0 200 OK 12950 CSeq: 6 12951 Session: abcdefg 12952 Range: npt=10.4-15 12953 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12954 ssrc=0D12F123:seq=4;rtptime=164400 12956 The ensuing RTP data stream is depicted below: 12958 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 12959 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 12960 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 12962 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 12963 server. After 20 seconds a PLAY is received by the server which 12964 takes 15 ms to process. The duration of time for which the session 12965 was paused is reflected in the RTP timestamp of the RTP packets sent 12966 after this PLAY request. 12968 A client can use the RTSP range header and RTP-Info header to map NPT 12969 time of a presentation with the RTP timestamp. 12971 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 12972 was misunderstood commonly. However, for RTSP 2.0 it is expected 12973 that this will be handled correctly and no exception handling will be 12974 required. 12976 Note further: It may be required to reset some of the state to ensure 12977 the correct media decoding and the usual jitter-buffer handling when 12978 issuing a PLAY request. 12980 C.5. RTSP / RTP Integration 12982 For certain data types, tight integration between the RTSP layer and 12983 the RTP layer will be necessary. This by no means precludes the 12984 above restrictions. Combined RTSP/RTP media clients should use the 12985 RTP-Info field to determine whether incoming RTP packets were sent 12986 before or after a seek or before or after a PAUSE. 12988 C.6. Scaling with RTP 12990 For scaling (see Section 18.46), RTP timestamps should correspond to 12991 the rendering timing. For example, when playing video recorded at 30 12992 frames/second at a scale of two and speed (Section 18.50) of one, the 12993 server would drop every second frame to maintain and deliver video 12994 packets with the normal timestamp spacing of 3,000 per frame, but NPT 12995 would increase by 1/15 second for each video frame. 12997 Note: The above scaling puts requirements on the media codec or a 12998 media stream to support it. For example motion JPEG or other non- 12999 predictive video coding can easier handle the above example. 13001 C.7. Maintaining NPT synchronization with RTP timestamps 13003 The client can maintain a correct display of NPT (Normal Play Time) 13004 by noting the RTP timestamp value of the first packet arriving after 13005 repositioning. The sequence parameter of the RTP-Info 13006 (Section 18.45) header provides the first sequence number of the next 13007 segment. 13009 C.8. Continuous Audio 13011 For continuous audio, the server SHOULD set the RTP marker bit at the 13012 beginning of serving a new PLAY request or at jumps in timeline. 13013 This allows the client to perform playout delay adaptation. 13015 C.9. Multiple Sources in an RTP Session 13017 Note that more than one SSRC MAY be sent in the media stream. If it 13018 happens all sources are expected to be rendered simultaneously. 13020 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 13022 The RTCP BYE message indicates the end of use of a given SSRC. If 13023 all sources leave an RTP session, it can, in most cases, be assumed 13024 to have ended. Therefore, a client or server MUST NOT send an RTCP 13025 BYE message until it has finished using a SSRC. A server SHOULD keep 13026 using a SSRC until the RTP session is terminated. Prolonging the use 13027 of a SSRC allows the established synchronization context associated 13028 with that SSRC to be used to synchronize subsequent PLAY requests 13029 even if the PLAY response is late. 13031 An SSRC collision with the SSRC that transmits media does also have 13032 consequences, as it will normally force the media sender to change 13033 its SSRC in accordance with the RTP specification [RFC3550]. 13034 However, an RTSP server may wait and see if the client changes and 13035 thus resolve the conflict to minimize the impact. As media sender 13036 SSRC change will result in a loss of synchronization context, and 13037 require any receiver to wait for RTCP sender reports for all media 13038 requiring synchronization before being able to play out synchronized. 13039 Due to these reasons a client joining a session should take care to 13040 not select the same SSRC(s) as the server indicates in the ssrc 13041 Transport header parameter. Any SSRC signalled in the Transport 13042 header MUST be avoided. A client detecting a collision prior to 13043 sending any RTP or RTCP messages SHALL also select a new SSRC. 13045 C.11. Future Additions 13047 It is the intention that any future protocol or profile regarding 13048 media delivery and lower transport should be easy to add to RTSP. 13049 This section provides the necessary steps that needs to be meet. 13051 The following things needs to be considered when adding a new 13052 protocol or profile for use with RTSP: 13054 o The protocol or profile needs to define a name tag representing 13055 it. This tag is required to be an ABNF "token" to be possible to 13056 use in the Transport header specification. 13058 o The useful combinations of protocol, profiles and lower layer 13059 transport for this extension needs to be defined. For each 13060 combination declare the necessary parameters to use in the 13061 Transport header. 13063 o For new media protocols the interaction with RTSP needs to be 13064 addressed. One important factor will be the media 13065 synchronization. It may be necessary to have new headers similar 13066 to RTP info to carry this information. 13068 o Discuss congestion control for media, especially if transport 13069 without built in congestion control is used. 13071 See the IANA section (Section 22) for information how to register new 13072 attributes. 13074 Appendix D. Use of SDP for RTSP Session Descriptions 13076 The Session Description Protocol (SDP, [RFC4566]) may be used to 13077 describe streams or presentations in RTSP. This description is 13078 typically returned in reply to a DESCRIBE request on a URI from a 13079 server to a client, or received via HTTP from a server to a client. 13081 This appendix describes how an SDP file determines the operation of 13082 an RTSP session. Thus, it is worth pointing out that the 13083 interpretation of the SDP is done in the context of the SDP receiver, 13084 which is the one being configured. This is the same as in SAP 13085 [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each 13086 SDP is interpreted in the context of the agent providing it. 13088 SDP as is provides no mechanism by which a client can distinguish, 13089 without human guidance, between several media streams to be rendered 13090 simultaneously and a set of alternatives (e.g., two audio streams 13091 spoken in different languages). The SDP extension "Grouping of Media 13092 Lines in the Session Description Protocol (SDP)" [RFC5888] provides 13093 such functionality to some degree. Appendix D.4 describes the usage 13094 of SDP media line grouping for RTSP. 13096 D.1. Definitions 13098 The terms "session-level", "media-level" and other key/attribute 13099 names and values used in this appendix are to be used as defined in 13100 SDP[RFC4566]: 13102 D.1.1. Control URI 13104 The "a=control:" attribute is used to convey the control URI. This 13105 attribute is used both for the session and media descriptions. If 13106 used for individual media, it indicates the URI to be used for 13107 controlling that particular media stream. If found at the session 13108 level, the attribute indicates the URI for aggregate control 13109 (presentation URI). The session level URI MUST be different from any 13110 media level URI. The presence of a session level control attribute 13111 MUST be interpreted as support for aggregated control. The control 13112 attribute MUST be present on media level unless the presentation only 13113 contains a single media stream, in which case the attribute MAY be 13114 present on the session level only and then also apply to that single 13115 media stream. 13117 ABNF for the attribute is defined in Section 20.3. 13119 Example: 13121 a=control:rtsp://example.com/foo 13123 This attribute MAY contain either relative or absolute URIs, 13124 following the rules and conventions set out in RFC 3986 [RFC3986]. 13125 Implementations MUST look for a base URI in the following order: 13127 1. the RTSP Content-Base field; 13129 2. the RTSP Content-Location field; 13131 3. the RTSP Request-URI. 13133 If this attribute contains only an asterisk (*), then the URI MUST be 13134 treated as if it were an empty embedded URI, and thus inherit the 13135 entire base URI. 13137 Note, RFC 2326 was very unclear on the processing of relative URI 13138 and several RTSP 1.0 implementations at the point of publishing 13139 this document did not perform RFC 3986 processing to determine the 13140 resulting URI, instead simple concatenation is common. To avoid 13141 this issue completely it is recommended to use absolute URI in the 13142 SDP. 13144 The URI handling for SDPs from container files need special 13145 consideration. For example let's assume that a container file has 13146 the URI: "rtsp://example.com/container.mp4". Let's further assume 13147 this URI is the base URI, and that there is an absolute media level 13148 URI: "rtsp://example.com/container.mp4/trackID=2". A relative media 13149 level URI that resolves in accordance with RFC 3986 [RFC3986] to the 13150 above given media URI is: "container.mp4/trackID=2". It is usually 13151 not desirable to need to include in or modify the SDP stored within 13152 the container file with the server local name of the container file. 13153 To avoid this, one can modify the base URI used to include a trailing 13154 slash, e.g., "rtsp://example.com/container.mp4/". In this case the 13155 relative URI for the media will only need to be: "trackID=2". 13156 However, this will also mean that using "*" in the SDP will result in 13157 control URI including the trailing slash, i.e., "rtsp://example.com/ 13158 container.mp4/". 13160 Note: The usage of TrackID in the above is not a standardized 13161 form, but one example out of several similar strings such as 13162 TrackID, Track_ID, StreamID that is used by different server 13163 vendors to indicate a particular piece of media inside a container 13164 file. 13166 D.1.2. Media Streams 13168 The "m=" field is used to enumerate the streams. It is expected that 13169 all the specified streams will be rendered with appropriate 13170 synchronization. If the session is over multicast, the port number 13171 indicated SHOULD be used for reception. The client MAY try to 13172 override the destination port, through the Transport header. The 13173 servers MAY allow this, the response will indicate if allowed or not. 13174 If the session is unicast, the port numbers are the ones RECOMMENDED 13175 by the server to the client, about which receiver ports to use; the 13176 client MUST still include its receiver ports in its SETUP request. 13177 The client MAY ignore this recommendation. If the server has no 13178 preference, it SHOULD set the port number value to zero. 13180 The "m=" lines contain information about which transport protocol, 13181 profile, and possibly lower-layer is to be used for the media stream. 13182 The combination of transport, profile and lower layer, like RTP/AVP/ 13183 UDP needs to be defined for how to be used with RTSP. The currently 13184 defined combinations are defined in Appendix C, further combinations 13185 MAY be specified. 13187 Example: 13189 m=audio 0 RTP/AVP 31 13191 D.1.3. Payload Type(s) 13193 The payload type(s) are specified in the "m=" line. In case the 13194 payload type is a static payload type from RFC 3551 [RFC3551], no 13195 other information may be required. In case it is a dynamic payload 13196 type, the media attribute "rtpmap" is used to specify what the media 13197 is. The "encoding name" within the "rtpmap" attribute may be one of 13198 those specified in [RFC4856], or a media type registered with IANA 13199 according to [RFC4855], or an experimental encoding as specified in 13200 SDP [RFC4566]). Codec-specific parameters are not specified in this 13201 field, but rather in the "fmtp" attribute described below. 13203 The selection of the RTP payload type numbers used may be required to 13204 consider RTP and RTCP Multiplexing [RFC5761] if that is to be 13205 supported by the server. 13207 D.1.4. Format-Specific Parameters 13209 Format-specific parameters are conveyed using the "fmtp" media 13210 attribute. The syntax of the "fmtp" attribute is specific to the 13211 encoding(s) that the attribute refers to. Note that some of the 13212 format specific parameters may be specified outside of the fmtp 13213 parameters, like for example the "ptime" attribute for most audio 13214 encodings. 13216 D.1.5. Directionality of media stream 13218 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 13219 provide instructions about the direction the media streams flow 13220 within a session. When using RTSP the SDP can be delivered to a 13221 client using either RTSP DESCRIBE or a number of RTSP external 13222 methods, like HTTP, FTP, and email. Based on this the SDP applies to 13223 how the RTSP client will see the complete session. Thus media 13224 streams delivered from the RTSP server to the client, would be given 13225 the "a=recvonly" attribute. 13227 "a=recvonly" in a SDP provided to the RTSP client indicates that 13228 media delivery will only occur in the direction from the RTSP server 13229 to the client. SDP provided to the RTSP client that lacks any of the 13230 directionality attributes (a=recvonly, a=sendonly, a=sendrecv) would 13231 be interpreted as having a=sendrecv. At the time of writing there 13232 exist no RTSP mode suitable for media traffic in the direction from 13233 the RTSP client to the server. Thus all RTSP SDP SHOULD have 13234 a=recvonly attribute when using the PLAY mode defined in this 13235 document. If future modes are defined for media in client to server 13236 direction, then usage of a=sendonly, or a=sendrecv may become 13237 suitable to indicate intended media directions. 13239 D.1.6. Range of Presentation 13241 The "a=range" attribute defines the total time range of the stored 13242 session or an individual media. Non-seekable live sessions can be 13243 indicated as specified below, while the length of live sessions can 13244 be deduced from the "t=" and "r=" SDP parameters. 13246 The attribute is both a session and a media level attribute. For 13247 presentations that contain media streams of the same duration, the 13248 range attribute SHOULD only be used at session-level. In case of 13249 different lengths the range attribute MUST be given at media level 13250 for all media, and SHOULD NOT be given at session level. If the 13251 attribute is present at both media level and session level the media 13252 level values MUST be used. 13254 Note: Usually one will specify the same length for all media, even if 13255 there isn't media available for the full duration on all media. 13256 However, that requires that the server accepts PLAY requests within 13257 that range. 13259 Servers MUST take care to provide RTSP Range (see Section 18.40) 13260 values that are consistent with what is presented in the SDP for the 13261 content. There is no reason for non dynamic content, like media 13262 clips provided on demand to have inconsistent values. Inconsistent 13263 values between the SDP and the actual values for the content handled 13264 by the server is likely to generate some failure, like 457 "Invalid 13265 Range", in case the client uses PLAY requests with a Range header. 13266 In case the content is dynamic in length and it is infeasible to 13267 provide a correct value in the SDP the server is recommended to 13268 describe this as non-seekable content (see below). The server MAY 13269 override that property in the response to a PLAY request using the 13270 correct values in the Range header. 13272 The unit is specified first, followed by the value range. The units 13273 and their values are as defined in Section 4.4.1, Section 4.4.2 and 13274 Section 4.4.3 and MAY be extended with further formats. Any open 13275 ended range (start-), i.e., without stop range, is of unspecified 13276 duration and MUST be considered as non-seekable content unless this 13277 property is overridden. Multiple instances carrying different clock 13278 formats MAY be included at either session or media level. 13280 ABNF for the attribute is defined in Section 20.3. 13282 Examples: 13284 a=range:npt=0-34.4368 13285 a=range:clock=19971113T211503Z-19971113T220300Z 13286 Non seekable stream of unknown duration: 13287 a=range:npt=0- 13289 D.1.7. Time of Availability 13291 The "t=" field defines when the SDP is valid. For on-demand content 13292 the server SHOULD indicate a stop time value for which it guarantees 13293 the description to be valid, and a start time that is equal to or 13294 before the time at which the DESCRIBE request was received. It MAY 13295 also indicate start and stop times of 0, meaning that the session is 13296 always available. 13298 For sessions that are of live type, i.e., specific start time, 13299 unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD 13300 be used to indicate the start time of the event. The stop time 13301 SHOULD be given so that the live event will have ended at that time, 13302 while still not be unnecessary long into the future. 13304 D.1.8. Connection Information 13306 In SDP used with RTSP, the "c=" field contains the destination 13307 address for the media stream. If a multicast address is specified 13308 the client SHOULD use this address in any SETUP request as 13309 destination address, including any additional parameters, such as 13310 TTL. For on-demand unicast streams and some multicast streams, the 13311 destination address MAY be specified by the client via the SETUP 13312 request, thus overriding any specified address. To identify streams 13313 without a fixed destination address, where the client is required to 13314 specify a destination address, the "c=" field SHOULD be set to a null 13315 value. For addresses of type "IP4", this value MUST be "0.0.0.0", 13316 and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be 13317 written as "::"), i.e., the unspecified address according to RFC 4291 13318 [RFC4291]. 13320 D.1.9. Message Body Tag 13322 The optional "a=mtag" attribute identifies a version of the session 13323 description. It is opaque to the client. SETUP requests may include 13324 this identifier in the If-Match field (see Section 18.24) to only 13325 allow session establishment if this attribute value still corresponds 13326 to that of the current description. The attribute value is opaque 13327 and may contain any character allowed within SDP attribute values. 13329 ABNF for the attribute is defined in Section 20.3. 13331 Example: 13333 a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a" 13335 One could argue that the "o=" field provides identical 13336 functionality. However, it does so in a manner that would put 13337 constraints on servers that need to support multiple session 13338 description types other than SDP for the same piece of media 13339 content. 13341 D.2. Aggregate Control Not Available 13343 If a presentation does not support aggregate control no session level 13344 "a=control:" attribute is specified. For a SDP with multiple media 13345 sections specified, each section will have its own control URI 13346 specified via the "a=control:" attribute. 13348 Example: 13350 v=0 13351 o=- 2890844256 2890842807 IN IP4 192.0.2.56 13352 s=I came from a web page 13353 e=adm@example.com 13354 c=IN IP4 0.0.0.0 13355 t=0 0 13356 m=video 8002 RTP/AVP 31 13357 a=control:rtsp://audio.example.com/movie.aud 13358 m=audio 8004 RTP/AVP 3 13359 a=control:rtsp://video.example.com/movie.vid 13361 Note that the position of the control URI in the description implies 13362 that the client establishes separate RTSP control sessions to the 13363 servers audio.example.com and video.example.com. 13365 It is recommended that an SDP file contains the complete media 13366 initialization information even if it is delivered to the media 13367 client through non-RTSP means. This is necessary as there is no 13368 mechanism to indicate that the client should request more detailed 13369 media stream information via DESCRIBE. 13371 D.3. Aggregate Control Available 13373 In this scenario, the server has multiple streams that can be 13374 controlled as a whole. In this case, there are both a media-level 13375 "a=control:" attributes, which are used to specify the stream URIs, 13376 and a session-level "a=control:" attribute which is used as the 13377 Request-URI for aggregate control. If the media-level URI is 13378 relative, it is resolved to absolute URIs according to Appendix D.1.1 13379 above. 13381 Example: 13383 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 13384 CSeq: 1 13385 User-Agent: PhonyClient/1.2 13387 M->C: RTSP/2.0 200 OK 13388 CSeq: 1 13389 Date: Wed, 23 Jan 2013 15:36:52 +0000 13390 Expires: Wed, 23 Jan 2013 16:36:52 +0000 13391 Content-Type: application/sdp 13392 Content-Base: rtsp://example.com/movie/ 13393 Content-Length: 227 13395 v=0 13396 o=- 2890844256 2890842807 IN IP4 192.0.2.211 13397 s=I contain 13398 i= 13399 e=adm@example.com 13400 c=IN IP4 0.0.0.0 13401 a=control:* 13402 t=0 0 13403 m=video 8002 RTP/AVP 31 13404 a=control:trackID=1 13405 m=audio 8004 RTP/AVP 3 13406 a=control:trackID=2 13408 In this example, the client is recommended to establish a single RTSP 13409 session to the server, and uses the URIs rtsp://example.com/movie/ 13410 trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video 13411 and audio streams, respectively. The URI rtsp://example.com/movie/, 13412 which is resolved from the "*", controls the whole presentation 13413 (movie). 13415 A client is not required to issue SETUP requests for all streams 13416 within an aggregate object. Servers should allow the client to ask 13417 for only a subset of the streams. 13419 D.4. Grouping of Media Lines in SDP 13421 For some types of media it is desirable to express a relationship 13422 between various media components, for instance, for lip 13423 synchronization or Scalable Video Codec (SVC) [RFC5583]. This 13424 relationship is expressed on the SDP level by grouping of media 13425 lines, as described in [RFC5888] and can be exposed to RTSP. 13427 For RTSP it is mainly important to know how to handle grouped medias 13428 received by means of SDP, i.e., if the media are under aggregate 13429 control (see Appendix D.3) or if aggregate control is not available 13430 (see Appendix D.2). 13432 It is RECOMMENDED that grouped medias are handled by aggregate 13433 control, to give the client the ability to control either the whole 13434 presentation or single medias. 13436 D.5. RTSP external SDP delivery 13438 There are some considerations that need to be made when the session 13439 description is delivered to the client outside of RTSP, for example 13440 via HTTP or email. 13442 First of all, the SDP needs to contain absolute URIs, since relative 13443 will in most cases not work as the delivery will not correctly 13444 forward the base URI. 13446 The writing of the SDP session availability information, i.e., "t=" 13447 and "r=", needs to be carefully considered. When the SDP is fetched 13448 by the DESCRIBE method, the probability that it is valid is very 13449 high. However, the same is much less certain for SDPs distributed 13450 using other methods. Therefore the publisher of the SDP should take 13451 care to follow the recommendations about availability in the SDP 13452 specification [RFC4566] in Section 4.2. 13454 Appendix E. RTSP Use Cases 13456 This Appendix describes the most important and considered use cases 13457 for RTSP. They are listed in descending order of importance in 13458 regards to ensuring that all necessary functionality is present. 13459 This specification only fully supports usage of the two first. Also 13460 in these first two cases, there are special cases or exceptions that 13461 are not supported without extensions, e.g., the redirection of media 13462 delivery to another address than the controlling agent's (client's). 13464 E.1. On-demand Playback of Stored Content 13466 An RTSP capable server stores content suitable for being streamed to 13467 a client. A client desiring playback of any of the stored content 13468 uses RTSP to set up the media transport required to deliver the 13469 desired content. RTSP is then used to initiate, halt and manipulate 13470 the actual transmission (playout) of the content. RTSP is also 13471 required to provide necessary description and synchronization 13472 information for the content. 13474 The above high level description can be broken down into a number of 13475 functions that RTSP needs to be capable of. 13477 Presentation Description: Provide initialization information about 13478 the presentation (content); for example, which media codecs are 13479 needed for the content. Other information that is important 13480 includes the number of media streams the presentation contains, 13481 the transport protocols used for the media streams, and 13482 identifiers for these media streams. This information is 13483 required before setup of the content is possible and to 13484 determine if the client is even capable of using the content. 13486 This information need not be sent using RTSP; other external 13487 protocols can be used to transmit the transport presentation 13488 descriptions. Two good examples are the use of HTTP [RFC2616] 13489 or email to fetch or receive presentation descriptions like SDP 13490 [RFC4566] 13492 Setup: Set up some or all of the media streams in a presentation. 13493 The setup itself consists of selecting the protocol for media 13494 transport and the necessary parameters for the protocol, like 13495 addresses and ports. 13497 Control of Transmission: After the necessary media streams have been 13498 established the client can request the server to start 13499 transmitting the content. The client must be allowed to start 13500 or stop the transmission of the content at arbitrary times. 13501 The client must also be able to start the transmission at any 13502 point in the timeline of the presentation. 13504 Synchronization: For media transport protocols like RTP [RFC3550] it 13505 might be beneficial to carry synchronization information within 13506 RTSP. This may be due to either the lack of inter-media 13507 synchronization within the protocol itself, or the potential 13508 delay before the synchronization is established (which is the 13509 case for RTP when using RTCP). 13511 Termination: Terminate the established contexts. 13513 For this use case there are a number of assumptions about how it 13514 works. These are: 13516 On-Demand content: The content is stored at the server and can be 13517 accessed at any time during a time period when it is intended 13518 to be available. 13520 Independent sessions: A server is capable of serving a number of 13521 clients simultaneously, including from the same piece of 13522 content at different points in that presentations time-line. 13524 Unicast Transport: Content for each individual client is transmitted 13525 to them using unicast traffic. 13527 It is also possible to redirect the media traffic to a different 13528 destination than that of the agent controlling the traffic. However, 13529 allowing this without appropriate mechanisms for checking that the 13530 destination approves of this allows for distributed denial of service 13531 attacks (DDoS). 13533 E.2. Unicast Distribution of Live Content 13535 This use case is similar to the above on-demand content case (see 13536 Appendix E.1) the difference is the nature of the content itself. 13537 Live content is continuously distributed as it becomes available from 13538 a source; i.e., the main difference from on-demand is that one starts 13539 distributing content before the end of it has become available to the 13540 server. 13542 In many cases the consumer of live content is only interested in 13543 consuming what actually happens "now"; i.e., very similar to 13544 broadcast TV. However, in this case it is assumed that there exists 13545 no broadcast or multicast channel to the users, and instead the 13546 server functions as a distribution node, sending the same content to 13547 multiple receivers, using unicast traffic between server and client. 13548 This unicast traffic and the transport parameters are individually 13549 negotiated for each receiving client. 13551 Another aspect of live content is that it often has a very limited 13552 time of availability, as it is only available for the duration of the 13553 event the content covers. An example of such a live content could be 13554 a music concert which lasts 2 hour and starts at a predetermined 13555 time. Thus there is a need to announce when and for how long the 13556 live content is available. 13558 In some cases, the server providing live content may be saving some 13559 or all of the content to allow clients to pause the stream and resume 13560 it from the paused point, or to "rewind" and play continuously from a 13561 point earlier than the live point. Hence, this use case does not 13562 necessarily exclude playing from other than the live point of the 13563 stream, playing with scales other than 1.0, etc. 13565 E.3. On-demand Playback using Multicast 13567 It is possible to use RTSP to request that media be delivered to a 13568 multicast group. The entity setting up the session (the controller) 13569 will then control when and what media is delivered to the group. 13570 This use case has some potential for denial of service attacks by 13571 flooding a multicast group. Therefore, a mechanism is needed to 13572 indicate that the group actually accepts the traffic from the RTSP 13573 server. 13575 An open issue in this use case is how one ensures that all receivers 13576 listening to the multicast or broadcast receives the session 13577 presentation configuring the receivers. This specification has to 13578 rely on an external solution to solve this issue. 13580 E.4. Inviting an RTSP server into a conference 13582 If one has an established conference or group session, it is possible 13583 to have an RTSP server distribute media to the whole group. 13584 Transmission to the group is simplest when controlled by a single 13585 participant or leader of the conference. Shared control might be 13586 possible, but would require further investigation and possibly 13587 extensions. 13589 This use case assumes that there exists either multicast or a 13590 conference focus that redistribute media to all participants. 13592 This use case is intended to be able to handle the following 13593 scenario: A conference leader or participant (hereafter called the 13594 controller) has some pre-stored content on an RTSP server that he 13595 wants to share with the group. The controller sets up an RTSP 13596 session at the streaming server for this content and retrieves the 13597 session description for the content. The destination for the media 13598 content is set to the shared multicast group or conference focus. 13599 When desired by the controller, he/she can start and stop the 13600 transmission of the media to the conference group. 13602 There are several issues with this use case that are not solved by 13603 this core specification for RTSP: 13605 Denial of service: To avoid an RTSP server from being an unknowing 13606 participant in a denial of service attack the server needs to 13607 be able to verify the destination's acceptance of the media. 13608 Such a mechanism to verify the approval of received media does 13609 not yet exist; instead, only policies can be used, which can be 13610 made to work in controlled environments. 13612 Distributing the presentation description to all participants in the 13613 group: 13614 To enable a media receiver to correctly decode the content 13615 the media configuration information needs to be distributed 13616 reliably to all participants. This will most likely require 13617 support from an external protocol. 13619 Passing control of the session: If it is desired to pass control 13620 of the RTSP session between the participants, some support 13621 will be required by an external protocol to exchange state 13622 information and possibly floor control of who is controlling 13623 the RTSP session. 13625 E.5. Live Content using Multicast 13627 This use case in its simplest form does not require any use of RTSP 13628 at all; this is what multicast conferences being announced with SAP 13629 [RFC2974] and SDP are intended to handle. However, in use cases 13630 where more advanced features like access control to the multicast 13631 session are desired, RTSP could be used for session establishment. 13633 A client desiring to join a live multicasted media session with 13634 cryptographic (encryption) access control could use RTSP in the 13635 following way. The source of the session announces the session and 13636 gives all interested an RTSP URI. The client connects to the server 13637 and requests the presentation description, allowing configuration for 13638 reception of the media. In this step it is possible for the client 13639 to use secured transport and any desired level of authentication; for 13640 example, for billing or access control. An RTSP link also allows for 13641 load balancing between multiple servers. 13643 If these were the only goals, they could be achieved by simply using 13644 HTTP. However, for cases where the sender likes to keep track of 13645 each individual receiver of a session, and possibly use the session 13646 as a side channel for distributing key-updates or other information 13647 on a per-receiver basis, and the full set of receivers is not known 13648 prior to the session start, the state establishment that RTSP 13649 provides can be beneficial. In this case a client would establish an 13650 RTSP session for this multicast group with the RTSP server. The RTSP 13651 server will not transmit any media, but instead will point to the 13652 multicast group. The client and server will be able to keep the 13653 session alive for as long as the receiver participates in the session 13654 thus enabling, for example, the server to push updates to the client. 13656 This use case will most likely not be able to be implemented without 13657 some extensions to the server-to-client push mechanism. Here the 13658 PLAY_NOTIFY method (see Section 13.5) with a suitable extension could 13659 provide clear benefits. 13661 Appendix F. Text format for Parameters 13663 A resource of type "text/parameters" consists of either 1) a list of 13664 parameters (for a query) or 2) a list of parameters and associated 13665 values (for an response or setting of the parameter). Each entry of 13666 the list is a single line of text. Parameters are separated from 13667 values by a colon. The parameter name MUST only use US-ASCII visible 13668 characters while the values are UTF-8 text strings. The media type 13669 registration form is in Section 22.16. 13671 There is a potential interoperability issue for this format. It was 13672 named in RFC 2326 but never defined, even if used in examples that 13673 hint at the syntax. This format matches the purpose and its syntax 13674 supports the examples provided. However, it goes further by allowing 13675 UTF-8 in the value part, thus usage of UTF-8 strings may not be 13676 supported. However, as individual parameters are not defined, the 13677 using application anyway needs to have out-of-band agreement or using 13678 feature-tag to determine if the end-point supports the parameters. 13680 The ABNF [RFC5234] grammar for "text/parameters" content is: 13682 file = *((parameter / parameter-value) CRLF) 13683 parameter = 1*visible-except-colon 13684 parameter-value = parameter *WSP ":" value 13685 visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" 13686 value = *(TEXT-UTF8char / WSP) 13687 TEXT-UTF8char = 13688 WSP = ; Space or HTAB 13689 VCHAR = 13690 CRLF = 13692 Appendix G. Requirements for Unreliable Transport of RTSP 13694 This appendix provides guidance for those who want to implement RTSP 13695 messages over unreliable transports as has been defined in RTSP 1.0 13696 [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some 13697 basic information for the transport of RTSP messages over UDP. The 13698 information is being provided here as there has been at at least one 13699 commercial implementation and compatibility with that should be 13700 maintained. 13702 The following points should be considered for an interoperable 13703 implementation: 13705 o Requests shall be acknowledged by the receiver. If there is no 13706 acknowledgement, the sender may resend the same message after a 13707 timeout of one round-trip time (RTT). Any retransmissions due to 13708 lack of acknowledgement must carry the same sequence number as the 13709 original request. 13711 o The round-trip time can be estimated as in TCP (RFC 6298) 13712 [RFC6298], with an initial round-trip value of 500 ms. An 13713 implementation may cache the last RTT measurement as the initial 13714 value for future connections. 13716 o The Timestamp header (Section 18.53) is used to avoid the 13717 retransmission ambiguity problem [Stevens98]. 13719 o The registered default port for RTSP over UDP for the server is 13720 554. 13722 o RTSP messages can be carried over any lower-layer transport 13723 protocol that is 8-bit clean. 13725 o RTSP messages are vulnerable to bit errors and should not be 13726 subjected to them. 13728 o Source authentication, or at least validation that RTSP messages 13729 comes from the same entity becomes extremely important, as session 13730 hijacking may be substantially easier for RTSP message transport 13731 using an unreliable protocol like UDP than for TCP. 13733 There are two RTSP headers that are primarily intended for being used 13734 by the unreliable handling of RTSP messages and which will be 13735 maintained: 13737 o CSeq: See Section 18.20. It should be noted that the CSeq header 13738 is also required to match requests and responses independent 13739 whether a reliable or unreliable transport is used. 13741 o Timestamp: See Section 18.53 13743 Appendix H. Backwards Compatibility Considerations 13745 This section contains notes on issues about backwards compatibility 13746 with clients or servers being implemented according to RFC 2326 13747 [RFC2326]. Note that there exists no requirement to implement RTSP 13748 1.0; in fact this document recommend against it as it is difficult to 13749 do in an interoperable way. 13751 A server implementing RTSP/2.0 MUST include an RTSP-Version of RTSP/ 13752 2.0 in all responses to requests containing RTSP-Version RTSP/2.0. 13753 If a server receives an RTSP/1.0 request, it MAY respond with an RTSP 13754 /1.0 response if it chooses to support RFC 2326. If the server 13755 chooses not to support RFC 2326, it MUST respond with a 505 (RTSP 13756 Version not supported) status code. A server MUST NOT respond to an 13757 RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 response. 13759 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 13760 Version of 2.0 to determine whether a server supports RTSP/2.0. If 13761 the server responds with either an RTSP-Version of 1.0 or a status 13762 code of 505 (RTSP Version not supported), the client will have to use 13763 RTSP/1.0 requests if it chooses to support RFC 2326. 13765 H.1. Play Request in Play State 13767 The behavior in the server when a Play is received in Play state has 13768 changed (Section 13.4). In RFC 2326, the new PLAY request would be 13769 queued until the current Play completed. Any new PLAY request now 13770 takes effect immediately replacing the previous request. 13772 H.2. Using Persistent Connections 13774 Some server implementations of RFC 2326 maintain a one-to-one 13775 relationship between a connection and an RTSP session. Such 13776 implementations require clients to use a persistent connection to 13777 communicate with the server and when a client closes its connection, 13778 the server may remove the RTSP session. This is worth noting if a 13779 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 13781 Appendix I. Changes 13783 This appendix briefly lists the differences between RTSP 1.0 13784 [RFC2326] and RTSP 2.0 for an informational purpose. For 13785 implementers of RTSP 2.0 it is recommended to read carefully through 13786 this memo and not to rely on the list of changes below to adapt from 13787 RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards 13788 compatible with RTSP 1.0 [RFC2326] other than the version negotiation 13789 mechanism. 13791 I.1. Brief Overview 13793 The following protocol elements were removed in RTSP 2.0 compared to 13794 RTSP 1.0: 13796 o there is no section on minimal implementation anymore, but more 13797 the definition of RTSP 2.0 core; 13799 o the RECORD and ANNOUNCE methods and all related functionality 13800 (including 201 (Created) and 250 (Low On Storage Space) status 13801 codes); 13803 o the use of UDP for RTSP message transport was removed due to 13804 missing interest and to broken specification; 13806 o the use of PLAY method for keep-alive in Play state. 13808 The following protocol elements were added or changed in RTSP 2.0 13809 compared to RTSP 1.0: 13811 o RTSP session TEARDOWN from the server to the client; 13812 o IPv6 support; 13814 o extended IANA registries (e.g., transport headers parameters, 13815 transport-protocol, profile, lower-transport, and mode); 13817 o request pipelining for quick session start-up; 13819 o fully reworked state-machine; 13821 o RTSP messages now use URIs rather then URLs; 13823 o incorporated much of related HTTP text ([RFC2616]) in this memo, 13824 compared to just referencing the sections in HTTP, to avoid 13825 ambiguities; 13827 o the REDIRECT method was expanded and diversified for different 13828 situations; 13830 o Includes a new section about how to setup different media 13831 transport alternatives and their profiles, and lower layer 13832 protocols. This caused the appendix on RTP interaction to be 13833 moved there instead of being in the part which describes RTP. The 13834 section also includes guidelines what to consider when writing 13835 usage guidelines for new protocols and profiles; 13837 o Added an asynchronous notification method PLAY_NOTIFY. This 13838 method is used by the RTSP server to asynchronously notify clients 13839 about session changes while in Play state. To a limited extent 13840 this is comparable with some implementations of ANNOUNCE in RTSP 13841 1.0 not intended for Recording. 13843 I.2. Detailed List of Changes 13845 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 13846 defining RTSP 2.0. Note that this list does not reflect minor 13847 changes in wording or correction of typographical errors. 13849 o The section on minimal implementation was deleted without 13850 substitution. 13852 o The Transport header has been changed in the following way: 13854 * The ABNF has been changed to define that extensions are 13855 possible, and that unknown parameters result in that servers 13856 ignore the transport specification. 13858 * To prevent backwards compatibility issues, any extension or new 13859 parameter requires the usage of a feature-tag combined with the 13860 Require header. 13862 * Syntax unclarities with the Mode parameter have been resolved. 13864 * Syntax error with ";" for multicast and unicast has been 13865 resolved. 13867 * Two new addressing parameters have been defined, src_addr and 13868 dest_addr. These replace the parameters "port", "client_port", 13869 "server_port", "destination", "source". 13871 * Support for IPv6 explicit addresses in all address fields has 13872 been included. 13874 * To handle URI definitions that contain ";" or "," a quoted URI 13875 format has been introduced and is required. 13877 * Defined IANA registries for the transport headers parameters, 13878 transport-protocol, profile, lower-transport, and mode. 13880 * The transport headers interleaved parameter's text was made 13881 more strict and uses formal requirements levels. It was also 13882 clarified that the interleaved channels are symmetric and that 13883 it is the server that sets the channel numbers. 13885 * It has been clarified that the client can't request of the 13886 server to use a certain RTP SSRC, using a request with the 13887 transport parameter SSRC. 13889 * Syntax definition for SSRC has been clarified to require 8HEX. 13890 It has also been extended to allow multiple values for clients 13891 supporting this version. 13893 * Clarified the text on the transport headers "dest_addr" 13894 parameters regarding what security precautions the server is 13895 required to perform. 13897 o The Range formats has been changed in the following way: 13899 * The NPT format has been given an initial NPT identifier that 13900 must now be used. 13902 * All formats now support initial open ended formats of type 13903 "npt=-10" and also format only "Range: smpte" ranges for usage 13904 with GET_PARAMETER requests. 13906 * The npt-hhmmss notation now follows ISO 8601 more stricter. 13908 o RTSP message handling has been changed in the following way: 13910 * RTSP messages now use URIs rather then URLs. 13912 * It has been clarified that a 4xx message due to missing CSeq 13913 header shall be returned without a CSeq header. 13915 * The 300 (Multiple Choices) response code has been removed. 13917 * Rules for how to handle timing out RTSP messages has been 13918 added. 13920 * Extended Pipelining rules allowing for quick session startup. 13922 * Sequence numbering and proxy handling of sequence number 13923 defined, including case when response arrive out of order. 13925 o The HTTP references have been updated to RFC 2616 and RFC 2617. 13926 Most of the text has been copied and then altered to fit RTSP into 13927 this specification. Public, and the Content-Base header has also 13928 been imported from RFC 2068 so that they are defined in the RTSP 13929 specification. Known effects on RTSP due to HTTP clarifications: 13931 * Content-Encoding header can include encoding of type 13932 "identity". 13934 o The state machine section has been completely rewritten. It now 13935 includes more details and is also more clear about the model used. 13937 o An IANA section has been included which contains a number of 13938 registries and their rules. This will allow us to use IANA to 13939 keep track of RTSP extensions. 13941 o The transport of RTSP messages has seen the following changes: 13943 * The use of UDP for RTSP message transport has been deprecated 13944 due to missing interest and to broken specification. 13946 * The rules for how TCP connections are to be handled has been 13947 clarified. Now it is made clear that servers should not close 13948 the TCP connection unless they have been unused for significant 13949 time. 13951 * Strong recommendations why server and clients should use 13952 persistent connections have also been added. 13954 * There is now a requirement on the servers to handle non- 13955 persistent connections as this provides fault tolerance. 13957 * Added wording on the usage of Connection:Close for RTSP. 13959 * Specified usage of TLS for RTSP messages, including a scheme to 13960 approve a proxy's TLS connection to the next hop. 13962 o The following header related changes have been made: 13964 * Accept-Ranges response-header is added. This header clarifies 13965 which range formats that can be used for a resource. 13967 * Fixed the missing definitions for the Cache-Control header. 13968 Also added to the syntax definition the missing delta-seconds 13969 for max-stale and min-fresh parameters. 13971 * Put requirement on CSeq header that the value is increased by 13972 one for each new RTSP request. A Recommendation to start at 0 13973 has also been added. 13975 * Added requirement that the Date header must be used for all 13976 messages with message body and the Server should always include 13977 it. 13979 * Removed possibility of using Range header with Scale header to 13980 indicate when it is to be activated, since it can't work as 13981 defined. Also added rule that lack of Scale header in response 13982 indicates lack of support for the header. Feature-tags for 13983 scaled playback has been defined. 13985 * The Speed header must now be responded to indicate support and 13986 the actual speed going to be used. A feature-tag is defined. 13987 Notes on congestion control were also added. 13989 * The Supported header was borrowed from SIP [RFC3261] to help 13990 with the feature negotiation in RTSP. 13992 * Clarified that the Timestamp header can be used to resolve 13993 retransmission ambiguities. 13995 * The Session header text has been expanded with an explanation 13996 on keep-alive and which methods to use. SET_PARAMETER is now 13997 recommended to use if only keep-alive within RTSP is desired. 13999 * It has been clarified how the Range header formats are used to 14000 indicate pause points in the PAUSE response. 14002 * Clarified that RTP-Info URIs that are relative, use the 14003 Request-URI as base URI. Also clarified that the used URI must 14004 be the one that was used in the SETUP request. The URIs are 14005 now also required to be quoted. The header also expresses the 14006 SSRC for the provided RTP timestamp and sequence number values. 14008 * Added text that requires the Range to always be present in PLAY 14009 responses. Clarified what should be sent in case of live 14010 streams. 14012 * The headers table has been updated using a structure borrowed 14013 from SIP. Those tables convey much more information and should 14014 provide a good overview of the available headers. 14016 * It has been clarified that any message with a message body is 14017 required to have a Content-Length header. This was the case in 14018 RFC 2326, but could be misinterpreted. 14020 * ETag has changed name to MTag. 14022 * To resolve functionality around MTag. The MTag and If-None- 14023 Match header have been added from HTTP with necessary 14024 clarification in regards to RTSP operation. 14026 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 14027 it has been removed from HTTP due to lack of use. Public is 14028 used quite frequently in RTSP. 14030 * Clarified rules for populating the Public header so that it is 14031 an intersection of the capabilities of all the RTSP agents in a 14032 chain. 14034 * Added the Media-Range header for listing the current 14035 availability of the media range. 14037 * Added the Notify-Reason header for giving the reason when 14038 sending PLAY_NOTIFY requests. 14040 * A new header Seek-Style has been defined to direct and inform 14041 how any seek operation should/have been performed. 14043 o The Protocol Syntax has been changed in the following way: 14045 * All ABNF definitions are updated according to the rules defined 14046 in RFC 5234 [RFC5234] and have been gathered in a separate 14047 Section 20. 14049 * The ABNF for the User-Agent and Server headers have been 14050 corrected. 14052 * Some definitions in the introduction regarding the RTSP session 14053 have been changed. 14055 * The protocol has been made fully IPv6 capable. 14057 * The CHAR rule has been changed to exclude NULL. 14059 o The Status codes have been changed in the following way: 14061 * The use of status code 303 "See Other" has been deprecated as 14062 it does not make sense to use in RTSP. 14064 * When sending response 451 and 458 the response body should 14065 contain the offending parameters. 14067 * Clarification on when a 3rr redirect status code can be 14068 received has been added. This includes receiving 3rr as a 14069 result of a request within a established session. This 14070 provides clarification to a previous unspecified behavior. 14072 * Removed the 201 (Created) and 250 (Low On Storage Space) status 14073 codes as they are only relevant to recording, which is 14074 deprecated. 14076 * Several new Status codes have been defined: 464 "Data Transport 14077 Not Ready Yet", 465 "Notification Reason Unknown", 470 14078 "Connection Authorization Required", 471 "Connection 14079 Credentials not accepted", 472 "Failure to establish secure 14080 connection". 14082 o The following functionality has been deprecated from the protocol: 14084 * The use of Queued Play. 14086 * The use of PLAY method for keep-alive in Play state. 14088 * The RECORD and ANNOUNCE methods and all related functionality. 14089 Some of the syntax has been removed. 14091 * The possibility to use timed execution of methods with the time 14092 parameter in the Range header. 14094 * The description on how rtspu works is not part of the core 14095 specification and will require external description. Only that 14096 it exists is defined here and some requirements for the 14097 transport is provided. 14099 o The following changes have been made in relation to methods: 14101 * The OPTIONS method has been clarified with regards to the use 14102 of the Public and Allow headers. 14104 * Added text clarifying the usage of SET_PARAMETER for keep-alive 14105 and usage without any body. 14107 * PLAY method is now allowed to be pipelined with the pipelining 14108 of one or more SETUP requests following the initial that 14109 generates the session for aggregated control. 14111 * REDIRECT has been expanded and diversified for different 14112 situations. 14114 * Added a new method PLAY_NOTIFY. This method is used by the 14115 RTSP server to asynchronously notify clients about session 14116 changes. 14118 o Wrote a new section about how to setup different media transport 14119 alternatives and their profiles, and lower layer protocols. This 14120 caused the appendix on RTP interaction to be moved there instead 14121 of being in the part which describes RTP. The section also 14122 includes guidelines what to consider when writing usage guidelines 14123 for new protocols and profiles. 14125 o Setup and usage of independent TCP connections for transport of 14126 RTP has been specified. 14128 o Added a new section describing the available mechanisms to 14129 determine if functionality is supported, called "Capability 14130 Handling". Renamed option-tags to feature-tags. 14132 o Added a contributors section with people who have contributed 14133 actual text to the specification. 14135 o Added a section Use Cases that describes the major use cases for 14136 RTSP. 14138 o Clarified the usage of a=range and how to indicate live content 14139 that are not seekable with this header. 14141 o Text specifying the special behavior of PLAY for live content. 14143 o Security features of RTSP have been clarified: 14145 * HTTP based authorization has been clarified requring both Basic 14146 and DIGEST support 14148 * TLS support mandated 14150 * IF one implements RTP then SRTP and defined MIKEY based key- 14151 exchange must be supported 14153 * Various minor mitigations discussed or resulted in protocol 14154 changes. 14156 Appendix J. Acknowledgements 14158 This memorandum defines RTSP version 2.0 which is a revision of the 14159 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 14160 The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert 14161 Lanphier. 14163 Both RTSP version 1.0 and RTSP version 2.0 borrow format and 14164 descriptions from HTTP/1.1. 14166 Robert Sparks and especially Elwyn Davies provided very valuable and 14167 detailed reviews in the IETF last call that greately improved the 14168 document and resolved many issues, especially regarding consistency. 14170 This document has benefited greatly from the comments of all those 14171 participating in the MMUSIC-WG. In addition to those already 14172 mentioned, the following individuals have contributed to this 14173 specification: 14175 Rahul Agarwal, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten 14176 Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen 14177 Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Spencer 14178 Dawkins, Kelly Djahandari, Martin Dunsmuir, Adrian Farrel, Stephen 14179 Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Grignon, 14180 Christian Groves, V. Guruprasad, Peter Haight, Mark Handley, Brad 14181 Hefta-Gaub, Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, 14182 Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders 14183 Klemets, Ruth Lang, Barry Leiba, Stephanie Leif, Jonathan Lennox, 14184 Eduardo F. Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob 14185 McCool, Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria 14186 Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, 14187 Pekka Pessi, Igor Plotnikov, Pete Resnick, Peter Saint-Andre, Holger 14188 Schmidt, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff 14189 Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, Geetha 14190 Srikantan, Scott Taylor, David Walker, Stephan Wenger, Dale R. 14191 Worley, and Byungjo Yoon , and especially to Flemming Andreasen. 14193 J.1. Contributors 14195 The following people have made written contributions that were 14196 included in the specification: 14198 o Tom Marshall contributed text on the usage of 3rr status codes. 14200 o Thomas Zheng contributed text on the usage of the Range in PLAY 14201 responses and proposed an earlier version of the PLAY_NOTIFY 14202 method. 14204 o Sean Sheedy contributed text on the timeout behavior of RTSP 14205 messages and connections, the 463 status code, and proposed an 14206 earlier version of the PLAY_NOTIFY method. 14208 o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY 14209 method. 14211 o Fredrik Lindholm contributed text about the RTSP security 14212 framework. 14214 o John Lazzaro contributed the text for RTP over Independent TCP. 14216 o Aravind Narasimhan contributed by rewriting Media Transport 14217 Alternatives (Appendix C) and editorial improvements on a number 14218 of places in the specification. 14220 o Torbjorn Einarsson has done some editorial improvements of the 14221 text. 14223 Appendix K. RFC Editor Consideration 14225 Please replace RFC XXXX with the RFC number this specification 14226 receives. 14228 Authors' Addresses 14230 Henning Schulzrinne 14231 Columbia University 14232 1214 Amsterdam Avenue 14233 New York, NY 10027 14234 USA 14236 Email: schulzrinne@cs.columbia.edu 14237 Anup Rao 14238 Cisco 14239 USA 14241 Email: anrao@cisco.com 14243 Rob Lanphier 14244 Seattle, WA 14245 USA 14247 Email: robla@robla.net 14249 Magnus Westerlund 14250 Ericsson AB 14251 Faeroegatan 6 14252 STOCKHOLM SE-164 80 14253 SWEDEN 14255 Email: magnus.westerlund@ericsson.com 14257 Martin Stiemerling 14258 NEC Laboratories Europe, NEC Europe Ltd. 14259 Kurfuersten-Anlage 36 14260 Heidelberg 69115 14261 Germany 14263 Phone: +49 (0) 6221 4342 113 14264 Email: mls.ietf@gmail.com 14265 URI: http://www.stiemerling.org