idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-35.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 2, 2013) is 3887 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 4975, but not defined == Missing Reference: 'H15' is mentioned on line 9381, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 10007, 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 6, 2014 R. Lanphier 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 September 2, 2013 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-35 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 6, 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 RTSP Messages that doesn't contain any message body is terminated by 1648 the first empty line after the header fields (Note: An empty line is 1649 a line with nothing preceding the CRLF.). In RTSP messages that 1650 contains 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 headers value represents 1653 the length of the message-body in octets. If this header field is 1654 not present, a value of zero is assumed, i.e. no message body present 1655 in message. Unlike an HTTP message, an RTSP message MUST contain a 1656 Content-Length header whenever it contains a message body. Note that 1657 RTSP does not support the HTTP/1.1 "chunked" transfer coding (see 1658 [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 | all | 1969 | | Required | | 1970 | | | | 1971 | 408 | Request Timeout | all | 1972 | | | | 1973 | 410 | Gone | all | 1974 | | | | 1975 | Precondition Failed | DESCRIBE, SETUP | 413 | 1976 | | | | 1977 | Request Message Body Too Large | all | 414 | 1978 | | | | 1979 | Request-URI Too Long | all | 415 | 1980 | | | | 1981 | Unsupported Media Type | all | 451 | 1982 | | | | 1983 | Parameter Not Understood | SET_PARAMETER, | 452 | 1984 | | GET_PARAMETER | | 1985 | | | | 1986 | reserved | n/a | 453 | 1987 | | | | 1988 | Not Enough Bandwidth | SETUP | 454 | 1989 | | | | 1990 | Session Not Found | all | 455 | 1991 | | | | 1992 | Method Not Valid In This State | all | 456 | 1993 | | | | 1994 | Header Field Not Valid | all | 457 | 1995 | | | | 1996 | Invalid Range | PLAY, PAUSE | 458 | 1997 | | | | 1998 | Parameter Is Read-Only | SET_PARAMETER | 459 | 1999 | | | | 2000 | Aggregate Operation Not | all | 460 | 2001 | Allowed | | | 2002 | Only Aggregate Operation | all | 461 | 2003 | Allowed | | | 2004 | | | | 2005 | Unsupported Transport | all | 462 | 2006 | | | | 2007 | Destination Unreachable | all | 463 | 2008 | | | | 2009 | Destination Prohibited | SETUP | 464 | 2010 | | | | 2011 | Data Transport Not Ready Yet | PLAY | 465 | 2012 | | | | 2013 | Notification Reason Unknown | PLAY_NOTIFY | 466 | 2014 | | | | 2015 | Key Management Error | all | 470 | 2016 | | | | 2017 | Connection Authorization | all | 471 | 2018 | Required | | | 2019 | | | | 2020 | Connection Credentials not | all | 472 | 2021 | accepted | | | 2022 | | | | 2023 | Failure to establish secure | all | | 2024 | connection | | | 2025 | | | | 2026 | | | 500 | 2027 | | | | 2028 | Internal Server Error | all | 501 | 2029 | | | | 2030 | Not Implemented | all | 502 | 2031 | | | | 2032 | Bad Gateway | all | 503 | 2033 | | | | 2034 | Service Unavailable | all | 504 | 2035 | | | | 2036 | Gateway Timeout | all | 505 | 2037 | | | | 2038 | RTSP Version Not Supported | all | 551 | 2039 | | | | 2040 | Option Not Supported | all | 553 | 2041 | | | | 2042 | Proxy Unavailable | all | | 2043 +--------------------------------+-------------------------+--------+ 2045 Table 4: Status codes and their usage with RTSP methods 2047 8.2. Response Headers 2049 The response-headers allow the request recipient to pass additional 2050 information about the response which cannot be placed in the Status- 2051 Line. This header gives information about the server and about 2052 further access to the resource identified by the Request-URI. All 2053 headers currently classified as response headers are listed in 2054 Table 5. 2056 +------------------------+--------------------+ 2057 | Header | Defined in Section | 2058 +------------------------+--------------------+ 2059 | Authentication-Info | Section 18.7 | 2060 | | | 2061 | Connection-Credentials | Section 18.13 | 2062 | | | 2063 | Location | Section 18.28 | 2064 | | | 2065 | MTag | Section 18.31 | 2066 | | | 2067 | Proxy-Authenticate | Section 18.34 | 2068 | | | 2069 | Public | Section 18.39 | 2070 | | | 2071 | Retry-After | Section 18.44 | 2072 | | | 2073 | Unsupported | Section 18.55 | 2074 | | | 2075 | WWW-Authenticate | Section 18.58 | 2076 +------------------------+--------------------+ 2078 Table 5: The RTSP response headers 2080 Response-header names can be extended reliably only in combination 2081 with a change in the protocol version. However, the usage of 2082 feature-tags in the request allows the responding party to learn the 2083 capability of the receiver of the response. A new or experimental 2084 header MAY be given the semantics of response-header if all parties 2085 in the communication recognize them to be a response-header. 2086 Unrecognized headers in responses are treated as message-headers and 2087 hence MUST be ignored. 2089 9. Message Body 2091 Request and Response messages MAY transfer a message body, if not 2092 otherwise restricted by the request method or response status code. 2093 The message body consists of the content data itself (see also 2094 Section 5.3). 2096 The SET_PARAMETER and GET_PARAMETER requests and responses, and the 2097 DESCRIBE response as defined by this specification MAY have a message 2098 body; the purpose of the message body is defined in each case. All 2099 4xx and 5xx responses MAY also have a message body to carry 2100 additional response information. Generally a message body MAY be 2101 attached to any RTSP 2.0 request or response, but the content of the 2102 message body MAY be ignored by the receiver. Extensions to this 2103 specification can specify the purpose and content of message bodies, 2104 including requiring their inclusion. 2106 In this section, both sender and recipient refer to either the client 2107 or the server, depending on who sends and who receives the message 2108 body. 2110 9.1. Message-Body Header Fields 2112 Message-body header fields define meta-information about the content 2113 data in the message body. The message-body header fields are listed 2114 in Table 6. 2116 +------------------+--------------------+ 2117 | Header | Defined in Section | 2118 +------------------+--------------------+ 2119 | Allow | Section 18.6 | 2120 | | | 2121 | Content-Base | Section 18.14 | 2122 | | | 2123 | Content-Encoding | Section 18.15 | 2124 | | | 2125 | Content-Language | Section 18.16 | 2126 | | | 2127 | Content-Length | Section 18.17 | 2128 | | | 2129 | Content-Location | Section 18.18 | 2130 | | | 2131 | Content-Type | Section 18.19 | 2132 | | | 2133 | Expires | Section 18.22 | 2134 | | | 2135 | Last-Modified | Section 18.27 | 2136 +------------------+--------------------+ 2138 Table 6: The RTSP message-body headers 2140 The extension-header mechanism allows additional message-body header 2141 fields to be defined without changing the protocol, but these fields 2142 cannot be assumed to be recognizable by the recipient. Unrecognized 2143 header fields MUST be ignored by the recipient and forwarded by 2144 proxies. 2146 9.2. Message Body 2148 An RTSP message with a message body MUST include the Content-Type and 2149 Content-Length headers. When a message body is included with a 2150 message, the data type of that content data is determined via the 2151 header fields Content-Type and Content-Encoding. 2153 Content-Type specifies the media type of the underlying data. 2154 Content-Encoding may be used to indicate any additional content 2155 codings applied to the data, usually for the purpose of data 2156 compression, that are a property of the requested resource. There is 2157 no default encoding. 2159 The Content-Length of a message is the length of the content, 2160 measured in octets. 2162 9.3. Message Body Format Negotiation 2164 The content format of the message body is provided using the Content- 2165 Type header (Section 18.19). To enable the responder of a request to 2166 determine which media type it should use, the requestor may include 2167 the Accept header (Section 18.1) in a request to identify supported 2168 media types or media type ranges suitable to the response. In cases 2169 the responder is not supporting any of the specified formats, then 2170 the request response will be a 406 (Not Acceptable) error code. 2172 The media types that may be used on requests with message bodies 2173 needs to be determined through the use of feature-tags, specification 2174 requirement or trial and error. Trial and error works in the regards 2175 that in case the responder is not supporting the media type of the 2176 message body it will respond with a 415 (Unsupported Media Type). 2178 The formats supported and their negotiation is done individually on a 2179 per method and direction (request or response body) direction. 2180 Requirements on supporting particular media types for use as message 2181 bodies in requests and response SHALL also be specified on per method 2182 and direction basis. 2184 10. Connections 2186 RTSP Messages are transferred between RTSP agents and proxies using a 2187 transport connection. This transport connection uses TCP or TCP/TLS. 2188 This transport connection is referred to as the connection or 2189 possibly RTSP connection within this document. 2191 RTSP requests can be transmitted using the two different connection 2192 scenarios listed below: 2194 o persistent - a transport connection is used for several request/ 2195 response transactions; 2197 o transient - a transport connection is used for a single request/ 2198 response transaction. 2200 RFC 2326 attempted to specify an optional mechanism for transmitting 2201 RTSP messages in connectionless mode over a transport protocol such 2202 as UDP. However, it was not specified in sufficient detail to allow 2203 for interoperable implementations. In an attempt to reduce 2204 complexity and scope, and due to lack of interest, RTSP 2.0 does not 2205 attempt to define a mechanism for supporting RTSP over UDP or other 2206 connectionless transport protocols. A side-effect of this is that 2207 RTSP requests MUST NOT be sent to multicast groups since no 2208 connection can be established with a specific receiver in multicast 2209 environments. 2211 Certain RTSP headers, such as the CSeq header (Section 18.20), which 2212 may appear to be relevant only to connectionless transport scenarios 2213 are still retained and MUST be implemented according to the 2214 specification. In the case of CSeq, it is quite useful for matching 2215 responses to requests if the requests are pipelined (see Section 12). 2216 It is also useful in proxies for keeping track of the different 2217 requests when aggregating several client requests on a single TCP 2218 connection. 2220 10.1. Reliability and Acknowledgements 2222 Since RTSP messages are transmitted using reliable transport 2223 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 2224 Instead, the implementation must rely on the underlying transport to 2225 provide reliability. The RTSP implementation may use any indication 2226 of reception acknowledgment of the message from the underlying 2227 transport protocols to optimize the RTSP behavior. 2229 If both the underlying reliable transport such as TCP and the RTSP 2230 application retransmit requests, each packet loss or message loss 2231 may result in two retransmissions. The receiver typically cannot 2232 take advantage of the application-layer retransmission since the 2233 transport stack will not deliver the application-layer 2234 retransmission before the first attempt has reached the receiver. 2235 If the packet loss is caused by congestion, multiple 2236 retransmissions at different layers will exacerbate the 2237 congestion. 2239 Lack of acknowledgment of an RTSP request should be handled within 2240 the constraints of the connection timeout considerations described 2241 below (Section 10.4). 2243 10.2. Using Connections 2245 A TCP transport can be used for both persistent connections (for 2246 several message exchanges) and transient connections (for a single 2247 message exchange). Implementations of this specification MUST 2248 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 2249 indicates the default port that the server will listen on if the port 2250 is not explicitly given. 2252 In addition to the registered default ports, i.e., 554 (rtsp) and 322 2253 (rtsps), there is an alternative port 8554 registered. This port may 2254 provide some benefits from non-registered ports if a RTSP server is 2255 unable to use the default ports. The benefits may include pre- 2256 configured security policies as well as classifiers in network 2257 monitoring tools. 2259 A RTSP client opening a TCP connection for accessing a particular 2260 resource as identified by a URI uses the IP address and port derived 2261 from the host and port parts of the URI. The IP address is either 2262 the explicit address provided in the URI or any of the addresses 2263 provided when performing A and AAAA record DNS lookups of the host 2264 name in the URI. 2266 A server MUST handle both persistent and transient connections. 2268 Transient connections facilitate mechanisms for fault tolerance. 2269 They also allow for application layer mobility. A server and 2270 client pair that support transient connections can survive the 2271 loss of a TCP connection; e.g., due to a NAT timeout. When the 2272 client has discovered that the TCP connection has been lost, it 2273 can set up a new one when there is need to communicate again. 2275 A persistent connection is RECOMMENDED to be used for all 2276 transactions between the server and client, including messages for 2277 multiple RTSP sessions. However, a persistent connection MAY be 2278 closed after a few message exchanges. For example, a client may use 2279 a persistent connection for the initial SETUP and PLAY message 2280 exchanges in a session and then close the connection. Later, when 2281 the client wishes to send a new request, such as a PAUSE for the 2282 session, a new connection would be opened. This connection may 2283 either be transient or persistent. 2285 An RTSP agent MAY use one connection to handle multiple RTSP sessions 2286 on the same server. The RTSP agent SHALL NOT use more than one 2287 connection per RTSP session at any given point. 2289 Using a single connection for multiple RTSP session saves 2290 connection resources on the server. Not using more than one 2291 connection at a time for a particular RTSP session avoids wasting 2292 connection resources and allows the server to track only for the 2293 latest in client to server used connection for each RTSP session 2294 as being the currently valid server to client connection. 2296 RTSP allows a server to send requests to a client. However, this can 2297 be supported only if a client establishes a persistent connection 2298 with the server. In cases where a persistent connection does not 2299 exist between a server and its client, due to the lack of a signaling 2300 channel the server may be forced to silently discard RTSP messages, 2301 and may even drop an RTSP session without notifying the client. An 2302 example of such a case is when the server desires to send a REDIRECT 2303 request for an RTSP session to the client but is not able to do so 2304 because it cannot reach the client. A server that attempts to send a 2305 request to a client that has no connection currently to the server 2306 SHALL discard the request directly. 2308 Without a persistent connection between the client and the server, 2309 the media server has no reliable way of reaching the client. 2310 Because the likely failure of server to client established 2311 connections the server will not even attempt establishing any 2312 connection. 2314 Queuing of server to client requests has been considered. However 2315 a security issue exist in how one authorizes a client establishing 2316 a new connection as being a legit receiver of request related to a 2317 particular RTSP session without the client first issuing requests 2318 related to the request. Thus, likely making any such requests 2319 even more delayed and less useful. 2321 The sending of client and server requests can be asynchronous events. 2322 To avoid deadlock situations both client and server MUST be able to 2323 send and receive requests simultaneously. As an RTSP response may be 2324 queued up for transmission, reception or processing behind the peer 2325 RTSP agent's own requests, all RTSP agents are required to have a 2326 certain capability of handling outstanding messages. A potential 2327 issue is that outstanding requests may timeout despite them being 2328 processed by the peer due to the response being caught in the queue 2329 behind a number of requests that the RTSP agent is processing but 2330 that take some time to complete. To avoid this problem an RTSP agent 2331 is recommended to buffer incoming messages locally so that any 2332 response messages can be processed immediately upon reception. If 2333 responses are separated from requests and directly forwarded for 2334 processing, not only can the result be used immediately, the state 2335 associated with that outstanding request can also be released. 2336 However, buffering a number of requests on the receiving RTSP agent 2337 consumes resources and enables a resource exhaustion attack on the 2338 agent. Therefore this buffer should be limited so that an 2339 unreasonable number of requests or total message size is not allowed 2340 to consume the receiving agent's resources. In most APIs, having the 2341 receiving agent stop reading from the TCP socket will result in TCP's 2342 window being clamped. Thus forcing the buffering onto the sending 2343 agent when the load is larger than expected. However, as both RTSP 2344 message sizes and frequency may be changed in the future by protocol 2345 extensions, an agent should be careful against taking harsher 2346 measurements against a potential attack. When under attack an RTSP 2347 agent can close TCP connections and release state associated with 2348 that TCP connection. 2350 To provide some guidance on what is reasonable the following 2351 guidelines are given. It is RECOMMENDED that: 2353 o an RTSP agent should not have more than 10 outstanding requests 2354 per RTSP session; 2356 o an RTSP agent should not have more than 10 outstanding requests 2357 that are not related to an RTSP session or that are requesting to 2358 create an RTSP session. 2360 In light of the above, it is RECOMMENDED that clients use persistent 2361 connections whenever possible. A client that supports persistent 2362 connections MAY "pipeline" its requests (see Section 12). 2364 RTSP Agents can send requests to multiple different destinations, 2365 either servers or client contexts over the same connection to a 2366 proxy. Then the proxy forks the message to the different 2367 destinations over proxy to agent connections. In these cases when 2368 multiple requests are outstanding the requesting agent MUST be ready 2369 to receive the responses out of order compared to the order they 2370 where sent on the connection. The order between multiple messages 2371 for each destination will be maintained, however, the order between 2372 response from different destinations can be different. 2374 The reason for this is to avoid a head of line blocking. In a 2375 sequence of request an early outstanding request may take time to 2376 be processed at one destination. Simultaneously a responses from 2377 any other destinations, that was later in the sequence of requests 2378 may have arrived at the proxy. Thus allowing out-of-order 2379 responses avoid forcing the proxy to buffer this response and 2380 instead deliver it as soon as possible. Note, this will not 2381 affect the order they where processed at request destination. 2383 This scenario can occur in two cases involving proxies. The first is 2384 a client issuing requests for sessions on different servers using a 2385 common client to proxy connection. The second is for server to 2386 client requests, like REDIRECT being sent by the server over a common 2387 transport connection the proxy created for its different connecting 2388 clients. 2390 10.3. Closing Connections 2392 The client MAY close a connection at any point when no outstanding 2393 request/response transactions exist for any RTSP session being 2394 managed through the connection. The server, however, SHOULD NOT 2395 close a connection until all RTSP sessions being managed through the 2396 connection have been timed out (Section 18.49). A server SHOULD NOT 2397 close a connection immediately after responding to a session-level 2398 TEARDOWN request for the last RTSP session being controlled through 2399 the connection. Instead, the server should wait for a reasonable 2400 amount of time for the client to receive and act upon the TEARDOWN 2401 response, and initiate the connection closing. The server SHOULD 2402 wait at least 10 seconds after sending the TEARDOWN response before 2403 closing the connection. 2405 This is to ensure that the client has time to issue a SETUP for a 2406 new session on the existing connection after having torn the last 2407 one down. 10 seconds should give the client ample opportunity to 2408 get its message to the server. 2410 A server SHOULD NOT close the connection directly as a result of 2411 responding to a request with an error code. 2413 Certain error responses such as "460 Only Aggregate Operation 2414 Allowed" (Section 17.4.24) are used for negotiating capabilities 2415 of a server with respect to content or other factors. In such 2416 cases, it is inefficient for the server to close a connection on 2417 an error response. Also, such behavior would prevent 2418 implementation of advanced/special types of requests or result in 2419 extra overhead for the client when testing for new features. On 2420 the other hand, keeping connections open after sending an error 2421 response poses a Denial of Service security risk (Section 21). 2423 The server MAY close a connection if it receives an incomplete 2424 message and if the message is not completed within a reasonable 2425 amount of time. It is RECOMMENDED that the server waits at least 10 2426 seconds for the completion of a message or for the next part of the 2427 message to arrive (which is an indication that the transport and the 2428 client are still alive). Servers believing they are under attack or 2429 otherwise starved for resources during that event MAY consider using 2430 a shorter timeout. 2432 If a server closes a connection while the client is attempting to 2433 send a new request, the client will have to close its current 2434 connection, establish a new connection and send its request over the 2435 new connection. 2437 An RTSP message SHOULD NOT be terminated by closing the connection. 2438 Such a message MAY be considered to be incomplete by the receiver and 2439 discarded. An RTSP message is properly terminated as defined in 2440 Section 5. 2442 10.4. Timing Out Connections and RTSP Messages 2444 Receivers of a request (responder) SHOULD respond to requests in a 2445 timely manner even when a reliable transport such as TCP is used. 2446 Similarly, the sender of a request (requester) SHOULD wait for a 2447 sufficient time for a response before concluding that the responder 2448 will not be acting upon its request. 2450 A responder SHOULD respond to all requests within 5 seconds. If the 2451 responder recognizes that processing of a request will take longer 2452 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 2453 possible. It SHOULD continue sending a 100 response every 5 seconds 2454 thereafter until it is ready to send the final response to the 2455 requester. After sending a 100 response, the receiver MUST send a 2456 final response indicating the success or failure of the request. 2458 A requester SHOULD wait at least 10 seconds for a response before 2459 concluding that the responder will not be responding to its request. 2460 After receiving a 100 response, the requester SHOULD continue waiting 2461 for further responses. If more than 10 seconds elapses without 2462 receiving any response, the requester MAY assume that the responder 2463 is unresponsive and abort the connection by closing the TCP 2464 connection. 2466 Note: In cases multiple RTSP sessions share the same transport 2467 connection, abandoning a request closing the connection may have 2468 significant impact on those other sessions. First of all, other 2469 RTSP requests may have become queued up due to the request taking 2470 long time. Secondly also those sessions loose the possibility to 2471 receive server to client requests. To mitigate that situation the 2472 RTSP agent should establish a new connection and send any queued 2473 up and non-responded requests on this new connection. Secondly, 2474 to ensure that the RTSP server knows which connection that is 2475 valid for a particular RTSP session, the RTSP agent should send a 2476 keep-alive request, if no other request will be sent immediately 2477 for that RTSP session, for each RTSP session on the old 2478 connection. The keep-alive request will normally be a 2479 GET_PARAMETER with a session header to inform the server that this 2480 agent cares about this RTSP session. 2482 A requester SHOULD wait longer than 10 seconds for a response if it 2483 is experiencing significant transport delays on its connection to the 2484 responder. The requester is capable of determining the round trip 2485 time (RTT) of the request/response cycle using the Timestamp header 2486 (Section 18.53) in any RTSP request. 2488 10 seconds was chosen for the following reasons. It gives TCP 2489 time to perform a couple of retransmissions, even if operating on 2490 default values. It is short enough that users may not abandon the 2491 process themselves. However, it should be noted that 10 seconds 2492 can be aggressive on certain type of networks. The 5 seconds 2493 value for 1xx messages is half the timeout giving a reasonable 2494 chance of successful delivery before timeout happens on the 2495 requester side. 2497 10.5. Showing Liveness 2499 The mechanisms for showing liveness of the client is, any RTSP 2500 request with a Session header, if RTP & RTCP is used an RTCP message, 2501 or through any other used media protocol capable of indicating 2502 liveness of the RTSP client. It is RECOMMENDED that a client does 2503 not wait to the last second of the timeout before trying to send a 2504 liveness message. The RTSP message may be lost or when using 2505 reliable protocols, such as TCP, the message may take some time to 2506 arrive safely at the receiver. To show liveness between RTSP 2507 requests being issued to accomplish other things, the following 2508 mechanisms can be used, in descending order of preference: 2510 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 2511 RTCP is used to report transport statistics, it will 2512 necessarily also function as a keep-alive. The server can 2513 determine the client by network address and port together with 2514 the fact that the client is reporting on the server's RTP 2515 sender sources (SSRCs). A downside of using RTCP is that it 2516 only gives statistical guarantees of reaching the server. 2517 However, the probability of a false client timeout is so low 2518 that it can be ignored in most cases. For example, assume a 2519 session with 60 seconds timeout and enough bitrate assigned to 2520 RTCP messages to send a message from client to server on 2521 average every 5 seconds. That client has, for a network with 2522 5% packet loss, a probability of failing to confirm liveness 2523 within the timeout interval for that session of 2.4*E-16. 2524 Sessions with shorter timeouts, or much higher packet loss, or 2525 small RTCP bandwidths SHOULD also implement one or more of the 2526 mechanisms below. 2528 SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body 2529 SHOULD NOT be included. This method is the RECOMMENDED RTSP 2530 method to use for a request intended only to perform keep- 2531 alive. Support of SET_PARAMETER is mandatory for RTSP Servers 2532 to ensure clients can use this method. 2534 GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body 2535 SHOULD be included. Dependent on implementation support in 2536 server. 2538 OPTIONS: This method is also usable, but it causes the server to 2539 perform more unnecessary processing and results in bigger 2540 responses than necessary for the task. The reason is that the 2541 server needs to determine the capabilities associated with the 2542 media resource to correctly populate the Public and Allow 2543 headers. 2545 The timeout parameter of the Session header (Section 18.49) MAY be 2546 included in a SETUP response, and MUST NOT be included in requests. 2547 The server uses it to indicate to the client how long the server is 2548 prepared to wait between RTSP commands or other signs of life before 2549 closing the session due to lack of activity (see Appendix B). The 2550 timeout is measured in seconds, with a default of 60 seconds. The 2551 length of the session timeout MUST NOT be changed in an established 2552 session. 2554 10.6. Use of IPv6 2556 Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC 2557 2326). RTSP 2.0 has been updated for explicit IPv6 support. 2558 Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in 2559 URIs and RTSP headers. Although the general URI format envisages 2560 potential future new versions of the literal IP address, usage of any 2561 such new version would require other modifications to the RTSP 2562 specification (e.g. address fields in the Transport header 2563 (Section 18.54)). 2565 10.7. Overload Control 2567 Overload in RTSP can occur when servers and proxies have insufficient 2568 resources to complete the processing of a request. An improper 2569 handling of such an overload situation at proxies and servers can 2570 impact the operation of the RTSP deployment, and probably worsen the 2571 situation. RTSP defines the 503 (Service Unavailable) response 2572 (Section 17.5.4) to let servers and proxies notify requesting proxies 2573 and RTSP clients about an overload situation. In conjunction with 2574 the Retry-After header (Section 18.44) the server or proxy can 2575 indicate the time after the requesting entity can send another 2576 request to the proxy or server. 2578 There are two scopes of such 503 answers, one for established RTSP 2579 sessions, where the request resulting in the 503 response as well as 2580 the response carries a Session header identifying the session which 2581 is suffering overload. This response only applies to this particular 2582 session. The other scope is the general RTSP server as identified by 2583 the host in the request URL. Such a 503 answer with any Retyr-After 2584 header applies to all non-session specific requests to that server, 2585 including SETUP request intended to create a new RTSP session. 2587 Another scope for overload situation exists, which is the RTSP proxy. 2588 To enable an RTSP proxy to signal that it is overloaded, or otherwise 2589 unavailable and can't handle the request, a 553 response code has 2590 been defined with the meaning "Proxy Unavailable". Also for proxies 2591 there is a separation in response scopes between requests associated 2592 with existing RTSP sessions, and requests to create new sessions or 2593 general proxy requests. 2595 Simply implementing and using the 503 (Service Unavailable) and 553 2596 (Proxy Unavailable) is not sufficient for properly handling overload 2597 situations. For instance, a simplistic approach would be to send the 2598 503 response with a Retry-After header set to a fixed value. 2599 However, this can cause the situation where multiple RTSP clients 2600 again send requests to a proxy or server at roughly the same time 2601 which may again cause an overload situation, or if the "old" overload 2602 situation is not yet solved, i.e., the length indicated in the Retry- 2603 After header was too short. 2605 An RTSP server or proxy in an overload situation must select the 2606 value of the Retry-After header carefully and bearing in mind its 2607 current load situation. It is REQUIRED to increase the timeout 2608 period in proportion to the current load on the server, i.e., an 2609 increasing workload should result in an increased length of the 2610 indicated unavailability. It is REQUIRED to not send the same value 2611 in the Retry-After header to all requesting proxies and clients, but 2612 to add a variation to the mean value of the Retry-After header. 2614 A more complex case may arise when a load balancing RTSP proxy is in 2615 use, i.e., where an RTSP proxy is used to select amongst a set of 2616 RTSP servers to handle the requests, or when multiple server 2617 addresses are available for a given server name. The proxy or client 2618 may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) 2619 from one of its RTSP servers or proxies, or a TCP timeout (if the 2620 server is even unable to handle the request message). The proxy or 2621 client simply retries the other addresses or configured proxies, but 2622 may also receive a 503 (Service Unavailable) or 553 (Proxy 2623 Unavailable) response or TCP timeouts from those addresses. In such 2624 a situation, where none of the RTSP servers/proxies/addresses can 2625 handle the request, the RTSP agent has to wait before it can send any 2626 new requests to the RTSP server. Any additional request to a 2627 specific address MUST be delayed according to the Retry-After headers 2628 received. For addresses where no response was received or TCP 2629 timeout occurred, an initial wait timer SHOULD be set to 5 seconds. 2630 That timer MUST be doubled for each additional failure to connect or 2631 receive response until the value exceeds 30 minutes when the timers 2632 mean value may be set to 30 minutes. It is REQUIRED to not set the 2633 same value in the timer for each scheduling, but instead to add a 2634 variation to the mean value, resulting in picking a random value 2635 within the range of 0.5 to 1.5 of the mean value. 2637 11. Capability Handling 2639 This section describes the available capability handling mechanism 2640 which allows RTSP to be extended. Extensions to this version of the 2641 protocol are basically done in two ways. First, new headers can be 2642 added. Secondly, new methods can be added. The capability handling 2643 mechanism is designed to handle both cases. 2645 When a method is added, the involved parties can use the OPTIONS 2646 method to discover whether it is supported. This is done by issuing 2647 an OPTIONS request to the other party. Depending on the URI it will 2648 either apply in regards to a certain media resource, the whole server 2649 in general, or simply the next hop. The OPTIONS response MUST 2650 contain a Public header which declares all methods supported for the 2651 indicated resource. 2653 It is not necessary to use OPTIONS to discover support of a method, 2654 as the client could simply try the method. If the receiver of the 2655 request does not support the method it will respond with an error 2656 code indicating the method is either not implemented (501) or does 2657 not apply for the resource (405). The choice between the two 2658 discovery methods depends on the requirements of the service. 2660 Feature-tags are defined to handle functionality additions that are 2661 not new methods. Each feature-tag represents a certain block of 2662 functionality. The amount of functionality that a feature-tag 2663 represents can vary significantly. A feature-tag can for example 2664 represent the functionality a single RTSP header provides. Another 2665 feature-tag can represent much more functionality, such as the 2666 "play.basic" feature-tag (Section 11.1) which represents the minimal 2667 media delivery for playback implementation. 2669 Feature-tags are used to determine whether the client, server or 2670 proxy supports the functionality that is necessary to achieve the 2671 desired service. To determine support of a feature-tag, several 2672 different headers can be used, each explained below: 2674 Supported: This header is used to determine the complete set of 2675 functionality that both client and server have in general and 2676 is not dependent on specific resource. The intended usage is 2677 to determine before one needs to use a functionality that it is 2678 supported. It can be used in any method, but OPTIONS is the 2679 most suitable one as it at the same time determines all methods 2680 that are implemented. When sending a request the requester 2681 declares all its capabilities by including all supported 2682 feature-tags. This results in the receiver is learning the 2683 requester's feature support. The receiver then includes its 2684 set of features in the response. 2686 Proxy-Supported: This header is used similarly to the Supported 2687 header, but instead of giving the supported functionality of 2688 the client or server it provides both the requester and the 2689 responder a view of the common functionality supported in 2690 general by all members of the proxy chain between the two 2691 supports and not dependent on the resource. Proxies are 2692 required to add this header whenever the Supported header is 2693 present, but proxies may also add it independently of the 2694 requester. 2696 Require: This header can be included in any request where the end- 2697 point, i.e., the client or server, is required to understand 2698 the feature to correctly perform the request. This can, for 2699 example, be a SETUP request where the server is required to 2700 understand a certain parameter to be able to set up the media 2701 delivery correctly. Ignoring this parameter would not have the 2702 desired effect and is not acceptable. Therefore the end-point 2703 receiving a request containing a Require MUST negatively 2704 acknowledge any feature that it does not understand and not 2705 perform the request. The response in cases where features are 2706 not supported are 551 (Option Not Supported). Also the 2707 features that are not supported are given in the Unsupported 2708 header in the response. 2710 Proxy-Require: This header has the same purpose and workings as 2711 Require except that it only applies to proxies and not the end- 2712 point. Features that need to be supported by both proxies and 2713 end-points need to be included in both the Require and Proxy- 2714 Require header. 2716 Unsupported: This header is used in a 551 error response, to 2717 indicate which features were not supported. Such a response is 2718 only the result of the usage of the Require and/or Proxy- 2719 Require header where one or more features where not supported. 2720 This information allows the requester to make the best of 2721 situations as it knows which features are not supported. 2723 11.1. Feature Tag: play.basic 2725 The play.basic feature tag represents an RTSP implementation 2726 according to all normative RTSP protocol features specified in this 2727 specification. This specification is both a RTSP core specification 2728 as well intended to enable setup and control of playback of media. 2729 Thus following all normative parts in the main sections (the ones 2730 with numbers), not the appendices (starting with letters), unless 2731 explicitly specified in a main section for being a required appendix. 2733 Note: This feature tag does not mandate any media delivery 2734 protocol, such as RTP. 2736 In RTSP 1.0 there was a minimal implementation section. However, 2737 that was not consistent with the rest of the specification. So 2738 rather than making an attempt to explicitly enumerate the features 2739 for play.basic this specification have to be read in completeness 2740 and the necessary features normatively defined as being required 2741 are included. 2743 12. Pipelining Support 2745 Pipelining is a general method to improve performance of request 2746 response protocols by allowing the requesting agent to have more than 2747 one request outstanding and send them over the same persistent 2748 connection. For RTSP, where the relative order of requests will 2749 matter, it is important to maintain the order of the requests. 2750 Because of this, the responding agent MUST process the incoming 2751 requests in their sending order. The sending order can be determined 2752 by the CSeq header and its sequence number. For TCP the delivery 2753 order will be the same between two agents, as the sending order. The 2754 processing of the request MUST also have been finished before 2755 processing the next request from the same agent. The responses MUST 2756 be sent in the order the requests were processed. 2758 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2759 The major improvement is to allow all requests involved in setting up 2760 and initiating media delivery to be pipelined after each other. This 2761 is accomplished by the utilization of the Pipelined-Requests header 2762 (see Section 18.33). This header allows a client to request that two 2763 or more requests are processed in the same RTSP session context which 2764 the first request creates. In other words, a client can request that 2765 two or more media streams are set-up and then played without needing 2766 to wait for a single response. This speeds up the initial startup 2767 time for an RTSP session by at least one RTT. 2769 If a pipelined request builds on the successful completion of one or 2770 more prior requests the requester must verify that all requests were 2771 executed as expected. A common example will be two SETUP requests 2772 and a PLAY request. In case one of the SETUP fails unexpectedly, the 2773 PLAY request can still be successfully executed. However, the 2774 resulting presentation will not be as expected by the requesting 2775 client, as only a single media instead of two will be played. In 2776 this case the client can send a PAUSE request, correct the failing 2777 SETUP request and then request it to be played. 2779 13. Method Definitions 2781 The method indicates what is to be performed on the resource 2782 identified by the Request-URI. The method name is case-sensitive. 2783 New methods may be defined in the future. Method names MUST NOT 2784 start with a $ character (decimal 36) and MUST be a token as defined 2785 by the ABNF [RFC5234] in the syntax chapter Section 20. The methods 2786 are summarized in Table 7. 2788 +---------------+-----------+--------+-------------+-------------+ 2789 | method | direction | object | Server req. | Client req. | 2790 +---------------+-----------+--------+-------------+-------------+ 2791 | DESCRIBE | C -> S | P,S | recommended | recommended | 2792 | | | | | | 2793 | GET_PARAMETER | C -> S | P,S | optional | optional | 2794 | | | | | | 2795 | | S -> C | P,S | optional | optional | 2796 | | | | | | 2797 | OPTIONS | C -> S | P,S | required | required | 2798 | | | | | | 2799 | | S -> C | P,S | optional | optional | 2800 | | | | | | 2801 | PAUSE | C -> S | P,S | required | required | 2802 | | | | | | 2803 | PLAY | C -> S | P,S | required | required | 2804 | | | | | | 2805 | PLAY_NOTIFY | S -> C | P,S | required | required | 2806 | | | | | | 2807 | REDIRECT | S -> C | P,S | optional | required | 2808 | | | | | | 2809 | SETUP | C -> S | S | required | required | 2810 | | | | | | 2811 | SET_PARAMETER | C -> S | P,S | required | optional | 2812 | | | | | | 2813 | | S -> C | P,S | optional | optional | 2814 | | | | | | 2815 | TEARDOWN | C -> S | P,S | required | required | 2816 | | | | | | 2817 | | S -> C | P | required | required | 2818 +---------------+-----------+--------+-------------+-------------+ 2820 Table 7: Overview of RTSP methods, their direction, and what objects 2821 (P: presentation, S: stream) they operate on. Further it indicates if 2822 a server or a client implementation are required (mandatory), 2823 recommended or if it is optional to implement the method. 2825 Note on Table 7: GET_PARAMETER is optional. For example, a fully 2826 functional server can be built to deliver media without any 2827 parameters. However, SET_PARAMETER is required, i.e. mandatory to 2828 implement for the server, this is due to its usage for keep-alive. 2829 PAUSE is required because it is the only way of leaving the Play 2830 state without terminating the whole session. 2832 If an RTSP agent does not support a particular method, it MUST return 2833 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2834 NOT try this method again for the given agent / resource combination. 2835 An RTSP proxy whose main function is to log or audit and not modify 2836 transport or media handling in any way MAY forward RTSP messages with 2837 unknown methods. Note that the proxy still needs to perform the 2838 minimal required processing, like adding the Via header. 2840 13.1. OPTIONS 2842 The semantics of the RTSP OPTIONS method is similar to that of the 2843 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2844 bi-directional, in that a client can send the request to a server and 2845 vice versa. A client MUST implement the capability to send an 2846 OPTIONS request and a server or a proxy MUST implement the capability 2847 to respond to an OPTIONS request. In addition to this "MUST 2848 implement" functionality, clients, servers and proxies MAY provide 2849 support both for sending OPTIONS requests and generating responses to 2850 the requests. 2852 An OPTIONS request may be issued at any time. Such a request does 2853 not modify the session state. However, it may prolong the session 2854 lifespan (see below). The URI in an OPTIONS request determines the 2855 scope of the request and the corresponding response. If the Request- 2856 URI refers to a specific media resource on a given host, the scope is 2857 limited to the set of methods supported for that media resource by 2858 the indicated RTSP agent. A Request-URI with only the host address 2859 limits the scope to the specified RTSP agent's general capabilities 2860 without regard to any specific media. If the Request-URI is an 2861 asterisk ("*"), the scope is limited to the general capabilities of 2862 the next hop (i.e., the RTSP agent in direct communication with the 2863 request sender). 2865 Regardless of the scope of the request, the Public header MUST always 2866 be included in the OPTIONS response listing the methods that are 2867 supported by the responding RTSP agent. In addition, if the scope of 2868 the request is limited to a media resource, the Allow header MUST be 2869 included in the response to enumerate the set of methods that are 2870 allowed for that resource unless the set of methods completely 2871 matches the set in the Public header. If the given resource is not 2872 available, the RTSP agent SHOULD return an appropriate response code 2873 such as 3rr or 4xx. The Supported header MAY be included in the 2874 request to query the set of features that are supported by the 2875 responding RTSP agent. 2877 The OPTIONS method can be used to keep an RTSP session alive. 2878 However, this is not the preferred way of session keep-alive 2879 signaling, see Section 18.49. An OPTIONS request intended for 2880 keeping alive an RTSP session MUST include the Session header with 2881 the associated session identifier. Such a request SHOULD also use 2882 the media or the aggregated control URI as the Request-URI. 2884 Example: 2886 C->S: OPTIONS rtsp://server.example.com RTSP/2.0 2887 CSeq: 1 2888 User-Agent: PhonyClient/1.2 2889 Proxy-Require: gzipped-messages 2890 Supported: play.basic 2892 S->C: RTSP/2.0 200 OK 2893 CSeq: 1 2894 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS 2895 Supported: play.basic, setup.rtp.rtcp.mux, play.scale 2896 Server: PhonyServer/1.1 2898 Note that some of the feature-tags in Supported and Proxy-Require are 2899 fictitious features. 2901 13.2. DESCRIBE 2903 The DESCRIBE method is used to retrieve the description of a 2904 presentation or media object from a server. The Request-URI of the 2905 DESCRIBE request identifies the media resource of interest. The 2906 client MAY include the Accept header in the request to list the 2907 description formats that it understands. The server MUST respond 2908 with a description of the requested resource and return the 2909 description in the message body of the response, if the DESCRIBE 2910 method request can be successfully fulfilled. The DESCRIBE reply- 2911 response pair constitutes the media initialization phase of RTSP. 2913 The DESCRIBE response SHOULD contain all media initialization 2914 information for the resource(s) that it describes. Servers SHOULD 2915 NOT use the DESCRIBE response as a means of media indirection by 2916 having the description point at another server; instead, using the 2917 3rr responses is RECOMMENDED. 2919 By forcing a DESCRIBE response to contain all media initialization 2920 information for the set of streams that it describes, and 2921 discouraging the use of DESCRIBE for media indirection, any 2922 looping problems can be avoided that might have resulted from 2923 other approaches. 2925 Example: 2927 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2928 CSeq: 312 2929 User-Agent: PhonyClient/1.2 2930 Accept: application/sdp, application/example 2932 S->C: RTSP/2.0 200 OK 2933 CSeq: 312 2934 Date: Thu, 23 Jan 1997 15:35:06 GMT 2935 Server: PhonyServer/1.1 2936 Content-Base: rtsp://server.example.com/fizzle/foo/ 2937 Content-Type: application/sdp 2938 Content-Length: 358 2940 v=0 2941 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46 2942 s=SDP Seminar 2943 i=A Seminar on the session description protocol 2944 u=http://www.example.com/lectures/sdp.ps 2945 e=seminar@example.com (Seminar Management) 2946 c=IN IP4 0.0.0.0 2947 a=control:* 2948 t=2873397496 2873404696 2949 m=audio 3456 RTP/AVP 0 2950 a=control:audio 2951 m=video 2232 RTP/AVP 31 2952 a=control:video 2954 Media initialization is a requirement for any RTSP-based system, but 2955 the RTSP specification does not dictate that this is required to be 2956 done via the DESCRIBE method. There are three ways that an RTSP 2957 client may receive initialization information: 2959 o via an RTSP DESCRIBE request 2961 o via some other protocol (HTTP, email attachment, etc.) 2963 o via some form of user interface 2965 If a client obtains a valid description from an alternate source, the 2966 client MAY use this description for initialization purposes without 2967 issuing a DESCRIBE request for the same media. The client should use 2968 any MTag to either validate the presentation description or make the 2969 session establishment conditional on being valid. 2971 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2972 and highly recommended that minimal clients support the ability to 2973 act as "helper applications" that accept a media initialization file 2974 from a user interface, and/or other means that are appropriate to the 2975 operating environment of the clients. 2977 13.3. SETUP 2979 The below description uses the following states in a protocol state 2980 machine that are related to a specific session when that session has 2981 been created. The state transitions are driven by protocol 2982 interactions. For additional information about the state machine see 2983 Appendix B. 2985 Init: Initial state: no session exists. 2987 Ready: Session is ready to start playing. 2989 Play: Session is playing, i.e., sending media stream data in the 2990 direction S->C. 2992 The SETUP request for an URI specifies the transport mechanism to be 2993 used for the streamed media. The SETUP method may be used in two 2994 different cases; Create an RTSP session and change the transport 2995 parameters of already set up media stream(s). SETUP can be used in 2996 all three states; Init, and Ready, for both purposes and in PLAY to 2997 change the transport parameters. There is also a third possible 2998 usage for the SETUP method which is not specified in this memo: 2999 adding a media to a session. Using SETUP to add media to an existing 3000 session, when the session is in Play state, is unspecified. 3002 The Transport header, see Section 18.54, specifies the media 3003 transport parameters acceptable to the client for data transmission; 3004 the response will contain the transport parameters selected by the 3005 server. This allows the client to enumerate in descending order of 3006 preference the transport mechanisms and parameters acceptable to it, 3007 while the server can select the most appropriate. It is expected 3008 that the session description format used will enable the client to 3009 select a limited number of possible configurations that are offered 3010 to the server to choose from. All transport related parameters SHALL 3011 be included in the Transport header; the use of other headers for 3012 this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls 3013 or NATs. 3015 For the benefit of any intervening firewalls, a client MUST indicate 3016 the known transport parameters, even if it has no influence over 3017 these parameters, for example, where the server advertises a fixed 3018 multicast address as destination. 3020 Since SETUP includes all transport initialization information, 3021 firewalls and other intermediate network devices (which need this 3022 information) are spared the more arduous task of parsing the 3023 DESCRIBE response, which has been reserved for media 3024 initialization. 3026 The client MUST include the Accept-Ranges header in the request 3027 indicating all supported unit formats in the Range header. This 3028 allows the server to know which formats it may use in future session 3029 related responses, such as a PLAY response without any range in the 3030 request. If the client does not support a time format necessary for 3031 the presentation, the server MUST respond using 456 (Header Field Not 3032 Valid for Resource) and include the Accept-Ranges header with the 3033 range unit formats supported for the resource. 3035 In a SETUP response the server MUST include the Accept-Ranges header 3036 (see Section 18.5) to indicate which time formats are acceptable to 3037 use for this media resource. 3039 The SETUP response 200 OK MUST include the Media-Properties header 3040 (see Section 18.29 ). The combination of the parameters of the 3041 Media-Properties header indicates the nature of the content present 3042 in the session (see also Section 4.7). For example, a live stream 3043 with time shifting is indicated by 3045 o Random Access set to Random-Access, 3047 o Content Modifications set to Time Progressing, 3049 o Retention set to Time-Duration (with specific recording window 3050 time value). 3052 The SETUP response 200 OK MUST include the Media-Range header (see 3053 Section 18.30) if the media is Time-Progressing. 3055 A basic example for SETUP: 3057 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 3058 CSeq: 302 3059 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 3060 RTP/AVP/TCP;unicast;interleaved=0-1 3061 Accept-Ranges: npt, clock 3062 User-Agent: PhonyClient/1.2 3064 S->C: RTSP/2.0 200 OK 3065 CSeq: 302 3066 Date: Thu, 23 Jan 1997 15:35:06 GMT 3067 Server: PhonyServer/1.1 3068 Session: 47112344;timeout=60 3069 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ 3070 "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ 3071 "198.51.100.241:6257"; ssrc=2A3F93ED 3072 Accept-Ranges: npt 3073 Media-Properties: Random-Access=3.2, Time-Progressing, 3074 Time-Duration=3600.0 3075 Media-Range: npt=0-2893.23 3077 In the above example the client wants to create an RTSP session 3078 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 3079 The transport parameters acceptable to the client are either RTP/AVP/ 3080 UDP (UDP per default) to be received on client port 4588 and 4589 at 3081 the address the RTSP setup connection comes from or RTP/AVP 3082 interleaved on the RTSP control channel. The server selects the RTP/ 3083 AVP/UDP transport and adds the address and ports it will send and 3084 receive RTP and RTCP from, and the RTP SSRC that will be used by the 3085 server. 3087 The server MUST generate a session identifier in response to a 3088 successful SETUP request, unless a SETUP request to a server includes 3089 a session identifier or a Pipelined-Requests header referencing an 3090 existing session context, in which case the server MUST bundle this 3091 SETUP request into the existing session (aggregated session) or 3092 return error 459 (Aggregate Operation Not Allowed) (see 3093 Section 17.4.23). An Aggregate control URI MUST be used to control 3094 an aggregated session. This URI MUST be different from the stream 3095 control URIs of the individual media streams included in the 3096 aggregate (see Section 13.4.2 for aggregated sessions and for the 3097 particular URIs see Appendix D.1.1). The Aggregate control URI is to 3098 be specified by the session description if the server supports 3099 aggregated control and aggregated control is desired for the session. 3100 However, even if aggregated control is offered the client MAY chose 3101 to not set up the session in aggregated control. If an Aggregate 3102 control URI is not specified in the session description, it is 3103 normally an indication that non-aggregated control should be used. 3104 The SETUP of media streams in an aggregate which has not been given 3105 an aggregated control URI is unspecified. 3107 While the session ID sometimes carries enough information for 3108 aggregate control of a session, the Aggregate control URI is still 3109 important for some methods such as SET_PARAMETER where the control 3110 URI enables the resource in question to be easily identified. The 3111 Aggregate control URI is also useful for proxies, enabling them to 3112 route the request to the appropriate server, and for logging, 3113 where it is useful to note the actual resource that a request was 3114 operating on. 3116 A session will exist until it is either removed by a TEARDOWN request 3117 or is timed-out by the server. The server MAY remove a session that 3118 has not demonstrated liveness signs from the client(s) within a 3119 certain timeout period. The default timeout value is 60 seconds; the 3120 server MAY set this to a different value and indicate so in the 3121 timeout field of the Session header in the SETUP response. For 3122 further discussion see Section 18.49. Signs of liveness for an RTSP 3123 session are: 3125 o Any RTSP request from a client which includes a Session header 3126 with that session's ID. 3128 o If RTP is used as a transport for the underlying media streams, an 3129 RTCP sender or receiver report from the client(s) for any of the 3130 media streams in that RTSP session. RTCP Sender Reports may for 3131 example be received in sessions where the server is invited into a 3132 conference session and is valid for keep-alive. 3134 If a SETUP request on a session fails for any reason, the session 3135 state, as well as transport and other parameters for associated 3136 streams MUST remain unchanged from their values as if the SETUP 3137 request had never been received by the server. 3139 13.3.1. Changing Transport Parameters 3141 A client MAY issue a SETUP request for a stream that is already set 3142 up or playing in the session to change transport parameters, which a 3143 server MAY allow. If it does not allow changing of parameters, it 3144 MUST respond with error 455 (Method Not Valid In This State). The 3145 reasons to support changing transport parameters include allowing 3146 application layer mobility and flexibility to utilize the best 3147 available transport as it becomes available. If a client receives a 3148 455 when trying to change transport parameters while the server is in 3149 Play state, it MAY try to put the server in Ready state using PAUSE, 3150 before issuing the SETUP request again. If that also fails the 3151 changing of transport parameters will require that the client 3152 performs a TEARDOWN of the affected media and then to set it up 3153 again. For an aggregated session avoiding tearing down all the media 3154 at the same time will avoid the creation of a new session. 3156 All transport parameters MAY be changed. However, the primary usage 3157 expected is to either change the transport protocol completely, like 3158 switching from Interleaved TCP mode to UDP or vice versa, or to 3159 change the delivery address. 3161 In a SETUP response for a request to change the transport parameters 3162 while in Play state, the server MUST include the Range to indicate at 3163 what point the new transport parameters will be used. Further, if 3164 RTP is used for delivery, the server MUST also include the RTP-Info 3165 header to indicate at what timestamp and RTP sequence number the 3166 change will take place. If both RTP-Info and Range are included in 3167 the response the "rtp_time" parameter and start point in the Range 3168 header MUST be for the corresponding time, i.e., be used in the same 3169 way as for PLAY to ensure the correct synchronization information is 3170 available. 3172 If the transport parameters change while in Play state results in a 3173 change of synchronization related information, for example changing 3174 RTP SSRC, the server MUST provide in the SETUP response the necessary 3175 synchronization information. However, the server is RECOMMENDED to 3176 avoid changing the synchronization information if possible. 3178 13.4. PLAY 3180 This section describes the usage of the PLAY method in general, for 3181 aggregated sessions, and in different usage scenarios. 3183 13.4.1. General Usage 3185 The PLAY method tells the server to start sending data via the 3186 mechanism specified in SETUP and which part of the media should be 3187 played out. PLAY requests are valid when the session is in Ready or 3188 Play states. A PLAY request MUST include a Session header to 3189 indicate which session the request applies to. 3191 Upon receipt of the PLAY request, the server MUST position the normal 3192 play time to the beginning of the range specified in the received 3193 Range header, within the limits of the media resource and in 3194 accordance with the Seek-Style header (Section 18.47) and deliver 3195 stream data until the end of the range if given, until a new PLAY 3196 request is received, or until the end of the media is reached. If no 3197 Range header is present in the PLAY request the server SHALL play 3198 from current pause point until the end of media. The pause point 3199 defaults at session start to the beginning of the media. For media 3200 that is time-progressing and has no retention, the pause point will 3201 always be set equal to NPT "now", i.e., the current delivery point. 3202 The pause point may also be set to a particular point in the media by 3203 the PAUSE method, see Section 13.6. The pause point for media that 3204 is currently playing is equal to the current media position. For 3205 time-progressing media with time-limited retention, if the pause 3206 point represents a position that is older than what is retained by 3207 the server, the pause point will be moved to the oldest retained. 3209 What range values are valid depends on the type of content. For 3210 content that isn't time progressing the range value is valid if the 3211 given range is part of any media within the aggregate. In other 3212 words the valid media range for the aggregate is the union of all of 3213 the media components in the aggregate. If a given range value points 3214 outside of the media, the response MUST be the 457 (Invalid Range) 3215 error code and include the Media-Range header (Section 18.30) with 3216 the valid range for the media. Except for time progressing content 3217 where the client requests a start point prior to what is retained, 3218 the start point is adjusted to the oldest retained content. For a 3219 start point that is beyond the media front edge, i.e., beyond the 3220 current value for "now", the server SHALL adjust the start value to 3221 the current front edge. The Range header's stop point value may 3222 point beyond the current media edge. In that case, the server SHALL 3223 deliver media from the requested (and possibly adjusted) start point 3224 until the provided stop point, or the end of the media is reached 3225 prior to the specified stop point. Please note that if one simply 3226 wants to play from a particular start point until the end of media 3227 using a Range header with an implicit stop point is RECOMMENDED. 3229 If a client requests to start playing at the end of media, either 3230 explicitly with a Range header or implicitly with a pause point that 3231 is at the end of media, a 457 (Invalid Range) error MUST be sent and 3232 include the Media-Range header (Section 18.30). It is specified 3233 below that the Range header also must be included in the response and 3234 that it will carry the pause point in the media, in the case of the 3235 session being in Ready State. Note that this also applies if the 3236 pause point or requested start point is at the beginning of the media 3237 and a Scale header (Section 18.46) is included with a negative value 3238 (playing backwards). 3240 For media with random access properties a client may express its 3241 preference on which policy for start point selection the server shall 3242 use. This is done by including the Seek-Style header (Section 18.47) 3243 in the PLAY request. The Seek-Style applied will effect the content 3244 of the Range header as it will be adjusted to indicate from what 3245 point the media actually is delivered. 3247 A client desiring to play the media from the beginning MUST send a 3248 PLAY request with a Range header pointing at the beginning, e.g., 3249 "npt=0-". If a PLAY request is received without a Range header and 3250 media delivery has stopped at the end, the server SHOULD respond with 3251 a 457 "Invalid Range" error response. In that response, the current 3252 pause point MUST be included in a Range header. 3254 All range specifiers in this specification allow for ranges with an 3255 implicit start point (e.g., "npt=-30"). When used in a PLAY request, 3256 the server treats this as a request to start or resume delivery from 3257 the current pause point, ending at the end time specified in the 3258 Range header. If the pause point is located later than the given end 3259 value, a 457 (Invalid Range) response MUST be given. 3261 The example below will play seconds 10 through 25. It also requests 3262 the server to deliver media from the first Random Access Point prior 3263 to the indicated start point. 3265 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 3266 CSeq: 835 3267 Session: 12345678 3268 Range: npt=10-25 3269 Seek-Style: RAP 3270 User-Agent: PhonyClient/1.2 3272 Servers MUST include a "Range" header in any PLAY response, even if 3273 no Range header was present in the request. The response MUST use 3274 the same format as the request's range header contained. If no Range 3275 header was in the request, the format used in any previous PLAY 3276 request within the session SHOULD be used. If no format has been 3277 indicated in a previous request the server MAY use any time format 3278 supported by the media and indicated in the Accept-Ranges header in 3279 the SETUP request. It is RECOMMENDED that NPT is used if supported 3280 by the media. 3282 For any error response to a PLAY request, the server's response 3283 depends on the current session state. If the session is in Ready 3284 state, the current pause-point is returned using Range header with 3285 the pause point as the explicit start-point and an implicit stop- 3286 point. For time-progressing content where the pause-point moves with 3287 real-time due to limited retention, the current pause point is 3288 returned. For sessions in Play state, the current playout point and 3289 the remaining parts of the range request is returned. For any media 3290 with retention longer than 0 seconds the currently valid Media-Range 3291 header SHALL also be included in the response. 3293 A PLAY response MAY include a header carrying synchronization 3294 information. As the information necessary is dependent on the media 3295 transport format, further rules specifying the header and its usage 3296 are needed. For RTP the RTP-Info header is specified, see 3297 Section 18.45, and used in the following example. 3299 Here is a simple example for a single audio stream where the client 3300 requests the media starting from 3.52 seconds and to the end. The 3301 server sends a 200 OK response with the actual play time which is 10 3302 ms prior (3.51) and the RTP-Info header that contains the necessary 3303 parameters for the RTP stack. 3305 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3306 CSeq: 836 3307 Session: 12345678 3308 Range: npt=3.52- 3309 User-Agent: PhonyClient/1.2 3311 S->C: RTSP/2.0 200 OK 3312 CSeq: 836 3313 Date: Thu, 23 Jan 1997 15:35:06 GMT 3314 Server: PhonyServer/1.0 3315 Range: npt=3.51-324.39 3316 Seek-Style: First-Prior 3317 RTP-Info:url="rtsp://example.com/audio" 3318 ssrc=0D12F123:seq=14783;rtptime=2345962545 3320 S->C: RTP Packet TS=2345962545 => NPT=3.51 3321 Media duration=0.16 seconds 3323 The server replies with the actual start point that will be 3324 delivered. This may differ from the requested range if alignment of 3325 the requested range to valid frame boundaries is required for the 3326 media source. Note that some media streams in an aggregate may need 3327 to be delivered from even earlier points. Also, some media formats 3328 have a very long duration per individual data unit, therefore it 3329 might be necessary for the client to parse the data unit, and select 3330 where to start. The server SHALL also indicate which policy it uses 3331 for selecting the actual start point by including a Seek-Style 3332 header. 3334 In the following example the client receives the first media packet 3335 that stretches all the way up and past the requested playtime. Thus, 3336 it is the client's decision whether to render to the user the time 3337 between 3.52 and 7.05, or to skip it. In most cases it is probably 3338 most suitable not to render that time period. 3340 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3341 CSeq: 836 3342 Session: 12345678 3343 Range: npt=7.05- 3344 User-Agent: PhonyClient/1.2 3346 S->C: RTSP/2.0 200 OK 3347 CSeq: 836 3348 Date: Thu, 23 Jan 1997 15:35:06 GMT 3349 Server: PhonyServer/1.0 3350 Range: npt=3.52- 3351 Seek-Style: First-Prior 3352 RTP-Info:url="rtsp://example.com/audio" 3353 ssrc=0D12F123:seq=14783;rtptime=2345962545 3355 S->C: RTP Packet TS=2345962545 => NPT=3.52 3356 Duration=4.15 seconds 3358 After playing the desired range, the presentation does NOT change to 3359 the Ready state, media delivery simply stops. A PAUSE request MUST 3360 be issued to make the stream enter the Ready state. A PLAY request 3361 while the stream is still in the Play state is legal, and can be 3362 issued without an intervening PAUSE request. Such a request MUST 3363 replace the current PLAY action with the new one requested, i.e., 3364 being handled in the same way as if as the request was received in 3365 Ready state. In the case that the range in Range header has an 3366 implicit start time ("-endtime"), the server MUST continue to play 3367 from where it currently was until the specified end point. This is 3368 useful to change the end to at another point than in the previous 3369 request. 3371 The following example plays the whole presentation starting at SMPTE 3372 time code 0:10:20 until the end of the clip. Note: The RTP-Info 3373 headers has been broken into several lines, where following lines 3374 start with whitespace as allowed by the syntax. 3376 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 3377 CSeq: 833 3378 Session: 12345678 3379 Range: smpte=0:10:20- 3380 User-Agent: PhonyClient/1.2 3382 S->C: RTSP/2.0 200 OK 3383 CSeq: 833 3384 Date: Thu, 23 Jan 1997 15:35:06 GMT 3385 Session: 12345678 3386 Server: PhonyServer/1.0 3387 Range: smpte=0:10:22-0:15:45 3388 Seek-Style: Next 3389 RTP-Info:url="rtsp://example.com/twister.en" 3390 ssrc=0D12F123:seq=14783;rtptime=2345962545 3392 For playing back a recording of a live presentation, it may be 3393 desirable to use clock units: 3395 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 3396 CSeq: 835 3397 Session: 12345678 3398 Range: clock=19961108T142300Z-19961108T143520Z 3399 User-Agent: PhonyClient/1.2 3401 S->C: RTSP/2.0 200 OK 3402 CSeq: 835 3403 Date: Thu, 23 Jan 1997 15:35:06 GMT 3404 Session: 12345678 3405 Server: PhonyServer/1.0 3406 Range: clock=19961108T142300Z-19961108T143520Z 3407 Seek-Style: Next 3408 RTP-Info:url="rtsp://example.com/meeting.en" 3409 ssrc=0D12F123:seq=53745;rtptime=484589019 3411 13.4.2. Aggregated Sessions 3413 PLAY requests can operate on sessions controlling a single media and 3414 on aggregated sessions controlling multiple media. 3416 In an aggregated session the PLAY request MUST contain an aggregated 3417 control URI. A server MUST respond with error 460 (Only Aggregate 3418 Operation Allowed) if the client PLAY Request-URI is for a single 3419 media. The media in an aggregate MUST be played in sync. If a 3420 client wants individual control of the media, it needs to use 3421 separate RTSP sessions for each media. 3423 For aggregated sessions where the initial SETUP request (creating a 3424 session) is followed by one or more additional SETUP requests, a PLAY 3425 request MAY be pipelined after those additional SETUP requests 3426 without awaiting their responses. This procedure can reduce the 3427 delay from start of session establishment until media play-out has 3428 started with one round trip time. However, a client needs to be 3429 aware that using this procedure will result in the playout of the 3430 server state established at the time of processing the PLAY, i.e., 3431 after the processing of all the requests prior to the PLAY request in 3432 the pipeline. This state may not be the intended one due to failure 3433 of any of the prior requests. A client can easily determine this 3434 based on the responses from those requests. In case of failure, the 3435 client can halt the media playout using PAUSE and try to establish 3436 the intended state again before issuing another PLAY request. 3438 13.4.3. Updating current PLAY Requests 3440 Clients can issue PLAY requests while the stream is in Play state and 3441 thus updating their request. 3443 The important difference compared to a PLAY request in Ready state is 3444 the handling of the current play point and how the Range header in 3445 the request is constructed. The session is actively playing media 3446 and the play point will be moving, making the exact time a request 3447 will take effect hard to predict. Depending on how the PLAY header 3448 appears two different cases exist: total replacement or continuation. 3449 A total replacement is signaled by having the first range 3450 specification have an explicit start value, e.g., "npt=45-" or 3451 "npt=45-60", in which case the server stops playout at the current 3452 playout point and then starts delivering media according to the Range 3453 header. This is equivalent to having the client first send a PAUSE 3454 and then a new PLAY request that isn't based on the pause point. In 3455 the case of continuation the first range specifier has an implicit 3456 start point and an explicit stop value (Z), e.g., "npt=-60", which 3457 indicate that it MUST convert the range specifier being played prior 3458 to this PLAY request (X to Y) into (X to Z) and continue as this was 3459 the request originally played. If the current delivery point is 3460 beyond the stop point, the server SHALL immediately pause delivery. 3461 As the request has been completed successfully it shall be responded 3462 with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to 3463 indicate the actual stop point. The pause point is set to the 3464 requested stop point. 3466 Following is an example of this behavior: The server has received 3467 requests to play ranges 10 to 15. If the new PLAY request arrives at 3468 the server 4 seconds after the previous one, it will take effect 3469 while the server still plays the first range (10-15). The server 3470 changes the current play to continue to 25 seconds, i.e., the 3471 equivalent single request would be PLAY with "range: npt=10-25". 3473 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3474 CSeq: 834 3475 Session: 12345678 3476 Range: npt=10-15 3477 User-Agent: PhonyClient/1.2 3479 S->C: RTSP/2.0 200 OK 3480 CSeq: 834 3481 Date: Thu, 23 Jan 1997 15:35:06 GMT 3482 Session: 12345678 3483 Server: PhonyServer/1.0 3484 Range: npt=10-15 3485 Seek-Style: Next 3486 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3487 ssrc=0D12F123:seq=5712;rtptime=934207921, 3488 url="rtsp://example.com/fizzle/videotrack" 3489 ssrc=789DAF12:seq=57654;rtptime=2792482193 3490 Session: 12345678 3492 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3493 CSeq: 835 3494 Session: 12345678 3495 Range: npt=-25 3496 User-Agent: PhonyClient/1.2 3498 S->C: RTSP/2.0 200 OK 3499 CSeq: 835 3500 Date: Thu, 23 Jan 1997 15:35:09 GMT 3501 Session: 12345678 3502 Server: PhonyServer/1.0 3503 Range: npt=14-25 3504 Seek-Style: Next 3505 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3506 ssrc=0D12F123:seq=5712;rtptime=934239921, 3507 url="rtsp://example.com/fizzle/videotrack" 3508 ssrc=789DAF12:seq=57654;rtptime=2792842193 3510 A common use of a PLAY request while in Play state is changing the 3511 scale of the media, i.e., entering or leaving fast forward or fast 3512 rewind. The client can issue an updating PLAY request that is either 3513 a continuation or a complete replacement, as discussed above this 3514 section. We give an example of a client that is requesting a fast 3515 forward (scale=2) without giving a stop point and then change from 3516 fast forward to regular playout (scale = 1). In the second PLAY 3517 request the time is set explicitly to be where ever the server 3518 currently plays out (npt=now-) and the server responds with the 3519 actual playback point where the new scale actually takes effect 3520 (npt=2:17:27.144-). 3522 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3523 CSeq: 2034 3524 Session: 12345678 3525 Range: npt=now- 3526 Scale: 2.0 3527 User-Agent: PhonyClient/1.2 3529 S->C: RTSP/2.0 200 OK 3530 CSeq: 2034 3531 Date: Thu, 23 Jan 1997 15:35:06 GMT 3532 Session: 12345678 3533 Server: PhonyServer/1.0 3534 Range: npt=2:17:21.394- 3535 Seek-Style: Next 3536 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3537 ssrc=0D12F123:seq=5712;rtptime=934207921, 3538 url="rtsp://example.com/fizzle/videotrack" 3539 ssrc=789DAF12:seq=57654;rtptime=2792482193 3541 [playing in fast forward and now returning to scale = 1] 3543 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3544 CSeq: 2035 3545 Session: 12345678 3546 Range: npt=now- 3547 Scale: 1.0 3548 User-Agent: PhonyClient/1.2 3550 S->C: RTSP/2.0 200 OK 3551 CSeq: 2035 3552 Date: Thu, 23 Jan 1997 15:35:09 GMT 3553 Session: 12345678 3554 Server: PhonyServer/1.0 3555 Range: npt=2:17:27.144- 3556 Seek-Style: Next 3557 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3558 ssrc=0D12F123:seq=5712;rtptime=934239921, 3559 url="rtsp://example.com/fizzle/videotrack" 3560 ssrc=789DAF12:seq=57654;rtptime=2792842193 3562 13.4.4. Playing On-Demand Media 3564 On-demand media is indicated by the content of the Media-Properties 3565 header in the SETUP response by (see also Section 18.29): 3567 o Random Access property is set to Random-Access; 3568 o Content Modifications set to Immutable; 3570 o Retention set to Unlimited or Time-Limited. 3572 Playing on-demand media follows the general usage as described in 3573 Section 13.4.1. 3575 13.4.5. Playing Dynamic On-Demand Media 3577 Dynamic on-demand media is indicated by the content of the Media- 3578 Properties header in the SETUP response by (see also Section 18.29): 3580 o Random Access set to Random-Access; 3582 o Content Modifications set to Dynamic; 3584 o Retention set to Unlimited or Time-Limited. 3586 Playing on-demand media follows the general usage as described in 3587 Section 13.4.1 as long as the media has not been changed. 3589 There are two ways for the client to be informed about changes of 3590 media resources in Play state. The client will receive a PLAY_NOTIFY 3591 request with Notify-Reason header set to media-properties-update (see 3592 Section 13.5.2. The client can use the value of the Media-Range to 3593 decide further actions, if the Media-Range header is present in the 3594 PLAY_NOTIFY request. The second way is that the client issues a 3595 GET_PARAMETER request without a body but including a Media-Range 3596 header. The 200 OK response MUST include the current Media-Range 3597 header (see Section 18.30). 3599 13.4.6. Playing Live Media 3601 Live media is indicated by the content of the Media-Properties header 3602 in the SETUP response by (see also Section 18.29): 3604 o Random-Access set to No-Seeking; 3606 o Content Modifications set to Time-Progressing; 3608 o Retention with Time-Duration set to 0.0. 3610 For live media, the SETUP response 200 OK MUST include the Media- 3611 Range header (see Section 18.30). 3613 A client MAY send PLAY requests without the Range header. If the 3614 request includes the Range header it MUST use a symbolic value 3615 representing "now". For NPT that range specification is "npt=now-". 3617 The server MUST include the Range header in the response and it MUST 3618 indicate an explicit time value and not a symbolic value. In other 3619 words, "npt=now-" is not valid to be used in the response. Instead 3620 the time since session start is recommended expressed as an open 3621 interval, e.g., "npt=96.23-". An absolute time value (clock) for the 3622 corresponding time MAY be given, i.e., "clock=20030213T143205Z-". 3623 The Absolute Time format can only be used if client has shown support 3624 for it using the Accept-Ranges header. 3626 13.4.7. Playing Live with Recording 3628 Certain media servers may offer recording services of live sessions 3629 to their clients. This recording would normally be from the 3630 beginning of the media session. Clients can randomly access the 3631 media between now and the beginning of the media session. This live 3632 media with recording is indicated by the content of the Media- 3633 Properties header in the SETUP response by (see also Section 18.29): 3635 o Random Access set to Random-Access; 3637 o Content Modifications set to Time-Progressing; 3639 o Retention set to Time-Limited or Unlimited 3641 The SETUP response 200 OK MUST include the Media-Range header (see 3642 Section 18.30) for this type of media. For live media with 3643 recording, the Range header indicates the current delivery point in 3644 the media and the Media-Range header indicates the currently 3645 available media window around the current time. This window can 3646 cover recorded content in the past (seen from current time in the 3647 media) or recorded content in the future (seen from current time in 3648 the media). The server adjusts the delivery point to the requested 3649 border of the window. If the client requests a delivery point that 3650 is located outside the recording window, e.g., if the requested point 3651 is too far in the past, the server selects the oldest point in the 3652 recording. The considerations in Section 13.5.3 apply if a client 3653 requests delivery with Scale (Section 18.46) values other than 1.0 3654 (Normal playback rate) while delivering live media with recording. 3656 13.4.8. Playing Live with Time-Shift 3658 Certain media servers may offer time-shift services to their clients. 3659 This time shift records a fixed interval in the past, i.e., a sliding 3660 window recording mechanism, but not past this interval. Clients can 3661 randomly access the media between now and the interval. This live 3662 media with recording is indicated by the content of the Media- 3663 Properties header in the SETUP response by (see also Section 18.29): 3665 o Random Access set to Random-Access; 3667 o Content Modifications set to Time-Progressing; 3669 o Retention set to Time-Duration and a value indicating the 3670 recording interval (>0). 3672 The SETUP response 200 OK MUST include the Media-Range header (see 3673 Section 18.30) for this type of media. For live media with recording 3674 the Range header indicates the current time in the media and the 3675 Media Range indicates a window around the current time. This window 3676 can cover recorded content in the past (seen from current time in the 3677 media) or recorded content in the future (seen from current time in 3678 the media). The server adjusts the play point to the requested 3679 border of the window, if the client requests a play point that is 3680 located outside the recording windows, e.g., if requested too far in 3681 the past, the server selects the oldest range in the recording. The 3682 considerations in Section 13.5.3 apply, if a client requests delivery 3683 using a Scale (Section 18.46) value other than 1.0 (Normal playback 3684 rate) while delivering live media with time-shift. 3686 13.5. PLAY_NOTIFY 3688 The PLAY_NOTIFY method is issued by a server to inform a client about 3689 an asynchronous event for a session in Play state. The Session 3690 header MUST be presented in a PLAY_NOTIFY request and indicates the 3691 scope of the request. Sending of PLAY_NOTIFY requests requires a 3692 persistent connection between server and client, otherwise there is 3693 no way for the server to send this request method to the client. 3695 PLAY_NOTIFY requests have an end-to-end (i.e., server to client) 3696 scope, as they carry the Session header, and apply only to the given 3697 session. The client SHOULD immediately return a response to the 3698 server. 3700 PLAY_NOTIFY requests MAY use both aggregate control URI and 3701 individual media resource URIs depending on scope of the 3702 notification. This scope may have important distinctions for 3703 aggregated sessions, and each reason for a PLAY_NOTIFY request needs 3704 to specify the interpretation and if aggregated control URIs or 3705 individual URIs may be used in requests. 3707 PLAY_NOTIFY requests MAY be used with a message body, depending on 3708 the value of the Notify-Reason header. It is described in the 3709 particular section for each Notify-Reason if a message body is used. 3710 However, currently there is no Notify-Reason that allows using a 3711 message body. In this case, there is a need to obey some limitations 3712 when adding new Notify-Reasons that intend to use a message body: the 3713 server can send any type of message body, but it is not ensured that 3714 the client can understand the received message body. This is related 3715 to DESCRIBE (see Section 13.2 ), but in this particular case the 3716 client can state its acceptable message bodies by using the Accept 3717 header. In the case of PLAY_NOTIFY, the server does not know which 3718 message bodies are understood by the client. 3720 The Notify-Reason header (see Section 18.32) specifies the reason why 3721 the server sends the PLAY_NOTIFY request. This is extensible and new 3722 reasons MAY be added in the future (see Section 22.8). In case the 3723 client does not understand the reason for the notification it MUST 3724 respond with a 465 (Notification Reason Unknown) (Section 17.4.29) 3725 error code. Servers can send PLAY_NOTIFY with these types: 3727 o end-of-stream (see Section 13.5.1); 3729 o media-properties-update (see Section 13.5.2); 3731 o scale-change (see Section 13.5.3). 3733 13.5.1. End-of-Stream 3735 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3736 indicates the completion or near completion of the PLAY request and 3737 the ending delivery of the media stream(s). The request MUST NOT be 3738 issued unless the server is in the Play state. The end of the media 3739 stream delivery notification may be used to indicate either a 3740 successful completion of the PLAY request currently being served, or 3741 to indicate some error resulting in failure to complete the request. 3742 The Request-Status header (Section 18.42) MUST be included to 3743 indicate which request the notification is for and its completion 3744 status. The message response status codes (Section 8.1.1) are used 3745 to indicate how the PLAY request concluded. The sender of a 3746 PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a 3747 PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY 3748 was issued before reaching the end-of-stream, but some error occurred 3749 resulting in that the previously sent PLAY_NOTIFY contained a wrong 3750 time when the stream will end. In this case a new PLAY_NOTIFY MUST 3751 be sent including the correct status for the completion and all 3752 additional information. 3754 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream 3755 MUST include a Range header and the Scale header if the scale value 3756 is not 1. The Range header indicates the point in the stream or 3757 streams where delivery is ending with the timescale that was used by 3758 the server in the PLAY response for the request being fulfilled. The 3759 server MUST NOT use the "now" constant in the Range header; it MUST 3760 use the actual numeric end position in the proper timescale. When 3761 end-of-stream notifications are issued prior to having sent the last 3762 media packets, this is evident as the end time in the Range header is 3763 beyond the current time in the media being received by the client, 3764 e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale 3765 header is to be included so that it is evident if the media time 3766 scale is moving backwards and/or have a non-default pace. The end- 3767 of-stream notification does not prevent the client from sending a new 3768 PLAY request. 3770 If RTP is used as media transport, a RTP-Info header MUST be 3771 included, and the RTP-Info header MUST indicate the last sequence 3772 number in the seq parameter. 3774 For RTSP Session where media resources under aggregated control the 3775 media resources will normally end at approximately the same time, 3776 although some small differences may exist, on the scale of a few 3777 hundred of milliseconds. In those cases a RTSP session under 3778 aggregated control SHOULD send only a single PLAY_NOTIFY request. By 3779 using the aggregate control URI in the PLAY_NOTIFY request the RTSP 3780 server indicates that this applies to all media resources within the 3781 session. In cases RTP is used for media delivery corresponding RTP- 3782 Info needs to be included for all media resources. In cases where 3783 one or more media resource has significantly shorter duration than 3784 some other resources in the aggregated session the server MAY send 3785 end-of-stream notifications using individual media resource URIs to 3786 indicate to agents that there will be no more media for this 3787 particular media resource related to the current active PLAY request. 3788 In such cases when the remaining media resources comes to end-of- 3789 stream they MUST send a PLAY_NOTIFY request using the aggregate 3790 control URI to indicate that no more resources remains. 3792 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3793 MUST NOT carry a message body. 3795 This example request notifies the client about a future end-of-stream 3796 event: 3798 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3799 CSeq: 854 3800 Notify-Reason: end-of-stream 3801 Request-Status: cseq=853 status=200 reason="OK" 3802 Range: npt=-145 3803 RTP-Info:url="rtsp://example.com/fizzle/foo/audio" 3804 ssrc=0D12F123:seq=14783;rtptime=2345962545, 3805 url="rtsp://example.com/fizzle/video" 3806 ssrc=789DAF12:seq=57654;rtptime=2792482193 3808 Session: uZ3ci0K+Ld-M 3809 Date: Mon, 08 Mar 2010 13:37:16 GMT 3811 C->S: RTSP/2.0 200 OK 3812 CSeq: 854 3813 User-Agent: PhonyClient/1.2 3814 Session: uZ3ci0K+Ld-M 3816 13.5.2. Media-Properties-Update 3818 A PLAY_NOTIFY request with Notify-Reason header set to media- 3819 properties-update indicates an update of the media properties for the 3820 given session (see Section 18.29) and/or the available media range 3821 that can be played as indicated by Media-Range (Section 18.30). 3822 PLAY_NOTIFY requests with Notify-Reason header set to media- 3823 properties-update MUST include a Media-Properties and Date header and 3824 SHOULD include a Media-Range header. The Media-Properties header has 3825 session scope, thus for aggregated sessions the PLAY_NOTIFY request 3826 MUST be using the aggregated control URI. 3828 This notification MUST be sent for media that are Time-Progressing 3829 every time an event happens that changes the basis for making 3830 estimates on how the available for play-back media range will 3831 progress with wall clock time. In addition it is RECOMMENDED that 3832 the server sends these notifications approximately every 5 minutes 3833 for time-progressing content to ensure the long-term stability of the 3834 client estimation and allowing for clock skew detection by the 3835 client. The time between notifications should be greater than 1 3836 minute and less than 2 hours. Requests for the just mentioned 3837 reasons MUST include Media-Range header to provide current Media 3838 duration and the Range header to indicate the current playing point 3839 and any remaining parts of the requested range. 3841 The recommendation for sending updates every 5 minutes is due to 3842 any clock skew issues. In 5 minutes the clock skew should not 3843 become too significant as this is not used for media playback and 3844 synchronization, only for determining which content is available 3845 to the user. 3847 A PLAY_NOTIFY request with Notify-Reason header set to media- 3848 properties-update MUST NOT carry a message body. 3850 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3851 Date: Tue, 14 Apr 2008 15:48:06 GMT 3852 CSeq: 854 3853 Notify-Reason: media-properties-update 3854 Session: uZ3ci0K+Ld-M 3855 Media-Properties: Time-Progressing, 3856 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3857 Media-Range: npt=0-1:37:21.394 3858 Range: npt=1:15:49.873- 3860 C->S: RTSP/2.0 200 OK 3861 CSeq: 854 3862 User-Agent: PhonyClient/1.2 3863 Session: uZ3ci0K+Ld-M 3865 13.5.3. Scale-Change 3867 The server may be forced to change the rate of media time per 3868 playback time when a client requests delivery using a Scale 3869 (Section 18.46) value other than 1.0 (normal playback rate). For 3870 time progressing media with some retention, i.e., the server stores 3871 already sent content, a client requesting to play with Scale values 3872 larger than 1 may catch up with the front end of the media. The 3873 server will then be unable to continue to provide content at Scale 3874 larger than 1 as content is only made available by the server at 3875 Scale=1. Another case is when Scale < 1 and the media retention is 3876 time-duration limited. In this case the delivery point can reach the 3877 oldest media unit available, and further playback at this scale 3878 becomes impossible as there will be no media available. To avoid 3879 having the client lose any media, the scale will need to be adjusted 3880 to the same rate at which the media is removed from the storage 3881 buffer, commonly Scale = 1.0. 3883 Another case is when the content itself consists of spliced pieces or 3884 is dynamically updated. In these cases the server may be required to 3885 change from one supported scale value (different than Scale=1.0) to 3886 another. In this case the server will pick the closest value and 3887 inform the client of what it has picked. In these cases the media 3888 properties will also be sent updating the supported Scale values. 3889 This enables a client to adjust the Scale value used. 3891 To minimize impact on playback in any of the above cases the server 3892 MUST modify the playback properties and set Scale to a supportable 3893 value and continue delivery of the media. When doing this 3894 modification it MUST send a PLAY_NOTIFY message with the Notify- 3895 Reason header set to "scale-change". The request MUST contain a 3896 Range header with the media time when the change took effect, a Scale 3897 header with the new value in use, Session header with the identifier 3898 for the session it applies to and a Date header with the server 3899 wallclock time of the change. For time progressing content also the 3900 Media-Range and the Media-Properties at this point in time MUST be 3901 included. The Media-Properties header MUST be included if the scale 3902 change was due to the content changing what scale values that is 3903 supported. 3905 For media streams being delivered using RTP also a RTP-Info header 3906 MUST be included. It MUST contain the rtptime parameter with a value 3907 corresponding to the point of change in that media and optionally 3908 also the sequence number. 3910 PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated 3911 control URI in the request. The scale change for any aggregated 3912 session do apply to all media streams part of the aggregate. 3914 A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" 3915 MUST NOT carry a message body. 3917 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3918 Date: Tue, 14 Apr 2008 15:48:06 GMT 3919 CSeq: 854 3920 Notify-Reason: scale-change 3921 Session: uZ3ci0K+Ld-M 3922 Media-Properties: Time-Progressing, 3923 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3924 Media-Range: npt=0-1:37:21.394 3925 Range: npt=1:37:21.394- 3926 Scale: 1 3927 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" 3928 ssrc=0D12F123:rtptime=2345962545, 3929 url="rtsp://example.com/fizzle/videotrack" 3930 ssrc=789DAF12:seq=57654;rtptime=2792482193 3932 C->S: RTSP/2.0 200 OK 3933 CSeq: 854 3934 User-Agent: PhonyClient/1.2 3935 Session: uZ3ci0K+Ld-M 3937 13.6. PAUSE 3939 The PAUSE request causes the stream delivery to immediately be 3940 interrupted (halted). A PAUSE request MUST be done either with the 3941 aggregated control URI for aggregated sessions, resulting in all 3942 media being halted, or the media URI for non-aggregated sessions. 3944 Any attempt to do muting of a single media with a PAUSE request in an 3945 aggregated session MUST be responded to with error 460 (Only 3946 Aggregate Operation Allowed). After resuming playback, 3947 synchronization of the tracks MUST be maintained. Any server 3948 resources are kept, though servers MAY close the session and free 3949 resources after being paused for the duration specified with the 3950 timeout parameter of the Session header in the SETUP message. 3952 Example: 3954 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3955 CSeq: 834 3956 Session: 12345678 3957 User-Agent: PhonyClient/1.2 3959 S->C: RTSP/2.0 200 OK 3960 CSeq: 834 3961 Date: Thu, 23 Jan 1997 15:35:06 GMT 3962 Range: npt=45.76-75.00 3964 The PAUSE request causes stream delivery to be interrupted 3965 immediately on receipt of the message and the pause point is set to 3966 the current point in the presentation. That pause point in the media 3967 stream needs to be maintained. A subsequent PLAY request without 3968 Range header resumes from the pause point and plays until media end. 3970 The pause point after any PAUSE request MUST be returned to the 3971 client by adding a Range header with what remains unplayed of the 3972 PLAY request's range. For media with random access properties, if 3973 one desires to resume playing a ranged request, one simply includes 3974 the Range header from the PAUSE response and includes the Seek-Style 3975 header with the Next policy in the PLAY request. For media that is 3976 time-progressing and has retention duration=0 the follow-up PLAY 3977 request to start media delivery again, MUST use "npt=now-" and not 3978 the answer given in the response to PAUSE. 3980 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3981 CSeq: 834 3982 Session: 12345678 3983 Range: npt=10-30 3984 User-Agent: PhonyClient/1.2 3986 S->C: RTSP/2.0 200 OK 3987 CSeq: 834 3988 Date: Thu, 23 Jan 1997 15:35:06 GMT 3989 Server: PhonyServer/1.0 3990 Range: npt=10-30 3991 Seek-Style: First-Prior 3992 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3993 ssrc=0D12F123:seq=5712;rtptime=934207921, 3994 url="rtsp://example.com/fizzle/videotrack" 3995 ssrc=4FAD8726:seq=57654;rtptime=2792482193 3996 Session: 12345678 3998 After 11 seconds, i.e., at 21 seconds into the presentation: 3999 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4000 CSeq: 835 4001 Session: 12345678 4002 User-Agent: PhonyClient/1.2 4004 S->C: RTSP/2.0 200 OK 4005 CSeq: 835 4006 Date: 23 Jan 1997 15:35:17 GMT 4007 Server: PhonyServer/1.0 4008 Range: npt=21-30 4009 Session: 12345678 4011 If a client issues a PAUSE request and the server acknowledges and 4012 enters the Ready state, the proper server response, if the player 4013 issues another PAUSE, is still 200 OK. The 200 OK response MUST 4014 include the Range header with the current pause point. See examples 4015 below: 4017 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4018 CSeq: 834 4019 Session: 12345678 4020 User-Agent: PhonyClient/1.2 4022 S->C: RTSP/2.0 200 OK 4023 CSeq: 834 4024 Session: 12345678 4025 Date: Thu, 23 Jan 1997 15:35:06 GMT 4026 Range: npt=45.76-98.36 4028 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4029 CSeq: 835 4030 Session: 12345678 4031 User-Agent: PhonyClient/1.2 4033 S->C: RTSP/2.0 200 OK 4034 CSeq: 835 4035 Session: 12345678 4036 Date: 23 Jan 1997 15:35:07 GMT 4037 Range: npt=45.76-98.36 4039 13.7. TEARDOWN 4041 13.7.1. Client to Server 4043 The TEARDOWN client to server request stops the stream delivery for 4044 the given URI, freeing the resources associated with it. A TEARDOWN 4045 request MAY be performed on either an aggregated or a media control 4046 URI. However, some restrictions apply depending on the current 4047 state. The TEARDOWN request MUST contain a Session header indicating 4048 what session the request applies to. The TEARDOWN request MUST NOT 4049 include a Terminate-Reason header. 4051 A TEARDOWN using the aggregated control URI or the media URI in a 4052 session under non-aggregated control (single media session) MAY be 4053 done in any state (Ready and Play). A successful request MUST result 4054 in that media delivery being immediately halted and the session state 4055 being destroyed. This MUST be indicated through the lack of a 4056 Session header in the response. 4058 A TEARDOWN using a media URI in an aggregated session MAY only be 4059 done in Ready state. Such a request only removes the indicated media 4060 stream and associated resources from the session. This may result in 4061 a session returning to non-aggregated control, because it only 4062 contains a single media after the request's completion. A session 4063 that will exist after the processing of the TEARDOWN request MUST in 4064 the response to that TEARDOWN request contain a Session header. Thus 4065 the presence of the Session header indicates to the receiver of the 4066 response if the session is still existing or has been removed. 4068 Example: 4070 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 4071 CSeq: 892 4072 Session: 12345678 4073 User-Agent: PhonyClient/1.2 4075 S->C: RTSP/2.0 200 OK 4076 CSeq: 892 4077 Server: PhonyServer/1.0 4079 13.7.2. Server to Client 4081 The server can send TEARDOWN requests in the server to client 4082 direction to indicate that the server has been forced to terminate 4083 the ongoing session. This may happen for several reasons, such as 4084 server maintenance without available backup, or that the session has 4085 been inactive for extended periods of time. The reason is provided 4086 in the Terminate-Reason header (Section 18.52). 4088 When a RTSP client has maintained a RTSP session that otherwise is 4089 inactive for an extended period of time the server may reclaim the 4090 resources. That is done by issuing a TEARDOWN request with the 4091 Terminate-Reason set to "Session-Timeout". This MAY be done when the 4092 client has been inactive in the RTSP session for more than one 4093 Session Timeout period (Section 18.49). However, the server is 4094 RECOMMENDED to not perform this operation until an extended period of 4095 inactivity of 10 times the Session Timeout period has passed. It is 4096 to the operator of the RTSP server to actually configure how long 4097 this extended period of inactivity is. An operator should take into 4098 account when doing this configuration what the served content is and 4099 what this means for the extended period of inactivity. 4101 In case the server needs to stop providing service to the established 4102 sessions and there is no server to point at in a REDIRECT request, 4103 then TEARDOWN SHALL be used to terminate the session. This method 4104 can also be used when non-recoverable internal errors have happened 4105 and the server has no other option then to terminate the sessions. 4107 The TEARDOWN request MUST be done only on the session aggregate 4108 control URI (i.e., it is not allowed to terminate individual media 4109 streams, if it is a session aggregate) and MUST include the following 4110 headers; Session and Terminate-Reason headers. The request only 4111 applies to the session identified in the Session header. The server 4112 may include a message to the client's user with the "user-msg" 4113 parameter. 4115 The TEARDOWN request may alternatively be done on the wild card URI * 4116 and without any session header. The scope of such a request is 4117 limited to the next-hop (i.e., the RTSP agent in direct communication 4118 with the server) and applies, as well, to the RTSP connection between 4119 the next-hop RTSP agent and the server. This request indicates that 4120 all sessions and pending requests being managed via the connection 4121 are terminated. Any intervening proxies SHOULD do all of the 4122 following in the order listed: 4124 1. respond to the TEARDOWN request 4126 2. disconnect the control channel from the requesting server 4128 3. pass the TEARDOWN request to each applicable client (typically 4129 those clients with an active session or an unanswered request) 4131 Note: The proxy is responsible for accepting TEARDOWN responses 4132 from its clients; these responses MUST NOT be passed on to either 4133 the original server or the target server in the redirect. 4135 13.8. GET_PARAMETER 4137 The GET_PARAMETER request retrieves the value of any specified 4138 parameter or parameters for a presentation or stream specified in the 4139 URI. If the Session header is present in a request, the value of a 4140 parameter MUST be retrieved in the specified session context. There 4141 are two ways of specifying the parameters to be retrieved. 4143 The first is by including headers which have been defined such that 4144 you can use them for this purpose. Headers for this purpose should 4145 allow empty, or stripped value parts to avoid having to specify bogus 4146 data when indicating the desire to retrieve a value. The successful 4147 completion of the request should also be evident from any filled out 4148 values in the response. The headers in this specification that MAY 4149 be used for retrieving their current value using GET_PARAMETER below. 4150 Additional headers MAY be specified in the future: 4152 o Accept-Ranges 4154 o Media-Range 4156 o Media-Properties 4158 o Range 4159 o RTP-Info 4161 The other way is to specify a message body that lists the 4162 parameter(s) that are desired to be retrieved. The Content-Type 4163 header (Section 18.19) is used to specify which format the message 4164 body has. If the receiver of the request is not supporting the media 4165 type used for the message body, it SHALL respond using the error code 4166 415 (Unsupported Media Type). The responder to a GET_PARAMETER 4167 request MUST use the media type of the request for the response. For 4168 additional considerations regarding message body negotiation see 4169 Section 9.3. 4171 RTSP Agents implementing support for responding to GET_PARAMETER 4172 requests SHALL implement the text/parameters format (Appendix F). 4173 This to ensure that at least one known format for parameter are 4174 implemented and thus prevent parameter format negotiation failure. 4176 Parameters specified within the body of the message must all be 4177 understood by the request receiving agent. If one or more parameters 4178 are not understood a 451 (Parameter Not Understood) MUST be sent 4179 including a body listing these parameters that weren't understood. 4180 If all parameters are understood their values are filled in and 4181 returned in the response message body. 4183 The method MAY also be used without a message body or any header that 4184 requests parameters for keep-alive purpose. The keep-alive timer has 4185 been updated for any request that is successful, i.e., a 200 OK 4186 response is received. Any non-required header present in such a 4187 request may or may not have been processed. Normally the presence of 4188 filled out values in the header will be indication that the header 4189 has been processed. However, for cases when this is difficult to 4190 determine, it is recommended to use a feature-tag and the Require 4191 header. For this reason it is usually easier if any parameters to be 4192 retrieved are sent in the body, rather than using any header. 4194 Example: 4196 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4197 CSeq: 431 4198 User-Agent: PhonyClient/1.2 4199 Session: 12345678 4200 Content-Length: 26 4201 Content-Type: text/parameters 4203 packets_received 4204 jitter 4206 C->S: RTSP/2.0 200 OK 4207 CSeq: 431 4208 Session: 12345678 4209 Server: PhonyServer/1.1 4210 Date: Mon, 08 Mar 2010 13:43:23 GMT 4211 Content-Length: 38 4212 Content-Type: text/parameters 4214 packets_received: 10 4215 jitter: 0.3838 4217 13.9. SET_PARAMETER 4219 This method requests to set the value of a parameter or a set of 4220 parameters for a presentation or stream specified by the URI. The 4221 method MAY also be used without a message body. It is the 4222 RECOMMENDED method to be used in a request sent for the sole purpose 4223 of updating the keep-alive timer. If this request is successful, 4224 i.e., a 200 OK response is received, then the keep-alive timer has 4225 been updated. Any non-required header present in such a request may 4226 or may not have been processed. To allow a client to determine if 4227 any such header has been processed, it is necessary to use a feature 4228 tag and the Require header. Due to this reason it is RECOMMENDED 4229 that any parameters are sent in the body, rather than using any 4230 header. 4232 When using a message body to list the parameter(s) that are desired 4233 to be set the Content-Type header (Section 18.19) is used to specify 4234 which format the message body has. If the receiver of the request is 4235 not supporting the media type used for the message body, it SHALL 4236 respond using the error code 415 (Unsupported Media Type). For 4237 additional considerations regarding message body negotiation see 4238 Section 9.3. 4240 RTSP Agents implementing support for responding to SET_PARAMETER 4241 requests SHALL implement the text/parameters format (Appendix F). 4242 This to ensure that at least one known format for parameters are 4243 implemented and thus prevent parameter format negotiation failure. 4245 A request is RECOMMENDED to only contain a single parameter to allow 4246 the client to determine why a particular request failed. If the 4247 request contains several parameters, the server MUST only act on the 4248 request if all of the parameters can be set successfully. A server 4249 MUST allow a parameter to be set repeatedly to the same value, but it 4250 MAY disallow changing parameter values. If the receiver of the 4251 request does not understand or cannot locate a parameter, error 451 4252 (Parameter Not Understood) MUST be used. When a parameter is not 4253 allowed to change, the error code is 458 (Parameter Is Read-Only). 4254 The response body MUST contain only the parameters that have errors. 4255 Otherwise no body MUST be returned. The response body MUST use the 4256 media type of the request for the response. 4258 Note: transport parameters for the media stream MUST only be set with 4259 the SETUP command. 4261 Restricting setting transport parameters to SETUP is for the 4262 benefit of firewalls. 4264 The parameters are split in a fine-grained fashion so that there 4265 can be more meaningful error indications. However, it may make 4266 sense to allow the setting of several parameters if an atomic 4267 setting is desirable. Imagine device control where the client 4268 does not want the camera to pan unless it can also tilt to the 4269 right angle at the same time. 4271 Example: 4273 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4274 CSeq: 421 4275 User-Agent: PhonyClient/1.2 4276 Session: iixT43KLc 4277 Date: Mon, 08 Mar 2010 14:45:04 GMT 4278 Content-length: 20 4279 Content-type: text/parameters 4281 barparam: barstuff 4283 S->C: RTSP/2.0 451 Parameter Not Understood 4284 CSeq: 421 4285 Session: iixT43KLc 4286 Server: PhonyServer/1.0 4287 Date: Mon, 08 Mar 2010 14:44:56 GMT 4288 Content-length: 20 4289 Content-type: text/parameters 4291 barparam: barstuff 4293 13.10. REDIRECT 4295 The REDIRECT method is issued by a server to inform a client that the 4296 service provided will be terminated and where a corresponding service 4297 can be provided instead. This may happen for different reasons. One 4298 is that the server is being administered such that it must stop 4299 providing service. Thus the client is required to connect to another 4300 server location to access the resource indicated by the Request-URI. 4302 The REDIRECT request SHALL contain a Terminate-Reason header 4303 (Section 18.52) to inform the client of the reason for the request. 4304 Additional parameters related to the reason may also be included. 4305 The intention here is to allow a server administrator to do a 4306 controlled shutdown of the RTSP server. That requires sufficient 4307 time to inform all entities having associated state with the server 4308 and for them to perform a controlled migration from this server to a 4309 fall back server. 4311 A REDIRECT request with a Session header has end-to-end (i.e., server 4312 to client) scope and applies only to the given session. Any 4313 intervening proxies SHOULD NOT disconnect the control channel while 4314 there are other remaining end-to-end sessions. The REQUIRED Location 4315 header MUST contain a complete absolute URI pointing to the resource 4316 to which the client SHOULD reconnect. Specifically, the Location 4317 MUST NOT contain just the host and port. A client may receive a 4318 REDIRECT request with a Session header, if and only if, an end-to-end 4319 session has been established. 4321 A client may receive a REDIRECT request without a Session header at 4322 any time when it has communication or a connection established with a 4323 server. The scope of such a request is limited to the next-hop 4324 (i.e., the RTSP agent in direct communication with the server) and 4325 applies to all sessions controlled, as well as the connection between 4326 the next-hop RTSP agent and the server. A REDIRECT request without a 4327 Session header indicates that all sessions and pending requests being 4328 managed via the connection MUST be redirected. The Location header, 4329 if included in such a request, SHOULD contain an absolute URI with 4330 only the host address and the OPTIONAL port number of the server to 4331 which the RTSP agent SHOULD reconnect. Any intervening proxies 4332 SHOULD do all of the following in the order listed: 4334 1. respond to the REDIRECT request 4336 2. disconnect the control channel from the requesting server 4338 3. connect to the server at the given host address 4339 4. pass the REDIRECT request to each applicable client (typically 4340 those clients with an active session or an unanswered request) 4342 Note: The proxy is responsible for accepting REDIRECT responses 4343 from its clients; these responses MUST NOT be passed on to either 4344 the original server or the redirected server. 4346 When the server lacks any alternative server and needs to terminate a 4347 session or all sessions the TEARDOWN request SHALL be used instead. 4349 When no Terminate-Reason "time" parameter is included in a REDIRECT 4350 request, the client SHALL perform the redirection immediately and 4351 return a response to the server. The server shall consider the 4352 session as terminated and can free any associated state after it 4353 receives the successful (2xx) response. The server MAY close the 4354 signaling connection upon receiving the response and the client 4355 SHOULD close the signaling connection after sending the 2xx response. 4356 The exception to this is when the client has several sessions on the 4357 server being managed by the given signaling connection. In this 4358 case, the client SHOULD close the connection when it has received and 4359 responded to REDIRECT requests for all the sessions managed by the 4360 signaling connection. 4362 The Terminate-Reason header "time" parameter MAY be used to indicate 4363 the wallclock time by when the redirection MUST have taken place. To 4364 allow a client to determine that redirect time without being time 4365 synchronized with the server, the server MUST include a Date header 4366 in the request. The client should have terminated the session and 4367 closed the connection before the redirection time-line terminated. 4368 The server MAY simply cease to provide service when the deadline time 4369 has been reached, or it may issue TEARDOWN requests to the remaining 4370 sessions. 4372 If the REDIRECT request times out following the rules in Section 10.4 4373 the server MAY terminate the session or transport connection that 4374 would be redirected by the request. This is a safeguard against 4375 misbehaving clients that refuse to respond to a REDIRECT request. 4376 Thus, removing any incentive to not acknowledge the reception of a 4377 REDIRECT request. 4379 After a REDIRECT request has been processed, a client that wants to 4380 continue to receive media for the resource identified by the Request- 4381 URI will have to establish a new session with the designated host. 4382 If the URI given in the Location header is a valid resource URI, a 4383 client SHOULD issue a DESCRIBE request for the URI. 4385 Note: The media resource indicated by the Location header can be 4386 identical, slightly different or totally different. This is the 4387 reason why a new DESCRIBE request SHOULD be issued. 4389 If the Location header contains only a host address, the client MAY 4390 assume that the media on the new server is identical to the media on 4391 the old server, i.e., all media configuration information from the 4392 old session is still valid except for the host address. However, the 4393 usage of conditional SETUP using MTag identifiers is RECOMMENDED as a 4394 means to verify the assumption. 4396 This example request redirects traffic for this session to the new 4397 server at the given absolute time: 4399 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 4400 CSeq: 732 4401 Location: rtsp://s2.example.com:8001 4402 Terminate-Reason: Server-Admin ;time=19960213T143205Z 4403 Session: uZ3ci0K+Ld-M 4404 Date: Thu, 13 Feb 1996 14:30:43 GMT 4406 C->S: RTSP/2.0 200 OK 4407 CSeq: 732 4408 User-Agent: PhonyClient/1.2 4409 Session: uZ3ci0K+Ld-M 4411 14. Embedded (Interleaved) Binary Data 4413 In order to fulfill certain requirements on the network side, e.g., 4414 in conjunction with network address translators that block RTP 4415 traffic over UDP, it may be necessary to interleave RTSP messages and 4416 media stream data. This interleaving should generally be avoided 4417 unless necessary since it complicates client and server operation and 4418 imposes additional overhead. Also, head of line blocking may cause 4419 problems. Interleaved binary data SHOULD only be used if RTSP is 4420 carried over TCP. Interleaved data is not allowed inside RTSP 4421 messages. 4423 Stream data such as RTP packets is encapsulated by an ASCII dollar 4424 sign (36 decimal), followed by a one-octet channel identifier, 4425 followed by the length of the encapsulated binary data as a binary, 4426 two-octet unsigned integer in network byte order. The stream data 4427 follows immediately afterwards, without a CRLF, but including the 4428 upper-layer protocol headers. Each $ block MUST contain exactly one 4429 upper-layer protocol data unit, e.g., one RTP packet. 4431 Note that this mechanism does not support larger PDUs than 65535 4432 bytes, which is the same that regular IPv4 and IPv6 is capable. 4433 If the media delivery protocol intended to be used has larger PDUs 4434 than that, the definition of such mechanisms usage of this 4435 mechanism will require the definition of a PDU fragmentation 4436 mechanism. 4438 0 1 2 3 4439 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 4440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4441 | "$" = 36 | Channel ID | Length in octets | 4442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4443 : Binary data (Length according to Length field) : 4444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4446 Figure 1: Embedded Interleaved Binary Data Format 4448 The channel identifier is defined in the Transport header with the 4449 interleaved parameter (Section 18.54). 4451 When the transport choice is RTP, RTCP messages are also interleaved 4452 by the server over the TCP connection. The usage of RTCP messages is 4453 indicated by including an interval containing a second channel in the 4454 interleaved parameter of the Transport header, see Section 18.54. If 4455 RTCP is used, packets MUST be sent on the first available channel 4456 higher than the RTP channel. The channels are bi-directional, using 4457 the same Channel ID in both directions, and therefore RTCP traffic is 4458 sent on the second channel in both directions. 4460 RTCP is sometimes needed for synchronization when two or more 4461 streams are interleaved in such a fashion. Also, this provides a 4462 convenient way to tunnel RTP/RTCP packets through the RTSP 4463 connection (TCP or TCP/TLS) when required by the network 4464 configuration and transfer them onto UDP when possible. 4466 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 4467 CSeq: 2 4468 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 4469 Accept-Ranges: npt, smpte, clock 4470 User-Agent: PhonyClient/1.2 4472 S->C: RTSP/2.0 200 OK 4473 CSeq: 2 4474 Date: Thu, 05 Jun 1997 18:57:18 GMT 4475 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 4476 Session: 12345678 4477 Accept-Ranges: npt 4478 Media-Properties: Random-Access=0.2, Immutable, Unlimited 4480 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 4481 CSeq: 3 4482 Session: 12345678 4483 User-Agent: PhonyClient/1.2 4485 S->C: RTSP/2.0 200 OK 4486 CSeq: 3 4487 Session: 12345678 4488 Date: Thu, 05 Jun 1997 18:57:19 GMT 4489 RTP-Info: url="rtsp://example.com/bar.file" 4490 ssrc=0D12F123:seq=232433;rtptime=972948234 4491 Range: npt=0-56.8 4492 Seek-Style: RAP 4494 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4495 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4496 S->C: $006{2 octet length}{"length" octets RTCP packet} 4498 15. Proxies 4500 RTSP Proxies are RTSP agents that are located in between a client and 4501 a server. A proxy can take on both the role as a client and as 4502 server depending on what it tries to accomplish. RTSP proxies use 4503 two transport layer connections, one from the RTSP client to the RTSP 4504 proxy and a second from the RTSP proxy to the RTSP server. Proxies 4505 are introduced for several different reasons and the below listed are 4506 often combined. 4508 There are these types of RTSP proxies: 4510 Caching Proxy: This type of proxy is used to reduce the workload on 4511 servers and connections. By caching the description and media 4512 streams, i.e., the presentation, the proxy can serve a client 4513 with content, but without requesting it from the server once it 4514 has been cached and has not become stale. See the caching 4515 Section 16. This type of proxy is also expected to understand 4516 RTSP end-point functionality, i.e., functionality identified in 4517 the Require header in addition to what Proxy-Require demands. 4519 Translator Proxy: This type of proxy is used to ensure that an RTSP 4520 client gets access to servers and content on an external 4521 network or using content encodings not supported by the client. 4522 The proxy performs the necessary translation of addresses, 4523 protocols or encodings. This type of proxy is expected to also 4524 understand RTSP end-point functionality, i.e., functionality 4525 identified in the Require header in addition to what Proxy- 4526 Require demands. 4528 Access Proxy: This type of proxy is used to ensure that an RTSP 4529 client gets access to servers on an external network. Thus 4530 this proxy is placed on the border between two domains, e.g., a 4531 private address space and the public Internet. The proxy 4532 performs the necessary translation, usually addresses. This 4533 type of proxy is required to redirect the media to itself or a 4534 controlled gateway that performs the translation before the 4535 media can reach the client. 4537 Security Proxy: This type of proxy is used to help facilitate 4538 security functions around RTSP. For example when having a 4539 firewalled network, the security proxy requests that the 4540 necessary pinholes in the firewall are opened when a client in 4541 the protected network wants to access media streams on the 4542 external side. This proxy can also limit the client's access 4543 to certain types of content. This proxy can perform its 4544 function without redirecting the media between the server and 4545 client. However, in deployments with private address spaces 4546 this proxy is likely to be combined with the access proxy. 4547 Anyway, the functionality of this proxy is usually closely tied 4548 into understanding all aspects of the media transport. 4550 Auditing Proxy: RTSP proxies can also provide network owners with a 4551 logging and audit point for RTSP sessions, e.g., for 4552 corporations that track their employees usage of the network. 4553 This type of proxy can perform its function without inserting 4554 itself or any other node in the media transport. This proxy 4555 type can also accept unknown methods as it doesn't interfere 4556 with the clients' requests. 4558 All types of proxies can be used also when using secured 4559 communication with TLS as RTSP 2.0 allows the client to approve 4560 certificate chains used for connection establishment from a proxy, 4561 see Section 19.3.2. However, that trust model may not be suitable 4562 for all types of deployment. In those cases, the secured sessions do 4563 by-pass the proxies. 4565 Access proxies SHOULD NOT be used in equipment like NATs and 4566 firewalls that aren't expected to be regularly maintained, like home 4567 or small office equipment. In these cases it is better to use the 4568 NAT traversal procedures defined for RTSP 2.0 4569 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 4570 that any extensions of RTSP resulting in new media transport 4571 protocols or profiles, new parameters, etc. may fail in a proxy that 4572 isn't maintained. This would impede RTSP's future development and 4573 usage. 4575 15.1. Proxies and Protocol Extensions 4577 The existence of proxies must always be considered when developing 4578 new RTSP extensions. Most types of proxies will need to implement 4579 any new method to operate correctly in the presence of that 4580 extension. New headers can be introduced and will not be blocked by 4581 older proxies. However, it is important to consider if this header 4582 and its function is required to be understood by the proxy or can be 4583 forwarded. If the header needs to be understood, a feature-tag 4584 representing the functionality MUST be included in the Proxy-Require 4585 header. Below are guidelines for analysis if the header needs to be 4586 understood. The transport header and its parameters also shows that 4587 headers that are extensible and require correct interpretation in the 4588 proxy also require handling rules. 4590 Whether a proxy needs to understand a header is not easy to 4591 determine, as they serve a broad variety of functions. When 4592 evaluating if a header needs to be understood, one can divide the 4593 functionality into three main categories: 4595 Media modifying: The caching and translator proxies are modifying 4596 the actual media and therefore need to understand also the request 4597 directed to the server that affects how the media is rendered. 4598 Thus, this type of proxy needs to also understand the server side 4599 functionality. 4601 Transport modifying: The access and the security proxy both need to 4602 understand how the transport is performed, either for opening 4603 pinholes or to translate the outer headers, e.g., IP and UDP. 4605 Non-modifying: The audit proxy is special in that it does not modify 4606 the messages in other ways than to insert the Via header. That 4607 makes it possible for this type to forward RTSP messages that 4608 contain different types of unknown methods, headers or header 4609 parameters. 4611 Based on the above classification, one should evaluate if the new 4612 functionality requires the Transport modifying type of proxies to 4613 understand it or not. 4615 15.2. Multiplexing and Demultiplexing of Messages 4617 RTSP proxies may have to multiplex multiple RTSP sessions from their 4618 clients towards RTSP servers. This requires that RTSP requests from 4619 multiple clients are multiplexed onto a common connection for 4620 requests outgoing to an RTSP server and on the way back the responses 4621 are demultiplexed from the server to per client responses. On the 4622 protocol level this requires that request and response messages are 4623 handled in both ways, requiring that there is a mechanism to 4624 correlate what request/response pair exchanged between proxy and 4625 server is mapped to what client (or client request). 4627 This multiplexing of requests and demultiplexing of responses is done 4628 by using the CSeq header field. The proxy has to rewrite the CSeq in 4629 requests to the server and responses from the server and remember 4630 what CSeq is mapped to what client. The proxy also needs to ensure 4631 that the order of the message related to each client is maintained. 4632 Section 18.20 is defining the handling of how requests and responses 4633 are rewritten. 4635 16. Caching 4637 In HTTP, request-response pairs are cached. RTSP differs 4638 significantly in that respect. Responses are not cacheable, with the 4639 exception of the presentation description returned by DESCRIBE. 4640 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4641 not return any data, caching is not really an issue for these 4642 requests.) However, it is desirable for the continuous media data, 4643 typically delivered out-of-band with respect to RTSP, to be cached, 4644 as well as the session description. 4646 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4647 has an up-to-date copy of the continuous media content and its 4648 description. It can determine whether the copy is up-to-date by 4649 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4650 Last-Modified header with that of the cached copy. If the copy is 4651 not up-to-date, it modifies the SETUP transport parameters as 4652 appropriate and forwards the request to the origin server. 4653 Subsequent control commands such as PLAY or PAUSE then pass the proxy 4654 unmodified. The proxy delivers the continuous media data to the 4655 client, while possibly making a local copy for later reuse. The 4656 exact allowed behavior of the cache is given by the cache-response 4657 directives described in Section 18.11. A cache MUST answer any 4658 DESCRIBE requests if it is currently serving the stream to the 4659 requester, as it is possible that low-level details of the stream 4660 description may have changed on the origin-server. 4662 Note that an RTSP cache, is of the "cut-through" variety. Rather 4663 than retrieving the whole resource from the origin server, the cache 4664 simply copies the streaming data as it passes by on its way to the 4665 client. Thus, it does not introduce additional latency. 4667 To the client, an RTSP proxy cache appears like a regular media 4668 server. To the media origin server an RTSP proxy cache appears like 4669 a client. Just as an HTTP cache has to store the content type, 4670 content language, and so on for the objects it caches, a media cache 4671 has to store the presentation description. Typically, a cache 4672 eliminates all transport-references (e.g., multicast information) 4673 from the presentation description, since these are independent of the 4674 data delivery from the cache to the client. Information on the 4675 encodings remains the same. If the cache is able to translate the 4676 cached media data, it would create a new presentation description 4677 with all the encoding possibilities it can offer. 4679 16.1. Validation Model 4681 When a cache has a stale entry that it would like to use as a 4682 response to a client's request, it first has to check with the origin 4683 server (or possibly an intermediate cache with a fresh response) to 4684 see if its cached entry is still usable. We call this "validating" 4685 the cache entry. Since we do not want to have to pay the overhead of 4686 retransmitting the full response if the cached entry is good, and we 4687 do not want to pay the overhead of an extra round trip if the cached 4688 entry is invalid, the RTSP protocol supports the use of conditional 4689 methods. 4691 The key protocol features for supporting conditional methods are 4692 those concerned with "cache validators." When an origin server 4693 generates a full response, it attaches some sort of validator to it, 4694 which is kept with the cache entry. When a client (user agent or 4695 proxy cache) makes a conditional request for a resource for which it 4696 has a cache entry, it includes the associated validator in the 4697 request. 4699 The server then checks that validator against the current validator 4700 for the requested resource, and, if they match (see Section 16.1.3), 4701 it responds with a special status code (usually, 304 (Not Modified)) 4702 and no message body. Otherwise, it returns a full response 4703 (including message body). Thus, we avoid transmitting the full 4704 response if the validator matches, and we avoid an extra round trip 4705 if it does not match. 4707 In RTSP, a conditional request looks exactly the same as a normal 4708 request for the same resource, except that it carries a special 4709 header (which includes the validator) that implicitly turns the 4710 method (usually DESCRIBE or SETUP) into a conditional. 4712 The protocol includes both positive and negative senses of cache- 4713 validating conditions. That is, it is possible to request either 4714 that a method be performed if and only if a validator matches or if 4715 and only if no validators match. 4717 Note: a response that lacks a validator may still be cached, and 4718 served from cache until it expires, unless this is explicitly 4719 prohibited by a cache-control directive (see Section 18.11). 4720 However, a cache cannot do a conditional retrieval if it does not 4721 have a validator for the resource, which means it will not be 4722 refreshable after it expires. 4724 Media streams that are being adapted based on the transport capacity 4725 between the server and the cache makes caching more difficult. A 4726 server needs to consider how it views caching of media streams that 4727 it adapts and potentially instruct any caches to not cache such 4728 streams. 4730 16.1.1. Last-Modified Dates 4732 The Last-Modified header (Section 18.27) value is often used as a 4733 cache validator. In simple terms, a cache entry is considered to be 4734 valid if the content has not been modified since the Last-Modified 4735 value. 4737 16.1.2. Message Body Tag Cache Validators 4739 The MTag response-header field value, a message body tag, provides 4740 for an "opaque" cache validator. This might allow more reliable 4741 validation in situations where it is inconvenient to store 4742 modification dates, where the one-second resolution of RTSP-date 4743 values is not sufficient, or where the origin server wishes to avoid 4744 certain paradoxes that might arise from the use of modification 4745 dates. 4747 Message body tags are described in Section 4.6 4749 16.1.3. Weak and Strong Validators 4751 Since both origin servers and caches will compare two validators to 4752 decide if they represent the same or different entities, one normally 4753 would expect that if the message body (i.e., the presentation 4754 description) or any associated message body headers changes in any 4755 way, then the associated validator would change as well. If this is 4756 true, then we call this validator a "strong validator." We call 4757 message body (i.e., the presentation description) or any associated 4758 message body headers an entity for a better understanding. 4760 However, there might be cases when a server prefers to change the 4761 validator only on semantically significant changes, and not when 4762 insignificant aspects of the entity change. A validator that does 4763 not always change when the resource changes is a "weak validator." 4765 Message body tags are normally "strong validators," but the protocol 4766 provides a mechanism to tag a message body tag as "weak." One can 4767 think of a strong validator as one that changes whenever the bits of 4768 an entity changes, while a weak value changes whenever the meaning of 4769 an entity changes. Alternatively, one can think of a strong 4770 validator as part of an identifier for a specific entity, while a 4771 weak validator is part of an identifier for a set of semantically 4772 equivalent entities. 4774 Note: One example of a strong validator is an integer that is 4775 incremented in stable storage every time an entity is changed. 4777 An entity's modification time, if represented with one-second 4778 resolution, could be a weak validator, since it is possible that 4779 the resource might be modified twice during a single second. 4781 Support for weak validators is optional. However, weak validators 4782 allow for more efficient caching of equivalent objects. 4784 A "use" of a validator is either when a client generates a request 4785 and includes the validator in a validating header field, or when a 4786 server compares two validators. 4788 Strong validators are usable in any context. Weak validators are 4789 only usable in contexts that do not depend on exact equality of an 4790 entity. For example, either kind is usable for a conditional 4791 DESCRIBE of a full entity. However, only a strong validator is 4792 usable for a sub-range retrieval, since otherwise the client might 4793 end up with an internally inconsistent entity. 4795 Clients MAY issue DESCRIBE requests with either weak validators or 4796 strong validators. Clients MUST NOT use weak validators in other 4797 forms of requests. 4799 The only function that the RTSP protocol defines on validators is 4800 comparison. There are two validator comparison functions, depending 4801 on whether the comparison context allows the use of weak validators 4802 or not: 4804 o The strong comparison function: in order to be considered equal, 4805 both validators MUST be identical in every way, and both MUST NOT 4806 be weak. 4808 o The weak comparison function: in order to be considered equal, 4809 both validators MUST be identical in every way, but either or both 4810 of them MAY be tagged as "weak" without affecting the result. 4812 A message body tag is strong unless it is explicitly tagged as weak. 4814 A Last-Modified time, when used as a validator in a request, is 4815 implicitly weak unless it is possible to deduce that it is strong, 4816 using the following rules: 4818 o The validator is being compared by an origin server to the actual 4819 current validator for the entity and, 4821 o That origin server reliably knows that the associated entity did 4822 not change more than once during the second covered by the 4823 presented validator. 4825 OR 4827 o The validator is about to be used by a client in an If-Modified- 4828 Since, because the client has a cache entry for the associated 4829 entity, and 4831 o That cache entry includes a Date value, which gives the time when 4832 the origin server sent the original response, and 4834 o The presented Last-Modified time is at least 60 seconds before the 4835 Date value. 4837 OR 4839 o The validator is being compared by an intermediate cache to the 4840 validator stored in its cache entry for the entity, and 4842 o That cache entry includes a Date value, which gives the time when 4843 the origin server sent the original response, and 4845 o The presented Last-Modified time is at least 60 seconds before the 4846 Date value. 4848 This method relies on the fact that if two different responses were 4849 sent by the origin server during the same second, but both had the 4850 same Last-Modified time, then at least one of those responses would 4851 have a Date value equal to its Last-Modified time. The arbitrary 60- 4852 second limit guards against the possibility that the Date and Last- 4853 Modified values are generated from different clocks, or at somewhat 4854 different times during the preparation of the response. An 4855 implementation MAY use a value larger than 60 seconds, if it is 4856 believed that 60 seconds is too short. 4858 If a client wishes to perform a sub-range retrieval on a value for 4859 which it has only a Last-Modified time and no opaque validator, it 4860 MAY do this only if the Last-Modified time is strong in the sense 4861 described here. 4863 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates 4865 We adopt a set of rules and recommendations for origin servers, 4866 clients, and caches regarding when various validator types ought to 4867 be used, and for what purposes. 4869 RTSP origin servers: 4871 o SHOULD send a message body tag validator unless it is not feasible 4872 to generate one. 4874 o MAY send a weak message body tag instead of a strong message body 4875 tag, if performance considerations support the use of weak message 4876 body tags, or if it is unfeasible to send a strong message body 4877 tag. 4879 o SHOULD send a Last-Modified value if it is feasible to send one, 4880 unless the risk of a breakdown in semantic transparency that could 4881 result from using this date in an If-Modified-Since header would 4882 lead to serious problems. 4884 In other words, the preferred behavior for an RTSP origin server is 4885 to send both a strong message body tag and a Last-Modified value. 4887 In order to be legal, a strong message body tag MUST change whenever 4888 the associated entity value changes in any way. A weak message body 4889 tag SHOULD change whenever the associated entity changes in a 4890 semantically significant way. 4892 Note: in order to provide semantically transparent caching, an 4893 origin server MUST avoid reusing a specific strong message body 4894 tag value for two different entities, or reusing a specific weak 4895 message body tag value for two semantically different entities. 4896 Cache entries might persist for arbitrarily long periods, 4897 regardless of expiration times, so it might be inappropriate to 4898 expect that a cache will never again attempt to validate an entry 4899 using a validator that it obtained at some point in the past. 4901 RTSP clients: 4903 o If a message body tag has been provided by the origin server, MUST 4904 use that message body tag in any cache-conditional request (using 4905 If-Match or If-None-Match). 4907 o If only a Last-Modified value has been provided by the origin 4908 server, SHOULD use that value in non-subrange cache-conditional 4909 requests (using If-Modified-Since). 4911 o If both a message body tag and a Last-Modified value have been 4912 provided by the origin server, SHOULD use both validators in 4913 cache-conditional requests. 4915 An RTSP origin server, upon receiving a conditional request that 4916 includes both a Last-Modified date (e.g., in an If-Modified-Since 4917 header) and one or more message body tags (e.g., in an If-Match, If- 4918 None-Match, or If-Range header field) as cache validators, MUST NOT 4919 return a response status of 304 (Not Modified) unless doing so is 4920 consistent with all of the conditional header fields in the request. 4922 Note: The general principle behind these rules is that RTSP 4923 servers and clients should transmit as much non-redundant 4924 information as is available in their responses and requests. RTSP 4925 systems receiving this information will make the most conservative 4926 assumptions about the validators they receive. 4928 16.1.5. Non-validating Conditionals 4930 The principle behind message body tags is that only the service 4931 author knows the semantics of a resource well enough to select an 4932 appropriate cache validation mechanism, and the specification of any 4933 validator comparison function more complex than octet-equality would 4934 open up a can of worms. Thus, comparisons of any other headers are 4935 never used for purposes of validating a cache entry. 4937 16.2. Invalidation After Updates or Deletions 4939 The effect of certain methods performed on a resource at the origin 4940 server might cause one or more existing cache entries to become non- 4941 transparently invalid. That is, although they might continue to be 4942 "fresh," they do not accurately reflect what the origin server would 4943 return for a new request on that resource. 4945 There is no way for the RTSP protocol to guarantee that all such 4946 cache entries are marked invalid. For example, the request that 4947 caused the change at the origin server might not have gone through 4948 the proxy where a cache entry is stored. However, several rules help 4949 reduce the likelihood of erroneous behavior. 4951 In this section, the phrase "invalidate an entity" means that the 4952 cache will either remove all instances of that entity from its 4953 storage, or will mark these as "invalid" and in need of a mandatory 4954 revalidation before they can be returned in response to a subsequent 4955 request. 4957 Some RTSP methods MUST cause a cache to invalidate an entity. This 4958 is either the entity referred to by the Request-URI, or by the 4959 Location or Content-Location headers (if present). These methods 4960 are: 4962 o DESCRIBE 4963 o SETUP 4965 In order to prevent denial of service attacks, an invalidation based 4966 on the URI in a Location or Content-Location header MUST only be 4967 performed if the host part is the same as in the Request-URI. 4969 A cache that passes through requests for methods it does not 4970 understand SHOULD invalidate any entities referred to by the Request- 4971 URI. 4973 17. Status Code Definitions 4975 Where applicable, HTTP status [H10] codes are reused. See Table 4 in 4976 Section 8.1 for a listing of which status codes may be returned by 4977 which requests. All error messages, 4xx and 5xx MAY return a body 4978 containing further information about the error. 4980 17.1. Success 1xx 4982 17.1.1. 100 Continue 4984 The client SHOULD continue with its request. This interim response 4985 is used to inform the client that the initial part of the request has 4986 been received and has not yet been rejected by the server. The 4987 client SHOULD continue by sending the remainder of the request or, if 4988 the request has already been completed, ignore this response. The 4989 server MUST send a final response after the request has been 4990 completed. 4992 17.2. Success 2xx 4994 This class of status code indicates that the client's request was 4995 successfully received, understood, and accepted. 4997 17.2.1. 200 OK 4999 The request has succeeded. The information returned with the 5000 response is dependent on the method used in the request. 5002 17.3. Redirection 3xx 5004 The notation "3xx" indicates response codes from 300 to 399 inclusive 5005 which are meant for redirection. The response code 304 is excluded, 5006 as it is not used for redirection and instead the "3rr" notation is 5007 used. The 304 response code appears here, rather than a 2xx response 5008 code which would have been appropriate, this as 304 has been used 5009 also in RTSP 1.0 [RFC2326]. 5011 Within RTSP, redirection may be used for load balancing or 5012 redirecting stream requests to a server topologically closer to the 5013 client. Mechanisms to determine topological proximity are beyond the 5014 scope of this specification. 5016 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 5017 that they are used if necessary before a session is established, 5018 i.e., in response to DESCRIBE or SETUP. However, in cases where a 5019 server is not able to send a REDIRECT request to the client, the 5020 server MAY need to resort to using 3rr responses to inform a client 5021 with an established session about the need for redirecting the 5022 session. If a 3rr response is received for a request in relation to 5023 an established session, the client SHOULD send a TEARDOWN request for 5024 the session, and MAY reestablish the session using the resource 5025 indicated by the Location. 5027 If the Location header is used in a response it MUST contain an 5028 absolute URI pointing out the media resource the client is redirected 5029 to, the URI MUST NOT only contain the host name. 5031 17.3.1. 300 5033 This response code is not used in RTSP 2.0. For behavior to use with 5034 unknown 3rr status codes, one follows the 302 (Section 17.3.3). 5036 17.3.2. 301 Moved Permanently 5038 The requested resource is moved permanently and resides now at the 5039 URI given by the Location header. The user client SHOULD redirect 5040 automatically to the given URI. This response MUST NOT contain a 5041 message-body. The Location header MUST be included in the response. 5043 17.3.3. 302 Found 5045 The requested resource resides temporarily at the URI given by the 5046 Location header. The Location header MUST be included in the 5047 response. This response is intended to be used for many types of 5048 temporary redirects; e.g., load balancing. It is RECOMMENDED that 5049 the server set the reason phrase to something more meaningful than 5050 "Found" in these cases. The user client SHOULD redirect 5051 automatically to the given URI. This response MUST NOT contain a 5052 message-body. 5054 This example shows a client being redirected to a different server: 5056 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 5057 CSeq: 2 5058 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 5059 Accept-Ranges: npt, smpte, clock 5060 User-Agent: PhonyClient/1.2 5062 S->C: RTSP/2.0 302 Try Other Server 5063 CSeq: 2 5064 Location: rtsp://s2.example.com:8001/fizzle/foo 5066 17.3.4. 303 See Other 5068 This status code MUST NOT be used in RTSP 2.0. However, it was 5069 allowed in RTSP 1.0 [RFC2326]. 5071 17.3.5. 304 Not Modified 5073 If the client has performed a conditional DESCRIBE or SETUP (see 5074 Section 18.25) and the requested resource has not been modified, the 5075 server SHOULD send a 304 response. This response MUST NOT contain a 5076 message-body. 5078 The response MUST include the following header fields: 5080 o Date 5082 o MTag and/or Content-Location, if the header(s) would have been 5083 sent in a 200 response to the same request. 5085 o Expires and Cache-Control if the field-value might differ from 5086 that sent in any previous response for the same variant. 5088 This response is independent for the DESCRIBE and SETUP requests. 5089 That is, a 304 response to DESCRIBE does NOT imply that the resource 5090 content is unchanged (only the session description) and a 304 5091 response to SETUP does NOT imply that the resource description is 5092 unchanged. The MTag and If-Match headers may be used to link the 5093 DESCRIBE and SETUP in this manner. 5095 17.3.6. 305 Use Proxy 5097 The requested resource MUST be accessed through the proxy given by 5098 the Location field. The Location field gives the URI of the proxy. 5099 The recipient is expected to repeat this single request via the 5100 proxy. 305 responses MUST only be generated by origin servers. 5102 17.4. Client Error 4xx 5104 17.4.1. 400 Bad Request 5106 The request could not be understood by the server due to malformed 5107 syntax. The client SHOULD NOT repeat the request without 5108 modifications. If the request does not have a CSeq header, the 5109 server MUST NOT include a CSeq in the response. 5111 17.4.2. 401 Unauthorized 5113 The request requires user authentication. The response MUST include 5114 a WWW-Authenticate header (Section 18.58) field containing a 5115 challenge applicable to the requested resource. The client MAY 5116 repeat the request with a suitable Authorization header field. If 5117 the request already included Authorization credentials, then the 401 5118 response indicates that authorization has been refused for those 5119 credentials. If the 401 response contains the same challenge as the 5120 prior response, and the user agent has already attempted 5121 authentication at least once, then the user SHOULD be presented the 5122 message body that was given in the response, since that message body 5123 might include relevant diagnostic information. HTTP access 5124 authentication is explained in [RFC2617]. 5126 17.4.3. 402 Payment Required 5128 This code is reserved for future use. 5130 17.4.4. 403 Forbidden 5132 The server understood the request, but is refusing to fulfill it. 5133 Authorization will not help and the request SHOULD NOT be repeated. 5134 If the server wishes to make public why the request has not been 5135 fulfilled, it SHOULD describe the reason for the refusal in the 5136 message body. If the server does not wish to make this information 5137 available to the client, the status code 404 (Not Found) can be used 5138 instead. 5140 17.4.5. 404 Not Found 5142 The server has not found anything matching the Request-URI. No 5143 indication is given of whether the condition is temporary or 5144 permanent. The 410 (Gone) status code SHOULD be used if the server 5145 knows, through some internally configurable mechanism, that an old 5146 resource is permanently unavailable and has no forwarding address. 5147 This status code is commonly used when the server does not wish to 5148 reveal exactly why the request has been refused, or when no other 5149 response is applicable. 5151 17.4.6. 405 Method Not Allowed 5153 The method specified in the request is not allowed for the resource 5154 identified by the Request-URI. The response MUST include an Allow 5155 header containing a list of valid methods for the requested resource. 5156 This status code is also to be used if a request attempts to use a 5157 method not indicated during SETUP. 5159 17.4.7. 406 Not Acceptable 5161 The resource identified by the request is only capable of generating 5162 response message bodies which have content characteristics not 5163 acceptable according to the Accept headers sent in the request. 5165 The response SHOULD include a message body containing a list of 5166 available message body characteristics and location(s) from which the 5167 user or user agent can choose the one most appropriate. The message 5168 body format is specified by the media type given in the Content-Type 5169 header field. Depending upon the format and the capabilities of the 5170 user agent, selection of the most appropriate choice MAY be performed 5171 automatically. However, this specification does not define any 5172 standard for such automatic selection. 5174 If the response could be unacceptable, a user agent SHOULD 5175 temporarily stop receipt of more data and query the user for a 5176 decision on further actions. 5178 17.4.8. 407 Proxy Authentication Required 5180 This code is similar to 401 (Unauthorized) (Section 17.4.2), but 5181 indicates that the client must first authenticate itself with the 5182 proxy. The proxy MUST return a Proxy-Authenticate header field 5183 (Section 18.34) containing a challenge applicable to the proxy for 5184 the requested resource. 5186 17.4.9. 408 Request Timeout 5188 The client did not produce a request within the time that the server 5189 was prepared to wait. The client MAY repeat the request without 5190 modifications at any later time. 5192 17.4.10. 410 Gone 5194 The requested resource is no longer available at the server and the 5195 forwarding address is not known. This condition is expected to be 5196 considered permanent. If the server does not know, or has no 5197 facility to determine, whether or not the condition is permanent, the 5198 status code 404 (Not Found) SHOULD be used instead. This response is 5199 cacheable unless indicated otherwise. 5201 The 410 response is primarily intended to assist the task of 5202 repository maintenance by notifying the recipient that the resource 5203 is intentionally unavailable and that the server owners desire that 5204 remote links to that resource be removed. Such an event is common 5205 for limited-time, promotional services and for resources belonging to 5206 individuals no longer working at the server's site. It is not 5207 necessary to mark all permanently unavailable resources as "gone" or 5208 to keep the mark for any length of time -- that is left to the 5209 discretion of the owner of the server. 5211 17.4.11. 412 Precondition Failed 5213 The precondition given in one or more of the 'if-' request-header 5214 fields evaluated to false when it was tested on the server. See 5215 these sections for the 'if-' headers: If-Match Section 18.24, If- 5216 Modified-Since Section 18.25, and If-None-Match Section 18.26. This 5217 response code allows the client to place preconditions on the current 5218 resource meta information (header field data) and thus prevent the 5219 requested method from being applied to a resource other than the one 5220 intended. 5222 17.4.12. 413 Request Message Body Too Large 5224 The server is refusing to process a request because the request 5225 message body is larger than the server is willing or able to process. 5226 The server MAY close the connection to prevent the client from 5227 continuing the request. 5229 If the condition is temporary, the server SHOULD include a Retry- 5230 After header field to indicate that it is temporary and after what 5231 time the client MAY try again. 5233 17.4.13. 414 Request-URI Too Long 5235 The server is refusing to service the request because the Request-URI 5236 is longer than the server is willing to interpret. This rare 5237 condition is only likely to occur when a client has used a request 5238 with long query information, when the client has descended into a URI 5239 "black hole" of redirection (e.g., a redirected URI prefix that 5240 points to a suffix of itself), or when the server is under attack by 5241 a client attempting to exploit security holes present in some servers 5242 using fixed-length buffers for reading or manipulating the Request- 5243 URI. 5245 17.4.14. 415 Unsupported Media Type 5247 The server is refusing to service the request because the message 5248 body of the request is in a format not supported by the requested 5249 resource for the requested method. 5251 17.4.15. 451 Parameter Not Understood 5253 The recipient of the request does not support one or more parameters 5254 contained in the request. When returning this error message the 5255 sender SHOULD return a message body containing the offending 5256 parameter(s). 5258 17.4.16. 452 reserved 5260 This status code MUST NOT be used in RTSP 2.0. However, it was 5261 allowed in RTSP 1.0 [RFC2326]. 5263 17.4.17. 453 Not Enough Bandwidth 5265 The request was refused because there was insufficient bandwidth. 5266 This may, for example, be the result of a resource reservation 5267 failure. 5269 17.4.18. 454 Session Not Found 5271 The RTSP session identifier in the Session header is missing, 5272 invalid, or has timed out. 5274 17.4.19. 455 Method Not Valid in This State 5276 The client or server cannot process this request in its current 5277 state. The response MUST contain an Allow header to make error 5278 recovery possible. 5280 17.4.20. 456 Header Field Not Valid for Resource 5282 The server could not act on a required request header. For example, 5283 if PLAY contains the Range header field but the stream does not allow 5284 seeking. This error message may also be used for specifying when the 5285 time format in Range is impossible for the resource. In that case 5286 the Accept-Ranges header MUST be returned to inform the client of 5287 which format(s) that are allowed. 5289 17.4.21. 457 Invalid Range 5291 The Range value given is out of bounds, e.g., beyond the end of the 5292 presentation. 5294 17.4.22. 458 Parameter Is Read-Only 5296 The parameter to be set by SET_PARAMETER can be read but not 5297 modified. When returning this error message the sender SHOULD return 5298 a message body containing the offending parameter(s). 5300 17.4.23. 459 Aggregate Operation Not Allowed 5302 The requested method may not be applied on the URI in question since 5303 it is an aggregate (presentation) URI. The method may be applied on 5304 a media URI. 5306 17.4.24. 460 Only Aggregate Operation Allowed 5308 The requested method may not be applied on the URI in question since 5309 it is not an aggregate control (presentation) URI. The method may be 5310 applied on the aggregate control URI. 5312 17.4.25. 461 Unsupported Transport 5314 The Transport field did not contain a supported transport 5315 specification. 5317 17.4.26. 462 Destination Unreachable 5319 The data transmission channel could not be established because the 5320 client address could not be reached. This error will most likely be 5321 the result of a client attempt to place an invalid dest_addr 5322 parameter in the Transport field. 5324 17.4.27. 463 Destination Prohibited 5326 The data transmission channel was not established because the server 5327 prohibited access to the client address. This error is most likely 5328 the result of a client attempt to redirect media traffic to another 5329 destination with a dest_addr parameter in the Transport header. 5331 17.4.28. 464 Data Transport Not Ready Yet 5333 The data transmission channel to the media destination is not yet 5334 ready for carrying data. However, the responding agent still expects 5335 that the data transmission channel will be established at some point 5336 in time. Note, however, that this may result in a permanent failure 5337 like 462 "Destination Unreachable". 5339 An example when this error may occur is in the case a client sends a 5340 PLAY request to a server prior to ensuring that the TCP connections 5341 negotiated for carrying media data was successfully established (In 5342 violation of this specification). The server would use this error 5343 code to indicate that the requested action could not be performed due 5344 to the failure of completing the connection establishment. 5346 17.4.29. 465 Notification Reason Unknown 5348 This indicates that the client has received a PLAY_NOTIFY 5349 (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to 5350 the client. 5352 17.4.30. 466 Key Management Error 5354 This indicates that there has been an error in a Key Management 5355 function used in conjunction with a request. For example usage of 5356 MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this 5357 error. 5359 17.4.31. 470 Connection Authorization Required 5361 The secured connection attempt needs user or client authorization 5362 before proceeding. The next hop's certificate is included in this 5363 response in the Accept-Credentials header. 5365 17.4.32. 471 Connection Credentials not accepted 5367 When performing a secure connection over multiple connections, an 5368 intermediary has refused to connect to the next hop and carry out the 5369 request due to unacceptable credentials for the used policy. 5371 17.4.33. 472 Failure to establish secure connection 5373 A proxy fails to establish a secure connection to the next hop RTSP 5374 agent. This is primarily caused by a fatal failure at the TLS 5375 handshake, for example due to server not accepting any cipher suites. 5377 17.5. Server Error 5xx 5379 Response status codes beginning with the digit "5" indicate cases in 5380 which the server is aware that it has erred or is incapable of 5381 performing the request The server SHOULD include a message body 5382 containing an explanation of the error situation, and whether it is a 5383 temporary or permanent condition. User agents SHOULD display any 5384 included message body to the user. These response codes are 5385 applicable to any request method. 5387 17.5.1. 500 Internal Server Error 5389 The server encountered an unexpected condition which prevented it 5390 from fulfilling the request. 5392 17.5.2. 501 Not Implemented 5394 The server does not support the functionality required to fulfill the 5395 request. This is the appropriate response when the server does not 5396 recognize the request method and is not capable of supporting it for 5397 any resource. 5399 17.5.3. 502 Bad Gateway 5401 The server, while acting as a gateway or proxy, received an invalid 5402 response from the upstream server it accessed in attempting to 5403 fulfill the request. 5405 17.5.4. 503 Service Unavailable 5407 The server is currently unable to handle the request due to a 5408 temporary overloading or maintenance of the server. The implication 5409 is that this is a temporary condition which will be alleviated after 5410 some delay. If known, the length of the delay MAY be indicated in a 5411 Retry-After header. If no Retry-After is given, the client SHOULD 5412 handle the response as it would for a 500 response. The client MUST 5413 honor the length, if given in the Retry-After header. 5415 Note: The existence of the 503 status code does not imply that 5416 a server must use it when becoming overloaded. Some servers 5417 may wish to simply refuse the connection. 5419 The response scope is dependent on the Request. If the request was 5420 in relation to an existing RTSP session, the scope of the overload 5421 response is to this individual RTSP session. If the request was non- 5422 session specific or intended to form a RTSP session it applies to the 5423 RTSP server identified by the host name in the request URI. 5425 17.5.5. 504 Gateway Timeout 5427 The server, while acting as a proxy, did not receive a timely 5428 response from the upstream server specified by the URI or some other 5429 auxiliary server (e.g., DNS) it needed to access in attempting to 5430 complete the request. 5432 17.5.6. 505 RTSP Version Not Supported 5434 The server does not support, or refuses to support, the RTSP protocol 5435 version that was used in the request message. The server is 5436 indicating that it is unable or unwilling to complete the request 5437 using the same major version as the client other than with this error 5438 message. The response SHOULD contain a message body describing why 5439 that version is not supported and what other protocols are supported 5440 by that server. 5442 17.5.7. 551 Option not supported 5444 A feature-tag given in the Require or the Proxy-Require fields was 5445 not supported. The Unsupported header MUST be returned stating the 5446 feature for which there is no support. 5448 17.5.8. 553 Proxy Unavailable 5450 The proxy is currently unable to handle the request due to a 5451 temporary overloading or maintenance of the proxy. The implication 5452 is that this is a temporary condition which will be alleviated after 5453 some delay. If known, the length of the delay MAY be indicated in a 5454 Retry-After header. If no Retry-After is given, the client SHOULD 5455 handle the response as it would for a 500 response. The client MUST 5456 honor the length, if given in the Retry-After header. 5458 Note: The existence of the 553 status code does not imply that 5459 a proxy must use it when becoming overloaded. Some proxies may 5460 wish to simply refuse the connection. 5462 The response scope is dependent on the Request. If the request was 5463 in relation to an existing RTSP session, the scope of the overload 5464 response is to this individual RTSP session. If the request was non- 5465 session specific or intended to form a RTSP session it applies to all 5466 such requests to this proxy. 5468 18. Header Field Definitions 5470 +---------------+----------------+--------+---------+------+ 5471 | method | direction | object | acronym | Body | 5472 +---------------+----------------+--------+---------+------+ 5473 | DESCRIBE | C -> S | P,S | DES | r | 5474 | | | | | | 5475 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 5476 | | | | | | 5477 | OPTIONS | C -> S, S -> C | P,S | OPT | | 5478 | | | | | | 5479 | PAUSE | C -> S | P,S | PSE | | 5480 | | | | | | 5481 | PLAY | C -> S | P,S | PLY | | 5482 | | | | | | 5483 | PLAY_NOTIFY | S -> C | P,S | PNY | R | 5484 | | | | | | 5485 | REDIRECT | S -> C | P,S | RDR | | 5486 | | | | | | 5487 | SETUP | C -> S | S | STP | | 5488 | | | | | | 5489 | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | 5490 | | | | | | 5491 | TEARDOWN | C -> S | P,S | TRD | | 5492 | | | | | | 5493 | | S -> C | P | TRD | | 5494 +---------------+----------------+--------+---------+------+ 5496 Table 8: Overview of RTSP methods, their direction, and what objects 5497 (P: presentation, S: stream) they operate on. Body notes if a method 5498 is allowed to carry body and in which direction, R = Request, 5499 r=response. Note: All error messages for statuses 4xx and 5xx are 5500 allowed to carry a body 5502 The general syntax for header fields is covered in Section 5.2. This 5503 section lists the full set of header fields along with notes on 5504 meaning, and usage. The syntax definition for header fields are 5505 present in Section 20.2.3. Throughout this section, we use [HX.Y] to 5506 reference Section X.Y of the current HTTP/1.1 specification RFC 2616 5507 [RFC2616]. Examples of each header field are given. 5509 Information about header fields in relation to methods and proxy 5510 processing is summarized in Table 9, Table 10, Table 11, and 5511 Table 12. 5513 The "where" column describes the request and response types in which 5514 the header field can be used. Values in this column are: 5516 R: header field may only appear in requests; 5518 r: header field may only appear in responses; 5520 2xx, 4xx, etc.: A numerical value or range indicates response codes 5521 with which the header field can be used; 5523 c: header field is copied from the request to the response. 5525 An empty entry in the "where" column indicates that the header field 5526 may be present in both requests and responses. 5528 The "proxy" column describes the operations a proxy may perform on a 5529 header field. An empty proxy column indicates that the proxy MUST 5530 NOT do any changes to that header, all allowed operations are 5531 explicitly stated: 5533 a: A proxy can add or concatenate the header field if not present. 5535 m: A proxy can modify an existing header field value. 5537 d: A proxy can delete a header field value. 5539 r: A proxy needs to be able to read the header field, and thus 5540 this header field cannot be encrypted. 5542 The rest of the columns relate to the presence of a header field in a 5543 method. The method names when abbreviated, are according to Table 8: 5545 c: Conditional; requirements on the header field depend on the 5546 context of the message. 5548 m: The header field is mandatory. 5550 m*: The header field SHOULD be sent, but clients/servers need to be 5551 prepared to receive messages without that header field. 5553 o: The header field is optional. 5555 *: The header field MUST be present if the message body is not 5556 empty. See Section 18.17, Section 18.19 and Section 5.3 for 5557 details. 5559 -: The header field is not applicable. 5561 "Optional" means that a Client/Server MAY include the header field in 5562 a request or response. The Client/Server behavior when receiving 5563 such headers varies, for some it may ignore the header field, in 5564 other cases it is a request to process the header. This is regulated 5565 by the method and header descriptions. Example of headers that 5566 require processing are the Require and Proxy-Require header fields 5567 discussed in Section 18.43 and Section 18.37. A "mandatory" header 5568 field MUST be present in a request, and MUST be understood by the 5569 Client/Server receiving the request. A mandatory response header 5570 field MUST be present in the response, and the header field MUST be 5571 understood by the Client/Server processing the response. "Not 5572 applicable" means that the header field MUST NOT be present in a 5573 request. If one is placed in a request by mistake, it MUST be 5574 ignored by the Client/Server receiving the request. Similarly, a 5575 header field labeled "not applicable" for a response means that the 5576 Client/Server MUST NOT place the header field in the response, and 5577 the Client/Server MUST ignore the header field in the response. 5579 An RTSP agent MUST ignore extension headers that are not understood. 5581 The From and Location header fields contain an URI. If the URI 5582 contains a comma, or semicolon, the URI MUST be enclosed in double 5583 quotes ("). Any URI parameters are contained within these quotes. 5584 If the URI is not enclosed in double quote, any semicolon-delimited 5585 parameters are header-parameters, not URI parameters. 5587 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5588 | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | 5589 | | | xy | S | | | | | | 5590 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5591 | Accept | R | | o | - | - | - | - | - | 5592 | | | | | | | | | | 5593 | Accept-Credentia | R | rm | o | o | o | o | o | o | 5594 | ls | | | | | | | | | 5595 | | | | | | | | | | 5596 | Accept-Encoding | R | r | o | - | - | - | - | - | 5597 | | | | | | | | | | 5598 | Accept-Language | R | r | o | - | - | - | - | - | 5599 | | | | | | | | | | 5600 | Accept-Ranges | R | r | - | - | m | - | - | - | 5601 | | | | | | | | | | 5602 | Accept-Ranges | r | r | - | - | m | - | - | - | 5603 | | | | | | | | | | 5604 | Accept-Ranges | 456 | r | - | - | - | m | - | - | 5605 | | | | | | | | | | 5606 | Allow | r | am | c | c | c | - | - | - | 5607 | | | | | | | | | | 5608 | Allow | 405 | am | m | m | m | m | m | m | 5609 | | | | | | | | | | 5610 | Authentication-I | r | | o | o | o | o | o | o/- | 5611 | nfo | | | | | | | | | 5612 | Authorization | R | | o | o | o | o | o | o | 5613 | | | | | | | | | | 5614 | Bandwidth | R | | o | o | o | o | - | - | 5615 | | | | | | | | | | 5616 | Blocksize | R | | o | - | o | o | - | - | 5617 | | | | | | | | | | 5618 | Cache-Control | | r | o | - | o | - | - | - | 5619 | | | | | | | | | | 5620 | Connection | | ad | o | o | o | o | o | o | 5621 | | | | | | | | | | 5622 | Connection-Crede | 470,4 | ar | o | o | o | o | o | o | 5623 | ntials | 07 | | | | | | | | 5624 | | | | | | | | | | 5625 | Content-Base | r | | o | - | - | - | - | - | 5626 | | | | | | | | | | 5627 | Content-Base | 4xx,5 | | o | o | o | o | o | o | 5628 | | xx | | | | | | | | 5629 | | | | | | | | | | 5630 | Content-Encoding | R | r | - | - | - | - | - | - | 5631 | | | | | | | | | | 5632 | Content-Encoding | r | r | o | - | - | - | - | - | 5633 | | | | | | | | | | 5634 | Content-Encoding | 4xx,5 | r | o | o | o | o | o | o | 5635 | | xx | | | | | | | | 5636 | | | | | | | | | | 5637 | Content-Language | R | r | - | - | - | - | - | - | 5638 | | | | | | | | | | 5639 | Content-Language | r | r | o | - | - | - | - | - | 5640 | | | | | | | | | | 5641 | Content-Language | 4xx,5 | r | o | o | o | o | o | o | 5642 | | xx | | | | | | | | 5643 | | | | | | | | | | 5644 | Content-Length | r | r | * | - | - | - | - | - | 5645 | | | | | | | | | | 5646 | Content-Length | 4xx,5 | r | * | * | * | * | * | * | 5647 | | xx | | | | | | | | 5648 | | | | | | | | | | 5649 | Content-Location | r | r | o | - | - | - | - | - | 5650 | | | | | | | | | | 5651 | Content-Location | 4xx,5 | r | o | o | o | o | o | o | 5652 | | xx | | | | | | | | 5653 | | | | | | | | | | 5654 | Content-Type | r | r | * | - | - | - | - | - | 5655 | | | | | | | | | | 5656 | Content-Type | 4xx,5 | ar | * | * | * | * | * | * | 5657 | | xx | | | | | | | | 5658 | | | | | | | | | | 5659 | CSeq | Rc | rm | m | m | m | m | m | m | 5660 | Date | | am | o/ | o/* | o/* | o/* | o/* | o/* | 5661 | | | | * | | | | | | 5662 | | | | | | | | | | 5663 | Expires | r | r | o | - | o | - | - | - | 5664 | | | | | | | | | | 5665 | From | R | r | o | o | o | o | o | o | 5666 | | | | | | | | | | 5667 | If-Match | R | r | - | - | o | - | - | - | 5668 | | | | | | | | | | 5669 | If-Modified-Sinc | R | r | o | - | o | - | - | - | 5670 | e | | | | | | | | | 5671 | | | | | | | | | | 5672 | If-None-Match | R | r | o | - | o | - | - | - | 5673 | | | | | | | | | | 5674 | Last-Modified | r | r | o | - | o | - | - | - | 5675 | | | | | | | | | | 5676 | Location | 3rr | | o | o | o | o | o | o | 5677 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5679 Table 9: Overview of RTSP header fields (A-L) related to methods 5680 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5682 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5683 | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | 5684 | | | xy | S | T | P | | | | 5685 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5686 | Media- | | | - | - | m | m | m | - | 5687 | Properties | | | | | | | | | 5688 | | | | | | | | | | 5689 | Media-Range | | | - | - | m | m | m | - | 5690 | | | | | | | | | | 5691 | MTag | r | r | o | - | o | - | - | - | 5692 | | | | | | | | | | 5693 | Pipelined-Reques | | amd | - | o | o | o | o | o | 5694 | ts | | r | | | | | | | 5695 | | | | | | | | | | 5696 | Proxy- | 407 | amr | m | m | m | m | m | m | 5697 | Authenticate | | | | | | | | | 5698 | | | | | | | | | | 5699 | Proxy-Authentica | r | amd | o | o | o | o | o | o/- | 5700 | tion-Info | | r | | | | | | | 5701 | | | | | | | | | | 5702 | Proxy- | R | rd | o | o | o | o | o | o | 5703 | Authorization | | | | | | | | | 5704 | | | | | | | | | | 5705 | Proxy- Require | R | ar | o | o | o | o | o | o | 5706 | | | | | | | | | | 5707 | Proxy- Require | r | r | c | c | c | c | c | c | 5708 | Proxy- Supported | R | amr | c | c | c | c | c | c | 5709 | | | | | | | | | | 5710 | Proxy- Supported | r | | c | c | c | c | c | c | 5711 | | | | | | | | | | 5712 | Public | r | amr | - | m | - | - | - | - | 5713 | | | | | | | | | | 5714 | Public | 501 | amr | m | m | m | m | m | m | 5715 | | | | | | | | | | 5716 | Range | R | | - | - | - | o | - | - | 5717 | | | | | | | | | | 5718 | Range | r | | - | - | c | m | m | - | 5719 | | | | | | | | | | 5720 | Referrer | R | | o | o | o | o | o | o | 5721 | | | | | | | | | | 5722 | Request- Status | R | | - | - | - | - | - | - | 5723 | | | | | | | | | | 5724 | Require | R | | o | o | o | o | o | o | 5725 | | | | | | | | | | 5726 | Retry-After | 3rr,503 | | o | o | o | o | o | - | 5727 | | ,553 | | | | | | | | 5728 | | | | | | | | | | 5729 | Retry-After | 413 | | o | - | - | - | - | - | 5730 | | | | | | | | | | 5731 | RTP-Info | r | | - | - | c | c | - | - | 5732 | | | | | | | | | | 5733 | Scale | R | r | - | - | - | o | - | - | 5734 | | | | | | | | | | 5735 | Scale | r | amr | - | - | - | c | - | - | 5736 | | | | | | | | | | 5737 | Seek-Style | R | | - | - | - | o | - | - | 5738 | | | | | | | | | | 5739 | Seek-Style | r | | - | - | - | m | - | - | 5740 | | | | | | | | | | 5741 | Server | R | r | - | o | - | - | - | o | 5742 | | | | | | | | | | 5743 | Server | r | r | o | o | o | o | o | o | 5744 | | | | | | | | | | 5745 | Session | R | r | - | o | o | m | m | m | 5746 | | | | | | | | | | 5747 | Session | r | r | - | c | m | m | m | o | 5748 | | | | | | | | | | 5749 | Speed | R | adm | - | - | - | o | - | - | 5750 | | | r | | | | | | | 5751 | | | | | | | | | | 5752 | Speed | r | adm | - | - | - | c | - | - | 5753 | | | r | | | | | | | 5754 | | | | | | | | | | 5755 | Supported | R | amr | o | o | o | o | o | o | 5756 | Supported | r | amr | c | c | c | c | c | c | 5757 | | | | | | | | | | 5758 | Terminate-Reason | R | r | - | - | - | - | - | - | 5759 | | | | | | | | | | 5760 | Timestamp | R | adm | o | o | o | o | o | o | 5761 | | | r | | | | | | | 5762 | | | | | | | | | | 5763 | Timestamp | c | adm | m | m | m | m | m | m | 5764 | | | r | | | | | | | 5765 | | | | | | | | | | 5766 | Transport | | mr | - | - | m | - | - | - | 5767 | | | | | | | | | | 5768 | Unsupported | r | | c | c | c | c | c | c | 5769 | | | | | | | | | | 5770 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 5771 | | | | | | | | | | 5772 | Via | R | amr | o | o | o | o | o | o | 5773 | | | | | | | | | | 5774 | Via | c | dr | m | m | m | m | m | m | 5775 | | | | | | | | | | 5776 | WWW- | 401 | | m | m | m | m | m | m | 5777 | Authenticate | | | | | | | | | 5778 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5780 Table 10: Overview of RTSP header fields (M-W) related to methods 5781 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5783 +-------------------------+---------+-------+-----+-----+-----+-----+ 5784 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5785 +-------------------------+---------+-------+-----+-----+-----+-----+ 5786 | Accept | R | arm | o | o | - | - | 5787 | | | | | | | | 5788 | Accept-Credentials | R | rm | o | o | o | - | 5789 | | | | | | | | 5790 | Accept-Encoding | R | r | o | o | o | - | 5791 | | | | | | | | 5792 | Accept-Language | R | r | o | o | o | - | 5793 | | | | | | | | 5794 | Accept-Ranges | | rm | o | - | - | - | 5795 | | | | | | | | 5796 | Allow | 405 | amr | m | m | m | - | 5797 | | | | | | | | 5798 | Authentication-Info | r | | o/- | o/- | - | - | 5799 | | | | | | | | 5800 | Authorization | R | | o | o | o | - | 5801 | | | | | | | | 5802 | Bandwidth | R | | - | o | - | - | 5803 | | | | | | | | 5804 | Blocksize | R | | - | o | - | - | 5805 | | | | | | | | 5806 | Cache-Control | | r | o | o | - | - | 5807 | | | | | | | | 5808 | Connection | | | o | o | o | o | 5809 | | | | | | | | 5810 | Connection-Credentials | 470,407 | ar | o | o | o | - | 5811 | | | | | | | | 5812 | Content-Base | R | | o | o | - | - | 5813 | | | | | | | | 5814 | Content-Base | r | | o | o | - | - | 5815 | | | | | | | | 5816 | Content-Base | 4xx,5xx | | o | o | o | o | 5817 | | | | | | | | 5818 | Content-Encoding | R | r | o | o | - | - | 5819 | | | | | | | | 5820 | Content-Encoding | r | r | o | o | - | - | 5821 | | | | | | | | 5822 | Content-Encoding | 4xx,5xx | r | o | o | o | o | 5823 | | | | | | | | 5824 | Content-Language | R | r | o | o | - | - | 5825 | | | | | | | | 5826 | Content-Language | r | r | o | o | - | - | 5827 | | | | | | | | 5828 | Content-Language | 4xx,5xx | r | o | o | o | o | 5829 | | | | | | | | 5830 | Content-Length | R | r | * | * | - | - | 5831 | | | | | | | | 5832 | Content-Length | r | r | * | * | - | - | 5833 | | | | | | | | 5834 | Content-Length | 4xx,5xx | r | * | * | * | * | 5835 | | | | | | | | 5836 | Content-Location | R | | o | o | - | - | 5837 | | | | | | | | 5838 | Content-Location | r | | o | o | - | - | 5839 | | | | | | | | 5840 | Content-Location | 4xx,5xx | | o | o | o | o | 5841 | | | | | | | | 5842 | Content-Type | R | | * | * | - | - | 5843 | | | | | | | | 5844 | Content-Type | r | | * | * | - | - | 5845 | | | | | | | | 5846 | Content-Type | 4xx,5xx | | * | * | * | * | 5847 | | | | | | | | 5848 | CSeq | R,c | mr | m | m | m | m | 5849 | | | | | | | | 5850 | Date | R | a | o | o | m | o | 5851 | | | | | | | | 5852 | Date | r | am | o | o | o | o | 5853 | | | | | | | | 5854 | Expires | r | r | - | - | - | - | 5855 | | | | | | | | 5856 | From | R | r | o | o | o | - | 5857 | | | | | | | | 5858 | If-Match | R | r | - | - | - | - | 5859 | | | | | | | | 5860 | If-Modified-Since | R | am | o | - | - | - | 5861 | | | | | | | | 5862 | If-None-Match | R | am | o | - | - | - | 5863 | | | | | | | | 5864 | Last-Modified | R | r | - | - | - | - | 5865 | | | | | | | | 5866 | Last-Modified | r | r | o | - | - | - | 5867 | | | | | | | | 5868 | Location | 3rr | | o | o | o | - | 5869 | | | | | | | | 5870 | Location | R | | - | - | m | - | 5871 | | | | | | | | 5872 | Media-Properties | R | amr | o | - | - | c | 5873 | | | | | | | | 5874 | Media-Properties | r | mr | c | - | - | - | 5875 | | | | | | | | 5876 | Media-Range | R | | o | - | - | c | 5877 | | | | | | | | 5878 | Media-Range | r | | c | - | - | - | 5879 | | | | | | | | 5880 | MTag | r | r | o | - | - | - | 5881 | | | | | | | | 5882 | Notify-Reason | R | | - | - | - | m | 5883 | | | | | | | | 5884 | Pipelined-Requests | R | amdr | o | o | - | - | 5885 | | | | | | | | 5886 | Proxy-Authenticate | 407 | amdr | m | m | m | - | 5887 | | | | | | | | 5888 | Proxy-Authentication-In | r | amdr | o/- | o/- | - | - | 5889 | fo | | | | | | | 5890 | | | | | | | | 5891 | Proxy-Authorization | R | amdr | o | o | o | - | 5892 | | | | | | | | 5893 | Proxy-Require | R | ar | o | o | o | - | 5894 | | | | | | | | 5895 | Proxy-Supported | R | amr | c | c | c | - | 5896 | | | | | | | | 5897 | Proxy-Supported | r | | c | c | c | - | 5898 | | | | | | | | 5899 | Public | 501 | admr | m | m | m | - | 5900 +-------------------------+---------+-------+-----+-----+-----+-----+ 5902 Table 11: Overview of RTSP header fields (A-P) related to methods 5903 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5905 +------------------+---------+-------+-----+-----+-----+-----+ 5906 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5907 +------------------+---------+-------+-----+-----+-----+-----+ 5908 | Range | R | | o | - | o | m | 5909 | | | | | | | | 5910 | Referrer | R | | o | o | o | - | 5911 | | | | | | | | 5912 | Request-Status | R | | - | - | - | c | 5913 | | | | | | | | 5914 | Require | R | r | o | o | o | - | 5915 | | | | | | | | 5916 | Retry-After | 3rr,503 | | o | o | - | - | 5917 | | | | | | | | 5918 | Retry-After | 413 | | o | o | - | - | 5919 | | | | | | | | 5920 | RTP-Info | R | r | o | - | - | C | 5921 | | | | | | | | 5922 | RTP-Info | r | r | c | - | - | - | 5923 | | | | | | | | 5924 | Scale | | | - | - | - | c | 5925 | | | | | | | | 5926 | Seek-Style | | | - | - | - | - | 5927 | | | | | | | | 5928 | Server | R | r | o | o | o | o | 5929 | | | | | | | | 5930 | Server | r | r | o | o | - | - | 5931 | | | | | | | | 5932 | Session | R | r | o | o | o | m | 5933 | | | | | | | | 5934 | Session | r | r | c | c | o | m | 5935 | | | | | | | | 5936 | Speed | | | - | - | - | - | 5937 | | | | | | | | 5938 | Supported | R | adrm | o | o | o | - | 5939 | | | | | | | | 5940 | Supported | r | adrm | c | c | c | - | 5941 | | | | | | | | 5942 | Terminate-Reason | R | r | - | - | m | - | 5943 | | | | | | | | 5944 | Timestamp | R | adrm | o | o | o | - | 5945 | | | | | | | | 5946 | Timestamp | c | adrm | m | m | m | - | 5947 | Transport | | mr | - | - | - | - | 5948 | | | | | | | | 5949 | Unsupported | r | arm | c | c | c | - | 5950 | | | | | | | | 5951 | User-Agent | R | r | m* | m* | - | - | 5952 | | | | | | | | 5953 | User-Agent | r | r | m* | m* | m* | m* | 5954 | | | | | | | | 5955 | Via | R | amr | o | o | o | - | 5956 | | | | | | | | 5957 | Via | c | dr | m | m | m | - | 5958 | | | | | | | | 5959 | WWW-Authenticate | 401 | | m | m | m | - | 5960 +------------------+---------+-------+-----+-----+-----+-----+ 5962 Table 12: Overview of RTSP header fields (R-W) related to methods 5963 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5965 18.1. Accept 5967 The Accept request-header field can be used to specify certain 5968 presentation description and parameter media types [RFC6838] which 5969 are acceptable for the response to DESCRIBE and GET_PARAMETER 5970 requests. 5972 See Section 20.2.3 for the syntax. 5974 The asterisk "*" character is used to group media types into ranges, 5975 with "*/*" indicating all media types and "type/*" indicating all 5976 subtypes of that type. The media-range MAY include media type 5977 parameters that are applicable to that range. 5979 Each media-range MAY be followed by one or more accept-params, 5980 beginning with the "q" parameter for indicating a relative quality 5981 factor. The first "q" parameter (if any) separates the media-range 5982 parameter(s) from the accept-params. Quality factors allow the user 5983 or user agent to indicate the relative degree of preference for that 5984 media-range, using the qvalue scale from 0 to 1 (section 3.9). The 5985 default value is q=1. 5987 Example of use: 5989 Accept: application/example ;q=0.7, application/sdp 5991 Indicates that the requesting agent prefers the media type 5992 application/sdp through the default 1.0 rating but also accepts the 5993 application/example media type with a 0.7 quality rating. 5995 If no Accept header field is present, then it is assumed that the 5996 client accepts all media types. If an Accept header field is 5997 present, and if the server cannot send a response which is acceptable 5998 according to the combined Accept field value, then the server SHOULD 5999 send a 406 (not acceptable) response. 6001 18.2. Accept-Credentials 6003 The Accept-Credentials header is a request header used to indicate to 6004 any trusted intermediary how to handle further secured connections to 6005 proxies or servers. See Section 19 for the usage of this header. It 6006 MUST NOT be included in server to client requests. 6008 In a request the header MUST contain the method (User, Proxy, or Any) 6009 for approving credentials selected by the requester. The method MUST 6010 NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY 6011 change it to "user" to take the role of user approving each further 6012 hop. If the method is "User" the header contains zero or more of 6013 credentials that the client accepts. The header may contain zero 6014 credentials in the first RTSP request to a RTSP server when using the 6015 "User" method. This is because the client has not yet received any 6016 credentials to accept. Each credential MUST consist of one URI 6017 identifying the proxy or server, the hash algorithm identifier, and 6018 the hash over that agent's ASN.1 distinguished encoding rules (DER) 6019 encoded certificate [RFC5280] in Base64 [RFC4648]. All RTSP clients 6020 and proxies MUST implement the SHA-256[FIPS-pub-180-2] algorithm for 6021 computation of the hash of the DER encoded certificate. The SHA-256 6022 algorithm is identified by the token "sha-256". 6024 The intention with allowing for other hash algorithms is to enable 6025 the future retirement of algorithms that are not implemented 6026 somewhere else than here. Thus the definition of future algorithms 6027 for this purpose is intended to be extremely limited. A feature tag 6028 can be used to ensure that support for the replacement algorithm 6029 exists. 6031 Example: 6033 Accept-Credentials:User 6034 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 6035 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 6037 18.3. Accept-Encoding 6039 The Accept-Encoding request-header field is similar to Accept, but 6040 restricts the content-codings (see Section 18.15),i.e., 6041 transformation codings of the message body, such as gzip compression, 6042 that are acceptable in the response. 6044 A server tests whether a content-coding is acceptable, according to 6045 an Accept-Encoding field, using these rules: 6047 1. If the content-coding is one of the content-codings listed in the 6048 Accept-Encoding field, then it is acceptable, unless it is 6049 accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of 6050 0 means "not acceptable.") 6052 2. The special "*" symbol in an Accept-Encoding field matches any 6053 available content-coding not explicitly listed in the header 6054 field. 6056 3. If multiple content-codings are acceptable, then the acceptable 6057 content-coding with the highest non-zero qvalue is preferred. 6059 4. The "identity" content-coding is always acceptable, i.e., no 6060 transformation at all, unless specifically refused because the 6061 Accept-Encoding field includes "identity;q=0", or because the 6062 field includes "*;q=0" and does not explicitly include the 6063 "identity" content-coding. If the Accept-Encoding field-value is 6064 empty, then only the "identity" encoding is acceptable. 6066 If an Accept-Encoding field is present in a request, and if the 6067 server cannot send a response which is acceptable according to the 6068 Accept-Encoding header, then the server SHOULD send an error response 6069 with the 406 (Not Acceptable) status code. 6071 If no Accept-Encoding field is present in a request, the server MAY 6072 assume that the client will accept any content coding. In this case, 6073 if "identity" is one of the available content-codings, then the 6074 server SHOULD use the "identity" content-coding, unless it has 6075 additional information that a different content-coding is meaningful 6076 to the client. 6078 18.4. Accept-Language 6080 The Accept-Language request-header field is similar to Accept, but 6081 restricts the set of natural languages that are preferred as a 6082 response to the request. Note that the language specified applies to 6083 the presentation description and any reason phrases, but not the 6084 media content. 6086 A language tag identifies a natural language spoken, written, or 6087 otherwise conveyed by human beings for communication of information 6088 to other human beings. Computer languages are explicitly excluded. 6089 The syntax and registry of RTSP 2.0 language tags is the same as that 6090 defined by [RFC5646]. 6092 Each language-range MAY be given an associated quality value which 6093 represents an estimate of the user's preference for the languages 6094 specified by that range. The quality value defaults to "q=1". For 6095 example: 6097 Accept-Language: da, en-gb;q=0.8, en;q=0.7 6099 would mean: "I prefer Danish, but will accept British English and 6100 other types of English." A language-range matches a language-tag if 6101 it exactly equals the full tag, or if it exactly equals a prefix of 6102 the tag, i.e., the primary-tag in the ABNF, such that the character 6103 following primary-tag is "-". The special range "*", if present in 6104 the Accept-Language field, matches every tag not matched by any other 6105 range present in the Accept-Language field. 6107 Note: This use of a prefix matching rule does not imply that 6108 language tags are assigned to languages in such a way that it is 6109 always true that if a user understands a language with a certain 6110 tag, then this user will also understand all languages with tags 6111 for which this tag is a prefix. The prefix rule simply allows the 6112 use of prefix tags if this is the case. 6114 In the process of selecting a language, each language-tag is assigned 6115 a qualification factor, i.e., if a language being supported by the 6116 client is actually supported by the server and what "preference" 6117 level the language achieves. The quality value (q-value) of the 6118 longest language-range in the field that matches the language-tag is 6119 assigned as the qualification factor for a particular language-tag. 6120 If no language-range in the field matches the tag, the language 6121 qualification factor assigned is 0. If no Accept-Language header is 6122 present in the request, the server SHOULD assume that all languages 6123 are equally acceptable. If an Accept-Language header is present, 6124 then all languages which are assigned a qualification factor greater 6125 than 0 are acceptable. 6127 18.5. Accept-Ranges 6129 The Accept-Ranges general-header field allows indication of the 6130 format supported in the Range header. The client MUST include the 6131 header in SETUP requests to indicate which formats are acceptable 6132 when received in PLAY and PAUSE responses, and REDIRECT requests. 6133 The server MUST include the header in SETUP and 456 error responses 6134 to indicate the formats supported for the resource indicated by the 6135 request URI. The header MAY be included in GET_PARAMETER request and 6136 response pairs. The GET_PARAMETER request MUST contain a Session 6137 header to identify the session context the request is related to. 6138 The requester and responder will indicate their capabilities 6139 regarding Range formats respectively. 6141 Accept-Ranges: npt, smpte, clock 6143 The syntax is defined in Section 20.2.3. 6145 18.6. Allow 6147 The Allow message-header field lists the methods supported by the 6148 resource identified by the Request-URI. The purpose of this field is 6149 to inform the recipient of the complete set of valid methods 6150 associated with the resource. An Allow header field MUST be present 6151 in a 405 (Method Not Allowed) response. The Allow header MUST also 6152 be present in all OPTIONS responses where the content of the header 6153 will not include exactly the same methods as listed in the Public 6154 header. 6156 The Allow message-header MUST also be included in SETUP and DESCRIBE 6157 responses, if the methods allowed for the resource is different from 6158 the complete set of methods defined in this memo. 6160 Example of use: 6162 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 6164 18.7. Authentication-Info 6166 The Authentication-Info header is used by the server to communicate 6167 some information regarding the successful authentication in the 6168 response message. This usage of this header is specified in 6169 [RFC2617] with some RTSP clarification in Section 19.1. This header 6170 MUST only be used in response messages related to client to server 6171 requests. 6173 18.8. Authorization 6175 An RTSP client that wishes to authenticate itself with a server using 6176 authentication mechanism from HTTP [RFC2617] , usually, but not 6177 necessarily, after receiving a 401 response, does so by including an 6178 Authorization request-header field with the request. The 6179 Authorization field value consists of credentials containing the 6180 authentication information of the user agent for the realm of the 6181 resource being requested. This header MUST only be used in client to 6182 server requests. 6184 If a request is authenticated and a realm specified, the same 6185 credentials SHOULD be valid for all other requests within this realm 6186 (assuming that the authentication scheme itself does not require 6187 otherwise, such as credentials that vary according to a challenge 6188 value or using synchronized clocks). 6190 When a shared cache (see Section 16) receives a request containing an 6191 Authorization field, it MUST NOT return the corresponding response as 6192 a reply to any other request, unless one of the following specific 6193 exceptions holds: 6195 1. If the response includes the "max-age" cache-control directive, 6196 the cache MAY use that response in replying to a subsequent 6197 request. But (if the specified maximum age has passed) a proxy 6198 cache MUST first revalidate it with the origin server, using the 6199 request-headers from the new request to allow the origin server 6200 to authenticate the new request. (This is the defined behavior 6201 for max-age.) If the response includes "max-age=0", the proxy 6202 MUST always revalidate it before re-using it. 6204 2. If the response includes the "must-revalidate" cache-control 6205 directive, the cache MAY use that response in replying to a 6206 subsequent request. But if the response is stale, all caches 6207 MUST first revalidate it with the origin server, using the 6208 request-headers from the new request to allow the origin server 6209 to authenticate the new request. 6211 3. If the response includes the "public" cache-control directive, it 6212 MAY be returned in reply to any subsequent request. 6214 18.9. Bandwidth 6216 The Bandwidth request-header field describes the estimated bandwidth 6217 available to the client, expressed as a positive integer and measured 6218 in kilobits per second. The bandwidth available to the client may 6219 change during an RTSP session, e.g., due to mobility, congestion, 6220 etc. 6222 Clients may not be able to accurately determine the available 6223 bandwidth, for example because first hop is not a bottleneck. For 6224 example most local area networks (LAN) will not be a bottleneck if 6225 the server is not in the same LAN. Thus link speeds of WLAN or 6226 Ethernet networks are normally not a basis for estimating the 6227 available bandwidth. Cellular devices or other devices directly 6228 connected to a modem or connection enabling device may more 6229 accurately estimate the bottleneck bandwidth and what is a reasonable 6230 share of it for RTSP controlled media. The client will also need to 6231 take into account other traffic sharing the bottleneck. For example 6232 by only assigning a certain fraction to RTSP and its media streams. 6233 It is RECOMMENDED that only clients that have accurate and explicit 6234 information about bandwidth bottlenecks uses this header. 6236 This header is not a substitute for proper congestion control. It is 6237 only a method providing an initial estimate and coarsely determines 6238 if the selected content can be delivered at all. 6240 Example: 6242 Bandwidth: 62360 6244 18.10. Blocksize 6246 The Blocksize request-header field is sent from the client to the 6247 media server asking the server for a particular media packet size. 6248 This packet size does not include lower-layer headers such as IP, 6249 UDP, or RTP. The server is free to use a blocksize which is lower 6250 than the one requested. The server MAY truncate this packet size to 6251 the closest multiple of the minimum, media-specific block size, or 6252 override it with the media-specific size if necessary. The block 6253 size MUST be a positive decimal number, measured in octets. The 6254 server only returns an error (4xx) if the value is syntactically 6255 invalid. 6257 18.11. Cache-Control 6259 The Cache-Control general-header field is used to specify directives 6260 that MUST be obeyed by all caching mechanisms along the request/ 6261 response chain. 6263 Cache directives MUST be passed through by a proxy or gateway 6264 application, regardless of their significance to that application, 6265 since the directives may be applicable to all recipients along the 6266 request/response chain. It is not possible to specify a cache- 6267 directive for a specific cache. 6269 Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, 6270 SET_PARAMETER and SETUP request and its response. Note: Cache- 6271 Control does not govern just the caching of responses as for HTTP, 6272 instead it also applies to the media stream identified by the SETUP 6273 request. The RTSP requests are generally not cacheable, for further 6274 information see Section 16. Below are the descriptions of the cache 6275 directives that can be included in the Cache-Control header. 6277 no-cache: Indicates that the media stream or RTSP response MUST NOT 6278 be cached anywhere. This allows an origin server to prevent 6279 caching even by caches that have been configured to return 6280 stale responses to client requests. Note, there is no security 6281 function preventing the caching of content. 6283 public: Indicates that the media stream or RTSP response is 6284 cacheable by any cache. 6286 private: Indicates that the media stream or RTSP response is 6287 intended for a single user and MUST NOT be cached by a shared 6288 cache. A private (non-shared) cache may cache the media 6289 streams. 6291 no-transform: An intermediate cache (proxy) may find it useful to 6292 convert the media type of a certain stream. A proxy might, for 6293 example, convert between video formats to save cache space or 6294 to reduce the amount of traffic on a slow link. Serious 6295 operational problems may occur, however, when these 6296 transformations have been applied to streams intended for 6297 certain kinds of applications. For example, applications for 6298 medical imaging, scientific data analysis and those using end- 6299 to-end authentication all depend on receiving a stream that is 6300 bit-for-bit identical to the original media stream or RTSP 6301 response. Therefore, if a response includes the no-transform 6302 directive, an intermediate cache or proxy MUST NOT change the 6303 encoding of the stream or response. Unlike HTTP, RTSP does not 6304 provide for partial transformation at this point, e.g., 6305 allowing translation into a different language. 6307 only-if-cached: In some cases, such as times of extremely poor 6308 network connectivity, a client may want a cache to return only 6309 those media streams or RTSP responses that it currently has 6310 stored, and not to receive these from the origin server. To do 6311 this, the client may include the only-if-cached directive in a 6312 request. If it receives this directive, a cache SHOULD either 6313 respond using a cached media stream or response that is 6314 consistent with the other constraints of the request, or 6315 respond with a 504 (Gateway Timeout) status. However, if a 6316 group of caches is being operated as a unified system with good 6317 internal connectivity, such a request MAY be forwarded within 6318 that group of caches. 6320 max-stale: Indicates that the client is willing to accept a media 6321 stream or RTSP response that has exceeded its expiration time. 6322 If max-stale is assigned a value, then the client is willing to 6323 accept a response that has exceeded its expiration time by no 6324 more than the specified number of seconds. If no value is 6325 assigned to max-stale, then the client is willing to accept a 6326 stale response of any age. 6328 min-fresh: Indicates that the client is willing to accept a media 6329 stream or RTSP response whose freshness lifetime is no less 6330 than its current age plus the specified time in seconds. That 6331 is, the client wants a response that will still be fresh for at 6332 least the specified number of seconds. 6334 must-revalidate: When the must-revalidate directive is present in a 6335 SETUP response received by a cache, that cache MUST NOT use the 6336 cache entry after it becomes stale to respond to a subsequent 6337 request without first revalidating it with the origin server. 6338 That is, the cache is required to do an end-to-end revalidation 6339 every time, if, based solely on the origin server's Expires, 6340 the cached response is stale. 6342 proxy-revalidate: The proxy-revalidate directive has the same 6343 meaning as the must-revalidate directive, except that it does 6344 not apply to non-shared user agent caches. It can be used on a 6345 response to an authenticated request to permit the user's cache 6346 to store and later return the response without needing to 6347 revalidate it (since it has already been authenticated once by 6348 that user), while still requiring proxies that service many 6349 users to revalidate each time (in order to make sure that each 6350 user has been authenticated). Note that such authenticated 6351 responses also need the public cache control directive in order 6352 to allow them to be cached at all. 6354 max-age: When an intermediate cache is forced, by means of a max- 6355 age=0 directive, to revalidate its own cache entry, and the 6356 client has supplied its own validator in the request, the 6357 supplied validator might differ from the validator currently 6358 stored with the cache entry. In this case, the cache MAY use 6359 either validator in making its own request without affecting 6360 semantic transparency. 6362 However, the choice of validator might affect performance. The 6363 best approach is for the intermediate cache to use its own 6364 validator when making its request. If the server replies with 6365 304 (Not Modified), then the cache can return its now validated 6366 copy to the client with a 200 (OK) response. If the server 6367 replies with a new message body and cache validator, however, 6368 the intermediate cache can compare the returned validator with 6369 the one provided in the client's request, using the strong 6370 comparison function. If the client's validator is equal to the 6371 origin server's, then the intermediate cache simply returns 304 6372 (Not Modified). Otherwise, it returns the new message body 6373 with a 200 (OK) response. 6375 18.12. Connection 6377 The Connection general-header field allows the sender to specify 6378 options that are desired for that particular connection. It MUST NOT 6379 be communicated by proxies over further connections. 6381 RTSP 2.0 proxies MUST parse the Connection header field before a 6382 message is forwarded and, for each connection-token in this field, 6383 remove any header field(s) from the message with the same name as the 6384 connection-token. Connection options are signaled by the presence of 6385 a connection-token in the Connection header field, not by any 6386 corresponding additional header field(s), since the additional header 6387 field may not be sent if there are no parameters associated with that 6388 connection option. 6390 Message headers listed in the Connection header MUST NOT include end- 6391 to-end headers, such as Cache-Control. 6393 RTSP 2.0 defines the "close" connection option for the sender to 6394 signal that the connection will be closed after completion of the 6395 response. For example, Connection: close in either the request or 6396 the response header fields indicates that the connection SHOULD NOT 6397 be considered `persistent' (Section 10.2) after the current request/ 6398 response is complete. 6400 The use of the connection option "close" in RTSP messages SHOULD be 6401 limited to error messages when the server is unable to recover and 6402 therefore sees it necessary to close the connection. The reason is 6403 that the client has the choice of continuing using a connection 6404 indefinitely, as long as it sends valid messages. 6406 18.13. Connection-Credentials 6408 The Connection-Credentials response header is used to carry the chain 6409 of credentials for any next hop that needs to be approved by the 6410 requester. It MUST only be used in server to client responses. 6412 The Connection-Credentials header in an RTSP response MUST, if 6413 included, contain the credential information (in form of a list of 6414 certificates providing the chain of certification) of the next hop 6415 that an intermediary needs to securely connect to. The header MUST 6416 include the URI of the next hop (proxy or server) and a base64 6417 [RFC4648] encoded binary structure containing a sequence of DER 6418 encoded X.509v3 certificates[RFC5280] . 6420 The binary structure starts with the number of certificates 6421 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 6422 by NR_CERTS number of 16 bit unsigned integers providing the size in 6423 octets of each DER encoded certificate. This is followed by NR_CERTS 6424 number of DER encoded X.509v3 certificates in a sequence (chain). 6425 This format is exemplified in Figure 2. The proxy or server's 6426 certificate must come first in the structure. Each following 6427 certificate must directly certify the one preceding it. Because 6428 certificate validation requires that root keys be distributed 6429 independently, the self-signed certificate which specifies the root 6430 certificate authority may optionally be omitted from the chain, under 6431 the assumption that the remote end must already possess it in order 6432 to validate it in any case. 6434 Example: 6436 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 6438 Where MIIDNTCC... is a Base64 encoding of the following structure: 6440 0 1 2 3 6441 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 6442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6443 | Number of certificates | Size of certificate #1 | 6444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6445 | Size of certificate #2 | Size of certificate #3 | 6446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6447 : DER Encoding of Certificate #1 : 6448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6449 : DER Encoding of Certificate #2 : 6450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6451 : DER Encoding of Certificate #3 : 6452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6454 Figure 2: Connection-Credentials header's Certificate Format Example 6456 18.14. Content-Base 6458 The Content-Base message-header field may be used to specify the base 6459 URI for resolving relative URIs within the message body. 6461 Content-Base: rtsp://media.example.com/movie/twister/ 6463 If no Content-Base field is present, the base URI of an message body 6464 is defined either by its Content-Location (if that Content-Location 6465 URI is an absolute URI) or the URI used to initiate the request, in 6466 that order of precedence. Note, however, that the base URI of the 6467 contents within the message-body may be redefined within that 6468 message-body. 6470 18.15. Content-Encoding 6472 The Content-Encoding message-header field is used as a modifier to 6473 the media-type. When present, its value indicates what additional 6474 content codings have been applied to the message body, and thus what 6475 decoding mechanisms must be applied in order to obtain the media-type 6476 referenced by the Content-Type header field. Content-Encoding is 6477 primarily used to allow a document to be compressed without losing 6478 the identity of its underlying media type. 6480 The content-coding is a characteristic of the message body identified 6481 by the Request-URI. Typically, the message body is stored with this 6482 encoding and is only decoded before rendering or analogous usage. 6483 However, an RTSP proxy MAY modify the content-coding if the new 6484 coding is known to be acceptable to the recipient, unless the "no- 6485 transform" cache-control directive is present in the message. 6487 If the content-coding of a message body is not "identity", then the 6488 response MUST include a Content-Encoding Message-body header that 6489 lists the non-identity content-coding(s) used. 6491 If the content-coding of a message body in a request message is not 6492 acceptable to the origin server, the server SHOULD respond with a 6493 status code of 415 (Unsupported Media Type). 6495 If multiple encodings have been applied to a message body, the 6496 content codings MUST be listed in the order in which they were 6497 applied, first to last from left to right. Additional information 6498 about the encoding parameters MAY be provided by other header fields 6499 not defined by this specification. 6501 18.16. Content-Language 6503 The Content-Language message-header field describes the natural 6504 language(s) of the intended audience for the enclosed message body. 6505 Note that this might not be equivalent to all the languages used 6506 within the message body. 6508 Language tags are mentioned in Section 18.4. The primary purpose of 6509 Content-Language is to allow a user to identify and differentiate 6510 entities according to the user's own preferred language. Thus, if 6511 the body content is intended only for a Danish-literate audience, the 6512 appropriate field is 6513 Content-Language: da 6515 If no Content-Language is specified, the default is that the content 6516 is intended for all language audiences. This might mean that the 6517 sender does not consider it to be specific to any natural language, 6518 or that the sender does not know for which language it is intended. 6520 Multiple languages MAY be listed for content that is intended for 6521 multiple audiences. For example, a rendition of the "Treaty of 6522 Waitangi," presented simultaneously in the original Maori and English 6523 versions, would call for 6525 Content-Language: mi, en 6527 However, just because multiple languages are present within a message 6528 body does not mean that it is intended for multiple linguistic 6529 audiences. An example would be a beginner's language primer, such as 6530 "A First Lesson in Latin," which is clearly intended to be used by an 6531 English-literate audience. In this case, the Content-Language would 6532 properly only include "en". 6534 Content-Language MAY be applied to any media type -- it is not 6535 limited to textual documents. 6537 18.17. Content-Length 6539 The Content-Length message-header field contains the length of the 6540 message body of the RTSP message (i.e., after the double CRLF 6541 following the last header). Unlike HTTP, it MUST be included in all 6542 messages that carry a message body beyond the header portion of the 6543 RTSP message. If it is missing, a default value of zero is assumed. 6544 Any Content-Length greater than or equal to zero is a valid value. 6546 18.18. Content-Location 6548 The Content-Location message-header field MAY be used to supply the 6549 resource location for the message body enclosed in the message when 6550 that body is accessible from a location separate from the requested 6551 resource's URI. A server SHOULD provide a Content-Location for the 6552 variant corresponding to the response message body; especially in the 6553 case where a resource has multiple variants associated with it, and 6554 those entities actually have separate locations by which they might 6555 be individually accessed, the server SHOULD provide a Content- 6556 Location for the particular variant which is returned. 6558 As example, if an RTSP client performs a DESCRIBE request on a given 6559 resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", 6560 then the server may use additional information, such as the User- 6561 Agent header, to determine the capabilities of the agent. The server 6562 will then return a media description tailored to that class of RTSP 6563 agents. To indicate which specific description the agent receives 6564 the resource identifier 6565 ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is 6566 provided in Content-Location, while the description is still a valid 6567 response for the generic resource identifier. Thus enabling both 6568 debugging and cache operation as discussed below. 6570 The Content-Location value is not a replacement for the original 6571 requested URI; it is only a statement of the location of the resource 6572 corresponding to this particular variant at the time of the request. 6573 Future requests MAY specify the Content-Location URI as the request 6574 URI if the desire is to identify the source of that particular 6575 variant. This is useful if the RTSP agent desires to verify if the 6576 resource variant is current through a conditional request. 6578 A cache cannot assume that a message body with a Content-Location 6579 different from the URI used to retrieve it can be used to respond to 6580 later requests on that Content-Location URI. However, the Content- 6581 Location can be used to differentiate between multiple variants 6582 retrieved from a single requested resource. 6584 If the Content-Location is a relative URI, the relative URI is 6585 interpreted relative to the Request-URI. 6587 Note, that Content-Location can be used in some cases to derive the 6588 base-URI for relative URI(s) present in session description formats. 6589 This needs to be taken into account when Content-Location is used. 6590 The easiest way to avoid needing to consider that issue is to include 6591 the Content-Base whenever the Content-Location is included. 6593 Note also, when using Media Tags in conjunction with Content-Location 6594 it is important that the different versions have different MTags, 6595 even if provided under different Content-Location URIs. This as they 6596 have still been provided under the same request URI. 6598 Note also, as in most cases the URI used in the DESCRIBE and the 6599 SETUP requests are different, the URI provided in a DESCRIBE Content- 6600 Location response can't directly be used in a SETUP request. Instead 6601 the extra step of resolving URIs combined with the media descriptions 6602 indication, like with SDP's a=control attribute. 6604 18.19. Content-Type 6606 The Content-Type message-header indicates the media type of the 6607 message body sent to the recipient. Note that the content types 6608 suitable for RTSP are likely to be restricted in practice to 6609 presentation descriptions and parameter-value types. 6611 18.20. CSeq 6613 The CSeq general-header field specifies the sequence number for an 6614 RTSP request-response pair. This field MUST be present in all 6615 requests and responses. For every RTSP request containing the given 6616 sequence number, the corresponding response will have the same 6617 number. For each new RTSP request an agent creates the CSeq value 6618 MUST be incremented by one. This primarily allows for associating 6619 requests with responses. It also enables detecting loss of a request 6620 and await a retransmission prior to processing a sub-sequent request 6621 when using unreliable transport. Any retransmitted request MUST 6622 contain the same sequence number as the original, i.e., the sequence 6623 number is not incremented for retransmissions of the same request. 6624 Agents receiving a request over a reliable transport with an in-order 6625 delivery MUST ignore how the sequence value increments, i.e. it can 6626 increment with other values than 1. The initial sequence number MAY 6627 be any number, however, it is RECOMMENDED to start at 0. Each 6628 sequence number series is unique between each requester and 6629 responder, i.e., the client has one series for its request to a 6630 server and the server has another when sending request to the client. 6631 Each requester and responder is identified with its socket address 6632 (IP address and port number), i.e., per direction of a TCP 6633 connection. 6635 The above rules may appear unnecessary loose. However, they are 6636 allowing for a behavior which is not uncommon. When using multiple 6637 connections in sequence it may still be easiest to use a single 6638 sequence number series for a client connecting with a particular 6639 server. Thus, the initial sequence number may be arbitrary depending 6640 on the number of previous requests. 6642 Proxies that aggregate several client sessions on the same transport 6643 will have to ensure that the requests sent towards a particular 6644 server have a joint sequence number space. A proxy having one client 6645 with concurrent sessions with two different servers using the same 6646 client proxy connection can avoid rewriting on the proxy to server 6647 connection. The latest equally applies to server to client requests, 6648 where one server may have multiple clients over the same proxy. The 6649 proxy can use only one joint sequence number space for a given 6650 transport connection to a particular server for sending request, as 6651 the identification of the RTSP agents, i.e., the proxy and the server 6652 is based on the IP address and port number. This requires that the 6653 proxy renumbers the CSeq header field in both requests and responses 6654 to fulfill the rules for the header. 6656 An RTSP proxy MUST renumber the RTSP request from RTSP agents that 6657 are sent to a particular RTSP agent in order to preserve the joint 6658 sequence number space on the connection between the proxy and the 6659 agent. The RTSP proxy MUST increase the CSeq for each request it 6660 transmits over a particular transport connection or transport flow, 6661 without regard of different sessions. 6663 An RTSP proxy MUST renumber RTSP responses back to the sequence 6664 number that the corresponding request had when originally received by 6665 the proxy before forwarding it to the RTSP agent. 6667 A proxy that forwards responses from multiple RTSP agents towards a 6668 specific agent MUST maintain the order between request/responses on a 6669 per incoming connection basis. This means that different RTSP 6670 sessions are handled over the same same transport connection between 6671 proxy and the specific agent. 6673 Given that the RTSP proxy and the agents are using reliable transport 6674 connections, the proxy MAY forward received responses without 6675 considering the response's relation to responses from other 6676 connections which will share the same outgoing transport connection 6677 from the proxy. 6679 Note: This exception is to avoid responses being blocked by 6680 other agents being slow to respond. This can result in out-of- 6681 order delivery of responses arriving at the RTSP client in 6682 relation to the transport connection, but that delivery is in- 6683 order with respect to the RTSP agent and any session. 6685 18.21. Date 6687 The Date general-header field represents the date and time at which 6688 the message was originated. The inclusion of the Date header in RTSP 6689 message follows these rules: 6691 o An RTSP message, sent either by the client or the server, 6692 containing a body MUST include a Date header, if the sending host 6693 has a clock; 6695 o Clients and servers are RECOMMENDED to include a Date header in 6696 all other RTSP messages, if the sending host has a clock; 6698 o If the server does not have a clock that can provide a reasonable 6699 approximation of the current time, its responses MUST NOT include 6700 a Date header field. In this case, this rule MUST be followed: 6701 Some origin server implementations might not have a clock 6702 available. An origin server without a clock MUST NOT assign 6703 Expires or Last-Modified values to a response, unless these values 6704 were associated with the resource by a system or user with a 6705 reliable clock. It MAY assign an Expires value that is known, at 6706 or before server configuration time, to be in the past (this 6707 allows "pre-expiration" of responses without storing separate 6708 Expires values for each resource). 6710 A received message that does not have a Date header field MUST be 6711 assigned one by the recipient if the message will be cached by that 6712 recipient. An RTSP implementation without a clock MUST NOT cache 6713 responses without revalidating them on every use. An RTSP cache, 6714 especially a shared cache, SHOULD use a mechanism, such as NTP, to 6715 synchronize its clock with a reliable external standard. 6717 The RTSP-date, a full date as specified by Section 3.3 of [RFC2822], 6718 sent in a Date header SHOULD NOT represent a date and time subsequent 6719 to the generation of the message. It SHOULD represent the best 6720 available approximation of the date and time of message generation, 6721 unless the implementation has no means of generating a reasonably 6722 accurate date and time. In theory, the date ought to represent the 6723 moment just before the message body is generated. In practice, the 6724 date can be generated at any time during the message origination 6725 without affecting its semantic value. 6727 Note: The RTSP 2.0 date is defined as RFC 2822 format date. This 6728 format is more allowing than the RTSP 1.0 and earlier draft 6729 versions using RFC 1123 date format. Thus implementations should 6730 use single spaces as recommended as separators and support 6731 receiving the obsoleted identifiers. 6733 18.22. Expires 6735 The Expires message-header field gives a date and time after which 6736 the description or media-stream should be considered stale. The 6737 interpretation depends on the method: 6739 DESCRIBE response: The Expires header indicates a date and time 6740 after which the presentation description (body) SHOULD be 6741 considered stale. 6743 SETUP response: The Expires header indicate a date and time after 6744 which the media stream SHOULD be considered stale. 6746 A stale cache entry may not normally be returned by a cache (either a 6747 proxy cache or an user agent cache) unless it is first validated with 6748 the origin server (or with an intermediate cache that has a fresh 6749 copy of the message body). See Section 16 for further discussion of 6750 the expiration model. 6752 The presence of an Expires field does not imply that the original 6753 resource will change or cease to exist at, before, or after that 6754 time. 6756 The format is an absolute date and time as defined by RTSP-date. An 6757 example of its use is 6759 Expires: Thu, 01 Dec 1994 16:00:00 GMT 6761 RTSP/2.0 clients and caches MUST treat other invalid date formats, 6762 especially including the value "0", as having occurred in the past 6763 (i.e., already expired). 6765 To mark a response as "already expired," an origin server should use 6766 an Expires date that is equal to the Date header value. To mark a 6767 response as "never expires," an origin server SHOULD use an Expires 6768 date approximately one year from the time the response is sent. 6769 RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in 6770 the future. 6772 18.23. From 6774 The From request-header field, if given, SHOULD contain an Internet 6775 e-mail address for the human user who controls the requesting user 6776 agent. The address SHOULD be machine-usable, as defined by "mailbox" 6777 in [RFC1123]. 6779 This header field MAY be used for logging purposes and as a means for 6780 identifying the source of invalid or unwanted requests. It SHOULD 6781 NOT be used as an insecure form of access protection. The 6782 interpretation of this field is that the request is being performed 6783 on behalf of the person given, who accepts responsibility for the 6784 method performed. In particular, robot agents SHOULD include this 6785 header so that the person responsible for running the robot can be 6786 contacted if problems occur on the receiving end. 6788 The Internet e-mail address in this field MAY be separate from the 6789 Internet host which issued the request. For example, when a request 6790 is passed through a proxy the original issuer's address SHOULD be 6791 used. 6793 The client SHOULD NOT send the From header field without the user's 6794 approval, as it might conflict with the user's privacy interests or 6795 their site's security policy. It is strongly recommended that the 6796 user be able to disable, enable, and modify the value of this field 6797 at any time prior to a request. 6799 18.24. If-Match 6801 The If-Match request-header field is especially useful for ensuring 6802 the integrity of the presentation description, independent of how the 6803 presentation description was received. The presentation description 6804 can be fetched via means external to RTSP (such as HTTP) or via the 6805 DESCRIBE message. In the case of retrieving the presentation 6806 description via RTSP, the server implementation is guaranteeing the 6807 integrity of the description between the time of the DESCRIBE message 6808 and the SETUP message. By including the MTag given in or with the 6809 session description in an If-Match header part of the SETUP request, 6810 the client ensures that resources set up are matching the 6811 description. A SETUP request with the If-Match header for which the 6812 MTag validation check fails, MUST generate a response using 412 6813 (Precondition Failed). 6815 This validation check is also very useful if a session has been 6816 redirected from one server to another. 6818 18.25. If-Modified-Since 6820 The If-Modified-Since request-header field is used with the DESCRIBE 6821 and SETUP methods to make them conditional. If the requested variant 6822 has not been modified since the time specified in this field, a 6823 description will not be returned from the server (DESCRIBE) or a 6824 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 6825 response MUST be returned without any message-body. 6827 An example of the field is: 6829 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 6831 18.26. If-None-Match 6833 This request header can be used with one or several message body tags 6834 to make DESCRIBE requests conditional. A client that has one or more 6835 message bodies previously obtained from the resource, can verify that 6836 none of those entities is current by including a list of their 6837 associated message body tags in the If-None-Match header field. The 6838 purpose of this feature is to allow efficient updates of cached 6839 information with a minimum amount of transaction overhead. As a 6840 special case, the value "*" matches any current entity of the 6841 resource. 6843 If any of the message body tags match the message body tag of the 6844 message body that would have been returned in the response to a 6845 similar DESCRIBE request (without the If-None-Match header) on that 6846 resource, or if "*" is given and any current entity exists for that 6847 resource, then the server MUST NOT perform the requested method, 6848 unless required to do so because the resource's modification date 6849 fails to match that supplied in an If-Modified-Since header field in 6850 the request. Instead, if the request method was DESCRIBE, the server 6851 SHOULD respond with a 304 (Not Modified) response, including the 6852 cache-related header fields (particularly MTag) of one of the message 6853 bodies that matched. For all other request methods, the server MUST 6854 respond with a status of 412 (Precondition Failed). 6856 See Section 16.1.3 for rules on how to determine if two message body 6857 tags match. 6859 If none of the message body tags match, then the server MAY perform 6860 the requested method as if the If-None-Match header field did not 6861 exist, but MUST also ignore any If-Modified-Since header field(s) in 6862 the request. That is, if no message body tags match, then the server 6863 MUST NOT return a 304 (Not Modified) response. 6865 If the request would, without the If-None-Match header field, result 6866 in anything other than a 2xx or 304 status, then the If-None-Match 6867 header MUST be ignored. (See Section 16.1.4 for a discussion of 6868 server behavior when both If-Modified-Since and If-None-Match appear 6869 in the same request.) 6871 The result of a request having both an If-None-Match header field and 6872 an If-Match header field is unspecified and MUST be considered an 6873 illegal request. 6875 18.27. Last-Modified 6877 The Last-Modified message-header field indicates the date and time at 6878 which the origin server believes the presentation description or 6879 media stream was last modified. For the method DESCRIBE, the header 6880 field indicates the last modification date and time of the 6881 description, for SETUP that of the media stream. 6883 An origin server MUST NOT send a Last-Modified date which is later 6884 than the server's time of message origination. In such cases, where 6885 the resource's last modification would indicate some time in the 6886 future, the server MUST replace that date with the message 6887 origination date. 6889 An origin server SHOULD obtain the Last-Modified value of the message 6890 body as close as possible to the time that it generates the Date 6891 value of its response. This allows a recipient to make an accurate 6892 assessment of the message body's modification time, especially if the 6893 message body changes near the time that the response is generated. 6895 RTSP servers SHOULD send Last-Modified whenever feasible. 6897 18.28. Location 6899 The Location response-header field is used to redirect the recipient 6900 to a location other than the Request-URI for completion of the 6901 request or identification of a new resource. For 3rr responses, the 6902 location SHOULD indicate the server's preferred URI for automatic 6903 redirection to the resource. The field value consists of a single 6904 absolute URI. 6906 Note: The Content-Location header field (Section 18.18) differs from 6907 Location in that the Content-Location identifies the original 6908 location of the message body enclosed in the request. It is 6909 therefore possible for a response to contain header fields for both 6910 Location and Content-Location. Also, see Section 16.2 for cache 6911 requirements of some methods. 6913 18.29. Media-Properties 6915 This general header is used in SETUP response or PLAY_NOTIFY requests 6916 to indicate the media's properties that currently are applicable to 6917 the RTSP session. PLAY_NOTIFY MAY be used to modify these properties 6918 at any point. However, the client SHOULD have received the update 6919 prior to any action related to the new media properties taking 6920 effect. For aggregated sessions, the Media-Properties header will be 6921 returned in each SETUP response. The header received in the latest 6922 response is the one that applies on the whole session from this point 6923 until any future update. The header MAY be included without value in 6924 GET_PARAMETER requests to the server with a Session header included 6925 to query the current Media-Properties for the session. The responder 6926 MUST include the current session's media properties. 6928 The media properties expressed by this header is the one applicable 6929 to all media in the RTSP session. For aggregated sessions, the 6930 header expressed the combined media-properties. As a result, 6931 aggregation of media MAY result in a change of the media properties, 6932 and thus the content of the Media-Properties header contained in 6933 subsequent SETUP responses. 6935 The header contains a list of property values that are applicable to 6936 the currently setup media or aggregate of media as indicated by the 6937 RTSP URI in the request. No ordering is enforced within the header. 6938 Property values should be grouped into a single group that handles a 6939 particular orthogonal property. Values or groups that express 6940 multiple properties SHOULD NOT be used. The list of properties that 6941 can be expressed MAY be extended at any time. Unknown property 6942 values MUST be ignored. 6944 This specification defines the following 4 groups and their property 6945 values: 6947 Random Access: 6949 Random-Access: Indicates that random access is possible. May 6950 optionally include a floating point value in seconds indicating 6951 the longest duration between any two random access points in 6952 the media. 6954 Beginning-Only: Seeking is limited to the beginning only. 6956 No-Seeking: No seeking is possible. 6958 Content Modifications: 6960 Immutable: The content will not be changed during the life-time 6961 of the RTSP session. 6963 Dynamic: The content may be changed based on external methods or 6964 triggers 6966 Time-Progressing: The media accessible progresses as wallclock 6967 time progresses. 6969 Retention: 6971 Unlimited: Content will be retained for the duration of the life- 6972 time of the RTSP session. 6974 Time-Limited: Content will be retained at least until the 6975 specified wallclock time. The time must be provided in the 6976 absolute time format specified in Section 4.4.3. 6978 Time-Duration: Each individual media unit is retained for at 6979 least the specified time duration. This definition allows for 6980 retaining data with a time based sliding window. The time 6981 duration is expressed as floating point number in seconds. 0.0 6982 is a valid value as this indicates that no data is retained in 6983 a time-progressing session. 6985 Supported Scale: 6987 Scales: A quoted comma separated list of one or more decimal 6988 values or ranges of scale values supported by the content in 6989 arbitrary order. A range has a start and stop value separated 6990 by a colon. A range indicates that the content supports fine 6991 grained selection of scale values. Fine grained allows for 6992 steps at least as small as one tenth of a scale value. A 6993 content is considered to support fine grained selection when 6994 the server in response to a given scale value can produce 6995 content with an actual scale that is less than 1 tenth of scale 6996 unit, i.e., 0.1, from the requested value. Negative values are 6997 supported. The value 0 has no meaning and MUST NOT be used. 6999 Examples of this header for on-demand content and a live stream 7000 without recording are: 7002 On-demand: 7003 Media-Properties: Random-Access=2.5, Unlimited, Immutable, 7004 Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" 7006 Live stream without recording/timeshifting: 7007 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 7009 18.30. Media-Range 7011 The Media-Range general header is used to give the range of the media 7012 at the time of sending the RTSP message. This header MUST be 7013 included in SETUP response, and PLAY and PAUSE response for media 7014 that are Time-Progressing, and PLAY and PAUSE response after any 7015 change for media that are Dynamic, and in PLAY_NOTIFY request that 7016 are sent due to Media-Property-Update. Media-Range header without 7017 any range specifications MAY be included in GET_PARAMETER requests to 7018 the server to request the current range. The server MUST in this 7019 case include the current range at the time of sending the response. 7021 The header MUST include range specifications for all time formats 7022 supported for the media, as indicated in Accept-Ranges header 7023 (Section 18.5) when setting up the media. The server MAY include 7024 more than one range specification of any given time format to 7025 indicate media that has non-continuous range. The range 7026 specifications shall be ordered with the range with the lowest value 7027 or earliest start time first, followed by ranges with increasingly 7028 higher values or later start time. 7030 For media that has the Time-Progressing property, the Media-Range 7031 values will only be valid for the particular point in time when it 7032 was issued. As wallclock progresses so will also the media range. 7033 However, it shall be assumed that media time progresses in direct 7034 relationship to wallclock time (with the exception of clock skew) so 7035 that a reasonably accurate estimation of the media range can be 7036 calculated. 7038 18.31. MTag 7040 The MTag response header MAY be included in DESCRIBE, GET_PARAMETER 7041 or SETUP responses. The message body tags (Section 4.6) returned in 7042 a DESCRIBE response, and the one in SETUP refers to the presentation, 7043 i.e., both the returned session description and the media stream. 7044 This allows for verification that one has the right session 7045 description to a media resource at the time of the SETUP request. 7046 However, it has the disadvantage that a change in any of the parts 7047 results in invalidation of all the parts. 7049 If the MTag is provided both inside the message body, e.g., within 7050 the "a=mtag" attribute in SDP, and in the response message, then both 7051 tags MUST be identical. It is RECOMMENDED that the MTag is primarily 7052 given in the RTSP response message, to ensure that caches can use the 7053 MTag without requiring content inspection. However, for session 7054 descriptions that are distributed outside of RTSP, for example using 7055 HTTP, etc. it will be necessary to include the message body tag in 7056 the session description as specified in Appendix D.1.9. 7058 SETUP and DESCRIBE requests can be made conditional upon the MTag 7059 using the headers If-Match (Section 18.24) and If-None-Match ( 7060 Section 18.26). 7062 18.32. Notify-Reason 7064 The Notify Reason header is solely used in the PLAY_NOTIFY method. 7065 It indicates the reason why the server has sent the asynchronous 7066 PLAY_NOTIFY request (see Section 13.5). 7068 18.33. Pipelined-Requests 7070 The Pipelined-Requests general header is used to indicate that a 7071 request is to be executed in the context created by a previous 7072 request(s). The primary usage of this header is to allow pipelining 7073 of SETUP requests so that any additional SETUP request after the 7074 first one does not need to wait for the session ID to be sent back to 7075 the requesting agent. The header contains a unique identifier that 7076 is scoped by the persistent connection used to send the requests. 7078 Upon receiving a request with the Pipelined-Requests the responding 7079 agent MUST look up if there exists a binding between this Pipelined- 7080 Requests identifier for the current persistent connection and an RTSP 7081 session ID. If that exists then the received request is processed 7082 the same way as if it contained the Session header with the found 7083 session ID. If there does not exist a mapping and no Session header 7084 is included in the request, the responding agent MUST create a 7085 binding upon the successful completion of a session creating request, 7086 i.e., SETUP. A binding MUST NOT be created, if the request failed to 7087 create an RTSP session. In case the request contains both a Session 7088 header and the Pipelined-Requests header the Pipelined-Requests MUST 7089 be ignored. 7091 Note: Based on the above definition at least the first request 7092 containing a new unique Pipelined-Requests will be required to be a 7093 SETUP request (unless the protocol is extended with new methods of 7094 creating a session). After that first one, additional SETUP requests 7095 or requests of any type using the RTSP session context may include 7096 the Pipelined-Requests header. 7098 When responding to any request that contained the Pipelined-Requests 7099 header the server MUST also include the Session header when a binding 7100 to a session context exists. An RTSP agent that knows the session 7101 identifier SHOULD NOT use the Pipelined-Requests header in any 7102 request and only use the Session header. This as the Session 7103 identifier is persistent across transport contexts, like TCP 7104 connections, which the Pipelined-Requests identifier is not. 7106 The RTSP agent sending the request with a Pipelined-Requests header 7107 has the responsibility for using a unique and previously unused 7108 identifier within the transport context. Currently only a TCP 7109 connection is defined as such transport context. A server MUST 7110 delete the Pipelined-Requests identifier and its binding to a session 7111 upon the termination of that session. Despite the previous mandate, 7112 RTSP agents are RECOMMENDED to not reuse identifiers to allow for 7113 better error handling and logging. 7115 RTSP Proxies may need to translate Pipelined-Requests identifier 7116 values from incoming requests to outgoing to allow for aggregation of 7117 requests onto a persistent connection. 7119 18.34. Proxy-Authenticate 7121 The Proxy-Authenticate response-header field MUST be included as part 7122 of a 407 (Proxy Authentication Required) response. The field value 7123 consists of a challenge that indicates the authentication scheme and 7124 parameters applicable to the proxy for this Request-URI. 7126 The HTTP access authentication process is described in [RFC2617]. 7127 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 7128 only to the current connection and SHOULD NOT be passed on to 7129 downstream agents. This header MUST only be used in response 7130 messages related to client to server requests. 7132 18.35. Proxy-Authentication-Info 7134 The Proxy-Authentication-Info header is used by the proxy to 7135 communicate some information regarding the successful authentication 7136 to the proxy in the message response. The content and usage of this 7137 header is described in the HTTP access authentication [RFC2617] that 7138 is also used by RTSP and clarified in Section 19.1. This header MUST 7139 only be used in response messages related to client to server 7140 requests. This header has hop by hop scope. 7142 18.36. Proxy-Authorization 7144 The Proxy-Authorization request-header field allows the client to 7145 identify itself (or its user) to a proxy which requires 7146 authentication. The Proxy-Authorization field value consists of 7147 credentials containing the authentication information of the user 7148 agent for the proxy and/or realm of the resource being requested. 7150 The HTTP access authentication process is described in [RFC2617]. 7151 Unlike Authorization, the Proxy-Authorization header field applies 7152 only to the next hop proxy. This header MUST only be used in client 7153 to server requests. 7155 18.37. Proxy-Require 7157 The Proxy-Require request-header field is used to indicate proxy- 7158 sensitive features that MUST be supported by the proxy. Any Proxy- 7159 Require header features that are not supported by the proxy MUST be 7160 negatively acknowledged by the proxy to the client using the 7161 Unsupported header. The proxy MUST use the 551 (Option Not 7162 Supported) status code in the response. Any feature-tag included in 7163 the Proxy-Require does not apply to the end-point (server or client). 7164 To ensure that a feature is supported by both proxies and servers the 7165 tag needs to be included in also a Require header. 7167 See Section 18.43 for more details on the mechanics of this message 7168 and a usage example. See discussion in the proxies section 7169 (Section 15.1) about when to consider that a feature requires proxy 7170 support. 7172 Example of use: 7174 Proxy-Require: play.basic 7176 18.38. Proxy-Supported 7178 The Proxy-Supported general-header field enumerates all the 7179 extensions supported by the proxy using feature-tags. The header 7180 carries the intersection of extensions supported by the forwarding 7181 proxies. The Proxy-Supported header MAY be included in any request 7182 by a proxy. It MUST be added by any proxy if the Supported header is 7183 present in a request. When present in a request, the receiver MUST 7184 in the response copy the received Proxy-Supported header. 7186 The Proxy-Supported header field contains a list of feature-tags 7187 applicable to proxies, as described in Section 4.5. The list is the 7188 intersection of all feature-tags understood by the proxies. To 7189 achieve an intersection, the proxy adding the Proxy-Supported header 7190 includes all proxy feature-tags it understands. Any proxy receiving 7191 a request with the header, MUST check the list and removes any 7192 feature-tag(s) it does not support. A Proxy-Supported header present 7193 in the response MUST NOT be modified by the proxies. These feature 7194 tags are the ones the proxy chain support in general, and is not 7195 specific to the request resource. 7197 Example: 7199 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 7200 Supported: foo, bar, blech 7201 User-Agent: PhonyClient/1.2 7203 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 7204 Supported: foo, bar, blech 7205 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 7206 Via: 2.0 pro.example.com 7208 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 7209 Supported: foo, bar, blech 7210 Proxy-Supported: proxy-foo, proxy-blech 7211 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7213 S->C: RTSP/2.0 200 OK 7214 Supported: foo, bar, baz 7215 Proxy-Supported: proxy-foo, proxy-blech 7216 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7217 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7219 18.39. Public 7221 The Public response header field lists the set of methods supported 7222 by the response sender. This header applies to the general 7223 capabilities of the sender and its only purpose is to indicate the 7224 sender's capabilities to the recipient. The methods listed may or 7225 may not be applicable to the Request-URI; the Allow header field 7226 (Section 18.6) MAY be used to indicate methods allowed for a 7227 particular URI. 7229 Example of use: 7231 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7233 In the event that there are proxies between the sender and the 7234 recipient of a response, each intervening proxy MUST modify the 7235 Public header field to remove any methods that are not supported via 7236 that proxy. The resulting Public header field will contain an 7237 intersection of the sender's methods and the methods allowed through 7238 by the intervening proxies. 7240 In general, proxies should allow all methods to transparently pass 7241 through from the sending RTSP agent to the receiving RTSP agent, 7242 but there may be cases where this is not desirable for a given 7243 proxy. Modification of the Public response header field by the 7244 intervening proxies ensures that the request sender gets an 7245 accurate response indicating the methods that can be used on the 7246 target agent via the proxy chain. 7248 18.40. Range 7250 The Range general-header specifies a time range in PLAY 7251 (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT 7252 (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and 7253 responses. It MAY be included in GET_PARAMETER requests from the 7254 client to the server with only a Range format and no value to request 7255 the current media position, whether the session is in Play or Ready 7256 state in the included format. The server SHALL, if supporting the 7257 range format, respond with the current playing point or pause point 7258 as the start of the range. If an explicit stop point was used in the 7259 previous PLAY request, then that value shall be included as stop 7260 point. Note that if the server is currently under any type of media 7261 playback manipulation affecting the interpretation of Range, like 7262 Scale, that is also required to be included in any GET_PARAMETER 7263 response to provide complete information. 7265 The range can be specified in a number of units. This specification 7266 defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock 7267 (Section 4.4.3) range units. While byte ranges [H14.35.1] and other 7268 extended units MAY be used, their behavior is unspecified since they 7269 are not normally meaningful in RTSP. Servers supporting the Range 7270 header MUST understand the NPT range format and SHOULD understand the 7271 SMPTE range format. If the Range header is sent in a time format 7272 that is not understood, the recipient SHOULD return 456 (Header Field 7273 Not Valid for Resource) and include an Accept-Ranges header 7274 indicating the supported time formats for the given resource. 7276 Example: 7278 Range: clock=19960213T143205Z- 7280 The Range header contains a range of one single range format. A 7281 range is a half-open interval with a start and an end point, 7282 including the start point, but excluding the end point. A range may 7283 either be fully specified with explicit values for start point and 7284 end point, or have either start or end point be implicit. An 7285 implicit start point indicates the session's pause point, and if no 7286 pause point is set the start of the content. An implicit end point 7287 indicates the end of the content. The usage of both implicit start 7288 and end point is not allowed in the same range header, however, the 7289 exclusion of the range header has that meaning, i.e., from pause 7290 point (or start) until end of content. 7292 Regarding the half-open intervals; a range of A-B starts exactly 7293 at time A, but ends just before B. Only the start time of a media 7294 unit such as a video or audio frame is relevant. For example, 7295 assume that video frames are generated every 40 ms. A range of 7296 10.0-10.1 would include a video frame starting at 10.0 or later 7297 time and would include a video frame starting at 10.08, even 7298 though it lasted beyond the interval. A range of 10.0-10.08, on 7299 the other hand, would exclude the frame at 10.08. 7301 Please note the difference between NPT time scales' "now" and an 7302 implicit start value. Implicit value reference the current pause- 7303 point. While "now" is the currently ongoing time. In a time- 7304 progressing session with recording (retention for some or full 7305 time) the pause point may be 2 min into the session while now 7306 could be 1 hour into the session. 7308 By default, range intervals increase, where the second point is 7309 larger than the first point. 7311 Example: 7313 Range: npt=10-15 7315 However, range intervals can also decrease if the Scale header (see 7316 Section 18.46) indicates a negative scale value. For example, this 7317 would be the case when a playback in reverse is desired. 7319 Example: 7321 Scale: -1 7322 Range: npt=15-10 7324 Decreasing ranges are still half open intervals as described above. 7325 Thus, for range A-B, A is closed and B is open. In the above 7326 example, 15 is closed and 10 is open. An exception to this rule is 7327 the case when B=0 in a decreasing range. In this case, the range is 7328 closed on both ends, as otherwise there would be no way to reach 0 on 7329 a reverse playback for formats that have such a notion, like NPT and 7330 SMPTE. 7332 Example: 7334 Scale: -1 7335 Range: npt=15-0 7337 In this range both 15 and 0 are closed. 7339 A decreasing range interval without a corresponding negative Scale 7340 header is not valid. 7342 18.41. Referrer 7344 The Referrer request-header field allows the client to specify, for 7345 the server's benefit, the address (URI) of the resource from which 7346 the Request-URI was obtained. The URI refers to that of the 7347 presentation description, typically retrieved via HTTP. The Referrer 7348 request-header allows a server to generate lists of back-links to 7349 resources for interest, logging, optimized caching, etc. It also 7350 allows obsolete or mistyped links to be traced for maintenance. The 7351 Referrer field MUST NOT be sent if the Request-URI was obtained from 7352 a source that does not have its own URI, such as input from the user 7353 keyboard. 7355 If the field value is a relative URI, it SHOULD be interpreted 7356 relative to the Request-URI. The URI MUST NOT include a fragment 7357 identifier. 7359 Because the source of a link might be private information or might 7360 reveal an otherwise private information source, it is strongly 7361 recommended that the user be able to select whether or not the 7362 Referrer field is sent. For example, a streaming client could have a 7363 toggle switch for openly/anonymously, which would respectively 7364 enable/disable the sending of Referrer and From information. 7366 Clients SHOULD NOT include a Referrer header field in a (non-secure) 7367 RTSP request if the referring page was transferred with a secure 7368 protocol. 7370 18.42. Request-Status 7372 This request header is used to indicate the end result for requests 7373 that take time to complete, such as PLAY (Section 13.4). It is sent 7374 in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report 7375 how the PLAY request concluded, either in success or in failure. The 7376 header carries a reference to the request it reports on using the 7377 CSeq number for the session indicated by the Session header in the 7378 request. It provides both a numerical status code (according to 7379 Section 8.1.1) and a human readable reason phrase. 7381 Example: 7382 Request-Status: cseq=63 status=500 reason="Media data unavailable" 7384 18.43. Require 7386 The Require request-header field is used by agents to ensure that the 7387 other end-point supports features that are required in respect to 7388 this request. It can also be used to query if the other end-point 7389 supports certain features, however, the use of the Supported message- 7390 header (Section 18.51) is much more effective in this purpose. In 7391 case any of the feature-tags listed by the Require header are not 7392 supported by the server or client receiving the request, it MUST 7393 respond to the request using the error code 551 (Option Not 7394 Supported) and include the Unsupported header listing those feature- 7395 tags which are NOT supported. This header does not apply to proxies, 7396 for the same functionality in respect to proxies see Proxy-Require 7397 header (Section 18.37) with the exception of media modifying proxies. 7398 Media modifying proxies, due to their nature of handling media in a 7399 way that is very similar to a server, do need to understand also the 7400 server's features to correctly serve the client. 7402 This is to make sure that the client-server interaction will 7403 proceed without delay when all features are understood by both 7404 sides, and only slow down if features are not understood (as in 7405 the example below). For a well-matched client-server pair, the 7406 interaction proceeds quickly, saving a round-trip often required 7407 by negotiation mechanisms. In addition, it also removes state 7408 ambiguity when the client requires features that the server does 7409 not understand. 7411 Example (Not complete): 7413 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 7414 CSeq: 302 7415 Require: funky-feature 7416 Funky-Parameter: funkystuff 7418 S->C: RTSP/2.0 551 Option not supported 7419 CSeq: 302 7420 Unsupported: funky-feature 7422 In this example, "funky-feature" is the feature-tag which indicates 7423 to the client that the fictional Funky-Parameter field is required. 7424 The relationship between "funky-feature" and Funky-Parameter is not 7425 communicated via the RTSP exchange, since that relationship is an 7426 immutable property of "funky-feature" and thus should not be 7427 transmitted with every exchange. 7429 Proxies and other intermediary devices MUST ignore this header. If a 7430 particular extension requires that intermediate devices support it, 7431 the extension should be tagged in the Proxy-Require field instead 7432 (see Section 18.37). See discussion in the proxies section 7433 (Section 15.1) about when to consider that a feature requires proxy 7434 support. 7436 18.44. Retry-After 7438 The Retry-After response-header field can be used with a 503 (Service 7439 Unavailable) or 553 (Proxy Unavailable) response to indicate how long 7440 the service is expected to be unavailable to the requesting client. 7441 This field MAY also be used with any 3rr (Redirection) response to 7442 indicate the minimum time the user-agent is asked to wait before 7443 issuing the redirected request. The value of this field can be 7444 either an RTSP-date or an integer number of seconds (in decimal) 7445 after the time of the response. 7447 Example: 7449 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 7450 Retry-After: 120 7452 In the latter example, the delay is 2 minutes. 7454 18.45. RTP-Info 7456 The RTP-Info general header field is used to set RTP-specific 7457 parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY 7458 and GET_PARAMETER requests. For streams using RTP as transport 7459 protocol the RTP-Info header SHOULD be part of a 200 response to 7460 PLAY. 7462 The exclusion of the RTP-Info in a PLAY response for RTP 7463 transported media will result in a client needing to synchronize 7464 the media streams using RTCP. This may have negative impact as 7465 the RTCP can be lost, and does not need to be particularly timely 7466 in its arrival. Also functionality that informs the client from 7467 which packet a seek has occurred is affected. 7469 The RTP-Info MAY be included in SETUP responses to provide 7470 synchronization information when changing transport parameters, see 7471 Section 13.3. The RTP-Info header and the Range header MAY be 7472 included in a GET_PARAMETER request from client to server without any 7473 values to request the current playback point and corresponding RTP 7474 synchronization information. When the RTP-Info header is included in 7475 a Request the Range header MUST also be included (Note, Range header 7476 only MAY be used). The server response SHALL include both the Range 7477 header and the RTP-Info header. If the session is in Play state, 7478 then the value of the Range header SHALL be filled in with the 7479 current playback point and with the corresponding RTP-Info values. 7480 If the server is another state, no values are included in the RTP- 7481 Info header. The header is included in PLAY_NOTIFY requests with the 7482 Notify-Reason of end-of-stream to provide RTP information about the 7483 end of the stream. 7485 The header can carry the following parameters: 7487 url: Indicates the stream URI for which the following RTP parameters 7488 correspond, this URI MUST be the same as used in the SETUP 7489 request for this media stream. Any relative URI MUST use the 7490 Request-URI as base URI. This parameter MUST be present. 7492 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 7493 sequence number provided applies to. This parameter MUST be 7494 present. 7496 seq: Indicates the sequence number of the first packet of the stream 7497 that is direct result of the request. This allows clients to 7498 gracefully deal with packets when seeking. The client uses 7499 this value to differentiate packets that originated before the 7500 seek from packets that originated after the seek. Note that a 7501 client may not receive the packet with the expressed sequence 7502 number, and instead packets with a higher sequence number, due 7503 to packet loss or reordering. This parameter is RECOMMENDED to 7504 be present. 7506 rtptime: MUST indicate the RTP timestamp value corresponding to the 7507 start time value in the Range response header, or if not 7508 explicitly given the implied start point. The client uses this 7509 value to calculate the mapping of RTP time to NPT or other 7510 media timescale. This parameter SHOULD be present to ensure 7511 inter-media synchronization is achieved. There exists no 7512 requirement that any received RTP packet will have the same RTP 7513 timestamp value as the one in the parameter used to establish 7514 synchronization. 7516 A mapping from RTP timestamps to Network Time Protocol (NTP) 7517 format timestamps (wallclock) is available via RTCP. However, 7518 this information is not sufficient to generate a mapping from RTP 7519 timestamps to media clock time (NPT, etc.). Furthermore, in order 7520 to ensure that this information is available at the necessary time 7521 (immediately at startup or after a seek), and that it is delivered 7522 reliably, this mapping is placed in the RTSP control channel. 7524 In order to compensate for drift for long, uninterrupted 7525 presentations, RTSP clients should additionally map NPT to NTP, 7526 using initial RTCP sender reports to do the mapping, and later 7527 reports to check drift against the mapping. 7529 Example: 7531 Range:npt=3.25-15 7532 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 7533 rtptime=12345678,url="rtsp://example.com/foo/video" 7534 ssrc=9A9DE123:seq=30211;rtptime=29567112 7536 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video 7537 a 90kHz RTP timestamp clock. Then the media synchronization is 7538 depicted in the following way. 7540 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 7541 Audio PA A 7542 Video V PV 7544 X: NPT time value = 3.25, from Range header. 7545 A: RTP timestamp value for Audio from RTP-Info header (12345678). 7546 V: RTP timestamp value for Video from RTP-Info header (29567112). 7547 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 7548 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 7549 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 7550 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 7552 18.46. Scale 7554 The Scale general-header indicates the requested or used view rate 7555 for the media resource being played back. A scale value of 1 7556 indicates normal play at the normal forward viewing rate. If not 1, 7557 the value corresponds to the rate with respect to normal viewing 7558 rate. For example, a ratio of 2 indicates twice the normal viewing 7559 rate ("fast forward") and a ratio of 0.5 indicates half the normal 7560 viewing rate. In other words, a ratio of 2 has content time increase 7561 at twice the playback time. For every second of elapsed (wallclock) 7562 time, 2 seconds of content time will be delivered. A negative value 7563 indicates reverse direction. For certain media transports this may 7564 require certain considerations to work consistent, see Appendix C.1 7565 for description on how RTP handles this. 7567 The transmitted data rate SHOULD NOT be changed by selection of a 7568 different scale value. The resulting bit-rate should be reasonably 7569 close to the nominal bit-rate of the content for Scale = 1. The 7570 server has to actively manipulate the data when needed to meet the 7571 bitrate constraints. Implementation of scale changes depends on the 7572 server and media type. For video, a server may, for example, deliver 7573 only key frames or selected frames. For audio, it may time-scale the 7574 audio while preserving pitch or, less desirably, deliver fragments of 7575 audio, or completely mute the audio. 7577 The server and content may restrict the range of scale values that it 7578 supports. The supported values are indicated by the Media-Properties 7579 header (Section 18.29). The client SHOULD only indicate request 7580 values to be supported. However, as the values may change as the 7581 content progresses a requested value may no longer be valid when the 7582 request arrives. Thus, a non-supported value in a request does not 7583 generate an error, only forces the server to choose the closest 7584 value. The response MUST always contain the actual scale value 7585 chosen by the server. 7587 If the server does not implement the possibility to scale, it will 7588 not return a Scale header. A server supporting Scale operations for 7589 PLAY MUST indicate this with the use of the "play.scale" feature-tag. 7591 When indicating a negative scale for a reverse playback, the Range 7592 header MUST indicate a decreasing range as described in 7593 Section 18.40. 7595 Example of playing in reverse at 3.5 times normal rate: 7597 Scale: -3.5 7598 Range: npt=15-10 7600 18.47. Seek-Style 7602 When a client sends a PLAY request with a Range header to perform a 7603 random access to the media, the client does not know if the server 7604 will pick the first media samples or the first random access point 7605 prior to the request range. Depending on use case, the client may 7606 have a strong preference. To express this preference and provide the 7607 client with information on how the server actually acted on that 7608 preference the Seek-Style header is defined. 7610 Seek-Style is a general header that MAY be included in any PLAY 7611 request to indicate the client's preference for any media stream that 7612 has random access properties. The server MUST always include the 7613 header in any PLAY response for media with random access properties 7614 to indicate what policy was applied. A server that receives an 7615 unknown Seek-Style policy MUST ignore it and select the server 7616 default policy. A client receiving an unknown policy MUST ignore it 7617 and use the Range header and any media synchronization information as 7618 basis to determine what the server did. 7620 This specification defines the following seek policies that may be 7621 requested (see also Section 4.7.1): 7623 RAP: Random Access Point (RAP) is the behavior of requesting the 7624 server to locate the closest previous random access point that 7625 exists in the media aggregate and deliver from that. By 7626 requesting a RAP, media quality will be the best possible as all 7627 media will be delivered from a point where full media state can be 7628 established in the media decoder. 7630 CoRAP: Conditional Random Access Point (CoRAP) is a variant of the 7631 above RAP behavior. This policy is primarily intended for cases 7632 where there is larger distance between the random access points in 7633 the media. CoRAP is conditioned on that there is a Random Access 7634 Point closer to the requested start point than to the current 7635 pause point. This policy assumes that the media state existing 7636 prior to the pause is usable if delivery is continued. If the 7637 client or server knows that this is not the fact the RAP policy 7638 should be used. In other words: in most cases when the client 7639 requests a start point prior to the current pause point, a valid 7640 decoding dependency chain from the media delivered prior to the 7641 pause and to the requested media unit will not exist. If the 7642 server searched to a random access point the server MUST return 7643 the CoRAP policy in the Seek-Style header and adjust the Range 7644 header to reflect the position of the picked RAP. In case the 7645 random access point is further away and the server selects to 7646 continue from the current pause point it MUST include the "Next" 7647 policy in the Seek-Style header and adjust the Range header start 7648 point to the current pause point. 7650 First-Prior: The first-prior policy will start delivery with the 7651 media unit that has a playout time first prior to the requested 7652 time. For discrete media that would only include media units that 7653 would still be rendered at the request time. For continuous media 7654 that is media that will be rendered during the requested start 7655 time of the range. 7657 Next: The next media units after the provided start time of the 7658 range. For continuous framed media that would mean the first next 7659 frame after the provided time. For discrete media the first unit 7660 that is to be rendered after the provided time. The main usage 7661 for this case is when the client knows it has all media up to a 7662 certain point and would like to continue delivery so that a 7663 complete non-interrupted media playback can be achieved. Example 7664 of such scenarios include switching from a broadcast/multicast 7665 delivery to a unicast based delivery. This policy MUST only be 7666 used on the client's explicit request. 7668 Please note that these expressed preferences exist for optimizing the 7669 startup time or the media quality. The "Next" policy breaks the 7670 normal definition of the Range header to enable a client to request 7671 media with minimal overlap, although some may still occur for 7672 aggregated sessions. RAP and First-Prior both fulfill the 7673 requirement of providing media from the requested range and forward. 7674 However, unless RAP is used, the media quality for many media codecs 7675 using predictive methods can be severely degraded unless additional 7676 data is available as, for example, already buffered, or through other 7677 side channels. 7679 18.48. Server 7681 The Server general-header field contains information about the 7682 software used by the origin server to create or handle the request. 7683 The field can contain multiple product tokens and comments 7684 identifying the server and any significant subproducts. The product 7685 tokens are listed in order of their significance for identifying the 7686 application. 7688 Example: 7690 Server: PhonyServer/1.0 7692 If the response is being forwarded through a proxy, the proxy 7693 application MUST NOT modify the Server response-header. Instead, it 7694 SHOULD include a Via field (Section 18.57). If the response is 7695 generated by the proxy, the proxy application MUST return the Server 7696 response-header as previously returned by the server. 7698 18.49. Session 7700 The Session general-header field identifies an RTSP session. An RTSP 7701 session is created by the server as a result of a successful SETUP 7702 request and in the response the session identifier is given to the 7703 client. The RTSP session exists until destroyed by a TEARDOWN, 7704 REDIRECT or timed out by the server. 7706 The session identifier is chosen by the server (see Section 4.3) and 7707 MUST be returned in the SETUP response. Once a client receives a 7708 session identifier, it MUST be included in any request related to 7709 that session. This means that the Session header MUST be included in 7710 a request, using the following methods: PLAY, PAUSE, and TEARDOWN, 7711 and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, 7712 and REDIRECT, and MUST NOT be included in DESCRIBE. The Session 7713 header MUST NOT be included in the following methods, if these 7714 requests are pipelined and if the session identifier is not yet 7715 known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and 7716 GET_PARAMETER. 7718 In an RTSP response the session header MUST be included in methods, 7719 SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and 7720 REDIRECT, and if included in the request of the following methods it 7721 MUST also be included in the response, OPTIONS, GET_PARAMETER, and 7722 SET_PARAMETER, and MUST NOT be included in DESCRIBE responses. 7724 Note that a session identifier identifies an RTSP session across 7725 transport sessions or connections. RTSP requests for a given session 7726 can use different URIs (Presentation and media URIs). Note, that 7727 there are restrictions depending on the session which URIs that are 7728 acceptable for a given method. However, multiple "user" sessions for 7729 the same URI from the same client will require use of different 7730 session identifiers. 7732 The session identifier is needed to distinguish several delivery 7733 requests for the same URI coming from the same client. 7735 The response 454 (Session Not Found) MUST be returned if the session 7736 identifier is invalid. 7738 The header MAY include a parameter for session timeout period. If 7739 not explicitly provided this value is set to 60 seconds. As this 7740 affects how often session keep-alives are needed values smaller than 7741 30 seconds are not recommended. However, larger than default values 7742 can be useful in applications of RTSP that have inactive but 7743 established sessions for longer time periods. 7745 60 seconds was chosen as session timeout value due to: Resulting 7746 in not too frequent keep-alive messages and having low sensitivity 7747 to variations in request response timing. If one reduces the 7748 timeout value to below 30 seconds the corresponding request 7749 response timeout becomes a significant part of the session 7750 timeout. 60 seconds also allows for reasonably rapid recovery of 7751 committed server resources in case of client failure. 7753 18.50. Speed 7755 The Speed general-header field requests the server to deliver 7756 specific amounts of nominal media time per unit of delivery time, 7757 contingent on the server's ability and desire to serve the media 7758 stream at the given speed. The client requests the delivery speed to 7759 be within a given range with a lower and upper bound. The server 7760 SHALL deliver at the highest possible speed within the range, but not 7761 faster than the upper-bound, for which the underlying network path 7762 can support the resulting transport data rates. As long as any speed 7763 value within the given range can be provided the server SHALL NOT 7764 modify the media quality. Only if the server is unable to deliver 7765 media at the speed value provided by the lower bound shall it reduce 7766 the media quality. 7768 Implementation of the Speed functionality by the server is OPTIONAL. 7769 The server can indicate its support through a feature-tag, 7770 play.speed. The lack of a Speed header in the response is an 7771 indication of lack of support of this functionality. 7773 The speed parameter values are expressed as a positive decimal value, 7774 e.g., a value of 2.0 indicates that data is to be delivered twice as 7775 fast as normal. A speed value of zero is invalid. The range is 7776 specified in the form "lower bound - upper bound". The lower bound 7777 value may be smaller or equal to the upper bound. All speeds may not 7778 be possible to support. Therefore the server MAY modify the 7779 requested values to the closest supported. The actual supported 7780 speed MUST be included in the response. Note, however, that the use 7781 cases may vary and that Speed value ranges such as 0.7 - 0.8, 7782 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 7784 Example: 7786 Speed: 1.0-2.5 7788 Use of this header changes the bandwidth used for data delivery. It 7789 is meant for use in specific circumstances where delivery of the 7790 presentation at a higher or lower rate is desired. The main use 7791 cases are buffer operations or local scale operations. Implementors 7792 should keep in mind that bandwidth for the session may be negotiated 7793 beforehand (by means other than RTSP), and therefore re-negotiation 7794 may be necessary. To perform Speed operations the server needs to 7795 ensure that the network path can support the resulting bit-rate. 7796 Thus the media transport needs to support feedback so that the server 7797 can react and adapt to the available bitrate. 7799 18.51. Supported 7801 The Supported general header enumerates all the extensions supported 7802 by the client or server using feature tags. The header carries the 7803 extensions supported by the message sending client or server. The 7804 Supported header MAY be included in any request. When present in a 7805 request, the receiver MUST respond with its corresponding Supported 7806 header. Note that the Supported header is also included in 4xx and 7807 5xx responses. 7809 The Supported header contains a list of feature-tags, described in 7810 Section 4.5, that are understood by the client or server. These 7811 feature tags are the ones the server or client support in general, 7812 and is not specific to the request resource. 7814 Example: 7816 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 7817 Supported: foo, bar, blech 7818 User-Agent: PhonyClient/1.2 7820 S->C: RTSP/2.0 200 OK 7821 Supported: bar, blech, baz 7823 18.52. Terminate-Reason 7825 The Terminate-Reason request header allows the server when sending a 7826 REDIRECT or TEARDOWN request to provide a reason for the session 7827 termination and any additional information. This specification 7828 identifies three reasons for Redirections and may be extended in the 7829 future: 7831 Server-Admin: The server needs to be shutdown for some 7832 administrative reason. 7834 Session-Timeout: A client's session has been kept alive for extended 7835 periods of time and the server has determined that it needs to 7836 reclaim the resources associated with this session. 7838 Internal-Error An internal error that is impossible to recover from 7839 has occurred forcing the server to terminate the session. 7841 The Server may provide additional parameters containing information 7842 around the redirect. This specification defines the following ones. 7844 time: Provides a wallclock time when the server will stop providing 7845 any service. 7847 user-msg: An UTF-8 text string with a message from the server to the 7848 user. This message SHOULD be displayed to the user. 7850 18.53. Timestamp 7852 The Timestamp general-header describes when the agent sent the 7853 request. The value of the timestamp is of significance only to the 7854 agent and may use any timescale. The responding agent MUST echo the 7855 exact same value and MAY, if it has accurate information about this, 7856 add a floating point number indicating the number of seconds that has 7857 elapsed since it has received the request. The timestamp can be used 7858 by the agent to compute the round-trip time to the responding agent 7859 so that it can adjust the timeout value for retransmissions when 7860 running over an unreliable protocol. It also resolves retransmission 7861 ambiguities for unreliable transport of RTSP. 7863 Note that the present specification provides only for reliable 7864 transport of RTSP messages. The Timestamp general-header is 7865 specified in case the protocol is extended in the future to use 7866 unreliable transport. 7868 18.54. Transport 7870 The Transport general-header indicates which transport protocol is to 7871 be used and configures its parameters such as destination address, 7872 compression, multicast time-to-live and destination port for a single 7873 stream. It sets those values not already determined by a 7874 presentation description. 7876 A Transport request header MAY contain a list of transport options 7877 acceptable to the client, in the form of multiple transport 7878 specification entries. Transport specifications are comma separated, 7879 listed in decreasing order of preference. Each transport 7880 specification consist of a transport protocol identifier, followed by 7881 any number of parameters, each parameter separated by a semicolon. A 7882 Transport request header MAY contain multiple transport 7883 specifications using the same transport protocol Identifier. The 7884 server MUST return a Transport response-header in the response to 7885 indicate the values actually chosen if any. If no transport 7886 specification is supported, no transport header is returned and the 7887 request MUST be responded using the status code 461 (Unsupported 7888 Transport) (Section 17.4.25). In case more than one transport 7889 specification was present in the request, the server MUST return the 7890 single transport specification (transport-spec) which was actually 7891 chosen, if any. The number of transport-spec entries is expected to 7892 be limited as the client will get guidance on what configurations 7893 that are possible from the presentation description. 7895 The Transport header MAY also be used in subsequent SETUP requests to 7896 change transport parameters. A server MAY refuse to change 7897 parameters of an existing stream. 7899 The transport protocol identifier defines for each transport 7900 specification which transport protocol to use and any related rules. 7901 Each transport protocol identifier defines the parameters that are 7902 required to occur, additional optional parameters MAY occur. This as 7903 parameters may be different and provide different options to the RTSP 7904 Agent. A transport specification may only contain one of any given 7905 parameter within it. A parameter consists of a name and optionally a 7906 value string. Parameters MAY be given in any order. Additionally, 7907 transport specification may only contain either of the unicast or the 7908 multicast transport type parameter. The transport protocol 7909 identifier and all parameters need to be understood in a transport 7910 specification, if not, the transport specification MUST be ignored. 7911 An RTSP proxy of any type that uses or modifies the transport 7912 specification, e.g., access proxy or security proxy, MUST remove 7913 specifications with unknown parameters before forwarding the RTSP 7914 message. If that results in no remaining transport specification the 7915 proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.25) 7916 response without any Transport header. 7918 The Transport header is restricted to describing a single media 7919 stream. (RTSP can also control multiple streams as a single 7920 entity.) Making it part of RTSP rather than relying on a 7921 multitude of session description formats greatly simplifies 7922 designs of firewalls. 7924 The general syntax for the transport protocol identifier is a list of 7925 slash separated tokens: 7927 Value1/Value2/Value3... 7929 Which for RTP transports take the form: 7931 RTP/profile/lower-transport. 7933 The default value for the "lower-transport" parameters is specific to 7934 the profile. For RTP/AVP, the default is UDP. 7936 There are two different methods for how to specify where the media 7937 should be delivered for unicast transport: 7939 dest_addr: The presence of this parameter and its values indicates 7940 the destination address or addresses (host address and port 7941 pairs for IP flows) necessary for the media transport. 7943 No dest_addr: The lack of the dest_addr parameter indicates that the 7944 server MUST send media to the same address from which the RTSP 7945 messages originates. 7947 The choice of method for indicating where the media is to be 7948 delivered depends on the use case. In some cases the only allowed 7949 method will be to use no explicit address indication and have the 7950 server deliver media to the source of the RTSP messages. 7952 For Multicast there is several methods for specifying addresses but 7953 they are different in how they work compared with unicast: 7955 dest_addr with client picked address: The address and relevant 7956 parameters, like TTL (scope), for the actual multicast group to 7957 deliver the media to. There are security implications 7958 (Section 21) with this method that need to be addressed if 7959 using this method because a RTSP server can be used as a Denial 7960 of Service (DoS) attacker on an existing multicast group. 7962 dest_addr using Session Description Information: The information 7963 included in the transport header can all be coming from the 7964 session description, e.g., the SDP c= and m= line. This 7965 mitigates some of the security issues of the previous methods 7966 as it is the session provider that picks the multicast group 7967 and scope. The client MUST include the information if it is 7968 available in the session description. 7970 No dest_addr: The behavior when no explicit multicast group is 7971 present in a request is not defined. 7973 An RTSP proxy will need to take care. If the media is not desired to 7974 be routed through the proxy, the proxy will need to introduce the 7975 destination indication. 7977 Below are the configuration parameters associated with transport: 7979 General parameters: 7981 unicast / multicast: This parameter is a mutually exclusive 7982 indication of whether unicast or multicast delivery will be 7983 attempted. One of the two values MUST be specified. Clients 7984 that are capable of handling both unicast and multicast 7985 transmission need to indicate such capability by including two 7986 full transport-specs with separate parameters for each. 7988 layers: The number of multicast layers to be used for this media 7989 stream. The layers are sent to consecutive addresses starting 7990 at the dest_addr address. If the parameter is not included, it 7991 defaults to a single layer. 7993 dest_addr: A general destination address parameter that can contain 7994 one or more address specifications. Each combination of 7995 protocol/profile/lower transport needs to have the format and 7996 interpretation of its address specification defined. For RTP/ 7997 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 7998 containing a host address and port. Note, only a single 7999 destination parameter per transport spec is intended. The 8000 usage of multiple destinations to distribute a single media to 8001 multiple entities is unspecified. 8003 The client originating the RTSP request MAY specify the 8004 destination address of the stream recipient with the host 8005 address part of the tuple. When the destination address is 8006 specified, the recipient may be a different party than the 8007 originator of the request. To avoid becoming the unwitting 8008 perpetrator of a remote-controlled denial-of-service attack, a 8009 server MUST perform security checks (see Section 21.2.1) and 8010 SHOULD log such attempts before allowing the client to direct a 8011 media stream to a recipient address not chosen by the server. 8012 Implementations cannot rely on TCP as reliable means of client 8013 identification. If the server does not allow the host address 8014 part of the tuple to be set, it MUST return 463 (Destination 8015 Prohibited). 8017 The host address part of the tuple MAY be empty, for example 8018 ":58044", in cases when it is desired to specify only the 8019 destination port. Responses to requests including the 8020 Transport header with a dest_addr parameter SHOULD include the 8021 full destination address that is actually used by the server. 8022 The server MUST NOT remove address information present already 8023 in the request when responding unless the protocol requires it. 8025 src_addr: A general source address parameter that can contain one or 8026 more address specifications. Each combination of protocol/ 8027 profile/lower transport needs to have the format and 8028 interpretation of its address specification defined. For RTP/ 8029 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8030 containing a host address and port. 8032 This parameter MUST be specified by the server if it transmits 8033 media packets from another address than the one RTSP messages 8034 are sent to. This will allow the client to verify source 8035 address and give it a destination address for its RTCP feedback 8036 packets, if RTP is used. The address or addresses indicated in 8037 the src_addr parameter SHOULD be used both for sending and 8038 receiving of the media stream's data packets. The main reasons 8039 are threefold: First, indicating the port and source address(s) 8040 lets the receiver know where from the packets is expected to 8041 originate. Secondly, traversal of NATs is greatly simplified 8042 when traffic is flowing symmetrically over a NAT binding. 8043 Thirdly, certain NAT traversal mechanisms, needs to know to 8044 which address and port to send so called "binding packets" from 8045 the receiver to the sender, thus creating an address binding in 8046 the NAT that the sender to receiver packet flow can use. 8048 This information may also be available through SDP. 8049 However, since this is more a feature of transport than 8050 media initialization, the authoritative source for this 8051 information should be in the SETUP response. 8053 mode: The mode parameter indicates the methods to be supported for 8054 this session. Currently defined valid values are "PLAY". If 8055 not provided, the default is "PLAY". The "RECORD" value was 8056 defined in RFC 2326 and is in this specification unspecified 8057 but reserved. RECORD and other values may be specified in the 8058 future. 8060 interleaved: The interleaved parameter implies mixing the media 8061 stream with the control stream in whatever protocol is being 8062 used by the control stream, using the mechanism defined in 8063 Section 14. The argument provides the channel number to be 8064 used in the $ block (see Section 14) and MUST be present. This 8065 parameter MAY be specified as an interval, e.g., 8066 interleaved=4-5 in cases where the transport choice for the 8067 media stream requires it, e.g., for RTP with RTCP. The channel 8068 number given in the request is only a guidance from the client 8069 to the server on what channel number(s) to use. The server MAY 8070 set any valid channel number in the response. The declared 8071 channel(s) are bi-directional, so both end-parties MAY send 8072 data on the given channel. One example of such usage is the 8073 second channel used for RTCP, where both server and client send 8074 RTCP packets on the same channel. 8076 This allows RTP/RTCP to be handled similarly to the way 8077 that it is done with UDP, i.e., one channel for RTP and 8078 the other for RTCP. 8080 MIKEY: This parameter is used in conjunction with transport 8081 specifications that can utilize MIKEY [RFC3830] for security 8082 context establishment. So far only the SRTP based RTP profiles 8083 SAVP and SAVPF can utilize MIKEY and this is defined in 8084 Appendix C.1.4.1. This parameter can be included both in 8085 request and response messages. The binary MIKEY message SHALL 8086 be Base64 [RFC4648] encoded before being included in the value 8087 part of the parameter. 8089 Multicast-specific: 8091 ttl: multicast time-to-live for IPv4. When included in requests the 8092 value indicate the TTL value that the client requests the 8093 server to use. In a response, the value actually being used by 8094 the server is returned. A server will need to consider what 8095 values that are reasonable and also the authority of the user 8096 to set this value. Corresponding functions are not needed for 8097 IPv6 as the scoping is part of the IPv6 multicast address 8098 [RFC4291]. 8100 RTP-specific: 8102 These parameters MAY only be used if the media transport protocol is 8103 RTP. 8105 ssrc: The ssrc parameter, if included in a SETUP response, indicates 8106 the RTP SSRC [RFC3550] value(s) that will be used by the media 8107 server for RTP packets within the stream. It is expressed as 8108 an eight digit hexadecimal value. 8110 The ssrc parameter MUST NOT be specified in requests. The 8111 functionality of specifying the ssrc parameter in a SETUP 8112 request is deprecated as it is incompatible with the 8113 specification of RTP in RFC 3550[RFC3550]. If the parameter is 8114 included in the Transport header of a SETUP request, the server 8115 SHOULD ignore it, and choose appropriate SSRCs for the stream. 8116 The server SHOULD set the ssrc parameter in the Transport 8117 header of the response. 8119 RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing 8120 [RFC5761] on a single underlying transport stream / flow. The 8121 presence of this parameter in a SETUP request indicates the 8122 client's support and requires the server to use RTP and RTCP 8123 multiplexing. The client SHALL only include one transport 8124 stream in the Transport header specification. To provide the 8125 server with a choice between using RTP/RTCP multiplexing or 8126 not, two different transport header specifications must be 8127 included. 8129 The parameters setup and connection defined below MAY only be used if 8130 the media transport protocol of the lower-level transport is 8131 connection-oriented (such as TCP). However, these parameters MUST 8132 NOT be used when interleaving data over the RTSP connection. 8134 setup: Clients use the setup parameter on the Transport line in a 8135 SETUP request, to indicate the roles it wishes to play in a TCP 8136 connection. This parameter is adapted from [RFC4145]. We 8137 discuss the use of this parameter in RTP/AVP/TCP non- 8138 interleaved transport in Appendix C.2.2; the discussion below 8139 is limited to syntactic issues. Clients may specify the 8140 following values for the setup parameter: 8142 active: The client will initiate an outgoing connection. 8144 passive: The client will accept an incoming connection. 8146 actpass: The client is willing to accept an incoming 8147 connection or to initiate an outgoing connection. 8149 If a client does not specify a setup value, the "active" value 8150 is assumed. 8152 In response to a client SETUP request where the setup parameter 8153 is set to "active", a server's 2xx reply MUST assign the setup 8154 parameter to "passive" on the Transport header line. 8156 In response to a client SETUP request where the setup parameter 8157 is set to "passive", a server's 2xx reply MUST assign the setup 8158 parameter to "active" on the Transport header line. 8160 In response to a client SETUP request where the setup parameter 8161 is set to "actpass", a server's 2xx reply MUST assign the setup 8162 parameter to "active" or "passive" on the Transport header 8163 line. 8165 Note that the "holdconn" value for setup is not defined for 8166 RTSP use, and MUST NOT appear on a Transport line. 8168 connection: Clients use the connection parameter in a transport 8169 specification part of the Transport header in a SETUP request, 8170 to indicate the client's preference for either reusing an 8171 existing connection between client and server (in which case 8172 the client sets the "connection" parameter to "existing"), or 8173 requesting the creation of a new connection between client and 8174 server (in which cast the client sets the "connection" 8175 parameter to "new"). Typically, clients use the "new" value 8176 for the first SETUP request for a URL, and "existing" for 8177 subsequent SETUP requests for a URL. 8179 If a client SETUP request assigns the "new" value to 8180 "connection", the server response MUST also assign the "new" 8181 value to "connection" on the Transport line. 8183 If a client SETUP request assigns the "existing" value to 8184 "connection", the server response MUST assign a value of 8185 "existing" or "new" to "connection" on the Transport line, at 8186 its discretion. 8188 The default value of "connection" is "existing", for all SETUP 8189 requests (initial and subsequent). 8191 The combination of transport protocol, profile and lower transport 8192 needs to be defined. A number of combinations are defined in the 8193 Appendix C. 8195 Below is a usage example, showing a client advertising the capability 8196 to handle multicast or unicast, preferring multicast. Since this is 8197 a unicast-only stream, the server responds with the proper transport 8198 parameters for unicast. 8200 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 8201 CSeq: 302 8202 Transport: RTP/AVP;multicast;mode="PLAY", 8203 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8204 "192.0.2.5:3457";mode="PLAY" 8205 Accept-Ranges: npt, smpte, clock 8206 User-Agent: PhonyClient/1.2 8208 S->C: RTSP/2.0 200 OK 8209 CSeq: 302 8210 Date: Thu, 23 Jan 1997 15:35:06 GMT 8211 Session: 47112344 8212 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8213 "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ 8214 "192.0.2.224:6257";mode="PLAY" 8215 Accept-Ranges: npt 8216 Media-Properties: Random-Access=0.6, Dynamic, 8217 Time-Limited=20081128T165900 8219 18.55. Unsupported 8221 The Unsupported response-header lists the features not supported by 8222 the responding RTSP agent. In the case where the feature was 8223 specified via the Proxy-Require field (Section 18.37), if there is a 8224 proxy on the path between the client and the server, the proxy MUST 8225 send a response message with a status code of 551 (Option Not 8226 Supported). The request MUST NOT be forwarded. 8228 See Section 18.43 for a usage example. 8230 18.56. User-Agent 8232 The User-Agent general-header field contains information about the 8233 user agent originating the request or producing a response. This is 8234 for statistical purposes, the tracing of protocol violations, and 8235 automated recognition of user agents for the sake of tailoring 8236 responses to avoid particular user agent limitations. User agents 8237 SHOULD include this field with requests. The field can contain 8238 multiple product tokens and comments identifying the agent and any 8239 subproducts which form a significant part of the user agent. By 8240 convention, the product tokens are listed in order of their 8241 significance for identifying the application. 8243 Example: 8245 User-Agent: PhonyClient/1.2 8247 18.57. Via 8249 The Via general-header field MUST be used by proxies to indicate the 8250 intermediate protocols and recipients between the user agent and the 8251 server on requests, and between the origin server and the client on 8252 responses. The field is intended to be used for tracking message 8253 forwards, avoiding request loops, and identifying the protocol 8254 capabilities of all senders along the request/response chain. 8256 Multiple Via field values represents each proxy that has forwarded 8257 the message. Each recipient MUST append its information such that 8258 the end result is ordered according to the sequence of forwarding 8259 applications. 8261 Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by 8262 default, forward the names and ports of hosts within the private/ 8263 protected region. This information SHOULD only be propagated if 8264 explicitly enabled. If not enabled, the via-received of any host 8265 behind the firewall/NAT SHOULD be replaced by an appropriate 8266 pseudonym for that host. 8268 For organizations that have strong privacy requirements for hiding 8269 internal structures, a proxy MAY combine an ordered subsequence of 8270 Via header field entries with identical sent-protocol values into a 8271 single such entry. Applications MUST NOT combine entries which have 8272 different received-protocol values. 8274 18.58. WWW-Authenticate 8276 The WWW-Authenticate response-header field MUST be included in 401 8277 (Unauthorized) response messages. The field value consists of at 8278 least one challenge that indicates the authentication scheme(s) and 8279 parameters applicable to the Request-URI. This header MUST only be 8280 used in response messages related to client to server requests. 8282 The HTTP access authentication process is described in [RFC2617] with 8283 some clarification in Section 19.1. User agents are advised to take 8284 special care in parsing the WWW- Authenticate field value as it might 8285 contain more than one challenge, or if more than one WWW-Authenticate 8286 header field is provided, the contents of a challenge itself can 8287 contain a comma-separated list of authentication parameters. 8289 19. Security Framework 8291 The RTSP security framework consists of two high level components: 8292 the pure authentication mechanisms based on HTTP authentication, and 8293 the message transport protection based on TLS, which is independent 8294 of RTSP. Because of the similarity in syntax and usage between RTSP 8295 servers and HTTP servers, the security for HTTP is re-used to a large 8296 extent. 8298 19.1. RTSP and HTTP Authentication 8300 RTSP and HTTP share common authentication schemes, and thus follow 8301 the same usage guidelines as specified in [RFC2617] with the 8302 additions for digest specified below in Section 19.1.1. Servers 8303 SHOULD implement both basic and digest [RFC2617] authentication. 8304 Clients MUST implement both basic and digest authentication [RFC2617] 8305 so that a server that requires the client to authenticate can trust 8306 that the capability is present. 8308 It should be stressed that using the HTTP authentication alone does 8309 not provide full control message security. Therefore, in 8310 environments requiring tighter security for the control messages, TLS 8311 SHOULD be used, see Section 19.2. Any RTSP message containing an 8312 Authorization header using basic authorization MUST be using a TLS 8313 connection with confidentiality protection enabled, i.e. no NULL 8314 encryption. 8316 In cases where there is a chain of proxies between the client and the 8317 server, each proxy may individually request the client or previous 8318 proxy to authenticate itself. This is done using the Proxy- 8319 Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36) 8320 and the Proxy-Authentication-Info (Section 18.35) headers. These 8321 headers are hop-by-hop headers and have only scope for the current 8322 connection. Thus if a chain exist, the proxy connecting to another 8323 proxy will have to act as a client to authorize itself towards the 8324 next proxy. The WWW-Authenticate (Section 18.58), Authorization 8325 (Section 18.8) and Authentication-Info (Section 18.7) headers are 8326 end-to-end and must not be modified by proxies. 8328 This authentication mechanism works only for client to server 8329 requests as currently defined. This leaves server to client request 8330 outside of the context of TLS based communication more vulnerable to 8331 message injection attacks on the client. Based on the server to 8332 client methods that exist, the potential risks are various; hijacking 8333 (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks 8334 with uncertain results (SET_PARAMETER). 8336 19.1.1. Digest Authentication 8338 This section describes the modifications and clarifications required 8339 to apply the HTTP Digest authentication scheme to RTSP. The RTSP 8340 scheme usage is almost completely identical to that for HTTP 8341 [RFC2617]. These are based on the procedures defined for SIP 2.0 8342 [RFC3261]. 8344 The rules for Digest authentication follow those defined in 8345 [RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the 8346 following differences: 8348 1. Use the ABNF specified in this document, rather than the one in 8349 [RFC2617]. That way the following is assured: 8351 * Using the right RTSP URIs allowed in the challenge as well as 8352 in the digest. 8354 * Resolved the error in the "uri" parameter of the Authorization 8355 header in [RFC2617]. 8357 2. If MTags are used then the example procedure for choosing a nonce 8358 based on Etag can work based on replacing ETag with the MTag. 8360 3. As a clarification to the calculation of the A2 value for message 8361 integrity assurance in the Digest authentication scheme, 8362 implementers should assume, when the entity-body is empty (that 8363 is, when the RTSP messages have no message body) that the hash of 8364 the message-body resolves to the MD5 hash of an empty string, or: 8365 H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e". 8367 4. RFC 2617 notes that a cnonce value MUST NOT be sent in an 8368 Authorization (and by extension Proxy-Authorization) header field 8369 if no qop directive has been sent. Therefore, any algorithms 8370 that have a dependency on the cnonce (including "MD5-Sess") 8371 require that the qop directive be sent. Use of the "qop" 8372 parameter is optional in RFC 2617 for the purposes of backwards 8373 compatibility with RFC 2069; since this specification defines 8374 RTSP 2.0 there is no backwards compatibility issue with 8375 mandating. Thus, all RTSP agents MUST implement qop-options. 8377 19.2. RTSP over TLS 8379 RTSP agents MUST implement RTSP over TLS as defined in this section 8380 and the next Section 19.3. RTSP MUST follow the same guidelines with 8381 regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. 8382 RTSP over TLS is separated from unsecured RTSP both on the URI level 8383 and the port level. Instead of using the "rtsp" scheme identifier in 8384 the URI, the "rtsps" scheme identifier MUST be used to signal RTSP 8385 over TLS. If no port is given in a URI with the "rtsps" scheme, port 8386 322 MUST be used for TLS over TCP/IP. 8388 When a client tries to setup an insecure channel to the server (using 8389 the "rtsp" URI), and the policy for the resource requires a secure 8390 channel, the server MUST redirect the client to the secure service by 8391 sending a 301 redirect response code together with the correct 8392 Location URI (using the "rtsps" scheme). A user or client MAY 8393 upgrade a non secured URI to a secured by changing the scheme from 8394 "rtsp" to "rtsps". A server implementing support for "rtsps" MUST 8395 allow this. 8397 It should be noted that TLS allows for mutual authentication (when 8398 using both server and client certificates). Still, one of the more 8399 common ways TLS is used is to only provide server side authentication 8400 (often to avoid client certificates). TLS is then used in addition 8401 to HTTP authentication, providing transport security and server 8402 authentication, while HTTP Authentication is used to authenticate the 8403 client. 8405 RTSP includes the possibility to keep a TCP session up between the 8406 client and server, throughout the RTSP session lifetime. It may be 8407 convenient to keep the TCP session, not only to save the extra setup 8408 time for TCP, but also the extra setup time for TLS (even if TLS uses 8409 the resume function, there will be almost two extra round trips). 8410 Still, when TLS is used, such behavior introduces extra active state 8411 in the server, not only for TCP and RTSP, but also for TLS. This may 8412 increase the vulnerability to DoS attacks. 8414 There exist a potential security vulnerability when reusing TCP and 8415 TLS state for different resources (URIs). If two different host 8416 names points at the same IP address it can be desirable to re-use the 8417 TCP/TLS connection to that server. In that case the RTSP agent 8418 having the TCP/TLS connection MUST verify that the server certificate 8419 associated with the connection has a SubjectAltName matching the host 8420 name present in the URI for the resource an RTSP request is to be 8421 issued for. 8423 In addition to these recommendations, Section 19.3 gives further 8424 recommendations of TLS usage with proxies. 8426 19.3. Security and Proxies 8428 The nature of a proxy is often to act as a "man-in-the-middle", while 8429 security is often about preventing the existence of a "man-in-the- 8430 middle". This section provides clients with the possibility to use 8431 proxies even when applying secure transports (TLS) between the RTSP 8432 agents. The TLS proxy mechanism allows for server and proxy 8433 identification using certificates. However, the client cannot be 8434 identified based on certificates. The client needs to select between 8435 using the procedure specified below or using a TLS connection 8436 directly (by-passing any proxies) to the server. The choice may be 8437 dependent on policies. 8439 There are in general two categories of proxies, the transparent 8440 proxies (of which the client is not aware) and the non-transparent 8441 proxies (of which the client is aware). This memo specifies only 8442 non-transparent RTSP proxies, i.e., proxies visible to the RTSP 8443 client and RTSP server. An infrastructure based on proxies requires 8444 that the trust model is such that both client and servers can trust 8445 the proxies to handle the RTSP messages correctly. To be able to 8446 trust a proxy, the client and server also need to be aware of the 8447 proxy. Hence, transparent proxies cannot generally be seen as 8448 trusted and will not work well with security (unless they work only 8449 at transport layer). In the rest of this section any reference to 8450 proxy will be to a non-transparent proxy, which inspects or 8451 manipulates the RTSP messages. 8453 HTTP Authentication is built on the assumption of proxies and can 8454 provide user-proxy authentication and proxy-proxy/server 8455 authentication in addition to the client-server authentication. 8457 When TLS is applied and a proxy is used, the client will connect to 8458 the proxy's address when connecting to any RTSP server. This implies 8459 that for TLS, the client will authenticate the proxy server and not 8460 the end server. Note that when the client checks the server 8461 certificate in TLS, it MUST check the proxy's identity (URI or 8462 possibly other known identity) against the proxy's identity as 8463 presented in the proxy's Certificate message. 8465 The problem is that for a proxy accepted by the client, the proxy 8466 needs to be provided information on which grounds it should accept 8467 the next-hop certificate. Both the proxy and the user may have rules 8468 for this, and the user should have the possibility to select the 8469 desired behavior. To handle this case, the Accept-Credentials header 8470 (See Section 18.2) is used, where the client can request the proxy/ 8471 proxies to relay back the chain of certificates used to authenticate 8472 any intermediate proxies as well as the server. The assumption that 8473 the proxies are viewed as trusted, gives the user a possibility to 8474 enforce policies to each trusted proxy of whether it should accept 8475 the next agent in the chain. However, it should be noted that not 8476 all deployments will return the chain of certificates used to 8477 authenticate any intermediate proxies as well as the server. An 8478 operator of such a deployment may want to hide its topology from the 8479 client. It should be noted well that the client does not have any 8480 insight into the proxy's operation. Even if the proxy is trusted, it 8481 can still return an incomplete chain of certificates. 8483 A proxy MUST use TLS for the next hop if the RTSP request includes a 8484 "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between 8485 client and proxy, or between proxy and proxy), even if the resource 8486 and the end server are not required to use it. The proxy MUST, when 8487 initiating the next hop TLS connection, use the incoming TLS 8488 connections cipher suite list, only modified by removing any cipher 8489 suites that the proxy does not support. In case a proxy fails to 8490 establish a TLS connection due to cipher suite mismatch between proxy 8491 and next hop proxy or server, this is indicated using error code 472 8492 (Failure to establish secure connection). 8494 19.3.1. Accept-Credentials 8496 The Accept-Credentials header can be used by the client to distribute 8497 simple authorization policies to intermediate proxies. The client 8498 includes the Accept-Credentials header to dictate how the proxy 8499 treats the server/next proxy certificate. There are currently three 8500 methods defined: 8502 Any, which means that the proxy (or proxies) MUST accept whatever 8503 certificate is presented. This is of course not a recommended 8504 option to use, but may be useful in certain circumstances (such 8505 as testing). 8507 Proxy: which means that the proxy (or proxies) MUST use its own 8508 policies to validate the certificate and decide whether to 8509 accept it or not. This is convenient in cases where the user 8510 has a strong trust relation with the proxy. Reasons why a 8511 strong trust relation may exist are: personal/company proxy, 8512 proxy has a out-of-band policy configuration mechanism. 8514 User, which means that the proxy (or proxies) MUST send credential 8515 information about the next hop to the client for authorization. 8516 The client can then decide whether the proxy should accept the 8517 certificate or not. See Section 19.3.2 for further details. 8519 If the Accept-Credentials header is not included in the RTSP request 8520 from the client, then the "Proxy" method MUST be used as default. If 8521 another method than the "Proxy" is to be used, then the Accept- 8522 Credentials header MUST be included in all of the RTSP requests from 8523 the client. This is because it cannot be assumed that the proxy 8524 always keeps the TLS state or the user's previous preference between 8525 different RTSP messages (in particular if the time interval between 8526 the messages is long). 8528 With the "Any" and "Proxy" methods the proxy will apply the policy as 8529 defined for each method. If the policy does not accept the 8530 credentials of the next hop, the proxy MUST respond with a message 8531 using status code 471 (Connection Credentials not accepted). 8533 An RTSP request in the direction server to client MUST NOT include 8534 the Accept-Credentials header. As for the non-secured communication, 8535 the possibility for these requests depends on the presence of a 8536 client established connection. However, if the server to client 8537 request is in relation to a session established over a TLS secured 8538 channel, it MUST be sent in a TLS secured connection. That secured 8539 connection MUST also be the one used by the last client to server 8540 request. If no such transport connection exists at the time when the 8541 server desires to send the request, the server MUST discard the 8542 message. 8544 Further policies MAY be defined and registered, but should be done so 8545 with caution. 8547 19.3.2. User approved TLS procedure 8549 For the "User" method, each proxy MUST perform the following 8550 procedure for each RTSP request: 8552 o Setup the TLS session to the next hop if not already present 8553 (i.e., run the TLS handshake, but do not send the RTSP request). 8555 o Extract the peer certificate chain for the TLS session. 8557 o Check if a matching identity and hash of the peer certificate is 8558 present in the Accept-Credentials header. If present, send the 8559 message to the next hop, and conclude these procedures. If not, 8560 go to the next step. 8562 o The proxy responds to the RTSP request with a 470 or 407 response 8563 code. The 407 response code MAY be used when the proxy requires 8564 both user and connection authorization from user or client. In 8565 this message the proxy MUST include a Connection-Credentials 8566 header, see Section 18.13 with the next hop's identity and 8567 certificate. 8569 The client MUST upon receiving a 470 or 407 response with Connection- 8570 Credentials header take the decision on whether to accept the 8571 certificate or not (if it cannot do so, the user SHOULD be 8572 consulted). If the certificate is accepted, the client has to again 8573 send the RTSP request. In that request the client has to include the 8574 Accept-Credentials header including the hash over the DER encoded 8575 certificate for all trusted proxies in the chain. 8577 Example: 8579 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8580 CSeq: 2 8581 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8582 "192.0.2.5:4589" 8583 Accept-Ranges: npt, smpte, clock 8584 Accept-Credentials: User 8586 P->C: RTSP/2.0 470 Connection Authorization Required 8587 CSeq: 2 8588 Connection-Credentials: "rtsps://test.example.org"; 8589 MIIDNTCCAp... 8591 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8592 CSeq: 3 8593 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8594 "192.0.2.5:4589" 8595 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8596 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8597 Accept-Ranges: npt, smpte, clock 8599 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8600 CSeq: 3 8601 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8602 "192.0.2.5:4589" 8603 Via: RTSP/2.0 proxy.example.org 8604 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8605 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8606 Accept-Ranges: npt, smpte, clock 8608 One implication of this process is that the connection for secured 8609 RTSP messages may take significantly more round-trip times for the 8610 first message. A complete extra message exchange between the proxy 8611 connecting to the next hop and the client results because of the 8612 process for approval for each hop. However, if each message contains 8613 the chain of proxies that the requester accepts, the remaining 8614 message exchange should not be delayed. The procedure of including 8615 the credentials in each request rather than building state in each 8616 proxy, avoids the need for revocation procedures. 8618 20. Syntax 8620 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 8621 as defined in RFC 5234 [RFC5234]. It uses the basic definitions 8622 present in RFC 5234. 8624 Please note that ABNF strings, e.g., "Accept", are case insensitive 8625 as specified in section 2.3 of RFC 5234. 8627 The RTSP syntax makes use of the ISO 10646 character set in UTF-8 8628 encoding RFC 3629 [RFC3629]. 8630 20.1. Base Syntax 8632 RTSP header values can be folded onto multiple lines if the 8633 continuation line begins with a space or horizontal tab. All linear 8634 white space, including folding, has the same semantics as SP. A 8635 recipient MAY replace any linear white space with a single SP before 8636 interpreting the field value or forwarding the message downstream. 8637 This is intended to behave exactly as HTTP/1.1 as described in RFC 8638 2616 [RFC2616]. The SWS construct is used when linear white space is 8639 optional, generally between tokens and separators. 8641 To separate the header name from the rest of value, a colon is used, 8642 which, by the above rule, allows whitespace before, but no line 8643 break, and whitespace after, including a line break. The HCOLON 8644 defines this construct. 8646 OCTET = %x00-FF ; any 8-bit sequence of data 8647 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 8648 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 8649 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 8650 ALPHA = UPALPHA / LOALPHA 8651 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 8652 CTL = %x00-1F / %x7F ; any US-ASCII control character 8653 ; (octets 0 - 31) and DEL (127) 8654 CR = %x0D ; US-ASCII CR, carriage return (13) 8655 LF = %x0A ; US-ASCII LF, linefeed (10) 8656 SP = %x20 ; US-ASCII SP, space (32) 8657 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 8658 BACKSLASH = %x5C ; US-ASCII backslash (92) 8659 CRLF = CR LF 8660 LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space 8661 SWS = [LWS] ; Separating White Space 8662 HCOLON = *( SP / HT ) ":" SWS 8663 TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs 8664 tspecials = "(" / ")" / "<" / ">" / "@" 8665 / "," / ";" / ":" / BACKSLASH / DQUOTE 8666 / "/" / "[" / "]" / "?" / "=" 8667 / "{" / "}" / SP / HT 8668 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 8669 / %x41-5A / %x5E-7A / %x7C / %x7E) 8670 ; 1* 8671 quoted-string = ( DQUOTE *qdtext DQUOTE ) 8672 qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair 8673 / UTF8-NONASCII 8674 ; No DQUOTE and no "\" 8675 quoted-pair = "\\" / ( "\" DQUOTE ) 8676 ctext = %x20-27 / %x2A-7E 8677 / %x80-FF ; any OCTET except CTLs, "(" and ")" 8678 generic-param = token [ EQUAL gen-value ] 8679 gen-value = token / host / quoted-string 8681 safe = "$" / "-" / "_" / "." / "+" 8682 extra = "!" / "*" / "'" / "(" / ")" / "," 8683 rtsp-extra = "!" / "*" / "'" / "(" / ")" 8685 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 8686 / "a" / "b" / "c" / "d" / "e" / "f" 8687 LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 8688 ; lowercase "a-f" Hex 8689 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 8691 unreserved = ALPHA / DIGIT / safe / extra 8692 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 8694 base64 = *base64-unit [base64-pad] 8695 base64-unit = 4base64-char 8696 base64-pad = (2base64-char "==") / (3base64-char "=") 8697 base64-char = ALPHA / DIGIT / "+" / "/" 8698 SLASH = SWS "/" SWS ; slash 8699 EQUAL = SWS "=" SWS ; equal 8700 LPAREN = SWS "(" SWS ; left parenthesis 8701 RPAREN = SWS ")" SWS ; right parenthesis 8702 COMMA = SWS "," SWS ; comma 8703 SEMI = SWS ";" SWS ; semicolon 8704 COLON = SWS ":" SWS ; colon 8705 MINUS = SWS "-" SWS ; minus/dash 8706 LDQUOT = SWS DQUOTE ; open double quotation mark 8707 RDQUOT = DQUOTE SWS ; close double quotation mark 8708 RAQUOT = ">" SWS ; right angle quote 8709 LAQUOT = SWS "<" ; left angle quote 8711 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 8712 UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 8713 UTF8-1 = 8714 UTF8-2 = 8715 UTF8-3 = 8716 UTF8-4 = 8717 UTF8-CONT = %x80-BF 8719 POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] 8720 FLOAT = ["-"] POS-FLOAT 8722 20.2. RTSP Protocol Definition 8724 20.2.1. Generic Protocol elements 8725 RTSP-IRI = schemes ":" IRI-rest 8726 IRI-rest = ihier-part [ "?" iquery ] 8727 ihier-part = "//" iauthority ipath-abempty 8728 RTSP-IRI-ref = RTSP-IRI / irelative-ref 8729 irelative-ref = irelative-part [ "?" iquery ] 8730 irelative-part = "//" iauthority ipath-abempty 8731 / ipath-absolute 8732 / ipath-noscheme 8733 / ipath-empty 8735 iauthority = < As defined in RFC 3987> 8736 ipath = ipath-abempty ; begins with "/" or is empty 8737 / ipath-absolute ; begins with "/" but not "//" 8738 / ipath-noscheme ; begins with a non-colon segment 8739 / ipath-rootless ; begins with a segment 8740 / ipath-empty ; zero characters 8742 ipath-abempty = *( "/" isegment ) 8743 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 8744 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 8745 ipath-rootless = isegment-nz *( "/" isegment ) 8746 ipath-empty = 0 8748 isegment = *ipchar [";" *ipchar] 8749 isegment-nz = 1*ipchar [";" *ipchar] 8750 / ";" *ipchar 8751 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 8752 / ";" *ipchar-nc 8753 ; non-zero-length segment without any colon ":" 8754 ; No parameter (; delimited) inside path. 8756 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 8757 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 8758 ; sub-delims is different from RFC 3987 8759 ; not including ";" 8761 iquery = < As defined in RFC 3987> 8762 iunreserved = < As defined in RFC 3987> 8763 pct-encoded = < As defined in RFC 3987> 8764 RTSP-URI = schemes ":" URI-rest 8765 RTSP-REQ-URI = schemes ":" URI-req-rest 8766 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 8767 RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel 8768 schemes = "rtsp" / "rtsps" / scheme 8769 scheme = < As defined in RFC 3986> 8770 URI-rest = hier-part [ "?" query ] 8771 URI-req-rest = hier-part [ "?" query ] 8772 ; Note fragment part not allowed in requests 8773 hier-part = "//" authority path-abempty 8775 RTSP-Relative = relative-part [ "?" query ] 8776 RTSP-REQ-Rel = relative-part [ "?" query ] 8777 relative-part = "//" authority path-abempty 8778 / path-absolute 8779 / path-noscheme 8780 / path-empty 8782 authority = < As defined in RFC 3986> 8783 query = < As defined in RFC 3986> 8785 path = path-abempty ; begins with "/" or is empty 8786 / path-absolute ; begins with "/" but not "//" 8787 / path-noscheme ; begins with a non-colon segment 8788 / path-rootless ; begins with a segment 8789 / path-empty ; zero characters 8791 path-abempty = *( "/" segment ) 8792 path-absolute = "/" [ segment-nz *( "/" segment ) ] 8793 path-noscheme = segment-nz-nc *( "/" segment ) 8794 path-rootless = segment-nz *( "/" segment ) 8795 path-empty = 0 8797 segment = *pchar [";" *pchar] 8798 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 8799 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 8800 ; non-zero-length segment without any colon ":" 8801 ; No parameter (; delimited) inside path. 8803 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 8804 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 8806 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 8807 / "*" / "+" / "," / "=" 8808 ; sub-delims is different from RFC 3986/3987 8809 ; not including ";" 8811 smpte-range = smpte-type [EQUAL smpte-range-spec] 8812 ; See section 4.4 8813 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 8814 / ( "-" smpte-time ) 8815 smpte-type = "smpte" / "smpte-30-drop" 8816 / "smpte-25" / smpte-type-extension 8817 ; other timecodes may be added 8818 smpte-type-extension = "smpte" token 8819 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 8820 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 8822 npt-range = "npt" [EQUAL npt-range-spec] 8823 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 8824 npt-time = "now" / npt-sec / npt-hhmmss 8825 npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] 8826 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] 8827 npt-hh = 1*19DIGIT ; any positive number 8828 npt-mm = 1*2DIGIT ; 0-59 8829 npt-ss = 1*2DIGIT ; 0-59 8831 utc-range = "clock" [EQUAL utc-range-spec] 8832 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 8833 utc-time = utc-date "T" utc-clock "Z" 8834 utc-date = 8DIGIT 8835 utc-clock = 6DIGIT [ "." 1*9DIGIT ] 8837 feature-tag = token 8839 session-id = 1*256( ALPHA / DIGIT / safe ) 8841 extension-header = header-name HCOLON header-value 8842 header-name = token 8843 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 8845 20.2.2. Message Syntax 8846 RTSP-message = Request / Response ; RTSP/2.0 messages 8848 Request = Request-Line 8849 *((general-header 8850 / request-header 8851 / message-header) CRLF) 8852 CRLF 8853 [ message-body-data ] 8855 Response = Status-Line 8856 *((general-header 8857 / response-header 8858 / message-header) CRLF) 8859 CRLF 8860 [ message-body-data ] 8862 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 8864 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 8865 Method = "DESCRIBE" 8866 / "GET_PARAMETER" 8867 / "OPTIONS" 8868 / "PAUSE" 8869 / "PLAY" 8870 / "PLAY_NOTIFY" 8871 / "REDIRECT" 8872 / "SETUP" 8873 / "SET_PARAMETER" 8874 / "TEARDOWN" 8875 / extension-method 8877 extension-method = token 8879 Request-URI = "*" / RTSP-REQ-URI 8880 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 8882 message-body-data = 1*OCTET 8884 Status-Code = "100" ; Continue 8885 / "200" ; OK 8886 / "301" ; Moved Permanently 8887 / "302" ; Found 8888 / "303" ; See Other 8889 / "304" ; Not Modified 8890 / "305" ; Use Proxy 8891 / "400" ; Bad Request 8892 / "401" ; Unauthorized 8893 / "402" ; Payment Required 8894 / "403" ; Forbidden 8895 / "404" ; Not Found 8896 / "405" ; Method Not Allowed 8897 / "406" ; Not Acceptable 8898 / "407" ; Proxy Authentication Required 8899 / "408" ; Request Time-out 8900 / "410" ; Gone 8901 / "412" ; Precondition Failed 8902 / "413" ; Request Message Body Too Large 8903 / "414" ; Request-URI Too Large 8904 / "415" ; Unsupported Media Type 8905 / "451" ; Parameter Not Understood 8906 / "452" ; reserved 8907 / "453" ; Not Enough Bandwidth 8908 / "454" ; Session Not Found 8909 / "455" ; Method Not Valid in This State 8910 / "456" ; Header Field Not Valid for Resource 8911 / "457" ; Invalid Range 8912 / "458" ; Parameter Is Read-Only 8913 / "459" ; Aggregate operation not allowed 8914 / "460" ; Only aggregate operation allowed 8915 / "461" ; Unsupported Transport 8916 / "462" ; Destination Unreachable 8917 / "463" ; Destination Prohibited 8918 / "464" ; Data Transport Not Ready Yet 8919 / "465" ; Notification Reason Unknown 8920 / "466" ; Key Management Error 8921 / "470" ; Connection Authorization Required 8922 / "471" ; Connection Credentials not accepted 8923 / "472" ; Failure to establish secure connection 8924 / "500" ; Internal Server Error 8925 / "501" ; Not Implemented 8926 / "502" ; Bad Gateway 8927 / "503" ; Service Unavailable 8928 / "504" ; Gateway Time-out 8929 / "505" ; RTSP Version not supported 8930 / "551" ; Option not supported 8931 / extension-code 8933 extension-code = 3DIGIT 8935 Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) 8936 general-header = Accept-Ranges 8937 / Cache-Control 8938 / Connection 8939 / CSeq 8940 / Date 8941 / Media-Properties 8942 / Media-Range 8943 / Pipelined-Requests 8944 / Proxy-Supported 8945 / Range 8946 / RTP-Info 8947 / Scale 8948 / Seek-Style 8949 / Server 8950 / Session 8951 / Speed 8952 / Supported 8953 / Timestamp 8954 / Transport 8955 / User-Agent 8956 / Via 8957 / extension-header 8959 request-header = Accept 8960 / Accept-Credentials 8961 / Accept-Encoding 8962 / Accept-Language 8963 / Authorization 8964 / Bandwidth 8965 / Blocksize 8966 / From 8967 / If-Match 8968 / If-Modified-Since 8969 / If-None-Match 8970 / Notify-Reason 8971 / Proxy-Authorization 8972 / Proxy-Require 8973 / Referrer 8974 / Request-Status 8975 / Require 8976 / Terminate-Reason 8977 / extension-header 8979 response-header = Authentication-Info 8980 / Connection-Credentials 8981 / Location 8982 / MTag 8983 / Proxy-Authenticate 8984 / Proxy-Authentication-Info 8985 / Public 8986 / Retry-After 8987 / Unsupported 8988 / WWW-Authenticate 8989 / extension-header 8991 message-header = Allow 8992 / Content-Base 8993 / Content-Encoding 8994 / Content-Language 8995 / Content-Length 8996 / Content-Location 8997 / Content-Type 8998 / Expires 8999 / Last-Modified 9000 / extension-header 9002 20.2.3. Header Syntax 9004 Accept = "Accept" HCOLON 9005 [ accept-range *(COMMA accept-range) ] 9006 accept-range = media-type-range [SEMI accept-params] 9007 media-type-range = ( "*/*" 9008 / ( m-type SLASH "*" ) 9009 / ( m-type SLASH m-subtype ) 9010 ) *( SEMI m-parameter ) 9011 accept-params = "q" EQUAL qvalue *(SEMI generic-param ) 9012 qvalue = ( "0" [ "." *3DIGIT ] ) 9013 / ( "1" [ "." *3("0") ] ) 9014 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision 9015 cred-decision = ("User" [LWS cred-info]) 9016 / "Proxy" 9017 / "Any" 9018 / (token [LWS 1*header-value]) 9019 ; For future extensions 9020 cred-info = cred-info-data *(COMMA cred-info-data) 9022 cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg 9023 SEMI base64 9024 hash-alg = "sha-256" / extension-alg 9025 extension-alg = token 9026 Accept-Encoding = "Accept-Encoding" HCOLON 9027 [ encoding *(COMMA encoding) ] 9028 encoding = codings [SEMI accept-params] 9029 codings = content-coding / "*" 9030 content-coding = "identity" / token 9031 Accept-Language = "Accept-Language" HCOLON 9032 language *(COMMA language) 9033 language = language-range [SEMI accept-params] 9034 language-range = language-tag / "*" 9035 language-tag = primary-tag *( "-" subtag ) 9036 primary-tag = 1*8ALPHA 9037 subtag = 1*8ALPHA 9038 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges 9039 acceptable-ranges = (range-unit *(COMMA range-unit)) 9040 range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25" 9041 / "clock" / extension-format 9042 extension-format = token 9043 Allow = "Allow" HCOLON Method *(COMMA Method) 9044 Authentication-Info = "Authentication-Info" HCOLON auth-info 9045 auth-info = auth-info-entry *(COMMA auth-info-entry) 9046 auth-info-entry = nextnonce 9047 / message-qop 9048 / response-auth 9049 / cnonce 9050 / nonce-count 9051 nextnonce = "nextnonce" EQUAL nonce-value 9052 response-auth = "rspauth" EQUAL response-digest 9053 response-digest = DQUOTE *LHEX DQUOTE 9054 Authorization = "Authorization" HCOLON credentials 9055 credentials = basic-credential 9056 / digest-credential 9057 / other-response 9058 basic-credential = "Basic" LWS basic-credentials 9059 basic-credentials = base64 ; Base64 encoding of user-password 9060 user-password = basic-username ":" password 9061 basic-username = *CF-TEXT 9062 CF-TEXT = %x20-39 / %x3B-7E / %x80-FF ; TEXT without : 9063 password = *TEXT 9064 digest-credential = ("Digest" LWS digest-response) 9065 digest-response = dig-resp *(COMMA dig-resp) 9066 dig-resp = username / realm / nonce / digest-uri 9067 / dresponse / algorithm / cnonce 9068 / opaque / message-qop 9069 / nonce-count / auth-param 9070 username = "username" EQUAL username-value 9071 username-value = quoted-string 9072 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 9073 digest-uri-value = RTSP-REQ-URI 9074 message-qop = "qop" EQUAL qop-value 9075 cnonce = "cnonce" EQUAL cnonce-value 9076 cnonce-value = nonce-value 9077 nonce-count = "nc" EQUAL nc-value 9078 nc-value = 8LHEX 9079 dresponse = "response" EQUAL request-digest 9080 request-digest = LDQUOT 32LHEX RDQUOT 9081 auth-param = auth-param-name EQUAL 9082 ( token / quoted-string ) 9083 auth-param-name = token 9084 other-response = auth-scheme LWS auth-param 9085 *(COMMA auth-param) 9086 auth-scheme = token 9088 Bandwidth = "Bandwidth" HCOLON 1*19DIGIT 9090 Blocksize = "Blocksize" HCOLON 1*9DIGIT 9092 Cache-Control = "Cache-Control" HCOLON cache-directive 9093 *(COMMA cache-directive) 9094 cache-directive = cache-rqst-directive 9095 / cache-rspns-directive 9097 cache-rqst-directive = "no-cache" 9098 / "max-stale" [EQUAL delta-seconds] 9099 / "min-fresh" EQUAL delta-seconds 9100 / "only-if-cached" 9101 / cache-extension 9103 cache-rspns-directive = "public" 9104 / "private" 9105 / "no-cache" 9106 / "no-transform" 9107 / "must-revalidate" 9108 / "proxy-revalidate" 9109 / "max-age" EQUAL delta-seconds 9110 / cache-extension 9112 cache-extension = token [EQUAL (token / quoted-string)] 9113 delta-seconds = 1*19DIGIT 9115 Connection = "Connection" HCOLON connection-token 9116 *(COMMA connection-token) 9117 connection-token = "close" / token 9119 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 9120 cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64 9121 Content-Base = "Content-Base" HCOLON RTSP-URI 9122 Content-Encoding = "Content-Encoding" HCOLON 9123 content-coding *(COMMA content-coding) 9124 Content-Language = "Content-Language" HCOLON 9125 language-tag *(COMMA language-tag) 9126 Content-Length = "Content-Length" HCOLON 1*19DIGIT 9127 Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref 9128 Content-Type = "Content-Type" HCOLON media-type 9129 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 9130 m-type = discrete-type / composite-type 9131 discrete-type = "text" / "image" / "audio" / "video" 9132 / "application" / extension-token 9133 composite-type = "message" / "multipart" / extension-token 9134 extension-token = ietf-token / x-token 9135 ietf-token = token 9136 x-token = "x-" token 9137 m-subtype = extension-token / iana-token 9138 iana-token = token 9139 m-parameter = m-attribute EQUAL m-value 9140 m-attribute = token 9141 m-value = token / quoted-string 9143 CSeq = "CSeq" HCOLON cseq-nr 9144 cseq-nr = 1*9DIGIT 9145 Date = "Date" HCOLON RTSP-date 9146 RTSP-date = date-time ; 9147 date-time = 9148 Expires = "Expires" HCOLON RTSP-date 9149 From = "From" HCOLON from-spec 9150 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 9151 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 9152 addr-spec = RTSP-REQ-URI / absolute-URI 9153 absolute-URI = < As defined in RFC 3986> 9154 display-name = *(token LWS) / quoted-string 9155 from-param = tag-param / generic-param 9156 tag-param = "tag" EQUAL token 9157 If-Match = "If-Match" HCOLON ("*" / message-tag-list) 9158 message-tag-list = message-tag *(COMMA message-tag) 9159 message-tag = [ weak ] opaque-tag 9160 weak = "W/" 9161 opaque-tag = quoted-string 9162 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 9163 If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list) 9164 Last-Modified = "Last-Modified" HCOLON RTSP-date 9165 Location = "Location" HCOLON RTSP-REQ-URI 9166 Media-Properties = "Media-Properties" HCOLON [media-prop-list] 9167 media-prop-list = media-prop-value *(COMMA media-prop-value) 9168 media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) 9169 / "Beginning-Only" 9170 / "No-Seeking" 9171 / "Immutable" 9172 / "Dynamic" 9173 / "Time-Progressing" 9174 / "Unlimited" 9175 / ("Time-Limited" EQUAL utc-time) 9176 / ("Time-Duration" EQUAL POS-FLOAT) 9177 / ("Scales" EQUAL scale-value-list) 9178 / media-prop-ext 9179 media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] 9180 scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE 9181 scale-entry = scale-value / (scale-value COLON scale-value) 9182 scale-value = FLOAT 9183 Media-Range = "Media-Range" HCOLON [ranges-list] 9184 ranges-list = ranges-spec *(COMMA ranges-spec) 9185 MTag = "MTag" HCOLON message-tag 9186 Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val 9187 Notify-Reas-val = "end-of-stream" 9188 / "media-properties-update" 9189 / "scale-change" 9190 / Notify-Reason-extension 9191 Notify-Reason-extension = token 9192 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 9193 startup-id = 1*8DIGIT 9195 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list 9196 challenge-list = challenge *(COMMA challenge) 9197 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 9198 / ("Basic" LWS realm) 9199 / other-challenge 9200 other-challenge = auth-scheme LWS auth-param 9201 *(COMMA auth-param) 9202 digest-cln = realm / domain / nonce 9203 / opaque / stale / algorithm 9204 / qop-options / auth-param 9205 realm = "realm" EQUAL realm-value 9206 realm-value = quoted-string 9207 domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref 9208 *(1*SP RTSP-REQ-Ref ) RDQUOT 9209 nonce = "nonce" EQUAL nonce-value 9210 nonce-value = quoted-string 9211 opaque = "opaque" EQUAL quoted-string 9212 stale = "stale" EQUAL ( "true" / "false" ) 9213 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 9214 qop-options = "qop" EQUAL LDQUOT qop-value 9215 *("," qop-value) RDQUOT 9216 qop-value = "auth" / "auth-int" / token 9217 Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON auth-info 9218 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials 9219 Proxy-Require = "Proxy-Require" HCOLON feature-tag-list 9220 feature-tag-list = feature-tag *(COMMA feature-tag) 9221 Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] 9223 Public = "Public" HCOLON Method *(COMMA Method) 9225 Range = "Range" HCOLON ranges-spec 9227 ranges-spec = npt-range / utc-range / smpte-range 9228 / range-ext 9229 range-ext = extension-format [EQUAL range-value] 9230 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 9232 Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) 9233 Request-Status = "Request-Status" HCOLON req-status-info 9234 req-status-info = cseq-info LWS status-info LWS reason-info 9235 cseq-info = "cseq" EQUAL cseq-nr 9236 status-info = "status" EQUAL Status-Code 9237 reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE 9238 Require = "Require" HCOLON feature-tag-list 9239 RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec 9240 *(COMMA rtsp-info-spec)] 9241 rtsp-info-spec = stream-url 1*ssrc-parameter 9242 stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE 9243 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 9244 ri-parameter *(SEMI ri-parameter) 9245 ri-parameter = ("seq" EQUAL 1*5DIGIT) 9246 / ("rtptime" EQUAL 1*10DIGIT) 9247 / generic-param 9249 Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds) 9250 Scale = "Scale" HCOLON scale-value 9251 Seek-Style = "Seek-Style" HCOLON Seek-S-values 9252 Seek-S-values = "RAP" 9253 / "CoRAP" 9254 / "First-Prior" 9255 / "Next" 9256 / Seek-S-value-ext 9257 Seek-S-value-ext = token 9259 Server = "Server" HCOLON ( product / comment ) 9260 *(LWS (product / comment)) 9261 product = token [SLASH product-version] 9262 product-version = token 9263 comment = LPAREN *( ctext / quoted-pair) RPAREN 9265 Session = "Session" HCOLON session-id 9266 [ SEMI "timeout" EQUAL delta-seconds ] 9268 Speed = "Speed" HCOLON lower-bound MINUS upper-bound 9269 lower-bound = POS-FLOAT 9270 upper-bound = POS-FLOAT 9272 Supported = "Supported" HCOLON [feature-tag-list] 9273 Terminate-Reason = "Terminate-Reason" HCOLON TR-Info 9274 TR-Info = TR-Reason *(SEMI TR-Parameter) 9275 TR-Reason = "Session-Timeout" 9276 / "Server-Admin" 9277 / "Internal-Error" 9278 / token 9279 TR-Parameter = TR-time / TR-user-msg / generic-param 9280 TR-time = "time" EQUAL utc-time 9281 TR-user-msg = "user-msg" EQUAL quoted-string 9283 Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay] 9284 timestamp-value = *19DIGIT [ "." *9DIGIT ] 9285 delay = *9DIGIT [ "." *9DIGIT ] 9287 Transport = "Transport" HCOLON transport-spec 9288 *(COMMA transport-spec) 9289 transport-spec = transport-id *trns-parameter 9290 transport-id = trans-id-rtp / other-trans 9291 trans-id-rtp = "RTP/" profile ["/" lower-transport] 9292 ; no LWS is allowed inside transport-id 9293 other-trans = token *("/" token) 9294 profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token 9295 lower-transport = "TCP" / "UDP" / token 9296 trns-parameter = (SEMI ( "unicast" / "multicast" )) 9297 / (SEMI "interleaved" EQUAL channel ["-" channel]) 9298 / (SEMI "ttl" EQUAL ttl) 9299 / (SEMI "layers" EQUAL 1*DIGIT) 9300 / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) 9301 / (SEMI "mode" EQUAL mode-spec) 9302 / (SEMI "dest_addr" EQUAL addr-list) 9303 / (SEMI "src_addr" EQUAL addr-list) 9304 / (SEMI "setup" EQUAL contrans-setup) 9305 / (SEMI "connection" EQUAL contrans-con) 9306 / (SEMI "RTCP-mux") 9307 / (SEMI "MIKEY" EQUAL MIKEY-Value) 9308 / (SEMI trn-param-ext) 9309 contrans-setup = "active" / "passive" / "actpass" 9310 contrans-con = "new" / "existing" 9311 trn-param-ext = par-name [EQUAL trn-par-value] 9312 par-name = token 9313 trn-par-value = *(rtsp-unreserved / quoted-string) 9314 ttl = 1*3DIGIT ; 0 to 255 9315 ssrc = 8HEX 9316 channel = 1*3DIGIT ; 0 to 255 9317 MIKEY-Value = base64 9318 mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) 9319 mode = "PLAY" / token 9320 addr-list = quoted-addr *(SLASH quoted-addr) 9321 quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE 9322 host-port = ( host [":" port] ) 9323 / ( ":" port ) 9324 extension-addr = 1*qdtext 9325 host = < As defined in RFC 3986> 9326 port = < As defined in RFC 3986> 9327 Unsupported = "Unsupported" HCOLON feature-tag-list 9328 User-Agent = "User-Agent" HCOLON ( product / comment ) 9329 *(LWS (product / comment)) 9330 Via = "Via" HCOLON via-parm *(COMMA via-parm) 9331 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 9332 via-params = via-ttl / via-maddr 9333 / via-received / via-extension 9334 via-ttl = "ttl" EQUAL ttl 9335 via-maddr = "maddr" EQUAL host 9336 via-received = "received" EQUAL (IPv4address / IPv6address) 9337 IPv4address = < As defined in RFC 3986> 9338 IPv6address = < As defined in RFC 3986> 9339 via-extension = generic-param 9340 sent-protocol = protocol-name SLASH protocol-version 9341 SLASH transport-prot 9342 protocol-name = "RTSP" / token 9343 protocol-version = token 9344 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 9345 other-transport = token 9346 sent-by = host [ COLON port ] 9348 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 9350 20.3. SDP extension Syntax 9352 This section defines in ABNF the SDP extensions defined for RTSP. 9353 See Appendix D for the definition of the extensions in text. 9355 control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF 9357 a-range-def = "a=range:" ranges-spec CRLF 9359 a-mtag-def = "a=mtag:" message-tag CRLF 9361 21. Security Considerations 9363 The security considerations and threats around RTSP and its usage can 9364 be divided into considerations around the signaling protocol itself 9365 and the issues related to the media stream delivery. However, when 9366 it comes to mitigations of security threats, a threat depending on 9367 the media stream delivery may in fact be mitigated by a mechanism in 9368 the signaling protocol. 9370 There are several chapters and an appendix in this document that 9371 define security solutions for the protocol. We will reference them 9372 when discussing the threats below. But the reader should take 9373 special notice of the Security Framework (Section 19) and the 9374 specification of how to use SRTP and its key-mangement 9375 (Appendix C.1.4) to achieve certain aspects of the media security. 9377 21.1. Signaling Protocol Threats 9379 This section focuses on issues related to the signaling protocol. 9380 Because of the similarity in syntax and usage between RTSP servers 9381 and HTTP servers, the security considerations outlined in [H15] apply 9382 also. 9384 Specifically, please note the following: 9386 Abuse of Server Log Information: A server is in the position to save 9387 personal data about a user's requests which might identify 9388 their media consumption patterns or subjects of interest. This 9389 information is clearly confidential in nature and its handling 9390 can be constrained by law in certain countries. RTSP servers 9391 will presumably have similar logging mechanisms to HTTP, and 9392 thus should be equally guarded in protecting the contents of 9393 those logs, thus protecting the privacy of the users of the 9394 servers. People using the RTSP protocol to provide media are 9395 responsible for ensuring that logging material is not 9396 distributed without the permission of any individuals that are 9397 identifiable by the published results. 9399 Transfer of Sensitive Information: There is no reason to believe 9400 that information transferred or controlled via RTSP may be any 9401 less sensitive than that normally transmitted via HTTP. 9402 Therefore, all of the precautions regarding the protection of 9403 data privacy and user privacy apply to implementors of RTSP 9404 clients, servers, and proxies. See [H15.1.2] for further 9405 details. 9407 Attacks Based On File and Path Names: Though RTSP URIs are opaque 9408 handles that do not necessarily have file system semantics, it 9409 is anticipated that many implementations will translate 9410 portions of the Request-URIs directly to file system calls. In 9411 such cases, file systems SHOULD follow the precautions outlined 9412 in [H15.2], such as checking for ".." in path components. 9414 Personal Information: RTSP clients are often privy to the same 9415 information that HTTP clients are (user name, location, etc.) 9416 and thus should be equally sensitive. See [H15.1] for further 9417 recommendations. 9419 Privacy Issues Connected to Accept Headers: Since may of the same 9420 "Accept" headers exist in RTSP as in HTTP, the same caveats 9421 outlined in [H15.1.4] with regards to their use should be 9422 followed. 9424 DNS Spoofing: Presumably, given the longer connection times 9425 typically associated to RTSP sessions relative to HTTP 9426 sessions, RTSP client DNS optimizations should be less 9427 prevalent. Nonetheless, the recommendations provided in 9428 [H15.3] are still relevant to any implementation which attempts 9429 to rely on a DNS-to-IP mapping to hold beyond a single use of 9430 the mapping. 9432 Location Headers and Spoofing: If a single server supports multiple 9433 organizations that do not trust each another, then it MUST 9434 check the values of Location and Content-Location header fields 9435 in responses that are generated under control of said 9436 organizations to make sure that they do not attempt to 9437 invalidate resources over which they have no authority. 9438 ([H15.4]) 9440 In addition to the recommendations in the current HTTP specification 9441 (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 9442 2068 [RFC2068], future HTTP specifications may provide additional 9443 guidance on security issues. 9445 The following are added considerations for RTSP implementations. 9447 Session hijacking: Since there is no or little relation between a 9448 transport layer connection and an RTSP session, it is possible 9449 for a malicious client to issue requests with random session 9450 identifiers which could affect other clients of an unsuspecting 9451 server. To mitigate this the server SHALL use a large, random 9452 and non-sequential session identifier to minimize the 9453 possibility of this kind of attack. However, unless the RTSP 9454 signaling is always confidentiality protected, e.g., using TLS, 9455 an on-path attacker will be able to hijack a session. Another 9456 choice for preventing session hijacking is to use client 9457 authentication and only allow the authenticated client creating 9458 the session to access that session. 9460 Authentication: Servers SHOULD implement both basic and digest 9461 [RFC2617] authentication. In environments requiring tighter 9462 security for the control messages, the transport layer 9463 mechanism TLS [RFC5246] SHOULD be used. 9465 Suspicious behavior: RTSP servers upon detecting instances of 9466 behavior which is deemed a security risk SHOULD return error 9467 code 403 (Forbidden). RTSP servers SHOULD also be aware of 9468 attempts to probe the server for weaknesses and entry points 9469 and MAY arbitrarily disconnect and ignore further requests from 9470 clients which are deemed to be in violation of local security 9471 policy. 9473 TLS through proxies: If one uses the possibility to connect TLS in 9474 multiple legs (Section 19.3) one really needs to be aware of 9475 the trust model. That procedure requires full faith and trust 9476 in all proxies, which will be identified, that one allows to 9477 connect through. They are men in the middle and have access to 9478 all that goes on over the TLS connection. Thus it is important 9479 to consider if that trust model is acceptable in the actual 9480 application. Further discussion of the actual trust model is 9481 in Section 19.3. 9483 Resource Exhaustion: As RTSP is a stateful protocol and establishes 9484 resource usage on the server there is a clear possibility to 9485 attack the server by trying to overbook these resources to 9486 perform a denial of service attack. This attack can be both 9487 against ongoing sessions and to prevent others from 9488 establishing sessions. RTSP agents will need to have 9489 mechanisms to prevent single peers from consuming extensive 9490 amounts of resources. The methods for guarding against this 9491 are varied and depends on the agent's role and capabilities and 9492 policies. Each implementation has to carefully consider their 9493 methods and policies to mitigate this threat. For example 9494 regarding handling of connections there are recommendations in 9495 Section 10.7. 9497 The above threats and considerations have resulted in a set of 9498 security functions and mechanisms built into or used by the protocol. 9499 The signaling protocol relies on two security features defined in the 9500 Security Framework (Section 19) namely client authentication using 9501 HTTP authentication and TLS based transport protection of the 9502 signaling messages. Both of these mechanisms are required to be 9503 implemented by any RTSP agent. 9505 A number of different security mitigations have been designed into 9506 the protocol and will be instantiated if the specification is 9507 implemented written, for example by ensuring sufficient amount of 9508 entropy in the randomly generated session identifiers when not using 9509 client authentication to minimize the risk of session hijacking. 9510 When client authentication is used the protection against hijacking 9511 will be greatly improved by scoping the accessible sessions to the 9512 one this client identity has created. Some of the above threats are 9513 such that the implementation of the RTSP functionality itself needs 9514 to consider which policy and strategy it uses to mitigate them. 9516 21.2. Media Stream Delivery Threats 9518 The fact that RTSP establishes and controls a media stream delivery 9519 results in a set of security issues related to the media streams. 9520 This section will attempt to analyze general threats, however the 9521 choice of media stream transport protocol, such as RTP will result in 9522 some differences in threats and what mechanisms that exist to 9523 mitigate them. Thus it becomes important that each specification of 9524 a new media stream transport and delivery protocol usable by RTSP 9525 requires its own security analysis. This section includes one for 9526 RTP. 9528 The set of general threats from or by the media stream delivery 9529 itself are: 9531 Concentrated denial-of-service attack: The protocol offers the 9532 opportunity for a remote-controlled denial-of-service (DoS) 9533 attack, where the media stream is the hammer in that DoS attack. 9534 See Section 21.2.1. 9536 Media Confidentiality: The media delivery may contain content of any 9537 type and it is not possible in general to determine how sensitive 9538 this content is from a confidentiality point. Thus it is a strong 9539 requirement that any media delivery protocol provides a method for 9540 providing confidentiality of the actual media content. In 9541 addition to the media level confidentiality it becomes critical 9542 that no resource identifiers used in the signaling are exposed to 9543 an attacker as they may have human understandable names, or may be 9544 also available to the attacker so they can determine the content 9545 the user was delivered. Thus the signaling protocol must also 9546 provide confidentiality protection of any information related to 9547 the media resource. 9549 Media Integrity and Authentication: There are several reasons, such 9550 as discrediting the target, misinformation of the target, why an 9551 attacker will be interested in substituting the media stream sent 9552 out from the RTSP server with one of the attacker's creation or 9553 selection. Therefore it is important that the media protocol 9554 provides mechanisms to verify the source authentication, integrity 9555 and prevent replay attacks on the media stream. 9557 Scope of Multicast: If RTSP is used to control the transmission of 9558 media onto a multicast network the scope of the delivery must be 9559 considered. RTSP supports the TTL Transport header parameter to 9560 indicate this scope for IPv4. IPv6 has a different mechanism for 9561 scope boundary. However, such scope control has risks, as it may 9562 be set too large and distribute media beyond the intended scope. 9564 Below (Section 21.2.2) we do a protocol specific analysis of security 9565 considerations for RTP based media transport. In that section we 9566 also make clear the requirements on implementing security functions 9567 for RTSP agents supporting media delivery over RTP. 9569 21.2.1. Remote Denial of Service Attack 9571 The attacker may initiate traffic flows to one or more IP addresses 9572 by specifying them as the destination in SETUP requests. While the 9573 attacker's IP address may be known in this case, this is not always 9574 useful in prevention of more attacks or ascertaining the attacker's 9575 identity. Thus, an RTSP server MUST only allow client-specified 9576 destinations for RTSP-initiated traffic flows if the server has 9577 ensured that the specified destination address accepts receiving 9578 media through different security mechanisms. Security mechanisms 9579 that are acceptable in order of increasing generality are: 9581 o Verification of the client's identity against a database of known 9582 users using RTSP authentication mechanisms (preferably digest 9583 authentication or stronger) 9585 o A list of addresses that have consented to be media destinations, 9586 especially considering user identity 9588 o Media path based verification 9590 The server SHOULD NOT allow the destination field to be set unless a 9591 mechanism exists in the system to authorize the request originator to 9592 direct streams to the recipient. It is preferred that this 9593 authorization be performed by the media recipient (destination) 9594 itself and the credentials passed along to the server. However, in 9595 certain cases, such as when the recipient address is a multicast 9596 group, or when the recipient is unable to communicate with the server 9597 in an out-of-band manner, this may not be possible. In these cases 9598 the server may chose another method such as a server-resident 9599 authorization list to ensure that the request originator has the 9600 proper credentials to request stream delivery to the recipient. 9602 One solution that performs the necessary verification of acceptance 9603 of media suitable for unicast based delivery is the Interactive 9604 Connectivity Establishment (ICE) [RFC5245] based NAT traversal method 9605 described in [I-D.ietf-mmusic-rtsp-nat]. This mechanism uses random 9606 passwords and a username so that the probability of unintended 9607 indication as a valid media destination is very low. In addition the 9608 server includes in its Session Traversal Utilities for NAT (STUN) 9609 [RFC5389] requests a cookie (consisting of random material) that the 9610 destination echoes back, thus the solution also safe-guards against 9611 having an off-path attacker being able to spoof the STUN checks. 9612 This leaves this solution vulnerable only to on-path attackers that 9613 can see the STUN requests go to the target of attack and thus forge a 9614 response. 9616 For delivery to multicast addresses there is a need for another 9617 solution which is not specified in this memo. 9619 21.2.2. RTP Security analysis 9621 RTP is a commonly used media transport protocol and has been the most 9622 common choice for RTSP 1.0 implementations. The core RTP protocol 9623 has been in use for a long time and it has well-known security 9624 properties and the RTP security consideration (Section 9 of 9625 [RFC3550]) needs to be reviewed. In perspective of the usage of RTP 9626 in context of RTSP the following properties should be noted: 9628 Stream Additions: RTP has support for multiple simultaneous media 9629 streams in each RTP session. As some use cases require support 9630 for non-synchronized adding and removal of media streams and their 9631 identifiers an attacker can easily insert additional media streams 9632 into a session context that according to protocol design is 9633 intended to be played out. Another threat vector is one of denial 9634 of service by exhausting the resources of the RTP session 9635 receiver, for example by using a large number of SSRC identifiers 9636 simultaneously. The strong mitigation of this is to ensure that 9637 one cryptographically authenticates any incoming packet flow to 9638 the RTP session. Weak mitigations like blocking additional media 9639 streams in session contexts easily lead to a denial of service 9640 vulnerability in addition to preventing certain RTP extensions or 9641 use cases which rely on multiple media streams, such as RTP 9642 retransmission [RFC4588] to function. 9644 Forged Feedback: The built in RTP control Protocol (RTCP) also 9645 offers a large attack surface for a couple of different types of 9646 attacks. One venue is to send RTCP feedback to the media sender 9647 indicating large amounts of packet loss and thus trigger a media 9648 bit-rate adaptation response from the sender resulting in lowered 9649 media quality and potentially shut down of the media stream. 9650 Another attack is to perform a resource exhaustion attack on the 9651 receiver by using many SSRC identifiers to create large state 9652 tables and increase the RTCP related processing demands. 9654 RTP/RTCP Extensions: RTP and RTCP extensions generally provide 9655 additional and sometimes extremely powerful tools to do denial of 9656 service or service disruption. For example the Code Control 9657 Message [RFC5104] RTCP extensions enables both locking down the 9658 bit-rate to low values and disruption of video quality by 9659 requesting Intra frames. 9661 Taking into account the above general discussion in Section 21.2 and 9662 the RTP specific discussion in this section it is clear that it is 9663 necessary that a strong security mechanism is supported to protect 9664 RTP. Therefore this specification has the following requirements on 9665 RTP security functions for all RTSP agents that handles media streams 9666 and where the media stream transport is done using RTP. 9668 RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] 9669 and thus the SAVP profile. In addition the secure AVP profile 9670 (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is 9671 implemented. This specification requires no additional crypto 9672 transforms or configuration values beyond those > mandatory to 9673 implement in RFC3711, i.e., AES-CM and HMAC-SHA1. The default key- 9674 management mechanism which MUST be implemented is the one defined in 9675 the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY 9676 implementation MUST implement the necessary functions for MIKEY-RSA-R 9677 mode [RFC4738] and in addition the SRTP parameter negotiation 9678 necessary to negotiate the supported SRTP transforms and parameters. 9680 22. IANA Considerations 9682 This section sets up a number of registries for RTSP 2.0 that should 9683 be maintained by IANA. These registries are separate from any 9684 registries existing for RTSP 1.0. For each registry there is a 9685 description of what it is required to contain, what specification is 9686 needed when adding an entry with IANA, and finally the entries that 9687 this document needs to register. See also the Section 2.7 "Extending 9688 RTSP". There is also an IANA registration of three SDP attributes. 9690 Registries or entries in registries which have been made for RTSP 1.0 9691 are not moved to RTSP 2.0. The registries and entries in registries 9692 of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry 9693 in a registry is also required in RTSP 2.0, it MUST follow the 9694 procedure defined below to allocate the registry or entry in a 9695 registry. 9697 The sections describing how to register an item uses some of the 9698 registration policies described in RFC 5226 [RFC5226], namely "First 9699 Come, First Served", "Expert Review, "Specification Required", and 9700 "Standards Action". 9702 RFC-Editor Note: Please replace all occurrences of RFCXXXX with 9703 the RFC number this specification receives when published. 9705 In case a registry requires a contact person, the authors, with 9706 Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are 9707 the contact persons for any entries created by this document. 9709 A registration request to IANA MUST contain the following 9710 information: 9712 o A name of the item to register according to the rules specified by 9713 the intended registry. 9715 o Indication of who has change control over the feature (for 9716 example, IETF, ISO, ITU-T, other international standardization 9717 bodies, a consortium, a particular company or group of companies, 9718 or an individual); 9720 o A reference to a further description, if available, for example 9721 (in decreasing order of preference) an RFC, a published standard, 9722 a published paper, a patent filing, a technical report, documented 9723 source code or a computer manual; 9725 o For proprietary features, contact information (postal and email 9726 address); 9728 22.1. Feature-tags 9730 22.1.1. Description 9732 When a client and server try to determine what part and functionality 9733 of the RTSP specification and any future extensions that its counter 9734 part implements there is need for a namespace. This registry 9735 contains named entries representing certain functionality. 9737 The usage of feature-tags is explained in Section 11 and 9738 Section 13.1. 9740 22.1.2. Registering New Feature-tags with IANA 9742 The registering of feature-tags is done on a first come, first served 9743 basis. 9745 The name of the feature MUST follow these rules: The name may be of 9746 any length, but SHOULD be no more than twenty characters long. The 9747 name MUST NOT contain any spaces, or control characters. The 9748 registration MUST indicate if the feature-tag applies to clients, 9749 servers, or proxies only or any combinations of these. Any 9750 proprietary feature MUST have as the first part of the name a vendor 9751 tag, which identifies the organization. The registry entries consist 9752 of the feature tag, a one paragraph description of what it 9753 represents, its applicability (server, client, proxy, any 9754 combination) and a reference to its specification where applicable. 9756 Examples for a vendor tag describing a proprietary feature are: 9758 vendorA.specfeat01 9760 vendorA.specfeat02 9762 22.1.3. Registered entries 9764 The following feature-tags are defined in this specification and 9765 hereby registered. The change control belongs to the IETF. 9767 play.basic: The implementation for delivery and playback operations 9768 according to the core RTSP specification, as defined in this 9769 memo. Applies for both clients, servers and proxies. See 9770 Section 11.1. 9772 play.scale: Support of scale operations for media playback. Applies 9773 only for servers. See Section 18.46. 9775 play.speed: Support of the speed functionality for media delivery. 9776 Applies only for servers. See Section 18.50. 9778 setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as 9779 discussed in Appendix C.1.6.4. Applies for both client and 9780 servers and any media caching proxy. 9782 This should be represented by IANA as a table with the feature tags, 9783 contact person and their references. 9785 22.2. RTSP Methods 9787 22.2.1. Description 9789 Methods are described in Section 13. Extending the protocol with new 9790 methods allow for totally new functionality. 9792 22.2.2. Registering New Methods with IANA 9794 A new method MUST be registered through an IETF Standards Action. 9795 The reason is that new methods may radically change the protocol's 9796 behavior and purpose. 9798 A specification for a new RTSP method MUST consist of the following 9799 items: 9801 o A method name which follows the ABNF rules for methods. 9803 o A clear specification what a request using the method does and 9804 what responses are expected. Which directions the method is used, 9805 C->S or S->C or both. How the use of headers, if any, modifies 9806 the behavior and effect of the method. 9808 o A list or table specifying which of the IANA registered headers 9809 that are allowed to be used with the method in request or/and 9810 response. The list or table SHOULD follow the format of tables in 9811 Section 18. 9813 o Describe how the method relates to network proxies. 9815 22.2.3. Registered Entries 9817 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 9818 GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, 9819 SET_PARAMETER, and TEARDOWN. The initial table of the registry is 9820 provided below. 9822 Method Directionality Reference 9823 ----------------------------------------------------- 9824 DESCRIBE C->S [RFCXXXX] 9825 GET_PARAMETER C->S, S->C [RFCXXXX] 9826 OPTIONS C->S, S->C [RFCXXXX] 9827 PAUSE C->S [RFCXXXX] 9828 PLAY C->S [RFCXXXX] 9829 PLAY_NOTIFY S->C [RFCXXXX] 9830 REDIRECT S->C [RFCXXXX] 9831 SETUP C->S [RFCXXXX] 9832 SET_PARAMETER C->S, S->C [RFCXXXX] 9833 TEARDOWN C->S, S->C [RFCXXXX] 9835 22.3. RTSP Status Codes 9837 22.3.1. Description 9839 A status code is the three digit number used to convey information in 9840 RTSP response messages, see Section 8. The number space is limited 9841 and care should be taken not to fill the space. 9843 22.3.2. Registering New Status Codes with IANA 9845 A new status code registration follows the policy of IETF Review. 9846 New RTSP functionality requiring Status Codes should first be 9847 registered in the range x50-x99. Only when the range is full should 9848 registrations be done in the x00-x49 range, unless it is to adopt an 9849 HTTP extension also to RTSP. The reason is to enable any HTTP 9850 extension to be adopted to RTSP without needing to renumber any 9851 related status codes. A specification for a new status code MUST 9852 specify the following: 9854 o The registered number. 9856 o A description of what the status code means and the expected 9857 behavior of the sender and receiver of the code. 9859 22.3.3. Registered Entries 9861 RFCXXXX, registers the numbered status code defined in the ABNF entry 9862 "Status-Code" except "extension-code" (that defines the syntax 9863 allowed for future extensions) in Section 20.2.2. 9865 22.4. RTSP Headers 9866 22.4.1. Description 9868 By specifying new headers a method(s) can be enhanced in many 9869 different ways. An unknown header will be ignored by the receiving 9870 agent. If the new header is vital for a certain functionality, a 9871 feature-tag for the functionality can be created and demanded to be 9872 used by the counter-part with the inclusion of a Require header 9873 carrying the feature-tag. 9875 22.4.2. Registering New Headers with IANA 9877 Registrations in the registry can be done following the Expert Review 9878 policy. A specification SHOULD be provided, preferably an IETF RFC 9879 or other Standards Developing Organization specification. The 9880 minimal information in a registration request is the header name and 9881 the contact information. 9883 The specification SHOULD contain the following information: 9885 o The name of the header. 9887 o An ABNF specification of the header syntax. 9889 o A list or table specifying when the header may be used, 9890 encompassing all methods, their request or response, the direction 9891 (C->S or S->C). 9893 o How the header is to be handled by proxies. 9895 o A description of the purpose of the header. 9897 22.4.3. Registered entries 9899 All headers specified in Section 18 in RFCXXXX are to be registered. 9900 The Registry is to include header name and reference. 9902 Furthermore the following legacy RTSP headers defined in other 9903 specifications are registered with header name, reference and 9904 description according to below list. Note: These references may not 9905 fulfill all of the above rules for registrations due to their legacy 9906 status. 9908 o x-wap-profile defined in [TS-26234]. The x-wap-profile request 9909 header contains one or more absolute URLs to the requesting 9910 agent's device capability profile. 9912 o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff 9913 request header contains a subset of a device capability profile. 9915 o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- 9916 warning is a response header that contains error codes explaining 9917 to what extent the server has been able to match the terminal 9918 request in regards to device capability profile as described using 9919 x-wap-profile and x-wap-profile-diff headers. 9921 o x-predecbufsize defined in [TS-26234]. This response header 9922 provides an RTSP agent with the TS 26.234 Annex G hypothetical 9923 pre-decoder buffer size. 9925 o x-initpredecbufperiod defined in [TS-26234]. This response header 9926 provides an RTSP agent with the TS 26.234 Annex G hypothetical 9927 pre-decoder buffering period. 9929 o x-initpostdecbufperiod defined in [TS-26234]. This response 9930 header provides an RTSP agent with the TS 26.234 Annex G post- 9931 decoder buffering period. 9933 o 3gpp-videopostdecbufsize defined in [TS-26234]. This response 9934 header provides an RTSP agent with the TS 26.234 defined post- 9935 decoder buffer size usable for H.264 (AVC) video streams. 9937 o 3GPP-Link-Char defined in [TS-26234]. This request header 9938 provides the RTSP server with the RTSP client's link 9939 characteristics as determined from the radio interface. The 9940 information that can be provided are guaranteed bit-rate, maximum 9941 bit-rate and maximum transfer delay. 9943 o 3GPP-Adaptation defined in [TS-26234]. This general header is 9944 part of the bit-rate adaptation solution specified for PSS. It 9945 provides the RTSP client's buffer sizes and target buffer levels 9946 to the server and responses are used to acknowledge the support 9947 and values. 9949 o 3GPP-QoE-Metrics defined in [TS-26234]. This general header is 9950 used by PSS RTSP agents to negotiate the quality of experience 9951 metrics that a client should gather and report to the server. 9953 o 3GPP-QoE-Feedback defined in [TS-26234]. This request header is 9954 used by RTSP clients supporting PSS to report the actual values of 9955 the metrics gathered in its quality of experience metering. 9957 The use of "x-" is NOT RECOMMENDED but the above headers in the 9958 register list were defined prior to the clarification. 9960 22.5. Accept-Credentials 9962 The security framework's TLS connection mechanism has two 9963 registerable entities. 9965 22.5.1. Accept-Credentials policies 9967 In Section 19.3.1 three policies for how to handle certificates are 9968 specified. Further policies may be defined and MUST be registered 9969 with IANA using the following rules: 9971 o Registering requires an IETF Standards Action 9973 o A registration is required to name a contact person. 9975 o Name of the policy. 9977 o A describing text that explains how the policy works for handling 9978 the certificates. 9980 This specification registers the following values: 9982 Any 9984 Proxy 9986 User 9988 22.5.2. Accept-Credentials hash algorithms 9990 The Accept-Credentials header (See Section 18.2) allows for the usage 9991 of other algorithms for hashing the DER records of accepted entities. 9992 The registration of any future algorithm is expected to be extremely 9993 rare and could also cause interoperability problems. Therefore the 9994 bar for registering new algorithms is intentionally placed high. 9996 Any registration of a new hash algorithm MUST fulfill the following 9997 requirement: 9999 o Follow the IETF Standards Action policy. 10001 o A definition of the algorithm and its identifier meeting the 10002 "token" ABNF requirement. 10004 The registered value is: 10005 Hash Alg. Id Reference 10006 ------------------------ 10007 sha-256 [RFCXXXX] 10009 22.6. Cache-Control Cache Directive Extensions 10011 There exists a number of cache directives which can be sent in the 10012 Cache-Control header. A registry for these cache directives MUST be 10013 defined with the following rules: 10015 o Registering requires an IETF Standards Action or IESG Approval. 10017 o A registration is required to contain a contact person. 10019 o Name of the directive and a definition of the value, if any. 10021 o Specification if it is a request or response directive. 10023 o A describing text that explains how the cache directive is used 10024 for RTSP controlled media streams. 10026 This specification registers the following values: 10028 no-cache: 10030 public: 10032 private: 10034 no-transform: 10036 only-if-cached: 10038 max-stale: 10040 min-fresh: 10042 must-revalidate: 10044 proxy-revalidate: 10046 max-age: 10048 The registry should be represented as: Name of the directive, contact 10049 person and reference. 10051 22.7. Media Properties 10052 22.7.1. Description 10054 The media streams being controlled by RTSP can have many different 10055 properties. The media properties required to cover the use cases 10056 that were in mind when writing the specification are defined. 10057 However, it can be expected that further innovation will result in 10058 new use cases or media streams with properties not covered by the 10059 ones specified here. Thus new media properties can be specified. As 10060 new media properties may need a substantial amount of new definitions 10061 to correctly specify behavior for this property the bar is intended 10062 to be high. 10064 22.7.2. Registration Rules 10066 Registering a new media property MUST fulfill the following 10067 requirements 10069 o Follow the Specification Required policy and get the approval of 10070 the designated Expert. 10072 o Have an ABNF definition of the media property value name that 10073 meets "media-prop-ext" definition 10075 o Define which media property group it belongs to or define a new 10076 group. 10078 o A Contact Person for the Registration 10080 o Description of all changes to the behavior of the RTSP protocol as 10081 result of these changes. 10083 22.7.3. Registered Values 10085 This specification registers the ten values listed in Section 18.29. 10086 The registry should be represented as: Name of the media property, 10087 property group, contact person and reference. 10089 22.8. Notify-Reason header 10091 22.8.1. Description 10093 Notify-Reason values are used for indicating the reason the 10094 notification was sent. Each reason has its associated rules on what 10095 headers and information that may or must be included in the 10096 notification. New notification behaviors need to be specified to 10097 enable interoperable usage, thus a specification of each new value is 10098 required. 10100 22.8.2. Registration Rules 10102 Registrations for new Notify-Reason value MUST fulfill the following 10103 requirements 10105 o Follow the Specification Required policy and get the approval of 10106 the designated Expert. 10108 o An ABNF definition of the Notify reason value name that meets 10109 "Notify-Reason-extension" definition 10111 o A Contact Person for the Registration 10113 o Description of which headers shall be included in the request and 10114 response, when it should be sent, and any effect it has on the 10115 server client state. 10117 22.8.3. Registered Values 10119 This specification registers 3 values defined in the Notify-Reas-val 10120 ABNF, Section 20.2.3: 10122 end-of-stream: This Notify-Reason value indicates the end of a media 10123 stream. 10125 media-properties-update: This Notify-Reason value allows the server 10126 to indicate that the properties of the media has changed during 10127 the playout. 10129 scale-change: This Notify-Reason value allows the server to notify 10130 the client about a change in the Scale of the media. 10132 The registry entries should be represented in the registry as: Name, 10133 short description, contact and reference. 10135 22.9. Range Header Formats 10137 22.9.1. Description 10139 The Range header (Section 18.40) allows for different range formats. 10140 These range formats also needs an identifier to be used the Accept- 10141 Ranges header (Section 18.5). New range formats may be registered, 10142 but moderation should be applied as it makes interoperability more 10143 difficult. 10145 22.9.2. Registration Rules 10147 A registration MUST fulfill the following requirements: 10149 o Follow the Specification Required policy. 10151 o An ABNF definition of the range format that fulfills the "range- 10152 ext" definition. 10154 o Define the range format identifier used in Accept-Ranges header 10155 according to the "extension-format" definition. 10157 o A Contact person for the registration. 10159 o Rules for how one handles the range when using a negative Scale. 10161 22.9.3. Registered Values 10163 The registry should be represented as: Range header format 10164 identifier, Name of the range format, contact person and reference. 10165 This specification registers the following values. 10167 npt: Normal Play Time 10169 clock: UTC Absolute Time format 10171 smpte: SMPTE Timestamps 10173 smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop) 10175 smpte-25: SMPTE Timestamps 25 Frames/sec 10177 22.10. Terminate-Reason Header 10179 The Terminate-Reason header (Section 18.52) has two registries for 10180 extensions. 10182 22.10.1. Redirect Reasons 10184 Registrations are done under the policy of Expert Review. The 10185 registered value needs to follow the Terminate-Reason ABNF, i.e., be 10186 a token. The specification needs to provide a definition of what 10187 procedures are to be followed when a client receives this redirect 10188 reason. This specification registers three values: 10190 o Session-Timeout 10191 o Server-Admin 10193 o Internal-Error 10195 The registry should be represented as: Name of the Redirect Reason, 10196 contact person and reference. 10198 22.10.2. Terminate-Reason Header Parameters 10200 Registrations are done under the policy of Specification Required. 10201 The registrations must define a syntax for the parameter that also 10202 follows the syntax allowed by the RTSP 2.0 specification. A contact 10203 person is also required. This specification registers: 10205 o time 10207 o user-msg 10209 The registry should be represented as: Name of the Terminate Reason, 10210 contact person and reference. 10212 22.11. RTP-Info header parameters 10214 22.11.1. Description 10216 The RTP-Info header (Section 18.45) carries one or more parameter 10217 value pairs with information about a particular point in the RTP 10218 stream. RTP extensions or new usages may need new types of 10219 information. As RTP information that could be needed is likely to be 10220 generic enough and to maximize the interoperability, new registration 10221 requires Specification Required. 10223 22.11.2. Registration Rules 10225 Registrations for new RTP-Info value MUST fulfill the following 10226 requirements 10228 o Follow the Specification Required policy and get the approval of 10229 the designated Expert. 10231 o Have an ABNF definition that meets the "generic-param" definition 10233 o A Contact Person for the Registration 10235 22.11.3. Registered Values 10237 This specification registers the following parameter value pairs: 10239 o url 10241 o ssrc 10243 o seq 10245 o rtptime 10247 The registry should be represented as: Name of the parameter, contact 10248 person and reference. 10250 22.12. Seek-Style Policies 10252 22.12.1. Description 10254 New seek policies may be registered, however, a large number of these 10255 will complicate implementation substantially. The impact of unknown 10256 policies is that the server will not honor the unknown and use the 10257 server default policy instead. 10259 22.12.2. Registration Rules 10261 Registrations of new Seek-Style polices MUST fulfill the following 10262 requirements 10264 o Follow the Specification Required policy. 10266 o Have an ABNF definition of the Seek-Style policy name that meets 10267 "Seek-S-value-ext" definition 10269 o A Contact Person for the Registration 10271 o Description of which headers shall be included in the request and 10272 response, when it should be sent, and any affect it has on the 10273 server client state. 10275 22.12.3. Registered Values 10277 This specification registers 4 values: 10279 o RAP 10281 o CoRAP 10282 o First-Prior 10284 o Next 10286 The registry should be represented as: Name of the Seek-Style Policy, 10287 short description, contact person and reference. 10289 22.13. Transport Header Registries 10291 The transport header (Section 18.54) contains a number of parameters 10292 which have possibilities for future extensions. Therefore registries 10293 for these need to be defined. 10295 22.13.1. Transport Protocol Identifier 10297 A Transport Protocol Specification consists of a Transport Protocol 10298 Identifier, representing some combination of transport protocols, and 10299 any number of transport header parameters required or optional to use 10300 with the identified protocol specification. This registry contains 10301 the identifiers used by registered Transport Protocol Identifiers. 10303 A registry for the parameter transport protocol identifier MUST be 10304 defined with the following rules: 10306 o Registering uses the policy of Specification Required. 10308 o A contact person or organization with address and email. 10310 o A value definition that are following the ABNF syntax definition 10311 of "transport-id" Section 20.2.3. 10313 o A describing text that explains how the registered value are used 10314 in RTSP, which underlying transport protocols that are used, and 10315 any required Transport header parameters. 10317 The registry should be represented as: The protocol ID string, 10318 contact person and reference. 10320 This specification registers the following values: 10322 RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in 10323 combination with the "RTP profile for audio and video 10324 conferences with minimal control" [RFC3551] over UDP. The 10325 usage is explained in RFC XXXX, Appendix C.1. 10327 RTP/AVP/UDP: the same as RTP/AVP. 10329 RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in 10330 combination with the "Extended RTP Profile for RTCP-based 10331 Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is 10332 explained in RFC XXXX, Appendix C.1. 10334 RTP/AVPF/UDP: the same as RTP/AVPF. 10336 RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in 10337 combination with the "The Secure Real-time Transport Protocol 10338 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 10339 XXXX, Appendix C.1. 10341 RTP/SAVP/UDP: the same as RTP/SAVP. 10343 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 10344 combination with the Extended Secure RTP Profile for Real-time 10345 Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 10346 [RFC5124] over UDP. The usage is explained in RFC XXXX, 10347 Appendix C.1. 10349 RTP/SAVPF/UDP: the same as RTP/SAVPF. 10351 RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10352 in combination with the "RTP profile for audio and video 10353 conferences with minimal control" [RFC3551] over TCP. The 10354 usage is explained in RFC XXXX, Appendix C.2.2. 10356 RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10357 in combination with the "Extended RTP Profile for RTCP-based 10358 Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is 10359 explained in RFC XXXX, Appendix C.2.2. 10361 RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10362 in combination with the "The Secure Real-time Transport 10363 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 10364 RFC XXXX, Appendix C.2.2. 10366 RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10367 in combination with the "Extended Secure RTP Profile for Real- 10368 time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 10369 SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 10370 XXXX, Appendix C.2.2. 10372 22.13.2. Transport modes 10374 The Transport Mode is a Transport header (Section 18.54) parameter, 10375 it is used to identify the general mode of media transport. The PLAY 10376 value registered defines a PLAYBACK mode, where media flows from 10377 Server to Client. 10379 A registry for the transport parameter mode MUST be defined with the 10380 following rules: 10382 o Registering requires an IETF Standards Action. 10384 o A contact person or organization with address and email. 10386 o A value definition that are following the ABNF "token" definition 10387 Section 20.2.3. 10389 o A describing text that explains how the registered value are used 10390 in RTSP. 10392 This specification registers 1 value: 10394 PLAY: See RFC XXXX. 10396 The registry should be represented as: The Transport Mode value, 10397 contact person and reference. 10399 22.13.3. Transport Parameters 10401 Transport Parameters are different parameters used in a Transport 10402 Header's transport specification (Section 18.54) to provide 10403 additional information required beyond the transport protocol 10404 identifier to establish a functioning transport. 10406 A registry for parameters that may be included in the Transport 10407 header MUST be defined with the following rules: 10409 o Registering uses the Specification Required policy. 10411 o A Transport Parameter Name following the "token" ABNF definition. 10413 o A value definition, if the parameter takes a value, that are 10414 following the ABNF definition "trn-par-value" Section 20.2.3. 10416 o A describing text that explains how the registered value are used 10417 in RTSP. 10419 This specification registers all the transport parameters defined in 10420 Section 18.54. This is a copy of this list: 10422 o unicast 10424 o multicast 10426 o interleaved 10428 o ttl 10430 o layers 10432 o ssrc 10434 o mode 10436 o dest_addr 10438 o src_addr 10440 o setup 10442 o connection 10444 o RTCP-mux 10446 o MIKEY 10448 The registry should be represented as: The transport parameter name, 10449 contact person and reference. 10451 22.14. URI Schemes 10453 This specification updates two URI schemes, one previously registered 10454 "rtsp", and one missing in the registry "rtspu", previously only 10455 defined in the RTSP 1.0 [RFC2326], one new URI scheme "rtsps" is also 10456 registered. These URI schemes are registered in an existing registry 10457 (Uniform Resource Identifier (URI) Schemes) which are not created by 10458 this memo. Registrations are following RFC 4395[RFC4395]. 10460 22.14.1. The rtsp URI Scheme 10462 URI scheme name: rtsp 10464 Status: Permanent 10465 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10467 URI scheme semantics: The rtsp scheme is used to indicate resources 10468 accessible through the usage of the Real-time Streaming 10469 Protocol (RTSP). RTSP allows different operations on the 10470 resource identified by the URI, but the primary purpose is the 10471 streaming delivery of the resource to a client. However, the 10472 operations that are currently defined are: DESCRIBE, 10473 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10474 SETUP, SET_PARAMETER, and TEARDOWN. 10476 Encoding considerations: IRIs in this scheme are defined and needs 10477 to be encoded as RTSP URIs when used within the RTSP protocol. 10478 That encoding is done according to RFC 3987. 10480 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10481 2326), RTSP 2.0 (RFC XXXX) 10483 Interoperability considerations: The extensions in the URI syntax 10484 performed between RTSP 1.0 and 2.0 can create interoperability 10485 issues. The changes are: 10487 Support for IPV6 literal in host part and future IP 10488 literals through RFC 3986 defined mechanism. 10490 A new relative format to use in the RTSP protocol 10491 elements that is not required to start with "/". 10493 The above changes should have no impact on interoperability as 10494 in detail discussed in Section 4.2 of RFCXXXX. 10496 Security considerations: All the security threats identified in 10497 Section 7 of RFC 3986 apply also to this scheme. They need to 10498 be reviewed and considered in any implementation utilizing this 10499 scheme. 10501 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10503 Author/Change controller: IETF 10505 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10507 22.14.2. The rtsps URI Scheme 10508 URI scheme name: rtsps 10510 Status: Permanent 10512 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10514 URI scheme semantics: The rtsps scheme is used to indicate resources 10515 accessible through the usage of the Real-time Streaming 10516 Protocol (RTSP) over TLS. RTSP allows different operations on 10517 the resource identified by the URI, but the primary purpose is 10518 the streaming delivery of the resource to a client. However, 10519 the operations that are currently defined are: DESCRIBE, 10520 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10521 SETUP, SET_PARAMETER, and TEARDOWN. 10523 Encoding considerations: IRIs in this scheme are defined and needs 10524 to be encoded as RTSP URIs when used within the RTSP protocol. 10525 That encoding is done according to RFC 3987. 10527 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10528 2326), RTSP 2.0 (RFC XXXX) 10530 Interoperability considerations: The "rtsps" scheme was never 10531 officially defined for RTSP 1.0, however it has seen widespread 10532 use in actual deployments of RTSP 1.0. Therefore this section 10533 discusses the believed changes between the unspecified RTSP 1.0 10534 "rtsps" scheme and RTSP 2.0 definition. The extensions in the 10535 URI syntax performed between RTSP 1.0 and 2.0 can create 10536 interoperability issues. The changes are: 10538 Support for IPV6 literal in host part and future IP 10539 literals through RFC 3986 defined mechanism. 10541 A new relative format to use in the RTSP protocol 10542 elements that is not required to start with "/". 10544 The above changes should have no impact on interoperability as 10545 in detail discussed in Section 4.2 of RFCXXXX. 10547 Security considerations: All the security threats identified in 10548 Section 7 of RFC 3986 apply also to this scheme. They need to 10549 be reviewed and considered in any implementation utilizing this 10550 scheme. 10552 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10553 Author/Change controller: IETF 10555 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10557 22.14.3. The rtspu URI Scheme 10559 URI scheme name: rtspu 10561 Status: Permanent 10563 URI scheme syntax: See Section 3.2 of RFC 2326. 10565 URI scheme semantics: The rtspu scheme is used to indicate resources 10566 accessible through the usage of the Real-time Streaming 10567 Protocol (RTSP) over unreliable datagram transport. RTSP 10568 allows different operations on the resource identified by the 10569 URI, but the primary purpose is the streaming delivery of the 10570 resource to a client. However, the operations that are 10571 currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, 10572 REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and 10573 TEARDOWN. 10575 Encoding considerations: This scheme is not intended to be used with 10576 characters outside the US-ASCII repertoire. 10578 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10579 2326) 10581 Interoperability considerations: The definition of the transport 10582 mechanism of RTSP over UDP has interoperability issues. That 10583 makes the usage of this scheme problematic. 10585 Security considerations: All the security threats identified in 10586 Section 7 of RFC 3986 apply also to this scheme. They needs to 10587 be reviewed and considered in any implementation utilizing this 10588 scheme. 10590 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10592 Author/Change controller: IETF 10594 References: RFC 2326 10596 22.15. SDP attributes 10598 This specification defines three SDP [RFC4566] attributes that it is 10599 requested that IANA register. 10601 SDP Attribute ("att-field"): 10603 Attribute name: range 10604 Long form: Media Range Attribute 10605 Type of name: att-field 10606 Type of attribute: Media and session level 10607 Subject to charset: No 10608 Purpose: RFC XXXX 10609 Reference: RFC XXXX, RFC 2326 10610 Values: See ABNF definition. 10612 Attribute name: control 10613 Long form: RTSP control URI 10614 Type of name: att-field 10615 Type of attribute: Media and session level 10616 Subject to charset: No 10617 Purpose: RFC XXXX 10618 Reference: RFC XXXX, RFC 2326 10619 Values: Absolute or Relative URIs. 10621 Attribute name: mtag 10622 Long form: Message Tag 10623 Type of name: att-field 10624 Type of attribute: Media and session level 10625 Subject to charset: No 10626 Purpose: RFC XXXX 10627 Reference: RFC XXXX 10628 Values: See ABNF definition 10630 22.16. Media Type Registration for text/parameters 10632 Type name: text 10634 Subtype name: parameters 10636 Required parameters: 10638 Optional parameters: charset: The charset parameter is applicable to 10639 the encoding of the parameter values. The default charset is 10640 UTF-8, if the 'charset' parameter is not present. 10642 Encoding considerations: 8bit 10644 Security considerations: This format may carry any type of 10645 parameters. Some can have security requirements, like privacy, 10646 confidentiality or integrity requirements. The format has no 10647 built in security protection. For the usage it was defined the 10648 transport can be protected between server and client using TLS. 10649 However, care must be taken to consider if also the proxies are 10650 trusted with the parameters in case hop-by-hop security is used. 10651 If stored as a file in file system, the necessary precautions need 10652 to be taken in relation to the parameters requirements including 10653 object security such as S/MIME [RFC5751]. 10655 Interoperability considerations: This media type was mentioned as a 10656 fictional example in [RFC2326], but was not formally specified. 10657 This has resulted in usage of this media type which may not match 10658 its formal definition. 10660 Published specification: RFC XXXX, Appendix F. 10662 Applications that use this media type: Applications that use RTSP 10663 and have additional parameters they like to read and set using the 10664 RTSP GET_PARAMETER and SET_PARAMETER methods. 10666 Additional information: 10668 Magic number(s): 10670 File extension(s): 10672 Macintosh file type code(s): 10674 Person & email address to contact for further information: Magnus 10675 Westerlund (magnus.westerlund@ericsson.com) 10677 Intended usage: Common 10679 Restrictions on usage: None 10681 Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 10683 Change controller: IETF 10685 Addition Notes: 10687 23. References 10689 23.1. Normative References 10691 [FIPS-pub-180-2] 10692 National Institute of Standards and Technology (NIST), 10693 "Federal Information Processing Standards Publications 10694 (FIPS PUBS) 180-2: Secure Hash Standard", August 2002. 10696 [I-D.ietf-avtcore-rtp-circuit-breakers] 10697 Perkins, C. and V. Singh, "Multimedia Congestion Control: 10698 Circuit Breakers for Unicast RTP Sessions", 10699 draft-ietf-avtcore-rtp-circuit-breakers-03 (work in 10700 progress), July 2013. 10702 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 10703 August 1980. 10705 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 10706 RFC 793, September 1981. 10708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10709 Requirement Levels", BCP 14, RFC 2119, March 1997. 10711 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 10712 (IPv6) Specification", RFC 2460, December 1998. 10714 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 10715 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 10716 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 10718 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 10719 Leach, P., Luotonen, A., and L. Stewart, "HTTP 10720 Authentication: Basic and Digest Access Authentication", 10721 RFC 2617, June 1999. 10723 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 10725 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 10726 Jacobson, "RTP: A Transport Protocol for Real-Time 10727 Applications", STD 64, RFC 3550, July 2003. 10729 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 10730 Video Conferences with Minimal Control", STD 65, RFC 3551, 10731 July 2003. 10733 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10734 10646", STD 63, RFC 3629, November 2003. 10736 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 10737 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 10738 RFC 3711, March 2004. 10740 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 10741 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 10742 August 2004. 10744 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 10745 Resource Identifier (URI): Generic Syntax", STD 66, 10746 RFC 3986, January 2005. 10748 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 10749 Identifiers (IRIs)", RFC 3987, January 2005. 10751 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 10752 Requirements for Security", BCP 106, RFC 4086, June 2005. 10754 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10755 Architecture", RFC 4291, February 2006. 10757 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 10758 Registration Procedures for New URI Schemes", BCP 35, 10759 RFC 4395, February 2006. 10761 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 10762 Description Protocol", RFC 4566, July 2006. 10764 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 10765 and RTP Control Protocol (RTCP) Packets over Connection- 10766 Oriented Transport", RFC 4571, July 2006. 10768 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 10769 "Extended RTP Profile for Real-time Transport Control 10770 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 10771 July 2006. 10773 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 10774 Encodings", RFC 4648, October 2006. 10776 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 10777 RSA-R: An Additional Mode of Key Distribution in 10778 Multimedia Internet KEYing (MIKEY)", RFC 4738, 10779 November 2006. 10781 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 10782 Real-time Transport Control Protocol (RTCP)-Based Feedback 10783 (RTP/SAVPF)", RFC 5124, February 2008. 10785 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 10786 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 10787 May 2008. 10789 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 10790 Specifications: ABNF", STD 68, RFC 5234, January 2008. 10792 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 10793 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 10795 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 10796 Housley, R., and W. Polk, "Internet X.509 Public Key 10797 Infrastructure Certificate and Certificate Revocation List 10798 (CRL) Profile", RFC 5280, May 2008. 10800 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 10801 Languages", BCP 47, RFC 5646, September 2009. 10803 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 10804 Mail Extensions (S/MIME) Version 3.2 Message 10805 Specification", RFC 5751, January 2010. 10807 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 10808 Control Packets on a Single Port", RFC 5761, April 2010. 10810 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 10811 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 10813 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 10814 Specifications and Registration Procedures", BCP 13, 10815 RFC 6838, January 2013. 10817 [SMPTE_TC] 10818 Society of Motion Picture and Television Engineers, "SMPTE 10819 Standard for Television -- Time and Control Code, ST 12M- 10820 1-2008". 10822 [TS-26234] 10823 Third Generation Partnership Project (3GPP), "Transparent 10824 end-to-end Packet-switched Streaming Service (PSS); 10825 Protocols and codecs; Technical Specification 26.234", 10826 December 2002. 10828 23.2. Informative References 10830 [I-D.ietf-mmusic-rtsp-nat] 10831 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 10832 Address Translator (NAT) Traversal mechanism for media 10833 controlled by Real-Time Streaming Protocol (RTSP)", 10834 draft-ietf-mmusic-rtsp-nat-16 (work in progress), 10835 May 2013. 10837 [ISO.13818-6.1995] 10838 International Organization for Standardization, 10839 "Information technology - Generic coding of moving 10840 pictures and associated audio information - part 6: 10841 Extension for digital storage media and control", 10842 ISO Draft Standard 13818-6, November 1995. 10844 [ISO.8601.2000] 10845 International Organization for Standardization, "Data 10846 elements and interchange formats - Information interchange 10847 - Representation of dates and times", ISO/IEC Standard 10848 8601, December 2000. 10850 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 10851 and Support", STD 3, RFC 1123, October 1989. 10853 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 10854 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 10855 RFC 2068, January 1997. 10857 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 10858 Streaming Protocol (RTSP)", RFC 2326, April 1998. 10860 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 10861 Translator (NAT) Terminology and Considerations", 10862 RFC 2663, August 1999. 10864 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 10865 April 2001. 10867 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 10868 Announcement Protocol", RFC 2974, October 2000. 10870 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 10871 A., Peterson, J., Sparks, R., Handley, M., and E. 10872 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 10873 June 2002. 10875 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 10876 with Session Description Protocol (SDP)", RFC 3264, 10877 June 2002. 10879 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 10880 the Session Description Protocol (SDP)", RFC 4145, 10881 September 2005. 10883 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 10884 Carrara, "Key Management Extensions for Session 10885 Description Protocol (SDP) and Real Time Streaming 10886 Protocol (RTSP)", RFC 4567, July 2006. 10888 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 10889 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 10890 July 2006. 10892 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 10893 Formats", RFC 4855, February 2007. 10895 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 10896 the RTP Profile for Audio and Video Conferences", 10897 RFC 4856, February 2007. 10899 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 10900 "Codec Control Messages in the RTP Audio-Visual Profile 10901 with Feedback (AVPF)", RFC 5104, February 2008. 10903 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 10904 (ICE): A Protocol for Network Address Translator (NAT) 10905 Traversal for Offer/Answer Protocols", RFC 5245, 10906 April 2010. 10908 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 10909 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 10910 October 2008. 10912 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 10913 Dependency in the Session Description Protocol (SDP)", 10914 RFC 5583, July 2009. 10916 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 10917 Time Protocol Version 4: Protocol and Algorithms 10918 Specification", RFC 5905, June 2010. 10920 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 10921 "Computing TCP's Retransmission Timer", RFC 6298, 10922 June 2011. 10924 [Stevens98] 10925 Stevens, W., "Unix Networking Programming - Volume 1, 10926 second edition", 1998. 10928 Appendix A. Examples 10930 This section contains several different examples trying to illustrate 10931 possible ways of using RTSP. The examples can also help with the 10932 understanding of how functions of RTSP work. However, remember that 10933 these are examples and the normative and syntax description in the 10934 other sections take precedence. Please also note that many of the 10935 examples contain syntax illegal line breaks to accommodate the 10936 formatting restriction that the RFC series impose. 10938 A.1. Media on Demand (Unicast) 10940 This is an example of media on demand streaming of a media stored in 10941 a container file. For purposes of this example, a container file is 10942 a storage entity in which multiple continuous media types pertaining 10943 to the same end-user presentation are present. In effect, the 10944 container file represents an RTSP presentation, with each of its 10945 components being RTSP controlled media streams. Container files are 10946 a widely used means to store such presentations. While the 10947 components are transported as independent streams, it is desirable to 10948 maintain a common context for those streams at the server end. 10950 This enables the server to keep a single storage handle open 10951 easily. It also allows treating all the streams equally in case 10952 of any prioritization of streams by the server. 10954 It is also possible that the presentation author may wish to prevent 10955 selective retrieval of the streams by the client in order to preserve 10956 the artistic effect of the combined media presentation. Similarly, 10957 in such a tightly bound presentation, it is desirable to be able to 10958 control all the streams via a single control message using an 10959 aggregate URI. 10961 The following is an example of using a single RTSP session to control 10962 multiple streams. It also illustrates the use of aggregate URIs. In 10963 a container file it is also desirable to not write any URI parts 10964 which are not kept, when the container is distributed, like the host 10965 and most of the path element. Therefore this example also uses the 10966 "*" and relative URI in the delivered SDP. 10968 Also this presentation description (SDP) is not cacheble, as the 10969 Expires header is set to an equal value with date indicating 10970 immediate expiration of its validity. 10972 Client C requests a presentation from media server M. The movie is 10973 stored in a container file. The client has obtained an RTSP URI to 10974 the container file. 10976 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 10977 CSeq: 1 10978 User-Agent: PhonyClient/1.2 10980 M->C: RTSP/2.0 200 OK 10981 CSeq: 1 10982 Server: PhonyServer/1.0 10983 Date: Thu, 24 Jan 1997 15:35:06 GMT 10984 Content-Type: application/sdp 10985 Content-Length: 271 10986 Content-Base: rtsp://example.com/twister.3gp/ 10987 Expires: 24 Jan 1997 15:35:06 GMT 10989 v=0 10990 o=- 2890844256 2890842807 IN IP4 198.51.100.5 10991 s=RTSP Session 10992 i=An Example of RTSP Session Usage 10993 e=adm@example.com 10994 c=IN IP4 0.0.0.0 10995 a=control: * 10996 a=range:npt=0-0:10:34.10 10997 t=0 0 10998 m=audio 0 RTP/AVP 0 10999 a=control: trackID=1 11000 m=video 0 RTP/AVP 26 11001 a=control: trackID=4 11003 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11004 CSeq: 2 11005 User-Agent: PhonyClient/1.2 11006 Require: play.basic 11007 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11008 Accept-Ranges: npt, smpte, clock 11010 M->C: RTSP/2.0 200 OK 11011 CSeq: 2 11012 Server: PhonyServer/1.0 11013 Transport: RTP/AVP;unicast; ssrc=93CB001E; 11014 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11015 src_addr="198.51.100.5:9000"/"198.51.100.5:9001" 11016 Session: 12345678 11017 Expires: 24 Jan 1997 15:35:12 GMT 11018 Date: 24 Jan 1997 15:35:12 GMT 11019 Accept-Ranges: npt 11020 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11022 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11023 CSeq: 3 11024 User-Agent: PhonyClient/1.2 11025 Require: play.basic 11026 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11027 Session: 12345678 11028 Accept-Ranges: npt, smpte, clock 11030 M->C: RTSP/2.0 200 OK 11031 CSeq: 3 11032 Server: PhonyServer/1.0 11033 Transport: RTP/AVP;unicast; ssrc=A813FC13; 11034 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 11035 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11037 Session: 12345678 11038 Expires: 24 Jan 1997 15:35:13 GMT 11039 Date: 24 Jan 1997 15:35:13 GMT 11040 Accept-Range: NPT 11041 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11043 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11044 CSeq: 4 11045 User-Agent: PhonyClient/1.2 11046 Range: npt=30- 11047 Seek-Style: RAP 11048 Session: 12345678 11050 M->C: RTSP/2.0 200 OK 11051 CSeq: 4 11052 Server: PhonyServer/1.0 11053 Date: 24 Jan 1997 15:35:14 GMT 11054 Session: 12345678 11055 Range: npt=30-634.10 11056 Seek-Style: RAP 11057 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11058 ssrc=0D12F123:seq=12345;rtptime=3450012, 11059 url="rtsp://example.com/twister.3gp/trackID=1" 11060 ssrc=4F312DD8:seq=54321;rtptime=2876889 11062 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 11063 CSeq: 5 11064 User-Agent: PhonyClient/1.2 11065 Session: 12345678 11067 # Pause happens 0.87 seconds after starting to play 11069 M->C: RTSP/2.0 200 OK 11070 CSeq: 5 11071 Server: PhonyServer/1.0 11072 Date: 24 Jan 1997 15:36:01 GMT 11073 Session: 12345678 11074 Range: npt=30.87-634.10 11076 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11077 CSeq: 6 11078 User-Agent: PhonyClient/1.2 11079 Range: npt=30.87-634.10 11080 Seek-Style: Next 11081 Session: 12345678 11083 M->C: RTSP/2.0 200 OK 11084 CSeq: 6 11085 Server: PhonyServer/1.0 11086 Date: 24 Jan 1997 15:36:01 GMT 11087 Session: 12345678 11088 Range: npt=30.87-634.10 11089 Seek-Style: Next 11090 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11091 ssrc=0D12F123:seq=12555;rtptime=6330012, 11092 url="rtsp://example.com/twister.3gp/trackID=1" 11093 ssrc=4F312DD8:seq=55021;rtptime=3132889 11095 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 11096 CSeq: 7 11097 User-Agent: PhonyClient/1.2 11098 Session: 12345678 11100 M->C: RTSP/2.0 200 OK 11101 CSeq: 7 11102 Server: PhonyServer/1.0 11103 Date: 24 Jan 1997 15:49:34 GMT 11105 A.2. Media on Demand using Pipelining 11107 This example is basically the example above (Appendix A.1), but now 11108 utilizing pipelining to speed up the setup. It requires only two 11109 round trip times until the media starts flowing. First of all, the 11110 session description is retrieved to determine what media resources 11111 need to be setup. In the second step, one sends the necessary SETUP 11112 requests and the PLAY request to initiate media delivery. 11114 Client C requests a presentation from media server M. The movie is 11115 stored in a container file. The client has obtained an RTSP URI to 11116 the container file. 11118 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11119 CSeq: 1 11120 User-Agent: PhonyClient/1.2 11122 M->C: RTSP/2.0 200 OK 11123 CSeq: 1 11124 Server: PhonyServer/1.0 11125 Date: Thu, 23 Jan 1997 15:35:06 GMT 11126 Content-Type: application/sdp 11127 Content-Length: 271 11128 Content-Base: rtsp://example.com/twister.3gp/ 11129 Expires: 24 Jan 1997 15:35:06 GMT 11131 v=0 11132 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11133 s=RTSP Session 11134 i=An Example of RTSP Session Usage 11135 e=adm@example.com 11136 c=IN IP4 0.0.0.0 11137 a=control: * 11138 a=range:npt=0-0:10:34.10 11139 t=0 0 11140 m=audio 0 RTP/AVP 0 11141 a=control: trackID=1 11142 m=video 0 RTP/AVP 26 11143 a=control: trackID=4 11145 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11146 CSeq: 2 11147 User-Agent: PhonyClient/1.2 11148 Require: play.basic 11149 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11150 Accept-Ranges: npt, smpte, clock 11151 Pipelined-Requests: 7654 11153 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11154 CSeq: 3 11155 User-Agent: PhonyClient/1.2 11156 Require: play.basic 11157 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11158 Accept-Ranges: npt, smpte, clock 11159 Pipelined-Requests: 7654 11161 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11162 CSeq: 4 11163 User-Agent: PhonyClient/1.2 11164 Range: npt=0- 11165 Seek-Style: RAP 11166 Pipelined-Requests: 7654 11168 M->C: RTSP/2.0 200 OK 11169 CSeq: 2 11170 Server: PhonyServer/1.0 11171 Transport: RTP/AVP;unicast; 11172 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11173 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11174 ssrc=93CB001E 11175 Session: 12345678 11176 Expires: 24 Jan 1997 15:35:12 GMT 11177 Date: 23 Jan 1997 15:35:12 GMT 11178 Accept-Ranges: npt 11179 Pipelined-Requests: 7654 11180 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11182 M->C: RTSP/2.0 200 OK 11183 CSeq: 3 11184 Server: PhonyServer/1.0 11185 Transport: RTP/AVP;unicast; 11186 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11187 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11188 ssrc=A813FC13 11189 Session: 12345678 11190 Expires: 24 Jan 1997 15:35:13 GMT 11191 Date: 23 Jan 1997 15:35:13 GMT 11192 Accept-Range: NPT 11193 Pipelined-Requests: 7654 11194 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11196 M->C: RTSP/2.0 200 OK 11197 CSeq: 4 11198 Server: PhonyServer/1.0 11199 Date: 23 Jan 1997 15:35:14 GMT 11200 Session: 12345678 11201 Range: npt=0-623.10 11202 Seek-Style: RAP 11203 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11204 ssrc=0D12F123:seq=12345;rtptime=3450012, 11205 url="rtsp://example.com/twister.3gp/trackID=1" 11206 ssrc=4F312DD8:seq=54321;rtptime=2876889 11207 Pipelined-Requests: 7654 11209 A.3. Secured Media Session for on Demand Content 11211 This example is basically the above example (Appendix A.2), but now 11212 including establishment of SRTP crypto contexts to get a secured 11213 media delivery. First of all, the client attempts to fetch this 11214 insecurely, but the server redirects to a URI indicating a 11215 requirement on using a secure connection for the RTSP messages. The 11216 client establish a TCP/TLS connections and the session description is 11217 retrieved to determine what media resources need to be setup. In the 11218 this session description secure media (SRTP) is indicated. In the 11219 next step, the client sends the necessary SETUP requests including 11220 MIKEY messages. This is pipeline with a PLAY request to initiate 11221 media delivery. 11223 Client C requests a presentation from media server M. The movie is 11224 stored in a container file. The client has obtained an RTSP URI to 11225 the container file. 11227 Note: The below MIKEY messages are not valid MIKEY message and are 11228 BASE64 encoded random data to represent where the MIKEY messages 11229 would go. 11230 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11231 CSeq: 1 11232 User-Agent: PhonyClient/1.2 11234 M->C: RTSP/2.0 301 Moved Permanently 11235 CSeq: 1 11236 Server: PhonyServer/1.0 11237 Date: Thu, 23 Jan 1997 15:35:06 GMT 11238 Location: rtsps://example.com/twister.3gp 11240 C->M: Establish TCP/TLS connection and verify server's 11241 certificate that is represents example.com. 11242 Used for all below RTSP messages. 11244 C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0 11245 CSeq: 2 11246 User-Agent: PhonyClient/1.2 11248 M->C: RTSP/2.0 200 OK 11249 CSeq: 2 11250 Server: PhonyServer/1.0 11251 Date: Thu, 23 Jan 1997 15:35:06 GMT 11252 Content-Type: application/sdp 11253 Content-Length: 271 11254 Content-Base: rtsps://example.com/twister.3gp/ 11255 Expires: 24 Jan 1997 15:35:06 GMT 11257 v=0 11258 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11259 s=RTSP Session 11260 i=An Example of RTSP Session Usage 11261 e=adm@example.com 11262 c=IN IP4 0.0.0.0 11263 a=control: * 11264 a=range:npt=0-0:10:34.10 11265 t=0 0 11266 m=audio 0 RTP/SAVP 0 11267 a=control: trackID=1 11268 m=video 0 RTP/SAVP 26 11269 a=control: trackID=4 11271 C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0 11272 CSeq: 3 11273 User-Agent: PhonyClient/1.2 11274 Require: play.basic 11275 Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001"; 11276 MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl 11277 Accept-Ranges: npt, smpte, clock 11278 Pipelined-Requests: 7654 11280 C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0 11281 CSeq: 4 11282 User-Agent: PhonyClient/1.2 11283 Require: play.basic 11284 Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003"; 11285 MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ= 11286 Accept-Ranges: npt, smpte, clock 11287 Pipelined-Requests: 7654 11289 C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0 11290 CSeq: 5 11291 User-Agent: PhonyClient/1.2 11292 Range: npt=0- 11293 Seek-Style: RAP 11294 Pipelined-Requests: 7654 11296 M->C: RTSP/2.0 200 OK 11297 CSeq: 3 11298 Server: PhonyServer/1.0 11299 Transport: RTP/SAVP;unicast; 11300 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11301 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11302 ssrc=93CB001E; 11303 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x 11304 Session: 12345678 11305 Expires: 24 Jan 1997 15:35:12 GMT 11306 Date: 23 Jan 1997 15:35:12 GMT 11307 Accept-Ranges: npt 11308 Pipelined-Requests: 7654 11309 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11311 M->C: RTSP/2.0 200 OK 11312 CSeq: 4 11313 Server: PhonyServer/1.0 11314 Transport: RTP/SAVP;unicast; 11315 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11316 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11317 ssrc=A813FC13; 11318 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 11319 Session: 12345678 11320 Expires: 24 Jan 1997 15:35:13 GMT 11321 Date: 23 Jan 1997 15:35:13 GMT 11322 Accept-Range: NPT 11323 Pipelined-Requests: 7654 11324 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11326 M->C: RTSP/2.0 200 OK 11327 CSeq: 5 11328 Server: PhonyServer/1.0 11329 Date: 23 Jan 1997 15:35:14 GMT 11330 Session: 12345678 11331 Range: npt=0-623.10 11332 Seek-Style: RAP 11333 RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" 11334 ssrc=0D12F123:seq=12345;rtptime=3450012, 11335 url="rtsps://example.com/twister.3gp/trackID=1" 11336 ssrc=4F312DD8:seq=54321;rtptime=2876889; 11338 Pipelined-Requests: 7654 11340 A.4. Media on Demand (Unicast) 11342 An alternative example of media on demand with a bit more tweaks is 11343 the following. Client C requests a movie distributed from two 11344 different media servers A (audio.example.com) and V ( 11345 video.example.com). The media description is stored on a web server 11346 W. The media description contains descriptions of the presentation 11347 and all its streams, including the codecs that are available, dynamic 11348 RTP payload types, the protocol stack, and content information such 11349 as language or copyright restrictions. It may also give an 11350 indication about the timeline of the movie. 11352 In this example, the client is only interested in the last part of 11353 the movie. 11355 C->W: GET /twister.sdp HTTP/1.1 11356 Host: www.example.com 11357 Accept: application/sdp 11359 W->C: HTTP/1.1 200 OK 11360 Date: Thu, 23 Jan 1997 15:35:06 GMT 11361 Content-Type: application/sdp 11362 Content-Length: 278 11363 Expires: 23 Jan 1998 15:35:06 GMT 11365 v=0 11366 o=- 2890844526 2890842807 IN IP4 198.51.100.5 11367 s=RTSP Session 11368 e=adm@example.com 11369 c=IN IP4 0.0.0.0 11370 a=range:npt=0-1:49:34 11371 t=0 0 11372 m=audio 0 RTP/AVP 0 11373 a=control:rtsp://audio.example.com/twister/audio.en 11374 m=video 0 RTP/AVP 31 11375 a=control:rtsp://video.example.com/twister/video 11377 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 11378 CSeq: 1 11379 User-Agent: PhonyClient/1.2 11380 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 11381 RTP/AVP/TCP;unicast;interleaved=0-1 11382 Accept-Ranges: npt, smpte, clock 11384 A->C: RTSP/2.0 200 OK 11385 CSeq: 1 11386 Session: 12345678 11387 Transport: RTP/AVP/UDP;unicast; 11388 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11389 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11390 Date: 23 Jan 1997 15:35:12 GMT 11391 Server: PhonyServer/1.0 11392 Expires: 24 Jan 1997 15:35:12 GMT 11393 Cache-Control: public 11394 Accept-Ranges: npt, smpte 11395 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11397 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 11398 CSeq: 1 11399 User-Agent: PhonyClient/1.2 11400 Transport: RTP/AVP/UDP;unicast; 11401 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", 11402 RTP/AVP/TCP;unicast;interleaved=0-1 11403 Accept-Ranges: npt, smpte, clock 11405 V->C: RTSP/2.0 200 OK 11406 CSeq: 1 11407 Session: 23456789 11408 Transport: RTP/AVP/UDP;unicast; 11409 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; 11410 src_addr="198.51.100.5:5002"/"198.51.100.5:5003" 11411 Date: 23 Jan 1997 15:35:12 GMT 11412 Server: PhonyServer/1.0 11413 Cache-Control: public 11414 Expires: 24 Jan 1997 15:35:12 GMT 11415 Accept-Ranges: npt, smpte 11416 Media-Properties: Random-Access=1.2, Immutable, Unlimited 11418 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 11419 CSeq: 2 11420 User-Agent: PhonyClient/1.2 11421 Session: 23456789 11422 Range: smpte=0:10:00- 11424 V->C: RTSP/2.0 200 OK 11425 CSeq: 2 11426 Session: 23456789 11427 Range: smpte=0:10:00-1:49:23 11428 Seek-Style: First-Prior 11429 RTP-Info: url="rtsp://video.example.com/twister/video" 11430 ssrc=A17E189D:seq=12312232;rtptime=78712811 11431 Server: PhonyServer/2.0 11432 Date: 23 Jan 1997 15:35:13 GMT 11434 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 11435 CSeq: 2 11436 User-Agent: PhonyClient/1.2 11437 Session: 12345678 11438 Range: smpte=0:10:00- 11440 A->C: RTSP/2.0 200 OK 11441 CSeq: 2 11442 Session: 12345678 11443 Range: smpte=0:10:00-1:49:23 11444 Seek-Style: First-Prior 11445 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 11446 ssrc=3D124F01:seq=876655;rtptime=1032181 11447 Server: PhonyServer/1.0 11448 Date: 23 Jan 1997 15:35:13 GMT 11450 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 11451 CSeq: 3 11452 User-Agent: PhonyClient/1.2 11453 Session: 12345678 11455 A->C: RTSP/2.0 200 OK 11456 CSeq: 3 11457 Server: PhonyServer/1.0 11458 Date: 23 Jan 1997 15:36:52 GMT 11460 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 11461 CSeq: 3 11462 User-Agent: PhonyClient/1.2 11463 Session: 23456789 11465 V->C: RTSP/2.0 200 OK 11466 CSeq: 3 11467 Server: PhonyServer/2.0 11468 Date: 23 Jan 1997 15:36:52 GMT 11470 Even though the audio and video track are on two different servers 11471 that may start at slightly different times and may drift with respect 11472 to each other over time, the client can perform initial 11473 synchronization of the two media using RTP-Info and Range received in 11474 the PLAY responses. If the two servers are time synchronized the 11475 RTCP packets can also be used to maintain synchronization. 11477 A.5. Single Stream Container Files 11479 Some RTSP servers may treat all files as though they are "container 11480 files", yet other servers may not support such a concept. Because of 11481 this, clients needs to use the rules set forth in the session 11482 description for Request-URIs, rather than assuming that a consistent 11483 URI may always be used throughout. Below is an example of how a 11484 multi-stream server might expect a single-stream file to be served: 11486 C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 11487 Accept: application/x-rtsp-mh, application/sdp 11488 CSeq: 1 11489 User-Agent: PhonyClient/1.2 11491 S->C: RTSP/2.0 200 OK 11492 CSeq: 1 11493 Content-base: rtsp://foo.example.com/test.wav/ 11494 Content-type: application/sdp 11495 Content-length: 163 11496 Server: PhonyServer/1.0 11497 Date: Thu, 23 Jan 1997 15:35:06 GMT 11498 Expires: 23 Jan 1997 17:00:00 GMT 11500 v=0 11501 o=- 872653257 872653257 IN IP4 192.0.2.5 11502 s=mu-law wave file 11503 i=audio test 11504 c=IN IP4 0.0.0.0 11505 t=0 0 11506 a=control: * 11507 m=audio 0 RTP/AVP 0 11508 a=control:streamid=0 11510 C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 11511 Transport: RTP/AVP/UDP;unicast; 11512 dest_addr=":6970"/":6971";mode="PLAY" 11513 CSeq: 2 11514 User-Agent: PhonyClient/1.2 11515 Accept-Ranges: npt, smpte, clock 11517 S->C: RTSP/2.0 200 OK 11518 Transport: RTP/AVP/UDP;unicast; 11519 dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; 11520 src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; 11521 mode="PLAY";ssrc=EAB98712 11522 CSeq: 2 11523 Session: 2034820394 11524 Expires: 23 Jan 1997 16:00:00 GMT 11525 Server: PhonyServer/1.0 11526 Date: 23 Jan 1997 15:35:07 GMT 11527 Accept-Ranges: npt 11528 Media-Properties: Random-Acces=0.5, Immutable, Unlimited 11530 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 11531 CSeq: 3 11532 User-Agent: PhonyClient/1.2 11533 Session: 2034820394 11535 S->C: RTSP/2.0 200 OK 11536 CSeq: 3 11537 Server: PhonyServer/1.0 11538 Date: 23 Jan 1997 15:35:08 GMT 11539 Session: 2034820394 11540 Range: npt=0-600 11541 Seek-Style: RAP 11542 RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" 11543 ssrc=0D12F123:seq=981888;rtptime=3781123 11545 Note the different URI in the SETUP command, and then the switch back 11546 to the aggregate URI in the PLAY command. This makes complete sense 11547 when there are multiple streams with aggregate control, but is less 11548 than intuitive in the special case where the number of streams is 11549 one. However, the server has declared the aggregated control URI in 11550 the SDP and therefore this is legal. 11552 In this case, it is also required that servers accept implementations 11553 that use the non-aggregated interpretation and use the individual 11554 media URI, like this: 11556 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 11557 CSeq: 3 11558 User-Agent: PhonyClient/1.2 11559 Session: 2034820394 11561 A.6. Live Media Presentation Using Multicast 11563 The media server M chooses the multicast address and port. Here, it 11564 is assumed that the web server only contains a pointer to the full 11565 description, while the media server M maintains the full description. 11567 C->W: GET /sessions.html HTTP/1.1 11568 Host: www.example.com 11570 W->C: HTTP/1.1 200 OK 11571 Content-Type: text/html 11573 11574 ... 11575 11576 Streamed Live Music performance 11577 ... 11578 11580 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 11581 CSeq: 1 11582 Supported: play.basic, play.scale 11583 User-Agent: PhonyClient/1.2 11585 M->C: RTSP/2.0 200 OK 11586 CSeq: 1 11587 Content-Type: application/sdp 11588 Content-Length: 183 11589 Server: PhonyServer/1.0 11590 Date: Thu, 23 Jan 1997 15:35:06 GMT 11591 Supported: play.basic 11593 v=0 11594 o=- 2890844526 2890842807 IN IP4 192.0.2.5 11595 s=RTSP Session 11596 t=0 0 11597 m=audio 3456 RTP/AVP 0 11598 c=IN IP4 233.252.0.54/16 11599 a=control: rtsp://live.example.com/concert/audio 11600 a=range:npt=0- 11602 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 11603 CSeq: 2 11604 Transport: RTP/AVP;multicast; 11605 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11606 Accept-Ranges: npt, smpte, clock 11607 User-Agent: PhonyClient/1.2 11609 M->C: RTSP/2.0 200 OK 11610 CSeq: 2 11611 Server: PhonyServer/1.0 11612 Date: Thu, 23 Jan 1997 15:35:06 GMT 11613 Transport: RTP/AVP;multicast; 11614 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11615 ;ssrc=4D12AB92/0DF876A3 11616 Session: 0456804596 11617 Accept-Ranges: npt, clock 11618 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 11620 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 11621 CSeq: 3 11622 Session: 0456804596 11623 User-Agent: PhonyClient/1.2 11625 M->C: RTSP/2.0 200 OK 11626 CSeq: 3 11627 Server: PhonyServer/1.0 11628 Date: 23 Jan 1997 15:35:07 GMT 11629 Session: 0456804596 11630 Seek-Style: Next 11631 Range:npt=1256- 11632 RTP-Info: url="rtsp://live.example.com/concert/audio" 11633 ssrc=0D12F123:seq=1473; rtptime=80000 11635 A.7. Capability Negotiation 11637 This example illustrates how the client and server determine their 11638 capability to support a special feature, in this case "play.scale". 11639 The server, through the clients request and the included Supported 11640 header, learns the client supports RTSP 2.0, and also supports the 11641 playback time scaling feature of RTSP. The server's response 11642 contains the following feature related information to the client; it 11643 supports the basic media delivery functions (play.basic), the 11644 extended functionality of time scaling of content (play.scale), and 11645 one "example.com" proprietary feature (com.example.flight). The 11646 client also learns the methods supported (Public header) by the 11647 server for the indicated resource. 11649 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 11650 CSeq: 1 11651 Supported: play.basic, play.scale 11652 User-Agent: PhonyClient/1.2 11654 S->C: RTSP/2.0 200 OK 11655 CSeq: 1 11656 Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER 11657 Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE 11658 Server: PhonyServer/2.0 11659 Supported: play.basic, play.scale, com.example.flight 11661 When the client sends its SETUP request it tells the server that it 11662 requires support of the play.scale feature for this session by 11663 including the Require header. 11665 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 11666 CSeq: 3 11667 User-Agent: PhonyClient/1.2 11668 Transport: RTP/AVP/UDP;unicast; 11669 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", 11670 RTP/AVP/TCP;unicast;interleaved=0-1 11671 Require: play.scale 11672 Accept-Ranges: npt, smpte, clock 11673 User-Agent: PhonyClient/1.2 11675 S->C: RTSP/2.0 200 OK 11676 CSeq: 3 11677 Session: 12345678 11678 Transport: RTP/AVP/UDP;unicast; 11679 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11680 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11681 Server: PhonyServer/2.0 11682 Accept-Ranges: npt, smpte 11683 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11685 Appendix B. RTSP Protocol State Machine 11687 The RTSP session state machine describes the behavior of the protocol 11688 from RTSP session initialization through RTSP session termination. 11689 It is likely easiest to think of this as the server's state and then 11690 the client need to track what it believe the server's state will be 11691 based on sent or received RTSP messages. Thus most cases the below 11692 state tables can be read as: If the client do X, assuming it fulfills 11693 any pre-requisite the state will move to the new state and the 11694 indicated response will come back. However, there are also server to 11695 client notifications or requests, where the action describes what 11696 notification or request that happens, its requisites and what new 11697 state will occur after the server has received the response, and 11698 describing the clients response to the action. 11700 The State machine is defined on a per session basis which is uniquely 11701 identified by the RTSP session identifier. The session may contain 11702 one or more media streams depending on state. If a single media 11703 stream is part of the session it is in non-aggregated control. If 11704 two or more is part of the session it is in aggregated control. 11706 The below state machine is an informative description of the 11707 protocols behavior. In case of ambiguity with the earlier parts of 11708 this specification, the description in the earlier parts take 11709 precedence. 11711 B.1. States 11713 The state machine contains three states, described below. For each 11714 state there exists a table which shows which requests and events are 11715 allowed and whether they will result in a state change. 11717 Init: Initial state no session exists. 11719 Ready: Session is ready to start playing. 11721 Play: Session is playing, i.e., sending media stream data in the 11722 direction S->C. 11724 B.2. State variables 11726 This representation of the state machine needs more than its state to 11727 work. A small number of variables are also needed and they are 11728 explained below. 11730 NRM: The number of media streams part of this session. 11732 RP: Resume point, the point in the presentation time line at which 11733 a request to continue playing will resume from. A time format 11734 for the variable is not mandated. 11736 B.3. Abbreviations 11738 To make the state tables more compact a number of abbreviations are 11739 used, which are explained below. 11741 IFI: IF Implemented. 11743 md: Media 11745 PP: Pause Point, the point in the presentation time line at which 11746 the presentation was paused. 11748 Prs: Presentation, the complete multimedia presentation. 11750 RedP: Redirect Point, the point in the presentation time line at 11751 which a REDIRECT was specified to occur. 11753 SES: Session. 11755 B.4. State Tables 11757 This section contains a table for each state. The table contains all 11758 the requests and events that this state is allowed to act on. The 11759 events which are method names are, unless noted, requests with the 11760 given method in the direction client to server (C->S). In some cases 11761 there exist one or more requisite. The response column tells what 11762 type of response actions should be performed. Possible actions that 11763 are requested for an event include: response codes, e.g., 200, 11764 headers that need to be included in the response, setting of state 11765 variables, or setting of other session related parameters. The new 11766 state column tells which state the state machine changes to. 11768 The response to a valid request meeting the requisites is normally a 11769 2xx (SUCCESS) unless otherwise noted in the response column. The 11770 exceptions need to be given a response according to the response 11771 column. If the request does not meet the requisite, is erroneous or 11772 some other type of error occurs, the appropriate response code is to 11773 be sent. If the response code is a 4xx the session state is 11774 unchanged. A response code of 3rr will result in that the session is 11775 ended and its state is changed to Init. A response code of 304 11776 results in no state change. However, there are restrictions to when 11777 a 3rr response may be used. A 5xx response does not result in any 11778 change of the session state, except if the error is not possible to 11779 recover from. A unrecoverable error results in the ending of the 11780 session. As it in the general case can't be determined if it was a 11781 unrecoverable error or not the client will be required to test. In 11782 the case that the next request after a 5xx is responded with 454 11783 (Session Not Found) the client knows that the session has ended. For 11784 any request message that cannot be responded to within the time 11785 defined in Section 10.4, a 100 response must be sent. 11787 The server will timeout the session after the period of time 11788 specified in the SETUP response, if no activity from the client is 11789 detected. Therefore there exists a timeout event for all states 11790 except Init. 11792 In the case that NRM = 1 the presentation URI is equal to the media 11793 URI or a specified presentation URI. For NRM > 1 the presentation 11794 URI needs to be other than any of the medias that are part of the 11795 session. This applies to all states. 11797 +---------------+-----------------+---------------------------------+ 11798 | Event | Prerequisite | Response | 11799 +---------------+-----------------+---------------------------------+ 11800 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 11801 | | | | 11802 | DESCRIBE | | 200, Session description | 11803 | | | | 11804 | OPTIONS | Session ID | 200, Reset session timeout | 11805 | | | timer | 11806 | | | | 11807 | OPTIONS | | 200 | 11808 | | | | 11809 | SET_PARAMETER | Valid parameter | 200, change value of parameter | 11810 | | | | 11811 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 11812 +---------------+-----------------+---------------------------------+ 11814 Table 13: None state-machine changing events 11816 The methods in Table 13 do not have any effect on the state machine 11817 or the state variables. However, some methods do change other 11818 session related parameters, for example SET_PARAMETER which will set 11819 the parameter(s) specified in its body. Also all of these methods 11820 that allow Session header will also update the keep-alive timer for 11821 the session. 11823 +------------------+----------------+-----------+-------------------+ 11824 | Action | Requisite | New State | Response | 11825 +------------------+----------------+-----------+-------------------+ 11826 | SETUP | | Ready | NRM=1, RP=0.0 | 11827 | | | | | 11828 | SETUP | Needs Redirect | Init | 3rr Redirect | 11829 | | | | | 11830 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 11831 +------------------+----------------+-----------+-------------------+ 11833 Table 14: State: Init 11835 The initial state of the state machine, see Table 14 can only be left 11836 by processing a correct SETUP request. As seen in the table the two 11837 state variables are also set by a correct request. This table also 11838 shows that a correct SETUP can in some cases be redirected to another 11839 URI and/or server by a 3rr response. 11841 +-------------+------------------------+---------+------------------+ 11842 | Action | Requisite | New | Response | 11843 | | | State | | 11844 +-------------+------------------------+---------+------------------+ 11845 | SETUP | New URI | Ready | NRM +=1 | 11846 | | | | | 11847 | SETUP | URI Setup prior | Ready | Change transport | 11848 | | | | param | 11849 | | | | | 11850 | TEARDOWN | Prs URI, | Init | No session hdr, | 11851 | | | | NRM = 0 | 11852 | | | | | 11853 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 11854 | | | | NRM = 0 | 11855 | | | | | 11856 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | 11857 | | | | -= 1 | 11858 | | | | | 11859 | PLAY | Prs URI, No range | Play | Play from RP | 11860 | | | | | 11861 | PLAY | Prs URI, Range | Play | According to | 11862 | | | | range | 11863 | | | | | 11864 | PLAY | md URI, NRM=1, Range | Play | According to | 11865 | | | | range | 11866 | | | | | 11867 | PLAY | md URI, NRM=1 | Play | Play from RP | 11868 | | | | | 11869 | PAUSE | Prs URI | Ready | Return PP | 11870 | | | | | 11871 | SC:REDIRECT | Terminate-Reason | Ready | Set RedP | 11872 | | | | | 11873 | SC:REDIRECT | No Terminate-Reason | Init | Session is | 11874 | | time parameter | | removed | 11875 | | | | | 11876 | Timeout | | Init | | 11877 | | | | | 11878 | RedP | | Init | TEARDOWN of | 11879 | reached | | | session | 11880 +-------------+------------------------+---------+------------------+ 11882 Table 15: State: Ready 11884 In the Ready state, see Table 15, some of the actions are depending 11885 on the number of media streams (NRM) in the session, i.e., aggregated 11886 or non-aggregated control. A SETUP request in the Ready state can 11887 either add one more media stream to the session or, if the media 11888 stream (same URI) already is part of the session, change the 11889 transport parameters. TEARDOWN is depending on both the Request-URI 11890 and the number of media streams within the session. If the Request- 11891 URI is the presentations URI the whole session is torn down. If a 11892 media URI is used in the TEARDOWN request and more than one media 11893 exists in the session, the session will remain and a session header 11894 is returned in the response. If only a single media stream remains 11895 in the session when performing a TEARDOWN with a media URI the 11896 session is removed. The number of media streams remaining after 11897 tearing down a media stream determines the new state. 11899 +----------------+-----------------------+--------+-----------------+ 11900 | Action | Requisite | New | Response | 11901 | | | State | | 11902 +----------------+-----------------------+--------+-----------------+ 11903 | PAUSE | Prs URI | Ready | Set RP to | 11904 | | | | present point | 11905 | | | | | 11906 | End of media | All media | Play | Set RP = End of | 11907 | | | | media | 11908 | | | | | 11909 | End of range | | Play | Set RP = End of | 11910 | | | | range | 11911 | | | | | 11912 | PLAY | Prs URI, No range | Play | Play from | 11913 | | | | present point | 11914 | | | | | 11915 | PLAY | Prs URI, Range | Play | According to | 11916 | | | | range | 11917 | | | | | 11918 | SC:PLAY_NOTIFY | | Play | 200 | 11919 | | | | | 11920 | SETUP | New URI | Play | 455 | 11921 | | | | | 11922 | SETUP | Setuped URI | Play | 455 | 11923 | | | | | 11924 | SETUP | Setuped URI, IFI | Play | Change | 11925 | | | | transport | 11926 | | | | param. | 11927 | | | | | 11928 | TEARDOWN | Prs URI | Init | No session hdr | 11929 | | | | | 11930 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 11931 | | | | NRM=0 | 11932 | | | | | 11933 | TEARDOWN | md URI | Play | 455 | 11934 | | | | | 11935 | SC:REDIRECT | Terminate Reason with | Play | Set RedP | 11936 | | Time parameter | | | 11937 | | | | | 11938 | SC:REDIRECT | | Init | Session is | 11939 | | | | removed | 11940 | | | | | 11941 | RedP reached | | Init | TEARDOWN of | 11942 | | | | session | 11943 | | | | | 11944 | Timeout | | Init | Stop Media | 11945 | | | | playout | 11946 +----------------+-----------------------+--------+-----------------+ 11947 Table 16: State: Play 11949 The Play state table, see Table 16, contains a number of requests 11950 that need a presentation URI (labeled as Prs URI) to work on (i.e., 11951 the presentation URI has to be used as the Request-URI). This is due 11952 to the exclusion of non-aggregated stream control in sessions with 11953 more than one media stream. 11955 To avoid inconsistencies between the client and server, automatic 11956 state transitions are avoided. This can be seen at for example "End 11957 of media" event when all media has finished playing, the session 11958 still remains in Play state. An explicit PAUSE request needs to be 11959 sent to change the state to Ready. It may appear that there exist 11960 automatic transitions in "RedP reached" and "PP reached". However, 11961 they are requested and acknowledged before they take place. The time 11962 at which the transition will happen is known by looking at the range 11963 header. If the client sends a request close in time to these 11964 transitions it needs to be prepared for receiving error messages, as 11965 the state may or may not have changed. 11967 Appendix C. Media Transport Alternatives 11969 This section defines how certain combinations of protocols, profiles 11970 and lower transports are used. This includes the usage of the 11971 Transport header's source and destination address parameters 11972 "src_addr" and "dest_addr". 11974 C.1. RTP 11976 This section defines the interaction of RTSP with respect to the RTP 11977 protocol [RFC3550]. It also defines any necessary media transport 11978 signaling with regards to RTP. 11980 The available RTP profiles and lower layer transports are described 11981 below along with rules on signaling the available combinations. 11983 C.1.1. AVP 11985 The usage of the "RTP Profile for Audio and Video Conferences with 11986 Minimal Control" [RFC3551] when using RTP for media transport over 11987 different lower layer transport protocols is defined below in regards 11988 to RTSP. 11990 One such case is defined within this document: the use of embedded 11991 (interleaved) binary data as defined in Section 14. The usage of 11992 this method is indicated by including the "interleaved" parameter. 11994 When using embedded binary data the "src_addr" and "dest_addr" MUST 11995 NOT be used. This addressing and multiplexing is used as defined 11996 with use of channel numbers and the interleaved parameter. 11998 C.1.2. AVP/UDP 12000 This part describes sending of RTP [RFC3550] over lower transport 12001 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 12002 and Video Conferences with Minimal Control" defined in RFC 3551 12003 [RFC3551]. Implementations of RTP/AVP/UDP MUST implement RTCP 12004 (Appendix C.1.6). This profile requires one or two uni- or bi- 12005 directional UDP flows per media stream. The first UDP flow is for 12006 RTP and the second is for RTCP. Multiplexing of RTP and RTCP 12007 (Appendix C.1.6.4) MAY be used, in which case a single UDP flow is 12008 used for both parts. Embedding of RTP data with the RTSP messages, 12009 in accordance with Section 14, SHOULD NOT be performed when RTSP 12010 messages are transported over unreliable transport protocols, like 12011 UDP [RFC0768]. 12013 The RTP/UDP and RTCP/UDP flows can be established using the Transport 12014 header's "src_addr", and "dest_addr" parameters. 12016 In RTSP PLAY mode, the transmission of RTP packets from client to 12017 server is unspecified. The behavior in regards to such RTP packets 12018 MAY be defined in future. 12020 The "src_addr" and "dest_addr" parameters are used in the following 12021 way for media delivery and playback mode, i.e., Mode=PLAY: 12023 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 12024 2 address specifications. Note that two address specifications 12025 MAY be provided even if RTP and RTCP multiplexing is negotiated. 12027 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 12028 contain either: 12030 * both an address and a port number, or 12032 * a port number without an address. 12034 o The first address specification given in either of the parameters 12035 applies to the RTP stream. The second specification if present 12036 applies to the RTCP stream, unless in case RTP and RTCP 12037 multiplexing is negotiated where both RTP and RTCP will use the 12038 first specification. 12040 o The RTP/UDP packets from the server to the client MUST be sent to 12041 the address and port given by the first address specification of 12042 the "dest_addr" parameter. 12044 o The RTCP/UDP packets from the server to the client MUST be sent to 12045 the address and port given by the second address specification of 12046 the "dest_addr" parameter, unless RTP and RTCP multiplexing has 12047 been negotiated, in which case RTCP MUST be sent to the first 12048 address specification. If no second pair is specified and RTP and 12049 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12051 o The RTCP/UDP packets from the client to the server MUST be sent to 12052 the address and port given by the second address specification of 12053 the "src_addr" parameter, unless RTP and RTCP multiplexing has 12054 been negotiated, in which case RTCP MUST be sent to the first 12055 address specification. If no second pair is specified and RTP and 12056 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12058 o The RTP/UDP packets from the client to the server MUST be sent to 12059 the address and port given by the first address specification of 12060 the "src_addr" parameter. 12062 o RTP and RTCP Packets SHOULD be sent from the corresponding 12063 receiver port, i.e., RTCP packets from the server should be sent 12064 from the "src_addr" parameters second address port pair, unless 12065 RTP and RTCP multiplexing has been negotiated in which case the 12066 first address port pair is used. 12068 C.1.3. AVPF/UDP 12070 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 12071 AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. 12072 All that is defined for AVP MUST also apply for AVPF. 12074 The usage of AVPF is indicated by the media initialization protocol 12075 used. In the case of SDP it is indicated by media lines (m=) 12076 containing the profile RTP/AVPF. That SDP MAY also contain further 12077 AVPF related SDP attributes configuring the AVPF session regarding 12078 reporting interval and feedback messages to be used [RFC4585]. This 12079 configuration MUST be followed. 12081 C.1.4. SAVP/UDP 12083 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 12084 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 12085 using RTP. All that is defined for AVP MUST also apply for SAVP. 12087 The usage of SRTP requires that a security context is established. 12088 The default key-management unless otherwise signalled SHALL be MIKEY 12089 in RSA-R mode as defined in Appendix C.1.4.1, and not according to 12090 the procedure defined in "Key Management Extensions for Session 12091 Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" 12092 [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY 12093 message in SDP, thus both requiring the usage of the DESCRIBE method 12094 and forcing the server to keep state for clients performing DESCRIBE 12095 in anticipation that they might require key management. 12097 MIKEY is selected as default method for establishing SRTP 12098 cryptographic context within an RTSP session as it can be embedded in 12099 the RTSP messages, while still ensuring confidentiality of content of 12100 the keying material, even when using hop-by-hop TLS security for the 12101 RTSP messages. This method does also support pipelining of the RTSP 12102 messages. 12104 C.1.4.1. MIKEY Key Establishment 12106 This method for using MIKEY [RFC3830] to establish the SRTP 12107 cryptographic context is initiated in the client's SETUP request, and 12108 the server's response to the SETUP carries the MIKEY response. This 12109 ensures that the crypto context establishment happens simultaneously 12110 with the establishment of the media stream being protected. By using 12111 MIKEY's RSA-R mode [RFC4738] the client can be the initiator and 12112 still allow the server to set the parameters in accordance with the 12113 actual media stream. 12115 The SRTP cryptographic context establishment is done according to the 12116 following process: 12118 1. The client determines that SAVP or SAVPF shall be used from 12119 media description format, e.g., SDP. If no other key management 12120 method is explicitly signalled, then MIKEY SHALL be used as 12121 defined herein. The use of SRTP with RTSP is only defined with 12122 MIKEY with keys established as defined in this Section. Future 12123 documents may define how an RTSP implementation treats SDP that 12124 indicates some other key mechanism to be used. The need for 12125 such specification include [RFC4567] that is not defined for use 12126 in RTSP 2.0 within this document. 12128 2. The client SHALL establish a TLS connection for RTSP messages, 12129 directly or hop by hop with the server. If hop-by-hop TLS 12130 security is used, the User method SHALL be indicated in the 12131 Accept-Credentials header. We do note that using hop-by-hop 12132 does allow the proxy to insert itself as a man in the middle 12133 also in the MIKEY exchange by providing one of its certificates, 12134 rather than the server's in the Connection-Credentials header. 12135 The client SHALL therefore validate the server certificate. 12137 3. The client retrieves the server's certificate from a direct TLS 12138 connection, or if hop by hop from Connection-Credentials header. 12139 The client then checks that the server certificate is valid and 12140 belongs to the server. 12142 4. The client forms the MIKEY Initiator message using RSA-R mode in 12143 unicast mode as specified in [RFC4738]. The client SHOULD use 12144 the same certificate for TLS and in MIKEY to enable the server 12145 to bind the two together. The client's certificate SHALL be 12146 included in the MIKEY message. The client SHALL indicate its 12147 SRTP capabilities in the message. 12149 5. The MIKEY message from the previous step is base64 [RFC4648] 12150 encoded and becomes the value of the MIKEY parameter that is 12151 included in the transport specification(s) that specifies a SRTP 12152 based profile (SAVP, SAVPF) in the SETUP request. 12154 6. Any proxy encountering the MIKEY parameter SHALL forward it 12155 without modification. A proxy requiring to understand transport 12156 specification which doesn't support SAVP/SAVPF with MIKEY will 12157 discard the whole transport specification. Most types of 12158 proxies can easily support SAVP and SAVPF with MIKEY. If 12159 possible bypassing the proxy should be tried. 12161 7. The server upon receiving the SETUP request, will need to decide 12162 upon the transport specification to use, if multiple are 12163 included by the client. In the determination of which transport 12164 specifications that are supported and preferred, the server 12165 SHOULD decode the MIKEY message to take the embedded SRTP 12166 parameters into account. If all transport specs require SRTP 12167 but no MIKEY parameter or other supported keying method is 12168 included, the server SHALL respond with 403. 12170 8. Upon generating a response the following outcomes can occur: 12172 * A transport spec not using SRTP and MIKEY is selected. Thus 12173 the response will not contain any MIKEY parameter. 12175 * A transport spec using SRTP and MIKEY is selected but an 12176 error is encountered in the MIKEY processing. In that case 12177 an RTSP error response code of 466 "Key Management Error" 12178 SHALL be used. A MIKEY message describing the error MAY be 12179 included. 12181 * A transport spec using SRTP and MIKEY is selected and a MIKEY 12182 response message can be created. The server SHOULD use the 12183 same certificate for TLS and in MIKEY to enable client to 12184 bind the two together. If a different certificate is used it 12185 SHALL be included in the MIKEY message. It is RECOMMENDED 12186 that the envelope key cache type is set to 'Cache' and that a 12187 single envelope key is reused for all MIKEY messages to the 12188 client. That message is included in the MIKEY parameter part 12189 of the single selected transport specification in the SETUP 12190 response. The server will set the SRTP parameters as 12191 preferred for this media stream within the supported range by 12192 the client. 12194 9. The server transmits the SETUP response back to the client. 12196 10. The client receives the SETUP response and if the response code 12197 indicates a successful request it decodes the MIKEY message and 12198 establishes the SRTP cryptographic context from the parameters 12199 in the MIKEY response. 12201 In the above method the client's certificate may be self-signed in 12202 cases where the client's identity is not necessary to authenticate 12203 and the security goal is only to ensure that the RTSP signaling 12204 client is the same as the one receiving the SRTP security context. 12206 C.1.5. SAVPF/UDP 12208 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 12209 (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in 12210 RTSP sessions using RTP. All that is defined for AVPF MUST also 12211 apply for SAVPF. 12213 The usage of SRTP requires that a cryptographic context is 12214 established. The default mechanism for establishing that security 12215 association is to use MIKEY[RFC3830] with RTSP as defined in 12216 Appendix C.1.4.1. 12218 C.1.6. RTCP usage with RTSP 12220 RTCP has several usages when RTP is used for media transport as 12221 explained below. Due to that RTCP MUST be supported if an RTSP agent 12222 handles RTP. 12224 C.1.6.1. Media synchronization 12226 RTCP provides media synchronization and clock drift compensation. 12227 The initial media synchronization is available from RTP-Info header. 12228 However, to be able to handle any clock drift between the media 12229 streams, RTCP is needed. 12231 C.1.6.2. RTSP Session keep-alive 12233 RTCP traffic from the RTSP client to the RTSP server MUST function as 12234 keep-alive. This requires an RTSP server supporting RTP to use the 12235 received RTCP packets as indications that the client desires the 12236 related RTSP session to be kept alive. 12238 C.1.6.3. Bit-rate adaption 12240 RTCP Receiver reports and any additional feedback from the client 12241 MUST be used to adapt the bit-rate used over the transport for all 12242 cases when RTP is sent over UDP. An RTP sender without reserved 12243 resources MUST NOT use more than its fair share of the available 12244 resources. This can be determined by comparing on short to medium 12245 term (some seconds) the used bit-rate and adapt it so that the RTP 12246 sender sends at a bit-rate comparable to what a TCP sender would 12247 achieve on average over the same path. 12249 To ensure that the implementation's adaptation mechanism has a well 12250 defined outer envelope, all implementations using a non-congestion 12251 controlled unicast transport protocol, like UDP, MUST implement 12252 Multimedia Congestion Control: Circuit Breakers for Unicast RTP 12253 Sessions [I-D.ietf-avtcore-rtp-circuit-breakers]. 12255 C.1.6.4. RTP and RTCP Multiplexing 12257 RTSP can be used to negotiate the usage of RTP and RTCP multiplexing 12258 as described in [RFC5761]. This allows servers and client to reduce 12259 the amount of resources required for the session by only requiring 12260 one underlying transport stream per media stream instead of two when 12261 using RTP and RTCP. This lessens the server port consumption and 12262 also the necessary state and keep-alive work when operating across 12263 Network and Address Translators [RFC2663]. 12265 Content must be prepared with some consideration for RTP and RTCP 12266 multiplexing, mainly ensuring that the RTP payload types used do not 12267 collide with the ones used for RTCP packet types. This option likely 12268 needs explicit support from the content unless the RTP payload types 12269 can be remapped by the server and that is correctly reflected in the 12270 session description. Beyond that support of this feature should come 12271 at little cost and much gain. 12273 It is recommended that if the content and server support RTP and RTCP 12274 multiplexing that this is indicated in the session description, for 12275 example using the SDP attribute "a=rtcp-mux". If the SDP message 12276 contains the a=rtcp-mux attribute for a media stream, the server MUST 12277 support RTP and RTCP multiplexing. If indicated or otherwise desired 12278 by the client it can include the Transport parameter "RTCP-mux" in 12279 any transport specification where it desires to use RTCP-mux. The 12280 server will indicate if it supports RTCP-mux. Servers and Clients 12281 SHOULD support RTP and RTCP multiplexing. 12283 For capability exchange, an RTSP feature tag for RTP and RTCP 12284 multiplexing is defined: "setup.rtp.rtcp.mux". 12286 To minimize the risk of negotiation failure while using RTP and RTCP 12287 multiplexing some recommendations are here provided. If the session 12288 description includes explicit indication of support (a=rtcp-mux in 12289 SDP), then a RTSP agent can safely create a SETUP request with a 12290 transport specification with only a single dest_addr parameter 12291 address specification. If no such explicit indication is provided, 12292 then even if the feature tag "setup.rtp.rtcp.mux" is provided in a 12293 Supported header by the RTSP server or the feature tag included in 12294 the Required header in the SETUP request, the media resource may not 12295 support RTP and RTCP multiplexing. Thus, to maximize the probability 12296 of successful negotiation the RTSP agent is recommended to include 12297 two dest_addr parameter address specifications in the first or first 12298 set (if pipelining is used) of SETUP request(s) for any media 12299 resource aggregate. That way the RTSP server can either accept RTP 12300 and RTCP multiplexing and only use the first address specification, 12301 and if not use both specifications. The RTSP agent after having 12302 received the response for a successful negotiation of the usage of 12303 RTP and RTCP multiplexing, can then release the resources associated 12304 with the second address specification. 12306 C.2. RTP over TCP 12308 Transport of RTP over TCP can be done in two ways: over independent 12309 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 12310 connection. In both cases the protocol MUST be "rtp" and the lower 12311 layer MUST be TCP. The profile may be any of the above specified 12312 ones; AVP, AVPF, SAVP or SAVPF. 12314 C.2.1. Interleaved RTP over TCP 12316 The use of embedded (interleaved) binary data transported on the RTSP 12317 connection is possible as specified in Section 14. When using this 12318 declared combination of interleaved binary data the RTSP messages 12319 MUST be transported over TCP. TLS may or may not be used. If TLS is 12320 used both RTSP messages and the binary data will be protected by TLS. 12322 One should, however, consider that this will result in all media 12323 streams go through any proxy. Using independent TCP connections can 12324 avoid that issue. 12326 C.2.2. RTP over independent TCP 12328 In this Appendix, we describe the sending of RTP [RFC3550] over lower 12329 transport layer TCP [RFC0793] according to "Framing Real-time 12330 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 12331 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 12332 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 12333 with RTSP. 12335 A client codes the support of RTP over independent TCP by specifying 12336 an RTP/AVP/TCP transport option without an interleaved parameter in 12337 the Transport line of a SETUP request. This transport option MUST 12338 include the "unicast" parameter. 12340 If the client wishes to use RTP with RTCP, two address specifications 12341 needs to be included in the dest_addr parameter. If the client 12342 wishes to use RTP without RTCP, one address specification is included 12343 in the dest_addr parameter. If the client wishes to multiplex RTP 12344 and RTCP on a single transport flow (see Appendix C.1.6.4), one or 12345 two address specifications are included in the dest_addr parameter in 12346 addition to the RTCP-mux transport parameter. Two address 12347 specifications are allowed to allow successful negotiation when 12348 server or content can't support RTP and RTCP multiplexing. Ordering 12349 rules of dest_addr ports follow the rules for RTP/AVP/UDP. 12351 If the client wishes to play the active role in initiating the TCP 12352 connection, it MAY set the "setup" parameter (See Section 18.54) on 12353 the Transport line to be "active", or it MAY omit the setup 12354 parameter, as active is the default. If the client signals the 12355 active role, the ports in the address specifications in the dest_addr 12356 parameter MUST be set to 9 (the discard port). 12358 If the client wishes to play the passive role in TCP connection 12359 initiation, it MUST set the "setup" parameter on the Transport line 12360 to be "passive". If the client is able to assume the active or the 12361 passive role, it MUST set the "setup" parameter on the Transport line 12362 to be "actpass". In either case, the dest_addr parameter's address 12363 specification port value for RTP MUST be set to the TCP port number 12364 on which the client is expecting to receive the TCP connection for 12365 RTP, and the dest_addr's address specification port value for RTCP 12366 MUST be set to the TCP port number on which the client is expecting 12367 to receive the TCP connection for RTCP. In the case that the client 12368 wishes to multiplex RTP and RTCP on a single transport flow, the 12369 RTCP-mux parameter is included and one or two dest_addr parameter 12370 address specifications are included, as mentioned earlier in this 12371 section. 12373 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 12374 server decides to accept this requested option, the 2xx reply MUST 12375 contain a Transport option that specifies RTP/AVP/TCP (without using 12376 the interleaved parameter, and with using the unicast parameter). 12377 The dest_addr parameter value MUST be echoed from the parameter value 12378 in the client request unless the destination address (only port) was 12379 not provided in which case the server MAY include the source address 12380 of the RTSP TCP connection with the port number unchanged. 12382 In addition, the server reply MUST set the setup parameter on the 12383 Transport line, to indicate the role the server will play in the 12384 connection setup. Permissible values are "active" (if a client set 12385 "setup" to "passive" or "actpass") and "passive" (if a client set 12386 "setup" to "active" or "actpass"). 12388 If a server sets "setup" to "passive", the "src_addr" in the reply 12389 MUST indicate the ports the server is willing to receive an TCP 12390 connection for RTP and (if the client requested an TCP connection for 12391 RTCP by specifying two dest_addr address specifications) an TCP/RTCP 12392 connection. If a server sets "setup" to "active", the ports 12393 specified in "src_addr" address specifications MUST be set to 9. The 12394 server MAY use the "ssrc" parameter, following the guidance in 12395 Section 18.54. The server sets only one address specification in the 12396 case that the client has indicated only a single address 12397 specification or in case RTP and RTCP multiplexing was requested and 12398 accepted by server. Port ordering for src_addr follows the rules for 12399 RTP/AVP/UDP. 12401 Servers MUST support taking the passive role and MAY support taking 12402 the active role. Servers with a public IP address take the passive 12403 role, thus enabling clients behind NATs and Firewalls a better chance 12404 of successful connect to the server by actively connecting outwards. 12405 Therefore the clients are RECOMMENDED to take the active role. 12407 After sending (receiving) a 2xx reply for a SETUP method for a non- 12408 interleaved RTP/AVP/TCP media stream, the active party SHOULD 12409 initiate the TCP connection as soon as possible. The client MUST NOT 12410 send a PLAY request prior to the establishment of all the TCP 12411 connections negotiated using SETUP for the session. In case the 12412 server receives a PLAY request in a session that has not yet 12413 established all the TCP connections, it MUST respond using the 464 12414 "Data Transport Not Ready Yet" (Section 17.4.28) error code. 12416 Once the PLAY request for a media resource transported over non- 12417 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 12418 client over the RTP TCP connection, and RTCP packets flow 12419 bidirectionally over the RTCP TCP connection. Unless RTP and RTCP 12420 multiplexing has been negotiated in which case RTP and RTCP will flow 12421 over a common TCP connection. As in the RTP/UDP case, client to 12422 server traffic on a RTP only TCP session is unspecified by this memo. 12423 The packets that travel on these connections MUST be framed using the 12424 protocol defined in [RFC4571], not by the framing defined for 12425 interleaving RTP over the RTSP connection defined in Section 14. 12427 A successful PAUSE request for a media being transported over RTP/ 12428 AVP/TCP pauses the flow of packets over the connections, without 12429 closing the connections. A successful TEARDOWN request signals that 12430 the TCP connections for RTP and RTCP are to be closed by the RTSP 12431 client as soon as possible. 12433 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 12434 ambiguous in the following way: does the client wish to open up new 12435 TCP connection for RTP or RTCP for the URI, or does the client wish 12436 to continue using the existing TCP connections? The client SHOULD 12437 use the "connection" parameter (defined in Section 18.54) on the 12438 Transport line to make its intention clear (by setting "connection" 12439 to "new" if new connections are needed, and by setting "connection" 12440 to "existing" if the existing connections are to be used). After a 12441 2xx reply for a SETUP request for a new connection, parties should 12442 close the pre-existing connections, after waiting a suitable period 12443 for any stray RTP or RTCP packets to arrive. 12445 The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that 12446 a security association is established. The default mechanism for 12447 establishing that security association is to use MIKEY[RFC3830] with 12448 RTSP as defined Appendix C.1.4.1. 12450 Below, we rewrite part of the example media on demand example shown 12451 in Appendix A.1 to use RTP/AVP/TCP non-interleaved: 12453 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 12454 CSeq: 1 12455 User-Agent: PhonyClient/1.2 12457 M->C: RTSP/2.0 200 OK 12458 CSeq: 1 12459 Server: PhonyServer/1.0 12460 Date: Thu, 23 Jan 1997 15:35:06 GMT 12461 Content-Type: application/sdp 12462 Content-Length: 227 12463 Content-Base: rtsp://example.com/twister.3gp/ 12464 Expires: 24 Jan 1997 15:35:06 GMT 12466 v=0 12467 o=- 2890844256 2890842807 IN IP4 198.51.100.34 12468 s=RTSP Session 12469 i=An Example of RTSP Session Usage 12470 e=adm@example.com 12471 c=IN IP4 0.0.0.0 12472 a=control: * 12473 a=range:npt=0-0:10:34.10 12474 t=0 0 12475 m=audio 0 RTP/AVP 0 12476 a=control: trackID=1 12478 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 12479 CSeq: 2 12480 User-Agent: PhonyClient/1.2 12481 Require: play.basic 12482 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 12483 setup=active;connection=new 12484 Accept-Ranges: npt, smpte, clock 12486 M->C: RTSP/2.0 200 OK 12487 CSeq: 2 12488 Server: PhonyServer/1.0 12489 Transport: RTP/AVP/TCP;unicast; 12490 dest_addr=":9"/":9"; 12491 src_addr="198.51.100.5:53478"/"198.51.100:54091"; 12492 setup=passive;connection=new;ssrc=93CB001E 12493 Session: 12345678 12494 Expires: 24 Jan 1997 15:35:12 GMT 12495 Date: 23 Jan 1997 15:35:12 GMT 12496 Accept-Ranges: npt 12497 Media-Properties: Random-Access=0.8, Immutable, Unlimited 12499 C->M: TCP Connection Establishment x2 12501 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 12502 CSeq: 4 12503 User-Agent: PhonyClient/1.2 12504 Range: npt=30- 12505 Session: 12345678 12507 M->C: RTSP/2.0 200 OK 12508 CSeq: 4 12509 Server: PhonyServer/1.0 12510 Date: 23 Jan 1997 15:35:14 GMT 12511 Session: 12345678 12512 Range: npt=30-623.10 12513 Seek-Style: First-Prior 12514 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" 12515 ssrc=4F312DD8:seq=54321;rtptime=2876889 12517 C.3. Handling Media Clock Time Jumps in the RTP Media Layer 12519 RTSP allows media clients to control selected, non-contiguous 12520 sections of media presentations, rendering those streams with an RTP 12521 media layer [RFC3550]. Two cases occur, the first is when a new PLAY 12522 request replaces an old ongoing request and the new request results 12523 in a jump in the media. This should produce in the RTP layer a 12524 continuous media stream. A client may also directly following a 12525 completed PLAY request perform a new PLAY request. This will result 12526 in some gap in the media layer. The below text will look into both 12527 cases. 12529 A PLAY request that replaces an ongoing request allows the media 12530 layer rendering the RTP stream without being affected by jumps in 12531 media clock time. The RTP timestamps for the new media range is set 12532 so that they become continuous with the previous media range in the 12533 previous request. The RTP sequence number for the first packet in 12534 the new range will be the next following the last packet in the 12535 previous range, i.e., monotonically increasing. The goal is to allow 12536 the media rendering layer to work without interruption or 12537 reconfiguration across the jumps in media clock. This should be 12538 possible in all cases of replaced PLAY requests for media that has 12539 random-access properties. In this case care is needed to align 12540 frames or similar media dependent structures. 12542 In cases where jumps in media clock time are a result of RTSP 12543 signaling operations arriving after a completed PLAY operation, the 12544 request timing will result in that media becomes non-continuous. The 12545 server becomes unable to send the media so that it arrives timely and 12546 still carry timestamps to make the media stream continuous. In these 12547 cases the server will produce RTP streams where there are gaps in the 12548 RTP timeline for the media. In such cases, if the media has frame 12549 structure, aligning the timestamp for the next frame with the 12550 previous structure reduces the burden to render this media. The gap 12551 should represent the time the server hasn't been serving media, e.g., 12552 the time between the end of the media stream or a PAUSE request and 12553 the new PLAY request. In these cases the RTP sequence number would 12554 normally be monotonically increasing across the gap. 12556 For RTSP sessions with media that lacks random access properties, 12557 such as live streams, any media clock jump is commonly the result of 12558 a correspondingly long pause of delivery. The RTP timestamp will 12559 have increased in direct proportion to the duration of the paused 12560 delivery. Note also that in this case the RTP sequence number should 12561 be the next packet number. If not, the RTCP packet loss reporting 12562 will indicate as loss all packets not received between the point of 12563 pausing and later resuming. This may trigger congestion avoidance 12564 mechanisms. An allowed exception from the above recommendation on 12565 monotonically increasing RTP sequence number is live media streams, 12566 likely being relayed. In this case, when the client resumes 12567 delivery, it will get the media that is currently being delivered to 12568 the server itself. For this type of basic delivery of live streams 12569 to multiple users over unicast, individual rewriting of RTP sequence 12570 numbers becomes quite a burden. For solutions that anyway caches 12571 media, timeshifts, etc, the rewriting should be a minor issue. 12573 The goal when handling jumps in media clock time is that the provided 12574 stream is continuous without gaps in RTP timestamp or sequence 12575 number. However, when delivery has been halted for some reason the 12576 RTP timestamp when resuming MUST represent the duration the delivery 12577 was halted. RTP sequence number MUST generally be the next number, 12578 i.e., monotonically increasing modulo 65536. For media resources 12579 with the properties Time-Progressing and Time-Duration=0.0 the server 12580 MAY create RTP media streams with RTP sequence number jumps in them 12581 due to the client first halting delivery and later resuming it (PAUSE 12582 and then later PLAY). However, servers utilizing this exception must 12583 take into consideration the resulting RTCP receiver reports that 12584 likely contain loss reports for all the packets part of the 12585 discontinuity. A client cannot rely on that a server will align when 12586 resuming playing even if it is RECOMMENDED. The RTP-Info header will 12587 provide information on how the server acts in each case. 12589 We cannot assume that the RTSP client can communicate with the RTP 12590 media agent, as the two may be independent processes. If the RTP 12591 timestamp shows the same gap as the NPT, the media agent will 12592 assume that there is a pause in the presentation. If the jump in 12593 NPT is large enough, the RTP timestamp may roll over and the media 12594 agent may believe later packets to be duplicates of packets just 12595 played out. Having the RTP timestamp jump will also affect the 12596 RTCP measurements based on this. 12598 As an example, assume an RTP timestamp frequency of 8000 Hz, a 12599 packetization interval of 100 ms and an initial sequence number and 12600 timestamp of zero. 12602 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12603 CSeq: 4 12604 Session: abcdefgh 12605 Range: npt=10-15 12606 User-Agent: PhonyClient/1.2 12608 S->C: RTSP/2.0 200 OK 12609 CSeq: 4 12610 Session: abcdefgh 12611 Range: npt=10-15 12612 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12613 ssrc=0D12F123:seq=0;rtptime=0 12615 The ensuing RTP data stream is depicted below: 12617 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12618 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12619 . . . 12620 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 12622 Upon the completion of the requested delivery the server sends a 12623 PLAY_NOTIFY 12624 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 12625 CSeq: 5 12626 Notify-Reason: end-of-stream 12627 Request-Status: cseq=4 status=200 reason="OK" 12628 Range: npt=-15 12629 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 12630 ssrc=0D12F123:seq=49;rtptime=39200 12631 Session: abcdefgh 12633 C->S: RTSP/2.0 200 OK 12634 CSeq: 5 12635 User-Agent: PhonyClient/1.2 12637 Upon the completion of the play range, the client follows up with a 12638 request to PLAY from a new NPT. 12640 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12641 CSeq: 6 12642 Session: abcdefg 12643 Range: npt=18-20 12644 User-Agent: PhonyClient/1.2 12646 S->C: RTSP/2.0 200 OK 12647 CSeq: 6 12648 Session: abcdefg 12649 Range: npt=18-20 12650 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12651 ssrc=0D12F123:seq=50;rtptime=40100 12653 The ensuing RTP data stream is depicted below: 12655 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 12656 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 12657 . . . 12658 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 12660 In this example, first, NPT 10 through 15 is played, then the client 12661 requests the server to skip ahead and play NPT 18 through 20. The 12662 first segment is presented as RTP packets with sequence numbers 0 12663 through 49 and timestamp 0 through 39,200. The second segment 12664 consists of RTP packets with sequence number 50 through 69, with 12665 timestamps 40,100 through 55,200. While there is a gap in the NPT, 12666 there is no gap in the sequence number space of the RTP data stream. 12668 The RTP timestamp gap is present in the above example due to the time 12669 it takes to perform the second play request, in this case 12.5 ms 12670 (100/8000). 12672 C.4. Handling RTP Timestamps after PAUSE 12674 During a PAUSE / PLAY interaction in an RTSP session, the duration of 12675 time for which the RTP transmission was halted MUST be reflected in 12676 the RTP timestamp of each RTP stream. The duration can be calculated 12677 for each RTP stream as the time elapsed from when the last RTP packet 12678 was sent before the PAUSE request was received and when the first RTP 12679 packet was sent after the subsequent PLAY request was received. The 12680 duration includes all latency incurred and processing time required 12681 to complete the request. 12683 The RTP RFC [RFC3550] states that: The RTP timestamp for each unit 12684 [packet] would be related to the wallclock time at which the unit 12685 becomes current on the virtual presentation timeline. 12687 In order to satisfy the requirements of [RFC3550], the RTP 12688 timestamp space needs to increase continuously with real time. 12689 While this is not optimal for stored media, it is required for RTP 12690 and RTCP to function as intended. Using a continuous RTP 12691 timestamp space allows the same timestamp model for both stored 12692 and live media and allows better opportunity to integrate both 12693 types of media under a single control. 12695 As an example, assume a clock frequency of 8000 Hz, a packetization 12696 interval of 100 ms and an initial sequence number and timestamp of 12697 zero. 12699 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12700 CSeq: 4 12701 Session: abcdefg 12702 Range: npt=10-15 12703 User-Agent: PhonyClient/1.2 12705 S->C: RTSP/2.0 200 OK 12706 CSeq: 4 12707 Session: abcdefg 12708 Range: npt=10-15 12709 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12710 ssrc=0D12F123:seq=0;rtptime=0 12712 The ensuing RTP data stream is depicted below: 12714 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12715 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12716 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 12717 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 12719 The client then sends a PAUSE request: 12721 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 12722 CSeq: 5 12723 Session: abcdefg 12724 User-Agent: PhonyClient/1.2 12726 S->C: RTSP/2.0 200 OK 12727 CSeq: 5 12728 Session: abcdefg 12729 Range: npt=10.4-15 12731 20 seconds elapse and then the client sends a PLAY request. In 12732 addition the server requires 15 ms to process the request: 12734 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12735 CSeq: 6 12736 Session: abcdefg 12737 User-Agent: PhonyClient/1.2 12739 S->C: RTSP/2.0 200 OK 12740 CSeq: 6 12741 Session: abcdefg 12742 Range: npt=10.4-15 12743 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12744 ssrc=0D12F123:seq=4;rtptime=164400 12746 The ensuing RTP data stream is depicted below: 12748 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 12749 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 12750 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 12752 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 12753 server. After 20 seconds a PLAY is received by the server which 12754 takes 15 ms to process. The duration of time for which the session 12755 was paused is reflected in the RTP timestamp of the RTP packets sent 12756 after this PLAY request. 12758 A client can use the RTSP range header and RTP-Info header to map NPT 12759 time of a presentation with the RTP timestamp. 12761 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 12762 was misunderstood commonly. However, for RTSP 2.0 it is expected 12763 that this will be handled correctly and no exception handling will be 12764 required. 12766 Note further: It may be required to reset some of the state to ensure 12767 the correct media decoding and the usual jitter-buffer handling when 12768 issuing a PLAY request. 12770 C.5. RTSP / RTP Integration 12772 For certain data types, tight integration between the RTSP layer and 12773 the RTP layer will be necessary. This by no means precludes the 12774 above restrictions. Combined RTSP/RTP media clients should use the 12775 RTP-Info field to determine whether incoming RTP packets were sent 12776 before or after a seek or before or after a PAUSE. 12778 C.6. Scaling with RTP 12780 For scaling (see Section 18.46), RTP timestamps should correspond to 12781 the rendering timing. For example, when playing video recorded at 30 12782 frames/second at a scale of two and speed (Section 18.50) of one, the 12783 server would drop every second frame to maintain and deliver video 12784 packets with the normal timestamp spacing of 3,000 per frame, but NPT 12785 would increase by 1/15 second for each video frame. 12787 Note: The above scaling puts requirements on the media codec or a 12788 media stream to support it. For example motion JPEG or other non- 12789 predictive video coding can easier handle the above example. 12791 C.7. Maintaining NPT synchronization with RTP timestamps 12793 The client can maintain a correct display of NPT (Normal Play Time) 12794 by noting the RTP timestamp value of the first packet arriving after 12795 repositioning. The sequence parameter of the RTP-Info 12796 (Section 18.45) header provides the first sequence number of the next 12797 segment. 12799 C.8. Continuous Audio 12801 For continuous audio, the server SHOULD set the RTP marker bit at the 12802 beginning of serving a new PLAY request or at jumps in timeline. 12803 This allows the client to perform playout delay adaptation. 12805 C.9. Multiple Sources in an RTP Session 12807 Note that more than one SSRC MAY be sent in the media stream. If it 12808 happens all sources are expected to be rendered simultaneously. 12810 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 12812 The RTCP BYE message indicates the end of use of a given SSRC. If 12813 all sources leave an RTP session, it can, in most cases, be assumed 12814 to have ended. Therefore, a client or server MUST NOT send an RTCP 12815 BYE message until it has finished using a SSRC. A server SHOULD keep 12816 using a SSRC until the RTP session is terminated. Prolonging the use 12817 of a SSRC allows the established synchronization context associated 12818 with that SSRC to be used to synchronize subsequent PLAY requests 12819 even if the PLAY response is late. 12821 An SSRC collision with the SSRC that transmits media does also have 12822 consequences, as it will normally force the media sender to change 12823 its SSRC in accordance with the RTP specification [RFC3550]. 12824 However, an RTSP server may wait and see if the client changes and 12825 thus resolve the conflict to minimize the impact. As media sender 12826 SSRC change will result in a loss of synchronization context, and 12827 require any receiver to wait for RTCP sender reports for all media 12828 requiring synchronization before being able to play out synchronized. 12829 Due to these reasons a client joining a session should take care to 12830 not select the same SSRC(s) as the server indicates in the ssrc 12831 Transport header parameter. Any SSRC signalled in the Transport 12832 header MUST be avoided. A client detecting a collision prior to 12833 sending any RTP or RTCP messages SHALL also select a new SSRC. 12835 C.11. Future Additions 12837 It is the intention that any future protocol or profile regarding 12838 media delivery and lower transport should be easy to add to RTSP. 12839 This section provides the necessary steps that needs to be meet. 12841 The following things needs to be considered when adding a new 12842 protocol or profile for use with RTSP: 12844 o The protocol or profile needs to define a name tag representing 12845 it. This tag is required to be an ABNF "token" to be possible to 12846 use in the Transport header specification. 12848 o The useful combinations of protocol, profiles and lower layer 12849 transport for this extension needs to be defined. For each 12850 combination declare the necessary parameters to use in the 12851 Transport header. 12853 o For new media protocols the interaction with RTSP needs to be 12854 addressed. One important factor will be the media 12855 synchronization. It may be necessary to have new headers similar 12856 to RTP info to carry this information. 12858 o Discuss congestion control for media, especially if transport 12859 without built in congestion control is used. 12861 See the IANA section (Section 22) for information how to register new 12862 attributes. 12864 Appendix D. Use of SDP for RTSP Session Descriptions 12866 The Session Description Protocol (SDP, [RFC4566]) may be used to 12867 describe streams or presentations in RTSP. This description is 12868 typically returned in reply to a DESCRIBE request on an URI from a 12869 server to a client, or received via HTTP from a server to a client. 12871 This appendix describes how an SDP file determines the operation of 12872 an RTSP session. Thus, it is worth pointing out that the 12873 interpretation of the SDP is done in the context of the SDP receiver, 12874 which is the one being configured. This is the same as in SAP 12875 [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each 12876 SDP is interpreted in the context of the agent providing it. 12878 SDP as is provides no mechanism by which a client can distinguish, 12879 without human guidance, between several media streams to be rendered 12880 simultaneously and a set of alternatives (e.g., two audio streams 12881 spoken in different languages). The SDP extension "Grouping of Media 12882 Lines in the Session Description Protocol (SDP)" [RFC5888] provides 12883 such functionality to some degree. Appendix D.4 describes the usage 12884 of SDP media line grouping for RTSP. 12886 D.1. Definitions 12888 The terms "session-level", "media-level" and other key/attribute 12889 names and values used in this appendix are to be used as defined in 12890 SDP[RFC4566]: 12892 D.1.1. Control URI 12894 The "a=control:" attribute is used to convey the control URI. This 12895 attribute is used both for the session and media descriptions. If 12896 used for individual media, it indicates the URI to be used for 12897 controlling that particular media stream. If found at the session 12898 level, the attribute indicates the URI for aggregate control 12899 (presentation URI). The session level URI MUST be different from any 12900 media level URI. The presence of a session level control attribute 12901 MUST be interpreted as support for aggregated control. The control 12902 attribute MUST be present on media level unless the presentation only 12903 contains a single media stream, in which case the attribute MAY be 12904 present on the session level only and then also apply to that single 12905 media stream. 12907 ABNF for the attribute is defined in Section 20.3. 12909 Example: 12910 a=control:rtsp://example.com/foo 12912 This attribute MAY contain either relative or absolute URIs, 12913 following the rules and conventions set out in RFC 3986 [RFC3986]. 12914 Implementations MUST look for a base URI in the following order: 12916 1. the RTSP Content-Base field; 12918 2. the RTSP Content-Location field; 12920 3. the RTSP Request-URI. 12922 If this attribute contains only an asterisk (*), then the URI MUST be 12923 treated as if it were an empty embedded URI, and thus inherit the 12924 entire base URI. 12926 Note, RFC 2326 was very unclear on the processing of relative URI 12927 and several RTSP 1.0 implementations at the point of publishing 12928 this document did not perform RFC 3986 processing to determine the 12929 resulting URI, instead simple concatenation is common. To avoid 12930 this issue completely it is recommended to use absolute URI in the 12931 SDP. 12933 The URI handling for SDPs from container files need special 12934 consideration. For example let's assume that a container file has 12935 the URI: "rtsp://example.com/container.mp4". Let's further assume 12936 this URI is the base URI, and that there is an absolute media level 12937 URI: "rtsp://example.com/container.mp4/trackID=2". A relative media 12938 level URI that resolves in accordance with RFC 3986 [RFC3986] to the 12939 above given media URI is: "container.mp4/trackID=2". It is usually 12940 not desirable to need to include in or modify the SDP stored within 12941 the container file with the server local name of the container file. 12942 To avoid this, one can modify the base URI used to include a trailing 12943 slash, e.g., "rtsp://example.com/container.mp4/". In this case the 12944 relative URI for the media will only need to be: "trackID=2". 12945 However, this will also mean that using "*" in the SDP will result in 12946 control URI including the trailing slash, i.e., 12947 "rtsp://example.com/container.mp4/". 12949 Note: The usage of TrackID in the above is not a standardized 12950 form, but one example out of several similar strings such as 12951 TrackID, Track_ID, StreamID that is used by different server 12952 vendors to indicate a particular piece of media inside a container 12953 file. 12955 D.1.2. Media Streams 12957 The "m=" field is used to enumerate the streams. It is expected that 12958 all the specified streams will be rendered with appropriate 12959 synchronization. If the session is over multicast, the port number 12960 indicated SHOULD be used for reception. The client MAY try to 12961 override the destination port, through the Transport header. The 12962 servers MAY allow this, the response will indicate if allowed or not. 12963 If the session is unicast, the port numbers are the ones RECOMMENDED 12964 by the server to the client, about which receiver ports to use; the 12965 client MUST still include its receiver ports in its SETUP request. 12966 The client MAY ignore this recommendation. If the server has no 12967 preference, it SHOULD set the port number value to zero. 12969 The "m=" lines contain information about which transport protocol, 12970 profile, and possibly lower-layer is to be used for the media stream. 12971 The combination of transport, profile and lower layer, like RTP/AVP/ 12972 UDP needs to be defined for how to be used with RTSP. The currently 12973 defined combinations are defined in Appendix C, further combinations 12974 MAY be specified. 12976 Example: 12977 m=audio 0 RTP/AVP 31 12979 D.1.3. Payload Type(s) 12981 The payload type(s) are specified in the "m=" line. In case the 12982 payload type is a static payload type from RFC 3551 [RFC3551], no 12983 other information may be required. In case it is a dynamic payload 12984 type, the media attribute "rtpmap" is used to specify what the media 12985 is. The "encoding name" within the "rtpmap" attribute may be one of 12986 those specified in [RFC4856], or a media type registered with IANA 12987 according to [RFC4855], or an experimental encoding as specified in 12988 SDP [RFC4566]). Codec-specific parameters are not specified in this 12989 field, but rather in the "fmtp" attribute described below. 12991 The selection of the RTP payload type numbers used may be required to 12992 consider RTP and RTCP Multiplexing [RFC5761] if that is to be 12993 supported by the server. 12995 D.1.4. Format-Specific Parameters 12997 Format-specific parameters are conveyed using the "fmtp" media 12998 attribute. The syntax of the "fmtp" attribute is specific to the 12999 encoding(s) that the attribute refers to. Note that some of the 13000 format specific parameters may be specified outside of the fmtp 13001 parameters, like for example the "ptime" attribute for most audio 13002 encodings. 13004 D.1.5. Directionality of media stream 13006 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 13007 provide instructions about the direction the media streams flow 13008 within a session. When using RTSP the SDP can be delivered to a 13009 client using either RTSP DESCRIBE or a number of RTSP external 13010 methods, like HTTP, FTP, and email. Based on this the SDP applies to 13011 how the RTSP client will see the complete session. Thus media 13012 streams delivered from the RTSP server to the client, would be given 13013 the "a=recvonly" attribute. 13015 "a=recvonly" in a SDP provided to the RTSP client indicates that 13016 media delivery will only occur in the direction from the RTSP server 13017 to the client. SDP provided to the RTSP client that lacks any of the 13018 directionality attributes (a=recvonly, a=sendonly, a=sendrecv) would 13019 be interpreted as having a=sendrecv. At the time of writing there 13020 exist no RTSP mode suitable for media traffic in the direction from 13021 the RTSP client to the server. Thus all RTSP SDP SHOULD have 13022 a=recvonly attribute when using the PLAY mode defined in this 13023 document. If future modes are defined for media in client to server 13024 direction, then usage of a=sendonly, or a=sendrecv may become 13025 suitable to indicate intended media directions. 13027 D.1.6. Range of Presentation 13029 The "a=range" attribute defines the total time range of the stored 13030 session or an individual media. Non-seekable live sessions can be 13031 indicated as specified below, while the length of live sessions can 13032 be deduced from the "t=" and "r=" SDP parameters. 13034 The attribute is both a session and a media level attribute. For 13035 presentations that contain media streams of the same duration, the 13036 range attribute SHOULD only be used at session-level. In case of 13037 different lengths the range attribute MUST be given at media level 13038 for all media, and SHOULD NOT be given at session level. If the 13039 attribute is present at both media level and session level the media 13040 level values MUST be used. 13042 Note: Usually one will specify the same length for all media, even if 13043 there isn't media available for the full duration on all media. 13044 However, that requires that the server accepts PLAY requests within 13045 that range. 13047 Servers MUST take care to provide RTSP Range (see Section 18.40) 13048 values that are consistent with what is presented in the SDP for the 13049 content. There is no reason for non dynamic content, like media 13050 clips provided on demand to have inconsistent values. Inconsistent 13051 values between the SDP and the actual values for the content handled 13052 by the server is likely to generate some failure, like 457 "Invalid 13053 Range", in case the client uses PLAY requests with a Range header. 13054 In case the content is dynamic in length and it is infeasible to 13055 provide a correct value in the SDP the server is recommended to 13056 describe this as non-seekable content (see below). The server MAY 13057 override that property in the response to a PLAY request using the 13058 correct values in the Range header. 13060 The unit is specified first, followed by the value range. The units 13061 and their values are as defined in Section 4.4.1, Section 4.4.2 and 13062 Section 4.4.3 and MAY be extended with further formats. Any open 13063 ended range (start-), i.e., without stop range, is of unspecified 13064 duration and MUST be considered as non-seekable content unless this 13065 property is overridden. Multiple instances carrying different clock 13066 formats MAY be included at either session or media level. 13068 ABNF for the attribute is defined in Section 20.3. 13070 Examples: 13071 a=range:npt=0-34.4368 13072 a=range:clock=19971113T211503Z-19971113T220300Z 13073 Non seekable stream of unknown duration: 13074 a=range:npt=0- 13076 D.1.7. Time of Availability 13078 The "t=" field defines when the SDP is valid. For on-demand content 13079 the server SHOULD indicate a stop time value for which it guarantees 13080 the description to be valid, and a start time that is equal to or 13081 before the time at which the DESCRIBE request was received. It MAY 13082 also indicate start and stop times of 0, meaning that the session is 13083 always available. 13085 For sessions that are of live type, i.e., specific start time, 13086 unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD 13087 be used to indicate the start time of the event. The stop time 13088 SHOULD be given so that the live event will have ended at that time, 13089 while still not be unnecessary long into the future. 13091 D.1.8. Connection Information 13093 In SDP used with RTSP, the "c=" field contains the destination 13094 address for the media stream. If a multicast address is specified 13095 the client SHOULD use this address in any SETUP request as 13096 destination address, including any additional parameters, such as 13097 TTL. For on-demand unicast streams and some multicast streams, the 13098 destination address MAY be specified by the client via the SETUP 13099 request, thus overriding any specified address. To identify streams 13100 without a fixed destination address, where the client is required to 13101 specify a destination address, the "c=" field SHOULD be set to a null 13102 value. For addresses of type "IP4", this value MUST be "0.0.0.0", 13103 and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be 13104 written as "::"), i.e., the unspecified address according to RFC 4291 13105 [RFC4291]. 13107 D.1.9. Message Body Tag 13109 The optional "a=mtag" attribute identifies a version of the session 13110 description. It is opaque to the client. SETUP requests may include 13111 this identifier in the If-Match field (see Section 18.24) to only 13112 allow session establishment if this attribute value still corresponds 13113 to that of the current description. The attribute value is opaque 13114 and may contain any character allowed within SDP attribute values. 13116 ABNF for the attribute is defined in Section 20.3. 13118 Example: 13119 a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a" 13121 One could argue that the "o=" field provides identical 13122 functionality. However, it does so in a manner that would put 13123 constraints on servers that need to support multiple session 13124 description types other than SDP for the same piece of media 13125 content. 13127 D.2. Aggregate Control Not Available 13129 If a presentation does not support aggregate control no session level 13130 "a=control:" attribute is specified. For a SDP with multiple media 13131 sections specified, each section will have its own control URI 13132 specified via the "a=control:" attribute. 13134 Example: 13135 v=0 13136 o=- 2890844256 2890842807 IN IP4 192.0.2.56 13137 s=I came from a web page 13138 e=adm@example.com 13139 c=IN IP4 0.0.0.0 13140 t=0 0 13141 m=video 8002 RTP/AVP 31 13142 a=control:rtsp://audio.example.com/movie.aud 13143 m=audio 8004 RTP/AVP 3 13144 a=control:rtsp://video.example.com/movie.vid 13146 Note that the position of the control URI in the description implies 13147 that the client establishes separate RTSP control sessions to the 13148 servers audio.example.com and video.example.com. 13150 It is recommended that an SDP file contains the complete media 13151 initialization information even if it is delivered to the media 13152 client through non-RTSP means. This is necessary as there is no 13153 mechanism to indicate that the client should request more detailed 13154 media stream information via DESCRIBE. 13156 D.3. Aggregate Control Available 13158 In this scenario, the server has multiple streams that can be 13159 controlled as a whole. In this case, there are both a media-level 13160 "a=control:" attributes, which are used to specify the stream URIs, 13161 and a session-level "a=control:" attribute which is used as the 13162 Request-URI for aggregate control. If the media-level URI is 13163 relative, it is resolved to absolute URIs according to Appendix D.1.1 13164 above. 13166 Example: 13167 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 13168 CSeq: 1 13169 User-Agent: PhonyClient/1.2 13171 M->C: RTSP/2.0 200 OK 13172 CSeq: 1 13173 Date: Thu, 23 Jan 1997 15:35:06 GMT 13174 Expires: Thu, 23 Jan 1997 16:35:06 GMT 13175 Content-Type: application/sdp 13176 Content-Base: rtsp://example.com/movie/ 13177 Content-Length: 227 13179 v=0 13180 o=- 2890844256 2890842807 IN IP4 192.0.2.211 13181 s=I contain 13182 i= 13183 e=adm@example.com 13184 c=IN IP4 0.0.0.0 13185 a=control:* 13186 t=0 0 13187 m=video 8002 RTP/AVP 31 13188 a=control:trackID=1 13189 m=audio 8004 RTP/AVP 3 13190 a=control:trackID=2 13192 In this example, the client is recommended to establish a single RTSP 13193 session to the server, and uses the URIs 13194 rtsp://example.com/movie/trackID=1 and 13195 rtsp://example.com/movie/trackID=2 to set up the video and audio 13196 streams, respectively. The URI rtsp://example.com/movie/, which is 13197 resolved from the "*", controls the whole presentation (movie). 13199 A client is not required to issue SETUP requests for all streams 13200 within an aggregate object. Servers should allow the client to ask 13201 for only a subset of the streams. 13203 D.4. Grouping of Media Lines in SDP 13205 For some types of media it is desirable to express a relationship 13206 between various media components, for instance, for lip 13207 synchronization or Scalable Video Codec (SVC) [RFC5583]. This 13208 relationship is expressed on the SDP level by grouping of media 13209 lines, as described in [RFC5888] and can be exposed to RTSP. 13211 For RTSP it is mainly important to know how to handle grouped medias 13212 received by means of SDP, i.e., if the media are under aggregate 13213 control (see Appendix D.3) or if aggregate control is not available 13214 (see Appendix D.2). 13216 It is RECOMMENDED that grouped medias are handled by aggregate 13217 control, to give the client the ability to control either the whole 13218 presentation or single medias. 13220 D.5. RTSP external SDP delivery 13222 There are some considerations that need to be made when the session 13223 description is delivered to the client outside of RTSP, for example 13224 via HTTP or email. 13226 First of all, the SDP needs to contain absolute URIs, since relative 13227 will in most cases not work as the delivery will not correctly 13228 forward the base URI. 13230 The writing of the SDP session availability information, i.e., "t=" 13231 and "r=", needs to be carefully considered. When the SDP is fetched 13232 by the DESCRIBE method, the probability that it is valid is very 13233 high. However, the same is much less certain for SDPs distributed 13234 using other methods. Therefore the publisher of the SDP should take 13235 care to follow the recommendations about availability in the SDP 13236 specification [RFC4566] in Section 4.2. 13238 Appendix E. RTSP Use Cases 13240 This Appendix describes the most important and considered use cases 13241 for RTSP. They are listed in descending order of importance in 13242 regards to ensuring that all necessary functionality is present. 13243 This specification only fully supports usage of the two first. Also 13244 in these first two cases, there are special cases or exceptions that 13245 are not supported without extensions, e.g., the redirection of media 13246 delivery to another address than the controlling agent's (client's). 13248 E.1. On-demand Playback of Stored Content 13250 An RTSP capable server stores content suitable for being streamed to 13251 a client. A client desiring playback of any of the stored content 13252 uses RTSP to set up the media transport required to deliver the 13253 desired content. RTSP is then used to initiate, halt and manipulate 13254 the actual transmission (playout) of the content. RTSP is also 13255 required to provide necessary description and synchronization 13256 information for the content. 13258 The above high level description can be broken down into a number of 13259 functions that RTSP needs to be capable of. 13261 Presentation Description: Provide initialization information about 13262 the presentation (content); for example, which media codecs are 13263 needed for the content. Other information that is important 13264 includes the number of media streams the presentation contains, 13265 the transport protocols used for the media streams, and 13266 identifiers for these media streams. This information is 13267 required before setup of the content is possible and to 13268 determine if the client is even capable of using the content. 13270 This information need not be sent using RTSP; other external 13271 protocols can be used to transmit the transport presentation 13272 descriptions. Two good examples are the use of HTTP [RFC2616] 13273 or email to fetch or receive presentation descriptions like SDP 13274 [RFC4566] 13276 Setup: Set up some or all of the media streams in a presentation. 13277 The setup itself consists of selecting the protocol for media 13278 transport and the necessary parameters for the protocol, like 13279 addresses and ports. 13281 Control of Transmission: After the necessary media streams have been 13282 established the client can request the server to start 13283 transmitting the content. The client must be allowed to start 13284 or stop the transmission of the content at arbitrary times. 13285 The client must also be able to start the transmission at any 13286 point in the timeline of the presentation. 13288 Synchronization: For media transport protocols like RTP [RFC3550] it 13289 might be beneficial to carry synchronization information within 13290 RTSP. This may be due to either the lack of inter-media 13291 synchronization within the protocol itself, or the potential 13292 delay before the synchronization is established (which is the 13293 case for RTP when using RTCP). 13295 Termination: Terminate the established contexts. 13297 For this use case there are a number of assumptions about how it 13298 works. These are: 13300 On-Demand content: The content is stored at the server and can be 13301 accessed at any time during a time period when it is intended 13302 to be available. 13304 Independent sessions: A server is capable of serving a number of 13305 clients simultaneously, including from the same piece of 13306 content at different points in that presentations time-line. 13308 Unicast Transport: Content for each individual client is transmitted 13309 to them using unicast traffic. 13311 It is also possible to redirect the media traffic to a different 13312 destination than that of the agent controlling the traffic. However, 13313 allowing this without appropriate mechanisms for checking that the 13314 destination approves of this allows for distributed denial of service 13315 attacks (DDoS). 13317 E.2. Unicast Distribution of Live Content 13319 This use case is similar to the above on-demand content case (see 13320 Appendix E.1) the difference is the nature of the content itself. 13321 Live content is continuously distributed as it becomes available from 13322 a source; i.e., the main difference from on-demand is that one starts 13323 distributing content before the end of it has become available to the 13324 server. 13326 In many cases the consumer of live content is only interested in 13327 consuming what actually happens "now"; i.e., very similar to 13328 broadcast TV. However, in this case it is assumed that there exists 13329 no broadcast or multicast channel to the users, and instead the 13330 server functions as a distribution node, sending the same content to 13331 multiple receivers, using unicast traffic between server and client. 13332 This unicast traffic and the transport parameters are individually 13333 negotiated for each receiving client. 13335 Another aspect of live content is that it often has a very limited 13336 time of availability, as it is only available for the duration of the 13337 event the content covers. An example of such a live content could be 13338 a music concert which lasts 2 hour and starts at a predetermined 13339 time. Thus there is a need to announce when and for how long the 13340 live content is available. 13342 In some cases, the server providing live content may be saving some 13343 or all of the content to allow clients to pause the stream and resume 13344 it from the paused point, or to "rewind" and play continuously from a 13345 point earlier than the live point. Hence, this use case does not 13346 necessarily exclude playing from other than the live point of the 13347 stream, playing with scales other than 1.0, etc. 13349 E.3. On-demand Playback using Multicast 13351 It is possible to use RTSP to request that media be delivered to a 13352 multicast group. The entity setting up the session (the controller) 13353 will then control when and what media is delivered to the group. 13354 This use case has some potential for denial of service attacks by 13355 flooding a multicast group. Therefore, a mechanism is needed to 13356 indicate that the group actually accepts the traffic from the RTSP 13357 server. 13359 An open issue in this use case is how one ensures that all receivers 13360 listening to the multicast or broadcast receives the session 13361 presentation configuring the receivers. This specification has to 13362 rely on an external solution to solve this issue. 13364 E.4. Inviting an RTSP server into a conference 13366 If one has an established conference or group session, it is possible 13367 to have an RTSP server distribute media to the whole group. 13368 Transmission to the group is simplest when controlled by a single 13369 participant or leader of the conference. Shared control might be 13370 possible, but would require further investigation and possibly 13371 extensions. 13373 This use case assumes that there exists either multicast or a 13374 conference focus that redistribute media to all participants. 13376 This use case is intended to be able to handle the following 13377 scenario: A conference leader or participant (hereafter called the 13378 controller) has some pre-stored content on an RTSP server that he 13379 wants to share with the group. The controller sets up an RTSP 13380 session at the streaming server for this content and retrieves the 13381 session description for the content. The destination for the media 13382 content is set to the shared multicast group or conference focus. 13384 When desired by the controller, he/she can start and stop the 13385 transmission of the media to the conference group. 13387 There are several issues with this use case that are not solved by 13388 this core specification for RTSP: 13390 Denial of service: To avoid an RTSP server from being an unknowing 13391 participant in a denial of service attack the server needs to 13392 be able to verify the destination's acceptance of the media. 13393 Such a mechanism to verify the approval of received media does 13394 not yet exist; instead, only policies can be used, which can be 13395 made to work in controlled environments. 13397 Distributing the presentation description to all participants in the 13398 group: To enable a media receiver to correctly decode the content 13399 the media configuration information needs to be distributed 13400 reliably to all participants. This will most likely require 13401 support from an external protocol. 13403 Passing control of the session: If it is desired to pass control of 13404 the RTSP session between the participants, some support will be 13405 required by an external protocol to exchange state information 13406 and possibly floor control of who is controlling the RTSP 13407 session. 13409 E.5. Live Content using Multicast 13411 This use case in its simplest form does not require any use of RTSP 13412 at all; this is what multicast conferences being announced with SAP 13413 [RFC2974] and SDP are intended to handle. However, in use cases 13414 where more advanced features like access control to the multicast 13415 session are desired, RTSP could be used for session establishment. 13417 A client desiring to join a live multicasted media session with 13418 cryptographic (encryption) access control could use RTSP in the 13419 following way. The source of the session announces the session and 13420 gives all interested an RTSP URI. The client connects to the server 13421 and requests the presentation description, allowing configuration for 13422 reception of the media. In this step it is possible for the client 13423 to use secured transport and any desired level of authentication; for 13424 example, for billing or access control. An RTSP link also allows for 13425 load balancing between multiple servers. 13427 If these were the only goals, they could be achieved by simply using 13428 HTTP. However, for cases where the sender likes to keep track of 13429 each individual receiver of a session, and possibly use the session 13430 as a side channel for distributing key-updates or other information 13431 on a per-receiver basis, and the full set of receivers is not known 13432 prior to the session start, the state establishment that RTSP 13433 provides can be beneficial. In this case a client would establish an 13434 RTSP session for this multicast group with the RTSP server. The RTSP 13435 server will not transmit any media, but instead will point to the 13436 multicast group. The client and server will be able to keep the 13437 session alive for as long as the receiver participates in the session 13438 thus enabling, for example, the server to push updates to the client. 13440 This use case will most likely not be able to be implemented without 13441 some extensions to the server-to-client push mechanism. Here the 13442 PLAY_NOTIFY method (see Section 13.5) with a suitable extension could 13443 provide clear benefits. 13445 Appendix F. Text format for Parameters 13447 A resource of type "text/parameters" consists of either 1) a list of 13448 parameters (for a query) or 2) a list of parameters and associated 13449 values (for an response or setting of the parameter). Each entry of 13450 the list is a single line of text. Parameters are separated from 13451 values by a colon. The parameter name MUST only use US-ASCII visible 13452 characters while the values are UTF-8 text strings. The media type 13453 registration form is in Section 22.16. 13455 There is a potential interoperability issue for this format. It was 13456 named in RFC 2326 but never defined, even if used in examples that 13457 hint at the syntax. This format matches the purpose and its syntax 13458 supports the examples provided. However, it goes further by allowing 13459 UTF-8 in the value part, thus usage of UTF-8 strings may not be 13460 supported. However, as individual parameters are not defined, the 13461 using application anyway needs to have out-of-band agreement or using 13462 feature-tag to determine if the end-point supports the parameters. 13464 The ABNF [RFC5234] grammar for "text/parameters" content is: 13466 file = *((parameter / parameter-value) CRLF) 13467 parameter = 1*visible-except-colon 13468 parameter-value = parameter *WSP ":" value 13469 visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" 13470 value = *(TEXT-UTF8char / WSP) 13471 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 13472 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 13473 / %xE0-EF 2UTF8-CONT 13474 / %xF0-F7 3UTF8-CONT 13475 / %xF8-FB 4UTF8-CONT 13476 / %xFC-FD 5UTF8-CONT 13477 UTF8-CONT = %x80-BF 13478 WSP = ; Space or HTAB 13479 VCHAR = 13480 CRLF = 13482 Appendix G. Requirements for Unreliable Transport of RTSP 13484 This appendix provides guidance for those who want to implement RTSP 13485 messages over unreliable transports as has been defined in RTSP 1.0 13486 [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some 13487 basic information for the transport of RTSP messages over UDP. The 13488 information is being provided here as there has been at at least one 13489 commercial implementation and compatibility with that should be 13490 maintained. 13492 The following points should be considered for an interoperable 13493 implementation: 13495 o Request shall be acknowledged by the receiver. If there is no 13496 acknowledgement, the sender may resend the same message after a 13497 timeout of one round-trip time (RTT). Any retransmissions due to 13498 lack of acknowledgement must carry the same sequence number as the 13499 original request. 13501 o The round-trip time can be estimated as in TCP (RFC 6298) 13502 [RFC6298], with an initial round-trip value of 500 ms. An 13503 implementation may cache the last RTT measurement as the initial 13504 value for future connections. 13506 o The Timestamp header (Section 18.53) is used to avoid the 13507 retransmission ambiguity problem [Stevens98]. 13509 o The registered default port for RTSP over UDP for the server is 13510 554. 13512 o RTSP messages can be carried over any lower-layer transport 13513 protocol that is 8-bit clean. 13515 o RTSP messages are vulnerable to bit errors and should not be 13516 subjected to them. 13518 o Source authentication, or at least validation that RTSP messages 13519 comes from the same entity becomes extremely important, as session 13520 hijacking may be substantially easier for RTSP message transport 13521 using an unreliable protocol like UDP than for TCP. 13523 There are two RTSP headers that are primarily intended for being used 13524 by the unreliable handling of RTSP messages and which will be 13525 maintained: 13527 o CSeq: See Section 18.20. It should be noted that the CSeq header 13528 is also required to match requests and responses independent 13529 whether a reliable or unreliable transport is used. 13531 o Timestamp: See Section 18.53 13533 Appendix H. Backwards Compatibility Considerations 13535 This section contains notes on issues about backwards compatibility 13536 with clients or servers being implemented according to RFC 2326 13537 [RFC2326]. Note that there exists no requirement to implement RTSP 13538 1.0; in fact we recommend against it as it is difficult to do in an 13539 interoperable way. 13541 A server implementing RTSP/2.0 MUST include an RTSP-Version of 13542 RTSP/2.0 in all responses to requests containing RTSP-Version 13543 RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond 13544 with an RTSP/1.0 response if it chooses to support RFC 2326. If the 13545 server chooses not to support RFC 2326, it MUST respond with a 505 13546 (RTSP Version not supported) status code. A server MUST NOT respond 13547 to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 13548 response. 13550 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 13551 Version of 2.0 to determine whether a server supports RTSP/2.0. If 13552 the server responds with either an RTSP-Version of 1.0 or a status 13553 code of 505 (RTSP Version not supported), the client will have to use 13554 RTSP/1.0 requests if it chooses to support RFC 2326. 13556 H.1. Play Request in Play State 13558 The behavior in the server when a Play is received in Play state has 13559 changed (Section 13.4). In RFC 2326, the new PLAY request would be 13560 queued until the current Play completed. Any new PLAY request now 13561 takes effect immediately replacing the previous request. 13563 H.2. Using Persistent Connections 13565 Some server implementations of RFC 2326 maintain a one-to-one 13566 relationship between a connection and an RTSP session. Such 13567 implementations require clients to use a persistent connection to 13568 communicate with the server and when a client closes its connection, 13569 the server may remove the RTSP session. This is worth noting if a 13570 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 13572 Appendix I. Changes 13574 This appendix briefly lists the differences between RTSP 1.0 13575 [RFC2326] and RTSP 2.0 for an informational purpose. For 13576 implementers of RTSP 2.0 it is recommended to read carefully through 13577 this memo and not to rely on the list of changes below to adapt from 13578 RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards 13579 compatible with RTSP 1.0 [RFC2326] other than the version negotiation 13580 mechanism. 13582 I.1. Brief Overview 13584 The following protocol elements were removed in RTSP 2.0 compared to 13585 RTSP 1.0: 13587 o there is no section on minimal implementation anymore, but more 13588 the definition of RTSP 2.0 core; 13590 o the RECORD and ANNOUNCE methods and all related functionality 13591 (including 201 (Created) and 250 (Low On Storage Space) status 13592 codes); 13594 o the use of UDP for RTSP message transport was removed due to 13595 missing interest and to broken specification; 13597 o the use of PLAY method for keep-alive in Play state. 13599 The following protocol elements were added or changed in RTSP 2.0 13600 compared to RTSP 1.0: 13602 o RTSP session TEARDOWN from the server to the client; 13604 o IPv6 support; 13606 o extended IANA registries (e.g., transport headers parameters, 13607 transport-protocol, profile, lower-transport, and mode); 13609 o request pipelining for quick session start-up; 13611 o fully reworked state-machine; 13613 o RTSP messages now use URIs rather then URLs; 13615 o incorporated much of related HTTP text ([RFC2616]) in this memo, 13616 compared to just referencing the sections in HTTP, to avoid 13617 ambiguities; 13619 o the REDIRECT method was expanded and diversified for different 13620 situations; 13622 o Includes a new section about how to setup different media 13623 transport alternatives and their profiles, and lower layer 13624 protocols. This caused the appendix on RTP interaction to be 13625 moved there instead of being in the part which describes RTP. The 13626 section also includes guidelines what to consider when writing 13627 usage guidelines for new protocols and profiles; 13629 o Added an asynchronous notification method PLAY_NOTIFY. This 13630 method is used by the RTSP server to asynchronously notify clients 13631 about session changes while in Play state. To a limited extent 13632 this is comparable with some implementations of ANNOUNCE in RTSP 13633 1.0 not intended for Recording. 13635 I.2. Detailed List of Changes 13637 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 13638 defining RTSP 2.0. Note that this list does not reflect minor 13639 changes in wording or correction of typographical errors. 13641 o The section on minimal implementation was deleted without 13642 substitution. 13644 o The Transport header has been changed in the following way: 13646 * The ABNF has been changed to define that extensions are 13647 possible, and that unknown parameters result in that servers 13648 ignore the transport specification. 13650 * To prevent backwards compatibility issues, any extension or new 13651 parameter requires the usage of a feature-tag combined with the 13652 Require header. 13654 * Syntax unclarities with the Mode parameter have been resolved. 13656 * Syntax error with ";" for multicast and unicast has been 13657 resolved. 13659 * Two new addressing parameters have been defined, src_addr and 13660 dest_addr. These replace the parameters "port", "client_port", 13661 "server_port", "destination", "source". 13663 * Support for IPv6 explicit addresses in all address fields has 13664 been included. 13666 * To handle URI definitions that contain ";" or "," a quoted URI 13667 format has been introduced and is required. 13669 * Defined IANA registries for the transport headers parameters, 13670 transport-protocol, profile, lower-transport, and mode. 13672 * The transport headers interleaved parameter's text was made 13673 more strict and uses formal requirements levels. It was also 13674 clarified that the interleaved channels are symmetric and that 13675 it is the server that sets the channel numbers. 13677 * It has been clarified that the client can't request of the 13678 server to use a certain RTP SSRC, using a request with the 13679 transport parameter SSRC. 13681 * Syntax definition for SSRC has been clarified to require 8HEX. 13682 It has also been extended to allow multiple values for clients 13683 supporting this version. 13685 * Clarified the text on the transport headers "dest_addr" 13686 parameters regarding what security precautions the server is 13687 required to perform. 13689 o The Range formats has been changed in the following way: 13691 * The NPT format has been given an initial NPT identifier that 13692 must now be used. 13694 * All formats now support initial open ended formats of type 13695 "npt=-10" and also format only "Range: smpte" ranges for usage 13696 with GET_PARAMETER requests. 13698 o RTSP message handling has been changed in the following way: 13700 * RTSP messages now use URIs rather then URLs. 13702 * It has been clarified that a 4xx message due to missing CSeq 13703 header shall be returned without a CSeq header. 13705 * The 300 (Multiple Choices) response code has been removed. 13707 * Rules for how to handle timing out RTSP messages has been 13708 added. 13710 * Extended Pipelining rules allowing for quick session startup. 13712 * Sequence numbering and proxy handling of sequence number 13713 defined, including case when response arrive out of order. 13715 o The HTTP references have been updated to RFC 2616 and RFC 2617. 13716 Most of the text has been copied and then altered to fit RTSP into 13717 this specification. Public, and the Content-Base header has also 13718 been imported from RFC 2068 so that they are defined in the RTSP 13719 specification. Known effects on RTSP due to HTTP clarifications: 13721 * Content-Encoding header can include encoding of type 13722 "identity". 13724 o The state machine section has been completely rewritten. It now 13725 includes more details and is also more clear about the model used. 13727 o An IANA section has been included which contains a number of 13728 registries and their rules. This will allow us to use IANA to 13729 keep track of RTSP extensions. 13731 o The transport of RTSP messages has seen the following changes: 13733 * The use of UDP for RTSP message transport has been deprecated 13734 due to missing interest and to broken specification. 13736 * The rules for how TCP connections are to be handled has been 13737 clarified. Now it is made clear that servers should not close 13738 the TCP connection unless they have been unused for significant 13739 time. 13741 * Strong recommendations why server and clients should use 13742 persistent connections have also been added. 13744 * There is now a requirement on the servers to handle non- 13745 persistent connections as this provides fault tolerance. 13747 * Added wording on the usage of Connection:Close for RTSP. 13749 * Specified usage of TLS for RTSP messages, including a scheme to 13750 approve a proxy's TLS connection to the next hop. 13752 o The following header related changes have been made: 13754 * Accept-Ranges response header is added. This header clarifies 13755 which range formats that can be used for a resource. 13757 * Fixed the missing definitions for the Cache-Control header. 13758 Also added to the syntax definition the missing delta-seconds 13759 for max-stale and min-fresh parameters. 13761 * Put requirement on CSeq header that the value is increased by 13762 one for each new RTSP request. A Recommendation to start at 0 13763 has also been added. 13765 * Added requirement that the Date header must be used for all 13766 messages with message body and the Server should always include 13767 it. 13769 * Removed possibility of using Range header with Scale header to 13770 indicate when it is to be activated, since it can't work as 13771 defined. Also added rule that lack of Scale header in response 13772 indicates lack of support for the header. Feature-tags for 13773 scaled playback has been defined. 13775 * The Speed header must now be responded to indicate support and 13776 the actual speed going to be used. A feature-tag is defined. 13777 Notes on congestion control were also added. 13779 * The Supported header was borrowed from SIP [RFC3261] to help 13780 with the feature negotiation in RTSP. 13782 * Clarified that the Timestamp header can be used to resolve 13783 retransmission ambiguities. 13785 * The Session header text has been expanded with an explanation 13786 on keep-alive and which methods to use. SET_PARAMETER is now 13787 recommended to use if only keep-alive within RTSP is desired. 13789 * It has been clarified how the Range header formats are used to 13790 indicate pause points in the PAUSE response. 13792 * Clarified that RTP-Info URIs that are relative, use the 13793 Request-URI as base URI. Also clarified that the used URI must 13794 be the one that was used in the SETUP request. The URIs are 13795 now also required to be quoted. The header also expresses the 13796 SSRC for the provided RTP timestamp and sequence number values. 13798 * Added text that requires the Range to always be present in PLAY 13799 responses. Clarified what should be sent in case of live 13800 streams. 13802 * The headers table has been updated using a structure borrowed 13803 from SIP. Those tables convey much more information and should 13804 provide a good overview of the available headers. 13806 * It has been clarified that any message with a message body is 13807 required to have a Content-Length header. This was the case in 13808 RFC 2326, but could be misinterpreted. 13810 * ETag has changed name to MTag. 13812 * To resolve functionality around MTag. The MTag and If-None- 13813 Match header have been added from HTTP with necessary 13814 clarification in regards to RTSP operation. 13816 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 13817 it has been removed from HTTP due to lack of use. Public is 13818 used quite frequently in RTSP. 13820 * Clarified rules for populating the Public header so that it is 13821 an intersection of the capabilities of all the RTSP agents in a 13822 chain. 13824 * Added the Media-Range header for listing the current 13825 availability of the media range. 13827 * Added the Notify-Reason header for giving the reason when 13828 sending PLAY_NOTIFY requests. 13830 * A new header Seek-Style has been defined to direct and inform 13831 how any seek operation should/have been performed. 13833 o The Protocol Syntax has been changed in the following way: 13835 * All ABNF definitions are updated according to the rules defined 13836 in RFC 5234 [RFC5234] and have been gathered in a separate 13837 Section 20. 13839 * The ABNF for the User-Agent and Server headers have been 13840 corrected. 13842 * Some definitions in the introduction regarding the RTSP session 13843 have been changed. 13845 * The protocol has been made fully IPv6 capable. 13847 * The CHAR rule has been changed to exclude NULL. 13849 o The Status codes have been changed in the following way: 13851 * The use of status code 303 "See Other" has been deprecated as 13852 it does not make sense to use in RTSP. 13854 * When sending response 451 and 458 the response body should 13855 contain the offending parameters. 13857 * Clarification on when a 3rr redirect status code can be 13858 received has been added. This includes receiving 3rr as a 13859 result of a request within a established session. This 13860 provides clarification to a previous unspecified behavior. 13862 * Removed the 201 (Created) and 250 (Low On Storage Space) status 13863 codes as they are only relevant to recording, which is 13864 deprecated. 13866 * Several new Status codes have been defined: 464 "Data Transport 13867 Not Ready Yet", 465 "Notification Reason Unknown", 470 13868 "Connection Authorization Required", 471 "Connection 13869 Credentials not accepted", 472 "Failure to establish secure 13870 connection". 13872 o The following functionality has been deprecated from the protocol: 13874 * The use of Queued Play. 13876 * The use of PLAY method for keep-alive in Play state. 13878 * The RECORD and ANNOUNCE methods and all related functionality. 13879 Some of the syntax has been removed. 13881 * The possibility to use timed execution of methods with the time 13882 parameter in the Range header. 13884 * The description on how rtspu works is not part of the core 13885 specification and will require external description. Only that 13886 it exists is defined here and some requirements for the 13887 transport is provided. 13889 o The following changes have been made in relation to methods: 13891 * The OPTIONS method has been clarified with regards to the use 13892 of the Public and Allow headers. 13894 * Added text clarifying the usage of SET_PARAMETER for keep-alive 13895 and usage without any body. 13897 * PLAY method is now allowed to be pipelined with the pipelining 13898 of one or more SETUP requests following the initial that 13899 generates the session for aggregated control. 13901 * REDIRECT has been expanded and diversified for different 13902 situations. 13904 * Added a new method PLAY_NOTIFY. This method is used by the 13905 RTSP server to asynchronously notify clients about session 13906 changes. 13908 o Wrote a new section about how to setup different media transport 13909 alternatives and their profiles, and lower layer protocols. This 13910 caused the appendix on RTP interaction to be moved there instead 13911 of being in the part which describes RTP. The section also 13912 includes guidelines what to consider when writing usage guidelines 13913 for new protocols and profiles. 13915 o Setup and usage of independent TCP connections for transport of 13916 RTP has been specified. 13918 o Added a new section describing the available mechanisms to 13919 determine if functionality is supported, called "Capability 13920 Handling". Renamed option-tags to feature-tags. 13922 o Added a contributors section with people who have contributed 13923 actual text to the specification. 13925 o Added a section Use Cases that describes the major use cases for 13926 RTSP. 13928 o Clarified the usage of a=range and how to indicate live content 13929 that are not seekable with this header. 13931 o Text specifying the special behavior of PLAY for live content. 13933 o Security features of RTSP has been clarified: 13935 * HTTP based authorization has been clarified requring both Basic 13936 and DIGEST support 13938 * TLS support mandated 13940 * IF one implements RTP then SRTP and defined MIKEY based key- 13941 exchange must be supported 13943 * Various minor mitigations discussed or resulted in protocol 13944 changes. 13946 Appendix J. Acknowledgements 13948 This memorandum defines RTSP version 2.0 which is a revision of the 13949 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 13950 The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert 13951 Lanphier. 13953 Both RTSP version 1.0 and RTSP version 2.0 borrow format and 13954 descriptions from HTTP/1.1. 13956 This document has benefited greatly from the comments of all those 13957 participating in the MMUSIC-WG. In addition to those already 13958 mentioned, the following individuals have contributed to this 13959 specification: 13961 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 13962 Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi, 13963 Francisco Cortes, Elwyn Davies, Kelly Djahandari, Martin Dunsmuir, 13964 Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy 13965 Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, 13966 Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, 13967 Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth 13968 Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Chris 13969 Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool, Martti Mela, 13970 David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, 13971 Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi, Igor 13972 Plotnikov, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David 13973 Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John 13974 Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker, 13975 Stephan Wenger, Dale R. Worley, and Byungjo Yoon , and especially to 13976 Flemming Andreasen. 13978 J.1. Contributors 13980 The following people have made written contributions that were 13981 included in the specification: 13983 o Tom Marshall contributed text on the usage of 3rr status codes. 13985 o Thomas Zheng contributed text on the usage of the Range in PLAY 13986 responses and proposed an earlier version of the PLAY_NOTIFY 13987 method. 13989 o Sean Sheedy contributed text on the timeout behavior of RTSP 13990 messages and connections, the 463 status code, and proposed an 13991 earlier version of the PLAY_NOTIFY method. 13993 o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY 13994 method. 13996 o Fredrik Lindholm contributed text about the RTSP security 13997 framework. 13999 o John Lazzaro contributed the text for RTP over Independent TCP. 14001 o Aravind Narasimhan contributed by rewriting Media Transport 14002 Alternatives (Appendix C) and editorial improvements on a number 14003 of places in the specification. 14005 o Torbjorn Einarsson has done some editorial improvements of the 14006 text. 14008 Appendix K. RFC Editor Consideration 14010 Please replace RFC XXXX with the RFC number this specification 14011 receives. 14013 Authors' Addresses 14015 Henning Schulzrinne 14016 Columbia University 14017 1214 Amsterdam Avenue 14018 New York, NY 10027 14019 USA 14021 Email: schulzrinne@cs.columbia.edu 14023 Anup Rao 14024 Cisco 14025 USA 14027 Email: anrao@cisco.com 14029 Rob Lanphier 14030 Seattle, WA 14031 USA 14033 Email: robla@robla.net 14035 Magnus Westerlund 14036 Ericsson AB 14037 Faeroegatan 6 14038 STOCKHOLM, SE-164 80 14039 SWEDEN 14041 Email: magnus.westerlund@ericsson.com 14043 Martin Stiemerling 14044 NEC Laboratories Europe, NEC Europe Ltd. 14045 Kurfuersten-Anlage 36 14046 Heidelberg 69115 14047 Germany 14049 Phone: +49 (0) 6221 4342 113 14050 Email: martin.stiemerling@neclab.eu 14051 URI: http://ietf.stiemerling.org