idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-29.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 (March 12, 2012) is 4427 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 4672, but not defined == Missing Reference: 'H15' is mentioned on line 8819, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 9426, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-pub-180-2' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** 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 4288 (Obsoleted by RFC 6838) ** 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-11 -- 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 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group H. Schulzrinne 3 Internet-Draft Columbia University 4 Obsoletes: 2326 (if approved) A. Rao 5 Intended status: Standards Track Cisco 6 Expires: September 13, 2012 R. Lanphier 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 March 12, 2012 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-29 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 September 13, 2012. 49 Copyright Notice 51 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 29 95 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29 96 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30 97 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31 98 4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 31 99 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31 100 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32 101 4.9.1. Random Access and Seeking . . . . . . . . . . . . . 33 102 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33 103 4.9.3. Content Modifications . . . . . . . . . . . . . . . 34 104 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34 105 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34 106 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35 107 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35 108 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35 109 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 110 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 111 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 38 112 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 113 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39 114 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 41 115 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 116 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 117 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 118 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 119 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48 120 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48 121 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49 122 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50 123 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50 124 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51 125 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 126 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 127 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 128 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56 129 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 56 130 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 131 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60 132 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 133 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62 134 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 63 135 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 65 136 13.3.1. Changing Transport Parameters . . . . . . . . . . . 68 137 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 69 138 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 69 139 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 74 140 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 75 141 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 77 142 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 78 143 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 78 144 13.4.7. Playing Live with Recording . . . . . . . . . . . . 79 145 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 79 146 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 80 147 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 81 148 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 82 149 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 83 150 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84 151 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 87 152 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 87 153 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 88 154 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89 155 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91 156 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 92 157 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 95 158 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 159 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 98 160 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 99 161 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 162 16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 100 163 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 102 164 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 102 165 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 102 166 16.1.4. Rules for When to Use Message Body Tags and 167 Last-Modified Dates . . . . . . . . . . . . . . . . 104 168 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 106 169 16.2. Invalidation After Updates or Deletions . . . . . . . . 106 170 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 108 171 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 108 172 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108 173 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 108 174 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 108 175 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 108 176 17.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 109 177 17.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 109 178 17.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 109 179 17.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 109 180 17.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 110 181 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 110 182 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 110 183 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 110 184 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 111 185 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 111 186 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 111 187 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 111 188 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 111 189 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 112 190 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 112 191 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 112 192 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 112 193 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 113 194 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 113 195 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 113 196 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 113 197 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 113 198 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 114 199 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 114 200 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 114 201 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 114 202 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 114 203 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 114 204 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 114 205 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 114 206 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 115 207 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 115 208 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 115 209 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 115 210 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 115 211 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 115 212 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 116 213 17.4.32. 470 Connection Authorization Required . . . . . . . 116 214 17.4.33. 471 Connection Credentials not accepted . . . . . . 116 215 17.4.34. 472 Failure to establish secure connection . . . . . 116 216 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 116 217 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 116 218 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 116 219 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 117 220 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 117 221 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 117 222 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 117 223 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 117 224 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 118 225 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 128 226 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 128 227 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 129 228 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 130 229 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 131 230 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 131 231 18.7. Authorization . . . . . . . . . . . . . . . . . . . . . 131 232 18.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 132 233 18.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 133 234 18.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 133 235 18.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 136 236 18.12. Connection-Credentials . . . . . . . . . . . . . . . . . 136 237 18.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 137 238 18.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 137 239 18.15. Content-Language . . . . . . . . . . . . . . . . . . . . 138 240 18.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 139 241 18.17. Content-Location . . . . . . . . . . . . . . . . . . . . 139 242 18.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 140 243 18.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 140 244 18.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 141 245 18.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 142 246 18.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 143 247 18.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 143 248 18.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 144 249 18.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144 250 18.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145 251 18.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 145 252 18.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 146 253 18.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 148 254 18.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 148 255 18.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 149 256 18.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 149 257 18.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 150 258 18.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 150 259 18.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 151 260 18.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 151 261 18.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 152 262 18.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 153 263 18.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 154 264 18.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 155 265 18.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 155 266 18.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 156 267 18.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 157 268 18.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 159 269 18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 160 270 18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 162 271 18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 162 272 18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 163 273 18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 164 274 18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 165 275 18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 165 276 18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 166 277 18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 173 278 18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 173 279 18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 173 280 18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 174 281 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175 282 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175 283 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175 284 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176 285 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177 286 19.3.2. User approved TLS procedure . . . . . . . . . . . . 178 287 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 288 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181 289 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183 290 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183 291 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186 292 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190 293 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199 294 21. Security Considerations . . . . . . . . . . . . . . . . . . . 200 295 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 200 296 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 203 297 21.2.1. Remote denial of Service Attack . . . . . . . . . . 204 298 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 205 299 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 207 300 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 207 301 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 208 302 22.1.2. Registering New Feature-tags with IANA . . . . . . . 208 303 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 208 304 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 209 305 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 209 306 22.2.2. Registering New Methods with IANA . . . . . . . . . 209 307 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 209 308 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 210 309 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 210 310 22.3.2. Registering New Status Codes with IANA . . . . . . . 210 311 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 210 312 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 210 313 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 210 314 22.4.2. Registering New Headers with IANA . . . . . . . . . 211 315 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 211 317 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 212 318 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 212 319 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 213 320 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 213 321 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 214 322 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 214 323 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 215 324 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 215 325 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 215 326 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 215 327 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 215 328 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 216 329 22.9. Range header formats . . . . . . . . . . . . . . . . . . 216 330 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 216 331 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 216 332 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 216 333 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 217 334 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 217 335 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 217 336 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 217 337 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 217 338 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 218 339 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 218 340 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 218 341 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 218 342 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 218 343 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 219 344 22.13. Transport Header Registries . . . . . . . . . . . . . . 219 345 22.13.1. Transport Protocol Specification . . . . . . . . . . 219 346 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 221 347 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 221 348 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 222 349 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 222 350 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 223 351 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 224 352 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 224 353 22.16. Media Type Registration for text/parameters . . . . . . 225 354 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 227 355 23.1. Normative References . . . . . . . . . . . . . . . . . . 227 356 23.2. Informative References . . . . . . . . . . . . . . . . . 229 357 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 232 358 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 232 359 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 236 360 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 238 361 A.4. Single Stream Container Files . . . . . . . . . . . . . 242 362 A.5. Live Media Presentation Using Multicast . . . . . . . . 244 363 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 245 364 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 247 365 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 247 366 B.2. State variables . . . . . . . . . . . . . . . . . . . . 247 367 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 247 368 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 248 369 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 254 370 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 254 371 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 254 372 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 254 373 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 255 374 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 256 375 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 258 376 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 258 377 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 260 378 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 260 379 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 260 380 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 264 381 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 268 382 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 270 383 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 270 384 C.7. Maintaining NPT synchronization with RTP timestamps . . 270 385 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 270 386 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 270 387 C.10. Usage of SSRCs and the RTCP BYE Message During an 388 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 270 389 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 271 390 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 272 391 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 272 392 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 272 393 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 273 394 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 274 395 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 274 396 D.1.5. Directionality of media stream . . . . . . . . . . . 274 397 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 275 398 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 276 399 D.1.8. Connection Information . . . . . . . . . . . . . . . 276 400 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 277 401 D.2. Aggregate Control Not Available . . . . . . . . . . . . 277 402 D.3. Aggregate Control Available . . . . . . . . . . . . . . 278 403 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 279 404 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 279 405 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 280 406 E.1. On-demand Playback of Stored Content . . . . . . . . . . 280 407 E.2. Unicast Distribution of Live Content . . . . . . . . . . 281 408 E.3. On-demand Playback using Multicast . . . . . . . . . . . 282 409 E.4. Inviting an RTSP server into a conference . . . . . . . 282 410 E.5. Live Content using Multicast . . . . . . . . . . . . . . 283 411 Appendix F. Text format for Parameters . . . . . . . . . . . . . 285 412 Appendix G. Requirements for Unreliable Transport of RTSP . . . 286 413 Appendix H. Backwards Compatibility Considerations . . . . . . . 288 414 H.1. Play Request in Play State . . . . . . . . . . . . . . . 288 415 H.2. Using Persistent Connections . . . . . . . . . . . . . . 288 416 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 289 417 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 289 418 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 290 419 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 297 420 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 297 421 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 299 422 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 300 424 1. Introduction 426 This memo defines version 2.0 of the Real Time Streaming Protocol 427 (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and 428 control over the delivery of data with real-time properties, 429 typically streaming media. Streaming media is, for instance, video 430 on demand or audio live streaming. Put simply, RTSP acts as a 431 "network remote control" for multimedia servers, similar to the 432 remote control for a DVD player. 434 The protocol operates between RTSP 2.0 clients and servers, but also 435 supports the usage of proxies placed between clients and servers. 436 Clients can request information about streaming media from servers by 437 asking for a description of the media or use media description 438 provided externally. The media delivery protocol is used to 439 establish the media streams described by the media description. 440 Clients can then request to play out the media, pause it, or stop it 441 completely, as known from DVD players remote control or media 442 players. The requested media can consist of multiple audio and video 443 streams that are delivered as a time-synchronized streams from 444 servers to clients. 446 RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that 447 specification. This protocol is based on RTSP 1.0 but is not 448 backwards compatible other than in the basic version negotiation 449 mechanism. The changes are documented in Appendix I. There are many 451 reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but 452 some of the main ones are: 454 o Most headers that needed to be extensible did not define the 455 allowed syntax, preventing safe deployment of extensions; 457 o The changed behavior of the PLAY method when received in Play 458 state; 460 o Changed behavior of the extensibility model and its mechanism; 462 o The change of syntax for some headers. 464 In summary, there are so many small details that changing version 465 became necessary to enable clarification and consistent behavior. 467 This document is structured as follows. It begins with an overview 468 of the protocol operations and its functions in an informal way. 469 Then a set of definitions of used terms and document conventions is 470 introduced. It is followed by the actual RTSP 2.0 core protocol 471 specification. The appendixes describe and define some 472 functionalities that are not part of the core RTSP specification, but 473 which are still important to enable some usages. Among them, the RTP 474 usage is defined in Appendix C and the SDP usage with RTSP is defined 475 in Appendix D, which are two mandatory appendixes. While others 476 include a number of informational parts discussing the changes, use 477 cases, different considerations or motivations. 479 2. Protocol Overview 481 This section provides an informative overview of the different 482 mechanisms in the RTSP 2.0 protocol, to give the reader a high level 483 understanding before getting into all the different details. In case 484 of conflict with this description and the later sections, the later 485 sections take precedence. For more information about considered use 486 cases for RTSP see Appendix E. 488 RTSP 2.0 is a bi-directional request and response protocol that first 489 establishes a context including content resources (the media) and 490 then controls the delivery of these content resources from the 491 provider to the consumer. RTSP has three fundamental parts: Session 492 Establishment, Media Delivery Control, and an extensibility model 493 described below. The protocol is based on some assumptions about 494 existing functionality to provide a complete solution for client 495 controlled real-time media delivery. 497 RTSP uses text-based messages, requests and responses, that may 498 contain a binary message body. An RTSP request starts with a method 499 line that identifies the method, the protocol and version and the 500 resource to act on. Following the method line are a number of RTSP 501 headers. This part is ended by two consecutive carriage return line 502 feed (CRLF) character pairs. The message body if present follows the 503 two CRLF and the body's length is described by a message header. 504 RTSP responses are similar, but start with a response line with the 505 protocol and version, followed by a status code and a reason phrase. 506 RTSP messages are sent over a reliable transport protocol between the 507 client and server. RTSP 2.0 requires clients and servers to 508 implement TCP, and TLS over TCP, as mandatory transports for RTSP 509 messages. 511 2.1. Presentation Description 513 RTSP exists to provide access to multi-media presentations and 514 content, but tries to be agnostic about the media type or the actual 515 media delivery protocol that is used. To enable a client to 516 implement a complete system, an RTSP-external mechanism for 517 describing the presentation and the delivery protocol(s) is used. 518 RTSP assumes that this description is either delivered completely out 519 of bands or as a data object in the response to a client's request 520 using the DESCRIBE method (Section 13.2). 522 Parameters that commonly have to be included in the Presentation 523 Description are the following: 525 o Number of media streams; 526 o The resource identifier for each media stream/resource that is to 527 be controlled by RTSP; 529 o The protocol that each media stream is to be delivered over; 531 o Transport protocol parameters that are not negotiated or vary with 532 each client; 534 o Media encoding information enabling a client to correctly decode 535 the media upon reception; 537 o An aggregate control resource identifier. 539 RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media 540 resources and aggregates under common control. 542 This specification describes in Appendix D how one uses SDP [RFC4566] 543 for Presentation Description 545 2.2. Session Establishment 547 The RTSP client can request the establishment of an RTSP session 548 after having used the presentation description to determine which 549 media streams are available, and also which media delivery protocol 550 is used and their particular resource identifiers. The RTSP session 551 is a common context between the client and the server that consists 552 of one or more media resources that are to be under common media 553 delivery control. 555 The client creates an RTSP session by sending a request using the 556 SETUP method (Section 13.3) to the server. In the SETUP request the 557 client also includes all the transport parameters necessary to enable 558 the media delivery protocol to function in the "Transport" header 559 (Section 18.52). This includes parameters that are pre-established 560 by the presentation description but necessary for any middlebox to 561 correctly handle the media delivery protocols. The Transport header 562 in a request may contain multiple alternatives for media delivery in 563 a prioritized list, which the server can select from. These 564 alternatives are typically based on information in the presentation 565 description. 567 The server determines if the media resource is available upon 568 receiving a SETUP request and if any of the transport parameter 569 specifications are acceptable. If that is successful, an RTSP 570 session context is created and the relevant parameters and state is 571 stored. An identifier is created for the RTSP session and included 572 in the response in the Session header (Section 18.47). The SETUP 573 response includes a Transport header that specifies which of the 574 alternatives has been selected and relevant parameters. 576 A SETUP request that references an existing RTSP session but 577 identifies a new media resource is a request to add that media 578 resource under common control with the already present media 579 resources in an aggregated session. A client can expect this to work 580 for all media resources under RTSP control within a multi-media 581 content. However, aggregating resources from different content are 582 likely to be refused by the server. The RTSP session as aggregate is 583 referenced by the aggregate control URI, even if the RTSP session 584 only contains a single media. 586 To avoid an extra round trip in the session establishment of 587 aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., 588 the client can send multiple requests back-to-back without waiting 589 first for the completion of any of them. The client uses client- 590 selected identifier in the Pipelined-Requests header to instruct the 591 server to bind multiple requests together as if they included the 592 session identifier. 594 The SETUP response also provides additional information about the 595 established sessions in a couple of different headers. The Media- 596 Properties header includes a number of properties that apply for the 597 aggregate that is valuable when doing media delivery control and 598 configuring user interface. The Accept-Ranges header informs the 599 client about which range formats that the server supports with these 600 media resources. The Media-Range header inform the client about the 601 time range of the media currently available. 603 2.3. Media Delivery Control 605 After having established an RTSP session, the client can start 606 controlling the media delivery. The basic operations are Start by 607 using the PLAY method (Section 13.4) and Halt by using the PAUSE 608 method (Section 13.6). PLAY also allows for choosing the starting 609 media position from which the server should deliver the media. The 610 positioning is done by using the Range header (Section 18.38) that 611 supports several different time formats: Normal Play Time (NPT) 612 (Section 4.5), SMPTE Timestamps (Section 4.4) and absolute time 613 (Section 4.6). The Range header does further allow the client to 614 specify a position where delivery should end, thus allowing a 615 specific interval to be delivered. 617 The support for positioning/searching within a content depends on the 618 content's media properties. Content exists in a number of different 619 types, such as: on-demand, live, and live with simultaneous 620 recording. Even within these categories there are differences in how 621 the content is generated and distributed, which affect how it can be 622 accessed for playback. The properties applicable for the RTSP 623 session are provided by the server in the SETUP response using the 624 Media-Properties header (Section 18.28). These are expressed using 625 one or several independent attributes. A first attribute is Random 626 Access, which expresses if positioning can be done, and with what 627 granularity. Another aspect is whether the content will change 628 during the lifetime of the session. While on-demand content will 629 provided in full from the beginning, a live stream being recorded 630 results in the length of the accessible content growing as the 631 session goes on. There also exist content that is dynamically built 632 by another protocol than RTSP and thus also changes in steps during 633 the session, but maybe not continuously. Furthermore, when content 634 is recorded, there are cases where not the complete content is 635 maintained, but, for example, only the last hour. All these 636 properties result in the need for mechanisms that will be discussed 637 below. 639 When the client accesses on-demand content that allows random access, 640 the client can issue the PLAY request for any point in the content 641 between the start and the end. The server will deliver media from 642 the closest random access point prior to the requested point and 643 indicate that in its PLAY response. If the client issues a PAUSE, 644 the delivery will be halted and the point at which the server stopped 645 will be reported back in the response. The client can later resume 646 by sending a PLAY request without a range header. When the server is 647 about to complete the PLAY request by delivering the end of the 648 content or the requested range, the server will send a PLAY_NOTIFY 649 request indicating this. 651 When playing live content with no extra functions, such as recording, 652 the client will receive the live media from the server after having 653 sent a PLAY request. Seeking in such content is not possible as the 654 server does not store it, but only forwards it from the source of the 655 session. Thus delivery continues until the client sends a PAUSE 656 request, tears down the session, or the content ends. 658 For live sessions that are being recorded the client will need to 659 keep track of how the recording progresses. Upon session 660 establishment the client will learn the current duration of the 661 recording from the Media-Range header. As the recording is ongoing 662 the content grows in direct relation to the passed time. Therefore, 663 each server's response to a PLAY request will contain the current 664 Media-Range header. The server should also regularly send every 5 665 minutes the current media range in a PLAY_NOTIFY request. If the 666 live transmission ends, the server must send a PLAY_NOTIFY request 667 with the updated Media-Properties indicating that the content stopped 668 being a recorded live session and instead became on-demand content; 669 the request also contains the final media range. While the live 670 delivery continues the client can request to play the current live 671 point by using the NPT timescale symbol "now", or it can request a 672 specific point in the available content by an explicit range request 673 for that point. If the requested point is outside of the available 674 interval the server will adjust the position to the closest available 675 point, i.e., either at the beginning or the end. 677 A special case of recording is that where the recording is not 678 retained longer than a specific time period, thus as the live 679 delivery continues the client can access any media within a moving 680 window that covers, for example, "now" to "now" minus 1 hour. A 681 client that pauses on a specific point within the content may not be 682 able to retrieve the content anymore. If the client waits too long 683 before resuming the pause point, the content may no longer be 684 available. In this case the pause point will be adjusted to the end 685 of the available media. 687 2.4. Session Parameter Manipulations 689 A session may have additional state or functionality that effects how 690 the server or client treats the session, content, how it functions, 691 or feedback on how well the session works. Such extensions are not 692 defined in this specification, but may be done in various extensions. 693 RTSP has two methods for retrieving and setting parameter values on 694 either the client or the server: GET_PARAMETER (Section 13.8) and 695 SET_PARAMETER (Section 13.9). These methods carry the parameters in 696 a message body of the appropriate format. One can also use headers 697 to query state with the GET_PARAMETER method. As an example, clients 698 needing to know the current media-range for a time-progressing 699 session can use the GET_PARAMETER method and include the media-range. 700 Furthermore, synchronization information can be requested by using a 701 combination of RTP-Info and Range. 703 RTSP 2.0 does not have a strong mechanism for providing negotiation 704 of which headers, or parameters and their formats, that can be used. 705 However, responses will indicate request headers or parameters that 706 are not supported. A priori determination of what features are 707 available needs to be done through out-of-band mechanisms, like the 708 session description, or through the usage of feature tags 709 (Section 4.7). 711 2.5. Media Delivery 713 The delivery of media to the RTSP client is done with a protocol 714 outside of RTSP and this protocol is determined during the session 715 establishment. This document specifies how media is delivered with 716 RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP control 717 connection. Additional protocols may be specified in the future 718 based on demand. 720 The usage of RTP as media delivery protocol requires some additional 721 information to function well. The PLAY response contains information 722 to enable reliable and timely delivery of how a client should 723 synchronize different sources in the different RTP sessions. It also 724 provides a mapping between RTP timestamps and the content time scale. 725 When the server wants to notify the client about the completion of 726 the media delivery, it sends a PLAY_NOTIFY request to the client. 727 The PLAY_NOTIFY request includes information about the stream end, 728 including the last RTP sequence number for each stream, thus enabling 729 the client to empty the buffer smoothly. 731 2.5.1. Media Delivery Manipulations 733 The basic playback functionality of RTSP enables delivery of a range 734 of requested content to the client at the pace intended by the 735 content's creator. However, RTSP can also manipulate the delivery to 736 the client in two ways. 738 Scale: The ratio of media content time delivered per unit playback 739 time. 741 Speed: The ratio of playback time delivered per unit of wallclock 742 time. 744 Both affect the media delivery per time unit. However, they 745 manipulate two independent time scales and the effects are possible 746 to combine. 748 Scale is used for fast forward or slow motion control as it changes 749 the amount of content timescale that should be played back per time 750 unit. Scale > 1.0, means fast forward, e.g. Scale=2.0 results in 751 that 2 seconds of content is played back every second of playback. 752 Scale = 1.0 is the default value that is used if no Scale is 753 specified, i.e., playback at the content's original rate. Scale 754 values between 0 and 1.0 is providing for slow motion. Scale can be 755 negative to allow for reverse playback in either regular pace (Scale 756 = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards 757 (-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed. 759 In most cases the realization of scale means server side manipulation 760 of the media to ensure that the client can actually play it back. 761 These media manipulation and when they are needed are highly media- 762 type dependent. Let's consider an example with two common media 763 types audio and video. 765 It is very difficult to modify the playback rate of audio. A maximum 766 of 10-30% is possible by changing the pitch-rate of speech. Music 767 goes out of tune if one tries to manipulate the playback rate by 768 resampling it. This is a well known problem and audio is commonly 769 muted or played back in short segments with skips to keep up with the 770 current playback point. 772 For video it is possible to manipulate the frame rate, although the 773 rendering capabilities are often limited to certain frame rates. 774 Also the allowed bitrates in decoding, the structure used in the 775 encoding and the dependency between frames and other capabilities of 776 the rendering device limits the possible manipulations. Therefore, 777 the basic fast forward capabilities often are implemented by 778 selecting certain subsets of frames. 780 Due to the media restrictions, the possible scale values are commonly 781 restricted to the set of realizable scale ratios. To enable the 782 clients to select from the possible scale values, RTSP can signal the 783 supported Scale ratios for the content. To support aggregated or 784 dynamic content, where this may change during the ongoing session and 785 dependent on the location within the content, a mechanism for 786 updating the media properties and the currently used scale factor 787 exist. 789 Speed affects how much of the playback timeline is delivered in a 790 given wallclock period. The default is Speed = 1 which means to 791 deliver at the same rate the media is consumed. Speed > 1 means that 792 the receiver will get content faster than it regularly would consume 793 it. Speed < 1 means that delivery is slower than the regular media 794 rate. Speed values of 0 or lower have no meaning and are not 795 allowed. This mechanism enables two general functionalities. One is 796 client side scale operations, i.e. the client receives all the frames 797 and makes the adjustment to the playback locally. The second is 798 delivery control for buffering of media. By specifying a speed over 799 1.0 the client can build up the amount of playback time it has 800 present in its buffers to a level that is sufficient for its needs. 802 A naive implementation of Speed would only affect the transmission 803 schedule of the media and has a clear impact on the needed bandwidth. 804 This would result in the data rate being proportional to the speed 805 factor. Speed = 1.5, i.e., 50% faster than normal delivery, would 806 result in a 50% increase in the data transport rate. If that can be 807 supported or not depends solely on the underlying network path. 808 Scale may also have some impact on the required bandwidth due to the 809 manipulation of the content in the new playback schedule. An example 810 is fast forward where only the independently decodable intra frames 811 are included in the media stream. This usage of solely intra frames 812 increases the data rate significantly compared to a normal sequence 813 with the same number of frames, where most frames are encoded using 814 prediction. 816 This potential increase of the data rate needs to be handled by the 817 media sender. The client has requested that the media will be 818 delivered in a specific way, which should be honored. However, the 819 media sender cannot ignore if the network path between the sender and 820 the receiver can't handle the resulting media stream. In that case 821 the media stream needs to be adapted to fit the available resources 822 of the path. This can result in a reduced media quality. 824 The need for bitrate adaptation becomes especially problematic in 825 connection with the Speed semantics. If the goal is to fill up the 826 buffer, the client may not want to do that at the cost of reduced 827 quality. If the client wants to make local playout changes then it 828 may actually require that the requested speed be honored. To resolve 829 this issue, Speed uses a range so that both cases can be supported. 830 The server is requested to use the highest possible speed value 831 within the range which is compatible with the available bandwidth. 832 As long as the server can maintain a speed value within the range it 833 shall not change the media quality, but instead modify the actual 834 delivery rate in response to available bandwidth and reflect this in 835 the Speed value in the response. However, if this is not possible, 836 the server should instead modify the media quality to respect the 837 lowest speed value and the available bandwidth. 839 This functionality enables the local scaling implementation to use a 840 tight range, or even a range where the lower bound equals the upper 841 bound, to identify that it requires the server to deliver the 842 requested amount of media time per delivery time independent of how 843 much it needs to adapt the media quality to fit within the available 844 path bandwidth. For buffer filling, it is suitable to use a range 845 with a reasonable span and with a lower bound at the nominal media 846 rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the 847 buffer, it can specify an upper bound that is below 1.0 to force the 848 server to deliver slower than the nominal media rate. 850 2.6. Session Maintenance and Termination 852 The session context that has been established is kept alive by having 853 the client show liveness. This is done in two main ways: 855 o Media transport protocol keep-alive. RTCP may be used when using 856 RTP. 858 o Any RTSP request referencing the session context. 860 Section 10.5 discusses the methods for showing liveness in more 861 depth. If the client fails to show liveness for more than the 862 established session timeout value (normally 60 seconds), the server 863 may terminate the context. Other values may be selected by the 864 server through the inclusion of the timeout parameter in the session 865 header. 867 The session context is normally terminated by the client sending a 868 TEARDOWN request to the server referencing the aggregated control 869 URI. An individual media resource can be removed from a session 870 context by a TEARDOWN request referencing that particular media 871 resource. If all media resources are removed from a session context, 872 the session context is terminated. 874 A client may keep the session alive indefinitely if allowed by the 875 server; however, it is recommended to release the session context 876 when an extended period of time without media delivery activity has 877 passed. The client can re-establish the session context if required 878 later. What constitutes an extended period of time is dependent on 879 the server and its usage. It is recommended that the client 880 terminates the session before 10*times the session timeout value has 881 passed. A server may terminate the session after one session timeout 882 period without any client activity beyond keep-alive. When a server 883 terminates the session context, it does that by sending a TEARDOWN 884 request indicating the reason. 886 A server can also request that the client tear down the session and 887 re-establish it at an alternative server, as may be needed for 888 maintenance. This is done by using the REDIRECT method. The 889 Terminate-Reason header is used to indicate when and why. The 890 Location header indicates where it should connect if there is an 891 alternative server available. When the deadline expires, the server 892 simply stops providing the service. To achieve a clean closure, the 893 client needs to initiate session termination prior to the deadline. 894 In case the server has no other server to redirect to, and wants to 895 close the session for maintenance, it shall use the TEARDOWN method 896 with a Terminate-Reason header. 898 2.7. Extending RTSP 900 RTSP is quite a versatile protocol which supports extensions in many 901 different directions. Even this core specification contains several 902 blocks of functionality that are optional to implement. The use case 903 and need for the protocol deployment should determine what parts are 904 implemented. Allowing for extensions makes it possible for RTSP to 905 reach out to additional use cases. However, extensions will affect 906 the interoperability of the protocol and therefore it is important 907 that they can be added in a structured way. 909 The client can learn the capability of a server by using the OPTIONS 910 method (Section 13.1) and the Supported header (Section 18.49). It 911 can also try and possibly fail using new methods, or require that 912 particular features are supported using the Require or Proxy-Require 913 header. 915 The RTSP protocol in itself can be extended in three ways, listed 916 here in order of the magnitude of changes supported: 918 o Existing methods can be extended with new parameters, for example, 919 headers, as long as these parameters can be safely ignored by the 920 recipient. If the client needs negative acknowledgment when a 921 method extension is not supported, a tag corresponding to the 922 extension may be added in the field of the Require or Proxy- 923 Require headers (see Section 18.35). 925 o New methods can be added. If the recipient of the message does 926 not understand the request, it must respond with error code 501 927 (Not Implemented) so that the sender can avoid using this method 928 again. A client may also use the OPTIONS method to inquire about 929 methods supported by the server. The server must list the methods 930 it supports using the Public response header. 932 o A new version of the protocol can be defined, allowing almost all 933 aspects (except the position of the protocol version number) to 934 change. A new version of the protocol must be registered through 935 an IETF standard track document. 937 The basic capability discovery mechanism can be used to both discover 938 support for a certain feature and to ensure that a feature is 939 available when performing a request. For a detailed explanation of 940 this see Section 11. 942 New media delivery protocols may be added and negotiated at session 943 establishment, in addition to extensions to the core protocol. 944 Certain types of protocol manipulations can be done through parameter 945 formats using SET_PARAMETER and GET_PARAMETER. 947 3. Document Conventions 949 3.1. Notational Conventions 951 Since a few of the definitions are identical to HTTP/1.1, this 952 specification only points to the section where they are defined 953 rather than copying it. For brevity, [HX.Y] is to be taken to refer 954 to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). 956 All the mechanisms specified in this document are described in both 957 prose and the Augmented Backus-Naur form (ABNF) described in detail 958 in [RFC5234]. 960 Indented and smaller-type paragraphs are used to provide informative 961 background and motivation. This is intended to give readers who were 962 not involved with the formulation of the specification an 963 understanding of why things are the way they are in RTSP. 965 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 966 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 967 "OPTIONAL" in this document are to be interpreted as described in 968 [RFC2119]. 970 The word, "unspecified" is used to indicate functionality or features 971 that are not defined in this specification. Such functionality 972 cannot be used in a standardized manner without further definition in 973 an extension specification to RTSP. 975 3.2. Terminology 977 Aggregate control: The concept of controlling multiple streams using 978 a single timeline, generally maintained by the server. A client, 979 for example, uses aggregate control when it issues a single play 980 or pause message to simultaneously control both the audio and 981 video in a movie. A session which is under aggregate control is 982 referred to as an aggregated session. 984 Aggregate control URI: The URI used in an RTSP request to refer to 985 and control an aggregated session. It normally, but not always, 986 corresponds to the presentation URI specified in the session 987 description. See Section 13.3 for more information. 989 Client: The client requests media service from the media server. 991 Connection: A transport layer virtual circuit established between 992 two programs for the purpose of communication. 994 Container file: A file which may contain multiple media streams 995 which often constitutes a presentation when played together. The 996 concept of a container file is not embedded in the protocol. 997 However, RTSP servers may offer aggregate control on the media 998 streams within these files. 1000 Continuous media: Data where there is a timing relationship between 1001 source and sink; that is, the sink needs to reproduce the timing 1002 relationship that existed at the source. The most common examples 1003 of continuous media are audio and motion video. Continuous media 1004 can be real-time (interactive or conversational), where there is a 1005 "tight" timing relationship between source and sink, or streaming 1006 where the relationship is less strict. 1008 Feature-tag: A tag representing a certain set of functionality, i.e. 1009 a feature. 1011 IRI: Internationalized Resource Identifier, is the same as an URI, 1012 with the exception that it allows characters from the whole 1013 Universal Character Set (Unicode/ISO 10646), rather than the US- 1014 ASCII only. See [RFC3987] for more information. 1016 Live: Normally used to describe a presentation or session with media 1017 coming from an ongoing event. This generally results in the 1018 session having an unbound or only loosely defined duration, and 1019 sometimes no seek operations are possible. 1021 Media initialization: Datatype/codec specific initialization. This 1022 includes such things as clock rates, color tables, etc. Any 1023 transport-independent information which is required by a client 1024 for playback of a media stream occurs in the media initialization 1025 phase of stream setup. 1027 Media parameter: Parameter specific to a media type that may be 1028 changed before or during stream delivery. 1030 Media server: The server providing media delivery services for one 1031 or more media streams. Different media streams within a 1032 presentation may originate from different media servers. A media 1033 server may reside on the same host or on a different host from 1034 which the presentation is invoked. 1036 (Media) stream: A single media instance, e.g., an audio stream or a 1037 video stream as well as a single whiteboard or shared application 1038 group. When using RTP, a stream consists of all RTP and RTCP 1039 packets created by a source within an RTP session. 1041 Message: The basic unit of RTSP communication, consisting of a 1042 structured sequence of octets matching the syntax defined in 1043 Section 20 and transmitted over a connection or a connectionless 1044 transport. A message is either a Request or a Response. 1046 Message Body: The information transferred as the payload of a 1047 message (Request and response). A message body consists of meta- 1048 information in the form of message-body headers and content in the 1049 form of a message-body, as described in Section 9. 1051 Non-Aggregated Control: Control of a single media stream. 1053 Presentation: A set of one or more streams presented to the client 1054 as a complete media feed and described by a presentation 1055 description as defined below. Presentations with more than one 1056 media stream are often handled in RTSP under aggregate control. 1058 Presentation description: A presentation description contains 1059 information about one or more media streams within a presentation, 1060 such as the set of encodings, network addresses and information 1061 about the content. Other IETF protocols such as SDP ([RFC4566]) 1062 use the term "session" for a presentation. The presentation 1063 description may take several different formats, including but not 1064 limited to the session description protocol format, SDP. 1066 Response: An RTSP response to a Request. One type of RTSP message. 1067 If an HTTP response is meant, it is indicated explicitly. 1069 Request: An RTSP request. One type of RTSP message. If an HTTP 1070 request is meant, it is indicated explicitly. 1072 Request-URI: The URI used in a request to indicate the resource on 1073 which the request is to be performed. 1075 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 1076 RTSP proxy. In this specification, there are many capabilities 1077 that are common to these three entities such as the capability to 1078 send requests or receive responses. This term will be used when 1079 describing functionality that is applicable to all three of these 1080 entities. 1082 RTSP session: A stateful abstraction upon which the main control 1083 methods of RTSP operate. An RTSP session is a common context; it 1084 is created and maintained on client's request and can be destroyed 1085 by either the client or server. It is established by an RTSP 1086 server upon the completion of a successful SETUP request (when a 1087 200 OK response is sent) and is labeled with a session identifier 1088 at that time. The session exists until timed out by the server or 1089 explicitly removed by a TEARDOWN request. An RTSP session is a 1090 stateful entity; an RTSP server maintains an explicit session 1091 state machine (see Appendix B) where most state transitions are 1092 triggered by client requests. The existence of a session implies 1093 the existence of state about the session's media streams and their 1094 respective transport mechanisms. A given session can have one or 1095 more media streams associated with it. An RTSP server uses the 1096 session to aggregate control over multiple media streams. 1098 Origin Server: The server on which a given resource resides. 1100 Transport initialization: The negotiation of transport information 1101 (e.g., port numbers, transport protocols) between the client and 1102 the server. 1104 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 1105 RTSP are generally URLs as they give a location for the resource. 1106 As URLs are a subset of URIs, they will be referred to as URIs to 1107 cover also the cases when an RTSP URI would not be an URL. 1109 URL: Universal Resource Locator, is an URI which identifies the 1110 resource through its primary access mechanism, rather than 1111 identifying the resource by name or by some other attribute(s) of 1112 that resource. 1114 4. Protocol Parameters 1116 4.1. RTSP Version 1118 This specification defines version 2.0 of RTSP. 1120 RTSP uses a "." numbering scheme to indicate versions 1121 of the protocol. The protocol versioning policy is intended to allow 1122 the sender to indicate the format of a message and its capacity for 1123 understanding further RTSP communication, rather than the features 1124 obtained via that communication. No change is made to the version 1125 number for the addition of message components which do not affect 1126 communication behavior or which only add to extensible field values. 1128 The number is incremented when the changes made to the 1129 protocol add features which do not change the general message parsing 1130 algorithm, but which may add to the message semantics and imply 1131 additional capabilities of the sender. The number is 1132 incremented when the format of a message within the protocol is 1133 changed. The version of an RTSP message is indicated by an RTSP- 1134 Version field in the first line of the message. Note that the major 1135 and minor numbers MUST be treated as separate integers and that each 1136 MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a 1137 lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. 1138 Leading zeros MUST be ignored by recipients and MUST NOT be sent. 1140 4.2. RTSP IRI and URI 1142 RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and 1143 "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, 1144 and is defined here to register and reserve the URI scheme that is 1145 defined in RTSP 1.0. The "rtspu" scheme indicates unspecified 1146 transport of the RTSP messages over unreliable transport (UDP in RTSP 1147 1.0). An RTSP server MUST response with an error code indicating the 1148 "rtspu" scheme is not implemented (501) to a request that carries a 1149 "rtspu" URI scheme. The details of the syntax of "rtsp" and "rtsps" 1150 URIs has been changed from RTSP 1.0. 1152 This specification also defines the format of the RTSP IRI [RFC3987] 1153 that can be used as RTSP resource identifiers and locators, in web 1154 pages, user interfaces, on paper, etc. However, the RTSP request 1155 message format only allows usage of the absolute URI format. The 1156 RTSP IRI format MUST use the rules and transformation for IRIs to 1157 URIs, as defined in [RFC3987]. This way RTSP 2.0 URIs for request 1158 can be produced from an RTSP IRI. 1160 The RTSP IRI and URI are both syntax restricted compared to the 1161 generic syntax defined in [RFC3986] and [RFC3987]: 1163 o An absolute URI requires the authority part; i.e., a host identity 1164 must be provided. 1166 o Parameters in the path element are prefixed with the reserved 1167 separator ";". 1169 The RTSP URI and IRI are case sensitive, with the exception of those 1170 parts that [RFC3986] and [RFC3987] defines as case-insensitive; for 1171 example, the scheme and host part. 1173 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1174 [RFC3986], i.e. the fragment is to be stripped from the IRI by the 1175 requester and not included in the request URI. The user agent needs 1176 to interpret the value of the fragment based on the media type the 1177 request relates to; i.e., the media type indicated in Content-Type 1178 header in the response to DESCRIBE. 1180 The syntax of any URI query string is unspecified and responder 1181 (usually the server) specific. The query is, from the requester's 1182 perspective, an opaque string and needs to be handled as such. 1183 Please note that relative URI with queries are difficult to handle 1184 due to the RFC 3986 relative URI handling rules. Any change of the 1185 path element using a relative URI results in the stripping of the 1186 query, which means the relative part needs to contain the query. 1188 The URI scheme "rtsp" requires that commands are issued via a 1189 reliable protocol (within the Internet, TCP), while the scheme 1190 "rtsps" identifies a reliable transport using secure transport (TLS 1191 [RFC5246], see (Section 19). 1193 For the scheme "rtsp", if no port number is provided in the authority 1194 part of the URI port number 554 MUST be used. For the scheme 1195 "rtsps", the TCP port 322 is registered and MUST be assumed. 1197 A presentation or a stream is identified by a textual media 1198 identifier, using the character set and escape conventions of URIs 1199 [RFC3986]. URIs may refer to a stream or an aggregate of streams; 1200 i.e., a presentation. Accordingly, requests described in 1201 (Section 13) can apply to either the whole presentation or an 1202 individual stream within the presentation. Note that some request 1203 methods can only be applied to streams, not presentations, and vice 1204 versa. 1206 For example, the RTSP URI: 1208 rtsp://media.example.com:554/twister/audiotrack 1210 may identify the audio stream within the presentation "twister", 1211 which can be controlled via RTSP requests issued over a TCP 1212 connection to port 554 of host media.example.com. 1214 Also, the RTSP URI: 1216 rtsp://media.example.com:554/twister 1218 identifies the presentation "twister", which may be composed of audio 1219 and video streams, but could also be something else like a random 1220 media redirector. 1222 This does not imply a standard way to reference streams in URIs. 1223 The presentation description defines the hierarchical 1224 relationships in the presentation and the URIs for the individual 1225 streams. A presentation description may name a stream "a.mov" and 1226 the whole presentation "b.mov". 1228 The path components of the RTSP URI are opaque to the client and do 1229 not imply any particular file system structure for the server. 1231 This decoupling also allows presentation descriptions to be used 1232 with non-RTSP media control protocols simply by replacing the 1233 scheme in the URI. 1235 4.3. Session Identifiers 1237 Session identifiers are strings of length 8-128 characters. A 1238 session identifier MUST be chosen cryptographically random (see 1239 [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, 1240 i.e. approximately 22 characters from a high quality generator (see 1241 Section 21). However, note that the session identifier does not 1242 provide any security against session hijacking unless it is kept 1243 confidential by the client, server and trusted proxies. 1245 4.4. SMPTE Relative Timestamps 1247 A SMPTE relative timestamp expresses time relative to the start of 1248 the clip. Relative timestamps are expressed as SMPTE time codes for 1249 frame-level access accuracy. The time code has the format 1251 hours:minutes:seconds:frames.subframes, 1253 with the origin at the start of the clip. The default SMPTE format 1254 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1255 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1256 through the use of "smpte-type". For SMPTE 30, the "frames" field in 1257 the time value can assume the values 0 through 29. The difference 1258 between 30 and 29.97 frames per second is handled by dropping the 1259 first two frame indices (values 00 and 01) of every minute, except 1260 every tenth minute. If the frame and the subframe values are zero, 1261 they may be omitted. Subframes are measured in one-hundredth of a 1262 frame. 1264 Examples: 1266 smpte=10:12:33:20- 1267 smpte=10:07:33- 1268 smpte=10:07:00-10:07:33:05.01 1269 smpte-25=10:07:00-10:07:33:05.01 1271 4.5. Normal Play Time 1273 Normal play time (NPT) indicates the stream absolute position 1274 relative to the beginning of the presentation, not to be confused 1275 with the Network Time Protocol (NTP) [RFC5905]. The timestamp 1276 consists of two parts: the mandatory first part may be expressed in 1277 either seconds or hours, minutes, and seconds. The optional second 1278 part consists of a decimal point and decimal figures and indicates 1279 fractions of a second. 1281 The beginning of a presentation corresponds to 0.0 seconds. Negative 1282 values are not defined. 1284 The special constant "now" is defined as the current instant of a 1285 live event. It MAY only be used for live events, and MUST NOT be 1286 used for on-demand (i.e., non-live) content. 1288 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1289 the clock the viewer associates with a program. It is often 1290 digitally displayed on a VCR. NPT advances normally when in normal 1291 play mode (scale = 1), advances at a faster rate when in fast scan 1292 forward (high positive scale ratio), decrements when in scan reverse 1293 (negative scale ratio) and is fixed in pause mode. NPT is 1294 (logically) equivalent to SMPTE time codes." 1296 Examples: 1298 npt=123.45-125 1299 npt=12:05:35.3- 1300 npt=now- 1301 The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec 1302 notation is optimized for automatic generation, the npt-hhmmss 1303 notation for consumption by human readers. The "now" constant 1304 allows clients to request to receive the live feed rather than the 1305 stored or time-delayed version. This is needed since neither 1306 absolute time nor zero time are appropriate for this case. 1308 4.6. Absolute Time 1310 Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, 1311 using UTC (GMT). Fractions of a second may be indicated. 1313 Example for November 8, 1996 at 14h 37 min and 20 and a quarter 1314 seconds UTC: 1316 19961108T143720.25Z 1318 4.7. Feature-Tags 1320 Feature-tags are unique identifiers used to designate features in 1321 RTSP. These tags are used in Require (Section 18.41), Proxy-Require 1322 (Section 18.35), Proxy-Supported (Section 18.36), Supported 1323 (Section 18.49) and Unsupported (Section 18.53) header fields. 1325 A feature-tag definition MUST indicate which combination of clients, 1326 servers or proxies it applies to. 1328 The creator of a new RTSP feature-tag should either prefix the 1329 feature-tag with a reverse domain name (e.g., 1330 "com.example.mynewfeature" is an apt name for a feature whose 1331 inventor can be reached at "example.com"), or register the new 1332 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1333 IANA Section 22). 1335 The usage of feature-tags is further described in Section 11 that 1336 deals with capability handling. 1338 4.8. Message Body Tags 1340 Message body tags are opaque strings that are used to compare two 1341 message bodies from the same resource, for example in caches or to 1342 optimize setup after a redirect. Message body tags can be carried in 1343 the MTag header (see Section 18.30) or in SDP (see Appendix D.1.9). 1344 MTag is similar to ETag in HTTP/1.1. 1346 A message body tag MUST be unique across all versions of all message 1347 bodies associated with a particular resource. A given message body 1348 tag value MAY be used for message bodies obtained by requests on 1349 different URIs. The use of the same message body tag value in 1350 conjunction with message bodies obtained by requests on different 1351 URIs does not imply the equivalence of those message bodies 1353 Message body tags are used in RTSP to make some methods conditional. 1354 The methods are made conditional through the inclusion of headers; 1355 see "If-Match" (Section 18.23) and "If-None-Match" (Section 18.25). 1356 Note that RTSP message body tags apply to the complete presentation; 1357 i.e., both the presentation description and the individual media 1358 streams. Thus message body tags can be used to verify at setup time 1359 after a redirect that the same session description applies to the 1360 media at the new location using the If-Match header. 1362 4.9. Media Properties 1364 When an RTSP server handles media, it is important to consider the 1365 different properties a media instance for delivery and playback can 1366 have. This specification considers the below listed media properties 1367 in its protocol operations. They are derived from the differences 1368 between a number of supported usages. 1370 On-demand: Media that has a fixed (given) duration that doesn't 1371 change during the life time of the RTSP session and is known at 1372 the time of the creation of the session. It is expected that the 1373 content of the media will not change, even if the representation, 1374 i.e encoding, quality, etc, may change. Generally one can seek, 1375 i.e. request any range, within the media. 1377 Dynamic On-demand: This is a variation of the on-demand case where 1378 external methods are used to manipulate the actual content of the 1379 media setup for the RTSP session. The main example is a content 1380 defined by a playlist. 1382 Live: Live media represents a progressing content stream (such as 1383 broadcast TV) where the duration may or may not be known. It is 1384 not seekable, only the content presently being delivered can be 1385 accessed. 1387 Live with Recording: A Live stream that is combined with a server- 1388 side capability to store and retain the content of the live 1389 session, and allow for random access delivery within the part of 1390 the already recorded content. The actual behavior of the media 1391 stream is very much dependent on the retention policy for the 1392 media stream; either the server will be able to capture the 1393 complete media stream, or it will have a limitation in how much 1394 will be retained. The media range will dynamically change as the 1395 session progress. For servers with a limited amount of storage 1396 available for recording, there will typically be a sliding window 1397 that moves forwards while new data is made available and older 1398 data is discarded. 1400 To cover the above usages, the following media properties with 1401 appropriate values are specified: 1403 4.9.1. Random Access and Seeking 1405 Random Access is the ability to specify and get media delivered from 1406 any point inside the content, an operation called seeking. This 1407 possibility is signaled using the Seek-Style header (see 1408 Section 18.45) which can take the following different values: 1410 Random Access: The media is seekable to any out of a large number of 1411 points within the media. Due to media encoding limitations, a 1412 particular point may not be reachable, but seeking to a point 1413 close by is enabled. A floating point number of seconds may be 1414 provided to express the worst case distance between random access 1415 points. 1417 Conditional Random Access: Based on the above Random Access but 1418 intended to handle a case where the distance in the media between 1419 random access points is large, and where small seek forward using 1420 Random Access would move the client further away than the current 1421 point. 1423 Return To Start: Seeking is only possible to the beginning of the 1424 content. 1426 No seeking: Seeking is not possible at all. 1428 4.9.2. Retention 1430 Media may have different retention policies in place that affect the 1431 operation on media. The following different media retention policies 1432 are envisioned and taken into consideration where applicable: 1434 Unlimited: The media will not be removed as long as the RTSP session 1435 is in existence. 1437 Time Limited: The media will not be removed before given wallclock 1438 time. After that time it may or may not be available any more. 1440 Duration limited: Each individual unit of the media will be retained 1441 for the specified duration. 1443 4.9.3. Content Modifications 1445 There is also the question of how the content may change during time 1446 for a given media resource: 1448 Immutable: The content of the media will not change, even if the 1449 representation, i.e., encoding, quality, etc., may change. 1451 Dynamic: Between explicit updates the media content will not change, 1452 but the content may change due to external methods or triggers, 1453 such as playlists. 1455 Time Progressing: As times progresses new content will become 1456 available. If the content also is retained it will become longer 1457 as everything between the start point and the point currently 1458 being made available can be accessed. If the media server uses a 1459 sliding window policy for retention, the start point will also 1460 change as time progresses. 1462 4.9.4. Supported Scale Factors 1464 Content often supports only a limited set or range of scales when 1465 delivering the media.. To enable the client to know what values or 1466 ranges of scale operations that the whole content or the current 1467 position supports, a media properties attribute for this is defined 1468 which contains a list with the values and/or ranges that are 1469 supported. The attribute is named "Scales". It may be updated at 1470 any point in the content due to content consisting of spliced pieces 1471 or content being dynamically updated by out-of-band mechanisms. 1473 4.9.5. Mapping to the Attributes 1475 This section shows examples of how one would map the above usages to 1476 the properties and their values. 1478 On-demand: Random Access: Random Access=5s, Content Modifications: 1479 Immutable, Retention: unlimited or time limited. 1481 Dynamic On-demand: Random Access: Random Access=3s, Content 1482 Modifications: Dynamic, Retention: unlimited or time limited. 1484 Live: Random Access: No seeking, Content Modifications: Time 1485 Progressing, Retention: Duration limited=0.0s 1487 Live with Recording: Random Access: Random Access=3s, Content 1488 Modifications: Time Progressing, Retention: Duration limited=2H 1490 5. RTSP Message 1492 RTSP is a text-based protocol and uses the ISO 10646 character set in 1493 UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. 1495 Text-based protocols make it easier to add optional parameters in 1496 a self-describing manner. Since the number of parameters and the 1497 frequency of commands is low, processing efficiency is not a 1498 concern. Text-based protocols, if done carefully, also allow easy 1499 implementation of research prototypes in scripting languages such 1500 as TCL, Visual Basic and Perl. 1502 The ISO 10646 character set avoids tricky character set switching, 1503 but is invisible to the application as long as US-ASCII is being 1504 used. This is also the encoding used for RTCP [RFC3550]. 1506 Requests contain methods, the object the method is operating upon and 1507 parameters to further describe the method. Methods are idempotent 1508 unless otherwise noted. Methods are also designed to require little 1509 or no state maintenance at the media server. 1511 5.1. Message Types 1513 RTSP messages consist of requests from client to server, or server to 1514 client, and responses in the reverse direction. Request (Section 7) 1515 and Response (Section 8) messages use a format based on the generic 1516 message format of RFC 2822 [RFC2822] for transferring bodies (the 1517 payload of the message). Both types of messages consist of a start- 1518 line, zero or more header fields (also known as "headers"), an empty 1519 line (i.e., a line with nothing preceding the CRLF) indicating the 1520 end of the header, and possibly the data of the message body. 1521 generic-message = start-line 1522 *(message-header CRLF) 1523 CRLF 1524 [ message-body-data ] 1525 start-line = Request-Line | Status-Line 1527 In the interest of robustness, agents MUST ignore any empty line(s) 1528 received where a Request-Line or Response-Line is expected. In other 1529 words, if the agent is reading the protocol stream at the beginning 1530 of a message and receives a CRLF first, it MUST ignore the CRLF. 1532 5.2. Message Headers 1534 RTSP header fields (see Section 18) include general-header, request- 1535 header, response-header, and message-body header fields. 1537 The order in which header fields with differing field names are 1538 received is not significant. However, it is "good practice" to send 1539 general-header fields first, followed by request-header or response- 1540 header fields, and ending with the Message-body header fields. 1542 Multiple message-header fields with the same field-name MAY be 1543 present in a message if and only if the entire field-value for that 1544 header field is defined as a comma-separated list. It MUST be 1545 possible to combine the multiple header fields into one "field-name: 1546 field-value" pair, without changing the semantics of the message, by 1547 appending each subsequent field-value to the first, each separated by 1548 a comma. The order in which header fields with the same field-name 1549 are received is therefore significant to the interpretation of the 1550 combined field value, and thus a proxy MUST NOT change the order of 1551 these field values when a message is forwarded. 1553 Unknown message headers MUST be ignored (skipping over the header to 1554 the next protocol element, and not causing an error) by a RTSP server 1555 or client. An RTSP Proxy MUST forward unknown message headers. 1556 Message headers defined outside of this specification that are 1557 required to be interpreted by the RTSP agent will need to use feature 1558 tags (Section 4.7) and include them in the appropriate Require 1559 (Section 18.41) or Proxy-Require (Section 18.35) header. 1561 5.3. Message Body 1563 The message body (if any) of an RTSP message is used to carry further 1564 information for a particular resource associated with the request or 1565 response. An example of a message body is the Session Description 1566 Protocol (SDP). 1568 The presence of a message body in either a request or a response MUST 1569 be signaled by the inclusion of a Content-Length header (see 1570 Section 18.16). A message body MUST NOT be included in a request or 1571 response if the specification of the particular method (see Method 1572 Definitions (Section 13)) does not allow sending a message body. 1574 5.4. Message Length 1576 When a message body is included in a message, the length of that body 1577 is determined by one of the following (in order of precedence): 1579 1. Any response message which MUST NOT include a message body (such 1580 as the 1xx, 204, and 304 responses) is always terminated by the 1581 first empty line after the header fields, regardless of the 1582 message-header fields present in the message. (Note: An empty 1583 line is a line with nothing preceding the CRLF.) 1585 2. If a Content-Length header(Section 18.16) is present, its value 1586 in bytes represents the length of the message-body. If this 1587 header field is not present, a value of zero is assumed. 1589 Unlike an HTTP message, an RTSP message MUST contain a Content-Length 1590 header whenever it contains a message body. Note that RTSP does not 1591 support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]). 1593 Given the moderate length of presentation descriptions returned, 1594 the server should always be able to determine its length, even if 1595 it is generated dynamically, making the chunked transfer encoding 1596 unnecessary. 1598 6. General Header Fields 1600 General headers are headers that may be used in both requests and 1601 responses. The general headers are listed in Table 1: 1603 +--------------------+--------------------+ 1604 | Header Name | Defined in Section | 1605 +--------------------+--------------------+ 1606 | Accept-Ranges | Section 18.5 | 1607 | | | 1608 | Cache-Control | Section 18.10 | 1609 | | | 1610 | Connection | Section 18.11 | 1611 | | | 1612 | CSeq | Section 18.19 | 1613 | | | 1614 | Date | Section 18.20 | 1615 | | | 1616 | Media-Properties | Section 18.28 | 1617 | | | 1618 | Media-Range | Section 18.29 | 1619 | | | 1620 | Pipelined-Requests | Section 18.32 | 1621 | | | 1622 | Proxy-Supported | Section 18.36 | 1623 | | | 1624 | RTP-Info | Section 18.43 | 1625 | | | 1626 | Seek-Style | Section 18.45 | 1627 | | | 1628 | Supported | Section 18.49 | 1629 | | | 1630 | Timestamp | Section 18.51 | 1631 | | | 1632 | Via | Section 18.55 | 1633 +--------------------+--------------------+ 1635 Table 1: The general headers used in RTSP 1637 7. Request 1639 A request message uses the format outlined below regardless of the 1640 direction of a request, client to server or server to client: 1642 o Request line, containing the method to be applied to the resource, 1643 the identifier of the resource, and the protocol version in use; 1645 o Zero or more Header lines, that can be of the following types: 1646 general headers (Section 6), request headers (Section 7.2), or 1647 message body headers (Section 9.1); 1649 o One empty line (CRLF) to indicate the end of the header section; 1651 o Optionally a message-body, consisting of one or more lines. The 1652 length of the message body in bytes is indicated by the Content- 1653 Length message header. 1655 7.1. Request Line 1657 The request line provides the key information about the request: what 1658 method, on what resources and using which RTSP version. The methods 1659 that are defined by this specification are listed in Table 2. 1661 +---------------+--------------------+ 1662 | Method | Defined in Section | 1663 +---------------+--------------------+ 1664 | DESCRIBE | Section 13.2 | 1665 | | | 1666 | GET_PARAMETER | Section 13.8 | 1667 | | | 1668 | OPTIONS | Section 13.1 | 1669 | | | 1670 | PAUSE | Section 13.6 | 1671 | | | 1672 | PLAY | Section 13.4 | 1673 | | | 1674 | PLAY_NOTIFY | Section 13.5 | 1675 | | | 1676 | REDIRECT | Section 13.10 | 1677 | | | 1678 | SETUP | Section 13.3 | 1679 | | | 1680 | SET_PARAMETER | Section 13.9 | 1681 | | | 1682 | TEARDOWN | Section 13.7 | 1683 +---------------+--------------------+ 1685 Table 2: The RTSP Methods 1687 The syntax of the RTSP request line is the following: 1689 SP SP CRLF 1691 Note: This syntax cannot be freely changed in future versions of 1692 RTSP. This line needs to remain parsable by older RTSP 1693 implementations since it indicates the RTSP version of the message. 1695 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1696 resource through an absolute RTSP URI (including scheme, host, and 1697 port) (see Section 4.2) rather than just the absolute path. 1699 HTTP/1.1 requires servers to understand the absolute URI, but 1700 clients are supposed to use the Host request header. This is 1701 purely needed for backward-compatibility with HTTP/1.0 servers, a 1702 consideration that does not apply to RTSP. 1704 An asterisk "*" can be used instead of an absolute URI in the 1705 Request-URI part to indicate that the request does not apply to a 1706 particular resource, but to the server or proxy itself, and is only 1707 allowed when the request method does not necessarily apply to a 1708 resource. 1710 For example: 1712 OPTIONS * RTSP/2.0 1714 An OPTIONS in this form will determine the capabilities of the server 1715 or the proxy that first receives the request. If the capability of 1716 the specific server needs to be determined, without regard to the 1717 capability of an intervening proxy, the server should be addressed 1718 explicitly with an absolute URI that contains the server's address. 1720 For example: 1722 OPTIONS rtsp://example.com RTSP/2.0 1724 7.2. Request Header Fields 1726 The RTSP headers in Table 3 can be included in a request, as request 1727 headers, to modify the specifics of the request. Some of these 1728 headers may also be used in the response to a request, as response 1729 headers, to modify the specifics of a response (Section 8.2). 1731 +--------------------+--------------------+ 1732 | Header | Defined in Section | 1733 +--------------------+--------------------+ 1734 | Accept | Section 18.1 | 1735 | | | 1736 | Accept-Credentials | Section 18.2 | 1737 | | | 1738 | Accept-Encoding | Section 18.3 | 1739 | | | 1740 | Accept-Language | Section 18.4 | 1741 | | | 1742 | Authorization | Section 18.7 | 1743 | | | 1744 | Bandwidth | Section 18.8 | 1745 | | | 1746 | Blocksize | Section 18.9 | 1747 | | | 1748 | From | Section 18.22 | 1749 | | | 1750 | If-Match | Section 18.23 | 1751 | | | 1752 | If-Modified-Since | Section 18.24 | 1753 | | | 1754 | If-None-Match | Section 18.25 | 1755 | | | 1756 | Notify-Reason | Section 18.31 | 1757 | | | 1758 | Proxy-Require | Section 18.35 | 1759 | | | 1760 | Range | Section 18.38 | 1761 | | | 1762 | Referrer | Section 18.39 | 1763 | | | 1764 | Request-Status | Section 18.40 | 1765 | | | 1766 | Require | Section 18.41 | 1767 | | | 1768 | Scale | Section 18.44 | 1769 | | | 1770 | Session | Section 18.47 | 1771 | | | 1772 | Speed | Section 18.48 | 1773 | | | 1774 | Supported | Section 18.49 | 1775 | | | 1776 | Terminate-Reason | Section 18.50 | 1777 | | | 1778 | Transport | Section 18.52 | 1779 | | | 1780 | User-Agent | Section 18.54 | 1781 +--------------------+--------------------+ 1783 Table 3: The RTSP request headers 1785 Detailed header definition are provided in Section 18 1787 New request headers may be defined. If the receiver of the request 1788 is required to understand the request header, the request MUST 1789 include a corresponding feature tag in a Require or Proxy-Require 1790 header to ensure the processing of the header. 1792 8. Response 1794 After receiving and interpreting a request message, the recipient 1795 responds with an RTSP response message. Normally, there is only one, 1796 final, response. Only responses using the response code class 1xx, 1797 are allowed to send one or more 1xx response messages prior to the 1798 final response message. 1800 The valid response codes and the methods they can be used with are 1801 listed in Table 4. 1803 8.1. Status-Line 1805 The first line of a Response message is the Status-Line, consisting 1806 of the protocol version followed by a numeric status code and the 1807 textual phrase associated with the status code, with each element 1808 separated by SP characters. No CR or LF is allowed except in the 1809 final CRLF sequence. 1811 SP SP CRLF 1813 8.1.1. Status Code and Reason Phrase 1815 The Status-Code element is a 3-digit integer result code of the 1816 attempt to understand and satisfy the request. These codes are fully 1817 defined in Section 17. The Reason-Phrase is intended to give a short 1818 textual description of the Status-Code. The Status-Code is intended 1819 for use by automata and the Reason-Phrase is intended for the human 1820 user. The client is not required to examine or display the Reason- 1821 Phrase. 1823 The first digit of the Status-Code defines the class of response. 1824 The last two digits do not have any categorization role. There are 5 1825 values for the first digit: 1827 1xx: Informational - Request received, continuing process 1829 2xx: Success - The action was successfully received, understood, and 1830 accepted 1832 3rr: Redirection - Further action needs to be taken in order to 1833 complete the request 1835 4xx: Client Error - The request contains bad syntax or cannot be 1836 fulfilled 1838 5xx: Server Error - The server failed to fulfill an apparently valid 1839 request 1841 The individual values of the numeric status codes defined for 1842 RTSP/2.0, and an example set of corresponding Reason-Phrases, are 1843 presented in Table 4. The reason phrases listed here are only 1844 recommended; they may be replaced by local equivalents without 1845 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1846 [RFC2616] status codes and adds RTSP-specific status codes starting 1847 at x50 to avoid conflicts with future HTTP status codes that are 1848 desirable to import into RTSP. 1850 RTSP status codes are extensible. RTSP applications are not required 1851 to understand the meaning of all registered status codes, though such 1852 understanding is obviously desirable. However, applications MUST 1853 understand the class of any status code, as indicated by the first 1854 digit, and treat any unrecognized response as being equivalent to the 1855 x00 status code of that class, with the exception that an 1856 unrecognized response MUST NOT be cached. For example, if an 1857 unrecognized status code of 431 is received by the client, it can 1858 safely assume that there was something wrong with its request and 1859 treat the response as if it had received a 400 status code. In such 1860 cases, user agents SHOULD present to the user the message body 1861 returned with the response, since that message body is likely to 1862 include human-readable information which will explain the unusual 1863 status. 1865 +------+---------------------------------+--------------------------+ 1866 | Code | Reason | Method | 1867 +------+---------------------------------+--------------------------+ 1868 | 100 | Continue | all | 1869 | | | | 1870 | | | | 1871 | 200 | OK | all | 1872 | | | | 1873 | | | | 1874 | 301 | Moved Permanently | all | 1875 | | | | 1876 | 302 | Found | all | 1877 | | | | 1878 | 303 | reserved | n/a | 1879 | | | | 1880 | 304 | Not Modified | all | 1881 | | | | 1882 | 305 | Use Proxy | all | 1883 | | | | 1884 | | | | 1885 | 400 | Bad Request | all | 1886 | 401 | Unauthorized | all | 1887 | | | | 1888 | 402 | Payment Required | all | 1889 | | | | 1890 | 403 | Forbidden | all | 1891 | | | | 1892 | 404 | Not Found | all | 1893 | | | | 1894 | 405 | Method Not Allowed | all | 1895 | | | | 1896 | 406 | Not Acceptable | all | 1897 | | | | 1898 | 407 | Proxy Authentication Required | all | 1899 | | | | 1900 | 408 | Request Timeout | all | 1901 | | | | 1902 | 410 | Gone | all | 1903 | | | | 1904 | 411 | Length Required | all | 1905 | | | | 1906 | 412 | Precondition Failed | DESCRIBE, SETUP | 1907 | | | | 1908 | 413 | Request Message Body Too Large | all | 1909 | | | | 1910 | 414 | Request-URI Too Long | all | 1911 | | | | 1912 | 415 | Unsupported Media Type | all | 1913 | | | | 1914 | 451 | Parameter Not Understood | SET_PARAMETER, | 1915 | | | GET_PARAMETER | 1916 | | | | 1917 | 452 | reserved | n/a | 1918 | | | | 1919 | 453 | Not Enough Bandwidth | SETUP | 1920 | | | | 1921 | 454 | Session Not Found | all | 1922 | | | | 1923 | 455 | Method Not Valid In This State | all | 1924 | | | | 1925 | 456 | Header Field Not Valid | all | 1926 | | | | 1927 | 457 | Invalid Range | PLAY, PAUSE | 1928 | | | | 1929 | 458 | Parameter Is Read-Only | SET_PARAMETER | 1930 | | | | 1931 | 459 | Aggregate Operation Not Allowed | all | 1932 | | | | 1933 | 460 | Only Aggregate Operation | all | 1934 | | Allowed | | 1935 | | | | 1936 | 461 | Unsupported Transport | all | 1937 | | | | 1938 | 462 | Destination Unreachable | all | 1939 | | | | 1940 | 463 | Destination Prohibited | SETUP | 1941 | | | | 1942 | 464 | Data Transport Not Ready Yet | PLAY | 1943 | | | | 1944 | 465 | Notification Reason Unknown | PLAY_NOTIFY | 1945 | | | | 1946 | 466 | Key Management Error | all | 1947 | | | | 1948 | 470 | Connection Authorization | all | 1949 | | Required | | 1950 | | | | 1951 | 471 | Connection Credentials not | all | 1952 | | accepted | | 1953 | | | | 1954 | 472 | Failure to establish secure | all | 1955 | | connection | | 1956 | | | | 1957 | | | | 1958 | 500 | Internal Server Error | all | 1959 | | | | 1960 | 501 | Not Implemented | all | 1961 | | | | 1962 | 502 | Bad Gateway | all | 1963 | | | | 1964 | 503 | Service Unavailable | all | 1965 | | | | 1966 | 504 | Gateway Timeout | all | 1967 | | | | 1968 | 505 | RTSP Version Not Supported | all | 1969 | | | | 1970 | 551 | Option Not Support | all | 1971 +------+---------------------------------+--------------------------+ 1973 Table 4: Status codes and their usage with RTSP methods 1975 8.2. Response Headers 1977 The response-header allows the request recipient to pass additional 1978 information about the response which cannot be placed in the Status- 1979 Line. This header gives information about the server and about 1980 further access to the resource identified by the Request-URI. All 1981 headers currently classified as response headers are listed in 1982 Table 5. 1984 +------------------------+--------------------+ 1985 | Header | Defined in Section | 1986 +------------------------+--------------------+ 1987 | Connection-Credentials | Section 18.12 | 1988 | | | 1989 | Location | Section 18.27 | 1990 | | | 1991 | MTag | Section 18.30 | 1992 | | | 1993 | Proxy-Authenticate | Section 18.33 | 1994 | | | 1995 | Public | Section 18.37 | 1996 | | | 1997 | Range | Section 18.38 | 1998 | | | 1999 | Retry-After | Section 18.42 | 2000 | | | 2001 | Scale | Section 18.44 | 2002 | | | 2003 | Session | Section 18.47 | 2004 | | | 2005 | Server | Section 18.46 | 2006 | | | 2007 | Speed | Section 18.48 | 2008 | | | 2009 | Transport | Section 18.52 | 2010 | | | 2011 | Unsupported | Section 18.53 | 2012 | | | 2013 | WWW-Authenticate | Section 18.56 | 2014 +------------------------+--------------------+ 2016 Table 5: The RTSP response headers 2018 Response-header names can be extended reliably only in combination 2019 with a change in the protocol version. However, the usage of 2020 feature-tags in the request allows the responding party to learn the 2021 capability of the receiver of the response. A new or experimental 2022 header MAY be given the semantics of response-header if all parties 2023 in the communication recognize them to be response-header. 2024 Unrecognized headers in responses are treated as message-headers and 2025 hence MUST be ignored. 2027 9. Message Body 2029 Request and Response messages MAY transfer a message body, if not 2030 otherwise restricted by the request method or response status code. 2031 The message body consists of the content data itself (see also 2032 Section 5.2. 2034 The SET_PARAMETER and GET_PARAMETER request and response, and 2035 DESCRIBE response MAY have a message body. All 4xx and 5xx responses 2036 MAY also have a message body. 2038 In this section, both sender and recipient refer to either the client 2039 or the server, depending on who sends and who receives the message 2040 body. 2042 9.1. Message-Body Header Fields 2044 Message-body header fields define meta-information about the content 2045 data in the message body. The message-body header fields are listed 2046 in Table 6. 2048 +------------------+--------------------+ 2049 | Header | Defined in Section | 2050 +------------------+--------------------+ 2051 | Allow | Section 18.6 | 2052 | | | 2053 | Content-Base | Section 18.13 | 2054 | | | 2055 | Content-Encoding | Section 18.14 | 2056 | | | 2057 | Content-Language | Section 18.15 | 2058 | | | 2059 | Content-Length | Section 18.16 | 2060 | | | 2061 | Content-Location | Section 18.17 | 2062 | | | 2063 | Content-Type | Section 18.18 | 2064 | | | 2065 | Expires | Section 18.21 | 2066 | | | 2067 | Last-Modified | Section 18.26 | 2068 +------------------+--------------------+ 2070 Table 6: The RTSP message-body headers 2072 The extension-header mechanism allows additional message-body header 2073 fields to be defined without changing the protocol, but these fields 2074 cannot be assumed to be recognizable by the recipient. Unrecognized 2075 header fields MUST be ignored by the recipient and forwarded by 2076 proxies. 2078 9.2. Message Body 2080 An RTSP message with a message body MUST include the Content-Type and 2081 Content-Length headers. When a message body is included with a 2082 message, the data type of that content data is determined via the 2083 header fields Content-Type and Content-Encoding. 2085 Content-Type specifies the media type of the underlying data. 2086 Content-Encoding may be used to indicate any additional content 2087 codings applied to the data, usually for the purpose of data 2088 compression, that are a property of the requested resource. There is 2089 no default encoding. 2091 The Content-Length of a message is the length of the content, 2092 measured in bytes. 2094 10. Connections 2096 RTSP requests can be transmitted using the two different connection 2097 scenarios listed below: 2099 o persistent - a transport connection is used for several request/ 2100 response transactions; 2102 o transient - a transport connection is used for a single request/ 2103 response transaction. 2105 RFC 2326 attempted to specify an optional mechanism for transmitting 2106 RTSP messages in connectionless mode over a transport protocol such 2107 as UDP. However, it was not specified in sufficient detail to allow 2108 for interoperable implementations. In an attempt to reduce 2109 complexity and scope, and due to lack of interest, RTSP 2.0 does not 2110 attempt to define a mechanism for supporting RTSP over UDP or other 2111 connectionless transport protocols. A side-effect of this is that 2112 RTSP requests MUST NOT be sent to multicast groups since no 2113 connection can be established with a specific receiver in multicast 2114 environments. 2116 Certain RTSP headers, such as the CSeq header (Section 18.19), which 2117 may appear to be relevant only to connectionless transport scenarios 2118 are still retained and MUST be implemented according to the 2119 specification. In the case of CSeq, it is quite useful for matching 2120 responses to requests if the requests are pipelined (see Section 12). 2121 It is also useful in proxies for keeping track of the different 2122 requests when aggregating several client requests on a single TCP 2123 connection. 2125 10.1. Reliability and Acknowledgements 2127 Since RTSP messages are transmitted using reliable transport 2128 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 2129 Instead, the implementation must rely on the underlying transport to 2130 provide reliability. The RTSP implementation may use any indication 2131 of reception acknowledgment of the message from the underlying 2132 transport protocols to optimize the RTSP behavior. 2134 If both the underlying reliable transport such as TCP and the RTSP 2135 application retransmit requests, each packet loss or message loss 2136 may result in two retransmissions. The receiver typically cannot 2137 take advantage of the application-layer retransmission since the 2138 transport stack will not deliver the application-layer 2139 retransmission before the first attempt has reached the receiver. 2140 If the packet loss is caused by congestion, multiple 2141 retransmissions at different layers will exacerbate the 2142 congestion. 2144 Lack of acknowledgment of an RTSP request should be handled within 2145 the constraints of the connection timeout considerations described 2146 below (Section 10.4). 2148 10.2. Using Connections 2150 A TCP transport can be used for both persistent connections (for 2151 several message exchanges) and transient connections (for a single 2152 message exchange). Implementations of this specification MUST 2153 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 2154 indicates the default port that the server will listen on if the port 2155 is not explicitly given. 2157 A server MUST handle both persistent and transient connections. 2159 Transient connections facilitate mechanisms for fault tolerance. 2160 They also allow for application layer mobility. A server and 2161 client pair that support transient connections can survive the 2162 loss of a TCP connection; e.g., due to a NAT timeout. When the 2163 client has discovered that the TCP connection has been lost, it 2164 can set up a new one when there is need to communicate again. 2166 A persistent connection is RECOMMENDED to be used for all 2167 transactions between the server and client, including messages for 2168 multiple RTSP sessions. However, a persistent connection MAY be 2169 closed after a few message exchanges. For example, a client may use 2170 a persistent connection for the initial SETUP and PLAY message 2171 exchanges in a session and then close the connection. Later, when 2172 the client wishes to send a new request, such as a PAUSE for the 2173 session, a new connection would be opened. This connection may 2174 either be transient or persistent. 2176 An RTSP agent SHOULD NOT have more than one connection to the server 2177 at any given point. If a client or proxy handles multiple RTSP 2178 sessions on the same server, it SHOULD use only one connection for 2179 managing those sessions. 2181 This saves connection resources on the server. It also reduces 2182 complexity by enabling the server to maintain less state about its 2183 sessions and connections. 2185 RTSP allows a server to send requests to a client. However, this can 2186 be supported only if a client establishes a persistent connection 2187 with the server. In cases where a persistent connection does not 2188 exist between a server and its client, due to the lack of a signaling 2189 channel the server may be forced to silently discard RTSP messages, 2190 and may even drop an RTSP session without notifying the client. An 2191 example of such a case is when the server desires to send a REDIRECT 2192 request for an RTSP session to the client but is not able to do so 2193 because it cannot reach the client. A server that attempts to send a 2194 request to a client that has no connection currently to the server 2195 SHOULD discard the request directly, but it MAY queue it for later 2196 delivery. However, if the server queues the request it SHOULD when 2197 adding additional requests to the queue ensure to remove older 2198 requests that are now redundant. 2200 Without a persistent connection between the client and the server, 2201 the media server has no reliable way of reaching the client. 2202 Because the likely failure of server to client established 2203 connections the server will not even attempt establishing any 2204 connection. 2206 The sending of client and server requests can be asynchronous events. 2207 To avoid deadlock situations both client and server MUST be able to 2208 send and receive requests simultaneously. As an RTSP response may be 2209 queued up for transmission, reception or processing behind the peer 2210 RTSP agent's own requests, all RTSP agents are required to have a 2211 certain capability of handling outstanding messages. A potential 2212 issue is that outstanding requests may timeout despite them being 2213 processed by the peer due to the response is caught in the queue 2214 behind a number of request that the RTSP agent is processing but that 2215 take some time to complete. To avoid this problem an RTSP agent is 2216 recommended to buffer incoming messages locally so that any response 2217 messages can be processed immediately upon reception. If responses 2218 are separated from requests and directly forwarded for processing, 2219 not only can the result be used immediately, the state associated 2220 with that outstanding request can also be released. However, 2221 buffering a number of requests on the receiving RTSP agent consumes 2222 resources and enables a resource exhaustion attack on the agent. 2223 Therefore this buffer should be limited so that an unreasonable 2224 number of requests or total message size is not allowed to consume 2225 the receiving agent's resources. In most APIs, having the receiving 2226 agent stop reading from the TCP socket will result in TCP's window 2227 being clamped. Thus forcing the buffering onto the sending agent 2228 when the load is larger than expected. However, as both RTSP message 2229 sizes and frequency may be changed in the future by protocol 2230 extensions, an agent should be careful against taking harsher 2231 measurements against a potential attack. When under attack an RTSP 2232 agent can close TCP connections and release state associated with 2233 that TCP connection. 2235 To provide some guidance on what is reasonable the following 2236 guidelines are given. It is RECOMMENDED that: 2238 o an RTSP agent should not have more than 10 outstanding requests 2239 per RTSP session; 2241 o an RTSP agent should not have more than 10 outstanding requests 2242 that are not related to an RTSP session or that are requesting to 2243 create an RTSP session. 2245 In light of the above, it is RECOMMENDED that clients use persistent 2246 connections whenever possible. A client that supports persistent 2247 connections MAY "pipeline" its requests (see Section 12). 2249 10.3. Closing Connections 2251 The client MAY close a connection at any point when no outstanding 2252 request/response transactions exist for any RTSP session being 2253 managed through the connection. The server, however, SHOULD NOT 2254 close a connection until all RTSP sessions being managed through the 2255 connection have been timed out (Section 18.47). A server SHOULD NOT 2256 close a connection immediately after responding to a session-level 2257 TEARDOWN request for the last RTSP session being controlled through 2258 the connection. Instead, it should wait for a reasonable amount of 2259 time for the client to receive the TEARDOWN response, take 2260 appropriate action, and initiate the connection closing. The server 2261 SHOULD wait at least 10 seconds after sending the TEARDOWN response 2262 before closing the connection. 2264 This is to ensure that the client has time to issue a SETUP for a 2265 new session on the existing connection after having torn the last 2266 one down. 10 seconds should give the client ample opportunity to 2267 get its message to the server. 2269 A server SHOULD NOT close the connection directly as a result of 2270 responding to a request with an error code. 2272 Certain error responses such as "460 Only Aggregate Operation 2273 Allowed" (Section 17.4.25) are used for negotiating capabilities 2274 of a server with respect to content or other factors. In such 2275 cases, it is inefficient for the server to close a connection on 2276 an error response. Also, such behavior would prevent 2277 implementation of advanced/special types of requests or result in 2278 extra overhead for the client when testing for new features. On 2279 the flip side, keeping connections open after sending an error 2280 response poses a Denial of Service security risk (Section 21). 2282 The server MAY close a connection if it receives an incomplete 2283 message and if the message is not completed within a reasonable 2284 amount of time. It is RECOMMENDED that the server waits at least 10 2285 seconds for the completion of a message or for the next part of the 2286 message to arrive (which is an indication that the transport and the 2287 client are still alive). Servers believing they are under attack or 2288 otherwise starved for resources during that event MAY consider using 2289 a shorter timeout. 2291 If a server closes a connection while the client is attempting to 2292 send a new request, the client will have to close its current 2293 connection, establish a new connection and send its request over the 2294 new connection. 2296 An RTSP message SHOULD NOT be terminated by closing the connection. 2297 Such a message MAY be considered to be incomplete by the receiver and 2298 discarded. An RTSP message is properly terminated as defined in 2299 Section 5. 2301 10.4. Timing Out Connections and RTSP Messages 2303 Receivers of a request (responder) SHOULD respond to requests in a 2304 timely manner even when a reliable transport such as TCP is used. 2305 Similarly, the sender of a request (requester) SHOULD wait for a 2306 sufficient time for a response before concluding that the responder 2307 will not be acting upon its request. 2309 A responder SHOULD respond to all requests within 5 seconds. If the 2310 responder recognizes that processing of a request will take longer 2311 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 2312 possible. It SHOULD continue sending a 100 response every 5 seconds 2313 thereafter until it is ready to send the final response to the 2314 requester. After sending a 100 response, the receiver MUST send a 2315 final response indicating the success or failure of the request. 2317 A requester SHOULD wait at least 10 seconds for a response before 2318 concluding that the responder will not be responding to its request. 2319 After receiving a 100 response, the requester SHOULD continue waiting 2320 for further responses. If more than 10 seconds elapses without 2321 receiving any response, the requester MAY assume that the responder 2322 is unresponsive and abort the connection. 2324 A requester SHOULD wait longer than 10 seconds for a response if it 2325 is experiencing significant transport delays on its connection to the 2326 responder. The requester is capable of determining the RTT of the 2327 request/response cycle using the Timestamp header (Section 18.51) in 2328 any RTSP request. 2330 10 seconds was chosen for the following reasons. It gives TCP 2331 time to perform a couple of retransmissions, even if operating on 2332 default values. It is short enough that users may not abandon the 2333 process themselves. However, it should be noted that 10 seconds 2334 can be aggressive on certain type of networks. The 5 seconds 2335 value for 1xx messages is half the timeout giving a reasonable 2336 change of successful delivery before timeout happens on the 2337 requester side. 2339 10.5. Showing Liveness 2341 The mechanisms for showing liveness of the client is, any RTSP 2342 request with a Session header, if RTP & RTCP is used an RTCP message, 2343 or through any other used media protocol capable of indicating 2344 liveness of the RTSP client. It is RECOMMENDED that a client does 2345 not wait to the last second of the timeout before trying to send a 2346 liveness message. The RTSP message may be lost or when using 2347 reliable protocols, such as TCP, the message may take some time to 2348 arrive safely at the receiver. To show liveness between RTSP request 2349 issued to accomplish other things, the following mechanisms can be 2350 used, in descending order of preference: 2352 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 2353 RTCP is used to report transport statistics, it MUST also work 2354 as keep alive. The server can determine the client by network 2355 address and port together with the fact that the client is 2356 reporting on the servers SSRC(s). A downside of using RTCP is 2357 that it only gives statistical guarantees to reach the server. 2358 However, the probability of a false client timeout is so low 2359 that it can be ignored in most cases. For example, assume a 2360 session with 60 seconds timeout and enough bitrate assigned to 2361 RTCP messages to send a message from client to server on 2362 average every 5 seconds. That client has, for a network with 5 2363 % packet loss, the probability to fail showing liveness sign in 2364 that session within the timeout interval of 2.4*E-16. Sessions 2365 with shorter timeouts, or much higher packet loss, or small 2366 RTCP bandwidths SHOULD also use any of the mechanisms below. 2368 SET_PARAMETER: When using SET_PARAMETER for keep alive, no body 2369 SHOULD be included. This method is the RECOMMENDED RTSP method 2370 to use for a request intended only to perform keep-alive. 2372 GET_PARAMETER: When using GET_PARAMETER for keep alive, no body 2373 SHOULD be included. 2375 OPTIONS: This method is also usable, but it causes the server to 2376 perform more unnecessary processing and results in bigger 2377 responses than necessary for the task. The reason is that the 2378 server needs to determine the capabilities associated with the 2379 media resource to correctly populate the Public and Allow 2380 headers. 2382 The timeout parameter MAY be included in a SETUP response, and MUST 2383 NOT be included in requests. The server uses it to indicate to the 2384 client how long the server is prepared to wait between RTSP commands 2385 or other signs of life before closing the session due to lack of 2386 activity (see Appendix B). The timeout is measured in seconds, with 2387 a default of 60 seconds. The length of the session timeout MUST NOT 2388 be changed in an established session. 2390 10.6. Use of IPv6 2392 Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC 2393 2326). RTSP 2.0 has been updated for explicit IPv6 support. 2394 Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in 2395 URIs and headers. 2397 10.7. Overload Control 2399 Overload in RTSP can occur when servers and proxies have insufficient 2400 resources to complete the processing of a request. An improper 2401 handling of such an overload situation at proxies and servers can 2402 impact the operation of the RTSP deployment, and probably worsen the 2403 situation. RTSP defines the 503 (Service Unavailable) response 2404 (Section 17.5.4) to let servers and proxies notify requesting proxies 2405 and RTSP clients about an overload situation. In conjunction with 2406 the Retry-After header (Section 18.42) the server or proxy can 2407 indicate the time after the requesting entity can send another 2408 request to the proxy or server. 2410 Simply implementing and using the 503 (Service Unavailable) is not 2411 sufficient for properly handling overload situations. For instance, 2412 a simplistic approach would be to send the 503 response with a Retry- 2413 After header set to a fixed value. However, this can cause the 2414 situation where multiple RTSP clients again send requests to a proxy 2415 or server at roughly the same time which may again cause an overload 2416 situation, or if the "old" overload situation is not yet solved, 2417 i.e., the length indicated in the Retry-After header was too short. 2419 An RTSP server or proxy in an overload situation must select the 2420 value of the Retry-After header carefully and in dependency of its 2421 current load situation. It is RECOMMENDED to increase the length 2422 proportional with the current load of the server, i.e., an increasing 2423 workload should result in an increased length of the indicated 2424 unavailability. It is RECOMMENDED to not send the same value in the 2425 Retry-After header to all requesting proxies and clients, but to add 2426 a variation to the mean value of the Retry-After header. 2428 Another issue are load balancing RTSP proxies, i.e., where an RTSP 2429 proxy is used to select amongst a set of RTSP servers to handle the 2430 requests, or when multiple server addresses are available for a given 2431 server name. The proxy or client may receive a 503 (Service 2432 Unavailable) from one of its RTSP servers or a TCP timeout (if the 2433 server is even unable to handled the request message). The proxy or 2434 client simply retries the other addresses, but may also receive a 503 2435 (Service Unavailable) response or TCP timeouts from those addresses. 2436 In such a situation, where none of the RTSP servers/addresses can 2437 handle the request, the RTSP agent has to wait before it can send any 2438 new requests to the RTSP server. Any additional request to a 2439 specific address MUST be delayed according to the Retry-After headers 2440 received. For addresses where no response was received or TCP 2441 timeout occurred, an initial wait timer SHOULD be set to 5 seconds. 2442 That timer MUST be doubled for each additional failure to connect or 2443 receive response. It is RECOMMENDED to not set the same value in the 2444 timer, but to add a variation to the mean value. 2446 11. Capability Handling 2448 This section describes the available capability handling mechanism 2449 which allows RTSP to be extended. Extensions to this version of the 2450 protocol are basically done in two ways. First, new headers can be 2451 added. Secondly, new methods can be added. The capability handling 2452 mechanism is designed to handle both cases. 2454 When a method is added, the involved parties can use the OPTIONS 2455 method to discover whether it is supported. This is done by issuing 2456 an OPTIONS request to the other party. Depending on the URI it will 2457 either apply in regards to a certain media resource, the whole server 2458 in general, or simply the next hop. The OPTIONS response MUST 2459 contain a Public header which declares all methods supported for the 2460 indicated resource. 2462 It is not necessary to use OPTIONS to discover support of a method, 2463 as the client could simply try the method. If the receiver of the 2464 request does not support the method it will respond with an error 2465 code indicating the method is either not implemented (501) or does 2466 not apply for the resource (405). The choice between the two 2467 discovery methods depends on the requirements of the service. 2469 Feature-Tags are defined to handle functionality additions that are 2470 not new methods. Each feature-tag represents a certain block of 2471 functionality. The amount of functionality that a feature-tag 2472 represents can vary significantly. A feature-tag can for example 2473 represent the functionality a single RTSP header provides. Another 2474 feature-tag can represent much more functionality, such as the 2475 "play.basic" feature-tag which represents the minimal media delivery 2476 for playback implementation. 2478 Feature-tags are used to determine whether the client, server or 2479 proxy supports the functionality that is necessary to achieve the 2480 desired service. To determine support of a feature-tag, several 2481 different headers can be used, each explained below: 2483 Supported: This header is used to determine the complete set of 2484 functionality that both client and server have. The intended 2485 usage is to determine before one needs to use a functionality 2486 that it is supported. It can be used in any method, but 2487 OPTIONS is the most suitable one as it at the same time 2488 determines all methods that are implemented. When sending a 2489 request the requester declares all its capabilities by 2490 including all supported feature-tags. This results in the 2491 receiver learns the requester's feature support. The receiver 2492 then includes its set of features in the response. 2494 Proxy-Supported: This header is used similarly to the Supported 2495 header, but instead of giving the supported functionality of 2496 the client or server it provides both the requester and the 2497 responder a view of what functionality the proxy chain between 2498 the two supports. Proxies are required to add this header 2499 whenever the Supported header is present, but proxies may also 2500 add it independently of the requester. 2502 Require: This header can be included in any request where the end- 2503 point, i.e. the client or server, is required to understand the 2504 feature to correctly perform the request. This can, for 2505 example, be a SETUP request where the server is required to 2506 understand a certain parameter to be able to set up the media 2507 delivery correctly. Ignoring this parameter would not have the 2508 desired effect and is not acceptable. Therefore the end-point 2509 receiving a request containing a Require MUST negatively 2510 acknowledge any feature that it does not understand and not 2511 perform the request. The response in cases where features are 2512 not supported are 551 (Option Not Supported). Also the 2513 features that are not supported are given in the Unsupported 2514 header in the response. 2516 Proxy-Require: This header has the same purpose and workings as 2517 Require except that it only applies to proxies and not the end- 2518 point. Features that need to be supported by both proxies and 2519 end-points need to be included in both the Require and Proxy- 2520 Require header. 2522 Unsupported: This header is used in a 551 error response, to 2523 indicate which features were not supported. Such a response is 2524 only the result of the usage of the Require and/or Proxy- 2525 Require header where one or more feature where not supported. 2526 This information allows the requester to make the best of 2527 situations as it knows which features are not supported. 2529 12. Pipelining Support 2531 Pipelining is a general method to improve performance of request 2532 response protocols by allowing the requesting agent to have more than 2533 one request outstanding and send them over the same persistent 2534 connection. For RTSP, where the relative order of requests will 2535 matter, it is important to maintain the order of the requests. 2536 Because of this, the responding agent MUST process the incoming 2537 requests in their sending order. The sending order can be determined 2538 by the CSeq header and its sequence number. For TCP the delivery 2539 order will be the same as the sending order. The processing of the 2540 request MUST also have been finished before processing the next 2541 request from the same agent. The responses MUST be sent in the order 2542 the requests were processed. 2544 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2545 The major improvement is to allow all requests to setup and initiate 2546 media delivery to be pipelined after each other. This is 2547 accomplished by the utilization of the Pipelined-Requests header (see 2548 Section 18.32). This header allows a client to request that two or 2549 more requests are processed in the same RTSP session context which 2550 the first request creates. In other words, a client can request that 2551 two or more media streams are set-up and then played without needing 2552 to wait for a single response. This speeds up the initial startup 2553 time for an RTSP session with at least one RTT. 2555 If a pipelined request builds on the successful completion of one or 2556 more prior requests the requester must verify that all requests were 2557 executed as expected. A common example will be two SETUP requests 2558 and a PLAY request. In case one of the SETUP fails unexpectedly, the 2559 PLAY request can still be successfully executed. However, the 2560 resulting presentation will not be as expected by the requesting 2561 client, as only a single media instead of two will be played. In 2562 this case the client can send a PAUSE request, correct the failing 2563 SETUP request and then request it to be played. 2565 13. Method Definitions 2567 The method indicates what is to be performed on the resource 2568 identified by the Request-URI. The method name is case-sensitive. 2569 New methods may be defined in the future. Method names MUST NOT 2570 start with a $ character (decimal 36) and MUST be a token as defined 2571 by the ABNF [RFC5234] in the syntax chapter Section 20. The methods 2572 are summarized in Table 7. 2574 +---------------+-----------+--------+-------------+-------------+ 2575 | method | direction | object | Server req. | Client req. | 2576 +---------------+-----------+--------+-------------+-------------+ 2577 | DESCRIBE | C -> S | P,S | recommended | recommended | 2578 | | | | | | 2579 | GET_PARAMETER | C -> S | P,S | optional | optional | 2580 | | | | | | 2581 | | S -> C | P,S | optional | optional | 2582 | | | | | | 2583 | OPTIONS | C -> S | P,S | required | required | 2584 | | | | | | 2585 | | S -> C | P,S | optional | optional | 2586 | | | | | | 2587 | PAUSE | C -> S | P,S | required | required | 2588 | | | | | | 2589 | PLAY | C -> S | P,S | required | required | 2590 | | | | | | 2591 | PLAY_NOTIFY | S -> C | P,S | required | required | 2592 | | | | | | 2593 | REDIRECT | S -> C | P,S | optional | required | 2594 | | | | | | 2595 | SETUP | C -> S | S | required | required | 2596 | | | | | | 2597 | SET_PARAMETER | C -> S | P,S | required | optional | 2598 | | | | | | 2599 | | S -> C | P,S | optional | optional | 2600 | | | | | | 2601 | TEARDOWN | C -> S | P,S | required | required | 2602 | | | | | | 2603 | | S -> C | P | required | required | 2604 +---------------+-----------+--------+-------------+-------------+ 2606 Table 7: Overview of RTSP methods, their direction, and what objects 2607 (P: presentation, S: stream) they operate on. 2609 Note on Table 7: GET_PARAMETER is optional. For example, a fully 2610 functional server can be built to deliver media without any 2611 parameters. SET_PARAMETER is required, however, due to its usage 2612 for keep-alive. PAUSE is now required because it is the only way 2613 of leaving the Play state without terminating the whole session. 2615 If an RTSP agent does not support a particular method, it MUST return 2616 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2617 NOT try this method again for the given agent / resource combination. 2618 An RTSP proxy whose main function is to log or audit and not modify 2619 transport or media handling in any way MAY forward RTSP messages with 2620 unknown methods. Note that the proxy still needs to perform the 2621 minimal required processing, like adding the Via header. 2623 13.1. OPTIONS 2625 The semantics of the RTSP OPTIONS method is similar to that of the 2626 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2627 bi-directional, in that a client can request it to a server and vice 2628 versa. A client MUST implement the capability to send an OPTIONS 2629 request and a server or a proxy MUST implement the capability to 2630 respond to an OPTIONS request. The client, server or proxy MAY also 2631 implement the converse of their required capability, but still retain 2632 the prior mentioned about what is a "MUST implement". 2634 An OPTIONS request may be issued at any time. Such a request does 2635 not modify the session state. However, it may prolong the session 2636 lifespan (see below). The URI in an OPTIONS request determines the 2637 scope of the request and the corresponding response. If the Request- 2638 URI refers to a specific media resource on a given host, the scope is 2639 limited to the set of methods supported for that media resource by 2640 the indicated RTSP agent. A Request-URI with only the host address 2641 limits the scope to the specified RTSP agent's general capabilities 2642 without regard to any specific media. If the Request-URI is an 2643 asterisk ("*"), the scope is limited to the general capabilities of 2644 the next hop (i.e. the RTSP agent in direct communication with the 2645 request sender). 2647 Regardless of scope of the request, the Public header MUST always be 2648 included in the OPTIONS response listing the methods that are 2649 supported by the responding RTSP agent. In addition, if the scope of 2650 the request is limited to a media resource, the Allow header MUST be 2651 included in the response to enumerate the set of methods that are 2652 allowed for that resource unless the set of methods completely 2653 matches the set in the Public header. If the given resource is not 2654 available, the RTSP agent SHOULD return an appropriate response code 2655 such as 3rr or 4xx. The Supported header MAY be included in the 2656 request to query the set of features that are supported by the 2657 responding RTSP agent. 2659 The OPTIONS method can be used to keep an RTSP session alive. 2660 However, this is not the preferred way of session keep-alive 2661 signaling, see Section 18.47. An OPTIONS request intended for 2662 keeping alive an RTSP session MUST include the Session header with 2663 the associated session ID. Such a request SHOULD also use the media 2664 or the aggregated control URI as the Request-URI. 2666 Example: 2668 C->S: OPTIONS rtsp://server.example.com RTSP/2.0 2669 CSeq: 1 2670 User-Agent: PhonyClient/1.2 2671 Proxy-Require: gzipped-messages 2672 Supported: play.basic 2674 S->C: RTSP/2.0 200 OK 2675 CSeq: 1 2676 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS 2677 Supported: play.basic, setup.rtp.rtcp.mux, play.scale 2678 Server: PhonyServer/1.1 2680 Note that some of the feature-tags in Supported and Proxy-Require are 2681 fictional features. 2683 13.2. DESCRIBE 2685 The DESCRIBE method is used to retrieve the description of a 2686 presentation or media object from a server. The Request-URI of the 2687 DESCRIBE request identifies the media resource of interest. The 2688 client MAY include the Accept header in the request to list the 2689 description formats that it understands. The server MUST respond 2690 with a description of the requested resource and return the 2691 description in the message body of the response, if the DESCRIBE 2692 method request can be successfully fulfilled. The DESCRIBE reply- 2693 response pair constitutes the media initialization phase of RTSP. 2695 The DESCRIBE response SHOULD contain all media initialization 2696 information for the resource(s) that it describes. Servers SHOULD 2697 NOT use the DESCRIBE response as a means of media indirection by 2698 having the description point at another server; instead, using the 2699 3rr responses is RECOMMENDED. 2701 By forcing a DESCRIBE response to contain all media initialization 2702 information for the set of streams that it describes, and 2703 discouraging the use of DESCRIBE for media indirection, any 2704 looping problems can be avoided that might have resulted from 2705 other approaches. 2707 Example: 2709 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2710 CSeq: 312 2711 User-Agent: PhonyClient/1.2 2712 Accept: application/sdp, application/example 2714 S->C: RTSP/2.0 200 OK 2715 CSeq: 312 2716 Date: Thu, 23 Jan 1997 15:35:06 GMT 2717 Server: PhonyServer/1.1 2718 Content-Base: rtsp://server.example.com/fizzle/foo/ 2719 Content-Type: application/sdp 2720 Content-Length: 358 2722 v=0 2723 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 2724 s=SDP Seminar 2725 i=A Seminar on the session description protocol 2726 u=http://www.example.com/lectures/sdp.ps 2727 e=seminar@example.com (Seminar Management) 2728 c=IN IP4 0.0.0.0 2729 a=control:* 2730 t=2873397496 2873404696 2731 m=audio 3456 RTP/AVP 0 2732 a=control:audio 2733 m=video 2232 RTP/AVP 31 2734 a=control:video 2736 Media initialization is a requirement for any RTSP-based system, but 2737 the RTSP specification does not dictate that this is required to be 2738 done via the DESCRIBE method. There are three ways that an RTSP 2739 client may receive initialization information: 2741 o via an RTSP DESCRIBE request 2743 o via some other protocol (HTTP, email attachment, etc.) 2745 o via some form of user interface 2747 If a client obtains a valid description from an alternate source, the 2748 client MAY use this description for initialization purposes without 2749 issuing a DESCRIBE request for the same media. The client should use 2750 any MTag to either validate the presentation description or make the 2751 session establishment conditional on being valid. 2753 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2754 and highly recommended that minimal clients support the ability to 2755 act as "helper applications" that accept a media initialization file 2756 from a user interface, and/or other means that are appropriate to the 2757 operating environment of the clients. 2759 13.3. SETUP 2761 Note: The states described in this section and the following are 2762 described in detail in Appendix B. 2764 The SETUP request for an URI specifies the transport mechanism to be 2765 used for the streamed media. The SETUP method may be used in two 2766 different cases; Create an RTSP session and change the transport 2767 parameters of already set up media stream. SETUP can be used in all 2768 three states; Init, and Ready, for both purposes and in PLAY to 2769 change the transport parameters. There is also a third possible 2770 usage for the SETUP method which is not specified in this memo: 2771 adding a media to a session. Using SETUP to add media to an existing 2772 session, when the session is in Play state, is unspecified. 2774 The Transport header, see Section 18.52, specifies the media 2775 transport parameters acceptable to the client for data transmission; 2776 the response will contain the transport parameters selected by the 2777 server. This allows the client to enumerate in descending order of 2778 preference the transport mechanisms and parameters acceptable to it, 2779 while the server can select the most appropriate. It is expected 2780 that the session description format used will enable the client to 2781 select a limited number of possible configurations that are offered 2782 to the server to choose from. All transport related parameters SHALL 2783 be included in the Transport header; the use of other headers for 2784 this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls 2785 or NATs. 2787 For the benefit of any intervening firewalls, a client MUST indicate 2788 the known transport parameters, even if it has no influence over 2789 these parameters, for example, where the server advertises a fixed 2790 multicast address as destination. 2792 Since SETUP includes all transport initialization information, 2793 firewalls and other intermediate network devices (which need this 2794 information) are spared the more arduous task of parsing the 2795 DESCRIBE response, which has been reserved for media 2796 initialization. 2798 The client MUST include the Accept-Ranges header in the request 2799 indicating all supported unit formats in the Range header. This 2800 allows the server to know which formats it may use in future session 2801 related responses, such as a PLAY response without any range in the 2802 request. If the client does not support a time format necessary for 2803 the presentation the server MUST respond using 456 (Header Field Not 2804 Valid for Resource) and include the Accept-Ranges header with the 2805 range unit formats supported for the resource. 2807 In a SETUP response the server MUST include the Accept-Ranges header 2808 (see Section 18.5) to indicate which time formats are acceptable to 2809 use for this media resource. 2811 The SETUP response 200 OK MUST include the Media-Properties header 2812 (see Section 18.28 ). The combination of the parameters of the 2813 Media-Properties header indicates the nature of the content present 2814 in the session (see also Section 4.9). For example, a live stream 2815 with time shifting is indicated by 2817 o Random Access set to Random-Access, 2819 o Content Modifications set to Time Progressing, 2821 o Retention set to Time-Duration (with specific recording window 2822 time value). 2824 The SETUP response 200 OK MUST include the Media-Range header (see 2825 Section 18.29) if the media is Time-Progressing. 2827 A basic example for SETUP: 2829 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 2830 CSeq: 302 2831 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 2832 RTP/AVP/TCP;unicast;interleaved=0-1 2833 Accept-Ranges: NPT, UTC 2834 User-Agent: PhonyClient/1.2 2836 S->C: RTSP/2.0 200 OK 2837 CSeq: 302 2838 Date: Thu, 23 Jan 1997 15:35:06 GMT 2839 Server: PhonyServer/1.1 2840 Session: 47112344;timeout=60 2841 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ 2842 "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ 2843 "198.51.100.241:6257"; ssrc=2A3F93ED 2844 Accept-Ranges: NPT 2845 Media-Properties: Random-Access=3.2, Time-Progressing, 2846 Time-Duration=3600.0 2847 Media-Range: npt=0-2893.23 2849 In the above example the client wants to create an RTSP session 2850 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 2851 The transport parameters acceptable to the client are either RTP/AVP/ 2852 UDP (UDP per default) to be received on client port 4588 and 4589 at 2853 the address the RTSP setup connection comes from or RTP/AVP 2854 interleaved on the RTSP control channel. The server selects the RTP/ 2855 AVP/UDP transport and adds the address and ports it will send and 2856 receive RTP and RTCP from, and the RTP SSRC that will be used by the 2857 server. 2859 The server MUST generate a session identifier in response to a 2860 successful SETUP request, unless a SETUP request to a server includes 2861 a session identifier or a Pipelined-Requests header referencing an 2862 existing session context, in which case the server MUST bundle this 2863 setup request into the existing session (aggregated session) or 2864 return error 459 (Aggregate Operation Not Allowed) (see 2865 Section 17.4.24). An Aggregate control URI MUST be used to control 2866 an aggregated session. This URI MUST be different from the stream 2867 control URIs of the individual media streams included in the 2868 aggregate (see Section 13.4.2 for aggregated sessions and for the 2869 particular URIs see Appendix D.1.1). The Aggregate control URI is to 2870 be specified by the session description if the server supports 2871 aggregated control and aggregated control is desired for the session. 2872 However, even if aggregated control is offered the client MAY chose 2873 to not set up the session in aggregated control. If an Aggregate 2874 control URI is not specified in the session description, it is 2875 normally an indication that non-aggregated control should be used. 2876 The SETUP of media streams in an aggregate which has not been given 2877 an aggregated control URI is unspecified. 2879 While the session ID sometimes carries enough information for 2880 aggregate control of a session, the Aggregate control URI is still 2881 important for some methods such as SET_PARAMETER where the control 2882 URI enables the resource in question to be easily identified. The 2883 Aggregate control URI is also useful for proxies, enabling them to 2884 route the request to the appropriate server, and for logging, 2885 where it is useful to note the actual resource that a request was 2886 operating on. 2888 A session will exist until it is either removed by a TEARDOWN request 2889 or is timed-out by the server. The server MAY remove a session that 2890 has not demonstrated liveness signs from the client(s) within a 2891 certain timeout period. The default timeout value is 60 seconds; the 2892 server MAY set this to a different value and indicate so in the 2893 timeout field of the Session header in the SETUP response. For 2894 further discussion see Section 18.47. Signs of liveness for an RTSP 2895 session are: 2897 o Any RTSP request from a client which includes a Session header 2898 with that session's ID. 2900 o If RTP is used as a transport for the underlying media streams, an 2901 RTCP sender or receiver report from the client(s) for any of the 2902 media streams in that RTSP session. RTCP Sender Reports may for 2903 example be received in sessions where the server is invited into a 2904 conference session and is valid for keep-alive. 2906 If a SETUP request on a session fails for any reason, the session 2907 state, as well as transport and other parameters for associated 2908 streams MUST remain unchanged from their values as if the SETUP 2909 request had never been received by the server. 2911 13.3.1. Changing Transport Parameters 2913 A client MAY issue a SETUP request for a stream that is already set 2914 up or playing in the session to change transport parameters, which a 2915 server MAY allow. If it does not allow changing of parameters, it 2916 MUST respond with error 455 (Method Not Valid In This State). The 2917 reasons to support changing transport parameters include allowing 2918 application layer mobility and flexibility to utilize the best 2919 available transport as it becomes available. If a client receives a 2920 455 when trying to change transport parameters while the server is in 2921 Play state, it MAY try to put the server in ready state using PAUSE, 2922 before issuing the SETUP request again. If that also fails the 2923 changing of transport parameters will require that the client 2924 performs a TEARDOWN of the affected media and then to set it up 2925 again. For an aggregated session avoiding tearing down all the media 2926 at the same time will avoid the creation of a new session. 2928 All transport parameters MAY be changed. However, the primary usage 2929 expected is to either change the transport protocol completely, like 2930 switching from Interleaved TCP mode to UDP or vice versa, or to 2931 change the delivery address. 2933 In a SETUP response for a request to change the transport parameters 2934 while in Play state, the server MUST include the Range to indicate at 2935 what point the new transport parameters will be used. Further, if 2936 RTP is used for delivery, the server MUST also include the RTP-Info 2937 header to indicate at what timestamp and RTP sequence number the 2938 change will take place. If both RTP-Info and Range are included in 2939 the response the "rtp_time" parameter and start point in the Range 2940 header MUST be for the corresponding time, i.e. be used in the same 2941 way as for PLAY to ensure the correct synchronization information is 2942 available. 2944 If the transport parameters change while in Play state results in a 2945 change of synchronization related information, for example changing 2946 RTP SSRC, the server MUST provide in the SETUP response the necessary 2947 synchronization information. However, the server is RECOMMENDED to 2948 avoid changing the synchronization information if possible. 2950 13.4. PLAY 2952 This section describes the usage of the PLAY method in general, for 2953 aggregated sessions, and in different usage scenarios. 2955 13.4.1. General Usage 2957 The PLAY method tells the server to start sending data via the 2958 mechanism specified in SETUP and which part of the media should be 2959 played out. PLAY requests are valid when the session is in Ready or 2960 Play states. A PLAY request MUST include a Session header to 2961 indicate which session the request applies to. 2963 Upon receipt of the PLAY request, the server MUST position the normal 2964 play time to the beginning of the range specified in the received 2965 Range header and deliver stream data until the end of the range if 2966 given, until a new PLAY request is received, or until the end of the 2967 media is reached. If no Range header is present in the PLAY request 2968 the server SHALL play from current pause point until the end of 2969 media. The pause point defaults at session start to the beginning of 2970 the media. For media that is time-progressing and has no retention, 2971 the pause point will always be set equal to NPT "now", i.e., the 2972 current delivery point. The pause point may also be set to a 2973 particular point in the media by the PAUSE method, see Section 13.6. 2974 The pause point for media that is currently playing is equal to the 2975 current media position. For time-progressing media with time-limited 2976 retention, if the pause point represents a position that is older 2977 than what is retained by the server, the pause point will be moved to 2978 the oldest retained. 2980 What range values are valid depends on the type of content. For 2981 content that isn't time progressing the range value is valid if the 2982 given range is part of any media within the aggregate. In other 2983 words the valid media range for the aggregate is the union of all of 2984 the media components in the aggregate. If a given range value points 2985 outside of the media, the response MUST be the 457 (Invalid Range) 2986 error code and include the Media-Range header (Section 18.29) with 2987 the valid range for the media. Except for time progressing content 2988 where the client requests a start point prior to what is retained, 2989 the start point is adjusted to the oldest retained content. For a 2990 start point that is beyond the media front edge, i.e. beyond the 2991 current value for "now", the server SHALL adjust the start value to 2992 the current front edge. The Range header's stop point value may 2993 point beyond the current media edge. In that case, the server SHALL 2994 deliver media from the requested (and possibly adjusted) start point 2995 until the provided stop point, or the end of the media is reached 2996 prior to the specified stop point. Please note that if one simply 2997 wants to play from a particular start point until the end of media 2998 using a Range header with an implicit stop point is RECOMMENDED. 3000 If a client requests to start playing at the end of media, either 3001 explicitly with a Range header or implicitly with a pause point that 3002 is at the end of media, a 457 (Invalid Range) error MUST be sent and 3003 include the Media-Range header (Section 18.29). It is specified 3004 below that the Range header also must be included in the response and 3005 that it will carry the pause point in the media, in the case of the 3006 session being in Ready State. Note that this also applies if the 3007 pause point or requested start point is at the beginning of the media 3008 and a Scale header (Section 18.44) is included with a negative value 3009 (playing backwards). 3011 For media with random access properties a client may express its 3012 preference on which policy for start point selection the server shall 3013 use. This is done by including the Seek-Style header (Section 18.45) 3014 in the PLAY request. The Seek-Style applied will effect the content 3015 of the Range header as it will be adjusted to indicate from what 3016 point the media actually is delivered. 3018 A client desiring to play the media from the beginning MUST send a 3019 PLAY request with a Range header pointing at the beginning, e.g. 3020 npt=0-. If a PLAY request is received without a Range header and 3021 media delivery has stopped at the end, the server SHOULD respond with 3022 a 457 "Invalid Range" error response. In that response, the current 3023 pause point MUST be included in a Range header. 3025 All range specifiers in this specification allow for ranges with an 3026 implicit start point (e.g. "npt=-30"). When used in a PLAY request, 3027 the server treats this as a request to start or resume delivery from 3028 the current pause point, ending at the end time specified in the 3029 Range header. If the pause point is located later than the given end 3030 value, a 457 (Invalid Range) response MUST be given. 3032 The example below will play seconds 10 through 25. It also requests 3033 the server to deliver media from the first Random Access Point prior 3034 to the indicated start point. 3036 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 3037 CSeq: 835 3038 Session: 12345678 3039 Range: npt=10-25 3040 Seek-Style: RAP 3041 User-Agent: PhonyClient/1.2 3043 Servers MUST include a "Range" header in any PLAY response, even if 3044 no Range header was present in the request. The response MUST use 3045 the same format as the request's range header contained. If no Range 3046 header was in the request, the format used in any previous PLAY 3047 request within the session SHOULD be used. If no format has been 3048 indicated in a previous request the server MAY use any time format 3049 supported by the media and indicated in the Accept-Ranges header in 3050 the SETUP request. It is RECOMMENDED that NPT is used if supported 3051 by the media. 3053 For any error response to a PLAY request, the server's response 3054 depends on the current session state. If the session is in Ready 3055 state, the current pause-point is returned using Range header with 3056 the pause point as the explicit start-point and an implicit stop- 3057 point. For time-progressing content where the pause-point moves with 3058 real-time due to limited retention, the current pause point is 3059 returned. For sessions in Play state, the current playout point and 3060 the remaining parts of the range request is returned. For any media 3061 with retention longer than 0 seconds the currently valid Media-Range 3062 header SHALL also be included in the response. 3064 A PLAY response MAY include a header carrying synchronization 3065 information. As the information necessary is dependent on the media 3066 transport format, further rules specifying the header and its usage 3067 are needed. For RTP the RTP-Info header is specified, see 3068 Section 18.43, and used in the following example. 3070 Here is a simple example for a single audio stream where the client 3071 requests the media starting from 3.52 seconds and to the end. The 3072 server sends a 200 OK response with the actual play time which is 10 3073 ms prior (3.51) and the RTP-Info header that contains the necessary 3074 parameters for the RTP stack. 3076 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3077 CSeq: 836 3078 Session: 12345678 3079 Range: npt=3.52- 3080 User-Agent: PhonyClient/1.2 3082 S->C: RTSP/2.0 200 OK 3083 CSeq: 836 3084 Date: Thu, 23 Jan 1997 15:35:06 GMT 3085 Server: PhonyServer/1.0 3086 Range: npt=3.51-324.39 3087 Seek-Style: First-Prior 3088 RTP-Info:url="rtsp://example.com/audio" 3089 ssrc=0D12F123:seq=14783;rtptime=2345962545 3091 S->C: RTP Packet TS=2345962545 => NPT=3.51 3092 Media duration=0.16 seconds 3094 The server replies with the actual start point that will be 3095 delivered. This may differ from the requested range if alignment of 3096 the requested range to valid frame boundaries is required for the 3097 media source. Note that some media streams in an aggregate may need 3098 to be delivered from even earlier points. Also, some media formats 3099 have a very long duration per individual data unit, therefore it 3100 might be necessary for the client to parse the data unit, and select 3101 where to start. The server SHALL also indicate which policy it uses 3102 for selecting the actual start point by including a Seek-Style 3103 header. 3105 In the following example the client receives the first media packet 3106 that stretches all the way up and past the requested playtime. Thus, 3107 it is the client's decision whether to render to the user the time 3108 between 3.52 and 7.05, or to skip it. In most cases it is probably 3109 most suitable not to render that time period. 3111 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3112 CSeq: 836 3113 Session: 12345678 3114 Range: npt=7.05- 3115 User-Agent: PhonyClient/1.2 3117 S->C: RTSP/2.0 200 OK 3118 CSeq: 836 3119 Date: Thu, 23 Jan 1997 15:35:06 GMT 3120 Server: PhonyServer/1.0 3121 Range: npt=3.52- 3122 Seek-Style: First-Prior 3123 RTP-Info:url="rtsp://example.com/audio" 3124 ssrc=0D12F123:seq=14783;rtptime=2345962545 3126 S->C: RTP Packet TS=2345962545 => NPT=3.52 3127 Duration=4.15 seconds 3129 After playing the desired range, the presentation does NOT change to 3130 the Ready state, media delivery simply stops. A PAUSE request MUST 3131 be issued to make the stream enter the Ready state. A PLAY request 3132 while the stream is still in the Play state is legal, and can be 3133 issued without an intervening PAUSE request. Such a request MUST 3134 replace the current PLAY action with the new one requested, i.e. 3135 being handled the same as the request was received in Ready state. 3136 In the case the range in Range header has an implicit start time 3137 (-endtime), the server MUST continue to play from where it currently 3138 was until the specified end point. This is useful to change end at 3139 another point than in the previous request. 3141 The following example plays the whole presentation starting at SMPTE 3142 time code 0:10:20 until the end of the clip. Note: The RTP-Info 3143 headers has been broken into several lines, where following lines 3144 start with whitespace as allowed by the syntax. 3146 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 3147 CSeq: 833 3148 Session: 12345678 3149 Range: smpte=0:10:20- 3150 User-Agent: PhonyClient/1.2 3152 S->C: RTSP/2.0 200 OK 3153 CSeq: 833 3154 Date: Thu, 23 Jan 1997 15:35:06 GMT 3155 Session: 12345678 3156 Server: PhonyServer/1.0 3157 Range: smpte=0:10:22-0:15:45 3158 Seek-Style: Next 3159 RTP-Info:url="rtsp://example.com/twister.en" 3160 ssrc=0D12F123:seq=14783;rtptime=2345962545 3162 For playing back a recording of a live presentation, it may be 3163 desirable to use clock units: 3165 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 3166 CSeq: 835 3167 Session: 12345678 3168 Range: clock=19961108T142300Z-19961108T143520Z 3169 User-Agent: PhonyClient/1.2 3171 S->C: RTSP/2.0 200 OK 3172 CSeq: 835 3173 Date: Thu, 23 Jan 1997 15:35:06 GMT 3174 Session: 12345678 3175 Server: PhonyServer/1.0 3176 Range: clock=19961108T142300Z-19961108T143520Z 3177 Seek-Style: Next 3178 RTP-Info:url="rtsp://example.com/meeting.en" 3179 ssrc=0D12F123:seq=53745;rtptime=484589019 3181 13.4.2. Aggregated Sessions 3183 PLAY requests can operate on sessions controlling a single media and 3184 on aggregated sessions controlling multiple media. 3186 In an aggregated session the PLAY request MUST contain an aggregated 3187 control URI. A server MUST respond with error 460 (Only Aggregate 3188 Operation Allowed) if the client PLAY Request-URI is for a single 3189 media. The media in an aggregate MUST be played in sync. If a 3190 client wants individual control of the media, it needs to use 3191 separate RTSP sessions for each media. 3193 For aggregated sessions where the initial SETUP request (creating a 3194 session) is followed by one or more additional SETUP requests, a PLAY 3195 request MAY be pipelined after those additional SETUP requests 3196 without awaiting their responses. This procedure can reduce the 3197 delay from start of session establishment until media play-out has 3198 started with one round trip time. However, a client needs to be 3199 aware that using this procedure will result in the playout of the 3200 server state established at the time of processing the PLAY, i.e., 3201 after the processing of all the requests prior to the PLAY request in 3202 the pipeline. This state may not be the intended one due to failure 3203 of any of the prior requests. A client can easily determine this 3204 based on the responses from those requests. In case of failure, the 3205 client can halt the media playout using PAUSE and try to establish 3206 the intended state again before issuing another PLAY request. 3208 13.4.3. Updating current PLAY Requests 3210 Clients can issue PLAY requests while the stream is in Play state and 3211 thus updating their request. 3213 The important difference compared to a PLAY request in Ready state is 3214 the handling of the current play point and how the Range header in 3215 request is constructed. The session is actively playing media and 3216 the play point will be moving, making the exact time a request will 3217 take action hard to predict. Depending on how the PLAY header 3218 appears two different cases exist: total replacement or continuation. 3219 A total replacement is signaled by having the first range 3220 specification have an explicit start value, e.g. npt=45- or 3221 npt=45-60, in which case the server stops playout at the current 3222 playout point and then starts delivering media according to the Range 3223 header. This is equivalent to having the client first send a PAUSE 3224 and then a new PLAY request that isn't based on the pause point. In 3225 the case of continuation the first range specifier has an implicit 3226 start point and an explicit stop value (Z), e.g. npt=-60, which 3227 indicate that it MUST convert the range specifier being played prior 3228 to this PLAY request (X to Y) into (X to Z) and continue as this was 3229 the request originally played. If the current delivery point is 3230 beyond the stop point, the server SHALL immediately pause delivery. 3231 As the request has been completed successfully it shall be responded 3232 with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to 3233 indicate the actual stop point. The pause point is set to the 3234 requested stop point. 3236 Following is an example of this behavior: The server has received 3237 requests to play ranges 10 to 15. If the new PLAY request arrives at 3238 the server 4 seconds after the previous one, it will take effect 3239 while the server still plays the first range (10-15). The server 3240 changes the current play to continue to 25 seconds, i.e. the 3241 equivalent single request would be PLAY with range: npt=10-25. 3243 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3244 CSeq: 834 3245 Session: 12345678 3246 Range: npt=10-15 3247 User-Agent: PhonyClient/1.2 3249 S->C: RTSP/2.0 200 OK 3250 CSeq: 834 3251 Date: Thu, 23 Jan 1997 15:35:06 GMT 3252 Session: 12345678 3253 Server: PhonyServer/1.0 3254 Range: npt=10-15 3255 Seek-Style: Next 3256 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3257 ssrc=0D12F123:seq=5712;rtptime=934207921, 3258 url="rtsp://example.com/fizzle/videotrack" 3259 ssrc=789DAF12:seq=57654;rtptime=2792482193 3260 Session: 12345678 3262 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3263 CSeq: 835 3264 Session: 12345678 3265 Range: npt=-25 3266 User-Agent: PhonyClient/1.2 3268 S->C: RTSP/2.0 200 OK 3269 CSeq: 835 3270 Date: Thu, 23 Jan 1997 15:35:09 GMT 3271 Session: 12345678 3272 Server: PhonyServer/1.0 3273 Range: npt=14-25 3274 Seek-Style: Next 3275 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3276 ssrc=0D12F123:seq=5712;rtptime=934239921, 3277 url="rtsp://example.com/fizzle/videotrack" 3278 ssrc=789DAF12:seq=57654;rtptime=2792842193 3280 A common use of a PLAY request while in Play state is changing the 3281 scale of the media, i.e., entering or leaving from fast forward or 3282 fast rewind. The client can issue an updating PLAY request that is 3283 either a continuation or a complete replacement, as discussed above 3284 this section. We give an example of a client that is requesting a 3285 fast forward (scale=2) without giving a stop point and then change 3286 from fast forward to regular playout (scale = 1). In the second PLAY 3287 request the time is set explicitly to be where ever the server 3288 currently plays out (npt=now-) and the server responds with the 3289 actual playback point where the new scale actually takes effect 3290 (npt=2:17:27.144-). 3292 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3293 CSeq: 2034 3294 Session: 12345678 3295 Range: npt=now- 3296 Scale: 2.0 3297 User-Agent: PhonyClient/1.2 3299 S->C: RTSP/2.0 200 OK 3300 CSeq: 2034 3301 Date: Thu, 23 Jan 1997 15:35:06 GMT 3302 Session: 12345678 3303 Server: PhonyServer/1.0 3304 Range: npt=2:17:21.394- 3305 Seek-Style: Next 3306 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3307 ssrc=0D12F123:seq=5712;rtptime=934207921, 3308 url="rtsp://example.com/fizzle/videotrack" 3309 ssrc=789DAF12:seq=57654;rtptime=2792482193 3311 [playing in fast forward and now returning to scale = 1] 3313 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3314 CSeq: 2035 3315 Session: 12345678 3316 Range: npt=now- 3317 Scale: 1.0 3318 User-Agent: PhonyClient/1.2 3320 S->C: RTSP/2.0 200 OK 3321 CSeq: 2035 3322 Date: Thu, 23 Jan 1997 15:35:09 GMT 3323 Session: 12345678 3324 Server: PhonyServer/1.0 3325 Range: npt=2:17:27.144- 3326 Seek-Style: Next 3327 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3328 ssrc=0D12F123:seq=5712;rtptime=934239921, 3329 url="rtsp://example.com/fizzle/videotrack" 3330 ssrc=789DAF12:seq=57654;rtptime=2792842193 3332 13.4.4. Playing On-Demand Media 3334 On-demand media is indicated by the content of the Media-Properties 3335 header in the SETUP response by (see also Section 18.28): 3337 o Random-Access property is set to Random Access; 3338 o Content Modifications set to Immutable; 3340 o Retention set to Unlimited or Time-Limited. 3342 Playing on-demand media follows the general usage as described in 3343 Section 13.4.1. 3345 13.4.5. Playing Dynamic On-Demand Media 3347 Dynamic on-demand media is indicated by the content of the Media- 3348 Properties header in the SETUP response by (see also Section 18.28): 3350 o RandomAccess set to Random-Access; 3352 o Content Modifications set to Dynamic; 3354 o Retention set to Unlimited or Time-Limited. 3356 Playing on-demand media follows the general usage as described in 3357 Section 13.4.1 as long as the media has not been changed. 3359 There are two ways for the client to be informed about changes of 3360 media resources in Play state. The client will receive a PLAY_NOTIFY 3361 request with Notify-Reason header set to media-properties-update (see 3362 Section 13.5.2. The client can use the value of the Media-Range to 3363 decide further actions, if the Media-Range header is present in the 3364 PLAY_NOTIFY request. The second way is that the client issues a 3365 GET_PARAMETER request without a body but including a Media-Range 3366 header. The 200 OK response MUST include the current Media-Range 3367 header (see Section 18.29). 3369 13.4.6. Playing Live Media 3371 Live media is indicated by the content of the Media-Properties header 3372 in the SETUP response by (see also Section 18.28): 3374 o Random-Access set to No-Seeking; 3376 o Content Modifications set to Time-Progressing; 3378 o Retention with Time-Duration set to 0.0. 3380 For live media, the SETUP response 200 OK MUST include the Media- 3381 Range header (see Section 18.29). 3383 A client MAY send PLAY requests without the Range header. If the 3384 request includes the Range header it MUST use a symbolic value 3385 representing "now". For NPT that range specification is "npt=now-". 3387 The server MUST include the Range header in the response and it MUST 3388 indicate an explicit time value and not a symbolic value. In other 3389 words, "npt=now-" is not valid to be used in the response. Instead 3390 the time since session start is recommended expressed as an open 3391 interval, e.g. "npt=96.23-". An absolute time value (clock) for the 3392 corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The 3393 UTC clock format can only be used if client has shown support for it 3394 using the Accept-Ranges header. 3396 13.4.7. Playing Live with Recording 3398 Certain media servers may offer recording services of live sessions 3399 to their clients. This recording would normally be from the 3400 beginning of the media session. Clients can randomly access the 3401 media between now and the beginning of the media session. This live 3402 media with recording is indicated by the content of the Media- 3403 Properties header in the SETUP response by (see also Section 18.28): 3405 o Random-Access set to Random-Access; 3407 o Content Modifications set to Time-Progressing; 3409 o Retention set to Time-limited or Unlimited 3411 The SETUP response 200 OK MUST include the Media-Range header (see 3412 Section 18.29) for this type of media. For live media with 3413 recording, the Range header indicates the current delivery point in 3414 the media and the Media-Range header indicates the currently 3415 available media window around the current time. This window can 3416 cover recorded content in the past (seen from current time in the 3417 media) or recorded content in the future (seen from current time in 3418 the media). The server adjusts the delivery point to the requested 3419 border of the window, if the client requests a delivery point that is 3420 located outside the recording windows, e.g., if requested to far in 3421 the past, the server selects the oldest range in the recording. The 3422 considerations in Section 13.5.3 apply, if a client requests delivery 3423 with Scale (Section 18.44) values other than 1.0 (Normal playback 3424 rate) while delivering live media with recording. 3426 13.4.8. Playing Live with Time-Shift 3428 Certain media servers may offer time-shift services to their clients. 3429 This time shift records a fixed interval in the past, i.e., a sliding 3430 window recording mechanism, but not past this interval. Clients can 3431 randomly access the media between now and the interval. This live 3432 media with recording is indicated by the content of the Media- 3433 Properties header in the SETUP response by (see also Section 18.28): 3435 o Random-Access set to Random-Access; 3437 o Content Modifications set to Time-Progressing; 3439 o Retention set to Time-Duration and a value indicating the 3440 recording interval (>0). 3442 The SETUP response 200 OK MUST include the Media-Range header (see 3443 Section 18.29) for this type of media. For live media with recording 3444 the Range header indicates the current time in the media and the 3445 Media Range indicates a window around the current time. This window 3446 can cover recorded content in the past (seen from current time in the 3447 media) or recorded content in the future (seen from current time in 3448 the media). The server adjusts the play point to the requested 3449 border of the window, if the client requests a play point that is 3450 located outside the recording windows, e.g., if requested too far in 3451 the past, the server selects the oldest range in the recording. The 3452 considerations in Section 13.5.3 apply, if a client requests delivery 3453 using a Scale (Section 18.44) value other than 1.0 (Normal playback 3454 rate) while delivering live media with time-shift. 3456 13.5. PLAY_NOTIFY 3458 The PLAY_NOTIFY method is issued by a server to inform a client about 3459 an asynchronous event for a session in Play state. The Session 3460 header MUST be presented in a PLAY_NOTIFY request and indicates the 3461 scope of the request. Sending of PLAY_NOTIFY requests requires a 3462 persistent connection between server and client, otherwise there is 3463 no way for the server to send this request method to the client. 3465 PLAY_NOTIFY requests have an end-to-end (i.e. server to client) 3466 scope, as they carry the Session header, and apply only to the given 3467 session. The client SHOULD immediately return a response to the 3468 server. 3470 PLAY_NOTIFY requests MAY be used with a message body, depending on 3471 the value of the Notify-Reason header. It is described in the 3472 particular section for each Notify-Reason if a message body is used. 3473 However, currently there is no Notify-Reason that allows using a 3474 message body. In this case, there is a need to obey some limitations 3475 when adding new Notify-Reasons that intend to use a message body: the 3476 server can send any type of message body, but it is not ensured that 3477 the client can understand the received message body. This is related 3478 to DESCRIBE (see Section 13.2 ), but in this particular case the 3479 client can state its acceptable message bodies by using the Accept 3480 header. In the case of PLAY_NOTIFY, the server does not know which 3481 message bodies are understood by the client. 3483 The Notify-Reason header (see Section 18.31) specifies the reason why 3484 the server sends the PLAY_NOTIFY request. This is extensible and new 3485 reasons MAY be added in the future (see Section 22.8). In case the 3486 client does not understand the reason for the notification it MUST 3487 respond with an 465 (Notification Reason Unknown) (Section 17.4.30) 3488 error code. Servers can send PLAY_NOTIFY with these types: 3490 o end-of-stream (see Section 13.5.1); 3492 o media-properties-update (see Section 13.5.2); 3494 o scale-change (see Section 13.5.3). 3496 13.5.1. End-of-Stream 3498 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3499 indicates the completion or near completion of the PLAY request and 3500 the ending delivery of the media stream(s). The request MUST NOT be 3501 issued unless the server is in the Play state. The end of the media 3502 stream delivery notification may be used to indicate either a 3503 successful completion of the PLAY request currently being served, or 3504 to indicate some error resulting in failure to complete the request. 3505 The Request-Status header (Section 18.40) MUST be included to 3506 indicate which request the notification is for and its completion 3507 status. The message response status codes (Section 8.1.1) are used 3508 to indicate how the PLAY request concluded. The sender of a 3509 PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a 3510 PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY 3511 was issued before reaching the end-of-stream, but some error occurred 3512 resulting in that the previously sent PLAY_NOTIFY contained a wrong 3513 time when the stream will end. In this case a new PLAY_NOTIFY MUST 3514 be sent including the correct status for the completion and all 3515 additional information. 3517 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream 3518 MUST include a Range header and the Scale header if the scale value 3519 is not 1. The Range header indicates the point in the stream or 3520 streams where delivery is ending with the timescale that was used by 3521 the server in the PLAY response for the request being fulfilled. The 3522 server MUST NOT use the "now" constant in the Range header; it MUST 3523 use the actual numeric end position in the proper timescale. When 3524 end-of-stream notifications are issued prior to having sent the last 3525 media packets, this is evident as the end time in the Range header is 3526 beyond the current time in the media being received by the client, 3527 e.g., npt=-15, if npt is currently at 14.2 seconds. The Scale header 3528 is to be included so that it is evident if the media time scale is 3529 moving backwards and/or have a non-default pace. The end-of-stream 3530 notification does not prevent the client from sending a new PLAY 3531 request. 3533 If RTP is used as media transport, a RTP-Info header MUST be 3534 included, and the RTP-Info header MUST indicate the last sequence 3535 number in the seq parameter. 3537 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3538 MUST NOT carry a message body. 3540 This example request notifies the client about a future end-of-stream 3541 event: 3542 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3543 CSeq: 854 3544 Notify-Reason: end-of-stream 3545 Request-Status: cseq=853 status=200 reason="OK" 3546 Range: npt=-145 3547 RTP-Info:url="rtsp://example.com/audio" 3548 ssrc=0D12F123:seq=14783;rtptime=2345962545 3549 Session: uZ3ci0K+Ld-M 3550 Date: Mon, 08 Mar 2010 13:37:16 GMT 3552 C->S: RTSP/2.0 200 OK 3553 CSeq: 854 3554 User-Agent: PhonyClient/1.2 3555 Session: uZ3ci0K+Ld-M 3557 13.5.2. Media-Properties-Update 3559 A PLAY_NOTIFY request with Notify-Reason header set to media- 3560 properties-update indicates an update of the media properties for the 3561 given session (see Section 18.28) and/or the available media range 3562 that can be played as indicated by Media-Range (Section 18.29). 3563 PLAY_NOTIFY requests with Notify-Reason header set to media- 3564 properties-update MUST include a Media-Properties and Date header and 3565 SHOULD include a Media-Range header. 3567 This notification MUST be sent for media that are time-progressing 3568 every time an event happens that changes the basis for making 3569 estimates on how the media range progress. In addition it is 3570 RECOMMENDED that the server sends these notifications every 5 minutes 3571 for time-progressing content to ensure the long-term stability of the 3572 client estimation and allowing for clock skew detection by the 3573 client. Requests for the just mentioned reasons MUST include Media- 3574 Range header to provide current Media duration and the Range header 3575 to indicate the current playing point and any remaining parts of the 3576 requested range. 3578 The recommendation for sending updates every 5 minutes is due to 3579 any clock skew issues. In 5 minutes the clock skew should not 3580 become too significant as this is not used for media playback and 3581 synchronization, only for determining which content is available 3582 to the user. 3584 A PLAY_NOTIFY request with Notify-Reason header set to media- 3585 properties-update MUST NOT carry a message body. 3586 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3587 Date: Tue, 14 Apr 2008 15:48:06 GMT 3588 CSeq: 854 3589 Notify-Reason: media-properties-update 3590 Session: uZ3ci0K+Ld-M 3591 Media-Properties: Time-Progressing, 3592 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3593 Media-Range: npt=0-1:37:21.394 3594 Range: npt=1:15:49.873- 3596 C->S: RTSP/2.0 200 OK 3597 CSeq: 854 3598 User-Agent: PhonyClient/1.2 3599 Session: uZ3ci0K+Ld-M 3601 13.5.3. Scale-Change 3603 The server may be forced to change the rate, when a client request 3604 delivery using a Scale (Section 18.44) value other than 1.0 (normal 3605 playback rate). For time progressing media with some retention, i.e. 3606 the server stores already sent content, a client requesting to play 3607 with Scale values larger than 1 may catch up with the front end of 3608 the media. The server will then be unable to continue to provide 3609 content at Scale larger than 1 as content is only made available by 3610 the server at Scale=1. Another case is when Scale < 1 and the media 3611 retention is time-duration limited. In this case the delivery point 3612 can reach the oldest media unit available, and further playback at 3613 this scale becomes impossible as there will be no media available. 3614 To avoid having the client lose any media, the scale will need to be 3615 adjusted to the same rate at which the media is removed from the 3616 storage buffer, commonly Scale = 1.0. 3618 Another case is when the content itself consists of spliced pieces or 3619 is dynamically updated. In these cases the server may be required to 3620 change from one supported scale value (different than Scale=1.0) to 3621 another. In this case the server will pick the closest value and 3622 inform the client of what it has picked. In these cases the media 3623 properties will also be sent updating the supported Scale values. 3624 This enables a client to adjust the used Scale value. 3626 To minimize impact on playback in any of the above cases the server 3627 MUST modify the playback properties and set Scale to a supportable 3628 value and continue delivery of the media. When doing this 3629 modification it MUST send a PLAY_NOTIFY message with the Notify- 3630 Reason header set to "scale-change". The request MUST contain a 3631 Range header with the media time where the change took effect, a 3632 Scale header with the new value in use, Session header with the ID 3633 for the session it applies to and a Date header with the server 3634 wallclock time of the change. For time progressing content also the 3635 Media-Range and the Media-Properties at this point in time MUST be 3636 included. The Media-Properties header MUST be included if the scale 3637 change was due to the content changing what scale values that is 3638 supported. 3640 For media streams being delivered using RTP also a RTP-Info header 3641 MUST be included. It MUST contain the rtptime parameter with a value 3642 corresponding to the point of change in that media and optionally 3643 also the sequence number. 3645 A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" 3646 MUST NOT carry a message body. 3648 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3649 Date: Tue, 14 Apr 2008 15:48:06 GMT 3650 CSeq: 854 3651 Notify-Reason: scale-change 3652 Session: uZ3ci0K+Ld-M 3653 Media-Properties: Time-Progressing, 3654 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3655 Media-Range: npt=0-1:37:21.394 3656 Range: npt=1:37:21.394- 3657 Scale: 1 3658 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" 3659 ssrc=0D12F123:rtptime=2345962545 3661 C->S: RTSP/2.0 200 OK 3662 CSeq: 854 3663 User-Agent: PhonyClient/1.2 3664 Session: uZ3ci0K+Ld-M 3666 13.6. PAUSE 3668 The PAUSE request causes the stream delivery to immediately be 3669 interrupted (halted). A PAUSE request MUST be done either with the 3670 aggregated control URI for aggregated sessions, resulting in all 3671 media being halted, or the media URI for non-aggregated sessions. 3672 Any attempt to do muting of a single media with a PAUSE request in an 3673 aggregated session MUST be responded to with error 460 (Only 3674 Aggregate Operation Allowed). After resuming playback, 3675 synchronization of the tracks MUST be maintained. Any server 3676 resources are kept, though servers MAY close the session and free 3677 resources after being paused for the duration specified with the 3678 timeout parameter of the Session header in the SETUP message. 3680 Example: 3682 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3683 CSeq: 834 3684 Session: 12345678 3685 User-Agent: PhonyClient/1.2 3687 S->C: RTSP/2.0 200 OK 3688 CSeq: 834 3689 Date: Thu, 23 Jan 1997 15:35:06 GMT 3690 Range: npt=45.76-75.00 3692 The PAUSE request causes stream delivery to be interrupted 3693 immediately on receipt of the message and the pause point is set to 3694 the current point in the presentation. That pause point in the media 3695 stream needs to be maintained. A subsequent PLAY request without 3696 Range header resume from the pause point and plays until media end. 3698 The pause point after any PAUSE request MUST be returned to the 3699 client by adding a Range header with what remains unplayed of the 3700 PLAY request's range. For media with random access properties, if 3701 one desires to resume playing a ranged request, one simply includes 3702 the Range header from the PAUSE response and includes the Seek-Style 3703 header with the Next policy in the PLAY request. For media that is 3704 time-progressing and has retention duration=0 the follow-up PLAY 3705 request to start media delivery again, will need to use "npt=now-" 3706 and not the answer given in the response to PAUSE. 3708 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3709 CSeq: 834 3710 Session: 12345678 3711 Range: npt=10-30 3712 User-Agent: PhonyClient/1.2 3714 S->C: RTSP/2.0 200 OK 3715 CSeq: 834 3716 Date: Thu, 23 Jan 1997 15:35:06 GMT 3717 Server: PhonyServer/1.0 3718 Range: npt=10-30 3719 Seek-Style: First-Prior 3720 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3721 ssrc=0D12F123:seq=5712;rtptime=934207921, 3722 url="rtsp://example.com/fizzle/videotrack" 3723 ssrc=4FAD8726:seq=57654;rtptime=2792482193 3724 Session: 12345678 3726 After 11 seconds, i.e. at 21 seconds into the presentation: 3727 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3728 CSeq: 835 3729 Session: 12345678 3730 User-Agent: PhonyClient/1.2 3732 S->C: RTSP/2.0 200 OK 3733 CSeq: 835 3734 Date: 23 Jan 1997 15:35:17 GMT 3735 Server: PhonyServer/1.0 3736 Range: npt=21-30 3737 Session: 12345678 3739 If a client issues a PAUSE request and the server acknowledges and 3740 enters the Ready state, the proper server response, if the player 3741 issues another PAUSE, is still 200 OK. The 200 OK response MUST 3742 include the Range header with the current pause point. See examples 3743 below: 3745 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3746 CSeq: 834 3747 Session: 12345678 3748 User-Agent: PhonyClient/1.2 3750 S->C: RTSP/2.0 200 OK 3751 CSeq: 834 3752 Session: 12345678 3753 Date: Thu, 23 Jan 1997 15:35:06 GMT 3754 Range: npt=45.76-98.36 3756 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 3757 CSeq: 835 3758 Session: 12345678 3759 User-Agent: PhonyClient/1.2 3761 S->C: RTSP/2.0 200 OK 3762 CSeq: 835 3763 Session: 12345678 3764 Date: 23 Jan 1997 15:35:07 GMT 3765 Range: npt=45.76-98.36 3767 13.7. TEARDOWN 3769 13.7.1. Client to Server 3771 The TEARDOWN client to server request stops the stream delivery for 3772 the given URI, freeing the resources associated with it. A TEARDOWN 3773 request MAY be performed on either an aggregated or a media control 3774 URI. However, some restrictions apply depending on the current 3775 state. The TEARDOWN request MUST contain a Session header indicating 3776 what session the request applies to. 3778 A TEARDOWN using the aggregated control URI or the media URI in a 3779 session under non-aggregated control (single media session) MAY be 3780 done in any state (Ready and Play). A successful request MUST result 3781 in that media delivery being immediately halted and the session state 3782 being destroyed. This MUST be indicated through the lack of a 3783 Session header in the response. 3785 A TEARDOWN using a media URI in an aggregated session MAY only be 3786 done in Ready state. Such a request only removes the indicated media 3787 stream and associated resources from the session. This may result in 3788 that a session returns to non-aggregated control, due to that it only 3789 contains a single media after the requests completion. A session 3790 that will exist after the processing of the TEARDOWN request MUST in 3791 the response to that TEARDOWN request contain a Session header. Thus 3792 the presence of the Session header indicates to the receiver of the 3793 response if the session is still existing or has been removed. 3795 Example: 3797 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 3798 CSeq: 892 3799 Session: 12345678 3800 User-Agent: PhonyClient/1.2 3802 S->C: RTSP/2.0 200 OK 3803 CSeq: 892 3804 Server: PhonyServer/1.0 3806 13.7.2. Server to Client 3808 The server can send TEARDOWN requests in the server to client 3809 direction to indicate that the server has been forced to terminate 3810 the ongoing session. This may happen for several reasons, such as 3811 server maintenance without available backup, or that the session has 3812 been inactive for extended periods of time. The reason is provided 3813 in the Terminate-Reason header (Section 18.50). 3815 When a RTSP client has maintained a RTSP session that otherwise is 3816 inactive for an extended period of time the server may reclaim the 3817 resources. That is done by issuing a TEARDOWN request with the 3818 Terminate-Reason set to "Session-Timeout". This MAY be done when the 3819 client has been inactive in the RTSP session for more than one 3820 Session Timeout period (Section 18.47). However, the server is 3821 RECOMMENDED to not perform this operation until an extended period of 3822 inactivity has passed. The time period is considered extended when 3823 it is 10 times the Session Timeout period. Consideration of the 3824 application of the server and its content should be performed when 3825 configuring what is considered as extended period of time. 3827 In case the server needs to stop providing service to the established 3828 sessions and there is no server to point at in a REDIRECT request, 3829 then TEARDOWN SHALL be used to terminate the session. This method 3830 can also be used when non-recoverable internal errors have happened 3831 and the server has no other option then to terminate the sessions. 3833 The TEARDOWN request MUST be done only on the session aggregate 3834 control URI (i.e., it is not allowed to terminate individual media 3835 streams, if it is a session aggregate) and MUST include the following 3836 headers; Session and Terminate-Reason headers. The request only 3837 applies to the session identified in the Session header. The server 3838 may include a message to the client's user with the "user-msg" 3839 parameter. 3841 The TEARDOWN request may alternatively be done on the wild card URI * 3842 and without any session header. The scope of such a request is 3843 limited to the next-hop (i.e. the RTSP agent in direct communication 3844 with the server) and applies, as well, to the control connection 3845 between the next-hop RTSP agent and the server. This request 3846 indicates that all sessions and pending requests being managed via 3847 the control connection are terminated. Any intervening proxies 3848 SHOULD do all of the following in the order listed: 3850 1. respond to the TEARDOWN request 3852 2. disconnect the control channel from the requesting server 3854 3. pass the TEARDOWN request to each applicable client (typically 3855 those clients with an active session or an unanswered request) 3857 Note: The proxy is responsible for accepting TEARDOWN responses 3858 from its clients; these responses MUST NOT be passed on to either 3859 the original server or the target server in the redirect. 3861 13.8. GET_PARAMETER 3863 The GET_PARAMETER request retrieves the value of any specified 3864 parameter or parameters for a presentation or stream specified in the 3865 URI. If the Session header is present in a request, the value of a 3866 parameter MUST be retrieved in the specified session context. There 3867 are two ways of specifying the parameters to be retrieved. The first 3868 is by including headers which have been defined such that you can use 3869 them for this purpose. Headers for this purpose should allow empty, 3870 or stripped value parts to avoid having to specify bogus data when 3871 indicating the desire to retrieve a value. The successful completion 3872 of the request should also be evident from any filled out values in 3873 the response. The Media-Range header (Section 18.29) is one such 3874 header. The other way is to specify a message body that lists the 3875 parameter(s) that are desired to be retrieved. The Content-Type 3876 header (Section 18.18) is used to specify which format the message 3877 body has. 3879 The headers that MAY be used for retrieving their current value using 3880 GET_PARAMETER are: 3882 o Accept-Ranges 3884 o Media-Range 3886 o Media-Properties 3887 o Range 3889 o RTP-Info 3891 The method MAY also be used without a message body or any header that 3892 request parameters for keep-alive purpose. The keep-alive timer has 3893 been updated for any request that is successful, i.e., a 200 OK 3894 response is received. Any non-required header present in such a 3895 request may or may not have been processed. Normally the presence of 3896 filled out values in the header will be indication that the header 3897 has been processed. However, for cases when this is difficult to 3898 determine, it is recommended to use a feature-tag and the Require 3899 header. Due to this reason it is usually easier if any parameters to 3900 be retrieved are sent in the body, rather than using any header. 3902 Parameters specified within the body of the message must all be 3903 understood by the request receiving agent. If one or more parameters 3904 are not understood a 451 (Parameter Not Understood) MUST be sent 3905 including a body listing these parameters that weren't understood. 3906 If all parameters are understood their values are filled in and 3907 returned in the response message body. 3909 Example: 3911 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 3912 CSeq: 431 3913 User-Agent: PhonyClient/1.2 3914 Session: 12345678 3915 Content-Length: 26 3916 Content-Type: text/parameters 3918 packets_received 3919 jitter 3921 C->S: RTSP/2.0 200 OK 3922 CSeq: 431 3923 Session: 12345678 3924 Server: PhonyServer/1.1 3925 Date: Mon, 08 Mar 2010 13:43:23 GMT 3926 Content-Length: 38 3927 Content-Type: text/parameters 3929 packets_received: 10 3930 jitter: 0.3838 3932 13.9. SET_PARAMETER 3934 This method requests to set the value of a parameter or a set of 3935 parameters for a presentation or stream specified by the URI. The 3936 method MAY also be used without a message body. It is the 3937 RECOMMENDED method to be used in a request sent for the sole purpose 3938 of updating the keep-alive timer. If this request is successful, 3939 i.e. a 200 OK response is received, then the keep-alive timer has 3940 been updated. Any non-required header present in such a request may 3941 or may not have been processed. To allow a client to determine if 3942 any such header has been processed, it is necessary to use a feature 3943 tag and the Require header. Due to this reason it is RECOMMENDED 3944 that any parameters are sent in the body, rather than using any 3945 header. 3947 A request is RECOMMENDED to only contain a single parameter to allow 3948 the client to determine why a particular request failed. If the 3949 request contains several parameters, the server MUST only act on the 3950 request if all of the parameters can be set successfully. A server 3951 MUST allow a parameter to be set repeatedly to the same value, but it 3952 MAY disallow changing parameter values. If the receiver of the 3953 request does not understand or cannot locate a parameter, error 451 3954 (Parameter Not Understood) MUST be used. In the case a parameter is 3955 not allowed to change, the error code is 458 (Parameter Is Read- 3956 Only). The response body MUST contain only the parameters that have 3957 errors. Otherwise no body MUST be returned. 3959 Note: transport parameters for the media stream MUST only be set with 3960 the SETUP command. 3962 Restricting setting transport parameters to SETUP is for the 3963 benefit of firewalls. 3965 The parameters are split in a fine-grained fashion so that there 3966 can be more meaningful error indications. However, it may make 3967 sense to allow the setting of several parameters if an atomic 3968 setting is desirable. Imagine device control where the client 3969 does not want the camera to pan unless it can also tilt to the 3970 right angle at the same time. 3972 Example: 3974 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 3975 CSeq: 421 3976 User-Agent: PhonyClient/1.2 3977 Session: iixT43KLc 3978 Date: Mon, 08 Mar 2010 14:45:04 GMT 3979 Content-length: 20 3980 Content-type: text/parameters 3982 barparam: barstuff 3984 S->C: RTSP/2.0 451 Parameter Not Understood 3985 CSeq: 421 3986 Session: iixT43KLc 3987 Server: PhonyServer/1.0 3988 Date: Mon, 08 Mar 2010 14:44:56 GMT 3989 Content-length: 20 3990 Content-type: text/parameters 3992 barparam: barstuff 3994 13.10. REDIRECT 3996 The REDIRECT method is issued by a server to inform a client that the 3997 service provided will be terminated and where a corresponding service 3998 can be provided instead. This may happen for different reasons. One 3999 is that the server is being administered such that it must stop 4000 providing service. Thus the client is required to connect to another 4001 server location to access the resource indicated by the Request-URI. 4003 The REDIRECT request SHALL contain a Terminate-Reason header 4004 (Section 18.50) to inform the client of the reason for the request. 4005 Additional parameters related to the reason may also be included. 4006 The intention here is to allow a server administrator to do a 4007 controlled shutdown of the RTSP server. That requires sufficient 4008 time to inform all entities having associated state with the server 4009 and for them to perform a controlled migration from this server to a 4010 fall back server. 4012 A REDIRECT request with a Session header has end-to-end (i.e. server 4013 to client) scope and applies only to the given session. Any 4014 intervening proxies SHOULD NOT disconnect the control channel while 4015 there are other remaining end-to-end sessions. The REQUIRED Location 4016 header MUST contain a complete absolute URI pointing to the resource 4017 to which the client SHOULD reconnect. Specifically, the Location 4018 MUST NOT contain just the host and port. A client may receive a 4019 REDIRECT request with a Session header, if and only if, an end-to-end 4020 session has been established. 4022 A client may receive a REDIRECT request without a Session header at 4023 any time when it has communication or a connection established with a 4024 server. The scope of such a request is limited to the next-hop (i.e. 4025 the RTSP agent in direct communication with the server) and applies 4026 to all sessions controlled, as well as the control connection between 4027 the next-hop RTSP agent and the server. A REDIRECT request without a 4028 Session header indicates that all sessions and pending requests being 4029 managed via the control connection MUST be redirected. The REQUIRED 4030 Location header, if included in such a request, SHOULD contain an 4031 absolute URI with only the host address and the OPTIONAL port number 4032 of the server to which the RTSP agent SHOULD reconnect. Any 4033 intervening proxies SHOULD do all of the following in the order 4034 listed: 4036 1. respond to the REDIRECT request 4038 2. disconnect the control channel from the requesting server 4040 3. connect to the server at the given host address 4042 4. pass the REDIRECT request to each applicable client (typically 4043 those clients with an active session or an unanswered request) 4045 Note: The proxy is responsible for accepting REDIRECT responses 4046 from its clients; these responses MUST NOT be passed on to either 4047 the original server or the redirected server. 4049 When the server lacks any alternative server and needs to terminate a 4050 session or all sessions the TEARDOWN request SHALL be used instead. 4052 When no Terminate-Reason "time" parameter are included in a REDIRECT 4053 request, the client SHALL perform the redirection immediately and 4054 return a response to the server. The server shall consider the 4055 session as terminated and can free any associated state after it 4056 receives the successful (2xx) response. The server MAY close the 4057 signaling connection upon receiving the response and the client 4058 SHOULD close the signaling connection after sending the 2xx response. 4059 The exception to this is when the client has several sessions on the 4060 server being managed by the given signaling connection. In this 4061 case, the client SHOULD close the connection when it has received and 4062 responded to REDIRECT requests for all the sessions managed by the 4063 signaling connection. 4065 The Terminate-Reason header "time" parameter MAY be used to indicate 4066 the wallclock time by when the redirection MUST have taken place. To 4067 allow a client to determine that redirect time without being time 4068 synchronized with the server, the server MUST include a Date header 4069 in the request. The client should have before the redirection time- 4070 line terminated the session and closed the control connection. The 4071 server MAY simple cease to provide service when the deadline time has 4072 been reached, or it may issue TEARDOWN requests to the remaining 4073 sessions. 4075 If the REDIRECT request times out following the rules in Section 10.4 4076 the server MAY terminate the session or transport connection that 4077 would be redirected by the request. This is a safeguard against 4078 misbehaving clients that refuse to respond to a REDIRECT request. 4079 That should not provide any benefit. 4081 After a REDIRECT request has been processed, a client that wants to 4082 continue to send or receive media for the resource identified by the 4083 Request-URI will have to establish a new session with the designated 4084 host. If the URI given in the Location header is a valid resource 4085 URI, a client SHOULD issue a DESCRIBE request for the URI. 4087 Note: The media resource indicated by the Location header can be 4088 identical, slightly different or totally different. This is the 4089 reason why a new DESCRIBE request SHOULD be issued. 4091 If the Location header contains only a host address, the client MAY 4092 assume that the media on the new server is identical to the media on 4093 the old server, i.e. all media configuration information from the old 4094 session is still valid except for the host address. However, the 4095 usage of conditional SETUP using MTag identifiers are RECOMMENDED to 4096 verify the assumption. 4098 This example request redirects traffic for this session to the new 4099 server at the given absolute time: 4101 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 4102 CSeq: 732 4103 Location: rtsp://s2.example.com:8001 4104 Terminate-Reason: Server-Admin ;time=19960213T143205Z 4105 Session: uZ3ci0K+Ld-M 4106 Date: Thu, 13 Feb 1996 14:30:43 GMT 4108 C->S: RTSP/2.0 200 OK 4109 CSeq: 732 4110 User-Agent: PhonyClient/1.2 4111 Session: uZ3ci0K+Ld-M 4113 14. Embedded (Interleaved) Binary Data 4115 In order to fulfill certain requirements on the network side, e.g. in 4116 conjunction with network address translators that block RTP traffic 4117 over UDP, it may be necessary to interleave RTSP messages and media 4118 stream data. This interleaving should generally be avoided unless 4119 necessary since it complicates client and server operation and 4120 imposes additional overhead. Also, head of line blocking may cause 4121 problems. Interleaved binary data SHOULD only be used if RTSP is 4122 carried over TCP. Interleaved data is not allowed inside RTSP 4123 messages. 4125 Stream data such as RTP packets is encapsulated by an ASCII dollar 4126 sign (36 decimal), followed by a one-byte channel identifier, 4127 followed by the length of the encapsulated binary data as a binary, 4128 two-byte integer in network byte order. The stream data follows 4129 immediately afterwards, without a CRLF, but including the upper-layer 4130 protocol headers. Each $ block MUST contain exactly one upper-layer 4131 protocol data unit, e.g., one RTP packet. 4132 0 1 2 3 4133 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 4134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4135 | "$" = 36 | Channel ID | Length in bytes | 4136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4137 : Length number of bytes of binary data : 4138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4140 The channel identifier is defined in the Transport header with the 4141 interleaved parameter (Section 18.52). 4143 When the transport choice is RTP, RTCP messages are also interleaved 4144 by the server over the TCP connection. The usage of RTCP messages is 4145 indicated by including an interval containing a second channel in the 4146 interleaved parameter of the Transport header, see Section 18.52. If 4147 RTCP is used, packets MUST be sent on the first available channel 4148 higher than the RTP channel. The channels are bi-directional, using 4149 the same ChannelD in both directions, and therefore RTCP traffic are 4150 sent on the second channel in both directions. 4152 RTCP is sometimes needed for synchronization when two or more 4153 streams are interleaved in such a fashion. Also, this provides a 4154 convenient way to tunnel RTP/RTCP packets through the TCP control 4155 connection when required by the network configuration and transfer 4156 them onto UDP when possible. 4158 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 4159 CSeq: 2 4160 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 4161 Accept-Ranges: NPT, SMPTE, UTC 4162 User-Agent: PhonyClient/1.2 4164 S->C: RTSP/2.0 200 OK 4165 CSeq: 2 4166 Date: Thu, 05 Jun 1997 18:57:18 GMT 4167 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 4168 Session: 12345678 4169 Accept-Ranges: NPT 4170 Media-Properties: Random-Access=0.2, Immutable, Unlimited 4172 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 4173 CSeq: 3 4174 Session: 12345678 4175 User-Agent: PhonyClient/1.2 4177 S->C: RTSP/2.0 200 OK 4178 CSeq: 3 4179 Session: 12345678 4180 Date: Thu, 05 Jun 1997 18:57:19 GMT 4181 RTP-Info: url="rtsp://example.com/bar.file" 4182 ssrc=0D12F123:seq=232433;rtptime=972948234 4183 Range: npt=0-56.8 4184 Seek-Style: RAP 4186 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 4187 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 4188 S->C: $006{2 byte length}{"length" bytes RTCP packet} 4190 15. Proxies 4192 RTSP Proxies are RTSP agents that are located in between a client and 4193 a server. A proxy can take on both the role as a client and as 4194 server depending on what it tries to accomplish. Proxies are also 4195 introduced for several different reasons and the below listed are 4196 often combined. 4198 In general there are two categories of RTSP proxies, transparent (of 4199 which the client is not aware) and the non-transparent proxies (of 4200 which the client is aware). Transparent proxies are not visible to 4201 the client in terms of that the transport layer connection, e.g., TCP 4202 for RTSP, as there is only a single transport connection which is 4203 terminated at the RTSP client and the RTSP server. In the case of 4204 non-transparent proxies, there are two transport layer connections, 4205 one from the RTSP client to the RTSP proxy and a second from the RTSP 4206 proxy to the RTSP server. 4208 There are these types of RTSP proxies: 4210 Caching Proxy: This type of proxy is used to reduce the workload on 4211 servers and connections. By caching the description and media 4212 streams, i.e., the presentation, the proxy can serve a client 4213 with content, but without requesting it from the server once it 4214 has been cached and has not become stale. See the caching 4215 Section 16. This type of proxy is also expected to understand 4216 RTSP end-point functionality, i.e., functionality identified in 4217 the Require header in addition to what Proxy-Require demands. 4219 Translator Proxy: This type of proxy is used to ensure that an RTSP 4220 client gets access to servers and content on an external 4221 network or using content encodings not supported by the client. 4222 The proxy performs the necessary translation of addresses, 4223 protocols or encodings. This type of proxy is expected to also 4224 understand RTSP end-point functionality, i.e. functionality 4225 identified in the Require header in addition to what Proxy- 4226 Require demands. 4228 Access Proxy: This type of proxy is used to ensure that an RTSP 4229 clients get access to servers on an external network. Thus 4230 this proxy is placed on the border between two domains, e.g. a 4231 private address space and the public Internet. The proxy 4232 performs the necessary translation, usually addresses. This 4233 type of proxy is required to redirect the media to itself or a 4234 controlled gateway that performs the translation before the 4235 media can reach the client. 4237 Security Proxy: This type of proxy is used to help facilitate 4238 security functions around RTSP. For example when having a 4239 firewalled network, the security proxy request that the 4240 necessary pinholes in the firewall are opened when a client in 4241 the protected network wants to access media streams on the 4242 external side. This proxy can also limit the clients access to 4243 certain types of content. This proxy can perform its function 4244 without redirecting the media between the server and client. 4245 However, in deployments with private address spaces this proxy 4246 is likely to be combined with the access proxy. Anyway, the 4247 functionality of this proxy is usually closely tied into 4248 understanding all aspects of the media transport. 4250 Auditing Proxy: RTSP proxies can also provide network owners with a 4251 logging and audit point for RTSP sessions, e.g. for 4252 corporations that track their employees usage of the network. 4253 This type of proxy can perform its function without inserting 4254 itself or any other node in the media transport. This proxy 4255 type can also accept unknown methods as it doesn't interfere 4256 with the clients' requests. 4258 All types of proxies can be used also when using secured 4259 communication with TLS as RTSP 2.0 allows the client to approve 4260 certificate chains used for connection establishment from a proxy, 4261 see Section 19.3.2. However, that trust model may not be suitable 4262 for all types of deployment. In those cases, the secured sessions do 4263 by-pass of the proxies. 4265 Access proxies SHOULD NOT be used in equipment like NATs and 4266 firewalls that aren't expected to be regularly maintained, like home 4267 or small office equipment. In these cases it is better to use the 4268 NAT traversal procedures defined for RTSP 2.0 4269 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 4270 that any extensions of RTSP resulting in new media transport 4271 protocols or profiles, new parameters, etc. may fail in a proxy that 4272 isn't maintained. This would impede RTSP's future development and 4273 usage. 4275 15.1. Proxies and Protocol Extensions 4277 The existence of proxies must always be considered when developing 4278 new RTSP extensions. Most types of proxies will need to implement 4279 any new method to operate correctly in the presence of that 4280 extension. New headers can be introduced and will not be blocked by 4281 older proxies. However, it is important to consider if this header 4282 and its function is required to be understood by the proxy or can be 4283 forwarded. If the header needs to be understood, a feature-tag 4284 representing the functionality MUST be included in the Proxy-Require 4285 header. Below are guidelines for analysis if the header needs to be 4286 understood. The transport header and its parameters also shows that 4287 headers that are extensible and require correct interpretation in the 4288 proxy also require handling rules. 4290 Whether a proxy needs to understand a header is not easy to 4291 determine, as they serve a broad variety of functions. When 4292 evaluating if a header needs to be understood, one can divide the 4293 functionality into three main categories: 4295 Media modifying: The caching and translator proxies are modifying 4296 the actual media and therefore needs to understand also request 4297 directed to the server that affects how the media is rendered. 4298 Thus, this type of proxy needs to also understand the server side 4299 functionality. 4301 Transport modifying: The access and the security proxy both need to 4302 understand how the transport is performed, either for opening 4303 pinholes or to translate the outer headers, e.g. IP and UDP. 4305 Non-modifying: The audit proxy is special in that it does not modify 4306 the messages in other ways than to insert the Via header. That 4307 makes it possible for this type to forward RTSP messages that 4308 contain different types of unknown methods, headers or header 4309 parameters. 4311 Based on the above classification, one should evaluate if the new 4312 functionality requires the Transport modifying type of proxies to 4313 understand it or not. 4315 15.2. Multiplexing and Demultiplexing of Messages 4317 RTSP proxies may have to multiplex multiple RTSP sessions from their 4318 clients towards RTSP servers. This requires that RTSP requests from 4319 multiple clients are multiplexed onto a common connection for 4320 requests outgoing to an RTSP server and on the way back the responses 4321 are demultiplexed from the server to per client responses. On the 4322 protocol level this requires that request and response messages are 4323 handled in both ways, requiring that there is a mechanism to 4324 correlate what request/response pair exchanged between proxy and 4325 server is mapped to what client (or client request). 4327 This multiplexing of requests and demultiplexing of responses is done 4328 by using the CSeq header field (see Section 18.19). The proxy has to 4329 rewrite the CSeq in requests to the server and responses from the 4330 server and remember what CSeq is mapped to what client. 4332 16. Caching 4334 In HTTP, request-response pairs are cached. RTSP differs 4335 significantly in that respect. Responses are not cacheable, with the 4336 exception of the presentation description returned by DESCRIBE. 4337 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4338 not return any data, caching is not really an issue for these 4339 requests.) However, it is desirable for the continuous media data, 4340 typically delivered out-of-band with respect to RTSP, to be cached, 4341 as well as the session description. 4343 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4344 has an up-to-date copy of the continuous media content and its 4345 description. It can determine whether the copy is up-to-date by 4346 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4347 Last-Modified header with that of the cached copy. If the copy is 4348 not up-to-date, it modifies the SETUP transport parameters as 4349 appropriate and forwards the request to the origin server. 4350 Subsequent control commands such as PLAY or PAUSE then pass the proxy 4351 unmodified. The proxy delivers the continuous media data to the 4352 client, while possibly making a local copy for later reuse. The 4353 exact allowed behavior of the cache is given by the cache-response 4354 directives described in Section 18.10. A cache MUST answer any 4355 DESCRIBE requests if it is currently serving the stream to the 4356 requester, as it is possible that low-level details of the stream 4357 description may have changed on the origin-server. 4359 Note that an RTSP cache, is of the "cut-through" variety. Rather 4360 than retrieving the whole resource from the origin server, the cache 4361 simply copies the streaming data as it passes by on its way to the 4362 client. Thus, it does not introduce additional latency. 4364 To the client, an RTSP proxy cache appears like a regular media 4365 server, to the media origin server like a client. Just as an HTTP 4366 cache has to store the content type, content language, and so on for 4367 the objects it caches, a media cache has to store the presentation 4368 description. Typically, a cache eliminates all transport-references 4369 (e.g., multicast information) from the presentation description, 4370 since these are independent of the data delivery from the cache to 4371 the client. Information on the encodings remains the same. If the 4372 cache is able to translate the cached media data, it would create a 4373 new presentation description with all the encoding possibilities it 4374 can offer. 4376 16.1. Validation Model 4378 When a cache has a stale entry that it would like to use as a 4379 response to a client's request, it first has to check with the origin 4380 server (or possibly an intermediate cache with a fresh response) to 4381 see if its cached entry is still usable. We call this "validating" 4382 the cache entry. Since we do not want to have to pay the overhead of 4383 retransmitting the full response if the cached entry is good, and we 4384 do not want to pay the overhead of an extra round trip if the cached 4385 entry is invalid, the RTSP protocol supports the use of conditional 4386 methods. 4388 The key protocol features for supporting conditional methods are 4389 those concerned with "cache validators." When an origin server 4390 generates a full response, it attaches some sort of validator to it, 4391 which is kept with the cache entry. When a client (user agent or 4392 proxy cache) makes a conditional request for a resource for which it 4393 has a cache entry, it includes the associated validator in the 4394 request. 4396 The server then checks that validator against the current validator 4397 for the requested resource, and, if they match (see Section 16.1.3), 4398 it responds with a special status code (usually, 304 (Not Modified)) 4399 and no message body. Otherwise, it returns a full response 4400 (including message body). Thus, we avoid transmitting the full 4401 response if the validator matches, and we avoid an extra round trip 4402 if it does not match. 4404 In RTSP, a conditional request looks exactly the same as a normal 4405 request for the same resource, except that it carries a special 4406 header (which includes the validator) that implicitly turns the 4407 method (usually DESCRIBE or SETUP) into a conditional. 4409 The protocol includes both positive and negative senses of cache- 4410 validating conditions. That is, it is possible to request either 4411 that a method be performed if and only if a validator matches or if 4412 and only if no validators match. 4414 Note: a response that lacks a validator may still be cached, and 4415 served from cache until it expires, unless this is explicitly 4416 prohibited by a cache-control directive (see Section 18.10). 4417 However, a cache cannot do a conditional retrieval if it does not 4418 have a validator for the resource, which means it will not be 4419 refreshable after it expires. 4421 Media streams that are being adapted based on the transport capacity 4422 between the server and the cache makes caching more difficult. A 4423 server needs to consider how it views caching of media streams that 4424 it adapts and potentially instruct any caches to not cache such 4425 streams. 4427 16.1.1. Last-Modified Dates 4429 The Last-Modified header (Section 18.26) value is often used as a 4430 cache validator. In simple terms, a cache entry is considered to be 4431 valid if the content has not been modified since the Last-Modified 4432 value. 4434 16.1.2. Message Body Tag Cache Validators 4436 The MTag response-header field value, a message body tag, provides 4437 for an "opaque" cache validator. This might allow more reliable 4438 validation in situations where it is inconvenient to store 4439 modification dates, where the one-second resolution of RTSP-date 4440 values is not sufficient, or where the origin server wishes to avoid 4441 certain paradoxes that might arise from the use of modification 4442 dates. 4444 Message body tags are described in Section 4.8 4446 16.1.3. Weak and Strong Validators 4448 Since both origin servers and caches will compare two validators to 4449 decide if they represent the same or different entities, one normally 4450 would expect that if the message body (i.e., the presentation 4451 description) or any associated message body headers changes in any 4452 way, then the associated validator would change as well. If this is 4453 true, then we call this validator a "strong validator." We call 4454 message body (i.e., the presentation description) or any associated 4455 message body headers an entity for a better understanding. 4457 However, there might be cases when a server prefers to change the 4458 validator only on semantically significant changes, and not when 4459 insignificant aspects of the entity change. A validator that does 4460 not always change when the resource changes is a "weak validator." 4462 Message body tags are normally "strong validators," but the protocol 4463 provides a mechanism to tag a message body tag as "weak." One can 4464 think of a strong validator as one that changes whenever the bits of 4465 an entity changes, while a weak value changes whenever the meaning of 4466 an entity changes. Alternatively, one can think of a strong 4467 validator as part of an identifier for a specific entity, while a 4468 weak validator is part of an identifier for a set of semantically 4469 equivalent entities. 4471 Note: One example of a strong validator is an integer that is 4472 incremented in stable storage every time an entity is changed. 4474 An entity's modification time, if represented with one-second 4475 resolution, could be a weak validator, since it is possible that 4476 the resource might be modified twice during a single second. 4478 Support for weak validators is optional. However, weak validators 4479 allow for more efficient caching of equivalent objects. 4481 A "use" of a validator is either when a client generates a request 4482 and includes the validator in a validating header field, or when a 4483 server compares two validators. 4485 Strong validators are usable in any context. Weak validators are 4486 only usable in contexts that do not depend on exact equality of an 4487 entity. For example, either kind is usable for a conditional 4488 DESCRIBE of a full entity. However, only a strong validator is 4489 usable for a sub-range retrieval, since otherwise the client might 4490 end up with an internally inconsistent entity. 4492 Clients MAY issue DESCRIBE requests with either weak validators or 4493 strong validators. Clients MUST NOT use weak validators in other 4494 forms of requests. 4496 The only function that the RTSP protocol defines on validators is 4497 comparison. There are two validator comparison functions, depending 4498 on whether the comparison context allows the use of weak validators 4499 or not: 4501 o The strong comparison function: in order to be considered equal, 4502 both validators MUST be identical in every way, and both MUST NOT 4503 be weak. 4505 o The weak comparison function: in order to be considered equal, 4506 both validators MUST be identical in every way, but either or both 4507 of them MAY be tagged as "weak" without affecting the result. 4509 A message body tag is strong unless it is explicitly tagged as weak. 4511 A Last-Modified time, when used as a validator in a request, is 4512 implicitly weak unless it is possible to deduce that it is strong, 4513 using the following rules: 4515 o The validator is being compared by an origin server to the actual 4516 current validator for the entity and, 4518 o That origin server reliably knows that the associated entity did 4519 not change more than once during the second covered by the 4520 presented validator. 4522 OR 4524 o The validator is about to be used by a client in an If-Modified- 4525 Since, because the client has a cache entry for the associated 4526 entity, and 4528 o That cache entry includes a Date value, which gives the time when 4529 the origin server sent the original response, and 4531 o The presented Last-Modified time is at least 60 seconds before the 4532 Date value. 4534 OR 4536 o The validator is being compared by an intermediate cache to the 4537 validator stored in its cache entry for the entity, and 4539 o That cache entry includes a Date value, which gives the time when 4540 the origin server sent the original response, and 4542 o The presented Last-Modified time is at least 60 seconds before the 4543 Date value. 4545 This method relies on the fact that if two different responses were 4546 sent by the origin server during the same second, but both had the 4547 same Last-Modified time, then at least one of those responses would 4548 have a Date value equal to its Last-Modified time. The arbitrary 60- 4549 second limit guards against the possibility that the Date and Last- 4550 Modified values are generated from different clocks, or at somewhat 4551 different times during the preparation of the response. An 4552 implementation MAY use a value larger than 60 seconds, if it is 4553 believed that 60 seconds is too short. 4555 If a client wishes to perform a sub-range retrieval on a value for 4556 which it has only a Last-Modified time and no opaque validator, it 4557 MAY do this only if the Last-Modified time is strong in the sense 4558 described here. 4560 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates 4562 We adopt a set of rules and recommendations for origin servers, 4563 clients, and caches regarding when various validator types ought to 4564 be used, and for what purposes. 4566 RTSP origin servers: 4568 o SHOULD send a message body tag validator unless it is not feasible 4569 to generate one. 4571 o MAY send a weak message body tag instead of a strong message body 4572 tag, if performance considerations support the use of weak message 4573 body tags, or if it is unfeasible to send a strong message body 4574 tag. 4576 o SHOULD send a Last-Modified value if it is feasible to send one, 4577 unless the risk of a breakdown in semantic transparency that could 4578 result from using this date in an If-Modified-Since header would 4579 lead to serious problems. 4581 In other words, the preferred behavior for an RTSP origin server is 4582 to send both a strong message body tag and a Last-Modified value. 4584 In order to be legal, a strong message body tag MUST change whenever 4585 the associated entity value changes in any way. A weak message body 4586 tag SHOULD change whenever the associated entity changes in a 4587 semantically significant way. 4589 Note: in order to provide semantically transparent caching, an 4590 origin server MUST avoid reusing a specific strong message body 4591 tag value for two different entities, or reusing a specific weak 4592 message body tag value for two semantically different entities. 4593 Cache entries might persist for arbitrarily long periods, 4594 regardless of expiration times, so it might be inappropriate to 4595 expect that a cache will never again attempt to validate an entry 4596 using a validator that it obtained at some point in the past. 4598 RTSP clients: 4600 o If a message body tag has been provided by the origin server, MUST 4601 use that message body tag in any cache-conditional request (using 4602 If-Match or If-None-Match). 4604 o If only a Last-Modified value has been provided by the origin 4605 server, SHOULD use that value in non-subrange cache-conditional 4606 requests (using If-Modified-Since). 4608 o If both a message body tag and a Last-Modified value have been 4609 provided by the origin server, SHOULD use both validators in 4610 cache-conditional requests. 4612 An RTSP origin server, upon receiving a conditional request that 4613 includes both a Last-Modified date (e.g., in an If-Modified-Since 4614 header) and one or more message body tags (e.g., in an If-Match, If- 4615 None-Match, or If-Range header field) as cache validators, MUST NOT 4616 return a response status of 304 (Not Modified) unless doing so is 4617 consistent with all of the conditional header fields in the request. 4619 Note: The general principle behind these rules is that RTSP 4620 servers and clients should transmit as much non-redundant 4621 information as is available in their responses and requests. RTSP 4622 systems receiving this information will make the most conservative 4623 assumptions about the validators they receive. 4625 16.1.5. Non-validating Conditionals 4627 The principle behind message body tags is that only the service 4628 author knows the semantics of a resource well enough to select an 4629 appropriate cache validation mechanism, and the specification of any 4630 validator comparison function more complex than byte-equality would 4631 open up a can of worms. Thus, comparisons of any other headers are 4632 never used for purposes of validating a cache entry. 4634 16.2. Invalidation After Updates or Deletions 4636 The effect of certain methods performed on a resource at the origin 4637 server might cause one or more existing cache entries to become non- 4638 transparently invalid. That is, although they might continue to be 4639 "fresh," they do not accurately reflect what the origin server would 4640 return for a new request on that resource. 4642 There is no way for the RTSP protocol to guarantee that all such 4643 cache entries are marked invalid. For example, the request that 4644 caused the change at the origin server might not have gone through 4645 the proxy where a cache entry is stored. However, several rules help 4646 reduce the likelihood of erroneous behavior. 4648 In this section, the phrase "invalidate an entity" means that the 4649 cache will either remove all instances of that entity from its 4650 storage, or will mark these as "invalid" and in need of a mandatory 4651 revalidation before they can be returned in response to a subsequent 4652 request. 4654 Some RTSP methods MUST cause a cache to invalidate an entity. This 4655 is either the entity referred to by the Request-URI, or by the 4656 Location or Content-Location headers (if present). These methods 4657 are: 4659 o DESCRIBE 4660 o SETUP 4662 In order to prevent denial of service attacks, an invalidation based 4663 on the URI in a Location or Content-Location header MUST only be 4664 performed if the host part is the same as in the Request-URI. 4666 A cache that passes through requests for methods it does not 4667 understand SHOULD invalidate any entities referred to by the Request- 4668 URI. 4670 17. Status Code Definitions 4672 Where applicable, HTTP status [H10] codes are reused. Status codes 4673 that have the same meaning are not repeated here. See Table 4 in 4674 Section 8.1 for a listing of which status codes may be returned by 4675 which requests. All error messages, 4xx and 5xx MAY return a body 4676 containing further information about the error. 4678 17.1. Success 1xx 4680 17.1.1. 100 Continue 4682 The client SHOULD continue with its request. This interim response 4683 is used to inform the client that the initial part of the request has 4684 been received and has not yet been rejected by the server. The 4685 client SHOULD continue by sending the remainder of the request or, if 4686 the request has already been completed, ignore this response. The 4687 server MUST send a final response after the request has been 4688 completed. 4690 17.2. Success 2xx 4692 This class of status code indicates that the client's request was 4693 successfully received, understood, and accepted. 4695 17.2.1. 200 OK 4697 The request has succeeded. The information returned with the 4698 response is dependent on the method used in the request. 4700 17.3. Redirection 3xx 4702 The notation "3rr" indicates response codes from 300 to 399 inclusive 4703 which are meant for redirection. The response code 304 is excluded 4704 from this set, as it is not used for redirection. 4706 Within RTSP, redirection may be used for load balancing or 4707 redirecting stream requests to a server topologically closer to the 4708 client. Mechanisms to determine topological proximity are beyond the 4709 scope of this specification. 4711 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 4712 that they are used if necessary before a session is established, 4713 i.e., in response to DESCRIBE or SETUP. However, in cases where a 4714 server is not able to send a REDIRECT request to the client, the 4715 server MAY need to resort to using 3rr responses to inform a client 4716 with an established session about the need for redirecting the 4717 session. If a 3rr response is received for a request in relation to 4718 an established session, the client SHOULD send a TEARDOWN request for 4719 the session, and MAY reestablish the session using the resource 4720 indicated by the Location. 4722 If the Location header is used in a response it MUST contain an 4723 absolute URI pointing out the media resource the client is redirected 4724 to, the URI MUST NOT only contain the host name. 4726 17.3.1. 301 Moved Permanently 4728 The requested resource is moved permanently and resides now at the 4729 URI given by the location header. The user client SHOULD redirect 4730 automatically to the given URI. This response MUST NOT contain a 4731 message-body. The Location header MUST be included in the response. 4733 17.3.2. 302 Found 4735 The requested resource resides temporarily at the URI given by the 4736 Location header. The Location header MUST be included in the 4737 response. This response is intended to be used for many types of 4738 temporary redirects; e.g., load balancing. It is RECOMMENDED that 4739 the server set the reason phrase to something more meaningful than 4740 "Found" in these cases. The user client SHOULD redirect 4741 automatically to the given URI. This response MUST NOT contain a 4742 message-body. 4744 This example shows a client being redirected to a different server: 4746 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 4747 CSeq: 2 4748 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 4749 Accept-Ranges: NPT, SMPTE, UTC 4750 User-Agent: PhonyClient/1.2 4752 S->C: RTSP/2.0 302 Try Other Server 4753 CSeq: 2 4754 Location: rtsp://s2.example.com:8001/fizzle/foo 4756 17.3.3. 303 See Other 4758 This status code MUST NOT be used in RTSP 2.0. However, it was 4759 allowed to use in RTSP 1.0 (RFC 2326). 4761 17.3.4. 304 Not Modified 4763 If the client has performed a conditional DESCRIBE or SETUP (see 4764 Section 18.24) and the requested resource has not been modified, the 4765 server SHOULD send a 304 response. This response MUST NOT contain a 4766 message-body. 4768 The response MUST include the following header fields: 4770 o Date 4772 o MTag and/or Content-Location, if the header(s) would have been 4773 sent in a 200 response to the same request. 4775 o Expires and Cache-Control if the field-value might differ from 4776 that sent in any previous response for the same variant. 4778 This response is independent for the DESCRIBE and SETUP requests. 4779 That is, a 304 response to DESCRIBE does NOT imply that the resource 4780 content is unchanged (only the session description) and a 304 4781 response to SETUP does NOT imply that the resource description is 4782 unchanged. The MTag and If-Match headers may be used to link the 4783 DESCRIBE and SETUP in this manner. 4785 17.3.5. 305 Use Proxy 4787 The requested resource MUST be accessed through the proxy given by 4788 the Location field. The Location field gives the URI of the proxy. 4789 The recipient is expected to repeat this single request via the 4790 proxy. 305 responses MUST only be generated by origin servers. 4792 17.4. Client Error 4xx 4794 17.4.1. 400 Bad Request 4796 The request could not be understood by the server due to malformed 4797 syntax. The client SHOULD NOT repeat the request without 4798 modifications. If the request does not have a CSeq header, the 4799 server MUST NOT include a CSeq in the response. 4801 17.4.2. 401 Unauthorized 4803 The request requires user authentication. The response MUST include 4804 a WWW-Authenticate header (Section 18.56) field containing a 4805 challenge applicable to the requested resource. The client MAY 4806 repeat the request with a suitable Authorization header field. If 4807 the request already included Authorization credentials, then the 401 4808 response indicates that authorization has been refused for those 4809 credentials. If the 401 response contains the same challenge as the 4810 prior response, and the user agent has already attempted 4811 authentication at least once, then the user SHOULD be presented the 4812 message body that was given in the response, since that message body 4813 might include relevant diagnostic information. HTTP access 4814 authentication is explained in [RFC2617]. 4816 17.4.3. 402 Payment Required 4818 This code is reserved for future use. 4820 17.4.4. 403 Forbidden 4822 The server understood the request, but is refusing to fulfill it. 4823 Authorization will not help and the request SHOULD NOT be repeated. 4824 If the server wishes to make public why the request has not been 4825 fulfilled, it SHOULD describe the reason for the refusal in the 4826 message body. If the server does not wish to make this information 4827 available to the client, the status code 404 (Not Found) can be used 4828 instead. 4830 17.4.5. 404 Not Found 4832 The server has not found anything matching the Request-URI. No 4833 indication is given of whether the condition is temporary or 4834 permanent. The 410 (Gone) status code SHOULD be used if the server 4835 knows, through some internally configurable mechanism, that an old 4836 resource is permanently unavailable and has no forwarding address. 4837 This status code is commonly used when the server does not wish to 4838 reveal exactly why the request has been refused, or when no other 4839 response is applicable. 4841 17.4.6. 405 Method Not Allowed 4843 The method specified in the request is not allowed for the resource 4844 identified by the Request-URI. The response MUST include an Allow 4845 header containing a list of valid methods for the requested resource. 4846 This status code is also to be used if a request attempts to use a 4847 method not indicated during SETUP. 4849 17.4.7. 406 Not Acceptable 4851 The resource identified by the request is only capable of generating 4852 response message bodies which have content characteristics not 4853 acceptable according to the Accept headers sent in the request. 4855 The response SHOULD include a message body containing a list of 4856 available message body characteristics and location(s) from which the 4857 user or user agent can choose the one most appropriate. The message 4858 body format is specified by the media type given in the Content-Type 4859 header field. Depending upon the format and the capabilities of the 4860 user agent, selection of the most appropriate choice MAY be performed 4861 automatically. However, this specification does not define any 4862 standard for such automatic selection. 4864 If the response could be unacceptable, a user agent SHOULD 4865 temporarily stop receipt of more data and query the user for a 4866 decision on further actions. 4868 17.4.8. 407 Proxy Authentication Required 4870 This code is similar to 401 (Unauthorized) (Section 17.4.2), but 4871 indicates that the client must first authenticate itself with the 4872 proxy. The proxy MUST return a Proxy-Authenticate header field 4873 (Section 18.33) containing a challenge applicable to the proxy for 4874 the requested resource. 4876 17.4.9. 408 Request Timeout 4878 The client did not produce a request within the time that the server 4879 was prepared to wait. The client MAY repeat the request without 4880 modifications at any later time. 4882 17.4.10. 410 Gone 4884 The requested resource is no longer available at the server and the 4885 forwarding address is not known. This condition is expected to be 4886 considered permanent. If the server does not know, or has no 4887 facility to determine, whether or not the condition is permanent, the 4888 status code 404 (Not Found) SHOULD be used instead. This response is 4889 cacheable unless indicated otherwise. 4891 The 410 response is primarily intended to assist the task of 4892 repository maintenance by notifying the recipient that the resource 4893 is intentionally unavailable and that the server owners desire that 4894 remote links to that resource be removed. Such an event is common 4895 for limited-time, promotional services and for resources belonging to 4896 individuals no longer working at the server's site. It is not 4897 necessary to mark all permanently unavailable resources as "gone" or 4898 to keep the mark for any length of time -- that is left to the 4899 discretion of the owner of the server. 4901 17.4.11. 411 Length Required 4903 The server refuses to accept the request without a defined Content- 4904 Length. The client MAY repeat the request if it adds a valid 4905 Content-Length header field containing the length of the message-body 4906 in the request message. 4908 17.4.12. 412 Precondition Failed 4910 The precondition given in one or more of the 'if-' request-header 4911 fields evaluated to false when it was tested on the server. See 4912 these sections for the 'if-' headers: If-Match Section 18.23, If- 4913 Modified-Since Section 18.24, and If-None-Match Section 18.25. This 4914 response code allows the client to place preconditions on the current 4915 resource meta information (header field data) and thus prevent the 4916 requested method from being applied to a resource other than the one 4917 intended. 4919 17.4.13. 413 Request Message Body Too Large 4921 The server is refusing to process a request because the request 4922 message body is larger than the server is willing or able to process. 4923 The server MAY close the connection to prevent the client from 4924 continuing the request. 4926 If the condition is temporary, the server SHOULD include a Retry- 4927 After header field to indicate that it is temporary and after what 4928 time the client MAY try again. 4930 17.4.14. 414 Request-URI Too Long 4932 The server is refusing to service the request because the Request-URI 4933 is longer than the server is willing to interpret. This rare 4934 condition is only likely to occur when a client has used a request 4935 with long query information, when the client has descended into a URI 4936 "black hole" of redirection (e.g., a redirected URI prefix that 4937 points to a suffix of itself), or when the server is under attack by 4938 a client attempting to exploit security holes present in some servers 4939 using fixed-length buffers for reading or manipulating the Request- 4940 URI. 4942 17.4.15. 415 Unsupported Media Type 4944 The server is refusing to service the request because the message 4945 body of the request is in a format not supported by the requested 4946 resource for the requested method. 4948 17.4.16. 451 Parameter Not Understood 4950 The recipient of the request does not support one or more parameters 4951 contained in the request. When returning this error message the 4952 sender SHOULD return a message body containing the offending 4953 parameter(s). 4955 17.4.17. 452 reserved 4957 This error code was removed from RFC 2326 [RFC2326] as it is 4958 obsolete. This error code MUST NOT be used anymore. 4960 17.4.18. 453 Not Enough Bandwidth 4962 The request was refused because there was insufficient bandwidth. 4963 This may, for example, be the result of a resource reservation 4964 failure. 4966 17.4.19. 454 Session Not Found 4968 The RTSP session identifier in the Session header is missing, 4969 invalid, or has timed out. 4971 17.4.20. 455 Method Not Valid in This State 4973 The client or server cannot process this request in its current 4974 state. The response MUST contain an Allow header to make error 4975 recovery possible. 4977 17.4.21. 456 Header Field Not Valid for Resource 4979 The server could not act on a required request header. For example, 4980 if PLAY contains the Range header field but the stream does not allow 4981 seeking. This error message may also be used for specifying when the 4982 time format in Range is impossible for the resource. In that case 4983 the Accept-Ranges header MUST be returned to inform the client of 4984 which format(s) that are allowed. 4986 17.4.22. 457 Invalid Range 4988 The Range value given is out of bounds, e.g., beyond the end of the 4989 presentation. 4991 17.4.23. 458 Parameter Is Read-Only 4993 The parameter to be set by SET_PARAMETER can be read but not 4994 modified. When returning this error message the sender SHOULD return 4995 a message body containing the offending parameter(s). 4997 17.4.24. 459 Aggregate Operation Not Allowed 4999 The requested method may not be applied on the URI in question since 5000 it is an aggregate (presentation) URI. The method may be applied on 5001 a media URI. 5003 17.4.25. 460 Only Aggregate Operation Allowed 5005 The requested method may not be applied on the URI in question since 5006 it is not an aggregate control (presentation) URI. The method may be 5007 applied on the aggregate control URI. 5009 17.4.26. 461 Unsupported Transport 5011 The Transport field did not contain a supported transport 5012 specification. 5014 17.4.27. 462 Destination Unreachable 5016 The data transmission channel could not be established because the 5017 client address could not be reached. This error will most likely be 5018 the result of a client attempt to place an invalid dest_addr 5019 parameter in the Transport field. 5021 17.4.28. 463 Destination Prohibited 5023 The data transmission channel was not established because the server 5024 prohibited access to the client address. This error is most likely 5025 the result of a client attempt to redirect media traffic to another 5026 destination with a dest_addr parameter in the Transport header. 5028 17.4.29. 464 Data Transport Not Ready Yet 5030 The data transmission channel to the media destination is not yet 5031 ready for carrying data. However, the responding agent still expects 5032 that the data transmission channel will be established at some point 5033 in time. Note, however, that this may result in a permanent failure 5034 like 462 "Destination Unreachable". 5036 An example when this error may occur is in the case a client sends a 5037 PLAY request to a server prior to ensuring that the TCP connections 5038 negotiated for carrying media data was successfully established (In 5039 violation of this specification). The server would use this error 5040 code to indicate that the requested action could not be performed due 5041 to the failure of completing the connection establishment. 5043 17.4.30. 465 Notification Reason Unknown 5045 This indicates that the client has received a PLAY_NOTIFY 5046 (Section 13.5) with a Notify-Reason header (Section 18.31) unknown to 5047 the client. 5049 17.4.31. 466 Key Management Error 5051 This indicates that there has been an error in a Key Management 5052 function used in conjunction with a request. For example usage of 5053 MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this 5054 error. 5056 17.4.32. 470 Connection Authorization Required 5058 The secured connection attempt needs user or client authorization 5059 before proceeding. The next hops certificate is included in this 5060 response in the Accept-Credentials header. 5062 17.4.33. 471 Connection Credentials not accepted 5064 When performing a secure connection over multiple connections, an 5065 intermediary has refused to connect to the next hop and carry out the 5066 request due to unacceptable credentials for the used policy. 5068 17.4.34. 472 Failure to establish secure connection 5070 A proxy fails to establish a secure connection to the next hop RTSP 5071 agent. This is primarily caused by a fatal failure at the TLS 5072 handshake, for example due to server not accepting any cipher suites. 5074 17.5. Server Error 5xx 5076 Response status codes beginning with the digit "5" indicate cases in 5077 which the server is aware that it has erred or is incapable of 5078 performing the request The server SHOULD include a message body 5079 containing an explanation of the error situation, and whether it is a 5080 temporary or permanent condition. User agents SHOULD display any 5081 included message body to the user. These response codes are 5082 applicable to any request method. 5084 17.5.1. 500 Internal Server Error 5086 The server encountered an unexpected condition which prevented it 5087 from fulfilling the request. 5089 17.5.2. 501 Not Implemented 5091 The server does not support the functionality required to fulfill the 5092 request. This is the appropriate response when the server does not 5093 recognize the request method and is not capable of supporting it for 5094 any resource. 5096 17.5.3. 502 Bad Gateway 5098 The server, while acting as a gateway or proxy, received an invalid 5099 response from the upstream server it accessed in attempting to 5100 fulfill the request. 5102 17.5.4. 503 Service Unavailable 5104 The server is currently unable to handle the request due to a 5105 temporary overloading or maintenance of the server. The implication 5106 is that this is a temporary condition which will be alleviated after 5107 some delay. If known, the length of the delay MAY be indicated in a 5108 Retry-After header. If no Retry-After is given, the client SHOULD 5109 handle the response as it would for a 500 response. The client MUST 5110 honor the length, if given in the Retry-After header. 5112 Note: The existence of the 503 status code does not imply that 5113 a server must use it when becoming overloaded. Some servers 5114 may wish to simply refuse the connection. 5116 17.5.5. 504 Gateway Timeout 5118 The server, while acting as a proxy, did not receive a timely 5119 response from the upstream server specified by the URI or some other 5120 auxiliary server (e.g., DNS) it needed to access in attempting to 5121 complete the request. 5123 17.5.6. 505 RTSP Version Not Supported 5125 The server does not support, or refuses to support, the RTSP protocol 5126 version that was used in the request message. The server is 5127 indicating that it is unable or unwilling to complete the request 5128 using the same major version as the client other than with this error 5129 message. The response SHOULD contain a message body describing why 5130 that version is not supported and what other protocols are supported 5131 by that server. 5133 17.5.7. 551 Option not supported 5135 A feature-tag given in the Require or the Proxy-Require fields was 5136 not supported. The Unsupported header MUST be returned stating the 5137 feature for which there is no support. 5139 18. Header Field Definitions 5141 +---------------+----------------+--------+---------+------+ 5142 | method | direction | object | acronym | Body | 5143 +---------------+----------------+--------+---------+------+ 5144 | DESCRIBE | C -> S | P,S | DES | r | 5145 | | | | | | 5146 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 5147 | | | | | | 5148 | OPTIONS | C -> S, S -> C | P,S | OPT | | 5149 | | | | | | 5150 | PAUSE | C -> S | P,S | PSE | | 5151 | | | | | | 5152 | PLAY | C -> S | P,S | PLY | | 5153 | | | | | | 5154 | PLAY_NOTIFY | S -> C | P,S | PNY | R | 5155 | | | | | | 5156 | REDIRECT | S -> C | P,S | RDR | | 5157 | | | | | | 5158 | SETUP | C -> S | S | STP | | 5159 | | | | | | 5160 | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | 5161 | | | | | | 5162 | TEARDOWN | C -> S | P,S | TRD | | 5163 | | | | | | 5164 | | S -> C | P | TRD | | 5165 +---------------+----------------+--------+---------+------+ 5167 Table 8: Overview of RTSP methods, their direction, and what objects 5168 (P: presentation, S: stream) they operate on. Body notes if a method 5169 is allowed to carry body and in which direction, R = Request, 5170 r=response. Note: It is allowed for all error messages 4xx and 5xx to 5171 have a body 5173 The general syntax for header fields is covered in Section 5.2. This 5174 section lists the full set of header fields along with notes on 5175 meaning, and usage. The syntax definition for header fields are 5176 present in Section 20.2.3. Throughout this section, we use [HX.Y] to 5177 informational refer to Section X.Y of the current HTTP/1.1 5178 specification RFC 2616 [RFC2616]. Examples of each header field are 5179 given. 5181 Information about header fields in relation to methods and proxy 5182 processing is summarized in Table 9, Table 10, Table 11, and 5183 Table 12. 5185 The "where" column describes the request and response types in which 5186 the header field can be used. Values in this column are: 5188 R: header field may only appear in requests; 5190 r: header field may only appear in responses; 5192 2xx, 4xx, etc.: A numerical value or range indicates response codes 5193 with which the header field can be used; 5195 c: header field is copied from the request to the response. 5197 An empty entry in the "where" column indicates that the header field 5198 may be present in both requests and responses. 5200 The "proxy" column describes the operations a proxy may perform on a 5201 header field. An empty proxy column indicates that the proxy MUST 5202 NOT do any changes to that header, all allowed operations are 5203 explicitly stated: 5205 a: A proxy can add or concatenate the header field if not present. 5207 m: A proxy can modify an existing header field value. 5209 d: A proxy can delete a header field value. 5211 r: A proxy needs to be able to read the header field, and thus 5212 this header field cannot be encrypted. 5214 The rest of the columns relate to the presence of a header field in a 5215 method. The method names when abbreviated, are according to Table 8: 5217 c: Conditional; requirements on the header field depend on the 5218 context of the message. 5220 m: The header field is mandatory. 5222 m*: The header field SHOULD be sent, but clients/servers need to be 5223 prepared to receive messages without that header field. 5225 o: The header field is optional. 5227 *: The header field MUST be present if the message body is not 5228 empty. See Section 18.16, Section 18.18 and Section 5.3 for 5229 details. 5231 -: The header field is not applicable. 5233 "Optional" means that a Client/Server MAY include the header field in 5234 a request or response. The Client/Server behavior when receiving 5235 such headers varies, for some it may ignore the header field, in 5236 other cases it is a request to process the header. This is regulated 5237 by the method and header descriptions. Example of headers that 5238 require processing are the Require and Proxy-Require header fields 5239 discussed in Section 18.41 and Section 18.35. A "mandatory" header 5240 field MUST be present in a request, and MUST be understood by the 5241 Client/Server receiving the request. A mandatory response header 5242 field MUST be present in the response, and the header field MUST be 5243 understood by the Client/Server processing the response. "Not 5244 applicable" means that the header field MUST NOT be present in a 5245 request. If one is placed in a request by mistake, it MUST be 5246 ignored by the Client/Server receiving the request. Similarly, a 5247 header field labeled "not applicable" for a response means that the 5248 Client/Server MUST NOT place the header field in the response, and 5249 the Client/Server MUST ignore the header field in the response. 5251 An RTSP agent MUST ignore extension headers that are not understood. 5253 The From and Location header fields contain an URI. If the URI 5254 contains a comma, or semicolon, the URI MUST be enclosed in double 5255 quotes ("). Any URI parameters are contained within these quotes. 5256 If the URI is not enclosed in double quote, any semicolon-delimited 5257 parameters are header-parameters, not URI parameters. 5259 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5260 | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | 5261 | | | xy | S | | | | | | 5262 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5263 | Accept | R | | o | - | - | - | - | - | 5264 | | | | | | | | | | 5265 | Accept-Credentia | R | rm | o | o | o | o | o | o | 5266 | ls | | | | | | | | | 5267 | | | | | | | | | | 5268 | Accept-Encoding | R | r | o | - | - | - | - | - | 5269 | | | | | | | | | | 5270 | Accept-Language | R | r | o | - | - | - | - | - | 5271 | | | | | | | | | | 5272 | Accept-Ranges | R | r | - | - | m | - | - | - | 5273 | | | | | | | | | | 5274 | Accept-Ranges | r | r | - | - | m | - | - | - | 5275 | | | | | | | | | | 5276 | Accept-Ranges | 456 | r | - | - | - | m | - | - | 5277 | | | | | | | | | | 5278 | Allow | r | am | c | c | c | - | - | - | 5279 | | | | | | | | | | 5280 | Allow | 405 | am | m | m | m | m | m | m | 5281 | | | | | | | | | | 5282 | Authorization | R | | o | o | o | o | o | o | 5283 | | | | | | | | | | 5284 | Bandwidth | R | | o | o | o | o | - | - | 5285 | | | | | | | | | | 5286 | Blocksize | R | | o | - | o | o | - | - | 5287 | | | | | | | | | | 5288 | Cache-Control | | r | o | - | o | - | - | - | 5289 | | | | | | | | | | 5290 | Connection | | ad | o | o | o | o | o | o | 5291 | | | | | | | | | | 5292 | Connection-Crede | 470,4 | ar | o | o | o | o | o | o | 5293 | ntials | 07 | | | | | | | | 5294 | | | | | | | | | | 5295 | Content-Base | r | | o | - | - | - | - | - | 5296 | | | | | | | | | | 5297 | Content-Base | 4xx,5 | | o | o | o | o | o | o | 5298 | | xx | | | | | | | | 5299 | | | | | | | | | | 5300 | Content-Encoding | R | r | - | - | - | - | - | - | 5301 | | | | | | | | | | 5302 | Content-Encoding | r | r | o | - | - | - | - | - | 5303 | | | | | | | | | | 5304 | Content-Encoding | 4xx,5 | r | o | o | o | o | o | o | 5305 | | xx | | | | | | | | 5306 | | | | | | | | | | 5307 | Content-Language | R | r | - | - | - | - | - | - | 5308 | | | | | | | | | | 5309 | Content-Language | r | r | o | - | - | - | - | - | 5310 | | | | | | | | | | 5311 | Content-Language | 4xx,5 | r | o | o | o | o | o | o | 5312 | | xx | | | | | | | | 5313 | | | | | | | | | | 5314 | Content-Length | r | r | * | - | - | - | - | - | 5315 | | | | | | | | | | 5316 | Content-Length | 4xx,5 | r | * | * | * | * | * | * | 5317 | | xx | | | | | | | | 5318 | | | | | | | | | | 5319 | Content-Location | r | r | o | - | - | - | - | - | 5320 | | | | | | | | | | 5321 | Content-Location | 4xx,5 | r | o | o | o | o | o | o | 5322 | | xx | | | | | | | | 5323 | | | | | | | | | | 5324 | Content-Type | r | r | * | - | - | - | - | - | 5325 | | | | | | | | | | 5326 | Content-Type | 4xx,5 | ar | * | * | * | * | * | * | 5327 | | xx | | | | | | | | 5328 | | | | | | | | | | 5329 | CSeq | Rc | rm | m | m | m | m | m | m | 5330 | | | | | | | | | | 5331 | Date | | am | o/ | o/* | o/* | o/* | o/* | o/* | 5332 | | | | * | | | | | | 5333 | | | | | | | | | | 5334 | Expires | r | r | o | - | o | - | - | - | 5335 | | | | | | | | | | 5336 | From | R | r | o | o | o | o | o | o | 5337 | | | | | | | | | | 5338 | If-Match | R | r | - | - | o | - | - | - | 5339 | | | | | | | | | | 5340 | If-Modified-Sinc | R | r | o | - | o | - | - | - | 5341 | e | | | | | | | | | 5342 | | | | | | | | | | 5343 | If-None-Match | R | r | o | - | o | - | - | - | 5344 | | | | | | | | | | 5345 | Last-Modified | r | r | o | - | o | - | - | - | 5346 | | | | | | | | | | 5347 | Location | 3rr | | o | o | o | o | o | o | 5348 +------------------+-------+-----+----+-----+-----+-----+-----+-----+ 5350 Table 9: Overview of RTSP header fields (A-L) related to methods 5351 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5353 +----------------+-------+------+-----+-----+-----+-----+-----+-----+ 5354 | Header | Where | Prox | DES | OPT | STP | PLY | PSE | TRD | 5355 | | | y | | | | | | | 5356 +----------------+-------+------+-----+-----+-----+-----+-----+-----+ 5357 | Media- | | | - | - | m | m | m | - | 5358 | Properties | | | | | | | | | 5359 | | | | | | | | | | 5360 | Media-Range | | | - | - | m | m | m | - | 5361 | | | | | | | | | | 5362 | MTag | r | r | o | - | o | - | - | - | 5363 | | | | | | | | | | 5364 | Pipelined-Requ | | amdr | - | o | o | o | o | o | 5365 | ests | | | | | | | | | 5366 | | | | | | | | | | 5367 | Proxy- | 407 | amr | m | m | m | m | m | m | 5368 | Authenticate | | | | | | | | | 5369 | | | | | | | | | | 5370 | Proxy- | R | rd | o | o | o | o | o | o | 5371 | Authorization | | | | | | | | | 5372 | | | | | | | | | | 5373 | Proxy- Require | R | ar | o | o | o | o | o | o | 5374 | | | | | | | | | | 5375 | Proxy- Require | r | r | c | c | c | c | c | c | 5376 | | | | | | | | | | 5377 | Proxy- | R | amr | c | c | c | c | c | c | 5378 | Supported | | | | | | | | | 5379 | Proxy- | r | | c | c | c | c | c | c | 5380 | Supported | | | | | | | | | 5381 | | | | | | | | | | 5382 | Public | r | amr | - | m | - | - | - | - | 5383 | | | | | | | | | | 5384 | Public | 501 | amr | m | m | m | m | m | m | 5385 | | | | | | | | | | 5386 | Range | R | | - | - | - | o | - | - | 5387 | | | | | | | | | | 5388 | Range | r | | - | - | c | m | m | - | 5389 | | | | | | | | | | 5390 | Referrer | R | | o | o | o | o | o | o | 5391 | | | | | | | | | | 5392 | Request- | R | | - | - | - | - | - | - | 5393 | Status | | | | | | | | | 5394 | | | | | | | | | | 5395 | Require | R | | o | o | o | o | o | o | 5396 | | | | | | | | | | 5397 | Retry-After | 3rr,5 | | o | o | o | o | o | - | 5398 | | 03 | | | | | | | | 5399 | | | | | | | | | | 5400 | Retry-After | 413 | | o | - | - | - | - | - | 5401 | | | | | | | | | | 5402 | RTP-Info | r | | - | - | c | c | - | - | 5403 | | | | | | | | | | 5404 | Scale | R | r | - | - | - | o | - | - | 5405 | | | | | | | | | | 5406 | Scale | r | amr | - | - | - | c | - | - | 5407 | | | | | | | | | | 5408 | Seek-Style | R | | - | - | - | o | - | - | 5409 | | | | | | | | | | 5410 | Seek-Style | r | | - | - | - | m | - | - | 5411 | | | | | | | | | | 5412 | Server | R | r | - | o | - | - | - | o | 5413 | | | | | | | | | | 5414 | Server | r | r | o | o | o | o | o | o | 5415 | | | | | | | | | | 5416 | Session | R | r | - | o | o | m | m | m | 5417 | | | | | | | | | | 5418 | Session | r | r | - | c | m | m | m | o | 5419 | | | | | | | | | | 5420 | Speed | R | admr | - | - | - | o | - | - | 5421 | | | | | | | | | | 5422 | Speed | r | admr | - | - | - | c | - | - | 5423 | | | | | | | | | | 5424 | Supported | R | amr | o | o | o | o | o | o | 5425 | | | | | | | | | | 5426 | Supported | r | amr | c | c | c | c | c | c | 5427 | Terminate-Reas | R | r | - | - | - | - | - | - | 5428 | on | | | | | | | | | 5429 | | | | | | | | | | 5430 | Timestamp | R | admr | o | o | o | o | o | o | 5431 | | | | | | | | | | 5432 | Timestamp | c | admr | m | m | m | m | m | m | 5433 | | | | | | | | | | 5434 | Transport | | mr | - | - | m | - | - | - | 5435 | | | | | | | | | | 5436 | Unsupported | r | | c | c | c | c | c | c | 5437 | | | | | | | | | | 5438 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 5439 | | | | | | | | | | 5440 | Via | R | amr | o | o | o | o | o | o | 5441 | | | | | | | | | | 5442 | Via | c | dr | m | m | m | m | m | m | 5443 | | | | | | | | | | 5444 | WWW- | 401 | | m | m | m | m | m | m | 5445 | Authenticate | | | | | | | | | 5446 +----------------+-------+------+-----+-----+-----+-----+-----+-----+ 5448 Table 10: Overview of RTSP header fields (M-W) related to methods 5449 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5451 +------------------------+---------+-------+-----+-----+-----+-----+ 5452 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5453 +------------------------+---------+-------+-----+-----+-----+-----+ 5454 | Accept | R | arm | o | o | - | - | 5455 | | | | | | | | 5456 | Accept-Credentials | R | rm | o | o | o | - | 5457 | | | | | | | | 5458 | Accept-Encoding | R | r | o | o | o | - | 5459 | | | | | | | | 5460 | Accept-Language | R | r | o | o | o | - | 5461 | | | | | | | | 5462 | Accept-Ranges | | rm | o | - | - | - | 5463 | | | | | | | | 5464 | Allow | 405 | amr | m | m | m | - | 5465 | | | | | | | | 5466 | Authorization | R | | o | o | o | - | 5467 | | | | | | | | 5468 | Bandwidth | R | | - | o | - | - | 5469 | | | | | | | | 5470 | Blocksize | R | | - | o | - | - | 5471 | | | | | | | | 5472 | Cache-Control | | r | o | o | - | - | 5473 | | | | | | | | 5474 | Connection | | | o | o | o | o | 5475 | Connection-Credentials | 470,407 | ar | o | o | o | - | 5476 | | | | | | | | 5477 | Content-Base | R | | o | o | - | - | 5478 | | | | | | | | 5479 | Content-Base | r | | o | o | - | - | 5480 | | | | | | | | 5481 | Content-Base | 4xx,5xx | | o | o | o | o | 5482 | | | | | | | | 5483 | Content-Encoding | R | r | o | o | - | - | 5484 | | | | | | | | 5485 | Content-Encoding | r | r | o | o | - | - | 5486 | | | | | | | | 5487 | Content-Encoding | 4xx,5xx | r | o | o | o | o | 5488 | | | | | | | | 5489 | Content-Language | R | r | o | o | - | - | 5490 | | | | | | | | 5491 | Content-Language | r | r | o | o | - | - | 5492 | | | | | | | | 5493 | Content-Language | 4xx,5xx | r | o | o | o | o | 5494 | | | | | | | | 5495 | Content-Length | R | r | * | * | - | - | 5496 | | | | | | | | 5497 | Content-Length | r | r | * | * | - | - | 5498 | | | | | | | | 5499 | Content-Length | 4xx,5xx | r | * | * | * | * | 5500 | | | | | | | | 5501 | Content-Location | R | | o | o | - | - | 5502 | | | | | | | | 5503 | Content-Location | r | | o | o | - | - | 5504 | | | | | | | | 5505 | Content-Location | 4xx,5xx | | o | o | o | o | 5506 | | | | | | | | 5507 | Content-Type | R | | * | * | - | - | 5508 | | | | | | | | 5509 | Content-Type | r | | * | * | - | - | 5510 | | | | | | | | 5511 | Content-Type | 4xx,5xx | | * | * | * | * | 5512 | | | | | | | | 5513 | CSeq | R,c | mr | m | m | m | m | 5514 | | | | | | | | 5515 | Date | R | a | o | o | m | o | 5516 | | | | | | | | 5517 | Date | r | am | o | o | o | o | 5518 | | | | | | | | 5519 | Expires | r | r | - | - | - | - | 5520 | | | | | | | | 5521 | From | R | r | o | o | o | - | 5522 | | | | | | | | 5523 | If-Match | R | r | - | - | - | - | 5524 | | | | | | | | 5525 | If-Modified-Since | R | am | o | - | - | - | 5526 | | | | | | | | 5527 | If-None-Match | R | am | o | - | - | - | 5528 | | | | | | | | 5529 | Last-Modified | R | r | - | - | - | - | 5530 | | | | | | | | 5531 | Last-Modified | r | r | o | - | - | - | 5532 | | | | | | | | 5533 | Location | 3rr | | o | o | o | - | 5534 | | | | | | | | 5535 | Location | R | | - | - | m | - | 5536 | | | | | | | | 5537 | Media-Properties | R | amr | o | - | - | c | 5538 | | | | | | | | 5539 | Media-Properties | r | mr | c | - | - | - | 5540 | | | | | | | | 5541 | Media-Range | R | | o | - | - | c | 5542 | | | | | | | | 5543 | Media-Range | r | | c | - | - | - | 5544 | | | | | | | | 5545 | MTag | r | r | o | - | - | - | 5546 | | | | | | | | 5547 | Notify-Reason | R | | - | - | - | m | 5548 | | | | | | | | 5549 | Pipelined-Requests | R | amdr | o | o | - | - | 5550 | | | | | | | | 5551 | Proxy-Authenticate | 407 | amr | m | m | m | - | 5552 | | | | | | | | 5553 | Proxy-Authorization | R | rd | o | o | o | - | 5554 | | | | | | | | 5555 | Proxy-Require | R | ar | o | o | o | - | 5556 | | | | | | | | 5557 | Proxy-Require | r | r | c | c | c | - | 5558 | | | | | | | | 5559 | Proxy-Supported | R | amr | c | c | c | - | 5560 | | | | | | | | 5561 | Proxy-Supported | r | | c | c | c | - | 5562 | | | | | | | | 5563 | Public | 501 | admr | m | m | m | - | 5564 +------------------------+---------+-------+-----+-----+-----+-----+ 5566 Table 11: Overview of RTSP header fields (A-P) related to methods 5567 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5569 +------------------+---------+-------+-----+-----+-----+-----+ 5570 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5571 +------------------+---------+-------+-----+-----+-----+-----+ 5572 | Range | R | | o | - | o | m | 5573 | | | | | | | | 5574 | Referrer | R | | o | o | o | - | 5575 | | | | | | | | 5576 | Request-Status | R | | - | - | - | c | 5577 | | | | | | | | 5578 | Require | R | r | o | o | o | - | 5579 | | | | | | | | 5580 | Retry-After | 3rr,503 | | o | o | - | - | 5581 | | | | | | | | 5582 | Retry-After | 413 | | o | o | - | - | 5583 | | | | | | | | 5584 | RTP-Info | R | r | o | - | - | C | 5585 | | | | | | | | 5586 | RTP-Info | r | r | c | - | - | - | 5587 | | | | | | | | 5588 | Scale | | | - | - | - | c | 5589 | | | | | | | | 5590 | Seek-Style | | | - | - | - | - | 5591 | | | | | | | | 5592 | Server | R | r | o | o | o | o | 5593 | | | | | | | | 5594 | Server | r | r | o | o | - | - | 5595 | | | | | | | | 5596 | Session | R | r | o | o | o | m | 5597 | | | | | | | | 5598 | Session | r | r | c | c | o | m | 5599 | | | | | | | | 5600 | Speed | | | - | - | - | - | 5601 | | | | | | | | 5602 | Supported | R | adrm | o | o | o | - | 5603 | | | | | | | | 5604 | Supported | r | adrm | c | c | c | - | 5605 | | | | | | | | 5606 | Terminate-Reason | R | r | - | - | m | - | 5607 | | | | | | | | 5608 | Timestamp | R | adrm | o | o | o | - | 5609 | | | | | | | | 5610 | Timestamp | c | adrm | m | m | m | - | 5611 | | | | | | | | 5612 | Transport | | mr | - | - | - | - | 5613 | | | | | | | | 5614 | Unsupported | r | arm | c | c | c | - | 5615 | | | | | | | | 5616 | User-Agent | R | r | m* | m* | - | - | 5617 | User-Agent | r | r | m* | m* | m* | m* | 5618 | | | | | | | | 5619 | Via | R | amr | o | o | o | - | 5620 | | | | | | | | 5621 | Via | c | dr | m | m | m | - | 5622 | | | | | | | | 5623 | WWW-Authenticate | 401 | | m | m | m | - | 5624 +------------------+---------+-------+-----+-----+-----+-----+ 5626 Table 12: Overview of RTSP header fields (R-W) related to methods 5627 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5629 18.1. Accept 5631 The Accept request-header field can be used to specify certain 5632 presentation description and parameter media types [RFC4288] which 5633 are acceptable for the response to DESCRIBE and GET_PARAMETER 5634 requests. 5636 See Section 20.2.3 for the syntax. 5638 Example of use: 5639 Accept: application/example ;q=1.0, application/sdp 5641 18.2. Accept-Credentials 5643 The Accept-Credentials header is a request header used to indicate to 5644 any trusted intermediary how to handle further secured connections to 5645 proxies or servers. See Section 19 for the usage of this header. It 5646 MUST NOT be included in server to client requests. 5648 In a request the header MUST contain the method (User, Proxy, or Any) 5649 for approving credentials selected by the requester. The method MUST 5650 NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY 5651 change it to "user" to take the role of user approving each further 5652 hop. If the method is "User" the header contains zero or more of 5653 credentials that the client accepts. The header may contain zero 5654 credentials in the first RTSP request to a RTSP server when using the 5655 "User" method. This as the client has not yet received any 5656 credentials to accept. Each credential MUST consist of one URI 5657 identifying the proxy or server, the hash algorithm identifier, and 5658 the hash over that agent's DER encoded certificate [RFC5280] in 5659 Base64 [RFC4648]. All RTSP clients and proxies MUST implement the 5660 SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the 5661 DER encoded certificate. The SHA-256 algorithm is identified by the 5662 token "sha-256". 5664 The intention with allowing for other hash algorithms is to enable 5665 the future retirement of algorithms that are not implemented 5666 somewhere else than here. Thus the definition of future algorithms 5667 for this purpose is intended to be extremely limited. A feature tag 5668 can be used to ensure that support for the replacement algorithm 5669 exist. 5671 Example: 5672 Accept-Credentials:User 5673 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 5674 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 5676 18.3. Accept-Encoding 5678 The Accept-Encoding request-header field is similar to Accept, but 5679 restricts the content-codings (see Section 18.14),i.e. transformation 5680 codings of the message body, such as gzip compression, that are 5681 acceptable in the response. 5683 A server tests whether a content-coding is acceptable, according to 5684 an Accept-Encoding field, using these rules: 5686 1. If the content-coding is one of the content-codings listed in the 5687 Accept-Encoding field, then it is acceptable, unless it is 5688 accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of 5689 0 means "not acceptable.") 5691 2. The special "*" symbol in an Accept-Encoding field matches any 5692 available content-coding not explicitly listed in the header 5693 field. 5695 3. If multiple content-codings are acceptable, then the acceptable 5696 content-coding with the highest non-zero qvalue is preferred. 5698 4. The "identity" content-coding is always acceptable, i.e. no 5699 transformation at all, unless specifically refused because the 5700 Accept-Encoding field includes "identity;q=0", or because the 5701 field includes "*;q=0" and does not explicitly include the 5702 "identity" content-coding. If the Accept-Encoding field-value is 5703 empty, then only the "identity" encoding is acceptable. 5705 If an Accept-Encoding field is present in a request, and if the 5706 server cannot send a response which is acceptable according to the 5707 Accept-Encoding header, then the server SHOULD send an error response 5708 with the 406 (Not Acceptable) status code. 5710 If no Accept-Encoding field is present in a request, the server MAY 5711 assume that the client will accept any content coding. In this case, 5712 if "identity" is one of the available content-codings, then the 5713 server SHOULD use the "identity" content-coding, unless it has 5714 additional information that a different content-coding is meaningful 5715 to the client. 5717 18.4. Accept-Language 5719 The Accept-Language request-header field is similar to Accept, but 5720 restricts the set of natural languages that are preferred as a 5721 response to the request. Note that the language specified applies to 5722 the presentation description and any reason phrases, but not the 5723 media content. 5725 A language tag identifies a natural language spoken, written, or 5726 otherwise conveyed by human beings for communication of information 5727 to other human beings. Computer languages are explicitly excluded. 5728 The syntax and registry of RTSP 2.0 language tags is the same as that 5729 defined by [RFC5646]. 5731 Each language-range MAY be given an associated quality value which 5732 represents an estimate of the user's preference for the languages 5733 specified by that range. The quality value defaults to "q=1". For 5734 example: 5736 Accept-Language: da, en-gb;q=0.8, en;q=0.7 5738 would mean: "I prefer Danish, but will accept British English and 5739 other types of English." A language-range matches a language-tag if 5740 it exactly equals the full tag, or if it exactly equals a prefix of 5741 the tag, i.e., the primary-tag in the ABNF, such that the character 5742 following primary-tag is "-". The special range "*", if present in 5743 the Accept-Language field, matches every tag not matched by any other 5744 range present in the Accept-Language field. 5746 Note: This use of a prefix matching rule does not imply that 5747 language tags are assigned to languages in such a way that it is 5748 always true that if a user understands a language with a certain 5749 tag, then this user will also understand all languages with tags 5750 for which this tag is a prefix. The prefix rule simply allows the 5751 use of prefix tags if this is the case. 5753 In the process of selecting a language, each language-tag is assigned 5754 a qualification factor, i.e., if a language being supported by the 5755 client is actually supported by the server and what "preference" 5756 level the language achieves. The quality value (q-value) of the 5757 longest language-range in the field that matches the language-tag is 5758 assigned as the qualification factor for a particular language-tag. 5759 If no language-range in the field matches the tag, the language 5760 qualification factor assigned is 0. If no Accept-Language header is 5761 present in the request, the server SHOULD assume that all languages 5762 are equally acceptable. If an Accept-Language header is present, 5763 then all languages which are assigned a qualification factor greater 5764 than 0 are acceptable. 5766 18.5. Accept-Ranges 5768 The Accept-Ranges general-header field allows indication of the 5769 format supported in the Range header. The client MUST include the 5770 header in SETUP requests to indicate which formats it support to 5771 receive in PLAY and PAUSE responses, and REDIRECT requests. The 5772 server MUST include the header in SETUP and 456 error responses to 5773 indicate the formats supported for the resource indicated by the 5774 request URI. The header MAY be included in GET_PARAMETER request and 5775 response pairs. The GET_PARAMETER request MUST contain a Session 5776 header to identify the session context the request is related to. 5777 The requester and responder will indicate their capabilities 5778 regarding Range formats respectively. 5780 Accept-Ranges: NPT, SMPTE 5782 The syntax is defined in Section 20.2.3. 5784 18.6. Allow 5786 The Allow message-header field lists the methods supported by the 5787 resource identified by the Request-URI. The purpose of this field is 5788 to strictly inform the recipient of valid methods associated with the 5789 resource. An Allow header field MUST be present in a 405 (Method Not 5790 Allowed) response. The Allow header MUST also be present in all 5791 OPTIONS responses where the content of the header will not include 5792 exactly the same methods as listed in the Public header. 5794 The Allow MUST also be included in SETUP and DESCRIBE responses, if 5795 the methods allowed for the resource is different than the complete 5796 set of methods defined in this memo. 5798 Example of use: 5799 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 5801 18.7. Authorization 5803 An RTSP client that wishes to authenticate itself with a server using 5804 authentication mechanism from HTTP [RFC2617] , usually, but not 5805 necessarily, after receiving a 401 response, does so by including an 5806 Authorization request-header field with the request. The 5807 Authorization field value consists of credentials containing the 5808 authentication information of the user agent for the realm of the 5809 resource being requested. 5811 If a request is authenticated and a realm specified, the same 5812 credentials SHOULD be valid for all other requests within this realm 5813 (assuming that the authentication scheme itself does not require 5814 otherwise, such as credentials that vary according to a challenge 5815 value or using synchronized clocks). 5817 When a shared cache (see Section 16) receives a request containing an 5818 Authorization field, it MUST NOT return the corresponding response as 5819 a reply to any other request, unless one of the following specific 5820 exceptions holds: 5822 1. If the response includes the "max-age" cache-control directive, 5823 the cache MAY use that response in replying to a subsequent 5824 request. But (if the specified maximum age has passed) a proxy 5825 cache MUST first revalidate it with the origin server, using the 5826 request-headers from the new request to allow the origin server 5827 to authenticate the new request. (This is the defined behavior 5828 for max-age.) If the response includes "max-age=0", the proxy 5829 MUST always revalidate it before re-using it. 5831 2. If the response includes the "must-revalidate" cache-control 5832 directive, the cache MAY use that response in replying to a 5833 subsequent request. But if the response is stale, all caches 5834 MUST first revalidate it with the origin server, using the 5835 request-headers from the new request to allow the origin server 5836 to authenticate the new request. 5838 3. If the response includes the "public" cache-control directive, it 5839 MAY be returned in reply to any subsequent request. 5841 18.8. Bandwidth 5843 The Bandwidth request-header field describes the estimated bandwidth 5844 available to the client, expressed as a positive integer and measured 5845 in kilobits per second. The bandwidth available to the client may 5846 change during an RTSP session, e.g., due to mobility, congestion, 5847 etc. 5849 Clients may not be able to accurately determine the available 5850 bandwidth, for example due to that first hop is not a bottleneck. 5851 For example most local area networks (LAN) will not be a bottleneck 5852 if the server is not in the same LAN. Thus link speeds of WLAN or 5853 Ethernet networks are normally not a basis for estimating the 5854 available bandwidth. Cellular devices or other devices directly 5855 connected to a modem or connection enabling device may more 5856 accurately estimate the bottleneck bandwidth and what is reasonable 5857 share of it for RTSP controlled media. The client will also need to 5858 take into account other traffic sharing the bottleneck. For example 5859 by only assigning a certain fraction to RTSP and its media streams. 5860 It is RECOMMENDED that only clients that has accurate and explicit 5861 information about bandwidth bottlenecks uses this header. 5863 This header is not a substitute for proper congestion control. Only 5864 a method providing an initial estimate and coarsely determine if the 5865 selected content can be delivered at all. 5867 Example: 5868 Bandwidth: 62360 5870 18.9. Blocksize 5872 The Blocksize request-header field is sent from the client to the 5873 media server asking the server for a particular media packet size. 5874 This packet size does not include lower-layer headers such as IP, 5875 UDP, or RTP. The server is free to use a blocksize which is lower 5876 than the one requested. The server MAY truncate this packet size to 5877 the closest multiple of the minimum, media-specific block size, or 5878 override it with the media-specific size if necessary. The block 5879 size MUST be a positive decimal number, measured in octets. The 5880 server only returns an error (4xx) if the value is syntactically 5881 invalid. 5883 18.10. Cache-Control 5885 The Cache-Control general-header field is used to specify directives 5886 that MUST be obeyed by all caching mechanisms along the request/ 5887 response chain. 5889 Cache directives MUST be passed through by a proxy or gateway 5890 application, regardless of their significance to that application, 5891 since the directives may be applicable to all recipients along the 5892 request/response chain. It is not possible to specify a cache- 5893 directive for a specific cache. 5895 Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, 5896 SET_PARAMETER and SETUP request and its response. Note: Cache- 5897 Control does not govern only the caching of responses as for HTTP, 5898 instead it also applies to the media stream identified by the SETUP 5899 request. The RTSP requests are generally not cacheable, for further 5900 information see Section 16. Below is the description of the cache 5901 directives that can be included in the Cache-Control header. 5903 no-cache: Indicates that the media stream MUST NOT be cached 5904 anywhere. This allows an origin server to prevent caching even 5905 by caches that have been configured to return stale responses 5906 to client requests. Note, there is no security function 5907 enforcing that the content can't be cached. 5909 public: Indicates that the media stream is cacheable by any cache. 5911 private: Indicates that the media stream is intended for a single 5912 user and MUST NOT be cached by a shared cache. A private (non- 5913 shared) cache may cache the media streams. 5915 no-transform: An intermediate cache (proxy) may find it useful to 5916 convert the media type of a certain stream. A proxy might, for 5917 example, convert between video formats to save cache space or 5918 to reduce the amount of traffic on a slow link. Serious 5919 operational problems may occur, however, when these 5920 transformations have been applied to streams intended for 5921 certain kinds of applications. For example, applications for 5922 medical imaging, scientific data analysis and those using end- 5923 to-end authentication all depend on receiving a stream that is 5924 bit-for-bit identical to the original media stream. Therefore, 5925 if a response includes the no-transform directive, an 5926 intermediate cache or proxy MUST NOT change the encoding of the 5927 stream. Unlike HTTP, RTSP does not provide for partial 5928 transformation at this point, e.g., allowing translation into a 5929 different language. 5931 only-if-cached: In some cases, such as times of extremely poor 5932 network connectivity, a client may want a cache to return only 5933 those media streams that it currently has stored, and not to 5934 receive these from the origin server. To do this, the client 5935 may include the only-if-cached directive in a request. If it 5936 receives this directive, a cache SHOULD either respond using a 5937 cached media stream that is consistent with the other 5938 constraints of the request, or respond with a 504 (Gateway 5939 Timeout) status. However, if a group of caches is being 5940 operated as a unified system with good internal connectivity, 5941 such a request MAY be forwarded within that group of caches. 5943 max-stale: Indicates that the client is willing to accept a media 5944 stream that has exceeded its expiration time. If max-stale is 5945 assigned a value, then the client is willing to accept a 5946 response that has exceeded its expiration time by no more than 5947 the specified number of seconds. If no value is assigned to 5948 max-stale, then the client is willing to accept a stale 5949 response of any age. 5951 min-fresh: Indicates that the client is willing to accept a media 5952 stream whose freshness lifetime is no less than its current age 5953 plus the specified time in seconds. That is, the client wants 5954 a response that will still be fresh for at least the specified 5955 number of seconds. 5957 must-revalidate: When the must-revalidate directive is present in a 5958 SETUP response received by a cache, that cache MUST NOT use the 5959 entry after it becomes stale to respond to a subsequent request 5960 without first revalidating it with the origin server. That is, 5961 the cache is required to do an end-to-end revalidation every 5962 time, if, based solely on the origin server's Expires, the 5963 cached response is stale. 5965 proxy-revalidate: The proxy-revalidate directive has the same 5966 meaning as the must-revalidate directive, except that it does 5967 not apply to non-shared user agent caches. It can be used on a 5968 response to an authenticated request to permit the user's cache 5969 to store and later return the response without needing to 5970 revalidate it (since it has already been authenticated once by 5971 that user), while still requiring proxies that service many 5972 users to revalidate each time (in order to make sure that each 5973 user has been authenticated). Note that such authenticated 5974 responses also need the public cache control directive in order 5975 to allow them to be cached at all. 5977 max-age: When an intermediate cache is forced, by means of a max- 5978 age=0 directive, to revalidate its own cache entry, and the 5979 client has supplied its own validator in the request, the 5980 supplied validator might differ from the validator currently 5981 stored with the cache entry. In this case, the cache MAY use 5982 either validator in making its own request without affecting 5983 semantic transparency. 5985 However, the choice of validator might affect performance. The best 5986 approach is for the intermediate cache to use its own validator when 5987 making its request. If the server replies with 304 (Not Modified), 5988 then the cache can return its now validated copy to the client with a 5989 200 (OK) response. If the server replies with a new message body and 5990 cache validator, however, the intermediate cache can compare the 5991 returned validator with the one provided in the client's request, 5992 using the strong comparison function. If the client's validator is 5993 equal to the origin server's, then the intermediate cache simply 5994 returns 304 (Not Modified). Otherwise, it returns the new message 5995 body with a 200 (OK) response. 5997 18.11. Connection 5999 The Connection general-header field allows the sender to specify 6000 options that are desired for that particular connection and MUST NOT 6001 be communicated by proxies over further connections. 6003 RTSP 2.0 proxies MUST parse the Connection header field before a 6004 message is forwarded and, for each connection-token in this field, 6005 remove any header field(s) from the message with the same name as the 6006 connection-token. Connection options are signaled by the presence of 6007 a connection-token in the Connection header field, not by any 6008 corresponding additional header field(s), since the additional header 6009 field may not be sent if there are no parameters associated with that 6010 connection option. 6012 Message headers listed in the Connection header MUST NOT include end- 6013 to-end headers, such as Cache-Control. 6015 RTSP 2.0 defines the "close" connection option for the sender to 6016 signal that the connection will be closed after completion of the 6017 response. For example, Connection: close in either the request or 6018 the response header fields indicates that the connection SHOULD NOT 6019 be considered `persistent' (Section 10.2) after the current request/ 6020 response is complete. 6022 The use of the connection option "close" in RTSP messages SHOULD be 6023 limited to error messages when the server is unable to recover and 6024 therefore see it necessary to close the connection. The reason is 6025 that the client has the choice of continuing using a connection 6026 indefinitely, as long as it sends valid messages. 6028 18.12. Connection-Credentials 6030 The Connection-Credentials response header is used to carry the chain 6031 of credentials of any next hop that need to be approved by the 6032 requester. It MUST only be used in server to client responses. 6034 The Connection-Credentials header in an RTSP response MUST, if 6035 included, contain the credential information (in form of a list of 6036 certificates providing the chain of certification) of the next hop 6037 that an intermediary needs to securely connect to. The header MUST 6038 include the URI of the next hop (proxy or server) and a base64 6039 [RFC4648] encoded binary structure containing a sequence of DER 6040 encoded X.509v3 certificates[RFC5280] . 6042 The binary structure starts with the number of certificates 6043 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 6044 by NR_CERTS number of 16 bit unsigned integers providing the size in 6045 octets of each DER encoded certificate. This is followed by NR_CERTS 6046 number of DER encoded X.509v3 certificates in a sequence (chain). 6047 The proxy or server's certificate must come first in the structure. 6048 Each following certificate must directly certify the one preceding 6049 it. Because certificate validation requires that root keys be 6050 distributed independently, the self-signed certificate which 6051 specifies the root certificate authority may optionally be omitted 6052 from the chain, under the assumption that the remote end must already 6053 possess it in order to validate it in any case. 6055 Example: 6057 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 6059 Where MIIDNTCC... is a BASE64 encoding of the following structure: 6061 0 1 2 3 6062 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 6063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6064 | Number of certificates | Size of certificate #1 | 6065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6066 | Size of certificate #2 | Size of certificate #3 | 6067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6068 : DER Encoding of Certificate #1 : 6069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6070 : DER Encoding of Certificate #2 : 6071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6072 : DER Encoding of Certificate #3 : 6073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6075 18.13. Content-Base 6077 The Content-Base message-header field may be used to specify the base 6078 URI for resolving relative URIs within the message body. 6080 Content-Base: rtsp://media.example.com/movie/twister/ 6082 If no Content-Base field is present, the base URI of an message body 6083 is defined either by its Content-Location (if that Content-Location 6084 URI is an absolute URI) or the URI used to initiate the request, in 6085 that order of precedence. Note, however, that the base URI of the 6086 contents within the message-body may be redefined within that 6087 message-body. 6089 18.14. Content-Encoding 6091 The Content-Encoding header field is used as a modifier to the media- 6092 type. When present, its value indicates what additional content 6093 codings have been applied to the message body, and thus what decoding 6094 mechanisms must be applied in order to obtain the media-type 6095 referenced by the Content-Type header field. Content-Encoding is 6096 primarily used to allow a document to be compressed without losing 6097 the identity of its underlying media type. 6099 The content-coding is a characteristic of the message body identified 6100 by the Request-URI. Typically, the message body is stored with this 6101 encoding and is only decoded before rendering or analogous usage. 6102 However, a non-transparent proxy MAY modify the content-coding if the 6103 new coding is known to be acceptable to the recipient, unless the 6104 "no-transform" cache-control directive is present in the message. 6106 If the content-coding of a message body is not "identity", then the 6107 response MUST include a Content-Encoding Message-body header that 6108 lists the non-identity content-coding(s) used. 6110 If the content-coding of a message body in a request message is not 6111 acceptable to the origin server, the server SHOULD respond with a 6112 status code of 415 (Unsupported Media Type). 6114 If multiple encodings have been applied to a message body, the 6115 content codings MUST be listed in the order in which they were 6116 applied, first to last from left to right. Additional information 6117 about the encoding parameters MAY be provided by other header fields 6118 not defined by this specification. 6120 18.15. Content-Language 6122 The Content-Language header field describes the natural language(s) 6123 of the intended audience for the enclosed message body. Note that 6124 this might not be equivalent to all the languages used within the 6125 message body. 6127 Language tags are mentioned in Section 18.4. The primary purpose of 6128 Content-Language is to allow a user to identify and differentiate 6129 entities according to the user's own preferred language. Thus, if 6130 the body content is intended only for a Danish-literate audience, the 6131 appropriate field is 6133 Content-Language: da 6135 If no Content-Language is specified, the default is that the content 6136 is intended for all language audiences. This might mean that the 6137 sender does not consider it to be specific to any natural language, 6138 or that the sender does not know for which language it is intended. 6140 Multiple languages MAY be listed for content that is intended for 6141 multiple audiences. For example, a rendition of the "Treaty of 6142 Waitangi," presented simultaneously in the original Maori and English 6143 versions, would call for 6145 Content-Language: mi, en 6147 However, just because multiple languages are present within a message 6148 body does not mean that it is intended for multiple linguistic 6149 audiences. An example would be a beginner's language primer, such as 6150 "A First Lesson in Latin," which is clearly intended to be used by an 6151 English-literate audience. In this case, the Content-Language would 6152 properly only include "en". 6154 Content-Language MAY be applied to any media type -- it is not 6155 limited to textual documents. 6157 18.16. Content-Length 6159 The Content-Length general-header field contains the length of the 6160 message body of the RTSP message (i.e. after the double CRLF 6161 following the last header). Unlike HTTP, it MUST be included in all 6162 messages that carry a message body beyond the header portion of the 6163 RTSP message. If it is missing, a default value of zero is assumed. 6164 Any Content-Length greater than or equal to zero is a valid value. 6166 18.17. Content-Location 6168 The Content-Location header field MAY be used to supply the resource 6169 location for the message body enclosed in the message when that body 6170 is accessible from a location separate from the requested resource's 6171 URI. A server SHOULD provide a Content-Location for the variant 6172 corresponding to the response message body; especially in the case 6173 where a resource has multiple variants associated with it, and those 6174 entities actually have separate locations by which they might be 6175 individually accessed, the server SHOULD provide a Content-Location 6176 for the particular variant which is returned. 6178 As example, if an RTSP client performs a DESCRIBE request on a given 6179 resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", 6180 then the server may use additional information, such as the User- 6181 Agent header, to determine the capabilities of the agent. The server 6182 will then return a media description tailored to that class of RTSP 6183 agents. To indicate which specific description the agent receives 6184 the resource identifier 6185 ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is 6186 provided in Content-Location, while the description is still a valid 6187 response for the generic resource identifier. Thus enabling both 6188 debugging and cache operation as discussed below. 6190 The Content-Location value is not a replacement for the original 6191 requested URI; it is only a statement of the location of the resource 6192 corresponding to this particular variant at the time of the request. 6193 Future requests MAY specify the Content-Location URI as the request 6194 URI if the desire is to identify the source of that particular 6195 variant. This is useful if the RTSP agent desires to verify if the 6196 resource variant is current through a conditional request. 6198 A cache cannot assume that a message body with a Content-Location 6199 different from the URI used to retrieve it can be used to respond to 6200 later requests on that Content-Location URI. However, the Content- 6201 Location can be used to differentiate between multiple variants 6202 retrieved from a single requested resource. 6204 If the Content-Location is a relative URI, the relative URI is 6205 interpreted relative to the Request-URI. 6207 Note, that Content-Location can be used in some cases to derive the 6208 base-URI for relative URI present in session description formats. 6209 This needs to be taken into account when Content-Location is used. 6210 The easiest way to avoid needing to consider that issue is to include 6211 the Content-Base whenever the Content-Location is included. 6213 Note also, when using Media Tags in conjunction with Content-Location 6214 it is important that the different versions have different MTags, 6215 even if provided under different Content-Location URIs. This as they 6216 have still been provided under the same request URI. 6218 Note also, as in most cases the URI used in the DESCRIBE and the 6219 SETUP requests are different, the URI provided in a DESCRIBE Content- 6220 Location response can't directly be used in a SETUP request. Instead 6221 the extra step of resolving URIs combined with the media descriptions 6222 indication, like with SDP's a=control attribute. 6224 18.18. Content-Type 6226 The Content-Type header indicates the media type of the message body 6227 sent to the recipient. Note that the content types suitable for RTSP 6228 are likely to be restricted in practice to presentation descriptions 6229 and parameter-value types. 6231 18.19. CSeq 6233 The CSeq general-header field specifies the sequence number for an 6234 RTSP request-response pair. This field MUST be present in all 6235 requests and responses. For every RTSP request containing the given 6236 sequence number, the corresponding response will have the same 6237 number. Any retransmitted request MUST contain the same sequence 6238 number as the original (i.e., the sequence number is not incremented 6239 for retransmissions of the same request). For each new RTSP request 6240 the CSeq value MUST be incremented by one. The initial sequence 6241 number MAY be any number, however, it is RECOMMENDED to start at 0. 6242 Each sequence number series is unique between each requester and 6243 responder, i.e., the client has one series for its request to a 6244 server and the server has another when sending request to the client. 6245 Each requester and responder is identified with its socket address 6246 (IP address and port number). 6248 Proxies that aggregate several sessions on the same transport will 6249 have to ensure that the requests sent towards a particular server 6250 have a joint sequence number space, i.e., they will regularly need to 6251 renumber the CSeq header field in requests (from proxy to server) and 6252 responses (from server to proxy) to fulfill the rules for the header. 6253 The proxy MUST increase the CSeq by one for each request it 6254 transmits, without regard of different sessions. 6256 Example: 6257 CSeq: 239 6259 18.20. Date 6261 The Date header field represents the date and time at which the 6262 message was originated. The inclusion of the Date header in RTSP 6263 message follows these rules: 6265 o An RTSP message, sent either by the client or the server, 6266 containing a body MUST include a Date header, if the sending host 6267 has a clock; 6269 o Clients and servers are RECOMMENDED to include a Date header in 6270 all other RTSP messages, if the sending host has a clock; 6272 o If the server does not have a clock that can provide a reasonable 6273 approximation of the current time, its responses MUST NOT include 6274 a Date header field. In this case, this rule MUST be followed: 6275 Some origin server implementations might not have a clock 6276 available. An origin server without a clock MUST NOT assign 6277 Expires or Last-Modified values to a response, unless these values 6278 were associated with the resource by a system or user with a 6279 reliable clock. It MAY assign an Expires value that is known, at 6280 or before server configuration time, to be in the past (this 6281 allows "pre-expiration" of responses without storing separate 6282 Expires values for each resource). 6284 A received message that does not have a Date header field MUST be 6285 assigned one by the recipient if the message will be cached by that 6286 recipient . An RTSP implementation without a clock MUST NOT cache 6287 responses without revalidating them on every use. An RTSP cache, 6288 especially a shared cache, SHOULD use a mechanism, such as NTP, to 6289 synchronize its clock with a reliable external standard. 6291 The RTSP-date sent in a Date header SHOULD NOT represent a date and 6292 time subsequent to the generation of the message. It SHOULD 6293 represent the best available approximation of the date and time of 6294 message generation, unless the implementation has no means of 6295 generating a reasonably accurate date and time. In theory, the date 6296 ought to represent the moment just before the message body is 6297 generated. In practice, the date can be generated at any time during 6298 the message origination without affecting its semantic value. 6300 18.21. Expires 6302 The Expires message-header field gives a date and time after which 6303 the description or media-stream should be considered stale. The 6304 interpretation depends on the method: 6306 DESCRIBE response: The Expires header indicates a date and time 6307 after which the presentation description (body) SHOULD be 6308 considered stale. 6310 SETUP response: The Expires header indicate a date and time after 6311 which the media stream SHOULD be considered stale. 6313 A stale cache entry may not normally be returned by a cache (either a 6314 proxy cache or an user agent cache) unless it is first validated with 6315 the origin server (or with an intermediate cache that has a fresh 6316 copy of the message body). See Section 16 for further discussion of 6317 the expiration model. 6319 The presence of an Expires field does not imply that the original 6320 resource will change or cease to exist at, before, or after that 6321 time. 6323 The format is an absolute date and time as defined by RTSP-date. An 6324 example of its use is 6325 Expires: Thu, 01 Dec 1994 16:00:00 GMT 6327 RTSP/2.0 clients and caches MUST treat other invalid date formats, 6328 especially including the value "0", as having occurred in the past 6329 (i.e., already expired). 6331 To mark a response as "already expired," an origin server should use 6332 an Expires date that is equal to the Date header value. To mark a 6333 response as "never expires," an origin server SHOULD use an Expires 6334 date approximately one year from the time the response is sent. 6335 RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in 6336 the future. 6338 18.22. From 6340 The From request-header field, if given, SHOULD contain an Internet 6341 e-mail address for the human user who controls the requesting user 6342 agent. The address SHOULD be machine-usable, as defined by "mailbox" 6343 in [RFC1123]. 6345 This header field MAY be used for logging purposes and as a means for 6346 identifying the source of invalid or unwanted requests. It SHOULD 6347 NOT be used as an insecure form of access protection. The 6348 interpretation of this field is that the request is being performed 6349 on behalf of the person given, who accepts responsibility for the 6350 method performed. In particular, robot agents SHOULD include this 6351 header so that the person responsible for running the robot can be 6352 contacted if problems occur on the receiving end. 6354 The Internet e-mail address in this field MAY be separate from the 6355 Internet host which issued the request. For example, when a request 6356 is passed through a proxy the original issuer's address SHOULD be 6357 used. 6359 The client SHOULD NOT send the From header field without the user's 6360 approval, as it might conflict with the user's privacy interests or 6361 their site's security policy. It is strongly recommended that the 6362 user be able to disable, enable, and modify the value of this field 6363 at any time prior to a request. 6365 18.23. If-Match 6367 The If-Match request-header field is especially useful for ensuring 6368 the integrity of the presentation description, independent of how the 6369 presentation description was received. The presentation description 6370 can be fetched via means external to RTSP (such as HTTP) or via the 6371 DESCRIBE message. In the case of retrieving the presentation 6372 description via RTSP, the server implementation is guaranteeing the 6373 integrity of the description between the time of the DESCRIBE message 6374 and the SETUP message. By including the MTag given in or with the 6375 session description in an If-Match header part of the SETUP request, 6376 the client ensures that resources set up are matching the 6377 description. A SETUP request with the If-Match header for which the 6378 MTag validation check fails, MUST response using 412 (Precondition 6379 Failed). 6381 This validation check is also very useful if a session has been 6382 redirected from one server to another. 6384 18.24. If-Modified-Since 6386 The If-Modified-Since request-header field is used with the DESCRIBE 6387 and SETUP methods to make them conditional. If the requested variant 6388 has not been modified since the time specified in this field, a 6389 description will not be returned from the server (DESCRIBE) or a 6390 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 6391 response MUST be returned without any message-body. 6393 An example of the field is: 6394 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 6396 18.25. If-None-Match 6398 This request header can be used with one or several message body tags 6399 to make DESCRIBE requests conditional. A client that has one or more 6400 message bodies previously obtained from the resource, can verify that 6401 none of those entities is current by including a list of their 6402 associated message body tags in the If-None-Match header field. The 6403 purpose of this feature is to allow efficient updates of cached 6404 information with a minimum amount of transaction overhead. As a 6405 special case, the value "*" matches any current entity of the 6406 resource. 6408 If any of the message body tags match the message body tag of the 6409 message body that would have been returned in the response to a 6410 similar DESCRIBE request (without the If-None-Match header) on that 6411 resource, or if "*" is given and any current entity exists for that 6412 resource, then the server MUST NOT perform the requested method, 6413 unless required to do so because the resource's modification date 6414 fails to match that supplied in an If-Modified-Since header field in 6415 the request. Instead, if the request method was DESCRIBE, the server 6416 SHOULD respond with a 304 (Not Modified) response, including the 6417 cache-related header fields (particularly MTag) of one of the message 6418 bodies that matched. For all other request methods, the server MUST 6419 respond with a status of 412 (Precondition Failed). 6421 See Section 16.1.3 for rules on how to determine if two message body 6422 tags match. 6424 If none of the message body tags match, then the server MAY perform 6425 the requested method as if the If-None-Match header field did not 6426 exist, but MUST also ignore any If-Modified-Since header field(s) in 6427 the request. That is, if no message body tags match, then the server 6428 MUST NOT return a 304 (Not Modified) response. 6430 If the request would, without the If-None-Match header field, result 6431 in anything other than a 2xx or 304 status, then the If-None-Match 6432 header MUST be ignored. (See Section 16.1.4 for a discussion of 6433 server behavior when both If-Modified-Since and If-None-Match appear 6434 in the same request.) 6436 The result of a request having both an If-None-Match header field and 6437 an If-Match header field is unspecified and MUST be considered an 6438 illegal request. 6440 18.26. Last-Modified 6442 The Last-Modified message-header field indicates the date and time at 6443 which the origin server believes the presentation description or 6444 media stream was last modified. For the method DESCRIBE, the header 6445 field indicates the last modification date and time of the 6446 description, for SETUP that of the media stream. 6448 An origin server MUST NOT send a Last-Modified date which is later 6449 than the server's time of message origination. In such cases, where 6450 the resource's last modification would indicate some time in the 6451 future, the server MUST replace that date with the message 6452 origination date. 6454 An origin server SHOULD obtain the Last-Modified value of the message 6455 body as close as possible to the time that it generates the Date 6456 value of its response. This allows a recipient to make an accurate 6457 assessment of the message body's modification time, especially if the 6458 message body changes near the time that the response is generated. 6460 RTSP servers SHOULD send Last-Modified whenever feasible. 6462 18.27. Location 6464 The Location response-header field is used to redirect the recipient 6465 to a location other than the Request-URI for completion of the 6466 request or identification of a new resource. For 3xx responses, the 6467 location SHOULD indicate the server's preferred URI for automatic 6468 redirection to the resource. The field value consists of a single 6469 absolute URI. 6471 Note: The Content-Location header field (Section 18.17) differs from 6472 Location in that the Content-Location identifies the original 6473 location of the message body enclosed in the request. It is 6474 therefore possible for a response to contain header fields for both 6475 Location and Content-Location. Also, see Section 16.2 for cache 6476 requirements of some methods. 6478 18.28. Media-Properties 6480 This general header is used in SETUP response or PLAY_NOTIFY requests 6481 to indicate the media's properties that currently are applicable to 6482 the RTSP session. PLAY_NOTIFY MAY be used to modify these properties 6483 at any point. However, the client SHOULD have received the update 6484 prior to any action related to the new media properties take effect. 6485 For aggregated sessions, the Media-Properties header will be returned 6486 in each SETUP response. The header received in the latest response 6487 is the one that applies on the whole session from this point until 6488 any future update. The header MAY be included without value in 6489 GET_PARAMETER requests to the server with a Session header included 6490 to query the current Media-Properties for the session. The responder 6491 MUST include the current session's media properties. 6493 The media properties expressed by this header is the one applicable 6494 to all media in the RTSP session. For aggregated sessions, the 6495 header expressed the combined media-properties. As a result, 6496 aggregation of media MAY result in a change of the media properties, 6497 and thus the content of the Media-Properties header contained in 6498 subsequent SETUP responses. 6500 The header contains a list of property values that are applicable to 6501 the currently setup media or aggregate of media as indicated by the 6502 RTSP URI in the request. No ordering is enforced within the header. 6503 Property values should be grouped into a single group that handles a 6504 particular orthogonal property. Values or groups that express 6505 multiple properties SHOULD NOT be used. The list of properties that 6506 can be expressed MAY be extended at any time. Unknown property 6507 values MUST be ignored. 6509 This specification defines the following 4 groups and their property 6510 values: 6512 Random Access: 6514 Random-Access: Indicates that random access is possible. May 6515 optionally include a floating point value in seconds indicating 6516 the longest duration between any two random access points in 6517 the media. 6519 Begining-Only: Seeking is limited to the beginning only. 6521 No-Seeking: No seeking is possible. 6523 Content Modifications: 6525 Immutable: The content will not be changed during the life-time 6526 of the RTSP session. 6528 Dynamic: The content may be changed based on external methods or 6529 triggers 6531 Time-Progressing The media accessible progresses as wallclock 6532 time progresses. 6534 Retention: 6536 Unlimited: Content will be retained for the duration of the life- 6537 time of the RTSP session. 6539 Time-Limited: Content will be retained at least until the 6540 specified wallclock time. The time must be provided in the 6541 absolute time format specified in Section 4.6. 6543 Time-Duration Each individual media unit is retained for at least 6544 the specified time duration. This definition allows for 6545 retaining data with a time based sliding window. The time 6546 duration is expressed as floating point number in seconds. 0.0 6547 is a valid value as this indicates that no data is retained in 6548 a time-progressing session. 6550 Supported Scale: 6552 Scales: A quoted comma separated list of one or more decimal 6553 values or ranges of scale values supported by the content in 6554 arbitrary order. A range has a start and stop value separated 6555 by a colon. A range indicates that the content supports fine 6556 grained selection of scale values. Fine grained allows for 6557 steps at least as small as one tenth of a scale value. A 6558 content is considered to support fine grained selection when 6559 the server in response to a given scale value can produce 6560 content with an actual scale that is less than 1 tenth of scale 6561 unit, i.e., 0.1, from the requested value. Negative values are 6562 supported. The value 0 has no meaning and MUST NOT be used. 6564 Examples of this header for on-demand content and a live stream 6565 without recording are: 6567 On-demand: 6568 Media-Properties: Random-Access=2.5s, Unlimited, Immutable, 6569 Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" 6571 Live stream without recording/timeshifting: 6572 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 6574 18.29. Media-Range 6576 The Media-Range general header is used to give the range of the media 6577 at the time of sending the RTSP message. This header MUST be 6578 included in SETUP response, and PLAY and PAUSE response for media 6579 that are Time-Progressing, and PLAY and PAUSE response after any 6580 change for media that are Dynamic, and in PLAY_NOTIFY request that 6581 are sent due to Media-Property-Update. Media-Range header without 6582 any range specifications MAY be included in GET_PARAMETER requests to 6583 the server to request the current range. The server MUST in this 6584 case include the current range at the time of sending the response. 6586 The header MUST include range specifications for all time formats 6587 supported for the media, as indicated in Accept-Ranges header 6588 (Section 18.5) when setting up the media. The server MAY include 6589 more than one range specification of any given time format to 6590 indicate media that has non-continuous range. 6592 For media that has the Time-Progressing property, the Media-Range 6593 values will only be valid for the particular point in time when it 6594 was issued. As wallclock progresses so will also the media range. 6595 However, it shall be assumed that media time progresses in direct 6596 relationship to wallclock time (with the exception of clock skew) so 6597 that a reasonably accurate estimation of the media range can be 6598 calculated. 6600 18.30. MTag 6602 The MTag response header MAY be included in DESCRIBE, GET_PARAMETER 6603 or SETUP responses. The message body tags (Section 4.8) returned in 6604 a DESCRIBE response, and the one in SETUP refers to the presentation, 6605 i.e. both the returned session description and the media stream. 6606 This allows for verification that one has the right session 6607 description to a media resource at the time of the SETUP request. 6608 However, it has the disadvantage that a change in any of the parts 6609 results in invalidation of all the parts. 6611 If the MTag is provided both inside the message body, e.g. within the 6612 "a=mtag" attribute in SDP, and in the response message, then both 6613 tags MUST be identical. It is RECOMMENDED that the MTag is primarily 6614 given in the RTSP response message, to ensure that caches can use the 6615 MTag without requiring content inspection. However, for session 6616 descriptions that are distributed outside of RTSP, for example using 6617 HTTP, etc. it will be necessary to include the message body tag in 6618 the session description as specified in Appendix D.1.9. 6620 SETUP and DESCRIBE requests can be made conditional upon the MTag 6621 using the headers If-Match (Section 18.23) and If-None-Match ( 6622 Section 18.25). 6624 18.31. Notify-Reason 6626 The Notify Reason header is solely used in the PLAY_NOTIFY method. 6627 It indicates the reason why the server has sent the asynchronous 6628 PLAY_NOTIFY request (see Section 13.5). 6630 18.32. Pipelined-Requests 6632 The Pipelined-Requests general header is used to indicate that a 6633 request is to be executed in the context created by a previous 6634 request(s). The primary usage of this header is to allow pipelining 6635 of SETUP requests so that any additional SETUP request after the 6636 first one does not need to wait for the session ID to be sent back to 6637 the requesting agent. The header contains a unique identifier that 6638 is scoped by the persistent connection used to send the requests. 6640 Upon receiving a request with the Pipelined-Requests the responding 6641 agent MUST look up if there exists a binding between this Pipelined- 6642 Requests identifier for the current persistent connection and an RTSP 6643 session ID. If that exists then the received request is processed 6644 the same way as if it contained the Session header with the found 6645 session ID. If there does not exist a mapping and no Session header 6646 is included in the request, the responding agent MUST create a 6647 binding upon the successful completion of a session creating request, 6648 i.e. SETUP. A binding MUST NOT be created, if the request failed to 6649 create an RTSP session. In case the request contains both a Session 6650 header and the Pipelined-Requests header the Pipelined-Requests MUST 6651 be ignored. 6653 Note: Based on the above definition at least the first request 6654 containing a new unique Pipelined-Requests will be required to be a 6655 SETUP request (unless the protocol is extended with new methods of 6656 creating a session). After that first one, additional SETUP requests 6657 or request of any type using the RTSP session context may include the 6658 Pipelined-Requests header. 6660 When responding to any request that contained the Pipelined-Requests 6661 header the server MUST also include the Session header when a binding 6662 to a session context exist. An RTSP agent that knows the session ID 6663 SHOULD NOT use the Pipelined-Requests header in any request and only 6664 use the Session header. This as the Session identifier is persistent 6665 across transport contexts, like TCP connections, which the Pipelined- 6666 Requests identifier is not. 6668 The RTSP agent sending the request with a Pipelined-Requests header 6669 has the responsibility for using a unique and previously unused 6670 identifier within the transport context. Currently only a TCP 6671 connection is defined as such transport context. A server MUST 6672 delete the Pipelined-Requests identifier and its binding to a session 6673 upon the termination of that session. Despite the previous mandate, 6674 RTSP agents are RECOMMENDED to not reuse identifiers to allow for 6675 better error handling and logging. 6677 RTSP Proxies may need to translate Pipelined-Requests identifier 6678 values from incoming request to outgoing to allow for aggregation of 6679 requests onto a persistent connection. 6681 18.33. Proxy-Authenticate 6683 The Proxy-Authenticate response-header field MUST be included as part 6684 of a 407 (Proxy Authentication Required) response. The field value 6685 consists of a challenge that indicates the authentication scheme and 6686 parameters applicable to the proxy for this Request-URI. 6688 The HTTP access authentication process is described in [RFC2617]. 6689 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 6690 only to the current connection and SHOULD NOT be passed on to 6691 downstream agents. However, an intermediate proxy might need to 6692 obtain its own credentials by requesting them from the downstream 6693 agent, which in some circumstances will appear as if the proxy is 6694 forwarding the Proxy-Authenticate header field. 6696 18.34. Proxy-Authorization 6698 The Proxy-Authorization request-header field allows the client to 6699 identify itself (or its user) to a proxy which requires 6700 authentication. The Proxy-Authorization field value consists of 6701 credentials containing the authentication information of the user 6702 agent for the proxy and/or realm of the resource being requested. 6704 The HTTP access authentication process is described in [RFC2617]. 6705 Unlike Authorization, the Proxy-Authorization header field applies 6706 only to the next outbound proxy that demanded authentication using 6707 the Proxy-Authenticate field. When multiple proxies are used in a 6708 chain, the Proxy-Authorization header field is consumed by the first 6709 outbound proxy that was expecting to receive credentials. A proxy 6710 MAY relay the credentials from the client request to the next proxy 6711 if that is the mechanism by which the proxies cooperatively 6712 authenticate a given request. 6714 18.35. Proxy-Require 6716 The Proxy-Require request-header field is used to indicate proxy- 6717 sensitive features that MUST be supported by the proxy. Any Proxy- 6718 Require header features that are not supported by the proxy MUST be 6719 negatively acknowledged by the proxy to the client using the 6720 Unsupported header. The proxy MUST use the 551 (Option Not 6721 Supported) status code in the response. Any feature-tag included in 6722 the Proxy-Require does not apply to the end-point (server or client). 6723 To ensure that a feature is supported by both proxies and servers the 6724 tag needs to be included in also a Require header. 6726 See Section 18.41 for more details on the mechanics of this message 6727 and a usage example. See discussion in the proxies section 6728 (Section 15.1) about when to consider that a feature requires proxy 6729 support. 6731 Example of use: 6732 Proxy-Require: play.basic 6734 18.36. Proxy-Supported 6736 The Proxy-Supported header field enumerates all the extensions 6737 supported by the proxy using feature-tags. The header carries the 6738 intersection of extensions supported by the forwarding proxies. The 6739 Proxy-Supported header MAY be included in any request by a proxy. It 6740 MUST be added by any proxy if the Supported header is present in a 6741 request. When present in a request, the receiver MUST in the 6742 response copy the received Proxy-Supported header. 6744 The Proxy-Supported header field contains a list of feature-tags 6745 applicable to proxies, as described in Section 4.7. The list is the 6746 intersection of all feature-tags understood by the proxies. To 6747 achieve an intersection, the proxy adding the Proxy-Supported header 6748 includes all proxy feature-tags it understands. Any proxy receiving 6749 a request with the header, MUST check the list and removes any 6750 feature-tag(s) it does not support. A Proxy-Supported header present 6751 in the response MUST NOT be touched by the proxies. 6753 Example: 6755 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 6756 Supported: foo, bar, blech 6757 User-Agent: PhonyClient/1.2 6759 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 6760 Supported: foo, bar, blech 6761 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 6762 Via: 2.0 pro.example.com 6764 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 6765 Supported: foo, bar, blech 6766 Proxy-Supported: proxy-foo, proxy-blech 6767 Via: 2.0 pro.example.com, 2.0 prox2.example.com 6769 S->C: RTSP/2.0 200 OK 6770 Supported: foo, bar, baz 6771 Proxy-Supported: proxy-foo, proxy-blech 6772 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 6773 Via: 2.0 pro.example.com, 2.0 prox2.example.com 6775 18.37. Public 6777 The Public response header field lists the set of methods supported 6778 by the response sender. This header applies to the general 6779 capabilities of the sender and its only purpose is to indicate the 6780 sender's capabilities to the recipient. The methods listed may or 6781 may not be applicable to the Request-URI; the Allow header field 6782 (Section 18.6) MAY be used to indicate methods allowed for a 6783 particular URI. 6785 Example of use: 6786 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 6788 In the event that there are proxies between the sender and the 6789 recipient of a response, each intervening proxy MUST modify the 6790 Public header field to remove any methods that are not supported via 6791 that proxy. The resulting Public header field will contain an 6792 intersection of the sender's methods and the methods allowed through 6793 by the intervening proxies. 6795 In general, proxies should allow all methods to transparently pass 6796 through from the sending RTSP agent to the receiving RTSP agent, 6797 but there may be cases where this is not desirable for a given 6798 proxy. Modification of the Public response header field by the 6799 intervening proxies ensures that the request sender gets an 6800 accurate response indicating the methods that can be used on the 6801 target agent via the proxy chain. 6803 18.38. Range 6805 The Range header specifies a time range in PLAY (Section 13.4), PAUSE 6806 (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and 6807 PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be 6808 included in GET_PARAMETER requests from the client to the server with 6809 only a Range format and no value to request the current media 6810 position, whether the session is in Play or Ready state in the 6811 included format. The server SHALL, if supporting the range format, 6812 respond with the current playing point or pause point as the start of 6813 the range. If an explicit stop point was used in the previous PLAY 6814 request, then that value shall be included as stop point. Note that 6815 if the server is currently under any type of media playback 6816 manipulation affecting the interpretation of Range, like Scale, that 6817 is also required to be included in any GET_PARAMETER response to 6818 provide complete information. 6820 The range can be specified in a number of units. This specification 6821 defines smpte (Section 4.4), npt (Section 4.5), and clock 6822 (Section 4.6) range units. While byte ranges [H14.35.1] and other 6823 extended units MAY be used, their behavior is unspecified since they 6824 are not normally meaningful in RTSP. Servers supporting the Range 6825 header MUST understand the NPT range format and SHOULD understand the 6826 SMPTE range format. If the Range header is sent in a time format 6827 that is not understood, the recipient SHOULD return 456 (Header Field 6828 Not Valid for Resource) and include an Accept-Ranges header 6829 indicating the supported time formats for the given resource. 6831 Example: 6832 Range: clock=19960213T143205Z- 6834 The Range header contains a range of one single range format. A 6835 range is a half-open interval with a start and an end point, 6836 including the start point, but excluding the end point. A range may 6837 either be fully specified with explicit values for start point and 6838 end point, or have either start or end point be implicit. An 6839 implicit start point indicates the session's pause point, and if no 6840 pause point is set the start of the content. An implicit end point 6841 indicates the end of the content. The usage of both implicit start 6842 and end point is not allowed in the same range header, however, the 6843 exclusion of the range header has that meaning, i.e. from pause point 6844 (or start) until end of content. 6846 Regarding the half-open intervals; a range of A-B starts exactly 6847 at time A, but ends just before B. Only the start time of a media 6848 unit such as a video or audio frame is relevant. For example, 6849 assume that video frames are generated every 40 ms. A range of 6850 10.0-10.1 would include a video frame starting at 10.0 or later 6851 time and would include a video frame starting at 10.08, even 6852 though it lasted beyond the interval. A range of 10.0-10.08, on 6853 the other hand, would exclude the frame at 10.08. 6855 Please note the difference between NPT time scales' "now" and an 6856 implicit start value. Implicit value reference the current pause- 6857 point. While "now" is the currently ongoing time. In a time- 6858 progressing session with recording (retention for some or full 6859 time) the pause point may be 2 min into the session while now 6860 could be 1 hour into the session. 6862 By default, range intervals increase, where the second point is 6863 larger than the first point. 6865 Example: 6866 Range: npt=10-15 6868 However, range intervals can also decrease if the Scale header (see 6869 Section 18.44) indicates a negative scale value. For example, this 6870 would be the case when a playback in reverse is desired. 6872 Example: 6873 Scale: -1 6874 Range: npt=15-10 6876 Decreasing ranges are still half open intervals as described above. 6877 Thus, for range A-B, A is closed and B is open. In the above 6878 example, 15 is closed and 10 is open. An exception to this rule is 6879 the case when B=0 in a decreasing range. In this case, the range is 6880 closed on both ends, as otherwise there would be no way to reach 0 on 6881 a reverse playback for formats that have such a notion, like NPT and 6882 SMPTE. 6884 Example: 6885 Scale: -1 6886 Range: npt=15-0 6888 In this range both 15 and 0 are closed. 6890 A decreasing range interval without a corresponding negative Scale 6891 header is not valid. 6893 18.39. Referrer 6895 The Referrer request-header field allows the client to specify, for 6896 the server's benefit, the address (URI) of the resource from which 6897 the Request-URI was obtained. The URI refers to that of the 6898 presentation description, typically retrieved via HTTP. The Referrer 6899 request-header allows a server to generate lists of back-links to 6900 resources for interest, logging, optimized caching, etc. It also 6901 allows obsolete or mistyped links to be traced for maintenance. The 6902 Referrer field MUST NOT be sent if the Request-URI was obtained from 6903 a source that does not have its own URI, such as input from the user 6904 keyboard. 6906 If the field value is a relative URI, it SHOULD be interpreted 6907 relative to the Request-URI. The URI MUST NOT include a fragment. 6909 Because the source of a link might be private information or might 6910 reveal an otherwise private information source, it is strongly 6911 recommended that the user be able to select whether or not the 6912 Referrer field is sent. For example, a streaming client could have a 6913 toggle switch for openly/anonymously, which would respectively 6914 enable/disable the sending of Referrer and From information. 6916 Clients SHOULD NOT include a Referrer header field in a (non-secure) 6917 RTSP request if the referring page was transferred with a secure 6918 protocol. 6920 18.40. Request-Status 6922 This request header is used to indicate the end result for requests 6923 that takes time to complete, such a PLAY (Section 13.4). It is sent 6924 in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report 6925 how the PLAY request concluded, either in success or in failure. The 6926 header carries a reference to the request it reports on using the 6927 CSeq number for the session indicated by the Session header in the 6928 request. It provides both a numerical status code (according to 6929 Section 8.1.1) and a human readable reason phrase. 6931 Example: 6932 Request-Status: cseq=63 status=500 reason="Media data unavailable" 6934 18.41. Require 6936 The Require request-header field is used by clients or servers to 6937 ensure that the other end-point supports features that are required 6938 in respect to this request. It can also be used to query if the 6939 other end-point supports certain features, however, the use of the 6940 Supported (Section 18.49) is much more effective in this purpose. 6941 The server MUST respond to this header by using the Unsupported 6942 header to negatively acknowledge those feature-tags which are NOT 6943 supported. The response MUST use the error code 551 (Option Not 6944 Supported). This header does not apply to proxies, for the same 6945 functionality in respect to proxies see Proxy-Require header 6946 (Section 18.35) with the exception of media modifying proxies. Media 6947 modifying proxies, due to their nature of handling media in a way 6948 that is very similar to a server, do need to understand also the 6949 server features to correctly serve the client. 6951 This is to make sure that the client-server interaction will 6952 proceed without delay when all features are understood by both 6953 sides, and only slow down if features are not understood (as in 6954 the example below). For a well-matched client-server pair, the 6955 interaction proceeds quickly, saving a round-trip often required 6956 by negotiation mechanisms. In addition, it also removes state 6957 ambiguity when the client requires features that the server does 6958 not understand. 6960 Example (Not complete): 6961 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 6962 CSeq: 302 6963 Require: funky-feature 6964 Funky-Parameter: funkystuff 6966 S->C: RTSP/2.0 551 Option not supported 6967 CSeq: 302 6968 Unsupported: funky-feature 6970 In this example, "funky-feature" is the feature-tag which indicates 6971 to the client that the fictional Funky-Parameter field is required. 6972 The relationship between "funky-feature" and Funky-Parameter is not 6973 communicated via the RTSP exchange, since that relationship is an 6974 immutable property of "funky-feature" and thus should not be 6975 transmitted with every exchange. 6977 Proxies and other intermediary devices MUST ignore this header. If a 6978 particular extension requires that intermediate devices support it, 6979 the extension should be tagged in the Proxy-Require field instead 6980 (see Section 18.35). See discussion in the proxies section 6981 (Section 15.1) about when to consider that a feature requires proxy 6982 support. 6984 18.42. Retry-After 6986 The Retry-After response-header field can be used with a 503 (Service 6987 Unavailable) response to indicate how long the service is expected to 6988 be unavailable to the requesting client. This field MAY also be used 6989 with any 3xx (Redirection) response to indicate the minimum time the 6990 user-agent is asked to wait before issuing the redirected request. 6991 The value of this field can be either an RTSP-date or an integer 6992 number of seconds (in decimal) after the time of the response. 6994 Example: 6996 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 6997 Retry-After: 120 6999 In the latter example, the delay is 2 minutes. 7001 18.43. RTP-Info 7003 The RTP-Info general header field is used to set RTP-specific 7004 parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY 7005 and GET_PARAMETER requests. For streams using RTP as transport 7006 protocol the RTP-Info header SHOULD be part of a 200 response to 7007 PLAY. 7009 The exclusion of the RTP-Info in a PLAY response for RTP 7010 transported media will result in that a client needs to 7011 synchronize the media streams using RTCP. This may have negative 7012 impact as the RTCP can be lost, and does not need to be 7013 particularly timely in its arrival. Also functionality as 7014 informing the client from which packet a seek has occurred is 7015 affected. 7017 The RTP-Info MAY be included in SETUP responses to provide 7018 synchronization information when changing transport parameters, see 7019 Section 13.3. The RTP-Info header and the Range header MAY be 7020 included in a GET_PARAMETER request from client to server without any 7021 values to request the current playback point and corresponding RTP 7022 synchronization information. When the RTP-Info header is included in 7023 a Request also the Range header MUST be included (Note, Range header 7024 only MAY be used). The server response SHALL include both the Range 7025 header and the RTP-Info header. If the session is in Play state, 7026 then the value of the Range header SHALL be filled in with the 7027 current playback point and with the corresponding RTP-Info values. 7028 If the server is another state, no values are included in the RTP- 7029 Info header. The header is included in PLAY_NOTIFY requests with the 7030 Notify-Reason of end-of-stream to provide RTP information about the 7031 end of the stream. 7033 The header can carry the following parameters: 7035 url: Indicates the stream URI for which the following RTP parameters 7036 correspond, this URI MUST be the same as used in the SETUP 7037 request for this media stream. Any relative URI MUST use the 7038 Request-URI as base URI. This parameter MUST be present. 7040 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 7041 sequence number provided applies to. This parameter MUST be 7042 present. 7044 seq: Indicates the sequence number of the first packet of the stream 7045 that is direct result of the request. This allows clients to 7046 gracefully deal with packets when seeking. The client uses 7047 this value to differentiate packets that originated before the 7048 seek from packets that originated after the seek. Note that a 7049 client may not receive the packet with the expressed sequence 7050 number, and instead packets with a higher sequence number, due 7051 to packet loss or reordering. This parameter is RECOMMENDED to 7052 be present. 7054 rtptime: MUST indicate the RTP timestamp value corresponding to the 7055 start time value in the Range response header, or if not 7056 explicitly given the implied start point. The client uses this 7057 value to calculate the mapping of RTP time to NPT or other 7058 media timescale. This parameter SHOULD be present to ensure 7059 inter-media synchronization is achieved. There exists no 7060 requirement that any received RTP packet will have the same RTP 7061 timestamp value as the one in the parameter used to establish 7062 synchronization. 7064 A mapping from RTP timestamps to NTP timestamps (wallclock) is 7065 available via RTCP. However, this information is not sufficient 7066 to generate a mapping from RTP timestamps to media clock time 7067 (NPT, etc.). Furthermore, in order to ensure that this 7068 information is available at the necessary time (immediately at 7069 startup or after a seek), and that it is delivered reliably, this 7070 mapping is placed in the RTSP control channel. 7072 In order to compensate for drift for long, uninterrupted 7073 presentations, RTSP clients should additionally map NPT to NTP, 7074 using initial RTCP sender reports to do the mapping, and later 7075 reports to check drift against the mapping. 7077 Example: 7079 Range:npt=3.25-15 7080 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 7081 rtptime=12345678,url="rtsp://example.com/foo/video" 7082 ssrc=9A9DE123:seq=30211;rtptime=29567112 7084 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video 7085 a 90kHz RTP timestamp clock. Then the media synchronization is 7086 depicted in the following way. 7088 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 7089 Audio PA A 7090 Video V PV 7092 X: NPT time value = 3.25, from Range header. 7093 A: RTP timestamp value for Audio from RTP-Info header (12345678). 7094 V: RTP timestamp value for Video from RTP-Info header (29567112). 7095 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 7096 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 7097 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 7098 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 7100 18.44. Scale 7102 A scale value of 1 indicates normal play at the normal forward 7103 viewing rate. If not 1, the value corresponds to the rate with 7104 respect to normal viewing rate. For example, a ratio of 2 indicates 7105 twice the normal viewing rate ("fast forward") and a ratio of 0.5 7106 indicates half the normal viewing rate. In other words, a ratio of 2 7107 has content time increase at twice the playback time. For every 7108 second of elapsed (wallclock) time, 2 seconds of content time will be 7109 delivered. A negative value indicates reverse direction. For 7110 certain media transports this may require certain considerations to 7111 work consistent, see Appendix C.1 for description on how RTP handles 7112 this. 7114 The transmitted data rate SHOULD NOT be changed by selection of a 7115 different scale value. The resulting bit-rate should be reasonably 7116 close to the nominal bit-rate of the content for Scale = 1. The 7117 server has to actively manipulate the data when needed to meet the 7118 bitrate constraints. Implementation of scale changes depends on the 7119 server and media type. For video, a server may, for example, deliver 7120 only key frames or selected frames. For audio, it may time-scale the 7121 audio while preserving pitch or, less desirably, deliver fragments of 7122 audio, or completely mute the audio. 7124 The server and content may restrict the range of scale values that it 7125 supports. The supported values are indicated by the Media-Properties 7126 header (Section 18.28). The client SHOULD only indicate values 7127 indicated to be supported. However, as the values may change as the 7128 content progresses a requested value may no longer be valid when the 7129 request arrives. Thus, a non-supported value in a request does not 7130 generate an error, only forces the server to choose the closest 7131 value. The response MUST always contain the actual scale value 7132 chosen by the server. 7134 If the server does not implement the possibility to scale, it will 7135 not return a Scale header. A server supporting Scale operations for 7136 PLAY MUST indicate this with the use of the "play.scale" feature-tag. 7138 When indicating a negative scale for a reverse playback, the Range 7139 header MUST indicate a decreasing range as described in 7140 Section 18.38. 7142 Example of playing in reverse at 3.5 times normal rate: 7143 Scale: -3.5 7144 Range: npt=15-10 7146 18.45. Seek-Style 7148 When a client sends a PLAY request with a Range header to perform a 7149 random access to the media, the client does not know if the server 7150 will pick the first media samples or the first random access point 7151 prior to the request range. Depending on use case, the client may 7152 have a strong preference. To express this preference and provide the 7153 client with information on how the server actually acted on that 7154 preference the Seek-Style header is defined. 7156 Seek-Style is a general header that MAY be included in any PLAY 7157 request to indicate the client's preference for any media stream that 7158 has random access properties. The server MUST always include the 7159 header in any PLAY response for media with random access properties 7160 to indicate what policy was applied. A server that receives an 7161 unknown Seek-Style policy MUST ignore it and select the server 7162 default policy. A client receiving an unknown policy MUST ignore it 7163 and use the Range header and any media synchronization information as 7164 basis to determine what the server did. 7166 This specification defines the following seek policies that may be 7167 requested (see also Section 4.9.1): 7169 RAP: Random Access Point (RAP) is the behavior of requesting the 7170 server to locate the closest previous random access point that 7171 exists in the media aggregate and deliver from that. By 7172 requesting a RAP, media quality will be the best possible as all 7173 media will be delivered from a point where full media state can be 7174 established in the media decoder. 7176 CoRAP: Conditional Random Access Point (CoRAP) is a variant of the 7177 above RAP behavior. This policy is primarily intended for cases 7178 where there is larger distance between the random access points in 7179 the media. CoRAP is conditioned on that there is a Random Access 7180 Point closer to the requested start point than to the current 7181 pause point. This policy assumes that the media state existing 7182 prior to the pause is usable if delivery is continued. If the 7183 client or server knows that this is not the fact the RAP policy 7184 should be used. In other words: in most cases when the client 7185 requests a start point prior to the current pause point, a valid 7186 decoding dependency chain from the media delivered prior to the 7187 pause and to the requested media unit will not exist. If the 7188 server searched to a random access point the server MUST return 7189 the CoRAP policy in the Seek-Style header and adjust the Range 7190 header to reflect the position of the picked RAP. In case the 7191 random access point is further away and the server selects to 7192 continue from the current pause point it MUST include the "Next" 7193 policy in the Seek-Style header and adjust the Range header start 7194 point to the current pause point. 7196 First-Prior: The first-prior policy will start delivery with the 7197 media unit that has a playout time first prior to the requested 7198 time. For discrete media that would only include media units that 7199 would still be rendered at the request time. For continuous media 7200 that is media that will be rendered during the requested start 7201 time of the range. 7203 Next: The next media units after the provided start time of the 7204 range. For continuous framed media that would mean the first next 7205 frame after the provided time. For discrete media the first unit 7206 that is to be rendered after the provided time. The main usage 7207 for this case is when the client knows it has all media up to a 7208 certain point and would like to continue delivery so that a 7209 complete non-interrupted media playback can be achieved. Example 7210 of such scenarios include switching from a broadcast/multicast 7211 delivery to a unicast based delivery. This policy MUST only be 7212 used on the client's explicit request. 7214 Please note that these expressed preferences exist for optimizing the 7215 startup time or the media quality. The "Next" policy breaks the 7216 normal definition of the Range header to enable a client to request 7217 media with minimal overlap, although some may still occur for 7218 aggregated sessions. RAP and First-Prior both fulfill the 7219 requirement of providing media from the requested range and forward. 7220 However, unless RAP is used, the media quality for many media codecs 7221 using predictive methods can be severely degraded unless additional 7222 data is available as, for example, already buffered, or through other 7223 side channels. 7225 18.46. Server 7227 The Server response-header field contains information about the 7228 software used by the origin server to handle the request. The field 7229 can contain multiple product tokens and comments identifying the 7230 server and any significant subproducts. The product tokens are 7231 listed in order of their significance for identifying the 7232 application. 7234 Example: 7235 Server: PhonyServer/1.0 7237 If the response is being forwarded through a proxy, the proxy 7238 application MUST NOT modify the Server response-header. Instead, it 7239 SHOULD include a Via field (Section 18.55). If the response is 7240 generated by the proxy, the proxy application MUST return the Server 7241 response-header as previously returned by the server. 7243 18.47. Session 7245 The Session request-header and response-header field identifies an 7246 RTSP session. An RTSP session is created by the server as a result 7247 of a successful SETUP request and in the response the session 7248 identifier is given to the client. The RTSP session exists until 7249 destroyed by a TEARDOWN, REDIRECT or timed out by the server. 7251 The session identifier is chosen by the server (see Section 4.3) and 7252 MUST be returned in the SETUP response. Once a client receives a 7253 session identifier, it MUST be included in any request related to 7254 that session. This means that the Session header MUST be included in 7255 a request, using the following methods: PLAY, PAUSE, and TEARDOWN, 7256 and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, 7257 and REDIRECT, and MUST NOT be included in DESCRIBE. The Session 7258 header MUST NOT be included in the following methods, if these 7259 requests are pipelined and if the session identifier is not yet 7260 known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and 7261 GET_PARAMETER. 7263 In an RTSP response the session header MUST be included in methods, 7264 SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and 7265 REDIRECT, and if included in the request of the following methods it 7266 MUST also be included in the response, OPTIONS, GET_PARAMETER, and 7267 SET_PARAMETER, and MUST NOT be included in DESCRIBE responses. 7269 Note that a session identifier identifies an RTSP session across 7270 transport sessions or connections. RTSP requests for a given session 7271 can use different URIs (Presentation and media URIs). Note, that 7272 there are restrictions depending on the session which URIs that are 7273 acceptable for a given method. However, multiple "user" sessions for 7274 the same URI from the same client will require use of different 7275 session identifiers. 7277 The session identifier is needed to distinguish several delivery 7278 requests for the same URI coming from the same client. 7280 The response 454 (Session Not Found) MUST be returned if the session 7281 identifier is invalid. 7283 The header MAY include the session timeout period. If not explicitly 7284 provided this value is set to 60 seconds. As this affects how often 7285 session keep-alives are needed values smaller than 30 seconds are not 7286 recommended. However, larger than default values can be useful in 7287 applications of RTSP that have inactive but established sessions for 7288 longer time periods. 7290 60 seconds was chosen as session timeout value due to: Resulting 7291 in not too frequent keep-alive messages and having low sensitivity 7292 to variations in request response timing. If one reduces the 7293 timeout value to below 30 seconds the corresponding request 7294 response timeout becomes a significant part of the session 7295 timeout. 60 seconds also allows for reasonably rapid recovery of 7296 committed server resources in case of client failure. 7298 18.48. Speed 7300 The Speed request-header field requests the server to deliver 7301 specific amounts of nominal media time per unit of delivery time, 7302 contingent on the server's ability and desire to serve the media 7303 stream at the given speed. The client requests the delivery speed to 7304 be within a given range with a lower and upper bound. The server 7305 SHALL deliver at the highest possible speed within the range, but not 7306 faster than the upper-bound, for which the underlying network path 7307 can support the resulting transport data rates. As long as any speed 7308 value within the given range can be provided the server SHALL NOT 7309 modify the media quality. Only if the server is unable to deliver 7310 media at the speed value provided by the lower bound shall it reduce 7311 the media quality. 7313 Implementation of the Speed functionality by the server is OPTIONAL. 7314 The server can indicate its support through a feature-tag, 7315 play.speed. The lack of a Speed header in the response is an 7316 indication of lack of support of this functionality. 7318 The speed parameter values are expressed as a positive decimal value, 7319 e.g., a value of 2.0 indicates that data is to be delivered twice as 7320 fast as normal. A speed value of zero is invalid. The range is 7321 specified in the form "lower bound - upper bound". The lower bound 7322 value may be smaller or equal to the upper bound. All speeds may not 7323 be possible to support. Therefore the server MAY modify the 7324 requested values to the closest supported. The actual supported 7325 speed MUST be included in the response. Note, however, that the use 7326 cases may vary and that Speed value ranges such as 0.7 - 0.8, 7327 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 7329 Example: 7331 Speed: 1.0-2.5 7333 Use of this header changes the bandwidth used for data delivery. It 7334 is meant for use in specific circumstances where delivery of the 7335 presentation at a higher or lower rate is desired. The main use 7336 cases are buffer operations or local scale operations. Implementors 7337 should keep in mind that bandwidth for the session may be negotiated 7338 beforehand (by means other than RTSP), and therefore re-negotiation 7339 may be necessary. To perform Speed operations the server needs to 7340 ensure that the network path can support the resulting bit-rate. 7341 Thus the media transport needs to support feedback so that the server 7342 can react and adapt to the available bitrate. 7344 18.49. Supported 7346 The Supported header enumerates all the extensions supported by the 7347 client or server using feature tags. The header carries the 7348 extensions supported by the message sending client or server. The 7349 Supported header MAY be included in any request. When present in a 7350 request, the receiver MUST respond with its corresponding Supported 7351 header. Note that the Supported header is also included in 4xx and 7352 5xx responses. 7354 The Supported header contains a list of feature-tags, described in 7355 Section 4.7, that are understood by the client or server. 7357 Example: 7359 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 7360 Supported: foo, bar, blech 7361 User-Agent: PhonyClient/1.2 7363 S->C: RTSP/2.0 200 OK 7364 Supported: bar, blech, baz 7366 18.50. Terminate-Reason 7368 The Terminate-Reason request header allows the server when sending a 7369 REDIRECT or TEARDOWN request to provide a reason for the session 7370 termination and any additional information. This specification 7371 identifies three reasons for Redirections and may be extended in the 7372 future: 7374 Server-Admin: The server needs to be shutdown for some 7375 administrative reason. 7377 Session-Timeout: A client's session is kept alive for extended 7378 periods of time and the server has determined that it needs to 7379 reclaim the resources associated with this session. 7381 Internal-Error An internal error that is impossible to recover from 7382 has occurred forcing the server to terminate the session. 7384 The Server may provide additional parameters containing information 7385 around the redirect. This specification defines the following ones. 7387 time: Provides a wallclock time when the server will stop provide 7388 any service. 7390 user-msg: An UTF-8 text string with a message from the server to the 7391 user. This message SHOULD be displayed to the user. 7393 18.51. Timestamp 7395 The Timestamp general-header describes when the agent sent the 7396 request. The value of the timestamp is of significance only to the 7397 agent and may use any timescale. The responding agent MUST echo the 7398 exact same value and MAY, if it has accurate information about this, 7399 add a floating point number indicating the number of seconds that has 7400 elapsed since it has received the request. The timestamp can be used 7401 by the agent to compute the round-trip time to the responding agent 7402 so that it can adjust the timeout value for retransmissions when 7403 running over an unreliable protocol. It also resolves retransmission 7404 ambiguities for unreliable transport of RTSP. 7406 Note that the present specification provides only for reliable 7407 transport of RTSP messages. The Timestamp general-header is 7408 specified in case the protocol is extended in the future to use 7409 unreliable transport. 7411 18.52. Transport 7413 The Transport request and response header indicates which transport 7414 protocol is to be used and configures its parameters such as 7415 destination address, compression, multicast time-to-live and 7416 destination port for a single stream. It sets those values not 7417 already determined by a presentation description. 7419 A Transport request header MAY contain a list of transport options 7420 acceptable to the client, in the form of multiple transport 7421 specification entries. Transport specifications are comma separated, 7422 listed in decreasing order of preference. Parameters may be added to 7423 each transport specification, separated by a semicolon. The server 7424 MUST return a Transport response-header in the response to indicate 7425 the values actually chosen if any. If the transport specification is 7426 not supported, no transport header is returned and the request MUST 7427 be responded using the status code 461 (Unsupported Transport) 7428 (Section 17.4.26). In case more than one transport specification was 7429 present in the request, the server MUST return the single (transport- 7430 spec) which was actually chosen, if any. The number of transport- 7431 spec entries is expected to be limited as the client will get 7432 guidance on what configurations that are possible from the 7433 presentation description. 7435 The Transport header MAY also be used in subsequent SETUP requests to 7436 change transport parameters. A server MAY refuse to change 7437 parameters of an existing stream. 7439 A transport specification may only contain one of any given parameter 7440 within it. Parameters MAY be given in any order. Additionally, it 7441 may only contain either of the unicast or the multicast transport 7442 type parameter. All parameters need to be understood in a transport 7443 specification, if not, the transport specification MUST be ignored. 7444 RTSP proxies of any type that uses or modifies the transport 7445 specification, e.g. access proxy or security proxy, MUST remove 7446 specifications with unknown parameters before forwarding the RTSP 7447 message. If that result in no remaining transport specification the 7448 proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26) 7449 response without any Transport header. 7451 The Transport header is restricted to describing a single media 7452 stream. (RTSP can also control multiple streams as a single 7453 entity.) Making it part of RTSP rather than relying on a 7454 multitude of session description formats greatly simplifies 7455 designs of firewalls. 7457 The general syntax for the transport specifier is a list of slash 7458 separated tokens: 7460 Value1/Value2/Value3... 7461 Which for RTP transports take the form: 7462 RTP/profile/lower-transport. 7464 The default value for the "lower-transport" parameters is specific to 7465 the profile. For RTP/AVP, the default is UDP. 7467 There are two different methods for how to specify where the media 7468 should be delivered for unicast transport: 7470 dest_addr: The presence of this parameter and its values indicates 7471 the destination address or addresses (host address and port 7472 pairs for IP flows) necessary for the media transport. 7474 No dest_addr: The lack of the dest_addr parameter indicates that the 7475 server MUST send media to same address for which the RTSP 7476 messages originates. 7478 The choice of method for indicating where the media is to be 7479 delivered depends on the use case. In some cases the only allowed 7480 method will be to use no explicit address indication and have the 7481 server deliver media to the source of the RTSP messages. 7483 For Multicast there is several methods for specifying addresses but 7484 they are different in how they work compared with unicast: 7486 dest_addr with client picked address: The address and relevant 7487 parameters like TTL (scope) for the actual multicast group to 7488 deliver the media to. There are security implications 7489 (Section 21) with this method that needs to be addressed if 7490 using this method because a RTSP server can be used as a DoS 7491 attacker on an existing multicast group. 7493 dest_addr using Session Description Information: The information 7494 included in the transport header can all be coming from the 7495 session description, e.g. the SDP c= and m= line. This 7496 mitigates some of the security issues of the previous methods 7497 as it is the session provider that picks the multicast group 7498 and scope. The client MUST include the information if it is 7499 available in the session description. 7501 No dest_addr: The behavior when no explicit multicast group is 7502 present in a request is not defined. 7504 An RTSP proxy will need to take care. If the media is not desired to 7505 be routed through the proxy, the proxy will need to introduce the 7506 destination indication. 7508 Below are the configuration parameters associated with transport: 7510 General parameters: 7512 unicast / multicast: This parameter is a mutually exclusive 7513 indication of whether unicast or multicast delivery will be 7514 attempted. One of the two values MUST be specified. Clients 7515 that are capable of handling both unicast and multicast 7516 transmission needs to indicate such capability by including two 7517 full transport-specs with separate parameters for each. 7519 layers: The number of multicast layers to be used for this media 7520 stream. The layers are sent to consecutive addresses starting 7521 at the dest_addr address. If the parameter is not included, it 7522 defaults to a single layer. 7524 dest_addr: A general destination address parameter that can contain 7525 one or more address specifications. Each combination of 7526 protocol/profile/lower transport needs to have the format and 7527 interpretation of its address specification defined. For RTP/ 7528 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 7529 containing a host address and port. Note, only a single 7530 destination parameter per transport spec is intended. The 7531 usage of multiple destinations to distribute a single media to 7532 multiple entities is unspecified. 7534 The client originating the RTSP request MAY specify the 7535 destination address of the stream recipient with the host 7536 address part of the tuple. When the destination address is 7537 specified, the recipient may be a different party than the 7538 originator of the request. To avoid becoming the unwitting 7539 perpetrator of a remote-controlled denial-of-service attack, a 7540 server MUST perform security checks (see Section 21.2.1) and 7541 SHOULD log such attempts before allowing the client to direct a 7542 media stream to a recipient address not chosen by the server. 7543 Implementations cannot rely on TCP as reliable means of client 7544 identification. If the server does not allow the host address 7545 part of the tuple to be set, it MUST return 463 (Destination 7546 Prohibited). 7548 The host address part of the tuple MAY be empty, for example 7549 ":58044", in cases when only destination port is desired to be 7550 specified. Responses to requests including the Transport 7551 header with a dest_addr parameter SHOULD include the full 7552 destination address that is actually used by the server. The 7553 server MUST NOT remove address information present already in 7554 the request when responding unless the protocol requires it. 7556 src_addr: A general source address parameter that can contain one or 7557 more address specifications. Each combination of protocol/ 7558 profile/lower transport needs to have the format and 7559 interpretation of its address specification defined. For RTP/ 7560 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 7561 containing a host address and port. 7563 This parameter MUST be specified by the server if it transmits 7564 media packets from another address than the one RTSP messages 7565 are sent to. This will allow the client to verify source 7566 address and give it a destination address for its RTCP feedback 7567 packets, if RTP is used. The address or addresses indicated in 7568 the src_addr parameter SHOULD be used both for sending and 7569 receiving of the media streams data packets. The main reasons 7570 are threefold: First, indicating the port and source address(s) 7571 lets the receiver know where from the packets is expected to 7572 originate. Secondly, traversal of NATs is greatly simplified 7573 when traffic is flowing symmetrically over an NAT binding. 7574 Thirdly, certain NAT traversal mechanisms, needs to know to 7575 which address and port to send so called "binding packets" from 7576 the receiver to the sender, thus creating an address binding in 7577 the NAT that the sender to receiver packet flow can use. 7579 This information may also be available through SDP. 7580 However, since this is more a feature of transport than 7581 media initialization, the authoritative source for this 7582 information should be in the SETUP response. 7584 mode: The mode parameter indicates the methods to be supported for 7585 this session. Currently defined valid values are "PLAY". If 7586 not provided, the default is "PLAY". The "RECORD" value was 7587 defined in RFC 2326 and is in this specification unspecified 7588 but reserved. RECORD and other values may be specified in the 7589 future. 7591 interleaved: The interleaved parameter implies mixing the media 7592 stream with the control stream in whatever protocol is being 7593 used by the control stream, using the mechanism defined in 7594 Section 14. The argument provides the channel number to be 7595 used in the $ block Section 14 and MUST be present. This 7596 parameter MAY be specified as a interval, e.g., interleaved=4-5 7597 in cases where the transport choice for the media stream 7598 requires it, e.g., for RTP with RTCP. The channel number given 7599 in the request is only a guidance from the client to the server 7600 on what channel number(s) to use. The server MAY set any valid 7601 channel number in the response. The declared channel(s) are 7602 bi-directional, so both end-parties MAY send data on the given 7603 channel. One example of such usage is the second channel used 7604 for RTCP, where both server and client send RTCP packets on the 7605 same channel. 7607 This allows RTP/RTCP to be handled similarly to the way 7608 that it is done with UDP, i.e., one channel for RTP and 7609 the other for RTCP. 7611 MIKEY: This parameter is used in conjunction with transport 7612 specifications that can utilize MIKEY [RFC3830] for security 7613 context establishment. So far only the SRTP based RTP profiles 7614 SAVP and SAVPF can utilize MIKEY and this is defined in 7615 Appendix C.1.4.1. This parameter can be included both in 7616 request and response messages. The binary MIKEY message SHALL 7617 be BASE64 [RFC4648] encoded before being included in the value 7618 part of the parameter. 7620 Multicast-specific: 7622 ttl: multicast time-to-live for IPv4. When included in requests the 7623 value indicate the TTL value that the client request the server 7624 to use. In a response, the value actually being used by the 7625 server is returned. A server will need to consider what values 7626 that are reasonable and also the authority of the user to set 7627 this value. Corresponding functions are not needed for IPv6 as 7628 the scoping is part of the IPv6 multicast address [RFC4291]. 7630 RTP-specific: 7632 These parameters MAY only be used if the media transport protocol is 7633 RTP. 7635 ssrc: The ssrc parameter, if included in a SETUP response, indicates 7636 the RTP SSRC [RFC3550] value(s) that will be used by the media 7637 server for RTP packets within the stream. It is expressed as 7638 an eight digit hexadecimal value. 7640 The ssrc parameter MUST NOT be specified in requests. The 7641 functionality of specifying the ssrc parameter in a SETUP 7642 request is deprecated as it is incompatible with the 7643 specification of RTP in RFC 3550[RFC3550]. If the parameter is 7644 included in the Transport header of a SETUP request, the server 7645 SHOULD ignore it, and choose appropriate SSRCs for the stream. 7646 The server SHOULD set the ssrc parameter in the Transport 7647 header of the response. 7649 RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing 7650 [RFC5761] on a single underlying transport stream / flow. The 7651 presence of this parameter in a SETUP request indicates the 7652 clients support and requires the server to use RTP and RTCP 7653 multiplexing. The client SHALL only include one transport 7654 stream in the Transport header specification. To provide the 7655 server with a choice between using RTP/RTCP multiplexing or 7656 not, two different transport header specifications must be 7657 included. 7659 The parameters setup and connection defined below MAY only be used if 7660 the media transport protocol of the lower-level transport is 7661 connection-oriented (such as TCP). However, these parameters MUST 7662 NOT be used when interleaving data over the RTSP control connection. 7664 setup: Clients use the setup parameter on the Transport line in a 7665 SETUP request, to indicate the roles it wishes to play in a TCP 7666 connection. This parameter is adapted from [RFC4145]. We 7667 discuss the use of this parameter in RTP/AVP/TCP non- 7668 interleaved transport in Appendix C.2.2; the discussion below 7669 is limited to syntactic issues. Clients may specify the 7670 following values for the setup parameter: ["active":] The 7671 client will initiate an outgoing connection. ["passive":] The 7672 client will accept an incoming connection. ["actpass":] The 7673 client is willing to accept an incoming connection or to 7674 initiate an outgoing connection. 7676 If a client does not specify a setup value, the "active" value 7677 is assumed. 7679 In response to a client SETUP request where the setup parameter 7680 is set to "active", a server's 2xx reply MUST assign the setup 7681 parameter to "passive" on the Transport header line. 7683 In response to a client SETUP request where the setup parameter 7684 is set to "passive", a server's 2xx reply MUST assign the setup 7685 parameter to "active" on the Transport header line. 7687 In response to a client SETUP request where the setup parameter 7688 is set to "actpass", a server's 2xx reply MUST assign the setup 7689 parameter to "active" or "passive" on the Transport header 7690 line. 7692 Note that the "holdconn" value for setup is not defined for 7693 RTSP use, and MUST NOT appear on a Transport line. 7695 connection: Clients use the setup parameter on the Transport line in 7696 a SETUP request, to indicate the SETUP request prefers the 7697 reuse of an existing connection between client and server (in 7698 which case the client sets the "connection" parameter to 7699 "existing"), or that the client requires the creation of a new 7700 connection between client and server (in which cast the client 7701 sets the "connection" parameter to "new"). Typically, clients 7702 use the "new" value for the first SETUP request for a URL, and 7703 "existing" for subsequent SETUP requests for a URL. 7705 If a client SETUP request assigns the "new" value to 7706 "connection", the server response MUST also assign the "new" 7707 value to "connection" on the Transport line. 7709 If a client SETUP request assigns the "existing" value to 7710 "connection", the server response MUST assign a value of 7711 "existing" or "new" to "connection" on the Transport line, at 7712 its discretion. 7714 The default value of "connection" is "existing", for all SETUP 7715 requests (initial and subsequent). 7717 The combination of transport protocol, profile and lower transport 7718 needs to be defined. A number of combinations are defined in the 7719 Appendix C. 7721 Below is a usage example, showing a client advertising the capability 7722 to handle multicast or unicast, preferring multicast. Since this is 7723 a unicast-only stream, the server responds with the proper transport 7724 parameters for unicast. 7726 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 7727 CSeq: 302 7728 Transport: RTP/AVP;multicast;mode="PLAY", 7729 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 7730 "192.0.2.5:3457";mode="PLAY" 7731 Accept-Ranges: NPT, SMPTE, UTC 7732 User-Agent: PhonyClient/1.2 7734 S->C: RTSP/2.0 200 OK 7735 CSeq: 302 7736 Date: Thu, 23 Jan 1997 15:35:06 GMT 7737 Session: 47112344 7738 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 7739 "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ 7740 "192.0.2.224:6257";mode="PLAY" 7741 Accept-Ranges: NPT 7742 Media-Properties: Random-Access=0.6, Dynamic, 7743 Time-Limited=20081128T165900 7745 18.53. Unsupported 7747 The Unsupported response-header lists the features not supported by 7748 the responding RTSP agent. In the case where the feature was 7749 specified via the Proxy-Require field (Section 18.35), if there is a 7750 proxy on the path between the client and the server, the proxy MUST 7751 send a response message with a status code of 551 (Option Not 7752 Supported). The request MUST NOT be forwarded. 7754 See Section 18.41 for a usage example. 7756 18.54. User-Agent 7758 The User-Agent general-header field contains information about the 7759 user agent originating the request. This is for statistical 7760 purposes, the tracing of protocol violations, and automated 7761 recognition of user agents for the sake of tailoring responses to 7762 avoid particular user agent limitations. User agents SHOULD include 7763 this field with requests. The field can contain multiple product 7764 tokens and comments identifying the agent and any subproducts which 7765 form a significant part of the user agent. By convention, the 7766 product tokens are listed in order of their significance for 7767 identifying the application. 7769 Example: 7770 User-Agent: PhonyClient/1.2 7772 18.55. Via 7774 The Via general-header field MUST be used by proxies to indicate the 7775 intermediate protocols and recipients between the user agent and the 7776 server on requests, and between the origin server and the client on 7777 responses. The field is intended to be used for tracking message 7778 forwards, avoiding request loops, and identifying the protocol 7779 capabilities of all senders along the request/response chain. 7781 Multiple Via field values represents each proxy that has forwarded 7782 the message. Each recipient MUST append its information such that 7783 the end result is ordered according to the sequence of forwarding 7784 applications. 7786 Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by 7787 default, forward the names and ports of hosts within the private/ 7788 protected region. This information SHOULD only be propagated if 7789 explicitly enabled. If not enabled, the via-received of any host 7790 behind the firewall/NAT SHOULD be replaced by an appropriate 7791 pseudonym for that host. 7793 For organizations that have strong privacy requirements for hiding 7794 internal structures, a proxy MAY combine an ordered subsequence of 7795 Via header field entries with identical sent-protocol values into a 7796 single such entry. Applications MUST NOT combine entries which have 7797 different received-protocol values. 7799 18.56. WWW-Authenticate 7801 The WWW-Authenticate response-header field MUST be included in 401 7802 (Unauthorized) response messages. The field value consists of at 7803 least one challenge that indicates the authentication scheme(s) and 7804 parameters applicable to the Request-URI. 7806 The HTTP access authentication process is described in [RFC2617]. 7807 User agents are advised to take special care in parsing the WWW- 7808 Authenticate field value as it might contain more than one challenge, 7809 or if more than one WWW-Authenticate header field is provided, the 7810 contents of a challenge itself can contain a comma-separated list of 7811 authentication parameters. 7813 19. Security Framework 7815 The RTSP security framework consists of two high level components: 7816 the pure authentication mechanisms based on HTTP authentication, and 7817 the message transport protection based on TLS, which is independent 7818 of RTSP. Because of the similarity in syntax and usage between RTSP 7819 servers and HTTP servers, the security for HTTP is re-used to a large 7820 extent. 7822 19.1. RTSP and HTTP Authentication 7824 RTSP and HTTP share common authentication schemes, and thus follow 7825 the same usage guidelines as specified in [RFC2617] and also in 7826 [H15]. Servers SHOULD implement both basic and digest [RFC2617] 7827 authentication. Clients MUST implement both basic and digest 7828 authentication [RFC2617] so that a server that requires the client to 7829 authenticate can trust that the capability is present. 7831 It should be stressed that using the HTTP authentication alone does 7832 not provide full control message security. Therefore, in 7833 environments requiring tighter security for the control messages, TLS 7834 SHOULD be used, see Section 19.2. 7836 19.2. RTSP over TLS 7838 RTSP agents MUST implement RTSP over TLS as defined in this section 7839 and the next Section 19.3. RTSP MUST follow the same guidelines with 7840 regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. 7841 RTSP over TLS is separated from unsecured RTSP both on URI level and 7842 port level. Instead of using the "rtsp" scheme identifier in the 7843 URI, the "rtsps" scheme identifier MUST be used to signal RTSP over 7844 TLS. If no port is given in a URI with the "rtsps" scheme, port 322 7845 MUST be used for TLS over TCP/IP. 7847 When a client tries to setup an insecure channel to the server (using 7848 the "rtsp" URI), and the policy for the resource requires a secure 7849 channel, the server MUST redirect the client to the secure service by 7850 sending a 301 redirect response code together with the correct 7851 Location URI (using the "rtsps" scheme). A user or client MAY 7852 upgrade a non secured URI to a secured by changing the scheme from 7853 "rtsp" to "rtsps". A server implementing support for "rtsps" MUST 7854 allow this. 7856 It should be noted that TLS allows for mutual authentication (when 7857 using both server and client certificates). Still, one of the more 7858 common ways TLS is used is to only provide server side authentication 7859 (often to avoid client certificates). TLS is then used in addition 7860 to HTTP authentication, providing transport security and server 7861 authentication, while HTTP Authentication is used to authenticate the 7862 client. 7864 RTSP includes the possibility to keep a TCP session up between the 7865 client and server, throughout the RTSP session lifetime. It may be 7866 convenient to keep the TCP session, not only to save the extra setup 7867 time for TCP, but also the extra setup time for TLS (even if TLS uses 7868 the resume function, there will be almost two extra round trips). 7869 Still, when TLS is used, such behavior introduces extra active state 7870 in the server, not only for TCP and RTSP, but also for TLS. This may 7871 increase the vulnerability to DoS attacks. 7873 In addition to these recommendations, Section 19.3 gives further 7874 recommendations of TLS usage with proxies. 7876 19.3. Security and Proxies 7878 The nature of a proxy is often to act as a "man-in-the-middle", while 7879 security is often about preventing the existence of a "man-in-the- 7880 middle". This section provides clients with the possibility to use 7881 proxies even when applying secure transports (TLS) between the RTSP 7882 agents. The TLS proxy mechanism allows for server and proxy 7883 identification using certificates. However, the client can not be 7884 identified based on certificates. The client needs to select between 7885 using the procedure specified below or using a TLS connection 7886 directly (by-passing any proxies) to the server. The choice may be 7887 dependent on policies. 7889 There are basically two categories of proxies, the transparent 7890 proxies (of which the client is not aware) and the non-transparent 7891 proxies (of which the client is aware), see Section 15 for an 7892 introduction to RTSP proxies. An infrastructure based on proxies 7893 requires that the trust model is such that both client and servers 7894 can trust the proxies to handle the RTSP messages correctly. To be 7895 able to trust a proxy, the client and server also needs to be aware 7896 of the proxy. Hence, transparent proxies cannot generally be seen as 7897 trusted and will not work well with security (unless they work only 7898 at transport layer). In the rest of this section any reference to 7899 proxy will be to a non-transparent proxy, which inspects or 7900 manipulate the RTSP messages. 7902 HTTP Authentication is built on the assumption of proxies and can 7903 provide user-proxy authentication and proxy-proxy/server 7904 authentication in addition to the client-server authentication. 7906 When TLS is applied and a proxy is used, the client will connect to 7907 the proxy's address when connecting to any RTSP server. This implies 7908 that for TLS, the client will authenticate the proxy server and not 7909 the end server. Note that when the client checks the server 7910 certificate in TLS, it MUST check the proxy's identity (URI or 7911 possibly other known identity) against the proxy's identity as 7912 presented in the proxy's Certificate message. 7914 The problem is that for a proxy accepted by the client, the proxy 7915 needs to be provided information on which grounds it should accept 7916 the next-hop certificate. Both the proxy and the user may have rules 7917 for this, and the user have the possibility to select the desired 7918 behavior. To handle this case, the Accept-Credentials header (See 7919 Section 18.2) is used, where the client can force the proxy/proxies 7920 to relay back the chain of certificates used to authenticate any 7921 intermediate proxies as well as the server. Given the assumption 7922 that the proxies are viewed as trusted, it gives the user a 7923 possibility to enforce policies to each trusted proxy of whether it 7924 should accept the next agent in the chain. However, it should be 7925 noted that not all deployments will return the chain of certificates 7926 used to authenticate any intermediate proxies as well as the server. 7927 An operator of such a deployment may want to hide its topology from 7928 the client. 7930 A proxy MUST use TLS for the next hop if the RTSP request includes a 7931 "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between 7932 client and proxy, or between proxy and proxy), even if the resource 7933 and the end server are not required to use it. The proxy MUST, when 7934 initiating the next hop TLS connection, use the incoming TLS 7935 connections cipher suite list, only modified by removing any cipher 7936 suits that the proxy does not support. In case a proxy fails to 7937 establish a TLS connection due to cipher suite mismatch between proxy 7938 and next hop proxy or server, this is indicated using error code 472 7939 (Failure to establish secure connection). 7941 19.3.1. Accept-Credentials 7943 The Accept-Credentials header can be used by the client to distribute 7944 simple authorization policies to intermediate proxies. The client 7945 includes the Accept-Credentials header to dictate how the proxy 7946 treats the server/next proxy certificate. There are currently three 7947 methods defined: 7949 Any, which means that the proxy (or proxies) MUST accept whatever 7950 certificate presented. This is of course not a recommended 7951 option to use, but may be useful in certain circumstances (such 7952 as testing). 7954 Proxy, which means that the proxy (or proxies) MUST use its own 7955 policies to validate the certificate and decide whether to 7956 accept it or not. This is convenient in cases where the user 7957 has a strong trust relation with the proxy. Reason why a 7958 strong trust relation may exist are; personal/company proxy, 7959 proxy has a out-of-band policy configuration mechanism. 7961 User, which means that the proxy (or proxies) MUST send credential 7962 information about the next hop to the client for authorization. 7963 The client can then decide whether the proxy should accept the 7964 certificate or not. See Section 19.3.2 for further details. 7966 If the Accept-Credentials header is not included in the RTSP request 7967 from the client, then the "Proxy" method MUST be used as default. If 7968 another method than the "Proxy" is to be used, then the Accept- 7969 Credentials header MUST be included in all of the RTSP requests from 7970 the client. This is because it cannot be assumed that the proxy 7971 always keeps the TLS state or the users previous preference between 7972 different RTSP messages (in particular if the time interval between 7973 the messages is long). 7975 With the "Any" and "Proxy" methods the proxy will apply the policy as 7976 defined for each method. If the policy does not accept the 7977 credentials of the next hop, the proxy MUST respond with a message 7978 using status code 471 (Connection Credentials not accepted). 7980 An RTSP request in the direction server to client MUST NOT include 7981 the Accept-Credentials header. As for the non-secured communication, 7982 the possibility for these requests depends on the presence of a 7983 client established connection. However, if the server to client 7984 request is in relation to a session established over a TLS secured 7985 channel, it MUST be sent in a TLS secured connection. That secured 7986 connection MUST also be the one used by the last client to server 7987 request. If no such transport connection exist at the time when the 7988 server desires to send the request, the server MUST discard the 7989 message. 7991 Further policies MAY be defined and registered, but should be done so 7992 with caution. 7994 19.3.2. User approved TLS procedure 7996 For the "User" method, each proxy MUST perform the following 7997 procedure for each RTSP request: 7999 o Setup the TLS session to the next hop if not already present (i.e. 8000 run the TLS handshake, but do not send the RTSP request). 8002 o Extract the peer certificate chain for the TLS session. 8004 o Check if a matching identity and hash of the peer certificate is 8005 present in the Accept-Credentials header. If present, send the 8006 message to the next hop, and conclude these procedures. If not, 8007 go to the next step. 8009 o The proxy responds to the RTSP request with a 470 or 407 response 8010 code. The 407 response code MAY be used when the proxy requires 8011 both user and connection authorization from user or client. In 8012 this message the proxy MUST include a Connection-Credentials 8013 header, see Section 18.12 with the next hop's identity and 8014 certificate. 8016 The client MUST upon receiving a 470 or 407 response with Connection- 8017 Credentials header take the decision on whether to accept the 8018 certificate or not (if it cannot do so, the user SHOULD be 8019 consulted). If the certificate is accepted, the client has to again 8020 send the RTSP request. In that request the client has to include the 8021 Accept-Credentials header including the hash over the DER encoded 8022 certificate for all trusted proxies in the chain. 8024 Example: 8026 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8027 CSeq: 2 8028 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8029 "192.0.2.5:4589" 8030 Accept-Ranges: NPT, SMPTE, UTC 8031 Accept-Credentials: User 8033 P->C: RTSP/2.0 470 Connection Authorization Required 8034 CSeq: 2 8035 Connection-Credentials: "rtsps://test.example.org"; 8036 MIIDNTCCAp... 8038 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8039 CSeq: 3 8040 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8041 "192.0.2.5:4589" 8042 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8043 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8044 Accept-Ranges: NPT, SMPTE, UTC 8046 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8047 CSeq: 3 8048 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8049 "192.0.2.5:4589" 8050 Via: RTSP/2.0 proxy.example.org 8051 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8052 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8053 Accept-Ranges: NPT, SMPTE, UTC 8055 One implication of this process is that the connection for secured 8056 RTSP messages may take significantly more round-trip times for the 8057 first message. A complete extra message exchange between the proxy 8058 connecting to the next hop and the client results because of the 8059 process for approval for each hop. However, if each message contains 8060 the chain of proxies that the requester accepts, the remaining 8061 message exchange should not be delayed. The procedure of including 8062 the credentials in each request rather than building state in each 8063 proxy, avoids the need for revocation procedures. 8065 20. Syntax 8067 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 8068 as defined in RFC 5234 [RFC5234]. It uses the basic definitions 8069 present in RFC 5234. 8071 Please note that ABNF strings, e.g. "Accept", are case insensitive 8072 as specified in section 2.3 of RFC 5234. 8074 20.1. Base Syntax 8076 RTSP header values can be folded onto multiple lines if the 8077 continuation line begins with a space or horizontal tab. All linear 8078 white space, including folding, has the same semantics as SP. A 8079 recipient MAY replace any linear white space with a single SP before 8080 interpreting the field value or forwarding the message downstream. 8081 This is intended to behave exactly as HTTP/1.1 as described in RFC 8082 2616 [RFC2616]. The SWS construct is used when linear white space is 8083 optional, generally between tokens and separators. 8085 To separate the header name from the rest of value, a colon is used, 8086 which, by the above rule, allows whitespace before, but no line 8087 break, and whitespace after, including a line break. The HCOLON 8088 defines this construct. 8090 OCTET = %x00-FF ; any 8-bit sequence of data 8091 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 8092 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 8093 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 8094 ALPHA = UPALPHA / LOALPHA 8095 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 8096 CTL = %x00-1F / %x7F ; any US-ASCII control character 8097 ; (octets 0 - 31) and DEL (127) 8098 CR = %x0D ; US-ASCII CR, carriage return (13) 8099 LF = %x0A ; US-ASCII LF, linefeed (10) 8100 SP = %x20 ; US-ASCII SP, space (32) 8101 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 8102 DQ = %x22 ; US-ASCII double-quote mark (34) 8103 BACKSLASH = %x5C ; US-ASCII backslash (92) 8104 CRLF = CR LF 8105 LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space 8106 SWS = [LWS] ; Separating White Space 8107 HCOLON = *( SP / HT ) ":" SWS 8108 TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs 8109 tspecials = "(" / ")" / "<" / ">" / "@" 8110 / "," / ";" / ":" / BACKSLASH / DQ 8111 / "/" / "[" / "]" / "?" / "=" 8112 / "{" / "}" / SP / HT 8113 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 8114 / %x41-5A / %x5E-7A / %x7C / %x7E) 8115 ; 1* 8116 quoted-string = ( DQ *qdtext DQ ) 8117 qdtext = %x20-21 / %x23-7E / %x80-FF / UTF8-NONASCII 8118 ; any UTF-8 TEXT except <"> 8119 quoted-pair = BACKSLASH CHAR 8120 ctext = %x20-27 / %x2A-7E 8121 / %x80-FF ; any OCTET except CTLs, "(" and ")" 8122 generic-param = token [ EQUAL gen-value ] 8123 gen-value = token / host / quoted-string 8125 safe = "$" / "-" / "_" / "." / "+" 8126 extra = "!" / "*" / "'" / "(" / ")" / "," 8127 rtsp-extra = "!" / "*" / "'" / "(" / ")" 8129 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 8130 / "a" / "b" / "c" / "d" / "e" / "f" 8131 LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 8132 ; lowercase "a-f" Hex 8133 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 8135 unreserved = ALPHA / DIGIT / safe / extra 8136 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 8138 base64 = *base64-unit [base64-pad] 8139 base64-unit = 4base64-char 8140 base64-pad = (2base64-char "==") / (3base64-char "=") 8141 base64-char = ALPHA / DIGIT / "+" / "/" 8142 SLASH = SWS "/" SWS ; slash 8143 EQUAL = SWS "=" SWS ; equal 8144 LPAREN = SWS "(" SWS ; left parenthesis 8145 RPAREN = SWS ")" SWS ; right parenthesis 8146 COMMA = SWS "," SWS ; comma 8147 SEMI = SWS ";" SWS ; semicolon 8148 COLON = SWS ":" SWS ; colon 8149 MINUS = SWS "-" SWS ; minus/dash 8150 LDQUOT = SWS DQ ; open double quotation mark 8151 RDQUOT = DQ SWS ; close double quotation mark 8152 RAQUOT = ">" SWS ; right angle quote 8153 LAQUOT = SWS "<" ; left angle quote 8155 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 8156 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 8157 / %xE0-EF 2UTF8-CONT 8158 / %xF0-F7 3UTF8-CONT 8159 / %xF8-FB 4UTF8-CONT 8160 / %xFC-FD 5UTF8-CONT 8161 UTF8-CONT = %x80-BF 8163 POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] 8164 FLOAT = ["-"] POS-FLOAT 8166 20.2. RTSP Protocol Definition 8168 20.2.1. Generic Protocol elements 8169 RTSP-IRI = schemes ":" IRI-rest 8170 IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] 8171 ihier-part = "//" iauthority ipath-abempty 8172 RTSP-IRI-ref = RTSP-IRI / irelative-ref 8173 irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] 8174 irelative-part = "//" iauthority ipath-abempty 8175 / ipath-absolute 8176 / ipath-noscheme 8177 / ipath-empty 8179 iauthority = < As defined in RFC 3987> 8180 ipath = ipath-abempty ; begins with "/" or is empty 8181 / ipath-absolute ; begins with "/" but not "//" 8182 / ipath-noscheme ; begins with a non-colon segment 8183 / ipath-rootless ; begins with a segment 8184 / ipath-empty ; zero characters 8186 ipath-abempty = *( "/" isegment ) 8187 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 8188 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 8189 ipath-rootless = isegment-nz *( "/" isegment ) 8190 ipath-empty = 0 8192 isegment = *ipchar [";" *ipchar] 8193 isegment-nz = 1*ipchar [";" *ipchar] 8194 / ";" *ipchar 8195 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 8196 / ";" *ipchar-nc 8197 ; non-zero-length segment without any colon ":" 8199 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 8200 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 8202 iquery = < As defined in RFC 3987> 8203 ifragment = < As defined in RFC 3987> 8204 iunreserved = < As defined in RFC 3987> 8205 pct-encoded = < As defined in RFC 3987> 8206 RTSP-URI = schemes ":" URI-rest 8207 RTSP-REQ-URI = schemes ":" URI-req-rest 8208 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 8209 RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel 8210 schemes = "rtsp" / "rtsps" / scheme 8211 scheme = < As defined in RFC 3986> 8212 URI-rest = hier-part [ "?" query ] [ "#" fragment ] 8213 URI-req-rest = hier-part [ "?" query ] 8214 ; Note fragment part not allowed in requests 8215 hier-part = "//" authority path-abempty 8217 RTSP-Relative = relative-part [ "?" query ] [ "#" fragment ] 8218 RTSP-REQ-Rel = relative-part [ "?" query ] 8219 relative-part = "//" authority path-abempty 8220 / path-absolute 8221 / path-noscheme 8222 / path-empty 8224 authority = < As defined in RFC 3986> 8225 query = < As defined in RFC 3986> 8226 fragment = < As defined in RFC 3986> 8228 path = path-abempty ; begins with "/" or is empty 8229 / path-absolute ; begins with "/" but not "//" 8230 / path-noscheme ; begins with a non-colon segment 8231 / path-rootless ; begins with a segment 8232 / path-empty ; zero characters 8234 path-abempty = *( "/" segment ) 8235 path-absolute = "/" [ segment-nz *( "/" segment ) ] 8236 path-noscheme = segment-nz-nc *( "/" segment ) 8237 path-rootless = segment-nz *( "/" segment ) 8238 path-empty = 0 8240 segment = *pchar [";" *pchar] 8241 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 8242 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 8243 ; non-zero-length segment without any colon ":" 8245 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 8246 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 8248 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 8249 / "*" / "+" / "," / "=" 8251 smpte-range = smpte-type ["=" smpte-range-spec] 8252 ; See section 3.4 8253 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 8254 / ( "-" smpte-time ) 8255 smpte-type = "smpte" / "smpte-30-drop" 8256 / "smpte-25" / smpte-type-extension 8257 ; other timecodes may be added 8258 smpte-type-extension = "smpte" token 8259 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 8260 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 8262 npt-range = "npt" ["=" npt-range-spec] 8263 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 8264 npt-time = "now" / npt-sec / npt-hhmmss 8265 npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] 8266 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] 8267 npt-hh = 1*19DIGIT ; any positive number 8268 npt-mm = 1*2DIGIT ; 0-59 8269 npt-ss = 1*2DIGIT ; 0-59 8271 utc-range = "clock" ["=" utc-range-spec] 8272 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 8273 utc-time = utc-date "T" utc-clock "Z" 8274 utc-date = 8DIGIT 8275 utc-clock = 6DIGIT [ "." 1*9DIGIT ] 8277 feature-tag = token 8279 session-id = 1*256( ALPHA / DIGIT / safe ) 8281 extension-header = header-name HCOLON header-value 8282 header-name = token 8283 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 8285 20.2.2. Message Syntax 8286 RTSP-message = Request / Response ; RTSP/2.0 messages 8288 Request = Request-Line 8289 *((general-header 8290 / request-header 8291 / message-header) CRLF) 8292 CRLF 8293 [ message-body-data ] 8295 Response = Status-Line 8296 *((general-header 8297 / response-header 8298 / message-header) CRLF) 8299 CRLF 8300 [ message-body-data ] 8302 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 8304 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 8305 Method = "DESCRIBE" 8306 / "GET_PARAMETER" 8307 / "OPTIONS" 8308 / "PAUSE" 8309 / "PLAY" 8310 / "PLAY_NOTIFY" 8311 / "REDIRECT" 8312 / "SETUP" 8313 / "SET_PARAMETER" 8314 / "TEARDOWN" 8315 / extension-method 8317 extension-method = token 8319 Request-URI = "*" / RTSP-REQ-URI 8320 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 8322 message-body-data = 1*OCTET 8324 Status-Code = "100" ; Continue 8325 / "200" ; OK 8326 / "301" ; Moved Permanently 8327 / "302" ; Found 8328 / "303" ; See Other 8329 / "304" ; Not Modified 8330 / "305" ; Use Proxy 8331 / "400" ; Bad Request 8332 / "401" ; Unauthorized 8333 / "402" ; Payment Required 8334 / "403" ; Forbidden 8335 / "404" ; Not Found 8336 / "405" ; Method Not Allowed 8337 / "406" ; Not Acceptable 8338 / "407" ; Proxy Authentication Required 8339 / "408" ; Request Time-out 8340 / "410" ; Gone 8341 / "411" ; Length Required 8342 / "412" ; Precondition Failed 8343 / "413" ; Request Message Body Too Large 8344 / "414" ; Request-URI Too Large 8345 / "415" ; Unsupported Media Type 8346 / "451" ; Parameter Not Understood 8347 / "452" ; reserved 8348 / "453" ; Not Enough Bandwidth 8349 / "454" ; Session Not Found 8350 / "455" ; Method Not Valid in This State 8351 / "456" ; Header Field Not Valid for Resource 8352 / "457" ; Invalid Range 8353 / "458" ; Parameter Is Read-Only 8354 / "459" ; Aggregate operation not allowed 8355 / "460" ; Only aggregate operation allowed 8356 / "461" ; Unsupported Transport 8357 / "462" ; Destination Unreachable 8358 / "463" ; Destination Prohibited 8359 / "464" ; Data Transport Not Ready Yet 8360 / "465" ; Notification Reason Unknown 8361 / "466" ; Key Management Error 8362 / "470" ; Connection Authorization Required 8363 / "471" ; Connection Credentials not accepted 8364 / "472" ; Failure to establish secure connection 8365 / "500" ; Internal Server Error 8366 / "501" ; Not Implemented 8367 / "502" ; Bad Gateway 8368 / "503" ; Service Unavailable 8369 / "504" ; Gateway Time-out 8370 / "505" ; RTSP Version not supported 8371 / "551" ; Option not supported 8372 / extension-code 8374 extension-code = 3DIGIT 8376 Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) 8377 general-header = Cache-Control 8378 / Connection 8379 / CSeq 8380 / Date 8381 / Media-Properties 8382 / Media-Range 8383 / Pipelined-Requests 8384 / Proxy-Supported 8385 / Seek-Style 8386 / Server 8387 / Supported 8388 / Timestamp 8389 / User-Agent 8390 / Via 8391 / extension-header 8393 request-header = Accept 8394 / Accept-Credentials 8395 / Accept-Encoding 8396 / Accept-Language 8397 / Authorization 8398 / Bandwidth 8399 / Blocksize 8400 / From 8401 / If-Match 8402 / If-Modified-Since 8403 / If-None-Match 8404 / Notify-Reason 8405 / Proxy-Require 8406 / Range 8407 / Referrer 8408 / Request-Status 8409 / Require 8410 / Scale 8411 / Session 8412 / Speed 8413 / Supported 8414 / Terminate-Reason 8415 / Transport 8416 / extension-header 8418 response-header = Accept-Credentials 8419 / Accept-Ranges 8420 / Connection-Credentials 8421 / MTag 8422 / Location 8423 / Proxy-Authenticate 8424 / Public 8425 / Range 8426 / Retry-After 8427 / RTP-Info 8428 / Scale 8429 / Session 8430 / Speed 8431 / Transport 8432 / Unsupported 8433 / WWW-Authenticate 8434 / extension-header 8436 message-header = Allow 8437 / Content-Base 8438 / Content-Encoding 8439 / Content-Language 8440 / Content-Length 8441 / Content-Location 8442 / Content-Type 8443 / Expires 8444 / Last-Modified 8445 / extension-header 8447 20.2.3. Header Syntax 8449 Accept = "Accept" HCOLON 8450 [ accept-range *(COMMA accept-range) ] 8451 accept-range = media-type-range [SEMI accept-params] 8452 media-type-range = ( "*/*" 8453 / ( m-type SLASH "*" ) 8454 / ( m-type SLASH m-subtype ) 8455 ) *( SEMI m-parameter ) 8456 accept-params = "q" EQUAL qvalue *(SEMI generic-param ) 8457 qvalue = ( "0" [ "." *3DIGIT ] ) 8458 / ( "1" [ "." *3("0") ] ) 8459 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision 8460 cred-decision = ("User" [LWS cred-info]) 8461 / "Proxy" 8462 / "Any" 8463 / (token [LWS 1*header-value]) 8464 ; For future extensions 8466 cred-info = cred-info-data *(COMMA cred-info-data) 8468 cred-info-data = DQ RTSP-REQ-URI DQ SEMI hash-alg SEMI base64 8469 hash-alg = "sha-256" / extension-alg 8470 extension-alg = token 8471 Accept-Encoding = "Accept-Encoding" HCOLON 8472 [ encoding *(COMMA encoding) ] 8473 encoding = codings [SEMI accept-params] 8474 codings = content-coding / "*" 8475 content-coding = token 8476 Accept-Language = "Accept-Language" HCOLON 8477 language *(COMMA language) 8478 language = language-range [SEMI accept-params] 8479 language-range = language-tag / "*" 8480 language-tag = primary-tag *( "-" subtag ) 8481 primary-tag = 1*8ALPHA 8482 subtag = 1*8ALPHA 8483 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges 8484 acceptable-ranges = (range-unit *(COMMA range-unit)) 8485 range-unit = "NPT" / "SMPTE" / "UTC" / extension-format 8486 extension-format = token 8487 Allow = "Allow" HCOLON Method *(COMMA Method) 8488 Authorization = "Authorization" HCOLON credentials 8489 credentials = ("Digest" LWS digest-response) 8490 / other-response 8491 digest-response = dig-resp *(COMMA dig-resp) 8492 dig-resp = username / realm / nonce / digest-uri 8493 / dresponse / algorithm / cnonce 8494 / opaque / message-qop 8495 / nonce-count / auth-param 8496 username = "username" EQUAL username-value 8497 username-value = quoted-string 8498 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 8499 digest-uri-value = RTSP-REQ-URI 8500 message-qop = "qop" EQUAL qop-value 8501 cnonce = "cnonce" EQUAL cnonce-value 8502 cnonce-value = nonce-value 8503 nonce-count = "nc" EQUAL nc-value 8504 nc-value = 8LHEX 8505 dresponse = "response" EQUAL request-digest 8506 request-digest = LDQUOT 32LHEX RDQUOT 8507 auth-param = auth-param-name EQUAL 8508 ( token / quoted-string ) 8509 auth-param-name = token 8510 other-response = auth-scheme LWS auth-param 8511 *(COMMA auth-param) 8512 auth-scheme = token 8513 Bandwidth = "Bandwidth" HCOLON 1*19DIGIT 8515 Blocksize = "Blocksize" HCOLON 1*9DIGIT 8517 Cache-Control = "Cache-Control" HCOLON cache-directive 8518 *(COMMA cache-directive) 8519 cache-directive = cache-rqst-directive 8520 / cache-rspns-directive 8522 cache-rqst-directive = "no-cache" 8523 / "max-stale" [EQUAL delta-seconds] 8524 / "min-fresh" EQUAL delta-seconds 8525 / "only-if-cached" 8526 / cache-extension 8528 cache-rspns-directive = "public" 8529 / "private" 8530 / "no-cache" 8531 / "no-transform" 8532 / "must-revalidate" 8533 / "proxy-revalidate" 8534 / "max-age" EQUAL delta-seconds 8535 / cache-extension 8537 cache-extension = token [EQUAL (token / quoted-string)] 8538 delta-seconds = 1*19DIGIT 8540 Connection = "Connection" HCOLON connection-token 8541 *(COMMA connection-token) 8542 connection-token = "close" / token 8544 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 8545 cred-chain = DQ RTSP-REQ-URI DQ SEMI base64 8547 Content-Base = "Content-Base" HCOLON RTSP-URI 8548 Content-Encoding = "Content-Encoding" HCOLON 8549 content-coding *(COMMA content-coding) 8550 Content-Language = "Content-Language" HCOLON 8551 language-tag *(COMMA language-tag) 8552 Content-Length = "Content-Length" HCOLON 1*19DIGIT 8553 Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref 8554 Content-Type = "Content-Type" HCOLON media-type 8555 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 8556 m-type = discrete-type / composite-type 8557 discrete-type = "text" / "image" / "audio" / "video" 8558 / "application" / extension-token 8559 composite-type = "message" / "multipart" / extension-token 8560 extension-token = ietf-token / x-token 8561 ietf-token = token 8562 x-token = "x-" token 8563 m-subtype = extension-token / iana-token 8564 iana-token = token 8565 m-parameter = m-attribute EQUAL m-value 8566 m-attribute = token 8567 m-value = token / quoted-string 8569 CSeq = "CSeq" HCOLON cseq-nr 8570 cseq-nr = 1*9DIGIT 8571 Date = "Date" HCOLON RTSP-date 8572 RTSP-date = rfc1123-date ; HTTP-date 8573 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 8574 date1 = 2DIGIT SP month SP 4DIGIT 8575 ; day month year (e.g., 02 Jun 1982) 8576 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 8577 ; 00:00:00 - 23:59:59 8578 wkday = "Mon" / "Tue" / "Wed" 8579 / "Thu" / "Fri" / "Sat" / "Sun" 8580 month = "Jan" / "Feb" / "Mar" / "Apr" 8581 / "May" / "Jun" / "Jul" / "Aug" 8582 / "Sep" / "Oct" / "Nov" / "Dec" 8584 Expires = "Expires" HCOLON RTSP-date 8585 From = "From" HCOLON from-spec 8586 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 8587 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 8588 addr-spec = RTSP-REQ-URI / absolute-URI 8589 absolute-URI = < As defined in RFC 3986> 8590 display-name = *(token LWS) / quoted-string 8591 from-param = tag-param / generic-param 8592 tag-param = "tag" EQUAL token 8593 If-Match = "If-Match" HCOLON ("*" / message-tag-list) 8594 message-tag-list = message-tag *(COMMA message-tag) 8595 message-tag = [ weak ] opaque-tag 8596 weak = "W/" 8597 opaque-tag = quoted-string 8598 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 8599 If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list) 8600 Last-Modified = "Last-Modified" HCOLON RTSP-date 8601 Location = "Location" HCOLON RTSP-REQ-URI 8602 Media-Properties = "Media-Properties" HCOLON [media-prop-list] 8603 media-prop-list = media-prop-value *(COMMA media-prop-value) 8604 media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) 8605 / "Begining-Only" 8606 / "No-Seeking" 8607 / "Immutable" 8608 / "Dynamic" 8609 / "Time-Progressing" 8610 / "Unlimited" 8611 / ("Time-Limited" EQUAL utc-time) 8612 / ("Time-Duration" EQUAL POS-FLOAT) 8613 / ("Scales" EQUAL scale-value-list) 8614 / media-prop-ext 8615 media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] 8616 scale-value-list = DQ scale-entry *(COMMA scale-entry) DQ 8617 scale-entry = scale-value / (scale-value COLON scale-value) 8618 scale-value = FLOAT 8619 Media-Range = "Media-Range" HCOLON [ranges-list] 8620 ranges-list = ranges-spec *(COMMA ranges-spec) 8621 MTag = "MTag" HCOLON message-tag 8622 Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val 8623 Notify-Reas-val = "end-of-stream" 8624 / "media-properties-update" 8625 / "scale-change" 8626 / Notify-Reason-extension 8627 Notify-Reason-extension = token 8628 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 8629 startup-id = 1*8DIGIT 8631 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list 8632 challenge-list = challenge *(COMMA challenge) 8633 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 8634 / other-challenge 8635 other-challenge = auth-scheme LWS auth-param 8636 *(COMMA auth-param) 8637 digest-cln = realm / domain / nonce 8638 / opaque / stale / algorithm 8639 / qop-options / auth-param 8640 realm = "realm" EQUAL realm-value 8641 realm-value = quoted-string 8642 domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref 8643 *(1*SP RTSP-REQ-Ref ) RDQUOT 8644 nonce = "nonce" EQUAL nonce-value 8645 nonce-value = quoted-string 8646 opaque = "opaque" EQUAL quoted-string 8647 stale = "stale" EQUAL ( "true" / "false" ) 8648 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 8649 qop-options = "qop" EQUAL LDQUOT qop-value 8650 *("," qop-value) RDQUOT 8651 qop-value = "auth" / "auth-int" / token 8652 Proxy-Require = "Proxy-Require" HCOLON feature-tag-list 8653 feature-tag-list = feature-tag *(COMMA feature-tag) 8654 Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] 8656 Public = "Public" HCOLON Method *(COMMA Method) 8658 Range = "Range" HCOLON ranges-spec 8660 ranges-spec = npt-range / utc-range / smpte-range 8661 / range-ext 8662 range-ext = extension-format ["=" range-value] 8663 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 8665 Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) 8666 Request-Status = "Request-Status" HCOLON req-status-info 8667 req-status-info = cseq-info LWS status-info LWS reason-info 8668 cseq-info = "cseq" EQUAL cseq-nr 8669 status-info = "status" EQUAL Status-Code 8670 reason-info = "reason" EQUAL DQ Reason-Phrase DQ 8671 Require = "Require" HCOLON feature-tag-list 8672 RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec 8673 *(COMMA rtsp-info-spec)] 8674 rtsp-info-spec = stream-url 1*ssrc-parameter 8675 stream-url = "url" EQUAL DQ RTSP-REQ-Ref DQ 8676 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 8677 ri-parameter *(SEMI ri-parameter) 8678 ri-parameter = ("seq" EQUAL 1*5DIGIT) 8679 / ("rtptime" EQUAL 1*10DIGIT) 8680 / generic-param 8682 Retry-After = "Retry-After" HCOLON ( RTSP-date / delta-seconds ) 8683 Scale = "Scale" HCOLON scale-value 8684 Seek-Style = "Seek-Style" HCOLON Seek-S-values 8685 Seek-S-values = "RAP" 8686 / "CoRAP" 8687 / "First-Prior" 8688 / "Next" 8689 / Seek-S-value-ext 8690 Seek-S-value-ext = token 8692 Server = "Server" HCOLON ( product / comment ) 8693 *(LWS (product / comment)) 8694 product = token [SLASH product-version] 8695 product-version = token 8696 comment = LPAREN *( ctext / quoted-pair) RPAREN 8698 Session = "Session" HCOLON session-id 8699 [ SEMI "timeout" EQUAL delta-seconds ] 8701 Speed = "Speed" HCOLON lower-bound MINUS upper-bound 8702 lower-bound = POS-FLOAT 8703 upper-bound = POS-FLOAT 8705 Supported = "Supported" HCOLON [feature-tag-list] 8706 Terminate-Reason = "Terminate-Reason" HCOLON TR-Info 8707 TR-Info = TR-Reason *(SEMI TR-Parameter) 8708 TR-Reason = "Session-Timeout" 8709 / "Server-Admin" 8710 / "Internal-Error" 8711 / token 8712 TR-Parameter = TR-time / TR-user-msg / generic-param 8713 TR-time = "time" EQUAL utc-time 8714 TR-user-msg = "user-msg" EQUAL quoted-string 8716 Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay] 8717 timestamp-value = *19DIGIT [ "." *9DIGIT ] 8718 delay = *9DIGIT [ "." *9DIGIT ] 8720 Transport = "Transport" HCOLON transport-spec 8721 *(COMMA transport-spec) 8722 transport-spec = transport-id *trns-parameter 8723 transport-id = trans-id-rtp / other-trans 8724 trans-id-rtp = "RTP/" profile ["/" lower-transport] 8725 ; no LWS is allowed inside transport-id 8726 other-trans = token *("/" token) 8728 profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token 8729 lower-transport = "TCP" / "UDP" / token 8730 trns-parameter = (SEMI ( "unicast" / "multicast" )) 8731 / (SEMI "interleaved" EQUAL channel [ "-" channel ]) 8732 / (SEMI "ttl" EQUAL ttl) 8733 / (SEMI "layers" EQUAL 1*DIGIT) 8734 / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) 8735 / (SEMI "mode" EQUAL mode-spec) 8736 / (SEMI "dest_addr" EQUAL addr-list) 8737 / (SEMI "src_addr" EQUAL addr-list) 8738 / (SEMI "setup" EQUAL contrans-setup) 8739 / (SEMI "connection" EQUAL contrans-con) 8740 / (SEMI "RTCP-mux") 8741 / (SEMI "MIKEY" EQUAL MIKEY-Value) 8742 / (SEMI trn-param-ext) 8743 contrans-setup = "active" / "passive" / "actpass" 8744 contrans-con = "new" / "existing" 8745 trn-param-ext = par-name [EQUAL trn-par-value] 8746 par-name = token 8747 trn-par-value = *(rtsp-unreserved / quoted-string) 8748 ttl = 1*3DIGIT ; 0 to 255 8749 ssrc = 8HEX 8750 channel = 1*3DIGIT ; 0 to 255 8751 MIKEY-Value = base64 8752 mode-spec = ( DQ mode *(COMMA mode) DQ ) 8753 mode = "PLAY" / token 8754 addr-list = quoted-addr *(SLASH quoted-addr) 8755 quoted-addr = DQ (host-port / extension-addr) DQ 8756 host-port = ( host [":" port] ) 8757 / ( ":" port ) 8758 extension-addr = 1*qdtext 8759 host = < As defined in RFC 3986> 8760 port = < As defined in RFC 3986> 8761 Unsupported = "Unsupported" HCOLON feature-tag-list 8763 User-Agent = "User-Agent" HCOLON ( product / comment ) 8764 *(LWS (product / comment)) 8766 field-name-list = field-name *(COMMA field-name) 8767 field-name = token 8768 Via = "Via" HCOLON via-parm *(COMMA via-parm) 8769 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 8770 via-params = via-ttl / via-maddr 8771 / via-received / via-extension 8772 via-ttl = "ttl" EQUAL ttl 8773 via-maddr = "maddr" EQUAL host 8774 via-received = "received" EQUAL (IPv4address / IPv6address) 8775 IPv4address = < As defined in RFC 3986> 8776 IPv6address = < As defined in RFC 3986> 8777 via-extension = generic-param 8778 sent-protocol = protocol-name SLASH protocol-version 8779 SLASH transport-prot 8780 protocol-name = "RTSP" / token 8781 protocol-version = token 8782 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 8783 other-transport = token 8784 sent-by = host [ COLON port ] 8786 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 8788 20.3. SDP extension Syntax 8790 This section defines in ABNF the SDP extensions defined for RTSP. 8791 See Appendix D for the definition of the extensions in text. 8793 control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF 8795 a-range-def = "a=range:" ranges-spec CRLF 8797 a-mtag-def = "a=mtag:" message-tag CRLF 8799 21. Security Considerations 8801 The security considerations and threats around RTSP and its usage can 8802 be divided to considerations around the signaling protocol itself and 8803 the issues related to the media stream delivery. However, when it 8804 comes to mitigations of security threats, a threat depending on the 8805 media stream delivery may in fact be mitigated by a mechanism in the 8806 signaling protocol. 8808 There are several chapters and appendix in this document that defines 8809 security solutions for the protocol. We will reference them when 8810 discussing the threats below. But the reader should take special 8811 notice of the Security Framework (Section 19) and the specification 8812 of how to use SRTP and its key-mangement (Appendix C.1.4) to achieve 8813 certain aspects of the media security. 8815 21.1. Signaling Protocol Threats 8817 This section focus on issues related to the signaling protocol. 8818 Because of the similarity in syntax and usage between RTSP servers 8819 and HTTP servers, the security considerations outlined in [H15] apply 8820 also. 8822 Specifically, please note the following: 8824 Abuse of Server Log Information: RTSP and HTTP servers will 8825 presumably have similar logging mechanisms, and thus should be 8826 equally guarded in protecting the contents of those logs, thus 8827 protecting the privacy of the users of the servers. See 8828 [H15.1.1] for HTTP server recommendations regarding server 8829 logs. 8831 Transfer of Sensitive Information: There is no reason to believe 8832 that information transferred or controlled via RTSP may be any 8833 less sensitive than that normally transmitted via HTTP. 8834 Therefore, all of the precautions regarding the protection of 8835 data privacy and user privacy apply to implementors of RTSP 8836 clients, servers, and proxies. See [H15.1.2] for further 8837 details. 8839 Attacks Based On File and Path Names: Though RTSP URIs are opaque 8840 handles that do not necessarily have file system semantics, it 8841 is anticipated that many implementations will translate 8842 portions of the Request-URIs directly to file system calls. In 8843 such cases, file systems SHOULD follow the precautions outlined 8844 in [H15.5], such as checking for ".." in path components. 8846 Personal Information: RTSP clients are often privy to the same 8847 information that HTTP clients are (user name, location, etc.) 8848 and thus should be equally sensitive. See [H15.1] for further 8849 recommendations. 8851 Privacy Issues Connected to Accept Headers: Since may of the same 8852 "Accept" headers exist in RTSP as in HTTP, the same caveats 8853 outlined in [H15.1.4] with regards to their use should be 8854 followed. 8856 DNS Spoofing: Presumably, given the longer connection times 8857 typically associated to RTSP sessions relative to HTTP 8858 sessions, RTSP client DNS optimizations should be less 8859 prevalent. Nonetheless, the recommendations provided in 8860 [H15.3] are still relevant to any implementation which attempts 8861 to rely on a DNS-to-IP mapping to hold beyond a single use of 8862 the mapping. 8864 Location Headers and Spoofing: If a single server supports multiple 8865 organizations that do not trust each another, then it needs to 8866 check the values of Location and Content-Location header fields 8867 in responses that are generated under control of said 8868 organizations to make sure that they do not attempt to 8869 invalidate resources over which they have no authority. 8870 ([H15.4]) 8872 In addition to the recommendations in the current HTTP specification 8873 (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 8874 2068 [RFC2068], future HTTP specifications may provide additional 8875 guidance on security issues. 8877 The following are added considerations for RTSP implementations. 8879 Session hijacking: Since there is no or little relation between a 8880 transport layer connection and an RTSP session, it is possible 8881 for a malicious client to issue requests with random session 8882 identifiers which would affect unsuspecting clients. To 8883 mitigate this the server SHALL use a large, random and non- 8884 sequential session identifier to minimize the possibility of 8885 this kind of attack. However, unless the RTSP signaling is 8886 always confidentiality protected, e.g. using TLS, an on-path 8887 attacker will be able to hijack a session. To prevent session 8888 hijacking client authentication needs to be performed and only 8889 the authenticated client creating the session SHALL be able to 8890 access that session. 8892 Authentication: Servers SHOULD implement both basic and digest 8893 [RFC2617] authentication. In environments requiring tighter 8894 security for the control messages, the transport layer 8895 mechanism TLS [RFC5246] SHOULD be used. 8897 Persistently suspicious behavior: RTSP servers SHOULD return error 8898 code 403 (Forbidden) upon receiving a single instance of 8899 behavior which is deemed a security risk. RTSP servers SHOULD 8900 also be aware of attempts to probe the server for weaknesses 8901 and entry points and MAY arbitrarily disconnect and ignore 8902 further requests from clients which are deemed to be in 8903 violation of local security policy. 8905 TLS through proxies: If one uses the possibility to connect TLS in 8906 multiple legs (Section 19.3) one really needs to be aware of 8907 the trust model. That procedure requires full faith and trust 8908 in all proxies, which will be identified, that one allows to 8909 connect through. They are men in the middle and have access to 8910 all that goes on over the TLS connection. Thus it is important 8911 to consider if that trust model is acceptable in the actual 8912 application. Further discussion of the actual trust model in 8913 Section 19.3. 8915 Resource Exhaustion: As RTSP is a stateful protocol and establish 8916 resource usage on the server there is a clear possibility to 8917 attack the server by trying to overbook these resources to 8918 perform a denial of service attack. This attack can be both 8919 against ongoing sessions and to prevent others from 8920 establishing sessions. RTSP agents will need to have 8921 mechanisms to prevent single peers from consuming extensive 8922 amounts of resources. The methods for guarding against this 8923 are varied and depends on the agents role and capabilities and 8924 policies. Each implementation have to careful consider their 8925 methods and policies to mitigate this threat. For example 8926 regarding handling of connections there is recommendations in 8927 Section 10.7. 8929 The above threats and consideration has resulted in a set of security 8930 function and mechanism built into or used by the protocol. The 8931 signaling protocol relies on two security features defined in the 8932 Security Framework (Section 19) namely client authentication using 8933 HTTP authentication and TLS based transport protection of the 8934 signaling messages. Both these there mechanism are required to be 8935 implemented by any RTSP agent. 8937 A number of different security mitigations has been designed into the 8938 protocol and will be present by following the specification as 8939 written, for example by ensuring sufficient amount of entropy in the 8940 randomly generated session identifiers when not using client 8941 authentication to prevent session hijacking. When client 8942 authentication is used the protection against hijacking will be 8943 strongly improved by scoping the accessible sessions to the one this 8944 client identity has created. Some of the above threats are such that 8945 the implementation of the RTSP functionality itself needs to consider 8946 which policy and strategy it uses to mitigate them. 8948 21.2. Media Stream Delivery Threats 8950 The fact that RTSP establish and controls a media stream delivery 8951 results in a set of security issues related to the media streams. 8952 This section will attempt to analyze general threats, however the 8953 choice of media stream transport protocol, like RTP will result in 8954 some difference in threats and what mechanisms that exist to mitigate 8955 them. Thus it becomes important that each specification of a new 8956 media stream transport and delivery protocol usable by RTSP requires 8957 its own security analyses. This section will include such a one for 8958 RTP. 8960 The set of general threats from or by the media stream delivery 8961 itself are: 8963 Concentrated denial-of-service attack: The protocol offers the 8964 opportunity for a remote-controlled denial-of-service (DoS) 8965 attack. Where the media stream is the hammer in that DoS attack. 8966 See Section 21.2.1. 8968 Media Confidentiality: The media delivery may contain content of any 8969 type and it is not possible in general to determine how sensitive 8970 this content is from a confidentiality point. Thus it is a strong 8971 requirement that any media delivery protocol provides method for 8972 providing confidentiality of the actual media content. In 8973 addition to the media level confidentiality it becomes critical 8974 that no resource identifier used in the signaling are exposed to 8975 an attacker as they may have human understandable names, or may be 8976 also available to the attacker so they can determine the content 8977 they user was delivered. Thus also the signaling protocol must 8978 provide confidentiality protection of any information related to 8979 the media resource. 8981 Media Integrity and Authentication: There exist several reasons, 8982 such as discrediting the target, misinformation of the target, why 8983 an attacker will have interest to substitute the media stream sent 8984 out from the RTSP server with one of the attackers creation or 8985 selection. Therefore it is important that the media protocol 8986 provides mechanism to verify the source authentication, integrity 8987 and prevent replay attacks on the media stream. 8989 Scope of Multicast: If RTSP is used to control the transmission of 8990 media onto a multicast network it is needed to consider the scope 8991 that delivery has. RTSP supports the TTL Transport header 8992 parameter to indicate this scope for IPv4. IPv6 has a different 8993 mechanism for scope boundary. However, such scope control has 8994 risks, as it may be set too large and distribute media beyond the 8995 intended scope. 8997 Below (Section 21.2.2) we do a protocol specific analysis of security 8998 considerations for RTP based media transport. In that section we 8999 also make clear the requirements on implementing security functions 9000 for RTSP agents supporting media delivery over RTP. 9002 21.2.1. Remote denial of Service Attack 9004 The attacker may initiate traffic flows to one or more IP addresses 9005 by specifying them as the destination in SETUP requests. While the 9006 attacker's IP address may be known in this case, this is not always 9007 useful in prevention of more attacks or ascertaining the attackers 9008 identity. Thus, an RTSP server MUST only allow client-specified 9009 destinations for RTSP-initiated traffic flows if the server has 9010 ensured that the specified destination address accepts receiving 9011 media through different security mechanisms. Security mechanisms 9012 that are acceptable in an increased generality are: 9014 o Verification of the client's identity against a database of known 9015 users using RTSP authentication mechanisms (preferably digest 9016 authentication or stronger) 9018 o A list of addresses that accept to be media destinations, 9019 especially considering user identity 9021 o Media path based verification 9023 The server SHOULD NOT allow the destination field to be set unless a 9024 mechanism exists in the system to authorize the request originator to 9025 direct streams to the recipient. It is preferred that this 9026 authorization be performed by the media recipient (destination) 9027 itself and the credentials passed along to the server. However, in 9028 certain cases, such as when recipient address is a multicast group, 9029 or when the recipient is unable to communicate with the server in an 9030 out-of-band manner, this may not be possible. In these cases the 9031 server may chose another method such as a server-resident 9032 authorization list to ensure that the request originator has the 9033 proper credentials to request stream delivery to the recipient. 9035 One solution that performs the necessary verification of acceptance 9036 of media suitable for unicast based delivery is the ICE based NAT 9037 traversal method described in [I-D.ietf-mmusic-rtsp-nat]. This 9038 mechanism uses random passwords and username so that the probability 9039 of unintended indication as a valid media destination is very low. 9040 In addition the server includes in its STUN requests a cookie 9041 (consisting of random material) that the destination echoes back, 9042 thus the solution also safe-guards against having a off-path attacker 9043 being able to spoof the STUN checks. This leaves this solution 9044 vulnerable only to on-path attackers that can see the STUN requests 9045 go to the target of attack and thus forge a response. 9047 For delivery to multicast addresses there is a need for another 9048 solution which is not specified in this memo. 9050 21.2.2. RTP Security analysis 9052 RTP is a commonly used media transport protocol and has been the most 9053 common choice for RTSP 1.0 implementations. The core RTP protocol 9054 has been in use for a long time and it has well-known security 9055 properties and the RTP security consideration (Section 9 of 9056 [RFC3550]) needs to be reviewed. In perspective of the usage of RTP 9057 in context of RTSP the following properties should be noted: 9059 Stream Additions: RTP has support for multiple simultaneous media 9060 streams in each RTP session. As some use case require support for 9061 non-synchronized adding and removal of media streams and their 9062 identifiers an attacker can easily insert additional media streams 9063 into a session context that according to protocol design is 9064 intended to be played out. Another threat vector is that one of 9065 denial of service by exhausting the resources of the RTP session 9066 receiver, for example by using a large number of SSRC identifier 9067 simultaneously. The strong mitigation of this is to ensure that 9068 one cryptographically authenticates any incoming packet flow to 9069 the RTP session. Weak mitigations like blocking additional media 9070 streams in session contexts easily lead to a denial of service 9071 vulnerability in addition to preventing certain RTP extensions or 9072 use cases which rely on multiple media streams, such as RTP 9073 retransmission [RFC4588] to function. 9075 Forged Feedback: The built in RTP control Protocol (RTCP) also 9076 offers a large attack surface for a couple of different types of 9077 attacks. One venue is to send RTCP feedback to the media sender 9078 indicating large amounts of packet loss and thus trigger an media 9079 bit-rate adaptation response from the sender resulting in lowered 9080 media quality and potentially shut down of the media stream. 9081 Another attack is to perform a resource exhaustion attack on the 9082 receiver by using many SSRC identifiers to create large state 9083 tables and increase the RTCP related processing demands. 9085 RTP/RTCP Extensions: RTP and RTCP extensions generally provide 9086 additional and sometimes extremely powerful tools to do denial of 9087 service or service disruption. For example the Code Control 9088 Message [RFC5104] RTCP extensions enables both locking down the 9089 bit-rate to low values and disrupt video quality by requesting 9090 Intra frames. 9092 Taking into account the above general discussion in Section 21.2 and 9093 the RTP specific discussion in this section it is clear that strong 9094 security mechanism to protect RTP is necessary to support. Therefore 9095 this specification has the following requirements on RTP security 9096 functions for all RTSP agents that handles media streams and where 9097 the media stream transport is done using RTP. 9099 RTSP agents supporting RTP MUST implement SRTP [RFC3711] and thus the 9100 SAVP profile, in addition the secure profile SAVPF MUST also be 9101 supported if the AVPF profile is implemented. This specification 9102 requires no additional crypto transforms or configuration values 9103 beyond the mandatory to implement in RFC3711, i.e. AES-CM and HMAC- 9104 SHA1. The default key-management mechanism which MUST be implemented 9105 is the one defined in the MIKEY Key Establishment (Appendix C.1.4.1). 9106 The MIKEY implementation MUST implement the necessary functions for 9107 MIKEY-RSA-R mode [RFC4738] and in addition the SRTP parameter 9108 negotiation necessary to negotiate the supported SRTP transforms and 9109 parameters. 9111 22. IANA Considerations 9113 This section sets up a number of registries for RTSP 2.0 that should 9114 be maintained by IANA. These registries are separate from any 9115 registries existing for RTSP 1.0. For each registry there is a 9116 description on what it is required to contain, what specification is 9117 needed when adding an entry with IANA, and finally the entries that 9118 this document needs to register. See also the Section 2.7 "Extending 9119 RTSP". There is also an IANA registration of two SDP attributes. 9121 Registries or entries in registries which have been made for RTSP 1.0 9122 are not moved to RTSP 2.0. The registries and entries in registries 9123 of RTSP 1.0 and RTSP 2.0 are indenpendent. If any registry or entry 9124 in a registry is also required in RTSP 2.0, it must follow the below 9125 defined procedure to allocated the registry or entry in a registry. 9127 The sections describing how to register an item uses some of the 9128 requirements level described in RFC 5226 [RFC5226], namely "First 9129 Come, First Served", "Expert Review, "Specification Required", and 9130 "Standards Action". 9132 In case a registry requires a contact person, the authors are the 9133 contact person for any entries created by this document. 9135 A registration request to IANA MUST contain the following 9136 information: 9138 o A name of the item to register according to the rules specified by 9139 the intended registry. 9141 o Indication of who has change control over the feature (for 9142 example, IETF, ISO, ITU-T, other international standardization 9143 bodies, a consortium, a particular company or group of companies, 9144 or an individual); 9146 o A reference to a further description, if available, for example 9147 (in decreasing order of preference) an RFC, a published standard, 9148 a published paper, a patent filing, a technical report, documented 9149 source code or a computer manual; 9151 o For proprietary features, contact information (postal and email 9152 address); 9154 22.1. Feature-tags 9155 22.1.1. Description 9157 When a client and server try to determine what part and functionality 9158 of the RTSP specification and any future extensions that its counter 9159 part implements there is need for a namespace. This registry 9160 contains named entries representing certain functionality. 9162 The usage of feature-tags is explained in Section 11 and 9163 Section 13.1. 9165 22.1.2. Registering New Feature-tags with IANA 9167 The registering of feature-tags is done on a first come, first served 9168 basis. 9170 The name of the feature MUST follow these rules: The name may be of 9171 any length, but SHOULD be no more than twenty characters long. The 9172 name MUST NOT contain any spaces, or control characters. The 9173 registration MUST indicate if the feature-tag applies to clients, 9174 servers, or proxies only or any combinations of these. Any 9175 proprietary feature MUST have as the first part of the name a vendor 9176 tag, which identifies the organization. The registry entries 9177 consists of the feature tag, a one paragraph description of what it 9178 represents, its applicability (server, client, proxy, any 9179 combination) and a reference to its specification where applicable. 9181 Examples for a vendor tag describing a proprietary feature are: 9183 vendorA.specfeat01 9185 vendorA.specfeat02 9187 22.1.3. Registered entries 9189 The following feature-tags are defined in this specification and 9190 hereby registered. The change control belongs to the IETF. 9192 play.basic: The implementation for delivery and playback operations 9193 according to the core RTSP specification, as defined in this 9194 memo. Applies for both clients, servers and proxies. 9196 play.scale: Support of scale operations for media playback. Applies 9197 only for servers. 9199 play.speed: Support of the speed functionality for media delivery. 9200 Applies only for servers. 9202 setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as 9203 discussed in Appendix C.1.6.4. Applies for both client and 9204 servers and any media caching proxy. 9206 This should be represented by IANA as table with the feature tags, 9207 contact person and their references. 9209 22.2. RTSP Methods 9211 22.2.1. Description 9213 What a method is, is described in Section Section 13. Extending the 9214 protocol with new methods allow for totally new functionality. 9216 22.2.2. Registering New Methods with IANA 9218 A new method MUST be registered through an IETF Standards Action. 9219 The reason is that new methods may radically change the protocol's 9220 behavior and purpose. 9222 A specification for a new RTSP method MUST consist of the following 9223 items: 9225 o A method name which follows the ABNF rules for methods. 9227 o A clear specification what a request using the method does and 9228 what responses are expected. Which directions the method is used, 9229 C->S or S->C or both. How the use of headers, if any, modifies 9230 the behavior and effect of the method. 9232 o A list or table specifying which of the IANA registered headers 9233 that are allowed to be used with the method in request or/and 9234 response. The list or table SHOULD follow the format of tables in 9235 Section Section 18. 9237 o Describe how the method relates to network proxies. 9239 22.2.3. Registered Entries 9241 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 9242 GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, 9243 SET_PARAMETER, and TEARDOWN. The initial table of the registry is 9244 below provided. 9246 Method Directionality Reference 9247 ----------------------------------------------------- 9248 DESCRIBE C->S [RFCXXXX] 9249 GET_PARAMETER C->S, S->C [RFCXXXX] 9250 OPTIONS C->S, S->C [RFCXXXX] 9251 PAUSE C->S [RFCXXXX] 9252 PLAY C->S [RFCXXXX] 9253 PLAY_NOTIFY S->C [RFCXXXX] 9254 REDIRECT S->C [RFCXXXX] 9255 SETUP C->S [RFCXXXX] 9256 SET_PARAMETER C->S, S->C [RFCXXXX] 9257 TEARDOWN C->S, S->C [RFCXXXX] 9259 22.3. RTSP Status Codes 9261 22.3.1. Description 9263 A status code is the three digit numbers used to convey information 9264 in RTSP response messages, see Section 8. The number space is 9265 limited and care should be taken not to fill the space. 9267 22.3.2. Registering New Status Codes with IANA 9269 A new status code registration follows the policy of IETF Review. A 9270 specification for a new status code MUST specify the following: 9272 o The registered number. 9274 o A description what the status code means and the expected behavior 9275 of the sender and receiver of the code. 9277 22.3.3. Registered Entries 9279 RFCXXXX, registers the numbered status code defined in the ABNF entry 9280 "Status-Code" except "extension-code" (that defines the syntax 9281 allowed for future extensions) in Section 20.2.2. 9283 22.4. RTSP Headers 9285 22.4.1. Description 9287 By specifying new headers a method(s) can be enhanced in many 9288 different ways. An unknown header will be ignored by the receiving 9289 agent. If the new header is vital for a certain functionality, a 9290 feature-tag for the functionality can be created and demanded to be 9291 used by the counter-part with the inclusion of a Require header 9292 carrying the feature-tag. 9294 22.4.2. Registering New Headers with IANA 9296 Registrations in the registry can be done following the Expert Review 9297 policy. A specification SHOULD be provided, preferably an IETF RFC 9298 or other Standards Developing Organization specification. The 9299 minimal information in a registration request is the header name and 9300 the contact information. 9302 The specification SHOULD contain the following information: 9304 o The name of the header. 9306 o An ABNF specification of the header syntax. 9308 o A list or table specifying when the header may be used, 9309 encompassing all methods, their request or response, the direction 9310 (C->S or S->C). 9312 o How the header is to be handled by proxies. 9314 o A description of the purpose of the header. 9316 22.4.3. Registered entries 9318 All headers specified in Section 18 in RFCXXXX are to be registered. 9319 The Registry is to include header name, description, and reference. 9321 Furthermore the following legacy RTSP headers defined in other 9322 specifications are registered with header name, reference and 9323 description according to below list. Note: These references may not 9324 fulfill all of the above rules for registrations due to their legacy 9325 status. 9327 o x-wap-profile defined in [TS-26234]. The x-wap-profile request 9328 header contains one or more absolute URLs to the requesting agents 9329 device capability profile. 9331 o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff 9332 request header contains a subset of an device capability profile. 9334 o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- 9335 warning is a response header that contains error codes explaining 9336 to what extent the server has been able to match the terminal 9337 request in regards to device capability profile as described using 9338 x-wap-profile and x-wap-profile-diff headers. 9340 o x-predecbufsize defined in [TS-26234]. This response header 9341 provides an RTSP agent with the TS 26.234 Annex G hypothetical 9342 pre-decoder buffer size. 9344 o x-initpredecbufperiod defined in [TS-26234]. This response header 9345 provides an RTSP agent with the TS 26.234 Annex G hypothetical 9346 pre-decoder buffering period. 9348 o x-initpostdecbufperiod defined in [TS-26234]. This response 9349 header provides an RTSP agent with the TS 26.234 Annex G post- 9350 decoder buffering period. 9352 o 3gpp-videopostdecbufsize defined in [TS-26234]. This response 9353 header provides an RTSP agent with the TS 26.234 defined post- 9354 decoder buffer size usable for H.264 (AVC) video streams. 9356 o 3GPP-Link-Char defined in [TS-26234]. This request header 9357 provides the RTSP server with the RTSP client's link 9358 charateristics as deterimined from the raido interface. The 9359 information that can be provided are guararnteed bit-rate, maximum 9360 bit-rate and maximum transfer delay. 9362 o 3GPP-Adaptation defined in [TS-26234]. This general header is 9363 part of the bit-rate adaptation solution specified for PSS. It 9364 provides the RTSP clients buffer sizes and target buffer levels to 9365 the server and responses are used to acknowledge the support and 9366 values. 9368 o 3GPP-QoE-Metrics defined in [TS-26234]. This general header is 9369 used by PSS RTSP agents to negotiate the quality of experince 9370 metrics that a client should gather and report to the server. 9372 o 3GPP-QoE-Feedback defined in [TS-26234]. This request header is 9373 used by RTSP clients supporting PSS to report the actual values of 9374 the metrics gathered in its quality of experince metering. 9376 The use of "x-" is NOT RECOMMENDED but the above headers in the 9377 register list was defined prior to the clarification. 9379 22.5. Accept-Credentials 9381 The security framework's TLS connection mechanism has two registrable 9382 entities. 9384 22.5.1. Accept-Credentials policies 9386 In Section 19.3.1 three policies for how to handle certificates are 9387 specified. Further policies may be defined and MUST be registered 9388 with IANA using the following rules: 9390 o Registering requires an IETF Standards Action 9392 o A registration is required to name a contact person. 9394 o Name of the policy. 9396 o A describing text that explains how the policy works for handling 9397 the certificates. 9399 This specification registers the following values: 9401 Any 9403 Proxy 9405 User 9407 22.5.2. Accept-Credentials hash algorithms 9409 The Accept-Credentials header (See Section 18.2) allows for the usage 9410 of other algorithms for hashing the DER records of accepted entities. 9411 The registration of any future algorithm is expected to be extremely 9412 rare and could also cause interoperability problems. Therefore the 9413 bar for registering new algorithms is intentionally placed high. 9415 Any registration of a new hash algorithm MUST fulfill the following 9416 requirement: 9418 o Follow the IETF Standards Action policy. 9420 o A definition of the algorithm and its identifier meeting the 9421 "token" ABNF requirement. 9423 The registered value is: 9424 Hash Alg. Id Reference 9425 ------------------------ 9426 sha-256 [RFCXXXX] 9428 22.6. Cache-Control Cache Directive Extensions 9430 There exists a number of cache directives which can be sent in the 9431 Cache-Control header. A registry for these cache directives MUST be 9432 defined with the following rules: 9434 o Registering requires an IETF Standards Action or IESG Approval. 9436 o A registration is required to contain a contact person. 9438 o Name of the directive and a definition of the value, if any. 9440 o Specification if it is a request or response directive. 9442 o A describing text that explains how the cache directive is used 9443 for RTSP controlled media streams. 9445 This specification registers the following values: 9447 no-cache: 9449 public: 9451 private: 9453 no-transform: 9455 only-if-cached: 9457 max-stale: 9459 min-fresh: 9461 must-revalidate: 9463 proxy-revalidate: 9465 max-age: 9467 The registry should be represented as: Name of the directive, contact 9468 person and reference. 9470 22.7. Media Properties 9472 22.7.1. Description 9474 The media streams being controlled by RTSP can have many different 9475 properties. The media properties required to cover the use cases 9476 that was in mind when writing the specification are defined. 9477 However, it can be expected that further innovation will result in 9478 new use cases or media streams with properties not covered by the 9479 ones specified here. Thus new media properties can be specified. As 9480 new media properties may need a substantial amount of new definitions 9481 to correctly specify behavior for this property the bar is intended 9482 to be high. 9484 22.7.2. Registration Rules 9486 Registering new media property MUST fulfill the following 9487 requirements 9489 o Follow the Specification Required policy and get the approval of 9490 the designated Expert. 9492 o Have an ABNF definition of the media property value name that 9493 meets "media-prop-ext" definition 9495 o A Contact Person for the Registration 9497 o Description of all changes to the behavior of the RTSP protocol as 9498 result of these changes. 9500 22.7.3. Registered Values 9502 This specification registers the 9 values listed in Section 18.28. 9503 The registry should be represented as: Name of the media property, 9504 contact person and reference. 9506 22.8. Notify-Reason header 9508 22.8.1. Description 9510 Notify-Reason values are used for indicating the reason the 9511 notification was sent. Each reason has its associated rules on what 9512 headers and information that may or must be included in the 9513 notification. New notification behaviors need to be specified to 9514 enable interoperable usage, thus a specification of each new value is 9515 required. 9517 22.8.2. Registration Rules 9519 Registrations for new Notify-Reason value MUST fulfill the following 9520 requirements 9522 o Follow the Specification Required policy and get the approval of 9523 the designated Expert. 9525 o An ABNF definition of the Notify reason value name that meets 9526 "Notify-Reason-extension" definition 9528 o A Contact Person for the Registration 9530 o Description of which headers shall be included in the request and 9531 response, when it should be sent, and any effect it has on the 9532 server client state. 9534 22.8.3. Registered Values 9536 This specification registers 3 values defined in the Notify-Reas-val 9537 ABNFSection 20.2.3: 9539 end-of-stream: This Notify-Reason header indicates the end of a 9540 media stream. 9542 media-properties-update: This Notify-Reason header allows the server 9543 to indicate that the properties of the media has changed during 9544 the playout. 9546 scale-change: This Notify-Reason header allows the server to notify 9547 the client about a change in the Scale of the media. 9549 The registry entries should be represented in the registry as: Name, 9550 short description, contact and reference. 9552 22.9. Range header formats 9554 22.9.1. Description 9556 The Range header (Section 18.38) allows for different range formats. 9557 New ones may be registered, but moderation should be applied as it 9558 makes interoperability more difficult. 9560 22.9.2. Registration Rules 9562 A registration MUST fulfill the following requirements: 9564 o Follow the Specification Required policy. 9566 o An ABNF definition of the range format that fulfills the "range- 9567 ext" definition. 9569 o A Contact person for the registration. 9571 o Rules for how one handles the range when using a negative Scale. 9573 22.9.3. Registered Values 9575 The registry should be represented as: Name of the range format, 9576 contact person and reference. This specification registers the 9577 following values. 9579 npt: Normal Play Time 9581 clock: UTC Clock format 9583 smpte: SMPTE Timestamps 9585 22.10. Terminate-Reason Header 9587 The Terminate-Reason header (Section 18.50) has two registries for 9588 extensions. 9590 22.10.1. Redirect Reasons 9592 Registrations are done under the policy of Expert Review. The 9593 registered value needs to follow syntax, i.e. be a token. The 9594 specification needs to provide a definition of what procedures are to 9595 be followed when a client receives this redirect reason. This 9596 specification registers two values: 9598 o Session-Timeout 9600 o Server-Admin 9602 The registry should be represented as: Name of the Redirect Reason, 9603 contact person and reference. 9605 22.10.2. Terminate-Reason Header Parameters 9607 Registrations are done under the policy of Specification Required. 9608 The registrations must define a syntax for the parameter that also 9609 follows the syntax allowed by the RTSP 2.0 specification. A contact 9610 person is also required. This specification registers: 9612 o time 9614 o user-msg 9616 The registry should be represented as: Name of the Terminate Reason, 9617 contact person and reference. 9619 22.11. RTP-Info header parameters 9621 22.11.1. Description 9623 The RTP-Info header (Section 18.43) carries one or more parameter 9624 value pairs with information about a particular point in the RTP 9625 stream. RTP extensions or new usages may need new types of 9626 information. As RTP information that could be needed is likely to be 9627 generic enough and to maximize the interoperability registration 9628 requires Specification Required. 9630 22.11.2. Registration Rules 9632 Registrations for new RTP-Info value MUST fulfill the following 9633 requirements 9635 o Follow the Specification Required policy and get the approval of 9636 the designated Expert. 9638 o Have an ABNF definition that meets the "generic-param" definition 9640 o A Contact Person for the Registration 9642 22.11.3. Registered Values 9644 This specification registers the following parameter value pairs: 9646 o url 9648 o ssrc 9650 o seq 9652 o rtptime 9654 The registry should be represented as: Name of the parameter, contact 9655 person and reference. 9657 22.12. Seek-Style Policies 9659 22.12.1. Description 9661 New seek policies may be registered, however, a large number of these 9662 will complicate implementation substantially. The impact of unknown 9663 policies is that the server will not honor the unknown and use the 9664 server default policy instead. 9666 22.12.2. Registration Rules 9668 Registrations of new Seek-Style polices MUST fulfill the following 9669 requirements 9671 o Follow the Specification Required policy. 9673 o Have an ABNF definition of the Seek-Style policy name that meets 9674 "Seek-S-value-ext" definition 9676 o A Contact Person for the Registration 9678 o Description of which headers shall be included in the request and 9679 response, when it should be sent, and any affect it has on the 9680 server client state. 9682 22.12.3. Registered Values 9684 This specification registers 4 values: 9686 o RAP 9688 o CoRAP 9690 o First-Prior 9692 o Next 9694 The registry should be represented as: Name of the Seek-Style Policy, 9695 short description, contact person and reference. 9697 22.13. Transport Header Registries 9699 The transport header contains a number of parameters which have 9700 possibilities for future extensions. Therefore registries for these 9701 need to be defined. 9703 22.13.1. Transport Protocol Specification 9705 A registry for the parameter transport-protocol specification MUST be 9706 defined with the following rules: 9708 o Registering uses the policy of Specification Required. 9710 o A contact person or organization with address and email. 9712 o A value definition that are following the ABNF syntax definition 9713 of "transport-id" Section 20.2.3. 9715 o A describing text that explains how the registered value are used 9716 in RTSP. 9718 The registry should be represented as: The protocol ID string, 9719 contact person and reference. 9721 This specification registers the following values: 9723 RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in 9724 combination with the "RTP profile for audio and video 9725 conferences with minimal control" [RFC3551] over UDP. The 9726 usage is explained in RFC XXXX, Appendix C.1. 9728 RTP/AVP/UDP: the same as RTP/AVP. 9730 RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in 9731 combination with the "Extended RTP Profile for RTCP-based 9732 Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is 9733 explained in RFC XXXX, Appendix C.1. 9735 RTP/AVPF/UDP: the same as RTP/AVPF. 9737 RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in 9738 combination with the "The Secure Real-time Transport Protocol 9739 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 9740 XXXX, Appendix C.1. 9742 RTP/SAVP/UDP: the same as RTP/SAVP. 9744 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 9745 combination with the Extended Secure RTP Profile for Real-time 9746 Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 9747 [RFC5124] over UDP. The usage is explained in RFC XXXX, 9748 Appendix C.1. 9750 RTP/SAVPF/UDP: the same as RTP/SAVPF. 9752 RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport 9753 in combination with the "RTP profile for audio and video 9754 conferences with minimal control" [RFC3551] over TCP. The 9755 usage is explained in RFC XXXX, Appendix C.2.2. 9757 RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 9758 in combination with the "Extended RTP Profile for RTCP-based 9759 Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is 9760 explained in RFC XXXX, Appendix C.2.2. 9762 RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport 9763 in combination with the "The Secure Real-time Transport 9764 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 9765 RFC XXXX, Appendix C.2.2. 9767 RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 9768 in combination with the "Extended Secure RTP Profile for Real- 9769 time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 9770 SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 9771 XXXX, Appendix C.2.2. 9773 22.13.2. Transport modes 9775 A registry for the transport parameter mode MUST be defined with the 9776 following rules: 9778 o Registering requires an IETF Standards Action. 9780 o A contact person or organization with address and email. 9782 o A value definition that are following the ABNF "token" definition 9783 Section 20.2.3. 9785 o A describing text that explains how the registered value are used 9786 in RTSP. 9788 This specification registers 1 value: 9790 PLAY: See RFC XXXX. 9792 22.13.3. Transport Parameters 9794 A registry for parameters that may be included in the Transport 9795 header MUST be defined with the following rules: 9797 o Registering uses the Specification Required policy. 9799 o A value definition that are following the ABNF "token" definition 9800 Section 20.2.3. 9802 o A describing text that explains how the registered value are used 9803 in RTSP. 9805 This specification registers all the transport parameters defined in 9806 Section 18.52. This is a copy of this list: 9808 o unicast 9810 o multicast 9812 o interleaved 9814 o ttl 9816 o layers 9817 o ssrc 9819 o mode 9821 o dest_addr 9823 o src_addr 9825 o setup 9827 o connection 9829 o RTCP-mux 9831 o MIKEY 9833 22.14. URI Schemes 9835 This specification defines two URI schemes ("rtsp" and "rtsps") and 9836 reserves a third one ("rtspu"). These URI schemes are defined in 9837 existing registries which are not created by RTSP. Registrations are 9838 following RFC 4395[RFC4395]. 9840 22.14.1. The rtsp URI Scheme 9842 URI scheme name: rtsp 9844 Status: Permanent 9846 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 9848 URI scheme semantics: The rtsp scheme is used to indicate resources 9849 accessible through the usage of the Real-time Streaming 9850 Protocol (RTSP). RTSP allows different operations on the 9851 resource identified by the URI, but the primary purpose is the 9852 streaming delivery of the resource to a client. However, the 9853 operations that are currently defined are: DESCRIBE, 9854 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, SETUP, 9855 SET_PARAMETER, and TEARDOWN. 9857 Encoding considerations: IRIs in this scheme are defined and needs 9858 to be encoded as RTSP URIs when used within the RTSP protocol. 9859 That encoding is done according to RFC 3987. 9861 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 9862 2326), RTSP 2.0 (RFC XXXX) 9864 Interoperability considerations: The change in URI syntax performed 9865 between RTSP 1.0 and 2.0 can create interoperability issues. 9867 Security considerations: All the security threats identified in 9868 Section 7 of RFC 3986 applies also to this scheme. They need 9869 to be reviewed and considered in any implementation utilizing 9870 this scheme. 9872 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 9874 Author/Change controller: IETF 9876 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 9878 22.14.2. The rtsps URI Scheme 9880 URI scheme name: rtsps 9882 Status: Permanent 9884 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 9886 URI scheme semantics: The rtsps scheme is used to indicate resources 9887 accessible through the usage of the Real-time Streaming 9888 Protocol (RTSP) over TLS. RTSP allows different operations on 9889 the resource identified by the URI, but the primary purpose is 9890 the streaming delivery of the resource to a client. However, 9891 the operations that are currently defined are: DESCRIBE, 9892 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, SETUP, 9893 SET_PARAMETER, and TEARDOWN. 9895 Encoding considerations: IRIs in this scheme are defined and needs 9896 to be encoded as RTSP URIs when used within the RTSP protocol. 9897 That encoding is done according to RFC 3987. 9899 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 9900 2326), RTSP 2.0 (RFC XXXX) 9902 Interoperability considerations: The change in URI syntax performed 9903 between RTSP 1.0 and 2.0 can create interoperability issues. 9905 Security considerations: All the security threats identified in 9906 Section 7 of RFC 3986 applies also to this scheme. They need 9907 to be reviewed and considered in any implementation utilizing 9908 this scheme. 9910 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 9912 Author/Change controller: IETF 9914 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 9916 22.14.3. The rtspu URI Scheme 9918 URI scheme name: rtspu 9920 Status: Permanent 9922 URI scheme syntax: See Section 3.2 of RFC 2326. 9924 URI scheme semantics: The rtspu scheme is used to indicate resources 9925 accessible through the usage of the Real-time Streaming 9926 Protocol (RTSP) over unreliable datagram transport. RTSP 9927 allows different operations on the resource identified by the 9928 URI, but the primary purpose is the streaming delivery of the 9929 resource to a client. However, the operations that are 9930 currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, 9931 PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN. 9933 Encoding considerations: IRIs in this scheme are not defined. 9935 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 9936 2326) 9938 Interoperability considerations: The definition of the transport 9939 mechanism of RTSP over UDP has interoperability issues. That 9940 makes the usage of this scheme problematic. 9942 Security considerations: All the security threats identified in 9943 Section 7 of RFC 3986 applies also to this scheme. They needs 9944 to be reviewed and considered in any implementation utilizing 9945 this scheme. 9947 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 9949 Author/Change controller: IETF 9951 References: RFC 2326 9953 22.15. SDP attributes 9955 This specification defines three SDP [RFC4566] attributes that it is 9956 requested that IANA register. 9958 SDP Attribute ("att-field"): 9960 Attribute name: range 9961 Long form: Media Range Attribute 9962 Type of name: att-field 9963 Type of attribute: Media and session level 9964 Subject to charset: No 9965 Purpose: RFC XXXX 9966 Reference: RFC XXXX, RFC 2326 9967 Values: See ABNF definition. 9969 Attribute name: control 9970 Long form: RTSP control URI 9971 Type of name: att-field 9972 Type of attribute: Media and session level 9973 Subject to charset: No 9974 Purpose: RFC XXXX 9975 Reference: RFC XXXX, RFC 2326 9976 Values: Absolute or Relative URIs. 9978 Attribute name: mtag 9979 Long form: Message Tag 9980 Type of name: att-field 9981 Type of attribute: Media and session level 9982 Subject to charset: No 9983 Purpose: RFC XXXX 9984 Reference: RFC XXXX 9985 Values: See ABNF definition 9987 22.16. Media Type Registration for text/parameters 9989 Type name: text 9991 Subtype name: parameters 9993 Required parameters: 9995 Optional parameters: 9997 Encoding considerations: 9999 Security considerations: This format may carry any type of 10000 parameters. Some can have security requirements, like privacy, 10001 confidentiality or integrity requirements. The format has no 10002 built in security protection. For the usage it was defined the 10003 transport can be protected between server and client using TLS. 10004 However, care must be take to consider if also the proxies are 10005 trusted with the parameters in case hop-by-hop security is used. 10006 If stored as file in file system the necessary precautions needs 10007 to be taken in relation to the parameters requirements including 10008 object security such as S/MIME [RFC5751]. 10010 Interoperability considerations: This media type was mentioned as a 10011 fictional example in RFC 2326 but was not formally specified. 10012 This has resulted in usage of this media type which may not match 10013 its formal definition. 10015 Published specification: RFC XXXX, Appendix F. 10017 Applications that use this media type: Applications that use RTSP 10018 and have additional parameters they like to read and set using the 10019 RTSP GET_PARAMETER and SET_PARAMETER methods. 10021 Additional information: 10023 Magic number(s): 10025 File extension(s): 10027 Macintosh file type code(s): 10029 Person & email address to contact for further information: Magnus 10030 Westerlund (magnus.westerlund@ericsson.com) 10032 Intended usage: Common 10034 Restrictions on usage: None 10036 Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 10038 Change controller: IETF 10040 Addition Notes: 10042 23. References 10044 23.1. Normative References 10046 [FIPS-pub-180-2] 10047 National Institute of Standards and Technology (NIST), 10048 "Federal Information Processing Standards Publications 10049 (FIPS PUBS) 180-2: Secure Hash Standard", August 2002. 10051 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 10052 August 1980. 10054 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 10055 RFC 793, September 1981. 10057 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10058 Requirement Levels", BCP 14, RFC 2119, March 1997. 10060 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 10061 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 10062 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 10064 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 10065 Leach, P., Luotonen, A., and L. Stewart, "HTTP 10066 Authentication: Basic and Digest Access Authentication", 10067 RFC 2617, June 1999. 10069 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 10071 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 10072 Jacobson, "RTP: A Transport Protocol for Real-Time 10073 Applications", STD 64, RFC 3550, July 2003. 10075 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 10076 Video Conferences with Minimal Control", STD 65, RFC 3551, 10077 July 2003. 10079 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10080 10646", STD 63, RFC 3629, November 2003. 10082 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 10083 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 10084 RFC 3711, March 2004. 10086 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 10087 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 10088 August 2004. 10090 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 10091 Resource Identifier (URI): Generic Syntax", STD 66, 10092 RFC 3986, January 2005. 10094 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 10095 Identifiers (IRIs)", RFC 3987, January 2005. 10097 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 10098 Requirements for Security", BCP 106, RFC 4086, June 2005. 10100 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 10101 Registration Procedures", BCP 13, RFC 4288, December 2005. 10103 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10104 Architecture", RFC 4291, February 2006. 10106 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 10107 Registration Procedures for New URI Schemes", BCP 35, 10108 RFC 4395, February 2006. 10110 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 10111 Description Protocol", RFC 4566, July 2006. 10113 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 10114 Carrara, "Key Management Extensions for Session 10115 Description Protocol (SDP) and Real Time Streaming 10116 Protocol (RTSP)", RFC 4567, July 2006. 10118 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 10119 and RTP Control Protocol (RTCP) Packets over Connection- 10120 Oriented Transport", RFC 4571, July 2006. 10122 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 10123 "Extended RTP Profile for Real-time Transport Control 10124 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 10125 July 2006. 10127 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 10128 Encodings", RFC 4648, October 2006. 10130 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 10131 RSA-R: An Additional Mode of Key Distribution in 10132 Multimedia Internet KEYing (MIKEY)", RFC 4738, 10133 November 2006. 10135 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 10136 Real-time Transport Control Protocol (RTCP)-Based Feedback 10137 (RTP/SAVPF)", RFC 5124, February 2008. 10139 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 10140 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 10141 May 2008. 10143 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 10144 Specifications: ABNF", STD 68, RFC 5234, January 2008. 10146 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 10147 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 10149 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 10150 Housley, R., and W. Polk, "Internet X.509 Public Key 10151 Infrastructure Certificate and Certificate Revocation List 10152 (CRL) Profile", RFC 5280, May 2008. 10154 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 10155 Languages", BCP 47, RFC 5646, September 2009. 10157 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 10158 Mail Extensions (S/MIME) Version 3.2 Message 10159 Specification", RFC 5751, January 2010. 10161 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 10162 Control Packets on a Single Port", RFC 5761, April 2010. 10164 [TS-26234] 10165 Third Generation Partnership Project (3GPP), "Transparent 10166 end-to-end Packet-switched Streaming Service (PSS); 10167 Protocols and codecs; Technical Specification 26.234", 10168 December 2002. 10170 23.2. Informative References 10172 [I-D.ietf-mmusic-rtsp-nat] 10173 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 10174 Address Translator (NAT) Traversal mechanism for media 10175 controlled by Real-Time Streaming Protocol (RTSP)", 10176 draft-ietf-mmusic-rtsp-nat-11 (work in progress), 10177 October 2011. 10179 [ISO.13818-6.1995] 10180 International Organization for Standardization, 10181 "Information technology - Generic coding of moving 10182 pictures and associated audio information - part 6: 10183 Extension for digital storage media and control", 10184 ISO Draft Standard 13818-6, November 1995. 10186 [ISO.8601.2000] 10187 International Organization for Standardization, "Data 10188 elements and interchange formats - Information interchange 10189 - Representation of dates and times", ISO/IEC Standard 10190 8601, December 2000. 10192 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 10193 and Support", STD 3, RFC 1123, October 1989. 10195 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 10196 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 10197 RFC 2068, January 1997. 10199 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 10200 Streaming Protocol (RTSP)", RFC 2326, April 1998. 10202 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 10203 (IPv6) Specification", RFC 2460, December 1998. 10205 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 10206 Translator (NAT) Terminology and Considerations", 10207 RFC 2663, August 1999. 10209 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 10210 April 2001. 10212 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 10213 Announcement Protocol", RFC 2974, October 2000. 10215 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 10216 A., Peterson, J., Sparks, R., Handley, M., and E. 10217 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 10218 June 2002. 10220 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 10221 the Session Description Protocol (SDP)", RFC 4145, 10222 September 2005. 10224 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 10225 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 10226 July 2006. 10228 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 10229 "Codec Control Messages in the RTP Audio-Visual Profile 10230 with Feedback (AVPF)", RFC 5104, February 2008. 10232 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 10233 Dependency in the Session Description Protocol (SDP)", 10234 RFC 5583, July 2009. 10236 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 10237 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 10239 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 10240 Time Protocol Version 4: Protocol and Algorithms 10241 Specification", RFC 5905, June 2010. 10243 [Stevens98] 10244 Stevens, W., "Unix Networking Programming - Volume 1, 10245 second edition", 1998. 10247 Appendix A. Examples 10249 This section contains several different examples trying to illustrate 10250 possible ways of using RTSP. The examples can also help with the 10251 understanding of how functions of RTSP work. However, remember that 10252 these are examples and the normative and syntax description in the 10253 other sections takes precedence. Please also note that many of the 10254 examples contain syntax illegal line breaks to accommodate the 10255 formatting restriction that the RFC series impose. 10257 A.1. Media on Demand (Unicast) 10259 This is an example of media on demand streaming of a media stored in 10260 a container file. For purposes of this example, a container file is 10261 a storage entity in which multiple continuous media types pertaining 10262 to the same end-user presentation are present. In effect, the 10263 container file represents an RTSP presentation, with each of its 10264 components being RTSP controlled media streams. Container files are 10265 a widely used means to store such presentations. While the 10266 components are transported as independent streams, it is desirable to 10267 maintain a common context for those streams at the server end. 10269 This enables the server to keep a single storage handle open 10270 easily. It also allows treating all the streams equally in case 10271 of any priorization of streams by the server. 10273 It is also possible that the presentation author may wish to prevent 10274 selective retrieval of the streams by the client in order to preserve 10275 the artistic effect of the combined media presentation. Similarly, 10276 in such a tightly bound presentation, it is desirable to be able to 10277 control all the streams via a single control message using an 10278 aggregate URI. 10280 The following is an example of using a single RTSP session to control 10281 multiple streams. It also illustrates the use of aggregate URIs. In 10282 a container file it is also desirable to not write any URI parts 10283 which is not kept, when the container is distributed, like the host 10284 and most of the path element. Therefore this example also uses the 10285 "*" and relative URI in the delivered SDP. 10287 Also this presentation description (SDP) is not cachable, as the 10288 Expires header is set to an equal value with date indicating 10289 immediate expiration of its valididty. 10291 Client C requests a presentation from media server M. The movie is 10292 stored in a container file. The client has obtained an RTSP URI to 10293 the container file. 10295 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 10296 CSeq: 1 10297 User-Agent: PhonyClient/1.2 10299 M->C: RTSP/2.0 200 OK 10300 CSeq: 1 10301 Server: PhonyServer/1.0 10302 Date: Thu, 24 Jan 1997 15:35:06 GMT 10303 Content-Type: application/sdp 10304 Content-Length: 271 10305 Content-Base: rtsp://example.com/twister.3gp/ 10306 Expires: 24 Jan 1997 15:35:06 GMT 10308 v=0 10309 o=- 2890844256 2890842807 IN IP4 198.51.100.5 10310 s=RTSP Session 10311 i=An Example of RTSP Session Usage 10312 e=adm@example.com 10313 c=IN IP4 0.0.0.0 10314 a=control: * 10315 a=range: npt=0-0:10:34.10 10316 t=0 0 10317 m=audio 0 RTP/AVP 0 10318 a=control: trackID=1 10319 m=video 0 RTP/AVP 26 10320 a=control: trackID=4 10322 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 10323 CSeq: 2 10324 User-Agent: PhonyClient/1.2 10325 Require: play.basic 10326 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 10327 Accept-Ranges: NPT, SMPTE, UTC 10329 M->C: RTSP/2.0 200 OK 10330 CSeq: 2 10331 Server: PhonyServer/1.0 10332 Transport: RTP/AVP;unicast; ssrc=93CB001E; 10333 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 10334 src_addr="198.51.100.5:9000"/"198.51.100.5:9001" 10335 Session: 12345678 10336 Expires: 24 Jan 1997 15:35:12 GMT 10337 Date: 24 Jan 1997 15:35:12 GMT 10338 Accept-Ranges: NPT 10339 Media-Properties: Random-Access=0.02, Immutable, Unlimited 10341 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 10342 CSeq: 3 10343 User-Agent: PhonyClient/1.2 10344 Require: play.basic 10345 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 10346 Session: 12345678 10347 Accept-Ranges: NPT, SMPTE, UTC 10349 M->C: RTSP/2.0 200 OK 10350 CSeq: 3 10351 Server: PhonyServer/1.0 10352 Transport: RTP/AVP;unicast; ssrc=A813FC13; 10353 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 10354 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 10356 Session: 12345678 10357 Expires: 24 Jan 1997 15:35:13 GMT 10358 Date: 24 Jan 1997 15:35:13 GMT 10359 Accept-Range: NPT 10360 Media-Properties: Random-Access=0.8, Immutable, Unlimited 10362 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 10363 CSeq: 4 10364 User-Agent: PhonyClient/1.2 10365 Range: npt=30- 10366 Seek-Style: RAP 10367 Session: 12345678 10369 M->C: RTSP/2.0 200 OK 10370 CSeq: 4 10371 Server: PhonyServer/1.0 10372 Date: 24 Jan 1997 15:35:14 GMT 10373 Session: 12345678 10374 Range: npt=30-634.10 10375 Seek-Style: RAP 10376 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 10377 ssrc=0D12F123:seq=12345;rtptime=3450012, 10378 url="rtsp://example.com/twister.3gp/trackID=1" 10379 ssrc=4F312DD8:seq=54321;rtptime=2876889 10381 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 10382 CSeq: 5 10383 User-Agent: PhonyClient/1.2 10384 Session: 12345678 10386 # Pause happens 0.87 seconds after starting to play 10388 M->C: RTSP/2.0 200 OK 10389 CSeq: 5 10390 Server: PhonyServer/1.0 10391 Date: 24 Jan 1997 15:36:01 GMT 10392 Session: 12345678 10393 Range: npt=30.87-634.10 10395 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 10396 CSeq: 6 10397 User-Agent: PhonyClient/1.2 10398 Range: npt=30.87-634.10 10399 Seek-Style: Next 10400 Session: 12345678 10402 M->C: RTSP/2.0 200 OK 10403 CSeq: 6 10404 Server: PhonyServer/1.0 10405 Date: 24 Jan 1997 15:36:01 GMT 10406 Session: 12345678 10407 Range: npt=30.87-634.10 10408 Seek-Style: Next 10409 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 10410 ssrc=0D12F123:seq=12555;rtptime=6330012, 10411 url="rtsp://example.com/twister.3gp/trackID=1" 10412 ssrc=4F312DD8:seq=55021;rtptime=3132889 10414 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 10415 CSeq: 7 10416 User-Agent: PhonyClient/1.2 10417 Session: 12345678 10419 M->C: RTSP/2.0 200 OK 10420 CSeq: 7 10421 Server: PhonyServer/1.0 10422 Date: 24 Jan 1997 15:49:34 GMT 10424 A.2. Media on Demand using Pipelining 10426 This example is basically the example above (Appendix A.1), but now 10427 utilizing pipelining to speed up the setup. It requires only two 10428 round trip times until the media starts flowing. First of all, the 10429 session description is retrieved to determine what media resources 10430 need to be setup. In the second step, one sends the necessary SETUP 10431 requests and the PLAY request to initiate media delivery. 10433 Client C requests a presentation from media server M. The movie is 10434 stored in a container file. The client has obtained an RTSP URI to 10435 the container file. 10437 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 10438 CSeq: 1 10439 User-Agent: PhonyClient/1.2 10441 M->C: RTSP/2.0 200 OK 10442 CSeq: 1 10443 Server: PhonyServer/1.0 10444 Date: Thu, 23 Jan 1997 15:35:06 GMT 10445 Content-Type: application/sdp 10446 Content-Length: 271 10447 Content-Base: rtsp://example.com/twister.3gp/ 10448 Expires: 24 Jan 1997 15:35:06 GMT 10450 v=0 10451 o=- 2890844256 2890842807 IN IP4 192.0.2.5 10452 s=RTSP Session 10453 i=An Example of RTSP Session Usage 10454 e=adm@example.com 10455 c=IN IP4 0.0.0.0 10456 a=control: * 10457 a=range: npt=0-0:10:34.10 10458 t=0 0 10459 m=audio 0 RTP/AVP 0 10460 a=control: trackID=1 10461 m=video 0 RTP/AVP 26 10462 a=control: trackID=4 10464 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 10465 CSeq: 2 10466 User-Agent: PhonyClient/1.2 10467 Require: play.basic 10468 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 10469 Accept-Ranges: NPT, SMPTE, UTC 10470 Pipelined-Requests: 7654 10472 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 10473 CSeq: 3 10474 User-Agent: PhonyClient/1.2 10475 Require: play.basic 10476 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 10477 Accept-Ranges: NPT, SMPTE, UTC 10478 Pipelined-Requests: 7654 10480 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 10481 CSeq: 4 10482 User-Agent: PhonyClient/1.2 10483 Range: npt=0- 10484 Seek-Style: RAP 10485 Pipelined-Requests: 7654 10487 M->C: RTSP/2.0 200 OK 10488 CSeq: 2 10489 Server: PhonyServer/1.0 10490 Transport: RTP/AVP;unicast; 10491 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 10492 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 10493 ssrc=93CB001E 10494 Session: 12345678 10495 Expires: 24 Jan 1997 15:35:12 GMT 10496 Date: 23 Jan 1997 15:35:12 GMT 10497 Accept-Ranges: NPT 10498 Pipelined-Requests: 7654 10499 Media-Properties: Random-Access=0.2, Immutable, Unlimited 10501 M->C: RTSP/2.0 200 OK 10502 CSeq: 3 10503 Server: PhonyServer/1.0 10504 Transport: RTP/AVP;unicast; 10505 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 10506 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 10507 ssrc=A813FC13 10508 Session: 12345678 10509 Expires: 24 Jan 1997 15:35:13 GMT 10510 Date: 23 Jan 1997 15:35:13 GMT 10511 Accept-Range: NPT 10512 Pipelined-Requests: 7654 10513 Media-Properties: Random-Access=0.8, Immutable, Unlimited 10515 M->C: RTSP/2.0 200 OK 10516 CSeq: 4 10517 Server: PhonyServer/1.0 10518 Date: 23 Jan 1997 15:35:14 GMT 10519 Session: 12345678 10520 Range: npt=0-623.10 10521 Seek-Style: RAP 10522 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 10523 ssrc=0D12F123:seq=12345;rtptime=3450012, 10524 url="rtsp://example.com/twister.3gp/trackID=1" 10525 ssrc=4F312DD8:seq=54321;rtptime=2876889 10526 Pipelined-Requests: 7654 10528 A.3. Media on Demand (Unicast) 10530 An alternative example of media on demand with a bit more tweaks is 10531 the following. Client C requests a movie distributed from two 10532 different media servers A (audio.example.com) and V ( 10533 video.example.com). The media description is stored on a web server 10534 W. The media description contains descriptions of the presentation 10535 and all its streams, including the codecs that are available, dynamic 10536 RTP payload types, the protocol stack, and content information such 10537 as language or copyright restrictions. It may also give an 10538 indication about the timeline of the movie. 10540 In this example, the client is only interested in the last part of 10541 the movie. 10543 C->W: GET /twister.sdp HTTP/1.1 10544 Host: www.example.com 10545 Accept: application/sdp 10547 W->C: HTTP/1.0 200 OK 10548 Date: Thu, 23 Jan 1997 15:35:06 GMT 10549 Content-Type: application/sdp 10550 Content-Length: 278 10551 Expires: 23 Jan 1998 15:35:06 GMT 10553 v=0 10554 o=- 2890844526 2890842807 IN IP4 198.51.100.5 10555 s=RTSP Session 10556 e=adm@example.com 10557 c=IN IP4 0.0.0.0 10558 a=range:npt=0-1:49:34 10559 t=0 0 10560 m=audio 0 RTP/AVP 0 10561 a=control:rtsp://audio.example.com/twister/audio.en 10562 m=video 0 RTP/AVP 31 10563 a=control:rtsp://video.example.com/twister/video 10565 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 10566 CSeq: 1 10567 User-Agent: PhonyClient/1.2 10568 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 10569 RTP/AVP/TCP;unicast;interleaved=0-1 10570 Accept-Ranges: NPT, SMPTE, UTC 10572 A->C: RTSP/2.0 200 OK 10573 CSeq: 1 10574 Session: 12345678 10575 Transport: RTP/AVP/UDP;unicast; 10576 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 10577 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 10578 Date: 23 Jan 1997 15:35:12 GMT 10579 Server: PhonyServer/1.0 10580 Expires: 24 Jan 1997 15:35:12 GMT 10581 Cache-Control: public 10582 Accept-Ranges: NPT, SMPTE 10583 Media-Properties: Random-Access=0.02, Immutable, Unlimited 10585 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 10586 CSeq: 1 10587 User-Agent: PhonyClient/1.2 10588 Transport: RTP/AVP/UDP;unicast; 10589 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", 10590 RTP/AVP/TCP;unicast;interleaved=0-1 10591 Accept-Ranges: NPT, SMPTE, UTC 10593 V->C: RTSP/2.0 200 OK 10594 CSeq: 1 10595 Session: 23456789 10596 Transport: RTP/AVP/UDP;unicast; 10597 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; 10598 src_addr="198.51.100.5:5002"/"198.51.100.5:5003" 10599 Date: 23 Jan 1997 15:35:12 GMT 10600 Server: PhonyServer/1.0 10601 Cache-Control: public 10602 Expires: 24 Jan 1997 15:35:12 GMT 10603 Accept-Ranges: NPT, SMPTE 10604 Media-Properties: Random-Access=1.2, Immutable, Unlimited 10606 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 10607 CSeq: 2 10608 User-Agent: PhonyClient/1.2 10609 Session: 23456789 10610 Range: smpte=0:10:00- 10612 V->C: RTSP/2.0 200 OK 10613 CSeq: 2 10614 Session: 23456789 10615 Range: smpte=0:10:00-1:49:23 10616 Seek-Style: First-Prior 10617 RTP-Info: url="rtsp://video.example.com/twister/video" 10618 ssrc=A17E189D:seq=12312232;rtptime=78712811 10619 Server: PhonyServer/2.0 10620 Date: 23 Jan 1997 15:35:13 GMT 10622 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 10623 CSeq: 2 10624 User-Agent: PhonyClient/1.2 10625 Session: 12345678 10626 Range: smpte=0:10:00- 10628 A->C: RTSP/2.0 200 OK 10629 CSeq: 2 10630 Session: 12345678 10631 Range: smpte=0:10:00-1:49:23 10632 Seek-Style: First-Prior 10633 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 10634 ssrc=3D124F01:seq=876655;rtptime=1032181 10635 Server: PhonyServer/1.0 10636 Date: 23 Jan 1997 15:35:13 GMT 10638 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 10639 CSeq: 3 10640 User-Agent: PhonyClient/1.2 10641 Session: 12345678 10643 A->C: RTSP/2.0 200 OK 10644 CSeq: 3 10645 Server: PhonyServer/1.0 10646 Date: 23 Jan 1997 15:36:52 GMT 10648 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 10649 CSeq: 3 10650 User-Agent: PhonyClient/1.2 10651 Session: 23456789 10653 V->C: RTSP/2.0 200 OK 10654 CSeq: 3 10655 Server: PhonyServer/2.0 10656 Date: 23 Jan 1997 15:36:52 GMT 10658 Even though the audio and video track are on two different servers 10659 that may start at slightly different times and may drift with respect 10660 to each other over time, the client can perform initial 10661 synchronization of the two media using RTP-Info and Range received in 10662 the PLAY responses. If the two servers are time synchronized the 10663 RTCP packets can also be used to maintain synchronization. 10665 A.4. Single Stream Container Files 10667 Some RTSP servers may treat all files as though they are "container 10668 files", yet other servers may not support such a concept. Because of 10669 this, clients needs to use the rules set forth in the session 10670 description for Request-URIs, rather than assuming that a consistent 10671 URI may always be used throughout. Below is an example of how a 10672 multi-stream server might expect a single-stream file to be served: 10674 C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 10675 Accept: application/x-rtsp-mh, application/sdp 10676 CSeq: 1 10677 User-Agent: PhonyClient/1.2 10679 S->C: RTSP/2.0 200 OK 10680 CSeq: 1 10681 Content-base: rtsp://foo.example.com/test.wav/ 10682 Content-type: application/sdp 10683 Content-length: 163 10684 Server: PhonyServer/1.0 10685 Date: Thu, 23 Jan 1997 15:35:06 GMT 10686 Expires: 23 Jan 1997 17:00:00 GMT 10688 v=0 10689 o=- 872653257 872653257 IN IP4 192.0.2.5 10690 s=mu-law wave file 10691 i=audio test 10692 c=IN IP4 0.0.0.0 10693 t=0 0 10694 a=control: * 10695 m=audio 0 RTP/AVP 0 10696 a=control:streamid=0 10698 C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 10699 Transport: RTP/AVP/UDP;unicast; 10700 dest_addr=":6970"/":6971";mode="PLAY" 10701 CSeq: 2 10702 User-Agent: PhonyClient/1.2 10703 Accept-Ranges: NPT, SMPTE, UTC 10705 S->C: RTSP/2.0 200 OK 10706 Transport: RTP/AVP/UDP;unicast; 10707 dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; 10708 src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; 10709 mode="PLAY";ssrc=EAB98712 10710 CSeq: 2 10711 Session: 2034820394 10712 Expires: 23 Jan 1997 16:00:00 GMT 10713 Server: PhonyServer/1.0 10714 Date: 23 Jan 1997 15:35:07 GMT 10715 Accept-Ranges: NPT 10716 Media-Properties: Random-Acces=0.5, Immutable, Unlimited 10718 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 10719 CSeq: 3 10720 User-Agent: PhonyClient/1.2 10721 Session: 2034820394 10723 S->C: RTSP/2.0 200 OK 10724 CSeq: 3 10725 Server: PhonyServer/1.0 10726 Date: 23 Jan 1997 15:35:08 GMT 10727 Session: 2034820394 10728 Range: npt=0-600 10729 Seek-Style: RAP 10730 RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" 10731 ssrc=0D12F123:seq=981888;rtptime=3781123 10733 Note the different URI in the SETUP command, and then the switch back 10734 to the aggregate URI in the PLAY command. This makes complete sense 10735 when there are multiple streams with aggregate control, but is less 10736 than intuitive in the special case where the number of streams is 10737 one. However, the server has declared the aggregated control URI in 10738 the SDP and therefore this is legal. 10740 In this case, it is also required that servers accept implementations 10741 that use the non-aggregated interpretation and use the individual 10742 media URI, like this: 10744 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 10745 CSeq: 3 10746 User-Agent: PhonyClient/1.2 10747 Session: 2034820394 10749 A.5. Live Media Presentation Using Multicast 10751 The media server M chooses the multicast address and port. Here, it 10752 is assumed that the web server only contains a pointer to the full 10753 description, while the media server M maintains the full description. 10755 C->W: GET /sessions.html HTTP/1.1 10756 Host: www.example.com 10758 W->C: HTTP/1.1 200 OK 10759 Content-Type: text/html 10761 10762 ... 10763 10764 Streamed Live Music performance 10765 ... 10766 10768 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 10769 CSeq: 1 10770 Supported: play.basic, play.scale 10771 User-Agent: PhonyClient/1.2 10773 M->C: RTSP/2.0 200 OK 10774 CSeq: 1 10775 Content-Type: application/sdp 10776 Content-Length: 183 10777 Server: PhonyServer/1.0 10778 Date: Thu, 23 Jan 1997 15:35:06 GMT 10779 Supported: play.basic 10781 v=0 10782 o=- 2890844526 2890842807 IN IP4 192.0.2.5 10783 s=RTSP Session 10784 t=0 0 10785 m=audio 3456 RTP/AVP 0 10786 c=IN IP4 233.252.0.54/16 10787 a=control: rtsp://live.example.com/concert/audio 10788 a=range:npt=0- 10790 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 10791 CSeq: 2 10792 Transport: RTP/AVP;multicast; 10793 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 10794 Accept-Ranges: NPT, SMPTE, UTC 10795 User-Agent: PhonyClient/1.2 10797 M->C: RTSP/2.0 200 OK 10798 CSeq: 2 10799 Server: PhonyServer/1.0 10800 Date: Thu, 23 Jan 1997 15:35:06 GMT 10801 Transport: RTP/AVP;multicast; 10802 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 10803 ;ssrc=4D12AB92/0DF876A3 10804 Session: 0456804596 10805 Accept-Ranges: NPT, UTC 10806 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 10808 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 10809 CSeq: 3 10810 Session: 0456804596 10811 User-Agent: PhonyClient/1.2 10813 M->C: RTSP/2.0 200 OK 10814 CSeq: 3 10815 Server: PhonyServer/1.0 10816 Date: 23 Jan 1997 15:35:07 GMT 10817 Session: 0456804596 10818 Seek-Style: Next 10819 Range:npt=1256- 10820 RTP-Info: url="rtsp://live.example.com/concert/audio" 10821 ssrc=0D12F123:seq=1473; rtptime=80000 10823 A.6. Capability Negotiation 10825 This example illustrates how the client and server determines their 10826 capability to support a special feature, in this case "play.scale". 10827 The server, through the clients request and the included Supported 10828 header, learns the client supports RTSP 2.0, and also supports the 10829 playback time scaling feature of RTSP. The server's response 10830 contains the following feature related information to the client; it 10831 supports the basic media delivery functions (play.basic), the 10832 extended functionality of time scaling of content (play.scale), and 10833 one "example.com" proprietary feature (com.example.flight). The 10834 client also learns the methods supported (Public header) by the 10835 server for the indicated resource. 10837 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 10838 CSeq: 1 10839 Supported: play.basic, play.scale 10840 User-Agent: PhonyClient/1.2 10842 S->C: RTSP/2.0 200 OK 10843 CSeq: 1 10844 Public: OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER 10845 Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE 10846 Server: PhonyServer/2.0 10847 Supported: play.basic, play.scale, com.example.flight 10849 When the client sends its SETUP request it tells the server that it 10850 requires support of the play.scale feature for this session by 10851 including the Require header. 10853 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 10854 CSeq: 3 10855 User-Agent: PhonyClient/1.2 10856 Transport: RTP/AVP/UDP;unicast; 10857 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", 10858 RTP/AVP/TCP;unicast;interleaved=0-1 10859 Require: play.scale 10860 Accept-Ranges: NPT, SMPTE, UTC 10861 User-Agent: PhonyClient/1.2 10863 S->C: RTSP/2.0 200 OK 10864 CSeq: 3 10865 Session: 12345678 10866 Transport: RTP/AVP/UDP;unicast; 10867 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 10868 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 10869 Server: PhonyServer/2.0 10870 Accept-Ranges: NPT, SMPTE 10871 Media-Properties: Random-Access=0.8, Immutable, Unlimited 10873 Appendix B. RTSP Protocol State Machine 10875 The RTSP session state machine describes the behavior of the protocol 10876 from RTSP session initialization through RTSP session termination. 10878 The State machine is defined on a per session basis which is uniquely 10879 identified by the RTSP session identifier. The session may contain 10880 one or more media streams depending on state. If a single media 10881 stream is part of the session it is in non-aggregated control. If 10882 two or more is part of the session it is in aggregated control. 10884 The below state machine is an informative description of the 10885 protocols behavior. In case of ambiguity with the earlier parts of 10886 this specification, the description in the earlier parts take 10887 precedence. 10889 B.1. States 10891 The state machine contains three states, described below. For each 10892 state there exist a table which shows which requests and events are 10893 allowed and whether they will result in a state change. 10895 Init: Initial state no session exists. 10897 Ready: Session is ready to start playing. 10899 Play: Session is playing, i.e. sending media stream data in the 10900 direction S->C. 10902 B.2. State variables 10904 This representation of the state machine needs more than its state to 10905 work. A small number of variables is also needed and they are 10906 explained below. 10908 NRM: The number of media streams part of this session. 10910 RP: Resume point, the point in the presentation time line at which 10911 a request to continue playing will resume from. A time format 10912 for the variable is not mandated. 10914 B.3. Abbreviations 10916 To make the state tables more compact a number of abbreviations are 10917 used, which are explained below. 10919 IFI: IF Implemented. 10921 md: Media 10923 PP: Pause Point, the point in the presentation time line at which 10924 the presentation was paused. 10926 Prs: Presentation, the complete multimedia presentation. 10928 RedP: Redirect Point, the point in the presentation time line at 10929 which a REDIRECT was specified to occur. 10931 SES: Session. 10933 B.4. State Tables 10935 This section contains a table for each state. The table contains all 10936 the requests and events that this state is allowed to act on. The 10937 events which are method names are, unless noted, requests with the 10938 given method in the direction client to server (C->S). In some cases 10939 there exist one or more requisite. The response column tells what 10940 type of response actions should be performed. Possible actions that 10941 are requested for an event includes: response codes, e.g. 200, 10942 headers that needs to be included in the response, setting of state 10943 variables, or setting of other session related parameters. The new 10944 state column tells which state the state machine changes to. 10946 The response to a valid request meeting the requisites is normally a 10947 2xx (SUCCESS) unless other noted in the response column. The 10948 exceptions need to be given a response according to the response 10949 column. If the request does not meet the requisite, is erroneous or 10950 some other type of error occur, the appropriate response code is to 10951 be sent. If the response code is a 4xx the session state is 10952 unchanged. A response code of 3rr will result in that the session is 10953 ended and its state is changed to Init. A response code of 304 10954 results in no state change. However, there are restrictions to when 10955 a 3rr response may be used. A 5xx response does not result in any 10956 change of the session state, except if the error is not possible to 10957 recover from. A unrecoverable error results in the ending of the 10958 session. As it in the general case can't be determined if it was a 10959 unrecoverable error or not the client will be required to test. In 10960 the case that the next request after a 5xx is responded with 454 10961 (Session Not Found) the client knows that the session has ended. For 10962 any request message that cannot be responded to within the time 10963 defined in Section 10.4, a 100 response must be sent. 10965 The server will timeout the session after the period of time 10966 specified in the SETUP response, if no activity from the client is 10967 detected. Therefore there exists a timeout event for all states 10968 except Init. 10970 In the case that NRM = 1 the presentation URI is equal to the media 10971 URI or a specified presentation URI. For NRM > 1 the presentation 10972 URI needs to be other than any of the medias that are part of the 10973 session. This applies to all states. 10975 +---------------+-----------------+---------------------------------+ 10976 | Event | Prerequisite | Response | 10977 +---------------+-----------------+---------------------------------+ 10978 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 10979 | | | | 10980 | DESCRIBE | | 200, Session description | 10981 | | | | 10982 | OPTIONS | Session ID | 200, Reset session timeout | 10983 | | | timer | 10984 | | | | 10985 | OPTIONS | | 200 | 10986 | | | | 10987 | SET_PARAMETER | Valid parameter | 200, change value of parameter | 10988 | | | | 10989 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 10990 +---------------+-----------------+---------------------------------+ 10992 Table 13: None state-machine changing events 10994 The methods in Table 13 do not have any effect on the state machine 10995 or the state variables. However, some methods do change other 10996 session related parameters, for example SET_PARAMETER which will set 10997 the parameter(s) specified in its body. Also all of these methods 10998 that allow Session header will also update the keep-alive timer for 10999 the session. 11001 +------------------+----------------+-----------+-------------------+ 11002 | Action | Requisite | New State | Response | 11003 +------------------+----------------+-----------+-------------------+ 11004 | SETUP | | Ready | NRM=1, RP=0.0 | 11005 | | | | | 11006 | SETUP | Needs Redirect | Init | 3rr Redirect | 11007 | | | | | 11008 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 11009 +------------------+----------------+-----------+-------------------+ 11011 Table 14: State: Init 11013 The initial state of the state machine, see Table 14 can only be left 11014 by processing a correct SETUP request. As seen in the table the two 11015 state variables are also set by a correct request. This table also 11016 shows that a correct SETUP can in some cases be redirected to another 11017 URI and/or server by a 3rr response. 11019 +-------------+------------------------+---------+------------------+ 11020 | Action | Requisite | New | Response | 11021 | | | State | | 11022 +-------------+------------------------+---------+------------------+ 11023 | SETUP | New URI | Ready | NRM +=1 | 11024 | | | | | 11025 | SETUP | URI Setup prior | Ready | Change transport | 11026 | | | | param | 11027 | | | | | 11028 | TEARDOWN | Prs URI, | Init | No session hdr, | 11029 | | | | NRM = 0 | 11030 | | | | | 11031 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 11032 | | | | NRM = 0 | 11033 | | | | | 11034 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | 11035 | | | | -= 1 | 11036 | | | | | 11037 | PLAY | Prs URI, No range | Play | Play from RP | 11038 | | | | | 11039 | PLAY | Prs URI, Range | Play | According to | 11040 | | | | range | 11041 | | | | | 11042 | PLAY | md URI, NRM=1, Range | Play | According to | 11043 | | | | range | 11044 | | | | | 11045 | PLAY | md URI, NRM=1 | Play | Play from RP | 11046 | | | | | 11047 | PAUSE | Prs URI | Ready | Return PP | 11048 | | | | | 11049 | SC:REDIRECT | Terminate-Reason | Ready | Set RedP | 11050 | | | | | 11051 | SC:REDIRECT | No Terminate-Reason | Init | Session is | 11052 | | time parameter | | removed | 11053 | | | | | 11054 | Timeout | | Init | | 11055 | | | | | 11056 | RedP | | Init | TEARDOWN of | 11057 | reached | | | session | 11058 +-------------+------------------------+---------+------------------+ 11060 Table 15: State: Ready 11062 In the Ready state, see Table 15, some of the actions are depending 11063 on the number of media streams (NRM) in the session, i.e., aggregated 11064 or non-aggregated control. A SETUP request in the Ready state can 11065 either add one more media stream to the session or, if the media 11066 stream (same URI) already is part of the session, change the 11067 transport parameters. TEARDOWN is depending on both the Request-URI 11068 and the number of media stream within the session. If the Request- 11069 URI is the presentations URI the whole session is torn down. If a 11070 media URI is used in the TEARDOWN request and more than one media 11071 exists in the session, the session will remain and a session header 11072 is returned in the response. If only a single media stream remains 11073 in the session when performing a TEARDOWN with a media URI the 11074 session is removed. The number of media streams remaining after 11075 tearing down a media stream determines the new state. 11077 +----------------+-----------------------+--------+-----------------+ 11078 | Action | Requisite | New | Response | 11079 | | | State | | 11080 +----------------+-----------------------+--------+-----------------+ 11081 | PAUSE | Prs URI | Ready | Set RP to | 11082 | | | | present point | 11083 | | | | | 11084 | End of media | All media | Play | Set RP = End of | 11085 | | | | media | 11086 | | | | | 11087 | End of range | | Play | Set RP = End of | 11088 | | | | range | 11089 | | | | | 11090 | PLAY | Prs URI, No range | Play | Play from | 11091 | | | | present point | 11092 | | | | | 11093 | PLAY | Prs URI, Range | Play | According to | 11094 | | | | range | 11095 | | | | | 11096 | SC:PLAY_NOTIFY | | Play | 200 | 11097 | | | | | 11098 | SETUP | New URI | Play | 455 | 11099 | | | | | 11100 | SETUP | Setuped URI | Play | 455 | 11101 | | | | | 11102 | SETUP | Setuped URI, IFI | Play | Change | 11103 | | | | transport | 11104 | | | | param. | 11105 | | | | | 11106 | TEARDOWN | Prs URI | Init | No session hdr | 11107 | | | | | 11108 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 11109 | | | | NRM=0 | 11110 | | | | | 11111 | TEARDOWN | md URI | Play | 455 | 11112 | | | | | 11113 | SC:REDIRECT | Terminate Reason with | Play | Set RedP | 11114 | | Time parameter | | | 11115 | | | | | 11116 | SC:REDIRECT | | Init | Session is | 11117 | | | | removed | 11118 | | | | | 11119 | RedP reached | | Init | TEARDOWN of | 11120 | | | | session | 11121 | | | | | 11122 | Timeout | | Init | Stop Media | 11123 | | | | playout | 11124 +----------------+-----------------------+--------+-----------------+ 11125 Table 16: State: Play 11127 The Play state table, see Table 16, contains a number of requests 11128 that need a presentation URI (labeled as Prs URI) to work on (i.e., 11129 the presentation URI has to be used as the Request-URI). This is due 11130 to the exclusion of non-aggregated stream control in sessions with 11131 more than one media stream. 11133 To avoid inconsistencies between the client and server, automatic 11134 state transitions are avoided. This can be seen at for example "End 11135 of media" event when all media has finished playing, the session 11136 still remains in Play state. An explicit PAUSE request needs to be 11137 sent to change the state to Ready. It may appear that there exist 11138 automatic transitions in "RedP reached" and "PP reached". However, 11139 they are requested and acknowledged before they take place. The time 11140 at which the transition will happen is known by looking at the range 11141 header. If the client sends a request close in time to these 11142 transitions it needs to be prepared for receiving error messages, as 11143 the state may or may not have changed. 11145 Appendix C. Media Transport Alternatives 11147 This section defines how certain combinations of protocols, profiles 11148 and lower transports are used. This includes the usage of the 11149 Transport header's source and destination address parameters 11150 "src_addr" and "dest_addr". 11152 C.1. RTP 11154 This section defines the interaction of RTSP with respect to the RTP 11155 protocol [RFC3550]. It also defines any necessary media transport 11156 signaling with regards to RTP. 11158 The available RTP profiles and lower layer transports are described 11159 below along with rules on signaling the available combinations. 11161 C.1.1. AVP 11163 The usage of the "RTP Profile for Audio and Video Conferences with 11164 Minimal Control" [RFC3551] when using RTP for media transport over 11165 different lower layer transport protocols is defined below in regards 11166 to RTSP. 11168 One such case is defined within this document, the use of embedded 11169 (interleaved) binary data as defined in Section 14. The usage of 11170 this method is indicated by including the "interleaved" parameter. 11172 When using embedded binary data the "src_addr" and "dest_addr" MUST 11173 NOT be used. This addressing and multiplexing is used as defined 11174 with use of channel numbers and the interleaved parameter. 11176 C.1.2. AVP/UDP 11178 This part describes sending of RTP [RFC3550] over lower transport 11179 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 11180 and Video Conferences with Minimal Control" defined in RFC 3551 11181 [RFC3551]. This profile requires one or two uni- or bi-directional 11182 UDP flows per media stream. The first UDP flow is for RTP and the 11183 second is for RTCP. Embedding of RTP data with the RTSP messages, in 11184 accordance with Section 14, SHOULD NOT be performed when RTSP 11185 messages are transported over unreliable transport protocols, like 11186 UDP [RFC0768]. 11188 The RTP/UDP and RTCP/UDP flows can be established using the Transport 11189 header's "src_addr", and "dest_addr" parameters. 11191 In RTSP PLAY mode, the transmission of RTP packets from client to 11192 server is unspecified. The behavior in regards to such RTP packets 11193 MAY be defined in future. 11195 The "src_addr" and "dest_addr" parameters are used in the following 11196 way for media delivery and playback mode, i.e. Mode=PLAY: 11198 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 11199 2 address specifications. 11201 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 11202 contain either: 11204 * both an address and a port number, or 11206 * a port number without an address. 11208 o The first address and port pair given in either of the parameters 11209 applies to the RTP stream. The second address and port pair if 11210 present applies to the RTCP stream. 11212 o The RTP/UDP packets from the server to the client MUST be sent to 11213 the address and port given by the first address and port pair of 11214 the "dest_addr" parameter. 11216 o The RTCP/UDP packets from the server to the client MUST be sent to 11217 the address and port given by the second address and port pair of 11218 the "dest_addr" parameter. If no second pair is specified RTCP 11219 MUST NOT be sent. 11221 o The RTCP/UDP packets from the client to the server MUST be sent to 11222 the address and port given by the second address and port pair of 11223 the "src_addr" parameter. If no second pair is given RTCP MUST 11224 NOT be sent. 11226 o The RTP/UDP packets from the client to the server MUST be sent to 11227 the address and port given by the first address and port pair of 11228 the "src_addr" parameter. 11230 o RTP and RTCP Packets SHOULD be sent from the corresponding 11231 receiver port, i.e. RTCP packets from the server should be sent 11232 from the "src_addr" parameters second address port pair. 11234 C.1.3. AVPF/UDP 11236 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 11237 AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. 11238 All that is defined for AVP MUST also apply for AVPF. 11240 The usage of AVPF is indicated by the media initialization protocol 11241 used. In the case of SDP it is indicated by media lines (m=) 11242 containing the profile RTP/AVPF. That SDP MAY also contain further 11243 AVPF related SDP attributes configuring the AVPF session regarding 11244 reporting interval and feedback messages to be used. This 11245 configuration MUST be followed. 11247 C.1.4. SAVP/UDP 11249 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 11250 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 11251 using RTP. All that is defined for AVP MUST also apply for SAVP. 11253 The usage of SRTP requires that a security context is established. 11254 The default key-management unless otherwise signalled shall be MIKEY 11255 in RSA-R mode as defined in Appendix C.1.4.1, and not according to 11256 the procedure defined in "Key Management Extensions for Session 11257 Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" 11258 [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY 11259 message in SDP, thus both requiring the usage of the DESCRIBE method 11260 and forcing the server to keep state for clients performing DESCRIBE 11261 in anticipation that they might require key management. 11263 MIKEY is selected as default method for establishing SRTP 11264 cryptographic context within an RTSP session as it can be embedded in 11265 the RTSP messages, while still ensuring confidentiality of content of 11266 the keying material, even when using hop-by-hop TLS security for the 11267 RTSP messages. This method does also support pipelining of the RTSP 11268 messages. 11270 C.1.4.1. MIKEY Key Establishment 11272 This method for using MIKEY [RFC3830] to establish the SRTP 11273 cryptographic context is initiated in the client's SETUP request, and 11274 the servers response to the SETUP carries the MIKEY response. Thus 11275 ensuring that the crypto context establishment happens simultaneously 11276 with the establishment of the media stream being protected. By using 11277 MIKEY's RSA-R mode [RFC4738] the client can be the initiator and 11278 still allow the server to set the parameters in accordance with the 11279 actual media stream. 11281 The SRTP cryptographic context establishment is done according to the 11282 following process: 11284 1. The client determines that SAVP or SAVPF shall be used from 11285 media description format, e.g. SDP. If no other key management 11286 method is explicitly signalled, then MIKEY SHALL be used as 11287 defined herein. This specification does not specify an explicit 11288 method for indicating this SRTP cryptographic context 11289 establishment method, but future specifications may. 11291 2. The client SHALL establish a TLS connection for RTSP messages, 11292 directly or hop by hop with the server. If hop-by-hop TLS 11293 security is used, the User method SHALL be indicated in the 11294 Accept-Credentials header. We do note that using hop-by-hop 11295 does allow the proxy to insert itself as a man in the middle 11296 also in the MIKEY exchange by providing one of its certificates, 11297 rather than the server's in the Connection-Credentials header. 11298 The client SHALL therefore validate the server certificate. 11300 3. The client retrieves the servers certificate from a direct TLS 11301 connection, or if hop by hop from Connection-Credentials header. 11302 The client then checks that the server certificate is valid and 11303 belongs to the server. 11305 4. The client forms the MIKEY Initiator message using RSA-R mode in 11306 unicast mode as specified in [RFC4738]. The client SHOULD use 11307 the same certificate for TLS and in MIKEY to enable the server 11308 to bind the two together. The client's certificate SHALL be 11309 included in the MIKEY message. The client SHALL indicate its 11310 SRTP capabilities in the message. 11312 5. The MIKEY message from the previous step is base64 [RFC4648] 11313 encoded and becomes the value of the MIKEY parameter that is 11314 included in the transport specification(s) that specifies a SRTP 11315 based profile (SAVP, SAVPF) in the SETUP request. 11317 6. Any proxy encountering the MIKEY parameter SHALL forward it 11318 without modification. A proxy requiring to understand transport 11319 specification which doesn't support SAVP/SAVPF with MIKEY will 11320 discard the whole transport specification. Most types of proxy 11321 can easily support SAVP and SAVPF with MIKEY. If possible 11322 bypassing the proxy should be tried. 11324 7. The server upon receiving the SETUP request, will need to decide 11325 upon the transport specification to use, if multiple are 11326 included by the client. In the determination of which transport 11327 specifications that are supported and preferred, the server 11328 SHOULD decode the MIKEY message to take the embedded SRTP 11329 parameters into account. If all transport specs require SRTP 11330 but no MIKEY parameter or other supported keying method is 11331 included, the server SHALL respond with 403. 11333 8. Upon generating a response the following outcomes can occur: 11335 * A transport spec not using SRTP and MIKEY is selected. Thus 11336 the response will not contain any MIKEY parameter. 11338 * A transport spec using SRTP and MIKEY is selected but an 11339 error is encountered in the MIKEY processing. In that case 11340 an RTSP error response code of 466 "Key Management Error" 11341 SHALL be used. A MIKEY message describing the error MAY be 11342 included. 11344 * A transport spec using SRTP and MIKEY is selected and a MIKEY 11345 response message can be created. The server SHOULD use the 11346 same certificate for TLS and in MIKEY to enable client to 11347 bind the two together. If a different certificate is used it 11348 SHALL be included in the MIKEY message. It is RECOMMENDED 11349 that the envelope key cache type is set to 'Cache' and that a 11350 single envelope key is reused for all MIKEY messages to the 11351 client. That message is included in the MIKEY parameter part 11352 of the single selected transport specification in the SETUP 11353 response. The server will set the SRTP parameters as 11354 preferred for this media stream within the supported range by 11355 the client. 11357 9. The server transmits the SETUP response back to the client. 11359 10. The client receives the SETUP response and if the response code 11360 indicates a successful request it decodes the MIKEY message and 11361 establish the SRTP cryptographic context from the parameters in 11362 the MIKEY response. 11364 In the above method the client's certificate may be self-signed in 11365 cases where the client's identity is not necessary to establish and 11366 the security goal is only to ensure that the RTSP signaling client is 11367 the same as the one receiving the SRTP security context. 11369 C.1.5. SAVPF/UDP 11371 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 11372 (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in 11373 RTSP sessions using RTP. All that is defined for AVP MUST also apply 11374 for SAVPF. 11376 The usage of SRTP requires that a cryptographic context is 11377 established. The default mechanism for establishing that security 11378 association is to use MIKEY[RFC3830] with RTSP as defined in 11379 Appendix C.1.4.1. 11381 C.1.6. RTCP usage with RTSP 11383 RTCP has several usages when RTP is used for media transport as 11384 explained below. Due to that RTCP MUST be supported if an RTSP agent 11385 handles RTP. 11387 C.1.6.1. Media synchronization 11389 RTCP provides media synchronization and clock drift compensation. 11390 The initial media synchronization is available from RTP-Info header. 11391 However, to be able to handle any clock drift between the media 11392 streams, RTCP is needed. 11394 C.1.6.2. RTSP Session keep-alive 11396 RTCP traffic from the RTSP client to the RTSP server MUST function as 11397 keep-alive. This requires an RTSP server supporting RTP to use the 11398 received RTCP packets as indications that the client desires the 11399 related RTSP session to be kept alive. 11401 C.1.6.3. Bit-rate adaption 11403 RTCP Receiver reports and any additional feedback from the client 11404 MUST be used to adapt the bit-rate used over the transport for all 11405 cases when RTP is sent over UDP. An RTP sender without reserved 11406 resources MUST NOT use more than its fair share of the available 11407 resources. This can be determined by comparing on short to medium 11408 term (some seconds) the used bit-rate and adapt it so that the RTP 11409 sender sends at a bit-rate comparable to what a TCP sender would 11410 achieve on average over the same path. 11412 C.1.6.4. RTP and RTCP Multiplexing 11414 RTSP can be used to negotiate the usage of RTP and RTCP multiplexing 11415 as described in [RFC5761]. This allows servers and client to reduce 11416 the amount of resources required for the session by only requiring 11417 one underlying transport stream per media stream instead of two when 11418 using RTP and RTCP. This lessens the server port consumption and 11419 also the necessary state and keep-alive work when operating across 11420 Network and Address Translators [RFC2663]. 11422 Content must be prepared with some consideration for RTP and RTCP 11423 multiplexing, mainly ensuring that the RTP payload types used do not 11424 collide with the ones used for RTCP packet types. This option likely 11425 needs explicit support from the content unless the RTP payload types 11426 can be remapped by the server and that is correctly reflected in the 11427 session description. Beyond that support of this feature should come 11428 at little cost and much gain. 11430 It is recommended that if the content and server support RTP and RTCP 11431 multiplexing that this is indicated in the session description, for 11432 example using the SDP attribute "a=rtcp-mux". If the SDP message 11433 contains the a=rtcp-mux attribute for a media stream, the server MUST 11434 support RTP and RTCP multiplexing. If indicated or otherwise desired 11435 by the client it can include the Transport parameter "RTCP-mux" in 11436 any transport specification where it desires to use RTCP-mux. The 11437 server will indicate if it supports RTCP-mux. Servers and Clients 11438 SHOULD support RTP and RTCP multiplexing. 11440 For capability exchange, an RTSP feature tag for RTP and RTCP 11441 multiplexing is defined: "setup.rtp.rtcp.mux". 11443 C.2. RTP over TCP 11445 Transport of RTP over TCP can be done in two ways: over independent 11446 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 11447 control connection. In both cases the protocol MUST be "rtp" and the 11448 lower layer MUST be TCP. The profile may be any of the above 11449 specified ones; AVP, AVPF, SAVP or SAVPF. 11451 C.2.1. Interleaved RTP over TCP 11453 The use of embedded (interleaved) binary data transported on the RTSP 11454 connection is possible as specified in Section 14. When using this 11455 declared combination of interleaved binary data the RTSP messages 11456 MUST be transported over TCP. TLS may or may not be used. 11458 One should, however, consider that this will result in all media 11459 streams go through any proxy. Using independent TCP connections can 11460 avoid that issue. 11462 C.2.2. RTP over independent TCP 11464 In this Appendix, we describe the sending of RTP [RFC3550] over lower 11465 transport layer TCP [RFC0793] according to "Framing Real-time 11466 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 11467 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 11468 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 11469 with RTSP. 11471 A client codes the support of RTP over independent TCP by specifying 11472 an RTP/AVP/TCP transport option without an interleaved parameter in 11473 the Transport line of a SETUP request. This transport option MUST 11474 include the "unicast" parameter. 11476 If the client wishes to use RTP with RTCP, two ports (or two address/ 11477 port pairs) are specified by the dest_addr parameter. If the client 11478 wishes to use RTP without RTCP, one port (or one address/port pair) 11479 is specified by the dest_addr parameter. If the client wishes to 11480 multiplex RTP and RTCP on a single port (see Section 11481 Appendix C.1.6.4, one port (or one address/port pair) is specified by 11482 the dest_addr parameter. Ordering rules of dest_addr ports follow 11483 the rules for RTP/AVP/UDP. 11485 If the client wishes to play the active role in initiating the TCP 11486 connection, it MAY set the "setup" parameter (See Section 18.52) on 11487 the Transport line to be "active", or it MAY omit the setup 11488 parameter, as active is the default. If the client signals the 11489 active role, the ports for all dest_addr values MUST be set to 9 (the 11490 discard port). 11492 If the client wishes to play the passive role in TCP connection 11493 initiation, it MUST set the "setup" parameter on the Transport line 11494 to be "passive". If the client is able to assume the active or the 11495 passive role, it MUST set the "setup" parameter on the Transport line 11496 to be "actpass". In either case, the dest_addr port value for RTP 11497 MUST be set to the TCP port number on which the client is expecting 11498 to receive the RTP stream connection, and the dest_addr port value 11499 for RTCP MUST be set to the TCP port number on which the client is 11500 expecting to receive the RTCP stream connection. 11502 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 11503 server decides to accept this requested option, the 2xx reply MUST 11504 contain a Transport option that specifies RTP/AVP/TCP (without using 11505 the interleaved parameter, and with using the unicast parameter). 11506 The dest_addr parameter value MUST be echoed from the parameter value 11507 in the client request unless the destination address (only port) was 11508 not provided in which case the server MAY include the source address 11509 of the RTSP TCP connection with the port number unchanged. 11511 In addition, the server reply MUST set the setup parameter on the 11512 Transport line, to indicate the role the server will play in the 11513 connection setup. Permissible values are "active" (if a client set 11514 "setup" to "passive" or "actpass") and "passive" (if a client set 11515 "setup" to "active" or "actpass"). 11517 If a server sets "setup" to "passive", the "src_addr" in the reply 11518 MUST indicate the ports the server is willing to receive an RTP 11519 connection and (if the client requested an RTCP connection by 11520 specifying two dest_addr ports or address/port pairs) and RTCP 11521 connection. If a server sets "setup" to "active", the ports 11522 specified in "src_addr" MUST be set to 9. The server MAY use the 11523 "ssrc" parameter, following the guidance in Section 18.52. Port 11524 ordering for src_addr follows the rules for RTP/AVP/UDP. 11526 Servers MUST support taking the passive role and MAY support taking 11527 the active role. Servers with a public IP address take the passive 11528 role, thus enabling clients behind NATs and Firewalls a better chance 11529 of successful connect to the server by actively connecting outwards. 11530 Therefore the clients are RECOMMENDED to take the active role. 11532 After sending (receiving) a 2xx reply for a SETUP method for a non- 11533 interleaved RTP/AVP/TCP media stream, the active party SHOULD 11534 initiate the TCP connection as soon as possible. The client MUST NOT 11535 send a PLAY request prior to the establishment of all the TCP 11536 connections negotiated using SETUP for the session. In case the 11537 server receives a PLAY request in a session that has not yet 11538 established all the TCP connections, it MUST respond using the 464 11539 "Data Transport Not Ready Yet" (Section 17.4.29) error code. 11541 Once the PLAY request for a media resource transported over non- 11542 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 11543 client over the RTP TCP connection, and RTCP packets flow 11544 bidirectionally over the RTCP TCP connection. As in the RTP/UDP 11545 case, client to server traffic on the TCP port is unspecified by this 11546 memo. The packets that travel on these connections MUST be framed 11547 using the protocol defined in [RFC4571], not by the framing defined 11548 for interleaving RTP over the RTSP control connection defined in 11549 Section 14. 11551 A successful PAUSE request for a media being transported over RTP/ 11552 AVP/TCP pauses the flow of packets over the connections, without 11553 closing the connections. A successful TEARDOWN request signals that 11554 the TCP connections for RTP and RTCP are to be closed as soon as 11555 possible. 11557 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 11558 ambiguous in the following way: does the client wish to open up new 11559 TCP RTP and RTCP connections for the URI, or does the client wish to 11560 continue using the existing TCP RTP and RTCP connections? The client 11561 SHOULD use the "connection" parameter (defined in Section 18.52) on 11562 the Transport line to make its intention clear (by setting 11563 "connection" to "new" if new connections are needed, and by setting 11564 "connection" to "existing" if the existing connections are to be 11565 used). After a 2xx reply for a SETUP request for a new connection, 11566 parties should close the pre-existing connections, after waiting a 11567 suitable period for any stray RTP or RTCP packets to arrive. 11569 The usage of SRTP, i.e. either SAVP or SAVPF profiles requires that a 11570 security association is established. The default mechanism for 11571 establishing that security association is to use MIKEY[RFC3830] with 11572 RTSP as defined Appendix C.1.4.1. 11574 Below, we rewrite part of the example media on demand example shown 11575 in Appendix A.1 to use RTP/AVP/TCP non-interleaved: 11577 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11578 CSeq: 1 11579 User-Agent: PhonyClient/1.2 11581 M->C: RTSP/2.0 200 OK 11582 CSeq: 1 11583 Server: PhonyServer/1.0 11584 Date: Thu, 23 Jan 1997 15:35:06 GMT 11585 Content-Type: application/sdp 11586 Content-Length: 227 11587 Content-Base: rtsp://example.com/twister.3gp/ 11588 Expires: 24 Jan 1997 15:35:06 GMT 11590 v=0 11591 o=- 2890844256 2890842807 IN IP4 198.51.100.34 11592 s=RTSP Session 11593 i=An Example of RTSP Session Usage 11594 e=adm@example.com 11595 c=IN IP4 0.0.0.0 11596 a=control: * 11597 a=range: npt=0-0:10:34.10 11598 t=0 0 11599 m=audio 0 RTP/AVP 0 11600 a=control: trackID=1 11602 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11603 CSeq: 2 11604 User-Agent: PhonyClient/1.2 11605 Require: play.basic 11606 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 11607 setup=active;connection=new 11608 Accept-Ranges: NPT, SMPTE, UTC 11610 M->C: RTSP/2.0 200 OK 11611 CSeq: 2 11612 Server: PhonyServer/1.0 11613 Transport: RTP/AVP/TCP;unicast; 11614 dest_addr=":9"/":9"; 11615 src_addr="198.51.100.5:53478"/"198.51.100:54091"; 11616 setup=passive;connection=new;ssrc=93CB001E 11617 Session: 12345678 11618 Expires: 24 Jan 1997 15:35:12 GMT 11619 Date: 23 Jan 1997 15:35:12 GMT 11620 Accept-Ranges: NPT 11621 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11623 C->M: TCP Connection Establishment x2 11625 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11626 CSeq: 4 11627 User-Agent: PhonyClient/1.2 11628 Range: npt=30- 11629 Session: 12345678 11631 M->C: RTSP/2.0 200 OK 11632 CSeq: 4 11633 Server: PhonyServer/1.0 11634 Date: 23 Jan 1997 15:35:14 GMT 11635 Session: 12345678 11636 Range: npt=30-623.10 11637 Seek-Style: First-Prior 11638 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" 11639 ssrc=4F312DD8:seq=54321;rtptime=2876889 11641 C.3. Handling Media Clock Time Jumps in the RTP Media Layer 11643 RTSP allows media clients to control selected, non-contiguous 11644 sections of media presentations, rendering those streams with an RTP 11645 media layer [RFC3550]. Two cases occur, the first is when a new PLAY 11646 request replaces an old ongoing request and the new request results 11647 in a jump in the media. This should produce in the RTP layer a 11648 continuous media stream. A client may also directly following a 11649 completed PLAY request perform a new PLAY request. This will result 11650 in some gap in the media layer. The below text will look into both 11651 cases. 11653 A PLAY request that replaces an ongoing request allows the media 11654 layer rendering the RTP stream without being affected by jumps in 11655 media clock time. The RTP timestamps for the new media range is set 11656 so that they become continuous with the previous media range in the 11657 previous request. The RTP sequence number for the first packet in 11658 the new range will be the next following the last packet in the 11659 previous range, i.e. monotonically increasing. The goal is to allow 11660 the media rendering layer to work without interruption or 11661 reconfiguration across the jumps in media clock. This should be 11662 possible in all cases of replaced PLAY requests for media that has 11663 random-access properties. In this case care is needed to align 11664 frames or similar media dependent structures. 11666 In cases where jumps in media clock time are a result of RTSP 11667 signaling operations arriving after a completed PLAY operation, the 11668 request timing will result in that media becomes non-continuous. The 11669 server becomes unable to send the media so that it arrives timely and 11670 still carry timestamps to make the media stream continuous. In these 11671 cases the server will produce RTP streams where there are gaps in the 11672 RTP timeline for the media. In such cases, if the media has frame 11673 structure, aligning the timestamp for the next frame with the 11674 previous structure reduces the burden to render this media. The gap 11675 should represent the time the server hasn't been serving media, e.g. 11676 the time between the end of the media stream or a PAUSE request and 11677 the new PLAY request. In these cases the RTP sequence number would 11678 normally be monotonically increasing across the gap. 11680 For RTSP sessions with media that lacks random access properties, 11681 such as live streams, any media clock jump is commonly the result of 11682 a correspondingly long pause of delivery. The RTP timestamp will 11683 have increased in direct proportion to the duration of the paused 11684 delivery. Note also that in this case the RTP sequence number should 11685 be the next packet number. If not, the RTCP packet loss reporting 11686 will indicate as loss all packets not received between the point of 11687 pausing and later resuming. This may trigger congestion avoidance 11688 mechanisms. An allowed exception from the above recommendation on 11689 monotonically increasing RTP sequence number is live media streams, 11690 likely being relayed. In this case, when the client resumes 11691 delivery, it will get the media that is currently being delivered to 11692 the server itself. For this type of basic delivery of live streams 11693 to multiple users over unicast, individual rewriting of RTP sequence 11694 numbers becomes quite a burden. For solutions that anyway caches 11695 media, timeshifts, etc, the rewriting should be a minor issue. 11697 The goal when handling jumps in media clock time is that the provided 11698 stream is continuous without gaps in RTP timestamp or sequence 11699 number. However, when delivery has been halted for some reason the 11700 RTP timestamp when resuming MUST represent the duration the delivery 11701 was halted. RTP sequence number MUST generally be the next number, 11702 i.e. monotonically increasing modulo 65536. For media resources with 11703 the properties Time-Progressing and Time-Duration=0.0 the server MAY 11704 create RTP media streams with RTP sequence number jumps in them due 11705 to the client first halting delivery and later resuming it (PAUSE and 11706 then later PLAY). However, servers utilizing this exception must 11707 take into consideration the resulting RTCP receiver reports that 11708 likely contains loss reports for all the packets part of the 11709 discontinuity. A client cannot rely on that a server will align when 11710 resuming playing even if it is RECOMMENDED. The RTP-Info header will 11711 provide information on how the server acts in each case. 11713 We cannot assume that the RTSP client can communicate with the RTP 11714 media agent, as the two may be independent processes. If the RTP 11715 timestamp shows the same gap as the NPT, the media agent will 11716 assume that there is a pause in the presentation. If the jump in 11717 NPT is large enough, the RTP timestamp may roll over and the media 11718 agent may believe later packets to be duplicates of packets just 11719 played out. Having the RTP timestamp jump will also affect the 11720 RTCP measurements based on this. 11722 As an example, assume an RTP timestamp frequency of 8000 Hz, a 11723 packetization interval of 100 ms and an initial sequence number and 11724 timestamp of zero. 11726 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 11727 CSeq: 4 11728 Session: abcdefgh 11729 Range: npt=10-15 11730 User-Agent: PhonyClient/1.2 11732 S->C: RTSP/2.0 200 OK 11733 CSeq: 4 11734 Session: abcdefgh 11735 Range: npt=10-15 11736 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 11737 ssrc=0D12F123:seq=0;rtptime=0 11739 The ensuing RTP data stream is depicted below: 11741 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 11742 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 11743 . . . 11744 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 11746 Upon the completion of the requested delivery the server sends a 11747 PLAY_NOTIFY 11748 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 11749 CSeq: 5 11750 Notify-Reason: end-of-stream 11751 Request-Status: cseq=4 status=200 reason="OK" 11752 Range: npt=-15 11753 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 11754 ssrc=0D12F123:seq=49;rtptime=39200 11755 Session: abcdefgh 11757 C->S: RTSP/2.0 200 OK 11758 CSeq: 5 11759 User-Agent: PhonyClient/1.2 11761 Upon the completion of the play range, the client follows up with a 11762 request to PLAY from a new NPT. 11764 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 11765 CSeq: 6 11766 Session: abcdefg 11767 Range: npt=18-20 11768 User-Agent: PhonyClient/1.2 11770 S->C: RTSP/2.0 200 OK 11771 CSeq: 6 11772 Session: abcdefg 11773 Range: npt=18-20 11774 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 11775 ssrc=0D12F123:seq=50;rtptime=40100 11777 The ensuing RTP data stream is depicted below: 11779 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 11780 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 11781 . . . 11782 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 11784 In this example, first, NPT 10 through 15 is played, then the client 11785 requests the server to skip ahead and play NPT 18 through 20. The 11786 first segment is presented as RTP packets with sequence numbers 0 11787 through 49 and timestamp 0 through 39,200. The second segment 11788 consists of RTP packets with sequence number 50 through 69, with 11789 timestamps 40,100 through 55,200. While there is a gap in the NPT, 11790 there is no gap in the sequence number space of the RTP data stream. 11792 The RTP timestamp gap is present in the above example due to the time 11793 it takes to perform the second play request, in this case 12.5 ms 11794 (100/8000). 11796 C.4. Handling RTP Timestamps after PAUSE 11798 During a PAUSE / PLAY interaction in an RTSP session, the duration of 11799 time for which the RTP transmission was halted MUST be reflected in 11800 the RTP timestamp of each RTP stream. The duration can be calculated 11801 for each RTP stream as the time elapsed from when the last RTP packet 11802 was sent before the PAUSE request was received and when the first RTP 11803 packet was sent after the subsequent PLAY request was received. The 11804 duration includes all latency incurred and processing time required 11805 to complete the request. 11807 The RTP RFC [RFC3550] states that: The RTP timestamp for each unit 11808 [packet] would be related to the wallclock time at which the unit 11809 becomes current on the virtual presentation timeline. 11811 In order to satisfy the requirements of [RFC3550], the RTP 11812 timestamp space needs to increase continuously with real time. 11813 While this is not optimal for stored media, it is required for RTP 11814 and RTCP to function as intended. Using a continuous RTP 11815 timestamp space allows the same timestamp model for both stored 11816 and live media and allows better opportunity to integrate both 11817 types of media under a single control. 11819 As an example, assume a clock frequency of 8000 Hz, a packetization 11820 interval of 100 ms and an initial sequence number and timestamp of 11821 zero. 11823 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 11824 CSeq: 4 11825 Session: abcdefg 11826 Range: npt=10-15 11827 User-Agent: PhonyClient/1.2 11829 S->C: RTSP/2.0 200 OK 11830 CSeq: 4 11831 Session: abcdefg 11832 Range: npt=10-15 11833 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 11834 ssrc=0D12F123:seq=0;rtptime=0 11836 The ensuing RTP data stream is depicted below: 11838 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 11839 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 11840 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 11841 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 11843 The client then sends a PAUSE request: 11845 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 11846 CSeq: 5 11847 Session: abcdefg 11848 User-Agent: PhonyClient/1.2 11850 S->C: RTSP/2.0 200 OK 11851 CSeq: 5 11852 Session: abcdefg 11853 Range: npt=10.4-15 11855 20 seconds elapse and then the client sends a PLAY request. In 11856 addition the server requires 15 ms to process the request: 11858 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 11859 CSeq: 6 11860 Session: abcdefg 11861 User-Agent: PhonyClient/1.2 11863 S->C: RTSP/2.0 200 OK 11864 CSeq: 6 11865 Session: abcdefg 11866 Range: npt=10.4-15 11867 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 11868 ssrc=0D12F123:seq=4;rtptime=164400 11870 The ensuing RTP data stream is depicted below: 11872 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 11873 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 11874 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 11876 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 11877 server. After 20 seconds a PLAY is received by the server which 11878 takes 15ms to process. The duration of time for which the session 11879 was paused is reflected in the RTP timestamp of the RTP packets sent 11880 after this PLAY request. 11882 A client can use the RTSP range header and RTP-Info header to map NPT 11883 time of a presentation with the RTP timestamp. 11885 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 11886 was misunderstood commonly. However, for RTSP 2.0 it is expected 11887 that this will be handled correctly and no exception handling will be 11888 required. 11890 Note further: It may be required to reset some of the state to ensure 11891 the correct media decoding and the usual jitter-buffer handling when 11892 issuing a PLAY request. 11894 C.5. RTSP / RTP Integration 11896 For certain datatypes, tight integration between the RTSP layer and 11897 the RTP layer will be necessary. This by no means precludes the 11898 above restrictions. Combined RTSP/RTP media clients should use the 11899 RTP-Info field to determine whether incoming RTP packets were sent 11900 before or after a seek or before or after a PAUSE. 11902 C.6. Scaling with RTP 11904 For scaling (see Section 18.44), RTP timestamps should correspond to 11905 the rendering timing. For example, when playing video recorded at 30 11906 frames/second at a scale of two and speed (Section 18.48) of one, the 11907 server would drop every second frame to maintain and deliver video 11908 packets with the normal timestamp spacing of 3,000 per frame, but NPT 11909 would increase by 1/15 second for each video frame. 11911 Note: The above scaling puts requirements on the media codec or a 11912 media stream to support it. For example motion JPEG or other non- 11913 predictive video coding can easier handle the above example. 11915 C.7. Maintaining NPT synchronization with RTP timestamps 11917 The client can maintain a correct display of NPT (Normal Play Time) 11918 by noting the RTP timestamp value of the first packet arriving after 11919 repositioning. The sequence parameter of the RTP-Info 11920 (Section 18.43) header provides the first sequence number of the next 11921 segment. 11923 C.8. Continuous Audio 11925 For continuous audio, the server SHOULD set the RTP marker bit at the 11926 beginning of serving a new PLAY request or at jumps in timeline. 11927 This allows the client to perform playout delay adaptation. 11929 C.9. Multiple Sources in an RTP Session 11931 Note that more than one SSRC MAY be sent in the media stream. If it 11932 happens all sources are expected to be rendered simultaneously. 11934 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 11936 The RTCP BYE message indicates the end of use of a given SSRC. If 11937 all sources leave an RTP session, it can, in most cases, be assumed 11938 to have ended. Therefore, a client or server MUST NOT send an RTCP 11939 BYE message until it has finished using a SSRC. A server SHOULD keep 11940 using a SSRC until the RTP session is terminated. Prolonging the use 11941 of a SSRC allows the established synchronization context associated 11942 with that SSRC to be used to synchronize subsequent PLAY requests 11943 even if the PLAY response is late. 11945 An SSRC collision with the SSRC that transmits media does also have 11946 consequences, as it will normally force the media sender to change 11947 its SSRC in accordance with the RTP specification [RFC3550]. 11948 However, an RTSP server may wait and see if the client changes and 11949 thus resolve the conflict to minimize the impact. As media sender 11950 SSRC change will result in a loss of synchronization context, and 11951 require any receiver to wait for RTCP sender reports for all media 11952 requiring synchronization before being able to play out synchronized. 11953 Due to these reasons a client joining a session should take care to 11954 not select the same SSRC(s) as the server indicates in the ssrc 11955 Transport header parameter. Any SSRC signalled in the Transport 11956 header MUST be avoided. A client detecting a collision prior to 11957 sending any RTP or RTCP messages SHALL also select a new SSRC. 11959 C.11. Future Additions 11961 It is the intention that any future protocol or profile regarding 11962 media delivery and lower transport should be easy to add to RTSP. 11963 This section provides the necessary steps that needs to be meet. 11965 The following things needs to be considered when adding a new 11966 protocol or profile for use with RTSP: 11968 o The protocol or profile needs to define a name tag representing 11969 it. This tag is required to be an ABNF "token" to be possible to 11970 use in the Transport header specification. 11972 o The useful combinations of protocol, profiles and lower layer 11973 transport for this extension needs to be defined. For each 11974 combination declare the necessary parameters to use in the 11975 Transport header. 11977 o For new media protocols the interaction with RTSP needs to be 11978 addressed. One important factor will be the media 11979 synchronization. May need new headers similar to RTP info to 11980 carry information. 11982 o Discuss congestion control for media, especially if transport 11983 without built in congestion control is used. 11985 See the IANA section (Section 22) for information how to register new 11986 attributes. 11988 Appendix D. Use of SDP for RTSP Session Descriptions 11990 The Session Description Protocol (SDP, [RFC4566]) may be used to 11991 describe streams or presentations in RTSP. This description is 11992 typically returned in reply to a DESCRIBE request on an URI from a 11993 server to a client, or received via HTTP from a server to a client. 11995 This appendix describes how an SDP file determines the operation of 11996 an RTSP session. SDP as is provides no mechanism by which a client 11997 can distinguish, without human guidance, between several media 11998 streams to be rendered simultaneously and a set of alternatives 11999 (e.g., two audio streams spoken in different languages). The SDP 12000 extension "Grouping of Media Lines in the Session Description 12001 Protocol (SDP)" [RFC5888] provides such functionality to some degree. 12002 Appendix D.4 describes the usage of SDP media line grouping for RTSP. 12004 D.1. Definitions 12006 The terms "session-level", "media-level" and other key/attribute 12007 names and values used in this appendix are to be used as defined in 12008 SDP[RFC4566]: 12010 D.1.1. Control URI 12012 The "a=control:" attribute is used to convey the control URI. This 12013 attribute is used both for the session and media descriptions. If 12014 used for individual media, it indicates the URI to be used for 12015 controlling that particular media stream. If found at the session 12016 level, the attribute indicates the URI for aggregate control 12017 (presentation URI). The session level URI MUST be different from any 12018 media level URI. The presence of a session level control attribute 12019 MUST be interpreted as support for aggregated control. The control 12020 attribute MUST be present on media level unless the presentation only 12021 contains a single media stream, in which case the attribute MAY only 12022 be present on the session level and then also apply to that single 12023 media level. 12025 ABNF for the attribute is defined in Section 20.3. 12027 Example: 12028 a=control:rtsp://example.com/foo 12030 This attribute MAY contain either relative or absolute URIs, 12031 following the rules and conventions set out in RFC 3986 [RFC3986]. 12032 Implementations MUST look for a base URI in the following order: 12034 1. the RTSP Content-Base field; 12035 2. the RTSP Content-Location field; 12037 3. the RTSP Request-URI. 12039 If this attribute contains only an asterisk (*), then the URI MUST be 12040 treated as if it were an empty embedded URI, and thus inherit the 12041 entire base URI. 12043 Note, RFC 2326 was very unclear on the processing of relative URI 12044 and several RTSP 1.0 implementations at the point of publishing 12045 this document did not perform RFC 3986 processing to determine the 12046 resulting URI, instead simple concatenation is common. To avoid 12047 this issue completely it is recommended to use absolute URI in the 12048 SDP. 12050 The URI handling for SDPs from container files need special 12051 consideration. For example lets assume that a container file has the 12052 URI: "rtsp://example.com/container.mp4". Lets further assume this 12053 URI is the base URI, and that there is an absolute media level URI: 12054 "rtsp://example.com/container.mp4/trackID=2". A relative media level 12055 URI that resolves in accordance with RFC 3986 [RFC3986] to the above 12056 given media URI is: "container.mp4/trackID=2". It is usually not 12057 desirable to need to include in or modify the SDP stored within the 12058 container file with the server local name of the container file. To 12059 avoid this, one can modify the base URI used to include a trailing 12060 slash, e.g. "rtsp://example.com/container.mp4/". In this case the 12061 relative URI for the media will only need to be: "trackID=2". 12062 However, this will also mean that using "*" in the SDP will result in 12063 control URI including the trailing slash, i.e. 12064 "rtsp://example.com/container.mp4/". 12066 Note: The usage of TrackID in the above is not a standardized 12067 form, but one example out of several similar strings such as 12068 TrackID, Track_ID, StreamID that is used by different server 12069 vendors to indicate a particular piece of media inside a container 12070 file. 12072 D.1.2. Media Streams 12074 The "m=" field is used to enumerate the streams. It is expected that 12075 all the specified streams will be rendered with appropriate 12076 synchronization. If the session is over multicast, the port number 12077 indicated SHOULD be used for reception. The client MAY try to 12078 override the destination port, through the Transport header. The 12079 servers MAY allow this, the response will indicate if allowed or not. 12080 If the session is unicast, the port numbers are the ones RECOMMENDED 12081 by the server to the client, about which receiver ports to use; the 12082 client MUST still include its receiver ports in its SETUP request. 12084 The client MAY ignore this recommendation. If the server has no 12085 preference, it SHOULD set the port number value to zero. 12087 The "m=" lines contain information about which transport protocol, 12088 profile, and possibly lower-layer is to be used for the media stream. 12089 The combination of transport, profile and lower layer, like RTP/AVP/ 12090 UDP needs to be defined for how to be used with RTSP. The currently 12091 defined combinations are defined in Appendix C, further combinations 12092 MAY be specified. 12094 Example: 12095 m=audio 0 RTP/AVP 31 12097 D.1.3. Payload Type(s) 12099 The payload type(s) are specified in the "m=" line. In case the 12100 payload type is a static payload type from RFC 3551 [RFC3551], no 12101 other information may be required. In case it is a dynamic payload 12102 type, the media attribute "rtpmap" is used to specify what the media 12103 is. The "encoding name" within the "rtpmap" attribute may be one of 12104 those specified in RFC 3551 (Sections 5 and 6), or media type 12105 registered with IANA [RFC4288], or an experimental encoding as 12106 specified in SDP (RFC 4566 [RFC4566]). Codec-specific parameters are 12107 not specified in this field, but rather in the "fmtp" attribute 12108 described below. 12110 The selection of the RTP payload type numbers used may be required to 12111 consider RTP and RTCP Multiplexing [RFC5761] if that is to be 12112 supported by the server. 12114 D.1.4. Format-Specific Parameters 12116 Format-specific parameters are conveyed using the "fmtp" media 12117 attribute. The syntax of the "fmtp" attribute is specific to the 12118 encoding(s) that the attribute refers to. Note that some of the 12119 format specific parameters may be specified outside of the fmtp 12120 parameters, like for example the "ptime" attribute for most audio 12121 encodings. 12123 D.1.5. Directionality of media stream 12125 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 12126 provide instructions about the direction the media streams flow 12127 within a session. When using RTSP the SDP can be delivered to a 12128 client using either RTSP DESCRIBE or a number of RTSP external 12129 methods, like HTTP, FTP, and email. Based on this the SDP applies to 12130 how the RTSP client will see the complete session. Thus media 12131 streams delivered from the RTSP server to the client, would be given 12132 the "a=recvonly" attribute. 12134 The direction attributes are not commonly used in SDPs for RTSP, but 12135 may occur. "a=recvonly" in a SDP provided to the RTSP client MUST 12136 indicate that media delivery will only occur in the direction from 12137 the RTSP server to the client. In SDP provided to the RTSP client 12138 that lacks any of the directionality attributes (a=recvonly, 12139 a=sendonly, a=sendrecv) MUST behave as if the "a=recvonly" attribute 12140 was received. Note that this overrules the normal default rule 12141 defined in SDP[RFC4566]. The usage of "a=sendonly" or "a=sendrecv" 12142 is not defined, nor is the interpretation of SDP by other entities 12143 than the RTSP client. 12145 D.1.6. Range of Presentation 12147 The "a=range" attribute defines the total time range of the stored 12148 session or an individual media. Non-seekable live sessions can be 12149 indicated as specified below, while the length of live sessions can 12150 be deduced from the "t" and "r" SDP parameters. 12152 The attribute is both a session and a media level attribute. For 12153 presentations that contain media streams of the same durations, the 12154 range attribute SHOULD only be used at session-level. In case of 12155 different length the range attribute MUST be given at media level for 12156 all media, and SHOULD NOT be given at session level. If the 12157 attribute is present at both media level and session level the media 12158 level values MUST be used. 12160 Note: Usually one will specify the same length for all media, even if 12161 there isn't media available for the full duration on all media. 12162 However, that requires that the server accepts PLAY requests within 12163 that range. 12165 Servers MUST take care to provide RTSP Range (see Section 18.38) 12166 values that are consistent with what is presented in the SDP for the 12167 content. There is no reason for non dynamic content, like media 12168 clips provided on demand to have inconsistent values. Inconsistent 12169 values between the SDP and the actual values for the content handled 12170 by the server is likely to generate some failure, like 457 "Invalid 12171 Range", in case the client uses PLAY requests with a Range header. 12172 In case the content is dynamic in length and it is infeasible to 12173 provide a correct value in the SDP the server is recommended to 12174 describe this as non-seekable content (see below). The server MAY 12175 override that property in the response to a PLAY request using the 12176 correct values in the Range header. 12178 The unit is specified first, followed by the value range. The units 12179 and their values are as defined in Section 4.4, Section 4.5 and 12180 Section 4.6 and MAY be extended with further formats. Any open ended 12181 range (start-), i.e. without stop range, is of unspecified duration 12182 and MUST be considered as non-seekable content unless this property 12183 is overridden. Multiple instances carrying different clock formats 12184 MAY be included at either session or media level. 12186 ABNF for the attribute is defined in Section 20.3. 12188 Examples: 12189 a=range:npt=0-34.4368 12190 a=range:clock=19971113T211503Z-19971113T220300Z 12191 Non seekable stream of unknown duration: 12192 a=range:npt=0- 12194 D.1.7. Time of Availability 12196 The "t=" field defines when the SDP is valid. For on-demand content 12197 the server SHOULD indicate a stop time value for which it guarantees 12198 the description to be valid, and a start time that is equal to or 12199 before the time at which the DESCRIBE request was received. It MAY 12200 also indicate start and stop times of 0, meaning that the session is 12201 always available. 12203 For sessions that are of live type, i.e. specific start time, unknown 12204 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used 12205 to indicate the start time of the event. The stop time SHOULD be 12206 given so that the live event will have ended at that time, while 12207 still not be unnecessary long into the future. 12209 D.1.8. Connection Information 12211 In SDP used with RTSP, the "c=" field contains the destination 12212 address for the media stream. If a multicast address is specified 12213 the client SHOULD use this address in any SETUP request as 12214 destination address, including any additional parameters, such as 12215 TTL. For on-demand unicast streams and some multicast streams, the 12216 destination address MAY be specified by the client via the SETUP 12217 request, thus overriding any specified address. To identify streams 12218 without a fixed destination address, where the client is required to 12219 specify a destination address, the "c=" field SHOULD be set to a null 12220 value. For addresses of type "IP4", this value MUST be "0.0.0.0", 12221 and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be 12222 written as "::"), i.e. the unspecified address according to RFC 4291 12223 [RFC4291]. 12225 D.1.9. Message Body Tag 12227 The optional "a=mtag" attribute identifies a version of the session 12228 description. It is opaque to the client. SETUP requests may include 12229 this identifier in the If-Match field (see Section 18.23) to only 12230 allow session establishment if this attribute value still corresponds 12231 to that of the current description. The attribute value is opaque 12232 and may contain any character allowed within SDP attribute values. 12234 ABNF for the attribute is defined in Section 20.3. 12236 Example: 12237 a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a" 12239 One could argue that the "o=" field provides identical 12240 functionality. However, it does so in a manner that would put 12241 constraints on servers that need to support multiple session 12242 description types other than SDP for the same piece of media 12243 content. 12245 D.2. Aggregate Control Not Available 12247 If a presentation does not support aggregate control no session level 12248 "a=control:" attribute is specified. For a SDP with multiple media 12249 sections specified, each section will have its own control URI 12250 specified via the "a=control:" attribute. 12252 Example: 12253 v=0 12254 o=- 2890844256 2890842807 IN IP4 192.0.2.56 12255 s=I came from a web page 12256 e=adm@example.com 12257 c=IN IP4 0.0.0.0 12258 t=0 0 12259 m=video 8002 RTP/AVP 31 12260 a=control:rtsp://audio.example.com/movie.aud 12261 m=audio 8004 RTP/AVP 3 12262 a=control:rtsp://video.example.com/movie.vid 12264 Note that the position of the control URI in the description implies 12265 that the client establishes separate RTSP control sessions to the 12266 servers audio.example.com and video.example.com. 12268 It is recommended that an SDP file contains the complete media 12269 initialization information even if it is delivered to the media 12270 client through non-RTSP means. This is necessary as there is no 12271 mechanism to indicate that the client should request more detailed 12272 media stream information via DESCRIBE. 12274 D.3. Aggregate Control Available 12276 In this scenario, the server has multiple streams that can be 12277 controlled as a whole. In this case, there are both a media-level 12278 "a=control:" attributes, which are used to specify the stream URIs, 12279 and a session-level "a=control:" attribute which is used as the 12280 Request-URI for aggregate control. If the media-level URI is 12281 relative, it is resolved to absolute URIs according to Appendix D.1.1 12282 above. 12284 Example: 12285 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 12286 CSeq: 1 12287 User-Agent: PhonyClient/1.2 12289 M->C: RTSP/2.0 200 OK 12290 CSeq: 1 12291 Date: Thu, 23 Jan 1997 15:35:06 GMT 12292 Expires: Thu, 23 Jan 1997 16:35:06 GMT 12293 Content-Type: application/sdp 12294 Content-Base: rtsp://example.com/movie/ 12295 Content-Length: 227 12297 v=0 12298 o=- 2890844256 2890842807 IN IP4 192.0.2.211 12299 s=I contain 12300 i= 12301 e=adm@example.com 12302 c=IN IP4 0.0.0.0 12303 a=control:* 12304 t=0 0 12305 m=video 8002 RTP/AVP 31 12306 a=control:trackID=1 12307 m=audio 8004 RTP/AVP 3 12308 a=control:trackID=2 12310 In this example, the client is recommended to establish a single RTSP 12311 session to the server, and uses the URIs 12312 rtsp://example.com/movie/trackID=1 and 12313 rtsp://example.com/movie/trackID=2 to set up the video and audio 12314 streams, respectively. The URI rtsp://example.com/movie/, which is 12315 resolved from the "*", controls the whole presentation (movie). 12317 A client is not required to issue SETUP requests for all streams 12318 within an aggregate object. Servers should allow the client to ask 12319 for only a subset of the streams. 12321 D.4. Grouping of Media Lines in SDP 12323 For some types of media it is desirable to express a relationship 12324 between various media components, for instance, for lip 12325 synchronization or Scalable Video Codec (SVC) [RFC5583]. This 12326 relationship is expressed on the SDP level by grouping of media 12327 lines, as described in [RFC5888] and can be exposed to RTSP. 12329 For RTSP it is mainly important to know how to handle grouped medias 12330 received by means of SDP, i.e., if the media are under aggregate 12331 control (see Appendix D.3) or if aggregate control is not available 12332 (see Appendix D.2). 12334 It is RECOMMENDED that grouped medias are handled by aggregate 12335 control, to give the client the ability to control either the whole 12336 presentation or single medias. 12338 D.5. RTSP external SDP delivery 12340 There are some considerations that need to be made when the session 12341 description is delivered to the client outside of RTSP, for example 12342 via HTTP or email. 12344 First of all, the SDP needs to contain absolute URIs, since relative 12345 will in most cases not work as the delivery will not correctly 12346 forward the base URI. 12348 The writing of the SDP session availability information, i.e. "t=" 12349 and "r=", needs to be carefully considered. When the SDP is fetched 12350 by the DESCRIBE method, the probability that it is valid is very 12351 high. However, the same is much less certain for SDPs distributed 12352 using other methods. Therefore the publisher of the SDP should take 12353 care to follow the recommendations about availability in the SDP 12354 specification [RFC4566] in Section 4.2. 12356 Appendix E. RTSP Use Cases 12358 This Appendix describes the most important and considered use cases 12359 for RTSP. They are listed in descending order of importance in 12360 regards to ensuring that all necessary functionality is present. 12361 This specification only fully supports usage of the two first. Also 12362 in these first two cases, there are special cases or exceptions that 12363 are not supported without extensions, e.g. the redirection of media 12364 delivery to another address than the controlling agent's (client's). 12366 E.1. On-demand Playback of Stored Content 12368 An RTSP capable server stores content suitable for being streamed to 12369 a client. A client desiring playback of any of the stored content 12370 uses RTSP to set up the media transport required to deliver the 12371 desired content. RTSP is then used to initiate, halt and manipulate 12372 the actual transmission (playout) of the content. RTSP is also 12373 required to provide necessary description and synchronization 12374 information for the content. 12376 The above high level description can be broken down into a number of 12377 functions that RTSP needs to be capable of. 12379 Presentation Description: Provide initialization information about 12380 the presentation (content); for example, which media codecs are 12381 needed for the content. Other information that is important 12382 includes the number of media streams the presentation contains, 12383 the transport protocols used for the media streams, and 12384 identifiers for these media streams. This information is 12385 required before setup of the content is possible and to 12386 determine if the client is even capable of using the content. 12388 This information need not be sent using RTSP; other external 12389 protocols can be used to transmit the transport presentation 12390 descriptions. Two good examples are the use of HTTP [RFC2616] 12391 or email to fetch or receive presentation descriptions like SDP 12392 [RFC4566] 12394 Setup: Set up some or all of the media streams in a presentation. 12395 The setup itself consists of selecting the protocol for media 12396 transport and the necessary parameters for the protocol, like 12397 addresses and ports. 12399 Control of Transmission: After the necessary media streams have been 12400 established the client can request the server to start 12401 transmitting the content. The client must be allowed to start 12402 or stop the transmission of the content at arbitrary times. 12403 The client must also be able to start the transmission at any 12404 point in the timeline of the presentation. 12406 Synchronization: For media transport protocols like RTP [RFC3550] it 12407 might be beneficial to carry synchronization information within 12408 RTSP. This may be due to either the lack of inter-media 12409 synchronization within the protocol itself, or the potential 12410 delay before the synchronization is established (which is the 12411 case for RTP when using RTCP). 12413 Termination: Terminate the established contexts. 12415 For this use case there are a number of assumptions about how it 12416 works. These are: 12418 On-Demand content: The content is stored at the server and can be 12419 accessed at any time during a time period when it is intended 12420 to be available. 12422 Independent sessions: A server is capable of serving a number of 12423 clients simultaneously, including from the same piece of 12424 content at different points in that presentations time-line. 12426 Unicast Transport: Content for each individual client is transmitted 12427 to them using unicast traffic. 12429 It is also possible to redirect the media traffic to a different 12430 destination than that of the agent controlling the traffic. However, 12431 allowing this without appropriate mechanisms for checking that the 12432 destination approves of this allows for distributed denial of service 12433 attacks (DDoS). 12435 E.2. Unicast Distribution of Live Content 12437 This use case is similar to the above on-demand content case (see 12438 Appendix E.1) the difference is the nature of the content itself. 12439 Live content is continuously distributed as it becomes available from 12440 a source; i.e., the main difference from on-demand is that one starts 12441 distributing content before the end of it has become available to the 12442 server. 12444 In many cases the consumer of live content is only interested in 12445 consuming what actually happens "now"; i.e., very similar to 12446 broadcast TV. However, in this case it is assumed that there exist 12447 no broadcast or multicast channel to the users, and instead the 12448 server functions as a distribution node, sending the same content to 12449 multiple receivers, using unicast traffic between server and client. 12450 This unicast traffic and the transport parameters are individually 12451 negotiated for each receiving client. 12453 Another aspect of live content is that it often has a very limited 12454 time of availability, as it is only available for the duration of the 12455 event the content covers. An example of such a live content could be 12456 a music concert which lasts 2 hour and starts at a predetermined 12457 time. Thus there is a need to announce when and for how long the 12458 live content is available. 12460 In some cases, the server providing live content may be saving some 12461 or all of the content to allow clients to pause the stream and resume 12462 it from the paused point, or to "rewind" and play continuously from a 12463 point earlier than the live point. Hence, this use case does not 12464 necessarily exclude playing from other than the live point of the 12465 stream, playing with scales other than 1.0, etc. 12467 E.3. On-demand Playback using Multicast 12469 It is possible to use RTSP to request that media be delivered to a 12470 multicast group. The entity setting up the session (the controller) 12471 will then control when and what media is delivered to the group. 12472 This use case has some potential for denial of service attacks by 12473 flooding a multicast group. Therefore, a mechanism is needed to 12474 indicate that the group actually accepts the traffic from the RTSP 12475 server. 12477 An open issue in this use case is how one ensures that all receivers 12478 listening to the multicast or broadcast receives the session 12479 presentation configuring the receivers. This specification has to 12480 rely on an external solution to solve this issue. 12482 E.4. Inviting an RTSP server into a conference 12484 If one has an established conference or group session, it is possible 12485 to have an RTSP server distribute media to the whole group. 12486 Transmission to the group is simplest when controlled by a single 12487 participant or leader of the conference. Shared control might be 12488 possible, but would require further investigation and possibly 12489 extensions. 12491 This use case assumes that there exists either multicast or a 12492 conference focus that redistribute media to all participants. 12494 This use case is intended to be able to handle the following 12495 scenario: A conference leader or participant (hereafter called the 12496 controller) has some pre-stored content on an RTSP server that he 12497 wants to share with the group. The controller sets up an RTSP 12498 session at the streaming server for this content and retrieves the 12499 session description for the content. The destination for the media 12500 content is set to the shared multicast group or conference focus. 12502 When desired by the controller, he/she can start and stop the 12503 transmission of the media to the conference group. 12505 There are several issues with this use case that are not solved by 12506 this core specification for RTSP: 12508 Denial of service: To avoid an RTSP server from being an unknowing 12509 participant in a denial of service attack the server needs to 12510 be able to verify the destination's acceptance of the media. 12511 Such a mechanism to verify the approval of received media does 12512 not yet exist; instead, only policies can be used, which can be 12513 made to work in controlled environments. 12515 Distributing the presentation description to all participants in the 12516 group: To enable a media receiver to correctly decode the content 12517 the media configuration information needs to be distributed 12518 reliably to all participants. This will most likely require 12519 support from an external protocol. 12521 Passing control of the session: If it is desired to pass control of 12522 the RTSP session between the participants, some support will be 12523 required by an external protocol to exchange state information 12524 and possibly floor control of who is controlling the RTSP 12525 session. 12527 E.5. Live Content using Multicast 12529 This use case in its simplest form does not require any use of RTSP 12530 at all; this is what multicast conferences being announced with SAP 12531 [RFC2974] and SDP are intended to handle. However, in use cases 12532 where more advanced features like access control to the multicast 12533 session are desired, RTSP could be used for session establishment. 12535 A client desiring to join a live multicasted media session with 12536 cryptographic (encryption) access control could use RTSP in the 12537 following way. The source of the session announces the session and 12538 gives all interested an RTSP URI. The client connects to the server 12539 and requests the presentation description, allowing configuration for 12540 reception of the media. In this step it is possible for the client 12541 to use secured transport and any desired level of authentication; for 12542 example, for billing or access control. An RTSP link also allows for 12543 load balancing between multiple servers. 12545 If these were the only goals, they could be achieved by simply using 12546 HTTP. However, for cases where the sender likes to keep track of 12547 each individual receiver of a session, and possibly use the session 12548 as a side channel for distributing key-updates or other information 12549 on a per-receiver basis, and the full set of receivers is not known 12550 prior to the session start, the state establishment that RTSP 12551 provides can be beneficial. In this case a client would establish an 12552 RTSP session for this multicast group with the RTSP server. The RTSP 12553 server will not transmit any media, but instead will point to the 12554 multicast group. The client and server will be able to keep the 12555 session alive for as long as the receiver participates in the session 12556 thus enabling, for example, the server to push updates to the client. 12558 This use case will most likely not be able to be implemented without 12559 some extensions to the server-to-client push mechanism. Here the 12560 PLAY_NOTIFY method (see Section 13.5) with a suitable extension could 12561 provide clear benefits. 12563 Appendix F. Text format for Parameters 12565 A resource of type "text/parameters" consists of either 1) a list of 12566 parameters (for a query) or 2) a list of parameters and associated 12567 values (for an response or setting of the parameter). Each entry of 12568 the list is a single line of text. Parameters are separated from 12569 values by a colon. The parameter name MUST only use US-ASCII visible 12570 characters while the values are UTF-8 text strings. The media type 12571 registration form is in Section 22.16. 12573 There is a potential interoperability issue for this format. It was 12574 named in RFC 2326 but never defined, even if used in examples that 12575 hint at the syntax. This format matches the purpose and its syntax 12576 supports the examples provided. However, it goes further by allowing 12577 UTF-8 in the value part, thus usage of UTF-8 strings may not be 12578 supported. However, as individual parameters are not defined, the 12579 using application anyway needs to have out-of-band agreement or using 12580 feature-tag to determine if the end-point supports the parameters. 12582 The ABNF [RFC5234] grammar for "text/parameters" content is: 12584 file = *((parameter / parameter-value) CRLF) 12585 parameter = 1*visible-except-colon 12586 parameter-value = parameter *WSP ":" value 12587 visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" 12588 value = *(TEXT-UTF8char / WSP) 12589 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 12590 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 12591 / %xE0-EF 2UTF8-CONT 12592 / %xF0-F7 3UTF8-CONT 12593 / %xF8-FB 4UTF8-CONT 12594 / %xFC-FD 5UTF8-CONT 12595 UTF8-CONT = %x80-BF 12596 WSP = ; Space or HTAB 12597 VCHAR = 12598 CRLF = 12600 Appendix G. Requirements for Unreliable Transport of RTSP 12602 This section provides anyone intending to define how to transport of 12603 RTSP messages over a unreliable transport protocol with some 12604 information learned by the attempt in RFC 2326 [RFC2326]. RFC 2326 12605 defined both an URI scheme and some basic functionality for transport 12606 of RTSP messages over UDP, however, it was not sufficient for 12607 reliable usage and successful interoperability. 12609 The RTSP scheme defined for unreliable transport of RTSP messages was 12610 "rtspu". It has been reserved by this specification as at least one 12611 commercial implementation exists, thus avoiding any collisions in the 12612 name space. 12614 The following considerations should exist for operation of RTSP over 12615 an unreliable transport protocol: 12617 o Request shall be acknowledged by the receiver. If there is no 12618 acknowledgement, the sender may resend the same message after a 12619 timeout of one round-trip time (RTT). Any retransmissions due to 12620 lack of acknowledgement must carry the same sequence number as the 12621 original request. 12623 o The round-trip time can be estimated as in TCP (RFC 1123) 12624 [RFC1123], with an initial round-trip value of 500 ms. An 12625 implementation may cache the last RTT measurement as the initial 12626 value for future connections. 12628 o The Timestamp header (Section 18.51) is used to avoid the 12629 retransmission ambiguity problem [Stevens98]. 12631 o The registered default port for RTSP over UDP for the server is 12632 554. 12634 o RTSP messages can be carried over any lower-layer transport 12635 protocol that is 8-bit clean. 12637 o RTSP messages are vulnerable to bit errors and should not be 12638 subjected to them. 12640 o Source authentication, or at least validation that RTSP messages 12641 comes from the same entity becomes extremely important, as session 12642 hijacking may be substantially easier for RTSP message transport 12643 using an unreliable protocol like UDP than for TCP. 12645 There are two RTSP headers that are primarily intended for being used 12646 by the unreliable handling of RTSP messages and which will be 12647 maintained: 12649 o CSeq: See Section 18.19 12651 o Timestamp: See Section 18.51 12653 Appendix H. Backwards Compatibility Considerations 12655 This section contains notes on issues about backwards compatibility 12656 with clients or servers being implemented according to RFC 2326 12657 [RFC2326]. Note that there exists no requirement to implement RTSP 12658 1.0; in fact we recommend against it as it is difficult to do in an 12659 interoperable way. 12661 A server implementing RTSP/2.0 MUST include an RTSP-Version of 12662 RTSP/2.0 in all responses to requests containing RTSP-Version 12663 RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond 12664 with an RTSP/1.0 response if it chooses to support RFC 2326. If the 12665 server chooses not to support RFC 2326, it MUST respond with a 505 12666 (RTSP Version not supported) status code. A server MUST NOT respond 12667 to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 12668 response. 12670 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 12671 Version of 2.0 to determine whether a server supports RTSP/2.0. If 12672 the server responds with either an RTSP-Version of 1.0 or a status 12673 code of 505 (RTSP Version not supported), the client will have to use 12674 RTSP/1.0 requests if it chooses to support RFC 2326. 12676 H.1. Play Request in Play State 12678 The behavior in the server when a Play is received in Play state has 12679 changed (Section 13.4). In RFC 2326, the new PLAY request would be 12680 queued until the current Play completed. Any new PLAY request now 12681 takes effect immediately replacing the previous request. 12683 H.2. Using Persistent Connections 12685 Some server implementations of RFC 2326 maintain a one-to-one 12686 relationship between a connection and an RTSP session. Such 12687 implementations require clients to use a persistent connection to 12688 communicate with the server and when a client closes its connection, 12689 the server may remove the RTSP session. This is worth noting if a 12690 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 12692 Appendix I. Changes 12694 This appendix briefly lists the differences between RTSP 1.0 12695 [RFC2326] and RTSP 2.0 for an informational purpose. For 12696 implementers of RTSP 2.0 it is recommended to read carefully through 12697 this memo and not to rely on the list of changes below to adapt from 12698 RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards 12699 compatible with RTSP 1.0 [RFC2326] other than the version negotiation 12700 mechanism. 12702 I.1. Brief Overview 12704 The following protocol elements were removed in RTSP 2.0 compared to 12705 RTSP 1.0: 12707 o there is no section on minimal implementation anymore, but more 12708 the definition of RTSP 2.0 core; 12710 o the RECORD and ANNOUNCE methods and all related functionality 12711 (including 201 (Created) and 250 (Low On Storage Space) status 12712 codes); 12714 o the use of UDP for RTSP message transport was removed due to 12715 missing interest and to broken specification; 12717 o the use of PLAY method for keep-alive in Play state. 12719 The following protocol elements were added or changed in RTSP 2.0 12720 compared to RTSP 1.0: 12722 o RTSP session TEARDOWN from the server to the client; 12724 o IPv6 support; 12726 o extended IANA registries (e.g., transport headers parameters, 12727 transport-protocol, profile, lower-transport, and mode); 12729 o request pipelining for quick session start-up; 12731 o fully reworked state-machine; 12733 o RTSP messages now use URIs rather then URLs; 12735 o incorporated much of related HTTP text ([RFC2616]) in this memo, 12736 compared to just referencing the sections in HTTP, to avoid 12737 ambiguities; 12739 o the REDIRECT method was expanded and diversified for different 12740 situations; 12742 o Includes a new section about how to setup different media 12743 transport alternatives and their profiles, and lower layer 12744 protocols. This caused the appendix on RTP interaction to be 12745 moved there instead of being in the part which describes RTP. The 12746 section also includes guidelines what to consider when writing 12747 usage guidelines for new protocols and profiles; 12749 o Added an asynchronous notification method PLAY_NOTIFY. This 12750 method is used by the RTSP server to asynchronously notify clients 12751 about session changes while in Play state. To a limited extent 12752 this is comparable with some implementations of ANNOUNCE in RTSP 12753 1.0 not intended for Recording. 12755 I.2. Detailed List of Changes 12757 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 12758 defining RTSP 2.0. Note that this list does not reflect minor 12759 changes in wording or correction of typographical errors. 12761 o The section on minimal implementation was deleted without 12762 substitution. 12764 o The Transport header has been changed in the following way: 12766 * The ABNF has been changed to define that extensions are 12767 possible, and that unknown parameters result in that servers 12768 ignore the transport specification. 12770 * To prevent backwards compatibility issues, any extension or new 12771 parameter requires the usage of a feature-tag combined with the 12772 Require header. 12774 * Syntax unclarities with the Mode parameter has been resolved. 12776 * Syntax error with ";" for multicast and unicast has been 12777 resolved. 12779 * Two new addressing parameters has been defined, src_addr and 12780 dest_addr. These replaces the parameters "port", 12781 "client_port", "server_port", "destination", "source". 12783 * Support for IPv6 explicit addresses in all address fields has 12784 been included. 12786 * To handle URI definitions that contain ";" or "," a quoted URI 12787 format has been introduced and is required. 12789 * Defined IANA registries for the transport headers parameters, 12790 transport-protocol, profile, lower-transport, and mode. 12792 * The transport headers interleaved parameter's text was made 12793 more strict and uses formal requirements levels. It was also 12794 clarified that the interleaved channels are symmetric and that 12795 it is the server that sets the channel numbers. 12797 * It has been clarified that the client can't request of the 12798 server to use a certain RTP SSRC, using a request with the 12799 transport parameter SSRC. 12801 * Syntax definition for SSRC has been clarified to require 8HEX. 12802 It has also been extended to allow multiple values for clients 12803 supporting this version. 12805 * Clarified the text on the transport headers "dest_addr" 12806 parameters regarding what security precautions the server is 12807 required to perform. 12809 o The Range formats has been changed in the following way: 12811 * The NPT format has been given an initial NPT identifier that 12812 must now be used. 12814 * All formats now support initial open ended formats of type 12815 "npt=-10" and also format only "Range: smpte" ranges for usage 12816 with GET_PARAMETER requests. 12818 o RTSP message handling has been changed in the following way: 12820 * RTSP messages now use URIs rather then URLs. 12822 * It has been clarified that a 4xx message due to missing CSeq 12823 header shall be returned without a CSeq header. 12825 * The 300 (Multiple Choices) response code has been removed. 12827 * Rules for how to handle timing out RTSP messages has been 12828 added. 12830 * Extended Pipelining rules allowing for quick session startup. 12832 o The HTTP references have been updated to RFC 2616 and RFC 2617. 12833 Most of the text has been copied and then altered to fit RTSP into 12834 this specification. Public, and the Content-Base header has also 12835 been imported from RFC 2068 so that they are defined in the RTSP 12836 specification. Known effects on RTSP due to HTTP clarifications: 12838 * Content-Encoding header can include encoding of type 12839 "identity". 12841 o The state machine section has completely been rewritten. It 12842 includes now more details and is also more clear about the model 12843 used. 12845 o An IANA section has been included with contains a number of 12846 registries and their rules. This will allow us to use IANA to 12847 keep track of RTSP extensions. 12849 o The transport of RTSP messages has seen the following changes: 12851 * The use of UDP for RTSP message transport has been deprecated 12852 due to missing interest and to broken specification. 12854 * The rules for how TCP connections are to be handled has been 12855 clarified. Now it is made clear that servers should not close 12856 the TCP connection unless they have been unused for significant 12857 time. 12859 * Strong recommendations why server and clients should use 12860 persistent connections have also been added. 12862 * There is now a requirement on the servers to handle non- 12863 persistent connections as this provides fault tolerance. 12865 * Added wording on the usage of Connection:Close for RTSP. 12867 * specified usage of TLS for RTSP messages, including a scheme to 12868 approve a proxy's TLS connection to the next hop. 12870 o The following header related changes have been made: 12872 * Accept-Ranges response header is added. This header clarifies 12873 which range formats that can be used for a resource. 12875 * Fixed the missing definitions for the Cache-Control header. 12876 Also added to the syntax definition the missing delta-seconds 12877 for max-stale and min-fresh parameters. 12879 * Put requirement on CSeq header that the value is increased by 12880 one for each new RTSP request. A Recommendation to start at 0 12881 has also been added. 12883 * Added requirement that the Date header must be used for all 12884 messages with message body and the Server should always include 12885 it. 12887 * Removed possibility of using Range header with Scale header to 12888 indicate when it is to be activated, since it can't work as 12889 defined. Also added rule that lack of Scale header in response 12890 indicates lack of support for the header. Feature-tags for 12891 scaled playback has been defined. 12893 * The Speed header must now be responded to indicate support and 12894 the actual speed going to be used. A feature-tag is defined. 12895 Notes on congestion control were also added. 12897 * The Supported header was borrowed from SIP [RFC3261] to help 12898 with the feature negotiation in RTSP. 12900 * Clarified that the Timestamp header can be used to resolve 12901 retransmission ambiguities. 12903 * The Session header text has been expanded with an explanation 12904 on keep alive and which methods to use. SET_PARAMETER is now 12905 recommended to use if only keep-alive within RTSP is desired. 12907 * It has been clarified how the Range header formats are used to 12908 indicate pause points in the PAUSE response. 12910 * Clarified that RTP-Info URIs that are relative, use the 12911 Request-URI as base URI. Also clarified that the used URI must 12912 be the one that was used in the SETUP request. The URIs are 12913 now also required to be quoted. The header also expresses the 12914 SSRC for the provided RTP timestamp and sequence number values. 12916 * Added text that requires the Range to always be present in PLAY 12917 responses. Clarified what should be sent in case of live 12918 streams. 12920 * The headers table has been updated using a structure borrowed 12921 from SIP. Those tables carries much more information and 12922 should provide a good overview of the available headers. 12924 * It has been clarified that any message with a message body is 12925 required to have a Content-Length header. This was the case in 12926 RFC 2326, but could be misinterpreted. 12928 * ETag has changed name to MTag. 12930 * To resolve functionality around MTag. The MTag and If-None- 12931 Match header have been added from HTTP with necessary 12932 clarification in regards to RTSP operation. 12934 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 12935 it has been removed from HTTP due to lack of use. Public is 12936 used quite frequently in RTSP. 12938 * Clarified rules for populating the Public header so that it is 12939 an intersection of the capabilities of all the RTSP agents in a 12940 chain. 12942 * Added the Media-Range header for listing the current 12943 availability of the media range. 12945 * Added the Notify-Reason header for giving the reason when 12946 sending PLAY_NOTIFY requests. 12948 * A new header Seek-Style has been defined to direct and inform 12949 how any seek operation should/have been performed. 12951 o The Protocol Syntax has been changed in the following way: 12953 * All ABNF definitions are updated according to the rules defined 12954 in RFC 5234 [RFC5234] and have been gathered in a separate 12955 Section 20. 12957 * The ABNF for the User-Agent and Server headers have been 12958 corrected. 12960 * Some definitions in the introduction regarding the RTSP session 12961 have been changed. 12963 * The protocol has been made fully IPv6 capable. 12965 * Added a fragment part to the RTSP URI. This seemed to be 12966 indicated by the note below the definition, however, it was not 12967 part of the ABNF. 12969 * The CHAR rule has been changed to exclude NULL. 12971 o The Status codes have been changed in the following way: 12973 * The use of status code 303 "See Other" has been deprecated as 12974 it does not make sense to use in RTSP. 12976 * When sending response 451 and 458 the response body should 12977 contain the offending parameters. 12979 * Clarification on when a 3rr redirect status code can be 12980 received has been added. This includes receiving 3rr as a 12981 result of a request within a established session. This 12982 provides clarification to a previous unspecified behavior. 12984 * Removed the 201 (Created) and 250 (Low On Storage Space) status 12985 codes as they are only relevant to recording, which is 12986 deprecated. 12988 * Several new Status codes have been defined: 464 "Data Transport 12989 Not Ready Yet", 465 "Notification Reason Unknown", 470 12990 "Connection Authorization Required", 471 "Connection 12991 Credentials not accepted", 472 "Failure to establish secure 12992 connection". 12994 o The following functionality has been deprecated from the protocol: 12996 * The use of Queued Play. 12998 * The use of PLAY method for keep-alive in Play state. 13000 * The RECORD and ANNOUNCE methods and all related functionality. 13001 Some of the syntax has been removed. 13003 * The possibility to use timed execution of methods with the time 13004 parameter in the Range header. 13006 * The description on how rtspu works is not part of the core 13007 specification and will require external description. Only that 13008 it exist is defined here and some requirements for the 13009 transport is provided. 13011 o The following changes have been made in relation to methods: 13013 * The OPTIONS method has been clarified with regards to the use 13014 of the Public and Allow headers. 13016 * Added text clarifying the usage of SET_PARAMETER for keep-alive 13017 and usage without any body. 13019 * PLAY method is now allowed to be pipelined with the pipelining 13020 of one or more SETUP requests following the initial that 13021 generates the session for aggregated control. 13023 * REDIRECT has been expanded and diversified for different 13024 situations. 13026 * Added a new method PLAY_NOTIFY. This method is used by the 13027 RTSP server to asynchronously notify clients about session 13028 changes. 13030 o Wrote a new section about how to setup different media transport 13031 alternatives and their profiles, and lower layer protocols. This 13032 caused the appendix on RTP interaction to be moved there instead 13033 of being in the part which describes RTP. The section also 13034 includes guidelines what to consider when writing usage guidelines 13035 for new protocols and profiles. 13037 o Setup and usage of independent TCP connections for transport of 13038 RTP has been specified. 13040 o Added a new section describing the available mechanisms to 13041 determine if functionality is supported, called "Capability 13042 Handling". Renamed option-tags to feature-tags. 13044 o Added a contributors section with people who have contributed 13045 actual text to the specification. 13047 o Added a section Use Cases that describes the major use cases for 13048 RTSP. 13050 o Clarified the usage of a=range and how to indicate live content 13051 that are not seekable with this header. 13053 o Text specifying the special behavior of PLAY for live content. 13055 Appendix J. Acknowledgements 13057 This memorandum defines RTSP version 2.0 which is a revision of the 13058 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 13059 The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert 13060 Lanphier. 13062 Both RTSP version 1.0 and RTSP version 2.0 borrow format and 13063 descriptions from HTTP/1.1. 13065 This document has benefited greatly from the comments of all those 13066 participating in the MMUSIC-WG. In addition to those already 13067 mentioned, the following individuals have contributed to this 13068 specification: 13070 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 13071 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 13072 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 13073 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 13074 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, 13075 Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo 13076 F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria 13077 Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, 13078 Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior 13079 Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis 13080 Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan 13081 Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell, 13082 Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick 13083 Hoffman, Jinhang Choi, Ross Finlayson, and especially to Flemming 13084 Andreasen. 13086 J.1. Contributors 13088 The following people have made written contributions that were 13089 included in the specification: 13091 o Tom Marshall contributed text on the usage of 3rr status codes. 13093 o Thomas Zheng contributed text on the usage of the Range in PLAY 13094 responses and proposed an earlier version of the PLAY_NOTIFY 13095 method. 13097 o Sean Sheedy contributed text on the timeout behavior of RTSP 13098 messages and connections, the 463 status code, and proposed an 13099 earlier version of the PLAY_NOTIFY method. 13101 o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY 13102 method. 13104 o Fredrik Lindholm contributed text about the RTSP security 13105 framework. 13107 o John Lazzaro contributed the text for RTP over Independent TCP. 13109 o Aravind Narasimhan contributed by rewriting Media Transport 13110 Alternatives (Appendix C) and editorial improvements on a number 13111 of places in the specification. 13113 o Torbjorn Einarsson has done some editorial improvements of the 13114 text. 13116 Appendix K. RFC Editor Consideration 13118 Please replace RFC XXXX with the RFC number this specification 13119 receives. 13121 Authors' Addresses 13123 Henning Schulzrinne 13124 Columbia University 13125 1214 Amsterdam Avenue 13126 New York, NY 10027 13127 USA 13129 Email: schulzrinne@cs.columbia.edu 13131 Anup Rao 13132 Cisco 13133 USA 13135 Email: anrao@cisco.com 13137 Rob Lanphier 13138 Seattle, WA 13139 USA 13141 Email: robla@robla.net 13143 Magnus Westerlund 13144 Ericsson AB 13145 Faeroegatan 6 13146 STOCKHOLM, SE-164 80 13147 SWEDEN 13149 Email: magnus.westerlund@ericsson.com 13151 Martin Stiemerling 13152 NEC Laboratories Europe, NEC Europe Ltd. 13153 Kurfuersten-Anlage 36 13154 Heidelberg 69115 13155 Germany 13157 Phone: +49 (0) 6221 4342 113 13158 Email: martin.stiemerling@neclab.eu 13159 URI: http://ietf.stiemerling.org