idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-38.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 (October 10, 2013) is 3851 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 5020, but not defined == Missing Reference: 'H15' is mentioned on line 9456, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 10081, 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-03 ** 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' == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-16 -- 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: April 13, 2014 R. Lanphier 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 October 10, 2013 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-38 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-level 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 April 13, 2014. 49 Copyright Notice 51 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 79 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 80 2.1. Presentation Description . . . . . . . . . . . . . . . . 13 81 2.2. Session Establishment . . . . . . . . . . . . . . . . . 14 82 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 15 83 2.4. Session Parameter Manipulations . . . . . . . . . . . . 17 84 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 18 85 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18 86 2.6. Session Maintenance and Termination . . . . . . . . . . 20 87 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21 88 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23 89 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23 90 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23 91 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27 92 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27 93 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27 94 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30 95 4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 30 96 4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . 30 97 4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 31 98 4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . 32 99 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 33 100 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . 33 101 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 34 102 4.7.1. Random Access and Seeking . . . . . . . . . . . . . 34 103 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . 35 104 4.7.3. Content Modifications . . . . . . . . . . . . . . . 35 105 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . 36 106 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . 36 107 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 37 108 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 37 109 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 38 110 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 38 111 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 39 112 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 40 113 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 114 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 42 115 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 44 116 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 46 117 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 46 118 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 46 119 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 50 120 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 51 121 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 51 122 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 52 123 9.3. Message Body Format Negotiation . . . . . . . . . . . . 53 125 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54 126 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 54 127 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 55 128 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 58 129 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 59 130 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 60 131 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 61 132 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 62 133 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 64 134 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 65 135 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 67 136 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 68 137 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 69 138 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 70 139 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 72 140 13.3.1. Changing Transport Parameters . . . . . . . . . . . 75 141 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 76 142 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 76 143 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 81 144 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 82 145 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 84 146 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 85 147 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 85 148 13.4.7. Playing Live with Recording . . . . . . . . . . . . 86 149 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 86 150 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 87 151 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 88 152 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 90 153 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 91 154 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 92 155 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 95 156 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 95 157 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 96 158 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 97 159 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 99 160 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 101 161 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 104 162 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 163 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 107 164 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 108 165 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 166 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 109 167 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 111 168 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 111 169 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 111 170 16.1.4. Rules for When to Use Message Body Tags and 171 Last-Modified Dates . . . . . . . . . . . . . . . . 113 172 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 115 174 16.2. Invalidation After Updates or Deletions . . . . . . . . 115 175 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 117 176 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 117 177 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 117 178 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 117 179 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 117 180 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 117 181 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 118 182 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 118 183 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 118 184 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 119 185 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 119 186 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 119 187 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 119 188 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 119 189 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 120 190 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 120 191 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 120 192 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 120 193 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 120 194 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 121 195 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 121 196 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 121 197 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 121 198 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 122 199 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 122 200 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 122 201 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 122 202 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 122 203 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 123 204 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 123 205 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 123 206 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 123 207 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 123 208 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 123 209 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 123 210 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 124 211 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 124 212 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 124 213 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 124 214 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 124 215 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 124 216 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 124 217 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 125 218 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 125 219 17.4.32. 470 Connection Authorization Required . . . . . . . 125 220 17.4.33. 471 Connection Credentials not accepted . . . . . . 125 221 17.4.34. 472 Failure to establish secure connection . . . . . 125 223 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 125 224 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 126 225 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 126 226 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 126 227 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 126 228 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 126 229 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 127 230 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 127 231 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 127 232 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 128 233 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 138 234 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 139 235 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 140 236 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 140 237 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 141 238 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 142 239 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 142 240 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 142 241 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 143 242 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 144 243 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 144 244 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 147 245 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 147 246 18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 148 247 18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 149 248 18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 149 249 18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 150 250 18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 150 251 18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 151 252 18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 152 253 18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 153 254 18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 154 255 18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 155 256 18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 156 257 18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 156 258 18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 156 259 18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 157 260 18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 158 261 18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 158 262 18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 160 263 18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 161 264 18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 161 265 18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 161 266 18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 162 267 18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 163 268 18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 163 269 18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 163 270 18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 164 271 18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 164 272 18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 165 273 18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 167 274 18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 168 275 18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 168 276 18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 169 277 18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 169 278 18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 171 279 18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 172 280 18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 174 281 18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 174 282 18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 176 283 18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 177 284 18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 177 285 18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 178 286 18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 178 287 18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 186 288 18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 186 289 18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 186 290 18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 187 291 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 188 292 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 188 293 19.1.1. Digest Authentication . . . . . . . . . . . . . . . 189 294 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 189 295 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 190 296 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 192 297 19.3.2. User approved TLS procedure . . . . . . . . . . . . 193 298 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 299 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 195 300 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 197 301 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 197 302 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 200 303 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 204 304 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 213 305 21. Security Considerations . . . . . . . . . . . . . . . . . . . 214 306 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 214 307 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 217 308 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 218 309 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 219 310 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 221 311 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 222 312 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 222 313 22.1.2. Registering New Feature-tags with IANA . . . . . . . 222 314 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 222 315 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 223 316 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 223 317 22.2.2. Registering New Methods with IANA . . . . . . . . . 223 318 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 223 320 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 224 321 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 224 322 22.3.2. Registering New Status Codes with IANA . . . . . . . 224 323 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 224 324 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 224 325 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 225 326 22.4.2. Registering New Headers with IANA . . . . . . . . . 225 327 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 225 328 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 227 329 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 227 330 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 227 331 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 228 332 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 228 333 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 229 334 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 229 335 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 229 336 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 229 337 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 229 338 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 230 339 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 230 340 22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 230 341 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 230 342 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 231 343 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 231 344 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 231 345 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 231 346 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 232 347 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 232 348 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 232 349 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 232 350 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 233 351 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 233 352 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 233 353 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 233 354 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 233 355 22.13. Transport Header Registries . . . . . . . . . . . . . . 234 356 22.13.1. Transport Protocol Identifier . . . . . . . . . . . 234 357 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 236 358 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 236 359 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 237 360 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 237 361 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 238 362 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 240 363 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 240 364 22.16. Media Type Registration for text/parameters . . . . . . 241 365 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 243 366 23.1. Normative References . . . . . . . . . . . . . . . . . . 243 367 23.2. Informative References . . . . . . . . . . . . . . . . . 246 369 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 249 370 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 249 371 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 253 372 A.3. Secured Media Session for on Demand Content . . . . . . 255 373 A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 258 374 A.5. Single Stream Container Files . . . . . . . . . . . . . 262 375 A.6. Live Media Presentation Using Multicast . . . . . . . . 264 376 A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 265 377 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 267 378 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 267 379 B.2. State variables . . . . . . . . . . . . . . . . . . . . 267 380 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 268 381 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 268 382 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 275 383 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 275 384 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 275 385 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 275 386 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 277 387 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 277 388 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 280 389 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 280 390 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 282 391 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 282 392 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 282 393 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 286 394 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 290 395 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 292 396 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 292 397 C.7. Maintaining NPT synchronization with RTP timestamps . . 292 398 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 292 399 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 292 400 C.10. Usage of SSRCs and the RTCP BYE Message During an 401 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 292 402 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 293 403 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 294 404 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 294 405 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 294 406 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 295 407 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 296 408 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 296 409 D.1.5. Directionality of media stream . . . . . . . . . . . 296 410 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 297 411 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 298 412 D.1.8. Connection Information . . . . . . . . . . . . . . . 298 413 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 299 414 D.2. Aggregate Control Not Available . . . . . . . . . . . . 299 415 D.3. Aggregate Control Available . . . . . . . . . . . . . . 300 416 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 301 417 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 301 418 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 302 419 E.1. On-demand Playback of Stored Content . . . . . . . . . . 302 420 E.2. Unicast Distribution of Live Content . . . . . . . . . . 303 421 E.3. On-demand Playback using Multicast . . . . . . . . . . . 304 422 E.4. Inviting an RTSP server into a conference . . . . . . . 304 423 E.5. Live Content using Multicast . . . . . . . . . . . . . . 305 424 Appendix F. Text format for Parameters . . . . . . . . . . . . . 307 425 Appendix G. Requirements for Unreliable Transport of RTSP . . . 308 426 Appendix H. Backwards Compatibility Considerations . . . . . . . 310 427 H.1. Play Request in Play State . . . . . . . . . . . . . . . 310 428 H.2. Using Persistent Connections . . . . . . . . . . . . . . 310 429 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 311 430 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 311 431 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 312 432 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 319 433 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 319 434 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 321 435 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 322 437 1. Introduction 439 This memo defines version 2.0 of the Real Time Streaming Protocol 440 (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and 441 control over the delivery of data with real-time properties, 442 typically streaming media. Streaming media is, for instance, video 443 on demand or audio live streaming. Put simply, RTSP acts as a 444 "network remote control" for multimedia servers, similar to the 445 remote control for a DVD player. 447 The protocol operates between RTSP 2.0 clients and servers, but also 448 supports the usage of proxies placed between clients and servers. 449 Clients can request information about streaming media from servers by 450 asking for a description of the media or use media description 451 provided externally. The media delivery protocol is used to 452 establish the media streams described by the media description. 453 Clients can then request to play out the media, pause it, or stop it 454 completely, as known from DVD players remote control or media 455 players. The requested media can consist of multiple audio and video 456 streams that are delivered as time-synchronized streams from servers 457 to clients. 459 RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that 460 specification. This protocol is based on RTSP 1.0 but is not 461 backwards compatible other than in the basic version negotiation 462 mechanism. The changes are documented in Appendix I. There are many 463 reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but 464 some of the main ones are: 466 o Most headers that needed to be extensible did not define the 467 allowed syntax, preventing safe deployment of extensions; 469 o The changed behavior of the PLAY method when received in Play 470 state; 472 o Changed behavior of the extensibility model and its mechanism; 474 o The change of syntax for some headers. 476 In summary, there are so many small details that changing version 477 became necessary to enable clarification and consistent behavior. 479 This document is structured as follows. It begins with an overview 480 of the protocol operations and its functions in an informal way. 481 Then a set of definitions of terms used and document conventions is 482 introduced. It is followed by the actual RTSP 2.0 core protocol 483 specification. The appendixes describe and define some 484 functionalities that are not part of the core RTSP specification, but 485 which are still important to enable some usages. Among them, the RTP 486 usage is defined in Appendix C, the Session Description Protocol 487 (SDP) usage with RTSP is defined in Appendix D, and the text/ 488 parameters file format Appendix F, are three normative specification 489 appendixes. Others include a number of informational parts 490 discussing the changes, use cases, different considerations or 491 motivations. 493 2. Protocol Overview 495 This section provides an informative overview of the different 496 mechanisms in the RTSP 2.0 protocol, to give the reader a high level 497 understanding before getting into all the different details. In case 498 of conflict with this description and the later sections, the later 499 sections take precedence. For more information about use cases 500 considered for RTSP see Appendix E. 502 RTSP 2.0 is a bi-directional request and response protocol that first 503 establishes a context including content resources (the media) and 504 then controls the delivery of these content resources from the 505 provider to the consumer. RTSP has three fundamental parts: Session 506 Establishment, Media Delivery Control, and an extensibility model 507 described below. The protocol is based on some assumptions about 508 existing functionality to provide a complete solution for client 509 controlled real-time media delivery. 511 RTSP uses text-based messages, requests and responses, that may 512 contain a binary message body. An RTSP request starts with a method 513 line that identifies the method, the protocol and version and the 514 resource to act on. The resource is identified by a URI and the 515 hostname part of the URI is used by RTSP client to resolve the IPv4 516 or IPv6 address of the RTSP server. Following the method line are a 517 number of RTSP headers. This part is ended by two consecutive 518 carriage return line feed (CRLF) character pairs. The message body 519 if present follows the two CRLF and the body's length is described by 520 a message header. RTSP responses are similar, but start with a 521 response line with the protocol and version, followed by a status 522 code and a reason phrase. RTSP messages are sent over a reliable 523 transport protocol between the client and server. RTSP 2.0 requires 524 clients and servers to implement TCP, and TLS over TCP, as mandatory 525 transports for RTSP messages. 527 2.1. Presentation Description 529 RTSP exists to provide access to multi-media presentations and 530 content, but tries to be agnostic about the media type or the actual 531 media delivery protocol that is used. To enable a client to 532 implement a complete system, an RTSP-external mechanism for 533 describing the presentation and the delivery protocol(s) is used. 534 RTSP assumes that this description is either delivered completely out 535 of band or as a data object in the response to a client's request 536 using the DESCRIBE method (Section 13.2). 538 Parameters that commonly have to be included in the Presentation 539 Description are the following: 541 o Number of media streams; 543 o The resource identifier for each media stream/resource that is to 544 be controlled by RTSP; 546 o The protocol that each media stream is to be delivered over; 548 o Transport protocol parameters that are not negotiated or vary with 549 each client; 551 o Media encoding information enabling a client to correctly decode 552 the media upon reception; 554 o An aggregate control resource identifier. 556 RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media 557 resources and aggregates under common control (See Section 4.2). 559 This specification describes in Appendix D how one uses SDP [RFC4566] 560 for Presentation Description 562 2.2. Session Establishment 564 The RTSP client can request the establishment of an RTSP session 565 after having used the presentation description to determine which 566 media streams are available, and also which media delivery protocol 567 is used and their particular resource identifiers. The RTSP session 568 is a common context between the client and the server that consists 569 of one or more media resources that are to be under common media 570 delivery control. 572 The client creates an RTSP session by sending a request using the 573 SETUP method (Section 13.3) to the server. In the SETUP request the 574 client also includes all the transport parameters necessary to enable 575 the media delivery protocol to function in the "Transport" header 576 (Section 18.54). This includes parameters that are pre-established 577 by the presentation description but necessary for any middlebox to 578 correctly handle the media delivery protocols. The Transport header 579 in a request may contain multiple alternatives for media delivery in 580 a prioritized list, which the server can select from. These 581 alternatives are typically based on information in the presentation 582 description. 584 The server determines if the media resource is available upon 585 receiving a SETUP request and if any of the transport parameter 586 specifications are acceptable. If that is successful, an RTSP 587 session context is created and the relevant parameters and state is 588 stored. An identifier is created for the RTSP session and included 589 in the response in the Session header (Section 18.49). The SETUP 590 response includes a Transport header that specifies which of the 591 alternatives has been selected and relevant parameters. 593 A SETUP request that references an existing RTSP session but 594 identifies a new media resource is a request to add that media 595 resource under common control with the already present media 596 resources in an aggregated session. A client can expect this to work 597 for all media resources under RTSP control within a multi-media 598 content. However, aggregating resources from different content are 599 likely to be refused by the server. The RTSP session as aggregate is 600 referenced by the aggregate control URI, even if the RTSP session 601 only contains a single media. 603 To avoid an extra round trip in the session establishment of 604 aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., 605 the client can send multiple requests back-to-back without waiting 606 first for the completion of any of them. The client uses a client- 607 selected identifier in the Pipelined-Requests header (Section 18.33) 608 to instruct the server to bind multiple requests together as if they 609 included the session identifier. 611 The SETUP response also provides additional information about the 612 established sessions in a couple of different headers. The Media- 613 Properties header (Section 18.29) includes a number of properties 614 that apply for the aggregate that is valuable when doing media 615 delivery control and configuring user interface. The Accept-Ranges 616 header (Section 18.5) informs the client about which range formats 617 that the server supports with these media resources. The Media-Range 618 header (Section 18.30) informs the client about the time range of the 619 media currently available. 621 2.3. Media Delivery Control 623 After having established an RTSP session, the client can start 624 controlling the media delivery. The basic operations are Start by 625 using the PLAY method (Section 13.4) and Halt by using the PAUSE 626 method (Section 13.6). PLAY also allows for choosing the starting 627 media position from which the server should deliver the media. The 628 positioning is done by using the Range header (Section 18.40) that 629 supports several different time formats: Normal Play Time (NPT) 630 (Section 4.4.2), Society of Motion Picture and Television Engineers 631 (SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3). 632 The Range header does further allow the client to specify a position 633 where delivery should end, thus allowing a specific interval to be 634 delivered. 636 The support for positioning/searching within a content depends on the 637 content's media properties. Content exists in a number of different 638 types, such as: on-demand, live, and live with simultaneous 639 recording. Even within these categories there are differences in how 640 the content is generated and distributed, which affect how it can be 641 accessed for playback. The properties applicable for the RTSP 642 session are provided by the server in the SETUP response using the 643 Media-Properties header (Section 18.29). These are expressed using 644 one or several independent attributes. A first attribute is Random 645 Access, which expresses if positioning can be done, and with what 646 granularity. Another aspect is whether the content will change 647 during the lifetime of the session. While on-demand content will be 648 provided in full from the beginning, a live stream being recorded 649 results in the length of the accessible content growing as the 650 session goes on. There also exists content that is dynamically built 651 by another protocol than RTSP and thus also changes in steps during 652 the session, but maybe not continuously. Furthermore, when content 653 is recorded, there are cases where not the complete content is 654 maintained, but, for example, only the last hour. All these 655 properties result in the need for mechanisms that will be discussed 656 below. 658 When the client accesses on-demand content that allows random access, 659 the client can issue the PLAY request for any point in the content 660 between the start and the end. The server will deliver media from 661 the closest random access point prior to the requested point and 662 indicate that in its PLAY response. If the client issues a PAUSE, 663 the delivery will be halted and the point at which the server stopped 664 will be reported back in the response. The client can later resume 665 by sending a PLAY request without a range header. When the server is 666 about to complete the PLAY request by delivering the end of the 667 content or the requested range, the server will send a PLAY_NOTIFY 668 request (Section 13.5) indicating this. 670 When playing live content with no extra functions, such as recording, 671 the client will receive the live media from the server after having 672 sent a PLAY request. Seeking in such content is not possible as the 673 server does not store it, but only forwards it from the source of the 674 session. Thus delivery continues until the client sends a PAUSE 675 request, tears down the session, or the content ends. 677 For live sessions that are being recorded the client will need to 678 keep track of how the recording progresses. Upon session 679 establishment the client will learn the current duration of the 680 recording from the Media-Range header. As the recording is ongoing 681 the content grows in direct relation to the passed time. Therefore, 682 each server's response to a PLAY request will contain the current 683 Media-Range header. The server should also regularly send 684 approximately every 5 minutes the current media range in a 685 PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, 686 the server must send a PLAY_NOTIFY request with the updated Media- 687 Properties indicating that the content stopped being a recorded live 688 session and instead became on-demand content; the request also 689 contains the final media range. While the live delivery continues 690 the client can request to play the current live point by using the 691 NPT timescale symbol "now", or it can request a specific point in the 692 available content by an explicit range request for that point. If 693 the requested point is outside of the available interval the server 694 will adjust the position to the closest available point, i.e., either 695 at the beginning or the end. 697 A special case of recording is that where the recording is not 698 retained longer than a specific time period, thus as the live 699 delivery continues the client can access any media within a moving 700 window that covers, for example, "now" to "now" minus 1 hour. A 701 client that pauses on a specific point within the content may not be 702 able to retrieve the content anymore. If the client waits too long 703 before resuming the pause point, the content may no longer be 704 available. In this case the pause point will be adjusted to the 705 closest point in the available media. 707 2.4. Session Parameter Manipulations 709 A session may have additional state or functionality that affects how 710 the server or client treats the session, content, how it functions, 711 or feedback on how well the session works. Such extensions are not 712 defined in this specification, but may be done in various extensions. 713 RTSP has two methods for retrieving and setting parameter values on 714 either the client or the server: GET_PARAMETER (Section 13.8) and 715 SET_PARAMETER (Section 13.9). These methods carry the parameters in 716 a message body of the appropriate format. One can also use headers 717 to query state with the GET_PARAMETER method. As an example, clients 718 needing to know the current media-range for a time-progressing 719 session can use the GET_PARAMETER method and include the media-range. 720 Furthermore, synchronization information can be requested by using a 721 combination of RTP-Info (Section 18.45) and Range (Section 18.40). 723 RTSP 2.0 does not have a strong mechanism for providing negotiation 724 of the headers, or parameters and their formats, that can be used. 725 However, responses will indicate request-headers or parameters that 726 are not supported. A priori determination of what features are 727 available needs to be done through out-of-band mechanisms, like the 728 session description, or through the usage of feature tags 729 (Section 4.5). 731 2.5. Media Delivery 733 The delivery of media to the RTSP client is done with a protocol 734 outside of RTSP and this protocol is determined during the session 735 establishment. This document specifies how media is delivered with 736 RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP 737 connection. Additional protocols may be specified in the future 738 based on demand. 740 The usage of RTP as media delivery protocol requires some additional 741 information to function well. The PLAY response contains information 742 to enable reliable and timely delivery of how a client should 743 synchronize different sources in the different RTP sessions. It also 744 provides a mapping between RTP timestamps and the content time scale. 745 When the server wants to notify the client about the completion of 746 the media delivery, it sends a PLAY_NOTIFY request to the client. 747 The PLAY_NOTIFY request includes information about the stream end, 748 including the last RTP sequence number for each stream, thus enabling 749 the client to empty the buffer smoothly. 751 2.5.1. Media Delivery Manipulations 753 The basic playback functionality of RTSP enables delivery of a range 754 of requested content to the client at the pace intended by the 755 content's creator. However, RTSP can also manipulate the delivery to 756 the client in two ways. 758 Scale: The ratio of media content time delivered per unit playback 759 time. 761 Speed: The ratio of playback time delivered per unit of wallclock 762 time. 764 Both affect the media delivery per time unit. However, they 765 manipulate two independent time scales and the effects are possible 766 to combine. 768 Scale (Section 18.46) is used for fast forward or slow motion control 769 as it changes the amount of content timescale that should be played 770 back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0 771 results in that 2 seconds of content is played back every second of 772 playback. Scale = 1.0 is the default value that is used if no Scale 773 is specified, i.e., playback at the content's original rate. Scale 774 values between 0 and 1.0 is providing for slow motion. Scale can be 775 negative to allow for reverse playback in either regular pace (Scale 776 = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards 777 (-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed. 779 In most cases the realization of scale means server side manipulation 780 of the media to ensure that the client can actually play it back. 781 The nature of these media manipulations and when they are needed is 782 highly media-type dependent. Let's consider an example with two 783 common media types audio and video. 785 It is very difficult to modify the playback rate of audio. A maximum 786 of 10-30% is possible by changing the pitch-rate of speech. Music 787 goes out of tune if one tries to manipulate the playback rate by 788 resampling it. This is a well known problem and audio is commonly 789 muted or played back in short segments with skips to keep up with the 790 current playback point. 792 For video it is possible to manipulate the frame rate, although the 793 rendering capabilities are often limited to certain frame rates. 794 Also the allowed bitrates in decoding, the structure used in the 795 encoding and the dependency between frames and other capabilities of 796 the rendering device limits the possible manipulations. Therefore, 797 the basic fast forward capabilities often are implemented by 798 selecting certain subsets of frames. 800 Due to the media restrictions, the possible scale values are commonly 801 restricted to the set of realizable scale ratios. To enable the 802 clients to select from the possible scale values, RTSP can signal the 803 supported Scale ratios for the content. To support aggregated or 804 dynamic content, where this may change during the ongoing session and 805 dependent on the location within the content, a mechanism for 806 updating the media properties and the scale factor currently in use, 807 exists. 809 Speed (Section 18.50) affects how much of the playback timeline is 810 delivered in a given wallclock period. The default is Speed = 1 811 which means to deliver at the same rate the media is consumed. Speed 812 > 1 means that the receiver will get content faster than it regularly 813 would consume it. Speed < 1 means that delivery is slower than the 814 regular media rate. Speed values of 0 or lower have no meaning and 815 are not allowed. This mechanism enables two general functionalities. 816 One is client side scale operations, i.e., the client receives all 817 the frames and makes the adjustment to the playback locally. The 818 second is delivery control for buffering of media. By specifying a 819 speed over 1.0 the client can build up the amount of playback time it 820 has present in its buffers to a level that is sufficient for its 821 needs. 823 A naive implementation of Speed would only affect the transmission 824 schedule of the media and has a clear impact on the needed bandwidth. 825 This would result in the data rate being proportional to the speed 826 factor. Speed = 1.5, i.e., 50% faster than normal delivery, would 827 result in a 50% increase in the data transport rate. If that can be 828 supported or not depends solely on the underlying network path. 829 Scale may also have some impact on the required bandwidth due to the 830 manipulation of the content in the new playback schedule. An example 831 is fast forward where only the independently decodable intra frames 832 are included in the media stream. This usage of solely intra frames 833 increases the data rate significantly compared to a normal sequence 834 with the same number of frames, where most frames are encoded using 835 prediction. 837 This potential increase of the data rate needs to be handled by the 838 media sender. The client has requested that the media will be 839 delivered in a specific way, which should be honored. However, the 840 media sender cannot ignore if the network path between the sender and 841 the receiver can't handle the resulting media stream. In that case 842 the media stream needs to be adapted to fit the available resources 843 of the path. This can result in a reduced media quality. 845 The need for bitrate adaptation becomes especially problematic in 846 connection with the Speed semantics. If the goal is to fill up the 847 buffer, the client may not want to do that at the cost of reduced 848 quality. If the client wants to make local playout changes then it 849 may actually require that the requested speed be honored. To resolve 850 this issue, Speed uses a range so that both cases can be supported. 851 The server is requested to use the highest possible speed value 852 within the range which is compatible with the available bandwidth. 853 As long as the server can maintain a speed value within the range it 854 shall not change the media quality, but instead modify the actual 855 delivery rate in response to available bandwidth and reflect this in 856 the Speed value in the response. However, if this is not possible, 857 the server should instead modify the media quality to respect the 858 lowest speed value and the available bandwidth. 860 This functionality enables the local scaling implementation to use a 861 tight range, or even a range where the lower bound equals the upper 862 bound, to identify that it requires the server to deliver the 863 requested amount of media time per delivery time independent of how 864 much it needs to adapt the media quality to fit within the available 865 path bandwidth. For buffer filling, it is suitable to use a range 866 with a reasonable span and with a lower bound at the nominal media 867 rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the 868 buffer, it can specify an upper bound that is below 1.0 to force the 869 server to deliver slower than the nominal media rate. 871 2.6. Session Maintenance and Termination 873 The session context that has been established is kept alive by having 874 the client show liveness. This is done in two main ways: 876 o Media transport protocol keep-alive. RTP Control Protocol (RTCP) 877 may be used when using RTP. 879 o Any RTSP request referencing the session context. 881 Section 10.5 discusses the methods for showing liveness in more 882 depth. If the client fails to show liveness for more than the 883 established session timeout value (normally 60 seconds), the server 884 may terminate the context. Other values may be selected by the 885 server through the inclusion of the timeout parameter in the session 886 header. 888 The session context is normally terminated by the client sending a 889 TEARDOWN request (Section 13.7) to the server referencing the 890 aggregated control URI. An individual media resource can be removed 891 from a session context by a TEARDOWN request referencing that 892 particular media resource. If all media resources are removed from a 893 session context, the session context is terminated. 895 A client may keep the session alive indefinitely if allowed by the 896 server; however, it is recommended to release the session context 897 when an extended period of time without media delivery activity has 898 passed. The client can re-establish the session context if required 899 later. What constitutes an extended period of time is dependent on 900 the server and its usage. It is recommended that the client 901 terminates the session before ten times the session timeout value has 902 passed. A server may terminate the session after one session timeout 903 period without any client activity beyond keep-alive. When a server 904 terminates the session context, it does that by sending a TEARDOWN 905 request indicating the reason. 907 A server can also request that the client tear down the session and 908 re-establish it at an alternative server, as may be needed for 909 maintenance. This is done by using the REDIRECT method 910 (Section 13.10). The Terminate-Reason header (Section 18.52) is used 911 to indicate when and why. The Location header indicates where it 912 should connect if there is an alternative server available. When the 913 deadline expires, the server simply stops providing the service. To 914 achieve a clean closure, the client needs to initiate session 915 termination prior to the deadline. In case the server has no other 916 server to redirect to, and wants to close the session for 917 maintenance, it shall use the TEARDOWN method with a Terminate-Reason 918 header. 920 2.7. Extending RTSP 922 RTSP is quite a versatile protocol which supports extensions in many 923 different directions. Even this core specification contains several 924 blocks of functionality that are optional to implement. The use case 925 and need for the protocol deployment should determine what parts are 926 implemented. Allowing for extensions makes it possible for RTSP to 927 reach out to additional use cases. However, extensions will affect 928 the interoperability of the protocol and therefore it is important 929 that they can be added in a structured way. 931 The client can learn the capability of a server by using the OPTIONS 932 method (Section 13.1) and the Supported header (Section 18.51). It 933 can also try and possibly fail using new methods, or require that 934 particular features are supported using the Require (Section 18.43) 935 or Proxy-Require (Section 18.37) header. 937 The RTSP protocol in itself can be extended in three ways, listed 938 here in increasing order of the magnitude of changes supported: 940 o Existing methods can be extended with new parameters, for example, 941 headers, as long as these parameters can be safely ignored by the 942 recipient. If the client needs negative acknowledgment when a 943 method extension is not supported, a tag corresponding to the 944 extension may be added in the field of the Require or Proxy- 945 Require headers. 947 o New methods can be added. If the recipient of the message does 948 not understand the request, it must respond with error code 501 949 (Not Implemented) so that the sender can avoid using this method 950 again. A client may also use the OPTIONS method to inquire about 951 methods supported by the server. The server must list the methods 952 it supports using the Public response-header. 954 o A new version of the protocol can be defined, allowing almost all 955 aspects (except the position of the protocol version number) to 956 change. A new version of the protocol must be registered through 957 an IETF standards track document. 959 The basic capability discovery mechanism can be used to both discover 960 support for a certain feature and to ensure that a feature is 961 available when performing a request. For a detailed explanation of 962 this see Section 11. 964 New media delivery protocols may be added and negotiated at session 965 establishment, in addition to extensions to the core protocol. 966 Certain types of protocol manipulations can be done through parameter 967 formats using SET_PARAMETER and GET_PARAMETER. 969 3. Document Conventions 971 3.1. Notational Conventions 973 Since a few of the definitions are identical to HTTP/1.1, this 974 specification only points to the section where they are defined 975 rather than copying it. For brevity, [HX.Y] is to be taken to refer 976 to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). 978 All the mechanisms specified in this document are described in both 979 prose and the Augmented Backus-Naur form (ABNF) described in detail 980 in [RFC5234]. 982 Indented paragraphs are used to provide informative background and 983 motivation. This is intended to give readers who were not involved 984 with the formulation of the specification an understanding of why 985 things are the way they are in RTSP. 987 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 988 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 989 "OPTIONAL" in this document are to be interpreted as described in 990 [RFC2119]. 992 The word, "unspecified" is used to indicate functionality or features 993 that are not defined in this specification. Such functionality 994 cannot be used in a standardized manner without further definition in 995 an extension specification to RTSP. 997 3.2. Terminology 999 Aggregate control: The concept of controlling multiple streams using 1000 a single timeline, generally maintained by the server. A client, 1001 for example, uses aggregate control when it issues a single play 1002 or pause message to simultaneously control both the audio and 1003 video in a movie. A session which is under aggregate control is 1004 referred to as an aggregated session. 1006 Aggregate control URI: The URI used in an RTSP request to refer to 1007 and control an aggregated session. It normally, but not always, 1008 corresponds to the presentation URI specified in the session 1009 description. See Section 13.3 for more information. 1011 Client: The client requests media service from the media server. 1013 Connection: A transport layer virtual circuit established between 1014 two programs for the purpose of communication. 1016 Container file: A file which may contain multiple media streams 1017 which often constitutes a presentation when played together. The 1018 concept of a container file is not embedded in the protocol. 1019 However, RTSP servers may offer aggregate control on the media 1020 streams within these files. 1022 Continuous media: Data where there is a timing relationship between 1023 source and sink; that is, the sink needs to reproduce the timing 1024 relationship that existed at the source. The most common examples 1025 of continuous media are audio and motion video. Continuous media 1026 can be real-time (interactive or conversational), where there is a 1027 "tight" timing relationship between source and sink, or streaming 1028 where the relationship is less strict. 1030 Feature-tag: A tag representing a certain set of functionality, 1031 i.e., a feature. 1033 IRI: Internationalized Resource Identifier, is the same as a URI, 1034 with the exception that it allows characters from the whole 1035 Universal Character Set (Unicode/ISO 10646), rather than the US- 1036 ASCII only. See [RFC3987] for more information. 1038 Live: Normally used to describe a presentation or session with media 1039 coming from an ongoing event. This generally results in the 1040 session having an unbound or only loosely defined duration, and 1041 sometimes no seek operations are possible. 1043 Media initialization: Datatype/codec specific initialization. This 1044 includes such things as clock rates, color tables, etc. Any 1045 transport-independent information which is required by a client 1046 for playback of a media stream occurs in the media initialization 1047 phase of stream setup. 1049 Media parameter: Parameter specific to a media type that may be 1050 changed before or during stream delivery. 1052 Media server: The server providing media delivery services for one 1053 or more media streams. Different media streams within a 1054 presentation may originate from different media servers. A media 1055 server may reside on the same host or on a different host from 1056 which the presentation is invoked. 1058 (Media) stream: A single media instance, e.g., an audio stream or a 1059 video stream as well as a single whiteboard or shared application 1060 group. When using RTP, a stream consists of all RTP and RTCP 1061 packets created by a source within an RTP session. 1063 Message: The basic unit of RTSP communication, consisting of a 1064 structured sequence of octets matching the syntax defined in 1065 Section 20 and transmitted over a connection-based transport. A 1066 message is either a Request or a Response. 1068 Message Body: The information transferred as the payload of a 1069 message (Request or response). A message body consists of meta- 1070 information in the form of message-body headers and content in the 1071 form of a message-body, as described in Section 9. 1073 Non-Aggregated Control: Control of a single media stream. 1075 Presentation: A set of one or more streams presented to the client 1076 as a complete media feed and described by a presentation 1077 description as defined below. Presentations with more than one 1078 media stream are often handled in RTSP under aggregate control. 1080 Presentation description: A presentation description contains 1081 information about one or more media streams within a presentation, 1082 such as the set of encodings, network addresses and information 1083 about the content. Other IETF protocols such as SDP ([RFC4566]) 1084 use the term "session" for a presentation. The presentation 1085 description may take several different formats, including but not 1086 limited to the session description protocol format, SDP. 1088 Response: An RTSP response to a Request. One type of RTSP message. 1089 If an HTTP response is meant, it is indicated explicitly. 1091 Request: An RTSP request. One type of RTSP message. If an HTTP 1092 request is meant, it is indicated explicitly. 1094 Request-URI: The URI used in a request to indicate the resource on 1095 which the request is to be performed. 1097 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 1098 RTSP proxy. In this specification, there are many capabilities 1099 that are common to these three entities such as the capability to 1100 send requests or receive responses. This term will be used when 1101 describing functionality that is applicable to all three of these 1102 entities. 1104 RTSP session: A stateful abstraction upon which the main control 1105 methods of RTSP operate. An RTSP session is a common context; it 1106 is created and maintained on client's request and can be destroyed 1107 by either the client or server. It is established by an RTSP 1108 server upon the completion of a successful SETUP request (when a 1109 200 OK response is sent) and is labeled with a session identifier 1110 at that time. The session exists until timed out by the server or 1111 explicitly removed by a TEARDOWN request. An RTSP session is a 1112 stateful entity; an RTSP server maintains an explicit session 1113 state machine (see Appendix B) where most state transitions are 1114 triggered by client requests. The existence of a session implies 1115 the existence of state about the session's media streams and their 1116 respective transport mechanisms. A given session can have one or 1117 more media streams associated with it. An RTSP server uses the 1118 session to aggregate control over multiple media streams. 1120 Origin Server: The server on which a given resource resides. 1122 Transport initialization: The negotiation of transport information 1123 (e.g., port numbers, transport protocols) between the client and 1124 the server. 1126 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 1127 RTSP are generally URLs as they give a location for the resource. 1128 As URLs are a subset of URIs, they will be referred to as URIs to 1129 cover also the cases when an RTSP URI would not be an URL. 1131 URL: Universal Resource Locator, is a URI which identifies the 1132 resource through its primary access mechanism, rather than 1133 identifying the resource by name or by some other attribute(s) of 1134 that resource. 1136 4. Protocol Parameters 1138 4.1. RTSP Version 1140 This specification defines version 2.0 of RTSP. 1142 RTSP uses a "." numbering scheme to indicate versions 1143 of the protocol. The protocol versioning policy is intended to allow 1144 the sender to indicate the format of a message and its capacity for 1145 understanding further RTSP communication, rather than the features 1146 obtained via that communication. No change is made to the version 1147 number for the addition of message components which do not affect 1148 communication behavior or which only add to extensible field values. 1150 The number is incremented when the changes made to the 1151 protocol add features which do not change the general message parsing 1152 algorithm, but which may add to the message semantics and imply 1153 additional capabilities of the sender. The number is 1154 incremented when the format of a message within the protocol is 1155 changed. The version of an RTSP message is indicated by an RTSP- 1156 Version field in the first line of the message. Note that the major 1157 and minor numbers MUST be treated as separate integers and that each 1158 MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a 1159 lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. 1160 Leading zeros SHALL NOT be sent and MUST be ignored by recipients. 1162 4.2. RTSP IRI and URI 1164 RTSP 2.0 defines and registers or updates three URI schemes "rtsp", 1165 "rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified 1166 in RTSP 2.0, and is defined here to register the URI scheme that was 1167 defined in RTSP 1.0. The "rtspu" scheme indicates unspecified 1168 transport of the RTSP messages over unreliable transport (UDP in RTSP 1169 1.0). An RTSP server MUST respond with an error code indicating the 1170 "rtspu" scheme is not implemented (501) to a request that carries a 1171 "rtspu" URI scheme. 1173 The details of the syntax of "rtsp" and "rtsps" URIs has been changed 1174 from RTSP 1.0. These changes are: 1176 o Support for IPV6 literal in host part and future IP literals 1177 through RFC 3986 defined mechanism. 1179 o A new relative format to use in the RTSP protocol elements that is 1180 not required to start with "/". 1182 Neither should have any significant impact on interoperability. If 1183 one is required to use IPv6 literals to reach an RTSP server, then 1184 that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully 1185 IPv6 capable protocol. If an RTSP 1.0 client attempts to process the 1186 URI it will not match the allowed syntax and be considered invalid 1187 and processing will be stopped. This is clearly a failure to reach 1188 the resource, however it is not a signification issue as RTSP 2.0 1189 support was needed anyway in both server and client. Thus failure 1190 will only occur in a later step when there is a RTSP version mismatch 1191 between client and server. The second change will only occur inside 1192 RTSP message headers, as the request URI must be an absolute URI. 1193 Thus such usages will only occur after an agent has accepted and 1194 started processing RTSP 2.0 messages, and an RTSP 1.0 only agent will 1195 not be required to parse such types of relative URIs. 1197 This specification also defines the format of the RTSP IRI [RFC3987] 1198 that can be used as RTSP resource identifiers and locators, in web 1199 pages, user interfaces, on paper, etc. However, the RTSP request 1200 message format only allows usage of the absolute URI format. The 1201 RTSP IRI format MUST use the rules and transformation for IRIs to 1202 URIs, as defined in [RFC3987]. This allows a URI that matches the 1203 RTSP 2.0 specification, and so is suitable for use in a request, to 1204 be created from an RTSP IRI. 1206 The RTSP IRI and URI are both syntax restricted compared to the 1207 generic syntax defined in [RFC3986] and [RFC3987]: 1209 o An absolute URI requires the authority part; i.e., a host identity 1210 MUST be provided. 1212 o Parameters in the path element are prefixed with the reserved 1213 separator ";". 1215 The RTSP URI and IRI are case sensitive, with the exception of those 1216 parts that [RFC3986] and [RFC3987] define as case-insensitive; for 1217 example, the scheme and host part. 1219 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1220 [RFC3986], i.e., the fragment is to be stripped from the IRI by the 1221 requester and not included in the request URI. The user agent needs 1222 to interpret the value of the fragment based on the media type the 1223 request relates to; i.e., the media type indicated in Content-Type 1224 header in the response to DESCRIBE. 1226 The syntax of any URI query string is unspecified and responder 1227 (usually the server) specific. The query is, from the requester's 1228 perspective, an opaque string and needs to be handled as such. 1229 Please note that relative URI with queries are difficult to handle 1230 due to the RFC 3986 relative URI handling rules. Any change of the 1231 path element using a relative URI results in the stripping of the 1232 query, which means the relative part needs to contain the query. 1234 The URI scheme "rtsp" requires that commands are issued via a 1235 reliable protocol (within the Internet, TCP), while the scheme 1236 "rtsps" identifies a reliable transport using secure transport (TLS 1237 [RFC5246], see (Section 19). 1239 For the scheme "rtsp", if no port number is provided in the authority 1240 part of the URI, the port number 554 MUST be used. For the scheme 1241 "rtsps", if no port number is provided in the authority part of the 1242 URI port number, the TCP port 322 MUST be used. 1244 A presentation or a stream is identified by a textual media 1245 identifier, using the character set and escape conventions of URIs 1246 [RFC3986]. URIs may refer to a stream or an aggregate of streams; 1247 i.e., a presentation. Accordingly, requests described in 1248 (Section 13) can apply to either the whole presentation or an 1249 individual stream within the presentation. Note that some request 1250 methods can only be applied to streams, not presentations, and vice 1251 versa. 1253 For example, the RTSP URI: 1255 rtsp://media.example.com:554/twister/audiotrack 1257 may identify the audio stream within the presentation "twister", 1258 which can be controlled via RTSP requests issued over a TCP 1259 connection to port 554 of host media.example.com. 1261 Also, the RTSP URI: 1263 rtsp://media.example.com:554/twister 1265 identifies the presentation "twister", which may be composed of audio 1266 and video streams, but could also be something else like a random 1267 media redirector. 1269 This does not imply a standard way to reference streams in URIs. 1270 The presentation description defines the hierarchical 1271 relationships in the presentation and the URIs for the individual 1272 streams. A presentation description may name a stream "a.mov" and 1273 the whole presentation "b.mov". 1275 The path components of the RTSP URI are opaque to the client and do 1276 not imply any particular file system structure for the server. 1278 This decoupling also allows presentation descriptions to be used 1279 with non-RTSP media control protocols simply by replacing the 1280 scheme in the URI. 1282 4.3. Session Identifiers 1284 Session identifiers are strings of length 8-128 characters. A 1285 session identifier MUST be chosen cryptographically random (see 1286 [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, 1287 i.e., approximately 22 characters from a high quality generator (see 1288 Section 21). However, note that the session identifier does not 1289 provide any security against session hijacking unless it is kept 1290 confidential by the client, server and trusted proxies. 1292 4.4. Media Time Formats 1294 RTSP currently supports three different media time formats defined 1295 below. Additional time formats may be specified in the future. 1296 These time formats can be used with the Range header (Section 18.40) 1297 to request playback and specify at which media position protocol 1298 requests actually will or have taken place. They are also used in 1299 description of the media's properties using the Media-Range header 1300 (Section 18.30). The unqualified format identifier is used on its 1301 own in Accept-Ranges header (Section 18.5) to declare supported time 1302 formats and also in the Range header (Section 18.40) to request the 1303 time format used in the response. 1305 4.4.1. SMPTE Relative Timestamps 1307 A Society of Motion Picture and Television Engineers (SMPTE) relative 1308 timestamp expresses time relative to the start of the clip. Relative 1309 timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame- 1310 level access accuracy. The time code has the format 1312 hours:minutes:seconds:frames.subframes, 1314 with the origin at the start of the clip. The default SMPTE format 1315 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1316 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1317 through the use of "smpte-type". For SMPTE 30, the "frames" field in 1318 the time value can assume the values 0 through 29. The difference 1319 between 30 and 29.97 frames per second is handled by dropping the 1320 first two frame indices (values 00 and 01) of every minute, except 1321 every tenth minute. If the frame and the subframe values are zero, 1322 they may be omitted. Subframes are measured in one-hundredth of a 1323 frame. 1325 Examples: 1327 smpte=10:12:33:20- 1328 smpte=10:07:33- 1329 smpte=10:07:00-10:07:33:05.01 1330 smpte-25=10:07:00-10:07:33:05.01 1332 4.4.2. Normal Play Time 1334 Normal play time (NPT) indicates the stream absolute position 1335 relative to the beginning of the presentation. The timestamp 1336 consists of two parts: the mandatory first part may be expressed in 1337 either seconds or hours, minutes, and seconds. The optional second 1338 part consists of a decimal point and decimal figures and indicates 1339 fractions of a second. 1341 The beginning of a presentation corresponds to 0.0 seconds. Negative 1342 values are not defined. 1344 The special constant "now" is defined as the current instant of a 1345 live event. It MAY only be used for live events, and MUST NOT be 1346 used for on-demand (i.e., non-live) content. 1348 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1349 the clock the viewer associates with a program. It is often 1350 digitally displayed on a VCR. NPT advances normally when in normal 1351 play mode (scale = 1), advances at a faster rate when in fast scan 1352 forward (high positive scale ratio), decrements when in scan reverse 1353 (negative scale ratio) and is fixed in pause mode. NPT is 1354 (logically) equivalent to SMPTE time codes." 1356 Examples: 1358 npt=123.45-125 1359 npt=12:05:35.3- 1360 npt=now- 1362 The syntax is based on ISO 8601 [ISO.8601.2000]. Two different 1363 notations are allowed. The npt-hhmmss notation are using a ISO 8601 1364 extended complete representation of the time of the day format 1365 (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators 1366 between hours, minutes and seconds (hh:mm:ss). With the exception 1367 that it expresses duration since presentation start rather than time 1368 since midnight and the hour counter is not limited to 0-24 hours, 1369 instead up to nineteen (19) digits of hours are allowed. ISO 8601 1370 time format requires all digits to be used for each format, and all 1371 format required needs to be included, e.g. if one use a hh:mm:ss 1372 format, then that requires two digits for hours, two digits for 1373 minutes and two digits for second, a time value such as 7 minutes and 1374 0 seconds, is expressed as 00:07:00. The npt-sec notation is 1375 expressing the duration since presentation start in seconds, using 1376 one to nineteen (19) digits. Both notations allows decimal fractions 1377 of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with 1378 the limitation of at maximum of 9 digits and only allowing "." (full 1379 stop) as separator. Due to RTSP 1.0 and the fact that the highest 1380 values are expanded beyond two digits, all implementations MUST allow 1381 the highest value to be single digit and SHALL NOT send leading zeros 1382 for hours in the npt-hhmmss notation and leading zeros for seconds in 1383 the npt-sec notation. The hours and the seconds in the npt-hhmmss 1384 notation SHALL be sent using leading zeros, but receivers SHALL 1385 accept values without leading zeros. 1387 The npt-sec notation is optimized for automatic generation, the npt- 1388 hhmmss notation for consumption by human readers. The "now" constant 1389 allows clients to request to receive the live feed rather than the 1390 stored or time-delayed version. This is needed since neither 1391 absolute time nor zero time are appropriate for this case. 1393 4.4.3. Absolute Time 1395 Absolute time is expressed following a specific types of ISO 8601 1396 [ISO.8601.2000] based timestamps. The date is complete 1397 representation calendar date in basic format (YYYYMMDD) without 1398 separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day 1399 is provided in the complete representation basic format (hhmmss) as 1400 specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal 1401 fractions of seconds following Section 5.3.1.3 requiring "." (full 1402 stop) as decimal separator and limiting the number of digits to no 1403 more than nine (9). The time expressed MUST be using UTC (GMT), i.e. 1404 no timezone offsets allowed. The full date and time specification is 1405 the eight digit date followed by a "T" followed by the six digits 1406 time value, optionally followed by a full stop followed by one to 1407 nine fractions of a second and ended by "Z", e.g. 1408 YYYYMMDDThhmmss.ssZ. 1410 The reason for this time format rather than using "Date and Time 1411 on the Internet: Timestamps" [RFC3339] are historic and using the 1412 format specified in RTSP 1.0. The motivations raised in RFC 3339 1413 applies to why a selection from ISO 8601 was done, but a different 1414 and even more restrictive selection was applied in this case. 1416 Example for clock format range request for a starting time of 1417 November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC 1418 playing for 10 min and 5 seconds, a Media-Properties header's "Time- 1419 Limited UTC property for 24th of December 2014 at 15 hours and 00 1420 mins, and a Terminate-Readon headers "time" property for 18th of June 1421 2013 at 16 hours, 12 minutes and 56 seconds: 1423 clock=19961108T143720.25Z-19961108T144725.25Z 1424 Time-Limited=20141224T1500Z 1425 time=20130618T161256Z 1427 4.5. Feature-Tags 1429 Feature-tags are unique identifiers used to designate features in 1430 RTSP. These tags are used in Require (Section 18.43), Proxy-Require 1431 (Section 18.37), Proxy-Supported (Section 18.38), Supported 1432 (Section 18.51) and Unsupported (Section 18.55) header fields. 1434 A feature-tag definition MUST indicate which combination of clients, 1435 servers or proxies it applies to. 1437 The creator of a new RTSP feature-tag should either prefix the 1438 feature-tag with a reverse domain name (e.g., 1439 "com.example.mynewfeature" is an apt name for a feature whose 1440 inventor can be reached at "example.com"), or register the new 1441 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1442 IANA Section 22). 1444 The usage of feature-tags is further described in Section 11 that 1445 deals with capability handling. 1447 4.6. Message Body Tags 1449 Message body tags are opaque strings that are used to compare two 1450 message bodies from the same resource, for example in caches or to 1451 optimize setup after a redirect. Message body tags can be carried in 1452 the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9). 1453 MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]). 1455 A message body tag MUST be unique across all versions of all message 1456 bodies associated with a particular resource. A given message body 1457 tag value MAY be used for message bodies obtained by requests on 1458 different URIs. The use of the same message body tag value in 1459 conjunction with message bodies obtained by requests on different 1460 URIs does not imply the equivalence of those message bodies 1462 Message body tags are used in RTSP to make some methods conditional. 1463 The methods are made conditional through the inclusion of headers; 1464 see "If-Match" (Section 18.24) and "If-None-Match" (Section 18.26). 1465 Note that RTSP message body tags apply to the complete presentation; 1466 i.e., both the presentation description and the individual media 1467 streams. Thus message body tags can be used to verify at setup time 1468 after a redirect that the same session description applies to the 1469 media at the new location using the If-Match header. 1471 4.7. Media Properties 1473 When an RTSP server handles media, it is important to consider the 1474 different properties a media instance for delivery and playback can 1475 have. This specification considers the media properties listed below 1476 in its protocol operations. They are derived from the differences 1477 between a number of supported usages. 1479 On-demand: Media that has a fixed (given) duration that doesn't 1480 change during the life time of the RTSP session and is known at 1481 the time of the creation of the session. It is expected that the 1482 content of the media will not change, even if the representation, 1483 i.e., encoding, quality, etc, may change. Generally one can seek, 1484 i.e., request any range, within the media. 1486 Dynamic On-demand: This is a variation of the on-demand case where 1487 external methods are used to manipulate the actual content of the 1488 media setup for the RTSP session. The main example is a content 1489 defined by a playlist. 1491 Live: Live media represents a progressing content stream (such as 1492 broadcast TV) where the duration may or may not be known. It is 1493 not seekable, only the content presently being delivered can be 1494 accessed. 1496 Live with Recording: A Live stream that is combined with a server- 1497 side capability to store and retain the content of the live 1498 session, and allow for random access delivery within the part of 1499 the already recorded content. The actual behavior of the media 1500 stream is very much dependent on the retention policy for the 1501 media stream; either the server will be able to capture the 1502 complete media stream, or it will have a limitation in how much 1503 will be retained. The media range will dynamically change as the 1504 session progress. For servers with a limited amount of storage 1505 available for recording, there will typically be a sliding window 1506 that moves forward while new data is made available and older data 1507 is discarded. 1509 To cover the above usages, the following media properties with 1510 appropriate values are specified: 1512 4.7.1. Random Access and Seeking 1514 Random Access is the ability to specify and get media delivered 1515 starting from any time instant within the content, an operation 1516 called seeking. The Media-Properties header will indicate the 1517 general capability for a media resource to perform random access: 1519 Random-Access: The media is seekable to any out of a large number of 1520 points within the media. Due to media encoding limitations, a 1521 particular point may not be reachable, but seeking to a point 1522 close by is enabled. A floating point number of seconds may be 1523 provided to express the worst case distance between random access 1524 points. 1526 Beginning-Only: Seeking is only possible to the beginning of the 1527 content. 1529 No-seeking: Seeking is not possible at all. 1531 If random access is possible, as indicated by the Media-Properties 1532 header, the actual behavior policy when seeking can be controlled 1533 using the Seek-Style header (Section 18.47). 1535 4.7.2. Retention 1537 Media may have different retention policies in place that affect the 1538 operation on media. The following different media retention policies 1539 are envisioned and taken into consideration where applicable: 1541 Unlimited: The media will not be removed as long as the RTSP session 1542 is in existence. 1544 Time-Limited: The media will not be removed before the given 1545 wallclock time. After that time it may or may not be available 1546 any more. 1548 Time-Duration: Each individual unit of the media will be retained 1549 for the specified duration. 1551 4.7.3. Content Modifications 1553 There is also the question of how the content may change over time 1554 for a given media resource: 1556 Immutable: The content of the media will not change, even if the 1557 representation, i.e., encoding, quality, etc., may change. 1559 Dynamic: Between explicit updates the media content will not change, 1560 but the content may change due to external methods or triggers, 1561 such as playlists. 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". It may be updated at 1578 any point in the content due to content consisting of spliced pieces 1579 or content being dynamically updated by out-of-band mechanisms. 1581 4.7.5. Mapping to the Attributes 1583 This section shows examples of how one would map the above usages to 1584 the properties and their values. 1586 On-demand: Random Access: Random-Access=5.0, Content Modifications: 1587 Immutable, Retention: Unlimited or Time-Limited. 1589 Dynamic On-demand: Random Access: Random-Access=3.0, Content 1590 Modifications: Dynamic, Retention: Unlimited or Time-Limited. 1592 Live: Random Access: No-seeking, Content Modifications: Time- 1593 Progressing, Retention: Time-Duration=0.0 1595 Live with Recording: Random Access: Random-Access=3.0, Content 1596 Modifications: Time-Progressing, Retention: Time-Duration=7200.0 1598 5. RTSP Message 1600 RTSP is a text-based protocol and uses the ISO 10646 character set in 1601 UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. 1603 Text-based protocols make it easier to add optional parameters in 1604 a self-describing manner. Since the number of parameters and the 1605 frequency of commands is low, processing efficiency is not a 1606 concern. Text-based protocols, if done carefully, also allow easy 1607 implementation of research prototypes in scripting languages such 1608 as TCL, Visual Basic and Perl. 1610 The ISO 10646 character set avoids character set switching, but is 1611 invisible to the application as long as US-ASCII is being used. This 1612 is also the encoding used for RTCP [RFC3550]. 1614 Requests contain methods, the object the method is operating upon and 1615 parameters to further describe the method. Methods are idempotent 1616 unless otherwise noted. Methods are also designed to require little 1617 or no state maintenance at the media server. 1619 5.1. Message Types 1621 RTSP messages consist of requests from client to server, or server to 1622 client, and responses in the reverse direction. Request (Section 7) 1623 and Response (Section 8) messages use a format based on the generic 1624 message format of RFC 5322 [RFC5322] for transferring bodies (the 1625 payload of the message). Both types of messages consist of a start- 1626 line, zero or more header fields (also known as "headers"), an empty 1627 line (i.e., a line with nothing preceding the CRLF) indicating the 1628 end of the headers, and possibly the data of the message body. The 1629 below ABNF [RFC5234] is for information and the formal message 1630 specification is present in Section 20.2.2. 1632 generic-message = start-line 1633 *(rtsp-header CRLF) 1634 CRLF 1635 [ message-body-data ] 1636 start-line = Request-Line | Status-Line 1638 In the interest of robustness, agents MUST ignore any empty line(s) 1639 received where a Request-Line or Response-Line is expected. In other 1640 words, if the agent is reading the protocol stream at the beginning 1641 of a message and receives a CRLF first, it MUST ignore the CRLF. 1643 5.2. Message Headers 1645 RTSP header fields (see Section 18) include general-header, request- 1646 header, response-header, and message-body header fields. 1648 The order in which header fields with differing field names are 1649 received is not significant. However, it is "good practice" to send 1650 general-header fields first, followed by request-header or response- 1651 header fields, and ending with the Message-body header fields. 1653 Multiple header fields with the same field-name MAY be present in a 1654 message if and only if the entire field-value for that header field 1655 is defined as a comma-separated list. It MUST be possible to combine 1656 the multiple header fields into one "field-name: field-value" pair, 1657 without changing the semantics of the message, by appending each 1658 subsequent field-value to the first, each separated by a comma. The 1659 order in which header fields with the same field-name are received is 1660 therefore significant to the interpretation of the combined field 1661 value, and thus a proxy MUST NOT change the order of these field 1662 values when a message is forwarded. 1664 Unknown message headers MUST be ignored (skipping over the header to 1665 the next protocol element, and not causing an error) by a RTSP server 1666 or client. An RTSP Proxy MUST forward unknown message headers. 1667 Message headers defined outside of this specification that are 1668 required to be interpreted by the RTSP agent will need to use feature 1669 tags (Section 4.5) and include them in the appropriate Require 1670 (Section 18.43) or Proxy-Require (Section 18.37) header. 1672 5.3. Message Body 1674 The message body (if any) of an RTSP message is used to carry further 1675 information for a particular resource associated with the request or 1676 response. An example of a message body is a Session Description 1677 Protocol (SDP) message. 1679 The presence of a message body in either a request or a response MUST 1680 be signaled by the inclusion of a Content-Length header (see 1681 Section 18.17) and Content-Type (see Section 18.19). A message body 1682 MUST NOT be included in a request or response if the specification of 1683 the particular method (see Method Definitions (Section 13)) does not 1684 allow sending a message body. In case a message body is received in 1685 a message when not expected the message body data SHOULD be 1686 discarded. This is to allow future extensions to define optional use 1687 of a message body. 1689 5.4. Message Length 1691 An RTSP Message that does not contain any message body is terminated 1692 by the first empty line after the header fields (Note: An empty line 1693 is a line with nothing preceding the CRLF.). In RTSP messages that 1694 contain message bodies the empty line is followed by the message 1695 body. The length of that body is determined by the value of the 1696 Content-Length header (Section 18.17). The value in the header 1697 represents the length of the message-body in octets. If this header 1698 field is not present, a value of zero is assumed, i.e., no message 1699 body present in the message. Unlike an HTTP message, an RTSP message 1700 MUST contain a Content-Length header whenever it contains a message 1701 body. Note that RTSP does not support the HTTP/1.1 "chunked" 1702 transfer coding (see [H3.6.1]). 1704 Given the moderate length of presentation descriptions returned, 1705 the server should always be able to determine its length, even if 1706 it is generated dynamically, making the chunked transfer encoding 1707 unnecessary. 1709 6. General Header Fields 1711 General headers are headers that may be used in both requests and 1712 responses. The general-headers are listed in Table 1: 1714 +--------------------+--------------------+ 1715 | Header Name | Defined in Section | 1716 +--------------------+--------------------+ 1717 | Accept-Ranges | Section 18.5 | 1718 | | | 1719 | Cache-Control | Section 18.11 | 1720 | | | 1721 | Connection | Section 18.12 | 1722 | | | 1723 | CSeq | Section 18.20 | 1724 | | | 1725 | Date | Section 18.21 | 1726 | | | 1727 | Media-Properties | Section 18.29 | 1728 | | | 1729 | Media-Range | Section 18.30 | 1730 | | | 1731 | Pipelined-Requests | Section 18.33 | 1732 | | | 1733 | Proxy-Supported | Section 18.38 | 1734 | | | 1735 | Range | Section 18.40 | 1736 | | | 1737 | RTP-Info | Section 18.45 | 1738 | | | 1739 | Scale | Section 18.46 | 1740 | | | 1741 | Seek-Style | Section 18.47 | 1742 | | | 1743 | Server | Section 18.48 | 1744 | | | 1745 | Session | Section 18.49 | 1746 | | | 1747 | Speed | Section 18.50 | 1748 | | | 1749 | Supported | Section 18.51 | 1750 | | | 1751 | Timestamp | Section 18.53 | 1752 | | | 1753 | Transport | Section 18.54 | 1754 | | | 1755 | User-Agent | Section 18.56 | 1756 | | | 1757 | Via | Section 18.57 | 1758 +--------------------+--------------------+ 1760 Table 1: The general headers used in RTSP 1762 7. Request 1764 A request message uses the format outlined below regardless of the 1765 direction of a request, client to server or server to client: 1767 o Request line, containing the method to be applied to the resource, 1768 the identifier of the resource, and the protocol version in use; 1770 o Zero or more Header lines, that can be of the following types: 1771 general-headers (Section 6), request-headers (Section 7.2), or 1772 message body headers (Section 9.1); 1774 o One empty line (CRLF) to indicate the end of the header section; 1776 o Optionally a message-body, consisting of one or more lines. The 1777 length of the message body in octets is indicated by the Content- 1778 Length message header. 1780 7.1. Request Line 1782 The request line provides the key information about the request: what 1783 method, on what resources and using which RTSP version. The methods 1784 that are defined by this specification are listed in Table 2. 1786 +---------------+--------------------+ 1787 | Method | Defined in Section | 1788 +---------------+--------------------+ 1789 | DESCRIBE | Section 13.2 | 1790 | | | 1791 | GET_PARAMETER | Section 13.8 | 1792 | | | 1793 | OPTIONS | Section 13.1 | 1794 | | | 1795 | PAUSE | Section 13.6 | 1796 | | | 1797 | PLAY | Section 13.4 | 1798 | | | 1799 | PLAY_NOTIFY | Section 13.5 | 1800 | | | 1801 | REDIRECT | Section 13.10 | 1802 | | | 1803 | SETUP | Section 13.3 | 1804 | | | 1805 | SET_PARAMETER | Section 13.9 | 1806 | | | 1807 | TEARDOWN | Section 13.7 | 1808 +---------------+--------------------+ 1810 Table 2: The RTSP Methods 1812 The syntax of the RTSP request line is the following: 1814 SP SP CRLF 1816 Note: This syntax cannot be freely changed in future versions of 1817 RTSP. This line needs to remain parsable by older RTSP 1818 implementations since it indicates the RTSP version of the message. 1820 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1821 resource through an absolute RTSP URI (including scheme, host, and 1822 port) (see Section 4.2) rather than just the absolute path. 1824 HTTP/1.1 requires servers to understand the absolute URI, but 1825 clients are supposed to use the Host request-header. This is 1826 purely needed for backward-compatibility with HTTP/1.0 servers, a 1827 consideration that does not apply to RTSP. 1829 An asterisk "*" can be used instead of an absolute URI in the 1830 Request-URI part to indicate that the request does not apply to a 1831 particular resource, but to the server or proxy itself, and is only 1832 allowed when the request method does not necessarily apply to a 1833 resource. 1835 For example: 1837 OPTIONS * RTSP/2.0 1839 An OPTIONS in this form will determine the capabilities of the server 1840 or the proxy that first receives the request. If the capability of 1841 the specific server needs to be determined, without regard to the 1842 capability of an intervening proxy, the server should be addressed 1843 explicitly with an absolute URI that contains the server's address. 1845 For example: 1847 OPTIONS rtsp://example.com RTSP/2.0 1849 7.2. Request Header Fields 1851 The RTSP headers in Table 3 can be included in a request, as request- 1852 headers, to modify the specifics of the request. 1854 +---------------------+--------------------+ 1855 | Header | Defined in Section | 1856 +---------------------+--------------------+ 1857 | Accept | Section 18.1 | 1858 | | | 1859 | Accept-Credentials | Section 18.2 | 1860 | | | 1861 | Accept-Encoding | Section 18.3 | 1862 | | | 1863 | Accept-Language | Section 18.4 | 1864 | | | 1865 | Authorization | Section 18.8 | 1866 | | | 1867 | Bandwidth | Section 18.9 | 1868 | | | 1869 | Blocksize | Section 18.10 | 1870 | | | 1871 | From | Section 18.23 | 1872 | | | 1873 | If-Match | Section 18.24 | 1874 | | | 1875 | If-Modified-Since | Section 18.25 | 1876 | | | 1877 | If-None-Match | Section 18.26 | 1878 | | | 1879 | Notify-Reason | Section 18.32 | 1880 | | | 1881 | Proxy-Authorization | Section 18.36 | 1882 | | | 1883 | Proxy-Require | Section 18.37 | 1884 | | | 1885 | Referrer | Section 18.41 | 1886 | | | 1887 | Request-Status | Section 18.42 | 1888 | | | 1889 | Require | Section 18.43 | 1890 | | | 1891 | Terminate-Reason | Section 18.52 | 1892 +---------------------+--------------------+ 1894 Table 3: The RTSP request headers 1896 Detailed header definitions are provided in Section 18. 1898 New request-headers may be defined. If the receiver of the request 1899 is required to understand the request-header, the request MUST 1900 include a corresponding feature tag in a Require or Proxy-Require 1901 header to ensure the processing of the header. 1903 8. Response 1905 After receiving and interpreting a request message, the recipient 1906 responds with an RTSP response message. Normally, there is only one, 1907 final, response. Only responses using the response code class 1xx, 1908 are allowed to send one or more 1xx response messages prior to the 1909 final response message. 1911 The valid response codes and the methods they can be used with are 1912 listed in Table 4. 1914 8.1. Status-Line 1916 The first line of a Response message is the Status-Line, consisting 1917 of the protocol version followed by a numeric status code and the 1918 textual phrase associated with the status code, with each element 1919 separated by SP characters. No CR or LF is allowed except in the 1920 final CRLF sequence. 1922 SP SP CRLF 1924 8.1.1. Status Code and Reason Phrase 1926 The Status-Code element is a 3-digit integer result code of the 1927 attempt to understand and satisfy the request. These codes are fully 1928 defined in Section 17. The Reason-Phrase is intended to give a short 1929 textual description of the Status-Code. The Status-Code is intended 1930 for use by automata and the Reason-Phrase is intended for the human 1931 user. The client is not required to examine or display the Reason- 1932 Phrase. 1934 The first digit of the Status-Code defines the class of response. 1935 The last two digits do not have any categorization role. There are 5 1936 values for the first digit: 1938 1xx: Informational - Request received, continuing process 1940 2xx: Success - The action was successfully received, understood, and 1941 accepted 1943 3rr: Redirection - Further action needs to be taken in order to 1944 complete the request (3rr rather than 3xx is used as 304 is 1945 excluded, see Section 17.3) 1947 4xx: Client Error - The request contains bad syntax or cannot be 1948 fulfilled 1950 5xx: Server Error - The server failed to fulfill an apparently valid 1951 request 1953 The individual values of the numeric status codes defined for 1954 RTSP/2.0, and an example set of corresponding Reason-Phrases, are 1955 presented in Table 4. The reason phrases listed here are only 1956 recommended; they may be replaced by local equivalents without 1957 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1958 [RFC2616] status codes and adds RTSP-specific status codes starting 1959 at x50 to avoid conflicts with future HTTP status codes that are 1960 desirable to import into RTSP. All these codes are RTSP specific and 1961 RTSP has its own registry separate from HTTP for status codes. 1963 RTSP status codes are extensible. RTSP applications are not required 1964 to understand the meaning of all registered status codes, though such 1965 understanding is obviously desirable. However, applications MUST 1966 understand the class of any status code, as indicated by the first 1967 digit, and treat any unrecognized response as being equivalent to the 1968 x00 status code of that class, with an exception for unknown 3xx 1969 codes, which MUST be treated as a 302 (Found). The reason being that 1970 no 300 (Multiple Choices in HTTP) is defined for RTSP. An response 1971 with an unrecognized status code MUST NOT be cached. For example, if 1972 an unrecognized status code of 431 is received by the client, it can 1973 safely assume that there was something wrong with its request and 1974 treat the response as if it had received a 400 status code. In such 1975 cases, user agents SHOULD present to the user the message body 1976 returned with the response, since that message body is likely to 1977 include human-readable information which will explain the unusual 1978 status. 1980 +------+---------------------------------+--------------------------+ 1981 | Code | Reason | Method | 1982 +------+---------------------------------+--------------------------+ 1983 | 100 | Continue | all | 1984 | | | | 1985 | | | | 1986 | 200 | OK | all | 1987 | | | | 1988 | | | | 1989 | 301 | Moved Permanently | all | 1990 | | | | 1991 | 302 | Found | all | 1992 | | | | 1993 | 303 | reserved | n/a | 1994 | | | | 1995 | 304 | Not Modified | all | 1996 | | | | 1997 | 305 | Use Proxy | all | 1998 | 400 | Bad Request | all | 1999 | | | | 2000 | 401 | Unauthorized | all | 2001 | | | | 2002 | 402 | Payment Required | all | 2003 | | | | 2004 | 403 | Forbidden | all | 2005 | | | | 2006 | 404 | Not Found | all | 2007 | | | | 2008 | 405 | Method Not Allowed | all | 2009 | | | | 2010 | 406 | Not Acceptable | all | 2011 | | | | 2012 | 407 | Proxy Authentication Required | all | 2013 | | | | 2014 | 408 | Request Timeout | all | 2015 | | | | 2016 | 410 | Gone | all | 2017 | | | | 2018 | 412 | Precondition Failed | DESCRIBE, SETUP | 2019 | | | | 2020 | 413 | Request Message Body Too Large | all | 2021 | | | | 2022 | 414 | Request-URI Too Long | all | 2023 | | | | 2024 | 415 | Unsupported Media Type | all | 2025 | | | | 2026 | 451 | Parameter Not Understood | SET_PARAMETER, | 2027 | | | GET_PARAMETER | 2028 | | | | 2029 | 452 | reserved | n/a | 2030 | | | | 2031 | 453 | Not Enough Bandwidth | SETUP | 2032 | | | | 2033 | 454 | Session Not Found | all | 2034 | | | | 2035 | 455 | Method Not Valid In This State | all | 2036 | | | | 2037 | 456 | Header Field Not Valid | all | 2038 | | | | 2039 | 457 | Invalid Range | PLAY, PAUSE | 2040 | | | | 2041 | 458 | Parameter Is Read-Only | SET_PARAMETER | 2042 | | | | 2043 | 459 | Aggregate Operation Not Allowed | all | 2044 | | | | 2045 | 460 | Only Aggregate Operation | all | 2046 | | Allowed | | 2047 | | | | 2048 | 461 | Unsupported Transport | all | 2049 | | | | 2050 | 462 | Destination Unreachable | all | 2051 | | | | 2052 | 463 | Destination Prohibited | SETUP | 2053 | | | | 2054 | 464 | Data Transport Not Ready Yet | PLAY | 2055 | | | | 2056 | 465 | Notification Reason Unknown | PLAY_NOTIFY | 2057 | | | | 2058 | 466 | Key Management Error | all | 2059 | | | | 2060 | 470 | Connection Authorization | all | 2061 | | Required | | 2062 | | | | 2063 | 471 | Connection Credentials not | all | 2064 | | accepted | | 2065 | | | | 2066 | 472 | Failure to establish secure | all | 2067 | | connection | | 2068 | | | | 2069 | | | | 2070 | 500 | Internal Server Error | all | 2071 | | | | 2072 | 501 | Not Implemented | all | 2073 | | | | 2074 | 502 | Bad Gateway | all | 2075 | | | | 2076 | 503 | Service Unavailable | all | 2077 | | | | 2078 | 504 | Gateway Timeout | all | 2079 | | | | 2080 | 505 | RTSP Version Not Supported | all | 2081 | | | | 2082 | 551 | Option Not Supported | all | 2083 | | | | 2084 | 553 | Proxy Unavailable | all | 2085 +------+---------------------------------+--------------------------+ 2087 Table 4: Status codes and their usage with RTSP methods 2089 8.2. Response Headers 2091 The response-headers allow the request recipient to pass additional 2092 information about the response which cannot be placed in the Status- 2093 Line. This header gives information about the server and about 2094 further access to the resource identified by the Request-URI. All 2095 headers currently classified as response-headers are listed in 2096 Table 5. 2098 +------------------------+--------------------+ 2099 | Header | Defined in Section | 2100 +------------------------+--------------------+ 2101 | Authentication-Info | Section 18.7 | 2102 | | | 2103 | Connection-Credentials | Section 18.13 | 2104 | | | 2105 | Location | Section 18.28 | 2106 | | | 2107 | MTag | Section 18.31 | 2108 | | | 2109 | Proxy-Authenticate | Section 18.34 | 2110 | | | 2111 | Public | Section 18.39 | 2112 | | | 2113 | Retry-After | Section 18.44 | 2114 | | | 2115 | Unsupported | Section 18.55 | 2116 | | | 2117 | WWW-Authenticate | Section 18.58 | 2118 +------------------------+--------------------+ 2120 Table 5: The RTSP response headers 2122 Response-header names can be extended reliably only in combination 2123 with a change in the protocol version. However, the usage of 2124 feature-tags in the request allows the responding party to learn the 2125 capability of the receiver of the response. A new or experimental 2126 header MAY be given the semantics of response-header if all parties 2127 in the communication recognize them to be a response-header. 2128 Unrecognized headers in responses are treated as message-body headers 2129 and hence MUST be ignored. 2131 9. Message Body 2133 Request and Response messages MAY transfer a message body, if not 2134 otherwise restricted by the request method or response status code. 2135 The message body consists of the content data itself (see also 2136 Section 5.3). 2138 The SET_PARAMETER and GET_PARAMETER requests and responses, and the 2139 DESCRIBE response as defined by this specification MAY have a message 2140 body; the purpose of the message body is defined in each case. All 2141 4xx and 5xx responses MAY also have a message body to carry 2142 additional response information. Generally a message body MAY be 2143 attached to any RTSP 2.0 request or response, but the content of the 2144 message body MAY be ignored by the receiver. Extensions to this 2145 specification can specify the purpose and content of message bodies, 2146 including requiring their inclusion. 2148 In this section, both sender and recipient refer to either the client 2149 or the server, depending on who sends and who receives the message 2150 body. 2152 9.1. Message-Body Header Fields 2154 Message-body header fields define meta-information about the content 2155 data in the message body. The message-body header fields are listed 2156 in Table 6. 2158 +------------------+--------------------+ 2159 | Header | Defined in Section | 2160 +------------------+--------------------+ 2161 | Allow | Section 18.6 | 2162 | | | 2163 | Content-Base | Section 18.14 | 2164 | | | 2165 | Content-Encoding | Section 18.15 | 2166 | | | 2167 | Content-Language | Section 18.16 | 2168 | | | 2169 | Content-Length | Section 18.17 | 2170 | | | 2171 | Content-Location | Section 18.18 | 2172 | | | 2173 | Content-Type | Section 18.19 | 2174 | | | 2175 | Expires | Section 18.22 | 2176 | | | 2177 | Last-Modified | Section 18.27 | 2178 +------------------+--------------------+ 2180 Table 6: The RTSP message-body headers 2182 The extension-header mechanism allows additional message-body header 2183 fields to be defined without changing the protocol, but these fields 2184 cannot be assumed to be recognizable by the recipient. Unrecognized 2185 header fields MUST be ignored by the recipient and forwarded by 2186 proxies. 2188 9.2. Message Body 2190 An RTSP message with a message body MUST include the Content-Type and 2191 Content-Length headers. When a message body is included with a 2192 message, the data type of that content data is determined via the 2193 header fields Content-Type and Content-Encoding. 2195 Content-Type specifies the media type of the underlying data. 2196 Content-Encoding may be used to indicate any additional content 2197 codings applied to the data, usually for the purpose of data 2198 compression, that are a property of the requested resource. There is 2199 no default encoding. 2201 The Content-Length of a message is the length of the content, 2202 measured in octets. 2204 9.3. Message Body Format Negotiation 2206 The content format of the message body is provided using the Content- 2207 Type header (Section 18.19). To enable the responder of a request to 2208 determine which media type it should use, the requestor may include 2209 the Accept header (Section 18.1) in a request to identify supported 2210 media types or media type ranges suitable to the response. In case 2211 the responder is not supporting any of the specified formats, then 2212 the request response will be a 406 (Not Acceptable) error code. 2214 The media types that may be used on requests with message bodies need 2215 to be determined through the use of feature-tags, specification 2216 requirement or trial and error. Trial and error works because when 2217 the responder does not support the media type of the message body it 2218 will respond with a 415 (Unsupported Media Type). 2220 The formats supported and their negotiation is done individually on a 2221 per method and direction (request or response body) direction. 2222 Requirements on supporting particular media types for use as message 2223 bodies in requests and response SHALL also be specified on per method 2224 and direction basis. 2226 10. Connections 2228 RTSP Messages are transferred between RTSP agents and proxies using a 2229 transport connection. This transport connection uses TCP or TCP/TLS. 2230 This transport connection is referred to as the connection or 2231 possibly RTSP connection within this document. 2233 RTSP requests can be transmitted using the two different connection 2234 scenarios listed below: 2236 o persistent - a transport connection is used for several request/ 2237 response transactions; 2239 o transient - a transport connection is used for a single request/ 2240 response transaction. 2242 RFC 2326 attempted to specify an optional mechanism for transmitting 2243 RTSP messages in connectionless mode over a transport protocol such 2244 as UDP. However, it was not specified in sufficient detail to allow 2245 for interoperable implementations. In an attempt to reduce 2246 complexity and scope, and due to lack of interest, RTSP 2.0 does not 2247 attempt to define a mechanism for supporting RTSP over UDP or other 2248 connectionless transport protocols. A side-effect of this is that 2249 RTSP requests MUST NOT be sent to multicast groups since no 2250 connection can be established with a specific receiver in multicast 2251 environments. 2253 Certain RTSP headers, such as the CSeq header (Section 18.20), which 2254 may appear to be relevant only to connectionless transport scenarios 2255 are still retained and MUST be implemented according to the 2256 specification. In the case of CSeq, it is quite useful for matching 2257 responses to requests if the requests are pipelined (see Section 12). 2258 It is also useful in proxies for keeping track of the different 2259 requests when aggregating several client requests on a single TCP 2260 connection. 2262 10.1. Reliability and Acknowledgements 2264 Since RTSP messages are transmitted using reliable transport 2265 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 2266 Instead, the implementation must rely on the underlying transport to 2267 provide reliability. The RTSP implementation may use any indication 2268 of reception acknowledgment of the message from the underlying 2269 transport protocols to optimize the RTSP behavior. 2271 If both the underlying reliable transport such as TCP and the RTSP 2272 application retransmit requests, each packet loss or message loss 2273 may result in two retransmissions. The receiver typically cannot 2274 take advantage of the application-layer retransmission since the 2275 transport stack will not deliver the application-layer 2276 retransmission before the first attempt has reached the receiver. 2277 If the packet loss is caused by congestion, multiple 2278 retransmissions at different layers will exacerbate the 2279 congestion. 2281 Lack of acknowledgment of an RTSP request should be handled within 2282 the constraints of the connection timeout considerations described 2283 below (Section 10.4). 2285 10.2. Using Connections 2287 A TCP transport can be used for both persistent connections (for 2288 several message exchanges) and transient connections (for a single 2289 message exchange). Implementations of this specification MUST 2290 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 2291 indicates the default port that the server will listen on if the port 2292 is not explicitly given. 2294 In addition to the registered default ports, i.e., 554 (rtsp) and 322 2295 (rtsps), there is an alternative port 8554 registered. This port may 2296 provide some benefits from non-registered ports if a RTSP server is 2297 unable to use the default ports. The benefits may include pre- 2298 configured security policies as well as classifiers in network 2299 monitoring tools. 2301 A RTSP client opening a TCP connection for accessing a particular 2302 resource as identified by a URI uses the IP address and port derived 2303 from the host and port parts of the URI. The IP address is either 2304 the explicit address provided in the URI or any of the addresses 2305 provided when performing A and AAAA record DNS lookups of the host 2306 name in the URI. 2308 A server MUST handle both persistent and transient connections. 2310 Transient connections facilitate mechanisms for fault tolerance. 2311 They also allow for application layer mobility. A server and 2312 client pair that support transient connections can survive the 2313 loss of a TCP connection; e.g., due to a NAT timeout. When the 2314 client has discovered that the TCP connection has been lost, it 2315 can set up a new one when there is need to communicate again. 2317 A persistent connection is RECOMMENDED to be used for all 2318 transactions between the server and client, including messages for 2319 multiple RTSP sessions. However, a persistent connection MAY be 2320 closed after a few message exchanges. For example, a client may use 2321 a persistent connection for the initial SETUP and PLAY message 2322 exchanges in a session and then close the connection. Later, when 2323 the client wishes to send a new request, such as a PAUSE for the 2324 session, a new connection would be opened. This connection may 2325 either be transient or persistent. 2327 An RTSP agent MAY use one connection to handle multiple RTSP sessions 2328 on the same server. The RTSP agent SHALL NOT use more than one 2329 connection per RTSP session at any given point. 2331 Using a single connection for multiple RTSP session saves 2332 complexity by enabling the server to maintain less state about its 2333 connection resources on the server. Not using more than one 2334 connection at a time for a particular RTSP session avoids wasting 2335 connection resources and allows the server to track only the most 2336 recently used client to server connection for each RTSP session as 2337 being the currently valid server to client connection. 2339 RTSP allows a server to send requests to a client. However, this can 2340 be supported only if a client establishes a persistent connection 2341 with the server. In cases where a persistent connection does not 2342 exist between a server and its client, due to the lack of a signaling 2343 channel the server may be forced to silently discard RTSP messages, 2344 and may even drop an RTSP session without notifying the client. An 2345 example of such a case is when the server desires to send a REDIRECT 2346 request for an RTSP session to the client but is not able to do so 2347 because it cannot reach the client. A server that attempts to send a 2348 request to a client that has no connection currently to the server 2349 SHALL discard the request directly. 2351 Without a persistent connection between the client and the server, 2352 the media server has no reliable way of reaching the client. 2353 Because the likely failure of server to client established 2354 connections the server will not even attempt establishing any 2355 connection. 2357 Queuing of server to client requests has been considered. However 2358 a security issue exists as to how it might be possible to 2359 authorize a client establishing a new connection as being a 2360 legitimate receiver of a request related to a particular RTSP 2361 session without the client first issuing requests related to the 2362 request. Thus, it would be likely to make any such requests even 2363 more delayed and less useful. 2365 The sending of client and server requests can be asynchronous events. 2366 To avoid deadlock situations both client and server MUST be able to 2367 send and receive requests simultaneously. As an RTSP response may be 2368 queued up for transmission, reception or processing behind the peer 2369 RTSP agent's own requests, all RTSP agents are required to have a 2370 certain capability of handling outstanding messages. A potential 2371 issue is that outstanding requests may timeout despite them being 2372 processed by the peer due to the response being caught in the queue 2373 behind a number of requests that the RTSP agent is processing but 2374 that take some time to complete. To avoid this problem an RTSP agent 2375 is recommended to buffer incoming messages locally so that any 2376 response messages can be processed immediately upon reception. If 2377 responses are separated from requests and directly forwarded for 2378 processing, not only can the result be used immediately, the state 2379 associated with that outstanding request can also be released. 2380 However, buffering a number of requests on the receiving RTSP agent 2381 consumes resources and enables a resource exhaustion attack on the 2382 agent. Therefore this buffer should be limited so that an 2383 unreasonable number of requests or total message size is not allowed 2384 to consume the receiving agent's resources. In most APIs, having the 2385 receiving agent stop reading from the TCP socket will result in TCP's 2386 window being clamped. Thus forcing the buffering onto the sending 2387 agent when the load is larger than expected. However, as both RTSP 2388 message sizes and frequency may be changed in the future by protocol 2389 extensions, an agent should be careful against taking harsher 2390 measurements against a potential attack. When under attack an RTSP 2391 agent can close TCP connections and release state associated with 2392 that TCP connection. 2394 To provide some guidance on what is reasonable the following 2395 guidelines are given. It is RECOMMENDED that: 2397 o an RTSP agent should not have more than 10 outstanding requests 2398 per RTSP session; 2400 o an RTSP agent should not have more than 10 outstanding requests 2401 that are not related to an RTSP session or that are requesting to 2402 create an RTSP session. 2404 In light of the above, it is RECOMMENDED that clients use persistent 2405 connections whenever possible. A client that supports persistent 2406 connections MAY "pipeline" its requests (see Section 12). 2408 RTSP Agents can send requests to multiple different destinations, 2409 either servers or client contexts over the same connection to a 2410 proxy. Then the proxy forks the message to the different 2411 destinations over proxy to agent connections. In these cases when 2412 multiple requests are outstanding the requesting agent MUST be ready 2413 to receive the responses out of order compared to the order they 2414 where sent on the connection. The order between multiple messages 2415 for each destination will be maintained, however, the order between 2416 response from different destinations can be different. 2418 The reason for this is to avoid a head-of-line blocking 2419 sitauation. In a sequence of requests an early outstanding 2420 request may take time to be processed at one destination. 2421 Simultaneously, a response from any other destination that was 2422 later in the sequence of requests, may have arrived at the proxy. 2423 Thus allowing out-of-order responses avoids forcing the proxy to 2424 buffer this response and instead deliver it as soon as possible. 2425 Note, this will not affect the order in which the messages sent to 2426 each separate destination were processed at request destination. 2428 This scenario can occur in two cases involving proxies. The first is 2429 a client issuing requests for sessions on different servers using a 2430 common client to proxy connection. The second is for server to 2431 client requests, like REDIRECT being sent by the server over a common 2432 transport connection the proxy created for its different connecting 2433 clients. 2435 10.3. Closing Connections 2437 The client MAY close a connection at any point when no outstanding 2438 request/response transactions exist for any RTSP session being 2439 managed through the connection. The server, however, SHOULD NOT 2440 close a connection until all RTSP sessions being managed through the 2441 connection have been timed out (Section 18.49). A server SHOULD NOT 2442 close a connection immediately after responding to a session-level 2443 TEARDOWN request for the last RTSP session being controlled through 2444 the connection. Instead, the server should wait for a reasonable 2445 amount of time for the client to receive and act upon the TEARDOWN 2446 response, and initiate the connection closing. The server SHOULD 2447 wait at least 10 seconds after sending the TEARDOWN response before 2448 closing the connection. 2450 This is to ensure that the client has time to issue a SETUP for a 2451 new session on the existing connection after having torn the last 2452 one down. 10 seconds should give the client ample opportunity to 2453 get its message to the server. 2455 A server SHOULD NOT close the connection directly as a result of 2456 responding to a request with an error code. 2458 Certain error responses such as "460 Only Aggregate Operation 2459 Allowed" (Section 17.4.25) are used for negotiating capabilities 2460 of a server with respect to content or other factors. In such 2461 cases, it is inefficient for the server to close a connection on 2462 an error response. Also, such behavior would prevent 2463 implementation of advanced/special types of requests or result in 2464 extra overhead for the client when testing for new features. On 2465 the other hand, keeping connections open after sending an error 2466 response poses a Denial of Service security risk (Section 21). 2468 The server MAY close a connection if it receives an incomplete 2469 message and if the message is not completed within a reasonable 2470 amount of time. It is RECOMMENDED that the server waits at least 10 2471 seconds for the completion of a message or for the next part of the 2472 message to arrive (which is an indication that the transport and the 2473 client are still alive). Servers believing they are under attack or 2474 otherwise starved for resources during that event MAY consider using 2475 a shorter timeout. 2477 If a server closes a connection while the client is attempting to 2478 send a new request, the client will have to close its current 2479 connection, establish a new connection and send its request over the 2480 new connection. 2482 An RTSP message SHOULD NOT be terminated by closing the connection. 2483 Such a message MAY be considered to be incomplete by the receiver and 2484 discarded. An RTSP message is properly terminated as defined in 2485 Section 5. 2487 10.4. Timing Out Connections and RTSP Messages 2489 Receivers of a request (responder) SHOULD respond to requests in a 2490 timely manner even when a reliable transport such as TCP is used. 2491 Similarly, the sender of a request (requester) SHOULD wait for a 2492 sufficient time for a response before concluding that the responder 2493 will not be acting upon its request. 2495 A responder SHOULD respond to all requests within 5 seconds. If the 2496 responder recognizes that processing of a request will take longer 2497 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 2498 possible. It SHOULD continue sending a 100 response every 5 seconds 2499 thereafter until it is ready to send the final response to the 2500 requester. After sending a 100 response, the receiver MUST send a 2501 final response indicating the success or failure of the request. 2503 A requester SHOULD wait at least 10 seconds for a response before 2504 concluding that the responder will not be responding to its request. 2505 After receiving a 100 response, the requester SHOULD continue waiting 2506 for further responses. If more than 10 seconds elapses without 2507 receiving any response, the requester MAY assume that the responder 2508 is unresponsive and abort the connection by closing the TCP 2509 connection. 2511 In cases multiple RTSP sessions share the same transport connection, 2512 abandoning a request and closing the connection may have significant 2513 impact on those other sessions. First of all, other RTSP requests 2514 may have become queued up due to the request taking long time. 2515 Secondly also those sessions loose the possibility to receive server 2516 to client requests. To mitigate that situation the RTSP agent SHOULD 2517 establish a new connection and send any queued up and non-responded 2518 requests on this new connection. Secondly, to ensure that the RTSP 2519 server knows which connection that is valid for a particular RTSP 2520 session, the RTSP agent SHOULD send a keep-alive request, if no other 2521 request will be sent immediately for that RTSP session, for each RTSP 2522 session on the old connection. The keep-alive request will normally 2523 be a GET_PARAMETER with a session header to inform the server that 2524 this agent cares about this RTSP session. 2526 A requester SHOULD wait longer than 10 seconds for a response if it 2527 is experiencing significant transport delays on its connection to the 2528 responder. The requester is capable of determining the round trip 2529 time (RTT) of the request/response cycle using the Timestamp header 2530 (Section 18.53) in any RTSP request. 2532 10 seconds was chosen for the following reasons. It gives TCP 2533 time to perform a couple of retransmissions, even if operating on 2534 default values. It is short enough that users may not abandon the 2535 process themselves. However, it should be noted that 10 seconds 2536 can be aggressive on certain type of networks. The 5 seconds 2537 value for 1xx messages is half the timeout giving a reasonable 2538 chance of successful delivery before timeout happens on the 2539 requester side. 2541 10.5. Showing Liveness 2543 The mechanisms for showing liveness of the client is, any RTSP 2544 request with a Session header, if RTP & RTCP is used an RTCP message, 2545 or through any other used media protocol capable of indicating 2546 liveness of the RTSP client. It is RECOMMENDED that a client does 2547 not wait to the last second of the timeout before trying to send a 2548 liveness message. The RTSP message may be lost or when using 2549 reliable protocols, such as TCP, the message may take some time to 2550 arrive safely at the receiver. To show liveness between RTSP 2551 requests being issued to accomplish other things, the following 2552 mechanisms can be used, in descending order of preference: 2554 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 2555 RTCP is used to report transport statistics, it will 2556 necessarily also function as a keep-alive. The server can 2557 determine the client by network address and port together with 2558 the fact that the client is reporting on the server's RTP 2559 sender sources (SSRCs). A downside of using RTCP is that it 2560 only gives statistical guarantees of reaching the server. 2561 However, the probability of a false client timeout is so low 2562 that it can be ignored in most cases. For example, assume a 2563 session with 60 seconds timeout and enough bitrate assigned to 2564 RTCP messages to send a message from client to server on 2565 average every 5 seconds. That client has, for a network with 2566 5% packet loss, a probability of failing to confirm liveness 2567 within the timeout interval for that session of 2.4*E-16. 2568 Sessions with shorter timeouts, or much higher packet loss, or 2569 small RTCP bandwidths SHOULD also implement one or more of the 2570 mechanisms below. 2572 SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body 2573 SHOULD NOT be included. This method is the RECOMMENDED RTSP 2574 method to use for a request intended only to perform keep- 2575 alive. Support of SET_PARAMETER is mandatory for RTSP Servers 2576 to ensure clients can use this method. 2578 GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body 2579 SHOULD be included. Dependent on implementation support in 2580 server. Use OPTIONS method to determine if there are method 2581 support or simply try. 2583 OPTIONS: This method is also usable, but it causes the server to 2584 perform more unnecessary processing and results in bigger 2585 responses than necessary for the task. The reason is that the 2586 server needs to determine the capabilities associated with the 2587 media resource to correctly populate the Public and Allow 2588 headers. 2590 The timeout parameter of the Session header (Section 18.49) MAY be 2591 included in a SETUP response, and MUST NOT be included in requests. 2592 The server uses it to indicate to the client how long the server is 2593 prepared to wait between RTSP commands or other signs of life before 2594 closing the session due to lack of activity (see Appendix B). The 2595 timeout is measured in seconds, with a default of 60 seconds. The 2596 length of the session timeout MUST NOT be changed in an established 2597 session. 2599 10.6. Use of IPv6 2601 Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC 2602 2326). RTSP 2.0 has been updated for explicit IPv6 support. 2603 Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in 2604 URIs and RTSP headers. Although the general URI format envisages 2605 potential future new versions of the literal IP address, usage of any 2606 such new version would require other modifications to the RTSP 2607 specification (e.g. address fields in the Transport header 2608 (Section 18.54)). 2610 10.7. Overload Control 2612 Overload in RTSP can occur when servers and proxies have insufficient 2613 resources to complete the processing of a request. An improper 2614 handling of such an overload situation at proxies and servers can 2615 impact the operation of the RTSP deployment, and probably worsen the 2616 situation. RTSP defines the 503 (Service Unavailable) response 2617 (Section 17.5.4) to let servers and proxies notify requesting proxies 2618 and RTSP clients about an overload situation. In conjunction with 2619 the Retry-After header (Section 18.44) the server or proxy can 2620 indicate the time after which the requesting entity can send another 2621 request to the proxy or server. 2623 There are two scopes of such 503 answers, one for established RTSP 2624 sessions, where the request resulting in the 503 response as well as 2625 the response carries a Session header identifying the session which 2626 is suffering overload. This response only applies to this particular 2627 session. The other scope is the general RTSP server as identified by 2628 the host in the request URL. Such a 503 answer with any Retry-After 2629 header applies to all non-session specific requests to that server, 2630 including SETUP request intended to create a new RTSP session. 2632 Another scope for overload situation exists, which is the RTSP proxy. 2633 To enable an RTSP proxy to signal that it is overloaded, or otherwise 2634 unavailable and can't handle the request, a 553 response code has 2635 been defined with the meaning "Proxy Unavailable". As with servers, 2636 there is a separation in response scopes between requests associated 2637 with existing RTSP sessions, and requests to create new sessions or 2638 general proxy requests. 2640 Simply implementing and using the 503 (Service Unavailable) and 553 2641 (Proxy Unavailable) is not sufficient for properly handling overload 2642 situations. For instance, a simplistic approach would be to send the 2643 503 response with a Retry-After header set to a fixed value. 2644 However, this can cause the situation where multiple RTSP clients 2645 again send requests to a proxy or server at roughly the same time 2646 which may again cause an overload situation, or if the "old" overload 2647 situation is not yet solved, i.e., the length indicated in the Retry- 2648 After header was too short. 2650 An RTSP server or proxy in an overload situation must select the 2651 value of the Retry-After header carefully and bearing in mind its 2652 current load situation. It is REQUIRED to increase the timeout 2653 period in proportion to the current load on the server, i.e., an 2654 increasing workload should result in an increased length of the 2655 indicated unavailability. It is REQUIRED to not send the same value 2656 in the Retry-After header to all requesting proxies and clients, but 2657 to add a variation to the mean value of the Retry-After header. 2659 A more complex case may arise when a load balancing RTSP proxy is in 2660 use, i.e., where an RTSP proxy is used to select amongst a set of 2661 RTSP servers to handle the requests, or when multiple server 2662 addresses are available for a given server name. The proxy or client 2663 may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) 2664 from one of its RTSP servers or proxies, or a TCP timeout (if the 2665 server is even unable to handle the request message). The proxy or 2666 client simply retries the other addresses or configured proxies, but 2667 may also receive a 503 (Service Unavailable) or 553 (Proxy 2668 Unavailable) response or TCP timeouts from those addresses. In such 2669 a situation, where none of the RTSP servers/proxies/addresses can 2670 handle the request, the RTSP agent has to wait before it can send any 2671 new requests to the RTSP server. Any additional request to a 2672 specific address MUST be delayed according to the Retry-After headers 2673 received. For addresses where no response was received or TCP 2674 timeout occurred, an initial wait timer SHOULD be set to 5 seconds. 2675 That timer MUST be doubled for each additional failure to connect or 2676 receive response until the value exceeds 30 minutes when the timers 2677 mean value may be set to 30 minutes. It is REQUIRED to not set the 2678 same value in the timer for each scheduling, but instead to add a 2679 variation to the mean value, resulting in picking a random value 2680 within the range of 0.5 to 1.5 of the mean value. 2682 11. Capability Handling 2684 This section describes the available capability handling mechanism 2685 which allows RTSP to be extended. Extensions to this version of the 2686 protocol are basically done in two ways. First, new headers can be 2687 added. Secondly, new methods can be added. The capability handling 2688 mechanism is designed to handle both cases. 2690 When a method is added, the involved parties can use the OPTIONS 2691 method to discover whether it is supported. This is done by issuing 2692 an OPTIONS request to the other party. Depending on the URI it will 2693 either apply in regards to a certain media resource, the whole server 2694 in general, or simply the next hop. The OPTIONS response MUST 2695 contain a Public header which declares all methods supported for the 2696 indicated resource. 2698 It is not necessary to use OPTIONS to discover support of a method, 2699 as the client could simply try the method. If the receiver of the 2700 request does not support the method it will respond with an error 2701 code indicating the method is either not implemented (501) or does 2702 not apply for the resource (405). The choice between the two 2703 discovery methods depends on the requirements of the service. 2705 Feature-tags are defined to handle functionality additions that are 2706 not new methods. Each feature-tag represents a certain block of 2707 functionality. The amount of functionality that a feature-tag 2708 represents can vary significantly. A feature-tag can for example 2709 represent the functionality a single RTSP header provides. Another 2710 feature-tag can represent much more functionality, such as the 2711 "play.basic" feature-tag (Section 11.1) which represents the minimal 2712 media delivery for playback implementation. 2714 Feature-tags are used to determine whether the client, server or 2715 proxy supports the functionality that is necessary to achieve the 2716 desired service. To determine support of a feature-tag, several 2717 different headers can be used, each explained below: 2719 Supported: This header is used to determine the complete set of 2720 functionality that both client and server have in general and 2721 is not dependent on a specific resource. The intended usage is 2722 to determine before one needs to use a functionality that it is 2723 supported. It can be used in any method, but OPTIONS is the 2724 most suitable one as it at the same time determines all methods 2725 that are implemented. When sending a request the requester 2726 declares all its capabilities by including all supported 2727 feature-tags. This results in the receiver learning the 2728 requester's feature support. The receiver then includes its 2729 set of features in the response. 2731 Proxy-Supported: This header is used similarly to the Supported 2732 header, but instead of giving the supported functionality of 2733 the client or server it provides both the requester and the 2734 responder a view of the common functionality supported in 2735 general by all members of the proxy chain between the two 2736 supports and not dependent on the resource. Proxies are 2737 required to add this header whenever the Supported header is 2738 present, but proxies may also add it independently of the 2739 requester. 2741 Require: This header can be included in any request where the end- 2742 point, i.e., the client or server, is required to understand 2743 the feature to correctly perform the request. This can, for 2744 example, be a SETUP request where the server is required to 2745 understand a certain parameter to be able to set up the media 2746 delivery correctly. Ignoring this parameter would not have the 2747 desired effect and is not acceptable. Therefore the end-point 2748 receiving a request containing a Require MUST negatively 2749 acknowledge any feature that it does not understand and not 2750 perform the request. The response in cases where features are 2751 not supported are 551 (Option Not Supported). Also the 2752 features that are not supported are given in the Unsupported 2753 header in the response. 2755 Proxy-Require: This header has the same purpose and workings as 2756 Require except that it only applies to proxies and not the end- 2757 point. Features that need to be supported by both proxies and 2758 end-points need to be included in both the Require and Proxy- 2759 Require header. 2761 Unsupported: This header is used in a 551 error response, to 2762 indicate which features were not supported. Such a response is 2763 only the result of the usage of the Require and/or Proxy- 2764 Require header where one or more features where not supported. 2765 This information allows the requester to make the best of 2766 situations as it knows which features are not supported. 2768 11.1. Feature Tag: play.basic 2770 The play.basic feature tag represents an RTSP implementation offering 2771 all the normative RTSP protocol features specified in this 2772 specification. This specification is both a RTSP core specification 2773 as well providing mechanisms for the setup and control of playback of 2774 media. Thus following all normative parts in the main sections (the 2775 ones with numbers), but omitting the appendices (starting with 2776 letters), unless explicitly specified in a main section as being a 2777 required appendix. 2779 Note: This feature tag does not mandate any media delivery 2780 protocol, such as RTP. 2782 In RTSP 1.0 there was a minimal implementation section. However, 2783 that was not consistent with the rest of the specification. So 2784 rather than making an attempt to explicitly enumerate the features 2785 for play.basic this specification has to be taken as a whole and 2786 the necessary features normatively defined as being required are 2787 included. 2789 12. Pipelining Support 2791 Pipelining is a general method to improve performance of request 2792 response protocols by allowing the requesting agent to have more than 2793 one request outstanding and send them over the same persistent 2794 connection. For RTSP, where the relative order of requests will 2795 matter, it is important to maintain the order of the requests. 2796 Because of this, the responding agent MUST process the incoming 2797 requests in their sending order. The sending order can be determined 2798 by the CSeq header and its sequence number. For TCP the delivery 2799 order will be the same between two agents, as the sending order. The 2800 processing of the request MUST also have been finished before 2801 processing the next request from the same agent. The responses MUST 2802 be sent in the order the requests were processed. 2804 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2805 The major improvement is to allow all requests involved in setting up 2806 and initiating media delivery to be pipelined after each other. This 2807 is accomplished by the utilization of the Pipelined-Requests header 2808 (see Section 18.33). This header allows a client to request that two 2809 or more requests are processed in the same RTSP session context which 2810 the first request creates. In other words, a client can request that 2811 two or more media streams are set-up and then played without needing 2812 to wait for a single response. This speeds up the initial startup 2813 time for an RTSP session by at least one RTT. 2815 If a pipelined request builds on the successful completion of one or 2816 more prior requests the requester must verify that all requests were 2817 executed as expected. A common example will be two SETUP requests 2818 and a PLAY request. In case one of the SETUP fails unexpectedly, the 2819 PLAY request can still be successfully executed. However, the 2820 resulting presentation will not be as expected by the requesting 2821 client, as only a single media instead of two will be played. In 2822 this case the client can send a PAUSE request, correct the failing 2823 SETUP request and then request it to be played. 2825 13. Method Definitions 2827 The method indicates what is to be performed on the resource 2828 identified by the Request-URI. The method name is case-sensitive. 2829 New methods may be defined in the future. Method names MUST NOT 2830 start with a $ character (decimal 36) and MUST be a token as defined 2831 by the ABNF [RFC5234] in the syntax chapter Section 20. The methods 2832 are summarized in Table 7. 2834 +---------------+-----------+--------+-------------+-------------+ 2835 | method | direction | object | Server req. | Client req. | 2836 +---------------+-----------+--------+-------------+-------------+ 2837 | DESCRIBE | C -> S | P,S | recommended | recommended | 2838 | | | | | | 2839 | GET_PARAMETER | C -> S | P,S | optional | optional | 2840 | | | | | | 2841 | | S -> C | P,S | optional | optional | 2842 | | | | | | 2843 | OPTIONS | C -> S | P,S | required | required | 2844 | | | | | | 2845 | | S -> C | P,S | optional | optional | 2846 | | | | | | 2847 | PAUSE | C -> S | P,S | required | required | 2848 | | | | | | 2849 | PLAY | C -> S | P,S | required | required | 2850 | | | | | | 2851 | PLAY_NOTIFY | S -> C | P,S | required | required | 2852 | | | | | | 2853 | REDIRECT | S -> C | P,S | optional | required | 2854 | | | | | | 2855 | SETUP | C -> S | S | required | required | 2856 | | | | | | 2857 | SET_PARAMETER | C -> S | P,S | required | optional | 2858 | | | | | | 2859 | | S -> C | P,S | optional | optional | 2860 | | | | | | 2861 | TEARDOWN | C -> S | P,S | required | required | 2862 | | | | | | 2863 | | S -> C | P | required | required | 2864 +---------------+-----------+--------+-------------+-------------+ 2866 Table 7: Overview of RTSP methods, their direction, and what objects 2867 (P: presentation, S: stream) they operate on. Further it indicates if 2868 a server or a client implementation are required (mandatory), 2869 recommended or if it is optional to implement the method. 2871 Note on Table 7: GET_PARAMETER is optional. For example, a fully 2872 functional server can be built to deliver media without any 2873 parameters. However, SET_PARAMETER is required, i.e., mandatory 2874 to implement for the server, this is due to its usage for keep- 2875 alive. PAUSE is required because it is the only way of leaving 2876 the Play state without terminating the whole session. 2878 If an RTSP agent does not support a particular method, it MUST return 2879 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2880 NOT try this method again for the given agent / resource combination. 2881 An RTSP proxy whose main function is to log or audit and not modify 2882 transport or media handling in any way MAY forward RTSP messages with 2883 unknown methods. Note that the proxy still needs to perform the 2884 minimal required processing, like adding the Via header. 2886 13.1. OPTIONS 2888 The semantics of the RTSP OPTIONS method is similar to that of the 2889 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2890 bi-directional, in that a client can send the request to a server and 2891 vice versa. A client MUST implement the capability to send an 2892 OPTIONS request and a server or a proxy MUST implement the capability 2893 to respond to an OPTIONS request. In addition to this "MUST 2894 implement" functionality, clients, servers and proxies MAY provide 2895 support both for sending OPTIONS requests and generating responses to 2896 the requests. 2898 An OPTIONS request may be issued at any time. Such a request does 2899 not modify the session state. However, it may prolong the session 2900 lifespan (see below). The URI in an OPTIONS request determines the 2901 scope of the request and the corresponding response. If the Request- 2902 URI refers to a specific media resource on a given host, the scope is 2903 limited to the set of methods supported for that media resource by 2904 the indicated RTSP agent. A Request-URI with only the host address 2905 limits the scope to the specified RTSP agent's general capabilities 2906 without regard to any specific media. If the Request-URI is an 2907 asterisk ("*"), the scope is limited to the general capabilities of 2908 the next hop (i.e., the RTSP agent in direct communication with the 2909 request sender). 2911 Regardless of the scope of the request, the Public header MUST always 2912 be included in the OPTIONS response listing the methods that are 2913 supported by the responding RTSP agent. In addition, if the scope of 2914 the request is limited to a media resource, the Allow header MUST be 2915 included in the response to enumerate the set of methods that are 2916 allowed for that resource unless the set of methods completely 2917 matches the set in the Public header. If the given resource is not 2918 available, the RTSP agent SHOULD return an appropriate response code 2919 such as 3rr or 4xx. The Supported header MAY be included in the 2920 request to query the set of features that are supported by the 2921 responding RTSP agent. 2923 The OPTIONS method can be used to keep an RTSP session alive. 2924 However, this is not the preferred way of session keep-alive 2925 signaling, see Section 18.49. An OPTIONS request intended for 2926 keeping alive an RTSP session MUST include the Session header with 2927 the associated session identifier. Such a request SHOULD also use 2928 the media or the aggregated control URI as the Request-URI. 2930 Example: 2932 C->S: OPTIONS rtsp://server.example.com RTSP/2.0 2933 CSeq: 1 2934 User-Agent: PhonyClient/1.2 2935 Proxy-Require: gzipped-messages 2936 Supported: play.basic 2938 S->C: RTSP/2.0 200 OK 2939 CSeq: 1 2940 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS 2941 Supported: play.basic, setup.rtp.rtcp.mux, play.scale 2942 Server: PhonyServer/1.1 2944 Note that some of the feature-tags in Supported and Proxy-Require are 2945 fictitious features. 2947 13.2. DESCRIBE 2949 The DESCRIBE method is used to retrieve the description of a 2950 presentation or media object from a server. The Request-URI of the 2951 DESCRIBE request identifies the media resource of interest. The 2952 client MAY include the Accept header in the request to list the 2953 description formats that it understands. The server MUST respond 2954 with a description of the requested resource and return the 2955 description in the message body of the response, if the DESCRIBE 2956 method request can be successfully fulfilled. The DESCRIBE reply- 2957 response pair constitutes the media initialization phase of RTSP. 2959 The DESCRIBE response SHOULD contain all media initialization 2960 information for the resource(s) that it describes. Servers SHOULD 2961 NOT use the DESCRIBE response as a means of media indirection by 2962 having the description point at another server; instead, using the 2963 3rr responses is RECOMMENDED. 2965 By forcing a DESCRIBE response to contain all media initialization 2966 information for the set of streams that it describes, and 2967 discouraging the use of DESCRIBE for media indirection, any 2968 looping problems can be avoided that might have resulted from 2969 other approaches. 2971 Example: 2973 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2974 CSeq: 312 2975 User-Agent: PhonyClient/1.2 2976 Accept: application/sdp, application/example 2978 S->C: RTSP/2.0 200 OK 2979 CSeq: 312 2980 Date: Thu, 23 Jan 1997 15:35:06 GMT 2981 Server: PhonyServer/1.1 2982 Content-Base: rtsp://server.example.com/fizzle/foo/ 2983 Content-Type: application/sdp 2984 Content-Length: 358 2986 v=0 2987 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46 2988 s=SDP Seminar 2989 i=A Seminar on the session description protocol 2990 u=http://www.example.com/lectures/sdp.ps 2991 e=seminar@example.com (Seminar Management) 2992 c=IN IP4 0.0.0.0 2993 a=control:* 2994 t=2873397496 2873404696 2995 m=audio 3456 RTP/AVP 0 2996 a=control:audio 2997 m=video 2232 RTP/AVP 31 2998 a=control:video 3000 Media initialization is a requirement for any RTSP-based system, but 3001 the RTSP specification does not dictate that this is required to be 3002 done via the DESCRIBE method. There are three ways that an RTSP 3003 client may receive initialization information: 3005 o via an RTSP DESCRIBE request 3007 o via some other protocol (HTTP, email attachment, etc.) 3009 o via some form of user interface 3011 If a client obtains a valid description from an alternate source, the 3012 client MAY use this description for initialization purposes without 3013 issuing a DESCRIBE request for the same media. The client should use 3014 any MTag to either validate the presentation description or make the 3015 session establishment conditional on being valid. 3017 It is RECOMMENDED that minimal servers support the DESCRIBE method, 3018 and highly recommended that minimal clients support the ability to 3019 act as "helper applications" that accept a media initialization file 3020 from a user interface, and/or other means that are appropriate to the 3021 operating environment of the clients. 3023 13.3. SETUP 3025 The description below uses the following states in a protocol state 3026 machine that is related to a specific session when that session has 3027 been created. The state transitions are driven by protocol 3028 interactions. For additional information about the state machine see 3029 Appendix B. 3031 Init: Initial state: no session exists. 3033 Ready: Session is ready to start playing. 3035 Play: Session is playing, i.e., sending media stream data in the 3036 direction S->C. 3038 The SETUP request for a URI specifies the transport mechanism to be 3039 used for the streamed media. The SETUP method may be used in two 3040 different cases; Create an RTSP session and change the transport 3041 parameters of already set up media stream(s). SETUP can be used in 3042 all three states; Init, and Ready, for both purposes and in PLAY to 3043 change the transport parameters. There is also a third possible 3044 usage for the SETUP method which is not specified in this memo: 3045 adding a media to a session. Using SETUP to add media to an existing 3046 session, when the session is in Play state, is unspecified. 3048 The Transport header, see Section 18.54, specifies the media 3049 transport parameters acceptable to the client for data transmission; 3050 the response will contain the transport parameters selected by the 3051 server. This allows the client to enumerate in descending order of 3052 preference the transport mechanisms and parameters acceptable to it, 3053 while the server can select the most appropriate. It is expected 3054 that the session description format used will enable the client to 3055 select a limited number of possible configurations that are offered 3056 to the server to choose from. All transport related parameters SHALL 3057 be included in the Transport header; the use of other headers for 3058 this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls 3059 or NATs. 3061 For the benefit of any intervening firewalls, a client MUST indicate 3062 the known transport parameters, even if it has no influence over 3063 these parameters, for example, where the server advertises a fixed 3064 multicast address as destination. 3066 Since SETUP includes all transport initialization information, 3067 firewalls and other intermediate network devices (which need this 3068 information) are spared the more arduous task of parsing the 3069 DESCRIBE response, which has been reserved for media 3070 initialization. 3072 The client MUST include the Accept-Ranges header in the request 3073 indicating all supported unit formats in the Range header. This 3074 allows the server to know which formats it may use in future session 3075 related responses, such as a PLAY response without any range in the 3076 request. If the client does not support a time format necessary for 3077 the presentation, the server MUST respond using 456 (Header Field Not 3078 Valid for Resource) and include the Accept-Ranges header with the 3079 range unit formats supported for the resource. 3081 In a SETUP response the server MUST include the Accept-Ranges header 3082 (see Section 18.5) to indicate which time formats are acceptable to 3083 use for this media resource. 3085 The SETUP response 200 OK MUST include the Media-Properties header 3086 (see Section 18.29 ). The combination of the parameters of the 3087 Media-Properties header indicates the nature of the content present 3088 in the session (see also Section 4.7). For example, a live stream 3089 with time shifting is indicated by 3091 o Random Access set to Random-Access, 3093 o Content Modifications set to Time Progressing, 3095 o Retention set to Time-Duration (with specific recording window 3096 time value). 3098 The SETUP response 200 OK MUST include the Media-Range header (see 3099 Section 18.30) if the media is Time-Progressing. 3101 A basic example for SETUP: 3103 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 3104 CSeq: 302 3105 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 3106 RTP/AVP/TCP;unicast;interleaved=0-1 3107 Accept-Ranges: npt, clock 3108 User-Agent: PhonyClient/1.2 3110 S->C: RTSP/2.0 200 OK 3111 CSeq: 302 3112 Date: Thu, 23 Jan 1997 15:35:06 GMT 3113 Server: PhonyServer/1.1 3114 Session: 47112344;timeout=60 3115 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ 3116 "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ 3117 "198.51.100.241:6257"; ssrc=2A3F93ED 3118 Accept-Ranges: npt 3119 Media-Properties: Random-Access=3.2, Time-Progressing, 3120 Time-Duration=3600.0 3121 Media-Range: npt=0-2893.23 3123 In the above example the client wants to create an RTSP session 3124 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 3125 The transport parameters acceptable to the client are either RTP/AVP/ 3126 UDP (UDP per default) to be received on client port 4588 and 4589 at 3127 the address the RTSP setup connection comes from or RTP/AVP 3128 interleaved on the RTSP control channel. The server selects the RTP/ 3129 AVP/UDP transport and adds the address and ports it will send and 3130 receive RTP and RTCP from, and the RTP SSRC that will be used by the 3131 server. 3133 The server MUST generate a session identifier in response to a 3134 successful SETUP request, unless a SETUP request to a server includes 3135 a session identifier or a Pipelined-Requests header referencing an 3136 existing session context, in which case the server MUST bundle this 3137 SETUP request into the existing session (aggregated session) or 3138 return error 459 (Aggregate Operation Not Allowed) (see 3139 Section 17.4.24). An Aggregate control URI MUST be used to control 3140 an aggregated session. This URI MUST be different from the stream 3141 control URIs of the individual media streams included in the 3142 aggregate (see Section 13.4.2 for aggregated sessions and for the 3143 particular URIs see Appendix D.1.1). The Aggregate control URI is to 3144 be specified by the session description if the server supports 3145 aggregated control and aggregated control is desired for the session. 3146 However, even if aggregated control is offered the client MAY chose 3147 to not set up the session in aggregated control. If an Aggregate 3148 control URI is not specified in the session description, it is 3149 normally an indication that non-aggregated control should be used. 3150 The SETUP of media streams in an aggregate which has not been given 3151 an aggregated control URI is unspecified. 3153 While the session ID sometimes carries enough information for 3154 aggregate control of a session, the Aggregate control URI is still 3155 important for some methods such as SET_PARAMETER where the control 3156 URI enables the resource in question to be easily identified. The 3157 Aggregate control URI is also useful for proxies, enabling them to 3158 route the request to the appropriate server, and for logging, 3159 where it is useful to note the actual resource that a request was 3160 operating on. 3162 A session will exist until it is either removed by a TEARDOWN request 3163 or is timed-out by the server. The server MAY remove a session that 3164 has not demonstrated liveness signs from the client(s) within a 3165 certain timeout period. The default timeout value is 60 seconds; the 3166 server MAY set this to a different value and indicate so in the 3167 timeout field of the Session header in the SETUP response. For 3168 further discussion see Section 18.49. Signs of liveness for an RTSP 3169 session are: 3171 o Any RTSP request from a client which includes a Session header 3172 with that session's ID. 3174 o If RTP is used as a transport for the underlying media streams, an 3175 RTCP sender or receiver report from the client(s) for any of the 3176 media streams in that RTSP session. RTCP Sender Reports may for 3177 example be received in sessions where the server is invited into a 3178 conference session and is valid for keep-alive. 3180 If a SETUP request on a session fails for any reason, the session 3181 state, as well as transport and other parameters for associated 3182 streams MUST remain unchanged from their values as if the SETUP 3183 request had never been received by the server. 3185 13.3.1. Changing Transport Parameters 3187 A client MAY issue a SETUP request for a stream that is already set 3188 up or playing in the session to change transport parameters, which a 3189 server MAY allow. If it does not allow changing of parameters, it 3190 MUST respond with error 455 (Method Not Valid In This State). The 3191 reasons to support changing transport parameters include allowing 3192 application layer mobility and flexibility to utilize the best 3193 available transport as it becomes available. If a client receives a 3194 455 when trying to change transport parameters while the server is in 3195 Play state, it MAY try to put the server in Ready state using PAUSE, 3196 before issuing the SETUP request again. If that also fails the 3197 changing of transport parameters will require that the client 3198 performs a TEARDOWN of the affected media and then to set it up 3199 again. For an aggregated session avoiding tearing down all the media 3200 at the same time will avoid the creation of a new session. 3202 All transport parameters MAY be changed. However, the primary usage 3203 expected is to either change the transport protocol completely, like 3204 switching from Interleaved TCP mode to UDP or vice versa, or to 3205 change the delivery address. 3207 In a SETUP response for a request to change the transport parameters 3208 while in Play state, the server MUST include the Range to indicate at 3209 what point the new transport parameters will be used. Further, if 3210 RTP is used for delivery, the server MUST also include the RTP-Info 3211 header to indicate at what timestamp and RTP sequence number the 3212 change will take place. If both RTP-Info and Range are included in 3213 the response the "rtp_time" parameter and start point in the Range 3214 header MUST be for the corresponding time, i.e., be used in the same 3215 way as for PLAY to ensure the correct synchronization information is 3216 available. 3218 If the transport parameters change while in Play state results in a 3219 change of synchronization related information, for example changing 3220 RTP SSRC, the server MUST provide in the SETUP response the necessary 3221 synchronization information. However, the server is RECOMMENDED to 3222 avoid changing the synchronization information if possible. 3224 13.4. PLAY 3226 This section describes the usage of the PLAY method in general, for 3227 aggregated sessions, and in different usage scenarios. 3229 13.4.1. General Usage 3231 The PLAY method tells the server to start sending data via the 3232 mechanism specified in SETUP and which part of the media should be 3233 played out. PLAY requests are valid when the session is in Ready or 3234 Play states. A PLAY request MUST include a Session header to 3235 indicate which session the request applies to. 3237 Upon receipt of the PLAY request, the server MUST position the normal 3238 play time to the beginning of the range specified in the received 3239 Range header, within the limits of the media resource and in 3240 accordance with the Seek-Style header (Section 18.47) and deliver 3241 stream data until the end of the range if given, until a new PLAY 3242 request is received, or until the end of the media is reached. If no 3243 Range header is present in the PLAY request the server SHALL play 3244 from current pause point until the end of media. The pause point 3245 defaults at session start to the beginning of the media. For media 3246 that is time-progressing and has no retention, the pause point will 3247 always be set equal to NPT "now", i.e., the current delivery point. 3248 The pause point may also be set to a particular point in the media by 3249 the PAUSE method, see Section 13.6. The pause point for media that 3250 is currently playing is equal to the current media position. For 3251 time-progressing media with time-limited retention, if the pause 3252 point represents a position that is older than what is retained by 3253 the server, the pause point will be moved to the oldest retained. 3255 What range values are valid depends on the type of content. For 3256 content that isn't time progressing the range value is valid if the 3257 given range is part of any media within the aggregate. In other 3258 words the valid media range for the aggregate is the union of all of 3259 the media components in the aggregate. If a given range value points 3260 outside of the media, the response MUST be the 457 (Invalid Range) 3261 error code and include the Media-Range header (Section 18.30) with 3262 the valid range for the media. Except for time progressing content 3263 where the client requests a start point prior to what is retained, 3264 the start point is adjusted to the oldest retained content. For a 3265 start point that is beyond the media front edge, i.e., beyond the 3266 current value for "now", the server SHALL adjust the start value to 3267 the current front edge. The Range header's stop point value may 3268 point beyond the current media edge. In that case, the server SHALL 3269 deliver media from the requested (and possibly adjusted) start point 3270 until the provided stop point, or the end of the media is reached 3271 prior to the specified stop point. Please note that if one simply 3272 wants to play from a particular start point until the end of media 3273 using a Range header with an implicit stop point is RECOMMENDED. 3275 If a client requests to start playing at the end of media, either 3276 explicitly with a Range header or implicitly with a pause point that 3277 is at the end of media, a 457 (Invalid Range) error MUST be sent and 3278 include the Media-Range header (Section 18.30). It is specified 3279 below that the Range header also must be included in the response and 3280 that it will carry the pause point in the media, in the case of the 3281 session being in Ready State. Note that this also applies if the 3282 pause point or requested start point is at the beginning of the media 3283 and a Scale header (Section 18.46) is included with a negative value 3284 (playing backwards). 3286 For media with random access properties a client may express its 3287 preference on which policy for start point selection the server shall 3288 use. This is done by including the Seek-Style header (Section 18.47) 3289 in the PLAY request. The Seek-Style applied will effect the content 3290 of the Range header as it will be adjusted to indicate from what 3291 point the media actually is delivered. 3293 A client desiring to play the media from the beginning MUST send a 3294 PLAY request with a Range header pointing at the beginning, e.g., 3295 "npt=0-". If a PLAY request is received without a Range header and 3296 media delivery has stopped at the end, the server SHOULD respond with 3297 a 457 "Invalid Range" error response. In that response, the current 3298 pause point MUST be included in a Range header. 3300 All range specifiers in this specification allow for ranges with an 3301 implicit start point (e.g., "npt=-30"). When used in a PLAY request, 3302 the server treats this as a request to start or resume delivery from 3303 the current pause point, ending at the end time specified in the 3304 Range header. If the pause point is located later than the given end 3305 value, a 457 (Invalid Range) response MUST be given. 3307 The example below will play seconds 10 through 25. It also requests 3308 the server to deliver media from the first Random Access Point prior 3309 to the indicated start point. 3311 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 3312 CSeq: 835 3313 Session: 12345678 3314 Range: npt=10-25 3315 Seek-Style: RAP 3316 User-Agent: PhonyClient/1.2 3318 Servers MUST include a "Range" header in any PLAY response, even if 3319 no Range header was present in the request. The response MUST use 3320 the same format as the request's range header contained. If no Range 3321 header was in the request, the format used in any previous PLAY 3322 request within the session SHOULD be used. If no format has been 3323 indicated in a previous request the server MAY use any time format 3324 supported by the media and indicated in the Accept-Ranges header in 3325 the SETUP request. It is RECOMMENDED that NPT is used if supported 3326 by the media. 3328 For any error response to a PLAY request, the server's response 3329 depends on the current session state. If the session is in Ready 3330 state, the current pause-point is returned using Range header with 3331 the pause point as the explicit start-point and an implicit stop- 3332 point. For time-progressing content where the pause-point moves with 3333 real-time due to limited retention, the current pause point is 3334 returned. For sessions in Play state, the current playout point and 3335 the remaining parts of the range request is returned. For any media 3336 with retention longer than 0 seconds the currently valid Media-Range 3337 header SHALL also be included in the response. 3339 A PLAY response MAY include a header carrying synchronization 3340 information. As the information necessary is dependent on the media 3341 transport format, further rules specifying the header and its usage 3342 are needed. For RTP the RTP-Info header is specified, see 3343 Section 18.45, and used in the following example. 3345 Here is a simple example for a single audio stream where the client 3346 requests the media starting from 3.52 seconds and to the end. The 3347 server sends a 200 OK response with the actual play time which is 10 3348 ms prior (3.51) and the RTP-Info header that contains the necessary 3349 parameters for the RTP stack. 3351 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3352 CSeq: 836 3353 Session: 12345678 3354 Range: npt=3.52- 3355 User-Agent: PhonyClient/1.2 3357 S->C: RTSP/2.0 200 OK 3358 CSeq: 836 3359 Date: Thu, 23 Jan 1997 15:35:06 GMT 3360 Server: PhonyServer/1.0 3361 Range: npt=3.51-324.39 3362 Seek-Style: First-Prior 3363 RTP-Info:url="rtsp://example.com/audio" 3364 ssrc=0D12F123:seq=14783;rtptime=2345962545 3366 S->C: RTP Packet TS=2345962545 => NPT=3.51 3367 Media duration=0.16 seconds 3369 The server replies with the actual start point that will be 3370 delivered. This may differ from the requested range if alignment of 3371 the requested range to valid frame boundaries is required for the 3372 media source. Note that some media streams in an aggregate may need 3373 to be delivered from even earlier points. Also, some media formats 3374 have a very long duration per individual data unit, therefore it 3375 might be necessary for the client to parse the data unit, and select 3376 where to start. The server SHALL also indicate which policy it uses 3377 for selecting the actual start point by including a Seek-Style 3378 header. 3380 In the following example the client receives the first media packet 3381 that stretches all the way up and past the requested playtime. Thus, 3382 it is the client's decision whether to render to the user the time 3383 between 3.52 and 7.05, or to skip it. In most cases it is probably 3384 most suitable not to render that time period. 3386 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3387 CSeq: 836 3388 Session: 12345678 3389 Range: npt=7.05- 3390 User-Agent: PhonyClient/1.2 3392 S->C: RTSP/2.0 200 OK 3393 CSeq: 836 3394 Date: Thu, 23 Jan 1997 15:35:06 GMT 3395 Server: PhonyServer/1.0 3396 Range: npt=3.52- 3397 Seek-Style: First-Prior 3398 RTP-Info:url="rtsp://example.com/audio" 3399 ssrc=0D12F123:seq=14783;rtptime=2345962545 3401 S->C: RTP Packet TS=2345962545 => NPT=3.52 3402 Duration=4.15 seconds 3404 After playing the desired range, the presentation does NOT change to 3405 the Ready state, media delivery simply stops. A PAUSE request MUST 3406 be issued to make the stream enter the Ready state. A PLAY request 3407 while the stream is still in the Play state is legal, and can be 3408 issued without an intervening PAUSE request. Such a request MUST 3409 replace the current PLAY action with the new one requested, i.e., 3410 being handled in the same way as if as the request was received in 3411 Ready state. In the case that the range in Range header has an 3412 implicit start time ("-endtime"), the server MUST continue to play 3413 from where it currently was until the specified end point. This is 3414 useful to change the end to at another point than in the previous 3415 request. 3417 The following example plays the whole presentation starting at SMPTE 3418 time code 0:10:20 until the end of the clip. Note: The RTP-Info 3419 headers has been broken into several lines, where following lines 3420 start with whitespace as allowed by the syntax. 3422 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 3423 CSeq: 833 3424 Session: 12345678 3425 Range: smpte=0:10:20- 3426 User-Agent: PhonyClient/1.2 3428 S->C: RTSP/2.0 200 OK 3429 CSeq: 833 3430 Date: Thu, 23 Jan 1997 15:35:06 GMT 3431 Session: 12345678 3432 Server: PhonyServer/1.0 3433 Range: smpte=0:10:22-0:15:45 3434 Seek-Style: Next 3435 RTP-Info:url="rtsp://example.com/twister.en" 3436 ssrc=0D12F123:seq=14783;rtptime=2345962545 3438 For playing back a recording of a live presentation, it may be 3439 desirable to use clock units: 3441 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 3442 CSeq: 835 3443 Session: 12345678 3444 Range: clock=19961108T142300Z-19961108T143520Z 3445 User-Agent: PhonyClient/1.2 3447 S->C: RTSP/2.0 200 OK 3448 CSeq: 835 3449 Date: Thu, 23 Jan 1997 15:35:06 GMT 3450 Session: 12345678 3451 Server: PhonyServer/1.0 3452 Range: clock=19961108T142300Z-19961108T143520Z 3453 Seek-Style: Next 3454 RTP-Info:url="rtsp://example.com/meeting.en" 3455 ssrc=0D12F123:seq=53745;rtptime=484589019 3457 13.4.2. Aggregated Sessions 3459 PLAY requests can operate on sessions controlling a single media and 3460 on aggregated sessions controlling multiple media. 3462 In an aggregated session the PLAY request MUST contain an aggregated 3463 control URI. A server MUST respond with error 460 (Only Aggregate 3464 Operation Allowed) if the client PLAY Request-URI is for a single 3465 media. The media in an aggregate MUST be played in sync. If a 3466 client wants individual control of the media, it needs to use 3467 separate RTSP sessions for each media. 3469 For aggregated sessions where the initial SETUP request (creating a 3470 session) is followed by one or more additional SETUP requests, a PLAY 3471 request MAY be pipelined after those additional SETUP requests 3472 without awaiting their responses. This procedure can reduce the 3473 delay from start of session establishment until media play-out has 3474 started with one round trip time. However, a client needs to be 3475 aware that using this procedure will result in the playout of the 3476 server state established at the time of processing the PLAY, i.e., 3477 after the processing of all the requests prior to the PLAY request in 3478 the pipeline. This state may not be the intended one due to failure 3479 of any of the prior requests. A client can easily determine this 3480 based on the responses from those requests. In case of failure, the 3481 client can halt the media playout using PAUSE and try to establish 3482 the intended state again before issuing another PLAY request. 3484 13.4.3. Updating current PLAY Requests 3486 Clients can issue PLAY requests while the stream is in Play state and 3487 thus updating their request. 3489 The important difference compared to a PLAY request in Ready state is 3490 the handling of the current play point and how the Range header in 3491 the request is constructed. The session is actively playing media 3492 and the play point will be moving, making the exact time a request 3493 will take effect hard to predict. Depending on how the PLAY header 3494 appears two different cases exist: total replacement or continuation. 3495 A total replacement is signaled by having the first range 3496 specification have an explicit start value, e.g., "npt=45-" or 3497 "npt=45-60", in which case the server stops playout at the current 3498 playout point and then starts delivering media according to the Range 3499 header. This is equivalent to having the client first send a PAUSE 3500 and then a new PLAY request that isn't based on the pause point. In 3501 the case of continuation the first range specifier has an implicit 3502 start point and an explicit stop value (Z), e.g., "npt=-60", which 3503 indicate that it MUST convert the range specifier being played prior 3504 to this PLAY request (X to Y) into (X to Z) and continue as this was 3505 the request originally played. If the current delivery point is 3506 beyond the stop point, the server SHALL immediately pause delivery. 3507 As the request has been completed successfully it shall be responded 3508 with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to 3509 indicate the actual stop point. The pause point is set to the 3510 requested stop point. 3512 Following is an example of this behavior: The server has received 3513 requests to play ranges 10 to 15. If the new PLAY request arrives at 3514 the server 4 seconds after the previous one, it will take effect 3515 while the server still plays the first range (10-15). The server 3516 changes the current play to continue to 25 seconds, i.e., the 3517 equivalent single request would be PLAY with "range: npt=10-25". 3519 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3520 CSeq: 834 3521 Session: 12345678 3522 Range: npt=10-15 3523 User-Agent: PhonyClient/1.2 3525 S->C: RTSP/2.0 200 OK 3526 CSeq: 834 3527 Date: Thu, 23 Jan 1997 15:35:06 GMT 3528 Session: 12345678 3529 Server: PhonyServer/1.0 3530 Range: npt=10-15 3531 Seek-Style: Next 3532 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3533 ssrc=0D12F123:seq=5712;rtptime=934207921, 3534 url="rtsp://example.com/fizzle/videotrack" 3535 ssrc=789DAF12:seq=57654;rtptime=2792482193 3536 Session: 12345678 3538 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3539 CSeq: 835 3540 Session: 12345678 3541 Range: npt=-25 3542 User-Agent: PhonyClient/1.2 3544 S->C: RTSP/2.0 200 OK 3545 CSeq: 835 3546 Date: Thu, 23 Jan 1997 15:35:09 GMT 3547 Session: 12345678 3548 Server: PhonyServer/1.0 3549 Range: npt=14-25 3550 Seek-Style: Next 3551 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3552 ssrc=0D12F123:seq=5712;rtptime=934239921, 3553 url="rtsp://example.com/fizzle/videotrack" 3554 ssrc=789DAF12:seq=57654;rtptime=2792842193 3556 A common use of a PLAY request while in Play state is changing the 3557 scale of the media, i.e., entering or leaving fast forward or fast 3558 rewind. The client can issue an updating PLAY request that is either 3559 a continuation or a complete replacement, as discussed above this 3560 section. We give an example of a client that is requesting a fast 3561 forward (scale=2) without giving a stop point and then change from 3562 fast forward to regular playout (scale = 1). In the second PLAY 3563 request the time is set explicitly to be where ever the server 3564 currently plays out (npt=now-) and the server responds with the 3565 actual playback point where the new scale actually takes effect 3566 (npt=2:17:27.144-). 3568 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3569 CSeq: 2034 3570 Session: 12345678 3571 Range: npt=now- 3572 Scale: 2.0 3573 User-Agent: PhonyClient/1.2 3575 S->C: RTSP/2.0 200 OK 3576 CSeq: 2034 3577 Date: Thu, 23 Jan 1997 15:35:06 GMT 3578 Session: 12345678 3579 Server: PhonyServer/1.0 3580 Range: npt=2:17:21.394- 3581 Seek-Style: Next 3582 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3583 ssrc=0D12F123:seq=5712;rtptime=934207921, 3584 url="rtsp://example.com/fizzle/videotrack" 3585 ssrc=789DAF12:seq=57654;rtptime=2792482193 3587 [playing in fast forward and now returning to scale = 1] 3589 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3590 CSeq: 2035 3591 Session: 12345678 3592 Range: npt=now- 3593 Scale: 1.0 3594 User-Agent: PhonyClient/1.2 3596 S->C: RTSP/2.0 200 OK 3597 CSeq: 2035 3598 Date: Thu, 23 Jan 1997 15:35:09 GMT 3599 Session: 12345678 3600 Server: PhonyServer/1.0 3601 Range: npt=2:17:27.144- 3602 Seek-Style: Next 3603 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3604 ssrc=0D12F123:seq=5712;rtptime=934239921, 3605 url="rtsp://example.com/fizzle/videotrack" 3606 ssrc=789DAF12:seq=57654;rtptime=2792842193 3608 13.4.4. Playing On-Demand Media 3610 On-demand media is indicated by the content of the Media-Properties 3611 header in the SETUP response by (see also Section 18.29): 3613 o Random Access property is set to Random-Access; 3614 o Content Modifications set to Immutable; 3616 o Retention set to Unlimited or Time-Limited. 3618 Playing on-demand media follows the general usage as described in 3619 Section 13.4.1. 3621 13.4.5. Playing Dynamic On-Demand Media 3623 Dynamic on-demand media is indicated by the content of the Media- 3624 Properties header in the SETUP response by (see also Section 18.29): 3626 o Random Access set to Random-Access; 3628 o Content Modifications set to Dynamic; 3630 o Retention set to Unlimited or Time-Limited. 3632 Playing on-demand media follows the general usage as described in 3633 Section 13.4.1 as long as the media has not been changed. 3635 There are two ways for the client to be informed about changes of 3636 media resources in Play state. The client will receive a PLAY_NOTIFY 3637 request with Notify-Reason header set to media-properties-update (see 3638 Section 13.5.2. The client can use the value of the Media-Range to 3639 decide further actions, if the Media-Range header is present in the 3640 PLAY_NOTIFY request. The second way is that the client issues a 3641 GET_PARAMETER request without a body but including a Media-Range 3642 header. The 200 OK response MUST include the current Media-Range 3643 header (see Section 18.30). 3645 13.4.6. Playing Live Media 3647 Live media is indicated by the content of the Media-Properties header 3648 in the SETUP response by (see also Section 18.29): 3650 o Random-Access set to No-Seeking; 3652 o Content Modifications set to Time-Progressing; 3654 o Retention with Time-Duration set to 0.0. 3656 For live media, the SETUP response 200 OK MUST include the Media- 3657 Range header (see Section 18.30). 3659 A client MAY send PLAY requests without the Range header. If the 3660 request includes the Range header it MUST use a symbolic value 3661 representing "now". For NPT that range specification is "npt=now-". 3663 The server MUST include the Range header in the response and it MUST 3664 indicate an explicit time value and not a symbolic value. In other 3665 words, "npt=now-" is not valid to be used in the response. Instead 3666 the time since session start is recommended expressed as an open 3667 interval, e.g., "npt=96.23-". An absolute time value (clock) for the 3668 corresponding time MAY be given, i.e., "clock=20030213T143205Z-". 3669 The Absolute Time format can only be used if client has shown support 3670 for it using the Accept-Ranges header. 3672 13.4.7. Playing Live with Recording 3674 Certain media servers may offer recording services of live sessions 3675 to their clients. This recording would normally be from the 3676 beginning of the media session. Clients can randomly access the 3677 media between now and the beginning of the media session. This live 3678 media with recording is indicated by the content of the Media- 3679 Properties header in the SETUP response by (see also Section 18.29): 3681 o Random Access set to Random-Access; 3683 o Content Modifications set to Time-Progressing; 3685 o Retention set to Time-Limited or Unlimited 3687 The SETUP response 200 OK MUST include the Media-Range header (see 3688 Section 18.30) for this type of media. For live media with 3689 recording, the Range header indicates the current delivery point in 3690 the media and the Media-Range header indicates the currently 3691 available media window around the current time. This window can 3692 cover recorded content in the past (seen from current time in the 3693 media) or recorded content in the future (seen from current time in 3694 the media). The server adjusts the delivery point to the requested 3695 border of the window. If the client requests a delivery point that 3696 is located outside the recording window, e.g., if the requested point 3697 is too far in the past, the server selects the oldest point in the 3698 recording. The considerations in Section 13.5.3 apply if a client 3699 requests delivery with Scale (Section 18.46) values other than 1.0 3700 (Normal playback rate) while delivering live media with recording. 3702 13.4.8. Playing Live with Time-Shift 3704 Certain media servers may offer time-shift services to their clients. 3705 This time shift records a fixed interval in the past, i.e., a sliding 3706 window recording mechanism, but not past this interval. Clients can 3707 randomly access the media between now and the interval. This live 3708 media with recording is indicated by the content of the Media- 3709 Properties header in the SETUP response by (see also Section 18.29): 3711 o Random Access set to Random-Access; 3713 o Content Modifications set to Time-Progressing; 3715 o Retention set to Time-Duration and a value indicating the 3716 recording interval (>0). 3718 The SETUP response 200 OK MUST include the Media-Range header (see 3719 Section 18.30) for this type of media. For live media with recording 3720 the Range header indicates the current time in the media and the 3721 Media Range indicates a window around the current time. This window 3722 can cover recorded content in the past (seen from current time in the 3723 media) or recorded content in the future (seen from current time in 3724 the media). The server adjusts the play point to the requested 3725 border of the window, if the client requests a play point that is 3726 located outside the recording windows, e.g., if requested too far in 3727 the past, the server selects the oldest range in the recording. The 3728 considerations in Section 13.5.3 apply, if a client requests delivery 3729 using a Scale (Section 18.46) value other than 1.0 (Normal playback 3730 rate) while delivering live media with time-shift. 3732 13.5. PLAY_NOTIFY 3734 The PLAY_NOTIFY method is issued by a server to inform a client about 3735 an asynchronous event for a session in Play state. The Session 3736 header MUST be presented in a PLAY_NOTIFY request and indicates the 3737 scope of the request. Sending of PLAY_NOTIFY requests requires a 3738 persistent connection between server and client, otherwise there is 3739 no way for the server to send this request method to the client. 3741 PLAY_NOTIFY requests have an end-to-end (i.e., server to client) 3742 scope, as they carry the Session header, and apply only to the given 3743 session. The client SHOULD immediately return a response to the 3744 server. 3746 PLAY_NOTIFY requests MAY use both aggregate control URI and 3747 individual media resource URIs depending on the scope of the 3748 notification. This scope may have important distinctions for 3749 aggregated sessions, and each reason for a PLAY_NOTIFY request needs 3750 to specify the interpretation and if aggregated control URIs or 3751 individual URIs may be used in requests. 3753 PLAY_NOTIFY requests MAY be used with a message body, depending on 3754 the value of the Notify-Reason header. It is described in the 3755 particular section for each Notify-Reason if a message body is used. 3756 However, currently there is no Notify-Reason that allows using a 3757 message body. In this case, there is a need to obey some limitations 3758 when adding new Notify-Reasons that intend to use a message body: the 3759 server can send any type of message body, but it is not ensured that 3760 the client can understand the received message body. This is related 3761 to DESCRIBE (see Section 13.2 ), but in this particular case the 3762 client can state its acceptable message bodies by using the Accept 3763 header. In the case of PLAY_NOTIFY, the server does not know which 3764 message bodies are understood by the client. 3766 The Notify-Reason header (see Section 18.32) specifies the reason why 3767 the server sends the PLAY_NOTIFY request. This is extensible and new 3768 reasons MAY be added in the future (see Section 22.8). In case the 3769 client does not understand the reason for the notification it MUST 3770 respond with a 465 (Notification Reason Unknown) (Section 17.4.30) 3771 error code. Servers can send PLAY_NOTIFY with these types: 3773 o end-of-stream (see Section 13.5.1); 3775 o media-properties-update (see Section 13.5.2); 3777 o scale-change (see Section 13.5.3). 3779 13.5.1. End-of-Stream 3781 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3782 indicates the completion or near completion of the PLAY request and 3783 the ending delivery of the media stream(s). The request MUST NOT be 3784 issued unless the server is in the Play state. The end of the media 3785 stream delivery notification may be used to indicate either a 3786 successful completion of the PLAY request currently being served, or 3787 to indicate some error resulting in failure to complete the request. 3788 The Request-Status header (Section 18.42) MUST be included to 3789 indicate which request the notification is for and its completion 3790 status. The message response status codes (Section 8.1.1) are used 3791 to indicate how the PLAY request concluded. The sender of a 3792 PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a 3793 PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY 3794 was issued before reaching the end-of-stream, but some error occurred 3795 resulting in that the previously sent PLAY_NOTIFY contained a wrong 3796 time when the stream will end. In this case a new PLAY_NOTIFY MUST 3797 be sent including the correct status for the completion and all 3798 additional information. 3800 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream 3801 MUST include a Range header and the Scale header if the scale value 3802 is not 1. The Range header indicates the point in the stream or 3803 streams where delivery is ending with the timescale that was used by 3804 the server in the PLAY response for the request being fulfilled. The 3805 server MUST NOT use the "now" constant in the Range header; it MUST 3806 use the actual numeric end position in the proper timescale. When 3807 end-of-stream notifications are issued prior to having sent the last 3808 media packets, this is evident as the end time in the Range header is 3809 beyond the current time in the media being received by the client, 3810 e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale 3811 header is to be included so that it is evident if the media time 3812 scale is moving backwards and/or have a non-default pace. The end- 3813 of-stream notification does not prevent the client from sending a new 3814 PLAY request. 3816 If RTP is used as media transport, a RTP-Info header MUST be 3817 included, and the RTP-Info header MUST indicate the last sequence 3818 number in the seq parameter. 3820 For an RTSP Session where media resources are under aggregated 3821 control the media resources will normally end at approximately the 3822 same time, although some small differences may exist, on the scale of 3823 a few hundred of milliseconds. In those cases a RTSP session under 3824 aggregated control SHOULD send only a single PLAY_NOTIFY request. By 3825 using the aggregate control URI in the PLAY_NOTIFY request the RTSP 3826 server indicates that this applies to all media resources within the 3827 session. In cases RTP is used for media delivery corresponding RTP- 3828 Info needs to be included for all media resources. In cases where 3829 one or more media resource has significantly shorter duration than 3830 some other resources in the aggregated session the server MAY send 3831 end-of-stream notifications using individual media resource URIs to 3832 indicate to agents that there will be no more media for this 3833 particular media resource related to the current active PLAY request. 3834 In such cases when the remaining media resources comes to end-of- 3835 stream they MUST send a PLAY_NOTIFY request using the aggregate 3836 control URI to indicate that no more resources remain. 3838 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3839 MUST NOT carry a message body. 3841 This example request notifies the client about a future end-of-stream 3842 event: 3844 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3845 CSeq: 854 3846 Notify-Reason: end-of-stream 3847 Request-Status: cseq=853 status=200 reason="OK" 3848 Range: npt=-145 3849 RTP-Info:url="rtsp://example.com/fizzle/foo/audio" 3850 ssrc=0D12F123:seq=14783;rtptime=2345962545, 3851 url="rtsp://example.com/fizzle/video" 3852 ssrc=789DAF12:seq=57654;rtptime=2792482193 3854 Session: uZ3ci0K+Ld-M 3855 Date: Mon, 08 Mar 2010 13:37:16 GMT 3857 C->S: RTSP/2.0 200 OK 3858 CSeq: 854 3859 User-Agent: PhonyClient/1.2 3860 Session: uZ3ci0K+Ld-M 3862 13.5.2. Media-Properties-Update 3864 A PLAY_NOTIFY request with Notify-Reason header set to media- 3865 properties-update indicates an update of the media properties for the 3866 given session (see Section 18.29) and/or the available media range 3867 that can be played as indicated by Media-Range (Section 18.30). 3868 PLAY_NOTIFY requests with Notify-Reason header set to media- 3869 properties-update MUST include a Media-Properties and Date header and 3870 SHOULD include a Media-Range header. The Media-Properties header has 3871 session scope, thus for aggregated sessions the PLAY_NOTIFY request 3872 MUST be using the aggregated control URI. 3874 This notification MUST be sent for media that are Time-Progressing 3875 every time an event happens that changes the basis for making 3876 estimates on how the available for play-back media range will 3877 progress with wall clock time. In addition it is RECOMMENDED that 3878 the server sends these notifications approximately every 5 minutes 3879 for time-progressing content to ensure the long-term stability of the 3880 client estimation and allowing for clock skew detection by the 3881 client. The time between notifications should be greater than 1 3882 minute and less than 2 hours. For the reasons just explained, 3883 requests MUST include a Media-Range header to provide current Media 3884 duration and a Range header to indicate the current playing point and 3885 any remaining parts of the requested range. 3887 The recommendation for sending updates every 5 minutes is due to 3888 any clock skew issues. In 5 minutes the clock skew should not 3889 become too significant as this is not used for media playback and 3890 synchronization, only for determining which content is available 3891 to the user. 3893 A PLAY_NOTIFY request with Notify-Reason header set to media- 3894 properties-update MUST NOT carry a message body. 3896 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3897 Date: Tue, 14 Apr 2008 15:48:06 GMT 3898 CSeq: 854 3899 Notify-Reason: media-properties-update 3900 Session: uZ3ci0K+Ld-M 3901 Media-Properties: Time-Progressing, 3902 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3903 Media-Range: npt=0-1:37:21.394 3904 Range: npt=1:15:49.873- 3906 C->S: RTSP/2.0 200 OK 3907 CSeq: 854 3908 User-Agent: PhonyClient/1.2 3909 Session: uZ3ci0K+Ld-M 3911 13.5.3. Scale-Change 3913 The server may be forced to change the rate of media time per 3914 playback time when a client requests delivery using a Scale 3915 (Section 18.46) value other than 1.0 (normal playback rate). For 3916 time progressing media with some retention, i.e., the server stores 3917 already sent content, a client requesting to play with Scale values 3918 larger than 1 may catch up with the front end of the media. The 3919 server will then be unable to continue to provide content at Scale 3920 larger than 1 as content is only made available by the server at 3921 Scale=1. Another case is when Scale < 1 and the media retention is 3922 time-duration limited. In this case the delivery point can reach the 3923 oldest media unit available, and further playback at this scale 3924 becomes impossible as there will be no media available. To avoid 3925 having the client lose any media, the scale will need to be adjusted 3926 to the same rate at which the media is removed from the storage 3927 buffer, commonly Scale = 1.0. 3929 Another case is when the content itself consists of spliced pieces or 3930 is dynamically updated. In these cases the server may be required to 3931 change from one supported scale value (different than Scale=1.0) to 3932 another. In this case the server will pick the closest value and 3933 inform the client of what it has picked. In these cases the media 3934 properties will also be sent updating the supported Scale values. 3935 This enables a client to adjust the Scale value used. 3937 To minimize impact on playback in any of the above cases the server 3938 MUST modify the playback properties and set Scale to a supportable 3939 value and continue delivery of the media. When doing this 3940 modification it MUST send a PLAY_NOTIFY message with the Notify- 3941 Reason header set to "scale-change". The request MUST contain a 3942 Range header with the media time when the change took effect, a Scale 3943 header with the new value in use, Session header with the identifier 3944 for the session it applies to and a Date header with the server 3945 wallclock time of the change. For time progressing content also the 3946 Media-Range and the Media-Properties at this point in time MUST be 3947 included. The Media-Properties header MUST be included if the scale 3948 change was due to the content changing what scale values that is 3949 supported. 3951 For media streams being delivered using RTP also a RTP-Info header 3952 MUST be included. It MUST contain the rtptime parameter with a value 3953 corresponding to the point of change in that media and optionally 3954 also the sequence number. 3956 PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated 3957 control URI in the request. The scale change for any aggregated 3958 session applies to all media streams part of the aggregate. 3960 A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" 3961 MUST NOT carry a message body. 3963 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3964 Date: Tue, 14 Apr 2008 15:48:06 GMT 3965 CSeq: 854 3966 Notify-Reason: scale-change 3967 Session: uZ3ci0K+Ld-M 3968 Media-Properties: Time-Progressing, 3969 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3970 Media-Range: npt=0-1:37:21.394 3971 Range: npt=1:37:21.394- 3972 Scale: 1 3973 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" 3974 ssrc=0D12F123:rtptime=2345962545, 3975 url="rtsp://example.com/fizzle/videotrack" 3976 ssrc=789DAF12:seq=57654;rtptime=2792482193 3978 C->S: RTSP/2.0 200 OK 3979 CSeq: 854 3980 User-Agent: PhonyClient/1.2 3981 Session: uZ3ci0K+Ld-M 3983 13.6. PAUSE 3985 The PAUSE request causes the stream delivery to immediately be 3986 interrupted (halted). A PAUSE request MUST be done either with the 3987 aggregated control URI for aggregated sessions, resulting in all 3988 media being halted, or the media URI for non-aggregated sessions. 3990 Any attempt to do muting of a single media with a PAUSE request in an 3991 aggregated session MUST be responded to with error 460 (Only 3992 Aggregate Operation Allowed). After resuming playback, 3993 synchronization of the tracks MUST be maintained. Any server 3994 resources are kept, though servers MAY close the session and free 3995 resources after being paused for the duration specified with the 3996 timeout parameter of the Session header in the SETUP message. 3998 Example: 4000 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4001 CSeq: 834 4002 Session: 12345678 4003 User-Agent: PhonyClient/1.2 4005 S->C: RTSP/2.0 200 OK 4006 CSeq: 834 4007 Date: Thu, 23 Jan 1997 15:35:06 GMT 4008 Range: npt=45.76-75.00 4010 The PAUSE request causes stream delivery to be interrupted 4011 immediately on receipt of the message and the pause point is set to 4012 the current point in the presentation. That pause point in the media 4013 stream needs to be maintained. A subsequent PLAY request without 4014 Range header resumes from the pause point and plays until media end. 4016 The pause point after any PAUSE request MUST be returned to the 4017 client by adding a Range header with what remains unplayed of the 4018 PLAY request's range. For media with random access properties, if 4019 one desires to resume playing a ranged request, one simply includes 4020 the Range header from the PAUSE response and includes the Seek-Style 4021 header with the Next policy in the PLAY request. For media that is 4022 time-progressing and has retention duration=0 the follow-up PLAY 4023 request to start media delivery again, MUST use "npt=now-" and not 4024 the answer given in the response to PAUSE. 4026 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 4027 CSeq: 834 4028 Session: 12345678 4029 Range: npt=10-30 4030 User-Agent: PhonyClient/1.2 4032 S->C: RTSP/2.0 200 OK 4033 CSeq: 834 4034 Date: Thu, 23 Jan 1997 15:35:06 GMT 4035 Server: PhonyServer/1.0 4036 Range: npt=10-30 4037 Seek-Style: First-Prior 4038 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 4039 ssrc=0D12F123:seq=5712;rtptime=934207921, 4040 url="rtsp://example.com/fizzle/videotrack" 4041 ssrc=4FAD8726:seq=57654;rtptime=2792482193 4042 Session: 12345678 4044 After 11 seconds, i.e., at 21 seconds into the presentation: 4045 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4046 CSeq: 835 4047 Session: 12345678 4048 User-Agent: PhonyClient/1.2 4050 S->C: RTSP/2.0 200 OK 4051 CSeq: 835 4052 Date: 23 Jan 1997 15:35:17 GMT 4053 Server: PhonyServer/1.0 4054 Range: npt=21-30 4055 Session: 12345678 4057 If a client issues a PAUSE request and the server acknowledges and 4058 enters the Ready state, the proper server response, if the player 4059 issues another PAUSE, is still 200 OK. The 200 OK response MUST 4060 include the Range header with the current pause point. See examples 4061 below: 4063 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4064 CSeq: 834 4065 Session: 12345678 4066 User-Agent: PhonyClient/1.2 4068 S->C: RTSP/2.0 200 OK 4069 CSeq: 834 4070 Session: 12345678 4071 Date: Thu, 23 Jan 1997 15:35:06 GMT 4072 Range: npt=45.76-98.36 4074 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4075 CSeq: 835 4076 Session: 12345678 4077 User-Agent: PhonyClient/1.2 4079 S->C: RTSP/2.0 200 OK 4080 CSeq: 835 4081 Session: 12345678 4082 Date: 23 Jan 1997 15:35:07 GMT 4083 Range: npt=45.76-98.36 4085 13.7. TEARDOWN 4087 13.7.1. Client to Server 4089 The TEARDOWN client to server request stops the stream delivery for 4090 the given URI, freeing the resources associated with it. A TEARDOWN 4091 request MAY be performed on either an aggregated or a media control 4092 URI. However, some restrictions apply depending on the current 4093 state. The TEARDOWN request MUST contain a Session header indicating 4094 what session the request applies to. The TEARDOWN request MUST NOT 4095 include a Terminate-Reason header. 4097 A TEARDOWN using the aggregated control URI or the media URI in a 4098 session under non-aggregated control (single media session) MAY be 4099 done in any state (Ready and Play). A successful request MUST result 4100 in that media delivery being immediately halted and the session state 4101 being destroyed. This MUST be indicated through the lack of a 4102 Session header in the response. 4104 A TEARDOWN using a media URI in an aggregated session MAY only be 4105 done in Ready state. Such a request only removes the indicated media 4106 stream and associated resources from the session. This may result in 4107 a session returning to non-aggregated control, because it only 4108 contains a single media after the request's completion. A session 4109 that will exist after the processing of the TEARDOWN request MUST in 4110 the response to that TEARDOWN request contain a Session header. Thus 4111 the presence of the Session header indicates to the receiver of the 4112 response if the session is still extant or has been removed. 4114 Example: 4116 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 4117 CSeq: 892 4118 Session: 12345678 4119 User-Agent: PhonyClient/1.2 4121 S->C: RTSP/2.0 200 OK 4122 CSeq: 892 4123 Server: PhonyServer/1.0 4125 13.7.2. Server to Client 4127 The server can send TEARDOWN requests in the server to client 4128 direction to indicate that the server has been forced to terminate 4129 the ongoing session. This may happen for several reasons, such as 4130 server maintenance without available backup, or that the session has 4131 been inactive for extended periods of time. The reason is provided 4132 in the Terminate-Reason header (Section 18.52). 4134 When a RTSP client has maintained a RTSP session that otherwise is 4135 inactive for an extended period of time the server may reclaim the 4136 resources. That is done by issuing a TEARDOWN request with the 4137 Terminate-Reason set to "Session-Timeout". This MAY be done when the 4138 client has been inactive in the RTSP session for more than one 4139 Session Timeout period (Section 18.49). However, the server is 4140 RECOMMENDED to not perform this operation until an extended period of 4141 inactivity of 10 times the Session Timeout period has passed. It is 4142 up to the operator of the RTSP server to actually configure how long 4143 this extended period of inactivity is. An operator should take into 4144 account when doing this configuration what the served content is and 4145 what this means for the extended period of inactivity. 4147 In case the server needs to stop providing service to the established 4148 sessions and there is no server to point at in a REDIRECT request, 4149 then TEARDOWN SHALL be used to terminate the session. This method 4150 can also be used when non-recoverable internal errors have happened 4151 and the server has no other option then to terminate the sessions. 4153 The TEARDOWN request MUST be done only on the session aggregate 4154 control URI (i.e., it is not allowed to terminate individual media 4155 streams, if it is a session aggregate) and MUST include the following 4156 headers; Session and Terminate-Reason headers. The request only 4157 applies to the session identified in the Session header. The server 4158 may include a message to the client's user with the "user-msg" 4159 parameter. 4161 The TEARDOWN request may alternatively be done on the wild card URI * 4162 and without any session header. The scope of such a request is 4163 limited to the next-hop (i.e., the RTSP agent in direct communication 4164 with the server) and applies, as well, to the RTSP connection between 4165 the next-hop RTSP agent and the server. This request indicates that 4166 all sessions and pending requests being managed via the connection 4167 are terminated. Any intervening proxies SHOULD do all of the 4168 following in the order listed: 4170 1. respond to the TEARDOWN request 4172 2. disconnect the control channel from the requesting server 4174 3. pass the TEARDOWN request to each applicable client (typically 4175 those clients with an active session or an unanswered request) 4177 Note: The proxy is responsible for accepting TEARDOWN responses 4178 from its clients; these responses MUST NOT be passed on to either 4179 the original server or the target server in the redirect. 4181 13.8. GET_PARAMETER 4183 The GET_PARAMETER request retrieves the value of any specified 4184 parameter or parameters for a presentation or stream specified in the 4185 URI. If the Session header is present in a request, the value of a 4186 parameter MUST be retrieved in the specified session context. There 4187 are two ways of specifying the parameters to be retrieved. 4189 The first is by including headers which have been defined such that 4190 you can use them for this purpose. Headers for this purpose should 4191 allow empty, or stripped value parts to avoid having to specify bogus 4192 data when indicating the desire to retrieve a value. The successful 4193 completion of the request should also be evident from any filled out 4194 values in the response. The headers in this specification that MAY 4195 be used for retrieving their current value using GET_PARAMETER are 4196 listed below; additional headers MAY be specified in the future: 4198 o Accept-Ranges 4200 o Media-Range 4202 o Media-Properties 4204 o Range 4205 o RTP-Info 4207 The other way is to specify a message body that lists the 4208 parameter(s) that are desired to be retrieved. The Content-Type 4209 header (Section 18.19) is used to specify which format the message 4210 body has. If the receiver of the request does not support the media 4211 type used for the message body, it SHALL respond using the error code 4212 415 (Unsupported Media Type). The responder to a GET_PARAMETER 4213 request MUST use the media type of the request for the response. For 4214 additional considerations regarding message body negotiation see 4215 Section 9.3. 4217 RTSP Agents implementing support for responding to GET_PARAMETER 4218 requests SHALL implement the text/parameters format (Appendix F). 4219 This to ensure that at least one known format for parameters is 4220 implemented and thus prevent parameter format negotiation failure. 4222 Parameters specified within the body of the message must all be 4223 understood by the request receiving agent. If one or more parameters 4224 are not understood a 451 (Parameter Not Understood) MUST be sent 4225 including a body listing these parameters that weren't understood. 4226 If all parameters are understood their values are filled in and 4227 returned in the response message body. 4229 The method MAY also be used without a message body or any header that 4230 requests parameters for keep-alive purpose. The keep-alive timer has 4231 been updated for any request that is successful, i.e., a 200 OK 4232 response is received. Any non-required header present in such a 4233 request may or may not have been processed. Normally the presence of 4234 filled out values in the header will be indication that the header 4235 has been processed. However, for cases when this is difficult to 4236 determine, it is recommended to use a feature-tag and the Require 4237 header. For this reason it is usually easier if any parameters to be 4238 retrieved are sent in the body, rather than using any header. 4240 Example: 4242 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4243 CSeq: 431 4244 User-Agent: PhonyClient/1.2 4245 Session: 12345678 4246 Content-Length: 26 4247 Content-Type: text/parameters 4249 packets_received 4250 jitter 4252 C->S: RTSP/2.0 200 OK 4253 CSeq: 431 4254 Session: 12345678 4255 Server: PhonyServer/1.1 4256 Date: Mon, 08 Mar 2010 13:43:23 GMT 4257 Content-Length: 38 4258 Content-Type: text/parameters 4260 packets_received: 10 4261 jitter: 0.3838 4263 13.9. SET_PARAMETER 4265 This method requests to set the value of a parameter or a set of 4266 parameters for a presentation or stream specified by the URI. The 4267 method MAY also be used without a message body. It is the 4268 RECOMMENDED method to be used in a request sent for the sole purpose 4269 of updating the keep-alive timer. If this request is successful, 4270 i.e., a 200 OK response is received, then the keep-alive timer has 4271 been updated. Any non-required header present in such a request may 4272 or may not have been processed. To allow a client to determine if 4273 any such header has been processed, it is necessary to use a feature 4274 tag and the Require header. Due to this reason it is RECOMMENDED 4275 that any parameters are sent in the body, rather than using any 4276 header. 4278 When using a message body to list the parameter(s) that are desired 4279 to be set the Content-Type header (Section 18.19) is used to specify 4280 which format the message body has. If the receiver of the request is 4281 not supporting the media type used for the message body, it SHALL 4282 respond using the error code 415 (Unsupported Media Type). For 4283 additional considerations regarding message body negotiation see 4284 Section 9.3. 4286 RTSP Agents implementing support for responding to SET_PARAMETER 4287 requests SHALL implement the text/parameters format (Appendix F). 4288 This to ensure that at least one known format for parameters is 4289 implemented and thus prevent parameter format negotiation failure. 4291 A request is RECOMMENDED to only contain a single parameter to allow 4292 the client to determine why a particular request failed. If the 4293 request contains several parameters, the server MUST only act on the 4294 request if all of the parameters can be set successfully. A server 4295 MUST allow a parameter to be set repeatedly to the same value, but it 4296 MAY disallow changing parameter values. If the receiver of the 4297 request does not understand or cannot locate a parameter, error 451 4298 (Parameter Not Understood) MUST be used. When a parameter is not 4299 allowed to change, the error code is 458 (Parameter Is Read-Only). 4300 The response body MUST contain only the parameters that have errors. 4301 Otherwise no body MUST be returned. The response body MUST use the 4302 media type of the request for the response. 4304 Note: transport parameters for the media stream MUST only be set with 4305 the SETUP command. 4307 Restricting setting transport parameters to SETUP is for the 4308 benefit of firewalls. 4310 The parameters are split in a fine-grained fashion so that there 4311 can be more meaningful error indications. However, it may make 4312 sense to allow the setting of several parameters if an atomic 4313 setting is desirable. Imagine device control where the client 4314 does not want the camera to pan unless it can also tilt to the 4315 right angle at the same time. 4317 Example: 4319 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4320 CSeq: 421 4321 User-Agent: PhonyClient/1.2 4322 Session: iixT43KLc 4323 Date: Mon, 08 Mar 2010 14:45:04 GMT 4324 Content-length: 20 4325 Content-type: text/parameters 4327 barparam: barstuff 4329 S->C: RTSP/2.0 451 Parameter Not Understood 4330 CSeq: 421 4331 Session: iixT43KLc 4332 Server: PhonyServer/1.0 4333 Date: Mon, 08 Mar 2010 14:44:56 GMT 4334 Content-length: 20 4335 Content-type: text/parameters 4337 barparam: barstuff 4339 13.10. REDIRECT 4341 The REDIRECT method is issued by a server to inform a client that the 4342 service provided will be terminated and where a corresponding service 4343 can be provided instead. This may happen for different reasons. One 4344 is that the server is being administered such that it must stop 4345 providing service. Thus the client is required to connect to another 4346 server location to access the resource indicated by the Request-URI. 4348 The REDIRECT request SHALL contain a Terminate-Reason header 4349 (Section 18.52) to inform the client of the reason for the request. 4350 Additional parameters related to the reason may also be included. 4351 The intention here is to allow a server administrator to do a 4352 controlled shutdown of the RTSP server. That requires sufficient 4353 time to inform all entities having associated state with the server 4354 and for them to perform a controlled migration from this server to a 4355 fall back server. 4357 A REDIRECT request with a Session header has end-to-end (i.e., server 4358 to client) scope and applies only to the given session. Any 4359 intervening proxies SHOULD NOT disconnect the control channel while 4360 there are other remaining end-to-end sessions. The REQUIRED Location 4361 header MUST contain a complete absolute URI pointing to the resource 4362 to which the client SHOULD reconnect. Specifically, the Location 4363 MUST NOT contain just the host and port. A client may receive a 4364 REDIRECT request with a Session header, if and only if, an end-to-end 4365 session has been established. 4367 A client may receive a REDIRECT request without a Session header at 4368 any time when it has communication or a connection established with a 4369 server. The scope of such a request is limited to the next-hop 4370 (i.e., the RTSP agent in direct communication with the server) and 4371 applies to all sessions controlled, as well as the connection between 4372 the next-hop RTSP agent and the server. A REDIRECT request without a 4373 Session header indicates that all sessions and pending requests being 4374 managed via the connection MUST be redirected. The Location header, 4375 if included in such a request, SHOULD contain an absolute URI with 4376 only the host address and the OPTIONAL port number of the server to 4377 which the RTSP agent SHOULD reconnect. Any intervening proxies 4378 SHOULD do all of the following in the order listed: 4380 1. respond to the REDIRECT request 4382 2. disconnect the control channel from the requesting server 4384 3. connect to the server at the given host address 4385 4. pass the REDIRECT request to each applicable client (typically 4386 those clients with an active session or an unanswered request) 4388 Note: The proxy is responsible for accepting REDIRECT responses 4389 from its clients; these responses MUST NOT be passed on to either 4390 the original server or the redirected server. 4392 When the server lacks any alternative server and needs to terminate a 4393 session or all sessions the TEARDOWN request SHALL be used instead. 4395 When no Terminate-Reason "time" parameter is included in a REDIRECT 4396 request, the client SHALL perform the redirection immediately and 4397 return a response to the server. The server shall consider the 4398 session as terminated and can free any associated state after it 4399 receives the successful (2xx) response. The server MAY close the 4400 signaling connection upon receiving the response and the client 4401 SHOULD close the signaling connection after sending the 2xx response. 4402 The exception to this is when the client has several sessions on the 4403 server being managed by the given signaling connection. In this 4404 case, the client SHOULD close the connection when it has received and 4405 responded to REDIRECT requests for all the sessions managed by the 4406 signaling connection. 4408 The Terminate-Reason header "time" parameter MAY be used to indicate 4409 the wallclock time by when the redirection MUST have taken place. To 4410 allow a client to determine that redirect time without being time 4411 synchronized with the server, the server MUST include a Date header 4412 in the request. The client should have terminated the session and 4413 closed the connection before the redirection time-line terminated. 4414 The server MAY simply cease to provide service when the deadline time 4415 has been reached, or it may issue TEARDOWN requests to the remaining 4416 sessions. 4418 If the REDIRECT request times out following the rules in Section 10.4 4419 the server MAY terminate the session or transport connection that 4420 would be redirected by the request. This is a safeguard against 4421 misbehaving clients that refuse to respond to a REDIRECT request. 4422 Thus, removing any incentive to not acknowledge the reception of a 4423 REDIRECT request. 4425 After a REDIRECT request has been processed, a client that wants to 4426 continue to receive media for the resource identified by the Request- 4427 URI will have to establish a new session with the designated host. 4428 If the URI given in the Location header is a valid resource URI, a 4429 client SHOULD issue a DESCRIBE request for the URI. 4431 Note: The media resource indicated by the Location header can be 4432 identical, slightly different or totally different. This is the 4433 reason why a new DESCRIBE request SHOULD be issued. 4435 If the Location header contains only a host address, the client MAY 4436 assume that the media on the new server is identical to the media on 4437 the old server, i.e., all media configuration information from the 4438 old session is still valid except for the host address. However, the 4439 usage of conditional SETUP using MTag identifiers is RECOMMENDED as a 4440 means to verify the assumption. 4442 This example request redirects traffic for this session to the new 4443 server at the given absolute time: 4445 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 4446 CSeq: 732 4447 Location: rtsp://s2.example.com:8001 4448 Terminate-Reason: Server-Admin ;time=19960213T143205Z 4449 Session: uZ3ci0K+Ld-M 4450 Date: Thu, 13 Feb 1996 14:30:43 GMT 4452 C->S: RTSP/2.0 200 OK 4453 CSeq: 732 4454 User-Agent: PhonyClient/1.2 4455 Session: uZ3ci0K+Ld-M 4457 14. Embedded (Interleaved) Binary Data 4459 In order to fulfill certain requirements on the network side, e.g., 4460 in conjunction with network address translators that block RTP 4461 traffic over UDP, it may be necessary to interleave RTSP messages and 4462 media stream data. This interleaving should generally be avoided 4463 unless necessary since it complicates client and server operation and 4464 imposes additional overhead. Also, head-of-line blocking may cause 4465 problems. Interleaved binary data SHOULD only be used if RTSP is 4466 carried over TCP. Interleaved data is not allowed inside RTSP 4467 messages. 4469 Stream data such as RTP packets is encapsulated by an ASCII dollar 4470 sign (36 decimal), followed by a one-octet channel identifier, 4471 followed by the length of the encapsulated binary data as a binary, 4472 two-octet unsigned integer in network octet order (Appendix B of 4473 [RFC0791]). The stream data follows immediately afterwards, without 4474 a CRLF, but including the upper-layer protocol headers. Each $ block 4475 MUST contain exactly one upper-layer protocol data unit, e.g., one 4476 RTP packet. 4478 Note that this mechanism does not support PDUs larger than 65535 4479 octets, which matches the maximum payload size of regular, non- 4480 jumbo IPv4 and IPv6 packets. If the media delivery protocol 4481 intended to be used has larger PDUs than that, definition of a PDU 4482 fragmentation mechanism will be required to support embedded 4483 binary data. 4485 0 1 2 3 4486 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 4487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4488 | "$" = 36 | Channel ID | Length in octets | 4489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4490 : Binary data (Length according to Length field) : 4491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4493 Figure 1: Embedded Interleaved Binary Data Format 4495 The channel identifier is defined in the Transport header with the 4496 interleaved parameter (Section 18.54). 4498 When the transport choice is RTP, RTCP messages are also interleaved 4499 by the server over the TCP connection. The usage of RTCP messages is 4500 indicated by including an interval containing a second channel in the 4501 interleaved parameter of the Transport header, see Section 18.54. If 4502 RTCP is used, packets MUST be sent on the first available channel 4503 higher than the RTP channel. The channels are bi-directional, using 4504 the same Channel ID in both directions, and therefore RTCP traffic is 4505 sent on the second channel in both directions. 4507 RTCP is sometimes needed for synchronization when two or more 4508 streams are interleaved in such a fashion. Also, this provides a 4509 convenient way to tunnel RTP/RTCP packets through the RTSP 4510 connection (TCP or TCP/TLS) when required by the network 4511 configuration and transfer them onto UDP when possible. 4513 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 4514 CSeq: 2 4515 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 4516 Accept-Ranges: npt, smpte, clock 4517 User-Agent: PhonyClient/1.2 4519 S->C: RTSP/2.0 200 OK 4520 CSeq: 2 4521 Date: Thu, 05 Jun 1997 18:57:18 GMT 4522 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 4523 Session: 12345678 4524 Accept-Ranges: npt 4525 Media-Properties: Random-Access=0.2, Immutable, Unlimited 4527 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 4528 CSeq: 3 4529 Session: 12345678 4530 User-Agent: PhonyClient/1.2 4532 S->C: RTSP/2.0 200 OK 4533 CSeq: 3 4534 Session: 12345678 4535 Date: Thu, 05 Jun 1997 18:57:19 GMT 4536 RTP-Info: url="rtsp://example.com/bar.file" 4537 ssrc=0D12F123:seq=232433;rtptime=972948234 4538 Range: npt=0-56.8 4539 Seek-Style: RAP 4541 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4542 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4543 S->C: $006{2 octet length}{"length" octets RTCP packet} 4545 15. Proxies 4547 RTSP Proxies are RTSP agents that are located in between a client and 4548 a server. A proxy can take on both the role as a client and as 4549 server depending on what it tries to accomplish. RTSP proxies use 4550 two transport layer connections, one from the RTSP client to the RTSP 4551 proxy and a second from the RTSP proxy to the RTSP server. Proxies 4552 are introduced for several different reasons and those listed below 4553 are often combined. 4555 Caching Proxy: This type of proxy is used to reduce the workload on 4556 servers and connections. By caching the description and media 4557 streams, i.e., the presentation, the proxy can serve a client 4558 with content, but without requesting it from the server once it 4559 has been cached and has not become stale. See the caching 4560 Section 16. This type of proxy is also expected to understand 4561 RTSP end-point functionality, i.e., functionality identified in 4562 the Require header in addition to what Proxy-Require demands. 4564 Translator Proxy: This type of proxy is used to ensure that an RTSP 4565 client gets access to servers and content on an external 4566 network or using content encodings not supported by the client. 4567 The proxy performs the necessary translation of addresses, 4568 protocols or encodings. This type of proxy is expected to also 4569 understand RTSP end-point functionality, i.e., functionality 4570 identified in the Require header in addition to what Proxy- 4571 Require demands. 4573 Access Proxy: This type of proxy is used to ensure that an RTSP 4574 client gets access to servers on an external network. Thus 4575 this proxy is placed on the border between two domains, e.g., a 4576 private address space and the public Internet. The proxy 4577 performs the necessary translation, usually addresses. This 4578 type of proxy is required to redirect the media to itself or a 4579 controlled gateway that performs the translation before the 4580 media can reach the client. 4582 Security Proxy: This type of proxy is used to help facilitate 4583 security functions around RTSP. For example when having a 4584 firewalled network, the security proxy requests that the 4585 necessary pinholes in the firewall are opened when a client in 4586 the protected network wants to access media streams on the 4587 external side. This proxy can also limit the client's access 4588 to certain types of content. This proxy can perform its 4589 function without redirecting the media between the server and 4590 client. However, in deployments with private address spaces 4591 this proxy is likely to be combined with the access proxy. 4592 Anyway, the functionality of this proxy is usually closely tied 4593 into understanding all aspects of the media transport. 4595 Auditing Proxy: RTSP proxies can also provide network owners with a 4596 logging and audit point for RTSP sessions, e.g., for 4597 corporations that track their employees usage of the network. 4598 This type of proxy can perform its function without inserting 4599 itself or any other node in the media transport. This proxy 4600 type can also accept unknown methods as it doesn't interfere 4601 with the clients' requests. 4603 All types of proxies can also be used when using secured 4604 communication with TLS as RTSP 2.0 allows the client to approve 4605 certificate chains used for connection establishment from a proxy, 4606 see Section 19.3.2. However, that trust model may not be suitable 4607 for all types of deployment. In those cases, the secured sessions do 4608 by-pass the proxies. 4610 Access proxies SHOULD NOT be used in equipment like NATs and 4611 firewalls that aren't expected to be regularly maintained, like home 4612 or small office equipment. In these cases it is better to use the 4613 NAT traversal procedures defined for RTSP 2.0 4614 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 4615 that any extensions of RTSP resulting in new media transport 4616 protocols or profiles, new parameters, etc. may fail in a proxy that 4617 isn't maintained. This would impede RTSP's future development and 4618 usage. 4620 15.1. Proxies and Protocol Extensions 4622 The existence of proxies must always be considered when developing 4623 new RTSP extensions. Most types of proxies will need to implement 4624 any new method to operate correctly in the presence of that 4625 extension. New headers can be introduced and will not be blocked by 4626 older proxies. However, it is important to consider if this header 4627 and its function is required to be understood by the proxy or can be 4628 forwarded. If the header needs to be understood, a feature-tag 4629 representing the functionality MUST be included in the Proxy-Require 4630 header. Below are guidelines for analysis if the header needs to be 4631 understood. The transport header and its parameters also shows that 4632 headers that are extensible and require correct interpretation in the 4633 proxy also require handling rules. 4635 Whether a proxy needs to understand a header is not easy to 4636 determine, as they serve a broad variety of functions. When 4637 evaluating if a header needs to be understood, one can divide the 4638 functionality into three main categories: 4640 Media modifying: The caching and translator proxies are modifying 4641 the actual media and therefore need to understand also the request 4642 directed to the server that affects how the media is rendered. 4643 Thus, this type of proxy needs to also understand the server side 4644 functionality. 4646 Transport modifying: The access and the security proxy both need to 4647 understand how the transport is performed, either for opening 4648 pinholes or to translate the outer headers, e.g., IP and UDP. 4650 Non-modifying: The audit proxy is special in that it does not modify 4651 the messages in other ways than to insert the Via header. That 4652 makes it possible for this type to forward RTSP messages that 4653 contain different types of unknown methods, headers or header 4654 parameters. 4656 Based on the above classification, one should evaluate if the new 4657 functionality requires the Transport modifying type of proxies to 4658 understand it or not. 4660 15.2. Multiplexing and Demultiplexing of Messages 4662 RTSP proxies may have to multiplex multiple RTSP sessions from their 4663 clients towards RTSP servers. This requires that RTSP requests from 4664 multiple clients are multiplexed onto a common connection for 4665 requests outgoing to an RTSP server and on the way back the responses 4666 are demultiplexed from the server to per client responses. On the 4667 protocol level this requires that request and response messages are 4668 handled in both ways, requiring that there is a mechanism to 4669 correlate what request/response pair exchanged between proxy and 4670 server is mapped to what client (or client request). 4672 This multiplexing of requests and demultiplexing of responses is done 4673 by using the CSeq header field. The proxy has to rewrite the CSeq in 4674 requests to the server and responses from the server and remember 4675 what CSeq is mapped to what client. The proxy also needs to ensure 4676 that the order of the message related to each client is maintained. 4677 Section 18.20 is defining the handling of how requests and responses 4678 are rewritten. 4680 16. Caching 4682 In HTTP, request-response pairs are cached. RTSP differs 4683 significantly in that respect. Responses are not cacheable, with the 4684 exception of the presentation description returned by DESCRIBE. 4685 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4686 not return any data, caching is not really an issue for these 4687 requests.) However, it is desirable for the continuous media data, 4688 typically delivered out-of-band with respect to RTSP, to be cached, 4689 as well as the session description. 4691 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4692 has an up-to-date copy of the continuous media content and its 4693 description. It can determine whether the copy is up-to-date by 4694 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4695 Last-Modified header with that of the cached copy. If the copy is 4696 not up-to-date, it modifies the SETUP transport parameters as 4697 appropriate and forwards the request to the origin server. 4698 Subsequent control commands such as PLAY or PAUSE then pass the proxy 4699 unmodified. The proxy delivers the continuous media data to the 4700 client, while possibly making a local copy for later reuse. The 4701 exact allowed behavior of the cache is given by the cache-response 4702 directives described in Section 18.11. A cache MUST answer any 4703 DESCRIBE requests if it is currently serving the stream to the 4704 requester, as it is possible that low-level details of the stream 4705 description may have changed on the origin-server. 4707 Note that an RTSP cache, is of the "cut-through" variety. Rather 4708 than retrieving the whole resource from the origin server, the cache 4709 simply copies the streaming data as it passes by on its way to the 4710 client. Thus, it does not introduce additional latency. 4712 To the client, an RTSP proxy cache appears like a regular media 4713 server. To the media origin server an RTSP proxy cache appears like 4714 a client. Just as an HTTP cache has to store the content type, 4715 content language, and so on for the objects it caches, a media cache 4716 has to store the presentation description. Typically, a cache 4717 eliminates all transport-references (e.g., multicast information) 4718 from the presentation description, since these are independent of the 4719 data delivery from the cache to the client. Information on the 4720 encodings remains the same. If the cache is able to translate the 4721 cached media data, it would create a new presentation description 4722 with all the encoding possibilities it can offer. 4724 16.1. Validation Model 4726 When a cache has a stale entry that it would like to use as a 4727 response to a client's request, it first has to check with the origin 4728 server (or possibly an intermediate cache with a fresh response) to 4729 see if its cached entry is still usable. We call this "validating" 4730 the cache entry. Since we do not want to have to pay the overhead of 4731 retransmitting the full response if the cached entry is good, and we 4732 do not want to pay the overhead of an extra round trip if the cached 4733 entry is invalid, the RTSP protocol supports the use of conditional 4734 methods. 4736 The key protocol features for supporting conditional methods are 4737 those concerned with "cache validators." When an origin server 4738 generates a full response, it attaches some sort of validator to it, 4739 which is kept with the cache entry. When a client (user agent or 4740 proxy cache) makes a conditional request for a resource for which it 4741 has a cache entry, it includes the associated validator in the 4742 request. 4744 The server then checks that validator against the current validator 4745 for the requested resource, and, if they match (see Section 16.1.3), 4746 it responds with a special status code (usually, 304 (Not Modified)) 4747 and no message body. Otherwise, it returns a full response 4748 (including message body). Thus, we avoid transmitting the full 4749 response if the validator matches, and we avoid an extra round trip 4750 if it does not match. 4752 In RTSP, a conditional request looks exactly the same as a normal 4753 request for the same resource, except that it carries a special 4754 header (which includes the validator) that implicitly turns the 4755 method (usually DESCRIBE or SETUP) into a conditional. 4757 The protocol includes both positive and negative senses of cache- 4758 validating conditions. That is, it is possible to request either 4759 that a method be performed if and only if a validator matches or if 4760 and only if no validators match. 4762 Note: a response that lacks a validator may still be cached, and 4763 served from cache until it expires, unless this is explicitly 4764 prohibited by a cache-control directive (see Section 18.11). 4765 However, a cache cannot do a conditional retrieval if it does not 4766 have a validator for the resource, which means it will not be 4767 refreshable after it expires. 4769 Media streams that are being adapted based on the transport capacity 4770 between the server and the cache makes caching more difficult. A 4771 server needs to consider how it views caching of media streams that 4772 it adapts and potentially instruct any caches to not cache such 4773 streams. 4775 16.1.1. Last-Modified Dates 4777 The Last-Modified header (Section 18.27) value is often used as a 4778 cache validator. In simple terms, a cache entry is considered to be 4779 valid if the content has not been modified since the Last-Modified 4780 value. 4782 16.1.2. Message Body Tag Cache Validators 4784 The MTag response-header field value, a message body tag, provides 4785 for an "opaque" cache validator. This might allow more reliable 4786 validation in situations where it is inconvenient to store 4787 modification dates, where the one-second resolution of RTSP-date 4788 values is not sufficient, or where the origin server wishes to avoid 4789 certain paradoxes that might arise from the use of modification 4790 dates. 4792 Message body tags are described in Section 4.6 4794 16.1.3. Weak and Strong Validators 4796 Since both origin servers and caches will compare two validators to 4797 decide if they represent the same or different entities, one normally 4798 would expect that if the message body (i.e., the presentation 4799 description) or any associated message body headers changes in any 4800 way, then the associated validator would change as well. If this is 4801 true, then we call this validator a "strong validator." We call 4802 message body (i.e., the presentation description) or any associated 4803 message body headers an entity for a better understanding. 4805 However, there might be cases when a server prefers to change the 4806 validator only on semantically significant changes, and not when 4807 insignificant aspects of the entity change. A validator that does 4808 not always change when the resource changes is a "weak validator." 4810 Message body tags are normally "strong validators," but the protocol 4811 provides a mechanism to tag a message body tag as "weak." One can 4812 think of a strong validator as one that changes whenever the bits of 4813 an entity changes, while a weak value changes whenever the meaning of 4814 an entity changes. Alternatively, one can think of a strong 4815 validator as part of an identifier for a specific entity, while a 4816 weak validator is part of an identifier for a set of semantically 4817 equivalent entities. 4819 Note: One example of a strong validator is an integer that is 4820 incremented in stable storage every time an entity is changed. 4822 An entity's modification time, if represented with one-second 4823 resolution, could be a weak validator, since it is possible that 4824 the resource might be modified twice during a single second. 4826 Support for weak validators is optional. However, weak validators 4827 allow for more efficient caching of equivalent objects. 4829 A "use" of a validator is either when a client generates a request 4830 and includes the validator in a validating header field, or when a 4831 server compares two validators. 4833 Strong validators are usable in any context. Weak validators are 4834 only usable in contexts that do not depend on exact equality of an 4835 entity. For example, either kind is usable for a conditional 4836 DESCRIBE of a full entity. However, only a strong validator is 4837 usable for a sub-range retrieval, since otherwise the client might 4838 end up with an internally inconsistent entity. 4840 Clients MAY issue DESCRIBE requests with either weak validators or 4841 strong validators. Clients MUST NOT use weak validators in other 4842 forms of requests. 4844 The only function that the RTSP protocol defines on validators is 4845 comparison. There are two validator comparison functions, depending 4846 on whether the comparison context allows the use of weak validators 4847 or not: 4849 o The strong comparison function: in order to be considered equal, 4850 both validators MUST be identical in every way, and both MUST NOT 4851 be weak. 4853 o The weak comparison function: in order to be considered equal, 4854 both validators MUST be identical in every way, but either or both 4855 of them MAY be tagged as "weak" without affecting the result. 4857 A message body tag is strong unless it is explicitly tagged as weak. 4859 A Last-Modified time, when used as a validator in a request, is 4860 implicitly weak unless it is possible to deduce that it is strong, 4861 using the following rules: 4863 o The validator is being compared by an origin server to the actual 4864 current validator for the entity and, 4866 o That origin server reliably knows that the associated entity did 4867 not change more than once during the second covered by the 4868 presented validator. 4870 OR 4872 o The validator is about to be used by a client in an If-Modified- 4873 Since, because the client has a cache entry for the associated 4874 entity, and 4876 o That cache entry includes a Date value, which gives the time when 4877 the origin server sent the original response, and 4879 o The presented Last-Modified time is at least 60 seconds before the 4880 Date value. 4882 OR 4884 o The validator is being compared by an intermediate cache to the 4885 validator stored in its cache entry for the entity, and 4887 o That cache entry includes a Date value, which gives the time when 4888 the origin server sent the original response, and 4890 o The presented Last-Modified time is at least 60 seconds before the 4891 Date value. 4893 This method relies on the fact that if two different responses were 4894 sent by the origin server during the same second, but both had the 4895 same Last-Modified time, then at least one of those responses would 4896 have a Date value equal to its Last-Modified time. The arbitrary 60- 4897 second limit guards against the possibility that the Date and Last- 4898 Modified values are generated from different clocks, or at somewhat 4899 different times during the preparation of the response. An 4900 implementation MAY use a value larger than 60 seconds, if it is 4901 believed that 60 seconds is too short. 4903 If a client wishes to perform a sub-range retrieval on a value for 4904 which it has only a Last-Modified time and no opaque validator, it 4905 MAY do this only if the Last-Modified time is strong in the sense 4906 described here. 4908 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates 4910 We adopt a set of rules and recommendations for origin servers, 4911 clients, and caches regarding when various validator types ought to 4912 be used, and for what purposes. 4914 RTSP origin servers: 4916 o SHOULD send a message body tag validator unless it is not feasible 4917 to generate one. 4919 o MAY send a weak message body tag instead of a strong message body 4920 tag, if performance considerations support the use of weak message 4921 body tags, or if it is unfeasible to send a strong message body 4922 tag. 4924 o SHOULD send a Last-Modified value if it is feasible to send one, 4925 unless the risk of a breakdown in semantic transparency that could 4926 result from using this date in an If-Modified-Since header would 4927 lead to serious problems. 4929 In other words, the preferred behavior for an RTSP origin server is 4930 to send both a strong message body tag and a Last-Modified value. 4932 In order to be legal, a strong message body tag MUST change whenever 4933 the associated entity value changes in any way. A weak message body 4934 tag SHOULD change whenever the associated entity changes in a 4935 semantically significant way. 4937 Note: in order to provide semantically transparent caching, an 4938 origin server MUST avoid reusing a specific strong message body 4939 tag value for two different entities, or reusing a specific weak 4940 message body tag value for two semantically different entities. 4941 Cache entries might persist for arbitrarily long periods, 4942 regardless of expiration times, so it might be inappropriate to 4943 expect that a cache will never again attempt to validate an entry 4944 using a validator that it obtained at some point in the past. 4946 RTSP clients: 4948 o If a message body tag has been provided by the origin server, MUST 4949 use that message body tag in any cache-conditional request (using 4950 If-Match or If-None-Match). 4952 o If only a Last-Modified value has been provided by the origin 4953 server, SHOULD use that value in non-subrange cache-conditional 4954 requests (using If-Modified-Since). 4956 o If both a message body tag and a Last-Modified value have been 4957 provided by the origin server, SHOULD use both validators in 4958 cache-conditional requests. 4960 An RTSP origin server, upon receiving a conditional request that 4961 includes both a Last-Modified date (e.g., in an If-Modified-Since 4962 header) and one or more message body tags (e.g., in an If-Match, If- 4963 None-Match, or If-Range header field) as cache validators, MUST NOT 4964 return a response status of 304 (Not Modified) unless doing so is 4965 consistent with all of the conditional header fields in the request. 4967 Note: The general principle behind these rules is that RTSP 4968 servers and clients should transmit as much non-redundant 4969 information as is available in their responses and requests. RTSP 4970 systems receiving this information will make the most conservative 4971 assumptions about the validators they receive. 4973 16.1.5. Non-validating Conditionals 4975 The principle behind message body tags is that only the service 4976 author knows the semantics of a resource well enough to select an 4977 appropriate cache validation mechanism, and the specification of any 4978 validator comparison function more complex than octet-equality would 4979 open up a can of worms. Thus, comparisons of any other headers are 4980 never used for purposes of validating a cache entry. 4982 16.2. Invalidation After Updates or Deletions 4984 The effect of certain methods performed on a resource at the origin 4985 server might cause one or more existing cache entries to become non- 4986 transparently invalid. That is, although they might continue to be 4987 "fresh," they do not accurately reflect what the origin server would 4988 return for a new request on that resource. 4990 There is no way for the RTSP protocol to guarantee that all such 4991 cache entries are marked invalid. For example, the request that 4992 caused the change at the origin server might not have gone through 4993 the proxy where a cache entry is stored. However, several rules help 4994 reduce the likelihood of erroneous behavior. 4996 In this section, the phrase "invalidate an entity" means that the 4997 cache will either remove all instances of that entity from its 4998 storage, or will mark these as "invalid" and in need of a mandatory 4999 revalidation before they can be returned in response to a subsequent 5000 request. 5002 Some RTSP methods MUST cause a cache to invalidate an entity. This 5003 is either the entity referred to by the Request-URI, or by the 5004 Location or Content-Location headers (if present). These methods 5005 are: 5007 o DESCRIBE 5008 o SETUP 5010 In order to prevent denial of service attacks, an invalidation based 5011 on the URI in a Location or Content-Location header MUST only be 5012 performed if the host part is the same as in the Request-URI. 5014 A cache that passes through requests for methods it does not 5015 understand SHOULD invalidate any entities referred to by the Request- 5016 URI. 5018 17. Status Code Definitions 5020 Where applicable, HTTP status [H10] codes are reused. See Table 4 in 5021 Section 8.1 for a listing of which status codes may be returned by 5022 which requests. All error messages, 4xx and 5xx MAY return a body 5023 containing further information about the error. 5025 17.1. Success 1xx 5027 17.1.1. 100 Continue 5029 The client SHOULD continue with its request. This interim response 5030 is used to inform the client that the initial part of the request has 5031 been received and has not yet been rejected by the server. The 5032 client SHOULD continue by sending the remainder of the request or, if 5033 the request has already been completed, ignore this response. The 5034 server MUST send a final response after the request has been 5035 completed. 5037 17.2. Success 2xx 5039 This class of status code indicates that the client's request was 5040 successfully received, understood, and accepted. 5042 17.2.1. 200 OK 5044 The request has succeeded. The information returned with the 5045 response is dependent on the method used in the request. 5047 17.3. Redirection 3xx 5049 The notation "3xx" indicates response codes from 300 to 399 inclusive 5050 which are meant for redirection. The response code 304 is excluded, 5051 as it is not used for redirection and instead the "3rr" notation is 5052 used. The 304 response code appears here, rather than a 2xx response 5053 code which would have been appropriate, this as 304 has been used 5054 also in RTSP 1.0 [RFC2326]. 5056 Within RTSP, redirection may be used for load balancing or 5057 redirecting stream requests to a server topologically closer to the 5058 client. Mechanisms to determine topological proximity are beyond the 5059 scope of this specification. 5061 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 5062 that they are used if necessary before a session is established, 5063 i.e., in response to DESCRIBE or SETUP. However, in cases where a 5064 server is not able to send a REDIRECT request to the client, the 5065 server MAY need to resort to using 3rr responses to inform a client 5066 with an established session about the need for redirecting the 5067 session. If a 3rr response is received for a request in relation to 5068 an established session, the client SHOULD send a TEARDOWN request for 5069 the session, and MAY reestablish the session using the resource 5070 indicated by the Location. 5072 If the Location header is used in a response it MUST contain an 5073 absolute URI pointing out the media resource the client is redirected 5074 to, the URI MUST NOT only contain the host name. 5076 17.3.1. 300 5078 This response code is not used in RTSP 2.0. In the event that an 5079 unknown 3rr status code is received, the agent SHOULD behave as if a 5080 302 response code had been received (Section 17.3.3). 5082 17.3.2. 301 Moved Permanently 5084 The requested resource is moved permanently and resides now at the 5085 URI given by the Location header. The user client SHOULD redirect 5086 automatically to the given URI. This response MUST NOT contain a 5087 message-body. The Location header MUST be included in the response. 5089 17.3.3. 302 Found 5091 The requested resource resides temporarily at the URI given by the 5092 Location header. The Location header MUST be included in the 5093 response. This response is intended to be used for many types of 5094 temporary redirects; e.g., load balancing. It is RECOMMENDED that 5095 the server set the reason phrase to something more meaningful than 5096 "Found" in these cases. The user client SHOULD redirect 5097 automatically to the given URI. This response MUST NOT contain a 5098 message-body. 5100 This example shows a client being redirected to a different server: 5102 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 5103 CSeq: 2 5104 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 5105 Accept-Ranges: npt, smpte, clock 5106 User-Agent: PhonyClient/1.2 5108 S->C: RTSP/2.0 302 Try Other Server 5109 CSeq: 2 5110 Location: rtsp://s2.example.com:8001/fizzle/foo 5112 17.3.4. 303 See Other 5114 This status code MUST NOT be used in RTSP 2.0. However, it was 5115 allowed in RTSP 1.0 [RFC2326]. 5117 17.3.5. 304 Not Modified 5119 If the client has performed a conditional DESCRIBE or SETUP (see 5120 Section 18.25) and the requested resource has not been modified, the 5121 server SHOULD send a 304 response. This response MUST NOT contain a 5122 message-body. 5124 The response MUST include the following header fields: 5126 o Date 5128 o MTag and/or Content-Location, if the header(s) would have been 5129 sent in a 200 response to the same request. 5131 o Expires and Cache-Control if the field-value might differ from 5132 that sent in any previous response for the same variant. 5134 This response is independent for the DESCRIBE and SETUP requests. 5135 That is, a 304 response to DESCRIBE does NOT imply that the resource 5136 content is unchanged (only the session description) and a 304 5137 response to SETUP does NOT imply that the resource description is 5138 unchanged. The MTag and If-Match headers may be used to link the 5139 DESCRIBE and SETUP in this manner. 5141 17.3.6. 305 Use Proxy 5143 The requested resource MUST be accessed through the proxy given by 5144 the Location field. The Location field gives the URI of the proxy. 5145 The recipient is expected to repeat this single request via the 5146 proxy. 305 responses MUST only be generated by origin servers. 5148 17.4. Client Error 4xx 5150 17.4.1. 400 Bad Request 5152 The request could not be understood by the server due to malformed 5153 syntax. The client SHOULD NOT repeat the request without 5154 modifications. If the request does not have a CSeq header, the 5155 server MUST NOT include a CSeq in the response. 5157 17.4.2. 401 Unauthorized 5159 The request requires user authentication. The response MUST include 5160 a WWW-Authenticate header (Section 18.58) field containing a 5161 challenge applicable to the requested resource. The client MAY 5162 repeat the request with a suitable Authorization header field. If 5163 the request already included Authorization credentials, then the 401 5164 response indicates that authorization has been refused for those 5165 credentials. If the 401 response contains the same challenge as the 5166 prior response, and the user agent has already attempted 5167 authentication at least once, then the user SHOULD be presented the 5168 message body that was given in the response, since that message body 5169 might include relevant diagnostic information. HTTP access 5170 authentication is explained in [RFC2617]. 5172 17.4.3. 402 Payment Required 5174 This code is reserved for future use. 5176 17.4.4. 403 Forbidden 5178 The server understood the request, but is refusing to fulfill it. 5179 Authorization will not help and the request SHOULD NOT be repeated. 5180 If the server wishes to make public why the request has not been 5181 fulfilled, it SHOULD describe the reason for the refusal in the 5182 message body. If the server does not wish to make this information 5183 available to the client, the status code 404 (Not Found) can be used 5184 instead. 5186 17.4.5. 404 Not Found 5188 The server has not found anything matching the Request-URI. No 5189 indication is given of whether the condition is temporary or 5190 permanent. The 410 (Gone) status code SHOULD be used if the server 5191 knows, through some internally configurable mechanism, that an old 5192 resource is permanently unavailable and has no forwarding address. 5193 This status code is commonly used when the server does not wish to 5194 reveal exactly why the request has been refused, or when no other 5195 response is applicable. 5197 17.4.6. 405 Method Not Allowed 5199 The method specified in the request is not allowed for the resource 5200 identified by the Request-URI. The response MUST include an Allow 5201 header containing a list of valid methods for the requested resource. 5202 This status code is also to be used if a request attempts to use a 5203 method not indicated during SETUP. 5205 17.4.7. 406 Not Acceptable 5207 The resource identified by the request is only capable of generating 5208 response message bodies which have content characteristics not 5209 acceptable according to the Accept headers sent in the request. 5211 The response SHOULD include a message body containing a list of 5212 available message body characteristics and location(s) from which the 5213 user or user agent can choose the one most appropriate. The message 5214 body format is specified by the media type given in the Content-Type 5215 header field. Depending upon the format and the capabilities of the 5216 user agent, selection of the most appropriate choice MAY be performed 5217 automatically. However, this specification does not define any 5218 standard for such automatic selection. 5220 If the response could be unacceptable, a user agent SHOULD 5221 temporarily stop receipt of more data and query the user for a 5222 decision on further actions. 5224 17.4.8. 407 Proxy Authentication Required 5226 This code is similar to 401 (Unauthorized) (Section 17.4.2), but 5227 indicates that the client must first authenticate itself with the 5228 proxy. The proxy MUST return a Proxy-Authenticate header field 5229 (Section 18.34) containing a challenge applicable to the proxy for 5230 the requested resource. 5232 17.4.9. 408 Request Timeout 5234 The client did not produce a request within the time that the server 5235 was prepared to wait. The client MAY repeat the request without 5236 modifications at any later time. 5238 17.4.10. 410 Gone 5240 The requested resource is no longer available at the server and the 5241 forwarding address is not known. This condition is expected to be 5242 considered permanent. If the server does not know, or has no 5243 facility to determine, whether or not the condition is permanent, the 5244 status code 404 (Not Found) SHOULD be used instead. This response is 5245 cacheable unless indicated otherwise. 5247 The 410 response is primarily intended to assist the task of 5248 repository maintenance by notifying the recipient that the resource 5249 is intentionally unavailable and that the server owners desire that 5250 remote links to that resource be removed. Such an event is common 5251 for limited-time, promotional services and for resources belonging to 5252 individuals no longer working at the server's site. It is not 5253 necessary to mark all permanently unavailable resources as "gone" or 5254 to keep the mark for any length of time -- that is left to the 5255 discretion of the owner of the server. 5257 17.4.11. 411 Length Required 5259 This error code is not defined for RTSP. This as the use of Content- 5260 Length (Section 18.17) is always required when message bodies are 5261 included in RTSP messages. 5263 17.4.12. 412 Precondition Failed 5265 The precondition given in one or more of the 'if-' request-header 5266 fields evaluated to false when it was tested on the server. See 5267 these sections for the 'if-' headers: If-Match Section 18.24, If- 5268 Modified-Since Section 18.25, and If-None-Match Section 18.26. This 5269 response code allows the client to place preconditions on the current 5270 resource meta information (header field data) and thus prevent the 5271 requested method from being applied to a resource other than the one 5272 intended. 5274 17.4.13. 413 Request Message Body Too Large 5276 The server is refusing to process a request because the request 5277 message body is larger than the server is willing or able to process. 5278 The server MAY close the connection to prevent the client from 5279 continuing the request. 5281 If the condition is temporary, the server SHOULD include a Retry- 5282 After header field to indicate that it is temporary and after what 5283 time the client MAY try again. 5285 17.4.14. 414 Request-URI Too Long 5287 The server is refusing to service the request because the Request-URI 5288 is longer than the server is willing to interpret. This rare 5289 condition is only likely to occur when a client has used a request 5290 with long query information, when the client has descended into a URI 5291 "black hole" of redirection (e.g., a redirected URI prefix that 5292 points to a suffix of itself), or when the server is under attack by 5293 a client attempting to exploit security holes present in some servers 5294 using fixed-length buffers for reading or manipulating the Request- 5295 URI. 5297 17.4.15. 415 Unsupported Media Type 5299 The server is refusing to service the request because the message 5300 body of the request is in a format not supported by the requested 5301 resource for the requested method. 5303 17.4.16. 451 Parameter Not Understood 5305 The recipient of the request does not support one or more parameters 5306 contained in the request. When returning this error message the 5307 sender SHOULD return a message body containing the offending 5308 parameter(s). 5310 17.4.17. 452 reserved 5312 This status code MUST NOT be used in RTSP 2.0. However, it was 5313 allowed in RTSP 1.0 [RFC2326]. 5315 17.4.18. 453 Not Enough Bandwidth 5317 The request was refused because there was insufficient bandwidth. 5318 This may, for example, be the result of a resource reservation 5319 failure. 5321 17.4.19. 454 Session Not Found 5323 The RTSP session identifier in the Session header is missing, 5324 invalid, or has timed out. 5326 17.4.20. 455 Method Not Valid in This State 5328 The client or server cannot process this request in its current 5329 state. The response MUST contain an Allow header to make error 5330 recovery possible. 5332 17.4.21. 456 Header Field Not Valid for Resource 5334 The server could not act on a required request-header. For example, 5335 if PLAY contains the Range header field but the stream does not allow 5336 seeking. This error message may also be used for specifying when the 5337 time format in Range is impossible for the resource. In that case 5338 the Accept-Ranges header MUST be returned to inform the client of 5339 which format(s) that are allowed. 5341 17.4.22. 457 Invalid Range 5343 The Range value given is out of bounds, e.g., beyond the end of the 5344 presentation. 5346 17.4.23. 458 Parameter Is Read-Only 5348 The parameter to be set by SET_PARAMETER can be read but not 5349 modified. When returning this error message the sender SHOULD return 5350 a message body containing the offending parameter(s). 5352 17.4.24. 459 Aggregate Operation Not Allowed 5354 The requested method may not be applied on the URI in question since 5355 it is an aggregate (presentation) URI. The method may be applied on 5356 a media URI. 5358 17.4.25. 460 Only Aggregate Operation Allowed 5360 The requested method may not be applied on the URI in question since 5361 it is not an aggregate control (presentation) URI. The method may be 5362 applied on the aggregate control URI. 5364 17.4.26. 461 Unsupported Transport 5366 The Transport field did not contain a supported transport 5367 specification. 5369 17.4.27. 462 Destination Unreachable 5371 The data transmission channel could not be established because the 5372 client address could not be reached. This error will most likely be 5373 the result of a client attempt to place an invalid dest_addr 5374 parameter in the Transport field. 5376 17.4.28. 463 Destination Prohibited 5378 The data transmission channel was not established because the server 5379 prohibited access to the client address. This error is most likely 5380 the result of a client attempt to redirect media traffic to another 5381 destination with a dest_addr parameter in the Transport header. 5383 17.4.29. 464 Data Transport Not Ready Yet 5385 The data transmission channel to the media destination is not yet 5386 ready for carrying data. However, the responding agent still expects 5387 that the data transmission channel will be established at some point 5388 in time. Note, however, that this may result in a permanent failure 5389 like 462 "Destination Unreachable". 5391 An example when this error may occur is in the case a client sends a 5392 PLAY request to a server prior to ensuring that the TCP connections 5393 negotiated for carrying media data was successfully established (In 5394 violation of this specification). The server would use this error 5395 code to indicate that the requested action could not be performed due 5396 to the failure of completing the connection establishment. 5398 17.4.30. 465 Notification Reason Unknown 5400 This indicates that the client has received a PLAY_NOTIFY 5401 (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to 5402 the client. 5404 17.4.31. 466 Key Management Error 5406 This indicates that there has been an error in a Key Management 5407 function used in conjunction with a request. For example usage of 5408 MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this 5409 error. 5411 17.4.32. 470 Connection Authorization Required 5413 The secured connection attempt needs user or client authorization 5414 before proceeding. The next hop's certificate is included in this 5415 response in the Accept-Credentials header. 5417 17.4.33. 471 Connection Credentials not accepted 5419 When performing a secure connection over multiple connections, an 5420 intermediary has refused to connect to the next hop and carry out the 5421 request due to unacceptable credentials for the used policy. 5423 17.4.34. 472 Failure to establish secure connection 5425 A proxy fails to establish a secure connection to the next hop RTSP 5426 agent. This is primarily caused by a fatal failure at the TLS 5427 handshake, for example due to server not accepting any cipher suites. 5429 17.5. Server Error 5xx 5431 Response status codes beginning with the digit "5" indicate cases in 5432 which the server is aware that it has erred or is incapable of 5433 performing the request The server SHOULD include a message body 5434 containing an explanation of the error situation, and whether it is a 5435 temporary or permanent condition. User agents SHOULD display any 5436 included message body to the user. These response codes are 5437 applicable to any request method. 5439 17.5.1. 500 Internal Server Error 5441 The server encountered an unexpected condition which prevented it 5442 from fulfilling the request. 5444 17.5.2. 501 Not Implemented 5446 The server does not support the functionality required to fulfill the 5447 request. This is the appropriate response when the server does not 5448 recognize the request method and is not capable of supporting it for 5449 any resource. 5451 17.5.3. 502 Bad Gateway 5453 The server, while acting as a gateway or proxy, received an invalid 5454 response from the upstream server it accessed in attempting to 5455 fulfill the request. 5457 17.5.4. 503 Service Unavailable 5459 The server is currently unable to handle the request due to a 5460 temporary overloading or maintenance of the server. The implication 5461 is that this is a temporary condition which will be alleviated after 5462 some delay. If known, the length of the delay MAY be indicated in a 5463 Retry-After header. If no Retry-After is given, the client SHOULD 5464 handle the response as it would for a 500 response. The client MUST 5465 honor the length, if given in the Retry-After header. 5467 Note: The existence of the 503 status code does not imply that 5468 a server must use it when becoming overloaded. Some servers 5469 may wish to simply refuse the connection. 5471 The response scope is dependent on the Request. If the request was 5472 in relation to an existing RTSP session, the scope of the overload 5473 response is to this individual RTSP session. If the request was non- 5474 session specific or intended to form a RTSP session it applies to the 5475 RTSP server identified by the host name in the request URI. 5477 17.5.5. 504 Gateway Timeout 5479 The server, while acting as a proxy, did not receive a timely 5480 response from the upstream server specified by the URI or some other 5481 auxiliary server (e.g., DNS) it needed to access in attempting to 5482 complete the request. 5484 17.5.6. 505 RTSP Version Not Supported 5486 The server does not support, or refuses to support, the RTSP protocol 5487 version that was used in the request message. The server is 5488 indicating that it is unable or unwilling to complete the request 5489 using the same major version as the client other than with this error 5490 message. The response SHOULD contain a message body describing why 5491 that version is not supported and what other protocols are supported 5492 by that server. 5494 17.5.7. 551 Option not supported 5496 A feature-tag given in the Require or the Proxy-Require fields was 5497 not supported. The Unsupported header MUST be returned stating the 5498 feature for which there is no support. 5500 17.5.8. 553 Proxy Unavailable 5502 The proxy is currently unable to handle the request due to a 5503 temporary overloading or maintenance of the proxy. The implication 5504 is that this is a temporary condition which will be alleviated after 5505 some delay. If known, the length of the delay MAY be indicated in a 5506 Retry-After header. If no Retry-After is given, the client SHOULD 5507 handle the response as it would for a 500 response. The client MUST 5508 honor the length, if given in the Retry-After header. 5510 Note: The existence of the 553 status code does not imply that 5511 a proxy must use it when becoming overloaded. Some proxies may 5512 wish to simply refuse the connection. 5514 The response scope is dependent on the Request. If the request was 5515 in relation to an existing RTSP session, the scope of the overload 5516 response is to this individual RTSP session. If the request was non- 5517 session specific or intended to form a RTSP session it applies to all 5518 such requests to this proxy. 5520 18. Header Field Definitions 5522 +---------------+----------------+--------+---------+------+ 5523 | method | direction | object | acronym | Body | 5524 +---------------+----------------+--------+---------+------+ 5525 | DESCRIBE | C -> S | P,S | DES | r | 5526 | | | | | | 5527 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 5528 | | | | | | 5529 | OPTIONS | C -> S, S -> C | P,S | OPT | | 5530 | | | | | | 5531 | PAUSE | C -> S | P,S | PSE | | 5532 | | | | | | 5533 | PLAY | C -> S | P,S | PLY | | 5534 | | | | | | 5535 | PLAY_NOTIFY | S -> C | P,S | PNY | R | 5536 | | | | | | 5537 | REDIRECT | S -> C | P,S | RDR | | 5538 | | | | | | 5539 | SETUP | C -> S | S | STP | | 5540 | | | | | | 5541 | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | 5542 | | | | | | 5543 | TEARDOWN | C -> S | P,S | TRD | | 5544 | | | | | | 5545 | | S -> C | P | TRD | | 5546 +---------------+----------------+--------+---------+------+ 5548 Table 8: Overview of RTSP methods, their direction, and what objects 5549 (P: presentation, S: stream) they operate on. Body notes if a method 5550 is allowed to carry body and in which direction, R = Request, 5551 r=response. Note: All error messages for statuses 4xx and 5xx are 5552 allowed to carry a body 5554 The general syntax for header fields is covered in Section 5.2. This 5555 section lists the full set of header fields along with notes on 5556 meaning, and usage. The syntax definition for header fields are 5557 present in Section 20.2.3. Throughout this section, we use [HX.Y] to 5558 reference Section X.Y of the current HTTP/1.1 specification RFC 2616 5559 [RFC2616]. Examples of each header field are given. 5561 Information about header fields in relation to methods and proxy 5562 processing is summarized in Table 9, Table 10, Table 11, and 5563 Table 12. 5565 The "where" column describes the request and response types in which 5566 the header field can be used. Values in this column are: 5568 R: header field may only appear in requests; 5570 r: header field may only appear in responses; 5572 2xx, 4xx, etc.: A numerical value or range indicates response codes 5573 with which the header field can be used; 5575 c: header field is copied from the request to the response. 5577 G: header field is a general-header and may be present in both 5578 requests and responses. 5580 Note: General headers does not always use the "G" value in the where 5581 column. This is due to differencies when the header may be applied 5582 in requests compared to responses. When such differencies exist they 5583 are expressed using two differet rows, one with where being "R" and 5584 one with it being "r". 5586 The "proxy" column describes the operations a proxy may perform on a 5587 header field. An empty proxy column indicates that the proxy MUST 5588 NOT do any changes to that header, all allowed operations are 5589 explicitly stated: 5591 a: A proxy can add or concatenate the header field if not present. 5593 m: A proxy can modify an existing header field value. 5595 d: A proxy can delete a header field value. 5597 r: A proxy needs to be able to read the header field, and thus 5598 this header field cannot be encrypted. 5600 The rest of the columns relate to the presence of a header field in a 5601 method. The method names when abbreviated, are according to Table 8: 5603 c: Conditional; requirements on the header field depend on the 5604 context of the message. 5606 m: The header field is mandatory. 5608 m*: The header field SHOULD be sent, but clients/servers need to be 5609 prepared to receive messages without that header field. 5611 o: The header field is optional. 5613 *: The header field MUST be present if the message body is not 5614 empty. See Section 18.17, Section 18.19 and Section 5.3 for 5615 details. 5617 -: The header field is not applicable. 5619 "Optional" means that a Client/Server MAY include the header field in 5620 a request or response. The Client/Server behavior when receiving 5621 such headers varies, for some it may ignore the header field, in 5622 other cases it is a request to process the header. This is regulated 5623 by the method and header descriptions. Example of headers that 5624 require processing are the Require and Proxy-Require header fields 5625 discussed in Section 18.43 and Section 18.37. A "mandatory" header 5626 field MUST be present in a request, and MUST be understood by the 5627 Client/Server receiving the request. A mandatory response-header 5628 field MUST be present in the response, and the header field MUST be 5629 understood by the Client/Server processing the response. "Not 5630 applicable" means that the header field MUST NOT be present in a 5631 request. If one is placed in a request by mistake, it MUST be 5632 ignored by the Client/Server receiving the request. Similarly, a 5633 header field labeled "not applicable" for a response means that the 5634 Client/Server MUST NOT place the header field in the response, and 5635 the Client/Server MUST ignore the header field in the response. 5637 An RTSP agent MUST ignore extension headers that are not understood. 5639 The From and Location header fields contain a URI. If the URI 5640 contains a comma, or semicolon, the URI MUST be enclosed in double 5641 quotes ("). Any URI parameters are contained within these quotes. 5642 If the URI is not enclosed in double quote, any semicolon-delimited 5643 parameters are header-parameters, not URI parameters. 5645 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5646 | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | 5647 | | | xy | S | | | | | | 5648 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5649 | Accept | R | | o | - | - | - | - | - | 5650 | | | | | | | | | | 5651 | Accept-Credentia | R | rm | o | o | o | o | o | o | 5652 | ls | | | | | | | | | 5653 | | | | | | | | | | 5654 | Accept-Encoding | R | r | o | - | - | - | - | - | 5655 | | | | | | | | | | 5656 | Accept-Language | R | r | o | - | - | - | - | - | 5657 | | | | | | | | | | 5658 | Accept-Ranges | G | r | - | - | m | - | - | - | 5659 | | | | | | | | | | 5660 | Accept-Ranges | 456 | r | - | - | - | m | - | - | 5661 | Allow | r | am | c | c | c | - | - | - | 5662 | | | | | | | | | | 5663 | Allow | 405 | am | m | m | m | m | m | m | 5664 | | | | | | | | | | 5665 | Authentication-I | r | | o | o | o | o | o | o/- | 5666 | nfo | | | | | | | | | 5667 | | | | | | | | | | 5668 | Authorization | R | | o | o | o | o | o | o | 5669 | | | | | | | | | | 5670 | Bandwidth | R | | o | o | o | o | - | - | 5671 | | | | | | | | | | 5672 | Blocksize | R | | o | - | o | o | - | - | 5673 | | | | | | | | | | 5674 | Cache-Control | G | r | o | - | o | - | - | - | 5675 | | | | | | | | | | 5676 | Connection | G | ad | o | o | o | o | o | o | 5677 | | | | | | | | | | 5678 | Connection-Crede | 470,4 | ar | o | o | o | o | o | o | 5679 | ntials | 07 | | | | | | | | 5680 | | | | | | | | | | 5681 | Content-Base | r | | o | - | - | - | - | - | 5682 | | | | | | | | | | 5683 | Content-Base | 4xx,5 | | o | o | o | o | o | o | 5684 | | xx | | | | | | | | 5685 | | | | | | | | | | 5686 | Content-Encoding | R | r | - | - | - | - | - | - | 5687 | | | | | | | | | | 5688 | Content-Encoding | r | r | o | - | - | - | - | - | 5689 | | | | | | | | | | 5690 | Content-Encoding | 4xx,5 | r | o | o | o | o | o | o | 5691 | | xx | | | | | | | | 5692 | | | | | | | | | | 5693 | Content-Language | R | r | - | - | - | - | - | - | 5694 | | | | | | | | | | 5695 | Content-Language | r | r | o | - | - | - | - | - | 5696 | | | | | | | | | | 5697 | Content-Language | 4xx,5 | r | o | o | o | o | o | o | 5698 | | xx | | | | | | | | 5699 | | | | | | | | | | 5700 | Content-Length | r | r | * | - | - | - | - | - | 5701 | | | | | | | | | | 5702 | Content-Length | 4xx,5 | r | * | * | * | * | * | * | 5703 | | xx | | | | | | | | 5704 | | | | | | | | | | 5705 | Content-Location | r | r | o | - | - | - | - | - | 5706 | | | | | | | | | | 5707 | Content-Location | 4xx,5 | r | o | o | o | o | o | o | 5708 | | xx | | | | | | | | 5709 | Content-Type | r | r | * | - | - | - | - | - | 5710 | | | | | | | | | | 5711 | Content-Type | 4xx,5 | ar | * | * | * | * | * | * | 5712 | | xx | | | | | | | | 5713 | | | | | | | | | | 5714 | CSeq | Gc | rm | m | m | m | m | m | m | 5715 | | | | | | | | | | 5716 | Date | G | am | o/ | o/* | o/* | o/* | o/* | o/* | 5717 | | | | * | | | | | | 5718 | | | | | | | | | | 5719 | Expires | r | r | o | - | o | - | - | - | 5720 | | | | | | | | | | 5721 | From | R | r | o | o | o | o | o | o | 5722 | | | | | | | | | | 5723 | If-Match | R | r | - | - | o | - | - | - | 5724 | | | | | | | | | | 5725 | If-Modified-Sinc | R | r | o | - | o | - | - | - | 5726 | e | | | | | | | | | 5727 | | | | | | | | | | 5728 | If-None-Match | R | r | o | - | o | - | - | - | 5729 | | | | | | | | | | 5730 | Last-Modified | r | r | o | - | o | - | - | - | 5731 | | | | | | | | | | 5732 | Location | 3rr | | o | o | o | o | o | o | 5733 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5735 Table 9: Overview of RTSP header fields (A-L) related to methods 5736 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5738 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5739 | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | 5740 | | | xy | S | T | P | | | | 5741 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5742 | Media- | G | | - | - | m | m | m | - | 5743 | Properties | | | | | | | | | 5744 | | | | | | | | | | 5745 | Media-Range | G | | - | - | m | m | m | - | 5746 | | | | | | | | | | 5747 | MTag | r | r | o | - | o | - | - | - | 5748 | | | | | | | | | | 5749 | Pipelined-Reques | G | amd | - | o | o | o | o | o | 5750 | ts | | r | | | | | | | 5751 | | | | | | | | | | 5752 | Proxy- | 407 | amr | m | m | m | m | m | m | 5753 | Authenticate | | | | | | | | | 5754 | | | | | | | | | | 5755 | Proxy-Authentica | r | amd | o | o | o | o | o | o/- | 5756 | tion-Info | | r | | | | | | | 5757 | Proxy- | R | rd | o | o | o | o | o | o | 5758 | Authorization | | | | | | | | | 5759 | | | | | | | | | | 5760 | Proxy- Require | R | ar | o | o | o | o | o | o | 5761 | | | | | | | | | | 5762 | Proxy- Require | r | r | c | c | c | c | c | c | 5763 | | | | | | | | | | 5764 | Proxy- Supported | R | amr | c | c | c | c | c | c | 5765 | | | | | | | | | | 5766 | Proxy- Supported | r | | c | c | c | c | c | c | 5767 | | | | | | | | | | 5768 | Public | r | amr | - | m | - | - | - | - | 5769 | | | | | | | | | | 5770 | Public | 501 | amr | m | m | m | m | m | m | 5771 | | | | | | | | | | 5772 | Range | R | | - | - | - | o | - | - | 5773 | | | | | | | | | | 5774 | Range | r | | - | - | c | m | m | - | 5775 | | | | | | | | | | 5776 | Referrer | R | | o | o | o | o | o | o | 5777 | | | | | | | | | | 5778 | Request- Status | R | | - | - | - | - | - | - | 5779 | | | | | | | | | | 5780 | Require | R | | o | o | o | o | o | o | 5781 | | | | | | | | | | 5782 | Retry-After | 3rr,503 | | o | o | o | o | o | - | 5783 | | ,553 | | | | | | | | 5784 | | | | | | | | | | 5785 | Retry-After | 413 | | o | - | - | - | - | - | 5786 | | | | | | | | | | 5787 | RTP-Info | r | | - | - | c | c | - | - | 5788 | | | | | | | | | | 5789 | Scale | R | r | - | - | - | o | - | - | 5790 | | | | | | | | | | 5791 | Scale | r | amr | - | - | - | c | - | - | 5792 | | | | | | | | | | 5793 | Seek-Style | R | | - | - | - | o | - | - | 5794 | | | | | | | | | | 5795 | Seek-Style | r | | - | - | - | m | - | - | 5796 | | | | | | | | | | 5797 | Server | R | r | - | o | - | - | - | o | 5798 | | | | | | | | | | 5799 | Server | r | r | o | o | o | o | o | o | 5800 | | | | | | | | | | 5801 | Session | R | r | - | o | o | m | m | m | 5802 | | | | | | | | | | 5803 | Session | r | r | - | c | m | m | m | o | 5804 | | | | | | | | | | 5805 | Speed | R | adm | - | - | - | o | - | - | 5806 | | | r | | | | | | | 5807 | | | | | | | | | | 5808 | Speed | r | adm | - | - | - | c | - | - | 5809 | | | r | | | | | | | 5810 | | | | | | | | | | 5811 | Supported | R | amr | o | o | o | o | o | o | 5812 | | | | | | | | | | 5813 | Supported | r | amr | c | c | c | c | c | c | 5814 | | | | | | | | | | 5815 | Terminate-Reason | R | r | - | - | - | - | - | - | 5816 | | | | | | | | | | 5817 | Timestamp | R | adm | o | o | o | o | o | o | 5818 | | | r | | | | | | | 5819 | | | | | | | | | | 5820 | Timestamp | c | adm | m | m | m | m | m | m | 5821 | | | r | | | | | | | 5822 | | | | | | | | | | 5823 | Transport | G | mr | - | - | m | - | - | - | 5824 | | | | | | | | | | 5825 | Unsupported | r | | c | c | c | c | c | c | 5826 | | | | | | | | | | 5827 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 5828 | | | | | | | | | | 5829 | Via | R | amr | o | o | o | o | o | o | 5830 | | | | | | | | | | 5831 | Via | c | dr | m | m | m | m | m | m | 5832 | | | | | | | | | | 5833 | WWW- | 401 | | m | m | m | m | m | m | 5834 | Authenticate | | | | | | | | | 5835 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5837 Table 10: Overview of RTSP header fields (M-W) related to methods 5838 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5840 +-------------------------+---------+-------+-----+-----+-----+-----+ 5841 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5842 +-------------------------+---------+-------+-----+-----+-----+-----+ 5843 | Accept | R | arm | o | o | - | - | 5844 | | | | | | | | 5845 | Accept-Credentials | R | rm | o | o | o | - | 5846 | | | | | | | | 5847 | Accept-Encoding | R | r | o | o | o | - | 5848 | | | | | | | | 5849 | Accept-Language | R | r | o | o | o | - | 5850 | | | | | | | | 5851 | Accept-Ranges | G | rm | o | - | - | - | 5852 | | | | | | | | 5853 | Allow | 405 | amr | m | m | m | - | 5854 | | | | | | | | 5855 | Authentication-Info | r | | o/- | o/- | - | - | 5856 | | | | | | | | 5857 | Authorization | R | | o | o | o | - | 5858 | | | | | | | | 5859 | Bandwidth | R | | - | o | - | - | 5860 | | | | | | | | 5861 | Blocksize | R | | - | o | - | - | 5862 | | | | | | | | 5863 | Cache-Control | G | r | o | o | - | - | 5864 | | | | | | | | 5865 | Connection | G | | o | o | o | o | 5866 | | | | | | | | 5867 | Connection-Credentials | 470,407 | ar | o | o | o | - | 5868 | | | | | | | | 5869 | Content-Base | R | | o | o | - | - | 5870 | | | | | | | | 5871 | Content-Base | r | | o | o | - | - | 5872 | | | | | | | | 5873 | Content-Base | 4xx,5xx | | o | o | o | o | 5874 | | | | | | | | 5875 | Content-Encoding | R | r | o | o | - | - | 5876 | | | | | | | | 5877 | Content-Encoding | r | r | o | o | - | - | 5878 | | | | | | | | 5879 | Content-Encoding | 4xx,5xx | r | o | o | o | o | 5880 | | | | | | | | 5881 | Content-Language | R | r | o | o | - | - | 5882 | | | | | | | | 5883 | Content-Language | r | r | o | o | - | - | 5884 | | | | | | | | 5885 | Content-Language | 4xx,5xx | r | o | o | o | o | 5886 | | | | | | | | 5887 | Content-Length | R | r | * | * | - | - | 5888 | | | | | | | | 5889 | Content-Length | r | r | * | * | - | - | 5890 | | | | | | | | 5891 | Content-Length | 4xx,5xx | r | * | * | * | * | 5892 | | | | | | | | 5893 | Content-Location | R | | o | o | - | - | 5894 | | | | | | | | 5895 | Content-Location | r | | o | o | - | - | 5896 | | | | | | | | 5897 | Content-Location | 4xx,5xx | | o | o | o | o | 5898 | | | | | | | | 5899 | Content-Type | R | | * | * | - | - | 5900 | | | | | | | | 5901 | Content-Type | r | | * | * | - | - | 5902 | | | | | | | | 5903 | Content-Type | 4xx,5xx | | * | * | * | * | 5904 | | | | | | | | 5905 | CSeq | R,c | mr | m | m | m | m | 5906 | | | | | | | | 5907 | Date | R | a | o | o | m | o | 5908 | | | | | | | | 5909 | Date | r | am | o | o | o | o | 5910 | | | | | | | | 5911 | Expires | r | r | - | - | - | - | 5912 | | | | | | | | 5913 | From | R | r | o | o | o | - | 5914 | | | | | | | | 5915 | If-Match | R | r | - | - | - | - | 5916 | | | | | | | | 5917 | If-Modified-Since | R | am | o | - | - | - | 5918 | | | | | | | | 5919 | If-None-Match | R | am | o | - | - | - | 5920 | | | | | | | | 5921 | Last-Modified | R | r | - | - | - | - | 5922 | | | | | | | | 5923 | Last-Modified | r | r | o | - | - | - | 5924 | | | | | | | | 5925 | Location | 3rr | | o | o | o | - | 5926 | | | | | | | | 5927 | Location | R | | - | - | m | - | 5928 | | | | | | | | 5929 | Media-Properties | R | amr | o | - | - | c | 5930 | | | | | | | | 5931 | Media-Properties | r | mr | c | - | - | - | 5932 | | | | | | | | 5933 | Media-Range | R | | o | - | - | c | 5934 | | | | | | | | 5935 | Media-Range | r | | c | - | - | - | 5936 | | | | | | | | 5937 | MTag | r | r | o | - | - | - | 5938 | | | | | | | | 5939 | Notify-Reason | R | | - | - | - | m | 5940 | | | | | | | | 5941 | Pipelined-Requests | R | amdr | o | o | - | - | 5942 | | | | | | | | 5943 | Proxy-Authenticate | 407 | amdr | m | m | m | - | 5944 | | | | | | | | 5945 | Proxy-Authentication-In | r | amdr | o/- | o/- | - | - | 5946 | fo | | | | | | | 5947 | | | | | | | | 5948 | Proxy-Authorization | R | amdr | o | o | o | - | 5949 | Proxy-Require | R | ar | o | o | o | - | 5950 | | | | | | | | 5951 | Proxy-Supported | R | amr | c | c | c | - | 5952 | | | | | | | | 5953 | Proxy-Supported | r | | c | c | c | - | 5954 | | | | | | | | 5955 | Public | 501 | admr | m | m | m | - | 5956 +-------------------------+---------+-------+-----+-----+-----+-----+ 5958 Table 11: Overview of RTSP header fields (A-P) related to methods 5959 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5961 +------------------+---------+-------+-----+-----+-----+-----+ 5962 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5963 +------------------+---------+-------+-----+-----+-----+-----+ 5964 | Range | R | | o | - | o | m | 5965 | | | | | | | | 5966 | Referrer | R | | o | o | o | - | 5967 | | | | | | | | 5968 | Request-Status | R | | - | - | - | c | 5969 | | | | | | | | 5970 | Require | R | r | o | o | o | - | 5971 | | | | | | | | 5972 | Retry-After | 3rr,503 | | o | o | - | - | 5973 | | | | | | | | 5974 | Retry-After | 413 | | o | o | - | - | 5975 | | | | | | | | 5976 | RTP-Info | R | r | o | - | - | C | 5977 | | | | | | | | 5978 | RTP-Info | r | r | c | - | - | - | 5979 | | | | | | | | 5980 | Scale | G | | - | - | - | c | 5981 | | | | | | | | 5982 | Seek-Style | G | | - | - | - | - | 5983 | | | | | | | | 5984 | Server | R | r | o | o | o | o | 5985 | | | | | | | | 5986 | Server | r | r | o | o | - | - | 5987 | | | | | | | | 5988 | Session | R | r | o | o | o | m | 5989 | | | | | | | | 5990 | Session | r | r | c | c | o | m | 5991 | | | | | | | | 5992 | Speed | G | | - | - | - | - | 5993 | | | | | | | | 5994 | Supported | R | adrm | o | o | o | - | 5995 | | | | | | | | 5996 | Supported | r | adrm | c | c | c | - | 5997 | Terminate-Reason | R | r | - | - | m | - | 5998 | | | | | | | | 5999 | Timestamp | R | adrm | o | o | o | - | 6000 | | | | | | | | 6001 | Timestamp | c | adrm | m | m | m | - | 6002 | | | | | | | | 6003 | Transport | G | mr | - | - | - | - | 6004 | | | | | | | | 6005 | Unsupported | r | arm | c | c | c | - | 6006 | | | | | | | | 6007 | User-Agent | R | r | m* | m* | - | - | 6008 | | | | | | | | 6009 | User-Agent | r | r | m* | m* | m* | m* | 6010 | | | | | | | | 6011 | Via | R | amr | o | o | o | - | 6012 | | | | | | | | 6013 | Via | c | dr | m | m | m | - | 6014 | | | | | | | | 6015 | WWW-Authenticate | 401 | | m | m | m | - | 6016 +------------------+---------+-------+-----+-----+-----+-----+ 6018 Table 12: Overview of RTSP header fields (R-W) related to methods 6019 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 6021 18.1. Accept 6023 The Accept request-header field can be used to specify certain 6024 presentation description and parameter media types [RFC6838] which 6025 are acceptable for the response to DESCRIBE and GET_PARAMETER 6026 requests. 6028 See Section 20.2.3 for the syntax. 6030 The asterisk "*" character is used to group media types into ranges, 6031 with "*/*" indicating all media types and "type/*" indicating all 6032 subtypes of that type. The media-range MAY include media type 6033 parameters that are applicable to that range. 6035 Each media-range MAY be followed by one or more accept-params, 6036 beginning with the "q" parameter for indicating a relative quality 6037 factor. The first "q" parameter (if any) separates the media-range 6038 parameter(s) from the accept-params. Quality factors allow the user 6039 or user agent to indicate the relative degree of preference for that 6040 media-range, using the qvalue scale from 0 to 1 (section 3.9). The 6041 default value is q=1. 6043 Example of use: 6045 Accept: application/example ;q=0.7, application/sdp 6047 Indicates that the requesting agent prefers the media type 6048 application/sdp through the default 1.0 rating but also accepts the 6049 application/example media type with a 0.7 quality rating. 6051 If no Accept header field is present, then it is assumed that the 6052 client accepts all media types. If an Accept header field is 6053 present, and if the server cannot send a response which is acceptable 6054 according to the combined Accept field value, then the server SHOULD 6055 send a 406 (not acceptable) response. 6057 18.2. Accept-Credentials 6059 The Accept-Credentials header is a request-header used to indicate to 6060 any trusted intermediary how to handle further secured connections to 6061 proxies or servers. See Section 19 for the usage of this header. It 6062 MUST NOT be included in server to client requests. 6064 In a request the header MUST contain the method (User, Proxy, or Any) 6065 for approving credentials selected by the requester. The method MUST 6066 NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY 6067 change it to "user" to take the role of user approving each further 6068 hop. If the method is "User" the header contains zero or more of 6069 credentials that the client accepts. The header may contain zero 6070 credentials in the first RTSP request to a RTSP server when using the 6071 "User" method. This is because the client has not yet received any 6072 credentials to accept. Each credential MUST consist of one URI 6073 identifying the proxy or server, the hash algorithm identifier, and 6074 the hash over that agent's ASN.1 distinguished encoding rules (DER) 6075 encoded certificate [RFC5280] in BASE64, according to Section 4 of 6076 [RFC4648] and where the padding bits are set to zero. All RTSP 6077 clients and proxies MUST implement the SHA-256[FIPS-pub-180-2] 6078 algorithm for computation of the hash of the DER encoded certificate. 6079 The SHA-256 algorithm is identified by the token "sha-256". 6081 The intention with allowing for other hash algorithms is to enable 6082 the future retirement of algorithms that are not implemented 6083 somewhere else than here. Thus the definition of future algorithms 6084 for this purpose is intended to be extremely limited. A feature tag 6085 can be used to ensure that support for the replacement algorithm 6086 exists. 6088 Example: 6090 Accept-Credentials:User 6091 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 6092 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 6094 18.3. Accept-Encoding 6096 The Accept-Encoding request-header field is similar to Accept, but 6097 restricts the content-codings (see Section 18.15),i.e., 6098 transformation codings of the message body, such as gzip compression, 6099 that are acceptable in the response. 6101 A server tests whether a content-coding is acceptable, according to 6102 an Accept-Encoding field, using these rules: 6104 1. If the content-coding is one of the content-codings listed in the 6105 Accept-Encoding field, then it is acceptable, unless it is 6106 accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of 6107 0 means "not acceptable.") 6109 2. The special "*" symbol in an Accept-Encoding field matches any 6110 available content-coding not explicitly listed in the header 6111 field. 6113 3. If multiple content-codings are acceptable, then the acceptable 6114 content-coding with the highest non-zero qvalue is preferred. 6116 4. The "identity" content-coding is always acceptable, i.e., no 6117 transformation at all, unless specifically refused because the 6118 Accept-Encoding field includes "identity;q=0", or because the 6119 field includes "*;q=0" and does not explicitly include the 6120 "identity" content-coding. If the Accept-Encoding field-value is 6121 empty, then only the "identity" encoding is acceptable. 6123 If an Accept-Encoding field is present in a request, and if the 6124 server cannot send a response which is acceptable according to the 6125 Accept-Encoding header, then the server SHOULD send an error response 6126 with the 406 (Not Acceptable) status code. 6128 If no Accept-Encoding field is present in a request, the server MAY 6129 assume that the client will accept any content coding. In this case, 6130 if "identity" is one of the available content-codings, then the 6131 server SHOULD use the "identity" content-coding, unless it has 6132 additional information that a different content-coding is meaningful 6133 to the client. 6135 18.4. Accept-Language 6137 The Accept-Language request-header field is similar to Accept, but 6138 restricts the set of natural languages that are preferred as a 6139 response to the request. Note that the language specified applies to 6140 the presentation description and any reason phrases, but not the 6141 media content. 6143 A language tag identifies a natural language spoken, written, or 6144 otherwise conveyed by human beings for communication of information 6145 to other human beings. Computer languages are explicitly excluded. 6146 The syntax and registry of RTSP 2.0 language tags is the same as that 6147 defined by [RFC5646]. 6149 Each language-range MAY be given an associated quality value which 6150 represents an estimate of the user's preference for the languages 6151 specified by that range. The quality value defaults to "q=1". For 6152 example: 6154 Accept-Language: da, en-gb;q=0.8, en;q=0.7 6156 would mean: "I prefer Danish, but will accept British English and 6157 other types of English." A language-range matches a language-tag if 6158 it exactly equals the full tag, or if it exactly equals a prefix of 6159 the tag, i.e., the primary-tag in the ABNF, such that the character 6160 following primary-tag is "-". The special range "*", if present in 6161 the Accept-Language field, matches every tag not matched by any other 6162 range present in the Accept-Language field. 6164 Note: This use of a prefix matching rule does not imply that 6165 language tags are assigned to languages in such a way that it is 6166 always true that if a user understands a language with a certain 6167 tag, then this user will also understand all languages with tags 6168 for which this tag is a prefix. The prefix rule simply allows the 6169 use of prefix tags if this is the case. 6171 In the process of selecting a language, each language-tag is assigned 6172 a qualification factor, i.e., if a language being supported by the 6173 client is actually supported by the server and what "preference" 6174 level the language achieves. The quality value (q-value) of the 6175 longest language-range in the field that matches the language-tag is 6176 assigned as the qualification factor for a particular language-tag. 6177 If no language-range in the field matches the tag, the language 6178 qualification factor assigned is 0. If no Accept-Language header is 6179 present in the request, the server SHOULD assume that all languages 6180 are equally acceptable. If an Accept-Language header is present, 6181 then all languages which are assigned a qualification factor greater 6182 than 0 are acceptable. 6184 18.5. Accept-Ranges 6186 The Accept-Ranges general-header field allows indication of the 6187 format supported in the Range header. The client MUST include the 6188 header in SETUP requests to indicate which formats are acceptable 6189 when received in PLAY and PAUSE responses, and REDIRECT requests. 6190 The server MUST include the header in SETUP and 456 error responses 6191 to indicate the formats supported for the resource indicated by the 6192 request URI. The header MAY be included in GET_PARAMETER request and 6193 response pairs. The GET_PARAMETER request MUST contain a Session 6194 header to identify the session context the request is related to. 6195 The requester and responder will indicate their capabilities 6196 regarding Range formats respectively. 6198 Accept-Ranges: npt, smpte, clock 6200 The syntax is defined in Section 20.2.3. 6202 18.6. Allow 6204 The Allow message-body header field lists the methods supported by 6205 the resource identified by the Request-URI. The purpose of this 6206 field is to inform the recipient of the complete set of valid methods 6207 associated with the resource. An Allow header field MUST be present 6208 in a 405 (Method Not Allowed) response. The Allow header MUST also 6209 be present in all OPTIONS responses where the content of the header 6210 will not include exactly the same methods as listed in the Public 6211 header. 6213 The Allow message-body header MUST also be included in SETUP and 6214 DESCRIBE responses, if the methods allowed for the resource are 6215 different from the complete set of methods defined in this memo. 6217 Example of use: 6219 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 6221 18.7. Authentication-Info 6223 The Authentication-Info response-header is used by the server to 6224 communicate some information regarding the successful authentication 6225 in the response message. This usage of this header is specified in 6226 [RFC2617] with some RTSP clarification in Section 19.1. This header 6227 MUST only be used in response messages related to client to server 6228 requests. 6230 18.8. Authorization 6232 An RTSP client that wishes to authenticate itself with a server using 6233 authentication mechanism from HTTP [RFC2617] , usually, but not 6234 necessarily, after receiving a 401 response, does so by including an 6235 Authorization request-header field with the request. The 6236 Authorization field value consists of credentials containing the 6237 authentication information of the user agent for the realm of the 6238 resource being requested. This header MUST only be used in client to 6239 server requests. 6241 If a request is authenticated and a realm specified, the same 6242 credentials SHOULD be valid for all other requests within this realm 6243 (assuming that the authentication scheme itself does not require 6244 otherwise, such as credentials that vary according to a challenge 6245 value or using synchronized clocks). 6247 When a shared cache (see Section 16) receives a request containing an 6248 Authorization field, it MUST NOT return the corresponding response as 6249 a reply to any other request, unless one of the following specific 6250 exceptions holds: 6252 1. If the response includes the "max-age" cache-control directive, 6253 the cache MAY use that response in replying to a subsequent 6254 request. But (if the specified maximum age has passed) a proxy 6255 cache MUST first revalidate it with the origin server, using the 6256 request-headers from the new request to allow the origin server 6257 to authenticate the new request. (This is the defined behavior 6258 for max-age.) If the response includes "max-age=0", the proxy 6259 MUST always revalidate it before re-using it. 6261 2. If the response includes the "must-revalidate" cache-control 6262 directive, the cache MAY use that response in replying to a 6263 subsequent request. But if the response is stale, all caches 6264 MUST first revalidate it with the origin server, using the 6265 request-headers from the new request to allow the origin server 6266 to authenticate the new request. 6268 3. If the response includes the "public" cache-control directive, it 6269 MAY be returned in reply to any subsequent request. 6271 18.9. Bandwidth 6273 The Bandwidth request-header field describes the estimated bandwidth 6274 available to the client, expressed as a positive integer and measured 6275 in kilobits per second. The bandwidth available to the client may 6276 change during an RTSP session, e.g., due to mobility, congestion, 6277 etc. 6279 Clients may not be able to accurately determine the available 6280 bandwidth, for example because the first hop is not a bottleneck. 6281 For example most local area networks (LAN) will not be a bottleneck 6282 if the server is not in the same LAN. Thus link speeds of WLAN or 6283 Ethernet networks are normally not a basis for estimating the 6284 available bandwidth. Cellular devices or other devices directly 6285 connected to a modem or connection enabling device may more 6286 accurately estimate the bottleneck bandwidth and what is a reasonable 6287 share of it for RTSP controlled media. The client will also need to 6288 take into account other traffic sharing the bottleneck. For example 6289 by only assigning a certain fraction to RTSP and its media streams. 6290 It is RECOMMENDED that only clients that have accurate and explicit 6291 information about bandwidth bottlenecks uses this header. 6293 This header is not a substitute for proper congestion control. It is 6294 only a method providing an initial estimate and coarsely determines 6295 if the selected content can be delivered at all. 6297 Example: 6299 Bandwidth: 62360 6301 18.10. Blocksize 6303 The Blocksize request-header field is sent from the client to the 6304 media server asking the server for a particular media packet size. 6305 This packet size does not include lower-layer headers such as IP, 6306 UDP, or RTP. The server is free to use a blocksize which is lower 6307 than the one requested. The server MAY truncate this packet size to 6308 the closest multiple of the minimum, media-specific block size, or 6309 override it with the media-specific size if necessary. The block 6310 size MUST be a positive decimal number, measured in octets. The 6311 server only returns an error (4xx) if the value is syntactically 6312 invalid. 6314 18.11. Cache-Control 6316 The Cache-Control general-header field is used to specify directives 6317 that MUST be obeyed by all caching mechanisms along the request/ 6318 response chain. 6320 Cache directives MUST be passed through by a proxy or gateway 6321 application, regardless of their significance to that application, 6322 since the directives may be applicable to all recipients along the 6323 request/response chain. It is not possible to specify a cache- 6324 directive for a specific cache. 6326 Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, 6327 SET_PARAMETER and SETUP request and its response. Note: Cache- 6328 Control does not govern just the caching of responses as for HTTP, 6329 instead it also applies to the media stream identified by the SETUP 6330 request. The RTSP requests are generally not cacheable, for further 6331 information see Section 16. Below are the descriptions of the cache 6332 directives that can be included in the Cache-Control header. 6334 no-cache: Indicates that the media stream or RTSP response MUST NOT 6335 be cached anywhere. This allows an origin server to prevent 6336 caching even by caches that have been configured to return 6337 stale responses to client requests. Note, there is no security 6338 function preventing the caching of content. 6340 public: Indicates that the media stream or RTSP response is 6341 cacheable by any cache. 6343 private: Indicates that the media stream or RTSP response is 6344 intended for a single user and MUST NOT be cached by a shared 6345 cache. A private (non-shared) cache may cache the media 6346 streams. 6348 no-transform: An intermediate cache (proxy) may find it useful to 6349 convert the media type of a certain stream. A proxy might, for 6350 example, convert between video formats to save cache space or 6351 to reduce the amount of traffic on a slow link. Serious 6352 operational problems may occur, however, when these 6353 transformations have been applied to streams intended for 6354 certain kinds of applications. For example, applications for 6355 medical imaging, scientific data analysis and those using end- 6356 to-end authentication all depend on receiving a stream that is 6357 bit-for-bit identical to the original media stream or RTSP 6358 response. Therefore, if a response includes the no-transform 6359 directive, an intermediate cache or proxy MUST NOT change the 6360 encoding of the stream or response. Unlike HTTP, RTSP does not 6361 provide for partial transformation at this point, e.g., 6362 allowing translation into a different language. 6364 only-if-cached: In some cases, such as times of extremely poor 6365 network connectivity, a client may want a cache to return only 6366 those media streams or RTSP responses that it currently has 6367 stored, and not to receive these from the origin server. To do 6368 this, the client may include the only-if-cached directive in a 6369 request. If it receives this directive, a cache SHOULD either 6370 respond using a cached media stream or response that is 6371 consistent with the other constraints of the request, or 6372 respond with a 504 (Gateway Timeout) status. However, if a 6373 group of caches is being operated as a unified system with good 6374 internal connectivity, such a request MAY be forwarded within 6375 that group of caches. 6377 max-stale: Indicates that the client is willing to accept a media 6378 stream or RTSP response that has exceeded its expiration time. 6379 If max-stale is assigned a value, then the client is willing to 6380 accept a response that has exceeded its expiration time by no 6381 more than the specified number of seconds. If no value is 6382 assigned to max-stale, then the client is willing to accept a 6383 stale response of any age. 6385 min-fresh: Indicates that the client is willing to accept a media 6386 stream or RTSP response whose freshness lifetime is no less 6387 than its current age plus the specified time in seconds. That 6388 is, the client wants a response that will still be fresh for at 6389 least the specified number of seconds. 6391 must-revalidate: When the must-revalidate directive is present in a 6392 SETUP response received by a cache, that cache MUST NOT use the 6393 cache entry after it becomes stale to respond to a subsequent 6394 request without first revalidating it with the origin server. 6395 That is, the cache is required to do an end-to-end revalidation 6396 every time, if, based solely on the origin server's Expires, 6397 the cached response is stale. 6399 proxy-revalidate: The proxy-revalidate directive has the same 6400 meaning as the must-revalidate directive, except that it does 6401 not apply to non-shared user agent caches. It can be used on a 6402 response to an authenticated request to permit the user's cache 6403 to store and later return the response without needing to 6404 revalidate it (since it has already been authenticated once by 6405 that user), while still requiring proxies that service many 6406 users to revalidate each time (in order to make sure that each 6407 user has been authenticated). Note that such authenticated 6408 responses also need the public cache control directive in order 6409 to allow them to be cached at all. 6411 max-age: When an intermediate cache is forced, by means of a max- 6412 age=0 directive, to revalidate its own cache entry, and the 6413 client has supplied its own validator in the request, the 6414 supplied validator might differ from the validator currently 6415 stored with the cache entry. In this case, the cache MAY use 6416 either validator in making its own request without affecting 6417 semantic transparency. 6419 However, the choice of validator might affect performance. The 6420 best approach is for the intermediate cache to use its own 6421 validator when making its request. If the server replies with 6422 304 (Not Modified), then the cache can return its now validated 6423 copy to the client with a 200 (OK) response. If the server 6424 replies with a new message body and cache validator, however, 6425 the intermediate cache can compare the returned validator with 6426 the one provided in the client's request, using the strong 6427 comparison function. If the client's validator is equal to the 6428 origin server's, then the intermediate cache simply returns 304 6429 (Not Modified). Otherwise, it returns the new message body 6430 with a 200 (OK) response. 6432 18.12. Connection 6434 The Connection general-header field allows the sender to specify 6435 options that are desired for that particular connection. It MUST NOT 6436 be communicated by proxies over further connections. 6438 RTSP 2.0 proxies MUST parse the Connection header field before a 6439 message is forwarded and, for each connection-token in this field, 6440 remove any header field(s) from the message with the same name as the 6441 connection-token. Connection options are signaled by the presence of 6442 a connection-token in the Connection header field, not by any 6443 corresponding additional header field(s), since the additional header 6444 field may not be sent if there are no parameters associated with that 6445 connection option. 6447 Message headers listed in the Connection header MUST NOT include end- 6448 to-end headers, such as Cache-Control. 6450 RTSP 2.0 defines the "close" connection option for the sender to 6451 signal that the connection will be closed after completion of the 6452 response. For example, Connection: close in either the request or 6453 the response-header fields indicates that the connection SHOULD NOT 6454 be considered `persistent' (Section 10.2) after the current request/ 6455 response is complete. 6457 The use of the connection option "close" in RTSP messages SHOULD be 6458 limited to error messages when the server is unable to recover and 6459 therefore sees it necessary to close the connection. The reason is 6460 that the client has the choice of continuing using a connection 6461 indefinitely, as long as it sends valid messages. 6463 18.13. Connection-Credentials 6465 The Connection-Credentials response-header is used to carry the chain 6466 of credentials for any next hop that needs to be approved by the 6467 requester. It MUST only be used in server to client responses. 6469 The Connection-Credentials header in an RTSP response MUST, if 6470 included, contain the credential information (in form of a list of 6471 certificates providing the chain of certification) of the next hop 6472 that an intermediary needs to securely connect to. The header MUST 6473 include the URI of the next hop (proxy or server) and a BASE64 6474 (according to Section 4 of [RFC4648] and where the padding bits are 6475 set to zero) encoded binary structure containing a sequence of DER 6476 encoded X.509v3 certificates [RFC5280]. 6478 The binary structure starts with the number of certificates 6479 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 6480 by NR_CERTS number of 16 bit unsigned integers providing the size in 6481 octets of each DER encoded certificate. This is followed by NR_CERTS 6482 number of DER encoded X.509v3 certificates in a sequence (chain). 6483 This format is exemplified in Figure 2. The proxy or server's 6484 certificate must come first in the structure. Each following 6485 certificate must directly certify the one preceding it. Because 6486 certificate validation requires that root keys be distributed 6487 independently, the self-signed certificate which specifies the root 6488 certificate authority may optionally be omitted from the chain, under 6489 the assumption that the remote end must already possess it in order 6490 to validate it in any case. 6492 Example: 6494 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 6496 Where MIIDNTCC... is a Base64 encoding of the following structure: 6498 0 1 2 3 6499 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 6500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6501 | Number of certificates | Size of certificate #1 | 6502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6503 | Size of certificate #2 | Size of certificate #3 | 6504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6505 : DER Encoding of Certificate #1 : 6506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6507 : DER Encoding of Certificate #2 : 6508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6509 : DER Encoding of Certificate #3 : 6510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6512 Figure 2: Connection-Credentials header's Certificate Format Example 6514 18.14. Content-Base 6516 The Content-Base message-body header field may be used to specify the 6517 base URI for resolving relative URIs within the message body. 6519 Content-Base: rtsp://media.example.com/movie/twister/ 6521 If no Content-Base field is present, the base URI of an message body 6522 is defined either by its Content-Location (if that Content-Location 6523 URI is an absolute URI) or the URI used to initiate the request, in 6524 that order of precedence. Note, however, that the base URI of the 6525 contents within the message-body may be redefined within that 6526 message-body. 6528 18.15. Content-Encoding 6530 The Content-Encoding message-body header field is used as a modifier 6531 to the media-type. When present, its value indicates what additional 6532 content codings have been applied to the message body, and thus what 6533 decoding mechanisms must be applied in order to obtain the media-type 6534 referenced by the Content-Type header field. Content-Encoding is 6535 primarily used to allow a document to be compressed without losing 6536 the identity of its underlying media type. 6538 The content-coding is a characteristic of the message body identified 6539 by the Request-URI. Typically, the message body is stored with this 6540 encoding and is only decoded before rendering or analogous usage. 6541 However, an RTSP proxy MAY modify the content-coding if the new 6542 coding is known to be acceptable to the recipient, unless the "no- 6543 transform" cache-control directive is present in the message. 6545 If the content-coding of a message body is not "identity", then the 6546 response MUST include a Content-Encoding Message-body header that 6547 lists the non-identity content-coding(s) used. 6549 If the content-coding of a message body in a request message is not 6550 acceptable to the origin server, the server SHOULD respond with a 6551 status code of 415 (Unsupported Media Type). 6553 If multiple encodings have been applied to a message body, the 6554 content codings MUST be listed in the order in which they were 6555 applied, first to last from left to right. Additional information 6556 about the encoding parameters MAY be provided by other header fields 6557 not defined by this specification. 6559 18.16. Content-Language 6561 The Content-Language message-body header field describes the natural 6562 language(s) of the intended audience for the enclosed message body. 6563 Note that this might not be equivalent to all the languages used 6564 within the message body. 6566 Language tags are mentioned in Section 18.4. The primary purpose of 6567 Content-Language is to allow a user to identify and differentiate 6568 entities according to the user's own preferred language. Thus, if 6569 the body content is intended only for a Danish-literate audience, the 6570 appropriate field is 6571 Content-Language: da 6573 If no Content-Language is specified, the default is that the content 6574 is intended for all language audiences. This might mean that the 6575 sender does not consider it to be specific to any natural language, 6576 or that the sender does not know for which language it is intended. 6578 Multiple languages MAY be listed for content that is intended for 6579 multiple audiences. For example, a rendition of the "Treaty of 6580 Waitangi," presented simultaneously in the original Maori and English 6581 versions, would call for 6583 Content-Language: mi, en 6585 However, just because multiple languages are present within a message 6586 body does not mean that it is intended for multiple linguistic 6587 audiences. An example would be a beginner's language primer, such as 6588 "A First Lesson in Latin," which is clearly intended to be used by an 6589 English-literate audience. In this case, the Content-Language would 6590 properly only include "en". 6592 Content-Language MAY be applied to any media type -- it is not 6593 limited to textual documents. 6595 18.17. Content-Length 6597 The Content-Length message-body header field contains the length of 6598 the message body of the RTSP message (i.e., after the double CRLF 6599 following the last header). Unlike HTTP, it MUST be included in all 6600 messages that carry a message body beyond the header portion of the 6601 RTSP message. If it is missing, a default value of zero is assumed. 6602 Any Content-Length greater than or equal to zero is a valid value. 6604 18.18. Content-Location 6606 The Content-Location message-body header field MAY be used to supply 6607 the resource location for the message body enclosed in the message 6608 when that body is accessible from a location separate from the 6609 requested resource's URI. A server SHOULD provide a Content-Location 6610 for the variant corresponding to the response message body; 6611 especially in the case where a resource has multiple variants 6612 associated with it, and those entities actually have separate 6613 locations by which they might be individually accessed, the server 6614 SHOULD provide a Content-Location for the particular variant which is 6615 returned. 6617 As example, if an RTSP client performs a DESCRIBE request on a given 6618 resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", 6619 then the server may use additional information, such as the User- 6620 Agent header, to determine the capabilities of the agent. The server 6621 will then return a media description tailored to that class of RTSP 6622 agents. To indicate which specific description the agent receives 6623 the resource identifier 6624 ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is 6625 provided in Content-Location, while the description is still a valid 6626 response for the generic resource identifier. Thus enabling both 6627 debugging and cache operation as discussed below. 6629 The Content-Location value is not a replacement for the original 6630 requested URI; it is only a statement of the location of the resource 6631 corresponding to this particular variant at the time of the request. 6632 Future requests MAY specify the Content-Location URI as the request 6633 URI if the desire is to identify the source of that particular 6634 variant. This is useful if the RTSP agent desires to verify if the 6635 resource variant is current through a conditional request. 6637 A cache cannot assume that a message body with a Content-Location 6638 different from the URI used to retrieve it can be used to respond to 6639 later requests on that Content-Location URI. However, the Content- 6640 Location can be used to differentiate between multiple variants 6641 retrieved from a single requested resource. 6643 If the Content-Location is a relative URI, the relative URI is 6644 interpreted relative to the Request-URI. 6646 Note, that Content-Location can be used in some cases to derive the 6647 base-URI for relative URI(s) present in session description formats. 6648 This needs to be taken into account when Content-Location is used. 6649 The easiest way to avoid needing to consider that issue is to include 6650 the Content-Base whenever the Content-Location is included. 6652 Note also, when using Media Tags in conjunction with Content-Location 6653 it is important that the different versions have different MTags, 6654 even if provided under different Content-Location URIs. This as they 6655 have still been provided under the same request URI. 6657 Note also, as in most cases the URI used in the DESCRIBE and the 6658 SETUP requests are different, the URI provided in a DESCRIBE Content- 6659 Location response can't directly be used in a SETUP request. Instead 6660 the extra step of resolving URIs combined with the media descriptions 6661 indication, like with SDP's a=control attribute. 6663 18.19. Content-Type 6665 The Content-Type message-body header indicates the media type of the 6666 message body sent to the recipient. Note that the content types 6667 suitable for RTSP are likely to be restricted in practice to 6668 presentation descriptions and parameter-value types. 6670 18.20. CSeq 6672 The CSeq general-header field specifies the sequence number (integer) 6673 for an RTSP request-response pair. This field MUST be present in all 6674 requests and responses. RTSP agents maintain a sequence number 6675 series for each responder to which they have an open message 6676 transport channel. For each new RTSP request an agent originates on 6677 a particular RTSP message transport the CSeq value MUST be 6678 incremented by one. The initial sequence number MAY be any number, 6679 however, it is RECOMMENDED to start at 0. Each sequence number 6680 series is unique between each requester and responder, i.e., the 6681 client has one series for its requests to a server and the server has 6682 another when sending requests to the client. Each requester and 6683 responder is identified by its socket address (IP address and port 6684 number), i.e., per direction of a TCP connection. Any retransmitted 6685 request MUST contain the same sequence number as the original, i.e., 6686 the sequence number is not incremented for retransmissions of the 6687 same request. The RTSP agent receiving requests MUST process the 6688 requests arriving on a particular transport in the order of the 6689 sequence numbers. Responses are sent in the order that they are 6690 generated. The RTSP response MUST have the same sequence number as 6691 was present in the corresponding request. A RTSP Agent receiving a 6692 response MAY receive the responses out of order compared to the order 6693 of the requests it sent. Thus, the agent MUST use the sequence 6694 number in the response to pair it with the corresponding request. 6696 The main purpose of the sequence number is to map responses to 6697 requests. 6699 The requirement to use a sequence number increment of one for each 6700 new request is to support any future specification of RTSP message 6701 transport over a protocol that does not provide in order delivery 6702 or is unreliable. 6704 The above rules relating to the initial sequence number may appear 6705 unnecessarily loose. The reason is to cater for some common 6706 behavior of existing implementations: When using multiple reliable 6707 connections in sequence it may still be easiest to use a single 6708 sequence number series for a client connecting with a particular 6709 server. Thus, the initial sequence number may be arbitrary 6710 depending on the number of previous requests. For any unreliable 6711 transport a stricter definition or other solution will be required 6712 to enable detection of any loss of the first request. 6714 When using multiple sequential transport connections, there is no 6715 protocol mechanism to ensure in order processing as the sequence 6716 number is scoped on the individual transport connection and its 6717 five tuple. Thus, there are potential issues with opening a new 6718 transport connection to the same host for which there already 6719 exists a transport connection with outstanding requests and 6720 previously despatched requests related to the same RTSP session. 6722 RTSP Proxies also need to follow the above rules. This implies that 6723 proxies that aggregate requests from multiple clients onto a single 6724 transport towards a server or a next hop proxy need to renumber these 6725 requests to form a unified sequence on that transport, fulfilling the 6726 above rules. A proxy capable of fulfilling some agent's request 6727 without emitting its own request (e.g., a caching proxy that fulfils 6728 a request from its cache), also causes a need to renumber as the 6729 number of received requests with a particular target, may not be the 6730 same as the number of emitted requests towards that target agent. A 6731 proxy that needs to renumber, needs to perform the corresponding 6732 renumbering back to the original sequence number for any received 6733 response before forwarding it back to the originator of the request. 6735 A client connected to a proxy, and using that transport to send 6736 requests to multiple servers creates a situation where it is quite 6737 likely to receive the responses out of order. This is because the 6738 proxy will establish separate transports from the proxy to the 6739 servers on which to forward the client's requests. When the 6740 responses arrive from the different servers they will be forwarded 6741 to the client in the order they arrive at the proxy and can be 6742 processed, not the order of the client's original sequence 6743 numbers. This is intentional to avoid some session's requests 6744 being blocked by another server's slow processing of requests. 6746 18.21. Date 6748 The Date general-header field represents the date and time at which 6749 the message was originated. The inclusion of the Date header in RTSP 6750 message follows these rules: 6752 o An RTSP message, sent either by the client or the server, 6753 containing a body MUST include a Date header, if the sending host 6754 has a clock; 6756 o Clients and servers are RECOMMENDED to include a Date header in 6757 all other RTSP messages, if the sending host has a clock; 6759 o If the server does not have a clock that can provide a reasonable 6760 approximation of the current time, its responses MUST NOT include 6761 a Date header field. In this case, this rule MUST be followed: 6763 Some origin server implementations might not have a clock 6764 available. An origin server without a clock MUST NOT assign 6765 Expires or Last-Modified values to a response, unless these values 6766 were associated with the resource by a system or user with a 6767 reliable clock. It MAY assign an Expires value that is known, at 6768 or before server configuration time, to be in the past (this 6769 allows "pre-expiration" of responses without storing separate 6770 Expires values for each resource). 6772 A received message that does not have a Date header field MUST be 6773 assigned one by the recipient if the message will be cached by that 6774 recipient. An RTSP implementation without a clock MUST NOT cache 6775 responses without revalidating them on every use. An RTSP cache, 6776 especially a shared cache, SHOULD use a mechanism, such as Network 6777 Time Protocol (NTP) [RFC5905], to synchronize its clock with a 6778 reliable external standard. 6780 The RTSP-date, a full date as specified by Section 3.3 of [RFC5322], 6781 sent in a Date header SHOULD NOT represent a date and time subsequent 6782 to the generation of the message. It SHOULD represent the best 6783 available approximation of the date and time of message generation, 6784 unless the implementation has no means of generating a reasonably 6785 accurate date and time. In theory, the date ought to represent the 6786 moment just before the message body is generated. In practice, the 6787 date can be generated at any time during the message origination 6788 without affecting its semantic value. 6790 Note: The RTSP 2.0 date format is defined to be the RFC 5322 full 6791 date format. This format is more flexible than the RFC 1123 date 6792 format used by RTSP 1.0. Thus implementations should use single 6793 spaces as recommended by RFC 5322 as separators and support 6794 receiving the obsolete format. 6796 [[RFC Editor please remove this note: Prior to version 37 of the 6797 draft, rfc2326bis envisaged sticking with the RFC 1123 format.]] 6799 18.22. Expires 6801 The Expires message-body header field gives a date and time after 6802 which the description or media-stream should be considered stale. 6803 The interpretation depends on the method: 6805 DESCRIBE response: The Expires header indicates a date and time 6806 after which the presentation description (body) SHOULD be 6807 considered stale. 6809 SETUP response: The Expires header indicate a date and time after 6810 which the media stream SHOULD be considered stale. 6812 A stale cache entry may not normally be returned by a cache (either a 6813 proxy cache or an user agent cache) unless it is first validated with 6814 the origin server (or with an intermediate cache that has a fresh 6815 copy of the message body). See Section 16 for further discussion of 6816 the expiration model. 6818 The presence of an Expires field does not imply that the original 6819 resource will change or cease to exist at, before, or after that 6820 time. 6822 The format is an absolute date and time as defined by RTSP-date. An 6823 example of its use is 6825 Expires: Thu, 01 Dec 1994 16:00:00 GMT 6827 RTSP/2.0 clients and caches MUST treat other invalid date formats, 6828 especially including the value "0", as having occurred in the past 6829 (i.e., already expired). 6831 To mark a response as "already expired," an origin server should use 6832 an Expires date that is equal to the Date header value. To mark a 6833 response as "never expires," an origin server SHOULD use an Expires 6834 date approximately one year from the time the response is sent. 6835 RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in 6836 the future. 6838 18.23. From 6840 The From request-header field, if given, SHOULD contain an Internet 6841 e-mail address for the human user who controls the requesting user 6842 agent. The address SHOULD be machine-usable, as defined by "mailbox" 6843 in [RFC1123]. 6845 This header field MAY be used for logging purposes and as a means for 6846 identifying the source of invalid or unwanted requests. It SHOULD 6847 NOT be used as an insecure form of access protection. The 6848 interpretation of this field is that the request is being performed 6849 on behalf of the person given, who accepts responsibility for the 6850 method performed. In particular, robot agents SHOULD include this 6851 header so that the person responsible for running the robot can be 6852 contacted if problems occur on the receiving end. 6854 The Internet e-mail address in this field MAY be separate from the 6855 Internet host which issued the request. For example, when a request 6856 is passed through a proxy the original issuer's address SHOULD be 6857 used. 6859 The client SHOULD NOT send the From header field without the user's 6860 approval, as it might conflict with the user's privacy interests or 6861 their site's security policy. It is strongly recommended that the 6862 user be able to disable, enable, and modify the value of this field 6863 at any time prior to a request. 6865 18.24. If-Match 6867 The If-Match request-header field is especially useful for ensuring 6868 the integrity of the presentation description, independent of how the 6869 presentation description was received. The presentation description 6870 can be fetched via means external to RTSP (such as HTTP) or via the 6871 DESCRIBE message. In the case of retrieving the presentation 6872 description via RTSP, the server implementation is guaranteeing the 6873 integrity of the description between the time of the DESCRIBE message 6874 and the SETUP message. By including the MTag given in or with the 6875 session description in an If-Match header part of the SETUP request, 6876 the client ensures that resources set up are matching the 6877 description. A SETUP request with the If-Match header for which the 6878 MTag validation check fails, MUST generate a response using 412 6879 (Precondition Failed). 6881 This validation check is also very useful if a session has been 6882 redirected from one server to another. 6884 18.25. If-Modified-Since 6886 The If-Modified-Since request-header field is used with the DESCRIBE 6887 and SETUP methods to make them conditional. If the requested variant 6888 has not been modified since the time specified in this field, a 6889 description will not be returned from the server (DESCRIBE) or a 6890 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 6891 response MUST be returned without any message-body. 6893 An example of the field is: 6895 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 6897 18.26. If-None-Match 6899 This request-header can be used with one or several message body tags 6900 to make DESCRIBE requests conditional. A client that has one or more 6901 message bodies previously obtained from the resource, can verify that 6902 none of those entities is current by including a list of their 6903 associated message body tags in the If-None-Match header field. The 6904 purpose of this feature is to allow efficient updates of cached 6905 information with a minimum amount of transaction overhead. As a 6906 special case, the value "*" matches any current entity of the 6907 resource. 6909 If any of the message body tags match the message body tag of the 6910 message body that would have been returned in the response to a 6911 similar DESCRIBE request (without the If-None-Match header) on that 6912 resource, or if "*" is given and any current entity exists for that 6913 resource, then the server MUST NOT perform the requested method, 6914 unless required to do so because the resource's modification date 6915 fails to match that supplied in an If-Modified-Since header field in 6916 the request. Instead, if the request method was DESCRIBE, the server 6917 SHOULD respond with a 304 (Not Modified) response, including the 6918 cache-related header fields (particularly MTag) of one of the message 6919 bodies that matched. For all other request methods, the server MUST 6920 respond with a status of 412 (Precondition Failed). 6922 See Section 16.1.3 for rules on how to determine if two message body 6923 tags match. 6925 If none of the message body tags match, then the server MAY perform 6926 the requested method as if the If-None-Match header field did not 6927 exist, but MUST also ignore any If-Modified-Since header field(s) in 6928 the request. That is, if no message body tags match, then the server 6929 MUST NOT return a 304 (Not Modified) response. 6931 If the request would, without the If-None-Match header field, result 6932 in anything other than a 2xx or 304 status, then the If-None-Match 6933 header MUST be ignored. (See Section 16.1.4 for a discussion of 6934 server behavior when both If-Modified-Since and If-None-Match appear 6935 in the same request.) 6937 The result of a request having both an If-None-Match header field and 6938 an If-Match header field is unspecified and MUST be considered an 6939 illegal request. 6941 18.27. Last-Modified 6943 The Last-Modified message-body header field indicates the date and 6944 time at which the origin server believes the presentation description 6945 or media stream was last modified. For the method DESCRIBE, the 6946 header field indicates the last modification date and time of the 6947 description, for SETUP that of the media stream. 6949 An origin server MUST NOT send a Last-Modified date which is later 6950 than the server's time of message origination. In such cases, where 6951 the resource's last modification would indicate some time in the 6952 future, the server MUST replace that date with the message 6953 origination date. 6955 An origin server SHOULD obtain the Last-Modified value of the message 6956 body as close as possible to the time that it generates the Date 6957 value of its response. This allows a recipient to make an accurate 6958 assessment of the message body's modification time, especially if the 6959 message body changes near the time that the response is generated. 6961 RTSP servers SHOULD send Last-Modified whenever feasible. 6963 18.28. Location 6965 The Location response-header field is used to redirect the recipient 6966 to a location other than the Request-URI for completion of the 6967 request or identification of a new resource. For 3rr responses, the 6968 location SHOULD indicate the server's preferred URI for automatic 6969 redirection to the resource. The field value consists of a single 6970 absolute URI. 6972 Note: The Content-Location header field (Section 18.18) differs from 6973 Location in that the Content-Location identifies the original 6974 location of the message body enclosed in the request. It is 6975 therefore possible for a response to contain header fields for both 6976 Location and Content-Location. Also, see Section 16.2 for cache 6977 requirements of some methods. 6979 18.29. Media-Properties 6981 This general-header is used in SETUP response or PLAY_NOTIFY requests 6982 to indicate the media's properties that currently are applicable to 6983 the RTSP session. PLAY_NOTIFY MAY be used to modify these properties 6984 at any point. However, the client SHOULD have received the update 6985 prior to any action related to the new media properties taking 6986 effect. For aggregated sessions, the Media-Properties header will be 6987 returned in each SETUP response. The header received in the latest 6988 response is the one that applies on the whole session from this point 6989 until any future update. The header MAY be included without value in 6990 GET_PARAMETER requests to the server with a Session header included 6991 to query the current Media-Properties for the session. The responder 6992 MUST include the current session's media properties. 6994 The media properties expressed by this header is the one applicable 6995 to all media in the RTSP session. For aggregated sessions, the 6996 header expressed the combined media-properties. As a result, 6997 aggregation of media MAY result in a change of the media properties, 6998 and thus the content of the Media-Properties header contained in 6999 subsequent SETUP responses. 7001 The header contains a list of property values that are applicable to 7002 the currently setup media or aggregate of media as indicated by the 7003 RTSP URI in the request. No ordering is enforced within the header. 7004 Property values should be grouped into a single group that handles a 7005 particular orthogonal property. Values or groups that express 7006 multiple properties SHOULD NOT be used. The list of properties that 7007 can be expressed MAY be extended at any time. Unknown property 7008 values MUST be ignored. 7010 This specification defines the following 4 groups and their property 7011 values: 7013 Random Access: 7015 Random-Access: Indicates that random access is possible. May 7016 optionally include a floating point value in seconds indicating 7017 the longest duration between any two random access points in 7018 the media. 7020 Beginning-Only: Seeking is limited to the beginning only. 7022 No-Seeking: No seeking is possible. 7024 Content Modifications: 7026 Immutable: The content will not be changed during the life-time 7027 of the RTSP session. 7029 Dynamic: The content may be changed based on external methods or 7030 triggers 7032 Time-Progressing: The media accessible progresses as wallclock 7033 time progresses. 7035 Retention: 7037 Unlimited: Content will be retained for the duration of the life- 7038 time of the RTSP session. 7040 Time-Limited: Content will be retained at least until the 7041 specified wallclock time. The time must be provided in the 7042 absolute time format specified in Section 4.4.3. 7044 Time-Duration: Each individual media unit is retained for at 7045 least the specified time duration. This definition allows for 7046 retaining data with a time based sliding window. The time 7047 duration is expressed as floating point number in seconds. 0.0 7048 is a valid value as this indicates that no data is retained in 7049 a time-progressing session. 7051 Supported Scale: 7053 Scales: A quoted comma separated list of one or more decimal 7054 values or ranges of scale values supported by the content in 7055 arbitrary order. A range has a start and stop value separated 7056 by a colon. A range indicates that the content supports fine 7057 grained selection of scale values. Fine grained allows for 7058 steps at least as small as one tenth of a scale value. A 7059 content is considered to support fine grained selection when 7060 the server in response to a given scale value can produce 7061 content with an actual scale that is less than 1 tenth of scale 7062 unit, i.e., 0.1, from the requested value. Negative values are 7063 supported. The value 0 has no meaning and MUST NOT be used. 7065 Examples of this header for on-demand content and a live stream 7066 without recording are: 7068 On-demand: 7069 Media-Properties: Random-Access=2.5, Unlimited, Immutable, 7070 Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" 7072 Live stream without recording/timeshifting: 7073 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 7075 18.30. Media-Range 7077 The Media-Range general-header is used to give the range of the media 7078 at the time of sending the RTSP message. This header MUST be 7079 included in SETUP response, and PLAY and PAUSE response for media 7080 that are Time-Progressing, and PLAY and PAUSE response after any 7081 change for media that are Dynamic, and in PLAY_NOTIFY request that 7082 are sent due to Media-Property-Update. Media-Range header without 7083 any range specifications MAY be included in GET_PARAMETER requests to 7084 the server to request the current range. The server MUST in this 7085 case include the current range at the time of sending the response. 7087 The header MUST include range specifications for all time formats 7088 supported for the media, as indicated in Accept-Ranges header 7089 (Section 18.5) when setting up the media. The server MAY include 7090 more than one range specification of any given time format to 7091 indicate media that has non-continuous range. The range 7092 specifications SHALL be ordered with the range with the lowest value 7093 or earliest start time first, followed by ranges with increasingly 7094 higher values or later start time. 7096 For media that has the Time-Progressing property, the Media-Range 7097 values will only be valid for the particular point in time when it 7098 was issued. As wallclock progresses so will also the media range. 7099 However, it shall be assumed that media time progresses in direct 7100 relationship to wallclock time (with the exception of clock skew) so 7101 that a reasonably accurate estimation of the media range can be 7102 calculated. 7104 18.31. MTag 7106 The MTag response-header MAY be included in DESCRIBE, GET_PARAMETER 7107 or SETUP responses. The message body tags (Section 4.6) returned in 7108 a DESCRIBE response, and the one in SETUP refers to the presentation, 7109 i.e., both the returned session description and the media stream. 7110 This allows for verification that one has the right session 7111 description to a media resource at the time of the SETUP request. 7112 However, it has the disadvantage that a change in any of the parts 7113 results in invalidation of all the parts. 7115 If the MTag is provided both inside the message body, e.g., within 7116 the "a=mtag" attribute in SDP, and in the response message, then both 7117 tags MUST be identical. It is RECOMMENDED that the MTag is primarily 7118 given in the RTSP response message, to ensure that caches can use the 7119 MTag without requiring content inspection. However, for session 7120 descriptions that are distributed outside of RTSP, for example using 7121 HTTP, etc. it will be necessary to include the message body tag in 7122 the session description as specified in Appendix D.1.9. 7124 SETUP and DESCRIBE requests can be made conditional upon the MTag 7125 using the headers If-Match (Section 18.24) and If-None-Match ( 7126 Section 18.26). 7128 18.32. Notify-Reason 7130 The Notify-Reason response-header is solely used in the PLAY_NOTIFY 7131 method. It indicates the reason why the server has sent the 7132 asynchronous PLAY_NOTIFY request (see Section 13.5). 7134 18.33. Pipelined-Requests 7136 The Pipelined-Requests general-header is used to indicate that a 7137 request is to be executed in the context created by a previous 7138 request(s). The primary usage of this header is to allow pipelining 7139 of SETUP requests so that any additional SETUP request after the 7140 first one does not need to wait for the session ID to be sent back to 7141 the requesting agent. The header contains a unique identifier that 7142 is scoped by the persistent connection used to send the requests. 7144 Upon receiving a request with the Pipelined-Requests the responding 7145 agent MUST look up if there exists a binding between this Pipelined- 7146 Requests identifier for the current persistent connection and an RTSP 7147 session ID. If that exists then the received request is processed 7148 the same way as if it contained the Session header with the found 7149 session ID. If there does not exist a mapping and no Session header 7150 is included in the request, the responding agent MUST create a 7151 binding upon the successful completion of a session creating request, 7152 i.e., SETUP. A binding MUST NOT be created, if the request failed to 7153 create an RTSP session. In case the request contains both a Session 7154 header and the Pipelined-Requests header the Pipelined-Requests MUST 7155 be ignored. 7157 Note: Based on the above definition at least the first request 7158 containing a new unique Pipelined-Requests will be required to be a 7159 SETUP request (unless the protocol is extended with new methods of 7160 creating a session). After that first one, additional SETUP requests 7161 or requests of any type using the RTSP session context may include 7162 the Pipelined-Requests header. 7164 When responding to any request that contained the Pipelined-Requests 7165 header the server MUST also include the Session header when a binding 7166 to a session context exists. An RTSP agent that knows the session 7167 identifier SHOULD NOT use the Pipelined-Requests header in any 7168 request and only use the Session header. This as the Session 7169 identifier is persistent across transport contexts, like TCP 7170 connections, which the Pipelined-Requests identifier is not. 7172 The RTSP agent sending the request with a Pipelined-Requests header 7173 has the responsibility for using a unique and previously unused 7174 identifier within the transport context. Currently only a TCP 7175 connection is defined as such transport context. A server MUST 7176 delete the Pipelined-Requests identifier and its binding to a session 7177 upon the termination of that session. Despite the previous mandate, 7178 RTSP agents are RECOMMENDED to not reuse identifiers to allow for 7179 better error handling and logging. 7181 RTSP Proxies may need to translate Pipelined-Requests identifier 7182 values from incoming requests to outgoing to allow for aggregation of 7183 requests onto a persistent connection. 7185 18.34. Proxy-Authenticate 7187 The Proxy-Authenticate response-header field MUST be included as part 7188 of a 407 (Proxy Authentication Required) response. The field value 7189 consists of a challenge that indicates the authentication scheme and 7190 parameters applicable to the proxy for this Request-URI. 7192 The HTTP access authentication process is described in [RFC2617]. 7194 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 7195 only to the current connection and SHOULD NOT be passed on to 7196 downstream agents. This header MUST only be used in response 7197 messages related to client to server requests. 7199 18.35. Proxy-Authentication-Info 7201 The Proxy-Authentication-Info response-header is used by the proxy to 7202 communicate some information regarding the successful authentication 7203 to the proxy in the message response. The content and usage of this 7204 header is described in the HTTP access authentication [RFC2617] that 7205 is also used by RTSP and clarified in Section 19.1. This header MUST 7206 only be used in response messages related to client to server 7207 requests. This header has hop by hop scope. 7209 18.36. Proxy-Authorization 7211 The Proxy-Authorization request-header field allows the client to 7212 identify itself (or its user) to a proxy which requires 7213 authentication. The Proxy-Authorization field value consists of 7214 credentials containing the authentication information of the user 7215 agent for the proxy and/or realm of the resource being requested. 7217 The HTTP access authentication process is described in [RFC2617]. 7218 Unlike Authorization, the Proxy-Authorization header field applies 7219 only to the next hop proxy. This header MUST only be used in client 7220 to server requests. 7222 18.37. Proxy-Require 7224 The Proxy-Require request-header field is used to indicate proxy- 7225 sensitive features that MUST be supported by the proxy. Any Proxy- 7226 Require header features that are not supported by the proxy MUST be 7227 negatively acknowledged by the proxy to the client using the 7228 Unsupported header. The proxy MUST use the 551 (Option Not 7229 Supported) status code in the response. Any feature-tag included in 7230 the Proxy-Require does not apply to the end-point (server or client). 7231 To ensure that a feature is supported by both proxies and servers the 7232 tag needs to be included in also a Require header. 7234 See Section 18.43 for more details on the mechanics of this message 7235 and a usage example. See discussion in the proxies section 7236 (Section 15.1) about when to consider that a feature requires proxy 7237 support. 7239 Example of use: 7241 Proxy-Require: play.basic 7243 18.38. Proxy-Supported 7245 The Proxy-Supported general-header field enumerates all the 7246 extensions supported by the proxy using feature-tags. The header 7247 carries the intersection of extensions supported by the forwarding 7248 proxies. The Proxy-Supported header MAY be included in any request 7249 by a proxy. It MUST be added by any proxy if the Supported header is 7250 present in a request. When present in a request, the receiver MUST 7251 in the response copy the received Proxy-Supported header. 7253 The Proxy-Supported header field contains a list of feature-tags 7254 applicable to proxies, as described in Section 4.5. The list is the 7255 intersection of all feature-tags understood by the proxies. To 7256 achieve an intersection, the proxy adding the Proxy-Supported header 7257 includes all proxy feature-tags it understands. Any proxy receiving 7258 a request with the header, MUST check the list and removes any 7259 feature-tag(s) it does not support. A Proxy-Supported header present 7260 in the response MUST NOT be modified by the proxies. These feature 7261 tags are the ones the proxy chain support in general, and is not 7262 specific to the request resource. 7264 Example: 7266 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 7267 Supported: foo, bar, blech 7268 User-Agent: PhonyClient/1.2 7270 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 7271 Supported: foo, bar, blech 7272 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 7273 Via: 2.0 pro.example.com 7275 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 7276 Supported: foo, bar, blech 7277 Proxy-Supported: proxy-foo, proxy-blech 7278 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7280 S->C: RTSP/2.0 200 OK 7281 Supported: foo, bar, baz 7282 Proxy-Supported: proxy-foo, proxy-blech 7283 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7284 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7286 18.39. Public 7288 The Public response-header field lists the set of methods supported 7289 by the response sender. This header applies to the general 7290 capabilities of the sender and its only purpose is to indicate the 7291 sender's capabilities to the recipient. The methods listed may or 7292 may not be applicable to the Request-URI; the Allow header field 7293 (Section 18.6) MAY be used to indicate methods allowed for a 7294 particular URI. 7296 Example of use: 7298 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7300 In the event that there are proxies between the sender and the 7301 recipient of a response, each intervening proxy MUST modify the 7302 Public header field to remove any methods that are not supported via 7303 that proxy. The resulting Public header field will contain an 7304 intersection of the sender's methods and the methods allowed through 7305 by the intervening proxies. 7307 In general, proxies should allow all methods to transparently pass 7308 through from the sending RTSP agent to the receiving RTSP agent, 7309 but there may be cases where this is not desirable for a given 7310 proxy. Modification of the Public response-header field by the 7311 intervening proxies ensures that the request sender gets an 7312 accurate response indicating the methods that can be used on the 7313 target agent via the proxy chain. 7315 18.40. Range 7317 The Range general-header specifies a time range in PLAY 7318 (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT 7319 (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and 7320 responses. It MAY be included in GET_PARAMETER requests from the 7321 client to the server with only a Range format and no value to request 7322 the current media position, whether the session is in Play or Ready 7323 state in the included format. The server SHALL, if supporting the 7324 range format, respond with the current playing point or pause point 7325 as the start of the range. If an explicit stop point was used in the 7326 previous PLAY request, then that value shall be included as stop 7327 point. Note that if the server is currently under any type of media 7328 playback manipulation affecting the interpretation of Range, like 7329 Scale, that is also required to be included in any GET_PARAMETER 7330 response to provide complete information. 7332 The range can be specified in a number of units. This specification 7333 defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock 7334 (Section 4.4.3) range units. While octet ranges (Byte Ranges) 7335 [H14.35.1] and other extended units MAY be used, their behavior is 7336 unspecified since they are not normally meaningful in RTSP. Servers 7337 supporting the Range header MUST understand the NPT range format and 7338 SHOULD understand the SMPTE range format. If the Range header is 7339 sent in a time format that is not understood, the recipient SHOULD 7340 return 456 (Header Field Not Valid for Resource) and include an 7341 Accept-Ranges header indicating the supported time formats for the 7342 given resource. 7344 Example: 7346 Range: clock=19960213T143205Z- 7348 The Range header contains a range of one single range format. A 7349 range is a half-open interval with a start and an end point, 7350 including the start point, but excluding the end point. A range may 7351 either be fully specified with explicit values for start point and 7352 end point, or have either start or end point be implicit. An 7353 implicit start point indicates the session's pause point, and if no 7354 pause point is set the start of the content. An implicit end point 7355 indicates the end of the content. The usage of both implicit start 7356 and end point is not allowed in the same range header, however, the 7357 exclusion of the range header has that meaning, i.e., from pause 7358 point (or start) until end of content. 7360 Regarding the half-open intervals; a range of A-B starts exactly 7361 at time A, but ends just before B. Only the start time of a media 7362 unit such as a video or audio frame is relevant. For example, 7363 assume that video frames are generated every 40 ms. A range of 7364 10.0-10.1 would include a video frame starting at 10.0 or later 7365 time and would include a video frame starting at 10.08, even 7366 though it lasted beyond the interval. A range of 10.0-10.08, on 7367 the other hand, would exclude the frame at 10.08. 7369 Please note the difference between NPT time scales' "now" and an 7370 implicit start value. Implicit value reference the current pause- 7371 point. While "now" is the currently ongoing time. In a time- 7372 progressing session with recording (retention for some or full 7373 time) the pause point may be 2 min into the session while now 7374 could be 1 hour into the session. 7376 By default, range intervals increase, where the second point is 7377 larger than the first point. 7379 Example: 7381 Range: npt=10-15 7383 However, range intervals can also decrease if the Scale header (see 7384 Section 18.46) indicates a negative scale value. For example, this 7385 would be the case when a playback in reverse is desired. 7387 Example: 7389 Scale: -1 7390 Range: npt=15-10 7392 Decreasing ranges are still half open intervals as described above. 7393 Thus, for range A-B, A is closed and B is open. In the above 7394 example, 15 is closed and 10 is open. An exception to this rule is 7395 the case when B=0 in a decreasing range. In this case, the range is 7396 closed on both ends, as otherwise there would be no way to reach 0 on 7397 a reverse playback for formats that have such a notion, like NPT and 7398 SMPTE. 7400 Example: 7402 Scale: -1 7403 Range: npt=15-0 7405 In this range both 15 and 0 are closed. 7407 A decreasing range interval without a corresponding negative Scale 7408 header is not valid. 7410 18.41. Referrer 7412 The Referrer request-header field allows the client to specify, for 7413 the server's benefit, the address (URI) of the resource from which 7414 the Request-URI was obtained. The URI refers to that of the 7415 presentation description, typically retrieved via HTTP. The Referrer 7416 request-header allows a server to generate lists of back-links to 7417 resources for interest, logging, optimized caching, etc. It also 7418 allows obsolete or mistyped links to be traced for maintenance. The 7419 Referrer field MUST NOT be sent if the Request-URI was obtained from 7420 a source that does not have its own URI, such as input from the user 7421 keyboard. 7423 If the field value is a relative URI, it SHOULD be interpreted 7424 relative to the Request-URI. The URI MUST NOT include a fragment 7425 identifier. 7427 Because the source of a link might be private information or might 7428 reveal an otherwise private information source, it is strongly 7429 recommended that the user be able to select whether or not the 7430 Referrer field is sent. For example, a streaming client could have a 7431 toggle switch for openly/anonymously, which would respectively 7432 enable/disable the sending of Referrer and From information. 7434 Clients SHOULD NOT include a Referrer header field in a (non-secure) 7435 RTSP request if the referring page was transferred with a secure 7436 protocol. 7438 18.42. Request-Status 7440 This request-header is used to indicate the end result for requests 7441 that take time to complete, such as PLAY (Section 13.4). It is sent 7442 in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report 7443 how the PLAY request concluded, either in success or in failure. The 7444 header carries a reference to the request it reports on using the 7445 CSeq number for the session indicated by the Session header in the 7446 request. It provides both a numerical status code (according to 7447 Section 8.1.1) and a human readable reason phrase. 7449 Example: 7450 Request-Status: cseq=63 status=500 reason="Media data unavailable" 7452 18.43. Require 7454 The Require request-header field is used by agents to ensure that the 7455 other end-point supports features that are required in respect to 7456 this request. It can also be used to query if the other end-point 7457 supports certain features, however, the use of the Supported general- 7458 header (Section 18.51) is much more effective in this purpose. In 7459 case any of the feature-tags listed by the Require header are not 7460 supported by the server or client receiving the request, it MUST 7461 respond to the request using the error code 551 (Option Not 7462 Supported) and include the Unsupported header listing those feature- 7463 tags which are NOT supported. This header does not apply to proxies, 7464 for the same functionality in respect to proxies see Proxy-Require 7465 header (Section 18.37) with the exception of media modifying proxies. 7466 Media modifying proxies, due to their nature of handling media in a 7467 way that is very similar to a server, do need to understand also the 7468 server's features to correctly serve the client. 7470 This is to make sure that the client-server interaction will 7471 proceed without delay when all features are understood by both 7472 sides, and only slow down if features are not understood (as in 7473 the example below). For a well-matched client-server pair, the 7474 interaction proceeds quickly, saving a round-trip often required 7475 by negotiation mechanisms. In addition, it also removes state 7476 ambiguity when the client requires features that the server does 7477 not understand. 7479 Example (Not complete): 7481 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 7482 CSeq: 302 7483 Require: funky-feature 7484 Funky-Parameter: funkystuff 7486 S->C: RTSP/2.0 551 Option not supported 7487 CSeq: 302 7488 Unsupported: funky-feature 7490 In this example, "funky-feature" is the feature-tag which indicates 7491 to the client that the fictional Funky-Parameter field is required. 7492 The relationship between "funky-feature" and Funky-Parameter is not 7493 communicated via the RTSP exchange, since that relationship is an 7494 immutable property of "funky-feature" and thus should not be 7495 transmitted with every exchange. 7497 Proxies and other intermediary devices MUST ignore this header. If a 7498 particular extension requires that intermediate devices support it, 7499 the extension should be tagged in the Proxy-Require field instead 7500 (see Section 18.37). See discussion in the proxies section 7501 (Section 15.1) about when to consider that a feature requires proxy 7502 support. 7504 18.44. Retry-After 7506 The Retry-After response-header field can be used with a 503 (Service 7507 Unavailable) or 553 (Proxy Unavailable) response to indicate how long 7508 the service is expected to be unavailable to the requesting client. 7509 This field MAY also be used with any 3rr (Redirection) response to 7510 indicate the minimum time the user-agent is asked to wait before 7511 issuing the redirected request. The value of this field can be 7512 either an RTSP-date or an integer number of seconds (in decimal) 7513 after the time of the response. 7515 Example: 7517 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 7518 Retry-After: 120 7520 In the latter example, the delay is 2 minutes. 7522 18.45. RTP-Info 7524 The RTP-Info general-header field is used to set RTP-specific 7525 parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY 7526 and GET_PARAMETER requests. For streams using RTP as transport 7527 protocol the RTP-Info header SHOULD be part of a 200 response to 7528 PLAY. 7530 The exclusion of the RTP-Info in a PLAY response for RTP 7531 transported media will result in a client needing to synchronize 7532 the media streams using RTCP. This may have negative impact as 7533 the RTCP can be lost, and does not need to be particularly timely 7534 in its arrival. Also functionality that informs the client from 7535 which packet a seek has occurred is affected. 7537 The RTP-Info MAY be included in SETUP responses to provide 7538 synchronization information when changing transport parameters, see 7539 Section 13.3. The RTP-Info header and the Range header MAY be 7540 included in a GET_PARAMETER request from client to server without any 7541 values to request the current playback point and corresponding RTP 7542 synchronization information. When the RTP-Info header is included in 7543 a Request the Range header MUST also be included (Note, Range header 7544 only MAY be used). The server response SHALL include both the Range 7545 header and the RTP-Info header. If the session is in Play state, 7546 then the value of the Range header SHALL be filled in with the 7547 current playback point and with the corresponding RTP-Info values. 7548 If the server is another state, no values are included in the RTP- 7549 Info header. The header is included in PLAY_NOTIFY requests with the 7550 Notify-Reason of end-of-stream to provide RTP information about the 7551 end of the stream. 7553 The header can carry the following parameters: 7555 url: Indicates the stream URI for which the following RTP parameters 7556 correspond, this URI MUST be the same as used in the SETUP 7557 request for this media stream. Any relative URI MUST use the 7558 Request-URI as base URI. This parameter MUST be present. 7560 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 7561 sequence number provided applies to. This parameter MUST be 7562 present. 7564 seq: Indicates the sequence number of the first packet of the stream 7565 that is direct result of the request. This allows clients to 7566 gracefully deal with packets when seeking. The client uses 7567 this value to differentiate packets that originated before the 7568 seek from packets that originated after the seek. Note that a 7569 client may not receive the packet with the expressed sequence 7570 number, and instead packets with a higher sequence number, due 7571 to packet loss or reordering. This parameter is RECOMMENDED to 7572 be present. 7574 rtptime: MUST indicate the RTP timestamp value corresponding to the 7575 start time value in the Range response-header, or if not 7576 explicitly given the implied start point. The client uses this 7577 value to calculate the mapping of RTP time to NPT or other 7578 media timescale. This parameter SHOULD be present to ensure 7579 inter-media synchronization is achieved. There exists no 7580 requirement that any received RTP packet will have the same RTP 7581 timestamp value as the one in the parameter used to establish 7582 synchronization. 7584 A mapping from RTP timestamps to Network Time Protocol (NTP) 7585 format timestamps (wallclock) is available via RTCP. However, 7586 this information is not sufficient to generate a mapping from RTP 7587 timestamps to media clock time (NPT, etc.). Furthermore, in order 7588 to ensure that this information is available at the necessary time 7589 (immediately at startup or after a seek), and that it is delivered 7590 reliably, this mapping is placed in the RTSP control channel. 7592 In order to compensate for drift for long, uninterrupted 7593 presentations, RTSP clients should additionally map NPT to NTP, 7594 using initial RTCP sender reports to do the mapping, and later 7595 reports to check drift against the mapping. 7597 Example: 7599 Range:npt=3.25-15 7600 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 7601 rtptime=12345678,url="rtsp://example.com/foo/video" 7602 ssrc=9A9DE123:seq=30211;rtptime=29567112 7604 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video 7605 a 90kHz RTP timestamp clock. Then the media synchronization is 7606 depicted in the following way. 7608 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 7609 Audio PA A 7610 Video V PV 7612 X: NPT time value = 3.25, from Range header. 7613 A: RTP timestamp value for Audio from RTP-Info header (12345678). 7614 V: RTP timestamp value for Video from RTP-Info header (29567112). 7615 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 7616 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 7617 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 7618 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 7620 18.46. Scale 7622 The Scale general-header indicates the requested or used view rate 7623 for the media resource being played back. A scale value of 1 7624 indicates normal play at the normal forward viewing rate. If not 1, 7625 the value corresponds to the rate with respect to normal viewing 7626 rate. For example, a ratio of 2 indicates twice the normal viewing 7627 rate ("fast forward") and a ratio of 0.5 indicates half the normal 7628 viewing rate. In other words, a ratio of 2 has content time increase 7629 at twice the playback time. For every second of elapsed (wallclock) 7630 time, 2 seconds of content time will be delivered. A negative value 7631 indicates reverse direction. For certain media transports this may 7632 require certain considerations to work consistent, see Appendix C.1 7633 for description on how RTP handles this. 7635 The transmitted data rate SHOULD NOT be changed by selection of a 7636 different scale value. The resulting bit-rate should be reasonably 7637 close to the nominal bit-rate of the content for Scale = 1. The 7638 server has to actively manipulate the data when needed to meet the 7639 bitrate constraints. Implementation of scale changes depends on the 7640 server and media type. For video, a server may, for example, deliver 7641 only key frames or selected frames. For audio, it may time-scale the 7642 audio while preserving pitch or, less desirably, deliver fragments of 7643 audio, or completely mute the audio. 7645 The server and content may restrict the range of scale values that it 7646 supports. The supported values are indicated by the Media-Properties 7647 header (Section 18.29). The client SHOULD only indicate request 7648 values to be supported. However, as the values may change as the 7649 content progresses a requested value may no longer be valid when the 7650 request arrives. Thus, a non-supported value in a request does not 7651 generate an error, only forces the server to choose the closest 7652 value. The response MUST always contain the actual scale value 7653 chosen by the server. 7655 If the server does not implement the possibility to scale, it will 7656 not return a Scale header. A server supporting Scale operations for 7657 PLAY MUST indicate this with the use of the "play.scale" feature-tag. 7659 When indicating a negative scale for a reverse playback, the Range 7660 header MUST indicate a decreasing range as described in 7661 Section 18.40. 7663 Example of playing in reverse at 3.5 times normal rate: 7665 Scale: -3.5 7666 Range: npt=15-10 7668 18.47. Seek-Style 7670 When a client sends a PLAY request with a Range header to perform a 7671 random access to the media, the client does not know if the server 7672 will pick the first media samples or the first random access point 7673 prior to the request range. Depending on use case, the client may 7674 have a strong preference. To express this preference and provide the 7675 client with information on how the server actually acted on that 7676 preference the Seek-Style general-header is defined. 7678 Seek-Style is a general-header that MAY be included in any PLAY 7679 request to indicate the client's preference for any media stream that 7680 has random access properties. The server MUST always include the 7681 header in any PLAY response for media with random access properties 7682 to indicate what policy was applied. A server that receives an 7683 unknown Seek-Style policy MUST ignore it and select the server 7684 default policy. A client receiving an unknown policy MUST ignore it 7685 and use the Range header and any media synchronization information as 7686 basis to determine what the server did. 7688 This specification defines the following seek policies that may be 7689 requested (see also Section 4.7.1): 7691 RAP: Random Access Point (RAP) is the behavior of requesting the 7692 server to locate the closest previous random access point that 7693 exists in the media aggregate and deliver from that. By 7694 requesting a RAP, media quality will be the best possible as all 7695 media will be delivered from a point where full media state can be 7696 established in the media decoder. 7698 CoRAP: Conditional Random Access Point (CoRAP) is a variant of the 7699 above RAP behavior. This policy is primarily intended for cases 7700 where there is larger distance between the random access points in 7701 the media. CoRAP is conditioned on that there is a Random Access 7702 Point closer to the requested start point than to the current 7703 pause point. This policy assumes that the media state existing 7704 prior to the pause is usable if delivery is continued. If the 7705 client or server knows that this is not the fact the RAP policy 7706 should be used. In other words: in most cases when the client 7707 requests a start point prior to the current pause point, a valid 7708 decoding dependency chain from the media delivered prior to the 7709 pause and to the requested media unit will not exist. If the 7710 server searched to a random access point the server MUST return 7711 the CoRAP policy in the Seek-Style header and adjust the Range 7712 header to reflect the position of the picked RAP. In case the 7713 random access point is further away and the server selects to 7714 continue from the current pause point it MUST include the "Next" 7715 policy in the Seek-Style header and adjust the Range header start 7716 point to the current pause point. 7718 First-Prior: The first-prior policy will start delivery with the 7719 media unit that has a playout time first prior to the requested 7720 time. For discrete media that would only include media units that 7721 would still be rendered at the request time. For continuous media 7722 that is media that will be rendered during the requested start 7723 time of the range. 7725 Next: The next media units after the provided start time of the 7726 range. For continuous framed media that would mean the first next 7727 frame after the provided time. For discrete media the first unit 7728 that is to be rendered after the provided time. The main usage 7729 for this case is when the client knows it has all media up to a 7730 certain point and would like to continue delivery so that a 7731 complete non-interrupted media playback can be achieved. Example 7732 of such scenarios include switching from a broadcast/multicast 7733 delivery to a unicast based delivery. This policy MUST only be 7734 used on the client's explicit request. 7736 Please note that these expressed preferences exist for optimizing the 7737 startup time or the media quality. The "Next" policy breaks the 7738 normal definition of the Range header to enable a client to request 7739 media with minimal overlap, although some may still occur for 7740 aggregated sessions. RAP and First-Prior both fulfill the 7741 requirement of providing media from the requested range and forward. 7742 However, unless RAP is used, the media quality for many media codecs 7743 using predictive methods can be severely degraded unless additional 7744 data is available as, for example, already buffered, or through other 7745 side channels. 7747 18.48. Server 7749 The Server general-header field contains information about the 7750 software used by the origin server to create or handle the request. 7751 The field can contain multiple product tokens and comments 7752 identifying the server and any significant subproducts. The product 7753 tokens are listed in order of their significance for identifying the 7754 application. 7756 Example: 7758 Server: PhonyServer/1.0 7760 If the response is being forwarded through a proxy, the proxy 7761 application MUST NOT modify the Server response-header. Instead, it 7762 SHOULD include a Via field (Section 18.57). If the response is 7763 generated by the proxy, the proxy application MUST return the Server 7764 response-header as previously returned by the server. 7766 18.49. Session 7768 The Session general-header field identifies an RTSP session. An RTSP 7769 session is created by the server as a result of a successful SETUP 7770 request and in the response the session identifier is given to the 7771 client. The RTSP session exists until destroyed by a TEARDOWN, 7772 REDIRECT or timed out by the server. 7774 The session identifier is chosen by the server (see Section 4.3) and 7775 MUST be returned in the SETUP response. Once a client receives a 7776 session identifier, it MUST be included in any request related to 7777 that session. This means that the Session header MUST be included in 7778 a request, using the following methods: PLAY, PAUSE, and TEARDOWN, 7779 and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, 7780 and REDIRECT, and MUST NOT be included in DESCRIBE. The Session 7781 header MUST NOT be included in the following methods, if these 7782 requests are pipelined and if the session identifier is not yet 7783 known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and 7784 GET_PARAMETER. 7786 In an RTSP response the session header MUST be included in methods, 7787 SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and 7788 REDIRECT, and if included in the request of the following methods it 7789 MUST also be included in the response, OPTIONS, GET_PARAMETER, and 7790 SET_PARAMETER, and MUST NOT be included in DESCRIBE responses. 7792 Note that a session identifier identifies an RTSP session across 7793 transport sessions or connections. RTSP requests for a given session 7794 can use different URIs (Presentation and media URIs). Note, that 7795 there are restrictions depending on the session which URIs that are 7796 acceptable for a given method. However, multiple "user" sessions for 7797 the same URI from the same client will require use of different 7798 session identifiers. 7800 The session identifier is needed to distinguish several delivery 7801 requests for the same URI coming from the same client. 7803 The response 454 (Session Not Found) MUST be returned if the session 7804 identifier is invalid. 7806 The header MAY include a parameter for session timeout period. If 7807 not explicitly provided this value is set to 60 seconds. As this 7808 affects how often session keep-alives are needed values smaller than 7809 30 seconds are not recommended. However, larger than default values 7810 can be useful in applications of RTSP that have inactive but 7811 established sessions for longer time periods. 7813 60 seconds was chosen as session timeout value due to: Resulting 7814 in not too frequent keep-alive messages and having low sensitivity 7815 to variations in request response timing. If one reduces the 7816 timeout value to below 30 seconds the corresponding request 7817 response timeout becomes a significant part of the session 7818 timeout. 60 seconds also allows for reasonably rapid recovery of 7819 committed server resources in case of client failure. 7821 18.50. Speed 7823 The Speed general-header field requests the server to deliver 7824 specific amounts of nominal media time per unit of delivery time, 7825 contingent on the server's ability and desire to serve the media 7826 stream at the given speed. The client requests the delivery speed to 7827 be within a given range with a lower and upper bound. The server 7828 SHALL deliver at the highest possible speed within the range, but not 7829 faster than the upper-bound, for which the underlying network path 7830 can support the resulting transport data rates. As long as any speed 7831 value within the given range can be provided the server SHALL NOT 7832 modify the media quality. Only if the server is unable to deliver 7833 media at the speed value provided by the lower bound shall it reduce 7834 the media quality. 7836 Implementation of the Speed functionality by the server is OPTIONAL. 7837 The server can indicate its support through a feature-tag, 7838 play.speed. The lack of a Speed header in the response is an 7839 indication of lack of support of this functionality. 7841 The speed parameter values are expressed as a positive decimal value, 7842 e.g., a value of 2.0 indicates that data is to be delivered twice as 7843 fast as normal. A speed value of zero is invalid. The range is 7844 specified in the form "lower bound - upper bound". The lower bound 7845 value may be smaller or equal to the upper bound. All speeds may not 7846 be possible to support. Therefore the server MAY modify the 7847 requested values to the closest supported. The actual supported 7848 speed MUST be included in the response. Note, however, that the use 7849 cases may vary and that Speed value ranges such as 0.7 - 0.8, 7850 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 7852 Example: 7854 Speed: 1.0-2.5 7856 Use of this header changes the bandwidth used for data delivery. It 7857 is meant for use in specific circumstances where delivery of the 7858 presentation at a higher or lower rate is desired. The main use 7859 cases are buffer operations or local scale operations. Implementors 7860 should keep in mind that bandwidth for the session may be negotiated 7861 beforehand (by means other than RTSP), and therefore re-negotiation 7862 may be necessary. To perform Speed operations the server needs to 7863 ensure that the network path can support the resulting bit-rate. 7864 Thus the media transport needs to support feedback so that the server 7865 can react and adapt to the available bitrate. 7867 18.51. Supported 7869 The Supported general-header enumerates all the extensions supported 7870 by the client or server using feature tags. The header carries the 7871 extensions supported by the message sending client or server. The 7872 Supported header MAY be included in any request. When present in a 7873 request, the receiver MUST respond with its corresponding Supported 7874 header. Note that the Supported header is also included in 4xx and 7875 5xx responses. 7877 The Supported header contains a list of feature-tags, described in 7878 Section 4.5, that are understood by the client or server. These 7879 feature tags are the ones the server or client support in general, 7880 and is not specific to the request resource. 7882 Example: 7884 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 7885 Supported: foo, bar, blech 7886 User-Agent: PhonyClient/1.2 7888 S->C: RTSP/2.0 200 OK 7889 Supported: bar, blech, baz 7891 18.52. Terminate-Reason 7893 The Terminate-Reason request-header allows the server when sending a 7894 REDIRECT or TEARDOWN request to provide a reason for the session 7895 termination and any additional information. This specification 7896 identifies three reasons for Redirections and may be extended in the 7897 future: 7899 Server-Admin: The server needs to be shutdown for some 7900 administrative reason. 7902 Session-Timeout: A client's session has been kept alive for extended 7903 periods of time and the server has determined that it needs to 7904 reclaim the resources associated with this session. 7906 Internal-Error An internal error that is impossible to recover from 7907 has occurred forcing the server to terminate the session. 7909 The Server may provide additional parameters containing information 7910 around the redirect. This specification defines the following ones. 7912 time: Provides a wallclock time when the server will stop providing 7913 any service. 7915 user-msg: An UTF-8 text string with a message from the server to the 7916 user. This message SHOULD be displayed to the user. 7918 18.53. Timestamp 7920 The Timestamp general-header describes when the agent sent the 7921 request. The value of the timestamp is of significance only to the 7922 agent and may use any timescale. The responding agent MUST echo the 7923 exact same value and MAY, if it has accurate information about this, 7924 add a floating point number indicating the number of seconds that has 7925 elapsed since it has received the request. The timestamp can be used 7926 by the agent to compute the round-trip time to the responding agent 7927 so that it can adjust the timeout value for retransmissions when 7928 running over an unreliable protocol. It also resolves retransmission 7929 ambiguities for unreliable transport of RTSP. 7931 Note that the present specification provides only for reliable 7932 transport of RTSP messages. The Timestamp general-header is 7933 specified in case the protocol is extended in the future to use 7934 unreliable transport. 7936 18.54. Transport 7938 The Transport general-header indicates which transport protocol is to 7939 be used and configures its parameters such as destination address, 7940 compression, multicast time-to-live and destination port for a single 7941 stream. It sets those values not already determined by a 7942 presentation description. 7944 A Transport request-header MAY contain a list of transport options 7945 acceptable to the client, in the form of multiple transport 7946 specification entries. Transport specifications are comma separated, 7947 listed in decreasing order of preference. Each transport 7948 specification consists of a transport protocol identifier, followed 7949 by any number of parameters, each parameter separated by a semicolon. 7950 A Transport request-header MAY contain multiple transport 7951 specifications using the same transport protocol Identifier. The 7952 server MUST return a Transport response-header in the response to 7953 indicate the values actually chosen if any. If no transport 7954 specification is supported, no transport header is returned and the 7955 response MUST use the status code 461 (Unsupported Transport) 7956 (Section 17.4.26). In case more than one transport specification was 7957 present in the request, the server MUST return the single transport 7958 specification (transport-spec) which was actually chosen, if any. 7959 The number of transport-spec entries is expected to be limited as the 7960 client will receive guidance on what configurations that are possible 7961 from the presentation description. 7963 The Transport header MAY also be used in subsequent SETUP requests to 7964 change transport parameters. A server MAY refuse to change 7965 parameters of an existing stream. 7967 The transport protocol identifier defines for each transport 7968 specification which transport protocol to use and any related rules. 7969 Each transport protocol identifier defines the parameters that are 7970 required to occur; additional optional parameters MAY occur. This 7971 flexibility is provided as parameters may be different and provide 7972 different options to the RTSP Agent. A transport specification may 7973 only contain one of any given parameter within it. A parameter 7974 consists of a name and optionally a value string. Parameters MAY be 7975 given in any order. Additionally, a transport specification may only 7976 contain either of the unicast or the multicast transport type 7977 parameter. The transport protocol identifier and all parameters need 7978 to be understood in a transport specification; if not, the transport 7979 specification MUST be ignored. An RTSP proxy of any type that uses 7980 or modifies the transport specification, e.g., access proxy or 7981 security proxy, MUST remove specifications with unknown parameters 7982 before forwarding the RTSP message. If that results in no remaining 7983 transport specification the proxy SHALL send a 461 (Unsupported 7984 Transport) (Section 17.4.26) response without any Transport header. 7986 The Transport header is restricted to describing a single media 7987 stream. (RTSP can also control multiple streams as a single 7988 entity.) Making it part of RTSP rather than relying on a 7989 multitude of session description formats greatly simplifies 7990 designs of firewalls. 7992 The general syntax for the transport protocol identifier is a list of 7993 slash separated tokens: 7995 Value1/Value2/Value3... 7997 Which for RTP transports take the form: 7999 RTP/profile/lower-transport. 8001 The default value for the "lower-transport" parameters is specific to 8002 the profile. For RTP/AVP, the default is UDP. 8004 There are two different methods for how to specify where the media 8005 should be delivered for unicast transport: 8007 dest_addr: The presence of this parameter and its values indicates 8008 the destination address or addresses (host address and port 8009 pairs for IP flows) necessary for the media transport. 8011 No dest_addr: The lack of the dest_addr parameter indicates that the 8012 server MUST send media to the same address from which the RTSP 8013 messages originates. 8015 The choice of method for indicating where the media is to be 8016 delivered depends on the use case. In some cases the only allowed 8017 method will be to use no explicit address indication and have the 8018 server deliver media to the source of the RTSP messages. 8020 For Multicast there is several methods for specifying addresses but 8021 they are different in how they work compared with unicast: 8023 dest_addr with client picked address: The address and relevant 8024 parameters, like TTL (scope), for the actual multicast group to 8025 deliver the media to. There are security implications 8026 (Section 21) with this method that need to be addressed if 8027 using this method because a RTSP server can be used as a Denial 8028 of Service (DoS) attacker on an existing multicast group. 8030 dest_addr using Session Description Information: The information 8031 included in the transport header can all be coming from the 8032 session description, e.g., the SDP c= and m= line. This 8033 mitigates some of the security issues of the previous methods 8034 as it is the session provider that picks the multicast group 8035 and scope. The client MUST include the information if it is 8036 available in the session description. 8038 No dest_addr: The behavior when no explicit multicast group is 8039 present in a request is not defined. 8041 An RTSP proxy will need to take care. If the media is not desired to 8042 be routed through the proxy, the proxy will need to introduce the 8043 destination indication. 8045 Below are the configuration parameters associated with transport: 8047 General parameters: 8049 unicast / multicast: This parameter is a mutually exclusive 8050 indication of whether unicast or multicast delivery will be 8051 attempted. One of the two values MUST be specified. Clients 8052 that are capable of handling both unicast and multicast 8053 transmission need to indicate such capability by including two 8054 full transport-specs with separate parameters for each. 8056 layers: The number of multicast layers to be used for this media 8057 stream. The layers are sent to consecutive addresses starting 8058 at the dest_addr address. If the parameter is not included, it 8059 defaults to a single layer. 8061 dest_addr: A general destination address parameter that can contain 8062 one or more address specifications. Each combination of 8063 protocol/profile/lower transport needs to have the format and 8064 interpretation of its address specification defined. For RTP/ 8065 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8066 containing a host address and port. Note, only a single 8067 destination parameter per transport spec is intended. The 8068 usage of multiple destinations to distribute a single media to 8069 multiple entities is unspecified. 8071 The client originating the RTSP request MAY specify the 8072 destination address of the stream recipient with the host 8073 address part of the tuple. When the destination address is 8074 specified, the recipient may be a different party than the 8075 originator of the request. To avoid becoming the unwitting 8076 perpetrator of a remote-controlled denial-of-service attack, a 8077 server MUST perform security checks (see Section 21.2.1) and 8078 SHOULD log such attempts before allowing the client to direct a 8079 media stream to a recipient address not chosen by the server. 8080 Implementations cannot rely on TCP as reliable means of client 8081 identification. If the server does not allow the host address 8082 part of the tuple to be set, it MUST return 463 (Destination 8083 Prohibited). 8085 The host address part of the tuple MAY be empty, for example 8086 ":58044", in cases when it is desired to specify only the 8087 destination port. Responses to requests including the 8088 Transport header with a dest_addr parameter SHOULD include the 8089 full destination address that is actually used by the server. 8090 The server MUST NOT remove address information present already 8091 in the request when responding unless the protocol requires it. 8093 src_addr: A general source address parameter that can contain one or 8094 more address specifications. Each combination of protocol/ 8095 profile/lower transport needs to have the format and 8096 interpretation of its address specification defined. For RTP/ 8097 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8098 containing a host address and port. 8100 This parameter MUST be specified by the server if it transmits 8101 media packets from another address than the one RTSP messages 8102 are sent to. This will allow the client to verify source 8103 address and give it a destination address for its RTCP feedback 8104 packets, if RTP is used. The address or addresses indicated in 8105 the src_addr parameter SHOULD be used both for sending and 8106 receiving of the media stream's data packets. The main reasons 8107 are threefold: First, indicating the port and source address(s) 8108 lets the receiver know where from the packets is expected to 8109 originate. Secondly, traversal of NATs is greatly simplified 8110 when traffic is flowing symmetrically over a NAT binding. 8111 Thirdly, certain NAT traversal mechanisms, needs to know to 8112 which address and port to send so called "binding packets" from 8113 the receiver to the sender, thus creating an address binding in 8114 the NAT that the sender to receiver packet flow can use. 8116 This information may also be available through SDP. 8117 However, since this is more a feature of transport than 8118 media initialization, the authoritative source for this 8119 information should be in the SETUP response. 8121 mode: The mode parameter indicates the methods to be supported for 8122 this session. Currently defined valid values are "PLAY". If 8123 not provided, the default is "PLAY". The "RECORD" value was 8124 defined in RFC 2326 and is in this specification unspecified 8125 but reserved. RECORD and other values may be specified in the 8126 future. 8128 interleaved: The interleaved parameter implies mixing the media 8129 stream with the control stream in whatever protocol is being 8130 used by the control stream, using the mechanism defined in 8131 Section 14. The argument provides the channel number to be 8132 used in the $ block (see Section 14) and MUST be present. This 8133 parameter MAY be specified as an interval, e.g., 8134 interleaved=4-5 in cases where the transport choice for the 8135 media stream requires it, e.g., for RTP with RTCP. The channel 8136 number given in the request is only a guidance from the client 8137 to the server on what channel number(s) to use. The server MAY 8138 set any valid channel number in the response. The declared 8139 channel(s) are bi-directional, so both end-parties MAY send 8140 data on the given channel. One example of such usage is the 8141 second channel used for RTCP, where both server and client send 8142 RTCP packets on the same channel. 8144 This allows RTP/RTCP to be handled similarly to the way 8145 that it is done with UDP, i.e., one channel for RTP and 8146 the other for RTCP. 8148 MIKEY: This parameter is used in conjunction with transport 8149 specifications that can utilize MIKEY [RFC3830] for security 8150 context establishment. So far only the SRTP based RTP profiles 8151 SAVP and SAVPF can utilize MIKEY and this is defined in 8152 Appendix C.1.4.1. This parameter can be included both in 8153 request and response messages. The binary MIKEY message SHALL 8154 be BASE64 [RFC4648] encoded before being included in the value 8155 part of the parameter, where the encoding adheres to the 8156 definition in Section 4 of RFC 4648 and where the padding bits 8157 are set to zero. 8159 Multicast-specific: 8161 ttl: multicast time-to-live for IPv4. When included in requests the 8162 value indicate the TTL value that the client requests the 8163 server to use. In a response, the value actually being used by 8164 the server is returned. A server will need to consider what 8165 values that are reasonable and also the authority of the user 8166 to set this value. Corresponding functions are not needed for 8167 IPv6 as the scoping is part of the IPv6 multicast address 8168 [RFC4291]. 8170 RTP-specific: 8172 These parameters MAY only be used if the media transport protocol is 8173 RTP. 8175 ssrc: The ssrc parameter, if included in a SETUP response, indicates 8176 the RTP SSRC [RFC3550] value(s) that will be used by the media 8177 server for RTP packets within the stream. It is expressed as 8178 an eight digit hexadecimal value. 8180 The ssrc parameter MUST NOT be specified in requests. The 8181 functionality of specifying the ssrc parameter in a SETUP 8182 request is deprecated as it is incompatible with the 8183 specification of RTP in RFC 3550[RFC3550]. If the parameter is 8184 included in the Transport header of a SETUP request, the server 8185 SHOULD ignore it, and choose appropriate SSRCs for the stream. 8186 The server SHOULD set the ssrc parameter in the Transport 8187 header of the response. 8189 RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing 8190 [RFC5761] on a single underlying transport stream / flow. The 8191 presence of this parameter in a SETUP request indicates the 8192 client's support and requires the server to use RTP and RTCP 8193 multiplexing. The client SHALL only include one transport 8194 stream in the Transport header specification. To provide the 8195 server with a choice between using RTP/RTCP multiplexing or 8196 not, two different transport header specifications must be 8197 included. 8199 The parameters setup and connection defined below MAY only be used if 8200 the media transport protocol of the lower-level transport is 8201 connection-oriented (such as TCP). However, these parameters MUST 8202 NOT be used when interleaving data over the RTSP connection. 8204 setup: Clients use the setup parameter on the Transport line in a 8205 SETUP request, to indicate the roles it wishes to play in a TCP 8206 connection. This parameter is adapted from [RFC4145]. We 8207 discuss the use of this parameter in RTP/AVP/TCP non- 8208 interleaved transport in Appendix C.2.2; the discussion below 8209 is limited to syntactic issues. Clients may specify the 8210 following values for the setup parameter: 8212 active: The client will initiate an outgoing connection. 8214 passive: The client will accept an incoming connection. 8216 actpass: The client is willing to accept an incoming 8217 connection or to initiate an outgoing connection. 8219 If a client does not specify a setup value, the "active" value 8220 is assumed. 8222 In response to a client SETUP request where the setup parameter 8223 is set to "active", a server's 2xx reply MUST assign the setup 8224 parameter to "passive" on the Transport header line. 8226 In response to a client SETUP request where the setup parameter 8227 is set to "passive", a server's 2xx reply MUST assign the setup 8228 parameter to "active" on the Transport header line. 8230 In response to a client SETUP request where the setup parameter 8231 is set to "actpass", a server's 2xx reply MUST assign the setup 8232 parameter to "active" or "passive" on the Transport header 8233 line. 8235 Note that the "holdconn" value for setup is not defined for 8236 RTSP use, and MUST NOT appear on a Transport line. 8238 connection: Clients use the connection parameter in a transport 8239 specification part of the Transport header in a SETUP request, 8240 to indicate the client's preference for either reusing an 8241 existing connection between client and server (in which case 8242 the client sets the "connection" parameter to "existing"), or 8243 requesting the creation of a new connection between client and 8244 server (in which cast the client sets the "connection" 8245 parameter to "new"). Typically, clients use the "new" value 8246 for the first SETUP request for a URL, and "existing" for 8247 subsequent SETUP requests for a URL. 8249 If a client SETUP request assigns the "new" value to 8250 "connection", the server response MUST also assign the "new" 8251 value to "connection" on the Transport line. 8253 If a client SETUP request assigns the "existing" value to 8254 "connection", the server response MUST assign a value of 8255 "existing" or "new" to "connection" on the Transport line, at 8256 its discretion. 8258 The default value of "connection" is "existing", for all SETUP 8259 requests (initial and subsequent). 8261 The combination of transport protocol, profile and lower transport 8262 needs to be defined. A number of combinations are defined in the 8263 Appendix C. 8265 Below is a usage example, showing a client advertising the capability 8266 to handle multicast or unicast, preferring multicast. Since this is 8267 a unicast-only stream, the server responds with the proper transport 8268 parameters for unicast. 8270 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 8271 CSeq: 302 8272 Transport: RTP/AVP;multicast;mode="PLAY", 8273 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8274 "192.0.2.5:3457";mode="PLAY" 8275 Accept-Ranges: npt, smpte, clock 8276 User-Agent: PhonyClient/1.2 8278 S->C: RTSP/2.0 200 OK 8279 CSeq: 302 8280 Date: Thu, 23 Jan 1997 15:35:06 GMT 8281 Session: 47112344 8282 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8283 "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ 8284 "192.0.2.224:6257";mode="PLAY" 8285 Accept-Ranges: npt 8286 Media-Properties: Random-Access=0.6, Dynamic, 8287 Time-Limited=20081128T165900 8289 18.55. Unsupported 8291 The Unsupported response-header lists the features not supported by 8292 the responding RTSP agent. In the case where the feature was 8293 specified via the Proxy-Require field (Section 18.37), if there is a 8294 proxy on the path between the client and the server, the proxy MUST 8295 send a response message with a status code of 551 (Option Not 8296 Supported). The request MUST NOT be forwarded. 8298 See Section 18.43 for a usage example. 8300 18.56. User-Agent 8302 The User-Agent general-header field contains information about the 8303 user agent originating the request or producing a response. This is 8304 for statistical purposes, the tracing of protocol violations, and 8305 automated recognition of user agents for the sake of tailoring 8306 responses to avoid particular user agent limitations. User agents 8307 SHOULD include this field with requests. The field can contain 8308 multiple product tokens and comments identifying the agent and any 8309 subproducts which form a significant part of the user agent. By 8310 convention, the product tokens are listed in order of their 8311 significance for identifying the application. 8313 Example: 8315 User-Agent: PhonyClient/1.2 8317 18.57. Via 8319 The Via general-header field MUST be used by proxies to indicate the 8320 intermediate protocols and recipients between the user agent and the 8321 server on requests, and between the origin server and the client on 8322 responses. The field is intended to be used for tracking message 8323 forwards, avoiding request loops, and identifying the protocol 8324 capabilities of all senders along the request/response chain. 8326 Multiple Via field values represents each proxy that has forwarded 8327 the message. Each recipient MUST append its information such that 8328 the end result is ordered according to the sequence of forwarding 8329 applications. 8331 Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by 8332 default, forward the names and ports of hosts within the private/ 8333 protected region. This information SHOULD only be propagated if 8334 explicitly enabled. If not enabled, the via-received of any host 8335 behind the firewall/NAT SHOULD be replaced by an appropriate 8336 pseudonym for that host. 8338 For organizations that have strong privacy requirements for hiding 8339 internal structures, a proxy MAY combine an ordered subsequence of 8340 Via header field entries with identical sent-protocol values into a 8341 single such entry. Applications MUST NOT combine entries which have 8342 different received-protocol values. 8344 18.58. WWW-Authenticate 8346 The WWW-Authenticate response-header field MUST be included in 401 8347 (Unauthorized) response messages. The field value consists of at 8348 least one challenge that indicates the authentication scheme(s) and 8349 parameters applicable to the Request-URI. This header MUST only be 8350 used in response messages related to client to server requests. 8352 The HTTP access authentication process is described in [RFC2617] with 8353 some clarification in Section 19.1. User agents are advised to take 8354 special care in parsing the WWW-Authenticate field value as it might 8355 contain more than one challenge, or if more than one WWW-Authenticate 8356 header field is provided, the contents of a challenge itself can 8357 contain a comma-separated list of authentication parameters. 8359 19. Security Framework 8361 The RTSP security framework consists of two high level components: 8362 the pure authentication mechanisms based on HTTP authentication, and 8363 the message transport protection based on TLS, which is independent 8364 of RTSP. Because of the similarity in syntax and usage between RTSP 8365 servers and HTTP servers, the security for HTTP is re-used to a large 8366 extent. 8368 19.1. RTSP and HTTP Authentication 8370 RTSP and HTTP share common authentication schemes, and thus follow 8371 the same usage guidelines as specified in [RFC2617] with the 8372 additions for digest authentication specified below in 8373 Section 19.1.1. Servers SHOULD implement both basic and digest 8374 [RFC2617] authentication. Clients MUST implement both basic and 8375 digest authentication [RFC2617] so that a server that requires the 8376 client to authenticate can trust that the capability is present. 8378 It should be stressed that using the HTTP authentication alone does 8379 not provide full control message security. Therefore, in 8380 environments requiring tighter security for the control messages, TLS 8381 SHOULD be used, see Section 19.2. Any RTSP message containing an 8382 Authorization header using basic authorization MUST be using a TLS 8383 connection with confidentiality protection enabled, i.e., no NULL 8384 encryption. 8386 In cases where there is a chain of proxies between the client and the 8387 server, each proxy may individually request the client or previous 8388 proxy to authenticate itself. This is done using the Proxy- 8389 Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36) 8390 and the Proxy-Authentication-Info (Section 18.35) headers. These 8391 headers are hop-by-hop headers and are only scoped to the current 8392 connection and hop. Thus if a proxy chain exists, a proxy connecting 8393 to another proxy will have to act as a client to authorize itself 8394 towards the next proxy. The WWW-Authenticate (Section 18.58), 8395 Authorization (Section 18.8) and Authentication-Info (Section 18.7) 8396 headers are end-to-end and must not be modified by proxies. 8398 This authentication mechanism works only for client to server 8399 requests as currently defined. This leaves server to client request 8400 outside of the context of TLS based communication more vulnerable to 8401 message injection attacks on the client. Based on the server to 8402 client methods that exist, the potential risks are various; hijacking 8403 (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks 8404 with uncertain results (SET_PARAMETER). 8406 19.1.1. Digest Authentication 8408 This section describes the modifications and clarifications required 8409 to apply the HTTP Digest authentication scheme to RTSP. The RTSP 8410 scheme usage is almost completely identical to that for HTTP 8411 [RFC2617]. These are based on the procedures defined for SIP 2.0 8412 [RFC3261]. 8414 The rules for Digest authentication follow those defined in 8415 [RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the 8416 following differences: 8418 1. Use the ABNF specified in this document, rather than the one in 8419 [RFC2617]. Consequently the following is assured: 8421 * Using the right RTSP URIs allowed in the challenge as well as 8422 in the digest. 8424 * Resolved the error in the "uri" parameter of the Authorization 8425 header in [RFC2617]. 8427 2. If MTags are used then the example procedure for choosing a nonce 8428 based on Etag can work based on replacing ETag with the MTag. 8430 3. As a clarification to the calculation of the A2 value for message 8431 integrity assurance in the Digest authentication scheme, 8432 implementers should assume, when the entity-body is empty (that 8433 is, when the RTSP messages have no message body) that the hash of 8434 the message-body resolves to the MD5 hash of an empty string, or: 8435 H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e". 8437 4. RFC 2617 notes that a cnonce value MUST NOT be sent in an 8438 Authorization (and by extension Proxy-Authorization) header field 8439 if no qop directive has been sent. Therefore, any algorithms 8440 that have a dependency on the cnonce (including "MD5-Sess") 8441 require that the qop directive be sent. Use of the "qop" 8442 parameter is optional in RFC 2617 for the purposes of backwards 8443 compatibility with RFC 2069; since this specification defines 8444 RTSP 2.0 there is no backwards compatibility issue with 8445 mandating. Thus, all RTSP agents MUST implement qop-options. 8447 19.2. RTSP over TLS 8449 RTSP agents MUST implement RTSP over TLS as defined in this section 8450 and the next Section 19.3. RTSP MUST follow the same guidelines with 8451 regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. 8452 RTSP over TLS is separated from unsecured RTSP both on the URI level 8453 and the port level. Instead of using the "rtsp" scheme identifier in 8454 the URI, the "rtsps" scheme identifier MUST be used to signal RTSP 8455 over TLS. If no port is given in a URI with the "rtsps" scheme, port 8456 322 MUST be used for TLS over TCP/IP. 8458 When a client tries to setup an insecure channel to the server (using 8459 the "rtsp" URI), and the policy for the resource requires a secure 8460 channel, the server MUST redirect the client to the secure service by 8461 sending a 301 redirect response code together with the correct 8462 Location URI (using the "rtsps" scheme). A user or client MAY 8463 upgrade a non secured URI to a secured by changing the scheme from 8464 "rtsp" to "rtsps". A server implementing support for "rtsps" MUST 8465 allow this. 8467 It should be noted that TLS allows for mutual authentication (when 8468 using both server and client certificates). Still, one of the more 8469 common ways TLS is used is to only provide server side authentication 8470 (often to avoid client certificates). TLS is then used in addition 8471 to HTTP authentication, providing transport security and server 8472 authentication, while HTTP Authentication is used to authenticate the 8473 client. 8475 RTSP includes the possibility to keep a TCP session up between the 8476 client and server, throughout the RTSP session lifetime. It may be 8477 convenient to keep the TCP session, not only to save the extra setup 8478 time for TCP, but also the extra setup time for TLS (even if TLS uses 8479 the resume function, there will be almost two extra round trips). 8480 Still, when TLS is used, such behavior introduces extra active state 8481 in the server, not only for TCP and RTSP, but also for TLS. This may 8482 increase the vulnerability to DoS attacks. 8484 There exists a potential security vulnerability when reusing TCP and 8485 TLS state for different resources (URIs). If two different host 8486 names point at the same IP address it can be desirable to re-use the 8487 TCP/TLS connection to that server. In that case the RTSP agent 8488 having the TCP/TLS connection MUST verify that the server certificate 8489 associated with the connection has a SubjectAltName matching the host 8490 name present in the URI for the resource an RTSP request is to be 8491 issued for. 8493 In addition to these recommendations, Section 19.3 gives further 8494 recommendations of TLS usage with proxies. 8496 19.3. Security and Proxies 8498 The nature of a proxy is often to act as a "man-in-the-middle", while 8499 security is often about preventing the existence of a "man-in-the- 8500 middle". This section provides clients with the possibility to use 8501 proxies even when applying secure transports (TLS) between the RTSP 8502 agents. The TLS proxy mechanism allows for server and proxy 8503 identification using certificates. However, the client cannot be 8504 identified based on certificates. The client needs to select between 8505 using the procedure specified below or using a TLS connection 8506 directly (by-passing any proxies) to the server. The choice may be 8507 dependent on policies. 8509 There are in general two categories of proxies, the transparent 8510 proxies (of which the client is not aware) and the non-transparent 8511 proxies (of which the client is aware). This memo specifies only 8512 non-transparent RTSP proxies, i.e., proxies visible to the RTSP 8513 client and RTSP server. An infrastructure based on proxies requires 8514 that the trust model is such that both client and servers can trust 8515 the proxies to handle the RTSP messages correctly. To be able to 8516 trust a proxy, the client and server also need to be aware of the 8517 proxy. Hence, transparent proxies cannot generally be seen as 8518 trusted and will not work well with security (unless they work only 8519 at the transport layer). In the rest of this section any reference 8520 to proxy will be to a non-transparent proxy, which inspects or 8521 manipulates the RTSP messages. 8523 HTTP Authentication is built on the assumption of proxies and can 8524 provide user-proxy authentication and proxy-proxy/server 8525 authentication in addition to the client-server authentication. 8527 When TLS is applied and a proxy is used, the client will connect to 8528 the proxy's address when connecting to any RTSP server. This implies 8529 that for TLS, the client will authenticate the proxy server and not 8530 the end server. Note that when the client checks the server 8531 certificate in TLS, it MUST check the proxy's identity (URI or 8532 possibly other known identity) against the proxy's identity as 8533 presented in the proxy's Certificate message. 8535 The problem is that for a proxy accepted by the client, the proxy 8536 needs to be provided information on which grounds it should accept 8537 the next-hop certificate. Both the proxy and the user may have rules 8538 for this, and the user should have the possibility to select the 8539 desired behavior. To handle this case, the Accept-Credentials header 8540 (See Section 18.2) is used, where the client can request the proxy/ 8541 proxies to relay back the chain of certificates used to authenticate 8542 any intermediate proxies as well as the server. The assumption that 8543 the proxies are viewed as trusted, gives the user a possibility to 8544 enforce policies to each trusted proxy of whether it should accept 8545 the next agent in the chain. However, it should be noted that not 8546 all deployments will return the chain of certificates used to 8547 authenticate any intermediate proxies as well as the server. An 8548 operator of such a deployment may want to hide its topology from the 8549 client. It should be noted well that the client does not have any 8550 insight into the proxy's operation. Even if the proxy is trusted, it 8551 can still return an incomplete chain of certificates. 8553 A proxy MUST use TLS for the next hop if the RTSP request includes a 8554 "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between 8555 client and proxy, or between proxy and proxy), even if the resource 8556 and the end server are not required to use it. The proxy MUST, when 8557 initiating the next hop TLS connection, use the incoming TLS 8558 connections cipher suite list, only modified by removing any cipher 8559 suites that the proxy does not support. In case a proxy fails to 8560 establish a TLS connection due to cipher suite mismatch between proxy 8561 and next hop proxy or server, this is indicated using error code 472 8562 (Failure to establish secure connection). 8564 19.3.1. Accept-Credentials 8566 The Accept-Credentials header can be used by the client to distribute 8567 simple authorization policies to intermediate proxies. The client 8568 includes the Accept-Credentials header to dictate how the proxy 8569 treats the server/next proxy certificate. There are currently three 8570 methods defined: 8572 Any: which means that the proxy (or proxies) MUST accept whatever 8573 certificate is presented. This is of course not a recommended 8574 option to use, but may be useful in certain circumstances (such 8575 as testing). 8577 Proxy: which means that the proxy (or proxies) MUST use its own 8578 policies to validate the certificate and decide whether to 8579 accept it or not. This is convenient in cases where the user 8580 has a strong trust relation with the proxy. Reasons why a 8581 strong trust relation may exist are: personal/company proxy, 8582 proxy has a out-of-band policy configuration mechanism. 8584 User: which means that the proxy (or proxies) MUST send credential 8585 information about the next hop to the client for authorization. 8586 The client can then decide whether the proxy should accept the 8587 certificate or not. See Section 19.3.2 for further details. 8589 If the Accept-Credentials header is not included in the RTSP request 8590 from the client, then the "Proxy" method MUST be used as default. If 8591 another method than the "Proxy" is to be used, then the Accept- 8592 Credentials header MUST be included in all of the RTSP requests from 8593 the client. This is because it cannot be assumed that the proxy 8594 always keeps the TLS state or the user's previous preference between 8595 different RTSP messages (in particular if the time interval between 8596 the messages is long). 8598 With the "Any" and "Proxy" methods the proxy will apply the policy as 8599 defined for each method. If the policy does not accept the 8600 credentials of the next hop, the proxy MUST respond with a message 8601 using status code 471 (Connection Credentials not accepted). 8603 An RTSP request in the direction server to client MUST NOT include 8604 the Accept-Credentials header. As for the non-secured communication, 8605 the possibility for these requests depends on the presence of a 8606 client established connection. However, if the server to client 8607 request is in relation to a session established over a TLS secured 8608 channel, it MUST be sent in a TLS secured connection. That secured 8609 connection MUST also be the one used by the last client to server 8610 request. If no such transport connection exists at the time when the 8611 server desires to send the request, the server MUST discard the 8612 message. 8614 Further policies MAY be defined and registered, but should be done so 8615 with caution. 8617 19.3.2. User approved TLS procedure 8619 For the "User" method, each proxy MUST perform the following 8620 procedure for each RTSP request: 8622 o Setup the TLS session to the next hop if not already present 8623 (i.e., run the TLS handshake, but do not send the RTSP request). 8625 o Extract the peer certificate chain for the TLS session. 8627 o Check if a matching identity and hash of the peer certificate is 8628 present in the Accept-Credentials header. If present, send the 8629 message to the next hop, and conclude these procedures. If not, 8630 go to the next step. 8632 o The proxy responds to the RTSP request with a 470 or 407 response 8633 code. The 407 response code MAY be used when the proxy requires 8634 both user and connection authorization from user or client. In 8635 this message the proxy MUST include a Connection-Credentials 8636 header, see Section 18.13 with the next hop's identity and 8637 certificate. 8639 The client MUST upon receiving a 470 or 407 response with Connection- 8640 Credentials header take the decision on whether to accept the 8641 certificate or not (if it cannot do so, the user SHOULD be 8642 consulted). If the certificate is accepted, the client has to again 8643 send the RTSP request. In that request the client has to include the 8644 Accept-Credentials header including the hash over the DER encoded 8645 certificate for all trusted proxies in the chain. 8647 Example: 8649 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8650 CSeq: 2 8651 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8652 "192.0.2.5:4589" 8653 Accept-Ranges: npt, smpte, clock 8654 Accept-Credentials: User 8656 P->C: RTSP/2.0 470 Connection Authorization Required 8657 CSeq: 2 8658 Connection-Credentials: "rtsps://test.example.org"; 8659 MIIDNTCCAp... 8661 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8662 CSeq: 3 8663 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8664 "192.0.2.5:4589" 8665 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8666 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8667 Accept-Ranges: npt, smpte, clock 8669 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8670 CSeq: 3 8671 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8672 "192.0.2.5:4589" 8673 Via: RTSP/2.0 proxy.example.org 8674 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8675 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8676 Accept-Ranges: npt, smpte, clock 8678 One implication of this process is that the connection for secured 8679 RTSP messages may take significantly more round-trip times for the 8680 first message. A complete extra message exchange between the proxy 8681 connecting to the next hop and the client results because of the 8682 process for approval for each hop. However, if each message contains 8683 the chain of proxies that the requester accepts, the remaining 8684 message exchange should not be delayed. The procedure of including 8685 the credentials in each request rather than building state in each 8686 proxy, avoids the need for revocation procedures. 8688 20. Syntax 8690 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 8691 as defined in RFC 5234 [RFC5234]. It uses the basic definitions 8692 present in RFC 5234. 8694 Please note that ABNF strings, e.g., "Accept", are case insensitive 8695 as specified in section 2.3 of RFC 5234. 8697 The RTSP syntax makes use of the ISO 10646 character set in UTF-8 8698 encoding RFC 3629 [RFC3629]. 8700 20.1. Base Syntax 8702 RTSP header values can be folded onto multiple lines if the 8703 continuation line begins with a space or horizontal tab. All linear 8704 white space, including folding, has the same semantics as SP. A 8705 recipient MAY replace any linear white space with a single SP before 8706 interpreting the field value or forwarding the message downstream. 8707 This is intended to behave exactly as HTTP/1.1 as described in RFC 8708 2616 [RFC2616]. The SWS construct is used when linear white space is 8709 optional, generally between tokens and separators. 8711 To separate the header name from the rest of value, a colon is used, 8712 which, by the above rule, allows whitespace before, but no line 8713 break, and whitespace after, including a line break. The HCOLON 8714 defines this construct. 8716 OCTET = %x00-FF ; any 8-bit sequence of data 8717 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 8718 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 8719 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 8720 ALPHA = UPALPHA / LOALPHA 8721 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 8722 CTL = %x00-1F / %x7F ; any US-ASCII control character 8723 ; (octets 0 - 31) and DEL (127) 8724 CR = %x0D ; US-ASCII CR, carriage return (13) 8725 LF = %x0A ; US-ASCII LF, linefeed (10) 8726 SP = %x20 ; US-ASCII SP, space (32) 8727 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 8728 BACKSLASH = %x5C ; US-ASCII backslash (92) 8729 CRLF = CR LF 8730 LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space 8731 SWS = [LWS] ; Separating White Space 8732 HCOLON = *( SP / HT ) ":" SWS 8733 TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs 8734 tspecials = "(" / ")" / "<" / ">" / "@" 8735 / "," / ";" / ":" / BACKSLASH / DQUOTE 8736 / "/" / "[" / "]" / "?" / "=" 8737 / "{" / "}" / SP / HT 8738 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 8739 / %x41-5A / %x5E-7A / %x7C / %x7E) 8740 ; 1* 8741 quoted-string = ( DQUOTE *qdtext DQUOTE ) 8742 qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair 8743 / UTF8-NONASCII 8744 ; No DQUOTE and no "\" 8745 quoted-pair = "\\" / ( "\" DQUOTE ) 8746 ctext = %x20-27 / %x2A-7E 8747 / %x80-FF ; any OCTET except CTLs, "(" and ")" 8748 generic-param = token [ EQUAL gen-value ] 8749 gen-value = token / host / quoted-string 8751 safe = "$" / "-" / "_" / "." / "+" 8752 extra = "!" / "*" / "'" / "(" / ")" / "," 8753 rtsp-extra = "!" / "*" / "'" / "(" / ")" 8755 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 8756 / "a" / "b" / "c" / "d" / "e" / "f" 8757 LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 8758 ; lowercase "a-f" Hex 8759 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 8761 unreserved = ALPHA / DIGIT / safe / extra 8762 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 8764 base64 = *base64-unit [base64-pad] 8765 base64-unit = 4base64-char 8766 base64-pad = (2base64-char "==") / (3base64-char "=") 8767 base64-char = ALPHA / DIGIT / "+" / "/" 8768 SLASH = SWS "/" SWS ; slash 8769 EQUAL = SWS "=" SWS ; equal 8770 LPAREN = SWS "(" SWS ; left parenthesis 8771 RPAREN = SWS ")" SWS ; right parenthesis 8772 COMMA = SWS "," SWS ; comma 8773 SEMI = SWS ";" SWS ; semicolon 8774 COLON = SWS ":" SWS ; colon 8775 MINUS = SWS "-" SWS ; minus/dash 8776 LDQUOT = SWS DQUOTE ; open double quotation mark 8777 RDQUOT = DQUOTE SWS ; close double quotation mark 8778 RAQUOT = ">" SWS ; right angle quote 8779 LAQUOT = SWS "<" ; left angle quote 8781 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 8782 UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 8783 UTF8-1 = 8784 UTF8-2 = 8785 UTF8-3 = 8786 UTF8-4 = 8787 UTF8-CONT = %x80-BF 8789 POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] 8790 FLOAT = ["-"] POS-FLOAT 8792 20.2. RTSP Protocol Definition 8794 20.2.1. Generic Protocol elements 8795 RTSP-IRI = schemes ":" IRI-rest 8796 IRI-rest = ihier-part [ "?" iquery ] 8797 ihier-part = "//" iauthority ipath-abempty 8798 RTSP-IRI-ref = RTSP-IRI / irelative-ref 8799 irelative-ref = irelative-part [ "?" iquery ] 8800 irelative-part = "//" iauthority ipath-abempty 8801 / ipath-absolute 8802 / ipath-noscheme 8803 / ipath-empty 8805 iauthority = < As defined in RFC 3987> 8806 ipath = ipath-abempty ; begins with "/" or is empty 8807 / ipath-absolute ; begins with "/" but not "//" 8808 / ipath-noscheme ; begins with a non-colon segment 8809 / ipath-rootless ; begins with a segment 8810 / ipath-empty ; zero characters 8812 ipath-abempty = *( "/" isegment ) 8813 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 8814 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 8815 ipath-rootless = isegment-nz *( "/" isegment ) 8816 ipath-empty = 0 8818 isegment = *ipchar [";" *ipchar] 8819 isegment-nz = 1*ipchar [";" *ipchar] 8820 / ";" *ipchar 8821 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 8822 / ";" *ipchar-nc 8823 ; non-zero-length segment without any colon ":" 8824 ; No parameter (; delimited) inside path. 8826 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 8827 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 8828 ; sub-delims is different from RFC 3987 8829 ; not including ";" 8831 iquery = < As defined in RFC 3987> 8832 iunreserved = < As defined in RFC 3987> 8833 pct-encoded = < As defined in RFC 3987> 8834 RTSP-URI = schemes ":" URI-rest 8835 RTSP-REQ-URI = schemes ":" URI-req-rest 8836 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 8837 RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel 8838 schemes = "rtsp" / "rtsps" / scheme 8839 scheme = < As defined in RFC 3986> 8840 URI-rest = hier-part [ "?" query ] 8841 URI-req-rest = hier-part [ "?" query ] 8842 ; Note fragment part not allowed in requests 8843 hier-part = "//" authority path-abempty 8845 RTSP-Relative = relative-part [ "?" query ] 8846 RTSP-REQ-Rel = relative-part [ "?" query ] 8847 relative-part = "//" authority path-abempty 8848 / path-absolute 8849 / path-noscheme 8850 / path-empty 8852 authority = < As defined in RFC 3986> 8853 query = < As defined in RFC 3986> 8855 path = path-abempty ; begins with "/" or is empty 8856 / path-absolute ; begins with "/" but not "//" 8857 / path-noscheme ; begins with a non-colon segment 8858 / path-rootless ; begins with a segment 8859 / path-empty ; zero characters 8861 path-abempty = *( "/" segment ) 8862 path-absolute = "/" [ segment-nz *( "/" segment ) ] 8863 path-noscheme = segment-nz-nc *( "/" segment ) 8864 path-rootless = segment-nz *( "/" segment ) 8865 path-empty = 0 8867 segment = *pchar [";" *pchar] 8868 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 8869 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 8870 ; non-zero-length segment without any colon ":" 8871 ; No parameter (; delimited) inside path. 8873 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 8874 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 8876 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 8877 / "*" / "+" / "," / "=" 8878 ; sub-delims is different from RFC 3986/3987 8879 ; not including ";" 8881 smpte-range = smpte-type [EQUAL smpte-range-spec] 8882 ; See section 4.4 8883 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 8884 / ( "-" smpte-time ) 8885 smpte-type = "smpte" / "smpte-30-drop" 8886 / "smpte-25" / smpte-type-extension 8887 ; other timecodes may be added 8888 smpte-type-extension = "smpte" token 8889 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 8890 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 8892 npt-range = "npt" [EQUAL npt-range-spec] 8893 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 8894 npt-time = "now" / npt-sec / npt-hhmmss 8895 npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] 8896 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] 8897 npt-hh = 1*19DIGIT ; any positive number 8898 npt-mm = 1*2DIGIT ; 0-59 8899 npt-ss = 1*2DIGIT ; 0-59 8901 utc-range = "clock" [EQUAL utc-range-spec] 8902 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 8903 utc-time = utc-date "T" utc-clock "Z" 8904 utc-date = 8DIGIT 8905 utc-clock = 6DIGIT [ "." 1*9DIGIT ] 8907 feature-tag = token 8909 session-id = 1*256( ALPHA / DIGIT / safe ) 8911 extension-header = header-name HCOLON header-value 8912 header-name = token 8913 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 8915 20.2.2. Message Syntax 8916 RTSP-message = Request / Response ; RTSP/2.0 messages 8918 Request = Request-Line 8919 *((general-header 8920 / request-header 8921 / message-body-header) CRLF) 8922 CRLF 8923 [ message-body-data ] 8925 Response = Status-Line 8926 *((general-header 8927 / response-header 8928 / message-body-header) CRLF) 8929 CRLF 8930 [ message-body-data ] 8932 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 8934 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 8935 Method = "DESCRIBE" 8936 / "GET_PARAMETER" 8937 / "OPTIONS" 8938 / "PAUSE" 8939 / "PLAY" 8940 / "PLAY_NOTIFY" 8941 / "REDIRECT" 8942 / "SETUP" 8943 / "SET_PARAMETER" 8944 / "TEARDOWN" 8945 / extension-method 8947 extension-method = token 8949 Request-URI = "*" / RTSP-REQ-URI 8950 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 8952 message-body-data = 1*OCTET 8954 Status-Code = "100" ; Continue 8955 / "200" ; OK 8956 / "301" ; Moved Permanently 8957 / "302" ; Found 8958 / "303" ; See Other 8959 / "304" ; Not Modified 8960 / "305" ; Use Proxy 8961 / "400" ; Bad Request 8962 / "401" ; Unauthorized 8963 / "402" ; Payment Required 8964 / "403" ; Forbidden 8965 / "404" ; Not Found 8966 / "405" ; Method Not Allowed 8967 / "406" ; Not Acceptable 8968 / "407" ; Proxy Authentication Required 8969 / "408" ; Request Time-out 8970 / "410" ; Gone 8971 / "412" ; Precondition Failed 8972 / "413" ; Request Message Body Too Large 8973 / "414" ; Request-URI Too Large 8974 / "415" ; Unsupported Media Type 8975 / "451" ; Parameter Not Understood 8976 / "452" ; reserved 8977 / "453" ; Not Enough Bandwidth 8978 / "454" ; Session Not Found 8979 / "455" ; Method Not Valid in This State 8980 / "456" ; Header Field Not Valid for Resource 8981 / "457" ; Invalid Range 8982 / "458" ; Parameter Is Read-Only 8983 / "459" ; Aggregate operation not allowed 8984 / "460" ; Only aggregate operation allowed 8985 / "461" ; Unsupported Transport 8986 / "462" ; Destination Unreachable 8987 / "463" ; Destination Prohibited 8988 / "464" ; Data Transport Not Ready Yet 8989 / "465" ; Notification Reason Unknown 8990 / "466" ; Key Management Error 8991 / "470" ; Connection Authorization Required 8992 / "471" ; Connection Credentials not accepted 8993 / "472" ; Failure to establish secure connection 8994 / "500" ; Internal Server Error 8995 / "501" ; Not Implemented 8996 / "502" ; Bad Gateway 8997 / "503" ; Service Unavailable 8998 / "504" ; Gateway Time-out 8999 / "505" ; RTSP Version not supported 9000 / "551" ; Option not supported 9001 / extension-code 9003 extension-code = 3DIGIT 9005 Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) 9006 rtsp-header = general-header 9007 / request-header 9008 / response-header 9009 / message-body-header 9011 general-header = Accept-Ranges 9012 / Cache-Control 9013 / Connection 9014 / CSeq 9015 / Date 9016 / Media-Properties 9017 / Media-Range 9018 / Pipelined-Requests 9019 / Proxy-Supported 9020 / Range 9021 / RTP-Info 9022 / Scale 9023 / Seek-Style 9024 / Server 9025 / Session 9026 / Speed 9027 / Supported 9028 / Timestamp 9029 / Transport 9030 / User-Agent 9031 / Via 9032 / extension-header 9034 request-header = Accept 9035 / Accept-Credentials 9036 / Accept-Encoding 9037 / Accept-Language 9038 / Authorization 9039 / Bandwidth 9040 / Blocksize 9041 / From 9042 / If-Match 9043 / If-Modified-Since 9044 / If-None-Match 9045 / Notify-Reason 9046 / Proxy-Authorization 9047 / Proxy-Require 9048 / Referrer 9049 / Request-Status 9050 / Require 9051 / Terminate-Reason 9052 / extension-header 9054 response-header = Authentication-Info 9055 / Connection-Credentials 9056 / Location 9057 / MTag 9058 / Proxy-Authenticate 9059 / Proxy-Authentication-Info 9060 / Public 9061 / Retry-After 9062 / Unsupported 9063 / WWW-Authenticate 9064 / extension-header 9066 message-body-header = Allow 9067 / Content-Base 9068 / Content-Encoding 9069 / Content-Language 9070 / Content-Length 9071 / Content-Location 9072 / Content-Type 9073 / Expires 9074 / Last-Modified 9075 / extension-header 9077 20.2.3. Header Syntax 9079 Accept = "Accept" HCOLON 9080 [ accept-range *(COMMA accept-range) ] 9081 accept-range = media-type-range [SEMI accept-params] 9082 media-type-range = ( "*/*" 9083 / ( m-type SLASH "*" ) 9084 / ( m-type SLASH m-subtype ) 9085 ) *( SEMI m-parameter ) 9086 accept-params = "q" EQUAL qvalue *(SEMI generic-param ) 9087 qvalue = ( "0" [ "." *3DIGIT ] ) 9088 / ( "1" [ "." *3("0") ] ) 9089 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision 9090 cred-decision = ("User" [LWS cred-info]) 9091 / "Proxy" 9092 / "Any" 9093 / (token [LWS 1*header-value]) 9094 ; For future extensions 9095 cred-info = cred-info-data *(COMMA cred-info-data) 9097 cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg 9098 SEMI base64 9099 hash-alg = "sha-256" / extension-alg 9100 extension-alg = token 9101 Accept-Encoding = "Accept-Encoding" HCOLON 9102 [ encoding *(COMMA encoding) ] 9103 encoding = codings [SEMI accept-params] 9104 codings = content-coding / "*" 9105 content-coding = "identity" / token 9106 Accept-Language = "Accept-Language" HCOLON 9107 language *(COMMA language) 9108 language = language-range [SEMI accept-params] 9109 language-range = language-tag / "*" 9110 language-tag = primary-tag *( "-" subtag ) 9111 primary-tag = 1*8ALPHA 9112 subtag = 1*8ALPHA 9113 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges 9114 acceptable-ranges = (range-unit *(COMMA range-unit)) 9115 range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25" 9116 / "clock" / extension-format 9117 extension-format = token 9118 Allow = "Allow" HCOLON Method *(COMMA Method) 9119 Authentication-Info = "Authentication-Info" HCOLON auth-info 9120 auth-info = auth-info-entry *(COMMA auth-info-entry) 9121 auth-info-entry = nextnonce 9122 / message-qop 9123 / response-auth 9124 / cnonce 9125 / nonce-count 9126 nextnonce = "nextnonce" EQUAL nonce-value 9127 response-auth = "rspauth" EQUAL response-digest 9128 response-digest = DQUOTE *LHEX DQUOTE 9129 Authorization = "Authorization" HCOLON credentials 9130 credentials = basic-credential 9131 / digest-credential 9132 / other-response 9133 basic-credential = "Basic" LWS basic-credentials 9134 basic-credentials = base64 ; Base64 encoding of user-password 9135 user-password = basic-username ":" password 9136 basic-username = *CF-TEXT 9137 CF-TEXT = %x20-39 / %x3B-7E / %x80-FF ; TEXT without : 9138 password = *TEXT 9139 digest-credential = ("Digest" LWS digest-response) 9140 digest-response = dig-resp *(COMMA dig-resp) 9141 dig-resp = username / realm / nonce / digest-uri 9142 / dresponse / algorithm / cnonce 9143 / opaque / message-qop 9144 / nonce-count / auth-param 9145 username = "username" EQUAL username-value 9146 username-value = quoted-string 9147 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 9148 digest-uri-value = RTSP-REQ-URI 9149 message-qop = "qop" EQUAL qop-value 9150 cnonce = "cnonce" EQUAL cnonce-value 9151 cnonce-value = nonce-value 9152 nonce-count = "nc" EQUAL nc-value 9153 nc-value = 8LHEX 9154 dresponse = "response" EQUAL request-digest 9155 request-digest = LDQUOT 32LHEX RDQUOT 9156 auth-param = auth-param-name EQUAL 9157 ( token / quoted-string ) 9158 auth-param-name = token 9159 other-response = auth-scheme LWS auth-param 9160 *(COMMA auth-param) 9161 auth-scheme = token 9163 Bandwidth = "Bandwidth" HCOLON 1*19DIGIT 9165 Blocksize = "Blocksize" HCOLON 1*9DIGIT 9167 Cache-Control = "Cache-Control" HCOLON cache-directive 9168 *(COMMA cache-directive) 9169 cache-directive = cache-rqst-directive 9170 / cache-rspns-directive 9172 cache-rqst-directive = "no-cache" 9173 / "max-stale" [EQUAL delta-seconds] 9174 / "min-fresh" EQUAL delta-seconds 9175 / "only-if-cached" 9176 / cache-extension 9178 cache-rspns-directive = "public" 9179 / "private" 9180 / "no-cache" 9181 / "no-transform" 9182 / "must-revalidate" 9183 / "proxy-revalidate" 9184 / "max-age" EQUAL delta-seconds 9185 / cache-extension 9187 cache-extension = token [EQUAL (token / quoted-string)] 9188 delta-seconds = 1*19DIGIT 9190 Connection = "Connection" HCOLON connection-token 9191 *(COMMA connection-token) 9192 connection-token = "close" / token 9194 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 9195 cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64 9196 Content-Base = "Content-Base" HCOLON RTSP-URI 9197 Content-Encoding = "Content-Encoding" HCOLON 9198 content-coding *(COMMA content-coding) 9199 Content-Language = "Content-Language" HCOLON 9200 language-tag *(COMMA language-tag) 9201 Content-Length = "Content-Length" HCOLON 1*19DIGIT 9202 Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref 9203 Content-Type = "Content-Type" HCOLON media-type 9204 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 9205 m-type = discrete-type / composite-type 9206 discrete-type = "text" / "image" / "audio" / "video" 9207 / "application" / extension-token 9208 composite-type = "message" / "multipart" / extension-token 9209 extension-token = ietf-token / x-token 9210 ietf-token = token 9211 x-token = "x-" token 9212 m-subtype = extension-token / iana-token 9213 iana-token = token 9214 m-parameter = m-attribute EQUAL m-value 9215 m-attribute = token 9216 m-value = token / quoted-string 9218 CSeq = "CSeq" HCOLON cseq-nr 9219 cseq-nr = 1*9DIGIT 9220 Date = "Date" HCOLON RTSP-date 9221 RTSP-date = date-time ; 9222 date-time = 9223 Expires = "Expires" HCOLON RTSP-date 9224 From = "From" HCOLON from-spec 9225 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 9226 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 9227 addr-spec = RTSP-REQ-URI / absolute-URI 9228 absolute-URI = < As defined in RFC 3986> 9229 display-name = *(token LWS) / quoted-string 9230 from-param = tag-param / generic-param 9231 tag-param = "tag" EQUAL token 9232 If-Match = "If-Match" HCOLON ("*" / message-tag-list) 9233 message-tag-list = message-tag *(COMMA message-tag) 9234 message-tag = [ weak ] opaque-tag 9235 weak = "W/" 9236 opaque-tag = quoted-string 9237 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 9238 If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list) 9239 Last-Modified = "Last-Modified" HCOLON RTSP-date 9240 Location = "Location" HCOLON RTSP-REQ-URI 9241 Media-Properties = "Media-Properties" HCOLON [media-prop-list] 9242 media-prop-list = media-prop-value *(COMMA media-prop-value) 9243 media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) 9244 / "Beginning-Only" 9245 / "No-Seeking" 9246 / "Immutable" 9247 / "Dynamic" 9248 / "Time-Progressing" 9249 / "Unlimited" 9250 / ("Time-Limited" EQUAL utc-time) 9251 / ("Time-Duration" EQUAL POS-FLOAT) 9252 / ("Scales" EQUAL scale-value-list) 9253 / media-prop-ext 9254 media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] 9255 scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE 9256 scale-entry = scale-value / (scale-value COLON scale-value) 9257 scale-value = FLOAT 9258 Media-Range = "Media-Range" HCOLON [ranges-list] 9259 ranges-list = ranges-spec *(COMMA ranges-spec) 9260 MTag = "MTag" HCOLON message-tag 9261 Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val 9262 Notify-Reas-val = "end-of-stream" 9263 / "media-properties-update" 9264 / "scale-change" 9265 / Notify-Reason-extension 9266 Notify-Reason-extension = token 9267 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 9268 startup-id = 1*8DIGIT 9270 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list 9271 challenge-list = challenge *(COMMA challenge) 9272 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 9273 / ("Basic" LWS realm) 9274 / other-challenge 9275 other-challenge = auth-scheme LWS auth-param 9276 *(COMMA auth-param) 9277 digest-cln = realm / domain / nonce 9278 / opaque / stale / algorithm 9279 / qop-options / auth-param 9280 realm = "realm" EQUAL realm-value 9281 realm-value = quoted-string 9282 domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref 9283 *(1*SP RTSP-REQ-Ref ) RDQUOT 9284 nonce = "nonce" EQUAL nonce-value 9285 nonce-value = quoted-string 9286 opaque = "opaque" EQUAL quoted-string 9287 stale = "stale" EQUAL ( "true" / "false" ) 9288 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 9289 qop-options = "qop" EQUAL LDQUOT qop-value 9290 *("," qop-value) RDQUOT 9291 qop-value = "auth" / "auth-int" / token 9292 Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON auth-info 9293 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials 9294 Proxy-Require = "Proxy-Require" HCOLON feature-tag-list 9295 feature-tag-list = feature-tag *(COMMA feature-tag) 9296 Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] 9298 Public = "Public" HCOLON Method *(COMMA Method) 9300 Range = "Range" HCOLON ranges-spec 9302 ranges-spec = npt-range / utc-range / smpte-range 9303 / range-ext 9304 range-ext = extension-format [EQUAL range-value] 9305 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 9307 Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) 9308 Request-Status = "Request-Status" HCOLON req-status-info 9309 req-status-info = cseq-info LWS status-info LWS reason-info 9310 cseq-info = "cseq" EQUAL cseq-nr 9311 status-info = "status" EQUAL Status-Code 9312 reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE 9313 Require = "Require" HCOLON feature-tag-list 9314 RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec 9315 *(COMMA rtsp-info-spec)] 9316 rtsp-info-spec = stream-url 1*ssrc-parameter 9317 stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE 9318 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 9319 ri-parameter *(SEMI ri-parameter) 9320 ri-parameter = ("seq" EQUAL 1*5DIGIT) 9321 / ("rtptime" EQUAL 1*10DIGIT) 9322 / generic-param 9324 Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds) 9325 Scale = "Scale" HCOLON scale-value 9326 Seek-Style = "Seek-Style" HCOLON Seek-S-values 9327 Seek-S-values = "RAP" 9328 / "CoRAP" 9329 / "First-Prior" 9330 / "Next" 9331 / Seek-S-value-ext 9332 Seek-S-value-ext = token 9334 Server = "Server" HCOLON ( product / comment ) 9335 *(LWS (product / comment)) 9336 product = token [SLASH product-version] 9337 product-version = token 9338 comment = LPAREN *( ctext / quoted-pair) RPAREN 9340 Session = "Session" HCOLON session-id 9341 [ SEMI "timeout" EQUAL delta-seconds ] 9343 Speed = "Speed" HCOLON lower-bound MINUS upper-bound 9344 lower-bound = POS-FLOAT 9345 upper-bound = POS-FLOAT 9347 Supported = "Supported" HCOLON [feature-tag-list] 9348 Terminate-Reason = "Terminate-Reason" HCOLON TR-Info 9349 TR-Info = TR-Reason *(SEMI TR-Parameter) 9350 TR-Reason = "Session-Timeout" 9351 / "Server-Admin" 9352 / "Internal-Error" 9353 / token 9354 TR-Parameter = TR-time / TR-user-msg / generic-param 9355 TR-time = "time" EQUAL utc-time 9356 TR-user-msg = "user-msg" EQUAL quoted-string 9358 Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay] 9359 timestamp-value = *19DIGIT [ "." *9DIGIT ] 9360 delay = *9DIGIT [ "." *9DIGIT ] 9362 Transport = "Transport" HCOLON transport-spec 9363 *(COMMA transport-spec) 9364 transport-spec = transport-id *trns-parameter 9365 transport-id = trans-id-rtp / other-trans 9366 trans-id-rtp = "RTP/" profile ["/" lower-transport] 9367 ; no LWS is allowed inside transport-id 9368 other-trans = token *("/" token) 9369 profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token 9370 lower-transport = "TCP" / "UDP" / token 9371 trns-parameter = (SEMI ( "unicast" / "multicast" )) 9372 / (SEMI "interleaved" EQUAL channel ["-" channel]) 9373 / (SEMI "ttl" EQUAL ttl) 9374 / (SEMI "layers" EQUAL 1*DIGIT) 9375 / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) 9376 / (SEMI "mode" EQUAL mode-spec) 9377 / (SEMI "dest_addr" EQUAL addr-list) 9378 / (SEMI "src_addr" EQUAL addr-list) 9379 / (SEMI "setup" EQUAL contrans-setup) 9380 / (SEMI "connection" EQUAL contrans-con) 9381 / (SEMI "RTCP-mux") 9382 / (SEMI "MIKEY" EQUAL MIKEY-Value) 9383 / (SEMI trn-param-ext) 9384 contrans-setup = "active" / "passive" / "actpass" 9385 contrans-con = "new" / "existing" 9386 trn-param-ext = par-name [EQUAL trn-par-value] 9387 par-name = token 9388 trn-par-value = *(rtsp-unreserved / quoted-string) 9389 ttl = 1*3DIGIT ; 0 to 255 9390 ssrc = 8HEX 9391 channel = 1*3DIGIT ; 0 to 255 9392 MIKEY-Value = base64 9393 mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) 9394 mode = "PLAY" / token 9395 addr-list = quoted-addr *(SLASH quoted-addr) 9396 quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE 9397 host-port = ( host [":" port] ) 9398 / ( ":" port ) 9399 extension-addr = 1*qdtext 9400 host = < As defined in RFC 3986> 9401 port = < As defined in RFC 3986> 9402 Unsupported = "Unsupported" HCOLON feature-tag-list 9403 User-Agent = "User-Agent" HCOLON ( product / comment ) 9404 *(LWS (product / comment)) 9405 Via = "Via" HCOLON via-parm *(COMMA via-parm) 9406 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 9407 via-params = via-ttl / via-maddr 9408 / via-received / via-extension 9409 via-ttl = "ttl" EQUAL ttl 9410 via-maddr = "maddr" EQUAL host 9411 via-received = "received" EQUAL (IPv4address / IPv6address) 9412 IPv4address = < As defined in RFC 3986> 9413 IPv6address = < As defined in RFC 3986> 9414 via-extension = generic-param 9415 sent-protocol = protocol-name SLASH protocol-version 9416 SLASH transport-prot 9417 protocol-name = "RTSP" / token 9418 protocol-version = token 9419 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 9420 other-transport = token 9421 sent-by = host [ COLON port ] 9423 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 9425 20.3. SDP extension Syntax 9427 This section defines in ABNF the SDP extensions defined for RTSP. 9428 See Appendix D for the definition of the extensions in text. 9430 control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF 9432 a-range-def = "a=range:" ranges-spec CRLF 9434 a-mtag-def = "a=mtag:" message-tag CRLF 9436 21. Security Considerations 9438 The security considerations and threats around RTSP and its usage can 9439 be divided into considerations around the signaling protocol itself 9440 and the issues related to the media stream delivery. However, when 9441 it comes to mitigations of security threats, a threat depending on 9442 the media stream delivery may in fact be mitigated by a mechanism in 9443 the signaling protocol. 9445 There are several chapters and an appendix in this document that 9446 define security solutions for the protocol. We will reference them 9447 when discussing the threats below. But the reader should take 9448 special notice of the Security Framework (Section 19) and the 9449 specification of how to use SRTP and its key-mangement 9450 (Appendix C.1.4) to achieve certain aspects of the media security. 9452 21.1. Signaling Protocol Threats 9454 This section focuses on issues related to the signaling protocol. 9455 Because of the similarity in syntax and usage between RTSP servers 9456 and HTTP servers, the security considerations outlined in [H15] apply 9457 also. 9459 Specifically, please note the following: 9461 Abuse of Server Log Information: A server is in the position to save 9462 personal data about a user's requests which might identify 9463 their media consumption patterns or subjects of interest. This 9464 information is clearly confidential in nature and its handling 9465 can be constrained by law in certain countries. RTSP servers 9466 will presumably have similar logging mechanisms to HTTP, and 9467 thus should be equally guarded in protecting the contents of 9468 those logs, thus protecting the privacy of the users of the 9469 servers. People using the RTSP protocol to provide media are 9470 responsible for ensuring that logging material is not 9471 distributed without the permission of any individuals that are 9472 identifiable by the published results. 9474 Transfer of Sensitive Information: There is no reason to believe 9475 that information transferred or controlled via RTSP may be any 9476 less sensitive than that normally transmitted via HTTP. 9477 Therefore, all of the precautions regarding the protection of 9478 data privacy and user privacy apply to implementors of RTSP 9479 clients, servers, and proxies. See [H15.1.2] for further 9480 details. 9482 Attacks Based On File and Path Names: Though RTSP URIs are opaque 9483 handles that do not necessarily have file system semantics, it 9484 is anticipated that many implementations will translate 9485 portions of the Request-URIs directly to file system calls. In 9486 such cases, file systems SHOULD follow the precautions outlined 9487 in [H15.2], such as checking for ".." in path components. 9489 Personal Information: RTSP clients are often privy to the same 9490 information that HTTP clients are (user name, location, etc.) 9491 and thus should be equally sensitive. See [H15.1] for further 9492 recommendations. 9494 Privacy Issues Connected to Accept Headers: Since may of the same 9495 "Accept" headers exist in RTSP as in HTTP, the same caveats 9496 outlined in [H15.1.4] with regards to their use should be 9497 followed. 9499 DNS Spoofing: Presumably, given the longer connection times 9500 typically associated to RTSP sessions relative to HTTP 9501 sessions, RTSP client DNS optimizations should be less 9502 prevalent. Nonetheless, the recommendations provided in 9503 [H15.3] are still relevant to any implementation which attempts 9504 to rely on a DNS-to-IP mapping to hold beyond a single use of 9505 the mapping. 9507 Location Headers and Spoofing: If a single server supports multiple 9508 organizations that do not trust each another, then it MUST 9509 check the values of Location and Content-Location header fields 9510 in responses that are generated under control of said 9511 organizations to make sure that they do not attempt to 9512 invalidate resources over which they have no authority. 9513 ([H15.4]) 9515 In addition to the recommendations in the current HTTP specification 9516 (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 9517 2068 [RFC2068], future HTTP specifications may provide additional 9518 guidance on security issues. 9520 The following are added considerations for RTSP implementations. 9522 Session hijacking: Since there is no or little relation between a 9523 transport layer connection and an RTSP session, it is possible 9524 for a malicious client to issue requests with random session 9525 identifiers which could affect other clients of an unsuspecting 9526 server. To mitigate this the server SHALL use a large, random 9527 and non-sequential session identifier to minimize the 9528 possibility of this kind of attack. However, unless the RTSP 9529 signaling is always confidentiality protected, e.g., using TLS, 9530 an on-path attacker will be able to hijack a session. Another 9531 choice for preventing session hijacking is to use client 9532 authentication and only allow the authenticated client creating 9533 the session to access that session. 9535 Authentication: Servers SHOULD implement both basic and digest 9536 [RFC2617] authentication. In environments requiring tighter 9537 security for the control messages, the transport layer 9538 mechanism TLS [RFC5246] SHOULD be used. 9540 Suspicious behavior: RTSP servers upon detecting instances of 9541 behavior which is deemed a security risk SHOULD return error 9542 code 403 (Forbidden). RTSP servers SHOULD also be aware of 9543 attempts to probe the server for weaknesses and entry points 9544 and MAY arbitrarily disconnect and ignore further requests from 9545 clients which are deemed to be in violation of local security 9546 policy. 9548 TLS through proxies: If one uses the possibility to connect TLS in 9549 multiple legs (Section 19.3) one really needs to be aware of 9550 the trust model. That procedure requires full faith and trust 9551 in all proxies, which will be identified, that one allows to 9552 connect through. They are men in the middle and have access to 9553 all that goes on over the TLS connection. Thus it is important 9554 to consider if that trust model is acceptable in the actual 9555 application. Further discussion of the actual trust model is 9556 in Section 19.3. 9558 Resource Exhaustion: As RTSP is a stateful protocol and establishes 9559 resource usage on the server there is a clear possibility to 9560 attack the server by trying to overbook these resources to 9561 perform a denial of service attack. This attack can be both 9562 against ongoing sessions and to prevent others from 9563 establishing sessions. RTSP agents will need to have 9564 mechanisms to prevent single peers from consuming extensive 9565 amounts of resources. The methods for guarding against this 9566 are varied and depends on the agent's role and capabilities and 9567 policies. Each implementation has to carefully consider their 9568 methods and policies to mitigate this threat. For example 9569 regarding handling of connections there are recommendations in 9570 Section 10.7. 9572 The above threats and considerations have resulted in a set of 9573 security functions and mechanisms built into or used by the protocol. 9574 The signaling protocol relies on two security features defined in the 9575 Security Framework (Section 19) namely client authentication using 9576 HTTP authentication and TLS based transport protection of the 9577 signaling messages. Both of these mechanisms are required to be 9578 implemented by any RTSP agent. 9580 A number of different security mitigations have been designed into 9581 the protocol and will be instantiated if the specification is 9582 implemented as written, for example by ensuring sufficient amount of 9583 entropy in the randomly generated session identifiers when not using 9584 client authentication to minimize the risk of session hijacking. 9585 When client authentication is used the protection against hijacking 9586 will be greatly improved by scoping the accessible sessions to the 9587 one this client identity has created. Some of the above threats are 9588 such that the implementation of the RTSP functionality itself needs 9589 to consider which policy and strategy it uses to mitigate them. 9591 21.2. Media Stream Delivery Threats 9593 The fact that RTSP establishes and controls a media stream delivery 9594 results in a set of security issues related to the media streams. 9595 This section will attempt to analyze general threats, however the 9596 choice of media stream transport protocol, such as RTP will result in 9597 some differences in threats and what mechanisms exist to mitigate 9598 them. Thus it becomes important that each specification of a new 9599 media stream transport and delivery protocol usable by RTSP requires 9600 its own security analysis. This section includes one for RTP. 9602 The set of general threats from or by the media stream delivery 9603 itself are: 9605 Concentrated denial-of-service attack: The protocol offers the 9606 opportunity for a remote-controlled denial-of-service (DoS) 9607 attack, where the media stream is the hammer in that DoS attack. 9608 See Section 21.2.1. 9610 Media Confidentiality: The media delivery may contain content of any 9611 type and it is not possible in general to determine how sensitive 9612 this content is from a confidentiality point. Thus it is a strong 9613 requirement that any media delivery protocol provides a method for 9614 providing confidentiality of the actual media content. In 9615 addition to the media level confidentiality it becomes critical 9616 that no resource identifiers used in the signaling are exposed to 9617 an attacker as they may have human understandable names, or may be 9618 also available to the attacker so they can determine the content 9619 the user was delivered. Thus the signaling protocol must also 9620 provide confidentiality protection of any information related to 9621 the media resource. 9623 Media Integrity and Authentication: There are several reasons, such 9624 as discrediting the target, misinformation of the target, why an 9625 attacker will be interested in substituting the media stream sent 9626 out from the RTSP server with one of the attacker's creation or 9627 selection. Therefore it is important that the media protocol 9628 provides mechanisms to verify the source authentication, integrity 9629 and prevent replay attacks on the media stream. 9631 Scope of Multicast: If RTSP is used to control the transmission of 9632 media onto a multicast network the scope of the delivery must be 9633 considered. RTSP supports the TTL Transport header parameter to 9634 indicate this scope for IPv4. IPv6 has a different mechanism for 9635 scope boundary. However, such scope control has risks, as it may 9636 be set too large and distribute media beyond the intended scope. 9638 Below (Section 21.2.2) we do a protocol specific analysis of security 9639 considerations for RTP based media transport. In that section we 9640 also make clear the requirements on implementing security functions 9641 for RTSP agents supporting media delivery over RTP. 9643 21.2.1. Remote Denial of Service Attack 9645 The attacker may initiate traffic flows to one or more IP addresses 9646 by specifying them as the destination in SETUP requests. While the 9647 attacker's IP address may be known in this case, this is not always 9648 useful in prevention of more attacks or ascertaining the attacker's 9649 identity. Thus, an RTSP server MUST only allow client-specified 9650 destinations for RTSP-initiated traffic flows if the server has 9651 ensured that the specified destination address accepts receiving 9652 media through different security mechanisms. Security mechanisms 9653 that are acceptable in order of increasing generality are: 9655 o Verification of the client's identity against a database of known 9656 users using RTSP authentication mechanisms (preferably digest 9657 authentication or stronger) 9659 o A list of addresses that have consented to be media destinations, 9660 especially considering user identity 9662 o Media path based verification 9664 The server SHOULD NOT allow the destination field to be set unless a 9665 mechanism exists in the system to authorize the request originator to 9666 direct streams to the recipient. It is preferred that this 9667 authorization be performed by the media recipient (destination) 9668 itself and the credentials passed along to the server. However, in 9669 certain cases, such as when the recipient address is a multicast 9670 group, or when the recipient is unable to communicate with the server 9671 in an out-of-band manner, this may not be possible. In these cases 9672 the server may chose another method such as a server-resident 9673 authorization list to ensure that the request originator has the 9674 proper credentials to request stream delivery to the recipient. 9676 One solution that performs the necessary verification of acceptance 9677 of media suitable for unicast based delivery is the Interactive 9678 Connectivity Establishment (ICE) [RFC5245] based NAT traversal method 9679 described in [I-D.ietf-mmusic-rtsp-nat]. This mechanism uses random 9680 passwords and a username so that the probability of unintended 9681 indication as a valid media destination is very low. In addition the 9682 server includes in its Session Traversal Utilities for NAT (STUN) 9683 [RFC5389] requests a cookie (consisting of random material) that the 9684 destination echoes back, thus the solution also safe-guards against 9685 having an off-path attacker being able to spoof the STUN checks. 9686 This leaves this solution vulnerable only to on-path attackers that 9687 can see the STUN requests go to the target of attack and thus forge a 9688 response. 9690 For delivery to multicast addresses there is a need for another 9691 solution which is not specified in this memo. 9693 21.2.2. RTP Security analysis 9695 RTP is a commonly used media transport protocol and has been the most 9696 common choice for RTSP 1.0 implementations. The core RTP protocol 9697 has been in use for a long time and it has well-known security 9698 properties and the RTP security consideration (Section 9 of 9699 [RFC3550]) needs to be reviewed. In perspective of the usage of RTP 9700 in context of RTSP the following properties should be noted: 9702 Stream Additions: RTP has support for multiple simultaneous media 9703 streams in each RTP session. As some use cases require support 9704 for non-synchronized adding and removal of media streams and their 9705 identifiers an attacker can easily insert additional media streams 9706 into a session context that according to protocol design is 9707 intended to be played out. Another threat vector is one of denial 9708 of service by exhausting the resources of the RTP session 9709 receiver, for example by using a large number of SSRC identifiers 9710 simultaneously. The strong mitigation of this is to ensure that 9711 one cryptographically authenticates any incoming packet flow to 9712 the RTP session. Weak mitigations like blocking additional media 9713 streams in session contexts easily lead to a denial of service 9714 vulnerability in addition to preventing certain RTP extensions or 9715 use cases which rely on multiple media streams, such as RTP 9716 retransmission [RFC4588] to function. 9718 Forged Feedback: The built in RTP control Protocol (RTCP) also 9719 offers a large attack surface for a couple of different types of 9720 attacks. One venue is to send RTCP feedback to the media sender 9721 indicating large amounts of packet loss and thus trigger a media 9722 bit-rate adaptation response from the sender resulting in lowered 9723 media quality and potentially shut down of the media stream. 9724 Another attack is to perform a resource exhaustion attack on the 9725 receiver by using many SSRC identifiers to create large state 9726 tables and increase the RTCP related processing demands. 9728 RTP/RTCP Extensions: RTP and RTCP extensions generally provide 9729 additional and sometimes extremely powerful tools to do denial of 9730 service or service disruption. For example the Code Control 9731 Message [RFC5104] RTCP extensions enables both locking down the 9732 bit-rate to low values and disruption of video quality by 9733 requesting Intra frames. 9735 Taking into account the above general discussion in Section 21.2 and 9736 the RTP specific discussion in this section it is clear that it is 9737 necessary that a strong security mechanism is supported to protect 9738 RTP. Therefore this specification has the following requirements on 9739 RTP security functions for all RTSP agents that handles media streams 9740 and where the media stream transport is done using RTP. 9742 RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] 9743 and thus the SAVP profile. In addition the secure AVP profile 9744 (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is 9745 implemented. This specification requires no additional cryptographic 9746 transforms or configuration values beyond those specified as 9747 mandatory to implement in RFC3711, i.e., AES-CM and HMAC-SHA1. The 9748 default key-management mechanism which MUST be implemented is the one 9749 defined in the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY 9750 implementation MUST implement the necessary functions for MIKEY-RSA-R 9751 mode [RFC4738] and in addition the SRTP parameter negotiation 9752 necessary to negotiate the supported SRTP transforms and parameters. 9754 22. IANA Considerations 9756 This section sets up a number of registries for RTSP 2.0 that should 9757 be maintained by IANA. These registries are separate from any 9758 registries existing for RTSP 1.0. For each registry there is a 9759 description of what it is required to contain, what specification is 9760 needed when adding an entry with IANA, and finally the entries that 9761 this document needs to register. See also the Section 2.7 "Extending 9762 RTSP". There is also an IANA registration of three SDP attributes. 9764 Registries or entries in registries which have been made for RTSP 1.0 9765 are not moved to RTSP 2.0. The registries and entries in registries 9766 of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry 9767 in a registry is also required in RTSP 2.0, it MUST follow the 9768 procedure defined below to allocate the registry or entry in a 9769 registry. 9771 The sections describing how to register an item uses some of the 9772 registration policies described in RFC 5226 [RFC5226], namely "First 9773 Come, First Served", "Expert Review, "Specification Required", and 9774 "Standards Action". 9776 RFC-Editor Note: Please replace all occurrences of RFCXXXX with 9777 the RFC number this specification receives when published. 9779 In case a registry requires a contact person, the authors, with 9780 Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are 9781 the contact persons for any entries created by this document. 9783 A registration request to IANA MUST contain the following 9784 information: 9786 o A name of the item to register according to the rules specified by 9787 the intended registry. 9789 o Indication of who has change control over the feature (for 9790 example, IETF, ISO, ITU-T, other international standardization 9791 bodies, a consortium, a particular company or group of companies, 9792 or an individual); 9794 o A reference to a further description, if available, for example 9795 (in decreasing order of preference) an RFC, a published standard, 9796 a published paper, a patent filing, a technical report, documented 9797 source code or a computer manual; 9799 o For proprietary features, contact information (postal and email 9800 address); 9802 22.1. Feature-tags 9804 22.1.1. Description 9806 When a client and server try to determine what part and functionality 9807 of the RTSP specification and any future extensions that its counter 9808 part implements there is need for a namespace. This registry 9809 contains named entries representing certain functionality. 9811 The usage of feature-tags is explained in Section 11 and 9812 Section 13.1. 9814 22.1.2. Registering New Feature-tags with IANA 9816 The registering of feature-tags is done on a first come, first served 9817 basis. 9819 The name of the feature MUST follow these rules: The name may be of 9820 any length, but SHOULD be no more than twenty characters long. The 9821 name MUST NOT contain any spaces, or control characters. The 9822 registration MUST indicate if the feature-tag applies to clients, 9823 servers, or proxies only or any combinations of these. Any 9824 proprietary feature MUST have as the first part of the name a vendor 9825 tag, which identifies the organization. The registry entries consist 9826 of the feature tag, a one paragraph description of what it 9827 represents, its applicability (server, client, proxy, any 9828 combination) and a reference to its specification where applicable. 9830 Examples for a vendor tag describing a proprietary feature are: 9832 vendorA.specfeat01 9834 vendorA.specfeat02 9836 22.1.3. Registered entries 9838 The following feature-tags are defined in this specification and 9839 hereby registered. The change control belongs to the IETF. 9841 play.basic: The implementation for delivery and playback operations 9842 according to the core RTSP specification, as defined in this 9843 memo. Applies for both clients, servers and proxies. See 9844 Section 11.1. 9846 play.scale: Support of scale operations for media playback. Applies 9847 only for servers. See Section 18.46. 9849 play.speed: Support of the speed functionality for media delivery. 9850 Applies only for servers. See Section 18.50. 9852 setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as 9853 discussed in Appendix C.1.6.4. Applies for both client and 9854 servers and any media caching proxy. 9856 This should be represented by IANA as a table with the feature tags, 9857 contact person and their references. 9859 22.2. RTSP Methods 9861 22.2.1. Description 9863 Methods are described in Section 13. Extending the protocol with new 9864 methods allow for totally new functionality. 9866 22.2.2. Registering New Methods with IANA 9868 A new method MUST be registered through an IETF Standards Action. 9869 The reason is that new methods may radically change the protocol's 9870 behavior and purpose. 9872 A specification for a new RTSP method MUST consist of the following 9873 items: 9875 o A method name which follows the ABNF rules for methods. 9877 o A clear specification what a request using the method does and 9878 what responses are expected. Which directions the method is used, 9879 C->S or S->C or both. How the use of headers, if any, modifies 9880 the behavior and effect of the method. 9882 o A list or table specifying which of the IANA registered headers 9883 that are allowed to be used with the method in request or/and 9884 response. The list or table SHOULD follow the format of tables in 9885 Section 18. 9887 o Describe how the method relates to network proxies. 9889 22.2.3. Registered Entries 9891 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 9892 GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, 9893 SET_PARAMETER, and TEARDOWN. The initial table of the registry is 9894 provided below. 9896 Method Directionality Reference 9897 ----------------------------------------------------- 9898 DESCRIBE C->S [RFCXXXX] 9899 GET_PARAMETER C->S, S->C [RFCXXXX] 9900 OPTIONS C->S, S->C [RFCXXXX] 9901 PAUSE C->S [RFCXXXX] 9902 PLAY C->S [RFCXXXX] 9903 PLAY_NOTIFY S->C [RFCXXXX] 9904 REDIRECT S->C [RFCXXXX] 9905 SETUP C->S [RFCXXXX] 9906 SET_PARAMETER C->S, S->C [RFCXXXX] 9907 TEARDOWN C->S, S->C [RFCXXXX] 9909 22.3. RTSP Status Codes 9911 22.3.1. Description 9913 A status code is the three digit number used to convey information in 9914 RTSP response messages, see Section 8. The number space is limited 9915 and care should be taken not to fill the space. 9917 22.3.2. Registering New Status Codes with IANA 9919 A new status code registration follows the policy of IETF Review. 9920 New RTSP functionality requiring Status Codes should first be 9921 registered in the range x50-x99. Only when the range is full should 9922 registrations be done in the x00-x49 range, unless it is to adopt an 9923 HTTP extension also to RTSP. The reason is to enable any HTTP 9924 extension to be adopted to RTSP without needing to renumber any 9925 related status codes. A specification for a new status code MUST 9926 specify the following: 9928 o The registered number. 9930 o A description of what the status code means and the expected 9931 behavior of the sender and receiver of the code. 9933 22.3.3. Registered Entries 9935 RFCXXXX, registers the numbered status code defined in the ABNF entry 9936 "Status-Code" except "extension-code" (that defines the syntax 9937 allowed for future extensions) in Section 20.2.2. 9939 22.4. RTSP Headers 9940 22.4.1. Description 9942 By specifying new headers a method(s) can be enhanced in many 9943 different ways. An unknown header will be ignored by the receiving 9944 agent. If the new header is vital for a certain functionality, a 9945 feature-tag for the functionality can be created and demanded to be 9946 used by the counter-part with the inclusion of a Require header 9947 carrying the feature-tag. 9949 22.4.2. Registering New Headers with IANA 9951 Registrations in the registry can be done following the Expert Review 9952 policy. A specification SHOULD be provided, preferably an IETF RFC 9953 or other Standards Developing Organization specification. The 9954 minimal information in a registration request is the header name and 9955 the contact information. 9957 The specification SHOULD contain the following information: 9959 o The name of the header. 9961 o An ABNF specification of the header syntax. 9963 o A list or table specifying when the header may be used, 9964 encompassing all methods, their request or response, the direction 9965 (C->S or S->C). 9967 o How the header is to be handled by proxies. 9969 o A description of the purpose of the header. 9971 22.4.3. Registered entries 9973 All headers specified in Section 18 in RFCXXXX are to be registered. 9974 The Registry is to include header name and reference. 9976 Furthermore the following legacy RTSP headers defined in other 9977 specifications are registered with header name, reference and 9978 description according to below list. Note: These references may not 9979 fulfill all of the above rules for registrations due to their legacy 9980 status. 9982 o x-wap-profile defined in [TS-26234]. The x-wap-profile request- 9983 header contains one or more absolute URLs to the requesting 9984 agent's device capability profile. 9986 o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff 9987 request-header contains a subset of a device capability profile. 9989 o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- 9990 warning is a response-header that contains error codes explaining 9991 to what extent the server has been able to match the terminal 9992 request in regards to device capability profile as described using 9993 x-wap-profile and x-wap-profile-diff headers. 9995 o x-predecbufsize defined in [TS-26234]. This response-header 9996 provides an RTSP agent with the TS 26.234 Annex G hypothetical 9997 pre-decoder buffer size. 9999 o x-initpredecbufperiod defined in [TS-26234]. This response-header 10000 provides an RTSP agent with the TS 26.234 Annex G hypothetical 10001 pre-decoder buffering period. 10003 o x-initpostdecbufperiod defined in [TS-26234]. This response- 10004 header provides an RTSP agent with the TS 26.234 Annex G post- 10005 decoder buffering period. 10007 o 3gpp-videopostdecbufsize defined in [TS-26234]. This response- 10008 header provides an RTSP agent with the TS 26.234 defined post- 10009 decoder buffer size usable for H.264 (AVC) video streams. 10011 o 3GPP-Link-Char defined in [TS-26234]. This request-header 10012 provides the RTSP server with the RTSP client's link 10013 characteristics as determined from the radio interface. The 10014 information that can be provided are guaranteed bit-rate, maximum 10015 bit-rate and maximum transfer delay. 10017 o 3GPP-Adaptation defined in [TS-26234]. This general-header is 10018 part of the bit-rate adaptation solution specified for PSS. It 10019 provides the RTSP client's buffer sizes and target buffer levels 10020 to the server and responses are used to acknowledge the support 10021 and values. 10023 o 3GPP-QoE-Metrics defined in [TS-26234]. This general-header is 10024 used by PSS RTSP agents to negotiate the quality of experience 10025 metrics that a client should gather and report to the server. 10027 o 3GPP-QoE-Feedback defined in [TS-26234]. This request-header is 10028 used by RTSP clients supporting PSS to report the actual values of 10029 the metrics gathered in its quality of experience metering. 10031 The use of "x-" is NOT RECOMMENDED but the above headers in the 10032 register list were defined prior to the clarification. 10034 22.5. Accept-Credentials 10036 The security framework's TLS connection mechanism has two 10037 registerable entities. 10039 22.5.1. Accept-Credentials policies 10041 In Section 19.3.1 three policies for how to handle certificates are 10042 specified. Further policies may be defined and MUST be registered 10043 with IANA using the following rules: 10045 o Registering requires an IETF Standards Action 10047 o A registration is required to name a contact person. 10049 o Name of the policy. 10051 o A describing text that explains how the policy works for handling 10052 the certificates. 10054 This specification registers the following values: 10056 Any 10058 Proxy 10060 User 10062 22.5.2. Accept-Credentials hash algorithms 10064 The Accept-Credentials header (See Section 18.2) allows for the usage 10065 of other algorithms for hashing the DER records of accepted entities. 10066 The registration of any future algorithm is expected to be extremely 10067 rare and could also cause interoperability problems. Therefore the 10068 bar for registering new algorithms is intentionally placed high. 10070 Any registration of a new hash algorithm MUST fulfill the following 10071 requirement: 10073 o Follow the IETF Standards Action policy. 10075 o A definition of the algorithm and its identifier meeting the 10076 "token" ABNF requirement. 10078 The registered value is: 10079 Hash Alg. Id Reference 10080 ------------------------ 10081 sha-256 [RFCXXXX] 10083 22.6. Cache-Control Cache Directive Extensions 10085 There exists a number of cache directives which can be sent in the 10086 Cache-Control header. A registry for these cache directives MUST be 10087 defined with the following rules: 10089 o Registering requires an IETF Standards Action or IESG Approval. 10091 o A registration is required to contain a contact person. 10093 o Name of the directive and a definition of the value, if any. 10095 o Specification if it is a request or response directive. 10097 o A describing text that explains how the cache directive is used 10098 for RTSP controlled media streams. 10100 This specification registers the following values: 10102 no-cache: 10104 public: 10106 private: 10108 no-transform: 10110 only-if-cached: 10112 max-stale: 10114 min-fresh: 10116 must-revalidate: 10118 proxy-revalidate: 10120 max-age: 10122 The registry should be represented as: Name of the directive, contact 10123 person and reference. 10125 22.7. Media Properties 10126 22.7.1. Description 10128 The media streams being controlled by RTSP can have many different 10129 properties. The media properties required to cover the use cases 10130 that were in mind when writing the specification are defined. 10131 However, it can be expected that further innovation will result in 10132 new use cases or media streams with properties not covered by the 10133 ones specified here. Thus new media properties can be specified. As 10134 new media properties may need a substantial amount of new definitions 10135 to correctly specify behavior for this property the bar is intended 10136 to be high. 10138 22.7.2. Registration Rules 10140 Registering a new media property MUST fulfill the following 10141 requirements 10143 o Follow the Specification Required policy and get the approval of 10144 the designated Expert. 10146 o Have an ABNF definition of the media property value name that 10147 meets "media-prop-ext" definition 10149 o Define which media property group it belongs to or define a new 10150 group. 10152 o A Contact Person for the Registration 10154 o Description of all changes to the behavior of the RTSP protocol as 10155 result of these changes. 10157 22.7.3. Registered Values 10159 This specification registers the ten values listed in Section 18.29. 10160 The registry should be represented as: Name of the media property, 10161 property group, contact person and reference. 10163 22.8. Notify-Reason header 10165 22.8.1. Description 10167 Notify-Reason values are used for indicating the reason the 10168 notification was sent. Each reason has its associated rules on what 10169 headers and information that may or must be included in the 10170 notification. New notification behaviors need to be specified to 10171 enable interoperable usage, thus a specification of each new value is 10172 required. 10174 22.8.2. Registration Rules 10176 Registrations for new Notify-Reason value MUST fulfill the following 10177 requirements 10179 o Follow the Specification Required policy and get the approval of 10180 the designated Expert. 10182 o An ABNF definition of the Notify reason value name that meets 10183 "Notify-Reason-extension" definition 10185 o A Contact Person for the Registration 10187 o Description of which headers shall be included in the request and 10188 response, when it should be sent, and any effect it has on the 10189 server client state. 10191 22.8.3. Registered Values 10193 This specification registers 3 values defined in the Notify-Reas-val 10194 ABNF, Section 20.2.3: 10196 end-of-stream: This Notify-Reason value indicates the end of a media 10197 stream. 10199 media-properties-update: This Notify-Reason value allows the server 10200 to indicate that the properties of the media has changed during 10201 the playout. 10203 scale-change: This Notify-Reason value allows the server to notify 10204 the client about a change in the Scale of the media. 10206 The registry entries should be represented in the registry as: Name, 10207 short description, contact and reference. 10209 22.9. Range Header Formats 10211 22.9.1. Description 10213 The Range header (Section 18.40) allows for different range formats. 10214 These range formats also needs an identifier to be used the Accept- 10215 Ranges header (Section 18.5). New range formats may be registered, 10216 but moderation should be applied as it makes interoperability more 10217 difficult. 10219 22.9.2. Registration Rules 10221 A registration MUST fulfill the following requirements: 10223 o Follow the Specification Required policy. 10225 o An ABNF definition of the range format that fulfills the "range- 10226 ext" definition. 10228 o Define the range format identifier used in Accept-Ranges header 10229 according to the "extension-format" definition. 10231 o A Contact person for the registration. 10233 o Rules for how one handles the range when using a negative Scale. 10235 22.9.3. Registered Values 10237 The registry should be represented as: Range header format 10238 identifier, Name of the range format, contact person and reference. 10239 This specification registers the following values. 10241 npt: Normal Play Time 10243 clock: UTC Absolute Time format 10245 smpte: SMPTE Timestamps 10247 smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop) 10249 smpte-25: SMPTE Timestamps 25 Frames/sec 10251 22.10. Terminate-Reason Header 10253 The Terminate-Reason header (Section 18.52) has two registries for 10254 extensions. 10256 22.10.1. Redirect Reasons 10258 Registrations are done under the policy of Expert Review. The 10259 registered value needs to follow the Terminate-Reason ABNF, i.e., be 10260 a token. The specification needs to provide a definition of what 10261 procedures are to be followed when a client receives this redirect 10262 reason. This specification registers three values: 10264 o Session-Timeout 10265 o Server-Admin 10267 o Internal-Error 10269 The registry should be represented as: Name of the Redirect Reason, 10270 contact person and reference. 10272 22.10.2. Terminate-Reason Header Parameters 10274 Registrations are done under the policy of Specification Required. 10275 The registrations must define a syntax for the parameter that also 10276 follows the syntax allowed by the RTSP 2.0 specification. A contact 10277 person is also required. This specification registers: 10279 o time 10281 o user-msg 10283 The registry should be represented as: Name of the Terminate Reason, 10284 contact person and reference. 10286 22.11. RTP-Info header parameters 10288 22.11.1. Description 10290 The RTP-Info header (Section 18.45) carries one or more parameter 10291 value pairs with information about a particular point in the RTP 10292 stream. RTP extensions or new usages may need new types of 10293 information. As RTP information that could be needed is likely to be 10294 generic enough and to maximize the interoperability, new registration 10295 requires Specification Required. 10297 22.11.2. Registration Rules 10299 Registrations for new RTP-Info value MUST fulfill the following 10300 requirements 10302 o Follow the Specification Required policy and get the approval of 10303 the designated Expert. 10305 o Have an ABNF definition that meets the "generic-param" definition 10307 o A Contact Person for the Registration 10309 22.11.3. Registered Values 10311 This specification registers the following parameter value pairs: 10313 o url 10315 o ssrc 10317 o seq 10319 o rtptime 10321 The registry should be represented as: Name of the parameter, contact 10322 person and reference. 10324 22.12. Seek-Style Policies 10326 22.12.1. Description 10328 New seek policies may be registered, however, a large number of these 10329 will complicate implementation substantially. The impact of unknown 10330 policies is that the server will not honor the unknown and use the 10331 server default policy instead. 10333 22.12.2. Registration Rules 10335 Registrations of new Seek-Style polices MUST fulfill the following 10336 requirements 10338 o Follow the Specification Required policy. 10340 o Have an ABNF definition of the Seek-Style policy name that meets 10341 "Seek-S-value-ext" definition 10343 o A Contact Person for the Registration 10345 o Description of which headers shall be included in the request and 10346 response, when it should be sent, and any affect it has on the 10347 server client state. 10349 22.12.3. Registered Values 10351 This specification registers 4 values: 10353 o RAP 10355 o CoRAP 10356 o First-Prior 10358 o Next 10360 The registry should be represented as: Name of the Seek-Style Policy, 10361 short description, contact person and reference. 10363 22.13. Transport Header Registries 10365 The transport header (Section 18.54) contains a number of parameters 10366 which have possibilities for future extensions. Therefore registries 10367 for these need to be defined. 10369 22.13.1. Transport Protocol Identifier 10371 A Transport Protocol Specification consists of a Transport Protocol 10372 Identifier, representing some combination of transport protocols, and 10373 any number of transport header parameters required or optional to use 10374 with the identified protocol specification. This registry contains 10375 the identifiers used by registered Transport Protocol Identifiers. 10377 A registry for the parameter transport protocol identifier MUST be 10378 defined with the following rules: 10380 o Registering uses the policy of Specification Required. 10382 o A contact person or organization with address and email. 10384 o A value definition that are following the ABNF syntax definition 10385 of "transport-id" Section 20.2.3. 10387 o A descriptive text that explains how the registered value are used 10388 in RTSP, which underlying transport protocols that are used, and 10389 any required Transport header parameters. 10391 The registry should be represented as: The protocol ID string, 10392 contact person and reference. 10394 This specification registers the following values: 10396 RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in 10397 combination with the "RTP profile for audio and video 10398 conferences with minimal control" [RFC3551] over UDP. The 10399 usage is explained in RFC XXXX, Appendix C.1. 10401 RTP/AVP/UDP: the same as RTP/AVP. 10403 RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in 10404 combination with the "Extended RTP Profile for RTCP-based 10405 Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is 10406 explained in RFC XXXX, Appendix C.1. 10408 RTP/AVPF/UDP: the same as RTP/AVPF. 10410 RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in 10411 combination with the "The Secure Real-time Transport Protocol 10412 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 10413 XXXX, Appendix C.1. 10415 RTP/SAVP/UDP: the same as RTP/SAVP. 10417 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 10418 combination with the Extended Secure RTP Profile for Real-time 10419 Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 10420 [RFC5124] over UDP. The usage is explained in RFC XXXX, 10421 Appendix C.1. 10423 RTP/SAVPF/UDP: the same as RTP/SAVPF. 10425 RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10426 in combination with the "RTP profile for audio and video 10427 conferences with minimal control" [RFC3551] over TCP. The 10428 usage is explained in RFC XXXX, Appendix C.2.2. 10430 RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10431 in combination with the "Extended RTP Profile for RTCP-based 10432 Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is 10433 explained in RFC XXXX, Appendix C.2.2. 10435 RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10436 in combination with the "The Secure Real-time Transport 10437 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 10438 RFC XXXX, Appendix C.2.2. 10440 RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10441 in combination with the "Extended Secure RTP Profile for Real- 10442 time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 10443 SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 10444 XXXX, Appendix C.2.2. 10446 22.13.2. Transport modes 10448 The Transport Mode is a Transport header (Section 18.54) parameter, 10449 it is used to identify the general mode of media transport. The PLAY 10450 value registered defines a PLAYBACK mode, where media flows from 10451 Server to Client. 10453 A registry for the transport parameter mode MUST be defined with the 10454 following rules: 10456 o Registering requires an IETF Standards Action. 10458 o A contact person or organization with address and email. 10460 o A value definition that are following the ABNF "token" definition 10461 Section 20.2.3. 10463 o A describing text that explains how the registered value are used 10464 in RTSP. 10466 This specification registers 1 value: 10468 PLAY: See RFC XXXX. 10470 The registry should be represented as: The Transport Mode value, 10471 contact person and reference. 10473 22.13.3. Transport Parameters 10475 Transport Parameters are different parameters used in a Transport 10476 Header's transport specification (Section 18.54) to provide 10477 additional information required beyond the transport protocol 10478 identifier to establish a functioning transport. 10480 A registry for parameters that may be included in the Transport 10481 header MUST be defined with the following rules: 10483 o Registering uses the Specification Required policy. 10485 o A Transport Parameter Name following the "token" ABNF definition. 10487 o A value definition, if the parameter takes a value, that are 10488 following the ABNF definition "trn-par-value" Section 20.2.3. 10490 o A describing text that explains how the registered value are used 10491 in RTSP. 10493 This specification registers all the transport parameters defined in 10494 Section 18.54. This is a copy of this list: 10496 o unicast 10498 o multicast 10500 o interleaved 10502 o ttl 10504 o layers 10506 o ssrc 10508 o mode 10510 o dest_addr 10512 o src_addr 10514 o setup 10516 o connection 10518 o RTCP-mux 10520 o MIKEY 10522 The registry should be represented as: The transport parameter name, 10523 contact person and reference. 10525 22.14. URI Schemes 10527 This specification updates two URI schemes, one previously registered 10528 "rtsp", and one missing in the registry "rtspu", previously only 10529 defined in the RTSP 1.0 [RFC2326], one new URI scheme "rtsps" is also 10530 registered. These URI schemes are registered in an existing registry 10531 (Uniform Resource Identifier (URI) Schemes) which is not created by 10532 this memo. Registrations are following RFC 4395[RFC4395]. 10534 22.14.1. The rtsp URI Scheme 10536 URI scheme name: rtsp 10538 Status: Permanent 10539 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10541 URI scheme semantics: The rtsp scheme is used to indicate resources 10542 accessible through the usage of the Real-time Streaming 10543 Protocol (RTSP). RTSP allows different operations on the 10544 resource identified by the URI, but the primary purpose is the 10545 streaming delivery of the resource to a client. However, the 10546 operations that are currently defined are: DESCRIBE, 10547 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10548 SETUP, SET_PARAMETER, and TEARDOWN. 10550 Encoding considerations: IRIs in this scheme are defined and needs 10551 to be encoded as RTSP URIs when used within the RTSP protocol. 10552 That encoding is done according to RFC 3987. 10554 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10555 2326), RTSP 2.0 (RFC XXXX) 10557 Interoperability considerations: The extensions in the URI syntax 10558 performed between RTSP 1.0 and 2.0 can create interoperability 10559 issues. The changes are: 10561 Support for IPV6 literal in host part and future IP 10562 literals through RFC 3986 defined mechanism. 10564 A new relative format to use in the RTSP protocol 10565 elements that is not required to start with "/". 10567 The above changes should have no impact on interoperability as 10568 in detail discussed in Section 4.2 of RFCXXXX. 10570 Security considerations: All the security threats identified in 10571 Section 7 of RFC 3986 apply also to this scheme. They need to 10572 be reviewed and considered in any implementation utilizing this 10573 scheme. 10575 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10577 Author/Change controller: IETF 10579 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10581 22.14.2. The rtsps URI Scheme 10582 URI scheme name: rtsps 10584 Status: Permanent 10586 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10588 URI scheme semantics: The rtsps scheme is used to indicate resources 10589 accessible through the usage of the Real-time Streaming 10590 Protocol (RTSP) over TLS. RTSP allows different operations on 10591 the resource identified by the URI, but the primary purpose is 10592 the streaming delivery of the resource to a client. However, 10593 the operations that are currently defined are: DESCRIBE, 10594 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10595 SETUP, SET_PARAMETER, and TEARDOWN. 10597 Encoding considerations: IRIs in this scheme are defined and needs 10598 to be encoded as RTSP URIs when used within the RTSP protocol. 10599 That encoding is done according to RFC 3987. 10601 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10602 2326), RTSP 2.0 (RFC XXXX) 10604 Interoperability considerations: The "rtsps" scheme was never 10605 officially defined for RTSP 1.0, however it has seen widespread 10606 use in actual deployments of RTSP 1.0. Therefore this section 10607 discusses the believed changes between the unspecified RTSP 1.0 10608 "rtsps" scheme and RTSP 2.0 definition. The extensions in the 10609 URI syntax performed between RTSP 1.0 and 2.0 can create 10610 interoperability issues. The changes are: 10612 Support for IPV6 literal in host part and future IP 10613 literals through RFC 3986 defined mechanism. 10615 A new relative format to use in the RTSP protocol 10616 elements that is not required to start with "/". 10618 The above changes should have no impact on interoperability as 10619 in detail discussed in Section 4.2 of RFCXXXX. 10621 Security considerations: All the security threats identified in 10622 Section 7 of RFC 3986 apply also to this scheme. They need to 10623 be reviewed and considered in any implementation utilizing this 10624 scheme. 10626 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10627 Author/Change controller: IETF 10629 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10631 22.14.3. The rtspu URI Scheme 10633 URI scheme name: rtspu 10635 Status: Permanent 10637 URI scheme syntax: See Section 3.2 of RFC 2326. 10639 URI scheme semantics: The rtspu scheme is used to indicate resources 10640 accessible through the usage of the Real-time Streaming 10641 Protocol (RTSP) over unreliable datagram transport. RTSP 10642 allows different operations on the resource identified by the 10643 URI, but the primary purpose is the streaming delivery of the 10644 resource to a client. However, the operations that are 10645 currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, 10646 REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and 10647 TEARDOWN. 10649 Encoding considerations: This scheme is not intended to be used with 10650 characters outside the US-ASCII repertoire. 10652 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10653 2326) 10655 Interoperability considerations: The definition of the transport 10656 mechanism of RTSP over UDP has interoperability issues. That 10657 makes the usage of this scheme problematic. 10659 Security considerations: All the security threats identified in 10660 Section 7 of RFC 3986 apply also to this scheme. They needs to 10661 be reviewed and considered in any implementation utilizing this 10662 scheme. 10664 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10666 Author/Change controller: IETF 10668 References: RFC 2326 10670 22.15. SDP attributes 10672 This specification defines three SDP [RFC4566] attributes that it is 10673 requested that IANA register. 10675 SDP Attribute ("att-field"): 10677 Attribute name: range 10678 Long form: Media Range Attribute 10679 Type of name: att-field 10680 Type of attribute: Media and session level 10681 Subject to charset: No 10682 Purpose: RFC XXXX 10683 Reference: RFC XXXX, RFC 2326 10684 Values: See ABNF definition. 10686 Attribute name: control 10687 Long form: RTSP control URI 10688 Type of name: att-field 10689 Type of attribute: Media and session level 10690 Subject to charset: No 10691 Purpose: RFC XXXX 10692 Reference: RFC XXXX, RFC 2326 10693 Values: Absolute or Relative URIs. 10695 Attribute name: mtag 10696 Long form: Message Tag 10697 Type of name: att-field 10698 Type of attribute: Media and session level 10699 Subject to charset: No 10700 Purpose: RFC XXXX 10701 Reference: RFC XXXX 10702 Values: See ABNF definition 10704 22.16. Media Type Registration for text/parameters 10706 Type name: text 10708 Subtype name: parameters 10710 Required parameters: 10712 Optional parameters: charset: The charset parameter is applicable to 10713 the encoding of the parameter values. The default charset is 10714 UTF-8, if the 'charset' parameter is not present. 10716 Encoding considerations: 8bit 10718 Security considerations: This format may carry any type of 10719 parameters. Some can have security requirements, like privacy, 10720 confidentiality or integrity requirements. The format has no 10721 built in security protection. For the usage it was defined the 10722 transport can be protected between server and client using TLS. 10723 However, care must be taken to consider if also the proxies are 10724 trusted with the parameters in case hop-by-hop security is used. 10725 If stored as a file in file system, the necessary precautions need 10726 to be taken in relation to the parameters requirements including 10727 object security such as S/MIME [RFC5751]. 10729 Interoperability considerations: This media type was mentioned as a 10730 fictional example in [RFC2326], but was not formally specified. 10731 This has resulted in usage of this media type which may not match 10732 its formal definition. 10734 Published specification: RFC XXXX, Appendix F. 10736 Applications that use this media type: Applications that use RTSP 10737 and have additional parameters they like to read and set using the 10738 RTSP GET_PARAMETER and SET_PARAMETER methods. 10740 Additional information: 10742 Magic number(s): 10744 File extension(s): 10746 Macintosh file type code(s): 10748 Person & email address to contact for further information: Magnus 10749 Westerlund (magnus.westerlund@ericsson.com) 10751 Intended usage: Common 10753 Restrictions on usage: None 10755 Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 10757 Change controller: IETF 10759 Addition Notes: 10761 23. References 10763 23.1. Normative References 10765 [FIPS-pub-180-2] 10766 National Institute of Standards and Technology (NIST), 10767 "Federal Information Processing Standards Publications 10768 (FIPS PUBS) 180-2: Secure Hash Standard", August 2002. 10770 [I-D.ietf-avtcore-rtp-circuit-breakers] 10771 Perkins, C. and V. Singh, "Multimedia Congestion Control: 10772 Circuit Breakers for Unicast RTP Sessions", 10773 draft-ietf-avtcore-rtp-circuit-breakers-03 (work in 10774 progress), July 2013. 10776 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 10777 August 1980. 10779 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 10780 RFC 793, September 1981. 10782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10783 Requirement Levels", BCP 14, RFC 2119, March 1997. 10785 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 10786 (IPv6) Specification", RFC 2460, December 1998. 10788 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 10789 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 10790 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 10792 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 10793 Leach, P., Luotonen, A., and L. Stewart, "HTTP 10794 Authentication: Basic and Digest Access Authentication", 10795 RFC 2617, June 1999. 10797 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 10799 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 10800 Jacobson, "RTP: A Transport Protocol for Real-Time 10801 Applications", STD 64, RFC 3550, July 2003. 10803 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 10804 Video Conferences with Minimal Control", STD 65, RFC 3551, 10805 July 2003. 10807 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10808 10646", STD 63, RFC 3629, November 2003. 10810 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 10811 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 10812 RFC 3711, March 2004. 10814 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 10815 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 10816 August 2004. 10818 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 10819 Resource Identifier (URI): Generic Syntax", STD 66, 10820 RFC 3986, January 2005. 10822 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 10823 Identifiers (IRIs)", RFC 3987, January 2005. 10825 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 10826 Requirements for Security", BCP 106, RFC 4086, June 2005. 10828 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10829 Architecture", RFC 4291, February 2006. 10831 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 10832 Registration Procedures for New URI Schemes", BCP 35, 10833 RFC 4395, February 2006. 10835 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 10836 Description Protocol", RFC 4566, July 2006. 10838 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 10839 and RTP Control Protocol (RTCP) Packets over Connection- 10840 Oriented Transport", RFC 4571, July 2006. 10842 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 10843 "Extended RTP Profile for Real-time Transport Control 10844 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 10845 July 2006. 10847 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 10848 Encodings", RFC 4648, October 2006. 10850 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 10851 RSA-R: An Additional Mode of Key Distribution in 10852 Multimedia Internet KEYing (MIKEY)", RFC 4738, 10853 November 2006. 10855 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 10856 Real-time Transport Control Protocol (RTCP)-Based Feedback 10857 (RTP/SAVPF)", RFC 5124, February 2008. 10859 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 10860 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 10861 May 2008. 10863 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 10864 Specifications: ABNF", STD 68, RFC 5234, January 2008. 10866 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 10867 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 10869 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 10870 Housley, R., and W. Polk, "Internet X.509 Public Key 10871 Infrastructure Certificate and Certificate Revocation List 10872 (CRL) Profile", RFC 5280, May 2008. 10874 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 10875 October 2008. 10877 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 10878 Languages", BCP 47, RFC 5646, September 2009. 10880 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 10881 Mail Extensions (S/MIME) Version 3.2 Message 10882 Specification", RFC 5751, January 2010. 10884 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 10885 Control Packets on a Single Port", RFC 5761, April 2010. 10887 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 10888 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 10890 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 10891 Specifications and Registration Procedures", BCP 13, 10892 RFC 6838, January 2013. 10894 [SMPTE_TC] 10895 Society of Motion Picture and Television Engineers, "SMPTE 10896 Standard for Television -- Time and Control Code, ST 12M- 10897 1-2008". 10899 [TS-26234] 10900 Third Generation Partnership Project (3GPP), "Transparent 10901 end-to-end Packet-switched Streaming Service (PSS); 10902 Protocols and codecs; Technical Specification 26.234", 10903 December 2002. 10905 23.2. Informative References 10907 [I-D.ietf-mmusic-rtsp-nat] 10908 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 10909 Address Translator (NAT) Traversal mechanism for media 10910 controlled by Real-Time Streaming Protocol (RTSP)", 10911 draft-ietf-mmusic-rtsp-nat-16 (work in progress), 10912 May 2013. 10914 [ISO.13818-6.1995] 10915 International Organization for Standardization, 10916 "Information technology - Generic coding of moving 10917 pictures and associated audio information - part 6: 10918 Extension for digital storage media and control", 10919 ISO Draft Standard 13818-6, November 1995. 10921 [ISO.8601.2000] 10922 International Organization for Standardization, "Data 10923 elements and interchange formats - Information interchange 10924 - Representation of dates and times", ISO/IEC Standard 10925 8601, December 2000. 10927 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 10928 September 1981. 10930 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 10931 and Support", STD 3, RFC 1123, October 1989. 10933 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 10934 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 10935 RFC 2068, January 1997. 10937 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 10938 Streaming Protocol (RTSP)", RFC 2326, April 1998. 10940 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 10941 Translator (NAT) Terminology and Considerations", 10942 RFC 2663, August 1999. 10944 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 10945 Announcement Protocol", RFC 2974, October 2000. 10947 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 10948 A., Peterson, J., Sparks, R., Handley, M., and E. 10949 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 10950 June 2002. 10952 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 10953 with Session Description Protocol (SDP)", RFC 3264, 10954 June 2002. 10956 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 10957 Internet: Timestamps", RFC 3339, July 2002. 10959 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 10960 the Session Description Protocol (SDP)", RFC 4145, 10961 September 2005. 10963 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 10964 Carrara, "Key Management Extensions for Session 10965 Description Protocol (SDP) and Real Time Streaming 10966 Protocol (RTSP)", RFC 4567, July 2006. 10968 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 10969 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 10970 July 2006. 10972 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 10973 Formats", RFC 4855, February 2007. 10975 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 10976 the RTP Profile for Audio and Video Conferences", 10977 RFC 4856, February 2007. 10979 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 10980 "Codec Control Messages in the RTP Audio-Visual Profile 10981 with Feedback (AVPF)", RFC 5104, February 2008. 10983 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 10984 (ICE): A Protocol for Network Address Translator (NAT) 10985 Traversal for Offer/Answer Protocols", RFC 5245, 10986 April 2010. 10988 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 10989 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 10990 October 2008. 10992 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 10993 Dependency in the Session Description Protocol (SDP)", 10994 RFC 5583, July 2009. 10996 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 10997 Time Protocol Version 4: Protocol and Algorithms 10998 Specification", RFC 5905, June 2010. 11000 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 11001 "Computing TCP's Retransmission Timer", RFC 6298, 11002 June 2011. 11004 [Stevens98] 11005 Stevens, W., "Unix Networking Programming - Volume 1, 11006 second edition", 1998. 11008 Appendix A. Examples 11010 This section contains several different examples trying to illustrate 11011 possible ways of using RTSP. The examples can also help with the 11012 understanding of how functions of RTSP work. However, remember that 11013 these are examples and the normative and syntax description in the 11014 other sections take precedence. Please also note that many of the 11015 examples contain syntax illegal line breaks to accommodate the 11016 formatting restriction that the RFC series impose. 11018 A.1. Media on Demand (Unicast) 11020 This is an example of media on demand streaming of a media stored in 11021 a container file. For purposes of this example, a container file is 11022 a storage entity in which multiple continuous media types pertaining 11023 to the same end-user presentation are present. In effect, the 11024 container file represents an RTSP presentation, with each of its 11025 components being RTSP controlled media streams. Container files are 11026 a widely used means to store such presentations. While the 11027 components are transported as independent streams, it is desirable to 11028 maintain a common context for those streams at the server end. 11030 This enables the server to keep a single storage handle open 11031 easily. It also allows treating all the streams equally in case 11032 of any prioritization of streams by the server. 11034 It is also possible that the presentation author may wish to prevent 11035 selective retrieval of the streams by the client in order to preserve 11036 the artistic effect of the combined media presentation. Similarly, 11037 in such a tightly bound presentation, it is desirable to be able to 11038 control all the streams via a single control message using an 11039 aggregate URI. 11041 The following is an example of using a single RTSP session to control 11042 multiple streams. It also illustrates the use of aggregate URIs. In 11043 a container file it is also desirable to not write any URI parts 11044 which are not kept, when the container is distributed, like the host 11045 and most of the path element. Therefore this example also uses the 11046 "*" and relative URI in the delivered SDP. 11048 Also this presentation description (SDP) is not cacheble, as the 11049 Expires header is set to an equal value with date indicating 11050 immediate expiration of its validity. 11052 Client C requests a presentation from media server M. The movie is 11053 stored in a container file. The client has obtained an RTSP URI to 11054 the container file. 11056 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11057 CSeq: 1 11058 User-Agent: PhonyClient/1.2 11060 M->C: RTSP/2.0 200 OK 11061 CSeq: 1 11062 Server: PhonyServer/1.0 11063 Date: Thu, 24 Jan 1997 15:35:06 GMT 11064 Content-Type: application/sdp 11065 Content-Length: 271 11066 Content-Base: rtsp://example.com/twister.3gp/ 11067 Expires: 24 Jan 1997 15:35:06 GMT 11069 v=0 11070 o=- 2890844256 2890842807 IN IP4 198.51.100.5 11071 s=RTSP Session 11072 i=An Example of RTSP Session Usage 11073 e=adm@example.com 11074 c=IN IP4 0.0.0.0 11075 a=control: * 11076 a=range:npt=0-0:10:34.10 11077 t=0 0 11078 m=audio 0 RTP/AVP 0 11079 a=control: trackID=1 11080 m=video 0 RTP/AVP 26 11081 a=control: trackID=4 11083 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11084 CSeq: 2 11085 User-Agent: PhonyClient/1.2 11086 Require: play.basic 11087 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11088 Accept-Ranges: npt, smpte, clock 11090 M->C: RTSP/2.0 200 OK 11091 CSeq: 2 11092 Server: PhonyServer/1.0 11093 Transport: RTP/AVP;unicast; ssrc=93CB001E; 11094 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11095 src_addr="198.51.100.5:9000"/"198.51.100.5:9001" 11096 Session: 12345678 11097 Expires: 24 Jan 1997 15:35:12 GMT 11098 Date: 24 Jan 1997 15:35:12 GMT 11099 Accept-Ranges: npt 11100 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11102 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11103 CSeq: 3 11104 User-Agent: PhonyClient/1.2 11105 Require: play.basic 11106 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11107 Session: 12345678 11108 Accept-Ranges: npt, smpte, clock 11110 M->C: RTSP/2.0 200 OK 11111 CSeq: 3 11112 Server: PhonyServer/1.0 11113 Transport: RTP/AVP;unicast; ssrc=A813FC13; 11114 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 11115 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11117 Session: 12345678 11118 Expires: 24 Jan 1997 15:35:13 GMT 11119 Date: 24 Jan 1997 15:35:13 GMT 11120 Accept-Range: NPT 11121 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11123 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11124 CSeq: 4 11125 User-Agent: PhonyClient/1.2 11126 Range: npt=30- 11127 Seek-Style: RAP 11128 Session: 12345678 11130 M->C: RTSP/2.0 200 OK 11131 CSeq: 4 11132 Server: PhonyServer/1.0 11133 Date: 24 Jan 1997 15:35:14 GMT 11134 Session: 12345678 11135 Range: npt=30-634.10 11136 Seek-Style: RAP 11137 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11138 ssrc=0D12F123:seq=12345;rtptime=3450012, 11139 url="rtsp://example.com/twister.3gp/trackID=1" 11140 ssrc=4F312DD8:seq=54321;rtptime=2876889 11142 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 11143 CSeq: 5 11144 User-Agent: PhonyClient/1.2 11145 Session: 12345678 11147 # Pause happens 0.87 seconds after starting to play 11149 M->C: RTSP/2.0 200 OK 11150 CSeq: 5 11151 Server: PhonyServer/1.0 11152 Date: 24 Jan 1997 15:36:01 GMT 11153 Session: 12345678 11154 Range: npt=30.87-634.10 11156 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11157 CSeq: 6 11158 User-Agent: PhonyClient/1.2 11159 Range: npt=30.87-634.10 11160 Seek-Style: Next 11161 Session: 12345678 11163 M->C: RTSP/2.0 200 OK 11164 CSeq: 6 11165 Server: PhonyServer/1.0 11166 Date: 24 Jan 1997 15:36:01 GMT 11167 Session: 12345678 11168 Range: npt=30.87-634.10 11169 Seek-Style: Next 11170 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11171 ssrc=0D12F123:seq=12555;rtptime=6330012, 11172 url="rtsp://example.com/twister.3gp/trackID=1" 11173 ssrc=4F312DD8:seq=55021;rtptime=3132889 11175 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 11176 CSeq: 7 11177 User-Agent: PhonyClient/1.2 11178 Session: 12345678 11180 M->C: RTSP/2.0 200 OK 11181 CSeq: 7 11182 Server: PhonyServer/1.0 11183 Date: 24 Jan 1997 15:49:34 GMT 11185 A.2. Media on Demand using Pipelining 11187 This example is basically the example above (Appendix A.1), but now 11188 utilizing pipelining to speed up the setup. It requires only two 11189 round trip times until the media starts flowing. First of all, the 11190 session description is retrieved to determine what media resources 11191 need to be setup. In the second step, one sends the necessary SETUP 11192 requests and the PLAY request to initiate media delivery. 11194 Client C requests a presentation from media server M. The movie is 11195 stored in a container file. The client has obtained an RTSP URI to 11196 the container file. 11198 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11199 CSeq: 1 11200 User-Agent: PhonyClient/1.2 11202 M->C: RTSP/2.0 200 OK 11203 CSeq: 1 11204 Server: PhonyServer/1.0 11205 Date: Thu, 23 Jan 1997 15:35:06 GMT 11206 Content-Type: application/sdp 11207 Content-Length: 271 11208 Content-Base: rtsp://example.com/twister.3gp/ 11209 Expires: 24 Jan 1997 15:35:06 GMT 11211 v=0 11212 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11213 s=RTSP Session 11214 i=An Example of RTSP Session Usage 11215 e=adm@example.com 11216 c=IN IP4 0.0.0.0 11217 a=control: * 11218 a=range:npt=0-0:10:34.10 11219 t=0 0 11220 m=audio 0 RTP/AVP 0 11221 a=control: trackID=1 11222 m=video 0 RTP/AVP 26 11223 a=control: trackID=4 11225 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11226 CSeq: 2 11227 User-Agent: PhonyClient/1.2 11228 Require: play.basic 11229 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11230 Accept-Ranges: npt, smpte, clock 11231 Pipelined-Requests: 7654 11233 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11234 CSeq: 3 11235 User-Agent: PhonyClient/1.2 11236 Require: play.basic 11237 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11238 Accept-Ranges: npt, smpte, clock 11239 Pipelined-Requests: 7654 11241 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11242 CSeq: 4 11243 User-Agent: PhonyClient/1.2 11244 Range: npt=0- 11245 Seek-Style: RAP 11246 Pipelined-Requests: 7654 11248 M->C: RTSP/2.0 200 OK 11249 CSeq: 2 11250 Server: PhonyServer/1.0 11251 Transport: RTP/AVP;unicast; 11252 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11253 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11254 ssrc=93CB001E 11255 Session: 12345678 11256 Expires: 24 Jan 1997 15:35:12 GMT 11257 Date: 23 Jan 1997 15:35:12 GMT 11258 Accept-Ranges: npt 11259 Pipelined-Requests: 7654 11260 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11262 M->C: RTSP/2.0 200 OK 11263 CSeq: 3 11264 Server: PhonyServer/1.0 11265 Transport: RTP/AVP;unicast; 11266 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11267 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11268 ssrc=A813FC13 11269 Session: 12345678 11270 Expires: 24 Jan 1997 15:35:13 GMT 11271 Date: 23 Jan 1997 15:35:13 GMT 11272 Accept-Range: NPT 11273 Pipelined-Requests: 7654 11274 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11276 M->C: RTSP/2.0 200 OK 11277 CSeq: 4 11278 Server: PhonyServer/1.0 11279 Date: 23 Jan 1997 15:35:14 GMT 11280 Session: 12345678 11281 Range: npt=0-623.10 11282 Seek-Style: RAP 11283 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11284 ssrc=0D12F123:seq=12345;rtptime=3450012, 11285 url="rtsp://example.com/twister.3gp/trackID=1" 11286 ssrc=4F312DD8:seq=54321;rtptime=2876889 11287 Pipelined-Requests: 7654 11289 A.3. Secured Media Session for on Demand Content 11291 This example is basically the above example (Appendix A.2), but now 11292 including establishment of SRTP crypto contexts to get a secured 11293 media delivery. First of all, the client attempts to fetch this 11294 insecurely, but the server redirects to a URI indicating a 11295 requirement on using a secure connection for the RTSP messages. The 11296 client establishes a TCP/TLS connections and the session description 11297 is retrieved to determine what media resources need to be setup. In 11298 the this session description secure media (SRTP) is indicated. In 11299 the next step, the client sends the necessary SETUP requests 11300 including MIKEY messages. This is pipeline with a PLAY request to 11301 initiate media delivery. 11303 Client C requests a presentation from media server M. The movie is 11304 stored in a container file. The client has obtained an RTSP URI to 11305 the container file. 11307 Note: The MIKEY messages below are not valid MIKEY message and are 11308 BASE64 encoded random data to represent where the MIKEY messages 11309 would go. 11310 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11311 CSeq: 1 11312 User-Agent: PhonyClient/1.2 11314 M->C: RTSP/2.0 301 Moved Permanently 11315 CSeq: 1 11316 Server: PhonyServer/1.0 11317 Date: Thu, 23 Jan 1997 15:35:06 GMT 11318 Location: rtsps://example.com/twister.3gp 11320 C->M: Establish TCP/TLS connection and verify server's 11321 certificate that is represents example.com. 11322 Used for all below RTSP messages. 11324 C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0 11325 CSeq: 2 11326 User-Agent: PhonyClient/1.2 11328 M->C: RTSP/2.0 200 OK 11329 CSeq: 2 11330 Server: PhonyServer/1.0 11331 Date: Thu, 23 Jan 1997 15:35:06 GMT 11332 Content-Type: application/sdp 11333 Content-Length: 271 11334 Content-Base: rtsps://example.com/twister.3gp/ 11335 Expires: 24 Jan 1997 15:35:06 GMT 11337 v=0 11338 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11339 s=RTSP Session 11340 i=An Example of RTSP Session Usage 11341 e=adm@example.com 11342 c=IN IP4 0.0.0.0 11343 a=control: * 11344 a=range:npt=0-0:10:34.10 11345 t=0 0 11346 m=audio 0 RTP/SAVP 0 11347 a=control: trackID=1 11348 m=video 0 RTP/SAVP 26 11349 a=control: trackID=4 11351 C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0 11352 CSeq: 3 11353 User-Agent: PhonyClient/1.2 11354 Require: play.basic 11355 Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001"; 11356 MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl 11357 Accept-Ranges: npt, smpte, clock 11358 Pipelined-Requests: 7654 11360 C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0 11361 CSeq: 4 11362 User-Agent: PhonyClient/1.2 11363 Require: play.basic 11364 Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003"; 11365 MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ= 11366 Accept-Ranges: npt, smpte, clock 11367 Pipelined-Requests: 7654 11369 C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0 11370 CSeq: 5 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: 3 11378 Server: PhonyServer/1.0 11379 Transport: RTP/SAVP;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 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x 11384 Session: 12345678 11385 Expires: 24 Jan 1997 15:35:12 GMT 11386 Date: 23 Jan 1997 15:35:12 GMT 11387 Accept-Ranges: npt 11388 Pipelined-Requests: 7654 11389 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11391 M->C: RTSP/2.0 200 OK 11392 CSeq: 4 11393 Server: PhonyServer/1.0 11394 Transport: RTP/SAVP;unicast; 11395 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11396 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11397 ssrc=A813FC13; 11398 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 11399 Session: 12345678 11400 Expires: 24 Jan 1997 15:35:13 GMT 11401 Date: 23 Jan 1997 15:35:13 GMT 11402 Accept-Range: NPT 11403 Pipelined-Requests: 7654 11404 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11406 M->C: RTSP/2.0 200 OK 11407 CSeq: 5 11408 Server: PhonyServer/1.0 11409 Date: 23 Jan 1997 15:35:14 GMT 11410 Session: 12345678 11411 Range: npt=0-623.10 11412 Seek-Style: RAP 11413 RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" 11414 ssrc=0D12F123:seq=12345;rtptime=3450012, 11415 url="rtsps://example.com/twister.3gp/trackID=1" 11416 ssrc=4F312DD8:seq=54321;rtptime=2876889; 11418 Pipelined-Requests: 7654 11420 A.4. Media on Demand (Unicast) 11422 An alternative example of media on demand with a bit more tweaks is 11423 the following. Client C requests a movie distributed from two 11424 different media servers A (audio.example.com) and V ( 11425 video.example.com). The media description is stored on a web server 11426 W. The media description contains descriptions of the presentation 11427 and all its streams, including the codecs that are available, dynamic 11428 RTP payload types, the protocol stack, and content information such 11429 as language or copyright restrictions. It may also give an 11430 indication about the timeline of the movie. 11432 In this example, the client is only interested in the last part of 11433 the movie. 11435 C->W: GET /twister.sdp HTTP/1.1 11436 Host: www.example.com 11437 Accept: application/sdp 11439 W->C: HTTP/1.1 200 OK 11440 Date: Thu, 23 Jan 1997 15:35:06 GMT 11441 Content-Type: application/sdp 11442 Content-Length: 278 11443 Expires: 23 Jan 1998 15:35:06 GMT 11445 v=0 11446 o=- 2890844526 2890842807 IN IP4 198.51.100.5 11447 s=RTSP Session 11448 e=adm@example.com 11449 c=IN IP4 0.0.0.0 11450 a=range:npt=0-1:49:34 11451 t=0 0 11452 m=audio 0 RTP/AVP 0 11453 a=control:rtsp://audio.example.com/twister/audio.en 11454 m=video 0 RTP/AVP 31 11455 a=control:rtsp://video.example.com/twister/video 11457 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 11458 CSeq: 1 11459 User-Agent: PhonyClient/1.2 11460 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 11461 RTP/AVP/TCP;unicast;interleaved=0-1 11462 Accept-Ranges: npt, smpte, clock 11464 A->C: RTSP/2.0 200 OK 11465 CSeq: 1 11466 Session: 12345678 11467 Transport: RTP/AVP/UDP;unicast; 11468 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11469 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11470 Date: 23 Jan 1997 15:35:12 GMT 11471 Server: PhonyServer/1.0 11472 Expires: 24 Jan 1997 15:35:12 GMT 11473 Cache-Control: public 11474 Accept-Ranges: npt, smpte 11475 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11477 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 11478 CSeq: 1 11479 User-Agent: PhonyClient/1.2 11480 Transport: RTP/AVP/UDP;unicast; 11481 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", 11482 RTP/AVP/TCP;unicast;interleaved=0-1 11483 Accept-Ranges: npt, smpte, clock 11485 V->C: RTSP/2.0 200 OK 11486 CSeq: 1 11487 Session: 23456789 11488 Transport: RTP/AVP/UDP;unicast; 11489 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; 11490 src_addr="198.51.100.5:5002"/"198.51.100.5:5003" 11491 Date: 23 Jan 1997 15:35:12 GMT 11492 Server: PhonyServer/1.0 11493 Cache-Control: public 11494 Expires: 24 Jan 1997 15:35:12 GMT 11495 Accept-Ranges: npt, smpte 11496 Media-Properties: Random-Access=1.2, Immutable, Unlimited 11498 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 11499 CSeq: 2 11500 User-Agent: PhonyClient/1.2 11501 Session: 23456789 11502 Range: smpte=0:10:00- 11504 V->C: RTSP/2.0 200 OK 11505 CSeq: 2 11506 Session: 23456789 11507 Range: smpte=0:10:00-1:49:23 11508 Seek-Style: First-Prior 11509 RTP-Info: url="rtsp://video.example.com/twister/video" 11510 ssrc=A17E189D:seq=12312232;rtptime=78712811 11511 Server: PhonyServer/2.0 11512 Date: 23 Jan 1997 15:35:13 GMT 11514 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 11515 CSeq: 2 11516 User-Agent: PhonyClient/1.2 11517 Session: 12345678 11518 Range: smpte=0:10:00- 11520 A->C: RTSP/2.0 200 OK 11521 CSeq: 2 11522 Session: 12345678 11523 Range: smpte=0:10:00-1:49:23 11524 Seek-Style: First-Prior 11525 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 11526 ssrc=3D124F01:seq=876655;rtptime=1032181 11527 Server: PhonyServer/1.0 11528 Date: 23 Jan 1997 15:35:13 GMT 11530 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 11531 CSeq: 3 11532 User-Agent: PhonyClient/1.2 11533 Session: 12345678 11535 A->C: RTSP/2.0 200 OK 11536 CSeq: 3 11537 Server: PhonyServer/1.0 11538 Date: 23 Jan 1997 15:36:52 GMT 11540 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 11541 CSeq: 3 11542 User-Agent: PhonyClient/1.2 11543 Session: 23456789 11545 V->C: RTSP/2.0 200 OK 11546 CSeq: 3 11547 Server: PhonyServer/2.0 11548 Date: 23 Jan 1997 15:36:52 GMT 11550 Even though the audio and video track are on two different servers 11551 that may start at slightly different times and may drift with respect 11552 to each other over time, the client can perform initial 11553 synchronization of the two media using RTP-Info and Range received in 11554 the PLAY responses. If the two servers are time synchronized the 11555 RTCP packets can also be used to maintain synchronization. 11557 A.5. Single Stream Container Files 11559 Some RTSP servers may treat all files as though they are "container 11560 files", yet other servers may not support such a concept. Because of 11561 this, clients needs to use the rules set forth in the session 11562 description for Request-URIs, rather than assuming that a consistent 11563 URI may always be used throughout. Below is an example of how a 11564 multi-stream server might expect a single-stream file to be served: 11566 C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 11567 Accept: application/x-rtsp-mh, application/sdp 11568 CSeq: 1 11569 User-Agent: PhonyClient/1.2 11571 S->C: RTSP/2.0 200 OK 11572 CSeq: 1 11573 Content-base: rtsp://foo.example.com/test.wav/ 11574 Content-type: application/sdp 11575 Content-length: 163 11576 Server: PhonyServer/1.0 11577 Date: Thu, 23 Jan 1997 15:35:06 GMT 11578 Expires: 23 Jan 1997 17:00:00 GMT 11580 v=0 11581 o=- 872653257 872653257 IN IP4 192.0.2.5 11582 s=mu-law wave file 11583 i=audio test 11584 c=IN IP4 0.0.0.0 11585 t=0 0 11586 a=control: * 11587 m=audio 0 RTP/AVP 0 11588 a=control:streamid=0 11590 C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 11591 Transport: RTP/AVP/UDP;unicast; 11592 dest_addr=":6970"/":6971";mode="PLAY" 11593 CSeq: 2 11594 User-Agent: PhonyClient/1.2 11595 Accept-Ranges: npt, smpte, clock 11597 S->C: RTSP/2.0 200 OK 11598 Transport: RTP/AVP/UDP;unicast; 11599 dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; 11600 src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; 11601 mode="PLAY";ssrc=EAB98712 11602 CSeq: 2 11603 Session: 2034820394 11604 Expires: 23 Jan 1997 16:00:00 GMT 11605 Server: PhonyServer/1.0 11606 Date: 23 Jan 1997 15:35:07 GMT 11607 Accept-Ranges: npt 11608 Media-Properties: Random-Acces=0.5, Immutable, Unlimited 11610 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 11611 CSeq: 3 11612 User-Agent: PhonyClient/1.2 11613 Session: 2034820394 11615 S->C: RTSP/2.0 200 OK 11616 CSeq: 3 11617 Server: PhonyServer/1.0 11618 Date: 23 Jan 1997 15:35:08 GMT 11619 Session: 2034820394 11620 Range: npt=0-600 11621 Seek-Style: RAP 11622 RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" 11623 ssrc=0D12F123:seq=981888;rtptime=3781123 11625 Note the different URI in the SETUP command, and then the switch back 11626 to the aggregate URI in the PLAY command. This makes complete sense 11627 when there are multiple streams with aggregate control, but is less 11628 than intuitive in the special case where the number of streams is 11629 one. However, the server has declared the aggregated control URI in 11630 the SDP and therefore this is legal. 11632 In this case, it is also required that servers accept implementations 11633 that use the non-aggregated interpretation and use the individual 11634 media URI, like this: 11636 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 11637 CSeq: 3 11638 User-Agent: PhonyClient/1.2 11639 Session: 2034820394 11641 A.6. Live Media Presentation Using Multicast 11643 The media server M chooses the multicast address and port. Here, it 11644 is assumed that the web server only contains a pointer to the full 11645 description, while the media server M maintains the full description. 11647 C->W: GET /sessions.html HTTP/1.1 11648 Host: www.example.com 11650 W->C: HTTP/1.1 200 OK 11651 Content-Type: text/html 11653 11654 ... 11655 11656 Streamed Live Music performance 11657 ... 11658 11660 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 11661 CSeq: 1 11662 Supported: play.basic, play.scale 11663 User-Agent: PhonyClient/1.2 11665 M->C: RTSP/2.0 200 OK 11666 CSeq: 1 11667 Content-Type: application/sdp 11668 Content-Length: 183 11669 Server: PhonyServer/1.0 11670 Date: Thu, 23 Jan 1997 15:35:06 GMT 11671 Supported: play.basic 11673 v=0 11674 o=- 2890844526 2890842807 IN IP4 192.0.2.5 11675 s=RTSP Session 11676 t=0 0 11677 m=audio 3456 RTP/AVP 0 11678 c=IN IP4 233.252.0.54/16 11679 a=control: rtsp://live.example.com/concert/audio 11680 a=range:npt=0- 11682 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 11683 CSeq: 2 11684 Transport: RTP/AVP;multicast; 11685 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11686 Accept-Ranges: npt, smpte, clock 11687 User-Agent: PhonyClient/1.2 11689 M->C: RTSP/2.0 200 OK 11690 CSeq: 2 11691 Server: PhonyServer/1.0 11692 Date: Thu, 23 Jan 1997 15:35:06 GMT 11693 Transport: RTP/AVP;multicast; 11694 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11695 ;ssrc=4D12AB92/0DF876A3 11696 Session: 0456804596 11697 Accept-Ranges: npt, clock 11698 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 11700 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 11701 CSeq: 3 11702 Session: 0456804596 11703 User-Agent: PhonyClient/1.2 11705 M->C: RTSP/2.0 200 OK 11706 CSeq: 3 11707 Server: PhonyServer/1.0 11708 Date: 23 Jan 1997 15:35:07 GMT 11709 Session: 0456804596 11710 Seek-Style: Next 11711 Range:npt=1256- 11712 RTP-Info: url="rtsp://live.example.com/concert/audio" 11713 ssrc=0D12F123:seq=1473; rtptime=80000 11715 A.7. Capability Negotiation 11717 This example illustrates how the client and server determine their 11718 capability to support a special feature, in this case "play.scale". 11719 The server, through the clients request and the included Supported 11720 header, learns the client supports RTSP 2.0, and also supports the 11721 playback time scaling feature of RTSP. The server's response 11722 contains the following feature related information to the client; it 11723 supports the basic media delivery functions (play.basic), the 11724 extended functionality of time scaling of content (play.scale), and 11725 one "example.com" proprietary feature (com.example.flight). The 11726 client also learns the methods supported (Public header) by the 11727 server for the indicated resource. 11729 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 11730 CSeq: 1 11731 Supported: play.basic, play.scale 11732 User-Agent: PhonyClient/1.2 11734 S->C: RTSP/2.0 200 OK 11735 CSeq: 1 11736 Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER 11737 Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE 11738 Server: PhonyServer/2.0 11739 Supported: play.basic, play.scale, com.example.flight 11741 When the client sends its SETUP request it tells the server that it 11742 requires support of the play.scale feature for this session by 11743 including the Require header. 11745 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 11746 CSeq: 3 11747 User-Agent: PhonyClient/1.2 11748 Transport: RTP/AVP/UDP;unicast; 11749 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", 11750 RTP/AVP/TCP;unicast;interleaved=0-1 11751 Require: play.scale 11752 Accept-Ranges: npt, smpte, clock 11753 User-Agent: PhonyClient/1.2 11755 S->C: RTSP/2.0 200 OK 11756 CSeq: 3 11757 Session: 12345678 11758 Transport: RTP/AVP/UDP;unicast; 11759 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11760 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11761 Server: PhonyServer/2.0 11762 Accept-Ranges: npt, smpte 11763 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11765 Appendix B. RTSP Protocol State Machine 11767 The RTSP session state machine describes the behavior of the protocol 11768 from RTSP session initialization through RTSP session termination. 11769 It is probably easiest to think of this as the server's state and 11770 then view the the client as needing to track what it believes the 11771 server's state will be based on sent or received RTSP messages. Thus 11772 in most cases the state tables below can be read as: If the client 11773 does X, and assuming it fulfills any pre-requisite(s), the (server) 11774 state will move to the new state and the indicated response will 11775 returned. However, there are also server to client notifications or 11776 requests, where the action describes what notification or request 11777 will occur, its requisites and what new state will result after the 11778 server has received the response, as well as describing the client's 11779 response to the action. 11781 The State machine is defined on a per session basis which is uniquely 11782 identified by the RTSP session identifier. The session may contain 11783 one or more media streams depending on state. If a single media 11784 stream is part of the session it is in non-aggregated control. If 11785 two or more is part of the session it is in aggregated control. 11787 The below state machine is an informative description of the 11788 protocols behavior. In case of ambiguity with the earlier parts of 11789 this specification, the description in the earlier parts take 11790 precedence. 11792 B.1. States 11794 The state machine contains three states, described below. For each 11795 state there exists a table which shows which requests and events are 11796 allowed and whether they will result in a state change. 11798 Init: Initial state no session exists. 11800 Ready: Session is ready to start playing. 11802 Play: Session is playing, i.e., sending media stream data in the 11803 direction S->C. 11805 B.2. State variables 11807 This representation of the state machine needs more than its state to 11808 work. A small number of variables are also needed and they are 11809 explained below. 11811 NRM: The number of media streams part of this session. 11813 RP: Resume point, the point in the presentation time line at which 11814 a request to continue playing will resume from. A time format 11815 for the variable is not mandated. 11817 B.3. Abbreviations 11819 To make the state tables more compact a number of abbreviations are 11820 used, which are explained below. 11822 IFI: IF Implemented. 11824 md: Media 11826 PP: Pause Point, the point in the presentation time line at which 11827 the presentation was paused. 11829 Prs: Presentation, the complete multimedia presentation. 11831 RedP: Redirect Point, the point in the presentation time line at 11832 which a REDIRECT was specified to occur. 11834 SES: Session. 11836 B.4. State Tables 11838 This section contains a table for each state. The table contains all 11839 the requests and events that this state is allowed to act on. The 11840 events which are method names are, unless noted, requests with the 11841 given method in the direction client to server (C->S). In some cases 11842 there exist one or more requisite. The response column tells what 11843 type of response actions should be performed. Possible actions that 11844 are requested for an event include: response codes, e.g., 200, 11845 headers that need to be included in the response, setting of state 11846 variables, or setting of other session related parameters. The new 11847 state column tells which state the state machine changes to. 11849 The response to a valid request meeting the requisites is normally a 11850 2xx (SUCCESS) unless otherwise noted in the response column. The 11851 exceptions need to be given a response according to the response 11852 column. If the request does not meet the requisite, is erroneous or 11853 some other type of error occurs, the appropriate response code is to 11854 be sent. If the response code is a 4xx the session state is 11855 unchanged. A response code of 3rr will result in that the session is 11856 ended and its state is changed to Init. A response code of 304 11857 results in no state change. However, there are restrictions to when 11858 a 3rr response may be used. A 5xx response does not result in any 11859 change of the session state, except if the error is not possible to 11860 recover from. A unrecoverable error results in the ending of the 11861 session. As it in the general case can't be determined if it was a 11862 unrecoverable error or not the client will be required to test. In 11863 the case that the next request after a 5xx is responded with 454 11864 (Session Not Found) the client knows that the session has ended. For 11865 any request message that cannot be responded to within the time 11866 defined in Section 10.4, a 100 response must be sent. 11868 The server will timeout the session after the period of time 11869 specified in the SETUP response, if no activity from the client is 11870 detected. Therefore there exists a timeout event for all states 11871 except Init. 11873 In the case that NRM = 1 the presentation URI is equal to the media 11874 URI or a specified presentation URI. For NRM > 1 the presentation 11875 URI needs to be other than any of the medias that are part of the 11876 session. This applies to all states. 11878 +---------------+-----------------+---------------------------------+ 11879 | Event | Prerequisite | Response | 11880 +---------------+-----------------+---------------------------------+ 11881 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 11882 | | | | 11883 | DESCRIBE | | 200, Session description | 11884 | | | | 11885 | OPTIONS | Session ID | 200, Reset session timeout | 11886 | | | timer | 11887 | | | | 11888 | OPTIONS | | 200 | 11889 | | | | 11890 | SET_PARAMETER | Valid parameter | 200, change value of parameter | 11891 | | | | 11892 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 11893 +---------------+-----------------+---------------------------------+ 11895 Table 13: None state-machine changing events 11897 The methods in Table 13 do not have any effect on the state machine 11898 or the state variables. However, some methods do change other 11899 session related parameters, for example SET_PARAMETER which will set 11900 the parameter(s) specified in its body. Also all of these methods 11901 that allow Session header will also update the keep-alive timer for 11902 the session. 11904 +------------------+----------------+-----------+-------------------+ 11905 | Action | Requisite | New State | Response | 11906 +------------------+----------------+-----------+-------------------+ 11907 | SETUP | | Ready | NRM=1, RP=0.0 | 11908 | | | | | 11909 | SETUP | Needs Redirect | Init | 3rr Redirect | 11910 | | | | | 11911 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 11912 +------------------+----------------+-----------+-------------------+ 11914 Table 14: State: Init 11916 The initial state of the state machine, see Table 14 can only be left 11917 by processing a correct SETUP request. As seen in the table the two 11918 state variables are also set by a correct request. This table also 11919 shows that a correct SETUP can in some cases be redirected to another 11920 URI and/or server by a 3rr response. 11922 +-------------+------------------------+---------+------------------+ 11923 | Action | Requisite | New | Response | 11924 | | | State | | 11925 +-------------+------------------------+---------+------------------+ 11926 | SETUP | New URI | Ready | NRM +=1 | 11927 | | | | | 11928 | SETUP | URI Setup prior | Ready | Change transport | 11929 | | | | param | 11930 | | | | | 11931 | TEARDOWN | Prs URI, | Init | No session hdr, | 11932 | | | | NRM = 0 | 11933 | | | | | 11934 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 11935 | | | | NRM = 0 | 11936 | | | | | 11937 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | 11938 | | | | -= 1 | 11939 | | | | | 11940 | PLAY | Prs URI, No range | Play | Play from RP | 11941 | | | | | 11942 | PLAY | Prs URI, Range | Play | According to | 11943 | | | | range | 11944 | | | | | 11945 | PLAY | md URI, NRM=1, Range | Play | According to | 11946 | | | | range | 11947 | | | | | 11948 | PLAY | md URI, NRM=1 | Play | Play from RP | 11949 | | | | | 11950 | PAUSE | Prs URI | Ready | Return PP | 11951 | | | | | 11952 | SC:REDIRECT | Terminate-Reason | Ready | Set RedP | 11953 | | | | | 11954 | SC:REDIRECT | No Terminate-Reason | Init | Session is | 11955 | | time parameter | | removed | 11956 | | | | | 11957 | Timeout | | Init | | 11958 | | | | | 11959 | RedP | | Init | TEARDOWN of | 11960 | reached | | | session | 11961 +-------------+------------------------+---------+------------------+ 11963 Table 15: State: Ready 11965 In the Ready state, see Table 15, some of the actions are depending 11966 on the number of media streams (NRM) in the session, i.e., aggregated 11967 or non-aggregated control. A SETUP request in the Ready state can 11968 either add one more media stream to the session or, if the media 11969 stream (same URI) already is part of the session, change the 11970 transport parameters. TEARDOWN is depending on both the Request-URI 11971 and the number of media streams within the session. If the Request- 11972 URI is the presentations URI the whole session is torn down. If a 11973 media URI is used in the TEARDOWN request and more than one media 11974 exists in the session, the session will remain and a session header 11975 is returned in the response. If only a single media stream remains 11976 in the session when performing a TEARDOWN with a media URI the 11977 session is removed. The number of media streams remaining after 11978 tearing down a media stream determines the new state. 11980 +----------------+-----------------------+--------+-----------------+ 11981 | Action | Requisite | New | Response | 11982 | | | State | | 11983 +----------------+-----------------------+--------+-----------------+ 11984 | PAUSE | Prs URI | Ready | Set RP to | 11985 | | | | present point | 11986 | | | | | 11987 | End of media | All media | Play | Set RP = End of | 11988 | | | | media | 11989 | | | | | 11990 | End of range | | Play | Set RP = End of | 11991 | | | | range | 11992 | | | | | 11993 | PLAY | Prs URI, No range | Play | Play from | 11994 | | | | present point | 11995 | | | | | 11996 | PLAY | Prs URI, Range | Play | According to | 11997 | | | | range | 11998 | | | | | 11999 | SC:PLAY_NOTIFY | | Play | 200 | 12000 | | | | | 12001 | SETUP | New URI | Play | 455 | 12002 | | | | | 12003 | SETUP | Setuped URI | Play | 455 | 12004 | | | | | 12005 | SETUP | Setuped URI, IFI | Play | Change | 12006 | | | | transport | 12007 | | | | param. | 12008 | | | | | 12009 | TEARDOWN | Prs URI | Init | No session hdr | 12010 | | | | | 12011 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 12012 | | | | NRM=0 | 12013 | | | | | 12014 | TEARDOWN | md URI | Play | 455 | 12015 | | | | | 12016 | SC:REDIRECT | Terminate Reason with | Play | Set RedP | 12017 | | Time parameter | | | 12018 | | | | | 12019 | SC:REDIRECT | | Init | Session is | 12020 | | | | removed | 12021 | | | | | 12022 | RedP reached | | Init | TEARDOWN of | 12023 | | | | session | 12024 | | | | | 12025 | Timeout | | Init | Stop Media | 12026 | | | | playout | 12027 +----------------+-----------------------+--------+-----------------+ 12028 Table 16: State: Play 12030 The Play state table, see Table 16, contains a number of requests 12031 that need a presentation URI (labeled as Prs URI) to work on (i.e., 12032 the presentation URI has to be used as the Request-URI). This is due 12033 to the exclusion of non-aggregated stream control in sessions with 12034 more than one media stream. 12036 To avoid inconsistencies between the client and server, automatic 12037 state transitions are avoided. This can be seen at for example "End 12038 of media" event when all media has finished playing, the session 12039 still remains in Play state. An explicit PAUSE request needs to be 12040 sent to change the state to Ready. It may appear that there exist 12041 automatic transitions in "RedP reached" and "PP reached". However, 12042 they are requested and acknowledged before they take place. The time 12043 at which the transition will happen is known by looking at the range 12044 header. If the client sends a request close in time to these 12045 transitions it needs to be prepared for receiving error messages, as 12046 the state may or may not have changed. 12048 Appendix C. Media Transport Alternatives 12050 This section defines how certain combinations of protocols, profiles 12051 and lower transports are used. This includes the usage of the 12052 Transport header's source and destination address parameters 12053 "src_addr" and "dest_addr". 12055 C.1. RTP 12057 This section defines the interaction of RTSP with respect to the RTP 12058 protocol [RFC3550]. It also defines any necessary media transport 12059 signaling with regards to RTP. 12061 The available RTP profiles and lower layer transports are described 12062 below along with rules on signaling the available combinations. 12064 C.1.1. AVP 12066 The usage of the "RTP Profile for Audio and Video Conferences with 12067 Minimal Control" [RFC3551] when using RTP for media transport over 12068 different lower layer transport protocols is defined below in regards 12069 to RTSP. 12071 One such case is defined within this document: the use of embedded 12072 (interleaved) binary data as defined in Section 14. The usage of 12073 this method is indicated by including the "interleaved" parameter. 12075 When using embedded binary data the "src_addr" and "dest_addr" MUST 12076 NOT be used. This addressing and multiplexing is used as defined 12077 with use of channel numbers and the interleaved parameter. 12079 C.1.2. AVP/UDP 12081 This part describes sending of RTP [RFC3550] over lower transport 12082 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 12083 and Video Conferences with Minimal Control" defined in RFC 3551 12084 [RFC3551]. Implementations of RTP/AVP/UDP MUST implement RTCP 12085 (Appendix C.1.6). This profile requires one or two uni- or bi- 12086 directional UDP flows per media stream. The first UDP flow is for 12087 RTP and the second is for RTCP. Multiplexing of RTP and RTCP 12088 (Appendix C.1.6.4) MAY be used, in which case a single UDP flow is 12089 used for both parts. Embedding of RTP data with the RTSP messages, 12090 in accordance with Section 14, SHOULD NOT be performed when RTSP 12091 messages are transported over unreliable transport protocols, like 12092 UDP [RFC0768]. 12094 The RTP/UDP and RTCP/UDP flows can be established using the Transport 12095 header's "src_addr", and "dest_addr" parameters. 12097 In RTSP PLAY mode, the transmission of RTP packets from client to 12098 server is unspecified. The behavior in regards to such RTP packets 12099 MAY be defined in future. 12101 The "src_addr" and "dest_addr" parameters are used in the following 12102 way for media delivery and playback mode, i.e., Mode=PLAY: 12104 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 12105 2 address specifications. Note that two address specifications 12106 MAY be provided even if RTP and RTCP multiplexing is negotiated. 12108 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 12109 contain either: 12111 * both an address and a port number, or 12113 * a port number without an address. 12115 o The first address specification given in either of the parameters 12116 applies to the RTP stream. The second specification if present 12117 applies to the RTCP stream, unless in case RTP and RTCP 12118 multiplexing is negotiated where both RTP and RTCP will use the 12119 first specification. 12121 o The RTP/UDP packets from the server to the client MUST be sent to 12122 the address and port given by the first address specification of 12123 the "dest_addr" parameter. 12125 o The RTCP/UDP packets from the server to the client MUST be sent to 12126 the address and port given by the second address specification of 12127 the "dest_addr" parameter, unless RTP and RTCP multiplexing has 12128 been negotiated, in which case RTCP MUST be sent to the first 12129 address specification. If no second pair is specified and RTP and 12130 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12132 o The RTCP/UDP packets from the client to the server MUST be sent to 12133 the address and port given by the second address specification of 12134 the "src_addr" parameter, unless RTP and RTCP multiplexing has 12135 been negotiated, in which case RTCP MUST be sent to the first 12136 address specification. If no second pair is specified and RTP and 12137 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12139 o The RTP/UDP packets from the client to the server MUST be sent to 12140 the address and port given by the first address specification of 12141 the "src_addr" parameter. 12143 o RTP and RTCP Packets SHOULD be sent from the corresponding 12144 receiver port, i.e., RTCP packets from the server should be sent 12145 from the "src_addr" parameters second address port pair, unless 12146 RTP and RTCP multiplexing has been negotiated in which case the 12147 first address port pair is used. 12149 C.1.3. AVPF/UDP 12151 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 12152 AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. 12153 All that is defined for AVP MUST also apply for AVPF. 12155 The usage of AVPF is indicated by the media initialization protocol 12156 used. In the case of SDP it is indicated by media lines (m=) 12157 containing the profile RTP/AVPF. That SDP MAY also contain further 12158 AVPF related SDP attributes configuring the AVPF session regarding 12159 reporting interval and feedback messages to be used [RFC4585]. This 12160 configuration MUST be followed. 12162 C.1.4. SAVP/UDP 12164 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 12165 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 12166 using RTP. All that is defined for AVP MUST also apply for SAVP. 12168 The usage of SRTP requires that a security context is established. 12169 The default key-management unless otherwise signalled SHALL be MIKEY 12170 in RSA-R mode as defined in Appendix C.1.4.1, and not according to 12171 the procedure defined in "Key Management Extensions for Session 12172 Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" 12173 [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY 12174 message in SDP, thus both requiring the usage of the DESCRIBE method 12175 and forcing the server to keep state for clients performing DESCRIBE 12176 in anticipation that they might require key management. 12178 MIKEY is selected as default method for establishing SRTP 12179 cryptographic context within an RTSP session as it can be embedded in 12180 the RTSP messages, while still ensuring confidentiality of content of 12181 the keying material, even when using hop-by-hop TLS security for the 12182 RTSP messages. This method does also support pipelining of the RTSP 12183 messages. 12185 C.1.4.1. MIKEY Key Establishment 12187 This method for using MIKEY [RFC3830] to establish the SRTP 12188 cryptographic context is initiated in the client's SETUP request, and 12189 the server's response to the SETUP carries the MIKEY response. This 12190 ensures that the crypto context establishment happens simultaneously 12191 with the establishment of the media stream being protected. By using 12192 MIKEY's RSA-R mode [RFC4738] the client can be the initiator and 12193 still allow the server to set the parameters in accordance with the 12194 actual media stream. 12196 The SRTP cryptographic context establishment is done according to the 12197 following process: 12199 1. The client determines that SAVP or SAVPF shall be used from 12200 media description format, e.g., SDP. If no other key management 12201 method is explicitly signalled, then MIKEY SHALL be used as 12202 defined herein. The use of SRTP with RTSP is only defined with 12203 MIKEY with keys established as defined in this Section. Future 12204 documents may define how an RTSP implementation treats SDP that 12205 indicates some other key mechanism to be used. The need for 12206 such specification include [RFC4567] that is not defined for use 12207 in RTSP 2.0 within this document. 12209 2. The client SHALL establish a TLS connection for RTSP messages, 12210 directly or hop by hop with the server. If hop-by-hop TLS 12211 security is used, the User method SHALL be indicated in the 12212 Accept-Credentials header. We do note that using hop-by-hop 12213 does allow the proxy to insert itself as a man in the middle 12214 also in the MIKEY exchange by providing one of its certificates, 12215 rather than the server's in the Connection-Credentials header. 12216 The client SHALL therefore validate the server certificate. 12218 3. The client retrieves the server's certificate from a direct TLS 12219 connection, or if hop by hop from Connection-Credentials header. 12220 The client then checks that the server certificate is valid and 12221 belongs to the server. 12223 4. The client forms the MIKEY Initiator message using RSA-R mode in 12224 unicast mode as specified in [RFC4738]. The client SHOULD use 12225 the same certificate for TLS and in MIKEY to enable the server 12226 to bind the two together. The client's certificate SHALL be 12227 included in the MIKEY message. The client SHALL indicate its 12228 SRTP capabilities in the message. 12230 5. The MIKEY message from the previous step is base64 [RFC4648] 12231 encoded and becomes the value of the MIKEY parameter that is 12232 included in the transport specification(s) that specifies a SRTP 12233 based profile (SAVP, SAVPF) in the SETUP request. 12235 6. Any proxy encountering the MIKEY parameter SHALL forward it 12236 without modification. A proxy requiring to understand transport 12237 specification which doesn't support SAVP/SAVPF with MIKEY will 12238 discard the whole transport specification. Most types of 12239 proxies can easily support SAVP and SAVPF with MIKEY. If 12240 possible bypassing the proxy should be tried. 12242 7. The server upon receiving the SETUP request, will need to decide 12243 upon the transport specification to use, if multiple are 12244 included by the client. In the determination of which transport 12245 specifications that are supported and preferred, the server 12246 SHOULD decode the MIKEY message to take the embedded SRTP 12247 parameters into account. If all transport specs require SRTP 12248 but no MIKEY parameter or other supported keying method is 12249 included, the server SHALL respond with 403. 12251 8. Upon generating a response the following outcomes can occur: 12253 * A transport spec not using SRTP and MIKEY is selected. Thus 12254 the response will not contain any MIKEY parameter. 12256 * A transport spec using SRTP and MIKEY is selected but an 12257 error is encountered in the MIKEY processing. In that case 12258 an RTSP error response code of 466 "Key Management Error" 12259 SHALL be used. A MIKEY message describing the error MAY be 12260 included. 12262 * A transport spec using SRTP and MIKEY is selected and a MIKEY 12263 response message can be created. The server SHOULD use the 12264 same certificate for TLS and in MIKEY to enable client to 12265 bind the two together. If a different certificate is used it 12266 SHALL be included in the MIKEY message. It is RECOMMENDED 12267 that the envelope key cache type is set to 'Cache' and that a 12268 single envelope key is reused for all MIKEY messages to the 12269 client. That message is included in the MIKEY parameter part 12270 of the single selected transport specification in the SETUP 12271 response. The server will set the SRTP parameters as 12272 preferred for this media stream within the supported range by 12273 the client. 12275 9. The server transmits the SETUP response back to the client. 12277 10. The client receives the SETUP response and if the response code 12278 indicates a successful request it decodes the MIKEY message and 12279 establishes the SRTP cryptographic context from the parameters 12280 in the MIKEY response. 12282 In the above method the client's certificate may be self-signed in 12283 cases where the client's identity is not necessary to authenticate 12284 and the security goal is only to ensure that the RTSP signaling 12285 client is the same as the one receiving the SRTP security context. 12287 C.1.5. SAVPF/UDP 12289 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 12290 (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in 12291 RTSP sessions using RTP. All that is defined for AVPF MUST also 12292 apply for SAVPF. 12294 The usage of SRTP requires that a cryptographic context is 12295 established. The default mechanism for establishing that security 12296 association is to use MIKEY[RFC3830] with RTSP as defined in 12297 Appendix C.1.4.1. 12299 C.1.6. RTCP usage with RTSP 12301 RTCP has several usages when RTP is used for media transport as 12302 explained below. Due to that RTCP MUST be supported if an RTSP agent 12303 handles RTP. 12305 C.1.6.1. Media synchronization 12307 RTCP provides media synchronization and clock drift compensation. 12308 The initial media synchronization is available from RTP-Info header. 12309 However, to be able to handle any clock drift between the media 12310 streams, RTCP is needed. 12312 C.1.6.2. RTSP Session keep-alive 12314 RTCP traffic from the RTSP client to the RTSP server MUST function as 12315 keep-alive. This requires an RTSP server supporting RTP to use the 12316 received RTCP packets as indications that the client desires the 12317 related RTSP session to be kept alive. 12319 C.1.6.3. Bit-rate adaption 12321 RTCP Receiver reports and any additional feedback from the client 12322 MUST be used to adapt the bit-rate used over the transport for all 12323 cases when RTP is sent over UDP. An RTP sender without reserved 12324 resources MUST NOT use more than its fair share of the available 12325 resources. This can be determined by comparing on short to medium 12326 term (some seconds) the used bit-rate and adapt it so that the RTP 12327 sender sends at a bit-rate comparable to what a TCP sender would 12328 achieve on average over the same path. 12330 To ensure that the implementation's adaptation mechanism has a well 12331 defined outer envelope, all implementations using a non-congestion 12332 controlled unicast transport protocol, like UDP, MUST implement 12333 Multimedia Congestion Control: Circuit Breakers for Unicast RTP 12334 Sessions [I-D.ietf-avtcore-rtp-circuit-breakers]. 12336 C.1.6.4. RTP and RTCP Multiplexing 12338 RTSP can be used to negotiate the usage of RTP and RTCP multiplexing 12339 as described in [RFC5761]. This allows servers and client to reduce 12340 the amount of resources required for the session by only requiring 12341 one underlying transport stream per media stream instead of two when 12342 using RTP and RTCP. This lessens the server port consumption and 12343 also the necessary state and keep-alive work when operating across 12344 Network and Address Translators [RFC2663]. 12346 Content must be prepared with some consideration for RTP and RTCP 12347 multiplexing, mainly ensuring that the RTP payload types used do not 12348 collide with the ones used for RTCP packet types. This option likely 12349 needs explicit support from the content unless the RTP payload types 12350 can be remapped by the server and that is correctly reflected in the 12351 session description. Beyond that support of this feature should come 12352 at little cost and much gain. 12354 It is recommended that if the content and server support RTP and RTCP 12355 multiplexing that this is indicated in the session description, for 12356 example using the SDP attribute "a=rtcp-mux". If the SDP message 12357 contains the a=rtcp-mux attribute for a media stream, the server MUST 12358 support RTP and RTCP multiplexing. If indicated or otherwise desired 12359 by the client it can include the Transport parameter "RTCP-mux" in 12360 any transport specification where it desires to use RTCP-mux. The 12361 server will indicate if it supports RTCP-mux. Servers and Clients 12362 SHOULD support RTP and RTCP multiplexing. 12364 For capability exchange, an RTSP feature tag for RTP and RTCP 12365 multiplexing is defined: "setup.rtp.rtcp.mux". 12367 To minimize the risk of negotiation failure while using RTP and RTCP 12368 multiplexing some recommendations are here provided. If the session 12369 description includes explicit indication of support (a=rtcp-mux in 12370 SDP), then a RTSP agent can safely create a SETUP request with a 12371 transport specification with only a single dest_addr parameter 12372 address specification. If no such explicit indication is provided, 12373 then even if the feature tag "setup.rtp.rtcp.mux" is provided in a 12374 Supported header by the RTSP server or the feature tag included in 12375 the Required header in the SETUP request, the media resource may not 12376 support RTP and RTCP multiplexing. Thus, to maximize the probability 12377 of successful negotiation the RTSP agent is recommended to include 12378 two dest_addr parameter address specifications in the first or first 12379 set (if pipelining is used) of SETUP request(s) for any media 12380 resource aggregate. That way the RTSP server can either accept RTP 12381 and RTCP multiplexing and only use the first address specification, 12382 and if not use both specifications. The RTSP agent after having 12383 received the response for a successful negotiation of the usage of 12384 RTP and RTCP multiplexing, can then release the resources associated 12385 with the second address specification. 12387 C.2. RTP over TCP 12389 Transport of RTP over TCP can be done in two ways: over independent 12390 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 12391 connection. In both cases the protocol MUST be "rtp" and the lower 12392 layer MUST be TCP. The profile may be any of the above specified 12393 ones; AVP, AVPF, SAVP or SAVPF. 12395 C.2.1. Interleaved RTP over TCP 12397 The use of embedded (interleaved) binary data transported on the RTSP 12398 connection is possible as specified in Section 14. When using this 12399 declared combination of interleaved binary data the RTSP messages 12400 MUST be transported over TCP. TLS may or may not be used. If TLS is 12401 used both RTSP messages and the binary data will be protected by TLS. 12403 One should, however, consider that this will result in all media 12404 streams go through any proxy. Using independent TCP connections can 12405 avoid that issue. 12407 C.2.2. RTP over independent TCP 12409 In this Appendix, we describe the sending of RTP [RFC3550] over lower 12410 transport layer TCP [RFC0793] according to "Framing Real-time 12411 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 12412 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 12413 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 12414 with RTSP. 12416 A client codes the support of RTP over independent TCP by specifying 12417 an RTP/AVP/TCP transport option without an interleaved parameter in 12418 the Transport line of a SETUP request. This transport option MUST 12419 include the "unicast" parameter. 12421 If the client wishes to use RTP with RTCP, two address specifications 12422 needs to be included in the dest_addr parameter. If the client 12423 wishes to use RTP without RTCP, one address specification is included 12424 in the dest_addr parameter. If the client wishes to multiplex RTP 12425 and RTCP on a single transport flow (see Appendix C.1.6.4), one or 12426 two address specifications are included in the dest_addr parameter in 12427 addition to the RTCP-mux transport parameter. Two address 12428 specifications are allowed to allow successful negotiation when 12429 server or content can't support RTP and RTCP multiplexing. Ordering 12430 rules of dest_addr ports follow the rules for RTP/AVP/UDP. 12432 If the client wishes to play the active role in initiating the TCP 12433 connection, it MAY set the "setup" parameter (See Section 18.54) on 12434 the Transport line to be "active", or it MAY omit the setup 12435 parameter, as active is the default. If the client signals the 12436 active role, the ports in the address specifications in the dest_addr 12437 parameter MUST be set to 9 (the discard port). 12439 If the client wishes to play the passive role in TCP connection 12440 initiation, it MUST set the "setup" parameter on the Transport line 12441 to be "passive". If the client is able to assume the active or the 12442 passive role, it MUST set the "setup" parameter on the Transport line 12443 to be "actpass". In either case, the dest_addr parameter's address 12444 specification port value for RTP MUST be set to the TCP port number 12445 on which the client is expecting to receive the TCP connection for 12446 RTP, and the dest_addr's address specification port value for RTCP 12447 MUST be set to the TCP port number on which the client is expecting 12448 to receive the TCP connection for RTCP. In the case that the client 12449 wishes to multiplex RTP and RTCP on a single transport flow, the 12450 RTCP-mux parameter is included and one or two dest_addr parameter 12451 address specifications are included, as mentioned earlier in this 12452 section. 12454 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 12455 server decides to accept this requested option, the 2xx reply MUST 12456 contain a Transport option that specifies RTP/AVP/TCP (without using 12457 the interleaved parameter, and with using the unicast parameter). 12458 The dest_addr parameter value MUST be echoed from the parameter value 12459 in the client request unless the destination address (only port) was 12460 not provided in which case the server MAY include the source address 12461 of the RTSP TCP connection with the port number unchanged. 12463 In addition, the server reply MUST set the setup parameter on the 12464 Transport line, to indicate the role the server will play in the 12465 connection setup. Permissible values are "active" (if a client set 12466 "setup" to "passive" or "actpass") and "passive" (if a client set 12467 "setup" to "active" or "actpass"). 12469 If a server sets "setup" to "passive", the "src_addr" in the reply 12470 MUST indicate the ports the server is willing to receive an TCP 12471 connection for RTP and (if the client requested an TCP connection for 12472 RTCP by specifying two dest_addr address specifications) an TCP/RTCP 12473 connection. If a server sets "setup" to "active", the ports 12474 specified in "src_addr" address specifications MUST be set to 9. The 12475 server MAY use the "ssrc" parameter, following the guidance in 12476 Section 18.54. The server sets only one address specification in the 12477 case that the client has indicated only a single address 12478 specification or in case RTP and RTCP multiplexing was requested and 12479 accepted by server. Port ordering for src_addr follows the rules for 12480 RTP/AVP/UDP. 12482 Servers MUST support taking the passive role and MAY support taking 12483 the active role. Servers with a public IP address take the passive 12484 role, thus enabling clients behind NATs and Firewalls a better chance 12485 of successful connect to the server by actively connecting outwards. 12486 Therefore the clients are RECOMMENDED to take the active role. 12488 After sending (receiving) a 2xx reply for a SETUP method for a non- 12489 interleaved RTP/AVP/TCP media stream, the active party SHOULD 12490 initiate the TCP connection as soon as possible. The client MUST NOT 12491 send a PLAY request prior to the establishment of all the TCP 12492 connections negotiated using SETUP for the session. In case the 12493 server receives a PLAY request in a session that has not yet 12494 established all the TCP connections, it MUST respond using the 464 12495 "Data Transport Not Ready Yet" (Section 17.4.29) error code. 12497 Once the PLAY request for a media resource transported over non- 12498 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 12499 client over the RTP TCP connection, and RTCP packets flow 12500 bidirectionally over the RTCP TCP connection. Unless RTP and RTCP 12501 multiplexing has been negotiated in which case RTP and RTCP will flow 12502 over a common TCP connection. As in the RTP/UDP case, client to 12503 server traffic on a RTP only TCP session is unspecified by this memo. 12504 The packets that travel on these connections MUST be framed using the 12505 protocol defined in [RFC4571], not by the framing defined for 12506 interleaving RTP over the RTSP connection defined in Section 14. 12508 A successful PAUSE request for a media being transported over RTP/ 12509 AVP/TCP pauses the flow of packets over the connections, without 12510 closing the connections. A successful TEARDOWN request signals that 12511 the TCP connections for RTP and RTCP are to be closed by the RTSP 12512 client as soon as possible. 12514 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 12515 ambiguous in the following way: does the client wish to open up new 12516 TCP connection for RTP or RTCP for the URI, or does the client wish 12517 to continue using the existing TCP connections? The client SHOULD 12518 use the "connection" parameter (defined in Section 18.54) on the 12519 Transport line to make its intention clear (by setting "connection" 12520 to "new" if new connections are needed, and by setting "connection" 12521 to "existing" if the existing connections are to be used). After a 12522 2xx reply for a SETUP request for a new connection, parties should 12523 close the pre-existing connections, after waiting a suitable period 12524 for any stray RTP or RTCP packets to arrive. 12526 The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that 12527 a security association is established. The default mechanism for 12528 establishing that security association is to use MIKEY[RFC3830] with 12529 RTSP as defined Appendix C.1.4.1. 12531 Below, we rewrite part of the example media on demand example shown 12532 in Appendix A.1 to use RTP/AVP/TCP non-interleaved: 12534 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 12535 CSeq: 1 12536 User-Agent: PhonyClient/1.2 12538 M->C: RTSP/2.0 200 OK 12539 CSeq: 1 12540 Server: PhonyServer/1.0 12541 Date: Thu, 23 Jan 1997 15:35:06 GMT 12542 Content-Type: application/sdp 12543 Content-Length: 227 12544 Content-Base: rtsp://example.com/twister.3gp/ 12545 Expires: 24 Jan 1997 15:35:06 GMT 12547 v=0 12548 o=- 2890844256 2890842807 IN IP4 198.51.100.34 12549 s=RTSP Session 12550 i=An Example of RTSP Session Usage 12551 e=adm@example.com 12552 c=IN IP4 0.0.0.0 12553 a=control: * 12554 a=range:npt=0-0:10:34.10 12555 t=0 0 12556 m=audio 0 RTP/AVP 0 12557 a=control: trackID=1 12559 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 12560 CSeq: 2 12561 User-Agent: PhonyClient/1.2 12562 Require: play.basic 12563 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 12564 setup=active;connection=new 12565 Accept-Ranges: npt, smpte, clock 12567 M->C: RTSP/2.0 200 OK 12568 CSeq: 2 12569 Server: PhonyServer/1.0 12570 Transport: RTP/AVP/TCP;unicast; 12571 dest_addr=":9"/":9"; 12572 src_addr="198.51.100.5:53478"/"198.51.100:54091"; 12573 setup=passive;connection=new;ssrc=93CB001E 12574 Session: 12345678 12575 Expires: 24 Jan 1997 15:35:12 GMT 12576 Date: 23 Jan 1997 15:35:12 GMT 12577 Accept-Ranges: npt 12578 Media-Properties: Random-Access=0.8, Immutable, Unlimited 12580 C->M: TCP Connection Establishment x2 12582 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 12583 CSeq: 4 12584 User-Agent: PhonyClient/1.2 12585 Range: npt=30- 12586 Session: 12345678 12588 M->C: RTSP/2.0 200 OK 12589 CSeq: 4 12590 Server: PhonyServer/1.0 12591 Date: 23 Jan 1997 15:35:14 GMT 12592 Session: 12345678 12593 Range: npt=30-623.10 12594 Seek-Style: First-Prior 12595 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" 12596 ssrc=4F312DD8:seq=54321;rtptime=2876889 12598 C.3. Handling Media Clock Time Jumps in the RTP Media Layer 12600 RTSP allows media clients to control selected, non-contiguous 12601 sections of media presentations, rendering those streams with an RTP 12602 media layer [RFC3550]. Two cases occur, the first is when a new PLAY 12603 request replaces an old ongoing request and the new request results 12604 in a jump in the media. This should produce in the RTP layer a 12605 continuous media stream. A client may also directly following a 12606 completed PLAY request perform a new PLAY request. This will result 12607 in some gap in the media layer. The below text will look into both 12608 cases. 12610 A PLAY request that replaces an ongoing request allows the media 12611 layer rendering the RTP stream without being affected by jumps in 12612 media clock time. The RTP timestamps for the new media range is set 12613 so that they become continuous with the previous media range in the 12614 previous request. The RTP sequence number for the first packet in 12615 the new range will be the next following the last packet in the 12616 previous range, i.e., monotonically increasing. The goal is to allow 12617 the media rendering layer to work without interruption or 12618 reconfiguration across the jumps in media clock. This should be 12619 possible in all cases of replaced PLAY requests for media that has 12620 random-access properties. In this case care is needed to align 12621 frames or similar media dependent structures. 12623 In cases where jumps in media clock time are a result of RTSP 12624 signaling operations arriving after a completed PLAY operation, the 12625 request timing will result in that media becomes non-continuous. The 12626 server becomes unable to send the media so that it arrives timely and 12627 still carry timestamps to make the media stream continuous. In these 12628 cases the server will produce RTP streams where there are gaps in the 12629 RTP timeline for the media. In such cases, if the media has frame 12630 structure, aligning the timestamp for the next frame with the 12631 previous structure reduces the burden to render this media. The gap 12632 should represent the time the server hasn't been serving media, e.g., 12633 the time between the end of the media stream or a PAUSE request and 12634 the new PLAY request. In these cases the RTP sequence number would 12635 normally be monotonically increasing across the gap. 12637 For RTSP sessions with media that lacks random access properties, 12638 such as live streams, any media clock jump is commonly the result of 12639 a correspondingly long pause of delivery. The RTP timestamp will 12640 have increased in direct proportion to the duration of the paused 12641 delivery. Note also that in this case the RTP sequence number should 12642 be the next packet number. If not, the RTCP packet loss reporting 12643 will indicate as loss all packets not received between the point of 12644 pausing and later resuming. This may trigger congestion avoidance 12645 mechanisms. An allowed exception from the above recommendation on 12646 monotonically increasing RTP sequence number is live media streams, 12647 likely being relayed. In this case, when the client resumes 12648 delivery, it will get the media that is currently being delivered to 12649 the server itself. For this type of basic delivery of live streams 12650 to multiple users over unicast, individual rewriting of RTP sequence 12651 numbers becomes quite a burden. For solutions that anyway caches 12652 media, timeshifts, etc, the rewriting should be a minor issue. 12654 The goal when handling jumps in media clock time is that the provided 12655 stream is continuous without gaps in RTP timestamp or sequence 12656 number. However, when delivery has been halted for some reason the 12657 RTP timestamp when resuming MUST represent the duration the delivery 12658 was halted. RTP sequence number MUST generally be the next number, 12659 i.e., monotonically increasing modulo 65536. For media resources 12660 with the properties Time-Progressing and Time-Duration=0.0 the server 12661 MAY create RTP media streams with RTP sequence number jumps in them 12662 due to the client first halting delivery and later resuming it (PAUSE 12663 and then later PLAY). However, servers utilizing this exception must 12664 take into consideration the resulting RTCP receiver reports that 12665 likely contain loss reports for all the packets part of the 12666 discontinuity. A client cannot rely on that a server will align when 12667 resuming playing even if it is RECOMMENDED. The RTP-Info header will 12668 provide information on how the server acts in each case. 12670 We cannot assume that the RTSP client can communicate with the RTP 12671 media agent, as the two may be independent processes. If the RTP 12672 timestamp shows the same gap as the NPT, the media agent will 12673 assume that there is a pause in the presentation. If the jump in 12674 NPT is large enough, the RTP timestamp may roll over and the media 12675 agent may believe later packets to be duplicates of packets just 12676 played out. Having the RTP timestamp jump will also affect the 12677 RTCP measurements based on this. 12679 As an example, assume an RTP timestamp frequency of 8000 Hz, a 12680 packetization interval of 100 ms and an initial sequence number and 12681 timestamp of zero. 12683 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12684 CSeq: 4 12685 Session: abcdefgh 12686 Range: npt=10-15 12687 User-Agent: PhonyClient/1.2 12689 S->C: RTSP/2.0 200 OK 12690 CSeq: 4 12691 Session: abcdefgh 12692 Range: npt=10-15 12693 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12694 ssrc=0D12F123:seq=0;rtptime=0 12696 The ensuing RTP data stream is depicted below: 12698 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12699 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12700 . . . 12701 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 12703 Upon the completion of the requested delivery the server sends a 12704 PLAY_NOTIFY 12705 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 12706 CSeq: 5 12707 Notify-Reason: end-of-stream 12708 Request-Status: cseq=4 status=200 reason="OK" 12709 Range: npt=-15 12710 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 12711 ssrc=0D12F123:seq=49;rtptime=39200 12712 Session: abcdefgh 12714 C->S: RTSP/2.0 200 OK 12715 CSeq: 5 12716 User-Agent: PhonyClient/1.2 12718 Upon the completion of the play range, the client follows up with a 12719 request to PLAY from a new NPT. 12721 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12722 CSeq: 6 12723 Session: abcdefg 12724 Range: npt=18-20 12725 User-Agent: PhonyClient/1.2 12727 S->C: RTSP/2.0 200 OK 12728 CSeq: 6 12729 Session: abcdefg 12730 Range: npt=18-20 12731 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12732 ssrc=0D12F123:seq=50;rtptime=40100 12734 The ensuing RTP data stream is depicted below: 12736 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 12737 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 12738 . . . 12739 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 12741 In this example, first, NPT 10 through 15 is played, then the client 12742 requests the server to skip ahead and play NPT 18 through 20. The 12743 first segment is presented as RTP packets with sequence numbers 0 12744 through 49 and timestamp 0 through 39,200. The second segment 12745 consists of RTP packets with sequence number 50 through 69, with 12746 timestamps 40,100 through 55,200. While there is a gap in the NPT, 12747 there is no gap in the sequence number space of the RTP data stream. 12749 The RTP timestamp gap is present in the above example due to the time 12750 it takes to perform the second play request, in this case 12.5 ms 12751 (100/8000). 12753 C.4. Handling RTP Timestamps after PAUSE 12755 During a PAUSE / PLAY interaction in an RTSP session, the duration of 12756 time for which the RTP transmission was halted MUST be reflected in 12757 the RTP timestamp of each RTP stream. The duration can be calculated 12758 for each RTP stream as the time elapsed from when the last RTP packet 12759 was sent before the PAUSE request was received and when the first RTP 12760 packet was sent after the subsequent PLAY request was received. The 12761 duration includes all latency incurred and processing time required 12762 to complete the request. 12764 The RTP RFC [RFC3550] states that: The RTP timestamp for each unit 12765 [packet] would be related to the wallclock time at which the unit 12766 becomes current on the virtual presentation timeline. 12768 In order to satisfy the requirements of [RFC3550], the RTP 12769 timestamp space needs to increase continuously with real time. 12770 While this is not optimal for stored media, it is required for RTP 12771 and RTCP to function as intended. Using a continuous RTP 12772 timestamp space allows the same timestamp model for both stored 12773 and live media and allows better opportunity to integrate both 12774 types of media under a single control. 12776 As an example, assume a clock frequency of 8000 Hz, a packetization 12777 interval of 100 ms and an initial sequence number and timestamp of 12778 zero. 12780 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12781 CSeq: 4 12782 Session: abcdefg 12783 Range: npt=10-15 12784 User-Agent: PhonyClient/1.2 12786 S->C: RTSP/2.0 200 OK 12787 CSeq: 4 12788 Session: abcdefg 12789 Range: npt=10-15 12790 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12791 ssrc=0D12F123:seq=0;rtptime=0 12793 The ensuing RTP data stream is depicted below: 12795 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12796 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12797 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 12798 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 12800 The client then sends a PAUSE request: 12802 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 12803 CSeq: 5 12804 Session: abcdefg 12805 User-Agent: PhonyClient/1.2 12807 S->C: RTSP/2.0 200 OK 12808 CSeq: 5 12809 Session: abcdefg 12810 Range: npt=10.4-15 12812 20 seconds elapse and then the client sends a PLAY request. In 12813 addition the server requires 15 ms to process the request: 12815 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12816 CSeq: 6 12817 Session: abcdefg 12818 User-Agent: PhonyClient/1.2 12820 S->C: RTSP/2.0 200 OK 12821 CSeq: 6 12822 Session: abcdefg 12823 Range: npt=10.4-15 12824 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12825 ssrc=0D12F123:seq=4;rtptime=164400 12827 The ensuing RTP data stream is depicted below: 12829 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 12830 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 12831 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 12833 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 12834 server. After 20 seconds a PLAY is received by the server which 12835 takes 15 ms to process. The duration of time for which the session 12836 was paused is reflected in the RTP timestamp of the RTP packets sent 12837 after this PLAY request. 12839 A client can use the RTSP range header and RTP-Info header to map NPT 12840 time of a presentation with the RTP timestamp. 12842 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 12843 was misunderstood commonly. However, for RTSP 2.0 it is expected 12844 that this will be handled correctly and no exception handling will be 12845 required. 12847 Note further: It may be required to reset some of the state to ensure 12848 the correct media decoding and the usual jitter-buffer handling when 12849 issuing a PLAY request. 12851 C.5. RTSP / RTP Integration 12853 For certain data types, tight integration between the RTSP layer and 12854 the RTP layer will be necessary. This by no means precludes the 12855 above restrictions. Combined RTSP/RTP media clients should use the 12856 RTP-Info field to determine whether incoming RTP packets were sent 12857 before or after a seek or before or after a PAUSE. 12859 C.6. Scaling with RTP 12861 For scaling (see Section 18.46), RTP timestamps should correspond to 12862 the rendering timing. For example, when playing video recorded at 30 12863 frames/second at a scale of two and speed (Section 18.50) of one, the 12864 server would drop every second frame to maintain and deliver video 12865 packets with the normal timestamp spacing of 3,000 per frame, but NPT 12866 would increase by 1/15 second for each video frame. 12868 Note: The above scaling puts requirements on the media codec or a 12869 media stream to support it. For example motion JPEG or other non- 12870 predictive video coding can easier handle the above example. 12872 C.7. Maintaining NPT synchronization with RTP timestamps 12874 The client can maintain a correct display of NPT (Normal Play Time) 12875 by noting the RTP timestamp value of the first packet arriving after 12876 repositioning. The sequence parameter of the RTP-Info 12877 (Section 18.45) header provides the first sequence number of the next 12878 segment. 12880 C.8. Continuous Audio 12882 For continuous audio, the server SHOULD set the RTP marker bit at the 12883 beginning of serving a new PLAY request or at jumps in timeline. 12884 This allows the client to perform playout delay adaptation. 12886 C.9. Multiple Sources in an RTP Session 12888 Note that more than one SSRC MAY be sent in the media stream. If it 12889 happens all sources are expected to be rendered simultaneously. 12891 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 12893 The RTCP BYE message indicates the end of use of a given SSRC. If 12894 all sources leave an RTP session, it can, in most cases, be assumed 12895 to have ended. Therefore, a client or server MUST NOT send an RTCP 12896 BYE message until it has finished using a SSRC. A server SHOULD keep 12897 using a SSRC until the RTP session is terminated. Prolonging the use 12898 of a SSRC allows the established synchronization context associated 12899 with that SSRC to be used to synchronize subsequent PLAY requests 12900 even if the PLAY response is late. 12902 An SSRC collision with the SSRC that transmits media does also have 12903 consequences, as it will normally force the media sender to change 12904 its SSRC in accordance with the RTP specification [RFC3550]. 12905 However, an RTSP server may wait and see if the client changes and 12906 thus resolve the conflict to minimize the impact. As media sender 12907 SSRC change will result in a loss of synchronization context, and 12908 require any receiver to wait for RTCP sender reports for all media 12909 requiring synchronization before being able to play out synchronized. 12910 Due to these reasons a client joining a session should take care to 12911 not select the same SSRC(s) as the server indicates in the ssrc 12912 Transport header parameter. Any SSRC signalled in the Transport 12913 header MUST be avoided. A client detecting a collision prior to 12914 sending any RTP or RTCP messages SHALL also select a new SSRC. 12916 C.11. Future Additions 12918 It is the intention that any future protocol or profile regarding 12919 media delivery and lower transport should be easy to add to RTSP. 12920 This section provides the necessary steps that needs to be meet. 12922 The following things needs to be considered when adding a new 12923 protocol or profile for use with RTSP: 12925 o The protocol or profile needs to define a name tag representing 12926 it. This tag is required to be an ABNF "token" to be possible to 12927 use in the Transport header specification. 12929 o The useful combinations of protocol, profiles and lower layer 12930 transport for this extension needs to be defined. For each 12931 combination declare the necessary parameters to use in the 12932 Transport header. 12934 o For new media protocols the interaction with RTSP needs to be 12935 addressed. One important factor will be the media 12936 synchronization. It may be necessary to have new headers similar 12937 to RTP info to carry this information. 12939 o Discuss congestion control for media, especially if transport 12940 without built in congestion control is used. 12942 See the IANA section (Section 22) for information how to register new 12943 attributes. 12945 Appendix D. Use of SDP for RTSP Session Descriptions 12947 The Session Description Protocol (SDP, [RFC4566]) may be used to 12948 describe streams or presentations in RTSP. This description is 12949 typically returned in reply to a DESCRIBE request on a URI from a 12950 server to a client, or received via HTTP from a server to a client. 12952 This appendix describes how an SDP file determines the operation of 12953 an RTSP session. Thus, it is worth pointing out that the 12954 interpretation of the SDP is done in the context of the SDP receiver, 12955 which is the one being configured. This is the same as in SAP 12956 [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each 12957 SDP is interpreted in the context of the agent providing it. 12959 SDP as is provides no mechanism by which a client can distinguish, 12960 without human guidance, between several media streams to be rendered 12961 simultaneously and a set of alternatives (e.g., two audio streams 12962 spoken in different languages). The SDP extension "Grouping of Media 12963 Lines in the Session Description Protocol (SDP)" [RFC5888] provides 12964 such functionality to some degree. Appendix D.4 describes the usage 12965 of SDP media line grouping for RTSP. 12967 D.1. Definitions 12969 The terms "session-level", "media-level" and other key/attribute 12970 names and values used in this appendix are to be used as defined in 12971 SDP[RFC4566]: 12973 D.1.1. Control URI 12975 The "a=control:" attribute is used to convey the control URI. This 12976 attribute is used both for the session and media descriptions. If 12977 used for individual media, it indicates the URI to be used for 12978 controlling that particular media stream. If found at the session 12979 level, the attribute indicates the URI for aggregate control 12980 (presentation URI). The session level URI MUST be different from any 12981 media level URI. The presence of a session level control attribute 12982 MUST be interpreted as support for aggregated control. The control 12983 attribute MUST be present on media level unless the presentation only 12984 contains a single media stream, in which case the attribute MAY be 12985 present on the session level only and then also apply to that single 12986 media stream. 12988 ABNF for the attribute is defined in Section 20.3. 12990 Example: 12991 a=control:rtsp://example.com/foo 12993 This attribute MAY contain either relative or absolute URIs, 12994 following the rules and conventions set out in RFC 3986 [RFC3986]. 12995 Implementations MUST look for a base URI in the following order: 12997 1. the RTSP Content-Base field; 12999 2. the RTSP Content-Location field; 13001 3. the RTSP Request-URI. 13003 If this attribute contains only an asterisk (*), then the URI MUST be 13004 treated as if it were an empty embedded URI, and thus inherit the 13005 entire base URI. 13007 Note, RFC 2326 was very unclear on the processing of relative URI 13008 and several RTSP 1.0 implementations at the point of publishing 13009 this document did not perform RFC 3986 processing to determine the 13010 resulting URI, instead simple concatenation is common. To avoid 13011 this issue completely it is recommended to use absolute URI in the 13012 SDP. 13014 The URI handling for SDPs from container files need special 13015 consideration. For example let's assume that a container file has 13016 the URI: "rtsp://example.com/container.mp4". Let's further assume 13017 this URI is the base URI, and that there is an absolute media level 13018 URI: "rtsp://example.com/container.mp4/trackID=2". A relative media 13019 level URI that resolves in accordance with RFC 3986 [RFC3986] to the 13020 above given media URI is: "container.mp4/trackID=2". It is usually 13021 not desirable to need to include in or modify the SDP stored within 13022 the container file with the server local name of the container file. 13023 To avoid this, one can modify the base URI used to include a trailing 13024 slash, e.g., "rtsp://example.com/container.mp4/". In this case the 13025 relative URI for the media will only need to be: "trackID=2". 13026 However, this will also mean that using "*" in the SDP will result in 13027 control URI including the trailing slash, i.e., 13028 "rtsp://example.com/container.mp4/". 13030 Note: The usage of TrackID in the above is not a standardized 13031 form, but one example out of several similar strings such as 13032 TrackID, Track_ID, StreamID that is used by different server 13033 vendors to indicate a particular piece of media inside a container 13034 file. 13036 D.1.2. Media Streams 13038 The "m=" field is used to enumerate the streams. It is expected that 13039 all the specified streams will be rendered with appropriate 13040 synchronization. If the session is over multicast, the port number 13041 indicated SHOULD be used for reception. The client MAY try to 13042 override the destination port, through the Transport header. The 13043 servers MAY allow this, the response will indicate if allowed or not. 13044 If the session is unicast, the port numbers are the ones RECOMMENDED 13045 by the server to the client, about which receiver ports to use; the 13046 client MUST still include its receiver ports in its SETUP request. 13047 The client MAY ignore this recommendation. If the server has no 13048 preference, it SHOULD set the port number value to zero. 13050 The "m=" lines contain information about which transport protocol, 13051 profile, and possibly lower-layer is to be used for the media stream. 13052 The combination of transport, profile and lower layer, like RTP/AVP/ 13053 UDP needs to be defined for how to be used with RTSP. The currently 13054 defined combinations are defined in Appendix C, further combinations 13055 MAY be specified. 13057 Example: 13058 m=audio 0 RTP/AVP 31 13060 D.1.3. Payload Type(s) 13062 The payload type(s) are specified in the "m=" line. In case the 13063 payload type is a static payload type from RFC 3551 [RFC3551], no 13064 other information may be required. In case it is a dynamic payload 13065 type, the media attribute "rtpmap" is used to specify what the media 13066 is. The "encoding name" within the "rtpmap" attribute may be one of 13067 those specified in [RFC4856], or a media type registered with IANA 13068 according to [RFC4855], or an experimental encoding as specified in 13069 SDP [RFC4566]). Codec-specific parameters are not specified in this 13070 field, but rather in the "fmtp" attribute described below. 13072 The selection of the RTP payload type numbers used may be required to 13073 consider RTP and RTCP Multiplexing [RFC5761] if that is to be 13074 supported by the server. 13076 D.1.4. Format-Specific Parameters 13078 Format-specific parameters are conveyed using the "fmtp" media 13079 attribute. The syntax of the "fmtp" attribute is specific to the 13080 encoding(s) that the attribute refers to. Note that some of the 13081 format specific parameters may be specified outside of the fmtp 13082 parameters, like for example the "ptime" attribute for most audio 13083 encodings. 13085 D.1.5. Directionality of media stream 13087 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 13088 provide instructions about the direction the media streams flow 13089 within a session. When using RTSP the SDP can be delivered to a 13090 client using either RTSP DESCRIBE or a number of RTSP external 13091 methods, like HTTP, FTP, and email. Based on this the SDP applies to 13092 how the RTSP client will see the complete session. Thus media 13093 streams delivered from the RTSP server to the client, would be given 13094 the "a=recvonly" attribute. 13096 "a=recvonly" in a SDP provided to the RTSP client indicates that 13097 media delivery will only occur in the direction from the RTSP server 13098 to the client. SDP provided to the RTSP client that lacks any of the 13099 directionality attributes (a=recvonly, a=sendonly, a=sendrecv) would 13100 be interpreted as having a=sendrecv. At the time of writing there 13101 exist no RTSP mode suitable for media traffic in the direction from 13102 the RTSP client to the server. Thus all RTSP SDP SHOULD have 13103 a=recvonly attribute when using the PLAY mode defined in this 13104 document. If future modes are defined for media in client to server 13105 direction, then usage of a=sendonly, or a=sendrecv may become 13106 suitable to indicate intended media directions. 13108 D.1.6. Range of Presentation 13110 The "a=range" attribute defines the total time range of the stored 13111 session or an individual media. Non-seekable live sessions can be 13112 indicated as specified below, while the length of live sessions can 13113 be deduced from the "t=" and "r=" SDP parameters. 13115 The attribute is both a session and a media level attribute. For 13116 presentations that contain media streams of the same duration, the 13117 range attribute SHOULD only be used at session-level. In case of 13118 different lengths the range attribute MUST be given at media level 13119 for all media, and SHOULD NOT be given at session level. If the 13120 attribute is present at both media level and session level the media 13121 level values MUST be used. 13123 Note: Usually one will specify the same length for all media, even if 13124 there isn't media available for the full duration on all media. 13125 However, that requires that the server accepts PLAY requests within 13126 that range. 13128 Servers MUST take care to provide RTSP Range (see Section 18.40) 13129 values that are consistent with what is presented in the SDP for the 13130 content. There is no reason for non dynamic content, like media 13131 clips provided on demand to have inconsistent values. Inconsistent 13132 values between the SDP and the actual values for the content handled 13133 by the server is likely to generate some failure, like 457 "Invalid 13134 Range", in case the client uses PLAY requests with a Range header. 13135 In case the content is dynamic in length and it is infeasible to 13136 provide a correct value in the SDP the server is recommended to 13137 describe this as non-seekable content (see below). The server MAY 13138 override that property in the response to a PLAY request using the 13139 correct values in the Range header. 13141 The unit is specified first, followed by the value range. The units 13142 and their values are as defined in Section 4.4.1, Section 4.4.2 and 13143 Section 4.4.3 and MAY be extended with further formats. Any open 13144 ended range (start-), i.e., without stop range, is of unspecified 13145 duration and MUST be considered as non-seekable content unless this 13146 property is overridden. Multiple instances carrying different clock 13147 formats MAY be included at either session or media level. 13149 ABNF for the attribute is defined in Section 20.3. 13151 Examples: 13152 a=range:npt=0-34.4368 13153 a=range:clock=19971113T211503Z-19971113T220300Z 13154 Non seekable stream of unknown duration: 13155 a=range:npt=0- 13157 D.1.7. Time of Availability 13159 The "t=" field defines when the SDP is valid. For on-demand content 13160 the server SHOULD indicate a stop time value for which it guarantees 13161 the description to be valid, and a start time that is equal to or 13162 before the time at which the DESCRIBE request was received. It MAY 13163 also indicate start and stop times of 0, meaning that the session is 13164 always available. 13166 For sessions that are of live type, i.e., specific start time, 13167 unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD 13168 be used to indicate the start time of the event. The stop time 13169 SHOULD be given so that the live event will have ended at that time, 13170 while still not be unnecessary long into the future. 13172 D.1.8. Connection Information 13174 In SDP used with RTSP, the "c=" field contains the destination 13175 address for the media stream. If a multicast address is specified 13176 the client SHOULD use this address in any SETUP request as 13177 destination address, including any additional parameters, such as 13178 TTL. For on-demand unicast streams and some multicast streams, the 13179 destination address MAY be specified by the client via the SETUP 13180 request, thus overriding any specified address. To identify streams 13181 without a fixed destination address, where the client is required to 13182 specify a destination address, the "c=" field SHOULD be set to a null 13183 value. For addresses of type "IP4", this value MUST be "0.0.0.0", 13184 and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be 13185 written as "::"), i.e., the unspecified address according to RFC 4291 13186 [RFC4291]. 13188 D.1.9. Message Body Tag 13190 The optional "a=mtag" attribute identifies a version of the session 13191 description. It is opaque to the client. SETUP requests may include 13192 this identifier in the If-Match field (see Section 18.24) to only 13193 allow session establishment if this attribute value still corresponds 13194 to that of the current description. The attribute value is opaque 13195 and may contain any character allowed within SDP attribute values. 13197 ABNF for the attribute is defined in Section 20.3. 13199 Example: 13200 a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a" 13202 One could argue that the "o=" field provides identical 13203 functionality. However, it does so in a manner that would put 13204 constraints on servers that need to support multiple session 13205 description types other than SDP for the same piece of media 13206 content. 13208 D.2. Aggregate Control Not Available 13210 If a presentation does not support aggregate control no session level 13211 "a=control:" attribute is specified. For a SDP with multiple media 13212 sections specified, each section will have its own control URI 13213 specified via the "a=control:" attribute. 13215 Example: 13216 v=0 13217 o=- 2890844256 2890842807 IN IP4 192.0.2.56 13218 s=I came from a web page 13219 e=adm@example.com 13220 c=IN IP4 0.0.0.0 13221 t=0 0 13222 m=video 8002 RTP/AVP 31 13223 a=control:rtsp://audio.example.com/movie.aud 13224 m=audio 8004 RTP/AVP 3 13225 a=control:rtsp://video.example.com/movie.vid 13227 Note that the position of the control URI in the description implies 13228 that the client establishes separate RTSP control sessions to the 13229 servers audio.example.com and video.example.com. 13231 It is recommended that an SDP file contains the complete media 13232 initialization information even if it is delivered to the media 13233 client through non-RTSP means. This is necessary as there is no 13234 mechanism to indicate that the client should request more detailed 13235 media stream information via DESCRIBE. 13237 D.3. Aggregate Control Available 13239 In this scenario, the server has multiple streams that can be 13240 controlled as a whole. In this case, there are both a media-level 13241 "a=control:" attributes, which are used to specify the stream URIs, 13242 and a session-level "a=control:" attribute which is used as the 13243 Request-URI for aggregate control. If the media-level URI is 13244 relative, it is resolved to absolute URIs according to Appendix D.1.1 13245 above. 13247 Example: 13248 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 13249 CSeq: 1 13250 User-Agent: PhonyClient/1.2 13252 M->C: RTSP/2.0 200 OK 13253 CSeq: 1 13254 Date: Thu, 23 Jan 1997 15:35:06 GMT 13255 Expires: Thu, 23 Jan 1997 16:35:06 GMT 13256 Content-Type: application/sdp 13257 Content-Base: rtsp://example.com/movie/ 13258 Content-Length: 227 13260 v=0 13261 o=- 2890844256 2890842807 IN IP4 192.0.2.211 13262 s=I contain 13263 i= 13264 e=adm@example.com 13265 c=IN IP4 0.0.0.0 13266 a=control:* 13267 t=0 0 13268 m=video 8002 RTP/AVP 31 13269 a=control:trackID=1 13270 m=audio 8004 RTP/AVP 3 13271 a=control:trackID=2 13273 In this example, the client is recommended to establish a single RTSP 13274 session to the server, and uses the URIs 13275 rtsp://example.com/movie/trackID=1 and 13276 rtsp://example.com/movie/trackID=2 to set up the video and audio 13277 streams, respectively. The URI rtsp://example.com/movie/, which is 13278 resolved from the "*", controls the whole presentation (movie). 13280 A client is not required to issue SETUP requests for all streams 13281 within an aggregate object. Servers should allow the client to ask 13282 for only a subset of the streams. 13284 D.4. Grouping of Media Lines in SDP 13286 For some types of media it is desirable to express a relationship 13287 between various media components, for instance, for lip 13288 synchronization or Scalable Video Codec (SVC) [RFC5583]. This 13289 relationship is expressed on the SDP level by grouping of media 13290 lines, as described in [RFC5888] and can be exposed to RTSP. 13292 For RTSP it is mainly important to know how to handle grouped medias 13293 received by means of SDP, i.e., if the media are under aggregate 13294 control (see Appendix D.3) or if aggregate control is not available 13295 (see Appendix D.2). 13297 It is RECOMMENDED that grouped medias are handled by aggregate 13298 control, to give the client the ability to control either the whole 13299 presentation or single medias. 13301 D.5. RTSP external SDP delivery 13303 There are some considerations that need to be made when the session 13304 description is delivered to the client outside of RTSP, for example 13305 via HTTP or email. 13307 First of all, the SDP needs to contain absolute URIs, since relative 13308 will in most cases not work as the delivery will not correctly 13309 forward the base URI. 13311 The writing of the SDP session availability information, i.e., "t=" 13312 and "r=", needs to be carefully considered. When the SDP is fetched 13313 by the DESCRIBE method, the probability that it is valid is very 13314 high. However, the same is much less certain for SDPs distributed 13315 using other methods. Therefore the publisher of the SDP should take 13316 care to follow the recommendations about availability in the SDP 13317 specification [RFC4566] in Section 4.2. 13319 Appendix E. RTSP Use Cases 13321 This Appendix describes the most important and considered use cases 13322 for RTSP. They are listed in descending order of importance in 13323 regards to ensuring that all necessary functionality is present. 13324 This specification only fully supports usage of the two first. Also 13325 in these first two cases, there are special cases or exceptions that 13326 are not supported without extensions, e.g., the redirection of media 13327 delivery to another address than the controlling agent's (client's). 13329 E.1. On-demand Playback of Stored Content 13331 An RTSP capable server stores content suitable for being streamed to 13332 a client. A client desiring playback of any of the stored content 13333 uses RTSP to set up the media transport required to deliver the 13334 desired content. RTSP is then used to initiate, halt and manipulate 13335 the actual transmission (playout) of the content. RTSP is also 13336 required to provide necessary description and synchronization 13337 information for the content. 13339 The above high level description can be broken down into a number of 13340 functions that RTSP needs to be capable of. 13342 Presentation Description: Provide initialization information about 13343 the presentation (content); for example, which media codecs are 13344 needed for the content. Other information that is important 13345 includes the number of media streams the presentation contains, 13346 the transport protocols used for the media streams, and 13347 identifiers for these media streams. This information is 13348 required before setup of the content is possible and to 13349 determine if the client is even capable of using the content. 13351 This information need not be sent using RTSP; other external 13352 protocols can be used to transmit the transport presentation 13353 descriptions. Two good examples are the use of HTTP [RFC2616] 13354 or email to fetch or receive presentation descriptions like SDP 13355 [RFC4566] 13357 Setup: Set up some or all of the media streams in a presentation. 13358 The setup itself consists of selecting the protocol for media 13359 transport and the necessary parameters for the protocol, like 13360 addresses and ports. 13362 Control of Transmission: After the necessary media streams have been 13363 established the client can request the server to start 13364 transmitting the content. The client must be allowed to start 13365 or stop the transmission of the content at arbitrary times. 13366 The client must also be able to start the transmission at any 13367 point in the timeline of the presentation. 13369 Synchronization: For media transport protocols like RTP [RFC3550] it 13370 might be beneficial to carry synchronization information within 13371 RTSP. This may be due to either the lack of inter-media 13372 synchronization within the protocol itself, or the potential 13373 delay before the synchronization is established (which is the 13374 case for RTP when using RTCP). 13376 Termination: Terminate the established contexts. 13378 For this use case there are a number of assumptions about how it 13379 works. These are: 13381 On-Demand content: The content is stored at the server and can be 13382 accessed at any time during a time period when it is intended 13383 to be available. 13385 Independent sessions: A server is capable of serving a number of 13386 clients simultaneously, including from the same piece of 13387 content at different points in that presentations time-line. 13389 Unicast Transport: Content for each individual client is transmitted 13390 to them using unicast traffic. 13392 It is also possible to redirect the media traffic to a different 13393 destination than that of the agent controlling the traffic. However, 13394 allowing this without appropriate mechanisms for checking that the 13395 destination approves of this allows for distributed denial of service 13396 attacks (DDoS). 13398 E.2. Unicast Distribution of Live Content 13400 This use case is similar to the above on-demand content case (see 13401 Appendix E.1) the difference is the nature of the content itself. 13402 Live content is continuously distributed as it becomes available from 13403 a source; i.e., the main difference from on-demand is that one starts 13404 distributing content before the end of it has become available to the 13405 server. 13407 In many cases the consumer of live content is only interested in 13408 consuming what actually happens "now"; i.e., very similar to 13409 broadcast TV. However, in this case it is assumed that there exists 13410 no broadcast or multicast channel to the users, and instead the 13411 server functions as a distribution node, sending the same content to 13412 multiple receivers, using unicast traffic between server and client. 13413 This unicast traffic and the transport parameters are individually 13414 negotiated for each receiving client. 13416 Another aspect of live content is that it often has a very limited 13417 time of availability, as it is only available for the duration of the 13418 event the content covers. An example of such a live content could be 13419 a music concert which lasts 2 hour and starts at a predetermined 13420 time. Thus there is a need to announce when and for how long the 13421 live content is available. 13423 In some cases, the server providing live content may be saving some 13424 or all of the content to allow clients to pause the stream and resume 13425 it from the paused point, or to "rewind" and play continuously from a 13426 point earlier than the live point. Hence, this use case does not 13427 necessarily exclude playing from other than the live point of the 13428 stream, playing with scales other than 1.0, etc. 13430 E.3. On-demand Playback using Multicast 13432 It is possible to use RTSP to request that media be delivered to a 13433 multicast group. The entity setting up the session (the controller) 13434 will then control when and what media is delivered to the group. 13435 This use case has some potential for denial of service attacks by 13436 flooding a multicast group. Therefore, a mechanism is needed to 13437 indicate that the group actually accepts the traffic from the RTSP 13438 server. 13440 An open issue in this use case is how one ensures that all receivers 13441 listening to the multicast or broadcast receives the session 13442 presentation configuring the receivers. This specification has to 13443 rely on an external solution to solve this issue. 13445 E.4. Inviting an RTSP server into a conference 13447 If one has an established conference or group session, it is possible 13448 to have an RTSP server distribute media to the whole group. 13449 Transmission to the group is simplest when controlled by a single 13450 participant or leader of the conference. Shared control might be 13451 possible, but would require further investigation and possibly 13452 extensions. 13454 This use case assumes that there exists either multicast or a 13455 conference focus that redistribute media to all participants. 13457 This use case is intended to be able to handle the following 13458 scenario: A conference leader or participant (hereafter called the 13459 controller) has some pre-stored content on an RTSP server that he 13460 wants to share with the group. The controller sets up an RTSP 13461 session at the streaming server for this content and retrieves the 13462 session description for the content. The destination for the media 13463 content is set to the shared multicast group or conference focus. 13465 When desired by the controller, he/she can start and stop the 13466 transmission of the media to the conference group. 13468 There are several issues with this use case that are not solved by 13469 this core specification for RTSP: 13471 Denial of service: To avoid an RTSP server from being an unknowing 13472 participant in a denial of service attack the server needs to 13473 be able to verify the destination's acceptance of the media. 13474 Such a mechanism to verify the approval of received media does 13475 not yet exist; instead, only policies can be used, which can be 13476 made to work in controlled environments. 13478 Distributing the presentation description to all participants in the 13479 group: To enable a media receiver to correctly decode the content 13480 the media configuration information needs to be distributed 13481 reliably to all participants. This will most likely require 13482 support from an external protocol. 13484 Passing control of the session: If it is desired to pass control of 13485 the RTSP session between the participants, some support will be 13486 required by an external protocol to exchange state information 13487 and possibly floor control of who is controlling the RTSP 13488 session. 13490 E.5. Live Content using Multicast 13492 This use case in its simplest form does not require any use of RTSP 13493 at all; this is what multicast conferences being announced with SAP 13494 [RFC2974] and SDP are intended to handle. However, in use cases 13495 where more advanced features like access control to the multicast 13496 session are desired, RTSP could be used for session establishment. 13498 A client desiring to join a live multicasted media session with 13499 cryptographic (encryption) access control could use RTSP in the 13500 following way. The source of the session announces the session and 13501 gives all interested an RTSP URI. The client connects to the server 13502 and requests the presentation description, allowing configuration for 13503 reception of the media. In this step it is possible for the client 13504 to use secured transport and any desired level of authentication; for 13505 example, for billing or access control. An RTSP link also allows for 13506 load balancing between multiple servers. 13508 If these were the only goals, they could be achieved by simply using 13509 HTTP. However, for cases where the sender likes to keep track of 13510 each individual receiver of a session, and possibly use the session 13511 as a side channel for distributing key-updates or other information 13512 on a per-receiver basis, and the full set of receivers is not known 13513 prior to the session start, the state establishment that RTSP 13514 provides can be beneficial. In this case a client would establish an 13515 RTSP session for this multicast group with the RTSP server. The RTSP 13516 server will not transmit any media, but instead will point to the 13517 multicast group. The client and server will be able to keep the 13518 session alive for as long as the receiver participates in the session 13519 thus enabling, for example, the server to push updates to the client. 13521 This use case will most likely not be able to be implemented without 13522 some extensions to the server-to-client push mechanism. Here the 13523 PLAY_NOTIFY method (see Section 13.5) with a suitable extension could 13524 provide clear benefits. 13526 Appendix F. Text format for Parameters 13528 A resource of type "text/parameters" consists of either 1) a list of 13529 parameters (for a query) or 2) a list of parameters and associated 13530 values (for an response or setting of the parameter). Each entry of 13531 the list is a single line of text. Parameters are separated from 13532 values by a colon. The parameter name MUST only use US-ASCII visible 13533 characters while the values are UTF-8 text strings. The media type 13534 registration form is in Section 22.16. 13536 There is a potential interoperability issue for this format. It was 13537 named in RFC 2326 but never defined, even if used in examples that 13538 hint at the syntax. This format matches the purpose and its syntax 13539 supports the examples provided. However, it goes further by allowing 13540 UTF-8 in the value part, thus usage of UTF-8 strings may not be 13541 supported. However, as individual parameters are not defined, the 13542 using application anyway needs to have out-of-band agreement or using 13543 feature-tag to determine if the end-point supports the parameters. 13545 The ABNF [RFC5234] grammar for "text/parameters" content is: 13547 file = *((parameter / parameter-value) CRLF) 13548 parameter = 1*visible-except-colon 13549 parameter-value = parameter *WSP ":" value 13550 visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" 13551 value = *(TEXT-UTF8char / WSP) 13552 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 13553 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 13554 / %xE0-EF 2UTF8-CONT 13555 / %xF0-F7 3UTF8-CONT 13556 / %xF8-FB 4UTF8-CONT 13557 / %xFC-FD 5UTF8-CONT 13558 UTF8-CONT = %x80-BF 13559 WSP = ; Space or HTAB 13560 VCHAR = 13561 CRLF = 13563 Appendix G. Requirements for Unreliable Transport of RTSP 13565 This appendix provides guidance for those who want to implement RTSP 13566 messages over unreliable transports as has been defined in RTSP 1.0 13567 [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some 13568 basic information for the transport of RTSP messages over UDP. The 13569 information is being provided here as there has been at at least one 13570 commercial implementation and compatibility with that should be 13571 maintained. 13573 The following points should be considered for an interoperable 13574 implementation: 13576 o Requests shall be acknowledged by the receiver. If there is no 13577 acknowledgement, the sender may resend the same message after a 13578 timeout of one round-trip time (RTT). Any retransmissions due to 13579 lack of acknowledgement must carry the same sequence number as the 13580 original request. 13582 o The round-trip time can be estimated as in TCP (RFC 6298) 13583 [RFC6298], with an initial round-trip value of 500 ms. An 13584 implementation may cache the last RTT measurement as the initial 13585 value for future connections. 13587 o The Timestamp header (Section 18.53) is used to avoid the 13588 retransmission ambiguity problem [Stevens98]. 13590 o The registered default port for RTSP over UDP for the server is 13591 554. 13593 o RTSP messages can be carried over any lower-layer transport 13594 protocol that is 8-bit clean. 13596 o RTSP messages are vulnerable to bit errors and should not be 13597 subjected to them. 13599 o Source authentication, or at least validation that RTSP messages 13600 comes from the same entity becomes extremely important, as session 13601 hijacking may be substantially easier for RTSP message transport 13602 using an unreliable protocol like UDP than for TCP. 13604 There are two RTSP headers that are primarily intended for being used 13605 by the unreliable handling of RTSP messages and which will be 13606 maintained: 13608 o CSeq: See Section 18.20. It should be noted that the CSeq header 13609 is also required to match requests and responses independent 13610 whether a reliable or unreliable transport is used. 13612 o Timestamp: See Section 18.53 13614 Appendix H. Backwards Compatibility Considerations 13616 This section contains notes on issues about backwards compatibility 13617 with clients or servers being implemented according to RFC 2326 13618 [RFC2326]. Note that there exists no requirement to implement RTSP 13619 1.0; in fact we recommend against it as it is difficult to do in an 13620 interoperable way. 13622 A server implementing RTSP/2.0 MUST include an RTSP-Version of 13623 RTSP/2.0 in all responses to requests containing RTSP-Version 13624 RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond 13625 with an RTSP/1.0 response if it chooses to support RFC 2326. If the 13626 server chooses not to support RFC 2326, it MUST respond with a 505 13627 (RTSP Version not supported) status code. A server MUST NOT respond 13628 to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 13629 response. 13631 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 13632 Version of 2.0 to determine whether a server supports RTSP/2.0. If 13633 the server responds with either an RTSP-Version of 1.0 or a status 13634 code of 505 (RTSP Version not supported), the client will have to use 13635 RTSP/1.0 requests if it chooses to support RFC 2326. 13637 H.1. Play Request in Play State 13639 The behavior in the server when a Play is received in Play state has 13640 changed (Section 13.4). In RFC 2326, the new PLAY request would be 13641 queued until the current Play completed. Any new PLAY request now 13642 takes effect immediately replacing the previous request. 13644 H.2. Using Persistent Connections 13646 Some server implementations of RFC 2326 maintain a one-to-one 13647 relationship between a connection and an RTSP session. Such 13648 implementations require clients to use a persistent connection to 13649 communicate with the server and when a client closes its connection, 13650 the server may remove the RTSP session. This is worth noting if a 13651 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 13653 Appendix I. Changes 13655 This appendix briefly lists the differences between RTSP 1.0 13656 [RFC2326] and RTSP 2.0 for an informational purpose. For 13657 implementers of RTSP 2.0 it is recommended to read carefully through 13658 this memo and not to rely on the list of changes below to adapt from 13659 RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards 13660 compatible with RTSP 1.0 [RFC2326] other than the version negotiation 13661 mechanism. 13663 I.1. Brief Overview 13665 The following protocol elements were removed in RTSP 2.0 compared to 13666 RTSP 1.0: 13668 o there is no section on minimal implementation anymore, but more 13669 the definition of RTSP 2.0 core; 13671 o the RECORD and ANNOUNCE methods and all related functionality 13672 (including 201 (Created) and 250 (Low On Storage Space) status 13673 codes); 13675 o the use of UDP for RTSP message transport was removed due to 13676 missing interest and to broken specification; 13678 o the use of PLAY method for keep-alive in Play state. 13680 The following protocol elements were added or changed in RTSP 2.0 13681 compared to RTSP 1.0: 13683 o RTSP session TEARDOWN from the server to the client; 13685 o IPv6 support; 13687 o extended IANA registries (e.g., transport headers parameters, 13688 transport-protocol, profile, lower-transport, and mode); 13690 o request pipelining for quick session start-up; 13692 o fully reworked state-machine; 13694 o RTSP messages now use URIs rather then URLs; 13696 o incorporated much of related HTTP text ([RFC2616]) in this memo, 13697 compared to just referencing the sections in HTTP, to avoid 13698 ambiguities; 13700 o the REDIRECT method was expanded and diversified for different 13701 situations; 13703 o Includes a new section about how to setup different media 13704 transport alternatives and their profiles, and lower layer 13705 protocols. This caused the appendix on RTP interaction to be 13706 moved there instead of being in the part which describes RTP. The 13707 section also includes guidelines what to consider when writing 13708 usage guidelines for new protocols and profiles; 13710 o Added an asynchronous notification method PLAY_NOTIFY. This 13711 method is used by the RTSP server to asynchronously notify clients 13712 about session changes while in Play state. To a limited extent 13713 this is comparable with some implementations of ANNOUNCE in RTSP 13714 1.0 not intended for Recording. 13716 I.2. Detailed List of Changes 13718 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 13719 defining RTSP 2.0. Note that this list does not reflect minor 13720 changes in wording or correction of typographical errors. 13722 o The section on minimal implementation was deleted without 13723 substitution. 13725 o The Transport header has been changed in the following way: 13727 * The ABNF has been changed to define that extensions are 13728 possible, and that unknown parameters result in that servers 13729 ignore the transport specification. 13731 * To prevent backwards compatibility issues, any extension or new 13732 parameter requires the usage of a feature-tag combined with the 13733 Require header. 13735 * Syntax unclarities with the Mode parameter have been resolved. 13737 * Syntax error with ";" for multicast and unicast has been 13738 resolved. 13740 * Two new addressing parameters have been defined, src_addr and 13741 dest_addr. These replace the parameters "port", "client_port", 13742 "server_port", "destination", "source". 13744 * Support for IPv6 explicit addresses in all address fields has 13745 been included. 13747 * To handle URI definitions that contain ";" or "," a quoted URI 13748 format has been introduced and is required. 13750 * Defined IANA registries for the transport headers parameters, 13751 transport-protocol, profile, lower-transport, and mode. 13753 * The transport headers interleaved parameter's text was made 13754 more strict and uses formal requirements levels. It was also 13755 clarified that the interleaved channels are symmetric and that 13756 it is the server that sets the channel numbers. 13758 * It has been clarified that the client can't request of the 13759 server to use a certain RTP SSRC, using a request with the 13760 transport parameter SSRC. 13762 * Syntax definition for SSRC has been clarified to require 8HEX. 13763 It has also been extended to allow multiple values for clients 13764 supporting this version. 13766 * Clarified the text on the transport headers "dest_addr" 13767 parameters regarding what security precautions the server is 13768 required to perform. 13770 o The Range formats has been changed in the following way: 13772 * The NPT format has been given an initial NPT identifier that 13773 must now be used. 13775 * All formats now support initial open ended formats of type 13776 "npt=-10" and also format only "Range: smpte" ranges for usage 13777 with GET_PARAMETER requests. 13779 o RTSP message handling has been changed in the following way: 13781 * RTSP messages now use URIs rather then URLs. 13783 * It has been clarified that a 4xx message due to missing CSeq 13784 header shall be returned without a CSeq header. 13786 * The 300 (Multiple Choices) response code has been removed. 13788 * Rules for how to handle timing out RTSP messages has been 13789 added. 13791 * Extended Pipelining rules allowing for quick session startup. 13793 * Sequence numbering and proxy handling of sequence number 13794 defined, including case when response arrive out of order. 13796 o The HTTP references have been updated to RFC 2616 and RFC 2617. 13797 Most of the text has been copied and then altered to fit RTSP into 13798 this specification. Public, and the Content-Base header has also 13799 been imported from RFC 2068 so that they are defined in the RTSP 13800 specification. Known effects on RTSP due to HTTP clarifications: 13802 * Content-Encoding header can include encoding of type 13803 "identity". 13805 o The state machine section has been completely rewritten. It now 13806 includes more details and is also more clear about the model used. 13808 o An IANA section has been included which contains a number of 13809 registries and their rules. This will allow us to use IANA to 13810 keep track of RTSP extensions. 13812 o The transport of RTSP messages has seen the following changes: 13814 * The use of UDP for RTSP message transport has been deprecated 13815 due to missing interest and to broken specification. 13817 * The rules for how TCP connections are to be handled has been 13818 clarified. Now it is made clear that servers should not close 13819 the TCP connection unless they have been unused for significant 13820 time. 13822 * Strong recommendations why server and clients should use 13823 persistent connections have also been added. 13825 * There is now a requirement on the servers to handle non- 13826 persistent connections as this provides fault tolerance. 13828 * Added wording on the usage of Connection:Close for RTSP. 13830 * Specified usage of TLS for RTSP messages, including a scheme to 13831 approve a proxy's TLS connection to the next hop. 13833 o The following header related changes have been made: 13835 * Accept-Ranges response-header is added. This header clarifies 13836 which range formats that can be used for a resource. 13838 * Fixed the missing definitions for the Cache-Control header. 13839 Also added to the syntax definition the missing delta-seconds 13840 for max-stale and min-fresh parameters. 13842 * Put requirement on CSeq header that the value is increased by 13843 one for each new RTSP request. A Recommendation to start at 0 13844 has also been added. 13846 * Added requirement that the Date header must be used for all 13847 messages with message body and the Server should always include 13848 it. 13850 * Removed possibility of using Range header with Scale header to 13851 indicate when it is to be activated, since it can't work as 13852 defined. Also added rule that lack of Scale header in response 13853 indicates lack of support for the header. Feature-tags for 13854 scaled playback has been defined. 13856 * The Speed header must now be responded to indicate support and 13857 the actual speed going to be used. A feature-tag is defined. 13858 Notes on congestion control were also added. 13860 * The Supported header was borrowed from SIP [RFC3261] to help 13861 with the feature negotiation in RTSP. 13863 * Clarified that the Timestamp header can be used to resolve 13864 retransmission ambiguities. 13866 * The Session header text has been expanded with an explanation 13867 on keep-alive and which methods to use. SET_PARAMETER is now 13868 recommended to use if only keep-alive within RTSP is desired. 13870 * It has been clarified how the Range header formats are used to 13871 indicate pause points in the PAUSE response. 13873 * Clarified that RTP-Info URIs that are relative, use the 13874 Request-URI as base URI. Also clarified that the used URI must 13875 be the one that was used in the SETUP request. The URIs are 13876 now also required to be quoted. The header also expresses the 13877 SSRC for the provided RTP timestamp and sequence number values. 13879 * Added text that requires the Range to always be present in PLAY 13880 responses. Clarified what should be sent in case of live 13881 streams. 13883 * The headers table has been updated using a structure borrowed 13884 from SIP. Those tables convey much more information and should 13885 provide a good overview of the available headers. 13887 * It has been clarified that any message with a message body is 13888 required to have a Content-Length header. This was the case in 13889 RFC 2326, but could be misinterpreted. 13891 * ETag has changed name to MTag. 13893 * To resolve functionality around MTag. The MTag and If-None- 13894 Match header have been added from HTTP with necessary 13895 clarification in regards to RTSP operation. 13897 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 13898 it has been removed from HTTP due to lack of use. Public is 13899 used quite frequently in RTSP. 13901 * Clarified rules for populating the Public header so that it is 13902 an intersection of the capabilities of all the RTSP agents in a 13903 chain. 13905 * Added the Media-Range header for listing the current 13906 availability of the media range. 13908 * Added the Notify-Reason header for giving the reason when 13909 sending PLAY_NOTIFY requests. 13911 * A new header Seek-Style has been defined to direct and inform 13912 how any seek operation should/have been performed. 13914 o The Protocol Syntax has been changed in the following way: 13916 * All ABNF definitions are updated according to the rules defined 13917 in RFC 5234 [RFC5234] and have been gathered in a separate 13918 Section 20. 13920 * The ABNF for the User-Agent and Server headers have been 13921 corrected. 13923 * Some definitions in the introduction regarding the RTSP session 13924 have been changed. 13926 * The protocol has been made fully IPv6 capable. 13928 * The CHAR rule has been changed to exclude NULL. 13930 o The Status codes have been changed in the following way: 13932 * The use of status code 303 "See Other" has been deprecated as 13933 it does not make sense to use in RTSP. 13935 * When sending response 451 and 458 the response body should 13936 contain the offending parameters. 13938 * Clarification on when a 3rr redirect status code can be 13939 received has been added. This includes receiving 3rr as a 13940 result of a request within a established session. This 13941 provides clarification to a previous unspecified behavior. 13943 * Removed the 201 (Created) and 250 (Low On Storage Space) status 13944 codes as they are only relevant to recording, which is 13945 deprecated. 13947 * Several new Status codes have been defined: 464 "Data Transport 13948 Not Ready Yet", 465 "Notification Reason Unknown", 470 13949 "Connection Authorization Required", 471 "Connection 13950 Credentials not accepted", 472 "Failure to establish secure 13951 connection". 13953 o The following functionality has been deprecated from the protocol: 13955 * The use of Queued Play. 13957 * The use of PLAY method for keep-alive in Play state. 13959 * The RECORD and ANNOUNCE methods and all related functionality. 13960 Some of the syntax has been removed. 13962 * The possibility to use timed execution of methods with the time 13963 parameter in the Range header. 13965 * The description on how rtspu works is not part of the core 13966 specification and will require external description. Only that 13967 it exists is defined here and some requirements for the 13968 transport is provided. 13970 o The following changes have been made in relation to methods: 13972 * The OPTIONS method has been clarified with regards to the use 13973 of the Public and Allow headers. 13975 * Added text clarifying the usage of SET_PARAMETER for keep-alive 13976 and usage without any body. 13978 * PLAY method is now allowed to be pipelined with the pipelining 13979 of one or more SETUP requests following the initial that 13980 generates the session for aggregated control. 13982 * REDIRECT has been expanded and diversified for different 13983 situations. 13985 * Added a new method PLAY_NOTIFY. This method is used by the 13986 RTSP server to asynchronously notify clients about session 13987 changes. 13989 o Wrote a new section about how to setup different media transport 13990 alternatives and their profiles, and lower layer protocols. This 13991 caused the appendix on RTP interaction to be moved there instead 13992 of being in the part which describes RTP. The section also 13993 includes guidelines what to consider when writing usage guidelines 13994 for new protocols and profiles. 13996 o Setup and usage of independent TCP connections for transport of 13997 RTP has been specified. 13999 o Added a new section describing the available mechanisms to 14000 determine if functionality is supported, called "Capability 14001 Handling". Renamed option-tags to feature-tags. 14003 o Added a contributors section with people who have contributed 14004 actual text to the specification. 14006 o Added a section Use Cases that describes the major use cases for 14007 RTSP. 14009 o Clarified the usage of a=range and how to indicate live content 14010 that are not seekable with this header. 14012 o Text specifying the special behavior of PLAY for live content. 14014 o Security features of RTSP have been clarified: 14016 * HTTP based authorization has been clarified requring both Basic 14017 and DIGEST support 14019 * TLS support mandated 14021 * IF one implements RTP then SRTP and defined MIKEY based key- 14022 exchange must be supported 14024 * Various minor mitigations discussed or resulted in protocol 14025 changes. 14027 Appendix J. Acknowledgements 14029 This memorandum defines RTSP version 2.0 which is a revision of the 14030 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 14031 The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert 14032 Lanphier. 14034 Both RTSP version 1.0 and RTSP version 2.0 borrow format and 14035 descriptions from HTTP/1.1. 14037 Robert Sparks and especially Elwyn Davies provided very valuable and 14038 detailed reviews in the IETF last call that greately improved the 14039 document and resolved many issues, especially regarding consistency. 14041 This document has benefited greatly from the comments of all those 14042 participating in the MMUSIC-WG. In addition to those already 14043 mentioned, the following individuals have contributed to this 14044 specification: 14046 Rahul Agarwal, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten 14047 Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen 14048 Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Kelly 14049 Djahandari, Martin Dunsmuir, Stephen Farrell, Ross Finlayson, Eric 14050 Fleischman, Jay Geagan, Andy Grignon, Christian Groves, V. 14051 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 14052 John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, Anne Jones, 14053 Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth Lang, Stephanie 14054 Leif, Jonathan Lennox, Eduardo F. Llach, Chris Lonvick, Xavier 14055 Marjou, Thomas Marshall, Rob McCool, Martti Mela, David Oran, Joerg 14056 Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu 14057 Periyannan, Colin Perkins, Pekka Pessi, Igor Plotnikov, Peter Saint- 14058 Andre, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David Singer, 14059 Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis 14060 Stracke, Geetha Srikantan, Scott Taylor, David Walker, Stephan 14061 Wenger, Dale R. Worley, and Byungjo Yoon , and especially to Flemming 14062 Andreasen. 14064 J.1. Contributors 14066 The following people have made written contributions that were 14067 included in the specification: 14069 o Tom Marshall contributed text on the usage of 3rr status codes. 14071 o Thomas Zheng contributed text on the usage of the Range in PLAY 14072 responses and proposed an earlier version of the PLAY_NOTIFY 14073 method. 14075 o Sean Sheedy contributed text on the timeout behavior of RTSP 14076 messages and connections, the 463 status code, and proposed an 14077 earlier version of the PLAY_NOTIFY method. 14079 o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY 14080 method. 14082 o Fredrik Lindholm contributed text about the RTSP security 14083 framework. 14085 o John Lazzaro contributed the text for RTP over Independent TCP. 14087 o Aravind Narasimhan contributed by rewriting Media Transport 14088 Alternatives (Appendix C) and editorial improvements on a number 14089 of places in the specification. 14091 o Torbjorn Einarsson has done some editorial improvements of the 14092 text. 14094 Appendix K. RFC Editor Consideration 14096 Please replace RFC XXXX with the RFC number this specification 14097 receives. 14099 Authors' Addresses 14101 Henning Schulzrinne 14102 Columbia University 14103 1214 Amsterdam Avenue 14104 New York, NY 10027 14105 USA 14107 Email: schulzrinne@cs.columbia.edu 14109 Anup Rao 14110 Cisco 14111 USA 14113 Email: anrao@cisco.com 14115 Rob Lanphier 14116 Seattle, WA 14117 USA 14119 Email: robla@robla.net 14121 Magnus Westerlund 14122 Ericsson AB 14123 Faeroegatan 6 14124 STOCKHOLM, SE-164 80 14125 SWEDEN 14127 Email: magnus.westerlund@ericsson.com 14129 Martin Stiemerling 14130 NEC Laboratories Europe, NEC Europe Ltd. 14131 Kurfuersten-Anlage 36 14132 Heidelberg 69115 14133 Germany 14135 Phone: +49 (0) 6221 4342 113 14136 Email: martin.stiemerling@neclab.eu 14137 URI: http://ietf.stiemerling.org