idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-39.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 (January 17, 2014) is 3745 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 5038, but not defined == Missing Reference: 'H15' is mentioned on line 9507, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 10174, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-pub-180-2' == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-03 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-17 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Possible downref: Non-RFC (?) normative reference: ref. 'TS-26234' -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group H. Schulzrinne 3 Internet-Draft Columbia University 4 Obsoletes: 2326 (if approved) A. Rao 5 Intended status: Standards Track Cisco 6 Expires: July 21, 2014 R. Lanphier 8 M. Westerlund 9 Ericsson AB 10 M. Stiemerling (Ed.) 11 NEC 12 January 17, 2014 14 Real Time Streaming Protocol 2.0 (RTSP) 15 draft-ietf-mmusic-rfc2326bis-39 17 Abstract 19 This memorandum defines RTSP version 2.0 which obsoletes RTSP version 20 1.0 defined in RFC 2326. 22 The Real Time Streaming Protocol, or RTSP, is an application-layer 23 protocol for setup and control of the delivery of data with real-time 24 properties. RTSP provides an extensible framework to enable 25 controlled, on-demand delivery of real-time data, such as audio and 26 video. Sources of data can include both live data feeds and stored 27 clips. This protocol is intended to control multiple data delivery 28 sessions, provide a means for choosing delivery channels such as UDP, 29 multicast UDP and TCP, and provide a means for choosing delivery 30 mechanisms based upon RTP (RFC 3550). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 21, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 79 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 80 2.1. Presentation Description . . . . . . . . . . . . . . . . 11 81 2.2. Session Establishment . . . . . . . . . . . . . . . . . . 12 82 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 13 83 2.4. Session Parameter Manipulations . . . . . . . . . . . . . 15 84 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 16 85 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 16 86 2.6. Session Maintenance and Termination . . . . . . . . . . . 19 87 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 20 88 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 21 89 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 21 90 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 21 91 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 92 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24 93 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 94 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . . 27 95 4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 27 96 4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . . 28 97 4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 28 98 4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . . 30 99 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 30 100 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . . 31 101 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 31 102 4.7.1. Random Access and Seeking . . . . . . . . . . . . . . 32 103 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . . 33 104 4.7.3. Content Modifications . . . . . . . . . . . . . . . . 33 105 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . . 33 106 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . . 34 107 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 108 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 34 109 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 35 110 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 111 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 112 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 36 113 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38 115 7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 40 116 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42 117 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 42 118 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 42 119 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 120 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 46 121 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47 122 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48 123 9.3. Message Body Format Negotiation . . . . . . . . . . . . . 48 124 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 48 125 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49 126 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50 127 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 128 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 129 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 130 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56 131 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 57 132 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 133 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 60 134 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60 135 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 136 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 63 137 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 64 138 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 66 139 13.3.1. Changing Transport Parameters . . . . . . . . . . . 69 140 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 70 141 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 70 142 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 75 143 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 76 144 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 79 145 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 79 146 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 79 147 13.4.7. Playing Live with Recording . . . . . . . . . . . . 80 148 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 81 149 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 81 150 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 82 151 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 84 152 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 85 153 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 86 154 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 89 155 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 89 156 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 90 157 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91 158 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 93 159 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 95 160 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 97 161 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 162 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 101 163 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 102 164 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 165 16.1. Validation Model . . . . . . . . . . . . . . . . . . . 103 166 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 104 167 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 104 168 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 104 169 16.1.4. Rules for When to Use Message Body Tags and Last- 170 Modified Dates . . . . . . . . . . . . . . . . . . . 107 171 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 108 172 16.2. Invalidation After Updates or Deletions . . . . . . . . 108 173 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 109 174 17.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 109 175 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 109 176 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 110 177 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 110 178 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 110 179 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 111 180 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 111 181 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 111 182 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 111 183 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 111 184 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 112 185 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 112 186 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 112 187 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 112 188 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 113 189 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 113 190 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 113 191 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 113 192 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 113 193 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 114 194 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 114 195 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 114 196 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 114 197 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 114 198 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 115 199 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 115 200 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 115 201 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 115 202 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 115 203 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 116 204 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 116 205 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 116 206 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 116 207 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 116 208 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 116 209 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 116 210 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 116 211 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 117 212 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 117 213 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 117 214 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 117 215 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 117 216 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 117 217 17.4.32. 470 Connection Authorization Required . . . . . . . 118 218 17.4.33. 471 Connection Credentials not accepted . . . . . . 118 219 17.4.34. 472 Failure to establish secure connection . . . . . 118 220 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 118 221 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 118 222 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 118 223 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 118 224 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 119 225 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 119 226 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 119 227 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 119 228 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 119 229 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 120 230 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 131 231 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 131 232 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 132 233 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 133 234 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 134 235 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 134 236 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 135 237 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 135 238 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 136 239 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 136 240 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 137 241 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 139 242 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 140 243 18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 141 244 18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 141 245 18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 142 246 18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 143 247 18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 143 248 18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 144 249 18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 144 250 18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 146 251 18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 147 252 18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 148 253 18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 148 254 18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 149 255 18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 149 256 18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 150 257 18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 150 258 18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 151 259 18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 153 260 18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 153 261 18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 154 262 18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 154 263 18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 155 264 18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 155 265 18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 156 266 18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 156 267 18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 156 268 18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 157 269 18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 158 270 18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 160 271 18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 160 272 18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 161 273 18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 162 274 18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 162 275 18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 164 276 18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 165 277 18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 167 278 18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 167 279 18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 168 280 18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 169 281 18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 170 282 18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 170 283 18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 171 284 18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 178 285 18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 178 286 18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 179 287 18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 179 288 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 180 289 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 180 290 19.1.1. Digest Authentication . . . . . . . . . . . . . . . 181 291 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 182 292 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 183 293 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 184 294 19.3.2. User approved TLS procedure . . . . . . . . . . . . 185 295 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 296 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 187 297 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 189 298 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 190 299 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 192 300 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 196 301 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 205 302 21. Security Considerations . . . . . . . . . . . . . . . . . . . 205 303 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 206 304 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 209 305 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 210 306 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 211 307 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 212 308 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 213 309 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 214 310 22.1.2. Registering New Feature-tags with IANA . . . . . . . 214 311 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 214 312 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 215 313 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 215 314 22.2.2. Registering New Methods with IANA . . . . . . . . . 215 315 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 216 316 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 216 317 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 216 318 22.3.2. Registering New Status Codes with IANA . . . . . . . 216 319 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 217 320 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 217 321 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 217 322 22.4.2. Registering New Headers with IANA . . . . . . . . . 217 323 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 217 324 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 219 325 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 219 326 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 219 327 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 220 328 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 221 329 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 221 330 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 221 331 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 221 332 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 222 333 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 222 334 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 222 335 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 222 336 22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 223 337 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 223 338 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 223 339 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 223 340 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 223 341 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 224 342 22.10.2. Terminate-Reason Header Parameters . . . . . . . . 224 343 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 225 344 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 225 345 22.11.2. Registration Rules . . . . . . . . . . . . . . . . 225 346 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 225 347 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 225 348 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 226 349 22.12.2. Registration Rules . . . . . . . . . . . . . . . . 226 350 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 226 351 22.13. Transport Header Registries . . . . . . . . . . . . . . 227 352 22.13.1. Transport Protocol Identifier . . . . . . . . . . . 227 353 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 228 354 22.13.3. Transport Parameters . . . . . . . . . . . . . . . 229 355 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 230 356 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 230 357 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . 231 358 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . 232 359 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 233 360 22.16. Media Type Registration for text/parameters . . . . . . 234 361 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 235 362 23.1. Normative References . . . . . . . . . . . . . . . . . . 235 363 23.2. Informative References . . . . . . . . . . . . . . . . . 239 364 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 241 365 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 241 366 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 245 367 A.3. Secured Media Session for on Demand Content . . . . . . . 247 368 A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 250 369 A.5. Single Stream Container Files . . . . . . . . . . . . . . 254 370 A.6. Live Media Presentation Using Multicast . . . . . . . . . 256 371 A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 257 372 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 258 373 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 259 374 B.2. State variables . . . . . . . . . . . . . . . . . . . . . 259 375 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 259 376 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 260 377 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 264 378 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 379 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 265 380 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 265 381 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 266 382 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 267 383 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 269 384 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 269 386 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 271 387 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 271 388 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 272 389 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 276 390 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 280 391 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 282 392 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 282 393 C.7. Maintaining NPT synchronization with RTP timestamps . . . 282 394 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 282 395 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 282 396 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP 397 Session . . . . . . . . . . . . . . . . . . . . . . . . . 283 398 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 283 399 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 284 400 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 284 401 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 284 402 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 286 403 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 286 404 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 286 405 D.1.5. Directionality of media stream . . . . . . . . . . . 287 406 D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 287 407 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 288 408 D.1.8. Connection Information . . . . . . . . . . . . . . . 288 409 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 289 410 D.2. Aggregate Control Not Available . . . . . . . . . . . . . 289 411 D.3. Aggregate Control Available . . . . . . . . . . . . . . . 290 412 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 291 413 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 292 414 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 292 415 E.1. On-demand Playback of Stored Content . . . . . . . . . . 292 416 E.2. Unicast Distribution of Live Content . . . . . . . . . . 294 417 E.3. On-demand Playback using Multicast . . . . . . . . . . . 294 418 E.4. Inviting an RTSP server into a conference . . . . . . . . 295 419 E.5. Live Content using Multicast . . . . . . . . . . . . . . 296 420 Appendix F. Text format for Parameters . . . . . . . . . . . . . 296 421 Appendix G. Requirements for Unreliable Transport of RTSP . . . 297 422 Appendix H. Backwards Compatibility Considerations . . . . . . . 298 423 H.1. Play Request in Play State . . . . . . . . . . . . . . . 299 424 H.2. Using Persistent Connections . . . . . . . . . . . . . . 299 425 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 299 426 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 299 427 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 300 428 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 307 429 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 308 430 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 308 431 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 308 433 1. Introduction 435 This memo defines version 2.0 of the Real Time Streaming Protocol 436 (RTSP 2.0). RTSP 2.0 is an application-layer protocol for setup and 437 control over the delivery of data with real-time properties, 438 typically streaming media. Streaming media is, for instance, video 439 on demand or audio live streaming. Put simply, RTSP acts as a 440 "network remote control" for multimedia servers. 442 The protocol operates between RTSP 2.0 clients and servers, but also 443 supports the usage of proxies placed between clients and servers. 444 Clients can request information about streaming media from servers by 445 asking for a description of the media or use media description 446 provided externally. The media delivery protocol is used to 447 establish the media streams described by the media description. 448 Clients can then request to play out the media, pause it, or stop it 449 completely. The requested media can consist of multiple audio and 450 video streams that are delivered as time-synchronized streams from 451 servers to clients. 453 RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that 454 specification. This protocol is based on RTSP 1.0 but is not 455 backwards compatible other than in the basic version negotiation 456 mechanism. The changes are documented in Appendix I. There are many 457 reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but 458 some of the main ones are: 460 o Most headers that needed to be extensible did not define the 461 allowed syntax, preventing safe deployment of extensions; 463 o The changed behavior of the PLAY method when received in Play 464 state; 466 o Changed behavior of the extensibility model and its mechanism; 468 o The change of syntax for some headers. 470 In summary, there are so many small details that changing version 471 became necessary to enable clarification and consistent behavior. 472 Anyone implementing RTSP for a new usage where they have no installed 473 based of RTSP 1.0 should only implement RTSP 2.0 to avoid having to 474 deal with RTSP 1.0 inconsistencies. 476 This document is structured as follows. It begins with an overview 477 of the protocol operations and its functions in an informal way. 478 Then a set of definitions of terms used and document conventions is 479 introduced. It is followed by the actual RTSP 2.0 core protocol 480 specification. The appendixes describe and define some 481 functionalities that are not part of the core RTSP specification, but 482 which are still important to enable some usages. Among them, the RTP 483 usage is defined in Appendix C, the Session Description Protocol 484 (SDP) usage with RTSP is defined in Appendix D, and the text/ 485 parameters file format Appendix F, are three normative specification 486 appendixes. Others include a number of informational parts 487 discussing the changes, use cases, different considerations or 488 motivations. 490 2. Protocol Overview 492 This section provides an informative overview of the different 493 mechanisms in the RTSP 2.0 protocol, to give the reader a high level 494 understanding before getting into all the different details. In case 495 of conflict with this description and the later sections, the later 496 sections take precedence. For more information about use cases 497 considered for RTSP see Appendix E. 499 RTSP 2.0 is a bi-directional request and response protocol that first 500 establishes a context including content resources (the media) and 501 then controls the delivery of these content resources from the 502 provider to the consumer. RTSP has three fundamental parts: Session 503 Establishment, Media Delivery Control, and an extensibility model 504 described below. The protocol is based on some assumptions about 505 existing functionality to provide a complete solution for client 506 controlled real-time media delivery. 508 RTSP uses text-based messages, requests and responses, that may 509 contain a binary message body. An RTSP request starts with a method 510 line that identifies the method, the protocol and version and the 511 resource to act on. The resource is identified by a URI and the 512 hostname part of the URI is used by RTSP client to resolve the IPv4 513 or IPv6 address of the RTSP server. Following the method line are a 514 number of RTSP headers. This part is ended by two consecutive 515 carriage return line feed (CRLF) character pairs. The message body 516 if present follows the two CRLF and the body's length is described by 517 a message header. RTSP responses are similar, but start with a 518 response line with the protocol and version, followed by a status 519 code and a reason phrase. RTSP messages are sent over a reliable 520 transport protocol between the client and server. RTSP 2.0 requires 521 clients and servers to implement TCP, and TLS over TCP, as mandatory 522 transports for RTSP messages. 524 2.1. Presentation Description 526 RTSP exists to provide access to multi-media presentations and 527 content, but tries to be agnostic about the media type or the actual 528 media delivery protocol that is used. To enable a client to 529 implement a complete system, an RTSP-external mechanism for 530 describing the presentation and the delivery protocol(s) is used. 531 RTSP assumes that this description is either delivered completely out 532 of band or as a data object in the response to a client's request 533 using the DESCRIBE method (Section 13.2). 535 Parameters that commonly have to be included in the Presentation 536 Description are the following: 538 o Number of media streams; 540 o The resource identifier for each media stream/resource that is to 541 be controlled by RTSP; 543 o The protocol that each media stream is to be delivered over; 545 o Transport protocol parameters that are not negotiated or vary with 546 each client; 548 o Media encoding information enabling a client to correctly decode 549 the media upon reception; 551 o An aggregate control resource identifier. 553 RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media 554 resources and aggregates under common control (See Section 4.2). 556 This specification describes in Appendix D how one uses SDP [RFC4566] 557 for Presentation Description 559 2.2. Session Establishment 561 The RTSP client can request the establishment of an RTSP session 562 after having used the presentation description to determine which 563 media streams are available, which media delivery protocol is used 564 and the resource identifiers of the media streams. The RTSP session 565 is a common context between the client and the server that consists 566 of one or more media resources that are to be under common media 567 delivery control. 569 The client creates an RTSP session by sending a request using the 570 SETUP method (Section 13.3) to the server. In the "Transport" header 571 (Section 18.54) of the SETUP request, the client also includes all 572 the transport parameters necessary to enable the media delivery 573 protocol to function. This includes parameters that are pre- 574 established by the presentation description but necessary for any 575 middlebox to correctly handle the media delivery protocols. The 576 Transport header in a request may contain multiple alternatives for 577 media delivery in a prioritized list, which the server can select 578 from. These alternatives are typically based on information in the 579 presentation description. 581 The server determines if the media resource is available upon 582 receiving a SETUP request and if any of the transport parameter 583 specifications are acceptable. If that is successful, an RTSP 584 session context is created and the relevant parameters and state is 585 stored. An identifier is created for the RTSP session and included 586 in the response in the Session header (Section 18.49). The SETUP 587 response includes a Transport header that specifies which of the 588 alternatives has been selected and relevant parameters. 590 A SETUP request that references an existing RTSP session but 591 identifies a new media resource is a request to add that media 592 resource under common control with the already present media 593 resources in an aggregated session. A client can expect this to work 594 for all media resources under RTSP control within a multi-media 595 content. However, aggregating resources from different content are 596 likely to be refused by the server. Even if a RTSP session contains 597 only a single media, the RTSP session can be referenced by the 598 aggregate control URI. 600 To avoid an extra round trip in the session establishment of 601 aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., 602 the client can send multiple requests back-to-back without waiting 603 first for the completion of any of them. The client uses a client- 604 selected identifier in the Pipelined-Requests header (Section 18.33) 605 to instruct the server to bind multiple requests together as if they 606 included the session identifier. 608 The SETUP response also provides additional information about the 609 established sessions in a couple of different headers. The Media- 610 Properties header (Section 18.29) includes a number of properties 611 that apply for the aggregate that is valuable when doing media 612 delivery control and configuring user interface. The Accept-Ranges 613 header (Section 18.5) informs the client about which range formats 614 that the server supports with these media resources. The Media-Range 615 header (Section 18.30) informs the client about the time range of the 616 media currently available. 618 2.3. Media Delivery Control 620 After having established an RTSP session, the client can start 621 controlling the media delivery. The basic operations are Start by 622 using the PLAY method (Section 13.4) and Halt by using the PAUSE 623 method (Section 13.6). PLAY also allows for choosing the starting 624 media position from which the server should deliver the media. The 625 positioning is done by using the Range header (Section 18.40) that 626 supports several different time formats: Normal Play Time (NPT) 627 (Section 4.4.2), Society of Motion Picture and Television Engineers 628 (SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3). 629 The Range header does further allow the client to specify a position 630 where delivery should end, thus allowing a specific interval to be 631 delivered. 633 The support for positioning/searching within a media content depends 634 on the content's media properties. Content exists in a number of 635 different types, such as: on-demand, live, and live with simultaneous 636 recording. Even within these categories there are differences in how 637 the content is generated and distributed, which affect how it can be 638 accessed for playback. The properties applicable for the RTSP 639 session are provided by the server in the SETUP response using the 640 Media-Properties header (Section 18.29). These are expressed using 641 one or several independent attributes. A first attribute is Random 642 Access, which expresses if positioning can be done, and with what 643 granularity. Another aspect is whether the content will change 644 during the lifetime of the session. While on-demand content will be 645 provided in full from the beginning, a live stream being recorded 646 results in the length of the accessible content growing as the 647 session goes on. There also exists content that is dynamically built 648 by another protocol than RTSP and thus also changes in steps during 649 the session, but maybe not continuously. Furthermore, when content 650 is recorded, there are cases where not the complete content is 651 maintained, but, for example, only the last hour. All these 652 properties result in the need for mechanisms that will be discussed 653 below. 655 When the client accesses on-demand content that allows random access, 656 the client can issue the PLAY request for any point in the content 657 between the start and the end. The server will deliver media from 658 the closest random access point prior to the requested point and 659 indicate that in its PLAY response. If the client issues a PAUSE, 660 the delivery will be halted and the point at which the server stopped 661 will be reported back in the response. The client can later resume 662 by sending a PLAY request without a range header. When the server is 663 about to complete the PLAY request by delivering the end of the 664 content or the requested range, the server will send a PLAY_NOTIFY 665 request (Section 13.5) indicating this. 667 When playing live content with no extra functions, such as recording, 668 the client will receive the live media from the server after having 669 sent a PLAY request. Seeking in such content is not possible as the 670 server does not store it, but only forwards it from the source of the 671 session. Thus delivery continues until the client sends a PAUSE 672 request, tears down the session, or the content ends. 674 For live sessions that are being recorded the client will need to 675 keep track of how the recording progresses. Upon session 676 establishment the client will learn the current duration of the 677 recording from the Media-Range header. As the recording is ongoing 678 the content grows in direct relation to the passed time. Therefore, 679 each server's response to a PLAY request will contain the current 680 Media-Range header. The server should also regularly send 681 approximately every 5 minutes the current media range in a 682 PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, 683 the server must send a PLAY_NOTIFY request with the updated Media- 684 Properties indicating that the content stopped being a recorded live 685 session and instead became on-demand content; the request also 686 contains the final media range. While the live delivery continues 687 the client can request to play the current live point by using the 688 NPT timescale symbol "now", or it can request a specific point in the 689 available content by an explicit range request for that point. If 690 the requested point is outside of the available interval the server 691 will adjust the position to the closest available point, i.e., either 692 at the beginning or the end. 694 A special case of recording is that where the recording is not 695 retained longer than a specific time period, thus as the live 696 delivery continues the client can access any media within a moving 697 window that covers, for example, "now" to "now" minus 1 hour. A 698 client that pauses on a specific point within the content may not be 699 able to retrieve the content anymore. If the client waits too long 700 before resuming the pause point, the content may no longer be 701 available. In this case the pause point will be adjusted to the 702 closest point in the available media. 704 2.4. Session Parameter Manipulations 706 A session may have additional state or functionality that affects how 707 the server or client treats the session, content, how it functions, 708 or feedback on how well the session works. Such extensions are not 709 defined in this specification, but may be done in various extensions. 710 RTSP has two methods for retrieving and setting parameter values on 711 either the client or the server: GET_PARAMETER (Section 13.8) and 712 SET_PARAMETER (Section 13.9). These methods carry the parameters in 713 a message body of the appropriate format. One can also use headers 714 to query state with the GET_PARAMETER method. As an example, clients 715 needing to know the current media-range for a time-progressing 716 session can use the GET_PARAMETER method and include the media-range. 717 Furthermore, synchronization information can be requested by using a 718 combination of RTP-Info (Section 18.45) and Range (Section 18.40). 720 RTSP 2.0 does not have a strong mechanism for providing negotiation 721 of the headers, or parameters and their formats, that can be used. 723 However, responses will indicate request-headers or parameters that 724 are not supported. A priori determination of what features are 725 available needs to be done through out-of-band mechanisms, like the 726 session description, or through the usage of feature tags 727 (Section 4.5). 729 2.5. Media Delivery 731 This document specifies how media is delivered with RTP [RFC3550] 732 over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. Additional 733 protocols may be specified in the future based on demand. 735 The usage of RTP as media delivery protocol requires some additional 736 information to function well. The PLAY response contains information 737 to enable reliable and timely delivery of how a client should 738 synchronize different sources in the different RTP sessions. It also 739 provides a mapping between RTP timestamps and the content time scale. 740 When the server wants to notify the client about the completion of 741 the media delivery, it sends a PLAY_NOTIFY request to the client. 742 The PLAY_NOTIFY request includes information about the stream end, 743 including the last RTP sequence number for each stream, thus enabling 744 the client to empty the buffer smoothly. 746 2.5.1. Media Delivery Manipulations 748 The basic playback functionality of RTSP enables delivery of a range 749 of requested content to the client at the pace intended by the 750 content's creator. However, RTSP can also manipulate the delivery to 751 the client in two ways. 753 Scale: The ratio of media content time delivered per unit playback 754 time. 756 Speed: The ratio of playback time delivered per unit of wallclock 757 time. 759 Both affect the media delivery per time unit. However, they 760 manipulate two independent time scales and the effects are possible 761 to combine. 763 Scale (Section 18.46) is used for fast forward or slow motion control 764 as it changes the amount of content timescale that should be played 765 back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0 766 results in that 2 seconds of content is played back every second of 767 playback. Scale = 1.0 is the default value that is used if no Scale 768 is specified, i.e., playback at the content's original rate. Scale 769 values between 0 and 1.0 is providing for slow motion. Scale can be 770 negative to allow for reverse playback in either regular pace (Scale 771 = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards 772 (-1.0 < Scale < 0). Scale = 0 would be equal to pause and is not 773 allowed. 775 In most cases the realization of scale means server side manipulation 776 of the media to ensure that the client can actually play it back. 777 The nature of these media manipulations and when they are needed is 778 highly media-type dependent. Let's consider an example with two 779 common media types audio and video. 781 It is very difficult to modify the playback rate of audio. A maximum 782 of 10-30% is possible by changing the pitch-rate of speech. Music 783 goes out of tune if one tries to manipulate the playback rate by 784 resampling it. This is a well known problem and audio is commonly 785 muted or played back in short segments with skips to keep up with the 786 current playback point. 788 For video it is possible to manipulate the frame rate, although the 789 rendering capabilities are often limited to certain frame rates. 790 Also the allowed bitrates in decoding, the structure used in the 791 encoding and the dependency between frames and other capabilities of 792 the rendering device limits the possible manipulations. Therefore, 793 the basic fast forward capabilities often are implemented by 794 selecting certain subsets of frames. 796 Due to the media restrictions, the possible scale values are commonly 797 restricted to the set of realizable scale ratios. To enable the 798 clients to select from the possible scale values, RTSP can signal the 799 supported Scale ratios for the content. To support aggregated or 800 dynamic content, where this may change during the ongoing session and 801 dependent on the location within the content, a mechanism for 802 updating the media properties and the scale factor currently in use, 803 exists. 805 Speed (Section 18.50) affects how much of the playback timeline is 806 delivered in a given wallclock period. The default is Speed = 1 807 which means to deliver at the same rate the media is consumed. Speed 808 > 1 means that the receiver will get content faster than it regularly 809 would consume it. Speed < 1 means that delivery is slower than the 810 regular media rate. Speed values of 0 or lower have no meaning and 811 are not allowed. This mechanism enables two general functionalities. 812 One is client side scale operations, i.e., the client receives all 813 the frames and makes the adjustment to the playback locally. The 814 second is delivery control for buffering of media. By specifying a 815 speed over 1.0 the client can build up the amount of playback time it 816 has present in its buffers to a level that is sufficient for its 817 needs. 819 A naive implementation of Speed would only affect the transmission 820 schedule of the media and has a clear impact on the needed bandwidth. 821 This would result in the data rate being proportional to the speed 822 factor. Speed = 1.5, i.e., 50% faster than normal delivery, would 823 result in a 50% increase in the data transport rate. If that can be 824 supported or not depends solely on the underlying network path. 825 Scale may also have some impact on the required bandwidth due to the 826 manipulation of the content in the new playback schedule. An example 827 is fast forward where only the independently decodable intra frames 828 are included in the media stream. This usage of solely intra frames 829 increases the data rate significantly compared to a normal sequence 830 with the same number of frames, where most frames are encoded using 831 prediction. 833 This potential increase of the data rate needs to be handled by the 834 media sender. The client has requested that the media will be 835 delivered in a specific way, which should be honored. However, the 836 media sender cannot ignore if the network path between the sender and 837 the receiver can't handle the resulting media stream. In that case 838 the media stream needs to be adapted to fit the available resources 839 of the path. This can result in a reduced media quality. 841 The need for bitrate adaptation becomes especially problematic in 842 connection with the Speed semantics. If the goal is to fill up the 843 buffer, the client may not want to do that at the cost of reduced 844 quality. If the client wants to make local playout changes then it 845 may actually require that the requested speed be honored. To resolve 846 this issue, Speed uses a range so that both cases can be supported. 847 The server is requested to use the highest possible speed value 848 within the range which is compatible with the available bandwidth. 849 As long as the server can maintain a speed value within the range it 850 shall not change the media quality, but instead modify the actual 851 delivery rate in response to available bandwidth and reflect this in 852 the Speed value in the response. However, if this is not possible, 853 the server should instead modify the media quality to respect the 854 lowest speed value and the available bandwidth. 856 This functionality enables the local scaling implementation to use a 857 tight range, or even a range where the lower bound equals the upper 858 bound, to identify that it requires the server to deliver the 859 requested amount of media time per delivery time independent of how 860 much it needs to adapt the media quality to fit within the available 861 path bandwidth. For buffer filling, it is suitable to use a range 862 with a reasonable span and with a lower bound at the nominal media 863 rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the 864 buffer, it can specify an upper bound that is below 1.0 to force the 865 server to deliver slower than the nominal media rate. 867 2.6. Session Maintenance and Termination 869 The session context that has been established is kept alive by having 870 the client show liveness. This is done in two main ways: 872 o Media transport protocol keep-alive. RTP Control Protocol (RTCP) 873 may be used when using RTP. 875 o Any RTSP request referencing the session context. 877 Section 10.5 discusses the methods for showing liveness in more 878 depth. If the client fails to show liveness for more than the 879 established session timeout value (normally 60 seconds), the server 880 may terminate the context. Other values may be selected by the 881 server through the inclusion of the timeout parameter in the session 882 header. 884 The session context is normally terminated by the client sending a 885 TEARDOWN request (Section 13.7) to the server referencing the 886 aggregated control URI. An individual media resource can be removed 887 from a session context by a TEARDOWN request referencing that 888 particular media resource. If all media resources are removed from a 889 session context, the session context is terminated. 891 A client may keep the session alive indefinitely if allowed by the 892 server; however, a client is recommended to release the session 893 context when an extended period of time without media delivery 894 activity has passed. The client can re-establish the session context 895 if required later. What constitutes an extended period of time is 896 dependent on the client, server and their usage. It is recommended 897 that the client terminates the session before ten times the session 898 timeout value has passed. A server may terminate the session after 899 one session timeout period without any client activity beyond keep- 900 alive. When a server terminates the session context, it does that by 901 sending a TEARDOWN request indicating the reason. 903 A server can also request that the client tear down the session and 904 re-establish it at an alternative server, as may be needed for 905 maintenance. This is done by using the REDIRECT method 906 (Section 13.10). The Terminate-Reason header (Section 18.52) is used 907 to indicate when and why. The Location header indicates where it 908 should connect if there is an alternative server available. When the 909 deadline expires, the server simply stops providing the service. To 910 achieve a clean closure, the client needs to initiate session 911 termination prior to the deadline. In case the server has no other 912 server to redirect to, and wants to close the session for 913 maintenance, it shall use the TEARDOWN method with a Terminate-Reason 914 header. 916 2.7. Extending RTSP 918 RTSP is quite a versatile protocol which supports extensions in many 919 different directions. Even this core specification contains several 920 blocks of functionality that are optional to implement. The use case 921 and need for the protocol deployment should determine what parts are 922 implemented. Allowing for extensions makes it possible for RTSP to 923 reach out to additional use cases. However, extensions will affect 924 the interoperability of the protocol and therefore it is important 925 that they can be added in a structured way. 927 The client can learn the capability of a server by using the OPTIONS 928 method (Section 13.1) and the Supported header (Section 18.51). It 929 can also try and possibly fail using new methods, or require that 930 particular features are supported using the Require (Section 18.43) 931 or Proxy-Require (Section 18.37) header. 933 The RTSP protocol in itself can be extended in three ways, listed 934 here in increasing order of the magnitude of changes supported: 936 o Existing methods can be extended with new parameters, for example, 937 headers, as long as these parameters can be safely ignored by the 938 recipient. If the client needs negative acknowledgment when a 939 method extension is not supported, a tag corresponding to the 940 extension may be added in the field of the Require or Proxy- 941 Require headers. 943 o New methods can be added. If the recipient of the message does 944 not understand the request, it must respond with error code 501 945 (Not Implemented) so that the sender can avoid using this method 946 again. A client may also use the OPTIONS method to inquire about 947 methods supported by the server. The server must list the methods 948 it supports using the Public response-header. 950 o A new version of the protocol can be defined, allowing almost all 951 aspects (except the position of the protocol version number) to 952 change. A new version of the protocol must be registered through 953 an IETF standards track document. 955 The basic capability discovery mechanism can be used to both discover 956 support for a certain feature and to ensure that a feature is 957 available when performing a request. For a detailed explanation of 958 this see Section 11. 960 New media delivery protocols may be added and negotiated at session 961 establishment, in addition to extensions to the core protocol. 962 Certain types of protocol manipulations can be done through parameter 963 formats using SET_PARAMETER and GET_PARAMETER. 965 3. Document Conventions 967 3.1. Notational Conventions 969 Since a few of the definitions are identical to HTTP/1.1, this 970 specification only points to the section where they are defined 971 rather than copying it. For brevity, [HX.Y] is to be taken to refer 972 to Section X.Y of the HTTP/1.1 specification ([RFC2616]). 974 All the mechanisms specified in this document are described in both 975 prose and the Augmented Backus-Naur form (ABNF) described in detail 976 in [RFC5234]. 978 Indented paragraphs are used to provide informative background and 979 motivation. This is intended to give readers who were not involved 980 with the formulation of the specification an understanding of why 981 things are the way they are in RTSP. 983 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 984 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 985 "OPTIONAL" in this document are to be interpreted as described in 986 [RFC2119]. 988 The word, "unspecified" is used to indicate functionality or features 989 that are not defined in this specification. Such functionality 990 cannot be used in a standardized manner without further definition in 991 an extension specification to RTSP. 993 3.2. Terminology 995 Aggregate control: The concept of controlling multiple streams using 996 a single timeline, generally maintained by the server. A client, 997 for example, uses aggregate control when it issues a single play 998 or pause message to simultaneously control both the audio and 999 video in a movie. A session which is under aggregate control is 1000 referred to as an aggregated session. 1002 Aggregate control URI: The URI used in an RTSP request to refer to 1003 and control an aggregated session. It normally, but not always, 1004 corresponds to the presentation URI specified in the session 1005 description. See Section 13.3 for more information. 1007 Client: The client requests media service from the media server. 1009 Connection: A transport layer virtual circuit established between 1010 two programs for the purpose of communication. 1012 Container file: A file which may contain multiple media streams 1013 which often constitutes a presentation when played together. The 1014 concept of a container file is not embedded in the protocol. 1015 However, RTSP servers may offer aggregate control on the media 1016 streams within these files. 1018 Continuous media: Data where there is a timing relationship between 1019 source and sink; that is, the sink needs to reproduce the timing 1020 relationship that existed at the source. The most common examples 1021 of continuous media are audio and motion video. Continuous media 1022 can be real-time (interactive or conversational), where there is a 1023 "tight" timing relationship between source and sink, or streaming 1024 where the relationship is less strict. 1026 Feature-tag: A tag representing a certain set of functionality, 1027 i.e., a feature. 1029 IRI: Internationalized Resource Identifier, is similar to a URI, but 1030 allows characters from the whole Universal Character Set (Unicode/ 1031 ISO 10646), rather than the US-ASCII only. See [RFC3987] for more 1032 information. 1034 Live: Normally used to describe a presentation or session with media 1035 coming from an ongoing event. This generally results in the 1036 session having an unbound or only loosely defined duration, and 1037 sometimes no seek operations are possible. 1039 Media initialization: Datatype/codec specific initialization. This 1040 includes such things as clock rates, color tables, etc. Any 1041 transport-independent information which is required by a client 1042 for playback of a media stream occurs in the media initialization 1043 phase of stream setup. 1045 Media parameter: Parameter specific to a media type that may be 1046 changed before or during stream delivery. 1048 Media server: The server providing media delivery services for one 1049 or more media streams. Different media streams within a 1050 presentation may originate from different media servers. A media 1051 server may reside on the same host or on a different host from 1052 which the presentation is invoked. 1054 (Media) stream: A single media instance, e.g., an audio stream or a 1055 video stream as well as a single whiteboard or shared application 1056 group. When using RTP, a stream consists of all RTP and RTCP 1057 packets created by a source within an RTP session. 1059 Message: The basic unit of RTSP communication, consisting of a 1060 structured sequence of octets matching the syntax defined in 1061 Section 20 and transmitted over a connection-based transport. A 1062 message is either a Request or a Response. 1064 Message Body: The information transferred as the payload of a 1065 message (Request or response). A message body consists of meta- 1066 information in the form of message-body headers and content in the 1067 form of a message-body, as described in Section 9. 1069 Non-Aggregated Control: Control of a single media stream. 1071 Presentation: A set of one or more streams presented to the client 1072 as a complete media feed and described by a presentation 1073 description as defined below. Presentations with more than one 1074 media stream are often handled in RTSP under aggregate control. 1076 Presentation description: A presentation description contains 1077 information about one or more media streams within a presentation, 1078 such as the set of encodings, network addresses and information 1079 about the content. Other IETF protocols such as SDP ([RFC4566]) 1080 use the term "session" for a presentation. The presentation 1081 description may take several different formats, including but not 1082 limited to the session description protocol format, SDP. 1084 Response: An RTSP response to a Request. One type of RTSP message. 1085 If an HTTP response is meant, it is indicated explicitly. 1087 Request: An RTSP request. One type of RTSP message. If an HTTP 1088 request is meant, it is indicated explicitly. 1090 Request-URI: The URI used in a request to indicate the resource on 1091 which the request is to be performed. 1093 RTSP agent: Refers to either an RTSP client, an RTSP server, or an 1094 RTSP proxy. In this specification, there are many capabilities 1095 that are common to these three entities such as the capability to 1096 send requests or receive responses. This term will be used when 1097 describing functionality that is applicable to all three of these 1098 entities. 1100 RTSP session: A stateful abstraction upon which the main control 1101 methods of RTSP operate. An RTSP session is a common context; it 1102 is created and maintained on client's request and can be destroyed 1103 by either the client or server. It is established by an RTSP 1104 server upon the completion of a successful SETUP request (when a 1105 200 OK response is sent) and is labeled with a session identifier 1106 at that time. The session exists until timed out by the server or 1107 explicitly removed by a TEARDOWN request. An RTSP session is a 1108 stateful entity; an RTSP server maintains an explicit session 1109 state machine (see Appendix B) where most state transitions are 1110 triggered by client requests. The existence of a session implies 1111 the existence of state about the session's media streams and their 1112 respective transport mechanisms. A given session can have one or 1113 more media streams associated with it. An RTSP server uses the 1114 session to aggregate control over multiple media streams. 1116 Origin Server: The server on which a given resource resides. 1118 Transport initialization: The negotiation of transport information 1119 (e.g., port numbers, transport protocols) between the client and 1120 the server. 1122 URI: Universal Resource Identifier, see [RFC3986]. The URIs used in 1123 RTSP are generally URLs as they give a location for the resource. 1124 As URLs are a subset of URIs, they will be referred to as URIs to 1125 cover also the cases when an RTSP URI would not be an URL. 1127 URL: Universal Resource Locator, is a URI which identifies the 1128 resource through its primary access mechanism, rather than 1129 identifying the resource by name or by some other attribute(s) of 1130 that resource. 1132 4. Protocol Parameters 1134 4.1. RTSP Version 1136 This specification defines version 2.0 of RTSP. 1138 RTSP uses a "." numbering scheme to indicate versions 1139 of the protocol. The protocol versioning policy is intended to allow 1140 the sender to indicate the format of a message and its capacity for 1141 understanding further RTSP communication, rather than the features 1142 obtained via that communication. No change is made to the version 1143 number for the addition of message components which do not affect 1144 communication behavior or which only add to extensible field values. 1146 The number is incremented when the changes made to the 1147 protocol add features which do not change the general message parsing 1148 algorithm, but which may add to the message semantics and imply 1149 additional capabilities of the sender. The number is 1150 incremented when the format of a message within the protocol is 1151 changed. The version of an RTSP message is indicated by an RTSP- 1152 Version field in the first line of the message. Note that the major 1153 and minor numbers MUST be treated as separate integers and that each 1154 MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a 1155 lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. 1156 Leading zeros SHALL NOT be sent and MUST be ignored by recipients. 1158 4.2. RTSP IRI and URI 1160 RTSP 2.0 defines and registers or updates three URI schemes "rtsp", 1161 "rtsps" and "rtspu". The usage of the last, "rtspu", is unspecified 1162 in RTSP 2.0, and is defined here to register the URI scheme that was 1163 defined in RTSP 1.0. The "rtspu" scheme indicates unspecified 1164 transport of the RTSP messages over unreliable transport (UDP in RTSP 1165 1.0). An RTSP server MUST respond with an error code indicating the 1166 "rtspu" scheme is not implemented (501) to a request that carries a 1167 "rtspu" URI scheme. 1169 The details of the syntax of "rtsp" and "rtsps" URIs has been changed 1170 from RTSP 1.0. These changes are: 1172 o Support for IPV6 literal in host part and future IP literals 1173 through RFC 3986 defined mechanism. 1175 o A new relative format to use in the RTSP protocol elements that is 1176 not required to start with "/". 1178 Neither should have any significant impact on interoperability. If 1179 one is required to use IPv6 literals to reach an RTSP server, then 1180 that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully 1181 IPv6 capable protocol. If an RTSP 1.0 client attempts to process the 1182 URI it will not match the allowed syntax and be considered invalid 1183 and processing will be stopped. This is clearly a failure to reach 1184 the resource, however it is not a signification issue as RTSP 2.0 1185 support was needed anyway in both server and client. Thus failure 1186 will only occur in a later step when there is a RTSP version mismatch 1187 between client and server. The second change will only occur inside 1188 RTSP message headers, as the request URI must be an absolute URI. 1189 Thus such usages will only occur after an agent has accepted and 1190 started processing RTSP 2.0 messages, and an RTSP 1.0 only agent will 1191 not be required to parse such types of relative URIs. 1193 This specification also defines the format of the RTSP IRI [RFC3987] 1194 that can be used as RTSP resource identifiers and locators, in web 1195 pages, user interfaces, on paper, etc. However, the RTSP request 1196 message format only allows usage of the absolute URI format. The 1197 RTSP IRI format MUST use the rules and transformation for IRIs to 1198 URIs, as defined in [RFC3987]. This allows a URI that matches the 1199 RTSP 2.0 specification, and so is suitable for use in a request, to 1200 be created from an RTSP IRI. 1202 The RTSP IRI and URI are both syntax restricted compared to the 1203 generic syntax defined in [RFC3986] and [RFC3987]: 1205 o An absolute URI requires the authority part; i.e., a host identity 1206 MUST be provided. 1208 o Parameters in the path element are prefixed with the reserved 1209 separator ";". 1211 The "scheme" and "host" parts of all URIs [RFC3986] and IRIs 1212 [RFC3987] are case-insensitive. All other parts of RTSP URIs and 1213 IRIs are case- sensitive, and MUST NOT be case-mapped. 1215 The fragment identifier is used as defined in sections 3.5 and 4.3 of 1216 [RFC3986], i.e., the fragment is to be stripped from the IRI by the 1217 requester and not included in the request URI. The user agent needs 1218 to interpret the value of the fragment based on the media type the 1219 request relates to; i.e., the media type indicated in Content-Type 1220 header in the response to DESCRIBE. 1222 The syntax of any URI query string is unspecified and responder 1223 (usually the server) specific. The query is, from the requester's 1224 perspective, an opaque string and needs to be handled as such. 1225 Please note that relative URI with queries are difficult to handle 1226 due to the RFC 3986 relative URI handling rules. Any change of the 1227 path element using a relative URI results in the stripping of the 1228 query, which means the relative part needs to contain the query. 1230 The URI scheme "rtsp" requires that commands are issued via a 1231 reliable protocol (within the Internet, TCP), while the scheme 1232 "rtsps" identifies a reliable transport using secure transport (TLS 1233 [RFC5246], see (Section 19). 1235 For the scheme "rtsp", if no port number is provided in the authority 1236 part of the URI, the port number 554 MUST be used. For the scheme 1237 "rtsps", if no port number is provided in the authority part of the 1238 URI port number, the TCP port 322 MUST be used. 1240 A presentation or a stream is identified by a textual media 1241 identifier, using the character set and escape conventions of URIs 1242 [RFC3986]. URIs may refer to a stream or an aggregate of streams; 1243 i.e., a presentation. Accordingly, requests described in 1244 (Section 13) can apply to either the whole presentation or an 1245 individual stream within the presentation. Note that some request 1246 methods can only be applied to streams, not presentations, and vice 1247 versa. 1249 For example, the RTSP URI: 1251 rtsp://media.example.com:554/twister/audiotrack 1253 may identify the audio stream within the presentation "twister", 1254 which can be controlled via RTSP requests issued over a TCP 1255 connection to port 554 of host media.example.com. 1257 Also, the RTSP URI: 1259 rtsp://media.example.com:554/twister 1261 identifies the presentation "twister", which may be composed of audio 1262 and video streams, but could also be something else like a random 1263 media redirector. 1265 This does not imply a standard way to reference streams in URIs. 1266 The presentation description defines the hierarchical 1267 relationships in the presentation and the URIs for the individual 1268 streams. A presentation description may name a stream "a.mov" and 1269 the whole presentation "b.mov". 1271 The path components of the RTSP URI are opaque to the client and do 1272 not imply any particular file system structure for the server. 1274 This decoupling also allows presentation descriptions to be used 1275 with non-RTSP media control protocols simply by replacing the 1276 scheme in the URI. 1278 4.3. Session Identifiers 1280 Session identifiers are strings of length 8-128 characters. A 1281 session identifier MUST be generated cryptographically random (see 1282 [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, 1283 i.e., approximately 22 characters from a high quality generator (see 1284 Section 21). However, note that the session identifier does not 1285 provide any security against session hijacking unless it is kept 1286 confidential by the client, server and trusted proxies. 1288 4.4. Media Time Formats 1290 RTSP currently supports three different media time formats defined 1291 below. Additional time formats may be specified in the future. 1292 These time formats can be used with the Range header (Section 18.40) 1293 to request playback and specify at which media position protocol 1294 requests actually will or have taken place. They are also used in 1295 description of the media's properties using the Media-Range header 1296 (Section 18.30). The unqualified format identifier is used on its 1297 own in Accept-Ranges header (Section 18.5) to declare supported time 1298 formats and also in the Range header (Section 18.40) to request the 1299 time format used in the response. 1301 4.4.1. SMPTE Relative Timestamps 1303 A Society of Motion Picture and Television Engineers (SMPTE) relative 1304 timestamp expresses time relative to the start of the clip. Relative 1305 timestamps are expressed as SMPTE time codes [SMPTE_TC] for frame- 1306 level access accuracy. The time code has the format 1308 hours:minutes:seconds:frames.subframes, 1310 with the origin at the start of the clip. The default SMPTE format 1311 is "SMPTE 30 drop" format, with frame rate is 29.97 frames per 1312 second. Other SMPTE codes MAY be supported (such as "SMPTE 25") 1313 through the use of "smpte-type". For SMPTE 30, the "frames" field in 1314 the time value can assume the values 0 through 29. The difference 1315 between 30 and 29.97 frames per second is handled by dropping the 1316 first two frame indices (values 00 and 01) of every minute, except 1317 every tenth minute. If the frame and the subframe values are zero, 1318 they may be omitted. Subframes are measured in one-hundredth of a 1319 frame. 1321 Examples: 1323 smpte=10:12:33:20- 1324 smpte=10:07:33- 1325 smpte=10:07:00-10:07:33:05.01 1326 smpte-25=10:07:00-10:07:33:05.01 1328 4.4.2. Normal Play Time 1330 Normal play time (NPT) indicates the stream absolute position 1331 relative to the beginning of the presentation. The timestamp 1332 consists of two parts: the mandatory first part may be expressed in 1333 either seconds or hours, minutes, and seconds. The optional second 1334 part consists of a decimal point and decimal figures and indicates 1335 fractions of a second. 1337 The beginning of a presentation corresponds to 0.0 seconds. Negative 1338 values are not defined. 1340 The special constant "now" is defined as the current instant of a 1341 live event. It MAY only be used for live events, and MUST NOT be 1342 used for on-demand (i.e., non-live) content. 1344 NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is 1345 the clock the viewer associates with a program. It is often 1346 digitally displayed on a VCR. NPT advances normally when in normal 1347 play mode (scale = 1), advances at a faster rate when in fast scan 1348 forward (high positive scale ratio), decrements when in scan reverse 1349 (negative scale ratio) and is fixed in pause mode. NPT is 1350 (logically) equivalent to SMPTE time codes." 1352 Examples: 1354 npt=123.45-125 1355 npt=12:05:35.3- 1356 npt=now- 1358 The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the 1359 time elapsed since presentation start, with two different notations 1360 allowed: 1362 o The npt-hhmmss notation uses an ISO 8601 extended complete 1363 representation of the time of the day format (Section 5.3.1.1 of 1364 [ISO.8601.2000] ) using colon (":") as separators between hours, 1365 minutes and seconds (hh:mm:ss). The hour counter is not limited 1366 to 0-24 hours; up to nineteen (19) digits of hours are allowed. 1368 o In accordance with the requirements of the ISO 8601 time format, 1369 the hours, minutes, and seconds MUST all be present, with two 1370 digits used for minutes and for seconds, and with a least two 1371 digits for hours. An NPT of 7 minutes and 0 seconds is 1372 represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 1373 6 seconds is represented as "392:00:06". 1375 o RTSP 1.0 allowed NPT in the npt-hhmmss notation without any 1376 leading zeros, to ensure that implementations doesn't fail if any 1377 implementation follows the RTSP 1.0 format, all implementations 1378 are REQUIRED to support receiving NPT values, hours, minutes or 1379 seconds, without leading zeros. 1381 o The npt-sec notation expresses the time in seconds, using between 1382 one and nineteen (19) digits. 1384 Both notations allow decimal fractions of seconds as specified in 1385 Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and 1386 allowing only "." (full stop) as the decimal separator. 1388 The npt-sec notation is optimized for automatic generation, the npt- 1389 hhmmss notation for consumption by human readers. The "now" constant 1390 allows clients to request to receive the live feed rather than the 1391 stored or time-delayed version. This is needed since neither 1392 absolute time nor zero time are appropriate for this case. 1394 4.4.3. Absolute Time 1396 Absolute time is expressed following a specific types of ISO 8601 1397 [ISO.8601.2000] based timestamps. The date is complete 1398 representation calendar date in basic format (YYYYMMDD) without 1399 separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day 1400 is provided in the complete representation basic format (hhmmss) as 1401 specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal 1402 fractions of seconds following Section 5.3.1.3 requiring "." (full 1403 stop) as decimal separator and limiting the number of digits to no 1404 more than nine (9). The time expressed MUST be using UTC (GMT), i.e. 1405 no timezone offsets allowed. The full date and time specification is 1406 the eight digit date followed by a "T" followed by the six digits 1407 time value, optionally followed by a full stop followed by one to 1408 nine fractions of a second and ended by "Z", e.g. 1409 YYYYMMDDThhmmss.ssZ. 1411 The reason for this time format rather than using "Date and Time 1412 on the Internet: Timestamps" [RFC3339] are historic and using the 1413 format specified in RTSP 1.0. The motivations raised in RFC 3339 1414 applies to why a selection from ISO 8601 was done, but a different 1415 and even more restrictive selection was applied in this case. 1417 Example for clock format range request for a starting time of 1418 November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC 1419 playing for 10 min and 5 seconds, a Media-Properties header's "Time- 1420 Limited UTC property for 24th of December 2014 at 15 hours and 00 1421 mins, and a Terminate-Readon headers "time" property for 18th of June 1422 2013 at 16 hours, 12 minutes and 56 seconds: 1424 clock=19961108T143720.25Z-19961108T144725.25Z 1425 Time-Limited=20141224T1500Z 1426 time=20130618T161256Z 1428 4.5. Feature-Tags 1430 Feature-tags are unique identifiers used to designate features in 1431 RTSP. These tags are used in Require (Section 18.43), Proxy-Require 1432 (Section 18.37), Proxy-Supported (Section 18.38), Supported 1433 (Section 18.51) and Unsupported (Section 18.55) header fields. 1435 A feature-tag definition MUST indicate which combination of clients, 1436 servers or proxies it applies to. 1438 The creator of a new RTSP feature-tag should either prefix the 1439 feature-tag with a reverse domain name (e.g., 1440 "com.example.mynewfeature" is an apt name for a feature whose 1441 inventor can be reached at "example.com"), or register the new 1442 feature-tag with the Internet Assigned Numbers Authority (IANA) (see 1443 IANA Section 22). 1445 The usage of feature-tags is further described in Section 11 that 1446 deals with capability handling. 1448 4.6. Message Body Tags 1450 Message body tags are opaque strings that are used to compare two 1451 message bodies from the same resource, for example in caches or to 1452 optimize setup after a redirect. Message body tags can be carried in 1453 the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9). 1454 MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]). 1456 A message body tag MUST be unique across all versions of all message 1457 bodies associated with a particular resource. A given message body 1458 tag value MAY be used for message bodies obtained by requests on 1459 different URIs. The use of the same message body tag value in 1460 conjunction with message bodies obtained by requests on different 1461 URIs does not imply the equivalence of those message bodies 1463 Message body tags are used in RTSP to make some methods conditional. 1464 The methods are made conditional through the inclusion of headers; 1465 see "If-Match" (Section 18.24) and "If-None-Match" (Section 18.26). 1466 Note that RTSP message body tags apply to the complete presentation; 1467 i.e., both the presentation description and the individual media 1468 streams. Thus message body tags can be used to verify at setup time 1469 after a redirect that the same session description applies to the 1470 media at the new location using the If-Match header. 1472 4.7. Media Properties 1474 When an RTSP server handles media, it is important to consider the 1475 different properties a media instance for delivery and playback can 1476 have. This specification considers the media properties listed below 1477 in its protocol operations. They are derived from the differences 1478 between a number of supported usages. 1480 On-demand: Media that has a fixed (given) duration that doesn't 1481 change during the life time of the RTSP session and is known at 1482 the time of the creation of the session. It is expected that the 1483 content of the media will not change, even if the representation, 1484 i.e., encoding, quality, etc, may change. Generally one can seek, 1485 i.e., request any range, within the media. 1487 Dynamic On-demand: This is a variation of the on-demand case where 1488 external methods are used to manipulate the actual content of the 1489 media setup for the RTSP session. The main example is a content 1490 defined by a playlist. 1492 Live: Live media represents a progressing content stream (such as 1493 broadcast TV) where the duration may or may not be known. It is 1494 not seekable, only the content presently being delivered can be 1495 accessed. 1497 Live with Recording: A Live stream that is combined with a server- 1498 side capability to store and retain the content of the live 1499 session, and allow for random access delivery within the part of 1500 the already recorded content. The actual behavior of the media 1501 stream is very much dependent on the retention policy for the 1502 media stream; either the server will be able to capture the 1503 complete media stream, or it will have a limitation in how much 1504 will be retained. The media range will dynamically change as the 1505 session progress. For servers with a limited amount of storage 1506 available for recording, there will typically be a sliding window 1507 that moves forward while new data is made available and older data 1508 is discarded. 1510 To cover the above usages, the following media properties with 1511 appropriate values are specified: 1513 4.7.1. Random Access and Seeking 1515 Random Access is the ability to specify and get media delivered 1516 starting from any time instant within the content, an operation 1517 called seeking. The Media-Properties header will indicate the 1518 general capability for a media resource to perform random access: 1520 Random-Access: The media is seekable to any out of a large number of 1521 points within the media. Due to media encoding limitations, a 1522 particular point may not be reachable, but seeking to a point 1523 close by is enabled. A floating point number of seconds may be 1524 provided to express the worst case distance between random access 1525 points. 1527 Beginning-Only: Seeking is only possible to the beginning of the 1528 content. 1530 No-seeking: Seeking is not possible at all. 1532 If random access is possible, as indicated by the Media-Properties 1533 header, the actual behavior policy when seeking can be controlled 1534 using the Seek-Style header (Section 18.47). 1536 4.7.2. Retention 1538 Media may have different retention policies in place that affect the 1539 operation on media. The following different media retention policies 1540 are envisioned and taken into consideration where applicable: 1542 Unlimited: The media will not be removed as long as the RTSP session 1543 is in existence. 1545 Time-Limited: The media will not be removed before the given 1546 wallclock time. After that time it may or may not be available 1547 any more. 1549 Time-Duration: Each individual unit of the media will be retained 1550 for the specified duration. 1552 4.7.3. Content Modifications 1554 There is also the question of how the content may change over time 1555 for a given media resource: 1557 Immutable: The content of the media will not change, even if the 1558 representation, i.e., encoding, quality, etc., may change. 1560 Dynamic: Between explicit updates the media content will not change, 1561 but the content may change due to external methods or triggers, 1562 such as playlists. 1564 Time-Progressing: As time progresses new content will become 1565 available. If the content also is retained it will become longer 1566 as everything between the start point and the point currently 1567 being made available can be accessed. If the media server uses a 1568 sliding window policy for retention, the start point will also 1569 change as time progresses. 1571 4.7.4. Supported Scale Factors 1573 Content often supports only a limited set or range of scales when 1574 delivering the media. To enable the client to know what values or 1575 ranges of scale operations that the whole content or the current 1576 position supports, a media properties attribute for this is defined 1577 which contains a list with the values and/or ranges that are 1578 supported. The attribute is named "Scales". The "Scales" attribute 1579 may be updated at any point in the content due to content consisting 1580 of spliced pieces or content being dynamically updated by out-of-band 1581 mechanisms. 1583 4.7.5. Mapping to the Attributes 1585 This section shows examples of how one would map the above usages to 1586 the properties and their values. 1588 Example of On-demand: Random Access: Random-Access=5.0, Content 1589 Modifications: Immutable, Retention: Unlimited or Time-Limited. 1591 Example of Dynamic On-demand: Random Access: Random-Access=3.0, 1592 Content Modifications: Dynamic, Retention: Unlimited or Time- 1593 Limited. 1595 Example of Live: Random Access: No-seeking, Content Modifications: 1596 Time-Progressing, Retention: Time-Duration=0.0 1598 Example of Live with Recording: Random Access: Random-Access=3.0, 1599 Content Modifications: Time-Progressing, Retention: Time- 1600 Duration=7200.0 1602 5. RTSP Message 1604 RTSP is a text-based protocol and uses the ISO 10646 character set in 1605 UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. 1607 Text-based protocols make it easier to add optional parameters in 1608 a self-describing manner. Since the number of parameters and the 1609 frequency of commands is low, processing efficiency is not a 1610 concern. Text-based protocols, if done carefully, also allow easy 1611 implementation of research prototypes in scripting languages such 1612 as TCL, Visual Basic and Perl. 1614 The ISO 10646 character set avoids character set switching, but is 1615 invisible to the application as long as US-ASCII is being used. This 1616 is also the encoding used for RTCP [RFC3550]. 1618 A request contains a method, the object the method is operating upon, 1619 and parameters to further describe the method. Methods are 1620 idempotent unless otherwise noted. Methods are also designed to 1621 require little or no state maintenance at the media server. 1623 5.1. Message Types 1625 RTSP messages are either requests from client to server, or server to 1626 client, and responses in the reverse direction. Request (Section 7) 1627 and Response (Section 8) messages use a format based on the generic 1628 message format of RFC 5322 [RFC5322] for transferring bodies (the 1629 payload of the message). Both types of messages consist of a start- 1630 line, zero or more header fields (also known as "headers"), an empty 1631 line (i.e., a line with nothing preceding the CRLF) indicating the 1632 end of the headers, and possibly the data of the message body. The 1633 below ABNF [RFC5234] is for information and the formal message 1634 specification is present in Section 20.2.2. 1636 generic-message = start-line 1637 *(rtsp-header CRLF) 1638 CRLF 1639 [ message-body-data ] 1640 start-line = Request-Line | Status-Line 1642 In the interest of robustness, agents MUST ignore any empty line(s) 1643 received where a Request-Line or Response-Line is expected. In other 1644 words, if the agent is reading the protocol stream at the beginning 1645 of a message and receives a CRLF first, it MUST ignore the CRLF. 1647 5.2. Message Headers 1649 RTSP header fields (see Section 18) include general-header, request- 1650 header, response-header, and message-body header fields. 1652 The order in which header fields with differing field names are 1653 received is not significant. However, it is "good practice" to send 1654 general-header fields first, followed by request-header or response- 1655 header fields, and ending with the Message-body header fields. 1657 Multiple header fields with the same field-name MAY be present in a 1658 message if and only if the entire field-value for that header field 1659 is defined as a comma-separated list. It MUST be possible to combine 1660 the multiple header fields into one "field-name: field-value" pair, 1661 without changing the semantics of the message, by appending each 1662 subsequent field-value to the first, each separated by a comma. The 1663 order in which header fields with the same field-name are received is 1664 therefore significant to the interpretation of the combined field 1665 value, and thus a proxy MUST NOT change the order of these field 1666 values when a message is forwarded. 1668 Unknown message headers MUST be ignored (skipping over the header to 1669 the next protocol element, and not causing an error) by a RTSP server 1670 or client. An RTSP Proxy MUST forward unknown message headers. 1671 Message headers defined outside of this specification that are 1672 required to be interpreted by the RTSP agent will need to use feature 1673 tags (Section 4.5) and include them in the appropriate Require 1674 (Section 18.43) or Proxy-Require (Section 18.37) header. 1676 5.3. Message Body 1678 The message body (if any) of an RTSP message is used to carry further 1679 information for a particular resource associated with the request or 1680 response. An example of a message body is a Session Description 1681 Protocol (SDP) message. 1683 The presence of a message body in either a request or a response MUST 1684 be signaled by the inclusion of a Content-Length header (see 1685 Section 18.17) and Content-Type (see Section 18.19). A message body 1686 MUST NOT be included in a request or response if the specification of 1687 the particular method (see Method Definitions (Section 13)) does not 1688 allow sending a message body. In case a message body is received in 1689 a message when not expected the message body data SHOULD be 1690 discarded. This is to allow future extensions to define optional use 1691 of a message body. 1693 5.4. Message Length 1695 An RTSP Message that does not contain any message body is terminated 1696 by the first empty line after the header fields (Note: An empty line 1697 is a line with nothing preceding the CRLF.). In RTSP messages that 1698 contain message bodies the empty line is followed by the message 1699 body. The length of that body is determined by the value of the 1700 Content-Length header (Section 18.17). The value in the header 1701 represents the length of the message-body in octets. If this header 1702 field is not present, a value of zero is assumed, i.e., no message 1703 body present in the message. Unlike an HTTP message, an RTSP message 1704 MUST contain a Content-Length header whenever it contains a message 1705 body. Note that RTSP does not support the HTTP/1.1 "chunked" 1706 transfer coding (see [H3.6.1]). 1708 Given the moderate length of presentation descriptions returned, 1709 the server should always be able to determine its length, even if 1710 it is generated dynamically, making the chunked transfer encoding 1711 unnecessary. 1713 6. General Header Fields 1715 General headers are headers that may be used in both requests and 1716 responses. The general-headers are listed in Table 1: 1718 +--------------------+--------------------+ 1719 | Header Name | Defined in Section | 1720 +--------------------+--------------------+ 1721 | Accept-Ranges | Section 18.5 | 1722 | | | 1723 | Cache-Control | Section 18.11 | 1724 | | | 1725 | Connection | Section 18.12 | 1726 | | | 1727 | CSeq | Section 18.20 | 1728 | | | 1729 | Date | Section 18.21 | 1730 | | | 1731 | Media-Properties | Section 18.29 | 1732 | | | 1733 | Media-Range | Section 18.30 | 1734 | | | 1735 | Pipelined-Requests | Section 18.33 | 1736 | | | 1737 | Proxy-Supported | Section 18.38 | 1738 | | | 1739 | Range | Section 18.40 | 1740 | | | 1741 | RTP-Info | Section 18.45 | 1742 | | | 1743 | Scale | Section 18.46 | 1744 | | | 1745 | Seek-Style | Section 18.47 | 1746 | | | 1747 | Server | Section 18.48 | 1748 | | | 1749 | Session | Section 18.49 | 1750 | | | 1751 | Speed | Section 18.50 | 1752 | | | 1753 | Supported | Section 18.51 | 1754 | | | 1755 | Timestamp | Section 18.53 | 1756 | | | 1757 | Transport | Section 18.54 | 1758 | | | 1759 | User-Agent | Section 18.56 | 1760 | | | 1761 | Via | Section 18.57 | 1762 +--------------------+--------------------+ 1764 Table 1: The general headers used in RTSP 1766 7. Request 1768 A request message uses the format outlined below regardless of the 1769 direction of a request, client to server or server to client: 1771 o Request line, containing the method to be applied to the resource, 1772 the identifier of the resource, and the protocol version in use; 1774 o Zero or more Header lines, that can be of the following types: 1775 general-headers (Section 6), request-headers (Section 7.2), or 1776 message body headers (Section 9.1); 1778 o One empty line (CRLF) to indicate the end of the header section; 1780 o Optionally a message-body, consisting of one or more lines. The 1781 length of the message body in octets is indicated by the Content- 1782 Length message header. 1784 7.1. Request Line 1786 The request line provides the key information about the request: what 1787 method, on what resources and using which RTSP version. The methods 1788 that are defined by this specification are listed in Table 2. 1790 +---------------+--------------------+ 1791 | Method | Defined in Section | 1792 +---------------+--------------------+ 1793 | DESCRIBE | Section 13.2 | 1794 | | | 1795 | GET_PARAMETER | Section 13.8 | 1796 | | | 1797 | OPTIONS | Section 13.1 | 1798 | | | 1799 | PAUSE | Section 13.6 | 1800 | | | 1801 | PLAY | Section 13.4 | 1802 | | | 1803 | PLAY_NOTIFY | Section 13.5 | 1804 | | | 1805 | REDIRECT | Section 13.10 | 1806 | | | 1807 | SETUP | Section 13.3 | 1808 | | | 1809 | SET_PARAMETER | Section 13.9 | 1810 | | | 1811 | TEARDOWN | Section 13.7 | 1812 +---------------+--------------------+ 1814 Table 2: The RTSP Methods 1816 The syntax of the RTSP request line is the following: 1818 SP SP CRLF 1820 Note: This syntax cannot be freely changed in future versions of 1821 RTSP. This line needs to remain parsable by older RTSP 1822 implementations since it indicates the RTSP version of the message. 1824 In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the 1825 resource through an absolute RTSP URI (including scheme, host, and 1826 port) (see Section 4.2) rather than just the absolute path. 1828 HTTP/1.1 requires servers to understand the absolute URI, but 1829 clients are supposed to use the Host request-header. This is 1830 purely needed for backward-compatibility with HTTP/1.0 servers, a 1831 consideration that does not apply to RTSP. 1833 An asterisk "*" can be used instead of an absolute URI in the 1834 Request-URI part to indicate that the request does not apply to a 1835 particular resource, but to the server or proxy itself, and is only 1836 allowed when the request method does not necessarily apply to a 1837 resource. 1839 For example: 1841 OPTIONS * RTSP/2.0 1843 An OPTIONS in this form will determine the capabilities of the server 1844 or the proxy that first receives the request. If the capability of 1845 the specific server needs to be determined, without regard to the 1846 capability of an intervening proxy, the server should be addressed 1847 explicitly with an absolute URI that contains the server's address. 1849 For example: 1851 OPTIONS rtsp://example.com RTSP/2.0 1853 7.2. Request Header Fields 1855 The RTSP headers in Table 3 can be included in a request, as request- 1856 headers, to modify the specifics of the request. 1858 +---------------------+--------------------+ 1859 | Header | Defined in Section | 1860 +---------------------+--------------------+ 1861 | Accept | Section 18.1 | 1862 | | | 1863 | Accept-Credentials | Section 18.2 | 1864 | | | 1865 | Accept-Encoding | Section 18.3 | 1866 | | | 1867 | Accept-Language | Section 18.4 | 1868 | | | 1869 | Authorization | Section 18.8 | 1870 | | | 1871 | Bandwidth | Section 18.9 | 1872 | | | 1873 | Blocksize | Section 18.10 | 1874 | | | 1875 | From | Section 18.23 | 1876 | | | 1877 | If-Match | Section 18.24 | 1878 | | | 1879 | If-Modified-Since | Section 18.25 | 1880 | | | 1881 | If-None-Match | Section 18.26 | 1882 | | | 1883 | Notify-Reason | Section 18.32 | 1884 | | | 1885 | Proxy-Authorization | Section 18.36 | 1886 | | | 1887 | Proxy-Require | Section 18.37 | 1888 | | | 1889 | Referrer | Section 18.41 | 1890 | | | 1891 | Request-Status | Section 18.42 | 1892 | | | 1893 | Require | Section 18.43 | 1894 | | | 1895 | Terminate-Reason | Section 18.52 | 1896 +---------------------+--------------------+ 1898 Table 3: The RTSP request headers 1900 Detailed header definitions are provided in Section 18. 1902 New request-headers may be defined. If the receiver of the request 1903 is required to understand the request-header, the request MUST 1904 include a corresponding feature tag in a Require or Proxy-Require 1905 header to ensure the processing of the header. 1907 8. Response 1909 After receiving and interpreting a request message, the recipient 1910 responds with an RTSP response message. Normally, there is only one, 1911 final, response. Only responses using the response code class 1xx, 1912 are allowed to send one or more 1xx response messages prior to the 1913 final response message. 1915 The valid response codes and the methods they can be used with are 1916 listed in Table 4. 1918 8.1. Status-Line 1920 The first line of a Response message is the Status-Line, consisting 1921 of the protocol version followed by a numeric status code and the 1922 textual phrase associated with the status code, with each element 1923 separated by SP characters. No CR or LF is allowed except in the 1924 final CRLF sequence. 1926 SP SP CRLF 1928 8.1.1. Status Code and Reason Phrase 1930 The Status-Code element is a 3-digit integer result code of the 1931 attempt to understand and satisfy the request. These codes are fully 1932 defined in Section 17. The Reason-Phrase is intended to give a short 1933 textual description of the Status-Code. The Status-Code is intended 1934 for use by automata and the Reason-Phrase is intended for the human 1935 user. The client is not required to examine or display the Reason- 1936 Phrase. 1938 The first digit of the Status-Code defines the class of response. 1939 The last two digits do not have any categorization role. There are 5 1940 values for the first digit: 1942 1xx: Informational - Request received, continuing process 1944 2xx: Success - The action was successfully received, understood, and 1945 accepted 1947 3rr: Redirection - Further action needs to be taken in order to 1948 complete the request (3rr rather than 3xx is used as 304 is 1949 excluded, see Section 17.3) 1951 4xx: Client Error - The request contains bad syntax or cannot be 1952 fulfilled 1954 5xx: Server Error - The server failed to fulfill an apparently valid 1955 request 1957 The individual values of the numeric status codes defined for RTSP/ 1958 2.0, and an example set of corresponding Reason-Phrases, are 1959 presented in Table 4. The reason phrases listed here are only 1960 recommended; they may be replaced by local equivalents without 1961 affecting the protocol. Note that RTSP adopts most HTTP/1.1 1962 [RFC2616] status codes and adds RTSP-specific status codes starting 1963 at x50 to avoid conflicts with future HTTP status codes that are 1964 desirable to import into RTSP. All these codes are RTSP specific and 1965 RTSP has its own registry separate from HTTP for status codes. 1967 RTSP status codes are extensible. RTSP applications are not required 1968 to understand the meaning of all registered status codes, though such 1969 understanding is obviously desirable. However, applications MUST 1970 understand the class of any status code, as indicated by the first 1971 digit, and treat any unrecognized response as being equivalent to the 1972 x00 status code of that class, with an exception for unknown 3xx 1973 codes, which MUST be treated as a 302 (Found). The reason being that 1974 no 300 (Multiple Choices in HTTP) is defined for RTSP. An response 1975 with an unrecognized status code MUST NOT be cached. For example, if 1976 an unrecognized status code of 431 is received by the client, it can 1977 safely assume that there was something wrong with its request and 1978 treat the response as if it had received a 400 status code. In such 1979 cases, user agents SHOULD present to the user the message body 1980 returned with the response, since that message body is likely to 1981 include human-readable information which will explain the unusual 1982 status. 1984 +------+---------------------------------+--------------------------+ 1985 | Code | Reason | Method | 1986 +------+---------------------------------+--------------------------+ 1987 | 100 | Continue | all | 1988 | | | | 1989 | | | | 1990 | | | | 1991 | 200 | OK | all | 1992 | | | | 1993 | | | | 1994 | | | | 1995 | 301 | Moved Permanently | all | 1996 | | | | 1997 | 302 | Found | all | 1998 | | | | 1999 | 303 | reserved | n/a | 2000 | | | | 2001 | 304 | Not Modified | all | 2002 | | | | 2003 | 305 | Use Proxy | all | 2004 | | | | 2005 | | | | 2006 | | | | 2007 | 400 | Bad Request | all | 2008 | | | | 2009 | 401 | Unauthorized | all | 2010 | | | | 2011 | 402 | Payment Required | all | 2012 | | | | 2013 | 403 | Forbidden | all | 2014 | | | | 2015 | 404 | Not Found | all | 2016 | | | | 2017 | 405 | Method Not Allowed | all | 2018 | | | | 2019 | 406 | Not Acceptable | all | 2020 | | | | 2021 | 407 | Proxy Authentication Required | all | 2022 | | | | 2023 | 408 | Request Timeout | all | 2024 | | | | 2025 | 410 | Gone | all | 2026 | | | | 2027 | 412 | Precondition Failed | DESCRIBE, SETUP | 2028 | | | | 2029 | 413 | Request Message Body Too Large | all | 2030 | | | | 2031 | 414 | Request-URI Too Long | all | 2032 | | | | 2033 | 415 | Unsupported Media Type | all | 2034 | | | | 2035 | 451 | Parameter Not Understood | SET_PARAMETER, | 2036 | | | GET_PARAMETER | 2037 | | | | 2038 | 452 | reserved | n/a | 2039 | | | | 2040 | 453 | Not Enough Bandwidth | SETUP | 2041 | | | | 2042 | 454 | Session Not Found | all | 2043 | | | | 2044 | 455 | Method Not Valid In This State | all | 2045 | | | | 2046 | 456 | Header Field Not Valid | all | 2047 | | | | 2048 | 457 | Invalid Range | PLAY, PAUSE | 2049 | | | | 2050 | 458 | Parameter Is Read-Only | SET_PARAMETER | 2051 | | | | 2052 | 459 | Aggregate Operation Not Allowed | all | 2053 | | | | 2054 | 460 | Only Aggregate Operation | all | 2055 | | Allowed | | 2056 | | | | 2057 | 461 | Unsupported Transport | all | 2058 | | | | 2059 | 462 | Destination Unreachable | all | 2060 | | | | 2061 | 463 | Destination Prohibited | SETUP | 2062 | | | | 2063 | 464 | Data Transport Not Ready Yet | PLAY | 2064 | | | | 2065 | 465 | Notification Reason Unknown | PLAY_NOTIFY | 2066 | | | | 2067 | 466 | Key Management Error | all | 2068 | | | | 2069 | 470 | Connection Authorization | all | 2070 | | Required | | 2071 | | | | 2072 | 471 | Connection Credentials not | all | 2073 | | accepted | | 2074 | | | | 2075 | 472 | Failure to establish secure | all | 2076 | | connection | | 2077 | | | | 2078 | | | | 2079 | | | | 2080 | 500 | Internal Server Error | all | 2081 | | | | 2082 | 501 | Not Implemented | all | 2083 | | | | 2084 | 502 | Bad Gateway | all | 2085 | | | | 2086 | 503 | Service Unavailable | all | 2087 | | | | 2088 | 504 | Gateway Timeout | all | 2089 | | | | 2090 | 505 | RTSP Version Not Supported | all | 2091 | | | | 2092 | 551 | Option Not Supported | all | 2093 | | | | 2094 | 553 | Proxy Unavailable | all | 2095 +------+---------------------------------+--------------------------+ 2097 Table 4: Status codes and their usage with RTSP methods 2099 8.2. Response Headers 2101 The response-headers allow the request recipient to pass additional 2102 information about the response which cannot be placed in the Status- 2103 Line. This header gives information about the server and about 2104 further access to the resource identified by the Request-URI. All 2105 headers currently classified as response-headers are listed in 2106 Table 5. 2108 +------------------------+--------------------+ 2109 | Header | Defined in Section | 2110 +------------------------+--------------------+ 2111 | Authentication-Info | Section 18.7 | 2112 | | | 2113 | Connection-Credentials | Section 18.13 | 2114 | | | 2115 | Location | Section 18.28 | 2116 | | | 2117 | MTag | Section 18.31 | 2118 | | | 2119 | Proxy-Authenticate | Section 18.34 | 2120 | | | 2121 | Public | Section 18.39 | 2122 | | | 2123 | Retry-After | Section 18.44 | 2124 | | | 2125 | Unsupported | Section 18.55 | 2126 | | | 2127 | WWW-Authenticate | Section 18.58 | 2128 +------------------------+--------------------+ 2130 Table 5: The RTSP response headers 2132 Response-header names can be extended reliably only in combination 2133 with a change in the protocol version. However, the usage of 2134 feature-tags in the request allows the responding party to learn the 2135 capability of the receiver of the response. A new or experimental 2136 header can be given the semantics of response-header if all parties 2137 in the communication recognize them to be a response-header. 2138 Unrecognized headers in responses MUST be ignored. 2140 9. Message Body 2142 Some Request and Response messages include a message body, if not 2143 otherwise restricted by the request method or response status code. 2144 The message body consists of the content data itself (see also 2145 Section 5.3). 2147 The SET_PARAMETER and GET_PARAMETER requests and responses, and the 2148 DESCRIBE response as defined by this specification can have a message 2149 body; the purpose of the message body is defined in each case. All 2150 4xx and 5xx responses MAY also have a message body to carry 2151 additional response information. Generally a message body MAY be 2152 attached to any RTSP 2.0 request or response, but the content of the 2153 message body MAY be ignored by the receiver. Extensions to this 2154 specification can specify the purpose and content of message bodies, 2155 including requiring their inclusion. 2157 In this section, both sender and recipient refer to either the client 2158 or the server, depending on who sends and who receives the message 2159 body. 2161 9.1. Message-Body Header Fields 2163 Message-body header fields define meta-information about the content 2164 data in the message body. The message-body header fields are listed 2165 in Table 6. 2167 +------------------+--------------------+ 2168 | Header | Defined in Section | 2169 +------------------+--------------------+ 2170 | Allow | Section 18.6 | 2171 | | | 2172 | Content-Base | Section 18.14 | 2173 | | | 2174 | Content-Encoding | Section 18.15 | 2175 | | | 2176 | Content-Language | Section 18.16 | 2177 | | | 2178 | Content-Length | Section 18.17 | 2179 | | | 2180 | Content-Location | Section 18.18 | 2181 | | | 2182 | Content-Type | Section 18.19 | 2183 | | | 2184 | Expires | Section 18.22 | 2185 | | | 2186 | Last-Modified | Section 18.27 | 2187 +------------------+--------------------+ 2189 Table 6: The RTSP message-body headers 2191 The extension-header mechanism allows additional message-body header 2192 fields to be defined without changing the protocol, but these fields 2193 cannot be assumed to be recognizable by the recipient. Unrecognized 2194 header fields MUST be ignored by the recipient and forwarded by 2195 proxies. 2197 9.2. Message Body 2199 An RTSP message with a message body MUST include the Content-Type and 2200 Content-Length headers. When a message body is included with a 2201 message, the data type of that content data is determined via the 2202 header fields Content-Type and Content-Encoding. 2204 Content-Type specifies the media type of the underlying data. 2205 Content-Encoding may be used to indicate any additional content 2206 codings applied to the data, usually for the purpose of data 2207 compression, that are a property of the requested resource. The 2208 default encoding is 'identity', i.e. no transformation of the message 2209 body. 2211 The Content-Length of a message is the length of the content, 2212 measured in octets. 2214 9.3. Message Body Format Negotiation 2216 The content format of the message body is provided using the Content- 2217 Type header (Section 18.19). To enable the responder of a request to 2218 determine which media type it should use, the requestor may include 2219 the Accept header (Section 18.1) in a request to identify supported 2220 media types or media type ranges suitable to the response. In case 2221 the responder is not supporting any of the specified formats, then 2222 the request response will be a 406 (Not Acceptable) error code. 2224 The media types that may be used on requests with message bodies need 2225 to be determined through the use of feature-tags, specification 2226 requirement or trial and error. Trial and error works because when 2227 the responder does not support the media type of the message body it 2228 will respond with a 415 (Unsupported Media Type). 2230 The formats supported and their negotiation is done individually on a 2231 per method and direction (request or response body) direction. 2232 Requirements on supporting particular media types for use as message 2233 bodies in requests and response SHALL also be specified on per method 2234 and direction basis. 2236 10. Connections 2238 RTSP Messages are transferred between RTSP agents and proxies using a 2239 transport connection. This transport connection uses TCP or TCP/TLS. 2240 This transport connection is referred to as the 'connection' or 'RTSP 2241 connection' within this document. 2243 RTSP requests can be transmitted using the two different connection 2244 scenarios listed below: 2246 o persistent - a transport connection is used for several request/ 2247 response transactions; 2249 o transient - a transport connection is used for each single request 2250 /response transaction. 2252 RFC 2326 attempted to specify an optional mechanism for transmitting 2253 RTSP messages in connectionless mode over a transport protocol such 2254 as UDP. However, it was not specified in sufficient detail to allow 2255 for interoperable implementations. In an attempt to reduce 2256 complexity and scope, and due to lack of interest, RTSP 2.0 does not 2257 attempt to define a mechanism for supporting RTSP over UDP or other 2258 connectionless transport protocols. A side-effect of this is that 2259 RTSP requests MUST NOT be sent to multicast groups since no 2260 connection can be established with a specific receiver in multicast 2261 environments. 2263 Certain RTSP headers, such as the CSeq header (Section 18.20), which 2264 may appear to be relevant only to connectionless transport scenarios 2265 are still retained and MUST be implemented according to the 2266 specification. In the case of CSeq, it is quite useful for matching 2267 responses to requests if the requests are pipelined (see Section 12). 2268 It is also useful in proxies for keeping track of the different 2269 requests when aggregating several client requests on a single TCP 2270 connection. 2272 10.1. Reliability and Acknowledgements 2274 Since RTSP messages are transmitted using reliable transport 2275 protocols, they MUST NOT be retransmitted at the RTSP protocol level. 2276 Instead, the implementation must rely on the underlying transport to 2277 provide reliability. The RTSP implementation may use any indication 2278 of reception acknowledgment of the message from the underlying 2279 transport protocols to optimize the RTSP behavior. 2281 If both the underlying reliable transport such as TCP and the RTSP 2282 application retransmit requests, each packet loss or message loss 2283 may result in two retransmissions. The receiver typically cannot 2284 take advantage of the application-layer retransmission since the 2285 transport stack will not deliver the application-layer 2286 retransmission before the first attempt has reached the receiver. 2287 If the packet loss is caused by congestion, multiple 2288 retransmissions at different layers will exacerbate the 2289 congestion. 2291 Lack of acknowledgment of an RTSP request should be handled within 2292 the constraints of the connection timeout considerations described 2293 below (Section 10.4). 2295 10.2. Using Connections 2297 A TCP transport can be used for both persistent connections (for 2298 several message exchanges) and transient connections (for a single 2299 message exchange). Implementations of this specification MUST 2300 support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) 2301 indicates the default port that the server will listen on if the port 2302 is not explicitly given. 2304 In addition to the registered default ports, i.e., 554 (rtsp) and 322 2305 (rtsps), there is an alternative port 8554 registered. This port may 2306 provide some benefits from non-registered ports if a RTSP server is 2307 unable to use the default ports. The benefits may include pre- 2308 configured security policies as well as classifiers in network 2309 monitoring tools. 2311 A RTSP client opening a TCP connection for accessing a particular 2312 resource as identified by a URI uses the IP address and port derived 2313 from the host and port parts of the URI. The IP address is either 2314 the explicit address provided in the URI or any of the addresses 2315 provided when performing A and AAAA record DNS lookups of the host 2316 name in the URI. 2318 A server MUST handle both persistent and transient connections. 2320 Transient connections facilitate mechanisms for fault tolerance. 2321 They also allow for application layer mobility. A server and 2322 client pair that support transient connections can survive the 2323 loss of a TCP connection; e.g., due to a NAT timeout. When the 2324 client has discovered that the TCP connection has been lost, it 2325 can set up a new one when there is need to communicate again. 2327 A persistent connection is RECOMMENDED to be used for all 2328 transactions between the server and client, including messages for 2329 multiple RTSP sessions. However, a persistent connection MAY be 2330 closed after a few message exchanges. For example, a client may use 2331 a persistent connection for the initial SETUP and PLAY message 2332 exchanges in a session and then close the connection. Later, when 2333 the client wishes to send a new request, such as a PAUSE for the 2334 session, a new connection would be opened. This connection may 2335 either be transient or persistent. 2337 An RTSP agent MAY use one connection to handle multiple RTSP sessions 2338 on the same server. The RTSP agent SHALL NOT use more than one 2339 connection per RTSP session at any given point. 2341 Having only one connection in use at any time avoids confusion on 2342 which connection any server to client requests shall be sent on. 2343 Using a single connection for multiple RTSP session also saves 2344 complexity by enabling the server to maintain less state about its 2345 connection resources on the server. Not using more than one 2346 connection at a time for a particular RTSP session avoids wasting 2347 connection resources and allows the server to track only the most 2348 recently used client to server connection for each RTSP session as 2349 being the currently valid server to client connection. 2351 RTSP allows a server to send requests to a client. However, this can 2352 be supported only if a client establishes a persistent connection 2353 with the server. In cases where a persistent connection does not 2354 exist between a server and its client, due to the lack of a signaling 2355 channel the server may be forced to silently discard RTSP messages, 2356 and may even drop an RTSP session without notifying the client. An 2357 example of such a case is when the server desires to send a REDIRECT 2358 request for an RTSP session to the client but is not able to do so 2359 because it cannot reach the client. A server that attempts to send a 2360 request to a client that has no connection currently to the server 2361 SHALL discard the request. 2363 Without a persistent connection between the client and the server, 2364 the media server has no reliable way of reaching the client. 2365 Because the likely failure of server to client established 2366 connections the server will not even attempt establishing any 2367 connection. 2369 Queuing of server to client requests has been considered. However 2370 a security issue exists as to how it might be possible to 2371 authorize a client establishing a new connection as being a 2372 legitimate receiver of a request related to a particular RTSP 2373 session without the client first issuing requests related to the 2374 request. Thus, it would be likely to make any such requests even 2375 more delayed and less useful. 2377 The sending of client and server requests can be asynchronous events. 2378 To avoid deadlock situations both client and server MUST be able to 2379 send and receive requests simultaneously. As an RTSP response may be 2380 queued up for transmission, reception or processing behind the peer 2381 RTSP agent's own requests, all RTSP agents are required to have a 2382 certain capability of handling outstanding messages. A potential 2383 issue is that outstanding requests may timeout despite them being 2384 processed by the peer due to the response being caught in the queue 2385 behind a number of requests that the RTSP agent is processing but 2386 that take some time to complete. To avoid this problem an RTSP agent 2387 is recommended to buffer incoming messages locally so that any 2388 response messages can be processed immediately upon reception. If 2389 responses are separated from requests and directly forwarded for 2390 processing, not only can the result be used immediately, the state 2391 associated with that outstanding request can also be released. 2392 However, buffering a number of requests on the receiving RTSP agent 2393 consumes resources and enables a resource exhaustion attack on the 2394 agent. Therefore this buffer should be limited so that an 2395 unreasonable number of requests or total message size is not allowed 2396 to consume the receiving agent's resources. In most APIs, having the 2397 receiving agent stop reading from the TCP socket will result in TCP's 2398 window being clamped. Thus forcing the buffering onto the sending 2399 agent when the load is larger than expected. However, as both RTSP 2400 message sizes and frequency may be changed in the future by protocol 2401 extensions, an agent should be careful against taking harsher 2402 measurements against a potential attack. When under attack an RTSP 2403 agent can close TCP connections and release state associated with 2404 that TCP connection. 2406 To provide some guidance on what is reasonable the following 2407 guidelines are given. It is RECOMMENDED that: 2409 o an RTSP agent should not have more than 10 outstanding requests 2410 per RTSP session; 2412 o an RTSP agent should not have more than 10 outstanding requests 2413 that are not related to an RTSP session or that are requesting to 2414 create an RTSP session. 2416 In light of the above, it is RECOMMENDED that clients use persistent 2417 connections whenever possible. A client that supports persistent 2418 connections MAY "pipeline" its requests (see Section 12). 2420 RTSP Agents can send requests to multiple different destinations, 2421 either servers or client contexts over the same connection to a 2422 proxy. Then the proxy forks the message to the different 2423 destinations over proxy to agent connections. In these cases when 2424 multiple requests are outstanding the requesting agent MUST be ready 2425 to receive the responses out of order compared to the order they 2426 where sent on the connection. The order between multiple messages 2427 for each destination will be maintained, however, the order between 2428 response from different destinations can be different. 2430 The reason for this is to avoid a head-of-line blocking 2431 sitauation. In a sequence of requests an early outstanding 2432 request may take time to be processed at one destination. 2434 Simultaneously, a response from any other destination that was 2435 later in the sequence of requests, may have arrived at the proxy. 2436 Thus allowing out-of-order responses avoids forcing the proxy to 2437 buffer this response and instead deliver it as soon as possible. 2438 Note, this will not affect the order in which the messages sent to 2439 each separate destination were processed at request destination. 2441 This scenario can occur in two cases involving proxies. The first is 2442 a client issuing requests for sessions on different servers using a 2443 common client to proxy connection. The second is for server to 2444 client requests, like REDIRECT being sent by the server over a common 2445 transport connection the proxy created for its different connecting 2446 clients. 2448 10.3. Closing Connections 2450 The client MAY close a connection at any point when no outstanding 2451 request/response transactions exist for any RTSP session being 2452 managed through the connection. The server, however, SHOULD NOT 2453 close a connection until all RTSP sessions being managed through the 2454 connection have been timed out (Section 18.49). A server SHOULD NOT 2455 close a connection immediately after responding to a session-level 2456 TEARDOWN request for the last RTSP session being controlled through 2457 the connection. Instead, the server should wait for a reasonable 2458 amount of time for the client to receive and act upon the TEARDOWN 2459 response, and initiate the connection closing. The server SHOULD 2460 wait at least 10 seconds after sending the TEARDOWN response before 2461 closing the connection. 2463 This is to ensure that the client has time to issue a SETUP for a 2464 new session on the existing connection after having torn the last 2465 one down. 10 seconds should give the client ample opportunity to 2466 get its message to the server. 2468 A server SHOULD NOT close the connection directly as a result of 2469 responding to a request with an error code. 2471 Certain error responses such as "460 Only Aggregate Operation 2472 Allowed" (Section 17.4.25) are used for negotiating capabilities 2473 of a server with respect to content or other factors. In such 2474 cases, it is inefficient for the server to close a connection on 2475 an error response. Also, such behavior would prevent 2476 implementation of advanced/special types of requests or result in 2477 extra overhead for the client when testing for new features. On 2478 the other hand, keeping connections open after sending an error 2479 response poses a Denial of Service security risk (Section 21). 2481 The server MAY close a connection if it receives an incomplete 2482 message and if the message is not completed within a reasonable 2483 amount of time. It is RECOMMENDED that the server waits at least 10 2484 seconds for the completion of a message or for the next part of the 2485 message to arrive (which is an indication that the transport and the 2486 client are still alive). Servers believing they are under attack or 2487 otherwise starved for resources during that event MAY consider using 2488 a shorter timeout. 2490 If a server closes a connection while the client is attempting to 2491 send a new request, the client will have to close its current 2492 connection, establish a new connection and send its request over the 2493 new connection. 2495 An RTSP message SHOULD NOT be terminated by closing the connection. 2496 Such a message MAY be considered to be incomplete by the receiver and 2497 discarded. An RTSP message is properly terminated as defined in 2498 Section 5. 2500 10.4. Timing Out Connections and RTSP Messages 2502 Receivers of a request (responder) SHOULD respond to requests in a 2503 timely manner even when a reliable transport such as TCP is used. 2504 Similarly, the sender of a request (requester) SHOULD wait for a 2505 sufficient time for a response before concluding that the responder 2506 will not be acting upon its request. 2508 A responder SHOULD respond to all requests within 5 seconds. If the 2509 responder recognizes that processing of a request will take longer 2510 than 5 seconds, it SHOULD send a 100 (Continue) response as soon as 2511 possible. It SHOULD continue sending a 100 response every 5 seconds 2512 thereafter until it is ready to send the final response to the 2513 requester. After sending a 100 response, the responder MUST send a 2514 final response indicating the success or failure of the request. 2516 A requester SHOULD wait at least 10 seconds for a response before 2517 concluding that the responder will not be responding to its request. 2518 After receiving a 100 response, the requester SHOULD continue waiting 2519 for further responses. If more than 10 seconds elapses without 2520 receiving any response, the requester MAY assume that the responder 2521 is unresponsive and abort the connection by closing the TCP 2522 connection. 2524 In cases multiple RTSP sessions share the same transport connection, 2525 abandoning a request and closing the connection may have significant 2526 impact on those other sessions. First of all, other RTSP requests 2527 may have become queued up due to the request taking long time to 2528 process. Secondly also those sessions loose the possibility to 2529 receive server to client requests. To mitigate that situation the 2530 RTSP client or server SHOULD establish a new connection and send any 2531 queued up and non-responded requests on this new connection. 2532 Secondly, to ensure that the RTSP server knows which connection that 2533 is valid for a particular RTSP session, the RTSP agent SHOULD send a 2534 keep-alive request, if no other request will be sent immediately for 2535 that RTSP session, for each RTSP session on the old connection. The 2536 keep-alive request will normally be a SET_PARAMETER with a session 2537 header to inform the server that this agent cares about this RTSP 2538 session. 2540 A requester SHOULD wait longer than 10 seconds for a response if it 2541 is experiencing significant transport delays on its connection to the 2542 responder. The requester is capable of determining the round trip 2543 time (RTT) of the request/response cycle using the Timestamp header 2544 (Section 18.53) in any RTSP request. 2546 10 seconds was chosen for the following reasons. It gives TCP 2547 time to perform a couple of retransmissions, even if operating on 2548 default values. It is short enough that users may not abandon the 2549 process themselves. However, it should be noted that 10 seconds 2550 can be aggressive on certain type of networks. The 5 seconds 2551 value for 1xx messages is half the timeout giving a reasonable 2552 chance of successful delivery before timeout happens on the 2553 requester side. 2555 10.5. Showing Liveness 2557 RTSP requires the client to periodically show its liveness to the 2558 server or the server may terminate any session state. Several 2559 different protocol mechanism includes in their usage a liveness proof 2560 from the client. These mechanisms are; RTSP requests with a Session 2561 header to the server; if RTP & RTCP is used for media data transport 2562 and the transport is established the RTCP message proves liveness; or 2563 through any other used media transport protocol capable of indicating 2564 liveness of the RTSP client. It is RECOMMENDED that a client does 2565 not wait to the last second of the timeout before trying to send a 2566 liveness message. The RTSP message may take some time to arrive 2567 safely at the receiver, due to packet loss and TCP retransmissions. 2568 To show liveness between RTSP requests being issued to accomplish 2569 other things, the following mechanisms can be used, in descending 2570 order of preference: 2572 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 2573 RTCP is used to report transport statistics, it will 2574 necessarily also function as a keep-alive. The server can 2575 determine the client by network address and port together with 2576 the fact that the client is reporting on the server's RTP 2577 sender sources (SSRCs). A downside of using RTCP is that it 2578 only gives statistical guarantees of reaching the server. 2579 However, the probability of a false client timeout is so low 2580 that it can be ignored in most cases. For example, assume a 2581 session with 60 seconds timeout and enough bitrate assigned to 2582 RTCP messages to send a message from client to server on 2583 average every 5 seconds. That client has, for a network with 2584 5% packet loss, a probability of failing to confirm liveness 2585 within the timeout interval for that session of 2.4*E-16. 2586 Sessions with shorter timeouts, or much higher packet loss, or 2587 small RTCP bandwidths SHOULD also implement one or more of the 2588 mechanisms below. 2590 SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body 2591 SHOULD NOT be included. This method is the RECOMMENDED RTSP 2592 method to use for a request intended only to perform keep- 2593 alive. Support of SET_PARAMETER is mandatory for RTSP Servers 2594 to ensure clients can use this method. 2596 GET_PARAMETER: When using GET_PARAMETER for keep-alive, a body 2597 SHOULD NOT be included. Dependent on implementation support in 2598 server. Use OPTIONS method to determine if there are method 2599 support or simply try. 2601 OPTIONS: This method is also usable, but it causes the server to 2602 perform more unnecessary processing and results in bigger 2603 responses than necessary for the task. The reason is that the 2604 server needs to determine the capabilities associated with the 2605 media resource to correctly populate the Public and Allow 2606 headers. 2608 The timeout parameter of the Session header (Section 18.49) MAY be 2609 included in a SETUP response, and MUST NOT be included in requests. 2610 The server uses it to indicate to the client how long the server is 2611 prepared to wait between RTSP commands or other signs of life before 2612 closing the session due to lack of activity (see Appendix B). The 2613 timeout is measured in seconds, with a default of 60 seconds. The 2614 length of the session timeout MUST NOT be changed in an established 2615 session. 2617 10.6. Use of IPv6 2619 Explicit IPv6 [RFC2460] support was not present in RTSP 1.0 (RFC 2620 2326). RTSP 2.0 has been updated for explicit IPv6 support. 2621 Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in 2622 URIs and RTSP headers. Although the general URI format envisages 2623 potential future new versions of the literal IP address, usage of any 2624 such new version would require other modifications to the RTSP 2625 specification (e.g. address fields in the Transport header 2626 (Section 18.54)). 2628 10.7. Overload Control 2630 Overload in RTSP can occur when servers and proxies have insufficient 2631 resources to complete the processing of a request. An improper 2632 handling of such an overload situation at proxies and servers can 2633 impact the operation of the RTSP deployment, and probably worsen the 2634 situation. RTSP defines the 503 (Service Unavailable) response 2635 (Section 17.5.4) to let servers and proxies notify requesting proxies 2636 and RTSP clients about an overload situation. In conjunction with 2637 the Retry-After header (Section 18.44) the server or proxy can 2638 indicate the time after which the requesting entity can send another 2639 request to the proxy or server. 2641 There are two scopes of such 503 answers, one for established RTSP 2642 sessions, where the request resulting in the 503 response as well as 2643 the response carries a Session header identifying the session which 2644 is suffering overload. This response only applies to this particular 2645 session. The other scope is the general RTSP server as identified by 2646 the host in the request URL. Such a 503 answer with any Retry-After 2647 header applies to all non-session specific requests to that server, 2648 including SETUP request intended to create a new RTSP session. 2650 Another scope for overload situation exists, which is the RTSP proxy. 2651 To enable an RTSP proxy to signal that it is overloaded, or otherwise 2652 unavailable and can't handle the request, a 553 response code has 2653 been defined with the meaning "Proxy Unavailable". As with servers, 2654 there is a separation in response scopes between requests associated 2655 with existing RTSP sessions, and requests to create new sessions or 2656 general proxy requests. 2658 Simply implementing and using the 503 (Service Unavailable) and 553 2659 (Proxy Unavailable) is not sufficient for properly handling overload 2660 situations. For instance, a simplistic approach would be to send the 2661 503 response with a Retry-After header set to a fixed value. 2662 However, this can cause the situation where multiple RTSP clients 2663 again send requests to a proxy or server at roughly the same time 2664 which may again cause an overload situation, or if the "old" overload 2665 situation is not yet solved, i.e., the length indicated in the Retry- 2666 After header was too short. 2668 An RTSP server or proxy in an overload situation must select the 2669 value of the Retry-After header carefully and bearing in mind its 2670 current load situation. It is REQUIRED to increase the timeout 2671 period in proportion to the current load on the server, i.e., an 2672 increasing workload should result in an increased length of the 2673 indicated unavailability. It is REQUIRED to not send the same value 2674 in the Retry-After header to all requesting proxies and clients, but 2675 to add a variation to the mean value of the Retry-After header. 2677 A more complex case may arise when a load balancing RTSP proxy is in 2678 use, i.e., where an RTSP proxy is used to select amongst a set of 2679 RTSP servers to handle the requests, or when multiple server 2680 addresses are available for a given server name. The proxy or client 2681 may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) 2682 from one of its RTSP servers or proxies, or a TCP timeout (if the 2683 server is even unable to handle the request message). The proxy or 2684 client simply retries the other addresses or configured proxies, but 2685 may also receive a 503 (Service Unavailable) or 553 (Proxy 2686 Unavailable) response or TCP timeouts from those addresses. In such 2687 a situation, where none of the RTSP servers/proxies/addresses can 2688 handle the request, the RTSP agent has to wait before it can send any 2689 new requests to the RTSP server. Any additional request to a 2690 specific address MUST be delayed according to the Retry-After headers 2691 received. For addresses where no response was received or TCP 2692 timeout occurred, an initial wait timer SHOULD be set to 5 seconds. 2693 That timer MUST be doubled for each additional failure to connect or 2694 receive response until the value exceeds 30 minutes when the timers 2695 mean value may be set to 30 minutes. It is REQUIRED to not set the 2696 same value in the timer for each scheduling, but instead to add a 2697 variation to the mean value, resulting in picking a random value 2698 within the range from 0.5 to 1.5 of the mean value. 2700 11. Capability Handling 2702 This section describes the available capability handling mechanism 2703 which allows RTSP to be extended. Extensions to this version of the 2704 protocol are basically done in two ways. First, new headers can be 2705 added. Secondly, new methods can be added. The capability handling 2706 mechanism is designed to handle both cases. 2708 When a method is added, the involved parties can use the OPTIONS 2709 method to discover whether it is supported. This is done by issuing 2710 an OPTIONS request to the other party. Depending on the URI it will 2711 either apply in regards to a certain media resource, the whole server 2712 in general, or simply the next hop. The OPTIONS response MUST 2713 contain a Public header which declares all methods supported for the 2714 indicated resource. 2716 It is not necessary to use OPTIONS to discover support of a method, 2717 as the client could simply try the method. If the receiver of the 2718 request does not support the method it will respond with an error 2719 code indicating the method is either not implemented (501) or does 2720 not apply for the resource (405). The choice between the two 2721 discovery methods depends on the requirements of the service. 2723 Feature-tags are defined to handle functionality additions that are 2724 not new methods. Each feature-tag represents a certain block of 2725 functionality. The amount of functionality that a feature-tag 2726 represents can vary significantly. A feature-tag can for example 2727 represent the functionality a single RTSP header provides. Another 2728 feature-tag can represent much more functionality, such as the 2729 "play.basic" feature-tag (Section 11.1) which represents the minimal 2730 media delivery for playback implementation. 2732 Feature-tags are used to determine whether the client, server or 2733 proxy supports the functionality that is necessary to achieve the 2734 desired service. To determine support of a feature-tag, several 2735 different headers can be used, each explained below: 2737 Supported: This header is used to determine the complete set of 2738 functionality that both client and server have in general and 2739 is not dependent on a specific resource. The intended usage is 2740 to determine before one needs to use a functionality that it is 2741 supported. It can be used in any method, but OPTIONS is the 2742 most suitable one as it at the same time determines all methods 2743 that are implemented. When sending a request the requester 2744 declares all its capabilities by including all supported 2745 feature-tags. This results in the receiver learning the 2746 requester's feature support. The receiver then includes its 2747 set of features in the response. 2749 Proxy-Supported: This header is used similarly to the Supported 2750 header, but instead of giving the supported functionality of 2751 the client or server it provides both the requester and the 2752 responder a view of the common functionality supported in 2753 general by all members of the proxy chain between the two 2754 supports and not dependent on the resource. Proxies are 2755 required to add this header whenever the Supported header is 2756 present, but proxies may also add it independently of the 2757 requester. 2759 Require: This header can be included in any request where the end- 2760 point, i.e., the client or server, is required to understand 2761 the feature to correctly perform the request. This can, for 2762 example, be a SETUP request where the server is required to 2763 understand a certain parameter to be able to set up the media 2764 delivery correctly. Ignoring this parameter would not have the 2765 desired effect and is not acceptable. Therefore the end-point 2766 receiving a request containing a Require MUST negatively 2767 acknowledge any feature that it does not understand and not 2768 perform the request. The response in cases where features are 2769 not supported are 551 (Option Not Supported). Also the 2770 features that are not supported are given in the Unsupported 2771 header in the response. 2773 Proxy-Require: This header has the same purpose and workings as 2774 Require except that it only applies to proxies and not the end- 2775 point. Features that need to be supported by both proxies and 2776 end-points need to be included in both the Require and Proxy- 2777 Require header. 2779 Unsupported: This header is used in a 551 error response, to 2780 indicate which features were not supported. Such a response is 2781 only the result of the usage of the Require and/or Proxy- 2782 Require header where one or more features where not supported. 2783 This information allows the requester to make the best of 2784 situations as it knows which features are not supported. 2786 11.1. Feature Tag: play.basic 2788 An implementation supporting all normative parts of this 2789 specification for the setup and control of playback of media uses the 2790 feature tag "play.basic" to indicate this support. The appendices 2791 (starting with letters), are not part of the functionality include in 2792 the feature tag unless the appendix is explicitly specified in a main 2793 section as being a required appendix. 2795 Note: This feature tag does not mandate any media delivery 2796 protocol, such as RTP. 2798 In RTSP 1.0 there was a minimal implementation section. However, 2799 that was not consistent with the rest of the specification. So 2800 rather than making an attempt to explicitly enumerate the features 2801 for play.basic this specification has to be taken as a whole and 2802 the necessary features normatively defined as being required are 2803 included. 2805 12. Pipelining Support 2807 Pipelining is a general method to improve performance of request 2808 response protocols by allowing the requesting agent to have more than 2809 one request outstanding and send them over the same persistent 2810 connection. For RTSP, where the relative order of requests will 2811 matter, it is important to maintain the order of the requests. 2812 Because of this, the responding agent MUST process the incoming 2813 requests in their sending order. The sending order can be determined 2814 by the CSeq header and its sequence number. For TCP the delivery 2815 order will be the same between two agents, as the sending order. The 2816 processing of the request MUST also have been finished before 2817 processing the next request from the same agent. The responses MUST 2818 be sent in the order the requests were processed. 2820 RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. 2821 The major improvement is to allow all requests involved in setting up 2822 and initiating media delivery to be pipelined after each other. This 2823 is accomplished by the utilization of the Pipelined-Requests header 2824 (see Section 18.33). This header allows a client to request that two 2825 or more requests are processed in the same RTSP session context which 2826 the first request creates. In other words, a client can request that 2827 two or more media streams are set-up and then played without needing 2828 to wait for a single response. This speeds up the initial startup 2829 time for an RTSP session by at least one RTT. 2831 If a pipelined request builds on the successful completion of one or 2832 more prior requests the requester must verify that all requests were 2833 executed as expected. A common example will be two SETUP requests 2834 and a PLAY request. In case one of the SETUP fails unexpectedly, the 2835 PLAY request can still be successfully executed. However, the 2836 resulting presentation will not be as expected by the requesting 2837 client, as only a single media instead of two will be played. In 2838 this case the client can send a PAUSE request, correct the failing 2839 SETUP request and then request it to be played. 2841 13. Method Definitions 2843 The method indicates what is to be performed on the resource 2844 identified by the Request-URI. The method name is case-sensitive. 2845 New methods may be defined in the future. Method names MUST NOT 2846 start with a $ character (decimal 36) and MUST be a token as defined 2847 by the ABNF [RFC5234] in the syntax chapter Section 20. The methods 2848 are summarized in Table 7. 2850 +---------------+-----------+--------+-------------+-------------+ 2851 | method | direction | object | Server req. | Client req. | 2852 +---------------+-----------+--------+-------------+-------------+ 2853 | DESCRIBE | C -> S | P,S | recommended | recommended | 2854 | | | | | | 2855 | GET_PARAMETER | C -> S | P,S | optional | optional | 2856 | | | | | | 2857 | | S -> C | P,S | optional | optional | 2858 | | | | | | 2859 | OPTIONS | C -> S | P,S | required | required | 2860 | | | | | | 2861 | | S -> C | P,S | optional | optional | 2862 | | | | | | 2863 | PAUSE | C -> S | P,S | required | required | 2864 | | | | | | 2865 | PLAY | C -> S | P,S | required | required | 2866 | | | | | | 2867 | PLAY_NOTIFY | S -> C | P,S | required | required | 2868 | | | | | | 2869 | REDIRECT | S -> C | P,S | optional | required | 2870 | | | | | | 2871 | SETUP | C -> S | S | required | required | 2872 | | | | | | 2873 | SET_PARAMETER | C -> S | P,S | required | optional | 2874 | | | | | | 2875 | | S -> C | P,S | optional | optional | 2876 | | | | | | 2877 | TEARDOWN | C -> S | P,S | required | required | 2878 | | | | | | 2879 | | S -> C | P | required | required | 2880 +---------------+-----------+--------+-------------+-------------+ 2882 Table 7: Overview of RTSP methods, their direction, and what objects 2883 (P: presentation, S: stream) they operate on. Further it indicates 2884 if a server or a client implementation are required (mandatory), 2885 recommended or if it is optional to implement the method. 2887 Note on Table 7: GET_PARAMETER is optional. For example, a fully 2888 functional server can be built to deliver media without any 2889 parameters. However, SET_PARAMETER is required, i.e., mandatory 2890 to implement for the server, this is due to its usage for keep- 2891 alive. PAUSE is required because it is the only way of leaving 2892 the Play state without terminating the whole session. 2894 If an RTSP agent does not support a particular method, it MUST return 2895 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 2896 NOT try this method again for the given agent / resource combination. 2897 An RTSP proxy whose main function is to log or audit and not modify 2898 transport or media handling in any way MAY forward RTSP messages with 2899 unknown methods. Note that the proxy still needs to perform the 2900 minimal required processing, like adding the Via header. 2902 13.1. OPTIONS 2904 The semantics of the RTSP OPTIONS method is similar to that of the 2905 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 2906 bi-directional, in that a client can send the request to a server and 2907 vice versa. A client MUST implement the capability to send an 2908 OPTIONS request and a server or a proxy MUST implement the capability 2909 to respond to an OPTIONS request. In addition to this "MUST 2910 implement" functionality, clients, servers and proxies MAY provide 2911 support both for sending OPTIONS requests and generating responses to 2912 the requests. 2914 An OPTIONS request may be issued at any time. Such a request does 2915 not modify the session state. However, it may prolong the session 2916 lifespan (see below). The URI in an OPTIONS request determines the 2917 scope of the request and the corresponding response. If the Request- 2918 URI refers to a specific media resource on a given host, the scope is 2919 limited to the set of methods supported for that media resource by 2920 the indicated RTSP agent. A Request-URI with only the host address 2921 limits the scope to the specified RTSP agent's general capabilities 2922 without regard to any specific media. If the Request-URI is an 2923 asterisk ("*"), the scope is limited to the general capabilities of 2924 the next hop (i.e., the RTSP agent in direct communication with the 2925 request sender). 2927 Regardless of the scope of the request, the Public header MUST always 2928 be included in the OPTIONS response listing the methods that are 2929 supported by the responding RTSP agent. In addition, if the scope of 2930 the request is limited to a media resource, the Allow header MUST be 2931 included in the response to enumerate the set of methods that are 2932 allowed for that resource unless the set of methods completely 2933 matches the set in the Public header. If the given resource is not 2934 available, the RTSP agent SHOULD return an appropriate response code 2935 such as 3rr or 4xx. The Supported header MAY be included in the 2936 request to query the set of features that are supported by the 2937 responding RTSP agent. 2939 The OPTIONS method can be used to keep an RTSP session alive. 2940 However, this is not the preferred way of session keep-alive 2941 signaling, see Section 18.49. An OPTIONS request intended for 2942 keeping alive an RTSP session MUST include the Session header with 2943 the associated session identifier. Such a request SHOULD also use 2944 the media or the aggregated control URI as the Request-URI. 2946 Example: 2948 C->S: OPTIONS rtsp://server.example.com RTSP/2.0 2949 CSeq: 1 2950 User-Agent: PhonyClient/1.2 2951 Proxy-Require: gzipped-messages 2952 Supported: play.basic 2954 S->C: RTSP/2.0 200 OK 2955 CSeq: 1 2956 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS 2957 Supported: play.basic, setup.rtp.rtcp.mux, play.scale 2958 Server: PhonyServer/1.1 2960 Note that some of the feature-tags in Supported and Proxy-Require are 2961 fictitious features. 2963 13.2. DESCRIBE 2965 The DESCRIBE method is used to retrieve the description of a 2966 presentation or media object from a server. The Request-URI of the 2967 DESCRIBE request identifies the media resource of interest. The 2968 client MAY include the Accept header in the request to list the 2969 description formats that it understands. The server MUST respond 2970 with a description of the requested resource and return the 2971 description in the message body of the response, if the DESCRIBE 2972 method request can be successfully fulfilled. The DESCRIBE reply- 2973 response pair constitutes the media initialization phase of RTSP. 2975 The DESCRIBE response SHOULD contain all media initialization 2976 information for the resource(s) that it describes. Servers SHOULD 2977 NOT use the DESCRIBE response as a means of media indirection by 2978 having the description point at another server; instead, using the 2979 3rr responses is RECOMMENDED. 2981 By forcing a DESCRIBE response to contain all media initialization 2982 information for the set of streams that it describes, and 2983 discouraging the use of DESCRIBE for media indirection, any 2984 looping problems can be avoided that might have resulted from 2985 other approaches. 2987 Example: 2989 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 2990 CSeq: 312 2991 User-Agent: PhonyClient/1.2 2992 Accept: application/sdp, application/example 2994 S->C: RTSP/2.0 200 OK 2995 CSeq: 312 2996 Date: Thu, 23 Jan 1997 15:35:06 GMT 2997 Server: PhonyServer/1.1 2998 Content-Base: rtsp://server.example.com/fizzle/foo/ 2999 Content-Type: application/sdp 3000 Content-Length: 358 3002 v=0 3003 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46 3004 s=SDP Seminar 3005 i=A Seminar on the session description protocol 3006 u=http://www.example.com/lectures/sdp.ps 3007 e=seminar@example.com (Seminar Management) 3008 c=IN IP4 0.0.0.0 3009 a=control:* 3010 t=2873397496 2873404696 3011 m=audio 3456 RTP/AVP 0 3012 a=control:audio 3013 m=video 2232 RTP/AVP 31 3014 a=control:video 3016 Media initialization is a requirement for any RTSP-based system, but 3017 the RTSP specification does not dictate that this is required to be 3018 done via the DESCRIBE method. There are three ways that an RTSP 3019 client may receive initialization information: 3021 o via an RTSP DESCRIBE request 3023 o via some other protocol (HTTP, email attachment, etc.) 3025 o via some form of user interface 3027 If a client obtains a valid description from an alternate source, the 3028 client MAY use this description for initialization purposes without 3029 issuing a DESCRIBE request for the same media. The client should use 3030 any MTag to either validate the presentation description or make the 3031 session establishment conditional on being valid. 3033 It is RECOMMENDED that minimal servers support the DESCRIBE method, 3034 and highly recommended that minimal clients support the ability to 3035 act as "helper applications" that accept a media initialization file 3036 from a user interface, and/or other means that are appropriate to the 3037 operating environment of the clients. 3039 13.3. SETUP 3041 The description below uses the following states in a protocol state 3042 machine that is related to a specific session when that session has 3043 been created. The state transitions are driven by protocol 3044 interactions. For additional information about the state machine see 3045 Appendix B. 3047 Init: Initial state: no session exists. 3049 Ready: Session is ready to start playing. 3051 Play: Session is playing, i.e., sending media stream data in the 3052 direction S->C. 3054 The SETUP request for a URI specifies the transport mechanism to be 3055 used for the streamed media. The SETUP method may be used in two 3056 different cases; Create an RTSP session and change the transport 3057 parameters of already set up media stream(s). SETUP can be used in 3058 all three states; Init, and Ready, for both purposes and in PLAY to 3059 change the transport parameters. The usage of SETUP method in the 3060 Play state to add a media resource to the session is unspecified 3061 (Section 3.1). 3063 The Transport header, see Section 18.54, specifies the media 3064 transport parameters acceptable to the client for data transmission; 3065 the response will contain the transport parameters selected by the 3066 server. This allows the client to enumerate in descending order of 3067 preference the transport mechanisms and parameters acceptable to it, 3068 while the server can select the most appropriate. It is expected 3069 that the session description format used will enable the client to 3070 select a limited number of possible configurations that are offered 3071 to the server to choose from. All transport related parameters SHALL 3072 be included in the Transport header; the use of other headers for 3073 this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls 3074 or NATs. 3076 For the benefit of any intervening firewalls, a client MUST indicate 3077 the known transport parameters, even if it has no influence over 3078 these parameters, for example, where the server advertises a fixed 3079 multicast address as destination. 3081 Since SETUP includes all transport initialization information, 3082 firewalls and other intermediate network devices (which need this 3083 information) are spared the more arduous task of parsing the 3084 DESCRIBE response, which has been reserved for media 3085 initialization. 3087 The client MUST include the Accept-Ranges header in the request 3088 indicating all supported unit formats in the Range header. This 3089 allows the server to know which formats it may use in future session 3090 related responses, such as a PLAY response without any range in the 3091 request. If the client does not support a time format necessary for 3092 the presentation, the server MUST respond using 456 (Header Field Not 3093 Valid for Resource) and include the Accept-Ranges header with the 3094 range unit formats supported for the resource. 3096 In a SETUP response the server MUST include the Accept-Ranges header 3097 (see Section 18.5) to indicate which time formats are acceptable to 3098 use for this media resource. 3100 The SETUP response 200 OK MUST include the Media-Properties header 3101 (see Section 18.29 ). The combination of the parameters of the 3102 Media-Properties header indicates the nature of the content present 3103 in the session (see also Section 4.7). For example, a live stream 3104 with time shifting is indicated by 3106 o Random Access set to Random-Access, 3108 o Content Modifications set to Time Progressing, 3110 o Retention set to Time-Duration (with specific recording window 3111 time value). 3113 The SETUP response 200 OK MUST include the Media-Range header (see 3114 Section 18.30) if the media is Time-Progressing. 3116 A basic example for SETUP: 3118 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 3119 CSeq: 302 3120 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 3121 RTP/AVP/TCP;unicast;interleaved=0-1 3122 Accept-Ranges: npt, clock 3123 User-Agent: PhonyClient/1.2 3125 S->C: RTSP/2.0 200 OK 3126 CSeq: 302 3127 Date: Thu, 23 Jan 1997 15:35:06 GMT 3128 Server: PhonyServer/1.1 3129 Session: 47112344;timeout=60 3130 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ 3131 "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ 3132 "198.51.100.241:6257"; ssrc=2A3F93ED 3133 Accept-Ranges: npt 3134 Media-Properties: Random-Access=3.2, Time-Progressing, 3135 Time-Duration=3600.0 3136 Media-Range: npt=0-2893.23 3138 In the above example the client wants to create an RTSP session 3139 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 3140 The transport parameters acceptable to the client are either RTP/AVP/ 3141 UDP (UDP per default) to be received on client port 4588 and 4589 at 3142 the address the RTSP setup connection comes from or RTP/AVP 3143 interleaved on the RTSP control channel. The server selects the RTP/ 3144 AVP/UDP transport and adds the address and ports it will send and 3145 receive RTP and RTCP from, and the RTP SSRC that will be used by the 3146 server. 3148 The server MUST generate a session identifier in response to a 3149 successful SETUP request, unless a SETUP request to a server includes 3150 a session identifier or a Pipelined-Requests header referencing an 3151 existing session context, in which case the server MUST bundle this 3152 SETUP request into the existing session (aggregated session) or 3153 return error 459 (Aggregate Operation Not Allowed) (see 3154 Section 17.4.24). An Aggregate control URI MUST be used to control 3155 an aggregated session. This URI MUST be different from the stream 3156 control URIs of the individual media streams included in the 3157 aggregate (see Section 13.4.2 for aggregated sessions and for the 3158 particular URIs see Appendix D.1.1). The Aggregate control URI is to 3159 be specified by the session description if the server supports 3160 aggregated control and aggregated control is desired for the session. 3161 However, even if aggregated control is offered the client MAY chose 3162 to not set up the session in aggregated control. If an Aggregate 3163 control URI is not specified in the session description, it is 3164 normally an indication that non-aggregated control should be used. 3166 The SETUP of media streams in an aggregate which has not been given 3167 an aggregated control URI is unspecified. 3169 While the session ID sometimes carries enough information for 3170 aggregate control of a session, the Aggregate control URI is still 3171 important for some methods such as SET_PARAMETER where the control 3172 URI enables the resource in question to be easily identified. The 3173 Aggregate control URI is also useful for proxies, enabling them to 3174 route the request to the appropriate server, and for logging, 3175 where it is useful to note the actual resource that a request was 3176 operating on. 3178 A session will exist until it is either removed by a TEARDOWN request 3179 or is timed-out by the server. The server MAY remove a session that 3180 has not demonstrated liveness signs from the client(s) within a 3181 certain timeout period. The default timeout value is 60 seconds; the 3182 server MAY set this to a different value and indicate so in the 3183 timeout field of the Session header in the SETUP response. For 3184 further discussion see Section 18.49. Signs of liveness for an RTSP 3185 session are: 3187 o Any RTSP request from a client which includes a Session header 3188 with that session's ID. 3190 o If RTP is used as a transport for the underlying media streams, an 3191 RTCP sender or receiver report from the client(s) for any of the 3192 media streams in that RTSP session. RTCP Sender Reports may for 3193 example be received in sessions where the server is invited into a 3194 conference session and is valid for keep-alive. 3196 If a SETUP request on a session fails for any reason, the session 3197 state, as well as transport and other parameters for associated 3198 streams MUST remain unchanged from their values as if the SETUP 3199 request had never been received by the server. 3201 13.3.1. Changing Transport Parameters 3203 A client MAY issue a SETUP request for a stream that is already set 3204 up or playing in the session to change transport parameters, which a 3205 server MAY allow. If it does not allow changing of parameters, it 3206 MUST respond with error 455 (Method Not Valid In This State). The 3207 reasons to support changing transport parameters include allowing 3208 application layer mobility and flexibility to utilize the best 3209 available transport as it becomes available. If a client receives a 3210 455 when trying to change transport parameters while the server is in 3211 Play state, it MAY try to put the server in Ready state using PAUSE, 3212 before issuing the SETUP request again. If that also fails the 3213 changing of transport parameters will require that the client 3214 performs a TEARDOWN of the affected media and then to set it up 3215 again. For an aggregated session avoiding tearing down all the media 3216 at the same time will avoid the creation of a new session. 3218 All transport parameters MAY be changed. However, the primary usage 3219 expected is to either change the transport protocol completely, like 3220 switching from Interleaved TCP mode to UDP or vice versa, or to 3221 change the delivery address. 3223 In a SETUP response for a request to change the transport parameters 3224 while in Play state, the server MUST include the Range to indicate at 3225 what point the new transport parameters will be used. Further, if 3226 RTP is used for delivery, the server MUST also include the RTP-Info 3227 header to indicate at what timestamp and RTP sequence number the 3228 change will take place. If both RTP-Info and Range are included in 3229 the response the "rtp_time" parameter and start point in the Range 3230 header MUST be for the corresponding time, i.e., be used in the same 3231 way as for PLAY to ensure the correct synchronization information is 3232 available. 3234 If the transport parameters change while in Play state results in a 3235 change of synchronization related information, for example changing 3236 RTP SSRC, the server MUST provide in the SETUP response the necessary 3237 synchronization information. However, the server is RECOMMENDED to 3238 avoid changing the synchronization information if possible. 3240 13.4. PLAY 3242 This section describes the usage of the PLAY method in general, for 3243 aggregated sessions, and in different usage scenarios. 3245 13.4.1. General Usage 3247 The PLAY method tells the server to start sending data via the 3248 mechanism specified in SETUP and which part of the media should be 3249 played out. PLAY requests are valid when the session is in Ready or 3250 Play states. A PLAY request MUST include a Session header to 3251 indicate which session the request applies to. 3253 Upon receipt of the PLAY request, the server MUST position the normal 3254 play time to the beginning of the range specified in the received 3255 Range header, within the limits of the media resource and in 3256 accordance with the Seek-Style header (Section 18.47) and deliver 3257 stream data until the end of the range if given, until a new PLAY 3258 request is received, or until the end of the media is reached. If no 3259 Range header is present in the PLAY request the server SHALL play 3260 from current pause point until the end of media. The pause point 3261 defaults at session start to the beginning of the media. For media 3262 that is time-progressing and has no retention, the pause point will 3263 always be set equal to NPT "now", i.e., the current delivery point. 3264 The pause point may also be set to a particular point in the media by 3265 the PAUSE method, see Section 13.6. The pause point for media that 3266 is currently playing is equal to the current media position. For 3267 time-progressing media with time-limited retention, if the pause 3268 point represents a position that is older than what is retained by 3269 the server, the pause point will be moved to the oldest retained. 3271 What range values are valid depends on the type of content. For 3272 content that isn't time progressing the range value is valid if the 3273 given range is part of any media within the aggregate. In other 3274 words the valid media range for the aggregate is the union of all of 3275 the media components in the aggregate. If a given range value points 3276 outside of the media, the response MUST be the 457 (Invalid Range) 3277 error code and include the Media-Range header (Section 18.30) with 3278 the valid range for the media. Except for time progressing content 3279 where the client requests a start point prior to what is retained, 3280 the start point is adjusted to the oldest retained content. For a 3281 start point that is beyond the media front edge, i.e., beyond the 3282 current value for "now", the server SHALL adjust the start value to 3283 the current front edge. The Range header's stop point value may 3284 point beyond the current media edge. In that case, the server SHALL 3285 deliver media from the requested (and possibly adjusted) start point 3286 until the provided stop point, or the end of the media is reached 3287 prior to the specified stop point. Please note that if one simply 3288 wants to play from a particular start point until the end of media 3289 using a Range header with an implicit stop point is RECOMMENDED. 3291 If a client requests to start playing at the end of media, either 3292 explicitly with a Range header or implicitly with a pause point that 3293 is at the end of media, a 457 (Invalid Range) error MUST be sent and 3294 include the Media-Range header (Section 18.30). It is specified 3295 below that the Range header also must be included in the response and 3296 that it will carry the pause point in the media, in the case of the 3297 session being in Ready State. Note that this also applies if the 3298 pause point or requested start point is at the beginning of the media 3299 and a Scale header (Section 18.46) is included with a negative value 3300 (playing backwards). 3302 For media with random access properties a client may express its 3303 preference on which policy for start point selection the server shall 3304 use. This is done by including the Seek-Style header (Section 18.47) 3305 in the PLAY request. The Seek-Style applied will affect the content 3306 of the Range header as it will be adjusted to indicate from what 3307 point the media actually is delivered. 3309 A client desiring to play the media from the beginning MUST send a 3310 PLAY request with a Range header pointing at the beginning, e.g., 3311 "npt=0-". If a PLAY request is received without a Range header and 3312 media delivery has stopped at the end, the server SHOULD respond with 3313 a 457 "Invalid Range" error response. In that response, the current 3314 pause point MUST be included in a Range header. 3316 All range specifiers in this specification allow for ranges with an 3317 implicit start point (e.g., "npt=-30"). When used in a PLAY request, 3318 the server treats this as a request to start or resume delivery from 3319 the current pause point, ending at the end time specified in the 3320 Range header. If the pause point is located later than the given end 3321 value, a 457 (Invalid Range) response MUST be given. 3323 The example below will play seconds 10 through 25. It also requests 3324 the server to deliver media from the first Random Access Point prior 3325 to the indicated start point. 3327 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 3328 CSeq: 835 3329 Session: 12345678 3330 Range: npt=10-25 3331 Seek-Style: RAP 3332 User-Agent: PhonyClient/1.2 3334 Servers MUST include a "Range" header in any PLAY response, even if 3335 no Range header was present in the request. The response MUST use 3336 the same format as the request's range header contained. If no Range 3337 header was in the request, the format used in any previous PLAY 3338 request within the session SHOULD be used. If no format has been 3339 indicated in a previous request the server MAY use any time format 3340 supported by the media and indicated in the Accept-Ranges header in 3341 the SETUP request. It is RECOMMENDED that NPT is used if supported 3342 by the media. 3344 For any error response to a PLAY request, the server's response 3345 depends on the current session state. If the session is in Ready 3346 state, the current pause-point is returned using Range header with 3347 the pause point as the explicit start-point and an implicit stop- 3348 point. For time-progressing content where the pause-point moves with 3349 real-time due to limited retention, the current pause point is 3350 returned. For sessions in Play state, the current playout point and 3351 the remaining parts of the range request is returned. For any media 3352 with retention longer than 0 seconds the currently valid Media-Range 3353 header SHALL also be included in the response. 3355 A PLAY response MAY include a header carrying synchronization 3356 information. As the information necessary is dependent on the media 3357 transport format, further rules specifying the header and its usage 3358 are needed. For RTP the RTP-Info header is specified, see 3359 Section 18.45, and used in the following example. 3361 Here is a simple example for a single audio stream where the client 3362 requests the media starting from 3.52 seconds and to the end. The 3363 server sends a 200 OK response with the actual play time which is 10 3364 ms prior (3.51) and the RTP-Info header that contains the necessary 3365 parameters for the RTP stack. 3367 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3368 CSeq: 836 3369 Session: 12345678 3370 Range: npt=3.52- 3371 User-Agent: PhonyClient/1.2 3373 S->C: RTSP/2.0 200 OK 3374 CSeq: 836 3375 Date: Thu, 23 Jan 1997 15:35:06 GMT 3376 Server: PhonyServer/1.0 3377 Range: npt=3.51-324.39 3378 Seek-Style: First-Prior 3379 RTP-Info:url="rtsp://example.com/audio" 3380 ssrc=0D12F123:seq=14783;rtptime=2345962545 3382 S->C: RTP Packet TS=2345962545 => NPT=3.51 3383 Media duration=0.16 seconds 3385 The server replies with the actual start point that will be 3386 delivered. This may differ from the requested range if alignment of 3387 the requested range to valid frame boundaries is required for the 3388 media source. Note that some media streams in an aggregate may need 3389 to be delivered from even earlier points. Also, some media formats 3390 have a very long duration per individual data unit, therefore it 3391 might be necessary for the client to parse the data unit, and select 3392 where to start. The server SHALL also indicate which policy it uses 3393 for selecting the actual start point by including a Seek-Style 3394 header. 3396 In the following example the client receives the first media packet 3397 that stretches all the way up and past the requested playtime. Thus, 3398 it is the client's decision whether to render to the user the time 3399 between 3.52 and 7.05, or to skip it. In most cases it is probably 3400 most suitable not to render that time period. 3402 C->S: PLAY rtsp://example.com/audio RTSP/2.0 3403 CSeq: 836 3404 Session: 12345678 3405 Range: npt=7.05- 3406 User-Agent: PhonyClient/1.2 3408 S->C: RTSP/2.0 200 OK 3409 CSeq: 836 3410 Date: Thu, 23 Jan 1997 15:35:06 GMT 3411 Server: PhonyServer/1.0 3412 Range: npt=3.52- 3413 Seek-Style: First-Prior 3414 RTP-Info:url="rtsp://example.com/audio" 3415 ssrc=0D12F123:seq=14783;rtptime=2345962545 3417 S->C: RTP Packet TS=2345962545 => NPT=3.52 3418 Duration=4.15 seconds 3420 After playing the desired range, the presentation does NOT change to 3421 the Ready state, media delivery simply stops. If it is necessary to 3422 put the stream into the Ready state, a PAUSE request MUST be issued 3423 to do that. A PLAY request while the stream is still in the Play 3424 state is legal, and can be issued without an intervening PAUSE 3425 request. Such a request MUST replace the current PLAY action with 3426 the new one requested, i.e., being handled in the same way as if as 3427 the request was received in Ready state. In the case that the range 3428 in Range header has an implicit start time ("-endtime"), the server 3429 MUST continue to play from where it currently was until the specified 3430 end point. This is useful to change the end to at another point than 3431 in the previous request. 3433 The following example plays the whole presentation starting at SMPTE 3434 time code 0:10:20 until the end of the clip. Note: The RTP-Info 3435 headers has been broken into several lines, where following lines 3436 start with whitespace as allowed by the syntax. 3438 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 3439 CSeq: 833 3440 Session: 12345678 3441 Range: smpte=0:10:20- 3442 User-Agent: PhonyClient/1.2 3444 S->C: RTSP/2.0 200 OK 3445 CSeq: 833 3446 Date: Thu, 23 Jan 1997 15:35:06 GMT 3447 Session: 12345678 3448 Server: PhonyServer/1.0 3449 Range: smpte=0:10:22-0:15:45 3450 Seek-Style: Next 3451 RTP-Info:url="rtsp://example.com/twister.en" 3452 ssrc=0D12F123:seq=14783;rtptime=2345962545 3454 For playing back a recording of a live presentation, it may be 3455 desirable to use clock units: 3457 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 3458 CSeq: 835 3459 Session: 12345678 3460 Range: clock=19961108T142300Z-19961108T143520Z 3461 User-Agent: PhonyClient/1.2 3463 S->C: RTSP/2.0 200 OK 3464 CSeq: 835 3465 Date: Thu, 23 Jan 1997 15:35:06 GMT 3466 Session: 12345678 3467 Server: PhonyServer/1.0 3468 Range: clock=19961108T142300Z-19961108T143520Z 3469 Seek-Style: Next 3470 RTP-Info:url="rtsp://example.com/meeting.en" 3471 ssrc=0D12F123:seq=53745;rtptime=484589019 3473 13.4.2. Aggregated Sessions 3475 PLAY requests can operate on sessions controlling a single media and 3476 on aggregated sessions controlling multiple media. 3478 In an aggregated session the PLAY request MUST contain an aggregated 3479 control URI. A server MUST respond with error 460 (Only Aggregate 3480 Operation Allowed) if the client PLAY Request-URI is for a single 3481 media. The media in an aggregate MUST be played in sync. If a 3482 client wants individual control of the media, it needs to use 3483 separate RTSP sessions for each media. 3485 For aggregated sessions where the initial SETUP request (creating a 3486 session) is followed by one or more additional SETUP requests, a PLAY 3487 request MAY be pipelined after those additional SETUP requests 3488 without awaiting their responses. This procedure can reduce the 3489 delay from start of session establishment until media play-out has 3490 started with one round trip time. However, a client needs to be 3491 aware that using this procedure will result in the playout of the 3492 server state established at the time of processing the PLAY, i.e., 3493 after the processing of all the requests prior to the PLAY request in 3494 the pipeline. This state may not be the intended one due to failure 3495 of any of the prior requests. A client can easily determine this 3496 based on the responses from those requests. In case of failure, the 3497 client can halt the media playout using PAUSE and try to establish 3498 the intended state again before issuing another PLAY request. 3500 13.4.3. Updating current PLAY Requests 3502 Clients can issue PLAY requests while the stream is in Play state and 3503 thus updating their request. 3505 The important difference compared to a PLAY request in Ready state is 3506 the handling of the current play point and how the Range header in 3507 the request is constructed. The session is actively playing media 3508 and the play point will be moving, making the exact time a request 3509 will take effect hard to predict. Depending on how the PLAY header 3510 appears two different cases exist: total replacement or continuation. 3511 A total replacement is signaled by having the first range 3512 specification have an explicit start value, e.g., "npt=45-" or 3513 "npt=45-60", in which case the server stops playout at the current 3514 playout point and then starts delivering media according to the Range 3515 header. This is equivalent to having the client first send a PAUSE 3516 and then a new PLAY request that isn't based on the pause point. In 3517 the case of continuation the first range specifier has an implicit 3518 start point and an explicit stop value (Z), e.g., "npt=-60", which 3519 indicate that it MUST convert the range specifier being played prior 3520 to this PLAY request (X to Y) into (X to Z) and continue as this was 3521 the request originally played. If the current delivery point is 3522 beyond the stop point, the server SHALL immediately pause delivery. 3523 As the request has been completed successfully it shall be responded 3524 with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to 3525 indicate the actual stop point. The pause point is set to the 3526 requested stop point. 3528 Following is an example of this behavior: The server has received 3529 requests to play ranges 10 to 15. If the new PLAY request arrives at 3530 the server 4 seconds after the previous one, it will take effect 3531 while the server still plays the first range (10-15). The server 3532 changes the current play to continue to 25 seconds, i.e., the 3533 equivalent single request would be PLAY with "range: npt=10-25". 3535 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3536 CSeq: 834 3537 Session: 12345678 3538 Range: npt=10-15 3539 User-Agent: PhonyClient/1.2 3541 S->C: RTSP/2.0 200 OK 3542 CSeq: 834 3543 Date: Thu, 23 Jan 1997 15:35:06 GMT 3544 Session: 12345678 3545 Server: PhonyServer/1.0 3546 Range: npt=10-15 3547 Seek-Style: Next 3548 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3549 ssrc=0D12F123:seq=5712;rtptime=934207921, 3550 url="rtsp://example.com/fizzle/videotrack" 3551 ssrc=789DAF12:seq=57654;rtptime=2792482193 3552 Session: 12345678 3554 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3555 CSeq: 835 3556 Session: 12345678 3557 Range: npt=-25 3558 User-Agent: PhonyClient/1.2 3560 S->C: RTSP/2.0 200 OK 3561 CSeq: 835 3562 Date: Thu, 23 Jan 1997 15:35:09 GMT 3563 Session: 12345678 3564 Server: PhonyServer/1.0 3565 Range: npt=14-25 3566 Seek-Style: Next 3567 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3568 ssrc=0D12F123:seq=5712;rtptime=934239921, 3569 url="rtsp://example.com/fizzle/videotrack" 3570 ssrc=789DAF12:seq=57654;rtptime=2792842193 3572 A common use of a PLAY request while in Play state is changing the 3573 scale of the media, i.e., entering or leaving fast forward or fast 3574 rewind. The client can issue an updating PLAY request that is either 3575 a continuation or a complete replacement, as discussed above this 3576 section. Below is an example of a client that is requesting a fast 3577 forward (scale=2) without giving a stop point and then change from 3578 fast forward to regular playout (scale = 1). In the second PLAY 3579 request the time is set explicitly to be where ever the server 3580 currently plays out (npt=now-) and the server responds with the 3581 actual playback point where the new scale actually takes effect 3582 (npt=02:17:27.144-). 3584 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3585 CSeq: 2034 3586 Session: 12345678 3587 Range: npt=now- 3588 Scale: 2.0 3589 User-Agent: PhonyClient/1.2 3591 S->C: RTSP/2.0 200 OK 3592 CSeq: 2034 3593 Date: Thu, 23 Jan 1997 15:35:06 GMT 3594 Session: 12345678 3595 Server: PhonyServer/1.0 3596 Range: npt=02:17:21.394- 3597 Seek-Style: Next 3598 Scale: 2.0 3599 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3600 ssrc=0D12F123:seq=5712;rtptime=934207921, 3601 url="rtsp://example.com/fizzle/videotrack" 3602 ssrc=789DAF12:seq=57654;rtptime=2792482193 3604 [playing in fast forward and now returning to scale = 1] 3606 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 3607 CSeq: 2035 3608 Session: 12345678 3609 Range: npt=now- 3610 Scale: 1.0 3611 User-Agent: PhonyClient/1.2 3613 S->C: RTSP/2.0 200 OK 3614 CSeq: 2035 3615 Date: Thu, 23 Jan 1997 15:35:09 GMT 3616 Session: 12345678 3617 Server: PhonyServer/1.0 3618 Range: npt=02:17:27.144- 3619 Seek-Style: Next 3620 Scale: 1.0 3621 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 3622 ssrc=0D12F123:seq=5712;rtptime=934239921, 3623 url="rtsp://example.com/fizzle/videotrack" 3624 ssrc=789DAF12:seq=57654;rtptime=2792842193 3626 13.4.4. Playing On-Demand Media 3628 On-demand media is indicated by the content of the Media-Properties 3629 header in the SETUP response by (see also Section 18.29): 3631 o Random Access property is set to Random-Access; 3633 o Content Modifications set to Immutable; 3635 o Retention set to Unlimited or Time-Limited. 3637 Playing on-demand media follows the general usage as described in 3638 Section 13.4.1. 3640 13.4.5. Playing Dynamic On-Demand Media 3642 Dynamic on-demand media is indicated by the content of the Media- 3643 Properties header in the SETUP response by (see also Section 18.29): 3645 o Random Access set to Random-Access; 3647 o Content Modifications set to Dynamic; 3649 o Retention set to Unlimited or Time-Limited. 3651 Playing on-demand media follows the general usage as described in 3652 Section 13.4.1 as long as the media has not been changed. 3654 There are two ways for the client to be informed about changes of 3655 media resources in Play state. The client will receive a PLAY_NOTIFY 3656 request with Notify-Reason header set to media-properties-update (see 3657 Section 13.5.2. The client can use the value of the Media-Range to 3658 decide further actions, if the Media-Range header is present in the 3659 PLAY_NOTIFY request. The second way is that the client issues a 3660 GET_PARAMETER request without a body but including a Media-Range 3661 header. The 200 OK response MUST include the current Media-Range 3662 header (see Section 18.30). 3664 13.4.6. Playing Live Media 3666 Live media is indicated by the content of the Media-Properties header 3667 in the SETUP response by (see also Section 18.29): 3669 o Random-Access set to No-Seeking; 3671 o Content Modifications set to Time-Progressing; 3673 o Retention with Time-Duration set to 0.0. 3675 For live media, the SETUP response 200 OK MUST include the Media- 3676 Range header (see Section 18.30). 3678 A client MAY send PLAY requests without the Range header. If the 3679 request includes the Range header it MUST use a symbolic value 3680 representing "now". For NPT that range specification is "npt=now-". 3681 The server MUST include the Range header in the response and it MUST 3682 indicate an explicit time value and not a symbolic value. In other 3683 words, "npt=now-" is not valid to be used in the response. Instead 3684 the time since session start is recommended expressed as an open 3685 interval, e.g., "npt=96.23-". An absolute time value (clock) for the 3686 corresponding time MAY be given, i.e., "clock=20030213T143205Z-". 3687 The Absolute Time format can only be used if client has shown support 3688 for it using the Accept-Ranges header. 3690 13.4.7. Playing Live with Recording 3692 Certain media servers may offer recording services of live sessions 3693 to their clients. This recording would normally be from the 3694 beginning of the media session. Clients can randomly access the 3695 media between now and the beginning of the media session. This live 3696 media with recording is indicated by the content of the Media- 3697 Properties header in the SETUP response by (see also Section 18.29): 3699 o Random Access set to Random-Access; 3701 o Content Modifications set to Time-Progressing; 3703 o Retention set to Time-Limited or Unlimited 3705 The SETUP response 200 OK MUST include the Media-Range header (see 3706 Section 18.30) for this type of media. For live media with 3707 recording, the Range header indicates the current delivery point in 3708 the media and the Media-Range header indicates the currently 3709 available media window around the current time. This window can 3710 cover recorded content in the past (seen from current time in the 3711 media) or recorded content in the future (seen from current time in 3712 the media). The server adjusts the delivery point to the requested 3713 border of the window. If the client requests a delivery point that 3714 is located outside the recording window, e.g., if the requested point 3715 is too far in the past, the server selects the oldest point in the 3716 recording. The considerations in Section 13.5.3 apply if a client 3717 requests delivery with Scale (Section 18.46) values other than 1.0 3718 (Normal playback rate) while delivering live media with recording. 3720 13.4.8. Playing Live with Time-Shift 3722 Certain media servers may offer time-shift services to their clients. 3723 This time shift records a fixed interval in the past, i.e., a sliding 3724 window recording mechanism, but not past this interval. Clients can 3725 randomly access the media between now and the interval. This live 3726 media with recording is indicated by the content of the Media- 3727 Properties header in the SETUP response by (see also Section 18.29): 3729 o Random Access set to Random-Access; 3731 o Content Modifications set to Time-Progressing; 3733 o Retention set to Time-Duration and a value indicating the 3734 recording interval (>0). 3736 The SETUP response 200 OK MUST include the Media-Range header (see 3737 Section 18.30) for this type of media. For live media with recording 3738 the Range header indicates the current time in the media and the 3739 Media Range indicates a window around the current time. This window 3740 can cover recorded content in the past (seen from current time in the 3741 media) or recorded content in the future (seen from current time in 3742 the media). The server adjusts the play point to the requested 3743 border of the window, if the client requests a play point that is 3744 located outside the recording windows, e.g., if requested too far in 3745 the past, the server selects the oldest range in the recording. The 3746 considerations in Section 13.5.3 apply, if a client requests delivery 3747 using a Scale (Section 18.46) value other than 1.0 (Normal playback 3748 rate) while delivering live media with time-shift. 3750 13.5. PLAY_NOTIFY 3752 The PLAY_NOTIFY method is issued by a server to inform a client about 3753 an asynchronous event for a session in Play state. The Session 3754 header MUST be presented in a PLAY_NOTIFY request and indicates the 3755 scope of the request. Sending of PLAY_NOTIFY requests requires a 3756 persistent connection between server and client, otherwise there is 3757 no way for the server to send this request method to the client. 3759 PLAY_NOTIFY requests have an end-to-end (i.e., server to client) 3760 scope, as they carry the Session header, and apply only to the given 3761 session. The client SHOULD immediately return a response to the 3762 server. 3764 PLAY_NOTIFY requests MAY use both aggregate control URI and 3765 individual media resource URIs depending on the scope of the 3766 notification. This scope may have important distinctions for 3767 aggregated sessions, and each reason for a PLAY_NOTIFY request needs 3768 to specify the interpretation and if aggregated control URIs or 3769 individual URIs may be used in requests. 3771 PLAY_NOTIFY requests MAY be used with a message body, depending on 3772 the value of the Notify-Reason header. It is described in the 3773 particular section for each Notify-Reason if a message body is used. 3774 However, currently there is no Notify-Reason that allows using a 3775 message body. In this case, there is a need to obey some limitations 3776 when adding new Notify-Reasons that intend to use a message body: the 3777 server can send any type of message body, but it is not ensured that 3778 the client can understand the received message body. This is related 3779 to DESCRIBE (see Section 13.2 ), but in this particular case the 3780 client can state its acceptable message bodies by using the Accept 3781 header. In the case of PLAY_NOTIFY, the server does not know which 3782 message bodies are understood by the client. 3784 The Notify-Reason header (see Section 18.32) specifies the reason why 3785 the server sends the PLAY_NOTIFY request. This is extensible and new 3786 reasons can be added in the future (see Section 22.8). In case the 3787 client does not understand the reason for the notification it MUST 3788 respond with a 465 (Notification Reason Unknown) (Section 17.4.30) 3789 error code. Servers can send PLAY_NOTIFY with these types: 3791 o end-of-stream (see Section 13.5.1); 3793 o media-properties-update (see Section 13.5.2); 3795 o scale-change (see Section 13.5.3). 3797 13.5.1. End-of-Stream 3799 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3800 indicates the completion or near completion of the PLAY request and 3801 the ending delivery of the media stream(s). The request MUST NOT be 3802 issued unless the server is in the Play state. The end of the media 3803 stream delivery notification may be used to indicate either a 3804 successful completion of the PLAY request currently being served, or 3805 to indicate some error resulting in failure to complete the request. 3806 The Request-Status header (Section 18.42) MUST be included to 3807 indicate which request the notification is for and its completion 3808 status. The message response status codes (Section 8.1.1) are used 3809 to indicate how the PLAY request concluded. The sender of a 3810 PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a 3811 PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY 3812 was issued before reaching the end-of-stream, but some error occurred 3813 resulting in that the previously sent PLAY_NOTIFY contained a wrong 3814 time when the stream will end. In this case a new PLAY_NOTIFY MUST 3815 be sent including the correct status for the completion and all 3816 additional information. 3818 PLAY_NOTIFY requests with Notify-Reason header set to end-of-stream 3819 MUST include a Range header and the Scale header if the scale value 3820 is not 1. The Range header indicates the point in the stream or 3821 streams where delivery is ending with the timescale that was used by 3822 the server in the PLAY response for the request being fulfilled. The 3823 server MUST NOT use the "now" constant in the Range header; it MUST 3824 use the actual numeric end position in the proper timescale. When 3825 end-of-stream notifications are issued prior to having sent the last 3826 media packets, this is evident as the end time in the Range header is 3827 beyond the current time in the media being received by the client, 3828 e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale 3829 header is to be included so that it is evident if the media time 3830 scale is moving backwards and/or have a non-default pace. The end- 3831 of-stream notification does not prevent the client from sending a new 3832 PLAY request. 3834 If RTP is used as media transport, a RTP-Info header MUST be 3835 included, and the RTP-Info header MUST indicate the last sequence 3836 number in the seq parameter. 3838 For an RTSP Session where media resources are under aggregated 3839 control the media resources will normally end at approximately the 3840 same time, although some small differences may exist, on the scale of 3841 a few hundred of milliseconds. In those cases a RTSP session under 3842 aggregated control SHOULD send only a single PLAY_NOTIFY request. By 3843 using the aggregate control URI in the PLAY_NOTIFY request the RTSP 3844 server indicates that this applies to all media resources within the 3845 session. In cases RTP is used for media delivery corresponding RTP- 3846 Info needs to be included for all media resources. In cases where 3847 one or more media resource has significantly shorter duration than 3848 some other resources in the aggregated session the server MAY send 3849 end-of-stream notifications using individual media resource URIs to 3850 indicate to agents that there will be no more media for this 3851 particular media resource related to the current active PLAY request. 3852 In such cases when the remaining media resources comes to end-of- 3853 stream they MUST send a PLAY_NOTIFY request using the aggregate 3854 control URI to indicate that no more resources remain. 3856 A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream 3857 MUST NOT carry a message body. 3859 This example request notifies the client about a future end-of-stream 3860 event: 3862 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3863 CSeq: 854 3864 Notify-Reason: end-of-stream 3865 Request-Status: cseq=853 status=200 reason="OK" 3866 Range: npt=-145 3867 RTP-Info:url="rtsp://example.com/fizzle/foo/audio" 3868 ssrc=0D12F123:seq=14783;rtptime=2345962545, 3869 url="rtsp://example.com/fizzle/video" 3870 ssrc=789DAF12:seq=57654;rtptime=2792482193 3872 Session: uZ3ci0K+Ld-M 3873 Date: Mon, 08 Mar 2010 13:37:16 GMT 3875 C->S: RTSP/2.0 200 OK 3876 CSeq: 854 3877 User-Agent: PhonyClient/1.2 3878 Session: uZ3ci0K+Ld-M 3880 13.5.2. Media-Properties-Update 3882 A PLAY_NOTIFY request with Notify-Reason header set to media- 3883 properties-update indicates an update of the media properties for the 3884 given session (see Section 18.29) and/or the available media range 3885 that can be played as indicated by Media-Range (Section 18.30). 3886 PLAY_NOTIFY requests with Notify-Reason header set to media- 3887 properties-update MUST include a Media-Properties and Date header and 3888 SHOULD include a Media-Range header. The Media-Properties header has 3889 session scope, thus for aggregated sessions the PLAY_NOTIFY request 3890 MUST be using the aggregated control URI. 3892 This notification MUST be sent for media that are Time-Progressing 3893 every time an event happens that changes the basis for making 3894 estimates on how the available for play-back media range will 3895 progress with wall clock time. In addition it is RECOMMENDED that 3896 the server sends these notifications approximately every 5 minutes 3897 for time-progressing content to ensure the long-term stability of the 3898 client estimation and allowing for clock skew detection by the 3899 client. The time between notifications should be greater than 1 3900 minute and less than 2 hours. For the reasons just explained, 3901 requests MUST include a Media-Range header to provide current Media 3902 duration and a Range header to indicate the current playing point and 3903 any remaining parts of the requested range. 3905 The recommendation for sending updates every 5 minutes is due to 3906 any clock skew issues. In 5 minutes the clock skew should not 3907 become too significant as this is not used for media playback and 3908 synchronization, only for determining which content is available 3909 to the user. 3911 A PLAY_NOTIFY request with Notify-Reason header set to media- 3912 properties-update MUST NOT carry a message body. 3914 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3915 Date: Tue, 14 Apr 2008 15:48:06 GMT 3916 CSeq: 854 3917 Notify-Reason: media-properties-update 3918 Session: uZ3ci0K+Ld-M 3919 Media-Properties: Time-Progressing, 3920 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3921 Media-Range: npt=00:00:00-01:37:21.394 3922 Range: npt=01:15:49.873- 3924 C->S: RTSP/2.0 200 OK 3925 CSeq: 854 3926 User-Agent: PhonyClient/1.2 3927 Session: uZ3ci0K+Ld-M 3929 13.5.3. Scale-Change 3931 The server may be forced to change the rate of media time per 3932 playback time when a client requests delivery using a Scale 3933 (Section 18.46) value other than 1.0 (normal playback rate). For 3934 time progressing media with some retention, i.e., the server stores 3935 already sent content, a client requesting to play with Scale values 3936 larger than 1 may catch up with the front end of the media. The 3937 server will then be unable to continue to provide content at Scale 3938 larger than 1 as content is only made available by the server at 3939 Scale=1. Another case is when Scale < 1 and the media retention is 3940 time-duration limited. In this case the delivery point can reach the 3941 oldest media unit available, and further playback at this scale 3942 becomes impossible as there will be no media available. To avoid 3943 having the client lose any media, the scale will need to be adjusted 3944 to the same rate at which the media is removed from the storage 3945 buffer, commonly Scale = 1.0. 3947 Another case is when the content itself consists of spliced pieces or 3948 is dynamically updated. In these cases the server may be required to 3949 change from one supported scale value (different than Scale=1.0) to 3950 another. In this case the server will pick the closest value and 3951 inform the client of what it has picked. In these cases the media 3952 properties will also be sent updating the supported Scale values. 3953 This enables a client to adjust the Scale value used. 3955 To minimize impact on playback in any of the above cases the server 3956 MUST modify the playback properties and set Scale to a supportable 3957 value and continue delivery of the media. When doing this 3958 modification it MUST send a PLAY_NOTIFY message with the Notify- 3959 Reason header set to "scale-change". The request MUST contain a 3960 Range header with the media time when the change took effect, a Scale 3961 header with the new value in use, Session header with the identifier 3962 for the session it applies to and a Date header with the server 3963 wallclock time of the change. For time progressing content also the 3964 Media-Range and the Media-Properties at this point in time MUST be 3965 included. The Media-Properties header MUST be included if the scale 3966 change was due to the content changing what scale values that is 3967 supported. 3969 For media streams being delivered using RTP also a RTP-Info header 3970 MUST be included. It MUST contain the rtptime parameter with a value 3971 corresponding to the point of change in that media and optionally 3972 also the sequence number. 3974 PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated 3975 control URI in the request. The scale change for any aggregated 3976 session applies to all media streams part of the aggregate. 3978 A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" 3979 MUST NOT carry a message body. 3981 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 3982 Date: Tue, 14 Apr 2008 15:48:06 GMT 3983 CSeq: 854 3984 Notify-Reason: scale-change 3985 Session: uZ3ci0K+Ld-M 3986 Media-Properties: Time-Progressing, 3987 Time-Limited=20080415T153919.36Z, Random-Access=5.0 3988 Media-Range: npt=00:00:00-01:37:21.394 3989 Range: npt=01:37:21.394- 3990 Scale: 1 3991 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" 3992 ssrc=0D12F123:rtptime=2345962545, 3993 url="rtsp://example.com/fizzle/videotrack" 3994 ssrc=789DAF12:seq=57654;rtptime=2792482193 3996 C->S: RTSP/2.0 200 OK 3997 CSeq: 854 3998 User-Agent: PhonyClient/1.2 3999 Session: uZ3ci0K+Ld-M 4001 13.6. PAUSE 4003 The PAUSE request causes the stream delivery to immediately be 4004 interrupted (halted). A PAUSE request MUST be done either with the 4005 aggregated control URI for aggregated sessions, resulting in all 4006 media being halted, or the media URI for non-aggregated sessions. 4008 Any attempt to do muting of a single media with a PAUSE request in an 4009 aggregated session MUST be responded to with error 460 (Only 4010 Aggregate Operation Allowed). After resuming playback, 4011 synchronization of the tracks MUST be maintained. Any server 4012 resources are kept, though servers MAY close the session and free 4013 resources after being paused for the duration specified with the 4014 timeout parameter of the Session header in the SETUP message. 4016 Example: 4018 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4019 CSeq: 834 4020 Session: 12345678 4021 User-Agent: PhonyClient/1.2 4023 S->C: RTSP/2.0 200 OK 4024 CSeq: 834 4025 Date: Thu, 23 Jan 1997 15:35:06 GMT 4026 Range: npt=45.76-75.00 4028 The PAUSE request causes stream delivery to be interrupted 4029 immediately on receipt of the message and the pause point is set to 4030 the current point in the presentation. That pause point in the media 4031 stream needs to be maintained. A subsequent PLAY request without 4032 Range header resumes from the pause point and plays until media end. 4034 The pause point after any PAUSE request MUST be returned to the 4035 client by adding a Range header with what remains unplayed of the 4036 PLAY request's range. For media with random access properties, if 4037 one desires to resume playing a ranged request, one simply includes 4038 the Range header from the PAUSE response and includes the Seek-Style 4039 header with the Next policy in the PLAY request. For media that is 4040 time-progressing and has retention duration=0 the follow-up PLAY 4041 request to start media delivery again, MUST use "npt=now-" and not 4042 the answer given in the response to PAUSE. 4044 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 4045 CSeq: 834 4046 Session: 12345678 4047 Range: npt=10-30 4048 User-Agent: PhonyClient/1.2 4050 S->C: RTSP/2.0 200 OK 4051 CSeq: 834 4052 Date: Thu, 23 Jan 1997 15:35:06 GMT 4053 Server: PhonyServer/1.0 4054 Range: npt=10-30 4055 Seek-Style: First-Prior 4056 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 4057 ssrc=0D12F123:seq=5712;rtptime=934207921, 4058 url="rtsp://example.com/fizzle/videotrack" 4059 ssrc=4FAD8726:seq=57654;rtptime=2792482193 4060 Session: 12345678 4062 After 11 seconds, i.e., at 21 seconds into the presentation: 4063 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4064 CSeq: 835 4065 Session: 12345678 4066 User-Agent: PhonyClient/1.2 4068 S->C: RTSP/2.0 200 OK 4069 CSeq: 835 4070 Date: 23 Jan 1997 15:35:17 GMT 4071 Server: PhonyServer/1.0 4072 Range: npt=21-30 4073 Session: 12345678 4075 If a client issues a PAUSE request and the server acknowledges and 4076 enters the Ready state, the proper server response, if the player 4077 issues another PAUSE, is still 200 OK. The 200 OK response MUST 4078 include the Range header with the current pause point. See examples 4079 below: 4081 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4082 CSeq: 834 4083 Session: 12345678 4084 User-Agent: PhonyClient/1.2 4086 S->C: RTSP/2.0 200 OK 4087 CSeq: 834 4088 Session: 12345678 4089 Date: Thu, 23 Jan 1997 15:35:06 GMT 4090 Range: npt=45.76-98.36 4092 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 4093 CSeq: 835 4094 Session: 12345678 4095 User-Agent: PhonyClient/1.2 4097 S->C: RTSP/2.0 200 OK 4098 CSeq: 835 4099 Session: 12345678 4100 Date: 23 Jan 1997 15:35:07 GMT 4101 Range: npt=45.76-98.36 4103 13.7. TEARDOWN 4105 13.7.1. Client to Server 4107 The TEARDOWN client to server request stops the stream delivery for 4108 the given URI, freeing the resources associated with it. A TEARDOWN 4109 request can be performed on either an aggregated or a media control 4110 URI. However, some restrictions apply depending on the current 4111 state. The TEARDOWN request MUST contain a Session header indicating 4112 what session the request applies to. The TEARDOWN request MUST NOT 4113 include a Terminate-Reason header. 4115 A TEARDOWN using the aggregated control URI or the media URI in a 4116 session under non-aggregated control (single media session) MAY be 4117 done in any state (Ready and Play). A successful request MUST result 4118 in that media delivery being immediately halted and the session state 4119 being destroyed. This MUST be indicated through the lack of a 4120 Session header in the response. 4122 A TEARDOWN using a media URI in an aggregated session can only be 4123 done in Ready state. Such a request only removes the indicated media 4124 stream and associated resources from the session. This may result in 4125 a session returning to non-aggregated control, because it only 4126 contains a single media after the request's completion. A session 4127 that will exist after the processing of the TEARDOWN request MUST in 4128 the response to that TEARDOWN request contain a Session header. Thus 4129 the presence of the Session header indicates to the receiver of the 4130 response if the session is still extant or has been removed. 4132 Example: 4134 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 4135 CSeq: 892 4136 Session: 12345678 4137 User-Agent: PhonyClient/1.2 4139 S->C: RTSP/2.0 200 OK 4140 CSeq: 892 4141 Server: PhonyServer/1.0 4143 13.7.2. Server to Client 4145 The server can send TEARDOWN requests in the server to client 4146 direction to indicate that the server has been forced to terminate 4147 the ongoing session. This may happen for several reasons, such as 4148 server maintenance without available backup, or that the session has 4149 been inactive for extended periods of time. The reason is provided 4150 in the Terminate-Reason header (Section 18.52). 4152 When a RTSP client has maintained a RTSP session that otherwise is 4153 inactive for an extended period of time the server may reclaim the 4154 resources. That is done by issuing a TEARDOWN request with the 4155 Terminate-Reason set to "Session-Timeout". This MAY be done when the 4156 client has been inactive in the RTSP session for more than one 4157 Session Timeout period (Section 18.49). However, the server is 4158 RECOMMENDED to not perform this operation until an extended period of 4159 inactivity of 10 times the Session Timeout period has passed. It is 4160 up to the operator of the RTSP server to actually configure how long 4161 this extended period of inactivity is. An operator should take into 4162 account when doing this configuration what the served content is and 4163 what this means for the extended period of inactivity. 4165 In case the server needs to stop providing service to the established 4166 sessions and there is no server to point at in a REDIRECT request, 4167 then TEARDOWN SHALL be used to terminate the session. This method 4168 can also be used when non-recoverable internal errors have happened 4169 and the server has no other option then to terminate the sessions. 4171 The TEARDOWN request MUST be done only on the session aggregate 4172 control URI (i.e., it is not allowed to terminate individual media 4173 streams, if it is a session aggregate) and MUST include the following 4174 headers; Session and Terminate-Reason headers. The request only 4175 applies to the session identified in the Session header. The server 4176 may include a message to the client's user with the "user-msg" 4177 parameter. 4179 The TEARDOWN request may alternatively be done on the wild card URI * 4180 and without any session header. The scope of such a request is 4181 limited to the next-hop (i.e., the RTSP agent in direct communication 4182 with the server) and applies, as well, to the RTSP connection between 4183 the next-hop RTSP agent and the server. This request indicates that 4184 all sessions and pending requests being managed via the connection 4185 are terminated. Any intervening proxies SHOULD do all of the 4186 following in the order listed: 4188 1. respond to the TEARDOWN request 4190 2. disconnect the control channel from the requesting server 4192 3. pass the TEARDOWN request to each applicable client (typically 4193 those clients with an active session or an unanswered request) 4195 Note: The proxy is responsible for accepting TEARDOWN responses 4196 from its clients; these responses MUST NOT be passed on to either 4197 the original server or the target server in the redirect. 4199 13.8. GET_PARAMETER 4201 The GET_PARAMETER request retrieves the value of any specified 4202 parameter or parameters for a presentation or stream specified in the 4203 URI. If the Session header is present in a request, the value of a 4204 parameter MUST be retrieved in the specified session context. There 4205 are two ways of specifying the parameters to be retrieved. 4207 The first is by including headers which have been defined such that 4208 you can use them for this purpose. Headers for this purpose should 4209 allow empty, or stripped value parts to avoid having to specify bogus 4210 data when indicating the desire to retrieve a value. The successful 4211 completion of the request should also be evident from any filled out 4212 values in the response. The headers in this specification that MAY 4213 be used for retrieving their current value using GET_PARAMETER are 4214 listed below; additional headers MAY be specified in the future: 4216 o Accept-Ranges 4218 o Media-Range 4220 o Media-Properties 4222 o Range 4223 o RTP-Info 4225 The other way is to specify a message body that lists the 4226 parameter(s) that are desired to be retrieved. The Content-Type 4227 header (Section 18.19) is used to specify which format the message 4228 body has. If the receiver of the request does not support the media 4229 type used for the message body, it SHALL respond using the error code 4230 415 (Unsupported Media Type). The responder to a GET_PARAMETER 4231 request MUST use the media type of the request for the response. For 4232 additional considerations regarding message body negotiation see 4233 Section 9.3. 4235 RTSP Agents implementing support for responding to GET_PARAMETER 4236 requests SHALL implement the text/parameters format (Appendix F). 4237 This to ensure that at least one known format for parameters is 4238 implemented and thus prevent parameter format negotiation failure. 4240 Parameters specified within the body of the message must all be 4241 understood by the request receiving agent. If one or more parameters 4242 are not understood a 451 (Parameter Not Understood) MUST be sent 4243 including a body listing these parameters that weren't understood. 4244 If all parameters are understood their values are filled in and 4245 returned in the response message body. 4247 The method can also be used without a message body or any header that 4248 requests parameters for keep-alive purpose. The keep-alive timer has 4249 been updated for any request that is successful, i.e., a 200 OK 4250 response is received. Any non-required header present in such a 4251 request may or may not have been processed. Normally the presence of 4252 filled out values in the header will be indication that the header 4253 has been processed. However, for cases when this is difficult to 4254 determine, it is recommended to use a feature-tag and the Require 4255 header. For this reason it is usually easier if any parameters to be 4256 retrieved are sent in the body, rather than using any header. 4258 Example: 4260 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4261 CSeq: 431 4262 User-Agent: PhonyClient/1.2 4263 Session: 12345678 4264 Content-Length: 26 4265 Content-Type: text/parameters 4267 packets_received 4268 jitter 4270 C->S: RTSP/2.0 200 OK 4271 CSeq: 431 4272 Session: 12345678 4273 Server: PhonyServer/1.1 4274 Date: Mon, 08 Mar 2010 13:43:23 GMT 4275 Content-Length: 38 4276 Content-Type: text/parameters 4278 packets_received: 10 4279 jitter: 0.3838 4281 13.9. SET_PARAMETER 4283 This method requests to set the value of a parameter or a set of 4284 parameters for a presentation or stream specified by the URI. The 4285 method MAY also be used without a message body. It is the 4286 RECOMMENDED method to be used in a request sent for the sole purpose 4287 of updating the keep-alive timer. If this request is successful, 4288 i.e., a 200 OK response is received, then the keep-alive timer has 4289 been updated. Any non-required header present in such a request may 4290 or may not have been processed. To allow a client to determine if 4291 any such header has been processed, it is necessary to use a feature 4292 tag and the Require header. Due to this reason it is RECOMMENDED 4293 that any parameters are sent in the body, rather than using any 4294 header. 4296 When using a message body to list the parameter(s) that are desired 4297 to be set the Content-Type header (Section 18.19) is used to specify 4298 which format the message body has. If the receiver of the request is 4299 not supporting the media type used for the message body, it SHALL 4300 respond using the error code 415 (Unsupported Media Type). For 4301 additional considerations regarding message body negotiation see 4302 Section 9.3. 4304 RTSP Agents implementing support for responding to SET_PARAMETER 4305 requests SHALL implement the text/parameters format (Appendix F). 4306 This to ensure that at least one known format for parameters is 4307 implemented and thus prevent parameter format negotiation failure. 4309 A request is RECOMMENDED to only contain a single parameter to allow 4310 the client to determine why a particular request failed. If the 4311 request contains several parameters, the server MUST only act on the 4312 request if all of the parameters can be set successfully. A server 4313 MUST allow a parameter to be set repeatedly to the same value, but it 4314 MAY disallow changing parameter values. If the receiver of the 4315 request does not understand or cannot locate a parameter, error 451 4316 (Parameter Not Understood) MUST be used. When a parameter is not 4317 allowed to change, the error code is 458 (Parameter Is Read-Only). 4318 The response body MUST contain only the parameters that have errors. 4319 Otherwise, a body MUST NOT be returned. The response body MUST use 4320 the media type of the request for the response. 4322 Note: transport parameters for the media stream MUST only be set with 4323 the SETUP command. 4325 Restricting setting transport parameters to SETUP is for the 4326 benefit of firewalls. 4328 The parameters are split in a fine-grained fashion so that there 4329 can be more meaningful error indications. However, it may make 4330 sense to allow the setting of several parameters if an atomic 4331 setting is desirable. Imagine device control where the client 4332 does not want the camera to pan unless it can also tilt to the 4333 right angle at the same time. 4335 Example: 4337 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 4338 CSeq: 421 4339 User-Agent: PhonyClient/1.2 4340 Session: iixT43KLc 4341 Date: Mon, 08 Mar 2010 14:45:04 GMT 4342 Content-length: 20 4343 Content-type: text/parameters 4345 barparam: barstuff 4347 S->C: RTSP/2.0 451 Parameter Not Understood 4348 CSeq: 421 4349 Session: iixT43KLc 4350 Server: PhonyServer/1.0 4351 Date: Mon, 08 Mar 2010 14:44:56 GMT 4352 Content-length: 20 4353 Content-type: text/parameters 4355 barparam: barstuff 4357 13.10. REDIRECT 4359 The REDIRECT method is issued by a server to inform a client that the 4360 service provided will be terminated and where a corresponding service 4361 can be provided instead. This may happen for different reasons. One 4362 is that the server is being administered such that it must stop 4363 providing service. Thus the client is required to connect to another 4364 server location to access the resource indicated by the Request-URI. 4366 The REDIRECT request SHALL contain a Terminate-Reason header 4367 (Section 18.52) to inform the client of the reason for the request. 4368 Additional parameters related to the reason may also be included. 4369 The intention here is to allow a server administrator to do a 4370 controlled shutdown of the RTSP server. That requires sufficient 4371 time to inform all entities having associated state with the server 4372 and for them to perform a controlled migration from this server to a 4373 fall back server. 4375 A REDIRECT request with a Session header has end-to-end (i.e., server 4376 to client) scope and applies only to the given session. Any 4377 intervening proxies SHOULD NOT disconnect the control channel while 4378 there are other remaining end-to-end sessions. The REQUIRED Location 4379 header MUST contain a complete absolute URI pointing to the resource 4380 to which the client SHOULD reconnect. Specifically, the Location 4381 MUST NOT contain just the host and port. A client may receive a 4382 REDIRECT request with a Session header, if and only if, an end-to-end 4383 session has been established. 4385 A client may receive a REDIRECT request without a Session header at 4386 any time when it has communication or a connection established with a 4387 server. The scope of such a request is limited to the next-hop 4388 (i.e., the RTSP agent in direct communication with the server) and 4389 applies to all sessions controlled, as well as the connection between 4390 the next-hop RTSP agent and the server. A REDIRECT request without a 4391 Session header indicates that all sessions and pending requests being 4392 managed via the connection MUST be redirected. The Location header, 4393 if included in such a request, SHOULD contain an absolute URI with 4394 only the host address and the OPTIONAL port number of the server to 4395 which the RTSP agent SHOULD reconnect. Any intervening proxies 4396 SHOULD do all of the following in the order listed: 4398 1. respond to the REDIRECT request 4400 2. disconnect the control channel from the requesting server 4402 3. connect to the server at the given host address 4403 4. pass the REDIRECT request to each applicable client (typically 4404 those clients with an active session or an unanswered request) 4406 Note: The proxy is responsible for accepting REDIRECT responses 4407 from its clients; these responses MUST NOT be passed on to either 4408 the original server or the redirected server. 4410 When the server lacks any alternative server and needs to terminate a 4411 session or all sessions the TEARDOWN request SHALL be used instead. 4413 When no Terminate-Reason "time" parameter is included in a REDIRECT 4414 request, the client SHALL perform the redirection immediately and 4415 return a response to the server. The server shall consider the 4416 session as terminated and can free any associated state after it 4417 receives the successful (2xx) response. The server MAY close the 4418 signaling connection upon receiving the response and the client 4419 SHOULD close the signaling connection after sending the 2xx response. 4420 The exception to this is when the client has several sessions on the 4421 server being managed by the given signaling connection. In this 4422 case, the client SHOULD close the connection when it has received and 4423 responded to REDIRECT requests for all the sessions managed by the 4424 signaling connection. 4426 The Terminate-Reason header "time" parameter MAY be used to indicate 4427 the wallclock time by when the redirection MUST have taken place. To 4428 allow a client to determine that redirect time without being time 4429 synchronized with the server, the server MUST include a Date header 4430 in the request. The client should have terminated the session and 4431 closed the connection before the redirection time-line terminated. 4432 The server MAY simply cease to provide service when the deadline time 4433 has been reached, or it may issue TEARDOWN requests to the remaining 4434 sessions. 4436 If the REDIRECT request times out following the rules in Section 10.4 4437 the server MAY terminate the session or transport connection that 4438 would be redirected by the request. This is a safeguard against 4439 misbehaving clients that refuse to respond to a REDIRECT request. 4440 Thus, removing any incentive to not acknowledge the reception of a 4441 REDIRECT request. 4443 After a REDIRECT request has been processed, a client that wants to 4444 continue to receive media for the resource identified by the Request- 4445 URI will have to establish a new session with the designated host. 4446 If the URI given in the Location header is a valid resource URI, a 4447 client SHOULD issue a DESCRIBE request for the URI. 4449 Note: The media resource indicated by the Location header can be 4450 identical, slightly different or totally different. This is the 4451 reason why a new DESCRIBE request SHOULD be issued. 4453 If the Location header contains only a host address, the client may 4454 assume that the media on the new server is identical to the media on 4455 the old server, i.e., all media configuration information from the 4456 old session is still valid except for the host address. However, the 4457 usage of conditional SETUP using MTag identifiers is RECOMMENDED as a 4458 means to verify the assumption. 4460 This example request redirects traffic for this session to the new 4461 server at the given absolute time: 4463 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 4464 CSeq: 732 4465 Location: rtsp://s2.example.com:8001 4466 Terminate-Reason: Server-Admin ;time=19960213T143205Z 4467 Session: uZ3ci0K+Ld-M 4468 Date: Thu, 13 Feb 1996 14:30:43 GMT 4470 C->S: RTSP/2.0 200 OK 4471 CSeq: 732 4472 User-Agent: PhonyClient/1.2 4473 Session: uZ3ci0K+Ld-M 4475 14. Embedded (Interleaved) Binary Data 4477 In order to fulfill certain requirements on the network side, e.g., 4478 in conjunction with network address translators that block RTP 4479 traffic over UDP, it may be necessary to interleave RTSP messages and 4480 media stream data. This interleaving should generally be avoided 4481 unless necessary since it complicates client and server operation and 4482 imposes additional overhead. Also, head-of-line blocking may cause 4483 problems. Interleaved binary data SHOULD only be used if RTSP is 4484 carried over TCP. Interleaved data is not allowed inside RTSP 4485 messages. 4487 Stream data such as RTP packets is encapsulated by an ASCII dollar 4488 sign (36 decimal), followed by a one-octet channel identifier, 4489 followed by the length of the encapsulated binary data as a binary, 4490 two-octet unsigned integer in network octet order (Appendix B of 4491 [RFC0791]). The stream data follows immediately afterwards, without 4492 a CRLF, but including the upper-layer protocol headers. Each $ block 4493 MUST contain exactly one upper-layer protocol data unit, e.g., one 4494 RTP packet. 4496 Note that this mechanism does not support PDUs larger than 65535 4497 octets, which matches the maximum payload size of regular, non- 4498 jumbo IPv4 and IPv6 packets. If the media delivery protocol 4499 intended to be used has larger PDUs than that, definition of a PDU 4500 fragmentation mechanism will be required to support embedded 4501 binary data. 4503 0 1 2 3 4504 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 4505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4506 | "$" = 36 | Channel ID | Length in octets | 4507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 : Binary data (Length according to Length field) : 4509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4511 Figure 1: Embedded Interleaved Binary Data Format 4513 The channel identifier is defined in the Transport header with the 4514 interleaved parameter (Section 18.54). 4516 When the transport choice is RTP, RTCP messages are also interleaved 4517 by the server over the TCP connection. The usage of RTCP messages is 4518 indicated by including an interval containing a second channel in the 4519 interleaved parameter of the Transport header, see Section 18.54. If 4520 RTCP is used, packets MUST be sent on the first available channel 4521 higher than the RTP channel. The channels are bi-directional, using 4522 the same Channel ID in both directions, and therefore RTCP traffic is 4523 sent on the second channel in both directions. 4525 RTCP is sometimes needed for synchronization when two or more 4526 streams are interleaved in such a fashion. Also, this provides a 4527 convenient way to tunnel RTP/RTCP packets through the RTSP 4528 connection (TCP or TCP/TLS) when required by the network 4529 configuration and transfer them onto UDP when possible. 4531 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 4532 CSeq: 2 4533 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 4534 Accept-Ranges: npt, smpte, clock 4535 User-Agent: PhonyClient/1.2 4537 S->C: RTSP/2.0 200 OK 4538 CSeq: 2 4539 Date: Thu, 05 Jun 1997 18:57:18 GMT 4540 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 4541 Session: 12345678 4542 Accept-Ranges: npt 4543 Media-Properties: Random-Access=0.2, Immutable, Unlimited 4545 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 4546 CSeq: 3 4547 Session: 12345678 4548 User-Agent: PhonyClient/1.2 4550 S->C: RTSP/2.0 200 OK 4551 CSeq: 3 4552 Session: 12345678 4553 Date: Thu, 05 Jun 1997 18:57:19 GMT 4554 RTP-Info: url="rtsp://example.com/bar.file" 4555 ssrc=0D12F123:seq=232433;rtptime=972948234 4556 Range: npt=0-56.8 4557 Seek-Style: RAP 4559 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4560 S->C: $005{2 octet length}{"length" octets data, w/RTP header} 4561 S->C: $006{2 octet length}{"length" octets RTCP packet} 4563 15. Proxies 4565 RTSP Proxies are RTSP agents that are located in between a client and 4566 a server. A proxy can take on both the role as a client and as 4567 server depending on what it tries to accomplish. RTSP proxies use 4568 two transport layer connections, one from the RTSP client to the RTSP 4569 proxy and a second from the RTSP proxy to the RTSP server. Proxies 4570 are introduced for several different reasons and those listed below 4571 are often combined. 4573 Caching Proxy: This type of proxy is used to reduce the workload on 4574 servers and connections. By caching the description and media 4575 streams, i.e., the presentation, the proxy can serve a client 4576 with content, but without requesting it from the server once it 4577 has been cached and has not become stale. See the caching 4578 Section 16. This type of proxy is also expected to understand 4579 RTSP end-point functionality, i.e., functionality identified in 4580 the Require header in addition to what Proxy-Require demands. 4582 Translator Proxy: This type of proxy is used to ensure that an RTSP 4583 client gets access to servers and content on an external 4584 network or using content encodings not supported by the client. 4585 The proxy performs the necessary translation of addresses, 4586 protocols or encodings. This type of proxy is expected to also 4587 understand RTSP end-point functionality, i.e., functionality 4588 identified in the Require header in addition to what Proxy- 4589 Require demands. 4591 Access Proxy: This type of proxy is used to ensure that an RTSP 4592 client gets access to servers on an external network. Thus 4593 this proxy is placed on the border between two domains, e.g., a 4594 private address space and the public Internet. The proxy 4595 performs the necessary translation, usually addresses. This 4596 type of proxy is required to redirect the media to itself or a 4597 controlled gateway that performs the translation before the 4598 media can reach the client. 4600 Security Proxy: This type of proxy is used to help facilitate 4601 security functions around RTSP. For example when having a 4602 firewalled network, the security proxy requests that the 4603 necessary pinholes in the firewall are opened when a client in 4604 the protected network wants to access media streams on the 4605 external side. This proxy can perform its function without 4606 redirecting the media between the server and client. However, 4607 in deployments with private address spaces this proxy is likely 4608 to be combined with the access proxy. Anyway, the 4609 functionality of this proxy is usually closely tied into 4610 understanding all aspects of the media transport. 4612 Auditing Proxy: RTSP proxies can also provide network owners with a 4613 logging and audit point for RTSP sessions, e.g., for 4614 corporations that track their employees usage of the network. 4615 This type of proxy can perform its function without inserting 4616 itself or any other node in the media transport. This proxy 4617 type can also accept unknown methods as it doesn't interfere 4618 with the clients' requests. 4620 All types of proxies can also be used when using secured 4621 communication with TLS as RTSP 2.0 allows the client to approve 4622 certificate chains used for connection establishment from a proxy, 4623 see Section 19.3.2. However, that trust model may not be suitable 4624 for all types of deployment. In those cases, the secured sessions do 4625 by-pass the proxies. 4627 Access proxies SHOULD NOT be used in equipment like NATs and 4628 firewalls that aren't expected to be regularly maintained, like home 4629 or small office equipment. In these cases it is better to use the 4630 NAT traversal procedures defined for RTSP 2.0 4631 [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is 4632 that any extensions of RTSP resulting in new media transport 4633 protocols or profiles, new parameters, etc. may fail in a proxy that 4634 isn't maintained. This would impede RTSP's future development and 4635 usage. 4637 15.1. Proxies and Protocol Extensions 4639 The existence of proxies must always be considered when developing 4640 new RTSP extensions. Most types of proxies will need to implement 4641 any new method to operate correctly in the presence of that 4642 extension. New headers can be introduced and will not be blocked by 4643 older proxies. However, it is important to consider if this header 4644 and its function is required to be understood by the proxy or can be 4645 forwarded. If the header needs to be understood, a feature-tag 4646 representing the functionality MUST be included in the Proxy-Require 4647 header. Below are guidelines for analysis if the header needs to be 4648 understood. The transport header and its parameters also shows that 4649 headers that are extensible and require correct interpretation in the 4650 proxy also require handling rules. 4652 Whether a proxy needs to understand a header is not easy to 4653 determine, as they serve a broad variety of functions. When 4654 evaluating if a header needs to be understood, one can divide the 4655 functionality into three main categories: 4657 Media modifying: The caching and translator proxies are modifying 4658 the actual media and therefore need to understand also the request 4659 directed to the server that affects how the media is rendered. 4660 Thus, this type of proxy needs to also understand the server side 4661 functionality. 4663 Transport modifying: The access and the security proxy both need to 4664 understand how the transport is performed, either for opening 4665 pinholes or to translate the outer headers, e.g., IP and UDP. 4667 Non-modifying: The audit proxy is special in that it does not modify 4668 the messages in other ways than to insert the Via header. That 4669 makes it possible for this type to forward RTSP messages that 4670 contain different types of unknown methods, headers or header 4671 parameters. 4673 Based on the above classification, one should evaluate if the new 4674 functionality requires the Transport modifying type of proxies to 4675 understand it or not. 4677 15.2. Multiplexing and Demultiplexing of Messages 4679 RTSP proxies may have to multiplex multiple RTSP sessions from their 4680 clients towards RTSP servers. This requires that RTSP requests from 4681 multiple clients are multiplexed onto a common connection for 4682 requests outgoing to an RTSP server and on the way back the responses 4683 are demultiplexed from the server to per client responses. On the 4684 protocol level this requires that request and response messages are 4685 handled in both ways, requiring that there is a mechanism to 4686 correlate what request/response pair exchanged between proxy and 4687 server is mapped to what client (or client request). 4689 This multiplexing of requests and demultiplexing of responses is done 4690 by using the CSeq header field. The proxy has to rewrite the CSeq in 4691 requests to the server and responses from the server and remember 4692 what CSeq is mapped to what client. The proxy also needs to ensure 4693 that the order of the message related to each client is maintained. 4694 Section 18.20 is defining the handling of how requests and responses 4695 are rewritten. 4697 16. Caching 4699 In HTTP, request-response pairs are cached. RTSP differs 4700 significantly in that respect. Responses are not cacheable, with the 4701 exception of the presentation description returned by DESCRIBE. 4702 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4703 not return any data, caching is not really an issue for these 4704 requests.) However, it is desirable for the continuous media data, 4705 typically delivered out-of-band with respect to RTSP, to be cached, 4706 as well as the session description. 4708 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4709 has an up-to-date copy of the continuous media content and its 4710 description. It can determine whether the copy is up-to-date by 4711 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4712 Last-Modified header with that of the cached copy. If the copy is 4713 not up-to-date, it modifies the SETUP transport parameters as 4714 appropriate and forwards the request to the origin server. 4715 Subsequent control commands such as PLAY or PAUSE then pass the proxy 4716 unmodified. The proxy delivers the continuous media data to the 4717 client, while possibly making a local copy for later reuse. The 4718 exact allowed behavior of the cache is given by the cache-response 4719 directives described in Section 18.11. A cache MUST answer any 4720 DESCRIBE requests if it is currently serving the stream to the 4721 requester, as it is possible that low-level details of the stream 4722 description may have changed on the origin-server. 4724 Note that an RTSP cache, is of the "cut-through" variety. Rather 4725 than retrieving the whole resource from the origin server, the cache 4726 simply copies the streaming data as it passes by on its way to the 4727 client. Thus, it does not introduce additional latency. 4729 To the client, an RTSP proxy cache appears like a regular media 4730 server. To the media origin server an RTSP proxy cache appears like 4731 a client. Just as an HTTP cache has to store the content type, 4732 content language, and so on for the objects it caches, a media cache 4733 has to store the presentation description. Typically, a cache 4734 eliminates all transport-references (e.g., multicast information) 4735 from the presentation description, since these are independent of the 4736 data delivery from the cache to the client. Information on the 4737 encodings remains the same. If the cache is able to translate the 4738 cached media data, it would create a new presentation description 4739 with all the encoding possibilities it can offer. 4741 16.1. Validation Model 4743 When a cache has a stale entry that it would like to use as a 4744 response to a client's request, it first has to check with the origin 4745 server (or possibly an intermediate cache with a fresh response) to 4746 see if its cached entry is still usable. This is called "validating" 4747 the cache entry. To avoid having to pay the overhead of 4748 retransmitting the full response if the cached entry is good, and at 4749 the same time avoiding to pay the overhead of an extra round trip if 4750 the cached entry is invalid, the RTSP protocol supports the use of 4751 conditional methods. 4753 The key protocol features for supporting conditional methods are 4754 those concerned with "cache validators." When an origin server 4755 generates a full response, it attaches some sort of validator to it, 4756 which is kept with the cache entry. When a client (user agent or 4757 proxy cache) makes a conditional request for a resource for which it 4758 has a cache entry, it includes the associated validator in the 4759 request. 4761 The server then checks that validator against the current validator 4762 for the requested resource, and, if they match (see Section 16.1.3), 4763 it responds with a special status code (usually, 304 (Not Modified)) 4764 and no message body. Otherwise, it returns a full response 4765 (including message body). Thus, avoiding transmitting the full 4766 response if the validator matches, and avoiding an extra round trip 4767 if it does not match. 4769 In RTSP, a conditional request looks exactly the same as a normal 4770 request for the same resource, except that it carries a special 4771 header (which includes the validator) that implicitly turns the 4772 method (usually DESCRIBE or SETUP) into a conditional. 4774 The protocol includes both positive and negative senses of cache- 4775 validating conditions. That is, it is possible to request either 4776 that a method be performed if and only if a validator matches or if 4777 and only if no validators match. 4779 Note: a response that lacks a validator may still be cached, and 4780 served from cache until it expires, unless this is explicitly 4781 prohibited by a cache-control directive (see Section 18.11). 4782 However, a cache cannot do a conditional retrieval if it does not 4783 have a validator for the resource, which means it will not be 4784 refreshable after it expires. 4786 Media streams that are being adapted based on the transport capacity 4787 between the server and the cache makes caching more difficult. A 4788 server needs to consider how it views caching of media streams that 4789 it adapts and potentially instruct any caches to not cache such 4790 streams. 4792 16.1.1. Last-Modified Dates 4794 The Last-Modified header (Section 18.27) value is often used as a 4795 cache validator. In simple terms, a cache entry is considered to be 4796 valid if the content has not been modified since the Last-Modified 4797 value. 4799 16.1.2. Message Body Tag Cache Validators 4801 The MTag response-header field value, a message body tag, provides 4802 for an "opaque" cache validator. This might allow more reliable 4803 validation in situations where it is inconvenient to store 4804 modification dates, where the one-second resolution of RTSP-date 4805 values is not sufficient, or where the origin server wishes to avoid 4806 certain paradoxes that might arise from the use of modification 4807 dates. 4809 Message body tags are described in Section 4.6 4811 16.1.3. Weak and Strong Validators 4813 Since both origin servers and caches will compare two validators to 4814 decide if they represent the same or different entities, one normally 4815 would expect that if the message body (i.e., the presentation 4816 description) or any associated message body headers changes in any 4817 way, then the associated validator would change as well. If this is 4818 true, then this validator is a "strong validator." The Message body 4819 (i.e., the presentation description) or any associated message body 4820 headers is named an entity for a better understanding. 4822 However, there might be cases when a server prefers to change the 4823 validator only on semantically significant changes, and not when 4824 insignificant aspects of the entity change. A validator that does 4825 not always change when the resource changes is a "weak validator." 4827 Message body tags are normally "strong validators," but the protocol 4828 provides a mechanism to tag a message body tag as "weak." One can 4829 think of a strong validator as one that changes whenever the bits of 4830 an entity changes, while a weak value changes whenever the meaning of 4831 an entity changes. Alternatively, one can think of a strong 4832 validator as part of an identifier for a specific entity, while a 4833 weak validator is part of an identifier for a set of semantically 4834 equivalent entities. 4836 Note: One example of a strong validator is an integer that is 4837 incremented in stable storage every time an entity is changed. 4839 An entity's modification time, if represented with one-second 4840 resolution, could be a weak validator, since it is possible that 4841 the resource might be modified twice during a single second. 4843 Support for weak validators is optional. However, weak validators 4844 allow for more efficient caching of equivalent objects. 4846 A "use" of a validator is either when a client generates a request 4847 and includes the validator in a validating header field, or when a 4848 server compares two validators. 4850 Strong validators are usable in any context. Weak validators are 4851 only usable in contexts that do not depend on exact equality of an 4852 entity. For example, either kind is usable for a conditional 4853 DESCRIBE of a full entity. However, only a strong validator is 4854 usable for a sub-range retrieval, since otherwise the client might 4855 end up with an internally inconsistent entity. 4857 Clients MAY issue DESCRIBE requests with either weak validators or 4858 strong validators. Clients MUST NOT use weak validators in other 4859 forms of requests. 4861 The only function that the RTSP protocol defines on validators is 4862 comparison. There are two validator comparison functions, depending 4863 on whether the comparison context allows the use of weak validators 4864 or not: 4866 o The strong comparison function: in order to be considered equal, 4867 both validators MUST be identical in every way, and both MUST NOT 4868 be weak. 4870 o The weak comparison function: in order to be considered equal, 4871 both validators MUST be identical in every way, but either or both 4872 of them MAY be tagged as "weak" without affecting the result. 4874 A message body tag is strong unless it is explicitly tagged as weak. 4876 A Last-Modified time, when used as a validator in a request, is 4877 implicitly weak unless it is possible to deduce that it is strong, 4878 using the following rules: 4880 o The validator is being compared by an origin server to the actual 4881 current validator for the entity and, 4883 o That origin server reliably knows that the associated entity did 4884 not change more than once during the second covered by the 4885 presented validator. 4887 OR 4889 o The validator is about to be used by a client in an If-Modified- 4890 Since, because the client has a cache entry for the associated 4891 entity, and 4893 o That cache entry includes a Date value, which gives the time when 4894 the origin server sent the original response, and 4896 o The presented Last-Modified time is at least 60 seconds before the 4897 Date value. 4899 OR 4901 o The validator is being compared by an intermediate cache to the 4902 validator stored in its cache entry for the entity, and 4904 o That cache entry includes a Date value, which gives the time when 4905 the origin server sent the original response, and 4907 o The presented Last-Modified time is at least 60 seconds before the 4908 Date value. 4910 This method relies on the fact that if two different responses were 4911 sent by the origin server during the same second, but both had the 4912 same Last-Modified time, then at least one of those responses would 4913 have a Date value equal to its Last-Modified time. The arbitrary 60- 4914 second limit guards against the possibility that the Date and Last- 4915 Modified values are generated from different clocks, or at somewhat 4916 different times during the preparation of the response. An 4917 implementation MAY use a value larger than 60 seconds, if it is 4918 believed that 60 seconds is too short. 4920 If a client wishes to perform a sub-range retrieval on a value for 4921 which it has only a Last-Modified time and no opaque validator, it 4922 MAY do this only if the Last-Modified time is strong in the sense 4923 described here. 4925 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates 4927 This document adopt a set of rules and recommendations for origin 4928 servers, clients, and caches regarding when various validator types 4929 ought to be used, and for what purposes. 4931 RTSP origin servers: 4933 o SHOULD send a message body tag validator unless it is not feasible 4934 to generate one. 4936 o MAY send a weak message body tag instead of a strong message body 4937 tag, if performance considerations support the use of weak message 4938 body tags, or if it is unfeasible to send a strong message body 4939 tag. 4941 o SHOULD send a Last-Modified value if it is feasible to send one, 4942 unless the risk of a breakdown in semantic transparency that could 4943 result from using this date in an If-Modified-Since header would 4944 lead to serious problems. 4946 In other words, the preferred behavior for an RTSP origin server is 4947 to send both a strong message body tag and a Last-Modified value. 4949 In order to be legal, a strong message body tag MUST change whenever 4950 the associated entity value changes in any way. A weak message body 4951 tag SHOULD change whenever the associated entity changes in a 4952 semantically significant way. 4954 Note: in order to provide semantically transparent caching, an 4955 origin server MUST avoid reusing a specific strong message body 4956 tag value for two different entities, or reusing a specific weak 4957 message body tag value for two semantically different entities. 4958 Cache entries might persist for arbitrarily long periods, 4959 regardless of expiration times, so it might be inappropriate to 4960 expect that a cache will never again attempt to validate an entry 4961 using a validator that it obtained at some point in the past. 4963 RTSP clients: 4965 o If a message body tag has been provided by the origin server, MUST 4966 use that message body tag in any cache-conditional request (using 4967 If-Match or If-None-Match). 4969 o If only a Last-Modified value has been provided by the origin 4970 server, SHOULD use that value in non-subrange cache-conditional 4971 requests (using If-Modified-Since). 4973 o If both a message body tag and a Last-Modified value have been 4974 provided by the origin server, SHOULD use both validators in 4975 cache-conditional requests. 4977 An RTSP origin server, upon receiving a conditional request that 4978 includes both a Last-Modified date (e.g., in an If-Modified-Since 4979 header) and one or more message body tags (e.g., in an If-Match, If- 4980 None-Match, or If-Range header field) as cache validators, MUST NOT 4981 return a response status of 304 (Not Modified) unless doing so is 4982 consistent with all of the conditional header fields in the request. 4984 Note: The general principle behind these rules is that RTSP 4985 servers and clients should transmit as much non-redundant 4986 information as is available in their responses and requests. RTSP 4987 systems receiving this information will make the most conservative 4988 assumptions about the validators they receive. 4990 16.1.5. Non-validating Conditionals 4992 The principle behind message body tags is that only the service 4993 author knows the semantics of a resource well enough to select an 4994 appropriate cache validation mechanism, and the specification of any 4995 validator comparison function more complex than octet-equality would 4996 open up a can of worms. Thus, comparisons of any other headers are 4997 never used for purposes of validating a cache entry. 4999 16.2. Invalidation After Updates or Deletions 5001 The effect of certain methods performed on a resource at the origin 5002 server might cause one or more existing cache entries to become non- 5003 transparently invalid. That is, although they might continue to be 5004 "fresh," they do not accurately reflect what the origin server would 5005 return for a new request on that resource. 5007 There is no way for the RTSP protocol to guarantee that all such 5008 cache entries are marked invalid. For example, the request that 5009 caused the change at the origin server might not have gone through 5010 the proxy where a cache entry is stored. However, several rules help 5011 reduce the likelihood of erroneous behavior. 5013 In this section, the phrase "invalidate an entity" means that the 5014 cache will either remove all instances of that entity from its 5015 storage, or will mark these as "invalid" and in need of a mandatory 5016 revalidation before they can be returned in response to a subsequent 5017 request. 5019 Some RTSP methods MUST cause a cache to invalidate an entity. This 5020 is either the entity referred to by the Request-URI, or by the 5021 Location or Content-Location headers (if present). These methods 5022 are: 5024 o DESCRIBE 5026 o SETUP 5028 In order to prevent denial of service attacks, an invalidation based 5029 on the URI in a Location or Content-Location header MUST only be 5030 performed if the host part is the same as in the Request-URI. 5032 A cache that passes through requests for methods it does not 5033 understand SHOULD invalidate any entities referred to by the Request- 5034 URI. 5036 17. Status Code Definitions 5038 Where applicable, HTTP status [H10] codes are reused. See Table 4 in 5039 Section 8.1 for a listing of which status codes may be returned by 5040 which requests. All error messages, 4xx and 5xx MAY return a body 5041 containing further information about the error. 5043 17.1. Informational 1xx 5045 17.1.1. 100 Continue 5047 The client SHOULD continue with its request. This interim response 5048 is used to inform the client that the initial part of the request has 5049 been received and has not yet been rejected by the server. The 5050 client SHOULD continue by sending the remainder of the request or, if 5051 the request has already been completed, ignore this response. The 5052 server MUST send a final response after the request has been 5053 completed. 5055 17.2. Success 2xx 5057 This class of status code indicates that the client's request was 5058 successfully received, understood, and accepted. 5060 17.2.1. 200 OK 5062 The request has succeeded. The information returned with the 5063 response is dependent on the method used in the request. 5065 17.3. Redirection 3xx 5067 The notation "3xx" indicates response codes from 300 to 399 inclusive 5068 which are meant for redirection. The response code 304 is excluded, 5069 as it is not used for redirection and instead the "3rr" notation is 5070 used. The 304 response code appears here, rather than a 2xx response 5071 code which would have been appropriate, this as 304 has been used 5072 also in RTSP 1.0 [RFC2326]. 5074 Within RTSP, redirection may be used for load balancing or 5075 redirecting stream requests to a server topologically closer to the 5076 client. Mechanisms to determine topological proximity are beyond the 5077 scope of this specification. 5079 A 3rr code MAY be used to respond to any request. The Location 5080 header MUST be included in any 3rr response. It is RECOMMENDED that 5081 they are used if necessary before a session is established, i.e., in 5082 response to DESCRIBE or SETUP. However, in cases where a server is 5083 not able to send a REDIRECT request to the client, the server MAY 5084 need to resort to using 3rr responses to inform a client with an 5085 established session about the need for redirecting the session. If a 5086 3rr response is received for a request in relation to an established 5087 session, the client SHOULD send a TEARDOWN request for the session, 5088 and MAY reestablish the session using the resource indicated by the 5089 Location. 5091 If the Location header is used in a response it MUST contain an 5092 absolute URI pointing out the media resource the client is redirected 5093 to, the URI MUST NOT only contain the host name. 5095 In the event that an unknown 3rr status code is received, the agent 5096 SHOULD behave as if a 302 response code had been received 5097 (Section 17.3.3). 5099 17.3.1. 300 5101 This response code is not used in RTSP 2.0. 5103 17.3.2. 301 Moved Permanently 5105 The requested resource is moved permanently and resides now at the 5106 URI given by the Location header. The user client SHOULD redirect 5107 automatically to the given URI. This response MUST NOT contain a 5108 message-body. The Location header MUST be included in the response. 5110 17.3.3. 302 Found 5112 The requested resource resides temporarily at the URI given by the 5113 Location header. This response is intended to be used for many types 5114 of temporary redirects; e.g., load balancing. It is RECOMMENDED that 5115 the server set the reason phrase to something more meaningful than 5116 "Found" in these cases. The user client SHOULD redirect 5117 automatically to the given URI. This response MUST NOT contain a 5118 message-body. 5120 This example shows a client being redirected to a different server: 5122 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 5123 CSeq: 2 5124 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 5125 Accept-Ranges: npt, smpte, clock 5126 User-Agent: PhonyClient/1.2 5128 S->C: RTSP/2.0 302 Try Other Server 5129 CSeq: 2 5130 Location: rtsp://s2.example.com:8001/fizzle/foo 5132 17.3.4. 303 See Other 5134 This status code MUST NOT be used in RTSP 2.0. However, it was 5135 allowed in RTSP 1.0 [RFC2326]. 5137 17.3.5. 304 Not Modified 5139 If the client has performed a conditional DESCRIBE or SETUP (see 5140 Section 18.25) and the requested resource has not been modified, the 5141 server SHOULD send a 304 response. This response MUST NOT contain a 5142 message-body. 5144 The response MUST include the following header fields: 5146 o Date 5147 o MTag and/or Content-Location, if the header(s) would have been 5148 sent in a 200 response to the same request. 5150 o Expires and Cache-Control if the field-value might differ from 5151 that sent in any previous response for the same variant. 5153 This response is independent for the DESCRIBE and SETUP requests. 5154 That is, a 304 response to DESCRIBE does NOT imply that the resource 5155 content is unchanged (only the session description) and a 304 5156 response to SETUP does NOT imply that the resource description is 5157 unchanged. The MTag and If-Match headers may be used to link the 5158 DESCRIBE and SETUP in this manner. 5160 17.3.6. 305 Use Proxy 5162 The requested resource MUST be accessed through the proxy given by 5163 the Location field. The Location field gives the URI of the proxy. 5164 The recipient is expected to repeat this single request via the 5165 proxy. 305 responses MUST only be generated by origin servers. 5167 17.4. Client Error 4xx 5169 17.4.1. 400 Bad Request 5171 The request could not be understood by the server due to malformed 5172 syntax. The client SHOULD NOT repeat the request without 5173 modifications. If the request does not have a CSeq header, the 5174 server MUST NOT include a CSeq in the response. 5176 17.4.2. 401 Unauthorized 5178 The request requires user authentication. The response MUST include 5179 a WWW-Authenticate header (Section 18.58) field containing a 5180 challenge applicable to the requested resource. The client MAY 5181 repeat the request with a suitable Authorization header field. If 5182 the request already included Authorization credentials, then the 401 5183 response indicates that authorization has been refused for those 5184 credentials. If the 401 response contains the same challenge as the 5185 prior response, and the user agent has already attempted 5186 authentication at least once, then the user SHOULD be presented the 5187 message body that was given in the response, since that message body 5188 might include relevant diagnostic information. HTTP access 5189 authentication is explained in [RFC2617]. 5191 17.4.3. 402 Payment Required 5193 This code is reserved for future use. 5195 17.4.4. 403 Forbidden 5197 The server understood the request, but is refusing to fulfill it. 5198 Authorization will not help and the request SHOULD NOT be repeated. 5199 If the server wishes to make public why the request has not been 5200 fulfilled, it SHOULD describe the reason for the refusal in the 5201 message body. If the server does not wish to make this information 5202 available to the client, the status code 404 (Not Found) can be used 5203 instead. 5205 17.4.5. 404 Not Found 5207 The server has not found anything matching the Request-URI. No 5208 indication is given of whether the condition is temporary or 5209 permanent. The 410 (Gone) status code SHOULD be used if the server 5210 knows, through some internally configurable mechanism, that an old 5211 resource is permanently unavailable and has no forwarding address. 5212 This status code is commonly used when the server does not wish to 5213 reveal exactly why the request has been refused, or when no other 5214 response is applicable. 5216 17.4.6. 405 Method Not Allowed 5218 The method specified in the request is not allowed for the resource 5219 identified by the Request-URI. The response MUST include an Allow 5220 header containing a list of valid methods for the requested resource. 5221 This status code is also to be used if a request attempts to use a 5222 method not indicated during SETUP. 5224 17.4.7. 406 Not Acceptable 5226 The resource identified by the request is only capable of generating 5227 response message bodies which have content characteristics not 5228 acceptable according to the Accept headers sent in the request. 5230 The response SHOULD include a message body containing a list of 5231 available message body characteristics and location(s) from which the 5232 user or user agent can choose the one most appropriate. The message 5233 body format is specified by the media type given in the Content-Type 5234 header field. Depending upon the format and the capabilities of the 5235 user agent, selection of the most appropriate choice MAY be performed 5236 automatically. However, this specification does not define any 5237 standard for such automatic selection. 5239 If the response could be unacceptable, a user agent SHOULD 5240 temporarily stop receipt of more data and query the user for a 5241 decision on further actions. 5243 17.4.8. 407 Proxy Authentication Required 5245 This code is similar to 401 (Unauthorized) (Section 17.4.2), but 5246 indicates that the client must first authenticate itself with the 5247 proxy. The proxy MUST return a Proxy-Authenticate header field 5248 (Section 18.34) containing a challenge applicable to the proxy for 5249 the requested resource. 5251 17.4.9. 408 Request Timeout 5253 The client did not produce a request within the time that the server 5254 was prepared to wait. The client MAY repeat the request without 5255 modifications at any later time. 5257 17.4.10. 410 Gone 5259 The requested resource is no longer available at the server and the 5260 forwarding address is not known. This condition is expected to be 5261 considered permanent. If the server does not know, or has no 5262 facility to determine, whether or not the condition is permanent, the 5263 status code 404 (Not Found) SHOULD be used instead. This response is 5264 cacheable unless indicated otherwise. 5266 The 410 response is primarily intended to assist the task of 5267 repository maintenance by notifying the recipient that the resource 5268 is intentionally unavailable and that the server owners desire that 5269 remote links to that resource be removed. Such an event is common 5270 for limited-time, promotional services and for resources belonging to 5271 individuals no longer working at the server's site. It is not 5272 necessary to mark all permanently unavailable resources as "gone" or 5273 to keep the mark for any length of time -- that is left to the 5274 discretion of the owner of the server. 5276 17.4.11. 411 Length Required 5278 This error code is not defined for RTSP. This as the use of Content- 5279 Length (Section 18.17) is always required when message bodies are 5280 included in RTSP messages. 5282 17.4.12. 412 Precondition Failed 5284 The precondition given in one or more of the 'if-' request-header 5285 fields evaluated to false when it was tested on the server. See 5286 these sections for the 'if-' headers: If-Match Section 18.24, If- 5287 Modified-Since Section 18.25, and If-None-Match Section 18.26. This 5288 response code allows the client to place preconditions on the current 5289 resource meta information (header field data) and thus prevent the 5290 requested method from being applied to a resource other than the one 5291 intended. 5293 17.4.13. 413 Request Message Body Too Large 5295 The server is refusing to process a request because the request 5296 message body is larger than the server is willing or able to process. 5297 The server MAY close the connection to prevent the client from 5298 continuing the request. 5300 If the condition is temporary, the server SHOULD include a Retry- 5301 After header field to indicate that it is temporary and after what 5302 time the client MAY try again. 5304 17.4.14. 414 Request-URI Too Long 5306 The server is refusing to service the request because the Request-URI 5307 is longer than the server is willing to interpret. This rare 5308 condition is only likely to occur when a client has used a request 5309 with long query information, when the client has descended into a URI 5310 "black hole" of redirection (e.g., a redirected URI prefix that 5311 points to a suffix of itself), or when the server is under attack by 5312 a client attempting to exploit security holes present in some servers 5313 using fixed-length buffers for reading or manipulating the Request- 5314 URI. 5316 17.4.15. 415 Unsupported Media Type 5318 The server is refusing to service the request because the message 5319 body of the request is in a format not supported by the requested 5320 resource for the requested method. 5322 17.4.16. 451 Parameter Not Understood 5324 The recipient of the request does not support one or more parameters 5325 contained in the request. When returning this error message the 5326 sender SHOULD return a message body containing the offending 5327 parameter(s). 5329 17.4.17. 452 reserved 5331 This status code MUST NOT be used in RTSP 2.0. However, it was 5332 allowed in RTSP 1.0 [RFC2326]. 5334 17.4.18. 453 Not Enough Bandwidth 5336 The request was refused because there was insufficient bandwidth. 5337 This may, for example, be the result of a resource reservation 5338 failure. 5340 17.4.19. 454 Session Not Found 5342 The RTSP session identifier in the Session header is missing, 5343 invalid, or has timed out. 5345 17.4.20. 455 Method Not Valid in This State 5347 The client or server cannot process this request in its current 5348 state. The response MUST contain an Allow header to make error 5349 recovery possible. 5351 17.4.21. 456 Header Field Not Valid for Resource 5353 The server could not act on a required request-header. For example, 5354 if PLAY contains the Range header field but the stream does not allow 5355 seeking. This error message may also be used for specifying when the 5356 time format in Range is impossible for the resource. In that case 5357 the Accept-Ranges header MUST be returned to inform the client of 5358 which format(s) that are allowed. 5360 17.4.22. 457 Invalid Range 5362 The Range value given is out of bounds, e.g., beyond the end of the 5363 presentation. 5365 17.4.23. 458 Parameter Is Read-Only 5367 The parameter to be set by SET_PARAMETER can be read but not 5368 modified. When returning this error message the sender SHOULD return 5369 a message body containing the offending parameter(s). 5371 17.4.24. 459 Aggregate Operation Not Allowed 5373 The requested method may not be applied on the URI in question since 5374 it is an aggregate (presentation) URI. The method may be applied on 5375 a media URI. 5377 17.4.25. 460 Only Aggregate Operation Allowed 5379 The requested method may not be applied on the URI in question since 5380 it is not an aggregate control (presentation) URI. The method may be 5381 applied on the aggregate control URI. 5383 17.4.26. 461 Unsupported Transport 5385 The Transport field did not contain a supported transport 5386 specification. 5388 17.4.27. 462 Destination Unreachable 5390 The data transmission channel could not be established because the 5391 client address could not be reached. This error will most likely be 5392 the result of a client attempt to place an invalid dest_addr 5393 parameter in the Transport field. 5395 17.4.28. 463 Destination Prohibited 5397 The data transmission channel was not established because the server 5398 prohibited access to the client address. This error is most likely 5399 the result of a client attempt to redirect media traffic to another 5400 destination with a dest_addr parameter in the Transport header. 5402 17.4.29. 464 Data Transport Not Ready Yet 5404 The data transmission channel to the media destination is not yet 5405 ready for carrying data. However, the responding agent still expects 5406 that the data transmission channel will be established at some point 5407 in time. Note, however, that this may result in a permanent failure 5408 like 462 "Destination Unreachable". 5410 An example when this error may occur is in the case a client sends a 5411 PLAY request to a server prior to ensuring that the TCP connections 5412 negotiated for carrying media data was successfully established (In 5413 violation of this specification). The server would use this error 5414 code to indicate that the requested action could not be performed due 5415 to the failure of completing the connection establishment. 5417 17.4.30. 465 Notification Reason Unknown 5419 This indicates that the client has received a PLAY_NOTIFY 5420 (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to 5421 the client. 5423 17.4.31. 466 Key Management Error 5425 This indicates that there has been an error in a Key Management 5426 function used in conjunction with a request. For example usage of 5427 MIKEY [RFC3830] according to Appendix C.1.4.1 may result in this 5428 error. 5430 17.4.32. 470 Connection Authorization Required 5432 The secured connection attempt needs user or client authorization 5433 before proceeding. The next hop's certificate is included in this 5434 response in the Accept-Credentials header. 5436 17.4.33. 471 Connection Credentials not accepted 5438 When performing a secure connection over multiple connections, an 5439 intermediary has refused to connect to the next hop and carry out the 5440 request due to unacceptable credentials for the used policy. 5442 17.4.34. 472 Failure to establish secure connection 5444 A proxy fails to establish a secure connection to the next hop RTSP 5445 agent. This is primarily caused by a fatal failure at the TLS 5446 handshake, for example due to server not accepting any cipher suites. 5448 17.5. Server Error 5xx 5450 Response status codes beginning with the digit "5" indicate cases in 5451 which the server is aware that it has erred or is incapable of 5452 performing the request The server SHOULD include a message body 5453 containing an explanation of the error situation, and whether it is a 5454 temporary or permanent condition. User agents SHOULD display any 5455 included message body to the user. These response codes are 5456 applicable to any request method. 5458 17.5.1. 500 Internal Server Error 5460 The server encountered an unexpected condition which prevented it 5461 from fulfilling the request. 5463 17.5.2. 501 Not Implemented 5465 The server does not support the functionality required to fulfill the 5466 request. This is the appropriate response when the server does not 5467 recognize the request method and is not capable of supporting it for 5468 any resource. 5470 17.5.3. 502 Bad Gateway 5472 The server, while acting as a gateway or proxy, received an invalid 5473 response from the upstream server it accessed in attempting to 5474 fulfill the request. 5476 17.5.4. 503 Service Unavailable 5478 The server is currently unable to handle the request due to a 5479 temporary overloading or maintenance of the server. The implication 5480 is that this is a temporary condition which will be alleviated after 5481 some delay. If known, the length of the delay MAY be indicated in a 5482 Retry-After header. If no Retry-After is given, the client SHOULD 5483 handle the response as it would for a 500 response. The client MUST 5484 honor the length, if given in the Retry-After header. 5486 Note: The existence of the 503 status code does not imply that 5487 a server must use it when becoming overloaded. Some servers 5488 may wish to simply refuse the connection. 5490 The response scope is dependent on the Request. If the request was 5491 in relation to an existing RTSP session, the scope of the overload 5492 response is to this individual RTSP session. If the request was non- 5493 session specific or intended to form a RTSP session it applies to the 5494 RTSP server identified by the host name in the request URI. 5496 17.5.5. 504 Gateway Timeout 5498 The server, while acting as a proxy, did not receive a timely 5499 response from the upstream server specified by the URI or some other 5500 auxiliary server (e.g., DNS) it needed to access in attempting to 5501 complete the request. 5503 17.5.6. 505 RTSP Version Not Supported 5505 The server does not support, or refuses to support, the RTSP protocol 5506 version that was used in the request message. The server is 5507 indicating that it is unable or unwilling to complete the request 5508 using the same major version as the client other than with this error 5509 message. The response SHOULD contain a message body describing why 5510 that version is not supported and what other protocols are supported 5511 by that server. 5513 17.5.7. 551 Option not supported 5515 A feature-tag given in the Require or the Proxy-Require fields was 5516 not supported. The Unsupported header MUST be returned stating the 5517 feature for which there is no support. 5519 17.5.8. 553 Proxy Unavailable 5521 The proxy is currently unable to handle the request due to a 5522 temporary overloading or maintenance of the proxy. The implication 5523 is that this is a temporary condition which will be alleviated after 5524 some delay. If known, the length of the delay MAY be indicated in a 5525 Retry-After header. If no Retry-After is given, the client SHOULD 5526 handle the response as it would for a 500 response. The client MUST 5527 honor the length, if given in the Retry-After header. 5529 Note: The existence of the 553 status code does not imply that 5530 a proxy must use it when becoming overloaded. Some proxies may 5531 wish to simply refuse the connection. 5533 The response scope is dependent on the Request. If the request was 5534 in relation to an existing RTSP session, the scope of the overload 5535 response is to this individual RTSP session. If the request was non- 5536 session specific or intended to form a RTSP session it applies to all 5537 such requests to this proxy. 5539 18. Header Field Definitions 5541 +---------------+----------------+--------+---------+------+ 5542 | method | direction | object | acronym | Body | 5543 +---------------+----------------+--------+---------+------+ 5544 | DESCRIBE | C -> S | P,S | DES | r | 5545 | | | | | | 5546 | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | 5547 | | | | | | 5548 | OPTIONS | C -> S, S -> C | P,S | OPT | | 5549 | | | | | | 5550 | PAUSE | C -> S | P,S | PSE | | 5551 | | | | | | 5552 | PLAY | C -> S | P,S | PLY | | 5553 | | | | | | 5554 | PLAY_NOTIFY | S -> C | P,S | PNY | R | 5555 | | | | | | 5556 | REDIRECT | S -> C | P,S | RDR | | 5557 | | | | | | 5558 | SETUP | C -> S | S | STP | | 5559 | | | | | | 5560 | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | 5561 | | | | | | 5562 | TEARDOWN | C -> S | P,S | TRD | | 5563 | | | | | | 5564 | | S -> C | P | TRD | | 5565 +---------------+----------------+--------+---------+------+ 5567 Table 8: Overview of RTSP methods, their direction, and what objects 5568 (P: presentation, S: stream) they operate on. Body notes if a method 5569 is allowed to carry body and in which direction, R = Request, 5570 r=response. Note: All error messages for statuses 4xx and 5xx are 5571 allowed to carry a body 5573 The general syntax for header fields is covered in Section 5.2. This 5574 section lists the full set of header fields along with notes on 5575 meaning, and usage. The syntax definition for header fields are 5576 present in Section 20.2.3. Throughout this section, [HX.Y] is used 5577 to reference Section X.Y of the HTTP/1.1 specification RFC 2616 5578 [RFC2616]. Examples of each header field are given. 5580 Information about header fields in relation to methods and proxy 5581 processing is summarized in Table 9, Table 10, Table 11, and 5582 Table 12. 5584 The "where" column describes the request and response types in which 5585 the header field can be used. Values in this column are: 5587 R: header field may only appear in requests; 5589 r: header field may only appear in responses; 5591 2xx, 4xx, etc.: A numerical value or range indicates response codes 5592 with which the header field can be used; 5594 c: header field is copied from the request to the response. 5596 G: header field is a general-header and may be present in both 5597 requests and responses. 5599 Note: General headers does not always use the "G" value in the where 5600 column. This is due to differencies when the header may be applied 5601 in requests compared to responses. When such differencies exist they 5602 are expressed using two differet rows, one with where being "R" and 5603 one with it being "r". 5605 The "proxy" column describes the operations a proxy may perform on a 5606 header field. An empty proxy column indicates that the proxy MUST 5607 NOT do any changes to that header, all allowed operations are 5608 explicitly stated: 5610 a: A proxy can add or concatenate the header field if not present. 5612 m: A proxy can modify an existing header field value. 5614 d: A proxy can delete a header field value. 5616 r: A proxy needs to be able to read the header field, and thus 5617 this header field cannot be encrypted. 5619 The rest of the columns relate to the presence of a header field in a 5620 method. The method names when abbreviated, are according to Table 8: 5622 c: Conditional; requirements on the header field depend on the 5623 context of the message. 5625 m: The header field is mandatory. 5627 m*: The header field SHOULD be sent, but clients/servers need to be 5628 prepared to receive messages without that header field. 5630 o: The header field is optional. 5632 *: The header field MUST be present if the message body is not 5633 empty. See Section 18.17, Section 18.19 and Section 5.3 for 5634 details. 5636 -: The header field is not applicable. 5638 "Optional" means that a Client/Server MAY include the header field in 5639 a request or response. The Client/Server behavior when receiving 5640 such headers varies, for some it may ignore the header field, in 5641 other cases it is a request to process the header. This is regulated 5642 by the method and header descriptions. Example of headers that 5643 require processing are the Require and Proxy-Require header fields 5644 discussed in Section 18.43 and Section 18.37. A "mandatory" header 5645 field MUST be present in a request, and MUST be understood by the 5646 Client/Server receiving the request. A mandatory response-header 5647 field MUST be present in the response, and the header field MUST be 5648 understood by the Client/Server processing the response. "Not 5649 applicable" means that the header field MUST NOT be present in a 5650 request. If one is placed in a request by mistake, it MUST be 5651 ignored by the Client/Server receiving the request. Similarly, a 5652 header field labeled "not applicable" for a response means that the 5653 Client/Server MUST NOT place the header field in the response, and 5654 the Client/Server MUST ignore the header field in the response. 5656 An RTSP agent MUST ignore extension headers that are not understood. 5658 The From and Location header fields contain a URI. If the URI 5659 contains a comma, or semicolon, the URI MUST be enclosed in double 5660 quotes ("). Any URI parameters are contained within these quotes. 5661 If the URI is not enclosed in double quote, any semicolon-delimited 5662 parameters are header-parameters, not URI parameters. 5664 +-------------------+------+------+----+----+-----+-----+-----+-----+ 5665 | Header | Wher | Prox | DE | OP | STP | PLY | PSE | TRD | 5666 | | e | y | S | T | | | | | 5667 +-------------------+------+------+----+----+-----+-----+-----+-----+ 5668 | Accept | R | | o | - | - | - | - | - | 5669 | | | | | | | | | | 5670 | Accept- | R | rm | o | o | o | o | o | o | 5671 | Credentials | | | | | | | | | 5672 | | | | | | | | | | 5673 | Accept-Encoding | R | r | o | - | - | - | - | - | 5674 | | | | | | | | | | 5675 | Accept-Language | R | r | o | - | - | - | - | - | 5676 | | | | | | | | | | 5677 | Accept-Ranges | G | r | - | - | m | - | - | - | 5678 | | | | | | | | | | 5679 | Accept-Ranges | 456 | r | - | - | - | m | - | - | 5680 | | | | | | | | | | 5681 | Allow | r | am | c | c | c | - | - | - | 5682 | | | | | | | | | | 5683 | Allow | 405 | am | m | m | m | m | m | m | 5684 | | | | | | | | | | 5685 | Authentication- | r | | o | o | o | o | o | o/- | 5686 | Info | | | | | | | | | 5687 | | | | | | | | | | 5688 | Authorization | R | | o | o | o | o | o | o | 5689 | | | | | | | | | | 5690 | Bandwidth | R | | o | o | o | o | - | - | 5691 | | | | | | | | | | 5692 | Blocksize | R | | o | - | o | o | - | - | 5693 | | | | | | | | | | 5694 | Cache-Control | G | r | o | - | o | - | - | - | 5695 | | | | | | | | | | 5696 | Connection | G | ad | o | o | o | o | o | o | 5697 | | | | | | | | | | 5698 | Connection- | 470, | ar | o | o | o | o | o | o | 5699 | Credentials | 407 | | | | | | | | 5700 | | | | | | | | | | 5701 | Content-Base | r | | o | - | - | - | - | - | 5702 | | | | | | | | | | 5703 | Content-Base | 4xx, | | o | o | o | o | o | o | 5704 | | 5xx | | | | | | | | 5705 | | | | | | | | | | 5706 | Content-Encoding | R | r | - | - | - | - | - | - | 5707 | | | | | | | | | | 5708 | Content-Encoding | r | r | o | - | - | - | - | - | 5709 | | | | | | | | | | 5710 | Content-Encoding | 4xx, | r | o | o | o | o | o | o | 5711 | | 5xx | | | | | | | | 5712 | | | | | | | | | | 5713 | Content-Language | R | r | - | - | - | - | - | - | 5714 | | | | | | | | | | 5715 | Content-Language | r | r | o | - | - | - | - | - | 5716 | | | | | | | | | | 5717 | Content-Language | 4xx, | r | o | o | o | o | o | o | 5718 | | 5xx | | | | | | | | 5719 | | | | | | | | | | 5720 | Content-Length | r | r | * | - | - | - | - | - | 5721 | | | | | | | | | | 5722 | Content-Length | 4xx, | r | * | * | * | * | * | * | 5723 | | 5xx | | | | | | | | 5724 | | | | | | | | | | 5725 | Content-Location | r | r | o | - | - | - | - | - | 5726 | | | | | | | | | | 5727 | Content-Location | 4xx, | r | o | o | o | o | o | o | 5728 | | 5xx | | | | | | | | 5729 | | | | | | | | | | 5730 | Content-Type | r | r | * | - | - | - | - | - | 5731 | | | | | | | | | | 5732 | Content-Type | 4xx, | ar | * | * | * | * | * | * | 5733 | | 5xx | | | | | | | | 5734 | | | | | | | | | | 5735 | CSeq | Gc | rm | m | m | m | m | m | m | 5736 | | | | | | | | | | 5737 | Date | G | am | o/ | o/ | o/* | o/* | o/* | o/* | 5738 | | | | * | * | | | | | 5739 | | | | | | | | | | 5740 | Expires | r | r | o | - | o | - | - | - | 5741 | | | | | | | | | | 5742 | From | R | r | o | o | o | o | o | o | 5743 | | | | | | | | | | 5744 | If-Match | R | r | - | - | o | - | - | - | 5745 | | | | | | | | | | 5746 | If-Modified-Since | R | r | o | - | o | - | - | - | 5747 | | | | | | | | | | 5748 | If-None-Match | R | r | o | - | o | - | - | - | 5749 | | | | | | | | | | 5750 | Last-Modified | r | r | o | - | o | - | - | - | 5751 | | | | | | | | | | 5752 | Location | 3rr | | o | o | o | o | o | o | 5753 +-------------------+------+------+----+----+-----+-----+-----+-----+ 5755 Table 9: Overview of RTSP header fields (A-L) related to methods 5756 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5758 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5759 | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | 5760 | | | xy | S | T | P | | | | 5761 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5762 | Media- | G | | - | - | m | m | m | - | 5763 | Properties | | | | | | | | | 5764 | | | | | | | | | | 5765 | Media-Range | G | | - | - | m | m | m | - | 5766 | | | | | | | | | | 5767 | MTag | r | r | o | - | o | - | - | - | 5768 | | | | | | | | | | 5769 | Pipelined- | G | amd | - | o | o | o | o | o | 5770 | Requests | | r | | | | | | | 5771 | | | | | | | | | | 5772 | Proxy- | 407 | amr | m | m | m | m | m | m | 5773 | Authenticate | | | | | | | | | 5774 | | | | | | | | | | 5775 | Proxy- | r | amd | o | o | o | o | o | o/- | 5776 | Authentication- | | r | | | | | | | 5777 | Info | | | | | | | | | 5778 | | | | | | | | | | 5779 | Proxy- | R | rd | o | o | o | o | o | o | 5780 | Authorization | | | | | | | | | 5781 | | | | | | | | | | 5782 | Proxy- Require | R | ar | o | o | o | o | o | o | 5783 | | | | | | | | | | 5784 | Proxy- Require | r | r | c | c | c | c | c | c | 5785 | | | | | | | | | | 5786 | Proxy- Supported | R | amr | c | c | c | c | c | c | 5787 | | | | | | | | | | 5788 | Proxy- Supported | r | | c | c | c | c | c | c | 5789 | | | | | | | | | | 5790 | Public | r | amr | - | m | - | - | - | - | 5791 | | | | | | | | | | 5792 | Public | 501 | amr | m | m | m | m | m | m | 5793 | | | | | | | | | | 5794 | Range | R | | - | - | - | o | - | - | 5795 | | | | | | | | | | 5796 | Range | r | | - | - | c | m | m | - | 5797 | | | | | | | | | | 5798 | Referrer | R | | o | o | o | o | o | o | 5799 | | | | | | | | | | 5800 | Request- Status | R | | - | - | - | - | - | - | 5801 | | | | | | | | | | 5802 | Require | R | | o | o | o | o | o | o | 5803 | | | | | | | | | | 5804 | Retry-After | 3rr,503 | | o | o | o | o | o | - | 5805 | | ,553 | | | | | | | | 5806 | | | | | | | | | | 5807 | Retry-After | 413 | | o | - | - | - | - | - | 5808 | | | | | | | | | | 5809 | RTP-Info | r | | - | - | c | c | - | - | 5810 | | | | | | | | | | 5811 | Scale | R | r | - | - | - | o | - | - | 5812 | | | | | | | | | | 5813 | Scale | r | amr | - | - | - | c | - | - | 5814 | | | | | | | | | | 5815 | Seek-Style | R | | - | - | - | o | - | - | 5816 | | | | | | | | | | 5817 | Seek-Style | r | | - | - | - | m | - | - | 5818 | | | | | | | | | | 5819 | Server | R | r | - | o | - | - | - | o | 5820 | | | | | | | | | | 5821 | Server | r | r | o | o | o | o | o | o | 5822 | | | | | | | | | | 5823 | Session | R | r | - | o | o | m | m | m | 5824 | | | | | | | | | | 5825 | Session | r | r | - | c | m | m | m | o | 5826 | | | | | | | | | | 5827 | Speed | R | adm | - | - | - | o | - | - | 5828 | | | r | | | | | | | 5829 | | | | | | | | | | 5830 | Speed | r | adm | - | - | - | c | - | - | 5831 | | | r | | | | | | | 5832 | | | | | | | | | | 5833 | Supported | R | amr | o | o | o | o | o | o | 5834 | | | | | | | | | | 5835 | Supported | r | amr | c | c | c | c | c | c | 5836 | | | | | | | | | | 5837 | Terminate-Reason | R | r | - | - | - | - | - | - | 5838 | | | | | | | | | | 5839 | Timestamp | R | adm | o | o | o | o | o | o | 5840 | | | r | | | | | | | 5841 | | | | | | | | | | 5842 | Timestamp | c | adm | m | m | m | m | m | m | 5843 | | | r | | | | | | | 5844 | | | | | | | | | | 5845 | Transport | G | mr | - | - | m | - | - | - | 5846 | | | | | | | | | | 5847 | Unsupported | r | | c | c | c | c | c | c | 5848 | | | | | | | | | | 5849 | User-Agent | R | | m* | m* | m* | m* | m* | m* | 5850 | | | | | | | | | | 5851 | Via | R | amr | o | o | o | o | o | o | 5852 | | | | | | | | | | 5853 | Via | c | dr | m | m | m | m | m | m | 5854 | | | | | | | | | | 5855 | WWW- | 401 | | m | m | m | m | m | m | 5856 | Authenticate | | | | | | | | | 5857 +------------------+---------+-----+----+----+----+-----+-----+-----+ 5859 Table 10: Overview of RTSP header fields (M-W) related to methods 5860 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 5862 +---------------------------+-------+-------+-----+-----+-----+-----+ 5863 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5864 +---------------------------+-------+-------+-----+-----+-----+-----+ 5865 | Accept | R | arm | o | o | - | - | 5866 | | | | | | | | 5867 | Accept-Credentials | R | rm | o | o | o | - | 5868 | | | | | | | | 5869 | Accept-Encoding | R | r | o | o | o | - | 5870 | | | | | | | | 5871 | Accept-Language | R | r | o | o | o | - | 5872 | | | | | | | | 5873 | Accept-Ranges | G | rm | o | - | - | - | 5874 | | | | | | | | 5875 | Allow | 405 | amr | m | m | m | - | 5876 | | | | | | | | 5877 | Authentication-Info | r | | o/- | o/- | - | - | 5878 | | | | | | | | 5879 | Authorization | R | | o | o | o | - | 5880 | | | | | | | | 5881 | Bandwidth | R | | - | o | - | - | 5882 | | | | | | | | 5883 | Blocksize | R | | - | o | - | - | 5884 | | | | | | | | 5885 | Cache-Control | G | r | o | o | - | - | 5886 | | | | | | | | 5887 | Connection | G | | o | o | o | o | 5888 | | | | | | | | 5889 | Connection-Credentials | 470, | ar | o | o | o | - | 5890 | | 407 | | | | | | 5891 | | | | | | | | 5892 | Content-Base | R | | o | o | - | - | 5893 | | | | | | | | 5894 | Content-Base | r | | o | o | - | - | 5895 | | | | | | | | 5896 | Content-Base | 4xx, | | o | o | o | o | 5897 | | 5xx | | | | | | 5898 | | | | | | | | 5899 | Content-Encoding | R | r | o | o | - | - | 5900 | | | | | | | | 5901 | Content-Encoding | r | r | o | o | - | - | 5902 | | | | | | | | 5903 | Content-Encoding | 4xx, | r | o | o | o | o | 5904 | | 5xx | | | | | | 5905 | | | | | | | | 5906 | Content-Language | R | r | o | o | - | - | 5907 | | | | | | | | 5908 | Content-Language | r | r | o | o | - | - | 5909 | | | | | | | | 5910 | Content-Language | 4xx, | r | o | o | o | o | 5911 | | 5xx | | | | | | 5912 | | | | | | | | 5913 | Content-Length | R | r | * | * | - | - | 5914 | | | | | | | | 5915 | Content-Length | r | r | * | * | - | - | 5916 | | | | | | | | 5917 | Content-Length | 4xx, | r | * | * | * | * | 5918 | | 5xx | | | | | | 5919 | | | | | | | | 5920 | Content-Location | R | | o | o | - | - | 5921 | | | | | | | | 5922 | Content-Location | r | | o | o | - | - | 5923 | | | | | | | | 5924 | Content-Location | 4xx, | | o | o | o | o | 5925 | | 5xx | | | | | | 5926 | | | | | | | | 5927 | Content-Type | R | | * | * | - | - | 5928 | | | | | | | | 5929 | Content-Type | r | | * | * | - | - | 5930 | | | | | | | | 5931 | Content-Type | 4xx, | | * | * | * | * | 5932 | | 5xx | | | | | | 5933 | | | | | | | | 5934 | CSeq | R,c | mr | m | m | m | m | 5935 | | | | | | | | 5936 | Date | R | a | o | o | m | o | 5937 | | | | | | | | 5938 | Date | r | am | o | o | o | o | 5939 | | | | | | | | 5940 | Expires | r | r | - | - | - | - | 5941 | | | | | | | | 5942 | From | R | r | o | o | o | - | 5943 | | | | | | | | 5944 | If-Match | R | r | - | - | - | - | 5945 | | | | | | | | 5946 | If-Modified-Since | R | am | o | - | - | - | 5947 | | | | | | | | 5948 | If-None-Match | R | am | o | - | - | - | 5949 | | | | | | | | 5950 | Last-Modified | R | r | - | - | - | - | 5951 | | | | | | | | 5952 | Last-Modified | r | r | o | - | - | - | 5953 | | | | | | | | 5954 | Location | 3rr | | o | o | o | - | 5955 | | | | | | | | 5956 | Location | R | | - | - | m | - | 5957 | | | | | | | | 5958 | Media-Properties | R | amr | o | - | - | c | 5959 | | | | | | | | 5960 | Media-Properties | r | mr | c | - | - | - | 5961 | | | | | | | | 5962 | Media-Range | R | | o | - | - | c | 5963 | | | | | | | | 5964 | Media-Range | r | | c | - | - | - | 5965 | | | | | | | | 5966 | MTag | r | r | o | - | - | - | 5967 | | | | | | | | 5968 | Notify-Reason | R | | - | - | - | m | 5969 | | | | | | | | 5970 | Pipelined-Requests | R | amdr | o | o | - | - | 5971 | | | | | | | | 5972 | Proxy-Authenticate | 407 | amdr | m | m | m | - | 5973 | | | | | | | | 5974 | Proxy-Authentication-Info | r | amdr | o/- | o/- | - | - | 5975 | | | | | | | | 5976 | Proxy-Authorization | R | amdr | o | o | o | - | 5977 | | | | | | | | 5978 | Proxy-Require | R | ar | o | o | o | - | 5979 | | | | | | | | 5980 | Proxy-Supported | R | amr | c | c | c | - | 5981 | | | | | | | | 5982 | Proxy-Supported | r | | c | c | c | - | 5983 | | | | | | | | 5984 | Public | 501 | admr | m | m | m | - | 5985 +---------------------------+-------+-------+-----+-----+-----+-----+ 5987 Table 11: Overview of RTSP header fields (A-P) related to methods 5988 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 5990 +------------------+---------+-------+-----+-----+-----+-----+ 5991 | Header | Where | Proxy | GPR | SPR | RDR | PNY | 5992 +------------------+---------+-------+-----+-----+-----+-----+ 5993 | Range | R | | o | - | o | m | 5994 | | | | | | | | 5995 | Referrer | R | | o | o | o | - | 5996 | | | | | | | | 5997 | Request-Status | R | | - | - | - | c | 5998 | | | | | | | | 5999 | Require | R | r | o | o | o | - | 6000 | | | | | | | | 6001 | Retry-After | 3rr,503 | | o | o | - | - | 6002 | | | | | | | | 6003 | Retry-After | 413 | | o | o | - | - | 6004 | | | | | | | | 6005 | RTP-Info | R | r | o | - | - | C | 6006 | | | | | | | | 6007 | RTP-Info | r | r | c | - | - | - | 6008 | | | | | | | | 6009 | Scale | G | | - | - | - | c | 6010 | | | | | | | | 6011 | Seek-Style | G | | - | - | - | - | 6012 | | | | | | | | 6013 | Server | R | r | o | o | o | o | 6014 | | | | | | | | 6015 | Server | r | r | o | o | - | - | 6016 | | | | | | | | 6017 | Session | R | r | o | o | o | m | 6018 | | | | | | | | 6019 | Session | r | r | c | c | o | m | 6020 | | | | | | | | 6021 | Speed | G | | - | - | - | - | 6022 | | | | | | | | 6023 | Supported | R | adrm | o | o | o | - | 6024 | | | | | | | | 6025 | Supported | r | adrm | c | c | c | - | 6026 | | | | | | | | 6027 | Terminate-Reason | R | r | - | - | m | - | 6028 | | | | | | | | 6029 | Timestamp | R | adrm | o | o | o | - | 6030 | | | | | | | | 6031 | Timestamp | c | adrm | m | m | m | - | 6032 | | | | | | | | 6033 | Transport | G | mr | - | - | - | - | 6034 | | | | | | | | 6035 | Unsupported | r | arm | c | c | c | - | 6036 | | | | | | | | 6037 | User-Agent | R | r | m* | m* | - | - | 6038 | | | | | | | | 6039 | User-Agent | r | r | m* | m* | m* | m* | 6040 | | | | | | | | 6041 | Via | R | amr | o | o | o | - | 6042 | | | | | | | | 6043 | Via | c | dr | m | m | m | - | 6044 | | | | | | | | 6045 | WWW-Authenticate | 401 | | m | m | m | - | 6046 +------------------+---------+-------+-----+-----+-----+-----+ 6048 Table 12: Overview of RTSP header fields (R-W) related to methods 6049 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. 6051 18.1. Accept 6053 The Accept request-header field can be used to specify certain 6054 presentation description and parameter media types [RFC6838] which 6055 are acceptable for the response to DESCRIBE and GET_PARAMETER 6056 requests. 6058 See Section 20.2.3 for the syntax. 6060 The asterisk "*" character is used to group media types into ranges, 6061 with "*/*" indicating all media types and "type/*" indicating all 6062 subtypes of that type. The media-range MAY include media type 6063 parameters that are applicable to that range. 6065 Each media-range MAY be followed by one or more accept-params, 6066 beginning with the "q" parameter for indicating a relative quality 6067 factor. The first "q" parameter (if any) separates the media-range 6068 parameter(s) from the accept-params. Quality factors allow the user 6069 or user agent to indicate the relative degree of preference for that 6070 media-range, using the qvalue scale from 0 to 1 (section 3.9). The 6071 default value is q=1. 6073 Example of use: 6075 Accept: application/example ;q=0.7, application/sdp 6077 Indicates that the requesting agent prefers the media type 6078 application/sdp through the default 1.0 rating but also accepts the 6079 application/example media type with a 0.7 quality rating. 6081 If no Accept header field is present, then it is assumed that the 6082 client accepts all media types. If an Accept header field is 6083 present, and if the server cannot send a response which is acceptable 6084 according to the combined Accept field value, then the server SHOULD 6085 send a 406 (not acceptable) response. 6087 18.2. Accept-Credentials 6089 The Accept-Credentials header is a request-header used to indicate to 6090 any trusted intermediary how to handle further secured connections to 6091 proxies or servers. See Section 19 for the usage of this header. It 6092 MUST NOT be included in server to client requests. 6094 In a request the header MUST contain the method (User, Proxy, or Any) 6095 for approving credentials selected by the requester. The method MUST 6096 NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY 6097 change it to "user" to take the role of user approving each further 6098 hop. If the method is "User" the header contains zero or more of 6099 credentials that the client accepts. The header may contain zero 6100 credentials in the first RTSP request to a RTSP server when using the 6101 "User" method. This is because the client has not yet received any 6102 credentials to accept. Each credential MUST consist of one URI 6103 identifying the proxy or server, the hash algorithm identifier, and 6104 the hash over that agent's ASN.1 distinguished encoding rules (DER) 6105 encoded certificate [RFC5280] in BASE64, according to Section 4 of 6106 [RFC4648] and where the padding bits are set to zero. All RTSP 6107 clients and proxies MUST implement the SHA-256[FIPS-pub-180-2] 6108 algorithm for computation of the hash of the DER encoded certificate. 6109 The SHA-256 algorithm is identified by the token "sha-256". 6111 The intention with allowing for other hash algorithms is to enable 6112 the future retirement of algorithms that are not implemented 6113 somewhere else than here. Thus the definition of future algorithms 6114 for this purpose is intended to be extremely limited. A feature tag 6115 can be used to ensure that support for the replacement algorithm 6116 exists. 6118 Example: 6120 Accept-Credentials:User 6121 "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, 6122 "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= 6124 18.3. Accept-Encoding 6126 The Accept-Encoding request-header field is similar to Accept, but 6127 restricts the content-codings (see Section 18.15),i.e., 6128 transformation codings of the message body, such as gzip compression, 6129 that are acceptable in the response. 6131 A server tests whether a content-coding is acceptable, according to 6132 an Accept-Encoding field, using these rules: 6134 1. If the content-coding is one of the content-codings listed in the 6135 Accept-Encoding field, then it is acceptable, unless it is 6136 accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of 6137 0 means "not acceptable.") 6139 2. The special "*" symbol in an Accept-Encoding field matches any 6140 available content-coding not explicitly listed in the header 6141 field. 6143 3. If multiple content-codings are acceptable, then the acceptable 6144 content-coding with the highest non-zero qvalue is preferred. 6146 4. The "identity" content-coding is always acceptable, i.e., no 6147 transformation at all, unless specifically refused because the 6148 Accept-Encoding field includes "identity;q=0", or because the 6149 field includes "*;q=0" and does not explicitly include the 6150 "identity" content-coding. If the Accept-Encoding field-value is 6151 empty, then only the "identity" encoding is acceptable. 6153 If an Accept-Encoding field is present in a request, and if the 6154 server cannot send a response which is acceptable according to the 6155 Accept-Encoding header, then the server SHOULD send an error response 6156 with the 406 (Not Acceptable) status code. 6158 If no Accept-Encoding field is present in a request, the server MAY 6159 assume that the client will accept any content coding. In this case, 6160 if "identity" is one of the available content-codings, then the 6161 server SHOULD use the "identity" content-coding, unless it has 6162 additional information that a different content-coding is meaningful 6163 to the client. 6165 18.4. Accept-Language 6167 The Accept-Language request-header field is similar to Accept, but 6168 restricts the set of natural languages that are preferred as a 6169 response to the request. Note that the language specified applies to 6170 the presentation description and any reason phrases, but not the 6171 media content. 6173 A language tag identifies a natural language spoken, written, or 6174 otherwise conveyed by human beings for communication of information 6175 to other human beings. Computer languages are explicitly excluded. 6176 The syntax and registry of RTSP 2.0 language tags is the same as that 6177 defined by [RFC5646]. 6179 Each language-range MAY be given an associated quality value which 6180 represents an estimate of the user's preference for the languages 6181 specified by that range. The quality value defaults to "q=1". For 6182 example: 6184 Accept-Language: da, en-gb;q=0.8, en;q=0.7 6186 would mean: "I prefer Danish, but will accept British English and 6187 other types of English." A language-range matches a language-tag if 6188 it exactly equals the full tag, or if it exactly equals a prefix of 6189 the tag, i.e., the primary-tag in the ABNF, such that the character 6190 following primary-tag is "-". The special range "*", if present in 6191 the Accept-Language field, matches every tag not matched by any other 6192 range present in the Accept-Language field. 6194 Note: This use of a prefix matching rule does not imply that 6195 language tags are assigned to languages in such a way that it is 6196 always true that if a user understands a language with a certain 6197 tag, then this user will also understand all languages with tags 6198 for which this tag is a prefix. The prefix rule simply allows the 6199 use of prefix tags if this is the case. 6201 In the process of selecting a language, each language-tag is assigned 6202 a qualification factor, i.e., if a language being supported by the 6203 client is actually supported by the server and what "preference" 6204 level the language achieves. The quality value (q-value) of the 6205 longest language-range in the field that matches the language-tag is 6206 assigned as the qualification factor for a particular language-tag. 6207 If no language-range in the field matches the tag, the language 6208 qualification factor assigned is 0. If no Accept-Language header is 6209 present in the request, the server SHOULD assume that all languages 6210 are equally acceptable. If an Accept-Language header is present, 6211 then all languages which are assigned a qualification factor greater 6212 than 0 are acceptable. 6214 18.5. Accept-Ranges 6216 The Accept-Ranges general-header field allows indication of the 6217 format supported in the Range header. The client MUST include the 6218 header in SETUP requests to indicate which formats are acceptable 6219 when received in PLAY and PAUSE responses, and REDIRECT requests. 6220 The server MUST include the header in SETUP and 456 error responses 6221 to indicate the formats supported for the resource indicated by the 6222 request URI. The header MAY be included in GET_PARAMETER request and 6223 response pairs. The GET_PARAMETER request MUST contain a Session 6224 header to identify the session context the request is related to. 6225 The requester and responder will indicate their capabilities 6226 regarding Range formats respectively. 6228 Accept-Ranges: npt, smpte, clock 6230 The syntax is defined in Section 20.2.3. 6232 18.6. Allow 6234 The Allow message-body header field lists the methods supported by 6235 the resource identified by the Request-URI. The purpose of this 6236 field is to inform the recipient of the complete set of valid methods 6237 associated with the resource. An Allow header field MUST be present 6238 in a 405 (Method Not Allowed) response. The Allow header MUST also 6239 be present in all OPTIONS responses where the content of the header 6240 will not include exactly the same methods as listed in the Public 6241 header. 6243 The Allow message-body header MUST also be included in SETUP and 6244 DESCRIBE responses, if the methods allowed for the resource are 6245 different from the complete set of methods defined in this memo. 6247 Example of use: 6249 Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE 6251 18.7. Authentication-Info 6253 The Authentication-Info response-header is used by the server to 6254 communicate some information regarding the successful authentication 6255 in the response message. This usage of this header is specified in 6256 [RFC2617] with some RTSP clarification in Section 19.1. This header 6257 MUST only be used in response messages related to client to server 6258 requests. 6260 18.8. Authorization 6262 An RTSP client that wishes to authenticate itself with a server using 6263 authentication mechanism from HTTP [RFC2617] , usually, but not 6264 necessarily, after receiving a 401 response, does so by including an 6265 Authorization request-header field with the request. The 6266 Authorization field value consists of credentials containing the 6267 authentication information of the user agent for the realm of the 6268 resource being requested. This header MUST only be used in client to 6269 server requests. 6271 If a request is authenticated and a realm specified, the same 6272 credentials SHOULD be valid for all other requests within this realm 6273 (assuming that the authentication scheme itself does not require 6274 otherwise, such as credentials that vary according to a challenge 6275 value or using synchronized clocks). Each client to server request 6276 MUST be individually authorized by including the Authorization header 6277 with the information. 6279 When a shared cache (see Section 16) receives a request containing an 6280 Authorization field, it MUST NOT return the corresponding response as 6281 a reply to any other request, unless one of the following specific 6282 exceptions holds: 6284 1. If the response includes the "max-age" cache-control directive, 6285 the cache MAY use that response in replying to a subsequent 6286 request. But (if the specified maximum age has passed) a proxy 6287 cache MUST first revalidate it with the origin server, using the 6288 request-headers from the new request to allow the origin server 6289 to authenticate the new request. (This is the defined behavior 6290 for max-age.) If the response includes "max-age=0", the proxy 6291 MUST always revalidate it before re-using it. 6293 2. If the response includes the "must-revalidate" cache-control 6294 directive, the cache MAY use that response in replying to a 6295 subsequent request. But if the response is stale, all caches 6296 MUST first revalidate it with the origin server, using the 6297 request-headers from the new request to allow the origin server 6298 to authenticate the new request. 6300 3. If the response includes the "public" cache-control directive, it 6301 MAY be returned in reply to any subsequent request. 6303 18.9. Bandwidth 6305 The Bandwidth request-header field describes the estimated bandwidth 6306 available to the client, expressed as a positive integer and measured 6307 in kilobits per second. The bandwidth available to the client may 6308 change during an RTSP session, e.g., due to mobility, congestion, 6309 etc. 6311 Clients may not be able to accurately determine the available 6312 bandwidth, for example because the first hop is not a bottleneck. 6313 For example most local area networks (LAN) will not be a bottleneck 6314 if the server is not in the same LAN. Thus link speeds of WLAN or 6315 Ethernet networks are normally not a basis for estimating the 6316 available bandwidth. Cellular devices or other devices directly 6317 connected to a modem or connection enabling device may more 6318 accurately estimate the bottleneck bandwidth and what is a reasonable 6319 share of it for RTSP controlled media. The client will also need to 6320 take into account other traffic sharing the bottleneck. For example 6321 by only assigning a certain fraction to RTSP and its media streams. 6322 It is RECOMMENDED that only clients that have accurate and explicit 6323 information about bandwidth bottlenecks uses this header. 6325 This header is not a substitute for proper congestion control. It is 6326 only a method providing an initial estimate and coarsely determines 6327 if the selected content can be delivered at all. 6329 Example: 6331 Bandwidth: 62360 6333 18.10. Blocksize 6335 The Blocksize request-header field is sent from the client to the 6336 media server asking the server for a particular media packet size. 6337 This packet size does not include lower-layer headers such as IP, 6338 UDP, or RTP. The server is free to use a blocksize which is lower 6339 than the one requested. The server MAY truncate this packet size to 6340 the closest multiple of the minimum, media-specific block size, or 6341 override it with the media-specific size if necessary. The block 6342 size MUST be a positive decimal number, measured in octets. The 6343 server only returns an error (4xx) if the value is syntactically 6344 invalid. 6346 18.11. Cache-Control 6348 The Cache-Control general-header field is used to specify directives 6349 that MUST be obeyed by all caching mechanisms along the request/ 6350 response chain. 6352 Cache directives MUST be passed through by a proxy or gateway 6353 application, regardless of their significance to that application, 6354 since the directives may be applicable to all recipients along the 6355 request/response chain. It is not possible to specify a cache- 6356 directive for a specific cache. 6358 Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, 6359 SET_PARAMETER and SETUP request and its response. Note: Cache- 6360 Control does not govern just the caching of responses as for HTTP, 6361 instead it also applies to the media stream identified by the SETUP 6362 request. The RTSP requests are generally not cacheable, for further 6363 information see Section 16. Below are the descriptions of the cache 6364 directives that can be included in the Cache-Control header. 6366 no-cache: Indicates that the media stream or RTSP response MUST NOT 6367 be cached anywhere. This allows an origin server to prevent 6368 caching even by caches that have been configured to return 6369 stale responses to client requests. Note, there is no security 6370 function preventing the caching of content. 6372 public: Indicates that the media stream or RTSP response is 6373 cacheable by any cache. 6375 private: Indicates that the media stream or RTSP response is 6376 intended for a single user and MUST NOT be cached by a shared 6377 cache. A private (non-shared) cache may cache the media 6378 streams. 6380 no-transform: An intermediate cache (proxy) may find it useful to 6381 convert the media type of a certain stream. A proxy might, for 6382 example, convert between video formats to save cache space or 6383 to reduce the amount of traffic on a slow link. Serious 6384 operational problems may occur, however, when these 6385 transformations have been applied to streams intended for 6386 certain kinds of applications. For example, applications for 6387 medical imaging, scientific data analysis and those using end- 6388 to-end authentication all depend on receiving a stream that is 6389 bit-for-bit identical to the original media stream or RTSP 6390 response. Therefore, if a response includes the no-transform 6391 directive, an intermediate cache or proxy MUST NOT change the 6392 encoding of the stream or response. Unlike HTTP, RTSP does not 6393 provide for partial transformation at this point, e.g., 6394 allowing translation into a different language. 6396 only-if-cached: In some cases, such as times of extremely poor 6397 network connectivity, a client may want a cache to return only 6398 those media streams or RTSP responses that it currently has 6399 stored, and not to receive these from the origin server. To do 6400 this, the client may include the only-if-cached directive in a 6401 request. If it receives this directive, a cache SHOULD either 6402 respond using a cached media stream or response that is 6403 consistent with the other constraints of the request, or 6404 respond with a 504 (Gateway Timeout) status. However, if a 6405 group of caches is being operated as a unified system with good 6406 internal connectivity, such a request MAY be forwarded within 6407 that group of caches. 6409 max-stale: Indicates that the client is willing to accept a media 6410 stream or RTSP response that has exceeded its expiration time. 6411 If max-stale is assigned a value, then the client is willing to 6412 accept a response that has exceeded its expiration time by no 6413 more than the specified number of seconds. If no value is 6414 assigned to max-stale, then the client is willing to accept a 6415 stale response of any age. 6417 min-fresh: Indicates that the client is willing to accept a media 6418 stream or RTSP response whose freshness lifetime is no less 6419 than its current age plus the specified time in seconds. That 6420 is, the client wants a response that will still be fresh for at 6421 least the specified number of seconds. 6423 must-revalidate: When the must-revalidate directive is present in a 6424 SETUP response received by a cache, that cache MUST NOT use the 6425 cache entry after it becomes stale to respond to a subsequent 6426 request without first revalidating it with the origin server. 6427 That is, the cache is required to do an end-to-end revalidation 6428 every time, if, based solely on the origin server's Expires, 6429 the cached response is stale. 6431 proxy-revalidate: The proxy-revalidate directive has the same 6432 meaning as the must-revalidate directive, except that it does 6433 not apply to non-shared user agent caches. It can be used on a 6434 response to an authenticated request to permit the user's cache 6435 to store and later return the response without needing to 6436 revalidate it (since it has already been authenticated once by 6437 that user), while still requiring proxies that service many 6438 users to revalidate each time (in order to make sure that each 6439 user has been authenticated). Note that such authenticated 6440 responses also need the public cache control directive in order 6441 to allow them to be cached at all. 6443 max-age: When an intermediate cache is forced, by means of a max- 6444 age=0 directive, to revalidate its own cache entry, and the 6445 client has supplied its own validator in the request, the 6446 supplied validator might differ from the validator currently 6447 stored with the cache entry. In this case, the cache MAY use 6448 either validator in making its own request without affecting 6449 semantic transparency. 6451 However, the choice of validator might affect performance. The 6452 best approach is for the intermediate cache to use its own 6453 validator when making its request. If the server replies with 6454 304 (Not Modified), then the cache can return its now validated 6455 copy to the client with a 200 (OK) response. If the server 6456 replies with a new message body and cache validator, however, 6457 the intermediate cache can compare the returned validator with 6458 the one provided in the client's request, using the strong 6459 comparison function. If the client's validator is equal to the 6460 origin server's, then the intermediate cache simply returns 304 6461 (Not Modified). Otherwise, it returns the new message body 6462 with a 200 (OK) response. 6464 18.12. Connection 6466 The Connection general-header field allows the sender to specify 6467 options that are desired for that particular connection. It MUST NOT 6468 be communicated by proxies over further connections. 6470 RTSP 2.0 proxies MUST parse the Connection header field before a 6471 message is forwarded and, for each connection-token in this field, 6472 remove any header field(s) from the message with the same name as the 6473 connection-token. Connection options are signaled by the presence of 6474 a connection-token in the Connection header field, not by any 6475 corresponding additional header field(s), since the additional header 6476 field may not be sent if there are no parameters associated with that 6477 connection option. 6479 Message headers listed in the Connection header MUST NOT include end- 6480 to-end headers, such as Cache-Control. 6482 RTSP 2.0 defines the "close" connection option for the sender to 6483 signal that the connection will be closed after completion of the 6484 response. For example, Connection: close in either the request or 6485 the response-header fields indicates that the connection SHOULD NOT 6486 be considered `persistent' (Section 10.2) after the current request/ 6487 response is complete. 6489 The use of the connection option "close" in RTSP messages SHOULD be 6490 limited to error messages when the server is unable to recover and 6491 therefore sees it necessary to close the connection. The reason is 6492 that the client has the choice of continuing using a connection 6493 indefinitely, as long as it sends valid messages. 6495 18.13. Connection-Credentials 6497 The Connection-Credentials response-header is used to carry the chain 6498 of credentials for any next hop that needs to be approved by the 6499 requester. It MUST only be used in server to client responses. 6501 The Connection-Credentials header in an RTSP response MUST, if 6502 included, contain the credential information (in form of a list of 6503 certificates providing the chain of certification) of the next hop 6504 that an intermediary needs to securely connect to. The header MUST 6505 include the URI of the next hop (proxy or server) and a BASE64 6506 (according to Section 4 of [RFC4648] and where the padding bits are 6507 set to zero) encoded binary structure containing a sequence of DER 6508 encoded X.509v3 certificates [RFC5280]. 6510 The binary structure starts with the number of certificates 6511 (NR_CERTS) included as a 16 bit unsigned integer. This is followed 6512 by NR_CERTS number of 16 bit unsigned integers providing the size in 6513 octets of each DER encoded certificate. This is followed by NR_CERTS 6514 number of DER encoded X.509v3 certificates in a sequence (chain). 6515 This format is exemplified in Figure 2. The proxy or server's 6516 certificate must come first in the structure. Each following 6517 certificate must directly certify the one preceding it. Because 6518 certificate validation requires that root keys be distributed 6519 independently, the self-signed certificate which specifies the root 6520 certificate authority may optionally be omitted from the chain, under 6521 the assumption that the remote end must already possess it in order 6522 to validate it in any case. 6524 Example: 6526 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 6528 Where MIIDNTCC... is a Base64 encoding of the following structure: 6530 0 1 2 3 6531 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 6532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6533 | Number of certificates | Size of certificate #1 | 6534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6535 | Size of certificate #2 | Size of certificate #3 | 6536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6537 : DER Encoding of Certificate #1 : 6538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6539 : DER Encoding of Certificate #2 : 6540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6541 : DER Encoding of Certificate #3 : 6542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6544 Figure 2: Connection-Credentials header's Certificate Format Example 6546 18.14. Content-Base 6548 The Content-Base message-body header field may be used to specify the 6549 base URI for resolving relative URIs within the message body. 6551 Content-Base: rtsp://media.example.com/movie/twister/ 6553 If no Content-Base field is present, the base URI of an message body 6554 is defined either by its Content-Location (if that Content-Location 6555 URI is an absolute URI) or the URI used to initiate the request, in 6556 that order of precedence. Note, however, that the base URI of the 6557 contents within the message-body may be redefined within that 6558 message-body. 6560 18.15. Content-Encoding 6562 The Content-Encoding message-body header field is used as a modifier 6563 to the media-type. When present, its value indicates what additional 6564 content codings have been applied to the message body, and thus what 6565 decoding mechanisms must be applied in order to obtain the media-type 6566 referenced by the Content-Type header field. Content-Encoding is 6567 primarily used to allow a document to be compressed without losing 6568 the identity of its underlying media type. 6570 The content-coding is a characteristic of the message body identified 6571 by the Request-URI. Typically, the message body is stored with this 6572 encoding and is only decoded before rendering or analogous usage. 6573 However, an RTSP proxy MAY modify the content-coding if the new 6574 coding is known to be acceptable to the recipient, unless the "no- 6575 transform" cache-control directive is present in the message. 6577 If the content-coding of a message body is not "identity", then the 6578 message MUST include a Content-Encoding Message-body header that 6579 lists the non-identity content-coding(s) used. 6581 If the content-coding of a message body in a request message is not 6582 acceptable to the origin server, the server SHOULD respond with a 6583 status code of 415 (Unsupported Media Type). 6585 If multiple encodings have been applied to a message body, the 6586 content codings MUST be listed in the order in which they were 6587 applied, first to last from left to right. Additional information 6588 about the encoding parameters MAY be provided by other header fields 6589 not defined by this specification. 6591 18.16. Content-Language 6593 The Content-Language message-body header field describes the natural 6594 language(s) of the intended audience for the enclosed message body. 6595 Note that this might not be equivalent to all the languages used 6596 within the message body. 6598 Language tags are mentioned in Section 18.4. The primary purpose of 6599 Content-Language is to allow a user to identify and differentiate 6600 entities according to the user's own preferred language. Thus, if 6601 the body content is intended only for a Danish-literate audience, the 6602 appropriate field is 6604 Content-Language: da 6606 If no Content-Language is specified, the default is that the content 6607 is intended for all language audiences. This might mean that the 6608 sender does not consider it to be specific to any natural language, 6609 or that the sender does not know for which language it is intended. 6611 Multiple languages MAY be listed for content that is intended for 6612 multiple audiences. For example, a rendition of the "Treaty of 6613 Waitangi," presented simultaneously in the original Maori and English 6614 versions, would call for 6616 Content-Language: mi, en 6618 However, just because multiple languages are present within a message 6619 body does not mean that it is intended for multiple linguistic 6620 audiences. An example would be a beginner's language primer, such as 6621 "A First Lesson in Latin," which is clearly intended to be used by an 6622 English-literate audience. In this case, the Content-Language would 6623 properly only include "en". 6625 Content-Language MAY be applied to any media type -- it is not 6626 limited to textual documents. 6628 18.17. Content-Length 6630 The Content-Length message-body header field contains the length of 6631 the message body of the RTSP message (i.e., after the double CRLF 6632 following the last header). Unlike HTTP, it MUST be included in all 6633 messages that carry a message body beyond the header portion of the 6634 RTSP message. If it is missing, a default value of zero is assumed. 6635 Any Content-Length greater than or equal to zero is a valid value. 6637 18.18. Content-Location 6639 The Content-Location message-body header field MAY be used to supply 6640 the resource location for the message body enclosed in the message 6641 when that body is accessible from a location separate from the 6642 requested resource's URI. A server SHOULD provide a Content-Location 6643 for the variant corresponding to the response message body; 6644 especially in the case where a resource has multiple variants 6645 associated with it, and those entities actually have separate 6646 locations by which they might be individually accessed, the server 6647 SHOULD provide a Content-Location for the particular variant which is 6648 returned. 6650 As example, if an RTSP client performs a DESCRIBE request on a given 6651 resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", 6652 then the server may use additional information, such as the User- 6653 Agent header, to determine the capabilities of the agent. The server 6654 will then return a media description tailored to that class of RTSP 6655 agents. To indicate which specific description the agent receives 6656 the resource identifier ("rtsp://a.example.com/movie/ 6657 Plan9FromOuterSpace/FullHD.sdp") is provided in Content-Location, 6658 while the description is still a valid response for the generic 6659 resource identifier. Thus enabling both debugging and cache 6660 operation as discussed below. 6662 The Content-Location value is not a replacement for the original 6663 requested URI; it is only a statement of the location of the resource 6664 corresponding to this particular variant at the time of the request. 6665 Future requests MAY specify the Content-Location URI as the request 6666 URI if the desire is to identify the source of that particular 6667 variant. This is useful if the RTSP agent desires to verify if the 6668 resource variant is current through a conditional request. 6670 A cache cannot assume that a message body with a Content-Location 6671 different from the URI used to retrieve it can be used to respond to 6672 later requests on that Content-Location URI. However, the Content- 6673 Location can be used to differentiate between multiple variants 6674 retrieved from a single requested resource. 6676 If the Content-Location is a relative URI, the relative URI is 6677 interpreted relative to the Request-URI. 6679 Note, that Content-Location can be used in some cases to derive the 6680 base-URI for relative URI(s) present in session description formats. 6681 This needs to be taken into account when Content-Location is used. 6682 The easiest way to avoid needing to consider that issue is to include 6683 the Content-Base whenever the Content-Location is included. 6685 Note also, when using Media Tags in conjunction with Content-Location 6686 it is important that the different versions have different MTags, 6687 even if provided under different Content-Location URIs. This as they 6688 have still been provided under the same request URI. 6690 Note also, as in most cases the URI used in the DESCRIBE and the 6691 SETUP requests are different, the URI provided in a DESCRIBE Content- 6692 Location response can't directly be used in a SETUP request. Instead 6693 the extra step of resolving URIs combined with the media descriptions 6694 indication, like with SDP's a=control attribute. 6696 18.19. Content-Type 6698 The Content-Type message-body header indicates the media type of the 6699 message body sent to the recipient. Note that the content types 6700 suitable for RTSP are likely to be restricted in practice to 6701 presentation descriptions and parameter-value types. 6703 18.20. CSeq 6705 The CSeq general-header field specifies the sequence number (integer) 6706 for an RTSP request-response pair. This field MUST be present in all 6707 requests and responses. RTSP agents maintain a sequence number 6708 series for each responder to which they have an open message 6709 transport channel. For each new RTSP request an agent originates on 6710 a particular RTSP message transport the CSeq value MUST be 6711 incremented by one. The initial sequence number can be any number, 6712 however, it is RECOMMENDED to start at 0. Each sequence number 6713 series is unique between each requester and responder, i.e., the 6714 client has one series for its requests to a server and the server has 6715 another when sending requests to the client. Each requester and 6716 responder is identified by its socket address (IP address and port 6717 number), i.e., per direction of a TCP connection. Any retransmitted 6718 request MUST contain the same sequence number as the original, i.e., 6719 the sequence number is not incremented for retransmissions of the 6720 same request. The RTSP agent receiving requests MUST process the 6721 requests arriving on a particular transport in the order of the 6722 sequence numbers. Responses are sent in the order that they are 6723 generated. The RTSP response MUST have the same sequence number as 6724 was present in the corresponding request. A RTSP Agent receiving a 6725 response MAY receive the responses out of order compared to the order 6726 of the requests it sent. Thus, the agent MUST use the sequence 6727 number in the response to pair it with the corresponding request. 6729 The main purpose of the sequence number is to map responses to 6730 requests. 6732 The requirement to use a sequence number increment of one for each 6733 new request is to support any future specification of RTSP message 6734 transport over a protocol that does not provide in order delivery 6735 or is unreliable. 6737 The above rules relating to the initial sequence number may appear 6738 unnecessarily loose. The reason is to cater for some common 6739 behavior of existing implementations: When using multiple reliable 6740 connections in sequence it may still be easiest to use a single 6741 sequence number series for a client connecting with a particular 6742 server. Thus, the initial sequence number may be arbitrary 6743 depending on the number of previous requests. For any unreliable 6744 transport a stricter definition or other solution will be required 6745 to enable detection of any loss of the first request. 6747 When using multiple sequential transport connections, there is no 6748 protocol mechanism to ensure in order processing as the sequence 6749 number is scoped on the individual transport connection and its 6750 five tuple. Thus, there are potential issues with opening a new 6751 transport connection to the same host for which there already 6752 exists a transport connection with outstanding requests and 6753 previously despatched requests related to the same RTSP session. 6755 RTSP Proxies also need to follow the above rules. This implies that 6756 proxies that aggregate requests from multiple clients onto a single 6757 transport towards a server or a next hop proxy need to renumber these 6758 requests to form a unified sequence on that transport, fulfilling the 6759 above rules. A proxy capable of fulfilling some agent's request 6760 without emitting its own request (e.g., a caching proxy that fulfils 6761 a request from its cache), also causes a need to renumber as the 6762 number of received requests with a particular target, may not be the 6763 same as the number of emitted requests towards that target agent. A 6764 proxy that needs to renumber, needs to perform the corresponding 6765 renumbering back to the original sequence number for any received 6766 response before forwarding it back to the originator of the request. 6768 A client connected to a proxy, and using that transport to send 6769 requests to multiple servers creates a situation where it is quite 6770 likely to receive the responses out of order. This is because the 6771 proxy will establish separate transports from the proxy to the 6772 servers on which to forward the client's requests. When the 6773 responses arrive from the different servers they will be forwarded 6774 to the client in the order they arrive at the proxy and can be 6775 processed, not the order of the client's original sequence 6776 numbers. This is intentional to avoid some session's requests 6777 being blocked by another server's slow processing of requests. 6779 18.21. Date 6781 The Date general-header field represents the date and time at which 6782 the message was originated. The inclusion of the Date header in RTSP 6783 message follows these rules: 6785 o An RTSP message, sent either by the client or the server, 6786 containing a body MUST include a Date header, if the sending host 6787 has a clock; 6789 o Clients and servers are RECOMMENDED to include a Date header in 6790 all other RTSP messages, if the sending host has a clock; 6792 o If the server does not have a clock that can provide a reasonable 6793 approximation of the current time, its responses MUST NOT include 6794 a Date header field. In this case, this rule MUST be followed: 6795 Some origin server implementations might not have a clock 6796 available. An origin server without a clock MUST NOT assign 6797 Expires or Last-Modified values to a response, unless these values 6798 were associated with the resource by a system or user with a 6799 reliable clock. It MAY assign an Expires value that is known, at 6800 or before server configuration time, to be in the past (this 6801 allows "pre-expiration" of responses without storing separate 6802 Expires values for each resource). 6804 A received message that does not have a Date header field MUST be 6805 assigned one by the recipient if the message will be cached by that 6806 recipient. An RTSP implementation without a clock MUST NOT cache 6807 responses without revalidating them on every use. An RTSP cache, 6808 especially a shared cache, SHOULD use a mechanism, such as Network 6809 Time Protocol (NTP) [RFC5905], to synchronize its clock with a 6810 reliable external standard. 6812 The RTSP-date, a full date as specified by Section 3.3 of [RFC5322], 6813 sent in a Date header SHOULD NOT represent a date and time subsequent 6814 to the generation of the message. It SHOULD represent the best 6815 available approximation of the date and time of message generation, 6816 unless the implementation has no means of generating a reasonably 6817 accurate date and time. In theory, the date ought to represent the 6818 moment just before the message body is generated. In practice, the 6819 date can be generated at any time during the message origination 6820 without affecting its semantic value. 6822 Note: The RTSP 2.0 date format is defined to be the RFC 5322 full 6823 date format. This format is more flexible than the RFC 1123 date 6824 format used by RTSP 1.0. Thus implementations should use single 6825 spaces as recommended by RFC 5322 as separators and support 6826 receiving the obsolete format. 6828 Further Note that the syntax allow for a comment to be added at 6829 the end of the date. 6831 [RFC Editor please remove this note in brackets: Prior to version 6832 37 of the draft, rfc2326bis envisaged sticking with the RFC 1123 6833 format.] 6835 18.22. Expires 6837 The Expires message-body header field gives a date and time after 6838 which the description or media-stream should be considered stale. 6839 The interpretation depends on the method: 6841 DESCRIBE response: The Expires header indicates a date and time 6842 after which the presentation description (body) SHOULD be 6843 considered stale. 6845 SETUP response: The Expires header indicate a date and time after 6846 which the media stream SHOULD be considered stale. 6848 A stale cache entry may not normally be returned by a cache (either a 6849 proxy cache or an user agent cache) unless it is first validated with 6850 the origin server (or with an intermediate cache that has a fresh 6851 copy of the message body). See Section 16 for further discussion of 6852 the expiration model. 6854 The presence of an Expires field does not imply that the original 6855 resource will change or cease to exist at, before, or after that 6856 time. 6858 The format is an absolute date and time as defined by RTSP-date. An 6859 example of its use is 6861 Expires: Wed, 23 Jan 2013 15:36:52 +0000 6863 RTSP/2.0 clients and caches MUST treat other invalid date formats, 6864 especially including the value "0", as having occurred in the past 6865 (i.e., already expired). 6867 To mark a response as "already expired," an origin server should use 6868 an Expires date that is equal to the Date header value. To mark a 6869 response as "never expires," an origin server SHOULD use an Expires 6870 date approximately one year from the time the response is sent. RTSP 6871 /2.0 servers SHOULD NOT send Expires dates more than one year in the 6872 future. 6874 18.23. From 6876 The From request-header field, if given, SHOULD contain an Internet 6877 e-mail address for the human user who controls the requesting user 6878 agent. The address SHOULD be machine-usable, as defined by "mailbox" 6879 in [RFC1123]. 6881 This header field MAY be used for logging purposes and as a means for 6882 identifying the source of invalid or unwanted requests. It SHOULD 6883 NOT be used as an insecure form of access protection. The 6884 interpretation of this field is that the request is being performed 6885 on behalf of the person given, who accepts responsibility for the 6886 method performed. In particular, robot agents SHOULD include this 6887 header so that the person responsible for running the robot can be 6888 contacted if problems occur on the receiving end. 6890 The Internet e-mail address in this field MAY be separate from the 6891 Internet host which issued the request. For example, when a request 6892 is passed through a proxy the original issuer's address SHOULD be 6893 used. 6895 The client SHOULD NOT send the From header field without the user's 6896 approval, as it might conflict with the user's privacy interests or 6897 their site's security policy. It is strongly recommended that the 6898 user be able to disable, enable, and modify the value of this field 6899 at any time prior to a request. 6901 18.24. If-Match 6903 The If-Match request-header field is especially useful for ensuring 6904 the integrity of the presentation description, independent of how the 6905 presentation description was received. The presentation description 6906 can be fetched via means external to RTSP (such as HTTP) or via the 6907 DESCRIBE message. In the case of retrieving the presentation 6908 description via RTSP, the server implementation is guaranteeing the 6909 integrity of the description between the time of the DESCRIBE message 6910 and the SETUP message. By including the MTag given in or with the 6911 session description in an If-Match header part of the SETUP request, 6912 the client ensures that resources set up are matching the 6913 description. A SETUP request with the If-Match header for which the 6914 MTag validation check fails, MUST generate a response using 412 6915 (Precondition Failed). 6917 This validation check is also very useful if a session has been 6918 redirected from one server to another. 6920 18.25. If-Modified-Since 6922 The If-Modified-Since request-header field is used with the DESCRIBE 6923 and SETUP methods to make them conditional. If the requested variant 6924 has not been modified since the time specified in this field, a 6925 description will not be returned from the server (DESCRIBE) or a 6926 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 6927 response MUST be returned without any message-body. 6929 An example of the field is: 6931 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 6933 18.26. If-None-Match 6935 This request-header can be used with one or several message body tags 6936 to make DESCRIBE requests conditional. A client that has one or more 6937 message bodies previously obtained from the resource, can verify that 6938 none of those entities is current by including a list of their 6939 associated message body tags in the If-None-Match header field. The 6940 purpose of this feature is to allow efficient updates of cached 6941 information with a minimum amount of transaction overhead. As a 6942 special case, the value "*" matches any current entity of the 6943 resource. 6945 If any of the message body tags match the message body tag of the 6946 message body that would have been returned in the response to a 6947 similar DESCRIBE request (without the If-None-Match header) on that 6948 resource, or if "*" is given and any current entity exists for that 6949 resource, then the server MUST NOT perform the requested method, 6950 unless required to do so because the resource's modification date 6951 fails to match that supplied in an If-Modified-Since header field in 6952 the request. Instead, if the request method was DESCRIBE, the server 6953 SHOULD respond with a 304 (Not Modified) response, including the 6954 cache-related header fields (particularly MTag) of one of the message 6955 bodies that matched. For all other request methods, the server MUST 6956 respond with a status of 412 (Precondition Failed). 6958 See Section 16.1.3 for rules on how to determine if two message body 6959 tags match. 6961 If none of the message body tags match, then the server MAY perform 6962 the requested method as if the If-None-Match header field did not 6963 exist, but MUST also ignore any If-Modified-Since header field(s) in 6964 the request. That is, if no message body tags match, then the server 6965 MUST NOT return a 304 (Not Modified) response. 6967 If the request would, without the If-None-Match header field, result 6968 in anything other than a 2xx or 304 status, then the If-None-Match 6969 header MUST be ignored. (See Section 16.1.4 for a discussion of 6970 server behavior when both If-Modified-Since and If-None-Match appear 6971 in the same request.) 6973 The result of a request having both an If-None-Match header field and 6974 an If-Match header field is unspecified and MUST be considered an 6975 illegal request. 6977 18.27. Last-Modified 6979 The Last-Modified message-body header field indicates the date and 6980 time at which the origin server believes the presentation description 6981 or media stream was last modified. For the method DESCRIBE, the 6982 header field indicates the last modification date and time of the 6983 description, for SETUP that of the media stream. 6985 An origin server MUST NOT send a Last-Modified date which is later 6986 than the server's time of message origination. In such cases, where 6987 the resource's last modification would indicate some time in the 6988 future, the server MUST replace that date with the message 6989 origination date. 6991 An origin server SHOULD obtain the Last-Modified value of the message 6992 body as close as possible to the time that it generates the Date 6993 value of its response. This allows a recipient to make an accurate 6994 assessment of the message body's modification time, especially if the 6995 message body changes near the time that the response is generated. 6997 RTSP servers SHOULD send Last-Modified whenever feasible. 6999 18.28. Location 7001 The Location response-header field is used to redirect the recipient 7002 to a location other than the Request-URI for completion of the 7003 request or identification of a new resource. For 3rr responses, the 7004 location SHOULD indicate the server's preferred URI for automatic 7005 redirection to the resource. The field value consists of a single 7006 absolute URI. 7008 Note: The Content-Location header field (Section 18.18) differs from 7009 Location in that the Content-Location identifies the original 7010 location of the message body enclosed in the request. It is 7011 therefore possible for a response to contain header fields for both 7012 Location and Content-Location. Also, see Section 16.2 for cache 7013 requirements of some methods. 7015 18.29. Media-Properties 7017 This general-header is used in SETUP response or PLAY_NOTIFY requests 7018 to indicate the media's properties that currently are applicable to 7019 the RTSP session. PLAY_NOTIFY MAY be used to modify these properties 7020 at any point. However, the client SHOULD have received the update 7021 prior to any action related to the new media properties taking 7022 effect. For aggregated sessions, the Media-Properties header will be 7023 returned in each SETUP response. The header received in the latest 7024 response is the one that applies on the whole session from this point 7025 until any future update. The header MAY be included without value in 7026 GET_PARAMETER requests to the server with a Session header included 7027 to query the current Media-Properties for the session. The responder 7028 MUST include the current session's media properties. 7030 The media properties expressed by this header is the one applicable 7031 to all media in the RTSP session. For aggregated sessions, the 7032 header expressed the combined media-properties. As a result, 7033 aggregation of media MAY result in a change of the media properties, 7034 and thus the content of the Media-Properties header contained in 7035 subsequent SETUP responses. 7037 The header contains a list of property values that are applicable to 7038 the currently setup media or aggregate of media as indicated by the 7039 RTSP URI in the request. No ordering is enforced within the header. 7040 Property values should be grouped into a single group that handles a 7041 particular orthogonal property. Values or groups that express 7042 multiple properties SHOULD NOT be used. The list of properties that 7043 can be expressed MAY be extended at any time. Unknown property 7044 values MUST be ignored. 7046 This specification defines the following 4 groups and their property 7047 values: 7049 Random Access: 7051 Random-Access: Indicates that random access is possible. May 7052 optionally include a floating point value in seconds indicating 7053 the longest duration between any two random access points in 7054 the media. 7056 Beginning-Only: Seeking is limited to the beginning only. 7058 No-Seeking: No seeking is possible. 7060 Content Modifications: 7062 Immutable: The content will not be changed during the life-time 7063 of the RTSP session. 7065 Dynamic: The content may be changed based on external methods or 7066 triggers 7068 Time-Progressing: The media accessible progresses as wallclock 7069 time progresses. 7071 Retention: 7073 Unlimited: Content will be retained for the duration of the life- 7074 time of the RTSP session. 7076 Time-Limited: Content will be retained at least until the 7077 specified wallclock time. The time must be provided in the 7078 absolute time format specified in Section 4.4.3. 7080 Time-Duration: Each individual media unit is retained for at 7081 least the specified time duration. This definition allows for 7082 retaining data with a time based sliding window. The time 7083 duration is expressed as floating point number in seconds. 0.0 7084 is a valid value as this indicates that no data is retained in 7085 a time-progressing session. 7087 Supported Scale: 7089 Scales: A quoted comma separated list of one or more decimal 7090 values or ranges of scale values supported by the content in 7091 arbitrary order. A range has a start and stop value separated 7092 by a colon. A range indicates that the content supports fine 7093 grained selection of scale values. Fine grained allows for 7094 steps at least as small as one tenth of a scale value. A 7095 content is considered to support fine grained selection when 7096 the server in response to a given scale value can produce 7097 content with an actual scale that is less than 1 tenth of scale 7098 unit, i.e., 0.1, from the requested value. Negative values are 7099 supported. The value 0 has no meaning and MUST NOT be used. 7101 Examples of this header for on-demand content and a live stream 7102 without recording are: 7104 On-demand: 7105 Media-Properties: Random-Access=2.5, Unlimited, Immutable, 7106 Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" 7108 Live stream without recording/timeshifting: 7109 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 7111 18.30. Media-Range 7113 The Media-Range general-header is used to give the range of the media 7114 at the time of sending the RTSP message. This header MUST be 7115 included in SETUP response, and PLAY and PAUSE response for media 7116 that are Time-Progressing, and PLAY and PAUSE response after any 7117 change for media that are Dynamic, and in PLAY_NOTIFY request that 7118 are sent due to Media-Property-Update. Media-Range header without 7119 any range specifications MAY be included in GET_PARAMETER requests to 7120 the server to request the current range. The server MUST in this 7121 case include the current range at the time of sending the response. 7123 The header MUST include range specifications for all time formats 7124 supported for the media, as indicated in Accept-Ranges header 7125 (Section 18.5) when setting up the media. The server MAY include 7126 more than one range specification of any given time format to 7127 indicate media that has non-continuous range. The range 7128 specifications SHALL be ordered with the range with the lowest value 7129 or earliest start time first, followed by ranges with increasingly 7130 higher values or later start time. 7132 For media that has the Time-Progressing property, the Media-Range 7133 values will only be valid for the particular point in time when it 7134 was issued. As wallclock progresses so will also the media range. 7135 However, it shall be assumed that media time progresses in direct 7136 relationship to wallclock time (with the exception of clock skew) so 7137 that a reasonably accurate estimation of the media range can be 7138 calculated. 7140 18.31. MTag 7142 The MTag response-header MAY be included in DESCRIBE, GET_PARAMETER 7143 or SETUP responses. The message body tags (Section 4.6) returned in 7144 a DESCRIBE response, and the one in SETUP refers to the presentation, 7145 i.e., both the returned session description and the media stream. 7146 This allows for verification that one has the right session 7147 description to a media resource at the time of the SETUP request. 7149 However, it has the disadvantage that a change in any of the parts 7150 results in invalidation of all the parts. 7152 If the MTag is provided both inside the message body, e.g., within 7153 the "a=mtag" attribute in SDP, and in the response message, then both 7154 tags MUST be identical. It is RECOMMENDED that the MTag is primarily 7155 given in the RTSP response message, to ensure that caches can use the 7156 MTag without requiring content inspection. However, for session 7157 descriptions that are distributed outside of RTSP, for example using 7158 HTTP, etc. it will be necessary to include the message body tag in 7159 the session description as specified in Appendix D.1.9. 7161 SETUP and DESCRIBE requests can be made conditional upon the MTag 7162 using the headers If-Match (Section 18.24) and If-None-Match ( 7163 Section 18.26). 7165 18.32. Notify-Reason 7167 The Notify-Reason response-header is solely used in the PLAY_NOTIFY 7168 method. It indicates the reason why the server has sent the 7169 asynchronous PLAY_NOTIFY request (see Section 13.5). 7171 18.33. Pipelined-Requests 7173 The Pipelined-Requests general-header is used to indicate that a 7174 request is to be executed in the context created by a previous 7175 request(s). The primary usage of this header is to allow pipelining 7176 of SETUP requests so that any additional SETUP request after the 7177 first one does not need to wait for the session ID to be sent back to 7178 the requesting agent. The header contains a unique identifier that 7179 is scoped by the persistent connection used to send the requests. 7181 Upon receiving a request with the Pipelined-Requests the responding 7182 agent MUST look up if there exists a binding between this Pipelined- 7183 Requests identifier for the current persistent connection and an RTSP 7184 session ID. If that exists then the received request is processed 7185 the same way as if it contained the Session header with the found 7186 session ID. If there does not exist a mapping and no Session header 7187 is included in the request, the responding agent MUST create a 7188 binding upon the successful completion of a session creating request, 7189 i.e., SETUP. A binding MUST NOT be created, if the request failed to 7190 create an RTSP session. In case the request contains both a Session 7191 header and the Pipelined-Requests header the Pipelined-Requests MUST 7192 be ignored. 7194 Note: Based on the above definition at least the first request 7195 containing a new unique Pipelined-Requests will be required to be a 7196 SETUP request (unless the protocol is extended with new methods of 7197 creating a session). After that first one, additional SETUP requests 7198 or requests of any type using the RTSP session context may include 7199 the Pipelined-Requests header. 7201 When responding to any request that contained the Pipelined-Requests 7202 header the server MUST also include the Session header when a binding 7203 to a session context exists. An RTSP agent that knows the session 7204 identifier SHOULD NOT use the Pipelined-Requests header in any 7205 request and only use the Session header. This as the Session 7206 identifier is persistent across transport contexts, like TCP 7207 connections, which the Pipelined-Requests identifier is not. 7209 The RTSP agent sending the request with a Pipelined-Requests header 7210 has the responsibility for using a unique and previously unused 7211 identifier within the transport context. Currently only a TCP 7212 connection is defined as such transport context. A server MUST 7213 delete the Pipelined-Requests identifier and its binding to a session 7214 upon the termination of that session. Despite the previous mandate, 7215 RTSP agents are RECOMMENDED to not reuse identifiers to allow for 7216 better error handling and logging. 7218 RTSP Proxies may need to translate Pipelined-Requests identifier 7219 values from incoming requests to outgoing to allow for aggregation of 7220 requests onto a persistent connection. 7222 18.34. Proxy-Authenticate 7224 The Proxy-Authenticate response-header field MUST be included as part 7225 of a 407 (Proxy Authentication Required) response. The field value 7226 consists of a challenge that indicates the authentication scheme and 7227 parameters applicable to the proxy for this Request-URI. 7229 The HTTP access authentication process is described in [RFC2617]. 7230 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 7231 only to the current connection and SHOULD NOT be passed on to 7232 downstream agents. This header MUST only be used in response 7233 messages related to client to server requests. 7235 18.35. Proxy-Authentication-Info 7237 The Proxy-Authentication-Info response-header is used by the proxy to 7238 communicate some information regarding the successful authentication 7239 to the proxy in the message response. The content and usage of this 7240 header is described in the HTTP access authentication [RFC2617] that 7241 is also used by RTSP and clarified in Section 19.1. This header MUST 7242 only be used in response messages related to client to server 7243 requests. This header has hop by hop scope. 7245 18.36. Proxy-Authorization 7247 The Proxy-Authorization request-header field allows the client to 7248 identify itself (or its user) to a proxy which requires 7249 authentication. The Proxy-Authorization field value consists of 7250 credentials containing the authentication information of the user 7251 agent for the proxy and/or realm of the resource being requested. 7253 The HTTP access authentication process is described in [RFC2617]. 7254 Unlike Authorization, the Proxy-Authorization header field applies 7255 only to the next hop proxy. This header MUST only be used in client 7256 to server requests. 7258 18.37. Proxy-Require 7260 The Proxy-Require request-header field is used to indicate proxy- 7261 sensitive features that MUST be supported by the proxy. Any Proxy- 7262 Require header features that are not supported by the proxy MUST be 7263 negatively acknowledged by the proxy to the client using the 7264 Unsupported header. The proxy MUST use the 551 (Option Not 7265 Supported) status code in the response. Any feature-tag included in 7266 the Proxy-Require does not apply to the end-point (server or client). 7267 To ensure that a feature is supported by both proxies and servers the 7268 tag needs to be included in also a Require header. 7270 See Section 18.43 for more details on the mechanics of this message 7271 and a usage example. See discussion in the proxies section 7272 (Section 15.1) about when to consider that a feature requires proxy 7273 support. 7275 Example of use: 7277 Proxy-Require: play.basic 7279 18.38. Proxy-Supported 7281 The Proxy-Supported general-header field enumerates all the 7282 extensions supported by the proxy using feature-tags. The header 7283 carries the intersection of extensions supported by the forwarding 7284 proxies. The Proxy-Supported header MAY be included in any request 7285 by a proxy. It MUST be added by any proxy if the Supported header is 7286 present in a request. When present in a request, the receiver MUST 7287 in the response copy the received Proxy-Supported header. 7289 The Proxy-Supported header field contains a list of feature-tags 7290 applicable to proxies, as described in Section 4.5. The list is the 7291 intersection of all feature-tags understood by the proxies. To 7292 achieve an intersection, the proxy adding the Proxy-Supported header 7293 includes all proxy feature-tags it understands. Any proxy receiving 7294 a request with the header, MUST check the list and removes any 7295 feature-tag(s) it does not support. A Proxy-Supported header present 7296 in the response MUST NOT be modified by the proxies. These feature 7297 tags are the ones the proxy chain support in general, and is not 7298 specific to the request resource. 7300 Example: 7302 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 7303 Supported: foo, bar, blech 7304 User-Agent: PhonyClient/1.2 7306 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 7307 Supported: foo, bar, blech 7308 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 7309 Via: 2.0 pro.example.com 7311 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 7312 Supported: foo, bar, blech 7313 Proxy-Supported: proxy-foo, proxy-blech 7314 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7316 S->C: RTSP/2.0 200 OK 7317 Supported: foo, bar, baz 7318 Proxy-Supported: proxy-foo, proxy-blech 7319 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7320 Via: 2.0 pro.example.com, 2.0 prox2.example.com 7322 18.39. Public 7324 The Public response-header field lists the set of methods supported 7325 by the response sender. This header applies to the general 7326 capabilities of the sender and its only purpose is to indicate the 7327 sender's capabilities to the recipient. The methods listed may or 7328 may not be applicable to the Request-URI; the Allow header field 7329 (Section 18.6) MAY be used to indicate methods allowed for a 7330 particular URI. 7332 Example of use: 7334 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 7336 In the event that there are proxies between the sender and the 7337 recipient of a response, each intervening proxy MUST modify the 7338 Public header field to remove any methods that are not supported via 7339 that proxy. The resulting Public header field will contain an 7340 intersection of the sender's methods and the methods allowed through 7341 by the intervening proxies. 7343 In general, proxies should allow all methods to transparently pass 7344 through from the sending RTSP agent to the receiving RTSP agent, 7345 but there may be cases where this is not desirable for a given 7346 proxy. Modification of the Public response-header field by the 7347 intervening proxies ensures that the request sender gets an 7348 accurate response indicating the methods that can be used on the 7349 target agent via the proxy chain. 7351 18.40. Range 7353 The Range general-header specifies a time range in PLAY 7354 (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT 7355 (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and 7356 responses. It MAY be included in GET_PARAMETER requests from the 7357 client to the server with only a Range format and no value to request 7358 the current media position, whether the session is in Play or Ready 7359 state in the included format. The server SHALL, if supporting the 7360 range format, respond with the current playing point or pause point 7361 as the start of the range. If an explicit stop point was used in the 7362 previous PLAY request, then that value shall be included as stop 7363 point. Note that if the server is currently under any type of media 7364 playback manipulation affecting the interpretation of Range, like 7365 Scale, that is also required to be included in any GET_PARAMETER 7366 response to provide complete information. 7368 The range can be specified in a number of units. This specification 7369 defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock 7370 (Section 4.4.3) range units. While octet ranges (Byte Ranges) 7371 [H14.35.1] and other extended units MAY be used, their behavior is 7372 unspecified since they are not normally meaningful in RTSP. Servers 7373 supporting the Range header MUST understand the NPT range format and 7374 SHOULD understand the SMPTE range format. If the Range header is 7375 sent in a time format that is not understood, the recipient SHOULD 7376 return 456 (Header Field Not Valid for Resource) and include an 7377 Accept-Ranges header indicating the supported time formats for the 7378 given resource. 7380 Example: 7382 Range: clock=19960213T143205Z- 7384 The Range header contains a range of one single range format. A 7385 range is a half-open interval with a start and an end point, 7386 including the start point, but excluding the end point. A range may 7387 either be fully specified with explicit values for start point and 7388 end point, or have either start or end point be implicit. An 7389 implicit start point indicates the session's pause point, and if no 7390 pause point is set the start of the content. An implicit end point 7391 indicates the end of the content. The usage of both implicit start 7392 and end point is not allowed in the same range header, however, the 7393 exclusion of the range header has that meaning, i.e., from pause 7394 point (or start) until end of content. 7396 Regarding the half-open intervals; a range of A-B starts exactly 7397 at time A, but ends just before B. Only the start time of a media 7398 unit such as a video or audio frame is relevant. For example, 7399 assume that video frames are generated every 40 ms. A range of 7400 10.0-10.1 would include a video frame starting at 10.0 or later 7401 time and would include a video frame starting at 10.08, even 7402 though it lasted beyond the interval. A range of 10.0-10.08, on 7403 the other hand, would exclude the frame at 10.08. 7405 Please note the difference between NPT time scales' "now" and an 7406 implicit start value. Implicit value reference the current pause- 7407 point. While "now" is the currently ongoing time. In a time- 7408 progressing session with recording (retention for some or full 7409 time) the pause point may be 2 min into the session while now 7410 could be 1 hour into the session. 7412 By default, range intervals increase, where the second point is 7413 larger than the first point. 7415 Example: 7417 Range: npt=10-15 7419 However, range intervals can also decrease if the Scale header (see 7420 Section 18.46) indicates a negative scale value. For example, this 7421 would be the case when a playback in reverse is desired. 7423 Example: 7425 Scale: -1 7426 Range: npt=15-10 7428 Decreasing ranges are still half open intervals as described above. 7429 Thus, for range A-B, A is closed and B is open. In the above 7430 example, 15 is closed and 10 is open. An exception to this rule is 7431 the case when B=0 in a decreasing range. In this case, the range is 7432 closed on both ends, as otherwise there would be no way to reach 0 on 7433 a reverse playback for formats that have such a notion, like NPT and 7434 SMPTE. 7436 Example: 7438 Scale: -1 7439 Range: npt=15-0 7441 In this range both 15 and 0 are closed. 7443 A decreasing range interval without a corresponding negative Scale 7444 header is not valid. 7446 18.41. Referrer 7448 The Referrer request-header field allows the client to specify, for 7449 the server's benefit, the address (URI) of the resource from which 7450 the Request-URI was obtained. The URI refers to that of the 7451 presentation description, typically retrieved via HTTP. The Referrer 7452 request-header allows a server to generate lists of back-links to 7453 resources for interest, logging, optimized caching, etc. It also 7454 allows obsolete or mistyped links to be traced for maintenance. The 7455 Referrer field MUST NOT be sent if the Request-URI was obtained from 7456 a source that does not have its own URI, such as input from the user 7457 keyboard. 7459 If the field value is a relative URI, it SHOULD be interpreted 7460 relative to the Request-URI. The URI MUST NOT include a fragment 7461 identifier. 7463 Because the source of a link might be private information or might 7464 reveal an otherwise private information source, it is strongly 7465 recommended that the user be able to select whether or not the 7466 Referrer field is sent. For example, a streaming client could have a 7467 toggle switch for openly/anonymously, which would respectively enable 7468 /disable the sending of Referrer and From information. 7470 Clients SHOULD NOT include a Referrer header field in a (non-secure) 7471 RTSP request if the referring page was transferred with a secure 7472 protocol. 7474 18.42. Request-Status 7476 This request-header is used to indicate the end result for requests 7477 that take time to complete, such as PLAY (Section 13.4). It is sent 7478 in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report 7479 how the PLAY request concluded, either in success or in failure. The 7480 header carries a reference to the request it reports on using the 7481 CSeq number for the session indicated by the Session header in the 7482 request. It provides both a numerical status code (according to 7483 Section 8.1.1) and a human readable reason phrase. 7485 Example: 7486 Request-Status: cseq=63 status=500 reason="Media data unavailable" 7488 18.43. Require 7490 The Require request-header field is used by agents to ensure that the 7491 other end-point supports features that are required in respect to 7492 this request. It can also be used to query if the other end-point 7493 supports certain features, however, the use of the Supported general- 7494 header (Section 18.51) is much more effective in this purpose. In 7495 case any of the feature-tags listed by the Require header are not 7496 supported by the server or client receiving the request, it MUST 7497 respond to the request using the error code 551 (Option Not 7498 Supported) and include the Unsupported header listing those feature- 7499 tags which are NOT supported. This header does not apply to proxies, 7500 for the same functionality in respect to proxies see Proxy-Require 7501 header (Section 18.37) with the exception of media modifying proxies. 7502 Media modifying proxies, due to their nature of handling media in a 7503 way that is very similar to a server, do need to understand also the 7504 server's features to correctly serve the client. 7506 This is to make sure that the client-server interaction will 7507 proceed without delay when all features are understood by both 7508 sides, and only slow down if features are not understood (as in 7509 the example below). For a well-matched client-server pair, the 7510 interaction proceeds quickly, saving a round-trip often required 7511 by negotiation mechanisms. In addition, it also removes state 7512 ambiguity when the client requires features that the server does 7513 not understand. 7515 Example (Not complete): 7517 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 7518 CSeq: 302 7519 Require: funky-feature 7520 Funky-Parameter: funkystuff 7522 S->C: RTSP/2.0 551 Option not supported 7523 CSeq: 302 7524 Unsupported: funky-feature 7526 In this example, "funky-feature" is the feature-tag which indicates 7527 to the client that the fictional Funky-Parameter field is required. 7528 The relationship between "funky-feature" and Funky-Parameter is not 7529 communicated via the RTSP exchange, since that relationship is an 7530 immutable property of "funky-feature" and thus should not be 7531 transmitted with every exchange. 7533 Proxies and other intermediary devices MUST ignore this header. If a 7534 particular extension requires that intermediate devices support it, 7535 the extension should be tagged in the Proxy-Require field instead 7536 (see Section 18.37). See discussion in the proxies section 7537 (Section 15.1) about when to consider that a feature requires proxy 7538 support. 7540 18.44. Retry-After 7542 The Retry-After response-header field can be used with a 503 (Service 7543 Unavailable) or 553 (Proxy Unavailable) response to indicate how long 7544 the service is expected to be unavailable to the requesting client. 7545 This field MAY also be used with any 3rr (Redirection) response to 7546 indicate the minimum time the user-agent is asked to wait before 7547 issuing the redirected request. The value of this field can be 7548 either an RTSP-date or an integer number of seconds (in decimal) 7549 after the time of the response. 7551 Example: 7553 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 7554 Retry-After: 120 7556 In the latter example, the delay is 2 minutes. 7558 18.45. RTP-Info 7560 The RTP-Info general-header field is used to set RTP-specific 7561 parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY 7562 and GET_PARAMETER requests. For streams using RTP as transport 7563 protocol the RTP-Info header SHOULD be part of a 200 response to 7564 PLAY. 7566 The exclusion of the RTP-Info in a PLAY response for RTP 7567 transported media will result in a client needing to synchronize 7568 the media streams using RTCP. This may have negative impact as 7569 the RTCP can be lost, and does not need to be particularly timely 7570 in its arrival. Also functionality that informs the client from 7571 which packet a seek has occurred is affected. 7573 The RTP-Info MAY be included in SETUP responses to provide 7574 synchronization information when changing transport parameters, see 7575 Section 13.3. The RTP-Info header and the Range header MAY be 7576 included in a GET_PARAMETER request from client to server without any 7577 values to request the current playback point and corresponding RTP 7578 synchronization information. When the RTP-Info header is included in 7579 a Request the Range header MUST also be included (Note, Range header 7580 only MAY be used). The server response SHALL include both the Range 7581 header and the RTP-Info header. If the session is in Play state, 7582 then the value of the Range header SHALL be filled in with the 7583 current playback point and with the corresponding RTP-Info values. 7584 If the server is another state, no values are included in the RTP- 7585 Info header. The header is included in PLAY_NOTIFY requests with the 7586 Notify-Reason of end-of-stream to provide RTP information about the 7587 end of the stream. 7589 The header can carry the following parameters: 7591 url: Indicates the stream URI for which the following RTP parameters 7592 correspond, this URI MUST be the same as used in the SETUP 7593 request for this media stream. Any relative URI MUST use the 7594 Request-URI as base URI. This parameter MUST be present. 7596 ssrc: The Synchronization source (SSRC) that the RTP timestamp and 7597 sequence number provided applies to. This parameter MUST be 7598 present. 7600 seq: Indicates the sequence number of the first packet of the stream 7601 that is direct result of the request. This allows clients to 7602 gracefully deal with packets when seeking. The client uses 7603 this value to differentiate packets that originated before the 7604 seek from packets that originated after the seek. Note that a 7605 client may not receive the packet with the expressed sequence 7606 number, and instead packets with a higher sequence number, due 7607 to packet loss or reordering. This parameter is RECOMMENDED to 7608 be present. 7610 rtptime: MUST indicate the RTP timestamp value corresponding to the 7611 start time value in the Range response-header, or if not 7612 explicitly given the implied start point. The client uses this 7613 value to calculate the mapping of RTP time to NPT or other 7614 media timescale. This parameter SHOULD be present to ensure 7615 inter-media synchronization is achieved. There exists no 7616 requirement that any received RTP packet will have the same RTP 7617 timestamp value as the one in the parameter used to establish 7618 synchronization. 7620 A mapping from RTP timestamps to Network Time Protocol (NTP) 7621 format timestamps (wallclock) is available via RTCP. However, 7622 this information is not sufficient to generate a mapping from RTP 7623 timestamps to media clock time (NPT, etc.). Furthermore, in order 7624 to ensure that this information is available at the necessary time 7625 (immediately at startup or after a seek), and that it is delivered 7626 reliably, this mapping is placed in the RTSP control channel. 7628 In order to compensate for drift for long, uninterrupted 7629 presentations, RTSP clients should additionally map NPT to NTP, 7630 using initial RTCP sender reports to do the mapping, and later 7631 reports to check drift against the mapping. 7633 Example: 7635 Range:npt=3.25-15 7636 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 7637 rtptime=12345678,url="rtsp://example.com/foo/video" 7638 ssrc=9A9DE123:seq=30211;rtptime=29567112 7640 Lets assume that Audio uses a 16kHz RTP timestamp clock and Video 7641 a 90kHz RTP timestamp clock. Then the media synchronization is 7642 depicted in the following way. 7644 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 7645 Audio PA A 7646 Video V PV 7648 X: NPT time value = 3.25, from Range header. 7649 A: RTP timestamp value for Audio from RTP-Info header (12345678). 7650 V: RTP timestamp value for Video from RTP-Info header (29567112). 7651 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 7652 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 7653 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 7654 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 7656 18.46. Scale 7658 The Scale general-header indicates the requested or used view rate 7659 for the media resource being played back. A scale value of 1 7660 indicates normal play at the normal forward viewing rate. If not 1, 7661 the value corresponds to the rate with respect to normal viewing 7662 rate. For example, a ratio of 2 indicates twice the normal viewing 7663 rate ("fast forward") and a ratio of 0.5 indicates half the normal 7664 viewing rate. In other words, a ratio of 2 has content time increase 7665 at twice the playback time. For every second of elapsed (wallclock) 7666 time, 2 seconds of content time will be delivered. A negative value 7667 indicates reverse direction. For certain media transports this may 7668 require certain considerations to work consistent, see Appendix C.1 7669 for description on how RTP handles this. 7671 The transmitted data rate SHOULD NOT be changed by selection of a 7672 different scale value. The resulting bit-rate should be reasonably 7673 close to the nominal bit-rate of the content for Scale = 1. The 7674 server has to actively manipulate the data when needed to meet the 7675 bitrate constraints. Implementation of scale changes depends on the 7676 server and media type. For video, a server may, for example, deliver 7677 only key frames or selected frames. For audio, it may time-scale the 7678 audio while preserving pitch or, less desirably, deliver fragments of 7679 audio, or completely mute the audio. 7681 The server and content may restrict the range of scale values that it 7682 supports. The supported values are indicated by the Media-Properties 7683 header (Section 18.29). The client SHOULD only indicate request 7684 values to be supported. However, as the values may change as the 7685 content progresses a requested value may no longer be valid when the 7686 request arrives. Thus, a non-supported value in a request does not 7687 generate an error, only forces the server to choose the closest 7688 value. The response MUST always contain the actual scale value 7689 chosen by the server. 7691 If the server does not implement the possibility to scale, it will 7692 not return a Scale header. A server supporting Scale operations for 7693 PLAY MUST indicate this with the use of the "play.scale" feature-tag. 7695 When indicating a negative scale for a reverse playback, the Range 7696 header MUST indicate a decreasing range as described in 7697 Section 18.40. 7699 Example of playing in reverse at 3.5 times normal rate: 7701 Scale: -3.5 7702 Range: npt=15-10 7704 18.47. Seek-Style 7706 When a client sends a PLAY request with a Range header to perform a 7707 random access to the media, the client does not know if the server 7708 will pick the first media samples or the first random access point 7709 prior to the request range. Depending on use case, the client may 7710 have a strong preference. To express this preference and provide the 7711 client with information on how the server actually acted on that 7712 preference the Seek-Style general-header is defined. 7714 Seek-Style is a general-header that MAY be included in any PLAY 7715 request to indicate the client's preference for any media stream that 7716 has random access properties. The server MUST always include the 7717 header in any PLAY response for media with random access properties 7718 to indicate what policy was applied. A server that receives an 7719 unknown Seek-Style policy MUST ignore it and select the server 7720 default policy. A client receiving an unknown policy MUST ignore it 7721 and use the Range header and any media synchronization information as 7722 basis to determine what the server did. 7724 This specification defines the following seek policies that may be 7725 requested (see also Section 4.7.1): 7727 RAP: Random Access Point (RAP) is the behavior of requesting the 7728 server to locate the closest previous random access point that 7729 exists in the media aggregate and deliver from that. By 7730 requesting a RAP, media quality will be the best possible as all 7731 media will be delivered from a point where full media state can be 7732 established in the media decoder. 7734 CoRAP: Conditional Random Access Point (CoRAP) is a variant of the 7735 above RAP behavior. This policy is primarily intended for cases 7736 where there is larger distance between the random access points in 7737 the media. CoRAP is conditioned on that there is a Random Access 7738 Point closer to the requested start point than to the current 7739 pause point. This policy assumes that the media state existing 7740 prior to the pause is usable if delivery is continued. If the 7741 client or server knows that this is not the fact the RAP policy 7742 should be used. In other words: in most cases when the client 7743 requests a start point prior to the current pause point, a valid 7744 decoding dependency chain from the media delivered prior to the 7745 pause and to the requested media unit will not exist. If the 7746 server searched to a random access point the server MUST return 7747 the CoRAP policy in the Seek-Style header and adjust the Range 7748 header to reflect the position of the picked RAP. In case the 7749 random access point is further away and the server selects to 7750 continue from the current pause point it MUST include the "Next" 7751 policy in the Seek-Style header and adjust the Range header start 7752 point to the current pause point. 7754 First-Prior: The first-prior policy will start delivery with the 7755 media unit that has a playout time first prior to the requested 7756 time. For discrete media that would only include media units that 7757 would still be rendered at the request time. For continuous media 7758 that is media that will be rendered during the requested start 7759 time of the range. 7761 Next: The next media units after the provided start time of the 7762 range. For continuous framed media that would mean the first next 7763 frame after the provided time. For discrete media the first unit 7764 that is to be rendered after the provided time. The main usage 7765 for this case is when the client knows it has all media up to a 7766 certain point and would like to continue delivery so that a 7767 complete non-interrupted media playback can be achieved. Example 7768 of such scenarios include switching from a broadcast/multicast 7769 delivery to a unicast based delivery. This policy MUST only be 7770 used on the client's explicit request. 7772 Please note that these expressed preferences exist for optimizing the 7773 startup time or the media quality. The "Next" policy breaks the 7774 normal definition of the Range header to enable a client to request 7775 media with minimal overlap, although some may still occur for 7776 aggregated sessions. RAP and First-Prior both fulfill the 7777 requirement of providing media from the requested range and forward. 7778 However, unless RAP is used, the media quality for many media codecs 7779 using predictive methods can be severely degraded unless additional 7780 data is available as, for example, already buffered, or through other 7781 side channels. 7783 18.48. Server 7785 The Server general-header field contains information about the 7786 software used by the origin server to create or handle the request. 7787 The field can contain multiple product tokens and comments 7788 identifying the server and any significant subproducts. The product 7789 tokens are listed in order of their significance for identifying the 7790 application. 7792 Example: 7794 Server: PhonyServer/1.0 7796 If the response is being forwarded through a proxy, the proxy 7797 application MUST NOT modify the Server response-header. Instead, it 7798 SHOULD include a Via field (Section 18.57). If the response is 7799 generated by the proxy, the proxy application MUST return the Server 7800 response-header as previously returned by the server. 7802 18.49. Session 7804 The Session general-header field identifies an RTSP session. An RTSP 7805 session is created by the server as a result of a successful SETUP 7806 request and in the response the session identifier is given to the 7807 client. The RTSP session exists until destroyed by a TEARDOWN, 7808 REDIRECT or timed out by the server. 7810 The session identifier is chosen by the server (see Section 4.3) and 7811 MUST be returned in the SETUP response. Once a client receives a 7812 session identifier, it MUST be included in any request related to 7813 that session. This means that the Session header MUST be included in 7814 a request, using the following methods: PLAY, PAUSE, and TEARDOWN, 7815 and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, 7816 and REDIRECT, and MUST NOT be included in DESCRIBE. The Session 7817 header MUST NOT be included in the following methods, if these 7818 requests are pipelined and if the session identifier is not yet 7819 known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and 7820 GET_PARAMETER. 7822 In an RTSP response the session header MUST be included in methods, 7823 SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and 7824 REDIRECT, and if included in the request of the following methods it 7825 MUST also be included in the response, OPTIONS, GET_PARAMETER, and 7826 SET_PARAMETER, and MUST NOT be included in DESCRIBE responses. 7828 Note that a session identifier identifies an RTSP session across 7829 transport sessions or connections. RTSP requests for a given session 7830 can use different URIs (Presentation and media URIs). Note, that 7831 there are restrictions depending on the session which URIs that are 7832 acceptable for a given method. However, multiple "user" sessions for 7833 the same URI from the same client will require use of different 7834 session identifiers. 7836 The session identifier is needed to distinguish several delivery 7837 requests for the same URI coming from the same client. 7839 The response 454 (Session Not Found) MUST be returned if the session 7840 identifier is invalid. 7842 The header MAY include a parameter for session timeout period. If 7843 not explicitly provided this value is set to 60 seconds. As this 7844 affects how often session keep-alives are needed values smaller than 7845 30 seconds are not recommended. However, larger than default values 7846 can be useful in applications of RTSP that have inactive but 7847 established sessions for longer time periods. 7849 60 seconds was chosen as session timeout value due to: Resulting 7850 in not too frequent keep-alive messages and having low sensitivity 7851 to variations in request response timing. If one reduces the 7852 timeout value to below 30 seconds the corresponding request 7853 response timeout becomes a significant part of the session 7854 timeout. 60 seconds also allows for reasonably rapid recovery of 7855 committed server resources in case of client failure. 7857 18.50. Speed 7859 The Speed general-header field requests the server to deliver 7860 specific amounts of nominal media time per unit of delivery time, 7861 contingent on the server's ability and desire to serve the media 7862 stream at the given speed. The client requests the delivery speed to 7863 be within a given range with a lower and upper bound. The server 7864 SHALL deliver at the highest possible speed within the range, but not 7865 faster than the upper-bound, for which the underlying network path 7866 can support the resulting transport data rates. As long as any speed 7867 value within the given range can be provided the server SHALL NOT 7868 modify the media quality. Only if the server is unable to deliver 7869 media at the speed value provided by the lower bound shall it reduce 7870 the media quality. 7872 Implementation of the Speed functionality by the server is OPTIONAL. 7873 The server can indicate its support through a feature-tag, 7874 play.speed. The lack of a Speed header in the response is an 7875 indication of lack of support of this functionality. 7877 The speed parameter values are expressed as a positive decimal value, 7878 e.g., a value of 2.0 indicates that data is to be delivered twice as 7879 fast as normal. A speed value of zero is invalid. The range is 7880 specified in the form "lower bound - upper bound". The lower bound 7881 value may be smaller or equal to the upper bound. All speeds may not 7882 be possible to support. Therefore the server MAY modify the 7883 requested values to the closest supported. The actual supported 7884 speed MUST be included in the response. Note, however, that the use 7885 cases may vary and that Speed value ranges such as 0.7 - 0.8, 7886 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 7888 Example: 7890 Speed: 1.0-2.5 7892 Use of this header changes the bandwidth used for data delivery. It 7893 is meant for use in specific circumstances where delivery of the 7894 presentation at a higher or lower rate is desired. The main use 7895 cases are buffer operations or local scale operations. Implementors 7896 should keep in mind that bandwidth for the session may be negotiated 7897 beforehand (by means other than RTSP), and therefore re-negotiation 7898 may be necessary. To perform Speed operations the server needs to 7899 ensure that the network path can support the resulting bit-rate. 7900 Thus the media transport needs to support feedback so that the server 7901 can react and adapt to the available bitrate. 7903 18.51. Supported 7905 The Supported general-header enumerates all the extensions supported 7906 by the client or server using feature tags. The header carries the 7907 extensions supported by the message sending client or server. The 7908 Supported header MAY be included in any request. When present in a 7909 request, the receiver MUST respond with its corresponding Supported 7910 header. Note that the Supported header is also included in 4xx and 7911 5xx responses. 7913 The Supported header contains a list of feature-tags, described in 7914 Section 4.5, that are understood by the client or server. These 7915 feature tags are the ones the server or client support in general, 7916 and is not specific to the request resource. 7918 Example: 7920 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 7921 Supported: foo, bar, blech 7922 User-Agent: PhonyClient/1.2 7924 S->C: RTSP/2.0 200 OK 7925 Supported: bar, blech, baz 7927 18.52. Terminate-Reason 7929 The Terminate-Reason request-header allows the server when sending a 7930 REDIRECT or TEARDOWN request to provide a reason for the session 7931 termination and any additional information. This specification 7932 identifies three reasons for Redirections and may be extended in the 7933 future: 7935 Server-Admin: The server needs to be shutdown for some 7936 administrative reason. 7938 Session-Timeout: A client's session has been kept alive for extended 7939 periods of time and the server has determined that it needs to 7940 reclaim the resources associated with this session. 7942 Internal-Error An internal error that is impossible to recover from 7943 has occurred forcing the server to terminate the session. 7945 The Server may provide additional parameters containing information 7946 around the redirect. This specification defines the following ones. 7948 time: Provides a wallclock time when the server will stop providing 7949 any service. 7951 user-msg: An UTF-8 text string with a message from the server to the 7952 user. This message SHOULD be displayed to the user. 7954 18.53. Timestamp 7956 The Timestamp general-header describes when the agent sent the 7957 request. The value of the timestamp is of significance only to the 7958 agent and may use any timescale. The responding agent MUST echo the 7959 exact same value and MAY, if it has accurate information about this, 7960 add a floating point number indicating the number of seconds that has 7961 elapsed since it has received the request. The timestamp can be used 7962 by the agent to compute the round-trip time to the responding agent 7963 so that it can adjust the timeout value for retransmissions when 7964 running over an unreliable protocol. It also resolves retransmission 7965 ambiguities for unreliable transport of RTSP. 7967 Note that the present specification provides only for reliable 7968 transport of RTSP messages. The Timestamp general-header is 7969 specified in case the protocol is extended in the future to use 7970 unreliable transport. 7972 18.54. Transport 7974 The Transport general-header indicates which transport protocol is to 7975 be used and configures its parameters such as destination address, 7976 compression, multicast time-to-live and destination port for a single 7977 stream. It sets those values not already determined by a 7978 presentation description. 7980 A Transport request-header MAY contain a list of transport options 7981 acceptable to the client, in the form of multiple transport 7982 specification entries. Transport specifications are comma separated, 7983 listed in decreasing order of preference. Each transport 7984 specification consists of a transport protocol identifier, followed 7985 by any number of parameters, each parameter separated by a semicolon. 7986 A Transport request-header MAY contain multiple transport 7987 specifications using the same transport protocol Identifier. The 7988 server MUST return a Transport response-header in the response to 7989 indicate the values actually chosen if any. If no transport 7990 specification is supported, no transport header is returned and the 7991 response MUST use the status code 461 (Unsupported Transport) 7992 (Section 17.4.26). In case more than one transport specification was 7993 present in the request, the server MUST return the single transport 7994 specification (transport-spec) which was actually chosen, if any. 7995 The number of transport-spec entries is expected to be limited as the 7996 client will receive guidance on what configurations that are possible 7997 from the presentation description. 7999 The Transport header MAY also be used in subsequent SETUP requests to 8000 change transport parameters. A server MAY refuse to change 8001 parameters of an existing stream. 8003 The transport protocol identifier defines for each transport 8004 specification which transport protocol to use and any related rules. 8005 Each transport protocol identifier defines the parameters that are 8006 required to occur; additional optional parameters MAY occur. This 8007 flexibility is provided as parameters may be different and provide 8008 different options to the RTSP Agent. A transport specification may 8009 only contain one of any given parameter within it. A parameter 8010 consists of a name and optionally a value string. Parameters MAY be 8011 given in any order. Additionally, a transport specification may only 8012 contain either of the unicast or the multicast transport type 8013 parameter. The transport protocol identifier and all parameters need 8014 to be understood in a transport specification; if not, the transport 8015 specification MUST be ignored. An RTSP proxy of any type that uses 8016 or modifies the transport specification, e.g., access proxy or 8017 security proxy, MUST remove specifications with unknown parameters 8018 before forwarding the RTSP message. If that results in no remaining 8019 transport specification the proxy SHALL send a 461 (Unsupported 8020 Transport) (Section 17.4.26) response without any Transport header. 8022 The Transport header is restricted to describing a single media 8023 stream. (RTSP can also control multiple streams as a single 8024 entity.) Making it part of RTSP rather than relying on a 8025 multitude of session description formats greatly simplifies 8026 designs of firewalls. 8028 The general syntax for the transport protocol identifier is a list of 8029 slash separated tokens: 8031 Value1/Value2/Value3... 8033 Which for RTP transports take the form: 8035 RTP/profile/lower-transport. 8037 The default value for the "lower-transport" parameters is specific to 8038 the profile. For RTP/AVP, the default is UDP. 8040 There are two different methods for how to specify where the media 8041 should be delivered for unicast transport: 8043 dest_addr: The presence of this parameter and its values indicates 8044 the destination address or addresses (host address and port 8045 pairs for IP flows) necessary for the media transport. 8047 No dest_addr: The lack of the dest_addr parameter indicates that the 8048 server MUST send media to the same address from which the RTSP 8049 messages originates. 8051 The choice of method for indicating where the media is to be 8052 delivered depends on the use case. In some cases the only allowed 8053 method will be to use no explicit address indication and have the 8054 server deliver media to the source of the RTSP messages. 8056 For Multicast there is several methods for specifying addresses but 8057 they are different in how they work compared with unicast: 8059 dest_addr with client picked address: The address and relevant 8060 parameters, like TTL (scope), for the actual multicast group to 8061 deliver the media to. There are security implications 8062 (Section 21) with this method that need to be addressed if 8063 using this method because a RTSP server can be used as a Denial 8064 of Service (DoS) attacker on an existing multicast group. 8066 dest_addr using Session Description Information: The information 8067 included in the transport header can all be coming from the 8068 session description, e.g., the SDP c= and m= line. This 8069 mitigates some of the security issues of the previous methods 8070 as it is the session provider that picks the multicast group 8071 and scope. The client MUST include the information if it is 8072 available in the session description. 8074 No dest_addr: The behavior when no explicit multicast group is 8075 present in a request is not defined. 8077 An RTSP proxy will need to take care. If the media is not desired to 8078 be routed through the proxy, the proxy will need to introduce the 8079 destination indication. 8081 Below are the configuration parameters associated with transport: 8083 General parameters: 8085 unicast / multicast: This parameter is a mutually exclusive 8086 indication of whether unicast or multicast delivery will be 8087 attempted. One of the two values MUST be specified. Clients 8088 that are capable of handling both unicast and multicast 8089 transmission need to indicate such capability by including two 8090 full transport-specs with separate parameters for each. 8092 layers: The number of multicast layers to be used for this media 8093 stream. The layers are sent to consecutive addresses starting 8094 at the dest_addr address. If the parameter is not included, it 8095 defaults to a single layer. 8097 dest_addr: A general destination address parameter that can contain 8098 one or more address specifications. Each combination of 8099 protocol/profile/lower transport needs to have the format and 8100 interpretation of its address specification defined. For RTP/ 8101 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8102 containing a host address and port. Note, only a single 8103 destination parameter per transport spec is intended. The 8104 usage of multiple destinations to distribute a single media to 8105 multiple entities is unspecified. 8107 The client originating the RTSP request MAY specify the 8108 destination address of the stream recipient with the host 8109 address part of the tuple. When the destination address is 8110 specified, the recipient may be a different party than the 8111 originator of the request. To avoid becoming the unwitting 8112 perpetrator of a remote-controlled denial-of-service attack, a 8113 server MUST perform security checks (see Section 21.2.1) and 8114 SHOULD log such attempts before allowing the client to direct a 8115 media stream to a recipient address not chosen by the server. 8116 Implementations cannot rely on TCP as reliable means of client 8117 identification. If the server does not allow the host address 8118 part of the tuple to be set, it MUST return 463 (Destination 8119 Prohibited). 8121 The host address part of the tuple MAY be empty, for example 8122 ":58044", in cases when it is desired to specify only the 8123 destination port. Responses to requests including the 8124 Transport header with a dest_addr parameter SHOULD include the 8125 full destination address that is actually used by the server. 8126 The server MUST NOT remove address information present already 8127 in the request when responding unless the protocol requires it. 8129 src_addr: A general source address parameter that can contain one or 8130 more address specifications. Each combination of protocol/ 8131 profile/lower transport needs to have the format and 8132 interpretation of its address specification defined. For RTP/ 8133 AVP/UDP and RTP/AVP/TCP, the address specification is a tuple 8134 containing a host address and port. 8136 This parameter MUST be specified by the server if it transmits 8137 media packets from another address than the one RTSP messages 8138 are sent to. This will allow the client to verify source 8139 address and give it a destination address for its RTCP feedback 8140 packets, if RTP is used. The address or addresses indicated in 8141 the src_addr parameter SHOULD be used both for sending and 8142 receiving of the media stream's data packets. The main reasons 8143 are threefold: First, indicating the port and source address(s) 8144 lets the receiver know where from the packets is expected to 8145 originate. Secondly, traversal of NATs is greatly simplified 8146 when traffic is flowing symmetrically over a NAT binding. 8147 Thirdly, certain NAT traversal mechanisms, needs to know to 8148 which address and port to send so called "binding packets" from 8149 the receiver to the sender, thus creating an address binding in 8150 the NAT that the sender to receiver packet flow can use. 8152 This information may also be available through SDP. 8153 However, since this is more a feature of transport than 8154 media initialization, the authoritative source for this 8155 information should be in the SETUP response. 8157 mode: The mode parameter indicates the methods to be supported for 8158 this session. Currently defined valid values are "PLAY". If 8159 not provided, the default is "PLAY". The "RECORD" value was 8160 defined in RFC 2326 and is in this specification unspecified 8161 but reserved. RECORD and other values may be specified in the 8162 future. 8164 interleaved: The interleaved parameter implies mixing the media 8165 stream with the control stream in whatever protocol is being 8166 used by the control stream, using the mechanism defined in 8167 Section 14. The argument provides the channel number to be 8168 used in the $ block (see Section 14) and MUST be present. This 8169 parameter MAY be specified as an interval, e.g., 8170 interleaved=4-5 in cases where the transport choice for the 8171 media stream requires it, e.g., for RTP with RTCP. The channel 8172 number given in the request is only a guidance from the client 8173 to the server on what channel number(s) to use. The server MAY 8174 set any valid channel number in the response. The declared 8175 channel(s) are bi-directional, so both end-parties MAY send 8176 data on the given channel. One example of such usage is the 8177 second channel used for RTCP, where both server and client send 8178 RTCP packets on the same channel. 8180 This allows RTP/RTCP to be handled similarly to the way that 8181 it is done with UDP, i.e., one channel for RTP and the other 8182 for RTCP. 8184 MIKEY: This parameter is used in conjunction with transport 8185 specifications that can utilize MIKEY [RFC3830] for security 8186 context establishment. So far only the SRTP based RTP profiles 8187 SAVP and SAVPF can utilize MIKEY and this is defined in 8188 Appendix C.1.4.1. This parameter can be included both in 8189 request and response messages. The binary MIKEY message SHALL 8190 be BASE64 [RFC4648] encoded before being included in the value 8191 part of the parameter, where the encoding adheres to the 8192 definition in Section 4 of RFC 4648 and where the padding bits 8193 are set to zero. 8195 Multicast-specific: 8197 ttl: multicast time-to-live for IPv4. When included in requests the 8198 value indicate the TTL value that the client requests the 8199 server to use. In a response, the value actually being used by 8200 the server is returned. A server will need to consider what 8201 values that are reasonable and also the authority of the user 8202 to set this value. Corresponding functions are not needed for 8203 IPv6 as the scoping is part of the IPv6 multicast address 8204 [RFC4291]. 8206 RTP-specific: 8208 These parameters MAY only be used if the media transport protocol is 8209 RTP. 8211 ssrc: The ssrc parameter, if included in a SETUP response, indicates 8212 the RTP SSRC [RFC3550] value(s) that will be used by the media 8213 server for RTP packets within the stream. It is expressed as 8214 an eight digit hexadecimal value. 8216 The ssrc parameter MUST NOT be specified in requests. The 8217 functionality of specifying the ssrc parameter in a SETUP 8218 request is deprecated as it is incompatible with the 8219 specification of RTP in RFC 3550[RFC3550]. If the parameter is 8220 included in the Transport header of a SETUP request, the server 8221 SHOULD ignore it, and choose appropriate SSRCs for the stream. 8222 The server SHOULD set the ssrc parameter in the Transport 8223 header of the response. 8225 RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing 8226 [RFC5761] on a single underlying transport stream / flow. The 8227 presence of this parameter in a SETUP request indicates the 8228 client's support and requires the server to use RTP and RTCP 8229 multiplexing. The client SHALL only include one transport 8230 stream in the Transport header specification. To provide the 8231 server with a choice between using RTP/RTCP multiplexing or 8232 not, two different transport header specifications must be 8233 included. 8235 The parameters setup and connection defined below MAY only be used if 8236 the media transport protocol of the lower-level transport is 8237 connection-oriented (such as TCP). However, these parameters MUST 8238 NOT be used when interleaving data over the RTSP connection. 8240 setup: Clients use the setup parameter on the Transport line in a 8241 SETUP request, to indicate the roles it wishes to play in a TCP 8242 connection. This parameter is adapted from [RFC4145]. The use 8243 of this parameter in RTP/AVP/TCP non-interleaved transport is 8244 discussed in Appendix C.2.2; the discussion below is limited to 8245 syntactic issues. Clients may specify the following values for 8246 the setup parameter: 8248 active: The client will initiate an outgoing connection. 8250 passive: The client will accept an incoming connection. 8252 actpass: The client is willing to accept an incoming 8253 connection or to initiate an outgoing connection. 8255 If a client does not specify a setup value, the "active" value 8256 is assumed. 8258 In response to a client SETUP request where the setup parameter 8259 is set to "active", a server's 2xx reply MUST assign the setup 8260 parameter to "passive" on the Transport header line. 8262 In response to a client SETUP request where the setup parameter 8263 is set to "passive", a server's 2xx reply MUST assign the setup 8264 parameter to "active" on the Transport header line. 8266 In response to a client SETUP request where the setup parameter 8267 is set to "actpass", a server's 2xx reply MUST assign the setup 8268 parameter to "active" or "passive" on the Transport header 8269 line. 8271 Note that the "holdconn" value for setup is not defined for 8272 RTSP use, and MUST NOT appear on a Transport line. 8274 connection: Clients use the connection parameter in a transport 8275 specification part of the Transport header in a SETUP request, 8276 to indicate the client's preference for either reusing an 8277 existing connection between client and server (in which case 8278 the client sets the "connection" parameter to "existing"), or 8279 requesting the creation of a new connection between client and 8280 server (in which cast the client sets the "connection" 8281 parameter to "new"). Typically, clients use the "new" value 8282 for the first SETUP request for a URL, and "existing" for 8283 subsequent SETUP requests for a URL. 8285 If a client SETUP request assigns the "new" value to 8286 "connection", the server response MUST also assign the "new" 8287 value to "connection" on the Transport line. 8289 If a client SETUP request assigns the "existing" value to 8290 "connection", the server response MUST assign a value of 8291 "existing" or "new" to "connection" on the Transport line, at 8292 its discretion. 8294 The default value of "connection" is "existing", for all SETUP 8295 requests (initial and subsequent). 8297 The combination of transport protocol, profile and lower transport 8298 needs to be defined. A number of combinations are defined in the 8299 Appendix C. 8301 Below is a usage example, showing a client advertising the capability 8302 to handle multicast or unicast, preferring multicast. Since this is 8303 a unicast-only stream, the server responds with the proper transport 8304 parameters for unicast. 8306 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 8307 CSeq: 302 8308 Transport: RTP/AVP;multicast;mode="PLAY", 8309 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8310 "192.0.2.5:3457";mode="PLAY" 8311 Accept-Ranges: npt, smpte, clock 8312 User-Agent: PhonyClient/1.2 8314 S->C: RTSP/2.0 200 OK 8315 CSeq: 302 8316 Date: Fri, 20 Dec 2013 10:20:32 +0000 8317 Session: 47112344 8318 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 8319 "192.0.2.5:3457";src_addr="192.0.2.224:6256"/ 8320 "192.0.2.224:6257";mode="PLAY" 8321 Accept-Ranges: npt 8322 Media-Properties: Random-Access=0.6, Dynamic, 8323 Time-Limited=20081128T165900 8325 18.55. Unsupported 8327 The Unsupported response-header lists the features not supported by 8328 the responding RTSP agent. In the case where the feature was 8329 specified via the Proxy-Require field (Section 18.37), if there is a 8330 proxy on the path between the client and the server, the proxy MUST 8331 send a response message with a status code of 551 (Option Not 8332 Supported). The request MUST NOT be forwarded. 8334 See Section 18.43 for a usage example. 8336 18.56. User-Agent 8338 The User-Agent general-header field contains information about the 8339 user agent originating the request or producing a response. This is 8340 for statistical purposes, the tracing of protocol violations, and 8341 automated recognition of user agents for the sake of tailoring 8342 responses to avoid particular user agent limitations. User agents 8343 SHOULD include this field with requests. The field can contain 8344 multiple product tokens and comments identifying the agent and any 8345 subproducts which form a significant part of the user agent. By 8346 convention, the product tokens are listed in order of their 8347 significance for identifying the application. 8349 Example: 8351 User-Agent: PhonyClient/1.2 8353 18.57. Via 8355 The Via general-header field MUST be used by proxies to indicate the 8356 intermediate protocols and recipients between the user agent and the 8357 server on requests, and between the origin server and the client on 8358 responses. The field is intended to be used for tracking message 8359 forwards, avoiding request loops, and identifying the protocol 8360 capabilities of all senders along the request/response chain. 8362 Multiple Via field values represents each proxy that has forwarded 8363 the message. Each recipient MUST append its information such that 8364 the end result is ordered according to the sequence of forwarding 8365 applications. 8367 Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by 8368 default, forward the names and ports of hosts within the private/ 8369 protected region. This information SHOULD only be propagated if 8370 explicitly enabled. If not enabled, the via-received of any host 8371 behind the firewall/NAT SHOULD be replaced by an appropriate 8372 pseudonym for that host. 8374 For organizations that have strong privacy requirements for hiding 8375 internal structures, a proxy MAY combine an ordered subsequence of 8376 Via header field entries with identical sent-protocol values into a 8377 single such entry. Applications MUST NOT combine entries which have 8378 different received-protocol values. 8380 18.58. WWW-Authenticate 8382 The WWW-Authenticate response-header field MUST be included in 401 8383 (Unauthorized) response messages. The field value consists of at 8384 least one challenge that indicates the authentication scheme(s) and 8385 parameters applicable to the Request-URI. This header MUST only be 8386 used in response messages related to client to server requests. 8388 The HTTP access authentication process is described in [RFC2617] with 8389 some clarification in Section 19.1. User agents are advised to take 8390 special care in parsing the WWW-Authenticate field value as it might 8391 contain more than one challenge, or if more than one WWW-Authenticate 8392 header field is provided, the contents of a challenge itself can 8393 contain a comma-separated list of authentication parameters. 8395 19. Security Framework 8397 The RTSP security framework consists of two high level components: 8398 the pure authentication mechanisms based on HTTP authentication, and 8399 the message transport protection based on TLS, which is independent 8400 of RTSP. Because of the similarity in syntax and usage between RTSP 8401 servers and HTTP servers, the security for HTTP is re-used to a large 8402 extent. 8404 19.1. RTSP and HTTP Authentication 8406 RTSP and HTTP share common authentication schemes, and thus follow 8407 the same usage guidelines as specified in [RFC2617] with the 8408 additions for digest authentication specified below in 8409 Section 19.1.1. Servers SHOULD implement both basic and digest 8410 [RFC2617] authentication. Clients MUST implement both basic and 8411 digest authentication [RFC2617] so that a server that requires the 8412 client to authenticate can trust that the capability is present. 8414 It should be stressed that using the HTTP authentication alone does 8415 not provide full control message security. Therefore, in 8416 environments requiring tighter security for the control messages, TLS 8417 SHOULD be used, see Section 19.2. Any RTSP message containing an 8418 Authorization header using basic authorization MUST be using a TLS 8419 connection with confidentiality protection enabled, i.e., no NULL 8420 encryption. 8422 In cases where there is a chain of proxies between the client and the 8423 server, each proxy may individually request the client or previous 8424 proxy to authenticate itself. This is done using the Proxy- 8425 Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36) 8426 and the Proxy-Authentication-Info (Section 18.35) headers. These 8427 headers are hop-by-hop headers and are only scoped to the current 8428 connection and hop. Thus if a proxy chain exists, a proxy connecting 8429 to another proxy will have to act as a client to authorize itself 8430 towards the next proxy. The WWW-Authenticate (Section 18.58), 8431 Authorization (Section 18.8) and Authentication-Info (Section 18.7) 8432 headers are end-to-end and must not be modified by proxies. 8434 This authentication mechanism works only for client to server 8435 requests as currently defined. This leaves server to client request 8436 outside of the context of TLS based communication more vulnerable to 8437 message injection attacks on the client. Based on the server to 8438 client methods that exist, the potential risks are various; hijacking 8439 (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks 8440 with uncertain results (SET_PARAMETER). 8442 19.1.1. Digest Authentication 8444 This section describes the modifications and clarifications required 8445 to apply the HTTP Digest authentication scheme to RTSP. The RTSP 8446 scheme usage is almost completely identical to that for HTTP 8447 [RFC2617]. These are based on the procedures defined for SIP 2.0 8448 [RFC3261]. 8450 The rules for Digest authentication follow those defined in 8451 [RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the 8452 following differences: 8454 1. Use the ABNF specified in this document, rather than the one in 8455 [RFC2617]. Consequently the following is assured: 8457 * Using the right RTSP URIs allowed in the challenge as well as 8458 in the digest. 8460 * Resolved the error in the "uri" parameter of the Authorization 8461 header in [RFC2617]. 8463 2. If MTags are used then the example procedure for choosing a nonce 8464 based on Etag can work based on replacing ETag with the MTag. 8466 3. As a clarification to the calculation of the A2 value for message 8467 integrity assurance in the Digest authentication scheme, 8468 implementers should assume, when the entity-body is empty (that 8469 is, when the RTSP messages have no message body) that the hash of 8470 the message-body resolves to the MD5 hash of an empty string, or: 8471 H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e". 8473 4. RFC 2617 notes that a cnonce value MUST NOT be sent in an 8474 Authorization (and by extension Proxy-Authorization) header field 8475 if no qop directive has been sent. Therefore, any algorithms 8476 that have a dependency on the cnonce (including "MD5-Sess") 8477 require that the qop directive be sent. Use of the "qop" 8478 parameter is optional in RFC 2617 for the purposes of backwards 8479 compatibility with RFC 2069; since this specification defines 8480 RTSP 2.0 there is no backwards compatibility issue with 8481 mandating. Thus, all RTSP agents MUST implement qop-options. 8483 19.2. RTSP over TLS 8485 RTSP agents MUST implement RTSP over TLS as defined in this section 8486 and the next Section 19.3. RTSP MUST follow the same guidelines with 8487 regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. 8488 RTSP over TLS is separated from unsecured RTSP both on the URI level 8489 and the port level. Instead of using the "rtsp" scheme identifier in 8490 the URI, the "rtsps" scheme identifier MUST be used to signal RTSP 8491 over TLS. If no port is given in a URI with the "rtsps" scheme, port 8492 322 MUST be used for TLS over TCP/IP. 8494 When a client tries to setup an insecure channel to the server (using 8495 the "rtsp" URI), and the policy for the resource requires a secure 8496 channel, the server MUST redirect the client to the secure service by 8497 sending a 301 redirect response code together with the correct 8498 Location URI (using the "rtsps" scheme). A user or client MAY 8499 upgrade a non secured URI to a secured by changing the scheme from 8500 "rtsp" to "rtsps". A server implementing support for "rtsps" MUST 8501 allow this. 8503 It should be noted that TLS allows for mutual authentication (when 8504 using both server and client certificates). Still, one of the more 8505 common ways TLS is used is to only provide server side authentication 8506 (often to avoid client certificates). TLS is then used in addition 8507 to HTTP authentication, providing transport security and server 8508 authentication, while HTTP Authentication is used to authenticate the 8509 client. 8511 RTSP includes the possibility to keep a TCP session up between the 8512 client and server, throughout the RTSP session lifetime. It may be 8513 convenient to keep the TCP session, not only to save the extra setup 8514 time for TCP, but also the extra setup time for TLS (even if TLS uses 8515 the resume function, there will be almost two extra round trips). 8516 Still, when TLS is used, such behavior introduces extra active state 8517 in the server, not only for TCP and RTSP, but also for TLS. This may 8518 increase the vulnerability to DoS attacks. 8520 There exists a potential security vulnerability when reusing TCP and 8521 TLS state for different resources (URIs). If two different host 8522 names point at the same IP address it can be desirable to re-use the 8523 TCP/TLS connection to that server. In that case the RTSP agent 8524 having the TCP/TLS connection MUST verify that the server certificate 8525 associated with the connection has a SubjectAltName matching the host 8526 name present in the URI for the resource an RTSP request is to be 8527 issued for. 8529 In addition to these recommendations, Section 19.3 gives further 8530 recommendations of TLS usage with proxies. 8532 19.3. Security and Proxies 8534 The nature of a proxy is often to act as a "man-in-the-middle", while 8535 security is often about preventing the existence of a "man-in-the- 8536 middle". This section provides clients with the possibility to use 8537 proxies even when applying secure transports (TLS) between the RTSP 8538 agents. The TLS proxy mechanism allows for server and proxy 8539 identification using certificates. However, the client cannot be 8540 identified based on certificates. The client needs to select between 8541 using the procedure specified below or using a TLS connection 8542 directly (by-passing any proxies) to the server. The choice may be 8543 dependent on policies. 8545 There are in general two categories of proxies, the transparent 8546 proxies (of which the client is not aware) and the non-transparent 8547 proxies (of which the client is aware). This memo specifies only 8548 non-transparent RTSP proxies, i.e., proxies visible to the RTSP 8549 client and RTSP server. An infrastructure based on proxies requires 8550 that the trust model is such that both client and servers can trust 8551 the proxies to handle the RTSP messages correctly. To be able to 8552 trust a proxy, the client and server also need to be aware of the 8553 proxy. Hence, transparent proxies cannot generally be seen as 8554 trusted and will not work well with security (unless they work only 8555 at the transport layer). In the rest of this section any reference 8556 to proxy will be to a non-transparent proxy, which inspects or 8557 manipulates the RTSP messages. 8559 HTTP Authentication is built on the assumption of proxies and can 8560 provide user-proxy authentication and proxy-proxy/server 8561 authentication in addition to the client-server authentication. 8563 When TLS is applied and a proxy is used, the client will connect to 8564 the proxy's address when connecting to any RTSP server. This implies 8565 that for TLS, the client will authenticate the proxy server and not 8566 the end server. Note that when the client checks the server 8567 certificate in TLS, it MUST check the proxy's identity (URI or 8568 possibly other known identity) against the proxy's identity as 8569 presented in the proxy's Certificate message. 8571 The problem is that for a proxy accepted by the client, the proxy 8572 needs to be provided information on which grounds it should accept 8573 the next-hop certificate. Both the proxy and the user may have rules 8574 for this, and the user should have the possibility to select the 8575 desired behavior. To handle this case, the Accept-Credentials header 8576 (See Section 18.2) is used, where the client can request the proxy/ 8577 proxies to relay back the chain of certificates used to authenticate 8578 any intermediate proxies as well as the server. The assumption that 8579 the proxies are viewed as trusted, gives the user a possibility to 8580 enforce policies to each trusted proxy of whether it should accept 8581 the next agent in the chain. However, it should be noted that not 8582 all deployments will return the chain of certificates used to 8583 authenticate any intermediate proxies as well as the server. An 8584 operator of such a deployment may want to hide its topology from the 8585 client. It should be noted well that the client does not have any 8586 insight into the proxy's operation. Even if the proxy is trusted, it 8587 can still return an incomplete chain of certificates. 8589 A proxy MUST use TLS for the next hop if the RTSP request includes a 8590 "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between 8591 client and proxy, or between proxy and proxy), even if the resource 8592 and the end server are not required to use it. The chain of proxies 8593 used by a client to reach a server and their TLS sessions MUST have 8594 commensurate security. Therefore a proxy MUST, when initiating the 8595 next hop TLS connection, use the incoming TLS connections cipher 8596 suite list, only modified by removing any cipher suites that the 8597 proxy does not support. In case a proxy fails to establish a TLS 8598 connection due to cipher suite mismatch between proxy and next hop 8599 proxy or server, this is indicated using error code 472 (Failure to 8600 establish secure connection). 8602 19.3.1. Accept-Credentials 8604 The Accept-Credentials header can be used by the client to distribute 8605 simple authorization policies to intermediate proxies. The client 8606 includes the Accept-Credentials header to dictate how the proxy 8607 treats the server/next proxy certificate. There are currently three 8608 methods defined: 8610 Any: which means that the proxy (or proxies) MUST accept whatever 8611 certificate is presented. This is of course not a recommended 8612 option to use, but may be useful in certain circumstances (such 8613 as testing). 8615 Proxy: which means that the proxy (or proxies) MUST use its own 8616 policies to validate the certificate and decide whether to 8617 accept it or not. This is convenient in cases where the user 8618 has a strong trust relation with the proxy. Reasons why a 8619 strong trust relation may exist are: personal/company proxy, 8620 proxy has a out-of-band policy configuration mechanism. 8622 User: which means that the proxy (or proxies) MUST send credential 8623 information about the next hop to the client for authorization. 8624 The client can then decide whether the proxy should accept the 8625 certificate or not. See Section 19.3.2 for further details. 8627 If the Accept-Credentials header is not included in the RTSP request 8628 from the client, then the "Proxy" method MUST be used as default. If 8629 another method than the "Proxy" is to be used, then the Accept- 8630 Credentials header MUST be included in all of the RTSP requests from 8631 the client. This is because it cannot be assumed that the proxy 8632 always keeps the TLS state or the user's previous preference between 8633 different RTSP messages (in particular if the time interval between 8634 the messages is long). 8636 With the "Any" and "Proxy" methods the proxy will apply the policy as 8637 defined for each method. If the policy does not accept the 8638 credentials of the next hop, the proxy MUST respond with a message 8639 using status code 471 (Connection Credentials not accepted). 8641 An RTSP request in the direction server to client MUST NOT include 8642 the Accept-Credentials header. As for the non-secured communication, 8643 the possibility for these requests depends on the presence of a 8644 client established connection. However, if the server to client 8645 request is in relation to a session established over a TLS secured 8646 channel, it MUST be sent in a TLS secured connection. That secured 8647 connection MUST also be the one used by the last client to server 8648 request. If no such transport connection exists at the time when the 8649 server desires to send the request, the server MUST discard the 8650 message. 8652 Further policies MAY be defined and registered, but should be done so 8653 with caution. 8655 19.3.2. User approved TLS procedure 8657 For the "User" method, each proxy MUST perform the following 8658 procedure for each RTSP request: 8660 o Setup the TLS session to the next hop if not already present 8661 (i.e., run the TLS handshake, but do not send the RTSP request). 8663 o Extract the peer certificate chain for the TLS session. 8665 o Check if a matching identity and hash of the peer certificate is 8666 present in the Accept-Credentials header. If present, send the 8667 message to the next hop, and conclude these procedures. If not, 8668 go to the next step. 8670 o The proxy responds to the RTSP request with a 470 or 407 response 8671 code. The 407 response code MAY be used when the proxy requires 8672 both user and connection authorization from user or client. In 8673 this message the proxy MUST include a Connection-Credentials 8674 header, see Section 18.13 with the next hop's identity and 8675 certificate. 8677 The client MUST upon receiving a 470 or 407 response with Connection- 8678 Credentials header take the decision on whether to accept the 8679 certificate or not (if it cannot do so, the user SHOULD be 8680 consulted). Using IP addresses in the next hop URI and certificates 8681 rather than domain names makes it very difficult for a user to 8682 determine if it should approve the next hop or not. Proxies are 8683 RECOMMENDED to use domain names to identify themselves in URIs and in 8684 the certificates. If the certificate is accepted, the client has to 8685 again send the RTSP request. In that request the client has to 8686 include the Accept-Credentials header including the hash over the DER 8687 encoded certificate for all trusted proxies in the chain. 8689 Example: 8691 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8692 CSeq: 2 8693 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8694 "192.0.2.5:4589" 8695 Accept-Ranges: npt, smpte, clock 8696 Accept-Credentials: User 8698 P->C: RTSP/2.0 470 Connection Authorization Required 8699 CSeq: 2 8700 Connection-Credentials: "rtsps://test.example.org"; 8701 MIIDNTCCAp... 8703 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8704 CSeq: 3 8705 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8706 "192.0.2.5:4589" 8707 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8708 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8709 Accept-Ranges: npt, smpte, clock 8711 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 8712 CSeq: 3 8713 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 8714 "192.0.2.5:4589" 8715 Via: RTSP/2.0 proxy.example.org 8716 Accept-Credentials: User "rtsps://test.example.org";sha-256; 8717 dPYD7txpoGTbAqZZQJ+vaeOkyH4= 8718 Accept-Ranges: npt, smpte, clock 8720 One implication of this process is that the connection for secured 8721 RTSP messages may take significantly more round-trip times for the 8722 first message. A complete extra message exchange between the proxy 8723 connecting to the next hop and the client results because of the 8724 process for approval for each hop. However, if each message contains 8725 the chain of proxies that the requester accepts, the remaining 8726 message exchange should not be delayed. The procedure of including 8727 the credentials in each request rather than building state in each 8728 proxy, avoids the need for revocation procedures. 8730 20. Syntax 8732 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 8733 as defined in RFC 5234 [RFC5234]. It uses the basic definitions 8734 present in RFC 5234. 8736 Please note that ABNF strings, e.g., "Accept", are case insensitive 8737 as specified in section 2.3 of RFC 5234. 8739 The RTSP syntax makes use of the ISO 10646 character set in UTF-8 8740 encoding RFC 3629 [RFC3629]. 8742 20.1. Base Syntax 8744 RTSP header values can be folded onto multiple lines if the 8745 continuation line begins with a space or horizontal tab. All linear 8746 white space, including folding, has the same semantics as SP. A 8747 recipient MAY replace any linear white space with a single SP before 8748 interpreting the field value or forwarding the message downstream. 8749 This is intended to behave exactly as HTTP/1.1 as described in RFC 8750 2616 [RFC2616]. The SWS construct is used when linear white space is 8751 optional, generally between tokens and separators. 8753 To separate the header name from the rest of value, a colon is used, 8754 which, by the above rule, allows whitespace before, but no line 8755 break, and whitespace after, including a line break. The HCOLON 8756 defines this construct. 8758 OCTET = %x00-FF ; any 8-bit sequence of data 8759 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 8760 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 8761 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 8762 ALPHA = UPALPHA / LOALPHA 8763 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 8764 CTL = %x00-1F / %x7F ; any US-ASCII control character 8765 ; (octets 0 - 31) and DEL (127) 8766 CR = %x0D ; US-ASCII CR, carriage return (13) 8767 LF = %x0A ; US-ASCII LF, linefeed (10) 8768 SP = %x20 ; US-ASCII SP, space (32) 8769 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 8770 BACKSLASH = %x5C ; US-ASCII backslash (92) 8771 CRLF = CR LF 8773 LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space 8774 SWS = [LWS] ; Separating White Space 8775 HCOLON = *( SP / HT ) ":" SWS 8776 TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs 8777 tspecials = "(" / ")" / "<" / ">" / "@" 8778 / "," / ";" / ":" / BACKSLASH / DQUOTE 8779 / "/" / "[" / "]" / "?" / "=" 8780 / "{" / "}" / SP / HT 8781 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 8782 / %x41-5A / %x5E-7A / %x7C / %x7E) 8783 ; 1* 8784 quoted-string = ( DQUOTE *qdtext DQUOTE ) 8785 qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair 8786 / UTF8-NONASCII 8787 ; No DQUOTE and no "\" 8788 quoted-pair = "\\" / ( "\" DQUOTE ) 8789 ctext = %x20-27 / %x2A-7E 8790 / %x80-FF ; any OCTET except CTLs, "(" and ")" 8791 generic-param = token [ EQUAL gen-value ] 8792 gen-value = token / host / quoted-string 8793 safe = "$" / "-" / "_" / "." / "+" 8794 extra = "!" / "*" / "'" / "(" / ")" / "," 8795 rtsp-extra = "!" / "*" / "'" / "(" / ")" 8797 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 8798 / "a" / "b" / "c" / "d" / "e" / "f" 8799 LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 8800 ; lowercase "a-f" Hex 8801 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 8803 unreserved = ALPHA / DIGIT / safe / extra 8804 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 8806 base64 = *base64-unit [base64-pad] 8807 base64-unit = 4base64-char 8808 base64-pad = (2base64-char "==") / (3base64-char "=") 8809 base64-char = ALPHA / DIGIT / "+" / "/" 8811 SLASH = SWS "/" SWS ; slash 8812 EQUAL = SWS "=" SWS ; equal 8813 LPAREN = SWS "(" SWS ; left parenthesis 8814 RPAREN = SWS ")" SWS ; right parenthesis 8815 COMMA = SWS "," SWS ; comma 8816 SEMI = SWS ";" SWS ; semicolon 8817 COLON = SWS ":" SWS ; colon 8818 MINUS = SWS "-" SWS ; minus/dash 8819 LDQUOT = SWS DQUOTE ; open double quotation mark 8820 RDQUOT = DQUOTE SWS ; close double quotation mark 8821 RAQUOT = ">" SWS ; right angle quote 8822 LAQUOT = SWS "<" ; left angle quote 8824 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 8825 UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4 8826 UTF8-1 = 8827 UTF8-2 = 8828 UTF8-3 = 8829 UTF8-4 = 8830 UTF8-tail = 8832 POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] 8833 FLOAT = ["-"] POS-FLOAT 8835 20.2. RTSP Protocol Definition 8836 20.2.1. Generic Protocol elements 8838 RTSP-IRI = schemes ":" IRI-rest 8839 IRI-rest = ihier-part [ "?" iquery ] 8840 ihier-part = "//" iauthority ipath-abempty 8841 RTSP-IRI-ref = RTSP-IRI / irelative-ref 8842 irelative-ref = irelative-part [ "?" iquery ] 8843 irelative-part = "//" iauthority ipath-abempty 8844 / ipath-absolute 8845 / ipath-noscheme 8846 / ipath-empty 8848 iauthority = < As defined in RFC 3987> 8849 ipath = ipath-abempty ; begins with "/" or is empty 8850 / ipath-absolute ; begins with "/" but not "//" 8851 / ipath-noscheme ; begins with a non-colon segment 8852 / ipath-rootless ; begins with a segment 8853 / ipath-empty ; zero characters 8855 ipath-abempty = *( "/" isegment ) 8856 ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] 8857 ipath-noscheme = isegment-nz-nc *( "/" isegment ) 8858 ipath-rootless = isegment-nz *( "/" isegment ) 8859 ipath-empty = 0 8861 isegment = *ipchar [";" *ipchar] 8862 isegment-nz = 1*ipchar [";" *ipchar] 8863 / ";" *ipchar 8864 isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) 8865 / ";" *ipchar-nc 8866 ; non-zero-length segment without any colon ":" 8867 ; No parameter (; delimited) inside path. 8869 ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" 8870 ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" 8871 ; sub-delims is different from RFC 3987 8872 ; not including ";" 8874 iquery = < As defined in RFC 3987> 8875 iunreserved = < As defined in RFC 3987> 8876 pct-encoded = < As defined in RFC 3987> 8877 RTSP-URI = schemes ":" URI-rest 8878 RTSP-REQ-URI = schemes ":" URI-req-rest 8879 RTSP-URI-Ref = RTSP-URI / RTSP-Relative 8880 RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel 8881 schemes = "rtsp" / "rtsps" / scheme 8882 scheme = < As defined in RFC 3986> 8883 URI-rest = hier-part [ "?" query ] 8884 URI-req-rest = hier-part [ "?" query ] 8885 ; Note fragment part not allowed in requests 8886 hier-part = "//" authority path-abempty 8888 RTSP-Relative = relative-part [ "?" query ] 8889 RTSP-REQ-Rel = relative-part [ "?" query ] 8890 relative-part = "//" authority path-abempty 8891 / path-absolute 8892 / path-noscheme 8893 / path-empty 8895 authority = < As defined in RFC 3986> 8896 query = < As defined in RFC 3986> 8898 path = path-abempty ; begins with "/" or is empty 8899 / path-absolute ; begins with "/" but not "//" 8900 / path-noscheme ; begins with a non-colon segment 8901 / path-rootless ; begins with a segment 8902 / path-empty ; zero characters 8904 path-abempty = *( "/" segment ) 8905 path-absolute = "/" [ segment-nz *( "/" segment ) ] 8906 path-noscheme = segment-nz-nc *( "/" segment ) 8907 path-rootless = segment-nz *( "/" segment ) 8908 path-empty = 0 8910 segment = *pchar [";" *pchar] 8911 segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) 8912 segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) 8913 ; non-zero-length segment without any colon ":" 8914 ; No parameter (; delimited) inside path. 8916 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 8917 pchar-nc = unreserved / pct-encoded / sub-delims / "@" 8919 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 8920 / "*" / "+" / "," / "=" 8921 ; sub-delims is different from RFC 3986/3987 8922 ; not including ";" 8924 smpte-range = smpte-type [EQUAL smpte-range-spec] 8925 ; See section 4.4 8926 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 8927 / ( "-" smpte-time ) 8928 smpte-type = "smpte" / "smpte-30-drop" 8929 / "smpte-25" / smpte-type-extension 8930 ; other timecodes may be added 8931 smpte-type-extension = "smpte" token 8932 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 8933 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 8935 npt-range = "npt" [EQUAL npt-range-spec] 8936 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 8937 npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp 8938 npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] 8939 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] 8940 npt-hh = 2*19DIGIT ; any positive number 8941 npt-mm = 2*2DIGIT ; 0-59 8942 npt-ss = 2*2DIGIT ; 0-59 8943 npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp 8944 [ "." 1*9DIGIT ] # Compatibility format 8945 npt-hh-comp = 1*19DIGIT ; any positive number 8946 npt-mm-comp = 1*2DIGIT ; 0-59 8947 npt-ss-comp = 1*2DIGIT ; 0-59 8949 utc-range = "clock" [EQUAL utc-range-spec] 8950 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 8951 utc-time = utc-date "T" utc-clock "Z" 8952 utc-date = 8DIGIT 8953 utc-clock = 6DIGIT [ "." 1*9DIGIT ] 8955 feature-tag = token 8957 session-id = 1*256( ALPHA / DIGIT / safe ) 8959 extension-header = header-name HCOLON header-value 8960 header-name = token 8961 header-value = *(TEXT-UTF8char / LWS) 8963 20.2.2. Message Syntax 8964 RTSP-message = Request / Response ; RTSP/2.0 messages 8966 Request = Request-Line 8967 *((general-header 8968 / request-header 8969 / message-body-header) CRLF) 8970 CRLF 8971 [ message-body-data ] 8973 Response = Status-Line 8974 *((general-header 8975 / response-header 8976 / message-body-header) CRLF) 8977 CRLF 8978 [ message-body-data ] 8980 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 8982 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 8984 Method = "DESCRIBE" 8985 / "GET_PARAMETER" 8986 / "OPTIONS" 8987 / "PAUSE" 8988 / "PLAY" 8989 / "PLAY_NOTIFY" 8990 / "REDIRECT" 8991 / "SETUP" 8992 / "SET_PARAMETER" 8993 / "TEARDOWN" 8994 / extension-method 8996 extension-method = token 8998 Request-URI = "*" / RTSP-REQ-URI 8999 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 9001 message-body-data = 1*OCTET 9003 Status-Code = "100" ; Continue 9004 / "200" ; OK 9005 / "301" ; Moved Permanently 9006 / "302" ; Found 9007 / "303" ; See Other 9008 / "304" ; Not Modified 9009 / "305" ; Use Proxy 9010 / "400" ; Bad Request 9011 / "401" ; Unauthorized 9012 / "402" ; Payment Required 9013 / "403" ; Forbidden 9014 / "404" ; Not Found 9015 / "405" ; Method Not Allowed 9016 / "406" ; Not Acceptable 9017 / "407" ; Proxy Authentication Required 9018 / "408" ; Request Time-out 9019 / "410" ; Gone 9020 / "412" ; Precondition Failed 9021 / "413" ; Request Message Body Too Large 9022 / "414" ; Request-URI Too Large 9023 / "415" ; Unsupported Media Type 9024 / "451" ; Parameter Not Understood 9025 / "452" ; reserved 9026 / "453" ; Not Enough Bandwidth 9027 / "454" ; Session Not Found 9028 / "455" ; Method Not Valid in This State 9029 / "456" ; Header Field Not Valid for Resource 9030 / "457" ; Invalid Range 9031 / "458" ; Parameter Is Read-Only 9032 / "459" ; Aggregate operation not allowed 9033 / "460" ; Only aggregate operation allowed 9034 / "461" ; Unsupported Transport 9035 / "462" ; Destination Unreachable 9036 / "463" ; Destination Prohibited 9037 / "464" ; Data Transport Not Ready Yet 9038 / "465" ; Notification Reason Unknown 9039 / "466" ; Key Management Error 9040 / "470" ; Connection Authorization Required 9041 / "471" ; Connection Credentials not accepted 9042 / "472" ; Failure to establish secure connection 9043 / "500" ; Internal Server Error 9044 / "501" ; Not Implemented 9045 / "502" ; Bad Gateway 9046 / "503" ; Service Unavailable 9047 / "504" ; Gateway Time-out 9048 / "505" ; RTSP Version not supported 9049 / "551" ; Option not supported 9050 / extension-code 9052 extension-code = 3DIGIT 9054 Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) 9055 rtsp-header = general-header 9056 / request-header 9057 / response-header 9058 / message-body-header 9060 general-header = Accept-Ranges 9061 / Cache-Control 9062 / Connection 9063 / CSeq 9064 / Date 9065 / Media-Properties 9066 / Media-Range 9067 / Pipelined-Requests 9068 / Proxy-Supported 9069 / Range 9070 / RTP-Info 9071 / Scale 9072 / Seek-Style 9073 / Server 9074 / Session 9075 / Speed 9076 / Supported 9077 / Timestamp 9078 / Transport 9079 / User-Agent 9080 / Via 9081 / extension-header 9083 request-header = Accept 9084 / Accept-Credentials 9085 / Accept-Encoding 9086 / Accept-Language 9087 / Authorization 9088 / Bandwidth 9089 / Blocksize 9090 / From 9091 / If-Match 9092 / If-Modified-Since 9093 / If-None-Match 9094 / Notify-Reason 9095 / Proxy-Authorization 9096 / Proxy-Require 9097 / Referrer 9098 / Request-Status 9099 / Require 9100 / Terminate-Reason 9101 / extension-header 9103 response-header = Authentication-Info 9104 / Connection-Credentials 9105 / Location 9106 / MTag 9107 / Proxy-Authenticate 9108 / Proxy-Authentication-Info 9109 / Public 9110 / Retry-After 9111 / Unsupported 9112 / WWW-Authenticate 9113 / extension-header 9115 message-body-header = Allow 9116 / Content-Base 9117 / Content-Encoding 9118 / Content-Language 9119 / Content-Length 9120 / Content-Location 9121 / Content-Type 9122 / Expires 9123 / Last-Modified 9124 / extension-header 9126 20.2.3. Header Syntax 9128 Accept = "Accept" HCOLON 9129 [ accept-range *(COMMA accept-range) ] 9130 accept-range = media-type-range [SEMI accept-params] 9131 media-type-range = ( "*/*" 9132 / ( m-type SLASH "*" ) 9133 / ( m-type SLASH m-subtype ) 9134 ) *( SEMI m-parameter ) 9135 accept-params = "q" EQUAL qvalue *(SEMI generic-param ) 9136 qvalue = ( "0" [ "." *3DIGIT ] ) 9137 / ( "1" [ "." *3("0") ] ) 9138 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision 9139 cred-decision = ("User" [LWS cred-info]) 9140 / "Proxy" 9141 / "Any" 9142 / (token [LWS 1*header-value]) 9143 ; For future extensions 9144 cred-info = cred-info-data *(COMMA cred-info-data) 9146 cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg 9147 SEMI base64 9148 hash-alg = "sha-256" / extension-alg 9149 extension-alg = token 9150 Accept-Encoding = "Accept-Encoding" HCOLON 9152 [ encoding *(COMMA encoding) ] 9153 encoding = codings [SEMI accept-params] 9154 codings = content-coding / "*" 9155 content-coding = "identity" / token 9156 Accept-Language = "Accept-Language" HCOLON 9157 language *(COMMA language) 9158 language = language-range [SEMI accept-params] 9159 language-range = language-tag / "*" 9160 language-tag = primary-tag *( "-" subtag ) 9161 primary-tag = 1*8ALPHA 9162 subtag = 1*8ALPHA 9163 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges 9164 acceptable-ranges = (range-unit *(COMMA range-unit)) 9165 range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25" 9166 / "clock" / extension-format 9167 extension-format = token 9168 Allow = "Allow" HCOLON Method *(COMMA Method) 9169 Authentication-Info = "Authentication-Info" HCOLON auth-info 9170 auth-info = auth-info-entry *(COMMA auth-info-entry) 9171 auth-info-entry = nextnonce 9172 / message-qop 9173 / response-auth 9174 / cnonce 9175 / nonce-count 9176 nextnonce = "nextnonce" EQUAL nonce-value 9177 response-auth = "rspauth" EQUAL response-digest 9178 response-digest = DQUOTE *LHEX DQUOTE 9179 Authorization = "Authorization" HCOLON credentials 9180 credentials = basic-credential 9181 / digest-credential 9182 / other-response 9183 basic-credential = "Basic" LWS basic-credentials 9184 basic-credentials = base64 ; Base64 encoding of user-password 9185 user-password = basic-username ":" password 9186 basic-username = *CF-TEXT 9187 CF-TEXT = %x20-39 / %x3B-7E / %x80-FF ; TEXT without : 9188 password = *TEXT 9189 digest-credential = ("Digest" LWS digest-response) 9190 digest-response = dig-resp *(COMMA dig-resp) 9191 dig-resp = username / realm / nonce / digest-uri 9192 / dresponse / algorithm / cnonce 9193 / opaque / message-qop 9194 / nonce-count / auth-param 9195 username = "username" EQUAL username-value 9196 username-value = quoted-string 9197 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 9198 digest-uri-value = RTSP-REQ-URI 9199 message-qop = "qop" EQUAL qop-value 9200 cnonce = "cnonce" EQUAL cnonce-value 9201 cnonce-value = nonce-value 9202 nonce-count = "nc" EQUAL nc-value 9203 nc-value = 8LHEX 9204 dresponse = "response" EQUAL request-digest 9205 request-digest = LDQUOT 32LHEX RDQUOT 9206 auth-param = auth-param-name EQUAL 9207 ( token / quoted-string ) 9208 auth-param-name = token 9209 other-response = auth-scheme LWS auth-param 9210 *(COMMA auth-param) 9211 auth-scheme = token 9213 Bandwidth = "Bandwidth" HCOLON 1*19DIGIT 9215 Blocksize = "Blocksize" HCOLON 1*9DIGIT 9217 Cache-Control = "Cache-Control" HCOLON cache-directive 9218 *(COMMA cache-directive) 9219 cache-directive = cache-rqst-directive 9220 / cache-rspns-directive 9222 cache-rqst-directive = "no-cache" 9223 / "max-stale" [EQUAL delta-seconds] 9224 / "min-fresh" EQUAL delta-seconds 9225 / "only-if-cached" 9226 / cache-extension 9228 cache-rspns-directive = "public" 9229 / "private" 9230 / "no-cache" 9231 / "no-transform" 9232 / "must-revalidate" 9233 / "proxy-revalidate" 9234 / "max-age" EQUAL delta-seconds 9235 / cache-extension 9237 cache-extension = token [EQUAL (token / quoted-string)] 9238 delta-seconds = 1*19DIGIT 9240 Connection = "Connection" HCOLON connection-token 9241 *(COMMA connection-token) 9242 connection-token = "close" / token 9244 Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 9245 cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64 9247 Content-Base = "Content-Base" HCOLON RTSP-URI 9248 Content-Encoding = "Content-Encoding" HCOLON 9249 content-coding *(COMMA content-coding) 9250 Content-Language = "Content-Language" HCOLON 9251 language-tag *(COMMA language-tag) 9252 Content-Length = "Content-Length" HCOLON 1*19DIGIT 9253 Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref 9254 Content-Type = "Content-Type" HCOLON media-type 9255 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 9256 m-type = discrete-type / composite-type 9257 discrete-type = "text" / "image" / "audio" / "video" 9258 / "application" / extension-token 9259 composite-type = "message" / "multipart" / extension-token 9260 extension-token = ietf-token / x-token 9261 ietf-token = token 9262 x-token = "x-" token 9263 m-subtype = extension-token / iana-token 9264 iana-token = token 9265 m-parameter = m-attribute EQUAL m-value 9266 m-attribute = token 9267 m-value = token / quoted-string 9269 CSeq = "CSeq" HCOLON cseq-nr 9270 cseq-nr = 1*9DIGIT 9271 Date = "Date" HCOLON RTSP-date 9272 RTSP-date = date-time ; 9273 date-time = 9274 Expires = "Expires" HCOLON RTSP-date 9275 From = "From" HCOLON from-spec 9276 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 9277 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 9278 addr-spec = RTSP-REQ-URI / absolute-URI 9279 absolute-URI = < As defined in RFC 3986> 9280 display-name = *(token LWS) / quoted-string 9281 from-param = tag-param / generic-param 9282 tag-param = "tag" EQUAL token 9283 If-Match = "If-Match" HCOLON ("*" / message-tag-list) 9284 message-tag-list = message-tag *(COMMA message-tag) 9285 message-tag = [ weak ] opaque-tag 9286 weak = "W/" 9287 opaque-tag = quoted-string 9288 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 9289 If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list) 9290 Last-Modified = "Last-Modified" HCOLON RTSP-date 9291 Location = "Location" HCOLON RTSP-REQ-URI 9292 Media-Properties = "Media-Properties" HCOLON [media-prop-list] 9293 media-prop-list = media-prop-value *(COMMA media-prop-value) 9294 media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) 9295 / "Beginning-Only" 9296 / "No-Seeking" 9297 / "Immutable" 9298 / "Dynamic" 9299 / "Time-Progressing" 9300 / "Unlimited" 9301 / ("Time-Limited" EQUAL utc-time) 9302 / ("Time-Duration" EQUAL POS-FLOAT) 9303 / ("Scales" EQUAL scale-value-list) 9304 / media-prop-ext 9305 media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] 9306 scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE 9307 scale-entry = scale-value / (scale-value COLON scale-value) 9308 scale-value = FLOAT 9309 Media-Range = "Media-Range" HCOLON [ranges-list] 9310 ranges-list = ranges-spec *(COMMA ranges-spec) 9311 MTag = "MTag" HCOLON message-tag 9312 Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val 9313 Notify-Reas-val = "end-of-stream" 9314 / "media-properties-update" 9315 / "scale-change" 9316 / Notify-Reason-extension 9317 Notify-Reason-extension = token 9318 Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id 9319 startup-id = 1*8DIGIT 9321 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list 9322 challenge-list = challenge *(COMMA challenge) 9323 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 9324 / ("Basic" LWS realm) 9325 / other-challenge 9326 other-challenge = auth-scheme LWS auth-param 9327 *(COMMA auth-param) 9328 digest-cln = realm / domain / nonce 9329 / opaque / stale / algorithm 9330 / qop-options / auth-param 9331 realm = "realm" EQUAL realm-value 9332 realm-value = quoted-string 9333 domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref 9334 *(1*SP RTSP-REQ-Ref ) RDQUOT 9335 nonce = "nonce" EQUAL nonce-value 9336 nonce-value = quoted-string 9337 opaque = "opaque" EQUAL quoted-string 9338 stale = "stale" EQUAL ( "true" / "false" ) 9339 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 9340 qop-options = "qop" EQUAL LDQUOT qop-value 9341 *("," qop-value) RDQUOT 9342 qop-value = "auth" / "auth-int" / token 9343 Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON auth-info 9344 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials 9345 Proxy-Require = "Proxy-Require" HCOLON feature-tag-list 9346 feature-tag-list = feature-tag *(COMMA feature-tag) 9347 Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] 9349 Public = "Public" HCOLON Method *(COMMA Method) 9351 Range = "Range" HCOLON ranges-spec 9353 ranges-spec = npt-range / utc-range / smpte-range 9354 / range-ext 9355 range-ext = extension-format [EQUAL range-value] 9356 range-value = 1*(rtsp-unreserved / quoted-string / ":" ) 9358 Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) 9359 Request-Status = "Request-Status" HCOLON req-status-info 9360 req-status-info = cseq-info LWS status-info LWS reason-info 9361 cseq-info = "cseq" EQUAL cseq-nr 9362 status-info = "status" EQUAL Status-Code 9363 reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE 9364 Require = "Require" HCOLON feature-tag-list 9365 RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec 9366 *(COMMA rtsp-info-spec)] 9367 rtsp-info-spec = stream-url 1*ssrc-parameter 9368 stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE 9369 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 9370 ri-parameter *(SEMI ri-parameter) 9371 ri-parameter = ("seq" EQUAL 1*5DIGIT) 9372 / ("rtptime" EQUAL 1*10DIGIT) 9373 / generic-param 9375 Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds) 9376 Scale = "Scale" HCOLON scale-value 9377 Seek-Style = "Seek-Style" HCOLON Seek-S-values 9378 Seek-S-values = "RAP" 9379 / "CoRAP" 9380 / "First-Prior" 9381 / "Next" 9382 / Seek-S-value-ext 9383 Seek-S-value-ext = token 9385 Server = "Server" HCOLON ( product / comment ) 9386 *(LWS (product / comment)) 9387 product = token [SLASH product-version] 9388 product-version = token 9389 comment = LPAREN *( ctext / quoted-pair) RPAREN 9391 Session = "Session" HCOLON session-id 9392 [ SEMI "timeout" EQUAL delta-seconds ] 9394 Speed = "Speed" HCOLON lower-bound MINUS upper-bound 9395 lower-bound = POS-FLOAT 9396 upper-bound = POS-FLOAT 9398 Supported = "Supported" HCOLON [feature-tag-list] 9399 Terminate-Reason = "Terminate-Reason" HCOLON TR-Info 9400 TR-Info = TR-Reason *(SEMI TR-Parameter) 9401 TR-Reason = "Session-Timeout" 9402 / "Server-Admin" 9403 / "Internal-Error" 9404 / token 9405 TR-Parameter = TR-time / TR-user-msg / generic-param 9406 TR-time = "time" EQUAL utc-time 9407 TR-user-msg = "user-msg" EQUAL quoted-string 9409 Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay] 9410 timestamp-value = *19DIGIT [ "." *9DIGIT ] 9411 delay = *9DIGIT [ "." *9DIGIT ] 9413 Transport = "Transport" HCOLON transport-spec 9414 *(COMMA transport-spec) 9415 transport-spec = transport-id *trns-parameter 9416 transport-id = trans-id-rtp / other-trans 9417 trans-id-rtp = "RTP/" profile ["/" lower-transport] 9418 ; no LWS is allowed inside transport-id 9419 other-trans = token *("/" token) 9420 profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token 9421 lower-transport = "TCP" / "UDP" / token 9422 trns-parameter = (SEMI ( "unicast" / "multicast" )) 9423 / (SEMI "interleaved" EQUAL channel ["-" channel]) 9424 / (SEMI "ttl" EQUAL ttl) 9425 / (SEMI "layers" EQUAL 1*DIGIT) 9426 / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) 9427 / (SEMI "mode" EQUAL mode-spec) 9428 / (SEMI "dest_addr" EQUAL addr-list) 9429 / (SEMI "src_addr" EQUAL addr-list) 9430 / (SEMI "setup" EQUAL contrans-setup) 9431 / (SEMI "connection" EQUAL contrans-con) 9432 / (SEMI "RTCP-mux") 9433 / (SEMI "MIKEY" EQUAL MIKEY-Value) 9434 / (SEMI trn-param-ext) 9435 contrans-setup = "active" / "passive" / "actpass" 9436 contrans-con = "new" / "existing" 9437 trn-param-ext = par-name [EQUAL trn-par-value] 9438 par-name = token 9439 trn-par-value = *(rtsp-unreserved / quoted-string) 9440 ttl = 1*3DIGIT ; 0 to 255 9441 ssrc = 8HEX 9442 channel = 1*3DIGIT ; 0 to 255 9443 MIKEY-Value = base64 9444 mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) 9445 mode = "PLAY" / token 9446 addr-list = quoted-addr *(SLASH quoted-addr) 9447 quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE 9448 host-port = ( host [":" port] ) 9449 / ( ":" port ) 9450 extension-addr = 1*qdtext 9451 host = < As defined in RFC 3986> 9452 port = < As defined in RFC 3986> 9453 Unsupported = "Unsupported" HCOLON feature-tag-list 9454 User-Agent = "User-Agent" HCOLON ( product / comment ) 9455 *(LWS (product / comment)) 9456 Via = "Via" HCOLON via-parm *(COMMA via-parm) 9457 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 9458 via-params = via-ttl / via-maddr 9459 / via-received / via-extension 9460 via-ttl = "ttl" EQUAL ttl 9461 via-maddr = "maddr" EQUAL host 9462 via-received = "received" EQUAL (IPv4address / IPv6address) 9463 IPv4address = < As defined in RFC 3986> 9464 IPv6address = < As defined in RFC 3986> 9465 via-extension = generic-param 9466 sent-protocol = protocol-name SLASH protocol-version 9467 SLASH transport-prot 9468 protocol-name = "RTSP" / token 9469 protocol-version = token 9470 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 9471 other-transport = token 9472 sent-by = host [ COLON port ] 9474 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list 9476 20.3. SDP extension Syntax 9478 This section defines in ABNF the SDP extensions defined for RTSP. 9479 See Appendix D for the definition of the extensions in text. 9481 control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF 9483 a-range-def = "a=range:" ranges-spec CRLF 9485 a-mtag-def = "a=mtag:" message-tag CRLF 9487 21. Security Considerations 9489 The security considerations and threats around RTSP and its usage can 9490 be divided into considerations around the signaling protocol itself 9491 and the issues related to the media stream delivery. However, when 9492 it comes to mitigations of security threats, a threat depending on 9493 the media stream delivery may in fact be mitigated by a mechanism in 9494 the signaling protocol. 9496 There are several chapters and an appendix in this document that 9497 define security solutions for the protocol. These sections will be 9498 referenced when discussing the threats below. But the reader should 9499 take special notice of the Security Framework (Section 19) and the 9500 specification of how to use SRTP and its key-mangement 9501 (Appendix C.1.4) to achieve certain aspects of the media security. 9503 21.1. Signaling Protocol Threats 9505 This section focuses on issues related to the signaling protocol. 9506 Because of the similarity in syntax and usage between RTSP servers 9507 and HTTP servers, the security considerations outlined in [H15] apply 9508 also. 9510 Specifically, please note the following: 9512 Abuse of Server Log Information: A server is in the position to save 9513 personal data about a user's requests which might identify 9514 their media consumption patterns or subjects of interest. This 9515 information is clearly confidential in nature and its handling 9516 can be constrained by law in certain countries. RTSP servers 9517 will presumably have similar logging mechanisms to HTTP, and 9518 thus should be equally guarded in protecting the contents of 9519 those logs, thus protecting the privacy of the users of the 9520 servers. People using the RTSP protocol to provide media are 9521 responsible for ensuring that logging material is not 9522 distributed without the permission of any individuals that are 9523 identifiable by the published results. 9525 Transfer of Sensitive Information: There is no reason to believe 9526 that information transferred in RTSP message, such as the URI 9527 and the content of headers, especially the Server, Via, 9528 Referrer and From headers, may be any less sensitive than when 9529 used in HTTP. Therefore, all of the precautions regarding the 9530 protection of data privacy and user privacy apply to 9531 implementors of RTSP clients, servers, and proxies. See 9532 [H15.1.2] for further details. 9534 The RTSP methods defined in this document is primarily used to 9535 establish and control the delivery of the media data 9536 represented by the URI, thus the RTSP message bodies are 9537 generally less sensitive than the ones in HTTP. Where HTTP 9538 bodies could contain for example your medical records, in RTSP 9539 the sensitive video of your medical operation would be in the 9540 media stream over the media transport protocol, not in the RTSP 9541 message. Still one have to take note of what potential 9542 sensitive informative are included in the RTSP protocol. The 9543 protection of the media data is separate, can be applied 9544 directly between client and server, and is dependent on the 9545 media transport protocol in use. See Section 21.2 for further 9546 discussion. This possibility for separation of security 9547 between media resource content and the signalling protocol 9548 mitigates the risk of exposing the media content when using 9549 hop-by-hop security for RTSP signaling using proxies 9550 (Section 19.3). 9552 Attacks Based On File and Path Names: Though RTSP URIs are opaque 9553 handles that do not necessarily have file system semantics, it 9554 is anticipated that many implementations will translate 9555 portions of the Request-URIs directly to file system calls. In 9556 such cases, file systems SHOULD follow the precautions outlined 9557 in [H15.2], such as checking for ".." in path components. 9559 Personal Information: RTSP clients are often privy to the same 9560 information that HTTP clients are (user name, location, etc.) 9561 and thus should be equally sensitive. See [H15.1] for further 9562 recommendations. 9564 Privacy Issues Connected to Accept Headers: Since similar usages of 9565 the "Accept" headers exist in RTSP as in HTTP, the same caveats 9566 outlined in [H15.1.4] with regards to their use should be 9567 followed. 9569 DNS Spoofing: Presumably, given the longer connection times 9570 typically associated to RTSP sessions relative to HTTP 9571 sessions, RTSP client DNS optimizations should be less 9572 prevalent. Nonetheless, the recommendations provided in 9573 [H15.3] are still relevant to any implementation which attempts 9574 to rely on a DNS-to-IP mapping to hold beyond a single use of 9575 the mapping. 9577 Location Headers and Spoofing: If a single server supports multiple 9578 organizations that do not trust each another, then it MUST 9579 check the values of the Content-Location header fields in 9580 responses that are generated under control of said 9581 organizations to make sure that they do not attempt to 9582 invalidate resources over which they have no authority. 9583 ([H15.4]) 9585 In addition to the recommendations in the current HTTP specification 9586 (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 9587 2068 [RFC2068], future HTTP specifications may provide additional 9588 guidance on security issues. 9590 The following are added considerations for RTSP implementations. 9592 Session hijacking: Since there is no or little relation between a 9593 transport layer connection and an RTSP session, it is possible 9594 for a malicious client to issue requests with random session 9595 identifiers which could affect other clients of an unsuspecting 9596 server. To mitigate this the server SHALL use a large, random 9597 and non-sequential session identifier to minimize the 9598 possibility of this kind of attack. However, unless the RTSP 9599 signaling is always confidentiality protected, e.g., using TLS, 9600 an on-path attacker will be able to hijack a session. Another 9601 choice for preventing session hijacking is to use client 9602 authentication and only allow the authenticated client creating 9603 the session to access that session. 9605 Authentication: Servers SHOULD implement both basic and digest 9606 [RFC2617] authentication. In environments requiring tighter 9607 security for the control messages, the transport layer 9608 mechanism TLS [RFC5246] SHOULD be used. 9610 Suspicious behavior: RTSP servers upon detecting instances of 9611 behavior which is deemed a security risk SHOULD return error 9612 code 403 (Forbidden). RTSP servers SHOULD also be aware of 9613 attempts to probe the server for weaknesses and entry points 9614 and MAY arbitrarily disconnect and ignore further requests from 9615 clients which are deemed to be in violation of local security 9616 policy. 9618 TLS through proxies: If one uses the possibility to connect TLS in 9619 multiple legs (Section 19.3) one really needs to be aware of 9620 the trust model. That procedure requires full faith and trust 9621 in all proxies, which will be identified, that one allows to 9622 connect through. They are men in the middle and have access to 9623 all that goes on over the TLS connection. Thus it is important 9624 to consider if that trust model is acceptable in the actual 9625 application. Further discussion of the actual trust model is 9626 in Section 19.3. It is important to note what difference in 9627 security properties, if any, that may exist with the used media 9628 transport protocol and its security mechanism. Using SRTP and 9629 the MIKEY based key-establishment defined in Appendix C.1.4.1, 9630 enables to media key-establishment to done end-to-end without 9631 revealing the keys to the proxies. 9633 Resource Exhaustion: As RTSP is a stateful protocol and establishes 9634 resource usage on the server there is a clear possibility to 9635 attack the server by trying to overbook these resources to 9636 perform a denial of service attack. This attack can be both 9637 against ongoing sessions and to prevent others from 9638 establishing sessions. RTSP agents will need to have 9639 mechanisms to prevent single peers from consuming extensive 9640 amounts of resources. The methods for guarding against this 9641 are varied and depends on the agent's role and capabilities and 9642 policies. Each implementation has to carefully consider their 9643 methods and policies to mitigate this threat. For example 9644 regarding handling of connections there are recommendations in 9645 Section 10.7. 9647 The above threats and considerations have resulted in a set of 9648 security functions and mechanisms built into or used by the protocol. 9649 The signaling protocol relies on two security features defined in the 9650 Security Framework (Section 19) namely client authentication using 9651 HTTP authentication and TLS based transport protection of the 9652 signaling messages. Both of these mechanisms are required to be 9653 implemented by any RTSP agent. 9655 A number of different security mitigations have been designed into 9656 the protocol and will be instantiated if the specification is 9657 implemented as written, for example by ensuring sufficient amount of 9658 entropy in the randomly generated session identifiers when not using 9659 client authentication to minimize the risk of session hijacking. 9660 When client authentication is used the protection against hijacking 9661 will be greatly improved by scoping the accessible sessions to the 9662 one this client identity has created. Some of the above threats are 9663 such that the implementation of the RTSP functionality itself needs 9664 to consider which policy and strategy it uses to mitigate them. 9666 21.2. Media Stream Delivery Threats 9668 The fact that RTSP establishes and controls a media stream delivery 9669 results in a set of security issues related to the media streams. 9670 This section will attempt to analyze general threats, however the 9671 choice of media stream transport protocol, such as RTP will result in 9672 some differences in threats and what mechanisms exist to mitigate 9673 them. Thus it becomes important that each specification of a new 9674 media stream transport and delivery protocol usable by RTSP requires 9675 its own security analysis. This section includes one for RTP. 9677 The set of general threats from or by the media stream delivery 9678 itself are: 9680 Concentrated denial-of-service attack: The protocol offers the 9681 opportunity for a remote-controlled denial-of-service (DoS) 9682 attack, where the media stream is the hammer in that DoS attack. 9683 See Section 21.2.1. 9685 Media Confidentiality: The media delivery may contain content of any 9686 type and it is not possible in general to determine how sensitive 9687 this content is from a confidentiality point. Thus it is a strong 9688 requirement that any media delivery protocol provides a method for 9689 providing confidentiality of the actual media content. In 9690 addition to the media level confidentiality it becomes critical 9691 that no resource identifiers used in the signaling are exposed to 9692 an attacker as they may have human understandable names, or may be 9693 also available to the attacker so they can determine the content 9694 the user was delivered. Thus the signaling protocol must also 9695 provide confidentiality protection of any information related to 9696 the media resource. 9698 Media Integrity and Authentication: There are several reasons, such 9699 as discrediting the target, misinformation of the target, why an 9700 attacker will be interested in substituting the media stream sent 9701 out from the RTSP server with one of the attacker's creation or 9702 selection. Therefore it is important that the media protocol 9703 provides mechanisms to verify the source authentication, integrity 9704 and prevent replay attacks on the media stream. 9706 Scope of Multicast: If RTSP is used to control the transmission of 9707 media onto a multicast network the scope of the delivery must be 9708 considered. RTSP supports the TTL Transport header parameter to 9709 indicate this scope for IPv4. IPv6 has a different mechanism for 9710 scope boundary. However, such scope control has risks, as it may 9711 be set too large and distribute media beyond the intended scope. 9713 Below (Section 21.2.2) a protocol specific analysis of security 9714 considerations for RTP based media transport is done. In that 9715 section it is also made clear the requirements on implementing 9716 security functions for RTSP agents supporting media delivery over 9717 RTP. 9719 21.2.1. Remote Denial of Service Attack 9721 The attacker may initiate traffic flows to one or more IP addresses 9722 by specifying them as the destination in SETUP requests. While the 9723 attacker's IP address may be known in this case, this is not always 9724 useful in prevention of more attacks or ascertaining the attacker's 9725 identity. Thus, an RTSP server MUST only allow client-specified 9726 destinations for RTSP-initiated traffic flows if the server has 9727 ensured that the specified destination address accepts receiving 9728 media through different security mechanisms. Security mechanisms 9729 that are acceptable in order of increasing generality are: 9731 o Verification of the client's identity against a database of known 9732 users using RTSP authentication mechanisms (preferably digest 9733 authentication or stronger) 9735 o A list of addresses that have consented to be media destinations, 9736 especially considering user identity 9738 o Media path based verification 9739 The server SHOULD NOT allow the destination field to be set unless a 9740 mechanism exists in the system to authorize the request originator to 9741 direct streams to the recipient. It is preferred that this 9742 authorization be performed by the media recipient (destination) 9743 itself and the credentials passed along to the server. However, in 9744 certain cases, such as when the recipient address is a multicast 9745 group, or when the recipient is unable to communicate with the server 9746 in an out-of-band manner, this may not be possible. In these cases 9747 the server may chose another method such as a server-resident 9748 authorization list to ensure that the request originator has the 9749 proper credentials to request stream delivery to the recipient. 9751 One solution that performs the necessary verification of acceptance 9752 of media suitable for unicast based delivery is the Interactive 9753 Connectivity Establishment (ICE) [RFC5245] based NAT traversal method 9754 described in [I-D.ietf-mmusic-rtsp-nat]. This mechanism uses random 9755 passwords and a username so that the probability of unintended 9756 indication as a valid media destination is very low. In addition the 9757 server includes in its Session Traversal Utilities for NAT (STUN) 9758 [RFC5389] requests a cookie (consisting of random material) that the 9759 destination echoes back, thus the solution also safe-guards against 9760 having an off-path attacker being able to spoof the STUN checks. 9761 This leaves this solution vulnerable only to on-path attackers that 9762 can see the STUN requests go to the target of attack and thus forge a 9763 response. 9765 For delivery to multicast addresses there is a need for another 9766 solution which is not specified in this memo. 9768 21.2.2. RTP Security analysis 9770 RTP is a commonly used media transport protocol and has been the most 9771 common choice for RTSP 1.0 implementations. The core RTP protocol 9772 has been in use for a long time and it has well-known security 9773 properties and the RTP security consideration (Section 9 of 9774 [RFC3550]) needs to be reviewed. In perspective of the usage of RTP 9775 in context of RTSP the following properties should be noted: 9777 Stream Additions: RTP has support for multiple simultaneous media 9778 streams in each RTP session. As some use cases require support 9779 for non-synchronized adding and removal of media streams and their 9780 identifiers an attacker can easily insert additional media streams 9781 into a session context that according to protocol design is 9782 intended to be played out. Another threat vector is one of denial 9783 of service by exhausting the resources of the RTP session 9784 receiver, for example by using a large number of SSRC identifiers 9785 simultaneously. The strong mitigation of this is to ensure that 9786 one cryptographically authenticates any incoming packet flow to 9787 the RTP session. Weak mitigations like blocking additional media 9788 streams in session contexts easily lead to a denial of service 9789 vulnerability in addition to preventing certain RTP extensions or 9790 use cases which rely on multiple media streams, such as RTP 9791 retransmission [RFC4588] to function. 9793 Forged Feedback: The built in RTP control Protocol (RTCP) also 9794 offers a large attack surface for a couple of different types of 9795 attacks. One venue is to send RTCP feedback to the media sender 9796 indicating large amounts of packet loss and thus trigger a media 9797 bit-rate adaptation response from the sender resulting in lowered 9798 media quality and potentially shut down of the media stream. 9799 Another attack is to perform a resource exhaustion attack on the 9800 receiver by using many SSRC identifiers to create large state 9801 tables and increase the RTCP related processing demands. 9803 RTP/RTCP Extensions: RTP and RTCP extensions generally provide 9804 additional and sometimes extremely powerful tools to do denial of 9805 service or service disruption. For example the Code Control 9806 Message [RFC5104] RTCP extensions enables both locking down the 9807 bit-rate to low values and disruption of video quality by 9808 requesting Intra frames. 9810 Taking into account the above general discussion in Section 21.2 and 9811 the RTP specific discussion in this section it is clear that it is 9812 necessary that a strong security mechanism is supported to protect 9813 RTP. Therefore this specification has the following requirements on 9814 RTP security functions for all RTSP agents that handles media streams 9815 and where the media stream transport is done using RTP. 9817 RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] 9818 and thus the SAVP profile. In addition the secure AVP profile 9819 (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is 9820 implemented. This specification requires no additional cryptographic 9821 transforms or configuration values beyond those specified as 9822 mandatory to implement in RFC3711, i.e., AES-CM and HMAC-SHA1. The 9823 default key-management mechanism which MUST be implemented is the one 9824 defined in the MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY 9825 implementation MUST implement the necessary functions for MIKEY-RSA-R 9826 mode [RFC4738] and in addition the SRTP parameter negotiation 9827 necessary to negotiate the supported SRTP transforms and parameters. 9829 22. IANA Considerations 9831 This section sets up a number of registries for RTSP 2.0 that should 9832 be maintained by IANA. These registries are separate from any 9833 registries existing for RTSP 1.0. For each registry there is a 9834 description of what it is required to contain, what specification is 9835 needed when adding an entry with IANA, and finally the entries that 9836 this document needs to register. See also the Section 2.7 "Extending 9837 RTSP". There is also an IANA registration of three SDP attributes. 9839 Registries or entries in registries which have been made for RTSP 1.0 9840 are not moved to RTSP 2.0. The registries and entries in registries 9841 of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry 9842 in a registry is also required in RTSP 2.0, it MUST follow the 9843 procedure defined below to allocate the registry or entry in a 9844 registry. 9846 The sections describing how to register an item uses some of the 9847 registration policies described in RFC 5226 [RFC5226], namely "First 9848 Come, First Served", "Expert Review, "Specification Required", and 9849 "Standards Action". 9851 RFC-Editor Note: Please replace all occurrences of RFCXXXX with 9852 the RFC number this specification receives when published. 9854 In case a registry requires a contact person, the authors, with 9855 Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are 9856 the contact persons for any entries created by this document. 9858 IANA will request the following information for any registration 9859 request: 9861 o A name of the item to register according to the rules specified by 9862 the intended registry. 9864 o Indication of who has change control over the feature (for 9865 example, IETF, ISO, ITU-T, other international standardization 9866 bodies, a consortium, a particular company or group of companies, 9867 or an individual); 9869 o A reference to a further description, if available, for example 9870 (in decreasing order of preference) an RFC, a published standard, 9871 a published paper, a patent filing, a technical report, documented 9872 source code or a computer manual; 9874 o For proprietary features, contact information (postal and email 9875 address); 9877 22.1. Feature-tags 9878 22.1.1. Description 9880 When a client and server try to determine what part and functionality 9881 of the RTSP specification and any future extensions that its counter 9882 part implements there is need for a namespace. This registry 9883 contains named entries representing certain functionality. 9885 The usage of feature-tags is explained in Section 11 and 9886 Section 13.1. 9888 22.1.2. Registering New Feature-tags with IANA 9890 The registering of feature-tags is done on a First Come, First Served 9891 [RFC5226] basis. 9893 The registry entry for a feature-tag has the following information: 9895 o The name of the feature-tag 9897 * If the registrant indicates that the feature is proprietary, 9898 IANA should request a vendor "prefix" portion of the name. The 9899 name will then be the vendor prefix followed by a "." followed 9900 by the rest of the provided feature name. 9902 * If the feature is not proprietary, then IANA need not collect a 9903 prefix for the name. 9905 o A one paragraph description of what the feature-tag represents 9907 o The applicability (server, client, proxy, or some combination) 9909 o A reference to a specification, if applicable 9911 Feature-tag names (including the vendor prefix) may contain any non- 9912 space and non-control characters. There is no length limit on 9913 feature-tags. 9915 Examples for a vendor tag describing a proprietary feature are: 9917 vendorA.specfeat01 9919 vendorA.specfeat02 9921 22.1.3. Registered entries 9923 The following feature-tags are defined in this specification and 9924 hereby registered. The change control belongs to the IETF. 9926 play.basic: The implementation for delivery and playback operations 9927 according to the core RTSP specification, as defined in this 9928 memo. Applies for both clients, servers and proxies. See 9929 Section 11.1. 9931 play.scale: Support of scale operations for media playback. Applies 9932 only for servers. See Section 18.46. 9934 play.speed: Support of the speed functionality for media delivery. 9935 Applies only for servers. See Section 18.50. 9937 setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as 9938 discussed in Appendix C.1.6.4. Applies for both client and 9939 servers and any media caching proxy. 9941 This should be represented by IANA as a table with the feature tags, 9942 contact person and their references. 9944 22.2. RTSP Methods 9946 22.2.1. Description 9948 Methods are described in Section 13. Extending the protocol with new 9949 methods allow for totally new functionality. 9951 22.2.2. Registering New Methods with IANA 9953 A new method is registered through an IETF Standards Action 9954 [RFC5226]. The reason is that new methods may radically change the 9955 protocol's behavior and purpose. 9957 A specification for a new RTSP method consist of the following items: 9959 o A method name which follows the ABNF rules for methods. 9961 o A clear specification what a request using the method does and 9962 what responses are expected. Which directions the method is used, 9963 C->S or S->C or both. How the use of headers, if any, modifies 9964 the behavior and effect of the method. 9966 o A list or table specifying which of the IANA registered headers 9967 that are allowed to be used with the method in request or/and 9968 response. The list or table SHOULD follow the format of tables in 9969 Section 18. 9971 o Describe how the method relates to network proxies. 9973 22.2.3. Registered Entries 9975 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 9976 GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, 9977 SET_PARAMETER, and TEARDOWN. The initial table of the registry is 9978 provided below. 9980 Method Directionality Reference 9981 ----------------------------------------------------- 9982 DESCRIBE C->S [RFCXXXX] 9983 GET_PARAMETER C->S, S->C [RFCXXXX] 9984 OPTIONS C->S, S->C [RFCXXXX] 9985 PAUSE C->S [RFCXXXX] 9986 PLAY C->S [RFCXXXX] 9987 PLAY_NOTIFY S->C [RFCXXXX] 9988 REDIRECT S->C [RFCXXXX] 9989 SETUP C->S [RFCXXXX] 9990 SET_PARAMETER C->S, S->C [RFCXXXX] 9991 TEARDOWN C->S, S->C [RFCXXXX] 9993 22.3. RTSP Status Codes 9995 22.3.1. Description 9997 A status code is the three digit number used to convey information in 9998 RTSP response messages, see Section 8. The number space is limited 9999 and care should be taken not to fill the space. 10001 22.3.2. Registering New Status Codes with IANA 10003 A new status code registration follows the policy of IETF Review 10004 [RFC5226]. New RTSP functionality requiring Status Codes should 10005 first be registered in the range x50-x99. Only when the range is 10006 full should registrations be done in the x00-x49 range, unless it is 10007 to adopt an HTTP extension also to RTSP. The reason is to enable any 10008 HTTP extension to be adopted to RTSP without needing to renumber any 10009 related status codes. A specification for a new status code specify 10010 the following: 10012 o The registered number. 10014 o A description of what the status code means and the expected 10015 behavior of the sender and receiver of the code. 10017 22.3.3. Registered Entries 10019 RFCXXXX, registers the numbered status code defined in the ABNF entry 10020 "Status-Code" except "extension-code" (that defines the syntax 10021 allowed for future extensions) in Section 20.2.2. 10023 22.4. RTSP Headers 10025 22.4.1. Description 10027 By specifying new headers a method(s) can be enhanced in many 10028 different ways. An unknown header will be ignored by the receiving 10029 agent. If the new header is vital for a certain functionality, a 10030 feature-tag for the functionality can be created and demanded to be 10031 used by the counter-part with the inclusion of a Require header 10032 carrying the feature-tag. 10034 22.4.2. Registering New Headers with IANA 10036 Registrations in the registry can be done following the Expert Review 10037 policy [RFC5226]. A specification is recommended to be provided, 10038 preferably an IETF RFC or other Standards Developing Organization 10039 specification. The minimal information in a registration request is 10040 the header name and the contact information. 10042 The expert reviewer verifies that the registration request contain 10043 the following information: 10045 o The name of the header. 10047 o An ABNF specification of the header syntax. 10049 o A list or table specifying when the header may be used, 10050 encompassing all methods, their request or response, the direction 10051 (C->S or S->C). 10053 o How the header is to be handled by proxies. 10055 o A description of the purpose of the header. 10057 22.4.3. Registered entries 10059 All headers specified in Section 18 in RFCXXXX are to be registered. 10060 The Registry is to include header name and reference. 10062 Furthermore the following legacy RTSP headers defined in other 10063 specifications are registered with header name, reference and 10064 description according to below list. Note: These references may not 10065 fulfill all of the above rules for registrations due to their legacy 10066 status. 10068 o x-wap-profile defined in [TS-26234]. The x-wap-profile request- 10069 header contains one or more absolute URLs to the requesting 10070 agent's device capability profile. 10072 o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff 10073 request-header contains a subset of a device capability profile. 10075 o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile- 10076 warning is a response-header that contains error codes explaining 10077 to what extent the server has been able to match the terminal 10078 request in regards to device capability profile as described using 10079 x-wap-profile and x-wap-profile-diff headers. 10081 o x-predecbufsize defined in [TS-26234]. This response-header 10082 provides an RTSP agent with the TS 26.234 Annex G hypothetical 10083 pre-decoder buffer size. 10085 o x-initpredecbufperiod defined in [TS-26234]. This response-header 10086 provides an RTSP agent with the TS 26.234 Annex G hypothetical 10087 pre-decoder buffering period. 10089 o x-initpostdecbufperiod defined in [TS-26234]. This response- 10090 header provides an RTSP agent with the TS 26.234 Annex G post- 10091 decoder buffering period. 10093 o 3gpp-videopostdecbufsize defined in [TS-26234]. This response- 10094 header provides an RTSP agent with the TS 26.234 defined post- 10095 decoder buffer size usable for H.264 (AVC) video streams. 10097 o 3GPP-Link-Char defined in [TS-26234]. This request-header 10098 provides the RTSP server with the RTSP client's link 10099 characteristics as determined from the radio interface. The 10100 information that can be provided are guaranteed bit-rate, maximum 10101 bit-rate and maximum transfer delay. 10103 o 3GPP-Adaptation defined in [TS-26234]. This general-header is 10104 part of the bit-rate adaptation solution specified for PSS. It 10105 provides the RTSP client's buffer sizes and target buffer levels 10106 to the server and responses are used to acknowledge the support 10107 and values. 10109 o 3GPP-QoE-Metrics defined in [TS-26234]. This general-header is 10110 used by PSS RTSP agents to negotiate the quality of experience 10111 metrics that a client should gather and report to the server. 10113 o 3GPP-QoE-Feedback defined in [TS-26234]. This request-header is 10114 used by RTSP clients supporting PSS to report the actual values of 10115 the metrics gathered in its quality of experience metering. 10117 The use of "x-" is NOT RECOMMENDED but the above headers in the 10118 register list were defined prior to the clarification. 10120 22.5. Accept-Credentials 10122 The security framework's TLS connection mechanism has two 10123 registerable entities. 10125 22.5.1. Accept-Credentials policies 10127 This registry are for polices for a RTSP proxy's handling and 10128 verification of TLS certificates when establishing outbound TLS 10129 connection on clients behalf. In Section 19.3.1 three policies for 10130 how to handle certificates are specified. Further policies may be 10131 defined and registration is done through an IETF Standards Action 10132 [RFC5226]. The registration is required to contain the following 10133 information: 10135 o Name of the policy. 10137 o A describing text that explains how the policy works for handling 10138 the certificates. 10140 o A contact person. 10142 This specification registers the following values: 10144 Any: A policy requiring the proxy to accept any received 10145 certificate. 10147 Proxy: A policy where the proxy applies its own policies to 10148 determine which certificates are accepted or not. 10150 User: A policy where the certificate is required to be forwarded down 10151 the proxy chain to the client, thus allowing the user to 10152 decided to accept or refuse a certificate. 10154 22.5.2. Accept-Credentials hash algorithms 10156 The Accept-Credentials header (See Section 18.2) allows for the usage 10157 of other algorithms for hashing the DER records of accepted entities. 10158 The registration of any future algorithm is expected to be extremely 10159 rare and could also cause interoperability problems. Therefore the 10160 bar for registering new algorithms is intentionally placed high. 10162 Any registration of a new hash algorithm requires an IETF Standards 10163 Action [RFC5226]. The registration needs to fulfill the following 10164 requirement: 10166 o The algorithms identifier meeting the "token" ABNF requirement. 10168 o Provide a definition of the algorithm. 10170 The registered value is: 10172 Hash Alg. Id Reference 10173 ------------------------ 10174 sha-256 [RFCXXXX] 10176 22.6. Cache-Control Cache Directive Extensions 10178 There exists a number of cache directives which can be sent in the 10179 Cache-Control header. A registry for these cache directives is 10180 established by IANA. New registrations in this registry requires an 10181 IETF Standards Action or IESG Approval [RFC5226]. The registration 10182 needs to contain the following information. 10184 o Name of the directive 10186 o A definition of the parameter value, if any is allowed. 10188 o Specification if it is a request or response directive. 10190 o A describing text that explains how the cache directive is used 10191 for RTSP controlled media streams. 10193 o A contact person. 10195 This specification registers the following values: 10197 no-cache: 10199 public: 10201 private: 10203 no-transform: 10205 only-if-cached: 10207 max-stale: 10209 min-fresh: 10211 must-revalidate: 10213 proxy-revalidate: 10215 max-age: 10217 The registry should be represented as: Name of the directive, contact 10218 person and reference. 10220 22.7. Media Properties 10222 22.7.1. Description 10224 The media streams being controlled by RTSP can have many different 10225 properties. The media properties required to cover the use cases 10226 that were in mind when writing the specification are defined. 10227 However, it can be expected that further innovation will result in 10228 new use cases or media streams with properties not covered by the 10229 ones specified here. Thus new media properties can be specified. As 10230 new media properties may need a substantial amount of new definitions 10231 to correctly specify behavior for this property the bar is intended 10232 to be high. 10234 22.7.2. Registration Rules 10236 Registering a new media property is done following the Specification 10237 Required policy [RFC5226]. The Expert reviewer verifies that a 10238 registration request fulfill the following requirements. 10240 o Have an ABNF definition of the media property value name that 10241 meets "media-prop-ext" definition. 10243 o Define which media property group it belongs to or define a new 10244 group. 10246 o Description of all changes to the behavior of the RTSP protocol as 10247 result of these changes. 10249 o A Contact Person for the Registration. 10251 22.7.3. Registered Values 10253 This specification registers the ten values listed in Section 18.29. 10254 The registry should be represented as: Name of the media property, 10255 property group, contact person and reference. 10257 22.8. Notify-Reason header 10259 22.8.1. Description 10261 Notify-Reason values are used for indicating the reason the 10262 notification was sent. Each reason has its associated rules on what 10263 headers and information that may or must be included in the 10264 notification. New notification behaviors need to be specified to 10265 enable interoperable usage, thus a specification of each new value is 10266 required. 10268 22.8.2. Registration Rules 10270 Registrations for new Notify-Reason value follows the Specification 10271 Required policy [RFC5226]. The Expert Reviewer verifies that the 10272 request fulfills the following requirements: 10274 o An ABNF definition of the Notify reason value name that meets 10275 "Notify-Reason-extension" definition 10277 o Description of which headers shall be included in the request and 10278 response, when it should be sent, and any effect it has on the 10279 server client state. 10281 o A Contact Person for the Registration 10283 22.8.3. Registered Values 10285 This specification registers 3 values defined in the Notify-Reas-val 10286 ABNF, Section 20.2.3: 10288 end-of-stream: This Notify-Reason value indicates the end of a media 10289 stream. 10291 media-properties-update: This Notify-Reason value allows the server 10292 to indicate that the properties of the media has changed during 10293 the playout. 10295 scale-change: This Notify-Reason value allows the server to notify 10296 the client about a change in the Scale of the media. 10298 The registry entries should be represented in the registry as: Name, 10299 short description, contact and reference. 10301 22.9. Range Header Formats 10303 22.9.1. Description 10305 The Range header (Section 18.40) allows for different range formats. 10306 These range formats also needs an identifier to be used the Accept- 10307 Ranges header (Section 18.5). New range formats may be registered, 10308 but moderation should be applied as it makes interoperability more 10309 difficult. 10311 22.9.2. Registration Rules 10313 A registration follows the Specification Required policy [RFC5226]. 10314 The Expert Reviewer verifies that the request fulfills the following 10315 requirements: 10317 o An ABNF definition of the range format that fulfills the "range- 10318 ext" definition. 10320 o Define the range format identifier used in Accept-Ranges header 10321 according to the "extension-format" definition. 10323 o Rules for how one handles the range when using a negative Scale. 10325 o A Contact person for the registration. 10327 22.9.3. Registered Values 10329 The registry should be represented as: Range header format 10330 identifier, Name of the range format, contact person and reference. 10331 This specification registers the following values. 10333 npt: Normal Play Time 10335 clock: UTC Absolute Time format 10337 smpte: SMPTE Timestamps 10339 smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop) 10341 smpte-25: SMPTE Timestamps 25 Frames/sec 10343 22.10. Terminate-Reason Header 10345 The Terminate-Reason header (Section 18.52) has two registries for 10346 extensions. 10348 22.10.1. Redirect Reasons 10350 This registry contains reasons for session Termination that can be 10351 included in a Terminate-Reason header (Section 18.52). Registrations 10352 are following the policy of Expert Review [RFC5226]. The Expert 10353 Reviewer verifies that the registration contains the following 10354 information: 10356 o The value follows the Terminate-Reason ABNF, i.e., be a token. 10358 o That the specification provide a definition of what procedures are 10359 to be followed when a client receives this redirect reason. 10361 o A Contact Person 10363 This specification registers three values: 10365 o Session-Timeout 10367 o Server-Admin 10369 o Internal-Error 10371 The registry should be represented as: Name of the Redirect Reason, 10372 contact person and reference. 10374 22.10.2. Terminate-Reason Header Parameters 10376 This registry contains parameters that may be included in the 10377 Terminate-Reason header (Section 18.52) in addition to a reason. 10378 Registrations are done under the policy of Specification Required 10379 [RFC5226]. The Expert Reviewer verifies that the registration or the 10380 reference specification contains the following: 10382 o A Parameter Name. 10384 o A Parameter following the syntax allowed by the RTSP 2.0 10385 specification. 10387 o A Reference to the specification. 10389 o A contact person. 10391 This specification registers: 10393 o time 10395 o user-msg 10396 The registry should be represented as: Name of the Terminate Reason, 10397 contact person and reference. 10399 22.11. RTP-Info header parameters 10401 22.11.1. Description 10403 The RTP-Info header (Section 18.45) carries one or more parameter 10404 value pairs with information about a particular point in the RTP 10405 stream. RTP extensions or new usages may need new types of 10406 information. As RTP information that could be needed is likely to be 10407 generic enough and to maximize the interoperability, new registration 10408 requires Specification Required. 10410 22.11.2. Registration Rules 10412 Registrations for new RTP-Info values follows the policy of 10413 Specification Required [RFC5226]. The Expert Reviewer verifies that 10414 the registration and its reference contains the following 10415 information. 10417 o Have an ABNF definition that meets the "generic-param" definition. 10419 o A Reference to the specification. 10421 o A Contact Person for the Registration. 10423 22.11.3. Registered Values 10425 This specification registers the following parameter value pairs: 10427 o url 10429 o ssrc 10431 o seq 10433 o rtptime 10435 The registry should be represented as: Name of the parameter, contact 10436 person and reference. 10438 22.12. Seek-Style Policies 10439 22.12.1. Description 10441 Seek-Style Policies defines how the RTSP agent seeks in media content 10442 when given a position within the media content. New seek policies 10443 may be registered, however, a large number of these will complicate 10444 implementation substantially. The impact of unknown policies is that 10445 the server will not honor the unknown and use the server default 10446 policy instead. 10448 22.12.2. Registration Rules 10450 Registrations of new Seek-Style polices follows the policy of 10451 Specification Required [RFC5226]. The Expert Reviewer verifies that 10452 the registration fulfill the following requirements: 10454 o Have an ABNF definition of the Seek-Style policy name that meets 10455 "Seek-S-value-ext" definition 10457 o Short Description 10459 o A Contact Person for the Registration 10461 o Description of which headers shall be included in the request and 10462 response, when it should be sent, and any affect it has on the 10463 server client state. 10465 22.12.3. Registered Values 10467 This specification registers 4 values (Name - Short Description): 10469 o RAP - Using the closest Random Access Point prior or at the 10470 requested start position. 10472 o CoRAP - Conditional Random Access Point is like RAP, but only if 10473 the RAP is closer prior to the requested start position than 10474 current pause point. 10476 o First-Prior - The first-prior policy will start delivery with the 10477 media unit that has a playout time first prior to the requested 10478 start position. 10480 o Next - The next media units after the provided start position. 10482 The registry should be represented as: Name of the Seek-Style Policy, 10483 short description, contact person and reference. 10485 22.13. Transport Header Registries 10487 The transport header (Section 18.54) contains a number of parameters 10488 which have possibilities for future extensions. Therefore registries 10489 for these need to be defined. 10491 22.13.1. Transport Protocol Identifier 10493 A Transport Protocol Specification consists of a Transport Protocol 10494 Identifier, representing some combination of transport protocols, and 10495 any number of transport header parameters required or optional to use 10496 with the identified protocol specification. This registry contains 10497 the identifiers used by registered Transport Protocol Identifiers. 10499 A registration for the parameter transport protocol identifier 10500 follows the policy of Specification Required [RFC5226]. The expert 10501 reviewer verifies that the registration fulfill the following 10502 requirements: 10504 o A contact person or organization with address and email. 10506 o A value definition that are following the ABNF syntax definition 10507 of "transport-id" Section 20.2.3. 10509 o A descriptive text that explains how the registered value are used 10510 in RTSP, which underlying transport protocols that are used, and 10511 any required Transport header parameters. 10513 The registry should be represented as: The protocol ID string, 10514 contact person and reference. 10516 This specification registers the following values: 10518 RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in 10519 combination with the "RTP profile for audio and video 10520 conferences with minimal control" [RFC3551] over UDP. The 10521 usage is explained in RFC XXXX, Appendix C.1. 10523 RTP/AVP/UDP: the same as RTP/AVP. 10525 RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in 10526 combination with the "Extended RTP Profile for RTCP-based 10527 Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is 10528 explained in RFC XXXX, Appendix C.1. 10530 RTP/AVPF/UDP: the same as RTP/AVPF. 10532 RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in 10533 combination with the "The Secure Real-time Transport Protocol 10534 (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 10535 XXXX, Appendix C.1. 10537 RTP/SAVP/UDP: the same as RTP/SAVP. 10539 RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in 10540 combination with the Extended Secure RTP Profile for Real-time 10541 Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 10542 [RFC5124] over UDP. The usage is explained in RFC XXXX, 10543 Appendix C.1. 10545 RTP/SAVPF/UDP: the same as RTP/SAVPF. 10547 RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10548 in combination with the "RTP profile for audio and video 10549 conferences with minimal control" [RFC3551] over TCP. The 10550 usage is explained in RFC XXXX, Appendix C.2.2. 10552 RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10553 in combination with the "Extended RTP Profile for RTCP-based 10554 Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is 10555 explained in RFC XXXX, Appendix C.2.2. 10557 RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport 10558 in combination with the "The Secure Real-time Transport 10559 Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in 10560 RFC XXXX, Appendix C.2.2. 10562 RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport 10563 in combination with the "Extended Secure RTP Profile for Real- 10564 time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 10565 SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 10566 XXXX, Appendix C.2.2. 10568 22.13.2. Transport modes 10570 The Transport Mode is a Transport header (Section 18.54) parameter, 10571 it is used to identify the general mode of media transport. The PLAY 10572 value registered defines a PLAYBACK mode, where media flows from 10573 Server to Client. 10575 A registration for the transport parameter mode follows the policy of 10576 IETF Standards Action [RFC5226]. The registration needs to meet the 10577 following requirements: 10579 o A value definition that are following the ABNF "token" definition 10580 Section 20.2.3. 10582 o A describing text that explains how the registered value are used 10583 in RTSP. 10585 This specification registers 1 value: 10587 PLAY: See RFC XXXX. 10589 The registry should be represented as: The Transport Mode value, 10590 contact person and reference. 10592 22.13.3. Transport Parameters 10594 Transport Parameters are different parameters used in a Transport 10595 Header's transport specification (Section 18.54) to provide 10596 additional information required beyond the transport protocol 10597 identifier to establish a functioning transport. 10599 A registration for parameters that may be included in the Transport 10600 header follows the policy of Specification Required [RFC5226]. The 10601 expert reviewer verifies that the registration fulfill the following 10602 requirements: 10604 o A Transport Parameter Name following the "token" ABNF definition. 10606 o A value definition, if the parameter takes a value, that are 10607 following the ABNF definition "trn-par-value" Section 20.2.3. 10609 o A describing text that explains how the registered value are used 10610 in RTSP. 10612 This specification registers all the transport parameters defined in 10613 Section 18.54. This is a copy of this list: 10615 o unicast 10617 o multicast 10619 o interleaved 10621 o ttl 10623 o layers 10625 o ssrc 10626 o mode 10628 o dest_addr 10630 o src_addr 10632 o setup 10634 o connection 10636 o RTCP-mux 10638 o MIKEY 10640 The registry should be represented as: The transport parameter name, 10641 contact person and reference. 10643 22.14. URI Schemes 10645 This specification updates two URI schemes, one previously registered 10646 "rtsp", and one missing in the registry "rtspu", previously only 10647 defined in the RTSP 1.0 [RFC2326], one new URI scheme "rtsps" is also 10648 registered. These URI schemes are registered in an existing registry 10649 (Uniform Resource Identifier (URI) Schemes) which is not created by 10650 this memo. Registrations are following RFC 4395[RFC4395]. 10652 22.14.1. The rtsp URI Scheme 10654 URI scheme name: rtsp 10656 Status: Permanent 10658 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10660 URI scheme semantics: The rtsp scheme is used to indicate resources 10661 accessible through the usage of the Real-time Streaming 10662 Protocol (RTSP). RTSP allows different operations on the 10663 resource identified by the URI, but the primary purpose is the 10664 streaming delivery of the resource to a client. However, the 10665 operations that are currently defined are: DESCRIBE, 10666 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10667 SETUP, SET_PARAMETER, and TEARDOWN. 10669 Encoding considerations: IRIs in this scheme are defined and needs 10670 to be encoded as RTSP URIs when used within the RTSP protocol. 10671 That encoding is done according to RFC 3987. 10673 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10674 2326), RTSP 2.0 (RFC XXXX) 10676 Interoperability considerations: The extensions in the URI syntax 10677 performed between RTSP 1.0 and 2.0 can create interoperability 10678 issues. The changes are: 10680 Support for IPV6 literal in host part and future IP literals 10681 through RFC 3986 defined mechanism. 10683 A new relative format to use in the RTSP protocol elements 10684 that is not required to start with "/". 10686 The above changes should have no impact on interoperability as 10687 in detail discussed in Section 4.2 of RFCXXXX. 10689 Security considerations: All the security threats identified in 10690 Section 7 of RFC 3986 apply also to this scheme. They need to 10691 be reviewed and considered in any implementation utilizing this 10692 scheme. 10694 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10696 Author/Change controller: IETF 10698 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10700 22.14.2. The rtsps URI Scheme 10702 URI scheme name: rtsps 10704 Status: Permanent 10706 URI scheme syntax: See Section 20.2.1 of RFC XXXX. 10708 URI scheme semantics: The rtsps scheme is used to indicate resources 10709 accessible through the usage of the Real-time Streaming 10710 Protocol (RTSP) over TLS. RTSP allows different operations on 10711 the resource identified by the URI, but the primary purpose is 10712 the streaming delivery of the resource to a client. However, 10713 the operations that are currently defined are: DESCRIBE, 10714 GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, 10715 SETUP, SET_PARAMETER, and TEARDOWN. 10717 Encoding considerations: IRIs in this scheme are defined and needs 10718 to be encoded as RTSP URIs when used within the RTSP protocol. 10719 That encoding is done according to RFC 3987. 10721 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10722 2326), RTSP 2.0 (RFC XXXX) 10724 Interoperability considerations: The "rtsps" scheme was never 10725 officially defined for RTSP 1.0, however it has seen widespread 10726 use in actual deployments of RTSP 1.0. Therefore this section 10727 discusses the believed changes between the unspecified RTSP 1.0 10728 "rtsps" scheme and RTSP 2.0 definition. The extensions in the 10729 URI syntax performed between RTSP 1.0 and 2.0 can create 10730 interoperability issues. The changes are: 10732 Support for IPV6 literal in host part and future IP literals 10733 through RFC 3986 defined mechanism. 10735 A new relative format to use in the RTSP protocol elements 10736 that is not required to start with "/". 10738 The above changes should have no impact on interoperability as 10739 in detail discussed in Section 4.2 of RFCXXXX. 10741 Security considerations: All the security threats identified in 10742 Section 7 of RFC 3986 apply also to this scheme. They need to 10743 be reviewed and considered in any implementation utilizing this 10744 scheme. 10746 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10748 Author/Change controller: IETF 10750 References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX 10752 22.14.3. The rtspu URI Scheme 10754 URI scheme name: rtspu 10756 Status: Permanent 10758 URI scheme syntax: See Section 3.2 of RFC 2326. 10760 URI scheme semantics: The rtspu scheme is used to indicate resources 10761 accessible through the usage of the Real-time Streaming 10762 Protocol (RTSP) over unreliable datagram transport. RTSP 10763 allows different operations on the resource identified by the 10764 URI, but the primary purpose is the streaming delivery of the 10765 resource to a client. However, the operations that are 10766 currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, 10767 REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and 10768 TEARDOWN. 10770 Encoding considerations: This scheme is not intended to be used with 10771 characters outside the US-ASCII repertoire. 10773 Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 10774 2326) 10776 Interoperability considerations: The definition of the transport 10777 mechanism of RTSP over UDP has interoperability issues. That 10778 makes the usage of this scheme problematic. 10780 Security considerations: All the security threats identified in 10781 Section 7 of RFC 3986 apply also to this scheme. They needs to 10782 be reviewed and considered in any implementation utilizing this 10783 scheme. 10785 Contact: Magnus Westerlund, magnus.westerlund@ericsson.com 10787 Author/Change controller: IETF 10789 References: RFC 2326 10791 22.15. SDP attributes 10793 This specification defines three SDP [RFC4566] attributes that it is 10794 requested that IANA register. 10796 SDP Attribute ("att-field"): 10798 Attribute name: range 10799 Long form: Media Range Attribute 10800 Type of name: att-field 10801 Type of attribute: Media and session level 10802 Subject to charset: No 10803 Purpose: RFC XXXX 10804 Reference: RFC XXXX, RFC 2326 10805 Values: See ABNF definition. 10807 Attribute name: control 10808 Long form: RTSP control URI 10809 Type of name: att-field 10810 Type of attribute: Media and session level 10811 Subject to charset: No 10812 Purpose: RFC XXXX 10813 Reference: RFC XXXX, RFC 2326 10814 Values: Absolute or Relative URIs. 10816 Attribute name: mtag 10817 Long form: Message Tag 10818 Type of name: att-field 10819 Type of attribute: Media and session level 10820 Subject to charset: No 10821 Purpose: RFC XXXX 10822 Reference: RFC XXXX 10823 Values: See ABNF definition 10825 22.16. Media Type Registration for text/parameters 10827 Type name: text 10829 Subtype name: parameters 10831 Required parameters: 10833 Optional parameters: charset: The charset parameter is applicable to 10834 the encoding of the parameter values. The default charset is 10835 UTF-8, if the 'charset' parameter is not present. 10837 Encoding considerations: 8bit 10839 Security considerations: This format may carry any type of 10840 parameters. Some can have security requirements, like privacy, 10841 confidentiality or integrity requirements. The format has no 10842 built in security protection. For the usage it was defined the 10843 transport can be protected between server and client using TLS. 10844 However, care must be taken to consider if also the proxies are 10845 trusted with the parameters in case hop-by-hop security is used. 10846 If stored as a file in file system, the necessary precautions need 10847 to be taken in relation to the parameters requirements including 10848 object security such as S/MIME [RFC5751]. 10850 Interoperability considerations: This media type was mentioned as a 10851 fictional example in [RFC2326], but was not formally specified. 10852 This has resulted in usage of this media type which may not match 10853 its formal definition. 10855 Published specification: RFC XXXX, Appendix F. 10857 Applications that use this media type: Applications that use RTSP 10858 and have additional parameters they like to read and set using the 10859 RTSP GET_PARAMETER and SET_PARAMETER methods. 10861 Additional information: 10863 Magic number(s): 10865 File extension(s): 10867 Macintosh file type code(s): 10869 Person & email address to contact for further information: Magnus We 10870 sterlund (magnus.westerlund@ericsson.com) 10872 Intended usage: Common 10874 Restrictions on usage: None 10876 Author: Magnus Westerlund (magnus.westerlund@ericsson.com) 10878 Change controller: IETF 10880 Addition Notes: 10882 23. References 10884 23.1. Normative References 10886 [FIPS-pub-180-2] 10887 National Institute of Standards and Technology (NIST), 10888 "Federal Information Processing Standards Publications 10889 (FIPS PUBS) 180-2: Secure Hash Standard", August 2002. 10891 [I-D.ietf-avtcore-rtp-circuit-breakers] 10892 Perkins, C. and V. Singh, "Multimedia Congestion Control: 10893 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 10894 avtcore-rtp-circuit-breakers-03 (work in progress), July 10895 2013. 10897 [I-D.ietf-mmusic-rtsp-nat] 10898 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 10899 Address Translator (NAT) Traversal mechanism for media 10900 controlled by Real-Time Streaming Protocol (RTSP)", draft- 10901 ietf-mmusic-rtsp-nat-17 (work in progress), November 2013. 10903 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 10904 August 1980. 10906 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 10907 793, September 1981. 10909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10910 Requirement Levels", BCP 14, RFC 2119, March 1997. 10912 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 10913 (IPv6) Specification", RFC 2460, December 1998. 10915 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 10916 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 10917 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 10919 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 10920 Leach, P., Luotonen, A., and L. Stewart, "HTTP 10921 Authentication: Basic and Digest Access Authentication", 10922 RFC 2617, June 1999. 10924 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 10926 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 10927 Jacobson, "RTP: A Transport Protocol for Real-Time 10928 Applications", STD 64, RFC 3550, July 2003. 10930 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 10931 Video Conferences with Minimal Control", STD 65, RFC 3551, 10932 July 2003. 10934 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10935 10646", STD 63, RFC 3629, November 2003. 10937 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 10938 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 10939 RFC 3711, March 2004. 10941 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 10942 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 10943 August 2004. 10945 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 10946 Resource Identifier (URI): Generic Syntax", STD 66, RFC 10947 3986, January 2005. 10949 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 10950 Identifiers (IRIs)", RFC 3987, January 2005. 10952 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 10953 Requirements for Security", BCP 106, RFC 4086, June 2005. 10955 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10956 Architecture", RFC 4291, February 2006. 10958 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 10959 Registration Procedures for New URI Schemes", BCP 35, RFC 10960 4395, February 2006. 10962 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 10963 Description Protocol", RFC 4566, July 2006. 10965 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 10966 and RTP Control Protocol (RTCP) Packets over Connection- 10967 Oriented Transport", RFC 4571, July 2006. 10969 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 10970 "Extended RTP Profile for Real-time Transport Control 10971 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 10972 2006. 10974 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 10975 Encodings", RFC 4648, October 2006. 10977 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 10978 RSA-R: An Additional Mode of Key Distribution in 10979 Multimedia Internet KEYing (MIKEY)", RFC 4738, November 10980 2006. 10982 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 10983 Real-time Transport Control Protocol (RTCP)-Based Feedback 10984 (RTP/SAVPF)", RFC 5124, February 2008. 10986 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 10987 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 10988 May 2008. 10990 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 10991 Specifications: ABNF", STD 68, RFC 5234, January 2008. 10993 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 10994 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 10996 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 10997 Housley, R., and W. Polk, "Internet X.509 Public Key 10998 Infrastructure Certificate and Certificate Revocation List 10999 (CRL) Profile", RFC 5280, May 2008. 11001 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 11002 October 2008. 11004 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 11005 Languages", BCP 47, RFC 5646, September 2009. 11007 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 11008 Mail Extensions (S/MIME) Version 3.2 Message 11009 Specification", RFC 5751, January 2010. 11011 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 11012 Control Packets on a Single Port", RFC 5761, April 2010. 11014 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 11015 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 11017 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 11018 Specifications and Registration Procedures", BCP 13, RFC 11019 6838, January 2013. 11021 [SMPTE_TC] 11022 Society of Motion Picture and Television Engineers, "SMPTE 11023 Standard for Television -- Time and Control Code, ST 11024 12M-1-2008", . 11026 [TS-26234] 11027 Third Generation Partnership Project (3GPP), "Transparent 11028 end-to-end Packet-switched Streaming Service (PSS); 11029 Protocols and codecs; Technical Specification 26.234", 11030 December 2002. 11032 23.2. Informative References 11034 [ISO.13818-6.1995] 11035 International Organization for Standardization, 11036 "Information technology - Generic coding of moving 11037 pictures and associated audio information - part 6: 11038 Extension for digital storage media and control", ISO 11039 Draft Standard 13818-6, November 1995. 11041 [ISO.8601.2000] 11042 International Organization for Standardization, "Data 11043 elements and interchange formats - Information interchange 11044 - Representation of dates and times", ISO/IEC Standard 11045 8601, December 2000. 11047 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 11048 1981. 11050 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 11051 and Support", STD 3, RFC 1123, October 1989. 11053 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 11054 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 11055 RFC 2068, January 1997. 11057 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 11058 Streaming Protocol (RTSP)", RFC 2326, April 1998. 11060 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 11061 Translator (NAT) Terminology and Considerations", RFC 11062 2663, August 1999. 11064 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 11065 Announcement Protocol", RFC 2974, October 2000. 11067 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 11068 A., Peterson, J., Sparks, R., Handley, M., and E. 11069 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 11070 June 2002. 11072 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 11073 with Session Description Protocol (SDP)", RFC 3264, June 11074 2002. 11076 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 11077 Internet: Timestamps", RFC 3339, July 2002. 11079 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 11080 the Session Description Protocol (SDP)", RFC 4145, 11081 September 2005. 11083 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 11084 Carrara, "Key Management Extensions for Session 11085 Description Protocol (SDP) and Real Time Streaming 11086 Protocol (RTSP)", RFC 4567, July 2006. 11088 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 11089 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 11090 July 2006. 11092 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 11093 Formats", RFC 4855, February 2007. 11095 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 11096 the RTP Profile for Audio and Video Conferences", RFC 11097 4856, February 2007. 11099 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 11100 "Codec Control Messages in the RTP Audio-Visual Profile 11101 with Feedback (AVPF)", RFC 5104, February 2008. 11103 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 11104 (ICE): A Protocol for Network Address Translator (NAT) 11105 Traversal for Offer/Answer Protocols", RFC 5245, April 11106 2010. 11108 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 11109 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 11110 October 2008. 11112 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 11113 Dependency in the Session Description Protocol (SDP)", RFC 11114 5583, July 2009. 11116 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 11117 Time Protocol Version 4: Protocol and Algorithms 11118 Specification", RFC 5905, June 2010. 11120 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 11121 "Computing TCP's Retransmission Timer", RFC 6298, June 11122 2011. 11124 [Stevens98] 11125 Stevens, W., "Unix Networking Programming - Volume 1, 11126 second edition", 1998. 11128 Appendix A. Examples 11130 This section contains several different examples trying to illustrate 11131 possible ways of using RTSP. The examples can also help with the 11132 understanding of how functions of RTSP work. However, remember that 11133 these are examples and the normative and syntax description in the 11134 other sections take precedence. Please also note that many of the 11135 examples contain syntax illegal line breaks to accommodate the 11136 formatting restriction that the RFC series impose. 11138 A.1. Media on Demand (Unicast) 11140 This is an example of media on demand streaming of a media stored in 11141 a container file. For purposes of this example, a container file is 11142 a storage entity in which multiple continuous media types pertaining 11143 to the same end-user presentation are present. In effect, the 11144 container file represents an RTSP presentation, with each of its 11145 components being RTSP controlled media streams. Container files are 11146 a widely used means to store such presentations. While the 11147 components are transported as independent streams, it is desirable to 11148 maintain a common context for those streams at the server end. 11150 This enables the server to keep a single storage handle open 11151 easily. It also allows treating all the streams equally in case 11152 of any prioritization of streams by the server. 11154 It is also possible that the presentation author may wish to prevent 11155 selective retrieval of the streams by the client in order to preserve 11156 the artistic effect of the combined media presentation. Similarly, 11157 in such a tightly bound presentation, it is desirable to be able to 11158 control all the streams via a single control message using an 11159 aggregate URI. 11161 The following is an example of using a single RTSP session to control 11162 multiple streams. It also illustrates the use of aggregate URIs. In 11163 a container file it is also desirable to not write any URI parts 11164 which are not kept, when the container is distributed, like the host 11165 and most of the path element. Therefore this example also uses the 11166 "*" and relative URI in the delivered SDP. 11168 Also this presentation description (SDP) is not cacheble, as the 11169 Expires header is set to an equal value with date indicating 11170 immediate expiration of its validity. 11172 Client C requests a presentation from media server M. The movie is 11173 stored in a container file. The client has obtained an RTSP URI to 11174 the container file. 11176 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11177 CSeq: 1 11178 User-Agent: PhonyClient/1.2 11180 M->C: RTSP/2.0 200 OK 11181 CSeq: 1 11182 Server: PhonyServer/1.0 11183 Date: Fri, 20 Dec 2013 10:20:32 +0000 11184 Content-Type: application/sdp 11185 Content-Length: 271 11186 Content-Base: rtsp://example.com/twister.3gp/ 11187 Expires: Fri, 20 Dec 2013 12:20:32 +0000 11189 v=0 11190 o=- 2890844256 2890842807 IN IP4 198.51.100.5 11191 s=RTSP Session 11192 i=An Example of RTSP Session Usage 11193 e=adm@example.com 11194 c=IN IP4 0.0.0.0 11195 a=control: * 11196 a=range:npt=00:00:00-00:10:34.10 11197 t=0 0 11198 m=audio 0 RTP/AVP 0 11199 a=control: trackID=1 11200 m=video 0 RTP/AVP 26 11201 a=control: trackID=4 11203 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11204 CSeq: 2 11205 User-Agent: PhonyClient/1.2 11206 Require: play.basic 11207 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11208 Accept-Ranges: npt, smpte, clock 11210 M->C: RTSP/2.0 200 OK 11211 CSeq: 2 11212 Server: PhonyServer/1.0 11213 Transport: RTP/AVP;unicast; ssrc=93CB001E; 11214 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11215 src_addr="198.51.100.5:9000"/"198.51.100.5:9001" 11216 Session: 12345678 11217 Expires: Fri, 20 Dec 2013 12:20:33 +0000 11218 Date: Fri, 20 Dec 2013 10:20:33 +0000 11219 Accept-Ranges: npt 11220 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11222 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11223 CSeq: 3 11224 User-Agent: PhonyClient/1.2 11225 Require: play.basic 11226 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11227 Session: 12345678 11228 Accept-Ranges: npt, smpte, clock 11230 M->C: RTSP/2.0 200 OK 11231 CSeq: 3 11232 Server: PhonyServer/1.0 11233 Transport: RTP/AVP;unicast; ssrc=A813FC13; 11234 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 11235 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11237 Session: 12345678 11238 Expires: Fri, 20 Dec 2013 12:20:33 +0000 11239 Date: Fri, 20 Dec 2013 10:20:33 +0000 11240 Accept-Range: NPT 11241 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11243 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11244 CSeq: 4 11245 User-Agent: PhonyClient/1.2 11246 Range: npt=30- 11247 Seek-Style: RAP 11248 Session: 12345678 11250 M->C: RTSP/2.0 200 OK 11251 CSeq: 4 11252 Server: PhonyServer/1.0 11253 Date: Fri, 20 Dec 2013 10:20:34 +0000 11254 Session: 12345678 11255 Range: npt=30-634.10 11256 Seek-Style: RAP 11257 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11258 ssrc=0D12F123:seq=12345;rtptime=3450012, 11259 url="rtsp://example.com/twister.3gp/trackID=1" 11260 ssrc=4F312DD8:seq=54321;rtptime=2876889 11262 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 11263 CSeq: 5 11264 User-Agent: PhonyClient/1.2 11265 Session: 12345678 11267 # Pause happens 0.87 seconds after starting to play 11269 M->C: RTSP/2.0 200 OK 11270 CSeq: 5 11271 Server: PhonyServer/1.0 11272 Date: Fri, 20 Dec 2013 10:20:35 +0000 11273 Session: 12345678 11274 Range: npt=30.87-634.10 11276 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11277 CSeq: 6 11278 User-Agent: PhonyClient/1.2 11279 Range: npt=30.87-634.10 11280 Seek-Style: Next 11281 Session: 12345678 11283 M->C: RTSP/2.0 200 OK 11284 CSeq: 6 11285 Server: PhonyServer/1.0 11286 Date: Fri, 20 Dec 2013 10:22:13 +0000 11287 Session: 12345678 11288 Range: npt=30.87-634.10 11289 Seek-Style: Next 11290 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11291 ssrc=0D12F123:seq=12555;rtptime=6330012, 11292 url="rtsp://example.com/twister.3gp/trackID=1" 11293 ssrc=4F312DD8:seq=55021;rtptime=3132889 11295 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 11296 CSeq: 7 11297 User-Agent: PhonyClient/1.2 11298 Session: 12345678 11300 M->C: RTSP/2.0 200 OK 11301 CSeq: 7 11302 Server: PhonyServer/1.0 11303 Date: Fri, 20 Dec 2013 10:31:53 +0000 11305 A.2. Media on Demand using Pipelining 11307 This example is basically the example above (Appendix A.1), but now 11308 utilizing pipelining to speed up the setup. It requires only two 11309 round trip times until the media starts flowing. First of all, the 11310 session description is retrieved to determine what media resources 11311 need to be setup. In the second step, one sends the necessary SETUP 11312 requests and the PLAY request to initiate media delivery. 11314 Client C requests a presentation from media server M. The movie is 11315 stored in a container file. The client has obtained an RTSP URI to 11316 the container file. 11318 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11319 CSeq: 1 11320 User-Agent: PhonyClient/1.2 11322 M->C: RTSP/2.0 200 OK 11323 CSeq: 1 11324 Server: PhonyServer/1.0 11325 Date: Fri, 20 Dec 2013 10:20:32 +0000 11326 Content-Type: application/sdp 11327 Content-Length: 271 11328 Content-Base: rtsp://example.com/twister.3gp/ 11329 Expires: Fri, 20 Dec 2013 12:20:32 +0000 11331 v=0 11332 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11333 s=RTSP Session 11334 i=An Example of RTSP Session Usage 11335 e=adm@example.com 11336 c=IN IP4 0.0.0.0 11337 a=control: * 11338 a=range:npt=00:00:00-00:10:34.10 11339 t=0 0 11340 m=audio 0 RTP/AVP 0 11341 a=control: trackID=1 11342 m=video 0 RTP/AVP 26 11343 a=control: trackID=4 11345 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 11346 CSeq: 2 11347 User-Agent: PhonyClient/1.2 11348 Require: play.basic 11349 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 11350 Accept-Ranges: npt, smpte, clock 11351 Pipelined-Requests: 7654 11353 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 11354 CSeq: 3 11355 User-Agent: PhonyClient/1.2 11356 Require: play.basic 11357 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 11358 Accept-Ranges: npt, smpte, clock 11359 Pipelined-Requests: 7654 11361 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 11362 CSeq: 4 11363 User-Agent: PhonyClient/1.2 11364 Range: npt=0- 11365 Seek-Style: RAP 11366 Pipelined-Requests: 7654 11368 M->C: RTSP/2.0 200 OK 11369 CSeq: 2 11370 Server: PhonyServer/1.0 11371 Transport: RTP/AVP;unicast; 11372 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11373 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11374 ssrc=93CB001E 11375 Session: 12345678 11376 Expires: Fri, 20 Dec 2013 12:20:32 +0000 11377 Date: Fri, 20 Dec 2013 10:20:32 +0000 11378 Accept-Ranges: npt 11379 Pipelined-Requests: 7654 11380 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11382 M->C: RTSP/2.0 200 OK 11383 CSeq: 3 11384 Server: PhonyServer/1.0 11385 Transport: RTP/AVP;unicast; 11386 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11387 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11388 ssrc=A813FC13 11389 Session: 12345678 11390 Expires: Sat, 21 Dec 2013 10:20:32 +0000 11391 Date: Fri, 20 Dec 2013 10:20:32 +0000 11392 Accept-Range: NPT 11393 Pipelined-Requests: 7654 11394 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11396 M->C: RTSP/2.0 200 OK 11397 CSeq: 4 11398 Server: PhonyServer/1.0 11399 Date: Fri, 20 Dec 2013 10:20:32 +0000 11400 Session: 12345678 11401 Range: npt=0-623.10 11402 Seek-Style: RAP 11403 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 11404 ssrc=0D12F123:seq=12345;rtptime=3450012, 11405 url="rtsp://example.com/twister.3gp/trackID=1" 11406 ssrc=4F312DD8:seq=54321;rtptime=2876889 11407 Pipelined-Requests: 7654 11409 A.3. Secured Media Session for on Demand Content 11411 This example is basically the above example (Appendix A.2), but now 11412 including establishment of SRTP crypto contexts to get a secured 11413 media delivery. First of all, the client attempts to fetch this 11414 insecurely, but the server redirects to a URI indicating a 11415 requirement on using a secure connection for the RTSP messages. The 11416 client establishes a TCP/TLS connections and the session description 11417 is retrieved to determine what media resources need to be setup. In 11418 the this session description secure media (SRTP) is indicated. In 11419 the next step, the client sends the necessary SETUP requests 11420 including MIKEY messages. This is pipeline with a PLAY request to 11421 initiate media delivery. 11423 Client C requests a presentation from media server M. The movie is 11424 stored in a container file. The client has obtained an RTSP URI to 11425 the container file. 11427 Note: The MIKEY messages below are not valid MIKEY message and are 11428 BASE64 encoded random data to represent where the MIKEY messages 11429 would go. 11431 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 11432 CSeq: 1 11433 User-Agent: PhonyClient/1.2 11435 M->C: RTSP/2.0 301 Moved Permanently 11436 CSeq: 1 11437 Server: PhonyServer/1.0 11438 Date: Fri, 20 Dec 2013 10:25:32 +0000 11439 Location: rtsps://example.com/twister.3gp 11441 C->M: Establish TCP/TLS connection and verify server's 11442 certificate that is represents example.com. 11443 Used for all below RTSP messages. 11445 C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0 11446 CSeq: 2 11447 User-Agent: PhonyClient/1.2 11449 M->C: RTSP/2.0 200 OK 11450 CSeq: 2 11451 Server: PhonyServer/1.0 11452 Date: Fri, 20 Dec 2013 10:25:33 +0000 11453 Content-Type: application/sdp 11454 Content-Length: 271 11455 Content-Base: rtsps://example.com/twister.3gp/ 11456 Expires: Fri, 20 Dec 2013 12:25:33 +0000 11458 v=0 11459 o=- 2890844256 2890842807 IN IP4 192.0.2.5 11460 s=RTSP Session 11461 i=An Example of RTSP Session Usage 11462 e=adm@example.com 11463 c=IN IP4 0.0.0.0 11464 a=control: * 11465 a=range:npt=00:00:00-00:10:34.10 11466 t=0 0 11467 m=audio 0 RTP/SAVP 0 11468 a=control: trackID=1 11469 m=video 0 RTP/SAVP 26 11470 a=control: trackID=4 11472 C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0 11473 CSeq: 3 11474 User-Agent: PhonyClient/1.2 11475 Require: play.basic 11476 Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001"; 11477 MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl 11478 Accept-Ranges: npt, smpte, clock 11479 Pipelined-Requests: 7654 11481 C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0 11482 CSeq: 4 11483 User-Agent: PhonyClient/1.2 11484 Require: play.basic 11485 Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003"; 11486 MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ= 11487 Accept-Ranges: npt, smpte, clock 11488 Pipelined-Requests: 7654 11490 C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0 11491 CSeq: 5 11492 User-Agent: PhonyClient/1.2 11493 Range: npt=0- 11494 Seek-Style: RAP 11495 Pipelined-Requests: 7654 11497 M->C: RTSP/2.0 200 OK 11498 CSeq: 3 11499 Server: PhonyServer/1.0 11500 Transport: RTP/SAVP;unicast; 11501 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 11502 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; 11503 ssrc=93CB001E; 11504 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x 11505 Session: 12345678 11506 Expires: Fri, 20 Dec 2013 12:25:34 +0000 11507 Date: Fri, 20 Dec 2013 10:25:34 +0000 11508 Accept-Ranges: npt 11509 Pipelined-Requests: 7654 11510 Media-Properties: Random-Access=0.2, Immutable, Unlimited 11512 M->C: RTSP/2.0 200 OK 11513 CSeq: 4 11514 Server: PhonyServer/1.0 11515 Transport: RTP/SAVP;unicast; 11516 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; 11517 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 11518 ssrc=A813FC13; 11519 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 11520 Session: 12345678 11521 Expires: Fri, 20 Dec 2013 12:25:34 +0000 11522 Date: Fri, 20 Dec 2013 10:25:34 +0000 11523 Accept-Range: NPT 11524 Pipelined-Requests: 7654 11525 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11527 M->C: RTSP/2.0 200 OK 11528 CSeq: 5 11529 Server: PhonyServer/1.0 11530 Date: Fri, 20 Dec 2013 10:25:34 +0000 11531 Session: 12345678 11532 Range: npt=0-623.10 11533 Seek-Style: RAP 11534 RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" 11535 ssrc=0D12F123:seq=12345;rtptime=3450012, 11536 url="rtsps://example.com/twister.3gp/trackID=1" 11537 ssrc=4F312DD8:seq=54321;rtptime=2876889; 11539 Pipelined-Requests: 7654 11541 A.4. Media on Demand (Unicast) 11543 An alternative example of media on demand with a bit more tweaks is 11544 the following. Client C requests a movie distributed from two 11545 different media servers A (audio.example.com) and V ( 11546 video.example.com). The media description is stored on a web server 11547 W. The media description contains descriptions of the presentation 11548 and all its streams, including the codecs that are available, dynamic 11549 RTP payload types, the protocol stack, and content information such 11550 as language or copyright restrictions. It may also give an 11551 indication about the timeline of the movie. 11553 In this example, the client is only interested in the last part of 11554 the movie. 11556 C->W: GET /twister.sdp HTTP/1.1 11557 Host: www.example.com 11558 Accept: application/sdp 11560 W->C: HTTP/1.1 200 OK 11561 Date: Wed, 23 Jan 2013 15:35:06 GMT 11562 Content-Type: application/sdp 11563 Content-Length: 278 11564 Expires: Thu, 24 Jan 2013 15:35:06 GMT 11566 v=0 11567 o=- 2890844526 2890842807 IN IP4 198.51.100.5 11568 s=RTSP Session 11569 e=adm@example.com 11570 c=IN IP4 0.0.0.0 11571 a=range:npt=00:00:00-01:49:34 11572 t=0 0 11573 m=audio 0 RTP/AVP 0 11574 a=control:rtsp://audio.example.com/twister/audio.en 11575 m=video 0 RTP/AVP 31 11576 a=control:rtsp://video.example.com/twister/video 11578 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 11579 CSeq: 1 11580 User-Agent: PhonyClient/1.2 11581 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 11582 RTP/AVP/TCP;unicast;interleaved=0-1 11583 Accept-Ranges: npt, smpte, clock 11585 A->C: RTSP/2.0 200 OK 11586 CSeq: 1 11587 Session: 12345678 11588 Transport: RTP/AVP/UDP;unicast; 11589 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11590 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11591 Date: Wed, 23 Jan 2013 15:35:12 +0000 11592 Server: PhonyServer/1.0 11593 Expires: Thu, 24 Jan 2013 15:35:12 +0000 11594 Cache-Control: public 11595 Accept-Ranges: npt, smpte 11596 Media-Properties: Random-Access=0.02, Immutable, Unlimited 11598 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 11599 CSeq: 1 11600 User-Agent: PhonyClient/1.2 11601 Transport: RTP/AVP/UDP;unicast; 11602 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", 11603 RTP/AVP/TCP;unicast;interleaved=0-1 11604 Accept-Ranges: npt, smpte, clock 11606 V->C: RTSP/2.0 200 OK 11607 CSeq: 1 11608 Session: 23456789 11609 Transport: RTP/AVP/UDP;unicast; 11610 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; 11611 src_addr="198.51.100.5:5002"/"198.51.100.5:5003" 11612 Date: Wed, 23 Jan 2013 15:35:12 +0000 11613 Server: PhonyServer/1.0 11614 Cache-Control: public 11615 Expires: Thu, 24 Jan 2013 15:35:12 +0000 11616 Accept-Ranges: npt, smpte 11617 Media-Properties: Random-Access=1.2, Immutable, Unlimited 11619 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 11620 CSeq: 2 11621 User-Agent: PhonyClient/1.2 11622 Session: 23456789 11623 Range: smpte=0:10:00- 11625 V->C: RTSP/2.0 200 OK 11626 CSeq: 2 11627 Session: 23456789 11628 Range: smpte=0:10:00-1:49:23 11629 Seek-Style: First-Prior 11630 RTP-Info: url="rtsp://video.example.com/twister/video" 11631 ssrc=A17E189D:seq=12312232;rtptime=78712811 11632 Server: PhonyServer/2.0 11633 Date: Wed, 23 Jan 2013 15:35:13 +0000 11635 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 11636 CSeq: 2 11637 User-Agent: PhonyClient/1.2 11638 Session: 12345678 11639 Range: smpte=0:10:00- 11641 A->C: RTSP/2.0 200 OK 11642 CSeq: 2 11643 Session: 12345678 11644 Range: smpte=0:10:00-1:49:23 11645 Seek-Style: First-Prior 11646 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 11647 ssrc=3D124F01:seq=876655;rtptime=1032181 11648 Server: PhonyServer/1.0 11649 Date: Wed, 23 Jan 2013 15:35:13 +0000 11651 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 11652 CSeq: 3 11653 User-Agent: PhonyClient/1.2 11654 Session: 12345678 11656 A->C: RTSP/2.0 200 OK 11657 CSeq: 3 11658 Server: PhonyServer/1.0 11659 Date: Wed, 23 Jan 2013 15:36:52 +0000 11661 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 11662 CSeq: 3 11663 User-Agent: PhonyClient/1.2 11664 Session: 23456789 11666 V->C: RTSP/2.0 200 OK 11667 CSeq: 3 11668 Server: PhonyServer/2.0 11669 Date: Wed, 23 Jan 2013 15:36:52 +0000 11671 Even though the audio and video track are on two different servers 11672 that may start at slightly different times and may drift with respect 11673 to each other over time, the client can perform initial 11674 synchronization of the two media using RTP-Info and Range received in 11675 the PLAY responses. If the two servers are time synchronized the 11676 RTCP packets can also be used to maintain synchronization. 11678 A.5. Single Stream Container Files 11680 Some RTSP servers may treat all files as though they are "container 11681 files", yet other servers may not support such a concept. Because of 11682 this, clients needs to use the rules set forth in the session 11683 description for Request-URIs, rather than assuming that a consistent 11684 URI may always be used throughout. Below is an example of how a 11685 multi-stream server might expect a single-stream file to be served: 11687 C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 11688 Accept: application/x-rtsp-mh, application/sdp 11689 CSeq: 1 11690 User-Agent: PhonyClient/1.2 11692 S->C: RTSP/2.0 200 OK 11693 CSeq: 1 11694 Content-base: rtsp://foo.example.com/test.wav/ 11695 Content-type: application/sdp 11696 Content-length: 163 11697 Server: PhonyServer/1.0 11698 Date: Wed, 23 Jan 2013 15:36:52 +0000 11699 Expires: Thu, 24 Jan 2013 15:36:52 +0000 11701 v=0 11702 o=- 872653257 872653257 IN IP4 192.0.2.5 11703 s=mu-law wave file 11704 i=audio test 11705 c=IN IP4 0.0.0.0 11706 t=0 0 11707 a=control: * 11708 m=audio 0 RTP/AVP 0 11709 a=control:streamid=0 11711 C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 11712 Transport: RTP/AVP/UDP;unicast; 11713 dest_addr=":6970"/":6971";mode="PLAY" 11714 CSeq: 2 11715 User-Agent: PhonyClient/1.2 11716 Accept-Ranges: npt, smpte, clock 11718 S->C: RTSP/2.0 200 OK 11719 Transport: RTP/AVP/UDP;unicast; 11720 dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; 11721 src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; 11722 mode="PLAY";ssrc=EAB98712 11723 CSeq: 2 11724 Session: 2034820394 11725 Expires: Thu, 24 Jan 2013 15:36:52 +0000 11726 Server: PhonyServer/1.0 11727 Date: Wed, 23 Jan 2013 15:36:52 +0000 11728 Accept-Ranges: npt 11729 Media-Properties: Random-Acces=0.5, Immutable, Unlimited 11731 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 11732 CSeq: 3 11733 User-Agent: PhonyClient/1.2 11734 Session: 2034820394 11736 S->C: RTSP/2.0 200 OK 11737 CSeq: 3 11738 Server: PhonyServer/1.0 11739 Date: Wed, 23 Jan 2013 15:36:52 +0000 11740 Session: 2034820394 11741 Range: npt=0-600 11742 Seek-Style: RAP 11743 RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" 11744 ssrc=0D12F123:seq=981888;rtptime=3781123 11746 Note the different URI in the SETUP command, and then the switch back 11747 to the aggregate URI in the PLAY command. This makes complete sense 11748 when there are multiple streams with aggregate control, but is less 11749 than intuitive in the special case where the number of streams is 11750 one. However, the server has declared the aggregated control URI in 11751 the SDP and therefore this is legal. 11753 In this case, it is also required that servers accept implementations 11754 that use the non-aggregated interpretation and use the individual 11755 media URI, like this: 11757 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 11758 CSeq: 3 11759 User-Agent: PhonyClient/1.2 11760 Session: 2034820394 11762 A.6. Live Media Presentation Using Multicast 11764 The media server M chooses the multicast address and port. Here, it 11765 is assumed that the web server only contains a pointer to the full 11766 description, while the media server M maintains the full description. 11768 C->W: GET /sessions.html HTTP/1.1 11769 Host: www.example.com 11771 W->C: HTTP/1.1 200 OK 11772 Content-Type: text/html 11774 11775 ... 11776 11777 Streamed Live Music performance 11778 ... 11779 11781 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 11782 CSeq: 1 11783 Supported: play.basic, play.scale 11784 User-Agent: PhonyClient/1.2 11786 M->C: RTSP/2.0 200 OK 11787 CSeq: 1 11788 Content-Type: application/sdp 11789 Content-Length: 183 11790 Server: PhonyServer/1.0 11791 Date: Wed, 23 Jan 2013 15:36:52 +0000 11792 Supported: play.basic 11794 v=0 11795 o=- 2890844526 2890842807 IN IP4 192.0.2.5 11796 s=RTSP Session 11797 t=0 0 11798 m=audio 3456 RTP/AVP 0 11799 c=IN IP4 233.252.0.54/16 11800 a=control: rtsp://live.example.com/concert/audio 11801 a=range:npt=0- 11803 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 11804 CSeq: 2 11805 Transport: RTP/AVP;multicast; 11806 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11807 Accept-Ranges: npt, smpte, clock 11808 User-Agent: PhonyClient/1.2 11810 M->C: RTSP/2.0 200 OK 11811 CSeq: 2 11812 Server: PhonyServer/1.0 11813 Date: Wed, 23 Jan 2013 15:36:52 +0000 11814 Transport: RTP/AVP;multicast; 11815 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 11816 ;ssrc=4D12AB92/0DF876A3 11817 Session: 0456804596 11818 Accept-Ranges: npt, clock 11819 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 11821 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 11822 CSeq: 3 11823 Session: 0456804596 11824 User-Agent: PhonyClient/1.2 11826 M->C: RTSP/2.0 200 OK 11827 CSeq: 3 11828 Server: PhonyServer/1.0 11829 Date: Wed, 23 Jan 2013 15:36:52 +0000 11830 Session: 0456804596 11831 Seek-Style: Next 11832 Range:npt=1256- 11833 RTP-Info: url="rtsp://live.example.com/concert/audio" 11834 ssrc=0D12F123:seq=1473; rtptime=80000 11836 A.7. Capability Negotiation 11838 This example illustrates how the client and server determine their 11839 capability to support a special feature, in this case "play.scale". 11840 The server, through the clients request and the included Supported 11841 header, learns the client supports RTSP 2.0, and also supports the 11842 playback time scaling feature of RTSP. The server's response 11843 contains the following feature related information to the client; it 11844 supports the basic media delivery functions (play.basic), the 11845 extended functionality of time scaling of content (play.scale), and 11846 one "example.com" proprietary feature (com.example.flight). The 11847 client also learns the methods supported (Public header) by the 11848 server for the indicated resource. 11850 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 11851 CSeq: 1 11852 Supported: play.basic, play.scale 11853 User-Agent: PhonyClient/1.2 11855 S->C: RTSP/2.0 200 OK 11856 CSeq: 1 11857 Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER 11858 Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE 11859 Server: PhonyServer/2.0 11860 Supported: play.basic, play.scale, com.example.flight 11862 When the client sends its SETUP request it tells the server that it 11863 requires support of the play.scale feature for this session by 11864 including the Require header. 11866 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 11867 CSeq: 3 11868 User-Agent: PhonyClient/1.2 11869 Transport: RTP/AVP/UDP;unicast; 11870 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", 11871 RTP/AVP/TCP;unicast;interleaved=0-1 11872 Require: play.scale 11873 Accept-Ranges: npt, smpte, clock 11874 User-Agent: PhonyClient/1.2 11876 S->C: RTSP/2.0 200 OK 11877 CSeq: 3 11878 Session: 12345678 11879 Transport: RTP/AVP/UDP;unicast; 11880 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; 11881 src_addr="198.51.100.5:5000"/"198.51.100.5:5001" 11882 Server: PhonyServer/2.0 11883 Accept-Ranges: npt, smpte 11884 Media-Properties: Random-Access=0.8, Immutable, Unlimited 11886 Appendix B. RTSP Protocol State Machine 11888 The RTSP session state machine describes the behavior of the protocol 11889 from RTSP session initialization through RTSP session termination. 11890 It is probably easiest to think of this as the server's state and 11891 then view the the client as needing to track what it believes the 11892 server's state will be based on sent or received RTSP messages. Thus 11893 in most cases the state tables below can be read as: If the client 11894 does X, and assuming it fulfills any pre-requisite(s), the (server) 11895 state will move to the new state and the indicated response will 11896 returned. However, there are also server to client notifications or 11897 requests, where the action describes what notification or request 11898 will occur, its requisites and what new state will result after the 11899 server has received the response, as well as describing the client's 11900 response to the action. 11902 The State machine is defined on a per session basis which is uniquely 11903 identified by the RTSP session identifier. The session may contain 11904 one or more media streams depending on state. If a single media 11905 stream is part of the session it is in non-aggregated control. If 11906 two or more is part of the session it is in aggregated control. 11908 The below state machine is an informative description of the 11909 protocols behavior. In case of ambiguity with the earlier parts of 11910 this specification, the description in the earlier parts take 11911 precedence. 11913 B.1. States 11915 The state machine contains three states, described below. For each 11916 state there exists a table which shows which requests and events are 11917 allowed and whether they will result in a state change. 11919 Init: Initial state no session exists. 11921 Ready: Session is ready to start playing. 11923 Play: Session is playing, i.e., sending media stream data in the 11924 direction S->C. 11926 B.2. State variables 11928 This representation of the state machine needs more than its state to 11929 work. A small number of variables are also needed and they are 11930 explained below. 11932 NRM: The number of media streams part of this session. 11934 RP: Resume point, the point in the presentation time line at which 11935 a request to continue playing will resume from. A time format 11936 for the variable is not mandated. 11938 B.3. Abbreviations 11940 To make the state tables more compact a number of abbreviations are 11941 used, which are explained below. 11943 IFI: IF Implemented. 11945 md: Media 11946 PP: Pause Point, the point in the presentation time line at which 11947 the presentation was paused. 11949 Prs: Presentation, the complete multimedia presentation. 11951 RedP: Redirect Point, the point in the presentation time line at 11952 which a REDIRECT was specified to occur. 11954 SES: Session. 11956 B.4. State Tables 11958 This section contains a table for each state. The table contains all 11959 the requests and events that this state is allowed to act on. The 11960 events which are method names are, unless noted, requests with the 11961 given method in the direction client to server (C->S). In some cases 11962 there exist one or more requisite. The response column tells what 11963 type of response actions should be performed. Possible actions that 11964 are requested for an event include: response codes, e.g., 200, 11965 headers that need to be included in the response, setting of state 11966 variables, or setting of other session related parameters. The new 11967 state column tells which state the state machine changes to. 11969 The response to a valid request meeting the requisites is normally a 11970 2xx (SUCCESS) unless otherwise noted in the response column. The 11971 exceptions need to be given a response according to the response 11972 column. If the request does not meet the requisite, is erroneous or 11973 some other type of error occurs, the appropriate response code is to 11974 be sent. If the response code is a 4xx the session state is 11975 unchanged. A response code of 3rr will result in that the session is 11976 ended and its state is changed to Init. A response code of 304 11977 results in no state change. However, there are restrictions to when 11978 a 3rr response may be used. A 5xx response does not result in any 11979 change of the session state, except if the error is not possible to 11980 recover from. A unrecoverable error results in the ending of the 11981 session. As it in the general case can't be determined if it was a 11982 unrecoverable error or not the client will be required to test. In 11983 the case that the next request after a 5xx is responded with 454 11984 (Session Not Found) the client knows that the session has ended. For 11985 any request message that cannot be responded to within the time 11986 defined in Section 10.4, a 100 response must be sent. 11988 The server will timeout the session after the period of time 11989 specified in the SETUP response, if no activity from the client is 11990 detected. Therefore there exists a timeout event for all states 11991 except Init. 11993 In the case that NRM = 1 the presentation URI is equal to the media 11994 URI or a specified presentation URI. For NRM > 1 the presentation 11995 URI needs to be other than any of the medias that are part of the 11996 session. This applies to all states. 11998 +---------------+-----------------+---------------------------------+ 11999 | Event | Prerequisite | Response | 12000 +---------------+-----------------+---------------------------------+ 12001 | DESCRIBE | Needs REDIRECT | 3rr, Redirect | 12002 | | | | 12003 | DESCRIBE | | 200, Session description | 12004 | | | | 12005 | OPTIONS | Session ID | 200, Reset session timeout | 12006 | | | timer | 12007 | | | | 12008 | OPTIONS | | 200 | 12009 | | | | 12010 | SET_PARAMETER | Valid parameter | 200, change value of parameter | 12011 | | | | 12012 | GET_PARAMETER | Valid parameter | 200, return value of parameter | 12013 +---------------+-----------------+---------------------------------+ 12015 Table 13: None state-machine changing events 12017 The methods in Table 13 do not have any effect on the state machine 12018 or the state variables. However, some methods do change other 12019 session related parameters, for example SET_PARAMETER which will set 12020 the parameter(s) specified in its body. Also all of these methods 12021 that allow Session header will also update the keep-alive timer for 12022 the session. 12024 +------------------+----------------+-----------+-------------------+ 12025 | Action | Requisite | New State | Response | 12026 +------------------+----------------+-----------+-------------------+ 12027 | SETUP | | Ready | NRM=1, RP=0.0 | 12028 | | | | | 12029 | SETUP | Needs Redirect | Init | 3rr Redirect | 12030 | | | | | 12031 | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | 12032 +------------------+----------------+-----------+-------------------+ 12034 Table 14: State: Init 12036 The initial state of the state machine, see Table 14 can only be left 12037 by processing a correct SETUP request. As seen in the table the two 12038 state variables are also set by a correct request. This table also 12039 shows that a correct SETUP can in some cases be redirected to another 12040 URI and/or server by a 3rr response. 12042 +-------------+------------------------+---------+------------------+ 12043 | Action | Requisite | New | Response | 12044 | | | State | | 12045 +-------------+------------------------+---------+------------------+ 12046 | SETUP | New URI | Ready | NRM +=1 | 12047 | | | | | 12048 | SETUP | URI Setup prior | Ready | Change transport | 12049 | | | | param | 12050 | | | | | 12051 | TEARDOWN | Prs URI, | Init | No session hdr, | 12052 | | | | NRM = 0 | 12053 | | | | | 12054 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 12055 | | | | NRM = 0 | 12056 | | | | | 12057 | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | 12058 | | | | -= 1 | 12059 | | | | | 12060 | PLAY | Prs URI, No range | Play | Play from RP | 12061 | | | | | 12062 | PLAY | Prs URI, Range | Play | According to | 12063 | | | | range | 12064 | | | | | 12065 | PLAY | md URI, NRM=1, Range | Play | According to | 12066 | | | | range | 12067 | | | | | 12068 | PLAY | md URI, NRM=1 | Play | Play from RP | 12069 | | | | | 12070 | PAUSE | Prs URI | Ready | Return PP | 12071 | | | | | 12072 | SC:REDIRECT | Terminate-Reason | Ready | Set RedP | 12073 | | | | | 12074 | SC:REDIRECT | No Terminate-Reason | Init | Session is | 12075 | | time parameter | | removed | 12076 | | | | | 12077 | Timeout | | Init | | 12078 | | | | | 12079 | RedP | | Init | TEARDOWN of | 12080 | reached | | | session | 12081 +-------------+------------------------+---------+------------------+ 12083 Table 15: State: Ready 12085 In the Ready state, see Table 15, some of the actions are depending 12086 on the number of media streams (NRM) in the session, i.e., aggregated 12087 or non-aggregated control. A SETUP request in the Ready state can 12088 either add one more media stream to the session or, if the media 12089 stream (same URI) already is part of the session, change the 12090 transport parameters. TEARDOWN is depending on both the Request-URI 12091 and the number of media streams within the session. If the Request- 12092 URI is the presentations URI the whole session is torn down. If a 12093 media URI is used in the TEARDOWN request and more than one media 12094 exists in the session, the session will remain and a session header 12095 is returned in the response. If only a single media stream remains 12096 in the session when performing a TEARDOWN with a media URI the 12097 session is removed. The number of media streams remaining after 12098 tearing down a media stream determines the new state. 12100 +----------------+-----------------------+--------+-----------------+ 12101 | Action | Requisite | New | Response | 12102 | | | State | | 12103 +----------------+-----------------------+--------+-----------------+ 12104 | PAUSE | Prs URI | Ready | Set RP to | 12105 | | | | present point | 12106 | | | | | 12107 | End of media | All media | Play | Set RP = End of | 12108 | | | | media | 12109 | | | | | 12110 | End of range | | Play | Set RP = End of | 12111 | | | | range | 12112 | | | | | 12113 | PLAY | Prs URI, No range | Play | Play from | 12114 | | | | present point | 12115 | | | | | 12116 | PLAY | Prs URI, Range | Play | According to | 12117 | | | | range | 12118 | | | | | 12119 | SC:PLAY_NOTIFY | | Play | 200 | 12120 | | | | | 12121 | SETUP | New URI | Play | 455 | 12122 | | | | | 12123 | SETUP | Setuped URI | Play | 455 | 12124 | | | | | 12125 | SETUP | Setuped URI, IFI | Play | Change | 12126 | | | | transport | 12127 | | | | param. | 12128 | | | | | 12129 | TEARDOWN | Prs URI | Init | No session hdr | 12130 | | | | | 12131 | TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | 12132 | | | | NRM=0 | 12133 | | | | | 12134 | TEARDOWN | md URI | Play | 455 | 12135 | | | | | 12136 | SC:REDIRECT | Terminate Reason with | Play | Set RedP | 12137 | | Time parameter | | | 12138 | | | | | 12139 | SC:REDIRECT | | Init | Session is | 12140 | | | | removed | 12141 | | | | | 12142 | RedP reached | | Init | TEARDOWN of | 12143 | | | | session | 12144 | | | | | 12145 | Timeout | | Init | Stop Media | 12146 | | | | playout | 12147 +----------------+-----------------------+--------+-----------------+ 12149 Table 16: State: Play 12151 The Play state table, see Table 16, contains a number of requests 12152 that need a presentation URI (labeled as Prs URI) to work on (i.e., 12153 the presentation URI has to be used as the Request-URI). This is due 12154 to the exclusion of non-aggregated stream control in sessions with 12155 more than one media stream. 12157 To avoid inconsistencies between the client and server, automatic 12158 state transitions are avoided. This can be seen at for example "End 12159 of media" event when all media has finished playing, the session 12160 still remains in Play state. An explicit PAUSE request needs to be 12161 sent to change the state to Ready. It may appear that there exist 12162 automatic transitions in "RedP reached" and "PP reached". However, 12163 they are requested and acknowledged before they take place. The time 12164 at which the transition will happen is known by looking at the range 12165 header. If the client sends a request close in time to these 12166 transitions it needs to be prepared for receiving error messages, as 12167 the state may or may not have changed. 12169 Appendix C. Media Transport Alternatives 12171 This section defines how certain combinations of protocols, profiles 12172 and lower transports are used. This includes the usage of the 12173 Transport header's source and destination address parameters 12174 "src_addr" and "dest_addr". 12176 C.1. RTP 12178 This section defines the interaction of RTSP with respect to the RTP 12179 protocol [RFC3550]. It also defines any necessary media transport 12180 signaling with regards to RTP. 12182 The available RTP profiles and lower layer transports are described 12183 below along with rules on signaling the available combinations. 12185 C.1.1. AVP 12187 The usage of the "RTP Profile for Audio and Video Conferences with 12188 Minimal Control" [RFC3551] when using RTP for media transport over 12189 different lower layer transport protocols is defined below in regards 12190 to RTSP. 12192 One such case is defined within this document: the use of embedded 12193 (interleaved) binary data as defined in Section 14. The usage of 12194 this method is indicated by including the "interleaved" parameter. 12196 When using embedded binary data the "src_addr" and "dest_addr" MUST 12197 NOT be used. This addressing and multiplexing is used as defined 12198 with use of channel numbers and the interleaved parameter. 12200 C.1.2. AVP/UDP 12202 This part describes sending of RTP [RFC3550] over lower transport 12203 layer UDP [RFC0768] according to the profile "RTP Profile for Audio 12204 and Video Conferences with Minimal Control" defined in RFC 3551 12205 [RFC3551]. Implementations of RTP/AVP/UDP MUST implement RTCP 12206 (Appendix C.1.6). This profile requires one or two uni- or bi- 12207 directional UDP flows per media stream. The first UDP flow is for 12208 RTP and the second is for RTCP. Multiplexing of RTP and RTCP 12209 (Appendix C.1.6.4) MAY be used, in which case a single UDP flow is 12210 used for both parts. Embedding of RTP data with the RTSP messages, 12211 in accordance with Section 14, SHOULD NOT be performed when RTSP 12212 messages are transported over unreliable transport protocols, like 12213 UDP [RFC0768]. 12215 The RTP/UDP and RTCP/UDP flows can be established using the Transport 12216 header's "src_addr", and "dest_addr" parameters. 12218 In RTSP PLAY mode, the transmission of RTP packets from client to 12219 server is unspecified. The behavior in regards to such RTP packets 12220 MAY be defined in future. 12222 The "src_addr" and "dest_addr" parameters are used in the following 12223 way for media delivery and playback mode, i.e., Mode=PLAY: 12225 o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 12226 2 address specifications. Note that two address specifications 12227 MAY be provided even if RTP and RTCP multiplexing is negotiated. 12229 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 12230 contain either: 12232 * both an address and a port number, or 12233 * a port number without an address. 12235 o The first address specification given in either of the parameters 12236 applies to the RTP stream. The second specification if present 12237 applies to the RTCP stream, unless in case RTP and RTCP 12238 multiplexing is negotiated where both RTP and RTCP will use the 12239 first specification. 12241 o The RTP/UDP packets from the server to the client MUST be sent to 12242 the address and port given by the first address specification of 12243 the "dest_addr" parameter. 12245 o The RTCP/UDP packets from the server to the client MUST be sent to 12246 the address and port given by the second address specification of 12247 the "dest_addr" parameter, unless RTP and RTCP multiplexing has 12248 been negotiated, in which case RTCP MUST be sent to the first 12249 address specification. If no second pair is specified and RTP and 12250 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12252 o The RTCP/UDP packets from the client to the server MUST be sent to 12253 the address and port given by the second address specification of 12254 the "src_addr" parameter, unless RTP and RTCP multiplexing has 12255 been negotiated, in which case RTCP MUST be sent to the first 12256 address specification. If no second pair is specified and RTP and 12257 RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent. 12259 o The RTP/UDP packets from the client to the server MUST be sent to 12260 the address and port given by the first address specification of 12261 the "src_addr" parameter. 12263 o RTP and RTCP Packets SHOULD be sent from the corresponding 12264 receiver port, i.e., RTCP packets from the server should be sent 12265 from the "src_addr" parameters second address port pair, unless 12266 RTP and RTCP multiplexing has been negotiated in which case the 12267 first address port pair is used. 12269 C.1.3. AVPF/UDP 12271 The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ 12272 AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. 12273 All that is defined for AVP MUST also apply for AVPF. 12275 The usage of AVPF is indicated by the media initialization protocol 12276 used. In the case of SDP it is indicated by media lines (m=) 12277 containing the profile RTP/AVPF. That SDP MAY also contain further 12278 AVPF related SDP attributes configuring the AVPF session regarding 12279 reporting interval and feedback messages to be used [RFC4585]. This 12280 configuration MUST be followed. 12282 C.1.4. SAVP/UDP 12284 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" 12285 [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions 12286 using RTP. All that is defined for AVP MUST also apply for SAVP. 12288 The usage of SRTP requires that a security context is established. 12289 The default key-management unless otherwise signalled SHALL be MIKEY 12290 in RSA-R mode as defined in Appendix C.1.4.1, and not according to 12291 the procedure defined in "Key Management Extensions for Session 12292 Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" 12293 [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY 12294 message in SDP, thus both requiring the usage of the DESCRIBE method 12295 and forcing the server to keep state for clients performing DESCRIBE 12296 in anticipation that they might require key management. 12298 MIKEY is selected as default method for establishing SRTP 12299 cryptographic context within an RTSP session as it can be embedded in 12300 the RTSP messages, while still ensuring confidentiality of content of 12301 the keying material, even when using hop-by-hop TLS security for the 12302 RTSP messages. This method does also support pipelining of the RTSP 12303 messages. 12305 C.1.4.1. MIKEY Key Establishment 12307 This method for using MIKEY [RFC3830] to establish the SRTP 12308 cryptographic context is initiated in the client's SETUP request, and 12309 the server's response to the SETUP carries the MIKEY response. This 12310 ensures that the crypto context establishment happens simultaneously 12311 with the establishment of the media stream being protected. By using 12312 MIKEY's RSA-R mode [RFC4738] the client can be the initiator and 12313 still allow the server to set the parameters in accordance with the 12314 actual media stream. 12316 The SRTP cryptographic context establishment is done according to the 12317 following process: 12319 1. The client determines that SAVP or SAVPF shall be used from 12320 media description format, e.g., SDP. If no other key management 12321 method is explicitly signalled, then MIKEY SHALL be used as 12322 defined herein. The use of SRTP with RTSP is only defined with 12323 MIKEY with keys established as defined in this Section. Future 12324 documents may define how an RTSP implementation treats SDP that 12325 indicates some other key mechanism to be used. The need for 12326 such specification include [RFC4567] that is not defined for use 12327 in RTSP 2.0 within this document. 12329 2. The client SHALL establish a TLS connection for RTSP messages, 12330 directly or hop by hop with the server. If hop-by-hop TLS 12331 security is used, the User method SHALL be indicated in the 12332 Accept-Credentials header. Note that using hop-by-hop does 12333 allow the proxy to insert itself as a man in the middle also in 12334 the MIKEY exchange by providing one of its certificates, rather 12335 than the server's in the Connection-Credentials header. The 12336 client SHALL therefore validate the server certificate. 12338 3. The client retrieves the server's certificate from a direct TLS 12339 connection, or if hop by hop from Connection-Credentials header. 12340 The client then checks that the server certificate is valid and 12341 belongs to the server. 12343 4. The client forms the MIKEY Initiator message using RSA-R mode in 12344 unicast mode as specified in [RFC4738]. The client SHOULD use 12345 the same certificate for TLS and in MIKEY to enable the server 12346 to bind the two together. The client's certificate SHALL be 12347 included in the MIKEY message. The client SHALL indicate its 12348 SRTP capabilities in the message. 12350 5. The MIKEY message from the previous step is base64 [RFC4648] 12351 encoded and becomes the value of the MIKEY parameter that is 12352 included in the transport specification(s) that specifies a SRTP 12353 based profile (SAVP, SAVPF) in the SETUP request. 12355 6. Any proxy encountering the MIKEY parameter SHALL forward it 12356 without modification. A proxy requiring to understand transport 12357 specification which doesn't support SAVP/SAVPF with MIKEY will 12358 discard the whole transport specification. Most types of 12359 proxies can easily support SAVP and SAVPF with MIKEY. If 12360 possible bypassing the proxy should be tried. 12362 7. The server upon receiving the SETUP request, will need to decide 12363 upon the transport specification to use, if multiple are 12364 included by the client. In the determination of which transport 12365 specifications that are supported and preferred, the server 12366 SHOULD decode the MIKEY message to take the embedded SRTP 12367 parameters into account. If all transport specs require SRTP 12368 but no MIKEY parameter or other supported keying method is 12369 included, the server SHALL respond with 403. 12371 8. Upon generating a response the following outcomes can occur: 12373 * A transport spec not using SRTP and MIKEY is selected. Thus 12374 the response will not contain any MIKEY parameter. 12376 * A transport spec using SRTP and MIKEY is selected but an 12377 error is encountered in the MIKEY processing. In that case 12378 an RTSP error response code of 466 "Key Management Error" 12379 SHALL be used. A MIKEY message describing the error MAY be 12380 included. 12382 * A transport spec using SRTP and MIKEY is selected and a MIKEY 12383 response message can be created. The server SHOULD use the 12384 same certificate for TLS and in MIKEY to enable client to 12385 bind the two together. If a different certificate is used it 12386 SHALL be included in the MIKEY message. It is RECOMMENDED 12387 that the envelope key cache type is set to 'Cache' and that a 12388 single envelope key is reused for all MIKEY messages to the 12389 client. That message is included in the MIKEY parameter part 12390 of the single selected transport specification in the SETUP 12391 response. The server will set the SRTP parameters as 12392 preferred for this media stream within the supported range by 12393 the client. 12395 9. The server transmits the SETUP response back to the client. 12397 10. The client receives the SETUP response and if the response code 12398 indicates a successful request it decodes the MIKEY message and 12399 establishes the SRTP cryptographic context from the parameters 12400 in the MIKEY response. 12402 In the above method the client's certificate may be self-signed in 12403 cases where the client's identity is not necessary to authenticate 12404 and the security goal is only to ensure that the RTSP signaling 12405 client is the same as the one receiving the SRTP security context. 12407 C.1.5. SAVPF/UDP 12409 The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback 12410 (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in 12411 RTSP sessions using RTP. All that is defined for AVPF MUST also 12412 apply for SAVPF. 12414 The usage of SRTP requires that a cryptographic context is 12415 established. The default mechanism for establishing that security 12416 association is to use MIKEY[RFC3830] with RTSP as defined in 12417 Appendix C.1.4.1. 12419 C.1.6. RTCP usage with RTSP 12421 RTCP has several usages when RTP is used for media transport as 12422 explained below. Due to that RTCP MUST be supported if an RTSP agent 12423 handles RTP. 12425 C.1.6.1. Media synchronization 12427 RTCP provides media synchronization and clock drift compensation. 12428 The initial media synchronization is available from RTP-Info header. 12429 However, to be able to handle any clock drift between the media 12430 streams, RTCP is needed. 12432 C.1.6.2. RTSP Session keep-alive 12434 RTCP traffic from the RTSP client to the RTSP server MUST function as 12435 keep-alive. This requires an RTSP server supporting RTP to use the 12436 received RTCP packets as indications that the client desires the 12437 related RTSP session to be kept alive. 12439 C.1.6.3. Bit-rate adaption 12441 RTCP Receiver reports and any additional feedback from the client 12442 MUST be used to adapt the bit-rate used over the transport for all 12443 cases when RTP is sent over UDP. An RTP sender without reserved 12444 resources MUST NOT use more than its fair share of the available 12445 resources. This can be determined by comparing on short to medium 12446 term (some seconds) the used bit-rate and adapt it so that the RTP 12447 sender sends at a bit-rate comparable to what a TCP sender would 12448 achieve on average over the same path. 12450 To ensure that the implementation's adaptation mechanism has a well 12451 defined outer envelope, all implementations using a non-congestion 12452 controlled unicast transport protocol, like UDP, MUST implement 12453 Multimedia Congestion Control: Circuit Breakers for Unicast RTP 12454 Sessions [I-D.ietf-avtcore-rtp-circuit-breakers]. 12456 C.1.6.4. RTP and RTCP Multiplexing 12458 RTSP can be used to negotiate the usage of RTP and RTCP multiplexing 12459 as described in [RFC5761]. This allows servers and client to reduce 12460 the amount of resources required for the session by only requiring 12461 one underlying transport stream per media stream instead of two when 12462 using RTP and RTCP. This lessens the server port consumption and 12463 also the necessary state and keep-alive work when operating across 12464 Network and Address Translators [RFC2663]. 12466 Content must be prepared with some consideration for RTP and RTCP 12467 multiplexing, mainly ensuring that the RTP payload types used do not 12468 collide with the ones used for RTCP packet types. This option likely 12469 needs explicit support from the content unless the RTP payload types 12470 can be remapped by the server and that is correctly reflected in the 12471 session description. Beyond that support of this feature should come 12472 at little cost and much gain. 12474 It is recommended that if the content and server support RTP and RTCP 12475 multiplexing that this is indicated in the session description, for 12476 example using the SDP attribute "a=rtcp-mux". If the SDP message 12477 contains the a=rtcp-mux attribute for a media stream, the server MUST 12478 support RTP and RTCP multiplexing. If indicated or otherwise desired 12479 by the client it can include the Transport parameter "RTCP-mux" in 12480 any transport specification where it desires to use RTCP-mux. The 12481 server will indicate if it supports RTCP-mux. Servers and Clients 12482 SHOULD support RTP and RTCP multiplexing. 12484 For capability exchange, an RTSP feature tag for RTP and RTCP 12485 multiplexing is defined: "setup.rtp.rtcp.mux". 12487 To minimize the risk of negotiation failure while using RTP and RTCP 12488 multiplexing some recommendations are here provided. If the session 12489 description includes explicit indication of support (a=rtcp-mux in 12490 SDP), then a RTSP agent can safely create a SETUP request with a 12491 transport specification with only a single dest_addr parameter 12492 address specification. If no such explicit indication is provided, 12493 then even if the feature tag "setup.rtp.rtcp.mux" is provided in a 12494 Supported header by the RTSP server or the feature tag included in 12495 the Required header in the SETUP request, the media resource may not 12496 support RTP and RTCP multiplexing. Thus, to maximize the probability 12497 of successful negotiation the RTSP agent is recommended to include 12498 two dest_addr parameter address specifications in the first or first 12499 set (if pipelining is used) of SETUP request(s) for any media 12500 resource aggregate. That way the RTSP server can either accept RTP 12501 and RTCP multiplexing and only use the first address specification, 12502 and if not use both specifications. The RTSP agent after having 12503 received the response for a successful negotiation of the usage of 12504 RTP and RTCP multiplexing, can then release the resources associated 12505 with the second address specification. 12507 C.2. RTP over TCP 12509 Transport of RTP over TCP can be done in two ways: over independent 12510 TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP 12511 connection. In both cases the protocol MUST be "rtp" and the lower 12512 layer MUST be TCP. The profile may be any of the above specified 12513 ones; AVP, AVPF, SAVP or SAVPF. 12515 C.2.1. Interleaved RTP over TCP 12517 The use of embedded (interleaved) binary data transported on the RTSP 12518 connection is possible as specified in Section 14. When using this 12519 declared combination of interleaved binary data the RTSP messages 12520 MUST be transported over TCP. TLS may or may not be used. If TLS is 12521 used both RTSP messages and the binary data will be protected by TLS. 12523 One should, however, consider that this will result in all media 12524 streams go through any proxy. Using independent TCP connections can 12525 avoid that issue. 12527 C.2.2. RTP over independent TCP 12529 In this Appendix, it is described the sending of RTP [RFC3550] over 12530 lower transport layer TCP [RFC0793] according to "Framing Real-time 12531 Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over 12532 Connection-Oriented Transport" [RFC4571]. This Appendix adapts the 12533 guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work 12534 with RTSP. 12536 A client codes the support of RTP over independent TCP by specifying 12537 an RTP/AVP/TCP transport option without an interleaved parameter in 12538 the Transport line of a SETUP request. This transport option MUST 12539 include the "unicast" parameter. 12541 If the client wishes to use RTP with RTCP, two address specifications 12542 needs to be included in the dest_addr parameter. If the client 12543 wishes to use RTP without RTCP, one address specification is included 12544 in the dest_addr parameter. If the client wishes to multiplex RTP 12545 and RTCP on a single transport flow (see Appendix C.1.6.4), one or 12546 two address specifications are included in the dest_addr parameter in 12547 addition to the RTCP-mux transport parameter. Two address 12548 specifications are allowed to allow successful negotiation when 12549 server or content can't support RTP and RTCP multiplexing. Ordering 12550 rules of dest_addr ports follow the rules for RTP/AVP/UDP. 12552 If the client wishes to play the active role in initiating the TCP 12553 connection, it MAY set the "setup" parameter (See Section 18.54) on 12554 the Transport line to be "active", or it MAY omit the setup 12555 parameter, as active is the default. If the client signals the 12556 active role, the ports in the address specifications in the dest_addr 12557 parameter MUST be set to 9 (the discard port). 12559 If the client wishes to play the passive role in TCP connection 12560 initiation, it MUST set the "setup" parameter on the Transport line 12561 to be "passive". If the client is able to assume the active or the 12562 passive role, it MUST set the "setup" parameter on the Transport line 12563 to be "actpass". In either case, the dest_addr parameter's address 12564 specification port value for RTP MUST be set to the TCP port number 12565 on which the client is expecting to receive the TCP connection for 12566 RTP, and the dest_addr's address specification port value for RTCP 12567 MUST be set to the TCP port number on which the client is expecting 12568 to receive the TCP connection for RTCP. In the case that the client 12569 wishes to multiplex RTP and RTCP on a single transport flow, the 12570 RTCP-mux parameter is included and one or two dest_addr parameter 12571 address specifications are included, as mentioned earlier in this 12572 section. 12574 If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 12575 server decides to accept this requested option, the 2xx reply MUST 12576 contain a Transport option that specifies RTP/AVP/TCP (without using 12577 the interleaved parameter, and with using the unicast parameter). 12578 The dest_addr parameter value MUST be echoed from the parameter value 12579 in the client request unless the destination address (only port) was 12580 not provided in which case the server MAY include the source address 12581 of the RTSP TCP connection with the port number unchanged. 12583 In addition, the server reply MUST set the setup parameter on the 12584 Transport line, to indicate the role the server will play in the 12585 connection setup. Permissible values are "active" (if a client set 12586 "setup" to "passive" or "actpass") and "passive" (if a client set 12587 "setup" to "active" or "actpass"). 12589 If a server sets "setup" to "passive", the "src_addr" in the reply 12590 MUST indicate the ports the server is willing to receive an TCP 12591 connection for RTP and (if the client requested an TCP connection for 12592 RTCP by specifying two dest_addr address specifications) an TCP/RTCP 12593 connection. If a server sets "setup" to "active", the ports 12594 specified in "src_addr" address specifications MUST be set to 9. The 12595 server MAY use the "ssrc" parameter, following the guidance in 12596 Section 18.54. The server sets only one address specification in the 12597 case that the client has indicated only a single address 12598 specification or in case RTP and RTCP multiplexing was requested and 12599 accepted by server. Port ordering for src_addr follows the rules for 12600 RTP/AVP/UDP. 12602 Servers MUST support taking the passive role and MAY support taking 12603 the active role. Servers with a public IP address take the passive 12604 role, thus enabling clients behind NATs and Firewalls a better chance 12605 of successful connect to the server by actively connecting outwards. 12606 Therefore the clients are RECOMMENDED to take the active role. 12608 After sending (receiving) a 2xx reply for a SETUP method for a non- 12609 interleaved RTP/AVP/TCP media stream, the active party SHOULD 12610 initiate the TCP connection as soon as possible. The client MUST NOT 12611 send a PLAY request prior to the establishment of all the TCP 12612 connections negotiated using SETUP for the session. In case the 12613 server receives a PLAY request in a session that has not yet 12614 established all the TCP connections, it MUST respond using the 464 12615 "Data Transport Not Ready Yet" (Section 17.4.29) error code. 12617 Once the PLAY request for a media resource transported over non- 12618 interleaved RTP/AVP/TCP occurs, media begins to flow from server to 12619 client over the RTP TCP connection, and RTCP packets flow 12620 bidirectionally over the RTCP TCP connection. Unless RTP and RTCP 12621 multiplexing has been negotiated in which case RTP and RTCP will flow 12622 over a common TCP connection. As in the RTP/UDP case, client to 12623 server traffic on a RTP only TCP session is unspecified by this memo. 12624 The packets that travel on these connections MUST be framed using the 12625 protocol defined in [RFC4571], not by the framing defined for 12626 interleaving RTP over the RTSP connection defined in Section 14. 12628 A successful PAUSE request for a media being transported over RTP/AVP 12629 /TCP pauses the flow of packets over the connections, without closing 12630 the connections. A successful TEARDOWN request signals that the TCP 12631 connections for RTP and RTCP are to be closed by the RTSP client as 12632 soon as possible. 12634 Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be 12635 ambiguous in the following way: does the client wish to open up new 12636 TCP connection for RTP or RTCP for the URI, or does the client wish 12637 to continue using the existing TCP connections? The client SHOULD 12638 use the "connection" parameter (defined in Section 18.54) on the 12639 Transport line to make its intention clear (by setting "connection" 12640 to "new" if new connections are needed, and by setting "connection" 12641 to "existing" if the existing connections are to be used). After a 12642 2xx reply for a SETUP request for a new connection, parties should 12643 close the pre-existing connections, after waiting a suitable period 12644 for any stray RTP or RTCP packets to arrive. 12646 The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that 12647 a security association is established. The default mechanism for 12648 establishing that security association is to use MIKEY[RFC3830] with 12649 RTSP as defined Appendix C.1.4.1. 12651 Below, a rewriten version of the example "media on demand" 12652 (Appendix A.1) shows the use of RTP/AVP/TCP non-interleaved: 12654 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 12655 CSeq: 1 12656 User-Agent: PhonyClient/1.2 12658 M->C: RTSP/2.0 200 OK 12659 CSeq: 1 12660 Server: PhonyServer/1.0 12661 Date: Wed, 23 Jan 2013 15:36:52 +0000 12662 Content-Type: application/sdp 12663 Content-Length: 227 12664 Content-Base: rtsp://example.com/twister.3gp/ 12665 Expires: Thu, 24 Jan 2013 15:36:52 +0000 12667 v=0 12668 o=- 2890844256 2890842807 IN IP4 198.51.100.34 12669 s=RTSP Session 12670 i=An Example of RTSP Session Usage 12671 e=adm@example.com 12672 c=IN IP4 0.0.0.0 12673 a=control: * 12674 a=range:npt=00:00:00-00:10:34.10 12675 t=0 0 12676 m=audio 0 RTP/AVP 0 12677 a=control: trackID=1 12679 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 12680 CSeq: 2 12681 User-Agent: PhonyClient/1.2 12682 Require: play.basic 12683 Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; 12684 setup=active;connection=new 12685 Accept-Ranges: npt, smpte, clock 12687 M->C: RTSP/2.0 200 OK 12688 CSeq: 2 12689 Server: PhonyServer/1.0 12690 Transport: RTP/AVP/TCP;unicast; 12691 dest_addr=":9"/":9"; 12692 src_addr="198.51.100.5:53478"/"198.51.100:54091"; 12693 setup=passive;connection=new;ssrc=93CB001E 12694 Session: 12345678 12695 Expires: Thu, 24 Jan 2013 15:36:52 +0000 12696 Date: Wed, 23 Jan 2013 15:36:52 +0000 12697 Accept-Ranges: npt 12698 Media-Properties: Random-Access=0.8, Immutable, Unlimited 12700 C->M: TCP Connection Establishment x2 12702 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 12703 CSeq: 4 12704 User-Agent: PhonyClient/1.2 12705 Range: npt=30- 12706 Session: 12345678 12708 M->C: RTSP/2.0 200 OK 12709 CSeq: 4 12710 Server: PhonyServer/1.0 12711 Date: Wed, 23 Jan 2013 15:36:54 +0000 12712 Session: 12345678 12713 Range: npt=30-623.10 12714 Seek-Style: First-Prior 12715 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" 12716 ssrc=4F312DD8:seq=54321;rtptime=2876889 12718 C.3. Handling Media Clock Time Jumps in the RTP Media Layer 12720 RTSP allows media clients to control selected, non-contiguous 12721 sections of media presentations, rendering those streams with an RTP 12722 media layer [RFC3550]. Two cases occur, the first is when a new PLAY 12723 request replaces an old ongoing request and the new request results 12724 in a jump in the media. This should produce in the RTP layer a 12725 continuous media stream. A client may also directly following a 12726 completed PLAY request perform a new PLAY request. This will result 12727 in some gap in the media layer. The below text will look into both 12728 cases. 12730 A PLAY request that replaces an ongoing request allows the media 12731 layer rendering the RTP stream without being affected by jumps in 12732 media clock time. The RTP timestamps for the new media range is set 12733 so that they become continuous with the previous media range in the 12734 previous request. The RTP sequence number for the first packet in 12735 the new range will be the next following the last packet in the 12736 previous range, i.e., monotonically increasing. The goal is to allow 12737 the media rendering layer to work without interruption or 12738 reconfiguration across the jumps in media clock. This should be 12739 possible in all cases of replaced PLAY requests for media that has 12740 random-access properties. In this case care is needed to align 12741 frames or similar media dependent structures. 12743 In cases where jumps in media clock time are a result of RTSP 12744 signaling operations arriving after a completed PLAY operation, the 12745 request timing will result in that media becomes non-continuous. The 12746 server becomes unable to send the media so that it arrives timely and 12747 still carry timestamps to make the media stream continuous. In these 12748 cases the server will produce RTP streams where there are gaps in the 12749 RTP timeline for the media. In such cases, if the media has frame 12750 structure, aligning the timestamp for the next frame with the 12751 previous structure reduces the burden to render this media. The gap 12752 should represent the time the server hasn't been serving media, e.g., 12753 the time between the end of the media stream or a PAUSE request and 12754 the new PLAY request. In these cases the RTP sequence number would 12755 normally be monotonically increasing across the gap. 12757 For RTSP sessions with media that lacks random access properties, 12758 such as live streams, any media clock jump is commonly the result of 12759 a correspondingly long pause of delivery. The RTP timestamp will 12760 have increased in direct proportion to the duration of the paused 12761 delivery. Note also that in this case the RTP sequence number should 12762 be the next packet number. If not, the RTCP packet loss reporting 12763 will indicate as loss all packets not received between the point of 12764 pausing and later resuming. This may trigger congestion avoidance 12765 mechanisms. An allowed exception from the above recommendation on 12766 monotonically increasing RTP sequence number is live media streams, 12767 likely being relayed. In this case, when the client resumes 12768 delivery, it will get the media that is currently being delivered to 12769 the server itself. For this type of basic delivery of live streams 12770 to multiple users over unicast, individual rewriting of RTP sequence 12771 numbers becomes quite a burden. For solutions that anyway caches 12772 media, timeshifts, etc, the rewriting should be a minor issue. 12774 The goal when handling jumps in media clock time is that the provided 12775 stream is continuous without gaps in RTP timestamp or sequence 12776 number. However, when delivery has been halted for some reason the 12777 RTP timestamp when resuming MUST represent the duration the delivery 12778 was halted. RTP sequence number MUST generally be the next number, 12779 i.e., monotonically increasing modulo 65536. For media resources 12780 with the properties Time-Progressing and Time-Duration=0.0 the server 12781 MAY create RTP media streams with RTP sequence number jumps in them 12782 due to the client first halting delivery and later resuming it (PAUSE 12783 and then later PLAY). However, servers utilizing this exception must 12784 take into consideration the resulting RTCP receiver reports that 12785 likely contain loss reports for all the packets part of the 12786 discontinuity. A client cannot rely on that a server will align when 12787 resuming playing even if it is RECOMMENDED. The RTP-Info header will 12788 provide information on how the server acts in each case. 12790 One cannot assume that the RTSP client can communicate with the 12791 RTP media agent, as the two may be independent processes. If the 12792 RTP timestamp shows the same gap as the NPT, the media agent will 12793 assume that there is a pause in the presentation. If the jump in 12794 NPT is large enough, the RTP timestamp may roll over and the media 12795 agent may believe later packets to be duplicates of packets just 12796 played out. Having the RTP timestamp jump will also affect the 12797 RTCP measurements based on this. 12799 As an example, assume an RTP timestamp frequency of 8000 Hz, a 12800 packetization interval of 100 ms and an initial sequence number and 12801 timestamp of zero. 12803 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12804 CSeq: 4 12805 Session: abcdefgh 12806 Range: npt=10-15 12807 User-Agent: PhonyClient/1.2 12809 S->C: RTSP/2.0 200 OK 12810 CSeq: 4 12811 Session: abcdefgh 12812 Range: npt=10-15 12813 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12814 ssrc=0D12F123:seq=0;rtptime=0 12816 The ensuing RTP data stream is depicted below: 12818 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12819 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12820 . . . 12821 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 12823 Upon the completion of the requested delivery the server sends a 12824 PLAY_NOTIFY 12825 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 12826 CSeq: 5 12827 Notify-Reason: end-of-stream 12828 Request-Status: cseq=4 status=200 reason="OK" 12829 Range: npt=-15 12830 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 12831 ssrc=0D12F123:seq=49;rtptime=39200 12832 Session: abcdefgh 12834 C->S: RTSP/2.0 200 OK 12835 CSeq: 5 12836 User-Agent: PhonyClient/1.2 12838 Upon the completion of the play range, the client follows up with a 12839 request to PLAY from a new NPT. 12841 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12842 CSeq: 6 12843 Session: abcdefg 12844 Range: npt=18-20 12845 User-Agent: PhonyClient/1.2 12847 S->C: RTSP/2.0 200 OK 12848 CSeq: 6 12849 Session: abcdefg 12850 Range: npt=18-20 12851 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12852 ssrc=0D12F123:seq=50;rtptime=40100 12854 The ensuing RTP data stream is depicted below: 12856 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 12857 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 12858 . . . 12859 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 12861 In this example, first, NPT 10 through 15 is played, then the client 12862 requests the server to skip ahead and play NPT 18 through 20. The 12863 first segment is presented as RTP packets with sequence numbers 0 12864 through 49 and timestamp 0 through 39,200. The second segment 12865 consists of RTP packets with sequence number 50 through 69, with 12866 timestamps 40,100 through 55,200. While there is a gap in the NPT, 12867 there is no gap in the sequence number space of the RTP data stream. 12869 The RTP timestamp gap is present in the above example due to the time 12870 it takes to perform the second play request, in this case 12.5 ms 12871 (100/8000). 12873 C.4. Handling RTP Timestamps after PAUSE 12875 During a PAUSE / PLAY interaction in an RTSP session, the duration of 12876 time for which the RTP transmission was halted MUST be reflected in 12877 the RTP timestamp of each RTP stream. The duration can be calculated 12878 for each RTP stream as the time elapsed from when the last RTP packet 12879 was sent before the PAUSE request was received and when the first RTP 12880 packet was sent after the subsequent PLAY request was received. The 12881 duration includes all latency incurred and processing time required 12882 to complete the request. 12884 The RTP RFC [RFC3550] states that: The RTP timestamp for each unit 12885 [packet] would be related to the wallclock time at which the unit 12886 becomes current on the virtual presentation timeline. 12888 In order to satisfy the requirements of [RFC3550], the RTP 12889 timestamp space needs to increase continuously with real time. 12890 While this is not optimal for stored media, it is required for RTP 12891 and RTCP to function as intended. Using a continuous RTP 12892 timestamp space allows the same timestamp model for both stored 12893 and live media and allows better opportunity to integrate both 12894 types of media under a single control. 12896 As an example, assume a clock frequency of 8000 Hz, a packetization 12897 interval of 100 ms and an initial sequence number and timestamp of 12898 zero. 12900 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12901 CSeq: 4 12902 Session: abcdefg 12903 Range: npt=10-15 12905 User-Agent: PhonyClient/1.2 12907 S->C: RTSP/2.0 200 OK 12908 CSeq: 4 12909 Session: abcdefg 12910 Range: npt=10-15 12911 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12912 ssrc=0D12F123:seq=0;rtptime=0 12914 The ensuing RTP data stream is depicted below: 12916 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 12917 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 12918 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 12919 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 12921 The client then sends a PAUSE request: 12923 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 12924 CSeq: 5 12925 Session: abcdefg 12926 User-Agent: PhonyClient/1.2 12928 S->C: RTSP/2.0 200 OK 12929 CSeq: 5 12930 Session: abcdefg 12931 Range: npt=10.4-15 12933 20 seconds elapse and then the client sends a PLAY request. In 12934 addition the server requires 15 ms to process the request: 12936 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 12937 CSeq: 6 12938 Session: abcdefg 12939 User-Agent: PhonyClient/1.2 12941 S->C: RTSP/2.0 200 OK 12942 CSeq: 6 12943 Session: abcdefg 12944 Range: npt=10.4-15 12945 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" 12946 ssrc=0D12F123:seq=4;rtptime=164400 12948 The ensuing RTP data stream is depicted below: 12950 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 12951 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 12952 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 12954 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 12955 server. After 20 seconds a PLAY is received by the server which 12956 takes 15 ms to process. The duration of time for which the session 12957 was paused is reflected in the RTP timestamp of the RTP packets sent 12958 after this PLAY request. 12960 A client can use the RTSP range header and RTP-Info header to map NPT 12961 time of a presentation with the RTP timestamp. 12963 Note: In RFC 2326 [RFC2326], this matter was not clearly defined and 12964 was misunderstood commonly. However, for RTSP 2.0 it is expected 12965 that this will be handled correctly and no exception handling will be 12966 required. 12968 Note further: It may be required to reset some of the state to ensure 12969 the correct media decoding and the usual jitter-buffer handling when 12970 issuing a PLAY request. 12972 C.5. RTSP / RTP Integration 12974 For certain data types, tight integration between the RTSP layer and 12975 the RTP layer will be necessary. This by no means precludes the 12976 above restrictions. Combined RTSP/RTP media clients should use the 12977 RTP-Info field to determine whether incoming RTP packets were sent 12978 before or after a seek or before or after a PAUSE. 12980 C.6. Scaling with RTP 12982 For scaling (see Section 18.46), RTP timestamps should correspond to 12983 the rendering timing. For example, when playing video recorded at 30 12984 frames/second at a scale of two and speed (Section 18.50) of one, the 12985 server would drop every second frame to maintain and deliver video 12986 packets with the normal timestamp spacing of 3,000 per frame, but NPT 12987 would increase by 1/15 second for each video frame. 12989 Note: The above scaling puts requirements on the media codec or a 12990 media stream to support it. For example motion JPEG or other non- 12991 predictive video coding can easier handle the above example. 12993 C.7. Maintaining NPT synchronization with RTP timestamps 12995 The client can maintain a correct display of NPT (Normal Play Time) 12996 by noting the RTP timestamp value of the first packet arriving after 12997 repositioning. The sequence parameter of the RTP-Info 12998 (Section 18.45) header provides the first sequence number of the next 12999 segment. 13001 C.8. Continuous Audio 13003 For continuous audio, the server SHOULD set the RTP marker bit at the 13004 beginning of serving a new PLAY request or at jumps in timeline. 13005 This allows the client to perform playout delay adaptation. 13007 C.9. Multiple Sources in an RTP Session 13009 Note that more than one SSRC MAY be sent in the media stream. If it 13010 happens all sources are expected to be rendered simultaneously. 13012 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session 13014 The RTCP BYE message indicates the end of use of a given SSRC. If 13015 all sources leave an RTP session, it can, in most cases, be assumed 13016 to have ended. Therefore, a client or server MUST NOT send an RTCP 13017 BYE message until it has finished using a SSRC. A server SHOULD keep 13018 using a SSRC until the RTP session is terminated. Prolonging the use 13019 of a SSRC allows the established synchronization context associated 13020 with that SSRC to be used to synchronize subsequent PLAY requests 13021 even if the PLAY response is late. 13023 An SSRC collision with the SSRC that transmits media does also have 13024 consequences, as it will normally force the media sender to change 13025 its SSRC in accordance with the RTP specification [RFC3550]. 13026 However, an RTSP server may wait and see if the client changes and 13027 thus resolve the conflict to minimize the impact. As media sender 13028 SSRC change will result in a loss of synchronization context, and 13029 require any receiver to wait for RTCP sender reports for all media 13030 requiring synchronization before being able to play out synchronized. 13031 Due to these reasons a client joining a session should take care to 13032 not select the same SSRC(s) as the server indicates in the ssrc 13033 Transport header parameter. Any SSRC signalled in the Transport 13034 header MUST be avoided. A client detecting a collision prior to 13035 sending any RTP or RTCP messages SHALL also select a new SSRC. 13037 C.11. Future Additions 13039 It is the intention that any future protocol or profile regarding 13040 media delivery and lower transport should be easy to add to RTSP. 13041 This section provides the necessary steps that needs to be meet. 13043 The following things needs to be considered when adding a new 13044 protocol or profile for use with RTSP: 13046 o The protocol or profile needs to define a name tag representing 13047 it. This tag is required to be an ABNF "token" to be possible to 13048 use in the Transport header specification. 13050 o The useful combinations of protocol, profiles and lower layer 13051 transport for this extension needs to be defined. For each 13052 combination declare the necessary parameters to use in the 13053 Transport header. 13055 o For new media protocols the interaction with RTSP needs to be 13056 addressed. One important factor will be the media 13057 synchronization. It may be necessary to have new headers similar 13058 to RTP info to carry this information. 13060 o Discuss congestion control for media, especially if transport 13061 without built in congestion control is used. 13063 See the IANA section (Section 22) for information how to register new 13064 attributes. 13066 Appendix D. Use of SDP for RTSP Session Descriptions 13068 The Session Description Protocol (SDP, [RFC4566]) may be used to 13069 describe streams or presentations in RTSP. This description is 13070 typically returned in reply to a DESCRIBE request on a URI from a 13071 server to a client, or received via HTTP from a server to a client. 13073 This appendix describes how an SDP file determines the operation of 13074 an RTSP session. Thus, it is worth pointing out that the 13075 interpretation of the SDP is done in the context of the SDP receiver, 13076 which is the one being configured. This is the same as in SAP 13077 [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each 13078 SDP is interpreted in the context of the agent providing it. 13080 SDP as is provides no mechanism by which a client can distinguish, 13081 without human guidance, between several media streams to be rendered 13082 simultaneously and a set of alternatives (e.g., two audio streams 13083 spoken in different languages). The SDP extension "Grouping of Media 13084 Lines in the Session Description Protocol (SDP)" [RFC5888] provides 13085 such functionality to some degree. Appendix D.4 describes the usage 13086 of SDP media line grouping for RTSP. 13088 D.1. Definitions 13090 The terms "session-level", "media-level" and other key/attribute 13091 names and values used in this appendix are to be used as defined in 13092 SDP[RFC4566]: 13094 D.1.1. Control URI 13096 The "a=control:" attribute is used to convey the control URI. This 13097 attribute is used both for the session and media descriptions. If 13098 used for individual media, it indicates the URI to be used for 13099 controlling that particular media stream. If found at the session 13100 level, the attribute indicates the URI for aggregate control 13101 (presentation URI). The session level URI MUST be different from any 13102 media level URI. The presence of a session level control attribute 13103 MUST be interpreted as support for aggregated control. The control 13104 attribute MUST be present on media level unless the presentation only 13105 contains a single media stream, in which case the attribute MAY be 13106 present on the session level only and then also apply to that single 13107 media stream. 13109 ABNF for the attribute is defined in Section 20.3. 13111 Example: 13113 a=control:rtsp://example.com/foo 13115 This attribute MAY contain either relative or absolute URIs, 13116 following the rules and conventions set out in RFC 3986 [RFC3986]. 13117 Implementations MUST look for a base URI in the following order: 13119 1. the RTSP Content-Base field; 13121 2. the RTSP Content-Location field; 13123 3. the RTSP Request-URI. 13125 If this attribute contains only an asterisk (*), then the URI MUST be 13126 treated as if it were an empty embedded URI, and thus inherit the 13127 entire base URI. 13129 Note, RFC 2326 was very unclear on the processing of relative URI 13130 and several RTSP 1.0 implementations at the point of publishing 13131 this document did not perform RFC 3986 processing to determine the 13132 resulting URI, instead simple concatenation is common. To avoid 13133 this issue completely it is recommended to use absolute URI in the 13134 SDP. 13136 The URI handling for SDPs from container files need special 13137 consideration. For example let's assume that a container file has 13138 the URI: "rtsp://example.com/container.mp4". Let's further assume 13139 this URI is the base URI, and that there is an absolute media level 13140 URI: "rtsp://example.com/container.mp4/trackID=2". A relative media 13141 level URI that resolves in accordance with RFC 3986 [RFC3986] to the 13142 above given media URI is: "container.mp4/trackID=2". It is usually 13143 not desirable to need to include in or modify the SDP stored within 13144 the container file with the server local name of the container file. 13145 To avoid this, one can modify the base URI used to include a trailing 13146 slash, e.g., "rtsp://example.com/container.mp4/". In this case the 13147 relative URI for the media will only need to be: "trackID=2". 13148 However, this will also mean that using "*" in the SDP will result in 13149 control URI including the trailing slash, i.e., "rtsp://example.com/ 13150 container.mp4/". 13152 Note: The usage of TrackID in the above is not a standardized 13153 form, but one example out of several similar strings such as 13154 TrackID, Track_ID, StreamID that is used by different server 13155 vendors to indicate a particular piece of media inside a container 13156 file. 13158 D.1.2. Media Streams 13160 The "m=" field is used to enumerate the streams. It is expected that 13161 all the specified streams will be rendered with appropriate 13162 synchronization. If the session is over multicast, the port number 13163 indicated SHOULD be used for reception. The client MAY try to 13164 override the destination port, through the Transport header. The 13165 servers MAY allow this, the response will indicate if allowed or not. 13166 If the session is unicast, the port numbers are the ones RECOMMENDED 13167 by the server to the client, about which receiver ports to use; the 13168 client MUST still include its receiver ports in its SETUP request. 13169 The client MAY ignore this recommendation. If the server has no 13170 preference, it SHOULD set the port number value to zero. 13172 The "m=" lines contain information about which transport protocol, 13173 profile, and possibly lower-layer is to be used for the media stream. 13174 The combination of transport, profile and lower layer, like RTP/AVP/ 13175 UDP needs to be defined for how to be used with RTSP. The currently 13176 defined combinations are defined in Appendix C, further combinations 13177 MAY be specified. 13179 Example: 13181 m=audio 0 RTP/AVP 31 13183 D.1.3. Payload Type(s) 13185 The payload type(s) are specified in the "m=" line. In case the 13186 payload type is a static payload type from RFC 3551 [RFC3551], no 13187 other information may be required. In case it is a dynamic payload 13188 type, the media attribute "rtpmap" is used to specify what the media 13189 is. The "encoding name" within the "rtpmap" attribute may be one of 13190 those specified in [RFC4856], or a media type registered with IANA 13191 according to [RFC4855], or an experimental encoding as specified in 13192 SDP [RFC4566]). Codec-specific parameters are not specified in this 13193 field, but rather in the "fmtp" attribute described below. 13195 The selection of the RTP payload type numbers used may be required to 13196 consider RTP and RTCP Multiplexing [RFC5761] if that is to be 13197 supported by the server. 13199 D.1.4. Format-Specific Parameters 13201 Format-specific parameters are conveyed using the "fmtp" media 13202 attribute. The syntax of the "fmtp" attribute is specific to the 13203 encoding(s) that the attribute refers to. Note that some of the 13204 format specific parameters may be specified outside of the fmtp 13205 parameters, like for example the "ptime" attribute for most audio 13206 encodings. 13208 D.1.5. Directionality of media stream 13210 The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" 13211 provide instructions about the direction the media streams flow 13212 within a session. When using RTSP the SDP can be delivered to a 13213 client using either RTSP DESCRIBE or a number of RTSP external 13214 methods, like HTTP, FTP, and email. Based on this the SDP applies to 13215 how the RTSP client will see the complete session. Thus media 13216 streams delivered from the RTSP server to the client, would be given 13217 the "a=recvonly" attribute. 13219 "a=recvonly" in a SDP provided to the RTSP client indicates that 13220 media delivery will only occur in the direction from the RTSP server 13221 to the client. SDP provided to the RTSP client that lacks any of the 13222 directionality attributes (a=recvonly, a=sendonly, a=sendrecv) would 13223 be interpreted as having a=sendrecv. At the time of writing there 13224 exist no RTSP mode suitable for media traffic in the direction from 13225 the RTSP client to the server. Thus all RTSP SDP SHOULD have 13226 a=recvonly attribute when using the PLAY mode defined in this 13227 document. If future modes are defined for media in client to server 13228 direction, then usage of a=sendonly, or a=sendrecv may become 13229 suitable to indicate intended media directions. 13231 D.1.6. Range of Presentation 13233 The "a=range" attribute defines the total time range of the stored 13234 session or an individual media. Non-seekable live sessions can be 13235 indicated as specified below, while the length of live sessions can 13236 be deduced from the "t=" and "r=" SDP parameters. 13238 The attribute is both a session and a media level attribute. For 13239 presentations that contain media streams of the same duration, the 13240 range attribute SHOULD only be used at session-level. In case of 13241 different lengths the range attribute MUST be given at media level 13242 for all media, and SHOULD NOT be given at session level. If the 13243 attribute is present at both media level and session level the media 13244 level values MUST be used. 13246 Note: Usually one will specify the same length for all media, even if 13247 there isn't media available for the full duration on all media. 13248 However, that requires that the server accepts PLAY requests within 13249 that range. 13251 Servers MUST take care to provide RTSP Range (see Section 18.40) 13252 values that are consistent with what is presented in the SDP for the 13253 content. There is no reason for non dynamic content, like media 13254 clips provided on demand to have inconsistent values. Inconsistent 13255 values between the SDP and the actual values for the content handled 13256 by the server is likely to generate some failure, like 457 "Invalid 13257 Range", in case the client uses PLAY requests with a Range header. 13258 In case the content is dynamic in length and it is infeasible to 13259 provide a correct value in the SDP the server is recommended to 13260 describe this as non-seekable content (see below). The server MAY 13261 override that property in the response to a PLAY request using the 13262 correct values in the Range header. 13264 The unit is specified first, followed by the value range. The units 13265 and their values are as defined in Section 4.4.1, Section 4.4.2 and 13266 Section 4.4.3 and MAY be extended with further formats. Any open 13267 ended range (start-), i.e., without stop range, is of unspecified 13268 duration and MUST be considered as non-seekable content unless this 13269 property is overridden. Multiple instances carrying different clock 13270 formats MAY be included at either session or media level. 13272 ABNF for the attribute is defined in Section 20.3. 13274 Examples: 13276 a=range:npt=0-34.4368 13277 a=range:clock=19971113T211503Z-19971113T220300Z 13278 Non seekable stream of unknown duration: 13279 a=range:npt=0- 13281 D.1.7. Time of Availability 13283 The "t=" field defines when the SDP is valid. For on-demand content 13284 the server SHOULD indicate a stop time value for which it guarantees 13285 the description to be valid, and a start time that is equal to or 13286 before the time at which the DESCRIBE request was received. It MAY 13287 also indicate start and stop times of 0, meaning that the session is 13288 always available. 13290 For sessions that are of live type, i.e., specific start time, 13291 unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD 13292 be used to indicate the start time of the event. The stop time 13293 SHOULD be given so that the live event will have ended at that time, 13294 while still not be unnecessary long into the future. 13296 D.1.8. Connection Information 13298 In SDP used with RTSP, the "c=" field contains the destination 13299 address for the media stream. If a multicast address is specified 13300 the client SHOULD use this address in any SETUP request as 13301 destination address, including any additional parameters, such as 13302 TTL. For on-demand unicast streams and some multicast streams, the 13303 destination address MAY be specified by the client via the SETUP 13304 request, thus overriding any specified address. To identify streams 13305 without a fixed destination address, where the client is required to 13306 specify a destination address, the "c=" field SHOULD be set to a null 13307 value. For addresses of type "IP4", this value MUST be "0.0.0.0", 13308 and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be 13309 written as "::"), i.e., the unspecified address according to RFC 4291 13310 [RFC4291]. 13312 D.1.9. Message Body Tag 13314 The optional "a=mtag" attribute identifies a version of the session 13315 description. It is opaque to the client. SETUP requests may include 13316 this identifier in the If-Match field (see Section 18.24) to only 13317 allow session establishment if this attribute value still corresponds 13318 to that of the current description. The attribute value is opaque 13319 and may contain any character allowed within SDP attribute values. 13321 ABNF for the attribute is defined in Section 20.3. 13323 Example: 13325 a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a" 13327 One could argue that the "o=" field provides identical 13328 functionality. However, it does so in a manner that would put 13329 constraints on servers that need to support multiple session 13330 description types other than SDP for the same piece of media 13331 content. 13333 D.2. Aggregate Control Not Available 13335 If a presentation does not support aggregate control no session level 13336 "a=control:" attribute is specified. For a SDP with multiple media 13337 sections specified, each section will have its own control URI 13338 specified via the "a=control:" attribute. 13340 Example: 13342 v=0 13343 o=- 2890844256 2890842807 IN IP4 192.0.2.56 13344 s=I came from a web page 13345 e=adm@example.com 13346 c=IN IP4 0.0.0.0 13347 t=0 0 13348 m=video 8002 RTP/AVP 31 13349 a=control:rtsp://audio.example.com/movie.aud 13350 m=audio 8004 RTP/AVP 3 13351 a=control:rtsp://video.example.com/movie.vid 13353 Note that the position of the control URI in the description implies 13354 that the client establishes separate RTSP control sessions to the 13355 servers audio.example.com and video.example.com. 13357 It is recommended that an SDP file contains the complete media 13358 initialization information even if it is delivered to the media 13359 client through non-RTSP means. This is necessary as there is no 13360 mechanism to indicate that the client should request more detailed 13361 media stream information via DESCRIBE. 13363 D.3. Aggregate Control Available 13365 In this scenario, the server has multiple streams that can be 13366 controlled as a whole. In this case, there are both a media-level 13367 "a=control:" attributes, which are used to specify the stream URIs, 13368 and a session-level "a=control:" attribute which is used as the 13369 Request-URI for aggregate control. If the media-level URI is 13370 relative, it is resolved to absolute URIs according to Appendix D.1.1 13371 above. 13373 Example: 13375 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 13376 CSeq: 1 13377 User-Agent: PhonyClient/1.2 13379 M->C: RTSP/2.0 200 OK 13380 CSeq: 1 13381 Date: Wed, 23 Jan 2013 15:36:52 +0000 13382 Expires: Wed, 23 Jan 2013 16:36:52 +0000 13383 Content-Type: application/sdp 13384 Content-Base: rtsp://example.com/movie/ 13385 Content-Length: 227 13387 v=0 13388 o=- 2890844256 2890842807 IN IP4 192.0.2.211 13389 s=I contain 13390 i= 13391 e=adm@example.com 13392 c=IN IP4 0.0.0.0 13393 a=control:* 13394 t=0 0 13395 m=video 8002 RTP/AVP 31 13396 a=control:trackID=1 13397 m=audio 8004 RTP/AVP 3 13398 a=control:trackID=2 13400 In this example, the client is recommended to establish a single RTSP 13401 session to the server, and uses the URIs rtsp://example.com/movie/ 13402 trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video 13403 and audio streams, respectively. The URI rtsp://example.com/movie/, 13404 which is resolved from the "*", controls the whole presentation 13405 (movie). 13407 A client is not required to issue SETUP requests for all streams 13408 within an aggregate object. Servers should allow the client to ask 13409 for only a subset of the streams. 13411 D.4. Grouping of Media Lines in SDP 13413 For some types of media it is desirable to express a relationship 13414 between various media components, for instance, for lip 13415 synchronization or Scalable Video Codec (SVC) [RFC5583]. This 13416 relationship is expressed on the SDP level by grouping of media 13417 lines, as described in [RFC5888] and can be exposed to RTSP. 13419 For RTSP it is mainly important to know how to handle grouped medias 13420 received by means of SDP, i.e., if the media are under aggregate 13421 control (see Appendix D.3) or if aggregate control is not available 13422 (see Appendix D.2). 13424 It is RECOMMENDED that grouped medias are handled by aggregate 13425 control, to give the client the ability to control either the whole 13426 presentation or single medias. 13428 D.5. RTSP external SDP delivery 13430 There are some considerations that need to be made when the session 13431 description is delivered to the client outside of RTSP, for example 13432 via HTTP or email. 13434 First of all, the SDP needs to contain absolute URIs, since relative 13435 will in most cases not work as the delivery will not correctly 13436 forward the base URI. 13438 The writing of the SDP session availability information, i.e., "t=" 13439 and "r=", needs to be carefully considered. When the SDP is fetched 13440 by the DESCRIBE method, the probability that it is valid is very 13441 high. However, the same is much less certain for SDPs distributed 13442 using other methods. Therefore the publisher of the SDP should take 13443 care to follow the recommendations about availability in the SDP 13444 specification [RFC4566] in Section 4.2. 13446 Appendix E. RTSP Use Cases 13448 This Appendix describes the most important and considered use cases 13449 for RTSP. They are listed in descending order of importance in 13450 regards to ensuring that all necessary functionality is present. 13451 This specification only fully supports usage of the two first. Also 13452 in these first two cases, there are special cases or exceptions that 13453 are not supported without extensions, e.g., the redirection of media 13454 delivery to another address than the controlling agent's (client's). 13456 E.1. On-demand Playback of Stored Content 13458 An RTSP capable server stores content suitable for being streamed to 13459 a client. A client desiring playback of any of the stored content 13460 uses RTSP to set up the media transport required to deliver the 13461 desired content. RTSP is then used to initiate, halt and manipulate 13462 the actual transmission (playout) of the content. RTSP is also 13463 required to provide necessary description and synchronization 13464 information for the content. 13466 The above high level description can be broken down into a number of 13467 functions that RTSP needs to be capable of. 13469 Presentation Description: Provide initialization information about 13470 the presentation (content); for example, which media codecs are 13471 needed for the content. Other information that is important 13472 includes the number of media streams the presentation contains, 13473 the transport protocols used for the media streams, and 13474 identifiers for these media streams. This information is 13475 required before setup of the content is possible and to 13476 determine if the client is even capable of using the content. 13478 This information need not be sent using RTSP; other external 13479 protocols can be used to transmit the transport presentation 13480 descriptions. Two good examples are the use of HTTP [RFC2616] 13481 or email to fetch or receive presentation descriptions like SDP 13482 [RFC4566] 13484 Setup: Set up some or all of the media streams in a presentation. 13485 The setup itself consists of selecting the protocol for media 13486 transport and the necessary parameters for the protocol, like 13487 addresses and ports. 13489 Control of Transmission: After the necessary media streams have been 13490 established the client can request the server to start 13491 transmitting the content. The client must be allowed to start 13492 or stop the transmission of the content at arbitrary times. 13493 The client must also be able to start the transmission at any 13494 point in the timeline of the presentation. 13496 Synchronization: For media transport protocols like RTP [RFC3550] it 13497 might be beneficial to carry synchronization information within 13498 RTSP. This may be due to either the lack of inter-media 13499 synchronization within the protocol itself, or the potential 13500 delay before the synchronization is established (which is the 13501 case for RTP when using RTCP). 13503 Termination: Terminate the established contexts. 13505 For this use case there are a number of assumptions about how it 13506 works. These are: 13508 On-Demand content: The content is stored at the server and can be 13509 accessed at any time during a time period when it is intended 13510 to be available. 13512 Independent sessions: A server is capable of serving a number of 13513 clients simultaneously, including from the same piece of 13514 content at different points in that presentations time-line. 13516 Unicast Transport: Content for each individual client is transmitted 13517 to them using unicast traffic. 13519 It is also possible to redirect the media traffic to a different 13520 destination than that of the agent controlling the traffic. However, 13521 allowing this without appropriate mechanisms for checking that the 13522 destination approves of this allows for distributed denial of service 13523 attacks (DDoS). 13525 E.2. Unicast Distribution of Live Content 13527 This use case is similar to the above on-demand content case (see 13528 Appendix E.1) the difference is the nature of the content itself. 13529 Live content is continuously distributed as it becomes available from 13530 a source; i.e., the main difference from on-demand is that one starts 13531 distributing content before the end of it has become available to the 13532 server. 13534 In many cases the consumer of live content is only interested in 13535 consuming what actually happens "now"; i.e., very similar to 13536 broadcast TV. However, in this case it is assumed that there exists 13537 no broadcast or multicast channel to the users, and instead the 13538 server functions as a distribution node, sending the same content to 13539 multiple receivers, using unicast traffic between server and client. 13540 This unicast traffic and the transport parameters are individually 13541 negotiated for each receiving client. 13543 Another aspect of live content is that it often has a very limited 13544 time of availability, as it is only available for the duration of the 13545 event the content covers. An example of such a live content could be 13546 a music concert which lasts 2 hour and starts at a predetermined 13547 time. Thus there is a need to announce when and for how long the 13548 live content is available. 13550 In some cases, the server providing live content may be saving some 13551 or all of the content to allow clients to pause the stream and resume 13552 it from the paused point, or to "rewind" and play continuously from a 13553 point earlier than the live point. Hence, this use case does not 13554 necessarily exclude playing from other than the live point of the 13555 stream, playing with scales other than 1.0, etc. 13557 E.3. On-demand Playback using Multicast 13559 It is possible to use RTSP to request that media be delivered to a 13560 multicast group. The entity setting up the session (the controller) 13561 will then control when and what media is delivered to the group. 13562 This use case has some potential for denial of service attacks by 13563 flooding a multicast group. Therefore, a mechanism is needed to 13564 indicate that the group actually accepts the traffic from the RTSP 13565 server. 13567 An open issue in this use case is how one ensures that all receivers 13568 listening to the multicast or broadcast receives the session 13569 presentation configuring the receivers. This specification has to 13570 rely on an external solution to solve this issue. 13572 E.4. Inviting an RTSP server into a conference 13574 If one has an established conference or group session, it is possible 13575 to have an RTSP server distribute media to the whole group. 13576 Transmission to the group is simplest when controlled by a single 13577 participant or leader of the conference. Shared control might be 13578 possible, but would require further investigation and possibly 13579 extensions. 13581 This use case assumes that there exists either multicast or a 13582 conference focus that redistribute media to all participants. 13584 This use case is intended to be able to handle the following 13585 scenario: A conference leader or participant (hereafter called the 13586 controller) has some pre-stored content on an RTSP server that he 13587 wants to share with the group. The controller sets up an RTSP 13588 session at the streaming server for this content and retrieves the 13589 session description for the content. The destination for the media 13590 content is set to the shared multicast group or conference focus. 13591 When desired by the controller, he/she can start and stop the 13592 transmission of the media to the conference group. 13594 There are several issues with this use case that are not solved by 13595 this core specification for RTSP: 13597 Denial of service: To avoid an RTSP server from being an unknowing 13598 participant in a denial of service attack the server needs to 13599 be able to verify the destination's acceptance of the media. 13600 Such a mechanism to verify the approval of received media does 13601 not yet exist; instead, only policies can be used, which can be 13602 made to work in controlled environments. 13604 Distributing the presentation description to all participants in the 13605 group: 13606 To enable a media receiver to correctly decode the content 13607 the media configuration information needs to be distributed 13608 reliably to all participants. This will most likely require 13609 support from an external protocol. 13611 Passing control of the session: If it is desired to pass control 13612 of the RTSP session between the participants, some support 13613 will be required by an external protocol to exchange state 13614 information and possibly floor control of who is controlling 13615 the RTSP session. 13617 E.5. Live Content using Multicast 13619 This use case in its simplest form does not require any use of RTSP 13620 at all; this is what multicast conferences being announced with SAP 13621 [RFC2974] and SDP are intended to handle. However, in use cases 13622 where more advanced features like access control to the multicast 13623 session are desired, RTSP could be used for session establishment. 13625 A client desiring to join a live multicasted media session with 13626 cryptographic (encryption) access control could use RTSP in the 13627 following way. The source of the session announces the session and 13628 gives all interested an RTSP URI. The client connects to the server 13629 and requests the presentation description, allowing configuration for 13630 reception of the media. In this step it is possible for the client 13631 to use secured transport and any desired level of authentication; for 13632 example, for billing or access control. An RTSP link also allows for 13633 load balancing between multiple servers. 13635 If these were the only goals, they could be achieved by simply using 13636 HTTP. However, for cases where the sender likes to keep track of 13637 each individual receiver of a session, and possibly use the session 13638 as a side channel for distributing key-updates or other information 13639 on a per-receiver basis, and the full set of receivers is not known 13640 prior to the session start, the state establishment that RTSP 13641 provides can be beneficial. In this case a client would establish an 13642 RTSP session for this multicast group with the RTSP server. The RTSP 13643 server will not transmit any media, but instead will point to the 13644 multicast group. The client and server will be able to keep the 13645 session alive for as long as the receiver participates in the session 13646 thus enabling, for example, the server to push updates to the client. 13648 This use case will most likely not be able to be implemented without 13649 some extensions to the server-to-client push mechanism. Here the 13650 PLAY_NOTIFY method (see Section 13.5) with a suitable extension could 13651 provide clear benefits. 13653 Appendix F. Text format for Parameters 13655 A resource of type "text/parameters" consists of either 1) a list of 13656 parameters (for a query) or 2) a list of parameters and associated 13657 values (for an response or setting of the parameter). Each entry of 13658 the list is a single line of text. Parameters are separated from 13659 values by a colon. The parameter name MUST only use US-ASCII visible 13660 characters while the values are UTF-8 text strings. The media type 13661 registration form is in Section 22.16. 13663 There is a potential interoperability issue for this format. It was 13664 named in RFC 2326 but never defined, even if used in examples that 13665 hint at the syntax. This format matches the purpose and its syntax 13666 supports the examples provided. However, it goes further by allowing 13667 UTF-8 in the value part, thus usage of UTF-8 strings may not be 13668 supported. However, as individual parameters are not defined, the 13669 using application anyway needs to have out-of-band agreement or using 13670 feature-tag to determine if the end-point supports the parameters. 13672 The ABNF [RFC5234] grammar for "text/parameters" content is: 13674 file = *((parameter / parameter-value) CRLF) 13675 parameter = 1*visible-except-colon 13676 parameter-value = parameter *WSP ":" value 13677 visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":" 13678 value = *(TEXT-UTF8char / WSP) 13679 TEXT-UTF8char = 13680 WSP = ; Space or HTAB 13681 VCHAR = 13682 CRLF = 13684 Appendix G. Requirements for Unreliable Transport of RTSP 13686 This appendix provides guidance for those who want to implement RTSP 13687 messages over unreliable transports as has been defined in RTSP 1.0 13688 [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some 13689 basic information for the transport of RTSP messages over UDP. The 13690 information is being provided here as there has been at at least one 13691 commercial implementation and compatibility with that should be 13692 maintained. 13694 The following points should be considered for an interoperable 13695 implementation: 13697 o Requests shall be acknowledged by the receiver. If there is no 13698 acknowledgement, the sender may resend the same message after a 13699 timeout of one round-trip time (RTT). Any retransmissions due to 13700 lack of acknowledgement must carry the same sequence number as the 13701 original request. 13703 o The round-trip time can be estimated as in TCP (RFC 6298) 13704 [RFC6298], with an initial round-trip value of 500 ms. An 13705 implementation may cache the last RTT measurement as the initial 13706 value for future connections. 13708 o The Timestamp header (Section 18.53) is used to avoid the 13709 retransmission ambiguity problem [Stevens98]. 13711 o The registered default port for RTSP over UDP for the server is 13712 554. 13714 o RTSP messages can be carried over any lower-layer transport 13715 protocol that is 8-bit clean. 13717 o RTSP messages are vulnerable to bit errors and should not be 13718 subjected to them. 13720 o Source authentication, or at least validation that RTSP messages 13721 comes from the same entity becomes extremely important, as session 13722 hijacking may be substantially easier for RTSP message transport 13723 using an unreliable protocol like UDP than for TCP. 13725 There are two RTSP headers that are primarily intended for being used 13726 by the unreliable handling of RTSP messages and which will be 13727 maintained: 13729 o CSeq: See Section 18.20. It should be noted that the CSeq header 13730 is also required to match requests and responses independent 13731 whether a reliable or unreliable transport is used. 13733 o Timestamp: See Section 18.53 13735 Appendix H. Backwards Compatibility Considerations 13737 This section contains notes on issues about backwards compatibility 13738 with clients or servers being implemented according to RFC 2326 13739 [RFC2326]. Note that there exists no requirement to implement RTSP 13740 1.0; in fact this document recommend against it as it is difficult to 13741 do in an interoperable way. 13743 A server implementing RTSP/2.0 MUST include an RTSP-Version of RTSP/ 13744 2.0 in all responses to requests containing RTSP-Version RTSP/2.0. 13745 If a server receives an RTSP/1.0 request, it MAY respond with an RTSP 13746 /1.0 response if it chooses to support RFC 2326. If the server 13747 chooses not to support RFC 2326, it MUST respond with a 505 (RTSP 13748 Version not supported) status code. A server MUST NOT respond to an 13749 RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 response. 13751 Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- 13752 Version of 2.0 to determine whether a server supports RTSP/2.0. If 13753 the server responds with either an RTSP-Version of 1.0 or a status 13754 code of 505 (RTSP Version not supported), the client will have to use 13755 RTSP/1.0 requests if it chooses to support RFC 2326. 13757 H.1. Play Request in Play State 13759 The behavior in the server when a Play is received in Play state has 13760 changed (Section 13.4). In RFC 2326, the new PLAY request would be 13761 queued until the current Play completed. Any new PLAY request now 13762 takes effect immediately replacing the previous request. 13764 H.2. Using Persistent Connections 13766 Some server implementations of RFC 2326 maintain a one-to-one 13767 relationship between a connection and an RTSP session. Such 13768 implementations require clients to use a persistent connection to 13769 communicate with the server and when a client closes its connection, 13770 the server may remove the RTSP session. This is worth noting if a 13771 RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. 13773 Appendix I. Changes 13775 This appendix briefly lists the differences between RTSP 1.0 13776 [RFC2326] and RTSP 2.0 for an informational purpose. For 13777 implementers of RTSP 2.0 it is recommended to read carefully through 13778 this memo and not to rely on the list of changes below to adapt from 13779 RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards 13780 compatible with RTSP 1.0 [RFC2326] other than the version negotiation 13781 mechanism. 13783 I.1. Brief Overview 13785 The following protocol elements were removed in RTSP 2.0 compared to 13786 RTSP 1.0: 13788 o there is no section on minimal implementation anymore, but more 13789 the definition of RTSP 2.0 core; 13791 o the RECORD and ANNOUNCE methods and all related functionality 13792 (including 201 (Created) and 250 (Low On Storage Space) status 13793 codes); 13795 o the use of UDP for RTSP message transport was removed due to 13796 missing interest and to broken specification; 13798 o the use of PLAY method for keep-alive in Play state. 13800 The following protocol elements were added or changed in RTSP 2.0 13801 compared to RTSP 1.0: 13803 o RTSP session TEARDOWN from the server to the client; 13804 o IPv6 support; 13806 o extended IANA registries (e.g., transport headers parameters, 13807 transport-protocol, profile, lower-transport, and mode); 13809 o request pipelining for quick session start-up; 13811 o fully reworked state-machine; 13813 o RTSP messages now use URIs rather then URLs; 13815 o incorporated much of related HTTP text ([RFC2616]) in this memo, 13816 compared to just referencing the sections in HTTP, to avoid 13817 ambiguities; 13819 o the REDIRECT method was expanded and diversified for different 13820 situations; 13822 o Includes a new section about how to setup different media 13823 transport alternatives and their profiles, and lower layer 13824 protocols. This caused the appendix on RTP interaction to be 13825 moved there instead of being in the part which describes RTP. The 13826 section also includes guidelines what to consider when writing 13827 usage guidelines for new protocols and profiles; 13829 o Added an asynchronous notification method PLAY_NOTIFY. This 13830 method is used by the RTSP server to asynchronously notify clients 13831 about session changes while in Play state. To a limited extent 13832 this is comparable with some implementations of ANNOUNCE in RTSP 13833 1.0 not intended for Recording. 13835 I.2. Detailed List of Changes 13837 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 13838 defining RTSP 2.0. Note that this list does not reflect minor 13839 changes in wording or correction of typographical errors. 13841 o The section on minimal implementation was deleted without 13842 substitution. 13844 o The Transport header has been changed in the following way: 13846 * The ABNF has been changed to define that extensions are 13847 possible, and that unknown parameters result in that servers 13848 ignore the transport specification. 13850 * To prevent backwards compatibility issues, any extension or new 13851 parameter requires the usage of a feature-tag combined with the 13852 Require header. 13854 * Syntax unclarities with the Mode parameter have been resolved. 13856 * Syntax error with ";" for multicast and unicast has been 13857 resolved. 13859 * Two new addressing parameters have been defined, src_addr and 13860 dest_addr. These replace the parameters "port", "client_port", 13861 "server_port", "destination", "source". 13863 * Support for IPv6 explicit addresses in all address fields has 13864 been included. 13866 * To handle URI definitions that contain ";" or "," a quoted URI 13867 format has been introduced and is required. 13869 * Defined IANA registries for the transport headers parameters, 13870 transport-protocol, profile, lower-transport, and mode. 13872 * The transport headers interleaved parameter's text was made 13873 more strict and uses formal requirements levels. It was also 13874 clarified that the interleaved channels are symmetric and that 13875 it is the server that sets the channel numbers. 13877 * It has been clarified that the client can't request of the 13878 server to use a certain RTP SSRC, using a request with the 13879 transport parameter SSRC. 13881 * Syntax definition for SSRC has been clarified to require 8HEX. 13882 It has also been extended to allow multiple values for clients 13883 supporting this version. 13885 * Clarified the text on the transport headers "dest_addr" 13886 parameters regarding what security precautions the server is 13887 required to perform. 13889 o The Range formats has been changed in the following way: 13891 * The NPT format has been given an initial NPT identifier that 13892 must now be used. 13894 * All formats now support initial open ended formats of type 13895 "npt=-10" and also format only "Range: smpte" ranges for usage 13896 with GET_PARAMETER requests. 13898 * The npt-hhmmss notation now follows ISO 8601 more stricter. 13900 o RTSP message handling has been changed in the following way: 13902 * RTSP messages now use URIs rather then URLs. 13904 * It has been clarified that a 4xx message due to missing CSeq 13905 header shall be returned without a CSeq header. 13907 * The 300 (Multiple Choices) response code has been removed. 13909 * Rules for how to handle timing out RTSP messages has been 13910 added. 13912 * Extended Pipelining rules allowing for quick session startup. 13914 * Sequence numbering and proxy handling of sequence number 13915 defined, including case when response arrive out of order. 13917 o The HTTP references have been updated to RFC 2616 and RFC 2617. 13918 Most of the text has been copied and then altered to fit RTSP into 13919 this specification. Public, and the Content-Base header has also 13920 been imported from RFC 2068 so that they are defined in the RTSP 13921 specification. Known effects on RTSP due to HTTP clarifications: 13923 * Content-Encoding header can include encoding of type 13924 "identity". 13926 o The state machine section has been completely rewritten. It now 13927 includes more details and is also more clear about the model used. 13929 o An IANA section has been included which contains a number of 13930 registries and their rules. This will allow us to use IANA to 13931 keep track of RTSP extensions. 13933 o The transport of RTSP messages has seen the following changes: 13935 * The use of UDP for RTSP message transport has been deprecated 13936 due to missing interest and to broken specification. 13938 * The rules for how TCP connections are to be handled has been 13939 clarified. Now it is made clear that servers should not close 13940 the TCP connection unless they have been unused for significant 13941 time. 13943 * Strong recommendations why server and clients should use 13944 persistent connections have also been added. 13946 * There is now a requirement on the servers to handle non- 13947 persistent connections as this provides fault tolerance. 13949 * Added wording on the usage of Connection:Close for RTSP. 13951 * Specified usage of TLS for RTSP messages, including a scheme to 13952 approve a proxy's TLS connection to the next hop. 13954 o The following header related changes have been made: 13956 * Accept-Ranges response-header is added. This header clarifies 13957 which range formats that can be used for a resource. 13959 * Fixed the missing definitions for the Cache-Control header. 13960 Also added to the syntax definition the missing delta-seconds 13961 for max-stale and min-fresh parameters. 13963 * Put requirement on CSeq header that the value is increased by 13964 one for each new RTSP request. A Recommendation to start at 0 13965 has also been added. 13967 * Added requirement that the Date header must be used for all 13968 messages with message body and the Server should always include 13969 it. 13971 * Removed possibility of using Range header with Scale header to 13972 indicate when it is to be activated, since it can't work as 13973 defined. Also added rule that lack of Scale header in response 13974 indicates lack of support for the header. Feature-tags for 13975 scaled playback has been defined. 13977 * The Speed header must now be responded to indicate support and 13978 the actual speed going to be used. A feature-tag is defined. 13979 Notes on congestion control were also added. 13981 * The Supported header was borrowed from SIP [RFC3261] to help 13982 with the feature negotiation in RTSP. 13984 * Clarified that the Timestamp header can be used to resolve 13985 retransmission ambiguities. 13987 * The Session header text has been expanded with an explanation 13988 on keep-alive and which methods to use. SET_PARAMETER is now 13989 recommended to use if only keep-alive within RTSP is desired. 13991 * It has been clarified how the Range header formats are used to 13992 indicate pause points in the PAUSE response. 13994 * Clarified that RTP-Info URIs that are relative, use the 13995 Request-URI as base URI. Also clarified that the used URI must 13996 be the one that was used in the SETUP request. The URIs are 13997 now also required to be quoted. The header also expresses the 13998 SSRC for the provided RTP timestamp and sequence number values. 14000 * Added text that requires the Range to always be present in PLAY 14001 responses. Clarified what should be sent in case of live 14002 streams. 14004 * The headers table has been updated using a structure borrowed 14005 from SIP. Those tables convey much more information and should 14006 provide a good overview of the available headers. 14008 * It has been clarified that any message with a message body is 14009 required to have a Content-Length header. This was the case in 14010 RFC 2326, but could be misinterpreted. 14012 * ETag has changed name to MTag. 14014 * To resolve functionality around MTag. The MTag and If-None- 14015 Match header have been added from HTTP with necessary 14016 clarification in regards to RTSP operation. 14018 * Imported the Public header from HTTP RFC 2068 [RFC2068] since 14019 it has been removed from HTTP due to lack of use. Public is 14020 used quite frequently in RTSP. 14022 * Clarified rules for populating the Public header so that it is 14023 an intersection of the capabilities of all the RTSP agents in a 14024 chain. 14026 * Added the Media-Range header for listing the current 14027 availability of the media range. 14029 * Added the Notify-Reason header for giving the reason when 14030 sending PLAY_NOTIFY requests. 14032 * A new header Seek-Style has been defined to direct and inform 14033 how any seek operation should/have been performed. 14035 o The Protocol Syntax has been changed in the following way: 14037 * All ABNF definitions are updated according to the rules defined 14038 in RFC 5234 [RFC5234] and have been gathered in a separate 14039 Section 20. 14041 * The ABNF for the User-Agent and Server headers have been 14042 corrected. 14044 * Some definitions in the introduction regarding the RTSP session 14045 have been changed. 14047 * The protocol has been made fully IPv6 capable. 14049 * The CHAR rule has been changed to exclude NULL. 14051 o The Status codes have been changed in the following way: 14053 * The use of status code 303 "See Other" has been deprecated as 14054 it does not make sense to use in RTSP. 14056 * When sending response 451 and 458 the response body should 14057 contain the offending parameters. 14059 * Clarification on when a 3rr redirect status code can be 14060 received has been added. This includes receiving 3rr as a 14061 result of a request within a established session. This 14062 provides clarification to a previous unspecified behavior. 14064 * Removed the 201 (Created) and 250 (Low On Storage Space) status 14065 codes as they are only relevant to recording, which is 14066 deprecated. 14068 * Several new Status codes have been defined: 464 "Data Transport 14069 Not Ready Yet", 465 "Notification Reason Unknown", 470 14070 "Connection Authorization Required", 471 "Connection 14071 Credentials not accepted", 472 "Failure to establish secure 14072 connection". 14074 o The following functionality has been deprecated from the protocol: 14076 * The use of Queued Play. 14078 * The use of PLAY method for keep-alive in Play state. 14080 * The RECORD and ANNOUNCE methods and all related functionality. 14081 Some of the syntax has been removed. 14083 * The possibility to use timed execution of methods with the time 14084 parameter in the Range header. 14086 * The description on how rtspu works is not part of the core 14087 specification and will require external description. Only that 14088 it exists is defined here and some requirements for the 14089 transport is provided. 14091 o The following changes have been made in relation to methods: 14093 * The OPTIONS method has been clarified with regards to the use 14094 of the Public and Allow headers. 14096 * Added text clarifying the usage of SET_PARAMETER for keep-alive 14097 and usage without any body. 14099 * PLAY method is now allowed to be pipelined with the pipelining 14100 of one or more SETUP requests following the initial that 14101 generates the session for aggregated control. 14103 * REDIRECT has been expanded and diversified for different 14104 situations. 14106 * Added a new method PLAY_NOTIFY. This method is used by the 14107 RTSP server to asynchronously notify clients about session 14108 changes. 14110 o Wrote a new section about how to setup different media transport 14111 alternatives and their profiles, and lower layer protocols. This 14112 caused the appendix on RTP interaction to be moved there instead 14113 of being in the part which describes RTP. The section also 14114 includes guidelines what to consider when writing usage guidelines 14115 for new protocols and profiles. 14117 o Setup and usage of independent TCP connections for transport of 14118 RTP has been specified. 14120 o Added a new section describing the available mechanisms to 14121 determine if functionality is supported, called "Capability 14122 Handling". Renamed option-tags to feature-tags. 14124 o Added a contributors section with people who have contributed 14125 actual text to the specification. 14127 o Added a section Use Cases that describes the major use cases for 14128 RTSP. 14130 o Clarified the usage of a=range and how to indicate live content 14131 that are not seekable with this header. 14133 o Text specifying the special behavior of PLAY for live content. 14135 o Security features of RTSP have been clarified: 14137 * HTTP based authorization has been clarified requring both Basic 14138 and DIGEST support 14140 * TLS support mandated 14142 * IF one implements RTP then SRTP and defined MIKEY based key- 14143 exchange must be supported 14145 * Various minor mitigations discussed or resulted in protocol 14146 changes. 14148 Appendix J. Acknowledgements 14150 This memorandum defines RTSP version 2.0 which is a revision of the 14151 Proposed Standard RTSP version 1.0 which is defined in [RFC2326]. 14152 The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert 14153 Lanphier. 14155 Both RTSP version 1.0 and RTSP version 2.0 borrow format and 14156 descriptions from HTTP/1.1. 14158 Robert Sparks and especially Elwyn Davies provided very valuable and 14159 detailed reviews in the IETF last call that greately improved the 14160 document and resolved many issues, especially regarding consistency. 14162 This document has benefited greatly from the comments of all those 14163 participating in the MMUSIC-WG. In addition to those already 14164 mentioned, the following individuals have contributed to this 14165 specification: 14167 Rahul Agarwal, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten 14168 Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen 14169 Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Spencer 14170 Dawkins, Kelly Djahandari, Martin Dunsmuir, Adrian Farrel, Stephen 14171 Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Grignon, 14172 Christian Groves, V. Guruprasad, Peter Haight, Mark Handley, Brad 14173 Hefta-Gaub, Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, 14174 Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders 14175 Klemets, Ruth Lang, Barry Leiba, Stephanie Leif, Jonathan Lennox, 14176 Eduardo F. Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob 14177 McCool, Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria 14178 Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, 14179 Pekka Pessi, Igor Plotnikov, Pete Resnick, Peter Saint-Andre, Holger 14180 Schmidt, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff 14181 Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, Geetha 14182 Srikantan, Scott Taylor, David Walker, Stephan Wenger, Dale R. 14183 Worley, and Byungjo Yoon , and especially to Flemming Andreasen. 14185 J.1. Contributors 14187 The following people have made written contributions that were 14188 included in the specification: 14190 o Tom Marshall contributed text on the usage of 3rr status codes. 14192 o Thomas Zheng contributed text on the usage of the Range in PLAY 14193 responses and proposed an earlier version of the PLAY_NOTIFY 14194 method. 14196 o Sean Sheedy contributed text on the timeout behavior of RTSP 14197 messages and connections, the 463 status code, and proposed an 14198 earlier version of the PLAY_NOTIFY method. 14200 o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY 14201 method. 14203 o Fredrik Lindholm contributed text about the RTSP security 14204 framework. 14206 o John Lazzaro contributed the text for RTP over Independent TCP. 14208 o Aravind Narasimhan contributed by rewriting Media Transport 14209 Alternatives (Appendix C) and editorial improvements on a number 14210 of places in the specification. 14212 o Torbjorn Einarsson has done some editorial improvements of the 14213 text. 14215 Appendix K. RFC Editor Consideration 14217 Please replace RFC XXXX with the RFC number this specification 14218 receives. 14220 Authors' Addresses 14222 Henning Schulzrinne 14223 Columbia University 14224 1214 Amsterdam Avenue 14225 New York, NY 10027 14226 USA 14228 Email: schulzrinne@cs.columbia.edu 14229 Anup Rao 14230 Cisco 14231 USA 14233 Email: anrao@cisco.com 14235 Rob Lanphier 14236 Seattle, WA 14237 USA 14239 Email: robla@robla.net 14241 Magnus Westerlund 14242 Ericsson AB 14243 Faeroegatan 6 14244 STOCKHOLM SE-164 80 14245 SWEDEN 14247 Email: magnus.westerlund@ericsson.com 14249 Martin Stiemerling 14250 NEC Laboratories Europe, NEC Europe Ltd. 14251 Kurfuersten-Anlage 36 14252 Heidelberg 69115 14253 Germany 14255 Phone: +49 (0) 6221 4342 113 14256 Email: mls.ietf@gmail.com 14257 URI: http://www.stiemerling.org