idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-36.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 (September 11, 2013) is 3880 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 4973, but not defined == Missing Reference: 'H15' is mentioned on line 9379, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 10005, 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 2822 (Obsoleted by RFC 5322) -- 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 (==), 12 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: March 15, 2014 R. Lanphier 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 September 11, 2013 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-36 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 March 15, 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 . . . . . . . . . . . . . . . . . . . 31 99 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 32 100 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . 32 101 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 33 102 4.7.1. Random Access and Seeking . . . . . . . . . . . . . 34 103 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . 34 104 4.7.3. Content Modifications . . . . . . . . . . . . . . . 34 105 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . 35 106 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . 35 107 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 36 108 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 36 109 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 37 110 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 37 111 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 38 112 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 39 113 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 114 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 41 115 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 43 116 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45 117 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 45 118 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 45 119 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 49 120 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 50 121 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 50 122 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 51 123 9.3. Message Body Format Negotiation . . . . . . . . . . . . 52 125 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 53 126 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 53 127 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 54 128 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 57 129 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 58 130 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 59 131 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 60 132 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 61 133 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 63 134 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 64 135 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 66 136 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 67 137 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 68 138 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 69 139 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 71 140 13.3.1. Changing Transport Parameters . . . . . . . . . . . 74 141 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 75 142 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 75 143 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 80 144 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 81 145 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 83 146 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 84 147 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 84 148 13.4.7. Playing Live with Recording . . . . . . . . . . . . 85 149 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 85 150 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 86 151 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 87 152 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 89 153 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 90 154 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 91 155 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 94 156 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 94 157 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 95 158 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 96 159 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 98 160 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 100 161 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 103 162 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 163 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 106 164 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 107 165 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 166 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 108 167 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 110 168 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 110 169 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 110 170 16.1.4. Rules for When to Use Message Body Tags and 171 Last-Modified Dates . . . . . . . . . . . . . . . . 112 172 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 114 174 16.2. Invalidation After Updates or Deletions . . . . . . . . 114 175 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 116 176 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 116 177 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 116 178 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 116 179 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 116 180 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 116 181 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 117 182 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 117 183 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 117 184 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 118 185 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 118 186 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 118 187 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 118 188 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 118 189 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 119 190 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 119 191 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 119 192 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 119 193 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 119 194 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 120 195 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 120 196 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 120 197 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 120 198 17.4.11. 412 Precondition Failed . . . . . . . . . . . . . . 121 199 17.4.12. 413 Request Message Body Too Large . . . . . . . . . 121 200 17.4.13. 414 Request-URI Too Long . . . . . . . . . . . . . . 121 201 17.4.14. 415 Unsupported Media Type . . . . . . . . . . . . . 121 202 17.4.15. 451 Parameter Not Understood . . . . . . . . . . . . 121 203 17.4.16. 452 reserved . . . . . . . . . . . . . . . . . . . . 122 204 17.4.17. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 122 205 17.4.18. 454 Session Not Found . . . . . . . . . . . . . . . 122 206 17.4.19. 455 Method Not Valid in This State . . . . . . . . . 122 207 17.4.20. 456 Header Field Not Valid for Resource . . . . . . 122 208 17.4.21. 457 Invalid Range . . . . . . . . . . . . . . . . . 122 209 17.4.22. 458 Parameter Is Read-Only . . . . . . . . . . . . . 122 210 17.4.23. 459 Aggregate Operation Not Allowed . . . . . . . . 123 211 17.4.24. 460 Only Aggregate Operation Allowed . . . . . . . . 123 212 17.4.25. 461 Unsupported Transport . . . . . . . . . . . . . 123 213 17.4.26. 462 Destination Unreachable . . . . . . . . . . . . 123 214 17.4.27. 463 Destination Prohibited . . . . . . . . . . . . . 123 215 17.4.28. 464 Data Transport Not Ready Yet . . . . . . . . . . 123 216 17.4.29. 465 Notification Reason Unknown . . . . . . . . . . 124 217 17.4.30. 466 Key Management Error . . . . . . . . . . . . . . 124 218 17.4.31. 470 Connection Authorization Required . . . . . . . 124 219 17.4.32. 471 Connection Credentials not accepted . . . . . . 124 220 17.4.33. 472 Failure to establish secure connection . . . . . 124 221 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 124 222 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 124 223 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 125 224 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 125 225 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 125 226 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 125 227 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 125 228 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 126 229 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 126 230 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 127 231 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 137 232 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 138 233 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 138 234 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 139 235 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 140 236 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 141 237 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 141 238 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 141 239 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 142 240 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 143 241 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 143 242 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 146 243 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 146 244 18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 147 245 18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 148 246 18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 148 247 18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 149 248 18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 149 249 18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 150 250 18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 151 251 18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 152 252 18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 153 253 18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 154 254 18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 155 255 18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 155 256 18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 155 257 18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 156 258 18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 157 259 18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 157 260 18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 159 261 18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 160 262 18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 160 263 18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 160 264 18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 161 265 18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 162 266 18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 162 267 18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 162 268 18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 162 269 18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 163 270 18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 164 271 18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 166 272 18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 166 273 18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 167 274 18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 168 275 18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 168 276 18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 170 277 18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 171 278 18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 173 279 18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 173 280 18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 175 281 18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 176 282 18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 176 283 18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 177 284 18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 177 285 18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 184 286 18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 185 287 18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 185 288 18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 186 289 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 187 290 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 187 291 19.1.1. Digest Authentication . . . . . . . . . . . . . . . 188 292 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 188 293 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 189 294 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 191 295 19.3.2. User approved TLS procedure . . . . . . . . . . . . 192 296 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 297 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 194 298 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 196 299 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 196 300 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 199 301 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 203 302 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 212 303 21. Security Considerations . . . . . . . . . . . . . . . . . . . 213 304 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 213 305 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 216 306 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 217 307 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 218 308 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 220 309 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 221 310 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 221 311 22.1.2. Registering New Feature-tags with IANA . . . . . . . 221 312 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 221 313 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 222 314 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 222 315 22.2.2. Registering New Methods with IANA . . . . . . . . . 222 316 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 222 317 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 223 318 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 223 319 22.3.2. Registering New Status Codes with IANA . . . . . . . 223 320 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 223 321 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 223 322 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 224 323 22.4.2. Registering New Headers with IANA . . . . . . . . . 224 324 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 224 325 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 226 326 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 226 327 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 226 328 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 227 329 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 227 330 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 228 331 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 228 332 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 228 333 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 228 334 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 228 335 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 229 336 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 229 337 22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 229 338 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 229 339 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 230 340 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 230 341 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 230 342 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 230 343 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 231 344 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 231 345 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 231 346 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 231 347 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 232 348 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 232 349 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 232 350 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 232 351 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 232 352 22.13. Transport Header Registries . . . . . . . . . . . . . . 233 353 22.13.1. Transport Protocol Identifier . . . . . . . . . . . 233 354 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 235 355 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 235 356 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 236 357 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 236 358 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 237 359 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 239 360 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 239 361 22.16. Media Type Registration for text/parameters . . . . . . 240 362 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 242 363 23.1. Normative References . . . . . . . . . . . . . . . . . . 242 364 23.2. Informative References . . . . . . . . . . . . . . . . . 244 365 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 247 366 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 247 367 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 251 368 A.3. Secured Media Session for on Demand Content . . . . . . 253 369 A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 256 370 A.5. Single Stream Container Files . . . . . . . . . . . . . 260 371 A.6. Live Media Presentation Using Multicast . . . . . . . . 262 372 A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 263 373 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 265 374 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 265 375 B.2. State variables . . . . . . . . . . . . . . . . . . . . 265 376 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 266 377 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 266 378 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 273 379 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 273 380 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 273 381 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 273 382 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 275 383 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 275 384 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 278 385 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 278 386 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 280 387 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 280 388 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 280 389 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 284 390 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 288 391 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 290 392 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 290 393 C.7. Maintaining NPT synchronization with RTP timestamps . . 290 394 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 290 395 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 290 396 C.10. Usage of SSRCs and the RTCP BYE Message During an 397 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 290 398 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 291 399 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 292 400 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 292 401 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 292 402 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 293 403 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 294 404 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 294 405 D.1.5. Directionality of media stream . . . . . . . . . . . 294 406 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 295 407 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 296 408 D.1.8. Connection Information . . . . . . . . . . . . . . . 296 409 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 297 410 D.2. Aggregate Control Not Available . . . . . . . . . . . . 297 411 D.3. Aggregate Control Available . . . . . . . . . . . . . . 298 412 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 299 413 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 299 415 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 300 416 E.1. On-demand Playback of Stored Content . . . . . . . . . . 300 417 E.2. Unicast Distribution of Live Content . . . . . . . . . . 301 418 E.3. On-demand Playback using Multicast . . . . . . . . . . . 302 419 E.4. Inviting an RTSP server into a conference . . . . . . . 302 420 E.5. Live Content using Multicast . . . . . . . . . . . . . . 303 421 Appendix F. Text format for Parameters . . . . . . . . . . . . . 305 422 Appendix G. Requirements for Unreliable Transport of RTSP . . . 306 423 Appendix H. Backwards Compatibility Considerations . . . . . . . 308 424 H.1. Play Request in Play State . . . . . . . . . . . . . . . 308 425 H.2. Using Persistent Connections . . . . . . . . . . . . . . 308 426 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 309 427 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 309 428 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 310 429 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 317 430 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 317 431 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 319 432 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 320 434 1. Introduction 436 This memo defines version 2.0 of the Real Time Streaming Protocol 437 (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and 438 control over the delivery of data with real-time properties, 439 typically streaming media. Streaming media is, for instance, video 440 on demand or audio live streaming. Put simply, RTSP acts as a 441 "network remote control" for multimedia servers, similar to the 442 remote control for a DVD player. 444 The protocol operates between RTSP 2.0 clients and servers, but also 445 supports the usage of proxies placed between clients and servers. 446 Clients can request information about streaming media from servers by 447 asking for a description of the media or use media description 448 provided externally. The media delivery protocol is used to 449 establish the media streams described by the media description. 450 Clients can then request to play out the media, pause it, or stop it 451 completely, as known from DVD players remote control or media 452 players. The requested media can consist of multiple audio and video 453 streams that are delivered as time-synchronized streams from servers 454 to clients. 456 RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that 457 specification. This protocol is based on RTSP 1.0 but is not 458 backwards compatible other than in the basic version negotiation 459 mechanism. The changes are documented in Appendix I. There are many 460 reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but 461 some of the main ones are: 463 o Most headers that needed to be extensible did not define the 464 allowed syntax, preventing safe deployment of extensions; 466 o The changed behavior of the PLAY method when received in Play 467 state; 469 o Changed behavior of the extensibility model and its mechanism; 471 o The change of syntax for some headers. 473 In summary, there are so many small details that changing version 474 became necessary to enable clarification and consistent behavior. 476 This document is structured as follows. It begins with an overview 477 of the protocol operations and its functions in an informal way. 478 Then a set of definitions of terms used and document conventions is 479 introduced. It is followed by the actual RTSP 2.0 core protocol 480 specification. The appendixes describe and define some 481 functionalities that are not part of the core RTSP specification, but 482 which are still important to enable some usages. Among them, the RTP 483 usage is defined in Appendix C, the Session Description Protocol 484 (SDP) usage with RTSP is defined in Appendix D, and the text/ 485 parameters file format Appendix F, are three normative specification 486 appendixes. Others include a number of informational parts 487 discussing the changes, use cases, different considerations or 488 motivations. 490 2. Protocol Overview 492 This section provides an informative overview of the different 493 mechanisms in the RTSP 2.0 protocol, to give the reader a high level 494 understanding before getting into all the different details. In case 495 of conflict with this description and the later sections, the later 496 sections take precedence. For more information about use cases 497 considered for RTSP see Appendix E. 499 RTSP 2.0 is a bi-directional request and response protocol that first 500 establishes a context including content resources (the media) and 501 then controls the delivery of these content resources from the 502 provider to the consumer. RTSP has three fundamental parts: Session 503 Establishment, Media Delivery Control, and an extensibility model 504 described below. The protocol is based on some assumptions about 505 existing functionality to provide a complete solution for client 506 controlled real-time media delivery. 508 RTSP uses text-based messages, requests and responses, that may 509 contain a binary message body. An RTSP request starts with a method 510 line that identifies the method, the protocol and version and the 511 resource to act on. The resource is identified by an URI and the 512 hostname part of the URI is used by RTSP client to resolve the IPv4 513 or IPv6 address of the RTSP server. Following the method line are a 514 number of RTSP headers. This part is ended by two consecutive 515 carriage return line feed (CRLF) character pairs. The message body 516 if present follows the two CRLF and the body's length is described by 517 a message header. RTSP responses are similar, but start with a 518 response line with the protocol and version, followed by a status 519 code and a reason phrase. RTSP messages are sent over a reliable 520 transport protocol between the client and server. RTSP 2.0 requires 521 clients and servers to implement TCP, and TLS over TCP, as mandatory 522 transports for RTSP messages. 524 2.1. Presentation Description 526 RTSP exists to provide access to multi-media presentations and 527 content, but tries to be agnostic about the media type or the actual 528 media delivery protocol that is used. To enable a client to 529 implement a complete system, an RTSP-external mechanism for 530 describing the presentation and the delivery protocol(s) is used. 531 RTSP assumes that this description is either delivered completely out 532 of band or as a data object in the response to a client's request 533 using the DESCRIBE method (Section 13.2). 535 Parameters that commonly have to be included in the Presentation 536 Description are the following: 538 o Number of media streams; 540 o The resource identifier for each media stream/resource that is to 541 be controlled by RTSP; 543 o The protocol that each media stream is to be delivered over; 545 o Transport protocol parameters that are not negotiated or vary with 546 each client; 548 o Media encoding information enabling a client to correctly decode 549 the media upon reception; 551 o An aggregate control resource identifier. 553 RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media 554 resources and aggregates under common control (See Section 4.2). 556 This specification describes in Appendix D how one uses SDP [RFC4566] 557 for Presentation Description 559 2.2. Session Establishment 561 The RTSP client can request the establishment of an RTSP session 562 after having used the presentation description to determine which 563 media streams are available, and also which media delivery protocol 564 is used and their particular resource identifiers. The RTSP session 565 is a common context between the client and the server that consists 566 of one or more media resources that are to be under common media 567 delivery control. 569 The client creates an RTSP session by sending a request using the 570 SETUP method (Section 13.3) to the server. In the SETUP request the 571 client also includes all the transport parameters necessary to enable 572 the media delivery protocol to function in the "Transport" header 573 (Section 18.54). This includes parameters that are pre-established 574 by the presentation description but necessary for any middlebox to 575 correctly handle the media delivery protocols. The Transport header 576 in a request may contain multiple alternatives for media delivery in 577 a prioritized list, which the server can select from. These 578 alternatives are typically based on information in the presentation 579 description. 581 The server determines if the media resource is available upon 582 receiving a SETUP request and if any of the transport parameter 583 specifications are acceptable. If that is successful, an RTSP 584 session context is created and the relevant parameters and state is 585 stored. An identifier is created for the RTSP session and included 586 in the response in the Session header (Section 18.49). The SETUP 587 response includes a Transport header that specifies which of the 588 alternatives has been selected and relevant parameters. 590 A SETUP request that references an existing RTSP session but 591 identifies a new media resource is a request to add that media 592 resource under common control with the already present media 593 resources in an aggregated session. A client can expect this to work 594 for all media resources under RTSP control within a multi-media 595 content. However, aggregating resources from different content are 596 likely to be refused by the server. The RTSP session as aggregate is 597 referenced by the aggregate control URI, even if the RTSP session 598 only contains a single media. 600 To avoid an extra round trip in the session establishment of 601 aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., 602 the client can send multiple requests back-to-back without waiting 603 first for the completion of any of them. The client uses a client- 604 selected identifier in the Pipelined-Requests header (Section 18.33) 605 to instruct the server to bind multiple requests together as if they 606 included the session identifier. 608 The SETUP response also provides additional information about the 609 established sessions in a couple of different headers. The Media- 610 Properties header (Section 18.29) includes a number of properties 611 that apply for the aggregate that is valuable when doing media 612 delivery control and configuring user interface. The Accept-Ranges 613 header (Section 18.5) informs the client about which range formats 614 that the server supports with these media resources. The Media-Range 615 header (Section 18.30) informs the client about the time range of the 616 media currently available. 618 2.3. Media Delivery Control 620 After having established an RTSP session, the client can start 621 controlling the media delivery. The basic operations are Start by 622 using the PLAY method (Section 13.4) and Halt by using the PAUSE 623 method (Section 13.6). PLAY also allows for choosing the starting 624 media position from which the server should deliver the media. The 625 positioning is done by using the Range header (Section 18.40) that 626 supports several different time formats: Normal Play Time (NPT) 627 (Section 4.4.2), Society of Motion Picture and Television Engineers 628 (SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3). 629 The Range header does further allow the client to specify a position 630 where delivery should end, thus allowing a specific interval to be 631 delivered. 633 The support for positioning/searching within a content depends on the 634 content's media properties. Content exists in a number of different 635 types, such as: on-demand, live, and live with simultaneous 636 recording. Even within these categories there are differences in how 637 the content is generated and distributed, which affect how it can be 638 accessed for playback. The properties applicable for the RTSP 639 session are provided by the server in the SETUP response using the 640 Media-Properties header (Section 18.29). These are expressed using 641 one or several independent attributes. A first attribute is Random 642 Access, which expresses if positioning can be done, and with what 643 granularity. Another aspect is whether the content will change 644 during the lifetime of the session. While on-demand content will be 645 provided in full from the beginning, a live stream being recorded 646 results in the length of the accessible content growing as the 647 session goes on. There also exists content that is dynamically built 648 by another protocol than RTSP and thus also changes in steps during 649 the session, but maybe not continuously. Furthermore, when content 650 is recorded, there are cases where not the complete content is 651 maintained, but, for example, only the last hour. All these 652 properties result in the need for mechanisms that will be discussed 653 below. 655 When the client accesses on-demand content that allows random access, 656 the client can issue the PLAY request for any point in the content 657 between the start and the end. The server will deliver media from 658 the closest random access point prior to the requested point and 659 indicate that in its PLAY response. If the client issues a PAUSE, 660 the delivery will be halted and the point at which the server stopped 661 will be reported back in the response. The client can later resume 662 by sending a PLAY request without a range header. When the server is 663 about to complete the PLAY request by delivering the end of the 664 content or the requested range, the server will send a PLAY_NOTIFY 665 request (Section 13.5) indicating this. 667 When playing live content with no extra functions, such as recording, 668 the client will receive the live media from the server after having 669 sent a PLAY request. Seeking in such content is not possible as the 670 server does not store it, but only forwards it from the source of the 671 session. Thus delivery continues until the client sends a PAUSE 672 request, tears down the session, or the content ends. 674 For live sessions that are being recorded the client will need to 675 keep track of how the recording progresses. Upon session 676 establishment the client will learn the current duration of the 677 recording from the Media-Range header. As the recording is ongoing 678 the content grows in direct relation to the passed time. Therefore, 679 each server's response to a PLAY request will contain the current 680 Media-Range header. The server should also regularly send 681 approximately every 5 minutes the current media range in a 682 PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, 683 the server must send a PLAY_NOTIFY request with the updated Media- 684 Properties indicating that the content stopped being a recorded live 685 session and instead became on-demand content; the request also 686 contains the final media range. While the live delivery continues 687 the client can request to play the current live point by using the 688 NPT timescale symbol "now", or it can request a specific point in the 689 available content by an explicit range request for that point. If 690 the requested point is outside of the available interval the server 691 will adjust the position to the closest available point, i.e., either 692 at the beginning or the end. 694 A special case of recording is that where the recording is not 695 retained longer than a specific time period, thus as the live 696 delivery continues the client can access any media within a moving 697 window that covers, for example, "now" to "now" minus 1 hour. A 698 client that pauses on a specific point within the content may not be 699 able to retrieve the content anymore. If the client waits too long 700 before resuming the pause point, the content may no longer be 701 available. In this case the pause point will be adjusted to the 702 closest point in the available media. 704 2.4. Session Parameter Manipulations 706 A session may have additional state or functionality that affects how 707 the server or client treats the session, content, how it functions, 708 or feedback on how well the session works. Such extensions are not 709 defined in this specification, but may be done in various extensions. 710 RTSP has two methods for retrieving and setting parameter values on 711 either the client or the server: GET_PARAMETER (Section 13.8) and 712 SET_PARAMETER (Section 13.9). These methods carry the parameters in 713 a message body of the appropriate format. One can also use headers 714 to query state with the GET_PARAMETER method. As an example, clients 715 needing to know the current media-range for a time-progressing 716 session can use the GET_PARAMETER method and include the media-range. 717 Furthermore, synchronization information can be requested by using a 718 combination of RTP-Info (Section 18.45) and Range (Section 18.40). 720 RTSP 2.0 does not have a strong mechanism for providing negotiation 721 of the headers, or parameters and their formats, which can be used. 722 However, responses will indicate request headers or parameters that 723 are not supported. A priori determination of what features are 724 available needs to be done through out-of-band mechanisms, like the 725 session description, or through the usage of feature tags 726 (Section 4.5). 728 2.5. Media Delivery 730 The delivery of media to the RTSP client is done with a protocol 731 outside of RTSP and this protocol is determined during the session 732 establishment. This document specifies how media is delivered with 733 RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP 734 connection. Additional protocols may be specified in the future 735 based on demand. 737 The usage of RTP as media delivery protocol requires some additional 738 information to function well. The PLAY response contains information 739 to enable reliable and timely delivery of how a client should 740 synchronize different sources in the different RTP sessions. It also 741 provides a mapping between RTP timestamps and the content time scale. 742 When the server wants to notify the client about the completion of 743 the media delivery, it sends a PLAY_NOTIFY request to the client. 744 The PLAY_NOTIFY request includes information about the stream end, 745 including the last RTP sequence number for each stream, thus enabling 746 the client to empty the buffer smoothly. 748 2.5.1. Media Delivery Manipulations 750 The basic playback functionality of RTSP enables delivery of a range 751 of requested content to the client at the pace intended by the 752 content's creator. However, RTSP can also manipulate the delivery to 753 the client in two ways. 755 Scale: The ratio of media content time delivered per unit playback 756 time. 758 Speed: The ratio of playback time delivered per unit of wallclock 759 time. 761 Both affect the media delivery per time unit. However, they 762 manipulate two independent time scales and the effects are possible 763 to combine. 765 Scale (Section 18.46) is used for fast forward or slow motion control 766 as it changes the amount of content timescale that should be played 767 back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0 768 results in that 2 seconds of content is played back every second of 769 playback. Scale = 1.0 is the default value that is used if no Scale 770 is specified, i.e., playback at the content's original rate. Scale 771 values between 0 and 1.0 is providing for slow motion. Scale can be 772 negative to allow for reverse playback in either regular pace (Scale 773 = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards 774 (-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed. 776 In most cases the realization of scale means server side manipulation 777 of the media to ensure that the client can actually play it back. 778 The nature of these media manipulations and when they are needed is 779 highly media-type dependent. Let's consider an example with two 780 common media types audio and video. 782 It is very difficult to modify the playback rate of audio. A maximum 783 of 10-30% is possible by changing the pitch-rate of speech. Music 784 goes out of tune if one tries to manipulate the playback rate by 785 resampling it. This is a well known problem and audio is commonly 786 muted or played back in short segments with skips to keep up with the 787 current playback point. 789 For video it is possible to manipulate the frame rate, although the 790 rendering capabilities are often limited to certain frame rates. 791 Also the allowed bitrates in decoding, the structure used in the 792 encoding and the dependency between frames and other capabilities of 793 the rendering device limits the possible manipulations. Therefore, 794 the basic fast forward capabilities often are implemented by 795 selecting certain subsets of frames. 797 Due to the media restrictions, the possible scale values are commonly 798 restricted to the set of realizable scale ratios. To enable the 799 clients to select from the possible scale values, RTSP can signal the 800 supported Scale ratios for the content. To support aggregated or 801 dynamic content, where this may change during the ongoing session and 802 dependent on the location within the content, a mechanism for 803 updating the media properties and the scale factor currently in use, 804 exists. 806 Speed (Section 18.50) affects how much of the playback timeline is 807 delivered in a given wallclock period. The default is Speed = 1 808 which means to deliver at the same rate the media is consumed. Speed 809 > 1 means that the receiver will get content faster than it regularly 810 would consume it. Speed < 1 means that delivery is slower than the 811 regular media rate. Speed values of 0 or lower have no meaning and 812 are not allowed. This mechanism enables two general functionalities. 813 One is client side scale operations, i.e., the client receives all 814 the frames and makes the adjustment to the playback locally. The 815 second is delivery control for buffering of media. By specifying a 816 speed over 1.0 the client can build up the amount of playback time it 817 has present in its buffers to a level that is sufficient for its 818 needs. 820 A naive implementation of Speed would only affect the transmission 821 schedule of the media and has a clear impact on the needed bandwidth. 822 This would result in the data rate being proportional to the speed 823 factor. Speed = 1.5, i.e., 50% faster than normal delivery, would 824 result in a 50% increase in the data transport rate. If that can be 825 supported or not depends solely on the underlying network path. 826 Scale may also have some impact on the required bandwidth due to the 827 manipulation of the content in the new playback schedule. An example 828 is fast forward where only the independently decodable intra frames 829 are included in the media stream. This usage of solely intra frames 830 increases the data rate significantly compared to a normal sequence 831 with the same number of frames, where most frames are encoded using 832 prediction. 834 This potential increase of the data rate needs to be handled by the 835 media sender. The client has requested that the media will be 836 delivered in a specific way, which should be honored. However, the 837 media sender cannot ignore if the network path between the sender and 838 the receiver can't handle the resulting media stream. In that case 839 the media stream needs to be adapted to fit the available resources 840 of the path. This can result in a reduced media quality. 842 The need for bitrate adaptation becomes especially problematic in 843 connection with the Speed semantics. If the goal is to fill up the 844 buffer, the client may not want to do that at the cost of reduced 845 quality. If the client wants to make local playout changes then it 846 may actually require that the requested speed be honored. To resolve 847 this issue, Speed uses a range so that both cases can be supported. 848 The server is requested to use the highest possible speed value 849 within the range which is compatible with the available bandwidth. 850 As long as the server can maintain a speed value within the range it 851 shall not change the media quality, but instead modify the actual 852 delivery rate in response to available bandwidth and reflect this in 853 the Speed value in the response. However, if this is not possible, 854 the server should instead modify the media quality to respect the 855 lowest speed value and the available bandwidth. 857 This functionality enables the local scaling implementation to use a 858 tight range, or even a range where the lower bound equals the upper 859 bound, to identify that it requires the server to deliver the 860 requested amount of media time per delivery time independent of how 861 much it needs to adapt the media quality to fit within the available 862 path bandwidth. For buffer filling, it is suitable to use a range 863 with a reasonable span and with a lower bound at the nominal media 864 rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the 865 buffer, it can specify an upper bound that is below 1.0 to force the 866 server to deliver slower than the nominal media rate. 868 2.6. Session Maintenance and Termination 870 The session context that has been established is kept alive by having 871 the client show liveness. This is done in two main ways: 873 o Media transport protocol keep-alive. RTP Control Protocol (RTCP) 874 may be used when using RTP. 876 o Any RTSP request referencing the session context. 878 Section 10.5 discusses the methods for showing liveness in more 879 depth. If the client fails to show liveness for more than the 880 established session timeout value (normally 60 seconds), the server 881 may terminate the context. Other values may be selected by the 882 server through the inclusion of the timeout parameter in the session 883 header. 885 The session context is normally terminated by the client sending a 886 TEARDOWN request (Section 13.7) to the server referencing the 887 aggregated control URI. An individual media resource can be removed 888 from a session context by a TEARDOWN request referencing that 889 particular media resource. If all media resources are removed from a 890 session context, the session context is terminated. 892 A client may keep the session alive indefinitely if allowed by the 893 server; however, it is recommended to release the session context 894 when an extended period of time without media delivery activity has 895 passed. The client can re-establish the session context if required 896 later. What constitutes an extended period of time is dependent on 897 the server and its usage. It is recommended that the client 898 terminates the session before ten times the session timeout value has 899 passed. A server may terminate the session after one session timeout 900 period without any client activity beyond keep-alive. When a server 901 terminates the session context, it does that by sending a TEARDOWN 902 request indicating the reason. 904 A server can also request that the client tear down the session and 905 re-establish it at an alternative server, as may be needed for 906 maintenance. This is done by using the REDIRECT method 907 (Section 13.10). The Terminate-Reason header (Section 18.52) is used 908 to indicate when and why. The Location header indicates where it 909 should connect if there is an alternative server available. When the 910 deadline expires, the server simply stops providing the service. To 911 achieve a clean closure, the client needs to initiate session 912 termination prior to the deadline. In case the server has no other 913 server to redirect to, and wants to close the session for 914 maintenance, it shall use the TEARDOWN method with a Terminate-Reason 915 header. 917 2.7. Extending RTSP 919 RTSP is quite a versatile protocol which supports extensions in many 920 different directions. Even this core specification contains several 921 blocks of functionality that are optional to implement. The use case 922 and need for the protocol deployment should determine what parts are 923 implemented. Allowing for extensions makes it possible for RTSP to 924 reach out to additional use cases. However, extensions will affect 925 the interoperability of the protocol and therefore it is important 926 that they can be added in a structured way. 928 The client can learn the capability of a server by using the OPTIONS 929 method (Section 13.1) and the Supported header (Section 18.51). It 930 can also try and possibly fail using new methods, or require that 931 particular features are supported using the Require (Section 18.43) 932 or Proxy-Require (Section 18.37) header. 934 The RTSP protocol in itself can be extended in three ways, listed 935 here in increasing order of the magnitude of changes supported: 937 o Existing methods can be extended with new parameters, for example, 938 headers, as long as these parameters can be safely ignored by the 939 recipient. If the client needs negative acknowledgment when a 940 method extension is not supported, a tag corresponding to the 941 extension may be added in the field of the Require or Proxy- 942 Require headers. 944 o New methods can be added. If the recipient of the message does 945 not understand the request, it must respond with error code 501 946 (Not Implemented) so that the sender can avoid using this method 947 again. A client may also use the OPTIONS method to inquire about 948 methods supported by the server. The server must list the methods 949 it supports using the Public response header. 951 o A new version of the protocol can be defined, allowing almost all 952 aspects (except the position of the protocol version number) to 953 change. A new version of the protocol must be registered through 954 an IETF standards track document. 956 The basic capability discovery mechanism can be used to both discover 957 support for a certain feature and to ensure that a feature is 958 available when performing a request. For a detailed explanation of 959 this see Section 11. 961 New media delivery protocols may be added and negotiated at session 962 establishment, in addition to extensions to the core protocol. 963 Certain types of protocol manipulations can be done through parameter 964 formats using SET_PARAMETER and GET_PARAMETER. 966 3. Document Conventions 968 3.1. Notational Conventions 970 Since a few of the definitions are identical to HTTP/1.1, this 971 specification only points to the section where they are defined 972 rather than copying it. For brevity, [HX.Y] is to be taken to refer 973 to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). 975 All the mechanisms specified in this document are described in both 976 prose and the Augmented Backus-Naur form (ABNF) described in detail 977 in [RFC5234]. 979 Indented paragraphs are used to provide informative background and 980 motivation. This is intended to give readers who were not involved 981 with the formulation of the specification an understanding of why 982 things are the way they are in RTSP. 984 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 985 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 986 "OPTIONAL" in this document are to be interpreted as described in 987 [RFC2119]. 989 The word, "unspecified" is used to indicate functionality or features 990 that are not defined in this specification. Such functionality 991 cannot be used in a standardized manner without further definition in 992 an extension specification to RTSP. 994 3.2. Terminology 996 Aggregate control: The concept of controlling multiple streams using 997 a single timeline, generally maintained by the server. A client, 998 for example, uses aggregate control when it issues a single play 999 or pause message to simultaneously control both the audio and 1000 video in a movie. A session which is under aggregate control is 1001 referred to as an aggregated session. 1003 Aggregate control URI: The URI used in an RTSP request to refer to 1004 and control an aggregated session. It normally, but not always, 1005 corresponds to the presentation URI specified in the session 1006 description. See Section 13.3 for more information. 1008 Client: The client requests media service from the media server. 1010 Connection: A transport layer virtual circuit established between 1011 two programs for the purpose of communication. 1013 Container file: A file which may contain multiple media streams 1014 which often constitutes a presentation when played together. The 1015 concept of a container file is not embedded in the protocol. 1016 However, RTSP servers may offer aggregate control on the media 1017 streams within these files. 1019 Continuous media: Data where there is a timing relationship between 1020 source and sink; that is, the sink needs to reproduce the timing 1021 relationship that existed at the source. The most common examples 1022 of continuous media are audio and motion video. Continuous media 1023 can be real-time (interactive or conversational), where there is a 1024 "tight" timing relationship between source and sink, or streaming 1025 where the relationship is less strict. 1027 Feature-tag: A tag representing a certain set of functionality, 1028 i.e., a feature. 1030 IRI: Internationalized Resource Identifier, is the same as an URI, 1031 with the exception that it allows characters from the whole 1032 Universal Character Set (Unicode/ISO 10646), rather than the US- 1033 ASCII only. See [RFC3987] for more information. 1035 Live: Normally used to describe a presentation or session with media 1036 coming from an ongoing event. This generally results in the 1037 session having an unbound or only loosely defined duration, and 1038 sometimes no seek operations are possible. 1040 Media initialization: Datatype/codec specific initialization. This 1041 includes such things as clock rates, color tables, etc. Any 1042 transport-independent information which is required by a client 1043 for playback of a media stream occurs in the media initialization 1044 phase of stream setup. 1046 Media parameter: Parameter specific to a media type that may be 1047 changed before or during stream delivery. 1049 Media server: The server providing media delivery services for one 1050 or more media streams. Different media streams within a 1051 presentation may originate from different media servers. A media 1052 server may reside on the same host or on a different host from 1053 which the presentation is invoked. 1055 (Media) stream: A single media instance, e.g., an audio stream or a 1056 video stream as well as a single whiteboard or shared application 1057 group. When using RTP, a stream consists of all RTP and RTCP 1058 packets created by a source within an RTP session. 1060 Message: The basic unit of RTSP communication, consisting of a 1061 structured sequence of octets matching the syntax defined in 1062 Section 20 and transmitted over a connection-based transport. A 1063 message is either a Request or a Response. 1065 Message Body: The information transferred as the payload of a 1066 message (Request or response). A message body consists of meta- 1067 information in the form of message-body headers and content in the 1068 form of a message-body, as described in Section 9. 1070 Non-Aggregated Control: Control of a single media stream. 1072 Presentation: A set of one or more streams presented to the client 1073 as a complete media feed and described by a presentation 1074 description as defined below. Presentations with more than one 1075 media stream are often handled in RTSP under aggregate control. 1077 Presentation description: A presentation description contains 1078 information about one or more media streams within a presentation, 1079 such as the set of encodings, network addresses and information 1080 about the content. Other IETF protocols such as SDP ([RFC4566]) 1081 use the term "session" for a presentation. The presentation 1082 description may take several different formats, including but not 1083 limited to the session description protocol format, SDP. 1085 Response: An RTSP response to a Request. One type of RTSP message. 1086 If an HTTP response is meant, it is indicated explicitly. 1088 Request: An RTSP request. One type of RTSP message. If an HTTP 1089 request is meant, it is indicated explicitly. 1091 Request-URI: The URI used in a request to indicate the resource on 1092 which the request is to be performed. 1094 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 1095 RTSP proxy. In this specification, there are many capabilities 1096 that are common to these three entities such as the capability to 1097 send requests or receive responses. This term will be used when 1098 describing functionality that is applicable to all three of these 1099 entities. 1101 RTSP session: A stateful abstraction upon which the main control 1102 methods of RTSP operate. An RTSP session is a common context; it 1103 is created and maintained on client's request and can be destroyed 1104 by either the client or server. It is established by an RTSP 1105 server upon the completion of a successful SETUP request (when a 1106 200 OK response is sent) and is labeled with a session identifier 1107 at that time. The session exists until timed out by the server or 1108 explicitly removed by a TEARDOWN request. An RTSP session is a 1109 stateful entity; an RTSP server maintains an explicit session 1110 state machine (see Appendix B) where most state transitions are 1111 triggered by client requests. The existence of a session implies 1112 the existence of state about the session's media streams and their 1113 respective transport mechanisms. A given session can have one or 1114 more media streams associated with it. An RTSP server uses the 1115 session to aggregate control over multiple media streams. 1117 Origin Server: The server on which a given resource resides. 1119 Transport initialization: The negotiation of transport information 1120 (e.g., port numbers, transport protocols) between the client and 1121 the server. 1123 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 1124 RTSP are generally URLs as they give a location for the resource. 1125 As URLs are a subset of URIs, they will be referred to as URIs to 1126 cover also the cases when an RTSP URI would not be an URL. 1128 URL: Universal Resource Locator, is an URI which identifies the 1129 resource through its primary access mechanism, rather than 1130 identifying the resource by name or by some other attribute(s) of 1131 that resource. 1133 4. Protocol Parameters 1135 4.1. RTSP Version 1137 This specification defines version 2.0 of RTSP. 1139 RTSP uses a "." numbering scheme to indicate versions 1140 of the protocol. The protocol versioning policy is intended to allow 1141 the sender to indicate the format of a message and its capacity for 1142 understanding further RTSP communication, rather than the features 1143 obtained via that communication. No change is made to the version 1144 number for the addition of message components which do not affect 1145 communication behavior or which only add to extensible field values. 1147 The number is incremented when the changes made to the 1148 protocol add features which do not change the general message parsing 1149 algorithm, but which may add to the message semantics and imply 1150 additional capabilities of the sender. The number is 1151 incremented when the format of a message within the protocol is 1152 changed. The version of an RTSP message is indicated by an RTSP- 1153 Version field in the first line of the message. Note that the major 1154 and minor numbers MUST be treated as separate integers and that each 1155 MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a 1156 lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. 1157 Leading zeros MUST be ignored by recipients and MUST NOT be sent. 1159 4.2. RTSP IRI and URI 1161 RTSP 2.0 defines and registers or updates three URI schemes "rtsp", 1162 "rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified 1163 in RTSP 2.0, and is defined here to register the URI scheme that was 1164 defined in RTSP 1.0. The "rtspu" scheme indicates unspecified 1165 transport of the RTSP messages over unreliable transport (UDP in RTSP 1166 1.0). An RTSP server MUST respond with an error code indicating the 1167 "rtspu" scheme is not implemented (501) to a request that carries a 1168 "rtspu" URI scheme. 1170 The details of the syntax of "rtsp" and "rtsps" URIs has been changed 1171 from RTSP 1.0. These changes are: 1173 o Support for IPV6 literal in host part and future IP literals 1174 through RFC 3986 defined mechanism. 1176 o A new relative format to use in the RTSP protocol elements that is 1177 not required to start with "/". 1179 Neither should have any significant impact on interoperability. If 1180 one is required to use IPv6 literals to reach an RTSP server, then 1181 that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully 1182 IPv6 capable protocol. If an RTSP 1.0 client attempts to process the 1183 URI it will not match the allowed syntax and be considered invalid 1184 and processing will be stopped. This is clearly a failure to reach 1185 the resource, however it is not a signification issue as RTSP 2.0 1186 support was needed anyway in both server and client. Thus failure 1187 will only occur in a later step when there is a RTSP version mismatch 1188 between client and server. The second change will only occur inside 1189 RTSP message headers, as the request URI must be an absolute URI. 1190 Thus such usages are occurring after agents has accepted processing 1191 RTSP 2.0 messages, and an RTSP 1.0 only agent will not be required to 1192 parse such types of relative URIs. 1194 This specification also defines the format of the RTSP IRI [RFC3987] 1195 that can be used as RTSP resource identifiers and locators, in web 1196 pages, user interfaces, on paper, etc. However, the RTSP request 1197 message format only allows usage of the absolute URI format. The 1198 RTSP IRI format MUST use the rules and transformation for IRIs to 1199 URIs, as defined in [RFC3987]. This allows a URI that matches the 1200 RTSP 2.0 specification, and so is suitable for use in a request, to 1201 be created from an RTSP IRI. 1203 The RTSP IRI and URI are both syntax restricted compared to the 1204 generic syntax defined in [RFC3986] and [RFC3987]: 1206 o An absolute URI requires the authority part; i.e., a host identity 1207 MUST be provided. 1209 o Parameters in the path element are prefixed with the reserved 1210 separator ";". 1212 The RTSP URI and IRI are case sensitive, with the exception of those 1213 parts that [RFC3986] and [RFC3987] define as case-insensitive; for 1214 example, the scheme and host part. 1216 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1217 [RFC3986], i.e., the fragment is to be stripped from the IRI by the 1218 requester and not included in the request URI. The user agent needs 1219 to interpret the value of the fragment based on the media type the 1220 request relates to; i.e., the media type indicated in Content-Type 1221 header in the response to DESCRIBE. 1223 The syntax of any URI query string is unspecified and responder 1224 (usually the server) specific. The query is, from the requester's 1225 perspective, an opaque string and needs to be handled as such. 1226 Please note that relative URI with queries are difficult to handle 1227 due to the RFC 3986 relative URI handling rules. Any change of the 1228 path element using a relative URI results in the stripping of the 1229 query, which means the relative part needs to contain the query. 1231 The URI scheme "rtsp" requires that commands are issued via a 1232 reliable protocol (within the Internet, TCP), while the scheme 1233 "rtsps" identifies a reliable transport using secure transport (TLS 1234 [RFC5246], see (Section 19). 1236 For the scheme "rtsp", if no port number is provided in the authority 1237 part of the URI, the port number 554 MUST be used. For the scheme 1238 "rtsps", if no port number is provided in the authority part of the 1239 URI port number, the TCP port 322 MUST be used. 1241 A presentation or a stream is identified by a textual media 1242 identifier, using the character set and escape conventions of URIs 1243 [RFC3986]. URIs may refer to a stream or an aggregate of streams; 1244 i.e., a presentation. Accordingly, requests described in 1245 (Section 13) can apply to either the whole presentation or an 1246 individual stream within the presentation. Note that some request 1247 methods can only be applied to streams, not presentations, and vice 1248 versa. 1250 For example, the RTSP URI: 1252 rtsp://media.example.com:554/twister/audiotrack 1254 may identify the audio stream within the presentation "twister", 1255 which can be controlled via RTSP requests issued over a TCP 1256 connection to port 554 of host media.example.com. 1258 Also, the RTSP URI: 1260 rtsp://media.example.com:554/twister 1262 identifies the presentation "twister", which may be composed of audio 1263 and video streams, but could also be something else like a random 1264 media redirector. 1266 This does not imply a standard way to reference streams in URIs. 1267 The presentation description defines the hierarchical 1268 relationships in the presentation and the URIs for the individual 1269 streams. A presentation description may name a stream "a.mov" and 1270 the whole presentation "b.mov". 1272 The path components of the RTSP URI are opaque to the client and do 1273 not imply any particular file system structure for the server. 1275 This decoupling also allows presentation descriptions to be used 1276 with non-RTSP media control protocols simply by replacing the 1277 scheme in the URI. 1279 4.3. Session Identifiers 1281 Session identifiers are strings of length 8-128 characters. A 1282 session identifier MUST be chosen cryptographically random (see 1283 [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, 1284 i.e., approximately 22 characters from a high quality generator (see 1285 Section 21). However, note that the session identifier does not 1286 provide any security against session hijacking unless it is kept 1287 confidential by the client, server and trusted proxies. 1289 4.4. Media Time Formats 1291 RTSP currently supports three different media time formats defined 1292 below. Additional time formats may be specified in the future. 1293 These time formats can be used with the Range header (Section 18.40) 1294 to request playback and specify at which media position protocol 1295 requests actually will or has taken place. They are also used in 1296 description of the media's properties using the Media-Range header 1297 (Section 18.30). The format identifier only are used in Accept- 1298 Ranges header (Section 18.5) to declare supported time formats and 1299 also in the Range header (Section 18.40) to request the time format 1300 used in the response. 1302 4.4.1. SMPTE Relative Timestamps 1304 A Society of Motion Picture and Television Engineers (SMPTE) relative 1305 timestamp expresses time relative to the start of the clip. Relative 1306 timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame- 1307 level access accuracy. The time code has the format 1309 hours:minutes:seconds:frames.subframes, 1311 with the origin at the start of the clip. The default SMPTE format 1312 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1313 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1314 through the use of "smpte-type". For SMPTE 30, the "frames" field in 1315 the time value can assume the values 0 through 29. The difference 1316 between 30 and 29.97 frames per second is handled by dropping the 1317 first two frame indices (values 00 and 01) of every minute, except 1318 every tenth minute. If the frame and the subframe values are zero, 1319 they may be omitted. Subframes are measured in one-hundredth of a 1320 frame. 1322 Examples: 1324 smpte=10:12:33:20- 1325 smpte=10:07:33- 1326 smpte=10:07:00-10:07:33:05.01 1327 smpte-25=10:07:00-10:07:33:05.01 1329 4.4.2. Normal Play Time 1331 Normal play time (NPT) indicates the stream absolute position 1332 relative to the beginning of the presentation, not to be confused 1333 with the Network Time Protocol (NTP) [RFC5905]. The timestamp 1334 consists of two parts: the mandatory first part may be expressed in 1335 either seconds or hours, minutes, and seconds. The optional second 1336 part consists of a decimal point and decimal figures and indicates 1337 fractions of a second. 1339 The beginning of a presentation corresponds to 0.0 seconds. Negative 1340 values are not defined. 1342 The special constant "now" is defined as the current instant of a 1343 live event. It MAY only be used for live events, and MUST NOT be 1344 used for on-demand (i.e., non-live) content. 1346 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1347 the clock the viewer associates with a program. It is often 1348 digitally displayed on a VCR. NPT advances normally when in normal 1349 play mode (scale = 1), advances at a faster rate when in fast scan 1350 forward (high positive scale ratio), decrements when in scan reverse 1351 (negative scale ratio) and is fixed in pause mode. NPT is 1352 (logically) equivalent to SMPTE time codes." 1354 Examples: 1356 npt=123.45-125 1357 npt=12:05:35.3- 1358 npt=now- 1360 The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec 1361 notation is optimized for automatic generation, the npt-hhmmss 1362 notation for consumption by human readers. The "now" constant 1363 allows clients to request to receive the live feed rather than the 1364 stored or time-delayed version. This is needed since neither 1365 absolute time nor zero time are appropriate for this case. 1367 4.4.3. Absolute Time 1369 Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, 1370 using UTC (GMT). Fractions of a second may be indicated. 1372 Example for clock format range request for a starting time of 1373 November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC 1374 playing for 10 min and 5 seconds, a Media-Properties header's "Time- 1375 Limited UTC property for 24th of December 2014 at 15 hours and 00 1376 mins, and a Terminate-Readon headers "time" property for 18th of June 1377 2013 at 16 hours, 12 minutes and 56 seconds: 1379 clock=19961108T143720.25Z-19961108T144725.25Z 1380 Time-Limited=20141224T1500Z 1381 time=20130618T161256Z 1383 4.5. Feature-Tags 1385 Feature-tags are unique identifiers used to designate features in 1386 RTSP. These tags are used in Require (Section 18.43), Proxy-Require 1387 (Section 18.37), Proxy-Supported (Section 18.38), Supported 1388 (Section 18.51) and Unsupported (Section 18.55) header fields. 1390 A feature-tag definition MUST indicate which combination of clients, 1391 servers or proxies it applies to. 1393 The creator of a new RTSP feature-tag should either prefix the 1394 feature-tag with a reverse domain name (e.g., 1395 "com.example.mynewfeature" is an apt name for a feature whose 1396 inventor can be reached at "example.com"), or register the new 1397 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1398 IANA Section 22). 1400 The usage of feature-tags is further described in Section 11 that 1401 deals with capability handling. 1403 4.6. Message Body Tags 1405 Message body tags are opaque strings that are used to compare two 1406 message bodies from the same resource, for example in caches or to 1407 optimize setup after a redirect. Message body tags can be carried in 1408 the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9). 1409 MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]). 1411 A message body tag MUST be unique across all versions of all message 1412 bodies associated with a particular resource. A given message body 1413 tag value MAY be used for message bodies obtained by requests on 1414 different URIs. The use of the same message body tag value in 1415 conjunction with message bodies obtained by requests on different 1416 URIs does not imply the equivalence of those message bodies 1418 Message body tags are used in RTSP to make some methods conditional. 1419 The methods are made conditional through the inclusion of headers; 1420 see "If-Match" (Section 18.24) and "If-None-Match" (Section 18.26). 1421 Note that RTSP message body tags apply to the complete presentation; 1422 i.e., both the presentation description and the individual media 1423 streams. Thus message body tags can be used to verify at setup time 1424 after a redirect that the same session description applies to the 1425 media at the new location using the If-Match header. 1427 4.7. Media Properties 1429 When an RTSP server handles media, it is important to consider the 1430 different properties a media instance for delivery and playback can 1431 have. This specification considers the media properties listed below 1432 in its protocol operations. They are derived from the differences 1433 between a number of supported usages. 1435 On-demand: Media that has a fixed (given) duration that doesn't 1436 change during the life time of the RTSP session and is known at 1437 the time of the creation of the session. It is expected that the 1438 content of the media will not change, even if the representation, 1439 i.e encoding, quality, etc, may change. Generally one can seek, 1440 i.e., request any range, within the media. 1442 Dynamic On-demand: This is a variation of the on-demand case where 1443 external methods are used to manipulate the actual content of the 1444 media setup for the RTSP session. The main example is a content 1445 defined by a playlist. 1447 Live: Live media represents a progressing content stream (such as 1448 broadcast TV) where the duration may or may not be known. It is 1449 not seekable, only the content presently being delivered can be 1450 accessed. 1452 Live with Recording: A Live stream that is combined with a server- 1453 side capability to store and retain the content of the live 1454 session, and allow for random access delivery within the part of 1455 the already recorded content. The actual behavior of the media 1456 stream is very much dependent on the retention policy for the 1457 media stream; either the server will be able to capture the 1458 complete media stream, or it will have a limitation in how much 1459 will be retained. The media range will dynamically change as the 1460 session progress. For servers with a limited amount of storage 1461 available for recording, there will typically be a sliding window 1462 that moves forward while new data is made available and older data 1463 is discarded. 1465 To cover the above usages, the following media properties with 1466 appropriate values are specified: 1468 4.7.1. Random Access and Seeking 1470 Random Access is the ability to specify and get media delivered 1471 starting from any time instant within the content, an operation 1472 called seeking. The Media-Properties header will indicate the 1473 general capability for a media resource to perform random access: 1475 Random-Access: The media is seekable to any out of a large number of 1476 points within the media. Due to media encoding limitations, a 1477 particular point may not be reachable, but seeking to a point 1478 close by is enabled. A floating point number of seconds may be 1479 provided to express the worst case distance between random access 1480 points. 1482 Beginning-Only: Seeking is only possible to the beginning of the 1483 content. 1485 No-seeking: Seeking is not possible at all. 1487 If random access is possible, as indicated by Media-Properties 1488 header, the actual behavior policy when seeking can be controlled 1489 using the Seek-Style header (Section 18.47). 1491 4.7.2. Retention 1493 Media may have different retention policies in place that affect the 1494 operation on media. The following different media retention policies 1495 are envisioned and taken into consideration where applicable: 1497 Unlimited: The media will not be removed as long as the RTSP session 1498 is in existence. 1500 Time-Limited: The media will not be removed before the given 1501 wallclock time. After that time it may or may not be available 1502 any more. 1504 Time-Duration: Each individual unit of the media will be retained 1505 for the specified duration. 1507 4.7.3. Content Modifications 1509 There is also the question of how the content may change over time 1510 for a given media resource: 1512 Immutable: The content of the media will not change, even if the 1513 representation, i.e., encoding, quality, etc., may change. 1515 Dynamic: Between explicit updates the media content will not change, 1516 but the content may change due to external methods or triggers, 1517 such as playlists. 1519 Time-Progressing: As time progresses new content will become 1520 available. If the content also is retained it will become longer 1521 as everything between the start point and the point currently 1522 being made available can be accessed. If the media server uses a 1523 sliding window policy for retention, the start point will also 1524 change as time progresses. 1526 4.7.4. Supported Scale Factors 1528 Content often supports only a limited set or range of scales when 1529 delivering the media.. To enable the client to know what values or 1530 ranges of scale operations that the whole content or the current 1531 position supports, a media properties attribute for this is defined 1532 which contains a list with the values and/or ranges that are 1533 supported. The attribute is named "Scales". It may be updated at 1534 any point in the content due to content consisting of spliced pieces 1535 or content being dynamically updated by out-of-band mechanisms. 1537 4.7.5. Mapping to the Attributes 1539 This section shows examples of how one would map the above usages to 1540 the properties and their values. 1542 On-demand: Random Access: Random-Access=5.0, Content Modifications: 1543 Immutable, Retention: Unlimited or Time-Limited. 1545 Dynamic On-demand: Random Access: Random-Access=3.0, Content 1546 Modifications: Dynamic, Retention: Unlimited or Time-Limited. 1548 Live: Random Access: No-seeking, Content Modifications: Time- 1549 Progressing, Retention: Time-Duration=0.0 1551 Live with Recording: Random Access: Random-Access=3.0, Content 1552 Modifications: Time-Progressing, Retention: Time-Duration=7200.0 1554 5. RTSP Message 1556 RTSP is a text-based protocol and uses the ISO 10646 character set in 1557 UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. 1559 Text-based protocols make it easier to add optional parameters in 1560 a self-describing manner. Since the number of parameters and the 1561 frequency of commands is low, processing efficiency is not a 1562 concern. Text-based protocols, if done carefully, also allow easy 1563 implementation of research prototypes in scripting languages such 1564 as TCL, Visual Basic and Perl. 1566 The ISO 10646 character set avoids character set switching, but is 1567 invisible to the application as long as US-ASCII is being used. This 1568 is also the encoding used for RTCP [RFC3550]. 1570 Requests contain methods, the object the method is operating upon and 1571 parameters to further describe the method. Methods are idempotent 1572 unless otherwise noted. Methods are also designed to require little 1573 or no state maintenance at the media server. 1575 5.1. Message Types 1577 RTSP messages consist of requests from client to server, or server to 1578 client, and responses in the reverse direction. Request (Section 7) 1579 and Response (Section 8) messages use a format based on the generic 1580 message format of RFC 2822 [RFC2822] for transferring bodies (the 1581 payload of the message). Both types of messages consist of a start- 1582 line, zero or more header fields (also known as "headers"), an empty 1583 line (i.e., a line with nothing preceding the CRLF) indicating the 1584 end of the headers, and possibly the data of the message body. The 1585 below ABNF [RFC5234] is for information and the formal message 1586 specification is present in Section 20.2.2. 1588 generic-message = start-line 1589 *(message-header CRLF) 1590 CRLF 1591 [ message-body-data ] 1592 start-line = Request-Line | Status-Line 1594 In the interest of robustness, agents MUST ignore any empty line(s) 1595 received where a Request-Line or Response-Line is expected. In other 1596 words, if the agent is reading the protocol stream at the beginning 1597 of a message and receives a CRLF first, it MUST ignore the CRLF. 1599 5.2. Message Headers 1601 RTSP header fields (see Section 18) include general-header, request- 1602 header, response-header, and message-body header fields. 1604 The order in which header fields with differing field names are 1605 received is not significant. However, it is "good practice" to send 1606 general-header fields first, followed by request-header or response- 1607 header fields, and ending with the Message-body header fields. 1609 Multiple message-header fields with the same field-name MAY be 1610 present in a message if and only if the entire field-value for that 1611 header field is defined as a comma-separated list. It MUST be 1612 possible to combine the multiple header fields into one "field-name: 1613 field-value" pair, without changing the semantics of the message, by 1614 appending each subsequent field-value to the first, each separated by 1615 a comma. The order in which header fields with the same field-name 1616 are received is therefore significant to the interpretation of the 1617 combined field value, and thus a proxy MUST NOT change the order of 1618 these field values when a message is forwarded. 1620 Unknown message headers MUST be ignored (skipping over the header to 1621 the next protocol element, and not causing an error) by a RTSP server 1622 or client. An RTSP Proxy MUST forward unknown message headers. 1623 Message headers defined outside of this specification that are 1624 required to be interpreted by the RTSP agent will need to use feature 1625 tags (Section 4.5) and include them in the appropriate Require 1626 (Section 18.43) or Proxy-Require (Section 18.37) header. 1628 5.3. Message Body 1630 The message body (if any) of an RTSP message is used to carry further 1631 information for a particular resource associated with the request or 1632 response. An example of a message body is a Session Description 1633 Protocol (SDP) message. 1635 The presence of a message body in either a request or a response MUST 1636 be signaled by the inclusion of a Content-Length header (see 1637 Section 18.17) and Content-Type (see Section 18.19). A message body 1638 MUST NOT be included in a request or response if the specification of 1639 the particular method (see Method Definitions (Section 13)) does not 1640 allow sending a message body. In case a message body is received in 1641 a message when not expected the message body data SHOULD be 1642 discarded. This is to allow future extensions to define optional use 1643 of message body. 1645 5.4. Message Length 1647 An RTSP Message that does not contain any message body is terminated 1648 by the first empty line after the header fields (Note: An empty line 1649 is a line with nothing preceding the CRLF.). In RTSP messages that 1650 contain message bodies the empty line is followed by the message 1651 body. The length of that body is determined by the value of the 1652 Content-Length header (Section 18.17). The value in the header 1653 represents the length of the message-body in octets. If this header 1654 field is not present, a value of zero is assumed, i.e., no message 1655 body present in the message. Unlike an HTTP message, an RTSP message 1656 MUST contain a Content-Length header whenever it contains a message 1657 body. Note that RTSP does not support the HTTP/1.1 "chunked" 1658 transfer coding (see [H3.6.1]). 1660 Given the moderate length of presentation descriptions returned, 1661 the server should always be able to determine its length, even if 1662 it is generated dynamically, making the chunked transfer encoding 1663 unnecessary. 1665 6. General Header Fields 1667 General headers are headers that may be used in both requests and 1668 responses. The general headers are listed in Table 1: 1670 +--------------------+--------------------+ 1671 | Header Name | Defined in Section | 1672 +--------------------+--------------------+ 1673 | Accept-Ranges | Section 18.5 | 1674 | | | 1675 | Cache-Control | Section 18.11 | 1676 | | | 1677 | Connection | Section 18.12 | 1678 | | | 1679 | CSeq | Section 18.20 | 1680 | | | 1681 | Date | Section 18.21 | 1682 | | | 1683 | Media-Properties | Section 18.29 | 1684 | | | 1685 | Media-Range | Section 18.30 | 1686 | | | 1687 | Pipelined-Requests | Section 18.33 | 1688 | | | 1689 | Proxy-Supported | Section 18.38 | 1690 | | | 1691 | Range | Section 18.40 | 1692 | | | 1693 | RTP-Info | Section 18.45 | 1694 | | | 1695 | Scale | Section 18.46 | 1696 | | | 1697 | Seek-Style | Section 18.47 | 1698 | | | 1699 | Server | Section 18.48 | 1700 | | | 1701 | Session | Section 18.49 | 1702 | | | 1703 | Speed | Section 18.50 | 1704 | | | 1705 | Supported | Section 18.51 | 1706 | | | 1707 | Timestamp | Section 18.53 | 1708 | | | 1709 | Transport | Section 18.54 | 1710 | | | 1711 | User-Agent | Section 18.56 | 1712 | | | 1713 | Via | Section 18.57 | 1714 +--------------------+--------------------+ 1716 Table 1: The general headers used in RTSP 1718 7. Request 1720 A request message uses the format outlined below regardless of the 1721 direction of a request, client to server or server to client: 1723 o Request line, containing the method to be applied to the resource, 1724 the identifier of the resource, and the protocol version in use; 1726 o Zero or more Header lines, that can be of the following types: 1727 general headers (Section 6), request headers (Section 7.2), or 1728 message body headers (Section 9.1); 1730 o One empty line (CRLF) to indicate the end of the header section; 1732 o Optionally a message-body, consisting of one or more lines. The 1733 length of the message body in octets is indicated by the Content- 1734 Length message header. 1736 7.1. Request Line 1738 The request line provides the key information about the request: what 1739 method, on what resources and using which RTSP version. The methods 1740 that are defined by this specification are listed in Table 2. 1742 +---------------+--------------------+ 1743 | Method | Defined in Section | 1744 +---------------+--------------------+ 1745 | DESCRIBE | Section 13.2 | 1746 | | | 1747 | GET_PARAMETER | Section 13.8 | 1748 | | | 1749 | OPTIONS | Section 13.1 | 1750 | | | 1751 | PAUSE | Section 13.6 | 1752 | | | 1753 | PLAY | Section 13.4 | 1754 | | | 1755 | PLAY_NOTIFY | Section 13.5 | 1756 | | | 1757 | REDIRECT | Section 13.10 | 1758 | | | 1759 | SETUP | Section 13.3 | 1760 | | | 1761 | SET_PARAMETER | Section 13.9 | 1762 | | | 1763 | TEARDOWN | Section 13.7 | 1764 +---------------+--------------------+ 1766 Table 2: The RTSP Methods 1768 The syntax of the RTSP request line is the following: 1770 SP SP CRLF 1772 Note: This syntax cannot be freely changed in future versions of 1773 RTSP. This line needs to remain parsable by older RTSP 1774 implementations since it indicates the RTSP version of the message. 1776 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1777 resource through an absolute RTSP URI (including scheme, host, and 1778 port) (see Section 4.2) rather than just the absolute path. 1780 HTTP/1.1 requires servers to understand the absolute URI, but 1781 clients are supposed to use the Host request header. This is 1782 purely needed for backward-compatibility with HTTP/1.0 servers, a 1783 consideration that does not apply to RTSP. 1785 An asterisk "*" can be used instead of an absolute URI in the 1786 Request-URI part to indicate that the request does not apply to a 1787 particular resource, but to the server or proxy itself, and is only 1788 allowed when the request method does not necessarily apply to a 1789 resource. 1791 For example: 1793 OPTIONS * RTSP/2.0 1795 An OPTIONS in this form will determine the capabilities of the server 1796 or the proxy that first receives the request. If the capability of 1797 the specific server needs to be determined, without regard to the 1798 capability of an intervening proxy, the server should be addressed 1799 explicitly with an absolute URI that contains the server's address. 1801 For example: 1803 OPTIONS rtsp://example.com RTSP/2.0 1805 7.2. Request Header Fields 1807 The RTSP headers in Table 3 can be included in a request, as request 1808 headers, to modify the specifics of the request. 1810 +---------------------+--------------------+ 1811 | Header | Defined in Section | 1812 +---------------------+--------------------+ 1813 | Accept | Section 18.1 | 1814 | | | 1815 | Accept-Credentials | Section 18.2 | 1816 | | | 1817 | Accept-Encoding | Section 18.3 | 1818 | | | 1819 | Accept-Language | Section 18.4 | 1820 | | | 1821 | Authorization | Section 18.8 | 1822 | | | 1823 | Bandwidth | Section 18.9 | 1824 | | | 1825 | Blocksize | Section 18.10 | 1826 | | | 1827 | From | Section 18.23 | 1828 | | | 1829 | If-Match | Section 18.24 | 1830 | | | 1831 | If-Modified-Since | Section 18.25 | 1832 | | | 1833 | If-None-Match | Section 18.26 | 1834 | | | 1835 | Notify-Reason | Section 18.32 | 1836 | | | 1837 | Proxy-Authorization | Section 18.36 | 1838 | | | 1839 | Proxy-Require | Section 18.37 | 1840 | | | 1841 | Referrer | Section 18.41 | 1842 | | | 1843 | Request-Status | Section 18.42 | 1844 | | | 1845 | Require | Section 18.43 | 1846 | | | 1847 | Terminate-Reason | Section 18.52 | 1848 +---------------------+--------------------+ 1850 Table 3: The RTSP request headers 1852 Detailed header definitions are provided in Section 18. 1854 New request headers may be defined. If the receiver of the request 1855 is required to understand the request header, the request MUST 1856 include a corresponding feature tag in a Require or Proxy-Require 1857 header to ensure the processing of the header. 1859 8. Response 1861 After receiving and interpreting a request message, the recipient 1862 responds with an RTSP response message. Normally, there is only one, 1863 final, response. Only responses using the response code class 1xx, 1864 are allowed to send one or more 1xx response messages prior to the 1865 final response message. 1867 The valid response codes and the methods they can be used with are 1868 listed in Table 4. 1870 8.1. Status-Line 1872 The first line of a Response message is the Status-Line, consisting 1873 of the protocol version followed by a numeric status code and the 1874 textual phrase associated with the status code, with each element 1875 separated by SP characters. No CR or LF is allowed except in the 1876 final CRLF sequence. 1878 SP SP CRLF 1880 8.1.1. Status Code and Reason Phrase 1882 The Status-Code element is a 3-digit integer result code of the 1883 attempt to understand and satisfy the request. These codes are fully 1884 defined in Section 17. The Reason-Phrase is intended to give a short 1885 textual description of the Status-Code. The Status-Code is intended 1886 for use by automata and the Reason-Phrase is intended for the human 1887 user. The client is not required to examine or display the Reason- 1888 Phrase. 1890 The first digit of the Status-Code defines the class of response. 1891 The last two digits do not have any categorization role. There are 5 1892 values for the first digit: 1894 1xx: Informational - Request received, continuing process 1896 2xx: Success - The action was successfully received, understood, and 1897 accepted 1899 3rr: Redirection - Further action needs to be taken in order to 1900 complete the request (3rr rather than 3xx is used as 304 is 1901 excluded, see Section 17.3) 1903 4xx: Client Error - The request contains bad syntax or cannot be 1904 fulfilled 1906 5xx: Server Error - The server failed to fulfill an apparently valid 1907 request 1909 The individual values of the numeric status codes defined for 1910 RTSP/2.0, and an example set of corresponding Reason-Phrases, are 1911 presented in Table 4. The reason phrases listed here are only 1912 recommended; they may be replaced by local equivalents without 1913 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1914 [RFC2616] status codes and adds RTSP-specific status codes starting 1915 at x50 to avoid conflicts with future HTTP status codes that are 1916 desirable to import into RTSP. All these codes are RTSP specific and 1917 RTSP has its own registry separate from HTTP for status codes. 1919 RTSP status codes are extensible. RTSP applications are not required 1920 to understand the meaning of all registered status codes, though such 1921 understanding is obviously desirable. However, applications MUST 1922 understand the class of any status code, as indicated by the first 1923 digit, and treat any unrecognized response as being equivalent to the 1924 x00 status code of that class, with an exception for unknown 3xx 1925 codes, which MUST be treated as a 302 (Found). The reason being that 1926 no 300 (Multiple Choices in HTTP) is defined for RTSP. An response 1927 with unrecognized status code MUST NOT be cached. For example, if an 1928 unrecognized status code of 431 is received by the client, it can 1929 safely assume that there was something wrong with its request and 1930 treat the response as if it had received a 400 status code. In such 1931 cases, user agents SHOULD present to the user the message body 1932 returned with the response, since that message body is likely to 1933 include human-readable information which will explain the unusual 1934 status. 1936 +------+---------------------------------+--------------------------+ 1937 | Code | Reason | Method | 1938 +------+---------------------------------+--------------------------+ 1939 | 100 | Continue | all | 1940 | | | | 1941 | | | | 1942 | 200 | OK | all | 1943 | | | | 1944 | | | | 1945 | 301 | Moved Permanently | all | 1946 | | | | 1947 | 302 | Found | all | 1948 | | | | 1949 | 303 | reserved | n/a | 1950 | | | | 1951 | 304 | Not Modified | all | 1952 | | | | 1953 | 305 | Use Proxy | all | 1954 | 400 | Bad Request | all | 1955 | | | | 1956 | 401 | Unauthorized | all | 1957 | | | | 1958 | 402 | Payment Required | all | 1959 | | | | 1960 | 403 | Forbidden | all | 1961 | | | | 1962 | 404 | Not Found | all | 1963 | | | | 1964 | 405 | Method Not Allowed | all | 1965 | | | | 1966 | 406 | Not Acceptable | all | 1967 | | | | 1968 | 407 | Proxy Authentication Required | all | 1969 | | | | 1970 | 408 | Request Timeout | all | 1971 | | | | 1972 | 410 | Gone | all | 1973 | | | | 1974 | 412 | Precondition Failed | DESCRIBE, SETUP | 1975 | | | | 1976 | 413 | Request Message Body Too Large | all | 1977 | | | | 1978 | 414 | Request-URI Too Long | all | 1979 | | | | 1980 | 415 | Unsupported Media Type | all | 1981 | | | | 1982 | 451 | Parameter Not Understood | SET_PARAMETER, | 1983 | | | GET_PARAMETER | 1984 | | | | 1985 | 452 | reserved | n/a | 1986 | | | | 1987 | 453 | Not Enough Bandwidth | SETUP | 1988 | | | | 1989 | 454 | Session Not Found | all | 1990 | | | | 1991 | 455 | Method Not Valid In This State | all | 1992 | | | | 1993 | 456 | Header Field Not Valid | all | 1994 | | | | 1995 | 457 | Invalid Range | PLAY, PAUSE | 1996 | | | | 1997 | 458 | Parameter Is Read-Only | SET_PARAMETER | 1998 | | | | 1999 | 459 | Aggregate Operation Not Allowed | all | 2000 | | | | 2001 | 460 | Only Aggregate Operation | all | 2002 | | Allowed | | 2003 | | | | 2004 | 461 | Unsupported Transport | all | 2005 | | | | 2006 | 462 | Destination Unreachable | all | 2007 | | | | 2008 | 463 | Destination Prohibited | SETUP | 2009 | | | | 2010 | 464 | Data Transport Not Ready Yet | PLAY | 2011 | | | | 2012 | 465 | Notification Reason Unknown | PLAY_NOTIFY | 2013 | | | | 2014 | 466 | Key Management Error | all | 2015 | | | | 2016 | 470 | Connection Authorization | all | 2017 | | Required | | 2018 | | | | 2019 | 471 | Connection Credentials not | all | 2020 | | accepted | | 2021 | | | | 2022 | 472 | Failure to establish secure | all | 2023 | | connection | | 2024 | | | | 2025 | | | | 2026 | 500 | Internal Server Error | all | 2027 | | | | 2028 | 501 | Not Implemented | all | 2029 | | | | 2030 | 502 | Bad Gateway | all | 2031 | | | | 2032 | 503 | Service Unavailable | all | 2033 | | | | 2034 | 504 | Gateway Timeout | all | 2035 | | | | 2036 | 505 | RTSP Version Not Supported | all | 2037 | | | | 2038 | 551 | Option Not Supported | all | 2039 | | | | 2040 | 553 | Proxy Unavailable | all | 2041 +------+---------------------------------+--------------------------+ 2043 Table 4: Status codes and their usage with RTSP methods 2045 8.2. Response Headers 2047 The response-headers allow the request recipient to pass additional 2048 information about the response which cannot be placed in the Status- 2049 Line. This header gives information about the server and about 2050 further access to the resource identified by the Request-URI. All 2051 headers currently classified as response headers are listed in 2052 Table 5. 2054 +------------------------+--------------------+ 2055 | Header | Defined in Section | 2056 +------------------------+--------------------+ 2057 | Authentication-Info | Section 18.7 | 2058 | | | 2059 | Connection-Credentials | Section 18.13 | 2060 | | | 2061 | Location | Section 18.28 | 2062 | | | 2063 | MTag | Section 18.31 | 2064 | | | 2065 | Proxy-Authenticate | Section 18.34 | 2066 | | | 2067 | Public | Section 18.39 | 2068 | | | 2069 | Retry-After | Section 18.44 | 2070 | | | 2071 | Unsupported | Section 18.55 | 2072 | | | 2073 | WWW-Authenticate | Section 18.58 | 2074 +------------------------+--------------------+ 2076 Table 5: The RTSP response headers 2078 Response-header names can be extended reliably only in combination 2079 with a change in the protocol version. However, the usage of 2080 feature-tags in the request allows the responding party to learn the 2081 capability of the receiver of the response. A new or experimental 2082 header MAY be given the semantics of response-header if all parties 2083 in the communication recognize them to be a response-header. 2084 Unrecognized headers in responses are treated as message-headers and 2085 hence MUST be ignored. 2087 9. Message Body 2089 Request and Response messages MAY transfer a message body, if not 2090 otherwise restricted by the request method or response status code. 2091 The message body consists of the content data itself (see also 2092 Section 5.3). 2094 The SET_PARAMETER and GET_PARAMETER requests and responses, and the 2095 DESCRIBE response as defined by this specification MAY have a message 2096 body; the purpose of the message body is defined in each case. All 2097 4xx and 5xx responses MAY also have a message body to carry 2098 additional response information. Generally a message body MAY be 2099 attached to any RTSP 2.0 request or response, but the content of the 2100 message body MAY be ignored by the receiver. Extensions to this 2101 specification can specify the purpose and content of message bodies, 2102 including requiring their inclusion. 2104 In this section, both sender and recipient refer to either the client 2105 or the server, depending on who sends and who receives the message 2106 body. 2108 9.1. Message-Body Header Fields 2110 Message-body header fields define meta-information about the content 2111 data in the message body. The message-body header fields are listed 2112 in Table 6. 2114 +------------------+--------------------+ 2115 | Header | Defined in Section | 2116 +------------------+--------------------+ 2117 | Allow | Section 18.6 | 2118 | | | 2119 | Content-Base | Section 18.14 | 2120 | | | 2121 | Content-Encoding | Section 18.15 | 2122 | | | 2123 | Content-Language | Section 18.16 | 2124 | | | 2125 | Content-Length | Section 18.17 | 2126 | | | 2127 | Content-Location | Section 18.18 | 2128 | | | 2129 | Content-Type | Section 18.19 | 2130 | | | 2131 | Expires | Section 18.22 | 2132 | | | 2133 | Last-Modified | Section 18.27 | 2134 +------------------+--------------------+ 2136 Table 6: The RTSP message-body headers 2138 The extension-header mechanism allows additional message-body header 2139 fields to be defined without changing the protocol, but these fields 2140 cannot be assumed to be recognizable by the recipient. Unrecognized 2141 header fields MUST be ignored by the recipient and forwarded by 2142 proxies. 2144 9.2. Message Body 2146 An RTSP message with a message body MUST include the Content-Type and 2147 Content-Length headers. When a message body is included with a 2148 message, the data type of that content data is determined via the 2149 header fields Content-Type and Content-Encoding. 2151 Content-Type specifies the media type of the underlying data. 2152 Content-Encoding may be used to indicate any additional content 2153 codings applied to the data, usually for the purpose of data 2154 compression, that are a property of the requested resource. There is 2155 no default encoding. 2157 The Content-Length of a message is the length of the content, 2158 measured in octets. 2160 9.3. Message Body Format Negotiation 2162 The content format of the message body is provided using the Content- 2163 Type header (Section 18.19). To enable the responder of a request to 2164 determine which media type it should use, the requestor may include 2165 the Accept header (Section 18.1) in a request to identify supported 2166 media types or media type ranges suitable to the response. In cases 2167 the responder is not supporting any of the specified formats, then 2168 the request response will be a 406 (Not Acceptable) error code. 2170 The media types that may be used on requests with message bodies 2171 needs to be determined through the use of feature-tags, specification 2172 requirement or trial and error. Trial and error works in the regards 2173 that in case the responder is not supporting the media type of the 2174 message body it will respond with a 415 (Unsupported Media Type). 2176 The formats supported and their negotiation is done individually on a 2177 per method and direction (request or response body) direction. 2178 Requirements on supporting particular media types for use as message 2179 bodies in requests and response SHALL also be specified on per method 2180 and direction basis. 2182 10. Connections 2184 RTSP Messages are transferred between RTSP agents and proxies using a 2185 transport connection. This transport connection uses TCP or TCP/TLS. 2186 This transport connection is referred to as the connection or 2187 possibly RTSP connection within this document. 2189 RTSP requests can be transmitted using the two different connection 2190 scenarios listed below: 2192 o persistent - a transport connection is used for several request/ 2193 response transactions; 2195 o transient - a transport connection is used for a single request/ 2196 response transaction. 2198 RFC 2326 attempted to specify an optional mechanism for transmitting 2199 RTSP messages in connectionless mode over a transport protocol such 2200 as UDP. However, it was not specified in sufficient detail to allow 2201 for interoperable implementations. In an attempt to reduce 2202 complexity and scope, and due to lack of interest, RTSP 2.0 does not 2203 attempt to define a mechanism for supporting RTSP over UDP or other 2204 connectionless transport protocols. A side-effect of this is that 2205 RTSP requests MUST NOT be sent to multicast groups since no 2206 connection can be established with a specific receiver in multicast 2207 environments. 2209 Certain RTSP headers, such as the CSeq header (Section 18.20), which 2210 may appear to be relevant only to connectionless transport scenarios 2211 are still retained and MUST be implemented according to the 2212 specification. In the case of CSeq, it is quite useful for matching 2213 responses to requests if the requests are pipelined (see Section 12). 2214 It is also useful in proxies for keeping track of the different 2215 requests when aggregating several client requests on a single TCP 2216 connection. 2218 10.1. Reliability and Acknowledgements 2220 Since RTSP messages are transmitted using reliable transport 2221 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 2222 Instead, the implementation must rely on the underlying transport to 2223 provide reliability. The RTSP implementation may use any indication 2224 of reception acknowledgment of the message from the underlying 2225 transport protocols to optimize the RTSP behavior. 2227 If both the underlying reliable transport such as TCP and the RTSP 2228 application retransmit requests, each packet loss or message loss 2229 may result in two retransmissions. The receiver typically cannot 2230 take advantage of the application-layer retransmission since the 2231 transport stack will not deliver the application-layer 2232 retransmission before the first attempt has reached the receiver. 2233 If the packet loss is caused by congestion, multiple 2234 retransmissions at different layers will exacerbate the 2235 congestion. 2237 Lack of acknowledgment of an RTSP request should be handled within 2238 the constraints of the connection timeout considerations described 2239 below (Section 10.4). 2241 10.2. Using Connections 2243 A TCP transport can be used for both persistent connections (for 2244 several message exchanges) and transient connections (for a single 2245 message exchange). Implementations of this specification MUST 2246 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 2247 indicates the default port that the server will listen on if the port 2248 is not explicitly given. 2250 In addition to the registered default ports, i.e., 554 (rtsp) and 322 2251 (rtsps), there is an alternative port 8554 registered. This port may 2252 provide some benefits from non-registered ports if a RTSP server is 2253 unable to use the default ports. The benefits may include pre- 2254 configured security policies as well as classifiers in network 2255 monitoring tools. 2257 A RTSP client opening a TCP connection for accessing a particular 2258 resource as identified by a URI uses the IP address and port derived 2259 from the host and port parts of the URI. The IP address is either 2260 the explicit address provided in the URI or any of the addresses 2261 provided when performing A and AAAA record DNS lookups of the host 2262 name in the URI. 2264 A server MUST handle both persistent and transient connections. 2266 Transient connections facilitate mechanisms for fault tolerance. 2267 They also allow for application layer mobility. A server and 2268 client pair that support transient connections can survive the 2269 loss of a TCP connection; e.g., due to a NAT timeout. When the 2270 client has discovered that the TCP connection has been lost, it 2271 can set up a new one when there is need to communicate again. 2273 A persistent connection is RECOMMENDED to be used for all 2274 transactions between the server and client, including messages for 2275 multiple RTSP sessions. However, a persistent connection MAY be 2276 closed after a few message exchanges. For example, a client may use 2277 a persistent connection for the initial SETUP and PLAY message 2278 exchanges in a session and then close the connection. Later, when 2279 the client wishes to send a new request, such as a PAUSE for the 2280 session, a new connection would be opened. This connection may 2281 either be transient or persistent. 2283 An RTSP agent MAY use one connection to handle multiple RTSP sessions 2284 on the same server. The RTSP agent SHALL NOT use more than one 2285 connection per RTSP session at any given point. 2287 Using a single connection for multiple RTSP session saves 2288 connection resources on the server. Not using more than one 2289 connection at a time for a particular RTSP session avoids wasting 2290 connection resources and allows the server to track only for the 2291 latest in client to server used connection for each RTSP session 2292 as being the currently valid server to client connection. 2294 RTSP allows a server to send requests to a client. However, this can 2295 be supported only if a client establishes a persistent connection 2296 with the server. In cases where a persistent connection does not 2297 exist between a server and its client, due to the lack of a signaling 2298 channel the server may be forced to silently discard RTSP messages, 2299 and may even drop an RTSP session without notifying the client. An 2300 example of such a case is when the server desires to send a REDIRECT 2301 request for an RTSP session to the client but is not able to do so 2302 because it cannot reach the client. A server that attempts to send a 2303 request to a client that has no connection currently to the server 2304 SHALL discard the request directly. 2306 Without a persistent connection between the client and the server, 2307 the media server has no reliable way of reaching the client. 2308 Because the likely failure of server to client established 2309 connections the server will not even attempt establishing any 2310 connection. 2312 Queuing of server to client requests has been considered. However 2313 a security issue exist in how one authorizes a client establishing 2314 a new connection as being a legit receiver of request related to a 2315 particular RTSP session without the client first issuing requests 2316 related to the request. Thus, likely making any such requests 2317 even more delayed and less useful. 2319 The sending of client and server requests can be asynchronous events. 2320 To avoid deadlock situations both client and server MUST be able to 2321 send and receive requests simultaneously. As an RTSP response may be 2322 queued up for transmission, reception or processing behind the peer 2323 RTSP agent's own requests, all RTSP agents are required to have a 2324 certain capability of handling outstanding messages. A potential 2325 issue is that outstanding requests may timeout despite them being 2326 processed by the peer due to the response being caught in the queue 2327 behind a number of requests that the RTSP agent is processing but 2328 that take some time to complete. To avoid this problem an RTSP agent 2329 is recommended to buffer incoming messages locally so that any 2330 response messages can be processed immediately upon reception. If 2331 responses are separated from requests and directly forwarded for 2332 processing, not only can the result be used immediately, the state 2333 associated with that outstanding request can also be released. 2334 However, buffering a number of requests on the receiving RTSP agent 2335 consumes resources and enables a resource exhaustion attack on the 2336 agent. Therefore this buffer should be limited so that an 2337 unreasonable number of requests or total message size is not allowed 2338 to consume the receiving agent's resources. In most APIs, having the 2339 receiving agent stop reading from the TCP socket will result in TCP's 2340 window being clamped. Thus forcing the buffering onto the sending 2341 agent when the load is larger than expected. However, as both RTSP 2342 message sizes and frequency may be changed in the future by protocol 2343 extensions, an agent should be careful against taking harsher 2344 measurements against a potential attack. When under attack an RTSP 2345 agent can close TCP connections and release state associated with 2346 that TCP connection. 2348 To provide some guidance on what is reasonable the following 2349 guidelines are given. It is RECOMMENDED that: 2351 o an RTSP agent should not have more than 10 outstanding requests 2352 per RTSP session; 2354 o an RTSP agent should not have more than 10 outstanding requests 2355 that are not related to an RTSP session or that are requesting to 2356 create an RTSP session. 2358 In light of the above, it is RECOMMENDED that clients use persistent 2359 connections whenever possible. A client that supports persistent 2360 connections MAY "pipeline" its requests (see Section 12). 2362 RTSP Agents can send requests to multiple different destinations, 2363 either servers or client contexts over the same connection to a 2364 proxy. Then the proxy forks the message to the different 2365 destinations over proxy to agent connections. In these cases when 2366 multiple requests are outstanding the requesting agent MUST be ready 2367 to receive the responses out of order compared to the order they 2368 where sent on the connection. The order between multiple messages 2369 for each destination will be maintained, however, the order between 2370 response from different destinations can be different. 2372 The reason for this is to avoid a head of line blocking. In a 2373 sequence of request an early outstanding request may take time to 2374 be processed at one destination. Simultaneously a responses from 2375 any other destinations, that was later in the sequence of requests 2376 may have arrived at the proxy. Thus allowing out-of-order 2377 responses avoid forcing the proxy to buffer this response and 2378 instead deliver it as soon as possible. Note, this will not 2379 affect the order they where processed at request destination. 2381 This scenario can occur in two cases involving proxies. The first is 2382 a client issuing requests for sessions on different servers using a 2383 common client to proxy connection. The second is for server to 2384 client requests, like REDIRECT being sent by the server over a common 2385 transport connection the proxy created for its different connecting 2386 clients. 2388 10.3. Closing Connections 2390 The client MAY close a connection at any point when no outstanding 2391 request/response transactions exist for any RTSP session being 2392 managed through the connection. The server, however, SHOULD NOT 2393 close a connection until all RTSP sessions being managed through the 2394 connection have been timed out (Section 18.49). A server SHOULD NOT 2395 close a connection immediately after responding to a session-level 2396 TEARDOWN request for the last RTSP session being controlled through 2397 the connection. Instead, the server should wait for a reasonable 2398 amount of time for the client to receive and act upon the TEARDOWN 2399 response, and initiate the connection closing. The server SHOULD 2400 wait at least 10 seconds after sending the TEARDOWN response before 2401 closing the connection. 2403 This is to ensure that the client has time to issue a SETUP for a 2404 new session on the existing connection after having torn the last 2405 one down. 10 seconds should give the client ample opportunity to 2406 get its message to the server. 2408 A server SHOULD NOT close the connection directly as a result of 2409 responding to a request with an error code. 2411 Certain error responses such as "460 Only Aggregate Operation 2412 Allowed" (Section 17.4.24) are used for negotiating capabilities 2413 of a server with respect to content or other factors. In such 2414 cases, it is inefficient for the server to close a connection on 2415 an error response. Also, such behavior would prevent 2416 implementation of advanced/special types of requests or result in 2417 extra overhead for the client when testing for new features. On 2418 the other hand, keeping connections open after sending an error 2419 response poses a Denial of Service security risk (Section 21). 2421 The server MAY close a connection if it receives an incomplete 2422 message and if the message is not completed within a reasonable 2423 amount of time. It is RECOMMENDED that the server waits at least 10 2424 seconds for the completion of a message or for the next part of the 2425 message to arrive (which is an indication that the transport and the 2426 client are still alive). Servers believing they are under attack or 2427 otherwise starved for resources during that event MAY consider using 2428 a shorter timeout. 2430 If a server closes a connection while the client is attempting to 2431 send a new request, the client will have to close its current 2432 connection, establish a new connection and send its request over the 2433 new connection. 2435 An RTSP message SHOULD NOT be terminated by closing the connection. 2436 Such a message MAY be considered to be incomplete by the receiver and 2437 discarded. An RTSP message is properly terminated as defined in 2438 Section 5. 2440 10.4. Timing Out Connections and RTSP Messages 2442 Receivers of a request (responder) SHOULD respond to requests in a 2443 timely manner even when a reliable transport such as TCP is used. 2444 Similarly, the sender of a request (requester) SHOULD wait for a 2445 sufficient time for a response before concluding that the responder 2446 will not be acting upon its request. 2448 A responder SHOULD respond to all requests within 5 seconds. If the 2449 responder recognizes that processing of a request will take longer 2450 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 2451 possible. It SHOULD continue sending a 100 response every 5 seconds 2452 thereafter until it is ready to send the final response to the 2453 requester. After sending a 100 response, the receiver MUST send a 2454 final response indicating the success or failure of the request. 2456 A requester SHOULD wait at least 10 seconds for a response before 2457 concluding that the responder will not be responding to its request. 2458 After receiving a 100 response, the requester SHOULD continue waiting 2459 for further responses. If more than 10 seconds elapses without 2460 receiving any response, the requester MAY assume that the responder 2461 is unresponsive and abort the connection by closing the TCP 2462 connection. 2464 Note: In cases multiple RTSP sessions share the same transport 2465 connection, abandoning a request closing the connection may have 2466 significant impact on those other sessions. First of all, other 2467 RTSP requests may have become queued up due to the request taking 2468 long time. Secondly also those sessions loose the possibility to 2469 receive server to client requests. To mitigate that situation the 2470 RTSP agent should establish a new connection and send any queued 2471 up and non-responded requests on this new connection. Secondly, 2472 to ensure that the RTSP server knows which connection that is 2473 valid for a particular RTSP session, the RTSP agent should send a 2474 keep-alive request, if no other request will be sent immediately 2475 for that RTSP session, for each RTSP session on the old 2476 connection. The keep-alive request will normally be a 2477 GET_PARAMETER with a session header to inform the server that this 2478 agent cares about this RTSP session. 2480 A requester SHOULD wait longer than 10 seconds for a response if it 2481 is experiencing significant transport delays on its connection to the 2482 responder. The requester is capable of determining the round trip 2483 time (RTT) of the request/response cycle using the Timestamp header 2484 (Section 18.53) in any RTSP request. 2486 10 seconds was chosen for the following reasons. It gives TCP 2487 time to perform a couple of retransmissions, even if operating on 2488 default values. It is short enough that users may not abandon the 2489 process themselves. However, it should be noted that 10 seconds 2490 can be aggressive on certain type of networks. The 5 seconds 2491 value for 1xx messages is half the timeout giving a reasonable 2492 chance of successful delivery before timeout happens on the 2493 requester side. 2495 10.5. Showing Liveness 2497 The mechanisms for showing liveness of the client is, any RTSP 2498 request with a Session header, if RTP & RTCP is used an RTCP message, 2499 or through any other used media protocol capable of indicating 2500 liveness of the RTSP client. It is RECOMMENDED that a client does 2501 not wait to the last second of the timeout before trying to send a 2502 liveness message. The RTSP message may be lost or when using 2503 reliable protocols, such as TCP, the message may take some time to 2504 arrive safely at the receiver. To show liveness between RTSP 2505 requests being issued to accomplish other things, the following 2506 mechanisms can be used, in descending order of preference: 2508 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 2509 RTCP is used to report transport statistics, it will 2510 necessarily also function as a keep-alive. The server can 2511 determine the client by network address and port together with 2512 the fact that the client is reporting on the server's RTP 2513 sender sources (SSRCs). A downside of using RTCP is that it 2514 only gives statistical guarantees of reaching the server. 2515 However, the probability of a false client timeout is so low 2516 that it can be ignored in most cases. For example, assume a 2517 session with 60 seconds timeout and enough bitrate assigned to 2518 RTCP messages to send a message from client to server on 2519 average every 5 seconds. That client has, for a network with 2520 5% packet loss, a probability of failing to confirm liveness 2521 within the timeout interval for that session of 2.4*E-16. 2522 Sessions with shorter timeouts, or much higher packet loss, or 2523 small RTCP bandwidths SHOULD also implement one or more of the 2524 mechanisms below. 2526 SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body 2527 SHOULD NOT be included. This method is the RECOMMENDED RTSP 2528 method to use for a request intended only to perform keep- 2529 alive. Support of SET_PARAMETER is mandatory for RTSP Servers 2530 to ensure clients can use this method. 2532 GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body 2533 SHOULD be included. Dependent on implementation support in 2534 server. 2536 OPTIONS: This method is also usable, but it causes the server to 2537 perform more unnecessary processing and results in bigger 2538 responses than necessary for the task. The reason is that the 2539 server needs to determine the capabilities associated with the 2540 media resource to correctly populate the Public and Allow 2541 headers. 2543 The timeout parameter of the Session header (Section 18.49) MAY be 2544 included in a SETUP response, and MUST NOT be included in requests. 2545 The server uses it to indicate to the client how long the server is 2546 prepared to wait between RTSP commands or other signs of life before 2547 closing the session due to lack of activity (see Appendix B). The 2548 timeout is measured in seconds, with a default of 60 seconds. The 2549 length of the session timeout MUST NOT be changed in an established 2550 session. 2552 10.6. Use of IPv6 2554 Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC 2555 2326). RTSP 2.0 has been updated for explicit IPv6 support. 2556 Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in 2557 URIs and RTSP headers. Although the general URI format envisages 2558 potential future new versions of the literal IP address, usage of any 2559 such new version would require other modifications to the RTSP 2560 specification (e.g. address fields in the Transport header 2561 (Section 18.54)). 2563 10.7. Overload Control 2565 Overload in RTSP can occur when servers and proxies have insufficient 2566 resources to complete the processing of a request. An improper 2567 handling of such an overload situation at proxies and servers can 2568 impact the operation of the RTSP deployment, and probably worsen the 2569 situation. RTSP defines the 503 (Service Unavailable) response 2570 (Section 17.5.4) to let servers and proxies notify requesting proxies 2571 and RTSP clients about an overload situation. In conjunction with 2572 the Retry-After header (Section 18.44) the server or proxy can 2573 indicate the time after the requesting entity can send another 2574 request to the proxy or server. 2576 There are two scopes of such 503 answers, one for established RTSP 2577 sessions, where the request resulting in the 503 response as well as 2578 the response carries a Session header identifying the session which 2579 is suffering overload. This response only applies to this particular 2580 session. The other scope is the general RTSP server as identified by 2581 the host in the request URL. Such a 503 answer with any Retyr-After 2582 header applies to all non-session specific requests to that server, 2583 including SETUP request intended to create a new RTSP session. 2585 Another scope for overload situation exists, which is the RTSP proxy. 2586 To enable an RTSP proxy to signal that it is overloaded, or otherwise 2587 unavailable and can't handle the request, a 553 response code has 2588 been defined with the meaning "Proxy Unavailable". Also for proxies 2589 there is a separation in response scopes between requests associated 2590 with existing RTSP sessions, and requests to create new sessions or 2591 general proxy requests. 2593 Simply implementing and using the 503 (Service Unavailable) and 553 2594 (Proxy Unavailable) is not sufficient for properly handling overload 2595 situations. For instance, a simplistic approach would be to send the 2596 503 response with a Retry-After header set to a fixed value. 2597 However, this can cause the situation where multiple RTSP clients 2598 again send requests to a proxy or server at roughly the same time 2599 which may again cause an overload situation, or if the "old" overload 2600 situation is not yet solved, i.e., the length indicated in the Retry- 2601 After header was too short. 2603 An RTSP server or proxy in an overload situation must select the 2604 value of the Retry-After header carefully and bearing in mind its 2605 current load situation. It is REQUIRED to increase the timeout 2606 period in proportion to the current load on the server, i.e., an 2607 increasing workload should result in an increased length of the 2608 indicated unavailability. It is REQUIRED to not send the same value 2609 in the Retry-After header to all requesting proxies and clients, but 2610 to add a variation to the mean value of the Retry-After header. 2612 A more complex case may arise when a load balancing RTSP proxy is in 2613 use, i.e., where an RTSP proxy is used to select amongst a set of 2614 RTSP servers to handle the requests, or when multiple server 2615 addresses are available for a given server name. The proxy or client 2616 may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) 2617 from one of its RTSP servers or proxies, or a TCP timeout (if the 2618 server is even unable to handle the request message). The proxy or 2619 client simply retries the other addresses or configured proxies, but 2620 may also receive a 503 (Service Unavailable) or 553 (Proxy 2621 Unavailable) response or TCP timeouts from those addresses. In such 2622 a situation, where none of the RTSP servers/proxies/addresses can 2623 handle the request, the RTSP agent has to wait before it can send any 2624 new requests to the RTSP server. Any additional request to a 2625 specific address MUST be delayed according to the Retry-After headers 2626 received. For addresses where no response was received or TCP 2627 timeout occurred, an initial wait timer SHOULD be set to 5 seconds. 2628 That timer MUST be doubled for each additional failure to connect or 2629 receive response until the value exceeds 30 minutes when the timers 2630 mean value may be set to 30 minutes. It is REQUIRED to not set the 2631 same value in the timer for each scheduling, but instead to add a 2632 variation to the mean value, resulting in picking a random value 2633 within the range of 0.5 to 1.5 of the mean value. 2635 11. Capability Handling 2637 This section describes the available capability handling mechanism 2638 which allows RTSP to be extended. Extensions to this version of the 2639 protocol are basically done in two ways. First, new headers can be 2640 added. Secondly, new methods can be added. The capability handling 2641 mechanism is designed to handle both cases. 2643 When a method is added, the involved parties can use the OPTIONS 2644 method to discover whether it is supported. This is done by issuing 2645 an OPTIONS request to the other party. Depending on the URI it will 2646 either apply in regards to a certain media resource, the whole server 2647 in general, or simply the next hop. The OPTIONS response MUST 2648 contain a Public header which declares all methods supported for the 2649 indicated resource. 2651 It is not necessary to use OPTIONS to discover support of a method, 2652 as the client could simply try the method. If the receiver of the 2653 request does not support the method it will respond with an error 2654 code indicating the method is either not implemented (501) or does 2655 not apply for the resource (405). The choice between the two 2656 discovery methods depends on the requirements of the service. 2658 Feature-tags are defined to handle functionality additions that are 2659 not new methods. Each feature-tag represents a certain block of 2660 functionality. The amount of functionality that a feature-tag 2661 represents can vary significantly. A feature-tag can for example 2662 represent the functionality a single RTSP header provides. Another 2663 feature-tag can represent much more functionality, such as the 2664 "play.basic" feature-tag (Section 11.1) which represents the minimal 2665 media delivery for playback implementation. 2667 Feature-tags are used to determine whether the client, server or 2668 proxy supports the functionality that is necessary to achieve the 2669 desired service. To determine support of a feature-tag, several 2670 different headers can be used, each explained below: 2672 Supported: This header is used to determine the complete set of 2673 functionality that both client and server have in general and 2674 is not dependent on specific resource. The intended usage is 2675 to determine before one needs to use a functionality that it is 2676 supported. It can be used in any method, but OPTIONS is the 2677 most suitable one as it at the same time determines all methods 2678 that are implemented. When sending a request the requester 2679 declares all its capabilities by including all supported 2680 feature-tags. This results in the receiver is learning the 2681 requester's feature support. The receiver then includes its 2682 set of features in the response. 2684 Proxy-Supported: This header is used similarly to the Supported 2685 header, but instead of giving the supported functionality of 2686 the client or server it provides both the requester and the 2687 responder a view of the common functionality supported in 2688 general by all members of the proxy chain between the two 2689 supports and not dependent on the resource. Proxies are 2690 required to add this header whenever the Supported header is 2691 present, but proxies may also add it independently of the 2692 requester. 2694 Require: This header can be included in any request where the end- 2695 point, i.e., the client or server, is required to understand 2696 the feature to correctly perform the request. This can, for 2697 example, be a SETUP request where the server is required to 2698 understand a certain parameter to be able to set up the media 2699 delivery correctly. Ignoring this parameter would not have the 2700 desired effect and is not acceptable. Therefore the end-point 2701 receiving a request containing a Require MUST negatively 2702 acknowledge any feature that it does not understand and not 2703 perform the request. The response in cases where features are 2704 not supported are 551 (Option Not Supported). Also the 2705 features that are not supported are given in the Unsupported 2706 header in the response. 2708 Proxy-Require: This header has the same purpose and workings as 2709 Require except that it only applies to proxies and not the end- 2710 point. Features that need to be supported by both proxies and 2711 end-points need to be included in both the Require and Proxy- 2712 Require header. 2714 Unsupported: This header is used in a 551 error response, to 2715 indicate which features were not supported. Such a response is 2716 only the result of the usage of the Require and/or Proxy- 2717 Require header where one or more features where not supported. 2718 This information allows the requester to make the best of 2719 situations as it knows which features are not supported. 2721 11.1. Feature Tag: play.basic 2723 The play.basic feature tag represents an RTSP implementation 2724 according to all normative RTSP protocol features specified in this 2725 specification. This specification is both a RTSP core specification 2726 as well intended to enable setup and control of playback of media. 2727 Thus following all normative parts in the main sections (the ones 2728 with numbers), not the appendices (starting with letters), unless 2729 explicitly specified in a main section for being a required appendix. 2731 Note: This feature tag does not mandate any media delivery 2732 protocol, such as RTP. 2734 In RTSP 1.0 there was a minimal implementation section. However, 2735 that was not consistent with the rest of the specification. So 2736 rather than making an attempt to explicitly enumerate the features 2737 for play.basic this specification have to be read in completeness 2738 and the necessary features normatively defined as being required 2739 are included. 2741 12. Pipelining Support 2743 Pipelining is a general method to improve performance of request 2744 response protocols by allowing the requesting agent to have more than 2745 one request outstanding and send them over the same persistent 2746 connection. For RTSP, where the relative order of requests will 2747 matter, it is important to maintain the order of the requests. 2748 Because of this, the responding agent MUST process the incoming 2749 requests in their sending order. The sending order can be determined 2750 by the CSeq header and its sequence number. For TCP the delivery 2751 order will be the same between two agents, as the sending order. The 2752 processing of the request MUST also have been finished before 2753 processing the next request from the same agent. The responses MUST 2754 be sent in the order the requests were processed. 2756 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2757 The major improvement is to allow all requests involved in setting up 2758 and initiating media delivery to be pipelined after each other. This 2759 is accomplished by the utilization of the Pipelined-Requests header 2760 (see Section 18.33). This header allows a client to request that two 2761 or more requests are processed in the same RTSP session context which 2762 the first request creates. In other words, a client can request that 2763 two or more media streams are set-up and then played without needing 2764 to wait for a single response. This speeds up the initial startup 2765 time for an RTSP session by at least one RTT. 2767 If a pipelined request builds on the successful completion of one or 2768 more prior requests the requester must verify that all requests were 2769 executed as expected. A common example will be two SETUP requests 2770 and a PLAY request. In case one of the SETUP fails unexpectedly, the 2771 PLAY request can still be successfully executed. However, the 2772 resulting presentation will not be as expected by the requesting 2773 client, as only a single media instead of two will be played. In 2774 this case the client can send a PAUSE request, correct the failing 2775 SETUP request and then request it to be played. 2777 13. Method Definitions 2779 The method indicates what is to be performed on the resource 2780 identified by the Request-URI. The method name is case-sensitive. 2781 New methods may be defined in the future. Method names MUST NOT 2782 start with a $ character (decimal 36) and MUST be a token as defined 2783 by the ABNF [RFC5234] in the syntax chapter Section 20. The methods 2784 are summarized in Table 7. 2786 +---------------+-----------+--------+-------------+-------------+ 2787 | method | direction | object | Server req. | Client req. | 2788 +---------------+-----------+--------+-------------+-------------+ 2789 | DESCRIBE | C -> S | P,S | recommended | recommended | 2790 | | | | | | 2791 | GET_PARAMETER | C -> S | P,S | optional | optional | 2792 | | | | | | 2793 | | S -> C | P,S | optional | optional | 2794 | | | | | | 2795 | OPTIONS | C -> S | P,S | required | required | 2796 | | | | | | 2797 | | S -> C | P,S | optional | optional | 2798 | | | | | | 2799 | PAUSE | C -> S | P,S | required | required | 2800 | | | | | | 2801 | PLAY | C -> S | P,S | required | required | 2802 | | | | | | 2803 | PLAY_NOTIFY | S -> C | P,S | required | required | 2804 | | | | | | 2805 | REDIRECT | S -> C | P,S | optional | required | 2806 | | | | | | 2807 | SETUP | C -> S | S | required | required | 2808 | | | | | | 2809 | SET_PARAMETER | C -> S | P,S | required | optional | 2810 | | | | | | 2811 | | S -> C | P,S | optional | optional | 2812 | | | | | | 2813 | TEARDOWN | C -> S | P,S | required | required | 2814 | | | | | | 2815 | | S -> C | P | required | required | 2816 +---------------+-----------+--------+-------------+-------------+ 2818 Table 7: Overview of RTSP methods, their direction, and what objects 2819 (P: presentation, S: stream) they operate on. Further it indicates if 2820 a server or a client implementation are required (mandatory), 2821 recommended or if it is optional to implement the method. 2823 Note on Table 7: GET_PARAMETER is optional. For example, a fully 2824 functional server can be built to deliver media without any 2825 parameters. However, SET_PARAMETER is required, i.e. mandatory to 2826 implement for the server, this is due to its usage for keep-alive. 2827 PAUSE is required because it is the only way of leaving the Play 2828 state without terminating the whole session. 2830 If an RTSP agent does not support a particular method, it MUST return 2831 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2832 NOT try this method again for the given agent / resource combination. 2833 An RTSP proxy whose main function is to log or audit and not modify 2834 transport or media handling in any way MAY forward RTSP messages with 2835 unknown methods. Note that the proxy still needs to perform the 2836 minimal required processing, like adding the Via header. 2838 13.1. OPTIONS 2840 The semantics of the RTSP OPTIONS method is similar to that of the 2841 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2842 bi-directional, in that a client can send the request to a server and 2843 vice versa. A client MUST implement the capability to send an 2844 OPTIONS request and a server or a proxy MUST implement the capability 2845 to respond to an OPTIONS request. In addition to this "MUST 2846 implement" functionality, clients, servers and proxies MAY provide 2847 support both for sending OPTIONS requests and generating responses to 2848 the requests. 2850 An OPTIONS request may be issued at any time. Such a request does 2851 not modify the session state. However, it may prolong the session 2852 lifespan (see below). The URI in an OPTIONS request determines the 2853 scope of the request and the corresponding response. If the Request- 2854 URI refers to a specific media resource on a given host, the scope is 2855 limited to the set of methods supported for that media resource by 2856 the indicated RTSP agent. A Request-URI with only the host address 2857 limits the scope to the specified RTSP agent's general capabilities 2858 without regard to any specific media. If the Request-URI is an 2859 asterisk ("*"), the scope is limited to the general capabilities of 2860 the next hop (i.e., the RTSP agent in direct communication with the 2861 request sender). 2863 Regardless of the scope of the request, the Public header MUST always 2864 be included in the OPTIONS response listing the methods that are 2865 supported by the responding RTSP agent. In addition, if the scope of 2866 the request is limited to a media resource, the Allow header MUST be 2867 included in the response to enumerate the set of methods that are 2868 allowed for that resource unless the set of methods completely 2869 matches the set in the Public header. If the given resource is not 2870 available, the RTSP agent SHOULD return an appropriate response code 2871 such as 3rr or 4xx. The Supported header MAY be included in the 2872 request to query the set of features that are supported by the 2873 responding RTSP agent. 2875 The OPTIONS method can be used to keep an RTSP session alive. 2876 However, this is not the preferred way of session keep-alive 2877 signaling, see Section 18.49. An OPTIONS request intended for 2878 keeping alive an RTSP session MUST include the Session header with 2879 the associated session identifier. Such a request SHOULD also use 2880 the media or the aggregated control URI as the Request-URI. 2882 Example: 2884 C->S: OPTIONS rtsp://server.example.com RTSP/2.0 2885 CSeq: 1 2886 User-Agent: PhonyClient/1.2 2887 Proxy-Require: gzipped-messages 2888 Supported: play.basic 2890 S->C: RTSP/2.0 200 OK 2891 CSeq: 1 2892 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS 2893 Supported: play.basic, setup.rtp.rtcp.mux, play.scale 2894 Server: PhonyServer/1.1 2896 Note that some of the feature-tags in Supported and Proxy-Require are 2897 fictitious features. 2899 13.2. DESCRIBE 2901 The DESCRIBE method is used to retrieve the description of a 2902 presentation or media object from a server. The Request-URI of the 2903 DESCRIBE request identifies the media resource of interest. The 2904 client MAY include the Accept header in the request to list the 2905 description formats that it understands. The server MUST respond 2906 with a description of the requested resource and return the 2907 description in the message body of the response, if the DESCRIBE 2908 method request can be successfully fulfilled. The DESCRIBE reply- 2909 response pair constitutes the media initialization phase of RTSP. 2911 The DESCRIBE response SHOULD contain all media initialization 2912 information for the resource(s) that it describes. Servers SHOULD 2913 NOT use the DESCRIBE response as a means of media indirection by 2914 having the description point at another server; instead, using the 2915 3rr responses is RECOMMENDED. 2917 By forcing a DESCRIBE response to contain all media initialization 2918 information for the set of streams that it describes, and 2919 discouraging the use of DESCRIBE for media indirection, any 2920 looping problems can be avoided that might have resulted from 2921 other approaches. 2923 Example: 2925 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2926 CSeq: 312 2927 User-Agent: PhonyClient/1.2 2928 Accept: application/sdp, application/example 2930 S->C: RTSP/2.0 200 OK 2931 CSeq: 312 2932 Date: Thu, 23 Jan 1997 15:35:06 GMT 2933 Server: PhonyServer/1.1 2934 Content-Base: rtsp://server.example.com/fizzle/foo/ 2935 Content-Type: application/sdp 2936 Content-Length: 358 2938 v=0 2939 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46 2940 s=SDP Seminar 2941 i=A Seminar on the session description protocol 2942 u=http://www.example.com/lectures/sdp.ps 2943 e=seminar@example.com (Seminar Management) 2944 c=IN IP4 0.0.0.0 2945 a=control:* 2946 t=2873397496 2873404696 2947 m=audio 3456 RTP/AVP 0 2948 a=control:audio 2949 m=video 2232 RTP/AVP 31 2950 a=control:video 2952 Media initialization is a requirement for any RTSP-based system, but 2953 the RTSP specification does not dictate that this is required to be 2954 done via the DESCRIBE method. There are three ways that an RTSP 2955 client may receive initialization information: 2957 o via an RTSP DESCRIBE request 2959 o via some other protocol (HTTP, email attachment, etc.) 2961 o via some form of user interface 2963 If a client obtains a valid description from an alternate source, the 2964 client MAY use this description for initialization purposes without 2965 issuing a DESCRIBE request for the same media. The client should use 2966 any MTag to either validate the presentation description or make the 2967 session establishment conditional on being valid. 2969 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2970 and highly recommended that minimal clients support the ability to 2971 act as "helper applications" that accept a media initialization file 2972 from a user interface, and/or other means that are appropriate to the 2973 operating environment of the clients. 2975 13.3. SETUP 2977 The below description uses the following states in a protocol state 2978 machine that are related to a specific session when that session has 2979 been created. The state transitions are driven by protocol 2980 interactions. For additional information about the state machine see 2981 Appendix B. 2983 Init: Initial state: no session exists. 2985 Ready: Session is ready to start playing. 2987 Play: Session is playing, i.e., sending media stream data in the 2988 direction S->C. 2990 The SETUP request for an URI specifies the transport mechanism to be 2991 used for the streamed media. The SETUP method may be used in two 2992 different cases; Create an RTSP session and change the transport 2993 parameters of already set up media stream(s). SETUP can be used in 2994 all three states; Init, and Ready, for both purposes and in PLAY to 2995 change the transport parameters. There is also a third possible 2996 usage for the SETUP method which is not specified in this memo: 2997 adding a media to a session. Using SETUP to add media to an existing 2998 session, when the session is in Play state, is unspecified. 3000 The Transport header, see Section 18.54, specifies the media 3001 transport parameters acceptable to the client for data transmission; 3002 the response will contain the transport parameters selected by the 3003 server. This allows the client to enumerate in descending order of 3004 preference the transport mechanisms and parameters acceptable to it, 3005 while the server can select the most appropriate. It is expected 3006 that the session description format used will enable the client to 3007 select a limited number of possible configurations that are offered 3008 to the server to choose from. All transport related parameters SHALL 3009 be included in the Transport header; the use of other headers for 3010 this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls 3011 or NATs. 3013 For the benefit of any intervening firewalls, a client MUST indicate 3014 the known transport parameters, even if it has no influence over 3015 these parameters, for example, where the server advertises a fixed 3016 multicast address as destination. 3018 Since SETUP includes all transport initialization information, 3019 firewalls and other intermediate network devices (which need this 3020 information) are spared the more arduous task of parsing the 3021 DESCRIBE response, which has been reserved for media 3022 initialization. 3024 The client MUST include the Accept-Ranges header in the request 3025 indicating all supported unit formats in the Range header. This 3026 allows the server to know which formats it may use in future session 3027 related responses, such as a PLAY response without any range in the 3028 request. If the client does not support a time format necessary for 3029 the presentation, the server MUST respond using 456 (Header Field Not 3030 Valid for Resource) and include the Accept-Ranges header with the 3031 range unit formats supported for the resource. 3033 In a SETUP response the server MUST include the Accept-Ranges header 3034 (see Section 18.5) to indicate which time formats are acceptable to 3035 use for this media resource. 3037 The SETUP response 200 OK MUST include the Media-Properties header 3038 (see Section 18.29 ). The combination of the parameters of the 3039 Media-Properties header indicates the nature of the content present 3040 in the session (see also Section 4.7). For example, a live stream 3041 with time shifting is indicated by 3043 o Random Access set to Random-Access, 3045 o Content Modifications set to Time Progressing, 3047 o Retention set to Time-Duration (with specific recording window 3048 time value). 3050 The SETUP response 200 OK MUST include the Media-Range header (see 3051 Section 18.30) if the media is Time-Progressing. 3053 A basic example for SETUP: 3055 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 3056 CSeq: 302 3057 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 3058 RTP/AVP/TCP;unicast;interleaved=0-1 3059 Accept-Ranges: npt, clock 3060 User-Agent: PhonyClient/1.2 3062 S->C: RTSP/2.0 200 OK 3063 CSeq: 302 3064 Date: Thu, 23 Jan 1997 15:35:06 GMT 3065 Server: PhonyServer/1.1 3066 Session: 47112344;timeout=60 3067 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ 3068 "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ 3069 "198.51.100.241:6257"; ssrc=2A3F93ED 3070 Accept-Ranges: npt 3071 Media-Properties: Random-Access=3.2, Time-Progressing, 3072 Time-Duration=3600.0 3073 Media-Range: npt=0-2893.23 3075 In the above example the client wants to create an RTSP session 3076 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 3077 The transport parameters acceptable to the client are either RTP/AVP/ 3078 UDP (UDP per default) to be received on client port 4588 and 4589 at 3079 the address the RTSP setup connection comes from or RTP/AVP 3080 interleaved on the RTSP control channel. The server selects the RTP/ 3081 AVP/UDP transport and adds the address and ports it will send and 3082 receive RTP and RTCP from, and the RTP SSRC that will be used by the 3083 server. 3085 The server MUST generate a session identifier in response to a 3086 successful SETUP request, unless a SETUP request to a server includes 3087 a session identifier or a Pipelined-Requests header referencing an 3088 existing session context, in which case the server MUST bundle this 3089 SETUP request into the existing session (aggregated session) or 3090 return error 459 (Aggregate Operation Not Allowed) (see 3091 Section 17.4.23). An Aggregate control URI MUST be used to control 3092 an aggregated session. This URI MUST be different from the stream 3093 control URIs of the individual media streams included in the 3094 aggregate (see Section 13.4.2 for aggregated sessions and for the 3095 particular URIs see Appendix D.1.1). The Aggregate control URI is to 3096 be specified by the session description if the server supports 3097 aggregated control and aggregated control is desired for the session. 3098 However, even if aggregated control is offered the client MAY chose 3099 to not set up the session in aggregated control. If an Aggregate 3100 control URI is not specified in the session description, it is 3101 normally an indication that non-aggregated control should be used. 3102 The SETUP of media streams in an aggregate which has not been given 3103 an aggregated control URI is unspecified. 3105 While the session ID sometimes carries enough information for 3106 aggregate control of a session, the Aggregate control URI is still 3107 important for some methods such as SET_PARAMETER where the control 3108 URI enables the resource in question to be easily identified. The 3109 Aggregate control URI is also useful for proxies, enabling them to 3110 route the request to the appropriate server, and for logging, 3111 where it is useful to note the actual resource that a request was 3112 operating on. 3114 A session will exist until it is either removed by a TEARDOWN request 3115 or is timed-out by the server. The server MAY remove a session that 3116 has not demonstrated liveness signs from the client(s) within a 3117 certain timeout period. The default timeout value is 60 seconds; the 3118 server MAY set this to a different value and indicate so in the 3119 timeout field of the Session header in the SETUP response. For 3120 further discussion see Section 18.49. Signs of liveness for an RTSP 3121 session are: 3123 o Any RTSP request from a client which includes a Session header 3124 with that session's ID. 3126 o If RTP is used as a transport for the underlying media streams, an 3127 RTCP sender or receiver report from the client(s) for any of the 3128 media streams in that RTSP session. RTCP Sender Reports may for 3129 example be received in sessions where the server is invited into a 3130 conference session and is valid for keep-alive. 3132 If a SETUP request on a session fails for any reason, the session 3133 state, as well as transport and other parameters for associated 3134 streams MUST remain unchanged from their values as if the SETUP 3135 request had never been received by the server. 3137 13.3.1. Changing Transport Parameters 3139 A client MAY issue a SETUP request for a stream that is already set 3140 up or playing in the session to change transport parameters, which a 3141 server MAY allow. If it does not allow changing of parameters, it 3142 MUST respond with error 455 (Method Not Valid In This State). The 3143 reasons to support changing transport parameters include allowing 3144 application layer mobility and flexibility to utilize the best 3145 available transport as it becomes available. If a client receives a 3146 455 when trying to change transport parameters while the server is in 3147 Play state, it MAY try to put the server in Ready state using PAUSE, 3148 before issuing the SETUP request again. If that also fails the 3149 changing of transport parameters will require that the client 3150 performs a TEARDOWN of the affected media and then to set it up 3151 again. For an aggregated session avoiding tearing down all the media 3152 at the same time will avoid the creation of a new session. 3154 All transport parameters MAY be changed. However, the primary usage 3155 expected is to either change the transport protocol completely, like 3156 switching from Interleaved TCP mode to UDP or vice versa, or to 3157 change the delivery address. 3159 In a SETUP response for a request to change the transport parameters 3160 while in Play state, the server MUST include the Range to indicate at 3161 what point the new transport parameters will be used. Further, if 3162 RTP is used for delivery, the server MUST also include the RTP-Info 3163 header to indicate at what timestamp and RTP sequence number the 3164 change will take place. If both RTP-Info and Range are included in 3165 the response the "rtp_time" parameter and start point in the Range 3166 header MUST be for the corresponding time, i.e., be used in the same 3167 way as for PLAY to ensure the correct synchronization information is 3168 available. 3170 If the transport parameters change while in Play state results in a 3171 change of synchronization related information, for example changing 3172 RTP SSRC, the server MUST provide in the SETUP response the necessary 3173 synchronization information. However, the server is RECOMMENDED to 3174 avoid changing the synchronization information if possible. 3176 13.4. PLAY 3178 This section describes the usage of the PLAY method in general, for 3179 aggregated sessions, and in different usage scenarios. 3181 13.4.1. General Usage 3183 The PLAY method tells the server to start sending data via the 3184 mechanism specified in SETUP and which part of the media should be 3185 played out. PLAY requests are valid when the session is in Ready or 3186 Play states. A PLAY request MUST include a Session header to 3187 indicate which session the request applies to. 3189 Upon receipt of the PLAY request, the server MUST position the normal 3190 play time to the beginning of the range specified in the received 3191 Range header, within the limits of the media resource and in 3192 accordance with the Seek-Style header (Section 18.47) and deliver 3193 stream data until the end of the range if given, until a new PLAY 3194 request is received, or until the end of the media is reached. If no 3195 Range header is present in the PLAY request the server SHALL play 3196 from current pause point until the end of media. The pause point 3197 defaults at session start to the beginning of the media. For media 3198 that is time-progressing and has no retention, the pause point will 3199 always be set equal to NPT "now", i.e., the current delivery point. 3200 The pause point may also be set to a particular point in the media by 3201 the PAUSE method, see Section 13.6. The pause point for media that 3202 is currently playing is equal to the current media position. For 3203 time-progressing media with time-limited retention, if the pause 3204 point represents a position that is older than what is retained by 3205 the server, the pause point will be moved to the oldest retained. 3207 What range values are valid depends on the type of content. For 3208 content that isn't time progressing the range value is valid if the 3209 given range is part of any media within the aggregate. In other 3210 words the valid media range for the aggregate is the union of all of 3211 the media components in the aggregate. If a given range value points 3212 outside of the media, the response MUST be the 457 (Invalid Range) 3213 error code and include the Media-Range header (Section 18.30) with 3214 the valid range for the media. Except for time progressing content 3215 where the client requests a start point prior to what is retained, 3216 the start point is adjusted to the oldest retained content. For a 3217 start point that is beyond the media front edge, i.e., beyond the 3218 current value for "now", the server SHALL adjust the start value to 3219 the current front edge. The Range header's stop point value may 3220 point beyond the current media edge. In that case, the server SHALL 3221 deliver media from the requested (and possibly adjusted) start point 3222 until the provided stop point, or the end of the media is reached 3223 prior to the specified stop point. Please note that if one simply 3224 wants to play from a particular start point until the end of media 3225 using a Range header with an implicit stop point is RECOMMENDED. 3227 If a client requests to start playing at the end of media, either 3228 explicitly with a Range header or implicitly with a pause point that 3229 is at the end of media, a 457 (Invalid Range) error MUST be sent and 3230 include the Media-Range header (Section 18.30). It is specified 3231 below that the Range header also must be included in the response and 3232 that it will carry the pause point in the media, in the case of the 3233 session being in Ready State. Note that this also applies if the 3234 pause point or requested start point is at the beginning of the media 3235 and a Scale header (Section 18.46) is included with a negative value 3236 (playing backwards). 3238 For media with random access properties a client may express its 3239 preference on which policy for start point selection the server shall 3240 use. This is done by including the Seek-Style header (Section 18.47) 3241 in the PLAY request. The Seek-Style applied will effect the content 3242 of the Range header as it will be adjusted to indicate from what 3243 point the media actually is delivered. 3245 A client desiring to play the media from the beginning MUST send a 3246 PLAY request with a Range header pointing at the beginning, e.g., 3247 "npt=0-". If a PLAY request is received without a Range header and 3248 media delivery has stopped at the end, the server SHOULD respond with 3249 a 457 "Invalid Range" error response. In that response, the current 3250 pause point MUST be included in a Range header. 3252 All range specifiers in this specification allow for ranges with an 3253 implicit start point (e.g., "npt=-30"). When used in a PLAY request, 3254 the server treats this as a request to start or resume delivery from 3255 the current pause point, ending at the end time specified in the 3256 Range header. If the pause point is located later than the given end 3257 value, a 457 (Invalid Range) response MUST be given. 3259 The example below will play seconds 10 through 25. It also requests 3260 the server to deliver media from the first Random Access Point prior 3261 to the indicated start point. 3263 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 3264 CSeq: 835 3265 Session: 12345678 3266 Range: npt=10-25 3267 Seek-Style: RAP 3268 User-Agent: PhonyClient/1.2 3270 Servers MUST include a "Range" header in any PLAY response, even if 3271 no Range header was present in the request. The response MUST use 3272 the same format as the request's range header contained. If no Range 3273 header was in the request, the format used in any previous PLAY 3274 request within the session SHOULD be used. If no format has been 3275 indicated in a previous request the server MAY use any time format 3276 supported by the media and indicated in the Accept-Ranges header in 3277 the SETUP request. It is RECOMMENDED that NPT is used if supported 3278 by the media. 3280 For any error response to a PLAY request, the server's response 3281 depends on the current session state. If the session is in Ready 3282 state, the current pause-point is returned using Range header with 3283 the pause point as the explicit start-point and an implicit stop- 3284 point. For time-progressing content where the pause-point moves with 3285 real-time due to limited retention, the current pause point is 3286 returned. For sessions in Play state, the current playout point and 3287 the remaining parts of the range request is returned. For any media 3288 with retention longer than 0 seconds the currently valid Media-Range 3289 header SHALL also be included in the response. 3291 A PLAY response MAY include a header carrying synchronization 3292 information. As the information necessary is dependent on the media 3293 transport format, further rules specifying the header and its usage 3294 are needed. For RTP the RTP-Info header is specified, see 3295 Section 18.45, and used in the following example. 3297 Here is a simple example for a single audio stream where the client 3298 requests the media starting from 3.52 seconds and to the end. The 3299 server sends a 200 OK response with the actual play time which is 10 3300 ms prior (3.51) and the RTP-Info header that contains the necessary 3301 parameters for the RTP stack. 3303 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3304 CSeq: 836 3305 Session: 12345678 3306 Range: npt=3.52- 3307 User-Agent: PhonyClient/1.2 3309 S->C: RTSP/2.0 200 OK 3310 CSeq: 836 3311 Date: Thu, 23 Jan 1997 15:35:06 GMT 3312 Server: PhonyServer/1.0 3313 Range: npt=3.51-324.39 3314 Seek-Style: First-Prior 3315 RTP-Info:url="rtsp://example.com/audio" 3316 ssrc=0D12F123:seq=14783;rtptime=2345962545 3318 S->C: RTP Packet TS=2345962545 => NPT=3.51 3319 Media duration=0.16 seconds 3321 The server replies with the actual start point that will be 3322 delivered. This may differ from the requested range if alignment of 3323 the requested range to valid frame boundaries is required for the 3324 media source. Note that some media streams in an aggregate may need 3325 to be delivered from even earlier points. Also, some media formats 3326 have a very long duration per individual data unit, therefore it 3327 might be necessary for the client to parse the data unit, and select 3328 where to start. The server SHALL also indicate which policy it uses 3329 for selecting the actual start point by including a Seek-Style 3330 header. 3332 In the following example the client receives the first media packet 3333 that stretches all the way up and past the requested playtime. Thus, 3334 it is the client's decision whether to render to the user the time 3335 between 3.52 and 7.05, or to skip it. In most cases it is probably 3336 most suitable not to render that time period. 3338 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3339 CSeq: 836 3340 Session: 12345678 3341 Range: npt=7.05- 3342 User-Agent: PhonyClient/1.2 3344 S->C: RTSP/2.0 200 OK 3345 CSeq: 836 3346 Date: Thu, 23 Jan 1997 15:35:06 GMT 3347 Server: PhonyServer/1.0 3348 Range: npt=3.52- 3349 Seek-Style: First-Prior 3350 RTP-Info:url="rtsp://example.com/audio" 3351 ssrc=0D12F123:seq=14783;rtptime=2345962545 3353 S->C: RTP Packet TS=2345962545 => NPT=3.52 3354 Duration=4.15 seconds 3356 After playing the desired range, the presentation does NOT change to 3357 the Ready state, media delivery simply stops. A PAUSE request MUST 3358 be issued to make the stream enter the Ready state. A PLAY request 3359 while the stream is still in the Play state is legal, and can be 3360 issued without an intervening PAUSE request. Such a request MUST 3361 replace the current PLAY action with the new one requested, i.e., 3362 being handled in the same way as if as the request was received in 3363 Ready state. In the case that the range in Range header has an 3364 implicit start time ("-endtime"), the server MUST continue to play 3365 from where it currently was until the specified end point. This is 3366 useful to change the end to at another point than in the previous 3367 request. 3369 The following example plays the whole presentation starting at SMPTE 3370 time code 0:10:20 until the end of the clip. Note: The RTP-Info 3371 headers has been broken into several lines, where following lines 3372 start with whitespace as allowed by the syntax. 3374 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 3375 CSeq: 833 3376 Session: 12345678 3377 Range: smpte=0:10:20- 3378 User-Agent: PhonyClient/1.2 3380 S->C: RTSP/2.0 200 OK 3381 CSeq: 833 3382 Date: Thu, 23 Jan 1997 15:35:06 GMT 3383 Session: 12345678 3384 Server: PhonyServer/1.0 3385 Range: smpte=0:10:22-0:15:45 3386 Seek-Style: Next 3387 RTP-Info:url="rtsp://example.com/twister.en" 3388 ssrc=0D12F123:seq=14783;rtptime=2345962545 3390 For playing back a recording of a live presentation, it may be 3391 desirable to use clock units: 3393 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 3394 CSeq: 835 3395 Session: 12345678 3396 Range: clock=19961108T142300Z-19961108T143520Z 3397 User-Agent: PhonyClient/1.2 3399 S->C: RTSP/2.0 200 OK 3400 CSeq: 835 3401 Date: Thu, 23 Jan 1997 15:35:06 GMT 3402 Session: 12345678 3403 Server: PhonyServer/1.0 3404 Range: clock=19961108T142300Z-19961108T143520Z 3405 Seek-Style: Next 3406 RTP-Info:url="rtsp://example.com/meeting.en" 3407 ssrc=0D12F123:seq=53745;rtptime=484589019 3409 13.4.2. Aggregated Sessions 3411 PLAY requests can operate on sessions controlling a single media and 3412 on aggregated sessions controlling multiple media. 3414 In an aggregated session the PLAY request MUST contain an aggregated 3415 control URI. A server MUST respond with error 460 (Only Aggregate 3416 Operation Allowed) if the client PLAY Request-URI is for a single 3417 media. The media in an aggregate MUST be played in sync. If a 3418 client wants individual control of the media, it needs to use 3419 separate RTSP sessions for each media. 3421 For aggregated sessions where the initial SETUP request (creating a 3422 session) is followed by one or more additional SETUP requests, a PLAY 3423 request MAY be pipelined after those additional SETUP requests 3424 without awaiting their responses. This procedure can reduce the 3425 delay from start of session establishment until media play-out has 3426 started with one round trip time. However, a client needs to be 3427 aware that using this procedure will result in the playout of the 3428 server state established at the time of processing the PLAY, i.e., 3429 after the processing of all the requests prior to the PLAY request in 3430 the pipeline. This state may not be the intended one due to failure 3431 of any of the prior requests. A client can easily determine this 3432 based on the responses from those requests. In case of failure, the 3433 client can halt the media playout using PAUSE and try to establish 3434 the intended state again before issuing another PLAY request. 3436 13.4.3. Updating current PLAY Requests 3438 Clients can issue PLAY requests while the stream is in Play state and 3439 thus updating their request. 3441 The important difference compared to a PLAY request in Ready state is 3442 the handling of the current play point and how the Range header in 3443 the request is constructed. The session is actively playing media 3444 and the play point will be moving, making the exact time a request 3445 will take effect hard to predict. Depending on how the PLAY header 3446 appears two different cases exist: total replacement or continuation. 3447 A total replacement is signaled by having the first range 3448 specification have an explicit start value, e.g., "npt=45-" or 3449 "npt=45-60", in which case the server stops playout at the current 3450 playout point and then starts delivering media according to the Range 3451 header. This is equivalent to having the client first send a PAUSE 3452 and then a new PLAY request that isn't based on the pause point. In 3453 the case of continuation the first range specifier has an implicit 3454 start point and an explicit stop value (Z), e.g., "npt=-60", which 3455 indicate that it MUST convert the range specifier being played prior 3456 to this PLAY request (X to Y) into (X to Z) and continue as this was 3457 the request originally played. If the current delivery point is 3458 beyond the stop point, the server SHALL immediately pause delivery. 3459 As the request has been completed successfully it shall be responded 3460 with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to 3461 indicate the actual stop point. The pause point is set to the 3462 requested stop point. 3464 Following is an example of this behavior: The server has received 3465 requests to play ranges 10 to 15. If the new PLAY request arrives at 3466 the server 4 seconds after the previous one, it will take effect 3467 while the server still plays the first range (10-15). The server 3468 changes the current play to continue to 25 seconds, i.e., the 3469 equivalent single request would be PLAY with "range: npt=10-25". 3471 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3472 CSeq: 834 3473 Session: 12345678 3474 Range: npt=10-15 3475 User-Agent: PhonyClient/1.2 3477 S->C: RTSP/2.0 200 OK 3478 CSeq: 834 3479 Date: Thu, 23 Jan 1997 15:35:06 GMT 3480 Session: 12345678 3481 Server: PhonyServer/1.0 3482 Range: npt=10-15 3483 Seek-Style: Next 3484 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3485 ssrc=0D12F123:seq=5712;rtptime=934207921, 3486 url="rtsp://example.com/fizzle/videotrack" 3487 ssrc=789DAF12:seq=57654;rtptime=2792482193 3488 Session: 12345678 3490 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3491 CSeq: 835 3492 Session: 12345678 3493 Range: npt=-25 3494 User-Agent: PhonyClient/1.2 3496 S->C: RTSP/2.0 200 OK 3497 CSeq: 835 3498 Date: Thu, 23 Jan 1997 15:35:09 GMT 3499 Session: 12345678 3500 Server: PhonyServer/1.0 3501 Range: npt=14-25 3502 Seek-Style: Next 3503 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3504 ssrc=0D12F123:seq=5712;rtptime=934239921, 3505 url="rtsp://example.com/fizzle/videotrack" 3506 ssrc=789DAF12:seq=57654;rtptime=2792842193 3508 A common use of a PLAY request while in Play state is changing the 3509 scale of the media, i.e., entering or leaving fast forward or fast 3510 rewind. The client can issue an updating PLAY request that is either 3511 a continuation or a complete replacement, as discussed above this 3512 section. We give an example of a client that is requesting a fast 3513 forward (scale=2) without giving a stop point and then change from 3514 fast forward to regular playout (scale = 1). In the second PLAY 3515 request the time is set explicitly to be where ever the server 3516 currently plays out (npt=now-) and the server responds with the 3517 actual playback point where the new scale actually takes effect 3518 (npt=2:17:27.144-). 3520 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3521 CSeq: 2034 3522 Session: 12345678 3523 Range: npt=now- 3524 Scale: 2.0 3525 User-Agent: PhonyClient/1.2 3527 S->C: RTSP/2.0 200 OK 3528 CSeq: 2034 3529 Date: Thu, 23 Jan 1997 15:35:06 GMT 3530 Session: 12345678 3531 Server: PhonyServer/1.0 3532 Range: npt=2:17:21.394- 3533 Seek-Style: Next 3534 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3535 ssrc=0D12F123:seq=5712;rtptime=934207921, 3536 url="rtsp://example.com/fizzle/videotrack" 3537 ssrc=789DAF12:seq=57654;rtptime=2792482193 3539 [playing in fast forward and now returning to scale = 1] 3541 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3542 CSeq: 2035 3543 Session: 12345678 3544 Range: npt=now- 3545 Scale: 1.0 3546 User-Agent: PhonyClient/1.2 3548 S->C: RTSP/2.0 200 OK 3549 CSeq: 2035 3550 Date: Thu, 23 Jan 1997 15:35:09 GMT 3551 Session: 12345678 3552 Server: PhonyServer/1.0 3553 Range: npt=2:17:27.144- 3554 Seek-Style: Next 3555 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3556 ssrc=0D12F123:seq=5712;rtptime=934239921, 3557 url="rtsp://example.com/fizzle/videotrack" 3558 ssrc=789DAF12:seq=57654;rtptime=2792842193 3560 13.4.4. Playing On-Demand Media 3562 On-demand media is indicated by the content of the Media-Properties 3563 header in the SETUP response by (see also Section 18.29): 3565 o Random Access property is set to Random-Access; 3566 o Content Modifications set to Immutable; 3568 o Retention set to Unlimited or Time-Limited. 3570 Playing on-demand media follows the general usage as described in 3571 Section 13.4.1. 3573 13.4.5. Playing Dynamic On-Demand Media 3575 Dynamic on-demand media is indicated by the content of the Media- 3576 Properties header in the SETUP response by (see also Section 18.29): 3578 o Random Access set to Random-Access; 3580 o Content Modifications set to Dynamic; 3582 o Retention set to Unlimited or Time-Limited. 3584 Playing on-demand media follows the general usage as described in 3585 Section 13.4.1 as long as the media has not been changed. 3587 There are two ways for the client to be informed about changes of 3588 media resources in Play state. The client will receive a PLAY_NOTIFY 3589 request with Notify-Reason header set to media-properties-update (see 3590 Section 13.5.2. The client can use the value of the Media-Range to 3591 decide further actions, if the Media-Range header is present in the 3592 PLAY_NOTIFY request. The second way is that the client issues a 3593 GET_PARAMETER request without a body but including a Media-Range 3594 header. The 200 OK response MUST include the current Media-Range 3595 header (see Section 18.30). 3597 13.4.6. Playing Live Media 3599 Live media is indicated by the content of the Media-Properties header 3600 in the SETUP response by (see also Section 18.29): 3602 o Random-Access set to No-Seeking; 3604 o Content Modifications set to Time-Progressing; 3606 o Retention with Time-Duration set to 0.0. 3608 For live media, the SETUP response 200 OK MUST include the Media- 3609 Range header (see Section 18.30). 3611 A client MAY send PLAY requests without the Range header. If the 3612 request includes the Range header it MUST use a symbolic value 3613 representing "now". For NPT that range specification is "npt=now-". 3615 The server MUST include the Range header in the response and it MUST 3616 indicate an explicit time value and not a symbolic value. In other 3617 words, "npt=now-" is not valid to be used in the response. Instead 3618 the time since session start is recommended expressed as an open 3619 interval, e.g., "npt=96.23-". An absolute time value (clock) for the 3620 corresponding time MAY be given, i.e., "clock=20030213T143205Z-". 3621 The Absolute Time format can only be used if client has shown support 3622 for it using the Accept-Ranges header. 3624 13.4.7. Playing Live with Recording 3626 Certain media servers may offer recording services of live sessions 3627 to their clients. This recording would normally be from the 3628 beginning of the media session. Clients can randomly access the 3629 media between now and the beginning of the media session. This live 3630 media with recording is indicated by the content of the Media- 3631 Properties header in the SETUP response by (see also Section 18.29): 3633 o Random Access set to Random-Access; 3635 o Content Modifications set to Time-Progressing; 3637 o Retention set to Time-Limited or Unlimited 3639 The SETUP response 200 OK MUST include the Media-Range header (see 3640 Section 18.30) for this type of media. For live media with 3641 recording, the Range header indicates the current delivery point in 3642 the media and the Media-Range header indicates the currently 3643 available media window around the current time. This window can 3644 cover recorded content in the past (seen from current time in the 3645 media) or recorded content in the future (seen from current time in 3646 the media). The server adjusts the delivery point to the requested 3647 border of the window. If the client requests a delivery point that 3648 is located outside the recording window, e.g., if the requested point 3649 is too far in the past, the server selects the oldest point in the 3650 recording. The considerations in Section 13.5.3 apply if a client 3651 requests delivery with Scale (Section 18.46) values other than 1.0 3652 (Normal playback rate) while delivering live media with recording. 3654 13.4.8. Playing Live with Time-Shift 3656 Certain media servers may offer time-shift services to their clients. 3657 This time shift records a fixed interval in the past, i.e., a sliding 3658 window recording mechanism, but not past this interval. Clients can 3659 randomly access the media between now and the interval. This live 3660 media with recording is indicated by the content of the Media- 3661 Properties header in the SETUP response by (see also Section 18.29): 3663 o Random Access set to Random-Access; 3665 o Content Modifications set to Time-Progressing; 3667 o Retention set to Time-Duration and a value indicating the 3668 recording interval (>0). 3670 The SETUP response 200 OK MUST include the Media-Range header (see 3671 Section 18.30) for this type of media. For live media with recording 3672 the Range header indicates the current time in the media and the 3673 Media Range indicates a window around the current time. This window 3674 can cover recorded content in the past (seen from current time in the 3675 media) or recorded content in the future (seen from current time in 3676 the media). The server adjusts the play point to the requested 3677 border of the window, if the client requests a play point that is 3678 located outside the recording windows, e.g., if requested too far in 3679 the past, the server selects the oldest range in the recording. The 3680 considerations in Section 13.5.3 apply, if a client requests delivery 3681 using a Scale (Section 18.46) value other than 1.0 (Normal playback 3682 rate) while delivering live media with time-shift. 3684 13.5. PLAY_NOTIFY 3686 The PLAY_NOTIFY method is issued by a server to inform a client about 3687 an asynchronous event for a session in Play state. The Session 3688 header MUST be presented in a PLAY_NOTIFY request and indicates the 3689 scope of the request. Sending of PLAY_NOTIFY requests requires a 3690 persistent connection between server and client, otherwise there is 3691 no way for the server to send this request method to the client. 3693 PLAY_NOTIFY requests have an end-to-end (i.e., server to client) 3694 scope, as they carry the Session header, and apply only to the given 3695 session. The client SHOULD immediately return a response to the 3696 server. 3698 PLAY_NOTIFY requests MAY use both aggregate control URI and 3699 individual media resource URIs depending on scope of the 3700 notification. This scope may have important distinctions for 3701 aggregated sessions, and each reason for a PLAY_NOTIFY request needs 3702 to specify the interpretation and if aggregated control URIs or 3703 individual URIs may be used in requests. 3705 PLAY_NOTIFY requests MAY be used with a message body, depending on 3706 the value of the Notify-Reason header. It is described in the 3707 particular section for each Notify-Reason if a message body is used. 3708 However, currently there is no Notify-Reason that allows using a 3709 message body. In this case, there is a need to obey some limitations 3710 when adding new Notify-Reasons that intend to use a message body: the 3711 server can send any type of message body, but it is not ensured that 3712 the client can understand the received message body. This is related 3713 to DESCRIBE (see Section 13.2 ), but in this particular case the 3714 client can state its acceptable message bodies by using the Accept 3715 header. In the case of PLAY_NOTIFY, the server does not know which 3716 message bodies are understood by the client. 3718 The Notify-Reason header (see Section 18.32) specifies the reason why 3719 the server sends the PLAY_NOTIFY request. This is extensible and new 3720 reasons MAY be added in the future (see Section 22.8). In case the 3721 client does not understand the reason for the notification it MUST 3722 respond with a 465 (Notification Reason Unknown) (Section 17.4.29) 3723 error code. Servers can send PLAY_NOTIFY with these types: 3725 o end-of-stream (see Section 13.5.1); 3727 o media-properties-update (see Section 13.5.2); 3729 o scale-change (see Section 13.5.3). 3731 13.5.1. End-of-Stream 3733 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3734 indicates the completion or near completion of the PLAY request and 3735 the ending delivery of the media stream(s). The request MUST NOT be 3736 issued unless the server is in the Play state. The end of the media 3737 stream delivery notification may be used to indicate either a 3738 successful completion of the PLAY request currently being served, or 3739 to indicate some error resulting in failure to complete the request. 3740 The Request-Status header (Section 18.42) MUST be included to 3741 indicate which request the notification is for and its completion 3742 status. The message response status codes (Section 8.1.1) are used 3743 to indicate how the PLAY request concluded. The sender of a 3744 PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a 3745 PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY 3746 was issued before reaching the end-of-stream, but some error occurred 3747 resulting in that the previously sent PLAY_NOTIFY contained a wrong 3748 time when the stream will end. In this case a new PLAY_NOTIFY MUST 3749 be sent including the correct status for the completion and all 3750 additional information. 3752 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream 3753 MUST include a Range header and the Scale header if the scale value 3754 is not 1. The Range header indicates the point in the stream or 3755 streams where delivery is ending with the timescale that was used by 3756 the server in the PLAY response for the request being fulfilled. The 3757 server MUST NOT use the "now" constant in the Range header; it MUST 3758 use the actual numeric end position in the proper timescale. When 3759 end-of-stream notifications are issued prior to having sent the last 3760 media packets, this is evident as the end time in the Range header is 3761 beyond the current time in the media being received by the client, 3762 e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale 3763 header is to be included so that it is evident if the media time 3764 scale is moving backwards and/or have a non-default pace. The end- 3765 of-stream notification does not prevent the client from sending a new 3766 PLAY request. 3768 If RTP is used as media transport, a RTP-Info header MUST be 3769 included, and the RTP-Info header MUST indicate the last sequence 3770 number in the seq parameter. 3772 For RTSP Session where media resources under aggregated control the 3773 media resources will normally end at approximately the same time, 3774 although some small differences may exist, on the scale of a few 3775 hundred of milliseconds. In those cases a RTSP session under 3776 aggregated control SHOULD send only a single PLAY_NOTIFY request. By 3777 using the aggregate control URI in the PLAY_NOTIFY request the RTSP 3778 server indicates that this applies to all media resources within the 3779 session. In cases RTP is used for media delivery corresponding RTP- 3780 Info needs to be included for all media resources. In cases where 3781 one or more media resource has significantly shorter duration than 3782 some other resources in the aggregated session the server MAY send 3783 end-of-stream notifications using individual media resource URIs to 3784 indicate to agents that there will be no more media for this 3785 particular media resource related to the current active PLAY request. 3786 In such cases when the remaining media resources comes to end-of- 3787 stream they MUST send a PLAY_NOTIFY request using the aggregate 3788 control URI to indicate that no more resources remains. 3790 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3791 MUST NOT carry a message body. 3793 This example request notifies the client about a future end-of-stream 3794 event: 3796 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3797 CSeq: 854 3798 Notify-Reason: end-of-stream 3799 Request-Status: cseq=853 status=200 reason="OK" 3800 Range: npt=-145 3801 RTP-Info:url="rtsp://example.com/fizzle/foo/audio" 3802 ssrc=0D12F123:seq=14783;rtptime=2345962545, 3803 url="rtsp://example.com/fizzle/video" 3804 ssrc=789DAF12:seq=57654;rtptime=2792482193 3806 Session: uZ3ci0K+Ld-M 3807 Date: Mon, 08 Mar 2010 13:37:16 GMT 3809 C->S: RTSP/2.0 200 OK 3810 CSeq: 854 3811 User-Agent: PhonyClient/1.2 3812 Session: uZ3ci0K+Ld-M 3814 13.5.2. Media-Properties-Update 3816 A PLAY_NOTIFY request with Notify-Reason header set to media- 3817 properties-update indicates an update of the media properties for the 3818 given session (see Section 18.29) and/or the available media range 3819 that can be played as indicated by Media-Range (Section 18.30). 3820 PLAY_NOTIFY requests with Notify-Reason header set to media- 3821 properties-update MUST include a Media-Properties and Date header and 3822 SHOULD include a Media-Range header. The Media-Properties header has 3823 session scope, thus for aggregated sessions the PLAY_NOTIFY request 3824 MUST be using the aggregated control URI. 3826 This notification MUST be sent for media that are Time-Progressing 3827 every time an event happens that changes the basis for making 3828 estimates on how the available for play-back media range will 3829 progress with wall clock time. In addition it is RECOMMENDED that 3830 the server sends these notifications approximately every 5 minutes 3831 for time-progressing content to ensure the long-term stability of the 3832 client estimation and allowing for clock skew detection by the 3833 client. The time between notifications should be greater than 1 3834 minute and less than 2 hours. Requests for the just mentioned 3835 reasons MUST include Media-Range header to provide current Media 3836 duration and the Range header to indicate the current playing point 3837 and any remaining parts of the requested range. 3839 The recommendation for sending updates every 5 minutes is due to 3840 any clock skew issues. In 5 minutes the clock skew should not 3841 become too significant as this is not used for media playback and 3842 synchronization, only for determining which content is available 3843 to the user. 3845 A PLAY_NOTIFY request with Notify-Reason header set to media- 3846 properties-update MUST NOT carry a message body. 3848 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3849 Date: Tue, 14 Apr 2008 15:48:06 GMT 3850 CSeq: 854 3851 Notify-Reason: media-properties-update 3852 Session: uZ3ci0K+Ld-M 3853 Media-Properties: Time-Progressing, 3854 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3855 Media-Range: npt=0-1:37:21.394 3856 Range: npt=1:15:49.873- 3858 C->S: RTSP/2.0 200 OK 3859 CSeq: 854 3860 User-Agent: PhonyClient/1.2 3861 Session: uZ3ci0K+Ld-M 3863 13.5.3. Scale-Change 3865 The server may be forced to change the rate of media time per 3866 playback time when a client requests delivery using a Scale 3867 (Section 18.46) value other than 1.0 (normal playback rate). For 3868 time progressing media with some retention, i.e., the server stores 3869 already sent content, a client requesting to play with Scale values 3870 larger than 1 may catch up with the front end of the media. The 3871 server will then be unable to continue to provide content at Scale 3872 larger than 1 as content is only made available by the server at 3873 Scale=1. Another case is when Scale < 1 and the media retention is 3874 time-duration limited. In this case the delivery point can reach the 3875 oldest media unit available, and further playback at this scale 3876 becomes impossible as there will be no media available. To avoid 3877 having the client lose any media, the scale will need to be adjusted 3878 to the same rate at which the media is removed from the storage 3879 buffer, commonly Scale = 1.0. 3881 Another case is when the content itself consists of spliced pieces or 3882 is dynamically updated. In these cases the server may be required to 3883 change from one supported scale value (different than Scale=1.0) to 3884 another. In this case the server will pick the closest value and 3885 inform the client of what it has picked. In these cases the media 3886 properties will also be sent updating the supported Scale values. 3887 This enables a client to adjust the Scale value used. 3889 To minimize impact on playback in any of the above cases the server 3890 MUST modify the playback properties and set Scale to a supportable 3891 value and continue delivery of the media. When doing this 3892 modification it MUST send a PLAY_NOTIFY message with the Notify- 3893 Reason header set to "scale-change". The request MUST contain a 3894 Range header with the media time when the change took effect, a Scale 3895 header with the new value in use, Session header with the identifier 3896 for the session it applies to and a Date header with the server 3897 wallclock time of the change. For time progressing content also the 3898 Media-Range and the Media-Properties at this point in time MUST be 3899 included. The Media-Properties header MUST be included if the scale 3900 change was due to the content changing what scale values that is 3901 supported. 3903 For media streams being delivered using RTP also a RTP-Info header 3904 MUST be included. It MUST contain the rtptime parameter with a value 3905 corresponding to the point of change in that media and optionally 3906 also the sequence number. 3908 PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated 3909 control URI in the request. The scale change for any aggregated 3910 session do apply to all media streams part of the aggregate. 3912 A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" 3913 MUST NOT carry a message body. 3915 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3916 Date: Tue, 14 Apr 2008 15:48:06 GMT 3917 CSeq: 854 3918 Notify-Reason: scale-change 3919 Session: uZ3ci0K+Ld-M 3920 Media-Properties: Time-Progressing, 3921 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3922 Media-Range: npt=0-1:37:21.394 3923 Range: npt=1:37:21.394- 3924 Scale: 1 3925 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" 3926 ssrc=0D12F123:rtptime=2345962545, 3927 url="rtsp://example.com/fizzle/videotrack" 3928 ssrc=789DAF12:seq=57654;rtptime=2792482193 3930 C->S: RTSP/2.0 200 OK 3931 CSeq: 854 3932 User-Agent: PhonyClient/1.2 3933 Session: uZ3ci0K+Ld-M 3935 13.6. PAUSE 3937 The PAUSE request causes the stream delivery to immediately be 3938 interrupted (halted). A PAUSE request MUST be done either with the 3939 aggregated control URI for aggregated sessions, resulting in all 3940 media being halted, or the media URI for non-aggregated sessions. 3942 Any attempt to do muting of a single media with a PAUSE request in an 3943 aggregated session MUST be responded to with error 460 (Only 3944 Aggregate Operation Allowed). After resuming playback, 3945 synchronization of the tracks MUST be maintained. Any server 3946 resources are kept, though servers MAY close the session and free 3947 resources after being paused for the duration specified with the 3948 timeout parameter of the Session header in the SETUP message. 3950 Example: 3952 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3953 CSeq: 834 3954 Session: 12345678 3955 User-Agent: PhonyClient/1.2 3957 S->C: RTSP/2.0 200 OK 3958 CSeq: 834 3959 Date: Thu, 23 Jan 1997 15:35:06 GMT 3960 Range: npt=45.76-75.00 3962 The PAUSE request causes stream delivery to be interrupted 3963 immediately on receipt of the message and the pause point is set to 3964 the current point in the presentation. That pause point in the media 3965 stream needs to be maintained. A subsequent PLAY request without 3966 Range header resumes from the pause point and plays until media end. 3968 The pause point after any PAUSE request MUST be returned to the 3969 client by adding a Range header with what remains unplayed of the 3970 PLAY request's range. For media with random access properties, if 3971 one desires to resume playing a ranged request, one simply includes 3972 the Range header from the PAUSE response and includes the Seek-Style 3973 header with the Next policy in the PLAY request. For media that is 3974 time-progressing and has retention duration=0 the follow-up PLAY 3975 request to start media delivery again, MUST use "npt=now-" and not 3976 the answer given in the response to PAUSE. 3978 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3979 CSeq: 834 3980 Session: 12345678 3981 Range: npt=10-30 3982 User-Agent: PhonyClient/1.2 3984 S->C: RTSP/2.0 200 OK 3985 CSeq: 834 3986 Date: Thu, 23 Jan 1997 15:35:06 GMT 3987 Server: PhonyServer/1.0 3988 Range: npt=10-30 3989 Seek-Style: First-Prior 3990 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3991 ssrc=0D12F123:seq=5712;rtptime=934207921, 3992 url="rtsp://example.com/fizzle/videotrack" 3993 ssrc=4FAD8726:seq=57654;rtptime=2792482193 3994 Session: 12345678 3996 After 11 seconds, i.e., at 21 seconds into the presentation: 3997 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3998 CSeq: 835 3999 Session: 12345678 4000 User-Agent: PhonyClient/1.2 4002 S->C: RTSP/2.0 200 OK 4003 CSeq: 835 4004 Date: 23 Jan 1997 15:35:17 GMT 4005 Server: PhonyServer/1.0 4006 Range: npt=21-30 4007 Session: 12345678 4009 If a client issues a PAUSE request and the server acknowledges and 4010 enters the Ready state, the proper server response, if the player 4011 issues another PAUSE, is still 200 OK. The 200 OK response MUST 4012 include the Range header with the current pause point. See examples 4013 below: 4015 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4016 CSeq: 834 4017 Session: 12345678 4018 User-Agent: PhonyClient/1.2 4020 S->C: RTSP/2.0 200 OK 4021 CSeq: 834 4022 Session: 12345678 4023 Date: Thu, 23 Jan 1997 15:35:06 GMT 4024 Range: npt=45.76-98.36 4026 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4027 CSeq: 835 4028 Session: 12345678 4029 User-Agent: PhonyClient/1.2 4031 S->C: RTSP/2.0 200 OK 4032 CSeq: 835 4033 Session: 12345678 4034 Date: 23 Jan 1997 15:35:07 GMT 4035 Range: npt=45.76-98.36 4037 13.7. TEARDOWN 4039 13.7.1. Client to Server 4041 The TEARDOWN client to server request stops the stream delivery for 4042 the given URI, freeing the resources associated with it. A TEARDOWN 4043 request MAY be performed on either an aggregated or a media control 4044 URI. However, some restrictions apply depending on the current 4045 state. The TEARDOWN request MUST contain a Session header indicating 4046 what session the request applies to. The TEARDOWN request MUST NOT 4047 include a Terminate-Reason header. 4049 A TEARDOWN using the aggregated control URI or the media URI in a 4050 session under non-aggregated control (single media session) MAY be 4051 done in any state (Ready and Play). A successful request MUST result 4052 in that media delivery being immediately halted and the session state 4053 being destroyed. This MUST be indicated through the lack of a 4054 Session header in the response. 4056 A TEARDOWN using a media URI in an aggregated session MAY only be 4057 done in Ready state. Such a request only removes the indicated media 4058 stream and associated resources from the session. This may result in 4059 a session returning to non-aggregated control, because it only 4060 contains a single media after the request's completion. A session 4061 that will exist after the processing of the TEARDOWN request MUST in 4062 the response to that TEARDOWN request contain a Session header. Thus 4063 the presence of the Session header indicates to the receiver of the 4064 response if the session is still existing or has been removed. 4066 Example: 4068 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 4069 CSeq: 892 4070 Session: 12345678 4071 User-Agent: PhonyClient/1.2 4073 S->C: RTSP/2.0 200 OK 4074 CSeq: 892 4075 Server: PhonyServer/1.0 4077 13.7.2. Server to Client 4079 The server can send TEARDOWN requests in the server to client 4080 direction to indicate that the server has been forced to terminate 4081 the ongoing session. This may happen for several reasons, such as 4082 server maintenance without available backup, or that the session has 4083 been inactive for extended periods of time. The reason is provided 4084 in the Terminate-Reason header (Section 18.52). 4086 When a RTSP client has maintained a RTSP session that otherwise is 4087 inactive for an extended period of time the server may reclaim the 4088 resources. That is done by issuing a TEARDOWN request with the 4089 Terminate-Reason set to "Session-Timeout". This MAY be done when the 4090 client has been inactive in the RTSP session for more than one 4091 Session Timeout period (Section 18.49). However, the server is 4092 RECOMMENDED to not perform this operation until an extended period of 4093 inactivity of 10 times the Session Timeout period has passed. It is 4094 to the operator of the RTSP server to actually configure how long 4095 this extended period of inactivity is. An operator should take into 4096 account when doing this configuration what the served content is and 4097 what this means for the extended period of inactivity. 4099 In case the server needs to stop providing service to the established 4100 sessions and there is no server to point at in a REDIRECT request, 4101 then TEARDOWN SHALL be used to terminate the session. This method 4102 can also be used when non-recoverable internal errors have happened 4103 and the server has no other option then to terminate the sessions. 4105 The TEARDOWN request MUST be done only on the session aggregate 4106 control URI (i.e., it is not allowed to terminate individual media 4107 streams, if it is a session aggregate) and MUST include the following 4108 headers; Session and Terminate-Reason headers. The request only 4109 applies to the session identified in the Session header. The server 4110 may include a message to the client's user with the "user-msg" 4111 parameter. 4113 The TEARDOWN request may alternatively be done on the wild card URI * 4114 and without any session header. The scope of such a request is 4115 limited to the next-hop (i.e., the RTSP agent in direct communication 4116 with the server) and applies, as well, to the RTSP connection between 4117 the next-hop RTSP agent and the server. This request indicates that 4118 all sessions and pending requests being managed via the connection 4119 are terminated. Any intervening proxies SHOULD do all of the 4120 following in the order listed: 4122 1. respond to the TEARDOWN request 4124 2. disconnect the control channel from the requesting server 4126 3. pass the TEARDOWN request to each applicable client (typically 4127 those clients with an active session or an unanswered request) 4129 Note: The proxy is responsible for accepting TEARDOWN responses 4130 from its clients; these responses MUST NOT be passed on to either 4131 the original server or the target server in the redirect. 4133 13.8. GET_PARAMETER 4135 The GET_PARAMETER request retrieves the value of any specified 4136 parameter or parameters for a presentation or stream specified in the 4137 URI. If the Session header is present in a request, the value of a 4138 parameter MUST be retrieved in the specified session context. There 4139 are two ways of specifying the parameters to be retrieved. 4141 The first is by including headers which have been defined such that 4142 you can use them for this purpose. Headers for this purpose should 4143 allow empty, or stripped value parts to avoid having to specify bogus 4144 data when indicating the desire to retrieve a value. The successful 4145 completion of the request should also be evident from any filled out 4146 values in the response. The headers in this specification that MAY 4147 be used for retrieving their current value using GET_PARAMETER below. 4148 Additional headers MAY be specified in the future: 4150 o Accept-Ranges 4152 o Media-Range 4154 o Media-Properties 4156 o Range 4157 o RTP-Info 4159 The other way is to specify a message body that lists the 4160 parameter(s) that are desired to be retrieved. The Content-Type 4161 header (Section 18.19) is used to specify which format the message 4162 body has. If the receiver of the request is not supporting the media 4163 type used for the message body, it SHALL respond using the error code 4164 415 (Unsupported Media Type). The responder to a GET_PARAMETER 4165 request MUST use the media type of the request for the response. For 4166 additional considerations regarding message body negotiation see 4167 Section 9.3. 4169 RTSP Agents implementing support for responding to GET_PARAMETER 4170 requests SHALL implement the text/parameters format (Appendix F). 4171 This to ensure that at least one known format for parameter are 4172 implemented and thus prevent parameter format negotiation failure. 4174 Parameters specified within the body of the message must all be 4175 understood by the request receiving agent. If one or more parameters 4176 are not understood a 451 (Parameter Not Understood) MUST be sent 4177 including a body listing these parameters that weren't understood. 4178 If all parameters are understood their values are filled in and 4179 returned in the response message body. 4181 The method MAY also be used without a message body or any header that 4182 requests parameters for keep-alive purpose. The keep-alive timer has 4183 been updated for any request that is successful, i.e., a 200 OK 4184 response is received. Any non-required header present in such a 4185 request may or may not have been processed. Normally the presence of 4186 filled out values in the header will be indication that the header 4187 has been processed. However, for cases when this is difficult to 4188 determine, it is recommended to use a feature-tag and the Require 4189 header. For this reason it is usually easier if any parameters to be 4190 retrieved are sent in the body, rather than using any header. 4192 Example: 4194 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4195 CSeq: 431 4196 User-Agent: PhonyClient/1.2 4197 Session: 12345678 4198 Content-Length: 26 4199 Content-Type: text/parameters 4201 packets_received 4202 jitter 4204 C->S: RTSP/2.0 200 OK 4205 CSeq: 431 4206 Session: 12345678 4207 Server: PhonyServer/1.1 4208 Date: Mon, 08 Mar 2010 13:43:23 GMT 4209 Content-Length: 38 4210 Content-Type: text/parameters 4212 packets_received: 10 4213 jitter: 0.3838 4215 13.9. SET_PARAMETER 4217 This method requests to set the value of a parameter or a set of 4218 parameters for a presentation or stream specified by the URI. The 4219 method MAY also be used without a message body. It is the 4220 RECOMMENDED method to be used in a request sent for the sole purpose 4221 of updating the keep-alive timer. If this request is successful, 4222 i.e., a 200 OK response is received, then the keep-alive timer has 4223 been updated. Any non-required header present in such a request may 4224 or may not have been processed. To allow a client to determine if 4225 any such header has been processed, it is necessary to use a feature 4226 tag and the Require header. Due to this reason it is RECOMMENDED 4227 that any parameters are sent in the body, rather than using any 4228 header. 4230 When using a message body to list the parameter(s) that are desired 4231 to be set the Content-Type header (Section 18.19) is used to specify 4232 which format the message body has. If the receiver of the request is 4233 not supporting the media type used for the message body, it SHALL 4234 respond using the error code 415 (Unsupported Media Type). For 4235 additional considerations regarding message body negotiation see 4236 Section 9.3. 4238 RTSP Agents implementing support for responding to SET_PARAMETER 4239 requests SHALL implement the text/parameters format (Appendix F). 4240 This to ensure that at least one known format for parameters are 4241 implemented and thus prevent parameter format negotiation failure. 4243 A request is RECOMMENDED to only contain a single parameter to allow 4244 the client to determine why a particular request failed. If the 4245 request contains several parameters, the server MUST only act on the 4246 request if all of the parameters can be set successfully. A server 4247 MUST allow a parameter to be set repeatedly to the same value, but it 4248 MAY disallow changing parameter values. If the receiver of the 4249 request does not understand or cannot locate a parameter, error 451 4250 (Parameter Not Understood) MUST be used. When a parameter is not 4251 allowed to change, the error code is 458 (Parameter Is Read-Only). 4252 The response body MUST contain only the parameters that have errors. 4253 Otherwise no body MUST be returned. The response body MUST use the 4254 media type of the request for the response. 4256 Note: transport parameters for the media stream MUST only be set with 4257 the SETUP command. 4259 Restricting setting transport parameters to SETUP is for the 4260 benefit of firewalls. 4262 The parameters are split in a fine-grained fashion so that there 4263 can be more meaningful error indications. However, it may make 4264 sense to allow the setting of several parameters if an atomic 4265 setting is desirable. Imagine device control where the client 4266 does not want the camera to pan unless it can also tilt to the 4267 right angle at the same time. 4269 Example: 4271 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4272 CSeq: 421 4273 User-Agent: PhonyClient/1.2 4274 Session: iixT43KLc 4275 Date: Mon, 08 Mar 2010 14:45:04 GMT 4276 Content-length: 20 4277 Content-type: text/parameters 4279 barparam: barstuff 4281 S->C: RTSP/2.0 451 Parameter Not Understood 4282 CSeq: 421 4283 Session: iixT43KLc 4284 Server: PhonyServer/1.0 4285 Date: Mon, 08 Mar 2010 14:44:56 GMT 4286 Content-length: 20 4287 Content-type: text/parameters 4289 barparam: barstuff 4291 13.10. REDIRECT 4293 The REDIRECT method is issued by a server to inform a client that the 4294 service provided will be terminated and where a corresponding service 4295 can be provided instead. This may happen for different reasons. One 4296 is that the server is being administered such that it must stop 4297 providing service. Thus the client is required to connect to another 4298 server location to access the resource indicated by the Request-URI. 4300 The REDIRECT request SHALL contain a Terminate-Reason header 4301 (Section 18.52) to inform the client of the reason for the request. 4302 Additional parameters related to the reason may also be included. 4303 The intention here is to allow a server administrator to do a 4304 controlled shutdown of the RTSP server. That requires sufficient 4305 time to inform all entities having associated state with the server 4306 and for them to perform a controlled migration from this server to a 4307 fall back server. 4309 A REDIRECT request with a Session header has end-to-end (i.e., server 4310 to client) scope and applies only to the given session. Any 4311 intervening proxies SHOULD NOT disconnect the control channel while 4312 there are other remaining end-to-end sessions. The REQUIRED Location 4313 header MUST contain a complete absolute URI pointing to the resource 4314 to which the client SHOULD reconnect. Specifically, the Location 4315 MUST NOT contain just the host and port. A client may receive a 4316 REDIRECT request with a Session header, if and only if, an end-to-end 4317 session has been established. 4319 A client may receive a REDIRECT request without a Session header at 4320 any time when it has communication or a connection established with a 4321 server. The scope of such a request is limited to the next-hop 4322 (i.e., the RTSP agent in direct communication with the server) and 4323 applies to all sessions controlled, as well as the connection between 4324 the next-hop RTSP agent and the server. A REDIRECT request without a 4325 Session header indicates that all sessions and pending requests being 4326 managed via the connection MUST be redirected. The Location header, 4327 if included in such a request, SHOULD contain an absolute URI with 4328 only the host address and the OPTIONAL port number of the server to 4329 which the RTSP agent SHOULD reconnect. Any intervening proxies 4330 SHOULD do all of the following in the order listed: 4332 1. respond to the REDIRECT request 4334 2. disconnect the control channel from the requesting server 4336 3. connect to the server at the given host address 4337 4. pass the REDIRECT request to each applicable client (typically 4338 those clients with an active session or an unanswered request) 4340 Note: The proxy is responsible for accepting REDIRECT responses 4341 from its clients; these responses MUST NOT be passed on to either 4342 the original server or the redirected server. 4344 When the server lacks any alternative server and needs to terminate a 4345 session or all sessions the TEARDOWN request SHALL be used instead. 4347 When no Terminate-Reason "time" parameter is included in a REDIRECT 4348 request, the client SHALL perform the redirection immediately and 4349 return a response to the server. The server shall consider the 4350 session as terminated and can free any associated state after it 4351 receives the successful (2xx) response. The server MAY close the 4352 signaling connection upon receiving the response and the client 4353 SHOULD close the signaling connection after sending the 2xx response. 4354 The exception to this is when the client has several sessions on the 4355 server being managed by the given signaling connection. In this 4356 case, the client SHOULD close the connection when it has received and 4357 responded to REDIRECT requests for all the sessions managed by the 4358 signaling connection. 4360 The Terminate-Reason header "time" parameter MAY be used to indicate 4361 the wallclock time by when the redirection MUST have taken place. To 4362 allow a client to determine that redirect time without being time 4363 synchronized with the server, the server MUST include a Date header 4364 in the request. The client should have terminated the session and 4365 closed the connection before the redirection time-line terminated. 4366 The server MAY simply cease to provide service when the deadline time 4367 has been reached, or it may issue TEARDOWN requests to the remaining 4368 sessions. 4370 If the REDIRECT request times out following the rules in Section 10.4 4371 the server MAY terminate the session or transport connection that 4372 would be redirected by the request. This is a safeguard against 4373 misbehaving clients that refuse to respond to a REDIRECT request. 4374 Thus, removing any incentive to not acknowledge the reception of a 4375 REDIRECT request. 4377 After a REDIRECT request has been processed, a client that wants to 4378 continue to receive media for the resource identified by the Request- 4379 URI will have to establish a new session with the designated host. 4380 If the URI given in the Location header is a valid resource URI, a 4381 client SHOULD issue a DESCRIBE request for the URI. 4383 Note: The media resource indicated by the Location header can be 4384 identical, slightly different or totally different. This is the 4385 reason why a new DESCRIBE request SHOULD be issued. 4387 If the Location header contains only a host address, the client MAY 4388 assume that the media on the new server is identical to the media on 4389 the old server, i.e., all media configuration information from the 4390 old session is still valid except for the host address. However, the 4391 usage of conditional SETUP using MTag identifiers is RECOMMENDED as a 4392 means to verify the assumption. 4394 This example request redirects traffic for this session to the new 4395 server at the given absolute time: 4397 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 4398 CSeq: 732 4399 Location: rtsp://s2.example.com:8001 4400 Terminate-Reason: Server-Admin ;time=19960213T143205Z 4401 Session: uZ3ci0K+Ld-M 4402 Date: Thu, 13 Feb 1996 14:30:43 GMT 4404 C->S: RTSP/2.0 200 OK 4405 CSeq: 732 4406 User-Agent: PhonyClient/1.2 4407 Session: uZ3ci0K+Ld-M 4409 14. Embedded (Interleaved) Binary Data 4411 In order to fulfill certain requirements on the network side, e.g., 4412 in conjunction with network address translators that block RTP 4413 traffic over UDP, it may be necessary to interleave RTSP messages and 4414 media stream data. This interleaving should generally be avoided 4415 unless necessary since it complicates client and server operation and 4416 imposes additional overhead. Also, head of line blocking may cause 4417 problems. Interleaved binary data SHOULD only be used if RTSP is 4418 carried over TCP. Interleaved data is not allowed inside RTSP 4419 messages. 4421 Stream data such as RTP packets is encapsulated by an ASCII dollar 4422 sign (36 decimal), followed by a one-octet channel identifier, 4423 followed by the length of the encapsulated binary data as a binary, 4424 two-octet unsigned integer in network byte order. The stream data 4425 follows immediately afterwards, without a CRLF, but including the 4426 upper-layer protocol headers. Each $ block MUST contain exactly one 4427 upper-layer protocol data unit, e.g., one RTP packet. 4429 Note that this mechanism does not support larger PDUs than 65535 4430 bytes, which is the same that regular IPv4 and IPv6 is capable. 4431 If the media delivery protocol intended to be used has larger PDUs 4432 than that, the definition of such mechanisms usage of this 4433 mechanism will require the definition of a PDU fragmentation 4434 mechanism. 4436 0 1 2 3 4437 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 4438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4439 | "$" = 36 | Channel ID | Length in octets | 4440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4441 : Binary data (Length according to Length field) : 4442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4444 Figure 1: Embedded Interleaved Binary Data Format 4446 The channel identifier is defined in the Transport header with the 4447 interleaved parameter (Section 18.54). 4449 When the transport choice is RTP, RTCP messages are also interleaved 4450 by the server over the TCP connection. The usage of RTCP messages is 4451 indicated by including an interval containing a second channel in the 4452 interleaved parameter of the Transport header, see Section 18.54. If 4453 RTCP is used, packets MUST be sent on the first available channel 4454 higher than the RTP channel. The channels are bi-directional, using 4455 the same Channel ID in both directions, and therefore RTCP traffic is 4456 sent on the second channel in both directions. 4458 RTCP is sometimes needed for synchronization when two or more 4459 streams are interleaved in such a fashion. Also, this provides a 4460 convenient way to tunnel RTP/RTCP packets through the RTSP 4461 connection (TCP or TCP/TLS) when required by the network 4462 configuration and transfer them onto UDP when possible. 4464 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 4465 CSeq: 2 4466 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 4467 Accept-Ranges: npt, smpte, clock 4468 User-Agent: PhonyClient/1.2 4470 S->C: RTSP/2.0 200 OK 4471 CSeq: 2 4472 Date: Thu, 05 Jun 1997 18:57:18 GMT 4473 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 4474 Session: 12345678 4475 Accept-Ranges: npt 4476 Media-Properties: Random-Access=0.2, Immutable, Unlimited 4478 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 4479 CSeq: 3 4480 Session: 12345678 4481 User-Agent: PhonyClient/1.2 4483 S->C: RTSP/2.0 200 OK 4484 CSeq: 3 4485 Session: 12345678 4486 Date: Thu, 05 Jun 1997 18:57:19 GMT 4487 RTP-Info: url="rtsp://example.com/bar.file" 4488 ssrc=0D12F123:seq=232433;rtptime=972948234 4489 Range: npt=0-56.8 4490 Seek-Style: RAP 4492 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4493 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4494 S->C: $006{2 octet length}{"length" octets RTCP packet} 4496 15. Proxies 4498 RTSP Proxies are RTSP agents that are located in between a client and 4499 a server. A proxy can take on both the role as a client and as 4500 server depending on what it tries to accomplish. RTSP proxies use 4501 two transport layer connections, one from the RTSP client to the RTSP 4502 proxy and a second from the RTSP proxy to the RTSP server. Proxies 4503 are introduced for several different reasons and the below listed are 4504 often combined. 4506 There are these types of RTSP proxies: 4508 Caching Proxy: This type of proxy is used to reduce the workload on 4509 servers and connections. By caching the description and media 4510 streams, i.e., the presentation, the proxy can serve a client 4511 with content, but without requesting it from the server once it 4512 has been cached and has not become stale. See the caching 4513 Section 16. This type of proxy is also expected to understand 4514 RTSP end-point functionality, i.e., functionality identified in 4515 the Require header in addition to what Proxy-Require demands. 4517 Translator Proxy: This type of proxy is used to ensure that an RTSP 4518 client gets access to servers and content on an external 4519 network or using content encodings not supported by the client. 4520 The proxy performs the necessary translation of addresses, 4521 protocols or encodings. This type of proxy is expected to also 4522 understand RTSP end-point functionality, i.e., functionality 4523 identified in the Require header in addition to what Proxy- 4524 Require demands. 4526 Access Proxy: This type of proxy is used to ensure that an RTSP 4527 client gets access to servers on an external network. Thus 4528 this proxy is placed on the border between two domains, e.g., a 4529 private address space and the public Internet. The proxy 4530 performs the necessary translation, usually addresses. This 4531 type of proxy is required to redirect the media to itself or a 4532 controlled gateway that performs the translation before the 4533 media can reach the client. 4535 Security Proxy: This type of proxy is used to help facilitate 4536 security functions around RTSP. For example when having a 4537 firewalled network, the security proxy requests that the 4538 necessary pinholes in the firewall are opened when a client in 4539 the protected network wants to access media streams on the 4540 external side. This proxy can also limit the client's access 4541 to certain types of content. This proxy can perform its 4542 function without redirecting the media between the server and 4543 client. However, in deployments with private address spaces 4544 this proxy is likely to be combined with the access proxy. 4545 Anyway, the functionality of this proxy is usually closely tied 4546 into understanding all aspects of the media transport. 4548 Auditing Proxy: RTSP proxies can also provide network owners with a 4549 logging and audit point for RTSP sessions, e.g., for 4550 corporations that track their employees usage of the network. 4551 This type of proxy can perform its function without inserting 4552 itself or any other node in the media transport. This proxy 4553 type can also accept unknown methods as it doesn't interfere 4554 with the clients' requests. 4556 All types of proxies can be used also when using secured 4557 communication with TLS as RTSP 2.0 allows the client to approve 4558 certificate chains used for connection establishment from a proxy, 4559 see Section 19.3.2. However, that trust model may not be suitable 4560 for all types of deployment. In those cases, the secured sessions do 4561 by-pass the proxies. 4563 Access proxies SHOULD NOT be used in equipment like NATs and 4564 firewalls that aren't expected to be regularly maintained, like home 4565 or small office equipment. In these cases it is better to use the 4566 NAT traversal procedures defined for RTSP 2.0 4567 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 4568 that any extensions of RTSP resulting in new media transport 4569 protocols or profiles, new parameters, etc. may fail in a proxy that 4570 isn't maintained. This would impede RTSP's future development and 4571 usage. 4573 15.1. Proxies and Protocol Extensions 4575 The existence of proxies must always be considered when developing 4576 new RTSP extensions. Most types of proxies will need to implement 4577 any new method to operate correctly in the presence of that 4578 extension. New headers can be introduced and will not be blocked by 4579 older proxies. However, it is important to consider if this header 4580 and its function is required to be understood by the proxy or can be 4581 forwarded. If the header needs to be understood, a feature-tag 4582 representing the functionality MUST be included in the Proxy-Require 4583 header. Below are guidelines for analysis if the header needs to be 4584 understood. The transport header and its parameters also shows that 4585 headers that are extensible and require correct interpretation in the 4586 proxy also require handling rules. 4588 Whether a proxy needs to understand a header is not easy to 4589 determine, as they serve a broad variety of functions. When 4590 evaluating if a header needs to be understood, one can divide the 4591 functionality into three main categories: 4593 Media modifying: The caching and translator proxies are modifying 4594 the actual media and therefore need to understand also the request 4595 directed to the server that affects how the media is rendered. 4596 Thus, this type of proxy needs to also understand the server side 4597 functionality. 4599 Transport modifying: The access and the security proxy both need to 4600 understand how the transport is performed, either for opening 4601 pinholes or to translate the outer headers, e.g., IP and UDP. 4603 Non-modifying: The audit proxy is special in that it does not modify 4604 the messages in other ways than to insert the Via header. That 4605 makes it possible for this type to forward RTSP messages that 4606 contain different types of unknown methods, headers or header 4607 parameters. 4609 Based on the above classification, one should evaluate if the new 4610 functionality requires the Transport modifying type of proxies to 4611 understand it or not. 4613 15.2. Multiplexing and Demultiplexing of Messages 4615 RTSP proxies may have to multiplex multiple RTSP sessions from their 4616 clients towards RTSP servers. This requires that RTSP requests from 4617 multiple clients are multiplexed onto a common connection for 4618 requests outgoing to an RTSP server and on the way back the responses 4619 are demultiplexed from the server to per client responses. On the 4620 protocol level this requires that request and response messages are 4621 handled in both ways, requiring that there is a mechanism to 4622 correlate what request/response pair exchanged between proxy and 4623 server is mapped to what client (or client request). 4625 This multiplexing of requests and demultiplexing of responses is done 4626 by using the CSeq header field. The proxy has to rewrite the CSeq in 4627 requests to the server and responses from the server and remember 4628 what CSeq is mapped to what client. The proxy also needs to ensure 4629 that the order of the message related to each client is maintained. 4630 Section 18.20 is defining the handling of how requests and responses 4631 are rewritten. 4633 16. Caching 4635 In HTTP, request-response pairs are cached. RTSP differs 4636 significantly in that respect. Responses are not cacheable, with the 4637 exception of the presentation description returned by DESCRIBE. 4638 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4639 not return any data, caching is not really an issue for these 4640 requests.) However, it is desirable for the continuous media data, 4641 typically delivered out-of-band with respect to RTSP, to be cached, 4642 as well as the session description. 4644 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4645 has an up-to-date copy of the continuous media content and its 4646 description. It can determine whether the copy is up-to-date by 4647 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4648 Last-Modified header with that of the cached copy. If the copy is 4649 not up-to-date, it modifies the SETUP transport parameters as 4650 appropriate and forwards the request to the origin server. 4651 Subsequent control commands such as PLAY or PAUSE then pass the proxy 4652 unmodified. The proxy delivers the continuous media data to the 4653 client, while possibly making a local copy for later reuse. The 4654 exact allowed behavior of the cache is given by the cache-response 4655 directives described in Section 18.11. A cache MUST answer any 4656 DESCRIBE requests if it is currently serving the stream to the 4657 requester, as it is possible that low-level details of the stream 4658 description may have changed on the origin-server. 4660 Note that an RTSP cache, is of the "cut-through" variety. Rather 4661 than retrieving the whole resource from the origin server, the cache 4662 simply copies the streaming data as it passes by on its way to the 4663 client. Thus, it does not introduce additional latency. 4665 To the client, an RTSP proxy cache appears like a regular media 4666 server. To the media origin server an RTSP proxy cache appears like 4667 a client. Just as an HTTP cache has to store the content type, 4668 content language, and so on for the objects it caches, a media cache 4669 has to store the presentation description. Typically, a cache 4670 eliminates all transport-references (e.g., multicast information) 4671 from the presentation description, since these are independent of the 4672 data delivery from the cache to the client. Information on the 4673 encodings remains the same. If the cache is able to translate the 4674 cached media data, it would create a new presentation description 4675 with all the encoding possibilities it can offer. 4677 16.1. Validation Model 4679 When a cache has a stale entry that it would like to use as a 4680 response to a client's request, it first has to check with the origin 4681 server (or possibly an intermediate cache with a fresh response) to 4682 see if its cached entry is still usable. We call this "validating" 4683 the cache entry. Since we do not want to have to pay the overhead of 4684 retransmitting the full response if the cached entry is good, and we 4685 do not want to pay the overhead of an extra round trip if the cached 4686 entry is invalid, the RTSP protocol supports the use of conditional 4687 methods. 4689 The key protocol features for supporting conditional methods are 4690 those concerned with "cache validators." When an origin server 4691 generates a full response, it attaches some sort of validator to it, 4692 which is kept with the cache entry. When a client (user agent or 4693 proxy cache) makes a conditional request for a resource for which it 4694 has a cache entry, it includes the associated validator in the 4695 request. 4697 The server then checks that validator against the current validator 4698 for the requested resource, and, if they match (see Section 16.1.3), 4699 it responds with a special status code (usually, 304 (Not Modified)) 4700 and no message body. Otherwise, it returns a full response 4701 (including message body). Thus, we avoid transmitting the full 4702 response if the validator matches, and we avoid an extra round trip 4703 if it does not match. 4705 In RTSP, a conditional request looks exactly the same as a normal 4706 request for the same resource, except that it carries a special 4707 header (which includes the validator) that implicitly turns the 4708 method (usually DESCRIBE or SETUP) into a conditional. 4710 The protocol includes both positive and negative senses of cache- 4711 validating conditions. That is, it is possible to request either 4712 that a method be performed if and only if a validator matches or if 4713 and only if no validators match. 4715 Note: a response that lacks a validator may still be cached, and 4716 served from cache until it expires, unless this is explicitly 4717 prohibited by a cache-control directive (see Section 18.11). 4718 However, a cache cannot do a conditional retrieval if it does not 4719 have a validator for the resource, which means it will not be 4720 refreshable after it expires. 4722 Media streams that are being adapted based on the transport capacity 4723 between the server and the cache makes caching more difficult. A 4724 server needs to consider how it views caching of media streams that 4725 it adapts and potentially instruct any caches to not cache such 4726 streams. 4728 16.1.1. Last-Modified Dates 4730 The Last-Modified header (Section 18.27) value is often used as a 4731 cache validator. In simple terms, a cache entry is considered to be 4732 valid if the content has not been modified since the Last-Modified 4733 value. 4735 16.1.2. Message Body Tag Cache Validators 4737 The MTag response-header field value, a message body tag, provides 4738 for an "opaque" cache validator. This might allow more reliable 4739 validation in situations where it is inconvenient to store 4740 modification dates, where the one-second resolution of RTSP-date 4741 values is not sufficient, or where the origin server wishes to avoid 4742 certain paradoxes that might arise from the use of modification 4743 dates. 4745 Message body tags are described in Section 4.6 4747 16.1.3. Weak and Strong Validators 4749 Since both origin servers and caches will compare two validators to 4750 decide if they represent the same or different entities, one normally 4751 would expect that if the message body (i.e., the presentation 4752 description) or any associated message body headers changes in any 4753 way, then the associated validator would change as well. If this is 4754 true, then we call this validator a "strong validator." We call 4755 message body (i.e., the presentation description) or any associated 4756 message body headers an entity for a better understanding. 4758 However, there might be cases when a server prefers to change the 4759 validator only on semantically significant changes, and not when 4760 insignificant aspects of the entity change. A validator that does 4761 not always change when the resource changes is a "weak validator." 4763 Message body tags are normally "strong validators," but the protocol 4764 provides a mechanism to tag a message body tag as "weak." One can 4765 think of a strong validator as one that changes whenever the bits of 4766 an entity changes, while a weak value changes whenever the meaning of 4767 an entity changes. Alternatively, one can think of a strong 4768 validator as part of an identifier for a specific entity, while a 4769 weak validator is part of an identifier for a set of semantically 4770 equivalent entities. 4772 Note: One example of a strong validator is an integer that is 4773 incremented in stable storage every time an entity is changed. 4775 An entity's modification time, if represented with one-second 4776 resolution, could be a weak validator, since it is possible that 4777 the resource might be modified twice during a single second. 4779 Support for weak validators is optional. However, weak validators 4780 allow for more efficient caching of equivalent objects. 4782 A "use" of a validator is either when a client generates a request 4783 and includes the validator in a validating header field, or when a 4784 server compares two validators. 4786 Strong validators are usable in any context. Weak validators are 4787 only usable in contexts that do not depend on exact equality of an 4788 entity. For example, either kind is usable for a conditional 4789 DESCRIBE of a full entity. However, only a strong validator is 4790 usable for a sub-range retrieval, since otherwise the client might 4791 end up with an internally inconsistent entity. 4793 Clients MAY issue DESCRIBE requests with either weak validators or 4794 strong validators. Clients MUST NOT use weak validators in other 4795 forms of requests. 4797 The only function that the RTSP protocol defines on validators is 4798 comparison. There are two validator comparison functions, depending 4799 on whether the comparison context allows the use of weak validators 4800 or not: 4802 o The strong comparison function: in order to be considered equal, 4803 both validators MUST be identical in every way, and both MUST NOT 4804 be weak. 4806 o The weak comparison function: in order to be considered equal, 4807 both validators MUST be identical in every way, but either or both 4808 of them MAY be tagged as "weak" without affecting the result. 4810 A message body tag is strong unless it is explicitly tagged as weak. 4812 A Last-Modified time, when used as a validator in a request, is 4813 implicitly weak unless it is possible to deduce that it is strong, 4814 using the following rules: 4816 o The validator is being compared by an origin server to the actual 4817 current validator for the entity and, 4819 o That origin server reliably knows that the associated entity did 4820 not change more than once during the second covered by the 4821 presented validator. 4823 OR 4825 o The validator is about to be used by a client in an If-Modified- 4826 Since, because the client has a cache entry for the associated 4827 entity, and 4829 o That cache entry includes a Date value, which gives the time when 4830 the origin server sent the original response, and 4832 o The presented Last-Modified time is at least 60 seconds before the 4833 Date value. 4835 OR 4837 o The validator is being compared by an intermediate cache to the 4838 validator stored in its cache entry for the entity, and 4840 o That cache entry includes a Date value, which gives the time when 4841 the origin server sent the original response, and 4843 o The presented Last-Modified time is at least 60 seconds before the 4844 Date value. 4846 This method relies on the fact that if two different responses were 4847 sent by the origin server during the same second, but both had the 4848 same Last-Modified time, then at least one of those responses would 4849 have a Date value equal to its Last-Modified time. The arbitrary 60- 4850 second limit guards against the possibility that the Date and Last- 4851 Modified values are generated from different clocks, or at somewhat 4852 different times during the preparation of the response. An 4853 implementation MAY use a value larger than 60 seconds, if it is 4854 believed that 60 seconds is too short. 4856 If a client wishes to perform a sub-range retrieval on a value for 4857 which it has only a Last-Modified time and no opaque validator, it 4858 MAY do this only if the Last-Modified time is strong in the sense 4859 described here. 4861 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates 4863 We adopt a set of rules and recommendations for origin servers, 4864 clients, and caches regarding when various validator types ought to 4865 be used, and for what purposes. 4867 RTSP origin servers: 4869 o SHOULD send a message body tag validator unless it is not feasible 4870 to generate one. 4872 o MAY send a weak message body tag instead of a strong message body 4873 tag, if performance considerations support the use of weak message 4874 body tags, or if it is unfeasible to send a strong message body 4875 tag. 4877 o SHOULD send a Last-Modified value if it is feasible to send one, 4878 unless the risk of a breakdown in semantic transparency that could 4879 result from using this date in an If-Modified-Since header would 4880 lead to serious problems. 4882 In other words, the preferred behavior for an RTSP origin server is 4883 to send both a strong message body tag and a Last-Modified value. 4885 In order to be legal, a strong message body tag MUST change whenever 4886 the associated entity value changes in any way. A weak message body 4887 tag SHOULD change whenever the associated entity changes in a 4888 semantically significant way. 4890 Note: in order to provide semantically transparent caching, an 4891 origin server MUST avoid reusing a specific strong message body 4892 tag value for two different entities, or reusing a specific weak 4893 message body tag value for two semantically different entities. 4894 Cache entries might persist for arbitrarily long periods, 4895 regardless of expiration times, so it might be inappropriate to 4896 expect that a cache will never again attempt to validate an entry 4897 using a validator that it obtained at some point in the past. 4899 RTSP clients: 4901 o If a message body tag has been provided by the origin server, MUST 4902 use that message body tag in any cache-conditional request (using 4903 If-Match or If-None-Match). 4905 o If only a Last-Modified value has been provided by the origin 4906 server, SHOULD use that value in non-subrange cache-conditional 4907 requests (using If-Modified-Since). 4909 o If both a message body tag and a Last-Modified value have been 4910 provided by the origin server, SHOULD use both validators in 4911 cache-conditional requests. 4913 An RTSP origin server, upon receiving a conditional request that 4914 includes both a Last-Modified date (e.g., in an If-Modified-Since 4915 header) and one or more message body tags (e.g., in an If-Match, If- 4916 None-Match, or If-Range header field) as cache validators, MUST NOT 4917 return a response status of 304 (Not Modified) unless doing so is 4918 consistent with all of the conditional header fields in the request. 4920 Note: The general principle behind these rules is that RTSP 4921 servers and clients should transmit as much non-redundant 4922 information as is available in their responses and requests. RTSP 4923 systems receiving this information will make the most conservative 4924 assumptions about the validators they receive. 4926 16.1.5. Non-validating Conditionals 4928 The principle behind message body tags is that only the service 4929 author knows the semantics of a resource well enough to select an 4930 appropriate cache validation mechanism, and the specification of any 4931 validator comparison function more complex than octet-equality would 4932 open up a can of worms. Thus, comparisons of any other headers are 4933 never used for purposes of validating a cache entry. 4935 16.2. Invalidation After Updates or Deletions 4937 The effect of certain methods performed on a resource at the origin 4938 server might cause one or more existing cache entries to become non- 4939 transparently invalid. That is, although they might continue to be 4940 "fresh," they do not accurately reflect what the origin server would 4941 return for a new request on that resource. 4943 There is no way for the RTSP protocol to guarantee that all such 4944 cache entries are marked invalid. For example, the request that 4945 caused the change at the origin server might not have gone through 4946 the proxy where a cache entry is stored. However, several rules help 4947 reduce the likelihood of erroneous behavior. 4949 In this section, the phrase "invalidate an entity" means that the 4950 cache will either remove all instances of that entity from its 4951 storage, or will mark these as "invalid" and in need of a mandatory 4952 revalidation before they can be returned in response to a subsequent 4953 request. 4955 Some RTSP methods MUST cause a cache to invalidate an entity. This 4956 is either the entity referred to by the Request-URI, or by the 4957 Location or Content-Location headers (if present). These methods 4958 are: 4960 o DESCRIBE 4961 o SETUP 4963 In order to prevent denial of service attacks, an invalidation based 4964 on the URI in a Location or Content-Location header MUST only be 4965 performed if the host part is the same as in the Request-URI. 4967 A cache that passes through requests for methods it does not 4968 understand SHOULD invalidate any entities referred to by the Request- 4969 URI. 4971 17. Status Code Definitions 4973 Where applicable, HTTP status [H10] codes are reused. See Table 4 in 4974 Section 8.1 for a listing of which status codes may be returned by 4975 which requests. All error messages, 4xx and 5xx MAY return a body 4976 containing further information about the error. 4978 17.1. Success 1xx 4980 17.1.1. 100 Continue 4982 The client SHOULD continue with its request. This interim response 4983 is used to inform the client that the initial part of the request has 4984 been received and has not yet been rejected by the server. The 4985 client SHOULD continue by sending the remainder of the request or, if 4986 the request has already been completed, ignore this response. The 4987 server MUST send a final response after the request has been 4988 completed. 4990 17.2. Success 2xx 4992 This class of status code indicates that the client's request was 4993 successfully received, understood, and accepted. 4995 17.2.1. 200 OK 4997 The request has succeeded. The information returned with the 4998 response is dependent on the method used in the request. 5000 17.3. Redirection 3xx 5002 The notation "3xx" indicates response codes from 300 to 399 inclusive 5003 which are meant for redirection. The response code 304 is excluded, 5004 as it is not used for redirection and instead the "3rr" notation is 5005 used. The 304 response code appears here, rather than a 2xx response 5006 code which would have been appropriate, this as 304 has been used 5007 also in RTSP 1.0 [RFC2326]. 5009 Within RTSP, redirection may be used for load balancing or 5010 redirecting stream requests to a server topologically closer to the 5011 client. Mechanisms to determine topological proximity are beyond the 5012 scope of this specification. 5014 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 5015 that they are used if necessary before a session is established, 5016 i.e., in response to DESCRIBE or SETUP. However, in cases where a 5017 server is not able to send a REDIRECT request to the client, the 5018 server MAY need to resort to using 3rr responses to inform a client 5019 with an established session about the need for redirecting the 5020 session. If a 3rr response is received for a request in relation to 5021 an established session, the client SHOULD send a TEARDOWN request for 5022 the session, and MAY reestablish the session using the resource 5023 indicated by the Location. 5025 If the Location header is used in a response it MUST contain an 5026 absolute URI pointing out the media resource the client is redirected 5027 to, the URI MUST NOT only contain the host name. 5029 17.3.1. 300 5031 This response code is not used in RTSP 2.0. For behavior to use with 5032 unknown 3rr status codes, one follows the 302 (Section 17.3.3). 5034 17.3.2. 301 Moved Permanently 5036 The requested resource is moved permanently and resides now at the 5037 URI given by the Location header. The user client SHOULD redirect 5038 automatically to the given URI. This response MUST NOT contain a 5039 message-body. The Location header MUST be included in the response. 5041 17.3.3. 302 Found 5043 The requested resource resides temporarily at the URI given by the 5044 Location header. The Location header MUST be included in the 5045 response. This response is intended to be used for many types of 5046 temporary redirects; e.g., load balancing. It is RECOMMENDED that 5047 the server set the reason phrase to something more meaningful than 5048 "Found" in these cases. The user client SHOULD redirect 5049 automatically to the given URI. This response MUST NOT contain a 5050 message-body. 5052 This example shows a client being redirected to a different server: 5054 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 5055 CSeq: 2 5056 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 5057 Accept-Ranges: npt, smpte, clock 5058 User-Agent: PhonyClient/1.2 5060 S->C: RTSP/2.0 302 Try Other Server 5061 CSeq: 2 5062 Location: rtsp://s2.example.com:8001/fizzle/foo 5064 17.3.4. 303 See Other 5066 This status code MUST NOT be used in RTSP 2.0. However, it was 5067 allowed in RTSP 1.0 [RFC2326]. 5069 17.3.5. 304 Not Modified 5071 If the client has performed a conditional DESCRIBE or SETUP (see 5072 Section 18.25) and the requested resource has not been modified, the 5073 server SHOULD send a 304 response. This response MUST NOT contain a 5074 message-body. 5076 The response MUST include the following header fields: 5078 o Date 5080 o MTag and/or Content-Location, if the header(s) would have been 5081 sent in a 200 response to the same request. 5083 o Expires and Cache-Control if the field-value might differ from 5084 that sent in any previous response for the same variant. 5086 This response is independent for the DESCRIBE and SETUP requests. 5087 That is, a 304 response to DESCRIBE does NOT imply that the resource 5088 content is unchanged (only the session description) and a 304 5089 response to SETUP does NOT imply that the resource description is 5090 unchanged. The MTag and If-Match headers may be used to link the 5091 DESCRIBE and SETUP in this manner. 5093 17.3.6. 305 Use Proxy 5095 The requested resource MUST be accessed through the proxy given by 5096 the Location field. The Location field gives the URI of the proxy. 5097 The recipient is expected to repeat this single request via the 5098 proxy. 305 responses MUST only be generated by origin servers. 5100 17.4. Client Error 4xx 5102 17.4.1. 400 Bad Request 5104 The request could not be understood by the server due to malformed 5105 syntax. The client SHOULD NOT repeat the request without 5106 modifications. If the request does not have a CSeq header, the 5107 server MUST NOT include a CSeq in the response. 5109 17.4.2. 401 Unauthorized 5111 The request requires user authentication. The response MUST include 5112 a WWW-Authenticate header (Section 18.58) field containing a 5113 challenge applicable to the requested resource. The client MAY 5114 repeat the request with a suitable Authorization header field. If 5115 the request already included Authorization credentials, then the 401 5116 response indicates that authorization has been refused for those 5117 credentials. If the 401 response contains the same challenge as the 5118 prior response, and the user agent has already attempted 5119 authentication at least once, then the user SHOULD be presented the 5120 message body that was given in the response, since that message body 5121 might include relevant diagnostic information. HTTP access 5122 authentication is explained in [RFC2617]. 5124 17.4.3. 402 Payment Required 5126 This code is reserved for future use. 5128 17.4.4. 403 Forbidden 5130 The server understood the request, but is refusing to fulfill it. 5131 Authorization will not help and the request SHOULD NOT be repeated. 5132 If the server wishes to make public why the request has not been 5133 fulfilled, it SHOULD describe the reason for the refusal in the 5134 message body. If the server does not wish to make this information 5135 available to the client, the status code 404 (Not Found) can be used 5136 instead. 5138 17.4.5. 404 Not Found 5140 The server has not found anything matching the Request-URI. No 5141 indication is given of whether the condition is temporary or 5142 permanent. The 410 (Gone) status code SHOULD be used if the server 5143 knows, through some internally configurable mechanism, that an old 5144 resource is permanently unavailable and has no forwarding address. 5145 This status code is commonly used when the server does not wish to 5146 reveal exactly why the request has been refused, or when no other 5147 response is applicable. 5149 17.4.6. 405 Method Not Allowed 5151 The method specified in the request is not allowed for the resource 5152 identified by the Request-URI. The response MUST include an Allow 5153 header containing a list of valid methods for the requested resource. 5154 This status code is also to be used if a request attempts to use a 5155 method not indicated during SETUP. 5157 17.4.7. 406 Not Acceptable 5159 The resource identified by the request is only capable of generating 5160 response message bodies which have content characteristics not 5161 acceptable according to the Accept headers sent in the request. 5163 The response SHOULD include a message body containing a list of 5164 available message body characteristics and location(s) from which the 5165 user or user agent can choose the one most appropriate. The message 5166 body format is specified by the media type given in the Content-Type 5167 header field. Depending upon the format and the capabilities of the 5168 user agent, selection of the most appropriate choice MAY be performed 5169 automatically. However, this specification does not define any 5170 standard for such automatic selection. 5172 If the response could be unacceptable, a user agent SHOULD 5173 temporarily stop receipt of more data and query the user for a 5174 decision on further actions. 5176 17.4.8. 407 Proxy Authentication Required 5178 This code is similar to 401 (Unauthorized) (Section 17.4.2), but 5179 indicates that the client must first authenticate itself with the 5180 proxy. The proxy MUST return a Proxy-Authenticate header field 5181 (Section 18.34) containing a challenge applicable to the proxy for 5182 the requested resource. 5184 17.4.9. 408 Request Timeout 5186 The client did not produce a request within the time that the server 5187 was prepared to wait. The client MAY repeat the request without 5188 modifications at any later time. 5190 17.4.10. 410 Gone 5192 The requested resource is no longer available at the server and the 5193 forwarding address is not known. This condition is expected to be 5194 considered permanent. If the server does not know, or has no 5195 facility to determine, whether or not the condition is permanent, the 5196 status code 404 (Not Found) SHOULD be used instead. This response is 5197 cacheable unless indicated otherwise. 5199 The 410 response is primarily intended to assist the task of 5200 repository maintenance by notifying the recipient that the resource 5201 is intentionally unavailable and that the server owners desire that 5202 remote links to that resource be removed. Such an event is common 5203 for limited-time, promotional services and for resources belonging to 5204 individuals no longer working at the server's site. It is not 5205 necessary to mark all permanently unavailable resources as "gone" or 5206 to keep the mark for any length of time -- that is left to the 5207 discretion of the owner of the server. 5209 17.4.11. 412 Precondition Failed 5211 The precondition given in one or more of the 'if-' request-header 5212 fields evaluated to false when it was tested on the server. See 5213 these sections for the 'if-' headers: If-Match Section 18.24, If- 5214 Modified-Since Section 18.25, and If-None-Match Section 18.26. This 5215 response code allows the client to place preconditions on the current 5216 resource meta information (header field data) and thus prevent the 5217 requested method from being applied to a resource other than the one 5218 intended. 5220 17.4.12. 413 Request Message Body Too Large 5222 The server is refusing to process a request because the request 5223 message body is larger than the server is willing or able to process. 5224 The server MAY close the connection to prevent the client from 5225 continuing the request. 5227 If the condition is temporary, the server SHOULD include a Retry- 5228 After header field to indicate that it is temporary and after what 5229 time the client MAY try again. 5231 17.4.13. 414 Request-URI Too Long 5233 The server is refusing to service the request because the Request-URI 5234 is longer than the server is willing to interpret. This rare 5235 condition is only likely to occur when a client has used a request 5236 with long query information, when the client has descended into a URI 5237 "black hole" of redirection (e.g., a redirected URI prefix that 5238 points to a suffix of itself), or when the server is under attack by 5239 a client attempting to exploit security holes present in some servers 5240 using fixed-length buffers for reading or manipulating the Request- 5241 URI. 5243 17.4.14. 415 Unsupported Media Type 5245 The server is refusing to service the request because the message 5246 body of the request is in a format not supported by the requested 5247 resource for the requested method. 5249 17.4.15. 451 Parameter Not Understood 5251 The recipient of the request does not support one or more parameters 5252 contained in the request. When returning this error message the 5253 sender SHOULD return a message body containing the offending 5254 parameter(s). 5256 17.4.16. 452 reserved 5258 This status code MUST NOT be used in RTSP 2.0. However, it was 5259 allowed in RTSP 1.0 [RFC2326]. 5261 17.4.17. 453 Not Enough Bandwidth 5263 The request was refused because there was insufficient bandwidth. 5264 This may, for example, be the result of a resource reservation 5265 failure. 5267 17.4.18. 454 Session Not Found 5269 The RTSP session identifier in the Session header is missing, 5270 invalid, or has timed out. 5272 17.4.19. 455 Method Not Valid in This State 5274 The client or server cannot process this request in its current 5275 state. The response MUST contain an Allow header to make error 5276 recovery possible. 5278 17.4.20. 456 Header Field Not Valid for Resource 5280 The server could not act on a required request header. For example, 5281 if PLAY contains the Range header field but the stream does not allow 5282 seeking. This error message may also be used for specifying when the 5283 time format in Range is impossible for the resource. In that case 5284 the Accept-Ranges header MUST be returned to inform the client of 5285 which format(s) that are allowed. 5287 17.4.21. 457 Invalid Range 5289 The Range value given is out of bounds, e.g., beyond the end of the 5290 presentation. 5292 17.4.22. 458 Parameter Is Read-Only 5294 The parameter to be set by SET_PARAMETER can be read but not 5295 modified. When returning this error message the sender SHOULD return 5296 a message body containing the offending parameter(s). 5298 17.4.23. 459 Aggregate Operation Not Allowed 5300 The requested method may not be applied on the URI in question since 5301 it is an aggregate (presentation) URI. The method may be applied on 5302 a media URI. 5304 17.4.24. 460 Only Aggregate Operation Allowed 5306 The requested method may not be applied on the URI in question since 5307 it is not an aggregate control (presentation) URI. The method may be 5308 applied on the aggregate control URI. 5310 17.4.25. 461 Unsupported Transport 5312 The Transport field did not contain a supported transport 5313 specification. 5315 17.4.26. 462 Destination Unreachable 5317 The data transmission channel could not be established because the 5318 client address could not be reached. This error will most likely be 5319 the result of a client attempt to place an invalid dest_addr 5320 parameter in the Transport field. 5322 17.4.27. 463 Destination Prohibited 5324 The data transmission channel was not established because the server 5325 prohibited access to the client address. This error is most likely 5326 the result of a client attempt to redirect media traffic to another 5327 destination with a dest_addr parameter in the Transport header. 5329 17.4.28. 464 Data Transport Not Ready Yet 5331 The data transmission channel to the media destination is not yet 5332 ready for carrying data. However, the responding agent still expects 5333 that the data transmission channel will be established at some point 5334 in time. Note, however, that this may result in a permanent failure 5335 like 462 "Destination Unreachable". 5337 An example when this error may occur is in the case a client sends a 5338 PLAY request to a server prior to ensuring that the TCP connections 5339 negotiated for carrying media data was successfully established (In 5340 violation of this specification). The server would use this error 5341 code to indicate that the requested action could not be performed due 5342 to the failure of completing the connection establishment. 5344 17.4.29. 465 Notification Reason Unknown 5346 This indicates that the client has received a PLAY_NOTIFY 5347 (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to 5348 the client. 5350 17.4.30. 466 Key Management Error 5352 This indicates that there has been an error in a Key Management 5353 function used in conjunction with a request. For example usage of 5354 MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this 5355 error. 5357 17.4.31. 470 Connection Authorization Required 5359 The secured connection attempt needs user or client authorization 5360 before proceeding. The next hop's certificate is included in this 5361 response in the Accept-Credentials header. 5363 17.4.32. 471 Connection Credentials not accepted 5365 When performing a secure connection over multiple connections, an 5366 intermediary has refused to connect to the next hop and carry out the 5367 request due to unacceptable credentials for the used policy. 5369 17.4.33. 472 Failure to establish secure connection 5371 A proxy fails to establish a secure connection to the next hop RTSP 5372 agent. This is primarily caused by a fatal failure at the TLS 5373 handshake, for example due to server not accepting any cipher suites. 5375 17.5. Server Error 5xx 5377 Response status codes beginning with the digit "5" indicate cases in 5378 which the server is aware that it has erred or is incapable of 5379 performing the request The server SHOULD include a message body 5380 containing an explanation of the error situation, and whether it is a 5381 temporary or permanent condition. User agents SHOULD display any 5382 included message body to the user. These response codes are 5383 applicable to any request method. 5385 17.5.1. 500 Internal Server Error 5387 The server encountered an unexpected condition which prevented it 5388 from fulfilling the request. 5390 17.5.2. 501 Not Implemented 5392 The server does not support the functionality required to fulfill the 5393 request. This is the appropriate response when the server does not 5394 recognize the request method and is not capable of supporting it for 5395 any resource. 5397 17.5.3. 502 Bad Gateway 5399 The server, while acting as a gateway or proxy, received an invalid 5400 response from the upstream server it accessed in attempting to 5401 fulfill the request. 5403 17.5.4. 503 Service Unavailable 5405 The server is currently unable to handle the request due to a 5406 temporary overloading or maintenance of the server. The implication 5407 is that this is a temporary condition which will be alleviated after 5408 some delay. If known, the length of the delay MAY be indicated in a 5409 Retry-After header. If no Retry-After is given, the client SHOULD 5410 handle the response as it would for a 500 response. The client MUST 5411 honor the length, if given in the Retry-After header. 5413 Note: The existence of the 503 status code does not imply that 5414 a server must use it when becoming overloaded. Some servers 5415 may wish to simply refuse the connection. 5417 The response scope is dependent on the Request. If the request was 5418 in relation to an existing RTSP session, the scope of the overload 5419 response is to this individual RTSP session. If the request was non- 5420 session specific or intended to form a RTSP session it applies to the 5421 RTSP server identified by the host name in the request URI. 5423 17.5.5. 504 Gateway Timeout 5425 The server, while acting as a proxy, did not receive a timely 5426 response from the upstream server specified by the URI or some other 5427 auxiliary server (e.g., DNS) it needed to access in attempting to 5428 complete the request. 5430 17.5.6. 505 RTSP Version Not Supported 5432 The server does not support, or refuses to support, the RTSP protocol 5433 version that was used in the request message. The server is 5434 indicating that it is unable or unwilling to complete the request 5435 using the same major version as the client other than with this error 5436 message. The response SHOULD contain a message body describing why 5437 that version is not supported and what other protocols are supported 5438 by that server. 5440 17.5.7. 551 Option not supported 5442 A feature-tag given in the Require or the Proxy-Require fields was 5443 not supported. The Unsupported header MUST be returned stating the 5444 feature for which there is no support. 5446 17.5.8. 553 Proxy Unavailable 5448 The proxy is currently unable to handle the request due to a 5449 temporary overloading or maintenance of the proxy. The implication 5450 is that this is a temporary condition which will be alleviated after 5451 some delay. If known, the length of the delay MAY be indicated in a 5452 Retry-After header. If no Retry-After is given, the client SHOULD 5453 handle the response as it would for a 500 response. The client MUST 5454 honor the length, if given in the Retry-After header. 5456 Note: The existence of the 553 status code does not imply that 5457 a proxy must use it when becoming overloaded. Some proxies may 5458 wish to simply refuse the connection. 5460 The response scope is dependent on the Request. If the request was 5461 in relation to an existing RTSP session, the scope of the overload 5462 response is to this individual RTSP session. If the request was non- 5463 session specific or intended to form a RTSP session it applies to all 5464 such requests to this proxy. 5466 18. Header Field Definitions 5468 +---------------+----------------+--------+---------+------+ 5469 | method | direction | object | acronym | Body | 5470 +---------------+----------------+--------+---------+------+ 5471 | DESCRIBE | C -> S | P,S | DES | r | 5472 | | | | | | 5473 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 5474 | | | | | | 5475 | OPTIONS | C -> S, S -> C | P,S | OPT | | 5476 | | | | | | 5477 | PAUSE | C -> S | P,S | PSE | | 5478 | | | | | | 5479 | PLAY | C -> S | P,S | PLY | | 5480 | | | | | | 5481 | PLAY_NOTIFY | S -> C | P,S | PNY | R | 5482 | | | | | | 5483 | REDIRECT | S -> C | P,S | RDR | | 5484 | | | | | | 5485 | SETUP | C -> S | S | STP | | 5486 | | | | | | 5487 | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | 5488 | | | | | | 5489 | TEARDOWN | C -> S | P,S | TRD | | 5490 | | | | | | 5491 | | S -> C | P | TRD | | 5492 +---------------+----------------+--------+---------+------+ 5494 Table 8: Overview of RTSP methods, their direction, and what objects 5495 (P: presentation, S: stream) they operate on. Body notes if a method 5496 is allowed to carry body and in which direction, R = Request, 5497 r=response. Note: All error messages for statuses 4xx and 5xx are 5498 allowed to carry a body 5500 The general syntax for header fields is covered in Section 5.2. This 5501 section lists the full set of header fields along with notes on 5502 meaning, and usage. The syntax definition for header fields are 5503 present in Section 20.2.3. Throughout this section, we use [HX.Y] to 5504 reference Section X.Y of the current HTTP/1.1 specification RFC 2616 5505 [RFC2616]. Examples of each header field are given. 5507 Information about header fields in relation to methods and proxy 5508 processing is summarized in Table 9, Table 10, Table 11, and 5509 Table 12. 5511 The "where" column describes the request and response types in which 5512 the header field can be used. Values in this column are: 5514 R: header field may only appear in requests; 5516 r: header field may only appear in responses; 5518 2xx, 4xx, etc.: A numerical value or range indicates response codes 5519 with which the header field can be used; 5521 c: header field is copied from the request to the response. 5523 An empty entry in the "where" column indicates that the header field 5524 may be present in both requests and responses. 5526 The "proxy" column describes the operations a proxy may perform on a 5527 header field. An empty proxy column indicates that the proxy MUST 5528 NOT do any changes to that header, all allowed operations are 5529 explicitly stated: 5531 a: A proxy can add or concatenate the header field if not present. 5533 m: A proxy can modify an existing header field value. 5535 d: A proxy can delete a header field value. 5537 r: A proxy needs to be able to read the header field, and thus 5538 this header field cannot be encrypted. 5540 The rest of the columns relate to the presence of a header field in a 5541 method. The method names when abbreviated, are according to Table 8: 5543 c: Conditional; requirements on the header field depend on the 5544 context of the message. 5546 m: The header field is mandatory. 5548 m*: The header field SHOULD be sent, but clients/servers need to be 5549 prepared to receive messages without that header field. 5551 o: The header field is optional. 5553 *: The header field MUST be present if the message body is not 5554 empty. See Section 18.17, Section 18.19 and Section 5.3 for 5555 details. 5557 -: The header field is not applicable. 5559 "Optional" means that a Client/Server MAY include the header field in 5560 a request or response. The Client/Server behavior when receiving 5561 such headers varies, for some it may ignore the header field, in 5562 other cases it is a request to process the header. This is regulated 5563 by the method and header descriptions. Example of headers that 5564 require processing are the Require and Proxy-Require header fields 5565 discussed in Section 18.43 and Section 18.37. A "mandatory" header 5566 field MUST be present in a request, and MUST be understood by the 5567 Client/Server receiving the request. A mandatory response header 5568 field MUST be present in the response, and the header field MUST be 5569 understood by the Client/Server processing the response. "Not 5570 applicable" means that the header field MUST NOT be present in a 5571 request. If one is placed in a request by mistake, it MUST be 5572 ignored by the Client/Server receiving the request. Similarly, a 5573 header field labeled "not applicable" for a response means that the 5574 Client/Server MUST NOT place the header field in the response, and 5575 the Client/Server MUST ignore the header field in the response. 5577 An RTSP agent MUST ignore extension headers that are not understood. 5579 The From and Location header fields contain an URI. If the URI 5580 contains a comma, or semicolon, the URI MUST be enclosed in double 5581 quotes ("). Any URI parameters are contained within these quotes. 5582 If the URI is not enclosed in double quote, any semicolon-delimited 5583 parameters are header-parameters, not URI parameters. 5585 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5586 | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | 5587 | | | xy | S | | | | | | 5588 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5589 | Accept | R | | o | - | - | - | - | - | 5590 | | | | | | | | | | 5591 | Accept-Credentia | R | rm | o | o | o | o | o | o | 5592 | ls | | | | | | | | | 5593 | | | | | | | | | | 5594 | Accept-Encoding | R | r | o | - | - | - | - | - | 5595 | | | | | | | | | | 5596 | Accept-Language | R | r | o | - | - | - | - | - | 5597 | | | | | | | | | | 5598 | Accept-Ranges | R | r | - | - | m | - | - | - | 5599 | | | | | | | | | | 5600 | Accept-Ranges | r | r | - | - | m | - | - | - | 5601 | | | | | | | | | | 5602 | Accept-Ranges | 456 | r | - | - | - | m | - | - | 5603 | | | | | | | | | | 5604 | Allow | r | am | c | c | c | - | - | - | 5605 | | | | | | | | | | 5606 | Allow | 405 | am | m | m | m | m | m | m | 5607 | | | | | | | | | | 5608 | Authentication-I | r | | o | o | o | o | o | o/- | 5609 | nfo | | | | | | | | | 5610 | Authorization | R | | o | o | o | o | o | o | 5611 | | | | | | | | | | 5612 | Bandwidth | R | | o | o | o | o | - | - | 5613 | | | | | | | | | | 5614 | Blocksize | R | | o | - | o | o | - | - | 5615 | | | | | | | | | | 5616 | Cache-Control | | r | o | - | o | - | - | - | 5617 | | | | | | | | | | 5618 | Connection | | ad | o | o | o | o | o | o | 5619 | | | | | | | | | | 5620 | Connection-Crede | 470,4 | ar | o | o | o | o | o | o | 5621 | ntials | 07 | | | | | | | | 5622 | | | | | | | | | | 5623 | Content-Base | r | | o | - | - | - | - | - | 5624 | | | | | | | | | | 5625 | Content-Base | 4xx,5 | | o | o | o | o | o | o | 5626 | | xx | | | | | | | | 5627 | | | | | | | | | | 5628 | Content-Encoding | R | r | - | - | - | - | - | - | 5629 | | | | | | | | | | 5630 | Content-Encoding | r | r | o | - | - | - | - | - | 5631 | | | | | | | | | | 5632 | Content-Encoding | 4xx,5 | r | o | o | o | o | o | o | 5633 | | xx | | | | | | | | 5634 | | | | | | | | | | 5635 | Content-Language | R | r | - | - | - | - | - | - | 5636 | | | | | | | | | | 5637 | Content-Language | r | r | o | - | - | - | - | - | 5638 | | | | | | | | | | 5639 | Content-Language | 4xx,5 | r | o | o | o | o | o | o | 5640 | | xx | | | | | | | | 5641 | | | | | | | | | | 5642 | Content-Length | r | r | * | - | - | - | - | - | 5643 | | | | | | | | | | 5644 | Content-Length | 4xx,5 | r | * | * | * | * | * | * | 5645 | | xx | | | | | | | | 5646 | | | | | | | | | | 5647 | Content-Location | r | r | o | - | - | - | - | - | 5648 | | | | | | | | | | 5649 | Content-Location | 4xx,5 | r | o | o | o | o | o | o | 5650 | | xx | | | | | | | | 5651 | | | | | | | | | | 5652 | Content-Type | r | r | * | - | - | - | - | - | 5653 | | | | | | | | | | 5654 | Content-Type | 4xx,5 | ar | * | * | * | * | * | * | 5655 | | xx | | | | | | | | 5656 | | | | | | | | | | 5657 | CSeq | Rc | rm | m | m | m | m | m | m | 5658 | Date | | am | o/ | o/* | o/* | o/* | o/* | o/* | 5659 | | | | * | | | | | | 5660 | | | | | | | | | | 5661 | Expires | r | r | o | - | o | - | - | - | 5662 | | | | | | | | | | 5663 | From | R | r | o | o | o | o | o | o | 5664 | | | | | | | | | | 5665 | If-Match | R | r | - | - | o | - | - | - | 5666 | | | | | | | | | | 5667 | If-Modified-Sinc | R | r | o | - | o | - | - | - | 5668 | e | | | | | | | | | 5669 | | | | | | | | | | 5670 | If-None-Match | R | r | o | - | o | - | - | - | 5671 | | | | | | | | | | 5672 | Last-Modified | r | r | o | - | o | - | - | - | 5673 | | | | | | | | | | 5674 | Location | 3rr | | o | o | o | o | o | o | 5675 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5677 Table 9: Overview of RTSP header fields (A-L) related to methods 5678 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5680 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5681 | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | 5682 | | | xy | S | T | P | | | | 5683 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5684 | Media- | | | - | - | m | m | m | - | 5685 | Properties | | | | | | | | | 5686 | | | | | | | | | | 5687 | Media-Range | | | - | - | m | m | m | - | 5688 | | | | | | | | | | 5689 | MTag | r | r | o | - | o | - | - | - | 5690 | | | | | | | | | | 5691 | Pipelined-Reques | | amd | - | o | o | o | o | o | 5692 | ts | | r | | | | | | | 5693 | | | | | | | | | | 5694 | Proxy- | 407 | amr | m | m | m | m | m | m | 5695 | Authenticate | | | | | | | | | 5696 | | | | | | | | | | 5697 | Proxy-Authentica | r | amd | o | o | o | o | o | o/- | 5698 | tion-Info | | r | | | | | | | 5699 | | | | | | | | | | 5700 | Proxy- | R | rd | o | o | o | o | o | o | 5701 | Authorization | | | | | | | | | 5702 | | | | | | | | | | 5703 | Proxy- Require | R | ar | o | o | o | o | o | o | 5704 | | | | | | | | | | 5705 | Proxy- Require | r | r | c | c | c | c | c | c | 5706 | Proxy- Supported | R | amr | c | c | c | c | c | c | 5707 | | | | | | | | | | 5708 | Proxy- Supported | r | | c | c | c | c | c | c | 5709 | | | | | | | | | | 5710 | Public | r | amr | - | m | - | - | - | - | 5711 | | | | | | | | | | 5712 | Public | 501 | amr | m | m | m | m | m | m | 5713 | | | | | | | | | | 5714 | Range | R | | - | - | - | o | - | - | 5715 | | | | | | | | | | 5716 | Range | r | | - | - | c | m | m | - | 5717 | | | | | | | | | | 5718 | Referrer | R | | o | o | o | o | o | o | 5719 | | | | | | | | | | 5720 | Request- Status | R | | - | - | - | - | - | - | 5721 | | | | | | | | | | 5722 | Require | R | | o | o | o | o | o | o | 5723 | | | | | | | | | | 5724 | Retry-After | 3rr,503 | | o | o | o | o | o | - | 5725 | | ,553 | | | | | | | | 5726 | | | | | | | | | | 5727 | Retry-After | 413 | | o | - | - | - | - | - | 5728 | | | | | | | | | | 5729 | RTP-Info | r | | - | - | c | c | - | - | 5730 | | | | | | | | | | 5731 | Scale | R | r | - | - | - | o | - | - | 5732 | | | | | | | | | | 5733 | Scale | r | amr | - | - | - | c | - | - | 5734 | | | | | | | | | | 5735 | Seek-Style | R | | - | - | - | o | - | - | 5736 | | | | | | | | | | 5737 | Seek-Style | r | | - | - | - | m | - | - | 5738 | | | | | | | | | | 5739 | Server | R | r | - | o | - | - | - | o | 5740 | | | | | | | | | | 5741 | Server | r | r | o | o | o | o | o | o | 5742 | | | | | | | | | | 5743 | Session | R | r | - | o | o | m | m | m | 5744 | | | | | | | | | | 5745 | Session | r | r | - | c | m | m | m | o | 5746 | | | | | | | | | | 5747 | Speed | R | adm | - | - | - | o | - | - | 5748 | | | r | | | | | | | 5749 | | | | | | | | | | 5750 | Speed | r | adm | - | - | - | c | - | - | 5751 | | | r | | | | | | | 5752 | | | | | | | | | | 5753 | Supported | R | amr | o | o | o | o | o | o | 5754 | Supported | r | amr | c | c | c | c | c | c | 5755 | | | | | | | | | | 5756 | Terminate-Reason | R | r | - | - | - | - | - | - | 5757 | | | | | | | | | | 5758 | Timestamp | R | adm | o | o | o | o | o | o | 5759 | | | r | | | | | | | 5760 | | | | | | | | | | 5761 | Timestamp | c | adm | m | m | m | m | m | m | 5762 | | | r | | | | | | | 5763 | | | | | | | | | | 5764 | Transport | | mr | - | - | m | - | - | - | 5765 | | | | | | | | | | 5766 | Unsupported | r | | c | c | c | c | c | c | 5767 | | | | | | | | | | 5768 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 5769 | | | | | | | | | | 5770 | Via | R | amr | o | o | o | o | o | o | 5771 | | | | | | | | | | 5772 | Via | c | dr | m | m | m | m | m | m | 5773 | | | | | | | | | | 5774 | WWW- | 401 | | m | m | m | m | m | m | 5775 | Authenticate | | | | | | | | | 5776 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5778 Table 10: Overview of RTSP header fields (M-W) related to methods 5779 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5781 +-------------------------+---------+-------+-----+-----+-----+-----+ 5782 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5783 +-------------------------+---------+-------+-----+-----+-----+-----+ 5784 | Accept | R | arm | o | o | - | - | 5785 | | | | | | | | 5786 | Accept-Credentials | R | rm | o | o | o | - | 5787 | | | | | | | | 5788 | Accept-Encoding | R | r | o | o | o | - | 5789 | | | | | | | | 5790 | Accept-Language | R | r | o | o | o | - | 5791 | | | | | | | | 5792 | Accept-Ranges | | rm | o | - | - | - | 5793 | | | | | | | | 5794 | Allow | 405 | amr | m | m | m | - | 5795 | | | | | | | | 5796 | Authentication-Info | r | | o/- | o/- | - | - | 5797 | | | | | | | | 5798 | Authorization | R | | o | o | o | - | 5799 | | | | | | | | 5800 | Bandwidth | R | | - | o | - | - | 5801 | | | | | | | | 5802 | Blocksize | R | | - | o | - | - | 5803 | | | | | | | | 5804 | Cache-Control | | r | o | o | - | - | 5805 | | | | | | | | 5806 | Connection | | | o | o | o | o | 5807 | | | | | | | | 5808 | Connection-Credentials | 470,407 | ar | o | o | o | - | 5809 | | | | | | | | 5810 | Content-Base | R | | o | o | - | - | 5811 | | | | | | | | 5812 | Content-Base | r | | o | o | - | - | 5813 | | | | | | | | 5814 | Content-Base | 4xx,5xx | | o | o | o | o | 5815 | | | | | | | | 5816 | Content-Encoding | R | r | o | o | - | - | 5817 | | | | | | | | 5818 | Content-Encoding | r | r | o | o | - | - | 5819 | | | | | | | | 5820 | Content-Encoding | 4xx,5xx | r | o | o | o | o | 5821 | | | | | | | | 5822 | Content-Language | R | r | o | o | - | - | 5823 | | | | | | | | 5824 | Content-Language | r | r | o | o | - | - | 5825 | | | | | | | | 5826 | Content-Language | 4xx,5xx | r | o | o | o | o | 5827 | | | | | | | | 5828 | Content-Length | R | r | * | * | - | - | 5829 | | | | | | | | 5830 | Content-Length | r | r | * | * | - | - | 5831 | | | | | | | | 5832 | Content-Length | 4xx,5xx | r | * | * | * | * | 5833 | | | | | | | | 5834 | Content-Location | R | | o | o | - | - | 5835 | | | | | | | | 5836 | Content-Location | r | | o | o | - | - | 5837 | | | | | | | | 5838 | Content-Location | 4xx,5xx | | o | o | o | o | 5839 | | | | | | | | 5840 | Content-Type | R | | * | * | - | - | 5841 | | | | | | | | 5842 | Content-Type | r | | * | * | - | - | 5843 | | | | | | | | 5844 | Content-Type | 4xx,5xx | | * | * | * | * | 5845 | | | | | | | | 5846 | CSeq | R,c | mr | m | m | m | m | 5847 | | | | | | | | 5848 | Date | R | a | o | o | m | o | 5849 | | | | | | | | 5850 | Date | r | am | o | o | o | o | 5851 | | | | | | | | 5852 | Expires | r | r | - | - | - | - | 5853 | | | | | | | | 5854 | From | R | r | o | o | o | - | 5855 | | | | | | | | 5856 | If-Match | R | r | - | - | - | - | 5857 | | | | | | | | 5858 | If-Modified-Since | R | am | o | - | - | - | 5859 | | | | | | | | 5860 | If-None-Match | R | am | o | - | - | - | 5861 | | | | | | | | 5862 | Last-Modified | R | r | - | - | - | - | 5863 | | | | | | | | 5864 | Last-Modified | r | r | o | - | - | - | 5865 | | | | | | | | 5866 | Location | 3rr | | o | o | o | - | 5867 | | | | | | | | 5868 | Location | R | | - | - | m | - | 5869 | | | | | | | | 5870 | Media-Properties | R | amr | o | - | - | c | 5871 | | | | | | | | 5872 | Media-Properties | r | mr | c | - | - | - | 5873 | | | | | | | | 5874 | Media-Range | R | | o | - | - | c | 5875 | | | | | | | | 5876 | Media-Range | r | | c | - | - | - | 5877 | | | | | | | | 5878 | MTag | r | r | o | - | - | - | 5879 | | | | | | | | 5880 | Notify-Reason | R | | - | - | - | m | 5881 | | | | | | | | 5882 | Pipelined-Requests | R | amdr | o | o | - | - | 5883 | | | | | | | | 5884 | Proxy-Authenticate | 407 | amdr | m | m | m | - | 5885 | | | | | | | | 5886 | Proxy-Authentication-In | r | amdr | o/- | o/- | - | - | 5887 | fo | | | | | | | 5888 | | | | | | | | 5889 | Proxy-Authorization | R | amdr | o | o | o | - | 5890 | | | | | | | | 5891 | Proxy-Require | R | ar | o | o | o | - | 5892 | | | | | | | | 5893 | Proxy-Supported | R | amr | c | c | c | - | 5894 | | | | | | | | 5895 | Proxy-Supported | r | | c | c | c | - | 5896 | | | | | | | | 5897 | Public | 501 | admr | m | m | m | - | 5898 +-------------------------+---------+-------+-----+-----+-----+-----+ 5900 Table 11: Overview of RTSP header fields (A-P) related to methods 5901 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5903 +------------------+---------+-------+-----+-----+-----+-----+ 5904 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5905 +------------------+---------+-------+-----+-----+-----+-----+ 5906 | Range | R | | o | - | o | m | 5907 | | | | | | | | 5908 | Referrer | R | | o | o | o | - | 5909 | | | | | | | | 5910 | Request-Status | R | | - | - | - | c | 5911 | | | | | | | | 5912 | Require | R | r | o | o | o | - | 5913 | | | | | | | | 5914 | Retry-After | 3rr,503 | | o | o | - | - | 5915 | | | | | | | | 5916 | Retry-After | 413 | | o | o | - | - | 5917 | | | | | | | | 5918 | RTP-Info | R | r | o | - | - | C | 5919 | | | | | | | | 5920 | RTP-Info | r | r | c | - | - | - | 5921 | | | | | | | | 5922 | Scale | | | - | - | - | c | 5923 | | | | | | | | 5924 | Seek-Style | | | - | - | - | - | 5925 | | | | | | | | 5926 | Server | R | r | o | o | o | o | 5927 | | | | | | | | 5928 | Server | r | r | o | o | - | - | 5929 | | | | | | | | 5930 | Session | R | r | o | o | o | m | 5931 | | | | | | | | 5932 | Session | r | r | c | c | o | m | 5933 | | | | | | | | 5934 | Speed | | | - | - | - | - | 5935 | | | | | | | | 5936 | Supported | R | adrm | o | o | o | - | 5937 | | | | | | | | 5938 | Supported | r | adrm | c | c | c | - | 5939 | | | | | | | | 5940 | Terminate-Reason | R | r | - | - | m | - | 5941 | | | | | | | | 5942 | Timestamp | R | adrm | o | o | o | - | 5943 | | | | | | | | 5944 | Timestamp | c | adrm | m | m | m | - | 5945 | Transport | | mr | - | - | - | - | 5946 | | | | | | | | 5947 | Unsupported | r | arm | c | c | c | - | 5948 | | | | | | | | 5949 | User-Agent | R | r | m* | m* | - | - | 5950 | | | | | | | | 5951 | User-Agent | r | r | m* | m* | m* | m* | 5952 | | | | | | | | 5953 | Via | R | amr | o | o | o | - | 5954 | | | | | | | | 5955 | Via | c | dr | m | m | m | - | 5956 | | | | | | | | 5957 | WWW-Authenticate | 401 | | m | m | m | - | 5958 +------------------+---------+-------+-----+-----+-----+-----+ 5960 Table 12: Overview of RTSP header fields (R-W) related to methods 5961 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5963 18.1. Accept 5965 The Accept request-header field can be used to specify certain 5966 presentation description and parameter media types [RFC6838] which 5967 are acceptable for the response to DESCRIBE and GET_PARAMETER 5968 requests. 5970 See Section 20.2.3 for the syntax. 5972 The asterisk "*" character is used to group media types into ranges, 5973 with "*/*" indicating all media types and "type/*" indicating all 5974 subtypes of that type. The media-range MAY include media type 5975 parameters that are applicable to that range. 5977 Each media-range MAY be followed by one or more accept-params, 5978 beginning with the "q" parameter for indicating a relative quality 5979 factor. The first "q" parameter (if any) separates the media-range 5980 parameter(s) from the accept-params. Quality factors allow the user 5981 or user agent to indicate the relative degree of preference for that 5982 media-range, using the qvalue scale from 0 to 1 (section 3.9). The 5983 default value is q=1. 5985 Example of use: 5987 Accept: application/example ;q=0.7, application/sdp 5989 Indicates that the requesting agent prefers the media type 5990 application/sdp through the default 1.0 rating but also accepts the 5991 application/example media type with a 0.7 quality rating. 5993 If no Accept header field is present, then it is assumed that the 5994 client accepts all media types. If an Accept header field is 5995 present, and if the server cannot send a response which is acceptable 5996 according to the combined Accept field value, then the server SHOULD 5997 send a 406 (not acceptable) response. 5999 18.2. Accept-Credentials 6001 The Accept-Credentials header is a request header used to indicate to 6002 any trusted intermediary how to handle further secured connections to 6003 proxies or servers. See Section 19 for the usage of this header. It 6004 MUST NOT be included in server to client requests. 6006 In a request the header MUST contain the method (User, Proxy, or Any) 6007 for approving credentials selected by the requester. The method MUST 6008 NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY 6009 change it to "user" to take the role of user approving each further 6010 hop. If the method is "User" the header contains zero or more of 6011 credentials that the client accepts. The header may contain zero 6012 credentials in the first RTSP request to a RTSP server when using the 6013 "User" method. This is because the client has not yet received any 6014 credentials to accept. Each credential MUST consist of one URI 6015 identifying the proxy or server, the hash algorithm identifier, and 6016 the hash over that agent's ASN.1 distinguished encoding rules (DER) 6017 encoded certificate [RFC5280] in Base64 [RFC4648]. All RTSP clients 6018 and proxies MUST implement the SHA-256[FIPS-pub-180-2] algorithm for 6019 computation of the hash of the DER encoded certificate. The SHA-256 6020 algorithm is identified by the token "sha-256". 6022 The intention with allowing for other hash algorithms is to enable 6023 the future retirement of algorithms that are not implemented 6024 somewhere else than here. Thus the definition of future algorithms 6025 for this purpose is intended to be extremely limited. A feature tag 6026 can be used to ensure that support for the replacement algorithm 6027 exists. 6029 Example: 6031 Accept-Credentials:User 6032 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 6033 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 6035 18.3. Accept-Encoding 6037 The Accept-Encoding request-header field is similar to Accept, but 6038 restricts the content-codings (see Section 18.15),i.e., 6039 transformation codings of the message body, such as gzip compression, 6040 that are acceptable in the response. 6042 A server tests whether a content-coding is acceptable, according to 6043 an Accept-Encoding field, using these rules: 6045 1. If the content-coding is one of the content-codings listed in the 6046 Accept-Encoding field, then it is acceptable, unless it is 6047 accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of 6048 0 means "not acceptable.") 6050 2. The special "*" symbol in an Accept-Encoding field matches any 6051 available content-coding not explicitly listed in the header 6052 field. 6054 3. If multiple content-codings are acceptable, then the acceptable 6055 content-coding with the highest non-zero qvalue is preferred. 6057 4. The "identity" content-coding is always acceptable, i.e., no 6058 transformation at all, unless specifically refused because the 6059 Accept-Encoding field includes "identity;q=0", or because the 6060 field includes "*;q=0" and does not explicitly include the 6061 "identity" content-coding. If the Accept-Encoding field-value is 6062 empty, then only the "identity" encoding is acceptable. 6064 If an Accept-Encoding field is present in a request, and if the 6065 server cannot send a response which is acceptable according to the 6066 Accept-Encoding header, then the server SHOULD send an error response 6067 with the 406 (Not Acceptable) status code. 6069 If no Accept-Encoding field is present in a request, the server MAY 6070 assume that the client will accept any content coding. In this case, 6071 if "identity" is one of the available content-codings, then the 6072 server SHOULD use the "identity" content-coding, unless it has 6073 additional information that a different content-coding is meaningful 6074 to the client. 6076 18.4. Accept-Language 6078 The Accept-Language request-header field is similar to Accept, but 6079 restricts the set of natural languages that are preferred as a 6080 response to the request. Note that the language specified applies to 6081 the presentation description and any reason phrases, but not the 6082 media content. 6084 A language tag identifies a natural language spoken, written, or 6085 otherwise conveyed by human beings for communication of information 6086 to other human beings. Computer languages are explicitly excluded. 6087 The syntax and registry of RTSP 2.0 language tags is the same as that 6088 defined by [RFC5646]. 6090 Each language-range MAY be given an associated quality value which 6091 represents an estimate of the user's preference for the languages 6092 specified by that range. The quality value defaults to "q=1". For 6093 example: 6095 Accept-Language: da, en-gb;q=0.8, en;q=0.7 6097 would mean: "I prefer Danish, but will accept British English and 6098 other types of English." A language-range matches a language-tag if 6099 it exactly equals the full tag, or if it exactly equals a prefix of 6100 the tag, i.e., the primary-tag in the ABNF, such that the character 6101 following primary-tag is "-". The special range "*", if present in 6102 the Accept-Language field, matches every tag not matched by any other 6103 range present in the Accept-Language field. 6105 Note: This use of a prefix matching rule does not imply that 6106 language tags are assigned to languages in such a way that it is 6107 always true that if a user understands a language with a certain 6108 tag, then this user will also understand all languages with tags 6109 for which this tag is a prefix. The prefix rule simply allows the 6110 use of prefix tags if this is the case. 6112 In the process of selecting a language, each language-tag is assigned 6113 a qualification factor, i.e., if a language being supported by the 6114 client is actually supported by the server and what "preference" 6115 level the language achieves. The quality value (q-value) of the 6116 longest language-range in the field that matches the language-tag is 6117 assigned as the qualification factor for a particular language-tag. 6118 If no language-range in the field matches the tag, the language 6119 qualification factor assigned is 0. If no Accept-Language header is 6120 present in the request, the server SHOULD assume that all languages 6121 are equally acceptable. If an Accept-Language header is present, 6122 then all languages which are assigned a qualification factor greater 6123 than 0 are acceptable. 6125 18.5. Accept-Ranges 6127 The Accept-Ranges general-header field allows indication of the 6128 format supported in the Range header. The client MUST include the 6129 header in SETUP requests to indicate which formats are acceptable 6130 when received in PLAY and PAUSE responses, and REDIRECT requests. 6131 The server MUST include the header in SETUP and 456 error responses 6132 to indicate the formats supported for the resource indicated by the 6133 request URI. The header MAY be included in GET_PARAMETER request and 6134 response pairs. The GET_PARAMETER request MUST contain a Session 6135 header to identify the session context the request is related to. 6136 The requester and responder will indicate their capabilities 6137 regarding Range formats respectively. 6139 Accept-Ranges: npt, smpte, clock 6141 The syntax is defined in Section 20.2.3. 6143 18.6. Allow 6145 The Allow message-header field lists the methods supported by the 6146 resource identified by the Request-URI. The purpose of this field is 6147 to inform the recipient of the complete set of valid methods 6148 associated with the resource. An Allow header field MUST be present 6149 in a 405 (Method Not Allowed) response. The Allow header MUST also 6150 be present in all OPTIONS responses where the content of the header 6151 will not include exactly the same methods as listed in the Public 6152 header. 6154 The Allow message-header MUST also be included in SETUP and DESCRIBE 6155 responses, if the methods allowed for the resource is different from 6156 the complete set of methods defined in this memo. 6158 Example of use: 6160 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 6162 18.7. Authentication-Info 6164 The Authentication-Info header is used by the server to communicate 6165 some information regarding the successful authentication in the 6166 response message. This usage of this header is specified in 6167 [RFC2617] with some RTSP clarification in Section 19.1. This header 6168 MUST only be used in response messages related to client to server 6169 requests. 6171 18.8. Authorization 6173 An RTSP client that wishes to authenticate itself with a server using 6174 authentication mechanism from HTTP [RFC2617] , usually, but not 6175 necessarily, after receiving a 401 response, does so by including an 6176 Authorization request-header field with the request. The 6177 Authorization field value consists of credentials containing the 6178 authentication information of the user agent for the realm of the 6179 resource being requested. This header MUST only be used in client to 6180 server requests. 6182 If a request is authenticated and a realm specified, the same 6183 credentials SHOULD be valid for all other requests within this realm 6184 (assuming that the authentication scheme itself does not require 6185 otherwise, such as credentials that vary according to a challenge 6186 value or using synchronized clocks). 6188 When a shared cache (see Section 16) receives a request containing an 6189 Authorization field, it MUST NOT return the corresponding response as 6190 a reply to any other request, unless one of the following specific 6191 exceptions holds: 6193 1. If the response includes the "max-age" cache-control directive, 6194 the cache MAY use that response in replying to a subsequent 6195 request. But (if the specified maximum age has passed) a proxy 6196 cache MUST first revalidate it with the origin server, using the 6197 request-headers from the new request to allow the origin server 6198 to authenticate the new request. (This is the defined behavior 6199 for max-age.) If the response includes "max-age=0", the proxy 6200 MUST always revalidate it before re-using it. 6202 2. If the response includes the "must-revalidate" cache-control 6203 directive, the cache MAY use that response in replying to a 6204 subsequent request. But if the response is stale, all caches 6205 MUST first revalidate it with the origin server, using the 6206 request-headers from the new request to allow the origin server 6207 to authenticate the new request. 6209 3. If the response includes the "public" cache-control directive, it 6210 MAY be returned in reply to any subsequent request. 6212 18.9. Bandwidth 6214 The Bandwidth request-header field describes the estimated bandwidth 6215 available to the client, expressed as a positive integer and measured 6216 in kilobits per second. The bandwidth available to the client may 6217 change during an RTSP session, e.g., due to mobility, congestion, 6218 etc. 6220 Clients may not be able to accurately determine the available 6221 bandwidth, for example because first hop is not a bottleneck. For 6222 example most local area networks (LAN) will not be a bottleneck if 6223 the server is not in the same LAN. Thus link speeds of WLAN or 6224 Ethernet networks are normally not a basis for estimating the 6225 available bandwidth. Cellular devices or other devices directly 6226 connected to a modem or connection enabling device may more 6227 accurately estimate the bottleneck bandwidth and what is a reasonable 6228 share of it for RTSP controlled media. The client will also need to 6229 take into account other traffic sharing the bottleneck. For example 6230 by only assigning a certain fraction to RTSP and its media streams. 6231 It is RECOMMENDED that only clients that have accurate and explicit 6232 information about bandwidth bottlenecks uses this header. 6234 This header is not a substitute for proper congestion control. It is 6235 only a method providing an initial estimate and coarsely determines 6236 if the selected content can be delivered at all. 6238 Example: 6240 Bandwidth: 62360 6242 18.10. Blocksize 6244 The Blocksize request-header field is sent from the client to the 6245 media server asking the server for a particular media packet size. 6246 This packet size does not include lower-layer headers such as IP, 6247 UDP, or RTP. The server is free to use a blocksize which is lower 6248 than the one requested. The server MAY truncate this packet size to 6249 the closest multiple of the minimum, media-specific block size, or 6250 override it with the media-specific size if necessary. The block 6251 size MUST be a positive decimal number, measured in octets. The 6252 server only returns an error (4xx) if the value is syntactically 6253 invalid. 6255 18.11. Cache-Control 6257 The Cache-Control general-header field is used to specify directives 6258 that MUST be obeyed by all caching mechanisms along the request/ 6259 response chain. 6261 Cache directives MUST be passed through by a proxy or gateway 6262 application, regardless of their significance to that application, 6263 since the directives may be applicable to all recipients along the 6264 request/response chain. It is not possible to specify a cache- 6265 directive for a specific cache. 6267 Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, 6268 SET_PARAMETER and SETUP request and its response. Note: Cache- 6269 Control does not govern just the caching of responses as for HTTP, 6270 instead it also applies to the media stream identified by the SETUP 6271 request. The RTSP requests are generally not cacheable, for further 6272 information see Section 16. Below are the descriptions of the cache 6273 directives that can be included in the Cache-Control header. 6275 no-cache: Indicates that the media stream or RTSP response MUST NOT 6276 be cached anywhere. This allows an origin server to prevent 6277 caching even by caches that have been configured to return 6278 stale responses to client requests. Note, there is no security 6279 function preventing the caching of content. 6281 public: Indicates that the media stream or RTSP response is 6282 cacheable by any cache. 6284 private: Indicates that the media stream or RTSP response is 6285 intended for a single user and MUST NOT be cached by a shared 6286 cache. A private (non-shared) cache may cache the media 6287 streams. 6289 no-transform: An intermediate cache (proxy) may find it useful to 6290 convert the media type of a certain stream. A proxy might, for 6291 example, convert between video formats to save cache space or 6292 to reduce the amount of traffic on a slow link. Serious 6293 operational problems may occur, however, when these 6294 transformations have been applied to streams intended for 6295 certain kinds of applications. For example, applications for 6296 medical imaging, scientific data analysis and those using end- 6297 to-end authentication all depend on receiving a stream that is 6298 bit-for-bit identical to the original media stream or RTSP 6299 response. Therefore, if a response includes the no-transform 6300 directive, an intermediate cache or proxy MUST NOT change the 6301 encoding of the stream or response. Unlike HTTP, RTSP does not 6302 provide for partial transformation at this point, e.g., 6303 allowing translation into a different language. 6305 only-if-cached: In some cases, such as times of extremely poor 6306 network connectivity, a client may want a cache to return only 6307 those media streams or RTSP responses that it currently has 6308 stored, and not to receive these from the origin server. To do 6309 this, the client may include the only-if-cached directive in a 6310 request. If it receives this directive, a cache SHOULD either 6311 respond using a cached media stream or response that is 6312 consistent with the other constraints of the request, or 6313 respond with a 504 (Gateway Timeout) status. However, if a 6314 group of caches is being operated as a unified system with good 6315 internal connectivity, such a request MAY be forwarded within 6316 that group of caches. 6318 max-stale: Indicates that the client is willing to accept a media 6319 stream or RTSP response that has exceeded its expiration time. 6320 If max-stale is assigned a value, then the client is willing to 6321 accept a response that has exceeded its expiration time by no 6322 more than the specified number of seconds. If no value is 6323 assigned to max-stale, then the client is willing to accept a 6324 stale response of any age. 6326 min-fresh: Indicates that the client is willing to accept a media 6327 stream or RTSP response whose freshness lifetime is no less 6328 than its current age plus the specified time in seconds. That 6329 is, the client wants a response that will still be fresh for at 6330 least the specified number of seconds. 6332 must-revalidate: When the must-revalidate directive is present in a 6333 SETUP response received by a cache, that cache MUST NOT use the 6334 cache entry after it becomes stale to respond to a subsequent 6335 request without first revalidating it with the origin server. 6336 That is, the cache is required to do an end-to-end revalidation 6337 every time, if, based solely on the origin server's Expires, 6338 the cached response is stale. 6340 proxy-revalidate: The proxy-revalidate directive has the same 6341 meaning as the must-revalidate directive, except that it does 6342 not apply to non-shared user agent caches. It can be used on a 6343 response to an authenticated request to permit the user's cache 6344 to store and later return the response without needing to 6345 revalidate it (since it has already been authenticated once by 6346 that user), while still requiring proxies that service many 6347 users to revalidate each time (in order to make sure that each 6348 user has been authenticated). Note that such authenticated 6349 responses also need the public cache control directive in order 6350 to allow them to be cached at all. 6352 max-age: When an intermediate cache is forced, by means of a max- 6353 age=0 directive, to revalidate its own cache entry, and the 6354 client has supplied its own validator in the request, the 6355 supplied validator might differ from the validator currently 6356 stored with the cache entry. In this case, the cache MAY use 6357 either validator in making its own request without affecting 6358 semantic transparency. 6360 However, the choice of validator might affect performance. The 6361 best approach is for the intermediate cache to use its own 6362 validator when making its request. If the server replies with 6363 304 (Not Modified), then the cache can return its now validated 6364 copy to the client with a 200 (OK) response. If the server 6365 replies with a new message body and cache validator, however, 6366 the intermediate cache can compare the returned validator with 6367 the one provided in the client's request, using the strong 6368 comparison function. If the client's validator is equal to the 6369 origin server's, then the intermediate cache simply returns 304 6370 (Not Modified). Otherwise, it returns the new message body 6371 with a 200 (OK) response. 6373 18.12. Connection 6375 The Connection general-header field allows the sender to specify 6376 options that are desired for that particular connection. It MUST NOT 6377 be communicated by proxies over further connections. 6379 RTSP 2.0 proxies MUST parse the Connection header field before a 6380 message is forwarded and, for each connection-token in this field, 6381 remove any header field(s) from the message with the same name as the 6382 connection-token. Connection options are signaled by the presence of 6383 a connection-token in the Connection header field, not by any 6384 corresponding additional header field(s), since the additional header 6385 field may not be sent if there are no parameters associated with that 6386 connection option. 6388 Message headers listed in the Connection header MUST NOT include end- 6389 to-end headers, such as Cache-Control. 6391 RTSP 2.0 defines the "close" connection option for the sender to 6392 signal that the connection will be closed after completion of the 6393 response. For example, Connection: close in either the request or 6394 the response header fields indicates that the connection SHOULD NOT 6395 be considered `persistent' (Section 10.2) after the current request/ 6396 response is complete. 6398 The use of the connection option "close" in RTSP messages SHOULD be 6399 limited to error messages when the server is unable to recover and 6400 therefore sees it necessary to close the connection. The reason is 6401 that the client has the choice of continuing using a connection 6402 indefinitely, as long as it sends valid messages. 6404 18.13. Connection-Credentials 6406 The Connection-Credentials response header is used to carry the chain 6407 of credentials for any next hop that needs to be approved by the 6408 requester. It MUST only be used in server to client responses. 6410 The Connection-Credentials header in an RTSP response MUST, if 6411 included, contain the credential information (in form of a list of 6412 certificates providing the chain of certification) of the next hop 6413 that an intermediary needs to securely connect to. The header MUST 6414 include the URI of the next hop (proxy or server) and a base64 6415 [RFC4648] encoded binary structure containing a sequence of DER 6416 encoded X.509v3 certificates[RFC5280] . 6418 The binary structure starts with the number of certificates 6419 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 6420 by NR_CERTS number of 16 bit unsigned integers providing the size in 6421 octets of each DER encoded certificate. This is followed by NR_CERTS 6422 number of DER encoded X.509v3 certificates in a sequence (chain). 6423 This format is exemplified in Figure 2. The proxy or server's 6424 certificate must come first in the structure. Each following 6425 certificate must directly certify the one preceding it. Because 6426 certificate validation requires that root keys be distributed 6427 independently, the self-signed certificate which specifies the root 6428 certificate authority may optionally be omitted from the chain, under 6429 the assumption that the remote end must already possess it in order 6430 to validate it in any case. 6432 Example: 6434 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 6436 Where MIIDNTCC... is a Base64 encoding of the following structure: 6438 0 1 2 3 6439 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 6440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6441 | Number of certificates | Size of certificate #1 | 6442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6443 | Size of certificate #2 | Size of certificate #3 | 6444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6445 : DER Encoding of Certificate #1 : 6446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6447 : DER Encoding of Certificate #2 : 6448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6449 : DER Encoding of Certificate #3 : 6450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6452 Figure 2: Connection-Credentials header's Certificate Format Example 6454 18.14. Content-Base 6456 The Content-Base message-header field may be used to specify the base 6457 URI for resolving relative URIs within the message body. 6459 Content-Base: rtsp://media.example.com/movie/twister/ 6461 If no Content-Base field is present, the base URI of an message body 6462 is defined either by its Content-Location (if that Content-Location 6463 URI is an absolute URI) or the URI used to initiate the request, in 6464 that order of precedence. Note, however, that the base URI of the 6465 contents within the message-body may be redefined within that 6466 message-body. 6468 18.15. Content-Encoding 6470 The Content-Encoding message-header field is used as a modifier to 6471 the media-type. When present, its value indicates what additional 6472 content codings have been applied to the message body, and thus what 6473 decoding mechanisms must be applied in order to obtain the media-type 6474 referenced by the Content-Type header field. Content-Encoding is 6475 primarily used to allow a document to be compressed without losing 6476 the identity of its underlying media type. 6478 The content-coding is a characteristic of the message body identified 6479 by the Request-URI. Typically, the message body is stored with this 6480 encoding and is only decoded before rendering or analogous usage. 6481 However, an RTSP proxy MAY modify the content-coding if the new 6482 coding is known to be acceptable to the recipient, unless the "no- 6483 transform" cache-control directive is present in the message. 6485 If the content-coding of a message body is not "identity", then the 6486 response MUST include a Content-Encoding Message-body header that 6487 lists the non-identity content-coding(s) used. 6489 If the content-coding of a message body in a request message is not 6490 acceptable to the origin server, the server SHOULD respond with a 6491 status code of 415 (Unsupported Media Type). 6493 If multiple encodings have been applied to a message body, the 6494 content codings MUST be listed in the order in which they were 6495 applied, first to last from left to right. Additional information 6496 about the encoding parameters MAY be provided by other header fields 6497 not defined by this specification. 6499 18.16. Content-Language 6501 The Content-Language message-header field describes the natural 6502 language(s) of the intended audience for the enclosed message body. 6503 Note that this might not be equivalent to all the languages used 6504 within the message body. 6506 Language tags are mentioned in Section 18.4. The primary purpose of 6507 Content-Language is to allow a user to identify and differentiate 6508 entities according to the user's own preferred language. Thus, if 6509 the body content is intended only for a Danish-literate audience, the 6510 appropriate field is 6511 Content-Language: da 6513 If no Content-Language is specified, the default is that the content 6514 is intended for all language audiences. This might mean that the 6515 sender does not consider it to be specific to any natural language, 6516 or that the sender does not know for which language it is intended. 6518 Multiple languages MAY be listed for content that is intended for 6519 multiple audiences. For example, a rendition of the "Treaty of 6520 Waitangi," presented simultaneously in the original Maori and English 6521 versions, would call for 6523 Content-Language: mi, en 6525 However, just because multiple languages are present within a message 6526 body does not mean that it is intended for multiple linguistic 6527 audiences. An example would be a beginner's language primer, such as 6528 "A First Lesson in Latin," which is clearly intended to be used by an 6529 English-literate audience. In this case, the Content-Language would 6530 properly only include "en". 6532 Content-Language MAY be applied to any media type -- it is not 6533 limited to textual documents. 6535 18.17. Content-Length 6537 The Content-Length message-header field contains the length of the 6538 message body of the RTSP message (i.e., after the double CRLF 6539 following the last header). Unlike HTTP, it MUST be included in all 6540 messages that carry a message body beyond the header portion of the 6541 RTSP message. If it is missing, a default value of zero is assumed. 6542 Any Content-Length greater than or equal to zero is a valid value. 6544 18.18. Content-Location 6546 The Content-Location message-header field MAY be used to supply the 6547 resource location for the message body enclosed in the message when 6548 that body is accessible from a location separate from the requested 6549 resource's URI. A server SHOULD provide a Content-Location for the 6550 variant corresponding to the response message body; especially in the 6551 case where a resource has multiple variants associated with it, and 6552 those entities actually have separate locations by which they might 6553 be individually accessed, the server SHOULD provide a Content- 6554 Location for the particular variant which is returned. 6556 As example, if an RTSP client performs a DESCRIBE request on a given 6557 resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", 6558 then the server may use additional information, such as the User- 6559 Agent header, to determine the capabilities of the agent. The server 6560 will then return a media description tailored to that class of RTSP 6561 agents. To indicate which specific description the agent receives 6562 the resource identifier 6563 ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is 6564 provided in Content-Location, while the description is still a valid 6565 response for the generic resource identifier. Thus enabling both 6566 debugging and cache operation as discussed below. 6568 The Content-Location value is not a replacement for the original 6569 requested URI; it is only a statement of the location of the resource 6570 corresponding to this particular variant at the time of the request. 6571 Future requests MAY specify the Content-Location URI as the request 6572 URI if the desire is to identify the source of that particular 6573 variant. This is useful if the RTSP agent desires to verify if the 6574 resource variant is current through a conditional request. 6576 A cache cannot assume that a message body with a Content-Location 6577 different from the URI used to retrieve it can be used to respond to 6578 later requests on that Content-Location URI. However, the Content- 6579 Location can be used to differentiate between multiple variants 6580 retrieved from a single requested resource. 6582 If the Content-Location is a relative URI, the relative URI is 6583 interpreted relative to the Request-URI. 6585 Note, that Content-Location can be used in some cases to derive the 6586 base-URI for relative URI(s) present in session description formats. 6587 This needs to be taken into account when Content-Location is used. 6588 The easiest way to avoid needing to consider that issue is to include 6589 the Content-Base whenever the Content-Location is included. 6591 Note also, when using Media Tags in conjunction with Content-Location 6592 it is important that the different versions have different MTags, 6593 even if provided under different Content-Location URIs. This as they 6594 have still been provided under the same request URI. 6596 Note also, as in most cases the URI used in the DESCRIBE and the 6597 SETUP requests are different, the URI provided in a DESCRIBE Content- 6598 Location response can't directly be used in a SETUP request. Instead 6599 the extra step of resolving URIs combined with the media descriptions 6600 indication, like with SDP's a=control attribute. 6602 18.19. Content-Type 6604 The Content-Type message-header indicates the media type of the 6605 message body sent to the recipient. Note that the content types 6606 suitable for RTSP are likely to be restricted in practice to 6607 presentation descriptions and parameter-value types. 6609 18.20. CSeq 6611 The CSeq general-header field specifies the sequence number for an 6612 RTSP request-response pair. This field MUST be present in all 6613 requests and responses. For every RTSP request containing the given 6614 sequence number, the corresponding response will have the same 6615 number. For each new RTSP request an agent creates the CSeq value 6616 MUST be incremented by one. This primarily allows for associating 6617 requests with responses. It also enables detecting loss of a request 6618 and await a retransmission prior to processing a sub-sequent request 6619 when using unreliable transport. Any retransmitted request MUST 6620 contain the same sequence number as the original, i.e., the sequence 6621 number is not incremented for retransmissions of the same request. 6622 Agents receiving a request over a reliable transport with an in-order 6623 delivery MUST ignore how the sequence value increments, i.e. it can 6624 increment with other values than 1. The initial sequence number MAY 6625 be any number, however, it is RECOMMENDED to start at 0. Each 6626 sequence number series is unique between each requester and 6627 responder, i.e., the client has one series for its request to a 6628 server and the server has another when sending request to the client. 6629 Each requester and responder is identified with its socket address 6630 (IP address and port number), i.e., per direction of a TCP 6631 connection. 6633 The above rules may appear unnecessary loose. However, they are 6634 allowing for a behavior which is not uncommon. When using multiple 6635 connections in sequence it may still be easiest to use a single 6636 sequence number series for a client connecting with a particular 6637 server. Thus, the initial sequence number may be arbitrary depending 6638 on the number of previous requests. 6640 Proxies that aggregate several client sessions on the same transport 6641 will have to ensure that the requests sent towards a particular 6642 server have a joint sequence number space. A proxy having one client 6643 with concurrent sessions with two different servers using the same 6644 client proxy connection can avoid rewriting on the proxy to server 6645 connection. The latest equally applies to server to client requests, 6646 where one server may have multiple clients over the same proxy. The 6647 proxy can use only one joint sequence number space for a given 6648 transport connection to a particular server for sending request, as 6649 the identification of the RTSP agents, i.e., the proxy and the server 6650 is based on the IP address and port number. This requires that the 6651 proxy renumbers the CSeq header field in both requests and responses 6652 to fulfill the rules for the header. 6654 An RTSP proxy MUST renumber the RTSP request from RTSP agents that 6655 are sent to a particular RTSP agent in order to preserve the joint 6656 sequence number space on the connection between the proxy and the 6657 agent. The RTSP proxy MUST increase the CSeq for each request it 6658 transmits over a particular transport connection or transport flow, 6659 without regard of different sessions. 6661 An RTSP proxy MUST renumber RTSP responses back to the sequence 6662 number that the corresponding request had when originally received by 6663 the proxy before forwarding it to the RTSP agent. 6665 A proxy that forwards responses from multiple RTSP agents towards a 6666 specific agent MUST maintain the order between request/responses on a 6667 per incoming connection basis. This means that different RTSP 6668 sessions are handled over the same same transport connection between 6669 proxy and the specific agent. 6671 Given that the RTSP proxy and the agents are using reliable transport 6672 connections, the proxy MAY forward received responses without 6673 considering the response's relation to responses from other 6674 connections which will share the same outgoing transport connection 6675 from the proxy. 6677 Note: This exception is to avoid responses being blocked by 6678 other agents being slow to respond. This can result in out-of- 6679 order delivery of responses arriving at the RTSP client in 6680 relation to the transport connection, but that delivery is in- 6681 order with respect to the RTSP agent and any session. 6683 18.21. Date 6685 The Date general-header field represents the date and time at which 6686 the message was originated. The inclusion of the Date header in RTSP 6687 message follows these rules: 6689 o An RTSP message, sent either by the client or the server, 6690 containing a body MUST include a Date header, if the sending host 6691 has a clock; 6693 o Clients and servers are RECOMMENDED to include a Date header in 6694 all other RTSP messages, if the sending host has a clock; 6696 o If the server does not have a clock that can provide a reasonable 6697 approximation of the current time, its responses MUST NOT include 6698 a Date header field. In this case, this rule MUST be followed: 6699 Some origin server implementations might not have a clock 6700 available. An origin server without a clock MUST NOT assign 6701 Expires or Last-Modified values to a response, unless these values 6702 were associated with the resource by a system or user with a 6703 reliable clock. It MAY assign an Expires value that is known, at 6704 or before server configuration time, to be in the past (this 6705 allows "pre-expiration" of responses without storing separate 6706 Expires values for each resource). 6708 A received message that does not have a Date header field MUST be 6709 assigned one by the recipient if the message will be cached by that 6710 recipient. An RTSP implementation without a clock MUST NOT cache 6711 responses without revalidating them on every use. An RTSP cache, 6712 especially a shared cache, SHOULD use a mechanism, such as NTP, to 6713 synchronize its clock with a reliable external standard. 6715 The RTSP-date, a full date as specified by Section 3.3 of [RFC2822], 6716 sent in a Date header SHOULD NOT represent a date and time subsequent 6717 to the generation of the message. It SHOULD represent the best 6718 available approximation of the date and time of message generation, 6719 unless the implementation has no means of generating a reasonably 6720 accurate date and time. In theory, the date ought to represent the 6721 moment just before the message body is generated. In practice, the 6722 date can be generated at any time during the message origination 6723 without affecting its semantic value. 6725 Note: The RTSP 2.0 date is defined as RFC 2822 format date. This 6726 format is more allowing than the RTSP 1.0 and earlier draft 6727 versions using RFC 1123 date format. Thus implementations should 6728 use single spaces as recommended as separators and support 6729 receiving the obsoleted identifiers. 6731 18.22. Expires 6733 The Expires message-header field gives a date and time after which 6734 the description or media-stream should be considered stale. The 6735 interpretation depends on the method: 6737 DESCRIBE response: The Expires header indicates a date and time 6738 after which the presentation description (body) SHOULD be 6739 considered stale. 6741 SETUP response: The Expires header indicate a date and time after 6742 which the media stream SHOULD be considered stale. 6744 A stale cache entry may not normally be returned by a cache (either a 6745 proxy cache or an user agent cache) unless it is first validated with 6746 the origin server (or with an intermediate cache that has a fresh 6747 copy of the message body). See Section 16 for further discussion of 6748 the expiration model. 6750 The presence of an Expires field does not imply that the original 6751 resource will change or cease to exist at, before, or after that 6752 time. 6754 The format is an absolute date and time as defined by RTSP-date. An 6755 example of its use is 6757 Expires: Thu, 01 Dec 1994 16:00:00 GMT 6759 RTSP/2.0 clients and caches MUST treat other invalid date formats, 6760 especially including the value "0", as having occurred in the past 6761 (i.e., already expired). 6763 To mark a response as "already expired," an origin server should use 6764 an Expires date that is equal to the Date header value. To mark a 6765 response as "never expires," an origin server SHOULD use an Expires 6766 date approximately one year from the time the response is sent. 6767 RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in 6768 the future. 6770 18.23. From 6772 The From request-header field, if given, SHOULD contain an Internet 6773 e-mail address for the human user who controls the requesting user 6774 agent. The address SHOULD be machine-usable, as defined by "mailbox" 6775 in [RFC1123]. 6777 This header field MAY be used for logging purposes and as a means for 6778 identifying the source of invalid or unwanted requests. It SHOULD 6779 NOT be used as an insecure form of access protection. The 6780 interpretation of this field is that the request is being performed 6781 on behalf of the person given, who accepts responsibility for the 6782 method performed. In particular, robot agents SHOULD include this 6783 header so that the person responsible for running the robot can be 6784 contacted if problems occur on the receiving end. 6786 The Internet e-mail address in this field MAY be separate from the 6787 Internet host which issued the request. For example, when a request 6788 is passed through a proxy the original issuer's address SHOULD be 6789 used. 6791 The client SHOULD NOT send the From header field without the user's 6792 approval, as it might conflict with the user's privacy interests or 6793 their site's security policy. It is strongly recommended that the 6794 user be able to disable, enable, and modify the value of this field 6795 at any time prior to a request. 6797 18.24. If-Match 6799 The If-Match request-header field is especially useful for ensuring 6800 the integrity of the presentation description, independent of how the 6801 presentation description was received. The presentation description 6802 can be fetched via means external to RTSP (such as HTTP) or via the 6803 DESCRIBE message. In the case of retrieving the presentation 6804 description via RTSP, the server implementation is guaranteeing the 6805 integrity of the description between the time of the DESCRIBE message 6806 and the SETUP message. By including the MTag given in or with the 6807 session description in an If-Match header part of the SETUP request, 6808 the client ensures that resources set up are matching the 6809 description. A SETUP request with the If-Match header for which the 6810 MTag validation check fails, MUST generate a response using 412 6811 (Precondition Failed). 6813 This validation check is also very useful if a session has been 6814 redirected from one server to another. 6816 18.25. If-Modified-Since 6818 The If-Modified-Since request-header field is used with the DESCRIBE 6819 and SETUP methods to make them conditional. If the requested variant 6820 has not been modified since the time specified in this field, a 6821 description will not be returned from the server (DESCRIBE) or a 6822 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 6823 response MUST be returned without any message-body. 6825 An example of the field is: 6827 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 6829 18.26. If-None-Match 6831 This request header can be used with one or several message body tags 6832 to make DESCRIBE requests conditional. A client that has one or more 6833 message bodies previously obtained from the resource, can verify that 6834 none of those entities is current by including a list of their 6835 associated message body tags in the If-None-Match header field. The 6836 purpose of this feature is to allow efficient updates of cached 6837 information with a minimum amount of transaction overhead. As a 6838 special case, the value "*" matches any current entity of the 6839 resource. 6841 If any of the message body tags match the message body tag of the 6842 message body that would have been returned in the response to a 6843 similar DESCRIBE request (without the If-None-Match header) on that 6844 resource, or if "*" is given and any current entity exists for that 6845 resource, then the server MUST NOT perform the requested method, 6846 unless required to do so because the resource's modification date 6847 fails to match that supplied in an If-Modified-Since header field in 6848 the request. Instead, if the request method was DESCRIBE, the server 6849 SHOULD respond with a 304 (Not Modified) response, including the 6850 cache-related header fields (particularly MTag) of one of the message 6851 bodies that matched. For all other request methods, the server MUST 6852 respond with a status of 412 (Precondition Failed). 6854 See Section 16.1.3 for rules on how to determine if two message body 6855 tags match. 6857 If none of the message body tags match, then the server MAY perform 6858 the requested method as if the If-None-Match header field did not 6859 exist, but MUST also ignore any If-Modified-Since header field(s) in 6860 the request. That is, if no message body tags match, then the server 6861 MUST NOT return a 304 (Not Modified) response. 6863 If the request would, without the If-None-Match header field, result 6864 in anything other than a 2xx or 304 status, then the If-None-Match 6865 header MUST be ignored. (See Section 16.1.4 for a discussion of 6866 server behavior when both If-Modified-Since and If-None-Match appear 6867 in the same request.) 6869 The result of a request having both an If-None-Match header field and 6870 an If-Match header field is unspecified and MUST be considered an 6871 illegal request. 6873 18.27. Last-Modified 6875 The Last-Modified message-header field indicates the date and time at 6876 which the origin server believes the presentation description or 6877 media stream was last modified. For the method DESCRIBE, the header 6878 field indicates the last modification date and time of the 6879 description, for SETUP that of the media stream. 6881 An origin server MUST NOT send a Last-Modified date which is later 6882 than the server's time of message origination. In such cases, where 6883 the resource's last modification would indicate some time in the 6884 future, the server MUST replace that date with the message 6885 origination date. 6887 An origin server SHOULD obtain the Last-Modified value of the message 6888 body as close as possible to the time that it generates the Date 6889 value of its response. This allows a recipient to make an accurate 6890 assessment of the message body's modification time, especially if the 6891 message body changes near the time that the response is generated. 6893 RTSP servers SHOULD send Last-Modified whenever feasible. 6895 18.28. Location 6897 The Location response-header field is used to redirect the recipient 6898 to a location other than the Request-URI for completion of the 6899 request or identification of a new resource. For 3rr responses, the 6900 location SHOULD indicate the server's preferred URI for automatic 6901 redirection to the resource. The field value consists of a single 6902 absolute URI. 6904 Note: The Content-Location header field (Section 18.18) differs from 6905 Location in that the Content-Location identifies the original 6906 location of the message body enclosed in the request. It is 6907 therefore possible for a response to contain header fields for both 6908 Location and Content-Location. Also, see Section 16.2 for cache 6909 requirements of some methods. 6911 18.29. Media-Properties 6913 This general header is used in SETUP response or PLAY_NOTIFY requests 6914 to indicate the media's properties that currently are applicable to 6915 the RTSP session. PLAY_NOTIFY MAY be used to modify these properties 6916 at any point. However, the client SHOULD have received the update 6917 prior to any action related to the new media properties taking 6918 effect. For aggregated sessions, the Media-Properties header will be 6919 returned in each SETUP response. The header received in the latest 6920 response is the one that applies on the whole session from this point 6921 until any future update. The header MAY be included without value in 6922 GET_PARAMETER requests to the server with a Session header included 6923 to query the current Media-Properties for the session. The responder 6924 MUST include the current session's media properties. 6926 The media properties expressed by this header is the one applicable 6927 to all media in the RTSP session. For aggregated sessions, the 6928 header expressed the combined media-properties. As a result, 6929 aggregation of media MAY result in a change of the media properties, 6930 and thus the content of the Media-Properties header contained in 6931 subsequent SETUP responses. 6933 The header contains a list of property values that are applicable to 6934 the currently setup media or aggregate of media as indicated by the 6935 RTSP URI in the request. No ordering is enforced within the header. 6936 Property values should be grouped into a single group that handles a 6937 particular orthogonal property. Values or groups that express 6938 multiple properties SHOULD NOT be used. The list of properties that 6939 can be expressed MAY be extended at any time. Unknown property 6940 values MUST be ignored. 6942 This specification defines the following 4 groups and their property 6943 values: 6945 Random Access: 6947 Random-Access: Indicates that random access is possible. May 6948 optionally include a floating point value in seconds indicating 6949 the longest duration between any two random access points in 6950 the media. 6952 Beginning-Only: Seeking is limited to the beginning only. 6954 No-Seeking: No seeking is possible. 6956 Content Modifications: 6958 Immutable: The content will not be changed during the life-time 6959 of the RTSP session. 6961 Dynamic: The content may be changed based on external methods or 6962 triggers 6964 Time-Progressing: The media accessible progresses as wallclock 6965 time progresses. 6967 Retention: 6969 Unlimited: Content will be retained for the duration of the life- 6970 time of the RTSP session. 6972 Time-Limited: Content will be retained at least until the 6973 specified wallclock time. The time must be provided in the 6974 absolute time format specified in Section 4.4.3. 6976 Time-Duration: Each individual media unit is retained for at 6977 least the specified time duration. This definition allows for 6978 retaining data with a time based sliding window. The time 6979 duration is expressed as floating point number in seconds. 0.0 6980 is a valid value as this indicates that no data is retained in 6981 a time-progressing session. 6983 Supported Scale: 6985 Scales: A quoted comma separated list of one or more decimal 6986 values or ranges of scale values supported by the content in 6987 arbitrary order. A range has a start and stop value separated 6988 by a colon. A range indicates that the content supports fine 6989 grained selection of scale values. Fine grained allows for 6990 steps at least as small as one tenth of a scale value. A 6991 content is considered to support fine grained selection when 6992 the server in response to a given scale value can produce 6993 content with an actual scale that is less than 1 tenth of scale 6994 unit, i.e., 0.1, from the requested value. Negative values are 6995 supported. The value 0 has no meaning and MUST NOT be used. 6997 Examples of this header for on-demand content and a live stream 6998 without recording are: 7000 On-demand: 7001 Media-Properties: Random-Access=2.5, Unlimited, Immutable, 7002 Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" 7004 Live stream without recording/timeshifting: 7005 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 7007 18.30. Media-Range 7009 The Media-Range general header is used to give the range of the media 7010 at the time of sending the RTSP message. This header MUST be 7011 included in SETUP response, and PLAY and PAUSE response for media 7012 that are Time-Progressing, and PLAY and PAUSE response after any 7013 change for media that are Dynamic, and in PLAY_NOTIFY request that 7014 are sent due to Media-Property-Update. Media-Range header without 7015 any range specifications MAY be included in GET_PARAMETER requests to 7016 the server to request the current range. The server MUST in this 7017 case include the current range at the time of sending the response. 7019 The header MUST include range specifications for all time formats 7020 supported for the media, as indicated in Accept-Ranges header 7021 (Section 18.5) when setting up the media. The server MAY include 7022 more than one range specification of any given time format to 7023 indicate media that has non-continuous range. The range 7024 specifications shall be ordered with the range with the lowest value 7025 or earliest start time first, followed by ranges with increasingly 7026 higher values or later start time. 7028 For media that has the Time-Progressing property, the Media-Range 7029 values will only be valid for the particular point in time when it 7030 was issued. As wallclock progresses so will also the media range. 7031 However, it shall be assumed that media time progresses in direct 7032 relationship to wallclock time (with the exception of clock skew) so 7033 that a reasonably accurate estimation of the media range can be 7034 calculated. 7036 18.31. MTag 7038 The MTag response header MAY be included in DESCRIBE, GET_PARAMETER 7039 or SETUP responses. The message body tags (Section 4.6) returned in 7040 a DESCRIBE response, and the one in SETUP refers to the presentation, 7041 i.e., both the returned session description and the media stream. 7042 This allows for verification that one has the right session 7043 description to a media resource at the time of the SETUP request. 7044 However, it has the disadvantage that a change in any of the parts 7045 results in invalidation of all the parts. 7047 If the MTag is provided both inside the message body, e.g., within 7048 the "a=mtag" attribute in SDP, and in the response message, then both 7049 tags MUST be identical. It is RECOMMENDED that the MTag is primarily 7050 given in the RTSP response message, to ensure that caches can use the 7051 MTag without requiring content inspection. However, for session 7052 descriptions that are distributed outside of RTSP, for example using 7053 HTTP, etc. it will be necessary to include the message body tag in 7054 the session description as specified in Appendix D.1.9. 7056 SETUP and DESCRIBE requests can be made conditional upon the MTag 7057 using the headers If-Match (Section 18.24) and If-None-Match ( 7058 Section 18.26). 7060 18.32. Notify-Reason 7062 The Notify Reason header is solely used in the PLAY_NOTIFY method. 7063 It indicates the reason why the server has sent the asynchronous 7064 PLAY_NOTIFY request (see Section 13.5). 7066 18.33. Pipelined-Requests 7068 The Pipelined-Requests general header is used to indicate that a 7069 request is to be executed in the context created by a previous 7070 request(s). The primary usage of this header is to allow pipelining 7071 of SETUP requests so that any additional SETUP request after the 7072 first one does not need to wait for the session ID to be sent back to 7073 the requesting agent. The header contains a unique identifier that 7074 is scoped by the persistent connection used to send the requests. 7076 Upon receiving a request with the Pipelined-Requests the responding 7077 agent MUST look up if there exists a binding between this Pipelined- 7078 Requests identifier for the current persistent connection and an RTSP 7079 session ID. If that exists then the received request is processed 7080 the same way as if it contained the Session header with the found 7081 session ID. If there does not exist a mapping and no Session header 7082 is included in the request, the responding agent MUST create a 7083 binding upon the successful completion of a session creating request, 7084 i.e., SETUP. A binding MUST NOT be created, if the request failed to 7085 create an RTSP session. In case the request contains both a Session 7086 header and the Pipelined-Requests header the Pipelined-Requests MUST 7087 be ignored. 7089 Note: Based on the above definition at least the first request 7090 containing a new unique Pipelined-Requests will be required to be a 7091 SETUP request (unless the protocol is extended with new methods of 7092 creating a session). After that first one, additional SETUP requests 7093 or requests of any type using the RTSP session context may include 7094 the Pipelined-Requests header. 7096 When responding to any request that contained the Pipelined-Requests 7097 header the server MUST also include the Session header when a binding 7098 to a session context exists. An RTSP agent that knows the session 7099 identifier SHOULD NOT use the Pipelined-Requests header in any 7100 request and only use the Session header. This as the Session 7101 identifier is persistent across transport contexts, like TCP 7102 connections, which the Pipelined-Requests identifier is not. 7104 The RTSP agent sending the request with a Pipelined-Requests header 7105 has the responsibility for using a unique and previously unused 7106 identifier within the transport context. Currently only a TCP 7107 connection is defined as such transport context. A server MUST 7108 delete the Pipelined-Requests identifier and its binding to a session 7109 upon the termination of that session. Despite the previous mandate, 7110 RTSP agents are RECOMMENDED to not reuse identifiers to allow for 7111 better error handling and logging. 7113 RTSP Proxies may need to translate Pipelined-Requests identifier 7114 values from incoming requests to outgoing to allow for aggregation of 7115 requests onto a persistent connection. 7117 18.34. Proxy-Authenticate 7119 The Proxy-Authenticate response-header field MUST be included as part 7120 of a 407 (Proxy Authentication Required) response. The field value 7121 consists of a challenge that indicates the authentication scheme and 7122 parameters applicable to the proxy for this Request-URI. 7124 The HTTP access authentication process is described in [RFC2617]. 7125 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 7126 only to the current connection and SHOULD NOT be passed on to 7127 downstream agents. This header MUST only be used in response 7128 messages related to client to server requests. 7130 18.35. Proxy-Authentication-Info 7132 The Proxy-Authentication-Info header is used by the proxy to 7133 communicate some information regarding the successful authentication 7134 to the proxy in the message response. The content and usage of this 7135 header is described in the HTTP access authentication [RFC2617] that 7136 is also used by RTSP and clarified in Section 19.1. This header MUST 7137 only be used in response messages related to client to server 7138 requests. This header has hop by hop scope. 7140 18.36. Proxy-Authorization 7142 The Proxy-Authorization request-header field allows the client to 7143 identify itself (or its user) to a proxy which requires 7144 authentication. The Proxy-Authorization field value consists of 7145 credentials containing the authentication information of the user 7146 agent for the proxy and/or realm of the resource being requested. 7148 The HTTP access authentication process is described in [RFC2617]. 7149 Unlike Authorization, the Proxy-Authorization header field applies 7150 only to the next hop proxy. This header MUST only be used in client 7151 to server requests. 7153 18.37. Proxy-Require 7155 The Proxy-Require request-header field is used to indicate proxy- 7156 sensitive features that MUST be supported by the proxy. Any Proxy- 7157 Require header features that are not supported by the proxy MUST be 7158 negatively acknowledged by the proxy to the client using the 7159 Unsupported header. The proxy MUST use the 551 (Option Not 7160 Supported) status code in the response. Any feature-tag included in 7161 the Proxy-Require does not apply to the end-point (server or client). 7162 To ensure that a feature is supported by both proxies and servers the 7163 tag needs to be included in also a Require header. 7165 See Section 18.43 for more details on the mechanics of this message 7166 and a usage example. See discussion in the proxies section 7167 (Section 15.1) about when to consider that a feature requires proxy 7168 support. 7170 Example of use: 7172 Proxy-Require: play.basic 7174 18.38. Proxy-Supported 7176 The Proxy-Supported general-header field enumerates all the 7177 extensions supported by the proxy using feature-tags. The header 7178 carries the intersection of extensions supported by the forwarding 7179 proxies. The Proxy-Supported header MAY be included in any request 7180 by a proxy. It MUST be added by any proxy if the Supported header is 7181 present in a request. When present in a request, the receiver MUST 7182 in the response copy the received Proxy-Supported header. 7184 The Proxy-Supported header field contains a list of feature-tags 7185 applicable to proxies, as described in Section 4.5. The list is the 7186 intersection of all feature-tags understood by the proxies. To 7187 achieve an intersection, the proxy adding the Proxy-Supported header 7188 includes all proxy feature-tags it understands. Any proxy receiving 7189 a request with the header, MUST check the list and removes any 7190 feature-tag(s) it does not support. A Proxy-Supported header present 7191 in the response MUST NOT be modified by the proxies. These feature 7192 tags are the ones the proxy chain support in general, and is not 7193 specific to the request resource. 7195 Example: 7197 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 7198 Supported: foo, bar, blech 7199 User-Agent: PhonyClient/1.2 7201 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 7202 Supported: foo, bar, blech 7203 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 7204 Via: 2.0 pro.example.com 7206 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 7207 Supported: foo, bar, blech 7208 Proxy-Supported: proxy-foo, proxy-blech 7209 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7211 S->C: RTSP/2.0 200 OK 7212 Supported: foo, bar, baz 7213 Proxy-Supported: proxy-foo, proxy-blech 7214 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7215 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7217 18.39. Public 7219 The Public response header field lists the set of methods supported 7220 by the response sender. This header applies to the general 7221 capabilities of the sender and its only purpose is to indicate the 7222 sender's capabilities to the recipient. The methods listed may or 7223 may not be applicable to the Request-URI; the Allow header field 7224 (Section 18.6) MAY be used to indicate methods allowed for a 7225 particular URI. 7227 Example of use: 7229 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7231 In the event that there are proxies between the sender and the 7232 recipient of a response, each intervening proxy MUST modify the 7233 Public header field to remove any methods that are not supported via 7234 that proxy. The resulting Public header field will contain an 7235 intersection of the sender's methods and the methods allowed through 7236 by the intervening proxies. 7238 In general, proxies should allow all methods to transparently pass 7239 through from the sending RTSP agent to the receiving RTSP agent, 7240 but there may be cases where this is not desirable for a given 7241 proxy. Modification of the Public response header field by the 7242 intervening proxies ensures that the request sender gets an 7243 accurate response indicating the methods that can be used on the 7244 target agent via the proxy chain. 7246 18.40. Range 7248 The Range general-header specifies a time range in PLAY 7249 (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT 7250 (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and 7251 responses. It MAY be included in GET_PARAMETER requests from the 7252 client to the server with only a Range format and no value to request 7253 the current media position, whether the session is in Play or Ready 7254 state in the included format. The server SHALL, if supporting the 7255 range format, respond with the current playing point or pause point 7256 as the start of the range. If an explicit stop point was used in the 7257 previous PLAY request, then that value shall be included as stop 7258 point. Note that if the server is currently under any type of media 7259 playback manipulation affecting the interpretation of Range, like 7260 Scale, that is also required to be included in any GET_PARAMETER 7261 response to provide complete information. 7263 The range can be specified in a number of units. This specification 7264 defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock 7265 (Section 4.4.3) range units. While byte ranges [H14.35.1] and other 7266 extended units MAY be used, their behavior is unspecified since they 7267 are not normally meaningful in RTSP. Servers supporting the Range 7268 header MUST understand the NPT range format and SHOULD understand the 7269 SMPTE range format. If the Range header is sent in a time format 7270 that is not understood, the recipient SHOULD return 456 (Header Field 7271 Not Valid for Resource) and include an Accept-Ranges header 7272 indicating the supported time formats for the given resource. 7274 Example: 7276 Range: clock=19960213T143205Z- 7278 The Range header contains a range of one single range format. A 7279 range is a half-open interval with a start and an end point, 7280 including the start point, but excluding the end point. A range may 7281 either be fully specified with explicit values for start point and 7282 end point, or have either start or end point be implicit. An 7283 implicit start point indicates the session's pause point, and if no 7284 pause point is set the start of the content. An implicit end point 7285 indicates the end of the content. The usage of both implicit start 7286 and end point is not allowed in the same range header, however, the 7287 exclusion of the range header has that meaning, i.e., from pause 7288 point (or start) until end of content. 7290 Regarding the half-open intervals; a range of A-B starts exactly 7291 at time A, but ends just before B. Only the start time of a media 7292 unit such as a video or audio frame is relevant. For example, 7293 assume that video frames are generated every 40 ms. A range of 7294 10.0-10.1 would include a video frame starting at 10.0 or later 7295 time and would include a video frame starting at 10.08, even 7296 though it lasted beyond the interval. A range of 10.0-10.08, on 7297 the other hand, would exclude the frame at 10.08. 7299 Please note the difference between NPT time scales' "now" and an 7300 implicit start value. Implicit value reference the current pause- 7301 point. While "now" is the currently ongoing time. In a time- 7302 progressing session with recording (retention for some or full 7303 time) the pause point may be 2 min into the session while now 7304 could be 1 hour into the session. 7306 By default, range intervals increase, where the second point is 7307 larger than the first point. 7309 Example: 7311 Range: npt=10-15 7313 However, range intervals can also decrease if the Scale header (see 7314 Section 18.46) indicates a negative scale value. For example, this 7315 would be the case when a playback in reverse is desired. 7317 Example: 7319 Scale: -1 7320 Range: npt=15-10 7322 Decreasing ranges are still half open intervals as described above. 7323 Thus, for range A-B, A is closed and B is open. In the above 7324 example, 15 is closed and 10 is open. An exception to this rule is 7325 the case when B=0 in a decreasing range. In this case, the range is 7326 closed on both ends, as otherwise there would be no way to reach 0 on 7327 a reverse playback for formats that have such a notion, like NPT and 7328 SMPTE. 7330 Example: 7332 Scale: -1 7333 Range: npt=15-0 7335 In this range both 15 and 0 are closed. 7337 A decreasing range interval without a corresponding negative Scale 7338 header is not valid. 7340 18.41. Referrer 7342 The Referrer request-header field allows the client to specify, for 7343 the server's benefit, the address (URI) of the resource from which 7344 the Request-URI was obtained. The URI refers to that of the 7345 presentation description, typically retrieved via HTTP. The Referrer 7346 request-header allows a server to generate lists of back-links to 7347 resources for interest, logging, optimized caching, etc. It also 7348 allows obsolete or mistyped links to be traced for maintenance. The 7349 Referrer field MUST NOT be sent if the Request-URI was obtained from 7350 a source that does not have its own URI, such as input from the user 7351 keyboard. 7353 If the field value is a relative URI, it SHOULD be interpreted 7354 relative to the Request-URI. The URI MUST NOT include a fragment 7355 identifier. 7357 Because the source of a link might be private information or might 7358 reveal an otherwise private information source, it is strongly 7359 recommended that the user be able to select whether or not the 7360 Referrer field is sent. For example, a streaming client could have a 7361 toggle switch for openly/anonymously, which would respectively 7362 enable/disable the sending of Referrer and From information. 7364 Clients SHOULD NOT include a Referrer header field in a (non-secure) 7365 RTSP request if the referring page was transferred with a secure 7366 protocol. 7368 18.42. Request-Status 7370 This request header is used to indicate the end result for requests 7371 that take time to complete, such as PLAY (Section 13.4). It is sent 7372 in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report 7373 how the PLAY request concluded, either in success or in failure. The 7374 header carries a reference to the request it reports on using the 7375 CSeq number for the session indicated by the Session header in the 7376 request. It provides both a numerical status code (according to 7377 Section 8.1.1) and a human readable reason phrase. 7379 Example: 7380 Request-Status: cseq=63 status=500 reason="Media data unavailable" 7382 18.43. Require 7384 The Require request-header field is used by agents to ensure that the 7385 other end-point supports features that are required in respect to 7386 this request. It can also be used to query if the other end-point 7387 supports certain features, however, the use of the Supported message- 7388 header (Section 18.51) is much more effective in this purpose. In 7389 case any of the feature-tags listed by the Require header are not 7390 supported by the server or client receiving the request, it MUST 7391 respond to the request using the error code 551 (Option Not 7392 Supported) and include the Unsupported header listing those feature- 7393 tags which are NOT supported. This header does not apply to proxies, 7394 for the same functionality in respect to proxies see Proxy-Require 7395 header (Section 18.37) with the exception of media modifying proxies. 7396 Media modifying proxies, due to their nature of handling media in a 7397 way that is very similar to a server, do need to understand also the 7398 server's features to correctly serve the client. 7400 This is to make sure that the client-server interaction will 7401 proceed without delay when all features are understood by both 7402 sides, and only slow down if features are not understood (as in 7403 the example below). For a well-matched client-server pair, the 7404 interaction proceeds quickly, saving a round-trip often required 7405 by negotiation mechanisms. In addition, it also removes state 7406 ambiguity when the client requires features that the server does 7407 not understand. 7409 Example (Not complete): 7411 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 7412 CSeq: 302 7413 Require: funky-feature 7414 Funky-Parameter: funkystuff 7416 S->C: RTSP/2.0 551 Option not supported 7417 CSeq: 302 7418 Unsupported: funky-feature 7420 In this example, "funky-feature" is the feature-tag which indicates 7421 to the client that the fictional Funky-Parameter field is required. 7422 The relationship between "funky-feature" and Funky-Parameter is not 7423 communicated via the RTSP exchange, since that relationship is an 7424 immutable property of "funky-feature" and thus should not be 7425 transmitted with every exchange. 7427 Proxies and other intermediary devices MUST ignore this header. If a 7428 particular extension requires that intermediate devices support it, 7429 the extension should be tagged in the Proxy-Require field instead 7430 (see Section 18.37). See discussion in the proxies section 7431 (Section 15.1) about when to consider that a feature requires proxy 7432 support. 7434 18.44. Retry-After 7436 The Retry-After response-header field can be used with a 503 (Service 7437 Unavailable) or 553 (Proxy Unavailable) response to indicate how long 7438 the service is expected to be unavailable to the requesting client. 7439 This field MAY also be used with any 3rr (Redirection) response to 7440 indicate the minimum time the user-agent is asked to wait before 7441 issuing the redirected request. The value of this field can be 7442 either an RTSP-date or an integer number of seconds (in decimal) 7443 after the time of the response. 7445 Example: 7447 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 7448 Retry-After: 120 7450 In the latter example, the delay is 2 minutes. 7452 18.45. RTP-Info 7454 The RTP-Info general header field is used to set RTP-specific 7455 parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY 7456 and GET_PARAMETER requests. For streams using RTP as transport 7457 protocol the RTP-Info header SHOULD be part of a 200 response to 7458 PLAY. 7460 The exclusion of the RTP-Info in a PLAY response for RTP 7461 transported media will result in a client needing to synchronize 7462 the media streams using RTCP. This may have negative impact as 7463 the RTCP can be lost, and does not need to be particularly timely 7464 in its arrival. Also functionality that informs the client from 7465 which packet a seek has occurred is affected. 7467 The RTP-Info MAY be included in SETUP responses to provide 7468 synchronization information when changing transport parameters, see 7469 Section 13.3. The RTP-Info header and the Range header MAY be 7470 included in a GET_PARAMETER request from client to server without any 7471 values to request the current playback point and corresponding RTP 7472 synchronization information. When the RTP-Info header is included in 7473 a Request the Range header MUST also be included (Note, Range header 7474 only MAY be used). The server response SHALL include both the Range 7475 header and the RTP-Info header. If the session is in Play state, 7476 then the value of the Range header SHALL be filled in with the 7477 current playback point and with the corresponding RTP-Info values. 7478 If the server is another state, no values are included in the RTP- 7479 Info header. The header is included in PLAY_NOTIFY requests with the 7480 Notify-Reason of end-of-stream to provide RTP information about the 7481 end of the stream. 7483 The header can carry the following parameters: 7485 url: Indicates the stream URI for which the following RTP parameters 7486 correspond, this URI MUST be the same as used in the SETUP 7487 request for this media stream. Any relative URI MUST use the 7488 Request-URI as base URI. This parameter MUST be present. 7490 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 7491 sequence number provided applies to. This parameter MUST be 7492 present. 7494 seq: Indicates the sequence number of the first packet of the stream 7495 that is direct result of the request. This allows clients to 7496 gracefully deal with packets when seeking. The client uses 7497 this value to differentiate packets that originated before the 7498 seek from packets that originated after the seek. Note that a 7499 client may not receive the packet with the expressed sequence 7500 number, and instead packets with a higher sequence number, due 7501 to packet loss or reordering. This parameter is RECOMMENDED to 7502 be present. 7504 rtptime: MUST indicate the RTP timestamp value corresponding to the 7505 start time value in the Range response header, or if not 7506 explicitly given the implied start point. The client uses this 7507 value to calculate the mapping of RTP time to NPT or other 7508 media timescale. This parameter SHOULD be present to ensure 7509 inter-media synchronization is achieved. There exists no 7510 requirement that any received RTP packet will have the same RTP 7511 timestamp value as the one in the parameter used to establish 7512 synchronization. 7514 A mapping from RTP timestamps to Network Time Protocol (NTP) 7515 format timestamps (wallclock) is available via RTCP. However, 7516 this information is not sufficient to generate a mapping from RTP 7517 timestamps to media clock time (NPT, etc.). Furthermore, in order 7518 to ensure that this information is available at the necessary time 7519 (immediately at startup or after a seek), and that it is delivered 7520 reliably, this mapping is placed in the RTSP control channel. 7522 In order to compensate for drift for long, uninterrupted 7523 presentations, RTSP clients should additionally map NPT to NTP, 7524 using initial RTCP sender reports to do the mapping, and later 7525 reports to check drift against the mapping. 7527 Example: 7529 Range:npt=3.25-15 7530 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 7531 rtptime=12345678,url="rtsp://example.com/foo/video" 7532 ssrc=9A9DE123:seq=30211;rtptime=29567112 7534 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video 7535 a 90kHz RTP timestamp clock. Then the media synchronization is 7536 depicted in the following way. 7538 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 7539 Audio PA A 7540 Video V PV 7542 X: NPT time value = 3.25, from Range header. 7543 A: RTP timestamp value for Audio from RTP-Info header (12345678). 7544 V: RTP timestamp value for Video from RTP-Info header (29567112). 7545 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 7546 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 7547 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 7548 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 7550 18.46. Scale 7552 The Scale general-header indicates the requested or used view rate 7553 for the media resource being played back. A scale value of 1 7554 indicates normal play at the normal forward viewing rate. If not 1, 7555 the value corresponds to the rate with respect to normal viewing 7556 rate. For example, a ratio of 2 indicates twice the normal viewing 7557 rate ("fast forward") and a ratio of 0.5 indicates half the normal 7558 viewing rate. In other words, a ratio of 2 has content time increase 7559 at twice the playback time. For every second of elapsed (wallclock) 7560 time, 2 seconds of content time will be delivered. A negative value 7561 indicates reverse direction. For certain media transports this may 7562 require certain considerations to work consistent, see Appendix C.1 7563 for description on how RTP handles this. 7565 The transmitted data rate SHOULD NOT be changed by selection of a 7566 different scale value. The resulting bit-rate should be reasonably 7567 close to the nominal bit-rate of the content for Scale = 1. The 7568 server has to actively manipulate the data when needed to meet the 7569 bitrate constraints. Implementation of scale changes depends on the 7570 server and media type. For video, a server may, for example, deliver 7571 only key frames or selected frames. For audio, it may time-scale the 7572 audio while preserving pitch or, less desirably, deliver fragments of 7573 audio, or completely mute the audio. 7575 The server and content may restrict the range of scale values that it 7576 supports. The supported values are indicated by the Media-Properties 7577 header (Section 18.29). The client SHOULD only indicate request 7578 values to be supported. However, as the values may change as the 7579 content progresses a requested value may no longer be valid when the 7580 request arrives. Thus, a non-supported value in a request does not 7581 generate an error, only forces the server to choose the closest 7582 value. The response MUST always contain the actual scale value 7583 chosen by the server. 7585 If the server does not implement the possibility to scale, it will 7586 not return a Scale header. A server supporting Scale operations for 7587 PLAY MUST indicate this with the use of the "play.scale" feature-tag. 7589 When indicating a negative scale for a reverse playback, the Range 7590 header MUST indicate a decreasing range as described in 7591 Section 18.40. 7593 Example of playing in reverse at 3.5 times normal rate: 7595 Scale: -3.5 7596 Range: npt=15-10 7598 18.47. Seek-Style 7600 When a client sends a PLAY request with a Range header to perform a 7601 random access to the media, the client does not know if the server 7602 will pick the first media samples or the first random access point 7603 prior to the request range. Depending on use case, the client may 7604 have a strong preference. To express this preference and provide the 7605 client with information on how the server actually acted on that 7606 preference the Seek-Style header is defined. 7608 Seek-Style is a general header that MAY be included in any PLAY 7609 request to indicate the client's preference for any media stream that 7610 has random access properties. The server MUST always include the 7611 header in any PLAY response for media with random access properties 7612 to indicate what policy was applied. A server that receives an 7613 unknown Seek-Style policy MUST ignore it and select the server 7614 default policy. A client receiving an unknown policy MUST ignore it 7615 and use the Range header and any media synchronization information as 7616 basis to determine what the server did. 7618 This specification defines the following seek policies that may be 7619 requested (see also Section 4.7.1): 7621 RAP: Random Access Point (RAP) is the behavior of requesting the 7622 server to locate the closest previous random access point that 7623 exists in the media aggregate and deliver from that. By 7624 requesting a RAP, media quality will be the best possible as all 7625 media will be delivered from a point where full media state can be 7626 established in the media decoder. 7628 CoRAP: Conditional Random Access Point (CoRAP) is a variant of the 7629 above RAP behavior. This policy is primarily intended for cases 7630 where there is larger distance between the random access points in 7631 the media. CoRAP is conditioned on that there is a Random Access 7632 Point closer to the requested start point than to the current 7633 pause point. This policy assumes that the media state existing 7634 prior to the pause is usable if delivery is continued. If the 7635 client or server knows that this is not the fact the RAP policy 7636 should be used. In other words: in most cases when the client 7637 requests a start point prior to the current pause point, a valid 7638 decoding dependency chain from the media delivered prior to the 7639 pause and to the requested media unit will not exist. If the 7640 server searched to a random access point the server MUST return 7641 the CoRAP policy in the Seek-Style header and adjust the Range 7642 header to reflect the position of the picked RAP. In case the 7643 random access point is further away and the server selects to 7644 continue from the current pause point it MUST include the "Next" 7645 policy in the Seek-Style header and adjust the Range header start 7646 point to the current pause point. 7648 First-Prior: The first-prior policy will start delivery with the 7649 media unit that has a playout time first prior to the requested 7650 time. For discrete media that would only include media units that 7651 would still be rendered at the request time. For continuous media 7652 that is media that will be rendered during the requested start 7653 time of the range. 7655 Next: The next media units after the provided start time of the 7656 range. For continuous framed media that would mean the first next 7657 frame after the provided time. For discrete media the first unit 7658 that is to be rendered after the provided time. The main usage 7659 for this case is when the client knows it has all media up to a 7660 certain point and would like to continue delivery so that a 7661 complete non-interrupted media playback can be achieved. Example 7662 of such scenarios include switching from a broadcast/multicast 7663 delivery to a unicast based delivery. This policy MUST only be 7664 used on the client's explicit request. 7666 Please note that these expressed preferences exist for optimizing the 7667 startup time or the media quality. The "Next" policy breaks the 7668 normal definition of the Range header to enable a client to request 7669 media with minimal overlap, although some may still occur for 7670 aggregated sessions. RAP and First-Prior both fulfill the 7671 requirement of providing media from the requested range and forward. 7672 However, unless RAP is used, the media quality for many media codecs 7673 using predictive methods can be severely degraded unless additional 7674 data is available as, for example, already buffered, or through other 7675 side channels. 7677 18.48. Server 7679 The Server general-header field contains information about the 7680 software used by the origin server to create or handle the request. 7681 The field can contain multiple product tokens and comments 7682 identifying the server and any significant subproducts. The product 7683 tokens are listed in order of their significance for identifying the 7684 application. 7686 Example: 7688 Server: PhonyServer/1.0 7690 If the response is being forwarded through a proxy, the proxy 7691 application MUST NOT modify the Server response-header. Instead, it 7692 SHOULD include a Via field (Section 18.57). If the response is 7693 generated by the proxy, the proxy application MUST return the Server 7694 response-header as previously returned by the server. 7696 18.49. Session 7698 The Session general-header field identifies an RTSP session. An RTSP 7699 session is created by the server as a result of a successful SETUP 7700 request and in the response the session identifier is given to the 7701 client. The RTSP session exists until destroyed by a TEARDOWN, 7702 REDIRECT or timed out by the server. 7704 The session identifier is chosen by the server (see Section 4.3) and 7705 MUST be returned in the SETUP response. Once a client receives a 7706 session identifier, it MUST be included in any request related to 7707 that session. This means that the Session header MUST be included in 7708 a request, using the following methods: PLAY, PAUSE, and TEARDOWN, 7709 and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, 7710 and REDIRECT, and MUST NOT be included in DESCRIBE. The Session 7711 header MUST NOT be included in the following methods, if these 7712 requests are pipelined and if the session identifier is not yet 7713 known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and 7714 GET_PARAMETER. 7716 In an RTSP response the session header MUST be included in methods, 7717 SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and 7718 REDIRECT, and if included in the request of the following methods it 7719 MUST also be included in the response, OPTIONS, GET_PARAMETER, and 7720 SET_PARAMETER, and MUST NOT be included in DESCRIBE responses. 7722 Note that a session identifier identifies an RTSP session across 7723 transport sessions or connections. RTSP requests for a given session 7724 can use different URIs (Presentation and media URIs). Note, that 7725 there are restrictions depending on the session which URIs that are 7726 acceptable for a given method. However, multiple "user" sessions for 7727 the same URI from the same client will require use of different 7728 session identifiers. 7730 The session identifier is needed to distinguish several delivery 7731 requests for the same URI coming from the same client. 7733 The response 454 (Session Not Found) MUST be returned if the session 7734 identifier is invalid. 7736 The header MAY include a parameter for session timeout period. If 7737 not explicitly provided this value is set to 60 seconds. As this 7738 affects how often session keep-alives are needed values smaller than 7739 30 seconds are not recommended. However, larger than default values 7740 can be useful in applications of RTSP that have inactive but 7741 established sessions for longer time periods. 7743 60 seconds was chosen as session timeout value due to: Resulting 7744 in not too frequent keep-alive messages and having low sensitivity 7745 to variations in request response timing. If one reduces the 7746 timeout value to below 30 seconds the corresponding request 7747 response timeout becomes a significant part of the session 7748 timeout. 60 seconds also allows for reasonably rapid recovery of 7749 committed server resources in case of client failure. 7751 18.50. Speed 7753 The Speed general-header field requests the server to deliver 7754 specific amounts of nominal media time per unit of delivery time, 7755 contingent on the server's ability and desire to serve the media 7756 stream at the given speed. The client requests the delivery speed to 7757 be within a given range with a lower and upper bound. The server 7758 SHALL deliver at the highest possible speed within the range, but not 7759 faster than the upper-bound, for which the underlying network path 7760 can support the resulting transport data rates. As long as any speed 7761 value within the given range can be provided the server SHALL NOT 7762 modify the media quality. Only if the server is unable to deliver 7763 media at the speed value provided by the lower bound shall it reduce 7764 the media quality. 7766 Implementation of the Speed functionality by the server is OPTIONAL. 7767 The server can indicate its support through a feature-tag, 7768 play.speed. The lack of a Speed header in the response is an 7769 indication of lack of support of this functionality. 7771 The speed parameter values are expressed as a positive decimal value, 7772 e.g., a value of 2.0 indicates that data is to be delivered twice as 7773 fast as normal. A speed value of zero is invalid. The range is 7774 specified in the form "lower bound - upper bound". The lower bound 7775 value may be smaller or equal to the upper bound. All speeds may not 7776 be possible to support. Therefore the server MAY modify the 7777 requested values to the closest supported. The actual supported 7778 speed MUST be included in the response. Note, however, that the use 7779 cases may vary and that Speed value ranges such as 0.7 - 0.8, 7780 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 7782 Example: 7784 Speed: 1.0-2.5 7786 Use of this header changes the bandwidth used for data delivery. It 7787 is meant for use in specific circumstances where delivery of the 7788 presentation at a higher or lower rate is desired. The main use 7789 cases are buffer operations or local scale operations. Implementors 7790 should keep in mind that bandwidth for the session may be negotiated 7791 beforehand (by means other than RTSP), and therefore re-negotiation 7792 may be necessary. To perform Speed operations the server needs to 7793 ensure that the network path can support the resulting bit-rate. 7794 Thus the media transport needs to support feedback so that the server 7795 can react and adapt to the available bitrate. 7797 18.51. Supported 7799 The Supported general header enumerates all the extensions supported 7800 by the client or server using feature tags. The header carries the 7801 extensions supported by the message sending client or server. The 7802 Supported header MAY be included in any request. When present in a 7803 request, the receiver MUST respond with its corresponding Supported 7804 header. Note that the Supported header is also included in 4xx and 7805 5xx responses. 7807 The Supported header contains a list of feature-tags, described in 7808 Section 4.5, that are understood by the client or server. These 7809 feature tags are the ones the server or client support in general, 7810 and is not specific to the request resource. 7812 Example: 7814 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 7815 Supported: foo, bar, blech 7816 User-Agent: PhonyClient/1.2 7818 S->C: RTSP/2.0 200 OK 7819 Supported: bar, blech, baz 7821 18.52. Terminate-Reason 7823 The Terminate-Reason request header allows the server when sending a 7824 REDIRECT or TEARDOWN request to provide a reason for the session 7825 termination and any additional information. This specification 7826 identifies three reasons for Redirections and may be extended in the 7827 future: 7829 Server-Admin: The server needs to be shutdown for some 7830 administrative reason. 7832 Session-Timeout: A client's session has been kept alive for extended 7833 periods of time and the server has determined that it needs to 7834 reclaim the resources associated with this session. 7836 Internal-Error An internal error that is impossible to recover from 7837 has occurred forcing the server to terminate the session. 7839 The Server may provide additional parameters containing information 7840 around the redirect. This specification defines the following ones. 7842 time: Provides a wallclock time when the server will stop providing 7843 any service. 7845 user-msg: An UTF-8 text string with a message from the server to the 7846 user. This message SHOULD be displayed to the user. 7848 18.53. Timestamp 7850 The Timestamp general-header describes when the agent sent the 7851 request. The value of the timestamp is of significance only to the 7852 agent and may use any timescale. The responding agent MUST echo the 7853 exact same value and MAY, if it has accurate information about this, 7854 add a floating point number indicating the number of seconds that has 7855 elapsed since it has received the request. The timestamp can be used 7856 by the agent to compute the round-trip time to the responding agent 7857 so that it can adjust the timeout value for retransmissions when 7858 running over an unreliable protocol. It also resolves retransmission 7859 ambiguities for unreliable transport of RTSP. 7861 Note that the present specification provides only for reliable 7862 transport of RTSP messages. The Timestamp general-header is 7863 specified in case the protocol is extended in the future to use 7864 unreliable transport. 7866 18.54. Transport 7868 The Transport general-header indicates which transport protocol is to 7869 be used and configures its parameters such as destination address, 7870 compression, multicast time-to-live and destination port for a single 7871 stream. It sets those values not already determined by a 7872 presentation description. 7874 A Transport request header MAY contain a list of transport options 7875 acceptable to the client, in the form of multiple transport 7876 specification entries. Transport specifications are comma separated, 7877 listed in decreasing order of preference. Each transport 7878 specification consist of a transport protocol identifier, followed by 7879 any number of parameters, each parameter separated by a semicolon. A 7880 Transport request header MAY contain multiple transport 7881 specifications using the same transport protocol Identifier. The 7882 server MUST return a Transport response-header in the response to 7883 indicate the values actually chosen if any. If no transport 7884 specification is supported, no transport header is returned and the 7885 request MUST be responded using the status code 461 (Unsupported 7886 Transport) (Section 17.4.25). In case more than one transport 7887 specification was present in the request, the server MUST return the 7888 single transport specification (transport-spec) which was actually 7889 chosen, if any. The number of transport-spec entries is expected to 7890 be limited as the client will get guidance on what configurations 7891 that are possible from the presentation description. 7893 The Transport header MAY also be used in subsequent SETUP requests to 7894 change transport parameters. A server MAY refuse to change 7895 parameters of an existing stream. 7897 The transport protocol identifier defines for each transport 7898 specification which transport protocol to use and any related rules. 7899 Each transport protocol identifier defines the parameters that are 7900 required to occur, additional optional parameters MAY occur. This as 7901 parameters may be different and provide different options to the RTSP 7902 Agent. A transport specification may only contain one of any given 7903 parameter within it. A parameter consists of a name and optionally a 7904 value string. Parameters MAY be given in any order. Additionally, 7905 transport specification may only contain either of the unicast or the 7906 multicast transport type parameter. The transport protocol 7907 identifier and all parameters need to be understood in a transport 7908 specification, if not, the transport specification MUST be ignored. 7909 An RTSP proxy of any type that uses or modifies the transport 7910 specification, e.g., access proxy or security proxy, MUST remove 7911 specifications with unknown parameters before forwarding the RTSP 7912 message. If that results in no remaining transport specification the 7913 proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.25) 7914 response without any Transport header. 7916 The Transport header is restricted to describing a single media 7917 stream. (RTSP can also control multiple streams as a single 7918 entity.) Making it part of RTSP rather than relying on a 7919 multitude of session description formats greatly simplifies 7920 designs of firewalls. 7922 The general syntax for the transport protocol identifier is a list of 7923 slash separated tokens: 7925 Value1/Value2/Value3... 7927 Which for RTP transports take the form: 7929 RTP/profile/lower-transport. 7931 The default value for the "lower-transport" parameters is specific to 7932 the profile. For RTP/AVP, the default is UDP. 7934 There are two different methods for how to specify where the media 7935 should be delivered for unicast transport: 7937 dest_addr: The presence of this parameter and its values indicates 7938 the destination address or addresses (host address and port 7939 pairs for IP flows) necessary for the media transport. 7941 No dest_addr: The lack of the dest_addr parameter indicates that the 7942 server MUST send media to the same address from which the RTSP 7943 messages originates. 7945 The choice of method for indicating where the media is to be 7946 delivered depends on the use case. In some cases the only allowed 7947 method will be to use no explicit address indication and have the 7948 server deliver media to the source of the RTSP messages. 7950 For Multicast there is several methods for specifying addresses but 7951 they are different in how they work compared with unicast: 7953 dest_addr with client picked address: The address and relevant 7954 parameters, like TTL (scope), for the actual multicast group to 7955 deliver the media to. There are security implications 7956 (Section 21) with this method that need to be addressed if 7957 using this method because a RTSP server can be used as a Denial 7958 of Service (DoS) attacker on an existing multicast group. 7960 dest_addr using Session Description Information: The information 7961 included in the transport header can all be coming from the 7962 session description, e.g., the SDP c= and m= line. This 7963 mitigates some of the security issues of the previous methods 7964 as it is the session provider that picks the multicast group 7965 and scope. The client MUST include the information if it is 7966 available in the session description. 7968 No dest_addr: The behavior when no explicit multicast group is 7969 present in a request is not defined. 7971 An RTSP proxy will need to take care. If the media is not desired to 7972 be routed through the proxy, the proxy will need to introduce the 7973 destination indication. 7975 Below are the configuration parameters associated with transport: 7977 General parameters: 7979 unicast / multicast: This parameter is a mutually exclusive 7980 indication of whether unicast or multicast delivery will be 7981 attempted. One of the two values MUST be specified. Clients 7982 that are capable of handling both unicast and multicast 7983 transmission need to indicate such capability by including two 7984 full transport-specs with separate parameters for each. 7986 layers: The number of multicast layers to be used for this media 7987 stream. The layers are sent to consecutive addresses starting 7988 at the dest_addr address. If the parameter is not included, it 7989 defaults to a single layer. 7991 dest_addr: A general destination address parameter that can contain 7992 one or more address specifications. Each combination of 7993 protocol/profile/lower transport needs to have the format and 7994 interpretation of its address specification defined. For RTP/ 7995 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 7996 containing a host address and port. Note, only a single 7997 destination parameter per transport spec is intended. The 7998 usage of multiple destinations to distribute a single media to 7999 multiple entities is unspecified. 8001 The client originating the RTSP request MAY specify the 8002 destination address of the stream recipient with the host 8003 address part of the tuple. When the destination address is 8004 specified, the recipient may be a different party than the 8005 originator of the request. To avoid becoming the unwitting 8006 perpetrator of a remote-controlled denial-of-service attack, a 8007 server MUST perform security checks (see Section 21.2.1) and 8008 SHOULD log such attempts before allowing the client to direct a 8009 media stream to a recipient address not chosen by the server. 8010 Implementations cannot rely on TCP as reliable means of client 8011 identification. If the server does not allow the host address 8012 part of the tuple to be set, it MUST return 463 (Destination 8013 Prohibited). 8015 The host address part of the tuple MAY be empty, for example 8016 ":58044", in cases when it is desired to specify only the 8017 destination port. Responses to requests including the 8018 Transport header with a dest_addr parameter SHOULD include the 8019 full destination address that is actually used by the server. 8020 The server MUST NOT remove address information present already 8021 in the request when responding unless the protocol requires it. 8023 src_addr: A general source address parameter that can contain one or 8024 more address specifications. Each combination of protocol/ 8025 profile/lower transport needs to have the format and 8026 interpretation of its address specification defined. For RTP/ 8027 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8028 containing a host address and port. 8030 This parameter MUST be specified by the server if it transmits 8031 media packets from another address than the one RTSP messages 8032 are sent to. This will allow the client to verify source 8033 address and give it a destination address for its RTCP feedback 8034 packets, if RTP is used. The address or addresses indicated in 8035 the src_addr parameter SHOULD be used both for sending and 8036 receiving of the media stream's data packets. The main reasons 8037 are threefold: First, indicating the port and source address(s) 8038 lets the receiver know where from the packets is expected to 8039 originate. Secondly, traversal of NATs is greatly simplified 8040 when traffic is flowing symmetrically over a NAT binding. 8041 Thirdly, certain NAT traversal mechanisms, needs to know to 8042 which address and port to send so called "binding packets" from 8043 the receiver to the sender, thus creating an address binding in 8044 the NAT that the sender to receiver packet flow can use. 8046 This information may also be available through SDP. 8047 However, since this is more a feature of transport than 8048 media initialization, the authoritative source for this 8049 information should be in the SETUP response. 8051 mode: The mode parameter indicates the methods to be supported for 8052 this session. Currently defined valid values are "PLAY". If 8053 not provided, the default is "PLAY". The "RECORD" value was 8054 defined in RFC 2326 and is in this specification unspecified 8055 but reserved. RECORD and other values may be specified in the 8056 future. 8058 interleaved: The interleaved parameter implies mixing the media 8059 stream with the control stream in whatever protocol is being 8060 used by the control stream, using the mechanism defined in 8061 Section 14. The argument provides the channel number to be 8062 used in the $ block (see Section 14) and MUST be present. This 8063 parameter MAY be specified as an interval, e.g., 8064 interleaved=4-5 in cases where the transport choice for the 8065 media stream requires it, e.g., for RTP with RTCP. The channel 8066 number given in the request is only a guidance from the client 8067 to the server on what channel number(s) to use. The server MAY 8068 set any valid channel number in the response. The declared 8069 channel(s) are bi-directional, so both end-parties MAY send 8070 data on the given channel. One example of such usage is the 8071 second channel used for RTCP, where both server and client send 8072 RTCP packets on the same channel. 8074 This allows RTP/RTCP to be handled similarly to the way 8075 that it is done with UDP, i.e., one channel for RTP and 8076 the other for RTCP. 8078 MIKEY: This parameter is used in conjunction with transport 8079 specifications that can utilize MIKEY [RFC3830] for security 8080 context establishment. So far only the SRTP based RTP profiles 8081 SAVP and SAVPF can utilize MIKEY and this is defined in 8082 Appendix C.1.4.1. This parameter can be included both in 8083 request and response messages. The binary MIKEY message SHALL 8084 be Base64 [RFC4648] encoded before being included in the value 8085 part of the parameter. 8087 Multicast-specific: 8089 ttl: multicast time-to-live for IPv4. When included in requests the 8090 value indicate the TTL value that the client requests the 8091 server to use. In a response, the value actually being used by 8092 the server is returned. A server will need to consider what 8093 values that are reasonable and also the authority of the user 8094 to set this value. Corresponding functions are not needed for 8095 IPv6 as the scoping is part of the IPv6 multicast address 8096 [RFC4291]. 8098 RTP-specific: 8100 These parameters MAY only be used if the media transport protocol is 8101 RTP. 8103 ssrc: The ssrc parameter, if included in a SETUP response, indicates 8104 the RTP SSRC [RFC3550] value(s) that will be used by the media 8105 server for RTP packets within the stream. It is expressed as 8106 an eight digit hexadecimal value. 8108 The ssrc parameter MUST NOT be specified in requests. The 8109 functionality of specifying the ssrc parameter in a SETUP 8110 request is deprecated as it is incompatible with the 8111 specification of RTP in RFC 3550[RFC3550]. If the parameter is 8112 included in the Transport header of a SETUP request, the server 8113 SHOULD ignore it, and choose appropriate SSRCs for the stream. 8114 The server SHOULD set the ssrc parameter in the Transport 8115 header of the response. 8117 RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing 8118 [RFC5761] on a single underlying transport stream / flow. The 8119 presence of this parameter in a SETUP request indicates the 8120 client's support and requires the server to use RTP and RTCP 8121 multiplexing. The client SHALL only include one transport 8122 stream in the Transport header specification. To provide the 8123 server with a choice between using RTP/RTCP multiplexing or 8124 not, two different transport header specifications must be 8125 included. 8127 The parameters setup and connection defined below MAY only be used if 8128 the media transport protocol of the lower-level transport is 8129 connection-oriented (such as TCP). However, these parameters MUST 8130 NOT be used when interleaving data over the RTSP connection. 8132 setup: Clients use the setup parameter on the Transport line in a 8133 SETUP request, to indicate the roles it wishes to play in a TCP 8134 connection. This parameter is adapted from [RFC4145]. We 8135 discuss the use of this parameter in RTP/AVP/TCP non- 8136 interleaved transport in Appendix C.2.2; the discussion below 8137 is limited to syntactic issues. Clients may specify the 8138 following values for the setup parameter: 8140 active: The client will initiate an outgoing connection. 8142 passive: The client will accept an incoming connection. 8144 actpass: The client is willing to accept an incoming 8145 connection or to initiate an outgoing connection. 8147 If a client does not specify a setup value, the "active" value 8148 is assumed. 8150 In response to a client SETUP request where the setup parameter 8151 is set to "active", a server's 2xx reply MUST assign the setup 8152 parameter to "passive" on the Transport header line. 8154 In response to a client SETUP request where the setup parameter 8155 is set to "passive", a server's 2xx reply MUST assign the setup 8156 parameter to "active" on the Transport header line. 8158 In response to a client SETUP request where the setup parameter 8159 is set to "actpass", a server's 2xx reply MUST assign the setup 8160 parameter to "active" or "passive" on the Transport header 8161 line. 8163 Note that the "holdconn" value for setup is not defined for 8164 RTSP use, and MUST NOT appear on a Transport line. 8166 connection: Clients use the connection parameter in a transport 8167 specification part of the Transport header in a SETUP request, 8168 to indicate the client's preference for either reusing an 8169 existing connection between client and server (in which case 8170 the client sets the "connection" parameter to "existing"), or 8171 requesting the creation of a new connection between client and 8172 server (in which cast the client sets the "connection" 8173 parameter to "new"). Typically, clients use the "new" value 8174 for the first SETUP request for a URL, and "existing" for 8175 subsequent SETUP requests for a URL. 8177 If a client SETUP request assigns the "new" value to 8178 "connection", the server response MUST also assign the "new" 8179 value to "connection" on the Transport line. 8181 If a client SETUP request assigns the "existing" value to 8182 "connection", the server response MUST assign a value of 8183 "existing" or "new" to "connection" on the Transport line, at 8184 its discretion. 8186 The default value of "connection" is "existing", for all SETUP 8187 requests (initial and subsequent). 8189 The combination of transport protocol, profile and lower transport 8190 needs to be defined. A number of combinations are defined in the 8191 Appendix C. 8193 Below is a usage example, showing a client advertising the capability 8194 to handle multicast or unicast, preferring multicast. Since this is 8195 a unicast-only stream, the server responds with the proper transport 8196 parameters for unicast. 8198 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 8199 CSeq: 302 8200 Transport: RTP/AVP;multicast;mode="PLAY", 8201 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8202 "192.0.2.5:3457";mode="PLAY" 8203 Accept-Ranges: npt, smpte, clock 8204 User-Agent: PhonyClient/1.2 8206 S->C: RTSP/2.0 200 OK 8207 CSeq: 302 8208 Date: Thu, 23 Jan 1997 15:35:06 GMT 8209 Session: 47112344 8210 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8211 "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ 8212 "192.0.2.224:6257";mode="PLAY" 8213 Accept-Ranges: npt 8214 Media-Properties: Random-Access=0.6, Dynamic, 8215 Time-Limited=20081128T165900 8217 18.55. Unsupported 8219 The Unsupported response-header lists the features not supported by 8220 the responding RTSP agent. In the case where the feature was 8221 specified via the Proxy-Require field (Section 18.37), if there is a 8222 proxy on the path between the client and the server, the proxy MUST 8223 send a response message with a status code of 551 (Option Not 8224 Supported). The request MUST NOT be forwarded. 8226 See Section 18.43 for a usage example. 8228 18.56. User-Agent 8230 The User-Agent general-header field contains information about the 8231 user agent originating the request or producing a response. This is 8232 for statistical purposes, the tracing of protocol violations, and 8233 automated recognition of user agents for the sake of tailoring 8234 responses to avoid particular user agent limitations. User agents 8235 SHOULD include this field with requests. The field can contain 8236 multiple product tokens and comments identifying the agent and any 8237 subproducts which form a significant part of the user agent. By 8238 convention, the product tokens are listed in order of their 8239 significance for identifying the application. 8241 Example: 8243 User-Agent: PhonyClient/1.2 8245 18.57. Via 8247 The Via general-header field MUST be used by proxies to indicate the 8248 intermediate protocols and recipients between the user agent and the 8249 server on requests, and between the origin server and the client on 8250 responses. The field is intended to be used for tracking message 8251 forwards, avoiding request loops, and identifying the protocol 8252 capabilities of all senders along the request/response chain. 8254 Multiple Via field values represents each proxy that has forwarded 8255 the message. Each recipient MUST append its information such that 8256 the end result is ordered according to the sequence of forwarding 8257 applications. 8259 Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by 8260 default, forward the names and ports of hosts within the private/ 8261 protected region. This information SHOULD only be propagated if 8262 explicitly enabled. If not enabled, the via-received of any host 8263 behind the firewall/NAT SHOULD be replaced by an appropriate 8264 pseudonym for that host. 8266 For organizations that have strong privacy requirements for hiding 8267 internal structures, a proxy MAY combine an ordered subsequence of 8268 Via header field entries with identical sent-protocol values into a 8269 single such entry. Applications MUST NOT combine entries which have 8270 different received-protocol values. 8272 18.58. WWW-Authenticate 8274 The WWW-Authenticate response-header field MUST be included in 401 8275 (Unauthorized) response messages. The field value consists of at 8276 least one challenge that indicates the authentication scheme(s) and 8277 parameters applicable to the Request-URI. This header MUST only be 8278 used in response messages related to client to server requests. 8280 The HTTP access authentication process is described in [RFC2617] with 8281 some clarification in Section 19.1. User agents are advised to take 8282 special care in parsing the WWW- Authenticate field value as it might 8283 contain more than one challenge, or if more than one WWW-Authenticate 8284 header field is provided, the contents of a challenge itself can 8285 contain a comma-separated list of authentication parameters. 8287 19. Security Framework 8289 The RTSP security framework consists of two high level components: 8290 the pure authentication mechanisms based on HTTP authentication, and 8291 the message transport protection based on TLS, which is independent 8292 of RTSP. Because of the similarity in syntax and usage between RTSP 8293 servers and HTTP servers, the security for HTTP is re-used to a large 8294 extent. 8296 19.1. RTSP and HTTP Authentication 8298 RTSP and HTTP share common authentication schemes, and thus follow 8299 the same usage guidelines as specified in [RFC2617] with the 8300 additions for digest specified below in Section 19.1.1. Servers 8301 SHOULD implement both basic and digest [RFC2617] authentication. 8302 Clients MUST implement both basic and digest authentication [RFC2617] 8303 so that a server that requires the client to authenticate can trust 8304 that the capability is present. 8306 It should be stressed that using the HTTP authentication alone does 8307 not provide full control message security. Therefore, in 8308 environments requiring tighter security for the control messages, TLS 8309 SHOULD be used, see Section 19.2. Any RTSP message containing an 8310 Authorization header using basic authorization MUST be using a TLS 8311 connection with confidentiality protection enabled, i.e. no NULL 8312 encryption. 8314 In cases where there is a chain of proxies between the client and the 8315 server, each proxy may individually request the client or previous 8316 proxy to authenticate itself. This is done using the Proxy- 8317 Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36) 8318 and the Proxy-Authentication-Info (Section 18.35) headers. These 8319 headers are hop-by-hop headers and have only scope for the current 8320 connection. Thus if a chain exist, the proxy connecting to another 8321 proxy will have to act as a client to authorize itself towards the 8322 next proxy. The WWW-Authenticate (Section 18.58), Authorization 8323 (Section 18.8) and Authentication-Info (Section 18.7) headers are 8324 end-to-end and must not be modified by proxies. 8326 This authentication mechanism works only for client to server 8327 requests as currently defined. This leaves server to client request 8328 outside of the context of TLS based communication more vulnerable to 8329 message injection attacks on the client. Based on the server to 8330 client methods that exist, the potential risks are various; hijacking 8331 (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks 8332 with uncertain results (SET_PARAMETER). 8334 19.1.1. Digest Authentication 8336 This section describes the modifications and clarifications required 8337 to apply the HTTP Digest authentication scheme to RTSP. The RTSP 8338 scheme usage is almost completely identical to that for HTTP 8339 [RFC2617]. These are based on the procedures defined for SIP 2.0 8340 [RFC3261]. 8342 The rules for Digest authentication follow those defined in 8343 [RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the 8344 following differences: 8346 1. Use the ABNF specified in this document, rather than the one in 8347 [RFC2617]. That way the following is assured: 8349 * Using the right RTSP URIs allowed in the challenge as well as 8350 in the digest. 8352 * Resolved the error in the "uri" parameter of the Authorization 8353 header in [RFC2617]. 8355 2. If MTags are used then the example procedure for choosing a nonce 8356 based on Etag can work based on replacing ETag with the MTag. 8358 3. As a clarification to the calculation of the A2 value for message 8359 integrity assurance in the Digest authentication scheme, 8360 implementers should assume, when the entity-body is empty (that 8361 is, when the RTSP messages have no message body) that the hash of 8362 the message-body resolves to the MD5 hash of an empty string, or: 8363 H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e". 8365 4. RFC 2617 notes that a cnonce value MUST NOT be sent in an 8366 Authorization (and by extension Proxy-Authorization) header field 8367 if no qop directive has been sent. Therefore, any algorithms 8368 that have a dependency on the cnonce (including "MD5-Sess") 8369 require that the qop directive be sent. Use of the "qop" 8370 parameter is optional in RFC 2617 for the purposes of backwards 8371 compatibility with RFC 2069; since this specification defines 8372 RTSP 2.0 there is no backwards compatibility issue with 8373 mandating. Thus, all RTSP agents MUST implement qop-options. 8375 19.2. RTSP over TLS 8377 RTSP agents MUST implement RTSP over TLS as defined in this section 8378 and the next Section 19.3. RTSP MUST follow the same guidelines with 8379 regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. 8380 RTSP over TLS is separated from unsecured RTSP both on the URI level 8381 and the port level. Instead of using the "rtsp" scheme identifier in 8382 the URI, the "rtsps" scheme identifier MUST be used to signal RTSP 8383 over TLS. If no port is given in a URI with the "rtsps" scheme, port 8384 322 MUST be used for TLS over TCP/IP. 8386 When a client tries to setup an insecure channel to the server (using 8387 the "rtsp" URI), and the policy for the resource requires a secure 8388 channel, the server MUST redirect the client to the secure service by 8389 sending a 301 redirect response code together with the correct 8390 Location URI (using the "rtsps" scheme). A user or client MAY 8391 upgrade a non secured URI to a secured by changing the scheme from 8392 "rtsp" to "rtsps". A server implementing support for "rtsps" MUST 8393 allow this. 8395 It should be noted that TLS allows for mutual authentication (when 8396 using both server and client certificates). Still, one of the more 8397 common ways TLS is used is to only provide server side authentication 8398 (often to avoid client certificates). TLS is then used in addition 8399 to HTTP authentication, providing transport security and server 8400 authentication, while HTTP Authentication is used to authenticate the 8401 client. 8403 RTSP includes the possibility to keep a TCP session up between the 8404 client and server, throughout the RTSP session lifetime. It may be 8405 convenient to keep the TCP session, not only to save the extra setup 8406 time for TCP, but also the extra setup time for TLS (even if TLS uses 8407 the resume function, there will be almost two extra round trips). 8408 Still, when TLS is used, such behavior introduces extra active state 8409 in the server, not only for TCP and RTSP, but also for TLS. This may 8410 increase the vulnerability to DoS attacks. 8412 There exist a potential security vulnerability when reusing TCP and 8413 TLS state for different resources (URIs). If two different host 8414 names points at the same IP address it can be desirable to re-use the 8415 TCP/TLS connection to that server. In that case the RTSP agent 8416 having the TCP/TLS connection MUST verify that the server certificate 8417 associated with the connection has a SubjectAltName matching the host 8418 name present in the URI for the resource an RTSP request is to be 8419 issued for. 8421 In addition to these recommendations, Section 19.3 gives further 8422 recommendations of TLS usage with proxies. 8424 19.3. Security and Proxies 8426 The nature of a proxy is often to act as a "man-in-the-middle", while 8427 security is often about preventing the existence of a "man-in-the- 8428 middle". This section provides clients with the possibility to use 8429 proxies even when applying secure transports (TLS) between the RTSP 8430 agents. The TLS proxy mechanism allows for server and proxy 8431 identification using certificates. However, the client cannot be 8432 identified based on certificates. The client needs to select between 8433 using the procedure specified below or using a TLS connection 8434 directly (by-passing any proxies) to the server. The choice may be 8435 dependent on policies. 8437 There are in general two categories of proxies, the transparent 8438 proxies (of which the client is not aware) and the non-transparent 8439 proxies (of which the client is aware). This memo specifies only 8440 non-transparent RTSP proxies, i.e., proxies visible to the RTSP 8441 client and RTSP server. An infrastructure based on proxies requires 8442 that the trust model is such that both client and servers can trust 8443 the proxies to handle the RTSP messages correctly. To be able to 8444 trust a proxy, the client and server also need to be aware of the 8445 proxy. Hence, transparent proxies cannot generally be seen as 8446 trusted and will not work well with security (unless they work only 8447 at transport layer). In the rest of this section any reference to 8448 proxy will be to a non-transparent proxy, which inspects or 8449 manipulates the RTSP messages. 8451 HTTP Authentication is built on the assumption of proxies and can 8452 provide user-proxy authentication and proxy-proxy/server 8453 authentication in addition to the client-server authentication. 8455 When TLS is applied and a proxy is used, the client will connect to 8456 the proxy's address when connecting to any RTSP server. This implies 8457 that for TLS, the client will authenticate the proxy server and not 8458 the end server. Note that when the client checks the server 8459 certificate in TLS, it MUST check the proxy's identity (URI or 8460 possibly other known identity) against the proxy's identity as 8461 presented in the proxy's Certificate message. 8463 The problem is that for a proxy accepted by the client, the proxy 8464 needs to be provided information on which grounds it should accept 8465 the next-hop certificate. Both the proxy and the user may have rules 8466 for this, and the user should have the possibility to select the 8467 desired behavior. To handle this case, the Accept-Credentials header 8468 (See Section 18.2) is used, where the client can request the proxy/ 8469 proxies to relay back the chain of certificates used to authenticate 8470 any intermediate proxies as well as the server. The assumption that 8471 the proxies are viewed as trusted, gives the user a possibility to 8472 enforce policies to each trusted proxy of whether it should accept 8473 the next agent in the chain. However, it should be noted that not 8474 all deployments will return the chain of certificates used to 8475 authenticate any intermediate proxies as well as the server. An 8476 operator of such a deployment may want to hide its topology from the 8477 client. It should be noted well that the client does not have any 8478 insight into the proxy's operation. Even if the proxy is trusted, it 8479 can still return an incomplete chain of certificates. 8481 A proxy MUST use TLS for the next hop if the RTSP request includes a 8482 "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between 8483 client and proxy, or between proxy and proxy), even if the resource 8484 and the end server are not required to use it. The proxy MUST, when 8485 initiating the next hop TLS connection, use the incoming TLS 8486 connections cipher suite list, only modified by removing any cipher 8487 suites that the proxy does not support. In case a proxy fails to 8488 establish a TLS connection due to cipher suite mismatch between proxy 8489 and next hop proxy or server, this is indicated using error code 472 8490 (Failure to establish secure connection). 8492 19.3.1. Accept-Credentials 8494 The Accept-Credentials header can be used by the client to distribute 8495 simple authorization policies to intermediate proxies. The client 8496 includes the Accept-Credentials header to dictate how the proxy 8497 treats the server/next proxy certificate. There are currently three 8498 methods defined: 8500 Any, which means that the proxy (or proxies) MUST accept whatever 8501 certificate is presented. This is of course not a recommended 8502 option to use, but may be useful in certain circumstances (such 8503 as testing). 8505 Proxy: which means that the proxy (or proxies) MUST use its own 8506 policies to validate the certificate and decide whether to 8507 accept it or not. This is convenient in cases where the user 8508 has a strong trust relation with the proxy. Reasons why a 8509 strong trust relation may exist are: personal/company proxy, 8510 proxy has a out-of-band policy configuration mechanism. 8512 User, which means that the proxy (or proxies) MUST send credential 8513 information about the next hop to the client for authorization. 8514 The client can then decide whether the proxy should accept the 8515 certificate or not. See Section 19.3.2 for further details. 8517 If the Accept-Credentials header is not included in the RTSP request 8518 from the client, then the "Proxy" method MUST be used as default. If 8519 another method than the "Proxy" is to be used, then the Accept- 8520 Credentials header MUST be included in all of the RTSP requests from 8521 the client. This is because it cannot be assumed that the proxy 8522 always keeps the TLS state or the user's previous preference between 8523 different RTSP messages (in particular if the time interval between 8524 the messages is long). 8526 With the "Any" and "Proxy" methods the proxy will apply the policy as 8527 defined for each method. If the policy does not accept the 8528 credentials of the next hop, the proxy MUST respond with a message 8529 using status code 471 (Connection Credentials not accepted). 8531 An RTSP request in the direction server to client MUST NOT include 8532 the Accept-Credentials header. As for the non-secured communication, 8533 the possibility for these requests depends on the presence of a 8534 client established connection. However, if the server to client 8535 request is in relation to a session established over a TLS secured 8536 channel, it MUST be sent in a TLS secured connection. That secured 8537 connection MUST also be the one used by the last client to server 8538 request. If no such transport connection exists at the time when the 8539 server desires to send the request, the server MUST discard the 8540 message. 8542 Further policies MAY be defined and registered, but should be done so 8543 with caution. 8545 19.3.2. User approved TLS procedure 8547 For the "User" method, each proxy MUST perform the following 8548 procedure for each RTSP request: 8550 o Setup the TLS session to the next hop if not already present 8551 (i.e., run the TLS handshake, but do not send the RTSP request). 8553 o Extract the peer certificate chain for the TLS session. 8555 o Check if a matching identity and hash of the peer certificate is 8556 present in the Accept-Credentials header. If present, send the 8557 message to the next hop, and conclude these procedures. If not, 8558 go to the next step. 8560 o The proxy responds to the RTSP request with a 470 or 407 response 8561 code. The 407 response code MAY be used when the proxy requires 8562 both user and connection authorization from user or client. In 8563 this message the proxy MUST include a Connection-Credentials 8564 header, see Section 18.13 with the next hop's identity and 8565 certificate. 8567 The client MUST upon receiving a 470 or 407 response with Connection- 8568 Credentials header take the decision on whether to accept the 8569 certificate or not (if it cannot do so, the user SHOULD be 8570 consulted). If the certificate is accepted, the client has to again 8571 send the RTSP request. In that request the client has to include the 8572 Accept-Credentials header including the hash over the DER encoded 8573 certificate for all trusted proxies in the chain. 8575 Example: 8577 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8578 CSeq: 2 8579 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8580 "192.0.2.5:4589" 8581 Accept-Ranges: npt, smpte, clock 8582 Accept-Credentials: User 8584 P->C: RTSP/2.0 470 Connection Authorization Required 8585 CSeq: 2 8586 Connection-Credentials: "rtsps://test.example.org"; 8587 MIIDNTCCAp... 8589 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8590 CSeq: 3 8591 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8592 "192.0.2.5:4589" 8593 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8594 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8595 Accept-Ranges: npt, smpte, clock 8597 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8598 CSeq: 3 8599 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8600 "192.0.2.5:4589" 8601 Via: RTSP/2.0 proxy.example.org 8602 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8603 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8604 Accept-Ranges: npt, smpte, clock 8606 One implication of this process is that the connection for secured 8607 RTSP messages may take significantly more round-trip times for the 8608 first message. A complete extra message exchange between the proxy 8609 connecting to the next hop and the client results because of the 8610 process for approval for each hop. However, if each message contains 8611 the chain of proxies that the requester accepts, the remaining 8612 message exchange should not be delayed. The procedure of including 8613 the credentials in each request rather than building state in each 8614 proxy, avoids the need for revocation procedures. 8616 20. Syntax 8618 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 8619 as defined in RFC 5234 [RFC5234]. It uses the basic definitions 8620 present in RFC 5234. 8622 Please note that ABNF strings, e.g., "Accept", are case insensitive 8623 as specified in section 2.3 of RFC 5234. 8625 The RTSP syntax makes use of the ISO 10646 character set in UTF-8 8626 encoding RFC 3629 [RFC3629]. 8628 20.1. Base Syntax 8630 RTSP header values can be folded onto multiple lines if the 8631 continuation line begins with a space or horizontal tab. All linear 8632 white space, including folding, has the same semantics as SP. A 8633 recipient MAY replace any linear white space with a single SP before 8634 interpreting the field value or forwarding the message downstream. 8635 This is intended to behave exactly as HTTP/1.1 as described in RFC 8636 2616 [RFC2616]. The SWS construct is used when linear white space is 8637 optional, generally between tokens and separators. 8639 To separate the header name from the rest of value, a colon is used, 8640 which, by the above rule, allows whitespace before, but no line 8641 break, and whitespace after, including a line break. The HCOLON 8642 defines this construct. 8644 OCTET = %x00-FF ; any 8-bit sequence of data 8645 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 8646 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 8647 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 8648 ALPHA = UPALPHA / LOALPHA 8649 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 8650 CTL = %x00-1F / %x7F ; any US-ASCII control character 8651 ; (octets 0 - 31) and DEL (127) 8652 CR = %x0D ; US-ASCII CR, carriage return (13) 8653 LF = %x0A ; US-ASCII LF, linefeed (10) 8654 SP = %x20 ; US-ASCII SP, space (32) 8655 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 8656 BACKSLASH = %x5C ; US-ASCII backslash (92) 8657 CRLF = CR LF 8658 LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space 8659 SWS = [LWS] ; Separating White Space 8660 HCOLON = *( SP / HT ) ":" SWS 8661 TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs 8662 tspecials = "(" / ")" / "<" / ">" / "@" 8663 / "," / ";" / ":" / BACKSLASH / DQUOTE 8664 / "/" / "[" / "]" / "?" / "=" 8665 / "{" / "}" / SP / HT 8666 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 8667 / %x41-5A / %x5E-7A / %x7C / %x7E) 8668 ; 1* 8669 quoted-string = ( DQUOTE *qdtext DQUOTE ) 8670 qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair 8671 / UTF8-NONASCII 8672 ; No DQUOTE and no "\" 8673 quoted-pair = "\\" / ( "\" DQUOTE ) 8674 ctext = %x20-27 / %x2A-7E 8675 / %x80-FF ; any OCTET except CTLs, "(" and ")" 8676 generic-param = token [ EQUAL gen-value ] 8677 gen-value = token / host / quoted-string 8679 safe = "$" / "-" / "_" / "." / "+" 8680 extra = "!" / "*" / "'" / "(" / ")" / "," 8681 rtsp-extra = "!" / "*" / "'" / "(" / ")" 8683 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 8684 / "a" / "b" / "c" / "d" / "e" / "f" 8685 LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 8686 ; lowercase "a-f" Hex 8687 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 8689 unreserved = ALPHA / DIGIT / safe / extra 8690 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 8692 base64 = *base64-unit [base64-pad] 8693 base64-unit = 4base64-char 8694 base64-pad = (2base64-char "==") / (3base64-char "=") 8695 base64-char = ALPHA / DIGIT / "+" / "/" 8696 SLASH = SWS "/" SWS ; slash 8697 EQUAL = SWS "=" SWS ; equal 8698 LPAREN = SWS "(" SWS ; left parenthesis 8699 RPAREN = SWS ")" SWS ; right parenthesis 8700 COMMA = SWS "," SWS ; comma 8701 SEMI = SWS ";" SWS ; semicolon 8702 COLON = SWS ":" SWS ; colon 8703 MINUS = SWS "-" SWS ; minus/dash 8704 LDQUOT = SWS DQUOTE ; open double quotation mark 8705 RDQUOT = DQUOTE SWS ; close double quotation mark 8706 RAQUOT = ">" SWS ; right angle quote 8707 LAQUOT = SWS "<" ; left angle quote 8709 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 8710 UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 8711 UTF8-1 = 8712 UTF8-2 = 8713 UTF8-3 = 8714 UTF8-4 = 8715 UTF8-CONT = %x80-BF 8717 POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] 8718 FLOAT = ["-"] POS-FLOAT 8720 20.2. RTSP Protocol Definition 8722 20.2.1. Generic Protocol elements 8723 RTSP-IRI = schemes ":" IRI-rest 8724 IRI-rest = ihier-part [ "?" iquery ] 8725 ihier-part = "//" iauthority ipath-abempty 8726 RTSP-IRI-ref = RTSP-IRI / irelative-ref 8727 irelative-ref = irelative-part [ "?" iquery ] 8728 irelative-part = "//" iauthority ipath-abempty 8729 / ipath-absolute 8730 / ipath-noscheme 8731 / ipath-empty 8733 iauthority = < As defined in RFC 3987> 8734 ipath = ipath-abempty ; begins with "/" or is empty 8735 / ipath-absolute ; begins with "/" but not "//" 8736 / ipath-noscheme ; begins with a non-colon segment 8737 / ipath-rootless ; begins with a segment 8738 / ipath-empty ; zero characters 8740 ipath-abempty = *( "/" isegment ) 8741 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 8742 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 8743 ipath-rootless = isegment-nz *( "/" isegment ) 8744 ipath-empty = 0 8746 isegment = *ipchar [";" *ipchar] 8747 isegment-nz = 1*ipchar [";" *ipchar] 8748 / ";" *ipchar 8749 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 8750 / ";" *ipchar-nc 8751 ; non-zero-length segment without any colon ":" 8752 ; No parameter (; delimited) inside path. 8754 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 8755 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 8756 ; sub-delims is different from RFC 3987 8757 ; not including ";" 8759 iquery = < As defined in RFC 3987> 8760 iunreserved = < As defined in RFC 3987> 8761 pct-encoded = < As defined in RFC 3987> 8762 RTSP-URI = schemes ":" URI-rest 8763 RTSP-REQ-URI = schemes ":" URI-req-rest 8764 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 8765 RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel 8766 schemes = "rtsp" / "rtsps" / scheme 8767 scheme = < As defined in RFC 3986> 8768 URI-rest = hier-part [ "?" query ] 8769 URI-req-rest = hier-part [ "?" query ] 8770 ; Note fragment part not allowed in requests 8771 hier-part = "//" authority path-abempty 8773 RTSP-Relative = relative-part [ "?" query ] 8774 RTSP-REQ-Rel = relative-part [ "?" query ] 8775 relative-part = "//" authority path-abempty 8776 / path-absolute 8777 / path-noscheme 8778 / path-empty 8780 authority = < As defined in RFC 3986> 8781 query = < As defined in RFC 3986> 8783 path = path-abempty ; begins with "/" or is empty 8784 / path-absolute ; begins with "/" but not "//" 8785 / path-noscheme ; begins with a non-colon segment 8786 / path-rootless ; begins with a segment 8787 / path-empty ; zero characters 8789 path-abempty = *( "/" segment ) 8790 path-absolute = "/" [ segment-nz *( "/" segment ) ] 8791 path-noscheme = segment-nz-nc *( "/" segment ) 8792 path-rootless = segment-nz *( "/" segment ) 8793 path-empty = 0 8795 segment = *pchar [";" *pchar] 8796 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 8797 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 8798 ; non-zero-length segment without any colon ":" 8799 ; No parameter (; delimited) inside path. 8801 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 8802 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 8804 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 8805 / "*" / "+" / "," / "=" 8806 ; sub-delims is different from RFC 3986/3987 8807 ; not including ";" 8809 smpte-range = smpte-type [EQUAL smpte-range-spec] 8810 ; See section 4.4 8811 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 8812 / ( "-" smpte-time ) 8813 smpte-type = "smpte" / "smpte-30-drop" 8814 / "smpte-25" / smpte-type-extension 8815 ; other timecodes may be added 8816 smpte-type-extension = "smpte" token 8817 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 8818 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 8820 npt-range = "npt" [EQUAL npt-range-spec] 8821 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 8822 npt-time = "now" / npt-sec / npt-hhmmss 8823 npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] 8824 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] 8825 npt-hh = 1*19DIGIT ; any positive number 8826 npt-mm = 1*2DIGIT ; 0-59 8827 npt-ss = 1*2DIGIT ; 0-59 8829 utc-range = "clock" [EQUAL utc-range-spec] 8830 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 8831 utc-time = utc-date "T" utc-clock "Z" 8832 utc-date = 8DIGIT 8833 utc-clock = 6DIGIT [ "." 1*9DIGIT ] 8835 feature-tag = token 8837 session-id = 1*256( ALPHA / DIGIT / safe ) 8839 extension-header = header-name HCOLON header-value 8840 header-name = token 8841 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 8843 20.2.2. Message Syntax 8844 RTSP-message = Request / Response ; RTSP/2.0 messages 8846 Request = Request-Line 8847 *((general-header 8848 / request-header 8849 / message-header) CRLF) 8850 CRLF 8851 [ message-body-data ] 8853 Response = Status-Line 8854 *((general-header 8855 / response-header 8856 / message-header) CRLF) 8857 CRLF 8858 [ message-body-data ] 8860 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 8862 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 8863 Method = "DESCRIBE" 8864 / "GET_PARAMETER" 8865 / "OPTIONS" 8866 / "PAUSE" 8867 / "PLAY" 8868 / "PLAY_NOTIFY" 8869 / "REDIRECT" 8870 / "SETUP" 8871 / "SET_PARAMETER" 8872 / "TEARDOWN" 8873 / extension-method 8875 extension-method = token 8877 Request-URI = "*" / RTSP-REQ-URI 8878 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 8880 message-body-data = 1*OCTET 8882 Status-Code = "100" ; Continue 8883 / "200" ; OK 8884 / "301" ; Moved Permanently 8885 / "302" ; Found 8886 / "303" ; See Other 8887 / "304" ; Not Modified 8888 / "305" ; Use Proxy 8889 / "400" ; Bad Request 8890 / "401" ; Unauthorized 8891 / "402" ; Payment Required 8892 / "403" ; Forbidden 8893 / "404" ; Not Found 8894 / "405" ; Method Not Allowed 8895 / "406" ; Not Acceptable 8896 / "407" ; Proxy Authentication Required 8897 / "408" ; Request Time-out 8898 / "410" ; Gone 8899 / "412" ; Precondition Failed 8900 / "413" ; Request Message Body Too Large 8901 / "414" ; Request-URI Too Large 8902 / "415" ; Unsupported Media Type 8903 / "451" ; Parameter Not Understood 8904 / "452" ; reserved 8905 / "453" ; Not Enough Bandwidth 8906 / "454" ; Session Not Found 8907 / "455" ; Method Not Valid in This State 8908 / "456" ; Header Field Not Valid for Resource 8909 / "457" ; Invalid Range 8910 / "458" ; Parameter Is Read-Only 8911 / "459" ; Aggregate operation not allowed 8912 / "460" ; Only aggregate operation allowed 8913 / "461" ; Unsupported Transport 8914 / "462" ; Destination Unreachable 8915 / "463" ; Destination Prohibited 8916 / "464" ; Data Transport Not Ready Yet 8917 / "465" ; Notification Reason Unknown 8918 / "466" ; Key Management Error 8919 / "470" ; Connection Authorization Required 8920 / "471" ; Connection Credentials not accepted 8921 / "472" ; Failure to establish secure connection 8922 / "500" ; Internal Server Error 8923 / "501" ; Not Implemented 8924 / "502" ; Bad Gateway 8925 / "503" ; Service Unavailable 8926 / "504" ; Gateway Time-out 8927 / "505" ; RTSP Version not supported 8928 / "551" ; Option not supported 8929 / extension-code 8931 extension-code = 3DIGIT 8933 Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) 8934 general-header = Accept-Ranges 8935 / Cache-Control 8936 / Connection 8937 / CSeq 8938 / Date 8939 / Media-Properties 8940 / Media-Range 8941 / Pipelined-Requests 8942 / Proxy-Supported 8943 / Range 8944 / RTP-Info 8945 / Scale 8946 / Seek-Style 8947 / Server 8948 / Session 8949 / Speed 8950 / Supported 8951 / Timestamp 8952 / Transport 8953 / User-Agent 8954 / Via 8955 / extension-header 8957 request-header = Accept 8958 / Accept-Credentials 8959 / Accept-Encoding 8960 / Accept-Language 8961 / Authorization 8962 / Bandwidth 8963 / Blocksize 8964 / From 8965 / If-Match 8966 / If-Modified-Since 8967 / If-None-Match 8968 / Notify-Reason 8969 / Proxy-Authorization 8970 / Proxy-Require 8971 / Referrer 8972 / Request-Status 8973 / Require 8974 / Terminate-Reason 8975 / extension-header 8977 response-header = Authentication-Info 8978 / Connection-Credentials 8979 / Location 8980 / MTag 8981 / Proxy-Authenticate 8982 / Proxy-Authentication-Info 8983 / Public 8984 / Retry-After 8985 / Unsupported 8986 / WWW-Authenticate 8987 / extension-header 8989 message-header = Allow 8990 / Content-Base 8991 / Content-Encoding 8992 / Content-Language 8993 / Content-Length 8994 / Content-Location 8995 / Content-Type 8996 / Expires 8997 / Last-Modified 8998 / extension-header 9000 20.2.3. Header Syntax 9002 Accept = "Accept" HCOLON 9003 [ accept-range *(COMMA accept-range) ] 9004 accept-range = media-type-range [SEMI accept-params] 9005 media-type-range = ( "*/*" 9006 / ( m-type SLASH "*" ) 9007 / ( m-type SLASH m-subtype ) 9008 ) *( SEMI m-parameter ) 9009 accept-params = "q" EQUAL qvalue *(SEMI generic-param ) 9010 qvalue = ( "0" [ "." *3DIGIT ] ) 9011 / ( "1" [ "." *3("0") ] ) 9012 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision 9013 cred-decision = ("User" [LWS cred-info]) 9014 / "Proxy" 9015 / "Any" 9016 / (token [LWS 1*header-value]) 9017 ; For future extensions 9018 cred-info = cred-info-data *(COMMA cred-info-data) 9020 cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg 9021 SEMI base64 9022 hash-alg = "sha-256" / extension-alg 9023 extension-alg = token 9024 Accept-Encoding = "Accept-Encoding" HCOLON 9025 [ encoding *(COMMA encoding) ] 9026 encoding = codings [SEMI accept-params] 9027 codings = content-coding / "*" 9028 content-coding = "identity" / token 9029 Accept-Language = "Accept-Language" HCOLON 9030 language *(COMMA language) 9031 language = language-range [SEMI accept-params] 9032 language-range = language-tag / "*" 9033 language-tag = primary-tag *( "-" subtag ) 9034 primary-tag = 1*8ALPHA 9035 subtag = 1*8ALPHA 9036 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges 9037 acceptable-ranges = (range-unit *(COMMA range-unit)) 9038 range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25" 9039 / "clock" / extension-format 9040 extension-format = token 9041 Allow = "Allow" HCOLON Method *(COMMA Method) 9042 Authentication-Info = "Authentication-Info" HCOLON auth-info 9043 auth-info = auth-info-entry *(COMMA auth-info-entry) 9044 auth-info-entry = nextnonce 9045 / message-qop 9046 / response-auth 9047 / cnonce 9048 / nonce-count 9049 nextnonce = "nextnonce" EQUAL nonce-value 9050 response-auth = "rspauth" EQUAL response-digest 9051 response-digest = DQUOTE *LHEX DQUOTE 9052 Authorization = "Authorization" HCOLON credentials 9053 credentials = basic-credential 9054 / digest-credential 9055 / other-response 9056 basic-credential = "Basic" LWS basic-credentials 9057 basic-credentials = base64 ; Base64 encoding of user-password 9058 user-password = basic-username ":" password 9059 basic-username = *CF-TEXT 9060 CF-TEXT = %x20-39 / %x3B-7E / %x80-FF ; TEXT without : 9061 password = *TEXT 9062 digest-credential = ("Digest" LWS digest-response) 9063 digest-response = dig-resp *(COMMA dig-resp) 9064 dig-resp = username / realm / nonce / digest-uri 9065 / dresponse / algorithm / cnonce 9066 / opaque / message-qop 9067 / nonce-count / auth-param 9068 username = "username" EQUAL username-value 9069 username-value = quoted-string 9070 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 9071 digest-uri-value = RTSP-REQ-URI 9072 message-qop = "qop" EQUAL qop-value 9073 cnonce = "cnonce" EQUAL cnonce-value 9074 cnonce-value = nonce-value 9075 nonce-count = "nc" EQUAL nc-value 9076 nc-value = 8LHEX 9077 dresponse = "response" EQUAL request-digest 9078 request-digest = LDQUOT 32LHEX RDQUOT 9079 auth-param = auth-param-name EQUAL 9080 ( token / quoted-string ) 9081 auth-param-name = token 9082 other-response = auth-scheme LWS auth-param 9083 *(COMMA auth-param) 9084 auth-scheme = token 9086 Bandwidth = "Bandwidth" HCOLON 1*19DIGIT 9088 Blocksize = "Blocksize" HCOLON 1*9DIGIT 9090 Cache-Control = "Cache-Control" HCOLON cache-directive 9091 *(COMMA cache-directive) 9092 cache-directive = cache-rqst-directive 9093 / cache-rspns-directive 9095 cache-rqst-directive = "no-cache" 9096 / "max-stale" [EQUAL delta-seconds] 9097 / "min-fresh" EQUAL delta-seconds 9098 / "only-if-cached" 9099 / cache-extension 9101 cache-rspns-directive = "public" 9102 / "private" 9103 / "no-cache" 9104 / "no-transform" 9105 / "must-revalidate" 9106 / "proxy-revalidate" 9107 / "max-age" EQUAL delta-seconds 9108 / cache-extension 9110 cache-extension = token [EQUAL (token / quoted-string)] 9111 delta-seconds = 1*19DIGIT 9113 Connection = "Connection" HCOLON connection-token 9114 *(COMMA connection-token) 9115 connection-token = "close" / token 9117 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 9118 cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64 9119 Content-Base = "Content-Base" HCOLON RTSP-URI 9120 Content-Encoding = "Content-Encoding" HCOLON 9121 content-coding *(COMMA content-coding) 9122 Content-Language = "Content-Language" HCOLON 9123 language-tag *(COMMA language-tag) 9124 Content-Length = "Content-Length" HCOLON 1*19DIGIT 9125 Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref 9126 Content-Type = "Content-Type" HCOLON media-type 9127 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 9128 m-type = discrete-type / composite-type 9129 discrete-type = "text" / "image" / "audio" / "video" 9130 / "application" / extension-token 9131 composite-type = "message" / "multipart" / extension-token 9132 extension-token = ietf-token / x-token 9133 ietf-token = token 9134 x-token = "x-" token 9135 m-subtype = extension-token / iana-token 9136 iana-token = token 9137 m-parameter = m-attribute EQUAL m-value 9138 m-attribute = token 9139 m-value = token / quoted-string 9141 CSeq = "CSeq" HCOLON cseq-nr 9142 cseq-nr = 1*9DIGIT 9143 Date = "Date" HCOLON RTSP-date 9144 RTSP-date = date-time ; 9145 date-time = 9146 Expires = "Expires" HCOLON RTSP-date 9147 From = "From" HCOLON from-spec 9148 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 9149 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 9150 addr-spec = RTSP-REQ-URI / absolute-URI 9151 absolute-URI = < As defined in RFC 3986> 9152 display-name = *(token LWS) / quoted-string 9153 from-param = tag-param / generic-param 9154 tag-param = "tag" EQUAL token 9155 If-Match = "If-Match" HCOLON ("*" / message-tag-list) 9156 message-tag-list = message-tag *(COMMA message-tag) 9157 message-tag = [ weak ] opaque-tag 9158 weak = "W/" 9159 opaque-tag = quoted-string 9160 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 9161 If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list) 9162 Last-Modified = "Last-Modified" HCOLON RTSP-date 9163 Location = "Location" HCOLON RTSP-REQ-URI 9164 Media-Properties = "Media-Properties" HCOLON [media-prop-list] 9165 media-prop-list = media-prop-value *(COMMA media-prop-value) 9166 media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) 9167 / "Beginning-Only" 9168 / "No-Seeking" 9169 / "Immutable" 9170 / "Dynamic" 9171 / "Time-Progressing" 9172 / "Unlimited" 9173 / ("Time-Limited" EQUAL utc-time) 9174 / ("Time-Duration" EQUAL POS-FLOAT) 9175 / ("Scales" EQUAL scale-value-list) 9176 / media-prop-ext 9177 media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] 9178 scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE 9179 scale-entry = scale-value / (scale-value COLON scale-value) 9180 scale-value = FLOAT 9181 Media-Range = "Media-Range" HCOLON [ranges-list] 9182 ranges-list = ranges-spec *(COMMA ranges-spec) 9183 MTag = "MTag" HCOLON message-tag 9184 Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val 9185 Notify-Reas-val = "end-of-stream" 9186 / "media-properties-update" 9187 / "scale-change" 9188 / Notify-Reason-extension 9189 Notify-Reason-extension = token 9190 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 9191 startup-id = 1*8DIGIT 9193 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list 9194 challenge-list = challenge *(COMMA challenge) 9195 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 9196 / ("Basic" LWS realm) 9197 / other-challenge 9198 other-challenge = auth-scheme LWS auth-param 9199 *(COMMA auth-param) 9200 digest-cln = realm / domain / nonce 9201 / opaque / stale / algorithm 9202 / qop-options / auth-param 9203 realm = "realm" EQUAL realm-value 9204 realm-value = quoted-string 9205 domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref 9206 *(1*SP RTSP-REQ-Ref ) RDQUOT 9207 nonce = "nonce" EQUAL nonce-value 9208 nonce-value = quoted-string 9209 opaque = "opaque" EQUAL quoted-string 9210 stale = "stale" EQUAL ( "true" / "false" ) 9211 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 9212 qop-options = "qop" EQUAL LDQUOT qop-value 9213 *("," qop-value) RDQUOT 9214 qop-value = "auth" / "auth-int" / token 9215 Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON auth-info 9216 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials 9217 Proxy-Require = "Proxy-Require" HCOLON feature-tag-list 9218 feature-tag-list = feature-tag *(COMMA feature-tag) 9219 Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] 9221 Public = "Public" HCOLON Method *(COMMA Method) 9223 Range = "Range" HCOLON ranges-spec 9225 ranges-spec = npt-range / utc-range / smpte-range 9226 / range-ext 9227 range-ext = extension-format [EQUAL range-value] 9228 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 9230 Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) 9231 Request-Status = "Request-Status" HCOLON req-status-info 9232 req-status-info = cseq-info LWS status-info LWS reason-info 9233 cseq-info = "cseq" EQUAL cseq-nr 9234 status-info = "status" EQUAL Status-Code 9235 reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE 9236 Require = "Require" HCOLON feature-tag-list 9237 RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec 9238 *(COMMA rtsp-info-spec)] 9239 rtsp-info-spec = stream-url 1*ssrc-parameter 9240 stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE 9241 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 9242 ri-parameter *(SEMI ri-parameter) 9243 ri-parameter = ("seq" EQUAL 1*5DIGIT) 9244 / ("rtptime" EQUAL 1*10DIGIT) 9245 / generic-param 9247 Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds) 9248 Scale = "Scale" HCOLON scale-value 9249 Seek-Style = "Seek-Style" HCOLON Seek-S-values 9250 Seek-S-values = "RAP" 9251 / "CoRAP" 9252 / "First-Prior" 9253 / "Next" 9254 / Seek-S-value-ext 9255 Seek-S-value-ext = token 9257 Server = "Server" HCOLON ( product / comment ) 9258 *(LWS (product / comment)) 9259 product = token [SLASH product-version] 9260 product-version = token 9261 comment = LPAREN *( ctext / quoted-pair) RPAREN 9263 Session = "Session" HCOLON session-id 9264 [ SEMI "timeout" EQUAL delta-seconds ] 9266 Speed = "Speed" HCOLON lower-bound MINUS upper-bound 9267 lower-bound = POS-FLOAT 9268 upper-bound = POS-FLOAT 9270 Supported = "Supported" HCOLON [feature-tag-list] 9271 Terminate-Reason = "Terminate-Reason" HCOLON TR-Info 9272 TR-Info = TR-Reason *(SEMI TR-Parameter) 9273 TR-Reason = "Session-Timeout" 9274 / "Server-Admin" 9275 / "Internal-Error" 9276 / token 9277 TR-Parameter = TR-time / TR-user-msg / generic-param 9278 TR-time = "time" EQUAL utc-time 9279 TR-user-msg = "user-msg" EQUAL quoted-string 9281 Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay] 9282 timestamp-value = *19DIGIT [ "." *9DIGIT ] 9283 delay = *9DIGIT [ "." *9DIGIT ] 9285 Transport = "Transport" HCOLON transport-spec 9286 *(COMMA transport-spec) 9287 transport-spec = transport-id *trns-parameter 9288 transport-id = trans-id-rtp / other-trans 9289 trans-id-rtp = "RTP/" profile ["/" lower-transport] 9290 ; no LWS is allowed inside transport-id 9291 other-trans = token *("/" token) 9292 profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token 9293 lower-transport = "TCP" / "UDP" / token 9294 trns-parameter = (SEMI ( "unicast" / "multicast" )) 9295 / (SEMI "interleaved" EQUAL channel ["-" channel]) 9296 / (SEMI "ttl" EQUAL ttl) 9297 / (SEMI "layers" EQUAL 1*DIGIT) 9298 / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) 9299 / (SEMI "mode" EQUAL mode-spec) 9300 / (SEMI "dest_addr" EQUAL addr-list) 9301 / (SEMI "src_addr" EQUAL addr-list) 9302 / (SEMI "setup" EQUAL contrans-setup) 9303 / (SEMI "connection" EQUAL contrans-con) 9304 / (SEMI "RTCP-mux") 9305 / (SEMI "MIKEY" EQUAL MIKEY-Value) 9306 / (SEMI trn-param-ext) 9307 contrans-setup = "active" / "passive" / "actpass" 9308 contrans-con = "new" / "existing" 9309 trn-param-ext = par-name [EQUAL trn-par-value] 9310 par-name = token 9311 trn-par-value = *(rtsp-unreserved / quoted-string) 9312 ttl = 1*3DIGIT ; 0 to 255 9313 ssrc = 8HEX 9314 channel = 1*3DIGIT ; 0 to 255 9315 MIKEY-Value = base64 9316 mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) 9317 mode = "PLAY" / token 9318 addr-list = quoted-addr *(SLASH quoted-addr) 9319 quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE 9320 host-port = ( host [":" port] ) 9321 / ( ":" port ) 9322 extension-addr = 1*qdtext 9323 host = < As defined in RFC 3986> 9324 port = < As defined in RFC 3986> 9325 Unsupported = "Unsupported" HCOLON feature-tag-list 9326 User-Agent = "User-Agent" HCOLON ( product / comment ) 9327 *(LWS (product / comment)) 9328 Via = "Via" HCOLON via-parm *(COMMA via-parm) 9329 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 9330 via-params = via-ttl / via-maddr 9331 / via-received / via-extension 9332 via-ttl = "ttl" EQUAL ttl 9333 via-maddr = "maddr" EQUAL host 9334 via-received = "received" EQUAL (IPv4address / IPv6address) 9335 IPv4address = < As defined in RFC 3986> 9336 IPv6address = < As defined in RFC 3986> 9337 via-extension = generic-param 9338 sent-protocol = protocol-name SLASH protocol-version 9339 SLASH transport-prot 9340 protocol-name = "RTSP" / token 9341 protocol-version = token 9342 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 9343 other-transport = token 9344 sent-by = host [ COLON port ] 9346 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 9348 20.3. SDP extension Syntax 9350 This section defines in ABNF the SDP extensions defined for RTSP. 9351 See Appendix D for the definition of the extensions in text. 9353 control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF 9355 a-range-def = "a=range:" ranges-spec CRLF 9357 a-mtag-def = "a=mtag:" message-tag CRLF 9359 21. Security Considerations 9361 The security considerations and threats around RTSP and its usage can 9362 be divided into considerations around the signaling protocol itself 9363 and the issues related to the media stream delivery. However, when 9364 it comes to mitigations of security threats, a threat depending on 9365 the media stream delivery may in fact be mitigated by a mechanism in 9366 the signaling protocol. 9368 There are several chapters and an appendix in this document that 9369 define security solutions for the protocol. We will reference them 9370 when discussing the threats below. But the reader should take 9371 special notice of the Security Framework (Section 19) and the 9372 specification of how to use SRTP and its key-mangement 9373 (Appendix C.1.4) to achieve certain aspects of the media security. 9375 21.1. Signaling Protocol Threats 9377 This section focuses on issues related to the signaling protocol. 9378 Because of the similarity in syntax and usage between RTSP servers 9379 and HTTP servers, the security considerations outlined in [H15] apply 9380 also. 9382 Specifically, please note the following: 9384 Abuse of Server Log Information: A server is in the position to save 9385 personal data about a user's requests which might identify 9386 their media consumption patterns or subjects of interest. This 9387 information is clearly confidential in nature and its handling 9388 can be constrained by law in certain countries. RTSP servers 9389 will presumably have similar logging mechanisms to HTTP, and 9390 thus should be equally guarded in protecting the contents of 9391 those logs, thus protecting the privacy of the users of the 9392 servers. People using the RTSP protocol to provide media are 9393 responsible for ensuring that logging material is not 9394 distributed without the permission of any individuals that are 9395 identifiable by the published results. 9397 Transfer of Sensitive Information: There is no reason to believe 9398 that information transferred or controlled via RTSP may be any 9399 less sensitive than that normally transmitted via HTTP. 9400 Therefore, all of the precautions regarding the protection of 9401 data privacy and user privacy apply to implementors of RTSP 9402 clients, servers, and proxies. See [H15.1.2] for further 9403 details. 9405 Attacks Based On File and Path Names: Though RTSP URIs are opaque 9406 handles that do not necessarily have file system semantics, it 9407 is anticipated that many implementations will translate 9408 portions of the Request-URIs directly to file system calls. In 9409 such cases, file systems SHOULD follow the precautions outlined 9410 in [H15.2], such as checking for ".." in path components. 9412 Personal Information: RTSP clients are often privy to the same 9413 information that HTTP clients are (user name, location, etc.) 9414 and thus should be equally sensitive. See [H15.1] for further 9415 recommendations. 9417 Privacy Issues Connected to Accept Headers: Since may of the same 9418 "Accept" headers exist in RTSP as in HTTP, the same caveats 9419 outlined in [H15.1.4] with regards to their use should be 9420 followed. 9422 DNS Spoofing: Presumably, given the longer connection times 9423 typically associated to RTSP sessions relative to HTTP 9424 sessions, RTSP client DNS optimizations should be less 9425 prevalent. Nonetheless, the recommendations provided in 9426 [H15.3] are still relevant to any implementation which attempts 9427 to rely on a DNS-to-IP mapping to hold beyond a single use of 9428 the mapping. 9430 Location Headers and Spoofing: If a single server supports multiple 9431 organizations that do not trust each another, then it MUST 9432 check the values of Location and Content-Location header fields 9433 in responses that are generated under control of said 9434 organizations to make sure that they do not attempt to 9435 invalidate resources over which they have no authority. 9436 ([H15.4]) 9438 In addition to the recommendations in the current HTTP specification 9439 (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 9440 2068 [RFC2068], future HTTP specifications may provide additional 9441 guidance on security issues. 9443 The following are added considerations for RTSP implementations. 9445 Session hijacking: Since there is no or little relation between a 9446 transport layer connection and an RTSP session, it is possible 9447 for a malicious client to issue requests with random session 9448 identifiers which could affect other clients of an unsuspecting 9449 server. To mitigate this the server SHALL use a large, random 9450 and non-sequential session identifier to minimize the 9451 possibility of this kind of attack. However, unless the RTSP 9452 signaling is always confidentiality protected, e.g., using TLS, 9453 an on-path attacker will be able to hijack a session. Another 9454 choice for preventing session hijacking is to use client 9455 authentication and only allow the authenticated client creating 9456 the session to access that session. 9458 Authentication: Servers SHOULD implement both basic and digest 9459 [RFC2617] authentication. In environments requiring tighter 9460 security for the control messages, the transport layer 9461 mechanism TLS [RFC5246] SHOULD be used. 9463 Suspicious behavior: RTSP servers upon detecting instances of 9464 behavior which is deemed a security risk SHOULD return error 9465 code 403 (Forbidden). RTSP servers SHOULD also be aware of 9466 attempts to probe the server for weaknesses and entry points 9467 and MAY arbitrarily disconnect and ignore further requests from 9468 clients which are deemed to be in violation of local security 9469 policy. 9471 TLS through proxies: If one uses the possibility to connect TLS in 9472 multiple legs (Section 19.3) one really needs to be aware of 9473 the trust model. That procedure requires full faith and trust 9474 in all proxies, which will be identified, that one allows to 9475 connect through. They are men in the middle and have access to 9476 all that goes on over the TLS connection. Thus it is important 9477 to consider if that trust model is acceptable in the actual 9478 application. Further discussion of the actual trust model is 9479 in Section 19.3. 9481 Resource Exhaustion: As RTSP is a stateful protocol and establishes 9482 resource usage on the server there is a clear possibility to 9483 attack the server by trying to overbook these resources to 9484 perform a denial of service attack. This attack can be both 9485 against ongoing sessions and to prevent others from 9486 establishing sessions. RTSP agents will need to have 9487 mechanisms to prevent single peers from consuming extensive 9488 amounts of resources. The methods for guarding against this 9489 are varied and depends on the agent's role and capabilities and 9490 policies. Each implementation has to carefully consider their 9491 methods and policies to mitigate this threat. For example 9492 regarding handling of connections there are recommendations in 9493 Section 10.7. 9495 The above threats and considerations have resulted in a set of 9496 security functions and mechanisms built into or used by the protocol. 9497 The signaling protocol relies on two security features defined in the 9498 Security Framework (Section 19) namely client authentication using 9499 HTTP authentication and TLS based transport protection of the 9500 signaling messages. Both of these mechanisms are required to be 9501 implemented by any RTSP agent. 9503 A number of different security mitigations have been designed into 9504 the protocol and will be instantiated if the specification is 9505 implemented written, for example by ensuring sufficient amount of 9506 entropy in the randomly generated session identifiers when not using 9507 client authentication to minimize the risk of session hijacking. 9508 When client authentication is used the protection against hijacking 9509 will be greatly improved by scoping the accessible sessions to the 9510 one this client identity has created. Some of the above threats are 9511 such that the implementation of the RTSP functionality itself needs 9512 to consider which policy and strategy it uses to mitigate them. 9514 21.2. Media Stream Delivery Threats 9516 The fact that RTSP establishes and controls a media stream delivery 9517 results in a set of security issues related to the media streams. 9518 This section will attempt to analyze general threats, however the 9519 choice of media stream transport protocol, such as RTP will result in 9520 some differences in threats and what mechanisms that exist to 9521 mitigate them. Thus it becomes important that each specification of 9522 a new media stream transport and delivery protocol usable by RTSP 9523 requires its own security analysis. This section includes one for 9524 RTP. 9526 The set of general threats from or by the media stream delivery 9527 itself are: 9529 Concentrated denial-of-service attack: The protocol offers the 9530 opportunity for a remote-controlled denial-of-service (DoS) 9531 attack, where the media stream is the hammer in that DoS attack. 9532 See Section 21.2.1. 9534 Media Confidentiality: The media delivery may contain content of any 9535 type and it is not possible in general to determine how sensitive 9536 this content is from a confidentiality point. Thus it is a strong 9537 requirement that any media delivery protocol provides a method for 9538 providing confidentiality of the actual media content. In 9539 addition to the media level confidentiality it becomes critical 9540 that no resource identifiers used in the signaling are exposed to 9541 an attacker as they may have human understandable names, or may be 9542 also available to the attacker so they can determine the content 9543 the user was delivered. Thus the signaling protocol must also 9544 provide confidentiality protection of any information related to 9545 the media resource. 9547 Media Integrity and Authentication: There are several reasons, such 9548 as discrediting the target, misinformation of the target, why an 9549 attacker will be interested in substituting the media stream sent 9550 out from the RTSP server with one of the attacker's creation or 9551 selection. Therefore it is important that the media protocol 9552 provides mechanisms to verify the source authentication, integrity 9553 and prevent replay attacks on the media stream. 9555 Scope of Multicast: If RTSP is used to control the transmission of 9556 media onto a multicast network the scope of the delivery must be 9557 considered. RTSP supports the TTL Transport header parameter to 9558 indicate this scope for IPv4. IPv6 has a different mechanism for 9559 scope boundary. However, such scope control has risks, as it may 9560 be set too large and distribute media beyond the intended scope. 9562 Below (Section 21.2.2) we do a protocol specific analysis of security 9563 considerations for RTP based media transport. In that section we 9564 also make clear the requirements on implementing security functions 9565 for RTSP agents supporting media delivery over RTP. 9567 21.2.1. Remote Denial of Service Attack 9569 The attacker may initiate traffic flows to one or more IP addresses 9570 by specifying them as the destination in SETUP requests. While the 9571 attacker's IP address may be known in this case, this is not always 9572 useful in prevention of more attacks or ascertaining the attacker's 9573 identity. Thus, an RTSP server MUST only allow client-specified 9574 destinations for RTSP-initiated traffic flows if the server has 9575 ensured that the specified destination address accepts receiving 9576 media through different security mechanisms. Security mechanisms 9577 that are acceptable in order of increasing generality are: 9579 o Verification of the client's identity against a database of known 9580 users using RTSP authentication mechanisms (preferably digest 9581 authentication or stronger) 9583 o A list of addresses that have consented to be media destinations, 9584 especially considering user identity 9586 o Media path based verification 9588 The server SHOULD NOT allow the destination field to be set unless a 9589 mechanism exists in the system to authorize the request originator to 9590 direct streams to the recipient. It is preferred that this 9591 authorization be performed by the media recipient (destination) 9592 itself and the credentials passed along to the server. However, in 9593 certain cases, such as when the recipient address is a multicast 9594 group, or when the recipient is unable to communicate with the server 9595 in an out-of-band manner, this may not be possible. In these cases 9596 the server may chose another method such as a server-resident 9597 authorization list to ensure that the request originator has the 9598 proper credentials to request stream delivery to the recipient. 9600 One solution that performs the necessary verification of acceptance 9601 of media suitable for unicast based delivery is the Interactive 9602 Connectivity Establishment (ICE) [RFC5245] based NAT traversal method 9603 described in [I-D.ietf-mmusic-rtsp-nat]. This mechanism uses random 9604 passwords and a username so that the probability of unintended 9605 indication as a valid media destination is very low. In addition the 9606 server includes in its Session Traversal Utilities for NAT (STUN) 9607 [RFC5389] requests a cookie (consisting of random material) that the 9608 destination echoes back, thus the solution also safe-guards against 9609 having an off-path attacker being able to spoof the STUN checks. 9610 This leaves this solution vulnerable only to on-path attackers that 9611 can see the STUN requests go to the target of attack and thus forge a 9612 response. 9614 For delivery to multicast addresses there is a need for another 9615 solution which is not specified in this memo. 9617 21.2.2. RTP Security analysis 9619 RTP is a commonly used media transport protocol and has been the most 9620 common choice for RTSP 1.0 implementations. The core RTP protocol 9621 has been in use for a long time and it has well-known security 9622 properties and the RTP security consideration (Section 9 of 9623 [RFC3550]) needs to be reviewed. In perspective of the usage of RTP 9624 in context of RTSP the following properties should be noted: 9626 Stream Additions: RTP has support for multiple simultaneous media 9627 streams in each RTP session. As some use cases require support 9628 for non-synchronized adding and removal of media streams and their 9629 identifiers an attacker can easily insert additional media streams 9630 into a session context that according to protocol design is 9631 intended to be played out. Another threat vector is one of denial 9632 of service by exhausting the resources of the RTP session 9633 receiver, for example by using a large number of SSRC identifiers 9634 simultaneously. The strong mitigation of this is to ensure that 9635 one cryptographically authenticates any incoming packet flow to 9636 the RTP session. Weak mitigations like blocking additional media 9637 streams in session contexts easily lead to a denial of service 9638 vulnerability in addition to preventing certain RTP extensions or 9639 use cases which rely on multiple media streams, such as RTP 9640 retransmission [RFC4588] to function. 9642 Forged Feedback: The built in RTP control Protocol (RTCP) also 9643 offers a large attack surface for a couple of different types of 9644 attacks. One venue is to send RTCP feedback to the media sender 9645 indicating large amounts of packet loss and thus trigger a media 9646 bit-rate adaptation response from the sender resulting in lowered 9647 media quality and potentially shut down of the media stream. 9648 Another attack is to perform a resource exhaustion attack on the 9649 receiver by using many SSRC identifiers to create large state 9650 tables and increase the RTCP related processing demands. 9652 RTP/RTCP Extensions: RTP and RTCP extensions generally provide 9653 additional and sometimes extremely powerful tools to do denial of 9654 service or service disruption. For example the Code Control 9655 Message [RFC5104] RTCP extensions enables both locking down the 9656 bit-rate to low values and disruption of video quality by 9657 requesting Intra frames. 9659 Taking into account the above general discussion in Section 21.2 and 9660 the RTP specific discussion in this section it is clear that it is 9661 necessary that a strong security mechanism is supported to protect 9662 RTP. Therefore this specification has the following requirements on 9663 RTP security functions for all RTSP agents that handles media streams 9664 and where the media stream transport is done using RTP. 9666 RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] 9667 and thus the SAVP profile. In addition the secure AVP profile 9668 (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is 9669 implemented. This specification requires no additional crypto 9670 transforms or configuration values beyond those > mandatory to 9671 implement in RFC3711, i.e., AES-CM and HMAC-SHA1. The default key- 9672 management mechanism which MUST be implemented is the one defined in 9673 the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY 9674 implementation MUST implement the necessary functions for MIKEY-RSA-R 9675 mode [RFC4738] and in addition the SRTP parameter negotiation 9676 necessary to negotiate the supported SRTP transforms and parameters. 9678 22. IANA Considerations 9680 This section sets up a number of registries for RTSP 2.0 that should 9681 be maintained by IANA. These registries are separate from any 9682 registries existing for RTSP 1.0. For each registry there is a 9683 description of what it is required to contain, what specification is 9684 needed when adding an entry with IANA, and finally the entries that 9685 this document needs to register. See also the Section 2.7 "Extending 9686 RTSP". There is also an IANA registration of three SDP attributes. 9688 Registries or entries in registries which have been made for RTSP 1.0 9689 are not moved to RTSP 2.0. The registries and entries in registries 9690 of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry 9691 in a registry is also required in RTSP 2.0, it MUST follow the 9692 procedure defined below to allocate the registry or entry in a 9693 registry. 9695 The sections describing how to register an item uses some of the 9696 registration policies described in RFC 5226 [RFC5226], namely "First 9697 Come, First Served", "Expert Review, "Specification Required", and 9698 "Standards Action". 9700 RFC-Editor Note: Please replace all occurrences of RFCXXXX with 9701 the RFC number this specification receives when published. 9703 In case a registry requires a contact person, the authors, with 9704 Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are 9705 the contact persons for any entries created by this document. 9707 A registration request to IANA MUST contain the following 9708 information: 9710 o A name of the item to register according to the rules specified by 9711 the intended registry. 9713 o Indication of who has change control over the feature (for 9714 example, IETF, ISO, ITU-T, other international standardization 9715 bodies, a consortium, a particular company or group of companies, 9716 or an individual); 9718 o A reference to a further description, if available, for example 9719 (in decreasing order of preference) an RFC, a published standard, 9720 a published paper, a patent filing, a technical report, documented 9721 source code or a computer manual; 9723 o For proprietary features, contact information (postal and email 9724 address); 9726 22.1. Feature-tags 9728 22.1.1. Description 9730 When a client and server try to determine what part and functionality 9731 of the RTSP specification and any future extensions that its counter 9732 part implements there is need for a namespace. This registry 9733 contains named entries representing certain functionality. 9735 The usage of feature-tags is explained in Section 11 and 9736 Section 13.1. 9738 22.1.2. Registering New Feature-tags with IANA 9740 The registering of feature-tags is done on a first come, first served 9741 basis. 9743 The name of the feature MUST follow these rules: The name may be of 9744 any length, but SHOULD be no more than twenty characters long. The 9745 name MUST NOT contain any spaces, or control characters. The 9746 registration MUST indicate if the feature-tag applies to clients, 9747 servers, or proxies only or any combinations of these. Any 9748 proprietary feature MUST have as the first part of the name a vendor 9749 tag, which identifies the organization. The registry entries consist 9750 of the feature tag, a one paragraph description of what it 9751 represents, its applicability (server, client, proxy, any 9752 combination) and a reference to its specification where applicable. 9754 Examples for a vendor tag describing a proprietary feature are: 9756 vendorA.specfeat01 9758 vendorA.specfeat02 9760 22.1.3. Registered entries 9762 The following feature-tags are defined in this specification and 9763 hereby registered. The change control belongs to the IETF. 9765 play.basic: The implementation for delivery and playback operations 9766 according to the core RTSP specification, as defined in this 9767 memo. Applies for both clients, servers and proxies. See 9768 Section 11.1. 9770 play.scale: Support of scale operations for media playback. Applies 9771 only for servers. See Section 18.46. 9773 play.speed: Support of the speed functionality for media delivery. 9774 Applies only for servers. See Section 18.50. 9776 setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as 9777 discussed in Appendix C.1.6.4. Applies for both client and 9778 servers and any media caching proxy. 9780 This should be represented by IANA as a table with the feature tags, 9781 contact person and their references. 9783 22.2. RTSP Methods 9785 22.2.1. Description 9787 Methods are described in Section 13. Extending the protocol with new 9788 methods allow for totally new functionality. 9790 22.2.2. Registering New Methods with IANA 9792 A new method MUST be registered through an IETF Standards Action. 9793 The reason is that new methods may radically change the protocol's 9794 behavior and purpose. 9796 A specification for a new RTSP method MUST consist of the following 9797 items: 9799 o A method name which follows the ABNF rules for methods. 9801 o A clear specification what a request using the method does and 9802 what responses are expected. Which directions the method is used, 9803 C->S or S->C or both. How the use of headers, if any, modifies 9804 the behavior and effect of the method. 9806 o A list or table specifying which of the IANA registered headers 9807 that are allowed to be used with the method in request or/and 9808 response. The list or table SHOULD follow the format of tables in 9809 Section 18. 9811 o Describe how the method relates to network proxies. 9813 22.2.3. Registered Entries 9815 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 9816 GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, 9817 SET_PARAMETER, and TEARDOWN. The initial table of the registry is 9818 provided below. 9820 Method Directionality Reference 9821 ----------------------------------------------------- 9822 DESCRIBE C->S [RFCXXXX] 9823 GET_PARAMETER C->S, S->C [RFCXXXX] 9824 OPTIONS C->S, S->C [RFCXXXX] 9825 PAUSE C->S [RFCXXXX] 9826 PLAY C->S [RFCXXXX] 9827 PLAY_NOTIFY S->C [RFCXXXX] 9828 REDIRECT S->C [RFCXXXX] 9829 SETUP C->S [RFCXXXX] 9830 SET_PARAMETER C->S, S->C [RFCXXXX] 9831 TEARDOWN C->S, S->C [RFCXXXX] 9833 22.3. RTSP Status Codes 9835 22.3.1. Description 9837 A status code is the three digit number used to convey information in 9838 RTSP response messages, see Section 8. The number space is limited 9839 and care should be taken not to fill the space. 9841 22.3.2. Registering New Status Codes with IANA 9843 A new status code registration follows the policy of IETF Review. 9844 New RTSP functionality requiring Status Codes should first be 9845 registered in the range x50-x99. Only when the range is full should 9846 registrations be done in the x00-x49 range, unless it is to adopt an 9847 HTTP extension also to RTSP. The reason is to enable any HTTP 9848 extension to be adopted to RTSP without needing to renumber any 9849 related status codes. A specification for a new status code MUST 9850 specify the following: 9852 o The registered number. 9854 o A description of what the status code means and the expected 9855 behavior of the sender and receiver of the code. 9857 22.3.3. Registered Entries 9859 RFCXXXX, registers the numbered status code defined in the ABNF entry 9860 "Status-Code" except "extension-code" (that defines the syntax 9861 allowed for future extensions) in Section 20.2.2. 9863 22.4. RTSP Headers 9864 22.4.1. Description 9866 By specifying new headers a method(s) can be enhanced in many 9867 different ways. An unknown header will be ignored by the receiving 9868 agent. If the new header is vital for a certain functionality, a 9869 feature-tag for the functionality can be created and demanded to be 9870 used by the counter-part with the inclusion of a Require header 9871 carrying the feature-tag. 9873 22.4.2. Registering New Headers with IANA 9875 Registrations in the registry can be done following the Expert Review 9876 policy. A specification SHOULD be provided, preferably an IETF RFC 9877 or other Standards Developing Organization specification. The 9878 minimal information in a registration request is the header name and 9879 the contact information. 9881 The specification SHOULD contain the following information: 9883 o The name of the header. 9885 o An ABNF specification of the header syntax. 9887 o A list or table specifying when the header may be used, 9888 encompassing all methods, their request or response, the direction 9889 (C->S or S->C). 9891 o How the header is to be handled by proxies. 9893 o A description of the purpose of the header. 9895 22.4.3. Registered entries 9897 All headers specified in Section 18 in RFCXXXX are to be registered. 9898 The Registry is to include header name and reference. 9900 Furthermore the following legacy RTSP headers defined in other 9901 specifications are registered with header name, reference and 9902 description according to below list. Note: These references may not 9903 fulfill all of the above rules for registrations due to their legacy 9904 status. 9906 o x-wap-profile defined in [TS-26234]. The x-wap-profile request 9907 header contains one or more absolute URLs to the requesting 9908 agent's device capability profile. 9910 o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff 9911 request header contains a subset of a device capability profile. 9913 o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- 9914 warning is a response header that contains error codes explaining 9915 to what extent the server has been able to match the terminal 9916 request in regards to device capability profile as described using 9917 x-wap-profile and x-wap-profile-diff headers. 9919 o x-predecbufsize defined in [TS-26234]. This response header 9920 provides an RTSP agent with the TS 26.234 Annex G hypothetical 9921 pre-decoder buffer size. 9923 o x-initpredecbufperiod defined in [TS-26234]. This response header 9924 provides an RTSP agent with the TS 26.234 Annex G hypothetical 9925 pre-decoder buffering period. 9927 o x-initpostdecbufperiod defined in [TS-26234]. This response 9928 header provides an RTSP agent with the TS 26.234 Annex G post- 9929 decoder buffering period. 9931 o 3gpp-videopostdecbufsize defined in [TS-26234]. This response 9932 header provides an RTSP agent with the TS 26.234 defined post- 9933 decoder buffer size usable for H.264 (AVC) video streams. 9935 o 3GPP-Link-Char defined in [TS-26234]. This request header 9936 provides the RTSP server with the RTSP client's link 9937 characteristics as determined from the radio interface. The 9938 information that can be provided are guaranteed bit-rate, maximum 9939 bit-rate and maximum transfer delay. 9941 o 3GPP-Adaptation defined in [TS-26234]. This general header is 9942 part of the bit-rate adaptation solution specified for PSS. It 9943 provides the RTSP client's buffer sizes and target buffer levels 9944 to the server and responses are used to acknowledge the support 9945 and values. 9947 o 3GPP-QoE-Metrics defined in [TS-26234]. This general header is 9948 used by PSS RTSP agents to negotiate the quality of experience 9949 metrics that a client should gather and report to the server. 9951 o 3GPP-QoE-Feedback defined in [TS-26234]. This request header is 9952 used by RTSP clients supporting PSS to report the actual values of 9953 the metrics gathered in its quality of experience metering. 9955 The use of "x-" is NOT RECOMMENDED but the above headers in the 9956 register list were defined prior to the clarification. 9958 22.5. Accept-Credentials 9960 The security framework's TLS connection mechanism has two 9961 registerable entities. 9963 22.5.1. Accept-Credentials policies 9965 In Section 19.3.1 three policies for how to handle certificates are 9966 specified. Further policies may be defined and MUST be registered 9967 with IANA using the following rules: 9969 o Registering requires an IETF Standards Action 9971 o A registration is required to name a contact person. 9973 o Name of the policy. 9975 o A describing text that explains how the policy works for handling 9976 the certificates. 9978 This specification registers the following values: 9980 Any 9982 Proxy 9984 User 9986 22.5.2. Accept-Credentials hash algorithms 9988 The Accept-Credentials header (See Section 18.2) allows for the usage 9989 of other algorithms for hashing the DER records of accepted entities. 9990 The registration of any future algorithm is expected to be extremely 9991 rare and could also cause interoperability problems. Therefore the 9992 bar for registering new algorithms is intentionally placed high. 9994 Any registration of a new hash algorithm MUST fulfill the following 9995 requirement: 9997 o Follow the IETF Standards Action policy. 9999 o A definition of the algorithm and its identifier meeting the 10000 "token" ABNF requirement. 10002 The registered value is: 10003 Hash Alg. Id Reference 10004 ------------------------ 10005 sha-256 [RFCXXXX] 10007 22.6. Cache-Control Cache Directive Extensions 10009 There exists a number of cache directives which can be sent in the 10010 Cache-Control header. A registry for these cache directives MUST be 10011 defined with the following rules: 10013 o Registering requires an IETF Standards Action or IESG Approval. 10015 o A registration is required to contain a contact person. 10017 o Name of the directive and a definition of the value, if any. 10019 o Specification if it is a request or response directive. 10021 o A describing text that explains how the cache directive is used 10022 for RTSP controlled media streams. 10024 This specification registers the following values: 10026 no-cache: 10028 public: 10030 private: 10032 no-transform: 10034 only-if-cached: 10036 max-stale: 10038 min-fresh: 10040 must-revalidate: 10042 proxy-revalidate: 10044 max-age: 10046 The registry should be represented as: Name of the directive, contact 10047 person and reference. 10049 22.7. Media Properties 10050 22.7.1. Description 10052 The media streams being controlled by RTSP can have many different 10053 properties. The media properties required to cover the use cases 10054 that were in mind when writing the specification are defined. 10055 However, it can be expected that further innovation will result in 10056 new use cases or media streams with properties not covered by the 10057 ones specified here. Thus new media properties can be specified. As 10058 new media properties may need a substantial amount of new definitions 10059 to correctly specify behavior for this property the bar is intended 10060 to be high. 10062 22.7.2. Registration Rules 10064 Registering a new media property MUST fulfill the following 10065 requirements 10067 o Follow the Specification Required policy and get the approval of 10068 the designated Expert. 10070 o Have an ABNF definition of the media property value name that 10071 meets "media-prop-ext" definition 10073 o Define which media property group it belongs to or define a new 10074 group. 10076 o A Contact Person for the Registration 10078 o Description of all changes to the behavior of the RTSP protocol as 10079 result of these changes. 10081 22.7.3. Registered Values 10083 This specification registers the ten values listed in Section 18.29. 10084 The registry should be represented as: Name of the media property, 10085 property group, contact person and reference. 10087 22.8. Notify-Reason header 10089 22.8.1. Description 10091 Notify-Reason values are used for indicating the reason the 10092 notification was sent. Each reason has its associated rules on what 10093 headers and information that may or must be included in the 10094 notification. New notification behaviors need to be specified to 10095 enable interoperable usage, thus a specification of each new value is 10096 required. 10098 22.8.2. Registration Rules 10100 Registrations for new Notify-Reason value MUST fulfill the following 10101 requirements 10103 o Follow the Specification Required policy and get the approval of 10104 the designated Expert. 10106 o An ABNF definition of the Notify reason value name that meets 10107 "Notify-Reason-extension" definition 10109 o A Contact Person for the Registration 10111 o Description of which headers shall be included in the request and 10112 response, when it should be sent, and any effect it has on the 10113 server client state. 10115 22.8.3. Registered Values 10117 This specification registers 3 values defined in the Notify-Reas-val 10118 ABNF, Section 20.2.3: 10120 end-of-stream: This Notify-Reason value indicates the end of a media 10121 stream. 10123 media-properties-update: This Notify-Reason value allows the server 10124 to indicate that the properties of the media has changed during 10125 the playout. 10127 scale-change: This Notify-Reason value allows the server to notify 10128 the client about a change in the Scale of the media. 10130 The registry entries should be represented in the registry as: Name, 10131 short description, contact and reference. 10133 22.9. Range Header Formats 10135 22.9.1. Description 10137 The Range header (Section 18.40) allows for different range formats. 10138 These range formats also needs an identifier to be used the Accept- 10139 Ranges header (Section 18.5). New range formats may be registered, 10140 but moderation should be applied as it makes interoperability more 10141 difficult. 10143 22.9.2. Registration Rules 10145 A registration MUST fulfill the following requirements: 10147 o Follow the Specification Required policy. 10149 o An ABNF definition of the range format that fulfills the "range- 10150 ext" definition. 10152 o Define the range format identifier used in Accept-Ranges header 10153 according to the "extension-format" definition. 10155 o A Contact person for the registration. 10157 o Rules for how one handles the range when using a negative Scale. 10159 22.9.3. Registered Values 10161 The registry should be represented as: Range header format 10162 identifier, Name of the range format, contact person and reference. 10163 This specification registers the following values. 10165 npt: Normal Play Time 10167 clock: UTC Absolute Time format 10169 smpte: SMPTE Timestamps 10171 smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop) 10173 smpte-25: SMPTE Timestamps 25 Frames/sec 10175 22.10. Terminate-Reason Header 10177 The Terminate-Reason header (Section 18.52) has two registries for 10178 extensions. 10180 22.10.1. Redirect Reasons 10182 Registrations are done under the policy of Expert Review. The 10183 registered value needs to follow the Terminate-Reason ABNF, i.e., be 10184 a token. The specification needs to provide a definition of what 10185 procedures are to be followed when a client receives this redirect 10186 reason. This specification registers three values: 10188 o Session-Timeout 10189 o Server-Admin 10191 o Internal-Error 10193 The registry should be represented as: Name of the Redirect Reason, 10194 contact person and reference. 10196 22.10.2. Terminate-Reason Header Parameters 10198 Registrations are done under the policy of Specification Required. 10199 The registrations must define a syntax for the parameter that also 10200 follows the syntax allowed by the RTSP 2.0 specification. A contact 10201 person is also required. This specification registers: 10203 o time 10205 o user-msg 10207 The registry should be represented as: Name of the Terminate Reason, 10208 contact person and reference. 10210 22.11. RTP-Info header parameters 10212 22.11.1. Description 10214 The RTP-Info header (Section 18.45) carries one or more parameter 10215 value pairs with information about a particular point in the RTP 10216 stream. RTP extensions or new usages may need new types of 10217 information. As RTP information that could be needed is likely to be 10218 generic enough and to maximize the interoperability, new registration 10219 requires Specification Required. 10221 22.11.2. Registration Rules 10223 Registrations for new RTP-Info value MUST fulfill the following 10224 requirements 10226 o Follow the Specification Required policy and get the approval of 10227 the designated Expert. 10229 o Have an ABNF definition that meets the "generic-param" definition 10231 o A Contact Person for the Registration 10233 22.11.3. Registered Values 10235 This specification registers the following parameter value pairs: 10237 o url 10239 o ssrc 10241 o seq 10243 o rtptime 10245 The registry should be represented as: Name of the parameter, contact 10246 person and reference. 10248 22.12. Seek-Style Policies 10250 22.12.1. Description 10252 New seek policies may be registered, however, a large number of these 10253 will complicate implementation substantially. The impact of unknown 10254 policies is that the server will not honor the unknown and use the 10255 server default policy instead. 10257 22.12.2. Registration Rules 10259 Registrations of new Seek-Style polices MUST fulfill the following 10260 requirements 10262 o Follow the Specification Required policy. 10264 o Have an ABNF definition of the Seek-Style policy name that meets 10265 "Seek-S-value-ext" definition 10267 o A Contact Person for the Registration 10269 o Description of which headers shall be included in the request and 10270 response, when it should be sent, and any affect it has on the 10271 server client state. 10273 22.12.3. Registered Values 10275 This specification registers 4 values: 10277 o RAP 10279 o CoRAP 10280 o First-Prior 10282 o Next 10284 The registry should be represented as: Name of the Seek-Style Policy, 10285 short description, contact person and reference. 10287 22.13. Transport Header Registries 10289 The transport header (Section 18.54) contains a number of parameters 10290 which have possibilities for future extensions. Therefore registries 10291 for these need to be defined. 10293 22.13.1. Transport Protocol Identifier 10295 A Transport Protocol Specification consists of a Transport Protocol 10296 Identifier, representing some combination of transport protocols, and 10297 any number of transport header parameters required or optional to use 10298 with the identified protocol specification. This registry contains 10299 the identifiers used by registered Transport Protocol Identifiers. 10301 A registry for the parameter transport protocol identifier MUST be 10302 defined with the following rules: 10304 o Registering uses the policy of Specification Required. 10306 o A contact person or organization with address and email. 10308 o A value definition that are following the ABNF syntax definition 10309 of "transport-id" Section 20.2.3. 10311 o A describing text that explains how the registered value are used 10312 in RTSP, which underlying transport protocols that are used, and 10313 any required Transport header parameters. 10315 The registry should be represented as: The protocol ID string, 10316 contact person and reference. 10318 This specification registers the following values: 10320 RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in 10321 combination with the "RTP profile for audio and video 10322 conferences with minimal control" [RFC3551] over UDP. The 10323 usage is explained in RFC XXXX, Appendix C.1. 10325 RTP/AVP/UDP: the same as RTP/AVP. 10327 RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in 10328 combination with the "Extended RTP Profile for RTCP-based 10329 Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is 10330 explained in RFC XXXX, Appendix C.1. 10332 RTP/AVPF/UDP: the same as RTP/AVPF. 10334 RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in 10335 combination with the "The Secure Real-time Transport Protocol 10336 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 10337 XXXX, Appendix C.1. 10339 RTP/SAVP/UDP: the same as RTP/SAVP. 10341 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 10342 combination with the Extended Secure RTP Profile for Real-time 10343 Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 10344 [RFC5124] over UDP. The usage is explained in RFC XXXX, 10345 Appendix C.1. 10347 RTP/SAVPF/UDP: the same as RTP/SAVPF. 10349 RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10350 in combination with the "RTP profile for audio and video 10351 conferences with minimal control" [RFC3551] over TCP. The 10352 usage is explained in RFC XXXX, Appendix C.2.2. 10354 RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10355 in combination with the "Extended RTP Profile for RTCP-based 10356 Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is 10357 explained in RFC XXXX, Appendix C.2.2. 10359 RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10360 in combination with the "The Secure Real-time Transport 10361 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 10362 RFC XXXX, Appendix C.2.2. 10364 RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10365 in combination with the "Extended Secure RTP Profile for Real- 10366 time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 10367 SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 10368 XXXX, Appendix C.2.2. 10370 22.13.2. Transport modes 10372 The Transport Mode is a Transport header (Section 18.54) parameter, 10373 it is used to identify the general mode of media transport. The PLAY 10374 value registered defines a PLAYBACK mode, where media flows from 10375 Server to Client. 10377 A registry for the transport parameter mode MUST be defined with the 10378 following rules: 10380 o Registering requires an IETF Standards Action. 10382 o A contact person or organization with address and email. 10384 o A value definition that are following the ABNF "token" definition 10385 Section 20.2.3. 10387 o A describing text that explains how the registered value are used 10388 in RTSP. 10390 This specification registers 1 value: 10392 PLAY: See RFC XXXX. 10394 The registry should be represented as: The Transport Mode value, 10395 contact person and reference. 10397 22.13.3. Transport Parameters 10399 Transport Parameters are different parameters used in a Transport 10400 Header's transport specification (Section 18.54) to provide 10401 additional information required beyond the transport protocol 10402 identifier to establish a functioning transport. 10404 A registry for parameters that may be included in the Transport 10405 header MUST be defined with the following rules: 10407 o Registering uses the Specification Required policy. 10409 o A Transport Parameter Name following the "token" ABNF definition. 10411 o A value definition, if the parameter takes a value, that are 10412 following the ABNF definition "trn-par-value" Section 20.2.3. 10414 o A describing text that explains how the registered value are used 10415 in RTSP. 10417 This specification registers all the transport parameters defined in 10418 Section 18.54. This is a copy of this list: 10420 o unicast 10422 o multicast 10424 o interleaved 10426 o ttl 10428 o layers 10430 o ssrc 10432 o mode 10434 o dest_addr 10436 o src_addr 10438 o setup 10440 o connection 10442 o RTCP-mux 10444 o MIKEY 10446 The registry should be represented as: The transport parameter name, 10447 contact person and reference. 10449 22.14. URI Schemes 10451 This specification updates two URI schemes, one previously registered 10452 "rtsp", and one missing in the registry "rtspu", previously only 10453 defined in the RTSP 1.0 [RFC2326], one new URI scheme "rtsps" is also 10454 registered. These URI schemes are registered in an existing registry 10455 (Uniform Resource Identifier (URI) Schemes) which are not created by 10456 this memo. Registrations are following RFC 4395[RFC4395]. 10458 22.14.1. The rtsp URI Scheme 10460 URI scheme name: rtsp 10462 Status: Permanent 10463 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10465 URI scheme semantics: The rtsp scheme is used to indicate resources 10466 accessible through the usage of the Real-time Streaming 10467 Protocol (RTSP). RTSP allows different operations on the 10468 resource identified by the URI, but the primary purpose is the 10469 streaming delivery of the resource to a client. However, the 10470 operations that are currently defined are: DESCRIBE, 10471 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10472 SETUP, SET_PARAMETER, and TEARDOWN. 10474 Encoding considerations: IRIs in this scheme are defined and needs 10475 to be encoded as RTSP URIs when used within the RTSP protocol. 10476 That encoding is done according to RFC 3987. 10478 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10479 2326), RTSP 2.0 (RFC XXXX) 10481 Interoperability considerations: The extensions in the URI syntax 10482 performed between RTSP 1.0 and 2.0 can create interoperability 10483 issues. The changes are: 10485 Support for IPV6 literal in host part and future IP 10486 literals through RFC 3986 defined mechanism. 10488 A new relative format to use in the RTSP protocol 10489 elements that is not required to start with "/". 10491 The above changes should have no impact on interoperability as 10492 in detail discussed in Section 4.2 of RFCXXXX. 10494 Security considerations: All the security threats identified in 10495 Section 7 of RFC 3986 apply also to this scheme. They need to 10496 be reviewed and considered in any implementation utilizing this 10497 scheme. 10499 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10501 Author/Change controller: IETF 10503 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10505 22.14.2. The rtsps URI Scheme 10506 URI scheme name: rtsps 10508 Status: Permanent 10510 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10512 URI scheme semantics: The rtsps scheme is used to indicate resources 10513 accessible through the usage of the Real-time Streaming 10514 Protocol (RTSP) over TLS. RTSP allows different operations on 10515 the resource identified by the URI, but the primary purpose is 10516 the streaming delivery of the resource to a client. However, 10517 the operations that are currently defined are: DESCRIBE, 10518 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10519 SETUP, SET_PARAMETER, and TEARDOWN. 10521 Encoding considerations: IRIs in this scheme are defined and needs 10522 to be encoded as RTSP URIs when used within the RTSP protocol. 10523 That encoding is done according to RFC 3987. 10525 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10526 2326), RTSP 2.0 (RFC XXXX) 10528 Interoperability considerations: The "rtsps" scheme was never 10529 officially defined for RTSP 1.0, however it has seen widespread 10530 use in actual deployments of RTSP 1.0. Therefore this section 10531 discusses the believed changes between the unspecified RTSP 1.0 10532 "rtsps" scheme and RTSP 2.0 definition. The extensions in the 10533 URI syntax performed between RTSP 1.0 and 2.0 can create 10534 interoperability issues. The changes are: 10536 Support for IPV6 literal in host part and future IP 10537 literals through RFC 3986 defined mechanism. 10539 A new relative format to use in the RTSP protocol 10540 elements that is not required to start with "/". 10542 The above changes should have no impact on interoperability as 10543 in detail discussed in Section 4.2 of RFCXXXX. 10545 Security considerations: All the security threats identified in 10546 Section 7 of RFC 3986 apply also to this scheme. They need to 10547 be reviewed and considered in any implementation utilizing this 10548 scheme. 10550 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10551 Author/Change controller: IETF 10553 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10555 22.14.3. The rtspu URI Scheme 10557 URI scheme name: rtspu 10559 Status: Permanent 10561 URI scheme syntax: See Section 3.2 of RFC 2326. 10563 URI scheme semantics: The rtspu scheme is used to indicate resources 10564 accessible through the usage of the Real-time Streaming 10565 Protocol (RTSP) over unreliable datagram transport. RTSP 10566 allows different operations on the resource identified by the 10567 URI, but the primary purpose is the streaming delivery of the 10568 resource to a client. However, the operations that are 10569 currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, 10570 REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and 10571 TEARDOWN. 10573 Encoding considerations: This scheme is not intended to be used with 10574 characters outside the US-ASCII repertoire. 10576 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10577 2326) 10579 Interoperability considerations: The definition of the transport 10580 mechanism of RTSP over UDP has interoperability issues. That 10581 makes the usage of this scheme problematic. 10583 Security considerations: All the security threats identified in 10584 Section 7 of RFC 3986 apply also to this scheme. They needs to 10585 be reviewed and considered in any implementation utilizing this 10586 scheme. 10588 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10590 Author/Change controller: IETF 10592 References: RFC 2326 10594 22.15. SDP attributes 10596 This specification defines three SDP [RFC4566] attributes that it is 10597 requested that IANA register. 10599 SDP Attribute ("att-field"): 10601 Attribute name: range 10602 Long form: Media Range Attribute 10603 Type of name: att-field 10604 Type of attribute: Media and session level 10605 Subject to charset: No 10606 Purpose: RFC XXXX 10607 Reference: RFC XXXX, RFC 2326 10608 Values: See ABNF definition. 10610 Attribute name: control 10611 Long form: RTSP control URI 10612 Type of name: att-field 10613 Type of attribute: Media and session level 10614 Subject to charset: No 10615 Purpose: RFC XXXX 10616 Reference: RFC XXXX, RFC 2326 10617 Values: Absolute or Relative URIs. 10619 Attribute name: mtag 10620 Long form: Message Tag 10621 Type of name: att-field 10622 Type of attribute: Media and session level 10623 Subject to charset: No 10624 Purpose: RFC XXXX 10625 Reference: RFC XXXX 10626 Values: See ABNF definition 10628 22.16. Media Type Registration for text/parameters 10630 Type name: text 10632 Subtype name: parameters 10634 Required parameters: 10636 Optional parameters: charset: The charset parameter is applicable to 10637 the encoding of the parameter values. The default charset is 10638 UTF-8, if the 'charset' parameter is not present. 10640 Encoding considerations: 8bit 10642 Security considerations: This format may carry any type of 10643 parameters. Some can have security requirements, like privacy, 10644 confidentiality or integrity requirements. The format has no 10645 built in security protection. For the usage it was defined the 10646 transport can be protected between server and client using TLS. 10647 However, care must be taken to consider if also the proxies are 10648 trusted with the parameters in case hop-by-hop security is used. 10649 If stored as a file in file system, the necessary precautions need 10650 to be taken in relation to the parameters requirements including 10651 object security such as S/MIME [RFC5751]. 10653 Interoperability considerations: This media type was mentioned as a 10654 fictional example in [RFC2326], but was not formally specified. 10655 This has resulted in usage of this media type which may not match 10656 its formal definition. 10658 Published specification: RFC XXXX, Appendix F. 10660 Applications that use this media type: Applications that use RTSP 10661 and have additional parameters they like to read and set using the 10662 RTSP GET_PARAMETER and SET_PARAMETER methods. 10664 Additional information: 10666 Magic number(s): 10668 File extension(s): 10670 Macintosh file type code(s): 10672 Person & email address to contact for further information: Magnus 10673 Westerlund (magnus.westerlund@ericsson.com) 10675 Intended usage: Common 10677 Restrictions on usage: None 10679 Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 10681 Change controller: IETF 10683 Addition Notes: 10685 23. References 10687 23.1. Normative References 10689 [FIPS-pub-180-2] 10690 National Institute of Standards and Technology (NIST), 10691 "Federal Information Processing Standards Publications 10692 (FIPS PUBS) 180-2: Secure Hash Standard", August 2002. 10694 [I-D.ietf-avtcore-rtp-circuit-breakers] 10695 Perkins, C. and V. Singh, "Multimedia Congestion Control: 10696 Circuit Breakers for Unicast RTP Sessions", 10697 draft-ietf-avtcore-rtp-circuit-breakers-03 (work in 10698 progress), July 2013. 10700 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 10701 August 1980. 10703 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 10704 RFC 793, September 1981. 10706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10707 Requirement Levels", BCP 14, RFC 2119, March 1997. 10709 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 10710 (IPv6) Specification", RFC 2460, December 1998. 10712 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 10713 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 10714 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 10716 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 10717 Leach, P., Luotonen, A., and L. Stewart, "HTTP 10718 Authentication: Basic and Digest Access Authentication", 10719 RFC 2617, June 1999. 10721 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 10723 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 10724 Jacobson, "RTP: A Transport Protocol for Real-Time 10725 Applications", STD 64, RFC 3550, July 2003. 10727 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 10728 Video Conferences with Minimal Control", STD 65, RFC 3551, 10729 July 2003. 10731 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10732 10646", STD 63, RFC 3629, November 2003. 10734 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 10735 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 10736 RFC 3711, March 2004. 10738 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 10739 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 10740 August 2004. 10742 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 10743 Resource Identifier (URI): Generic Syntax", STD 66, 10744 RFC 3986, January 2005. 10746 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 10747 Identifiers (IRIs)", RFC 3987, January 2005. 10749 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 10750 Requirements for Security", BCP 106, RFC 4086, June 2005. 10752 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10753 Architecture", RFC 4291, February 2006. 10755 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 10756 Registration Procedures for New URI Schemes", BCP 35, 10757 RFC 4395, February 2006. 10759 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 10760 Description Protocol", RFC 4566, July 2006. 10762 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 10763 and RTP Control Protocol (RTCP) Packets over Connection- 10764 Oriented Transport", RFC 4571, July 2006. 10766 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 10767 "Extended RTP Profile for Real-time Transport Control 10768 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 10769 July 2006. 10771 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 10772 Encodings", RFC 4648, October 2006. 10774 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 10775 RSA-R: An Additional Mode of Key Distribution in 10776 Multimedia Internet KEYing (MIKEY)", RFC 4738, 10777 November 2006. 10779 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 10780 Real-time Transport Control Protocol (RTCP)-Based Feedback 10781 (RTP/SAVPF)", RFC 5124, February 2008. 10783 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 10784 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 10785 May 2008. 10787 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 10788 Specifications: ABNF", STD 68, RFC 5234, January 2008. 10790 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 10791 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 10793 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 10794 Housley, R., and W. Polk, "Internet X.509 Public Key 10795 Infrastructure Certificate and Certificate Revocation List 10796 (CRL) Profile", RFC 5280, May 2008. 10798 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 10799 Languages", BCP 47, RFC 5646, September 2009. 10801 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 10802 Mail Extensions (S/MIME) Version 3.2 Message 10803 Specification", RFC 5751, January 2010. 10805 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 10806 Control Packets on a Single Port", RFC 5761, April 2010. 10808 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 10809 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 10811 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 10812 Specifications and Registration Procedures", BCP 13, 10813 RFC 6838, January 2013. 10815 [SMPTE_TC] 10816 Society of Motion Picture and Television Engineers, "SMPTE 10817 Standard for Television -- Time and Control Code, ST 12M- 10818 1-2008". 10820 [TS-26234] 10821 Third Generation Partnership Project (3GPP), "Transparent 10822 end-to-end Packet-switched Streaming Service (PSS); 10823 Protocols and codecs; Technical Specification 26.234", 10824 December 2002. 10826 23.2. Informative References 10828 [I-D.ietf-mmusic-rtsp-nat] 10829 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 10830 Address Translator (NAT) Traversal mechanism for media 10831 controlled by Real-Time Streaming Protocol (RTSP)", 10832 draft-ietf-mmusic-rtsp-nat-16 (work in progress), 10833 May 2013. 10835 [ISO.13818-6.1995] 10836 International Organization for Standardization, 10837 "Information technology - Generic coding of moving 10838 pictures and associated audio information - part 6: 10839 Extension for digital storage media and control", 10840 ISO Draft Standard 13818-6, November 1995. 10842 [ISO.8601.2000] 10843 International Organization for Standardization, "Data 10844 elements and interchange formats - Information interchange 10845 - Representation of dates and times", ISO/IEC Standard 10846 8601, December 2000. 10848 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 10849 and Support", STD 3, RFC 1123, October 1989. 10851 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 10852 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 10853 RFC 2068, January 1997. 10855 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 10856 Streaming Protocol (RTSP)", RFC 2326, April 1998. 10858 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 10859 Translator (NAT) Terminology and Considerations", 10860 RFC 2663, August 1999. 10862 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 10863 April 2001. 10865 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 10866 Announcement Protocol", RFC 2974, October 2000. 10868 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 10869 A., Peterson, J., Sparks, R., Handley, M., and E. 10870 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 10871 June 2002. 10873 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 10874 with Session Description Protocol (SDP)", RFC 3264, 10875 June 2002. 10877 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 10878 the Session Description Protocol (SDP)", RFC 4145, 10879 September 2005. 10881 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 10882 Carrara, "Key Management Extensions for Session 10883 Description Protocol (SDP) and Real Time Streaming 10884 Protocol (RTSP)", RFC 4567, July 2006. 10886 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 10887 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 10888 July 2006. 10890 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 10891 Formats", RFC 4855, February 2007. 10893 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 10894 the RTP Profile for Audio and Video Conferences", 10895 RFC 4856, February 2007. 10897 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 10898 "Codec Control Messages in the RTP Audio-Visual Profile 10899 with Feedback (AVPF)", RFC 5104, February 2008. 10901 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 10902 (ICE): A Protocol for Network Address Translator (NAT) 10903 Traversal for Offer/Answer Protocols", RFC 5245, 10904 April 2010. 10906 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 10907 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 10908 October 2008. 10910 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 10911 Dependency in the Session Description Protocol (SDP)", 10912 RFC 5583, July 2009. 10914 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 10915 Time Protocol Version 4: Protocol and Algorithms 10916 Specification", RFC 5905, June 2010. 10918 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 10919 "Computing TCP's Retransmission Timer", RFC 6298, 10920 June 2011. 10922 [Stevens98] 10923 Stevens, W., "Unix Networking Programming - Volume 1, 10924 second edition", 1998. 10926 Appendix A. Examples 10928 This section contains several different examples trying to illustrate 10929 possible ways of using RTSP. The examples can also help with the 10930 understanding of how functions of RTSP work. However, remember that 10931 these are examples and the normative and syntax description in the 10932 other sections take precedence. Please also note that many of the 10933 examples contain syntax illegal line breaks to accommodate the 10934 formatting restriction that the RFC series impose. 10936 A.1. Media on Demand (Unicast) 10938 This is an example of media on demand streaming of a media stored in 10939 a container file. For purposes of this example, a container file is 10940 a storage entity in which multiple continuous media types pertaining 10941 to the same end-user presentation are present. In effect, the 10942 container file represents an RTSP presentation, with each of its 10943 components being RTSP controlled media streams. Container files are 10944 a widely used means to store such presentations. While the 10945 components are transported as independent streams, it is desirable to 10946 maintain a common context for those streams at the server end. 10948 This enables the server to keep a single storage handle open 10949 easily. It also allows treating all the streams equally in case 10950 of any prioritization of streams by the server. 10952 It is also possible that the presentation author may wish to prevent 10953 selective retrieval of the streams by the client in order to preserve 10954 the artistic effect of the combined media presentation. Similarly, 10955 in such a tightly bound presentation, it is desirable to be able to 10956 control all the streams via a single control message using an 10957 aggregate URI. 10959 The following is an example of using a single RTSP session to control 10960 multiple streams. It also illustrates the use of aggregate URIs. In 10961 a container file it is also desirable to not write any URI parts 10962 which are not kept, when the container is distributed, like the host 10963 and most of the path element. Therefore this example also uses the 10964 "*" and relative URI in the delivered SDP. 10966 Also this presentation description (SDP) is not cacheble, as the 10967 Expires header is set to an equal value with date indicating 10968 immediate expiration of its validity. 10970 Client C requests a presentation from media server M. The movie is 10971 stored in a container file. The client has obtained an RTSP URI to 10972 the container file. 10974 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 10975 CSeq: 1 10976 User-Agent: PhonyClient/1.2 10978 M->C: RTSP/2.0 200 OK 10979 CSeq: 1 10980 Server: PhonyServer/1.0 10981 Date: Thu, 24 Jan 1997 15:35:06 GMT 10982 Content-Type: application/sdp 10983 Content-Length: 271 10984 Content-Base: rtsp://example.com/twister.3gp/ 10985 Expires: 24 Jan 1997 15:35:06 GMT 10987 v=0 10988 o=- 2890844256 2890842807 IN IP4 198.51.100.5 10989 s=RTSP Session 10990 i=An Example of RTSP Session Usage 10991 e=adm@example.com 10992 c=IN IP4 0.0.0.0 10993 a=control: * 10994 a=range:npt=0-0:10:34.10 10995 t=0 0 10996 m=audio 0 RTP/AVP 0 10997 a=control: trackID=1 10998 m=video 0 RTP/AVP 26 10999 a=control: trackID=4 11001 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11002 CSeq: 2 11003 User-Agent: PhonyClient/1.2 11004 Require: play.basic 11005 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11006 Accept-Ranges: npt, smpte, clock 11008 M->C: RTSP/2.0 200 OK 11009 CSeq: 2 11010 Server: PhonyServer/1.0 11011 Transport: RTP/AVP;unicast; ssrc=93CB001E; 11012 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11013 src_addr="198.51.100.5:9000"/"198.51.100.5:9001" 11014 Session: 12345678 11015 Expires: 24 Jan 1997 15:35:12 GMT 11016 Date: 24 Jan 1997 15:35:12 GMT 11017 Accept-Ranges: npt 11018 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11020 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11021 CSeq: 3 11022 User-Agent: PhonyClient/1.2 11023 Require: play.basic 11024 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11025 Session: 12345678 11026 Accept-Ranges: npt, smpte, clock 11028 M->C: RTSP/2.0 200 OK 11029 CSeq: 3 11030 Server: PhonyServer/1.0 11031 Transport: RTP/AVP;unicast; ssrc=A813FC13; 11032 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 11033 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11035 Session: 12345678 11036 Expires: 24 Jan 1997 15:35:13 GMT 11037 Date: 24 Jan 1997 15:35:13 GMT 11038 Accept-Range: NPT 11039 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11041 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11042 CSeq: 4 11043 User-Agent: PhonyClient/1.2 11044 Range: npt=30- 11045 Seek-Style: RAP 11046 Session: 12345678 11048 M->C: RTSP/2.0 200 OK 11049 CSeq: 4 11050 Server: PhonyServer/1.0 11051 Date: 24 Jan 1997 15:35:14 GMT 11052 Session: 12345678 11053 Range: npt=30-634.10 11054 Seek-Style: RAP 11055 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11056 ssrc=0D12F123:seq=12345;rtptime=3450012, 11057 url="rtsp://example.com/twister.3gp/trackID=1" 11058 ssrc=4F312DD8:seq=54321;rtptime=2876889 11060 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 11061 CSeq: 5 11062 User-Agent: PhonyClient/1.2 11063 Session: 12345678 11065 # Pause happens 0.87 seconds after starting to play 11067 M->C: RTSP/2.0 200 OK 11068 CSeq: 5 11069 Server: PhonyServer/1.0 11070 Date: 24 Jan 1997 15:36:01 GMT 11071 Session: 12345678 11072 Range: npt=30.87-634.10 11074 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11075 CSeq: 6 11076 User-Agent: PhonyClient/1.2 11077 Range: npt=30.87-634.10 11078 Seek-Style: Next 11079 Session: 12345678 11081 M->C: RTSP/2.0 200 OK 11082 CSeq: 6 11083 Server: PhonyServer/1.0 11084 Date: 24 Jan 1997 15:36:01 GMT 11085 Session: 12345678 11086 Range: npt=30.87-634.10 11087 Seek-Style: Next 11088 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11089 ssrc=0D12F123:seq=12555;rtptime=6330012, 11090 url="rtsp://example.com/twister.3gp/trackID=1" 11091 ssrc=4F312DD8:seq=55021;rtptime=3132889 11093 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 11094 CSeq: 7 11095 User-Agent: PhonyClient/1.2 11096 Session: 12345678 11098 M->C: RTSP/2.0 200 OK 11099 CSeq: 7 11100 Server: PhonyServer/1.0 11101 Date: 24 Jan 1997 15:49:34 GMT 11103 A.2. Media on Demand using Pipelining 11105 This example is basically the example above (Appendix A.1), but now 11106 utilizing pipelining to speed up the setup. It requires only two 11107 round trip times until the media starts flowing. First of all, the 11108 session description is retrieved to determine what media resources 11109 need to be setup. In the second step, one sends the necessary SETUP 11110 requests and the PLAY request to initiate media delivery. 11112 Client C requests a presentation from media server M. The movie is 11113 stored in a container file. The client has obtained an RTSP URI to 11114 the container file. 11116 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11117 CSeq: 1 11118 User-Agent: PhonyClient/1.2 11120 M->C: RTSP/2.0 200 OK 11121 CSeq: 1 11122 Server: PhonyServer/1.0 11123 Date: Thu, 23 Jan 1997 15:35:06 GMT 11124 Content-Type: application/sdp 11125 Content-Length: 271 11126 Content-Base: rtsp://example.com/twister.3gp/ 11127 Expires: 24 Jan 1997 15:35:06 GMT 11129 v=0 11130 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11131 s=RTSP Session 11132 i=An Example of RTSP Session Usage 11133 e=adm@example.com 11134 c=IN IP4 0.0.0.0 11135 a=control: * 11136 a=range:npt=0-0:10:34.10 11137 t=0 0 11138 m=audio 0 RTP/AVP 0 11139 a=control: trackID=1 11140 m=video 0 RTP/AVP 26 11141 a=control: trackID=4 11143 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11144 CSeq: 2 11145 User-Agent: PhonyClient/1.2 11146 Require: play.basic 11147 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11148 Accept-Ranges: npt, smpte, clock 11149 Pipelined-Requests: 7654 11151 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11152 CSeq: 3 11153 User-Agent: PhonyClient/1.2 11154 Require: play.basic 11155 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11156 Accept-Ranges: npt, smpte, clock 11157 Pipelined-Requests: 7654 11159 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11160 CSeq: 4 11161 User-Agent: PhonyClient/1.2 11162 Range: npt=0- 11163 Seek-Style: RAP 11164 Pipelined-Requests: 7654 11166 M->C: RTSP/2.0 200 OK 11167 CSeq: 2 11168 Server: PhonyServer/1.0 11169 Transport: RTP/AVP;unicast; 11170 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11171 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11172 ssrc=93CB001E 11173 Session: 12345678 11174 Expires: 24 Jan 1997 15:35:12 GMT 11175 Date: 23 Jan 1997 15:35:12 GMT 11176 Accept-Ranges: npt 11177 Pipelined-Requests: 7654 11178 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11180 M->C: RTSP/2.0 200 OK 11181 CSeq: 3 11182 Server: PhonyServer/1.0 11183 Transport: RTP/AVP;unicast; 11184 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11185 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11186 ssrc=A813FC13 11187 Session: 12345678 11188 Expires: 24 Jan 1997 15:35:13 GMT 11189 Date: 23 Jan 1997 15:35:13 GMT 11190 Accept-Range: NPT 11191 Pipelined-Requests: 7654 11192 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11194 M->C: RTSP/2.0 200 OK 11195 CSeq: 4 11196 Server: PhonyServer/1.0 11197 Date: 23 Jan 1997 15:35:14 GMT 11198 Session: 12345678 11199 Range: npt=0-623.10 11200 Seek-Style: RAP 11201 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11202 ssrc=0D12F123:seq=12345;rtptime=3450012, 11203 url="rtsp://example.com/twister.3gp/trackID=1" 11204 ssrc=4F312DD8:seq=54321;rtptime=2876889 11205 Pipelined-Requests: 7654 11207 A.3. Secured Media Session for on Demand Content 11209 This example is basically the above example (Appendix A.2), but now 11210 including establishment of SRTP crypto contexts to get a secured 11211 media delivery. First of all, the client attempts to fetch this 11212 insecurely, but the server redirects to a URI indicating a 11213 requirement on using a secure connection for the RTSP messages. The 11214 client establish a TCP/TLS connections and the session description is 11215 retrieved to determine what media resources need to be setup. In the 11216 this session description secure media (SRTP) is indicated. In the 11217 next step, the client sends the necessary SETUP requests including 11218 MIKEY messages. This is pipeline with a PLAY request to initiate 11219 media delivery. 11221 Client C requests a presentation from media server M. The movie is 11222 stored in a container file. The client has obtained an RTSP URI to 11223 the container file. 11225 Note: The below MIKEY messages are not valid MIKEY message and are 11226 BASE64 encoded random data to represent where the MIKEY messages 11227 would go. 11228 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11229 CSeq: 1 11230 User-Agent: PhonyClient/1.2 11232 M->C: RTSP/2.0 301 Moved Permanently 11233 CSeq: 1 11234 Server: PhonyServer/1.0 11235 Date: Thu, 23 Jan 1997 15:35:06 GMT 11236 Location: rtsps://example.com/twister.3gp 11238 C->M: Establish TCP/TLS connection and verify server's 11239 certificate that is represents example.com. 11240 Used for all below RTSP messages. 11242 C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0 11243 CSeq: 2 11244 User-Agent: PhonyClient/1.2 11246 M->C: RTSP/2.0 200 OK 11247 CSeq: 2 11248 Server: PhonyServer/1.0 11249 Date: Thu, 23 Jan 1997 15:35:06 GMT 11250 Content-Type: application/sdp 11251 Content-Length: 271 11252 Content-Base: rtsps://example.com/twister.3gp/ 11253 Expires: 24 Jan 1997 15:35:06 GMT 11255 v=0 11256 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11257 s=RTSP Session 11258 i=An Example of RTSP Session Usage 11259 e=adm@example.com 11260 c=IN IP4 0.0.0.0 11261 a=control: * 11262 a=range:npt=0-0:10:34.10 11263 t=0 0 11264 m=audio 0 RTP/SAVP 0 11265 a=control: trackID=1 11266 m=video 0 RTP/SAVP 26 11267 a=control: trackID=4 11269 C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0 11270 CSeq: 3 11271 User-Agent: PhonyClient/1.2 11272 Require: play.basic 11273 Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001"; 11274 MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl 11275 Accept-Ranges: npt, smpte, clock 11276 Pipelined-Requests: 7654 11278 C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0 11279 CSeq: 4 11280 User-Agent: PhonyClient/1.2 11281 Require: play.basic 11282 Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003"; 11283 MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ= 11284 Accept-Ranges: npt, smpte, clock 11285 Pipelined-Requests: 7654 11287 C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0 11288 CSeq: 5 11289 User-Agent: PhonyClient/1.2 11290 Range: npt=0- 11291 Seek-Style: RAP 11292 Pipelined-Requests: 7654 11294 M->C: RTSP/2.0 200 OK 11295 CSeq: 3 11296 Server: PhonyServer/1.0 11297 Transport: RTP/SAVP;unicast; 11298 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11299 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11300 ssrc=93CB001E; 11301 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x 11302 Session: 12345678 11303 Expires: 24 Jan 1997 15:35:12 GMT 11304 Date: 23 Jan 1997 15:35:12 GMT 11305 Accept-Ranges: npt 11306 Pipelined-Requests: 7654 11307 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11309 M->C: RTSP/2.0 200 OK 11310 CSeq: 4 11311 Server: PhonyServer/1.0 11312 Transport: RTP/SAVP;unicast; 11313 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11314 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11315 ssrc=A813FC13; 11316 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 11317 Session: 12345678 11318 Expires: 24 Jan 1997 15:35:13 GMT 11319 Date: 23 Jan 1997 15:35:13 GMT 11320 Accept-Range: NPT 11321 Pipelined-Requests: 7654 11322 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11324 M->C: RTSP/2.0 200 OK 11325 CSeq: 5 11326 Server: PhonyServer/1.0 11327 Date: 23 Jan 1997 15:35:14 GMT 11328 Session: 12345678 11329 Range: npt=0-623.10 11330 Seek-Style: RAP 11331 RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" 11332 ssrc=0D12F123:seq=12345;rtptime=3450012, 11333 url="rtsps://example.com/twister.3gp/trackID=1" 11334 ssrc=4F312DD8:seq=54321;rtptime=2876889; 11336 Pipelined-Requests: 7654 11338 A.4. Media on Demand (Unicast) 11340 An alternative example of media on demand with a bit more tweaks is 11341 the following. Client C requests a movie distributed from two 11342 different media servers A (audio.example.com) and V ( 11343 video.example.com). The media description is stored on a web server 11344 W. The media description contains descriptions of the presentation 11345 and all its streams, including the codecs that are available, dynamic 11346 RTP payload types, the protocol stack, and content information such 11347 as language or copyright restrictions. It may also give an 11348 indication about the timeline of the movie. 11350 In this example, the client is only interested in the last part of 11351 the movie. 11353 C->W: GET /twister.sdp HTTP/1.1 11354 Host: www.example.com 11355 Accept: application/sdp 11357 W->C: HTTP/1.1 200 OK 11358 Date: Thu, 23 Jan 1997 15:35:06 GMT 11359 Content-Type: application/sdp 11360 Content-Length: 278 11361 Expires: 23 Jan 1998 15:35:06 GMT 11363 v=0 11364 o=- 2890844526 2890842807 IN IP4 198.51.100.5 11365 s=RTSP Session 11366 e=adm@example.com 11367 c=IN IP4 0.0.0.0 11368 a=range:npt=0-1:49:34 11369 t=0 0 11370 m=audio 0 RTP/AVP 0 11371 a=control:rtsp://audio.example.com/twister/audio.en 11372 m=video 0 RTP/AVP 31 11373 a=control:rtsp://video.example.com/twister/video 11375 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 11376 CSeq: 1 11377 User-Agent: PhonyClient/1.2 11378 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 11379 RTP/AVP/TCP;unicast;interleaved=0-1 11380 Accept-Ranges: npt, smpte, clock 11382 A->C: RTSP/2.0 200 OK 11383 CSeq: 1 11384 Session: 12345678 11385 Transport: RTP/AVP/UDP;unicast; 11386 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11387 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11388 Date: 23 Jan 1997 15:35:12 GMT 11389 Server: PhonyServer/1.0 11390 Expires: 24 Jan 1997 15:35:12 GMT 11391 Cache-Control: public 11392 Accept-Ranges: npt, smpte 11393 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11395 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 11396 CSeq: 1 11397 User-Agent: PhonyClient/1.2 11398 Transport: RTP/AVP/UDP;unicast; 11399 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", 11400 RTP/AVP/TCP;unicast;interleaved=0-1 11401 Accept-Ranges: npt, smpte, clock 11403 V->C: RTSP/2.0 200 OK 11404 CSeq: 1 11405 Session: 23456789 11406 Transport: RTP/AVP/UDP;unicast; 11407 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; 11408 src_addr="198.51.100.5:5002"/"198.51.100.5:5003" 11409 Date: 23 Jan 1997 15:35:12 GMT 11410 Server: PhonyServer/1.0 11411 Cache-Control: public 11412 Expires: 24 Jan 1997 15:35:12 GMT 11413 Accept-Ranges: npt, smpte 11414 Media-Properties: Random-Access=1.2, Immutable, Unlimited 11416 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 11417 CSeq: 2 11418 User-Agent: PhonyClient/1.2 11419 Session: 23456789 11420 Range: smpte=0:10:00- 11422 V->C: RTSP/2.0 200 OK 11423 CSeq: 2 11424 Session: 23456789 11425 Range: smpte=0:10:00-1:49:23 11426 Seek-Style: First-Prior 11427 RTP-Info: url="rtsp://video.example.com/twister/video" 11428 ssrc=A17E189D:seq=12312232;rtptime=78712811 11429 Server: PhonyServer/2.0 11430 Date: 23 Jan 1997 15:35:13 GMT 11432 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 11433 CSeq: 2 11434 User-Agent: PhonyClient/1.2 11435 Session: 12345678 11436 Range: smpte=0:10:00- 11438 A->C: RTSP/2.0 200 OK 11439 CSeq: 2 11440 Session: 12345678 11441 Range: smpte=0:10:00-1:49:23 11442 Seek-Style: First-Prior 11443 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 11444 ssrc=3D124F01:seq=876655;rtptime=1032181 11445 Server: PhonyServer/1.0 11446 Date: 23 Jan 1997 15:35:13 GMT 11448 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 11449 CSeq: 3 11450 User-Agent: PhonyClient/1.2 11451 Session: 12345678 11453 A->C: RTSP/2.0 200 OK 11454 CSeq: 3 11455 Server: PhonyServer/1.0 11456 Date: 23 Jan 1997 15:36:52 GMT 11458 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 11459 CSeq: 3 11460 User-Agent: PhonyClient/1.2 11461 Session: 23456789 11463 V->C: RTSP/2.0 200 OK 11464 CSeq: 3 11465 Server: PhonyServer/2.0 11466 Date: 23 Jan 1997 15:36:52 GMT 11468 Even though the audio and video track are on two different servers 11469 that may start at slightly different times and may drift with respect 11470 to each other over time, the client can perform initial 11471 synchronization of the two media using RTP-Info and Range received in 11472 the PLAY responses. If the two servers are time synchronized the 11473 RTCP packets can also be used to maintain synchronization. 11475 A.5. Single Stream Container Files 11477 Some RTSP servers may treat all files as though they are "container 11478 files", yet other servers may not support such a concept. Because of 11479 this, clients needs to use the rules set forth in the session 11480 description for Request-URIs, rather than assuming that a consistent 11481 URI may always be used throughout. Below is an example of how a 11482 multi-stream server might expect a single-stream file to be served: 11484 C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 11485 Accept: application/x-rtsp-mh, application/sdp 11486 CSeq: 1 11487 User-Agent: PhonyClient/1.2 11489 S->C: RTSP/2.0 200 OK 11490 CSeq: 1 11491 Content-base: rtsp://foo.example.com/test.wav/ 11492 Content-type: application/sdp 11493 Content-length: 163 11494 Server: PhonyServer/1.0 11495 Date: Thu, 23 Jan 1997 15:35:06 GMT 11496 Expires: 23 Jan 1997 17:00:00 GMT 11498 v=0 11499 o=- 872653257 872653257 IN IP4 192.0.2.5 11500 s=mu-law wave file 11501 i=audio test 11502 c=IN IP4 0.0.0.0 11503 t=0 0 11504 a=control: * 11505 m=audio 0 RTP/AVP 0 11506 a=control:streamid=0 11508 C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 11509 Transport: RTP/AVP/UDP;unicast; 11510 dest_addr=":6970"/":6971";mode="PLAY" 11511 CSeq: 2 11512 User-Agent: PhonyClient/1.2 11513 Accept-Ranges: npt, smpte, clock 11515 S->C: RTSP/2.0 200 OK 11516 Transport: RTP/AVP/UDP;unicast; 11517 dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; 11518 src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; 11519 mode="PLAY";ssrc=EAB98712 11520 CSeq: 2 11521 Session: 2034820394 11522 Expires: 23 Jan 1997 16:00:00 GMT 11523 Server: PhonyServer/1.0 11524 Date: 23 Jan 1997 15:35:07 GMT 11525 Accept-Ranges: npt 11526 Media-Properties: Random-Acces=0.5, Immutable, Unlimited 11528 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 11529 CSeq: 3 11530 User-Agent: PhonyClient/1.2 11531 Session: 2034820394 11533 S->C: RTSP/2.0 200 OK 11534 CSeq: 3 11535 Server: PhonyServer/1.0 11536 Date: 23 Jan 1997 15:35:08 GMT 11537 Session: 2034820394 11538 Range: npt=0-600 11539 Seek-Style: RAP 11540 RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" 11541 ssrc=0D12F123:seq=981888;rtptime=3781123 11543 Note the different URI in the SETUP command, and then the switch back 11544 to the aggregate URI in the PLAY command. This makes complete sense 11545 when there are multiple streams with aggregate control, but is less 11546 than intuitive in the special case where the number of streams is 11547 one. However, the server has declared the aggregated control URI in 11548 the SDP and therefore this is legal. 11550 In this case, it is also required that servers accept implementations 11551 that use the non-aggregated interpretation and use the individual 11552 media URI, like this: 11554 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 11555 CSeq: 3 11556 User-Agent: PhonyClient/1.2 11557 Session: 2034820394 11559 A.6. Live Media Presentation Using Multicast 11561 The media server M chooses the multicast address and port. Here, it 11562 is assumed that the web server only contains a pointer to the full 11563 description, while the media server M maintains the full description. 11565 C->W: GET /sessions.html HTTP/1.1 11566 Host: www.example.com 11568 W->C: HTTP/1.1 200 OK 11569 Content-Type: text/html 11571 11572 ... 11573 11574 Streamed Live Music performance 11575 ... 11576 11578 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 11579 CSeq: 1 11580 Supported: play.basic, play.scale 11581 User-Agent: PhonyClient/1.2 11583 M->C: RTSP/2.0 200 OK 11584 CSeq: 1 11585 Content-Type: application/sdp 11586 Content-Length: 183 11587 Server: PhonyServer/1.0 11588 Date: Thu, 23 Jan 1997 15:35:06 GMT 11589 Supported: play.basic 11591 v=0 11592 o=- 2890844526 2890842807 IN IP4 192.0.2.5 11593 s=RTSP Session 11594 t=0 0 11595 m=audio 3456 RTP/AVP 0 11596 c=IN IP4 233.252.0.54/16 11597 a=control: rtsp://live.example.com/concert/audio 11598 a=range:npt=0- 11600 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 11601 CSeq: 2 11602 Transport: RTP/AVP;multicast; 11603 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11604 Accept-Ranges: npt, smpte, clock 11605 User-Agent: PhonyClient/1.2 11607 M->C: RTSP/2.0 200 OK 11608 CSeq: 2 11609 Server: PhonyServer/1.0 11610 Date: Thu, 23 Jan 1997 15:35:06 GMT 11611 Transport: RTP/AVP;multicast; 11612 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11613 ;ssrc=4D12AB92/0DF876A3 11614 Session: 0456804596 11615 Accept-Ranges: npt, clock 11616 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 11618 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 11619 CSeq: 3 11620 Session: 0456804596 11621 User-Agent: PhonyClient/1.2 11623 M->C: RTSP/2.0 200 OK 11624 CSeq: 3 11625 Server: PhonyServer/1.0 11626 Date: 23 Jan 1997 15:35:07 GMT 11627 Session: 0456804596 11628 Seek-Style: Next 11629 Range:npt=1256- 11630 RTP-Info: url="rtsp://live.example.com/concert/audio" 11631 ssrc=0D12F123:seq=1473; rtptime=80000 11633 A.7. Capability Negotiation 11635 This example illustrates how the client and server determine their 11636 capability to support a special feature, in this case "play.scale". 11637 The server, through the clients request and the included Supported 11638 header, learns the client supports RTSP 2.0, and also supports the 11639 playback time scaling feature of RTSP. The server's response 11640 contains the following feature related information to the client; it 11641 supports the basic media delivery functions (play.basic), the 11642 extended functionality of time scaling of content (play.scale), and 11643 one "example.com" proprietary feature (com.example.flight). The 11644 client also learns the methods supported (Public header) by the 11645 server for the indicated resource. 11647 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 11648 CSeq: 1 11649 Supported: play.basic, play.scale 11650 User-Agent: PhonyClient/1.2 11652 S->C: RTSP/2.0 200 OK 11653 CSeq: 1 11654 Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER 11655 Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE 11656 Server: PhonyServer/2.0 11657 Supported: play.basic, play.scale, com.example.flight 11659 When the client sends its SETUP request it tells the server that it 11660 requires support of the play.scale feature for this session by 11661 including the Require header. 11663 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 11664 CSeq: 3 11665 User-Agent: PhonyClient/1.2 11666 Transport: RTP/AVP/UDP;unicast; 11667 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", 11668 RTP/AVP/TCP;unicast;interleaved=0-1 11669 Require: play.scale 11670 Accept-Ranges: npt, smpte, clock 11671 User-Agent: PhonyClient/1.2 11673 S->C: RTSP/2.0 200 OK 11674 CSeq: 3 11675 Session: 12345678 11676 Transport: RTP/AVP/UDP;unicast; 11677 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11678 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11679 Server: PhonyServer/2.0 11680 Accept-Ranges: npt, smpte 11681 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11683 Appendix B. RTSP Protocol State Machine 11685 The RTSP session state machine describes the behavior of the protocol 11686 from RTSP session initialization through RTSP session termination. 11687 It is likely easiest to think of this as the server's state and then 11688 the client need to track what it believe the server's state will be 11689 based on sent or received RTSP messages. Thus most cases the below 11690 state tables can be read as: If the client do X, assuming it fulfills 11691 any pre-requisite the state will move to the new state and the 11692 indicated response will come back. However, there are also server to 11693 client notifications or requests, where the action describes what 11694 notification or request that happens, its requisites and what new 11695 state will occur after the server has received the response, and 11696 describing the clients response to the action. 11698 The State machine is defined on a per session basis which is uniquely 11699 identified by the RTSP session identifier. The session may contain 11700 one or more media streams depending on state. If a single media 11701 stream is part of the session it is in non-aggregated control. If 11702 two or more is part of the session it is in aggregated control. 11704 The below state machine is an informative description of the 11705 protocols behavior. In case of ambiguity with the earlier parts of 11706 this specification, the description in the earlier parts take 11707 precedence. 11709 B.1. States 11711 The state machine contains three states, described below. For each 11712 state there exists a table which shows which requests and events are 11713 allowed and whether they will result in a state change. 11715 Init: Initial state no session exists. 11717 Ready: Session is ready to start playing. 11719 Play: Session is playing, i.e., sending media stream data in the 11720 direction S->C. 11722 B.2. State variables 11724 This representation of the state machine needs more than its state to 11725 work. A small number of variables are also needed and they are 11726 explained below. 11728 NRM: The number of media streams part of this session. 11730 RP: Resume point, the point in the presentation time line at which 11731 a request to continue playing will resume from. A time format 11732 for the variable is not mandated. 11734 B.3. Abbreviations 11736 To make the state tables more compact a number of abbreviations are 11737 used, which are explained below. 11739 IFI: IF Implemented. 11741 md: Media 11743 PP: Pause Point, the point in the presentation time line at which 11744 the presentation was paused. 11746 Prs: Presentation, the complete multimedia presentation. 11748 RedP: Redirect Point, the point in the presentation time line at 11749 which a REDIRECT was specified to occur. 11751 SES: Session. 11753 B.4. State Tables 11755 This section contains a table for each state. The table contains all 11756 the requests and events that this state is allowed to act on. The 11757 events which are method names are, unless noted, requests with the 11758 given method in the direction client to server (C->S). In some cases 11759 there exist one or more requisite. The response column tells what 11760 type of response actions should be performed. Possible actions that 11761 are requested for an event include: response codes, e.g., 200, 11762 headers that need to be included in the response, setting of state 11763 variables, or setting of other session related parameters. The new 11764 state column tells which state the state machine changes to. 11766 The response to a valid request meeting the requisites is normally a 11767 2xx (SUCCESS) unless otherwise noted in the response column. The 11768 exceptions need to be given a response according to the response 11769 column. If the request does not meet the requisite, is erroneous or 11770 some other type of error occurs, the appropriate response code is to 11771 be sent. If the response code is a 4xx the session state is 11772 unchanged. A response code of 3rr will result in that the session is 11773 ended and its state is changed to Init. A response code of 304 11774 results in no state change. However, there are restrictions to when 11775 a 3rr response may be used. A 5xx response does not result in any 11776 change of the session state, except if the error is not possible to 11777 recover from. A unrecoverable error results in the ending of the 11778 session. As it in the general case can't be determined if it was a 11779 unrecoverable error or not the client will be required to test. In 11780 the case that the next request after a 5xx is responded with 454 11781 (Session Not Found) the client knows that the session has ended. For 11782 any request message that cannot be responded to within the time 11783 defined in Section 10.4, a 100 response must be sent. 11785 The server will timeout the session after the period of time 11786 specified in the SETUP response, if no activity from the client is 11787 detected. Therefore there exists a timeout event for all states 11788 except Init. 11790 In the case that NRM = 1 the presentation URI is equal to the media 11791 URI or a specified presentation URI. For NRM > 1 the presentation 11792 URI needs to be other than any of the medias that are part of the 11793 session. This applies to all states. 11795 +---------------+-----------------+---------------------------------+ 11796 | Event | Prerequisite | Response | 11797 +---------------+-----------------+---------------------------------+ 11798 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 11799 | | | | 11800 | DESCRIBE | | 200, Session description | 11801 | | | | 11802 | OPTIONS | Session ID | 200, Reset session timeout | 11803 | | | timer | 11804 | | | | 11805 | OPTIONS | | 200 | 11806 | | | | 11807 | SET_PARAMETER | Valid parameter | 200, change value of parameter | 11808 | | | | 11809 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 11810 +---------------+-----------------+---------------------------------+ 11812 Table 13: None state-machine changing events 11814 The methods in Table 13 do not have any effect on the state machine 11815 or the state variables. However, some methods do change other 11816 session related parameters, for example SET_PARAMETER which will set 11817 the parameter(s) specified in its body. Also all of these methods 11818 that allow Session header will also update the keep-alive timer for 11819 the session. 11821 +------------------+----------------+-----------+-------------------+ 11822 | Action | Requisite | New State | Response | 11823 +------------------+----------------+-----------+-------------------+ 11824 | SETUP | | Ready | NRM=1, RP=0.0 | 11825 | | | | | 11826 | SETUP | Needs Redirect | Init | 3rr Redirect | 11827 | | | | | 11828 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 11829 +------------------+----------------+-----------+-------------------+ 11831 Table 14: State: Init 11833 The initial state of the state machine, see Table 14 can only be left 11834 by processing a correct SETUP request. As seen in the table the two 11835 state variables are also set by a correct request. This table also 11836 shows that a correct SETUP can in some cases be redirected to another 11837 URI and/or server by a 3rr response. 11839 +-------------+------------------------+---------+------------------+ 11840 | Action | Requisite | New | Response | 11841 | | | State | | 11842 +-------------+------------------------+---------+------------------+ 11843 | SETUP | New URI | Ready | NRM +=1 | 11844 | | | | | 11845 | SETUP | URI Setup prior | Ready | Change transport | 11846 | | | | param | 11847 | | | | | 11848 | TEARDOWN | Prs URI, | Init | No session hdr, | 11849 | | | | NRM = 0 | 11850 | | | | | 11851 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 11852 | | | | NRM = 0 | 11853 | | | | | 11854 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | 11855 | | | | -= 1 | 11856 | | | | | 11857 | PLAY | Prs URI, No range | Play | Play from RP | 11858 | | | | | 11859 | PLAY | Prs URI, Range | Play | According to | 11860 | | | | range | 11861 | | | | | 11862 | PLAY | md URI, NRM=1, Range | Play | According to | 11863 | | | | range | 11864 | | | | | 11865 | PLAY | md URI, NRM=1 | Play | Play from RP | 11866 | | | | | 11867 | PAUSE | Prs URI | Ready | Return PP | 11868 | | | | | 11869 | SC:REDIRECT | Terminate-Reason | Ready | Set RedP | 11870 | | | | | 11871 | SC:REDIRECT | No Terminate-Reason | Init | Session is | 11872 | | time parameter | | removed | 11873 | | | | | 11874 | Timeout | | Init | | 11875 | | | | | 11876 | RedP | | Init | TEARDOWN of | 11877 | reached | | | session | 11878 +-------------+------------------------+---------+------------------+ 11880 Table 15: State: Ready 11882 In the Ready state, see Table 15, some of the actions are depending 11883 on the number of media streams (NRM) in the session, i.e., aggregated 11884 or non-aggregated control. A SETUP request in the Ready state can 11885 either add one more media stream to the session or, if the media 11886 stream (same URI) already is part of the session, change the 11887 transport parameters. TEARDOWN is depending on both the Request-URI 11888 and the number of media streams within the session. If the Request- 11889 URI is the presentations URI the whole session is torn down. If a 11890 media URI is used in the TEARDOWN request and more than one media 11891 exists in the session, the session will remain and a session header 11892 is returned in the response. If only a single media stream remains 11893 in the session when performing a TEARDOWN with a media URI the 11894 session is removed. The number of media streams remaining after 11895 tearing down a media stream determines the new state. 11897 +----------------+-----------------------+--------+-----------------+ 11898 | Action | Requisite | New | Response | 11899 | | | State | | 11900 +----------------+-----------------------+--------+-----------------+ 11901 | PAUSE | Prs URI | Ready | Set RP to | 11902 | | | | present point | 11903 | | | | | 11904 | End of media | All media | Play | Set RP = End of | 11905 | | | | media | 11906 | | | | | 11907 | End of range | | Play | Set RP = End of | 11908 | | | | range | 11909 | | | | | 11910 | PLAY | Prs URI, No range | Play | Play from | 11911 | | | | present point | 11912 | | | | | 11913 | PLAY | Prs URI, Range | Play | According to | 11914 | | | | range | 11915 | | | | | 11916 | SC:PLAY_NOTIFY | | Play | 200 | 11917 | | | | | 11918 | SETUP | New URI | Play | 455 | 11919 | | | | | 11920 | SETUP | Setuped URI | Play | 455 | 11921 | | | | | 11922 | SETUP | Setuped URI, IFI | Play | Change | 11923 | | | | transport | 11924 | | | | param. | 11925 | | | | | 11926 | TEARDOWN | Prs URI | Init | No session hdr | 11927 | | | | | 11928 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 11929 | | | | NRM=0 | 11930 | | | | | 11931 | TEARDOWN | md URI | Play | 455 | 11932 | | | | | 11933 | SC:REDIRECT | Terminate Reason with | Play | Set RedP | 11934 | | Time parameter | | | 11935 | | | | | 11936 | SC:REDIRECT | | Init | Session is | 11937 | | | | removed | 11938 | | | | | 11939 | RedP reached | | Init | TEARDOWN of | 11940 | | | | session | 11941 | | | | | 11942 | Timeout | | Init | Stop Media | 11943 | | | | playout | 11944 +----------------+-----------------------+--------+-----------------+ 11945 Table 16: State: Play 11947 The Play state table, see Table 16, contains a number of requests 11948 that need a presentation URI (labeled as Prs URI) to work on (i.e., 11949 the presentation URI has to be used as the Request-URI). This is due 11950 to the exclusion of non-aggregated stream control in sessions with 11951 more than one media stream. 11953 To avoid inconsistencies between the client and server, automatic 11954 state transitions are avoided. This can be seen at for example "End 11955 of media" event when all media has finished playing, the session 11956 still remains in Play state. An explicit PAUSE request needs to be 11957 sent to change the state to Ready. It may appear that there exist 11958 automatic transitions in "RedP reached" and "PP reached". However, 11959 they are requested and acknowledged before they take place. The time 11960 at which the transition will happen is known by looking at the range 11961 header. If the client sends a request close in time to these 11962 transitions it needs to be prepared for receiving error messages, as 11963 the state may or may not have changed. 11965 Appendix C. Media Transport Alternatives 11967 This section defines how certain combinations of protocols, profiles 11968 and lower transports are used. This includes the usage of the 11969 Transport header's source and destination address parameters 11970 "src_addr" and "dest_addr". 11972 C.1. RTP 11974 This section defines the interaction of RTSP with respect to the RTP 11975 protocol [RFC3550]. It also defines any necessary media transport 11976 signaling with regards to RTP. 11978 The available RTP profiles and lower layer transports are described 11979 below along with rules on signaling the available combinations. 11981 C.1.1. AVP 11983 The usage of the "RTP Profile for Audio and Video Conferences with 11984 Minimal Control" [RFC3551] when using RTP for media transport over 11985 different lower layer transport protocols is defined below in regards 11986 to RTSP. 11988 One such case is defined within this document: the use of embedded 11989 (interleaved) binary data as defined in Section 14. The usage of 11990 this method is indicated by including the "interleaved" parameter. 11992 When using embedded binary data the "src_addr" and "dest_addr" MUST 11993 NOT be used. This addressing and multiplexing is used as defined 11994 with use of channel numbers and the interleaved parameter. 11996 C.1.2. AVP/UDP 11998 This part describes sending of RTP [RFC3550] over lower transport 11999 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 12000 and Video Conferences with Minimal Control" defined in RFC 3551 12001 [RFC3551]. Implementations of RTP/AVP/UDP MUST implement RTCP 12002 (Appendix C.1.6). This profile requires one or two uni- or bi- 12003 directional UDP flows per media stream. The first UDP flow is for 12004 RTP and the second is for RTCP. Multiplexing of RTP and RTCP 12005 (Appendix C.1.6.4) MAY be used, in which case a single UDP flow is 12006 used for both parts. Embedding of RTP data with the RTSP messages, 12007 in accordance with Section 14, SHOULD NOT be performed when RTSP 12008 messages are transported over unreliable transport protocols, like 12009 UDP [RFC0768]. 12011 The RTP/UDP and RTCP/UDP flows can be established using the Transport 12012 header's "src_addr", and "dest_addr" parameters. 12014 In RTSP PLAY mode, the transmission of RTP packets from client to 12015 server is unspecified. The behavior in regards to such RTP packets 12016 MAY be defined in future. 12018 The "src_addr" and "dest_addr" parameters are used in the following 12019 way for media delivery and playback mode, i.e., Mode=PLAY: 12021 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 12022 2 address specifications. Note that two address specifications 12023 MAY be provided even if RTP and RTCP multiplexing is negotiated. 12025 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 12026 contain either: 12028 * both an address and a port number, or 12030 * a port number without an address. 12032 o The first address specification given in either of the parameters 12033 applies to the RTP stream. The second specification if present 12034 applies to the RTCP stream, unless in case RTP and RTCP 12035 multiplexing is negotiated where both RTP and RTCP will use the 12036 first specification. 12038 o The RTP/UDP packets from the server to the client MUST be sent to 12039 the address and port given by the first address specification of 12040 the "dest_addr" parameter. 12042 o The RTCP/UDP packets from the server to the client MUST be sent to 12043 the address and port given by the second address specification of 12044 the "dest_addr" parameter, unless RTP and RTCP multiplexing has 12045 been negotiated, in which case RTCP MUST be sent to the first 12046 address specification. If no second pair is specified and RTP and 12047 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12049 o The RTCP/UDP packets from the client to the server MUST be sent to 12050 the address and port given by the second address specification of 12051 the "src_addr" parameter, unless RTP and RTCP multiplexing has 12052 been negotiated, in which case RTCP MUST be sent to the first 12053 address specification. If no second pair is specified and RTP and 12054 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12056 o The RTP/UDP packets from the client to the server MUST be sent to 12057 the address and port given by the first address specification of 12058 the "src_addr" parameter. 12060 o RTP and RTCP Packets SHOULD be sent from the corresponding 12061 receiver port, i.e., RTCP packets from the server should be sent 12062 from the "src_addr" parameters second address port pair, unless 12063 RTP and RTCP multiplexing has been negotiated in which case the 12064 first address port pair is used. 12066 C.1.3. AVPF/UDP 12068 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 12069 AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. 12070 All that is defined for AVP MUST also apply for AVPF. 12072 The usage of AVPF is indicated by the media initialization protocol 12073 used. In the case of SDP it is indicated by media lines (m=) 12074 containing the profile RTP/AVPF. That SDP MAY also contain further 12075 AVPF related SDP attributes configuring the AVPF session regarding 12076 reporting interval and feedback messages to be used [RFC4585]. This 12077 configuration MUST be followed. 12079 C.1.4. SAVP/UDP 12081 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 12082 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 12083 using RTP. All that is defined for AVP MUST also apply for SAVP. 12085 The usage of SRTP requires that a security context is established. 12086 The default key-management unless otherwise signalled SHALL be MIKEY 12087 in RSA-R mode as defined in Appendix C.1.4.1, and not according to 12088 the procedure defined in "Key Management Extensions for Session 12089 Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" 12090 [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY 12091 message in SDP, thus both requiring the usage of the DESCRIBE method 12092 and forcing the server to keep state for clients performing DESCRIBE 12093 in anticipation that they might require key management. 12095 MIKEY is selected as default method for establishing SRTP 12096 cryptographic context within an RTSP session as it can be embedded in 12097 the RTSP messages, while still ensuring confidentiality of content of 12098 the keying material, even when using hop-by-hop TLS security for the 12099 RTSP messages. This method does also support pipelining of the RTSP 12100 messages. 12102 C.1.4.1. MIKEY Key Establishment 12104 This method for using MIKEY [RFC3830] to establish the SRTP 12105 cryptographic context is initiated in the client's SETUP request, and 12106 the server's response to the SETUP carries the MIKEY response. This 12107 ensures that the crypto context establishment happens simultaneously 12108 with the establishment of the media stream being protected. By using 12109 MIKEY's RSA-R mode [RFC4738] the client can be the initiator and 12110 still allow the server to set the parameters in accordance with the 12111 actual media stream. 12113 The SRTP cryptographic context establishment is done according to the 12114 following process: 12116 1. The client determines that SAVP or SAVPF shall be used from 12117 media description format, e.g., SDP. If no other key management 12118 method is explicitly signalled, then MIKEY SHALL be used as 12119 defined herein. The use of SRTP with RTSP is only defined with 12120 MIKEY with keys established as defined in this Section. Future 12121 documents may define how an RTSP implementation treats SDP that 12122 indicates some other key mechanism to be used. The need for 12123 such specification include [RFC4567] that is not defined for use 12124 in RTSP 2.0 within this document. 12126 2. The client SHALL establish a TLS connection for RTSP messages, 12127 directly or hop by hop with the server. If hop-by-hop TLS 12128 security is used, the User method SHALL be indicated in the 12129 Accept-Credentials header. We do note that using hop-by-hop 12130 does allow the proxy to insert itself as a man in the middle 12131 also in the MIKEY exchange by providing one of its certificates, 12132 rather than the server's in the Connection-Credentials header. 12133 The client SHALL therefore validate the server certificate. 12135 3. The client retrieves the server's certificate from a direct TLS 12136 connection, or if hop by hop from Connection-Credentials header. 12137 The client then checks that the server certificate is valid and 12138 belongs to the server. 12140 4. The client forms the MIKEY Initiator message using RSA-R mode in 12141 unicast mode as specified in [RFC4738]. The client SHOULD use 12142 the same certificate for TLS and in MIKEY to enable the server 12143 to bind the two together. The client's certificate SHALL be 12144 included in the MIKEY message. The client SHALL indicate its 12145 SRTP capabilities in the message. 12147 5. The MIKEY message from the previous step is base64 [RFC4648] 12148 encoded and becomes the value of the MIKEY parameter that is 12149 included in the transport specification(s) that specifies a SRTP 12150 based profile (SAVP, SAVPF) in the SETUP request. 12152 6. Any proxy encountering the MIKEY parameter SHALL forward it 12153 without modification. A proxy requiring to understand transport 12154 specification which doesn't support SAVP/SAVPF with MIKEY will 12155 discard the whole transport specification. Most types of 12156 proxies can easily support SAVP and SAVPF with MIKEY. If 12157 possible bypassing the proxy should be tried. 12159 7. The server upon receiving the SETUP request, will need to decide 12160 upon the transport specification to use, if multiple are 12161 included by the client. In the determination of which transport 12162 specifications that are supported and preferred, the server 12163 SHOULD decode the MIKEY message to take the embedded SRTP 12164 parameters into account. If all transport specs require SRTP 12165 but no MIKEY parameter or other supported keying method is 12166 included, the server SHALL respond with 403. 12168 8. Upon generating a response the following outcomes can occur: 12170 * A transport spec not using SRTP and MIKEY is selected. Thus 12171 the response will not contain any MIKEY parameter. 12173 * A transport spec using SRTP and MIKEY is selected but an 12174 error is encountered in the MIKEY processing. In that case 12175 an RTSP error response code of 466 "Key Management Error" 12176 SHALL be used. A MIKEY message describing the error MAY be 12177 included. 12179 * A transport spec using SRTP and MIKEY is selected and a MIKEY 12180 response message can be created. The server SHOULD use the 12181 same certificate for TLS and in MIKEY to enable client to 12182 bind the two together. If a different certificate is used it 12183 SHALL be included in the MIKEY message. It is RECOMMENDED 12184 that the envelope key cache type is set to 'Cache' and that a 12185 single envelope key is reused for all MIKEY messages to the 12186 client. That message is included in the MIKEY parameter part 12187 of the single selected transport specification in the SETUP 12188 response. The server will set the SRTP parameters as 12189 preferred for this media stream within the supported range by 12190 the client. 12192 9. The server transmits the SETUP response back to the client. 12194 10. The client receives the SETUP response and if the response code 12195 indicates a successful request it decodes the MIKEY message and 12196 establishes the SRTP cryptographic context from the parameters 12197 in the MIKEY response. 12199 In the above method the client's certificate may be self-signed in 12200 cases where the client's identity is not necessary to authenticate 12201 and the security goal is only to ensure that the RTSP signaling 12202 client is the same as the one receiving the SRTP security context. 12204 C.1.5. SAVPF/UDP 12206 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 12207 (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in 12208 RTSP sessions using RTP. All that is defined for AVPF MUST also 12209 apply for SAVPF. 12211 The usage of SRTP requires that a cryptographic context is 12212 established. The default mechanism for establishing that security 12213 association is to use MIKEY[RFC3830] with RTSP as defined in 12214 Appendix C.1.4.1. 12216 C.1.6. RTCP usage with RTSP 12218 RTCP has several usages when RTP is used for media transport as 12219 explained below. Due to that RTCP MUST be supported if an RTSP agent 12220 handles RTP. 12222 C.1.6.1. Media synchronization 12224 RTCP provides media synchronization and clock drift compensation. 12225 The initial media synchronization is available from RTP-Info header. 12226 However, to be able to handle any clock drift between the media 12227 streams, RTCP is needed. 12229 C.1.6.2. RTSP Session keep-alive 12231 RTCP traffic from the RTSP client to the RTSP server MUST function as 12232 keep-alive. This requires an RTSP server supporting RTP to use the 12233 received RTCP packets as indications that the client desires the 12234 related RTSP session to be kept alive. 12236 C.1.6.3. Bit-rate adaption 12238 RTCP Receiver reports and any additional feedback from the client 12239 MUST be used to adapt the bit-rate used over the transport for all 12240 cases when RTP is sent over UDP. An RTP sender without reserved 12241 resources MUST NOT use more than its fair share of the available 12242 resources. This can be determined by comparing on short to medium 12243 term (some seconds) the used bit-rate and adapt it so that the RTP 12244 sender sends at a bit-rate comparable to what a TCP sender would 12245 achieve on average over the same path. 12247 To ensure that the implementation's adaptation mechanism has a well 12248 defined outer envelope, all implementations using a non-congestion 12249 controlled unicast transport protocol, like UDP, MUST implement 12250 Multimedia Congestion Control: Circuit Breakers for Unicast RTP 12251 Sessions [I-D.ietf-avtcore-rtp-circuit-breakers]. 12253 C.1.6.4. RTP and RTCP Multiplexing 12255 RTSP can be used to negotiate the usage of RTP and RTCP multiplexing 12256 as described in [RFC5761]. This allows servers and client to reduce 12257 the amount of resources required for the session by only requiring 12258 one underlying transport stream per media stream instead of two when 12259 using RTP and RTCP. This lessens the server port consumption and 12260 also the necessary state and keep-alive work when operating across 12261 Network and Address Translators [RFC2663]. 12263 Content must be prepared with some consideration for RTP and RTCP 12264 multiplexing, mainly ensuring that the RTP payload types used do not 12265 collide with the ones used for RTCP packet types. This option likely 12266 needs explicit support from the content unless the RTP payload types 12267 can be remapped by the server and that is correctly reflected in the 12268 session description. Beyond that support of this feature should come 12269 at little cost and much gain. 12271 It is recommended that if the content and server support RTP and RTCP 12272 multiplexing that this is indicated in the session description, for 12273 example using the SDP attribute "a=rtcp-mux". If the SDP message 12274 contains the a=rtcp-mux attribute for a media stream, the server MUST 12275 support RTP and RTCP multiplexing. If indicated or otherwise desired 12276 by the client it can include the Transport parameter "RTCP-mux" in 12277 any transport specification where it desires to use RTCP-mux. The 12278 server will indicate if it supports RTCP-mux. Servers and Clients 12279 SHOULD support RTP and RTCP multiplexing. 12281 For capability exchange, an RTSP feature tag for RTP and RTCP 12282 multiplexing is defined: "setup.rtp.rtcp.mux". 12284 To minimize the risk of negotiation failure while using RTP and RTCP 12285 multiplexing some recommendations are here provided. If the session 12286 description includes explicit indication of support (a=rtcp-mux in 12287 SDP), then a RTSP agent can safely create a SETUP request with a 12288 transport specification with only a single dest_addr parameter 12289 address specification. If no such explicit indication is provided, 12290 then even if the feature tag "setup.rtp.rtcp.mux" is provided in a 12291 Supported header by the RTSP server or the feature tag included in 12292 the Required header in the SETUP request, the media resource may not 12293 support RTP and RTCP multiplexing. Thus, to maximize the probability 12294 of successful negotiation the RTSP agent is recommended to include 12295 two dest_addr parameter address specifications in the first or first 12296 set (if pipelining is used) of SETUP request(s) for any media 12297 resource aggregate. That way the RTSP server can either accept RTP 12298 and RTCP multiplexing and only use the first address specification, 12299 and if not use both specifications. The RTSP agent after having 12300 received the response for a successful negotiation of the usage of 12301 RTP and RTCP multiplexing, can then release the resources associated 12302 with the second address specification. 12304 C.2. RTP over TCP 12306 Transport of RTP over TCP can be done in two ways: over independent 12307 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 12308 connection. In both cases the protocol MUST be "rtp" and the lower 12309 layer MUST be TCP. The profile may be any of the above specified 12310 ones; AVP, AVPF, SAVP or SAVPF. 12312 C.2.1. Interleaved RTP over TCP 12314 The use of embedded (interleaved) binary data transported on the RTSP 12315 connection is possible as specified in Section 14. When using this 12316 declared combination of interleaved binary data the RTSP messages 12317 MUST be transported over TCP. TLS may or may not be used. If TLS is 12318 used both RTSP messages and the binary data will be protected by TLS. 12320 One should, however, consider that this will result in all media 12321 streams go through any proxy. Using independent TCP connections can 12322 avoid that issue. 12324 C.2.2. RTP over independent TCP 12326 In this Appendix, we describe the sending of RTP [RFC3550] over lower 12327 transport layer TCP [RFC0793] according to "Framing Real-time 12328 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 12329 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 12330 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 12331 with RTSP. 12333 A client codes the support of RTP over independent TCP by specifying 12334 an RTP/AVP/TCP transport option without an interleaved parameter in 12335 the Transport line of a SETUP request. This transport option MUST 12336 include the "unicast" parameter. 12338 If the client wishes to use RTP with RTCP, two address specifications 12339 needs to be included in the dest_addr parameter. If the client 12340 wishes to use RTP without RTCP, one address specification is included 12341 in the dest_addr parameter. If the client wishes to multiplex RTP 12342 and RTCP on a single transport flow (see Appendix C.1.6.4), one or 12343 two address specifications are included in the dest_addr parameter in 12344 addition to the RTCP-mux transport parameter. Two address 12345 specifications are allowed to allow successful negotiation when 12346 server or content can't support RTP and RTCP multiplexing. Ordering 12347 rules of dest_addr ports follow the rules for RTP/AVP/UDP. 12349 If the client wishes to play the active role in initiating the TCP 12350 connection, it MAY set the "setup" parameter (See Section 18.54) on 12351 the Transport line to be "active", or it MAY omit the setup 12352 parameter, as active is the default. If the client signals the 12353 active role, the ports in the address specifications in the dest_addr 12354 parameter MUST be set to 9 (the discard port). 12356 If the client wishes to play the passive role in TCP connection 12357 initiation, it MUST set the "setup" parameter on the Transport line 12358 to be "passive". If the client is able to assume the active or the 12359 passive role, it MUST set the "setup" parameter on the Transport line 12360 to be "actpass". In either case, the dest_addr parameter's address 12361 specification port value for RTP MUST be set to the TCP port number 12362 on which the client is expecting to receive the TCP connection for 12363 RTP, and the dest_addr's address specification port value for RTCP 12364 MUST be set to the TCP port number on which the client is expecting 12365 to receive the TCP connection for RTCP. In the case that the client 12366 wishes to multiplex RTP and RTCP on a single transport flow, the 12367 RTCP-mux parameter is included and one or two dest_addr parameter 12368 address specifications are included, as mentioned earlier in this 12369 section. 12371 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 12372 server decides to accept this requested option, the 2xx reply MUST 12373 contain a Transport option that specifies RTP/AVP/TCP (without using 12374 the interleaved parameter, and with using the unicast parameter). 12375 The dest_addr parameter value MUST be echoed from the parameter value 12376 in the client request unless the destination address (only port) was 12377 not provided in which case the server MAY include the source address 12378 of the RTSP TCP connection with the port number unchanged. 12380 In addition, the server reply MUST set the setup parameter on the 12381 Transport line, to indicate the role the server will play in the 12382 connection setup. Permissible values are "active" (if a client set 12383 "setup" to "passive" or "actpass") and "passive" (if a client set 12384 "setup" to "active" or "actpass"). 12386 If a server sets "setup" to "passive", the "src_addr" in the reply 12387 MUST indicate the ports the server is willing to receive an TCP 12388 connection for RTP and (if the client requested an TCP connection for 12389 RTCP by specifying two dest_addr address specifications) an TCP/RTCP 12390 connection. If a server sets "setup" to "active", the ports 12391 specified in "src_addr" address specifications MUST be set to 9. The 12392 server MAY use the "ssrc" parameter, following the guidance in 12393 Section 18.54. The server sets only one address specification in the 12394 case that the client has indicated only a single address 12395 specification or in case RTP and RTCP multiplexing was requested and 12396 accepted by server. Port ordering for src_addr follows the rules for 12397 RTP/AVP/UDP. 12399 Servers MUST support taking the passive role and MAY support taking 12400 the active role. Servers with a public IP address take the passive 12401 role, thus enabling clients behind NATs and Firewalls a better chance 12402 of successful connect to the server by actively connecting outwards. 12403 Therefore the clients are RECOMMENDED to take the active role. 12405 After sending (receiving) a 2xx reply for a SETUP method for a non- 12406 interleaved RTP/AVP/TCP media stream, the active party SHOULD 12407 initiate the TCP connection as soon as possible. The client MUST NOT 12408 send a PLAY request prior to the establishment of all the TCP 12409 connections negotiated using SETUP for the session. In case the 12410 server receives a PLAY request in a session that has not yet 12411 established all the TCP connections, it MUST respond using the 464 12412 "Data Transport Not Ready Yet" (Section 17.4.28) error code. 12414 Once the PLAY request for a media resource transported over non- 12415 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 12416 client over the RTP TCP connection, and RTCP packets flow 12417 bidirectionally over the RTCP TCP connection. Unless RTP and RTCP 12418 multiplexing has been negotiated in which case RTP and RTCP will flow 12419 over a common TCP connection. As in the RTP/UDP case, client to 12420 server traffic on a RTP only TCP session is unspecified by this memo. 12421 The packets that travel on these connections MUST be framed using the 12422 protocol defined in [RFC4571], not by the framing defined for 12423 interleaving RTP over the RTSP connection defined in Section 14. 12425 A successful PAUSE request for a media being transported over RTP/ 12426 AVP/TCP pauses the flow of packets over the connections, without 12427 closing the connections. A successful TEARDOWN request signals that 12428 the TCP connections for RTP and RTCP are to be closed by the RTSP 12429 client as soon as possible. 12431 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 12432 ambiguous in the following way: does the client wish to open up new 12433 TCP connection for RTP or RTCP for the URI, or does the client wish 12434 to continue using the existing TCP connections? The client SHOULD 12435 use the "connection" parameter (defined in Section 18.54) on the 12436 Transport line to make its intention clear (by setting "connection" 12437 to "new" if new connections are needed, and by setting "connection" 12438 to "existing" if the existing connections are to be used). After a 12439 2xx reply for a SETUP request for a new connection, parties should 12440 close the pre-existing connections, after waiting a suitable period 12441 for any stray RTP or RTCP packets to arrive. 12443 The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that 12444 a security association is established. The default mechanism for 12445 establishing that security association is to use MIKEY[RFC3830] with 12446 RTSP as defined Appendix C.1.4.1. 12448 Below, we rewrite part of the example media on demand example shown 12449 in Appendix A.1 to use RTP/AVP/TCP non-interleaved: 12451 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 12452 CSeq: 1 12453 User-Agent: PhonyClient/1.2 12455 M->C: RTSP/2.0 200 OK 12456 CSeq: 1 12457 Server: PhonyServer/1.0 12458 Date: Thu, 23 Jan 1997 15:35:06 GMT 12459 Content-Type: application/sdp 12460 Content-Length: 227 12461 Content-Base: rtsp://example.com/twister.3gp/ 12462 Expires: 24 Jan 1997 15:35:06 GMT 12464 v=0 12465 o=- 2890844256 2890842807 IN IP4 198.51.100.34 12466 s=RTSP Session 12467 i=An Example of RTSP Session Usage 12468 e=adm@example.com 12469 c=IN IP4 0.0.0.0 12470 a=control: * 12471 a=range:npt=0-0:10:34.10 12472 t=0 0 12473 m=audio 0 RTP/AVP 0 12474 a=control: trackID=1 12476 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 12477 CSeq: 2 12478 User-Agent: PhonyClient/1.2 12479 Require: play.basic 12480 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 12481 setup=active;connection=new 12482 Accept-Ranges: npt, smpte, clock 12484 M->C: RTSP/2.0 200 OK 12485 CSeq: 2 12486 Server: PhonyServer/1.0 12487 Transport: RTP/AVP/TCP;unicast; 12488 dest_addr=":9"/":9"; 12489 src_addr="198.51.100.5:53478"/"198.51.100:54091"; 12490 setup=passive;connection=new;ssrc=93CB001E 12491 Session: 12345678 12492 Expires: 24 Jan 1997 15:35:12 GMT 12493 Date: 23 Jan 1997 15:35:12 GMT 12494 Accept-Ranges: npt 12495 Media-Properties: Random-Access=0.8, Immutable, Unlimited 12497 C->M: TCP Connection Establishment x2 12499 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 12500 CSeq: 4 12501 User-Agent: PhonyClient/1.2 12502 Range: npt=30- 12503 Session: 12345678 12505 M->C: RTSP/2.0 200 OK 12506 CSeq: 4 12507 Server: PhonyServer/1.0 12508 Date: 23 Jan 1997 15:35:14 GMT 12509 Session: 12345678 12510 Range: npt=30-623.10 12511 Seek-Style: First-Prior 12512 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" 12513 ssrc=4F312DD8:seq=54321;rtptime=2876889 12515 C.3. Handling Media Clock Time Jumps in the RTP Media Layer 12517 RTSP allows media clients to control selected, non-contiguous 12518 sections of media presentations, rendering those streams with an RTP 12519 media layer [RFC3550]. Two cases occur, the first is when a new PLAY 12520 request replaces an old ongoing request and the new request results 12521 in a jump in the media. This should produce in the RTP layer a 12522 continuous media stream. A client may also directly following a 12523 completed PLAY request perform a new PLAY request. This will result 12524 in some gap in the media layer. The below text will look into both 12525 cases. 12527 A PLAY request that replaces an ongoing request allows the media 12528 layer rendering the RTP stream without being affected by jumps in 12529 media clock time. The RTP timestamps for the new media range is set 12530 so that they become continuous with the previous media range in the 12531 previous request. The RTP sequence number for the first packet in 12532 the new range will be the next following the last packet in the 12533 previous range, i.e., monotonically increasing. The goal is to allow 12534 the media rendering layer to work without interruption or 12535 reconfiguration across the jumps in media clock. This should be 12536 possible in all cases of replaced PLAY requests for media that has 12537 random-access properties. In this case care is needed to align 12538 frames or similar media dependent structures. 12540 In cases where jumps in media clock time are a result of RTSP 12541 signaling operations arriving after a completed PLAY operation, the 12542 request timing will result in that media becomes non-continuous. The 12543 server becomes unable to send the media so that it arrives timely and 12544 still carry timestamps to make the media stream continuous. In these 12545 cases the server will produce RTP streams where there are gaps in the 12546 RTP timeline for the media. In such cases, if the media has frame 12547 structure, aligning the timestamp for the next frame with the 12548 previous structure reduces the burden to render this media. The gap 12549 should represent the time the server hasn't been serving media, e.g., 12550 the time between the end of the media stream or a PAUSE request and 12551 the new PLAY request. In these cases the RTP sequence number would 12552 normally be monotonically increasing across the gap. 12554 For RTSP sessions with media that lacks random access properties, 12555 such as live streams, any media clock jump is commonly the result of 12556 a correspondingly long pause of delivery. The RTP timestamp will 12557 have increased in direct proportion to the duration of the paused 12558 delivery. Note also that in this case the RTP sequence number should 12559 be the next packet number. If not, the RTCP packet loss reporting 12560 will indicate as loss all packets not received between the point of 12561 pausing and later resuming. This may trigger congestion avoidance 12562 mechanisms. An allowed exception from the above recommendation on 12563 monotonically increasing RTP sequence number is live media streams, 12564 likely being relayed. In this case, when the client resumes 12565 delivery, it will get the media that is currently being delivered to 12566 the server itself. For this type of basic delivery of live streams 12567 to multiple users over unicast, individual rewriting of RTP sequence 12568 numbers becomes quite a burden. For solutions that anyway caches 12569 media, timeshifts, etc, the rewriting should be a minor issue. 12571 The goal when handling jumps in media clock time is that the provided 12572 stream is continuous without gaps in RTP timestamp or sequence 12573 number. However, when delivery has been halted for some reason the 12574 RTP timestamp when resuming MUST represent the duration the delivery 12575 was halted. RTP sequence number MUST generally be the next number, 12576 i.e., monotonically increasing modulo 65536. For media resources 12577 with the properties Time-Progressing and Time-Duration=0.0 the server 12578 MAY create RTP media streams with RTP sequence number jumps in them 12579 due to the client first halting delivery and later resuming it (PAUSE 12580 and then later PLAY). However, servers utilizing this exception must 12581 take into consideration the resulting RTCP receiver reports that 12582 likely contain loss reports for all the packets part of the 12583 discontinuity. A client cannot rely on that a server will align when 12584 resuming playing even if it is RECOMMENDED. The RTP-Info header will 12585 provide information on how the server acts in each case. 12587 We cannot assume that the RTSP client can communicate with the RTP 12588 media agent, as the two may be independent processes. If the RTP 12589 timestamp shows the same gap as the NPT, the media agent will 12590 assume that there is a pause in the presentation. If the jump in 12591 NPT is large enough, the RTP timestamp may roll over and the media 12592 agent may believe later packets to be duplicates of packets just 12593 played out. Having the RTP timestamp jump will also affect the 12594 RTCP measurements based on this. 12596 As an example, assume an RTP timestamp frequency of 8000 Hz, a 12597 packetization interval of 100 ms and an initial sequence number and 12598 timestamp of zero. 12600 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12601 CSeq: 4 12602 Session: abcdefgh 12603 Range: npt=10-15 12604 User-Agent: PhonyClient/1.2 12606 S->C: RTSP/2.0 200 OK 12607 CSeq: 4 12608 Session: abcdefgh 12609 Range: npt=10-15 12610 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12611 ssrc=0D12F123:seq=0;rtptime=0 12613 The ensuing RTP data stream is depicted below: 12615 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12616 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12617 . . . 12618 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 12620 Upon the completion of the requested delivery the server sends a 12621 PLAY_NOTIFY 12622 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 12623 CSeq: 5 12624 Notify-Reason: end-of-stream 12625 Request-Status: cseq=4 status=200 reason="OK" 12626 Range: npt=-15 12627 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 12628 ssrc=0D12F123:seq=49;rtptime=39200 12629 Session: abcdefgh 12631 C->S: RTSP/2.0 200 OK 12632 CSeq: 5 12633 User-Agent: PhonyClient/1.2 12635 Upon the completion of the play range, the client follows up with a 12636 request to PLAY from a new NPT. 12638 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12639 CSeq: 6 12640 Session: abcdefg 12641 Range: npt=18-20 12642 User-Agent: PhonyClient/1.2 12644 S->C: RTSP/2.0 200 OK 12645 CSeq: 6 12646 Session: abcdefg 12647 Range: npt=18-20 12648 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12649 ssrc=0D12F123:seq=50;rtptime=40100 12651 The ensuing RTP data stream is depicted below: 12653 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 12654 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 12655 . . . 12656 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 12658 In this example, first, NPT 10 through 15 is played, then the client 12659 requests the server to skip ahead and play NPT 18 through 20. The 12660 first segment is presented as RTP packets with sequence numbers 0 12661 through 49 and timestamp 0 through 39,200. The second segment 12662 consists of RTP packets with sequence number 50 through 69, with 12663 timestamps 40,100 through 55,200. While there is a gap in the NPT, 12664 there is no gap in the sequence number space of the RTP data stream. 12666 The RTP timestamp gap is present in the above example due to the time 12667 it takes to perform the second play request, in this case 12.5 ms 12668 (100/8000). 12670 C.4. Handling RTP Timestamps after PAUSE 12672 During a PAUSE / PLAY interaction in an RTSP session, the duration of 12673 time for which the RTP transmission was halted MUST be reflected in 12674 the RTP timestamp of each RTP stream. The duration can be calculated 12675 for each RTP stream as the time elapsed from when the last RTP packet 12676 was sent before the PAUSE request was received and when the first RTP 12677 packet was sent after the subsequent PLAY request was received. The 12678 duration includes all latency incurred and processing time required 12679 to complete the request. 12681 The RTP RFC [RFC3550] states that: The RTP timestamp for each unit 12682 [packet] would be related to the wallclock time at which the unit 12683 becomes current on the virtual presentation timeline. 12685 In order to satisfy the requirements of [RFC3550], the RTP 12686 timestamp space needs to increase continuously with real time. 12687 While this is not optimal for stored media, it is required for RTP 12688 and RTCP to function as intended. Using a continuous RTP 12689 timestamp space allows the same timestamp model for both stored 12690 and live media and allows better opportunity to integrate both 12691 types of media under a single control. 12693 As an example, assume a clock frequency of 8000 Hz, a packetization 12694 interval of 100 ms and an initial sequence number and timestamp of 12695 zero. 12697 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12698 CSeq: 4 12699 Session: abcdefg 12700 Range: npt=10-15 12701 User-Agent: PhonyClient/1.2 12703 S->C: RTSP/2.0 200 OK 12704 CSeq: 4 12705 Session: abcdefg 12706 Range: npt=10-15 12707 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12708 ssrc=0D12F123:seq=0;rtptime=0 12710 The ensuing RTP data stream is depicted below: 12712 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12713 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12714 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 12715 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 12717 The client then sends a PAUSE request: 12719 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 12720 CSeq: 5 12721 Session: abcdefg 12722 User-Agent: PhonyClient/1.2 12724 S->C: RTSP/2.0 200 OK 12725 CSeq: 5 12726 Session: abcdefg 12727 Range: npt=10.4-15 12729 20 seconds elapse and then the client sends a PLAY request. In 12730 addition the server requires 15 ms to process the request: 12732 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12733 CSeq: 6 12734 Session: abcdefg 12735 User-Agent: PhonyClient/1.2 12737 S->C: RTSP/2.0 200 OK 12738 CSeq: 6 12739 Session: abcdefg 12740 Range: npt=10.4-15 12741 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12742 ssrc=0D12F123:seq=4;rtptime=164400 12744 The ensuing RTP data stream is depicted below: 12746 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 12747 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 12748 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 12750 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 12751 server. After 20 seconds a PLAY is received by the server which 12752 takes 15 ms to process. The duration of time for which the session 12753 was paused is reflected in the RTP timestamp of the RTP packets sent 12754 after this PLAY request. 12756 A client can use the RTSP range header and RTP-Info header to map NPT 12757 time of a presentation with the RTP timestamp. 12759 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 12760 was misunderstood commonly. However, for RTSP 2.0 it is expected 12761 that this will be handled correctly and no exception handling will be 12762 required. 12764 Note further: It may be required to reset some of the state to ensure 12765 the correct media decoding and the usual jitter-buffer handling when 12766 issuing a PLAY request. 12768 C.5. RTSP / RTP Integration 12770 For certain data types, tight integration between the RTSP layer and 12771 the RTP layer will be necessary. This by no means precludes the 12772 above restrictions. Combined RTSP/RTP media clients should use the 12773 RTP-Info field to determine whether incoming RTP packets were sent 12774 before or after a seek or before or after a PAUSE. 12776 C.6. Scaling with RTP 12778 For scaling (see Section 18.46), RTP timestamps should correspond to 12779 the rendering timing. For example, when playing video recorded at 30 12780 frames/second at a scale of two and speed (Section 18.50) of one, the 12781 server would drop every second frame to maintain and deliver video 12782 packets with the normal timestamp spacing of 3,000 per frame, but NPT 12783 would increase by 1/15 second for each video frame. 12785 Note: The above scaling puts requirements on the media codec or a 12786 media stream to support it. For example motion JPEG or other non- 12787 predictive video coding can easier handle the above example. 12789 C.7. Maintaining NPT synchronization with RTP timestamps 12791 The client can maintain a correct display of NPT (Normal Play Time) 12792 by noting the RTP timestamp value of the first packet arriving after 12793 repositioning. The sequence parameter of the RTP-Info 12794 (Section 18.45) header provides the first sequence number of the next 12795 segment. 12797 C.8. Continuous Audio 12799 For continuous audio, the server SHOULD set the RTP marker bit at the 12800 beginning of serving a new PLAY request or at jumps in timeline. 12801 This allows the client to perform playout delay adaptation. 12803 C.9. Multiple Sources in an RTP Session 12805 Note that more than one SSRC MAY be sent in the media stream. If it 12806 happens all sources are expected to be rendered simultaneously. 12808 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 12810 The RTCP BYE message indicates the end of use of a given SSRC. If 12811 all sources leave an RTP session, it can, in most cases, be assumed 12812 to have ended. Therefore, a client or server MUST NOT send an RTCP 12813 BYE message until it has finished using a SSRC. A server SHOULD keep 12814 using a SSRC until the RTP session is terminated. Prolonging the use 12815 of a SSRC allows the established synchronization context associated 12816 with that SSRC to be used to synchronize subsequent PLAY requests 12817 even if the PLAY response is late. 12819 An SSRC collision with the SSRC that transmits media does also have 12820 consequences, as it will normally force the media sender to change 12821 its SSRC in accordance with the RTP specification [RFC3550]. 12822 However, an RTSP server may wait and see if the client changes and 12823 thus resolve the conflict to minimize the impact. As media sender 12824 SSRC change will result in a loss of synchronization context, and 12825 require any receiver to wait for RTCP sender reports for all media 12826 requiring synchronization before being able to play out synchronized. 12827 Due to these reasons a client joining a session should take care to 12828 not select the same SSRC(s) as the server indicates in the ssrc 12829 Transport header parameter. Any SSRC signalled in the Transport 12830 header MUST be avoided. A client detecting a collision prior to 12831 sending any RTP or RTCP messages SHALL also select a new SSRC. 12833 C.11. Future Additions 12835 It is the intention that any future protocol or profile regarding 12836 media delivery and lower transport should be easy to add to RTSP. 12837 This section provides the necessary steps that needs to be meet. 12839 The following things needs to be considered when adding a new 12840 protocol or profile for use with RTSP: 12842 o The protocol or profile needs to define a name tag representing 12843 it. This tag is required to be an ABNF "token" to be possible to 12844 use in the Transport header specification. 12846 o The useful combinations of protocol, profiles and lower layer 12847 transport for this extension needs to be defined. For each 12848 combination declare the necessary parameters to use in the 12849 Transport header. 12851 o For new media protocols the interaction with RTSP needs to be 12852 addressed. One important factor will be the media 12853 synchronization. It may be necessary to have new headers similar 12854 to RTP info to carry this information. 12856 o Discuss congestion control for media, especially if transport 12857 without built in congestion control is used. 12859 See the IANA section (Section 22) for information how to register new 12860 attributes. 12862 Appendix D. Use of SDP for RTSP Session Descriptions 12864 The Session Description Protocol (SDP, [RFC4566]) may be used to 12865 describe streams or presentations in RTSP. This description is 12866 typically returned in reply to a DESCRIBE request on an URI from a 12867 server to a client, or received via HTTP from a server to a client. 12869 This appendix describes how an SDP file determines the operation of 12870 an RTSP session. Thus, it is worth pointing out that the 12871 interpretation of the SDP is done in the context of the SDP receiver, 12872 which is the one being configured. This is the same as in SAP 12873 [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each 12874 SDP is interpreted in the context of the agent providing it. 12876 SDP as is provides no mechanism by which a client can distinguish, 12877 without human guidance, between several media streams to be rendered 12878 simultaneously and a set of alternatives (e.g., two audio streams 12879 spoken in different languages). The SDP extension "Grouping of Media 12880 Lines in the Session Description Protocol (SDP)" [RFC5888] provides 12881 such functionality to some degree. Appendix D.4 describes the usage 12882 of SDP media line grouping for RTSP. 12884 D.1. Definitions 12886 The terms "session-level", "media-level" and other key/attribute 12887 names and values used in this appendix are to be used as defined in 12888 SDP[RFC4566]: 12890 D.1.1. Control URI 12892 The "a=control:" attribute is used to convey the control URI. This 12893 attribute is used both for the session and media descriptions. If 12894 used for individual media, it indicates the URI to be used for 12895 controlling that particular media stream. If found at the session 12896 level, the attribute indicates the URI for aggregate control 12897 (presentation URI). The session level URI MUST be different from any 12898 media level URI. The presence of a session level control attribute 12899 MUST be interpreted as support for aggregated control. The control 12900 attribute MUST be present on media level unless the presentation only 12901 contains a single media stream, in which case the attribute MAY be 12902 present on the session level only and then also apply to that single 12903 media stream. 12905 ABNF for the attribute is defined in Section 20.3. 12907 Example: 12908 a=control:rtsp://example.com/foo 12910 This attribute MAY contain either relative or absolute URIs, 12911 following the rules and conventions set out in RFC 3986 [RFC3986]. 12912 Implementations MUST look for a base URI in the following order: 12914 1. the RTSP Content-Base field; 12916 2. the RTSP Content-Location field; 12918 3. the RTSP Request-URI. 12920 If this attribute contains only an asterisk (*), then the URI MUST be 12921 treated as if it were an empty embedded URI, and thus inherit the 12922 entire base URI. 12924 Note, RFC 2326 was very unclear on the processing of relative URI 12925 and several RTSP 1.0 implementations at the point of publishing 12926 this document did not perform RFC 3986 processing to determine the 12927 resulting URI, instead simple concatenation is common. To avoid 12928 this issue completely it is recommended to use absolute URI in the 12929 SDP. 12931 The URI handling for SDPs from container files need special 12932 consideration. For example let's assume that a container file has 12933 the URI: "rtsp://example.com/container.mp4". Let's further assume 12934 this URI is the base URI, and that there is an absolute media level 12935 URI: "rtsp://example.com/container.mp4/trackID=2". A relative media 12936 level URI that resolves in accordance with RFC 3986 [RFC3986] to the 12937 above given media URI is: "container.mp4/trackID=2". It is usually 12938 not desirable to need to include in or modify the SDP stored within 12939 the container file with the server local name of the container file. 12940 To avoid this, one can modify the base URI used to include a trailing 12941 slash, e.g., "rtsp://example.com/container.mp4/". In this case the 12942 relative URI for the media will only need to be: "trackID=2". 12943 However, this will also mean that using "*" in the SDP will result in 12944 control URI including the trailing slash, i.e., 12945 "rtsp://example.com/container.mp4/". 12947 Note: The usage of TrackID in the above is not a standardized 12948 form, but one example out of several similar strings such as 12949 TrackID, Track_ID, StreamID that is used by different server 12950 vendors to indicate a particular piece of media inside a container 12951 file. 12953 D.1.2. Media Streams 12955 The "m=" field is used to enumerate the streams. It is expected that 12956 all the specified streams will be rendered with appropriate 12957 synchronization. If the session is over multicast, the port number 12958 indicated SHOULD be used for reception. The client MAY try to 12959 override the destination port, through the Transport header. The 12960 servers MAY allow this, the response will indicate if allowed or not. 12961 If the session is unicast, the port numbers are the ones RECOMMENDED 12962 by the server to the client, about which receiver ports to use; the 12963 client MUST still include its receiver ports in its SETUP request. 12964 The client MAY ignore this recommendation. If the server has no 12965 preference, it SHOULD set the port number value to zero. 12967 The "m=" lines contain information about which transport protocol, 12968 profile, and possibly lower-layer is to be used for the media stream. 12969 The combination of transport, profile and lower layer, like RTP/AVP/ 12970 UDP needs to be defined for how to be used with RTSP. The currently 12971 defined combinations are defined in Appendix C, further combinations 12972 MAY be specified. 12974 Example: 12975 m=audio 0 RTP/AVP 31 12977 D.1.3. Payload Type(s) 12979 The payload type(s) are specified in the "m=" line. In case the 12980 payload type is a static payload type from RFC 3551 [RFC3551], no 12981 other information may be required. In case it is a dynamic payload 12982 type, the media attribute "rtpmap" is used to specify what the media 12983 is. The "encoding name" within the "rtpmap" attribute may be one of 12984 those specified in [RFC4856], or a media type registered with IANA 12985 according to [RFC4855], or an experimental encoding as specified in 12986 SDP [RFC4566]). Codec-specific parameters are not specified in this 12987 field, but rather in the "fmtp" attribute described below. 12989 The selection of the RTP payload type numbers used may be required to 12990 consider RTP and RTCP Multiplexing [RFC5761] if that is to be 12991 supported by the server. 12993 D.1.4. Format-Specific Parameters 12995 Format-specific parameters are conveyed using the "fmtp" media 12996 attribute. The syntax of the "fmtp" attribute is specific to the 12997 encoding(s) that the attribute refers to. Note that some of the 12998 format specific parameters may be specified outside of the fmtp 12999 parameters, like for example the "ptime" attribute for most audio 13000 encodings. 13002 D.1.5. Directionality of media stream 13004 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 13005 provide instructions about the direction the media streams flow 13006 within a session. When using RTSP the SDP can be delivered to a 13007 client using either RTSP DESCRIBE or a number of RTSP external 13008 methods, like HTTP, FTP, and email. Based on this the SDP applies to 13009 how the RTSP client will see the complete session. Thus media 13010 streams delivered from the RTSP server to the client, would be given 13011 the "a=recvonly" attribute. 13013 "a=recvonly" in a SDP provided to the RTSP client indicates that 13014 media delivery will only occur in the direction from the RTSP server 13015 to the client. SDP provided to the RTSP client that lacks any of the 13016 directionality attributes (a=recvonly, a=sendonly, a=sendrecv) would 13017 be interpreted as having a=sendrecv. At the time of writing there 13018 exist no RTSP mode suitable for media traffic in the direction from 13019 the RTSP client to the server. Thus all RTSP SDP SHOULD have 13020 a=recvonly attribute when using the PLAY mode defined in this 13021 document. If future modes are defined for media in client to server 13022 direction, then usage of a=sendonly, or a=sendrecv may become 13023 suitable to indicate intended media directions. 13025 D.1.6. Range of Presentation 13027 The "a=range" attribute defines the total time range of the stored 13028 session or an individual media. Non-seekable live sessions can be 13029 indicated as specified below, while the length of live sessions can 13030 be deduced from the "t=" and "r=" SDP parameters. 13032 The attribute is both a session and a media level attribute. For 13033 presentations that contain media streams of the same duration, the 13034 range attribute SHOULD only be used at session-level. In case of 13035 different lengths the range attribute MUST be given at media level 13036 for all media, and SHOULD NOT be given at session level. If the 13037 attribute is present at both media level and session level the media 13038 level values MUST be used. 13040 Note: Usually one will specify the same length for all media, even if 13041 there isn't media available for the full duration on all media. 13042 However, that requires that the server accepts PLAY requests within 13043 that range. 13045 Servers MUST take care to provide RTSP Range (see Section 18.40) 13046 values that are consistent with what is presented in the SDP for the 13047 content. There is no reason for non dynamic content, like media 13048 clips provided on demand to have inconsistent values. Inconsistent 13049 values between the SDP and the actual values for the content handled 13050 by the server is likely to generate some failure, like 457 "Invalid 13051 Range", in case the client uses PLAY requests with a Range header. 13052 In case the content is dynamic in length and it is infeasible to 13053 provide a correct value in the SDP the server is recommended to 13054 describe this as non-seekable content (see below). The server MAY 13055 override that property in the response to a PLAY request using the 13056 correct values in the Range header. 13058 The unit is specified first, followed by the value range. The units 13059 and their values are as defined in Section 4.4.1, Section 4.4.2 and 13060 Section 4.4.3 and MAY be extended with further formats. Any open 13061 ended range (start-), i.e., without stop range, is of unspecified 13062 duration and MUST be considered as non-seekable content unless this 13063 property is overridden. Multiple instances carrying different clock 13064 formats MAY be included at either session or media level. 13066 ABNF for the attribute is defined in Section 20.3. 13068 Examples: 13069 a=range:npt=0-34.4368 13070 a=range:clock=19971113T211503Z-19971113T220300Z 13071 Non seekable stream of unknown duration: 13072 a=range:npt=0- 13074 D.1.7. Time of Availability 13076 The "t=" field defines when the SDP is valid. For on-demand content 13077 the server SHOULD indicate a stop time value for which it guarantees 13078 the description to be valid, and a start time that is equal to or 13079 before the time at which the DESCRIBE request was received. It MAY 13080 also indicate start and stop times of 0, meaning that the session is 13081 always available. 13083 For sessions that are of live type, i.e., specific start time, 13084 unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD 13085 be used to indicate the start time of the event. The stop time 13086 SHOULD be given so that the live event will have ended at that time, 13087 while still not be unnecessary long into the future. 13089 D.1.8. Connection Information 13091 In SDP used with RTSP, the "c=" field contains the destination 13092 address for the media stream. If a multicast address is specified 13093 the client SHOULD use this address in any SETUP request as 13094 destination address, including any additional parameters, such as 13095 TTL. For on-demand unicast streams and some multicast streams, the 13096 destination address MAY be specified by the client via the SETUP 13097 request, thus overriding any specified address. To identify streams 13098 without a fixed destination address, where the client is required to 13099 specify a destination address, the "c=" field SHOULD be set to a null 13100 value. For addresses of type "IP4", this value MUST be "0.0.0.0", 13101 and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be 13102 written as "::"), i.e., the unspecified address according to RFC 4291 13103 [RFC4291]. 13105 D.1.9. Message Body Tag 13107 The optional "a=mtag" attribute identifies a version of the session 13108 description. It is opaque to the client. SETUP requests may include 13109 this identifier in the If-Match field (see Section 18.24) to only 13110 allow session establishment if this attribute value still corresponds 13111 to that of the current description. The attribute value is opaque 13112 and may contain any character allowed within SDP attribute values. 13114 ABNF for the attribute is defined in Section 20.3. 13116 Example: 13117 a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a" 13119 One could argue that the "o=" field provides identical 13120 functionality. However, it does so in a manner that would put 13121 constraints on servers that need to support multiple session 13122 description types other than SDP for the same piece of media 13123 content. 13125 D.2. Aggregate Control Not Available 13127 If a presentation does not support aggregate control no session level 13128 "a=control:" attribute is specified. For a SDP with multiple media 13129 sections specified, each section will have its own control URI 13130 specified via the "a=control:" attribute. 13132 Example: 13133 v=0 13134 o=- 2890844256 2890842807 IN IP4 192.0.2.56 13135 s=I came from a web page 13136 e=adm@example.com 13137 c=IN IP4 0.0.0.0 13138 t=0 0 13139 m=video 8002 RTP/AVP 31 13140 a=control:rtsp://audio.example.com/movie.aud 13141 m=audio 8004 RTP/AVP 3 13142 a=control:rtsp://video.example.com/movie.vid 13144 Note that the position of the control URI in the description implies 13145 that the client establishes separate RTSP control sessions to the 13146 servers audio.example.com and video.example.com. 13148 It is recommended that an SDP file contains the complete media 13149 initialization information even if it is delivered to the media 13150 client through non-RTSP means. This is necessary as there is no 13151 mechanism to indicate that the client should request more detailed 13152 media stream information via DESCRIBE. 13154 D.3. Aggregate Control Available 13156 In this scenario, the server has multiple streams that can be 13157 controlled as a whole. In this case, there are both a media-level 13158 "a=control:" attributes, which are used to specify the stream URIs, 13159 and a session-level "a=control:" attribute which is used as the 13160 Request-URI for aggregate control. If the media-level URI is 13161 relative, it is resolved to absolute URIs according to Appendix D.1.1 13162 above. 13164 Example: 13165 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 13166 CSeq: 1 13167 User-Agent: PhonyClient/1.2 13169 M->C: RTSP/2.0 200 OK 13170 CSeq: 1 13171 Date: Thu, 23 Jan 1997 15:35:06 GMT 13172 Expires: Thu, 23 Jan 1997 16:35:06 GMT 13173 Content-Type: application/sdp 13174 Content-Base: rtsp://example.com/movie/ 13175 Content-Length: 227 13177 v=0 13178 o=- 2890844256 2890842807 IN IP4 192.0.2.211 13179 s=I contain 13180 i= 13181 e=adm@example.com 13182 c=IN IP4 0.0.0.0 13183 a=control:* 13184 t=0 0 13185 m=video 8002 RTP/AVP 31 13186 a=control:trackID=1 13187 m=audio 8004 RTP/AVP 3 13188 a=control:trackID=2 13190 In this example, the client is recommended to establish a single RTSP 13191 session to the server, and uses the URIs 13192 rtsp://example.com/movie/trackID=1 and 13193 rtsp://example.com/movie/trackID=2 to set up the video and audio 13194 streams, respectively. The URI rtsp://example.com/movie/, which is 13195 resolved from the "*", controls the whole presentation (movie). 13197 A client is not required to issue SETUP requests for all streams 13198 within an aggregate object. Servers should allow the client to ask 13199 for only a subset of the streams. 13201 D.4. Grouping of Media Lines in SDP 13203 For some types of media it is desirable to express a relationship 13204 between various media components, for instance, for lip 13205 synchronization or Scalable Video Codec (SVC) [RFC5583]. This 13206 relationship is expressed on the SDP level by grouping of media 13207 lines, as described in [RFC5888] and can be exposed to RTSP. 13209 For RTSP it is mainly important to know how to handle grouped medias 13210 received by means of SDP, i.e., if the media are under aggregate 13211 control (see Appendix D.3) or if aggregate control is not available 13212 (see Appendix D.2). 13214 It is RECOMMENDED that grouped medias are handled by aggregate 13215 control, to give the client the ability to control either the whole 13216 presentation or single medias. 13218 D.5. RTSP external SDP delivery 13220 There are some considerations that need to be made when the session 13221 description is delivered to the client outside of RTSP, for example 13222 via HTTP or email. 13224 First of all, the SDP needs to contain absolute URIs, since relative 13225 will in most cases not work as the delivery will not correctly 13226 forward the base URI. 13228 The writing of the SDP session availability information, i.e., "t=" 13229 and "r=", needs to be carefully considered. When the SDP is fetched 13230 by the DESCRIBE method, the probability that it is valid is very 13231 high. However, the same is much less certain for SDPs distributed 13232 using other methods. Therefore the publisher of the SDP should take 13233 care to follow the recommendations about availability in the SDP 13234 specification [RFC4566] in Section 4.2. 13236 Appendix E. RTSP Use Cases 13238 This Appendix describes the most important and considered use cases 13239 for RTSP. They are listed in descending order of importance in 13240 regards to ensuring that all necessary functionality is present. 13241 This specification only fully supports usage of the two first. Also 13242 in these first two cases, there are special cases or exceptions that 13243 are not supported without extensions, e.g., the redirection of media 13244 delivery to another address than the controlling agent's (client's). 13246 E.1. On-demand Playback of Stored Content 13248 An RTSP capable server stores content suitable for being streamed to 13249 a client. A client desiring playback of any of the stored content 13250 uses RTSP to set up the media transport required to deliver the 13251 desired content. RTSP is then used to initiate, halt and manipulate 13252 the actual transmission (playout) of the content. RTSP is also 13253 required to provide necessary description and synchronization 13254 information for the content. 13256 The above high level description can be broken down into a number of 13257 functions that RTSP needs to be capable of. 13259 Presentation Description: Provide initialization information about 13260 the presentation (content); for example, which media codecs are 13261 needed for the content. Other information that is important 13262 includes the number of media streams the presentation contains, 13263 the transport protocols used for the media streams, and 13264 identifiers for these media streams. This information is 13265 required before setup of the content is possible and to 13266 determine if the client is even capable of using the content. 13268 This information need not be sent using RTSP; other external 13269 protocols can be used to transmit the transport presentation 13270 descriptions. Two good examples are the use of HTTP [RFC2616] 13271 or email to fetch or receive presentation descriptions like SDP 13272 [RFC4566] 13274 Setup: Set up some or all of the media streams in a presentation. 13275 The setup itself consists of selecting the protocol for media 13276 transport and the necessary parameters for the protocol, like 13277 addresses and ports. 13279 Control of Transmission: After the necessary media streams have been 13280 established the client can request the server to start 13281 transmitting the content. The client must be allowed to start 13282 or stop the transmission of the content at arbitrary times. 13283 The client must also be able to start the transmission at any 13284 point in the timeline of the presentation. 13286 Synchronization: For media transport protocols like RTP [RFC3550] it 13287 might be beneficial to carry synchronization information within 13288 RTSP. This may be due to either the lack of inter-media 13289 synchronization within the protocol itself, or the potential 13290 delay before the synchronization is established (which is the 13291 case for RTP when using RTCP). 13293 Termination: Terminate the established contexts. 13295 For this use case there are a number of assumptions about how it 13296 works. These are: 13298 On-Demand content: The content is stored at the server and can be 13299 accessed at any time during a time period when it is intended 13300 to be available. 13302 Independent sessions: A server is capable of serving a number of 13303 clients simultaneously, including from the same piece of 13304 content at different points in that presentations time-line. 13306 Unicast Transport: Content for each individual client is transmitted 13307 to them using unicast traffic. 13309 It is also possible to redirect the media traffic to a different 13310 destination than that of the agent controlling the traffic. However, 13311 allowing this without appropriate mechanisms for checking that the 13312 destination approves of this allows for distributed denial of service 13313 attacks (DDoS). 13315 E.2. Unicast Distribution of Live Content 13317 This use case is similar to the above on-demand content case (see 13318 Appendix E.1) the difference is the nature of the content itself. 13319 Live content is continuously distributed as it becomes available from 13320 a source; i.e., the main difference from on-demand is that one starts 13321 distributing content before the end of it has become available to the 13322 server. 13324 In many cases the consumer of live content is only interested in 13325 consuming what actually happens "now"; i.e., very similar to 13326 broadcast TV. However, in this case it is assumed that there exists 13327 no broadcast or multicast channel to the users, and instead the 13328 server functions as a distribution node, sending the same content to 13329 multiple receivers, using unicast traffic between server and client. 13330 This unicast traffic and the transport parameters are individually 13331 negotiated for each receiving client. 13333 Another aspect of live content is that it often has a very limited 13334 time of availability, as it is only available for the duration of the 13335 event the content covers. An example of such a live content could be 13336 a music concert which lasts 2 hour and starts at a predetermined 13337 time. Thus there is a need to announce when and for how long the 13338 live content is available. 13340 In some cases, the server providing live content may be saving some 13341 or all of the content to allow clients to pause the stream and resume 13342 it from the paused point, or to "rewind" and play continuously from a 13343 point earlier than the live point. Hence, this use case does not 13344 necessarily exclude playing from other than the live point of the 13345 stream, playing with scales other than 1.0, etc. 13347 E.3. On-demand Playback using Multicast 13349 It is possible to use RTSP to request that media be delivered to a 13350 multicast group. The entity setting up the session (the controller) 13351 will then control when and what media is delivered to the group. 13352 This use case has some potential for denial of service attacks by 13353 flooding a multicast group. Therefore, a mechanism is needed to 13354 indicate that the group actually accepts the traffic from the RTSP 13355 server. 13357 An open issue in this use case is how one ensures that all receivers 13358 listening to the multicast or broadcast receives the session 13359 presentation configuring the receivers. This specification has to 13360 rely on an external solution to solve this issue. 13362 E.4. Inviting an RTSP server into a conference 13364 If one has an established conference or group session, it is possible 13365 to have an RTSP server distribute media to the whole group. 13366 Transmission to the group is simplest when controlled by a single 13367 participant or leader of the conference. Shared control might be 13368 possible, but would require further investigation and possibly 13369 extensions. 13371 This use case assumes that there exists either multicast or a 13372 conference focus that redistribute media to all participants. 13374 This use case is intended to be able to handle the following 13375 scenario: A conference leader or participant (hereafter called the 13376 controller) has some pre-stored content on an RTSP server that he 13377 wants to share with the group. The controller sets up an RTSP 13378 session at the streaming server for this content and retrieves the 13379 session description for the content. The destination for the media 13380 content is set to the shared multicast group or conference focus. 13382 When desired by the controller, he/she can start and stop the 13383 transmission of the media to the conference group. 13385 There are several issues with this use case that are not solved by 13386 this core specification for RTSP: 13388 Denial of service: To avoid an RTSP server from being an unknowing 13389 participant in a denial of service attack the server needs to 13390 be able to verify the destination's acceptance of the media. 13391 Such a mechanism to verify the approval of received media does 13392 not yet exist; instead, only policies can be used, which can be 13393 made to work in controlled environments. 13395 Distributing the presentation description to all participants in the 13396 group: To enable a media receiver to correctly decode the content 13397 the media configuration information needs to be distributed 13398 reliably to all participants. This will most likely require 13399 support from an external protocol. 13401 Passing control of the session: If it is desired to pass control of 13402 the RTSP session between the participants, some support will be 13403 required by an external protocol to exchange state information 13404 and possibly floor control of who is controlling the RTSP 13405 session. 13407 E.5. Live Content using Multicast 13409 This use case in its simplest form does not require any use of RTSP 13410 at all; this is what multicast conferences being announced with SAP 13411 [RFC2974] and SDP are intended to handle. However, in use cases 13412 where more advanced features like access control to the multicast 13413 session are desired, RTSP could be used for session establishment. 13415 A client desiring to join a live multicasted media session with 13416 cryptographic (encryption) access control could use RTSP in the 13417 following way. The source of the session announces the session and 13418 gives all interested an RTSP URI. The client connects to the server 13419 and requests the presentation description, allowing configuration for 13420 reception of the media. In this step it is possible for the client 13421 to use secured transport and any desired level of authentication; for 13422 example, for billing or access control. An RTSP link also allows for 13423 load balancing between multiple servers. 13425 If these were the only goals, they could be achieved by simply using 13426 HTTP. However, for cases where the sender likes to keep track of 13427 each individual receiver of a session, and possibly use the session 13428 as a side channel for distributing key-updates or other information 13429 on a per-receiver basis, and the full set of receivers is not known 13430 prior to the session start, the state establishment that RTSP 13431 provides can be beneficial. In this case a client would establish an 13432 RTSP session for this multicast group with the RTSP server. The RTSP 13433 server will not transmit any media, but instead will point to the 13434 multicast group. The client and server will be able to keep the 13435 session alive for as long as the receiver participates in the session 13436 thus enabling, for example, the server to push updates to the client. 13438 This use case will most likely not be able to be implemented without 13439 some extensions to the server-to-client push mechanism. Here the 13440 PLAY_NOTIFY method (see Section 13.5) with a suitable extension could 13441 provide clear benefits. 13443 Appendix F. Text format for Parameters 13445 A resource of type "text/parameters" consists of either 1) a list of 13446 parameters (for a query) or 2) a list of parameters and associated 13447 values (for an response or setting of the parameter). Each entry of 13448 the list is a single line of text. Parameters are separated from 13449 values by a colon. The parameter name MUST only use US-ASCII visible 13450 characters while the values are UTF-8 text strings. The media type 13451 registration form is in Section 22.16. 13453 There is a potential interoperability issue for this format. It was 13454 named in RFC 2326 but never defined, even if used in examples that 13455 hint at the syntax. This format matches the purpose and its syntax 13456 supports the examples provided. However, it goes further by allowing 13457 UTF-8 in the value part, thus usage of UTF-8 strings may not be 13458 supported. However, as individual parameters are not defined, the 13459 using application anyway needs to have out-of-band agreement or using 13460 feature-tag to determine if the end-point supports the parameters. 13462 The ABNF [RFC5234] grammar for "text/parameters" content is: 13464 file = *((parameter / parameter-value) CRLF) 13465 parameter = 1*visible-except-colon 13466 parameter-value = parameter *WSP ":" value 13467 visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" 13468 value = *(TEXT-UTF8char / WSP) 13469 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 13470 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 13471 / %xE0-EF 2UTF8-CONT 13472 / %xF0-F7 3UTF8-CONT 13473 / %xF8-FB 4UTF8-CONT 13474 / %xFC-FD 5UTF8-CONT 13475 UTF8-CONT = %x80-BF 13476 WSP = ; Space or HTAB 13477 VCHAR = 13478 CRLF = 13480 Appendix G. Requirements for Unreliable Transport of RTSP 13482 This appendix provides guidance for those who want to implement RTSP 13483 messages over unreliable transports as has been defined in RTSP 1.0 13484 [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some 13485 basic information for the transport of RTSP messages over UDP. The 13486 information is being provided here as there has been at at least one 13487 commercial implementation and compatibility with that should be 13488 maintained. 13490 The following points should be considered for an interoperable 13491 implementation: 13493 o Request shall be acknowledged by the receiver. If there is no 13494 acknowledgement, the sender may resend the same message after a 13495 timeout of one round-trip time (RTT). Any retransmissions due to 13496 lack of acknowledgement must carry the same sequence number as the 13497 original request. 13499 o The round-trip time can be estimated as in TCP (RFC 6298) 13500 [RFC6298], with an initial round-trip value of 500 ms. An 13501 implementation may cache the last RTT measurement as the initial 13502 value for future connections. 13504 o The Timestamp header (Section 18.53) is used to avoid the 13505 retransmission ambiguity problem [Stevens98]. 13507 o The registered default port for RTSP over UDP for the server is 13508 554. 13510 o RTSP messages can be carried over any lower-layer transport 13511 protocol that is 8-bit clean. 13513 o RTSP messages are vulnerable to bit errors and should not be 13514 subjected to them. 13516 o Source authentication, or at least validation that RTSP messages 13517 comes from the same entity becomes extremely important, as session 13518 hijacking may be substantially easier for RTSP message transport 13519 using an unreliable protocol like UDP than for TCP. 13521 There are two RTSP headers that are primarily intended for being used 13522 by the unreliable handling of RTSP messages and which will be 13523 maintained: 13525 o CSeq: See Section 18.20. It should be noted that the CSeq header 13526 is also required to match requests and responses independent 13527 whether a reliable or unreliable transport is used. 13529 o Timestamp: See Section 18.53 13531 Appendix H. Backwards Compatibility Considerations 13533 This section contains notes on issues about backwards compatibility 13534 with clients or servers being implemented according to RFC 2326 13535 [RFC2326]. Note that there exists no requirement to implement RTSP 13536 1.0; in fact we recommend against it as it is difficult to do in an 13537 interoperable way. 13539 A server implementing RTSP/2.0 MUST include an RTSP-Version of 13540 RTSP/2.0 in all responses to requests containing RTSP-Version 13541 RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond 13542 with an RTSP/1.0 response if it chooses to support RFC 2326. If the 13543 server chooses not to support RFC 2326, it MUST respond with a 505 13544 (RTSP Version not supported) status code. A server MUST NOT respond 13545 to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 13546 response. 13548 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 13549 Version of 2.0 to determine whether a server supports RTSP/2.0. If 13550 the server responds with either an RTSP-Version of 1.0 or a status 13551 code of 505 (RTSP Version not supported), the client will have to use 13552 RTSP/1.0 requests if it chooses to support RFC 2326. 13554 H.1. Play Request in Play State 13556 The behavior in the server when a Play is received in Play state has 13557 changed (Section 13.4). In RFC 2326, the new PLAY request would be 13558 queued until the current Play completed. Any new PLAY request now 13559 takes effect immediately replacing the previous request. 13561 H.2. Using Persistent Connections 13563 Some server implementations of RFC 2326 maintain a one-to-one 13564 relationship between a connection and an RTSP session. Such 13565 implementations require clients to use a persistent connection to 13566 communicate with the server and when a client closes its connection, 13567 the server may remove the RTSP session. This is worth noting if a 13568 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 13570 Appendix I. Changes 13572 This appendix briefly lists the differences between RTSP 1.0 13573 [RFC2326] and RTSP 2.0 for an informational purpose. For 13574 implementers of RTSP 2.0 it is recommended to read carefully through 13575 this memo and not to rely on the list of changes below to adapt from 13576 RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards 13577 compatible with RTSP 1.0 [RFC2326] other than the version negotiation 13578 mechanism. 13580 I.1. Brief Overview 13582 The following protocol elements were removed in RTSP 2.0 compared to 13583 RTSP 1.0: 13585 o there is no section on minimal implementation anymore, but more 13586 the definition of RTSP 2.0 core; 13588 o the RECORD and ANNOUNCE methods and all related functionality 13589 (including 201 (Created) and 250 (Low On Storage Space) status 13590 codes); 13592 o the use of UDP for RTSP message transport was removed due to 13593 missing interest and to broken specification; 13595 o the use of PLAY method for keep-alive in Play state. 13597 The following protocol elements were added or changed in RTSP 2.0 13598 compared to RTSP 1.0: 13600 o RTSP session TEARDOWN from the server to the client; 13602 o IPv6 support; 13604 o extended IANA registries (e.g., transport headers parameters, 13605 transport-protocol, profile, lower-transport, and mode); 13607 o request pipelining for quick session start-up; 13609 o fully reworked state-machine; 13611 o RTSP messages now use URIs rather then URLs; 13613 o incorporated much of related HTTP text ([RFC2616]) in this memo, 13614 compared to just referencing the sections in HTTP, to avoid 13615 ambiguities; 13617 o the REDIRECT method was expanded and diversified for different 13618 situations; 13620 o Includes a new section about how to setup different media 13621 transport alternatives and their profiles, and lower layer 13622 protocols. This caused the appendix on RTP interaction to be 13623 moved there instead of being in the part which describes RTP. The 13624 section also includes guidelines what to consider when writing 13625 usage guidelines for new protocols and profiles; 13627 o Added an asynchronous notification method PLAY_NOTIFY. This 13628 method is used by the RTSP server to asynchronously notify clients 13629 about session changes while in Play state. To a limited extent 13630 this is comparable with some implementations of ANNOUNCE in RTSP 13631 1.0 not intended for Recording. 13633 I.2. Detailed List of Changes 13635 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 13636 defining RTSP 2.0. Note that this list does not reflect minor 13637 changes in wording or correction of typographical errors. 13639 o The section on minimal implementation was deleted without 13640 substitution. 13642 o The Transport header has been changed in the following way: 13644 * The ABNF has been changed to define that extensions are 13645 possible, and that unknown parameters result in that servers 13646 ignore the transport specification. 13648 * To prevent backwards compatibility issues, any extension or new 13649 parameter requires the usage of a feature-tag combined with the 13650 Require header. 13652 * Syntax unclarities with the Mode parameter have been resolved. 13654 * Syntax error with ";" for multicast and unicast has been 13655 resolved. 13657 * Two new addressing parameters have been defined, src_addr and 13658 dest_addr. These replace the parameters "port", "client_port", 13659 "server_port", "destination", "source". 13661 * Support for IPv6 explicit addresses in all address fields has 13662 been included. 13664 * To handle URI definitions that contain ";" or "," a quoted URI 13665 format has been introduced and is required. 13667 * Defined IANA registries for the transport headers parameters, 13668 transport-protocol, profile, lower-transport, and mode. 13670 * The transport headers interleaved parameter's text was made 13671 more strict and uses formal requirements levels. It was also 13672 clarified that the interleaved channels are symmetric and that 13673 it is the server that sets the channel numbers. 13675 * It has been clarified that the client can't request of the 13676 server to use a certain RTP SSRC, using a request with the 13677 transport parameter SSRC. 13679 * Syntax definition for SSRC has been clarified to require 8HEX. 13680 It has also been extended to allow multiple values for clients 13681 supporting this version. 13683 * Clarified the text on the transport headers "dest_addr" 13684 parameters regarding what security precautions the server is 13685 required to perform. 13687 o The Range formats has been changed in the following way: 13689 * The NPT format has been given an initial NPT identifier that 13690 must now be used. 13692 * All formats now support initial open ended formats of type 13693 "npt=-10" and also format only "Range: smpte" ranges for usage 13694 with GET_PARAMETER requests. 13696 o RTSP message handling has been changed in the following way: 13698 * RTSP messages now use URIs rather then URLs. 13700 * It has been clarified that a 4xx message due to missing CSeq 13701 header shall be returned without a CSeq header. 13703 * The 300 (Multiple Choices) response code has been removed. 13705 * Rules for how to handle timing out RTSP messages has been 13706 added. 13708 * Extended Pipelining rules allowing for quick session startup. 13710 * Sequence numbering and proxy handling of sequence number 13711 defined, including case when response arrive out of order. 13713 o The HTTP references have been updated to RFC 2616 and RFC 2617. 13714 Most of the text has been copied and then altered to fit RTSP into 13715 this specification. Public, and the Content-Base header has also 13716 been imported from RFC 2068 so that they are defined in the RTSP 13717 specification. Known effects on RTSP due to HTTP clarifications: 13719 * Content-Encoding header can include encoding of type 13720 "identity". 13722 o The state machine section has been completely rewritten. It now 13723 includes more details and is also more clear about the model used. 13725 o An IANA section has been included which contains a number of 13726 registries and their rules. This will allow us to use IANA to 13727 keep track of RTSP extensions. 13729 o The transport of RTSP messages has seen the following changes: 13731 * The use of UDP for RTSP message transport has been deprecated 13732 due to missing interest and to broken specification. 13734 * The rules for how TCP connections are to be handled has been 13735 clarified. Now it is made clear that servers should not close 13736 the TCP connection unless they have been unused for significant 13737 time. 13739 * Strong recommendations why server and clients should use 13740 persistent connections have also been added. 13742 * There is now a requirement on the servers to handle non- 13743 persistent connections as this provides fault tolerance. 13745 * Added wording on the usage of Connection:Close for RTSP. 13747 * Specified usage of TLS for RTSP messages, including a scheme to 13748 approve a proxy's TLS connection to the next hop. 13750 o The following header related changes have been made: 13752 * Accept-Ranges response header is added. This header clarifies 13753 which range formats that can be used for a resource. 13755 * Fixed the missing definitions for the Cache-Control header. 13756 Also added to the syntax definition the missing delta-seconds 13757 for max-stale and min-fresh parameters. 13759 * Put requirement on CSeq header that the value is increased by 13760 one for each new RTSP request. A Recommendation to start at 0 13761 has also been added. 13763 * Added requirement that the Date header must be used for all 13764 messages with message body and the Server should always include 13765 it. 13767 * Removed possibility of using Range header with Scale header to 13768 indicate when it is to be activated, since it can't work as 13769 defined. Also added rule that lack of Scale header in response 13770 indicates lack of support for the header. Feature-tags for 13771 scaled playback has been defined. 13773 * The Speed header must now be responded to indicate support and 13774 the actual speed going to be used. A feature-tag is defined. 13775 Notes on congestion control were also added. 13777 * The Supported header was borrowed from SIP [RFC3261] to help 13778 with the feature negotiation in RTSP. 13780 * Clarified that the Timestamp header can be used to resolve 13781 retransmission ambiguities. 13783 * The Session header text has been expanded with an explanation 13784 on keep-alive and which methods to use. SET_PARAMETER is now 13785 recommended to use if only keep-alive within RTSP is desired. 13787 * It has been clarified how the Range header formats are used to 13788 indicate pause points in the PAUSE response. 13790 * Clarified that RTP-Info URIs that are relative, use the 13791 Request-URI as base URI. Also clarified that the used URI must 13792 be the one that was used in the SETUP request. The URIs are 13793 now also required to be quoted. The header also expresses the 13794 SSRC for the provided RTP timestamp and sequence number values. 13796 * Added text that requires the Range to always be present in PLAY 13797 responses. Clarified what should be sent in case of live 13798 streams. 13800 * The headers table has been updated using a structure borrowed 13801 from SIP. Those tables convey much more information and should 13802 provide a good overview of the available headers. 13804 * It has been clarified that any message with a message body is 13805 required to have a Content-Length header. This was the case in 13806 RFC 2326, but could be misinterpreted. 13808 * ETag has changed name to MTag. 13810 * To resolve functionality around MTag. The MTag and If-None- 13811 Match header have been added from HTTP with necessary 13812 clarification in regards to RTSP operation. 13814 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 13815 it has been removed from HTTP due to lack of use. Public is 13816 used quite frequently in RTSP. 13818 * Clarified rules for populating the Public header so that it is 13819 an intersection of the capabilities of all the RTSP agents in a 13820 chain. 13822 * Added the Media-Range header for listing the current 13823 availability of the media range. 13825 * Added the Notify-Reason header for giving the reason when 13826 sending PLAY_NOTIFY requests. 13828 * A new header Seek-Style has been defined to direct and inform 13829 how any seek operation should/have been performed. 13831 o The Protocol Syntax has been changed in the following way: 13833 * All ABNF definitions are updated according to the rules defined 13834 in RFC 5234 [RFC5234] and have been gathered in a separate 13835 Section 20. 13837 * The ABNF for the User-Agent and Server headers have been 13838 corrected. 13840 * Some definitions in the introduction regarding the RTSP session 13841 have been changed. 13843 * The protocol has been made fully IPv6 capable. 13845 * The CHAR rule has been changed to exclude NULL. 13847 o The Status codes have been changed in the following way: 13849 * The use of status code 303 "See Other" has been deprecated as 13850 it does not make sense to use in RTSP. 13852 * When sending response 451 and 458 the response body should 13853 contain the offending parameters. 13855 * Clarification on when a 3rr redirect status code can be 13856 received has been added. This includes receiving 3rr as a 13857 result of a request within a established session. This 13858 provides clarification to a previous unspecified behavior. 13860 * Removed the 201 (Created) and 250 (Low On Storage Space) status 13861 codes as they are only relevant to recording, which is 13862 deprecated. 13864 * Several new Status codes have been defined: 464 "Data Transport 13865 Not Ready Yet", 465 "Notification Reason Unknown", 470 13866 "Connection Authorization Required", 471 "Connection 13867 Credentials not accepted", 472 "Failure to establish secure 13868 connection". 13870 o The following functionality has been deprecated from the protocol: 13872 * The use of Queued Play. 13874 * The use of PLAY method for keep-alive in Play state. 13876 * The RECORD and ANNOUNCE methods and all related functionality. 13877 Some of the syntax has been removed. 13879 * The possibility to use timed execution of methods with the time 13880 parameter in the Range header. 13882 * The description on how rtspu works is not part of the core 13883 specification and will require external description. Only that 13884 it exists is defined here and some requirements for the 13885 transport is provided. 13887 o The following changes have been made in relation to methods: 13889 * The OPTIONS method has been clarified with regards to the use 13890 of the Public and Allow headers. 13892 * Added text clarifying the usage of SET_PARAMETER for keep-alive 13893 and usage without any body. 13895 * PLAY method is now allowed to be pipelined with the pipelining 13896 of one or more SETUP requests following the initial that 13897 generates the session for aggregated control. 13899 * REDIRECT has been expanded and diversified for different 13900 situations. 13902 * Added a new method PLAY_NOTIFY. This method is used by the 13903 RTSP server to asynchronously notify clients about session 13904 changes. 13906 o Wrote a new section about how to setup different media transport 13907 alternatives and their profiles, and lower layer protocols. This 13908 caused the appendix on RTP interaction to be moved there instead 13909 of being in the part which describes RTP. The section also 13910 includes guidelines what to consider when writing usage guidelines 13911 for new protocols and profiles. 13913 o Setup and usage of independent TCP connections for transport of 13914 RTP has been specified. 13916 o Added a new section describing the available mechanisms to 13917 determine if functionality is supported, called "Capability 13918 Handling". Renamed option-tags to feature-tags. 13920 o Added a contributors section with people who have contributed 13921 actual text to the specification. 13923 o Added a section Use Cases that describes the major use cases for 13924 RTSP. 13926 o Clarified the usage of a=range and how to indicate live content 13927 that are not seekable with this header. 13929 o Text specifying the special behavior of PLAY for live content. 13931 o Security features of RTSP has been clarified: 13933 * HTTP based authorization has been clarified requring both Basic 13934 and DIGEST support 13936 * TLS support mandated 13938 * IF one implements RTP then SRTP and defined MIKEY based key- 13939 exchange must be supported 13941 * Various minor mitigations discussed or resulted in protocol 13942 changes. 13944 Appendix J. Acknowledgements 13946 This memorandum defines RTSP version 2.0 which is a revision of the 13947 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 13948 The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert 13949 Lanphier. 13951 Both RTSP version 1.0 and RTSP version 2.0 borrow format and 13952 descriptions from HTTP/1.1. 13954 This document has benefited greatly from the comments of all those 13955 participating in the MMUSIC-WG. In addition to those already 13956 mentioned, the following individuals have contributed to this 13957 specification: 13959 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 13960 Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi, 13961 Francisco Cortes, Elwyn Davies, Kelly Djahandari, Martin Dunsmuir, 13962 Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy 13963 Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, 13964 Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, 13965 Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth 13966 Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Chris 13967 Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool, Martti Mela, 13968 David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, 13969 Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi, Igor 13970 Plotnikov, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David 13971 Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John 13972 Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker, 13973 Stephan Wenger, Dale R. Worley, and Byungjo Yoon , and especially to 13974 Flemming Andreasen. 13976 J.1. Contributors 13978 The following people have made written contributions that were 13979 included in the specification: 13981 o Tom Marshall contributed text on the usage of 3rr status codes. 13983 o Thomas Zheng contributed text on the usage of the Range in PLAY 13984 responses and proposed an earlier version of the PLAY_NOTIFY 13985 method. 13987 o Sean Sheedy contributed text on the timeout behavior of RTSP 13988 messages and connections, the 463 status code, and proposed an 13989 earlier version of the PLAY_NOTIFY method. 13991 o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY 13992 method. 13994 o Fredrik Lindholm contributed text about the RTSP security 13995 framework. 13997 o John Lazzaro contributed the text for RTP over Independent TCP. 13999 o Aravind Narasimhan contributed by rewriting Media Transport 14000 Alternatives (Appendix C) and editorial improvements on a number 14001 of places in the specification. 14003 o Torbjorn Einarsson has done some editorial improvements of the 14004 text. 14006 Appendix K. RFC Editor Consideration 14008 Please replace RFC XXXX with the RFC number this specification 14009 receives. 14011 Authors' Addresses 14013 Henning Schulzrinne 14014 Columbia University 14015 1214 Amsterdam Avenue 14016 New York, NY 10027 14017 USA 14019 Email: schulzrinne@cs.columbia.edu 14021 Anup Rao 14022 Cisco 14023 USA 14025 Email: anrao@cisco.com 14027 Rob Lanphier 14028 Seattle, WA 14029 USA 14031 Email: robla@robla.net 14033 Magnus Westerlund 14034 Ericsson AB 14035 Faeroegatan 6 14036 STOCKHOLM, SE-164 80 14037 SWEDEN 14039 Email: magnus.westerlund@ericsson.com 14041 Martin Stiemerling 14042 NEC Laboratories Europe, NEC Europe Ltd. 14043 Kurfuersten-Anlage 36 14044 Heidelberg 69115 14045 Germany 14047 Phone: +49 (0) 6221 4342 113 14048 Email: martin.stiemerling@neclab.eu 14049 URI: http://ietf.stiemerling.org